From Internet-Drafts@ietf.org Wed Oct 2 15:22:52 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7646921F8EB2; Wed, 2 Oct 2013 15:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.483 X-Spam-Level: X-Spam-Status: No, score=-102.483 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7tOZHBjYya4c; Wed, 2 Oct 2013 15:22:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 46D8F21F92B8; Wed, 2 Oct 2013 15:20:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.72.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131002222020.8062.32327.idtracker@ietfa.amsl.com> Date: Wed, 02 Oct 2013 15:20:20 -0700 Cc: roll@ietf.org Subject: [Roll] I-D ACTION:draft-ietf-roll-terminology-13.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 22:22:52 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : Terms used in Ruting for Low power And Lossy Networks Author(s) : J. Vasseur Filename : draft-ietf-roll-terminology Pages : 8 Date : Oct. 2, 2013 The documents provides a glossary of terminology used in routing requirements and solutions for networks referred to as Low power and Lossy Networks (LLN). An LLN is typically composed of many embedded devices with limited power, memory, and processing resources interconnected by a variety of links. There is a wide scope of application areas for LLNs, including industrial monitoring, building automation (e.g. Heating, Ventilating, Air Conditioning, lighting, access control, fire), connected home, healthcare, environmental monitoring, urban sensor networks, energy management, assets tracking, refrigeration. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-terminology-13.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-roll-terminology"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2013-10-02152019.I-D@ietf.org> --NextPart-- From adrian@olddog.co.uk Thu Oct 3 01:50: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 B950021E805D for ; Thu, 3 Oct 2013 01:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.318 X-Spam-Level: X-Spam-Status: No, score=-2.318 tagged_above=-999 required=5 tests=[AWL=0.281, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oK-GUdtovAhq for ; Thu, 3 Oct 2013 01:50:11 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id D9FF821F9633 for ; Thu, 3 Oct 2013 01:48:37 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r938marc011351 for ; Thu, 3 Oct 2013 09:48:36 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r938mZkv011333 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 3 Oct 2013 09:48:35 +0100 From: "Adrian Farrel" To: References: <20131002185522.20697.96027.idtracker@ietfa.amsl.com> In-Reply-To: <20131002185522.20697.96027.idtracker@ietfa.amsl.com> Date: Thu, 3 Oct 2013 09:48:32 +0100 Message-ID: <031201cec015$579f31a0$06dd94e0$@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: AQH0d2L6ZdDWbm+Vxt1g3seAlz4BR5mXO69w Content-Language: en-gb Subject: [Roll] FW: Last Call: (Implications of Oversized IPv6 Header Chains) to Proposed Standard X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 08:50:25 -0000 I think that Some of you in ROLL should look at this document (which is in IETF last call) just to make sure that there is no conflict with RPL. Thanks, Adrian > -----Original Message----- > From: ietf-announce-bounces@ietf.org [mailto:ietf-announce- > bounces@ietf.org] On Behalf Of The IESG > Sent: 02 October 2013 19:55 > To: IETF-Announce > Cc: ipv6@ietf.org > Subject: Last Call: (Implications > of Oversized IPv6 Header Chains) to Proposed Standard > > > The IESG has received a request from the IPv6 Maintenance WG (6man) to > consider the following document: > - 'Implications of Oversized IPv6 Header Chains' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2013-10-16. 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 > > > The IPv6 specification allows IPv6 header chains of an arbitrary > size. The specification also allows options which can in turn extend > each of the headers. In those scenarios in which the IPv6 header > chain or options are unusually long and packets are fragmented, or > scenarios in which the fragment size is very small, the first > fragment of a packet may fail to include the entire IPv6 header > chain. This document discusses the interoperability and security > problems of such traffic, and updates RFC 2460 such that the first > fragment of a packet is required to contain the entire IPv6 header > chain. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-6man-oversized-header-chain/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-6man-oversized-header-chain/ballot/ > > > No IPR declarations have been submitted directly on this I-D. From iesg-secretary@ietf.org Thu Oct 3 03:36: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 C8BE011E8114; Thu, 3 Oct 2013 03:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.297 X-Spam-Level: X-Spam-Status: No, score=-102.297 tagged_above=-999 required=5 tests=[AWL=0.303, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KLAuvHARAvxW; Thu, 3 Oct 2013 03:36:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 392C911E80E7; Thu, 3 Oct 2013 03:34:39 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.72.p1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20131003103439.13078.31787.idtracker@ietfa.amsl.com> Date: Thu, 03 Oct 2013 03:34:39 -0700 Cc: roll@ietf.org Subject: [Roll] Last Call: (Terms used in Ruting for Low power And Lossy Networks) to Informational RFC X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: ietf@ietf.org, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 10:36:36 -0000 The IESG has received a request from the Routing Over Low power and Lossy networks WG (roll) to consider the following document: - 'Terms used in Ruting for Low power And Lossy Networks' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-10-17. 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 The documents provides a glossary of terminology used in routing requirements and solutions for networks referred to as Low power and Lossy Networks (LLN). An 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 file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-roll-terminology/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-roll-terminology/ballot/ No IPR declarations have been submitted directly on this I-D. From stokcons@xs4all.nl Thu Oct 3 06:09: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 DD62B11E80A2 for ; Thu, 3 Oct 2013 06:09:05 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cp6-fJqDW9CS for ; Thu, 3 Oct 2013 06:08:53 -0700 (PDT) Received: from smtp-vbr4.xs4all.nl (smtp-vbr4.xs4all.nl [194.109.24.24]) by ietfa.amsl.com (Postfix) with ESMTP id AEE1711E80DE for ; Thu, 3 Oct 2013 06:04:39 -0700 (PDT) Received: from roundcube.xs4all.nl (roundcube9.xs4all.net [194.109.20.207]) by smtp-vbr4.xs4all.nl (8.13.8/8.13.8) with ESMTP id r93D4cPA019853 for ; Thu, 3 Oct 2013 15:04:38 +0200 (CEST) (envelope-from stokcons@xs4all.nl) Received: from AMontpellier-654-1-22-56.w90-0.abo.wanadoo.fr ([90.0.37.56]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 03 Oct 2013 15:04:38 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 03 Oct 2013 15:04:38 +0200 From: peter van der Stok To: roll@ietf.org Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <03B78081B371D44390ED6E7BADBB4A77238284EB@xmb-rcd-x02.cisco.com> References: <03B78081B371D44390ED6E7BADBB4A77238284EB@xmb-rcd-x02.cisco.com> Message-ID: <2729a8acea264eaa74d77162cabd47bc@xs4all.nl> X-Sender: stokcons@xs4all.nl (TeaEQBbE9vpTwt0ldloS0Hg+Es1eej0z) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Subject: Re: [Roll] Applicability Statements Documents X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: consultancy@vanderstok.org, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 13:09:06 -0000 Dear all, for building we have submitted a draft version with all sections filled in, conformant to the last template but one. The draft is not completely finished as I am waiting for more information on MPL execution behaviour investigations that are currently going on. Suggestions for improvement will be appreciated, Peter JP Vasseur (jvasseur) schreef op 2013-09-26 14:16: > Dear all (especially to the authors), > > As you know, we are dramatically lagging behind with regards to our > applicability statements (AMI, home, industrial, ...). As a reminder: > > Feb 2013 > Submit first draft of RPL applicability statement for Home > Automation applications to the IESG to be considered as an > Informational RFC > > Feb 2013 > Submit first draft of RPL applicability statement for Building > Automation applications to the IESG to be considered as an > Informational RFC > > Feb 2013 > Submit first draft of RPL applicability statement for Industrial > applications to the IESG to be considered as an Informational RFC > > So we would really appreciate if the authors could give us an update > on these WG documents, copying the list. > > Many Thanks ! > > JP and Michael. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From mcr@sandelman.ca Thu Oct 3 07:17: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 4178F21F999B; Thu, 3 Oct 2013 07:17:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UyXdXZAsTen1; Thu, 3 Oct 2013 07:16:55 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 5C05721E804D; Thu, 3 Oct 2013 07:11:18 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id BB61A2017B; Thu, 3 Oct 2013 11:21:01 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 8858163B18; Thu, 3 Oct 2013 10:11:16 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 75EAD63AED; Thu, 3 Oct 2013 10:11:16 -0400 (EDT) From: Michael Richardson To: Dave Cridland In-Reply-To: References: <20131003103439.13078.31787.idtracker@ietfa.amsl.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 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, "ietf@ietf.org Discussion" , Scott O Bradner Subject: Re: [Roll] Last Call: (Terms used in Ruting for Low power And Lossy Networks) to Informational RFC X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 14:17:03 -0000 Dave Cridland wrote: >> The IESG has received a request from the Routing Over Low power and >> Lossy networks WG (roll) to consider the following document: - 'Terms >> used in Ruting for Low power And Lossy Networks' >> =C2=A0 as Informational RFC > I'd assumed that they'd misspelt "rutting", and was quite disappointed > in the document as a result. Well. I think that we really do not want the motes to start replicating. At least, we need to let Jack O'Neil decode the Ancient Knowledge first. (I've been rewatching SG-1...) -- ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | network architect= [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ From yusuke.doi@toshiba.co.jp Fri Oct 4 01:15: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 A1F3021F9B85 for ; Fri, 4 Oct 2013 01:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.089 X-Spam-Level: X-Spam-Status: No, score=-8.089 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-8, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zj6GbRzcRLfk for ; Fri, 4 Oct 2013 01:15:28 -0700 (PDT) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by ietfa.amsl.com (Postfix) with ESMTP id 34B5821F9C69 for ; Fri, 4 Oct 2013 01:08:05 -0700 (PDT) Received: from tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp ([133.199.232.103]) by imx12.toshiba.co.jp with ESMTP id r9487i4Z024337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 4 Oct 2013 17:07:45 +0900 (JST) Received: from tsbmgw-mgw01 (localhost [127.0.0.1]) by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r9487hig012311 for ; Fri, 4 Oct 2013 17:07:43 +0900 Received: from localhost ([127.0.0.1]) by tsbmgw-mgw01 (JAMES SMTP Server 2.3.1) with SMTP ID 281 for ; Fri, 4 Oct 2013 17:07:43 +0900 (JST) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r9487hua012306 for ; Fri, 4 Oct 2013 17:07:43 +0900 Received: (from root@localhost) by arc11.toshiba.co.jp id r9487hI0023511 for roll@ietf.org; Fri, 4 Oct 2013 17:07:43 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id TAA23507; Fri, 4 Oct 2013 17:07:43 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id r9487gNl028982 for ; Fri, 4 Oct 2013 17:07:42 +0900 (JST) Received: from spiffy21.isl.rdc.toshiba.co.jp by toshiba.co.jp id r9487gsb024011; Fri, 4 Oct 2013 17:07:42 +0900 (JST) Received: from [133.196.16.145] (ncg-dhcp145.isl.rdc.toshiba.co.jp [133.196.16.145]) by spiffy21.isl.rdc.toshiba.co.jp (Postfix) with ESMTPS id 3141997D7E for ; Fri, 4 Oct 2013 17:07:39 +0900 (JST) Message-ID: <524E7734.1010604@toshiba.co.jp> Date: Fri, 04 Oct 2013 17:07:16 +0900 From: Yusuke DOI User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: roll@ietf.org Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: [Roll] Question on MPL: parameter update on runnning MPL forwarders X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 08:15:41 -0000 Hi, I have a simple question: is it possible to update MPL parameters of running forwarder instances? To maintain the system in 'good state', I expect some sort of parameter tuning on MPL. Especially for the systems dynamically grows, static configuration of MPL parameters will be difficult. For example, DHCPv6 reconfigure request can be used to update MPL forwarder parameter. However, I'm not sure it's 'safe' to update parameters (K, Imin, Imax) of running MPL forwarder instances. I think it's safe if there are no transmission / no valid seed set. Is it possible to update a running MPL forwarder parameter without breaking current state? Regards, Yusuke From stokcons@xs4all.nl Fri Oct 4 01:35: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 B01F721F98EE for ; Fri, 4 Oct 2013 01:35:41 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id unbQ+J2C-FJb for ; Fri, 4 Oct 2013 01:35:30 -0700 (PDT) Received: from smtp-vbr6.xs4all.nl (smtp-vbr6.xs4all.nl [194.109.24.26]) by ietfa.amsl.com (Postfix) with ESMTP id A319F21F8F3C for ; Fri, 4 Oct 2013 01:29:52 -0700 (PDT) Received: from roundcube.xs4all.nl (roundcube12.xs4all.net [194.109.20.211]) by smtp-vbr6.xs4all.nl (8.13.8/8.13.8) with ESMTP id r948Toka015082 for ; Fri, 4 Oct 2013 10:29:51 +0200 (CEST) (envelope-from stokcons@xs4all.nl) Received: from AMontpellier-654-1-22-56.w90-0.abo.wanadoo.fr ([90.0.37.56]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Fri, 04 Oct 2013 10:29:50 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 04 Oct 2013 10:29:50 +0200 From: peter van der Stok To: roll@ietf.org Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <524E7734.1010604@toshiba.co.jp> References: <524E7734.1010604@toshiba.co.jp> Message-ID: <161bac5b78b2dd33ad805a81e7df83f4@xs4all.nl> X-Sender: stokcons@xs4all.nl (ZlKOByBhRmf0X4qHeKR3xAA/gbgBnl21) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Subject: Re: [Roll] Question on MPL: parameter update on runnning MPL forwarders X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: consultancy@vanderstok.org, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 08:35:42 -0000 Hi Yusuke. I think you may "safely" change Imin, ,k, Imax and repeat per new message for all involved forwarders, while leaving all earlier messages unaffected. BUT this needs LARGE changes to the current spec. My 2 cents, peter Yusuke DOI schreef op 2013-10-04 10:07: > Hi, > > I have a simple question: is it possible to update MPL parameters of > running forwarder instances? > > To maintain the system in 'good state', I expect some sort of > parameter tuning on MPL. Especially for the systems dynamically grows, > static configuration of MPL parameters will be difficult. For example, > DHCPv6 reconfigure request can be used to update MPL forwarder > parameter. However, I'm not sure it's 'safe' to update parameters (K, > Imin, Imax) of running MPL forwarder instances. > > I think it's safe if there are no transmission / no valid seed set. Is > it possible to update a running MPL forwarder parameter without > breaking current state? > > Regards, > > Yusuke > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From yusuke.doi@toshiba.co.jp Fri Oct 4 04:06: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 A8EFB21F942D for ; Fri, 4 Oct 2013 04:06:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.089 X-Spam-Level: X-Spam-Status: No, score=-6.089 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YvqbTZKVLfja for ; Fri, 4 Oct 2013 04:06:09 -0700 (PDT) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id 7247021F9991 for ; Fri, 4 Oct 2013 04:04:51 -0700 (PDT) Received: from tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp ([133.199.200.50]) by imx2.toshiba.co.jp with ESMTP id r94B4mSV021828 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 4 Oct 2013 20:04:48 +0900 (JST) Received: from tsbmgw-mgw02 (localhost [127.0.0.1]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r94B4m2I015552 for ; Fri, 4 Oct 2013 20:04:48 +0900 Received: from localhost ([127.0.0.1]) by tsbmgw-mgw02 (JAMES SMTP Server 2.3.1) with SMTP ID 667 for ; Fri, 4 Oct 2013 20:04:48 +0900 (JST) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r94B4mPu015546 for ; Fri, 4 Oct 2013 20:04:48 +0900 Received: (from root@localhost) by arc1.toshiba.co.jp id r94B4mAY022867 for roll@ietf.org; Fri, 4 Oct 2013 20:04:48 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id WAA22861; Fri, 4 Oct 2013 20:04:48 +0900 Received: from mx12.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id r94B4lr5029574 for ; Fri, 4 Oct 2013 20:04:47 +0900 (JST) Received: from spiffy21.isl.rdc.toshiba.co.jp by toshiba.co.jp id r94B4lfN012419; Fri, 4 Oct 2013 20:04:47 +0900 (JST) Received: from [133.196.16.145] (ncg-dhcp145.isl.rdc.toshiba.co.jp [133.196.16.145]) by spiffy21.isl.rdc.toshiba.co.jp (Postfix) with ESMTPS id 7EA2897D7E; Fri, 4 Oct 2013 20:04:47 +0900 (JST) Message-ID: <524EA0B9.4090908@toshiba.co.jp> Date: Fri, 04 Oct 2013 20:04:25 +0900 From: Yusuke DOI User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: consultancy@vanderstok.org References: <524E7734.1010604@toshiba.co.jp> <161bac5b78b2dd33ad805a81e7df83f4@xs4all.nl> In-Reply-To: <161bac5b78b2dd33ad805a81e7df83f4@xs4all.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: roll@ietf.org, peter van der Stok Subject: Re: [Roll] Question on MPL: parameter update on runnning MPL forwarders X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 11:06:21 -0000 Hi Peter, I have not recognized it needs LARGE change. My first idea was to replace the parameters at the very beginning of an interval (step 2 of RFC6206 section 4.2) for each trickle timer. Because it's difficult to synchronize the update, I think unbalanced retransmission may occur in transient period. I assume it's acceptable (safe enough). Could you tell me about your concerns that requires LARGE spec update? Regards, Yusuke (2013-10-04 17:29), peter van der Stok wrote: > Hi Yusuke. > > I think you may "safely" change Imin, ,k, Imax and repeat per new message for all involved forwarders, while leaving all earlier messages unaffected. BUT this needs LARGE changes to the current spec. > > My 2 cents, > > peter > > > > Yusuke DOI schreef op 2013-10-04 10:07: >> Hi, >> >> I have a simple question: is it possible to update MPL parameters of >> running forwarder instances? >> >> To maintain the system in 'good state', I expect some sort of >> parameter tuning on MPL. Especially for the systems dynamically grows, >> static configuration of MPL parameters will be difficult. For example, >> DHCPv6 reconfigure request can be used to update MPL forwarder >> parameter. However, I'm not sure it's 'safe' to update parameters (K, >> Imin, Imax) of running MPL forwarder instances. >> >> I think it's safe if there are no transmission / no valid seed set. Is >> it possible to update a running MPL forwarder parameter without >> breaking current state? >> >> Regards, >> >> Yusuke >> >> >> _______________________________________________ >> 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 stokcons@xs4all.nl Fri Oct 4 05:03:28 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA31921F86BE for ; Fri, 4 Oct 2013 05:03:28 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PI5pOZfEuWVy for ; Fri, 4 Oct 2013 05:03:17 -0700 (PDT) Received: from smtp-vbr1.xs4all.nl (smtp-vbr1.xs4all.nl [194.109.24.21]) by ietfa.amsl.com (Postfix) with ESMTP id 56DA421F8790 for ; Fri, 4 Oct 2013 05:02:37 -0700 (PDT) Received: from roundcube.xs4all.nl (roundcube12.xs4all.net [194.109.20.211]) by smtp-vbr1.xs4all.nl (8.13.8/8.13.8) with ESMTP id r94C2T0e020947; Fri, 4 Oct 2013 14:02:30 +0200 (CEST) (envelope-from stokcons@xs4all.nl) Received: from AMontpellier-654-1-22-56.w90-0.abo.wanadoo.fr ([90.0.37.56]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Fri, 04 Oct 2013 14:02:29 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 04 Oct 2013 14:02:29 +0200 From: peter van der Stok To: Yusuke DOI Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <524EA0B9.4090908@toshiba.co.jp> References: <524E7734.1010604@toshiba.co.jp> <161bac5b78b2dd33ad805a81e7df83f4@xs4all.nl> <524EA0B9.4090908@toshiba.co.jp> Message-ID: <641a5c59776214374984816097e08d9a@xs4all.nl> X-Sender: stokcons@xs4all.nl (q8svXxnbx7DmvEgJaXKdqCA9dzKt/gHc) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Cc: roll@ietf.org Subject: Re: [Roll] Question on MPL: parameter update on runnning MPL forwarders X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: consultancy@vanderstok.org, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 12:03:28 -0000 Hi Yusuke, For the moment the parameters are general for al interfaces, seeds and messages. In the case of changing per message, the parameter sets need to be attached to each message entry. (for me that is a large change) Second for synchronous change, parameters need to be transported in message from seed. (Another large change to the message format). Please be aware that there are as many trickle timers as there are messages outstanding, so what is the start of the interval? Anything I missed here? peter Yusuke DOI schreef op 2013-10-04 13:04: > Hi Peter, > > I have not recognized it needs LARGE change. My first idea was to > replace the parameters at the very beginning of an interval (step 2 of > RFC6206 section 4.2) for each trickle timer. Because it's difficult to > synchronize the update, I think unbalanced retransmission may occur in > transient period. I assume it's acceptable (safe enough). > > Could you tell me about your concerns that requires LARGE spec update? > > Regards, > > Yusuke > > > (2013-10-04 17:29), peter van der Stok wrote: > Hi Yusuke. > > I think you may "safely" change Imin, ,k, Imax and repeat per new > message for all involved forwarders, while leaving all earlier messages > unaffected. BUT this needs LARGE changes to the current spec. > > My 2 cents, > > peter > > > > Yusuke DOI schreef op 2013-10-04 10:07: > Hi, > > I have a simple question: is it possible to update MPL parameters of > running forwarder instances? > > To maintain the system in 'good state', I expect some sort of > parameter tuning on MPL. Especially for the systems dynamically grows, > static configuration of MPL parameters will be difficult. For example, > DHCPv6 reconfigure request can be used to update MPL forwarder > parameter. However, I'm not sure it's 'safe' to update parameters (K, > Imin, Imax) of running MPL forwarder instances. > > I think it's safe if there are no transmission / no valid seed set. Is > it possible to update a running MPL forwarder parameter without > breaking current state? > > Regards, > > Yusuke > > > _______________________________________________ > 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 yusuke.doi@toshiba.co.jp Fri Oct 4 06:14:34 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A6BB21F999C for ; Fri, 4 Oct 2013 06:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.089 X-Spam-Level: X-Spam-Status: No, score=-7.089 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-8, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fbQAMtTxCL6A for ; Fri, 4 Oct 2013 06:14:22 -0700 (PDT) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by ietfa.amsl.com (Postfix) with ESMTP id 8D9A821F8B07 for ; Fri, 4 Oct 2013 06:03:38 -0700 (PDT) Received: from tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp ([133.199.232.103]) by imx12.toshiba.co.jp with ESMTP id r94D3awn017923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 4 Oct 2013 22:03:36 +0900 (JST) Received: from tsbmgw-mgw01 (localhost [127.0.0.1]) by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r94D3aaK030163 for ; Fri, 4 Oct 2013 22:03:36 +0900 Received: from localhost ([127.0.0.1]) by tsbmgw-mgw01 (JAMES SMTP Server 2.3.1) with SMTP ID 1005 for ; Fri, 4 Oct 2013 22:03:36 +0900 (JST) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r94D3ZIF030157 for ; Fri, 4 Oct 2013 22:03:35 +0900 Received: (from root@localhost) by arc11.toshiba.co.jp id r94D3Zve011849 for roll@ietf.org; Fri, 4 Oct 2013 22:03:35 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id YAA11847; Fri, 4 Oct 2013 22:03:35 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id r94D3ZUq002353 for ; Fri, 4 Oct 2013 22:03:35 +0900 (JST) Received: from spiffy21.isl.rdc.toshiba.co.jp by toshiba.co.jp id r94D3Z9Y024112; Fri, 4 Oct 2013 22:03:35 +0900 (JST) Received: from [133.196.16.145] (ncg-dhcp145.isl.rdc.toshiba.co.jp [133.196.16.145]) by spiffy21.isl.rdc.toshiba.co.jp (Postfix) with ESMTPS id BC18B97D7E; Fri, 4 Oct 2013 22:03:35 +0900 (JST) Message-ID: <524EBC90.3020702@toshiba.co.jp> Date: Fri, 04 Oct 2013 22:03:12 +0900 From: Yusuke DOI User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: consultancy@vanderstok.org References: <524E7734.1010604@toshiba.co.jp> <161bac5b78b2dd33ad805a81e7df83f4@xs4all.nl> <524EA0B9.4090908@toshiba.co.jp> <641a5c59776214374984816097e08d9a@xs4all.nl> In-Reply-To: <641a5c59776214374984816097e08d9a@xs4all.nl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: roll@ietf.org, peter van der Stok Subject: Re: [Roll] Question on MPL: parameter update on runnning MPL forwarders X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 13:14:34 -0000 Hi Peter, Thanks! I think my idea can be applied only for the trickle timer for control messages. I agree synchronous change will be difficult without changing message format. It may be done out-of-band (such as DHCP, SNMP, ...) if asynchronous per-node update is allowed. Regards, Yusuke (2013-10-04 21:02), peter van der Stok wrote: > Hi Yusuke, > > For the moment the parameters are general for al interfaces, seeds and messages. > In the case of changing per message, the parameter sets need to be attached to each message entry. (for me that is a large change) > Second for synchronous change, parameters need to be transported in message from seed. (Another large change to the message format). > > Please be aware that there are as many trickle timers as there are messages outstanding, so what is the start of the interval? > > Anything I missed here? > > peter > > > Yusuke DOI schreef op 2013-10-04 13:04: >> Hi Peter, >> >> I have not recognized it needs LARGE change. My first idea was to >> replace the parameters at the very beginning of an interval (step 2 of >> RFC6206 section 4.2) for each trickle timer. Because it's difficult to >> synchronize the update, I think unbalanced retransmission may occur in >> transient period. I assume it's acceptable (safe enough). >> >> Could you tell me about your concerns that requires LARGE spec update? >> >> Regards, >> >> Yusuke >> >> >> (2013-10-04 17:29), peter van der Stok wrote: >> Hi Yusuke. >> >> I think you may "safely" change Imin, ,k, Imax and repeat per new message for all involved forwarders, while leaving all earlier messages unaffected. BUT this needs LARGE changes to the current spec. >> >> My 2 cents, >> >> peter >> >> >> >> Yusuke DOI schreef op 2013-10-04 10:07: >> Hi, >> >> I have a simple question: is it possible to update MPL parameters of >> running forwarder instances? >> >> To maintain the system in 'good state', I expect some sort of >> parameter tuning on MPL. Especially for the systems dynamically grows, >> static configuration of MPL parameters will be difficult. For example, >> DHCPv6 reconfigure request can be used to update MPL forwarder >> parameter. However, I'm not sure it's 'safe' to update parameters (K, >> Imin, Imax) of running MPL forwarder instances. >> >> I think it's safe if there are no transmission / no valid seed set. Is >> it possible to update a running MPL forwarder parameter without >> breaking current state? >> >> Regards, >> >> Yusuke >> >> >> _______________________________________________ >> 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 d.sturek@att.net Fri Oct 4 06:51: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 928EA21F9A90 for ; Fri, 4 Oct 2013 06:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7uQQNeKhYEQY for ; Fri, 4 Oct 2013 06:51:22 -0700 (PDT) Received: from nm7-vm8.access.bullet.mail.bf1.yahoo.com (nm7-vm8.access.bullet.mail.bf1.yahoo.com [216.109.114.167]) by ietfa.amsl.com (Postfix) with ESMTP id B7BF721F9A2E for ; Fri, 4 Oct 2013 06:45:18 -0700 (PDT) Received: from [66.196.81.158] by nm7.access.bullet.mail.bf1.yahoo.com with NNFMP; 04 Oct 2013 13:45:17 -0000 Received: from [98.138.104.99] by tm4.access.bullet.mail.bf1.yahoo.com with NNFMP; 04 Oct 2013 13:45:17 -0000 Received: from [127.0.0.1] by smtp119.sbc.mail.ne1.yahoo.com with NNFMP; 04 Oct 2013 13:45:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1380894317; bh=2nSR+pED1QPQXCtuCKXkcqvlZ124wQsI5sP0fF76jLM=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=0Ek+/Gh68IEmqg93ZO8YBROo8smRGVTV9AcxqE5UpfIJdrVHROwHlejj8cxydNVU/m8D0v9vMkT4TiVDdp7KmLQi9cY1WSBbZ0iKOo3yEUPmSZBQohz0YSQ9X9zAvP5Juh/jLX3uTuXuwCM2AxwfNUvkOkQ2clELsb/K5FBpkf8= X-Yahoo-Newman-Id: 63068.44506.bm@smtp119.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: _u6NolYVM1mIjE6_IyNHiekE85yUePuqZl1Gj0VOCXvV8ZI YOxwOIw2oJ.ovIAuWzM.kZRVOG_iKr5QCSlHSm71XhmTPA7eVz4OPnC.HuDN IewIHsDaJQ4MQh6XDEqoVjQnSaFUUC53m5zlSc.DfkeBWaGh6A3yRJanw9WV xaKSLS2m5SsNgpLvpUio37130vVd_LXOSe4LgK5IxrOnlod7kl5msblRORp6 1oZ.c4Y9VvTHrb2C3a2bJXgIth6pH0ICElNSwLghIf3MthMN5NlDCUkuzpdW eXUTTHpuF8513QTWcsL5emGkWygUf83hSA3So6z1E7T0RQwOFt4OqXE5.Tnj 8yk_Ji4Y2MOcXk4vPiCMOJTt5cRqKVoTjxm2N0y6tIAQQFOXS5XIhZJDkagh iSXzHspuunbDFC616v.Ja3lYzKhzcLdnY0RqCDwW2d4rY2DnnaMaq8up_URt xyXkdpYbS916wEvXCvgWh7aZUUB6Cxx8b_Bo9JDyckeYS.KiXGZbynDePh9Q hb4.ca.pa2UKMiv15qNMDkXhScx9nSCK6.eteZfqMzV8vv4Hcobz3RuVKS6S _TNY6 X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-Rocket-Received: from [10.0.0.4] (d.sturek@69.105.138.165 with ) by smtp119.sbc.mail.ne1.yahoo.com with SMTP; 04 Oct 2013 13:45:17 +0000 UTC User-Agent: Microsoft-MacOutlook/14.3.7.130812 Date: Fri, 04 Oct 2013 06:45:13 -0700 From: Don Sturek To: Routing Over Low power and Lossy networks Message-ID: Thread-Topic: [Roll] Question on MPL: parameter update on runnning MPL forwarders In-Reply-To: <524E7734.1010604@toshiba.co.jp> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [Roll] Question on MPL: parameter update on runnning MPL forwarders X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 13:51:43 -0000 Hi Yusuke, I don't believe it is possible to change imin, imax, k or any other operational MPL forwarder parameter without some sort of pre-distribution/synchronization of the new parameters. It would work as you note if there are no transmission or valid seed set but if multicast traffic is already present using an existing seed, I would expect you would see issues in distribution of messages if you change the parameters while in operation. Additionally, if you use MPL to distribute the change with existing multicast traffic you will find some nodes do not get the new parameters (which will create other problems when you want the new parameters to take effect) Don On 10/4/13 1:07 AM, "Yusuke DOI" wrote: >Hi, > >I have a simple question: is it possible to update MPL parameters of >running forwarder instances? > >To maintain the system in 'good state', I expect some sort of parameter >tuning on MPL. Especially for the systems dynamically grows, static >configuration of MPL parameters will be difficult. For example, DHCPv6 >reconfigure request can be used to update MPL forwarder parameter. >However, I'm not sure it's 'safe' to update parameters (K, Imin, Imax) of >running MPL forwarder instances. > >I think it's safe if there are no transmission / no valid seed set. Is it >possible to update a running MPL forwarder parameter without breaking >current state? > >Regards, > >Yusuke > > >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll From yusuke.doi@toshiba.co.jp Fri Oct 4 08:11: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 0A14921F9BB5 for ; Fri, 4 Oct 2013 08:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.09 X-Spam-Level: X-Spam-Status: No, score=-8.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zTmt++vhrwvw for ; Fri, 4 Oct 2013 08:11:26 -0700 (PDT) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by ietfa.amsl.com (Postfix) with ESMTP id 3F5F321F9D9A for ; Fri, 4 Oct 2013 08:07:07 -0700 (PDT) Received: from tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp ([133.199.232.103]) by imx12.toshiba.co.jp with ESMTP id r94F76po000084 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 5 Oct 2013 00:07:06 +0900 (JST) Received: from tsbmgw-mgw01 (localhost [127.0.0.1]) by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r94F755A014256 for ; Sat, 5 Oct 2013 00:07:05 +0900 Received: from localhost ([127.0.0.1]) by tsbmgw-mgw01 (JAMES SMTP Server 2.3.1) with SMTP ID 846 for ; Sat, 5 Oct 2013 00:07:05 +0900 (JST) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r94F75Q3014250 for ; Sat, 5 Oct 2013 00:07:05 +0900 Received: (from root@localhost) by arc11.toshiba.co.jp id r94F75HK005027 for roll@ietf.org; Sat, 5 Oct 2013 00:07:05 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id AAA05025; Sat, 5 Oct 2013 00:07:05 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id r94F75P6017239 for ; Sat, 5 Oct 2013 00:07:05 +0900 (JST) Received: by toshiba.co.jp id r94F74xX010751; Sat, 5 Oct 2013 00:07:04 +0900 (JST) Date: Sat, 05 Oct 2013 00:07:03 +0900 (JST) Message-Id: <201310041507.r94F74xX010751@toshiba.co.jp> To: roll@ietf.org, d.sturek@att.net From: DOI Yusuke In-Reply-To: References: <524E7734.1010604@toshiba.co.jp> X-Mailer: Mew version 6.3 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [Roll] Question on MPL: parameter update on runnning MPL forwarders X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 15:11:40 -0000 Hi Don, I thought some unbalanced transmission could happen and acceptable, but other issues may occur as you and Peter say. I think it's better to find some workaround for now. Thank you very much! Yusuke From: Don Sturek Subject: Re: [Roll] Question on MPL: parameter update on runnning MPL forwarders Date: Fri, 04 Oct 2013 06:45:13 -0700 > Hi Yusuke, > > > > I don't believe it is possible to change imin, imax, k or any other > operational MPL forwarder parameter without some sort of > pre-distribution/synchronization of the new parameters. It would work as > you note if there are no transmission or valid seed set but if multicast > traffic is already present using an existing seed, I would expect you > would see issues in distribution of messages if you change the parameters > while in operation. Additionally, if you use MPL to distribute the > change with existing multicast traffic you will find some nodes do not get > the new parameters (which will create other problems when you want the new > parameters to take effect) > > Don > > > > On 10/4/13 1:07 AM, "Yusuke DOI" wrote: > >>Hi, >> >>I have a simple question: is it possible to update MPL parameters of >>running forwarder instances? >> >>To maintain the system in 'good state', I expect some sort of parameter >>tuning on MPL. Especially for the systems dynamically grows, static >>configuration of MPL parameters will be difficult. For example, DHCPv6 >>reconfigure request can be used to update MPL forwarder parameter. >>However, I'm not sure it's 'safe' to update parameters (K, Imin, Imax) of >>running MPL forwarder instances. >> >>I think it's safe if there are no transmission / no valid seed set. Is it >>possible to update a running MPL forwarder parameter without breaking >>current state? >> >>Regards, >> >>Yusuke >> >> >>_______________________________________________ >>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 d.sturek@att.net Fri Oct 4 08: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 0618021F9AA1 for ; Fri, 4 Oct 2013 08:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KRyc+STf1W88 for ; Fri, 4 Oct 2013 08:17:10 -0700 (PDT) Received: from nm6-vm1.access.bullet.mail.gq1.yahoo.com (nm6-vm1.access.bullet.mail.gq1.yahoo.com [216.39.63.4]) by ietfa.amsl.com (Postfix) with ESMTP id 31D7821F99FD for ; Fri, 4 Oct 2013 08:14:37 -0700 (PDT) Received: from [216.39.60.173] by nm6.access.bullet.mail.gq1.yahoo.com with NNFMP; 04 Oct 2013 15:14:37 -0000 Received: from [98.138.104.96] by tm9.access.bullet.mail.gq1.yahoo.com with NNFMP; 04 Oct 2013 15:14:37 -0000 Received: from [127.0.0.1] by smtp116.sbc.mail.ne1.yahoo.com with NNFMP; 04 Oct 2013 15:14:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1380899677; bh=bi/dgDyTYkv74CirolMV6Wi2IOL6hbFMSsnCq9Q1pOI=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=BFBAW6gN3NMJvPDKaabUGdN1QVxR+Wen0AKz3RRqPHrdEj3jESQ7Kc7XU5cHG6ZEFLFVmF4a3uh1h7Gc3i0UmmENC2MH8tREXqnDhmoFMobTYoKpiABJzBOvnwbAc92eY15IDRWw0aJjAYZ1FICZFfnwZb8mw3jn19Q6FRFf9Zg= X-Yahoo-Newman-Id: 432364.60404.bm@smtp116.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: i6r9fZ8VM1nU3hdbYW.Ro0FDr9w9Qa6FGTu95d_vkm6DeAj r.aGzwMrwQuetlOUlBImLZiXhrUsw4a_i0HMKzffmbu.vfSohAYSEIg5AZiy kIV5EmVR.XgLF.dXANRtAYEhxtHznexRdKbv81BBj8LrrkssoYwdODeEifmr UXYGC.vDHzP4M6Eurxl4OB2I4AGpMAIzhVIbCUZPl7mSVknhcicBe4cU8eaQ Jvsftr1ajYcNa4oZQCAqKzYojbU9LslXPXkOjMNqa4dYymDbbpMxKCe4sr9X 6E26_YDPgb9VOxalg9._aiUaYjx8z6hu4iUV_oboC1DhuKTTW0we2gXVm2F. KpL7yOxmJlToYhG98UNE2wan2wn..whaypIqV9.NBrqjFTBeP8xTWEaXm91N 9J8qJcIFP679V0K2El3KoLGU.brHXyLMkv5I6ePAoEOZ.ceQ47SKt_SpROP7 xcwb1GCedG_ICEb4n9KWwx6QNgYeY5rxIslnY89Q7FG.cYbOehOiXLsnzDRO e80RO2LdYpVPpljAqLhUHPzBxFJU3aUTMPcu_2Ai7KcawmLF9_mLVu4_UOS3 ZZIYa X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-Rocket-Received: from [10.0.0.4] (d.sturek@69.105.138.165 with ) by smtp116.sbc.mail.ne1.yahoo.com with SMTP; 04 Oct 2013 15:14:37 +0000 UTC User-Agent: Microsoft-MacOutlook/14.3.7.130812 Date: Fri, 04 Oct 2013 08:14:33 -0700 From: Don Sturek To: DOI Yusuke , Message-ID: Thread-Topic: [Roll] Question on MPL: parameter update on runnning MPL forwarders In-Reply-To: <201310041507.r94F7475016020@toshiba.co.jp> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [Roll] Question on MPL: parameter update on runnning MPL forwarders X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 15:17:24 -0000 Hi Yusuke, I think it would depend on how different the settings are between the old imin, imax, k, etc. Imagine a change where the values of the old imin, imax, k, etc. and the new ones were such that the new imax is now less than the old imin. If you mix that in with the unmanaged delivery of the new values I think you would find that the forwarding of transmissions at that time (including the update of the new MPL parameters themselves) would not guarantee delivery to all nodes. I do think if you were to change the imin, imax, k values in a "small" way then there might be little to no impact on forwarding (where "small" I guess would be a bit hard to quantify} The safest solution is to use the old values to distribute the new values and then validate all nodes have the value (synchronization) and then have the new values take effect. Don On 10/4/13 8:07 AM, "DOI Yusuke" wrote: >Hi Don, > >I thought some unbalanced transmission could happen and acceptable, >but other issues may occur as you and Peter say. > >I think it's better to find some workaround for now. > >Thank you very much! > >Yusuke > >From: Don Sturek >Subject: Re: [Roll] Question on MPL: parameter update on runnning MPL >forwarders >Date: Fri, 04 Oct 2013 06:45:13 -0700 > >> Hi Yusuke, >> >> >> >> I don't believe it is possible to change imin, imax, k or any other >> operational MPL forwarder parameter without some sort of >> pre-distribution/synchronization of the new parameters. It would work >>as >> you note if there are no transmission or valid seed set but if multicast >> traffic is already present using an existing seed, I would expect you >> would see issues in distribution of messages if you change the >>parameters >> while in operation. Additionally, if you use MPL to distribute the >> change with existing multicast traffic you will find some nodes do not >>get >> the new parameters (which will create other problems when you want the >>new >> parameters to take effect) >> >> Don >> >> >> >> On 10/4/13 1:07 AM, "Yusuke DOI" wrote: >> >>>Hi, >>> >>>I have a simple question: is it possible to update MPL parameters of >>>running forwarder instances? >>> >>>To maintain the system in 'good state', I expect some sort of parameter >>>tuning on MPL. Especially for the systems dynamically grows, static >>>configuration of MPL parameters will be difficult. For example, DHCPv6 >>>reconfigure request can be used to update MPL forwarder parameter. >>>However, I'm not sure it's 'safe' to update parameters (K, Imin, Imax) >>>of >>>running MPL forwarder instances. >>> >>>I think it's safe if there are no transmission / no valid seed set. Is >>>it >>>possible to update a running MPL forwarder parameter without breaking >>>current state? >>> >>>Regards, >>> >>>Yusuke >>> >>> >>>_______________________________________________ >>>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 cabo@tzi.org Sat Oct 5 09:31: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 771B821F8616; Sat, 5 Oct 2013 09:31:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.949 X-Spam-Level: X-Spam-Status: No, score=-105.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tj7XAJn+DN-u; Sat, 5 Oct 2013 09:31:21 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 1BC1521F8447; Sat, 5 Oct 2013 09:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r95GVIrR013568; Sat, 5 Oct 2013 18:31:18 +0200 (CEST) Received: from [192.168.217.105] (p54892064.dip0.t-ipconnect.de [84.137.32.100]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 58C9ECAC; Sat, 5 Oct 2013 18:31:18 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Carsten Bormann In-Reply-To: Date: Sat, 5 Oct 2013 18:31:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: lwip@ietf.org, "core@ietf.org WG" , roll WG , 6lowpan@ietf.org, "dtls-iot@ietf.org" , "6lo@ietf.org WG" <6lo@ietf.org>, IETF 6TSCH <6tsch@ietf.org> X-Mailer: Apple Mail (2.1510) Subject: [Roll] Constrained Node/Network Cluster @ IETF88, early draft version X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Oct 2013 16:31:27 -0000 A first draft version of the IETF88 agenda is out. ** THIS IS GOING TO CHANGE ** for conflict resolution,=20 so please don't make travel arrangements based on it. Here is my usual eclectic condensed agenda built from that. =20 All times are PST (UTC-0800). The Constrained Node/Network group meetings are nicely spread out over = the week. The lwig/6tisch conflict is unfortunate; this will split the audience. The oauth conflict on Monday is survivable, we'll do all = security-related CoRE work on Thursday then. Gr=FC=DFe, Carsten MONDAY, November 4, 2013 0900-1130 Morning Session I Georgia B APP appsawg Applications Area Working Group WG - - = Combined with APPAREA Regency D INT 6man IPv6 Maintenance WG 1300-1430 Afternoon Session I Regency B SEC *** dice DTLS In Constrained Environments WG 1450-1720 Afternoon Session II Georgia B APP *** core Constrained RESTful Environments WG Regency C INT intarea Internet Area Working Group WG Plaza C SEC oauth Web Authorization Protocol WG 1740-1940 Afternoon Session III Regency A APP httpbis Hypertext Transfer Protocol Bis WG Regency D OPS v6ops IPv6 Operations WG Regency C RTG rtgarea Routing Area Open Meeting TUESDAY, November 5, 2013 0900-1130 Morning Session I Georgia A APP httpbis Hypertext Transfer Protocol Bis WG 1300-1400 Afternoon Session I Plaza A APP json JavaScript Object Notation WG Regency B INT its Intelligent Transportation Systems BOF 1420-1550 Afternoon Session II Georgia B INT *** 6tisch IPv6 over the TSCH mode of IEEE = 802.15.4e WG Regency A INT *** lwig Light-Weight Implementation Guidance WG Regency B TSV tsvwg Transport Area Working Group WG 1610-1840 Afternoon Session III Regency A INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Plaza A OPS eman Energy Management WG Georgia A SEC tls Transport Layer Security WG WEDNESDAY, November 6, 2013 1300-1530 Afternoon Session I Regency C OPS v6ops IPv6 Operations WG Regency D SEC perpass Handling Pervasive Monitoring in the = IETF BOF Georgia B TSV rmcat RTP Media Congestion Avoidance = Techniques WG THURSDAY, November 7, 2013 0900-1130 Morning Session I Regency D INT homenet Home Networking WG Georgia A SEC jose Javascript Object Signing and Encryption = WG Regency C TSV tsvarea Transport Area Open Meeting 1300-1500 Afternoon Session I Regency D SEC saag Security Area Open Meeting 1520-1720 Afternoon Session II Georgia B APP *** core Constrained RESTful Environments WG FRIDAY, November 8, 2013 0900-1100 Morning Session I Regency D RTG *** roll Routing Over Low power and Lossy = networks WG Georgia B SEC httpauth Hypertext Transfer Protocol = Authentication WG Regency B TSV tsvwg Transport Area Working Group WG 1120-1220 Afternoon Session I Regency D INT dnssd Extensions for Scalable DNS Service = Discovery WG 1230-1330 Afternoon Session II Regency D INT dnssd Extensions for Scalable DNS Service = Discovery WG From yusuke.doi@toshiba.co.jp Tue Oct 8 06:06: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 67DF621E8084 for ; Tue, 8 Oct 2013 06:06:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.422 X-Spam-Level: X-Spam-Status: No, score=-7.422 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-8, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnT5wBKiW2Ll for ; Tue, 8 Oct 2013 06:06:14 -0700 (PDT) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by ietfa.amsl.com (Postfix) with ESMTP id A685B21E819C for ; Tue, 8 Oct 2013 06:05:59 -0700 (PDT) Received: from tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp ([133.199.232.103]) by imx12.toshiba.co.jp with ESMTP id r98D5vZw003483 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 8 Oct 2013 22:05:57 +0900 (JST) Received: from tsbmgw-mgw01 (localhost [127.0.0.1]) by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r98D5vpx018614 for ; Tue, 8 Oct 2013 22:05:57 +0900 Received: from localhost ([127.0.0.1]) by tsbmgw-mgw01 (JAMES SMTP Server 2.3.1) with SMTP ID 55 for ; Tue, 8 Oct 2013 22:05:57 +0900 (JST) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r98D5viB018611 for ; Tue, 8 Oct 2013 22:05:57 +0900 Received: (from root@localhost) by arc11.toshiba.co.jp id r98D5vDW025613 for roll@ietf.org; Tue, 8 Oct 2013 22:05:57 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id YAA25612; Tue, 8 Oct 2013 22:05:57 +0900 Received: from mx11.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id r98D5vs4016624 for ; Tue, 8 Oct 2013 22:05:57 +0900 (JST) Received: from spiffy21.isl.rdc.toshiba.co.jp by toshiba.co.jp id r98D5v8Z025781; Tue, 8 Oct 2013 22:05:57 +0900 (JST) Received: from [133.196.16.145] (ncg-dhcp145.isl.rdc.toshiba.co.jp [133.196.16.145]) by spiffy21.isl.rdc.toshiba.co.jp (Postfix) with ESMTPS id 1B21097D39 for ; Tue, 8 Oct 2013 22:05:57 +0900 (JST) Message-ID: <5254032E.4070604@toshiba.co.jp> Date: Tue, 08 Oct 2013 22:05:50 +0900 From: Yusuke DOI User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: roll@ietf.org Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: [Roll] Maybe stupid question: draft-ietf-roll-trickle-mcast-05 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 13:06:21 -0000 Hi, I'm trying to reproduce RPL on my local environment and got two questions. 1) Section 9.2: o This document defines an "inconsistent" transmission as receiving an MPL Data Message that has the same MPL Domain Address, seed-id value, and the M flag set, but has a sequence value less than MPL Data Message managed by the Trickle timer. My reading from section 9.3 is: each data message is handled by correspoinding buffered message information base with the same sequence number, or if not, the message is accepted in a new buffered message information base with the sequence number. What is the case of a trickle timer (with an associated buffered message information base) need to handle 'inconsistent' data message? I think I have some misunderstanding on somewhere.... 2) The draft says 'reset the timer'. I cannot find exact definition of resetting timer in RFC6206. I think let the timer start from the step 1 of RFC6206 section 4.2 will 'reset the timer'. Is it correct? Regards, Yusuke From yusuke.doi@toshiba.co.jp Thu Oct 10 03:24: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 3821521E8100 for ; Thu, 10 Oct 2013 03:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.589 X-Spam-Level: X-Spam-Status: No, score=-5.589 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJPhSTUcvkP5 for ; Thu, 10 Oct 2013 03:24:35 -0700 (PDT) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id 3037C21E80DC for ; Thu, 10 Oct 2013 03:24:34 -0700 (PDT) Received: from tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp ([133.199.200.50]) by imx2.toshiba.co.jp with ESMTP id r9AAOWJV007694 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 10 Oct 2013 19:24:32 +0900 (JST) Received: from tsbmgw-mgw02 (localhost [127.0.0.1]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r9AAOWOv016917 for ; Thu, 10 Oct 2013 19:24:32 +0900 Received: from localhost ([127.0.0.1]) by tsbmgw-mgw02 (JAMES SMTP Server 2.3.1) with SMTP ID 764 for ; Thu, 10 Oct 2013 19:24:32 +0900 (JST) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r9AAOWpP016914 for ; Thu, 10 Oct 2013 19:24:32 +0900 Received: (from root@localhost) by arc1.toshiba.co.jp id r9AAOWGm017004 for roll@ietf.org; Thu, 10 Oct 2013 19:24:32 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id VAA17003; Thu, 10 Oct 2013 19:24:32 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id r9AAOVNm000367 for ; Thu, 10 Oct 2013 19:24:32 +0900 (JST) Received: from spiffy21.isl.rdc.toshiba.co.jp by toshiba.co.jp id r9AAOVB2025418; Thu, 10 Oct 2013 19:24:31 +0900 (JST) Received: from [133.196.16.145] (ncg-dhcp145.isl.rdc.toshiba.co.jp [133.196.16.145]) by spiffy21.isl.rdc.toshiba.co.jp (Postfix) with ESMTPS id EBA6A97D53 for ; Thu, 10 Oct 2013 19:24:31 +0900 (JST) Message-ID: <5256804F.6010209@toshiba.co.jp> Date: Thu, 10 Oct 2013 19:24:15 +0900 From: Yusuke DOI User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: roll@ietf.org References: <20131010101608.30339.11540.idtracker@ietfa.amsl.com> In-Reply-To: <20131010101608.30339.11540.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20131010101608.30339.11540.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Roll] Fwd: I-D Action: draft-doi-roll-mpl-parameter-configuration-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 10:24:41 -0000 Dear roll folks, I just updated MPL parameter option draft with recent discussion about MPL parameter update. My idea behind this topic is the question: 'how can I deploy many MPL networks?' I cannot assume there is a MPL parameter that applied to all the network instances I would make. Thus, per-network configuration management would be one of the important items to make MPL networks, or wireless meshes, to be deployed in many places. I added some text to describe when to leave the MPL domain specified by this DHCP option. Any comments are welcome. Regards, Yusuke -------- Original Message -------- Subject: I-D Action: draft-doi-roll-mpl-parameter-configuration-03.txt Date: Thu, 10 Oct 2013 03:16:08 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : MPL Parameter Configuration Option for DHCPv6 Author(s) : Yusuke Doi Matthew Gillmore Filename : draft-doi-roll-mpl-parameter-configuration-03.txt Pages : 8 Date : 2013-10-10 Abstract: This draft is to define a way to configure MPL parameter via DHCPv6 option. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-doi-roll-mpl-parameter-configuration There's also a htmlized version available at: http://tools.ietf.org/html/draft-doi-roll-mpl-parameter-configuration-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-doi-roll-mpl-parameter-configuration-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From mcr@sandelman.ca Thu Oct 10 10:26: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 A24A711E8176 for ; Thu, 10 Oct 2013 10:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZ6kmzej9QAG for ; Thu, 10 Oct 2013 10:26:18 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 01B5811E812A for ; Thu, 10 Oct 2013 10:26:07 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 0C8D920266 for ; Thu, 10 Oct 2013 14:36:15 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id B2CA863B88; Thu, 10 Oct 2013 13:26:01 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 9131663AEF for ; Thu, 10 Oct 2013 13:26:01 -0400 (EDT) From: Michael Richardson To: roll@ietf.org In-Reply-To: <021401cec5da$d09fd080$71df7180$@olddog.co.uk> References: <021401cec5da$d09fd080$71df7180$@olddog.co.uk> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 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] IETF roll meeting at IETF88 cancelled X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 17:26:41 -0000 <#secure method=pgpmime mode=sign> After some significant discussion JP and I have concluded that of the many things on the ROLL agenda that we need to accelerate, few of them will benefit from the significant cost of IETF meeting time. This is not to say that we are done: merely that the time for big group meetings and presentations is temporarily not a useful thing. I hope very much to spend some one on one time with each of the active authors during IETF88. -- Michael Richardson , Sandelman Software Works IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ From iesg-secretary@ietf.org Thu Oct 10 15:17: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 8AD5C21E8164; Thu, 10 Oct 2013 15:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.415 X-Spam-Level: X-Spam-Status: No, score=-102.415 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FbZ-5n71F4la; Thu, 10 Oct 2013 15:17:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C2E0221E8145; Thu, 10 Oct 2013 15:17:13 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20131010221713.891.32620.idtracker@ietfa.amsl.com> Date: Thu, 10 Oct 2013 15:17:13 -0700 Cc: roll@ietf.org Subject: [Roll] Last Call: (Multicast Protocol for Low power and Lossy Networks (MPL)) to Proposed Standard X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: ietf@ietf.org, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 22:17:15 -0000 The IESG has received a request from the Routing Over Low power and Lossy networks WG (roll) to consider the following document: - 'Multicast Protocol for Low power and Lossy Networks (MPL)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-10-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 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 file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-roll-trickle-mcast/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-roll-trickle-mcast/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1858/ From rdroms.ietf@gmail.com Fri Oct 11 10:09: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 3B97D21E80E9; Fri, 11 Oct 2013 10:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id znMu2jV1l7H3; Fri, 11 Oct 2013 10:09:35 -0700 (PDT) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 5EA5B21E8063; Fri, 11 Oct 2013 10:09:35 -0700 (PDT) Received: by mail-qc0-f182.google.com with SMTP id n4so3245892qcx.13 for ; Fri, 11 Oct 2013 10:09:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=GSwF6PDFlaM7QEWzCmdd3b8F04nblBjhhCsRrRa1C6c=; b=uwH1VE3EqFhD5zqnEh9XW1OlukURDcAQp3cjQIVL7AWkfgqSdntWjTvDyUf8yD+A0d 97GiwN+bwufA/tHhcMW92wRV1TnO9549pEjIXPtiv/9ZKG9AEVbFpsgYHH7rPl18vHv6 kdy9McTp0LfZjxeIJkST+005KvsdG+gaIsTnj+piofzYOHsDmSYjTw4diVkqU9fm6bTL 7tlqy0O3DDNCIMmRS1YmGtAMlLUBpTfDqD7AZQ5RKkXO5QJgcpjbL0JbMhzEK8eGguLb QVmFrIobidfeRA9M4b/3l24lo4BhyCYqqM8Lt4b5vLYPIDySfBSNFJUFxRwo8/acM51s JhZg== X-Received: by 10.49.81.237 with SMTP id d13mr9066694qey.44.1381511371579; Fri, 11 Oct 2013 10:09:31 -0700 (PDT) Received: from ?IPv6:2001:420:2481:20:90c2:cb2c:7e7a:2470? ([2001:420:2481:20:90c2:cb2c:7e7a:2470]) by mx.google.com with ESMTPSA id g2sm112348856qaf.12.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 11 Oct 2013 10:09:28 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Ralph Droms In-Reply-To: <20131010221713.891.32620.idtracker@ietfa.amsl.com> Date: Fri, 11 Oct 2013 13:09:27 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20131010221713.891.32620.idtracker@ietfa.amsl.com> To: ietf@ietf.org X-Mailer: Apple Mail (2.1510) Cc: roll@ietf.org Subject: Re: [Roll] Last Call: (Multicast Protocol for Low power and Lossy Networks (MPL)) to Proposed Standard X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 17:09:36 -0000 draft-ietf-roll-trickle-mcast-05 and draft-ietf-6man-multicast-scopes-00 = are in conflict with each other. =46rom draft-ietf-roll-trickle-mcast-05: When used with MPL, Realm-Local scope is administratively defined and used to define the boundaries of multicast message dissemination by MPL. =46rom draft-ietf-6man-multicast-scopes-00: Realm-Local scope is the largest scope that is automatically configured, i.e., automatically derived from physical connectivity or other, non-multicast-related configuration. Specifically, "administratively defined" seems to me to be in direct conflict with "automatically configured".=20 I suggest fixing the problem with two updates. First, the definition of "scop 3" in an IP-over-IEEE802.15.4 needs to be published, based on this text from draft-ietf-6man-multicast-scopes-00:=20 The definition of any Realm-Local scope for a particular network technology should be published in an RFC. I suggest: When used in an IP-over-IEEE802.15.4 network, "scop 3" is defined to include all interfaces sharing a PAN ID. This text could be added to draft-ietf-roll-trickle-mcast-05, or to draft-ietf-6man-multicast-scopes-00 or published separately in yet another "world's shortest RFC". Second, draft-ietf-roll-trickle-mcast-05 should be changed to read: When used with MPL, Realm-local scope is defined according to the underlying network technology; for example, [cite the IP-over-IEEE802.15.4 definition]. As a further refinement, I suggest text be added to draft-ietf-roll-trickle-mcast-05 to the effect of: "scop 4" can also be used with MPL to cover deployments that use administratively defined scopes that cover, for example, subnets based on different underlying network technologies. - Ralph PS I originally posted about this issue to the rool WG mailing list: http://www.ietf.org/mail-archive/web/roll/current/msg08188.html. After a discussion with Kerry Lynn, I made a change to the definition of scop 3 for IEEE802.15.4.= From trac+roll@trac.tools.ietf.org Fri Oct 11 13:18: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 10D4821F9A70 for ; Fri, 11 Oct 2013 13:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zyoV2ida6+fp for ; Fri, 11 Oct 2013 13:18:03 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 2BBD321F9A6D for ; Fri, 11 Oct 2013 13:18:02 -0700 (PDT) Received: from localhost ([127.0.0.1]:50052 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VUj9n-0002UD-7v; Fri, 11 Oct 2013 22:17:55 +0200 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: johui@cisco.com, mariainesrobles@gmail.com, rdroms@cisco.com, mcr@sandelman.ca X-Trac-Project: roll Date: Fri, 11 Oct 2013 20:17:55 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/132#comment:7 Message-ID: <082.6d923b56e89f979e00a33a1bab8bbfc5@trac.tools.ietf.org> References: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org> X-Trac-Ticket-ID: 132 In-Reply-To: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: johui@cisco.com, mariainesrobles@gmail.com, rdroms@cisco.com, mcr@sandelman.ca, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local 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, 11 Oct 2013 20:18:04 -0000 #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local Comment (by mariainesrobles@gmail.com): From: Ralph Droms Date: Fri, 11 Oct 2013 13:09:27 -0400 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08220.html " draft-ietf-roll-trickle-mcast-05 and draft-ietf-6man-multicast-scopes-00 are in conflict with each other. From draft-ietf-roll-trickle-mcast-05: When used with MPL, Realm-Local scope is administratively defined and used to define the boundaries of multicast message dissemination by MPL. From draft-ietf-6man-multicast-scopes-00: Realm-Local scope is the largest scope that is automatically configured, i.e., automatically derived from physical connectivity or other, non-multicast-related configuration. Specifically, "administratively defined" seems to me to be in direct conflict with "automatically configured". I suggest fixing the problem with two updates. First, the definition of "scop 3" in an IP-over-IEEE802.15.4 needs to be published, based on this text from draft-ietf-6man-multicast-scopes-00: The definition of any Realm-Local scope for a particular network technology should be published in an RFC. I suggest: When used in an IP-over-IEEE802.15.4 network, "scop 3" is defined to include all interfaces sharing a PAN ID. This text could be added to draft-ietf-roll-trickle-mcast-05, or to draft-ietf-6man-multicast-scopes-00 or published separately in yet another "world's shortest RFC". Second, draft-ietf-roll-trickle-mcast-05 should be changed to read: When used with MPL, Realm-local scope is defined according to the underlying network technology; for example, [cite the IP-over-IEEE802.15.4 definition]. As a further refinement, I suggest text be added to draft-ietf-roll-trickle-mcast-05 to the effect of: "scop 4" can also be used with MPL to cover deployments that use administratively defined scopes that cover, for example, subnets based on different underlying network technologies. - Ralph PS I originally posted about this issue to the rool WG mailing list: http://www.ietf.org/mail-archive/web/roll/current/msg08188.html. After a discussion with Kerry Lynn, I made a change to the definition of scop 3 for IEEE802.15.4. " -- ---------------------------------------+------------------------------ Reporter: mariainesrobles@gmail.com | Owner: johui@cisco.com Type: defect | Status: reopened Priority: major | Milestone: Component: trickle-mcast | Version: Severity: In WG Last Call | Resolution: Keywords: | ---------------------------------------+------------------------------ Ticket URL: roll From cabo@tzi.org Fri Oct 11 23:56: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 68DD021E80D0; Fri, 11 Oct 2013 23:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.861 X-Spam-Level: X-Spam-Status: No, score=-105.861 tagged_above=-999 required=5 tests=[AWL=-0.212, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WhMvb2eThU+5; Fri, 11 Oct 2013 23:55:56 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 7114821F9FA5; Fri, 11 Oct 2013 23:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r9C6tjQc003442; Sat, 12 Oct 2013 08:55:45 +0200 (CEST) Received: from [192.168.217.105] (p54890CAC.dip0.t-ipconnect.de [84.137.12.172]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 87EA4D2E; Sat, 12 Oct 2013 08:55:44 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Carsten Bormann In-Reply-To: Date: Sat, 12 Oct 2013 08:55:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8529DF4C-1952-4A98-A4FC-B29806FE02B4@tzi.org> References: To: lwip@ietf.org, "core@ietf.org WG" , roll WG , 6lowpan@ietf.org, dtls-iot@ietf.org, "6lo@ietf.org WG" <6lo@ietf.org>, "6tisch@ietf.org" <6tisch@ietf.org> X-Mailer: Apple Mail (2.1510) Subject: [Roll] Constrained Node/Network Cluster @ IETF88, "final" version X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Oct 2013 06:56:07 -0000 On Oct 5, 2013, at 18:31, Carsten Bormann wrote: > A first draft version of the IETF88 agenda is out. [...] > Here is my usual eclectic condensed agenda built from that. =20 > All times are PST (UTC-0800). And here is the update based on the "final" agenda. (Which is "final" only in that it will be committed to print; it still = could change some more.) Apart from room changes, the changes are: 1) The lwig/6tisch conflict was resolved; unfortunately the moved lwig = now conflicts with perpass. 2) There will be no ROLL meeting in Vancouver. Besides the official agenda, there will be unofficial ("hallway") = meetings. I have started to collect info on a Wiki page: http://trac.tools.ietf.org/wg/core/trac/wiki/hallway88 You can edit and add meetings there using your tools login. Gr=FC=DFe, Carsten MONDAY, November 4, 2013 0900-1130 Morning Session I Georgia B APP appsawg Applications Area Working Group WG - - = Combined with APPAREA Regency D INT 6man IPv6 Maintenance WG 1300-1430 Afternoon Session I Regency B SEC *** dice DTLS In Constrained Environments WG 1450-1720 Afternoon Session II Georgia B APP *** core Constrained RESTful Environments WG Regency C INT intarea Internet Area Working Group WG Plaza C SEC oauth Web Authorization Protocol WG 1740-1940 Afternoon Session III Regency A APP httpbis Hypertext Transfer Protocol Bis WG Regency D OPS v6ops IPv6 Operations WG Regency C RTG rtgarea Routing Area Open Meeting TUESDAY, November 5, 2013 0900-1130 Morning Session I Georgia A APP httpbis Hypertext Transfer Protocol Bis WG 1300-1400 Afternoon Session I Plaza A APP json JavaScript Object Notation WG Regency B INT its Intelligent Transportation Systems BOF 1420-1550 Afternoon Session II Georgia B INT *** 6tisch IPv6 over the TSCH mode of IEEE = 802.15.4e WG Regency B TSV tsvwg Transport Area Working Group WG 1610-1840 Afternoon Session III Regency A INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Plaza A OPS eman Energy Management WG Georgia A SEC tls Transport Layer Security WG WEDNESDAY, November 6, 2013 1300-1530 Afternoon Session I Plaza C INT *** lwig Light-Weight Implementation Guidance WG Regency C OPS v6ops IPv6 Operations WG Regency D SEC perpass Handling Pervasive Monitoring in the = IETF BOF Georgia B TSV rmcat RTP Media Congestion Avoidance = Techniques WG THURSDAY, November 7, 2013 0900-1130 Morning Session I Regency D INT homenet Home Networking WG Georgia A SEC jose Javascript Object Signing and Encryption = WG Regency C TSV tsvarea Transport Area Open Meeting 1300-1500 Afternoon Session I Regency D SEC saag Security Area Open Meeting 1520-1720 Afternoon Session II Regency B APP *** core Constrained RESTful Environments WG FRIDAY, November 8, 2013 0900-1100 Morning Session I Georgia B SEC httpauth Hypertext Transfer Protocol = Authentication WG Regency B TSV tsvwg Transport Area Working Group WG 1120-1220 Afternoon Session I Regency D INT dnssdext Extensions for Scalable DNS = Service Discovery WG 1230-1330 Afternoon Session II Regency D INT dnssdext Extensions for Scalable DNS = Service Discovery WG From stokcons@xs4all.nl Mon Oct 14 01:26: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 C6A5021E8157 for ; Mon, 14 Oct 2013 01:26:50 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F9DgDrhkmUZq for ; Mon, 14 Oct 2013 01:26:45 -0700 (PDT) Received: from smtp-vbr6.xs4all.nl (smtp-vbr6.xs4all.nl [194.109.24.26]) by ietfa.amsl.com (Postfix) with ESMTP id 90C1221F9CB0 for ; Mon, 14 Oct 2013 01:26:33 -0700 (PDT) Received: from roundcube.xs4all.nl (roundcube5.xs4all.net [194.109.20.203]) by smtp-vbr6.xs4all.nl (8.13.8/8.13.8) with ESMTP id r9E8QRMY011947 for ; Mon, 14 Oct 2013 10:26:32 +0200 (CEST) (envelope-from stokcons@xs4all.nl) Received: from AMontpellier-654-1-95-199.w90-28.abo.wanadoo.fr ([90.28.134.199]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 14 Oct 2013 10:26:27 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 14 Oct 2013 10:26:27 +0200 From: peter van der Stok To: roll@ietf.org Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <5256804F.6010209@toshiba.co.jp> References: <20131010101608.30339.11540.idtracker@ietfa.amsl.com> <5256804F.6010209@toshiba.co.jp> Message-ID: X-Sender: stokcons@xs4all.nl (7DVnYlnOGo+xo8j/JGYkmN1lLUS6kbDM) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Subject: Re: [Roll] Fwd: I-D Action: draft-doi-roll-mpl-parameter-configuration-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: consultancy@vanderstok.org, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 08:26:51 -0000 Hi Yusuke, I read the draft and have two questions: 1) What is a MPL domain address? Can that be any address selected for this purpose, or is it the MC address for which an interface is enabled? 2) the function and format of the wildcard has not become clear to me. Greetings, peter Yusuke DOI schreef op 2013-10-10 12:24: > Dear roll folks, > > I just updated MPL parameter option draft with recent discussion about > MPL parameter update. > > My idea behind this topic is the question: 'how can I deploy many MPL > networks?' I cannot assume there is a MPL parameter that applied to > all the network instances I would make. Thus, per-network > configuration management would be one of the important items to make > MPL networks, or wireless meshes, to be deployed in many places. > > I added some text to describe when to leave the MPL domain specified > by this DHCP option. > > Any comments are welcome. > > Regards, > > Yusuke > > > > -------- Original Message -------- > Subject: I-D Action: draft-doi-roll-mpl-parameter-configuration-03.txt > Date: Thu, 10 Oct 2013 03:16:08 -0700 > From: internet-drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : MPL Parameter Configuration Option for DHCPv6 > Author(s) : Yusuke Doi > Matthew Gillmore > Filename : draft-doi-roll-mpl-parameter-configuration-03.txt > Pages : 8 > Date : 2013-10-10 > > Abstract: > This draft is to define a way to configure MPL parameter via DHCPv6 > option. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-doi-roll-mpl-parameter-configuration > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-doi-roll-mpl-parameter-configuration-03 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-doi-roll-mpl-parameter-configuration-03 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From robert.cragie@gridmerge.com Mon Oct 14 07:06:31 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C26A021E8176 for ; Mon, 14 Oct 2013 07:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hOVWBazWqxiM for ; Mon, 14 Oct 2013 07:06:26 -0700 (PDT) Received: from mail41.extendcp.co.uk (mail41.extendcp.co.uk [79.170.44.41]) by ietfa.amsl.com (Postfix) with ESMTP id A553821E8093 for ; Mon, 14 Oct 2013 07:06:25 -0700 (PDT) Received: from [94.117.151.69] (helo=[10.38.244.62]) by mail41.extendcp.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) id 1VVimt-0000ic-Av for roll@ietf.org; Mon, 14 Oct 2013 15:06:23 +0100 Message-ID: <525BFA61.4040104@gridmerge.com> Date: Mon, 14 Oct 2013 15:06:25 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: roll@ietf.org References: <20131010221713.891.32620.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000407060301070602050506" X-Authenticated-As: robert.cragie@gridmerge.com Subject: Re: [Roll] Last Call: (Multicast Protocol for Low power and Lossy Networks (MPL)) to Proposed Standard X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert.cragie@gridmerge.com, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 14:06:31 -0000 This is a cryptographically signed message in MIME format. --------------ms000407060301070602050506 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable I would propose adding the language to draft-ietf-roll-trickle-mcast.=20 There doesn't seem much point to doing another "world's shortest RFC". Here's an attempt at combining Ralph's text with the terminology in the=20 draft: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D OLD By default, an MPL Forwarder SHOULD participate in an MPL Domain=20 identified by the ALL_MPL_FORWARDERS multicast address with a scope=20 value of 3 (Realm-Local) [I-D.droms-6man-multicast-scopes]. When used=20 with MPL, Realm-Local scope is administratively defined and used to=20 define the boundaries of multicast message dissemination by MPL. NEW By default, an MPL Forwarder SHOULD participate in an MPL Domain where=20 the MPL Domain Address is the ALL_MPL_FORWARDERS multicast address with=20 a scope value of 3 (Realm-Local) [I-D.droms-6man-multicast-scopes]. =20 When used with MPL, Realm-Local scope is defined according to the=20 underlying network technology; for example, when used in an=20 IP-over-IEEE802.15.4 network, Realm-Local scope is defined to include=20 the set of MPL Interfaces sharing a PAN ID. An MPL Forwarder MAY participate in an MPL Domain where the MPL Domain=20 Address uses a scope value of 4 (Admin-Local)=20 [I-D.droms-6man-multicast-scopes]. When used with MPL, Admin-Local scope = can be used in deployments that use administratively defined scopes that = cover, for example, subnets based on different underlying network=20 technologies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Robert On 11/10/2013 18:09, Ralph Droms wrote: > draft-ietf-roll-trickle-mcast-05 and draft-ietf-6man-multicast-scopes-0= 0 are in conflict with each other. > > >From draft-ietf-roll-trickle-mcast-05: > > When > used with MPL, Realm-Local scope is administratively defined and us= ed > to define the boundaries of multicast message dissemination by MPL.= > > >From draft-ietf-6man-multicast-scopes-00: > > Realm-Local scope is the largest scope that is automatically > configured, i.e., automatically derived from physical > connectivity or other, non-multicast-related configuration. > > Specifically, "administratively defined" seems to me to be in direct > conflict with "automatically configured". > > I suggest fixing the problem with two updates. First, the definition > of "scop 3" in an IP-over-IEEE802.15.4 needs to be published, based on > this text from draft-ietf-6man-multicast-scopes-00: > > The definition of any Realm-Local scope for a particular network > technology should be published in an RFC. > > I suggest: > > When used in an IP-over-IEEE802.15.4 network, "scop 3" is defined > to include all interfaces sharing a PAN ID. > > This text could be added to draft-ietf-roll-trickle-mcast-05, or to > draft-ietf-6man-multicast-scopes-00 or published separately in yet > another "world's shortest RFC". > > Second, draft-ietf-roll-trickle-mcast-05 should be changed to read: > > When used with MPL, Realm-local scope is defined according to the > underlying network technology; for example, [cite the > IP-over-IEEE802.15.4 definition]. > > As a further refinement, I suggest text be added to > draft-ietf-roll-trickle-mcast-05 to the effect of: > > "scop 4" can also be used with MPL to cover deployments that use > administratively defined scopes that cover, for example, subnets > based on different underlying network technologies. > > - Ralph > > PS I originally posted about this issue to the rool WG mailing list: > http://www.ietf.org/mail-archive/web/roll/current/msg08188.html. > After a discussion with Kerry Lynn, I made a change to the definition > of scop 3 for IEEE802.15.4. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --------------ms000407060301070602050506 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 Fw0xMzEwMTQxNDA2MjVaMCMGCSqGSIb3DQEJBDEWBBRQZspTHRdrmlGDahq8NKZg7ZplozBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEFwxUNvELajLmHIeX9p072YwgbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9m MA0GCSqGSIb3DQEBAQUABIIBACcD86nO0J8bj+OQOhNpulYi81u4iCKgwDMTj+bmeKxsnYzu 3lDLJqvgCy53FCx5jP6u/FmJUQmwWMCChoLxXFoulVWb13CsHhlcsu3HP3OfuhimqTLa7UhS Wi3PviT67XTi1D+PsZaPQnX/lAPZWJzSgjtF++MDndVFaad7p5qvMeCSAwWMgjdrw2LwfcQ8 agrj1DQ/wfuapK16ypwpy9NgQMfnixThkC7e+mw9U7RlrHY4LtdfnZ4Ao9FDwzkfMtmRDBm4 D+kn/kcxlKQXQb2uYidpXuzOE0TLttcMVGp+DrNQmxi6sR89VBL1lI6HgqCFQezfKzTrSaPd /S2ax5YAAAAAAAA= --------------ms000407060301070602050506-- From trac+roll@trac.tools.ietf.org Mon Oct 14 11:18: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 043BE11E81A5 for ; Mon, 14 Oct 2013 11:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O26zehcqcTZk for ; Mon, 14 Oct 2013 11:18:02 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 745F611E8152 for ; Mon, 14 Oct 2013 11:18:02 -0700 (PDT) Received: from localhost ([127.0.0.1]:48502 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VVmiK-0005M1-HR; Mon, 14 Oct 2013 20:17:56 +0200 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: johui@cisco.com, mariainesrobles@gmail.com, rdroms@cisco.com, mcr@sandelman.ca X-Trac-Project: roll Date: Mon, 14 Oct 2013 18:17:56 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/132#comment:8 Message-ID: <082.0e60a05a9e9a33903054243f518f8668@trac.tools.ietf.org> References: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org> X-Trac-Ticket-ID: 132 In-Reply-To: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: johui@cisco.com, mariainesrobles@gmail.com, rdroms@cisco.com, mcr@sandelman.ca, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local 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: Mon, 14 Oct 2013 18:18:06 -0000 #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local Comment (by mariainesrobles@gmail.com): From: Robert Cragie Date: Mon, 14 Oct 2013 15:06:25 +0100 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08224.html "I would propose adding the language to draft-ietf-roll-trickle-mcast. There doesn't seem much point to doing another "world's shortest RFC". Here's an attempt at combining Ralph's text with the terminology in the draft: ================= OLD By default, an MPL Forwarder SHOULD participate in an MPL Domain identified by the ALL_MPL_FORWARDERS multicast address with a scope value of 3 (Realm-Local) [I-D.droms-6man-multicast-scopes]. When used with MPL, Realm-Local scope is administratively defined and used to define the boundaries of multicast message dissemination by MPL. NEW By default, an MPL Forwarder SHOULD participate in an MPL Domain where the MPL Domain Address is the ALL_MPL_FORWARDERS multicast address with a scope value of 3 (Realm-Local) [I-D.droms-6man-multicast-scopes]. When used with MPL, Realm-Local scope is defined according to the underlying network technology; for example, when used in an IP-over-IEEE802.15.4 network, Realm-Local scope is defined to include the set of MPL Interfaces sharing a PAN ID. An MPL Forwarder MAY participate in an MPL Domain where the MPL Domain Address uses a scope value of 4 (Admin-Local) [I-D.droms-6man-multicast- scopes]. When used with MPL, Admin-Local scope can be used in deployments that use administratively defined scopes that cover, for example, subnets based on different underlying network technologies. ================= Robert " -- ---------------------------------------+------------------------------ Reporter: mariainesrobles@gmail.com | Owner: johui@cisco.com Type: defect | Status: reopened Priority: major | Milestone: Component: trickle-mcast | Version: Severity: In WG Last Call | Resolution: Keywords: | ---------------------------------------+------------------------------ Ticket URL: roll From mcr@sandelman.ca Tue Oct 15 07:11:34 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3678111E8121 for ; Tue, 15 Oct 2013 07:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FTQiBR4x4qIo for ; Tue, 15 Oct 2013 07:11:29 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id E8F1711E8138 for ; Tue, 15 Oct 2013 07:11:28 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 3599C2017F; Tue, 15 Oct 2013 11:21:45 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 41CE063B88; Tue, 15 Oct 2013 10:11:13 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 2CCF463AEF; Tue, 15 Oct 2013 10:11:13 -0400 (EDT) From: Michael Richardson To: roll@ietf.org In-Reply-To: <082.0e60a05a9e9a33903054243f518f8668@trac.tools.ietf.org> References: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org> <082.0e60a05a9e9a33903054243f518f8668@trac.tools.ietf.org> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 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: mariainesrobles@gmail.com, johui@cisco.com, rdroms@cisco.com Subject: Re: [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 14:11:34 -0000 --=-=-= roll issue tracker wrote: > An MPL Forwarder MAY participate in an MPL Domain where the MPL Domain > Address uses a scope value of 4 (Admin-Local) Why do we need/want scope value 4 at all? I don't agree with using the PAN ID as the automatically configured criteria. I think that subnet is the right thing. RPL and MPL is specifically designed to cross layer-2. -- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUl1M/oqHRg3pndX9AQK+oQQA45Hlh3Lfb8esC6EIkCsiG2x8qLzE0MXb qy/V/joxLOqZDkBNWczpY5qP8J2TSDVehGScNVeyriAujdPtX1tK72Q4xIG0MdNS +SZmrsUQXwDf66pa+zH2CseyaleU/ffTIf8l3cH2+q8ncOm3OL3q8Y7ICnpdv+38 psKmN4Sc4hs= =Ew8L -----END PGP SIGNATURE----- --=-=-=-- From d.sturek@att.net Tue Oct 15 07:22: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 DB6ED21E80CC for ; Tue, 15 Oct 2013 07:22:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tHag8xs5tIxS for ; Tue, 15 Oct 2013 07:22:35 -0700 (PDT) Received: from nm13-vm5.access.bullet.mail.gq1.yahoo.com (nm13-vm5.access.bullet.mail.gq1.yahoo.com [216.39.63.131]) by ietfa.amsl.com (Postfix) with ESMTP id 99EB321E80BB for ; Tue, 15 Oct 2013 07:22:33 -0700 (PDT) Received: from [216.39.60.173] by nm13.access.bullet.mail.gq1.yahoo.com with NNFMP; 15 Oct 2013 14:22:33 -0000 Received: from [98.138.104.98] by tm9.access.bullet.mail.gq1.yahoo.com with NNFMP; 15 Oct 2013 14:22:33 -0000 Received: from [127.0.0.1] by smtp118.sbc.mail.ne1.yahoo.com with NNFMP; 15 Oct 2013 14:22:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1381846952; bh=2MndELc4z/8dq/5K/aC0gyBNaynprlJei6gPFVYcwAI=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=qufiDRCoulf8ZHoZUbVsDSgLL16weyc+FJS4lUgojp13bdTysMyUwvG0E/a3fVcRghlGMCrcvzPXmbHLSG8QQaS6vBnFUmW1iKiIGrFoKKZXd97a938RN2P6oI+KfZPm8rp++cSPVAoFa1d0httkeYGHLl7qtC+RByG0SoYwEhs= X-Yahoo-Newman-Id: 870332.50729.bm@smtp118.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: ZJwzo5oVM1lAx6q9JXEKixo_gPtQ.vG80QSt9cz1MEh6VPS dZ8qGHEHkwaUD2XtuwNN7ED5x23pUwrBRqtnt1fWeKtujpF3UVsf0gM8pOjB mIfEgSg5Wz5gEEv.QwbNBA13SL759Ub4xCU0h0gGM1ytIXWrgeQrmsobsORF hOnTyYyVwk_9gg_qw1OAF5o4ieGAIFkg9CdVovdXvCJIY3s5b9AwLR_XnB2t NVbkAkuTGtJnkFUa_._dAw5xzmQXytjAW.GoUm39d7u5uThHZQyCd4OoIL.4 3qVehgqmtGsi5_0YJgHDPghp6.v6jJCN.zJubvqUtCrE6XBOuvfDiyGRp1N_ TCsGsr7S1b30RU57Srk7BN9aE7yddv3jMFrJmaw1gNkB5KNaEtOcAQzSM7Xm sRBS_3abGTmeWtJJuv7EJrxqlX52ZVoR1fdg7WRQOtjnM.w6h9RnQ.iGlyZh sG5880Icf06tuEoS1fJkLaeNMtxQqHVZw0K07YKf74xc_tcZR38xGlHddoag LKM.4lkql8PMTZX7VsUHgvAzulpHhTf3GDhawTXMzwjwxBnH7Numf0j5k6Me 7IA-- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-Rocket-Received: from [10.0.0.4] (d.sturek@69.108.49.49 with ) by smtp118.sbc.mail.ne1.yahoo.com with SMTP; 15 Oct 2013 14:22:32 +0000 UTC User-Agent: Microsoft-MacOutlook/14.3.8.130913 Date: Tue, 15 Oct 2013 07:20:01 -0700 From: Don Sturek To: Routing Over Low power and Lossy networks Message-ID: Thread-Topic: [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local In-Reply-To: <13450.1381846273@sandelman.ca> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: mariainesrobles@gmail.com, johui@cisco.com, rdroms@cisco.com Subject: Re: [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 14:22:42 -0000 HI Michael, At some point, I think it would be interesting to see multicast forwarding rules in a mesh network where flooding is not used. I would see that case as the example of where scope 4 would be used. I know that a lot of work is needed in defining the rules for forwarding when flooding is not used but in a large mesh network, there would be a lot of benefit to such a feature. Don On 10/15/13 7:11 AM, "Michael Richardson" wrote: > > >roll issue tracker wrote: > > An MPL Forwarder MAY participate in an MPL Domain where the MPL >Domain > > Address uses a scope value of 4 (Admin-Local) > >Why do we need/want scope value 4 at all? > >I don't agree with using the PAN ID as the automatically configured >criteria. I think that subnet is the right thing. RPL and MPL >is specifically designed to cross layer-2. > >-- >Michael Richardson , Sandelman Software Works >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll From rdroms@cisco.com Tue Oct 15 07:58: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 BE57C21E81D8 for ; Tue, 15 Oct 2013 07:58:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sjZGY73LtbRM for ; Tue, 15 Oct 2013 07:58:00 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 3A16B21F9EAD for ; Tue, 15 Oct 2013 07:57:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1689; q=dns/txt; s=iport; t=1381849069; x=1383058669; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=CwZhcyr2h5OVd4P6Dd7z1CC3Z+4lvoUu2C/stUQOsik=; b=VNFLQS1MJigT6Spxhvlzas2l/hjjFsa+86AnHNLUUHr8mEdSqQ636CmB lcF2sn6NAeZ8+hr13Re4qcFi6KupaFrcHJFx5BR2kab0oZC96sYcB6sIN ubobsPUpp9mwMJBF9C15O6hyNKcwpeMVmCwmsgN2BIZvALJaDehV9t+Q5 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFABBXXVKtJV2d/2dsb2JhbABagwc4UsIlgSEWdIIlAQEBAwEBAQE3NAsQAgEIGAoUECcLJQIEDgUIh3gGDL0rBI8XAjEHgx+BBgOqBoFmgT6CKQ X-IronPort-AV: E=Sophos;i="4.93,499,1378857600"; d="scan'208";a="272336443" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP; 15 Oct 2013 14:57:49 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r9FEvmLh012270 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Oct 2013 14:57:48 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.229]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Tue, 15 Oct 2013 09:57:48 -0500 From: "Ralph Droms (rdroms)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local Thread-Index: AQHOyQm0EEMO5JOK1Ei62VsuFuvrVZn2Io2AgAANA4A= Date: Tue, 15 Oct 2013 14:57:47 +0000 Message-ID: <4518F39EB578034D8C99A9B7776CDBA301BE0790@xmb-aln-x04.cisco.com> References: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org> <082.0e60a05a9e9a33903054243f518f8668@trac.tools.ietf.org> <13450.1381846273@sandelman.ca> In-Reply-To: <13450.1381846273@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.155.136.73] Content-Type: text/plain; charset="us-ascii" Content-ID: <85DC2056E021864F8920B5BE6982AAC7@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mariainesrobles@gmail.com" , "Jonathan Hui \(johui\)" Subject: Re: [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 14:58:06 -0000 On Oct 15, 2013, at 7:11 AM 10/15/13, Michael Richardson wrote: >=20 > roll issue tracker wrote: >> An MPL Forwarder MAY participate in an MPL Domain where the MPL Domain >> Address uses a scope value of 4 (Admin-Local) >=20 > Why do we need/want scope value 4 at all? There apparently was interest in an administratively defined MP domain. sc= op 4 is available for that kind of domain. If there is no interest, scop 4= need not be added. >=20 > I don't agree with using the PAN ID as the automatically configured > criteria. I think that subnet is the right thing. RPL and MPL > is specifically designed to cross layer-2. What is your definition for "subnet" that is compatible with the definition= from draft-ietf-6man-multicast-scopes: automatically configured, i.e., automatically derived from physical connectivity or other, non-multicast-related configuration. I chose PAN ID as a way of identifying a "subnet" within a distribution of = MPL forwarders that might be within radio range of each other but should be= in separate MPL domains. For example, suppose I have MPL forwarders in my= flat and you have MPL forwarders in your flat. How do my forwarders know = they belong to the MPL domain in my flat while your forwarders know they be= long to the MPL domain in your flat. PAN ID would be one way to make that = differentation. - Ralph >=20 > -- > Michael Richardson , Sandelman Software Works > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From mcr@sandelman.ca Tue Oct 15 08:59: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 9D87821E81B9 for ; Tue, 15 Oct 2013 08:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.458 X-Spam-Level: X-Spam-Status: No, score=-2.458 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N0JL4emUvcvA for ; Tue, 15 Oct 2013 08:59:22 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 8450A11E813D for ; Tue, 15 Oct 2013 08:59:22 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 2B9BF2017F; Tue, 15 Oct 2013 13:09:45 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id DBA6E63B88; Tue, 15 Oct 2013 11:59:12 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id C9C0C63AEF; Tue, 15 Oct 2013 11:59:12 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: References: X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 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: mariainesrobles@gmail.com, johui@cisco.com, rdroms@cisco.com Subject: Re: [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 15:59:27 -0000 --=-=-= Don Sturek wrote: > At some point, I think it would be interesting to see multicast > forwarding rules in a mesh network where flooding is not used. I would > see that case as the example of where scope 4 would be used. okay, so when we write a new protocol, we can specify this. Why have the code there to support scope-4 when there is no other behaviour? > I know that a lot of work is needed in defining the rules for > forwarding when flooding is not used but in a large mesh network, there > would be a lot of benefit to such a feature. Do you agree with me about PANID vs Subnet or not? -- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUl1mToqHRg3pndX9AQJqtwQAs2x5e1pOCM7YuX9//0bBawkL+u3x0S0h 5Ylzl15+ixX73pNaHargPLxwfHEWNUOK6fZDBbQ/ApbA+pqBB3Z4TSj7sz/QJt4R EsYR7NJaAKHHS4pq5OF4jrc2AfIatAgo0P2t/O9P0Tx2r87Pj3QZvW8IkXFVmKgJ 3r0+DVSUKQI= =viAy -----END PGP SIGNATURE----- --=-=-=-- From Daniel.Popa@itron.com Tue Oct 15 09:02: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 0B7D421E81BB for ; Tue, 15 Oct 2013 09:02:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M3QEqUmL536p for ; Tue, 15 Oct 2013 09:02:07 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0157.outbound.protection.outlook.com [207.46.163.157]) by ietfa.amsl.com (Postfix) with ESMTP id 3B47A21E81CA for ; Tue, 15 Oct 2013 09:02:01 -0700 (PDT) Received: from CO1PR04MB346.namprd04.prod.outlook.com (10.141.52.25) by CO1PR04MB345.namprd04.prod.outlook.com (10.141.52.20) with Microsoft SMTP Server (TLS) id 15.0.785.10; Tue, 15 Oct 2013 16:01:58 +0000 Received: from CO1PR04MB346.namprd04.prod.outlook.com ([169.254.1.219]) by CO1PR04MB346.namprd04.prod.outlook.com ([169.254.1.219]) with mapi id 15.00.0785.001; Tue, 15 Oct 2013 16:01:57 +0000 From: "Popa, Daniel" To: Michael Richardson Thread-Topic: AMI applicability: storing/non-storing. Thread-Index: AQHOk6aA+bKz6Eg6Tk61X66o+hJEnZn2Vfow Date: Tue, 15 Oct 2013 16:01:57 +0000 Message-ID: References: <23764.1375904475@sandelman.ca> In-Reply-To: <23764.1375904475@sandelman.ca> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [109.2.132.2] x-forefront-prvs: 00003DBFE7 x-forefront-antispam-report: SFV:NSPM; SFS:(55784002)(51444003)(189002)(199002)(81816001)(47976001)(50986001)(81542001)(74706001)(81342001)(54316002)(74366001)(49866001)(74876001)(47736001)(56816003)(77096001)(76796001)(76786001)(76576001)(69226001)(59766001)(77982001)(85306002)(80022001)(66066001)(74502001)(83072001)(31966008)(54356001)(47446002)(74662001)(51856001)(33646001)(53806001)(83322001)(19580395003)(15202345003)(19580405001)(76482001)(81686001)(4396001)(56776001)(46102001)(15975445006)(80976001)(65816001)(74316001)(63696002)(79102001)(85806002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR04MB345; H:CO1PR04MB346.namprd04.prod.outlook.com; CLIP:109.2.132.2; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: itron.com Cc: "roll@ietf.org" Subject: Re: [Roll] AMI applicability: storing/non-storing. X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 16:02:12 -0000 Hi Michael, all,=20 Sorry for delayed answer... I will do my best to get much shorter the respo= nse time for future conversations... PLS see reply within your lines. Regards, Daniel -----Message d'origine----- De=A0: mcr@sandelman.ca [mailto:mcr@sandelman.ca] De la part de Michael Ric= hardson Envoy=E9=A0: mercredi 7 ao=FBt 2013 21:41 =C0=A0: roll@ietf.org Cc=A0: draft-ietf-roll-applicability-ami@tools.ietf.org Objet=A0: AMI applicability: storing/non-storing. I read draft-ietf-roll-applicability-ami-07 on Monday,and I am so pleased t= o see this work resume. I see that there has been some hard thinking for c= ertain aspects, and I hope that this process will continue. Some comments though on storing/non-storing mode. You write: > As a result, different AMI deployments can vary significantly in > terms of memory size, computation power and communication > capabilities. For this reason, the use of RPL storing or non-storing > mode SHOULD be deployment specific. When meters are memory a manufacturer that wishes to make meters for more than one market/RFP woul= d need to put in enough memory for the worst case storing situation. So th= e advice here is empty. And how many routes is enough? The restof section 9.1.2 says, "if you have memory use storing mode, if you= don't, then don't". DP> The assumption is correct but in practice the size of the memory to put= into a device is a trade-off between several constraints: e.g., cost, mech= anics, power consumption, performance, .. the markets/RFPs come with differ= ent requirements and constraints, and there are many markets where the glob= al cost of a device can severely constraint the capabilities of a device. I= n such cases, over-dimensioning the memory is not always a suitable solutio= n. Also, although memory size increased considerably in AMI devices over th= e past few years, we should take into account that this memory is shared wi= th other applications. Routing/RPL is one of the key pieces of the meter ec= osystem , but when it comes to sharing memory resources we cannot always af= ford to give routing/RPL the highest slice of this memory.=20 DP> It is not easy to answer the questions "how many routes is enough?". Th= is is because it depends on metering device HW architecture, on metering de= vice SW/FW architecture, on how efficiently one implements its FW/SW, on wh= at type of OS is used, on how many other applications and functionalities a= re sharing the same memory resources, and so on. As an example, although an= AMI platform for US market is sharing some in common with an AMI platform= for EU market, their requirements/constraints, functionalities and applica= tions can be significantly different. > route repair latency. However, in high-density environments, storing > routes can be challenging because some nodes may have to maintain > routing information for a large number of descendents. When the > routing table size becomes challenging, it is RECOMMENDED that nodes > perform route aggregation, similarly to the approach taken by other > routing protocols, although the required set of mechanism may differ. I'm really unclear what this means. What mechanism are you referring? Route aggregation in BGP4 is accomplished by applocating aggregatable addresses. Are you suggesting that all the meters in a high-density environment should be numbered in a /64 different from the meters in the ne= xt building? How would this be configured? What device would do this? DP> Because - as you highlighted as well - route aggregation in a mesh netw= ork is not a trivial thing we only make recommendation to implementers to c= onsider route aggregation as a potential solution to the potential issue of= routing table scalability when RPL with storing mode of operation is used = in high-density environments. It seems to me that the AMI community would be interested in the hydrid mod= es which have been proposed, and further R&D in that area would be waranted= . DP> By hybrid mode you mean mixing RPL storing and non-storing modes in the= "same" DODAG, right ? I believe that hybrid mode of operation deserve at = least some discussions/brainstorming.. This mode of operation may - as you = say - can help dealing with scalability issues as well as with supporting a= mix of devices with different constraints (e.g., a mix of AC powered devic= es and battery operated devices) (The lack of a compromise between storing and non-storing is why I felt tha= t would perhaps be multiple applicability statements for urban and suburban= /rural environments, and perhaps also for battery operated environments. Y= our 1.3 seems to copy my text exactly, so please edit it. I would suggest that you write a document that says something like: this applies to metering applications where the number of possible parent= s is > X. (possible parents controls for differences in radio power, propogation, and= physical density of meters. Or you could be specific about radio type, and= just list meter density directly) DP> Good catch. Section 1.3 will be updated accordingly for the next review= .=20 DP> I think that the only mode of operation that can potentially suffer fro= m routing table scalability issues is RPL storing mode. Routing table sizes= at nodes in RPL non storing mode (except the DODAG root) is not signific= antly affected by the density of nodes. DP> It will be difficult to define the right value for "X" (i.e., number of= parents >3), because - as stated previously - the potential routing table = scalability issues for RPL storing mode is tightly related to specific mark= ets and implementations. Alternatively, we can eventually narrow down this = applicability statement document to only "RPL non-storing mode of operation= ", if this may help. DP> I tend to agree with you that battery operated nodes are different beas= ts and do not have the same constraints as AC powered devices. We discussed= among the authors to eventually narrow down the scope of this applicabilit= y statement to only AC powered devices. We can provide this as an update on= the next revision of the document, based on feedback we get from the group= . -- Michael Richardson , Sandelman Software Works IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ From mcr@sandelman.ca Tue Oct 15 09:08:48 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C60421E81F9 for ; Tue, 15 Oct 2013 09:08:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DjsIq5tO6ifO for ; Tue, 15 Oct 2013 09:08:43 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id A94C921E81E3 for ; Tue, 15 Oct 2013 09:08:23 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 0F05B2017F; Tue, 15 Oct 2013 13:18:38 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id B6FC963B88; Tue, 15 Oct 2013 12:08:05 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id A480C63AEF; Tue, 15 Oct 2013 12:08:05 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: <4518F39EB578034D8C99A9B7776CDBA301BE0790@xmb-aln-x04.cisco.com> References: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org> <082.0e60a05a9e9a33903054243f518f8668@trac.tools.ietf.org> <13450.1381846273@sandelman.ca> <4518F39EB578034D8C99A9B7776CDBA301BE0790@xmb-aln-x04.cisco.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 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: "mariainesrobles@gmail.com" , "Jonathan Hui \(johui\)" Subject: Re: [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 16:08:48 -0000 --=-=-= Ralph Droms (rdroms) wrote: > What is your definition for "subnet" that is compatible with the > definition from draft-ietf-6man-multicast-scopes: > automatically configured, i.e., automatically derived from physical > connectivity or other, non-multicast-related configuration. > I chose PAN ID as a way of identifying a "subnet" within a distribution > of MPL forwarders that might be within radio range of each other but > should be in separate MPL domains. For example, suppose I have MPL > forwarders in my flat and you have MPL forwarders in your flat. How do > my forwarders know they belong to the MPL domain in my flat while your > forwarders know they belong to the MPL domain in your flat. PAN ID > would be one way to make that differentation. PANID is too restrictive in my opinion. I may well have a radio networks on the first floor of my (penthouse) flat, and another radio network on the second floor of my flat, connected by any number of wired (ethernet) or higher-powered wireless (wifi) layer-2 technologies. There are good radio reasons to use different PANIDs, because the isolation might be inconsistent. The devices which connect my two floors know they are supposed to do that at the RPL level, and so subnet is the right thing. This is where we need to be prescriptive. -- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUl1oY4qHRg3pndX9AQKfZQQAulILpmM0KN98K/qTvHxdVtOxXvy/Soqv h2EF12CacE1+7/o6I+Wu8iBYnDZd3LSm0HrdiCtuhde4uScmZrg4or4PCg1qV4yv A7QrS6hXKVOmoTYnISnqyh3P38b+bF3DTFQ4yXrTnSNfwhdaI6vXzDdFl1NiSPYo NWJYS+W4cs4= =bK1r -----END PGP SIGNATURE----- --=-=-=-- From robert.cragie@gridmerge.com Tue Oct 15 09:15:39 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8F6611E81E4 for ; Tue, 15 Oct 2013 09:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nfk6KzEM09V9 for ; Tue, 15 Oct 2013 09:15:35 -0700 (PDT) Received: from mail41.extendcp.co.uk (mail41.extendcp.co.uk [79.170.44.41]) by ietfa.amsl.com (Postfix) with ESMTP id 95CB521F9E43 for ; Tue, 15 Oct 2013 09:14:43 -0700 (PDT) Received: from [94.116.219.190] (helo=[10.38.244.62]) by mail41.extendcp.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) id 1VW7Gc-0006Xn-GT for roll@ietf.org; Tue, 15 Oct 2013 17:14:42 +0100 Message-ID: <525D69F4.4030204@gridmerge.com> Date: Tue, 15 Oct 2013 17:14:44 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: roll@ietf.org References: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org> <082.0e60a05a9e9a33903054243f518f8668@trac.tools.ietf.org> <13450.1381846273@sandelman.ca> <4518F39EB578034D8C99A9B7776CDBA301BE0790@xmb-aln-x04.cisco.com> <5697.1381853285@sandelman.ca> In-Reply-To: <5697.1381853285@sandelman.ca> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070908040009020800020000" X-Authenticated-As: robert.cragie@gridmerge.com Subject: Re: [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert.cragie@gridmerge.com, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 16:15:40 -0000 This is a cryptographically signed message in MIME format. --------------ms070908040009020800020000 Content-Type: multipart/alternative; boundary="------------070602070102000901020901" This is a multi-part message in MIME format. --------------070602070102000901020901 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Yes, but your scenario is surely one where it cannot be automatically=20 configured and therefore scope 4 is surely more applicable? Robert On 15/10/2013 17:08, Michael Richardson wrote: > Ralph Droms (rdroms) wrote: > > What is your definition for "subnet" that is compatible with the= > > definition from draft-ietf-6man-multicast-scopes: > > > automatically configured, i.e., automatically derived from phy= sical > > connectivity or other, non-multicast-related configuration. > > > I chose PAN ID as a way of identifying a "subnet" within a distr= ibution > > of MPL forwarders that might be within radio range of each other= but > > should be in separate MPL domains. For example, suppose I have = MPL > > forwarders in my flat and you have MPL forwarders in your flat. = How do > > my forwarders know they belong to the MPL domain in my flat whil= e your > > forwarders know they belong to the MPL domain in your flat. PAN= ID > > would be one way to make that differentation. > > PANID is too restrictive in my opinion. > > I may well have a radio networks on the first floor of my (penthouse) f= lat, > and another radio network on the second floor of my flat, connected by = any > number of wired (ethernet) or higher-powered wireless (wifi) layer-2 > technologies. There are good radio reasons to use different PANIDs, > because the isolation might be inconsistent. The devices which connect= my > two floors know they are supposed to do that at the RPL level, and so > subnet is the right thing. > > This is where we need to be prescriptive. > > -- > Michael Richardson , Sandelman Software Works > > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --------------070602070102000901020901 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes, but your scenario is surely one where it cannot be automatically configured and therefore scope 4 is surely more applicable?

Robert

On 15/10/2013 17:08, Michael Richardso= n wrote:
Ralph Droms (rdroms) <rdroms@cisco.com> wrote:
    > What is your definition for "subnet" that is compatible with the=

    > definition from draft-ietf-6man-multicast-scopes:

    >   automatically configured, i.e., automatically derived from phy=
sical
    > connectivity or other, non-multicast-related configuration.

    > I chose PAN ID as a way of identifying a "subnet" within a distr=
ibution
    > of MPL forwarders that might be within radio range of each other=
 but
    > should be in separate MPL domains.  For example, suppose I have =
MPL
    > forwarders in my flat and you have MPL forwarders in your flat. =
 How do
    > my forwarders know they belong to the MPL domain in my flat whil=
e your
    > forwarders know they belong to the MPL domain in your flat.  PAN=
 ID
    > would be one way to make that differentation.

PANID is too restrictive in my opinion.

I may well have a radio networks on the first floor of my (penthouse) fla=
t,
and another radio network on the second floor of my flat, connected by an=
y
number of wired (ethernet) or higher-powered wireless (wifi) layer-2
technologies.  There are good radio reasons to use different PANIDs,
because the isolation might be inconsistent.  The devices which connect m=
y
two floors know they are supposed to do that at the RPL level, and so
subnet is the right thing.

This is where we need to be prescriptive.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software =
Works





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

--------------070602070102000901020901-- --------------ms070908040009020800020000 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 Fw0xMzEwMTUxNjE0NDRaMCMGCSqGSIb3DQEJBDEWBBT3vtDv26oe//w1Gj9Cht37jdTi6zBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEFwxUNvELajLmHIeX9p072YwgbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9m MA0GCSqGSIb3DQEBAQUABIIBAI6pL87j0nc+sTkZf5GvTV6a6fLTCbQfva0IFrb/x4wExBeq AIYIHMdHd6un1pgNg18OQFhWl3MenSham3Xj6mIy518QmASADuidtzorsj7jOjg3KsYmU04c vO4SYC3Zm+81aq4S3axSrWx58390CCaj/Txd69G2Yd/17Z5Eu4+ky0exAmdHIhrN2kc5qN16 eA0IZUSq0LXUVVlVCaFUFYf3p9Y/Fmd37vuPwDjM41BJUekg98D7MndFUt39gw3GtNPD3ZbQ Qa8npboO1278x09oFBbTYdxaH7Hr+wR7XmDJLUSDne+hmwFTIWhDof88/9TxbMnYYOfC9YDL 8rN6mWgAAAAAAAA= --------------ms070908040009020800020000-- From d.sturek@att.net Tue Oct 15 09:22: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 DA5B111E81EA for ; Tue, 15 Oct 2013 09:22:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fq1K7T8Tkral for ; Tue, 15 Oct 2013 09:22:17 -0700 (PDT) Received: from nm18-vm3.access.bullet.mail.gq1.yahoo.com (nm18-vm3.access.bullet.mail.gq1.yahoo.com [216.39.63.76]) by ietfa.amsl.com (Postfix) with ESMTP id 09A1921E80C0 for ; Tue, 15 Oct 2013 09:21:52 -0700 (PDT) Received: from [216.39.60.170] by nm18.access.bullet.mail.gq1.yahoo.com with NNFMP; 15 Oct 2013 16:21:51 -0000 Received: from [67.195.23.144] by tm6.access.bullet.mail.gq1.yahoo.com with NNFMP; 15 Oct 2013 16:21:51 -0000 Received: from [127.0.0.1] by smtp116.sbc.mail.gq1.yahoo.com with NNFMP; 15 Oct 2013 16:21:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1381854111; bh=fBxtEKUnyABJm4CQEJuw93FSv1yifeufq2q/YhLRasc=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=Aa8IMunCiK6NCXt3zAtVO542otMZa2qLG//KZhMaRYn8iJ2kK6AxOG3c7ct6fR/XbJHoTSMyJGTE8xrsoqRdkynsRwqd689aNxZtEktVc7sVikjqY9UH+/wUNM4D/rvZD28OFnv0CHnzwkSPB9uxf+5Q8e6sKC8BB8sBgnDoCBc= X-Yahoo-Newman-Id: 268646.78680.bm@smtp116.sbc.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: paGGQpIVM1n7mptZ8lJI00T5eJ2dR9xBH310AB1x9nIpA.1 GhFzLEjz27LQsvkyhj9B7cVUXeOjwsc8mXFj8ytn5V3SiR8YzcOY.TWLU43e ZIxr1.6qW8QqIKh4mocoAD81Jb4mMMZ6t_zcrL3wNOAhsGw4XiTQcTzlje1j 1mYperooGG270ljTtY7DZSPKOwafApQeopa93HI5NFE2cR6TCFSRSOlxIvSR flf0vYR2bsny9AJNIWMhMQKVbmHVIihpYGUgUSO0XpP3m8jm2a.7IN6Pqeeb Lo04EqpCuFvVI.CGu4.v3c0bA58YYa0GK5BdE8_abwEl71M0nnaysEfSUCr7 29s.IxTk2lA4w8_y685t1qGlhgz6AibTAAMfxzaxAVpKJvIQt4CbO0qO7N5P fLc7uYNndfmWrAWofxbS0eR8sBzydnCQ61fH3xsUWRbOE7VUIgNl8nxAnq36 tNWU7QQFkPVwcCgj5Fdqu97PbcaG30NjPzvMD5LhjvAzPu47jbKdU54gf3a7 i9DrXweUDf48_q2evn3wNVJBrtMvynBDLRZqZP38rRQKXJyWAA5VuiZTX X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-Rocket-Received: from [10.1.1.129] (d.sturek@66.27.60.174 with ) by smtp116.sbc.mail.gq1.yahoo.com with SMTP; 15 Oct 2013 16:21:51 +0000 UTC User-Agent: Microsoft-MacOutlook/14.3.8.130913 Date: Tue, 15 Oct 2013 09:21:40 -0700 From: Don Sturek To: Routing Over Low power and Lossy networks Message-ID: Thread-Topic: [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local In-Reply-To: <5697.1381853285@sandelman.ca> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "mariainesrobles@gmail.com" , "Jonathan Hui \(johui\)" Subject: Re: [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 16:22:23 -0000 Hi Michael, I don't see how scope 3 (automatically configured) fits with your example. There would need to be some administrative configuration to let these devices know that the two PANs you have should be linked in one domain. Don On 10/15/13 9:08 AM, "Michael Richardson" wrote: > > >Ralph Droms (rdroms) wrote: > > What is your definition for "subnet" that is compatible with the > > definition from draft-ietf-6man-multicast-scopes: > > > automatically configured, i.e., automatically derived from >physical > > connectivity or other, non-multicast-related configuration. > > > I chose PAN ID as a way of identifying a "subnet" within a >distribution > > of MPL forwarders that might be within radio range of each other but > > should be in separate MPL domains. For example, suppose I have MPL > > forwarders in my flat and you have MPL forwarders in your flat. >How do > > my forwarders know they belong to the MPL domain in my flat while >your > > forwarders know they belong to the MPL domain in your flat. PAN ID > > would be one way to make that differentation. > >PANID is too restrictive in my opinion. > >I may well have a radio networks on the first floor of my (penthouse) >flat, >and another radio network on the second floor of my flat, connected by any >number of wired (ethernet) or higher-powered wireless (wifi) layer-2 >technologies. There are good radio reasons to use different PANIDs, >because the isolation might be inconsistent. The devices which connect my >two floors know they are supposed to do that at the RPL level, and so >subnet is the right thing. > >This is where we need to be prescriptive. > >-- >Michael Richardson , Sandelman Software Works > > >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll From rdroms.ietf@gmail.com Tue Oct 15 09:22:57 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A26A911E81D5 for ; Tue, 15 Oct 2013 09:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PHOMlViaClP7 for ; Tue, 15 Oct 2013 09:22:55 -0700 (PDT) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 5E0CB21E80D1 for ; Tue, 15 Oct 2013 09:22:43 -0700 (PDT) Received: by mail-pd0-f169.google.com with SMTP id r10so9118408pdi.14 for ; Tue, 15 Oct 2013 09:22:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=szzN09giALG7/FD6LiswFp1AI5aKHqjwF2PUwB4ZHoM=; b=HOLleNyA6FeW5Jy2w1/qY44l9rEC/LO60Q0lJtL63iBConFLNiyye2uJL7ZXRbO8wh kTJjYNdfHoZwl9w2fON61TOb48HEYSMhXiXRFMONg9leHFOLGwTVZzZ+tvM+jGZsB/KG VzKdBPbdvQWDuEs0voEBQhFeFrXKevRlQusZ7AEZe4kxrDbpuMinXEAOamxSd6B0NaJ8 MezC9TqHgXmosQatV/bNCwBDyNVnpL4J3/nz6Iq+vJ0tF/9qZ2i+5JOhmXCWSJO0nEHA U9QPoOYnHBXw+bPrUUKnjjmglGiFy8Vx1X2TMMrpz81Zt9z7AzmpxEzfiVkrWjsp58Um e4mg== X-Received: by 10.68.217.167 with SMTP id oz7mr2268035pbc.188.1381854163093; Tue, 15 Oct 2013 09:22:43 -0700 (PDT) Received: from dhcp-10-155-136-73.cisco.com (128-107-239-234.cisco.com. [128.107.239.234]) by mx.google.com with ESMTPSA id j9sm100080072paj.18.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Oct 2013 09:22:40 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Ralph Droms In-Reply-To: <5697.1381853285@sandelman.ca> Date: Tue, 15 Oct 2013 09:22:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4B4C7F25-EF5B-4B54-8A9D-F639A98052E4@gmail.com> References: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org> <082.0e60a05a9e9a33903054243f518f8668@trac.tools.ietf.org> <13450.1381846273@sandelman.ca> <4518F39EB578034D8C99A9B7776CDBA301BE0790@xmb-aln-x04.cisco.com> <5697.1381853285@sandelman.ca> To: Routing Over Low power and Lossy networks X-Mailer: Apple Mail (2.1510) Cc: mariainesrobles@gmail.com, "Jonathan Hui \(johui\)" Subject: Re: [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 16:22:57 -0000 On Oct 15, 2013, at 9:08 AM 10/15/13, Michael Richardson = wrote: >=20 > Ralph Droms (rdroms) wrote: >> What is your definition for "subnet" that is compatible with the >> definition from draft-ietf-6man-multicast-scopes: >=20 >> automatically configured, i.e., automatically derived from physical >> connectivity or other, non-multicast-related configuration. >=20 >> I chose PAN ID as a way of identifying a "subnet" within a = distribution >> of MPL forwarders that might be within radio range of each other but >> should be in separate MPL domains. For example, suppose I have MPL >> forwarders in my flat and you have MPL forwarders in your flat. How = do >> my forwarders know they belong to the MPL domain in my flat while = your >> forwarders know they belong to the MPL domain in your flat. PAN ID >> would be one way to make that differentation. >=20 > PANID is too restrictive in my opinion. >=20 > I may well have a radio networks on the first floor of my (penthouse) = flat, > and another radio network on the second floor of my flat, connected by = any > number of wired (ethernet) or higher-powered wireless (wifi) layer-2 > technologies. There are good radio reasons to use different PANIDs, > because the isolation might be inconsistent. The devices which = connect my > two floors know they are supposed to do that at the RPL level, and so > subnet is the right thing. >=20 > This is where we need to be prescriptive. If I'm understanding your example correctly, I would say that the MPL = domain you describe would use scop 4, administratively defined to cover = the various radio domains. I might also consider using scop 3 to simply forward across the mesh = networks, with a broader scope and traditional multicast protocols to = tie together the MPL domains with other links in the home network. Suppose an application uses multicast address FF08::DB8:0:1234 in a = network with RTR1 connected to MESH1 and some other links, and RTR2 = connected to MESH2 and some other links. RTR1 and RTR2 share at least = on link. One architecture would be to use traditional multicast protocols to = connect the various links to which RTR1 and RTR2 are connected. RTR1 = and RTR2 then act as MPL encapsulators for MESH1 and MESH2. Traffic on = MESH1 looks like (hope the summarization is understandable) FF03:0:0:0:0:0:0:FC | MPL header | FF08::DB8:0:1234 | application = payload - Ralph > -- > Michael Richardson , Sandelman Software Works >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From d.sturek@att.net Tue Oct 15 09:35:44 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 2AE0811E819E for ; Tue, 15 Oct 2013 09:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iFudnu97zRP3 for ; Tue, 15 Oct 2013 09:35:39 -0700 (PDT) Received: from nm1-vm5.access.bullet.mail.gq1.yahoo.com (nm1-vm5.access.bullet.mail.gq1.yahoo.com [216.39.63.119]) by ietfa.amsl.com (Postfix) with ESMTP id 9E0A521E81B0 for ; Tue, 15 Oct 2013 09:35:15 -0700 (PDT) Received: from [216.39.60.165] by nm1.access.bullet.mail.gq1.yahoo.com with NNFMP; 15 Oct 2013 16:34:02 -0000 Received: from [67.195.22.118] by tm1.access.bullet.mail.gq1.yahoo.com with NNFMP; 15 Oct 2013 16:34:02 -0000 Received: from [127.0.0.1] by smtp113.sbc.mail.gq1.yahoo.com with NNFMP; 15 Oct 2013 16:34:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1381854842; bh=7OyvWHCmJdNDicTnJgKzeHczy6Ta2gyz535wKkzQ590=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=WAKoplw3yhybgXkXyfCQ517f9aDF9fCtjWf5Sf8ayPhsE6aEpLXYvfDPE8u730V+hXINSqhcnvGQqXnGuQ2i2+sdN4SWNXory9qYNTUzVijO24t+UdHxT2Mo5cD/mWoiv6IvIjjWF4c9sJwrkOrriK5eacHzMv6TFlqbrmcmIAY= X-Yahoo-Newman-Id: 380136.61539.bm@smtp113.sbc.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: vLIbOEkVM1nyFbtE8aKYlKhV3JDqYtgNfcZzdlg5YsnK_7r WSdjEmluYSAsB13wPHOnYg_K5.yrzMZFnCEKu0xNxdm6GBy4TqM1qvwwUuix vo6b.PrZXs58YWENmR9mR.xxHOqz_xNIRNndmFoCCcU2n3FzqEv6jBFWU4wq Q_rYPzGSHd5A7Ux82ZCP0WwIXzZvJptvMnmgJa3wKSVvGnX00b8vFzVI386R lex8I5v3Q6u9v2Om2T0zyD_7dVsrvFqo9iJNp0MsZAlctEGB3Y6zvpQ_BLnB Uhvjge5LyPIN2hIg4Eca5.WT60N1TJXd8NmiAISpjceifLSB0H3Lpd3MB4v6 YDt.140Zcvkd5cMgVVDe.8wX8RLo1iiNbT9WRYISAV8zRJ6PHxrEeaQpvpDM _xQwWteWj1Ew8LXYeySYfTj_wHS4tlYRVlZK2EqpNB0ZeBER34i.Cu7QGOGx VfMj.CxSurkv3lr8xDdh29kwb2TEzlM.uW7pjMMhx0d_.BIMUf64AdnPNKwn BG5JBMgxgRWI8sPZ9EWVxxVZU1yuyFUwjcgDwR5aXBd.6Lx2zDRwbkCO6 X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-Rocket-Received: from [10.1.1.129] (d.sturek@66.27.60.174 with ) by smtp113.sbc.mail.gq1.yahoo.com with SMTP; 15 Oct 2013 09:34:02 -0700 PDT User-Agent: Microsoft-MacOutlook/14.3.8.130913 Date: Tue, 15 Oct 2013 09:33:59 -0700 From: Don Sturek To: Routing Over Low power and Lossy networks Message-ID: Thread-Topic: [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local In-Reply-To: <3599.1381852752@sandelman.ca> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: mariainesrobles@gmail.com, johui@cisco.com, rdroms@cisco.com Subject: Re: [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 16:35:44 -0000 Hi Michael, We should leave in scope 4 for use in administratively scoped domains. This would allow applications to define specific multicast addresses using scope 4 without having to go through the trouble to "un-reserve" adminstrative scope. Also, I am in favor of Ralph's proposal on using PAN ID for MPL scope 3. I don't see how any automatic configuration could take place if we can't identify a concrete identifier for the scope. The other alternative (and to be honest the one I thought we were going to use) is DODAG ID. This would allow your scenario where a subnet of different link technologies could support MPL domain 3. Don On 10/15/13 8:59 AM, "Michael Richardson" wrote: > > >Don Sturek wrote: > > At some point, I think it would be interesting to see multicast > > forwarding rules in a mesh network where flooding is not used. I >would > > see that case as the example of where scope 4 would be used. > >okay, so when we write a new protocol, we can specify this. >Why have the code there to support scope-4 when there is no other >behaviour? > > > I know that a lot of work is needed in defining the rules for > > forwarding when flooding is not used but in a large mesh network, >there > > would be a lot of benefit to such a feature. > >Do you agree with me about PANID vs Subnet or not? > >-- >Michael Richardson , Sandelman Software Works > > >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll From rdroms@cisco.com Tue Oct 15 09:37: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 3E08621E80C7 for ; Tue, 15 Oct 2013 09:37:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mIjYWqxeymyv for ; Tue, 15 Oct 2013 09:37:27 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 41A7F11E818C for ; Tue, 15 Oct 2013 09:37:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2181; q=dns/txt; s=iport; t=1381855045; x=1383064645; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=XU9skf6/4MnD3CtWCe5FE6Xth7cgn5/sauqhaHXoRyU=; b=gVXdvHLCGZYvcDS2G3v1lnvkeFtbrFBsR75lDlFl6Ox+EPExnSW/4gBT O5BK7nAUqb8k2JZARjTx3YlQYkW9WpS3GWlzbt8Zvn0Ifd3BYKTnGsbG5 ux/ACUWiWhKiZCx8xjpe2J850H3grri4JDgdEstw20HNriaB2SbubVR2F U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAExuXVKtJXG+/2dsb2JhbABQCoMHOFLCKYEiFnSCJQEBAQMBAQEBNzQLBQsCAQgYChQQJwslAgQOBQiHbAMJBgyzUAWJbwSOB4EQAjEHgx+BBgOqBoFmgT6CKQ X-IronPort-AV: E=Sophos;i="4.93,500,1378857600"; d="scan'208";a="272390241" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 15 Oct 2013 16:37:24 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9FGbOqA020621 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Oct 2013 16:37:24 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.229]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Tue, 15 Oct 2013 11:37:24 -0500 From: "Ralph Droms (rdroms)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local Thread-Index: AQHOyQm0EEMO5JOK1Ei62VsuFuvrVZn2Io2AgAACdYCAABu3AIAACbeAgAAA9IA= Date: Tue, 15 Oct 2013 16:37:23 +0000 Message-ID: <4518F39EB578034D8C99A9B7776CDBA301BE0FA1@xmb-aln-x04.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.155.136.73] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mariainesrobles@gmail.com" , "Jonathan Hui \(johui\)" Subject: Re: [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 16:37:32 -0000 On Oct 15, 2013, at 9:33 AM 10/15/13, Don Sturek wrote: > Hi Michael, >=20 > We should leave in scope 4 for use in administratively scoped domains. > This would allow applications to define specific multicast addresses usin= g > scope 4 without having to go through the trouble to "un-reserve" > adminstrative scope. >=20 > Also, I am in favor of Ralph's proposal on using PAN ID for MPL scope 3. > I don't see how any automatic configuration could take place if we can't > identify a concrete identifier for the scope. The other alternative (and > to be honest the one I thought we were going to use) is DODAG ID. This > would allow your scenario where a subnet of different link technologies > could support MPL domain 3. Don - at present, MPL is, as far as I know, independent of RPL. In particu= lar, MPL can be used in a mesh that does not use RPL. Therefore, there mig= ht not be a DODAG ID to use as a MPL domain identifier. - Ralph >=20 > Don >=20 >=20 > On 10/15/13 8:59 AM, "Michael Richardson" wrote: >=20 >>=20 >>=20 >> Don Sturek wrote: >>> At some point, I think it would be interesting to see multicast >>> forwarding rules in a mesh network where flooding is not used. I >> would >>> see that case as the example of where scope 4 would be used. >>=20 >> okay, so when we write a new protocol, we can specify this. >> Why have the code there to support scope-4 when there is no other >> behaviour? >>=20 >>> I know that a lot of work is needed in defining the rules for >>> forwarding when flooding is not used but in a large mesh network, >> there >>> would be a lot of benefit to such a feature. >>=20 >> Do you agree with me about PANID vs Subnet or not? >>=20 >> -- >> Michael Richardson , Sandelman Software Works >>=20 >>=20 >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From mcr@sandelman.ca Tue Oct 15 10:09: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 34C7921F9DD6 for ; Tue, 15 Oct 2013 10:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.268 X-Spam-Level: X-Spam-Status: No, score=-2.268 tagged_above=-999 required=5 tests=[AWL=0.331, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5fOvr2zIfOBb for ; Tue, 15 Oct 2013 10:09:55 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 266E011E813D for ; Tue, 15 Oct 2013 10:09:54 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id BBB162017F; Tue, 15 Oct 2013 14:20:19 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 891CE63B88; Tue, 15 Oct 2013 13:09:46 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 7A19963AEF; Tue, 15 Oct 2013 13:09:46 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: References: X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 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: mariainesrobles@gmail.com, johui@cisco.com, rdroms@cisco.com Subject: Re: [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 17:09:56 -0000 --=-=-= Don Sturek wrote: > Also, I am in favor of Ralph's proposal on using PAN ID for MPL scope > 3. I don't see how any automatic configuration could take place if we > can't identify a concrete identifier for the scope. The other > alternative (and to be honest the one I thought we were going to use) > is DODAG ID. This would allow your scenario where a subnet of > different link technologies could support MPL domain 3. I like DODAG ID. That suits me fine. -- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUl122IqHRg3pndX9AQKpQAP9E8q5KK1wSz553gQ4apX/xf2shUhpfiHv VCqGtk4f44COJW1MSKv+pP7U6W/FbxdPUwo8ekL2D8Mw1uJbk3dwtptxZc2OgLnA l8NsOqifS7Odg4IAmg6D6aNIUORNIvOK54mOHuXv+qWFOIq7u6VApNEptQBDCNNU bDmto3EeBEs= =p5Au -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Tue Oct 15 10:16: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 2E93F11E81E4 for ; Tue, 15 Oct 2013 10:16:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-IIlQDtrKsp for ; Tue, 15 Oct 2013 10:16:51 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 5D76C11E8136 for ; Tue, 15 Oct 2013 10:16:27 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 0059520256; Tue, 15 Oct 2013 14:26:52 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 876A363B88; Tue, 15 Oct 2013 13:16:20 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 7751663AEF; Tue, 15 Oct 2013 13:16:20 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: <4518F39EB578034D8C99A9B7776CDBA301BE0FA1@xmb-aln-x04.cisco.com> References: <4518F39EB578034D8C99A9B7776CDBA301BE0FA1@xmb-aln-x04.cisco.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 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: "mariainesrobles@gmail.com" , "Jonathan Hui \(johui\)" Subject: Re: [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 17:16:56 -0000 --=-=-= Ralph Droms (rdroms) wrote: >> Also, I am in favor of Ralph's proposal on using PAN ID for MPL scope >> 3. I don't see how any automatic configuration could take place if we >> can't identify a concrete identifier for the scope. The other >> alternative (and to be honest the one I thought we were going to use) >> is DODAG ID. This would allow your scenario where a subnet of >> different link technologies could support MPL domain 3. > Don - at present, MPL is, as far as I know, independent of RPL. In > particular, MPL can be used in a mesh that does not use RPL. > Therefore, there might not be a DODAG ID to use as a MPL domain > identifier. While I agree with you, that MPL is separate from RPL in the same way that HTTP can run over V32bis or ITU-T Rec. X.214 (OSI TPx) if we want it to, if one want to use MPL in another environment one will have to specify the boundaries somehow. Using PANID limits one to 802.15.4-ish networks: what is the PANID of ethernet? ROLL is specifically chartered to work across a multitude of different layer-2 protocols. -- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUl14YIqHRg3pndX9AQKEFgP+P2kURBMtD52aycC47LUPRAmGe0ghNyPT C/V/Mhr0xIkyt8IybLfiupUz5ZSrrpdrHtHtQlSLRbE57uySydqPY/CXbmjMOfqZ s3DgI7IjxMFww/v4aunl8hd6FJJ4HwEllwo1LVY6nQqC0Kg83fdfh+wk6aSdicxc SdoAR/yTQPQ= =YAWo -----END PGP SIGNATURE----- --=-=-=-- From kerlyn2001@gmail.com Tue Oct 15 10:17:39 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF73D11E8121 for ; Tue, 15 Oct 2013 10:17:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QzqK0VMFBSD3 for ; Tue, 15 Oct 2013 10:17:39 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 57FA011E813F for ; Tue, 15 Oct 2013 10:17:36 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id i19so1439869wiw.12 for ; Tue, 15 Oct 2013 10:17:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=BIiQOrXNU12Vopkq0wZ4iTGnU49xxou3NV9sSDFOFi8=; b=Y0yZkjF7hbjnZ6fNC1BVLKOOgyeHgQsKQOc+JxLMcfv2a+UWDynIvk+gNap+vAsdn4 VPONUhD4/lYEdhb8GACQvdJ9JbtJY0huAe1iukhwpZj+Nj79mZT0ZwqtAfjl7LJJCMgo pcBwWhje6ILyaRYBbo2KVAtCFWAE80z4W4//GoB5LtEiENNv1o6Veabv942JmGrMwNC0 7lA95gqMtu6W9ZoIknBTf/jsXpslk7bs5jCYSWn30zWoznm+/xBBK/MHYNyI33rtlbFI k2xZ2K2jErQRRzfw3bpTMI9B/ypdNht+rKkHvfCuTWEwaufRUmtbj5JIKgVc3pkVFRIu asyA== MIME-Version: 1.0 X-Received: by 10.194.93.3 with SMTP id cq3mr35801729wjb.26.1381857455488; Tue, 15 Oct 2013 10:17:35 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.216.227.132 with HTTP; Tue, 15 Oct 2013 10:17:35 -0700 (PDT) In-Reply-To: References: <3599.1381852752@sandelman.ca> Date: Tue, 15 Oct 2013 13:17:35 -0400 X-Google-Sender-Auth: F-hTrmREHSOHyMSp4jxDQAmoy9g Message-ID: From: Kerry Lynn To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary=047d7bb04822c3cd0b04e8cac26c Cc: mariainesrobles@gmail.com, "Jonathan Hui \(johui\)" , Ralph Droms Subject: Re: [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 17:17:39 -0000 --047d7bb04822c3cd0b04e8cac26c Content-Type: text/plain; charset=ISO-8859-1 On Tue, Oct 15, 2013 at 12:33 PM, Don Sturek wrote: > Hi Michael, > > We should leave in scope 4 for use in administratively scoped domains. > This would allow applications to define specific multicast addresses using > scope 4 without having to go through the trouble to "un-reserve" > adminstrative scope. > > Also, I am in favor of Ralph's proposal on using PAN ID for MPL scope 3. > I don't see how any automatic configuration could take place if we can't > identify a concrete identifier for the scope. The other alternative (and > to be honest the one I thought we were going to use) is DODAG ID. This > would allow your scenario where a subnet of different link technologies > could support MPL domain 3. > > If a host can be present simultaneously in more than one DODAG then we run afoul of normative RFC 4007 behavior: Zones of the same scope cannot overlap; i.e., they can have no links or interfaces in common. Link-local scope is essentially defined by a combination of link layer connectivity and routing behavior. I believe we need something similar in order to automatically define scope 0x03. To the extent that we need scope 0x03 at all, I think it's to emulate classic link-local behavior in a mesh. There are only so many ways that meshes can be distinguished: either by location, frequency, or code diversity (assuming any two of three overlap). In Ralph's example, he assumes location and frequency overlap. In Michael's example, I suspect he assumes location and PAN ID overlap. Finally, we may need to constrain Ralph's definition a bit further and define an 802.15.4 scope 0x03 zone as a set of interfaces that share a common PAN coordinator and PAN ID. -K- Don > > > On 10/15/13 8:59 AM, "Michael Richardson" wrote: > > > > > > >Don Sturek wrote: > > > At some point, I think it would be interesting to see multicast > > > forwarding rules in a mesh network where flooding is not used. I > >would > > > see that case as the example of where scope 4 would be used. > > > >okay, so when we write a new protocol, we can specify this. > >Why have the code there to support scope-4 when there is no other > >behaviour? > > > > > I know that a lot of work is needed in defining the rules for > > > forwarding when flooding is not used but in a large mesh network, > >there > > > would be a lot of benefit to such a feature. > > > >Do you agree with me about PANID vs Subnet or not? > > > >-- > >Michael Richardson , Sandelman Software Works > > > > > >_______________________________________________ > >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 > --047d7bb04822c3cd0b04e8cac26c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Oct 15, 2013 at 12:33 PM, Don Sturek <d.sturek@att= .net> wrote:
Hi Michael,

We should leave in scope 4 for use in administratively scoped domains.
This would allow applications to define specific multicast addresses using<= br> scope 4 without having to go through the trouble to "un-reserve"<= br> adminstrative scope.

Also, I am in favor of Ralph's proposal on using PAN ID for MPL scope 3= .
I don't see how any automatic configuration could take place if we can&= #39;t
identify a concrete identifier for the scope. =A0The other alternative (and=
to be honest the one I thought we were going to use) is DODAG ID. =A0 This<= br> would allow your scenario where a subnet of different link technologies
could support MPL domain 3.

If a host can be present simultaneously in more than one DODAG then=
we run afoul of normative RFC 4007 behavior:

=A0 Zone= s of the same scope cannot overlap; i.e., they can have no links
=A0 or interfaces in common.

Link-local scope = is essentially defined by a combination of link layer
connectivity and r= outing behavior.=A0 I believe we need something similar
in order to auto= matically define scope 0x03.=A0 To the extent that we need
scope 0x03 at all, I think it's to emulate classic link-local behavior = in a
mesh.=A0 There are only so many ways that meshes can be distinguish= ed:
either by location, frequency, or code diversity (assuming any two o= f
three overlap).=A0 In Ralph's example, he assumes location and frequenc= y
overlap.=A0 In Michael's example, I suspect he assumes = location and PAN
ID overlap.

Finally, we ma= y need to constrain Ralph's definition a bit further and
define an 802.15.4=A0 scope 0x03 zone as a set of interfaces that share
= a common PAN coordinator and PAN ID.

-K-

Don


On 10/15/13 8:59 AM, "Michael Richardson" <mcr+ietf@sandelman.ca> wrote:

>
>
>Don Sturek <d.sturek@att.net= > wrote:
> =A0 =A0> At some point, I think it would be interesting to see mult= icast
> =A0 =A0> forwarding rules in a mesh network where flooding is not u= sed. =A0I
>would
> =A0 =A0> see that case as the example of where scope 4 would be use= d.
>
>okay, so when we write a new protocol, we can specify this.
>Why have the code there to support scope-4 when there is no other
>behaviour?
>
> =A0 =A0> I know that a lot of work is needed in defining the rules = for
> =A0 =A0> forwarding when flooding is not used but in a large mesh n= etwork,
>there
> =A0 =A0> would be a lot of benefit to such a feature.
>
>Do you agree with me about PANID vs Subnet or not?
>
>--
>Michael Richardson <mcr+I= ETF@sandelman.ca>, Sandelman Software Works
>
>
>___________________= ____________________________
>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

--047d7bb04822c3cd0b04e8cac26c-- From mcr@sandelman.ca Tue Oct 15 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 1E0F911E8141 for ; Tue, 15 Oct 2013 10:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.497 X-Spam-Level: X-Spam-Status: No, score=-2.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FbfLxOI5A5r6 for ; Tue, 15 Oct 2013 10:18:17 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 44A5811E813D for ; Tue, 15 Oct 2013 10:18:13 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id BE29A2025A; Tue, 15 Oct 2013 14:28:28 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 587CD63B88; Tue, 15 Oct 2013 13:17:56 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 4BBEE63AEF; Tue, 15 Oct 2013 13:17:56 -0400 (EDT) From: Michael Richardson To: robert.cragie@gridmerge.com, Routing Over Low power and Lossy networks In-Reply-To: <525D69F4.4030204@gridmerge.com> References: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org> <082.0e60a05a9e9a33903054243f518f8668@trac.tools.ietf.org> <13450.1381846273@sandelman.ca> <4518F39EB578034D8C99A9B7776CDBA301BE0790@xmb-aln-x04.cisco.com> <5697.1381853285@sandelman.ca> <525D69F4.4030204@gridmerge.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Subject: Re: [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 17:18:22 -0000 --=-=-= Robert Cragie wrote: > Yes, but your scenario is surely one where it cannot be automatically > configured and therefore scope 4 is surely more applicable? If the RPL can discover/build the network, then the MPL should automatically use it. Yes, I agree that I have to plug the cables in, and I probably have to apply power. -- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUl14wYqHRg3pndX9AQJgtQQAmfdjI8jp/+Ad1zBfbrmHOS/hxJ0jtqPu IlkPvvaDeJ6AV3LA1j67KBAGDx8gbZQnH8HzA9RL6pL9bH/KjXmOarkFD8kzNADE 4Z8Vf06ivEIGRq8J+FiNA6WxJvs1R+a8H4mW5oAVh1uZzAIZj084gFCUddf1SQG2 4SM9DxlwJSA= =hDRf -----END PGP SIGNATURE----- --=-=-=-- From rdroms@cisco.com Tue Oct 15 10:26: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 0840011E8147 for ; Tue, 15 Oct 2013 10:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RG8x7EEwfy2H for ; Tue, 15 Oct 2013 10:25:55 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id BA17B11E8188 for ; Tue, 15 Oct 2013 10:25:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3487; q=dns/txt; s=iport; t=1381857952; x=1383067552; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=MykneCnYFRzRYNF+oqObw2H0dZhCOs/pfq5PWYwMoaY=; b=V57NfvGnit1xw2n4stqWZ9wTiSwQD4lzdILOeYjmJ9nbegHMdLf2QGrD vsG/Ns23GvX05aAjlCSQvksSVW7T0+qFkgkwX0Itoa+prA2Req66Wsrfm QxAWVZ6CZPQ22h7pSAmZEwbgUjvHGLa5N3E9vGwoX1BFjI6F6/2h15uGy I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAEB6XVKtJXG//2dsb2JhbABQCoMHOFLCKYEjFnSCJQEBAQMBAQEBawsFCwIBCBgKJCcLJQIEDgUIh2wDCQYMs20FiW8EjgeBEAIxB4MfgQYDiQSLI5VfgWaBPoIp X-IronPort-AV: E=Sophos;i="4.93,500,1378857600"; d="scan'208";a="272496811" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-4.cisco.com with ESMTP; 15 Oct 2013 17:25:50 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r9FHPo48004473 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Oct 2013 17:25:50 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.229]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Tue, 15 Oct 2013 12:25:50 -0500 From: "Ralph Droms (rdroms)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local Thread-Index: AQHOyQm0EEMO5JOK1Ei62VsuFuvrVZn2Io2AgAACdYCAABu3AIAACbeAgAAML4CAAAJNgA== Date: Tue, 15 Oct 2013 17:25:50 +0000 Message-ID: <4518F39EB578034D8C99A9B7776CDBA301BE13CE@xmb-aln-x04.cisco.com> References: <3599.1381852752@sandelman.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.155.136.73] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <91A063E392453C479D9E2F55F7CF52AF@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mariainesrobles@gmail.com" , "Jonathan Hui \(johui\)" Subject: Re: [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 17:26:00 -0000 On Oct 15, 2013, at 10:17 AM 10/15/13, Kerry Lynn wrote: > On Tue, Oct 15, 2013 at 12:33 PM, Don Sturek wrote: > Hi Michael, >=20 > We should leave in scope 4 for use in administratively scoped domains. > This would allow applications to define specific multicast addresses usin= g > scope 4 without having to go through the trouble to "un-reserve" > adminstrative scope. >=20 > Also, I am in favor of Ralph's proposal on using PAN ID for MPL scope 3. > I don't see how any automatic configuration could take place if we can't > identify a concrete identifier for the scope. The other alternative (and > to be honest the one I thought we were going to use) is DODAG ID. This > would allow your scenario where a subnet of different link technologies > could support MPL domain 3. >=20 > If a host can be present simultaneously in more than one DODAG then > we run afoul of normative RFC 4007 behavior: >=20 > Zones of the same scope cannot overlap; i.e., they can have no links > or interfaces in common. >=20 > Link-local scope is essentially defined by a combination of link layer > connectivity and routing behavior. I believe we need something similar > in order to automatically define scope 0x03. To the extent that we need > scope 0x03 at all, I think it's to emulate classic link-local behavior in= a > mesh. There are only so many ways that meshes can be distinguished: > either by location, frequency, or code diversity (assuming any two of > three overlap). In Ralph's example, he assumes location and frequency > overlap. In Michael's example, I suspect he assumes location and PAN > ID overlap. Following up on Kerry's observation that a node can belong to more than one= DODAG, how does such a node determine which DODAG to use for scop 3 forwar= ding, or which DODAG to use for filtering inbound scop 3 traffic? - Ralph >=20 > Finally, we may need to constrain Ralph's definition a bit further and > define an 802.15.4 scope 0x03 zone as a set of interfaces that share > a common PAN coordinator and PAN ID. >=20 > -K- >=20 >=20 > Don >=20 >=20 > On 10/15/13 8:59 AM, "Michael Richardson" wrote: >=20 > > > > > >Don Sturek wrote: > > > At some point, I think it would be interesting to see multicast > > > forwarding rules in a mesh network where flooding is not used. I > >would > > > see that case as the example of where scope 4 would be used. > > > >okay, so when we write a new protocol, we can specify this. > >Why have the code there to support scope-4 when there is no other > >behaviour? > > > > > I know that a lot of work is needed in defining the rules for > > > forwarding when flooding is not used but in a large mesh network, > >there > > > would be a lot of benefit to such a feature. > > > >Do you agree with me about PANID vs Subnet or not? > > > >-- > >Michael Richardson , Sandelman Software Works > > > > > >_______________________________________________ > >Roll mailing list > >Roll@ietf.org > >https://www.ietf.org/mailman/listinfo/roll >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From kerlyn2001@gmail.com Tue Oct 15 10:33: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 1C3DB11E8121 for ; Tue, 15 Oct 2013 10:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HB962TkjZfpU for ; Tue, 15 Oct 2013 10:33:31 -0700 (PDT) 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 69B0511E81F0 for ; Tue, 15 Oct 2013 10:33:21 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id w62so8784594wes.35 for ; Tue, 15 Oct 2013 10:33:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=WInjMYBU0iWzCS0KNuYP9yawPFsHJ/khU/Gql+EmsRg=; b=fEu+EhZRQM1KLHafsdGfjT8xqGhTz5R02Xg8yAPSvSiaVKSFNN/UpYJWwHx5bZPBxA 4eK1ViNnUdXosb0s4oLysQy601NWHYTYmYaLHzAquZYsCtcJ+s38aROaBs9l7wAym1ey ynU+JWlYIbeipocP8oruPnae7WDhs1rBEbZlWXQZyQ7sLGRBG8wRV0Wt8OEkObvGirAN Ak+WYPHKeNaaUZR9/PgSbq6LdINuAM77dJerPZtDysR1+USFHmG1lgUpgVGbZJwWIH+G N+hwt2XQAqdkeQQ3atEfEVth7HwmdvTpA/9j8SUisJUA2GUYVOqSt1a5Q71c+ftostV0 ixRA== MIME-Version: 1.0 X-Received: by 10.180.13.13 with SMTP id d13mr20810003wic.34.1381858400470; Tue, 15 Oct 2013 10:33:20 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.216.227.132 with HTTP; Tue, 15 Oct 2013 10:33:20 -0700 (PDT) In-Reply-To: <19709.1381857380@sandelman.ca> References: <4518F39EB578034D8C99A9B7776CDBA301BE0FA1@xmb-aln-x04.cisco.com> <19709.1381857380@sandelman.ca> Date: Tue, 15 Oct 2013 13:33:20 -0400 X-Google-Sender-Auth: AvDHDrOlXfxTghU3HdkdtFmgM4k Message-ID: From: Kerry Lynn To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary=001a11c2a462170b3504e8cafbd0 Cc: "mariainesrobles@gmail.com" , "Jonathan Hui \(johui\)" Subject: Re: [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 17:33:32 -0000 --001a11c2a462170b3504e8cafbd0 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Oct 15, 2013 at 1:16 PM, Michael Richardson wrote: > > Ralph Droms (rdroms) wrote: > >> Also, I am in favor of Ralph's proposal on using PAN ID for MPL > scope > >> 3. I don't see how any automatic configuration could take place if > we > >> can't identify a concrete identifier for the scope. The other > >> alternative (and to be honest the one I thought we were going to > use) > >> is DODAG ID. This would allow your scenario where a subnet of > >> different link technologies could support MPL domain 3. > > > Don - at present, MPL is, as far as I know, independent of RPL. In > > particular, MPL can be used in a mesh that does not use RPL. > > Therefore, there might not be a DODAG ID to use as a MPL domain > > identifier. > > While I agree with you, that MPL is separate from RPL in the same way that > HTTP can run over V32bis or ITU-T Rec. X.214 (OSI TPx) if we want it to, > if one want to use MPL in another environment one will have to specify > the boundaries somehow. > > If MPL were defined in terms of scope 0x02 messages (as the Trickle Algorithm is) we'd be done by now. An MPL domain would then be the set of links connected by MPL forwarders, with the boundary set by administratively opting out interfaces (a MPL domain boundary would thus be defined as cutting through a node, not a link). Using PANID limits one to 802.15.4-ish networks: what is the PANID of > ethernet? ROLL is specifically chartered to work across a multitude of > different layer-2 protocols. > > Scope 0x03 is not defined on 802.3. It is only needed at all on mesh networks, therefore it is defined (or not) on a link layer basis. -K- > -- > Michael Richardson , Sandelman Software Works > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > --001a11c2a462170b3504e8cafbd0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Oct 15, 2013 at 1:16 PM, Michael Richardson <= mcr+ietf@sandelman.ca> wrote:
<= div class=3D"gmail_quote">

Ralph Droms (rdroms) <rdroms@cisco.c= om> wrote:
=A0 =A0 >> Also, I am in favor of Ralph's= proposal on using PAN ID for MPL scope
=A0 =A0 >> 3. =A0I don't see how any automatic configuration coul= d take place if we
=A0 =A0 >> can't identify a concrete identifier for the scope. = =A0The other
=A0 =A0 >> alternative (and to be honest the one I thought we were go= ing to use)
=A0 =A0 >> is DODAG ID. =A0This would allow your scenario where a sub= net of
=A0 =A0 >> different link technologies could support MPL domain 3.
=A0 =A0 > Don - at present, MPL is, as far as I know, independent of RPL= . =A0In
=A0 =A0 > particular, MPL can be used in a mesh that does not use RPL. =A0 =A0 > Therefore, there might not be a DODAG ID to use as a MPL domai= n
=A0 =A0 > identifier.

While I agree with you, that MPL is separate from RPL in the same way= that
HTTP can run over V32bis or ITU-T Rec. X.214 (OSI TPx) if we want it to, if one want to use MPL in another environment one will have to specify
the boundaries somehow.

If MPL were defined in terms of scope 0x02 messages (= as the Trickle
Algorithm is) we'd be done by now.=A0 An MPL domain w= ould then be the
set of links connected by=A0 MPL forwarders, with the b= oundary set by
administratively opting out interfaces (a MPL domain boundary wo= uld
thus be defined as cutting through a node, not a link).

Using PANID limits one to 802.15.4-ish networks: what is the PANID of
ethernet? =A0ROLL is specifically chartered to work across a multitude of different layer-2 protocols.

S= cope 0x03 is not defined on 802.3.=A0 It is only needed at all on mesh
<= /div>
networks, therefore it is defined (or not) on a link layer basis.=

-K-
=A0
--
Michael Richardson <mcr+IETF@= sandelman.ca>, Sandelman Software Works



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


--001a11c2a462170b3504e8cafbd0-- From Richard.Kelsey@silabs.com Tue Oct 15 12:56: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 B843611E8201 for ; Tue, 15 Oct 2013 12:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X+1iobSWN9XC for ; Tue, 15 Oct 2013 12:56:21 -0700 (PDT) Received: from na3sys009aog105.obsmtp.com (na3sys009aog105.obsmtp.com [74.125.149.75]) by ietfa.amsl.com (Postfix) with ESMTP id 6194E11E8184 for ; Tue, 15 Oct 2013 12:56:20 -0700 (PDT) Received: from mxsause01.silabs.com ([66.193.122.70]) (using TLSv1) by na3sys009aob105.postini.com ([74.125.148.12]) with SMTP ID DSNKUl2d4ovME0+gOLnX7Kl9oj6yp4UskkzR@postini.com; Tue, 15 Oct 2013 12:56:20 PDT Received: from EXCAUS010.silabs.com (unknown [10.100.0.94]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mxsause01.silabs.com (Postfix) with ESMTP id AB54EFF103; Tue, 15 Oct 2013 14:56:17 -0500 (CDT) Received: from kelsey-ws (10.4.148.34) by EXCAUS010.silabs.com (10.100.0.59) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 15 Oct 2013 14:56:17 -0500 Date: Tue, 15 Oct 2013 16:01:17 -0400 Message-ID: <87ppr6gv76.fsf@kelsey-ws.hq.ember.com> From: Richard Kelsey To: Routing Over Low power and Lossy networks In-Reply-To: (message from Kerry Lynn on Tue, 15 Oct 2013 13:17:35 -0400) X-Auto-Response-Suppress: DR, OOF, AutoReply References: <3599.1381852752@sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.4.148.34] Cc: roll@ietf.org, mariainesrobles@gmail.com, johui@cisco.com, rdroms@cisco.com Subject: Re: [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 19:56:39 -0000 > Date: Tue, 15 Oct 2013 13:17:35 -0400 > From: Kerry Lynn > > Link-local scope is essentially defined by a combination of link layer > connectivity and routing behavior. I believe we need something similar > in order to automatically define scope 0x03. To the extent that we need > scope 0x03 at all, I think it's to emulate classic link-local behavior in a > mesh. There are only so many ways that meshes can be distinguished: > either by location, frequency, or code diversity (assuming any two of > three overlap). In Ralph's example, he assumes location and frequency > overlap. In Michael's example, I suspect he assumes location and PAN > ID overlap. > > Finally, we may need to constrain Ralph's definition a bit further and > define an 802.15.4 scope 0x03 zone as a set of interfaces that share > a common PAN coordinator and PAN ID. > > -K- I think you have to fall back on routing behavior. Consider a mixed-PHY mesh, such as a a combination of 802.15.4 and PLC links. If the routing layer considers it all one mesh, then it is, regardless of whether or not there are any 802.15.4 nodes in direct communication using the same PAN ID. On the other hand, the routing layer could take the same physical setup and treat it as distinct 802.15.4 meshes with PLC interconnects, in which case you would get multiple 0x03 scopes. I shall not today attempt further to define 0x03 scope; and perhaps I could never succeed in intelligibly doing so. But I know it when I see it. (paraphrasing Justice Potter Stewart) -Richard This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed and may contain information that is non-public, proprietary, privileged, confidential, and exempt from disclosure under applicable law or may constitute as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, notify us immediately by telephone and (i) destroy this message if a facsimile or (ii) delete this message immediately if this is an electronic communication. Thank you. From rdroms@cisco.com Tue Oct 15 15:33: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 E8A0611E820C for ; Tue, 15 Oct 2013 15:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tm57JHhorevQ for ; Tue, 15 Oct 2013 15:33:33 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 1BF3521F9DBA for ; Tue, 15 Oct 2013 15:33:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3093; q=dns/txt; s=iport; t=1381876413; x=1383086013; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=uBE9B7h50CyCdSGMuaZt0tvLGoKeZCYhd+oO9Ttjkzk=; b=PTjnyV0W7CmuWKa4fkz2e9QZj1z9QmMjp8dFCgVrDR9FJo6cdBoUiTIH lg8bc5yb4FFfAxR8MIB4tdBeJfjRyiUN5AbMhPcYYz5mD/g23qxtyIObn KiNgCK67mA+TLY9An9hiheObJS3oM759GxSLOqDWsz0QlHtlVcv+5r/Nt E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAAjCXVKtJV2Z/2dsb2JhbABagwc4UsIqgSIWdIIlAQEBAwEBAQE3NAsFCwIBCBQBDRQQJwslAgQOBQiHeAYMvXYEjxcCLAUHgx+BBgOUJ5VfgWaBPoIp X-IronPort-AV: E=Sophos;i="4.93,503,1378857600"; d="scan'208";a="272543687" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 15 Oct 2013 22:33:31 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9FMXVxt010836 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Oct 2013 22:33:31 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.229]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Tue, 15 Oct 2013 17:33:31 -0500 From: "Ralph Droms (rdroms)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local Thread-Index: AQHOyQm0EEMO5JOK1Ei62VsuFuvrVZn2Io2AgAACdYCAABu3AIAACbeAgAAML4D//9iZVoAAf6sA Date: Tue, 15 Oct 2013 22:33:30 +0000 Message-ID: <4518F39EB578034D8C99A9B7776CDBA301BE29E1@xmb-aln-x04.cisco.com> References: <3599.1381852752@sandelman.ca> <87ppr6gv76.fsf@kelsey-ws.hq.ember.com> In-Reply-To: <87ppr6gv76.fsf@kelsey-ws.hq.ember.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.155.136.73] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mariainesrobles@gmail.com" , "Jonathan Hui \(johui\)" Subject: Re: [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 22:33:38 -0000 On Oct 15, 2013, at 1:01 PM 10/15/13, Richard Kelsey wrote: >> Date: Tue, 15 Oct 2013 13:17:35 -0400 >> From: Kerry Lynn >>=20 >> Link-local scope is essentially defined by a combination of link layer >> connectivity and routing behavior. I believe we need something similar >> in order to automatically define scope 0x03. To the extent that we need >> scope 0x03 at all, I think it's to emulate classic link-local behavior i= n a >> mesh. There are only so many ways that meshes can be distinguished: >> either by location, frequency, or code diversity (assuming any two of >> three overlap). In Ralph's example, he assumes location and frequency >> overlap. In Michael's example, I suspect he assumes location and PAN >> ID overlap. >>=20 >> Finally, we may need to constrain Ralph's definition a bit further and >> define an 802.15.4 scope 0x03 zone as a set of interfaces that share >> a common PAN coordinator and PAN ID. >>=20 >> -K- >=20 > I think you have to fall back on routing behavior. Consider a > mixed-PHY mesh, such as a a combination of 802.15.4 and PLC > links. If the routing layer considers it all one mesh, then it > is, regardless of whether or not there are any 802.15.4 nodes in > direct communication using the same PAN ID. OK, but I don't think there is a good way to associate a specific MPL datag= ram with a DODAG ID, so a node can determine which scope 3 that MPL datagra= m is associated with. And, using DODAG ID tightly couples MPL with RPL, when MPL as currently def= ined can be used without RPL. I think scope 4 is a much better candidate for the "composite" subnet use c= ase, while scope 3 is good for a single physical mesh. - Ralph > On the other hand, > the routing layer could take the same physical setup and treat it > as distinct 802.15.4 meshes with PLC interconnects, in which case > you would get multiple 0x03 scopes. >=20 > I shall not today attempt further to define 0x03 scope; and > perhaps I could never succeed in intelligibly doing so. But I > know it when I see it. > (paraphrasing Justice Potter Stewart) >=20 > -Richard > This message (including any attachments) is intended only for the use of = the individual or entity to which it is addressed and may contain informati= on that is non-public, proprietary, privileged, confidential, and exempt fr= om disclosure under applicable law or may constitute as attorney work produ= ct. If you are not the intended recipient, you are hereby notified that an= y use, dissemination, distribution, or copying of this communication is str= ictly prohibited. If you have received this communication in error, notify = us immediately by telephone and (i) destroy this message if a facsimile or = (ii) delete this message immediately if this is an electronic communication= . =20 >=20 > Thank you. >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From robert.cragie@gridmerge.com Tue Oct 15 15:50:54 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 CEAE521F996A for ; Tue, 15 Oct 2013 15:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.69 X-Spam-Level: X-Spam-Status: No, score=-0.69 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_ILLEGAL_IP=1.908] 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 siW5V8fDhyjZ for ; Tue, 15 Oct 2013 15:50:50 -0700 (PDT) Received: from mail41.extendcp.co.uk (mail41.extendcp.co.uk [79.170.44.41]) by ietfa.amsl.com (Postfix) with ESMTP id B134621F9A4C for ; Tue, 15 Oct 2013 15:50:47 -0700 (PDT) Received: from host-2-102-194-92.as13285.net ([2.102.194.92] helo=[192.168.1.90]) by mail41.extendcp.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) id 1VWDRt-0003kt-SJ for roll@ietf.org; Tue, 15 Oct 2013 23:50:46 +0100 Message-ID: <525DC6C9.2010808@gridmerge.com> Date: Tue, 15 Oct 2013 23:50:49 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: roll@ietf.org References: <3599.1381852752@sandelman.ca> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080905060705070902080503" X-Authenticated-As: robert.cragie@gridmerge.com Subject: Re: [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert.cragie@gridmerge.com, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 22:50:55 -0000 This is a cryptographically signed message in MIME format. --------------ms080905060705070902080503 Content-Type: multipart/alternative; boundary="------------040505000600060809080500" This is a multi-part message in MIME format. --------------040505000600060809080500 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Kerry, Comments inline. I am in favour of using PAN ID as the basis for the MPL Domain Address=20 with scope 3 for 802.15.4-based networks. The PAN ID is the fundamental=20 identifier that groups nodes in a PAN and therefore forms a clear zone=20 for multicast dissemination. Anything else is going to be an unclear=20 superset or subset. The language can get a bit circular so I think the statement for an=20 802.15.4-based network is: "An MPL Domain associated with an MPL Domain Address of=20 ALL_MPL_FORWARDERS with a scope value of 3 (Realm-Local) is a scope zone = within which the set of 802.15.4 MPL Interfaces subscribing to that MPL=20 Domain Address all have the same PAN ID." Compare with a similar statement for Admin-Local scope: "An MPL Domain associated with an MPL Domain Address with a scope value=20 of 4 (Admin-Local) is a scope zone within which the set of MPL=20 Interfaces subscribing to that MPL Domain Address is administratively=20 configured." Robert On 15/10/2013 18:17, Kerry Lynn wrote: > On Tue, Oct 15, 2013 at 12:33 PM, Don Sturek > wrote: > > Hi Michael, > > We should leave in scope 4 for use in administratively scoped domai= ns. > This would allow applications to define specific multicast > addresses using > scope 4 without having to go through the trouble to "un-reserve" > adminstrative scope. > > Also, I am in favor of Ralph's proposal on using PAN ID for MPL > scope 3. > I don't see how any automatic configuration could take place if we > can't > identify a concrete identifier for the scope. The other > alternative (and > to be honest the one I thought we were going to use) is DODAG ID. > This > would allow your scenario where a subnet of different link > technologies > could support MPL domain 3. > > If a host can be present simultaneously in more than one DODAG then > we run afoul of normative RFC 4007 behavior: > > Zones of the same scope cannot overlap; i.e., they can have no links > or interfaces in common. > > Link-local scope is essentially defined by a combination of link layer > connectivity and routing behavior. Link-local scope is defined by link layer connectivity only,=20 surely? Where does routing behavior come into it?<.RCC> > I believe we need something similar > in order to automatically define scope 0x03. To the extent that we nee= d > scope 0x03 at all, I think it's to emulate classic link-local behavior = > in a > mesh. I agree with this, however it is not always clear what constitutes=20 "the mesh". There has to be one thing in common with all the interfaces=20 which participate in the mesh; PAN ID is an obvious choice and clearly=20 sets the zone of scope 3 in this case. DODAG ID is another possibility=20 but MPL propagation through MPL forwarders is not rooted at a single=20 node so it is more like RPL-P2P in some respects. > There are only so many ways that meshes can be distinguished: > either by location, frequency, or code diversity (assuming any two of > three overlap). In Ralph's example, he assumes location and frequency > overlap. In Michael's example, I suspect he assumes location and PAN > ID overlap. > > Finally, we may need to constrain Ralph's definition a bit further and > define an 802.15.4 scope 0x03 zone as a set of interfaces that share > a common PAN coordinator and PAN ID. I think that statement is tautological as the PAN coordinator=20 dictates the PAN ID therefore must share the PAN ID. Therefore this=20 reduces to sharing a PAN ID. > > -K- > > > Don > > > On 10/15/13 8:59 AM, "Michael Richardson" > wrote: > > > > > > >Don Sturek > wrote: > > > At some point, I think it would be interesting to see multic= ast > > > forwarding rules in a mesh network where flooding is not > used. I > >would > > > see that case as the example of where scope 4 would be used.= > > > >okay, so when we write a new protocol, we can specify this. > >Why have the code there to support scope-4 when there is no other > >behaviour? > > > > > I know that a lot of work is needed in defining the rules fo= r > > > forwarding when flooding is not used but in a large mesh > network, > >there > > > would be a lot of benefit to such a feature. > > > >Do you agree with me about PANID vs Subnet or not? > > > >-- > >Michael Richardson >, Sandelman Software Works > > > > > >_______________________________________________ > >Roll mailing list > >Roll@ietf.org > >https://www.ietf.org/mailman/listinfo/roll > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --------------040505000600060809080500 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Kerry,

Comments inline.

I am in favour of using PAN ID as the basis for the MPL Domain Address with scope 3 for 802.15.4-based networks. The PAN ID is the fundamental identifier that groups nodes in a PAN and therefore forms a clear zone for multicast dissemination. Anything else is going to be an unclear superset or subset.

The language can get a bit circular so I think the statement for an 802.15.4-based network is:

"An MPL Domain associated with an MPL Domain Address of ALL_MPL_FORWARDERS with a scope value of 3 (Realm-Local) is a scope zone within which the set of 802.15.4 MPL Interfaces subscribing to that MPL Domain Address all have the same PAN ID."

Compare with a similar statement for Admin-Local scope:

"An MPL Domain associated with an MPL Domain Address with a scope value of 4 (Admin-Local) is a scope zone within which the set of MPL Interfaces subscribing to that MPL Domain Address is administratively configured."

Robert

On 15/10/2013 18:17, Kerry Lynn wrote:=
On Tue, Oct 15, 2013 at 12:33 PM, Don Sturek <d.sturek@a= tt.net> wrote:
Hi Michael,

We should leave in scope 4 for use in administratively scoped domains.
This would allow applications to define specific multicast addresses using
scope 4 without having to go through the trouble to "un-reserve"
adminstrative scope.

Also, I am in favor of Ralph's proposal on using PAN ID for MPL scope 3.
I don't see how any automatic configuration could take place if we can't
identify a concrete identifier for the scope.  The oth= er alternative (and
to be honest the one I thought we were going to use) is DODAG ID.   This
would allow your scenario where a subnet of different link technologies
could support MPL domain 3.

If a host can be present simultaneously in more than one DODAG then
we run afoul of normative RFC 4007 behavior:

  Zones of the same scope cannot overlap; i.e., the= y can have no links
  or interfaces in common.

Link-local scope is essentially defined by a combination of link layer
connectivity and routing behavior.
<RCC>Link-local scope is defined by link layer connectivity only, surely? Where does routing behavior come into it?<.RCC>
I believe we need something similar
in order to automatically define scope 0x03.  To the extent that we need
scope 0x03 at all, I think it's to emulate classic link-local behavior in a
mesh.
<RCC>I agree with this, however it is not always clear what constitutes "the mesh". There has to be one thing in common with all the interfaces which participate in the mesh; PAN ID is an obvious choice and clearly sets the zone of scope 3 in this case. DODAG ID is another possibility but MPL propagation through MPL forwarders is not rooted at a single node so it is more like RPL-P2P in some respects.</RCC>
There are only so many ways that meshes can be distinguished:
either by location, frequency, or code diversity (assuming any two of
three overlap).  In Ralph's example, he assumes locati= on and frequency
overlap.  In Michael's example, I suspect he assume= s location and PAN
ID overlap.

Finally, we may need to constrain Ralph's definition a bit further and
define an 802.15.4  scope 0x03 zone as a set of interf= aces that share
a common PAN coordinator and PAN ID.
<RCC>I think that statement is tautological as the PAN coordinator dictates the PAN ID therefore must share the PAN ID. Therefore this reduces to sharing a PAN ID.</RCC>

-K-


Don


On 10/15/13 8:59 AM, "Michael Richardson" <mcr+ietf@sand= elman.ca> wrote:

>
>
>Don Sturek <d.sturek@att.net= > wrote:
>    > At some point, I think it would = be interesting to see multicast
>    > forwarding rules in a mesh netwo= rk where flooding is not used.  I
>would
>    > see that case as the example of = where scope 4 would be used.
>
>okay, so when we write a new protocol, we can specify this.
>Why have the code there to support scope-4 when there is no other
>behaviour?
>
>    > I know that a lot of work is nee= ded in defining the rules for
>    > forwarding when flooding is not = used but in a large mesh network,
>there
>    > would be a lot of benefit to suc= h a feature.
>
>Do you agree with me about PANID vs Subnet or not?<= br> >
>--
>Michael Richardson <mcr+IETF@sand= elman.ca>, Sandelman Software Works
>
>
>___________________________________= ____________
>Roll mailing list
>Roll@ietf.org
>https://www.ietf.org/mailman/listin= fo/roll


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



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

--------------040505000600060809080500-- --------------ms080905060705070902080503 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 Fw0xMzEwMTUyMjUwNDlaMCMGCSqGSIb3DQEJBDEWBBTREWP5iEGQm+jvv77E3iRoHjlKATBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEFwxUNvELajLmHIeX9p072YwgbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9m MA0GCSqGSIb3DQEBAQUABIIBAATzpo6pTDUn78NGtgPoRFOlX1GMfjIXKFW+YXLcD4HVeA3O UOGcc1oKJJ88iNWXVfDrQne7Kl4K+Z/jdOVdJkS/0tCoZlzTRLErgkkyqPMhG61L33JglMxx 6SF72Hv7a2gFPOohmY9VbjbNmggmBiEISatTAju5CD2HYR3sktarzAJXc7AgU91UrVZDOweU jV7YRXgt1Cmh0J4bw2RiSJetEiB8HdFXsKH9DvTf7vd0QYWkYpHofgcYvQXUb87Nb+k3MSOt ZwTITLYghhTFWZTbgIJy9mbQR5jagBYPAI6nL/S1fKxBDIdISUN6u2ipoJA9j7SCieUqlntB tTPLmkkAAAAAAAA= --------------ms080905060705070902080503-- From robert.cragie@gridmerge.com Tue Oct 15 15:52: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 19A3321F9A50 for ; Tue, 15 Oct 2013 15:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.691 X-Spam-Level: X-Spam-Status: No, score=-0.691 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908] 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 M-V56f40yW6Y for ; Tue, 15 Oct 2013 15:51:57 -0700 (PDT) Received: from mail41.extendcp.co.uk (mail41.extendcp.co.uk [79.170.44.41]) by ietfa.amsl.com (Postfix) with ESMTP id A96C221F9DF6 for ; Tue, 15 Oct 2013 15:51:51 -0700 (PDT) Received: from host-2-102-194-92.as13285.net ([2.102.194.92] helo=[192.168.1.90]) by mail41.extendcp.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) id 1VWDSs-0004f6-N3 for roll@ietf.org; Tue, 15 Oct 2013 23:51:46 +0100 Message-ID: <525DC705.2050301@gridmerge.com> Date: Tue, 15 Oct 2013 23:51:49 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Routing Over Low power and Lossy networks References: <3599.1381852752@sandelman.ca> <87ppr6gv76.fsf@kelsey-ws.hq.ember.com> <4518F39EB578034D8C99A9B7776CDBA301BE29E1@xmb-aln-x04.cisco.com> In-Reply-To: <4518F39EB578034D8C99A9B7776CDBA301BE29E1@xmb-aln-x04.cisco.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070205070802010303060804" X-Authenticated-As: robert.cragie@gridmerge.com Subject: Re: [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert.cragie@gridmerge.com, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 22:52:02 -0000 This is a cryptographically signed message in MIME format. --------------ms070205070802010303060804 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable +1 to Ralph's comments below. Robert On 15/10/2013 23:33, Ralph Droms (rdroms) wrote: > On Oct 15, 2013, at 1:01 PM 10/15/13, Richard Kelsey wrote: > >>> Date: Tue, 15 Oct 2013 13:17:35 -0400 >>> From: Kerry Lynn >>> >>> Link-local scope is essentially defined by a combination of link laye= r >>> connectivity and routing behavior. I believe we need something simil= ar >>> in order to automatically define scope 0x03. To the extent that we n= eed >>> scope 0x03 at all, I think it's to emulate classic link-local behavio= r in a >>> mesh. There are only so many ways that meshes can be distinguished: >>> either by location, frequency, or code diversity (assuming any two of= >>> three overlap). In Ralph's example, he assumes location and frequenc= y >>> overlap. In Michael's example, I suspect he assumes location and PAN= >>> ID overlap. >>> >>> Finally, we may need to constrain Ralph's definition a bit further an= d >>> define an 802.15.4 scope 0x03 zone as a set of interfaces that share= >>> a common PAN coordinator and PAN ID. >>> >>> -K- >> I think you have to fall back on routing behavior. Consider a >> mixed-PHY mesh, such as a a combination of 802.15.4 and PLC >> links. If the routing layer considers it all one mesh, then it >> is, regardless of whether or not there are any 802.15.4 nodes in >> direct communication using the same PAN ID. > OK, but I don't think there is a good way to associate a specific MPL d= atagram with a DODAG ID, so a node can determine which scope 3 that MPL d= atagram is associated with. > > And, using DODAG ID tightly couples MPL with RPL, when MPL as currently= defined can be used without RPL. > > I think scope 4 is a much better candidate for the "composite" subnet u= se case, while scope 3 is good for a single physical mesh. > > - Ralph > >> On the other hand, >> the routing layer could take the same physical setup and treat it >> as distinct 802.15.4 meshes with PLC interconnects, in which case >> you would get multiple 0x03 scopes. >> >> I shall not today attempt further to define 0x03 scope; and >> perhaps I could never succeed in intelligibly doing so. But I >> know it when I see it. >> (paraphrasing Justice Potter Stewart) >> >> -Richard >> This message (including any attachments) is intended only for the use = of the individual or entity to which it is addressed and may contain info= rmation that is non-public, proprietary, privileged, confidential, and ex= empt from disclosure under applicable law or may constitute as attorney w= ork product. If you are not the intended recipient, you are hereby notif= ied that any use, dissemination, distribution, or copying of this communi= cation is strictly prohibited. If you have received this communication in= error, notify us immediately by telephone and (i) destroy this message i= f a facsimile or (ii) delete this message immediately if this is an elect= ronic communication. >> >> Thank you. >> >> _______________________________________________ >> 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 > --------------ms070205070802010303060804 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 Fw0xMzEwMTUyMjUxNDlaMCMGCSqGSIb3DQEJBDEWBBSBaFuShhJnZo2SXJ51b4m5eJN3LjBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEFwxUNvELajLmHIeX9p072YwgbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9m MA0GCSqGSIb3DQEBAQUABIIBAJW9nlzI/VZ1wFPOMF7VScvqQM/1oPHIYFlGVweDUSwv0MYO FZjUf2YHxzo+K73c6ClyKKseFy4gOqYdH6aOlH3IjlTkHXlwLIrtZdsyBysPmP5pGtvPe8F9 qvJ0uDM+tlRk5SAiYanyO/OOmto8jHaE/+fYJ6A5JZgfCKu2WPRfWOCu6LucN+FAO1beCyxp w4xxoGTabvUFllOX/Y/glljoWu2Qf1Ob++SYNbcMRmfx+XmmiT8pl7sXaOR6p4wpbnp76nQW s/KThnqZAp/rMfSPEmgpg46UBPM+EDCnUZrxStdOmtSTeQvVzsXGPpE6TRKYszhT4MRPXvWc 5I94AF8AAAAAAAA= --------------ms070205070802010303060804-- From kerlyn2001@gmail.com Tue Oct 15 18:23: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 6E14611E81FA for ; Tue, 15 Oct 2013 18:23:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ibKb5kMrVdt4 for ; Tue, 15 Oct 2013 18:23:26 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id A78FA21F995F for ; Tue, 15 Oct 2013 18:23:25 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id h11so63337wiv.16 for ; Tue, 15 Oct 2013 18:23:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=XPYM/Lx8mQ8SWKyv7fc47RNedtBX6GjM240MCvEqv0I=; b=m86DVJ2s2PlS1EfP6dIWv7/7QeHVszW+y5A3uFLhAPiCCb4FK9q0Hw6cYZ1N598mF9 9DBiPNvtSiaUScfaKfa/1Gfsykbm3nMYTzh3hW6G6i5IzBlWXhejHh8cVCawvITqdyYq m/H0u9YtFo+9EzmsJg8AlglrbdFIrkm9/6qERZFiatwunqhrDi/wFaq4VR0nxsVtJt0K A/ZOItj/fxGDWVHea2uaz34rvL/VDMyP9FtAvzgHcFeG6fw1Wkt2hQavT1DaI3sqo1aA S9cTVVRgh7mMcQjBUaD88osCoqZEt43+JUaOBI2OjjSlNZ5zIUUNmdIcyLx3X63heE/d yhxQ== MIME-Version: 1.0 X-Received: by 10.194.80.137 with SMTP id r9mr98021wjx.88.1381886604488; Tue, 15 Oct 2013 18:23:24 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.216.227.132 with HTTP; Tue, 15 Oct 2013 18:23:24 -0700 (PDT) In-Reply-To: <525DC6C9.2010808@gridmerge.com> References: <3599.1381852752@sandelman.ca> <525DC6C9.2010808@gridmerge.com> Date: Tue, 15 Oct 2013 21:23:24 -0400 X-Google-Sender-Auth: Q-f-IQDPIbipJlFHzHIlGdKRagE Message-ID: From: Kerry Lynn To: Robert Cragie , Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary=047d7bdc8e862e37f404e8d18c68 Subject: Re: [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 01:23:27 -0000 --047d7bdc8e862e37f404e8d18c68 Content-Type: text/plain; charset=ISO-8859-1 Hi Robert, Comments inline... On Tue, Oct 15, 2013 at 6:50 PM, Robert Cragie wrote: > Hi Kerry, > > Comments inline. > > I am in favour of using PAN ID as the basis for the MPL Domain Address > with scope 3 for 802.15.4-based networks. The PAN ID is the fundamental > identifier that groups nodes in a PAN and therefore forms a clear zone for > multicast dissemination. Anything else is going to be an unclear superset > or subset. > > The language can get a bit circular so I think the statement for an > 802.15.4-based network is: > > "An MPL Domain associated with an MPL Domain Address of ALL_MPL_FORWARDERS > with a scope value of 3 (Realm-Local) is a scope zone within which the set > of 802.15.4 MPL Interfaces subscribing to that MPL Domain Address all have > the same PAN ID." > > I feel that MPL should be defined strictly in terms of how it handles different scopes and that the definition of scope 0x03 belongs in the appropriate IP-over-foo RFC or an update to same. There's always the outside possibility that another (non 15.4) mesh data link may emerge in the future. Also, as I suggested in an earlier email, the PAN ID based definition should make it clear we're talking about a set of interfaces that share physical connectivity as well as PAN ID. It should be possible to create an MPL Domain from traditional links (e.g. ethernet) that only uses scope 0x02 messages. > Compare with a similar statement for Admin-Local scope: > > "An MPL Domain associated with an MPL Domain Address with a scope value of > 4 (Admin-Local) is a scope zone within which the set of MPL Interfaces > subscribing to that MPL Domain Address is administratively configured." > > With the definition of scope 0x03, RFC 4007 requires a scope 0x04 zone to fully encompass any scope 0x03 zones that fall within its boundaries. It seems the best use of Admin-Local scope by MPL may be to aggregate mesh and traditional links into larger MPL Domains. Robert > > > On 15/10/2013 18:17, Kerry Lynn wrote: > > On Tue, Oct 15, 2013 at 12:33 PM, Don Sturek wrote: > >> Hi Michael, >> >> We should leave in scope 4 for use in administratively scoped domains. >> This would allow applications to define specific multicast addresses using >> scope 4 without having to go through the trouble to "un-reserve" >> adminstrative scope. >> >> Also, I am in favor of Ralph's proposal on using PAN ID for MPL scope 3. >> I don't see how any automatic configuration could take place if we can't >> identify a concrete identifier for the scope. The other alternative (and >> to be honest the one I thought we were going to use) is DODAG ID. This >> would allow your scenario where a subnet of different link technologies >> could support MPL domain 3. >> >> If a host can be present simultaneously in more than one DODAG then > we run afoul of normative RFC 4007 behavior: > > Zones of the same scope cannot overlap; i.e., they can have no links > or interfaces in common. > > Link-local scope is essentially defined by a combination of link layer > connectivity and routing behavior. > > Link-local scope is defined by link layer connectivity only, surely? > Where does routing behavior come into it?<.RCC> > > To be more accurate, the boundary of a link-local zone is defined by the lack of forwarding. RFC 4291 states: Routers must not forward any packets with Link-Local source or destination addresses to other links. Thus, Link-Local scope zones may exist on adjacent links but they will be disjoint. > > I believe we need something similar > in order to automatically define scope 0x03. To the extent that we need > scope 0x03 at all, I think it's to emulate classic link-local behavior in a > mesh. > > I agree with this, however it is not always clear what constitutes > "the mesh". There has to be one thing in common with all the interfaces > which participate in the mesh; PAN ID is an obvious choice and clearly sets > the zone of scope 3 in this case. DODAG ID is another possibility but MPL > propagation through MPL forwarders is not rooted at a single node so it is > more like RPL-P2P in some respects. > > My concern here is the case of overlapping DODAGs. We cannot have overlapping zones of the same scope. In practice, I think the definition of scope 0x03 using PAN ID for 802.15.4 networks is transparent at layer 3. It's a requirement that the node must filter by PAN ID at layer 2 and again this definition should be part of the IP-over-foo specification. > There are only so many ways that meshes can be distinguished: > either by location, frequency, or code diversity (assuming any two of > three overlap). In Ralph's example, he assumes location and frequency > overlap. In Michael's example, I suspect he assumes location and PAN > ID overlap. > > Finally, we may need to constrain Ralph's definition a bit further and > define an 802.15.4 scope 0x03 zone as a set of interfaces that share > a common PAN coordinator and PAN ID. > > I think that statement is tautological as the PAN coordinator > dictates the PAN ID therefore must share the PAN ID. Therefore this reduces > to sharing a PAN ID. > > OK, I was trying to prevent the interpretation that two PANs on opposite sides of the earth with the same PAN ID will be in the same scope zone. There's no doubt a better way to state it. BTW, I hope there's a method for two PAN coordinators on opposite sides of a wall to ensure that they pick different PAN IDs? > > -K- > > > Don >> >> >> On 10/15/13 8:59 AM, "Michael Richardson" wrote: >> >> > >> > >> >Don Sturek wrote: >> > > At some point, I think it would be interesting to see multicast >> > > forwarding rules in a mesh network where flooding is not used. I >> >would >> > > see that case as the example of where scope 4 would be used. >> > >> >okay, so when we write a new protocol, we can specify this. >> >Why have the code there to support scope-4 when there is no other >> >behaviour? >> > >> > > I know that a lot of work is needed in defining the rules for >> > > forwarding when flooding is not used but in a large mesh network, >> >there >> > > would be a lot of benefit to such a feature. >> > >> >Do you agree with me about PANID vs Subnet or not? >> > >> >-- >> >Michael Richardson , Sandelman Software Works >> > >> > >> >_______________________________________________ >> >Roll mailing list >> >Roll@ietf.org >> >https://www.ietf.org/mailman/listinfo/roll >> >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> > > > > _______________________________________________ > Roll mailing listRoll@ietf.orghttps://www.ietf.org/mailman/listinfo/roll > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > --047d7bdc8e862e37f404e8d18c68 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Robert,

Comments inline...


On Tue, Oc= t 15, 2013 at 6:50 PM, Robert Cragie <robert.cragie@gridmerge.co= m> wrote:
=20 =20 =20
Hi Kerry,

Comments inline.

I am in favour of using PAN ID as the basis for the MPL Domain Address with scope 3 for 802.15.4-based networks. The PAN ID is the fundamental identifier that groups nodes in a PAN and therefore forms a clear zone for multicast dissemination. Anything else is going to be an unclear superset or subset.

The language can get a bit circular so I think the statement for an 802.15.4-based network is:

"An MPL Domain associated with an MPL Domain Address of ALL_MPL_FORWARDERS with a scope value of 3 (Realm-Local) is a scope zone within which the set of 802.15.4 MPL Interfaces subscribing to that MPL Domain Address all have the same PAN ID."

<kel>
I feel that MPL should be de= fined strictly in terms of how it handles different scopes and that the
=
definition of scope 0x03 belongs in the appropriate IP-over-foo = RFC or an update to same.
There's always the outside possibility that another (non 15.= 4) mesh data link may emerge in
the future.=A0 Also, as I sug= gested in an earlier email, the PAN ID based definition should make
it c= lear we're talking about a set of interfaces that share physical connec= tivity as well as PAN ID.

It should be possible to create an MPL Domain from tradition= al links (e.g. ethernet) that only uses
scope 0x02 messages.
</kel>
=A0
Compare with a similar statement for Admin-Local scope:

"An MPL Domain associated with an MPL Domain Address with a scope value of 4 (Admin-Local) is a scope zone within which the set of MPL Interfaces subscribing to that MPL Domain Address is administratively configured."

<kel>
With the definiti= on of scope 0x03, RFC 4007 requires a scope 0x04 zone to fully encompass an= y
scope 0x03 zones that fall within its boundaries.=A0 It seems the best= use of Admin-Local scope by
MPL may be to aggregate mesh and traditional links into larger MPL Domains.=
</kel>

Robert


On 15/10/2013 18:17, Kerry Lynn wrote:
On Tue, Oct 15, 2013 at 12:33 PM, Don Sturek <d.stur= ek@att.net> wrote:
Hi Michael,

We should leave in scope 4 for use in administratively scoped domains.
This would allow applications to define specific multicast addresses using
scope 4 without having to go through the trouble to "un-reserve"
adminstrative scope.

Also, I am in favor of Ralph's proposal on using PAN ID for MPL scope 3.
I don't see how any automatic configuration could take place if we can't
identify a concrete identifier for the scope. =A0The other alternative (and
to be honest the one I thought we were going to use) is DODAG ID. =A0 This
would allow your scenario where a subnet of different link technologies
could support MPL domain 3.

If a host can be present simultaneously in more than one DODAG then
we run afoul of normative RFC 4007 behavior:

=A0 Zones of the same scope cannot overlap; i.e., they can have no links
=A0 or interfaces in common.

Link-local scope is essentially defined by a combination of link layer
connectivity and routing behavior.
<RCC>Link-local scope is defined by link layer connectivity only, surely? Where does routing behavior come into it?<.RCC>
<kel>
T= o be more accurate, the boundary of a link-local zone is defined by the lac= k of
forwarding.=A0 RFC 4291 states:

=A0 Routers mu= st not forward any packets with Link-Local source or
=A0 dest= ination addresses to other links.

Thus, Link-L= ocal scope zones may exist on adjacent links but they will be disjoint.
</kel>

I believe we need something similar
in order to automatically define scope 0x03.=A0 To the extent that we need
scope 0x03 at all, I think it's to emulate classic link-local behavior in a
mesh.
<RCC>I agree with this, however it is not always clear what constitutes "the mesh". There has to be one thing in common w= ith all the interfaces which participate in the mesh; PAN ID is an obvious choice and clearly sets the zone of scope 3 in this case. DODAG ID is another possibility but MPL propagation through MPL forwarders is not rooted at a single node so it is more like RPL-P2P in some respects.</RCC>

<kel>
My concern here is the case of overlapping DODA= Gs.=A0 We cannot have overlapping
zones of the same scope.
In practice, I think the definition of scope 0x03 using PAN = ID for 802.15.4 networks
is transparent at layer 3.=A0 It's a requir= ement that the node must filter by PAN ID at
layer 2 and agai= n this definition should be part of the IP-over-foo specification.
</kel>
There are only so many ways that meshes can be distinguished:
either by location, frequency, or code diversity (assuming any two of
three overlap).=A0 In Ralph's example, he assumes locatio= n and frequency
overlap.=A0 In Michael's example, I suspect he assumes location and PAN
ID overlap.

Finally, we may need to constrain Ralph's definition a bit further and
define an 802.15.4=A0 scope 0x03 zone as a set of interfaces that share
a common PAN coordinator and PAN ID.
<RCC>I think that statement is tautological as the PAN coordinator dictates the PAN ID therefore must share the PAN ID. Therefore this reduces to sharing a PAN ID.</RCC>

<kel>
O= K, I was trying to prevent the interpretation that two PANs on opposite sid= es
of the earth with the same PAN ID will be in the same scope zone= .=A0 There's no
doubt a better way to state it.

BT= W, I hope there's a method for two PAN coordinators on opposite sides o= f
a wall to ensure that they pick different PAN IDs?
</kel&g= t;

-K-


Don


On 10/15/13 8:59 AM, "Michael Richardson" <<= a href=3D"mailto:mcr%2Bietf@sandelman.ca" target=3D"_blank">mcr+ietf@sandel= man.ca> wrote:

>
>
>Don Sturek <d.sturek@att.net> wrote:
> =A0 =A0> At some point, I think it would be interesting to see multicast
> =A0 =A0> forwarding rules in a mesh network where flooding is not used. =A0I
>would
> =A0 =A0> see that case as the example of where scope 4 would be used.
>
>okay, so when we write a new protocol, we can specify this.
>Why have the code there to support scope-4 when there is no other
>behaviour?
>
> =A0 =A0> I know that a lot of work is needed in defining the rules for
> =A0 =A0> forwarding when flooding is not used but in a large mesh network,
>there
> =A0 =A0> would be a lot of benefit to such a feature.
>
>Do you agree with me about PANID vs Subnet or not? >
>--
>Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
>
>
>_______________________________________________ >Roll mailing list
>Ro= ll@ietf.org
>https://www.ietf.org/mailman/listinfo/roll


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



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


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


--047d7bdc8e862e37f404e8d18c68-- From robert.cragie@gridmerge.com Wed Oct 16 01:38: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 E16C221F9C53 for ; Wed, 16 Oct 2013 01:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1t0Re2VhbQFq for ; Wed, 16 Oct 2013 01:37:57 -0700 (PDT) Received: from mail41.extendcp.co.uk (mail41.extendcp.co.uk [79.170.44.41]) by ietfa.amsl.com (Postfix) with ESMTP id 0FDF721F9C6B for ; Wed, 16 Oct 2013 01:37:55 -0700 (PDT) Received: from [94.117.18.14] (helo=[10.38.244.62]) by mail41.extendcp.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) id 1VWMc5-0000G8-8m; Wed, 16 Oct 2013 09:37:53 +0100 Message-ID: <525E5064.4050109@gridmerge.com> Date: Wed, 16 Oct 2013 09:37:56 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Kerry Lynn , Routing Over Low power and Lossy networks References: <3599.1381852752@sandelman.ca> <525DC6C9.2010808@gridmerge.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000404050402040503090905" X-Authenticated-As: robert.cragie@gridmerge.com Subject: Re: [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert.cragie@gridmerge.com, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 08:38:02 -0000 This is a cryptographically signed message in MIME format. --------------ms000404050402040503090905 Content-Type: multipart/alternative; boundary="------------010304030706090105060503" This is a multi-part message in MIME format. --------------010304030706090105060503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Kerry, More comments inline, bracketed by . In summary - I=20 generally agree with what you say. There needs to be a decision on where = to write the IP-over-foo scope 3 definition, especially for=20 IP-over-802.15.4. Robert On 16/10/2013 02:23, Kerry Lynn wrote: > Hi Robert, > > Comments inline... > > > On Tue, Oct 15, 2013 at 6:50 PM, Robert Cragie=20 > > wrot= e: > > Hi Kerry, > > Comments inline. > > I am in favour of using PAN ID as the basis for the MPL Domain > Address with scope 3 for 802.15.4-based networks. The PAN ID is > the fundamental identifier that groups nodes in a PAN and > therefore forms a clear zone for multicast dissemination. Anything > else is going to be an unclear superset or subset. > > The language can get a bit circular so I think the statement for > an 802.15.4-based network is: > > "An MPL Domain associated with an MPL Domain Address of > ALL_MPL_FORWARDERS with a scope value of 3 (Realm-Local) is a > scope zone within which the set of 802.15.4 MPL Interfaces > subscribing to that MPL Domain Address all have the same PAN ID." > > > I feel that MPL should be defined strictly in terms of how it handles=20 > different scopes and that the > definition of scope 0x03 belongs in the appropriate IP-over-foo RFC or = > an update to same. In principle, I agree. Practically, what is the best way to achieve this?= 1. A 6lo-led RFC for all IP-over-foo 2. Updates to all the existing IP-over-foo RFCs 3. Lots of short RFCs for each IP-over-foo 4. Start with 802.15.4 example in MPL I think all are reasonable and there are bound to be other approaches=20 which are reasonable as well. I think as already discussed it comes down = to (3) or (4) to get draft-ietf-roll-trickle-mcast finished as quickly=20 as possible. > There's always the outside possibility that another (non 15.4) mesh=20 > data link may emerge in > the future. In this case, it should be clear that a statement regarding scope=20 3 is included in the corresponding IP-over-foo RFC > Also, as I suggested in an earlier email, the PAN ID based definition=20 > should make > it clear we're talking about a set of interfaces that share physical=20 > connectivity as well as PAN ID. See below > > It should be possible to create an MPL Domain from traditional links=20 > (e.g. ethernet) that only uses > scope 0x02 messages. It is now, however the MPL Domain will only reach one hop. We did=20 discuss at length some time ago in the ZigBee IP community the merits of = using scope 2 vs. scope 3 for propagating multicasts. The outcome was=20 that both are feasible solutions but using scope 2 conceptually means=20 multiple overlapping one-hop MPL domains in some arbitrary zone. To=20 propagate multicasts in this arbitrary zone would mean administratively=20 configuring MPL forwarder behaviour to ensure propagation. In practice,=20 the difference is minimal but architecturally it is quite different > > > Compare with a similar statement for Admin-Local scope: > > "An MPL Domain associated with an MPL Domain Address with a scope > value of 4 (Admin-Local) is a scope zone within which the set of > MPL Interfaces subscribing to that MPL Domain Address is > administratively configured." > > > With the definition of scope 0x03, RFC 4007 requires a scope 0x04 zone = > to fully encompass any > scope 0x03 zones that fall within its boundaries. It seems the best=20 > use of Admin-Local scope by > MPL may be to aggregate mesh and traditional links into larger MPL=20 > Domains. > I agree > > Robert > > > On 15/10/2013 18:17, Kerry Lynn wrote: >> On Tue, Oct 15, 2013 at 12:33 PM, Don Sturek > > wrote: >> >> Hi Michael, >> >> We should leave in scope 4 for use in administratively scoped >> domains. >> This would allow applications to define specific multicast >> addresses using >> scope 4 without having to go through the trouble to "un-reserv= e" >> adminstrative scope. >> >> Also, I am in favor of Ralph's proposal on using PAN ID for >> MPL scope 3. >> I don't see how any automatic configuration could take place >> if we can't >> identify a concrete identifier for the scope. The other >> alternative (and >> to be honest the one I thought we were going to use) is DODAG >> ID. This >> would allow your scenario where a subnet of different link >> technologies >> could support MPL domain 3. >> >> If a host can be present simultaneously in more than one DODAG the= n >> we run afoul of normative RFC 4007 behavior: >> >> Zones of the same scope cannot overlap; i.e., they can have no >> links >> or interfaces in common. >> >> Link-local scope is essentially defined by a combination of link >> layer >> connectivity and routing behavior. > Link-local scope is defined by link layer connectivity only, > surely? Where does routing behavior come into it?<.RCC> > > > To be more accurate, the boundary of a link-local zone is defined by=20 > the lack of > forwarding. RFC 4291 states: > > Routers must not forward any packets with Link-Local source or > destination addresses to other links. > > Thus, Link-Local scope zones may exist on adjacent links but they will = > be disjoint. > Exactly - see earlier description of link-local MPL Domain based=20 on scope 2 > > >> I believe we need something similar >> in order to automatically define scope 0x03. To the extent that >> we need >> scope 0x03 at all, I think it's to emulate classic link-local >> behavior in a >> mesh. > I agree with this, however it is not always clear what > constitutes "the mesh". There has to be one thing in common with > all the interfaces which participate in the mesh; PAN ID is an > obvious choice and clearly sets the zone of scope 3 in this case. > DODAG ID is another possibility but MPL propagation through MPL > forwarders is not rooted at a single node so it is more like > RPL-P2P in some respects. > > > My concern here is the case of overlapping DODAGs. We cannot have=20 > overlapping > zones of the same scope. > > In practice, I think the definition of scope 0x03 using PAN ID for=20 > 802.15.4 networks > is transparent at layer 3. It's a requirement that the node must=20 > filter by PAN ID at > layer 2 and again this definition should be part of the IP-over-foo=20 > specification. > It's a tricky one this. I can sort of see the sense in wanting to=20 limit propagation of a multicast to those nodes which have something in=20 common with regard to routing. So in this sense, a DODAG ID would make=20 sense. In that case, we have to rethink the idea of a MPL Domain being a = scope zone and I'm not sure we want to go down that road again? So I do=20 agree that if we are using scope zones, it has to be transparent at=20 layer 3. >> There are only so many ways that meshes can be distinguished: >> either by location, frequency, or code diversity (assuming any two= of >> three overlap). In Ralph's example, he assumes location and >> frequency >> overlap. In Michael's example, I suspect he assumes location and = PAN >> ID overlap. >> >> Finally, we may need to constrain Ralph's definition a bit >> further and >> define an 802.15.4 scope 0x03 zone as a set of interfaces that sh= are >> a common PAN coordinator and PAN ID. > I think that statement is tautological as the PAN coordinator > dictates the PAN ID therefore must share the PAN ID. Therefore > this reduces to sharing a PAN ID. > > > OK, I was trying to prevent the interpretation that two PANs on=20 > opposite sides > of the earth with the same PAN ID will be in the same scope zone. =20 > There's no > doubt a better way to state it. > > BTW, I hope there's a method for two PAN coordinators on opposite sides= of > a wall to ensure that they pick different PAN IDs? > OK, I see where you are coming from and I have no problem with the = extra text for clarity purposes. However, the definition of PAN and thus = PAN ID should preclude this. It is not allowed for overlapping PANs to=20 have the same PAN ID and 802.15.4 has mechanisms to prevent and fix=20 this. Given the definition of a zone is a connected region of topology,=20 this means that two PANs on opposite sides of the earth with the same=20 PAN ID cannot be in the same scope zone as they are not connected. > >> >> -K- >> >> >> Don >> >> >> On 10/15/13 8:59 AM, "Michael Richardson" >> > wrote= : >> >> > >> > >> >Don Sturek > wrote= : >> > > At some point, I think it would be interesting to see >> multicast >> > > forwarding rules in a mesh network where flooding is >> not used. I >> >would >> > > see that case as the example of where scope 4 would be >> used. >> > >> >okay, so when we write a new protocol, we can specify this. >> >Why have the code there to support scope-4 when there is no >> other >> >behaviour? >> > >> > > I know that a lot of work is needed in defining the >> rules for >> > > forwarding when flooding is not used but in a large >> mesh network, >> >there >> > > would be a lot of benefit to such a feature. >> > >> >Do you agree with me about PANID vs Subnet or not? >> > >> >-- >> >Michael Richardson > >, Sandelman Software Works >> > >> > >> >_______________________________________________ >> >Roll mailing list >> >Roll@ietf.org >> >https://www.ietf.org/mailman/listinfo/roll >> >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> >> >> >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > --------------010304030706090105060503 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Kerry,

More comments inline, bracketed by <RCC2></RCC2>. In summary - I generally agree with what you say. There needs to be a decision on where to write the IP-over-foo scope 3 definition, especially for IP-over-802.15.4.

Robert

On 16/10/2013 02:23, Kerry Lynn wrote:=
Hi Robert,

Comments inline...


On Tue, Oct 15, 2013 at 6:50 PM,= Robert Cragie <robert.cragie@gridmerge.com>= wrote:
Hi Kerry,
Comments inline.

I am in favour of using PAN ID as the basis for the MPL Domain Address with scope 3 for 802.15.4-based networks. The PAN ID is the fundamental identifier that groups nodes in a PAN and therefore forms a clear zone for multicast dissemination. Anything else is going to be an unclear superset or subset.
The language can get a bit circular so I think the statement for an 802.15.4-based network is:

"An MPL Domain associated with an MPL Domain Address of ALL_MPL_FORWARDERS with a scope value of 3 (Realm-Local) is a scope zone within which the set of 802.15.4 MPL Interfaces subscribing to that MPL Domain Address all have the same PAN ID."

<kel>
I feel that MPL should be defined strictly in terms of how it handles different scopes and that the
definition of scope 0x03 belongs in the appropriate IP-over-foo RFC or an update to same.
<RCC2>
In principle, I agree. Practically, what is the best way to achieve this?

  1. A 6lo-led RFC for all IP-over-foo
  2. Updates to all the existing IP-over-foo RFCs
  3. Lots of short RFCs for each IP-over-foo
  4. Start with 802.15.4 example in MPL

I think all are reasonable and there are bound to be other approaches which are reasonable as well. I think as already discussed it comes down to (3) or (4) to get draft-ietf-roll-trickle-mcast finished as quickly as possible.
</RCC2>

There's always the outside possibility that another (non 15.4) mesh data link may emerge in
the future.
<RCC2>In this case, it should be clear that a statement regarding scope 3 is included in the corresponding IP-over-foo RFC</RCC2>
Also, as I suggested in an earlier email, the PAN ID based definition should make
it clear we're talking about a set of interfaces that share physical connectivity as well as PAN ID.
<RCC2>See below</RCC2>

It should be possible to create an MPL Domain from traditional links (e.g. ethernet) that only uses
scope 0x02 messages.
<RCC2>It is now, however the MPL Domain will only reach one hop. We did discuss at length some time ago in the ZigBee IP community the merits of using scope 2 vs. scope 3 for propagating multicasts. The outcome was that both are feasible solutions but using scope 2 conceptually means multiple overlapping one-hop MPL domains in some arbitrary zone. To propagate multicasts in this arbitrary zone would mean administratively configuring MPL forwarder behaviour to ensure propagation. In practice, the difference is minimal but architecturally it is quite different</RCC2>
</kel>
 
Compare with= a similar statement for Admin-Local scope:

"An MPL Domain associated with an MPL Domain Address with a scope value of 4 (Admin-Local) is a scope zone within which the set of MPL Interfaces subscribing to that MPL Domain Address is administratively configured."

<kel>
With the definition of scope 0x03, RFC 4007 requires a scope 0x04 zone to fully encompass any
scope 0x03 zones that fall within its boundaries. = It seems the best use of Admin-Local scope by
MPL may be to aggregate mesh and traditional links into larger MPL Domains.
</kel>
<RCC2>I agree</RCC>

Robert


On 15/10/2013 18:17, Kerry Lynn wrote:
On Tue, Oct 15, 2013 at 12:33 PM= , Don Sturek <d.sturek@att.net><= /span> wrote:
Hi Michael,

We should leave in scope 4 for use in administratively scoped domains.
This would allow applications to define specific multicast addresses using
scope 4 without having to go through the trouble to "un-reserve"
adminstrative scope.

Also, I am in favor of Ralph's proposal on using PAN ID for MPL scope 3.
I don't see how any automatic configuration could take place if we can't
identify a concrete identifier for the scope.  The other alternative (and to be honest the one I thought we were going to use) is DODAG ID.   This would allow your scenario where a subnet of different link technologies
could support MPL domain 3.

If a host can be present simultaneously in more than one DODAG then
we run afoul of normative RFC 4007 behavior:

  Zones of the same scope cannot overlap; i.e., they can have no links
=
  or interfaces in common.

Link-local scope is essentially defined by a combination of link layer connectivity and routing behavior.
<RCC>Link-local scope is defined by link layer connectivity only, surely? Where does routing behavior come into it?<.RCC>

<kel>
To be more accurate, the boundary of a link-local zone is defined by the lack of
forwarding.  RFC 4291 states:

  Routers must not forward any packets with Link-Local source or
  destination addresses to other links.

Thus, Link-Local scope zones may exist on adjacent links but they will be disjoint.
</kel>
<RCC2>Exactly - see earlier description of link-local MPL Domain based on scope 2</RCC2>

I believe we need something similar in order to automatically define scope 0x03.  To the extent that we need scope 0x03 at all, I think it's to emulate classic link-local behavior in a<= br> mesh.
<RCC>I agree with this, however it is not always clear what constitutes "the mesh". There has to be one thing in common with all the interfaces which participate in the mesh; PAN ID is an obvious choice and clearly sets the zone of scope 3 in this case. DODAG ID is another possibility but MPL propagation through MPL forwarders is not rooted at a single node so it is more like RPL-P2P in some respects.</RCC>

<kel>
My concern here is the case of overlapping DODAGs.&n= bsp; We cannot have overlapping
zones of the same scope.

In practice, I think the definition of scope 0x03 using PAN ID for 802.15.4 networks
is transparent at layer 3.  It's a requirement tha= t the node must filter by PAN ID at
layer 2 and again this definition should be part of the IP-over-foo specification.
</kel>
<RCC2>It's a tricky one this. I can sort of see the sense in wanting to limit propagation of a multicast to those nodes which have something in common with regard to routing. So in this sense, a DODAG ID would make sense. In that case, we have to rethink the idea of a MPL Domain being a scope zone and I'm not sure we want to go down that road again? So I do agree that if we are using scope zones, it has to be transparent at layer 3.</RCC2?
There are only so many ways that meshes can be distinguished:
either by location, frequency, or code diversity (assuming any two of
three overlap).  In Ralph's example,= he assumes location and frequency
overlap.  In Michael's example, I= suspect he assumes location and PAN
ID overlap.

Finally, we may need to constrain Ralph's definition a bit further and
define an 802.15.4  scope 0x03 zone = as a set of interfaces that share
a common PAN coordinator and PAN ID.
<RCC>I think that statement is tautological as the PAN coordinator dictates the PAN ID therefore must share the PAN ID. Therefore this reduces to sharing a PAN ID.</RCC>

<kel>
OK, I was trying to prevent the interpretation that two PANs on opposite sides
of the earth with the same PAN ID will be in the same scope zone.  There's no
doubt a better way to state it.

BTW, I hope there's a method for two PAN coordinators on opposite sides of
a wall to ensure that they pick different PAN IDs?
</kel>
<RCC2>OK, I see where you are coming from and I have no problem with the extra text for clarity purposes. However, the definition of PAN and thus PAN ID should preclude this. It is not allowed for overlapping PANs to have the same PAN ID and 802.15.4 has mechanisms to prevent and fix this. Given the definition of a zone is a connected region of topology, this means that two PANs on opposite sides of the earth with the same PAN ID cannot be in the same scope zone as they are not connected.  </RCC2>

-K-


Don


On 10/15/13 8:59 AM, "Michael Richardson" <mcr+ietf@sandel= man.ca> wrote:

>
>
>Don Sturek <d.sturek@att.ne= t> wrote:
>    > At some poin= t, I think it would be interesting to see multicast
>    > forwarding r= ules in a mesh network where flooding is not used.  I
>would
>    > see that cas= e as the example of where scope 4 would be used.
>
>okay, so when we write a new protocol, we can specify this.
>Why have the code there to support scope-4 when there is no other
>behaviour?
>
>    > I know that = a lot of work is needed in defining the rules for
>    > forwarding w= hen flooding is not used but in a large mesh network,
>there
>    > would be a l= ot of benefit to such a feature.
>
>Do you agree with me about PANID vs Subnet or not?
>
>--
>Michael Richardson <mcr+IETF@sandel= man.ca>, Sandelman Software Works
>
>
>____________________________= ___________________
>Roll mailing list
>Roll@ietf.org
>https://www.iet= f.org/mailman/listinfo/roll


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



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


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



--------------010304030706090105060503-- --------------ms000404050402040503090905 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 Fw0xMzEwMTYwODM3NTZaMCMGCSqGSIb3DQEJBDEWBBQfnmHCrr6+p7tg/mw6cKydEkZoWzBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEFwxUNvELajLmHIeX9p072YwgbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9m MA0GCSqGSIb3DQEBAQUABIIBAD2c5tgh1mcjsIKKpWaAoMZ4xKMsA+X3OwYFhFoxFs1BDR+a 3s1sCPYPJmoqNqYpqleldOWLkiV/H91tqfQ/S+BzWTxra60W3Hb9gDFunbHBf7SoXlz78KQE /TAHOuI53af309Py/Ab9eMKQ5544heXtwLLZyJ1QHfkJjTd8uMjEXfKdoKej3xEx3FbxsrGr JQDc086ycDACyw3Wlz8o+ytaQ33FlrfAJcccR1zj6SOSKd/uxC/d4szEmWc56vW+5+ZR4htM l7ec/ycMD5pcW8JECg5Zwyqcp06QmqKPpC4z7HToCrdZHgdHrnxuDSAoLgOD/114gz/fCNHy s1XlnGsAAAAAAAA= --------------ms000404050402040503090905-- From kerlyn2001@gmail.com Wed Oct 16 10:04:35 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9958A11E8109 for ; Wed, 16 Oct 2013 10:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5IrccXKzzf-y for ; Wed, 16 Oct 2013 10:04:34 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id 93B8A11E822D for ; Wed, 16 Oct 2013 10:04:33 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id cb5so7324493wib.4 for ; Wed, 16 Oct 2013 10:04:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=U9o/XcqDl19mS5k/k4Op8ojtO5bc+oBUQsBS1n6iz2M=; b=wypHiUvwTucsrqFkrHBjLoCW9kMl0oyTdAps8D5YlMWgpDVrVFguI/PJmwFaILcMk2 yi/CDYSZBuOHkQfxx54svcAbTbn+Tu+6aZZ6WEp5og+RpeSQyWS5Q/yoVygbz5287KBl /i1ZyimHHO8TQsctC/EhvnSIrqE6lLPHsZ+s3wBFKkx3uI3mb6nh/5VYFK41irkaM2Vt XU5Ua9WEbt8x4GH26Iana+KshfnR7jCLKPN1gcJdikf8r6HznJ03W+3ajUc+cXlJPIqk oXUdg7RPfszo4DlYC6csUxERgcyixgEe70cYKpWoi9HngwUDXQJV6hfTcTmScXimT/ml J1iw== MIME-Version: 1.0 X-Received: by 10.180.73.40 with SMTP id i8mr25173874wiv.37.1381943072523; Wed, 16 Oct 2013 10:04:32 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.216.227.132 with HTTP; Wed, 16 Oct 2013 10:04:32 -0700 (PDT) In-Reply-To: <525E5064.4050109@gridmerge.com> References: <3599.1381852752@sandelman.ca> <525DC6C9.2010808@gridmerge.com> <525E5064.4050109@gridmerge.com> Date: Wed, 16 Oct 2013 13:04:32 -0400 X-Google-Sender-Auth: oUfDyrK4G3UDK8U-e9cXTaUJGK4 Message-ID: From: Kerry Lynn To: Robert Cragie Content-Type: multipart/alternative; boundary=f46d0438907df00ac304e8deb11e Cc: Routing Over Low power and Lossy networks Subject: Re: [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 17:04:35 -0000 --f46d0438907df00ac304e8deb11e Content-Type: text/plain; charset=ISO-8859-1 Hi Robert, My responses bracketed by ... On Wed, Oct 16, 2013 at 4:37 AM, Robert Cragie wrote: > Hi Kerry, > > More comments inline, bracketed by . In summary - I generally > agree with what you say. There needs to be a decision on where to write the > IP-over-foo scope 3 definition, especially for IP-over-802.15.4. > > See below > Robert > > > On 16/10/2013 02:23, Kerry Lynn wrote: > > Hi Robert, > > Comments inline... > > > On Tue, Oct 15, 2013 at 6:50 PM, Robert Cragie < > robert.cragie@gridmerge.com> wrote: > >> Hi Kerry, >> >> Comments inline. >> >> I am in favour of using PAN ID as the basis for the MPL Domain Address >> with scope 3 for 802.15.4-based networks. The PAN ID is the fundamental >> identifier that groups nodes in a PAN and therefore forms a clear zone for >> multicast dissemination. Anything else is going to be an unclear superset >> or subset. >> >> The language can get a bit circular so I think the statement for an >> 802.15.4-based network is: >> >> "An MPL Domain associated with an MPL Domain Address of >> ALL_MPL_FORWARDERS with a scope value of 3 (Realm-Local) is a scope zone >> within which the set of 802.15.4 MPL Interfaces subscribing to that MPL >> Domain Address all have the same PAN ID." >> >> > I feel that MPL should be defined strictly in terms of how it handles > different scopes and that the > definition of scope 0x03 belongs in the appropriate IP-over-foo RFC or > an update to same. > > > In principle, I agree. Practically, what is the best way to achieve this? > > > 1. A 6lo-led RFC for all IP-over-foo > 2. Updates to all the existing IP-over-foo RFCs > 3. Lots of short RFCs for each IP-over-foo > 4. Start with 802.15.4 example in MPL > > I think Ralph's approach is the correct one. His draft-droms-6man-multicast-scopes belongs in 6man as it re-defines a reserved code point in the IPv6 addressing architecture. It nominally updates RFC 4291 but should probably also update RFC 4007 as these RFCs are in conflict regarding the automatic definition of scope 0x03. Ralph's draft says that scope 0x03 is defined on a network technology basis and should be published in an RFC. Since 6LoWPAN is trying to close down, I think a (short) update to RFC 4944 could be done in 6lo. Other 6lo drafts should define scope 0x03 (or not) for their particular technology. I think scope 0x03 is unnecessary for any technology that doesn't have a hidden node issue and probably not necessary for all wireless data links. MPL should be clear of technology discussion and just define forwarding behavior on a scope-by-scope basis. For example, *if* it is possible to create a MPL "Super-Domain" from scope 2 domains, I expect the behavior would be to retransmit (or not, as determined by the Trickle Algorithm) on all active MPL interfaces but use a new source address at each hop. You then have a set of connected one-hop tunnels and the seed and sequence data is preserved in the inner header. For scope > 2 I expect the MPL Data packet would be re-transmitted (forwarded) using the original (received) source address. Is it sufficient to just reference Ralph's draft when scope 0x03 is discussed in MPL and thus decouple the two discussions? I think all are reasonable and there are bound to be other approaches which > are reasonable as well. I think as already discussed it comes down to (3) > or (4) to get draft-ietf-roll-trickle-mcast finished as quickly as possible. > > > > There's always the outside possibility that another (non 15.4) mesh > data link may emerge in > the future. > > In this case, it should be clear that a statement regarding scope 3 > is included in the corresponding IP-over-foo RFC > > Ralph's draft makes this clear. > Also, as I suggested in an earlier email, the PAN ID based definition > should make > it clear we're talking about a set of interfaces that share physical > connectivity as well as PAN ID. > > See below > > > It should be possible to create an MPL Domain from traditional links (e.g. > ethernet) that only uses > scope 0x02 messages. > > It is now, however the MPL Domain will only reach one hop. We did > discuss at length some time ago in the ZigBee IP community the merits of > using scope 2 vs. scope 3 for propagating multicasts. The outcome was that > both are feasible solutions but using scope 2 conceptually means multiple > overlapping one-hop MPL domains in some arbitrary zone. To propagate > multicasts in this arbitrary zone would mean administratively configuring > MPL forwarder behaviour to ensure propagation. In practice, the difference > is minimal but architecturally it is quite different > I think it would have been better to use the term "MPL zone", especially since an MPL Domain is currently defined to be an RFC 4007 scope zone. Since scope zones cannot overlap, the same must be true for MPL Domains. However, I see you point when considering MPL Forwarders that only have a single 802.15.4 interface. It seems they must function like a router-on-a-stick that forwards between VLANs on an ethernet link. > > > > >> Compare with a similar statement for Admin-Local scope: >> >> "An MPL Domain associated with an MPL Domain Address with a scope value >> of 4 (Admin-Local) is a scope zone within which the set of MPL Interfaces >> subscribing to that MPL Domain Address is administratively configured." >> >> > With the definition of scope 0x03, RFC 4007 requires a scope 0x04 zone > to fully encompass any > scope 0x03 zones that fall within its boundaries. It seems the best use > of Admin-Local scope by > MPL may be to aggregate mesh and traditional links into larger MPL Domains. > > > I agree > > > >> I believe we need something similar >> in order to automatically define scope 0x03. To the extent that we need >> scope 0x03 at all, I think it's to emulate classic link-local behavior in >> a >> mesh. >> >> I agree with this, however it is not always clear what constitutes >> "the mesh". There has to be one thing in common with all the interfaces >> which participate in the mesh; PAN ID is an obvious choice and clearly sets >> the zone of scope 3 in this case. DODAG ID is another possibility but MPL >> propagation through MPL forwarders is not rooted at a single node so it is >> more like RPL-P2P in some respects. >> >> > My concern here is the case of overlapping DODAGs. We cannot have > overlapping > zones of the same scope. > > In practice, I think the definition of scope 0x03 using PAN ID for > 802.15.4 networks > is transparent at layer 3. It's a requirement that the node must filter > by PAN ID at > layer 2 and again this definition should be part of the IP-over-foo > specification. > > > It's a tricky one this. I can sort of see the sense in wanting to > limit propagation of a multicast to those nodes which have something in > common with regard to routing. So in this sense, a DODAG ID would make > sense. In that case, we have to rethink the idea of a MPL Domain being a > scope zone and I'm not sure we want to go down that road again? So I do > agree that if we are using scope zones, it has to be transparent at layer > 3. > In the case of scope 0x02, a zone is defined by physical connectivity and the nodes need not have anything in common w.r.t. routing. I assume it is possible to have multiple DODAGs in the same PAN (please correct me if that is not the case) and that the BR can route between them. When extending our scope 0x02 intuition to scope 0x03 it seems the only dependence on routing behavior is in enabling a response to reach a requester. Put another way, I don't think that source address should be considered in the MPL Forwarder's decision to re-transmit a packet. > There are only so many ways that meshes can be distinguished: >> either by location, frequency, or code diversity (assuming any two of >> three overlap). In Ralph's example, he assumes location and frequency >> overlap. In Michael's example, I suspect he assumes location and PAN >> ID overlap. >> >> Finally, we may need to constrain Ralph's definition a bit further and >> define an 802.15.4 scope 0x03 zone as a set of interfaces that share >> a common PAN coordinator and PAN ID. >> >> I think that statement is tautological as the PAN coordinator >> dictates the PAN ID therefore must share the PAN ID. Therefore this reduces >> to sharing a PAN ID. >> >> > OK, I was trying to prevent the interpretation that two PANs on opposite > sides > of the earth with the same PAN ID will be in the same scope zone. > There's no > doubt a better way to state it. > > BTW, I hope there's a method for two PAN coordinators on opposite sides > of > a wall to ensure that they pick different PAN IDs? > > > OK, I see where you are coming from and I have no problem with the > extra text for clarity purposes. However, the definition of PAN and thus > PAN ID should preclude this. It is not allowed for overlapping PANs to have > the same PAN ID and 802.15.4 has mechanisms to prevent and fix this. Given > the definition of a zone is a connected region of topology, this means that > two PANs on opposite sides of the earth with the same PAN ID cannot be in > the same scope zone as they are not connected. > > I think you are saying that "same PAN ID" is sufficient to automatically define a scope 0x03 zone and I agree with your reasoning. Regards, -K- --f46d0438907df00ac304e8deb11e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Robert,

My responses bracketed by <= ;kel2/>...


On Wed, Oct 16, 2013 at 4:37 AM, Robert Cragie <ro= bert.cragie@gridmerge.com> wrote:
=20 =20 =20
Hi Kerry,

More comments inline, bracketed by <RCC2></RCC2>. In summary - I generally agree with what you say. There needs to be a decision on where to write the IP-over-foo scope 3 definition, especially for IP-over-802.15.4.

<kel2> See below </kel2>
=A0=
Robert


On 16/10/2013 02:23, Kerry Lynn wrote:
Hi Robert,

Comments inline...


On Tue, Oct 15, 2013 at 6:50 PM, Robert Cragie <robert.cragie@gridmerge.com&g= t; wrote:
Hi Kerry,

Comments inline.

I am in favour of using PAN ID as the basis for the MPL Domain Address with scope 3 for 802.15.4-based networks. The PAN ID is the fundamental identifier that groups nodes in a PAN and therefore forms a clear zone for multicast dissemination. Anything else is going to be an unclear superset or subset.

The language can get a bit circular so I think the statement for an 802.15.4-based network is:

"An MPL Domain associated with an MPL Domain Addre= ss of ALL_MPL_FORWARDERS with a scope value of 3 (Realm-Local) is a scope zone within which the set of 802.15.4 MPL Interfaces subscribing to that MPL Domain Address all have the same PAN ID."

<kel>
I feel that MPL should be defined strictly in terms of how it handles different scopes and that the
definition of scope 0x03 belongs in the appropriate IP-over-foo RFC or an update to same.
<RCC2>
In principle, I agree. Practically, what is the best way to achieve this?

  1. A 6lo-led RFC for all IP-over-foo
  2. Updates to all the existing IP-over-foo RFCs
  3. Lots of short RFCs for each IP-over-foo
  4. Start with 802.15.4 example in MPL
<kel2>
I think Ralph's approach is the correct o= ne.=A0 His draft-droms-6man-multicast-scopes belongs in
6man = as it re-defines a reserved code point in the IPv6 addressing architecture.= =A0 It nominally
updates RFC 4291 but should probably also update RFC 4007 as these RFCs are= in conflict
regarding the automatic definition of scope 0x03.

Ralph's draft says that scope 0x03 is defined on a network tec= hnology basis and should be
published in an RFC.=A0 Since 6LoWPAN is trying to close down, I think a (s= hort)=A0 update to RFC
4944 could be done in 6lo.

Othe= r 6lo drafts should define scope 0x03 (or not) for their particular technol= ogy.=A0 I think
scope 0x03 is unnecessary for any technology that doesn't ha= ve a hidden node issue and
probably not necessary for all wir= eless data links.

MPL should be clear of techn= ology discussion and just define forwarding behavior on a
scope-by-scope basis.=A0 For example, *if* it is possible to create a MPL &= quot;Super-Domain"
from scope 2 domains, I expect the be= havior would be to retransmit (or not, as determined
by the Trickle Algo= rithm) on all active MPL interfaces but use a new source address at
each hop.=A0 You then have a set of connected one-hop tunnels and the seed = and sequence
data is preserved in the inner header.

For scope > 2 I expect the MPL Data packet would be re-transmit= ted (forwarded) using
the original (received) source address.=A0 Is it sufficient to j= ust reference Ralph's draft when
scope 0x03 is discussed = in MPL and thus decouple the two discussions?
</kel2>
I think all are reasonable and there are bound to be other approaches which are reasonable as well. I think as already discussed it comes down to (3) or (4) to get draft-ietf-roll-trickle-mcast finished as quickly as possible.
</RCC2>


There's always the outside possibility that anothe= r (non 15.4) mesh data link may emerge in
the future.
<RCC2>In this case, it should be clear that a statement regarding scope 3 is included in the corresponding IP-over-foo RFC</RCC2>

<= ;kel2> Ralph's draft makes this clear. </kel2>
Also, as I suggested in an earlier email, the PAN ID based definition should make
it clear we're talking about a set of interfaces that share physical connectivity as well as PAN ID.
<RCC2>See below</RCC2>


It should be possible to create an MPL Domain from traditional links (e.g. ethernet) that only uses
scope 0x02 messages.
<RCC2>It is now, however the MPL Domain will only reach one hop. We did discuss at length some time ago in the ZigBee IP community the merits of using scope 2 vs. scope 3 for propagating multicasts. The outcome was that both are feasible solutions but using scope 2 conceptually means multiple overlapping one-hop MPL domains in some arbitrary zone. To propagate multicasts in this arbitrary zone would mean administratively configuring MPL forwarder behaviour to ensure propagation. In practice, the difference is minimal but architecturally it is quite different</RCC2>

<kel2>
I think it would h= ave been better to use the term "MPL zone", especially since an M= PL Domain is
currently defined to be an RFC 4007 scope zone.=A0 Since scope zones cannot= overlap, the same
must be true for MPL Domains.=A0 However, = I see you point when considering MPL Forwarders
that only hav= e a single 802.15.4 interface.=A0 It seems they must function like a router= -on-a-stick
that forwards between VLANs on an ethernet link.
</kel2>= ;

</kel>
=A0
Compare with a similar statement for Admin-Local scope:

"An MPL Domain associated with an MPL Domain Addre= ss with a scope value of 4 (Admin-Local) is a scope zone within which the set of MPL Interfaces subscribing to that MPL Domain Address is administratively configured."

<kel>
With the definition of scope 0x03, RFC 4007 requires a scope 0x04 zone to fully encompass any
scope 0x03 zones that fall within its boundaries.=A0 It seems the best use of Admin-Local scope by
MPL may be to aggregate mesh and traditional links into larger MPL Domains.
</kel>
<RCC2>I agree</RCC>

<= /div>
<snip>

I believe we need something similar
in order to automatically define scope 0x03.=A0 To the extent that we need
scope 0x03 at all, I think it's to emulate classic link-local behavior in a mesh.
<RCC>I agree with this, however it is not always clear what constitutes "the mesh". The= re has to be one thing in common with all the interfaces which participate in the mesh; PAN ID is an obvious choice and clearly sets the zone of scope 3 in this case. DODAG ID is another possibility but MPL propagation through MPL forwarders is not rooted at a single node so it is more like RPL-P2P in some respects.</RCC>

<kel>
My concern here is the case of overlapping DODAGs.=A0 We cannot have overlapping
zones of the same scope.

In practice, I think the definition of scope 0x03 using PAN ID for 802.15.4 networks
is transparent at layer 3.=A0 It's a requirement that the node must filter by PAN ID at
layer 2 and again this definition should be part of the IP-over-foo specification.
</kel>
<RCC2>It's a tricky one this. I can sort of see the sense in wanting to limit propagation of a multicast to those nodes which have something in common with regard to routing. So in this sense, a DODAG ID would make sense. In that case, we have to rethink the idea of a MPL Domain being a scope zone and I'm not sure we want to go down that road again? So I do agree that if we are using scope zones, it has to be transparent at layer 3.</RCC2?
=
<kel2>
In the case of= scope 0x02, a zone is defined by physical connectivity and the nodes need<= br>
not have anything in common w.r.t. routing.=A0 I assume it is po= ssible to have multiple DODAGs
in the same PAN (please correc= t me if that is not the case) and that the BR can route between
them.=A0 When extending our scope 0x02 intuition to scope 0x03 it seem= s the only dependence
on routing behavior is in enabling a re= sponse to reach a requester.=A0 Put another way, I don't
think that = source address should be considered in the MPL Forwarder's decision to = re-transmit
a packet.
</kel2>
There are only so many ways that meshes can be distinguished:
either by location, frequency, or code diversity (assuming any two of
three overlap).=A0 In Ralph's example, = he assumes location and frequency
overlap.=A0 In Michael's example, I suspect he assumes location and PAN
ID overlap.

Finally, we may need to constrain Ralph's definition a bit further and define an 802.15.4=A0 scope 0x03 zone as a set of interfaces that share
a common PAN coordinator and PAN ID.
<RCC>I think that statement is tautological as the PAN coordinator dictates the PAN ID therefore must share the PAN ID. Therefore this reduces to sharing a PAN ID.</RCC>

<kel>
OK, I was trying to prevent the interpretation that two PANs on opposite sides
of the earth with the same PAN ID will be in the same scope zone.=A0 There's no
doubt a better way to state it.

BTW, I hope there's a method for two PAN coordinators on opposite sides of
a wall to ensure that they pick different PAN IDs?
</kel>
<RCC2>OK, I see where you are coming from and I have no problem with the extra text for clarity purposes. However, the definition of PAN and thus PAN ID should preclude this. It is not allowed for overlapping PANs to have the same PAN ID and 802.15.4 has mechanisms to prevent and fix this. Given the definition of a zone is a connected region of topology, this means that two PANs on opposite sides of the earth with the same PAN ID cannot be in the same scope zone as they are not connected.=A0 </RCC2>

<kel2>
I think = you are saying that "same PAN ID" is sufficient to automatically = define a
scope 0x03 zone and I agree with your reasoning.

Regards,= -K-
</kel2>

<snip>
--f46d0438907df00ac304e8deb11e-- From stokcons@xs4all.nl Thu Oct 17 05:22: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 A699C21F9B25 for ; Thu, 17 Oct 2013 05:22:08 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id taxpR95DVYHj for ; Thu, 17 Oct 2013 05:22:02 -0700 (PDT) Received: from smtp-vbr1.xs4all.nl (smtp-vbr1.xs4all.nl [194.109.24.21]) by ietfa.amsl.com (Postfix) with ESMTP id 3198111E8164 for ; Thu, 17 Oct 2013 05:21:52 -0700 (PDT) Received: from roundcube.xs4all.nl (roundcube8.xs4all.net [194.109.20.206]) by smtp-vbr1.xs4all.nl (8.13.8/8.13.8) with ESMTP id r9HCLpTs051618 for ; Thu, 17 Oct 2013 14:21:51 +0200 (CEST) (envelope-from stokcons@xs4all.nl) Received: from AMontpellier-654-1-109-86.w90-0.abo.wanadoo.fr ([90.0.84.86]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 17 Oct 2013 14:21:51 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 17 Oct 2013 14:21:51 +0200 From: peter van der Stok To: roll@ietf.org Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <3599.1381852752@sandelman.ca> <525DC6C9.2010808@gridmerge.com> <525E5064.4050109@gridmerge.com> Message-ID: <06f53671b3a2a83e5c2dfe8a919a45fd@xs4all.nl> X-Sender: stokcons@xs4all.nl (LDxFvtsSRzWYrCnWrAXpowrdsdoPqxRT) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Subject: Re: [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - separate MPL from 0x3 scope definition X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: consultancy@vanderstok.org, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 12:22:08 -0000 Dear all, Looking at the discussion there seem to be two issues: -1 tunnelling MC messages through MPL domain -2 Sending multicast to all members of a mesh I suggest to separate them to make the progress of MPL draft independent of 0x3 scope definition Ad 1) I understand that on reception by a seed of a MC message without MPL option, the wish is to encapsulate the message with a header which contains the MPL option to distribute the message over the mesh using MPL. At reception of the message each receiver still needs to check whether the MC address in the original message is destined to the receiving node. Therefore I think that the encapsulating header does not need the ALL_MPL_FORWARDERS multicast address but can be equal to the MC address of the original message. This means that receiving nodes need to enable their interfaces to the MC-address stored in the header of the original message. Given that the node needs to know this address anyway, I don't think this complicates the use of MPL. This also works for a message leaving the MPL domain. Any mistakes in my reasoning? Putting this text in section 5.1, and removing the text in section 4.1 can help the progress of MPL draft. Ad 2) There is a clear wish to distribute a MC message to all members of a mesh network, for example to distribute mdns messages or to learn lowpan start-up information like address of border router. Making that the subject of IP_over_Foo drafts seems very reasonable to me. The 6lo WG can provide an addendum to the 6lowpan RFC to provide an algorithm that makes it possible that all mesh members learn the same 0x3 scope address, and enable the address. Although MPL forwarders need to forward the message, the destinations are not necessarily MPL forwarders. Identifying the MC address with the PAN-ID (given the PAN-ID does not change in spite of coordinator failures) of the mesh seems logical for IEEE802.15.4. Sending a multicast to all members to a heterogeneous multi-link network looks like a different problem to me. Hope this may help. Peter From rdroms.ietf@gmail.com Thu Oct 17 09:11: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 0723521F9C4A; Thu, 17 Oct 2013 09:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FsKPznzRxXMw; Thu, 17 Oct 2013 09:11:00 -0700 (PDT) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 8478321F9A61; Thu, 17 Oct 2013 09:10:55 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id fb1so1019392pad.31 for ; Thu, 17 Oct 2013 09:10:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=QycdZMbsWrKXKVMc2LTsHhAMtORtYHVk5lpladNznsI=; b=bB+Wkk1wr+gyhB98ADdO14CZNDD0F1m7IwjPv3P8v2Brr6hT3SxxlH3VfWqvpjqZKK R0yI4sTMUXjcdjeQPgKNwOPJlERPD+Kr2nFR6KrguFntcoSQIxzxeTkByqGhoYwWI2vb Rbrzigs5XWuu6r4AZLebn3gfryPyGrBDcLnvbXhGAECLpFSP82Lqj5LjTCgvGQeOQN6Q a1L/n4jA8lvIEj/Wra4JMscs8e+LKdR6nvq3fyGhuJBa1vQw5wS9xlWSL4P5E2KPj3yP YwT71MwzCPvPryLwxz+BmGpDDCx6DZiI19xX/MvejaaG1cfwpRQNrgV//04LQAal02Jn RAMA== X-Received: by 10.68.172.36 with SMTP id az4mr9449936pbc.48.1382026254983; Thu, 17 Oct 2013 09:10:54 -0700 (PDT) Received: from [10.154.37.65] (128-107-239-234.cisco.com. [128.107.239.234]) by mx.google.com with ESMTPSA id qw8sm98747783pbb.27.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Oct 2013 09:10:51 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Ralph Droms In-Reply-To: Date: Thu, 17 Oct 2013 09:10:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3CC8783F-F4DA-47B9-A051-DBBA6EF00C19@gmail.com> References: <3599.1381852752@sandelman.ca> <525DC6C9.2010808@gridmerge.com> <525E5064.4050109@gridmerge.com> To: "6man@ietf.org" <6man@ietf.org> X-Mailer: Apple Mail (2.1510) Cc: Routing Over Low power and Lossy networks Subject: [Roll] draft-ietf-6man-multicast-scopes updates RFC 4007 (Was Re: [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 16:11:01 -0000 Kerry correctly points out that RFC 4007 and RFC 4291 are in conflict = regarding the way in which multicast scope 3 is defined: RFC 4007, section 5: o The boundaries of zones of a scope other than interface-local, link-local, and global must be defined and configured by network administrators. RFC 4291, section 2.7: Admin-Local scope is the smallest scope that must be administratively configured, i.e., not automatically derived from physical connectivity or other, non-multicast-related configuration. Noting this conflict, I propose adding a bit of text to = draft-ietf-6man-multicast-scopes to update RFC 4007 for consistency with = RFC 4291: Add section 3 (and renumber current section 3-5): 3. Updates to RFC 4007, section 5 Section 5 of RFC 4007 and section 2.7 of RFC 4291 disagree about the way in which multicast scope 3 is configured. To resolve that = disagreement, change the last bullet in the list in section 5 of RFC 4007 as = follows: OLD: o The boundaries of zones of a scope other than interface-local, link-local, and global must be defined and configured by network administrators. NEW: o Admin-Local scope is the smallest scope that must be administratively configured, i.e., not automatically derived from physical connectivity or other, non-multicast-related configuration. Looking for consensus in the 6man WG before I make this change... - Ralph On Oct 16, 2013, at 10:04 AM 10/16/13, Kerry Lynn = wrote: > [...] > I think Ralph's approach is the correct one. His = draft-droms-6man-multicast-scopes belongs in > 6man as it re-defines a reserved code point in the IPv6 addressing = architecture. It nominally > updates RFC 4291 but should probably also update RFC 4007 as these = RFCs are in conflict > regarding the automatic definition of scope 0x03. [...] From kerlyn2001@gmail.com Thu Oct 17 09:16:44 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 0817711E825D; Thu, 17 Oct 2013 09:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UnBzs2Kz6Bcu; Thu, 17 Oct 2013 09:16:43 -0700 (PDT) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 489ED11E8271; Thu, 17 Oct 2013 09:16:39 -0700 (PDT) Received: by mail-wg0-f54.google.com with SMTP id c11so2594439wgh.9 for ; Thu, 17 Oct 2013 09:16:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=3m6QM95Y58yuqeOqhvhP2HX72L7Ku2fd+vuM74irvOg=; b=NOsj4d0ELoDKRGIuUSYQ7lmuy9uWf61D+kX//zUmIdRX2llO0jnI/5mXaHiR3K7jMI qlqkRA1B+pZq1mGx5UUfvKCjwJhV8gkq5oHporzBvLMKc98NNOIA8s9GA1vMYwPSP/06 JkD7+yVmrJsK0t8+Cmrm+fg4XquyjVZiHOZvUvn9JxqYpGU+dJXMvuMKmzwcmhTO2XZT lbQaFavIZKKgipXT4juwKVKFJptkJPO1pIhz5UOJfrGjbGhl55uRobzhqoWqppjXXI/E JF3xTWuJurE8CndCCEq1UDi5508G85Zst16lkGyERDIDSsiOTixTgENidljhyZsylVno l/sw== MIME-Version: 1.0 X-Received: by 10.180.182.15 with SMTP id ea15mr29921654wic.16.1382026597536; Thu, 17 Oct 2013 09:16:37 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.216.227.132 with HTTP; Thu, 17 Oct 2013 09:16:37 -0700 (PDT) In-Reply-To: <3CC8783F-F4DA-47B9-A051-DBBA6EF00C19@gmail.com> References: <3599.1381852752@sandelman.ca> <525DC6C9.2010808@gridmerge.com> <525E5064.4050109@gridmerge.com> <3CC8783F-F4DA-47B9-A051-DBBA6EF00C19@gmail.com> Date: Thu, 17 Oct 2013 12:16:37 -0400 X-Google-Sender-Auth: _d8c8iiXon2bZ9RiaS8uIK7F4Xw Message-ID: From: Kerry Lynn To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary=047d7b62535a6a98d504e8f2243a Cc: "6man@ietf.org" <6man@ietf.org> Subject: Re: [Roll] draft-ietf-6man-multicast-scopes updates RFC 4007 (Was Re: [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 16:16:44 -0000 --047d7b62535a6a98d504e8f2243a Content-Type: text/plain; charset=ISO-8859-1 On Thu, Oct 17, 2013 at 12:10 PM, Ralph Droms wrote: > Kerry correctly points out that RFC 4007 and RFC 4291 are in conflict > regarding the way in which multicast scope 3 is defined: > > RFC 4007, section 5: > > o The boundaries of zones of a scope other than interface-local, > link-local, and global must be defined and configured by network > administrators. > > RFC 4291, section 2.7: > > Admin-Local scope is the smallest scope that must be > administratively configured, i.e., not automatically derived > from physical connectivity or other, non-multicast-related > configuration. > > Noting this conflict, I propose adding a bit of text to > draft-ietf-6man-multicast-scopes to update RFC 4007 for consistency with > RFC 4291: > > Add section 3 (and renumber current section 3-5): > > 3. Updates to RFC 4007, section 5 > > Section 5 of RFC 4007 and section 2.7 of RFC 4291 disagree about the > way in which multicast scope 3 is configured. To resolve that > disagreement, > change the last bullet in the list in section 5 of RFC 4007 as follows: > > OLD: > > o The boundaries of zones of a scope other than interface-local, > link-local, and global must be defined and configured by network > administrators. > > NEW: > > o Admin-Local scope is the smallest scope that must be > administratively configured, i.e., not automatically derived > from physical connectivity or other, non-multicast-related > configuration. > > Looking for consensus in the 6man WG before I make this change... > > +1 -K- > - Ralph > > On Oct 16, 2013, at 10:04 AM 10/16/13, Kerry Lynn wrote: > > > [...] > > > I think Ralph's approach is the correct one. His > draft-droms-6man-multicast-scopes belongs in > > 6man as it re-defines a reserved code point in the IPv6 addressing > architecture. It nominally > > updates RFC 4291 but should probably also update RFC 4007 as these RFCs > are in conflict > > regarding the automatic definition of scope 0x03. > [...] > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --047d7b62535a6a98d504e8f2243a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Oct 17, 2013 at 12:10 PM, Ralph Droms <rdroms= .ietf@gmail.com> wrote:
Kerry correctly points out that RFC 4007 and= RFC 4291 are in conflict regarding the way in which multicast scope 3 is d= efined:

RFC 4007, section 5:

=A0 =A0o =A0The boundaries of zones of a scope other than interface-local,<= br> =A0 =A0 =A0 link-local, and global must be defined and configured by networ= k
=A0 =A0 =A0 administrators.

RFC 4291, section 2.7:

=A0 =A0 =A0 =A0 =A0Admin-Local scope is the smallest scope that must be
=A0 =A0 =A0 =A0 =A0administratively configured, i.e., not automatically der= ived
=A0 =A0 =A0 =A0 =A0from physical connectivity or other, non-multicast-relat= ed
=A0 =A0 =A0 =A0 =A0configuration.

Noting this conflict, I propose adding a bit of text to draft-ietf-6man-mul= ticast-scopes to update RFC 4007 for consistency with RFC 4291:

Add section 3 (and renumber current section 3-5):

3. =A0Updates to RFC 4007, section 5

=A0 =A0Section 5 of RFC 4007 and section 2.7 of RFC 4291 disagree about the=
=A0 =A0way in which multicast scope 3 is configured. =A0To resolve that dis= agreement,
=A0 =A0change the last bullet in the list in section 5 of RFC 4007 as follo= ws:

OLD:

=A0 =A0o =A0The boundaries of zones of a scope other than interface-local,<= br> =A0 =A0 =A0 link-local, and global must be defined and configured by networ= k
=A0 =A0 =A0 administrators.

NEW:

=A0 =A0o =A0Admin-Local scope is the smallest scope that must be
=A0 =A0 =A0 administratively configured, i.e., not automatically derived =A0 =A0 =A0 from physical connectivity or other, non-multicast-related
=A0 =A0 =A0 configuration.

Looking for consensus in the 6man WG before I make this change...

+1

-K-
=A0
- Ralph

On Oct 16, 2013, at 10:04 AM 10/16/13, Kerry Lynn <kerlyn@ieee.org> wrote:

> [...]

> I think Ralph's approach is the correct one. =A0His draft-droms-6m= an-multicast-scopes belongs in
> 6man as it re-defines a reserved code point in the IPv6 addressing arc= hitecture. =A0It nominally
> updates RFC 4291 but should probably also update RFC 4007 as these RFC= s are in conflict
> regarding the automatic definition of scope 0x03.
[...]

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

--047d7b62535a6a98d504e8f2243a-- From trac+roll@trac.tools.ietf.org Thu Oct 17 19:43:34 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC0E111E8133 for ; Thu, 17 Oct 2013 19:43:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9TcjoZCWfnH1 for ; Thu, 17 Oct 2013 19:43:30 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 1E73621F9AE7 for ; Thu, 17 Oct 2013 19:43:27 -0700 (PDT) Received: from localhost ([127.0.0.1]:40010 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VX024-000170-FX; Fri, 18 Oct 2013 04:43:20 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit 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: johui@cisco.com, mariainesrobles@gmail.com, rdroms@cisco.com, mcr@sandelman.ca X-Trac-Project: roll Date: Fri, 18 Oct 2013 02:43:20 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/roll/trac/ticket/132#comment:9 Message-ID: <082.0daa4be2ae6418b82a3c6ead981bc343@trac.tools.ietf.org> References: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org> X-Trac-Ticket-ID: 132 In-Reply-To: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: johui@cisco.com, mariainesrobles@gmail.com, rdroms@cisco.com, mcr@sandelman.ca, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local 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, 18 Oct 2013 02:43:34 -0000 #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local Comment (by mariainesrobles@gmail.com): Previous comments on this topic Thread from [07/11/13-07/26/13]: http://www.ietf.org/mail- archive/web/roll/current/msg08020.html Thread from [09/13/13-09/24/13]: http://www.ietf.org/mail- archive/web/roll/current/msg08158.html On 10/15/13 Thread: http://www.ietf.org/mail- archive/web/roll/current/msg08225.html Why do we need/want scope value 4 at all? I don't agree with using the PAN ID as the automatically configured criteria. I think that subnet is the right thing. RPL and MPL is specifically designed to cross layer-2. There apparently was interest in an administratively defined MP domain. scop 4 is available for that kind of domain. If there is no interest, scop 4 need not be added. What is your definition for "subnet" that is compatible with the definition from draft-ietf-6man-multicast-scopes: automatically configured, i.e., automatically derived from physical connectivity or other, non-multicast-related configuration. I chose PAN ID as a way of identifying a "subnet" within a distribution of MPL forwarders that might be within radio range of each other but should be in separate MPL domains. For example, suppose I have MPL forwarders in my flat and you have MPL forwarders in your flat. How do my forwarders know they belong to the MPL domain in my flat while your forwarders know they belong to the MPL domain in your flat. PAN ID would be one way to make that differentation. PANID is too restrictive in my opinion. I may well have a radio networks on the first floor of my (penthouse) flat, and another radio network on the second floor of my flat, connected by any number of wired (ethernet) or higher-powered wireless (wifi) layer-2 technologies. There are good radio reasons to use different PANIDs, because the isolation might be inconsistent. The devices which connect my two floors know they are supposed to do that at the RPL level, and so subnet is the right thing. This is where we need to be prescriptive. Yes, but your scenario is surely one where it cannot be automatically configured and therefore scope 4 is surely more applicable? If the RPL can discover/build the network, then the MPL should automatically use it. Yes, I agree that I have to plug the cables in, and I probably have to apply power. I don't see how scope 3 (automatically configured) fits with your example. There would need to be some administrative configuration to let these devices know that the two PANs you have should be linked in one domain. If I'm understanding your example correctly, I would say that the MPL domain you describe would use scop 4, administratively defined to cover the various radio domains. I might also consider using scop 3 to simply forward across the mesh networks, with a broader scope and traditional multicast protocols to tie together the MPL domains with other links in the home network. Suppose an application uses multicast address FF08::DB8:0:1234 in a network with RTR1 connected to MESH1 and some other links, and RTR2 connected to MESH2 and some other links. RTR1 and RTR2 share at least on link. One architecture would be to use traditional multicast protocols to connect the various links to which RTR1 and RTR2 are connected. RTR1 and RTR2 then act as MPL encapsulators for MESH1 and MESH2. Traffic on MESH1 looks like (hope the summarization is understandable) FF03:0:0:0:0:0:0:FC | MPL header | FF08::DB8:0:1234 | application payload At some point, I think it would be interesting to see multicast forwarding rules in a mesh network where flooding is not used. I would see that case as the example of where scope 4 would be used. I know that a lot of work is needed in defining the rules for forwarding when flooding is not used but in a large mesh network, there would be a lot of benefit to such a feature. okay, so when we write a new protocol, we can specify this. Why have the code there to support scope-4 when there is no other behaviour? Do you agree with me about PANID vs Subnet or not? We should leave in scope 4 for use in administratively scoped domains. This would allow applications to define specific multicast addresses using scope 4 without having to go through the trouble to "un-reserve" adminstrative scope. Also, I am in favor of Ralph's proposal on using PAN ID for MPL scope 3. I don't see how any automatic configuration could take place if we can't identify a concrete identifier for the scope. The other alternative (and to be honest the one I thought we were going to use) is DODAG ID. This would allow your scenario where a subnet of different link technologies could support MPL domain 3. Don - at present, MPL is, as far as I know, independent of RPL. In particular, MPL can be used in a mesh that does not use RPL. Therefore, there might not be a DODAG ID to use as a MPL domain identifier. While I agree with you (ralph), that MPL is separate from RPL in the same way that HTTP can run over V32bis or ITU-T Rec. X.214 (OSI TPx) if we want it to, if one want to use MPL in another environment one will have to specify the boundaries somehow. Using PANID limits one to 802.15.4-ish networks: what is the PANID of ethernet? ROLL is specifically chartered to work across a multitude of different layer-2 protocols. If MPL were defined in terms of scope 0x02 messages (as the Trickle Algorithm is) we'd be done by now. An MPL domain would then be the set of links connected by MPL forwarders, with the boundary set by administratively opting out interfaces (a MPL domain boundary would thus be defined as cutting through a node, not a link).[[BR]] Scope 0x03 is not defined on 802.3. It is only needed at all on mesh networks, therefore it is defined (or not) on a link layer basis. I like DODAG ID. That suits me fine. If a host can be present simultaneously in more than one DODAG then we run afoul of normative RFC 4007 behavior: Zones of the same scope cannot overlap; i.e., they can have no links or interfaces in common. Link-local scope is essentially defined by a combination of link layer connectivity and routing behavior. I believe we need something similar in order to automatically define scope 0x03. To the extent that we need scope 0x03 at all, I think it's to emulate classic link-local behavior in a mesh. There are only so many ways that meshes can be distinguished: either by location, frequency, or code diversity (assuming any two of three overlap). In Ralph's example, he assumes location and frequency overlap. In Michael's example, I suspect he assumes location and PAN ID overlap. Finally, we may need to constrain Ralph's definition a bit further and define an 802.15.4 scope 0x03 zone as a set of interfaces that share a common PAN coordinator and PAN ID. Following up on Kerry's observation that a node can belong to more than one DODAG, how does such a node determine which DODAG to use for scop 3 forwarding, or which DODAG to use for filtering inbound scop 3 traffic? I think you have to fall back on routing behavior. Consider a mixed-PHY mesh, such as a a combination of 802.15.4 and PLC links. If the routing layer considers it all one mesh, then it is, regardless of whether or not there are any 802.15.4 nodes in direct communication using the same PAN ID. On the other hand, the routing layer could take the same physical setup and treat it as distinct 802.15.4 meshes with PLC interconnects, in which case you would get multiple 0x03 scopes. I shall not today attempt further to define 0x03 scope; and perhaps I could never succeed in intelligibly doing so. But I know it when I see it. (paraphrasing Justice Potter Stewart) OK, but I don't think there is a good way to associate a specific MPL datagram with a DODAG ID, so a node can determine which scope 3 that MPL datagram is associated with. And, using DODAG ID tightly couples MPL with RPL, when MPL as currently defined can be used without RPL. I think scope 4 is a much better candidate for the "composite" subnet use case, while scope 3 is good for a single physical mesh. “...I am in favour of using PAN ID as the basis for the MPL Domain Address with scope 3 for 802.15.4-based networks. The PAN ID is the fundamental identifier that groups nodes in a PAN and therefore forms a clear zone for multicast dissemination. Anything else is going to be an unclear superset or subset. The language can get a bit circular so I think the statement for an 802.15.4-based network is: "An MPL Domain associated with an MPL Domain Address of ALL_MPL_FORWARDERS with a scope value of 3 (Realm-Local) is a scope zone within which the set of 802.15.4 MPL Interfaces subscribing to that MPL Domain Address all have the same PAN ID." Compare with a similar statement for Admin-Local scope: "An MPL Domain associated with an MPL Domain Address with a scope value of 4 (Admin-Local) is a scope zone within which the set of MPL Interfaces subscribing to that MPL Domain Address is administratively configured."...” “...Link-local scope is defined by link layer connectivity only, surely? Where does routing behavior come into it?...” “...it is not always clear what constitutes "the mesh". There has to be one thing in common with all the interfaces which participate in the mesh; PAN ID is an obvious choice and clearly sets the zone of scope 3 in this case. DODAG ID is another possibility but MPL propagation through MPL forwarders is not rooted at a single node so it is more like RPL-P2P in some respects….” “...the PAN coordinator dictates the PAN ID therefore must share the PAN ID. Therefore this reduces to sharing a PAN ID…” “...I feel that MPL should be defined strictly in terms of how it handles different scopes and that the definition of scope 0x03 belongs in the appropriate IP-over-foo RFC or an update to same. There's always the outside possibility that another (non 15.4) mesh data link may emerge in the future. Also, as I suggested in an earlier email, the PAN ID based definition should make it clear we're talking about a set of interfaces that share physical connectivity as well as PAN ID. It should be possible to create an MPL Domain from traditional links (e.g. ethernet) that only uses scope 0x02 messages….” “...With the definition of scope 0x03, RFC 4007 requires a scope 0x04 zone to fully encompass any scope 0x03 zones that fall within its boundaries. It seems the best use of Admin-Local scope by MPL may be to aggregate mesh and traditional links into larger MPL Domains….” “...To be more accurate, the boundary of a link-local zone is defined by the lack of forwarding. RFC 4291 states: Routers must not forward any packets with Link-Local source or destination addresses to other links. Thus, Link-Local scope zones may exist on adjacent links but they will be disjoint....” “...My concern here is the case of overlapping DODAGs. We cannot have overlapping zones of the same scope. In practice, I think the definition of scope 0x03 using PAN ID for 802.15.4 networks is transparent at layer 3. It's a requirement that the node must filter by PAN ID at layer 2 and again this definition should be part of the IP-over-foo specification....” “....OK, I was trying to prevent the interpretation that two PANs on opposite sides of the earth with the same PAN ID will be in the same scope zone. There's no doubt a better way to state it. BTW, I hope there's a method for two PAN coordinators on opposite sides of a wall to ensure that they pick different PAN IDs?...” On 10/16/13 “... There needs to be a decision on where to write the IP-over-foo scope 3 definition, especially for IP-over-802.15.4…” “...In principle, I agree. Practically, what is the best way to achieve this? A 6lo-led RFC for all IP-over-foo Updates to all the existing IP-over-foo RFCs Lots of short RFCs for each IP-over-foo Start with 802.15.4 example in MPL I think all are reasonable and there are bound to be other approaches which are reasonable as well. I think as already discussed it comes down to (3) or (4) to get draft-ietf-roll-trickle-mcast finished as quickly as possible….” “...it should be clear that a statement regarding scope 3 is included in the corresponding IP-over-foo RFC...” “...It is now, however the MPL Domain will only reach one hop. We did discuss at length some time ago in the ZigBee IP community the merits of using scope 2 vs. scope 3 for propagating multicasts. The outcome was that both are feasible solutions but using scope 2 conceptually means multiple overlapping one-hop MPL domains in some arbitrary zone. To propagate multicasts in this arbitrary zone would mean administratively configuring MPL forwarder behaviour to ensure propagation. In practice, the difference is minimal but architecturally it is quite different…” “...I can sort of see the sense in wanting to limit propagation of a multicast to those nodes which have something in common with regard to routing. So in this sense, a DODAG ID would make sense. In that case, we have to rethink the idea of a MPL Domain being a scope zone and I'm not sure we want to go down that road again? So I do agree that if we are using scope zones, it has to be transparent at layer 3….” “...the definition of PAN and thus PAN ID should preclude this. It is not allowed for overlapping PANs to have the same PAN ID and 802.15.4 has mechanisms to prevent and fix this. Given the definition of a zone is a connected region of topology, this means that two PANs on opposite sides of the earth with the same PAN ID cannot be in the same scope zone as they are not connected...” “...I think Ralph's approach is the correct one. His draft-droms-6man- multicast-scopes belongs in 6man as it re-defines a reserved code point in the IPv6 addressing architecture. It nominally updates RFC 4291 but should probably also update RFC 4007 as these RFCs are in conflict regarding the automatic definition of scope 0x03. Ralph's draft says that scope 0x03 is defined on a network technology basis and should be published in an RFC. Since 6LoWPAN is trying to close down, I think a (short) update to RFC 4944 could be done in 6lo. Other 6lo drafts should define scope 0x03 (or not) for their particular technology. I think scope 0x03 is unnecessary for any technology that doesn't have a hidden node issue and probably not necessary for all wireless data links. MPL should be clear of technology discussion and just define forwarding behavior on a scope-by-scope basis. For example, *if* it is possible to create a MPL "Super-Domain" from scope 2 domains, I expect the behavior would be to retransmit (or not, as determined by the Trickle Algorithm) on all active MPL interfaces but use a new source address at each hop. You then have a set of connected one-hop tunnels and the seed and sequence data is preserved in the inner header. For scope > 2 I expect the MPL Data packet would be re-transmitted (forwarded) using the original (received) source address. Is it sufficient to just reference Ralph's draft when scope 0x03 is discussed in MPL and thus decouple the two discussions? ...” “...I think it would have been better to use the term "MPL zone", especially since an MPL Domain is currently defined to be an RFC 4007 scope zone. Since scope zones cannot overlap, the same must be true for MPL Domains. However, I see you point when considering MPL Forwarders that only have a single 802.15.4 interface. It seems they must function like a router-on-a-stick that forwards between VLANs on an ethernet link....” “... In the case of scope 0x02, a zone is defined by physical connectivity and the nodes need not have anything in common w.r.t. routing. I assume it is possible to have multiple DODAGs in the same PAN (please correct me if that is not the case) and that the BR can route between them. When extending our scope 0x02 intuition to scope 0x03 it seems the only dependence on routing behavior is in enabling a response to reach a requester. Put another way, I don't think that source address should be considered in the MPL Forwarder's decision to re-transmit a packet....” “...I think you are saying that "same PAN ID" is sufficient to automatically define a scope 0x03 zone and I agree with your reasoning...” On 10/17/13 Kerry correctly points out that RFC 4007 and RFC 4291 are in conflict regarding the way in which multicast scope 3 is defined: RFC 4007, section 5: o The boundaries of zones of a scope other than interface-local, link-local, and global must be defined and configured by network administrators. RFC 4291, section 2.7: Admin-Local scope is the smallest scope that must be administratively configured, i.e., not automatically derived from physical connectivity or other, non-multicast-related configuration. Noting this conflict, I propose adding a bit of text to draft-ietf-6man- multicast-scopes to update RFC 4007 for consistency with RFC 4291: Add section 3 (and renumber current section 3-5): 3. Updates to RFC 4007, section 5 Section 5 of RFC 4007 and section 2.7 of RFC 4291 disagree about the way in which multicast scope 3 is configured. To resolve that disagreement, change the last bullet in the list in section 5 of RFC 4007 as follows: OLD: o The boundaries of zones of a scope other than interface-local, link-local, and global must be defined and configured by network administrators. NEW: o Admin-Local scope is the smallest scope that must be administratively configured, i.e., not automatically derived from physical connectivity or other, non-multicast-related configuration. Looking for consensus in the 6man WG before I make this change... -- ---------------------------------------+------------------------------ Reporter: mariainesrobles@gmail.com | Owner: johui@cisco.com Type: defect | Status: reopened Priority: major | Milestone: Component: trickle-mcast | Version: Severity: In WG Last Call | Resolution: Keywords: | ---------------------------------------+------------------------------ Ticket URL: roll From trac+roll@trac.tools.ietf.org Thu Oct 17 19:47: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 7E79821F9B28 for ; Thu, 17 Oct 2013 19:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cKV7f+LzvFyC for ; Thu, 17 Oct 2013 19:47:34 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 87CED11E80EC for ; Thu, 17 Oct 2013 19:47:29 -0700 (PDT) Received: from localhost ([127.0.0.1]:40708 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VX061-0006z3-Ug; Fri, 18 Oct 2013 04:47:25 +0200 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: johui@cisco.com, mariainesrobles@gmail.com, rdroms@cisco.com, mcr@sandelman.ca X-Trac-Project: roll Date: Fri, 18 Oct 2013 02:47:25 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/132#comment:10 Message-ID: <082.57081c4f1572e1aaa25063db00d0cf32@trac.tools.ietf.org> References: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org> X-Trac-Ticket-ID: 132 In-Reply-To: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: johui@cisco.com, mariainesrobles@gmail.com, rdroms@cisco.com, mcr@sandelman.ca, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local 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, 18 Oct 2013 02:47:37 -0000 #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local Comment (by mariainesrobles@gmail.com): From: peter van der Stok Date: Thu, 17 Oct 2013 14:21:51 +0200 Thread: http://www.ietf.org/mail-archive/web/roll/current/msg08250.html "Looking at the discussion there seem to be two issues: -1 tunnelling MC messages through MPL domain -2 Sending multicast to all members of a mesh I suggest to separate them to make the progress of MPL draft independent of 0x3 scope definition Ad 1) I understand that on reception by a seed of a MC message without MPL option, the wish is to encapsulate the message with a header which contains the MPL option to distribute the message over the mesh using MPL. At reception of the message each receiver still needs to check whether the MC address in the original message is destined to the receiving node. Therefore I think that the encapsulating header does not need the ALL_MPL_FORWARDERS multicast address but can be equal to the MC address of the original message. This means that receiving nodes need to enable their interfaces to the MC-address stored in the header of the original message. Given that the node needs to know this address anyway, I don't think this complicates the use of MPL. This also works for a message leaving the MPL domain. Any mistakes in my reasoning? Putting this text in section 5.1, and removing the text in section 4.1 can help the progress of MPL draft. Ad 2) There is a clear wish to distribute a MC message to all members of a mesh network, for example to distribute mdns messages or to learn lowpan start- up information like address of border router. Making that the subject of IP_over_Foo drafts seems very reasonable to me. The 6lo WG can provide an addendum to the 6lowpan RFC to provide an algorithm that makes it possible that all mesh members learn the same 0x3 scope address, and enable the address. Although MPL forwarders need to forward the message, the destinations are not necessarily MPL forwarders. Identifying the MC address with the PAN-ID (given the PAN-ID does not change in spite of coordinator failures) of the mesh seems logical for IEEE802.15.4. Sending a multicast to all members to a heterogeneous multi-link network looks like a different problem to me. Hope this may help." -- ---------------------------------------+------------------------------ Reporter: mariainesrobles@gmail.com | Owner: johui@cisco.com Type: defect | Status: reopened Priority: major | Milestone: Component: trickle-mcast | Version: Severity: In WG Last Call | Resolution: Keywords: | ---------------------------------------+------------------------------ Ticket URL: roll From trac+roll@trac.tools.ietf.org Sun Oct 20 18:23: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 13A8211E830D for ; Sun, 20 Oct 2013 18:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GidmXbPRx7ah for ; Sun, 20 Oct 2013 18:23:21 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id E1E2211E831A for ; Sun, 20 Oct 2013 18:23:14 -0700 (PDT) Received: from localhost ([127.0.0.1]:54132 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VY4CT-0004sh-4z; Mon, 21 Oct 2013 03:22:37 +0200 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: mcr@sandelman.ca, mariainesrobles@gmail.com X-Trac-Project: roll Date: Mon, 21 Oct 2013 01:22:26 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/125#comment:5 Message-ID: <082.d7f4c7689259107ecf4bea43e5660481@trac.tools.ietf.org> References: <067.b8a42ee3aa07b56a25c0575de68ce20e@trac.tools.ietf.org> X-Trac-Ticket-ID: 125 In-Reply-To: <067.b8a42ee3aa07b56a25c0575de68ce20e@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: mcr@sandelman.ca, mariainesrobles@gmail.com, tzeta.tsao@cooperindustries.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org, tzeta.tsao@cooperindustries.com Subject: Re: [Roll] [roll] #125: draft-ietf-roll-security-threats-01.txt --- Delete section/terms 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: Mon, 21 Oct 2013 01:23:22 -0000 #125: draft-ietf-roll-security-threats-01.txt --- Delete section/terms Changes (by mcr@sandelman.ca): * status: assigned => closed * resolution: => fixed -- ---------------------------------------+------------------------------- Reporter: mariainesrobles@gmail.com | Owner: mcr@sandelman.ca Type: defect | Status: closed Priority: major | Milestone: Component: security-threats | Version: Severity: Active WG Document | Resolution: fixed Keywords: | ---------------------------------------+------------------------------- Ticket URL: roll From trac+roll@trac.tools.ietf.org Sun Oct 20 18:32:31 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C64D111E80F8 for ; Sun, 20 Oct 2013 18:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8g2IUTdU0i0 for ; Sun, 20 Oct 2013 18:32:31 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 2951E11E830F for ; Sun, 20 Oct 2013 18:32:28 -0700 (PDT) Received: from localhost ([127.0.0.1]:54825 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VY4Ll-0005np-5L; Mon, 21 Oct 2013 03:32:11 +0200 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: mcr@sandelman.ca, mariainesrobles@gmail.com X-Trac-Project: roll Date: Mon, 21 Oct 2013 01:32:04 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/121#comment:4 Message-ID: <082.bce1cdb281cc2f583dae55f525ab3e51@trac.tools.ietf.org> References: <067.966e013d1f392cdfd7a3db95de968ef6@trac.tools.ietf.org> X-Trac-Ticket-ID: 121 In-Reply-To: <067.966e013d1f392cdfd7a3db95de968ef6@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: mcr@sandelman.ca, mariainesrobles@gmail.com, tzeta.tsao@cooperindustries.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org, tzeta.tsao@cooperindustries.com Subject: Re: [Roll] [roll] #121: draft-ietf-roll-security-threats-01.txt --- Provide a pointer to the concept of control plane and specify it in the figure 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: Mon, 21 Oct 2013 01:32:31 -0000 #121: draft-ietf-roll-security-threats-01.txt --- Provide a pointer to the concept of control plane and specify it in the figure Changes (by mcr@sandelman.ca): * status: assigned => closed * resolution: => fixed -- ---------------------------------------+------------------------------- Reporter: mariainesrobles@gmail.com | Owner: mcr@sandelman.ca Type: defect | Status: closed Priority: major | Milestone: Component: security-threats | Version: Severity: Active WG Document | Resolution: fixed Keywords: | ---------------------------------------+------------------------------- Ticket URL: roll From trac+roll@trac.tools.ietf.org Sun Oct 20 18:41: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 E88F911E8107 for ; Sun, 20 Oct 2013 18:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YYE811f-9pzd for ; Sun, 20 Oct 2013 18:41:22 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id CBA6E11E8101 for ; Sun, 20 Oct 2013 18:41:12 -0700 (PDT) Received: from localhost ([127.0.0.1]:55063 helo=grenache.tools.ietf.org) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VY4Ty-0004Qd-Br; Mon, 21 Oct 2013 03:40:39 +0200 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: tzeta.tsao@cooperindustries.com, mariainesrobles@gmail.com, mcr@sandelman.ca X-Trac-Project: roll Date: Mon, 21 Oct 2013 01:40:22 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/124#comment:3 Message-ID: <082.ddce5283b49d6415b6cfe86afb3421bd@trac.tools.ietf.org> References: <067.fdab363d655b1902d82f78e9aebff2a7@trac.tools.ietf.org> X-Trac-Ticket-ID: 124 In-Reply-To: <067.fdab363d655b1902d82f78e9aebff2a7@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: tzeta.tsao@cooperindustries.com, mariainesrobles@gmail.com, mcr@sandelman.ca, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #124: draft-ietf-roll-security-threats-01.txt --- Include further explanation 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: Mon, 21 Oct 2013 01:41:24 -0000 #124: draft-ietf-roll-security-threats-01.txt --- Include further explanation Comment (by mcr@sandelman.ca): {{{ s3.3: Highly directional traffic: Are you trying to say that the LBRs are higher valued targets and warrant something different than the regular nodes?-- BY ST }}} LRBs and low-ranked nodes are higher value targets, but predicting which nodes (in an inventory of thousands) is probably pretty difficult, so having good security everywhere is easier. Further, if low-rank nodes are easily identified, then they are more easily destroyed, leaving a lower rank (and if we differentiated, less secure) node to fill in. -- -------------------------------------+------------------------------------- Reporter: | Owner: mariainesrobles@gmail.com | tzeta.tsao@cooperindustries.com Type: defect | Status: new Priority: major | Milestone: Component: security-threats | Version: Severity: Active WG Document | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: roll From trac+roll@trac.tools.ietf.org Sun Oct 20 19:03: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 2291D11E8100 for ; Sun, 20 Oct 2013 19:03:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IiovHmbzYoGi for ; Sun, 20 Oct 2013 19:03:58 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 90DA911E80F5 for ; Sun, 20 Oct 2013 19:03:58 -0700 (PDT) Received: from localhost ([127.0.0.1]:57144 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VY4qZ-0000Zl-So; Mon, 21 Oct 2013 04:03:55 +0200 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: tzeta.tsao@cooperindustries.com, mariainesrobles@gmail.com, mcr@sandelman.ca X-Trac-Project: roll Date: Mon, 21 Oct 2013 02:03:55 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/124#comment:4 Message-ID: <082.44dbe562bb971254822b02622cf013f8@trac.tools.ietf.org> References: <067.fdab363d655b1902d82f78e9aebff2a7@trac.tools.ietf.org> X-Trac-Ticket-ID: 124 In-Reply-To: <067.fdab363d655b1902d82f78e9aebff2a7@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: tzeta.tsao@cooperindustries.com, mariainesrobles@gmail.com, mcr@sandelman.ca, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #124: draft-ietf-roll-security-threats-01.txt --- Include further explanation 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: Mon, 21 Oct 2013 02:03:59 -0000 #124: draft-ietf-roll-security-threats-01.txt --- Include further explanation Comment (by mcr@sandelman.ca): section 8.2.4 has been changed to list the countermeasure that RPL has to replays. -- -------------------------------------+------------------------------------- Reporter: | Owner: mariainesrobles@gmail.com | tzeta.tsao@cooperindustries.com Type: defect | Status: new Priority: major | Milestone: Component: security-threats | Version: Severity: Active WG Document | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: roll From trac+roll@trac.tools.ietf.org Sun Oct 20 19:30: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 9F25911E8120 for ; Sun, 20 Oct 2013 19:30:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NkjlIojS2onZ for ; Sun, 20 Oct 2013 19:30:26 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 513B311E8102 for ; Sun, 20 Oct 2013 19:30:16 -0700 (PDT) Received: from localhost ([127.0.0.1]:59434 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VY5Fz-0002wd-B3; Mon, 21 Oct 2013 04:30:11 +0200 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: tzeta.tsao@cooperindustries.com, mariainesrobles@gmail.com, mcr@sandelman.ca X-Trac-Project: roll Date: Mon, 21 Oct 2013 02:30:11 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/124#comment:5 Message-ID: <082.803b8b2937f81a2fbf257ec4d10e323a@trac.tools.ietf.org> References: <067.fdab363d655b1902d82f78e9aebff2a7@trac.tools.ietf.org> X-Trac-Ticket-ID: 124 In-Reply-To: <067.fdab363d655b1902d82f78e9aebff2a7@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: tzeta.tsao@cooperindustries.com, mariainesrobles@gmail.com, mcr@sandelman.ca, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #124: draft-ietf-roll-security-threats-01.txt --- Include further explanation 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: Mon, 21 Oct 2013 02:30:27 -0000 #124: draft-ietf-roll-security-threats-01.txt --- Include further explanation Comment (by mcr@sandelman.ca): section 5.3.1/8.3.1: rewrote this section with specific reference to RPL mechanisms. -- -------------------------------------+------------------------------------- Reporter: | Owner: mariainesrobles@gmail.com | tzeta.tsao@cooperindustries.com Type: defect | Status: new Priority: major | Milestone: Component: security-threats | Version: Severity: Active WG Document | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: roll From trac+roll@trac.tools.ietf.org Sun Oct 20 19:43:31 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD5311E8328 for ; Sun, 20 Oct 2013 19:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XPXOmhcKAzsA for ; Sun, 20 Oct 2013 19:43:30 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id C154011E832B for ; Sun, 20 Oct 2013 19:43:25 -0700 (PDT) Received: from localhost ([127.0.0.1]:60378 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VY5Sg-0002n6-Or; Mon, 21 Oct 2013 04:43:19 +0200 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: tzeta.tsao@cooperindustries.com, mariainesrobles@gmail.com, mcr@sandelman.ca X-Trac-Project: roll Date: Mon, 21 Oct 2013 02:43:18 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/124#comment:6 Message-ID: <082.5f55bcf1dc186b7ea1b09cdb1abaa6b5@trac.tools.ietf.org> References: <067.fdab363d655b1902d82f78e9aebff2a7@trac.tools.ietf.org> X-Trac-Ticket-ID: 124 In-Reply-To: <067.fdab363d655b1902d82f78e9aebff2a7@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: tzeta.tsao@cooperindustries.com, mariainesrobles@gmail.com, mcr@sandelman.ca, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #124: draft-ietf-roll-security-threats-01.txt --- Include further explanation 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: Mon, 21 Oct 2013 02:43:31 -0000 #124: draft-ietf-roll-security-threats-01.txt --- Include further explanation Comment (by mcr@sandelman.ca): section 5.3.4/8.3.4: removed geographic information is ideal, as it is seldom trustworthy, and may not, as mentioned in the comment, not even be desireable (ethernet faster than wireless). -- -------------------------------------+------------------------------------- Reporter: | Owner: mariainesrobles@gmail.com | tzeta.tsao@cooperindustries.com Type: defect | Status: new Priority: major | Milestone: Component: security-threats | Version: Severity: Active WG Document | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: roll From trac+roll@trac.tools.ietf.org Sun Oct 20 19:51: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 006F011E8320 for ; Sun, 20 Oct 2013 19:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XPtNKmPKzYj0 for ; Sun, 20 Oct 2013 19:51:01 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 165D811E8118 for ; Sun, 20 Oct 2013 19:51:01 -0700 (PDT) Received: from localhost ([127.0.0.1]:33000 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VY5a5-0006ue-OQ; Mon, 21 Oct 2013 04:50:57 +0200 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: tzeta.tsao@cooperindustries.com, mariainesrobles@gmail.com, mcr@sandelman.ca X-Trac-Project: roll Date: Mon, 21 Oct 2013 02:50:57 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/124#comment:7 Message-ID: <082.7b46744293dc0012b6f7e2b973333ca5@trac.tools.ietf.org> References: <067.fdab363d655b1902d82f78e9aebff2a7@trac.tools.ietf.org> X-Trac-Ticket-ID: 124 In-Reply-To: <067.fdab363d655b1902d82f78e9aebff2a7@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: tzeta.tsao@cooperindustries.com, mariainesrobles@gmail.com, mcr@sandelman.ca, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #124: draft-ietf-roll-security-threats-01.txt --- Include further explanation 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: Mon, 21 Oct 2013 02:51:02 -0000 #124: draft-ietf-roll-security-threats-01.txt --- Include further explanation Comment (by mcr@sandelman.ca): 5.3.5/8.3.5: I agree: a stable wormhole that does not lead to cuthulu is a feature... it is the instability that could be a problem, and RPL has hystersis (MRHOF) to deal with this. -- -------------------------------------+------------------------------------- Reporter: | Owner: mariainesrobles@gmail.com | tzeta.tsao@cooperindustries.com Type: defect | Status: new Priority: major | Milestone: Component: security-threats | Version: Severity: Active WG Document | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: roll From trac+roll@trac.tools.ietf.org Sun Oct 20 19:54: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 D19B411E8126 for ; Sun, 20 Oct 2013 19:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.49 X-Spam-Level: X-Spam-Status: No, score=-101.49 tagged_above=-999 required=5 tests=[AWL=-1.109, BAYES_00=-2.599, TVD_SPACE_RATIO=2.219, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T1XTs-F8SIrp for ; Sun, 20 Oct 2013 19:54:02 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 370CF11E8471 for ; Sun, 20 Oct 2013 19:54:00 -0700 (PDT) Received: from localhost ([127.0.0.1]:33371 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VY5d0-0002M6-E0; Mon, 21 Oct 2013 04:53:58 +0200 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: tzeta.tsao@cooperindustries.com, mariainesrobles@gmail.com, mcr@sandelman.ca X-Trac-Project: roll Date: Mon, 21 Oct 2013 02:53:58 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/124#comment:8 Message-ID: <082.42fdca36d346d1c9874d8f69e6577271@trac.tools.ietf.org> References: <067.fdab363d655b1902d82f78e9aebff2a7@trac.tools.ietf.org> X-Trac-Ticket-ID: 124 In-Reply-To: <067.fdab363d655b1902d82f78e9aebff2a7@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: tzeta.tsao@cooperindustries.com, mariainesrobles@gmail.com, mcr@sandelman.ca, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #124: draft-ietf-roll-security-threats-01.txt --- Include further explanation 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: Mon, 21 Oct 2013 02:54:02 -0000 #124: draft-ietf-roll-security-threats-01.txt --- Include further explanation Comment (by mcr@sandelman.ca): Geopriv/RFC3693 reference removed. -- -------------------------------------+------------------------------------- Reporter: | Owner: mariainesrobles@gmail.com | tzeta.tsao@cooperindustries.com Type: defect | Status: new Priority: major | Milestone: Component: security-threats | Version: Severity: Active WG Document | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: roll From trac+roll@trac.tools.ietf.org Sun Oct 20 20:14:54 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 8397B11E8333 for ; Sun, 20 Oct 2013 20:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.507 X-Spam-Level: X-Spam-Status: No, score=-102.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zsoC67kEogg8 for ; Sun, 20 Oct 2013 20:14:54 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 3958B11E8126 for ; Sun, 20 Oct 2013 20:14:51 -0700 (PDT) Received: from localhost ([127.0.0.1]:35296 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VY5x6-0001Y9-Gq; Mon, 21 Oct 2013 05:14:45 +0200 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: tzeta.tsao@cooperindustries.com, mariainesrobles@gmail.com, mcr@sandelman.ca X-Trac-Project: roll Date: Mon, 21 Oct 2013 03:14:44 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/124#comment:9 Message-ID: <082.9273644d652e69f6bb59919cb09e45b4@trac.tools.ietf.org> References: <067.fdab363d655b1902d82f78e9aebff2a7@trac.tools.ietf.org> X-Trac-Ticket-ID: 124 In-Reply-To: <067.fdab363d655b1902d82f78e9aebff2a7@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: tzeta.tsao@cooperindustries.com, mariainesrobles@gmail.com, mcr@sandelman.ca, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #124: draft-ietf-roll-security-threats-01.txt --- Include further explanation 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: Mon, 21 Oct 2013 03:14:54 -0000 #124: draft-ietf-roll-security-threats-01.txt --- Include further explanation Comment (by mcr@sandelman.ca): Section 6.2/9.2: removed suggestion about transitive trust. Logging is a major can of worms, probably requiring another WG document with a MIB! -- -------------------------------------+------------------------------------- Reporter: | Owner: mariainesrobles@gmail.com | tzeta.tsao@cooperindustries.com Type: defect | Status: new Priority: major | Milestone: Component: security-threats | Version: Severity: Active WG Document | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: roll From trac+roll@trac.tools.ietf.org Sun Oct 20 20:20: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 A7EFC11E8472 for ; Sun, 20 Oct 2013 20:20:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.514 X-Spam-Level: X-Spam-Status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GiBxlsUWxguO for ; Sun, 20 Oct 2013 20:20:04 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id D4C6D11E8484 for ; Sun, 20 Oct 2013 20:20:01 -0700 (PDT) Received: from localhost ([127.0.0.1]:35904 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VY62B-0005Xb-NI; Mon, 21 Oct 2013 05:19:59 +0200 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: tzeta.tsao@cooperindustries.com, mariainesrobles@gmail.com, mcr@sandelman.ca X-Trac-Project: roll Date: Mon, 21 Oct 2013 03:19:59 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/124#comment:10 Message-ID: <082.f0ce7d24991c634265e3957ff1a6946c@trac.tools.ietf.org> References: <067.fdab363d655b1902d82f78e9aebff2a7@trac.tools.ietf.org> X-Trac-Ticket-ID: 124 In-Reply-To: <067.fdab363d655b1902d82f78e9aebff2a7@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: tzeta.tsao@cooperindustries.com, mariainesrobles@gmail.com, mcr@sandelman.ca, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #124: draft-ietf-roll-security-threats-01.txt --- Include further explanation 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: Mon, 21 Oct 2013 03:20:04 -0000 #124: draft-ietf-roll-security-threats-01.txt --- Include further explanation Comment (by mcr@sandelman.ca): section 6.4/9.4: is stuff that seems to be left over from some author of this document thinking that this was requirements for 6550, rather than analysis of mechanisms available in 6550. -- -------------------------------------+------------------------------------- Reporter: | Owner: mariainesrobles@gmail.com | tzeta.tsao@cooperindustries.com Type: defect | Status: new Priority: major | Milestone: Component: security-threats | Version: Severity: Active WG Document | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: roll From trac+roll@trac.tools.ietf.org Sun Oct 20 20:21: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 8378B11E848B for ; Sun, 20 Oct 2013 20:21:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.52 X-Spam-Level: X-Spam-Status: No, score=-102.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zPPLkYFwVb17 for ; Sun, 20 Oct 2013 20:21:50 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 75D1211E8485 for ; Sun, 20 Oct 2013 20:21:45 -0700 (PDT) Received: from localhost ([127.0.0.1]:36054 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VY63r-0000NS-7y; Mon, 21 Oct 2013 05:21:43 +0200 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: tzeta.tsao@cooperindustries.com, mariainesrobles@gmail.com, mcr@sandelman.ca X-Trac-Project: roll Date: Mon, 21 Oct 2013 03:21:43 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/124#comment:11 Message-ID: <082.2961d43ad8bd738a73d980497a1bc018@trac.tools.ietf.org> References: <067.fdab363d655b1902d82f78e9aebff2a7@trac.tools.ietf.org> X-Trac-Ticket-ID: 124 In-Reply-To: <067.fdab363d655b1902d82f78e9aebff2a7@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: tzeta.tsao@cooperindustries.com, mariainesrobles@gmail.com, mcr@sandelman.ca, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #124: draft-ietf-roll-security-threats-01.txt --- Include further explanation 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: Mon, 21 Oct 2013 03:21:50 -0000 #124: draft-ietf-roll-security-threats-01.txt --- Include further explanation Comment (by mcr@sandelman.ca): > > === Section 6.5.1[[BR]] > *This draft boils down to this paragraph if I'm not mistaken: > > A ROLL protocol MUST be made flexible by a design that offers the > configuration facility so that the user (network administrator) can > choose the security settings that match the application's needs. > Furthermore, in the case of LLNs, that flexibility SHOULD extend to > allowing the routing protocol security requirements to be met by > measures applied at different protocol layers, provided the > identified requirements are collectively met. > > I'm absolutely fine with the first sentence. I'm even okay with the second > sentence it gets done at the application layer all the time, but at the > application layer they can all point to something that's all specified up and > has MTI etc (think TLS). If we end up doing that here then something similar > needs to end up happening. If use cases are so broad that they can't possibly > pick an underlying security mechanism then you need to try again but with a > smaller net. -- by ST Needs further discussion over beer. -- -------------------------------------+------------------------------------- Reporter: | Owner: mariainesrobles@gmail.com | tzeta.tsao@cooperindustries.com Type: defect | Status: new Priority: major | Milestone: Component: security-threats | Version: Severity: Active WG Document | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: roll From trac+roll@trac.tools.ietf.org Sun Oct 20 20:22: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 8F9D411E8472 for ; Sun, 20 Oct 2013 20:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qaK3Yr1wYl-o for ; Sun, 20 Oct 2013 20:22:11 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 9FCD411E8480 for ; Sun, 20 Oct 2013 20:22:08 -0700 (PDT) Received: from localhost ([127.0.0.1]:36066 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VY64D-0008RM-Mt; Mon, 21 Oct 2013 05:22:05 +0200 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: mcr@sandelman.ca, mariainesrobles@gmail.com X-Trac-Project: roll Date: Mon, 21 Oct 2013 03:22:05 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/124#comment:12 Message-ID: <082.3fdd40ba264e6437950041064416b5f8@trac.tools.ietf.org> References: <067.fdab363d655b1902d82f78e9aebff2a7@trac.tools.ietf.org> X-Trac-Ticket-ID: 124 In-Reply-To: <067.fdab363d655b1902d82f78e9aebff2a7@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: mcr@sandelman.ca, mariainesrobles@gmail.com, tzeta.tsao@cooperindustries.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org, tzeta.tsao@cooperindustries.com Subject: Re: [Roll] [roll] #124: draft-ietf-roll-security-threats-01.txt --- Include further explanation 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: Mon, 21 Oct 2013 03:22:11 -0000 #124: draft-ietf-roll-security-threats-01.txt --- Include further explanation Changes (by mcr@sandelman.ca): * owner: tzeta.tsao@cooperindustries.com => mcr@sandelman.ca * status: new => assigned -- ---------------------------------------+------------------------------- Reporter: mariainesrobles@gmail.com | Owner: mcr@sandelman.ca Type: defect | Status: assigned Priority: major | Milestone: Component: security-threats | Version: Severity: Active WG Document | Resolution: Keywords: | ---------------------------------------+------------------------------- Ticket URL: roll From trac+roll@trac.tools.ietf.org Sun Oct 20 20:27: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 56D9E11E8472 for ; Sun, 20 Oct 2013 20:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPEGk6MY8Apz for ; Sun, 20 Oct 2013 20:27:23 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 7E6FF11E8480 for ; Sun, 20 Oct 2013 20:27:22 -0700 (PDT) Received: from localhost ([127.0.0.1]:36849 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VY696-0002on-J3; Mon, 21 Oct 2013 05:27:08 +0200 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-security-threats@tools.ietf.org, mcr@sandelman.ca X-Trac-Project: roll Date: Mon, 21 Oct 2013 03:27:08 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/133 Message-ID: <058.3ebcd19f1f3fc0fef03bd4a4106009f7@trac.tools.ietf.org> X-Trac-Ticket-ID: 133 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-roll-security-threats@tools.ietf.org, mcr@sandelman.ca, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: angel.lozano@upf.edu, mcr+ietf@sandelman.ca, mischa.dohler@cttc.es, roger.alexander@cooperindustries.com, tzeta.tsao@cooperindustries.com, vanesa.daza@upf.edu Resent-Message-Id: <20131021032722.7E6FF11E8480@ietfa.amsl.com> Resent-Date: Sun, 20 Oct 2013 20:27:22 -0700 (PDT) Resent-From: trac+roll@trac.tools.ietf.org Cc: roll@ietf.org Subject: [Roll] [roll] #133: 9.5.1. Security Architecture 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: Mon, 21 Oct 2013 03:27:24 -0000 #133: 9.5.1. Security Architecture > === Section 9.5.1[[BR]] > *This draft boils down to this paragraph if I'm not mistaken: > > A ROLL protocol MUST be made flexible by a design that offers the > configuration facility so that the user (network administrator) can > choose the security settings that match the application's needs. > Furthermore, in the case of LLNs, that flexibility SHOULD extend to > allowing the routing protocol security requirements to be met by > measures applied at different protocol layers, provided the > identified requirements are collectively met. > > I'm absolutely fine with the first sentence. I'm even okay with the second > sentence it gets done at the application layer all the time, but at the > application layer they can all point to something that's all specified up and > has MTI etc (think TLS). If we end up doing that here then something similar > needs to end up happening. If use cases are so broad that they can't possibly > pick an underlying security mechanism then you need to try again but with a > smaller net. -- by ST It is not clear that any of 9.5.1 belongs anymore. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-roll-security- mcr@sandelman.ca | threats@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: security- | Version: threats | Keywords: Severity: Active WG | Document | -------------------------+------------------------------------------------- Ticket URL: roll From trac+roll@trac.tools.ietf.org Sun Oct 20 20:27: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 AC53B11E848E for ; Sun, 20 Oct 2013 20:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nmstr7MpSpBN for ; Sun, 20 Oct 2013 20:27:58 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 25D7111E8133 for ; Sun, 20 Oct 2013 20:27:58 -0700 (PDT) Received: from localhost ([127.0.0.1]:36875 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VY69r-0002h1-6P; Mon, 21 Oct 2013 05:27:55 +0200 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: mcr@sandelman.ca, mariainesrobles@gmail.com X-Trac-Project: roll Date: Mon, 21 Oct 2013 03:27:55 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/124#comment:13 Message-ID: <082.56d72fff731b0adb59af5b42bfc10b3c@trac.tools.ietf.org> References: <067.fdab363d655b1902d82f78e9aebff2a7@trac.tools.ietf.org> X-Trac-Ticket-ID: 124 In-Reply-To: <067.fdab363d655b1902d82f78e9aebff2a7@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: mcr@sandelman.ca, mariainesrobles@gmail.com, tzeta.tsao@cooperindustries.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org, tzeta.tsao@cooperindustries.com Subject: Re: [Roll] [roll] #124: draft-ietf-roll-security-threats-01.txt --- Include further explanation 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: Mon, 21 Oct 2013 03:27:58 -0000 #124: draft-ietf-roll-security-threats-01.txt --- Include further explanation Changes (by mcr@sandelman.ca): * status: assigned => closed * resolution: => fixed Comment: Ticket #133 opened with last bit. -- ---------------------------------------+------------------------------- Reporter: mariainesrobles@gmail.com | Owner: mcr@sandelman.ca Type: defect | Status: closed Priority: major | Milestone: Component: security-threats | Version: Severity: Active WG Document | Resolution: fixed Keywords: | ---------------------------------------+------------------------------- Ticket URL: roll From trac+roll@trac.tools.ietf.org Sun Oct 20 20:31: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 E0A0711E8332 for ; Sun, 20 Oct 2013 20:31:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNzmDVj0evra for ; Sun, 20 Oct 2013 20:31:02 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 573B211E8133 for ; Sun, 20 Oct 2013 20:31:02 -0700 (PDT) Received: from localhost ([127.0.0.1]:37004 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VY6Co-000221-Iv; Mon, 21 Oct 2013 05:30:58 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit 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: mcr@sandelman.ca, mariainesrobles@gmail.com X-Trac-Project: roll Date: Mon, 21 Oct 2013 03:30:58 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/115#comment:5 Message-ID: <082.f337dff8e5b3ea8106030e3c5f7453ce@trac.tools.ietf.org> References: <067.b8704d3db60284c62fffde3d26abf9e1@trac.tools.ietf.org> X-Trac-Ticket-ID: 115 In-Reply-To: <067.b8704d3db60284c62fffde3d26abf9e1@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: mcr@sandelman.ca, mariainesrobles@gmail.com, tzeta.tsao@cooperindustries.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org, tzeta.tsao@cooperindustries.com Subject: Re: [Roll] [roll] #115: draft-ietf-roll-security-threats-01.txt --- Editorial Comments 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: Mon, 21 Oct 2013 03:31:03 -0000 #115: draft-ietf-roll-security-threats-01.txt --- Editorial Comments Comment (by mcr@sandelman.ca): Replying to [ticket:115 mariainesrobles@…]: > === Section 4.1 [[BR]] > * 4.1- the authors should use technical terminology from 4949, since they went to the trouble to cite in various places, e.g., replace “sniffing” with “passive wiretapping,” both here and throughput the document.--by SK > Done. -- ---------------------------------------+------------------------------- Reporter: mariainesrobles@gmail.com | Owner: mcr@sandelman.ca Type: defect | Status: assigned Priority: minor | Milestone: Component: security-threats | Version: Severity: Active WG Document | Resolution: Keywords: Editorial | ---------------------------------------+------------------------------- Ticket URL: roll From trac+roll@trac.tools.ietf.org Sun Oct 20 20:33:26 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C92E11E8477 for ; Sun, 20 Oct 2013 20:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OwOOzOkzl5CF for ; Sun, 20 Oct 2013 20:33:20 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 5C42011E8332 for ; Sun, 20 Oct 2013 20:33:20 -0700 (PDT) Received: from localhost ([127.0.0.1]:37277 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VY6F3-00076K-8J; Mon, 21 Oct 2013 05:33:17 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit 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: mcr@sandelman.ca, mariainesrobles@gmail.com X-Trac-Project: roll Date: Mon, 21 Oct 2013 03:33:17 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/115#comment:6 Message-ID: <082.ae99e66fdcec5d0063189cd6d6df7014@trac.tools.ietf.org> References: <067.b8704d3db60284c62fffde3d26abf9e1@trac.tools.ietf.org> X-Trac-Ticket-ID: 115 In-Reply-To: <067.b8704d3db60284c62fffde3d26abf9e1@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: mcr@sandelman.ca, mariainesrobles@gmail.com, tzeta.tsao@cooperindustries.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org, tzeta.tsao@cooperindustries.com Subject: Re: [Roll] [roll] #115: draft-ietf-roll-security-threats-01.txt --- Editorial Comments 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: Mon, 21 Oct 2013 03:33:26 -0000 #115: draft-ietf-roll-security-threats-01.txt --- Editorial Comments Comment (by mcr@sandelman.ca): Replying to [ticket:115 mariainesrobles@…]: > === Section 5.1.3 [[BR]] > * 5.1.3 - TA is always a passive attack, so the description here “… may be passive…” is wrong. --by SK Done. > === Section 5.2.3 [[BR]] > * 5.2.3 – “liveliness” -> “liveness” --by SK done. -- ---------------------------------------+------------------------------- Reporter: mariainesrobles@gmail.com | Owner: mcr@sandelman.ca Type: defect | Status: assigned Priority: minor | Milestone: Component: security-threats | Version: Severity: Active WG Document | Resolution: Keywords: Editorial | ---------------------------------------+------------------------------- Ticket URL: roll From trac+roll@trac.tools.ietf.org Sun Oct 20 20:37: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 6BD3911E8495 for ; Sun, 20 Oct 2013 20:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l6NOF-pp4qVy for ; Sun, 20 Oct 2013 20:37:07 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 2E3AC11E82BE for ; Sun, 20 Oct 2013 20:37:04 -0700 (PDT) Received: from localhost ([127.0.0.1]:37779 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VY6If-0005CL-M5; Mon, 21 Oct 2013 05:37:01 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit 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: mcr@sandelman.ca, mariainesrobles@gmail.com X-Trac-Project: roll Date: Mon, 21 Oct 2013 03:37:01 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/119#comment:5 Message-ID: <082.60245dd6504e2987146c4c2acb2e9591@trac.tools.ietf.org> References: <067.8571ad6f4d633472ef48478791cc6332@trac.tools.ietf.org> X-Trac-Ticket-ID: 119 In-Reply-To: <067.8571ad6f4d633472ef48478791cc6332@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: mcr@sandelman.ca, mariainesrobles@gmail.com, tzeta.tsao@cooperindustries.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org, tzeta.tsao@cooperindustries.com Subject: Re: [Roll] [roll] #119: draft-ietf-roll-security-threats-01.txt --- Verify abstraction/superficial terms 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: Mon, 21 Oct 2013 03:37:07 -0000 #119: draft-ietf-roll-security-threats-01.txt --- Verify abstraction/superficial terms Comment (by mcr@sandelman.ca): Replying to [ticket:119 mariainesrobles@…]: > === Section 3.1[[BR]] > * Verify abstraction/superficial terms > > === Section 5.2.1[[BR]] > * 5.2.1 – the discussion here is very superficial, not as thorough as the subsections in 5.1. > > === Section 5.2.2[[BR]] > * 5.2.2 – This discussion is very superficial as well. > > === Section 5.2.3[[BR]] > * 5.2.3 –The discussion of the use of public key technology vs. symmetric cryptographic mechanisms for authentication is vastly oversimplified, and thus not very useful. much rewriting of these sections done. -- ---------------------------------------+------------------------------- Reporter: mariainesrobles@gmail.com | Owner: mcr@sandelman.ca Type: defect | Status: assigned Priority: minor | Milestone: Component: security-threats | Version: Severity: Active WG Document | Resolution: Keywords: | ---------------------------------------+------------------------------- Ticket URL: roll From trac+roll@trac.tools.ietf.org Sun Oct 20 20:37:26 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE7111E8135 for ; Sun, 20 Oct 2013 20:37:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.546 X-Spam-Level: X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1KwJ8pPBglEn for ; Sun, 20 Oct 2013 20:37:15 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 12A5911E849C for ; Sun, 20 Oct 2013 20:37:13 -0700 (PDT) Received: from localhost ([127.0.0.1]:37789 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VY6In-0007Qa-Hc; Mon, 21 Oct 2013 05:37:09 +0200 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: mcr@sandelman.ca, mariainesrobles@gmail.com X-Trac-Project: roll Date: Mon, 21 Oct 2013 03:37:09 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/119#comment:6 Message-ID: <082.d63270af44b14c953a1b58519de01846@trac.tools.ietf.org> References: <067.8571ad6f4d633472ef48478791cc6332@trac.tools.ietf.org> X-Trac-Ticket-ID: 119 In-Reply-To: <067.8571ad6f4d633472ef48478791cc6332@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: mcr@sandelman.ca, mariainesrobles@gmail.com, tzeta.tsao@cooperindustries.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org, tzeta.tsao@cooperindustries.com Subject: Re: [Roll] [roll] #119: draft-ietf-roll-security-threats-01.txt --- Verify abstraction/superficial terms 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: Mon, 21 Oct 2013 03:37:27 -0000 #119: draft-ietf-roll-security-threats-01.txt --- Verify abstraction/superficial terms Changes (by mcr@sandelman.ca): * status: assigned => closed * resolution: => fixed -- ---------------------------------------+------------------------------- Reporter: mariainesrobles@gmail.com | Owner: mcr@sandelman.ca Type: defect | Status: closed Priority: minor | Milestone: Component: security-threats | Version: Severity: Active WG Document | Resolution: fixed Keywords: | ---------------------------------------+------------------------------- Ticket URL: roll From trac+roll@trac.tools.ietf.org Sun Oct 20 20:45:10 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 476AA11E8142 for ; Sun, 20 Oct 2013 20:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3xZ0UGfC8n5u for ; Sun, 20 Oct 2013 20:45:08 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id E28A711E8135 for ; Sun, 20 Oct 2013 20:45:01 -0700 (PDT) Received: from localhost ([127.0.0.1]:38379 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VY6QK-0006a9-BY; Mon, 21 Oct 2013 05:44:56 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit 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: mcr@sandelman.ca, mariainesrobles@gmail.com X-Trac-Project: roll Date: Mon, 21 Oct 2013 03:44:56 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/116#comment:4 Message-ID: <082.63e53bfa1cc31ff13290fc3bdd472172@trac.tools.ietf.org> References: <067.d6cfe14f83c6ca306e7f0311d9ee1435@trac.tools.ietf.org> X-Trac-Ticket-ID: 116 In-Reply-To: <067.d6cfe14f83c6ca306e7f0311d9ee1435@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: mcr@sandelman.ca, mariainesrobles@gmail.com, tzeta.tsao@cooperindustries.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org, tzeta.tsao@cooperindustries.com Subject: Re: [Roll] [roll] #116: draft-ietf-roll-security-threats-01.txt --- Include/fix/verify definitions/terms 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: Mon, 21 Oct 2013 03:45:10 -0000 #116: draft-ietf-roll-security-threats-01.txt --- Include/fix/verify definitions/terms Comment (by mcr@sandelman.ca): Replying to [comment:1 mariainesrobles@…]: > == Section 3.1 [[BR]] > > The goal of the data flow diagram (Figure 1) was modified, an asset was added (route generation process).[[BR]] > > Database is not listed in node resources. "node" without a qualifier seems still missing. Got rid of "database" as a generic term. -- ---------------------------------------+------------------------------- Reporter: mariainesrobles@gmail.com | Owner: mcr@sandelman.ca Type: defect | Status: assigned Priority: minor | Milestone: Component: security-threats | Version: Severity: Active WG Document | Resolution: Keywords: | ---------------------------------------+------------------------------- Ticket URL: roll From trac+roll@trac.tools.ietf.org Sun Oct 20 20:49:35 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C67211E813D for ; Sun, 20 Oct 2013 20:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kafi3QXckk6E for ; Sun, 20 Oct 2013 20:49:34 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 80B2311E8132 for ; Sun, 20 Oct 2013 20:49:34 -0700 (PDT) Received: from localhost ([127.0.0.1]:38799 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VY6Ul-0005IH-2F; Mon, 21 Oct 2013 05:49:31 +0200 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: mcr@sandelman.ca, mariainesrobles@gmail.com X-Trac-Project: roll Date: Mon, 21 Oct 2013 03:49:31 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/116#comment:5 Message-ID: <082.1ba768d2c1198e2ac4ae58f6641ad1a4@trac.tools.ietf.org> References: <067.d6cfe14f83c6ca306e7f0311d9ee1435@trac.tools.ietf.org> X-Trac-Ticket-ID: 116 In-Reply-To: <067.d6cfe14f83c6ca306e7f0311d9ee1435@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: mcr@sandelman.ca, mariainesrobles@gmail.com, tzeta.tsao@cooperindustries.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org, tzeta.tsao@cooperindustries.com Subject: Re: [Roll] [roll] #116: draft-ietf-roll-security-threats-01.txt --- Include/fix/verify definitions/terms 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: Mon, 21 Oct 2013 03:49:35 -0000 #116: draft-ietf-roll-security-threats-01.txt --- Include/fix/verify definitions/terms Comment (by mcr@sandelman.ca): Many changes made. -- ---------------------------------------+------------------------------- Reporter: mariainesrobles@gmail.com | Owner: mcr@sandelman.ca Type: defect | Status: assigned Priority: minor | Milestone: Component: security-threats | Version: Severity: Active WG Document | Resolution: Keywords: | ---------------------------------------+------------------------------- Ticket URL: roll From trac+roll@trac.tools.ietf.org Sun Oct 20 20:49: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 4A3B511E8494 for ; Sun, 20 Oct 2013 20:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OvJQ+eEVFuj1 for ; Sun, 20 Oct 2013 20:49:39 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 63B0611E848B for ; Sun, 20 Oct 2013 20:49:39 -0700 (PDT) Received: from localhost ([127.0.0.1]:38811 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VY6Uq-00077k-Mq; Mon, 21 Oct 2013 05:49:36 +0200 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: mcr@sandelman.ca, mariainesrobles@gmail.com X-Trac-Project: roll Date: Mon, 21 Oct 2013 03:49:36 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/116#comment:6 Message-ID: <082.3c2cd73663fdeac30f15c2fc3a5baf06@trac.tools.ietf.org> References: <067.d6cfe14f83c6ca306e7f0311d9ee1435@trac.tools.ietf.org> X-Trac-Ticket-ID: 116 In-Reply-To: <067.d6cfe14f83c6ca306e7f0311d9ee1435@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: mcr@sandelman.ca, mariainesrobles@gmail.com, tzeta.tsao@cooperindustries.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org, tzeta.tsao@cooperindustries.com Subject: Re: [Roll] [roll] #116: draft-ietf-roll-security-threats-01.txt --- Include/fix/verify definitions/terms 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: Mon, 21 Oct 2013 03:49:40 -0000 #116: draft-ietf-roll-security-threats-01.txt --- Include/fix/verify definitions/terms Changes (by mcr@sandelman.ca): * status: assigned => closed * resolution: => fixed -- ---------------------------------------+------------------------------- Reporter: mariainesrobles@gmail.com | Owner: mcr@sandelman.ca Type: defect | Status: closed Priority: minor | Milestone: Component: security-threats | Version: Severity: Active WG Document | Resolution: fixed Keywords: | ---------------------------------------+------------------------------- Ticket URL: roll From internet-drafts@ietf.org Mon Oct 21 06:12:49 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 419E211E8509; Mon, 21 Oct 2013 06:12:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTMCYNwF7ICe; Mon, 21 Oct 2013 06:12:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B99311E8561; Mon, 21 Oct 2013 06:10:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131021131031.29534.26555.idtracker@ietfa.amsl.com> Date: Mon, 21 Oct 2013 06:10:31 -0700 Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-security-threats-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 13:12:49 -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 Michael Richardson Filename : draft-ietf-roll-security-threats-05.txt Pages : 43 Date : 2013-10-21 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-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-security-threats-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Oct 21 08:54:57 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E37A311E8559; Mon, 21 Oct 2013 08:54:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2oVQJiYQYjr; Mon, 21 Oct 2013 08:54:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6867311E863D; Mon, 21 Oct 2013 08:54:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131021155433.29482.97616.idtracker@ietfa.amsl.com> Date: Mon, 21 Oct 2013 08:54:33 -0700 Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-rpl-industrial-applicability-02.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 15:54:58 -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 : RPL applicability in industrial networks Author(s) : Tom Phinney Pascal Thubert Robert Assimiti Filename : draft-ietf-roll-rpl-industrial-applicability-02.txt Pages : 31 Date : 2013-10-21 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 field devices. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-rpl-industrial-applicabili= ty There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-roll-rpl-industrial-applicability-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-rpl-industrial-applicabi= lity-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From pthubert@cisco.com Mon Oct 21 09:08: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 242BD11E81BF; Mon, 21 Oct 2013 09:08:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.506 X-Spam-Level: X-Spam-Status: No, score=-10.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id stpapxpFNeus; Mon, 21 Oct 2013 09:08:07 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 6820311E8645; Mon, 21 Oct 2013 09:06:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3458; q=dns/txt; s=iport; t=1382371616; x=1383581216; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=CL1LSIprmnw/N3ViVyjtO31VFMYKV9DvILi0qz/QCGM=; b=Dg9t7OIqacqYrfVwvSBDVqGumGZ/W6fznkczp1qeufg0uTPhwxA+z773 GgYph0v1lM2CoWnQ8KLF3MtvuBxO4glUbhDJMfFouwvGWhOaRAczZXjxp Ve8t5YQ8iJf8kDsm1FiYqE6IabLkRqCLk0Jcud+BmPcyvFYGOMhB21lCJ Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQFAH5QZVKtJV2d/2dsb2JhbABZgwc4VIMquwUYgRYWdIIlAQEBBCMRQwIMBgEZBAEBAwIGHQMCBDAUAQgJAQQBDQUIAYd9DadDkjyBKYx0B4EHMQ2CZDWBCgOZOJBYgWaBPoFoQg X-IronPort-AV: E=Sophos;i="4.93,539,1378857600"; d="scan'208";a="274752155" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP; 21 Oct 2013 16:06:36 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r9LG6aWJ020380 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 21 Oct 2013 16:06:36 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.2]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Mon, 21 Oct 2013 11:06:35 -0500 From: "Pascal Thubert (pthubert)" To: "JP Vasseur (jvasseur)" , Michael Richardson , "Tom Phinney (tom.phinney@COX.NET)" , "Robert Assimiti " Thread-Topic: New Version Notification for draft-ietf-roll-rpl-industrial-applicability-02.txt Thread-Index: Ac7OdxRRNqDiXpnHQQiGrAx1R0dBBw== Date: Mon, 21 Oct 2013 16:04:44 +0000 Deferred-Delivery: Mon, 21 Oct 2013 16:04: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.61.170.31] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "6tisch@ietf.org" <6tisch@ietf.org>, Routing Over Low power and Lossy networks Subject: [Roll] New Version Notification for draft-ietf-roll-rpl-industrial-applicability-02.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 16:08:14 -0000 RGVhciBST0xMIGNoYWlyczoNCg0KSW4gdGhpcyBuZXcgdmVyc2lvbiwgSSBjbG9zZWQgdGhlIG9w ZW5lZCBnYXBzLCBtb3N0bHkgcmVsYXRlZCB0byBMMiBvcGVyYXRpb25zLCBhbmQgcGxhY2VkIHJl ZmVyZW5jZXMgdG8gdGhlIDZUaVNDSCB3b3JrLCB0aGF0IGhhcyBub3cgc3RhcnRlZCBhbmQgaXMg dGFraW5nIG92ZXIgZm9yIHRoYXQgTExDIHJlbGF0ZWQgbWF0dGVycy4gQXMgaXQgZ29lcywgZHJh ZnQtaWV0Zi1yb2xsLXJwbC1pbmR1c3RyaWFsLWFwcGxpY2FiaWxpdHkgcHJvYmFibHkgd2VudCBh cyBmYXIgYXMgaXQgY291bGQgZ28gd2l0aCB0aGUgZmVlZGJhY2sgd2UgZ290IGZyb20gdGhlIGxp bWl0ZWQgZXhpc3RpbmcgZGVwbG95bWVudHMsIGFuZCBpdCBpcyBwcm9iYWJseSB0aW1lIHRvIGNv bmNsdWRlIGFuZCBwYXNzIHRoZSBiYWxsIHRvIDZUaVNDSCwgd2hpY2ggdGhpcyB3b3JrIGRlZmlu aXRlbHkgY29udHJpYnV0ZWQgdG8gZm9ybS4NCg0KSSB0aGluayB0aGUgZG9jIGlzIG5vdyByaXBl IGZvciBsYXN0IGNhbGwuIA0KDQpXaGF0IGRvIHlvdSBsIHRoaW5rPw0KDQpQYXNjYWwNCg0KDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn IFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IGx1bmRpIDIxIG9jdG9i cmUgMjAxMyAxNzo1NQ0KVG86IFRvbSBQaGlubmV5OyBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQp OyBSb2JlcnQgQXNzaW1pdGkNClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3Ig ZHJhZnQtaWV0Zi1yb2xsLXJwbC1pbmR1c3RyaWFsLWFwcGxpY2FiaWxpdHktMDIudHh0DQoNCg0K QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWlldGYtcm9sbC1ycGwtaW5kdXN0cmlhbC1hcHBs aWNhYmlsaXR5LTAyLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBUb20g UGhpbm5leSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkg ZHJhZnQtaWV0Zi1yb2xsLXJwbC1pbmR1c3RyaWFsLWFwcGxpY2FiaWxpdHkNClJldmlzaW9uOgkg MDINClRpdGxlOgkJIFJQTCBhcHBsaWNhYmlsaXR5IGluIGluZHVzdHJpYWwgbmV0d29ya3MNCkNy ZWF0aW9uIGRhdGU6CSAyMDEzLTEwLTIxDQpHcm91cDoJCSByb2xsDQpOdW1iZXIgb2YgcGFnZXM6 IDMxDQpVUkw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz L2RyYWZ0LWlldGYtcm9sbC1ycGwtaW5kdXN0cmlhbC1hcHBsaWNhYmlsaXR5LTAyLnR4dA0KU3Rh dHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYt cm9sbC1ycGwtaW5kdXN0cmlhbC1hcHBsaWNhYmlsaXR5DQpIdG1saXplZDogICAgICAgIGh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcm9sbC1ycGwtaW5kdXN0cmlhbC1hcHBs aWNhYmlsaXR5LTAyDQpEaWZmOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlm Zj91cmwyPWRyYWZ0LWlldGYtcm9sbC1ycGwtaW5kdXN0cmlhbC1hcHBsaWNhYmlsaXR5LTAyDQoN CkFic3RyYWN0Og0KICAgVGhlIHdpZGUgZGVwbG95bWVudCBvZiB3aXJlbGVzcyBkZXZpY2VzLCB3 aXRoIHRoZWlyIGxvdyBpbnN0YWxsZWQNCiAgIGNvc3QgKGNvbXBhcmVkIHRvIHdpcmVkIGRldmlj ZXMpLCB3aWxsIHNpZ25pZmljYW50bHkgaW1wcm92ZSB0aGUNCiAgIHByb2R1Y3Rpdml0eSBhbmQg c2FmZXR5IG9mIGluZHVzdHJpYWwgcGxhbnRzLiAgSXQgd2lsbCBzaW11bHRhbmVvdXNseQ0KICAg aW5jcmVhc2UgdGhlIGVmZmljaWVuY3kgYW5kIHNhZmV0eSBvZiB0aGUgcGxhbnQncyB3b3JrZXJz LCBieQ0KICAgZXh0ZW5kaW5nIGFuZCBtYWtpbmcgbW9yZSB0aW1lbHkgdGhlIGluZm9ybWF0aW9u IHNldCBhdmFpbGFibGUgYWJvdXQNCiAgIHBsYW50IG9wZXJhdGlvbnMuICBUaGUgbmV3IFJvdXRp bmcgUHJvdG9jb2wgZm9yIExvdyBQb3dlciBhbmQgTG9zc3kNCiAgIE5ldHdvcmtzIChSUEwpIGRl ZmluZXMgYSBEaXN0YW5jZSBWZWN0b3IgcHJvdG9jb2wgdGhhdCBpcyBkZXNpZ25lZA0KICAgZm9y IHN1Y2ggbmV0d29ya3MuICBUaGUgYWltIG9mIHRoaXMgZG9jdW1lbnQgaXMgdG8gYW5hbHl6ZSB0 aGUNCiAgIGFwcGxpY2FiaWxpdHkgb2YgdGhhdCByb3V0aW5nIHByb3RvY29sIGluIGluZHVzdHJp YWwgTExOcyBmb3JtZWQgb2YNCiAgIGZpZWxkIGRldmljZXMuDQoNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1p bnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJz aW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRG IFNlY3JldGFyaWF0DQoNCg== From alexandru.petrescu@gmail.com Mon Oct 21 10:34: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 BAEF811E81DF for ; Mon, 21 Oct 2013 10:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.201 X-Spam-Level: X-Spam-Status: No, score=-10.201 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tpXDvc9q3kwi for ; Mon, 21 Oct 2013 10:34:15 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 7A22111E8219 for ; Mon, 21 Oct 2013 10:34:14 -0700 (PDT) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r9LHYDvS031359 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 21 Oct 2013 19:34:13 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r9LHYBLT003161 for ; Mon, 21 Oct 2013 19:34:11 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r9LHY7VT011536 for ; Mon, 21 Oct 2013 19:34:11 +0200 Message-ID: <5265658F.4030300@gmail.com> Date: Mon, 21 Oct 2013 19:34:07 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: roll@ietf.org References: <067.fdab363d655b1902d82f78e9aebff2a7@trac.tools.ietf.org> <082.f0ce7d24991c634265e3957ff1a6946c@trac.tools.ietf.org> In-Reply-To: <082.f0ce7d24991c634265e3957ff1a6946c@trac.tools.ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Roll] Announcing MPL evaluation results draft-roux-roll-mpl-eval-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 17:34:21 -0000 Dear ROLLers, We have just submitted draft-roux-roll-mpl-eval-00 about evaluation results of MPL, using an in-house simulator. draft-roux-roll-mpl-eval-00 "Preliminary results about MPL performance evaluation" Pierre Roux Alexandru Petrescu Mounir Kellil http://tools.ietf.org/html/draft-roux-roll-mpl-eval-00 Please comment. Yours, Alex, with co-authors. From trac+roll@trac.tools.ietf.org Mon Oct 21 11:21: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 5617811E8398 for ; Mon, 21 Oct 2013 11:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JXrx83pYTOeb for ; Mon, 21 Oct 2013 11:21:24 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 0F7A211E84A0 for ; Mon, 21 Oct 2013 11:21:18 -0700 (PDT) Received: from localhost ([127.0.0.1]:36837 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VYK6O-0006k2-7T; Mon, 21 Oct 2013 20:21:16 +0200 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: jonhui@cisco.com, mariainesrobles@gmail.com X-Trac-Project: roll Date: Mon, 21 Oct 2013 18:21:16 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/roll/trac/ticket/134 Message-ID: <067.8ed0ad50c483043cf2b4bacef0279070@trac.tools.ietf.org> X-Trac-Ticket-ID: 134 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: jonhui@cisco.com, mariainesrobles@gmail.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: [Roll] [roll] #134: draft-ietf-roll-trickle-mcast-05 - Minor editorial comments 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: Mon, 21 Oct 2013 18:21:25 -0000 #134: draft-ietf-roll-trickle-mcast-05 - Minor editorial comments From From: Kerry Lynn On Fri, 13 Sep 2013 08:10:03 -0400 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08155.html Editorial: - In section 4.3, on Proactive Forwarding, the phrase "MPL Data Message message" is redundant and should be "MPL Data Message". - In the last paragraph of section 4.3 the phrase "a new MPL Data messages" should be "a new MPL Data Message". - [I-D.droms-6man-multicast-scopes] should be moved from section 14.1 to 14.2. -- ---------------------------------------+------------------------------ Reporter: mariainesrobles@gmail.com | Owner: jonhui@cisco.com Type: defect | Status: new Priority: minor | Milestone: Component: trickle-mcast | Version: Severity: In WG Last Call | Keywords: ---------------------------------------+------------------------------ Ticket URL: roll From mariainesrobles@googlemail.com Mon Oct 21 11: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 0AACC11E8431 for ; Mon, 21 Oct 2013 11:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 84l2jWqfNm8P for ; Mon, 21 Oct 2013 11:43:23 -0700 (PDT) Received: from mail-vb0-x233.google.com (mail-vb0-x233.google.com [IPv6:2607:f8b0:400c:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 4E5C211E842F for ; Mon, 21 Oct 2013 11:43:05 -0700 (PDT) Received: by mail-vb0-f51.google.com with SMTP id x16so4192641vbf.24 for ; Mon, 21 Oct 2013 11:43:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=U+fCpo7OdHKfDP195Nka7O9vYxOpC8IE+SzYwzcJfLo=; b=GP9SKj1Tz16tZygrg5NBVvCW+x8M3zrQM7DRMQV3SXD3wuuaD9zB1fzGEUjXwRUQ2p okyDDqngR6YMy9tK/bs/k/NqL3X8aZIfwqcTqyDdVF6+S0COGvGLvsgM77Zxhs7JGv4U wwOEMy7tDdMS04BKiog2bK5kEeesVBbcdOd460vmH/QEP2TpHaAd28VwqrBp4yst3Hoa oRi22tT7E8jg7416+XIdAR1nuZ2yGuxJlGP5Z1aZCa+yNMn7jw5MUyWZ3NxTj517WMyK IOzxcaY9d1uzzDftem6rEAao5xy1gsycC72+DiVIR6FqY1ydOVlyVorPq7MdfOLSsVJE BAcw== MIME-Version: 1.0 X-Received: by 10.58.144.168 with SMTP id sn8mr148331veb.33.1382380981616; Mon, 21 Oct 2013 11:43:01 -0700 (PDT) Received: by 10.220.46.198 with HTTP; Mon, 21 Oct 2013 11:43:01 -0700 (PDT) Date: Mon, 21 Oct 2013 16:43:01 -0200 Message-ID: From: Ines Robles To: Michael Richardson , JP Vasseur Content-Type: multipart/alternative; boundary=047d7b5da93b5ab96f04e944a788 Cc: roll@ietf.org Subject: [Roll] Last Call: draft-ietf-roll-trickle-mcast-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 18:43:24 -0000 --047d7b5da93b5ab96f04e944a788 Content-Type: text/plain; charset=ISO-8859-1 Hello, Just a reminder, The IESG solicits final comments on this action. Please send substantive comments to the ietf at ietf.org mailing lists by 2013-10-24 -http://www.ietf.org/mail-archive/web/roll/current/msg08219.html So far, there are three open tickets: Ticket #103: trickle-mcast: suppress ICMP messages for PROACTIVE_TIMER_EXPIRATIONS Ticket #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local Ticket #134 draft-ietf-roll-trickle-mcast-05 - Minor editorial comments Thanks and Regards, Ines Robles. --047d7b5da93b5ab96f04e944a788 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello,<= div>
Just a reminder,=A0

The IESG = solicits final comments on this action. Please send substantive comments to= the ietf at ietf.org mailing lists by 2013-10-2= 4 -http://www.ietf.org/mail-archive/web/roll/current/msg08219.html<= /a>

= So far, there are three open tickets:<= /div>


Ticket #132:=A0

draft-ietf-rol= l-trickle-mcast-04 - Clarify scope value of 3 - subnet-local
Ticket=A0#134

draft-ietf-roll-trickle-mcast-0= 5 - Minor editorial comments


Thanks and Regards,

=
Ines Robles.
--047d7b5da93b5ab96f04e944a788-- From rdroms.ietf@gmail.com Wed Oct 23 06:05:44 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 A724011E836F for ; Wed, 23 Oct 2013 06:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id reN0ErSkIFt4 for ; Wed, 23 Oct 2013 06:05:43 -0700 (PDT) Received: from mail-qe0-x22a.google.com (mail-qe0-x22a.google.com [IPv6:2607:f8b0:400d:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 1B8F011E8375 for ; Wed, 23 Oct 2013 06:05:42 -0700 (PDT) Received: by mail-qe0-f42.google.com with SMTP id gc15so430004qeb.29 for ; Wed, 23 Oct 2013 06:05:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=ucRvPQ8SqBs+vUKNBg3OEvQJ7tgKhZqr/gog0uUfYz0=; b=kex8fxqBfSyEqdkz12bD8YwkzLxqtUWnWgbBstd8LGtxjI+ujkHZld1FczPlCFk4hV TVA9sUsYh/73LZvuBABrEhVf3kf3z2CEr8vCtgn+C6zrR09ciS9WVh5Hvav3CzGoL4e8 Mn3rA1qcVDovVo3utE5kLbTqpjGtBSJcOZMAs2GuvYh8/s7CeO+00im/DUiDrdsRtUlM PxzDaFWi6DXBfuMHblSf/m8WuR8R5h97959aIugearlDleA4RBVuPCAo6CYATL/WR08e HNhVYfA7/DuctplGbS4OnD2BILPtSPWihR2mG8c4LTGGIod3XSM7cEg7V8T6WGu/jX1P r3dQ== X-Received: by 10.224.160.83 with SMTP id m19mr2164137qax.108.1382533542600; Wed, 23 Oct 2013 06:05:42 -0700 (PDT) Received: from [10.86.252.81] (198-135-0-233.cisco.com. [198.135.0.233]) by mx.google.com with ESMTPSA id og1sm52584648qeb.3.2013.10.23.06.05.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Oct 2013 06:05:40 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Ralph Droms In-Reply-To: <06f53671b3a2a83e5c2dfe8a919a45fd@xs4all.nl> Date: Wed, 23 Oct 2013 09:05:36 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3E818BD0-34B0-4877-A5D2-86F9B35B6626@gmail.com> References: <3599.1381852752@sandelman.ca> <525DC6C9.2010808@gridmerge.com> <525E5064.4050109@gridmerge.com> <06f53671b3a2a83e5c2dfe8a919a45fd@xs4all.nl> To: consultancy@vanderstok.org, Routing Over Low power and Lossy networks X-Mailer: Apple Mail (2.1510) Subject: Re: [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - separate MPL from 0x3 scope definition X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 13:05:44 -0000 On Oct 17, 2013, at 8:21 AM 10/17/13, peter van der Stok = wrote: > Dear all, >=20 >=20 > Looking at the discussion there seem to be two issues: > -1 tunnelling MC messages through MPL domain > -2 Sending multicast to all members of a mesh >=20 > I suggest to separate them to make the progress of MPL draft = independent of 0x3 scope definition >=20 > Ad 1) > I understand that on reception by a seed of a MC message without MPL = option, the wish is to encapsulate the message with a header which = contains the MPL option to distribute the message over the mesh using = MPL. > At reception of the message each receiver still needs to check whether = the MC address in the original message is destined to the receiving = node. > Therefore I think that the encapsulating header does not need the = ALL_MPL_FORWARDERS multicast address but can be equal to the MC address = of the original message. > This means that receiving nodes need to enable their interfaces to the = MC-address stored in the header of the original message. > Given that the node needs to know this address anyway, I don't think = this complicates the use of MPL. >=20 > This also works for a message leaving the MPL domain. >=20 > Any mistakes in my reasoning? Putting this text in section 5.1, and = removing the text in section 4.1 can help the progress of MPL draft. This idea is interesting. I don't know if the WG considered it. =20 However, I'm not sure it's a simplification. There are two functions in = a MPL forwarding node: forwarding multicast traffic on to other nodes in = the MPL domain and delivering traffic to local applications. The former = function requires that the node stack receive and forward all multicast = traffic while the latter function uses the list of locally subscribed = multicast addresses for local delivery. I suppose there's no difference between a node accepting all multicast = traffic for forwarding rather than using ALL_MPL_FORWARDERS in the outer = header, and then delivering only subscribed traffic based on the inner = header. >=20 > Ad 2) > There is a clear wish to distribute a MC message to all members of a = mesh network, for example to distribute mdns messages or to learn lowpan = start-up information like address of border router. > Making that the subject of IP_over_Foo drafts seems very reasonable to = me. > The 6lo WG can provide an addendum to the 6lowpan RFC to provide an = algorithm that makes it possible that all mesh members learn the same = 0x3 scope address, and enable the address. > Although MPL forwarders need to forward the message, the destinations = are not necessarily MPL forwarders. > Identifying the MC address with the PAN-ID (given the PAN-ID does not = change in spite of coordinator failures) of the mesh seems logical for = IEEE802.15.4. If I've got it right, you support publication of a very short RFC that = gives the definition of IEEE802.15.4 scope 3 as the list of all = interfaces that share the same PAN ID. >=20 > Sending a multicast to all members to a heterogeneous multi-link = network looks like a different problem to me. Agreed. - Ralph >=20 > Hope this may help. >=20 > Peter > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From mcr+ietf@sandelman.ca Wed Oct 23 11:19: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 96A6311E83E8 for ; Wed, 23 Oct 2013 11:19:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mMQWvxDwwDWU for ; Wed, 23 Oct 2013 11:19:42 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 19BAC11E83EC for ; Wed, 23 Oct 2013 11:19:41 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 849BC20186; Wed, 23 Oct 2013 15:30:32 -0400 (EDT) From: Michael Richardson To: Ines Robles In-Reply-To: References: X-Mailer: MH-E 8.2; nmh 1.5; GNU Emacs 23.4.1 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 Cc: roll@ietf.org Subject: Re: [Roll] Last Call: draft-ietf-roll-trickle-mcast-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 18:19:42 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ines Robles wrote: > Just a reminder,=C2=A0 Thanks. > So far, there are three open tickets: > Ticket #103:=C2=A0trickle-mcast: suppress ICMP messages for > PROACTIVE_TIMER_EXPIRATIONS I don't think we got consensus on this, but maybe I'm wrong. > Ticket #132:=C2=A0 > draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - > subnet-local I really don't understand the dispute, and it's gonna take some in-person discussion. Not clear to me that it's going to be an edit to this document. > Ticket=C2=A0#134 > draft-ietf-roll-trickle-mcast-05 - Minor editorial comments Something which I hope the authors will just act on. =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) iQCVAwUBUmgTOoqHRg3pndX9AQI1BQP+OmY72uuP5zxM8EEeSe36xugQrkd+ofXM enQgTC95KT+vYS5k8SXk5OEYaJ6J5Msr5tTrkrJ+7lFq3lkQRpvRY+s+Th4juWBx uT51wpHq3o2KeAkW6ZnMFpQMS4szaus+RgNh9iwr+PBZ5YycQrbqiqJFC5Xnwjd4 t6WxGtjSy5Y= =FlDx -----END PGP SIGNATURE----- --=-=-=-- From rdroms.ietf@gmail.com Wed Oct 23 11:36:57 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDD4F11E8182 for ; Wed, 23 Oct 2013 11:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oXGFTvFb03AU for ; Wed, 23 Oct 2013 11:36:42 -0700 (PDT) Received: from mail-qe0-x233.google.com (mail-qe0-x233.google.com [IPv6:2607:f8b0:400d:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 8BCCA11E8156 for ; Wed, 23 Oct 2013 11:36:41 -0700 (PDT) Received: by mail-qe0-f51.google.com with SMTP id q19so740116qeb.24 for ; Wed, 23 Oct 2013 11:36:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=ym0WmZWNFg/PItQhPVNTF/ToyhZ/kgO41NqXTV9HfDo=; b=aFcTP8DCNMh8tN891k5fDfvTSx2T4G96gPe+cuwjLZ0DeKR771v0GpdDZ3LfcuBtY0 klMtYdn0xN+kk/8JLJk6HGLxawYgQ0EbgwQpPM/LmzzJ+4Wi3XTZNYRGxMLRUlBEaviG V0F3H1re3V7IKJbPzgS30MgjliXDwTruuMWo0nrAwwO9DV6K/YGWDZLTnhoVXFmimv0m 5cQ6kVJVdBKdLwoPJVad+ueJ2lrVbW921rYgASdnSX63B8CkuX6Jvy5OYEswMpl0m62/ NqvVLImjQei3PfvTkHeTGaINRzvmgVOsq0smxRb/nR9cx8JcHVljza3H7xDi10FsbCGi pAAQ== X-Received: by 10.49.72.164 with SMTP id e4mr4262424qev.36.1382553401125; Wed, 23 Oct 2013 11:36:41 -0700 (PDT) Received: from ?IPv6:2001:420:2c52:1316:143:7974:fe17:7855? ([2001:420:2c52:1316:143:7974:fe17:7855]) by mx.google.com with ESMTPSA id ge5sm55124774qeb.5.2013.10.23.11.36.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Oct 2013 11:36:39 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Ralph Droms In-Reply-To: <17136.1382552378@obiwan.sandelman.ca> Date: Wed, 23 Oct 2013 14:36:38 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1B46DC63-B198-45A1-B658-B958E9F312D3@gmail.com> References: <17136.1382552378@obiwan.sandelman.ca> To: Routing Over Low power and Lossy networks X-Mailer: Apple Mail (2.1510) Subject: Re: [Roll] Last Call: draft-ietf-roll-trickle-mcast-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 18:36:57 -0000 X-List-Received-Date: Wed, 23 Oct 2013 18:36:57 -0000 On Oct 23, 2013, at 2:19 PM 10/23/13, Michael Richardson = wrote: >=20 > Ines Robles wrote: >> Just a reminder,=20 >=20 > Thanks. >=20 >> So far, there are three open tickets: >=20 >> Ticket #103: trickle-mcast: suppress ICMP messages for >> PROACTIVE_TIMER_EXPIRATIONS >=20 > I don't think we got consensus on this, but maybe I'm wrong. >=20 >> Ticket #132:=20 >=20 >> draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - >> subnet-local >=20 > I really don't understand the dispute, and it's gonna take some = in-person > discussion. Without a WG meeting in Vancouver, how will this in-person discussion = take place? I'd be happy to have a one-to-one or sponsor a multi-way teleconf to = discuss the issue. In my opinion, the problem is pretty clear: draft-ietf-roll-trickle-mcast-05 and = draft-ietf-6man-multicast-scopes-00 are in conflict with each other. =46rom draft-ietf-roll-trickle-mcast-05: When used with MPL, Realm-Local scope is administratively defined and = used to define the boundaries of multicast message dissemination by MPL. =46rom draft-ietf-6man-multicast-scopes-00: Realm-Local scope is the largest scope that is automatically configured, i.e., automatically derived from physical connectivity or other, non-multicast-related configuration. Specifically, "administratively defined" seems to me to be in direct conflict with "automatically configured". Part of the solution will require either a change in either = draft-ietf-roll-trickle-mcast or draft-ietf-6man-multicast-scopes. I = think we have WG support, if not consensus, to edit = draft-ietf-roll-trickle-mcast-05: OLD: When used with MPL, Realm-Local scope is administratively defined and = used to define the boundaries of multicast message dissemination by MPL. NEW: When used with MPL, Realm-Local scope is defined according to the underlying network technology; for example, [cite the IP-over-IEEE802.15.4 definition]. One additional bit of text is needed, but not necessarily in = draft-ietf-roll-trickle-mcast, to define explicitly the meaning of scop = 3 in an IEEE802.15.4 network (which is the definition to be cited in the = NEW text above): When used in an IP-over-IEEE802.15.4 network, "scop 3" is defined to include all interfaces sharing a PAN ID. As a further refinement, I suggest text be added to = draft-ietf-roll-trickle-mcast-05 to the effect of (this refinement has = seen less WG discussion, in my opinion): "scop 4" can also be used with MPL to cover deployments that use administratively defined scopes that cover, for example, subnets based on different underlying network technologies. > Not clear to me that it's going to be an edit to this = document.draft-ietf-roll-trickle-mcast-05 I'm pretty sure *something* has to be changed in = draft-ietf-roll-trickle-mcast unless the definition of scop 3 is changed = in draft-ietf-6man-multicast-scopes. - Ralph =20 >=20 >> Ticket #134 >> draft-ietf-roll-trickle-mcast-05 - Minor editorial comments >=20 > Something which I hope the authors will just act on. >=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 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From kerlyn2001@gmail.com Wed Oct 23 12:01: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 17A6511E820F for ; Wed, 23 Oct 2013 12:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pRd+OYHG-Asv for ; Wed, 23 Oct 2013 12:01:21 -0700 (PDT) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 3A66C11E84E5 for ; Wed, 23 Oct 2013 12:01:09 -0700 (PDT) Received: by mail-wg0-f54.google.com with SMTP id c11so1261965wgh.21 for ; Wed, 23 Oct 2013 12:01:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=awQ2SbNoF7IA4cji9K6FkwRye+rEF0aVeUKqYyd2+yo=; b=BV+LxfbIcUOnqS/k75rVXsPe31km8LBdZ1n9PLEI5UiaxaIb4b6iRTunA3B5DgBn4T jnlgFYkJ2aUG6RRVZ8hnIK4bhWEt3ZeDM4ZvKwqZsI1tG3OQbgqQswbVG6tfKSs7gs1v fnkgF6cYkSs3GQX4H+WLjlm6r4HC4yWlEhwqEq8jQWCP8St2AXMX3lKm4SbsUSNT2n/x 5W9/9U7xmxiRy1x5HN5Y0wts8xEIa46Aq97HPyua7mr8EXnkigw0XLJPft8vZLvC8dpv +sgqs6l4gTKV0YM/2WIhjz0iNeqDcKtAaexnFrq42NA/yi3OX7tEmG02mXf7F39XT3fj cW5g== MIME-Version: 1.0 X-Received: by 10.180.73.40 with SMTP id i8mr3347714wiv.37.1382554868451; Wed, 23 Oct 2013 12:01:08 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.216.227.132 with HTTP; Wed, 23 Oct 2013 12:01:08 -0700 (PDT) In-Reply-To: <1B46DC63-B198-45A1-B658-B958E9F312D3@gmail.com> References: <17136.1382552378@obiwan.sandelman.ca> <1B46DC63-B198-45A1-B658-B958E9F312D3@gmail.com> Date: Wed, 23 Oct 2013 15:01:08 -0400 X-Google-Sender-Auth: AvXJewJPAi1ss2rm8LlIrkjBiWA Message-ID: From: Kerry Lynn To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary=f46d0438907dd111e804e96d231a Subject: Re: [Roll] Last Call: draft-ietf-roll-trickle-mcast-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 19:01:22 -0000 --f46d0438907dd111e804e96d231a Content-Type: text/plain; charset=ISO-8859-1 On Wed, Oct 23, 2013 at 2:36 PM, Ralph Droms wrote: > > On Oct 23, 2013, at 2:19 PM 10/23/13, Michael Richardson < > mcr+ietf@sandelman.ca> wrote: > > > > > Ines Robles wrote: > >> Just a reminder, > > > > Thanks. > > > >> So far, there are three open tickets: > > > >> Ticket #103: trickle-mcast: suppress ICMP messages for > >> PROACTIVE_TIMER_EXPIRATIONS > > > > I don't think we got consensus on this, but maybe I'm wrong. > > > >> Ticket #132: > > > >> draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - > >> subnet-local > > > > I really don't understand the dispute, and it's gonna take some in-person > > discussion. > > Without a WG meeting in Vancouver, how will this in-person discussion take > place? > > Right. Which bar are we meeting at and when? > I'd be happy to have a one-to-one or sponsor a multi-way teleconf to > discuss the issue. > > In my opinion, the problem is pretty clear: > > draft-ietf-roll-trickle-mcast-05 and draft-ietf-6man-multicast-scopes-00 > are in conflict with each other. > > From draft-ietf-roll-trickle-mcast-05: > > When > used with MPL, Realm-Local scope is administratively defined and used > to define the boundaries of multicast message dissemination by MPL. > > From draft-ietf-6man-multicast-scopes-00: > > Realm-Local scope is the largest scope that is automatically > configured, i.e., automatically derived from physical > connectivity or other, non-multicast-related configuration. > > Note the above requirement (albeit with slightly different wording) comes from RFC 4291. Specifically, "administratively defined" seems to me to be in direct > conflict with "automatically configured". > > +1 > Part of the solution will require either a change in either > draft-ietf-roll-trickle-mcast or draft-ietf-6man-multicast-scopes. I think > we have WG support, if not consensus, to edit > draft-ietf-roll-trickle-mcast-05: > > OLD: > > When > used with MPL, Realm-Local scope is administratively defined and used > to define the boundaries of multicast message dissemination by MPL. > > NEW: > > When > used with MPL, Realm-Local scope is defined according to > the underlying network technology; for example, [cite the > IP-over-IEEE802.15.4 definition]. > > One additional bit of text is needed, but not necessarily in > draft-ietf-roll-trickle-mcast, to define explicitly the meaning of scop 3 > in an IEEE802.15.4 network (which is the definition to be cited in the NEW > text above): > > When used in an IP-over-IEEE802.15.4 network, "scop 3" is defined > to include all interfaces sharing a PAN ID. > > I agree with draft-ietf-6man-multicast-scopes that the proper place for this definition is in an IP-over-foo RFC. Specifically, any new 6lo drafts that desire to use an automatically configured scop 3 must define the link-layer technology specific attribute used to identify the scope zone. So I think the proper way to set the precedent is to issue a short RFC in 6lo (given that 6LoWPAN is shutting down) to update RFC 4944. Otherwise, future protocols that wish to make use of scop 3 will have to reference Ralph's RFC plus the MPL RFC. As a further refinement, I suggest text be added to > draft-ietf-roll-trickle-mcast-05 to the effect of (this refinement has seen > less WG discussion, in my opinion): > > "scop 4" can also be used with MPL to cover deployments > that use administratively defined scopes that cover, for > example, subnets based on different underlying network > technologies. > > The place for this would be section 4.1, which currently says: An MPL Forwarder MAY participate in additional MPL Domains identified by other multicast addresses. An MPL Interface MUST subscribe to the MPL Domain Addresses for the MPL Domains that it participates in. The assignment of other multicast addresses is out of scope. > > Not clear to me that it's going to be an edit to this > document.draft-ietf-roll-trickle-mcast-05 > > I'm pretty sure *something* has to be changed in > draft-ietf-roll-trickle-mcast unless the definition of scop 3 is changed in > draft-ietf-6man-multicast-scopes. > > And, by extension, in RFC 4291. -K- > - Ralph > > > > >> Ticket #134 > >> draft-ietf-roll-trickle-mcast-05 - Minor editorial comments > > > > Something which I hope the authors will just act on. > > > > -- > > ] 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 > --f46d0438907dd111e804e96d231a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Oct 23, 2013 at 2:36 PM, Ralph Droms <rdroms.= ietf@gmail.com> wrote:

On Oct 23, 2013, at 2:19 PM 10/23/13, Michael Richardson <mcr+ietf@sandelman.ca> wrote:

>
> Ines =A0Robles <m= ariainesrobles@googlemail.com> wrote:
>> Just a reminder,
>
> Thanks.
>
>> So far, there are three open tickets:
>
>> Ticket #103: trickle-mcast: suppress ICMP messages for
>> PROACTIVE_TIMER_EXPIRATIONS
>
> I don't think we got consensus on this, but maybe I'm wrong. >
>> Ticket #132:
>
>> draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 -
>> subnet-local
>
> I really don't understand the dispute, and it's gonna take som= e in-person
> discussion.

Without a WG meeting in Vancouver, how will this in-person discussion= take place?

Right.=A0 Which bar are we meeting at and when?
= =A0
I'd be happy to have a one-to-one or sponsor a multi-way teleconf to di= scuss the issue.

In my opinion, the problem is pretty clear:

=A0draft-ietf-roll-trickle-mcast-05 and draft-ietf-6man-multicast-scopes-00=
=A0are in conflict with each other.

=A0From draft-ietf-roll-trickle-mcast-05:

=A0 =A0 When
=A0 =A0 used with MPL, Realm-Local scope is administratively defined and us= ed
=A0 =A0 to define the boundaries of multicast message dissemination by MPL.=

=A0From draft-ietf-6man-multicast-scopes-00:

=A0 =A0 Realm-Local scope is the largest scope that is automatically
=A0 =A0 configured, i.e., automatically derived from physical
=A0 =A0 connectivity or other, non-multicast-related configuration.

Note the above requirement (albeit with slightly diff= erent wording) comes from RFC 4291.

=A0Specifically, "administratively defined" seems to me to be in = direct
=A0conflict with "automatically configured".

+1
=A0
Part of the solution will require either a change in either draft-ietf-roll= -trickle-mcast or draft-ietf-6man-multicast-scopes. =A0I think we have WG s= upport, if not consensus, to edit draft-ietf-roll-trickle-mcast-05:

OLD:

=A0 =A0 When
=A0 =A0 used with MPL, Realm-Local scope is administratively defined and us= ed
=A0 =A0 to define the boundaries of multicast message dissemination by MPL.=

NEW:

=A0 =A0 When
=A0 =A0 used with MPL, Realm-Local scope is defined according to
=A0 =A0 the underlying network technology; for example, [cite the
=A0 =A0 IP-over-IEEE802.15.4 definition].

One additional bit of text is needed, but not necessarily in draft-ietf-rol= l-trickle-mcast, to define explicitly the meaning of scop 3 in an IEEE802.1= 5.4 network (which is the definition to be cited in the NEW text above):
=A0 =A0 When used in an IP-over-IEEE802.15.4 network, "scop 3" is= defined
=A0 =A0 to include all interfaces sharing a PAN ID.

I agree with draft-ietf-6man-multicast-scopes that th= e proper place for this definition is in
an IP-over-foo RFC.=A0 Specific= ally, any new 6lo drafts that desire to use an automatically
configured scop 3 must define the link-layer technology specific attribute = used to identify
the scope zone.=A0 So I think the proper way= to set the precedent is to issue a short RFC
in 6lo (given that 6LoWPAN= is shutting down) to update RFC 4944.=A0 Otherwise, future
protocols that wish to make use of scop 3 will have to reference= Ralph's RFC plus the
MPL RFC.

<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex"> As a further refinement, I suggest text be added to draft-ietf-roll-trickle= -mcast-05 to the effect of (this refinement has seen less WG discussion, in= my opinion):

=A0 =A0 "scop 4" can also be used with MPL to cover deployments =A0 =A0 that use administratively defined scopes that cover, for
=A0 =A0 example, subnets based on different underlying network
=A0 =A0 technologies.

The place for this would be section 4.1, which curren= tly says:
   An MPL Forwarder MAY participate in additio=
nal MPL Domains identified
   by other multicast addresses.  An MPL Interface MUST subscribe to the
   MPL Domain Addresses for the MPL Domains that it participates in.
   The assignment of other multicast addresses is out of scope.
=A0
> =A0Not clear to me that it's going to be an edit to this document.= draft-ietf-roll-trickle-mcast-05

I'm pretty sure *something* has to be changed in draft-ietf-roll-trickl= e-mcast unless the definition of scop 3 is changed in draft-ietf-6man-multi= cast-scopes.

And, by extension, in RFC 4291.

-K-=
=A0
- Ralph

>
>> Ticket #134
>> draft-ietf-roll-trickle-mcast-05 - Minor editorial comments
>
> Something which I hope the authors will just act on.
>
> --
> ] =A0 =A0 =A0 =A0 =A0 =A0 =A0 Never tell me the odds! =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 | ipv6 mesh networks [
> ] =A0 Michael Richardson, Sandelman Software Works =A0 =A0 =A0 =A0| ne= twork architect =A0[
> ] =A0 =A0 mcr@sandelman.ca =A0= http://www.sandelman= .ca/ =A0 =A0 =A0 =A0| =A0 ruby on rails =A0 =A0[
>
> _______________________________________________
> 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


--f46d0438907dd111e804e96d231a-- From rdroms.ietf@gmail.com Wed Oct 23 12:56:51 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 499C611E820C; Wed, 23 Oct 2013 12:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.45 X-Spam-Level: X-Spam-Status: No, score=-102.45 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pidO2NNw1obz; Wed, 23 Oct 2013 12:56:50 -0700 (PDT) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 901D711E81DF; Wed, 23 Oct 2013 12:56:50 -0700 (PDT) Received: by mail-qc0-f182.google.com with SMTP id n7so793129qcx.13 for ; Wed, 23 Oct 2013 12:56:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=UmW/mIxx9X6QYWSAXE22eUDeKdx7DexynDZnExTzkqI=; b=NCc8dMC6PYKGoJBTO8/G32t4FV4W01v59iXwVGwJtIktdNTC4IgtG2hU6jtMUzie3q CGbsx/3BOnyx/yfbGTqTff/7lxP68ZQy0NQD0C0VDcvbO4UEdaD22qjLxYOjjZ2XwCbm LPbLxtwMuD8kToCmG+Y/mfXOPdBeJg5eup9z/ZqjjU2yl9ZEsjOd32fpJRugQOf9Oj+a zfRy7zgXZ/MgoSD3dW6shszMAuxf+Pm6PKjmc84KdrabTWWBRzYDb+JEtJA/R041B9hI v507avft212l+SAG3l8FQsld3l4edCw0OnZJ6hbG0QCRLUZQivu+g1/gw6ZDKp0ZAuDJ E1RQ== X-Received: by 10.224.54.66 with SMTP id p2mr6292079qag.87.1382558209989; Wed, 23 Oct 2013 12:56:49 -0700 (PDT) Received: from ?IPv6:2001:420:2c52:1316:143:7974:fe17:7855? ([2001:420:2c52:1316:143:7974:fe17:7855]) by mx.google.com with ESMTPSA id x1sm64785236qai.6.2013.10.23.12.56.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Oct 2013 12:56:48 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Ralph Droms In-Reply-To: Date: Wed, 23 Oct 2013 15:56:46 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <52FECA00-C316-4693-A821-7EA6510AC0F8@gmail.com> References: <3599.1381852752@sandelman.ca> <525DC6C9.2010808@gridmerge.com> <525E5064.4050109@gridmerge.com> <3CC8783F-F4DA-47B9-A051-DBBA6EF00C19@gmail.com> To: =?utf-8?B?56We5piO6YGU5ZOJ?= X-Mailer: Apple Mail (2.1510) Cc: Routing Over Low power and Lossy networks , 6man@ietf.org Subject: Re: [Roll] draft-ietf-6man-multicast-scopes updates RFC 4007 (Was Re: [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 19:56:51 -0000 On Oct 21, 2013, at 3:00 PM 10/21/13, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89= wrote: > At Thu, 17 Oct 2013 09:10:50 -0700, > Ralph Droms wrote: >=20 >> Noting this conflict, I propose adding a bit of text to >> draft-ietf-6man-multicast-scopes to update RFC 4007 for consistency >> with RFC 4291: >=20 > I think making these consistent is a good idea. >=20 >> OLD: >>=20 >> o The boundaries of zones of a scope other than interface-local, >> link-local, and global must be defined and configured by network >> administrators. >>=20 >> NEW: >>=20 >> o Admin-Local scope is the smallest scope that must be >> administratively configured, i.e., not automatically derived >> from physical connectivity or other, non-multicast-related >> configuration. >=20 > I'm okay with the proposed text, but on a closer look I've noticed > a couple of subtle points you may want to consider: >=20 > - I see a slight difference between the OLD (RFC 4007) and NEW (RFC > 4291) even after fixing the obvious inconsistency, in that the NEW > version does not necessarily say how the scopes larger than > admin-local scope is configured; technically it only states > interface-local and link-local (and "Realm-Local" if assigned) > would not be automatically configured. In fact, the global scope > shouldn't be "administratively" configured, which is crystal clear > from the OLD version, but not necessarily in the NEW version. >=20 > - should we worry about possible future updates to the addressing > architecture and scope architecture documents? If we keep these > documents separately and have a copy of the text in both, we may need > to update both copies when we need to make a change on this point as > more "currently reserved" scopes are assigned. Both good points. As long as we have to make an update to RFC 4007, = let's make sure the update is correct. >=20 > These are probably too minor and maybe we can simply ignore the > subtlety. If that's our consensus I'm okay with that. But if we want > to address these points, maybe: >=20 > OLD: >=20 > o The boundaries of zones of a scope other than interface-local, > link-local, and global must be defined and configured by network > administrators. >=20 > NEW: >=20 > o The boundaries of zones of an interface-local, link-local, or > global scope automatically derived from physical connectivity. > For zones of other types of scopes, the IPv6 addressing > architecture specification defines how their boundaries must be > determined, whether automatically derived or administratively > configured. Perhaps we want to go a step farther and take the zone boundary text out = of RFC 4007 altogether? OLD: o The boundaries of zones of a scope other than interface-local, link-local, and global must be defined and configured by network administrators NEW: o The boundaries of zones of a scope are defined by the IPv6 addressing architecture. - Ralph >=20 > -- > JINMEI, Tatuya From kerlyn2001@gmail.com Wed Oct 23 14:38: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 C870C11E825B; Wed, 23 Oct 2013 14:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.101 X-Spam-Level: X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[AWL=-0.876, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7qAPlLeCY4O; Wed, 23 Oct 2013 14:38:15 -0700 (PDT) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 3F10C11E8181; Wed, 23 Oct 2013 14:38:10 -0700 (PDT) Received: by mail-ob0-f180.google.com with SMTP id wo20so1484406obc.11 for ; Wed, 23 Oct 2013 14:38:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=WFKYjAmQ4nr9G1lcaLcyAVnAUYOqkzPKrb+YD0sFrtE=; b=wGBBtan1X6n2EkjZ5j+5oOJkcDUeIbHKsj4egRY2Sok5dfhjyGPbkevrhCv+uthdyJ WoEslCwLQXBcX7BMWsaHfPaaMnnNK6vB2rsx172TMQXAA3xmYeF8ApJzwkbcYwZV92qY /s594eh+wsBOdJgTPq2QDWzavmSeBWGEjxc5TY6LB2mYNy4pt37X8koaP/vobekRw8f9 k3dPgOQgpC2qh1fLBikJufvlTwy7B6prc02CrEnFzKVIDY6bPeTFTZzsUgVWvah5GRHo DVSb2rz0DGsR/6Mmwl07Dlx2Tw/LbiAwaqz+etXUlEsT/44xapSsB31Ys9sZo2pvOX1m Mc5g== MIME-Version: 1.0 X-Received: by 10.182.246.74 with SMTP id xu10mr3755288obc.23.1382564287673; Wed, 23 Oct 2013 14:38:07 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.60.73.6 with HTTP; Wed, 23 Oct 2013 14:38:07 -0700 (PDT) In-Reply-To: References: <3599.1381852752@sandelman.ca> <525DC6C9.2010808@gridmerge.com> <525E5064.4050109@gridmerge.com> <3CC8783F-F4DA-47B9-A051-DBBA6EF00C19@gmail.com> <52FECA00-C316-4693-A821-7EA6510AC0F8@gmail.com> Date: Wed, 23 Oct 2013 17:38:07 -0400 X-Google-Sender-Auth: 49IQKZyZDA0hkIuuNaDVCXN-aH8 Message-ID: From: Kerry Lynn To: =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Content-Type: multipart/alternative; boundary=001a11c2e6083efebb04e96f5567 Cc: Routing Over Low power and Lossy networks , "6man@ietf.org" <6man@ietf.org> Subject: Re: [Roll] draft-ietf-6man-multicast-scopes updates RFC 4007 (Was Re: [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 21:38:20 -0000 --001a11c2e6083efebb04e96f5567 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit On Wed, Oct 23, 2013 at 5:21 PM, $B?@L@C#:H(B wrote: > At Wed, 23 Oct 2013 15:56:46 -0400, > Ralph Droms wrote: > > > Perhaps we want to go a step farther and take the zone boundary text > > out of RFC 4007 altogether? > > Basically works for me. > > > OLD: > > > > o The boundaries of zones of a scope other than interface-local, > > link-local, and global must be defined and configured by network > > administrators > > > > NEW: > > > > o The boundaries of zones of a scope are defined by the IPv6 > > addressing architecture. > > With a reference (it's currently RFC 4291)? > > I'd also note that not all points described in the RFC 4007 text are > described in RFC 4291 (at least not very clearly). So, not just > remove the text from RFC 4007, I'd like to unify it in the address > architecture, e.g. update the following part of RFC 4291: > > Admin-Local scope is the smallest scope that must be > administratively configured, i.e., not automatically derived > from physical connectivity or other, non-multicast-related > configuration. > > as follows: > > Admin-Local scope is the smallest scope that must be > administratively configured, i.e., not automatically derived > from physical connectivity or other, non-multicast-related > configuration. For all non-reserved scopes except the global > scope, the zone boundaries must also be administratively > configured. > > I think this statement is self-contradictory. When automatic configuration is discussed, it is in relation to zone boundaries. Here's an attempt to explain this without negations: Interface-Local, Link-Local, and Realm-Local scope boundaries are automatically derived from physical connectivity or other, non-multicast related configuration. Global scope has no boundary. The boundaries of all other non-reserved scopes are administratively configured. BTW, just my opinion, but "Realm-Local" might be more meaningfully named "Multilink-Local" -K- -- > JINMEI, Tatuya > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --001a11c2e6083efebb04e96f5567 Content-Type: text/html; charset=ISO-2022-JP Content-Transfer-Encoding: base64 PGRpdiBkaXI9Imx0ciI+T24gV2VkLCBPY3QgMjMsIDIwMTMgYXQgNToyMSBQTSwgGyRCP0BMQEMj OkgbKEIgPHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJtYWlsdG86amlubWVpQHdpZGUuYWQu anAiIHRhcmdldD0iX2JsYW5rIj5qaW5tZWlAd2lkZS5hZC5qcDwvYT4mZ3Q7PC9zcGFuPiB3cm90 ZTo8YnI+PGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj48 YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHgg MC44ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNvbGlkIHJnYigyMDQsMjA0LDIwNCk7cGFkZGluZy1sZWZ0 OjFleCI+DQpBdCBXZWQsIDIzIE9jdCAyMDEzIDE1OjU2OjQ2IC0wNDAwLDxicj4NCjxkaXYgY2xh c3M9ImltIj5SYWxwaCBEcm9tcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJkcm9tcy5pZXRmQGdtYWls LmNvbSI+cmRyb21zLmlldGZAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KPGJyPg0KJmd0 OyBQZXJoYXBzIHdlIHdhbnQgdG8gZ28gYSBzdGVwIGZhcnRoZXIgYW5kIHRha2UgdGhlIHpvbmUg Ym91bmRhcnkgdGV4dDxicj4NCiZndDsgb3V0IG9mIFJGQyA0MDA3IGFsdG9nZXRoZXI/PGJyPg0K PGJyPg0KPC9kaXY+QmFzaWNhbGx5IHdvcmtzIGZvciBtZS48YnI+DQo8ZGl2IGNsYXNzPSJpbSI+ PGJyPg0KJmd0OyBPTEQ6PGJyPg0KJmd0Ozxicj4NCiZndDsgJm5ic3A7IG8gJm5ic3A7VGhlIGJv dW5kYXJpZXMgb2Ygem9uZXMgb2YgYSBzY29wZSBvdGhlciB0aGFuIGludGVyZmFjZS1sb2NhbCw8 YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7bGluay1sb2NhbCwgYW5kIGdsb2JhbCBtdXN0 IGJlIGRlZmluZWQgYW5kIGNvbmZpZ3VyZWQgYnkgbmV0d29yazxicj4NCiZndDsgJm5ic3A7ICZu YnNwOyAmbmJzcDthZG1pbmlzdHJhdG9yczxicj4NCiZndDs8YnI+DQomZ3Q7IE5FVzo8YnI+DQom Z3Q7PGJyPg0KJmd0OyAmbmJzcDsgbyAmbmJzcDtUaGUgYm91bmRhcmllcyBvZiB6b25lcyBvZiBh IHNjb3BlIGFyZSBkZWZpbmVkIGJ5IHRoZSBJUHY2PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZu YnNwO2FkZHJlc3NpbmcgYXJjaGl0ZWN0dXJlLjxicj4NCjxicj4NCjwvZGl2PldpdGggYSByZWZl cmVuY2UgKGl0JiMzOTtzIGN1cnJlbnRseSBSRkMgNDI5MSk/PGJyPg0KPGJyPg0KSSYjMzk7ZCBh bHNvIG5vdGUgdGhhdCBub3QgYWxsIHBvaW50cyBkZXNjcmliZWQgaW4gdGhlIFJGQyA0MDA3IHRl eHQgYXJlPGJyPg0KZGVzY3JpYmVkIGluIFJGQyA0MjkxIChhdCBsZWFzdCBub3QgdmVyeSBjbGVh cmx5KS4gJm5ic3A7U28sIG5vdCBqdXN0PGJyPg0KcmVtb3ZlIHRoZSB0ZXh0IGZyb20gUkZDIDQw MDcsIEkmIzM5O2QgbGlrZSB0byB1bmlmeSBpdCBpbiB0aGUgYWRkcmVzczxicj4NCmFyY2hpdGVj dHVyZSwgZS5nLiB1cGRhdGUgdGhlIGZvbGxvd2luZyBwYXJ0IG9mIFJGQyA0MjkxOjxicj4NCjxk aXYgY2xhc3M9ImltIj48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7QWRt aW4tTG9jYWwgc2NvcGUgaXMgdGhlIHNtYWxsZXN0IHNjb3BlIHRoYXQgbXVzdCBiZTxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDthZG1pbmlzdHJhdGl2ZWx5IGNvbmZpZ3Vy ZWQsIGkuZS4sIG5vdCBhdXRvbWF0aWNhbGx5IGRlcml2ZWQ8YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ZnJvbSBwaHlzaWNhbCBjb25uZWN0aXZpdHkgb3Igb3RoZXIsIG5v bi1tdWx0aWNhc3QtcmVsYXRlZDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDtjb25maWd1cmF0aW9uLjxicj4NCjxicj4NCjwvZGl2PmFzIGZvbGxvd3M6PGJyPg0KPGRpdiBj bGFzcz0iaW0iPjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtBZG1pbi1M b2NhbCBzY29wZSBpcyB0aGUgc21hbGxlc3Qgc2NvcGUgdGhhdCBtdXN0IGJlPGJyPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2FkbWluaXN0cmF0aXZlbHkgY29uZmlndXJlZCwg aS5lLiwgbm90IGF1dG9tYXRpY2FsbHkgZGVyaXZlZDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDtmcm9tIHBoeXNpY2FsIGNvbm5lY3Rpdml0eSBvciBvdGhlciwgbm9uLW11 bHRpY2FzdC1yZWxhdGVkPGJyPg0KPC9kaXY+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO2NvbmZpZ3VyYXRpb24uICZuYnNwO0ZvciBhbGwgbm9uLXJlc2VydmVkIHNjb3BlcyBleGNl cHQgdGhlIGdsb2JhbDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtzY29w ZSwgdGhlIHpvbmUgYm91bmRhcmllcyBtdXN0IGFsc28gYmUgYWRtaW5pc3RyYXRpdmVseTxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtjb25maWd1cmVkLjxicj4NCjxkaXYg Y2xhc3M9IiI+PGRpdiBjbGFzcz0iaDUiPjxicj48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PGRp dj5JIHRoaW5rIHRoaXMgc3RhdGVtZW50IGlzIHNlbGYtY29udHJhZGljdG9yeS4mbmJzcDsgV2hl biBhdXRvbWF0aWMgY29uZmlndXJhdGlvbiBpczxicj5kaXNjdXNzZWQsIGl0IGlzIGluIHJlbGF0 aW9uIHRvIHpvbmUgYm91bmRhcmllcy4mbmJzcDsgSGVyZSYjMzk7cyBhbiBhdHRlbXB0IHRvIGV4 cGxhaW48YnI+DQo8L2Rpdj48ZGl2PnRoaXMgd2l0aG91dCBuZWdhdGlvbnM6PGJyPjxicj48L2Rp dj48ZGl2PiZuYnNwOyAmbmJzcDsgSW50ZXJmYWNlLUxvY2FsLCBMaW5rLUxvY2FsLCBhbmQgUmVh bG0tTG9jYWwgc2NvcGUgYm91bmRhcmllcyBhcmUgYXV0b21hdGljYWxseTxicj48L2Rpdj48ZGl2 PiZuYnNwOyZuYnNwOyZuYnNwOyBkZXJpdmVkIGZyb20gcGh5c2ljYWwgY29ubmVjdGl2aXR5IG9y IG90aGVyLCBub24tbXVsdGljYXN0IHJlbGF0ZWQgY29uZmlndXJhdGlvbi48YnI+DQo8L2Rpdj48 ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyBHbG9iYWwgc2NvcGUgaGFzIG5vIGJvdW5kYXJ5LiZuYnNw OyBUaGUgYm91bmRhcmllcyBvZiBhbGwgb3RoZXIgbm9uLXJlc2VydmVkIHNjb3Blczxicj48L2Rp dj48ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyBhcmUgYWRtaW5pc3RyYXRpdmVseSBjb25maWd1cmVk Ljxicj48YnI+PC9kaXY+PGRpdj5CVFcsIGp1c3QgbXkgb3BpbmlvbiwgYnV0ICZxdW90O1JlYWxt LUxvY2FsJnF1b3Q7IG1pZ2h0IGJlIG1vcmUgbWVhbmluZ2Z1bGx5IG5hbWVkPGJyPg0KPC9kaXY+ PGRpdj4mcXVvdDtNdWx0aWxpbmstTG9jYWwmcXVvdDs8YnI+PGJyPjwvZGl2PjxkaXY+LUstPGJy Pjxicj48L2Rpdj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46 MHB4IDBweCAwcHggMC44ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNvbGlkIHJnYigyMDQsMjA0LDIwNCk7 cGFkZGluZy1sZWZ0OjFleCI+PGRpdiBjbGFzcz0iIj48ZGl2IGNsYXNzPSJoNSI+DQoNCi0tPGJy Pg0KSklOTUVJLCBUYXR1eWE8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCklFVEYgSVB2NiB3b3JraW5n IGdyb3VwIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzppcHY2QGlldGYub3JnIj5p cHY2QGlldGYub3JnPC9hPjxicj4NCkFkbWluaXN0cmF0aXZlIFJlcXVlc3RzOiA8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYiIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjY8L2E+PGJyPg0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS08YnI+DQo8L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PC9kaXY+PGJyPjwvZGl2Pjwv ZGl2Pg0K --001a11c2e6083efebb04e96f5567-- From robert.cragie@gmail.com Wed Oct 23 23:59: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 F140F11E8159; Wed, 23 Oct 2013 23:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.101 X-Spam-Level: X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[AWL=-0.876, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 808w3twucFbK; Wed, 23 Oct 2013 23:59:10 -0700 (PDT) Received: from mail-ea0-x229.google.com (mail-ea0-x229.google.com [IPv6:2a00:1450:4013:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 6D62711E82F3; Wed, 23 Oct 2013 23:59:07 -0700 (PDT) Received: by mail-ea0-f169.google.com with SMTP id k11so966836eaj.0 for ; Wed, 23 Oct 2013 23:59:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=R3Dhr67wafdDkYy9fVc6IjrkYoYaoOomnNzDFhjXspI=; b=EadZmlt2x5Tc6cv2+i+Epro3UYDTI+UBjgVZ16NTd85K4vTTY/c+7jekVe7le/VpoX cm3RH7jcKojo5WjNgM5vhBX5C5+xuqXDEpbOQvPLBrzHNQF2fLKLTNNsumiKYLlPCKg/ hs6AnRqE/w6UgmOJ2ARRPgcVRcLATH5lnVWIopXX6LnWgKk9IpIQgbDr3TAuPzst7o0h XijtrWFSb4VY/fDc9TrlO5i50XTnMTUobgoVOHbIKJ3FPJF285rjs7L8Q1qIu3FjO/xw iFScm6+Twuk9cNONvG/I8cFhFLDI6nnMIqQHKLEFcuEEYeUpBl0Lz+jhtN+STGl4Tt7g xFvQ== MIME-Version: 1.0 X-Received: by 10.14.183.2 with SMTP id p2mr1307714eem.44.1382597945813; Wed, 23 Oct 2013 23:59:05 -0700 (PDT) Sender: robert.cragie@gmail.com Received: by 10.15.44.1 with HTTP; Wed, 23 Oct 2013 23:59:05 -0700 (PDT) In-Reply-To: References: <3599.1381852752@sandelman.ca> <525DC6C9.2010808@gridmerge.com> <525E5064.4050109@gridmerge.com> <3CC8783F-F4DA-47B9-A051-DBBA6EF00C19@gmail.com> <52FECA00-C316-4693-A821-7EA6510AC0F8@gmail.com> Date: Thu, 24 Oct 2013 07:59:05 +0100 X-Google-Sender-Auth: EGg-qmv2qUs_f5sC0EbR9R6Dr3c Message-ID: From: Robert Cragie To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary=047d7b343dc46d717704e9772b07 Cc: "6man@ietf.org" <6man@ietf.org>, =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Subject: Re: [Roll] draft-ietf-6man-multicast-scopes updates RFC 4007 (Was Re: [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert.cragie@gridmerge.com, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 06:59:21 -0000 --047d7b343dc46d717704e9772b07 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit On 23 October 2013 22:38, Kerry Lynn wrote: > On Wed, Oct 23, 2013 at 5:21 PM, $B?@L@C#:H(B wrote: > >> At Wed, 23 Oct 2013 15:56:46 -0400, >> >> Ralph Droms wrote: >> >> > Perhaps we want to go a step farther and take the zone boundary text >> > out of RFC 4007 altogether? >> >> Basically works for me. > > Me too > >> >> > OLD: >> > >> > o The boundaries of zones of a scope other than interface-local, >> > link-local, and global must be defined and configured by network >> > administrators >> > >> > NEW: >> > >> > o The boundaries of zones of a scope are defined by the IPv6 >> > addressing architecture. >> >> With a reference (it's currently RFC 4291)? >> >> I'd also note that not all points described in the RFC 4007 text are >> described in RFC 4291 (at least not very clearly). So, not just >> remove the text from RFC 4007, I'd like to unify it in the address >> architecture, e.g. update the following part of RFC 4291: >> >> >> Admin-Local scope is the smallest scope that must be >> administratively configured, i.e., not automatically derived >> from physical connectivity or other, non-multicast-related >> configuration. >> >> as follows: >> >> >> Admin-Local scope is the smallest scope that must be >> administratively configured, i.e., not automatically derived >> from physical connectivity or other, non-multicast-related >> configuration. For all non-reserved scopes except the global >> scope, the zone boundaries must also be administratively >> configured. >> >> I think this statement is self-contradictory. When automatic > configuration is > discussed, it is in relation to zone boundaries. Here's an attempt to > explain > this without negations: > > Interface-Local, Link-Local, and Realm-Local scope boundaries are > automatically > derived from physical connectivity or other, non-multicast related > configuration. > Global scope has no boundary. The boundaries of all other > non-reserved scopes > are administratively configured. > That makes it clear. IMO RFC4007 should be changed to something like: o Each interface on a node comprises a single zone of interface-local scope (for multicast only). o Each link and the interfaces attached to that link comprise a single zone of link-local scope (for both unicast and multicast). o Multiple links and the interfaces attached to those links may form a multilink-local scope based on underlying network technology; for example, [cite the IP-over-IEEE802.15.4 definition]. o There is a single zone of global scope (for both unicast and multicast) comprising all the links and interfaces in the Internet. o The boundaries of zones of a scope other than interface-local, link-local, multilink-local and global must be defined and configured by network administrators. Either that or just remove the text as Ralph suggested earlier. > > BTW, just my opinion, but "Realm-Local" might be more meaningfully named > "Multilink-Local" > I agree - it is more meaningful > > > -K- > > -- >> JINMEI, Tatuya >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > --047d7b343dc46d717704e9772b07 Content-Type: text/html; charset=ISO-2022-JP Content-Transfer-Encoding: base64 PGRpdiBkaXI9Imx0ciI+PGJyPjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnI+PGJyPjxkaXYg Y2xhc3M9ImdtYWlsX3F1b3RlIj5PbiAyMyBPY3RvYmVyIDIwMTMgMjI6MzgsIEtlcnJ5IEx5bm4g PHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJtYWlsdG86a2VybHluQGllZWUub3JnIiB0YXJn ZXQ9Il9ibGFuayI+a2VybHluQGllZWUub3JnPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxicj4NCg0K PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4 IDAuOGV4O2JvcmRlci1sZWZ0LXdpZHRoOjFweDtib3JkZXItbGVmdC1jb2xvcjpyZ2IoMjA0LDIw NCwyMDQpO2JvcmRlci1sZWZ0LXN0eWxlOnNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPjxkaXYgZGly PSJsdHIiPk9uIFdlZCwgT2N0IDIzLCAyMDEzIGF0IDU6MjEgUE0sIBskQj9ATEBDIzpIGyhCIDxz cGFuIGRpcj0ibHRyIj4mbHQ7PGEgaHJlZj0ibWFpbHRvOmppbm1laUB3aWRlLmFkLmpwIiB0YXJn ZXQ9Il9ibGFuayI+amlubWVpQHdpZGUuYWQuanA8L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJyPg0K DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPjxibG9j a3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhl eDtib3JkZXItbGVmdC13aWR0aDoxcHg7Ym9yZGVyLWxlZnQtc3R5bGU6c29saWQ7Ym9yZGVyLWxl ZnQtY29sb3I6cmdiKDIwNCwyMDQsMjA0KTtwYWRkaW5nLWxlZnQ6MWV4Ij4NCkF0IFdlZCwgMjMg T2N0IDIwMTMgMTU6NTY6NDYgLTA0MDAsPGRpdj48YnI+DQo8ZGl2PlJhbHBoIERyb21zICZsdDs8 YSBocmVmPSJtYWlsdG86cmRyb21zLmlldGZAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+cmRy b21zLmlldGZAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KPGJyPg0KJmd0OyBQZXJoYXBz IHdlIHdhbnQgdG8gZ28gYSBzdGVwIGZhcnRoZXIgYW5kIHRha2UgdGhlIHpvbmUgYm91bmRhcnkg dGV4dDxicj4NCiZndDsgb3V0IG9mIFJGQyA0MDA3IGFsdG9nZXRoZXI/PGJyPg0KPGJyPg0KPC9k aXY+PC9kaXY+QmFzaWNhbGx5IHdvcmtzIGZvciBtZS48L2Jsb2NrcXVvdGU+PC9kaXY+PC9kaXY+ PC9kaXY+PC9ibG9ja3F1b3RlPjxkaXY+Jmx0O1JDQyZndDtNZSB0b28mbHQ7L1JDQyZndDsmbmJz cDs8L2Rpdj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4 IDBweCAwcHggMC44ZXg7Ym9yZGVyLWxlZnQtd2lkdGg6MXB4O2JvcmRlci1sZWZ0LWNvbG9yOnJn YigyMDQsMjA0LDIwNCk7Ym9yZGVyLWxlZnQtc3R5bGU6c29saWQ7cGFkZGluZy1sZWZ0OjFleCI+ DQoNCjxkaXYgZGlyPSJsdHIiPjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48ZGl2IGNsYXNzPSJn bWFpbF9xdW90ZSI+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2lu OjBweCAwcHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0LXdpZHRoOjFweDtib3JkZXItbGVmdC1zdHls ZTpzb2xpZDtib3JkZXItbGVmdC1jb2xvcjpyZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmctbGVmdDox ZXgiPg0KPGRpdj48YnI+DQo8ZGl2Pjxicj4NCiZndDsgT0xEOjxicj4NCiZndDs8YnI+DQomZ3Q7 ICZuYnNwOyBvICZuYnNwO1RoZSBib3VuZGFyaWVzIG9mIHpvbmVzIG9mIGEgc2NvcGUgb3RoZXIg dGhhbiBpbnRlcmZhY2UtbG9jYWwsPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwO2xpbmst bG9jYWwsIGFuZCBnbG9iYWwgbXVzdCBiZSBkZWZpbmVkIGFuZCBjb25maWd1cmVkIGJ5IG5ldHdv cms8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YWRtaW5pc3RyYXRvcnM8YnI+DQomZ3Q7 PGJyPg0KJmd0OyBORVc6PGJyPg0KJmd0Ozxicj4NCiZndDsgJm5ic3A7IG8gJm5ic3A7VGhlIGJv dW5kYXJpZXMgb2Ygem9uZXMgb2YgYSBzY29wZSBhcmUgZGVmaW5lZCBieSB0aGUgSVB2Njxicj4N CiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDthZGRyZXNzaW5nIGFyY2hpdGVjdHVyZS48YnI+DQo8 YnI+DQo8L2Rpdj48L2Rpdj5XaXRoIGEgcmVmZXJlbmNlIChpdCYjMzk7cyBjdXJyZW50bHkgUkZD IDQyOTEpPzxicj4NCjxicj4NCkkmIzM5O2QgYWxzbyBub3RlIHRoYXQgbm90IGFsbCBwb2ludHMg ZGVzY3JpYmVkIGluIHRoZSBSRkMgNDAwNyB0ZXh0IGFyZTxicj4NCmRlc2NyaWJlZCBpbiBSRkMg NDI5MSAoYXQgbGVhc3Qgbm90IHZlcnkgY2xlYXJseSkuICZuYnNwO1NvLCBub3QganVzdDxicj4N CnJlbW92ZSB0aGUgdGV4dCBmcm9tIFJGQyA0MDA3LCBJJiMzOTtkIGxpa2UgdG8gdW5pZnkgaXQg aW4gdGhlIGFkZHJlc3M8YnI+DQphcmNoaXRlY3R1cmUsIGUuZy4gdXBkYXRlIHRoZSBmb2xsb3dp bmcgcGFydCBvZiBSRkMgNDI5MTo8ZGl2Pjxicj4NCjxkaXY+PGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO0FkbWluLUxvY2FsIHNjb3BlIGlzIHRoZSBzbWFsbGVzdCBzY29w ZSB0aGF0IG11c3QgYmU8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YWRt aW5pc3RyYXRpdmVseSBjb25maWd1cmVkLCBpLmUuLCBub3QgYXV0b21hdGljYWxseSBkZXJpdmVk PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2Zyb20gcGh5c2ljYWwgY29u bmVjdGl2aXR5IG9yIG90aGVyLCBub24tbXVsdGljYXN0LXJlbGF0ZWQ8YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Y29uZmlndXJhdGlvbi48YnI+DQo8YnI+DQo8L2Rpdj48 L2Rpdj5hcyBmb2xsb3dzOjxkaXY+PGJyPg0KPGRpdj48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7QWRtaW4tTG9jYWwgc2NvcGUgaXMgdGhlIHNtYWxsZXN0IHNjb3BlIHRo YXQgbXVzdCBiZTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDthZG1pbmlz dHJhdGl2ZWx5IGNvbmZpZ3VyZWQsIGkuZS4sIG5vdCBhdXRvbWF0aWNhbGx5IGRlcml2ZWQ8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZnJvbSBwaHlzaWNhbCBjb25uZWN0 aXZpdHkgb3Igb3RoZXIsIG5vbi1tdWx0aWNhc3QtcmVsYXRlZDxicj4NCjwvZGl2PjwvZGl2PiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtjb25maWd1cmF0aW9uLiAmbmJzcDtGb3Ig YWxsIG5vbi1yZXNlcnZlZCBzY29wZXMgZXhjZXB0IHRoZSBnbG9iYWw8YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7c2NvcGUsIHRoZSB6b25lIGJvdW5kYXJpZXMgbXVzdCBh bHNvIGJlIGFkbWluaXN0cmF0aXZlbHk8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7Y29uZmlndXJlZC48YnI+DQo8ZGl2PjxkaXY+PGJyPjwvZGl2PjwvZGl2PjwvYmxvY2tx dW90ZT48ZGl2PkkgdGhpbmsgdGhpcyBzdGF0ZW1lbnQgaXMgc2VsZi1jb250cmFkaWN0b3J5LiZu YnNwOyBXaGVuIGF1dG9tYXRpYyBjb25maWd1cmF0aW9uIGlzPGJyPmRpc2N1c3NlZCwgaXQgaXMg aW4gcmVsYXRpb24gdG8gem9uZSBib3VuZGFyaWVzLiZuYnNwOyBIZXJlJiMzOTtzIGFuIGF0dGVt cHQgdG8gZXhwbGFpbjxicj4NCjwvZGl2PjxkaXY+dGhpcyB3aXRob3V0IG5lZ2F0aW9uczo8YnI+ PGJyPjwvZGl2PjxkaXY+Jm5ic3A7ICZuYnNwOyBJbnRlcmZhY2UtTG9jYWwsIExpbmstTG9jYWws IGFuZCBSZWFsbS1Mb2NhbCBzY29wZSBib3VuZGFyaWVzIGFyZSBhdXRvbWF0aWNhbGx5PGJyPjwv ZGl2PjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRlcml2ZWQgZnJvbSBwaHlzaWNhbCBjb25uZWN0 aXZpdHkgb3Igb3RoZXIsIG5vbi1tdWx0aWNhc3QgcmVsYXRlZCBjb25maWd1cmF0aW9uLjxicj4N Cg0KDQo8L2Rpdj48ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyBHbG9iYWwgc2NvcGUgaGFzIG5vIGJv dW5kYXJ5LiZuYnNwOyBUaGUgYm91bmRhcmllcyBvZiBhbGwgb3RoZXIgbm9uLXJlc2VydmVkIHNj b3Blczxicj48L2Rpdj48ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyBhcmUgYWRtaW5pc3RyYXRpdmVs eSBjb25maWd1cmVkLjxicj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PGRp dj4mbHQ7UkNDJmd0OzwvZGl2PjxkaXY+VGhhdCBtYWtlcyBpdCBjbGVhci4gSU1PIFJGQzQwMDcg c2hvdWxkIGJlIGNoYW5nZWQgdG8gc29tZXRoaW5nIGxpa2U6PC9kaXY+DQo8ZGl2Pjxicj48L2Rp dj48ZGl2PjxkaXY+byAmbmJzcDtFYWNoIGludGVyZmFjZSBvbiBhIG5vZGUgY29tcHJpc2VzIGEg c2luZ2xlIHpvbmUgb2YgaW50ZXJmYWNlLWxvY2FsIHNjb3BlIChmb3IgbXVsdGljYXN0IG9ubHkp LjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+byAmbmJzcDtFYWNoIGxpbmsgYW5kIHRoZSBpbnRl cmZhY2VzIGF0dGFjaGVkIHRvIHRoYXQgbGluayBjb21wcmlzZSBhIHNpbmdsZSB6b25lIG9mIGxp bmstbG9jYWwgc2NvcGUgKGZvciBib3RoIHVuaWNhc3QgYW5kIG11bHRpY2FzdCkuPC9kaXY+DQo8 ZGl2Pjxicj48L2Rpdj48ZGl2Pm8gJm5ic3A7TXVsdGlwbGUgbGlua3MgYW5kIHRoZSBpbnRlcmZh Y2VzIGF0dGFjaGVkIHRvIHRob3NlIGxpbmtzIG1heSBmb3JtIGEgbXVsdGlsaW5rLWxvY2FsIHNj b3BlIGJhc2VkIG9uIHVuZGVybHlpbmcgbmV0d29yayB0ZWNobm9sb2d5OyBmb3IgZXhhbXBsZSwg W2NpdGUgdGhlIElQLW92ZXItSUVFRTgwMi4xNS40IGRlZmluaXRpb25dLjwvZGl2PjxkaXY+DQo8 YnI+PC9kaXY+PGRpdj5vICZuYnNwO1RoZXJlIGlzIGEgc2luZ2xlIHpvbmUgb2YgZ2xvYmFsIHNj b3BlIChmb3IgYm90aCB1bmljYXN0IGFuZCBtdWx0aWNhc3QpIGNvbXByaXNpbmcgYWxsIHRoZSBs aW5rcyBhbmQgaW50ZXJmYWNlcyBpbiB0aGUgSW50ZXJuZXQuPC9kaXY+PGRpdj48YnI+PC9kaXY+ PGRpdj5vICZuYnNwO1RoZSBib3VuZGFyaWVzIG9mIHpvbmVzIG9mIGEgc2NvcGUgb3RoZXIgdGhh biBpbnRlcmZhY2UtbG9jYWwsIGxpbmstbG9jYWwsIG11bHRpbGluay1sb2NhbCBhbmQgZ2xvYmFs IG11c3QgYmUgZGVmaW5lZCBhbmQgY29uZmlndXJlZCBieSBuZXR3b3JrIGFkbWluaXN0cmF0b3Jz LjwvZGl2Pg0KPGRpdj48YnI+PC9kaXY+PGRpdj5FaXRoZXIgdGhhdCBvciBqdXN0IHJlbW92ZSB0 aGUgdGV4dCBhcyBSYWxwaCBzdWdnZXN0ZWQgZWFybGllci48L2Rpdj48ZGl2PiZsdDsvUkNDJmd0 OzwvZGl2PjwvZGl2Pg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFy Z2luOjBweCAwcHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0LXdpZHRoOjFweDtib3JkZXItbGVmdC1j b2xvcjpyZ2IoMjA0LDIwNCwyMDQpO2JvcmRlci1sZWZ0LXN0eWxlOnNvbGlkO3BhZGRpbmctbGVm dDoxZXgiPjxkaXYgZGlyPSJsdHIiPjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48ZGl2IGNsYXNz PSJnbWFpbF9xdW90ZSI+DQo8ZGl2Pjxicj48L2Rpdj48ZGl2PkJUVywganVzdCBteSBvcGluaW9u LCBidXQgJnF1b3Q7UmVhbG0tTG9jYWwmcXVvdDsgbWlnaHQgYmUgbW9yZSBtZWFuaW5nZnVsbHkg bmFtZWQ8YnI+DQoNCjwvZGl2PjxkaXY+JnF1b3Q7TXVsdGlsaW5rLUxvY2FsJnF1b3Q7PC9kaXY+ PC9kaXY+PC9kaXY+PC9kaXY+PC9ibG9ja3F1b3RlPjxkaXY+Jmx0O1JDQyZndDsgSSBhZ3JlZSAt IGl0IGlzIG1vcmUgbWVhbmluZ2Z1bCZsdDsvUkNDJmd0OyZuYnNwOzwvZGl2PjxibG9ja3F1b3Rl IGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDtib3Jk ZXItbGVmdC13aWR0aDoxcHg7Ym9yZGVyLWxlZnQtY29sb3I6cmdiKDIwNCwyMDQsMjA0KTtib3Jk ZXItbGVmdC1zdHlsZTpzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgZGlyPSJsdHIiPjxk aXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+PGRpdj48c3Bh bj48Zm9udCBjb2xvcj0iIzg4ODg4OCI+PGJyPjxicj48L2ZvbnQ+PC9zcGFuPjwvZGl2PjxzcGFu Pjxmb250IGNvbG9yPSIjODg4ODg4Ij48ZGl2Pi1LLTxicj48YnI+PC9kaXY+PGJsb2NrcXVvdGUg Y2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4O2JvcmRl ci1sZWZ0LXdpZHRoOjFweDtib3JkZXItbGVmdC1zdHlsZTpzb2xpZDtib3JkZXItbGVmdC1jb2xv cjpyZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmctbGVmdDoxZXgiPg0KDQo8ZGl2PjxkaXY+DQoNCi0t PGJyPg0KSklOTUVJLCBUYXR1eWE8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCklFVEYgSVB2NiB3b3Jr aW5nIGdyb3VwIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzppcHY2QGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+aXB2NkBpZXRmLm9yZzwvYT48YnI+DQpBZG1pbmlzdHJhdGl2ZSBS ZXF1ZXN0czogPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9p cHY2IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9pcHY2PC9hPjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KPC9kaXY+PC9kaXY+PC9ibG9ja3F1b3Rl PjwvZm9udD48L3NwYW4+PC9kaXY+PGJyPjwvZGl2PjwvZGl2Pg0KPGJyPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KUm9sbCBtYWlsaW5nIGxpc3Q8 YnI+DQo8YSBocmVmPSJtYWlsdG86Um9sbEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPlJvbGxA aWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9yb2xsIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9yb2xsPC9hPjxicj4NCjxicj48L2Jsb2NrcXVvdGU+PC9kaXY+PGJyPjwvZGl2 PjwvZGl2Pg0K --047d7b343dc46d717704e9772b07-- From stokcons@xs4all.nl Fri Oct 25 02:52:48 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B473511E83A6 for ; Fri, 25 Oct 2013 02:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 bD72rXQoPLFZ for ; Fri, 25 Oct 2013 02:52:43 -0700 (PDT) Received: from smtp-vbr1.xs4all.nl (smtp-vbr1.xs4all.nl [194.109.24.21]) by ietfa.amsl.com (Postfix) with ESMTP id 70DD911E83B1 for ; Fri, 25 Oct 2013 02:52:40 -0700 (PDT) Received: from roundcube.xs4all.nl (roundcube9.xs4all.net [194.109.20.207]) by smtp-vbr1.xs4all.nl (8.13.8/8.13.8) with ESMTP id r9P9qcq6069165 for ; Fri, 25 Oct 2013 11:52:39 +0200 (CEST) (envelope-from stokcons@xs4all.nl) Received: from a82-95-140-48.adsl.xs4all.nl ([82.95.140.48]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Fri, 25 Oct 2013 11:52:38 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Fri, 25 Oct 2013 11:52:38 +0200 From: peter van der Stok To: roll@ietf.org Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <3599.1381852752@sandelman.ca> <525DC6C9.2010808@gridmerge.com> <525E5064.4050109@gridmerge.com> <3CC8783F-F4DA-47B9-A051-DBBA6EF00C19@gmail.com> <52FECA00-C316-4693-A821-7EA6510AC0F8@gmail.com> Message-ID: <1889382d8c35c9325f1bc615f6bf6c8e@xs4all.nl> X-Sender: stokcons@xs4all.nl (YOMrsnyBA3Zt8D/9BpMwqWkPRvTIfu6y) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Subject: Re: [Roll] draft-ietf-6man-multicast-scopes updates RFC 4007 (Was Re: [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: consultancy@vanderstok.org, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 09:52:48 -0000 I like the consensus that seems to emerge. It should be clear that the realm-local specification concerns a homogeneous multi-link network For example: o Multiple links, following the same IP over Foo specification, and the interfaces attached to those links may form a multilink-local scope based on underlying network technology; for example, [cite the IP-over-IEEE802.15.4 definition]. Peter Robert Cragie schreef op 2013-10-24 08:59: > On 23 October 2013 22:38, Kerry Lynn wrote: > >> On Wed, Oct 23, 2013 at 5:21 PM, 神明達哉 >> wrote: >> >>> At Wed, 23 Oct 2013 15:56:46 -0400, >>> >>> Ralph Droms wrote: >>> >>>> Perhaps we want to go a step farther and take the zone boundary >>> text >>>> out of RFC 4007 altogether? >>> >>> Basically works for me. > > Me too > >>>> OLD: >>>> >>>> o The boundaries of zones of a scope other than >>> interface-local, >>>> link-local, and global must be defined and configured by >>> network >>>> administrators >>>> >>>> NEW: >>>> >>>> o The boundaries of zones of a scope are defined by the IPv6 >>>> addressing architecture. >>> >>> With a reference (it's currently RFC 4291)? >>> >>> I'd also note that not all points described in the RFC 4007 text >>> are >>> described in RFC 4291 (at least not very clearly). So, not just >>> remove the text from RFC 4007, I'd like to unify it in the >>> address >>> architecture, e.g. update the following part of RFC 4291: >>> >>> Admin-Local scope is the smallest scope that must be >>> administratively configured, i.e., not automatically derived >>> from physical connectivity or other, non-multicast-related >>> configuration. >>> >>> as follows: >>> >>> Admin-Local scope is the smallest scope that must be >>> administratively configured, i.e., not automatically derived >>> from physical connectivity or other, non-multicast-related >>> configuration. For all non-reserved scopes except the global >>> scope, the zone boundaries must also be administratively >>> configured. >> >> I think this statement is self-contradictory. When automatic >> configuration is >> discussed, it is in relation to zone boundaries. Here's an attempt >> to explain >> >> this without negations: >> >> Interface-Local, Link-Local, and Realm-Local scope boundaries are >> automatically >> >> derived from physical connectivity or other, non-multicast related >> configuration. >> >> Global scope has no boundary. The boundaries of all other >> non-reserved scopes >> >> are administratively configured. > > > That makes it clear. IMO RFC4007 should be changed to something like: > > o Each interface on a node comprises a single zone of interface-local > scope (for multicast only). > > o Each link and the interfaces attached to that link comprise a single > zone of link-local scope (for both unicast and multicast). > > o Multiple links and the interfaces attached to those links may form a > multilink-local scope based on underlying network technology; for > example, [cite the IP-over-IEEE802.15.4 definition]. > > o There is a single zone of global scope (for both unicast and > multicast) comprising all the links and interfaces in the Internet. > > o The boundaries of zones of a scope other than interface-local, > link-local, multilink-local and global must be defined and configured > by network administrators. > > Either that or just remove the text as Ralph suggested earlier. > > >> BTW, just my opinion, but "Realm-Local" might be more meaningfully >> named >> >> "Multilink-Local" > > I agree - it is more meaningful > >> -K- >> >>> -- >>> JINMEI, Tatuya >>> >> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: >>> https://www.ietf.org/mailman/listinfo/ipv6 [1] >>> >> -------------------------------------------------------------------- >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll [2] > > > > Links: > ------ > [1] https://www.ietf.org/mailman/listinfo/ipv6 > [2] https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From Daniel.Popa@itron.com Fri Oct 25 04:35:26 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00CD111E831B for ; Fri, 25 Oct 2013 04:35:26 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXeWwfMtVRoZ for ; Fri, 25 Oct 2013 04:35:21 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0158.outbound.protection.outlook.com [207.46.163.158]) by ietfa.amsl.com (Postfix) with ESMTP id C4EF611E83BF for ; Fri, 25 Oct 2013 04:35:19 -0700 (PDT) Received: from CO1PR04MB346.namprd04.prod.outlook.com (10.141.52.25) by CO1PR04MB345.namprd04.prod.outlook.com (10.141.52.20) with Microsoft SMTP Server (TLS) id 15.0.785.10; Fri, 25 Oct 2013 11:35:14 +0000 Received: from CO1PR04MB346.namprd04.prod.outlook.com ([169.254.1.219]) by CO1PR04MB346.namprd04.prod.outlook.com ([169.254.1.238]) with mapi id 15.00.0785.001; Fri, 25 Oct 2013 11:35:14 +0000 From: "Popa, Daniel" To: "consultancy@vanderstok.org" , "Routing Over Low power and Lossy networks" Thread-Topic: [Roll] draft-ietf-6man-multicast-scopes updates RFC 4007 (Was Re: [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local) Thread-Index: AQHO0DhAMKsCNOt2fEejpOHp8pqxMpoDbJ2AgAHC0gCAABmFoA== Date: Fri, 25 Oct 2013 11:35:13 +0000 Message-ID: References: <3599.1381852752@sandelman.ca> <525DC6C9.2010808@gridmerge.com> <525E5064.4050109@gridmerge.com> <3CC8783F-F4DA-47B9-A051-DBBA6EF00C19@gmail.com> <52FECA00-C316-4693-A821-7EA6510AC0F8@gmail.com> <1889382d8c35c9325f1bc615f6bf6c8e@xs4all.nl> In-Reply-To: <1889382d8c35c9325f1bc615f6bf6c8e@xs4all.nl> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [109.2.132.2] x-forefront-prvs: 0010D93EFE x-forefront-antispam-report: SFV:NSPM; SFS:(377424004)(24454002)(199002)(189002)(55784002)(51704005)(377454003)(63696002)(81342001)(65816001)(74316001)(85306002)(66066001)(80022001)(81686001)(69226001)(81816001)(74662001)(31966008)(47446002)(74502001)(83322001)(81542001)(80976001)(19580405001)(19580395003)(15975445006)(76786001)(74706001)(56776001)(76796001)(50986001)(49866001)(47976001)(33646001)(47736001)(51856001)(46102001)(54316002)(54356001)(77982001)(4396001)(56816003)(53806001)(85806002)(59766001)(77096001)(76576001)(76482001)(83072001)(79102001)(74876001)(74366001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR04MB345; H:CO1PR04MB346.namprd04.prod.outlook.com; CLIP:109.2.132.2; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: itron.com Subject: Re: [Roll] draft-ietf-6man-multicast-scopes updates RFC 4007 (Was Re: [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 11:35:26 -0000 SGkgUGV0ZXIsIA0KDQpCeSAiaG9tb2dlbmVvdXMgbXVsdGktbGluayBuZXR3b3JrIiBkbyB5b3Ug cmVmZXIgdG8gImhvbW9nZW5lb3VzIGxpbmstbGF5ZXIgdGVjaG5vbG9neSIgPyANCg0KSWYgdGhp cyBpcyB0aGUgY2FzZSwgSSBzdWdnZXN0IHdlIGRvIG5vdCBjb3JyZWxhdGUgdGhlIHNjb3BlIG9m IHRoZSBtdWx0aWNhc3QgdG8gdGhlIHVzZSBvZiBhIHNwZWNpZmljIGxpbmstbGF5ZXIgdGVjaG5v bG9neS4uLiBXZSBzaG91bGQgYmUgYWJsZSB0byBkZXBsb3kgc3lzdGVtcyB3aGVyZSBhbGwgbm9k ZXMgaW4gYSBtdWx0aS1saW5rIG5ldHdvcmsgY2FuIGJlIG1lbWJlcnMgb2YgdGhlIHNhbWUgIm11 bHRpbGluay1sb2NhbCBtdWx0aWNhc3Qgc2NvcGUiLCBpbmRlcGVuZGVudGx5IG9mIHRoZSBsaW5r LWxheWVyIHRlY2hub2xvZ3kgdGhleSB1c2UgKGhvbW9nZW5lb3VzIG9yIGhldGVyb2dlbmVvdXMp IHRvIGNvbW11bmljYXRlIHdpdGggZWFjaCBvdGhlci4NCg0KUmVnYXJkcywNCkRhbmllbCAgDQoN Ci0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KRGXCoDogcm9sbC1ib3VuY2VzQGlldGYub3Jn IFttYWlsdG86cm9sbC1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIHBldGVyIHZhbiBk ZXIgU3Rvaw0KRW52b3nDqcKgOiB2ZW5kcmVkaSAyNSBvY3RvYnJlIDIwMTMgMTE6NTMNCsOAwqA6 IHJvbGxAaWV0Zi5vcmcNCk9iamV0wqA6IFJlOiBbUm9sbF0gZHJhZnQtaWV0Zi02bWFuLW11bHRp Y2FzdC1zY29wZXMgdXBkYXRlcyBSRkMgNDAwNyAoV2FzIFJlOiBbcm9sbF0gIzEzMjogZHJhZnQt aWV0Zi1yb2xsLXRyaWNrbGUtbWNhc3QtMDQgLSBDbGFyaWZ5IHNjb3BlIHZhbHVlIG9mIDMgLSBz dWJuZXQtbG9jYWwpDQoNCkkgbGlrZSB0aGUgY29uc2Vuc3VzIHRoYXQgc2VlbXMgdG8gZW1lcmdl Lg0KDQpJdCBzaG91bGQgYmUgY2xlYXIgdGhhdCB0aGUgcmVhbG0tbG9jYWwgc3BlY2lmaWNhdGlv biBjb25jZXJucyBhIGhvbW9nZW5lb3VzIG11bHRpLWxpbmsgbmV0d29yayBGb3IgZXhhbXBsZToN Cg0KICBvIE11bHRpcGxlIGxpbmtzLCBmb2xsb3dpbmcgdGhlIHNhbWUgSVAgb3ZlciBGb28gc3Bl Y2lmaWNhdGlvbiwgYW5kIHRoZSBpbnRlcmZhY2VzIGF0dGFjaGVkIHRvIHRob3NlIGxpbmtzIG1h eSBmb3JtIGEgbXVsdGlsaW5rLWxvY2FsIHNjb3BlIGJhc2VkIG9uIHVuZGVybHlpbmcgbmV0d29y ayB0ZWNobm9sb2d5OyBmb3IgZXhhbXBsZSwgW2NpdGUgdGhlDQpJUC1vdmVyLUlFRUU4MDIuMTUu NCBkZWZpbml0aW9uXS4NCg0KUGV0ZXINCg0KDQpSb2JlcnQgQ3JhZ2llIHNjaHJlZWYgb3AgMjAx My0xMC0yNCAwODo1OToNCj4gT24gMjMgT2N0b2JlciAyMDEzIDIyOjM4LCBLZXJyeSBMeW5uIDxr ZXJseW5AaWVlZS5vcmc+IHdyb3RlOg0KPiANCj4+IE9uIFdlZCwgT2N0IDIzLCAyMDEzIGF0IDU6 MjEgUE0sIOelnuaYjumBlOWTiSA8amlubWVpQHdpZGUuYWQuanA+DQo+PiB3cm90ZToNCj4+IA0K Pj4+IEF0IFdlZCwgMjMgT2N0IDIwMTMgMTU6NTY6NDYgLTA0MDAsDQo+Pj4gDQo+Pj4gUmFscGgg RHJvbXMgPHJkcm9tcy5pZXRmQGdtYWlsLmNvbT4gd3JvdGU6DQo+Pj4gDQo+Pj4+IFBlcmhhcHMg d2Ugd2FudCB0byBnbyBhIHN0ZXAgZmFydGhlciBhbmQgdGFrZSB0aGUgem9uZSBib3VuZGFyeQ0K Pj4+IHRleHQNCj4+Pj4gb3V0IG9mIFJGQyA0MDA3IGFsdG9nZXRoZXI/DQo+Pj4gDQo+Pj4gQmFz aWNhbGx5IHdvcmtzIGZvciBtZS4NCj4gDQo+IDxSQ0M+TWUgdG9vPC9SQ0M+DQo+IA0KPj4+PiBP TEQ6DQo+Pj4+IA0KPj4+PiBvIFRoZSBib3VuZGFyaWVzIG9mIHpvbmVzIG9mIGEgc2NvcGUgb3Ro ZXIgdGhhbg0KPj4+IGludGVyZmFjZS1sb2NhbCwNCj4+Pj4gbGluay1sb2NhbCwgYW5kIGdsb2Jh bCBtdXN0IGJlIGRlZmluZWQgYW5kIGNvbmZpZ3VyZWQgYnkNCj4+PiBuZXR3b3JrDQo+Pj4+IGFk bWluaXN0cmF0b3JzDQo+Pj4+IA0KPj4+PiBORVc6DQo+Pj4+IA0KPj4+PiBvIFRoZSBib3VuZGFy aWVzIG9mIHpvbmVzIG9mIGEgc2NvcGUgYXJlIGRlZmluZWQgYnkgdGhlIElQdjYgDQo+Pj4+IGFk ZHJlc3NpbmcgYXJjaGl0ZWN0dXJlLg0KPj4+IA0KPj4+IFdpdGggYSByZWZlcmVuY2UgKGl0J3Mg Y3VycmVudGx5IFJGQyA0MjkxKT8NCj4+PiANCj4+PiBJJ2QgYWxzbyBub3RlIHRoYXQgbm90IGFs bCBwb2ludHMgZGVzY3JpYmVkIGluIHRoZSBSRkMgNDAwNyB0ZXh0IGFyZSANCj4+PiBkZXNjcmli ZWQgaW4gUkZDIDQyOTEgKGF0IGxlYXN0IG5vdCB2ZXJ5IGNsZWFybHkpLiBTbywgbm90IGp1c3Qg DQo+Pj4gcmVtb3ZlIHRoZSB0ZXh0IGZyb20gUkZDIDQwMDcsIEknZCBsaWtlIHRvIHVuaWZ5IGl0 IGluIHRoZSBhZGRyZXNzIA0KPj4+IGFyY2hpdGVjdHVyZSwgZS5nLiB1cGRhdGUgdGhlIGZvbGxv d2luZyBwYXJ0IG9mIFJGQyA0MjkxOg0KPj4+IA0KPj4+IEFkbWluLUxvY2FsIHNjb3BlIGlzIHRo ZSBzbWFsbGVzdCBzY29wZSB0aGF0IG11c3QgYmUgDQo+Pj4gYWRtaW5pc3RyYXRpdmVseSBjb25m aWd1cmVkLCBpLmUuLCBub3QgYXV0b21hdGljYWxseSBkZXJpdmVkIGZyb20gDQo+Pj4gcGh5c2lj YWwgY29ubmVjdGl2aXR5IG9yIG90aGVyLCBub24tbXVsdGljYXN0LXJlbGF0ZWQgY29uZmlndXJh dGlvbi4NCj4+PiANCj4+PiBhcyBmb2xsb3dzOg0KPj4+IA0KPj4+IEFkbWluLUxvY2FsIHNjb3Bl IGlzIHRoZSBzbWFsbGVzdCBzY29wZSB0aGF0IG11c3QgYmUgDQo+Pj4gYWRtaW5pc3RyYXRpdmVs eSBjb25maWd1cmVkLCBpLmUuLCBub3QgYXV0b21hdGljYWxseSBkZXJpdmVkIGZyb20gDQo+Pj4g cGh5c2ljYWwgY29ubmVjdGl2aXR5IG9yIG90aGVyLCBub24tbXVsdGljYXN0LXJlbGF0ZWQgY29u ZmlndXJhdGlvbi4gDQo+Pj4gRm9yIGFsbCBub24tcmVzZXJ2ZWQgc2NvcGVzIGV4Y2VwdCB0aGUg Z2xvYmFsIHNjb3BlLCB0aGUgem9uZSANCj4+PiBib3VuZGFyaWVzIG11c3QgYWxzbyBiZSBhZG1p bmlzdHJhdGl2ZWx5IGNvbmZpZ3VyZWQuDQo+PiANCj4+IEkgdGhpbmsgdGhpcyBzdGF0ZW1lbnQg aXMgc2VsZi1jb250cmFkaWN0b3J5LiBXaGVuIGF1dG9tYXRpYyANCj4+IGNvbmZpZ3VyYXRpb24g aXMgZGlzY3Vzc2VkLCBpdCBpcyBpbiByZWxhdGlvbiB0byB6b25lIGJvdW5kYXJpZXMuIA0KPj4g SGVyZSdzIGFuIGF0dGVtcHQgdG8gZXhwbGFpbg0KPj4gDQo+PiB0aGlzIHdpdGhvdXQgbmVnYXRp b25zOg0KPj4gDQo+PiBJbnRlcmZhY2UtTG9jYWwsIExpbmstTG9jYWwsIGFuZCBSZWFsbS1Mb2Nh bCBzY29wZSBib3VuZGFyaWVzIGFyZSANCj4+IGF1dG9tYXRpY2FsbHkNCj4+IA0KPj4gZGVyaXZl ZCBmcm9tIHBoeXNpY2FsIGNvbm5lY3Rpdml0eSBvciBvdGhlciwgbm9uLW11bHRpY2FzdCByZWxh dGVkIA0KPj4gY29uZmlndXJhdGlvbi4NCj4+IA0KPj4gR2xvYmFsIHNjb3BlIGhhcyBubyBib3Vu ZGFyeS4gVGhlIGJvdW5kYXJpZXMgb2YgYWxsIG90aGVyIA0KPj4gbm9uLXJlc2VydmVkIHNjb3Bl cw0KPj4gDQo+PiBhcmUgYWRtaW5pc3RyYXRpdmVseSBjb25maWd1cmVkLg0KPiANCj4gPFJDQz4N Cj4gVGhhdCBtYWtlcyBpdCBjbGVhci4gSU1PIFJGQzQwMDcgc2hvdWxkIGJlIGNoYW5nZWQgdG8g c29tZXRoaW5nIGxpa2U6DQo+IA0KPiBvIEVhY2ggaW50ZXJmYWNlIG9uIGEgbm9kZSBjb21wcmlz ZXMgYSBzaW5nbGUgem9uZSBvZiBpbnRlcmZhY2UtbG9jYWwgDQo+IHNjb3BlIChmb3IgbXVsdGlj YXN0IG9ubHkpLg0KPiANCj4gbyBFYWNoIGxpbmsgYW5kIHRoZSBpbnRlcmZhY2VzIGF0dGFjaGVk IHRvIHRoYXQgbGluayBjb21wcmlzZSBhIHNpbmdsZSANCj4gem9uZSBvZiBsaW5rLWxvY2FsIHNj b3BlIChmb3IgYm90aCB1bmljYXN0IGFuZCBtdWx0aWNhc3QpLg0KPiANCj4gbyBNdWx0aXBsZSBs aW5rcyBhbmQgdGhlIGludGVyZmFjZXMgYXR0YWNoZWQgdG8gdGhvc2UgbGlua3MgbWF5IGZvcm0g YSANCj4gbXVsdGlsaW5rLWxvY2FsIHNjb3BlIGJhc2VkIG9uIHVuZGVybHlpbmcgbmV0d29yayB0 ZWNobm9sb2d5OyBmb3IgDQo+IGV4YW1wbGUsIFtjaXRlIHRoZSBJUC1vdmVyLUlFRUU4MDIuMTUu NCBkZWZpbml0aW9uXS4NCj4gDQo+IG8gVGhlcmUgaXMgYSBzaW5nbGUgem9uZSBvZiBnbG9iYWwg c2NvcGUgKGZvciBib3RoIHVuaWNhc3QgYW5kDQo+IG11bHRpY2FzdCkgY29tcHJpc2luZyBhbGwg dGhlIGxpbmtzIGFuZCBpbnRlcmZhY2VzIGluIHRoZSBJbnRlcm5ldC4NCj4gDQo+IG8gVGhlIGJv dW5kYXJpZXMgb2Ygem9uZXMgb2YgYSBzY29wZSBvdGhlciB0aGFuIGludGVyZmFjZS1sb2NhbCwg DQo+IGxpbmstbG9jYWwsIG11bHRpbGluay1sb2NhbCBhbmQgZ2xvYmFsIG11c3QgYmUgZGVmaW5l ZCBhbmQgY29uZmlndXJlZCANCj4gYnkgbmV0d29yayBhZG1pbmlzdHJhdG9ycy4NCj4gDQo+IEVp dGhlciB0aGF0IG9yIGp1c3QgcmVtb3ZlIHRoZSB0ZXh0IGFzIFJhbHBoIHN1Z2dlc3RlZCBlYXJs aWVyLg0KPiA8L1JDQz4NCj4gDQo+PiBCVFcsIGp1c3QgbXkgb3BpbmlvbiwgYnV0ICJSZWFsbS1M b2NhbCIgbWlnaHQgYmUgbW9yZSBtZWFuaW5nZnVsbHkgDQo+PiBuYW1lZA0KPj4gDQo+PiAiTXVs dGlsaW5rLUxvY2FsIg0KPiANCj4gPFJDQz4gSSBhZ3JlZSAtIGl0IGlzIG1vcmUgbWVhbmluZ2Z1 bDwvUkNDPg0KPiANCj4+IC1LLQ0KPj4gDQo+Pj4gLS0NCj4+PiBKSU5NRUksIFRhdHV5YQ0KPj4+ IA0KPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCj4+PiBJRVRGIElQdjYgd29ya2luZyBncm91cCBtYWlsaW5nIGxp c3QgaXB2NkBpZXRmLm9yZyBBZG1pbmlzdHJhdGl2ZSANCj4+PiBSZXF1ZXN0czoNCj4+PiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYgWzFdDQo+Pj4gDQo+PiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KPj4gDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPj4gUm9sbCBtYWlsaW5nIGxpc3QNCj4+IFJvbGxAaWV0Zi5vcmcNCj4+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9sbCBbMl0NCj4gDQo+IA0KPiANCj4g TGlua3M6DQo+IC0tLS0tLQ0KPiBbMV0gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9pcHY2DQo+IFsyXSBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Jv bGwNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+IFJvbGwgbWFpbGluZyBsaXN0DQo+IFJvbGxAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb2xsDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KUm9sbCBtYWlsaW5nIGxpc3QNClJvbGxAaWV0Zi5vcmcNCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9sbA0K From robert.cragie@gmail.com Fri Oct 25 09:39: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 6955211E8381 for ; Fri, 25 Oct 2013 09:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.685 X-Spam-Level: X-Spam-Status: No, score=-1.685 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bcjy0lh99QNc for ; Fri, 25 Oct 2013 09:39:49 -0700 (PDT) Received: from mail-ee0-x229.google.com (mail-ee0-x229.google.com [IPv6:2a00:1450:4013:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id E638E11E836C for ; Fri, 25 Oct 2013 09:39:41 -0700 (PDT) Received: by mail-ee0-f41.google.com with SMTP id d49so2148500eek.0 for ; Fri, 25 Oct 2013 09:39:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=IFim6oBiyt8IK4Vp2MNqmcIXiE8lwmgl9wauT0uoPdk=; b=Tuj57GI8p/dLw7a3iWlTwZGR5I4EsLi4AdGWLwehlG6UqhjNzpiyrUsEY5LnpFmgIn C8LlR0Y17QnORn2q0hWUIWTTNNwUd5VXW9gNLbWg1HvAhg8/KsF7eqf4B6chxln/Fe3t VKX1gSJQTMD2ayCwDf7YN2By8s+W0GN18x+IbhQLFIvUQCyDC0r3is4zV83SZ/aVbxgD n1UpcXMRfHepqQetde6s88SDWEF839HYIA4bmtKCeV4xsYdeBTQP1QcyyrMeoRlK2EKn ykw7T/zcU/XgOStQTEMzM2lr9zOER0PkVXU9BYimLlzkyg++z1gtxt/ElDT5hawB3g4d tZTQ== MIME-Version: 1.0 X-Received: by 10.14.3.9 with SMTP id 9mr8660442eeg.72.1382719180688; Fri, 25 Oct 2013 09:39:40 -0700 (PDT) Sender: robert.cragie@gmail.com Received: by 10.15.44.1 with HTTP; Fri, 25 Oct 2013 09:39:40 -0700 (PDT) Received: by 10.15.44.1 with HTTP; Fri, 25 Oct 2013 09:39:40 -0700 (PDT) In-Reply-To: References: <3599.1381852752@sandelman.ca> <525DC6C9.2010808@gridmerge.com> <525E5064.4050109@gridmerge.com> <3CC8783F-F4DA-47B9-A051-DBBA6EF00C19@gmail.com> <52FECA00-C316-4693-A821-7EA6510AC0F8@gmail.com> <1889382d8c35c9325f1bc615f6bf6c8e@xs4all.nl> Date: Fri, 25 Oct 2013 17:39:40 +0100 X-Google-Sender-Auth: oSXiaVfgcz3a2kc2T3y6Lx8XxbI Message-ID: From: Robert Cragie To: "roll@ietf.org WG" Content-Type: multipart/alternative; boundary=047d7b6250bc96d08d04e993653f Subject: Re: [Roll] draft-ietf-6man-multicast-scopes updates RFC 4007 (Was Re: [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert.cragie@gridmerge.com, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 16:39:50 -0000 --047d7b6250bc96d08d04e993653f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Daniel, I think the conclusion in that case was that scope 4 would have to be used as it would be difficult to imagine anything other than administrative configuration for a scope which spans multiple links on different link layer technologies. Robert On 25 Oct 2013 12:35, "Popa, Daniel" wrote: > Hi Peter, > > By "homogeneous multi-link network" do you refer to "homogeneous > link-layer technology" ? > > If this is the case, I suggest we do not correlate the scope of the > multicast to the use of a specific link-layer technology... We should be > able to deploy systems where all nodes in a multi-link network can be > members of the same "multilink-local multicast scope", independently of t= he > link-layer technology they use (homogeneous or heterogeneous) to > communicate with each other. > > Regards, > Daniel > > -----Message d'origine----- > De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de > peter van der Stok > Envoy=C3=A9 : vendredi 25 octobre 2013 11:53 > =C3=80 : roll@ietf.org > Objet : Re: [Roll] draft-ietf-6man-multicast-scopes updates RFC 4007 (Was > Re: [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value o= f > 3 - subnet-local) > > I like the consensus that seems to emerge. > > It should be clear that the realm-local specification concerns a > homogeneous multi-link network For example: > > o Multiple links, following the same IP over Foo specification, and the > interfaces attached to those links may form a multilink-local scope based > on underlying network technology; for example, [cite the > IP-over-IEEE802.15.4 definition]. > > Peter > > > Robert Cragie schreef op 2013-10-24 08:59: > > On 23 October 2013 22:38, Kerry Lynn wrote: > > > >> On Wed, Oct 23, 2013 at 5:21 PM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 = > >> wrote: > >> > >>> At Wed, 23 Oct 2013 15:56:46 -0400, > >>> > >>> Ralph Droms wrote: > >>> > >>>> Perhaps we want to go a step farther and take the zone boundary > >>> text > >>>> out of RFC 4007 altogether? > >>> > >>> Basically works for me. > > > > Me too > > > >>>> OLD: > >>>> > >>>> o The boundaries of zones of a scope other than > >>> interface-local, > >>>> link-local, and global must be defined and configured by > >>> network > >>>> administrators > >>>> > >>>> NEW: > >>>> > >>>> o The boundaries of zones of a scope are defined by the IPv6 > >>>> addressing architecture. > >>> > >>> With a reference (it's currently RFC 4291)? > >>> > >>> I'd also note that not all points described in the RFC 4007 text are > >>> described in RFC 4291 (at least not very clearly). So, not just > >>> remove the text from RFC 4007, I'd like to unify it in the address > >>> architecture, e.g. update the following part of RFC 4291: > >>> > >>> Admin-Local scope is the smallest scope that must be > >>> administratively configured, i.e., not automatically derived from > >>> physical connectivity or other, non-multicast-related configuration. > >>> > >>> as follows: > >>> > >>> Admin-Local scope is the smallest scope that must be > >>> administratively configured, i.e., not automatically derived from > >>> physical connectivity or other, non-multicast-related configuration. > >>> For all non-reserved scopes except the global scope, the zone > >>> boundaries must also be administratively configured. > >> > >> I think this statement is self-contradictory. When automatic > >> configuration is discussed, it is in relation to zone boundaries. > >> Here's an attempt to explain > >> > >> this without negations: > >> > >> Interface-Local, Link-Local, and Realm-Local scope boundaries are > >> automatically > >> > >> derived from physical connectivity or other, non-multicast related > >> configuration. > >> > >> Global scope has no boundary. The boundaries of all other > >> non-reserved scopes > >> > >> are administratively configured. > > > > > > That makes it clear. IMO RFC4007 should be changed to something like: > > > > o Each interface on a node comprises a single zone of interface-local > > scope (for multicast only). > > > > o Each link and the interfaces attached to that link comprise a single > > zone of link-local scope (for both unicast and multicast). > > > > o Multiple links and the interfaces attached to those links may form a > > multilink-local scope based on underlying network technology; for > > example, [cite the IP-over-IEEE802.15.4 definition]. > > > > o There is a single zone of global scope (for both unicast and > > multicast) comprising all the links and interfaces in the Internet. > > > > o The boundaries of zones of a scope other than interface-local, > > link-local, multilink-local and global must be defined and configured > > by network administrators. > > > > Either that or just remove the text as Ralph suggested earlier. > > > > > >> BTW, just my opinion, but "Realm-Local" might be more meaningfully > >> named > >> > >> "Multilink-Local" > > > > I agree - it is more meaningful > > > >> -K- > >> > >>> -- > >>> JINMEI, Tatuya > >>> > >> -------------------------------------------------------------------- > >>> IETF IPv6 working group mailing list ipv6@ietf.org Administrative > >>> Requests: > >>> https://www.ietf.org/mailman/listinfo/ipv6 [1] > >>> > >> -------------------------------------------------------------------- > >> > >> _______________________________________________ > >> Roll mailing list > >> Roll@ietf.org > >> https://www.ietf.org/mailman/listinfo/roll [2] > > > > > > > > Links: > > ------ > > [1] https://www.ietf.org/mailman/listinfo/ipv6 > > [2] https://www.ietf.org/mailman/listinfo/roll > > > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --047d7b6250bc96d08d04e993653f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Daniel,

I think the conclusion in that case was that scope 4 would h= ave to be used as it would be difficult to imagine anything other than admi= nistrative configuration for a scope which spans multiple links on differen= t link layer technologies.

Robert

On 25 Oct 2013 12:35, "Popa, Daniel" &= lt;Daniel.Popa@itron.com> w= rote:
Hi Peter,

By "homogeneous multi-link network" do you refer to "homogen= eous link-layer technology" ?

If this is the case, I suggest we do not correlate the scope of the multica= st to the use of a specific link-layer technology... We should be able to d= eploy systems where all nodes in a multi-link network can be members of the= same "multilink-local multicast scope", independently of the lin= k-layer technology they use (homogeneous or heterogeneous) to communicate w= ith each other.

Regards,
Daniel

-----Message d'origine-----
De=C2=A0: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de peter van der Stok
Envoy=C3=A9=C2=A0: vendredi 25 octobre 2013 11:53
=C3=80=C2=A0: roll@ietf.org
Objet=C2=A0: Re: [Roll] draft-ietf-6man-multicast-scopes updates RFC 4007 (= Was Re: [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value= of 3 - subnet-local)

I like the consensus that seems to emerge.

It should be clear that the realm-local specification concerns a homogeneou= s multi-link network For example:

=C2=A0 o Multiple links, following the same IP over Foo specification, and = the interfaces attached to those links may form a multilink-local scope bas= ed on underlying network technology; for example, [cite the
IP-over-IEEE802.15.4 definition].

Peter


Robert Cragie schreef op 2013-10-24 08:59:
> On 23 October 2013 22:38, Kerry Lynn <kerlyn@ieee.org> wrote:
>
>> On Wed, Oct 23, 2013 at 5:21 PM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93= =89 <jinmei@wide.ad.jp>
>> wrote:
>>
>>> At Wed, 23 Oct 2013 15:56:46 -0400,
>>>
>>> Ralph Droms <rdrom= s.ietf@gmail.com> wrote:
>>>
>>>> Perhaps we want to go a step farther and take the zone bou= ndary
>>> text
>>>> out of RFC 4007 altogether?
>>>
>>> Basically works for me.
>
> <RCC>Me too</RCC>
>
>>>> OLD:
>>>>
>>>> o The boundaries of zones of a scope other than
>>> interface-local,
>>>> link-local, and global must be defined and configured by >>> network
>>>> administrators
>>>>
>>>> NEW:
>>>>
>>>> o The boundaries of zones of a scope are defined by the IP= v6
>>>> addressing architecture.
>>>
>>> With a reference (it's currently RFC 4291)?
>>>
>>> I'd also note that not all points described in the RFC 400= 7 text are
>>> described in RFC 4291 (at least not very clearly). So, not jus= t
>>> remove the text from RFC 4007, I'd like to unify it in the= address
>>> architecture, e.g. update the following part of RFC 4291:
>>>
>>> Admin-Local scope is the smallest scope that must be
>>> administratively configured, i.e., not automatically derived f= rom
>>> physical connectivity or other, non-multicast-related configur= ation.
>>>
>>> as follows:
>>>
>>> Admin-Local scope is the smallest scope that must be
>>> administratively configured, i.e., not automatically derived f= rom
>>> physical connectivity or other, non-multicast-related configur= ation.
>>> For all non-reserved scopes except the global scope, the zone<= br> >>> boundaries must also be administratively configured.
>>
>> I think this statement is self-contradictory. When automatic
>> configuration is discussed, it is in relation to zone boundaries.<= br> >> Here's an attempt to explain
>>
>> this without negations:
>>
>> Interface-Local, Link-Local, and Realm-Local scope boundaries are<= br> >> automatically
>>
>> derived from physical connectivity or other, non-multicast related=
>> configuration.
>>
>> Global scope has no boundary. The boundaries of all other
>> non-reserved scopes
>>
>> are administratively configured.
>
> <RCC>
> That makes it clear. IMO RFC4007 should be changed to something like:<= br> >
> o Each interface on a node comprises a single zone of interface-local<= br> > scope (for multicast only).
>
> o Each link and the interfaces attached to that link comprise a single=
> zone of link-local scope (for both unicast and multicast).
>
> o Multiple links and the interfaces attached to those links may form a=
> multilink-local scope based on underlying network technology; for
> example, [cite the IP-over-IEEE802.15.4 definition].
>
> o There is a single zone of global scope (for both unicast and
> multicast) comprising all the links and interfaces in the Internet. >
> o The boundaries of zones of a scope other than interface-local,
> link-local, multilink-local and global must be defined and configured<= br> > by network administrators.
>
> Either that or just remove the text as Ralph suggested earlier.
> </RCC>
>
>> BTW, just my opinion, but "Realm-Local" might be more me= aningfully
>> named
>>
>> "Multilink-Local"
>
> <RCC> I agree - it is more meaningful</RCC>
>
>> -K-
>>
>>> --
>>> JINMEI, Tatuya
>>>
>> ------------------------------------------------------------------= --
>>> IETF IPv6 working group mailing list ipv6@ietf.org Administrative
>>> Requests:
>>> https://www.ietf.org/mailman/listinfo/ipv6 [1]
>>>
>> ------------------------------------------------------------------= --
>>
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll [2]
>
>
>
> Links:
> ------
> [1] https://www.ietf.org/mailman/listinfo/ipv6
> [2] https://www.ietf.org/mailman/listinfo/roll
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
_______________________________________________
Roll mailing list
Roll@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/roll
_______________________________________________
Roll mailing list
Roll@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/roll
--047d7b6250bc96d08d04e993653f-- From trac+roll@trac.tools.ietf.org Fri Oct 25 12:36:10 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4BD11E8182 for ; Fri, 25 Oct 2013 12:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bv0M9W+bTyyi for ; Fri, 25 Oct 2013 12:36:08 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 7566D11E81B2 for ; Fri, 25 Oct 2013 12:36:07 -0700 (PDT) Received: from localhost ([127.0.0.1]:54544 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VZnAk-0001JU-Tx; Fri, 25 Oct 2013 21:35:50 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit 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: johui@cisco.com, mariainesrobles@gmail.com, rdroms@cisco.com, mcr@sandelman.ca X-Trac-Project: roll Date: Fri, 25 Oct 2013 19:35:50 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/132#comment:11 Message-ID: <082.edfe2409c64752e7b85834f8849899d2@trac.tools.ietf.org> References: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org> X-Trac-Ticket-ID: 132 In-Reply-To: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: johui@cisco.com, mariainesrobles@gmail.com, rdroms@cisco.com, mcr@sandelman.ca, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 19:36:11 -0000 #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local Comment (by mariainesrobles@gmail.com): Source: http://www.ietf.org/mail-archive/web/roll/current/msg08282.html From: Ralph Droms Date: Wed, 23 Oct 2013 09:05:36 -0400 > peter van der Stok wrote: > > Looking at the discussion there seem to be two issues: > -1 tunnelling MC messages through MPL domain > -2 Sending multicast to all members of a mesh >... > > This also works for a message leaving the MPL domain. > > Any mistakes in my reasoning? Putting this text in section 5.1, and removing the text in section 4.1 can help the progress of MPL draft. This idea is interesting. I don't know if the WG considered it. However, I'm not sure it's a simplification. There are two functions in a MPL forwarding node: forwarding multicast traffic on to other nodes in the MPL domain and delivering traffic to local applications. The former function requires that the node stack receive and forward all multicast traffic while the latter function uses the list of locally subscribed multicast addresses for local delivery. I suppose there's no difference between a node accepting all multicast traffic for forwarding rather than using ALL_MPL_FORWARDERS in the outer header, and then delivering only subscribed traffic based on the inner header. > > Ad 2) > ... > Identifying the MC address with the PAN-ID (given the PAN-ID does not change in spite of coordinator failures) of the mesh seems logical for IEEE802.15.4. If I've got it right, you support publication of a very short RFC that gives the definition of IEEE802.15.4 scope 3 as the list of all interfaces that share the same PAN ID. > > Sending a multicast to all members to a heterogeneous multi-link network looks like a different problem to me. Agreed. - Ralph ----------------------------------------------------------- Source: http://www.ietf.org/mail-archive/web/roll/current/msg08283.html From: Michael Richardson Date: Wed, 23 Oct 2013 14:19:38 -0400 > Ticket #132: > draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - > subnet-local I really don't understand the dispute, and it's gonna take some in-person discussion. Not clear to me that it's going to be an edit to this document. ---------------------------------------------------------------------------------------------------------- Source: http://www.ietf.org/mail-archive/web/roll/current/msg08284.html From: Ralph Droms Date: Wed, 23 Oct 2013 14:36:38 -0400 “... In my opinion, the problem is pretty clear: draft-ietf-roll-trickle-mcast-05 and draft-ietf-6man-multicast-scopes-00 are in conflict with each other. From draft-ietf-roll-trickle-mcast-05: When used with MPL, Realm-Local scope is administratively defined and used to define the boundaries of multicast message dissemination by MPL. From draft-ietf-6man-multicast-scopes-00: Realm-Local scope is the largest scope that is automatically configured, i.e., automatically derived from physical connectivity or other, non-multicast-related configuration. Specifically, "administratively defined" seems to me to be in direct conflict with "automatically configured". Part of the solution will require either a change in either draft-ietf- roll-trickle-mcast or draft-ietf-6man-multicast-scopes. I think we have WG support, if not consensus, to edit draft-ietf-roll-trickle-mcast-05: OLD: When used with MPL, Realm-Local scope is administratively defined and used to define the boundaries of multicast message dissemination by MPL. NEW: When used with MPL, Realm-Local scope is defined according to the underlying network technology; for example, [cite the IP-over-IEEE802.15.4 definition]. One additional bit of text is needed, but not necessarily in draft-ietf- roll-trickle-mcast, to define explicitly the meaning of scop 3 in an IEEE802.15.4 network (which is the definition to be cited in the NEW text above): When used in an IP-over-IEEE802.15.4 network, "scop 3" is defined to include all interfaces sharing a PAN ID. As a further refinement, I suggest text be added to draft-ietf-roll- trickle-mcast-05 to the effect of (this refinement has seen less WG discussion, in my opinion): "scop 4" can also be used with MPL to cover deployments that use administratively defined scopes that cover, for example, subnets based on different underlying network technologies. > Not clear to me that it's going to be an edit to this document.draft- ietf-roll-trickle-mcast-05 I'm pretty sure *something* has to be changed in draft-ietf-roll-trickle- mcast unless the definition of scop 3 is changed in draft-ietf-6man- multicast-scopes. - Ralph ” ------------------------------------------------------------------------------------------------------------------- Source: http://www.ietf.org/mail-archive/web/roll/current/msg08285.html From: Kerry Lynn Date: Wed, 23 Oct 2013 15:01:08 -0400 >... draft-ietf-roll-trickle-mcast-05 and draft-ietf-6man-multicast- scopes-00 > are in conflict with each other…. Note the above requirement (albeit with slightly different wording) comes from RFC 4291. > Specifically, "administratively defined" seems to me to be in direct > conflict with "automatically configured". +1 > OLD:... > NEW:... I agree with draft-ietf-6man-multicast-scopes that the proper place for this definition is in an IP-over-foo RFC. Specifically, any new 6lo drafts that desire to use an automatically configured scop 3 must define the link-layer technology specific attribute used to identify the scope zone. So I think the proper way to set the precedent is to issue a short RFC in 6lo (given that 6LoWPAN is shutting down) to update RFC 4944. Otherwise, future protocols that wish to make use of scop 3 will have to reference Ralph's RFC plus the MPL RFC. >As a further refinement, I suggest text be added to draft-ietf-roll- trickle-mcast-05 to the >effect of (this refinement has seen less WG discussion, in my opinion): > "scop 4" can also be used with MPL to cover deployments > that use administratively defined scopes that cover, for > example, subnets based on different underlying network > technologies. The place for this would be section 4.1, which currently says: An MPL Forwarder MAY participate in additional MPL Domains identified by other multicast addresses. An MPL Interface MUST subscribe to the MPL Domain Addresses for the MPL Domains that it participates in. The assignment of other multicast addresses is out of scope. >> Not clear to me that it's going to be an edit to this document.draft- ietf-roll-trickle-mcast-05 >I'm pretty sure *something* has to be changed in draft-ietf-roll-trickle- mcast unless the >definition of scop 3 is changed in draft-ietf-6man- multicast-scopes. And, by extension, in RFC 4291. -K- ------------------------------------------------------------------------------------------------------------------- Source: http://www.ietf.org/mail-archive/web/roll/current/msg08286.html From: Ralph Droms Date: Wed, 23 Oct 2013 15:56:46 -0400 >On Oct 21, 2013, at 3:00 PM 10/21/13, çæéå wrote: > At Thu, 17 Oct 2013 09:10:50 -0700, > Ralph Droms wrote: > >> Noting this conflict, I propose adding a bit of text to >> draft-ietf-6man-multicast-scopes to update RFC 4007 for consistency >> with RFC 4291: > > I think making these consistent is a good idea. > >> OLD: >> >> o The boundaries of zones of a scope other than interface-local, >> link-local, and global must be defined and configured by network >> administrators. >> >> NEW: >> >> o Admin-Local scope is the smallest scope that must be >> administratively configured, i.e., not automatically derived >> from physical connectivity or other, non-multicast-related >> configuration. > > I'm okay with the proposed text, but on a closer look I've noticed > a couple of subtle points you may want to consider: > > - I see a slight difference between the OLD (RFC 4007) and NEW (RFC > 4291) even after fixing the obvious inconsistency, in that the NEW > version does not necessarily say how the scopes larger than > admin-local scope is configured; technically it only states > interface-local and link-local (and "Realm-Local" if assigned) > would not be automatically configured. In fact, the global scope > shouldn't be "administratively" configured, which is crystal clear > from the OLD version, but not necessarily in the NEW version. > > - should we worry about possible future updates to the addressing > architecture and scope architecture documents? If we keep these > documents separately and have a copy of the text in both, we may need > to update both copies when we need to make a change on this point as > more "currently reserved" scopes are assigned. Both good points. As long as we have to make an update to RFC 4007, let's make sure the update is correct. > > These are probably too minor and maybe we can simply ignore the > subtlety. If that's our consensus I'm okay with that. But if we want > to address these points, maybe: > > OLD: > > o The boundaries of zones of a scope other than interface-local, > link-local, and global must be defined and configured by network > administrators. > > NEW: > > o The boundaries of zones of an interface-local, link-local, or > global scope automatically derived from physical connectivity. > For zones of other types of scopes, the IPv6 addressing > architecture specification defines how their boundaries must be > determined, whether automatically derived or administratively > configured. Perhaps we want to go a step farther and take the zone boundary text out of RFC 4007 altogether? OLD: o The boundaries of zones of a scope other than interface-local, link-local, and global must be defined and configured by network administrators NEW: o The boundaries of zones of a scope are defined by the IPv6 addressing architecture. - Ralph ------------------------------------------------------------------------------------------------------------------- Source: http://www.ietf.org/mail-archive/web/roll/current/msg08287.html From: Kerry Lynn Date: Wed, 23 Oct 2013 17:38:07 -0400 >On Wed, Oct 23, 2013 at 5:21 PM, ¿ 癆 明達哉 wrote: >At Wed, 23 Oct 2013 15:56:46 -0400, >Ralph Droms wrote: >> Perhaps we want to go a step farther and take the zone boundary text >> out of RFC 4007 altogether? >Basically works for me. >> OLD: >> >> o The boundaries of zones of a scope other than interface-local, >> link-local, and global must be defined and configured by network >> administrators >> >> NEW: >> >> o The boundaries of zones of a scope are defined by the IPv6 >> addressing architecture. >With a reference (it's currently RFC 4291)? >I'd also note that not all points described in the RFC 4007 text are >described in RFC 4291 (at least not very clearly). So, not just >remove the text from RFC 4007, I'd like to unify it in the address >architecture, e.g. update the following part of RFC 4291: > Admin-Local scope is the smallest scope that must be > administratively configured, i.e., not automatically derived > from physical connectivity or other, non-multicast-related > configuration. >as follows: > Admin-Local scope is the smallest scope that must be > administratively configured, i.e., not automatically derived > from physical connectivity or other, non-multicast-related > configuration. For all non-reserved scopes except the global > scope, the zone boundaries must also be administratively > configured. I think this statement is self-contradictory. When automatic configuration is discussed, it is in relation to zone boundaries. Here's an attempt to explain this without negations: Interface-Local, Link-Local, and Realm-Local scope boundaries are automatically derived from physical connectivity or other, non-multicast related configuration. Global scope has no boundary. The boundaries of all other non- reserved scopes are administratively configured. BTW, just my opinion, but "Realm-Local" might be more meaningfully named "Multilink-Local" -K- ------------------------------------------------------------------------------------------------------------------- Source: http://www.ietf.org/mail-archive/web/roll/current/msg08288.html From: Robert Cragie Date: Thu, 24 Oct 2013 07:59:05 +0100 >On 23 October 2013 22:38, Kerry Lynn wrote: >> Perhaps we want to go a step farther and take the zone boundary text >> out of RFC 4007 altogether? >Basically works for me. Me too >> OLD: >With a reference (it's currently RFC 4291)? > ... > Interface-Local, Link-Local, and Realm-Local scope boundaries are automatically > derived from physical connectivity or other, non-multicast related configuration. > Global scope has no boundary. The boundaries of all other non- reserved scopes > are administratively configured. That makes it clear. IMO RFC4007 should be changed to something like: o Each interface on a node comprises a single zone of interface-local scope (for multicast only). o Each link and the interfaces attached to that link comprise a single zone of link-local scope (for both unicast and multicast). o Multiple links and the interfaces attached to those links may form a multilink-local scope based on underlying network technology; for example, [cite the IP-over-IEEE802.15.4 definition]. o There is a single zone of global scope (for both unicast and multicast) comprising all the links and interfaces in the Internet. o The boundaries of zones of a scope other than interface-local, link- local, multilink-local and global must be defined and configured by network administrators. Either that or just remove the text as Ralph suggested earlier. >BTW, just my opinion, but "Realm-Local" might be more meaningfully named >"Multilink-Local" I agree - it is more meaningful ------------------------------------------------------------------------------------------------------------------- Source: http://www.ietf.org/mail-archive/web/roll/current/msg08289.html From: peter van der Stok Date: Fri, 25 Oct 2013 11:52:38 +0200 I like the consensus that seems to emerge. It should be clear that the realm-local specification concerns a homogeneous multi-link network For example: o Multiple links, following the same IP over Foo specification, and the interfaces attached to those links may form a multilink-local scope based on underlying network technology; for example, [cite the IP-over- IEEE802.15.4 definition]. Peter ------------------------------------------------------------------------------------------------------------------- Source: http://www.ietf.org/mail-archive/web/roll/current/msg08290.html From: "Popa, Daniel" Date: Fri, 25 Oct 2013 11:35:13 +0000 Hi Peter, By "homogeneous multi-link network" do you refer to "homogeneous link- layer technology" ? If this is the case, I suggest we do not correlate the scope of the multicast to the use of a specific link-layer technology... We should be able to deploy systems where all nodes in a multi-link network can be members of the same "multilink-local multicast scope", independently of the link-layer technology they use (homogeneous or heterogeneous) to communicate with each other. Regards, Daniel ------------------------------------------------------------------------------------------------------------------- Source: http://www.ietf.org/mail-archive/web/roll/current/msg08291.html From: Robert Cragie Date: Fri, 25 Oct 2013 17:39:40 +0100 Hi Daniel, I think the conclusion in that case was that scope 4 would have to be used as it would be difficult to imagine anything other than administrative configuration for a scope which spans multiple links on different link layer technologies. Robert -- ---------------------------------------+------------------------------ Reporter: mariainesrobles@gmail.com | Owner: johui@cisco.com Type: defect | Status: reopened Priority: major | Milestone: Component: trickle-mcast | Version: Severity: In WG Last Call | Resolution: Keywords: | ---------------------------------------+------------------------------ Ticket URL: roll From rdroms@cisco.com Fri Oct 25 12:56: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 15B6E11E81CF; Fri, 25 Oct 2013 12:56:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vM3MTXPOvVWj; Fri, 25 Oct 2013 12:56:46 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 3B01B11E81CB; Fri, 25 Oct 2013 12:56:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2095; q=dns/txt; s=iport; t=1382731003; x=1383940603; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=1LWoRS4K09YN3RZ7H0On+224HuK6MVj3iNgzQKwe+Hk=; b=BqUjDoZx4sOHb3825q6wt3CmmIsgrJjEzuOBm+c0Hm3siaY6vJtYPPSC +QsG+bDMC83+iNKlOQN5zUaRDkiBwmGrgP5UgAie516lLYyDds0Beab7g aJXyzRAfEGQq8YFhOPgl5Do8LpNm6kFrsEIf1QE3N0UK7ByVSWToDwoMM 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAGvMalKtJV2Z/2dsb2JhbABZgweBDL5IgSMWdIImAQEEOjQLEAIBCCIUBQsyJQIEDgUIh3+5VI4bgQUCMQeDH4ENA6oRgWiBPoIq X-IronPort-AV: E=Sophos;i="4.93,572,1378857600"; d="scan'208";a="273781249" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 25 Oct 2013 19:56:42 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9PJug6M029987 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Oct 2013 19:56:42 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.229]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.02.0318.004; Fri, 25 Oct 2013 14:56:42 -0500 From: "Ralph Droms (rdroms)" To: "ietf@ietf.org list" Thread-Topic: Last Call: (Multicast Protocol for Low power and Lossy Networks (MPL)) to Proposed Standard Thread-Index: AQHO0bxTB8hb4i6HYEmq/bFuLj8olw== Date: Fri, 25 Oct 2013 19:56:42 +0000 Message-ID: <4518F39EB578034D8C99A9B7776CDBA301C0651B@xmb-aln-x04.cisco.com> References: <20131010221713.891.32620.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.68.183] Content-Type: text/plain; charset="us-ascii" Content-ID: <7980C149C96C0545807856C9D47B5268@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "roll@ietf.org" Subject: Re: [Roll] Last Call: (Multicast Protocol for Low power and Lossy Networks (MPL)) to Proposed Standard X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 19:56:53 -0000 There was a long discussion about this issue on the roll@ietf.org mailing l= ist: draft-ietf-roll-trickle-mcast-05 and draft-ietf-6man-multicast-scopes-00 ar= e in conflict with each other. >From draft-ietf-roll-trickle-mcast-05: When used with MPL, Realm-Local scope is administratively defined and used to define the boundaries of multicast message dissemination by MPL. >From draft-ietf-6man-multicast-scopes-00: Realm-Local scope is the largest scope that is automatically configured, i.e., automatically derived from physical connectivity or other, non-multicast-related configuration. Specifically, "administratively defined" seems to me to be in direct conflict with "automatically configured".=20 I think I've read consensus in the various discussion threads to make the f= ollowing change to draft-ietf-roll-trickle-mcast-05: OLD: When used with MPL, Realm-Local scope is administratively defined and used to define the boundaries of multicast message dissemination by MPL. NEW: When used with MPL, Realm-Local scope is defined according to the underlying network technology; for example, [cite the IP-over-IEEE802.15.4 definition]. where "the IP-over-IEEE802.15.4 definition" is text to be published elsewhe= re (perhaps draft-ietf-6man-multicast-scopes) that defines scop 3 for IEEE8= 02.15.4 mesh networks. I read less strong consensus (less discussion) of the following proposed ch= anges: NEW (to be added immediately following text describing the use of Realm-Loc= al scope): Admin-Local scope (scop value 4) can also be used with MPL in deployments that use administratively defined scopes that cover, for example, multiple subnets based on different underlying network technologies. As a side note, there is a related discussion about draft-ietf-6man-multica= st-scopes on the 6man@ietf.org mailing list. The term "Realm-Local scope" = may change (should be changed for consistency with) the final published ver= sion of draft-ietf-6man-multicast-scopes. - Ralph From rdroms@cisco.com Fri Oct 25 13: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 BAC1211E8152; Fri, 25 Oct 2013 13:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KDSb-6Le18vk; Fri, 25 Oct 2013 13:21:16 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id BFD0811E8108; Fri, 25 Oct 2013 13:21:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3820; q=dns/txt; s=iport; t=1382732476; x=1383942076; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=p9lTnSrPdiv2prTRTCaSTLQh4sCVtV0d3koY4fuQ1wk=; b=L+XFUCMTg7x9/duAXO51IAzP0P35V9enMba/oCss574VltlSblDCjTw1 pkBlVvQLHF+JVe8xKnRWWWCOZ6u4+LeVyK2mJ0JHI+6mRpD9Lv2rp/I1F 3F9gwxyYuYm+X1ozt/w4An1qXWXSp01X7yjREzRNyCqLl96QvhwC34aCX c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtcGAL7RalKtJXHA/2dsb2JhbABZgweBDL5IgSMWbQeCJQEBAQMBeQULAgEIEgYKGQshERcOAgQOBQiHbQMJBq9XDYlrjGOCPQIxB4MfgQ0DiQeNGI47hTeBaIE+gio X-IronPort-AV: E=Sophos;i="4.93,572,1378857600"; d="scan'208";a="276801832" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-8.cisco.com with ESMTP; 25 Oct 2013 20:21:16 +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 r9PKLG7G011288 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Oct 2013 20:21:16 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.229]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Fri, 25 Oct 2013 15:21:16 -0500 From: "Ralph Droms (rdroms)" To: "6man@ietf.org" <6man@ietf.org> Thread-Topic: draft-ietf-6man-multicast-scopes updates RFC 4007 (Was Re: [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local) Thread-Index: AQHO0b/BbRYL5zf1Mk6G4zsqvD6ovQ== Date: Fri, 25 Oct 2013 20:21:15 +0000 Message-ID: <4518F39EB578034D8C99A9B7776CDBA301C067D0@xmb-aln-x04.cisco.com> References: <3599.1381852752@sandelman.ca> <525DC6C9.2010808@gridmerge.com> <525E5064.4050109@gridmerge.com> <3CC8783F-F4DA-47B9-A051-DBBA6EF00C19@gmail.com> In-Reply-To: <3CC8783F-F4DA-47B9-A051-DBBA6EF00C19@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.68.183] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Routing Over Low power and Lossy networks Subject: Re: [Roll] draft-ietf-6man-multicast-scopes updates RFC 4007 (Was Re: [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 20:21:22 -0000 I think I read consensus from the WG to make the following changes to draft= -ietf-6man-multicast-scopes, and list the document as "Updates RFC 4007": *** Add as a new last paragraph in section 2: The following change is applied to section 2.7 of RFC 4291: OLD: Admin-Local scope is the smallest scope that must be administratively configured, i.e., not automatically derived from physical connectivity or other, non-multicast-related configuration. NEW: Interface-Local, Link-Local, and Realm-Local scope boundaries are automatically derived from physical connectivity or other, non-multicast related configuration. Global scope has no boundary. The boundaries of all other non-reserved scopes are administratively configured. *** Add section 3 (and renumber current section 3-5): 3. Updates to RFC 4007, section 5 Section 5 of RFC 4007 and section 2.7 of RFC 4291 disagree about the way in which multicast scope 3 is configured. To resolve that disagreem= ent, change the last bullet in the list in section 5 of RFC 4007 as follows: OLD: o The boundaries of zones of a scope other than interface-local, link-local, and global must be defined and configured by network administrators. NEW: o The boundaries of zones of a scope are defined by the IPv6 addressing architecture [RFC4291]. I haven't seen any discussion of changing Realm-Local to Multilink-Local be= yond Kerry's initial suggestion and Robert's support of the change. - Ralph On Oct 17, 2013, at 12:10 PM 10/17/13, Ralph Droms = wrote: > Kerry correctly points out that RFC 4007 and RFC 4291 are in conflict reg= arding the way in which multicast scope 3 is defined: >=20 > RFC 4007, section 5: >=20 > o The boundaries of zones of a scope other than interface-local, > link-local, and global must be defined and configured by network > administrators. >=20 > RFC 4291, section 2.7: >=20 > Admin-Local scope is the smallest scope that must be > administratively configured, i.e., not automatically derived > from physical connectivity or other, non-multicast-related > configuration. >=20 > Noting this conflict, I propose adding a bit of text to draft-ietf-6man-m= ulticast-scopes to update RFC 4007 for consistency with RFC 4291: >=20 > Add section 3 (and renumber current section 3-5): >=20 > 3. Updates to RFC 4007, section 5 >=20 > Section 5 of RFC 4007 and section 2.7 of RFC 4291 disagree about the > way in which multicast scope 3 is configured. To resolve that disagree= ment, > change the last bullet in the list in section 5 of RFC 4007 as follows: >=20 > OLD: >=20 > o The boundaries of zones of a scope other than interface-local, > link-local, and global must be defined and configured by network > administrators. >=20 > NEW: >=20 > o Admin-Local scope is the smallest scope that must be > administratively configured, i.e., not automatically derived > from physical connectivity or other, non-multicast-related > configuration. >=20 > Looking for consensus in the 6man WG before I make this change... >=20 > - Ralph >=20 > On Oct 16, 2013, at 10:04 AM 10/16/13, Kerry Lynn wrote= : >=20 >> [...] >=20 >> I think Ralph's approach is the correct one. His draft-droms-6man-multi= cast-scopes belongs in >> 6man as it re-defines a reserved code point in the IPv6 addressing archi= tecture. It nominally >> updates RFC 4291 but should probably also update RFC 4007 as these RFCs = are in conflict >> regarding the automatic definition of scope 0x03. > [...] >=20 From rdroms@cisco.com Fri Oct 25 13:45: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 ABB5421F9FDE; Fri, 25 Oct 2013 13:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZoytbKGi1DUx; Fri, 25 Oct 2013 13:45:08 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id A2FA421F9FCE; Fri, 25 Oct 2013 13:45:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5644; q=dns/txt; s=iport; t=1382733901; x=1383943501; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=zjq9XTarseY+9VlRGbeadkTKF8VNflkxJ4pZFOL9rTE=; b=NH4OAqi8h3UeqiCi68CosLfJE6kAITrKGuFzTmP9OO9ds+FQ5p8iIzO4 dxIiW9aFhitlJz7v00Mjgt0au2s+ssKdCKgLtZzQWlVHAXYRFKDHCL+r4 x+gN13hpfRO5aU2cIrN2W/PJCIYemgl5NCWEohziBcxIxzJbgn2c+4Q/j E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAG3XalKtJXG//2dsb2JhbABZgwc4VL5IgSMWdIIlAQEBBAEBATc0CwwEAgEIDgMBAwEBAQoUBQQHIQYLFAMGCAIEDgUIh20DDw2vRg2JZwSMY4E4gQUCMQcGgxmBDQOWH447hTeBaIE+gio X-IronPort-AV: E=Sophos;i="4.93,573,1378857600"; d="scan'208";a="276817098" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-8.cisco.com with ESMTP; 25 Oct 2013 20:44:59 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r9PKiweM020371 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Oct 2013 20:44:58 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.229]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Fri, 25 Oct 2013 15:44:58 -0500 From: "Ralph Droms (rdroms)" To: Dave Thaler Thread-Topic: draft-ietf-6man-multicast-scopes updates RFC 4007 (Was Re: [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local) Thread-Index: AQHO0cMRVKgL102kqEWw4KBFp4Nd5w== Date: Fri, 25 Oct 2013 20:44:57 +0000 Message-ID: <4518F39EB578034D8C99A9B7776CDBA301C06DD6@xmb-aln-x04.cisco.com> References: <3599.1381852752@sandelman.ca> <525DC6C9.2010808@gridmerge.com> <525E5064.4050109@gridmerge.com> <3CC8783F-F4DA-47B9-A051-DBBA6EF00C19@gmail.com> <4518F39EB578034D8C99A9B7776CDBA301C067D0@xmb-aln-x04.cisco.com> <1daea916972b4e60be575e5f5276cb78@BY2PR03MB269.namprd03.prod.outlook.com> In-Reply-To: <1daea916972b4e60be575e5f5276cb78@BY2PR03MB269.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.68.183] Content-Type: text/plain; charset="us-ascii" Content-ID: <88FC4D114D123C489DF2DA6FDB96D533@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Routing Over Low power and Lossy networks , "6man@ietf.org" <6man@ietf.org> Subject: Re: [Roll] draft-ietf-6man-multicast-scopes updates RFC 4007 (Was Re: [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 20:45:16 -0000 On Oct 25, 2013, at 4:38 PM 10/25/13, Dave Thaler w= rote: >> -----Original Message----- >> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of >> Ralph Droms (rdroms) >> Sent: Friday, October 25, 2013 1:21 PM >> To: 6man@ietf.org >> Cc: Routing Over Low power and Lossy networks >> Subject: Re: draft-ietf-6man-multicast-scopes updates RFC 4007 (Was Re: >> [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope val= ue of 3 - >> subnet-local) >>=20 >> I think I read consensus from the WG to make the following changes to dr= aft- >> ietf-6man-multicast-scopes, and list the document as "Updates RFC 4007": >>=20 >> *** Add as a new last paragraph in section 2: >>=20 >> The following change is applied to section 2.7 of RFC 4291: >>=20 >> OLD: >>=20 >> Admin-Local scope is the smallest scope that must be >> administratively configured, i.e., not automatically derived >> from physical connectivity or other, non-multicast-related >> configuration. >>=20 >> NEW: >>=20 >> Interface-Local, Link-Local, and Realm-Local scope boundaries >> are automatically derived from physical connectivity or >> other, non-multicast related configuration. Global scope has >> no boundary. The boundaries of all other non-reserved scopes >> are administratively configured. >=20 > I disagree with the last sentence above. Specifically > "non-reserved" should be removed. That is, we should not start > precluding admin configuration of reserved scopes, given we didn't > before. They just didn't have defined names or uses, but they could > have been used within private environments. Good catch. So the last sentence should read: The boundaries of all other scopes are administratively configured. ? - Ralph >=20 > -Dave >=20 >>=20 >> *** Add section 3 (and renumber current section 3-5): >>=20 >> 3. Updates to RFC 4007, section 5 >>=20 >> Section 5 of RFC 4007 and section 2.7 of RFC 4291 disagree about the >> way in which multicast scope 3 is configured. To resolve that disagre= ement, >> change the last bullet in the list in section 5 of RFC 4007 as follows= : >>=20 >> OLD: >>=20 >> o The boundaries of zones of a scope other than interface-local, >> link-local, and global must be defined and configured by network >> administrators. >>=20 >> NEW: >>=20 >> o The boundaries of zones of a scope are defined by the IPv6 >> addressing architecture [RFC4291]. >>=20 >> I haven't seen any discussion of changing Realm-Local to Multilink-Local >> beyond Kerry's initial suggestion and Robert's support of the change. >>=20 >> - Ralph >>=20 >> On Oct 17, 2013, at 12:10 PM 10/17/13, Ralph Droms >> wrote: >>=20 >>> Kerry correctly points out that RFC 4007 and RFC 4291 are in conflict >> regarding the way in which multicast scope 3 is defined: >>>=20 >>> RFC 4007, section 5: >>>=20 >>> o The boundaries of zones of a scope other than interface-local, >>> link-local, and global must be defined and configured by network >>> administrators. >>>=20 >>> RFC 4291, section 2.7: >>>=20 >>> Admin-Local scope is the smallest scope that must be >>> administratively configured, i.e., not automatically derived >>> from physical connectivity or other, non-multicast-related >>> configuration. >>>=20 >>> Noting this conflict, I propose adding a bit of text to draft-ietf-6man= - >> multicast-scopes to update RFC 4007 for consistency with RFC 4291: >>>=20 >>> Add section 3 (and renumber current section 3-5): >>>=20 >>> 3. Updates to RFC 4007, section 5 >>>=20 >>> Section 5 of RFC 4007 and section 2.7 of RFC 4291 disagree about the >>> way in which multicast scope 3 is configured. To resolve that >> disagreement, >>> change the last bullet in the list in section 5 of RFC 4007 as follows= : >>>=20 >>> OLD: >>>=20 >>> o The boundaries of zones of a scope other than interface-local, >>> link-local, and global must be defined and configured by network >>> administrators. >>>=20 >>> NEW: >>>=20 >>> o Admin-Local scope is the smallest scope that must be >>> administratively configured, i.e., not automatically derived >>> from physical connectivity or other, non-multicast-related >>> configuration. >>>=20 >>> Looking for consensus in the 6man WG before I make this change... >>>=20 >>> - Ralph >>>=20 >>> On Oct 16, 2013, at 10:04 AM 10/16/13, Kerry Lynn >> wrote: >>>=20 >>>> [...] >>>=20 >>>> I think Ralph's approach is the correct one. His >>>> draft-droms-6man-multicast-scopes belongs in 6man as it re-defines a >>>> reserved code point in the IPv6 addressing architecture. It >>>> nominally updates RFC 4291 but should probably also update RFC 4007 as >> these RFCs are in conflict regarding the automatic definition of scope 0= x03. >>> [...] >>>=20 >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From kerlyn2001@gmail.com Fri Oct 25 14:07:10 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF33E11E8204; Fri, 25 Oct 2013 14:07:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvKDiEXXEITI; Fri, 25 Oct 2013 14:07:07 -0700 (PDT) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id A2F0411E8210; Fri, 25 Oct 2013 14:06:48 -0700 (PDT) Received: by mail-ob0-f180.google.com with SMTP id wo20so1484079obc.39 for ; Fri, 25 Oct 2013 14:06:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=jUaQLYWxXb9weVRFehkbFYex7Vl477zHI4SEu0fJO4U=; b=u9Qh3lxJ4q/gP9cCyN8Cku/cEG9D7c27FfTopfW/IRQA+QHYENhNHv8sId7peSUytV PszFyar4bfSZRrRW7hcpaHxKLgNmmbnSiuiGACsvbVQyzHotMhI4UDpLK04+Jwpb2/TN e66WLj0kFsQG/glyVPSmf62OU9JZYWxdRLUClpdvQ6g+KIpXEECOjnyOQFZBDtMsjYib z+8abSdIQ9n+PtX7SBHGt2xWwHSXrOq9ENK0racM/chk1Ylvb/4Bku5vC3Nf6KHzEf6c 7BmEWTLDT+4X6CASln70+kZ7CTULTHcm2CevN1IiGUyuw6giEl26Yl/OHyoVx0KjuPy7 xbLg== MIME-Version: 1.0 X-Received: by 10.182.220.225 with SMTP id pz1mr4575581obc.51.1382735186522; Fri, 25 Oct 2013 14:06:26 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.60.73.6 with HTTP; Fri, 25 Oct 2013 14:06:26 -0700 (PDT) In-Reply-To: <4518F39EB578034D8C99A9B7776CDBA301C06DD6@xmb-aln-x04.cisco.com> References: <3599.1381852752@sandelman.ca> <525DC6C9.2010808@gridmerge.com> <525E5064.4050109@gridmerge.com> <3CC8783F-F4DA-47B9-A051-DBBA6EF00C19@gmail.com> <4518F39EB578034D8C99A9B7776CDBA301C067D0@xmb-aln-x04.cisco.com> <1daea916972b4e60be575e5f5276cb78@BY2PR03MB269.namprd03.prod.outlook.com> <4518F39EB578034D8C99A9B7776CDBA301C06DD6@xmb-aln-x04.cisco.com> Date: Fri, 25 Oct 2013 17:06:26 -0400 X-Google-Sender-Auth: 8K5Ip9gJrJZ90a3kkgdfpJQpo5Y Message-ID: From: Kerry Lynn To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary=001a11c30fac9c789604e9971fee Cc: "6man@ietf.org" <6man@ietf.org>, Dave Thaler Subject: Re: [Roll] draft-ietf-6man-multicast-scopes updates RFC 4007 (Was Re: [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 21:07:10 -0000 --001a11c30fac9c789604e9971fee Content-Type: text/plain; charset=ISO-8859-1 On Fri, Oct 25, 2013 at 4:44 PM, Ralph Droms (rdroms) wrote: > > On Oct 25, 2013, at 4:38 PM 10/25/13, Dave Thaler > wrote: > > >> -----Original Message----- > >> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > >> Ralph Droms (rdroms) > >> Sent: Friday, October 25, 2013 1:21 PM > >> To: 6man@ietf.org > >> Cc: Routing Over Low power and Lossy networks > >> Subject: Re: draft-ietf-6man-multicast-scopes updates RFC 4007 (Was Re: > >> [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope > value of 3 - > >> subnet-local) > >> > >> I think I read consensus from the WG to make the following changes to > draft- > >> ietf-6man-multicast-scopes, and list the document as "Updates RFC 4007": > >> > >> *** Add as a new last paragraph in section 2: > >> > >> The following change is applied to section 2.7 of RFC 4291: > >> > >> OLD: > >> > >> Admin-Local scope is the smallest scope that must be > >> administratively configured, i.e., not automatically derived > >> from physical connectivity or other, non-multicast-related > >> configuration. > >> > >> NEW: > >> > >> Interface-Local, Link-Local, and Realm-Local scope boundaries > >> are automatically derived from physical connectivity or > >> other, non-multicast related configuration. Global scope has > >> no boundary. The boundaries of all other non-reserved scopes > >> are administratively configured. > > > > I disagree with the last sentence above. Specifically > > "non-reserved" should be removed. That is, we should not start > > precluding admin configuration of reserved scopes, given we didn't > > before. They just didn't have defined names or uses, but they could > > have been used within private environments. > > Logically, the last sentence above doesn't entail how the boundaries of reserved scopes are configured (the inference is that they may be administratively or automatically configured). > Good catch. So the last sentence should read: > > The boundaries of all other scopes are administratively configured. > > ? > > This makes it clear that the boundary of 11 of the 15 scopes defined in RFC 4291 sect 2.7 (including 0) are administratively configured. So it is not equivalent in meaning to the old text if that was the intention. -K- - Ralph > > > > > > -Dave > > > >> > >> *** Add section 3 (and renumber current section 3-5): > >> > >> 3. Updates to RFC 4007, section 5 > >> > >> Section 5 of RFC 4007 and section 2.7 of RFC 4291 disagree about the > >> way in which multicast scope 3 is configured. To resolve that > disagreement, > >> change the last bullet in the list in section 5 of RFC 4007 as > follows: > >> > >> OLD: > >> > >> o The boundaries of zones of a scope other than interface-local, > >> link-local, and global must be defined and configured by network > >> administrators. > >> > >> NEW: > >> > >> o The boundaries of zones of a scope are defined by the IPv6 > >> addressing architecture [RFC4291]. > >> > >> I haven't seen any discussion of changing Realm-Local to Multilink-Local > >> beyond Kerry's initial suggestion and Robert's support of the change. > >> > >> - Ralph > >> > >> On Oct 17, 2013, at 12:10 PM 10/17/13, Ralph Droms > >> wrote: > >> > >>> Kerry correctly points out that RFC 4007 and RFC 4291 are in conflict > >> regarding the way in which multicast scope 3 is defined: > >>> > >>> RFC 4007, section 5: > >>> > >>> o The boundaries of zones of a scope other than interface-local, > >>> link-local, and global must be defined and configured by network > >>> administrators. > >>> > >>> RFC 4291, section 2.7: > >>> > >>> Admin-Local scope is the smallest scope that must be > >>> administratively configured, i.e., not automatically derived > >>> from physical connectivity or other, non-multicast-related > >>> configuration. > >>> > >>> Noting this conflict, I propose adding a bit of text to > draft-ietf-6man- > >> multicast-scopes to update RFC 4007 for consistency with RFC 4291: > >>> > >>> Add section 3 (and renumber current section 3-5): > >>> > >>> 3. Updates to RFC 4007, section 5 > >>> > >>> Section 5 of RFC 4007 and section 2.7 of RFC 4291 disagree about the > >>> way in which multicast scope 3 is configured. To resolve that > >> disagreement, > >>> change the last bullet in the list in section 5 of RFC 4007 as > follows: > >>> > >>> OLD: > >>> > >>> o The boundaries of zones of a scope other than interface-local, > >>> link-local, and global must be defined and configured by network > >>> administrators. > >>> > >>> NEW: > >>> > >>> o Admin-Local scope is the smallest scope that must be > >>> administratively configured, i.e., not automatically derived > >>> from physical connectivity or other, non-multicast-related > >>> configuration. > >>> > >>> Looking for consensus in the 6man WG before I make this change... > >>> > >>> - Ralph > >>> > >>> On Oct 16, 2013, at 10:04 AM 10/16/13, Kerry Lynn > >> wrote: > >>> > >>>> [...] > >>> > >>>> I think Ralph's approach is the correct one. His > >>>> draft-droms-6man-multicast-scopes belongs in 6man as it re-defines a > >>>> reserved code point in the IPv6 addressing architecture. It > >>>> nominally updates RFC 4291 but should probably also update RFC 4007 as > >> these RFCs are in conflict regarding the automatic definition of scope > 0x03. > >>> [...] > >>> > >> > >> -------------------------------------------------------------------- > >> IETF IPv6 working group mailing list > >> ipv6@ietf.org > >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >> -------------------------------------------------------------------- > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --001a11c30fac9c789604e9971fee Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Oct 25, 2013 at 4:44 PM, Ralph Droms (rdroms) <rdr= oms@cisco.com> wrote:

On Oct 25, 2013, at 4:38 PM 10/25/13, Dave Thaler <dthaler@microsoft.com> wrote:

>> -----Original Message-----
>> From: ipv6-bounces@ietf.o= rg [mailto:ipv6-bounces@ietf.o= rg] On Behalf Of
>> Ralph Droms (rdroms)
>> Sent: Friday, October 25, 2013 1:21 PM
>> To: 6man@ietf.org
>> Cc: Routing Over Low power and Lossy networks
>> Subject: Re: draft-ietf-6man-multicast-scopes updates RFC 4007 (Wa= s Re:
>> [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify sco= pe value of 3 -
>> subnet-local)
>>
>> I think I read consensus from the WG to ma= ke the following changes to draft-
>> ietf-6man-multicast-scopes, and list the document as "Updates= RFC 4007":
>>
>> *** Add as a new last paragraph in section 2:
>>
>> =A0 The following change is applied to section 2.7 of RFC 4291: >>
>> =A0 OLD:
>>
>> =A0 =A0 =A0 =A0 Admin-Local scope is the smallest scope that must = be
>> =A0 =A0 =A0 =A0 administratively configured, i.e., not automatical= ly derived
>> =A0 =A0 =A0 =A0 from physical connectivity or other, non-multicast= -related
>> =A0 =A0 =A0 =A0 configuration.
>>
>> =A0 NEW:
>>
>> =A0 =A0 =A0 =A0 Interface-Local, Link-Local, and Realm-Local scope= boundaries
>> =A0 =A0 =A0 =A0 are automatically derived from physical connectivi= ty or
>> =A0 =A0 =A0 =A0 other, non-multicast related configuration. =A0Glo= bal scope has
>> =A0 =A0 =A0 =A0 no boundary. =A0The boundaries of all other non-re= served scopes
>> =A0 =A0 =A0 =A0 are administratively configured.
>
> I disagree with the last sentence above. =A0Specifically
> "non-reserved" should be removed. =A0That is, we should not = start
> precluding admin configuration of reserved scopes, given we didn't=
> before. =A0They just didn't have defined names or uses, but they c= ould
> have been used within private environments.

Logically, the last sentence above doesn't e= ntail how the boundaries
of reserved scopes are configured (the inferenc= e is that they may be
administratively or automatically confi= gured).
=A0
Good catch. =A0So the last sentence should read:

=A0 The boundaries of all other scopes are administratively configured.

?

This makes it clear that the boundary of 11 of the 15 scop= es defined in
RFC 4291 sect 2.7 (including 0) are administratively confi= gured.=A0 So it
is not equivalent in me= aning to the old text if that was the intention.

-K-

- Ralph


>
> -Dave
>
>>
>> *** Add section 3 (and renumber current section 3-5):
>>
>> 3. =A0Updates to RFC 4007, section 5
>>
>> =A0 Section 5 of RFC 4007 and section 2.7 of RFC 4291 disagree abo= ut the
>> =A0 way in which multicast scope 3 is configured. =A0To resolve th= at disagreement,
>> =A0 change the last bullet in the list in section 5 of RFC 4007 as= follows:
>>
>> OLD:
>>
>> =A0 o =A0The boundaries of zones of a scope other than interface-l= ocal,
>> =A0 =A0 =A0link-local, and global must be defined and configured b= y network
>> =A0 =A0 =A0administrators.
>>
>> NEW:
>>
>> =A0 o =A0The boundaries of zones of a scope are defined by the IPv= 6
>> =A0 =A0 =A0addressing architecture [RFC4291].
>>
>> I haven't seen any discussion of changing Realm-Local to Multi= link-Local
>> beyond Kerry's initial suggestion and Robert's support of = the change.
>>
>> - Ralph
>>
>> On Oct 17, 2013, at 12:10 PM 10/17/13, Ralph Droms
>> <rdroms.ietf@gmail.com= > wrote:
>>
>>> Kerry correctly points out that RFC 4007 and RFC 4291 are in c= onflict
>> regarding the way in which multicast scope 3 is defined:
>>>
>>> RFC 4007, section 5:
>>>
>>> =A0o =A0The boundaries of zones of a scope other than interfac= e-local,
>>> =A0 =A0 link-local, and global must be defined and configured = by network
>>> =A0 =A0 administrators.
>>>
>>> RFC 4291, section 2.7:
>>>
>>> =A0 =A0 =A0 =A0Admin-Local scope is the smallest scope that mu= st be
>>> =A0 =A0 =A0 =A0administratively configured, i.e., not automati= cally derived
>>> =A0 =A0 =A0 =A0from physical connectivity or other, non-multic= ast-related
>>> =A0 =A0 =A0 =A0configuration.
>>>
>>> Noting this conflict, I propose adding a bit of text to draft-= ietf-6man-
>> multicast-scopes to update RFC 4007 for consistency with RFC 4291:=
>>>
>>> Add section 3 (and renumber current section 3-5):
>>>
>>> 3. =A0Updates to RFC 4007, section 5
>>>
>>> =A0Section 5 of RFC 4007 and section 2.7 of RFC 4291 disagree = about the
>>> =A0way in which multicast scope 3 is configured. =A0To resolve= that
>> disagreement,
>>> =A0change the last bullet in the list in section 5 of RFC 4007= as follows:
>>>
>>> OLD:
>>>
>>> =A0o =A0The boundaries of zones of a scope other than interfac= e-local,
>>> =A0 =A0 link-local, and global must be defined and configured = by network
>>> =A0 =A0 administrators.
>>>
>>> NEW:
>>>
>>> =A0o =A0Admin-Local scope is the smallest scope that must be >>> =A0 =A0 administratively configured, i.e., not automatically d= erived
>>> =A0 =A0 from physical connectivity or other, non-multicast-rel= ated
>>> =A0 =A0 configuration.
>>>
>>> Looking for consensus in the 6man WG before I make this change= ...
>>>
>>> - Ralph
>>>
>>> On Oct 16, 2013, at 10:04 AM 10/16/13, Kerry Lynn <kerlyn@ieee.org>
>> wrote:
>>>
>>>> [...]
>>>
>>>> I think Ralph's approach is the correct one. =A0His >>>> draft-droms-6man-multicast-scopes belongs in 6man as it re= -defines a
>>>> reserved code point in the IPv6 addressing architecture. = =A0It
>>>> nominally updates RFC 4291 but should probably also update= RFC 4007 as
>> these RFCs are in conflict regarding the automatic definition of s= cope 0x03.
>>> [...]
>>>
>>
>> ------------------------------------= --------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<= /a>
>> ------------------------------------------------------------= --------
> ----------------------------------------------------= ----------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<= br>
> ----------------------------------------------------------------= ----

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

--001a11c30fac9c789604e9971fee-- From pal@cs.stanford.edu Mon Oct 28 22:51: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 EDF8F11E8127 for ; Mon, 28 Oct 2013 22:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b3egPsedY-vT for ; Mon, 28 Oct 2013 22:51:39 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by ietfa.amsl.com (Postfix) with ESMTP id 6B8FD11E810D for ; Mon, 28 Oct 2013 22:51:37 -0700 (PDT) Received: from [76.14.66.110] (helo=[192.168.0.100]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1Vb2DH-0002aY-Sa; Mon, 28 Oct 2013 22:51:36 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Philip Levis In-Reply-To: Date: Mon, 28 Oct 2013 22:51:35 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <62C3DC8A-E36F-42B1-963F-E5A73CDC06EA@cs.stanford.edu> References: To: Routing Over Low power and Lossy networks X-Mailer: Apple Mail (2.1510) X-Scan-Signature: 104fcb84af92cc131bf6e023e43ddbb4 Subject: Re: [Roll] Question on MPL: parameter update on runnning MPL forwarders X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 05:51:44 -0000 RFC6206 goes into some of the implications of mismatched parameters. It = kind of assumes the values are not *tremendously* different, with the = general conclusion is that there will be uneven load but it will = generally continue to work alright, especially in the presence of = inconsistencies. It only really breaks down when consistency criteria = differ. Phil ------- Philip Levis Associate Professor Computer Science and Electrical Engineering Stanford University http://csl.stanford.edu/~pal On Oct 4, 2013, at 8:14 AM, Don Sturek wrote: > Hi Yusuke, >=20 > I think it would depend on how different the settings are between the = old > imin, imax, k, etc. >=20 > Imagine a change where the values of the old imin, imax, k, etc. and = the > new ones were such that the new imax is now less than the old imin. = If > you mix that in with the unmanaged delivery of the new values I think = you > would find that the forwarding of transmissions at that time = (including > the update of the new MPL parameters themselves) would not guarantee > delivery to all nodes. >=20 > I do think if you were to change the imin, imax, k values in a "small" = way > then there might be little to no impact on forwarding (where "small" I > guess would be a bit hard to quantify} >=20 > The safest solution is to use the old values to distribute the new = values > and then validate all nodes have the value (synchronization) and then = have > the new values take effect. >=20 > Don >=20 >=20 > On 10/4/13 8:07 AM, "DOI Yusuke" wrote: >=20 >> Hi Don, >>=20 >> I thought some unbalanced transmission could happen and acceptable, >> but other issues may occur as you and Peter say. >>=20 >> I think it's better to find some workaround for now. >>=20 >> Thank you very much! >>=20 >> Yusuke >>=20 >> From: Don Sturek >> Subject: Re: [Roll] Question on MPL: parameter update on runnning MPL >> forwarders >> Date: Fri, 04 Oct 2013 06:45:13 -0700 >>=20 >>> Hi Yusuke, >>>=20 >>> >>>=20 >>> I don't believe it is possible to change imin, imax, k or any other >>> operational MPL forwarder parameter without some sort of >>> pre-distribution/synchronization of the new parameters. It would = work >>> as >>> you note if there are no transmission or valid seed set but if = multicast >>> traffic is already present using an existing seed, I would expect = you >>> would see issues in distribution of messages if you change the >>> parameters >>> while in operation. Additionally, if you use MPL to distribute the >>> change with existing multicast traffic you will find some nodes do = not >>> get >>> the new parameters (which will create other problems when you want = the >>> new >>> parameters to take effect) >>>=20 >>> Don >>>=20 >>>=20 >>>=20 >>> On 10/4/13 1:07 AM, "Yusuke DOI" wrote: >>>=20 >>>> Hi, >>>>=20 >>>> I have a simple question: is it possible to update MPL parameters = of >>>> running forwarder instances? >>>>=20 >>>> To maintain the system in 'good state', I expect some sort of = parameter >>>> tuning on MPL. Especially for the systems dynamically grows, static >>>> configuration of MPL parameters will be difficult. For example, = DHCPv6 >>>> reconfigure request can be used to update MPL forwarder parameter. >>>> However, I'm not sure it's 'safe' to update parameters (K, Imin, = Imax) >>>> of >>>> running MPL forwarder instances. >>>>=20 >>>> I think it's safe if there are no transmission / no valid seed set. = Is >>>> it >>>> possible to update a running MPL forwarder parameter without = breaking >>>> current state?=20 >>>>=20 >>>> Regards, >>>>=20 >>>> Yusuke >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Roll mailing list >>>> Roll@ietf.org >>>> https://www.ietf.org/mailman/listinfo/roll >>>=20 >>>=20 >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>=20 >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From trac+roll@trac.tools.ietf.org Tue Oct 29 05:52:39 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4076611E815F for ; Tue, 29 Oct 2013 05:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZPyp9Q9222iM for ; Tue, 29 Oct 2013 05:52:38 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id A867611E80E3 for ; Tue, 29 Oct 2013 05:52:36 -0700 (PDT) Received: from localhost ([127.0.0.1]:40492 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Vb8me-0004CC-Bk; Tue, 29 Oct 2013 13:52:32 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: johui@cisco.com, mariainesrobles@gmail.com, rdroms@cisco.com, mcr@sandelman.ca X-Trac-Project: roll Date: Tue, 29 Oct 2013 12:52:32 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/132#comment:12 Message-ID: <082.319af2b73178bd832c18ace7fb50373f@trac.tools.ietf.org> References: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org> X-Trac-Ticket-ID: 132 In-Reply-To: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: johui@cisco.com, mariainesrobles@gmail.com, rdroms@cisco.com, mcr@sandelman.ca, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local 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: Tue, 29 Oct 2013 12:52:39 -0000 #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local Comment (by mariainesrobles@gmail.com): ------------------------------------------------------------------------------------------------------------------- Source: http://www.ietf.org/mail-archive/web/roll/current/msg08296.html From: "Ralph Droms (rdroms)" Date: Fri, 25 Oct 2013 19:56:42 +0000 There was a long discussion about this issue on the roll at ietf.org mailing list: draft-ietf-roll-trickle-mcast-05 and draft-ietf-6man-multicast-scopes-00 are in conflict with each other. From draft-ietf-roll-trickle-mcast-05: When used with MPL, Realm-Local scope is administratively defined and used to define the boundaries of multicast message dissemination by MPL. From draft-ietf-6man-multicast-scopes-00: Realm-Local scope is the largest scope that is automatically configured, i.e., automatically derived from physical connectivity or other, non-multicast-related configuration. Specifically, "administratively defined" seems to me to be in direct conflict with "automatically configured". I think I've read consensus in the various discussion threads to make the following change to draft-ietf-roll-trickle-mcast-05: OLD: When used with MPL, Realm-Local scope is administratively defined and used to define the boundaries of multicast message dissemination by MPL. NEW: When used with MPL, Realm-Local scope is defined according to the underlying network technology; for example, [cite the IP-over-IEEE802.15.4 definition]. where "the IP-over-IEEE802.15.4 definition" is text to be published elsewhere (perhaps draft-ietf-6man-multicast-scopes) that defines scop 3 for IEEE802.15.4 mesh networks. I read less strong consensus (less discussion) of the following proposed changes: NEW (to be added immediately following text describing the use of Realm- Local scope): Admin-Local scope (scop value 4) can also be used with MPL in deployments that use administratively defined scopes that cover, for example, multiple subnets based on different underlying network technologies. As a side note, there is a related discussion about draft-ietf-6man- multicast-scopes on the 6man at ietf.org mailing list. The term "Realm- Local scope" may change (should be changed for consistency with) the final published version of draft-ietf-6man-multicast-scopes. - Ralph ------------------------------------------------------------------------------------------------------------------- Source: http://www.ietf.org/mail-archive/web/roll/current/msg08294.html From: "Ralph Droms (rdroms)" Date: Fri, 25 Oct 2013 20:21:15 +0000 I think I read consensus from the WG to make the following changes to draft-ietf-6man-multicast-scopes, and list the document as "Updates RFC 4007": *** Add as a new last paragraph in section 2: The following change is applied to section 2.7 of RFC 4291: OLD: Admin-Local scope is the smallest scope that must be administratively configured, i.e., not automatically derived from physical connectivity or other, non-multicast-related configuration. NEW: Interface-Local, Link-Local, and Realm-Local scope boundaries are automatically derived from physical connectivity or other, non-multicast related configuration. Global scope has no boundary. The boundaries of all other non-reserved scopes are administratively configured. *** Add section 3 (and renumber current section 3-5): 3. Updates to RFC 4007, section 5 Section 5 of RFC 4007 and section 2.7 of RFC 4291 disagree about the way in which multicast scope 3 is configured. To resolve that disagreement, change the last bullet in the list in section 5 of RFC 4007 as follows: OLD: o The boundaries of zones of a scope other than interface-local, link-local, and global must be defined and configured by network administrators. NEW: o The boundaries of zones of a scope are defined by the IPv6 addressing architecture [RFC4291]. I haven't seen any discussion of changing Realm-Local to Multilink-Local beyond Kerry's initial suggestion and Robert's support of the change. - Ralph ------------------------------------------------------------------------------------------------------------------- Source: http://www.ietf.org/mail-archive/web/roll/current/msg08295.html From: "Ralph Droms (rdroms)" Date: Fri, 25 Oct 2013 20:44:57 +0000 On Oct 25, 2013, at 4:38 PM 10/25/13, Dave Thaler wrote: >> -----Original Message----- >> From: ipv6-bounces at ietf.org [mailto:ipv6-bounces at ietf.org] On Behalf Of >> Ralph Droms (rdroms) >> Sent: Friday, October 25, 2013 1:21 PM >> To: 6man at ietf.org >> Cc: Routing Over Low power and Lossy networks >> Subject: Re: draft-ietf-6man-multicast-scopes updates RFC 4007 (Was Re: >> [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - >> subnet-local) >> >> I think I read consensus from the WG to make the following changes to draft- >> ietf-6man-multicast-scopes, and list the document as "Updates RFC 4007": >> >> *** Add as a new last paragraph in section 2: >> >> The following change is applied to section 2.7 of RFC 4291: >> >> OLD: >> >> Admin-Local scope is the smallest scope that must be >> administratively configured, i.e., not automatically derived >> from physical connectivity or other, non-multicast-related >> configuration. >> >> NEW: >> >> Interface-Local, Link-Local, and Realm-Local scope boundaries >> are automatically derived from physical connectivity or >> other, non-multicast related configuration. Global scope has >> no boundary. The boundaries of all other non-reserved scopes >> are administratively configured. > > I disagree with the last sentence above. Specifically > "non-reserved" should be removed. That is, we should not start > precluding admin configuration of reserved scopes, given we didn't > before. They just didn't have defined names or uses, but they could > have been used within private environments. Good catch. So the last sentence should read: The boundaries of all other scopes are administratively configured. ? - Ralph ------------------------------------------------------------------------------------------------------------------- Source: http://www.ietf.org/mail-archive/web/roll/current/msg08296.html From: Kerry Lynn Date: Fri, 25 Oct 2013 17:06:26 -0400 >On Fri, Oct 25, 2013 at 4:44 PM, Ralph Droms (rdroms) wrote: >>On Oct 25, 2013, at 4:38 PM 10/25/13, Dave Thaler wrote: >> >... >> I disagree with the last sentence above. Specifically >> "non-reserved" should be removed. That is, we should not start >> precluding admin configuration of reserved scopes, given we didn't >> before. They just didn't have defined names or uses, but they could >> have been used within private environments. Logically, the last sentence above doesn't entail how the boundaries of reserved scopes are configured (the inference is that they may be administratively or automatically configured). >Good catch. So the last sentence should read: > The boundaries of all other scopes are administratively configured. >? This makes it clear that the boundary of 11 of the 15 scopes defined in RFC 4291 sect 2.7 (including 0) are administratively configured. So it is not equivalent in meaning to the old text if that was the intention. -K- -- ---------------------------------------+------------------------------ Reporter: mariainesrobles@gmail.com | Owner: johui@cisco.com Type: defect | Status: reopened Priority: major | Milestone: Component: trickle-mcast | Version: Severity: In WG Last Call | Resolution: Keywords: | ---------------------------------------+------------------------------ Ticket URL: roll From geoff.ietf@mulligan.com Wed Oct 30 09:24: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 388B021E8109 for ; Wed, 30 Oct 2013 09:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SS0iyICh8JVu for ; Wed, 30 Oct 2013 09:24:38 -0700 (PDT) Received: from mail.coslabs.com (mail.coslabs.com [199.233.92.34]) by ietfa.amsl.com (Postfix) with ESMTP id A4AC121E80B6 for ; Wed, 30 Oct 2013 09:24:26 -0700 (PDT) Received: from [192.168.43.8] (11.sub-70-192-217.myvzw.com [70.192.217.11]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.coslabs.com (Postfix) with ESMTPSA id CC7E75F8E7 for ; Wed, 30 Oct 2013 10:24:24 -0600 (MDT) Message-ID: <527132B4.9020508@mulligan.com> Date: Wed, 30 Oct 2013 10:24:20 -0600 From: Geoff Mulligan User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: roll@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Roll] Smart America meeting - Monday Nov 4 at IETF88 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 16:24:43 -0000 Hopefully you might have seen elsewhere (but probably from me), Sokwoo and I have launched our PIF project called Smart America (www.smartamerica.org). We are trying to get a wide visibility to knowledgeable folks to gather ideas and available technologies that might fit into the program and project. We are insistent that it be based on open standard protocols and thus the IETF. So the meeting is currently planned for Monday November 4 from 7:30pm US/Pacific (0300 UTC - I think) until 9:00pm US/Pacific (0500 UTC - I hope). Again - please reply to me directly if you plan to attend so that we can size the room accordingly. Thanks, Geoff