From nobody Tue Sep 1 23:27:03 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 324851B3509; Tue, 1 Sep 2015 23:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SwToD-hROuxR; Tue, 1 Sep 2015 23:27:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 119D41B491E; Tue, 1 Sep 2015 23:26:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150902062646.26920.90250.idtracker@ietfa.amsl.com> Date: Tue, 01 Sep 2015 23:26:46 -0700 Archived-At: Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-mpl-parameter-configuration-07.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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 Sep 2015 06:27:02 -0000 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 : MPL Parameter Configuration Option for DHCPv6 Authors : Yusuke Doi Matthew Gillmore Filename : draft-ietf-roll-mpl-parameter-configuration-07.txt Pages : 12 Date : 2015-09-01 Abstract: This document defines a way to configure a parameter set for MPL (Multicast Protocol for Low power and Lossy Networks) via a DHCPv6 option. MPL has a set of parameters to control its behavior, and the parameter set is often configured as a network-wide parameter because the parameter set should be identical for each MPL forwarder in an MPL domain. Using the MPL Parameter Configuration Option defined in this document, a network can easily be configured with a single set of MPL parameters. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-mpl-parameter-configuration/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-roll-mpl-parameter-configuration-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-mpl-parameter-configuration-07 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 nobody Tue Sep 1 23:49:26 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF5E71AD079; Tue, 1 Sep 2015 23:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.197 X-Spam-Level: X-Spam-Status: No, score=0.197 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8aR1FrDsw08; Tue, 1 Sep 2015 23:49:19 -0700 (PDT) Received: from imx2.toshiba.co.jp (imx2.toshiba.co.jp [106.186.93.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB1161B34EA; Tue, 1 Sep 2015 23:49:12 -0700 (PDT) Received: from tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp ([133.199.200.50]) by imx2.toshiba.co.jp with ESMTP id t826nAUW022195 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Sep 2015 15:49:10 +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 t826nA3t018902; Wed, 2 Sep 2015 15:49:10 +0900 Received: from localhost ([127.0.0.1]) by tsbmgw-mgw02 (JAMES SMTP Server 2.3.1) with SMTP ID 419; Wed, 2 Sep 2015 15:49:10 +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 t826nAId018894; Wed, 2 Sep 2015 15:49:10 +0900 Received: (from root@localhost) by arc1.toshiba.co.jp id t826n93v009564; Wed, 2 Sep 2015 15:49:09 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id RAA09544; Wed, 2 Sep 2015 15:49:09 +0900 Received: from mx12.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id t826n7BC023712; Wed, 2 Sep 2015 15:49:08 +0900 (JST) Received: from spiffy20.isl.rdc.toshiba.co.jp by toshiba.co.jp id t826moGt028168; Wed, 2 Sep 2015 15:48:50 +0900 (JST) Received: from [133.199.145.164] (ivpn-5-164.mobile.toshiba.co.jp [133.199.145.164]) by spiffy20.isl.rdc.toshiba.co.jp (Postfix) with ESMTPSA id 1013518F4A6; Wed, 2 Sep 2015 15:48:48 +0900 (JST) Message-ID: <55E69B47.8070102@toshiba.co.jp> Date: Wed, 02 Sep 2015 15:46:31 +0900 From: Yusuke DOI User-Agent: Mozilla/5.0 (Windows NT 6.2; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Routing Over Low power and Lossy networks , The IESG References: <20150708195730.18658.96701.idtracker@ietfa.amsl.com> In-Reply-To: <20150708195730.18658.96701.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: roll-chairs@ietf.org, draft-ietf-roll-mpl-parameter-configuration@ietf.org, draft-ietf-roll-mpl-parameter-configuration.shepherd@ietf.org, maria.ines.robles@ericsson.com, draft-ietf-roll-mpl-parameter-configuration.ad@ietf.org Subject: Re: [Roll] Alia Atlas' Discuss on draft-ietf-roll-mpl-parameter-configuration-06: (with DISCUSS and COMMENT) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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, 02 Sep 2015 06:49:22 -0000 Dear Alia, I finally updated the draft. I think the update can resolve your discussion point. Sorry for belated update. > First, a minor point on the "Reserved" bits. In Sec 2.1, it says "Z (7 > bits): Reserved. Should be 0." and then in Sec 2.2: > " Clients MUST discard the MPL Parameter Configuration Option if it is > invalid (e.g., it sets reserved bits)." (snip) Thanks for the comment. I clarified definition of the reserved bit as you suggested. > Second, given that the meaning of the *_IMAX values is based on RFC6206 > (as indicated in the update history) and that the *_IMAX and *_IMIN are > confusing values, PLEASE have a reference to RFC6206. I added the reference to RFC6206 and cited definition from the RFC /w examples. I hope it resolves your discussion point. Thanks again for your kind review. Yusuke On 2015-07-09 4:57, Alia Atlas wrote: > Alia Atlas has entered the following ballot position for > draft-ietf-roll-mpl-parameter-configuration-06: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-roll-mpl-parameter-configuration/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > In general, this draft is well-written and easy to understand. I do have > a few points of technical clarity that I think are important. > > First, a minor point on the "Reserved" bits. In Sec 2.1, it says "Z (7 > bits): Reserved. Should be 0." and then in Sec 2.2: > " Clients MUST discard the MPL Parameter Configuration Option if it is > invalid (e.g., it sets reserved bits)." Frequently, > Reserved bits are available for future enhancements - so setting to zero > on write and ignoring the value on read is a useful > default. If these bits are really always going to be zero and > interpreted as an error, then could you rename them to MBZ (Must Be Zero) > and indicate in the field definition that a value other than zero is an > error. Also, from what I read in the rest of the draft, > if an invalid option is received, that could cause the client to be > removed from the MPL region. Could you clarify in the document what the > expected behavior is if an invalid option is discarded? Is that like > having no option? Is that pretending that the client didn't get one and > staying with the previous option? It seems like it would be pretty easy > to remove a client from the MPL region by flipping a bit. I would also > like to see better clarification of how an option is considered invalid; > while it may seem obvious, it's these details that impact > interoperability. In the write-up, I don't see any indications that > there have been interoperable implementations yet? > > Second, given that the meaning of the *_IMAX values is based on RFC6206 > (as indicated in the update history) and that the *_IMAX and *_IMIN are > confusing values, PLEASE have a reference to RFC6206. To continue, it > seems that DATA_MESSAGE_IMIN and DATA_MESSAGE_IMAX have different units - > as is explained in RFC6206 where *_IMAX is the number of doublings and > *_IMIN is the value in milliseconds. However, in > draft-ietf-roll-trickle-mcast-12, Section 5.4, the definition of > DATA_MESSAGE_IMIN and DATA_MESSAGE_IMAX and C_IMIN and C_IMAX are given > as: > > " DATA_MESSAGE_IMIN The minimum Trickle timer interval, as defined in > [RFC6206], for MPL Data Message transmissions. DATA_MESSAGE_IMIN > has a default value of 10 times the expected link-layer latency. > > DATA MESSAGE_IMAX The maximum Trickle timer interval, as defined in > [RFC6206], for MPL Data Message transmissions. DATA_MESSAGE_IMAX > has a default value equal to DATA_MESSAGE_IMIN. > > CONTROL_MESSAGE_IMIN The minimum Trickle timer interval, as defined > in [RFC6206], for MPL Control Message transmissions. > CONTROL_MESSAGE_IMIN has a default value of 10 times the worst- > case link-layer latency. > > CONTROL_MESSAGE_IMAX The maximum Trickle timer interval, as defined > in [RFC6206], for MPL Control Message transmissions. > CONTROL_MESSAGE_IMAX has a default value of 5 minutes. > " > > Clearly, if DATA_MESSAGE_IMIN is a 16 bit value and DATA_MESSAGE_IMAX is > only an 8-bit value, they are expected to have different ranges. > Additionally, it's quite unclear which actually needs to be divided by > TUNIT. The draft describes this as happening for DM_IMIN and C_IMIN, but > then goes on to say > " Note that all time values (Trickle timers and expiration periods) > are > in TUNIT milliseconds precision. For example, if TUNIT is 20 and the > data message interval minimum (DATA_MESSAGE_IMIN) is 1000ms, then > DM_IMIN shall be set to 50." > > Unfortunately, the draft doesn't describe which parameters are time > values and apparently draft-ietf-roll-trickle-mcast-12 > has some confusion as well. For instance, CONTROL_MESSAGE_IMAX is > defined as a time value (5 minutes). > > I suspect that the solution here is to clarify/fix > draft-ietf-roll-trickle-mcast-12, add references in Sec 2 to where the > parameters > are defined, indicate which are considered "time values", and clean up > the language in Sec 2.1. > > Thanks! It looks like a useful document to address an operational > problem once these clarity issues are addressed. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > In Sec 2.1, it says: "OPTION_MPL_PARAMETERS: DHCPv6 option identifier > (not yet assigned)" > Instead of "not yet assigned", it would be better to use TBD1 and then > reference TBD1 in the IANA section. > That makes it easy and clear how to update the draft as it is prepared to > be an RFC. > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From nobody Wed Sep 2 00:36:09 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E0121B49F0; Wed, 2 Sep 2015 00:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bj4Zl3VRfItp; Wed, 2 Sep 2015 00:36:03 -0700 (PDT) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D80721B49D0; Wed, 2 Sep 2015 00:36:02 -0700 (PDT) Received: from tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp ([133.199.232.103]) by imx12.toshiba.co.jp with ESMTP id t827a0vi006106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Sep 2015 16:36:00 +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 t827a0wV023549; Wed, 2 Sep 2015 16:36:00 +0900 Received: from localhost ([127.0.0.1]) by tsbmgw-mgw01 (JAMES SMTP Server 2.3.1) with SMTP ID 975; Wed, 2 Sep 2015 16:36:00 +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 t827a0eh023528; Wed, 2 Sep 2015 16:36:00 +0900 Received: (from root@localhost) by arc11.toshiba.co.jp id t827a0Jb012570; Wed, 2 Sep 2015 16:36:00 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id SAA12560; Wed, 2 Sep 2015 16:35:59 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id t827ZxRJ015525; Wed, 2 Sep 2015 16:35:59 +0900 (JST) Received: from spiffy20.isl.rdc.toshiba.co.jp by toshiba.co.jp id t827ZwOl025608; Wed, 2 Sep 2015 16:35:58 +0900 (JST) Received: from [133.199.17.96] (ivpn-2-96.mobile.toshiba.co.jp [133.199.17.96]) by spiffy20.isl.rdc.toshiba.co.jp (Postfix) with ESMTPSA id 77E4718F4A6; Wed, 2 Sep 2015 16:35:57 +0900 (JST) Message-ID: <55E69F07.5000901@toshiba.co.jp> Date: Wed, 02 Sep 2015 16:02:31 +0900 From: Yusuke DOI User-Agent: Mozilla/5.0 (Windows NT 6.2; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Barry Leiba References: <20150707181803.6403.35920.idtracker@ietfa.amsl.com> <559DB480.7080507@toshiba.co.jp> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "roll-chairs@ietf.org" , "draft-ietf-roll-mpl-parameter-configuration@ietf.org" , Routing Over Low power and Lossy networks , "draft-ietf-roll-mpl-parameter-configuration.ad@ietf.org" , The IESG , "draft-ietf-roll-mpl-parameter-configuration.shepherd@ietf.org" , "maria.ines.robles@ericsson.com" Subject: Re: [Roll] Barry Leiba's Discuss on draft-ietf-roll-mpl-parameter-configuration-06: (with DISCUSS and COMMENT) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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, 02 Sep 2015 07:36:05 -0000 Dear Barry, I updated the document with the discussions. Sorry for late update. (I missed some nit so I'll update -08 soon) On 2015-07-09 11:18, Barry Leiba wrote: > > That does correct the apparent contradiction, but it doesn't answer > one question I had, which seems to leave things uncertain: Where the > text says, "A node SHOULD leave an MPL domain if it receives an > updated MPL Parameter Configuration Option without a configuration for > the MPL domain, unless it has overriding manual configuration on the > MPL domain," it's important to note that this still means that if you > *don't* have an overriding manual configuration on the domain, you > still SHOULD (not MUST) leave the domain. That still means that you > could choose not to leave the domain. Is that OK? > > In other words: > > 1. You receive an updated MPL PCO without a config for the MPL domain. > > 1a. You *do* have an overriding manual configuration on the domain. > What are your choices? I think you mean to say that your choices are > to stay on the domain or to leave it, at your option. In this case, the node should remain. I think the case is clear. > 1b. You *don't* have an overriding manual configuration on the domain. > What are your choices? I don't know whether you mean to say that you > MUST leave the domain in this case, or whether there might be other > reasons you might choose to stay, and the SHOULD is appropriate. My first thought was SHOULD is strong enough. I understand 'MUST leave' is clearer. Thanks for kind comments, Yusuke From nobody Wed Sep 2 00:36:26 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC541B4B78; Wed, 2 Sep 2015 00:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.702 X-Spam-Level: X-Spam-Status: No, score=-1.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hWs6kOj5jBqV; Wed, 2 Sep 2015 00:36:17 -0700 (PDT) Received: from imx2.toshiba.co.jp (imx2.toshiba.co.jp [106.186.93.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBA231B4AAC; Wed, 2 Sep 2015 00:36:16 -0700 (PDT) Received: from tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp ([133.199.200.50]) by imx2.toshiba.co.jp with ESMTP id t827aFYC014949 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Sep 2015 16:36:15 +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 t827aFm6028231; Wed, 2 Sep 2015 16:36:15 +0900 Received: from localhost ([127.0.0.1]) by tsbmgw-mgw02 (JAMES SMTP Server 2.3.1) with SMTP ID 792; Wed, 2 Sep 2015 16:36:14 +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 t827aEQJ028219; Wed, 2 Sep 2015 16:36:14 +0900 Received: (from root@localhost) by arc1.toshiba.co.jp id t827aEFU028121; Wed, 2 Sep 2015 16:36:14 +0900 (JST) Received: from ovp2.toshiba.co.jp [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id SAA28116; Wed, 2 Sep 2015 16:36:14 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id t827aExc019268; Wed, 2 Sep 2015 16:36:14 +0900 (JST) Received: from spiffy20.isl.rdc.toshiba.co.jp by toshiba.co.jp id t827aDPX026082; Wed, 2 Sep 2015 16:36:13 +0900 (JST) Received: from [133.199.17.96] (ivpn-2-96.mobile.toshiba.co.jp [133.199.17.96]) by spiffy20.isl.rdc.toshiba.co.jp (Postfix) with ESMTPSA id 9973B18F4A6; Wed, 2 Sep 2015 16:36:12 +0900 (JST) Message-ID: <55E6A5FE.2050309@toshiba.co.jp> Date: Wed, 02 Sep 2015 16:32:14 +0900 From: Yusuke DOI User-Agent: Mozilla/5.0 (Windows NT 6.2; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Routing Over Low power and Lossy networks , The IESG References: <20150708141537.17660.50617.idtracker@ietfa.amsl.com> In-Reply-To: <20150708141537.17660.50617.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: roll-chairs@ietf.org, draft-ietf-roll-mpl-parameter-configuration@ietf.org, draft-ietf-roll-mpl-parameter-configuration.shepherd@ietf.org, maria.ines.robles@ericsson.com, draft-ietf-roll-mpl-parameter-configuration.ad@ietf.org Subject: Re: [Roll] Brian Haberman's Discuss on draft-ietf-roll-mpl-parameter-configuration-06: (with DISCUSS and COMMENT) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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, 02 Sep 2015 07:36:18 -0000 Hi Brian, Thank you very much for your kind review. I updated the document. Sorry for late response. On 2015-07-08 23:15, Brian Haberman wrote: > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Some of these points come from Bernie Volz's INT-Dir review... > > 1. This is one of the few options that is not a singleton, as defined in > section 16 of RFC 7227. While the use of multiple options seems > appropriate here, it would be best to clarify that clients (section 2.2) > and servers (section 2.4) must be able to support multiple instances of > this option. Given the discussion around supporting multiple MPL domains > in draft-ietf-roll-trickle-mcast, I would expect there to be situations > where the option appears multiple times. > > 2. In section 2.3 (MPL Forwarder Behavior), there should be a brief > discussion of the role of the MPL Domain Address and include a reference > to [I-D.ietf-roll-trickle-mcast]. Thank you for suggestion. I added some notes on multiple options and reference. > 3. In section 2.6 (Operational Considerations), the text is a bit odd. > Why should a parameter set not be updated more often than twice the > Information Refresh Time? How does the failure to refresh the option play > with text in section 2.3 that indicates a missing option means the node > should leave the MPL domain? Perhaps defining what "failure to refresh" > means (i.e., I think it refers to lack of a DHCPv6 server response to a > Renew or Information Request). Note also that Information Refresh Time is > only applicable to Information-Request messages (see RFC 4242) so work > may be needed as to how this this sections relate to Renew/Rebind > operations? I am also not sure why 2.6 is a standalone section when it > appears to be only applicable to clients and should be in either section > 2.2 or 2.3. I modified text with reference to RFC6206, with clarification on 'failure' If a DHCPv6 client with an MPL forwarder configured by the MPL Parameter Configuration Option is unable to receive a valid response from a server within T2 of the las\ t valid DHCPv6 message sent from the server (if stateful) or twice the Information Refresh Time (if stateless), it MUST suspend the MPL forwarders of the MPL domains \ configured by the option. MPL forwarders configured by other methods such as static configuration file MUST NOT be suspended. Clients MUST ignore all MPL Parameter Configuration Options if the options in a DHCPv6 message contains any invalid value (e.g., it uses reserved all-0 or all-1 value\ s in parameters). In this case, the message is considered not received in MPL context and the condition described in the previous paragraph applies. > 1. I support Barry's DISCUSS on the lack of an option potentially forcing > a node to leave an MPL domain. I hope answer to Barry's DISCUSS can make this resolved. > 2. Why is the text in Appendix B not in the Operational Considerations > section? No reason to have separate section so I merged it on local copy (will be submitted as -08). Thanks for suggestion. > 3. Please be consistent with the use of MUSTs and SHALLs. Pick one. Agreed and fixed. > 4. In section 2.2 (DHCPv6 Client Behavior), 2nd paragraph - why would a > client discard the option if the reserved bits are set? I would think > you'd want to use a new option if you're changing things drastically? But > it certainly is your choice as to whether you want to do that. Perhaps a > better reason is if one of the not-permitted values is used (such as 0 > and 'all-bits-set') where are clearly reserved? 0 in many of these case > could be bad since that would yield 0 time values? This really is up to > you, but do think about what you might want to do any maintain backwards > compatibility. Adding a new flag bit to the reserved field is probably > not going to break things if existing implementations ignore the bit(s). Thanks. As I stated on Alia's DISCUSS, I changed the definitions of reserved bits as you suggested. Best Regards, Yusuke From nobody Wed Sep 2 01:23:09 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B3681B3EE5; Tue, 1 Sep 2015 23:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TjqckYFL2o_t; Tue, 1 Sep 2015 23:27:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 31DC61B4939; Tue, 1 Sep 2015 23:26:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , , , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150902062646.26920.92887.idtracker@ietfa.amsl.com> Date: Tue, 01 Sep 2015 23:26:46 -0700 Archived-At: X-Mailman-Approved-At: Wed, 02 Sep 2015 01:23:08 -0700 Subject: [Roll] New Version Notification - draft-ietf-roll-mpl-parameter-configuration-07.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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 Sep 2015 06:27:03 -0000 A new version (-07) has been submitted for draft-ietf-roll-mpl-parameter-configuration: https://www.ietf.org/internet-drafts/draft-ietf-roll-mpl-parameter-configuration-07.txt Sub state has been changed to AD Followup from Revised ID Needed The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-mpl-parameter-configuration/ Diff from previous version: https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-mpl-parameter-configuration-07 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. IETF Secretariat. From nobody Wed Sep 9 05:27:54 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BF9C1A904A; Wed, 9 Sep 2015 05:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BMC0BwgBnQ92; Wed, 9 Sep 2015 05:27:50 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5A4E1A9058; Wed, 9 Sep 2015 05:27:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6870; q=dns/txt; s=iport; t=1441801664; x=1443011264; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=LQw05vFDDMdCrUoaEpKnr7Uoq1acRLs6q0vICXu94eA=; b=BIDSr5f64+ILg1gTNa8dknDruw5Xnp97+M77flji6TH2163kt9tHNoG4 5MF55PWAEfpvIHWw5NUiN9ef7xjwiBEMgw6ugnFkZwKizsGW/Ra1dXSWW Wq5tGlq7Ys0YcLJSB65tWL0Gw7St9CiATn/ZNSjxLH+Qax6yXNP6gg7tS 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ADAgD3JPBV/4kNJK1dgyNUaQa9HgEJgW0MhXcCgTc4FAEBAQEBAQGBCoQjAQEBAwEBAQE3NAsQAgEIGB4FCycLJQIEAQ0FG4gLCA3KEgEBAQEBAQEBAQEBAQEBAQEBAQEBARMEhnMBg3WBBYQpEQFRAgWELAWHMYptgzgBhQmHcIFMhDODH3SIMYRJg2wmgkKBPnEBhwk6gQUBAQE X-IronPort-AV: E=Sophos;i="5.17,496,1437436800"; d="scan'208";a="186442445" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-8.cisco.com with ESMTP; 09 Sep 2015 12:27:42 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t89CRgKg011879 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 9 Sep 2015 12:27:42 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 9 Sep 2015 07:27:41 -0500 Received: from xhc-rcd-x03.cisco.com (173.37.183.77) by xch-aln-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Wed, 9 Sep 2015 07:27:41 -0500 Received: from xmb-aln-x15.cisco.com ([169.254.9.140]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0248.002; Wed, 9 Sep 2015 07:27:41 -0500 From: "Alvaro Retana (aretana)" To: Yusuke DOI , Alia Atlas Thread-Topic: [Roll] Alia Atlas' Discuss on draft-ietf-roll-mpl-parameter-configuration-06: (with DISCUSS and COMMENT) Thread-Index: AQHQubhVExP7PSQ+FEaLhHT/au8Qjg== Date: Wed, 9 Sep 2015 12:27:40 +0000 Message-ID: References: <20150708195730.18658.96701.idtracker@ietfa.amsl.com> <55E69B47.8070102@toshiba.co.jp> In-Reply-To: <55E69B47.8070102@toshiba.co.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.36.7.20] Content-Type: text/plain; charset="us-ascii" Content-ID: <8661A389A19DB74DAE5179E0AA8A149C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "roll-chairs@ietf.org" , "draft-ietf-roll-mpl-parameter-configuration@ietf.org" , Routing Over Low power and Lossy networks , "maria.ines.robles@ericsson.com" , The IESG , "draft-ietf-roll-mpl-parameter-configuration.shepherd@ietf.org" , "draft-ietf-roll-mpl-parameter-configuration.ad@ietf.org" Subject: Re: [Roll] Alia Atlas' Discuss on draft-ietf-roll-mpl-parameter-configuration-06: (with DISCUSS and COMMENT) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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, 09 Sep 2015 12:27:52 -0000 [Explicitly adding Alia.] On 9/2/15, 2:46 AM, "iesg on behalf of Yusuke DOI" wrote: >Dear Alia, > >I finally updated the draft. I think the update can resolve your >discussion point. Sorry for belated update. > > > First, a minor point on the "Reserved" bits. In Sec 2.1, it says "Z (7 > > bits): Reserved. Should be 0." and then in Sec 2.2: > > " Clients MUST discard the MPL Parameter Configuration Option if it >is > > invalid (e.g., it sets reserved bits)." >(snip) > >Thanks for the comment. I clarified definition of the reserved bit as >you suggested. > > > > Second, given that the meaning of the *_IMAX values is based on RFC6206 > > (as indicated in the update history) and that the *_IMAX and *_IMIN are > > confusing values, PLEASE have a reference to RFC6206. > >I added the reference to RFC6206 and cited definition from the RFC /w >examples. > >I hope it resolves your discussion point. Thanks again for your kind >review. > >Yusuke > > >On 2015-07-09 4:57, Alia Atlas wrote: >> Alia Atlas has entered the following ballot position for >> draft-ietf-roll-mpl-parameter-configuration-06: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to=20 >>https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >>=20 >>https://datatracker.ietf.org/doc/draft-ietf-roll-mpl-parameter-configurat >>ion/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> In general, this draft is well-written and easy to understand. I do >>have >> a few points of technical clarity that I think are important. >> >> First, a minor point on the "Reserved" bits. In Sec 2.1, it says "Z (7 >> bits): Reserved. Should be 0." and then in Sec 2.2: >> " Clients MUST discard the MPL Parameter Configuration Option if it is >> invalid (e.g., it sets reserved bits)." Frequently, >> Reserved bits are available for future enhancements - so setting to zero >> on write and ignoring the value on read is a useful >> default. If these bits are really always going to be zero and >> interpreted as an error, then could you rename them to MBZ (Must Be >>Zero) >> and indicate in the field definition that a value other than zero is an >> error. Also, from what I read in the rest of the draft, >> if an invalid option is received, that could cause the client to be >> removed from the MPL region. Could you clarify in the document what the >> expected behavior is if an invalid option is discarded? Is that like >> having no option? Is that pretending that the client didn't get one and >> staying with the previous option? It seems like it would be pretty easy >> to remove a client from the MPL region by flipping a bit. I would also >> like to see better clarification of how an option is considered invalid; >> while it may seem obvious, it's these details that impact >> interoperability. In the write-up, I don't see any indications that >> there have been interoperable implementations yet? >> >> Second, given that the meaning of the *_IMAX values is based on RFC6206 >> (as indicated in the update history) and that the *_IMAX and *_IMIN are >> confusing values, PLEASE have a reference to RFC6206. To continue, it >> seems that DATA_MESSAGE_IMIN and DATA_MESSAGE_IMAX have different units >>- >> as is explained in RFC6206 where *_IMAX is the number of doublings and >> *_IMIN is the value in milliseconds. However, in >> draft-ietf-roll-trickle-mcast-12, Section 5.4, the definition of >> DATA_MESSAGE_IMIN and DATA_MESSAGE_IMAX and C_IMIN and C_IMAX are given >> as: >> >> " DATA_MESSAGE_IMIN The minimum Trickle timer interval, as defined in >> [RFC6206], for MPL Data Message transmissions. DATA_MESSAGE_IMIN >> has a default value of 10 times the expected link-layer latency. >> >> DATA MESSAGE_IMAX The maximum Trickle timer interval, as defined in >> [RFC6206], for MPL Data Message transmissions. DATA_MESSAGE_IMAX >> has a default value equal to DATA_MESSAGE_IMIN. >> >> CONTROL_MESSAGE_IMIN The minimum Trickle timer interval, as defined >> in [RFC6206], for MPL Control Message transmissions. >> CONTROL_MESSAGE_IMIN has a default value of 10 times the worst- >> case link-layer latency. >> >> CONTROL_MESSAGE_IMAX The maximum Trickle timer interval, as defined >> in [RFC6206], for MPL Control Message transmissions. >> CONTROL_MESSAGE_IMAX has a default value of 5 minutes. >> " >> >> Clearly, if DATA_MESSAGE_IMIN is a 16 bit value and DATA_MESSAGE_IMAX is >> only an 8-bit value, they are expected to have different ranges. >> Additionally, it's quite unclear which actually needs to be divided by >> TUNIT. The draft describes this as happening for DM_IMIN and C_IMIN, >>but >> then goes on to say >> " Note that all time values (Trickle timers and expiration periods) >> are >> in TUNIT milliseconds precision. For example, if TUNIT is 20 and >>the >> data message interval minimum (DATA_MESSAGE_IMIN) is 1000ms, then >> DM_IMIN shall be set to 50." >> >> Unfortunately, the draft doesn't describe which parameters are time >> values and apparently draft-ietf-roll-trickle-mcast-12 >> has some confusion as well. For instance, CONTROL_MESSAGE_IMAX is >> defined as a time value (5 minutes). >> >> I suspect that the solution here is to clarify/fix >> draft-ietf-roll-trickle-mcast-12, add references in Sec 2 to where the >> parameters >> are defined, indicate which are considered "time values", and clean up >> the language in Sec 2.1. >> >> Thanks! It looks like a useful document to address an operational >> problem once these clarity issues are addressed. >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> In Sec 2.1, it says: "OPTION_MPL_PARAMETERS: DHCPv6 option identifier >> (not yet assigned)" >> Instead of "not yet assigned", it would be better to use TBD1 and then >> reference TBD1 in the IANA section. >> That makes it easy and clear how to update the draft as it is prepared >>to >> be an RFC. >> >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> > > From nobody Wed Sep 9 05:31:03 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 911511B2A2A; Wed, 9 Sep 2015 05:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uSf0BZ6Q4-oo; Wed, 9 Sep 2015 05:30:58 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97ACB1B2AD6; Wed, 9 Sep 2015 05:30:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4442; q=dns/txt; s=iport; t=1441801857; x=1443011457; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=wS10l6shYC0MSU+XBa9J6ag8BXdaATheEgNOZ8sZAhE=; b=dx8oJeFrQx+nTV4DCdAN2PevW9ZG2MVnJV8iAxGhvGhB3iLqB2VZ4LXt lWeHcsnx5sxKMsmpLHPx7UIQXNstw/etAZ5XZEpYGQTC0pkXqQhsGVHhV dqpHYth0g/1m8xg84qmgTfMIg+so+PgRGSiVPqVpMxtHJcJWds31iES6t w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ABAgAtJfBV/4UNJK1WB4MjgT0GvR4BCYdwAoE3OBQBAQEBAQEBgQqEJAEBBDoNMhACAQgYHgULMiUCBAENBYguunyPIwEBAQEBAQEBAQEBAQEBAQEBAQEZhnMBg3WBBYRBA0gHhCwBBIcxjiUBjHmBTIQzkQ2DbCaCQoE+cYcBIyCBBQEBAQ X-IronPort-AV: E=Sophos;i="5.17,496,1437436800"; d="scan'208";a="30700095" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-2.cisco.com with ESMTP; 09 Sep 2015 12:30:56 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t89CUuVY006211 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 9 Sep 2015 12:30:56 GMT Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 9 Sep 2015 07:30:55 -0500 Received: from xhc-rcd-x14.cisco.com (173.37.183.88) by xch-rcd-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Wed, 9 Sep 2015 07:30:55 -0500 Received: from xmb-aln-x15.cisco.com ([169.254.9.140]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0248.002; Wed, 9 Sep 2015 07:30:55 -0500 From: "Alvaro Retana (aretana)" To: Yusuke DOI , Brian Haberman Thread-Topic: [Roll] Brian Haberman's Discuss on draft-ietf-roll-mpl-parameter-configuration-06: (with DISCUSS and COMMENT) Thread-Index: AQHQuYnUlrU5N5zZwECQSPYsc22SyQ== Date: Wed, 9 Sep 2015 12:30:54 +0000 Message-ID: References: <20150708141537.17660.50617.idtracker@ietfa.amsl.com> <55E6A5FE.2050309@toshiba.co.jp> In-Reply-To: <55E6A5FE.2050309@toshiba.co.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.36.7.20] Content-Type: text/plain; charset="us-ascii" Content-ID: <7E53FDD0EB7780468B8ADB7523B3E617@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "roll-chairs@ietf.org" , "draft-ietf-roll-mpl-parameter-configuration@ietf.org" , Routing Over Low power and Lossy networks , "maria.ines.robles@ericsson.com" , The IESG , "draft-ietf-roll-mpl-parameter-configuration.shepherd@ietf.org" , "draft-ietf-roll-mpl-parameter-configuration.ad@ietf.org" Subject: Re: [Roll] Brian Haberman's Discuss on draft-ietf-roll-mpl-parameter-configuration-06: (with DISCUSS and COMMENT) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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, 09 Sep 2015 12:30:59 -0000 [Explicitly adding Brian.] On 9/2/15, 3:32 AM, "Yusuke DOI" wrote: >Hi Brian, > >Thank you very much for your kind review. >I updated the document. Sorry for late response. > >On 2015-07-08 23:15, Brian Haberman wrote: >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> Some of these points come from Bernie Volz's INT-Dir review... >> >> 1. This is one of the few options that is not a singleton, as defined in >> section 16 of RFC 7227. While the use of multiple options seems >> appropriate here, it would be best to clarify that clients (section 2.2) >> and servers (section 2.4) must be able to support multiple instances of >> this option. Given the discussion around supporting multiple MPL domains >> in draft-ietf-roll-trickle-mcast, I would expect there to be situations >> where the option appears multiple times. > > >> 2. In section 2.3 (MPL Forwarder Behavior), there should be a brief >> discussion of the role of the MPL Domain Address and include a reference >> to [I-D.ietf-roll-trickle-mcast]. > >Thank you for suggestion. I added some notes on multiple options and >reference. > >> 3. In section 2.6 (Operational Considerations), the text is a bit odd. >> Why should a parameter set not be updated more often than twice the >> Information Refresh Time? How does the failure to refresh the option >>play >> with text in section 2.3 that indicates a missing option means the node >> should leave the MPL domain? Perhaps defining what "failure to refresh" >> means (i.e., I think it refers to lack of a DHCPv6 server response to a >> Renew or Information Request). Note also that Information Refresh Time >>is >> only applicable to Information-Request messages (see RFC 4242) so work >> may be needed as to how this this sections relate to Renew/Rebind >> operations? I am also not sure why 2.6 is a standalone section when it >> appears to be only applicable to clients and should be in either section >> 2.2 or 2.3. > >I modified text with reference to RFC6206, with clarification on 'failure' > > >If a DHCPv6 client with an MPL forwarder configured by the MPL Parameter >Configuration Option is unable to receive a valid response from a server >within T2 of the las\ >t valid DHCPv6 message sent from the server (if stateful) or twice the >Information Refresh Time (if stateless), it MUST suspend the MPL >forwarders of the MPL domains \ >configured by the option. MPL forwarders configured by other methods >such as static configuration file MUST NOT be suspended. > >Clients MUST ignore all MPL Parameter Configuration Options if the >options in a DHCPv6 message contains any invalid value (e.g., it uses >reserved all-0 or all-1 value\ >s in parameters). In this case, the message is considered not received >in MPL context and the condition described in the previous paragraph >applies. > > >> 1. I support Barry's DISCUSS on the lack of an option potentially >>forcing >> a node to leave an MPL domain. > >I hope answer to Barry's DISCUSS can make this resolved. > >> 2. Why is the text in Appendix B not in the Operational Considerations >> section? > >No reason to have separate section so I merged it on local copy (will be >submitted as -08). Thanks for suggestion. > >> 3. Please be consistent with the use of MUSTs and SHALLs. Pick one. > >Agreed and fixed. > >> 4. In section 2.2 (DHCPv6 Client Behavior), 2nd paragraph - why would a >> client discard the option if the reserved bits are set? I would think >> you'd want to use a new option if you're changing things drastically? >>But >> it certainly is your choice as to whether you want to do that. Perhaps a >> better reason is if one of the not-permitted values is used (such as 0 >> and 'all-bits-set') where are clearly reserved? 0 in many of these case >> could be bad since that would yield 0 time values? This really is up to >> you, but do think about what you might want to do any maintain backwards >> compatibility. Adding a new flag bit to the reserved field is probably >> not going to break things if existing implementations ignore the bit(s). > >Thanks. As I stated on Alia's DISCUSS, I changed the definitions of >reserved bits as you suggested. > > >Best Regards, > >Yusuke > From nobody Wed Sep 9 07:40:08 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A30251A6F7D; Wed, 9 Sep 2015 07:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IIhDTFRVwBO1; Wed, 9 Sep 2015 07:40:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 10BF91A21C6; Wed, 9 Sep 2015 07:39:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Brian Haberman" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150909143959.25684.48803.idtracker@ietfa.amsl.com> Date: Wed, 09 Sep 2015 07:39:59 -0700 Archived-At: Cc: roll-chairs@ietf.org, draft-ietf-roll-mpl-parameter-configuration@ietf.org, roll@ietf.org, maria.ines.robles@ericsson.com, draft-ietf-roll-mpl-parameter-configuration.shepherd@ietf.org, draft-ietf-roll-mpl-parameter-configuration.ad@ietf.org Subject: [Roll] Brian Haberman's Discuss on draft-ietf-roll-mpl-parameter-configuration-07: (with DISCUSS and COMMENT) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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, 09 Sep 2015 14:40:06 -0000 Brian Haberman has entered the following ballot position for draft-ietf-roll-mpl-parameter-configuration-07: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-roll-mpl-parameter-configuration/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Updated for -07... 1. Resolved 2. In section 2.3 (MPL Forwarder Behavior), there should be a brief discussion of the role of the MPL Domain Address and include a reference to [I-D.ietf-roll-trickle-mcast]. 3. Resolved ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - Why is the text in Appendix A not in the Operational Considerations section? From nobody Mon Sep 14 07:08:51 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 669531B37D8; Mon, 14 Sep 2015 07:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7rdlhp1jAfzR; Mon, 14 Sep 2015 07:08:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 642B71A21B5; Mon, 14 Sep 2015 07:08:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF Announcement List" X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150914140848.32003.32473.idtracker@ietfa.amsl.com> Date: Mon, 14 Sep 2015 07:08:48 -0700 Archived-At: Cc: roll@ietf.org Subject: [Roll] ROLL WG Virtual Interim Meeting, September 29, 2015 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 14 Sep 2015 14:08:49 -0000 The ROLL Working Group will hold a virtual interim meeting on Tuesday, September 29, 2015 from 13:00 to 15:00 UTC. Additional information will be announced on the ROLL WG mailing list: https://mailarchive.ietf.org/arch/browse/roll/ From nobody Mon Sep 14 09:18:16 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B34C51B3FDF for ; Mon, 14 Sep 2015 09:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6amf5yqPgqTy for ; Mon, 14 Sep 2015 09:18:09 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 140F51A92F0 for ; Mon, 14 Sep 2015 09:18:08 -0700 (PDT) Received: by lamp12 with SMTP id p12so89201717lam.0 for ; Mon, 14 Sep 2015 09:18:06 -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=rBhOPI3ObgaO8CdBp1eTAWPtbrr8HeUCnpybbIMHTIQ=; b=y3mgoxOoC6wLO70ZZq1GCplFG2QqO3POa9pSTfBgYPXl2h6D8dKWbuaHk8LQcTtQKV UgienHH4Zu2yNETLSU9M3Obm/6r90AHPqHo34Y4J5ZW9UlXpjHCfk/Q4m+6Yz1uPBU++ Vw+g2DOGUizapS91QXbE1kmzQt1uTZobqZrUtcLgrOXmjj73KauAHdwlpJHpCZLD2xnk +zxo/kYFEqKKwgW4jspKfPS66Bj7mOvTO+77bx8lgH7blWtxcY2wkkqxR0lQtB9N86LO 0eTRjN423eXVeBKAZzTZMTSHfTDLisbBDannbXidcBAJ+atGyWwjNuK1FSDmN8B6k537 MIAA== MIME-Version: 1.0 X-Received: by 10.112.149.68 with SMTP id ty4mr14859308lbb.74.1442247486232; Mon, 14 Sep 2015 09:18:06 -0700 (PDT) Received: by 10.25.153.194 with HTTP; Mon, 14 Sep 2015 09:18:06 -0700 (PDT) Date: Mon, 14 Sep 2015 19:18:06 +0300 Message-ID: From: Ines Robles To: roll Content-Type: multipart/alternative; boundary=047d7b3a8ca8186b63051fb7692c Archived-At: Cc: Michael Richardson Subject: [Roll] Virtual Interim Meeting, September 29, 2015 - Discuss about uses cases - X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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, 14 Sep 2015 16:18:15 -0000 --047d7b3a8ca8186b63051fb7692c Content-Type: text/plain; charset=UTF-8 Dear all, We scheduled a virtual interim meeting to discuss about the draft: "When to use RFC 6553, 6554 and IPv6-in-IPv6 " [ https://datatracker.ietf.org/doc/draft-robles-roll-useofrplinfo/] The idea is to fill the empty tables of the draft. We kindly appreciate your help. We will post later the details about the connectivity. Thank you very much in advance, Michael and Ines ---------- Forwarded message ---------- From: IESG Secretary Date: 2015-09-14 17:08 GMT+03:00 Subject: [Roll] ROLL WG Virtual Interim Meeting, September 29, 2015 To: IETF Announcement List Cc: roll@ietf.org The ROLL Working Group will hold a virtual interim meeting on Tuesday, September 29, 2015 from 13:00 to 15:00 UTC. Additional information will be announced on the ROLL WG mailing list: https://mailarchive.ietf.org/arch/browse/roll/ --047d7b3a8ca8186b63051fb7692c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear all,

We scheduled a vir= tual interim meeting to discuss about the draft: "When to use RFC 6553= , 6554 and IPv6-in-IPv6 " [https://datatracker.ietf.org/doc/draft-ro= bles-roll-useofrplinfo/]

The idea is to fill t= he empty tables of the draft. We kindly appreciate your help.
We will post later the details about the connectivity.

Thank you very much in advance,

M= ichael and Ines

---------- F= orwarded message ----------
From: IESG Sec= retary <iesg-secretary@ietf.org>
Date: 2015-09-14 17:08 GMT+03:00=
Subject: [Roll] ROLL WG Virtual Interim Meeting, September 29, 2015
= To: IETF Announcement List <ie= tf-announce@ietf.org>
Cc: roll@i= etf.org


The ROLL Working Group will hold a virtual interim m= eeting on Tuesday,
September 29, 2015 from 13:00 to 15:00 UTC.

Additional information will be announced on the ROLL WG mailing list:
https://mailarchive.ietf.org/arch/browse/roll/



--047d7b3a8ca8186b63051fb7692c-- From nobody Wed Sep 16 02:34:03 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06B2A1B3ACF; Wed, 16 Sep 2015 02:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JPm4x5O88U6B; Wed, 16 Sep 2015 02:34:02 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C33A91B3ACA; Wed, 16 Sep 2015 02:34:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3031; q=dns/txt; s=iport; t=1442396041; x=1443605641; h=from:to:cc:subject:date:message-id:mime-version; bh=61mz4lKwIMGks0q76TBYxWNdHSjtsjIbv2Wa8sSJmmI=; b=LbaqKmUbbwyBsrTTRqVUvbv4KDe7lUwrDTbjP/kOSv381GqxQd4YvQcx w412p98mRr6OtMrieeaa51fRp+rFpWNY6RbVETeMg/rI4BUTorRR+vuXw gVczyR7Xk9RMmD0seM8kQWqwyGZHV8jDh0WG7+53uc2WLMhmNaOW39c6m o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DxAQCkNvlV/5JdJa1dglZNVG+9LAENgXmFeQKBQzgUAQEBAQEBAX8LhCUBBC1MEgEMHlYmAQQODYgmDclRAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSGc4R9hFwtBIMfgRQFlV4BdYQah3WbDh8BAUKEAYoWgQUBAQE X-IronPort-AV: E=Sophos;i="5.17,538,1437436800"; d="scan'208,217";a="188503463" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-6.cisco.com with ESMTP; 16 Sep 2015 09:34:01 +0000 Received: from XCH-RCD-020.cisco.com (xch-rcd-020.cisco.com [173.37.102.30]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t8G9Y1LQ014479 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 16 Sep 2015 09:34:01 GMT Received: from xch-rcd-020.cisco.com (173.37.102.30) by XCH-RCD-020.cisco.com (173.37.102.30) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 16 Sep 2015 04:34:00 -0500 Received: from xhc-rcd-x04.cisco.com (173.37.183.78) by xch-rcd-020.cisco.com (173.37.102.30) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Wed, 16 Sep 2015 04:34:00 -0500 Received: from xmb-rcd-x01.cisco.com ([169.254.1.101]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.03.0248.002; Wed, 16 Sep 2015 04:34:00 -0500 From: "Pascal Thubert (pthubert)" To: "6lo@ietf.org" <6lo@ietf.org> Thread-Topic: New routing dispatch and RPL Thread-Index: AdDwYMeoWoUnc7yfSZGKU8XVBJVQeQ== Date: Wed, 16 Sep 2015 09:33:59 +0000 Deferred-Delivery: Wed, 16 Sep 2015 09:33:15 +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.228.42.123] Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD84A048732xmbrcdx01ciscoc_" MIME-Version: 1.0 Archived-At: Cc: Routing Over Low power and Lossy networks Subject: [Roll] New routing dispatch and RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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 Sep 2015 09:34:03 -0000 --_000_E045AECD98228444A58C61C200AE1BD84A048732xmbrcdx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all: We packed pretty much all we got from the meeting(s) in Prague into https:/= /tools.ietf.org/html/draft-thubert-6lo-routing-dispatch-06 Do you see some consequent change we need to make before we ask for last ca= ll? Cheers, Pascal --_000_E045AECD98228444A58C61C200AE1BD84A048732xmbrcdx01ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all:

 

We packed pretty much all we got from the meeting(s)= in Prague into https://tools.ietf.org/html/draft-thubert-6lo-routing-dispatch-06

Do you see some consequent change we need to make be= fore we ask for last call?

 

Cheers,

 

Pascal

 

--_000_E045AECD98228444A58C61C200AE1BD84A048732xmbrcdx01ciscoc_-- From nobody Wed Sep 16 04:39:25 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A3501A924A for ; Wed, 16 Sep 2015 04:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vCRKRPQngF73 for ; Wed, 16 Sep 2015 04:39:21 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62B931A8F46 for ; Wed, 16 Sep 2015 04:39:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10732; q=dns/txt; s=iport; t=1442403561; x=1443613161; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Pt3pm0QcK37H6I9hwhFi9zy70oa6xmwhlzoWPg7LlDA=; b=AfCNuGztTrR8xcvVgmgYyKBw2a/S0wlBts9ipW0M3Av2aXy8d0NwpiG1 SkF7RaAnXEing2DLkrUpxzhDjTbS0beauoChiMMzimVwt2K/tfvTV8d5r HWrCJbXrxaf2rJl8Wt0tNoMndm8eKUM++ks73U/8xIMdQUyXDpgtlKPKI 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DyAQCvU/lV/4kNJK1dglZNVGkGvSEBDYF7hXcCHIEhOBQBAQEBAQEBgQqEIwEBAQQjCkELEAIBCBEDAQEBCx0DAgICMBQJCAIEDgUIiCYNtQaUSAEBAQEBAQEBAQEBAQEBAQEBAQEBAReGc4R9gT2DHw8HCg0EBgEGgmMvgRQFhzOLA4MoAYUPh3WBS5VXg2wfAQFCghEcFoE+cYklgQUBAQE X-IronPort-AV: E=Sophos; i="5.17,538,1437436800"; d="scan'208,217"; a="27406439" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-9.cisco.com with ESMTP; 16 Sep 2015 11:39:20 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t8GBdKGc003289 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 16 Sep 2015 11:39:20 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 16 Sep 2015 06:39:19 -0500 Received: from xhc-rcd-x09.cisco.com (173.37.183.83) by xch-aln-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Wed, 16 Sep 2015 06:39:19 -0500 Received: from xmb-rcd-x01.cisco.com ([169.254.1.101]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0248.002; Wed, 16 Sep 2015 06:39:19 -0500 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] Virtual Interim Meeting, September 29, 2015 - Discuss about uses cases - Thread-Index: AQHQ7wj9GmJBfmkhQn23R1lxKZvdsJ49oiYg Date: Wed, 16 Sep 2015 11:39:18 +0000 Deferred-Delivery: Wed, 16 Sep 2015 11:38:27 +0000 Message-ID: References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.228.42.123] Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD84A048BCAxmbrcdx01ciscoc_" MIME-Version: 1.0 Archived-At: Cc: Michael Richardson Subject: Re: [Roll] Virtual Interim Meeting, September 29, 2015 - Discuss about uses cases - X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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 Sep 2015 11:39:23 -0000 --_000_E045AECD98228444A58C61C200AE1BD84A048BCAxmbrcdx01ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGEgYnVuY2ggSW5lcyENCg0KaHR0cDovL3d3dy53b3JsZHRpbWVidWRkeS5jb20vP3Bs PTEmbGlkPTEwMCwxMiw1MzkyMTcxJmg9MTAwJmRhdGU9OS8yOS8yMDE1fDMNCg0KdGVsbHMgbWUg dGhhdCB0aGlzIGlzIDNQTSBDRVNULCA2QU0gUGFjaWZpYy4NCg0KQ2hlZXJzLA0KDQpQYXNjYWwN Cg0KRnJvbTogUm9sbCBbbWFpbHRvOnJvbGwtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IEluZXMgUm9ibGVzDQpTZW50OiBsdW5kaSAxNCBzZXB0ZW1icmUgMjAxNSAxODoxOA0KVG86IHJv bGwgPHJvbGxAaWV0Zi5vcmc+DQpDYzogTWljaGFlbCBSaWNoYXJkc29uIDxtY3IraWV0ZkBzYW5k ZWxtYW4uY2E+DQpTdWJqZWN0OiBbUm9sbF0gVmlydHVhbCBJbnRlcmltIE1lZXRpbmcsIFNlcHRl bWJlciAyOSwgMjAxNSAtIERpc2N1c3MgYWJvdXQgdXNlcyBjYXNlcyAtDQoNCkRlYXIgYWxsLA0K DQpXZSBzY2hlZHVsZWQgYSB2aXJ0dWFsIGludGVyaW0gbWVldGluZyB0byBkaXNjdXNzIGFib3V0 IHRoZSBkcmFmdDogIldoZW4gdG8gdXNlIFJGQyA2NTUzLCA2NTU0IGFuZCBJUHY2LWluLUlQdjYg IiBbaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcm9ibGVzLXJvbGwtdXNl b2ZycGxpbmZvL10NCg0KVGhlIGlkZWEgaXMgdG8gZmlsbCB0aGUgZW1wdHkgdGFibGVzIG9mIHRo ZSBkcmFmdC4gV2Uga2luZGx5IGFwcHJlY2lhdGUgeW91ciBoZWxwLg0KDQpXZSB3aWxsIHBvc3Qg bGF0ZXIgdGhlIGRldGFpbHMgYWJvdXQgdGhlIGNvbm5lY3Rpdml0eS4NCg0KVGhhbmsgeW91IHZl cnkgbXVjaCBpbiBhZHZhbmNlLA0KDQpNaWNoYWVsIGFuZCBJbmVzDQoNCi0tLS0tLS0tLS0gRm9y d2FyZGVkIG1lc3NhZ2UgLS0tLS0tLS0tLQ0KRnJvbTogSUVTRyBTZWNyZXRhcnkgPGllc2ctc2Vj cmV0YXJ5QGlldGYub3JnPG1haWx0bzppZXNnLXNlY3JldGFyeUBpZXRmLm9yZz4+DQpEYXRlOiAy MDE1LTA5LTE0IDE3OjA4IEdNVCswMzowMA0KU3ViamVjdDogW1JvbGxdIFJPTEwgV0cgVmlydHVh bCBJbnRlcmltIE1lZXRpbmcsIFNlcHRlbWJlciAyOSwgMjAxNQ0KVG86IElFVEYgQW5ub3VuY2Vt ZW50IExpc3QgPGlldGYtYW5ub3VuY2VAaWV0Zi5vcmc8bWFpbHRvOmlldGYtYW5ub3VuY2VAaWV0 Zi5vcmc+Pg0KQ2M6IHJvbGxAaWV0Zi5vcmc8bWFpbHRvOnJvbGxAaWV0Zi5vcmc+DQoNCg0KVGhl IFJPTEwgV29ya2luZyBHcm91cCB3aWxsIGhvbGQgYSB2aXJ0dWFsIGludGVyaW0gbWVldGluZyBv biBUdWVzZGF5LA0KU2VwdGVtYmVyIDI5LCAyMDE1IGZyb20gMTM6MDAgdG8gMTU6MDAgVVRDLg0K DQpBZGRpdGlvbmFsIGluZm9ybWF0aW9uIHdpbGwgYmUgYW5ub3VuY2VkIG9uIHRoZSBST0xMIFdH IG1haWxpbmcgbGlzdDoNCmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9icm93c2Uv cm9sbC8NCg0KDQo= --_000_E045AECD98228444A58C61C200AE1BD84A048BCAxmbrcdx01ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3 OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFu Zz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj5UaGFua3MgYSBidW5jaCBJbmVzITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+PGEgaHJlZj0iaHR0cDovL3d3dy53b3JsZHRpbWVidWRkeS5jb20vP3BsPTEm YW1wO2xpZD0xMDAsMTIsNTM5MjE3MSZhbXA7aD0xMDAmYW1wO2RhdGU9OS8yOS8yMDE1fDMiPmh0 dHA6Ly93d3cud29ybGR0aW1lYnVkZHkuY29tLz9wbD0xJmFtcDtsaWQ9MTAwLDEyLDUzOTIxNzEm YW1wO2g9MTAwJmFtcDtkYXRlPTkvMjkvMjAxNXwzPC9hPg0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj50ZWxscyBtZSB0aGF0IHRoaXMgaXMgM1BNIENFU1QsIDZB TSBQYWNpZmljLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+UGFzY2FsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gUm9sbCBbbWFpbHRvOnJvbGwt Ym91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+SW5lcyBSb2JsZXM8YnI+DQo8 Yj5TZW50OjwvYj4gbHVuZGkgMTQgc2VwdGVtYnJlIDIwMTUgMTg6MTg8YnI+DQo8Yj5Ubzo8L2I+ IHJvbGwgJmx0O3JvbGxAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBNaWNoYWVsIFJpY2hh cmRzb24gJmx0O21jciYjNDM7aWV0ZkBzYW5kZWxtYW4uY2EmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8 L2I+IFtSb2xsXSBWaXJ0dWFsIEludGVyaW0gTWVldGluZywgU2VwdGVtYmVyIDI5LCAyMDE1IC0g RGlzY3VzcyBhYm91dCB1c2VzIGNhc2VzIC08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRlYXIgYWxsLDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSBzY2hlZHVsZWQgYSB2aXJ0 dWFsIGludGVyaW0gbWVldGluZyB0byBkaXNjdXNzIGFib3V0IHRoZSBkcmFmdDogJnF1b3Q7V2hl biB0byB1c2UgUkZDIDY1NTMsIDY1NTQgYW5kIElQdjYtaW4tSVB2NiAmcXVvdDsgWzxhIGhyZWY9 Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXJvYmxlcy1yb2xsLXVzZW9m cnBsaW5mby8iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXJvYmxlcy1y b2xsLXVzZW9mcnBsaW5mby88L2E+XTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgaWRlYSBpcyB0byBmaWxsIHRoZSBlbXB0eSB0YWJsZXMg b2YgdGhlIGRyYWZ0LiBXZSBraW5kbHkgYXBwcmVjaWF0ZSB5b3VyIGhlbHAuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIHdpbGwgcG9zdCBs YXRlciB0aGUgZGV0YWlscyBhYm91dCB0aGUgY29ubmVjdGl2aXR5LjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFuayB5b3UgdmVyeSBtdWNo IGluIGFkdmFuY2UsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPk1pY2hhZWwgYW5kIEluZXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij4tLS0t LS0tLS0tIEZvcndhcmRlZCBtZXNzYWdlIC0tLS0tLS0tLS08YnI+DQpGcm9tOiA8Yj5JRVNHIFNl Y3JldGFyeTwvYj4gJmx0OzxhIGhyZWY9Im1haWx0bzppZXNnLXNlY3JldGFyeUBpZXRmLm9yZyI+ aWVzZy1zZWNyZXRhcnlAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCkRhdGU6IDIwMTUtMDktMTQgMTc6 MDggR01UJiM0MzswMzowMDxicj4NClN1YmplY3Q6IFtSb2xsXSBST0xMIFdHIFZpcnR1YWwgSW50 ZXJpbSBNZWV0aW5nLCBTZXB0ZW1iZXIgMjksIDIwMTU8YnI+DQpUbzogSUVURiBBbm5vdW5jZW1l bnQgTGlzdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlldGYtYW5ub3VuY2VAaWV0Zi5vcmciPmlldGYt YW5ub3VuY2VAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCkNjOiA8YSBocmVmPSJtYWlsdG86cm9sbEBp ZXRmLm9yZyI+cm9sbEBpZXRmLm9yZzwvYT48YnI+DQo8YnI+DQo8YnI+DQpUaGUgUk9MTCBXb3Jr aW5nIEdyb3VwIHdpbGwgaG9sZCBhIHZpcnR1YWwgaW50ZXJpbSBtZWV0aW5nIG9uIFR1ZXNkYXks PGJyPg0KU2VwdGVtYmVyIDI5LCAyMDE1IGZyb20gMTM6MDAgdG8gMTU6MDAgVVRDLjxicj4NCjxi cj4NCkFkZGl0aW9uYWwgaW5mb3JtYXRpb24gd2lsbCBiZSBhbm5vdW5jZWQgb24gdGhlIFJPTEwg V0cgbWFpbGluZyBsaXN0Ojxicj4NCjxhIGhyZWY9Imh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5v cmcvYXJjaC9icm93c2Uvcm9sbC8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL21haWxhcmNoaXZl LmlldGYub3JnL2FyY2gvYnJvd3NlL3JvbGwvPC9hPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_E045AECD98228444A58C61C200AE1BD84A048BCAxmbrcdx01ciscoc_-- From nobody Wed Sep 23 06:57:58 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 007281B3246 for ; Wed, 23 Sep 2015 06:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id my3i6KLfFPIY for ; Wed, 23 Sep 2015 06:57:53 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0790.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::790]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55D241B3250 for ; Wed, 23 Sep 2015 06:57:52 -0700 (PDT) Received: from DB5PR01MB1080.eurprd01.prod.exchangelabs.com (10.162.152.142) by DB5PR01MB1080.eurprd01.prod.exchangelabs.com (10.162.152.142) with Microsoft SMTP Server (TLS) id 15.1.274.16; Wed, 23 Sep 2015 13:57:34 +0000 Received: from DB5PR01MB1080.eurprd01.prod.exchangelabs.com ([10.162.152.142]) by DB5PR01MB1080.eurprd01.prod.exchangelabs.com ([10.162.152.142]) with mapi id 15.01.0274.009; Wed, 23 Sep 2015 13:57:34 +0000 From: "Turner, Randy" To: "roll@ietf.org" Thread-Topic: DIO option for compression context Thread-Index: AdD2BsNcrFf93nN9TPOoLrSgBAab3Q== Date: Wed, 23 Sep 2015 13:57:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Randy.Turner@landisgyr.com; x-originating-ip: [148.80.255.144] x-microsoft-exchange-diagnostics: 1; DB5PR01MB1080; 5:IyU5/Qm7kW+jxzGiarbOEPObm4xBCk+jEzsXopL+yKik3Fn/wmlFFAvNcdhPGtODNoqMHf+b+KQz7nHHIBWavlGSf//+iVNSuWF9gb0bbMrAs7atBGLX4r0FmQIajlhPj+mzUEbIHZ1GFKyZigsqgg==; 24:Lf4j06BCH6uFma9F/Y2M/SubU3WA/2rnUr2V7GAOynlauW4kuh5a59agEBKUINDeb0KroIcyOzP79L/h7pxdp6fGKObIPZiJQ5w0386pvjY=; 20:w9Agw3T5iwy4MOnzAP2nuZFG2RWMXd9OPD921OR9HI/k6NrWPnJSOJk5SPIIHtjW1ZkLDFV83R1S+xUqrLjYNQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5PR01MB1080; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(520078)(3002001); SRVR:DB5PR01MB1080; BCL:0; PCL:0; RULEID:; SRVR:DB5PR01MB1080; x-forefront-prvs: 07083FF734 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(126464002)(53754006)(199003)(189002)(189998001)(62966003)(19625215002)(5003600100002)(5001830100001)(110136002)(77156002)(81156007)(4001540100001)(229853001)(5001860100001)(2900100001)(107886002)(74316001)(5002640100001)(5890100001)(97736004)(2501003)(92566002)(54356999)(105586002)(68736005)(2351001)(50986999)(122556002)(87936001)(64706001)(101416001)(16236675004)(77096005)(5004730100002)(11100500001)(40100003)(561944003)(19300405004)(5001960100002)(86362001)(106356001)(450100001)(66066001)(33656002)(15975445007)(10400500002)(46102003)(102836002)(5007970100001)(99936001)(19580395003); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR01MB1080; H:DB5PR01MB1080.eurprd01.prod.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: landisgyr.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/mixed; boundary="_004_DB5PR01MB10804EF1C9549773EEBCB1E980440DB5PR01MB1080eurp_" MIME-Version: 1.0 X-OriginatorOrg: landisgyr.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Sep 2015 13:57:34.0426 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: ee2cd48b-958f-4be4-9852-b8f104c001b9 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR01MB1080 Archived-At: Subject: [Roll] DIO option for compression context X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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 Sep 2015 13:57:58 -0000 --_004_DB5PR01MB10804EF1C9549773EEBCB1E980440DB5PR01MB1080eurp_ Content-Type: multipart/alternative; boundary="_000_DB5PR01MB10804EF1C9549773EEBCB1E980440DB5PR01MB1080eurp_" --_000_DB5PR01MB10804EF1C9549773EEBCB1E980440DB5PR01MB1080eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello All, At the Prague plenary, during the 6lo session, a number of ROLL participant= s suggested that a multicast DIO option might be better suited for dissemin= ation of RFC 6282 compression context information as an alternative to RFC = 6775 - rather than use DHCPv6 for values that are not "node-specific" but a= pply to all nodes on the network. The attached document re-states the option in the form of a DIO option and = references RFC 6775 section 7.2 for context lifecycle management. This document would be categorized as experimental. I was looking for comments from the ROLL group on this preliminary text (as= this is a DIO option proposal) prior to finalizing the text and submitting= as a draft. Thanks! Randy P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL. This e-mail (including any attachments) is confidential and may be legally = privileged. If you are not an intended recipient or an authorized represent= ative of an intended recipient, you are prohibited from using, copying or d= istributing the information in this e-mail or its attachments. If you have = received this e-mail in error, please notify the sender immediately by retu= rn e-mail and delete all copies of this message and any attachments. Thank = you. --_000_DB5PR01MB10804EF1C9549773EEBCB1E980440DB5PR01MB1080eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello All,

 

At the Prague plenary, during the 6lo session, a num= ber of ROLL participants suggested that a multicast DIO option might be bet= ter suited for dissemination of RFC 6282 compression context information as= an alternative to RFC 6775 – rather than use DHCPv6 for values that are not “node-specific” but ap= ply to all nodes on the network.

 

The attached document re-states the option in the fo= rm of a DIO option and references RFC 6775 section 7.2 for context lifecycl= e management.

 

This document would be categorized as experimental.<= o:p>

 

I was looking for comments from the ROLL group on th= is preliminary text (as this is a DIO option proposal) prior to finalizing = the text and submitting as a draft.

 

Thanks!
Randy


P PLEA= SE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL.

This e-mail (including any attachments) is con= fidential and may be legally privileged. If you are not an intended recipie= nt or an authorized representative of an intended recipient, you are prohib= ited from using, copying or distributing the information in this e-mail or its attachments. If you have received th= is e-mail in error, please notify the sender immediately by return e-mail a= nd delete all copies of this message and any attachments. Thank you.

--_000_DB5PR01MB10804EF1C9549773EEBCB1E980440DB5PR01MB1080eurp_-- --_004_DB5PR01MB10804EF1C9549773EEBCB1E980440DB5PR01MB1080eurp_ Content-Type: text/plain; name="draft-turner-dio-ctx-00.txt" Content-Description: draft-turner-dio-ctx-00.txt Content-Disposition: attachment; filename="draft-turner-dio-ctx-00.txt"; size=9295; creation-date="Wed, 23 Sep 2015 13:49:10 GMT"; modification-date="Wed, 23 Sep 2015 13:49:10 GMT" Content-Transfer-Encoding: base64 CgoKCmluZGl2aWR1YWwgc3VibWlzc2lvbiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFIuIFR1cm5lcgpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIExhbmRpcytHeXIKSW50ZW5kZWQgc3RhdHVzOiBFeHBl cmltZW50YWwgICAgICAgICAgICAgICAgICAgICAgICAgU2VwdGVtYmVyIDIzLCAyMDE1CkV4cGly ZXM6IE1hcmNoIDI2LCAyMDE2CgoKICAgICAgICAgICBSUEwgRElPIE9wdGlvbiBmb3IgU3BlY2lm eWluZyBDb21wcmVzc2lvbiBDb250ZXh0cwogICAgICAgICAgICAgICAgICAgICAgICBkcmFmdC10 dXJuZXItZGlvLWN0eC0wMAoKQWJzdHJhY3QKCiAgIFRoaXMgbWVtbyBkZXNjcmliZXMgYW4gb3B0 aW9uIHRvIGJlIGluY2x1ZGVkIGluIFJQTCBESU8gbWVzc2FnZXMgdGhhdAogICBzcGVjaWZpZXMg b25lIG9yIG1vcmUgY29tcHJlc3Npb24gY29udGV4dHMgdG8gYmUgdXNlZCBmb3IgSVB2NgogICBh ZGRyZXNzIGNvbXByZXNzaW9uLiAgQSBjb21wcmVzc2lvbiBjb250ZXh0IHNwZWNpZmllcyBhIHBh cnRpY3VsYXIKICAgSVB2NiBhZGRyZXNzIHByZWZpeCB0byBiZSB1c2VkIGluIGJvdGggSVB2NiBo ZWFkZXIgY29tcHJlc3Npb24sIGFzCiAgIHdlbGwgYXMgZ2VuZXJpYyBjb21wcmVzc2lvbiB1c2Ut Y2FzZXMuICBUaGUgbGlzdCBvZiBjb21wcmVzc2lvbgogICBjb250ZXh0cyBpcyBpbmRleGVkIGJ5 IGEgY29tcHJlc3Npb24gY29udGV4dCBJRCBjb21wYXRpYmxlIHdpdGggUkZDCiAgIDYyODIuCgpT dGF0dXMgb2YgVGhpcyBNZW1vCgogICBUaGlzIEludGVybmV0LURyYWZ0IGlzIHN1Ym1pdHRlZCBp biBmdWxsIGNvbmZvcm1hbmNlIHdpdGggdGhlCiAgIHByb3Zpc2lvbnMgb2YgQkNQIDc4IGFuZCBC Q1AgNzkuCgogICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJ bnRlcm5ldCBFbmdpbmVlcmluZwogICBUYXNrIEZvcmNlIChJRVRGKS4gIE5vdGUgdGhhdCBvdGhl ciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZQogICB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRl cm5ldC1EcmFmdHMuICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LQogICBEcmFmdHMgaXMg YXQgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RyYWZ0cy9jdXJyZW50Ly4KCiAgIEludGVy bmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4 IG1vbnRocwogICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkg b3RoZXIgZG9jdW1lbnRzIGF0IGFueQogICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1 c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQogICBtYXRlcmlhbCBvciB0byBjaXRlIHRo ZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iCgogICBUaGlzIEludGVybmV0LURy YWZ0IHdpbGwgZXhwaXJlIG9uIE1hcmNoIDI2LCAyMDE2LgoKQ29weXJpZ2h0IE5vdGljZQoKICAg Q29weXJpZ2h0IChjKSAyMDE1IElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQg YXMgdGhlCiAgIGRvY3VtZW50IGF1dGhvcnMuICBBbGwgcmlnaHRzIHJlc2VydmVkLgoKICAgVGhp cyBkb2N1bWVudCBpcyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQgdGhlIElFVEYgVHJ1c3QncyBMZWdh bAogICBQcm92aXNpb25zIFJlbGF0aW5nIHRvIElFVEYgRG9jdW1lbnRzCiAgIChodHRwOi8vdHJ1 c3RlZS5pZXRmLm9yZy9saWNlbnNlLWluZm8pIGluIGVmZmVjdCBvbiB0aGUgZGF0ZSBvZgogICBw dWJsaWNhdGlvbiBvZiB0aGlzIGRvY3VtZW50LiAgUGxlYXNlIHJldmlldyB0aGVzZSBkb2N1bWVu dHMKICAgY2FyZWZ1bGx5LCBhcyB0aGV5IGRlc2NyaWJlIHlvdXIgcmlnaHRzIGFuZCByZXN0cmlj dGlvbnMgd2l0aCByZXNwZWN0CiAgIHRvIHRoaXMgZG9jdW1lbnQuICBDb2RlIENvbXBvbmVudHMg ZXh0cmFjdGVkIGZyb20gdGhpcyBkb2N1bWVudCBtdXN0CiAgIGluY2x1ZGUgU2ltcGxpZmllZCBC U0QgTGljZW5zZSB0ZXh0IGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuZSBvZgoKCgpUdXJuZXIg ICAgICAgICAgICAgICAgICAgRXhwaXJlcyBNYXJjaCAyNiwgMjAxNiAgICAgICAgICAgICAgICAg W1BhZ2UgMV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICBESU8gQ29tcHJlc3Npb24gQ29udGV4dCBP cHRpb24gICAgICAgU2VwdGVtYmVyIDIwMTUKCgogICB0aGUgVHJ1c3QgTGVnYWwgUHJvdmlzaW9u cyBhbmQgYXJlIHByb3ZpZGVkIHdpdGhvdXQgd2FycmFudHkgYXMKICAgZGVzY3JpYmVkIGluIHRo ZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNlLgoKMS4gIEludHJvZHVjdGlvbgoKICAgUkZDIDY1NTAg W1JGQzY1NTBdIGluY2x1ZGVzIGEgIkRPREFHIEluZm9ybWF0aW9uIE9iamVjdCIgKERJTykKICAg bWVzc2FnZSB0aGF0IGFsbG93cyBub2RlcyB3aXRoaW4gYSBwYXJ0aWN1bGFyIERPREFHIGluc3Rh bmNlIHRvIGxlYXJuCiAgIGFib3V0IGNvbmZpZ3VyYXRpb24gcGFyYW1ldGVycyBzcGVjaWZpYyB0 byB0aGUgRE9EQUcgaW5zdGFuY2UuICBUaGUKICAgbWVzc2FnZSBpbmNsdWRlcyBmaXhlZCBmaWVs ZHMgY29udGFpbmluZyBmdW5kYW1lbnRhbCBET0RBRwogICBvcGVyYXRpb25hbCBwYXJhbWV0ZXJz LCBhbmQgYWxzbyBwcm92aWRlcyBmb3Igb3B0aW9uYWwgZmllbGRzIHRoYXQKICAgc3BlY2lmeSBh ZGRpdGlvbmFsIERPREFHIHBhcmFtZXRlcnMuICBUaGUgb3B0aW9uYWwgcGFyYW1ldGVycyBhcmUK ICAgc3BlY2lmaWVkIHRocm91Z2ggdHlwZS1sZW5ndGgtdmFsdWUgKFRMVikgZXh0ZW5zaW9ucy4g IFRoaXMgbWVtbwogICBwcm9wb3NlcyBhIG5ldyBESU8gb3B0aW9uIGZvciBzcGVjaWZ5aW5nIGEg bGlzdCBvZiBjb21wcmVzc2lvbgogICBjb250ZXh0cyBhcHByb3ByaWF0ZSBmb3IgYWRkcmVzc2lu ZyB1c2UtY2FzZXMgd2hlcmUgSVB2NiBhZGRyZXNzCiAgIGNvbXByZXNzaW9uIGlzIHJlcXVpcmVk LgoKMS4xLiAgUmVxdWlyZW1lbnRzIExhbmd1YWdlCgogICBUaGUga2V5IHdvcmRzICJNVVNUIiwg Ik1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsCiAgICJTSE9VTEQi LCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0 aGlzCiAgIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gW1JG QzIxMTldIFtSRkMyMTE5XS4KCjIuICBUZXJtaW5vbG9neQoKICAgVGhpcyBkb2N1bWVudCBwcmlt YXJpbHkgdXNlcyB0aGUgdGVybWlub2xvZ3kgZGVzY3JpYmVkIGluIFtSRkM2NTUwXQogICBbUkZD NjU1MF0sIFtSRkM2MjgyXSBbUkZDNjI4Ml0sIGFuZCBbUkZDNjc3NV0gW1JGQzY3NzVdLgoKMy4g IENvbXByZXNzaW9uIENvbnRleHQgT3B0aW9uCgogICBUaGUgNkNPIG9wdGlvbiBkZXNjcmliZXMg YSBwYXJ0aWN1bGFyIElQdjYgYWRkcmVzcyBwcmVmaXggdG8gYXNzdW1lCiAgIGZvciB1c2UtY2Fz ZXMgd2hlcmUgSVB2NiBhZGRyZXNzIGNvbXByZXNzaW9uIGlzIHJlcXVpcmVkLgoKCgoKCgoKCgoK CgoKCgoKCgoKClR1cm5lciAgICAgICAgICAgICAgICAgICBFeHBpcmVzIE1hcmNoIDI2LCAyMDE2 ICAgICAgICAgICAgICAgICBbUGFnZSAyXQoMCkludGVybmV0LURyYWZ0ICAgICAgIERJTyBDb21w cmVzc2lvbiBDb250ZXh0IE9wdGlvbiAgICAgICBTZXB0ZW1iZXIgMjAxNQoKCiAgICAwICAgICAg ICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAgICAgICAgICAzCiAg ICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3 IDggOSAwIDEKICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSsKICAgfCAgICAgVHlwZSAgICAgIHwgICAgIExlbmd0aCAgICB8 Q29udGV4dCBMZW5ndGggfCBSZXMgfEN8ICBDSUQgIHwKICAgKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgLiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC4K ICAgLiAgICAgICAgICAgICAgICAgICAgICAgQ29udGV4dCBQcmVmaXggICAgICAgICAgICAgICAg ICAgICAgICAgIC4KICAgLiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIC4KICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKCiAgICAgICAgICAgICAgICAgIEZp Z3VyZSAxOiA2TG9XUEFOIENvbnRleHQgT3B0aW9uIEZvcm1hdAoKICAgTGVuZ3RoOiAgICAgICAg ICA4LWJpdCB1bnNpZ25lZCBpbnRlZ2VyLiAgVGhlIGxlbmd0aCBvZiB0aGUgb3B0aW9uCiAgICAg ICAgICAgICAgICAgICAgKGluY2x1ZGluZyB0aGUgVHlwZSBhbmQgTGVuZ3RoIGZpZWxkcykgaW4g dW5pdHMgb2YKICAgICAgICAgICAgICAgICAgICA4IGJ5dGVzLiAgTWF5IGJlIDIgb3IgMywgZGVw ZW5kaW5nIG9uIHRoZSBsZW5ndGggb2YKICAgICAgICAgICAgICAgICAgICB0aGUgQ29udGV4dCBQ cmVmaXggZmllbGQuCgogICBDb250ZXh0IExlbmd0aDogIDgtYml0IHVuc2lnbmVkIGludGVnZXIu ICBUaGUgbnVtYmVyIG9mIGxlYWRpbmcgYml0cwogICAgICAgICAgICAgICAgICAgIGluIHRoZSBD b250ZXh0IFByZWZpeCBmaWVsZCB0aGF0IGFyZSB2YWxpZC4gIFRoZQogICAgICAgICAgICAgICAg ICAgIHZhbHVlIHJhbmdlcyBmcm9tIDAgdG8gMTI4LiAgSWYgaXQgaXMgbW9yZSB0aGFuIDY0LAog ICAgICAgICAgICAgICAgICAgIHRoZW4gdGhlIExlbmd0aCBNVVNUIGJlIDMuCgogICBDOiAgICAg ICAgICAgICAgIDEtYml0IGNvbnRleHQgQ29tcHJlc3Npb24gZmxhZy4gIFRoaXMgZmxhZyBpbmRp Y2F0ZXMKICAgICAgICAgICAgICAgICAgICBpZiB0aGUgY29udGV4dCBpcyB2YWxpZCBmb3IgdXNl IGluIGNvbXByZXNzaW9uLiAgQQogICAgICAgICAgICAgICAgICAgIGNvbnRleHQgdGhhdCBpcyBu b3QgdmFsaWQgTVVTVCBOT1QgYmUgdXNlZCBmb3IKICAgICAgICAgICAgICAgICAgICBjb21wcmVz c2lvbiBidXQgU0hPVUxEIGJlIHVzZWQgaW4gZGVjb21wcmVzc2lvbiBpbgogICAgICAgICAgICAg ICAgICAgIGNhc2UgYW5vdGhlciBjb21wcmVzc29yIGhhcyBub3QgeWV0IHJlY2VpdmVkIHRoZQog ICAgICAgICAgICAgICAgICAgIHVwZGF0ZWQgY29udGV4dCBpbmZvcm1hdGlvbi4gIFRoaXMgZmxh ZyBpcyB1c2VkIHRvCiAgICAgICAgICAgICAgICAgICAgbWFuYWdlIHRoZSBjb250ZXh0IGxpZmUg Y3ljbGUgYmFzZWQgb24gdGhlCiAgICAgICAgICAgICAgICAgICAgcmVjb21tZW5kYXRpb25zIGlu IFtSRkM2Nzc1XSBTZWN0aW9uIDcuMi4KCiAgIENJRDogICAgICAgICAgICAgNC1iaXQgQ29udGV4 dCBJZGVudGlmaWVyIGZvciB0aGlzIHByZWZpeAogICAgICAgICAgICAgICAgICAgIGluZm9ybWF0 aW9uLiAgVGhlIENJRCBpcyB1c2VkIGJ5IGNvbnRleHQtYmFzZWQKICAgICAgICAgICAgICAgICAg ICBoZWFkZXIgY29tcHJlc3Npb24gYXMgc3BlY2lmaWVkIGluIFtSRkM2MjgyXS4gIFRoZQogICAg ICAgICAgICAgICAgICAgIGxpc3Qgb2YgQ0lEcyBmb3IgYSBMb1dQQU4gaXMgY29uZmlndXJlZCBv biB0aGUgNkxCUgogICAgICAgICAgICAgICAgICAgIHRoYXQgb3JpZ2luYXRlcyB0aGUgY29udGV4 dCBpbmZvcm1hdGlvbiBmb3IgdGhlCiAgICAgICAgICAgICAgICAgICAgNkxvV1BBTi4KCiAgIENv bnRleHQgUHJlZml4OiAgVGhlIElQdjYgcHJlZml4IG9yIGFkZHJlc3MgY29ycmVzcG9uZGluZyB0 byB0aGUgQ0lECiAgICAgICAgICAgICAgICAgICAgZmllbGQuICBUaGUgdmFsaWQgbGVuZ3RoIG9m IHRoaXMgZmllbGQgaXMgaW5jbHVkZWQKICAgICAgICAgICAgICAgICAgICBpbiB0aGUgQ29udGV4 dCBMZW5ndGggZmllbGQuICBUaGlzIGZpZWxkIGlzIHBhZGRlZAogICAgICAgICAgICAgICAgICAg IHdpdGggemVyb3MgaW4gb3JkZXIgdG8gbWFrZSB0aGUgb3B0aW9uIGEgbXVsdGlwbGUgb2YKICAg ICAgICAgICAgICAgICAgICA4IGJ5dGVzLgoKCgoKCgoKClR1cm5lciAgICAgICAgICAgICAgICAg ICBFeHBpcmVzIE1hcmNoIDI2LCAyMDE2ICAgICAgICAgICAgICAgICBbUGFnZSAzXQoMCkludGVy bmV0LURyYWZ0ICAgICAgIERJTyBDb21wcmVzc2lvbiBDb250ZXh0IE9wdGlvbiAgICAgICBTZXB0 ZW1iZXIgMjAxNQoKCjQuICBSUEwgUm9vdCBPcGVyYXRpb24KCiAgIFZhbGlkIGNvbXByZXNzaW9u IGNvbnRleHRzIGFyZSBwcm92aXNpb25lZCBpbnRvIFJQTCByb290CiAgIGltcGxlbWVudGF0aW9u cyBpbiBhIG1hbm5lciBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50LgogICBDb250 ZXh0cyBhcmUgcHJvdmlzaW9uZWQgYXMgb25lIG9yIG1vcmUgcHJlZml4LCBwcmVmaXgtbGVuZ3Ro LCBhbmQKICAgY29udGV4dC1JRCB0dXBsZXMsIGFzIGRlc2NyaWJlZCBpbiBSRkMgNjI4Mi4gIFVw IHRvIDE2IHR1cGxlcyAoMCB0bwogICAxNSkgY2FuIGJlIGNvbmZpZ3VyZWQuICBFYWNoIHR1cGxl IHdpbGwgcmVxdWlyZSBvbmUgRElPIG9wdGlvbiBpbiBhCiAgIERJTyBtZXNzYWdlLCBzbyBpZiB0 aGVyZSBhcmUgOCBjb250ZXh0IHR1cGxlcyBjb25maWd1cmVkLCB0aGVuIGEgRElPCiAgIG1lc3Nh Z2Ugd2lsbCBjb250YWluIDggRElPIGNvbXByZXNzaW9uIGNvbnRleHQgb3B0aW9ucy4KCjUuICBS UEwgUm91dGVyIGFuZCBMZWFmIE9wZXJhdGlvbgoKICAgUlBMIHJvdXRlcnMgYW5kIGxlYWZzICho ZW5jZWZvcnRoIHJlZmVycmVkIHRvIGFzICdub2RlcycpIHJlY2VpdmUgRElPCiAgIG1lc3NhZ2Vz IGFuZCBleHRyYWN0IHRoZSBjb21wcmVzc2lvbiBjb250ZXh0IG9wdGlvbihzKSBmcm9tIHRoZSBE SU8KICAgbWVzc2FnZS4gIFRoZSAnQycgYml0IGluIHRoZSBjb21wcmVzc2lvbiBjb250ZXh0IG9w dGlvbiBlbmFibGVzCiAgIGxpZmVjeWNsZSBtYW5hZ2VtZW50IG9mIHRoZSBwYXJ0aWN1bGFyIG9w dGlvbiBhY2NvcmRpbmcgdG8gc2VjdGlvbgogICA3LjIgb2YgUkZDIDY3NzUuCgo2LiAgU2VjdXJp dHkgQ29uc2lkZXJhdGlvbnMKCiAgIFRoZSBpbnRyb2R1Y3Rpb24gb2YgY29tcHJlc3Npb24gY29u dGV4dHMgaW50byBhIDZMb1dQQU4gaW52b2x2ZXMKICAgYmVpbmcgYWJsZSB0byB0cnVzdCB0aGUg c2VuZGVyIG9mIHRoZSBjb250ZXh0IGluZm9ybWF0aW9uLCBhcyB3ZWxsIGFzCiAgIHZlcmlmeWlu ZyB0aGF0IHRoZSBjb250ZXh0IGluZm9ybWF0aW9uIGhhcyBub3QgYmVlbiBtb2RpZmllZCBzaW5j ZQogICB0cmFuc21pc3Npb24gYnkgYSB0cnVzdGVkIHNlbmRlci4KCiAgIENvbmZpZGVudGlhbGl0 eSBvZiBjb250ZXh0IGluZm9ybWF0aW9uIGlzIG5vdCBjb25zaWRlcmVkIGEKICAgcmVxdWlyZW1l bnQuCgogICBSUEwgcHJvdmlkZXMgYW4gb3B0aW9uYWwgZmFjaWxpdHkgdG8gc2VjdXJlIFJQTCBt ZXNzYWdlcyBmb3IKICAgY29uZmlkZW50aWFsaXR5LCBhdXRoZW50aWNpdHksIGFuZCBpbnRlZ3Jp dHkuICBVc2luZyBSUEwgc2VjdXJpdHkKICAgd291bGQgc2F0aXNmeSB0aGUgc2VjdXJpdHkgcmVx dWlyZW1lbnRzIGZvciB0aGUgZGlzc2VtaW5hdGlvbiBvZgogICBjb21wcmVzc2lvbiBjb250ZXh0 IGluZm9ybWF0aW9uLiAgQWx0ZXJuYXRpdmVseSwgaWYgYSA2TG9XUEFOIG5ldHdvcmsKICAgdXNl cyA4MDIuMTUuNCwgdGhlbiB0aGUgc2VjdXJpdHkgcmVxdWlyZW1lbnRzIG9mIHRoaXMgbWVtbyB3 b3VsZCBiZQogICBtZXQgYnkgdXNpbmcgYSAic2VjdXJlIG5ldHdvcmsgam9pbiIgbWV0aG9kIHdo ZXJlYnkgc29tZSB0eXBlIG9mCiAgIG11dHVhbCBhdXRoZW50aWNhdGlvbiB3b3VsZCBiZSB1dGls aXplZCBzbyB0aGF0IDZMb1dQQU4gbm9kZXMgY291bGQKICAgdHJ1c3QgRElPIG1lc3NhZ2VzIG9y aWdpbmF0aW5nIGZyb20gdGhlIG5ldHdvcmsuCgo3LiAgUmVmZXJlbmNlcwoKICAgW1JGQzY1NTBd ICBXaW50ZXIsIFQuLCBUaHViZXJ0LCBQLiwgQnJhbmR0LCBBLiwgSHVpLCBKLiwgS2Vsc2V5LCBS LiwKICAgICAgICAgICAgICBMZXZpcywgUC4sIFBpc3RlciwgSy4sIFN0cnVpaywgUi4sIFZhc3Nl dXIsIEpQLiwgYW5kIFIuCiAgICAgICAgICAgICAgQWxleGFuZGVyLCAiUlBMOiBJUHY2IFJvdXRp bmcgUHJvdG9jb2wgZm9yIExvdy1Qb3dlciBhbmQKICAgICAgICAgICAgICBMb3NzeSBOZXR3b3Jr cyIsIFJGQyA2NTUwLCBNYXJjaCAyMDEyLgoKICAgW1JGQzY3NzVdICBTaGVsYnksIFouLCBDaGFr cmFiYXJ0aSwgUy4sIE5vcmRtYXJrLCBFLiwgYW5kIEMuIEJvcm1hbm4sCiAgICAgICAgICAgICAg Ik5laWdoYm9yIERpc2NvdmVyeSBPcHRpbWl6YXRpb24gZm9yIElQdjYgb3ZlciA2TG9XUEFOcyIs CiAgICAgICAgICAgICAgUkZDIDY3NzUsIE5vdmVtYmVyIDIwMTIuCgoKCgpUdXJuZXIgICAgICAg ICAgICAgICAgICAgRXhwaXJlcyBNYXJjaCAyNiwgMjAxNiAgICAgICAgICAgICAgICAgW1BhZ2Ug NF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICBESU8gQ29tcHJlc3Npb24gQ29udGV4dCBPcHRpb24g ICAgICAgU2VwdGVtYmVyIDIwMTUKCgogICBbUkZDNjI4Ml0gIEh1aSwgSi4gYW5kIFAuIFRodWJl cnQsICJDb21wcmVzc2lvbiBGb3JtYXQgZm9yIElQdjYKICAgICAgICAgICAgICBEYXRhZ3JhbXMg b3ZlciA4MDIuMTUuNC1CYXNlZCBOZXR3b3JrcyIsIFJGQyA2MjgyLAogICAgICAgICAgICAgIFNl cHRlbWJlciAyMDExLgoKICAgW1JGQzIxMTldICBCcmFkbmVyLCBTLiwgIktleSB3b3JkcyBmb3Ig dXNlIGluIFJGQ3MgdG8gSW5kaWNhdGUKICAgICAgICAgICAgICBSZXF1aXJlbWVudCBMZXZlbHMi LCBSRkMgMjExOSwgTWFyY2ggMTk5Ny4KCkF1dGhvcidzIEFkZHJlc3MKCiAgIFJhbmR5IFR1cm5l cgogICBMYW5kaXMrR3lyCiAgIDMwMDAwIE1pbGwgQ3JlZWsgQXZlCiAgIFN1aXRlIDEwMAogICBB bHBoYXJldHRhLCBHQSAgMzAwMjIKICAgVVMKCiAgIFBob25lOiArMSA2NzggMjU4IDE5MjkKICAg RW1haWw6IHJhbmR5LnR1cm5lckBsYW5kaXNneXIuY29tCiAgIFVSSTogICBodHRwOi8vd3d3Lmxh bmRpc2d5ci5jb20vCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKVHVybmVyICAgICAg ICAgICAgICAgICAgIEV4cGlyZXMgTWFyY2ggMjYsIDIwMTYgICAgICAgICAgICAgICAgIFtQYWdl IDVdCg== --_004_DB5PR01MB10804EF1C9549773EEBCB1E980440DB5PR01MB1080eurp_-- From nobody Wed Sep 23 09:19:23 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 352D01A8842 for ; Wed, 23 Sep 2015 09:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U4c4GVC6aas3 for ; Wed, 23 Sep 2015 09:19:17 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AC101A8862 for ; Wed, 23 Sep 2015 09:19:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8623; q=dns/txt; s=iport; t=1443025157; x=1444234757; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=xQTuf68pvmbHlxBVS1W3i0744zpOANciBHWvyRVCH9w=; b=apXvB16svC0oPRcSZ+m2mGGYOGv4ZWkqyE3jfI/B9BDwM1rJu5qnZUPv zON+PQF+vj2t9969Iv0TPdvMHPvFcAxBzJlERwnu3yW/8IYqzeiid0Qlb N3zKN8HdrFMaFGzvZ7m4CjbW7LQMRZZBBBGwt5xPzALdyg2Cbu1cIov7V E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DwAQCT0AJW/4UNJK1dgldNVGkGvVABDYdzAoFLOBQBAQEBAQEBgQqEJAEBAQQtXAIBCBEEAQEoBzIUCQgBAQQTCIgmy2YBAQEBAQEBAQEBAQEBAQEBAQEBAQEXhnOEfYQqEQFXAQaEJgWVZwGNBoFThDaVJAEfAQFChAFxiC46gQUBAQE X-IronPort-AV: E=Sophos; i="5.17,577,1437436800"; d="scan'208,217"; a="29532929" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-7.cisco.com with ESMTP; 23 Sep 2015 16:18:58 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t8NGIwha024461 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 23 Sep 2015 16:18:58 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 23 Sep 2015 11:18:58 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1104.000; Wed, 23 Sep 2015 11:18:57 -0500 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: DIO option for compression context Thread-Index: AdD2BsNcrFf93nN9TPOoLrSgBAab3QAE2k4g Date: Wed, 23 Sep 2015 16:18:52 +0000 Deferred-Delivery: Wed, 23 Sep 2015 16:18:51 +0000 Message-ID: <610f76cd75bc4e25b652872a71ece71a@XCH-RCD-001.cisco.com> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.49.80.24] Content-Type: multipart/alternative; boundary="_000_610f76cd75bc4e25b652872a71ece71aXCHRCD001ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] DIO option for compression context X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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 Sep 2015 16:19:20 -0000 --_000_610f76cd75bc4e25b652872a71ece71aXCHRCD001ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Randy: This is good work and I think it needs to be pursued I see that you omitted the lifetime in the option (comparing to RFC 6775). = Why is this so? Section 5 should mention that the option is propagated as is. If it is not = needed in all DIOs then you could indicate when to send it. This could be f= or instance trickled upon a change and placed in responses to DIS messages. Cheers, Pascal From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Turner, Randy Sent: mercredi 23 septembre 2015 15:58 To: roll@ietf.org Subject: [Roll] DIO option for compression context Hello All, At the Prague plenary, during the 6lo session, a number of ROLL participant= s suggested that a multicast DIO option might be better suited for dissemin= ation of RFC 6282 compression context information as an alternative to RFC = 6775 - rather than use DHCPv6 for values that are not "node-specific" but a= pply to all nodes on the network. The attached document re-states the option in the form of a DIO option and = references RFC 6775 section 7.2 for context lifecycle management. This document would be categorized as experimental. I was looking for comments from the ROLL group on this preliminary text (as= this is a DIO option proposal) prior to finalizing the text and submitting= as a draft. Thanks! Randy P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL. This e-mail (including any attachments) is confidential and may be legally = privileged. If you are not an intended recipient or an authorized represent= ative of an intended recipient, you are prohibited from using, copying or d= istributing the information in this e-mail or its attachments. If you have = received this e-mail in error, please notify the sender immediately by retu= rn e-mail and delete all copies of this message and any attachments. Thank = you. --_000_610f76cd75bc4e25b652872a71ece71aXCHRCD001ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Randy:

 

This is good work and = I think it needs to be pursued

 

I see that you omitted= the lifetime in the option (comparing to RFC 6775). Why is this so?

 

Section 5 should menti= on that the option is propagated as is. If it is not needed in all DIOs the= n you could indicate when to send it. This could be for instance trickled u= pon a change and placed in responses to DIS messages.

 

Cheers,

 = ;

Pascal

 

From: Roll [mailto:roll-bounces@ietf.org] = On Behalf Of Turner, Randy
Sent: mercredi 23 septembre 2015 15:58
To: roll@ietf.org
Subject: [Roll] DIO option for compression context

 

Hello All,

 

At the Prague plenary, during the 6lo session, a num= ber of ROLL participants suggested that a multicast DIO option might be bet= ter suited for dissemination of RFC 6282 compression context information as= an alternative to RFC 6775 – rather than use DHCPv6 for values that are not “node-specific” but ap= ply to all nodes on the network.

 

The attached document re-states the option in the fo= rm of a DIO option and references RFC 6775 section 7.2 for context lifecycl= e management.

 

This document would be categorized as experimental.<= o:p>

 

I was looking for comments from the ROLL group on th= is preliminary text (as this is a DIO option proposal) prior to finalizing = the text and submitting as a draft.

 

Thanks!
Randy

 

P PLEASE CONSIDER OUR E= NVIRONMENT BEFORE PRINTING THIS EMAIL.

This e-mail (including any attachments) is confident= ial and may be legally privileged. If you are not an intended recipient or = an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the info= rmation in this e-mail or its attachments. If you have received this e-mail= in error, please notify the sender immediately by return e-mail and delete= all copies of this message and any attachments. Thank you. =

--_000_610f76cd75bc4e25b652872a71ece71aXCHRCD001ciscocom_-- From nobody Wed Sep 23 10:10:42 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E334E1A884E for ; Wed, 23 Sep 2015 10:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EwDjQgFTIJZs for ; Wed, 23 Sep 2015 10:10:37 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0752.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::752]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FEED1A8755 for ; Wed, 23 Sep 2015 10:06:43 -0700 (PDT) Received: from DB5PR01MB1077.eurprd01.prod.exchangelabs.com (10.162.152.14) by DB5PR01MB0965.eurprd01.prod.exchangelabs.com (10.161.197.23) with Microsoft SMTP Server (TLS) id 15.1.274.16; Wed, 23 Sep 2015 17:06:22 +0000 Received: from DB5PR01MB1080.eurprd01.prod.exchangelabs.com (10.162.152.142) by DB5PR01MB1077.eurprd01.prod.exchangelabs.com (10.162.152.14) with Microsoft SMTP Server (TLS) id 15.1.274.16; Wed, 23 Sep 2015 17:06:21 +0000 Received: from DB5PR01MB1080.eurprd01.prod.exchangelabs.com ([10.162.152.142]) by DB5PR01MB1080.eurprd01.prod.exchangelabs.com ([10.162.152.142]) with mapi id 15.01.0274.009; Wed, 23 Sep 2015 17:06:21 +0000 From: "Turner, Randy" To: "pthubert@cisco.com" Thread-Topic: DIO compression option Thread-Index: AdD2IbYxqzl6YbyQR+67lzbuc7ttTg== Date: Wed, 23 Sep 2015 17:06:21 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Randy.Turner@landisgyr.com; x-originating-ip: [148.80.255.144] x-microsoft-exchange-diagnostics: 1; DB5PR01MB1077; 5:zS7vqQBz7Naf9vVVPTc2OoMo7fyIiAja/rEc/Yt/mKCulg+Qx684i9h/yfy8yuDDruLskffeW+XaKI+A/pt5IMROvcTgncCIELbUSp44gYZ7ZpDcK77gg8mmPNMV3u9YpRJuyolvNqyMi2af5kRhSQ==; 24:KOOHCrzQLa3a2wq0Ac3G0CHE3US7Qd82a3Z3ohNp9oHlFByrYB48Omx3mwDcmxLRvuNcINq5J3LP3FPxl/tlJTcTsPM4U38zNkJRYKtMeYE=; 20:7ogU7iLKvlus8KA2FhA67pRdEhvkfQi/24A155PlZjU9lvA6tz+sA6CuU8QxkmlYcEi8y321O8GS4ka9iGpZFA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5PR01MB1077; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014)(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(3002001); SRVR:DB5PR01MB1077; BCL:0; PCL:0; RULEID:; SRVR:DB5PR01MB1077; x-forefront-prvs: 07083FF734 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(53754006)(126464002)(33656002)(5003600100002)(86362001)(2501003)(5001960100002)(19580405001)(19625215002)(64706001)(87936001)(561944003)(74316001)(122556002)(66066001)(5890100001)(7520500002)(101416001)(92566002)(77096005)(2351001)(16236675004)(77156002)(46102003)(5007970100001)(105586002)(97736004)(50986999)(110136002)(5001920100001)(11100500001)(5001860100001)(19580395003)(40100003)(2900100001)(81156007)(54356999)(5001830100001)(106356001)(4001540100001)(10400500002)(68736005)(189998001)(15975445007)(102836002)(5002640100001)(229853001)(19300405004)(62966003)(5004730100002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR01MB1077; H:DB5PR01MB1080.eurprd01.prod.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: landisgyr.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB5PR01MB10801FA4759E5D4CA856F8C780440DB5PR01MB1080eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Sep 2015 17:06:21.3087 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: ee2cd48b-958f-4be4-9852-b8f104c001b9 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR01MB1077 X-Microsoft-Exchange-Diagnostics: 1; DB5PR01MB0965; 2:0kZRE6JH/eGgctDX5l5sp7FJUYTfFZTQAtmM5lzdH2z+F8xwqm/20py/wWOrWQ8h/4Mqtqi1r9rq7eC7NpM0A7IlocfLBZCgOuejLaDAHs3VNDjSfOzP7838HPNjcJsZ0GHaRiZ1Yh7W+uhqM+ogMhyIV5fYGnxFByrJ85inIPE=; 23:9RaDEfFXM7TbPiuUNKhdx/MEDuMHmtFtctljAYScg97prLr9zHEcLn5gc1Zt1e0XlAEtXRMHCEH+cj3i7kHmAIanPOJNjf1DhhcBIsSLly9hPSIEBxJ/Dmr5/6ofF2aHPKzyRNvSlI6NfQR6Y1dA/+eHpqlxnmbHyRtCMRBmdlFXxGiiLD4vQL9pTi3qQZke X-OriginatorOrg: landisgyr.com Archived-At: Cc: "roll@ietf.org" Subject: [Roll] DIO compression option X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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 Sep 2015 17:10:41 -0000 --_000_DB5PR01MB10801FA4759E5D4CA856F8C780440DB5PR01MB1080eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Pascal, It was not my intention to leave out the lifetime value...just a cut and pa= ste error on my part - the lifetime value will be added to this document...= I wanted this option to semantically be the same as the 6775 version, inclu= ding lifecycle management. I was definitely going to provide some text as to when this option might be= disseminated - under what circumstances (would it be solicited, or periodi= cally sent) basically under what conditions a non-root node might be expect= ed to receive the option. Thanks! Randy Re: [Roll] DIO option for compression context "Pascal Thubert (pthubert)" Wed, 23 September 2015 16:= 19 UTCShow header Hello Randy: This is good work and I think it needs to be pursued I see that you omitted the lifetime in the option (comparing to RFC 6775). = Why is this so? Section 5 should mention that the option is propagated as is. If it is not = needed in all DIOs then you could indicate when to send it. This could be f= or instance trickled upon a change and placed in responses to DIS messages. Cheers, Pascal From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Turner, Randy Sent: mercredi 23 septembre 2015 15:58 To: roll@ietf.org Subject: [Roll] DIO option for compression context Hello All, At the Prague plenary, during the 6lo session, a number of ROLL participant= s suggested that a multicast DIO option might be better suited for dissemin= ation of RFC 6282 compression context information as an alternative to RFC = 6775 - rather than use DHCPv6 for values that are not "node-specific" but a= pply to all nodes on the network. The attached document re-states the option in the form of a DIO option and = references RFC 6775 section 7.2 for context lifecycle management. This document would be categorized as experimental. I was looking for comments from the ROLL group on this preliminary text (as= this is a DIO option proposal) prior to finalizing the text and submitting= as a draft. Thanks! Randy P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL. This e-mail (including any attachments) is confidential and may be legally = privileged. If you are not an intended recipient or an authorized represent= ative of an intended recipient, you are prohibited from using, copying or d= istributing the information in this e-mail or its attachments. If you have = received this e-mail in error, please notify the sender immediately by retu= rn e-mail and delete all copies of this message and any attachments. Thank = you. --_000_DB5PR01MB10801FA4759E5D4CA856F8C780440DB5PR01MB1080eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Pascal,

 

It was not my intention to leave out the lifetime va= lue…just a cut and paste error on my part – the lifetime value = will be added to this document…I wanted this option to semantically b= e the same as the 6775 version, including lifecycle management.

 

I was definitely going to provide some text as to wh= en this option might be disseminated – under what circumstances (woul= d it be solicited, or periodically sent) basically under what conditions a = non-root node might be expected to receive the option.

 

Thanks!
Randy

 

 

Re: [Roll] DIO option for compression context

"Pascal Thubert (pthubert)" <pthubert@c= isco.com> Wed, 23 September 2015 16:19 UTCShow header

Hello Randy:

 

This is good work and I think it needs to be pursued=

 

I see that you omitted the lifetime in the option (c= omparing to RFC 6775). Why is this so?

 

Section 5 should mention that the option is propagat= ed as is. If it is not needed in all DIOs then you could indicate when to s= end it. This could be for instance trickled upon a change and placed in res= ponses to DIS messages.

 

Cheers,

 

Pascal

 

From: Roll [mailto:roll-bounces@ietf.org] On Behalf = Of Turner, Randy

Sent: mercredi 23 septembre 2015 15:58

To: roll@ietf.org

Subject: [Roll] DIO option for compression context

 

Hello All,

 

At the Prague plenary, during the 6lo session, a num= ber of ROLL participants suggested that a multicast DIO option might be bet= ter suited for dissemination of RFC 6282 compression context information as= an alternative to RFC 6775 - rather than use DHCPv6 for values that are not "node-specific" but appl= y to all nodes on the network.

 

The attached document re-states the option in the fo= rm of a DIO option and references RFC 6775 section 7.2 for context lifecycl= e management.

 

This document would be categorized as experimental.<= o:p>

 

I was looking for comments from the ROLL group on th= is preliminary text (as this is a DIO option proposal) prior to finalizing = the text and submitting as a draft.

 

Thanks!

Randy

 

 


P PLEA= SE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL.

This e-mail (including any attachments) is con= fidential and may be legally privileged. If you are not an intended recipie= nt or an authorized representative of an intended recipient, you are prohib= ited from using, copying or distributing the information in this e-mail or its attachments. If you have received th= is e-mail in error, please notify the sender immediately by return e-mail a= nd delete all copies of this message and any attachments. Thank you.

--_000_DB5PR01MB10801FA4759E5D4CA856F8C780440DB5PR01MB1080eurp_-- From nobody Wed Sep 23 14:26:20 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F17171B2E4B for ; Wed, 23 Sep 2015 14:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TNTIGpOMyxCj for ; Wed, 23 Sep 2015 14:26:17 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 720E51B2E46 for ; Wed, 23 Sep 2015 14:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t8NLQ8bt002863; Wed, 23 Sep 2015 23:26:08 +0200 (CEST) Received: from alma.local (p5DCCDB06.dip0.t-ipconnect.de [93.204.219.6]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3nLsxq4srjz4q6g; Wed, 23 Sep 2015 23:26:07 +0200 (CEST) Message-ID: <560318EE.5050509@tzi.org> Date: Wed, 23 Sep 2015 23:26:06 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.4 (Macintosh/20150825) MIME-Version: 1.0 To: Routing Over Low power and Lossy networks References: In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Roll] DIO compression option X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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 Sep 2015 21:26:19 -0000 I'm not sure I understand the approach. 6CO already is an option. What is wrong with adding this to other random ICMP messages (such as DIOs)? Why do we need a new option option to say the same thing? (Yes, you still would need to discuss any damage to the semantics, e.g., considering section 7.2 of RFC 6775, but that is true in any case.) Maybe I should read the document. (I also would like to see a resolution of the question whether ROLL is now planning to officially replace RFC 6775 for all intents and purposes. We could have done that but didn't. Was there a point? But that is maybe a separate question.) Grüße, Carsten PS.: Yes, *anything* is better than using DHCP for this. Turner, Randy wrote: > Hi Pascal, > > > > It was not my intention to leave out the lifetime value…just a cut and > paste error on my part – the lifetime value will be added to this > document…I wanted this option to semantically be the same as the 6775 > version, including lifecycle management. > > > > I was definitely going to provide some text as to when this option might > be disseminated – under what circumstances (would it be solicited, or > periodically sent) basically under what conditions a non-root node might > be expected to receive the option. > > > > Thanks! > Randy > > > > > > Re: [Roll] DIO option for compression context > > "Pascal Thubert (pthubert)" Wed, 23 September 2015 > 16:19 UTCShow header > > Hello Randy: > > > > This is good work and I think it needs to be pursued > > > > I see that you omitted the lifetime in the option (comparing to RFC > 6775). Why is this so? > > > > Section 5 should mention that the option is propagated as is. If it is > not needed in all DIOs then you could indicate when to send it. This > could be for instance trickled upon a change and placed in responses to > DIS messages. > > > > Cheers, > > > > Pascal > > > > From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Turner, Randy > > Sent: mercredi 23 septembre 2015 15:58 > > To: roll@ietf.org > > Subject: [Roll] DIO option for compression context > > > > Hello All, > > > > At the Prague plenary, during the 6lo session, a number of ROLL > participants suggested that a multicast DIO option might be better > suited for dissemination of RFC 6282 compression context information as > an alternative to RFC 6775 - rather than use DHCPv6 for values that are > not "node-specific" but apply to all nodes on the network. > > > > The attached document re-states the option in the form of a DIO option > and references RFC 6775 section 7.2 for context lifecycle management. > > > > This document would be categorized as experimental. > > > > I was looking for comments from the ROLL group on this preliminary text > (as this is a DIO option proposal) prior to finalizing the text and > submitting as a draft. > > > > Thanks! > > Randy > > > > > > > P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL. > > This e-mail (including any attachments) is confidential and may be > legally privileged. If you are not an intended recipient or an > authorized representative of an intended recipient, you are prohibited > from using, copying or distributing the information in this e-mail or > its attachments. If you have received this e-mail in error, please > notify the sender immediately by return e-mail and delete all copies of > this message and any attachments. Thank you. > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Thu Sep 24 07:14:13 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 394C61A1B4E for ; Thu, 24 Sep 2015 07:14:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9xMjyEIGk4my for ; Thu, 24 Sep 2015 07:14:05 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0727.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::727]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E18161A1A7D for ; Thu, 24 Sep 2015 07:14:04 -0700 (PDT) Received: from HE1PR01MB1083.eurprd01.prod.exchangelabs.com (10.162.182.141) by HE1PR01MB1083.eurprd01.prod.exchangelabs.com (10.162.182.141) with Microsoft SMTP Server (TLS) id 15.1.274.16; Thu, 24 Sep 2015 14:13:47 +0000 Received: from HE1PR01MB1083.eurprd01.prod.exchangelabs.com ([10.162.182.141]) by HE1PR01MB1083.eurprd01.prod.exchangelabs.com ([10.162.182.141]) with mapi id 15.01.0274.009; Thu, 24 Sep 2015 14:13:47 +0000 From: "Turner, Randy" To: "Carsten Bormann (cabo@tzi.org)" Thread-Topic: Re: [Roll] DIO compression option Thread-Index: AdD20GwWJKD5+6eZTKe0Z7enVAjOiA== Date: Thu, 24 Sep 2015 14:13:46 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Randy.Turner@landisgyr.com; x-originating-ip: [148.80.255.216] x-microsoft-exchange-diagnostics: 1; HE1PR01MB1083; 5:Ptl3A/r6d2wUattR67L1YBVYNZQ3r+fnBnpzChAYKAbAD3/mayuAcuVbRdvbhwa9GieVld8JLkvDVXRJZUuFdcyVYKKN8tSZZ70E1HyP2snWltiVjQyYveGM/ZsGMOSJru0y4925yiYNyq8iOv3How==; 24:3xlWZUABAgoMiGKOP0NSl9a/+nqvvgGW7yP+9Zas//ZZ9iX6r0LyKhS664oWpiLhrG6E5WLRNZ4vBcGNQ763scuO5QG55JQwih+8lXx+pK0=; 20:kR7SYrwyKXsYRS7JyVcptRU4yCyE0RBhuDlBvTL9CwzzisjSlYkwyjpa/JmRZS8r0kXiJypV1Wx0p6sV3kUcWg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR01MB1083; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014)(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(3002001); SRVR:HE1PR01MB1083; BCL:0; PCL:0; RULEID:; SRVR:HE1PR01MB1083; x-forefront-prvs: 070912876F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(57704003)(53754006)(24454002)(126464002)(62966003)(2900100001)(5003600100002)(33656002)(50986999)(19580395003)(87936001)(40100003)(86362001)(122556002)(106356001)(19300405004)(101416001)(54356999)(16236675004)(19625215002)(110136002)(77156002)(5890100001)(561944003)(15975445007)(74316001)(5001860100001)(11100500001)(92566002)(77096005)(19580405001)(46102003)(5007970100001)(189998001)(64706001)(4001540100001)(5004730100002)(81156007)(10400500002)(105586002)(7520500002)(5001960100002)(68736005)(5002640100001)(97736004)(102836002)(5001830100001)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR01MB1083; H:HE1PR01MB1083.eurprd01.prod.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: landisgyr.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_HE1PR01MB1083E7CE4CB5C8A69E2E23E580430HE1PR01MB1083eurp_" MIME-Version: 1.0 X-OriginatorOrg: landisgyr.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Sep 2015 14:13:46.8910 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: ee2cd48b-958f-4be4-9852-b8f104c001b9 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR01MB1083 Archived-At: Cc: "roll@ietf.org" Subject: Re: [Roll] DIO compression option X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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, 24 Sep 2015 14:14:10 -0000 --_000_HE1PR01MB1083E7CE4CB5C8A69E2E23E580430HE1PR01MB1083eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes, I mentioned this in Prague (the fact that 6775 6CO already exists). T= he Zigbee NAN group decided that the additional traffic imposed by neighbor= discovery was not required (in the presence of DIO and DIO options) - howe= ver, we still would like to receive compression options, and we've already = paid the DIO price traffic-wise, so we're piggy backing the compression opt= ion onto DIOs we're already handling. I'm trying to maintain the context lifecycles per 6775, so the existing tex= t will be modified to include the "lifetime" field in the option (the "C" b= it already exists) Randy Re: [Roll] DIO compression option Carsten Bormann Wed, 23 September 2015 21:26 UTCShow header I'm not sure I understand the approach. 6CO already is an option. What is wrong with adding this to other random ICMP messages (such as DIOs)? Why do we need a new option option to say the same thing? (Yes, you still would need to discuss any damage to the semantics, e.g., considering section 7.2 of RFC 6775, but that is true in any case.) Maybe I should read the document. (I also would like to see a resolution of the question whether ROLL is now planning to officially replace RFC 6775 for all intents and purposes. We could have done that but didn't. Was there a point? But that is maybe a separate question.) Gr=FC=DFe, Carsten PS.: Yes, *anything* is better than using DHCP for this. Turner, Randy wrote: > Hi Pascal, > > > > It was not my intention to leave out the lifetime value...just a cut and > paste error on my part - the lifetime value will be added to this > document...I wanted this option to semantically be the same as the 6775 > version, including lifecycle management. > > > > I was definitely going to provide some text as to when this option might > be disseminated - under what circumstances (would it be solicited, or > periodically sent) basically under what conditions a non-root node might > be expected to receive the option. > > > > Thanks! > Randy > > > > > > Re: [Roll] DIO option for compression context > > "Pascal Thubert (pthubert)" Wed, 23 September 2015 > 16:19 UTCShow header > > Hello Randy: > > > > This is good work and I think it needs to be pursued > > > > I see that you omitted the lifetime in the option (comparing to RFC > 6775). Why is this so? > > > > Section 5 should mention that the option is propagated as is. If it is > not needed in all DIOs then you could indicate when to send it. This > could be for instance trickled upon a change and placed in responses to > DIS messages. > > > > Cheers, > > > > Pascal > > > > From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Turner, Randy > > Sent: mercredi 23 septembre 2015 15:58 > > To: roll@ietf.org > > Subject: [Roll] DIO option for compression context > > > > Hello All, > > > > At the Prague plenary, during the 6lo session, a number of ROLL > participants suggested that a multicast DIO option might be better > suited for dissemination of RFC 6282 compression context information as > an alternative to RFC 6775 - rather than use DHCPv6 for values that are > not "node-specific" but apply to all nodes on the network. > > > > The attached document re-states the option in the form of a DIO option > and references RFC 6775 section 7.2 for context lifecycle management. > > > > This document would be categorized as experimental. > > > > I was looking for comments from the ROLL group on this preliminary text > (as this is a DIO option proposal) prior to finalizing the text and > submitting as a draft. > > > > Thanks! > > Randy > P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL. This e-mail (including any attachments) is confidential and may be legally = privileged. If you are not an intended recipient or an authorized represent= ative of an intended recipient, you are prohibited from using, copying or d= istributing the information in this e-mail or its attachments. If you have = received this e-mail in error, please notify the sender immediately by retu= rn e-mail and delete all copies of this message and any attachments. Thank = you. --_000_HE1PR01MB1083E7CE4CB5C8A69E2E23E580430HE1PR01MB1083eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Yes, I mentioned this in Prague (the fact that 6775 = 6CO already exists).  The Zigbee NAN group decided that the additional= traffic imposed by neighbor discovery was not required (in the presence of= DIO and DIO options) – however, we still would like to receive compression options, and we’ve already paid th= e DIO price traffic-wise, so we’re piggy backing the compression opti= on onto DIOs we’re already handling.

 

I’m trying to maintain the context lifecycles = per 6775, so the existing text will be modified to include the “lifet= ime” field in the option (the “C” bit already exists)

 

Randy

 

 

 

 

Re: [Roll] DIO compression option

Carsten Bormann <cabo@tzi.org> Wed, 23 Septemb= er 2015 21:26 UTCShow header

I'm not sure I understand the approach.

 

6CO already is an option.

 

What is wrong with adding this to other random ICMP = messages (such as

DIOs)?  Why do we need a new option option to s= ay the same thing?

(Yes, you still would need to discuss any damage to = the semantics, e.g.,

considering section 7.2 of RFC 6775, but that is tru= e in any case.)

 

Maybe I should read the document.

 

(I also would like to see a resolution of the questi= on whether ROLL is

now planning to officially replace RFC 6775 for all = intents and

purposes.  We could have done that but didn't.&= nbsp;  Was there a point?

But that is maybe a separate question.)

 

Gr=FC=DFe, Carsten

 

PS.: Yes, *anything* is better than using DHCP for t= his.

 

 

Turner, Randy wrote:

> Hi Pascal,

>

> 

>

> It was not my intention to leave out the lifeti= me value…just a cut and

> paste error on my part – the lifetime val= ue will be added to this

> document…I wanted this option to semantic= ally be the same as the 6775

> version, including lifecycle management.

>

> 

>

> I was definitely going to provide some text as = to when this option might

> be disseminated – under what circumstance= s (would it be solicited, or

> periodically sent) basically under what conditi= ons a non-root node might

> be expected to receive the option.

>

> 

>

> Thanks!

> Randy

>

> 

>

> 

>

> Re: [Roll] DIO option for compression context

>

> "Pascal Thubert (pthubert)" <pthub= ert@cisco.com> Wed, 23 September 2015

> 16:19 UTCShow header

>

> Hello Randy:

>

> 

>

> This is good work and I think it needs to be pu= rsued

>

> 

>

> I see that you omitted the lifetime in the opti= on (comparing to RFC

> 6775). Why is this so?

>

> 

>

> Section 5 should mention that the option is pro= pagated as is. If it is

> not needed in all DIOs then you could indicate = when to send it. This

> could be for instance trickled upon a change an= d placed in responses to

> DIS messages.

>

> 

>

> Cheers,

>

> 

>

> Pascal

>

> 

>

> From: Roll [mailto:roll-bounces@ietf.org] On Be= half Of Turner, Randy

>

> Sent: mercredi 23 septembre 2015 15:58

>

> To: roll@ietf.org

>

> Subject: [Roll] DIO option for compression cont= ext

>

> 

>

> Hello All,

>

> 

>

> At the Prague plenary, during the 6lo session, = a number of ROLL

> participants suggested that a multicast DIO opt= ion might be better

> suited for dissemination of RFC 6282 compressio= n context information as

> an alternative to RFC 6775 - rather than use DH= CPv6 for values that are

> not "node-specific" but apply to all = nodes on the network.

>

> 

>

> The attached document re-states the option in t= he form of a DIO option

> and references RFC 6775 section 7.2 for context= lifecycle management.

>

> 

>

> This document would be categorized as experimen= tal.

>

> 

>

> I was looking for comments from the ROLL group = on this preliminary text

> (as this is a DIO option proposal) prior to fin= alizing the text and

> submitting as a draft.

>

> 

>

> Thanks!

>

> Randy

> 

 


P PLEA= SE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL.

This e-mail (including any attachments) is con= fidential and may be legally privileged. If you are not an intended recipie= nt or an authorized representative of an intended recipient, you are prohib= ited from using, copying or distributing the information in this e-mail or its attachments. If you have received th= is e-mail in error, please notify the sender immediately by return e-mail a= nd delete all copies of this message and any attachments. Thank you.

--_000_HE1PR01MB1083E7CE4CB5C8A69E2E23E580430HE1PR01MB1083eurp_-- From nobody Thu Sep 24 07:45:29 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 642571A1B7C for ; Thu, 24 Sep 2015 07:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AzS4KqYi_Ovo for ; Thu, 24 Sep 2015 07:45:26 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2D7C1A1B76 for ; Thu, 24 Sep 2015 07:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t8OEjMrw012615; Thu, 24 Sep 2015 16:45:22 +0200 (CEST) Received: from alma.local (eduroam-pool7-0876.wlan.uni-bremen.de [134.102.115.108]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3nMK0y1bJpz4pbJ; Thu, 24 Sep 2015 16:45:22 +0200 (CEST) Message-ID: <56040C7F.50401@tzi.org> Date: Thu, 24 Sep 2015 16:45:19 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.4 (Macintosh/20150825) MIME-Version: 1.0 To: "Turner, Randy" References: In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "roll@ietf.org" Subject: Re: [Roll] DIO compression option X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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, 24 Sep 2015 14:45:27 -0000 > Yes, I mentioned this in Prague (the fact that 6775 6CO already exists). > The Zigbee NAN group decided that the additional traffic imposed by > neighbor discovery was not required (in the presence of DIO and DIO > options) – however, we still would like to receive compression options, > and we’ve already paid the DIO price traffic-wise, so we’re piggy > backing the compression option onto DIOs we’re already handling. > > > > I’m trying to maintain the context lifecycles per 6775, so the existing > text will be modified to include the “lifetime” field in the option (the > “C” bit already exists) So is the observation fair that this is essentially about repackaging 6CO into the syntactic environment of a ROLL message? I think we could do that for the rest of the 6Lo-ND messages as well and reduce the cognitive dissonance of sending ND information with ROLL messages. Grüße, Carsten From nobody Thu Sep 24 08:02:47 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 885E41A6EED for ; Thu, 24 Sep 2015 08:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JZid4puybJeh for ; Thu, 24 Sep 2015 08:02:43 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D7D91AD34D for ; Thu, 24 Sep 2015 08:02:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6372; q=dns/txt; s=iport; t=1443106965; x=1444316565; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=8RkkdatvzDtYHpLkgCae6WesOjzcQsxG2ncsS56MFQI=; b=N0ZHj2OF2H36dmXW2v2t8PYP1Xkz2nKs5BioPEye0mrlV0F1ni4TtEgE QNV3oPx0Ifkgb/jGc4a4R0S4ziscSydFDeIKkCKaoUy+ZonHyA87m9Jyu LuL1vVYJJSEiWXgo5viAVF6d0GJvsysZv5vxN6jBNUHP9CJdLQRXcqrIl Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AQAgBTDwRW/49dJa1dgyRUaQaDJLoZAQ2BcAqFeQIcgSk4FAEBAQEBAQGBCoQkAQEBBAEBASAROhcEAgEGAg4DBAEBAQICIwMCAgIlCxQBCAgBAQQBEgiIJg2aOp0rlDQBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIEihVGEfYQqEQECVgaCY4FDBZVnAY0GgVOENoMhkgMBHwEBQoIOH4FUcYgtOoEFAQEB X-IronPort-AV: E=Sophos;i="5.17,581,1437436800"; d="scan'208";a="191393577" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Sep 2015 15:02:43 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t8OF2fYQ015783 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 24 Sep 2015 15:02:41 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 24 Sep 2015 10:02:41 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1104.000; Thu, 24 Sep 2015 10:02:38 -0500 From: "Pascal Thubert (pthubert)" To: Carsten Bormann , Routing Over Low power and Lossy networks Thread-Topic: [Roll] DIO compression option Thread-Index: AdD2IbYxqzl6YbyQR+67lzbuc7ttTgATqdYAABoi6mA= Date: Thu, 24 Sep 2015 15:02:31 +0000 Deferred-Delivery: Thu, 24 Sep 2015 15:01:41 +0000 Message-ID: References: <560318EE.5050509@tzi.org> In-Reply-To: <560318EE.5050509@tzi.org> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.169.2] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] DIO compression option X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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, 24 Sep 2015 15:02:45 -0000 SGVsbG8gQ2Fyc3Rlbg0KDQpGb3IgdGhlIGJldHRlciBhbmQgdGhlIHdvcnN0LCBSUEwgZGVjaWRl ZCB0byBhdm9pZCBJUHY2IE5EIGFsaWdubWVudHM7IFJQTCBleHByZXNzZXMgdGhlIGxlbmd0aCBp biBieXRlcy4gDQoNClNvIGEgbnVtYmVyIG9mIG9wdGlvbnMgYXJlIGp1c3QgcmVkZWZpbmVkIGlu IFJGQyA2NTUwIHRvIGVjaG8gdGhlIE5EIGRyYWZ0cy4gVGhlIDZDTyBpcyBjbGVhcmx5IG1pc3Np bmcsIGZvciBoaXN0b3JpY2FsIHJlYXNvbnMuIE90aGVycyBzdWNoIGFzIFNMTEFPIHdvdWxkIGJl IGNsZWFybHkgdXNlZnVsIGFzIHdlbGwuIEFuZCAgTVRVIHdoZW4gd2UgYnVpbGQgaGV0ZXJvZ2Vu ZW91cyBuZXR3b3Jrcy4uLg0KDQpDaGVlcnMsDQoNClBhc2NhbA0KDQo+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+IEZyb206IENhcnN0ZW4gQm9ybWFubiBbbWFpbHRvOmNhYm9AdHppLm9y Z10NCj4gU2VudDogbWVyY3JlZGkgMjMgc2VwdGVtYnJlIDIwMTUgMjM6MjYNCj4gVG86IFJvdXRp bmcgT3ZlciBMb3cgcG93ZXIgYW5kIExvc3N5IG5ldHdvcmtzIDxyb2xsQGlldGYub3JnPg0KPiBD YzogUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KSA8cHRodWJlcnRAY2lzY28uY29tPg0KPiBTdWJq ZWN0OiBSZTogW1JvbGxdIERJTyBjb21wcmVzc2lvbiBvcHRpb24NCj4gDQo+IEknbSBub3Qgc3Vy ZSBJIHVuZGVyc3RhbmQgdGhlIGFwcHJvYWNoLg0KPiANCj4gNkNPIGFscmVhZHkgaXMgYW4gb3B0 aW9uLg0KPiANCj4gV2hhdCBpcyB3cm9uZyB3aXRoIGFkZGluZyB0aGlzIHRvIG90aGVyIHJhbmRv bSBJQ01QIG1lc3NhZ2VzIChzdWNoIGFzDQo+IERJT3MpPyAgV2h5IGRvIHdlIG5lZWQgYSBuZXcg b3B0aW9uIG9wdGlvbiB0byBzYXkgdGhlIHNhbWUgdGhpbmc/DQo+IChZZXMsIHlvdSBzdGlsbCB3 b3VsZCBuZWVkIHRvIGRpc2N1c3MgYW55IGRhbWFnZSB0byB0aGUgc2VtYW50aWNzLCBlLmcuLA0K PiBjb25zaWRlcmluZyBzZWN0aW9uIDcuMiBvZiBSRkMgNjc3NSwgYnV0IHRoYXQgaXMgdHJ1ZSBp biBhbnkgY2FzZS4pDQo+IA0KPiBNYXliZSBJIHNob3VsZCByZWFkIHRoZSBkb2N1bWVudC4NCj4g DQo+IChJIGFsc28gd291bGQgbGlrZSB0byBzZWUgYSByZXNvbHV0aW9uIG9mIHRoZSBxdWVzdGlv biB3aGV0aGVyIFJPTEwgaXMgbm93DQo+IHBsYW5uaW5nIHRvIG9mZmljaWFsbHkgcmVwbGFjZSBS RkMgNjc3NSBmb3IgYWxsIGludGVudHMgYW5kDQo+IHB1cnBvc2VzLiAgV2UgY291bGQgaGF2ZSBk b25lIHRoYXQgYnV0IGRpZG4ndC4gICBXYXMgdGhlcmUgYSBwb2ludD8NCj4gQnV0IHRoYXQgaXMg bWF5YmUgYSBzZXBhcmF0ZSBxdWVzdGlvbi4pDQo+IA0KPiBHcsO8w59lLCBDYXJzdGVuDQo+IA0K PiBQUy46IFllcywgKmFueXRoaW5nKiBpcyBiZXR0ZXIgdGhhbiB1c2luZyBESENQIGZvciB0aGlz Lg0KPiANCj4gDQo+IFR1cm5lciwgUmFuZHkgd3JvdGU6DQo+ID4gSGkgUGFzY2FsLA0KPiA+DQo+ ID4NCj4gPg0KPiA+IEl0IHdhcyBub3QgbXkgaW50ZW50aW9uIHRvIGxlYXZlIG91dCB0aGUgbGlm ZXRpbWUgdmFsdWXigKZqdXN0IGEgY3V0IGFuZA0KPiA+IHBhc3RlIGVycm9yIG9uIG15IHBhcnQg 4oCTIHRoZSBsaWZldGltZSB2YWx1ZSB3aWxsIGJlIGFkZGVkIHRvIHRoaXMNCj4gPiBkb2N1bWVu dOKApkkgd2FudGVkIHRoaXMgb3B0aW9uIHRvIHNlbWFudGljYWxseSBiZSB0aGUgc2FtZSBhcyB0 aGUgNjc3NQ0KPiA+IHZlcnNpb24sIGluY2x1ZGluZyBsaWZlY3ljbGUgbWFuYWdlbWVudC4NCj4g Pg0KPiA+DQo+ID4NCj4gPiBJIHdhcyBkZWZpbml0ZWx5IGdvaW5nIHRvIHByb3ZpZGUgc29tZSB0 ZXh0IGFzIHRvIHdoZW4gdGhpcyBvcHRpb24NCj4gPiBtaWdodCBiZSBkaXNzZW1pbmF0ZWQg4oCT IHVuZGVyIHdoYXQgY2lyY3Vtc3RhbmNlcyAod291bGQgaXQgYmUNCj4gPiBzb2xpY2l0ZWQsIG9y IHBlcmlvZGljYWxseSBzZW50KSBiYXNpY2FsbHkgdW5kZXIgd2hhdCBjb25kaXRpb25zIGENCj4g PiBub24tcm9vdCBub2RlIG1pZ2h0IGJlIGV4cGVjdGVkIHRvIHJlY2VpdmUgdGhlIG9wdGlvbi4N Cj4gPg0KPiA+DQo+ID4NCj4gPiBUaGFua3MhDQo+ID4gUmFuZHkNCj4gPg0KPiA+DQo+ID4NCj4g Pg0KPiA+DQo+ID4gUmU6IFtSb2xsXSBESU8gb3B0aW9uIGZvciBjb21wcmVzc2lvbiBjb250ZXh0 DQo+ID4NCj4gPiAiUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KSIgPHB0aHViZXJ0QGNpc2NvLmNv bT4gV2VkLCAyMyBTZXB0ZW1iZXINCj4gPiAyMDE1DQo+ID4gMTY6MTkgVVRDU2hvdyBoZWFkZXIN Cj4gPg0KPiA+IEhlbGxvIFJhbmR5Og0KPiA+DQo+ID4NCj4gPg0KPiA+IFRoaXMgaXMgZ29vZCB3 b3JrIGFuZCBJIHRoaW5rIGl0IG5lZWRzIHRvIGJlIHB1cnN1ZWQNCj4gPg0KPiA+DQo+ID4NCj4g PiBJIHNlZSB0aGF0IHlvdSBvbWl0dGVkIHRoZSBsaWZldGltZSBpbiB0aGUgb3B0aW9uIChjb21w YXJpbmcgdG8gUkZDDQo+ID4gNjc3NSkuIFdoeSBpcyB0aGlzIHNvPw0KPiA+DQo+ID4NCj4gPg0K PiA+IFNlY3Rpb24gNSBzaG91bGQgbWVudGlvbiB0aGF0IHRoZSBvcHRpb24gaXMgcHJvcGFnYXRl ZCBhcyBpcy4gSWYgaXQgaXMNCj4gPiBub3QgbmVlZGVkIGluIGFsbCBESU9zIHRoZW4geW91IGNv dWxkIGluZGljYXRlIHdoZW4gdG8gc2VuZCBpdC4gVGhpcw0KPiA+IGNvdWxkIGJlIGZvciBpbnN0 YW5jZSB0cmlja2xlZCB1cG9uIGEgY2hhbmdlIGFuZCBwbGFjZWQgaW4gcmVzcG9uc2VzDQo+ID4g dG8gRElTIG1lc3NhZ2VzLg0KPiA+DQo+ID4NCj4gPg0KPiA+IENoZWVycywNCj4gPg0KPiA+DQo+ ID4NCj4gPiBQYXNjYWwNCj4gPg0KPiA+DQo+ID4NCj4gPiBGcm9tOiBSb2xsIFttYWlsdG86cm9s bC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgVHVybmVyLCBSYW5keQ0KPiA+DQo+ID4g U2VudDogbWVyY3JlZGkgMjMgc2VwdGVtYnJlIDIwMTUgMTU6NTgNCj4gPg0KPiA+IFRvOiByb2xs QGlldGYub3JnDQo+ID4NCj4gPiBTdWJqZWN0OiBbUm9sbF0gRElPIG9wdGlvbiBmb3IgY29tcHJl c3Npb24gY29udGV4dA0KPiA+DQo+ID4NCj4gPg0KPiA+IEhlbGxvIEFsbCwNCj4gPg0KPiA+DQo+ ID4NCj4gPiBBdCB0aGUgUHJhZ3VlIHBsZW5hcnksIGR1cmluZyB0aGUgNmxvIHNlc3Npb24sIGEg bnVtYmVyIG9mIFJPTEwNCj4gPiBwYXJ0aWNpcGFudHMgc3VnZ2VzdGVkIHRoYXQgYSBtdWx0aWNh c3QgRElPIG9wdGlvbiBtaWdodCBiZSBiZXR0ZXINCj4gPiBzdWl0ZWQgZm9yIGRpc3NlbWluYXRp b24gb2YgUkZDIDYyODIgY29tcHJlc3Npb24gY29udGV4dCBpbmZvcm1hdGlvbg0KPiA+IGFzIGFu IGFsdGVybmF0aXZlIHRvIFJGQyA2Nzc1IC0gcmF0aGVyIHRoYW4gdXNlIERIQ1B2NiBmb3IgdmFs dWVzIHRoYXQNCj4gPiBhcmUgbm90ICJub2RlLXNwZWNpZmljIiBidXQgYXBwbHkgdG8gYWxsIG5v ZGVzIG9uIHRoZSBuZXR3b3JrLg0KPiA+DQo+ID4NCj4gPg0KPiA+IFRoZSBhdHRhY2hlZCBkb2N1 bWVudCByZS1zdGF0ZXMgdGhlIG9wdGlvbiBpbiB0aGUgZm9ybSBvZiBhIERJTyBvcHRpb24NCj4g PiBhbmQgcmVmZXJlbmNlcyBSRkMgNjc3NSBzZWN0aW9uIDcuMiBmb3IgY29udGV4dCBsaWZlY3lj bGUgbWFuYWdlbWVudC4NCj4gPg0KPiA+DQo+ID4NCj4gPiBUaGlzIGRvY3VtZW50IHdvdWxkIGJl IGNhdGVnb3JpemVkIGFzIGV4cGVyaW1lbnRhbC4NCj4gPg0KPiA+DQo+ID4NCj4gPiBJIHdhcyBs b29raW5nIGZvciBjb21tZW50cyBmcm9tIHRoZSBST0xMIGdyb3VwIG9uIHRoaXMgcHJlbGltaW5h cnkNCj4gPiB0ZXh0IChhcyB0aGlzIGlzIGEgRElPIG9wdGlvbiBwcm9wb3NhbCkgcHJpb3IgdG8g ZmluYWxpemluZyB0aGUgdGV4dA0KPiA+IGFuZCBzdWJtaXR0aW5nIGFzIGEgZHJhZnQuDQo+ID4N Cj4gPg0KPiA+DQo+ID4gVGhhbmtzIQ0KPiA+DQo+ID4gUmFuZHkNCj4gPg0KPiA+DQo+ID4NCj4g Pg0KPiA+DQo+ID4NCj4gPiBQIFBMRUFTRSBDT05TSURFUiBPVVIgRU5WSVJPTk1FTlQgQkVGT1JF IFBSSU5USU5HIFRISVMgRU1BSUwuDQo+ID4NCj4gPiBUaGlzIGUtbWFpbCAoaW5jbHVkaW5nIGFu eSBhdHRhY2htZW50cykgaXMgY29uZmlkZW50aWFsIGFuZCBtYXkgYmUNCj4gPiBsZWdhbGx5IHBy aXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCBvciBhbg0KPiA+ IGF1dGhvcml6ZWQgcmVwcmVzZW50YXRpdmUgb2YgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCB5b3Ug YXJlIHByb2hpYml0ZWQNCj4gPiBmcm9tIHVzaW5nLCBjb3B5aW5nIG9yIGRpc3RyaWJ1dGluZyB0 aGUgaW5mb3JtYXRpb24gaW4gdGhpcyBlLW1haWwgb3INCj4gPiBpdHMgYXR0YWNobWVudHMuIElm IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZS1tYWlsIGluIGVycm9yLCBwbGVhc2UNCj4gPiBub3Rp ZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSByZXR1cm4gZS1tYWlsIGFuZCBkZWxldGUgYWxs IGNvcGllcw0KPiA+IG9mIHRoaXMgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnRzLiBUaGFuayB5 b3UuDQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiA+IFJvbGwgbWFpbGluZyBsaXN0DQo+ID4gUm9sbEBpZXRmLm9yZw0KPiA+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9sbA0K From nobody Thu Sep 24 08:24:39 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9069E1B29A5 for ; Thu, 24 Sep 2015 08:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 782Ok2NNW4su for ; Thu, 24 Sep 2015 08:24:34 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0724.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::724]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C40EB1B29D0 for ; Thu, 24 Sep 2015 08:24:33 -0700 (PDT) Received: from DB5PR01MB1080.eurprd01.prod.exchangelabs.com (10.162.152.142) by DB5PR01MB1078.eurprd01.prod.exchangelabs.com (10.162.152.140) with Microsoft SMTP Server (TLS) id 15.1.280.20; Thu, 24 Sep 2015 15:24:11 +0000 Received: from DB5PR01MB1080.eurprd01.prod.exchangelabs.com ([10.162.152.142]) by DB5PR01MB1080.eurprd01.prod.exchangelabs.com ([10.162.152.142]) with mapi id 15.01.0280.017; Thu, 24 Sep 2015 15:24:11 +0000 From: "Turner, Randy" To: "Carsten Bormann (cabo@tzi.org)" Thread-Topic: DIO compression option Thread-Index: AdD23JVMrXvJt+2MRYStZjw1XFLeTA== Date: Thu, 24 Sep 2015 15:24:11 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Randy.Turner@landisgyr.com; x-originating-ip: [148.80.255.144] x-microsoft-exchange-diagnostics: 1; DB5PR01MB1078; 5:kmHGJ4tIMRcBDx05IGysAPwkuJnCIB2exhuERBZQn/JV2IowcI3JDe0//Fo/VBdoACp0j9r4HIA96yNRQFLnD4fMoeFP1BQ0jjdEtb9XnhRgQYtJqTRXsDqz4OLhtStTHHhD0zKRr9K3n6gUu6x6jQ==; 24:bzXojAgbsyJheBZReJbS95RqxQFHTV73mY/NzF87dpTnojSAYv01xzSPno3+K5C+0ZMzG1qpwqDU1IwiQbrv2Dw7jhBkO1SVTOAF534SfqU=; 20:wubYYpECbkpZXzCGBZQEtaUygi183bEsHHEtundbY0uEU/9pJy3nF+lni/P2MfuM7rsiLOf30kiQqKEUNDdVaQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5PR01MB1078; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001); SRVR:DB5PR01MB1078; BCL:0; PCL:0; RULEID:; SRVR:DB5PR01MB1078; x-forefront-prvs: 070912876F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51444003)(199003)(189002)(229853001)(15975445007)(102836002)(5890100001)(68736005)(77096005)(16236675004)(33656002)(74316001)(81156007)(4001540100001)(97736004)(54356999)(50986999)(5001830100001)(101416001)(92566002)(105586002)(5004730100002)(11100500001)(5007970100001)(106356001)(62966003)(5001960100002)(110136002)(19300405004)(77156002)(2900100001)(189998001)(40100003)(122556002)(5003600100002)(46102003)(5002640100001)(5001860100001)(64706001)(19580405001)(19580395003)(10400500002)(86362001)(66066001)(19625215002)(87936001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR01MB1078; H:DB5PR01MB1080.eurprd01.prod.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: landisgyr.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB5PR01MB1080A57E2591DDB8C45C515280430DB5PR01MB1080eurp_" MIME-Version: 1.0 X-OriginatorOrg: landisgyr.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Sep 2015 15:24:11.2533 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: ee2cd48b-958f-4be4-9852-b8f104c001b9 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR01MB1078 Archived-At: Cc: "roll@ietf.org" Subject: [Roll] DIO compression option X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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, 24 Sep 2015 15:24:38 -0000 --_000_DB5PR01MB1080A57E2591DDB8C45C515280430DB5PR01MB1080eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes, I think that's what I'm doing with the compression context option (syn= tactically recreating it for DIO) - the options' interpretation is identica= l to RFC 6775 - the only difference I can possibly see between the 6775 tex= t and the option I proposed is regarding "when" these options might appear = in DIOs from the root. Randy Re: [Roll] DIO compression option Carsten Bormann Thu, 24 September 2015 14:45 UTCShow header > Yes, I mentioned this in Prague (the fact that 6775 6CO already exists). > The Zigbee NAN group decided that the additional traffic imposed by > neighbor discovery was not required (in the presence of DIO and DIO > options) - however, we still would like to receive compression options, > and we've already paid the DIO price traffic-wise, so we're piggy > backing the compression option onto DIOs we're already handling. > > > > I'm trying to maintain the context lifecycles per 6775, so the existing > text will be modified to include the "lifetime" field in the option (the > "C" bit already exists) So is the observation fair that this is essentially about repackaging 6CO into the syntactic environment of a ROLL message? I think we could do that for the rest of the 6Lo-ND messages as well and reduce the cognitive dissonance of sending ND information with ROLL messages. Gr=FC=DFe, Carsten P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL. This e-mail (including any attachments) is confidential and may be legally = privileged. If you are not an intended recipient or an authorized represent= ative of an intended recipient, you are prohibited from using, copying or d= istributing the information in this e-mail or its attachments. If you have = received this e-mail in error, please notify the sender immediately by retu= rn e-mail and delete all copies of this message and any attachments. Thank = you. --_000_DB5PR01MB1080A57E2591DDB8C45C515280430DB5PR01MB1080eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 

Yes, I think that’s what I’m doing with = the compression context option (syntactically recreating it for DIO) –= ; the options’ interpretation is identical to RFC 6775 – the on= ly difference I can possibly see between the 6775 text and the option I proposed is regarding “when” these options might appear in D= IOs from the root.

 

Randy

 

 

Re: [Roll] DIO compression option

Carsten Bormann <cabo@tzi.org> Thu, 24 Septemb= er 2015 14:45 UTCShow header

> Yes, I mentioned this in Prague (the fact that = 6775 6CO already exists).

>  The Zigbee NAN group decided that the add= itional traffic imposed by

> neighbor discovery was not required (in the pre= sence of DIO and DIO

> options) – however, we still would like t= o receive compression options,

> and we’ve already paid the DIO price traf= fic-wise, so we’re piggy

> backing the compression option onto DIOs weR= 17;re already handling.

>

> 

>

> I’m trying to maintain the context lifecy= cles per 6775, so the existing

> text will be modified to include the “lif= etime” field in the option (the

> “C” bit already exists)<= /p>

 

So is the observation fair that this is essentially = about repackaging

6CO into the syntactic environment of a ROLL message= ?

 

I think we could do that for the rest of the 6Lo-ND = messages as well and

reduce the cognitive dissonance of sending ND inform= ation with ROLL

messages.

 

Gr=FC=DFe, Carsten


P PLEA= SE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL.

This e-mail (including any attachments) is con= fidential and may be legally privileged. If you are not an intended recipie= nt or an authorized representative of an intended recipient, you are prohib= ited from using, copying or distributing the information in this e-mail or its attachments. If you have received th= is e-mail in error, please notify the sender immediately by return e-mail a= nd delete all copies of this message and any attachments. Thank you.

--_000_DB5PR01MB1080A57E2591DDB8C45C515280430DB5PR01MB1080eurp_-- From nobody Thu Sep 24 13:56:00 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 641081B3890 for ; Thu, 24 Sep 2015 13:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N3vN9e12aTud for ; Thu, 24 Sep 2015 13:55:56 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7E7A1B3875 for ; Thu, 24 Sep 2015 13:55:55 -0700 (PDT) Received: by wiclk2 with SMTP id lk2so45445696wic.0 for ; Thu, 24 Sep 2015 13:55:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type; bh=zJl6YNq6pkclmE5PTm8GANL+VXASc4sZe90L9d9H3ok=; b=FlX/mKeNSL0fFGJRnGmiVNIja5tVUGOqUAvPJEQyBkXAkqzxIp/A62T9z5zNPLU/oN C1wqyorj80Gdo3QaJckTDcvwUboOON/feazFAbFEngN6M03jGJ/duOr9M8rK3lgtxctE XT+v2TKdgyoW3S9Pv8TGzZmJYlNFSqnfrdko8yap7usqE0CiRRHo2jpNuR56Fu564jhF y99sQuGQ7a7d0HdUAnTtIA/0zi5iTbm6k9PXejBKu7bWDeJbyfv8yQh91dUPW5v1E/jr acpOWKb581RVsHm45YAKqKDpst8t9ICjfaD8GWrspKrlIvNc3hTUXgYDV6z8CCXLcXfE Fv9w== X-Received: by 10.194.205.68 with SMTP id le4mr2170883wjc.74.1443128154430; Thu, 24 Sep 2015 13:55:54 -0700 (PDT) Received: from ?IPv6:2a02:8109:9ac0:a94:221:ccff:fe67:d847? ([2a02:8109:9ac0:a94:221:ccff:fe67:d847]) by smtp.googlemail.com with ESMTPSA id ki7sm130066wjc.28.2015.09.24.13.55.53 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 24 Sep 2015 13:55:53 -0700 (PDT) To: roll@ietf.org References: From: =?UTF-8?Q?Cenk_G=c3=bcndogan?= Message-ID: <56046359.4070202@gmail.com> Date: Thu, 24 Sep 2015 22:55:53 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------030702020606030109090202" Archived-At: Subject: Re: [Roll] DIO compression option X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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, 24 Sep 2015 20:55:58 -0000 This is a multi-part message in MIME format. --------------030702020606030109090202 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hello Carsten, Pascal, Randy, * I like the idea of having the 6CO included into RPL, simply because it already includes the PIO and there is no RPL-ish way to tag any prefix information with context identifiers in 6LoWPANs. Hence, and that is just my opinion, it is not desired, but a necessity to add the 6CO to RPL's known options list. Also: RFC 6775#1.4 clearly states that in order to substitute multihop prefix distribution, it is also necessary to substitute the distribution of header compression contexts. To quote RFC 6775 "... [they] go hand in hand." With this quote in mind, adding the 6CO to RPL and using them (PIO + 6CO) in DIOs could be the first step in dropping the ABRO overhead in RA messages when using RPL in a 6LoWPAN. Currently, running RPL and 6LoWPAN-ND simultaneously would require to handle the versioning of DODAGs (by DODAG root) and the versioning of ABRO related information (PIO + 6CO) (by 6LBR). Without looking too much into details, and please correct me if I am wrong, but: The ABRO and the DIO seem to have a few similarities. Both have versioning and both have a concept of an "origin" (DODAG-ID <-> 6LBR Address). So, wouldn't it be possible to abandon the ABRO in RPL domains where RPL also controls the PIOs and 6COs ? Cheers, Cenk On 24.09.2015 17:24, Turner, Randy wrote: > > Yes, I think that’s what I’m doing with the compression context option > (syntactically recreating it for DIO) – the options’ interpretation is > identical to RFC 6775 – the only difference I can possibly see between > the 6775 text and the option I proposed is regarding “when” these > options might appear in DIOs from the root. > > Randy > > Re: [Roll] DIO compression option > > Carsten Bormann Thu, 24 September 2015 14:45 UTCShow header > > > Yes, I mentioned this in Prague (the fact that 6775 6CO already exists). > > > The Zigbee NAN group decided that the additional traffic imposed by > > > neighbor discovery was not required (in the presence of DIO and DIO > > > options) – however, we still would like to receive compression options, > > > and we’ve already paid the DIO price traffic-wise, so we’re piggy > > > backing the compression option onto DIOs we’re already handling. > > > > > > > > > > > > I’m trying to maintain the context lifecycles per 6775, so the existing > > > text will be modified to include the “lifetime” field in the option (the > > > “C” bit already exists) > > So is the observation fair that this is essentially about repackaging > > 6CO into the syntactic environment of a ROLL message? > > I think we could do that for the rest of the 6Lo-ND messages as well and > > reduce the cognitive dissonance of sending ND information with ROLL > > messages. > > Grüße, Carsten > > > P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL. > > This e-mail (including any attachments) is confidential and may be > legally privileged. If you are not an intended recipient or an > authorized representative of an intended recipient, you are prohibited > from using, copying or distributing the information in this e-mail or > its attachments. If you have received this e-mail in error, please > notify the sender immediately by return e-mail and delete all copies > of this message and any attachments. Thank you. > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --------------030702020606030109090202 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hello Carsten, Pascal, Randy, *

I like the idea of having the 6CO included into RPL, simply because it already includes the PIO
and there is no RPL-ish way to tag any prefix information with context identifiers in 6LoWPANs.
Hence, and that is just my opinion, it is not desired, but a necessity to add the 6CO to RPL's
known options list.

Also: RFC 6775#1.4 clearly states that in order to substitute multihop prefix distribution,
it is also necessary to substitute the distribution of header compression contexts.
To quote RFC 6775 "... [they] go hand in hand."

With this quote in mind, adding the 6CO to RPL and using them (PIO + 6CO) in DIOs could be
the first step in dropping the ABRO overhead in RA messages when using RPL in a 6LoWPAN.
Currently, running RPL and 6LoWPAN-ND simultaneously would require to handle the versioning
of DODAGs (by DODAG root) and the versioning of ABRO related information (PIO + 6CO) (by 6LBR).
Without looking too much into details, and please correct me if I am wrong, but:
The ABRO and the DIO seem to have a few similarities. Both have versioning and both have a
concept of an "origin" (DODAG-ID <-> 6LBR Address).

So, wouldn't it be possible to abandon the ABRO in RPL domains where RPL also controls the PIOs and 6COs ?

Cheers,
Cenk

On 24.09.2015 17:24, Turner, Randy wrote:

 

Yes, I think that’s what I’m doing with the compression context option (syntactically recreating it for DIO) – the options’ interpretation is identical to RFC 6775 – the only difference I can possibly see between the 6775 text and the option I proposed is regarding “when” these options might appear in DIOs from the root.

 

Randy

 

 

Re: [Roll] DIO compression option

Carsten Bormann <cabo@tzi.org> Thu, 24 September 2015 14:45 UTCShow header

> Yes, I mentioned this in Prague (the fact that 6775 6CO already exists).

>  The Zigbee NAN group decided that the additional traffic imposed by

> neighbor discovery was not required (in the presence of DIO and DIO

> options) – however, we still would like to receive compression options,

> and we’ve already paid the DIO price traffic-wise, so we’re piggy

> backing the compression option onto DIOs we’re already handling.

>

> 

>

> I’m trying to maintain the context lifecycles per 6775, so the existing

> text will be modified to include the “lifetime” field in the option (the

> “C” bit already exists)

 

So is the observation fair that this is essentially about repackaging

6CO into the syntactic environment of a ROLL message?

 

I think we could do that for the rest of the 6Lo-ND messages as well and

reduce the cognitive dissonance of sending ND information with ROLL

messages.

 

Grüße, Carsten


P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL.

This e-mail (including any attachments) is confidential and may be legally privileged. If you are not an intended recipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the information in this e-mail or its attachments. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete all copies of this message and any attachments. Thank you. 



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

--------------030702020606030109090202-- From nobody Fri Sep 25 01:19:55 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0872C1B36B5 for ; Fri, 25 Sep 2015 01:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eq6npJRhW783 for ; Fri, 25 Sep 2015 01:19:50 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0193D1B36B4 for ; Fri, 25 Sep 2015 01:19:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23140; q=dns/txt; s=iport; t=1443169190; x=1444378790; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=49iTwgK8+RGbH9v2EzF7NyU0oWqxvCYl7Il1+6Y6FDc=; b=jz8qJaNSCFYsH0DHsrERsEqHRlKiimvEKWZpRp3uASNIoW1iIFZR1iFR I6F2QQiQlAybtFPNO6UX5hRUnBP0O1TPGkilWwQvqb/QKRsBxgwFFACfq 9qU1cCUKRZ2Qhl0pFN4UYxUCMwHdhs0zDo1hnG+oQGVrm9jqoI7+bn48C o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BsBQCGAgVW/5xdJa1dgldNVGkGgl5GvBcBCYV5AhyBGTwQAQEBAQEBAYEKhCQBAQEDAQEBAQkXBAY6BxALAgEGAhEBAwEBKAMCAgIlCxQDBggCBBMIiB4IDZofnSuUIAEBAQEBAQEBAQEBAQEBAQEBAQEBARMEhnOEfYQqEQE2FgEKAQaCY4FDBZI+gykBh3+FB4FThDaVJAE4K4IRHIFUcYgtOoEFAQEB X-IronPort-AV: E=Sophos;i="5.17,585,1437436800"; d="scan'208,217";a="191489134" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-7.cisco.com with ESMTP; 25 Sep 2015 08:19:49 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t8P8JmWX018365 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 25 Sep 2015 08:19:49 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 25 Sep 2015 03:19:48 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1104.000; Fri, 25 Sep 2015 03:19:48 -0500 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] DIO compression option Thread-Index: AQHQ9wt3uHSVLX7nyUu6jdZEqWIY/p5M4w1w Date: Fri, 25 Sep 2015 08:19:34 +0000 Deferred-Delivery: Fri, 25 Sep 2015 08:18:58 +0000 Message-ID: <49ca8038c29a4498b23281c1ee7ee48a@XCH-RCD-001.cisco.com> References: <56046359.4070202@gmail.com> In-Reply-To: <56046359.4070202@gmail.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.49.80.24] Content-Type: multipart/alternative; boundary="_000_49ca8038c29a4498b23281c1ee7ee48aXCHRCD001ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] DIO compression option X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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 Sep 2015 08:19:53 -0000 --_000_49ca8038c29a4498b23281c1ee7ee48aXCHRCD001ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gQ2Vuaw0KDQpUaGUgNlRpU0NIIGFyY2hpdGVjdHVyZSBpcyB0aGUgZmlyc3QgSUVURiBl ZmZvcnQgdGhhdCBjb21iaW5lcyBSUEwgYW5kIDZMb1dQQU4gTkQgYW5kIHN1Z2dlc3RzIGEgd2F5 IG9mIHB1dHRpbmcgdGhlbSB0b2dldGhlci4gVGhlIGVmZm9ydCBpcyBub3QgY29tcGxldGUgYnV0 IGl0IHJhaXNlcyB0aGF0IHNvcnQgb2YgY29leGlzdGVuY2UgcHJvYmxlbS4NCg0KT25lIG9mIHRo ZSBjb25jbHVzaW9ucyBpcyB0aGF0IHRoZSA2QkJSIGFuZCB0aGUgUlBMIHJvb3Qgc2hvdWxkIGJl IGNvbGxvY2F0ZWQgc28gdGhhdCBhIHJvb3QgZ2V0cyBhIGRldmljZSB1bmlxdWUgSUQgKGZyb20g NkxvV1BBTiBORCkgYW5kIGEgc2VxdWVuY2UgY291bnRlciAoZnJvbSBSUEwpIHNpbmNlIGluIHBy YWN0aWNlIGJvdGggYXJlIG5lZWRlZCBmb3IgdGhlIGJhY2tib25lIHJvdXRlciBvcGVyYXRpb24u IFRoZSBhcmNoaXRlY3R1cmUgYWxzbyBzdWdnZXN0cyB0aGF0IFJQTCBEQU8gc2VxdWVuY2UgY291 bnRlciBzaG91bGQgYmUgdXNlZCBhcyBUSUQgaW4gYW4gZXh0ZW5kZWQgQVJPIG9wdGlvbi4NCg0K VGhpcyBjb25jbHVzaW9uIG1hdGNoZXMgeW91cnMgdGhhdCBldmVuIHRob3VnaCB0aGUgMiBwcm90 b2NvbHMgYXJlIGRlc2lnbmVkIHRvIHN1cnZpdmUgc3RhbmQgYWxvbmUsIHNvbWUgc2ltcGxpZmlj YXRpb25zIGFuZCBwYWlyaW5ncyBhcmUgbmVlZGVkIHdoZW4gdGhleSBjb2V4aXN0Lg0KDQpBQlJP IGlzIG5vdCB0aGUgb25seSBvbmUuIFRoZSBESU8gZG9lcyBub3QgcHJvdmlkZSB0aGUgcm91dGVy IFNMTEEgZm9yIGluc3RhbmNlLCBzbyB0aGUgUkEgaXMgc3RpbGwgbmVlZGVkIGZvciB0aGF0IGFz IHdlbGwuDQoNCknigJlsbCBzdXBwb3J0LCBhbmQgZXZlbiBjb250cmlidXRlIGlmIG5lZWRlZCwg dG8gd29yayBhdCBST0xMIHRoYXQgYWxsb3dzIEFCUk8sIFNMTEFPLCBNVFVPIGFuZCA2Q08gaW4g RElPcy4gVGhlIHdvcmsgbWF5IGltcGFjdCB0aGUgRElTIHRoYXQgY2FuIGJlIHVzZWQgdG8gcmVx dWVzdCBzb21lIG9wdGlvbnMgdGhhdCBkbyBub3QgbmVlZCB0byBiZSBjYXJyaWVkIGluIGFsbCBE SU9zIGluIGEgZmFzaGlvbiBzaW1pbGFyIHRvIHRoZSBET0RBRyBDb25maWd1cmF0aW9uIG9wdGlv bi4gSXQgbWF5IGFsc28gZGlzY3VzcyBpbiBtb3JlIGRldGFpbHMgaG93IERJT3MgYXJlIHNlbnQg b24gY29uc3RyYWluZWQgbWF4aW11bSBmcmFtZSBzaXplIHdoZW4gbXVsdGlwbGUgb3B0aW9ucyBh cmUgbmVlZGVkLg0KDQpRdWVzdGlvbiB0byB0aGUgY2hhaXJzOiBpcyB0aGF0IHdvcmsgd2l0aGlu IFdIIGNoYXJ0ZXIgYm91bmRhcmllcz8NCg0KQ2hlZXJzLA0KDQpQYXNjYWwNCg0KRnJvbTogUm9s bCBbbWFpbHRvOnJvbGwtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIENlbmsgR8O8bmRv Z2FuDQpTZW50OiBqZXVkaSAyNCBzZXB0ZW1icmUgMjAxNSAyMjo1Ng0KVG86IHJvbGxAaWV0Zi5v cmcNClN1YmplY3Q6IFJlOiBbUm9sbF0gRElPIGNvbXByZXNzaW9uIG9wdGlvbg0KDQpIZWxsbyBD YXJzdGVuLCBQYXNjYWwsIFJhbmR5LCAqDQoNCkkgbGlrZSB0aGUgaWRlYSBvZiBoYXZpbmcgdGhl IDZDTyBpbmNsdWRlZCBpbnRvIFJQTCwgc2ltcGx5IGJlY2F1c2UgaXQgYWxyZWFkeSBpbmNsdWRl cyB0aGUgUElPDQphbmQgdGhlcmUgaXMgbm8gUlBMLWlzaCB3YXkgdG8gdGFnIGFueSBwcmVmaXgg aW5mb3JtYXRpb24gd2l0aCBjb250ZXh0IGlkZW50aWZpZXJzIGluIDZMb1dQQU5zLg0KSGVuY2Us IGFuZCB0aGF0IGlzIGp1c3QgbXkgb3BpbmlvbiwgaXQgaXMgbm90IGRlc2lyZWQsIGJ1dCBhIG5l Y2Vzc2l0eSB0byBhZGQgdGhlIDZDTyB0byBSUEwncw0Ka25vd24gb3B0aW9ucyBsaXN0Lg0KDQpB bHNvOiBSRkMgNjc3NSMxLjQgY2xlYXJseSBzdGF0ZXMgdGhhdCBpbiBvcmRlciB0byBzdWJzdGl0 dXRlIG11bHRpaG9wIHByZWZpeCBkaXN0cmlidXRpb24sDQppdCBpcyBhbHNvIG5lY2Vzc2FyeSB0 byBzdWJzdGl0dXRlIHRoZSBkaXN0cmlidXRpb24gb2YgaGVhZGVyIGNvbXByZXNzaW9uIGNvbnRl eHRzLg0KVG8gcXVvdGUgUkZDIDY3NzUgIi4uLiBbdGhleV0gZ28gaGFuZCBpbiBoYW5kLiINCg0K V2l0aCB0aGlzIHF1b3RlIGluIG1pbmQsIGFkZGluZyB0aGUgNkNPIHRvIFJQTCBhbmQgdXNpbmcg dGhlbSAoUElPICsgNkNPKSBpbiBESU9zIGNvdWxkIGJlDQp0aGUgZmlyc3Qgc3RlcCBpbiBkcm9w cGluZyB0aGUgQUJSTyBvdmVyaGVhZCBpbiBSQSBtZXNzYWdlcyB3aGVuIHVzaW5nIFJQTCBpbiBh IDZMb1dQQU4uDQpDdXJyZW50bHksIHJ1bm5pbmcgUlBMIGFuZCA2TG9XUEFOLU5EIHNpbXVsdGFu ZW91c2x5IHdvdWxkIHJlcXVpcmUgdG8gaGFuZGxlIHRoZSB2ZXJzaW9uaW5nDQpvZiBET0RBR3Mg KGJ5IERPREFHIHJvb3QpIGFuZCB0aGUgdmVyc2lvbmluZyBvZiBBQlJPIHJlbGF0ZWQgaW5mb3Jt YXRpb24gKFBJTyArIDZDTykgKGJ5IDZMQlIpLg0KV2l0aG91dCBsb29raW5nIHRvbyBtdWNoIGlu dG8gZGV0YWlscywgYW5kIHBsZWFzZSBjb3JyZWN0IG1lIGlmIEkgYW0gd3JvbmcsIGJ1dDoNClRo ZSBBQlJPIGFuZCB0aGUgRElPIHNlZW0gdG8gaGF2ZSBhIGZldyBzaW1pbGFyaXRpZXMuIEJvdGgg aGF2ZSB2ZXJzaW9uaW5nIGFuZCBib3RoIGhhdmUgYQ0KY29uY2VwdCBvZiBhbiAib3JpZ2luIiAo RE9EQUctSUQgPC0+IDZMQlIgQWRkcmVzcykuDQoNClNvLCB3b3VsZG4ndCBpdCBiZSBwb3NzaWJs ZSB0byBhYmFuZG9uIHRoZSBBQlJPIGluIFJQTCBkb21haW5zIHdoZXJlIFJQTCBhbHNvIGNvbnRy b2xzIHRoZSBQSU9zIGFuZCA2Q09zID8NCg0KQ2hlZXJzLA0KQ2Vuaw0KT24gMjQuMDkuMjAxNSAx NzoyNCwgVHVybmVyLCBSYW5keSB3cm90ZToNCg0KWWVzLCBJIHRoaW5rIHRoYXTigJlzIHdoYXQg SeKAmW0gZG9pbmcgd2l0aCB0aGUgY29tcHJlc3Npb24gY29udGV4dCBvcHRpb24gKHN5bnRhY3Rp Y2FsbHkgcmVjcmVhdGluZyBpdCBmb3IgRElPKSDigJMgdGhlIG9wdGlvbnPigJkgaW50ZXJwcmV0 YXRpb24gaXMgaWRlbnRpY2FsIHRvIFJGQyA2Nzc1IOKAkyB0aGUgb25seSBkaWZmZXJlbmNlIEkg Y2FuIHBvc3NpYmx5IHNlZSBiZXR3ZWVuIHRoZSA2Nzc1IHRleHQgYW5kIHRoZSBvcHRpb24gSSBw cm9wb3NlZCBpcyByZWdhcmRpbmcg4oCcd2hlbuKAnSB0aGVzZSBvcHRpb25zIG1pZ2h0IGFwcGVh ciBpbiBESU9zIGZyb20gdGhlIHJvb3QuDQoNClJhbmR5DQoNCg0KUmU6IFtSb2xsXSBESU8gY29t cHJlc3Npb24gb3B0aW9uDQpDYXJzdGVuIEJvcm1hbm4gPGNhYm9AdHppLm9yZz48bWFpbHRvOmNh Ym9AdHppLm9yZz4gVGh1LCAyNCBTZXB0ZW1iZXIgMjAxNSAxNDo0NSBVVENTaG93IGhlYWRlcg0K PiBZZXMsIEkgbWVudGlvbmVkIHRoaXMgaW4gUHJhZ3VlICh0aGUgZmFjdCB0aGF0IDY3NzUgNkNP IGFscmVhZHkgZXhpc3RzKS4NCj4gIFRoZSBaaWdiZWUgTkFOIGdyb3VwIGRlY2lkZWQgdGhhdCB0 aGUgYWRkaXRpb25hbCB0cmFmZmljIGltcG9zZWQgYnkNCj4gbmVpZ2hib3IgZGlzY292ZXJ5IHdh cyBub3QgcmVxdWlyZWQgKGluIHRoZSBwcmVzZW5jZSBvZiBESU8gYW5kIERJTw0KPiBvcHRpb25z KSDigJMgaG93ZXZlciwgd2Ugc3RpbGwgd291bGQgbGlrZSB0byByZWNlaXZlIGNvbXByZXNzaW9u IG9wdGlvbnMsDQo+IGFuZCB3ZeKAmXZlIGFscmVhZHkgcGFpZCB0aGUgRElPIHByaWNlIHRyYWZm aWMtd2lzZSwgc28gd2XigJlyZSBwaWdneQ0KPiBiYWNraW5nIHRoZSBjb21wcmVzc2lvbiBvcHRp b24gb250byBESU9zIHdl4oCZcmUgYWxyZWFkeSBoYW5kbGluZy4NCj4NCj4NCj4NCj4gSeKAmW0g dHJ5aW5nIHRvIG1haW50YWluIHRoZSBjb250ZXh0IGxpZmVjeWNsZXMgcGVyIDY3NzUsIHNvIHRo ZSBleGlzdGluZw0KPiB0ZXh0IHdpbGwgYmUgbW9kaWZpZWQgdG8gaW5jbHVkZSB0aGUg4oCcbGlm ZXRpbWXigJ0gZmllbGQgaW4gdGhlIG9wdGlvbiAodGhlDQo+IOKAnEPigJ0gYml0IGFscmVhZHkg ZXhpc3RzKQ0KDQpTbyBpcyB0aGUgb2JzZXJ2YXRpb24gZmFpciB0aGF0IHRoaXMgaXMgZXNzZW50 aWFsbHkgYWJvdXQgcmVwYWNrYWdpbmcNCjZDTyBpbnRvIHRoZSBzeW50YWN0aWMgZW52aXJvbm1l bnQgb2YgYSBST0xMIG1lc3NhZ2U/DQoNCkkgdGhpbmsgd2UgY291bGQgZG8gdGhhdCBmb3IgdGhl IHJlc3Qgb2YgdGhlIDZMby1ORCBtZXNzYWdlcyBhcyB3ZWxsIGFuZA0KcmVkdWNlIHRoZSBjb2du aXRpdmUgZGlzc29uYW5jZSBvZiBzZW5kaW5nIE5EIGluZm9ybWF0aW9uIHdpdGggUk9MTA0KbWVz c2FnZXMuDQoNCkdyw7zDn2UsIENhcnN0ZW4NCg0KDQpQIFBMRUFTRSBDT05TSURFUiBPVVIgRU5W SVJPTk1FTlQgQkVGT1JFIFBSSU5USU5HIFRISVMgRU1BSUwuDQoNClRoaXMgZS1tYWlsIChpbmNs dWRpbmcgYW55IGF0dGFjaG1lbnRzKSBpcyBjb25maWRlbnRpYWwgYW5kIG1heSBiZSBsZWdhbGx5 IHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCBvciBhbiBh dXRob3JpemVkIHJlcHJlc2VudGF0aXZlIG9mIGFuIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFy ZSBwcm9oaWJpdGVkIGZyb20gdXNpbmcsIGNvcHlpbmcgb3IgZGlzdHJpYnV0aW5nIHRoZSBpbmZv cm1hdGlvbiBpbiB0aGlzIGUtbWFpbCBvciBpdHMgYXR0YWNobWVudHMuIElmIHlvdSBoYXZlIHJl Y2VpdmVkIHRoaXMgZS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1t ZWRpYXRlbHkgYnkgcmV0dXJuIGUtbWFpbCBhbmQgZGVsZXRlIGFsbCBjb3BpZXMgb2YgdGhpcyBt ZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMuIFRoYW5rIHlvdS4NCg0KDQoNCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KUm9sbCBtYWlsaW5nIGxp c3QNCg0KUm9sbEBpZXRmLm9yZzxtYWlsdG86Um9sbEBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb2xsDQoNCg== --_000_49ca8038c29a4498b23281c1ee7ee48aXCHRCD001ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OldlYmRpbmdzOw0K CXBhbm9zZS0xOjUgMyAxIDIgMSA1IDkgNiA3IDM7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNv SHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxv d2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnByZQ0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVk IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazt9DQpz cGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uSFRNTFBy ZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIi Ow0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3Jt YXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1h aWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3 Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGlu az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkhlbGxvIENlbms8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlRoZSA2VGlTQ0ggYXJjaGl0ZWN0 dXJlIGlzIHRoZSBmaXJzdCBJRVRGIGVmZm9ydCB0aGF0IGNvbWJpbmVzIFJQTCBhbmQgNkxvV1BB TiBORCBhbmQgc3VnZ2VzdHMgYSB3YXkgb2YgcHV0dGluZyB0aGVtIHRvZ2V0aGVyLiBUaGUgZWZm b3J0IGlzIG5vdCBjb21wbGV0ZSBidXQgaXQgcmFpc2VzIHRoYXQgc29ydCBvZiBjb2V4aXN0ZW5j ZSBwcm9ibGVtLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+T25lIG9mIHRo ZSBjb25jbHVzaW9ucyBpcyB0aGF0IHRoZSA2QkJSIGFuZCB0aGUgUlBMIHJvb3Qgc2hvdWxkIGJl IGNvbGxvY2F0ZWQgc28gdGhhdCBhIHJvb3QgZ2V0cyBhIGRldmljZSB1bmlxdWUgSUQgKGZyb20g NkxvV1BBTiBORCkgYW5kIGEgc2VxdWVuY2UgY291bnRlciAoZnJvbSBSUEwpIHNpbmNlIGluIHBy YWN0aWNlIGJvdGggYXJlIG5lZWRlZCBmb3IgdGhlDQogYmFja2JvbmUgcm91dGVyIG9wZXJhdGlv bi4gVGhlIGFyY2hpdGVjdHVyZSBhbHNvIHN1Z2dlc3RzIHRoYXQgUlBMIERBTyBzZXF1ZW5jZSBj b3VudGVyIHNob3VsZCBiZSB1c2VkIGFzIFRJRCBpbiBhbiBleHRlbmRlZCBBUk8gb3B0aW9uLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+VGhpcyBjb25jbHVzaW9uIG1hdGNo ZXMgeW91cnMgdGhhdCBldmVuIHRob3VnaCB0aGUgMiBwcm90b2NvbHMgYXJlIGRlc2lnbmVkIHRv IHN1cnZpdmUgc3RhbmQgYWxvbmUsIHNvbWUgc2ltcGxpZmljYXRpb25zIGFuZCBwYWlyaW5ncyBh cmUgbmVlZGVkIHdoZW4gdGhleSBjb2V4aXN0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+QUJSTyBpcyBub3QgdGhlIG9ubHkgb25lLiBUaGUgRElPIGRvZXMgbm90IHByb3Zp ZGUgdGhlIHJvdXRlciBTTExBIGZvciBpbnN0YW5jZSwgc28gdGhlIFJBIGlzIHN0aWxsIG5lZWRl ZCBmb3IgdGhhdCBhcyB3ZWxsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ SeKAmWxsIHN1cHBvcnQsIGFuZCBldmVuIGNvbnRyaWJ1dGUgaWYgbmVlZGVkLCB0byB3b3JrIGF0 IFJPTEwgdGhhdCBhbGxvd3MgQUJSTywgU0xMQU8sIE1UVU8gYW5kIDZDTyBpbiBESU9zLiBUaGUg d29yayBtYXkgaW1wYWN0IHRoZSBESVMgdGhhdCBjYW4gYmUgdXNlZCB0byByZXF1ZXN0IHNvbWUg b3B0aW9ucyB0aGF0IGRvIG5vdCBuZWVkIHRvIGJlIGNhcnJpZWQNCiBpbiBhbGwgRElPcyBpbiBh IGZhc2hpb24gc2ltaWxhciB0byB0aGUgRE9EQUcgQ29uZmlndXJhdGlvbiBvcHRpb24uIEl0IG1h eSBhbHNvIGRpc2N1c3MgaW4gbW9yZSBkZXRhaWxzIGhvdyBESU9zIGFyZSBzZW50IG9uIGNvbnN0 cmFpbmVkIG1heGltdW0gZnJhbWUgc2l6ZSB3aGVuIG11bHRpcGxlIG9wdGlvbnMgYXJlIG5lZWRl ZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlF1ZXN0aW9uIHRvIHRoZSBj aGFpcnM6IGlzIHRoYXQgd29yayB3aXRoaW4gV0ggY2hhcnRlciBib3VuZGFyaWVzPzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkNoZWVycyw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRlIiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5QYXNjYWw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4w cHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0Ux RTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPiBSb2xsIFttYWlsdG86cm9sbC1ib3VuY2VzQGll dGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5DZW5rIEfDvG5kb2dhbjxicj4NCjxiPlNlbnQ6 PC9iPiBqZXVkaSAyNCBzZXB0ZW1icmUgMjAxNSAyMjo1Njxicj4NCjxiPlRvOjwvYj4gcm9sbEBp ZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1JvbGxdIERJTyBjb21wcmVzc2lvbiBv cHRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkhlbGxvIENhcnN0ZW4sIFBhc2NhbCwgUmFuZHksICo8 YnI+DQo8YnI+DQpJIGxpa2UgdGhlIGlkZWEgb2YgaGF2aW5nIHRoZSA2Q08gaW5jbHVkZWQgaW50 byBSUEwsIHNpbXBseSBiZWNhdXNlIGl0IGFscmVhZHkgaW5jbHVkZXMgdGhlIFBJTzxicj4NCmFu ZCB0aGVyZSBpcyBubyBSUEwtaXNoIHdheSB0byB0YWcgYW55IHByZWZpeCBpbmZvcm1hdGlvbiB3 aXRoIGNvbnRleHQgaWRlbnRpZmllcnMgaW4gNkxvV1BBTnMuPGJyPg0KSGVuY2UsIGFuZCB0aGF0 IGlzIGp1c3QgbXkgb3BpbmlvbiwgaXQgaXMgbm90IGRlc2lyZWQsIGJ1dCBhIG5lY2Vzc2l0eSB0 byBhZGQgdGhlIDZDTyB0byBSUEwnczxicj4NCmtub3duIG9wdGlvbnMgbGlzdC48YnI+DQo8YnI+ DQpBbHNvOiBSRkMgNjc3NSMxLjQgY2xlYXJseSBzdGF0ZXMgdGhhdCBpbiBvcmRlciB0byBzdWJz dGl0dXRlIG11bHRpaG9wIHByZWZpeCBkaXN0cmlidXRpb24sPGJyPg0KaXQgaXMgYWxzbyBuZWNl c3NhcnkgdG8gc3Vic3RpdHV0ZSB0aGUgZGlzdHJpYnV0aW9uIG9mIGhlYWRlciBjb21wcmVzc2lv biBjb250ZXh0cy4NCjxicj4NClRvIHF1b3RlIFJGQyA2Nzc1ICZxdW90Oy4uLiBbdGhleV0gZ28g aGFuZCBpbiBoYW5kLiZxdW90Ozxicj4NCjxicj4NCldpdGggdGhpcyBxdW90ZSBpbiBtaW5kLCBh ZGRpbmcgdGhlIDZDTyB0byBSUEwgYW5kIHVzaW5nIHRoZW0gKFBJTyAmIzQzOyA2Q08pIGluIERJ T3MgY291bGQgYmU8YnI+DQp0aGUgZmlyc3Qgc3RlcCBpbiBkcm9wcGluZyB0aGUgQUJSTyBvdmVy aGVhZCBpbiBSQSBtZXNzYWdlcyB3aGVuIHVzaW5nIFJQTCBpbiBhIDZMb1dQQU4uPGJyPg0KQ3Vy cmVudGx5LCBydW5uaW5nIFJQTCBhbmQgNkxvV1BBTi1ORCBzaW11bHRhbmVvdXNseSB3b3VsZCBy ZXF1aXJlIHRvIGhhbmRsZSB0aGUgdmVyc2lvbmluZzxicj4NCm9mIERPREFHcyAoYnkgRE9EQUcg cm9vdCkgYW5kIHRoZSB2ZXJzaW9uaW5nIG9mIEFCUk8gcmVsYXRlZCBpbmZvcm1hdGlvbiAoUElP ICYjNDM7IDZDTykgKGJ5IDZMQlIpLjxicj4NCldpdGhvdXQgbG9va2luZyB0b28gbXVjaCBpbnRv IGRldGFpbHMsIGFuZCBwbGVhc2UgY29ycmVjdCBtZSBpZiBJIGFtIHdyb25nLCBidXQ6PGJyPg0K VGhlIEFCUk8gYW5kIHRoZSBESU8gc2VlbSB0byBoYXZlIGEgZmV3IHNpbWlsYXJpdGllcy4gQm90 aCBoYXZlIHZlcnNpb25pbmcgYW5kIGJvdGggaGF2ZSBhPGJyPg0KY29uY2VwdCBvZiBhbiAmcXVv dDtvcmlnaW4mcXVvdDsgKERPREFHLUlEICZsdDstJmd0OyA2TEJSIEFkZHJlc3MpLiA8YnI+DQo8 YnI+DQpTbywgd291bGRuJ3QgaXQgYmUgcG9zc2libGUgdG8gYWJhbmRvbiB0aGUgQUJSTyBpbiBS UEwgZG9tYWlucyB3aGVyZSBSUEwgYWxzbyBjb250cm9scyB0aGUgUElPcyBhbmQgNkNPcyA/PGJy Pg0KPGJyPg0KQ2hlZXJzLDxicj4NCkNlbmsgPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAy NC4wOS4yMDE1IDE3OjI0LCBUdXJuZXIsIFJhbmR5IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+WWVzLCBJIHRoaW5rIHRoYXTigJlzIHdoYXQgSeKAmW0gZG9pbmcgd2l0 aCB0aGUgY29tcHJlc3Npb24gY29udGV4dCBvcHRpb24gKHN5bnRhY3RpY2FsbHkgcmVjcmVhdGlu ZyBpdCBmb3IgRElPKSDigJMgdGhlIG9wdGlvbnPigJkgaW50ZXJwcmV0YXRpb24gaXMgaWRlbnRp Y2FsIHRvIFJGQyA2Nzc1IOKAkyB0aGUgb25seSBkaWZmZXJlbmNlIEkgY2FuIHBvc3NpYmx5IHNl ZSBiZXR3ZWVuIHRoZSA2Nzc1IHRleHQgYW5kIHRoZSBvcHRpb24NCiBJIHByb3Bvc2VkIGlzIHJl Z2FyZGluZyDigJx3aGVu4oCdIHRoZXNlIG9wdGlvbnMgbWlnaHQgYXBwZWFyIGluIERJT3MgZnJv bSB0aGUgcm9vdC4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SYW5keTxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJl OiBbUm9sbF0gRElPIGNvbXByZXNzaW9uIG9wdGlvbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Q2Fyc3RlbiBCb3JtYW5uIDxhIGhyZWY9Im1haWx0bzpjYWJvQHR6aS5vcmci PiZsdDtjYWJvQHR6aS5vcmcmZ3Q7PC9hPiBUaHUsIDI0IFNlcHRlbWJlciAyMDE1IDE0OjQ1IFVU Q1Nob3cgaGVhZGVyPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IFll cywgSSBtZW50aW9uZWQgdGhpcyBpbiBQcmFndWUgKHRoZSBmYWN0IHRoYXQgNjc3NSA2Q08gYWxy ZWFkeSBleGlzdHMpLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyZu YnNwOyBUaGUgWmlnYmVlIE5BTiBncm91cCBkZWNpZGVkIHRoYXQgdGhlIGFkZGl0aW9uYWwgdHJh ZmZpYyBpbXBvc2VkIGJ5PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7 IG5laWdoYm9yIGRpc2NvdmVyeSB3YXMgbm90IHJlcXVpcmVkIChpbiB0aGUgcHJlc2VuY2Ugb2Yg RElPIGFuZCBESU88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgb3B0 aW9ucykg4oCTIGhvd2V2ZXIsIHdlIHN0aWxsIHdvdWxkIGxpa2UgdG8gcmVjZWl2ZSBjb21wcmVz c2lvbiBvcHRpb25zLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyBh bmQgd2XigJl2ZSBhbHJlYWR5IHBhaWQgdGhlIERJTyBwcmljZSB0cmFmZmljLXdpc2UsIHNvIHdl 4oCZcmUgcGlnZ3k8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgYmFj a2luZyB0aGUgY29tcHJlc3Npb24gb3B0aW9uIG9udG8gRElPcyB3ZeKAmXJlIGFscmVhZHkgaGFu ZGxpbmcuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IDxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyZuYnNwOyA8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mZ3Q7IEnigJltIHRyeWluZyB0byBtYWludGFpbiB0aGUgY29udGV4dCBsaWZlY3lj bGVzIHBlciA2Nzc1LCBzbyB0aGUgZXhpc3Rpbmc8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZndDsgdGV4dCB3aWxsIGJlIG1vZGlmaWVkIHRvIGluY2x1ZGUgdGhlIOKAnGxp ZmV0aW1l4oCdIGZpZWxkIGluIHRoZSBvcHRpb24gKHRoZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jmd0OyDigJxD4oCdIGJpdCBhbHJlYWR5IGV4aXN0cyk8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+U28gaXMgdGhlIG9ic2VydmF0aW9uIGZhaXIgdGhhdCB0aGlzIGlzIGVz c2VudGlhbGx5IGFib3V0IHJlcGFja2FnaW5nPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj42Q08gaW50byB0aGUgc3ludGFjdGljIGVudmlyb25tZW50IG9mIGEgUk9MTCBtZXNz YWdlPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIHdlIGNvdWxkIGRvIHRoYXQgZm9y IHRoZSByZXN0IG9mIHRoZSA2TG8tTkQgbWVzc2FnZXMgYXMgd2VsbCBhbmQ8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnJlZHVjZSB0aGUgY29nbml0aXZlIGRpc3NvbmFuY2Ug b2Ygc2VuZGluZyBORCBpbmZvcm1hdGlvbiB3aXRoIFJPTEw8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPm1lc3NhZ2VzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5HcsO8w59l LCBDYXJzdGVuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7LHNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OldlYmRpbmdzO2NvbG9yOmdyZWVuIj5QPC9zcGFuPjwvYj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6Z3JlZW4iPiBQTEVBU0UgQ09OU0lERVIgT1VSIEVOVklST05NRU5UIEJFRk9SRSBQ UklOVElORyBUSElTIEVNQUlMLg0KPGJyPg0KPGJyPg0KPC9zcGFuPjwvYj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6Z3JheSI+VGhpcyBlLW1haWwgKGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMpIGlz IGNvbmZpZGVudGlhbCBhbmQgbWF5IGJlIGxlZ2FsbHkgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBu b3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50IG9yIGFuIGF1dGhvcml6ZWQgcmVwcmVzZW50YXRpdmUg b2YgYW4gaW50ZW5kZWQNCiByZWNpcGllbnQsIHlvdSBhcmUgcHJvaGliaXRlZCBmcm9tIHVzaW5n LCBjb3B5aW5nIG9yIGRpc3RyaWJ1dGluZyB0aGUgaW5mb3JtYXRpb24gaW4gdGhpcyBlLW1haWwg b3IgaXRzIGF0dGFjaG1lbnRzLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGUtbWFpbCBpbiBl cnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IHJldHVybiBlLW1h aWwgYW5kIGRlbGV0ZSBhbGwgY29waWVzIG9mIHRoaXMgbWVzc2FnZSBhbmQNCiBhbnkgYXR0YWNo bWVudHMuIFRoYW5rIHlvdS4gPC9zcGFuPjwvYj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Z3JlZW4i PjxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OyxzZXJpZiI+PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHByZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlJvbGwgbWFpbGluZyBsaXN0PG86cD48L286cD48L3By ZT4NCjxwcmU+PGEgaHJlZj0ibWFpbHRvOlJvbGxAaWV0Zi5vcmciPlJvbGxAaWV0Zi5vcmc8L2E+ PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9yb2xsIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3JvbGw8L2E+PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_49ca8038c29a4498b23281c1ee7ee48aXCHRCD001ciscocom_-- From nobody Fri Sep 25 05:42:58 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF4051B3179 for ; Fri, 25 Sep 2015 05:42:56 -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=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2aXKA59MpUea for ; Fri, 25 Sep 2015 05:42:53 -0700 (PDT) Received: from mail-la0-f49.google.com (mail-la0-f49.google.com [209.85.215.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8B441A90B2 for ; Fri, 25 Sep 2015 05:42:52 -0700 (PDT) Received: by laclj5 with SMTP id lj5so1752873lac.3 for ; Fri, 25 Sep 2015 05:42:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=WWj+OpUDIobe8rtnNtLTHFmLWJTXidgIxaXn7vlARXw=; b=a/LJSjNo5vcoiIK/TpoiY+JivIMpnjELkC9ncXdr1qGV7yfZ1RIDbycYiBf6uVt+hI nLtebpMt4NzrYyN9fZZvcVzfU415FN26icOyz6iZNl6cw0fq0mEwimCQB96+KTqENEoh mk2+YlPfYQ44dXus2ks5SJwzu9Qn7At3/znCXnSD61bPMSVsIgRNbH7OKJGdCrOza+N8 WEW2v5P+8A5zw6BkYUuhtodJf/6ckPpaSk/44WOwQIiygq2INC+in7L3SPbuDBzooJ12 3V5WjFIzN4xamiVk5Dw0X4toxWOOurIh81K2ZBrKLjUrOdzLyVUKrGTLKN6BJmnLEMc4 JNyw== X-Gm-Message-State: ALoCoQkJsLeJKy7bmK+I4zMdZ6UbRA3Qg9PZQ/Puv7ijbNLBEkLW/XcQqldvCCGJh0lAsGCtl0Ur X-Received: by 10.152.44.233 with SMTP id h9mr1561255lam.74.1443184970602; Fri, 25 Sep 2015 05:42:50 -0700 (PDT) Received: from [172.16.135.137] (178-78-237-194.customers.ownit.se. [178.78.237.194]) by smtp.gmail.com with ESMTPSA id e3sm371736laa.0.2015.09.25.05.42.49 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 25 Sep 2015 05:42:49 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_54F14390-37C3-4F60-B3B4-620AA8B9316F" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Joakim Eriksson In-Reply-To: <49ca8038c29a4498b23281c1ee7ee48a@XCH-RCD-001.cisco.com> Date: Fri, 25 Sep 2015 14:42:48 +0200 Message-Id: <94E53561-962E-45D1-B669-6F071F5831DF@sics.se> References: <56046359.4070202@gmail.com> <49ca8038c29a4498b23281c1ee7ee48a@XCH-RCD-001.cisco.com> To: Routing Over Low power and Lossy networks X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [Roll] DIO compression option X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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 Sep 2015 12:42:57 -0000 --Apple-Mail=_54F14390-37C3-4F60-B3B4-620AA8B9316F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I also promote thinking and developments in this direction. RPL and = 6LoWPAN ND do have overlaps and if we can add more options to DIOs that would probably simplify implementations = significantly. We would be happy to help out test some of these ideas in ContikiRPL. Best regards, =E2=80=94 Joakim Eriksson, SICS Swedish ICT > On 25 Sep 2015, at 10:19, Pascal Thubert (pthubert) = wrote: >=20 > Hello Cenk > =20 > The 6TiSCH architecture is the first IETF effort that combines RPL and = 6LoWPAN ND and suggests a way of putting them together. The effort is = not complete but it raises that sort of coexistence problem. > =20 > One of the conclusions is that the 6BBR and the RPL root should be = collocated so that a root gets a device unique ID (from 6LoWPAN ND) and = a sequence counter (from RPL) since in practice both are needed for the = backbone router operation. The architecture also suggests that RPL DAO = sequence counter should be used as TID in an extended ARO option. > =20 > This conclusion matches yours that even though the 2 protocols are = designed to survive stand alone, some simplifications and pairings are = needed when they coexist. > =20 > ABRO is not the only one. The DIO does not provide the router SLLA for = instance, so the RA is still needed for that as well. > =20 > I=E2=80=99ll support, and even contribute if needed, to work at ROLL = that allows ABRO, SLLAO, MTUO and 6CO in DIOs. The work may impact the = DIS that can be used to request some options that do not need to be = carried in all DIOs in a fashion similar to the DODAG Configuration = option. It may also discuss in more details how DIOs are sent on = constrained maximum frame size when multiple options are needed. > =20 > Question to the chairs: is that work within WH charter boundaries? > =20 > Cheers, > =20 > Pascal > =20 > From: Roll [mailto:roll-bounces@ietf.org = ] On Behalf Of Cenk G=C3=BCndogan > Sent: jeudi 24 septembre 2015 22:56 > To: roll@ietf.org > Subject: Re: [Roll] DIO compression option > =20 > Hello Carsten, Pascal, Randy, * >=20 > I like the idea of having the 6CO included into RPL, simply because it = already includes the PIO > and there is no RPL-ish way to tag any prefix information with context = identifiers in 6LoWPANs. > Hence, and that is just my opinion, it is not desired, but a necessity = to add the 6CO to RPL's > known options list. >=20 > Also: RFC 6775#1.4 clearly states that in order to substitute multihop = prefix distribution, > it is also necessary to substitute the distribution of header = compression contexts.=20 > To quote RFC 6775 "... [they] go hand in hand." >=20 > With this quote in mind, adding the 6CO to RPL and using them (PIO + = 6CO) in DIOs could be > the first step in dropping the ABRO overhead in RA messages when using = RPL in a 6LoWPAN. > Currently, running RPL and 6LoWPAN-ND simultaneously would require to = handle the versioning > of DODAGs (by DODAG root) and the versioning of ABRO related = information (PIO + 6CO) (by 6LBR). > Without looking too much into details, and please correct me if I am = wrong, but: > The ABRO and the DIO seem to have a few similarities. Both have = versioning and both have a > concept of an "origin" (DODAG-ID <-> 6LBR Address).=20 >=20 > So, wouldn't it be possible to abandon the ABRO in RPL domains where = RPL also controls the PIOs and 6COs ? >=20 > Cheers, > Cenk=20 >=20 > On 24.09.2015 17:24, Turner, Randy wrote: > =20 > Yes, I think that=E2=80=99s what I=E2=80=99m doing with the = compression context option (syntactically recreating it for DIO) =E2=80=93= the options=E2=80=99 interpretation is identical to RFC 6775 =E2=80=93 = the only difference I can possibly see between the 6775 text and the = option I proposed is regarding =E2=80=9Cwhen=E2=80=9D these options = might appear in DIOs from the root. > =20 > Randy > =20 > =20 > Re: [Roll] DIO compression option > Carsten Bormann Thu, 24 September = 2015 14:45 UTCShow header > > Yes, I mentioned this in Prague (the fact that 6775 6CO already = exists). > > The Zigbee NAN group decided that the additional traffic imposed by > > neighbor discovery was not required (in the presence of DIO and DIO > > options) =E2=80=93 however, we still would like to receive = compression options, > > and we=E2=80=99ve already paid the DIO price traffic-wise, so = we=E2=80=99re piggy > > backing the compression option onto DIOs we=E2=80=99re already = handling. > >=20 > > =20 > >=20 > > I=E2=80=99m trying to maintain the context lifecycles per 6775, so = the existing > > text will be modified to include the =E2=80=9Clifetime=E2=80=9D = field in the option (the > > =E2=80=9CC=E2=80=9D bit already exists) > =20 > So is the observation fair that this is essentially about repackaging > 6CO into the syntactic environment of a ROLL message? > =20 > I think we could do that for the rest of the 6Lo-ND messages as well = and > reduce the cognitive dissonance of sending ND information with ROLL > messages. > =20 > Gr=C3=BC=C3=9Fe, Carsten > =20 > P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL.=20 >=20 > This e-mail (including any attachments) is confidential and may be = legally privileged. If you are not an intended recipient or an = authorized representative of an intended recipient, you are prohibited = from using, copying or distributing the information in this e-mail or = its attachments. If you have received this e-mail in error, please = notify the sender immediately by return e-mail and delete all copies of = this message and any attachments. Thank you.=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll = > =20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll = --Apple-Mail=_54F14390-37C3-4F60-B3B4-620AA8B9316F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
I also promote thinking and developments in = this direction. RPL and 6LoWPAN ND do have overlaps and if we can = add
more options to DIOs that would probably = simplify implementations significantly. We would be happy
to help out test some of these ideas in ContikiRPL.

Best regards,
=E2=80=94 Joakim Eriksson, SICS Swedish ICT



On = 25 Sep 2015, at 10:19, Pascal Thubert (pthubert) <pthubert@cisco.com> = wrote:

Hello Cenk
 
The 6TiSCH architecture is the first IETF effort that = combines RPL and 6LoWPAN ND and suggests a way of putting them together. = The effort is not complete but it raises that sort of coexistence = problem.
 
One of the conclusions is = that the 6BBR and the RPL root should be collocated so that a root gets = a device unique ID (from 6LoWPAN ND) and a sequence counter (from RPL) = since in practice both are needed for the backbone router operation. The = architecture also suggests that RPL DAO sequence counter should be used = as TID in an extended ARO option.
 
This = conclusion matches yours that even though the 2 protocols are designed = to survive stand alone, some simplifications and pairings are needed = when they coexist.
 
ABRO is not the only one. = The DIO does not provide the router SLLA for instance, so the RA is = still needed for that as well.
 
I=E2=80=99l= l support, and even contribute if needed, to work at ROLL that allows = ABRO, SLLAO, MTUO and 6CO in DIOs. The work may impact the DIS that can = be used to request some options that do not need to be carried in all = DIOs in a fashion similar to the DODAG Configuration option. It may also = discuss in more details how DIOs are sent on constrained maximum frame = size when multiple options are needed.
 
Question to the chairs: is that work within WH charter = boundaries?
 
Cheers,
 
Pascal
 
From: Roll [mailto:roll-bounces@ietf.org] On Behalf = Of Cenk = G=C3=BCndogan
Sent: jeudi 24 septembre 2015 = 22:56
To: roll@ietf.org
Subject: Re: [Roll] DIO compression = option
 

Hello Carsten, Pascal, Randy, *

I like the idea of having the 6CO included into RPL, simply = because it already includes the PIO
and there is no = RPL-ish way to tag any prefix information with context identifiers in = 6LoWPANs.
Hence, and that is just my opinion, it is not = desired, but a necessity to add the 6CO to RPL's
known = options list.

Also: RFC 6775#1.4 clearly = states that in order to substitute multihop prefix distribution,
it is also necessary to substitute the distribution of header = compression contexts. 
To quote RFC = 6775 "... [they] go hand in hand."

With = this quote in mind, adding the 6CO to RPL and using them (PIO + 6CO) in = DIOs could be
the first step in dropping the ABRO overhead = in RA messages when using RPL in a 6LoWPAN.
Currently, = running RPL and 6LoWPAN-ND simultaneously would require to handle the = versioning
of DODAGs (by DODAG root) and the versioning of = ABRO related information (PIO + 6CO) (by 6LBR).
Without = looking too much into details, and please correct me if I am wrong, = but:
The ABRO and the DIO seem to have a few similarities. = Both have versioning and both have a
concept of an = "origin" (DODAG-ID <-> 6LBR Address). 

So, wouldn't it be possible to abandon the ABRO in RPL = domains where RPL also controls the PIOs and 6COs ?

Cheers,
Cenk 

On 24.09.2015 17:24, Turner, Randy = wrote:
 
Yes, I think that=E2=80=99s what I=E2=80=99m doing with the = compression context option (syntactically recreating it for DIO) =E2=80=93= the options=E2=80=99 interpretation is identical to RFC 6775 =E2=80=93 = the only difference I can possibly see between the 6775 text and the = option I proposed is regarding =E2=80=9Cwhen=E2=80=9D these options = might appear in DIOs from the root.
 
Randy
 
 
Re: [Roll] DIO compression option
Carsten = Bormann <cabo@tzi.org> Thu, 24 September 2015 = 14:45 UTCShow header
> Yes, I mentioned this in Prague (the fact that 6775 6CO = already exists).
>  The Zigbee NAN group decided that the additional = traffic imposed by
> neighbor discovery was not required (in the presence of = DIO and DIO
> options) =E2=80=93 however, we still would like to = receive compression options,
> and we=E2=80=99ve already paid the = DIO price traffic-wise, so we=E2=80=99re piggy
> = backing the compression option onto DIOs we=E2=80=99re already = handling.
> 
>  
> 
> = I=E2=80=99m trying to maintain the context lifecycles per 6775, so the = existing
> text will be modified to include the =E2=80=9Clifetime=E2=80= =9D field in the option (the
> =E2=80=9CC=E2=80=9D bit already = exists)
 
So is the observation fair that this is essentially about = repackaging
6CO into the syntactic environment of a ROLL message?
 
I think = we could do that for the rest of the 6Lo-ND messages as well and
reduce = the cognitive dissonance of sending ND information with ROLL
messages.
 
Gr=C3=BC=C3=9Fe, Carsten
 

P PLEASE CONSIDER OUR = ENVIRONMENT BEFORE PRINTING THIS EMAIL. 

This e-mail = (including any attachments) is confidential and may be legally = privileged. If you are not an intended recipient or an authorized = representative of an intended recipient, you are prohibited from using, = copying or distributing the information in this e-mail or its = attachments. If you have received this e-mail in error, please notify = the sender immediately by return e-mail and delete all copies of this = message and any attachments. 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

= --Apple-Mail=_54F14390-37C3-4F60-B3B4-620AA8B9316F-- From nobody Fri Sep 25 06:07:10 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 346571A01A5 for ; Fri, 25 Sep 2015 06:07:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.21 X-Spam-Level: X-Spam-Status: No, score=-6.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n_i0x3WVuDwK for ; Fri, 25 Sep 2015 06:07:07 -0700 (PDT) Received: from sjmda10.webex.com (sjmda10.webex.com [64.68.124.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E921E1A01F7 for ; Fri, 25 Sep 2015 06:06:53 -0700 (PDT) Received: from jva2tc206.webex.com (sjc02-wxp00-lbace03-core-vl120-np10b-4.webex.com [64.68.121.239]) by sjmda10.webex.com (Postfix) with ESMTP id 76C741F0B for ; Fri, 25 Sep 2015 13:06:53 +0000 (GMT) Received: from jva2tc206.webex.com (localhost [127.0.0.1]) by jva2tc206.webex.com (Postfix) with ESMTP id 3981CA0625 for ; Fri, 25 Sep 2015 13:06:53 +0000 (GMT) Date: Fri, 25 Sep 2015 13:06:53 +0000 (GMT) From: Michael Richardson To: roll@ietf.org Message-ID: <971672143.30546.1443186413233.JavaMail.nobody@jva2tc206.webex.com> MIME-Version: 1.0 Content-Type: multipart/Mixed; boundary="----=_Part_30544_848233964.1443186413233" X-Priority: 3 Importance: normal Archived-At: Subject: [Roll] WebEx meeting invitation: ROLL use-of-rpi X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mcr+nomcom@sandelman.ca, 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 Sep 2015 13:07:09 -0000 ------=_Part_30544_848233964.1443186413233 Content-Type: multipart/Alternative; boundary="----=_Part_30545_1271784162.1443186413233" ------=_Part_30545_1271784162.1443186413233 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: base64 CkhlbGxvLAoKTWljaGFlbCBSaWNoYXJkc29uIGludml0ZXMgeW91IHRvIGpvaW4gdGhpcyBXZWJF eCBtZWV0aW5nLgoKClJPTEwgdXNlLW9mLXJwaQpUdWVzZGF5LCBTZXB0ZW1iZXIgMjksIDIwMTUK OTowMCBhbSAgfCAgRWFzdGVybiBEYXlsaWdodCBUaW1lIChOZXcgWW9yaywgR01ULTA0OjAwKSAg fCAgMiBocnMKCgpKT0lOIFdFQkVYIE1FRVRJTkcKaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRm L2oucGhwP01USUQ9bTZjYjVhZDcyNmYwMzgzMjFiOGJkMDQxNDU0MTY2MGIxCk1lZXRpbmcgbnVt YmVyOiA2NDIgODIwIDU2NwpNZWV0aW5nIHBhc3N3b3JkOiByb2xsCgoNCkpPSU4gQlkgUEhPTkUN CjEtODc3LTY2OC00NDkzIENhbGwtaW4gdG9sbCBmcmVlIG51bWJlciAoVVMvQ2FuYWRhKSAKMS02 NTAtNDc5LTMyMDggQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKQpBY2Nlc3MgY29kZTog NjQyIDgyMCA1NjcKClRvbGwtZnJlZSBkaWFsaW5nIHJlc3RyaWN0aW9uczogCmh0dHA6Ly93d3cu d2ViZXguY29tL3BkZi90b2xsZnJlZV9yZXN0cmljdGlvbnMucGRmDQoNCgpBZGQgdGhpcyBtZWV0 aW5nIHRvIHlvdXIgY2FsZW5kYXI6Cmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9N VElEPW04YTEyNTNkYjIxNzBmNzM5YjNkOTU4NzM4OTE2MjQwZg0KDQoKQ2FuJ3Qgam9pbiB0aGUg bWVldGluZz8gQ29udGFjdCBzdXBwb3J0IGhlcmU6Cmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0 Zi9tYwoKCklNUE9SVEFOVCBOT1RJQ0U6IFBsZWFzZSBub3RlIHRoYXQgdGhpcyBXZWJFeCBzZXJ2 aWNlIGFsbG93cyBhdWRpbyBhbmQgb3RoZXIgaW5mb3JtYXRpb24gc2VudCBkdXJpbmcgdGhlIHNl c3Npb24gdG8gYmUgcmVjb3JkZWQsIHdoaWNoIG1heSBiZSBkaXNjb3ZlcmFibGUgaW4gYSBsZWdh bCBtYXR0ZXIuIEJ5IGpvaW5pbmcgdGhpcyBzZXNzaW9uLCB5b3UgYXV0b21hdGljYWxseSBjb25z ZW50IHRvIHN1Y2ggcmVjb3JkaW5ncy4gSWYgeW91IGRvIG5vdCBjb25zZW50IHRvIGJlaW5nIHJl Y29yZGVkLCBkaXNjdXNzIHlvdXIgY29uY2VybnMgd2l0aCB0aGUgaG9zdCBvciBkbyBub3Qgam9p biB0aGUgc2Vzc2lvbi4K ------=_Part_30545_1271784162.1443186413233 Content-Type: text/html;charset=UTF-8 Content-Transfer-Encoding: base64 PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPjxtZXRhIG5hbWU9InZpZXdwb3J0IiBjb250ZW50PSJ3aWR0aD1kZXZpY2Utd2lk dGgsIGluaXRpYWwtc2NhbGU9MSIgLz48Ym9keT48c3R5bGUgdHlwZT0idGV4dC9jc3MiPgpkaXYs cCx0ZCxzcGFuIHt3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7d29yZC1icmVhazogbm9ybWFsO30KCnRh YmxlIHtib3JkZXItY29sbGFwc2U6IHNlcGFyYXRlOyBib3JkZXI6IDA7Ym9yZGVyLXNwYWNpbmc6 IDA7Ym9yZGVyLWNvbG9yOiB3aGl0ZTsgd2lkdGg6MTAwJSFpbXBvcnRhbnQ7d2lkdGg6NTI1cHg7 IG1heC13aWR0aDo1MjVweCFpbXBvcnRhbnQ7IG1pbi13aWR0aDogMjc5cHghaW1wb3J0YW50O30K dHIge2xpbmUtaGVpZ2h0OiAyMHB4O30KCnRkLGEge2ZvbnQtc2l6ZTogMTVweDtmb250LWZhbWls eTogQXJpYWw7Y29sb3I6ICM2NjY2NjY7cGFkZGluZzowO30KPC9zdHlsZT4KCjx0YWJsZSBzdHls ZT0icGFkZGluZzowOyBtYXJnaW46MCIgd2lkdGg9IjEwMCUiIGFsaWduPSJsZWZ0Ij4KICAgPHRy PgogICAgICA8dGQgc3R5bGU9InBhZGRpbmctdG9wOjVweDsiPgogICAgICAgIDx0YWJsZSBzdHls ZT0id2lkdGg6IDUyNXB4O21hcmdpbi1sZWZ0OjVweCIgYWxpZ249ImxlZnQiPgoJCQk8dHI+CgkJ CQk8dGQgdmFsaWduPSJ0b3AiPgoKPHRhYmxlPgogICAgICAgPHRyPgogICAgICAgICAgPHRkIHN0 eWxlPSJmb250LXNpemU6IDE1cHg7Zm9udC1mYW1pbHk6IEFyaWFsO2NvbG9yOiM0RDRENEQiPgog ICAgICAgICAgICAgSGVsbG8sCiAgICAgICAgICA8L3RkPgogICAgICAgPC90cj4KICAgICAgIDx0 cj4KICAgICAgICAgICA8dGQgc3R5bGU9ImZvbnQtc2l6ZTogMTVweDtmb250LWZhbWlseTogQXJp YWw7Y29sb3I6IzRENEQ0RDtwYWRkaW5nLXRvcDoxMHB4OyI+CiAgICAgICAgICAgICAgICBNaWNo YWVsIFJpY2hhcmRzb24gaW52aXRlcyB5b3UgdG8gam9pbiB0aGlzIFdlYkV4IG1lZXRpbmcuCiAg ICAgICAgICAgICAgICAJICAgICAgICAgICA8L3RkPgogICAgICA8L3RyPgo8L3RhYmxlPgoKCgoK PHRhYmxlPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDIwcHg7Ij48dGQgc3R5bGU9ImhlaWdodDoy MHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90YWJsZT4KCQkJCQkJPHRhYmxlICB3aWR0aD0iMTAwJSI+ CgkJCQkJCQk8dHI+CgkJCQkJCQkJPHRkIHN0eWxlPSJmb250LXNpemU6MTZweDsgY29sb3I6IzRE NEQ0RCI+CgkJCQkJCQkJCTxiPlJPTEwgdXNlLW9mLXJwaTwvYj4KCQkJCQkJCQk8L3RkPgoJCQkJ CQkJPC90cj4KCQkJCQkJCTx0ciBzdHlsZT0ibWFyZ2luOjBweCI+CgkJCQkJCQkJPHRkPlR1ZXNk YXksIFNlcHRlbWJlciAyOSwgMjAxNQoJCQkJCQkJCTwvdGQ+CgkJCQkJCQk8L3RyPgoJCQkJCQkJ PHRyIHN0eWxlPSJtYXJnaW46MHB4Ij4KCQkJCQkJCQk8dGQ+OTowMCBhbSZuYnNwOyZuYnNwO3wm bmJzcDsmbmJzcDtFYXN0ZXJuIERheWxpZ2h0IFRpbWUgKE5ldyBZb3JrLCBHTVQtMDQ6MDApJm5i c3A7Jm5ic3A7fCZuYnNwOyZuYnNwOzIgaHJzCgkJCQkJCQkJPC90ZD4KCQkJCQkJCTwvdHI+CgkJ CQkJCTwvdGFibGU+Cgo8dGFibGU+PHRyIHN0eWxlPSJsaW5lLWhlaWdodDogMjBweDsiPjx0ZCBz dHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPgoJCQkJCQk8dGFibGUg c3R5bGU9IndpZHRoOmF1dG87IHdpZHRoOmF1dG8haW1wb3J0YW50Ij4KCQkJCQkJCTx0cj4KCQkJ CQkJCQk8dGQgc3R5bGU9ImNvbG9yOiMwMEFGRjk7Zm9udC1zaXplOjE2cHgiPgoJCQkJCQkJCQk8 YSBocmVmPSJodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tNmNiNWFkNzI2 ZjAzODMyMWI4YmQwNDE0NTQxNjYwYjEiCgkJCQkJCQkJCQlzdHlsZT0idGV4dC1kZWNvcmF0aW9u Om5vbmU7Zm9udC1zaXplOjE2cHg7Y29sb3I6IzAwQUZGOSI+CgkJCQkJCQkJCQk8Yj5Kb2luIFdl YkV4IG1lZXRpbmc8L2I+CgkJCQkJCQkJCTwvYT4KCQkJCQkJCQk8L3RkPgoJCQkJCQkJPC90cj4K CQkJCQkJPC90YWJsZT4KCQkJCQkJPHRhYmxlIHN0eWxlPSJ3aWR0aDphdXRvOyB3aWR0aDphdXRv IWltcG9ydGFudCI+CgkJCQkJCQk8dHIgc3R5bGU9Im1hcmdpbjowcHgiPgoJCQkJCQkJCTx0ZCBz dHlsZT0icGFkZGluZy1yaWdodDogNXB4OyI+CgkJCQkJCQkJCU1lZXRpbmcgbnVtYmVyOgoJCQkJ CQkJCTwvdGQ+CgkJCQkJCQkJPHRkPjY0MiA4MjAgNTY3CgkJCQkJCQkJPC90ZD4KCQkJCQkJCTwv dHI+CgkJCQkJCQk8dHI+CgkJCQkJCQkJPHRkIHN0eWxlPSJwYWRkaW5nLXJpZ2h0OiA1cHg7Ij5N ZWV0aW5nIHBhc3N3b3JkOjwvdGQ+CgkJCQkJCQkJPHRkPnJvbGw8L3RkPgoJCQkJCQkJPC90cj4K CQkJCQkJPC90YWJsZT4KCgoKCQoKCTx0YWJsZT48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OjIwcHgi Pjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPjx0YWJsZT48 dHI+PHRkIHN0eWxlPSJmb250LXNpemU6MTZweCI+PGI+Sm9pbiBieSBwaG9uZTwvYj48L3RkPjwv dHI+PHRyIHN0eWxlPSJtYXJnaW46MHB4Ij48dGQ+PGI+MS04NzctNjY4LTQ0OTM8L2I+Jm5ic3A7 Q2FsbC1pbiB0b2xsIGZyZWUgbnVtYmVyIChVUy9DYW5hZGEpPC90ZD48L3RyPjx0ciBzdHlsZT0i bWFyZ2luOjBweCI+PHRkPjxiPjEtNjUwLTQ3OS0zMjA4PC9iPiZuYnNwO0NhbGwtaW4gdG9sbCBu dW1iZXIgKFVTL0NhbmFkYSk8L3RkPjwvdHI+PHRyIHN0eWxlPSJtYXJnaW46MHB4Ij48dGQ+QWNj ZXNzIGNvZGU6Jm5ic3A7NjQyIDgyMCA1Njc8L3RkPjwvdHI+PHRyIHN0eWxlPSJtYXJnaW46MHB4 Ij48dGQ+PGEgaHJlZj0iaHR0cDovL3d3dy53ZWJleC5jb20vcGRmL3RvbGxmcmVlX3Jlc3RyaWN0 aW9ucy5wZGYiIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246bm9uZTtmb250LXNpemU6MTNweDtjb2xv cjojMDBBRkY5OyI+VG9sbC1mcmVlIGNhbGxpbmcgcmVzdHJpY3Rpb25zPC9hPjwvdGQ+PC90cj48 L3RhYmxlPgoKCQkJCQk8dGFibGU+PHRyIHN0eWxlPSJsaW5lLWhlaWdodDoyMHB4Ij48dGQgc3R5 bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90YWJsZT48dGFibGU+PHRyPjx0ZCBz dHlsZT0iZm9udC1zaXplOjEzcHgiPjxhIGhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0 Zi9qLnBocD9NVElEPW04YTEyNTNkYjIxNzBmNzM5YjNkOTU4NzM4OTE2MjQwZiIgc3R5bGU9InRl eHQtZGVjb3JhdGlvbjpub25lO2NvbG9yOiMwMEFGRjk7IGZvbnQtc2l6ZToxM3B4Ij5BZGQgdGhp cyBtZWV0aW5nPC9hPiB0byB5b3VyIGNhbGVuZGFyLjwvdGQ+PC90cj48L3RhYmxlPgo8dGFibGU+ PHRyIHN0eWxlPSJsaW5lLWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZu YnNwOzwvdGQ+PC90cj48L3RhYmxlPgo8dGFibGU+CiAgICA8dHI+CiAgICAgICA8dGQgc3R5bGU9 ImZvbnQtc2l6ZTogMTNweDtmb250LWZhbWlseTogQXJpYWw7Y29sb3I6ICM2NjY2NjY7Ij4KICAg ICAgICBDYW4ndCBqb2luIHRoZSBtZWV0aW5nPwogICAgIAk8YSBocmVmPSJodHRwczovL2lldGYu d2ViZXguY29tL2lldGYvbWMiIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246bm9uZTtmb250LXNpemU6 MTNweDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjojMDBBRkY5O2ZvbnQtY29sb3I6IzAwQUZGOTsi PgogICAgICAgIAlDb250YWN0IHN1cHBvcnQuPC9hPgoJCTwvdGQ+CiAgICA8L3RyPgo8L3RhYmxl Pgo8dGFibGU+PHRyIHN0eWxlPSJsaW5lLWhlaWdodDogMTBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0 OjEwcHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPgoJCQkJCQk8dGFibGU+CgkJCQkJCQk8dHI+ CgkJCQkJCQkJPHRkIHN0eWxlPSJmb250LXNpemU6MTJweDtjb2xvcjogI0EwQTBBMDsiPgoJCQkJ CQkJCQlJTVBPUlRBTlQgTk9USUNFOiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2ViRXggc2Vydmlj ZSBhbGxvd3MgYXVkaW8gYW5kIG90aGVyIGluZm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNz aW9uIHRvIGJlIHJlY29yZGVkLCB3aGljaCBtYXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwg bWF0dGVyLiBCeSBqb2luaW5nIHRoaXMgc2Vzc2lvbiwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2Vu dCB0byBzdWNoIHJlY29yZGluZ3MuIElmIHlvdSBkbyBub3QgY29uc2VudCB0byBiZWluZyByZWNv cmRlZCwgZGlzY3VzcyB5b3VyIGNvbmNlcm5zIHdpdGggdGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4g dGhlIHNlc3Npb24uPC90ZD4KCQkJCQkJCTwvdHI+CgkJCQkJCTwvdGFibGU+CgkJCQk8L3RkPgoJ CQk8L3RyPgoJCTwvdGFibGU+Cgk8L3RkPgogICA8L3RyPgo8L3RhYmxlPgoKPC9ib2R5Pg== ------=_Part_30545_1271784162.1443186413233-- ------=_Part_30544_848233964.1443186413233 Content-Type: application/octet-stream; name="WebEx_Meeting.ics" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="WebEx_Meeting.ics" QkVHSU46VkNBTEVOREFSClBST0RJRDotLy9NaWNyb3NvZnQgQ29ycG9yYXRpb24vL091dGxvb2sg MTAuMCBNSU1FRElSLy9FTgpWRVJTSU9OOjIuMApNRVRIT0Q6UkVRVUVTVApCRUdJTjpWVElNRVpP TkUKVFpJRDpFYXN0ZXJuIFRpbWUKQkVHSU46U1RBTkRBUkQKRFRTVEFSVDoyMDEzMTEwMVQwMjAw MDAKUlJVTEU6RlJFUT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0xU1U7QllNT05USD0xMQpUWk9G RlNFVEZST006LTA0MDAKVFpPRkZTRVRUTzotMDUwMApUWk5BTUU6U3RhbmRhcmQgVGltZQpFTkQ6 U1RBTkRBUkQKQkVHSU46REFZTElHSFQKRFRTVEFSVDoyMDEzMDMwMVQwMjAwMDAKUlJVTEU6RlJF UT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0yU1U7QllNT05USD0zClRaT0ZGU0VURlJPTTotMDUw MApUWk9GRlNFVFRPOi0wNDAwClRaTkFNRTpEYXlsaWdodCBTYXZpbmdzIFRpbWUKRU5EOkRBWUxJ R0hUCkVORDpWVElNRVpPTkUKQkVHSU46VkVWRU5UCkFUVEVOREVFO0NOPSIiO1JPTEU9UkVRLVBB UlRJQ0lQQU5UO1JTVlA9VFJVRTpNQUlMVE86cm9sbEBpZXRmLm9yZwpPUkdBTklaRVI7Q049Ik1p Y2hhZWwgUmljaGFyZHNvbiI6TUFJTFRPOm1jcitub21jb21Ac2FuZGVsbWFuLmNhCkRUU1RBUlQ7 VFpJRD0iRWFzdGVybiBUaW1lIjoyMDE1MDkyOVQwOTAwMDAKRFRFTkQ7VFpJRD0iRWFzdGVybiBU aW1lIjoyMDE1MDkyOVQxMTAwMDAKTE9DQVRJT046aHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRm ClRSQU5TUDpPUEFRVUUKU0VRVUVOQ0U6MTQ0MzE4NjQxMwpVSUQ6NzAxYjUzMjQtMzRkZS00ZDY5 LWJjY2UtMGVjZDVjYjliMzVjCkRUU1RBTVA6MjAxNTA5MjlUMTMwMDAwWgpERVNDUklQVElPTjpc blxuXG5KT0lOIFdFQkVYIE1FRVRJTkdcbmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBo cD9NVElEPW04NmYxMzkyNmYyNWY4YTBkNzdlYzVhYjVlMDlhMzA1Y1xuTWVldGluZyBudW1iZXI6 IDY0MiA4MjAgNTY3XG5NZWV0aW5nIHBhc3N3b3JkOiByb2xsXG5cblxuSk9JTiBCWSBQSE9ORVxu MS04NzctNjY4LTQ0OTMgQ2FsbC1pbiB0b2xsIGZyZWUgbnVtYmVyIChVUy9DYW5hZGEpIFxuMS02 NTAtNDc5LTMyMDggQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKVxuQWNjZXNzIGNvZGU6 IDY0MiA4MjAgNTY3XG5cblRvbGwtZnJlZSBkaWFsaW5nIHJlc3RyaWN0aW9uczogXG5odHRwOi8v d3d3LndlYmV4LmNvbS9wZGYvdG9sbGZyZWVfcmVzdHJpY3Rpb25zLnBkZlxuXG5cblxuQ2FuJ3Qg am9pbiB0aGUgbWVldGluZz8gQ29udGFjdCBzdXBwb3J0IGhlcmU6XG5odHRwczovL2lldGYud2Vi ZXguY29tL2lldGYvbWNcblxuXG5JTVBPUlRBTlQgTk9USUNFOiBQbGVhc2Ugbm90ZSB0aGF0IHRo aXMgV2ViRXggc2VydmljZSBhbGxvd3MgYXVkaW8gYW5kIG90aGVyIGluZm9ybWF0aW9uIHNlbnQg ZHVyaW5nIHRoZSBzZXNzaW9uIHRvIGJlIHJlY29yZGVkLCB3aGljaCBtYXkgYmUgZGlzY292ZXJh YmxlIGluIGEgbGVnYWwgbWF0dGVyLiBCeSBqb2luaW5nIHRoaXMgc2Vzc2lvbiwgeW91IGF1dG9t YXRpY2FsbHkgY29uc2VudCB0byBzdWNoIHJlY29yZGluZ3MuIElmIHlvdSBkbyBub3QgY29uc2Vu dCB0byBiZWluZyByZWNvcmRlZCwgZGlzY3VzcyB5b3VyIGNvbmNlcm5zIHdpdGggdGhlIGhvc3Qg b3IgZG8gbm90IGpvaW4gdGhlIHNlc3Npb24uXG4KWC1BTFQtREVTQztGTVRUWVBFPXRleHQvaHRt bDoJPEZPTlQgU0laRT0iMSIgRkFDRT0iQVJJQUwiPiZuYnNwOzxCUj4gPEZPTlQgU0laRT0iNCIg RkFDRT0iQVJJQUwiPgkJPGEJCQkJCWhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9q LnBocD9NVElEPW04NmYxMzkyNmYyNWY4YTBkNzdlYzVhYjVlMDlhMzA1YyI+PEZPTlQgU0laRT0i MyIgQ09MT1I9IiMwMEFGRjkiIEZBQ0U9IkFyaWFsIj5Kb2luIFdlYkV4IG1lZXRpbmc8L0ZPTlQ+ PC9hPgkJCTx0YWJsZT4JCQkJPHRyPgkJCQkJPHRkPgkJCQkJCTxGT05UIFNJWkU9IjIiIENPTE9S PSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+TWVldGluZyBudW1iZXI6PC9GT05UPgkJCQkJPC90ZD4J CQkJCTx0ZD4JCQkJCQk8Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwi PjY0MiA4MjAgNTY3PC9GT05UPgkJCQkJPC90ZD4JCQkJPC90cj4JCQk8L3RhYmxlPgkJCTx0YWJs ZT48dHI+PHRkPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+TWVl dGluZyBwYXNzd29yZDo8L0ZPTlQ+PC90ZD48dGQ+PEZPTlQgU0laRT0iMiIgIENPTE9SPSIjNjY2 NjY2IiBGQUNFPSJhcmlhbCI+cm9sbDwvRk9OVD48L3RkPjwvdHI+PC90YWJsZT4JCTwvRk9OVD48 Rk9OVCBTSVpFPSIxIiBGQUNFPSJBUklBTCI+Jm5ic3A7PEJSPiZuYnNwOzxCUj48L0ZPTlQ+PEZP TlQgU0laRT0iNCIgRkFDRT0iQVJJQUwiPjxGT05UIFNJWkU9IjMiIENPTE9SPSIjNjY2NjY2IiBG QUNFPSJhcmlhbCI+Sm9pbiBieSBwaG9uZTwvRk9OVD4mbmJzcDsgPEJSPjxGT05UIFNJWkU9IjIi IENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+PHN0cm9uZz4xLTg3Ny02NjgtNDQ5Mzwvc3Ry b25nPiZuYnNwO0NhbGwtaW4gdG9sbCBmcmVlIG51bWJlciAoVVMvQ2FuYWRhKTwvRk9OVD4mbmJz cDsgPEJSPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+PHN0cm9u Zz4xLTY1MC00NzktMzIwODwvc3Ryb25nPiZuYnNwO0NhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0Nh bmFkYSk8L0ZPTlQ+Jm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFD RT0iYXJpYWwiPkFjY2VzcyBjb2RlOiA2NDIgODIwIDU2NzwvRk9OVD4mbmJzcDsgPEJSPjxhIGhy ZWY9Imh0dHA6Ly93d3cud2ViZXguY29tL3BkZi90b2xsZnJlZV9yZXN0cmljdGlvbnMucGRmIj48 Rk9OVCBTSVpFPSIxIiBDT0xPUj0iIzAwQUZGOSIgRkFDRT0iYXJpYWwiPlRvbGwtZnJlZSBjYWxs aW5nIHJlc3RyaWN0aW9uczwvRk9OVD48L2E+ICZuYnNwOyA8QlI+PC9GT05UPjxCUj48QlI+CSZu YnNwOzxCUj4JPEZPTlQgU0laRT0iMSIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj4JCQkJ Q2FuJ3Qgam9pbiB0aGUgbWVldGluZz88L0ZPTlQ+CTxhIGhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJl eC5jb20vaWV0Zi9tYyI+CTxGT05UIFNJWkU9IjEiIENPTE9SPSIjMDBBRkY5IiBGQUNFPSJBcmlh bCI+Q29udGFjdCBzdXBwb3J0LjwvRk9OVD48L2E+CSZuYnNwOzxCUj4mbmJzcDs8QlI+PEZPTlQg Q09MT1I9IiNBMEEwQTAiIHNpemU9IjEiIEZBQ0U9ImFyaWFsIj5JTVBPUlRBTlQgTk9USUNFOiBQ bGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2ViRXggc2VydmljZSBhbGxvd3MgYXVkaW8gYW5kIG90aGVy IGluZm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRvIGJlIHJlY29yZGVkLCB3aGlj aCBtYXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVyLiBCeSBqb2luaW5nIHRoaXMg c2Vzc2lvbiwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0byBzdWNoIHJlY29yZGluZ3MuIElm IHlvdSBkbyBub3QgY29uc2VudCB0byBiZWluZyByZWNvcmRlZCwgZGlzY3VzcyB5b3VyIGNvbmNl cm5zIHdpdGggdGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhlIHNlc3Npb24uPC9GT05UPjwvRk9O VD4KU1VNTUFSWTpST0xMIHVzZS1vZi1ycGkKUFJJT1JJVFk6NQpDTEFTUzpQVUJMSUMKQkVHSU46 VkFMQVJNClRSSUdHRVI6LVBUNU0KQUNUSU9OOkRJU1BMQVkKREVTQ1JJUFRJT046UmVtaW5kZXIK RU5EOlZBTEFSTQpFTkQ6VkVWRU5UCkVORDpWQ0FMRU5EQVIK ------=_Part_30544_848233964.1443186413233-- From nobody Fri Sep 25 06:08:21 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B7861A0119 for ; Fri, 25 Sep 2015 06:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BX5wRP9b9u97 for ; Fri, 25 Sep 2015 06:08:17 -0700 (PDT) Received: from sjmda12.webex.com (sjmda12.webex.com [64.68.124.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15BDC1A01F2 for ; Fri, 25 Sep 2015 06:08:17 -0700 (PDT) Received: from jva2tc206.webex.com (sjc02-wxp00-lbace03-core-vl120-np10b-4.webex.com [64.68.121.239]) by sjmda12.webex.com (Postfix) with ESMTP id D7777316E for ; Fri, 25 Sep 2015 13:08:16 +0000 (GMT) Received: from jva2tc206.webex.com (localhost [127.0.0.1]) by jva2tc206.webex.com (Postfix) with ESMTP id 9DDC3A0625 for ; Fri, 25 Sep 2015 13:08:16 +0000 (GMT) Date: Fri, 25 Sep 2015 13:08:16 +0000 (GMT) From: Michael Richardson To: roll@ietf.org Message-ID: <355328634.30555.1443186496645.JavaMail.nobody@jva2tc206.webex.com> MIME-Version: 1.0 Content-Type: multipart/Mixed; boundary="----=_Part_30553_885815170.1443186496644" X-Priority: 3 Importance: normal Archived-At: Subject: [Roll] WebEx meeting changed: ROLL use-of-rpi X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mcr+nomcom@sandelman.ca, 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 Sep 2015 13:08:18 -0000 ------=_Part_30553_885815170.1443186496644 Content-Type: multipart/Alternative; boundary="----=_Part_30554_1538921186.1443186496644" ------=_Part_30554_1538921186.1443186496644 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: base64 CkhlbGxvLAoKTWljaGFlbCBSaWNoYXJkc29uIGNoYW5nZWQgdGhlIFdlYkV4IG1lZXRpbmcgaW5m b3JtYXRpb24uCgoKUk9MTCB1c2Utb2YtcnBpClR1ZXNkYXksIFNlcHRlbWJlciAyOSwgMjAxNQo5 OjAwIGFtICB8ICBFYXN0ZXJuIERheWxpZ2h0IFRpbWUgKE5ldyBZb3JrLCBHTVQtMDQ6MDApICB8 ICAyIGhycyAxNSBtaW5zCgoKSk9JTiBXRUJFWCBNRUVUSU5HCmh0dHBzOi8vaWV0Zi53ZWJleC5j b20vaWV0Zi9qLnBocD9NVElEPW02Y2I1YWQ3MjZmMDM4MzIxYjhiZDA0MTQ1NDE2NjBiMQpNZWV0 aW5nIG51bWJlcjogNjQyIDgyMCA1NjcKTWVldGluZyBwYXNzd29yZDogcm9sbAoKDQpKT0lOIEJZ IFBIT05FDQoxLTg3Ny02NjgtNDQ5MyBDYWxsLWluIHRvbGwgZnJlZSBudW1iZXIgKFVTL0NhbmFk YSkgCjEtNjUwLTQ3OS0zMjA4IENhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSkKQWNjZXNz IGNvZGU6IDY0MiA4MjAgNTY3CgpUb2xsLWZyZWUgZGlhbGluZyByZXN0cmljdGlvbnM6IApodHRw Oi8vd3d3LndlYmV4LmNvbS9wZGYvdG9sbGZyZWVfcmVzdHJpY3Rpb25zLnBkZg0KDQoKQWRkIHRo aXMgbWVldGluZyB0byB5b3VyIGNhbGVuZGFyOgpodHRwczovL2lldGYud2ViZXguY29tL2lldGYv ai5waHA/TVRJRD1tNWNiZGJlODUxNmRhMzUzZmU0ZGE5MWI3MWI5MmZjNDMNCg0KCkNhbid0IGpv aW4gdGhlIG1lZXRpbmc/IENvbnRhY3Qgc3VwcG9ydCBoZXJlOgpodHRwczovL2lldGYud2ViZXgu Y29tL2lldGYvbWMKCgpJTVBPUlRBTlQgTk9USUNFOiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2Vi RXggc2VydmljZSBhbGxvd3MgYXVkaW8gYW5kIG90aGVyIGluZm9ybWF0aW9uIHNlbnQgZHVyaW5n IHRoZSBzZXNzaW9uIHRvIGJlIHJlY29yZGVkLCB3aGljaCBtYXkgYmUgZGlzY292ZXJhYmxlIGlu IGEgbGVnYWwgbWF0dGVyLiBCeSBqb2luaW5nIHRoaXMgc2Vzc2lvbiwgeW91IGF1dG9tYXRpY2Fs bHkgY29uc2VudCB0byBzdWNoIHJlY29yZGluZ3MuIElmIHlvdSBkbyBub3QgY29uc2VudCB0byBi ZWluZyByZWNvcmRlZCwgZGlzY3VzcyB5b3VyIGNvbmNlcm5zIHdpdGggdGhlIGhvc3Qgb3IgZG8g bm90IGpvaW4gdGhlIHNlc3Npb24uCg== ------=_Part_30554_1538921186.1443186496644 Content-Type: text/html;charset=UTF-8 Content-Transfer-Encoding: base64 PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPjxtZXRhIG5hbWU9InZpZXdwb3J0IiBjb250ZW50PSJ3aWR0aD1kZXZpY2Utd2lk dGgsIGluaXRpYWwtc2NhbGU9MSIgLz48Ym9keT48c3R5bGUgdHlwZT0idGV4dC9jc3MiPgpkaXYs cCx0ZCxzcGFuIHt3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7d29yZC1icmVhazogbm9ybWFsO30KCnRh YmxlIHtib3JkZXItY29sbGFwc2U6IHNlcGFyYXRlOyBib3JkZXI6IDA7Ym9yZGVyLXNwYWNpbmc6 IDA7Ym9yZGVyLWNvbG9yOiB3aGl0ZTsgd2lkdGg6MTAwJSFpbXBvcnRhbnQ7d2lkdGg6NTI1cHg7 IG1heC13aWR0aDo1MjVweCFpbXBvcnRhbnQ7IG1pbi13aWR0aDogMjc5cHghaW1wb3J0YW50O30K dHIge2xpbmUtaGVpZ2h0OiAyMHB4O30KCnRkLGEge2ZvbnQtc2l6ZTogMTVweDtmb250LWZhbWls eTogQXJpYWw7Y29sb3I6ICM2NjY2NjY7cGFkZGluZzowO30KPC9zdHlsZT4KCjx0YWJsZSBzdHls ZT0icGFkZGluZzowOyBtYXJnaW46MCIgd2lkdGg9IjEwMCUiIGFsaWduPSJsZWZ0Ij4KICAgPHRy PgogICAgICA8dGQgc3R5bGU9InBhZGRpbmctdG9wOjVweDsiPgogICAgICAgIDx0YWJsZSBzdHls ZT0id2lkdGg6IDUyNXB4O21hcmdpbi1sZWZ0OjVweCIgYWxpZ249ImxlZnQiPgoJCQk8dHI+CgkJ CQk8dGQgdmFsaWduPSJ0b3AiPgoKPHRhYmxlPgogICAgICAgPHRyPgogICAgICAgICAgPHRkIHN0 eWxlPSJmb250LXNpemU6IDE1cHg7Zm9udC1mYW1pbHk6IEFyaWFsO2NvbG9yOiM0RDRENEQiPgog ICAgICAgICAgICAgSGVsbG8sCiAgICAgICAgICA8L3RkPgogICAgICAgPC90cj4KICAgICAgIDx0 cj4KICAgICAgICAgICA8dGQgc3R5bGU9ImZvbnQtc2l6ZTogMTVweDtmb250LWZhbWlseTogQXJp YWw7Y29sb3I6IzRENEQ0RDtwYWRkaW5nLXRvcDoxMHB4OyI+CiAgICAgICAgICAgICAgICBNaWNo YWVsIFJpY2hhcmRzb24gY2hhbmdlZCB0aGUgV2ViRXggbWVldGluZyBpbmZvcm1hdGlvbi4KICAg ICAgICAgICAgICAgIAkgICAgICAgICAgIDwvdGQ+CiAgICAgIDwvdHI+CjwvdGFibGU+CgoKCgo8 dGFibGU+PHRyIHN0eWxlPSJsaW5lLWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIw cHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPgoJCQkJCQk8dGFibGUgIHdpZHRoPSIxMDAlIj4K CQkJCQkJCTx0cj4KCQkJCQkJCQk8dGQgc3R5bGU9ImZvbnQtc2l6ZToxNnB4OyBjb2xvcjojNEQ0 RDREIj4KCQkJCQkJCQkJPGI+Uk9MTCB1c2Utb2YtcnBpPC9iPgoJCQkJCQkJCTwvdGQ+CgkJCQkJ CQk8L3RyPgoJCQkJCQkJPHRyIHN0eWxlPSJtYXJnaW46MHB4Ij4KCQkJCQkJCQk8dGQ+VHVlc2Rh eSwgU2VwdGVtYmVyIDI5LCAyMDE1CgkJCQkJCQkJPC90ZD4KCQkJCQkJCTwvdHI+CgkJCQkJCQk8 dHIgc3R5bGU9Im1hcmdpbjowcHgiPgoJCQkJCQkJCTx0ZD45OjAwIGFtJm5ic3A7Jm5ic3A7fCZu YnNwOyZuYnNwO0Vhc3Rlcm4gRGF5bGlnaHQgVGltZSAoTmV3IFlvcmssIEdNVC0wNDowMCkmbmJz cDsmbmJzcDt8Jm5ic3A7Jm5ic3A7MiBocnMgMTUgbWlucwoJCQkJCQkJCTwvdGQ+CgkJCQkJCQk8 L3RyPgoJCQkJCQk8L3RhYmxlPgoKPHRhYmxlPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDIwcHg7 Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90YWJsZT4KCQkJCQkJ PHRhYmxlIHN0eWxlPSJ3aWR0aDphdXRvOyB3aWR0aDphdXRvIWltcG9ydGFudCI+CgkJCQkJCQk8 dHI+CgkJCQkJCQkJPHRkIHN0eWxlPSJjb2xvcjojMDBBRkY5O2ZvbnQtc2l6ZToxNnB4Ij4KCQkJ CQkJCQkJPGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTZj YjVhZDcyNmYwMzgzMjFiOGJkMDQxNDU0MTY2MGIxIgoJCQkJCQkJCQkJc3R5bGU9InRleHQtZGVj b3JhdGlvbjpub25lO2ZvbnQtc2l6ZToxNnB4O2NvbG9yOiMwMEFGRjkiPgoJCQkJCQkJCQkJPGI+ Sm9pbiBXZWJFeCBtZWV0aW5nPC9iPgoJCQkJCQkJCQk8L2E+CgkJCQkJCQkJPC90ZD4KCQkJCQkJ CTwvdHI+CgkJCQkJCTwvdGFibGU+CgkJCQkJCTx0YWJsZSBzdHlsZT0id2lkdGg6YXV0bzsgd2lk dGg6YXV0byFpbXBvcnRhbnQiPgoJCQkJCQkJPHRyIHN0eWxlPSJtYXJnaW46MHB4Ij4KCQkJCQkJ CQk8dGQgc3R5bGU9InBhZGRpbmctcmlnaHQ6IDVweDsiPgoJCQkJCQkJCQlNZWV0aW5nIG51bWJl cjoKCQkJCQkJCQk8L3RkPgoJCQkJCQkJCTx0ZD42NDIgODIwIDU2NwoJCQkJCQkJCTwvdGQ+CgkJ CQkJCQk8L3RyPgoJCQkJCQkJPHRyPgoJCQkJCQkJCTx0ZCBzdHlsZT0icGFkZGluZy1yaWdodDog NXB4OyI+TWVldGluZyBwYXNzd29yZDo8L3RkPgoJCQkJCQkJCTx0ZD5yb2xsPC90ZD4KCQkJCQkJ CTwvdHI+CgkJCQkJCTwvdGFibGU+CgoKCgkKCgk8dGFibGU+PHRyIHN0eWxlPSJsaW5lLWhlaWdo dDoyMHB4Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90YWJsZT48 dGFibGU+PHRyPjx0ZCBzdHlsZT0iZm9udC1zaXplOjE2cHgiPjxiPkpvaW4gYnkgcGhvbmU8L2I+ PC90ZD48L3RyPjx0ciBzdHlsZT0ibWFyZ2luOjBweCI+PHRkPjxiPjEtODc3LTY2OC00NDkzPC9i PiZuYnNwO0NhbGwtaW4gdG9sbCBmcmVlIG51bWJlciAoVVMvQ2FuYWRhKTwvdGQ+PC90cj48dHIg c3R5bGU9Im1hcmdpbjowcHgiPjx0ZD48Yj4xLTY1MC00NzktMzIwODwvYj4mbmJzcDtDYWxsLWlu IHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpPC90ZD48L3RyPjx0ciBzdHlsZT0ibWFyZ2luOjBweCI+ PHRkPkFjY2VzcyBjb2RlOiZuYnNwOzY0MiA4MjAgNTY3PC90ZD48L3RyPjx0ciBzdHlsZT0ibWFy Z2luOjBweCI+PHRkPjxhIGhyZWY9Imh0dHA6Ly93d3cud2ViZXguY29tL3BkZi90b2xsZnJlZV9y ZXN0cmljdGlvbnMucGRmIiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOm5vbmU7Zm9udC1zaXplOjEz cHg7Y29sb3I6IzAwQUZGOTsiPlRvbGwtZnJlZSBjYWxsaW5nIHJlc3RyaWN0aW9uczwvYT48L3Rk PjwvdHI+PC90YWJsZT4KCgkJCQkJPHRhYmxlPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6MjBweCI+ PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+PHRhYmxlPjx0 cj48dGQgc3R5bGU9ImZvbnQtc2l6ZToxM3B4Ij48YSBocmVmPSJodHRwczovL2lldGYud2ViZXgu Y29tL2lldGYvai5waHA/TVRJRD1tNWNiZGJlODUxNmRhMzUzZmU0ZGE5MWI3MWI5MmZjNDMiIHN0 eWxlPSJ0ZXh0LWRlY29yYXRpb246bm9uZTtjb2xvcjojMDBBRkY5OyBmb250LXNpemU6MTNweCI+ QWRkIHRoaXMgbWVldGluZzwvYT4gdG8geW91ciBjYWxlbmRhci48L3RkPjwvdHI+PC90YWJsZT4K PHRhYmxlPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDIwcHg7Ij48dGQgc3R5bGU9ImhlaWdodDoy MHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90YWJsZT4KPHRhYmxlPgogICAgPHRyPgogICAgICAgPHRk IHN0eWxlPSJmb250LXNpemU6IDEzcHg7Zm9udC1mYW1pbHk6IEFyaWFsO2NvbG9yOiAjNjY2NjY2 OyI+CiAgICAgICAgQ2FuJ3Qgam9pbiB0aGUgbWVldGluZz8KICAgICAJPGEgaHJlZj0iaHR0cHM6 Ly9pZXRmLndlYmV4LmNvbS9pZXRmL21jIiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOm5vbmU7Zm9u dC1zaXplOjEzcHg7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6IzAwQUZGOTtmb250LWNvbG9yOiMw MEFGRjk7Ij4KICAgICAgICAJQ29udGFjdCBzdXBwb3J0LjwvYT4KCQk8L3RkPgogICAgPC90cj4K PC90YWJsZT4KPHRhYmxlPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDEwcHg7Ij48dGQgc3R5bGU9 ImhlaWdodDoxMHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90YWJsZT4KCQkJCQkJPHRhYmxlPgoJCQkJ CQkJPHRyPgoJCQkJCQkJCTx0ZCBzdHlsZT0iZm9udC1zaXplOjEycHg7Y29sb3I6ICNBMEEwQTA7 Ij4KCQkJCQkJCQkJSU1QT1JUQU5UIE5PVElDRTogUGxlYXNlIG5vdGUgdGhhdCB0aGlzIFdlYkV4 IHNlcnZpY2UgYWxsb3dzIGF1ZGlvIGFuZCBvdGhlciBpbmZvcm1hdGlvbiBzZW50IGR1cmluZyB0 aGUgc2Vzc2lvbiB0byBiZSByZWNvcmRlZCwgd2hpY2ggbWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBh IGxlZ2FsIG1hdHRlci4gQnkgam9pbmluZyB0aGlzIHNlc3Npb24sIHlvdSBhdXRvbWF0aWNhbGx5 IGNvbnNlbnQgdG8gc3VjaCByZWNvcmRpbmdzLiBJZiB5b3UgZG8gbm90IGNvbnNlbnQgdG8gYmVp bmcgcmVjb3JkZWQsIGRpc2N1c3MgeW91ciBjb25jZXJucyB3aXRoIHRoZSBob3N0IG9yIGRvIG5v dCBqb2luIHRoZSBzZXNzaW9uLjwvdGQ+CgkJCQkJCQk8L3RyPgoJCQkJCQk8L3RhYmxlPgoJCQkJ PC90ZD4KCQkJPC90cj4KCQk8L3RhYmxlPgoJPC90ZD4KICAgPC90cj4KPC90YWJsZT4KCjwvYm9k eT4= ------=_Part_30554_1538921186.1443186496644-- ------=_Part_30553_885815170.1443186496644 Content-Type: application/octet-stream; name="WebEx_Meeting.ics" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="WebEx_Meeting.ics" QkVHSU46VkNBTEVOREFSClBST0RJRDotLy9NaWNyb3NvZnQgQ29ycG9yYXRpb24vL091dGxvb2sg MTAuMCBNSU1FRElSLy9FTgpWRVJTSU9OOjIuMApNRVRIT0Q6UkVRVUVTVApCRUdJTjpWVElNRVpP TkUKVFpJRDpFYXN0ZXJuIFRpbWUKQkVHSU46U1RBTkRBUkQKRFRTVEFSVDoyMDEzMTEwMVQwMjAw MDAKUlJVTEU6RlJFUT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0xU1U7QllNT05USD0xMQpUWk9G RlNFVEZST006LTA0MDAKVFpPRkZTRVRUTzotMDUwMApUWk5BTUU6U3RhbmRhcmQgVGltZQpFTkQ6 U1RBTkRBUkQKQkVHSU46REFZTElHSFQKRFRTVEFSVDoyMDEzMDMwMVQwMjAwMDAKUlJVTEU6RlJF UT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0yU1U7QllNT05USD0zClRaT0ZGU0VURlJPTTotMDUw MApUWk9GRlNFVFRPOi0wNDAwClRaTkFNRTpEYXlsaWdodCBTYXZpbmdzIFRpbWUKRU5EOkRBWUxJ R0hUCkVORDpWVElNRVpPTkUKQkVHSU46VkVWRU5UCkFUVEVOREVFO0NOPSIiO1JPTEU9UkVRLVBB UlRJQ0lQQU5UO1JTVlA9VFJVRTpNQUlMVE86cm9sbEBpZXRmLm9yZwpPUkdBTklaRVI7Q049Ik1p Y2hhZWwgUmljaGFyZHNvbiI6TUFJTFRPOm1jcitub21jb21Ac2FuZGVsbWFuLmNhCkRUU1RBUlQ7 VFpJRD0iRWFzdGVybiBUaW1lIjoyMDE1MDkyOVQwOTAwMDAKRFRFTkQ7VFpJRD0iRWFzdGVybiBU aW1lIjoyMDE1MDkyOVQxMTE1MDAKTE9DQVRJT046aHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRm ClRSQU5TUDpPUEFRVUUKU0VRVUVOQ0U6MTQ0MzE4NjQ5NgpVSUQ6NzAxYjUzMjQtMzRkZS00ZDY5 LWJjY2UtMGVjZDVjYjliMzVjCkRUU1RBTVA6MjAxNTA5MjlUMTMwMDAwWgpERVNDUklQVElPTjpc blxuXG5KT0lOIFdFQkVYIE1FRVRJTkdcbmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBo cD9NVElEPW04NmYxMzkyNmYyNWY4YTBkNzdlYzVhYjVlMDlhMzA1Y1xuTWVldGluZyBudW1iZXI6 IDY0MiA4MjAgNTY3XG5NZWV0aW5nIHBhc3N3b3JkOiByb2xsXG5cblxuSk9JTiBCWSBQSE9ORVxu MS04NzctNjY4LTQ0OTMgQ2FsbC1pbiB0b2xsIGZyZWUgbnVtYmVyIChVUy9DYW5hZGEpIFxuMS02 NTAtNDc5LTMyMDggQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKVxuQWNjZXNzIGNvZGU6 IDY0MiA4MjAgNTY3XG5cblRvbGwtZnJlZSBkaWFsaW5nIHJlc3RyaWN0aW9uczogXG5odHRwOi8v d3d3LndlYmV4LmNvbS9wZGYvdG9sbGZyZWVfcmVzdHJpY3Rpb25zLnBkZlxuXG5cblxuQ2FuJ3Qg am9pbiB0aGUgbWVldGluZz8gQ29udGFjdCBzdXBwb3J0IGhlcmU6XG5odHRwczovL2lldGYud2Vi ZXguY29tL2lldGYvbWNcblxuXG5JTVBPUlRBTlQgTk9USUNFOiBQbGVhc2Ugbm90ZSB0aGF0IHRo aXMgV2ViRXggc2VydmljZSBhbGxvd3MgYXVkaW8gYW5kIG90aGVyIGluZm9ybWF0aW9uIHNlbnQg ZHVyaW5nIHRoZSBzZXNzaW9uIHRvIGJlIHJlY29yZGVkLCB3aGljaCBtYXkgYmUgZGlzY292ZXJh YmxlIGluIGEgbGVnYWwgbWF0dGVyLiBCeSBqb2luaW5nIHRoaXMgc2Vzc2lvbiwgeW91IGF1dG9t YXRpY2FsbHkgY29uc2VudCB0byBzdWNoIHJlY29yZGluZ3MuIElmIHlvdSBkbyBub3QgY29uc2Vu dCB0byBiZWluZyByZWNvcmRlZCwgZGlzY3VzcyB5b3VyIGNvbmNlcm5zIHdpdGggdGhlIGhvc3Qg b3IgZG8gbm90IGpvaW4gdGhlIHNlc3Npb24uXG4KWC1BTFQtREVTQztGTVRUWVBFPXRleHQvaHRt bDoJPEZPTlQgU0laRT0iMSIgRkFDRT0iQVJJQUwiPiZuYnNwOzxCUj4gPEZPTlQgU0laRT0iNCIg RkFDRT0iQVJJQUwiPgkJPGEJCQkJCWhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9q LnBocD9NVElEPW04NmYxMzkyNmYyNWY4YTBkNzdlYzVhYjVlMDlhMzA1YyI+PEZPTlQgU0laRT0i MyIgQ09MT1I9IiMwMEFGRjkiIEZBQ0U9IkFyaWFsIj5Kb2luIFdlYkV4IG1lZXRpbmc8L0ZPTlQ+ PC9hPgkJCTx0YWJsZT4JCQkJPHRyPgkJCQkJPHRkPgkJCQkJCTxGT05UIFNJWkU9IjIiIENPTE9S PSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+TWVldGluZyBudW1iZXI6PC9GT05UPgkJCQkJPC90ZD4J CQkJCTx0ZD4JCQkJCQk8Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwi PjY0MiA4MjAgNTY3PC9GT05UPgkJCQkJPC90ZD4JCQkJPC90cj4JCQk8L3RhYmxlPgkJCTx0YWJs ZT48dHI+PHRkPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+TWVl dGluZyBwYXNzd29yZDo8L0ZPTlQ+PC90ZD48dGQ+PEZPTlQgU0laRT0iMiIgIENPTE9SPSIjNjY2 NjY2IiBGQUNFPSJhcmlhbCI+cm9sbDwvRk9OVD48L3RkPjwvdHI+PC90YWJsZT4JCTwvRk9OVD48 Rk9OVCBTSVpFPSIxIiBGQUNFPSJBUklBTCI+Jm5ic3A7PEJSPiZuYnNwOzxCUj48L0ZPTlQ+PEZP TlQgU0laRT0iNCIgRkFDRT0iQVJJQUwiPjxGT05UIFNJWkU9IjMiIENPTE9SPSIjNjY2NjY2IiBG QUNFPSJhcmlhbCI+Sm9pbiBieSBwaG9uZTwvRk9OVD4mbmJzcDsgPEJSPjxGT05UIFNJWkU9IjIi IENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+PHN0cm9uZz4xLTg3Ny02NjgtNDQ5Mzwvc3Ry b25nPiZuYnNwO0NhbGwtaW4gdG9sbCBmcmVlIG51bWJlciAoVVMvQ2FuYWRhKTwvRk9OVD4mbmJz cDsgPEJSPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+PHN0cm9u Zz4xLTY1MC00NzktMzIwODwvc3Ryb25nPiZuYnNwO0NhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0Nh bmFkYSk8L0ZPTlQ+Jm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFD RT0iYXJpYWwiPkFjY2VzcyBjb2RlOiA2NDIgODIwIDU2NzwvRk9OVD4mbmJzcDsgPEJSPjxhIGhy ZWY9Imh0dHA6Ly93d3cud2ViZXguY29tL3BkZi90b2xsZnJlZV9yZXN0cmljdGlvbnMucGRmIj48 Rk9OVCBTSVpFPSIxIiBDT0xPUj0iIzAwQUZGOSIgRkFDRT0iYXJpYWwiPlRvbGwtZnJlZSBjYWxs aW5nIHJlc3RyaWN0aW9uczwvRk9OVD48L2E+ICZuYnNwOyA8QlI+PC9GT05UPjxCUj48QlI+CSZu YnNwOzxCUj4JPEZPTlQgU0laRT0iMSIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj4JCQkJ Q2FuJ3Qgam9pbiB0aGUgbWVldGluZz88L0ZPTlQ+CTxhIGhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJl eC5jb20vaWV0Zi9tYyI+CTxGT05UIFNJWkU9IjEiIENPTE9SPSIjMDBBRkY5IiBGQUNFPSJBcmlh bCI+Q29udGFjdCBzdXBwb3J0LjwvRk9OVD48L2E+CSZuYnNwOzxCUj4mbmJzcDs8QlI+PEZPTlQg Q09MT1I9IiNBMEEwQTAiIHNpemU9IjEiIEZBQ0U9ImFyaWFsIj5JTVBPUlRBTlQgTk9USUNFOiBQ bGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2ViRXggc2VydmljZSBhbGxvd3MgYXVkaW8gYW5kIG90aGVy IGluZm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRvIGJlIHJlY29yZGVkLCB3aGlj aCBtYXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVyLiBCeSBqb2luaW5nIHRoaXMg c2Vzc2lvbiwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0byBzdWNoIHJlY29yZGluZ3MuIElm IHlvdSBkbyBub3QgY29uc2VudCB0byBiZWluZyByZWNvcmRlZCwgZGlzY3VzcyB5b3VyIGNvbmNl cm5zIHdpdGggdGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhlIHNlc3Npb24uPC9GT05UPjwvRk9O VD4KU1VNTUFSWTpST0xMIHVzZS1vZi1ycGkKUFJJT1JJVFk6NQpDTEFTUzpQVUJMSUMKQkVHSU46 VkFMQVJNClRSSUdHRVI6LVBUMTBNCkFDVElPTjpESVNQTEFZCkRFU0NSSVBUSU9OOlJlbWluZGVy CkVORDpWQUxBUk0KRU5EOlZFVkVOVApFTkQ6VkNBTEVOREFSCg== ------=_Part_30553_885815170.1443186496644-- From nobody Fri Sep 25 06:16:16 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C5421A0248 for ; Fri, 25 Sep 2015 06:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9PPGUAR2Og8E for ; Fri, 25 Sep 2015 06:16:14 -0700 (PDT) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87D8A1A023E for ; Fri, 25 Sep 2015 06:16:12 -0700 (PDT) Received: by laclj5 with SMTP id lj5so2776665lac.3 for ; Fri, 25 Sep 2015 06:16:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=e1K19kFuwErl4uW01HrZf759dLUIlS9OKRiCwdHWSBo=; b=I8hxYa3vbicY1xn9QM5yW2NR7oJpSZITVjwvaKVbKkJLj8EEqIZJkJI/aErPmL/uZp QND/dnQ9LJkhfs3HeIUVVOYZEJLq4Yog4KI5NZTeHr9H4Gx7eX8IGmRAUSTCJNophSux Idm5IWaG3OhjPitILOKICCR9GEOmx4s344visFQqkvmV1YimdjBliyN8fhcsRJ2Rd41j KE9aKV9Z8k/SZeUzRQSX+j/4v0H7zKTI5k/tAhQvFS81VeSf1LiSH4b67RraYSm9+KF6 KS1BAa/WjSIUHzrQJvZAcXfLJEE0+rIwKRGsZoQu384ZxH2ORIzDX0dYFkq0OVj85dTL CFGA== MIME-Version: 1.0 X-Received: by 10.152.44.233 with SMTP id h9mr1609582lam.74.1443186970562; Fri, 25 Sep 2015 06:16:10 -0700 (PDT) Received: by 10.25.153.194 with HTTP; Fri, 25 Sep 2015 06:16:10 -0700 (PDT) In-Reply-To: References: Date: Fri, 25 Sep 2015 16:16:10 +0300 Message-ID: From: Ines Robles To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary=089e0160b3bab99b3305209226e2 Archived-At: Subject: Re: [Roll] Virtual Interim Meeting, September 29, 2015 - Discuss about uses cases - X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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 Sep 2015 13:16:15 -0000 --089e0160b3bab99b3305209226e2 Content-Type: text/plain; charset=UTF-8 Hi Pascal, Yes, it is. Sorry for late reply Cheers, Ines 2015-09-16 14:39 GMT+03:00 Pascal Thubert (pthubert) : > Thanks a bunch Ines! > > > > > http://www.worldtimebuddy.com/?pl=1&lid=100,12,5392171&h=100&date=9/29/2015|3 > > > > tells me that this is 3PM CEST, 6AM Pacific. > > > > Cheers, > > > > Pascal > > > > *From:* Roll [mailto:roll-bounces@ietf.org] *On Behalf Of *Ines Robles > *Sent:* lundi 14 septembre 2015 18:18 > *To:* roll > *Cc:* Michael Richardson > *Subject:* [Roll] Virtual Interim Meeting, September 29, 2015 - Discuss > about uses cases - > > > > Dear all, > > > > We scheduled a virtual interim meeting to discuss about the draft: "When > to use RFC 6553, 6554 and IPv6-in-IPv6 " [ > https://datatracker.ietf.org/doc/draft-robles-roll-useofrplinfo/] > > > > The idea is to fill the empty tables of the draft. We kindly appreciate > your help. > > > > We will post later the details about the connectivity. > > > > Thank you very much in advance, > > > > Michael and Ines > > > > ---------- Forwarded message ---------- > From: *IESG Secretary* > Date: 2015-09-14 17:08 GMT+03:00 > Subject: [Roll] ROLL WG Virtual Interim Meeting, September 29, 2015 > To: IETF Announcement List > Cc: roll@ietf.org > > > The ROLL Working Group will hold a virtual interim meeting on Tuesday, > September 29, 2015 from 13:00 to 15:00 UTC. > > Additional information will be announced on the ROLL WG mailing list: > https://mailarchive.ietf.org/arch/browse/roll/ > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > --089e0160b3bab99b3305209226e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Pascal,

Yes, it is.

Sorry for late reply

Cheers,
Ines

2015-09-16 14:39 GMT+03:00 Pascal Thubert (pthubert) <pthube= rt@cisco.com>:

Thanks a bunch Ines!

=C2=A0

http://www.worldtimebuddy.com/?pl=3D1&lid=3D100,12,53= 92171&h=3D100&date=3D9/29/2015|3

=C2=A0

tells me that this is 3PM CEST, 6AM P= acific.

=C2=A0

Cheers,

=C2=A0

Pascal

=C2=A0

From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Ines Robles
Sent: lundi 14 septembre 2015 18:18
To: roll <roll= @ietf.org>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>
Subject: [Roll] Virtual Interim Meeting, September 29, 2015 - Discus= s about uses cases -

=C2=A0

Dear all,

=C2=A0

We scheduled a virtual interim meeting to discuss ab= out the draft: "When to use RFC 6553, 6554 and IPv6-in-IPv6 " [https://datatracker.ietf.org/doc/draft-robles-roll-useofr= plinfo/]

=C2=A0

The idea is to fill the empty tables of the draft. W= e kindly appreciate your help.

=C2=A0

We will post later the details about the connectivit= y.

=C2=A0

Thank you very much in advance,

=C2=A0

Michael and Ines

=C2=A0

---------- Forwarded = message ----------
From: IESG Secretary <iesg-secretary@ietf.org>
Date: 2015-09-14 17:08 GMT+03:00
Subject: [Roll] ROLL WG Virtual Interim Meeting, September 29, 2015
To: IETF Announcement List <ietf-announce@ietf.org>
Cc: roll@ietf.org

The ROLL Working Group will hold a virtual interim meeting on Tuesday,
September 29, 2015 from 13:00 to 15:00 UTC.

Additional information will be announced on the ROLL WG mailing list:
https://mailarchive.ietf.org/arch/browse/roll/

=C2=A0


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


--089e0160b3bab99b3305209226e2-- From nobody Fri Sep 25 07:53:44 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD1311A1BBD for ; Fri, 25 Sep 2015 07:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VwcYwCeUr_b7 for ; Fri, 25 Sep 2015 07:53:40 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0745.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::745]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F0241A1BAF for ; Fri, 25 Sep 2015 07:53:40 -0700 (PDT) Received: from DB5PR01MB1080.eurprd01.prod.exchangelabs.com (10.162.152.142) by DB5PR01MB1079.eurprd01.prod.exchangelabs.com (10.162.152.141) with Microsoft SMTP Server (TLS) id 15.1.280.20; Fri, 25 Sep 2015 14:53:35 +0000 Received: from DB5PR01MB1080.eurprd01.prod.exchangelabs.com ([10.162.152.142]) by DB5PR01MB1080.eurprd01.prod.exchangelabs.com ([10.162.152.142]) with mapi id 15.01.0280.017; Fri, 25 Sep 2015 14:53:35 +0000 From: "Turner, Randy" To: "roll@ietf.org" Thread-Topic: DAO lifetime Thread-Index: AdD3oaMaJR4px1hfTZKjl60yXLkFRw== Date: Fri, 25 Sep 2015 14:53:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Randy.Turner@landisgyr.com; x-originating-ip: [148.80.255.144] x-microsoft-exchange-diagnostics: 1; DB5PR01MB1079; 5:iRW6kxUkegbHTkC4CPglxWizAmkzxPBVBKP6He+ub0MgZNao3gHPsYzefgWKErRj0XulVdyeqVubN9N/wm0Kf4fC+ZdAOAAOU25aOsgZ9TVSALdoRT/gSeslG7jQBRb2TOJ4ur4WOSxMas+YwGeyuw==; 24:LdWMUJNuZ4NB+Eo2yVIE9IKUyKqPFKbihtBTHn/o+m5m63i/wkqhGK40XAdV36kVco6DcoH8GAvBF60X5xSqn1/+nmK+sYJNsmy+nndsXOQ=; 20:mZrTPJ0yN4q+DW/gWils91rqj1PrGZL+7Xp+B9rPy4g6NMlu4OSDVzjx2BZWJa8bTGHQ6Qh6FbsKz9fYBqDVaA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5PR01MB1079; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001); SRVR:DB5PR01MB1079; BCL:0; PCL:0; RULEID:; SRVR:DB5PR01MB1079; x-forefront-prvs: 07106EF9B9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(5007970100001)(4001540100001)(19300405004)(16236675004)(122556002)(221733001)(19625215002)(81156007)(66066001)(5003600100002)(2900100001)(11100500001)(107886002)(110136002)(10400500002)(19580395003)(77096005)(5001960100002)(68736005)(15975445007)(54356999)(33656002)(50986999)(5004730100002)(102836002)(77156002)(229853001)(87936001)(40100003)(189998001)(5002640100001)(5890100001)(92566002)(450100001)(2351001)(74316001)(97736004)(101416001)(64706001)(2501003)(5001830100001)(86362001)(5001860100001)(106356001)(105586002)(46102003)(62966003); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR01MB1079; H:DB5PR01MB1080.eurprd01.prod.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: landisgyr.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB5PR01MB10807DAF503BBFF45787599C80420DB5PR01MB1080eurp_" MIME-Version: 1.0 X-OriginatorOrg: landisgyr.com X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Sep 2015 14:53:34.9144 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: ee2cd48b-958f-4be4-9852-b8f104c001b9 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR01MB1079 Archived-At: Subject: [Roll] DAO lifetime X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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 Sep 2015 14:53:42 -0000 --_000_DB5PR01MB10807DAF503BBFF45787599C80420DB5PR01MB1080eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Guys, I was hoping someone could answer a quick question regarding non-storing mo= de and DAOs - If I establish a route to a node using DAO with transit info = at time 0 with a lifetime of 100 lifetime units, and then 20 lifetime units= later, I send another DAO for the same target address specifying a differe= nt path, will this latest DAO cause the root or LBR to overwrite its' routi= ng information for the destination? I was trying to figure out if I need t= o explicitly send a DAO with a lifetime of 0 (or something else) to kill th= e previous route before sending a new DAO for the same destination? Thanks for any replies... Randy P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL. This e-mail (including any attachments) is confidential and may be legally = privileged. If you are not an intended recipient or an authorized represent= ative of an intended recipient, you are prohibited from using, copying or d= istributing the information in this e-mail or its attachments. If you have = received this e-mail in error, please notify the sender immediately by retu= rn e-mail and delete all copies of this message and any attachments. Thank = you. --_000_DB5PR01MB10807DAF503BBFF45787599C80420DB5PR01MB1080eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Guys,

 

I was hoping someone could answer a quick question r= egarding non-storing mode and DAOs – If I establish a route to a node= using DAO with transit info at time 0 with a lifetime of 100 lifetime unit= s, and then 20 lifetime units later, I send another DAO for the same target address specifying a different path, will = this latest DAO cause the root or LBR to overwrite its’ routing infor= mation for the destination?  I was trying to figure out if I need to e= xplicitly send a DAO with a lifetime of 0 (or something else) to kill the previous route before sending a new DAO for th= e same destination?

 

Thanks for any replies…

Randy


P PLEA= SE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL.

This e-mail (including any attachments) is con= fidential and may be legally privileged. If you are not an intended recipie= nt or an authorized representative of an intended recipient, you are prohib= ited from using, copying or distributing the information in this e-mail or its attachments. If you have received th= is e-mail in error, please notify the sender immediately by return e-mail a= nd delete all copies of this message and any attachments. Thank you.

--_000_DB5PR01MB10807DAF503BBFF45787599C80420DB5PR01MB1080eurp_-- From nobody Fri Sep 25 08:25:01 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3BF11A6F41 for ; Fri, 25 Sep 2015 08:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uc4OncUy1GRi for ; Fri, 25 Sep 2015 08:24:58 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8A821A6F3C for ; Fri, 25 Sep 2015 08:24:57 -0700 (PDT) Received: by wicfx3 with SMTP id fx3so26683983wic.1 for ; Fri, 25 Sep 2015 08:24:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type; bh=wgIpKkJvtXTlDoEcbp3L5H2RTNcMyru0y+F4lHKWbe4=; b=jUz0g3dB8yCdiTZjb9h4rmhBHjeuukRU20rqK74MbkpLTbsHOKCsnojeDEoLra8A6w iFpnj4OxGldxtKNyczmuhz9RPSe/ac4MYX3Ae9E0kuxoEmnCtNnMvZWliJ7YSPb/oVBV otPDTNrkMr88WkLA8XQaVmD7VZTixPW3pzLItzDAjWQt/jwhcHJkTIwyNn5d0HssC/XS QsKy7wW0aRm8kIoiir1Mbi4ypsRLznNKgQtBRdBUrNmE0GfQf0IvYCb7QZE+cyqw0Kc0 2t5JTxnutdaQ7x/iYMj4YmmdL7sR+zcGPbLqB9f5utU8sudKnHlCgfUygl37VeZxDbrP xmhg== X-Received: by 10.180.105.138 with SMTP id gm10mr3812437wib.37.1443194696213; Fri, 25 Sep 2015 08:24:56 -0700 (PDT) Received: from ?IPv6:2a02:8109:9ac0:a94:221:ccff:fe67:d847? ([2a02:8109:9ac0:a94:221:ccff:fe67:d847]) by smtp.googlemail.com with ESMTPSA id l17sm3872141wjr.18.2015.09.25.08.24.55 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 25 Sep 2015 08:24:55 -0700 (PDT) To: roll@ietf.org References: From: =?UTF-8?Q?Cenk_G=c3=bcndogan?= Message-ID: <56056747.4040600@gmail.com> Date: Fri, 25 Sep 2015 17:24:55 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------040107060704090309070500" Archived-At: Subject: Re: [Roll] DAO lifetime X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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 Sep 2015 15:24:59 -0000 This is a multi-part message in MIME format. --------------040107060704090309070500 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hello Randy, It seems like for the Non-Storing mode there is no "No-Path" DAO (DAOs with Path lifetime of 0) [2]. To quote section 9.7 section [2]: 3. When a node removes a node from its DAO parent set, it MAY generate a new DAO message with an updated Transit Information option. I am not so sure about this, but I would assume that this new DAO message would include an incremented Path Sequence in order to mark other DAOs, which might be also still on the way to the root, as outdated. So I guess the root would make the decision to overwrite or not based on the comparison of the path sequence. Best, Cenk [1] https://tools.ietf.org/html/rfc6550#section-6.4.3 [2] https://tools.ietf.org/html/rfc6550#section-9.7 On 25.09.2015 16:53, Turner, Randy wrote: > > Hi Guys, > > I was hoping someone could answer a quick question regarding > non-storing mode and DAOs – If I establish a route to a node using DAO > with transit info at time 0 with a lifetime of 100 lifetime units, and > then 20 lifetime units later, I send another DAO for the same target > address specifying a different path, will this latest DAO cause the > root or LBR to overwrite its’ routing information for the > destination? I was trying to figure out if I need to explicitly send > a DAO with a lifetime of 0 (or something else) to kill the previous > route before sending a new DAO for the same destination? > > Thanks for any replies… > > Randy > > > P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL. > > This e-mail (including any attachments) is confidential and may be > legally privileged. If you are not an intended recipient or an > authorized representative of an intended recipient, you are prohibited > from using, copying or distributing the information in this e-mail or > its attachments. If you have received this e-mail in error, please > notify the sender immediately by return e-mail and delete all copies > of this message and any attachments. Thank you. > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --------------040107060704090309070500 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hello Randy,

It seems like for the Non-Storing mode there is no "No-Path" DAO (DAOs with Path lifetime of 0) [2].

To quote section 9.7 section [2]:

3.  When a node removes a node from its DAO parent set, it MAY
       generate a new DAO message with an updated Transit Information
       option.

I am not so sure about this, but I would assume that this new DAO message would include an incremented Path Sequence in order to mark other DAOs, which might be also still on the way to the root, as outdated. So I guess the root would make the decision to overwrite or not based on the comparison of the path sequence.

Best,
Cenk

[1] https://tools.ietf.org/html/rfc6550#section-6.4.3
[2] https://tools.ietf.org/html/rfc6550#section-9.7

On 25.09.2015 16:53, Turner, Randy wrote:

Hi Guys,

 

I was hoping someone could answer a quick question regarding non-storing mode and DAOs – If I establish a route to a node using DAO with transit info at time 0 with a lifetime of 100 lifetime units, and then 20 lifetime units later, I send another DAO for the same target address specifying a different path, will this latest DAO cause the root or LBR to overwrite its’ routing information for the destination?  I was trying to figure out if I need to explicitly send a DAO with a lifetime of 0 (or something else) to kill the previous route before sending a new DAO for the same destination?

 

Thanks for any replies…

Randy


P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL.

This e-mail (including any attachments) is confidential and may be legally privileged. If you are not an intended recipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the information in this e-mail or its attachments. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete all copies of this message and any attachments. Thank you. 



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

--------------040107060704090309070500-- From nobody Mon Sep 28 05:21:02 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 370DF1A8ACC for ; Mon, 28 Sep 2015 05:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.611 X-Spam-Level: X-Spam-Status: No, score=-12.611 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m0UDoON-efQr for ; Mon, 28 Sep 2015 05:20:58 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E09EF1A8AC4 for ; Mon, 28 Sep 2015 05:20:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8096; q=dns/txt; s=iport; t=1443442858; x=1444652458; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=L7bQAlaahM4gh7gpH9enk8bXq+HdqdABew5ORD4Dpt8=; b=RUHfPB96usPvCB39gBMJWQYxJHgkE2PJp6pxHFA9cKSP1MGfrki9/6FS w30uY36Z8SssfNQ1XuiIic7YfDHtqaso584nL5GGbrv399VQmuaAEoEOa 4h7577NfI144ySjKLVH40MExGzDgnfYNMFEZKCbf/uBs+YnF6D7YyDUjs c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D+BABqMAlW/5FdJa1dgldNVGkGvUaHdAKBQzoSAQEBAQEBAYEKhCQBAQEELUUXAgEIEQQBASgHMhQJCAEBBBMIiCbLJAEBAQEBAQEBAQEBAQEBAQEBAQEBAReGc4R9hCoRAVcBBoQmBZVwAY0KgVOENpU5ASgDOIQBcYdiOoEFAQEB X-IronPort-AV: E=Sophos;i="5.17,602,1437436800"; d="scan'208,217";a="192178185" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-5.cisco.com with ESMTP; 28 Sep 2015 12:20:51 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t8SCKpGF017325 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 28 Sep 2015 12:20:51 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 28 Sep 2015 07:20:50 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1104.000; Mon, 28 Sep 2015 07:20:50 -0500 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: DAO lifetime Thread-Index: AdD3oaMaJR4px1hfTZKjl60yXLkFRwCRYX+g Date: Mon, 28 Sep 2015 12:19:28 +0000 Deferred-Delivery: Mon, 28 Sep 2015 12:17:26 +0000 Message-ID: <6d21d0f86ab14ae7a99ff9fe6873b1fd@XCH-RCD-001.cisco.com> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.215.87] Content-Type: multipart/alternative; boundary="_000_6d21d0f86ab14ae7a99ff9fe6873b1fdXCHRCD001ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] DAO lifetime X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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, 28 Sep 2015 12:21:01 -0000 --_000_6d21d0f86ab14ae7a99ff9fe6873b1fdXCHRCD001ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Randy: Sorry for overlooking this. Answer is that it depends on the path sequence = (see section 7.1 in RFC 6550). A same sequence indicates multiple parents that can be used in parallel. Ne= w sequence cleans all state from the preceding sequence. Clarification: the non-storing DAO does not indicate a path but a one paren= t-child relationship. Cheers, Pascal From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Turner, Randy Sent: vendredi 25 septembre 2015 16:54 To: roll@ietf.org Subject: [Roll] DAO lifetime Hi Guys, I was hoping someone could answer a quick question regarding non-storing mo= de and DAOs - If I establish a route to a node using DAO with transit info = at time 0 with a lifetime of 100 lifetime units, and then 20 lifetime units= later, I send another DAO for the same target address specifying a differe= nt path, will this latest DAO cause the root or LBR to overwrite its' routi= ng information for the destination? I was trying to figure out if I need t= o explicitly send a DAO with a lifetime of 0 (or something else) to kill th= e previous route before sending a new DAO for the same destination? Thanks for any replies... Randy P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL. This e-mail (including any attachments) is confidential and may be legally = privileged. If you are not an intended recipient or an authorized represent= ative of an intended recipient, you are prohibited from using, copying or d= istributing the information in this e-mail or its attachments. If you have = received this e-mail in error, please notify the sender immediately by retu= rn e-mail and delete all copies of this message and any attachments. Thank = you. --_000_6d21d0f86ab14ae7a99ff9fe6873b1fdXCHRCD001ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Randy:

 

Sorry for overlooking = this. Answer is that it depends on the path sequence (see section 7.1 in RF= C 6550).

A same sequence indica= tes multiple parents that can be used in parallel. New sequence cleans all = state from the preceding sequence.

 

Clarification: the non= -storing DAO does not indicate a path but a one parent-child relationship.<= o:p>

 

Cheers,

 

Pascal

 

From: Roll [mailto:roll-bounces@ietf.org] = On Behalf Of Turner, Randy
Sent: vendredi 25 septembre 2015 16:54
To: roll@ietf.org
Subject: [Roll] DAO lifetime

 

Hi Guys,

 

I was hoping someone could answer a quick question r= egarding non-storing mode and DAOs – If I establish a route to a node= using DAO with transit info at time 0 with a lifetime of 100 lifetime unit= s, and then 20 lifetime units later, I send another DAO for the same target address specifying a different path, will = this latest DAO cause the root or LBR to overwrite its’ routing infor= mation for the destination?  I was trying to figure out if I need to e= xplicitly send a DAO with a lifetime of 0 (or something else) to kill the previous route before sending a new DAO for th= e same destination?

 

Thanks for any replies…

Randy

 

P PLEASE CONSIDER OUR E= NVIRONMENT BEFORE PRINTING THIS EMAIL.

This e-mail (including any attachments) is confident= ial and may be legally privileged. If you are not an intended recipient or = an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the info= rmation in this e-mail or its attachments. If you have received this e-mail= in error, please notify the sender immediately by return e-mail and delete= all copies of this message and any attachments. Thank you. =

--_000_6d21d0f86ab14ae7a99ff9fe6873b1fdXCHRCD001ciscocom_-- From nobody Tue Sep 29 05:03:29 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 805691A87C9 for ; Tue, 29 Sep 2015 05:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.376 X-Spam-Level: X-Spam-Status: No, score=-1.376 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l9ercegzFclN for ; Tue, 29 Sep 2015 05:03:12 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7BAF1A87DE for ; Tue, 29 Sep 2015 05:02:21 -0700 (PDT) Received: by laer8 with SMTP id r8so5524031lae.2 for ; Tue, 29 Sep 2015 05:02:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=4/nIRXSnjHHmvVLbz7U3WRN6HflmLBw1v/E4Pesk7/0=; b=SBl0ggnqhsjBM7eVcRDMC+qdEoucIAgwzos7ivf2o/sMMHGRe80tnZhuz7DrEdCCkU O0hxt+AUNmIQIbsYcSI5toLExRDM6wwPR7gBWGT0IlYP3CCKezA7x1yX9kr03DFAdFZE 004fjBpHx+R4QFor1mcdWpGNyGrZBkaSNoznTuPEuse8jEniX72ixibgcK4BgfvfKkZb 1XAcD6lLXaWQtuZ67KXp60pNUhD1G2v1wzK2JIVrTk3pY7SDgMPmmUt0RNOrMCp/nE2y tswWW6C+iEHjmAjiu6pgwk6FaX6xHyw1tJMhfxbG1XYJYETRyfJoFYmBuKebln4MY4Pw IRRQ== MIME-Version: 1.0 X-Received: by 10.152.27.70 with SMTP id r6mr7040330lag.67.1443528139771; Tue, 29 Sep 2015 05:02:19 -0700 (PDT) Received: by 10.25.151.213 with HTTP; Tue, 29 Sep 2015 05:02:19 -0700 (PDT) In-Reply-To: <355328634.30555.1443186496645.JavaMail.nobody@jva2tc206.webex.com> References: <355328634.30555.1443186496645.JavaMail.nobody@jva2tc206.webex.com> Date: Tue, 29 Sep 2015 15:02:19 +0300 Message-ID: From: Ines Robles To: mcr+nomcom@sandelman.ca, Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary=089e0160a468fe97040520e19527 Archived-At: Subject: Re: [Roll] WebEx meeting changed: ROLL use-of-rpi X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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 Sep 2015 12:03:14 -0000 --089e0160a468fe97040520e19527 Content-Type: text/plain; charset=UTF-8 Hi, Please find the agenda/minute for the meeting today http://etherpad.tools.ietf.org:9000/p/ROLL-Interim_Meeting_-09-29-2015 Thank you, 2015-09-25 16:08 GMT+03:00 Michael Richardson : > Hello, Michael Richardson changed the WebEx meeting information. *ROLL > use-of-rpi* Tuesday, September 29, 2015 9:00 am | Eastern Daylight Time > (New York, GMT-04:00) | 2 hrs 15 mins *Join WebEx meeting* > Meeting > number: 642 820 567 Meeting password: roll *Join by phone**1-877-668-4493 > <1-877-668-4493>* Call-in toll free number (US/Canada)*1-650-479-3208 > <1-650-479-3208>* Call-in toll number (US/Canada)Access code: 642 820 567Toll-free > calling restrictions > Add this meeting > > to your calendar. Can't join the meeting? Contact support. > IMPORTANT NOTICE: Please note that > this WebEx service allows audio and other information sent during the > session to be recorded, which may be discoverable in a legal matter. By > joining this session, you automatically consent to such recordings. If you > do not consent to being recorded, discuss your concerns with the host or do > not join the session. > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > --089e0160a468fe97040520e19527 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Please find the agenda/minute for t= he meeting today


<= div>Thank you,

2015-09-25 16:08 GMT+03:00 Michael Richardson &l= t;messenger@webex.= com>:
Hello,
Michael Richardson changed the WebEx meeting information.
=C2= =A0
ROLL use-of-rpi
Tuesday, September 29, 2015
9:00 am=C2=A0=C2=A0|=C2=A0=C2=A0Eastern Daylight Time (New York= , GMT-04:00)=C2=A0=C2=A0|=C2=A0=C2=A02 hrs 15 mins
=C2= =A0
Join WebEx meeting
Meeting number: 642 820 567
Meeting password: roll
=09
=C2= =A0
=
Join by phone
1-877-668-4493<= /a>=C2=A0Call-in toll free number (US/Canada)
1-650-479-3208=C2=A0Call-in toll number (US/Canada)
Access code:=C2=A0642 820 567
Toll-free calling restrictions
=C2=A0
Add this meeting to your calendar.
=C2= =A0
Can't join the meeting? Contact support.
=C2= =A0
IMPORTANT NOTICE: Please note that this WebEx service allows audio= and other information sent during the session to be recorded, which may be= discoverable in a legal matter. By joining this session, you automatically= consent to such recordings. If you do not consent to being recorded, discu= ss your concerns with the host or do not join the session.

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


--089e0160a468fe97040520e19527-- From nobody Tue Sep 29 08:14:19 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E22621A924C; Tue, 29 Sep 2015 08:14:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.898 X-Spam-Level: X-Spam-Status: No, score=-101.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fMYMSN1Vp_01; Tue, 29 Sep 2015 08:14:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A1C81A924A; Tue, 29 Sep 2015 08:14:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alia Atlas" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150929151414.1775.20190.idtracker@ietfa.amsl.com> Date: Tue, 29 Sep 2015 08:14:14 -0700 Archived-At: Cc: roll-chairs@ietf.org, draft-ietf-roll-mpl-parameter-configuration@ietf.org, roll@ietf.org, maria.ines.robles@ericsson.com, draft-ietf-roll-mpl-parameter-configuration.shepherd@ietf.org, draft-ietf-roll-mpl-parameter-configuration.ad@ietf.org Subject: [Roll] Alia Atlas' Yes on draft-ietf-roll-mpl-parameter-configuration-07: (with COMMENT) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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 Sep 2015 15:14:16 -0000 Alia Atlas has entered the following ballot position for draft-ietf-roll-mpl-parameter-configuration-07: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-roll-mpl-parameter-configuration/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for addressing my Discuss so thoroughly! From nobody Tue Sep 29 12:45:00 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3013E1B2BDE for ; Tue, 29 Sep 2015 12:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yoqVpcKo15zg for ; Tue, 29 Sep 2015 12:44:57 -0700 (PDT) Received: from mail-la0-f43.google.com (mail-la0-f43.google.com [209.85.215.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F24A1B2BBF for ; Tue, 29 Sep 2015 12:44:57 -0700 (PDT) Received: by laer8 with SMTP id r8so21411545lae.2 for ; Tue, 29 Sep 2015 12:44:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=HuTcFwBvMwTGd2GMSdMiMxTbLX8mo//ZBeIZRnQgZB0=; b=WlluU6kpny7THSad+tHRgWk7iIhvmKW0Mwi8AFiIb1q69ht43+3W9k30u88V8YwA2K BLBE10dW4os3NcV5MrbP4RJbHwGQYxnSFUKE4MLttepJzY5/5oP6+qTaYW96Qag3x0s8 1dtH8rKet4Rb8YE7YAo2TPZYdNwXO7/qBLRDCchpLPsLmqOuucz3+ISWI+YYKbVLA85h L5+JgpB5aTrqUOZ7+WjcwnNPEiBxuIcTq+SK3I1+kom3bRmpCqZRwfTFuhrUAn8J3sG/ SX0R9/6qXvVFLIBMl4MVsm/fMJ8dbprY3EduvcRK14BVq28t7m3yKlkt9a0Syhio5Yb3 YfXQ== X-Gm-Message-State: ALoCoQkjxSyfOfvkQO0BMhXyI4R5HFT48MNrBwa20q2GMXHJQQYvYD/fxeiqSRkRUwl4NepD3K4n X-Received: by 10.25.151.65 with SMTP id z62mr5141747lfd.21.1443555895224; Tue, 29 Sep 2015 12:44:55 -0700 (PDT) Received: from [192.168.1.102] (h31n15-sbg-a11.ias.bredband.telia.com. [195.67.245.31]) by smtp.gmail.com with ESMTPSA id x128sm2992309lfd.26.2015.09.29.12.44.54 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Sep 2015 12:44:54 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Joakim Eriksson In-Reply-To: <6d21d0f86ab14ae7a99ff9fe6873b1fd@XCH-RCD-001.cisco.com> Date: Tue, 29 Sep 2015 21:44:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6d21d0f86ab14ae7a99ff9fe6873b1fd@XCH-RCD-001.cisco.com> To: Routing Over Low power and Lossy networks X-Mailer: Apple Mail (2.2104) Archived-At: Subject: [Roll] Semantics of DAO ACK X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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 Sep 2015 19:44:59 -0000 Hello All, I have spend quite some time to get a more stable implementation of DAO = handling for Contiki RPL and I am currently looking into DAO aggregation. But I = realised that it is for me not 100% clear what a node that receives a DAO with several = prefixes to be registered but can only accept a sub-set of them. Should it be a = DAO_NACK in this case or is there any other way to handle that case? If each would have been sent separately it is obvious that the receiving = node can do a NACK when the routing table is full and therefore it is possible to = get fine-grained answers. But with aggregation of DAOs this is not the case. Any ideas? Best regards, =E2=80=94 Joakim Eriksson, SICS= From nobody Tue Sep 29 14:08:17 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B79EE1B2C82 for ; Tue, 29 Sep 2015 14:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-De8vuujPzF for ; Tue, 29 Sep 2015 14:08:14 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25CE21B2C80 for ; Tue, 29 Sep 2015 14:08:14 -0700 (PDT) Received: by wicfx3 with SMTP id fx3so169090401wic.1 for ; Tue, 29 Sep 2015 14:08:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=WMWyKbuAHKwT9Tlq+u/nN7RxivG05cglHgyCQ/Mp7OI=; b=rdwPt+Meg09leDMl0lkS+h0qZBJ3RfuWIZeTNInqab9GoPw9oYXEt0+gD41QEvHg59 IjNPvjCTqp9RWXStOZ4Bw5PGF/1fV+X6fLDHnAmwTA4j9YflAVxzHZGC/hzKmu0Kc6ji /C9/wX2Su1fTNNYFFH4JyWdnU851EvtGLOvUrI5KQjuk0i+/RAToB9jQsuHPrqhqpye9 syF1PjCBMp4RYeGyFJCsjpw2dRjcWQ2dC4AZmBppchpt1m8ltC90BK4STSk//yrHGCps clc/DQXLBRYltRDNc8iD580X2z5YHk1Ke9npk96+x5sItWuHQCNL5DyBXr1a6wdd9mbq ENww== X-Received: by 10.180.76.177 with SMTP id l17mr837260wiw.16.1443560892741; Tue, 29 Sep 2015 14:08:12 -0700 (PDT) Received: from ?IPv6:2a02:8109:9ac0:a94:221:ccff:fe67:d847? ([2a02:8109:9ac0:a94:221:ccff:fe67:d847]) by smtp.googlemail.com with ESMTPSA id fz1sm25801192wic.8.2015.09.29.14.08.11 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 29 Sep 2015 14:08:12 -0700 (PDT) To: roll@ietf.org References: <6d21d0f86ab14ae7a99ff9fe6873b1fd@XCH-RCD-001.cisco.com> From: =?UTF-8?Q?Cenk_G=c3=bcndogan?= Message-ID: <560AFDBB.8050505@gmail.com> Date: Tue, 29 Sep 2015 23:08:11 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Roll] Semantics of DAO ACK X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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 Sep 2015 21:08:15 -0000 Hello Joakim, This is an interesting question and I also couldn't find any answers in RFC 6550. However, my thoughts on this are as follows: Since a sub-set of the announced RPL targets could have been accepted before filling up the routing table (e.g.), I would choose a status code between 1 and 127. I would expect a node to choose another parent if a more aggressive status code is received ([128-255]). But a full routing table can have free space again until the next or any subsequent DAO arrives .. therefore I prefer a "mild rejection" with a status code of [1-127]. To give some feedback to the originator of the DAO, it might be sensible to copy the rejected RPL Target options from the affected DAO to the DAO-ACK, so that the originator is fully aware of which Target prefixes got rejected (and which ones got accepted, implicitly). I would choose this method, because it doesn't require the originator of the DAO to save any extra state about the DAO and its contents. Nonetheless, everything I wrote is nonconform and I am also interested in the RPL experts' opinions and solutions. Best, Cenk On 29.09.2015 21:44, Joakim Eriksson wrote: > Hello All, > > I have spend quite some time to get a more stable implementation of DAO handling > for Contiki RPL and I am currently looking into DAO aggregation. But I realised that > it is for me not 100% clear what a node that receives a DAO with several prefixes to > be registered but can only accept a sub-set of them. Should it be a DAO_NACK in > this case or is there any other way to handle that case? > > If each would have been sent separately it is obvious that the receiving node can > do a NACK when the routing table is full and therefore it is possible to get fine-grained > answers. But with aggregation of DAOs this is not the case. > > Any ideas? > > Best regards, > — Joakim Eriksson, SICS > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Tue Sep 29 21:44:36 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21ACC1B5BC0 for ; Tue, 29 Sep 2015 21:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NNpXoGkDCrHa for ; Tue, 29 Sep 2015 21:44:33 -0700 (PDT) Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB8F41B5BBF for ; Tue, 29 Sep 2015 21:44:32 -0700 (PDT) Received: by wicgb1 with SMTP id gb1so176816864wic.1 for ; Tue, 29 Sep 2015 21:44:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=T/VzTstMgupjqI/jgubkKULWpcFAsIak0zchi3N2IYE=; b=asaETrRSv5QEDlCXmSdfT2i/+Lc60jvYCZ8NpiGSZqEXd1DoDeKSHTZa9FH4IpRdem vnUT6kynb3kNDzE39YCd+Zc3JM0OmvI4IH07GApBV5hK6dCZhXO5akj9rKGutdQIEtyY soGdu3A/DyfayDLnUzU2BwW91N4wVtttgPHcqyX/FQHw1S9F1WrzFyZU0iPjKJdqOVvL 3D2c/8yl3LicmKkQh1j87cGzc1ZvrYI5qt1yTMC2qz2l08Y1xSvC1R+QnzgphGIM/04E cXRXAgoOx/AobZq02Cz73ld/uSdJiY8VJa15hl5ZCccWhMA34T8/flnQ+YREhLzC0uw6 KBmA== X-Gm-Message-State: ALoCoQkuGHwHKpYRyBdiIWC+0bT2MF+EDCSq0v8xcCk37l2XVGor+jwFenxM3F5Z6eltjo0HjJJ44FigEntiYhXg5o7Kuo4Tt1dFEktBghCo1kHm7/J8aYCfdD2IftqRiSMOX56LAW9uEBWJ6vs9DGNzQUH8AGm3WgCfE8IU0r1WZafEsIamQ24= X-Received: by 10.194.113.1 with SMTP id iu1mr1919359wjb.158.1443588271133; Tue, 29 Sep 2015 21:44:31 -0700 (PDT) Received: from cskiralys-air.homenet.telecomitalia.it (host238-105-dynamic.31-79-r.retail.telecomitalia.it. [79.31.105.238]) by smtp.googlemail.com with ESMTPSA id wn10sm27256292wjc.46.2015.09.29.21.44.29 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Sep 2015 21:44:30 -0700 (PDT) To: roll@ietf.org References: <6d21d0f86ab14ae7a99ff9fe6873b1fd@XCH-RCD-001.cisco.com> <560AFDBB.8050505@gmail.com> From: Csaba Kiraly Message-ID: <560B68B2.6030501@fbk.eu> Date: Wed, 30 Sep 2015 06:44:34 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <560AFDBB.8050505@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Roll] Semantics of DAO ACK X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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 Sep 2015 04:44:35 -0000 Hello Joakim, I have also worked on the Contiki DAO-ACK code, enabling ACKs, implementing fixes to the DAOSequence handling, and looking into multiple targets. What Cenk is saying sounds a reasonable hack, but the standard itself is in my opinion a bit underspecified for the semantics of DAO-ACK messages in several ways. My preferred solution for ACKing DAO messages with multiple targets would be to have support for the same semantics that you would have had with one DAO message per Target, i.e., I would prefer an option field that gives an individual status for each Target. To give another example of subtle problems with DAO-ACK, it was not clear to me whether I want my implementation to ACK when the Target is added to the routing table, or only when this node itself receives an ACK for the same Target from its parent. Both makes sense, with the former giving a quick one-hop ACK, while the latter works as an end-to-end ACK, ensuring that the path is actually built. Both look conformant to the standard, but I suppose the original author was thinking of the former, and I can easily see interoperability problems arising between two implementations using different semantics. Best regards, Csaba On 29/09/15 23:08, Cenk Gündogan wrote: > Hello Joakim, > > This is an interesting question and I also couldn't find any answers > in RFC 6550. > However, my thoughts on this are as follows: > Since a sub-set of the announced RPL targets could have been accepted > before filling up > the routing table (e.g.), I would choose a status code between 1 and 127. > I would expect a node to choose another parent if a more aggressive > status code is received ([128-255]). > But a full routing table can have free space again until the next or > any subsequent DAO arrives .. > therefore I prefer a "mild rejection" with a status code of [1-127]. > > To give some feedback to the originator of the DAO, it might be > sensible to copy the > rejected RPL Target options from the affected DAO to the DAO-ACK, so > that the originator is fully > aware of which Target prefixes got rejected (and which ones got > accepted, implicitly). > I would choose this method, because it doesn't require the originator > of the DAO to save any extra state > about the DAO and its contents. > > Nonetheless, everything I wrote is nonconform and I am also interested > in the RPL experts' opinions > and solutions. > > Best, > Cenk > > On 29.09.2015 21:44, Joakim Eriksson wrote: >> Hello All, >> >> I have spend quite some time to get a more stable implementation of >> DAO handling >> for Contiki RPL and I am currently looking into DAO aggregation. But >> I realised that >> it is for me not 100% clear what a node that receives a DAO with >> several prefixes to >> be registered but can only accept a sub-set of them. Should it be a >> DAO_NACK in >> this case or is there any other way to handle that case? >> >> If each would have been sent separately it is obvious that the >> receiving node can >> do a NACK when the routing table is full and therefore it is possible >> to get fine-grained >> answers. But with aggregation of DAOs this is not the case. >> >> Any ideas? >> >> Best regards, >> — Joakim Eriksson, SICS >> _______________________________________________ >> 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 nobody Tue Sep 29 22:27:06 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93DE41B5C44; Tue, 29 Sep 2015 22:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.402 X-Spam-Level: X-Spam-Status: No, score=-4.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NKjIGnp75o8l; Tue, 29 Sep 2015 22:27:00 -0700 (PDT) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A65B71B5C48; Tue, 29 Sep 2015 22:26:59 -0700 (PDT) Received: from tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp ([133.199.232.103]) by imx12.toshiba.co.jp with ESMTP id t8U5Qv0Y021037 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Sep 2015 14:26: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 t8U5QvHH031333; Wed, 30 Sep 2015 14:26:57 +0900 Received: from localhost ([127.0.0.1]) by tsbmgw-mgw01 (JAMES SMTP Server 2.3.1) with SMTP ID 238; Wed, 30 Sep 2015 14:26: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 t8U5QvCB031330; Wed, 30 Sep 2015 14:26:57 +0900 Received: (from root@localhost) by arc11.toshiba.co.jp id t8U5Qvr5015554; Wed, 30 Sep 2015 14:26:57 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id QAA15547; Wed, 30 Sep 2015 14:26:56 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id t8U5QunN001401; Wed, 30 Sep 2015 14:26:56 +0900 (JST) Received: from spiffy20.isl.rdc.toshiba.co.jp by toshiba.co.jp id t8U5Quis024829; Wed, 30 Sep 2015 14:26:56 +0900 (JST) Received: from [IPv6:2001:200:1b1:1010:f1ff:e236:9fb2:deeb] (unknown [IPv6:2001:200:1b1:1010:f1ff:e236:9fb2:deeb]) by spiffy20.isl.rdc.toshiba.co.jp (Postfix) with ESMTPS id E3EE118F4DF; Wed, 30 Sep 2015 14:26:55 +0900 (JST) To: roll@ietf.org, iesg@ietf.org References: <20150909143959.25684.48803.idtracker@ietfa.amsl.com> From: Yusuke DOI Message-ID: <560B72CB.5030305@toshiba.co.jp> Date: Wed, 30 Sep 2015 14:27:39 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150909143959.25684.48803.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: roll-chairs@ietf.org, draft-ietf-roll-mpl-parameter-configuration@ietf.org, draft-ietf-roll-mpl-parameter-configuration.shepherd@ietf.org, maria.ines.robles@ericsson.com, draft-ietf-roll-mpl-parameter-configuration.ad@ietf.org Subject: Re: [Roll] Brian Haberman's Discuss on draft-ietf-roll-mpl-parameter-configuration-07: (with DISCUSS and COMMENT) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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 Sep 2015 05:27:02 -0000 Hi Brian, Thank you very much for your review! > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- (snip) > 2. In section 2.3 (MPL Forwarder Behavior), there should be a brief > discussion of the role of the MPL Domain Address and include a reference > to [I-D.ietf-roll-trickle-mcast]. (snip) Does the following text added on Section 2.3 looks good for you? """ If a DHCPv6 client requests and receives the MPL Parameter Configuration Option, the node SHOULD join the MPL domain given by the option and act as an MPL forwarder. Note that there may be cases in which a node may fail to join a domain (or domains) due to local resource constraints. Each joining node SHOULD configure its MPL forwarder with the given parameter set for the MPL domain. Each MPL domain is defined by an MPL Domain Address given by an MPL Parameter Configuration Option. As defined in Section 2 of [I-D.ietf-roll-trickle-mcast], an MPL Domain Address is an IPv6 multicast address associated to a set of MPL network interfaces in an MPL Domain. """ > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > - Why is the text in Appendix A not in the Operational Considerations > section? It's my another mistake. I'll move it on next revision (already merged as operational consideration on my local repo) Best Regards, // Yusuke DOI On 2015-09-09 23:39, Brian Haberman wrote: > Brian Haberman has entered the following ballot position for > draft-ietf-roll-mpl-parameter-configuration-07: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-roll-mpl-parameter-configuration/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Updated for -07... > > 1. Resolved > > 2. In section 2.3 (MPL Forwarder Behavior), there should be a brief > discussion of the role of the MPL Domain Address and include a reference > to [I-D.ietf-roll-trickle-mcast]. > > 3. Resolved > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > - Why is the text in Appendix A not in the Operational Considerations > section? > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From nobody Wed Sep 30 00:58:39 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01D691B2CE1 for ; Wed, 30 Sep 2015 00:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DK2CLv0Zjy3E for ; Wed, 30 Sep 2015 00:58:37 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B3EF1A1A70 for ; Wed, 30 Sep 2015 00:58:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6138; q=dns/txt; s=iport; t=1443599917; x=1444809517; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=OuVXYAHPLxiudMrf6IT7zRG/3MI5BB4W3XPAy/oFtak=; b=bS+4I13ff1wT41H/nO55UC33nIDbQXpLTTKg3s/4b/v1PycOzNik9zm2 3f9C4UHjgT3a+YLSJbbuFaIskGUOFkwIhFJB6TggsUxNBFPq8vscZ+/79 WAXB8bcnkeTJTCHCfsQ35YKwVYqPIY99JAIHI83k6Aym0zwBB6ZFO8nlk E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AOAgDelQtW/4QNJK1egyRUaQaDJbo/AQ2BcQqFeQIcgSQ4FAEBAQEBAQGBCoQkAQEBBAEBASARNwMXBAIBCBEEAQEBAgIjAwICAiULFAEICAIEEwgTiBMNtmGUawEBAQEBAQEBAQEBAQEBAQEBAQEBARMEgSKFUYR9hCROIgaCY4FDBYc9hnWHRQGNDptJAR8BAUKCERyBVHGIGYEFAQEB X-IronPort-AV: E=Sophos;i="5.17,611,1437436800"; d="scan'208";a="193119787" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Sep 2015 07:58:36 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t8U7wa6R015997 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 30 Sep 2015 07:58:36 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 30 Sep 2015 02:58:35 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1104.000; Wed, 30 Sep 2015 02:58:35 -0500 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] Semantics of DAO ACK Thread-Index: AQHQ+1XIXTm9D29Fq02dhWu58Vn5kA== Date: Wed, 30 Sep 2015 07:58:24 +0000 Deferred-Delivery: Wed, 30 Sep 2015 07:58:02 +0000 Message-ID: <8f1d44568afa4348a05169bedc3c3020@XCH-RCD-001.cisco.com> References: <6d21d0f86ab14ae7a99ff9fe6873b1fd@XCH-RCD-001.cisco.com> <560AFDBB.8050505@gmail.com> In-Reply-To: <560AFDBB.8050505@gmail.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.228.32.172] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] Semantics of DAO ACK X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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 Sep 2015 07:58:39 -0000 SGVsbG8gYWxsOg0KDQpUaGUgREFPIEFDSyBzdGF0dXMgcmVhbGx5IGlzIGEgc3VtbWFyeSB0aGF0 IGluZGljYXRlcyB0aGF0IHRoZXJlIHdhcyBhIHByb2JsZW0gb3Igbm90LCBzbyBpZiB0aGVyZSBp cyBub25lLCBubyBuZWVkIHRvIGRpZyBmdXJ0aGVyLiBXaXRoIHRoaXMsIHRoZSBvbmx5IHRoaW5n IHRoZSBjaGlsZCBjYW4gZG8gaXMgZ2xvYmFsbHkgcGljayBhbm90aGVyIHBhcmVudCwgYW5kLCBk ZXBlbmRpbmcgb24gdGhlIHJhbmdlIGluIHRoZSBzdGF0dXMsIG5ldmVyIGNvbWUgYmFjay4NCg0K QnV0IHRoZSBkaWdnaW5nIGZ1cnRoZXIsIEkgYWdyZWUsIGlzIG5vdCBzcGVjaWZpZWQuIElmIHRo ZSBncm91cHMgd2FudHMgaXQsIHdlJ2xsIGhhdmUgdG8gZGVzaWduIGFkZGl0aW9uYWwgc3R1ZmYg YW5kIGRyYWZ0IGl0Lg0KDQoqIFdlIGNvdWxkIHVzZSB0aGUgc3RhdHVzIGFzIGFuIGVudW1lcmF0 aW9uIHRoZSB3YXkgcGVvcGxlIHByb2JhYmx5IGV4cGVjdCBpdC4gQnV0IHlvdSdsbCBub3RlIHRo YXQgd2UgZGlkIG5vdCBjcmVhdGUgYSByZWdpc3RyeSBmb3IgaXQuDQoNCiogV2hpY2ggaGludHMg eW91IHRoYXQgd2UgY291bGQgYWxzbyB1c2UgaXQgYXMgYSBtZXRyaWMuIEEgc2NhbGFyIGRlZ3Jl ZSBvZiB1bndpbGxpbmduZXNzIHRvIHNlcnZlIGFzIGEgcGFyZW50LCB0aGF0IGFjY291bnRzIGZv ciBzdHVmZiBsaWtlIG1lbW9yeSwgYXZhaWxhYmxlIHRpbWUgc2xvdHMgaW4gYSBjaHVuayAoZm9y IDZUaVNDSCkgYW5kL29yIGJhdHRlcnkgZGVwbGV0aW9uIG9mIHRoZSBub2RlLiBUaGUgc3RhdHVz IHdvdWxkIHRyYW5zbGF0ZSBpbiBzdWNoIHRoaW5ncyBhcyBzZXJ2aW5nIGFzIGFsdGVybmF0ZSBi dXQgbm90IGFzIHByZWZlcnJlZCBwYXJlbnQuDQoNCkZvciBtb3JlIHNlbGVjdGl2ZSBzdHVmZiwg d2Ugd291bGQgaGF2ZSB0byBpbmRpY2F0ZSB0aGUgcHJvYmxlbSBpbiB0aGUgZGFvLWFjayBwZXIg cm91dGUgYWR2ZXJ0aXNlbWVudCB0aGF0IGlzIGEgcHJvYmxlbS4gVGhpcyBpcyBhIHN0ZXAgdGhh dCB3ZSBkaWQgbm90IHRha2Ugd2l0aCBSRkMgNjU1MCwgcGVvcGxlIGFkdmlzaW5nIHRoYXQgdGhl IGRyYWZ0IHdhcyB3b3JrYWJsZSBhbmQgdGhpY2sgZW5vdWdoIHdpdGhvdXQgaXQuDQoNClRoZSBw YXRoIHRoYXQgaXMgcmVhbGx5IGFjY2VwdGVkIGluIHN0b3JpbmcgbW9kZSBpcyBzZWxmIGFzIGEg dHJhbnNpdCBmb3IgYSBnaXZlbiB0YXJnZXQuIFRyYW5zaXQgY2FuIGJlIGFnZ3JlZ2F0ZWQgZm9y IG11bHRpcGxlIHRhcmdldHMuIEFuZCB0aGVyZSBjYW4gYmUgbXVsdGlwbGUgdHJhbnNpdHMgZm9y IGEgdGFyZ2V0LiBUaGUgREFPIEFjayBjb3VsZCBpbmNsdWRlIHRoZSBwYWlycyAodHJhbnNpdC90 YXJnZXQpIHRoYXQgYXJlIHRyb3VibGUgIGFuZCBpbmRpY2F0ZSBmb3IgZWFjaCB3aGF0IHRoZSB0 cm91YmxlIGlzLiBJdCBjb3VsZCBpbiB0aGVvcnkgYWdncmVnYXRlIHdoYXQncyBhZ2dyZWdhdGFi bGUsIGJ1dCB0aGUgd2F5IHRoZSBpbmZvIGluIHRoZSBkYW8gYWNrIGlzIGFnZ3JlZ2F0ZWQgbWF5 IGhhdmUgdG8gZGlmZmVyIGZyb20gd2hhdCB3YXMgcGxhY2VkIGluIHRoZSBEQU8uDQoNClRoZSBw YXRoIGNvbnRyb2wgZGVsZWdhdGVzIGEgcmlnaHQgdG8gcHJvcGFnYXRlIGFuZCBldmVudHVhbGx5 IGZhbiBvdXQgdGhlIGFkdmVydGlzZW1lbnQuIElmIHRoZSBUK1QgcGFpciBpcyBwbGFjZWQgaW4g dGhlIGRhbyBhY2ssIHRoZSBwYXRoIGNvbnRyb2wgY291bGQgYmUgdXNlZCB0byByZWZ1c2UgdGhh dCByaWdodCB0byBwcm9wYWdhdGUsIHNvIHRoZSBjaGlsZCB3b3VsZCBiZSBmcmVlIHRvIG9mZmVy IHRoYXQgcGFydGljdWxhciBwYWlyIHRvIGFuIGFsdGVybmF0ZSBwYXJlbnQuIFdlIHN0aWxsIGhh dmUgYml0cyBpbiB0aGUgdHJhbnNpdCB0aGF0IGNvdWxkIGluZGljYXRlIHN0dWZmIGlmIHdlIG5l ZWQgaXQgYXMgd2VsbC4NCg0KVGhvdWdodHM/DQoNClBhc2NhbA0KDQo+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+IEZyb206IFJvbGwgW21haWx0bzpyb2xsLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBDZW5rIEfDvG5kb2dhbg0KPiBTZW50OiBtYXJkaSAyOSBzZXB0ZW1icmUg MjAxNSAyMzowOA0KPiBUbzogcm9sbEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW1JvbGxdIFNl bWFudGljcyBvZiBEQU8gQUNLDQo+IA0KPiBIZWxsbyBKb2FraW0sDQo+IA0KPiBUaGlzIGlzIGFu IGludGVyZXN0aW5nIHF1ZXN0aW9uIGFuZCBJIGFsc28gY291bGRuJ3QgZmluZCBhbnkgYW5zd2Vy cyBpbiBSRkMNCj4gNjU1MC4NCj4gSG93ZXZlciwgbXkgdGhvdWdodHMgb24gdGhpcyBhcmUgYXMg Zm9sbG93czoNCj4gU2luY2UgYSBzdWItc2V0IG9mIHRoZSBhbm5vdW5jZWQgUlBMIHRhcmdldHMg Y291bGQgaGF2ZSBiZWVuIGFjY2VwdGVkDQo+IGJlZm9yZSBmaWxsaW5nIHVwIHRoZSByb3V0aW5n IHRhYmxlIChlLmcuKSwgSSB3b3VsZCBjaG9vc2UgYSBzdGF0dXMgY29kZQ0KPiBiZXR3ZWVuIDEg YW5kIDEyNy4NCj4gSSB3b3VsZCBleHBlY3QgYSBub2RlIHRvIGNob29zZSBhbm90aGVyIHBhcmVu dCBpZiBhIG1vcmUgYWdncmVzc2l2ZSBzdGF0dXMNCj4gY29kZSBpcyByZWNlaXZlZCAoWzEyOC0y NTVdKS4NCj4gQnV0IGEgZnVsbCByb3V0aW5nIHRhYmxlIGNhbiBoYXZlIGZyZWUgc3BhY2UgYWdh aW4gdW50aWwgdGhlIG5leHQgb3IgYW55DQo+IHN1YnNlcXVlbnQgREFPIGFycml2ZXMgLi4NCj4g dGhlcmVmb3JlIEkgcHJlZmVyIGEgIm1pbGQgcmVqZWN0aW9uIiB3aXRoIGEgc3RhdHVzIGNvZGUg b2YgWzEtMTI3XS4NCj4gDQo+IFRvIGdpdmUgc29tZSBmZWVkYmFjayB0byB0aGUgb3JpZ2luYXRv ciBvZiB0aGUgREFPLCBpdCBtaWdodCBiZSBzZW5zaWJsZSB0bw0KPiBjb3B5IHRoZSByZWplY3Rl ZCBSUEwgVGFyZ2V0IG9wdGlvbnMgZnJvbSB0aGUgYWZmZWN0ZWQgREFPIHRvIHRoZSBEQU8tDQo+ IEFDSywgc28gdGhhdCB0aGUgb3JpZ2luYXRvciBpcyBmdWxseSBhd2FyZSBvZiB3aGljaCBUYXJn ZXQgcHJlZml4ZXMgZ290DQo+IHJlamVjdGVkIChhbmQgd2hpY2ggb25lcyBnb3QgYWNjZXB0ZWQs IGltcGxpY2l0bHkpLg0KPiBJIHdvdWxkIGNob29zZSB0aGlzIG1ldGhvZCwgYmVjYXVzZSBpdCBk b2Vzbid0IHJlcXVpcmUgdGhlIG9yaWdpbmF0b3Igb2YgdGhlDQo+IERBTyB0byBzYXZlIGFueSBl eHRyYSBzdGF0ZSBhYm91dCB0aGUgREFPIGFuZCBpdHMgY29udGVudHMuDQo+IA0KPiBOb25ldGhl bGVzcywgZXZlcnl0aGluZyBJIHdyb3RlIGlzIG5vbmNvbmZvcm0gYW5kIEkgYW0gYWxzbyBpbnRl cmVzdGVkIGluDQo+IHRoZSBSUEwgZXhwZXJ0cycgb3BpbmlvbnMgYW5kIHNvbHV0aW9ucy4NCj4g DQo+IEJlc3QsDQo+IENlbmsNCj4gDQo+IE9uIDI5LjA5LjIwMTUgMjE6NDQsIEpvYWtpbSBFcmlr c3NvbiB3cm90ZToNCj4gPiBIZWxsbyBBbGwsDQo+ID4NCj4gPiBJIGhhdmUgc3BlbmQgcXVpdGUg c29tZSB0aW1lIHRvIGdldCBhIG1vcmUgc3RhYmxlIGltcGxlbWVudGF0aW9uIG9mDQo+ID4gREFP IGhhbmRsaW5nIGZvciBDb250aWtpIFJQTCBhbmQgSSBhbSBjdXJyZW50bHkgbG9va2luZyBpbnRv IERBTw0KPiA+IGFnZ3JlZ2F0aW9uLiBCdXQgSSByZWFsaXNlZCB0aGF0IGl0IGlzIGZvciBtZSBu b3QgMTAwJSBjbGVhciB3aGF0IGENCj4gPiBub2RlIHRoYXQgcmVjZWl2ZXMgYSBEQU8gd2l0aCBz ZXZlcmFsIHByZWZpeGVzIHRvIGJlIHJlZ2lzdGVyZWQgYnV0DQo+ID4gY2FuIG9ubHkgYWNjZXB0 IGEgc3ViLXNldCBvZiB0aGVtLiBTaG91bGQgaXQgYmUgYSBEQU9fTkFDSyBpbiB0aGlzIGNhc2UN Cj4gb3IgaXMgdGhlcmUgYW55IG90aGVyIHdheSB0byBoYW5kbGUgdGhhdCBjYXNlPw0KPiA+DQo+ ID4gSWYgZWFjaCB3b3VsZCBoYXZlIGJlZW4gc2VudCBzZXBhcmF0ZWx5IGl0IGlzIG9idmlvdXMg dGhhdCB0aGUNCj4gPiByZWNlaXZpbmcgbm9kZSBjYW4gZG8gYSBOQUNLIHdoZW4gdGhlIHJvdXRp bmcgdGFibGUgaXMgZnVsbCBhbmQNCj4gPiB0aGVyZWZvcmUgaXQgaXMgcG9zc2libGUgdG8gZ2V0 IGZpbmUtZ3JhaW5lZCBhbnN3ZXJzLiBCdXQgd2l0aCBhZ2dyZWdhdGlvbg0KPiBvZiBEQU9zIHRo aXMgaXMgbm90IHRoZSBjYXNlLg0KPiA+DQo+ID4gQW55IGlkZWFzPw0KPiA+DQo+ID4gQmVzdCBy ZWdhcmRzLA0KPiA+IOKAlCBKb2FraW0gRXJpa3Nzb24sIFNJQ1MNCj4gPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IFJvbGwgbWFpbGluZyBsaXN0 DQo+ID4gUm9sbEBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vcm9sbA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gUm9sbCBtYWlsaW5nIGxpc3QNCj4gUm9sbEBpZXRmLm9yZw0KPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGwNCg== From nobody Wed Sep 30 08:51:07 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C528D1B5EBE for ; Wed, 30 Sep 2015 08:51:05 -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=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IO2upbLlYl9R for ; Wed, 30 Sep 2015 08:51:04 -0700 (PDT) Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56A681B5EBD for ; Wed, 30 Sep 2015 08:51:03 -0700 (PDT) Received: by lahh2 with SMTP id h2so51734435lah.0 for ; Wed, 30 Sep 2015 08:51:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=8SxX9eOdG9ajbTlYHGpU+DJCQirqI/c/0VdwTLYSmY4=; b=dSgYUQvvJxF7q5lzOtvIEnbS5ae9qcfsSfoOy3cMS+ua/0KwGWGAh6zMX/6EUT6qnc 8/GYxl24T/mYjlsSWNxLJsZA4HX2U8b1IXNroL+amPmvqEQwnTuyHpGF5PkmnkKLv1tJ APvG+M4+eSUobphsUgCCdd+K52pvOhEh5/Y7QGBxZGb2/S4Ad2C+FEOe1Hv0IsxQanSC WJWyVT/N1WmHnkaXaMkb/h2xCZtG4Rd2DLCkcnPyI3/PlmEvEWaDbRRQ+u4IbBRIFfpI Jl7TbW9VaAUKClZ4rnqQbj2q0Bsr3KAveHOrlujBwx4zd54Xt1FqaeWTcormWeNGhD8/ 1nVw== X-Gm-Message-State: ALoCoQmSXTPATpaw3yJRj3LwmuKUYO6KEBwv/dB4cCgN//hpjviDdnm6FpEobpq12qzYVh5tALEs X-Received: by 10.112.16.199 with SMTP id i7mr1335006lbd.105.1443628261183; Wed, 30 Sep 2015 08:51:01 -0700 (PDT) Received: from [192.168.1.102] (h31n15-sbg-a11.ias.bredband.telia.com. [195.67.245.31]) by smtp.gmail.com with ESMTPSA id ca11sm133225lad.48.2015.09.30.08.51.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Sep 2015 08:51:00 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_A1447DDF-FBB6-4C61-9201-42FE3BC7EF5E" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Joakim Eriksson In-Reply-To: <560AFDBB.8050505@gmail.com> Date: Wed, 30 Sep 2015 17:50:59 +0200 Message-Id: <98263B30-2739-4923-8E4A-0235EFDB3F8F@sics.se> References: <6d21d0f86ab14ae7a99ff9fe6873b1fd@XCH-RCD-001.cisco.com> <560AFDBB.8050505@gmail.com> To: Routing Over Low power and Lossy networks X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [Roll] Semantics of DAO ACK X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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 Sep 2015 15:51:05 -0000 --Apple-Mail=_A1447DDF-FBB6-4C61-9201-42FE3BC7EF5E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 29 Sep 2015, at 23:08, Cenk G=C3=BCndogan = wrote: >=20 > This is an interesting question and I also couldn't find any answers = in RFC 6550. > However, my thoughts on this are as follows: > Since a sub-set of the announced RPL targets could have been accepted = before filling up > the routing table (e.g.), I would choose a status code between 1 and = 127. > I would expect a node to choose another parent if a more aggressive = status code is received ([128-255]). > But a full routing table can have free space again until the next or = any subsequent DAO arrives .. > therefore I prefer a "mild rejection" with a status code of [1-127]. Yes, but I am in bad need to know exactly what was accepted or not since = I would like to provide full scalability and reliability of the =E2=80=9Cpromised=E2=80=9D= routes. But it is very hard to know the best thing to do for aggregated DAOs. At the moment I am keeping the = single DAO target model that we have been using for registration - but I am considering to = do aggregation on no-path DAOs since they can not fail in the same way. >=20 > To give some feedback to the originator of the DAO, it might be = sensible to copy the > rejected RPL Target options from the affected DAO to the DAO-ACK, so = that the originator is fully > aware of which Target prefixes got rejected (and which ones got = accepted, implicitly). > I would choose this method, because it doesn't require the originator = of the DAO to save any extra state > about the DAO and its contents. Yes, that would work - but I guess we would need to specify clearly in a = RFC-add-on how to handle this.=20 > Nonetheless, everything I wrote is nonconform and I am also interested = in the RPL experts' opinions > and solutions. Yes, I think this topic is something we need to figure out to get out = the full potential of RPL.=20 Best regards, =E2=80=94 Joakim > Best, > Cenk --Apple-Mail=_A1447DDF-FBB6-4C61-9201-42FE3BC7EF5E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 29 Sep 2015, at 23:08, Cenk G=C3=BCndogan <cnkgndgn@gmail.com> = wrote:

This is an interesting question and I also = couldn't find any answers in RFC 6550.
However, my thoughts on this are as = follows:
Since a sub-set of the = announced RPL targets could have been accepted before filling = up
the routing table (e.g.), = I would choose a status code between 1 and 127.
I would expect a node to choose another parent = if a more aggressive status code is received ([128-255]).
But a full routing table can have free space = again until the next or any subsequent DAO arrives ..
therefore I prefer a "mild rejection" with a = status code of [1-127].

Yes, = but I am in bad need to know exactly what was accepted or not since I = would like to
provide full scalability and reliability of the = =E2=80=9Cpromised=E2=80=9D routes. But it is very hard to = know
the best thing to do for aggregated DAOs. At the moment I = am keeping the single DAO target
model that we have been using = for registration - but I am considering to do aggregation
on = no-path DAOs since they can not fail in the same way.


To give some feedback to the originator of the = DAO, it might be sensible to copy the
rejected RPL Target options from the affected = DAO to the DAO-ACK, so that the originator is fully
aware of which Target prefixes got rejected (and = which ones got accepted, implicitly).
I would choose this method, because it doesn't = require the originator of the DAO to save any extra state
about the DAO and its contents.

Yes, that would = work - but I guess we would need to specify clearly in a RFC-add-on = how
to handle this. 

Nonetheless, = everything I wrote is nonconform and I am also interested in the RPL = experts' opinions
and solutions.

Yes, I think this topic is = something we need to figure out to get out the full potential of = RPL. 


Best regards,
=E2=80=94 Joakim

Best,
Cenk

= --Apple-Mail=_A1447DDF-FBB6-4C61-9201-42FE3BC7EF5E-- From nobody Wed Sep 30 08:55:48 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 845ED1B5EB5 for ; Wed, 30 Sep 2015 08:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N5L62-NT4RDQ for ; Wed, 30 Sep 2015 08:55:45 -0700 (PDT) Received: from mail-la0-f50.google.com (mail-la0-f50.google.com [209.85.215.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58DED1B5E7E for ; Wed, 30 Sep 2015 08:55:45 -0700 (PDT) Received: by laclj5 with SMTP id lj5so51790249lac.3 for ; Wed, 30 Sep 2015 08:55:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=6oBp3oh4g3iJ6QSEx/b7do5g5oy7WnOb1zSyj8hIK6M=; b=TkXtVDMDbIIkJvSOKwyrJrOHlphqx6UhtrO5yawAC9RsqBwdBVO94dcxUzHbZxZatO 4MAOosulw7GhMc8FSsOmBB+4hsUGREH7CSuG5sM58ZlmnOpsutUZVr/kObml+maSWBjS c/KvTPDcwFqSKv3lXBbPQGRBldmKK9hx6ItBrUcei09CUEmEpcMTJhpNHhPr1fofgXzt XTp+2sXP0VUdUpWqe9HG6Z0xzu0WHV2vBtTn6RHNZQDCsjmOSLbu1PTsNxMM2wymIIDM shntBeg6M/JzUUnP+xeaCR3msoVP7gx5/GlZfIEZaInBjSY2L6EWkNco4yX3SRvCTRDA enXA== X-Gm-Message-State: ALoCoQlLp16cT1l0YwcgFocOsx08GZmH+LhOSf/FeWNrIpNSEtUoQnSI3RF1yCJFBl5OfoNVLD/R X-Received: by 10.112.55.2 with SMTP id n2mr1428762lbp.59.1443628543095; Wed, 30 Sep 2015 08:55:43 -0700 (PDT) Received: from [192.168.1.102] (h31n15-sbg-a11.ias.bredband.telia.com. [195.67.245.31]) by smtp.gmail.com with ESMTPSA id s8sm141213lae.18.2015.09.30.08.55.42 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Sep 2015 08:55:42 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Joakim Eriksson In-Reply-To: <560B68B2.6030501@fbk.eu> Date: Wed, 30 Sep 2015 17:55:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <245E0C92-6ED6-426B-95E1-09BA8736F1BC@sics.se> References: <6d21d0f86ab14ae7a99ff9fe6873b1fd@XCH-RCD-001.cisco.com> <560AFDBB.8050505@gmail.com> <560B68B2.6030501@fbk.eu> To: Routing Over Low power and Lossy networks X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [Roll] Semantics of DAO ACK X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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 Sep 2015 15:55:47 -0000 > On 30 Sep 2015, at 06:44, Csaba Kiraly wrote: >=20 > Hello Joakim, >=20 > I have also worked on the Contiki DAO-ACK code, enabling ACKs, = implementing fixes to the DAOSequence handling, and looking into = multiple targets. Nice, I have a PR on Contiki now with what we have been doing to get = Contiki RPL more scalable (but still only single targets / paths). > What Cenk is saying sounds a reasonable hack, but the standard itself = is in my opinion a bit underspecified for the semantics of DAO-ACK = messages in several ways. Yes, it is underspecified. There is need for clarifications and more = details on the DAO / DAO ACK! > My preferred solution for ACKing DAO messages with multiple targets = would be to have support for the same semantics that you would have had = with one DAO message per Target, i.e., I would prefer an option field = that gives an individual status for each Target. Yes, but that would require more memory in the sending node to keep = track of things or full specification of the target in the response. I guess it might be solved by allowing multiple DAO ACKs for the same = DAO and to have the Target options included in the DAO ACK. >=20 > To give another example of subtle problems with DAO-ACK, it was not = clear to me whether I want my implementation to ACK when the Target is = added to the routing table, or only when this node itself receives an = ACK for the same Target from its parent. Both makes sense, with the = former giving a quick one-hop ACK, while the latter works as an = end-to-end ACK, ensuring that the path is actually built. Both look = conformant to the standard, but I suppose the original author was = thinking of the former, and I can easily see interoperability problems = arising between two implementations using different semantics. >=20 We did go for the end-to-end ACK to achieve better scalability. There is = to me no point having a route to the parent if it is not possible to get it all the way to root. But I totally agree - this is not obvious = from the RPL RFC either. Do you have your Contiki code somewhere in the open-source? Best regards, =E2=80=94 Joakim > Best regards, > Csaba >=20 > On 29/09/15 23:08, Cenk G=C3=BCndogan wrote: >> Hello Joakim, >>=20 >> This is an interesting question and I also couldn't find any answers = in RFC 6550. >> However, my thoughts on this are as follows: >> Since a sub-set of the announced RPL targets could have been accepted = before filling up >> the routing table (e.g.), I would choose a status code between 1 and = 127. >> I would expect a node to choose another parent if a more aggressive = status code is received ([128-255]). >> But a full routing table can have free space again until the next or = any subsequent DAO arrives .. >> therefore I prefer a "mild rejection" with a status code of [1-127]. >>=20 >> To give some feedback to the originator of the DAO, it might be = sensible to copy the >> rejected RPL Target options from the affected DAO to the DAO-ACK, so = that the originator is fully >> aware of which Target prefixes got rejected (and which ones got = accepted, implicitly). >> I would choose this method, because it doesn't require the originator = of the DAO to save any extra state >> about the DAO and its contents. >>=20 >> Nonetheless, everything I wrote is nonconform and I am also = interested in the RPL experts' opinions >> and solutions. >>=20 >> Best, >> Cenk >>=20 >> On 29.09.2015 21:44, Joakim Eriksson wrote: >>> Hello All, >>>=20 >>> I have spend quite some time to get a more stable implementation of = DAO handling >>> for Contiki RPL and I am currently looking into DAO aggregation. But = I realised that >>> it is for me not 100% clear what a node that receives a DAO with = several prefixes to >>> be registered but can only accept a sub-set of them. Should it be a = DAO_NACK in >>> this case or is there any other way to handle that case? >>>=20 >>> If each would have been sent separately it is obvious that the = receiving node can >>> do a NACK when the routing table is full and therefore it is = possible to get fine-grained >>> answers. But with aggregation of DAOs this is not the case. >>>=20 >>> Any ideas? >>>=20 >>> Best regards, >>> =E2=80=94 Joakim Eriksson, SICS >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>=20 >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Wed Sep 30 09:06:27 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 392921B5ED9 for ; Wed, 30 Sep 2015 09:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ub5eDI3Wnse7 for ; Wed, 30 Sep 2015 09:06:24 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0C811B4654 for ; Wed, 30 Sep 2015 09:06:21 -0700 (PDT) Received: by laer8 with SMTP id r8so52077585lae.2 for ; Wed, 30 Sep 2015 09:06:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=rOwB3mhUWATxnI8zECjUd/H1g8+Oo0+yTV2bLPSNhBg=; b=PPnhUsAkVtOrfAnntQtbxV6bTE1gwGixbaGfPzZXU3914VluBqJFQ/DuxCiG8nk9Ac nUoEmPwag5NC9XJaWxYAH6cC1OngCMMAFwPnj8w2XICTGS0UpmaRRTr0V736QQaGbjHE ZvQwXWngqir1WBrt1d9Y914la2iFVLqQyn/srN1UGhbBI8lbfZriW53cbU4QF+RUdzSJ LTag6l9rA8AxM7KnVbddsgYNNW5SOXBQAEodLPSSLZJXYJui6SgEi9RHnhUfx63y0iee 2AF1ElXTYONd2E2usxlJa3jhfVu6Xv2Qwoyn/5bts/LDQSFGRdE6zcL2N4FvZj/k2MOM JzTA== X-Gm-Message-State: ALoCoQmAHFLkMewr2KemJUbfXR6zqMZNogtNS+OqpdNyW18syPnwC+0Qg+778iwMeBR7vL6/LslV X-Received: by 10.112.134.197 with SMTP id pm5mr1327880lbb.3.1443629179730; Wed, 30 Sep 2015 09:06:19 -0700 (PDT) Received: from [192.168.1.102] (h31n15-sbg-a11.ias.bredband.telia.com. [195.67.245.31]) by smtp.gmail.com with ESMTPSA id ar7sm144510lbc.24.2015.09.30.09.06.18 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Sep 2015 09:06:18 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Joakim Eriksson In-Reply-To: <8f1d44568afa4348a05169bedc3c3020@XCH-RCD-001.cisco.com> Date: Wed, 30 Sep 2015 18:06:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <518931B3-E437-4086-82B0-ADFB57F96646@sics.se> References: <6d21d0f86ab14ae7a99ff9fe6873b1fd@XCH-RCD-001.cisco.com> <560AFDBB.8050505@gmail.com> <8f1d44568afa4348a05169bedc3c3020@XCH-RCD-001.cisco.com> To: Routing Over Low power and Lossy networks X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [Roll] Semantics of DAO ACK X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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 Sep 2015 16:06:26 -0000 > On 30 Sep 2015, at 09:58, Pascal Thubert (pthubert) = wrote: >=20 > Hello all: >=20 > The DAO ACK status really is a summary that indicates that there was a = problem or not, so if there is none, no need to dig further. With this, = the only thing the child can do is globally pick another parent, and, = depending on the range in the status, never come back. >=20 > But the digging further, I agree, is not specified. If the groups = wants it, we'll have to design additional stuff and draft it. >=20 Yes - lets try to get this designed and detailed so that we can get = interoperability between implementations!=20 I would be happy to provide what we have been doing to get our = implementation working! > * We could use the status as an enumeration the way people probably = expect it. But you'll note that we did not create a registry for it. Not yet - I guess creating a registry might be fairly easy? >=20 > * Which hints you that we could also use it as a metric. A scalar = degree of unwillingness to serve as a parent, that accounts for stuff = like memory, available time slots in a chunk (for 6TiSCH) and/or battery = depletion of the node. The status would translate in such things as = serving as alternate but not as preferred parent. Not sure that degree of unwillingness can be specified in a clear way so = that everybody will interpret it the same way. But sure - it is an option. I have done a =E2=80=9Cquick hack=E2=80=9D and = defined 255 as =E2=80=9CRoot is out of routes=E2=80=9D. Because if you = get that type of response - there is no immediate need to look for another parent and = another path - it will not work anyway=E2=80=A6 (that is if the node is desired to get a path all the way to/from root). >=20 > For more selective stuff, we would have to indicate the problem in the = dao-ack per route advertisement that is a problem. This is a step that = we did not take with RFC 6550, people advising that the draft was = workable and thick enough without it. >=20 Yes, and we were tired of writing more I guess - and eager to implement = ;-) > The path that is really accepted in storing mode is self as a transit = for a given target. Transit can be aggregated for multiple targets. And = there can be multiple transits for a target. The DAO Ack could include = the pairs (transit/target) that are trouble and indicate for each what = the trouble is. It could in theory aggregate what's aggregatable, but = the way the info in the dao ack is aggregated may have to differ from = what was placed in the DAO. Yes, the thing with todays RFC is that there is not yet any defined = options for the DAO ACK - but that is of course easy to add. One other = option would be to add a flag into the DAO that says =E2=80=9Call-or-nothing=E2=80= =9D. If it is set all routes or no-routes should be installed. It is a = bit complex possibly but it would be very clear when the DAO sending node gets the ack what = happened. < 128 means all routes are installed. >=3D128 means none was installed.=20 >=20 > The path control delegates a right to propagate and eventually fan out = the advertisement. If the T+T pair is placed in the dao ack, the path = control could be used to refuse that right to propagate, so the child = would be free to offer that particular pair to an alternate parent. We = still have bits in the transit that could indicate stuff if we need it = as well. Yes, but I my case I am doing the simple case of just registering with = one single parent / one single DAO path per target. My current =E2=80=9Cplan=E2=80=9D is to avoid aggregation when doing the = regular DAO but possibly aggregate the no-path DAO since that one can not possibly cause out-of-memory or other problems (or?). Best regards, =E2=80=94 Joakim > Thoughts? >=20 > Pascal >=20 >> -----Original Message----- >> From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Cenk G=C3=BCndog= an >> Sent: mardi 29 septembre 2015 23:08 >> To: roll@ietf.org >> Subject: Re: [Roll] Semantics of DAO ACK >>=20 >> Hello Joakim, >>=20 >> This is an interesting question and I also couldn't find any answers = in RFC >> 6550. >> However, my thoughts on this are as follows: >> Since a sub-set of the announced RPL targets could have been accepted >> before filling up the routing table (e.g.), I would choose a status = code >> between 1 and 127. >> I would expect a node to choose another parent if a more aggressive = status >> code is received ([128-255]). >> But a full routing table can have free space again until the next or = any >> subsequent DAO arrives .. >> therefore I prefer a "mild rejection" with a status code of [1-127]. >>=20 >> To give some feedback to the originator of the DAO, it might be = sensible to >> copy the rejected RPL Target options from the affected DAO to the = DAO- >> ACK, so that the originator is fully aware of which Target prefixes = got >> rejected (and which ones got accepted, implicitly). >> I would choose this method, because it doesn't require the originator = of the >> DAO to save any extra state about the DAO and its contents. >>=20 >> Nonetheless, everything I wrote is nonconform and I am also = interested in >> the RPL experts' opinions and solutions. >>=20 >> Best, >> Cenk >>=20 >> On 29.09.2015 21:44, Joakim Eriksson wrote: >>> Hello All, >>>=20 >>> I have spend quite some time to get a more stable implementation of >>> DAO handling for Contiki RPL and I am currently looking into DAO >>> aggregation. But I realised that it is for me not 100% clear what a >>> node that receives a DAO with several prefixes to be registered but >>> can only accept a sub-set of them. Should it be a DAO_NACK in this = case >> or is there any other way to handle that case? >>>=20 >>> If each would have been sent separately it is obvious that the >>> receiving node can do a NACK when the routing table is full and >>> therefore it is possible to get fine-grained answers. But with = aggregation >> of DAOs this is not the case. >>>=20 >>> Any ideas? >>>=20 >>> Best regards, >>> =E2=80=94 Joakim Eriksson, SICS >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>=20 >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Wed Sep 30 09:40:56 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4737F1B4774; Wed, 30 Sep 2015 09:40:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G64yYs0JnFZU; Wed, 30 Sep 2015 09:40:50 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C38951A7028; Wed, 30 Sep 2015 09:40:50 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id A26F28814A; Wed, 30 Sep 2015 09:40:50 -0700 (PDT) Received: from clemson.jhuapl.edu (swifi-nat.jhuapl.edu [128.244.87.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id D8E16328081A; Wed, 30 Sep 2015 09:40:49 -0700 (PDT) To: Yusuke DOI , roll@ietf.org, iesg@ietf.org References: <20150909143959.25684.48803.idtracker@ietfa.amsl.com> <560B72CB.5030305@toshiba.co.jp> From: Brian Haberman Message-ID: <560C1090.4080503@innovationslab.net> Date: Wed, 30 Sep 2015 12:40:48 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <560B72CB.5030305@toshiba.co.jp> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="4a77xgOn7tETTMx3IJbPceaPue9dCwoWv" Archived-At: Cc: roll-chairs@ietf.org, draft-ietf-roll-mpl-parameter-configuration@ietf.org, draft-ietf-roll-mpl-parameter-configuration.shepherd@ietf.org, maria.ines.robles@ericsson.com, draft-ietf-roll-mpl-parameter-configuration.ad@ietf.org Subject: Re: [Roll] Brian Haberman's Discuss on draft-ietf-roll-mpl-parameter-configuration-07: (with DISCUSS and COMMENT) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 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 Sep 2015 16:40:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --4a77xgOn7tETTMx3IJbPceaPue9dCwoWv Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable These changes look good. Regards, Brian On 9/30/15 1:27 AM, Yusuke DOI wrote: > Hi Brian, >=20 > Thank you very much for your review! >=20 >> ----------------------------------------------------------------------= >> DISCUSS: >> ----------------------------------------------------------------------= > (snip) >> 2. In section 2.3 (MPL Forwarder Behavior), there should be a brief >> discussion of the role of the MPL Domain Address and include a referen= ce >> to [I-D.ietf-roll-trickle-mcast]. > (snip) >=20 > Does the following text added on Section 2.3 looks good for you? >=20 >=20 > """ > If a DHCPv6 client requests and receives the MPL Parameter > Configuration Option, the node SHOULD join the MPL domain given by > the option and act as an MPL forwarder. Note that there may be cases > in which a node may fail to join a domain (or domains) due to local > resource constraints. Each joining node SHOULD configure its MPL > forwarder with the given parameter set for the MPL domain. > > Each MPL domain is defined by an MPL Domain Address given by an MPL > Parameter Configuration Option. As defined in Section 2 of > [I-D.ietf-roll-trickle-mcast], an MPL Domain Address is an IPv6 > multicast address associated to a set of MPL network interfaces > in an MPL Domain. > > """ >=20 >> ----------------------------------------------------------------------= >> COMMENT: >> ----------------------------------------------------------------------= >> >> - Why is the text in Appendix A not in the Operational Considerations >> section? >=20 > It's my another mistake. I'll move it on next revision (already merged > as operational consideration on my local repo) >=20 > Best Regards, >=20 > // Yusuke DOI >=20 > On 2015-09-09 23:39, Brian Haberman wrote: >> Brian Haberman has entered the following ballot position for >> draft-ietf-roll-mpl-parameter-configuration-07: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut thi= s >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.h= tml >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-roll-mpl-parameter-configu= ration/ >> >> >> >> >> ----------------------------------------------------------------------= >> DISCUSS: >> ----------------------------------------------------------------------= >> >> Updated for -07... >> >> 1. Resolved >> >> 2. In section 2.3 (MPL Forwarder Behavior), there should be a brief >> discussion of the role of the MPL Domain Address and include a referen= ce >> to [I-D.ietf-roll-trickle-mcast]. >> >> 3. Resolved >> >> >> ----------------------------------------------------------------------= >> COMMENT: >> ----------------------------------------------------------------------= >> >> - Why is the text in Appendix A not in the Operational Considerations >> section? >> >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> >=20 --4a77xgOn7tETTMx3IJbPceaPue9dCwoWv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJWDBCQAAoJEBOZRqCi7goqCgkH/Rw5XJMxOv0LGCtXqxiiIOzU vfu3xAcyhhGa6yUNFEkcy5EKfuvC+gq+QU3TjIjhJ7Xs6b518Q2rt4OtDDw2tO2q Fb1mdVn9wOPYG6q9infp4EN7Y60m3J+65HHwNkFn+Lw74LHsEN9QE8+av25dFR6U kUto6ea4GitVLzsive6YRdU+bsJbJ7iUgadnQHm/MBDA8eBi7lsa1tQsxAHLvxBo uT1846yn0iZJ0WfSx8Xr/0ZBqEfEq11NfytOje/Qkebb5nNC4cdNy1QQWiWWrO1a wDp8SDgoQFg7MtdMQLe/cqZucPt9heJDnTHZ8P/yvKgrvN6CvwLctRMSMxmJjkk= =93HU -----END PGP SIGNATURE----- --4a77xgOn7tETTMx3IJbPceaPue9dCwoWv--