From nobody Wed Nov 1 03:07:26 2017 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78EA813F6C4 for ; Wed, 1 Nov 2017 03:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.08 X-Spam-Level: X-Spam-Status: No, score=0.08 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 rmAn-I6GbwFX for ; Wed, 1 Nov 2017 03:07:22 -0700 (PDT) Received: from lb3-smtp-cloud9.xs4all.net (lb3-smtp-cloud9.xs4all.net [194.109.24.30]) (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 F0E541395F0 for ; Wed, 1 Nov 2017 03:07:21 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:204]) by smtp-cloud9.xs4all.net with ESMTPA id 9pvbeCVklnIXb9pvbeAWpc; Wed, 01 Nov 2017 11:07:20 +0100 Received: from AMontpellier-654-1-160-210.w90-0.abo.wanadoo.fr ([90.0.255.210]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 01 Nov 2017 11:07:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 01 Nov 2017 11:07:19 +0100 From: peter van der Stok To: Roll Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org Message-ID: <5edec33fd70903438539e60015f391ab@xs4all.nl> X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfKzpr7N2tKs4dnG7gW2S5mAFfjJ+L1nJq/ZKDlGgxdaBRdSbq8o7YBuAXFllUW27pldTm+yFz5v5BL5q3HOZQ3NKKNvZSsjIL1LfFDRGlp4hTrjBryoO LSwUWSbC6F/pmbFICA2KrjkUshUlqHTlAx7JOuzmFd7dSKKKfslrbUGogvwuYHtSQONOdX6yYnbpocKqHnC7lbMcxvWT41DP8vo= Archived-At: Subject: [Roll] Roll agenda X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 10:07:24 -0000 HI Roll, The PRELIMINARY agenda has been uploaded. Given the low ML traffic we asked for one hour and a half; With the current agenda we go beyond. Some arrangements are still necessary; see https://datatracker.ietf.org/meeting/100/materials/agenda-100-roll/ Thanks for your understanding, Peter -- Peter van der Stok vanderstok consultancy mailto: consultancy@vanderstok.org www: www.vanderstok.org tel NL: +31(0)492474673 F: +33(0)966015248 From nobody Thu Nov 2 02:05:56 2017 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E734013F569; Thu, 2 Nov 2017 02:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 u7pxmlhd8UZB; Thu, 2 Nov 2017 02:05:53 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFFFE13F3F5; Thu, 2 Nov 2017 02:05:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11663; q=dns/txt; s=iport; t=1509613553; x=1510823153; h=from:to:cc:subject:date:message-id:mime-version; bh=TvG6JlOwW6PNg2fU1w1cA8v/jwd2LwQGQnIWYdN4nsk=; b=cEFLTusWAMdywhpLkU81la4I/5Sybe9+HrQbLQuvpypU9S7BaNo4W3Yl IL1tpRFIqCyuHVLTXYSb4A10Ay6g/0eU73l4G/hzE4OiXQSNF0DHF2gEp l93BcSd8P0jOmKhmk2BdJB1uqXJD38Tn1bkbfCnX89pFDcPLUIdlx5xzd 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CyAAAv3/pZ/5pdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgkRwZG4ujhWPGpJ7hUYQggEKI4UYhQw/GAEBAQEBAQEBAWsohVF?= =?us-ascii?q?MEgGBACYBBA4NiTdkEKsDixcBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYMuggeBU?= =?us-ascii?q?4FpiAOGLwWiDQKHZI0NkzuMYYkIAhEZAYE4AR84gWx6FYMugloBHIFnjE+BEQE?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos; i="5.44,333,1505779200"; d="scan'208,217"; a="25072744" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Nov 2017 09:05:52 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id vA295pDr023505 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 2 Nov 2017 09:05:51 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.1320.4; Thu, 2 Nov 2017 04:05:51 -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.1320.000; Thu, 2 Nov 2017 04:05:51 -0500 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks CC: "roll-chairs@ietf.org" Thread-Topic: Does BIER ROLL? Thread-Index: AdNTtHg9V6EGAiYcS72JT8pNAXqUlQ== Date: Thu, 2 Nov 2017 09:05:51 +0000 Deferred-Delivery: Thu, 2 Nov 2017 09:05:08 +0000 Message-ID: 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.90.201] Content-Type: multipart/alternative; boundary="_000_c2ebc4764c6d4c3983b3a3f622909effXCHRCD001ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [Roll] Does BIER ROLL? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 09:05:55 -0000 --_000_c2ebc4764c6d4c3983b3a3f622909effXCHRCD001ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all ; At the last IETF, I presented how BIER can be used in RPL for storing mode-= unicast, multicast, and reliable multicast. I published https://tools.ietf.= org/html/draft-thubert-roll-bier-00 to explain it in more details. In that draft, I position Bloom Filters as a bitmap compression option. I l= eft open a number of questions for which I guess that protocol elements are= needed: 6.2.1. Computing and Saving Bloom Filters 6.2.2. Forwarding based on Bloom Filters 6.2.3. Hash Functions Distribution And then we have a WG doc, https://tools.ietf.org/html/draft-ietf-roll-ccas= t-01 that focusses on non-storing multicast with Bloom only. You'll note th= at ccast does not yet address the questions above on Bloom, and that there'= s a lot of remaining work just for Bloom. As you see, there is a 3D matrix here, mode * routing * compression, IOW st= oring vs. non-storing mode * reliable multicast vs. multicast vs. unicast *= flat vs. Bloom vs. ? which appears to have at least 12 combinations. But i= n fact, I'd argue that the three dimensions are orthogonal and can be treat= ed separately. The current position of the WG, which has a single WG doc, ccast, that cove= rs only one combination only, seems lacking to me. Did we think that throug= h? I think not. I think we understood the benefits of bitmaps but did not clea= rly studied the scope we wanted to cover. I'd like to discuss the options at the next IETF and decide which WG doc(s)= we really want to cover the 3 dimensions. I can see at least: - A) 2 docs, whereby I remove compression from mine, and we keep cc= ast as is. - B) One document with all dimensions in it - C) 2 docs, one without Bloom compression and one that focusses on= the Bloom compression for all (modes*routing) including non-BIER - D) 3 docs, the 2 above, and the 6LoRH separate. I like C) and D), because there is a lot that's needed for Bloom, in partic= ular the distribution of hash functions, that is very special to that techn= ique. Also Bloom can compress anything. We could for instance hash the IPv6= address on the outgoing port that needs to forward in non-storing to speci= fy the multicast tree in non-storing mode, and hash the destination in stor= ing mode, since the Bloom filters are additive. What do others think? Pascal --_000_c2ebc4764c6d4c3983b3a3f622909effXCHRCD001ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all ;<= /p>

 

At the last IETF, I presented how BIER can be used i= n RPL for storing mode-unicast, multicast, and reliable multicast. I publis= hed https://= tools.ietf.org/html/draft-thubert-roll-bier-00 to explain it in more de= tails.

In that draft, I position Bloom Filters as a bitmap = compression option. I left open a number of questions for which I guess tha= t protocol elements are needed:

6.2.1.  Computing and Saving Bloom Filters=

6.2.2.  Forwarding based on Bloom Filters<= /o:p>

6.2.3.  Hash Functions Distribution<= /p>

 

And then we have a WG doc, https://tools.ietf.org/html/draft-ietf-roll-ccast-01 that focusses on n= on-storing multicast with Bloom only. You’ll note that ccast does not= yet address the questions above on Bloom, and that there’s a lot of = remaining work just for Bloom.

 

As you see, there is a 3D matrix here, mode * routin= g * compression, IOW storing vs. non-storing mode * reliable multicast vs. = multicast vs. unicast * flat vs. Bloom vs. ? which appears to have at least= 12 combinations. But in fact, I’d argue that the three dimensions are orthogonal and can be treated separate= ly.

 

The current position of the WG, which has a single W= G doc, ccast, that covers only one combination only, seems lacking to me. D= id we think that through?   

 

I think not. I think we understood the benefits of b= itmaps but did not clearly studied the scope we wanted to cover.

 

I’d like to discuss the options at the next IE= TF and decide which WG doc(s) we really want to cover the 3 dimensions.

 

I can see at least:

-     &= nbsp;   A) 2 docs, whereby I remove compression from mine, = and we keep ccast as is.

-     &= nbsp;   B) One document with all dimensions in it

-     &= nbsp;   C) 2 docs, one without Bloom compression and one th= at focusses on the Bloom compression for all (modes*routing) including non-= BIER

-     &= nbsp;   D) 3 docs, the 2 above, and the 6LoRH separate.

 

I like C) and D), because there is a lot that’= s needed for Bloom, in particular the distribution of hash functions, that = is very special to that technique. Also Bloom can compress anything. We cou= ld for instance hash the IPv6 address on the outgoing port that needs to forward in non-storing to specify the mult= icast tree in non-storing mode, and hash the destination in storing mode, s= ince the Bloom filters are additive.

 

What do others think?

 

Pascal

 

 

--_000_c2ebc4764c6d4c3983b3a3f622909effXCHRCD001ciscocom_-- From nobody Thu Nov 2 02:22:09 2017 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 915EF13F47C for ; Thu, 2 Nov 2017 02:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=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 FtyGAu7mJ2SH for ; Thu, 2 Nov 2017 02:22:06 -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 7F28713F646 for ; Thu, 2 Nov 2017 02:22:04 -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 vA29LuWQ005020 for ; Thu, 2 Nov 2017 10:21:56 +0100 (CET) Received: from [192.168.217.124] (p5DC7FC78.dip0.t-ipconnect.de [93.199.252.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3ySKNN5gwbzDX68; Thu, 2 Nov 2017 10:21:56 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: Date: Thu, 2 Nov 2017 10:21:55 +0100 X-Mao-Original-Outgoing-Id: 531307315.800838-3eac0917f367318b599a3357640ece99 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Routing Over Low power and Lossy networks X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Roll] Does BIER ROLL? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 09:22:08 -0000 On Nov 2, 2017, at 10:05, Pascal Thubert (pthubert) = wrote: >=20 > What do others think? I for one would like to understand the IPR landscape some more before we = focus on specific branches of this interesting design tree. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Nov 2 03:10:27 2017 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32C9713F642 for ; Thu, 2 Nov 2017 03:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 OKyZ6Ru_NMwV for ; Thu, 2 Nov 2017 03:10:25 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1206013F646 for ; Thu, 2 Nov 2017 03:10:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1856; q=dns/txt; s=iport; t=1509617424; x=1510827024; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=186IBomcvphAE3ATMdqOGAY5VFcDMoFgw67Kbmsgpqo=; b=boteFSZGvTG5tkj2mbliShfBz/1LzO5IEitsdMm4tSB2jLwhK1MlBeHF rqJgbhUqu+I5B32MzMEw4G0rF4Awa33WMakhrZGs8B3/ZYpamrPg7ZGG5 Ev6i3ONL2ToOElsTPXR4gCjtZ6BOGJRSBQR6+FyKZDxSvq+ZCSU4FeEzU I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CfAAA17vpZ/5RdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzRkbicHg3aKH48agXyWRYIRChgPhRQCGoRuPxgBAQEBAQEBAQF?= =?us-ascii?q?rKIUdAQEBAQMBASEROhcEAgEGAhEEAQEBAgIjAwICAiULFAEICAEBBBMIihsQi?= =?us-ascii?q?wydZ4InixcBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYEPgh+CB4FTgWmDKoM+gTe?= =?us-ascii?q?DMYJiBaINAodkjQ2TO4xhiQgCERkBgTgBHziBbHoVSYJkhF93i1iBEQEBAQ?= X-IronPort-AV: E=Sophos;i="5.44,333,1505779200"; d="scan'208";a="25625037" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Nov 2017 10:10:23 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id vA2AAN0j006955 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 2 Nov 2017 10:10:23 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.1320.4; Thu, 2 Nov 2017 05:10:22 -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.1320.000; Thu, 2 Nov 2017 05:10:22 -0500 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] Does BIER ROLL? Thread-Index: AdNTtHg9V6EGAiYcS72JT8pNAXqUlQAMXb+AAAkno3A= Date: Thu, 2 Nov 2017 10:10:17 +0000 Deferred-Delivery: Thu, 2 Nov 2017 10:09:25 +0000 Message-ID: <0183caa64bb741efb41b0f9e4b66e587@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.210.52] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] Does BIER ROLL? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 10:10:26 -0000 Rm9yIG9uZSwgQ2lzY28gaGFzIElQUiBvbiBib3RoIEJJRVIgYW5kIG9uIHRoZSBSUEwgQklFUiBk cmFmdC4NCg0KKElBTkFMIGJ1dC4uLikgQ2lzY28ncyB0ZXJtcyBpbiB0aGUgYWJvdmUgY2FzZSBh cmUgZGVmZW5zaXZlIFJBTkQuIA0KDQpZb3UnbGwgZmluZCB0aGUgd2hvbGUgbGlzdCBvZiBJRVRG IGRlY2xhcmF0aW9ucyBvbiBCSUVSIGhlcmU6DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2lwci9zZWFyY2gvP2RyYWZ0PSZyZmM9ODIzNyZkb2N0aXRsZT1CSUVSJnN1Ym1pdD1kb2N0aXRs ZSZncm91cD0maG9sZGVyPSZpcHJ0aXRsZT0mcGF0ZW50PQ0KDQpUaGVyZSBpcyBhbHNvIElQUiBy ZWxhdGVkIHRvIFJQTCBpbiBnZW5lcmFsLCBhbmQgaW4gcGFydGljdWxhciBDaXNjbydzIElQUjoN Cmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvaXByL3NlYXJjaC8/ZHJhZnQ9JnJmYz04MjM3 JmRvY3RpdGxlPVJQTCZzdWJtaXQ9ZG9jdGl0bGUmZ3JvdXA9JmhvbGRlcj0maXBydGl0bGU9JnBh dGVudD0NCg0KTXkgZHJhZnQgaXMgYXQgdGhlIGludGVyc2VjdGlvbiBvYnZpb3VzbHk6DQpodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2lwci8zMDQ5Lw0KIA0KQXBwYXJlbnRseSB0aGUgSVBS IGhhcyBub3QgYmxvY2tlZCBJRVRGIHdvcmsgb24gUlBMIGFuZCBCSUVSLCBpbmNsdWRpbmcgb3Bl bnNvdXJjZS4NCg0KVGFrZSBjYXJlLA0KDQpQYXNjYWwNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogUm9sbCBbbWFpbHRvOnJvbGwtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIENhcnN0ZW4gQm9ybWFubg0KU2VudDogamV1ZGkgMiBub3ZlbWJyZSAyMDE3IDEwOjIy DQpUbzogUm91dGluZyBPdmVyIExvdyBwb3dlciBhbmQgTG9zc3kgbmV0d29ya3MgPHJvbGxAaWV0 Zi5vcmc+DQpTdWJqZWN0OiBSZTogW1JvbGxdIERvZXMgQklFUiBST0xMPw0KDQpPbiBOb3YgMiwg MjAxNywgYXQgMTA6MDUsIFBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkgPHB0aHViZXJ0QGNpc2Nv LmNvbT4gd3JvdGU6DQo+IA0KPiBXaGF0IGRvIG90aGVycyB0aGluaz8NCg0KSSBmb3Igb25lIHdv dWxkIGxpa2UgdG8gdW5kZXJzdGFuZCB0aGUgSVBSIGxhbmRzY2FwZSBzb21lIG1vcmUgYmVmb3Jl IHdlIGZvY3VzIG9uIHNwZWNpZmljIGJyYW5jaGVzIG9mIHRoaXMgaW50ZXJlc3RpbmcgZGVzaWdu IHRyZWUuDQoNCkdyw7zDn2UsIENhcnN0ZW4NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KUm9sbCBtYWlsaW5nIGxpc3QNClJvbGxAaWV0Zi5vcmcN Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9sbA0K From nobody Thu Nov 2 05:30:42 2017 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E645A13F45D for ; Thu, 2 Nov 2017 05:30: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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 WLpxWQm9Lu4W for ; Thu, 2 Nov 2017 05:30:40 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEFD3137A70 for ; Thu, 2 Nov 2017 05:30:39 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 5F782200DD; Thu, 2 Nov 2017 08:31:35 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id B817A82639; Thu, 2 Nov 2017 08:30:38 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Roll] Does BIER ROLL? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 12:30:41 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Pascal Thubert (pthubert) wrote: > The current position of the WG, which has a single WG doc, ccast, tha= t covers > only one combination only, seems lacking to me. Did we think that thr= ough? > I think not. I think we understood the benefits of bitmaps but did not > clearly studied the scope we wanted to cover. I think that the WG took small steps forward without excluding additional o= nes. > I=E2=80=99d like to discuss the options at the next IETF and decide w= hich WG doc(s) > we really want to cover the 3 dimensions. I agree that it's a discussion we should have. > I can see at least: > - A) 2 docs, whereby I remove compression from mine, and we keep ccas= t as is. > - B) One document with all dimensions in it > - C) 2 docs, one without Bloom compression and one that focusses on t= he Bloom > compression for all (modes*routing) including non-BIER > - D) 3 docs, the 2 above, and the 6LoRH separate. Is the 6LoRH one the compression specification from your document? > I like C) and D), because there is a lot that=E2=80=99s needed for Bl= oom, in > particular the distribution of hash functions, that is very special t= o that > technique. Also Bloom can compress anything. We could for instance ha= sh the > IPv6 address on the outgoing port that needs to forward in non-storin= g to > specify the multicast tree in non-storing mode, and hash the destinat= ion in > storing mode, since the Bloom filters are additive. > What do others think? > Pascal =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAln7D+4ACgkQgItw+93Q 3WWdBAgAldtZhVDrHYmncmofG+huz8IA2e1YqgYXVpk2QsHHIY7NA3yEUn260U5f uC8vT30rzNR99ZiOc2j7oxCqISTIsWZE3p6EMaV9O2BqBpM7PIbITgdEEWt9rWtn qMoBh2AfrKY2oAiN76DeaOa2lvdn1JBuaoKE8qNmo0PHNvCIHFJ/jr3NkerjvLXl 9t+mI3mwCioi9lKsHxIv8H/DQ+P0p+2HerHHEZsVchSetJYCXh217NIr598N/EGb ZTdn7DuWIlebcj4HvECSgSoHjbP2J8E+G48v/w2G0el9Trp/c0dLoQPVo3Xswbmh LwbQcftL8zct1u0/QnKLA77Crg79UQ== =qS5A -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Nov 2 06:05:01 2017 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E517813F65E for ; Thu, 2 Nov 2017 06:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 t2deD3CMNDEV for ; Thu, 2 Nov 2017 06:04:58 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B31B13F6B0 for ; Thu, 2 Nov 2017 06:04:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3178; q=dns/txt; s=iport; t=1509627896; x=1510837496; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=KJ2WpmxYkaCqKU/Ua+FRJ83v+fvRhS3bQeoRlCXU2cg=; b=I7QAGLpDwia3IzRwzx9I8qwT+aRrVPP48uszcohtnil0N75yzUENaqi+ gaxjzbc4FyuZlwtKYkr0aSkbDv6HoPLHHwUhl2Ab00M7vj4A5/TyebVuB i10lm5xPQuRNUh0Z1eobZLvMwzGU8mYcak5Ho51qUrS03fKo7suhdLS1K A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CdAACyFvtZ/5BdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzRkbicHg3aKH48bgXyWRYIRCiOBXoM6AhqEND8YAQEBAQEBAQE?= =?us-ascii?q?BayiFHQEBAQMBIxFKBwQCAQgRBAEBAQICIwMCAgIwFAEICAEBBBMIihMIEKhpg?= =?us-ascii?q?ieLFwEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgQ+CH4IHgVOBaYMqhHWDMYJiBZk?= =?us-ascii?q?GiQcCh2SNDZM7jGGJCAIRGQGBOAEfOIFsehWDLYJbARyBZ3eLASyBBYERAQEB?= X-IronPort-AV: E=Sophos;i="5.44,334,1505779200"; d="scan'208";a="25191338" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Nov 2017 13:04:55 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id vA2D4tZ5029646 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 2 Nov 2017 13:04:55 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 2 Nov 2017 08:04:54 -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.1320.000; Thu, 2 Nov 2017 08:04:54 -0500 From: "Pascal Thubert (pthubert)" To: Michael Richardson , "Routing Over Low power and Lossy networks" Thread-Topic: Does BIER ROLL? Thread-Index: AdNTtHg9V6EGAiYcS72JT8pNAXqUlQAS9QEAAAlpaAA= Date: Thu, 2 Nov 2017 13:04:49 +0000 Deferred-Delivery: Thu, 2 Nov 2017 13:04:11 +0000 Message-ID: <74ef64b6a878459d8a8d203838f0273e@XCH-RCD-001.cisco.com> References: <31140.1509625838@obiwan.sandelman.ca> In-Reply-To: <31140.1509625838@obiwan.sandelman.ca> 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.77.177] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] Does BIER ROLL? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 13:05:00 -0000 SGVsbG8gTWljaGFlbCANCg0KQWdyZWVkLg0KDQoNCj4gSXMgdGhlIDZMb1JIIG9uZSB0aGUgY29t cHJlc3Npb24gc3BlY2lmaWNhdGlvbiBmcm9tIHlvdXIgZG9jdW1lbnQ/DQoNCldlIGhhdmUgaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXRodWJlcnQtNmxvLWJpZXItZGlzcGF0Y2gt MDMgdGhhdCBpcyBkZXNpZ25lZCBmb3IgaXQuIFBvaW50IGlzLCBoYXZpbmcgaXQgc2VwYXJhdGUg ZW5hYmxlcyB0byBzZW5kIHRoYXQgZG9jIHRvIDZsbyBmb3IgdmFsaWRhdGlvbi4gT1RPSCwgaXQg aXMgYW4gb3RoZXIgZHJhZnQgdG8gdGFrZSB0aHJvdWdoIElFU0cuDQoNClRha2UgY2FyZSwNCg0K UGFzY2FsDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBNaWNoYWVsIFJpY2hh cmRzb24gW21haWx0bzptY3IraWV0ZkBzYW5kZWxtYW4uY2FdIA0KU2VudDogamV1ZGkgMiBub3Zl bWJyZSAyMDE3IDEzOjMxDQpUbzogUm91dGluZyBPdmVyIExvdyBwb3dlciBhbmQgTG9zc3kgbmV0 d29ya3MgPHJvbGxAaWV0Zi5vcmc+DQpDYzogUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KSA8cHRo dWJlcnRAY2lzY28uY29tPg0KU3ViamVjdDogUmU6IERvZXMgQklFUiBST0xMPw0KDQoNClBhc2Nh bCBUaHViZXJ0IChwdGh1YmVydCkgPHB0aHViZXJ0QGNpc2NvLmNvbT4gd3JvdGU6DQogICAgPiBU aGUgY3VycmVudCBwb3NpdGlvbiBvZiB0aGUgV0csIHdoaWNoIGhhcyBhIHNpbmdsZSBXRyBkb2Ms IGNjYXN0LCB0aGF0IGNvdmVycw0KICAgID4gb25seSBvbmUgY29tYmluYXRpb24gb25seSwgc2Vl bXMgbGFja2luZyB0byBtZS4gRGlkIHdlIHRoaW5rIHRoYXQgdGhyb3VnaD8NCg0KICAgID4gSSB0 aGluayBub3QuIEkgdGhpbmsgd2UgdW5kZXJzdG9vZCB0aGUgYmVuZWZpdHMgb2YgYml0bWFwcyBi dXQgZGlkIG5vdA0KICAgID4gY2xlYXJseSBzdHVkaWVkIHRoZSBzY29wZSB3ZSB3YW50ZWQgdG8g Y292ZXIuDQoNCkkgdGhpbmsgdGhhdCB0aGUgV0cgdG9vayBzbWFsbCBzdGVwcyBmb3J3YXJkIHdp dGhvdXQgZXhjbHVkaW5nIGFkZGl0aW9uYWwgb25lcy4NCg0KICAgID4gSeKAmWQgbGlrZSB0byBk aXNjdXNzIHRoZSBvcHRpb25zIGF0IHRoZSBuZXh0IElFVEYgYW5kIGRlY2lkZSB3aGljaCBXRyBk b2MocykNCiAgICA+IHdlIHJlYWxseSB3YW50IHRvIGNvdmVyIHRoZSAzIGRpbWVuc2lvbnMuDQoN CkkgYWdyZWUgdGhhdCBpdCdzIGEgZGlzY3Vzc2lvbiB3ZSBzaG91bGQgaGF2ZS4NCg0KICAgID4g SSBjYW4gc2VlIGF0IGxlYXN0Og0KDQogICAgPiAtIEEpIDIgZG9jcywgd2hlcmVieSBJIHJlbW92 ZSBjb21wcmVzc2lvbiBmcm9tIG1pbmUsIGFuZCB3ZSBrZWVwIGNjYXN0IGFzIGlzLg0KDQogICAg PiAtIEIpIE9uZSBkb2N1bWVudCB3aXRoIGFsbCBkaW1lbnNpb25zIGluIGl0DQoNCiAgICA+IC0g QykgMiBkb2NzLCBvbmUgd2l0aG91dCBCbG9vbSBjb21wcmVzc2lvbiBhbmQgb25lIHRoYXQgZm9j dXNzZXMgb24gdGhlIEJsb29tDQogICAgPiBjb21wcmVzc2lvbiBmb3IgYWxsIChtb2Rlcypyb3V0 aW5nKSBpbmNsdWRpbmcgbm9uLUJJRVINCg0KICAgID4gLSBEKSAzIGRvY3MsIHRoZSAyIGFib3Zl LCBhbmQgdGhlIDZMb1JIIHNlcGFyYXRlLg0KDQpJcyB0aGUgNkxvUkggb25lIHRoZSBjb21wcmVz c2lvbiBzcGVjaWZpY2F0aW9uIGZyb20geW91ciBkb2N1bWVudD8NCg0KICAgID4gSSBsaWtlIEMp IGFuZCBEKSwgYmVjYXVzZSB0aGVyZSBpcyBhIGxvdCB0aGF04oCZcyBuZWVkZWQgZm9yIEJsb29t LCBpbg0KICAgID4gcGFydGljdWxhciB0aGUgZGlzdHJpYnV0aW9uIG9mIGhhc2ggZnVuY3Rpb25z LCB0aGF0IGlzIHZlcnkgc3BlY2lhbCB0byB0aGF0DQogICAgPiB0ZWNobmlxdWUuIEFsc28gQmxv b20gY2FuIGNvbXByZXNzIGFueXRoaW5nLiBXZSBjb3VsZCBmb3IgaW5zdGFuY2UgaGFzaCB0aGUN CiAgICA+IElQdjYgYWRkcmVzcyBvbiB0aGUgb3V0Z29pbmcgcG9ydCB0aGF0IG5lZWRzIHRvIGZv cndhcmQgaW4gbm9uLXN0b3JpbmcgdG8NCiAgICA+IHNwZWNpZnkgdGhlIG11bHRpY2FzdCB0cmVl IGluIG5vbi1zdG9yaW5nIG1vZGUsIGFuZCBoYXNoIHRoZSBkZXN0aW5hdGlvbiBpbg0KICAgID4g c3RvcmluZyBtb2RlLCBzaW5jZSB0aGUgQmxvb20gZmlsdGVycyBhcmUgYWRkaXRpdmUuDQoNCiAg ICA+IFdoYXQgZG8gb3RoZXJzIHRoaW5rPw0KDQogICAgPiBQYXNjYWwNCg0KDQoNCi0tDQpNaWNo YWVsIFJpY2hhcmRzb24gPG1jcitJRVRGQHNhbmRlbG1hbi5jYT4sIFNhbmRlbG1hbiBTb2Z0d2Fy ZSBXb3JrcyAgLT0gSVB2NiBJb1QgY29uc3VsdGluZyA9LQ0KDQoNCg0K From nobody Fri Nov 3 00:10:23 2017 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D545D13FCA7 for ; Fri, 3 Nov 2017 00:10:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 3De3ch0ZMDXL for ; Fri, 3 Nov 2017 00:10:12 -0700 (PDT) Received: from lb1-smtp-cloud9.xs4all.net (lb1-smtp-cloud9.xs4all.net [194.109.24.22]) (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 2A4BA13FB28 for ; Fri, 3 Nov 2017 00:10:11 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:195]) by smtp-cloud9.xs4all.net with ESMTPA id AW7FeZOVMnIXbAW7FeIx2C; Fri, 03 Nov 2017 08:10:10 +0100 Received: from AReims-651-1-28-87.w92-131.abo.wanadoo.fr ([92.131.227.87]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Fri, 03 Nov 2017 08:10:09 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Fri, 03 Nov 2017 08:10:09 +0100 From: peter van der Stok To: Routing Over Low power and Lossy networks Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <0183caa64bb741efb41b0f9e4b66e587@XCH-RCD-001.cisco.com> References: <0183caa64bb741efb41b0f9e4b66e587@XCH-RCD-001.cisco.com> Message-ID: X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfA3Jb0DV001RVbR/RmQ4m6N/WInmwvzY4SSz2R6gbfZY8vLnnAn98KKhFvHeKjwVVCLNKCmAYNP2JEOGp3MuKQSp9WabQRUvpTMWNuLoVB3BGacROueo GZ22GqmZdtyqJPiUWVzmxXxShRqHA+teUZValjelLjByZdPmJIykSCP020Ky90N1BqRV2kTvju7N7tf+PfdazzX3hA6J2Z6EnDXNEKTQ3/DaSZcgwAzaveSu U8INyA2/llLhK/9OxlatUA== Archived-At: Subject: Re: [Roll] Does BIER ROLL? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 07:10:21 -0000 I surely wanted to discuss this topic during the 15 mins reserved for new topics and relations. Personally, (no hat) I think the subject is important when RPL networks grow. Peter Pascal Thubert (pthubert) schreef op 2017-11-02 11:10: > For one, Cisco has IPR on both BIER and on the RPL BIER draft. > > (IANAL but...) Cisco's terms in the above case are defensive RAND. > > You'll find the whole list of IETF declarations on BIER here: > https://datatracker.ietf.org/ipr/search/?draft=&rfc=8237&doctitle=BIER&submit=doctitle&group=&holder=&iprtitle=&patent= > > There is also IPR related to RPL in general, and in particular Cisco's > IPR: > https://datatracker.ietf.org/ipr/search/?draft=&rfc=8237&doctitle=RPL&submit=doctitle&group=&holder=&iprtitle=&patent= > > My draft is at the intersection obviously: > https://datatracker.ietf.org/ipr/3049/ > > Apparently the IPR has not blocked IETF work on RPL and BIER, > including opensource. > > Take care, > > Pascal > > > -----Original Message----- > From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Carsten Bormann > Sent: jeudi 2 novembre 2017 10:22 > To: Routing Over Low power and Lossy networks > Subject: Re: [Roll] Does BIER ROLL? > > On Nov 2, 2017, at 10:05, Pascal Thubert (pthubert) > wrote: >> >> What do others think? > > I for one would like to understand the IPR landscape some more before > we focus on specific branches of this interesting design tree. > > Grüße, Carsten > > > _______________________________________________ > 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 Fri Nov 3 10:21:52 2017 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52DB513FF02 for ; Fri, 3 Nov 2017 10:21:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=imt-atlantique.net 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 fKsNlLKST3Nb for ; Fri, 3 Nov 2017 10:21:47 -0700 (PDT) Received: from zproxy130.enst.fr (zproxy130.enst.fr [IPv6:2001:660:330f:2::c2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0059D13FF01 for ; Fri, 3 Nov 2017 10:21:46 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by zproxy130.enst.fr (Postfix) with ESMTP id 3EE37120694; Fri, 3 Nov 2017 18:21:45 +0100 (CET) Received: from zproxy130.enst.fr ([IPv6:::1]) by localhost (zproxy130.enst.fr [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id 03QuzjqF8q7l; Fri, 3 Nov 2017 18:21:43 +0100 (CET) Received: from localhost (localhost [IPv6:::1]) by zproxy130.enst.fr (Postfix) with ESMTP id 9F0F5120A94; Fri, 3 Nov 2017 18:21:43 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.10.3 zproxy130.enst.fr 9F0F5120A94 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=imt-atlantique.net; s=6A0CDB44-C782-11E6-82EC-91BDBA474D24; t=1509729703; bh=eIKlxb0sqVp4fJDP0Htagse2ssqyXi26t0AyDlqXoCg=; h=Date:From:To:Message-ID:MIME-Version; b=fPjNvzGcYQ9NRERQG9dJIJGkdfFPkZxv/mUKIuNs3E+TmEpfa1pv3FH1J93K205ov CshPbkRT+sl9b2cXVwpy5trny3AjHIlpuWlOahH5xNLwNSMbl+k4cBB33X6xsFp5EA wTFwXmvYPeyJl8BMLSJwGKvjW0u5ZL1uvi+sBfu8= X-Virus-Scanned: amavisd-new at zproxy130.enst.fr Received: from zproxy130.enst.fr ([IPv6:::1]) by localhost (zproxy130.enst.fr [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id CPcPnpEBT6Ib; Fri, 3 Nov 2017 18:21:43 +0100 (CET) Received: from zmail131.enst.fr (zmail131.enst.fr [137.194.2.203]) by zproxy130.enst.fr (Postfix) with ESMTP id 7F208120694; Fri, 3 Nov 2017 18:21:43 +0100 (CET) Date: Fri, 3 Nov 2017 18:21:43 +0100 (CET) From: Chenyang JI To: "Houjianqiang (Derek)" , roll Message-ID: <544130816.4872551.1509729703443.JavaMail.zimbra@imt-atlantique.net> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [2001:660:7301:51:c126:3f76:249e:b974] X-Mailer: Zimbra 8.7.11_GA_1854 (ZimbraWebClient - FF56 (Linux)/8.7.11_GA_1854) Thread-Topic: Child count in parent selection Thread-Index: AdNR5qGs8C64+4nvRem9wuaViXd9zYyJQ2td Archived-At: Subject: Re: [Roll] Child count in parent selection X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 17:21:50 -0000 Hello, Thank you for the answer and I apologize for my late response. Today I realized that you had a new version of draft draft-qasem-roll-rpl-load-balancing-02 and I also have some questions on this. The description about LB-OF is: In LB-OF algorithm, the received DIO from the child node is counted by the preferred parent node. Each DIO contains the IP address of the chosen preferred parent as detailed in section 4.3. Thus,for each received DIO, the node matches its own IP address with the preferred parent IP address which is inserted in the DIO message, thenincrements the number of children by ONE for this node if there is a matching. And the format of DIO metric container object is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags |P| CNC | CNC_MAX | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + | | + Parent Address + | | + +-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ which Parent Address field is optional and is set if 'p'flag is set. Also,it says that: Thus, to minimize traffic load, the Parent Address field in the CNC object should not be present in the storing mode. That means the 'p'flag is set for every DIO message sent in Non-storing mode? Thank you, Chenyang ji https://www.ietf.org/id/draft-qasem-roll-rpl-load-balancing-02.txt ----- Original Message ----- From: "Houjianqiang (Derek)" To: "chenyang ji" Cc: "roll" , "jichenyang920" , "Qasem, Mamoun" Sent: Tuesday, October 31, 2017 2:42:19 AM Subject: Re: [Roll] Child count in parent selection Hi Chenyang Many thanks for your interest in our draft. I am happy to answer your questions. Please see my response in line. Best regards, Jianqiang Hou (Derek) Date: Mon, 30 Oct 2017 08:40:02 +0100 (CET) From: Chenyang JI > To: roll@ietf.org Cc: jichenyang920 > Subject: [Roll] Child count in parent selection Message-ID: <961578433.3782382.1509349202587.JavaMail.zimbra@imt-atlantique.net> Content-Type: text/plain; charset=utf-8 Hello, I have some questions about draft-hou-roll-rpl-parent-selection-00 and draft-qasem-roll-rpl-load-balancing-01. In the draft,it describes a new type of metric which has this format: CNC: 8 bits. The Child Node Count is encoded in 8 bits in unsigned integer format, expressed in number count, representing the number of child nodes. MAX_CNC: 8 bits. The Maximum Child Node Count is encoded in 8 bits in unsigned integer format, expressed in number count, representing the maximum number of child nodes allowed in the neighbor cache. but it does not clarify if this number of child nodes refers to the number of direct child or the subtree size. [Jianqiang] My mistake... This number of child nodes refers to the number of direct child. In draft-qasem-roll-rpl-load-balancing-01: In LB-OF algorithm, the received DIO from the child node is counted by the preferred parent node. Each DIO contains the IP address of the chosen preferred parent as detailed in section 4.3. Thus, for each received DIO, the node matches its own IP address with the preferred parent IP address which is inserted in the DIO message, then increments the number of children by ONE for this node if there is a matching. My question is if that mean it will store the children's address and if yes,how will the node stores its children. [Jianqiang] There are two possible ways of storing its children. One is to store the children's address in a new table with extra cache, the other way is to manage the neighbor cache entry (after all the direct children set is a subset of the neighbor set). The first draft https://tools.ietf.org/html/draft-hou-roll-rpl-parent-selection-00 The second draft https://datatracker.ietf.org/doc/html/draft-qasem-roll-rpl-load-balancing Best regards, Chenyang Ji From nobody Mon Nov 6 00:50:50 2017 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACD5913FB1B for ; Mon, 6 Nov 2017 00:50:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 R9NIydS82B_s for ; Mon, 6 Nov 2017 00:50:48 -0800 (PST) Received: from lb1-smtp-cloud9.xs4all.net (lb1-smtp-cloud9.xs4all.net [194.109.24.22]) (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 CDD2913F963 for ; Mon, 6 Nov 2017 00:50:47 -0800 (PST) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:200]) by smtp-cloud9.xs4all.net with ESMTPA id Bd7GexjVbnIXbBd7GeSgkk; Mon, 06 Nov 2017 09:50:46 +0100 Received: from 83-161-167-237.mobile.xs4all.nl ([83.161.167.237]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 06 Nov 2017 09:50:45 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Mon, 06 Nov 2017 09:50:45 +0100 From: peter van der Stok To: Routing Over Low power and Lossy networks Cc: Michael Richardson Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <31140.1509625838@obiwan.sandelman.ca> References: <31140.1509625838@obiwan.sandelman.ca> Message-ID: <02014133b5949ee3433847fe56ef0f05@xs4all.nl> X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfHY5avFkHSZM/TOZ2OdglsRpjcE8vNhWHwn4WCSSfLRbAutRoslO1KmBDxdtAZbS2hPdFYxIEybn2r2EiUlU10xxlEKVm8q/joiz3vxvYBTySsOA2xNt 9GVgVEs+SCKSjxOsqIpA8rSK91v4dGHmTo1dp/6p62K2goMdt0Z3ib1uNShc34ApkC9adJN5QIBp4j33eJvULTcgayQ7Wo8vEu+dQGaGKKFszxP4Yjbg2Ewc SYlkg4VVX03rrJ+eDI5Q7Q== Archived-At: Subject: Re: [Roll] Does BIER ROLL? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Nov 2017 08:50:50 -0000 Hi Pascal, Carsten, and Michael, I agree that we should have this discussion. But the discussion will take some time and I think that the ietf100 slot will be much too short to handle all proposed topics. I should like to have a short discussion that confirms the work is necessary, and determines the people to work on it. Probably, a composing a design group would be best (IMO). Peter Michael Richardson schreef op 2017-11-02 13:30: > Pascal Thubert (pthubert) wrote: > > The current position of the WG, which has a single WG doc, > ccast, that covers > > only one combination only, seems lacking to me. Did we think that > through? > > > I think not. I think we understood the benefits of bitmaps but > did not > > clearly studied the scope we wanted to cover. > > I think that the WG took small steps forward without excluding > additional ones. > > > I’d like to discuss the options at the next IETF and decide > which WG doc(s) > > we really want to cover the 3 dimensions. > > I agree that it's a discussion we should have. > > > I can see at least: > > > - A) 2 docs, whereby I remove compression from mine, and we keep > ccast as is. > > > - B) One document with all dimensions in it > > > - C) 2 docs, one without Bloom compression and one that focusses > on the Bloom > > compression for all (modes*routing) including non-BIER > > > - D) 3 docs, the 2 above, and the 6LoRH separate. > > Is the 6LoRH one the compression specification from your document? > > > I like C) and D), because there is a lot that’s needed for Bloom, > in > > particular the distribution of hash functions, that is very > special to that > > technique. Also Bloom can compress anything. We could for > instance hash the > > IPv6 address on the outgoing port that needs to forward in > non-storing to > > specify the multicast tree in non-storing mode, and hash the > destination in > > storing mode, since the Bloom filters are additive. > > > What do others think? > > > Pascal > > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Mon Nov 6 01:31:03 2017 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A5F113FAE5 for ; Mon, 6 Nov 2017 01:31:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 pwfuIY_VCl6V for ; Mon, 6 Nov 2017 01:31:00 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E782A13F963 for ; Mon, 6 Nov 2017 01:30:58 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DSC03912; Mon, 06 Nov 2017 09:30:56 +0000 (GMT) Received: from DGGEMM402-HUB.china.huawei.com (10.3.20.210) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.361.1; Mon, 6 Nov 2017 09:30:00 +0000 Received: from DGGEMM506-MBS.china.huawei.com ([169.254.4.18]) by DGGEMM402-HUB.china.huawei.com ([10.3.20.210]) with mapi id 14.03.0361.001; Mon, 6 Nov 2017 17:29:35 +0800 From: "Houjianqiang (Derek)" To: Chenyang JI , roll Thread-Topic: [Roll] Child count in parent selection Thread-Index: AQHTVMhD4PR5R6hXSke6aZFwTvCsNqMHBNlQ Date: Mon, 6 Nov 2017 09:29:35 +0000 Message-ID: References: <544130816.4872551.1509729703443.JavaMail.zimbra@imt-atlantique.net> In-Reply-To: <544130816.4872551.1509729703443.JavaMail.zimbra@imt-atlantique.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.134.134.224] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.5A002BD1.0019, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.18, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 639e88c998d46ae724895f6dd937afe6 Archived-At: Subject: Re: [Roll] Child count in parent selection X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Nov 2017 09:31:02 -0000 SGkgQ2hlbnlhbmcsDQoNClllcywgd2Ugd2FudCB0aGUgJ1AnIGZsYWcgb2YgdGhlIENOQyBtZXRy aWMgdG8gYmUgc2V0IGluIGV2ZXJ5IERJTyBpbiBub24tc3RvcmluZyBtb2RlLg0KDQpJbiBzdG9y aW5nIG1vZGUsIERBTy9OUC1EQU8gY2FuIGJlIHVzZWQgZm9yIGNoaWxkIHJlZ2lzdHJhdGlvbiBh bmQgZGUtcmVnaXN0cmF0aW9uLCB0aHVzIHRoZXJlIGlzIG5vIG5lZWQgb2YgYSBwYXJlbnQgYWRk cmVzcyBpbiBESU8uIEJ1dCBpbiBub24tc3RvcmluZyBtb2RlLCBEQU8gY2Fubm90IGJlIHVzZWQg Zm9yIGNvdW50aW5nIHRoZSBudW1iZXIgb2YgY2hpbGRyZW4sIHNvIHdlIHVzZSBESU8oKyBwYXJl bnQgYWRkcmVzcykgaW5zdGVhZC4NCg0KUmVnYXJkcywNCkppYW5xaWFuZyBIb3UgKERlcmVrKSAN Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IENoZW55YW5nIEpJIFttYWlsdG86 Y2hlbnlhbmcuamlAaW10LWF0bGFudGlxdWUubmV0XSANClNlbnQ6IFNhdHVyZGF5LCBOb3ZlbWJl ciAwNCwgMjAxNyAxOjIyIEFNDQpUbzogSG91amlhbnFpYW5nIChEZXJlaykgPGhvdWppYW5xaWFu Z0BodWF3ZWkuY29tPjsgcm9sbCA8cm9sbEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbUm9sbF0g Q2hpbGQgY291bnQgaW4gcGFyZW50IHNlbGVjdGlvbg0KDQpIZWxsbywNCg0KVGhhbmsgeW91IGZv ciB0aGUgYW5zd2VyIGFuZCBJIGFwb2xvZ2l6ZSBmb3IgbXkgbGF0ZSByZXNwb25zZS4NClRvZGF5 IEkgcmVhbGl6ZWQgdGhhdCB5b3UgaGFkIGEgbmV3IHZlcnNpb24gb2YgZHJhZnQgZHJhZnQtcWFz ZW0tcm9sbC1ycGwtbG9hZC1iYWxhbmNpbmctMDIgYW5kIEkgYWxzbyBoYXZlIHNvbWUgcXVlc3Rp b25zIG9uIHRoaXMuDQpUaGUgZGVzY3JpcHRpb24gYWJvdXQgTEItT0YgaXM6DQoNCiBJbiBMQi1P RiBhbGdvcml0aG0sIHRoZSByZWNlaXZlZCBESU8gZnJvbSB0aGUgY2hpbGQgbm9kZSBpcyBjb3Vu dGVkIGJ5IHRoZSBwcmVmZXJyZWQgcGFyZW50IG5vZGUuIEVhY2ggRElPIGNvbnRhaW5zIHRoZSBJ UCAgYWRkcmVzcyBvZiB0aGUgY2hvc2VuIHByZWZlcnJlZCBwYXJlbnQgYXMgZGV0YWlsZWQgaW4g c2VjdGlvbiA0LjMuIFRodXMsZm9yIGVhY2ggcmVjZWl2ZWQgRElPLCB0aGUgbm9kZSBtYXRjaGVz IGl0cyBvd24gSVAgIGFkZHJlc3Mgd2l0aCB0aGUgcHJlZmVycmVkIHBhcmVudCBJUCBhZGRyZXNz IHdoaWNoIGlzIGluc2VydGVkIGluIHRoZSBESU8gbWVzc2FnZSwgdGhlbmluY3JlbWVudHMgdGhl IG51bWJlciBvZiBjaGlsZHJlbiBieSAgT05FIGZvciB0aGlzIG5vZGUgaWYgdGhlcmUgaXMgYSBt YXRjaGluZy4NCg0KQW5kIHRoZSBmb3JtYXQgb2YgRElPIG1ldHJpYyBjb250YWluZXIgb2JqZWN0 IGlzOg0KDQogICAgICAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAy ICAgICAgICAgICAgICAgICAgIDMNCiAgICAgICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAz IDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxDQogICAgICAgKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAg ICAgICB8ICAgRmxhZ3MgICAgIHxQfCAgICAgQ05DICAgICAgIHwgICAgQ05DX01BWCAgICB8ICAg ICAgICAgICAgICAgfA0KICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSsgICAgICAgICAgICAgICArDQogICAgICAgfCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAr ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgKw0KICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgICAgKyAgICAgICAgICAgICAgICAgICAgICAg IFBhcmVudCBBZGRyZXNzICAgICAgICAgICAgICAgICAgICAgICAgICsNCiAgICAgICB8ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg fA0KICAgICAgICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICstKy0rLSstKy0rLSstKy0rDQogICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfA0KICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSsNCg0Kd2hpY2ggUGFyZW50IEFkZHJlc3MgZmllbGQgaXMgb3B0 aW9uYWwgYW5kIGlzIHNldCBpZiAncCdmbGFnIGlzIHNldC4NCkFsc28saXQgc2F5cyB0aGF0Og0K DQpUaHVzLCB0byBtaW5pbWl6ZSB0cmFmZmljIGxvYWQsIHRoZSBQYXJlbnQgQWRkcmVzcyBmaWVs ZCBpbiB0aGUgQ05DIG9iamVjdCBzaG91bGQgbm90IGJlIHByZXNlbnQgaW4gdGhlIHN0b3Jpbmcg bW9kZS4NCg0KVGhhdCBtZWFucyB0aGUgJ3AnZmxhZyBpcyBzZXQgZm9yIGV2ZXJ5IERJTyBtZXNz YWdlIHNlbnQgaW4gTm9uLXN0b3JpbmcgbW9kZT8NCg0KVGhhbmsgeW91LA0KQ2hlbnlhbmcgamkN Cg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtcWFzZW0tcm9sbC1ycGwtbG9hZC1iYWxh bmNpbmctMDIudHh0DQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCkZyb206ICJIb3Vq aWFucWlhbmcgKERlcmVrKSIgPGhvdWppYW5xaWFuZ0BodWF3ZWkuY29tPg0KVG86ICJjaGVueWFu ZyBqaSIgPGNoZW55YW5nLmppQGltdC1hdGxhbnRpcXVlLm5ldD4NCkNjOiAicm9sbCIgPHJvbGxA aWV0Zi5vcmc+LCAiamljaGVueWFuZzkyMCIgPGppY2hlbnlhbmc5MjBAZ21haWwuY29tPiwgIlFh c2VtLCBNYW1vdW4iIDxNLlFhc2VtQG5hcGllci5hYy51az4NClNlbnQ6IFR1ZXNkYXksIE9jdG9i ZXIgMzEsIDIwMTcgMjo0MjoxOSBBTQ0KU3ViamVjdDogUmU6IFtSb2xsXSBDaGlsZCBjb3VudCBp biBwYXJlbnQgc2VsZWN0aW9uDQoNCkhpIENoZW55YW5nDQoNCg0KDQpNYW55IHRoYW5rcyBmb3Ig eW91ciBpbnRlcmVzdCBpbiBvdXIgZHJhZnQuIEkgYW0gaGFwcHkgdG8gYW5zd2VyIHlvdXIgcXVl c3Rpb25zLiBQbGVhc2Ugc2VlIG15IHJlc3BvbnNlIGluIGxpbmUuDQoNCg0KDQpCZXN0IHJlZ2Fy ZHMsDQoNCkppYW5xaWFuZyBIb3UgKERlcmVrKQ0KDQoNCg0KRGF0ZTogTW9uLCAzMCBPY3QgMjAx NyAwODo0MDowMiArMDEwMCAoQ0VUKQ0KDQpGcm9tOiBDaGVueWFuZyBKSSA8Y2hlbnlhbmcuamlA aW10LWF0bGFudGlxdWUubmV0PG1haWx0bzpjaGVueWFuZy5qaUBpbXQtYXRsYW50aXF1ZS5uZXQ+ Pg0KDQpUbzogcm9sbEBpZXRmLm9yZzxtYWlsdG86cm9sbEBpZXRmLm9yZz4NCg0KQ2M6IGppY2hl bnlhbmc5MjAgPGppY2hlbnlhbmc5MjBAZ21haWwuY29tPG1haWx0bzpqaWNoZW55YW5nOTIwQGdt YWlsLmNvbT4+DQoNClN1YmplY3Q6IFtSb2xsXSBDaGlsZCBjb3VudCBpbiBwYXJlbnQgc2VsZWN0 aW9uDQoNCk1lc3NhZ2UtSUQ6DQoNCiAgICAgICAgICAgICAgICA8OTYxNTc4NDMzLjM3ODIzODIu MTUwOTM0OTIwMjU4Ny5KYXZhTWFpbC56aW1icmFAaW10LWF0bGFudGlxdWUubmV0PG1haWx0bzo5 NjE1Nzg0MzMuMzc4MjM4Mi4xNTA5MzQ5MjAyNTg3LkphdmFNYWlsLnppbWJyYUBpbXQtYXRsYW50 aXF1ZS5uZXQ+Pg0KDQpDb250ZW50LVR5cGU6IHRleHQvcGxhaW47IGNoYXJzZXQ9dXRmLTgNCg0K DQoNCkhlbGxvLA0KDQoNCg0KSSBoYXZlIHNvbWUgcXVlc3Rpb25zIGFib3V0IGRyYWZ0LWhvdS1y b2xsLXJwbC1wYXJlbnQtc2VsZWN0aW9uLTAwIGFuZCBkcmFmdC1xYXNlbS1yb2xsLXJwbC1sb2Fk LWJhbGFuY2luZy0wMS4NCg0KSW4gdGhlIGRyYWZ0LGl0IGRlc2NyaWJlcyBhIG5ldyB0eXBlIG9m IG1ldHJpYyB3aGljaCBoYXMgdGhpcyBmb3JtYXQ6DQoNCg0KDQpDTkM6IDggYml0cy4gVGhlIENo aWxkIE5vZGUgQ291bnQgaXMgZW5jb2RlZCBpbiA4IGJpdHMgaW4gdW5zaWduZWQgaW50ZWdlciBm b3JtYXQsIGV4cHJlc3NlZCBpbiBudW1iZXIgY291bnQsIHJlcHJlc2VudGluZyB0aGUgbnVtYmVy IG9mIGNoaWxkIG5vZGVzLg0KDQoNCg0KTUFYX0NOQzogOCBiaXRzLiBUaGUgTWF4aW11bSBDaGls ZCBOb2RlIENvdW50IGlzIGVuY29kZWQgaW4gOCBiaXRzIGluIHVuc2lnbmVkIGludGVnZXIgZm9y bWF0LCBleHByZXNzZWQgaW4gbnVtYmVyIGNvdW50LCByZXByZXNlbnRpbmcgdGhlIG1heGltdW0g bnVtYmVyIG9mIGNoaWxkIG5vZGVzIGFsbG93ZWQgaW4gdGhlIG5laWdoYm9yIGNhY2hlLg0KDQoN Cg0KYnV0IGl0IGRvZXMgbm90IGNsYXJpZnkgaWYgdGhpcyBudW1iZXIgb2YgY2hpbGQgbm9kZXMg cmVmZXJzIHRvIHRoZSBudW1iZXIgb2YgZGlyZWN0IGNoaWxkIG9yIHRoZSBzdWJ0cmVlIHNpemUu DQoNCltKaWFucWlhbmddIE15IG1pc3Rha2UuLi4gVGhpcyBudW1iZXIgb2YgY2hpbGQgbm9kZXMg cmVmZXJzIHRvIHRoZSBudW1iZXIgb2YgZGlyZWN0IGNoaWxkLg0KDQoNCg0KSW4gZHJhZnQtcWFz ZW0tcm9sbC1ycGwtbG9hZC1iYWxhbmNpbmctMDE6DQoNCg0KDQpJbiBMQi1PRiBhbGdvcml0aG0s IHRoZSByZWNlaXZlZCBESU8gZnJvbSB0aGUgY2hpbGQgbm9kZSBpcyBjb3VudGVkIGJ5IHRoZSBw cmVmZXJyZWQgcGFyZW50IG5vZGUuIEVhY2ggRElPIGNvbnRhaW5zIHRoZSBJUCBhZGRyZXNzIG9m IHRoZSBjaG9zZW4gcHJlZmVycmVkIHBhcmVudCBhcyBkZXRhaWxlZCBpbiBzZWN0aW9uIDQuMy4g VGh1cywgZm9yIGVhY2ggcmVjZWl2ZWQgRElPLCB0aGUgbm9kZSBtYXRjaGVzIGl0cyBvd24gSVAg YWRkcmVzcyB3aXRoIHRoZSBwcmVmZXJyZWQgcGFyZW50IElQIGFkZHJlc3Mgd2hpY2ggaXMgaW5z ZXJ0ZWQgaW4gdGhlIERJTyBtZXNzYWdlLCB0aGVuIGluY3JlbWVudHMgdGhlIG51bWJlciBvZiBj aGlsZHJlbiBieSBPTkUgZm9yIHRoaXMgbm9kZSBpZiB0aGVyZSBpcyBhIG1hdGNoaW5nLg0KDQoN Cg0KTXkgcXVlc3Rpb24gaXMgaWYgdGhhdCBtZWFuIGl0IHdpbGwgc3RvcmUgdGhlIGNoaWxkcmVu J3MgYWRkcmVzcyBhbmQgaWYgeWVzLGhvdyB3aWxsIHRoZSBub2RlIHN0b3JlcyBpdHMgY2hpbGRy ZW4uDQoNCltKaWFucWlhbmddIFRoZXJlIGFyZSB0d28gcG9zc2libGUgd2F5cyBvZiBzdG9yaW5n IGl0cyBjaGlsZHJlbi4gT25lIGlzIHRvIHN0b3JlIHRoZSBjaGlsZHJlbidzIGFkZHJlc3MgaW4g YSBuZXcgdGFibGUgd2l0aCBleHRyYSBjYWNoZSwgdGhlIG90aGVyIHdheSBpcyB0byBtYW5hZ2Ug dGhlIG5laWdoYm9yIGNhY2hlIGVudHJ5IChhZnRlciBhbGwgdGhlIGRpcmVjdCBjaGlsZHJlbiBz ZXQgaXMgYSBzdWJzZXQgb2YgdGhlIG5laWdoYm9yIHNldCkuDQoNCg0KDQpUaGUgZmlyc3QgZHJh ZnQNCg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWhvdS1yb2xsLXJwbC1wYXJl bnQtc2VsZWN0aW9uLTAwDQoNCg0KDQpUaGUgc2Vjb25kIGRyYWZ0DQoNCmh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtcWFzZW0tcm9sbC1ycGwtbG9hZC1iYWxhbmNp bmcNCg0KDQoNCkJlc3QgcmVnYXJkcywNCg0KQ2hlbnlhbmcgSmkNCg== From nobody Mon Nov 6 01:50:52 2017 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2916E13FC13 for ; Mon, 6 Nov 2017 01:50:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=imt-atlantique.net 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 nW99Qa7C2A7C for ; Mon, 6 Nov 2017 01:50:48 -0800 (PST) Received: from zproxy110.enst.fr (zproxy110.enst.fr [IPv6:2001:660:330f:2::c0]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 197DB13FB8C for ; Mon, 6 Nov 2017 01:50:47 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by zproxy110.enst.fr (Postfix) with ESMTP id 82C43808A3; Mon, 6 Nov 2017 10:50:45 +0100 (CET) Received: from zproxy110.enst.fr ([IPv6:::1]) by localhost (zproxy110.enst.fr [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id 1lb1ezRdDM5c; Mon, 6 Nov 2017 10:50:43 +0100 (CET) Received: from localhost (localhost [IPv6:::1]) by zproxy110.enst.fr (Postfix) with ESMTP id DAD67808C8; Mon, 6 Nov 2017 10:50:43 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.10.3 zproxy110.enst.fr DAD67808C8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=imt-atlantique.net; s=6A0CDB44-C782-11E6-82EC-91BDBA474D24; t=1509961843; bh=FtDr+MVNeaElq5jOZB330lv2pXpJe7KPjfQo7Lh8Hvs=; h=Date:From:To:Message-ID:MIME-Version; b=g0EiPLn6TBMkSjIp7uF6Aose+NugVIt42MRTGTnX1w0/5gSAuCp3brTuWFpmRQzTM lsXFZghZpwLhUAcXfXFOAwiRLMNYvTryhlPoPgmZV5PpvW8jSyyIu44kYpkruZtfIS 2kqdwNdg/MAsACPsIcVVqstf8C9gpGSpCjX68y9Y= X-Virus-Scanned: amavisd-new at zproxy110.enst.fr Received: from zproxy110.enst.fr ([IPv6:::1]) by localhost (zproxy110.enst.fr [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id I6lhXeIX3L6v; Mon, 6 Nov 2017 10:50:43 +0100 (CET) Received: from zmail131.enst.fr (zmail131.enst.fr [137.194.2.203]) by zproxy110.enst.fr (Postfix) with ESMTP id B7739806D5; Mon, 6 Nov 2017 10:50:43 +0100 (CET) Date: Mon, 6 Nov 2017 10:50:43 +0100 (CET) From: Chenyang JI To: Houjianqiang Cc: roll Message-ID: <272885943.5182366.1509961843464.JavaMail.zimbra@imt-atlantique.net> In-Reply-To: References: <544130816.4872551.1509729703443.JavaMail.zimbra@imt-atlantique.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [2001:660:7301:51:c126:3f76:249e:b974] X-Mailer: Zimbra 8.7.11_GA_1854 (ZimbraWebClient - FF56 (Linux)/8.7.11_GA_1854) Thread-Topic: Child count in parent selection Thread-Index: AQHTVMhD4PR5R6hXSke6aZFwTvCsNqMHBNlQDhNm1yE= Archived-At: Subject: Re: [Roll] Child count in parent selection X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Nov 2017 09:50:51 -0000 Hello, Thank you for the answer. Best regards, Chenyang Ji ----- Original Message ----- From: "Houjianqiang" To: "Chenyang JI" , "roll" Sent: Monday, November 6, 2017 10:29:35 AM Subject: RE: [Roll] Child count in parent selection Hi Chenyang, Yes, we want the 'P' flag of the CNC metric to be set in every DIO in non-storing mode. In storing mode, DAO/NP-DAO can be used for child registration and de-registration, thus there is no need of a parent address in DIO. But in non-storing mode, DAO cannot be used for counting the number of children, so we use DIO(+ parent address) instead. Regards, Jianqiang Hou (Derek) -----Original Message----- From: Chenyang JI [mailto:chenyang.ji@imt-atlantique.net] Sent: Saturday, November 04, 2017 1:22 AM To: Houjianqiang (Derek) ; roll Subject: Re: [Roll] Child count in parent selection Hello, Thank you for the answer and I apologize for my late response. Today I realized that you had a new version of draft draft-qasem-roll-rpl-load-balancing-02 and I also have some questions on this. The description about LB-OF is: In LB-OF algorithm, the received DIO from the child node is counted by the preferred parent node. Each DIO contains the IP address of the chosen preferred parent as detailed in section 4.3. Thus,for each received DIO, the node matches its own IP address with the preferred parent IP address which is inserted in the DIO message, thenincrements the number of children by ONE for this node if there is a matching. And the format of DIO metric container object is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags |P| CNC | CNC_MAX | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + | | + Parent Address + | | + +-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ which Parent Address field is optional and is set if 'p'flag is set. Also,it says that: Thus, to minimize traffic load, the Parent Address field in the CNC object should not be present in the storing mode. That means the 'p'flag is set for every DIO message sent in Non-storing mode? Thank you, Chenyang ji https://www.ietf.org/id/draft-qasem-roll-rpl-load-balancing-02.txt ----- Original Message ----- From: "Houjianqiang (Derek)" To: "chenyang ji" Cc: "roll" , "jichenyang920" , "Qasem, Mamoun" Sent: Tuesday, October 31, 2017 2:42:19 AM Subject: Re: [Roll] Child count in parent selection Hi Chenyang Many thanks for your interest in our draft. I am happy to answer your questions. Please see my response in line. Best regards, Jianqiang Hou (Derek) Date: Mon, 30 Oct 2017 08:40:02 +0100 (CET) From: Chenyang JI > To: roll@ietf.org Cc: jichenyang920 > Subject: [Roll] Child count in parent selection Message-ID: <961578433.3782382.1509349202587.JavaMail.zimbra@imt-atlantique.net> Content-Type: text/plain; charset=utf-8 Hello, I have some questions about draft-hou-roll-rpl-parent-selection-00 and draft-qasem-roll-rpl-load-balancing-01. In the draft,it describes a new type of metric which has this format: CNC: 8 bits. The Child Node Count is encoded in 8 bits in unsigned integer format, expressed in number count, representing the number of child nodes. MAX_CNC: 8 bits. The Maximum Child Node Count is encoded in 8 bits in unsigned integer format, expressed in number count, representing the maximum number of child nodes allowed in the neighbor cache. but it does not clarify if this number of child nodes refers to the number of direct child or the subtree size. [Jianqiang] My mistake... This number of child nodes refers to the number of direct child. In draft-qasem-roll-rpl-load-balancing-01: In LB-OF algorithm, the received DIO from the child node is counted by the preferred parent node. Each DIO contains the IP address of the chosen preferred parent as detailed in section 4.3. Thus, for each received DIO, the node matches its own IP address with the preferred parent IP address which is inserted in the DIO message, then increments the number of children by ONE for this node if there is a matching. My question is if that mean it will store the children's address and if yes,how will the node stores its children. [Jianqiang] There are two possible ways of storing its children. One is to store the children's address in a new table with extra cache, the other way is to manage the neighbor cache entry (after all the direct children set is a subset of the neighbor set). The first draft https://tools.ietf.org/html/draft-hou-roll-rpl-parent-selection-00 The second draft https://datatracker.ietf.org/doc/html/draft-qasem-roll-rpl-load-balancing Best regards, Chenyang Ji From nobody Mon Nov 6 06:08:55 2017 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 543B713FC1D for ; Mon, 6 Nov 2017 06:08:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.com 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 CcSRScEZk54R for ; Mon, 6 Nov 2017 06:08:52 -0800 (PST) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (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 7F74D13FC1C for ; Mon, 6 Nov 2017 06:08:52 -0800 (PST) Received: by mail-it0-x22c.google.com with SMTP id 72so5177144itk.3 for ; Mon, 06 Nov 2017 06:08:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=xGyyl6wUcyMFtj3YDA4KgGSxSvMW3oNe7W3rsxIyQpM=; b=X89OziAhai/dpA5iKGk4vHH+ufoZAIvRRM4/UCjji9OR8F15NcRY+wxQV82C96Fj89 otw4w5P7QLGfTU7jquonlZj1uTN6UbJ2sQwR0DegrhV+hBhZdZhFuTpYzHjsmqyqvnwV +X0CAZN127g8qSQV45Gv1jNNycbDzbm5vDgeL1b/PS/oM8vgYxRwtRFJCW8L29Pfbj+K eJErKPau4E6uLbzg1T/vgnLk3uw5Bz3xs+FFJl8cLfIveTBiaPTEVV3QeegpL4tVsxCd nCzbn1I9EuaGpEj08U+cCTwEU4/CH/35CAA7MLCK1tn1Hcn7VeUBFtX35Odoe98Jvseq oJGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=xGyyl6wUcyMFtj3YDA4KgGSxSvMW3oNe7W3rsxIyQpM=; b=PAXxUFjk3DJuWJ2PdqYKf6ukaZcC510IBBCoEcKZpgHBn2YfqkS7VSCdcM7Xb+GRGl pNje6YquaIq+2I7oQr78sV0NLjRWDrgdfwKDXO9/2GhwCizi0PhsZ9E0hton3IhPnc4T kimYGeslVNF3aeffP502jskRxwKLTTtv9OQcaY6fgI+GHh6xDRLYGVwQkBKi0JWngjcI MqGsvpIGDxnvzBZf0krsxpfcth9KaQJKwiv4e+A4c2eYr+PgnUMpsKK7lPTfA6K4jLpi o4iVL6J4ZEMRYCDlH2VXy03bYu1Aa/Prn+MWNyD+5qxIPNH209rEjm9x+OhgLJI1kg0w NuRA== X-Gm-Message-State: AJaThX7UfiKBRYhb0eTHeHDvSZ4paT6TsOh7m1Lk//Udz2H3qwCMuGDo JogQtbNV40CoGNtZEiCaz6NV0H0qhSLR98ZGPFfrkQ== X-Google-Smtp-Source: ABhQp+QXmdtdG81260a2oZdGqSi/P0rYsPUSnImG3QXINgKIZs9+cTSvjL40VjKfoR4oroQBTAd1vyhSQ2Ox8Pl0cxk= X-Received: by 10.36.112.143 with SMTP id f137mr9202934itc.84.1509977331435; Mon, 06 Nov 2017 06:08:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.138.197 with HTTP; Mon, 6 Nov 2017 06:08:51 -0800 (PST) From: Ines Robles Date: Mon, 6 Nov 2017 16:08:51 +0200 Message-ID: To: roll Cc: peter van der Stok Content-Type: multipart/alternative; boundary="001a113f6806758d5f055d50fe53" Archived-At: Subject: [Roll] WGLC for draft-ietf-roll-aodv-rpl-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Nov 2017 14:08:54 -0000 --001a113f6806758d5f055d50fe53 Content-Type: text/plain; charset="UTF-8" Dear all, A Working Group Last call (WGLC) starts today (11/06) until 11/20/2017 for draft-ietf-roll-aodv-rpl-02 The draft is available here: https://datatracker.ietf.org/doc/draft-ietf-roll-aodv-rpl/ Please review this draft to see if you think that it is ready for publication and send comments to the list stating your view. Thank you very much in advance, Peter and Ines. --001a113f6806758d5f055d50fe53 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,=C2=A0

A Working Gr= oup Last call (WGLC) starts today (11/06) until 11/20/2017 for draft-ietf-r= oll-aodv-rpl-02

The draft is available here:=C2=A0=
=

Please review this draft to see if you think that it is= ready for publication and send comments to the list stating your view.=C2= =A0


Thank you very much in advance,=

Peter and Ines.
--001a113f6806758d5f055d50fe53-- From nobody Mon Nov 6 12:32:39 2017 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C86D13FBB8; Mon, 6 Nov 2017 12:32:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 QDQTmPHvEvJP; Mon, 6 Nov 2017 12:32:36 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5E7F13FB1F; Mon, 6 Nov 2017 12:32:35 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 99F6AB819F5; Mon, 6 Nov 2017 12:32:22 -0800 (PST) To: jim.list@hotmail.com, yusuke.doi@toshiba.co.jp, matthew.gillmore@itron.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: aretana.ietf@gmail.com, iesg@ietf.org, roll@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20171106203222.99F6AB819F5@rfc-editor.org> Date: Mon, 6 Nov 2017 12:32:22 -0800 (PST) Archived-At: Subject: [Roll] [Errata Held for Document Update] RFC7774 (5063) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Nov 2017 20:32:37 -0000 The following errata report has been held for document update for RFC7774, "Multicast Protocol for Low-Power and Lossy Networks (MPL) Parameter Configuration Option for DHCPv6". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5063 -------------------------------------- Status: Held for Document Update Type: Technical Reported by: James K. Date Reported: 2017-07-06 Held by: Alvaro Retana (IESG) Section: 2.1 Original Text ------------- C_T_EXP (unsigned 16-bit integer): CONTROL_MESSAGE_TIMER_EXPIRATIONS. 0 and 0xffff are reserved and MUST NOT be used. Corrected Text -------------- C_T_EXP (unsigned 16-bit integer): CONTROL_MESSAGE_TIMER_EXPIRATIONS. 0xffff is reserved and MUST NOT be used. Notes ----- [RFC 7731] states: 9.3. MPL Data Message Processing o If the MPL Control Message Trickle timer is not running and CONTROL_MESSAGE_TIMER_EXPIRATIONS is non-zero, the MPL Forwarder MUST initialize and start the MPL Control Message Trickle timer. 10.2. MPL Control Message Transmission An MPL Forwarder transmits MPL Control Messages using the Trickle algorithm. An MPL Forwarder maintains a single Trickle timer for each MPL Domain. When CONTROL_MESSAGE_TIMER_EXPIRATIONS is 0, the MPL Forwarder does not execute the Trickle algorithm and does not transmit MPL Control Messages. Thus, 0 is a valid configuration for C_T_EXP to disable Reactive Forwarding. ===== [Alvaro Retana] The pointer to rfc7731 seems to indicate that the description for CONTROL_MESSAGE_TIMER_EXPIRATIONS is incorrect. However, this document uses Normative language to define the C_T_EXP parameter. I am then not marking this report as Verified, but as "Hold for Document Update", which means that when this document is updated, the validity should be considered then. [1] [1] https://www.ietf.org/iesg/statement/errata-processing.html -------------------------------------- RFC7774 (draft-ietf-roll-mpl-parameter-configuration-08) -------------------------------------- Title : Multicast Protocol for Low-Power and Lossy Networks (MPL) Parameter Configuration Option for DHCPv6 Publication Date : March 2016 Author(s) : Y. Doi, M. Gillmore Category : PROPOSED STANDARD Source : Routing Over Low power and Lossy networks Area : Routing Stream : IETF Verifying Party : IESG From nobody Mon Nov 6 12:41:10 2017 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0944F13FBC5; Mon, 6 Nov 2017 12:41:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 b9UZbOfbaQmE; Mon, 6 Nov 2017 12:41:07 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9C1F13FB8B; Mon, 6 Nov 2017 12:41:07 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 8FB98B81A3E; Mon, 6 Nov 2017 12:40:54 -0800 (PST) To: jim.list@hotmail.com, yusuke.doi@toshiba.co.jp, matthew.gillmore@itron.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: aretana.ietf@gmail.com, iesg@ietf.org, roll@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20171106204054.8FB98B81A3E@rfc-editor.org> Date: Mon, 6 Nov 2017 12:40:54 -0800 (PST) Archived-At: Subject: [Roll] [Errata Held for Document Update] RFC7774 (5057) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Nov 2017 20:41:09 -0000 The following errata report has been held for document update for RFC7774, "Multicast Protocol for Low-Power and Lossy Networks (MPL) Parameter Configuration Option for DHCPv6". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5057 -------------------------------------- Status: Held for Document Update Type: Technical Reported by: James K. Date Reported: 2017-06-29 Held by: Alvaro Retana (IESG) Section: 2.1 Original Text ------------- DM_IMAX (unsigned 8-bit integer): DATA_MESSAGE_IMAX. The actual maximum timeout is described as a number of doublings of DATA_MESSAGE_IMIN, as described in [RFC6206], Section 4.1. 0 and 0xff are reserved and MUST NOT be used. Corrected Text -------------- DM_IMAX (unsigned 8-bit integer): DATA_MESSAGE_IMAX. The actual maximum timeout is described as a number of doublings of DATA_MESSAGE_IMIN, as described in [RFC6206], Section 4.1. 0xff is reserved and MUST NOT be used. Notes ----- RFC6206 The maximum interval size, Imax, is described as a number of doublings of the minimum interval size. RFC7731 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. also The default MPL parameters specify a forwarding strategy that utilizes both proactive and reactive techniques. Using these default values, an MPL Forwarder proactively transmits any new MPL Data Messages it receives and then uses MPL Control Messages to trigger additional MPL Data Message retransmissions where message drops are detected. Setting DATA_MESSAGE_IMAX to the same value as DATA_MESSAGE_IMIN in this case is acceptable, since subsequent MPL Data Message retransmissions are triggered by MPL Control Messages, where CONTROL_MESSAGE_IMAX is greater than CONTROL_MESSAGE_IMIN. For DATA_MESSAGE_IMAX == DATA_MESSAGE_IMIN implies DM_IMAX=0. 0 is a valid value for DM_IMAX. ===== [Alvaro Retana] The pointer to rfc7731 seems to indicate that the description for is incorrect. However, this document uses Normative language to define the DM_IMAX parameter. I am then not marking this report as Verified, but as "Hold for Document Update", which means that when this document is updated, the validity should be considered then. [1] [1] https://www.ietf.org/iesg/statement/errata-processing.html -------------------------------------- RFC7774 (draft-ietf-roll-mpl-parameter-configuration-08) -------------------------------------- Title : Multicast Protocol for Low-Power and Lossy Networks (MPL) Parameter Configuration Option for DHCPv6 Publication Date : March 2016 Author(s) : Y. Doi, M. Gillmore Category : PROPOSED STANDARD Source : Routing Over Low power and Lossy networks Area : Routing Stream : IETF Verifying Party : IESG From nobody Mon Nov 6 16:00:59 2017 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7050213FC9A; Mon, 6 Nov 2017 15:17:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 eFiMfqEVKe_n; Mon, 6 Nov 2017 15:17:14 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3547C13FC98; Mon, 6 Nov 2017 15:17:14 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id A27A2B8161B; Mon, 6 Nov 2017 15:17:00 -0800 (PST) To: aris@ariskou.com, wintert@acm.org, pthubert@cisco.com, abr@sdesigns.dk, jhui@archrock.com, kelsey@ember.com, pal@cs.stanford.edu, kpister@dustnetworks.com, rstruik.ext@gmail.com, jpv@cisco.com, roger.alexander@cooperindustries.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: aretana.ietf@gmail.com, iesg@ietf.org, roll@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20171106231700.A27A2B8161B@rfc-editor.org> Date: Mon, 6 Nov 2017 15:17:00 -0800 (PST) Archived-At: X-Mailman-Approved-At: Mon, 06 Nov 2017 16:00:47 -0800 Subject: [Roll] [Errata Held for Document Update] RFC6550 (5160) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Nov 2017 23:17:15 -0000 The following errata report has been held for document update for RFC6550, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5160 -------------------------------------- Status: Held for Document Update Type: Technical Reported by: Remous-Aris Koutsiamanis Date Reported: 2017-10-18 Held by: Alvaro Retana (IESG) Section: 6.7.4 Original Text ------------- The DAG Metric Container option MAY be present in DIO or DAO messages, and its format is as follows: Corrected Text -------------- The DAG Metric Container option MAY be present in the DIO message, and its format is as follows: Notes ----- The DAG Metric Container is not defined as one of the valid options in Section 6.4.3. -------------------------------------- RFC6550 (draft-ietf-roll-rpl-19) -------------------------------------- Title : RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks Publication Date : March 2012 Author(s) : T. Winter, Ed., P. Thubert, Ed., A. Brandt, J. Hui, R. Kelsey, P. Levis, K. Pister, R. Struik, JP. Vasseur, R. Alexander Category : PROPOSED STANDARD Source : Routing Over Low power and Lossy networks Area : Routing Stream : IETF Verifying Party : IESG From nobody Mon Nov 13 03:53:07 2017 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3E54129422 for ; Mon, 13 Nov 2017 03:53:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.com 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 bNY5KBdcKbkj for ; Mon, 13 Nov 2017 03:53:04 -0800 (PST) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (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 8397F129411 for ; Mon, 13 Nov 2017 03:53:04 -0800 (PST) Received: by mail-it0-x22a.google.com with SMTP id m191so8999470itg.2 for ; Mon, 13 Nov 2017 03:53:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=cqZ/Hhhz1cpyu63kg146idAIMTqraWy8/Ld9qbauSfk=; b=LBQ/UN7UNObQ83xruFh0UjBJAFxVGQk4K5uDo0tpU6O0rdZlSILQCvmuSROHDelIc+ EpTxIIiZLMzKgnju0ukXwbR8yb5QMva5aYfoxd1Zfv2zfuATUbKVkTLpXwCinneMc+RN e/ro7GZMFpGLvmDG8g+5S6gJtfBokaQAlzQigSPLqAoWaN2EuYmMVsC0bbiy5eOQCoCI MLxFpAs3lJZgHBkkxyUu1UuvqbYt2uKlBQQZUv0c6T0BGDO1Pklh1dSKBSbqwowe8jfv FcUYS1GgfK/MQmdLp8jIgcWmzc9xMIkWPCdNa+jAF1DBOTVZEIHxPL51U2tTIaYwxYz4 2RRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=cqZ/Hhhz1cpyu63kg146idAIMTqraWy8/Ld9qbauSfk=; b=oX7UCau6F8SwbDpA0BzZbFdDgD9xHVURgCLKArCRtYj2o3iq4c5aPYJ7ks6zp2pw0o Lk5VHLNYxDcupxzoVG6E5xoZj9MRfXAZtTB4lo7S6mh9TEMHE07p9p20RiynqybA3nTw cOvR6+qP3kMh9tBxXoZgakxpgh4t3c/w39m+N/4N/GPq0nDC91GerI46mq6tuTDchhRX qe6Dx90oAJfm3knW4EbbGCo1RQlRvqP5OFdd4H4pu3u8XL30q5+SdqVqjBpo1IHIrJol h4W3e4iPJEEGsRnFVoji/35Q4GfGLaJUfNf5z9SKGIEx2M2m6sfwDJHY1W+v+xqHeaBo DKBg== X-Gm-Message-State: AJaThX4jCA/dLZp6gF9CAQGfW9yXpT3t/11vciX81NOeMK85urvJhdaR Y7FQp+M4l7cN1UOMwYoCrCcjXVpPXD40qs8CuGuxmA== X-Google-Smtp-Source: AGs4zMbZcVHGW/cFR77gR4PESYqi1+KwlI4uW65kfUfpWnIb3OYWwTL4a/O05aLmUEwe10ruL9vZQPsYGMOM62Kolmc= X-Received: by 10.36.135.199 with SMTP id f190mr9257639ite.133.1510573983620; Mon, 13 Nov 2017 03:53:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.69.130 with HTTP; Mon, 13 Nov 2017 03:53:03 -0800 (PST) From: Ines Robles Date: Mon, 13 Nov 2017 19:53:03 +0800 Message-ID: To: roll Cc: peter van der Stok Content-Type: multipart/alternative; boundary="94eb2c033ffab363fb055ddbe982" Archived-At: Subject: [Roll] Slides - IETF 100 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 11:53:06 -0000 --94eb2c033ffab363fb055ddbe982 Content-Type: text/plain; charset="UTF-8" Hi, Please find a first version of the slides for IETF 100, https://datatracker.ietf.org/meeting/100/materials/slides-100-roll-slides-ietf-100/ Comments welcome, Thanks, Ines and Peter --94eb2c033ffab363fb055ddbe982 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Please find a first version of the = slides for IETF 100,


Comments welcome,

Thanks,

Ines and Peter
--94eb2c033ffab363fb055ddbe982-- From nobody Mon Nov 13 20:39:21 2017 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7AB0128B90 for ; Mon, 13 Nov 2017 20:39:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.com 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 cUOq95jt7No8 for ; Mon, 13 Nov 2017 20:39:18 -0800 (PST) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (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 F3D191276AF for ; Mon, 13 Nov 2017 20:39:17 -0800 (PST) Received: by mail-it0-x22c.google.com with SMTP id m191so12151019itg.2 for ; Mon, 13 Nov 2017 20:39:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bonE7kL2sbHu50fEe2t8fGE7fJGAw63Rgp9fsIJlHgU=; b=n7Si/5/pLPgzuB7bXvGiAvWhp6/lN/j5cgVk3MWecSh9J+ulP5ZrWA/aEEAMrvMiuK vhh/hpg2zz9vJk77fFL+9wSrD8s/EDyfMzEorF59NN+MthmpkfS6cCnB0qSU36hLFLQi rNd17oPvGPUrCACtJfS7TmZ2j4bKgO+qPBFQlo6P6veV7NZLCVI9ym2rJ8zFD8hf8lR6 rwv1/8jxM/f5kvoVEvJwt1rhkGLvuFR2j/FHT8pYFEPgazNfa5KQd01HlGYJZeD+TCPv 3Kc8jMRCknSaVUORj83IxTpiVvgiSlxnj4SLnwl9AG6lYAmK3nuzaoV+nWPW9m1yJmVq tVSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bonE7kL2sbHu50fEe2t8fGE7fJGAw63Rgp9fsIJlHgU=; b=ZaXPvsJF0Uz4L24gSHeCqSnPcuN3NOnYQRGAi6TDkBzxhKWO5zWqLJAwUCYqzNfVV6 yMRa0VWN0DO0x47D7Mw363lKzrntTKYSSTbmJEvU4PTo43iP1jD1OOCKaLwu/1NHss54 iBCdXC2rPOVrJVh1usU8GEOYMwmPGEsPShqwueUqb1DP5VwgFS2HyskRhVRWNFnAqwi0 iKsFxcgt/hE499YZblkFGUMi6HZx1z5myVcwpbycRrss9in9dVe5OQFVZiI2pDr297MO mfU69foevX0DaV7Os67YKPlSpK2RNG9LWBNwJfMyyQZeIGFcsobCnzvFscErHH8d1w4I VLkQ== X-Gm-Message-State: AJaThX51AB6KBDmx4CGp4pjBGNoacvibnHu+KwHkMGkZmp9ih1fSQNHv RReqvSty8XVvMyErNlCD87PHQws9Lax7PLSoC/L1RQ== X-Google-Smtp-Source: AGs4zMYtsVYJf4Is1o/9fyf4c6t49yOiC07A8dXNd4r7iVRV6siLvjO3ItESaQ/BD66lK+0YAaOvhbK2UfoC85Bq8HY= X-Received: by 10.36.1.211 with SMTP id 202mr13375155itk.14.1510634357014; Mon, 13 Nov 2017 20:39:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.69.130 with HTTP; Mon, 13 Nov 2017 20:39:16 -0800 (PST) In-Reply-To: References: From: Ines Robles Date: Tue, 14 Nov 2017 12:39:16 +0800 Message-ID: To: roll Cc: peter van der Stok Content-Type: multipart/alternative; boundary="001a1143d4b03c472e055de9f815" Archived-At: Subject: Re: [Roll] Slides - IETF 100 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 04:39:20 -0000 --001a1143d4b03c472e055de9f815 Content-Type: text/plain; charset="UTF-8" Dear all, Please find an updated version of the slides https://datatracker.ietf.org/meeting/100/materials/slides-100-roll-consolidatedslides/ Thanks, Ines + Peter 2017-11-13 19:53 GMT+08:00 Ines Robles : > Hi, > > Please find a first version of the slides for IETF 100, > > https://datatracker.ietf.org/meeting/100/materials/slides- > 100-roll-slides-ietf-100/ > > Comments welcome, > > Thanks, > > Ines and Peter > --001a1143d4b03c472e055de9f815 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,

Please find an updated versio= n of the slides=C2=A0


Thanks,

Ines = + Peter

2017-1= 1-13 19:53 GMT+08:00 Ines Robles <mariainesrobles@googlemail= .com>:
<= div dir=3D"ltr">Hi,

Please find a first version of the s= lides for IETF 100,


Comments welco= me,

Thanks,

Ines and Pete= r

--001a1143d4b03c472e055de9f815-- From nobody Wed Nov 15 00:18:15 2017 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC9A12951F for ; Wed, 15 Nov 2017 00:18:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 ewx5cMKhSmRI for ; Wed, 15 Nov 2017 00:18:12 -0800 (PST) Received: from lb3-smtp-cloud9.xs4all.net (lb3-smtp-cloud9.xs4all.net [194.109.24.30]) (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 113EC126C25 for ; Wed, 15 Nov 2017 00:18:11 -0800 (PST) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:211]) by smtp-cloud9.xs4all.net with ESMTPA id EstdeH5mMnIXbEstde3hA0; Wed, 15 Nov 2017 09:18:10 +0100 Received: from 2001:67c:1232:144:97b:d840:d875:53d9 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 15 Nov 2017 09:18:09 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 15 Nov 2017 09:18:09 +0100 From: peter van der Stok To: Roll Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org Message-ID: X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfFRn/pQclNoUYMoKYTFDH7AEawr2iPP393KXxuF+G7NE8ZJdjmK1vbM4mFke1CqdgqePmrYBBw3v3VXszk8aeMi8w8nS6LxQhH1uOm32IVaqomWzyAW3 /sb94lKuJTBs8wEymBo2bl8wdFSeQSIKf0fTzkKVArpwDZTUadAgfAn/qyldt4XZy7z+jh4Ai4ywVAx9ZhtaeRb1vmNY1sMySPY= Archived-At: Subject: [Roll] roll minutes X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 08:18:14 -0000 Hi all, Roll minutes available at: https://datatracker.ietf.org/meeting/100/materials/minutes-100-roll/ with many thanks to Dominique for his unrelenting efforts. Peter -- Peter van der Stok vanderstok consultancy mailto: consultancy@vanderstok.org www: www.vanderstok.org tel NL: +31(0)492474673 F: +33(0)966015248 From nobody Wed Nov 15 20:57:46 2017 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C08A128D64 for ; Wed, 15 Nov 2017 20:57:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 qoCtVlO-fpER for ; Wed, 15 Nov 2017 20:57:43 -0800 (PST) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (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 20171127522 for ; Wed, 15 Nov 2017 20:57:43 -0800 (PST) Received: by mail-wm0-x22e.google.com with SMTP id r68so612715wmr.0 for ; Wed, 15 Nov 2017 20:57:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=TaFiRJtqXNn1BD8uhU+LSTT9IhJGsNkifJvVDKsxmlU=; b=TmJ0mejDpJpB/v2y032mNyaYznnpAv+AX4OHSAsCHCr6Oo/XYjeU3FRylsyHp7di/I 24D+/qS08pnio9cO9246xwKj7/LtQ75+cDuAAAg0euW17tSJvJIGbI11D8PMjjD8eKQH vuWuijap1LqdiAy+0iOlcKl0WZoMG/wzEp+2q7cPoUr70dJ6a4rnvr+z2mx3tkkpB8/j 0S9+ZhEoA8eKFyD9UeVCJgfM2tJa3sgSO8g8ZMPrp6naZh9HpY53GyMwEVZKwGnWqB+F 5NSbI6SA+cPvpDa/jVmQbB+8LuYtRiiYuUiusH76Y26Q+1OLSW6wosDYWvU5yeZzav/X 7LDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=TaFiRJtqXNn1BD8uhU+LSTT9IhJGsNkifJvVDKsxmlU=; b=Dzo4yUmRz13HbsQVEiC7YHTVg+wETx6OwIDUHeUkrVxkhEf/9OzECh5axvlQW6tn5V 6bqsxD7+s7/Y4Ra9X1bh7IzdLA+irdaq2QeDK/eMcnlIRlBjS/nSzmOSBUv5wZeKZgDf oGZPJwhJKab46B/g4qx+nA039P8xaACs5E89oLRhlCuoMB00HKVsDFFMvippCVxyyrIO HULKWYkGlkXPI1hrjgeFFw5AUQk/rddxasi7VLv7L4CPNN4tAp+t9h/VntXDvd/98HO2 +8DgkPI2WqoIxs8cgTOdWibHVmbgARltER4jRVw2SRcbFW3zY5bGGZ0slC8HslY79UFI y3cQ== X-Gm-Message-State: AJaThX54IHq18p5hr6e23AnlscfjpG5+SsVlSXiDxkB7oA4ZabzHwK5z rODwPhHVDIrzDOxDBzyi7Q9YLV6v0p5LpxAdNKsUmg== X-Google-Smtp-Source: AGs4zMZxlCe9+qf8swEjjzb+ppyg4tv9HhurR8paf7N/3JjenGNiCUHPeHCn71u7vQLXxFa1oIUG9Cs8YcK1MEOMF5g= X-Received: by 10.80.224.65 with SMTP id g1mr919983edl.264.1510808261283; Wed, 15 Nov 2017 20:57:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.142.74 with HTTP; Wed, 15 Nov 2017 20:57:40 -0800 (PST) From: Rahul Jadhav Date: Thu, 16 Nov 2017 12:57:40 +0800 Message-ID: To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary="089e082209a0bcd66a055e127561" Archived-At: Subject: [Roll] Review of AODV-RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 04:57:46 -0000 --089e082209a0bcd66a055e127561 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Following is my review of AODV-RPL. One of the stated goal of AODV-RPL is to cater to asymmetric links. While this is really great to have, I have doubts that the current specification achieves it in a practical way. Foll is the reasoning: 1. The Messaging: AODV-RPL requires that you send a multicast message from OrigNode to TargNode and realise a routing path in the opposite direction. For e.g. A -> B -> C -> D, A sends a RREQ-Instance message towards D and nodes B,C,D establish routing adjacencies in the opposite direction. This kind of messaging is the reason why RPL depends on bidirectional links for control/data paths. 2. The Assumptions: a. Quoting draft, =E2=80=9CEach intermediate node R_i computes the rank for RREQ-Instance and= creates a routing table entry for the upstream route towards the source if the routing metrics/constraints are satisfied. For this purpose R_i ***must use the asymmetric link metric measured in the upstream direction***, from R_i to its upstream neighbor that multicasted the RREQ-Instance message.=E2= =80=9D This is the primary assumption which achieves asymmetric behaviour. But it=E2=80=99s an implementation nightmare to do this measurement especially = because we do not know which neighbour we might end up tieing up with (thus need to probe all neighbours). It will add up so much to the control overhead and also requires (a good deal of) state info to be maintained on behalf of the neighbouring nodes. Anyways i tried to search for your implementation to check on this but i could not find it. b. Use of past conditions to suggest future traffic path selection: =E2=80=9CIf the RREQ-Instance arrives over an interface that is not known t= o be symmetric, or is known to be asymmetric, the 'S' bit is set to be 0.=E2=80= =9D This is a typical problem we face as well. Probing for measurements at such scale (all neighbours) is a problem. If you do the probing sparsely, the network conditions might have changed when you want to use the measurements= . Other points: 1. Use of odd/even numbers for pairing instances may not be a robust way of pairing =E2=80=A6 There could be race conditions where other P2P-RPL = instances or floating DODAG instances end up using one of the same value in the instance-id pair. How to resolve such collision? 2. I would recommend to use Cooja with links in DGRM mode to evaluate the perf. 3. The RSSI values in the Appendix do not look correct. An RSSI of <-70dbm is too good [1] to have for good PDR. The mapping of RSSI-ETX in the appendix hence may not be correct (i believe these values are from Cooja). [1] RSSI is Under-Appreciated https://sing.stanford.edu/site/publications/emnets2006srinivasan.pdf Regards, Rahul --089e082209a0bcd66a055e127561 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Following is my review of AODV-RPL.

One of the stated goal of AODV-RPL is to cater to asy= mmetric links. While this is really great to have, I have doubts that the c= urrent specification achieves it in a practical way. Foll is the reasoning:=

  1. The Messaging:

AODV-RPL requires that you send a multicast message from OrigNod= e to TargNode and realise a routing path in the opposite direction.=C2=A0

= For e.g. A -> B -> C -> D, A sends a RREQ-Instance message towards= D and nodes B,C,D establish routing adjacencies in the opposite direction.= This kind of messaging is the reason why RPL depends on bidirectional link= s for control/data paths.

2. The Assumptions:

a. Quoting draft,=C2=A0

=E2=80=9CEach intermedia= te node R_i computes the rank for RREQ-Instance and creates a routing table= entry for the upstream route towards the=C2=A0source i= f the routing metrics/constraints are satisfied.=C2=A0 For this purpose R_i ***must use the asymmet= ric link metric measured in the upstream direction***, from R_i to its upst= ream neighbor that multicasted the RREQ-Instance message.=E2=80=9D

This is the primary assumption which achiev= es asymmetric behaviour. But it=E2=80=99s an implementation nightmare to do= this measurement especially because we do not know which neighbour we migh= t end up tieing up with (thus need to probe all neighbours). It will add up= so much to the control overhead and also requires (a good deal of) state i= nfo to be maintained on behalf of the neighbouring nodes.

Anyways i tried to search for your implementation to check on th= is but i could not find it.

b. Use of past conditions to suggest future traffic path selecti= on:

= =E2=80=9CIf the RREQ-Instance arrives over an interface that is not known t= o=C2=A0be symmetric, or is known to be asymmetric, the = 'S' bit is set to be 0.=E2=80=9D

This is a typical problem we face as well. Probing for measureme= nts at such scale (all neighbours) is a problem. If you do the probing spar= sely, the network conditions might have changed when you want to use the me= asurements.

Other points:

  1. Use of odd/even numbers for pairing instances may n= ot be a robust way of pairing =E2=80=A6 There could be race conditions wher= e other P2P-RPL instances or floating DODAG instances end up using one of t= he same value in the instance-id pair. How to resolve such collision?
  2. I would recommend to use Cooja with links in DGRM m= ode to evaluate the perf.
  3. The RSSI values in the Appendix do not look correct= . An RSSI of <-70dbm is too good [1] to have for good PDR. The mapping o= f RSSI-ETX in the appendix hence may not be correct (i believe these values= are from Cooja).

[1]=C2=A0 RSSI is Under-Appreciated https://sing.stanford.edu/site/publications/emnets2006sriniv= asan.pdf


Regards,

Rahul

--089e082209a0bcd66a055e127561-- From nobody Sun Nov 19 05:09:59 2017 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 082FF127077 for ; Sun, 19 Nov 2017 05:09:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 LqHxz7H3Ez9L for ; Sun, 19 Nov 2017 05:09:55 -0800 (PST) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (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 EE3FB127873 for ; Sun, 19 Nov 2017 05:09:54 -0800 (PST) Received: by mail-qk0-x22a.google.com with SMTP id n3so4507738qkn.11 for ; Sun, 19 Nov 2017 05:09:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=V4J/YDf3JPRG3HIlUJ2iD32WiamybjPjIUHKPOUVGYE=; b=CWahx2qllxvA64sCDlIdu8478vAwooL06SvVML4/zbYZrpqgJUgz/dvM1d2IZZK7c6 i0qLT/Oc0UcwpEiUkxmzAbmHQQLeXiIAflbXOGxd3bMXlKL/MLsOpXW7fZDWV1NsuATx 4duMbzomWRbk6upIEDg+aB//1Cv4Z+avGW/MlQVIIMlOeaI22/RSF43x+OIoHTJMp18S 6aSTTkMVbiq6xPKwyaZJGqPyixJl+tP0eYBPDZJvEDpLCeagj74A6a10ob4cLgbobTzX jOQbPGAB7hnBefCHvL/EPZZNQUhmDrMbQyEZgzTSicmnfxXcLZEL+fn546d9QS7ATrqB 2VKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=V4J/YDf3JPRG3HIlUJ2iD32WiamybjPjIUHKPOUVGYE=; b=U9MqT6ZxsAbJzC3o+FPlojDEZKg3YxAFhSJ5Mk6HWHvg1lFmfRxIu4Wt58JPo24WdD FAKjctHGAXBj1Zi1vMj9/52CmVJ/b8DhyoRJIU9DFKJys0s3EvKT+4eCEy/2rs6gezJK nsjxB0MJfQp87oYFcN4eSpFqtoE31Ulsr7CTO+QBKr6cbybztzDwF6TJX1/YiDMitsK7 Im/PjJ0/AhXy+6wwNg6Zhc/2od/6/9IHICN4C/hoB7236utUdXoUJpoG+TerJaksPjke /n27yWAwRCW6ozVUQDqegp5DjoWmwhvmZ1pv/OEkDkB2l1C0GyUnVnxyz3aHQ5aN6BhZ WzXQ== X-Gm-Message-State: AJaThX5YlWR2dbVoz8FLr7AXfA07v7aCxZDRIPawR9QjreVg1/qHISnl Lo/MXDr+dLVEc3+QpkIY8r+3smFCOhwullr1lbCwAA== X-Google-Smtp-Source: AGs4zMbl1/WMS5gVwN3ydXUJHG2fFWUWQEbIo97UODd9G07qCtz5EeSmLxiy5Dc+C7e7OODcvfYgKfRa+FXERhJXsOU= X-Received: by 10.55.110.196 with SMTP id j187mr16983248qkc.192.1511096993581; Sun, 19 Nov 2017 05:09:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.108.229 with HTTP; Sun, 19 Nov 2017 05:09:53 -0800 (PST) In-Reply-To: References: From: satish anamalamudi Date: Sun, 19 Nov 2017 21:09:53 +0800 Message-ID: To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary="94eb2c05b69a860ebd055e55af2a" Archived-At: Subject: Re: [Roll] Review of AODV-RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Nov 2017 13:09:58 -0000 --94eb2c05b69a860ebd055e55af2a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Rahul, Thanks a lot for the review and comments on AODV-RPL. Please see my response to your comments in [SA]. With regards Satish. Following is my review of AODV-RPL. One of the stated goal of AODV-RPL is to cater to asymmetric links. While this is really great to have, I have doubts that the current specification achieves it in a practical way. Foll is the reasoning: 1. The Messaging: AODV-RPL requires that you send a multicast message from OrigNode to TargNode and realise a routing path in the opposite direction. For e.g. A -> B -> C -> D, A sends a RREQ-Instance message towards D and nodes B,C,D establish routing adjacencies in the opposite direction. This kind of messaging is the reason why RPL depends on bidirectional links for control/data paths. [SA] Yes Rahul. The control messages(RREQ, RREP) and application data transmission is in the opposite direction for AODV-RPL. We are checking for the bi-directional asymmetry during control message broadcast and initiates another multicast RREQ from destination whenever there is link asymmetry from Source to Destination. 2. The Assumptions: a. Quoting draft, =E2=80=9CEach intermediate node R_i computes the rank for RREQ-Instance and= creates a routing table entry for the upstream route towards the source if the routing metrics/constraints are satisfied. For this purpose R_i ***must use the asymmetric link metric measured in the upstream direction***, from R_i to its upstream neighbor that multicasted the RREQ-Instance message.=E2= =80=9D This is the primary assumption which achieves asymmetric behaviour. But it=E2=80=99s an implementation nightmare to do this measurement especially = because we do not know which neighbour we might end up tieing up with (thus need to probe all neighbours). It will add up so much to the control overhead and also requires (a good deal of) state info to be maintained on behalf of the neighbouring nodes. Anyways i tried to search for your implementation to check on this but i could not find it. [SA] In fact, the AODV-RPL draft is not intended to check how the links are going to be symmetric (or) asymmetric. The objective of our draft is when the link is bidirectional asymmetric then how the AODV-RPL protocol handles the scenarios of asymmetric bi-directional links. Please check the below link for the implementation of asymmetric AODV-RPL in Cooja Simulator. https://github.com/lavanyahm/Contiki_AODVRPL b. Use of past conditions to suggest future traffic path selection: =E2=80=9CIf the RREQ-Instance arrives over an interface that is not known t= o be symmetric, or is known to be asymmetric, the 'S' bit is set to be 0.=E2=80= =9D This is a typical problem we face as well. Probing for measurements at such scale (all neighbours) is a problem. If you do the probing sparsely, the network conditions might have changed when you want to use the measurements= . [SA] Yes, this is indeed a good problem in itself which calls for a separate draft exploring alternate methods. In the literature, one comes across several techniques being proposed that include active and passive probing techniques, radio sniffing, statistical channel estimation methods, message passing, and other energy efficient techniques. In AODV-RPL, we assume that the link property is obtained through some means, and do not recommend any specific method to come with the symmetric and asymmetric link property. Other points: 1. Use of odd/even numbers for pairing instances may not be a robust way of pairing =E2=80=A6 There could be race conditions where other P2P-RPL instan= ces or floating DODAG instances end up using one of the same value in the instance-id pair. How to resolve such collision? [SA] In order to establish the upstream route from TargNode to OrigNode, OrigNode multicasts the RREQ-Instance message to its one-hop neighbours. In order to enable intermediate nodes R_i to associate a future RREP message to an incoming RREQ message, the RREQ message MUST assign an odd number for the OrigNode's Dest SeqNo which is included in the RREQ message. When an intermediate node R_i receives a RREQ message in storing mode, it MUST store the OrigNode's Dest Seqno along with the other routing information needed to establish the route back to the OrigNode. This will enable R_i to determine that a future RREP message (containing a paired Dest Seqno for the TargNode) must be transmitted back to the OrigNode's IP address. 'T' bit (DIO-RREP option): 'T' is set to true to indicate that the TargNode IPv6 Address field is present. TargNode IPv6 Address (when present) : IPv6 address of the TargNode that receives RREP-Instance message. In order to reduce the need for the TargNode IPv6 Address to be included with the RREP message, the Dest SeqNo of the RREP is paired, whenever possible, with the Dest SeqNo from the RREQ message, which is always an odd number. The pairing is accomplished by adding one to the Dest Seqno from the RREQ message and using that, whenever possible, as the Dest Seqno for the RREP message. If this is not possible (for instance because the incremented sequence number is still a valid sequence number for another route to the TargNode from an earlier Route Discovery operation), then the 'T' bit is set and an odd number is chosen for the TargNode's Dest SeqNo. 2. I would recommend to use Cooja with links in DGRM mode to evaluate the perf. [SA] Please, check the above github link. We too used the DGRM mode to evaluate the performance of AODV-RPL. The RSSI values in the Appendix do not look correct. An RSSI of <-70dbm is too good [1] to have for good PDR. The mapping of RSSI-ETX in the appendix hence may not be correct (i believe these values are from Cooja). [SA] Yes, we considered the appendix values based on the experiments in Cooja simulator. On Thu, Nov 16, 2017 at 12:57 PM, Rahul Jadhav wrote= : > Following is my review of AODV-RPL. > > One of the stated goal of AODV-RPL is to cater to asymmetric links. While > this is really great to have, I have doubts that the current specificatio= n > achieves it in a practical way. Foll is the reasoning: > > 1. The Messaging: > > AODV-RPL requires that you send a multicast message from OrigNode to > TargNode and realise a routing path in the opposite direction. > > For e.g. A -> B -> C -> D, A sends a RREQ-Instance message towards D and > nodes B,C,D establish routing adjacencies in the opposite direction. This > kind of messaging is the reason why RPL depends on bidirectional links fo= r > control/data paths. > > 2. The Assumptions: > > a. Quoting draft, > > =E2=80=9CEach intermediate node R_i computes the rank for RREQ-Instance a= nd > creates a routing table entry for the upstream route towards the source > if the routing metrics/constraints are satisfied. For this purpose R_i > ***must use the asymmetric link metric measured in the upstream > direction***, from R_i to its upstream neighbor that multicasted the > RREQ-Instance message.=E2=80=9D > > This is the primary assumption which achieves asymmetric behaviour. But > it=E2=80=99s an implementation nightmare to do this measurement especiall= y because > we do not know which neighbour we might end up tieing up with (thus need = to > probe all neighbours). It will add up so much to the control overhead and > also requires (a good deal of) state info to be maintained on behalf of t= he > neighbouring nodes. > > Anyways i tried to search for your implementation to check on this but i > could not find it. > > b. Use of past conditions to suggest future traffic path selection: > > =E2=80=9CIf the RREQ-Instance arrives over an interface that is not known= to be > symmetric, or is known to be asymmetric, the 'S' bit is set to be 0.=E2= =80=9D > > This is a typical problem we face as well. Probing for measurements at > such scale (all neighbours) is a problem. If you do the probing sparsely, > the network conditions might have changed when you want to use the > measurements. > > Other points: > > 1. Use of odd/even numbers for pairing instances may not be a robust > way of pairing =E2=80=A6 There could be race conditions where other P2= P-RPL > instances or floating DODAG instances end up using one of the same val= ue in > the instance-id pair. How to resolve such collision? > 2. I would recommend to use Cooja with links in DGRM mode to evaluate > the perf. > 3. The RSSI values in the Appendix do not look correct. An RSSI of > <-70dbm is too good [1] to have for good PDR. The mapping of RSSI-ETX = in > the appendix hence may not be correct (i believe these values are from > Cooja). > > > [1] RSSI is Under-Appreciated https://sing.stanford.edu/ > site/publications/emnets2006srinivasan.pdf > > > Regards, > > Rahul > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > --=20 *With Regards,* *Dr. Satish Anamalamudi, PhD.,* --94eb2c05b69a860ebd055e55af2a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hello Rahul,

Thanks a lot for the rev= iew and comments on AODV-RPL. Please see my response to your comments in [S= A].

With regards

Satish.

Following is m= y review of AODV-RPL.

One of the stated go= al of AODV-RPL is to cater to asymmetric links. While this is really great = to have, I have doubts that the current specification achieves it in a prac= tical way. Foll is the reasoning:

  1. The Messaging:

AODV-RPL r= equires that you send a multicast message from OrigNode to TargNode and rea= lise a routing path in the opposite direction.=C2= =A0

For e.g. A -> B -> C -> D, A sends a RREQ-Instanc= e message towards D and nodes B,C,D establish routing adjacencies in the op= posite direction. This kind of messaging is the reason why RPL depends on b= idirectional links for control/data paths.

[SA]=C2=A0Yes Rahul. The control messages(RREQ, RREP) and ap= plication data transmission is in the opposite direction for AODV-RPL. We a= re checking for the bi-directional asymmetry during control message broadca= st and initiates another multicast RREQ from destination whenever there is = link asymmetry from Source to Destination.=C2=A0

2. The Assumptions:

a. Quoting d= raft,=C2=A0

=E2=80=9CEach intermediate node R_i c= omputes the rank for RREQ-Instance and creates a routing table entry for th= e upstream route towards the=C2=A0source if= the routing metrics/constraints are satisfied.=C2= =A0=C2=A0For this purpose R_i ***must use the asymmetric link metric= measured in the upstream direction***, from R_i to its upstream neighbor t= hat multicasted the RREQ-Instance message.=E2=80=9D

This is the primary assumption which achieves asymmetr= ic behaviour. But it=E2=80=99s an implementation nightmare to do this measu= rement especially because we do not know which neighbour we might end up ti= eing up with (thus need to probe all neighbours). It will add up so much to= the control overhead and also requires (a good deal of) state info to be m= aintained on behalf of the neighbouring nodes.

=

Anyways i tried to search for your implementation to check on this but i= could not find it.

[SA]=C2= =A0In fact, the AODV-RPL draft is not intended to check how the links are g= oing to be symmetric (or) asymmetric. The objective of our draft is when th= e link is bidirectional asymmetric then how the AODV-RPL protocol handles t= he scenarios of asymmetric bi-directional links.=C2=A0 Please check the bel= ow link for the implementation of asymmetric AODV-RPL in Cooja Simulator.

https://github.com/lavanyahm/Contiki_AODVRPL=

b. Use of past conditions to suggest future traffic path se= lection:

=E2=80=9CIf the RREQ-Instance= arrives over an interface that is not known to=C2= =A0be symmetric, or is known to be asymmetric, the 'S' bit i= s set to be 0.=E2=80=9D

This = is a typical problem we face as well. Probing for measurements at such scal= e (all neighbours) is a problem. If you do the probing sparsely, the networ= k conditions might have changed when you want to use the measurements.

<= /blockquote>

[SA]=C2=A0=C2=A0Yes, this is ind= eed a good problem in itself which calls for a separate=C2=A0draft explorin= g alternate methods. In the literature, one comes across several=C2=A0techniques being proposed that include a= ctive and passive probing techniques,=C2=A0radio sniffing, statistical channel estimation methods, message pas= sing, and=C2=A0other energy efficie= nt techniques. In AODV-RPL, we assume that the link property=C2=A0is obtained through some means, and do not r= ecommend any specific method to come=C2=A0with the symmetric and asymmetric link property.

Other points:

1. Use of odd/even numbers for pairing instances may not be a r= obust way of pairing =E2=80=A6 There could be race conditions where other P= 2P-RPL instances or floating DODAG instances end up using one of the same v= alue in the instance-id pair. How to resolve such collision?

<= span style=3D"font-size:12.8px">[SA]=C2=A0In order to establish the upstrea= m route from TargNode to OrigNode,=C2=A0 OrigNode multicasts the RREQ-Insta= nce message to its one-hop neighbours.=C2=A0 In order to enable intermediat= e nodes R_i to associate a future RREP message to an incoming RREQ message,= the RREQ message MUST assign an odd number for the OrigNode's Dest Seq= No which is included in the RREQ message. When an intermediate node R_i rec= eives a RREQ message in storing mode, it MUST store the OrigNode's Dest= Seqno along with the other routing information needed to establish the rou= te back to the OrigNode.=C2=A0 This will enable R_i to determine that a fut= ure RREP message (containing a paired Dest Seqno for the TargNode) must be = transmitted back to the OrigNode's IP address.

'T' bit (DIO-RREP option):=C2=A0 'T' = is set to true to indicate that the TargNode IPv6 Address field is present.=

TargNode IPv6 Address=C2=A0 = (when present) :=C2=A0 IPv6 address of the TargNode that receives RREP-Inst= ance message. In order to reduce the need for the TargNode IPv6 Address to = be included with the RREP message, the Dest SeqNo of the RREP is paired, wh= enever possible, with the Dest SeqNo from the RREQ message, which is always= an odd number.=C2=A0 The pairing is accomplished by adding one to the Dest= Seqno from the RREQ message and using that, whenever possible, as the Dest= Seqno for the RREP message.=C2=A0 If this is not possible (for instance be= cause the incremented sequence number is still a valid sequence number for = another route to the TargNode from an earlier Route Discovery operation), t= hen the 'T' bit is set and an odd number is chosen for the TargNode= 's Dest SeqNo.

2. I w= ould recommend to use Cooja with links in DGRM mode to evaluate the perf.

[SA]=C2=A0Please, check the ab= ove github link. We too used the DGRM mode to evaluate the performance of A= ODV-RPL.

The RSSI values in t= he Appendix do not look correct. An RSSI of <-70dbm is too good [1] to h= ave for good PDR. The mapping of RSSI-ETX in the appendix hence may not be = correct (i believe these values are from Cooja).

[SA]=C2=A0Y= es, we considered the appendix values based on the experiments in Cooja sim= ulator.

On Thu, Nov 16, 2017 at 12:57 PM, Rahul Jadhav <rahul.ietf@gmail.com<= /a>> wrote:

Following is my review of AODV-R= PL.

One of the stated goal of AODV-R= PL is to cater to asymmetric links. While this is really great to have, I h= ave doubts that the current specification achieves it in a practical way. F= oll is the reasoning:

  1. The Messaging:

AODV-RPL requires that you send a multicast= message from OrigNode to TargNode and realise a routing path in the opposi= te direction.=C2=A0

For e.g. A -= > B -> C -> D, A sends a RREQ-Instance message towards D and nodes= B,C,D establish routing adjacencies in the opposite direction. This kind o= f messaging is the reason why RPL depends on bidirectional links for contro= l/data paths.

2. The Assump= tions:

a. Quoting draft,=C2=A0

=E2=80=9CEach intermediate node R_i computes the rank for= RREQ-Instance and creates a routing table entry for the upstream route tow= ards the=C2=A0source if the routing metrics/constraints are satisfied.=C2=A0 For this purpo= se R_i ***must use the asymmetric link metric measured in the upstream dire= ction***, from R_i to its upstream neighbor that multicasted the RREQ-Insta= nce message.=E2=80=9D

This is the primary assumption which achieves asymmetric behaviour.= But it=E2=80=99s an implementation nightmare to do this measurement especi= ally because we do not know which neighbour we might end up tieing up with = (thus need to probe all neighbours). It will add up so much to the control = overhead and also requires (a good deal of) state info to be maintained on = behalf of the neighbouring nodes.

Anyways i tried to search for your implemen= tation to check on this but i could not find it.

b. Use of past conditions to suggest future= traffic path selection:

=E2=80=9CIf the RREQ-Instance arrives over an interfac= e that is not known to=C2= =A0be symmetric, or is known to be asymmetric, the 'S'= ; bit is set to be 0.=E2=80=9D

This is a typical problem we face as well. = Probing for measurements at such scale (all neighbours) is a problem. If yo= u do the probing sparsely, the network conditions might have changed when y= ou want to use the measurements.

Other points:

  1. Use of odd/even numbers for pa= iring instances may not be a robust way of pairing =E2=80=A6 There could be= race conditions where other P2P-RPL instances or floating DODAG instances = end up using one of the same value in the instance-id pair. How to resolve = such collision?
  2. I would recommend to use Cooja= with links in DGRM mode to evaluate the perf.
  3. The RSSI values in the Appendi= x do not look correct. An RSSI of <-70dbm is too good [1] to have for go= od PDR. The mapping of RSSI-ETX in the appendix hence may not be correct (i= believe these values are from Cooja).

[1]=C2=A0 RSSI is Under-Appreciated https://sing.stanford.edu/si= te/publications/emnets2006srinivasan.pdf


Regards,

Rahul


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




--
=











With Regards= ,
Dr. Satish Anamalamudi, PhD.,

--94eb2c05b69a860ebd055e55af2a-- From nobody Sun Nov 19 07:15:29 2017 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0F2C126D46 for ; Sun, 19 Nov 2017 07:15:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 gtoRyGrLq2PG for ; Sun, 19 Nov 2017 07:15:24 -0800 (PST) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 7A7EF126DED for ; Sun, 19 Nov 2017 07:15:23 -0800 (PST) Received: by mail-wm0-x229.google.com with SMTP id x63so1551435wmf.4 for ; Sun, 19 Nov 2017 07:15:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=Nsy77PT7XQenOKpkOdq6C3x28La6slVVtF4DG3izPTI=; b=SpqGHai7xRC2SnpjAv9/z3PLejspVhj1bhfgPa5F1k+/7EhPCpgR3Y3lwa7jzUEeP0 MYvVhZC6pjNkkR9AvUnlqWnwd8EoeBOwDpirb1n88sY11ChcEu5xEBx0L/8jc3Pc37P0 xgoPoYR+fmKP7KC2hL/E7FiRv8r3h2qThmHln8Jfmibira5DDnJpQN/7ToEX0j+2fnKc /d9oGn6yF9+aTbkr3MbVUBwvQImwuZ3yuJyNGm45x5887Q33R4Fsu3pf6jm+o4X9msef ePOcJNFLpjqA3o00lK3Ad/qew7e2HmSbyoLuQ1MIEGoQjPKx5yrbgB53S1jwWy9HAL8x p2mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=Nsy77PT7XQenOKpkOdq6C3x28La6slVVtF4DG3izPTI=; b=ETco3Lxgfc+0tka4nseEmacogBPJ7SDg7m6IICkvgw9wh8YHiEPnr8XL9mxk1KMr4v 1W7XC4WmXViLDFpZcQYjG9O50UxCrTYqUSdCEx0aInvLsvZJyYvPAP1Zr6XGHRqc7r/z DeIwLqs6lEQyn5jCfTL13Ja+X7nXfdxg527WUdwe3TNwlUKGDVt6GKbcjOdcbbM1pR28 Iw4PMSPtAJ1JtpZouAKBQt39pkO4/WWZDMrXAacUn6ghxxBA806iaJbbU+9EX9wqUJVa r4IEqi4GhVghNe1TbUGXguEJ2ZWVbDfZE8ul4AEMDFZTAEibPYDdfR+6wcxslEsALMhm u5fQ== X-Gm-Message-State: AJaThX7s9anOk5azx87kfV4kAT6LHNixLtqxvFF+6GK4hojBFHc3zy6C oqQEABsIsFEoyq8+OGrzN2P98Eil3LBdrYWk7bU= X-Google-Smtp-Source: AGs4zMYXegzbtsOY9d65g51OlPUm82qd16LWKdkiluV6bICSk+74+kqZLA23jGnKk0VXT9AqtCF6cUvGumqxhSJ91zs= X-Received: by 10.80.194.145 with SMTP id o17mr15627545edf.59.1511104521593; Sun, 19 Nov 2017 07:15:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.142.4 with HTTP; Sun, 19 Nov 2017 07:15:20 -0800 (PST) In-Reply-To: References: From: Rahul Jadhav Date: Sun, 19 Nov 2017 20:45:20 +0530 Message-ID: To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary="94eb2c1cd9f43a66c1055e577016" Archived-At: Subject: Re: [Roll] Review of AODV-RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Nov 2017 15:15:28 -0000 --94eb2c1cd9f43a66c1055e577016 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Please find my comments inline [RJ]. Regards, Rahul On 19 November 2017 at 18:39, satish anamalamudi wrote: > Hello Rahul, > > Thanks a lot for the review and comments on AODV-RPL. Please see my > response to your comments in [SA]. > > With regards > > Satish. > > Following is my review of AODV-RPL. > > One of the stated goal of AODV-RPL is to cater to asymmetric links. While > this is really great to have, I have doubts that the current specificatio= n > achieves it in a practical way. Foll is the reasoning: > > 1. The Messaging: > > AODV-RPL requires that you send a multicast message from OrigNode to > TargNode and realise a routing path in the opposite direction. > > For e.g. A -> B -> C -> D, A sends a RREQ-Instance message towards D and > nodes B,C,D establish routing adjacencies in the opposite direction. This > kind of messaging is the reason why RPL depends on bidirectional links fo= r > control/data paths. > > [SA] Yes Rahul. The control messages(RREQ, RREP) and application data > transmission is in the opposite direction for AODV-RPL. We are checking f= or > the bi-directional asymmetry > > [RJ] I did not understand how this checking happens. Based on what i read, the draft says that this checking (i.e detection of bidirectional asymmetry) is left upto implementation. And my point is that it is non-trivial, albeit impractical to do it for constrained networks especially the way draft words it. > during control message broadcast and initiates another multicast RREQ fro= m > destination whenever there is link asymmetry from Source to Destination. > > 2. The Assumptions: > > a. Quoting draft, > > =E2=80=9CEach intermediate node R_i computes the rank for RREQ-Instance a= nd > creates a routing table entry for the upstream route towards the source > if the routing metrics/constraints are satisfied. For this purpose R_i > ***must use the asymmetric link metric measured in the upstream > direction***, from R_i to its upstream neighbor that multicasted the > RREQ-Instance message.=E2=80=9D > > This is the primary assumption which achieves asymmetric behaviour. But > it=E2=80=99s an implementation nightmare to do this measurement especiall= y because > we do not know which neighbour we might end up tieing up with (thus need = to > probe all neighbours). It will add up so much to the control overhead and > also requires (a good deal of) state info to be maintained on behalf of t= he > neighbouring nodes. > > Anyways i tried to search for your implementation to check on this but i > could not find it. > > [SA] In fact, the AODV-RPL draft is not intended to check how the links > are going to be symmetric (or) asymmetric. The objective of our draft is > when the link is bidirectional asymmetric then how the AODV-RPL protocol > handles the scenarios of asymmetric bi-directional links. > > [RJ] The draft talks about establishing asymmetric paths and leaves the critical asymmetric detection part out of scope. My point is, the draft currently relies on some mechanism which is impractical and further builds a signalling mechanism on top of it. > Please check the below link for the implementation of asymmetric AODV-RPL > in Cooja Simulator. > > https://github.com/lavanyahm/Contiki_AODVRPL > > [RJ] Thank you this link. After skimming through the implementation i understand that the node defines the uplink ETX based on RREQ multicast message signal strength. This is not realistic. Consider if the upstream node is transmitting at a higher power. The downstream node will receive the signal with good RSSI and it will infer (incorrectly) that the upstream connectivity (ETX) is good as well. > > b. Use of past conditions to suggest future traffic path selection: > > =E2=80=9CIf the RREQ-Instance arrives over an interface that is not known= to be > symmetric, or is known to be asymmetric, the 'S' bit is set to be 0.=E2= =80=9D > > This is a typical problem we face as well. Probing for measurements at > such scale (all neighbours) is a problem. If you do the probing sparsely, > the network conditions might have changed when you want to use the > measurements. > > [SA] Yes, this is indeed a good problem in itself which calls for a > separate draft exploring alternate methods. In the literature, one comes > across several techniques being proposed that include active and passive > probing techniques, radio sniffing, statistical channel estimation > methods, message passing, and other energy efficient techniques. In > AODV-RPL, we assume that the link property is obtained through some > means, and do not recommend any specific method to come with the > symmetric and asymmetric link property. > > [RJ] All the above techniques are good in specific context. Can you have an implementation consideration section in the draft which talks about how to use any of these techniques especially considering that the probe neighbour set is open-ended? > Other points: > > 1. Use of odd/even numbers for pairing instances may not be a robust way > of pairing =E2=80=A6 There could be race conditions where other P2P-RPL i= nstances > or floating DODAG instances end up using one of the same value in the > instance-id pair. How to resolve such collision? > > [SA] In order to establish the upstream route from TargNode to OrigNode, > OrigNode multicasts the RREQ-Instance message to its one-hop neighbours. > In order to enable intermediate nodes R_i to associate a future RREP > message to an incoming RREQ message, the RREQ message MUST assign an odd > number for the OrigNode's Dest SeqNo which is included in the RREQ messag= e. > When an intermediate node R_i receives a RREQ message in storing mode, it > MUST store the OrigNode's Dest Seqno along with the other routing > information needed to establish the route back to the OrigNode. This wil= l > enable R_i to determine that a future RREP message (containing a paired > Dest Seqno for the TargNode) must be transmitted back to the OrigNode's I= P > address. > > 'T' bit (DIO-RREP option): 'T' is set to true to indicate that the > TargNode IPv6 Address field is present. > > TargNode IPv6 Address (when present) : IPv6 address of the TargNode tha= t > receives RREP-Instance message. In order to reduce the need for the > TargNode IPv6 Address to be included with the RREP message, the Dest SeqN= o > of the RREP is paired, whenever possible, with the Dest SeqNo from the RR= EQ > message, which is always an odd number. The pairing is accomplished by > adding one to the Dest Seqno from the RREQ message and using that, whenev= er > possible, as the Dest Seqno for the RREP message. If this is not possibl= e > (for instance because the incremented sequence number is still a valid > sequence number for another route to the TargNode from an earlier Route > Discovery operation), then the 'T' bit is set and an odd number is chosen > for the TargNode's Dest SeqNo. > [RJ] This whole explanation talks about setting odd number in Dest SeqNo. The draft does not assign an odd number to seq numbers. (Pls point me to appropriate section if it does). I mentioned about odd-numbered instanceID and not seqno. InstanceIDs are paired between RREQ/RREP instances based on this odd-numbered InstanceID scheme which in my opinion is fragile (has issues with race-conditions which i mentioned before) > > 2. I would recommend to use Cooja with links in DGRM mode to evaluate the > perf. > > [SA] Please, check the above github link. We too used the DGRM mode to > evaluate the performance of AODV-RPL. > [RJ] In DGRM mode, if you maintain a link pair (lets say A -- B) where only A could transmit to B but B cannot transmit to A, the implementation wont work. What i m trying to say is, merely using DGRM mode does not help. DGRM mode allows Cooja to define asymmetric links but you still need to further define realistic parameters for DGRM mode without depending on the default values. The RSSI values in the Appendix do not look correct. An RSSI of <-70dbm is > too good [1] to have for good PDR. The mapping of RSSI-ETX in the appendi= x > hence may not be correct (i believe these values are from Cooja). > [SA] Yes, we considered the appendix values based on the experiments in > Cooja simulator. > [RJ] The values in the appendix are incorrect and misleading. Cooja simulator RSSI values are incorrect and you should not use cooja simulator to get these values. Please refer to the other reference "RSSI is under appreciated" to understand how practical RSSI values look. > > On Thu, Nov 16, 2017 at 12:57 PM, Rahul Jadhav > wrote: > >> Following is my review of AODV-RPL. >> >> One of the stated goal of AODV-RPL is to cater to asymmetric links. Whil= e >> this is really great to have, I have doubts that the current specificati= on >> achieves it in a practical way. Foll is the reasoning: >> >> 1. The Messaging: >> >> AODV-RPL requires that you send a multicast message from OrigNode to >> TargNode and realise a routing path in the opposite direction. >> >> For e.g. A -> B -> C -> D, A sends a RREQ-Instance message towards D and >> nodes B,C,D establish routing adjacencies in the opposite direction. Thi= s >> kind of messaging is the reason why RPL depends on bidirectional links f= or >> control/data paths. >> >> 2. The Assumptions: >> >> a. Quoting draft, >> >> =E2=80=9CEach intermediate node R_i computes the rank for RREQ-Instance = and >> creates a routing table entry for the upstream route towards the source >> if the routing metrics/constraints are satisfied. For this purpose R_i >> ***must use the asymmetric link metric measured in the upstream >> direction***, from R_i to its upstream neighbor that multicasted the >> RREQ-Instance message.=E2=80=9D >> >> This is the primary assumption which achieves asymmetric behaviour. But >> it=E2=80=99s an implementation nightmare to do this measurement especial= ly because >> we do not know which neighbour we might end up tieing up with (thus need= to >> probe all neighbours). It will add up so much to the control overhead an= d >> also requires (a good deal of) state info to be maintained on behalf of = the >> neighbouring nodes. >> >> Anyways i tried to search for your implementation to check on this but i >> could not find it. >> >> b. Use of past conditions to suggest future traffic path selection: >> >> =E2=80=9CIf the RREQ-Instance arrives over an interface that is not know= n to be >> symmetric, or is known to be asymmetric, the 'S' bit is set to be 0.=E2= =80=9D >> >> This is a typical problem we face as well. Probing for measurements at >> such scale (all neighbours) is a problem. If you do the probing sparsely= , >> the network conditions might have changed when you want to use the >> measurements. >> >> Other points: >> >> 1. Use of odd/even numbers for pairing instances may not be a robust >> way of pairing =E2=80=A6 There could be race conditions where other P= 2P-RPL >> instances or floating DODAG instances end up using one of the same va= lue in >> the instance-id pair. How to resolve such collision? >> 2. I would recommend to use Cooja with links in DGRM mode to evaluate >> the perf. >> 3. The RSSI values in the Appendix do not look correct. An RSSI of >> <-70dbm is too good [1] to have for good PDR. The mapping of RSSI-ETX= in >> the appendix hence may not be correct (i believe these values are fro= m >> Cooja). >> >> >> [1] RSSI is Under-Appreciated https://sing.stanford.edu/site >> /publications/emnets2006srinivasan.pdf >> >> >> Regards, >> >> Rahul >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> >> > > > -- > > > > > > > > > > > > *With Regards,* > > *Dr. Satish Anamalamudi, PhD.,* > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > --94eb2c1cd9f43a66c1055e577016 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Please find my comments inline [RJ].
Re= gards,
Rahul

On 19 November 2017 at 18:39, satish anamalamudi <satishn= aidu80@gmail.com> wrote:

Hello Rah= ul,

Thanks a lot for the review and comments on AODV-RPL. Pleas= e see my response to your comments in [SA].

With regards=

Satish.

Following is my review of AODV-RPL.

One of the stated goal of A= ODV-RPL is to cater to asymmetric links. While this is really great to have= , I have doubts that the current specification achieves it in a practical w= ay. Foll is the reasoning:

  1. The Messaging:=

AODV-RPL requires that you se= nd a multicast message from OrigNode to TargNode and realise a routing path= in the opposite direction.= =C2=A0

For e.g. A -> B -> C -> D= , A sends a RREQ-Instance message towards D and nodes B,C,D establish routi= ng adjacencies in the opposite direction. This kind of messaging is the rea= son why RPL depends on bidirectional links for control/data paths.

[SA]=C2= =A0Yes Rahul. The control messages(RREQ, RREP) and application data transmi= ssion is in the opposite direction for AODV-RPL. We are checking for the bi= -directional asymmetry

[RJ]= I did not understand=C2=A0 how this checking happens. Based on what i read= , the draft says that this checking (i.e detection of bidirectional asymmet= ry) is left upto implementation. And my point is that it is non-trivial, al= beit impractical to do it for constrained networks especially the way draft= words it.

during control message broadcast a= nd initiates another multicast RREQ from destination whenever there is link= asymmetry from Source to Destination.=C2=A0

<= /blockquote>

2. The Assumptions:

<= blockquote style=3D"font-size:12.8px;margin:0px 0px 0px 40px;border:none;pa= dding:0px">

a. Quoting draft,=C2=A0

=

=E2=80=9CEach intermediate node R_i computes= the rank for RREQ-Instance and creates a routing table entry for the upstr= eam route towards the=C2=A0source if the routing metrics/constraints are satisfied.=C2=A0=C2=A0For this purpose R_i ***= must use the asymmetric link metric measured in the upstream direction***, = from R_i to its upstream neighbor that multicasted the RREQ-Instance messag= e.=E2=80=9D

Anyways i tried to search for your implementation to check on this but= i could not find it.

[SA]=C2=A0In fact, the AODV-RPL draft is not intended= to check how the links are going to be symmetric (or) asymmetric. The obje= ctive of our draft is when the link is bidirectional asymmetric then how th= e AODV-RPL protocol handles the scenarios of asymmetric bi-directional link= s.=C2=A0

[RJ] The draft talk= s about establishing asymmetric paths and leaves the critical asymmetric de= tection part out of scope. My point is, the draft currently relies on some = mechanism which is impractical and further builds a signalling mechanism on= top of it.

Please check the below link for = the implementation of asymmetric AODV-RPL in Cooja Simulator.

https://github.com/la= vanyahm/Contiki_AODVRPL

=
[RJ] Thank you this link. After skimming through the implementation i = understand that the node defines the uplink ETX based on RREQ multicast mes= sage signal strength. This is not realistic. Consider if the upstream node = is transmitting at a higher power. The downstream node will receive the sig= nal with good RSSI and it will infer (incorrectly) that the upstream connec= tivity (ETX) is good as well.


= b. Use of past conditions to suggest future traffic path selection:<= br>

=C2=A0be symmetric,= or is known to be asymmetric, the 'S' bit is set to be 0.=E2=80=9D=

This is a= typical problem we face as well. Probing for measurements at such scale (a= ll neighbours) is a problem. If you do the probing sparsely, the network co= nditions might have changed when you want to use the measurements.

[SA]=C2= =A0=C2=A0Yes, this is indeed a good problem in itself which calls for a sep= arate=C2=A0draft exploring alternate methods. In the literature, one comes = across several=C2=A0techniques bein= g proposed that include active and passive probing techniques,=C2=A0= radio sniffing, statistical channel estima= tion methods, message passing, and=C2=A0other energy efficient techniques. In AODV-RPL, we assume that the lin= k property=C2=A0is obtained through= some means, and do not recommend any specific method to come=C2=A0<= span style=3D"font-size:12.8px">with the symmetric and asymmetric link prop= erty.

[RJ] All the above tec= hniques are good in specific context. Can you have an implementation consid= eration section in the draft which talks about how to use any of these tech= niques especially considering that the probe neighbour set is open-ended?= =C2=A0

Other points:

1. Use of odd/even numbers for pairing i= nstances may not be a robust way of pairing =E2=80=A6 There could be race c= onditions where other P2P-RPL instances or floating DODAG instances end up = using one of the same value in the instance-id pair. How to resolve such co= llision?

[SA]=C2=A0In order to establish the upstream route from TargNode to OrigNo= de,=C2=A0 OrigNode multicasts the RREQ-Instance message to its one-hop neig= hbours.=C2=A0 In order to enable intermediate nodes R_i to associate a futu= re RREP message to an incoming RREQ message, the RREQ message MUST assign a= n odd number for the OrigNode's Dest SeqNo which is included in the RRE= Q message. When an intermediate node R_i receives a RREQ message in storing= mode, it MUST store the OrigNode's Dest Seqno along with the other rou= ting information needed to establish the route back to the OrigNode.=C2=A0 = This will enable R_i to determine that a future RREP message (containing a = paired Dest Seqno for the TargNode) must be transmitted back to the OrigNod= e's IP address.

'T' bit (DIO-RREP option):=C2=A0 'T' is set to = true to indicate that the TargNode IPv6 Address field is present.

TargNode IPv6 Add= ress=C2=A0 (when present) :=C2=A0 IPv6 address of the TargNode that receive= s RREP-Instance message. In order to reduce the need for the TargNode IPv6 = Address to be included with the RREP message, the Dest SeqNo of the RREP is= paired, whenever possible, with the Dest SeqNo from the RREQ message, whic= h is always an odd number.=C2=A0 The pairing is accomplished by adding one = to the Dest Seqno from the RREQ message and using that, whenever possible, = as the Dest Seqno for the RREP message.=C2=A0 If this is not possible (for = instance because the incremented sequence number is still a valid sequence = number for another route to the TargNode from an earlier Route Discovery op= eration), then the 'T' bit is set and an odd number is chosen for t= he TargNode's Dest SeqNo.


<= div>[RJ] This whole explanation talks about setting odd number in Dest SeqN= o. The draft does not assign an odd number to seq numbers. (Pls point me to= appropriate section if it does).
I mentioned about odd-numbered = instanceID and not seqno. InstanceIDs are paired between RREQ/RREP instance= s based on this odd-numbered InstanceID scheme which in my opinion is fragi= le (has issues with race-conditions which i mentioned before)=C2=A0


<= /p>

2. I would reco= mmend to use Cooja with links in DGRM mode to evaluate the perf.

=

[SA]=C2=A0Please, = check the above github link. We too used the DGRM mode to evaluate the perf= ormance of AODV-RPL.

[RJ] In DGRM mode, i= f you maintain a link pair (lets say A -- B) where only A could transmit to= B but B cannot transmit to A, the implementation wont work. What i m tryin= g to say is, merely using DGRM mode does not help. DGRM mode allows Cooja t= o define asymmetric links but you still need to further define realistic pa= rameters for DGRM mode without depending on the default values.
<= br>
<= p class=3D"m_4808448981297649739gmail-m_-7354843324401384222gmail-m_-570058= 0772172137514gmail-p1">The RSSI values in = the Appendix do not look correct. An RSSI of <-70dbm is too good [1] to = have for good PDR. The mapping of RSSI-ETX in the appendix hence may not be= correct (i believe these values are from Cooja).

[SA= ]=C2=A0Yes, we considered the appendix values based on the experiments in C= ooja simulator.

[RJ] The values= in the appendix are incorrect and misleading. Cooja simulator RSSI values = are incorrect and you should not use cooja simulator to get these values. P= lease refer to the other reference "RSSI is under appreciated" to= understand how practical RSSI values look.
=C2=A0

On Thu, Nov 16, 2017 at 12:57 PM, Rahul Jadhav = <rahul.ietf@gmail.com> wrote:

Following i= s my review of AODV-RPL.

One of the = stated goal of AODV-RPL is to cater to asymmetric links. While this is real= ly great to have, I have doubts that the current specification achieves it = in a practical way. Foll is the reasoning:

  1. The Messa= ging:

AODV-RPL requires that= you send a multicast message from OrigNode to TargNode and realise a routi= ng path in the opposite direction.=C2=A0

For e.g. A -> B ->= C -> D, A sends a RREQ-Instance message towards D and nodes B,C,D estab= lish routing adjacencies in the opposite direction. This kind of messaging = is the reason why RPL depends on bidirectional links for control/data paths= .

2. T= he Assumptions:

a. Quoting draft,=C2= =A0

=E2=80=9CEach= intermediate node R_i computes the rank for RREQ-Instance and creates a ro= uting table entry for the upstream route towards the=C2=A0<= /span>source if the routing metrics/constraints are satisfied.=C2=A0 For this purpose R_i ***must use the asymmetric link met= ric measured in the upstream direction***, from R_i to its upstream neighbo= r that multicasted the RREQ-Instance message.=E2=80=9D

This is the p= rimary assumption which achieves asymmetric behaviour. But it=E2=80=99s an = implementation nightmare to do this measurement especially because we do no= t know which neighbour we might end up tieing up with (thus need to probe a= ll neighbours). It will add up so much to the control overhead and also req= uires (a good deal of) state info to be maintained on behalf of the neighbo= uring nodes.

Anyways i tried to sea= rch for your implementation to check on this but i could not find it.

b. Use of past conditi= ons to suggest future traffic path selection:

=E2=80=9CIf the RREQ-Instance arr= ives over an interface that is not known to=C2=A0be symmetric, or is known to be asymmetric, the 'S' bit is set t= o be 0.=E2=80=9D

This is a typical prob= lem we face as well. Probing for measurements at such scale (all neighbours= ) is a problem. If you do the probing sparsely, the network conditions migh= t have changed when you want to use the measurements.

Other point= s:

  1. Use of od= d/even numbers for pairing instances may not be a robust way of pairing =E2= =80=A6 There could be race conditions where other P2P-RPL instances or floa= ting DODAG instances end up using one of the same value in the instance-id = pair. How to resolve such collision?
  2. I would r= ecommend to use Cooja with links in DGRM mode to evaluate the perf.
  3. The RSSI = values in the Appendix do not look correct. An RSSI of <-70dbm is too go= od [1] to have for good PDR. The mapping of RSSI-ETX in the appendix hence = may not be correct (i believe these values are from Cooja).
<= br>

[1]=C2= =A0 RSSI is Under-Appreciated https://sing.stanford.= edu/site/publications/emnets2006srinivasan.pdf<= /p>


<= p class=3D"m_4808448981297649739m_1582040862837549873gmail-p3">Regards,

=

Rahul


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




--
<= div class=3D"m_4808448981297649739gmail_signature" data-smartmail=3D"gmail_= signature">

=




=




=
With Regards,
Dr. = Satish Anamalamudi, PhD.,


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


--94eb2c1cd9f43a66c1055e577016-- From nobody Fri Nov 24 02:22:04 2017 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B526612751F for ; Fri, 24 Nov 2017 02:22:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.204 X-Spam-Level: * X-Spam-Status: No, score=1.204 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, FSL_HELO_BARE_IP_2=1.499, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ZUzDgrpGuV3M for ; Fri, 24 Nov 2017 02:22:02 -0800 (PST) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e: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 54756126C19 for ; Fri, 24 Nov 2017 02:22:02 -0800 (PST) Received: by mail-pg0-x232.google.com with SMTP id q7so2561832pgr.8 for ; Fri, 24 Nov 2017 02:22:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:message-id:date:to:mime-version :content-transfer-encoding; bh=8aVm08sJ0q6hdpQQCgn48YbTvbU6oYYwbuCy5AzMQQg=; b=f3AxOPrR+ERe+0Li8zWgEVY4KHa6Hx6iSEDhfni86IezuRAdVsa8NSOt4Dkd1fJYso JBr/oB1KuMyFrEX3C6HZVeRh7BTP2+fp0cYSvLgg7PrNP86IXT3454X2TgbNk5nHtyva U9jt2gxquWmJub1vgY6gN+eL+MhB95ccsWxDuUtz+PVUV4oXX3wUYuAM1GyCaspNH8W7 eVClzl/BecHpSWWBPKGrWlilIXRwWzrV3eoBGHQNRe1rhXfScf+iakBu6pkC1+GQ+Yjl lZkcm5r5hvOS7YNoMKAIqJOrh6PxNTEajTYBjGmGLXSayjZv3Kig1n2qWqYehSbd4tTn BNhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:message-id:date:to:mime-version :content-transfer-encoding; bh=8aVm08sJ0q6hdpQQCgn48YbTvbU6oYYwbuCy5AzMQQg=; b=Ea3dxKqtTTtW51VBOIqee2Beb9hxIHAnrlPdH+e1ZU8CzWSwF6I6PwPkxEsiY8epWF SguqbFIDJD2A/Yd3TWYei+PaRy5Bg2hn3H1e8sQxXx8Pf6+UOiCTqyOUC2586BtxnGse sIG9lK7KE2hleenS0zBw0Y9FWp7ljR81GGq8U5R1wM7gxyqBeNYjy1RqJvNkMpaD9L+z h4wRmoTm0HaemPLn3p7JCvRhvs+WO8mAzqUdrNJTppnm73A9Hbnb8Ey34gbsS+rLELqe NwNKWcr+adKGvWUDPfJR64X3wsppcK90lQiFDaWhKPiCJUZ5ShQgnn546OwI5Xxhz1TJ JZfQ== X-Gm-Message-State: AJaThX4NIwWltJ1gPEWM9xKvFad15VvrWYaSEvTG8a4OQtm3jp/Wnk/P D1DbyAZQyuioD+BC/DI5P92MGPvP X-Google-Smtp-Source: AGs4zMZzV4P4gW4UZzlpU4l1uSA8wzhdW4XjtttV5048MmyeZnmrV/69jcW3oHNAfvH0Gsl8evScZg== X-Received: by 10.99.5.1 with SMTP id 1mr26892069pgf.183.1511518921490; Fri, 24 Nov 2017 02:22:01 -0800 (PST) Received: from 10.33.245.183 ([103.211.228.150]) by smtp.gmail.com with ESMTPSA id x11sm13532402pge.16.2017.11.24.02.21.59 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Nov 2017 02:22:00 -0800 (PST) From: Rahul Jadhav Message-ID: <71EA7FB9-8BDA-4371-98F5-591803AC6450@gmail.com> Date: Fri, 24 Nov 2017 18:21:57 +0800 To: "roll@ietf.org" X-Mailer: NetEase iOS Mail 6.0.6.1127 [iPhone 7 iOS11.1.2] MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [Roll] Review of useofrplinfo-19 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Nov 2017 10:22:04 -0000

The chang= e of RPI option type has really helped to make things more easier to unde= rstand. Also, compared to the ver i previously reviewed, this ver has imp= roved a lot in terms of structure and wordings. Thank you for the efforts= .

=46= ollowing are my review comments categorized as technical/editorial:

 

-----=5BTech= corrections/suggestions=5D-----

Section 3.1:

=22It is suggested that implement= ations

= accept both 0x63 and 0x23 when processing.  When forwarding pa= ckets,

= implementations SHOULD use the same value as it was received. = When

<= span style=3D=22-webkit-tap-highlight-color: rgba(26, 26, 26, 0.301961); = -webkit-text-size-adjust: auto; background-color: rgba(255, 255, 255, 0);= =22>originating new packets, implementations SHOULD have an option to

det= ermine which value to originate with, this option is controlled by=

the DIO o= ption described below.=22

=5BRJ=5D: Regarding pkt fwding, it is mentioned that= implementations should continue using the same option type that was rcvd= in incoming pkt. Is there any specific reason for this behaviour=3F The = reason why i ask this is, using this flag one can infer nodes that are no= t upgraded, and this may have security implications especially with RPI b= een sent out on Internet.

 

Section 3.3:

       &n= bsp;        =22In case of rebooting, t= he DIO is sent with flag indicating the new

      =           RPI value.=22

=5BRJ=5D: Di= dn't understand why this should be stated. BR/Node reboot should not impa= ct the choice of this flag, imo.

 

Section 4:

      &= nbsp;         =22A RPL network in= general is composed of a 6LBR (6LoWPAN Border

   Router), Backbone= Router (6BBR), 6LR (6LoWPAN Router) and 6LN

   (6LoWPAN Node) as= leaf logically organized in a DODAG structure.=22

=5BRJ=5D: Why 6BBR in gener= al case=3F Anyways the corresponding topology diagram (fig 6) below does = not has 6BBR.

 

Section 4:

          &nb= sp;     =22The 6LN is a RPL aware router, or host.

&n= bsp;  But, the 6LN leaves (Raf - =22RPL aware leaf=22-) marked as (=46= , H and I)

   are RPL nodes with no children hosts.=22

=5BRJ=5D: Shou= ld the first line be, =22The 6LN is a RPL aware leaf node or host.=22, bu= t then it is redundant with the subsequent stmt.

 

Section 6:

    =             =22In = storing mode (fully stateful), the sender can determine if the

  = destination is inside the LLN by looking if the destination address

&nbs= p;  is matched by the DIO's PIO option.=22

=5BRJ=5D: It is not necessary = that the LLN will have RPL-aware-nodes addressed only using DIO's PIO. Wh= at happens if the dst RPL node has an IPv6 address not using this PIO=3F = RPL does allow this. In storing mode i see no issues because the handling= remains same, but for non-storing mode there may be implications.=

 =

Section 6.2.3= :

&nb= sp;           &nbs= p;   =22The 6LR=5F1 (i=3D1) node will add an IP-in-IP(RPI) head= er addressed

   either to the root, or hop-by-hop such that the= root can remove the

   RPI header before passing upwards. = ; (EDNOTE: we SHOULD recommend one

   or the other)=22

=5BRJ=5D: Lin= gering EDNOTE... I like using IP-in-IP destined to root (because its rela= tively less processing overhead=21), but hop-by-hop has its own advantage= . The advantage is, If there is RPL aware node with a DAO-advertised IPv6= address not using the DIO-advertised network prefix in PIO, then the rou= ting would be faster/more efficient (since 6LR=5Fi would be able to remov= e IP-in-IP and check the routing table for the dst in underlying IP hdr).=

&nbs= p;

Se= ction 6.2.3:

           &= nbsp;    =22The originating node will ideally leave the IP= v6 flow label as zero

   so that the packet can be better compre= ssed through the LLN.  The

   6LBR will set the flow label= of the packet to a non-zero value when

   sending to the Inter= net.=22

=5BRJ=5D: The 6LBR is going to strip off the IP-in-IP(RPI) in this case.= Why the stmt, =226LBR will set the flow label of the packet to a non-zer= o...=22=3F

<= font color=3D=22=23000000=22 face=3D=22-webkit-standard=22 size=3D=223=22= > 

-----=5BEditorial= fixes=5D-----

Section 3.3:

compatibilit =3D> compatibility

 

Section 3.3:

=

   &nbs= p;            =22T= he DODAG Configuration Option is as follows.  The =46lag field is th= e

&nb= sp;           &nbs= p;   interesting field.  The remaining fields states as de= fined in

            =     =5BR=46C6550=5D.=22

=5BRJ=5D: This para needs to be reworde= d. Suggesting,

           &= nbsp;    =22The DODAG Configuration Option has a =46lags f= ield which is modified by this document. Currently, the DODAG Configurati= on Option in =5BR=46C6550=5D is as follows.=22

 

Section 4:

    &nb= sp;           =22A RPL = Stack is showed in =46igure 1.=22

=5BRJ=5D: A RPL Stack is showed in =46igure = 5.

&n= bsp;

S= ection 6:

=            &n= bsp;    =22In all cases the RH3 is not need because...=22<= /span>

=5BRJ=5D = In all cases the RH3 is not needed because...

 

Section 7.1.2:

<= p class=3D=22MsoNormal NE-CH-HEIGHT=22 style=3D=22text-indent: 0px; curs= or: pointer; margin: 0cm 0cm 0.0001pt;=22>=227.1.2.  on-SM:=22=

=5BR= J=5D =227.1.2.  Non-SM:=22


Regards,
Rahul 
=20 =20 From nobody Sun Nov 26 19:47:02 2017 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2EAC126B7E; Sun, 26 Nov 2017 19:46:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 AqVSjtGXzrDZ; Sun, 26 Nov 2017 19:46:53 -0800 (PST) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::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 104C81205D3; Sun, 26 Nov 2017 19:46:53 -0800 (PST) Received: by mail-pf0-x22f.google.com with SMTP id r14so10275618pfl.11; Sun, 26 Nov 2017 19:46:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:cc:references:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=b+E/h92+SqZYEkRaXhFKGCc9LGqaPmFi9VVYbQMMVwg=; b=D7j8PuAMffgnfUFjmF+btp8D4Iy1Eouoxtgm6XfOzgvxesO2q+70QZ/mYw458Dev5g 4Z6yoxRnRC3W/ogHJ/1++P649iiNB+0gsbuuVNzknY/s3QB6CWNfzwtcOR5IDYvvx4lN +VD964/d70bgfdZEZL6W4LfTfDQMcGMDYfxYdo29QvQSyyEvLMZukwuiXigQHSzIkJfO h6LT/3ZF3y4bNnOoGliEAFnHbdZ+FJrPAjAn5afDTCciY8ON15v5avxFNhRYhpKkTrM5 fzUjM8mV4ZIzCTu0WYCw3/u7mkd6Nkbnp/uLX251xnEmMejN1n7QeYFwENfMY/OCbULs W1GQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=b+E/h92+SqZYEkRaXhFKGCc9LGqaPmFi9VVYbQMMVwg=; b=q5rKYhR53IXS+ycXS6LalFqcbba1A/mUEq4YfyRbN7Ne6v9g7Ij3W5WPkebxIQYoC/ VK9ls/50N+C8sBf/5dFJ9GnCb2gqw4pdphDTzHmRrsiiOujdsF1j9qNWfXi+OLccRzT+ 0inN3TMCxuLdwTLPJly/zcYQOgsr5bKU6VCyXXZ6hVjhK0dZXOhMxICde7qrpiLJr2CK zgUr1RxlMhm/4kxPus3ncimaQxdiWcl1DHnzfY4Cofp1zUeorR/Z51gv8rik2TgleV8W 6bqK8ErJQKzsJ54x4bcOPXKbzk9ePIF/L0r4y+h3xKkixaL7uWYQCR7IUIVCmnenEkHs Ny1g== X-Gm-Message-State: AJaThX46AAaARkk7cT981d89LeXhvovRO7HPUMC+UupBnxkvQvX2w/Ti zTqjsMezYK42MIkvQPENngP9Dg== X-Google-Smtp-Source: AGs4zMYdfRPR2feAGl5noCKZhn44uhFP2ls78Z03UGK4hdR/aRIKPysSO+nZSujjFuGo6X0UH7dRTA== X-Received: by 10.98.99.68 with SMTP id x65mr18067510pfb.56.1511754412114; Sun, 26 Nov 2017 19:46:52 -0800 (PST) Received: from ?IPv6:2406:e007:6f17:1:28cc:dc4c:9703:6781? ([2406:e007:6f17:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id a13sm39035736pgq.10.2017.11.26.19.46.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Nov 2017 19:46:50 -0800 (PST) From: Brian E Carpenter To: consultancy@vanderstok.org, roll@ietf.org Cc: emarobl , Michael Richardson , 6man References: Organization: University of Auckland Message-ID: <1bc47bb5-46b3-1268-dbcc-98ee0795a015@gmail.com> Date: Mon, 27 Nov 2017 16:46:39 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Roll] [ROLL] WGLC of useof rplinfo X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Nov 2017 03:46:55 -0000 On 22/11/2017 21:56, peter van der Stok wrote: > I have a review request for you from the ROLL WG. > You previously reviewed useofrplinfo wrt how headers are > inserted. In the light of RFC8200 being published, could you access > whether > useofrplinfo is inline with the new guidance as part of the useofrplinfo > WGLC? > > Please post to the roll ML, and please cc 6man. > > Many thanks, > > peter I looked at the way the hop-by-hop option is redefined here, and the suggested use of IPv6-in-IPv6 encapsulation to attach the HbH option to packets. To me it seems consistent with RFC 8200. That's the only aspect I reviewed. A couple of nits: The phrases "IPv6-in-IPv6", "IP-in-IP" and "IPIP" occur pretty randomly and I think it's confusing. I suggest picking one, defining it carefully in section 2.1, and using it consistently. > 10. IANA Considerations > > This document updates the registration made in [RFC6553] Destination > Options and Hop-by-Hop Options registry from 0x63 to 0x23. > > > Hex Value Binary Value > act chg rest Description Reference > --------- --- --- ------- ----------------- ---------- > 0x23 00 1 00011 RPL Option [RFCXXXX] > 0x63 01 1 00011 RPL Option(DEPRECATED) [RFC6553][RFCXXXX] I don't think you can *tell* IANA to do this, because the whole 8 bits are allocated for a given use, not just the bottom 5. You can ask them to mark 0x63 as deprecated, and request a new 00 1 xxxxx option code. You can even suggest politely to assign 00 1 00011, but it's their decision. Regards Brian From nobody Wed Nov 29 12:32:47 2017 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8C8D1270A7 for ; Wed, 29 Nov 2017 12:32:46 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 E6xV87NRhyrs for ; Wed, 29 Nov 2017 12:32:45 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFD3D1200CF for ; Wed, 29 Nov 2017 12:32:44 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 29E2820008; Wed, 29 Nov 2017 15:35:15 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 2CBFE83C5D; Wed, 29 Nov 2017 15:32:44 -0500 (EST) From: Michael Richardson To: roll@ietf.org, "Rahul Jadhav" CC: Ines Robles In-Reply-To: References: <71EA7FB9-8BDA-4371-98F5-591803AC6450@gmail.com> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Roll] Fwd: Review of useofrplinfo-19 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 20:32:47 -0000 --=-=-= Content-Type: text/plain Thank you for the review! >>>>> "Rahul" == Rahul Jadhav writes: Rahul> [RJ]: Regarding pkt fwding, it is mentioned that implementations Rahul> should continue using the same option type that was rcvd in incoming Rahul> pkt. Is there any specific reason for this behaviour? The reason why i Rahul> ask this is, using this flag one can infer nodes that are not Rahul> upgraded, and this may have security implications especially with RPI Rahul> been sent out on Internet. By continuing to use the same option type that was received we do two things: 1) avoid changing packets mid-flight which RFC8200 says not to. 2) permit the network to be incrementally upgraded, and for the DODAG root to know which parts of the network are upgraded. (We also provided the flag and DIO configuration option, but it isn't clear to me that everyone will implement that or that it's even a good idea) Packets with the old 0x63 option are likely to be dropped by the Internet pre-RFC8200, so I don't see the problem. If you can see RPI header in the near term, I'd say that you are part of the Enterprise. Afterward, you will see only 0x23 options. I think that this transition will take many years. If knowing a node hasn't been upgraded lets you exploit it, then the exploit is already possible. There are many other upgrades that a node could have... Rahul> Section 3.3: Rahul> "In case of rebooting, the DIO is sent with flag indicating the new Rahul> RPI value." Rahul> [RJ]: Didn't understand why this should be stated. BR/Node reboot Rahul> should not impact the choice of this flag, imo. If a node has restarted, then it won't remember the flag. Rahul> Section 4: Rahul> "A RPL network in general is composed of a 6LBR (6LoWPAN Border Rahul> Router), Backbone Router (6BBR), 6LR (6LoWPAN Router) and 6LN Rahul> (6LoWPAN Node) as leaf logically organized in a DODAG structure." Rahul> [RJ]: Why 6BBR in general case? Anyways the corresponding topology Rahul> diagram (fig 6) below does not has 6BBR. "in general" ... there might be a 6BBR, but showing it is too cumbersome in the diagram and does not change anything. Rahul> Section 4: Rahul> "The 6LN is a RPL aware router, or host. Rahul> But, the 6LN leaves (Raf - "RPL aware leaf"-) marked as (F, H and I) Rahul> are RPL nodes with no children hosts." Rahul> [RJ]: Should the first line be, "The 6LN is a RPL aware leaf node or Rahul> host.", but then it is redundant with the subsequent stmt. That F, H and I have no children doesn't make them leaf (node) only. They are simply routers without children *at the moment*. Rahul> "In storing mode (fully stateful), the sender can determine if the Rahul> destination is inside the LLN by looking if the destination address Rahul> is matched by the DIO's PIO option." Rahul> [RJ]: It is not necessary that the LLN will have RPL-aware-nodes Rahul> addressed only using DIO's PIO. What happens if the dst RPL node has Rahul> an IPv6 address not using this PIO? RPL does allow this. In storing Rahul> mode i see no issues because the handling remains same, but for Rahul> non-storing mode there may be implications. If some node has an address which is not in the DIO's PIO prefix, then a naive other node will assume it is not in the LLN. That's the best heuristic we came up with to determine if the destination is in the LLN, and therefore RPL capable. Rahul> Section 6.2.3: Rahul> "The 6LR_1 (i=1) node will add an IP-in-IP(RPI) header addressed Rahul> either to the root, or hop-by-hop such that the root can remove the Rahul> RPI header before passing upwards. (EDNOTE: we SHOULD recommend one Rahul> or the other)" Rahul> [RJ]: Lingering EDNOTE... I like using IP-in-IP destined to root Rahul> (because its relatively less processing overhead!), but hop-by-hop has Rahul> its own advantage. The advantage is, If there is RPL aware node with a Rahul> DAO-advertised IPv6 address not using the DIO-advertised network Rahul> prefix in PIO, then the routing would be faster/more efficient (since Rahul> 6LR_i would be able to remove IP-in-IP and check the routing table for Rahul> the dst in underlying IP hdr). yes, you are right. Can you tell us why such a node would exist? What's the use case? Rahul> [RJ]: The 6LBR is going to strip off the IP-in-IP(RPI) in this case. Rahul> Why the stmt, "6LBR will set the flow label of the packet to a Rahul> non-zero..."? Because the flow-label is supposed to be non-zero when traffic enters the "Internet" -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlofGWsACgkQgItw+93Q 3WWIOQgAoEPh73vFt+nNRs7OSwn9+7EfbkT09+U0WRjBxm5Ogfzfs46j4Am0jjP1 huyzlYsigLTtZ8cavpoThlb6TzwAN+PBE0uLXlqpllYYKCYKh5+nIDuFy8HbJFeP 7vU/C9ceFRJ2rC7+/TFW/dGpM54bFQNRjMkfQO+2dF70edlGqj7fHja4d5qVup0N MfzJnEnTvlG9ttu1MVtx2rjns7rl82rQ8Ig0uw004U6wPMBjMemzHraDPH97/WFJ FXM8ui3hTCdpUEQOhh74VQmL9+xMH36+XgU8OqxoZ2ObZM2dk4WgNMcugXrHA4TR gWLdMG8VDj+f80cfw0ALZ7/PMz+kPg== =wtXv -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Nov 29 12:48:05 2017 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F6EF126BF6 for ; Wed, 29 Nov 2017 12:48:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 bS-XG2M4AaoA for ; Wed, 29 Nov 2017 12:48:01 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D52AD126CF9 for ; Wed, 29 Nov 2017 12:48:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20799; q=dns/txt; s=iport; t=1511988480; x=1513198080; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=h/2lr2gOrOE57/Mz5TWCQ8nTJo0u4TbOzSs7CNin8+o=; b=fQpgCsVarST6SRKU4PtApiX7WPN7lIkZFFKp9A3HQj+30MepOiB7YYjh XtwN+lyAEn8SrMkFjXmCdM6W8/jX3663NDGQw+HgG9Ssw5Pp9WhLlIk7J cx4sPqR3cEYsuhtrdcePJpMcQ1z9ECXYut1EIH16pFAG3k/scWQVCyww5 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ATAgB5HB9a/5xdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM8Zm4ng3+ZEIpniECHWwoYAQqBXoM6AhqEe0IVAQEBAQEBAQE?= =?us-ascii?q?BayiFIAIBAwEBIUsLEAIBCD8DAgICHwYLFBECBA4FiT5MAxUQp1GCJ4c0DYMmA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBGAWDQYIJgVaCEoMCgmuBfiqDIjGCMgWZKoh?= =?us-ascii?q?mPQKQE4R5k1GNNIhhAhEZAYE5ATUjgVFvFToqAYF+glIcgWd3hzACJYIgAQEB?= X-IronPort-AV: E=Sophos; i="5.45,339,1508803200"; d="scan'208,217"; a="37576566" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Nov 2017 20:48:00 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id vATKlxnA022979 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 29 Nov 2017 20:47:59 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 29 Nov 2017 14:47:59 -0600 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.1320.000; Wed, 29 Nov 2017 14:47:59 -0600 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks CC: Rahul Jadhav , Ines Robles Thread-Topic: [Roll] Fwd: Review of useofrplinfo-19 Thread-Index: AQHTaVFVkyaAd+cNrkKdvhSsiCbq1aMr1Au2 Date: Wed, 29 Nov 2017 20:47:59 +0000 Message-ID: <6E6930A9-C575-4E86-A823-42D4B17D1397@cisco.com> References: <71EA7FB9-8BDA-4371-98F5-591803AC6450@gmail.com> , <13976.1511987564@obiwan.sandelman.ca> In-Reply-To: <13976.1511987564@obiwan.sandelman.ca> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_6E6930A9C5754E86A82342D4B17D1397ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] Fwd: Review of useofrplinfo-19 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 20:48:03 -0000 --_000_6E6930A9C5754E86A82342D4B17D1397ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gTWljaGFlbA0KDQpJdGVtIDEgaXMgbm90IGNvcnJlY3QuIFdlIGNhbiBhY3R1YWxseSBj aGFuZ2UgdGhlIFJQSSBpbiBtaWQgZmxpZ2h0LiBSRkMgODIwMCBzYXlzIG5vIGluc2VydGlvbiBv ciBkZWxldGlvbiBmb3IgSGJIIGJ1dCBkb2VzIG5vdCBwcmVjbHVkZSBtb2RzLiBJbiBmYWN0IGV2 ZXJ5IGhvcCBjaGFuZ2VzIHRoZSBSUEkgaW4gTm9ybWFsIFJQTCBiZWhhdmlvci4gSSBhZ3JlZSB0 aGF0IGNoYW5naW5nIHRoZSBvcHRpb24gdHlwZSBpcyBtb3JlIHZpb2xlbnQgdGhvdWdoLg0KDQpB bHNvIHBhY2tldHMgd2l0aCAweDYzIHByb2JhYmx5IG9iZXllZCB0aGUgYW5jaWVudCBydWxlcyB0 aHVzIElQIGluIElQIGluIHdoaWNoIGNhc2UgdGhlIHJvb3QgZGVjYXBzdWxhdGVzIGFuZCB0aGUg UlBJIGdvZXMuDQoNClJlZ2FyZHMsDQoNClBhc2NhbA0KDQpMZSAyOSBub3YuIDIwMTcgw6AgMjE6 MzMsIE1pY2hhZWwgUmljaGFyZHNvbiA8bWNyK2lldGZAc2FuZGVsbWFuLmNhPG1haWx0bzptY3Ir aWV0ZkBzYW5kZWxtYW4uY2E+PiBhIMOpY3JpdCA6DQoNCg0KVGhhbmsgeW91IGZvciB0aGUgcmV2 aWV3IQ0KDQoiUmFodWwiID09IFJhaHVsIEphZGhhdiA8cmFodWwuaWV0ZkBnbWFpbC5jb208bWFp bHRvOnJhaHVsLmlldGZAZ21haWwuY29tPj4gd3JpdGVzOg0KICAgUmFodWw+IFtSSl06IFJlZ2Fy ZGluZyBwa3QgZndkaW5nLCBpdCBpcyBtZW50aW9uZWQgdGhhdCBpbXBsZW1lbnRhdGlvbnMNCiAg IFJhaHVsPiBzaG91bGQgY29udGludWUgdXNpbmcgdGhlIHNhbWUgb3B0aW9uIHR5cGUgdGhhdCB3 YXMgcmN2ZCBpbiBpbmNvbWluZw0KICAgUmFodWw+IHBrdC4gSXMgdGhlcmUgYW55IHNwZWNpZmlj IHJlYXNvbiBmb3IgdGhpcyBiZWhhdmlvdXI/IFRoZSByZWFzb24gd2h5IGkNCiAgIFJhaHVsPiBh c2sgdGhpcyBpcywgdXNpbmcgdGhpcyBmbGFnIG9uZSBjYW4gaW5mZXIgbm9kZXMgdGhhdCBhcmUg bm90DQogICBSYWh1bD4gdXBncmFkZWQsIGFuZCB0aGlzIG1heSBoYXZlIHNlY3VyaXR5IGltcGxp Y2F0aW9ucyBlc3BlY2lhbGx5IHdpdGggUlBJDQogICBSYWh1bD4gYmVlbiBzZW50IG91dCBvbiBJ bnRlcm5ldC4NCg0KQnkgY29udGludWluZyB0byB1c2UgdGhlIHNhbWUgb3B0aW9uIHR5cGUgdGhh dCB3YXMgcmVjZWl2ZWQgd2UgZG8gdHdvIHRoaW5nczoNCjEpIGF2b2lkIGNoYW5naW5nIHBhY2tl dHMgbWlkLWZsaWdodCB3aGljaCBSRkM4MjAwIHNheXMgbm90IHRvLg0KDQoyKSBwZXJtaXQgdGhl IG5ldHdvcmsgdG8gYmUgaW5jcmVtZW50YWxseSB1cGdyYWRlZCwgYW5kIGZvciB0aGUgRE9EQUcg cm9vdCB0bw0KICBrbm93IHdoaWNoIHBhcnRzIG9mIHRoZSBuZXR3b3JrIGFyZSB1cGdyYWRlZC4N CiAgKFdlIGFsc28gcHJvdmlkZWQgdGhlIGZsYWcgYW5kIERJTyBjb25maWd1cmF0aW9uIG9wdGlv biwgYnV0IGl0IGlzbid0DQogIGNsZWFyIHRvIG1lIHRoYXQgZXZlcnlvbmUgd2lsbCBpbXBsZW1l bnQgdGhhdCBvciB0aGF0IGl0J3MgZXZlbiBhIGdvb2QgaWRlYSkNCg0KUGFja2V0cyB3aXRoIHRo ZSBvbGQgMHg2MyBvcHRpb24gYXJlIGxpa2VseSB0byBiZSBkcm9wcGVkIGJ5IHRoZSBJbnRlcm5l dA0KcHJlLVJGQzgyMDAsIHNvIEkgZG9uJ3Qgc2VlIHRoZSBwcm9ibGVtLiAgIElmIHlvdSBjYW4g c2VlIFJQSSBoZWFkZXIgaW4gdGhlDQpuZWFyIHRlcm0sIEknZCBzYXkgdGhhdCB5b3UgYXJlIHBh cnQgb2YgdGhlIEVudGVycHJpc2UuICBBZnRlcndhcmQsIHlvdSB3aWxsDQpzZWUgb25seSAweDIz IG9wdGlvbnMuICAgSSB0aGluayB0aGF0IHRoaXMgdHJhbnNpdGlvbiB3aWxsIHRha2UgbWFueSB5 ZWFycy4NCg0KSWYga25vd2luZyBhIG5vZGUgaGFzbid0IGJlZW4gdXBncmFkZWQgbGV0cyB5b3Ug ZXhwbG9pdCBpdCwgdGhlbiB0aGUgZXhwbG9pdA0KaXMgYWxyZWFkeSBwb3NzaWJsZS4gVGhlcmUg YXJlIG1hbnkgb3RoZXIgdXBncmFkZXMgdGhhdCBhIG5vZGUgY291bGQgaGF2ZS4uLg0KDQogICBS YWh1bD4gU2VjdGlvbiAzLjM6DQoNCiAgIFJhaHVsPiAiSW4gY2FzZSBvZiByZWJvb3RpbmcsIHRo ZSBESU8gaXMgc2VudCB3aXRoIGZsYWcgaW5kaWNhdGluZyB0aGUgbmV3DQoNCiAgIFJhaHVsPiBS UEkgdmFsdWUuIg0KDQogICBSYWh1bD4gW1JKXTogRGlkbid0IHVuZGVyc3RhbmQgd2h5IHRoaXMg c2hvdWxkIGJlIHN0YXRlZC4gQlIvTm9kZSByZWJvb3QNCiAgIFJhaHVsPiBzaG91bGQgbm90IGlt cGFjdCB0aGUgY2hvaWNlIG9mIHRoaXMgZmxhZywgaW1vLg0KDQpJZiBhIG5vZGUgaGFzIHJlc3Rh cnRlZCwgdGhlbiBpdCB3b24ndCByZW1lbWJlciB0aGUgZmxhZy4NCg0KICAgUmFodWw+IFNlY3Rp b24gNDoNCg0KICAgUmFodWw+ICJBIFJQTCBuZXR3b3JrIGluIGdlbmVyYWwgaXMgY29tcG9zZWQg b2YgYSA2TEJSICg2TG9XUEFOIEJvcmRlcg0KDQogICBSYWh1bD4gUm91dGVyKSwgQmFja2JvbmUg Um91dGVyICg2QkJSKSwgNkxSICg2TG9XUEFOIFJvdXRlcikgYW5kIDZMTg0KDQogICBSYWh1bD4g KDZMb1dQQU4gTm9kZSkgYXMgbGVhZiBsb2dpY2FsbHkgb3JnYW5pemVkIGluIGEgRE9EQUcgc3Ry dWN0dXJlLiINCg0KICAgUmFodWw+IFtSSl06IFdoeSA2QkJSIGluIGdlbmVyYWwgY2FzZT8gQW55 d2F5cyB0aGUgY29ycmVzcG9uZGluZyB0b3BvbG9neQ0KICAgUmFodWw+IGRpYWdyYW0gKGZpZyA2 KSBiZWxvdyBkb2VzIG5vdCBoYXMgNkJCUi4NCg0KImluIGdlbmVyYWwiIC4uLiB0aGVyZSBtaWdo dCBiZSBhIDZCQlIsIGJ1dCBzaG93aW5nIGl0IGlzIHRvbyBjdW1iZXJzb21lIGluDQp0aGUgZGlh Z3JhbSBhbmQgZG9lcyBub3QgY2hhbmdlIGFueXRoaW5nLg0KDQogICBSYWh1bD4gU2VjdGlvbiA0 Og0KDQogICBSYWh1bD4gIlRoZSA2TE4gaXMgYSBSUEwgYXdhcmUgcm91dGVyLCBvciBob3N0Lg0K DQogICBSYWh1bD4gQnV0LCB0aGUgNkxOIGxlYXZlcyAoUmFmIC0gIlJQTCBhd2FyZSBsZWFmIi0p IG1hcmtlZCBhcyAoRiwgSCBhbmQgSSkNCg0KICAgUmFodWw+IGFyZSBSUEwgbm9kZXMgd2l0aCBu byBjaGlsZHJlbiBob3N0cy4iDQoNCiAgIFJhaHVsPiBbUkpdOiBTaG91bGQgdGhlIGZpcnN0IGxp bmUgYmUsICJUaGUgNkxOIGlzIGEgUlBMIGF3YXJlIGxlYWYgbm9kZSBvcg0KICAgUmFodWw+IGhv c3QuIiwgYnV0IHRoZW4gaXQgaXMgcmVkdW5kYW50IHdpdGggdGhlIHN1YnNlcXVlbnQgc3RtdC4N Cg0KVGhhdCBGLCBIIGFuZCBJIGhhdmUgbm8gY2hpbGRyZW4gZG9lc24ndCBtYWtlIHRoZW0gbGVh ZiAobm9kZSkgb25seS4NClRoZXkgYXJlIHNpbXBseSByb3V0ZXJzIHdpdGhvdXQgY2hpbGRyZW4g KmF0IHRoZSBtb21lbnQqLg0KDQogICBSYWh1bD4gIkluIHN0b3JpbmcgbW9kZSAoZnVsbHkgc3Rh dGVmdWwpLCB0aGUgc2VuZGVyIGNhbiBkZXRlcm1pbmUgaWYgdGhlDQogICBSYWh1bD4gZGVzdGlu YXRpb24gaXMgaW5zaWRlIHRoZSBMTE4gYnkgbG9va2luZyBpZiB0aGUgZGVzdGluYXRpb24gYWRk cmVzcw0KICAgUmFodWw+IGlzIG1hdGNoZWQgYnkgdGhlIERJTydzIFBJTyBvcHRpb24uIg0KDQog ICBSYWh1bD4gW1JKXTogSXQgaXMgbm90IG5lY2Vzc2FyeSB0aGF0IHRoZSBMTE4gd2lsbCBoYXZl IFJQTC1hd2FyZS1ub2Rlcw0KICAgUmFodWw+IGFkZHJlc3NlZCBvbmx5IHVzaW5nIERJTydzIFBJ Ty4gV2hhdCBoYXBwZW5zIGlmIHRoZSBkc3QgUlBMIG5vZGUgaGFzDQogICBSYWh1bD4gYW4gSVB2 NiBhZGRyZXNzIG5vdCB1c2luZyB0aGlzIFBJTz8gUlBMIGRvZXMgYWxsb3cgdGhpcy4gSW4gc3Rv cmluZw0KICAgUmFodWw+IG1vZGUgaSBzZWUgbm8gaXNzdWVzIGJlY2F1c2UgdGhlIGhhbmRsaW5n IHJlbWFpbnMgc2FtZSwgYnV0IGZvcg0KICAgUmFodWw+IG5vbi1zdG9yaW5nIG1vZGUgdGhlcmUg bWF5IGJlIGltcGxpY2F0aW9ucy4NCg0KSWYgc29tZSBub2RlIGhhcyBhbiBhZGRyZXNzIHdoaWNo IGlzIG5vdCBpbiB0aGUgRElPJ3MgUElPIHByZWZpeCwgdGhlbiBhDQpuYWl2ZSBvdGhlciBub2Rl IHdpbGwgYXNzdW1lIGl0IGlzIG5vdCBpbiB0aGUgTExOLiAgVGhhdCdzIHRoZSBiZXN0IGhldXJp c3RpYw0Kd2UgY2FtZSB1cCB3aXRoIHRvIGRldGVybWluZSBpZiB0aGUgZGVzdGluYXRpb24gaXMg aW4gdGhlIExMTiwgYW5kIHRoZXJlZm9yZQ0KUlBMIGNhcGFibGUuDQoNCiAgIFJhaHVsPiBTZWN0 aW9uIDYuMi4zOg0KDQogICBSYWh1bD4gIlRoZSA2TFJfMSAoaT0xKSBub2RlIHdpbGwgYWRkIGFu IElQLWluLUlQKFJQSSkgaGVhZGVyIGFkZHJlc3NlZA0KDQogICBSYWh1bD4gZWl0aGVyIHRvIHRo ZSByb290LCBvciBob3AtYnktaG9wIHN1Y2ggdGhhdCB0aGUgcm9vdCBjYW4gcmVtb3ZlIHRoZQ0K DQogICBSYWh1bD4gUlBJIGhlYWRlciBiZWZvcmUgcGFzc2luZyB1cHdhcmRzLiAoRUROT1RFOiB3 ZSBTSE9VTEQgcmVjb21tZW5kIG9uZQ0KDQogICBSYWh1bD4gb3IgdGhlIG90aGVyKSINCg0KICAg UmFodWw+IFtSSl06IExpbmdlcmluZyBFRE5PVEUuLi4gSSBsaWtlIHVzaW5nIElQLWluLUlQIGRl c3RpbmVkIHRvIHJvb3QNCiAgIFJhaHVsPiAoYmVjYXVzZSBpdHMgcmVsYXRpdmVseSBsZXNzIHBy b2Nlc3Npbmcgb3ZlcmhlYWQhKSwgYnV0IGhvcC1ieS1ob3AgaGFzDQogICBSYWh1bD4gaXRzIG93 biBhZHZhbnRhZ2UuIFRoZSBhZHZhbnRhZ2UgaXMsIElmIHRoZXJlIGlzIFJQTCBhd2FyZSBub2Rl IHdpdGggYQ0KICAgUmFodWw+IERBTy1hZHZlcnRpc2VkIElQdjYgYWRkcmVzcyBub3QgdXNpbmcg dGhlIERJTy1hZHZlcnRpc2VkIG5ldHdvcmsNCiAgIFJhaHVsPiBwcmVmaXggaW4gUElPLCB0aGVu IHRoZSByb3V0aW5nIHdvdWxkIGJlIGZhc3Rlci9tb3JlIGVmZmljaWVudCAoc2luY2UNCiAgIFJh aHVsPiA2TFJfaSB3b3VsZCBiZSBhYmxlIHRvIHJlbW92ZSBJUC1pbi1JUCBhbmQgY2hlY2sgdGhl IHJvdXRpbmcgdGFibGUgZm9yDQogICBSYWh1bD4gdGhlIGRzdCBpbiB1bmRlcmx5aW5nIElQIGhk cikuDQoNCnllcywgeW91IGFyZSByaWdodC4NCkNhbiB5b3UgdGVsbCB1cyB3aHkgc3VjaCBhIG5v ZGUgd291bGQgZXhpc3Q/ICBXaGF0J3MgdGhlIHVzZSBjYXNlPw0KDQogICBSYWh1bD4gW1JKXTog VGhlIDZMQlIgaXMgZ29pbmcgdG8gc3RyaXAgb2ZmIHRoZSBJUC1pbi1JUChSUEkpIGluIHRoaXMg Y2FzZS4NCiAgIFJhaHVsPiBXaHkgdGhlIHN0bXQsICI2TEJSIHdpbGwgc2V0IHRoZSBmbG93IGxh YmVsIG9mIHRoZSBwYWNrZXQgdG8gYQ0KICAgUmFodWw+IG5vbi16ZXJvLi4uIj8NCg0KQmVjYXVz ZSB0aGUgZmxvdy1sYWJlbCBpcyBzdXBwb3NlZCB0byBiZSBub24temVybyB3aGVuIHRyYWZmaWMg ZW50ZXJzIHRoZSAiSW50ZXJuZXQiDQoNCi0tDQpNaWNoYWVsIFJpY2hhcmRzb24gPG1jcitJRVRG QHNhbmRlbG1hbi5jYTxtYWlsdG86bWNyK0lFVEZAc2FuZGVsbWFuLmNhPj4sIFNhbmRlbG1hbiBT b2Z0d2FyZSBXb3Jrcw0KLT0gSVB2NiBJb1QgY29uc3VsdGluZyA9LQ0KDQoNCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClJvbGwgbWFpbGluZyBsaXN0 DQpSb2xsQGlldGYub3JnPG1haWx0bzpSb2xsQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9yb2xsDQo= --_000_6E6930A9C5754E86A82342D4B17D1397ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQpI ZWxsbyBNaWNoYWVsJm5ic3A7DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JdGVtIDEgaXMgbm90 IGNvcnJlY3QuIFdlIGNhbiBhY3R1YWxseSBjaGFuZ2UgdGhlIFJQSSBpbiBtaWQgZmxpZ2h0LiBS RkMgODIwMCBzYXlzIG5vIGluc2VydGlvbiBvciBkZWxldGlvbiBmb3IgSGJIIGJ1dCBkb2VzIG5v dCBwcmVjbHVkZSBtb2RzLiBJbiBmYWN0IGV2ZXJ5IGhvcCBjaGFuZ2VzIHRoZSBSUEkgaW4gTm9y bWFsIFJQTCBiZWhhdmlvci4gSSBhZ3JlZSB0aGF0IGNoYW5naW5nIHRoZSBvcHRpb24gdHlwZSBp cyBtb3JlIHZpb2xlbnQNCiB0aG91Z2guPGJyPg0KPGJyPg0KPGRpdj4NCjxkaXY+QWxzbyBwYWNr ZXRzIHdpdGggMHg2MyBwcm9iYWJseSBvYmV5ZWQgdGhlIGFuY2llbnQgcnVsZXMgdGh1cyBJUCBp biBJUCBpbiB3aGljaCBjYXNlIHRoZSByb290IGRlY2Fwc3VsYXRlcyBhbmQgdGhlIFJQSSBnb2Vz LjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NClJlZ2FyZHMsDQo8ZGl2Pjxicj4NCjwvZGl2Pg0K PGRpdj5QYXNjYWw8L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnI+DQpMZSAyOSBub3YuIDIwMTcgw6Ag MjE6MzMsIE1pY2hhZWwgUmljaGFyZHNvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1jciYjNDM7aWV0 ZkBzYW5kZWxtYW4uY2EiPm1jciYjNDM7aWV0ZkBzYW5kZWxtYW4uY2E8L2E+Jmd0OyBhIMOpY3Jp dCZuYnNwOzo8YnI+DQo8YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRp dj48c3Bhbj48L3NwYW4+PGJyPg0KPHNwYW4+VGhhbmsgeW91IGZvciB0aGUgcmV2aWV3ITwvc3Bh bj48YnI+DQo8c3Bhbj48L3NwYW4+PGJyPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj4mcXVvdDtSYWh1 bCZxdW90OyA9PSBSYWh1bCBKYWRoYXYgJmx0OzxhIGhyZWY9Im1haWx0bzpyYWh1bC5pZXRmQGdt YWlsLmNvbSI+cmFodWwuaWV0ZkBnbWFpbC5jb208L2E+Jmd0OyB3cml0ZXM6PC9zcGFuPjxicj4N CjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90 ZT4NCjwvYmxvY2txdW90ZT4NCjxzcGFuPiZuYnNwOyZuYnNwOyZuYnNwO1JhaHVsJmd0OyBbUkpd OiBSZWdhcmRpbmcgcGt0IGZ3ZGluZywgaXQgaXMgbWVudGlvbmVkIHRoYXQgaW1wbGVtZW50YXRp b25zPC9zcGFuPjxicj4NCjxzcGFuPiZuYnNwOyZuYnNwOyZuYnNwO1JhaHVsJmd0OyBzaG91bGQg Y29udGludWUgdXNpbmcgdGhlIHNhbWUgb3B0aW9uIHR5cGUgdGhhdCB3YXMgcmN2ZCBpbiBpbmNv bWluZzwvc3Bhbj48YnI+DQo8c3Bhbj4mbmJzcDsmbmJzcDsmbmJzcDtSYWh1bCZndDsgcGt0LiBJ cyB0aGVyZSBhbnkgc3BlY2lmaWMgcmVhc29uIGZvciB0aGlzIGJlaGF2aW91cj8gVGhlIHJlYXNv biB3aHkgaTwvc3Bhbj48YnI+DQo8c3Bhbj4mbmJzcDsmbmJzcDsmbmJzcDtSYWh1bCZndDsgYXNr IHRoaXMgaXMsIHVzaW5nIHRoaXMgZmxhZyBvbmUgY2FuIGluZmVyIG5vZGVzIHRoYXQgYXJlIG5v dDwvc3Bhbj48YnI+DQo8c3Bhbj4mbmJzcDsmbmJzcDsmbmJzcDtSYWh1bCZndDsgdXBncmFkZWQs IGFuZCB0aGlzIG1heSBoYXZlIHNlY3VyaXR5IGltcGxpY2F0aW9ucyBlc3BlY2lhbGx5IHdpdGgg UlBJPC9zcGFuPjxicj4NCjxzcGFuPiZuYnNwOyZuYnNwOyZuYnNwO1JhaHVsJmd0OyBiZWVuIHNl bnQgb3V0IG9uIEludGVybmV0Ljwvc3Bhbj48YnI+DQo8c3Bhbj48L3NwYW4+PGJyPg0KPHNwYW4+ QnkgY29udGludWluZyB0byB1c2UgdGhlIHNhbWUgb3B0aW9uIHR5cGUgdGhhdCB3YXMgcmVjZWl2 ZWQgd2UgZG8gdHdvIHRoaW5nczo8L3NwYW4+PGJyPg0KPHNwYW4+MSkgYXZvaWQgY2hhbmdpbmcg cGFja2V0cyBtaWQtZmxpZ2h0IHdoaWNoIFJGQzgyMDAgc2F5cyBub3QgdG8uPC9zcGFuPjxicj4N CjxzcGFuPjwvc3Bhbj48YnI+DQo8c3Bhbj4yKSBwZXJtaXQgdGhlIG5ldHdvcmsgdG8gYmUgaW5j cmVtZW50YWxseSB1cGdyYWRlZCwgYW5kIGZvciB0aGUgRE9EQUcgcm9vdCB0bzwvc3Bhbj48YnI+ DQo8c3Bhbj4mbmJzcDsmbmJzcDtrbm93IHdoaWNoIHBhcnRzIG9mIHRoZSBuZXR3b3JrIGFyZSB1 cGdyYWRlZC48L3NwYW4+PGJyPg0KPHNwYW4+Jm5ic3A7Jm5ic3A7KFdlIGFsc28gcHJvdmlkZWQg dGhlIGZsYWcgYW5kIERJTyBjb25maWd1cmF0aW9uIG9wdGlvbiwgYnV0IGl0IGlzbid0PC9zcGFu Pjxicj4NCjxzcGFuPiZuYnNwOyZuYnNwO2NsZWFyIHRvIG1lIHRoYXQgZXZlcnlvbmUgd2lsbCBp bXBsZW1lbnQgdGhhdCBvciB0aGF0IGl0J3MgZXZlbiBhIGdvb2QgaWRlYSk8L3NwYW4+PGJyPg0K PHNwYW4+PC9zcGFuPjxicj4NCjxzcGFuPlBhY2tldHMgd2l0aCB0aGUgb2xkIDB4NjMgb3B0aW9u IGFyZSBsaWtlbHkgdG8gYmUgZHJvcHBlZCBieSB0aGUgSW50ZXJuZXQ8L3NwYW4+PGJyPg0KPHNw YW4+cHJlLVJGQzgyMDAsIHNvIEkgZG9uJ3Qgc2VlIHRoZSBwcm9ibGVtLiAmbmJzcDsmbmJzcDtJ ZiB5b3UgY2FuIHNlZSBSUEkgaGVhZGVyIGluIHRoZTwvc3Bhbj48YnI+DQo8c3Bhbj5uZWFyIHRl cm0sIEknZCBzYXkgdGhhdCB5b3UgYXJlIHBhcnQgb2YgdGhlIEVudGVycHJpc2UuICZuYnNwO0Fm dGVyd2FyZCwgeW91IHdpbGw8L3NwYW4+PGJyPg0KPHNwYW4+c2VlIG9ubHkgMHgyMyBvcHRpb25z LiAmbmJzcDsmbmJzcDtJIHRoaW5rIHRoYXQgdGhpcyB0cmFuc2l0aW9uIHdpbGwgdGFrZSBtYW55 IHllYXJzLjwvc3Bhbj48YnI+DQo8c3Bhbj48L3NwYW4+PGJyPg0KPHNwYW4+SWYga25vd2luZyBh IG5vZGUgaGFzbid0IGJlZW4gdXBncmFkZWQgbGV0cyB5b3UgZXhwbG9pdCBpdCwgdGhlbiB0aGUg ZXhwbG9pdDwvc3Bhbj48YnI+DQo8c3Bhbj5pcyBhbHJlYWR5IHBvc3NpYmxlLiBUaGVyZSBhcmUg bWFueSBvdGhlciB1cGdyYWRlcyB0aGF0IGEgbm9kZSBjb3VsZCBoYXZlLi4uPC9zcGFuPjxicj4N CjxzcGFuPjwvc3Bhbj48YnI+DQo8c3Bhbj4mbmJzcDsmbmJzcDsmbmJzcDtSYWh1bCZndDsgU2Vj dGlvbiAzLjM6PC9zcGFuPjxicj4NCjxzcGFuPjwvc3Bhbj48YnI+DQo8c3Bhbj4mbmJzcDsmbmJz cDsmbmJzcDtSYWh1bCZndDsgJnF1b3Q7SW4gY2FzZSBvZiByZWJvb3RpbmcsIHRoZSBESU8gaXMg c2VudCB3aXRoIGZsYWcgaW5kaWNhdGluZyB0aGUgbmV3PC9zcGFuPjxicj4NCjxzcGFuPjwvc3Bh bj48YnI+DQo8c3Bhbj4mbmJzcDsmbmJzcDsmbmJzcDtSYWh1bCZndDsgUlBJIHZhbHVlLiZxdW90 Ozwvc3Bhbj48YnI+DQo8c3Bhbj48L3NwYW4+PGJyPg0KPHNwYW4+Jm5ic3A7Jm5ic3A7Jm5ic3A7 UmFodWwmZ3Q7IFtSSl06IERpZG4ndCB1bmRlcnN0YW5kIHdoeSB0aGlzIHNob3VsZCBiZSBzdGF0 ZWQuIEJSL05vZGUgcmVib290PC9zcGFuPjxicj4NCjxzcGFuPiZuYnNwOyZuYnNwOyZuYnNwO1Jh aHVsJmd0OyBzaG91bGQgbm90IGltcGFjdCB0aGUgY2hvaWNlIG9mIHRoaXMgZmxhZywgaW1vLjwv c3Bhbj48YnI+DQo8c3Bhbj48L3NwYW4+PGJyPg0KPHNwYW4+SWYgYSBub2RlIGhhcyByZXN0YXJ0 ZWQsIHRoZW4gaXQgd29uJ3QgcmVtZW1iZXIgdGhlIGZsYWcuPC9zcGFuPjxicj4NCjxzcGFuPjwv c3Bhbj48YnI+DQo8c3Bhbj4mbmJzcDsmbmJzcDsmbmJzcDtSYWh1bCZndDsgU2VjdGlvbiA0Ojwv c3Bhbj48YnI+DQo8c3Bhbj48L3NwYW4+PGJyPg0KPHNwYW4+Jm5ic3A7Jm5ic3A7Jm5ic3A7UmFo dWwmZ3Q7ICZxdW90O0EgUlBMIG5ldHdvcmsgaW4gZ2VuZXJhbCBpcyBjb21wb3NlZCBvZiBhIDZM QlIgKDZMb1dQQU4gQm9yZGVyPC9zcGFuPjxicj4NCjxzcGFuPjwvc3Bhbj48YnI+DQo8c3Bhbj4m bmJzcDsmbmJzcDsmbmJzcDtSYWh1bCZndDsgUm91dGVyKSwgQmFja2JvbmUgUm91dGVyICg2QkJS KSwgNkxSICg2TG9XUEFOIFJvdXRlcikgYW5kIDZMTjwvc3Bhbj48YnI+DQo8c3Bhbj48L3NwYW4+ PGJyPg0KPHNwYW4+Jm5ic3A7Jm5ic3A7Jm5ic3A7UmFodWwmZ3Q7ICg2TG9XUEFOIE5vZGUpIGFz IGxlYWYgbG9naWNhbGx5IG9yZ2FuaXplZCBpbiBhIERPREFHIHN0cnVjdHVyZS4mcXVvdDs8L3Nw YW4+PGJyPg0KPHNwYW4+PC9zcGFuPjxicj4NCjxzcGFuPiZuYnNwOyZuYnNwOyZuYnNwO1JhaHVs Jmd0OyBbUkpdOiBXaHkgNkJCUiBpbiBnZW5lcmFsIGNhc2U/IEFueXdheXMgdGhlIGNvcnJlc3Bv bmRpbmcgdG9wb2xvZ3k8L3NwYW4+PGJyPg0KPHNwYW4+Jm5ic3A7Jm5ic3A7Jm5ic3A7UmFodWwm Z3Q7IGRpYWdyYW0gKGZpZyA2KSBiZWxvdyBkb2VzIG5vdCBoYXMgNkJCUi48L3NwYW4+PGJyPg0K PHNwYW4+PC9zcGFuPjxicj4NCjxzcGFuPiZxdW90O2luIGdlbmVyYWwmcXVvdDsgLi4uIHRoZXJl IG1pZ2h0IGJlIGEgNkJCUiwgYnV0IHNob3dpbmcgaXQgaXMgdG9vIGN1bWJlcnNvbWUgaW48L3Nw YW4+PGJyPg0KPHNwYW4+dGhlIGRpYWdyYW0gYW5kIGRvZXMgbm90IGNoYW5nZSBhbnl0aGluZy48 L3NwYW4+PGJyPg0KPHNwYW4+PC9zcGFuPjxicj4NCjxzcGFuPiZuYnNwOyZuYnNwOyZuYnNwO1Jh aHVsJmd0OyBTZWN0aW9uIDQ6PC9zcGFuPjxicj4NCjxzcGFuPjwvc3Bhbj48YnI+DQo8c3Bhbj4m bmJzcDsmbmJzcDsmbmJzcDtSYWh1bCZndDsgJnF1b3Q7VGhlIDZMTiBpcyBhIFJQTCBhd2FyZSBy b3V0ZXIsIG9yIGhvc3QuPC9zcGFuPjxicj4NCjxzcGFuPjwvc3Bhbj48YnI+DQo8c3Bhbj4mbmJz cDsmbmJzcDsmbmJzcDtSYWh1bCZndDsgQnV0LCB0aGUgNkxOIGxlYXZlcyAoUmFmIC0gJnF1b3Q7 UlBMIGF3YXJlIGxlYWYmcXVvdDstKSBtYXJrZWQgYXMgKEYsIEggYW5kIEkpPC9zcGFuPjxicj4N CjxzcGFuPjwvc3Bhbj48YnI+DQo8c3Bhbj4mbmJzcDsmbmJzcDsmbmJzcDtSYWh1bCZndDsgYXJl IFJQTCBub2RlcyB3aXRoIG5vIGNoaWxkcmVuIGhvc3RzLiZxdW90Ozwvc3Bhbj48YnI+DQo8c3Bh bj48L3NwYW4+PGJyPg0KPHNwYW4+Jm5ic3A7Jm5ic3A7Jm5ic3A7UmFodWwmZ3Q7IFtSSl06IFNo b3VsZCB0aGUgZmlyc3QgbGluZSBiZSwgJnF1b3Q7VGhlIDZMTiBpcyBhIFJQTCBhd2FyZSBsZWFm IG5vZGUgb3I8L3NwYW4+PGJyPg0KPHNwYW4+Jm5ic3A7Jm5ic3A7Jm5ic3A7UmFodWwmZ3Q7IGhv c3QuJnF1b3Q7LCBidXQgdGhlbiBpdCBpcyByZWR1bmRhbnQgd2l0aCB0aGUgc3Vic2VxdWVudCBz dG10Ljwvc3Bhbj48YnI+DQo8c3Bhbj48L3NwYW4+PGJyPg0KPHNwYW4+VGhhdCBGLCBIIGFuZCBJ IGhhdmUgbm8gY2hpbGRyZW4gZG9lc24ndCBtYWtlIHRoZW0gbGVhZiAobm9kZSkgb25seS48L3Nw YW4+PGJyPg0KPHNwYW4+VGhleSBhcmUgc2ltcGx5IHJvdXRlcnMgd2l0aG91dCBjaGlsZHJlbiAq YXQgdGhlIG1vbWVudCouPC9zcGFuPjxicj4NCjxzcGFuPjwvc3Bhbj48YnI+DQo8c3Bhbj4mbmJz cDsmbmJzcDsmbmJzcDtSYWh1bCZndDsgJnF1b3Q7SW4gc3RvcmluZyBtb2RlIChmdWxseSBzdGF0 ZWZ1bCksIHRoZSBzZW5kZXIgY2FuIGRldGVybWluZSBpZiB0aGU8L3NwYW4+PGJyPg0KPHNwYW4+ Jm5ic3A7Jm5ic3A7Jm5ic3A7UmFodWwmZ3Q7IGRlc3RpbmF0aW9uIGlzIGluc2lkZSB0aGUgTExO IGJ5IGxvb2tpbmcgaWYgdGhlIGRlc3RpbmF0aW9uIGFkZHJlc3M8L3NwYW4+PGJyPg0KPHNwYW4+ Jm5ic3A7Jm5ic3A7Jm5ic3A7UmFodWwmZ3Q7IGlzIG1hdGNoZWQgYnkgdGhlIERJTydzIFBJTyBv cHRpb24uJnF1b3Q7PC9zcGFuPjxicj4NCjxzcGFuPjwvc3Bhbj48YnI+DQo8c3Bhbj4mbmJzcDsm bmJzcDsmbmJzcDtSYWh1bCZndDsgW1JKXTogSXQgaXMgbm90IG5lY2Vzc2FyeSB0aGF0IHRoZSBM TE4gd2lsbCBoYXZlIFJQTC1hd2FyZS1ub2Rlczwvc3Bhbj48YnI+DQo8c3Bhbj4mbmJzcDsmbmJz cDsmbmJzcDtSYWh1bCZndDsgYWRkcmVzc2VkIG9ubHkgdXNpbmcgRElPJ3MgUElPLiBXaGF0IGhh cHBlbnMgaWYgdGhlIGRzdCBSUEwgbm9kZSBoYXM8L3NwYW4+PGJyPg0KPHNwYW4+Jm5ic3A7Jm5i c3A7Jm5ic3A7UmFodWwmZ3Q7IGFuIElQdjYgYWRkcmVzcyBub3QgdXNpbmcgdGhpcyBQSU8/IFJQ TCBkb2VzIGFsbG93IHRoaXMuIEluIHN0b3Jpbmc8L3NwYW4+PGJyPg0KPHNwYW4+Jm5ic3A7Jm5i c3A7Jm5ic3A7UmFodWwmZ3Q7IG1vZGUgaSBzZWUgbm8gaXNzdWVzIGJlY2F1c2UgdGhlIGhhbmRs aW5nIHJlbWFpbnMgc2FtZSwgYnV0IGZvcjwvc3Bhbj48YnI+DQo8c3Bhbj4mbmJzcDsmbmJzcDsm bmJzcDtSYWh1bCZndDsgbm9uLXN0b3JpbmcgbW9kZSB0aGVyZSBtYXkgYmUgaW1wbGljYXRpb25z Ljwvc3Bhbj48YnI+DQo8c3Bhbj48L3NwYW4+PGJyPg0KPHNwYW4+SWYgc29tZSBub2RlIGhhcyBh biBhZGRyZXNzIHdoaWNoIGlzIG5vdCBpbiB0aGUgRElPJ3MgUElPIHByZWZpeCwgdGhlbiBhPC9z cGFuPjxicj4NCjxzcGFuPm5haXZlIG90aGVyIG5vZGUgd2lsbCBhc3N1bWUgaXQgaXMgbm90IGlu IHRoZSBMTE4uICZuYnNwO1RoYXQncyB0aGUgYmVzdCBoZXVyaXN0aWM8L3NwYW4+PGJyPg0KPHNw YW4+d2UgY2FtZSB1cCB3aXRoIHRvIGRldGVybWluZSBpZiB0aGUgZGVzdGluYXRpb24gaXMgaW4g dGhlIExMTiwgYW5kIHRoZXJlZm9yZTwvc3Bhbj48YnI+DQo8c3Bhbj5SUEwgY2FwYWJsZS48L3Nw YW4+PGJyPg0KPHNwYW4+PC9zcGFuPjxicj4NCjxzcGFuPiZuYnNwOyZuYnNwOyZuYnNwO1JhaHVs Jmd0OyBTZWN0aW9uIDYuMi4zOjwvc3Bhbj48YnI+DQo8c3Bhbj48L3NwYW4+PGJyPg0KPHNwYW4+ Jm5ic3A7Jm5ic3A7Jm5ic3A7UmFodWwmZ3Q7ICZxdW90O1RoZSA2TFJfMSAoaT0xKSBub2RlIHdp bGwgYWRkIGFuIElQLWluLUlQKFJQSSkgaGVhZGVyIGFkZHJlc3NlZDwvc3Bhbj48YnI+DQo8c3Bh bj48L3NwYW4+PGJyPg0KPHNwYW4+Jm5ic3A7Jm5ic3A7Jm5ic3A7UmFodWwmZ3Q7IGVpdGhlciB0 byB0aGUgcm9vdCwgb3IgaG9wLWJ5LWhvcCBzdWNoIHRoYXQgdGhlIHJvb3QgY2FuIHJlbW92ZSB0 aGU8L3NwYW4+PGJyPg0KPHNwYW4+PC9zcGFuPjxicj4NCjxzcGFuPiZuYnNwOyZuYnNwOyZuYnNw O1JhaHVsJmd0OyBSUEkgaGVhZGVyIGJlZm9yZSBwYXNzaW5nIHVwd2FyZHMuIChFRE5PVEU6IHdl IFNIT1VMRCByZWNvbW1lbmQgb25lPC9zcGFuPjxicj4NCjxzcGFuPjwvc3Bhbj48YnI+DQo8c3Bh bj4mbmJzcDsmbmJzcDsmbmJzcDtSYWh1bCZndDsgb3IgdGhlIG90aGVyKSZxdW90Ozwvc3Bhbj48 YnI+DQo8c3Bhbj48L3NwYW4+PGJyPg0KPHNwYW4+Jm5ic3A7Jm5ic3A7Jm5ic3A7UmFodWwmZ3Q7 IFtSSl06IExpbmdlcmluZyBFRE5PVEUuLi4gSSBsaWtlIHVzaW5nIElQLWluLUlQIGRlc3RpbmVk IHRvIHJvb3Q8L3NwYW4+PGJyPg0KPHNwYW4+Jm5ic3A7Jm5ic3A7Jm5ic3A7UmFodWwmZ3Q7IChi ZWNhdXNlIGl0cyByZWxhdGl2ZWx5IGxlc3MgcHJvY2Vzc2luZyBvdmVyaGVhZCEpLCBidXQgaG9w LWJ5LWhvcCBoYXM8L3NwYW4+PGJyPg0KPHNwYW4+Jm5ic3A7Jm5ic3A7Jm5ic3A7UmFodWwmZ3Q7 IGl0cyBvd24gYWR2YW50YWdlLiBUaGUgYWR2YW50YWdlIGlzLCBJZiB0aGVyZSBpcyBSUEwgYXdh cmUgbm9kZSB3aXRoIGE8L3NwYW4+PGJyPg0KPHNwYW4+Jm5ic3A7Jm5ic3A7Jm5ic3A7UmFodWwm Z3Q7IERBTy1hZHZlcnRpc2VkIElQdjYgYWRkcmVzcyBub3QgdXNpbmcgdGhlIERJTy1hZHZlcnRp c2VkIG5ldHdvcms8L3NwYW4+PGJyPg0KPHNwYW4+Jm5ic3A7Jm5ic3A7Jm5ic3A7UmFodWwmZ3Q7 IHByZWZpeCBpbiBQSU8sIHRoZW4gdGhlIHJvdXRpbmcgd291bGQgYmUgZmFzdGVyL21vcmUgZWZm aWNpZW50IChzaW5jZTwvc3Bhbj48YnI+DQo8c3Bhbj4mbmJzcDsmbmJzcDsmbmJzcDtSYWh1bCZn dDsgNkxSX2kgd291bGQgYmUgYWJsZSB0byByZW1vdmUgSVAtaW4tSVAgYW5kIGNoZWNrIHRoZSBy b3V0aW5nIHRhYmxlIGZvcjwvc3Bhbj48YnI+DQo8c3Bhbj4mbmJzcDsmbmJzcDsmbmJzcDtSYWh1 bCZndDsgdGhlIGRzdCBpbiB1bmRlcmx5aW5nIElQIGhkcikuPC9zcGFuPjxicj4NCjxzcGFuPjwv c3Bhbj48YnI+DQo8c3Bhbj55ZXMsIHlvdSBhcmUgcmlnaHQuPC9zcGFuPjxicj4NCjxzcGFuPkNh biB5b3UgdGVsbCB1cyB3aHkgc3VjaCBhIG5vZGUgd291bGQgZXhpc3Q/ICZuYnNwO1doYXQncyB0 aGUgdXNlIGNhc2U/PC9zcGFuPjxicj4NCjxzcGFuPjwvc3Bhbj48YnI+DQo8c3Bhbj4mbmJzcDsm bmJzcDsmbmJzcDtSYWh1bCZndDsgW1JKXTogVGhlIDZMQlIgaXMgZ29pbmcgdG8gc3RyaXAgb2Zm IHRoZSBJUC1pbi1JUChSUEkpIGluIHRoaXMgY2FzZS48L3NwYW4+PGJyPg0KPHNwYW4+Jm5ic3A7 Jm5ic3A7Jm5ic3A7UmFodWwmZ3Q7IFdoeSB0aGUgc3RtdCwgJnF1b3Q7NkxCUiB3aWxsIHNldCB0 aGUgZmxvdyBsYWJlbCBvZiB0aGUgcGFja2V0IHRvIGE8L3NwYW4+PGJyPg0KPHNwYW4+Jm5ic3A7 Jm5ic3A7Jm5ic3A7UmFodWwmZ3Q7IG5vbi16ZXJvLi4uJnF1b3Q7Pzwvc3Bhbj48YnI+DQo8c3Bh bj48L3NwYW4+PGJyPg0KPHNwYW4+QmVjYXVzZSB0aGUgZmxvdy1sYWJlbCBpcyBzdXBwb3NlZCB0 byBiZSBub24temVybyB3aGVuIHRyYWZmaWMgZW50ZXJzIHRoZSAmcXVvdDtJbnRlcm5ldCZxdW90 Ozwvc3Bhbj48YnI+DQo8c3Bhbj48L3NwYW4+PGJyPg0KPHNwYW4+LS08L3NwYW4+PGJyPg0KPHNw YW4+TWljaGFlbCBSaWNoYXJkc29uICZsdDs8YSBocmVmPSJtYWlsdG86bWNyJiM0MztJRVRGQHNh bmRlbG1hbi5jYSI+bWNyJiM0MztJRVRGQHNhbmRlbG1hbi5jYTwvYT4mZ3Q7LCBTYW5kZWxtYW4g U29mdHdhcmUgV29ya3M8L3NwYW4+PGJyPg0KPHNwYW4+LT0gSVB2NiBJb1QgY29uc3VsdGluZyA9 LTwvc3Bhbj48YnI+DQo8c3Bhbj48L3NwYW4+PGJyPg0KPHNwYW4+PC9zcGFuPjxicj4NCjxzcGFu Pjwvc3Bhbj48YnI+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNp dGUiPg0KPGRpdj48c3Bhbj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzwvc3Bhbj48YnI+DQo8c3Bhbj5Sb2xsIG1haWxpbmcgbGlzdDwvc3Bhbj48YnI+DQo8 c3Bhbj48YSBocmVmPSJtYWlsdG86Um9sbEBpZXRmLm9yZyI+Um9sbEBpZXRmLm9yZzwvYT48L3Nw YW4+PGJyPg0KPHNwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9yb2xsIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGw8L2E+ PC9zcGFuPjxicj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_6E6930A9C5754E86A82342D4B17D1397ciscocom_-- From nobody Wed Nov 29 18:38:23 2017 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B0041270FC for ; Wed, 29 Nov 2017 18:38:22 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 JaqiUwjbRAaJ for ; Wed, 29 Nov 2017 18:38:21 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27814120454 for ; Wed, 29 Nov 2017 18:38:21 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id D39412008C; Wed, 29 Nov 2017 21:40:51 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id F179B829D1; Wed, 29 Nov 2017 21:38:19 -0500 (EST) From: Michael Richardson To: Routing Over Low power and Lossy networks cc: Ines Robles In-Reply-To: <6E6930A9-C575-4E86-A823-42D4B17D1397@cisco.com> References: <71EA7FB9-8BDA-4371-98F5-591803AC6450@gmail.com> , <13976.1511987564@obiwan.sandelman.ca> <6E6930A9-C575-4E86-A823-42D4B17D1397@cisco.com> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Roll] Fwd: Review of useofrplinfo-19 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Nov 2017 02:38:22 -0000 --=-=-= Content-Type: text/plain Pascal Thubert (pthubert) wrote: > Item 1 is not correct. We can actually change the RPI in mid flight. > RFC 8200 says no insertion or deletion for HbH but does not preclude > mods. In fact every hop changes the RPI in Normal RPL behavior. I > agree that changing the option type is more violent though. We can't change the RPI type code, just the contents of the header itself. It would be delete 0x63 header and insert 0x23 header. > Also packets with 0x63 probably obeyed the ancient rules thus IP in IP > in which case the root decapsulates and the RPI goes. True. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlofbxsACgkQgItw+93Q 3WU+NQf/c7Eke3yY5loqybIR58mK8MrjfGyjhKEnyIZbn/+881wkMiy17JMbPjHs rmoDHWXZxJw5y0yONJ6pIWTNyBhSbepfaOX3WCbrSRv4MY1DkImtq6HktYZTxQf4 l2f0DcPnpGK0GdhD898ECLk4+JzWqpBej0HCiaTm6RDGLQChm9CDp3MM9FDWNLTc zNbTbuD+Fr6unr7+FTRBZC52/BrLDifChdyQlb6KhBxCrk1y/vOwaVxLcMEo4u/u BC51FRjIayQcqkg0+XNGRtQ6E2nqhhR3xTcdjfLJsDTMyPP9OgvUfcGZq7OcfSff fF50fgr7k9hbfR1LK38PVJAC3X+xDA== =KJs4 -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Nov 29 21:21:52 2017 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05D7D127419 for ; Wed, 29 Nov 2017 21:21:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.519 X-Spam-Level: X-Spam-Status: No, score=-14.519 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 ba_CW4HPuwBh for ; Wed, 29 Nov 2017 21:21:48 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11C24124207 for ; Wed, 29 Nov 2017 21:21:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7675; q=dns/txt; s=iport; t=1512019308; x=1513228908; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=PC2HyCbWhG1CH9gjIZRuAyMTVZ2rlyqWK8GUh9TUTJU=; b=HJQvYw+4rngLNskgrkhY3h8hFJ4SAF0mfwtHAA9bryoXrqo9yfJK/CfG W6bpK6hUF2yHZdd/DgLpo7Runz1fyaIE8afkcbZY8guK+MRkEIkM7p+KH WsKeruzn2mWxojyNrkMpLp45bZkm49fM9AdKw02xaI+Pg1wuTxzZGIOMj s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CJAwAvlR9a/51dJa1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM8Zm4ng3+ZEYFXkVGFS4IRChgBCoFegzoCGoR7QRYBAQEBAQE?= =?us-ascii?q?BAQFrKIUgAgEDAQEhSwsQAgEIPwMCAgIlCxQRAgQOBYk+ZBAIpxOCJ4plAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBGAWDQYIJgVaCEguCd4Rpg0wxgjIFikuOYokmApU?= =?us-ascii?q?Ok1KWFQIRGQGBOQEmBC6BUW8VOioBgX6CUhyBZ3eHQIJHAQEB?= X-IronPort-AV: E=Sophos; i="5.45,340,1508803200"; d="scan'208,217"; a="38249232" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Nov 2017 05:21:46 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id vAU5LkMp008150 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 30 Nov 2017 05:21:46 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.1320.4; Wed, 29 Nov 2017 23:21:45 -0600 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.1320.000; Wed, 29 Nov 2017 23:21:45 -0600 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks CC: Ines Robles Thread-Topic: [Roll] Fwd: Review of useofrplinfo-19 Thread-Index: AQHTaYROeUOy1PNKnkiz/U3kv2Q4TKMsYzFU Date: Thu, 30 Nov 2017 05:21:45 +0000 Message-ID: <53D6466B-9633-4795-B16F-FB9120F94D93@cisco.com> References: <71EA7FB9-8BDA-4371-98F5-591803AC6450@gmail.com> , <13976.1511987564@obiwan.sandelman.ca> <6E6930A9-C575-4E86-A823-42D4B17D1397@cisco.com>, <30834.1512009499@obiwan.sandelman.ca> In-Reply-To: <30834.1512009499@obiwan.sandelman.ca> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_53D6466B96334795B16FFB9120F94D93ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] Fwd: Review of useofrplinfo-19 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Nov 2017 05:21:50 -0000 --_000_53D6466B96334795B16FFB9120F94D93ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB1bmRlcnN0YW5kIGhvdyB5b3Ugc2VlIGl0IE1pY2hhZWwuIE1ha2VzIHNlbnNlIHRvIG1lLg0K DQpOb3cgaWYgd2UgZG8gbm90IHJld3JpdGUgdGhlbiBpZiBhIHBhY2tldCBjb21lcyB0byB0aGUg cm9vdCB3aXRoIDB4NjMgYW5kIG5vIElQIGluIElQIHRoZSByb290IHdpbGwgbm90IHJld3JpdGUu IElmIGl0IGZvbGxvd3MgdGhlIHJ1bGVzIGluIHRoZSBvcHMgZHJhZnQgaXQgc2hvdWxkIGRyb3Ag dGhlIHBhY2tldC4gQXQgbGVhc3QgaXQgY291bGQgcmVwb3J0IGFuIGFsZXJ0IHRvIGRvY3VtZW50 IHRoZSBpc3N1ZS4NCg0KQnV0LCBzYW1lIGFzIGxlYWtpbmcgMHgyMywgdGhhdCBpcyBhIHJlY2lw ZSBmb3IgdW5oYXBweSBjdXN0b21lcnMuIEluIGJvdGggY2FzZXMgd2Ugd2FudCB0byBhdm9pZCBr ZWVwaW5nIHRoZSBSUEkgaW4gdGhlIG91dGVyIGhlYWRlci4gSW4gYm90aCBjYXNlcyBpdCBpcyB0 byBhdm9pZCBpc3N1ZXMgZnJvbSBkZXZpY2VzIHRoYXQgZG8gbm90IGZvbGxvdyB0aGUgcnVsZXMg YnV0IHdoaWNoIHdlIGRvIG5vdCBjb250cm9sIGVpdGhlci4NCg0KQXMgYSBzdGFuZGFyZCBib2R5 IHdlIGNhbiBwcm9iYWJseSBpZ25vcmUgdGhhdC4gQXMgYSBkZXZpY2UgbWFudWZhY3R1cmVyIHRo YXQgYnVpbGRzIFJQTCByb290cyBJIGNhbiBwcm9iYWJseSBub3QuIEkgd2lsbCBoYXZlIHRvIGNo b3NlIGJldHdlZW4gaWdub3JpbmcgdGhlIHJ1bGUgYW5kIHJlZW5jYXBzdWxhdGluZyB0aGUgcGFj a2V0IGZyb20gdGhlIHJvb3QgIHRvIGl0cyBmaW5hbCBkZXN0aW5hdGlvbi4NCg0KSSBndWVzcyB0 aGF04oCZcyBPSy4gQnV0IEkgcHJlZmVyIHRoZSBTUiB3YXkgdGhhdCBkb2N1bWVudHMgdGhlaXIg ZGV2aWF0aW9uIGluIGFuIG92ZXJyaWRpbmcgUkZDIGZvciB0aGVpciBjYXNlIGFuZCBsaXZlIHF1 aXRlIGhhcHBpbHkgd2l0aCBpdC4gQnV0IG1heWJlIHdlIGRvIG5vdCBoYXZlIGVub3VnaCByZWFs IGRlcGxveW1lbnRzIHRvIGJlbmQgdGhlIHJ1bGVzLi4uDQoNClRha2UgY2FyZSwNCg0KUGFzY2Fs DQoNCkxlIDMwIG5vdi4gMjAxNyDDoCAwMzozOCwgTWljaGFlbCBSaWNoYXJkc29uIDxtY3IraWV0 ZkBzYW5kZWxtYW4uY2E8bWFpbHRvOm1jcitpZXRmQHNhbmRlbG1hbi5jYT4+IGEgw6ljcml0IDoN Cg0KDQpQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpIDxwdGh1YmVydEBjaXNjby5jb208bWFpbHRv OnB0aHViZXJ0QGNpc2NvLmNvbT4+IHdyb3RlOg0KSXRlbSAxIGlzIG5vdCBjb3JyZWN0LiBXZSBj YW4gYWN0dWFsbHkgY2hhbmdlIHRoZSBSUEkgaW4gbWlkIGZsaWdodC4NClJGQyA4MjAwIHNheXMg bm8gaW5zZXJ0aW9uIG9yIGRlbGV0aW9uIGZvciBIYkggYnV0IGRvZXMgbm90IHByZWNsdWRlDQpt b2RzLiBJbiBmYWN0IGV2ZXJ5IGhvcCBjaGFuZ2VzIHRoZSBSUEkgaW4gTm9ybWFsIFJQTCBiZWhh dmlvci4gSQ0KYWdyZWUgdGhhdCBjaGFuZ2luZyB0aGUgb3B0aW9uIHR5cGUgaXMgbW9yZSB2aW9s ZW50IHRob3VnaC4NCg0KV2UgY2FuJ3QgY2hhbmdlIHRoZSBSUEkgdHlwZSBjb2RlLCBqdXN0IHRo ZSBjb250ZW50cyBvZiB0aGUgaGVhZGVyIGl0c2VsZi4NCkl0IHdvdWxkIGJlIGRlbGV0ZSAweDYz IGhlYWRlciBhbmQgaW5zZXJ0IDB4MjMgaGVhZGVyLg0KDQpBbHNvIHBhY2tldHMgd2l0aCAweDYz IHByb2JhYmx5IG9iZXllZCB0aGUgYW5jaWVudCBydWxlcyB0aHVzIElQIGluIElQDQppbiB3aGlj aCBjYXNlIHRoZSByb290IGRlY2Fwc3VsYXRlcyBhbmQgdGhlIFJQSSBnb2VzLg0KDQpUcnVlLg0K DQotLQ0KTWljaGFlbCBSaWNoYXJkc29uIDxtY3IrSUVURkBzYW5kZWxtYW4uY2E8bWFpbHRvOm1j citJRVRGQHNhbmRlbG1hbi5jYT4+LCBTYW5kZWxtYW4gU29mdHdhcmUgV29ya3MNCi09IElQdjYg SW9UIGNvbnN1bHRpbmcgPS0NCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpSb2xsIG1haWxpbmcgbGlzdA0KUm9sbEBpZXRmLm9yZzxtYWlsdG86 Um9sbEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9s bA0K --_000_53D6466B96334795B16FFB9120F94D93ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQpJ IHVuZGVyc3RhbmQgaG93IHlvdSBzZWUgaXQgTWljaGFlbC4gTWFrZXMgc2Vuc2UgdG8gbWUuDQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5Ob3cgaWYgd2UgZG8gbm90IHJld3JpdGUgdGhlbiBpZiBh IHBhY2tldCBjb21lcyB0byB0aGUgcm9vdCB3aXRoIDB4NjMgYW5kIG5vIElQIGluIElQIHRoZSBy b290IHdpbGwgbm90IHJld3JpdGUuIElmIGl0IGZvbGxvd3MgdGhlIHJ1bGVzIGluIHRoZSBvcHMg ZHJhZnQgaXQgc2hvdWxkIGRyb3AgdGhlIHBhY2tldC4gQXQgbGVhc3QgaXQgY291bGQgcmVwb3J0 IGFuIGFsZXJ0IHRvIGRvY3VtZW50IHRoZSBpc3N1ZS4mbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8ZGl2PkJ1dCwgc2FtZSBhcyBsZWFraW5nIDB4MjMsIHRoYXQgaXMgYSByZWNpcGUg Zm9yIHVuaGFwcHkgY3VzdG9tZXJzLiBJbiBib3RoIGNhc2VzIHdlIHdhbnQgdG8gYXZvaWQga2Vl cGluZyB0aGUgUlBJIGluIHRoZSBvdXRlciBoZWFkZXIuIEluIGJvdGggY2FzZXMgaXQgaXMgdG8g YXZvaWQgaXNzdWVzIGZyb20gZGV2aWNlcyB0aGF0IGRvIG5vdCBmb2xsb3cgdGhlIHJ1bGVzIGJ1 dCB3aGljaCB3ZSBkbyBub3QgY29udHJvbCBlaXRoZXIuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPGRpdj5BcyBhIHN0YW5kYXJkIGJvZHkgd2UgY2FuIHByb2JhYmx5IGlnbm9yZSB0aGF0LiBB cyBhIGRldmljZSBtYW51ZmFjdHVyZXIgdGhhdCBidWlsZHMgUlBMIHJvb3RzIEkgY2FuIHByb2Jh Ymx5IG5vdC4gSSB3aWxsIGhhdmUgdG8gY2hvc2UgYmV0d2VlbiBpZ25vcmluZyB0aGUgcnVsZSBh bmQgcmVlbmNhcHN1bGF0aW5nIHRoZSBwYWNrZXQgZnJvbSB0aGUgcm9vdCAmbmJzcDt0byBpdHMg ZmluYWwgZGVzdGluYXRpb24uICZuYnNwOzxicj4NCjxicj4NCjxkaXY+DQo8ZGl2PkkgZ3Vlc3Mg dGhhdOKAmXMgT0suIEJ1dCBJIHByZWZlciB0aGUgU1Igd2F5IHRoYXQgZG9jdW1lbnRzIHRoZWly IGRldmlhdGlvbiBpbiBhbiBvdmVycmlkaW5nIFJGQyBmb3IgdGhlaXIgY2FzZSBhbmQgbGl2ZSBx dWl0ZSBoYXBwaWx5IHdpdGggaXQuIEJ1dCBtYXliZSB3ZSBkbyBub3QgaGF2ZSBlbm91Z2ggcmVh bCBkZXBsb3ltZW50cyB0byBiZW5kIHRoZSBydWxlcy4uLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxkaXY+VGFrZSBjYXJlLDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+UGFzY2Fs PC9kaXY+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KTGUgMzAgbm92LiAyMDE3IMOgIDAzOjM4LCBNaWNo YWVsIFJpY2hhcmRzb24gJmx0OzxhIGhyZWY9Im1haWx0bzptY3ImIzQzO2lldGZAc2FuZGVsbWFu LmNhIj5tY3ImIzQzO2lldGZAc2FuZGVsbWFuLmNhPC9hPiZndDsgYSDDqWNyaXQmbmJzcDs6PGJy Pg0KPGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXY+PHNwYW4+PC9z cGFuPjxicj4NCjxzcGFuPlBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkgJmx0OzxhIGhyZWY9Im1h aWx0bzpwdGh1YmVydEBjaXNjby5jb20iPnB0aHViZXJ0QGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3Rl Ojwvc3Bhbj48YnI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj5JdGVtIDEgaXMgbm90 IGNvcnJlY3QuIFdlIGNhbiBhY3R1YWxseSBjaGFuZ2UgdGhlIFJQSSBpbiBtaWQgZmxpZ2h0Ljwv c3Bhbj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj5S RkMgODIwMCBzYXlzIG5vIGluc2VydGlvbiBvciBkZWxldGlvbiBmb3IgSGJIIGJ1dCBkb2VzIG5v dCBwcmVjbHVkZTwvc3Bhbj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJj aXRlIj48c3Bhbj5tb2RzLiBJbiBmYWN0IGV2ZXJ5IGhvcCBjaGFuZ2VzIHRoZSBSUEkgaW4gTm9y bWFsIFJQTCBiZWhhdmlvci4gSTwvc3Bhbj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90 ZSB0eXBlPSJjaXRlIj48c3Bhbj5hZ3JlZSB0aGF0IGNoYW5naW5nIHRoZSBvcHRpb24gdHlwZSBp cyBtb3JlIHZpb2xlbnQgdGhvdWdoLjwvc3Bhbj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8c3Bhbj48 L3NwYW4+PGJyPg0KPHNwYW4+V2UgY2FuJ3QgY2hhbmdlIHRoZSBSUEkgdHlwZSBjb2RlLCBqdXN0 IHRoZSBjb250ZW50cyBvZiB0aGUgaGVhZGVyIGl0c2VsZi48L3NwYW4+PGJyPg0KPHNwYW4+SXQg d291bGQgYmUgZGVsZXRlIDB4NjMgaGVhZGVyIGFuZCBpbnNlcnQgMHgyMyBoZWFkZXIuPC9zcGFu Pjxicj4NCjxzcGFuPjwvc3Bhbj48YnI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj5B bHNvIHBhY2tldHMgd2l0aCAweDYzIHByb2JhYmx5IG9iZXllZCB0aGUgYW5jaWVudCBydWxlcyB0 aHVzIElQIGluIElQPC9zcGFuPjxicj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9 ImNpdGUiPjxzcGFuPmluIHdoaWNoIGNhc2UgdGhlIHJvb3QgZGVjYXBzdWxhdGVzIGFuZCB0aGUg UlBJIGdvZXMuPC9zcGFuPjxicj4NCjwvYmxvY2txdW90ZT4NCjxzcGFuPjwvc3Bhbj48YnI+DQo8 c3Bhbj5UcnVlLjwvc3Bhbj48YnI+DQo8c3Bhbj48L3NwYW4+PGJyPg0KPHNwYW4+LS08L3NwYW4+ PGJyPg0KPHNwYW4+TWljaGFlbCBSaWNoYXJkc29uICZsdDs8YSBocmVmPSJtYWlsdG86bWNyJiM0 MztJRVRGQHNhbmRlbG1hbi5jYSI+bWNyJiM0MztJRVRGQHNhbmRlbG1hbi5jYTwvYT4mZ3Q7LCBT YW5kZWxtYW4gU29mdHdhcmUgV29ya3M8L3NwYW4+PGJyPg0KPHNwYW4+LT0gSVB2NiBJb1QgY29u c3VsdGluZyA9LTwvc3Bhbj48YnI+DQo8c3Bhbj48L3NwYW4+PGJyPg0KPHNwYW4+PC9zcGFuPjxi cj4NCjxzcGFuPjwvc3Bhbj48YnI+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiPg0KPGRpdj48c3Bhbj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzwvc3Bhbj48YnI+DQo8c3Bhbj5Sb2xsIG1haWxpbmcgbGlzdDwvc3Bh bj48YnI+DQo8c3Bhbj48YSBocmVmPSJtYWlsdG86Um9sbEBpZXRmLm9yZyI+Um9sbEBpZXRmLm9y ZzwvYT48L3NwYW4+PGJyPg0KPHNwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9yb2xsIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3JvbGw8L2E+PC9zcGFuPjxicj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_53D6466B96334795B16FFB9120F94D93ciscocom_--