From nobody Mon Sep 1 02:19:04 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93DC01A02E5; Mon, 1 Sep 2014 02:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.251 X-Spam-Level: *** X-Spam-Status: No, score=3.251 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLOSJ69vEYgh; Mon, 1 Sep 2014 02:18:56 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E5871A02E3; Mon, 1 Sep 2014 02:18:55 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id D8A473B40FE; Mon, 1 Sep 2014 11:18:53 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.16]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id AF3B74C015; Mon, 1 Sep 2014 11:18:53 +0200 (CEST) Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.43]) by OPEXCLILH05.corporate.adroot.infra.ftgroup ([10.114.31.16]) with mapi id 14.03.0195.001; Mon, 1 Sep 2014 11:18:53 +0200 From: To: Haoweiguo , "Dongjie (Jimmy)" , "UTTARO, JAMES" , "'idr@ietf.org'" , "'l2vpn@ietf.org'" Thread-Topic: [Idr] New Version Notification for draft-hao-idr-flowspec-evpn-00.txt Thread-Index: AQHPveJIWJLTbI4GBU++fHvCm8LPj5vg93EAgANADICAB9cBMA== Date: Mon, 1 Sep 2014 09:18:53 +0000 Message-ID: <18151_1409563133_540439FD_18151_1643_1_9E32478DFA9976438E7A22F69B08FF92080C70@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: <20140820002030.18902.50278.idtracker@ietfa.amsl.com> , <29476_1408695761_53F6FDD1_29476_12929_1_9E32478DFA9976438E7A22F69B08FF9207DB14@OPEXCLILM34.corporate.adroot.infra.ftgroup>, <76CD132C3ADEF848BD84D028D243C927337098E0@nkgeml512-mbx.china.huawei.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.25.81224 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/jT1L3sueEJo0POutGP0fWZrYexQ Cc: liuweihang Subject: Re: [Idr] New Version Notification for draft-hao-idr-flowspec-evpn-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2014 09:18:58 -0000 SGksDQoNCj4gSW4gcHVyZSBMRFAgVlBMUyBzY2VuYXJpbywgbm8gQkdQIHByb3RvY29sIGNhbiBi ZSB1c2VkIGZvciBmbG93LXNwZWMsICBpIHRoaW5rIGV0aGVybmV0IGZsb3ctc3BlYyBpcyBoYXJk IHRvIGJlIGRlcGxveWVkIGluIHRoaXMgc2NlbmFyaW8uIEluIGFsbCBvdGhlciBzY2VuYXJpb3Ms IEJHUCBmbG93LXNwZWMgaXMgZWFzeSB0byBiZSBpbmNyZW1lbnRhbGx5IGRlcGxveWVkLg0KDQpJ TU8sIGl0IGRlcGVuZHMgb2YgdGhlIGN1cnJlbnQgZGVzaWduLiBJIGNvbXBsZXRlbHkgYWdyZWUg dGhhdCBvbiBhIHB1cmUgTDIgTVBMUyBuZXR3b3JrIHdpdGggbm8gQkdQIGF0IGFsbCwgaXQgd291 bGQgYmUgY29zdGx5IHRvIGRlcGxveSBCR1Agb25seSB0byBwZXJmb3JtIE1BQyBmaWx0ZXJpbmcg dXNpbmcgRlMuDQpCdXQgdGhlcmUgY291bGQgYmUgc29tZSBuZXR3b3JrIHVzaW5nIHB1cmUgTERQ IFZQTFMsIGJ1dCBzdGlsbCBoYXZpbmcgYW4gZXhpc3RpbmcgQkdQIGNvbnRyb2xwbGFuZSBmb3Ig c29tZSBvdGhlciBzZXJ2aWNlcy4gVGhpcyBjb250cm9sIHBsYW5lIGNhbiBiZSByZXVzZWQgZm9y IHVzaW5nIEZTLg0KSSB0aGluayBpdCdzIG5vdCB0aGUgcm9sZSBvZiB0aGlzIGRyYWZ0IHRvIHNh eSB3aGljaCBkZXNpZ24gaXMgZ29vZCBvciBiYWQuIFRoYXQncyB3aHkgSSB3b3VsZCBwcmVmZXIg dG8gbm90IGxpbWl0IHRoZSBhcHBsaWNhYmlsaXR5IG9mIHRoaXMgZHJhZnQuDQoNClN0ZXBoYW5l DQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEhhb3dlaWd1byBbbWFpbHRv Omhhb3dlaWd1b0BodWF3ZWkuY29tXSANClNlbnQ6IFdlZG5lc2RheSwgQXVndXN0IDI3LCAyMDE0 IDEzOjMxDQpUbzogRG9uZ2ppZSAoSmltbXkpOyBMSVRLT1dTS0kgU3RlcGhhbmUgU0NFL0lCTkY7 IFVUVEFSTywgSkFNRVM7ICdpZHJAaWV0Zi5vcmcnOyAnbDJ2cG5AaWV0Zi5vcmcnDQpDYzogbGl1 d2VpaGFuZw0KU3ViamVjdDogtPC4tDogW0lkcl0gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv ciBkcmFmdC1oYW8taWRyLWZsb3dzcGVjLWV2cG4tMDAudHh0DQoNCkhpIEppZSBhbmQgU3RlcGhh bmUsDQpGbG93LXNwZWMgcmVsaWVzIG9uIEJHUCBwcm90b2NvbCB0byBwcm9wYWdhdGUgQUNMIHJ1 bGVzLiBMMlZQTiBjYW4gYmUgY2xhc3NpZmllZCBpbnRvIEVWUE4gYW5kIFZQTFMuIFZQTFMgY2Fu IGJlIGZ1cnRoZXIgY2xhc3NpZmllZCBpbnRvIHRocmVlIGNhdGVnb3JpZXMgd2hpY2ggYXJlIEJH UCBWUExTLCBMRFAgVlBMUywgQkdQIEFEICtMRFAgVlBMUy4NCkluIHB1cmUgTERQIFZQTFMgc2Nl bmFyaW8sIG5vIEJHUCBwcm90b2NvbCBjYW4gYmUgdXNlZCBmb3IgZmxvdy1zcGVjLCAgaSB0aGlu ayBldGhlcm5ldCBmbG93LXNwZWMgaXMgaGFyZCB0byBiZSBkZXBsb3llZCBpbiB0aGlzIHNjZW5h cmlvLiBJbiBhbGwgb3RoZXIgc2NlbmFyaW9zLCBCR1AgZmxvdy1zcGVjIGlzIGVhc3kgdG8gYmUg aW5jcmVtZW50YWxseSBkZXBsb3llZC4NClRoYW5rcw0Kd2VpZ3VvDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6IERvbmdqaWUgKEppbW15KQ0Kt6LLzcqx vOQ6IDIwMTTE6jjUwjI1yNUgMTc6NTMNCsrVvP7Iyzogc3RlcGhhbmUubGl0a293c2tpQG9yYW5n ZS5jb207IEhhb3dlaWd1bzsgVVRUQVJPLCBKQU1FUzsgJ2lkckBpZXRmLm9yZyc7ICdsMnZwbkBp ZXRmLm9yZycNCrOty806IGxpdXdlaWhhbmcNCtb3zOI6IFJFOiBbSWRyXSBOZXcgVmVyc2lvbiBO b3RpZmljYXRpb24gZm9yICAgICAgZHJhZnQtaGFvLWlkci1mbG93c3BlYy1ldnBuLTAwLnR4dA0K DQpIaSwNCg0KQWZ0ZXIgcmVhZGluZyB0aGlzIGRyYWZ0LCBJIGFncmVlIHdpdGggU3RlcGhhbmUg dGhhdCB0aGUgbmV3IEZsb3cgU3BlYyBBRkkvU0FGSSBjb3VsZCBiZSBnZW5lcmFsaXplZCBmb3Ig TDIuDQoNClJlZ2FyZGluZyB0aGUgYXBwbGljYXRpb24gb2YgRlMgdG8gU0ROLCBzcGVjaWZpYyB1 c2UgY2FzZXMgbWF5IGhlbHAgdG8gaWxsdXN0cmF0ZSB0aGUgYmVuZWZpdHMgb2YgdXNpbmcgRlMg dGhhbiB1c2luZyBvdGhlciB0b29scy4NCg0KQmVzdCByZWdhcmRzLA0KSmllDQoNCj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSWRyIFttYWlsdG86aWRyLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiANCj4gc3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb20NCj4g U2VudDogRnJpZGF5LCBBdWd1c3QgMjIsIDIwMTQgNDoyMyBQTQ0KPiBUbzogSGFvd2VpZ3VvOyBV VFRBUk8sIEpBTUVTOyAnaWRyQGlldGYub3JnJzsgJ2wydnBuQGlldGYub3JnJw0KPiBDYzogbGl1 d2VpaGFuZw0KPiBTdWJqZWN0OiBSZTogW0lkcl0gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv ciANCj4gZHJhZnQtaGFvLWlkci1mbG93c3BlYy1ldnBuLTAwLnR4dA0KPg0KPiBIaSwNCj4NCj4g SSB0aGluayB0aGlzIGlzIGEgdmFsdWFibGUgYWRkaXRpb24sIGJ1dCBJIHdvdWxkIGxpa2UgdG8g c2VlIHRoZXNlIE1BQyANCj4gZmlsdGVycyBiZWluZyBhcHBsaWNhYmxlIGFsc28gdG8gSVB2NCBw bHVncyAoRlMgSVB2NCAmIFZQTnY0KQ0KPg0KPiBNb3Jlb3ZlciAsIHRoZSBuZXcgQUZJL1NBRkkg c2hvdWxkIG5vdCBiZSByZXN0cmljdGVkIHRvIEVWUE4sIGFueSBMMiANCj4gaW50ZXJmYWNlIG1h eSBiZSBpbnRlcmVzdGVkIGJ5IHN1Y2ggZmlsdGVyIChWUExTLCBiYXNpYyBMMiBzd2l0Y2hpbmcg Li4uKS4NCj4NCj4gUm91dGUgZGlzdGluZ3Vpc2hlciBtYXkgYmUgaXMgbWlzc2luZyAuLi4NCj4N Cj4gTm93IG1vcmUgZ2xvYmFsbHksIG1heSBiZSBpdCdzIHRpbWUgdG8gdGhpbmsgbW9yZSBnbG9i YWxseSBhYm91dCB0aGUgDQo+IGV2b2x1dGlvbiBvZiBGUy4gSSBwcmV0dHkgc2VlIEZTIGV2b2x1 dGlvbiBsYXJnZWx5IGJleW9uZCBERG9TIGRvbWFpbi4gDQo+IEZTIGlzIGEgdmVyeSBnb29kIHBy b3RvY29sIGZvciBTRE4gYXBwbGljYXRpb25zLiBUaGUgcXVlc3Rpb24gYmVoaW5kIA0KPiBpcyBk byB3ZSByZWFsbHkgbmVlZCB0byB3b3JrIHdpdGggbXVsdGlwbGUgYWRkcmVzcyBmYW1pbGllcyBm b3IgZWFjaCANCj4gdHlwZSBvZiAic2VydmljZSIvImludGVyZmFjZSB0eXBlIiB0byBmaWx0ZXIg b3IgZG8gd2UgbmVlZCB0byBoYXZlIGEgDQo+IG1vcmUgZ2xvYmFsIG1vZGVsIHdoZXJlIHdlIHdv dWxkIGJlIGFibGUgdG8gcHV0IGFueSB0eXBlIG9mIGZpbHRlciBhbnkgd2hlcmUgYW5kIGFwcGx5 IG11bHRpcGxlIGFjdGlvbnMgKG9wZW5mbG93IGxpa2UgRlMpLg0KPiBDb21wYXJlZCB0byBvcGVu ZmxvdywgRlMgaGFzIHRoZSBtYWdpYyB0byBlbmFibGUgbXVsdGlwb2ludCANCj4gZGlzdHJpYnV0 aW9uIG9mIGFjdGlvbnMuDQo+DQo+IEJlc3QgUmVnYXJkcywNCj4NCj4gU3RlcGhhbmUNCj4NCj4N Cj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSWRyIFttYWlsdG86aWRyLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBIYW93ZWlndW8NCj4gU2VudDogVGh1cnNkYXks IEF1Z3VzdCAyMSwgMjAxNCAwNDoxMQ0KPiBUbzogVVRUQVJPLCBKQU1FUzsgJ2lkckBpZXRmLm9y Zyc7ICdsMnZwbkBpZXRmLm9yZycNCj4gQ2M6IGxpdXdlaWhhbmcNCj4gU3ViamVjdDogW0lkcl0g tPC4tDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciANCj4gZHJhZnQtaGFvLWlkci1mbG93 c3BlYy1ldnBuLTAwLnR4dA0KPg0KPiBIaSBKaW0sDQo+IFRoYW5rcyBmb3IgeW91ciBjb21tZW50 cy4gVGhlIEJHUCBGbG93c3BlYyBwcm9jZWR1cmVzIGlzIGlsbHVzdHJhdGVkIA0KPiBhcw0KPiBm b2xsb3dpbmc6DQo+DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IEVWUE4gRmxvd1NwZWMgU2Vzc2lvbiBFVlBOIA0KPiBGbG93U3BlYyBTZXNzaW9uIERET1MgRGV0 ZWN0aW9uIA0KPiBBcHBsaWFuY2UtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLUVncmVzcw0KPiBQ RS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tSW5ncmVzcyBQRS0tLS0tLUNFMg0KPg0KPiB8 DQo+DQo+IENFMSBERE9TIERldGVjdGlvbiBBcHBsaWFuY2UgZXN0YWJsaXNoZXMgRVZQTiBmbG93 c3BlYyBzZXNzaW9uIHdpdGggDQo+IEVncmVzcyBQRSwgaXQgZGV0ZWN0cyBERE9TIGF0dGFjayB0 cmFmZmljIGFuZCBnZW5lcmF0ZSBBQ0wgcnVsZSwgdGhlIA0KPiBBQ0wgcnVsZSBpcyBhbm5vdW5j ZWQgdG8gRWdyZXNzIFBFIHRocm91Z2ggRVZQTiBmbG93c3BlYyBwcm90b2NvbCwgDQo+IHRoZW4g dGhlIGVncmVzcyBQRSBhbm5vdW5jZXMgaXQgdG8gaW5ncmVzcyBQRSwgZmluYWxseSBpbmdyZXNz IFBFIA0KPiBpbnN0YWxscyB0aGUgQUNMIHJ1bGUgZm9yIHRyYWZmaWMgZmlsdGVyaW5nLg0KPiBE RE9TIERldGVjdGlvbiBBcHBsaWFuY2Ugb25seSBuZWVkcyB0byBzdXBwb3J0IEVWUE4gZmxvd3Nw ZWMgZnVuY3Rpb24sIA0KPiBpdCBkb2Vzbid0IG5lZWQgdG8gc3VwcG9ydCBiYXNpYyBFVlBOIGZ1 bmN0aW9uLg0KPiBUaGFua3MNCj4gd2VpZ3VvDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gt6K8/sjLOiBVVFRBUk8sIEpBTUVTIFtqdTE3MzhAYXR0LmNvbV0N Cj4gt6LLzcqxvOQ6IDIwMTTE6jjUwjIxyNUgMDoyOQ0KPiDK1bz+yMs6IEhhb3dlaWd1bzsgJ2lk ckBpZXRmLm9yZyc7ICdsMnZwbkBpZXRmLm9yZycNCj4gs63LzTogbGl1d2VpaGFuZw0KPiDW98zi OiBSRTogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciANCj4gZHJhZnQtaGFvLWlkci1mbG93 c3BlYy1ldnBuLTAwLnR4dA0KPg0KPiBXZWlndW8sDQo+DQo+ICAgICAgICAgSSB3b3VsZCBsaWtl IHRvIGJldHRlciB1bmRlcnN0YW5kIGhvdyBhIHJlbW90ZSBQRSB3aWxsICJsZWFybiIgDQo+IHRo YXQgaXQgbmVlZHMgdG8gZGVsaXZlciBhIEZTIHBhdGggdG8gdGhlIGluZ3Jlc3MgUEU/PyBJdCBj YW5ub3QgY29tZSANCj4gZnJvbSB0aGUgQ0UgYXMgdGhhdCBpcyBkYXRhIHBsYW5lIGxlYXJuaW5n LiBJIHdvdWxkIHRoaW5rIHRoYXQgYWxsIEZTIA0KPiBwYXRocyBoYXZlIHRvIGJlIGRpc3NlbWlu YXRlZCBieSBhIGNlbnRyYWxpemVkIGNvbnRyb2xsZXIuDQo+DQo+IEppbSBVdHRhcm8NCj4NCj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSWRyIFttYWlsdG86aWRyLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBIYW93ZWlndW8NCj4gU2VudDogVHVlc2RheSwgQXVn dXN0IDE5LCAyMDE0IDg6MzEgUE0NCj4gVG86IGlkckBpZXRmLm9yZzsgbDJ2cG5AaWV0Zi5vcmcN Cj4gQ2M6IGxpdXdlaWhhbmcNCj4gU3ViamVjdDogW0lkcl0gtPC4tDogTmV3IFZlcnNpb24gTm90 aWZpY2F0aW9uIGZvciANCj4gZHJhZnQtaGFvLWlkci1mbG93c3BlYy1ldnBuLTAwLnR4dA0KPg0K PiBIaSBBbGwsDQo+IFdlIGhhdmUgc3VibWl0dGVkIGEgZHJhZnQgb2YgIiBEaXNzZW1pbmF0aW9u IG9mIEZsb3cgU3BlY2lmaWNhdGlvbiANCj4gUnVsZXMgZm9yIEVWUE4iLiAgSSB3aWxsIGFwcHJp Y2lhdGUgaWYgeW91IGNhbiBnaXZlIHVzIHNvbWUgc3VnZ2VzdGlvbnMgYW5kIGNvbW1lbnRzLg0K PiBUaGFua3MNCj4gd2VpZ3VvDQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gt6K8/sjLOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW2ludGVybmV0LWRy YWZ0c0BpZXRmLm9yZ10NCj4gt6LLzcqxvOQ6IDIwMTTE6jjUwjIwyNUgODoyMA0KPiDK1bz+yMs6 IFpodWFuZ3NodW53YW47IEhhb3dlaWd1bzsgbGl1d2VpaGFuZzsgWmh1YW5nc2h1bndhbjsgbGl1 d2VpaGFuZzsgDQo+IEhhb3dlaWd1bw0KPiDW98ziOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g Zm9yIGRyYWZ0LWhhby1pZHItZmxvd3NwZWMtZXZwbi0wMC50eHQNCj4NCj4gQSBuZXcgdmVyc2lv biBvZiBJLUQsIGRyYWZ0LWhhby1pZHItZmxvd3NwZWMtZXZwbi0wMC50eHQNCj4gaGFzIGJlZW4g c3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBXZWlndW8gSGFvIGFuZCBwb3N0ZWQgdG8gdGhlIElF VEYgDQo+IHJlcG9zaXRvcnkuDQo+DQo+IE5hbWU6ICAgICAgICAgICBkcmFmdC1oYW8taWRyLWZs b3dzcGVjLWV2cG4NCj4gUmV2aXNpb246ICAgICAgIDAwDQo+IFRpdGxlOiAgICAgICAgICBEaXNz ZW1pbmF0aW9uIG9mIEZsb3cgU3BlY2lmaWNhdGlvbiBSdWxlcyBmb3IgRVZQTg0KPiBEb2N1bWVu dCBkYXRlOiAgMjAxNC0wOC0yMA0KPiBHcm91cDogICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNz aW9uDQo+IFBhZ2VzOiAgICAgICAgICA3DQo+IFVSTDoNCj4gaHR0cDovL3d3dy5pZXRmLm9yZy9p bnRlcm5ldC1kcmFmdHMvZHJhZnQtaGFvLWlkci1mbG93c3BlYy1ldnBuLTAwLnR4dA0KPiBTdGF0 dXM6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWhhby1pZHItZmxv d3NwZWMtZXZwbi8NCj4gSHRtbGl6ZWQ6ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWhhby1pZHItZmxvd3NwZWMtZXZwbi0wMA0KPg0KPg0KPiBBYnN0cmFjdDoNCj4gICAg VGhpcyBkb2N1bWVudCBkZWZpbmVzIEJHUCBmbG93LXNwZWMgZXh0ZW5zaW9uIGZvciBFdGhlcm5l dCB0cmFmZmljDQo+ICAgIGZpbHRlcmluZyBpbiBFVlBOIG5ldHdvcmsuIEEgbmV3IEJHUCBOTFJJ IHR5cGUgKEFGST0yNSwgU0FGST1UQkQpDQo+ICAgIHZhbHVlIGlzIHByb3Bvc2VkIHRvIGlkZW50 aWZ5IEVWUE4gZmxvdy1zcGVjIGFwcGxpY2F0aW9uLiBBIG5ldw0KPiAgICBzdWJzZXQgb2YgY29t cG9uZW50IHR5cGVzIGFuZCBleHRlbmRlZCBjb21tdW5pdHkgYWxzbyBhcmUgZGVmaW5lZC4NCj4N Cj4NCj4NCj4NCj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51 dGVzIGZyb20gdGhlIHRpbWUgb2YgDQo+IHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZl cnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4NCj4gVGhl IElFVEYgU2VjcmV0YXJpYXQNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gSWRyIG1haWxpbmcgbGlzdA0KPiBJZHJAaWV0Zi5vcmcNCj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZHINCj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gSWRyIG1haWxpbmcgbGlzdA0KPiBJZHJA aWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZHINCj4N Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4NCj4gQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1 dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIA0KPiBjb25maWRlbnRpZWxsZXMgb3UgcHJp dmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYyBwYXMgZXRyZSBkaWZmdXNlcywgDQo+IGV4cGxv aXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1l c3NhZ2UgDQo+IHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyIGEgbCdleHBlZGl0ZXVy IGV0IGxlIGRldHJ1aXJlIGFpbnNpIA0KPiBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVz c2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgDQo+IGQnYWx0ZXJhdGlvbiwg T3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBh bHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KPg0KPiBUaGlzIG1lc3NhZ2UgYW5k IGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgDQo+IHByaXZpbGVn ZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsgdGhleSBzaG91bGQg bm90IA0KPiBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0 aW9uLg0KPiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ug bm90aWZ5IHRoZSBzZW5kZXIgYW5kIA0KPiBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0 YWNobWVudHMuDQo+IEFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFi bGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSANCj4gYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBm YWxzaWZpZWQuDQo+IFRoYW5rIHlvdS4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gSWRyIG1haWxpbmcgbGlzdA0KPiBJZHJAaWV0Zi5vcmcN Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZHINCgpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpD ZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZv cm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRv bmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRp b24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUg c2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVj ZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVz IGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2Ug bWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBt ZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHBy aXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBz aG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlz YXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBu b3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1l bnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBt ZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRo YW5rIHlvdS4KCg== From nobody Mon Sep 1 02:28:09 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE93E1A02E3; Mon, 1 Sep 2014 02:28:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.551 X-Spam-Level: X-Spam-Status: No, score=0.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9pvBfh_WwmUn; Mon, 1 Sep 2014 02:28:01 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C15471A02D5; Mon, 1 Sep 2014 02:28:00 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 53E432DC0CE; Mon, 1 Sep 2014 11:27:59 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.55]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 2FEE923807E; Mon, 1 Sep 2014 11:27:59 +0200 (CEST) Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.43]) by OPEXCLILH03.corporate.adroot.infra.ftgroup ([10.114.31.55]) with mapi id 14.03.0195.001; Mon, 1 Sep 2014 11:27:59 +0200 From: To: Haoweiguo , "UTTARO, JAMES" , "'idr@ietf.org'" , "'l2vpn@ietf.org'" Thread-Topic: New Version Notification for draft-hao-idr-flowspec-evpn-00.txt Thread-Index: AQHPvqEF5Cl2vO5yjka3RlNsOr2/kZvsDntg Date: Mon, 1 Sep 2014 09:27:58 +0000 Message-ID: <28799_1409563679_54043C1F_28799_2589_1_9E32478DFA9976438E7A22F69B08FF92080C92@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: <20140820002030.18902.50278.idtracker@ietfa.amsl.com> , , <29476_1408695761_53F6FDD1_29476_12929_1_9E32478DFA9976438E7A22F69B08FF9207DB14@OPEXCLILM34.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.9.1.61823 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/RSxsBoe16j5dhMAe39MBUBXtcxg Cc: liuweihang Subject: Re: [Idr] New Version Notification for draft-hao-idr-flowspec-evpn-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2014 09:28:04 -0000 W3dlaWd1b106IFRoYW5rcy4gQnV0IE1BQyBmaWx0ZXJzIG1heWJlIG5vdCBhcHBsaWNhYmxlIHRv IElQVjQgJlZQTnY0LCBiZWNhdXNlIGluIHRoaXMgY2FzZSwgTUFDIGluZm9ybWF0aW9uIHdpbGwg YmUgY2hhbmdlZCBvbiBkaWZmZXJlbnQgUEUgZGV2aWNlcywgYSBzaW5nbGUgQUNMIHJ1bGUgY2Fu J3QgaWRlbnRpZnkgYSBjb25zaXN0YW50IGZsb3cgYXQgZGlmZmVyZW50IFBFIGRldmljZXMuIFNv IGluIElQIG5ldHdvcmssIGZsb3ctc3BlYyBjYW4gb25seSBiZSBkZWZpbmVkIHVzaW5nIElQIHJl bGF0ZWQgaW5mb3JtYXRpb24uDQpbU0xJXSBJIGFncmVlIHdpdGggeW91ciBwb2ludCBidXQgSSB3 YXMgdGhpbmtpbmcgYWJvdXQgYSBmdXR1cmUgKGhvcGUgaXQgd2lsbCBoYXBwZW4gOikgd2hlbiB3 ZSB3aWxsIGJlIGFibGUgdG8gb2ZmZXIgTDIgYW5kIEwzIHNlcnZpY2VzIG9uIHRoZSBzYW1lIHBs dWcgKGluY2x1ZGluZyBzYW1lIFZMQU4sIHNvcnQgb2YgY29uY3VycmVudCByb3V0aW5nICYgYnJp ZGdpbmcgaW50ZXJmYWNlKS4gSW4gdGhpcyBzaXR1YXRpb24sIGlzIGl0IGdvb2QgdG8gdXNlIHR3 byBhZGRyZXNzIGZhbWlsaWVzIHRvIGZpbHRlciB0aGUgZGlmZmVyZW50IHNlcnZpY2VzID8gV2h5 IG5vdCB1c2luZyBvbmx5IG9uZSAuLi4NCg0KDQpbd2VpZ3VvXTogUkQgdXNhZ2UgaGFzIG5vIGRp ZmZlcmVuY2Ugd2l0aCBvcmlnaW5hbCBCR1AgVlBOIGRlZmluaWNhdGlvbi4gQ2FuIHlvdSBnaXZl IG1lIHNvbWUgbW9yZSBjbGFyaWZpY2F0aW9ucz8NCltTTEldIFJpZ2h0LCBidXQgUkZDNTU3NSBw cmVjaXNlcyB0aGF0IFJEIGlzIHBhcnQgb2YgTkxSSSBmb3IgVlBOIDoNCiJUaGUgTkxSSSBmb3Jt YXQgZm9yIHRoaXMgYWRkcmVzcyBmYW1pbHkgY29uc2lzdHMgb2YgYSBmaXhlZC1sZW5ndGgNCiAg IFJvdXRlIERpc3Rpbmd1aXNoZXIgZmllbGQgKDggYnl0ZXMpIGZvbGxvd2VkIGJ5IGEgZmxvdyBz cGVjaWZpY2F0aW9uLA0KICAgZm9sbG93aW5nIHRoZSBlbmNvZGluZyBkZWZpbmVkIGluIHRoaXMg ZG9jdW1lbnQuICBUaGUgTkxSSSBsZW5ndGgNCiAgIGZpZWxkIHNoYWxsIGluY2x1ZGUgYm90aCB0 aGUgOCBieXRlcyBvZiB0aGUgUm91dGUgRGlzdGluZ3Vpc2hlciBhcw0KICAgd2VsbCBhcyB0aGUg c3Vic2VxdWVudCBmbG93IHNwZWNpZmljYXRpb24uDQoiDQpJbiB5b3VyIGRvY3VtZW50ICwgSSBj YW4ndCBzZWUgdGhpcyAuLi4gYXMgeW91IGFyZSBkZWZpbmluZyBhIG5ldyBOTFJJLCB5b3UgbmVl ZCB0byBwcmVjaXNlIHRoZSBmb3JtYXQuDQoNCg0KDQpTdGVwaGFuZQ0KDQoNCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEhhb3dlaWd1byBbbWFpbHRvOmhhb3dlaWd1b0BodWF3 ZWkuY29tXSANClNlbnQ6IFNhdHVyZGF5LCBBdWd1c3QgMjMsIDIwMTQgMDk6MDgNClRvOiBMSVRL T1dTS0kgU3RlcGhhbmUgU0NFL0lCTkY7IFVUVEFSTywgSkFNRVM7ICdpZHJAaWV0Zi5vcmcnOyAn bDJ2cG5AaWV0Zi5vcmcnDQpDYzogbGl1d2VpaGFuZw0KU3ViamVjdDogtPC4tDogTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1oYW8taWRyLWZsb3dzcGVjLWV2cG4tMDAudHh0DQoN CkhpIFN0ZXBoYW5lLA0KVGhhbmtzIGZvciB5b3VyIGRldGFpbCBjb21tZW50cy4gUGxzIHNlZSBt eSByZXBseSBpbmxpbmUgd2l0aCBbd2VpZ3VvXSBiZWxvdy4NCndlaWd1bw0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6IHN0ZXBoYW5lLmxpdGtvd3Nr aUBvcmFuZ2UuY29tIFtzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbV0NCreiy83KsbzkOiAy MDE0xOo41MIyMsjVIDE2OjIyDQrK1bz+yMs6IEhhb3dlaWd1bzsgVVRUQVJPLCBKQU1FUzsgJ2lk ckBpZXRmLm9yZyc7ICdsMnZwbkBpZXRmLm9yZycNCrOty806IGxpdXdlaWhhbmcNCtb3zOI6IFJF OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWhhby1pZHItZmxvd3NwZWMtZXZw bi0wMC50eHQNCg0KSGksDQoNCkkgdGhpbmsgdGhpcyBpcyBhIHZhbHVhYmxlIGFkZGl0aW9uLCBi dXQgSSB3b3VsZCBsaWtlIHRvIHNlZSB0aGVzZSBNQUMgZmlsdGVycyBiZWluZyBhcHBsaWNhYmxl IGFsc28gdG8gSVB2NCBwbHVncyAoRlMgSVB2NCAmIFZQTnY0KQ0KW3dlaWd1b106IFRoYW5rcy4g QnV0IE1BQyBmaWx0ZXJzIG1heWJlIG5vdCBhcHBsaWNhYmxlIHRvIElQVjQgJlZQTnY0LCBiZWNh dXNlIGluIHRoaXMgY2FzZSwgTUFDIGluZm9ybWF0aW9uIHdpbGwgYmUgY2hhbmdlZCBvbiBkaWZm ZXJlbnQgUEUgZGV2aWNlcywgYSBzaW5nbGUgQUNMIHJ1bGUgY2FuJ3QgaWRlbnRpZnkgYSBjb25z aXN0YW50IGZsb3cgYXQgZGlmZmVyZW50IFBFIGRldmljZXMuIFNvIGluIElQIG5ldHdvcmssIGZs b3ctc3BlYyBjYW4gb25seSBiZSBkZWZpbmVkIHVzaW5nIElQIHJlbGF0ZWQgaW5mb3JtYXRpb24u DQoNCk1vcmVvdmVyICwgdGhlIG5ldyBBRkkvU0FGSSBzaG91bGQgbm90IGJlIHJlc3RyaWN0ZWQg dG8gRVZQTiwgYW55IEwyIGludGVyZmFjZSBtYXkgYmUgaW50ZXJlc3RlZCBieSBzdWNoIGZpbHRl ciAoVlBMUywgYmFzaWMgTDIgc3dpdGNoaW5nIC4uLikuDQpbd2VpZ3VvXTogWWVzLCBJIGFncmVl LiBGaXJzdGx5IGkgcHJvcG9zZSBFdGhlcm5ldCBmbG93LXNwZWMgb25seSBpbiBFVlBOIG5ldHdv cmssIGJlY2F1c2UgZmxvd3MtcGVjIHJlbGllcyBvbiBCR1AgcHJvdG9jb2wgYW5kIEVWUE4gaGFz IEJHUCBjb250cm9sIHBsYW5lLCBzbyBpdCB3aWxsIGJlIGVhc3kgdG8gZGVwbG95IEJHUCBmbG93 c3BlYyBpbiBFVlBOIG5ldHdvcmsuIElmIHdlIHdhbnQgdG8gZGVwbG95IHRoZSBmbG93LXNwZWMg aW4gVlBMUyBuZXR3b3JrLCBub3JtYWxseSBWUExTIG9ubHkgcmVsaWVzIG9uIExEUCBwcm90b2Nv bCwgYWRkaXRpb25hbCBwcm90b2NvbCBvZiBCR1AgZmxvdy1zcGVjIHNob3VsZCBiZSBkZXBsb3ll ZCBmb3IgTUFDIGZpbHRlcmluZy4NCklmIHRoZSBjb21tdW5pdHkgdGhpbmtzIGl0IGlzIG5lY2Vz c2FyeSB0byBpbnRyb2R1Y2UgZXRoZXJuZXQgZmxvdy1zcGVjIGZvciBhbGwgTDIgaW50ZXJmYWNl LCBpIGNhbiB1cGRhdGUgdGhpcyBwYXJ0IHRvIGxldCBpdCBub3QgYmUgcmVzdHJpY3RlZCB0byBF VlBOLg0KDQpSb3V0ZSBkaXN0aW5ndWlzaGVyIG1heSBiZSBpcyBtaXNzaW5nIC4uLg0KW3dlaWd1 b106IFJEIHVzYWdlIGhhcyBubyBkaWZmZXJlbmNlIHdpdGggb3JpZ2luYWwgQkdQIFZQTiBkZWZp bmljYXRpb24uIENhbiB5b3UgZ2l2ZSBtZSBzb21lIG1vcmUgY2xhcmlmaWNhdGlvbnM/DQoNCk5v dyBtb3JlIGdsb2JhbGx5LCBtYXkgYmUgaXQncyB0aW1lIHRvIHRoaW5rIG1vcmUgZ2xvYmFsbHkg YWJvdXQgdGhlIGV2b2x1dGlvbiBvZiBGUy4gSSBwcmV0dHkgc2VlIEZTIGV2b2x1dGlvbiBsYXJn ZWx5IGJleW9uZCBERG9TIGRvbWFpbi4gRlMgaXMgYSB2ZXJ5IGdvb2QgcHJvdG9jb2wgZm9yIFNE TiBhcHBsaWNhdGlvbnMuIFRoZSBxdWVzdGlvbiBiZWhpbmQgaXMgZG8gd2UgcmVhbGx5IG5lZWQg dG8gd29yayB3aXRoIG11bHRpcGxlIGFkZHJlc3MgZmFtaWxpZXMgZm9yIGVhY2ggdHlwZSBvZiAi c2VydmljZSIvImludGVyZmFjZSB0eXBlIiB0byBmaWx0ZXIgb3IgZG8gd2UgbmVlZCB0byBoYXZl IGEgbW9yZSBnbG9iYWwgbW9kZWwgd2hlcmUgd2Ugd291bGQgYmUgYWJsZSB0byBwdXQgYW55IHR5 cGUgb2YgZmlsdGVyIGFueSB3aGVyZSBhbmQgYXBwbHkgbXVsdGlwbGUgYWN0aW9ucyAob3BlbmZs b3cgbGlrZSBGUykuIENvbXBhcmVkIHRvIG9wZW5mbG93LCBGUyBoYXMgdGhlIG1hZ2ljIHRvIGVu YWJsZSBtdWx0aXBvaW50IGRpc3RyaWJ1dGlvbiBvZiBhY3Rpb25zLg0KDQpbd2VpZ3VvXTogWWVz LCBCR1AgZmxvdy1zcGVjIGNhbiBiZSBhcHBsaWNhYmxlIGZvciBzb21lIFNETiBhcHBsaWNhdGlv bnMuIEl0IGhhcyBtb3JlIHBvdGVudGlhbCB0byBkbyBtb3JlIGF0dGFjdGl2ZSB0aGluZ3MuDQoN CkJlc3QgUmVnYXJkcywNCg0KU3RlcGhhbmUNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogSWRyIFttYWlsdG86aWRyLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBI YW93ZWlndW8NClNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMjEsIDIwMTQgMDQ6MTENClRvOiBVVFRB Uk8sIEpBTUVTOyAnaWRyQGlldGYub3JnJzsgJ2wydnBuQGlldGYub3JnJw0KQ2M6IGxpdXdlaWhh bmcNClN1YmplY3Q6IFtJZHJdILTwuLQ6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJh ZnQtaGFvLWlkci1mbG93c3BlYy1ldnBuLTAwLnR4dA0KDQpIaSBKaW0sDQpUaGFua3MgZm9yIHlv dXIgY29tbWVudHMuIFRoZSBCR1AgRmxvd3NwZWMgcHJvY2VkdXJlcyBpcyBpbGx1c3RyYXRlZCBh cyBmb2xsb3dpbmc6DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IEVWUE4gRmxvd1NwZWMgU2Vzc2lvbiAgICAgICAgICAgICAgICAgIEVWUE4gRmxvd1NwZWMgU2Vz c2lvbg0KRERPUyBEZXRlY3Rpb24gQXBwbGlhbmNlLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS1F Z3Jlc3MgUEUtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLUluZ3Jlc3MgUEUtLS0tLS1DRTIN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBDRTEgRERPUyBEZXRlY3Rpb24gQXBwbGlhbmNlIGVzdGFibGlzaGVzIEVWUE4gZmxv d3NwZWMgc2Vzc2lvbiB3aXRoIEVncmVzcyBQRSwgaXQgZGV0ZWN0cyBERE9TIGF0dGFjayB0cmFm ZmljIGFuZCBnZW5lcmF0ZSBBQ0wgcnVsZSwgdGhlIEFDTCBydWxlIGlzIGFubm91bmNlZCB0byBF Z3Jlc3MgUEUgdGhyb3VnaCBFVlBOIGZsb3dzcGVjIHByb3RvY29sLCB0aGVuIHRoZSBlZ3Jlc3Mg UEUgYW5ub3VuY2VzIGl0IHRvIGluZ3Jlc3MgUEUsIGZpbmFsbHkgaW5ncmVzcyBQRSBpbnN0YWxs cyB0aGUgQUNMIHJ1bGUgZm9yIHRyYWZmaWMgZmlsdGVyaW5nLg0KRERPUyBEZXRlY3Rpb24gQXBw bGlhbmNlIG9ubHkgbmVlZHMgdG8gc3VwcG9ydCBFVlBOIGZsb3dzcGVjIGZ1bmN0aW9uLCBpdCBk b2Vzbid0IG5lZWQgdG8gc3VwcG9ydCBiYXNpYyBFVlBOIGZ1bmN0aW9uLg0KVGhhbmtzDQp3ZWln dW8NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCreivP7IyzogVVRU QVJPLCBKQU1FUyBbanUxNzM4QGF0dC5jb21dDQq3osvNyrG85DogMjAxNMTqONTCMjHI1SAwOjI5 DQrK1bz+yMs6IEhhb3dlaWd1bzsgJ2lkckBpZXRmLm9yZyc7ICdsMnZwbkBpZXRmLm9yZycNCrOt y806IGxpdXdlaWhhbmcNCtb3zOI6IFJFOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRy YWZ0LWhhby1pZHItZmxvd3NwZWMtZXZwbi0wMC50eHQNCg0KV2VpZ3VvLA0KDQogICAgICAgIEkg d291bGQgbGlrZSB0byBiZXR0ZXIgdW5kZXJzdGFuZCBob3cgYSByZW1vdGUgUEUgd2lsbCAibGVh cm4iIHRoYXQgaXQgbmVlZHMgdG8gZGVsaXZlciBhIEZTIHBhdGggdG8gdGhlIGluZ3Jlc3MgUEU/ PyBJdCBjYW5ub3QgY29tZSBmcm9tIHRoZSBDRSBhcyB0aGF0IGlzIGRhdGEgcGxhbmUgbGVhcm5p bmcuIEkgd291bGQgdGhpbmsgdGhhdCBhbGwgRlMgcGF0aHMgaGF2ZSB0byBiZSBkaXNzZW1pbmF0 ZWQgYnkgYSBjZW50cmFsaXplZCBjb250cm9sbGVyLg0KDQpKaW0gVXR0YXJvDQoNCi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBJZHIgW21haWx0bzppZHItYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIEhhb3dlaWd1bw0KU2VudDogVHVlc2RheSwgQXVndXN0IDE5LCAyMDE0 IDg6MzEgUE0NClRvOiBpZHJAaWV0Zi5vcmc7IGwydnBuQGlldGYub3JnDQpDYzogbGl1d2VpaGFu Zw0KU3ViamVjdDogW0lkcl0gtPC4tDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFm dC1oYW8taWRyLWZsb3dzcGVjLWV2cG4tMDAudHh0DQoNCkhpIEFsbCwNCldlIGhhdmUgc3VibWl0 dGVkIGEgZHJhZnQgb2YgIiBEaXNzZW1pbmF0aW9uIG9mIEZsb3cgU3BlY2lmaWNhdGlvbiBSdWxl cyBmb3IgRVZQTiIuICBJIHdpbGwgYXBwcmljaWF0ZSBpZiB5b3UgY2FuIGdpdmUgdXMgc29tZSBz dWdnZXN0aW9ucyBhbmQgY29tbWVudHMuDQpUaGFua3MNCndlaWd1bw0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6IGludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZyBbaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0Kt6LLzcqxvOQ6IDIwMTTE6jjUwjIwyNUg ODoyMA0KytW8/sjLOiBaaHVhbmdzaHVud2FuOyBIYW93ZWlndW87IGxpdXdlaWhhbmc7IFpodWFu Z3NodW53YW47IGxpdXdlaWhhbmc7IEhhb3dlaWd1bw0K1vfM4jogTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvciBkcmFmdC1oYW8taWRyLWZsb3dzcGVjLWV2cG4tMDAudHh0DQoNCkEgbmV3IHZl cnNpb24gb2YgSS1ELCBkcmFmdC1oYW8taWRyLWZsb3dzcGVjLWV2cG4tMDAudHh0DQpoYXMgYmVl biBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFdlaWd1byBIYW8gYW5kIHBvc3RlZCB0byB0aGUg SUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOiAgICAgICAgICAgZHJhZnQtaGFvLWlkci1mbG93c3Bl Yy1ldnBuDQpSZXZpc2lvbjogICAgICAgMDANClRpdGxlOiAgICAgICAgICBEaXNzZW1pbmF0aW9u IG9mIEZsb3cgU3BlY2lmaWNhdGlvbiBSdWxlcyBmb3IgRVZQTg0KRG9jdW1lbnQgZGF0ZTogIDIw MTQtMDgtMjANCkdyb3VwOiAgICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOiAg ICAgICAgICA3DQpVUkw6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1k cmFmdHMvZHJhZnQtaGFvLWlkci1mbG93c3BlYy1ldnBuLTAwLnR4dA0KU3RhdHVzOiAgICAgICAg IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWhhby1pZHItZmxvd3NwZWMt ZXZwbi8NCkh0bWxpemVkOiAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1o YW8taWRyLWZsb3dzcGVjLWV2cG4tMDANCg0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQg ZGVmaW5lcyBCR1AgZmxvdy1zcGVjIGV4dGVuc2lvbiBmb3IgRXRoZXJuZXQgdHJhZmZpYw0KICAg ZmlsdGVyaW5nIGluIEVWUE4gbmV0d29yay4gQSBuZXcgQkdQIE5MUkkgdHlwZSAoQUZJPTI1LCBT QUZJPVRCRCkNCiAgIHZhbHVlIGlzIHByb3Bvc2VkIHRvIGlkZW50aWZ5IEVWUE4gZmxvdy1zcGVj IGFwcGxpY2F0aW9uLiBBIG5ldw0KICAgc3Vic2V0IG9mIGNvbXBvbmVudCB0eXBlcyBhbmQgZXh0 ZW5kZWQgY29tbXVuaXR5IGFsc28gYXJlIGRlZmluZWQuDQoNCg0KDQoNClBsZWFzZSBub3RlIHRo YXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1p c3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBh dCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJZHIgbWFpbGluZyBsaXN0DQpJZHJA aWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRyDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSWRyIG1haWxpbmcg bGlzdA0KSWRyQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2lkcg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQoNCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZl bnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdp ZWVzIGV0IG5lIGRvaXZlbnQgZG9uYyBwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNv cGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIg ZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlciBhIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWly ZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVl cyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLCBPcmFuZ2UgZGVjbGluZSB0b3V0ZSBy ZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxz aWZpZS4gTWVyY2kuDQoNClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250 YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHBy b3RlY3RlZCBieSBsYXc7IHRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBj b3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBl bWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBt ZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9y YW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwg Y2hhbmdlZCBvciBmYWxzaWZpZWQuDQpUaGFuayB5b3UuDQoKX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBl dCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNv bmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJl IGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3Vz IGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEg bCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMu IExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRp b24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBl dGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQg aXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGlu Zm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBi ZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5 b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBz ZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1h aWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhh dCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= From nobody Mon Sep 1 02:30:06 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F33A21A02E5 for ; Mon, 1 Sep 2014 02:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i5SxeaRgGnam for ; Mon, 1 Sep 2014 02:30:01 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E8E31A02D5 for ; Mon, 1 Sep 2014 02:30:00 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id 477DB1B818F; Mon, 1 Sep 2014 11:29:58 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.30]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 269F6C8080; Mon, 1 Sep 2014 11:29:58 +0200 (CEST) Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.43]) by OPEXCLILH02.corporate.adroot.infra.ftgroup ([10.114.31.30]) with mapi id 14.03.0195.001; Mon, 1 Sep 2014 11:29:58 +0200 From: To: Susan Hares , idr wg Thread-Topic: [Idr] WG LC Thread-Index: Ac/BReTO0pJPTvXCTT6RAuhkpoMwRwAocS6QAPfmrPA= Date: Mon, 1 Sep 2014 09:29:57 +0000 Message-ID: <21271_1409563798_54043C96_21271_6004_1_9E32478DFA9976438E7A22F69B08FF92080CAB@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: <018e01cfc146$4be6c480$e3b44d80$@ndzh.com> <1B502206DFA0C544B7A60469152008633F36409D@eusaamb105.ericsson.se> In-Reply-To: <1B502206DFA0C544B7A60469152008633F36409D@eusaamb105.ericsson.se> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF92080CABOPEXCLILM34corpor_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.8.31.223625 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/wUMDpMlyjr5bqnKvvlskTb4k_aI Cc: Alia Atlas Subject: Re: [Idr] WG LC X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2014 09:30:04 -0000 --_000_9E32478DFA9976438E7A22F69B08FF92080CABOPEXCLILM34corpor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Tuesday, August 26, 2014 8:56 AM To: idr wg Cc: Alia Atlas Subject: [Idr] WG LC This is a 2 week WGT LC on draft-ietf-idr-as-migration starting 8/26/2014 a= nd ending 9/6/2014. The draft can be accessed at: http://datatracker.ietf.org/doc/draft-ietf-idr-as-migration/ Please include in your call "support or no support". This call also ask t= he authors to indicate if there is any IPR related to the draft. Sue ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_9E32478DFA9976438E7A22F69B08FF92080CABOPEXCLILM34corpor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Tuesday, August 26, 2014 8:56 AM
To: idr wg
Cc: Alia Atlas
Subject: [Idr] WG LC

 

This is a 2 week WGT LC on draft-ietf-idr-as-migrati= on starting 8/26/2014 and ending 9/6/2014.

 

The draft can be accessed at:

 

http://datatracker.ietf.org/doc/draft-ietf-idr-as-migr= ation/

 

Please include in your call “support or no sup= port”.   This call also ask the authors to indicate if ther= e is any IPR related to the draft.

 

Sue 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_9E32478DFA9976438E7A22F69B08FF92080CABOPEXCLILM34corpor_-- From nobody Mon Sep 1 02:30:25 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A1E41A02E4 for ; Mon, 1 Sep 2014 02:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gFGBwuPzXVNL for ; Mon, 1 Sep 2014 02:30:19 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB2D31A02E3 for ; Mon, 1 Sep 2014 02:30:18 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id 9343FC0081; Mon, 1 Sep 2014 11:30:17 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.56]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 72F11C8065; Mon, 1 Sep 2014 11:30:17 +0200 (CEST) Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.43]) by OPEXCLILH04.corporate.adroot.infra.ftgroup ([10.114.31.56]) with mapi id 14.03.0195.001; Mon, 1 Sep 2014 11:30:17 +0200 From: To: Susan Hares Thread-Topic: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-ietf-idr-ls-distribut-impl Thread-Index: Ac/BW2lXGFeOO91XQC6F7jVfIRzoQgEa+d7A Date: Mon, 1 Sep 2014 09:30:17 +0000 Message-ID: <21271_1409563817_54043CA9_21271_6013_1_9E32478DFA9976438E7A22F69B08FF92080CBE@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: <025201cfc15c$bbe17260$33a45720$@ndzh.com> In-Reply-To: <025201cfc15c$bbe17260$33a45720$@ndzh.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF92080CBEOPEXCLILM34corpor_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.8.31.223625 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/czswVzTUA7w28O8rGY12AO37kow Cc: "idr@ietf.org" Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-ietf-idr-ls-distribut-impl X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2014 09:30:22 -0000 --_000_9E32478DFA9976438E7A22F69B08FF92080CBEOPEXCLILM34corpor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Tuesday, August 26, 2014 20:37 To: idr@ietf.org Cc: 'John G. Scudder'; shares@ndzh.com Subject: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-ietf-idr-= ls-distribut-impl This is a WG LC for http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/ http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution-impl/ Please respond with comments and "support or no support." This WG LC also = includes a request for the authors to provide IPR on the subject. Please note: due to the European vacations in August, we are bundling these= three reviews into the next two weeks (these two drafts and draft-ietf-as-= migration). The chairs would like feedback (list or private email) whethe= r the three WG LC s impact anyone's ability to review these drafts carefull= y. Thank you, Sue Hares and John Scudder ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_9E32478DFA9976438E7A22F69B08FF92080CBEOPEXCLILM34corpor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support

 

 

From: Idr [mai= lto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Tuesday, August 26, 2014 20:37
To: idr@ietf.org
Cc: 'John G. Scudder'; shares@ndzh.com
Subject: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-ie= tf-idr-ls-distribut-impl

 

This is a WG LC for

 

  http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/

  http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution-impl/

 

Please respond with comments and “support or n= o support.”  This WG LC also includes a request for the authors = to provide IPR on the subject.

 

Please note: due to the European vacations in August= , we are bundling these three reviews into the next two weeks (these two dr= afts and draft-ietf-as-migration).   The chairs would like feedba= ck (list or private email) whether the three WG LC s impact anyone’s ability to review these drafts carefully.

 

Thank you,

 

Sue Hares and John Scudder

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_9E32478DFA9976438E7A22F69B08FF92080CBEOPEXCLILM34corpor_-- From nobody Mon Sep 1 04:36:04 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3397E1A039A; Mon, 1 Sep 2014 04:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.081 X-Spam-Level: * X-Spam-Status: No, score=1.081 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4R4npJP5qpUt; Mon, 1 Sep 2014 04:36:00 -0700 (PDT) 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 83AE31A0398; Mon, 1 Sep 2014 04:35:59 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLZ50856; Mon, 01 Sep 2014 11:35:58 +0000 (GMT) Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 1 Sep 2014 12:35:57 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.209]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Mon, 1 Sep 2014 19:35:44 +0800 From: Haoweiguo To: "stephane.litkowski@orange.com" , "Dongjie (Jimmy)" , "UTTARO, JAMES" , "'idr@ietf.org'" , "'l2vpn@ietf.org'" Thread-Topic: [Idr] New Version Notification for draft-hao-idr-flowspec-evpn-00.txt Thread-Index: AQHPwEpl0MndSDFfVU6P6bRKSaxL45vkUKCBgAc0LoCAAKrDwQ== Date: Mon, 1 Sep 2014 11:35:43 +0000 Message-ID: References: <20140820002030.18902.50278.idtracker@ietfa.amsl.com> , <29476_1408695761_53F6FDD1_29476_12929_1_9E32478DFA9976438E7A22F69B08FF9207DB14@OPEXCLILM34.corporate.adroot.infra.ftgroup>, <76CD132C3ADEF848BD84D028D243C927337098E0@nkgeml512-mbx.china.huawei.com> , <18151_1409563133_540439FD_18151_1643_1_9E32478DFA9976438E7A22F69B08FF92080C70@OPEXCLILM34.corporate.adroot.infra.ftgroup> In-Reply-To: <18151_1409563133_540439FD_18151_1643_1_9E32478DFA9976438E7A22F69B08FF92080C70@OPEXCLILM34.corporate.adroot.infra.ftgroup> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.23.94] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/idr/xKskYV8-zA8S1ex0zRm_4NJSweQ Cc: liuweihang Subject: [Idr] =?gb2312?b?tPC4tDogIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IJ?= =?gb2312?b?ZHJhZnQtaGFvLWlkci1mbG93c3BlYy1ldnBuLTAwLnR4dA==?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2014 11:36:03 -0000 SGkgU3RlcGhhbmUsDQpJIGFncmVlIHdpdGggeW91LiBUaGUgZmxvdy1zcGVjIGFwcGxpY2FiaWxp dHkgc2NvcGUgY2FuIGJlIGVubGFyZ2VkIHRvIEwyVlBOIGFyZWEuIElmIHRoZXJlIHdlcmUgQkdQ IGNvbnRyb2wgcGxhbmUgZGVwbG95ZWQsIGl0IHdpbGwgYmUgZWFzaWVyIHRvIGluY3JlbWVudGFs bHkgZGVwbG95IE1BQyBmaWx0ZXJpbmcgdXNpbmcgRlMuDQpUaGFua3MNCndlaWd1bw0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6IHN0ZXBoYW5lLmxp dGtvd3NraUBvcmFuZ2UuY29tIFtzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbV0NCreiy83K sbzkOiAyMDE0xOo51MIxyNUgMTc6MTgNCsrVvP7IyzogSGFvd2VpZ3VvOyBEb25namllIChKaW1t eSk7IFVUVEFSTywgSkFNRVM7ICdpZHJAaWV0Zi5vcmcnOyAnbDJ2cG5AaWV0Zi5vcmcnDQqzrcvN OiBsaXV3ZWloYW5nDQrW98ziOiBSRTogW0lkcl0gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv ciAgICAgIGRyYWZ0LWhhby1pZHItZmxvd3NwZWMtZXZwbi0wMC50eHQNCg0KSGksDQoNCj4gSW4g cHVyZSBMRFAgVlBMUyBzY2VuYXJpbywgbm8gQkdQIHByb3RvY29sIGNhbiBiZSB1c2VkIGZvciBm bG93LXNwZWMsICBpIHRoaW5rIGV0aGVybmV0IGZsb3ctc3BlYyBpcyBoYXJkIHRvIGJlIGRlcGxv eWVkIGluIHRoaXMgc2NlbmFyaW8uIEluIGFsbCBvdGhlciBzY2VuYXJpb3MsIEJHUCBmbG93LXNw ZWMgaXMgZWFzeSB0byBiZSBpbmNyZW1lbnRhbGx5IGRlcGxveWVkLg0KDQpJTU8sIGl0IGRlcGVu ZHMgb2YgdGhlIGN1cnJlbnQgZGVzaWduLiBJIGNvbXBsZXRlbHkgYWdyZWUgdGhhdCBvbiBhIHB1 cmUgTDIgTVBMUyBuZXR3b3JrIHdpdGggbm8gQkdQIGF0IGFsbCwgaXQgd291bGQgYmUgY29zdGx5 IHRvIGRlcGxveSBCR1Agb25seSB0byBwZXJmb3JtIE1BQyBmaWx0ZXJpbmcgdXNpbmcgRlMuDQpC dXQgdGhlcmUgY291bGQgYmUgc29tZSBuZXR3b3JrIHVzaW5nIHB1cmUgTERQIFZQTFMsIGJ1dCBz dGlsbCBoYXZpbmcgYW4gZXhpc3RpbmcgQkdQIGNvbnRyb2xwbGFuZSBmb3Igc29tZSBvdGhlciBz ZXJ2aWNlcy4gVGhpcyBjb250cm9sIHBsYW5lIGNhbiBiZSByZXVzZWQgZm9yIHVzaW5nIEZTLg0K SSB0aGluayBpdCdzIG5vdCB0aGUgcm9sZSBvZiB0aGlzIGRyYWZ0IHRvIHNheSB3aGljaCBkZXNp Z24gaXMgZ29vZCBvciBiYWQuIFRoYXQncyB3aHkgSSB3b3VsZCBwcmVmZXIgdG8gbm90IGxpbWl0 IHRoZSBhcHBsaWNhYmlsaXR5IG9mIHRoaXMgZHJhZnQuDQoNClN0ZXBoYW5lDQoNCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEhhb3dlaWd1byBbbWFpbHRvOmhhb3dlaWd1b0Bo dWF3ZWkuY29tXQ0KU2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMjcsIDIwMTQgMTM6MzENClRvOiBE b25namllIChKaW1teSk7IExJVEtPV1NLSSBTdGVwaGFuZSBTQ0UvSUJORjsgVVRUQVJPLCBKQU1F UzsgJ2lkckBpZXRmLm9yZyc7ICdsMnZwbkBpZXRmLm9yZycNCkNjOiBsaXV3ZWloYW5nDQpTdWJq ZWN0OiC08Li0OiBbSWRyXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWhhby1p ZHItZmxvd3NwZWMtZXZwbi0wMC50eHQNCg0KSGkgSmllIGFuZCBTdGVwaGFuZSwNCkZsb3ctc3Bl YyByZWxpZXMgb24gQkdQIHByb3RvY29sIHRvIHByb3BhZ2F0ZSBBQ0wgcnVsZXMuIEwyVlBOIGNh biBiZSBjbGFzc2lmaWVkIGludG8gRVZQTiBhbmQgVlBMUy4gVlBMUyBjYW4gYmUgZnVydGhlciBj bGFzc2lmaWVkIGludG8gdGhyZWUgY2F0ZWdvcmllcyB3aGljaCBhcmUgQkdQIFZQTFMsIExEUCBW UExTLCBCR1AgQUQgK0xEUCBWUExTLg0KSW4gcHVyZSBMRFAgVlBMUyBzY2VuYXJpbywgbm8gQkdQ IHByb3RvY29sIGNhbiBiZSB1c2VkIGZvciBmbG93LXNwZWMsICBpIHRoaW5rIGV0aGVybmV0IGZs b3ctc3BlYyBpcyBoYXJkIHRvIGJlIGRlcGxveWVkIGluIHRoaXMgc2NlbmFyaW8uIEluIGFsbCBv dGhlciBzY2VuYXJpb3MsIEJHUCBmbG93LXNwZWMgaXMgZWFzeSB0byBiZSBpbmNyZW1lbnRhbGx5 IGRlcGxveWVkLg0KVGhhbmtzDQp3ZWlndW8NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCreivP7IyzogRG9uZ2ppZSAoSmltbXkpDQq3osvNyrG85DogMjAxNMTqONTC MjXI1SAxNzo1Mw0KytW8/sjLOiBzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbTsgSGFvd2Vp Z3VvOyBVVFRBUk8sIEpBTUVTOyAnaWRyQGlldGYub3JnJzsgJ2wydnBuQGlldGYub3JnJw0Ks63L zTogbGl1d2VpaGFuZw0K1vfM4jogUkU6IFtJZHJdIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBm b3IgICAgICBkcmFmdC1oYW8taWRyLWZsb3dzcGVjLWV2cG4tMDAudHh0DQoNCkhpLA0KDQpBZnRl ciByZWFkaW5nIHRoaXMgZHJhZnQsIEkgYWdyZWUgd2l0aCBTdGVwaGFuZSB0aGF0IHRoZSBuZXcg RmxvdyBTcGVjIEFGSS9TQUZJIGNvdWxkIGJlIGdlbmVyYWxpemVkIGZvciBMMi4NCg0KUmVnYXJk aW5nIHRoZSBhcHBsaWNhdGlvbiBvZiBGUyB0byBTRE4sIHNwZWNpZmljIHVzZSBjYXNlcyBtYXkg aGVscCB0byBpbGx1c3RyYXRlIHRoZSBiZW5lZml0cyBvZiB1c2luZyBGUyB0aGFuIHVzaW5nIG90 aGVyIHRvb2xzLg0KDQpCZXN0IHJlZ2FyZHMsDQpKaWUNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiBGcm9tOiBJZHIgW21haWx0bzppZHItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mDQo+IHN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tDQo+IFNlbnQ6IEZyaWRheSwg QXVndXN0IDIyLCAyMDE0IDQ6MjMgUE0NCj4gVG86IEhhb3dlaWd1bzsgVVRUQVJPLCBKQU1FUzsg J2lkckBpZXRmLm9yZyc7ICdsMnZwbkBpZXRmLm9yZycNCj4gQ2M6IGxpdXdlaWhhbmcNCj4gU3Vi amVjdDogUmU6IFtJZHJdIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCj4gZHJhZnQtaGFv LWlkci1mbG93c3BlYy1ldnBuLTAwLnR4dA0KPg0KPiBIaSwNCj4NCj4gSSB0aGluayB0aGlzIGlz IGEgdmFsdWFibGUgYWRkaXRpb24sIGJ1dCBJIHdvdWxkIGxpa2UgdG8gc2VlIHRoZXNlIE1BQw0K PiBmaWx0ZXJzIGJlaW5nIGFwcGxpY2FibGUgYWxzbyB0byBJUHY0IHBsdWdzIChGUyBJUHY0ICYg VlBOdjQpDQo+DQo+IE1vcmVvdmVyICwgdGhlIG5ldyBBRkkvU0FGSSBzaG91bGQgbm90IGJlIHJl c3RyaWN0ZWQgdG8gRVZQTiwgYW55IEwyDQo+IGludGVyZmFjZSBtYXkgYmUgaW50ZXJlc3RlZCBi eSBzdWNoIGZpbHRlciAoVlBMUywgYmFzaWMgTDIgc3dpdGNoaW5nIC4uLikuDQo+DQo+IFJvdXRl IGRpc3Rpbmd1aXNoZXIgbWF5IGJlIGlzIG1pc3NpbmcgLi4uDQo+DQo+IE5vdyBtb3JlIGdsb2Jh bGx5LCBtYXkgYmUgaXQncyB0aW1lIHRvIHRoaW5rIG1vcmUgZ2xvYmFsbHkgYWJvdXQgdGhlDQo+ IGV2b2x1dGlvbiBvZiBGUy4gSSBwcmV0dHkgc2VlIEZTIGV2b2x1dGlvbiBsYXJnZWx5IGJleW9u ZCBERG9TIGRvbWFpbi4NCj4gRlMgaXMgYSB2ZXJ5IGdvb2QgcHJvdG9jb2wgZm9yIFNETiBhcHBs aWNhdGlvbnMuIFRoZSBxdWVzdGlvbiBiZWhpbmQNCj4gaXMgZG8gd2UgcmVhbGx5IG5lZWQgdG8g d29yayB3aXRoIG11bHRpcGxlIGFkZHJlc3MgZmFtaWxpZXMgZm9yIGVhY2gNCj4gdHlwZSBvZiAi c2VydmljZSIvImludGVyZmFjZSB0eXBlIiB0byBmaWx0ZXIgb3IgZG8gd2UgbmVlZCB0byBoYXZl IGENCj4gbW9yZSBnbG9iYWwgbW9kZWwgd2hlcmUgd2Ugd291bGQgYmUgYWJsZSB0byBwdXQgYW55 IHR5cGUgb2YgZmlsdGVyIGFueSB3aGVyZSBhbmQgYXBwbHkgbXVsdGlwbGUgYWN0aW9ucyAob3Bl bmZsb3cgbGlrZSBGUykuDQo+IENvbXBhcmVkIHRvIG9wZW5mbG93LCBGUyBoYXMgdGhlIG1hZ2lj IHRvIGVuYWJsZSBtdWx0aXBvaW50DQo+IGRpc3RyaWJ1dGlvbiBvZiBhY3Rpb25zLg0KPg0KPiBC ZXN0IFJlZ2FyZHMsDQo+DQo+IFN0ZXBoYW5lDQo+DQo+DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+IEZyb206IElkciBbbWFpbHRvOmlkci1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgSGFvd2VpZ3VvDQo+IFNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMjEsIDIwMTQgMDQ6MTEN Cj4gVG86IFVUVEFSTywgSkFNRVM7ICdpZHJAaWV0Zi5vcmcnOyAnbDJ2cG5AaWV0Zi5vcmcnDQo+ IENjOiBsaXV3ZWloYW5nDQo+IFN1YmplY3Q6IFtJZHJdILTwuLQ6IE5ldyBWZXJzaW9uIE5vdGlm aWNhdGlvbiBmb3INCj4gZHJhZnQtaGFvLWlkci1mbG93c3BlYy1ldnBuLTAwLnR4dA0KPg0KPiBI aSBKaW0sDQo+IFRoYW5rcyBmb3IgeW91ciBjb21tZW50cy4gVGhlIEJHUCBGbG93c3BlYyBwcm9j ZWR1cmVzIGlzIGlsbHVzdHJhdGVkDQo+IGFzDQo+IGZvbGxvd2luZzoNCj4NCj4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRVZQTiBGbG93U3BlYyBTZXNzaW9uIEVW UE4NCj4gRmxvd1NwZWMgU2Vzc2lvbiBERE9TIERldGVjdGlvbg0KPiBBcHBsaWFuY2UtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLUVncmVzcw0KPiBQRS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tSW5ncmVzcyBQRS0tLS0tLUNFMg0KPg0KPiB8DQo+DQo+IENFMSBERE9TIERldGVjdGlvbiBB cHBsaWFuY2UgZXN0YWJsaXNoZXMgRVZQTiBmbG93c3BlYyBzZXNzaW9uIHdpdGgNCj4gRWdyZXNz IFBFLCBpdCBkZXRlY3RzIERET1MgYXR0YWNrIHRyYWZmaWMgYW5kIGdlbmVyYXRlIEFDTCBydWxl LCB0aGUNCj4gQUNMIHJ1bGUgaXMgYW5ub3VuY2VkIHRvIEVncmVzcyBQRSB0aHJvdWdoIEVWUE4g Zmxvd3NwZWMgcHJvdG9jb2wsDQo+IHRoZW4gdGhlIGVncmVzcyBQRSBhbm5vdW5jZXMgaXQgdG8g aW5ncmVzcyBQRSwgZmluYWxseSBpbmdyZXNzIFBFDQo+IGluc3RhbGxzIHRoZSBBQ0wgcnVsZSBm b3IgdHJhZmZpYyBmaWx0ZXJpbmcuDQo+IERET1MgRGV0ZWN0aW9uIEFwcGxpYW5jZSBvbmx5IG5l ZWRzIHRvIHN1cHBvcnQgRVZQTiBmbG93c3BlYyBmdW5jdGlvbiwNCj4gaXQgZG9lc24ndCBuZWVk IHRvIHN1cHBvcnQgYmFzaWMgRVZQTiBmdW5jdGlvbi4NCj4gVGhhbmtzDQo+IHdlaWd1bw0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ILeivP7IyzogVVRUQVJP LCBKQU1FUyBbanUxNzM4QGF0dC5jb21dDQo+ILeiy83KsbzkOiAyMDE0xOo41MIyMcjVIDA6MjkN Cj4gytW8/sjLOiBIYW93ZWlndW87ICdpZHJAaWV0Zi5vcmcnOyAnbDJ2cG5AaWV0Zi5vcmcnDQo+ ILOty806IGxpdXdlaWhhbmcNCj4g1vfM4jogUkU6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBm b3INCj4gZHJhZnQtaGFvLWlkci1mbG93c3BlYy1ldnBuLTAwLnR4dA0KPg0KPiBXZWlndW8sDQo+ DQo+ICAgICAgICAgSSB3b3VsZCBsaWtlIHRvIGJldHRlciB1bmRlcnN0YW5kIGhvdyBhIHJlbW90 ZSBQRSB3aWxsICJsZWFybiINCj4gdGhhdCBpdCBuZWVkcyB0byBkZWxpdmVyIGEgRlMgcGF0aCB0 byB0aGUgaW5ncmVzcyBQRT8/IEl0IGNhbm5vdCBjb21lDQo+IGZyb20gdGhlIENFIGFzIHRoYXQg aXMgZGF0YSBwbGFuZSBsZWFybmluZy4gSSB3b3VsZCB0aGluayB0aGF0IGFsbCBGUw0KPiBwYXRo cyBoYXZlIHRvIGJlIGRpc3NlbWluYXRlZCBieSBhIGNlbnRyYWxpemVkIGNvbnRyb2xsZXIuDQo+ DQo+IEppbSBVdHRhcm8NCj4NCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTog SWRyIFttYWlsdG86aWRyLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBIYW93ZWlndW8N Cj4gU2VudDogVHVlc2RheSwgQXVndXN0IDE5LCAyMDE0IDg6MzEgUE0NCj4gVG86IGlkckBpZXRm Lm9yZzsgbDJ2cG5AaWV0Zi5vcmcNCj4gQ2M6IGxpdXdlaWhhbmcNCj4gU3ViamVjdDogW0lkcl0g tPC4tDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcg0KPiBkcmFmdC1oYW8taWRyLWZsb3dz cGVjLWV2cG4tMDAudHh0DQo+DQo+IEhpIEFsbCwNCj4gV2UgaGF2ZSBzdWJtaXR0ZWQgYSBkcmFm dCBvZiAiIERpc3NlbWluYXRpb24gb2YgRmxvdyBTcGVjaWZpY2F0aW9uDQo+IFJ1bGVzIGZvciBF VlBOIi4gIEkgd2lsbCBhcHByaWNpYXRlIGlmIHlvdSBjYW4gZ2l2ZSB1cyBzb21lIHN1Z2dlc3Rp b25zIGFuZCBjb21tZW50cy4NCj4gVGhhbmtzDQo+IHdlaWd1bw0KPg0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ILeivP7IyzogaW50ZXJuZXQtZHJhZnRzQGll dGYub3JnIFtpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQo+ILeiy83KsbzkOiAyMDE0xOo41MIy MMjVIDg6MjANCj4gytW8/sjLOiBaaHVhbmdzaHVud2FuOyBIYW93ZWlndW87IGxpdXdlaWhhbmc7 IFpodWFuZ3NodW53YW47IGxpdXdlaWhhbmc7DQo+IEhhb3dlaWd1bw0KPiDW98ziOiBOZXcgVmVy c2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWhhby1pZHItZmxvd3NwZWMtZXZwbi0wMC50eHQN Cj4NCj4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWhhby1pZHItZmxvd3NwZWMtZXZwbi0w MC50eHQNCj4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBXZWlndW8gSGFvIGFu ZCBwb3N0ZWQgdG8gdGhlIElFVEYNCj4gcmVwb3NpdG9yeS4NCj4NCj4gTmFtZTogICAgICAgICAg IGRyYWZ0LWhhby1pZHItZmxvd3NwZWMtZXZwbg0KPiBSZXZpc2lvbjogICAgICAgMDANCj4gVGl0 bGU6ICAgICAgICAgIERpc3NlbWluYXRpb24gb2YgRmxvdyBTcGVjaWZpY2F0aW9uIFJ1bGVzIGZv ciBFVlBODQo+IERvY3VtZW50IGRhdGU6ICAyMDE0LTA4LTIwDQo+IEdyb3VwOiAgICAgICAgICBJ bmRpdmlkdWFsIFN1Ym1pc3Npb24NCj4gUGFnZXM6ICAgICAgICAgIDcNCj4gVVJMOg0KPiBodHRw Oi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1oYW8taWRyLWZsb3dzcGVjLWV2 cG4tMDAudHh0DQo+IFN0YXR1czoNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtaGFvLWlkci1mbG93c3BlYy1ldnBuLw0KPiBIdG1saXplZDogICAgICAgaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaGFvLWlkci1mbG93c3BlYy1ldnBuLTAwDQo+DQo+DQo+ IEFic3RyYWN0Og0KPiAgICBUaGlzIGRvY3VtZW50IGRlZmluZXMgQkdQIGZsb3ctc3BlYyBleHRl bnNpb24gZm9yIEV0aGVybmV0IHRyYWZmaWMNCj4gICAgZmlsdGVyaW5nIGluIEVWUE4gbmV0d29y ay4gQSBuZXcgQkdQIE5MUkkgdHlwZSAoQUZJPTI1LCBTQUZJPVRCRCkNCj4gICAgdmFsdWUgaXMg cHJvcG9zZWQgdG8gaWRlbnRpZnkgRVZQTiBmbG93LXNwZWMgYXBwbGljYXRpb24uIEEgbmV3DQo+ ICAgIHN1YnNldCBvZiBjb21wb25lbnQgdHlwZXMgYW5kIGV4dGVuZGVkIGNvbW11bml0eSBhbHNv IGFyZSBkZWZpbmVkLg0KPg0KPg0KPg0KPg0KPiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtl IGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZg0KPiBzdWJtaXNzaW9uIHVudGls IHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0 Zi5vcmcuDQo+DQo+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQo+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IElkciBtYWlsaW5nIGxpc3QNCj4gSWRyQGll dGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRyDQo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IElkciBtYWls aW5nIGxpc3QNCj4gSWRyQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vaWRyDQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+DQo+IENlIG1lc3NhZ2UgZXQgc2VzIHBp ZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucw0KPiBjb25maWRl bnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYyBwYXMgZXRyZSBkaWZm dXNlcywNCj4gZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBh dmV6IHJlY3UgY2UgbWVzc2FnZQ0KPiBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlciBh IGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaQ0KPiBxdWUgbGVzIHBpZWNlcyBqb2lu dGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMNCj4gZCdh bHRlcmF0aW9uLCBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNz YWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQo+DQo+IFRoaXMg bWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvcg0K PiBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7IHRo ZXkgc2hvdWxkIG5vdA0KPiBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBh dXRob3Jpc2F0aW9uLg0KPiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9y LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kDQo+IGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5k IGl0cyBhdHRhY2htZW50cy4NCj4gQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMg bm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlDQo+IGJlZW4gbW9kaWZpZWQsIGNoYW5n ZWQgb3IgZmFsc2lmaWVkLg0KPiBUaGFuayB5b3UuDQo+DQo+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IElkciBtYWlsaW5nIGxpc3QNCj4gSWRyQGll dGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRyDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCg0KQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5p ciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUg ZG9pdmVudCBkb25jDQpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5z IGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2 ZXVpbGxleiBsZSBzaWduYWxlcg0KYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kg cXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQg c3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwNCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNh YmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBN ZXJjaS4NCg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29u ZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVk IGJ5IGxhdzsNCnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQg d2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBp biBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdl IGFuZCBpdHMgYXR0YWNobWVudHMuDQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBp cyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdl ZCBvciBmYWxzaWZpZWQuDQpUaGFuayB5b3Uu From nobody Mon Sep 1 04:50:53 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 335211A0398; Mon, 1 Sep 2014 04:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.081 X-Spam-Level: * X-Spam-Status: No, score=1.081 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GNHy6lRmy1kj; Mon, 1 Sep 2014 04:50:46 -0700 (PDT) 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 D010C1A02BD; Mon, 1 Sep 2014 04:50:45 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BIY27250; Mon, 01 Sep 2014 11:50:44 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 1 Sep 2014 12:50:43 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.209]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Mon, 1 Sep 2014 19:50:34 +0800 From: Haoweiguo To: "stephane.litkowski@orange.com" , "UTTARO, JAMES" , "'idr@ietf.org'" , "'l2vpn@ietf.org'" Thread-Topic: New Version Notification for draft-hao-idr-flowspec-evpn-00.txt Thread-Index: AQHPvAyV6atOnhH9DE6j9dLImcRrM5vYoV9zgADsHqCAAMQoQIAB9eqQgAF7eR6ADczLAIAAqdxw Date: Mon, 1 Sep 2014 11:50:33 +0000 Message-ID: References: <20140820002030.18902.50278.idtracker@ietfa.amsl.com> , , <29476_1408695761_53F6FDD1_29476_12929_1_9E32478DFA9976438E7A22F69B08FF9207DB14@OPEXCLILM34.corporate.adroot.infra.ftgroup> , <28799_1409563679_54043C1F_28799_2589_1_9E32478DFA9976438E7A22F69B08FF92080C92@OPEXCLILM34.corporate.adroot.infra.ftgroup> In-Reply-To: <28799_1409563679_54043C1F_28799_2589_1_9E32478DFA9976438E7A22F69B08FF92080C92@OPEXCLILM34.corporate.adroot.infra.ftgroup> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.23.94] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/idr/TvAzd36FmNmb3CuR77MxtpXb7lk Cc: liuweihang Subject: [Idr] =?gb2312?b?tPC4tDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBk?= =?gb2312?b?cmFmdC1oYW8taWRyLWZsb3dzcGVjLWV2cG4tMDAudHh0?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2014 11:50:49 -0000 SGkgU3RlcGhhbmUsDQpQbHMgc2VlIG15IHJlcGx5IGlubGluZSB3aXRoIFt3ZWlndW8yXSBiZWxv dy4NClRoYW5rcw0Kd2VpZ3VvDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCreivP7Iyzogc3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb20gW3N0ZXBoYW5lLmxp dGtvd3NraUBvcmFuZ2UuY29tXQ0Kt6LLzcqxvOQ6IDIwMTTE6jnUwjHI1SAxNzoyNw0KytW8/sjL OiBIYW93ZWlndW87IFVUVEFSTywgSkFNRVM7ICdpZHJAaWV0Zi5vcmcnOyAnbDJ2cG5AaWV0Zi5v cmcnDQqzrcvNOiBsaXV3ZWloYW5nDQrW98ziOiBSRTogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9u IGZvciBkcmFmdC1oYW8taWRyLWZsb3dzcGVjLWV2cG4tMDAudHh0DQoNClt3ZWlndW9dOiBUaGFu a3MuIEJ1dCBNQUMgZmlsdGVycyBtYXliZSBub3QgYXBwbGljYWJsZSB0byBJUFY0ICZWUE52NCwg YmVjYXVzZSBpbiB0aGlzIGNhc2UsIE1BQyBpbmZvcm1hdGlvbiB3aWxsIGJlIGNoYW5nZWQgb24g ZGlmZmVyZW50IFBFIGRldmljZXMsIGEgc2luZ2xlIEFDTCBydWxlIGNhbid0IGlkZW50aWZ5IGEg Y29uc2lzdGFudCBmbG93IGF0IGRpZmZlcmVudCBQRSBkZXZpY2VzLiBTbyBpbiBJUCBuZXR3b3Jr LCBmbG93LXNwZWMgY2FuIG9ubHkgYmUgZGVmaW5lZCB1c2luZyBJUCByZWxhdGVkIGluZm9ybWF0 aW9uLg0KW1NMSV0gSSBhZ3JlZSB3aXRoIHlvdXIgcG9pbnQgYnV0IEkgd2FzIHRoaW5raW5nIGFi b3V0IGEgZnV0dXJlIChob3BlIGl0IHdpbGwgaGFwcGVuIDopIHdoZW4gd2Ugd2lsbCBiZSBhYmxl IHRvIG9mZmVyIEwyIGFuZCBMMyBzZXJ2aWNlcyBvbiB0aGUgc2FtZSBwbHVnIChpbmNsdWRpbmcg c2FtZSBWTEFOLCBzb3J0IG9mIGNvbmN1cnJlbnQgcm91dGluZyAmIGJyaWRnaW5nIGludGVyZmFj ZSkuIEluIHRoaXMgc2l0dWF0aW9uLCBpcyBpdCBnb29kIHRvIHVzZSB0d28gYWRkcmVzcyBmYW1p bGllcyB0byBmaWx0ZXIgdGhlIGRpZmZlcmVudCBzZXJ2aWNlcyA/IFdoeSBub3QgdXNpbmcgb25s eSBvbmUgLi4uDQoNClt3ZWlndW8yXTogSSBrbm93IHdoYXQgeW91IHNhaWQuIFllcywgSW4gSVJC IHNjZW5hcmlvLCBub3Qgb25seSBldGhlcm5ldCBoZWFkZXIgYnV0IGFsc28gSVAgaGVhZGVyIGNh biBiZSB1c2VkIGZvciB0cmFmZmljIGZpbHRlcmluZy4gIEkgdGhpbmsgb3VyIGRyYWZ0IGNhbiBj b3ZlciB0aGlzIHNjZW5hcmlvLiBJbiB0aGUgZHJhZnQsIGNvbXBvbmVudCB0eXBlcyBpbmNsdWRl IGJvdGggSVAgYW5kIGV0aGVybmV0IHBhcnQsIElQIGNvbXBvbmVudCB0eXBlcyBhcmUgaW5oZXJp dGVkIGZyb20gUkZDWzU1NzVdLCBNQUMgY29tcG9uZXQgdHlwZXMgYXJlIG5ld2x5IGRlZmluZWQu IFNvIG9ubHkgb25lIGFkZHJlc3MgZmFtaWx5IGlzIG5lZWRlZCBmb3IgSVAgYW5kIEV0aGVybmV0 IHRyYWZmaWMgZmlsdGVyaW5nLg0KDQpbd2VpZ3VvXTogUkQgdXNhZ2UgaGFzIG5vIGRpZmZlcmVu Y2Ugd2l0aCBvcmlnaW5hbCBCR1AgVlBOIGRlZmluaWNhdGlvbi4gQ2FuIHlvdSBnaXZlIG1lIHNv bWUgbW9yZSBjbGFyaWZpY2F0aW9ucz8NCltTTEldIFJpZ2h0LCBidXQgUkZDNTU3NSBwcmVjaXNl cyB0aGF0IFJEIGlzIHBhcnQgb2YgTkxSSSBmb3IgVlBOIDoNCiJUaGUgTkxSSSBmb3JtYXQgZm9y IHRoaXMgYWRkcmVzcyBmYW1pbHkgY29uc2lzdHMgb2YgYSBmaXhlZC1sZW5ndGgNCiAgIFJvdXRl IERpc3Rpbmd1aXNoZXIgZmllbGQgKDggYnl0ZXMpIGZvbGxvd2VkIGJ5IGEgZmxvdyBzcGVjaWZp Y2F0aW9uLA0KICAgZm9sbG93aW5nIHRoZSBlbmNvZGluZyBkZWZpbmVkIGluIHRoaXMgZG9jdW1l bnQuICBUaGUgTkxSSSBsZW5ndGgNCiAgIGZpZWxkIHNoYWxsIGluY2x1ZGUgYm90aCB0aGUgOCBi eXRlcyBvZiB0aGUgUm91dGUgRGlzdGluZ3Vpc2hlciBhcw0KICAgd2VsbCBhcyB0aGUgc3Vic2Vx dWVudCBmbG93IHNwZWNpZmljYXRpb24uDQoiDQpJbiB5b3VyIGRvY3VtZW50ICwgSSBjYW4ndCBz ZWUgdGhpcyAuLi4gYXMgeW91IGFyZSBkZWZpbmluZyBhIG5ldyBOTFJJLCB5b3UgbmVlZCB0byBw cmVjaXNlIHRoZSBmb3JtYXQuDQoNClt3ZWlndW8yXTogT0suIEluIG91ciBkcmFmdCwgdGhlIGZv cm1hdCBpcyBzYW1lIHdpdGggUkZDNTU3NSwgSSBjYW4gYWRkIHRoZSBzYW1lIGRlc2NyaXB0aW9u IHRvIG1ha2UgaXQgbW9yZSBjbGVhci4NCg0KDQpTdGVwaGFuZQ0KDQoNCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IEhhb3dlaWd1byBbbWFpbHRvOmhhb3dlaWd1b0BodWF3ZWku Y29tXQ0KU2VudDogU2F0dXJkYXksIEF1Z3VzdCAyMywgMjAxNCAwOTowOA0KVG86IExJVEtPV1NL SSBTdGVwaGFuZSBTQ0UvSUJORjsgVVRUQVJPLCBKQU1FUzsgJ2lkckBpZXRmLm9yZyc7ICdsMnZw bkBpZXRmLm9yZycNCkNjOiBsaXV3ZWloYW5nDQpTdWJqZWN0OiC08Li0OiBOZXcgVmVyc2lvbiBO b3RpZmljYXRpb24gZm9yIGRyYWZ0LWhhby1pZHItZmxvd3NwZWMtZXZwbi0wMC50eHQNCg0KSGkg U3RlcGhhbmUsDQpUaGFua3MgZm9yIHlvdXIgZGV0YWlsIGNvbW1lbnRzLiBQbHMgc2VlIG15IHJl cGx5IGlubGluZSB3aXRoIFt3ZWlndW9dIGJlbG93Lg0Kd2VpZ3VvDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCreivP7Iyzogc3RlcGhhbmUubGl0a293c2tpQG9y YW5nZS5jb20gW3N0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tXQ0Kt6LLzcqxvOQ6IDIwMTTE 6jjUwjIyyNUgMTY6MjINCsrVvP7IyzogSGFvd2VpZ3VvOyBVVFRBUk8sIEpBTUVTOyAnaWRyQGll dGYub3JnJzsgJ2wydnBuQGlldGYub3JnJw0Ks63LzTogbGl1d2VpaGFuZw0K1vfM4jogUkU6IE5l dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaGFvLWlkci1mbG93c3BlYy1ldnBuLTAw LnR4dA0KDQpIaSwNCg0KSSB0aGluayB0aGlzIGlzIGEgdmFsdWFibGUgYWRkaXRpb24sIGJ1dCBJ IHdvdWxkIGxpa2UgdG8gc2VlIHRoZXNlIE1BQyBmaWx0ZXJzIGJlaW5nIGFwcGxpY2FibGUgYWxz byB0byBJUHY0IHBsdWdzIChGUyBJUHY0ICYgVlBOdjQpDQpbd2VpZ3VvXTogVGhhbmtzLiBCdXQg TUFDIGZpbHRlcnMgbWF5YmUgbm90IGFwcGxpY2FibGUgdG8gSVBWNCAmVlBOdjQsIGJlY2F1c2Ug aW4gdGhpcyBjYXNlLCBNQUMgaW5mb3JtYXRpb24gd2lsbCBiZSBjaGFuZ2VkIG9uIGRpZmZlcmVu dCBQRSBkZXZpY2VzLCBhIHNpbmdsZSBBQ0wgcnVsZSBjYW4ndCBpZGVudGlmeSBhIGNvbnNpc3Rh bnQgZmxvdyBhdCBkaWZmZXJlbnQgUEUgZGV2aWNlcy4gU28gaW4gSVAgbmV0d29yaywgZmxvdy1z cGVjIGNhbiBvbmx5IGJlIGRlZmluZWQgdXNpbmcgSVAgcmVsYXRlZCBpbmZvcm1hdGlvbi4NCg0K TW9yZW92ZXIgLCB0aGUgbmV3IEFGSS9TQUZJIHNob3VsZCBub3QgYmUgcmVzdHJpY3RlZCB0byBF VlBOLCBhbnkgTDIgaW50ZXJmYWNlIG1heSBiZSBpbnRlcmVzdGVkIGJ5IHN1Y2ggZmlsdGVyIChW UExTLCBiYXNpYyBMMiBzd2l0Y2hpbmcgLi4uKS4NClt3ZWlndW9dOiBZZXMsIEkgYWdyZWUuIEZp cnN0bHkgaSBwcm9wb3NlIEV0aGVybmV0IGZsb3ctc3BlYyBvbmx5IGluIEVWUE4gbmV0d29yaywg YmVjYXVzZSBmbG93cy1wZWMgcmVsaWVzIG9uIEJHUCBwcm90b2NvbCBhbmQgRVZQTiBoYXMgQkdQ IGNvbnRyb2wgcGxhbmUsIHNvIGl0IHdpbGwgYmUgZWFzeSB0byBkZXBsb3kgQkdQIGZsb3dzcGVj IGluIEVWUE4gbmV0d29yay4gSWYgd2Ugd2FudCB0byBkZXBsb3kgdGhlIGZsb3ctc3BlYyBpbiBW UExTIG5ldHdvcmssIG5vcm1hbGx5IFZQTFMgb25seSByZWxpZXMgb24gTERQIHByb3RvY29sLCBh ZGRpdGlvbmFsIHByb3RvY29sIG9mIEJHUCBmbG93LXNwZWMgc2hvdWxkIGJlIGRlcGxveWVkIGZv ciBNQUMgZmlsdGVyaW5nLg0KSWYgdGhlIGNvbW11bml0eSB0aGlua3MgaXQgaXMgbmVjZXNzYXJ5 IHRvIGludHJvZHVjZSBldGhlcm5ldCBmbG93LXNwZWMgZm9yIGFsbCBMMiBpbnRlcmZhY2UsIGkg Y2FuIHVwZGF0ZSB0aGlzIHBhcnQgdG8gbGV0IGl0IG5vdCBiZSByZXN0cmljdGVkIHRvIEVWUE4u DQoNClJvdXRlIGRpc3Rpbmd1aXNoZXIgbWF5IGJlIGlzIG1pc3NpbmcgLi4uDQpbd2VpZ3VvXTog UkQgdXNhZ2UgaGFzIG5vIGRpZmZlcmVuY2Ugd2l0aCBvcmlnaW5hbCBCR1AgVlBOIGRlZmluaWNh dGlvbi4gQ2FuIHlvdSBnaXZlIG1lIHNvbWUgbW9yZSBjbGFyaWZpY2F0aW9ucz8NCg0KTm93IG1v cmUgZ2xvYmFsbHksIG1heSBiZSBpdCdzIHRpbWUgdG8gdGhpbmsgbW9yZSBnbG9iYWxseSBhYm91 dCB0aGUgZXZvbHV0aW9uIG9mIEZTLiBJIHByZXR0eSBzZWUgRlMgZXZvbHV0aW9uIGxhcmdlbHkg YmV5b25kIEREb1MgZG9tYWluLiBGUyBpcyBhIHZlcnkgZ29vZCBwcm90b2NvbCBmb3IgU0ROIGFw cGxpY2F0aW9ucy4gVGhlIHF1ZXN0aW9uIGJlaGluZCBpcyBkbyB3ZSByZWFsbHkgbmVlZCB0byB3 b3JrIHdpdGggbXVsdGlwbGUgYWRkcmVzcyBmYW1pbGllcyBmb3IgZWFjaCB0eXBlIG9mICJzZXJ2 aWNlIi8iaW50ZXJmYWNlIHR5cGUiIHRvIGZpbHRlciBvciBkbyB3ZSBuZWVkIHRvIGhhdmUgYSBt b3JlIGdsb2JhbCBtb2RlbCB3aGVyZSB3ZSB3b3VsZCBiZSBhYmxlIHRvIHB1dCBhbnkgdHlwZSBv ZiBmaWx0ZXIgYW55IHdoZXJlIGFuZCBhcHBseSBtdWx0aXBsZSBhY3Rpb25zIChvcGVuZmxvdyBs aWtlIEZTKS4gQ29tcGFyZWQgdG8gb3BlbmZsb3csIEZTIGhhcyB0aGUgbWFnaWMgdG8gZW5hYmxl IG11bHRpcG9pbnQgZGlzdHJpYnV0aW9uIG9mIGFjdGlvbnMuDQoNClt3ZWlndW9dOiBZZXMsIEJH UCBmbG93LXNwZWMgY2FuIGJlIGFwcGxpY2FibGUgZm9yIHNvbWUgU0ROIGFwcGxpY2F0aW9ucy4g SXQgaGFzIG1vcmUgcG90ZW50aWFsIHRvIGRvIG1vcmUgYXR0YWN0aXZlIHRoaW5ncy4NCg0KQmVz dCBSZWdhcmRzLA0KDQpTdGVwaGFuZQ0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBJZHIgW21haWx0bzppZHItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEhhb3dl aWd1bw0KU2VudDogVGh1cnNkYXksIEF1Z3VzdCAyMSwgMjAxNCAwNDoxMQ0KVG86IFVUVEFSTywg SkFNRVM7ICdpZHJAaWV0Zi5vcmcnOyAnbDJ2cG5AaWV0Zi5vcmcnDQpDYzogbGl1d2VpaGFuZw0K U3ViamVjdDogW0lkcl0gtPC4tDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1o YW8taWRyLWZsb3dzcGVjLWV2cG4tMDAudHh0DQoNCkhpIEppbSwNClRoYW5rcyBmb3IgeW91ciBj b21tZW50cy4gVGhlIEJHUCBGbG93c3BlYyBwcm9jZWR1cmVzIGlzIGlsbHVzdHJhdGVkIGFzIGZv bGxvd2luZzoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRVZQ TiBGbG93U3BlYyBTZXNzaW9uICAgICAgICAgICAgICAgICAgRVZQTiBGbG93U3BlYyBTZXNzaW9u DQpERE9TIERldGVjdGlvbiBBcHBsaWFuY2UtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLUVncmVz cyBQRS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tSW5ncmVzcyBQRS0tLS0tLUNFMg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIENFMSBERE9TIERldGVjdGlvbiBBcHBsaWFuY2UgZXN0YWJsaXNoZXMgRVZQTiBmbG93c3Bl YyBzZXNzaW9uIHdpdGggRWdyZXNzIFBFLCBpdCBkZXRlY3RzIERET1MgYXR0YWNrIHRyYWZmaWMg YW5kIGdlbmVyYXRlIEFDTCBydWxlLCB0aGUgQUNMIHJ1bGUgaXMgYW5ub3VuY2VkIHRvIEVncmVz cyBQRSB0aHJvdWdoIEVWUE4gZmxvd3NwZWMgcHJvdG9jb2wsIHRoZW4gdGhlIGVncmVzcyBQRSBh bm5vdW5jZXMgaXQgdG8gaW5ncmVzcyBQRSwgZmluYWxseSBpbmdyZXNzIFBFIGluc3RhbGxzIHRo ZSBBQ0wgcnVsZSBmb3IgdHJhZmZpYyBmaWx0ZXJpbmcuDQpERE9TIERldGVjdGlvbiBBcHBsaWFu Y2Ugb25seSBuZWVkcyB0byBzdXBwb3J0IEVWUE4gZmxvd3NwZWMgZnVuY3Rpb24sIGl0IGRvZXNu J3QgbmVlZCB0byBzdXBwb3J0IGJhc2ljIEVWUE4gZnVuY3Rpb24uDQpUaGFua3MNCndlaWd1bw0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kt6K8/sjLOiBVVFRBUk8s IEpBTUVTIFtqdTE3MzhAYXR0LmNvbV0NCreiy83KsbzkOiAyMDE0xOo41MIyMcjVIDA6MjkNCsrV vP7IyzogSGFvd2VpZ3VvOyAnaWRyQGlldGYub3JnJzsgJ2wydnBuQGlldGYub3JnJw0Ks63LzTog bGl1d2VpaGFuZw0K1vfM4jogUkU6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQt aGFvLWlkci1mbG93c3BlYy1ldnBuLTAwLnR4dA0KDQpXZWlndW8sDQoNCiAgICAgICAgSSB3b3Vs ZCBsaWtlIHRvIGJldHRlciB1bmRlcnN0YW5kIGhvdyBhIHJlbW90ZSBQRSB3aWxsICJsZWFybiIg dGhhdCBpdCBuZWVkcyB0byBkZWxpdmVyIGEgRlMgcGF0aCB0byB0aGUgaW5ncmVzcyBQRT8/IEl0 IGNhbm5vdCBjb21lIGZyb20gdGhlIENFIGFzIHRoYXQgaXMgZGF0YSBwbGFuZSBsZWFybmluZy4g SSB3b3VsZCB0aGluayB0aGF0IGFsbCBGUyBwYXRocyBoYXZlIHRvIGJlIGRpc3NlbWluYXRlZCBi eSBhIGNlbnRyYWxpemVkIGNvbnRyb2xsZXIuDQoNCkppbSBVdHRhcm8NCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IElkciBbbWFpbHRvOmlkci1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgSGFvd2VpZ3VvDQpTZW50OiBUdWVzZGF5LCBBdWd1c3QgMTksIDIwMTQgODoz MSBQTQ0KVG86IGlkckBpZXRmLm9yZzsgbDJ2cG5AaWV0Zi5vcmcNCkNjOiBsaXV3ZWloYW5nDQpT dWJqZWN0OiBbSWRyXSC08Li0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWhh by1pZHItZmxvd3NwZWMtZXZwbi0wMC50eHQNCg0KSGkgQWxsLA0KV2UgaGF2ZSBzdWJtaXR0ZWQg YSBkcmFmdCBvZiAiIERpc3NlbWluYXRpb24gb2YgRmxvdyBTcGVjaWZpY2F0aW9uIFJ1bGVzIGZv ciBFVlBOIi4gIEkgd2lsbCBhcHByaWNpYXRlIGlmIHlvdSBjYW4gZ2l2ZSB1cyBzb21lIHN1Z2dl c3Rpb25zIGFuZCBjb21tZW50cy4NClRoYW5rcw0Kd2VpZ3VvDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCreivP7IyzogaW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn IFtpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQq3osvNyrG85DogMjAxNMTqONTCMjDI1SA4OjIw DQrK1bz+yMs6IFpodWFuZ3NodW53YW47IEhhb3dlaWd1bzsgbGl1d2VpaGFuZzsgWmh1YW5nc2h1 bndhbjsgbGl1d2VpaGFuZzsgSGFvd2VpZ3VvDQrW98ziOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yIGRyYWZ0LWhhby1pZHItZmxvd3NwZWMtZXZwbi0wMC50eHQNCg0KQSBuZXcgdmVyc2lv biBvZiBJLUQsIGRyYWZ0LWhhby1pZHItZmxvd3NwZWMtZXZwbi0wMC50eHQNCmhhcyBiZWVuIHN1 Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgV2VpZ3VvIEhhbyBhbmQgcG9zdGVkIHRvIHRoZSBJRVRG IHJlcG9zaXRvcnkuDQoNCk5hbWU6ICAgICAgICAgICBkcmFmdC1oYW8taWRyLWZsb3dzcGVjLWV2 cG4NClJldmlzaW9uOiAgICAgICAwMA0KVGl0bGU6ICAgICAgICAgIERpc3NlbWluYXRpb24gb2Yg RmxvdyBTcGVjaWZpY2F0aW9uIFJ1bGVzIGZvciBFVlBODQpEb2N1bWVudCBkYXRlOiAgMjAxNC0w OC0yMA0KR3JvdXA6ICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6ICAgICAg ICAgIDcNClVSTDogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1oYW8taWRyLWZsb3dzcGVjLWV2cG4tMDAudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaGFvLWlkci1mbG93c3BlYy1ldnBu Lw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWhhby1p ZHItZmxvd3NwZWMtZXZwbi0wMA0KDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBkZWZp bmVzIEJHUCBmbG93LXNwZWMgZXh0ZW5zaW9uIGZvciBFdGhlcm5ldCB0cmFmZmljDQogICBmaWx0 ZXJpbmcgaW4gRVZQTiBuZXR3b3JrLiBBIG5ldyBCR1AgTkxSSSB0eXBlIChBRkk9MjUsIFNBRkk9 VEJEKQ0KICAgdmFsdWUgaXMgcHJvcG9zZWQgdG8gaWRlbnRpZnkgRVZQTiBmbG93LXNwZWMgYXBw bGljYXRpb24uIEEgbmV3DQogICBzdWJzZXQgb2YgY29tcG9uZW50IHR5cGVzIGFuZCBleHRlbmRl ZCBjb21tdW5pdHkgYWxzbyBhcmUgZGVmaW5lZC4NCg0KDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBp dCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lv biB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRv b2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklkciBtYWlsaW5nIGxpc3QNCklkckBpZXRm Lm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZHINCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJZHIgbWFpbGluZyBsaXN0 DQpJZHJAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRy DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCg0KQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBj b250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMg ZXQgbmUgZG9pdmVudCBkb25jIHBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVz IHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJl dXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyIGEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFp bnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0 YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sIE9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3Bv bnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmll LiBNZXJjaS4NCg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4g Y29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVj dGVkIGJ5IGxhdzsgdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGll ZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWls IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3Nh Z2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3Jhbmdl IGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFu Z2VkIG9yIGZhbHNpZmllZC4NClRoYW5rIHlvdS4NCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpDZSBtZXNzYWdlIGV0 IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29u ZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMNCnBhcyBldHJl IGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3Vz IGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyDQph IGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVz LiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0 aW9uLA0KT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBh IGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KDQpUaGlzIG1lc3NhZ2Ug YW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdl ZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Ow0KdGhleSBzaG91bGQg bm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24u DQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5 IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4N CkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3Nh Z2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NClRoYW5r IHlvdS4= From nobody Mon Sep 1 08:41:58 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEB581A065E; Mon, 1 Sep 2014 08:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.551 X-Spam-Level: X-Spam-Status: No, score=0.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Ug1uRXyCTJo; Mon, 1 Sep 2014 08:41:48 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 544D71A06C8; Mon, 1 Sep 2014 08:21:46 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 1C9A9264106; Mon, 1 Sep 2014 17:21:44 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.30]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id EE16B238055; Mon, 1 Sep 2014 17:21:43 +0200 (CEST) Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.43]) by OPEXCLILH02.corporate.adroot.infra.ftgroup ([10.114.31.30]) with mapi id 14.03.0195.001; Mon, 1 Sep 2014 17:21:43 +0200 From: To: Haoweiguo , "UTTARO, JAMES" , "'idr@ietf.org'" , "'l2vpn@ietf.org'" Thread-Topic: New Version Notification for draft-hao-idr-flowspec-evpn-00.txt Thread-Index: AQHPxdr4397Nmj5y/ECp23+mIXsmgZvsYOXA Date: Mon, 1 Sep 2014 15:21:43 +0000 Message-ID: <25521_1409584904_54048F08_25521_750_1_9E32478DFA9976438E7A22F69B08FF920810A4@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: <20140820002030.18902.50278.idtracker@ietfa.amsl.com> , , <29476_1408695761_53F6FDD1_29476_12929_1_9E32478DFA9976438E7A22F69B08FF9207DB14@OPEXCLILM34.corporate.adroot.infra.ftgroup> , <28799_1409563679_54043C1F_28799_2589_1_9E32478DFA9976438E7A22F69B08FF92080C92@OPEXCLILM34.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.25.81224 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/gq1wBwUFFUjxVuKPYIzlni15lWY Cc: liuweihang Subject: Re: [Idr] New Version Notification for draft-hao-idr-flowspec-evpn-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2014 15:41:54 -0000 W3dlaWd1bzJdOiBJIGtub3cgd2hhdCB5b3Ugc2FpZC4gWWVzLCBJbiBJUkIgc2NlbmFyaW8sIG5v dCBvbmx5IGV0aGVybmV0IGhlYWRlciBidXQgYWxzbyBJUCBoZWFkZXIgY2FuIGJlIHVzZWQgZm9y IHRyYWZmaWMgZmlsdGVyaW5nLiAgSSB0aGluayBvdXIgZHJhZnQgY2FuIGNvdmVyIHRoaXMgc2Nl bmFyaW8uIEluIHRoZSBkcmFmdCwgY29tcG9uZW50IHR5cGVzIGluY2x1ZGUgYm90aCBJUCBhbmQg ZXRoZXJuZXQgcGFydCwgSVAgY29tcG9uZW50IHR5cGVzIGFyZSBpbmhlcml0ZWQgZnJvbSBSRkNb NTU3NV0sIE1BQyBjb21wb25ldCB0eXBlcyBhcmUgbmV3bHkgZGVmaW5lZC4gU28gb25seSBvbmUg YWRkcmVzcyBmYW1pbHkgaXMgbmVlZGVkIGZvciBJUCBhbmQgRXRoZXJuZXQgdHJhZmZpYyBmaWx0 ZXJpbmcuDQoNCltTTEldIFJpZ2h0LCB0aGF0J3Mgb25lIHBvc3NpYmlsaXR5LCB0aGUgb3RoZXIg b25lIGNvdWxkIGJlIHRvIG5vdCBjcmVhdGUgYSBuZXcgQUYgZm9yIE1BQyBGUyBidXQganVzdCBl eHRlbmQgdGhlIGN1cnJlbnQgRlMgYWRkcmVzcy1mYW1pbGllcyAoVlBOIGFuZCBub24gVlBOKSB3 aXRoIE1BQyBjb21wb25lbnQgdHlwZXMgYW5kIG5ldyBhY3Rpb25zLg0KVGhlIG1haW4gcXVlc3Rp b24gaW4gdGVybSBvZiBwcm90b2NvbCBkZXNpZ24gaXMgdG8gd2Ugd2FudCB0byBrZWVwIGZpbHRl cmluZyBBRiBhZ25vc3RpYyAoc2luZ2xlIEZTIEFGIGZvciBhbGwgdHlwZSBvZiBmbG93cykgb3Ig ZG8gd2UgbmVlZCB0byBrZWVwIHNlcGFyYXRlIEZTIEFGcyA/DQpUaGUgd2F5IHRha2VuIGZvciB0 aGUgbW9tZW50IGlzIHRvIGhhdmUgc2VwYXJhdGUgb25lcywgd2UgY2FuIHNlZSB0aGF0IElQdjYg RlMgaXMgY3VycmVudGx5IGRlZmluZWQgYXMgYSBuZXcgY291cGxlIG9mIEFGSS9TQUZJIGJ1dCBp cyBpdCB0aGUgZ29vZCB3YXkgdG8gZG8gPyBJIGRvbid0IHJlbWVtYmVyIGlmIHRoaXMgaGFzIGJl ZW4gZGlzY3Vzc2VkIG9yIG5vdCB3aGVuIGRlZmluaW5nIEZTIElQdjYgPw0KSSdtIHdvbmRlcmlu ZyBpZiB3ZSBjYW5ub3QgbWFrZSBGbG93U3BlYyB3b3JraW5nIGFzIElQRklYIGZvciB0aGUgZmxv dyBkZWZpbml0aW9uLg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEhh b3dlaWd1byBbbWFpbHRvOmhhb3dlaWd1b0BodWF3ZWkuY29tXSANClNlbnQ6IE1vbmRheSwgU2Vw dGVtYmVyIDAxLCAyMDE0IDEzOjUxDQpUbzogTElUS09XU0tJIFN0ZXBoYW5lIFNDRS9JQk5GOyBV VFRBUk8sIEpBTUVTOyAnaWRyQGlldGYub3JnJzsgJ2wydnBuQGlldGYub3JnJw0KQ2M6IGxpdXdl aWhhbmcNClN1YmplY3Q6ILTwuLQ6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQt aGFvLWlkci1mbG93c3BlYy1ldnBuLTAwLnR4dA0KDQpIaSBTdGVwaGFuZSwNClBscyBzZWUgbXkg cmVwbHkgaW5saW5lIHdpdGggW3dlaWd1bzJdIGJlbG93Lg0KVGhhbmtzDQp3ZWlndW8NCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kt6K8/sjLOiBzdGVwaGFuZS5s aXRrb3dza2lAb3JhbmdlLmNvbSBbc3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb21dDQq3osvN yrG85DogMjAxNMTqOdTCMcjVIDE3OjI3DQrK1bz+yMs6IEhhb3dlaWd1bzsgVVRUQVJPLCBKQU1F UzsgJ2lkckBpZXRmLm9yZyc7ICdsMnZwbkBpZXRmLm9yZycNCrOty806IGxpdXdlaWhhbmcNCtb3 zOI6IFJFOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWhhby1pZHItZmxvd3Nw ZWMtZXZwbi0wMC50eHQNCg0KW3dlaWd1b106IFRoYW5rcy4gQnV0IE1BQyBmaWx0ZXJzIG1heWJl IG5vdCBhcHBsaWNhYmxlIHRvIElQVjQgJlZQTnY0LCBiZWNhdXNlIGluIHRoaXMgY2FzZSwgTUFD IGluZm9ybWF0aW9uIHdpbGwgYmUgY2hhbmdlZCBvbiBkaWZmZXJlbnQgUEUgZGV2aWNlcywgYSBz aW5nbGUgQUNMIHJ1bGUgY2FuJ3QgaWRlbnRpZnkgYSBjb25zaXN0YW50IGZsb3cgYXQgZGlmZmVy ZW50IFBFIGRldmljZXMuIFNvIGluIElQIG5ldHdvcmssIGZsb3ctc3BlYyBjYW4gb25seSBiZSBk ZWZpbmVkIHVzaW5nIElQIHJlbGF0ZWQgaW5mb3JtYXRpb24uDQpbU0xJXSBJIGFncmVlIHdpdGgg eW91ciBwb2ludCBidXQgSSB3YXMgdGhpbmtpbmcgYWJvdXQgYSBmdXR1cmUgKGhvcGUgaXQgd2ls bCBoYXBwZW4gOikgd2hlbiB3ZSB3aWxsIGJlIGFibGUgdG8gb2ZmZXIgTDIgYW5kIEwzIHNlcnZp Y2VzIG9uIHRoZSBzYW1lIHBsdWcgKGluY2x1ZGluZyBzYW1lIFZMQU4sIHNvcnQgb2YgY29uY3Vy cmVudCByb3V0aW5nICYgYnJpZGdpbmcgaW50ZXJmYWNlKS4gSW4gdGhpcyBzaXR1YXRpb24sIGlz IGl0IGdvb2QgdG8gdXNlIHR3byBhZGRyZXNzIGZhbWlsaWVzIHRvIGZpbHRlciB0aGUgZGlmZmVy ZW50IHNlcnZpY2VzID8gV2h5IG5vdCB1c2luZyBvbmx5IG9uZSAuLi4NCg0KW3dlaWd1bzJdOiBJ IGtub3cgd2hhdCB5b3Ugc2FpZC4gWWVzLCBJbiBJUkIgc2NlbmFyaW8sIG5vdCBvbmx5IGV0aGVy bmV0IGhlYWRlciBidXQgYWxzbyBJUCBoZWFkZXIgY2FuIGJlIHVzZWQgZm9yIHRyYWZmaWMgZmls dGVyaW5nLiAgSSB0aGluayBvdXIgZHJhZnQgY2FuIGNvdmVyIHRoaXMgc2NlbmFyaW8uIEluIHRo ZSBkcmFmdCwgY29tcG9uZW50IHR5cGVzIGluY2x1ZGUgYm90aCBJUCBhbmQgZXRoZXJuZXQgcGFy dCwgSVAgY29tcG9uZW50IHR5cGVzIGFyZSBpbmhlcml0ZWQgZnJvbSBSRkNbNTU3NV0sIE1BQyBj b21wb25ldCB0eXBlcyBhcmUgbmV3bHkgZGVmaW5lZC4gU28gb25seSBvbmUgYWRkcmVzcyBmYW1p bHkgaXMgbmVlZGVkIGZvciBJUCBhbmQgRXRoZXJuZXQgdHJhZmZpYyBmaWx0ZXJpbmcuDQoNClt3 ZWlndW9dOiBSRCB1c2FnZSBoYXMgbm8gZGlmZmVyZW5jZSB3aXRoIG9yaWdpbmFsIEJHUCBWUE4g ZGVmaW5pY2F0aW9uLiBDYW4geW91IGdpdmUgbWUgc29tZSBtb3JlIGNsYXJpZmljYXRpb25zPw0K W1NMSV0gUmlnaHQsIGJ1dCBSRkM1NTc1IHByZWNpc2VzIHRoYXQgUkQgaXMgcGFydCBvZiBOTFJJ IGZvciBWUE4gOg0KIlRoZSBOTFJJIGZvcm1hdCBmb3IgdGhpcyBhZGRyZXNzIGZhbWlseSBjb25z aXN0cyBvZiBhIGZpeGVkLWxlbmd0aA0KICAgUm91dGUgRGlzdGluZ3Vpc2hlciBmaWVsZCAoOCBi eXRlcykgZm9sbG93ZWQgYnkgYSBmbG93IHNwZWNpZmljYXRpb24sDQogICBmb2xsb3dpbmcgdGhl IGVuY29kaW5nIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudC4gIFRoZSBOTFJJIGxlbmd0aA0KICAg ZmllbGQgc2hhbGwgaW5jbHVkZSBib3RoIHRoZSA4IGJ5dGVzIG9mIHRoZSBSb3V0ZSBEaXN0aW5n dWlzaGVyIGFzDQogICB3ZWxsIGFzIHRoZSBzdWJzZXF1ZW50IGZsb3cgc3BlY2lmaWNhdGlvbi4N CiINCkluIHlvdXIgZG9jdW1lbnQgLCBJIGNhbid0IHNlZSB0aGlzIC4uLiBhcyB5b3UgYXJlIGRl ZmluaW5nIGEgbmV3IE5MUkksIHlvdSBuZWVkIHRvIHByZWNpc2UgdGhlIGZvcm1hdC4NCg0KW3dl aWd1bzJdOiBPSy4gSW4gb3VyIGRyYWZ0LCB0aGUgZm9ybWF0IGlzIHNhbWUgd2l0aCBSRkM1NTc1 LCBJIGNhbiBhZGQgdGhlIHNhbWUgZGVzY3JpcHRpb24gdG8gbWFrZSBpdCBtb3JlIGNsZWFyLg0K DQoNClN0ZXBoYW5lDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSGFv d2VpZ3VvIFttYWlsdG86aGFvd2VpZ3VvQGh1YXdlaS5jb21dDQpTZW50OiBTYXR1cmRheSwgQXVn dXN0IDIzLCAyMDE0IDA5OjA4DQpUbzogTElUS09XU0tJIFN0ZXBoYW5lIFNDRS9JQk5GOyBVVFRB Uk8sIEpBTUVTOyAnaWRyQGlldGYub3JnJzsgJ2wydnBuQGlldGYub3JnJw0KQ2M6IGxpdXdlaWhh bmcNClN1YmplY3Q6ILTwuLQ6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaGFv LWlkci1mbG93c3BlYy1ldnBuLTAwLnR4dA0KDQpIaSBTdGVwaGFuZSwNClRoYW5rcyBmb3IgeW91 ciBkZXRhaWwgY29tbWVudHMuIFBscyBzZWUgbXkgcmVwbHkgaW5saW5lIHdpdGggW3dlaWd1b10g YmVsb3cuDQp3ZWlndW8NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0Kt6K8/sjLOiBzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbSBbc3RlcGhhbmUubGl0a293 c2tpQG9yYW5nZS5jb21dDQq3osvNyrG85DogMjAxNMTqONTCMjLI1SAxNjoyMg0KytW8/sjLOiBI YW93ZWlndW87IFVUVEFSTywgSkFNRVM7ICdpZHJAaWV0Zi5vcmcnOyAnbDJ2cG5AaWV0Zi5vcmcn DQqzrcvNOiBsaXV3ZWloYW5nDQrW98ziOiBSRTogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv ciBkcmFmdC1oYW8taWRyLWZsb3dzcGVjLWV2cG4tMDAudHh0DQoNCkhpLA0KDQpJIHRoaW5rIHRo aXMgaXMgYSB2YWx1YWJsZSBhZGRpdGlvbiwgYnV0IEkgd291bGQgbGlrZSB0byBzZWUgdGhlc2Ug TUFDIGZpbHRlcnMgYmVpbmcgYXBwbGljYWJsZSBhbHNvIHRvIElQdjQgcGx1Z3MgKEZTIElQdjQg JiBWUE52NCkNClt3ZWlndW9dOiBUaGFua3MuIEJ1dCBNQUMgZmlsdGVycyBtYXliZSBub3QgYXBw bGljYWJsZSB0byBJUFY0ICZWUE52NCwgYmVjYXVzZSBpbiB0aGlzIGNhc2UsIE1BQyBpbmZvcm1h dGlvbiB3aWxsIGJlIGNoYW5nZWQgb24gZGlmZmVyZW50IFBFIGRldmljZXMsIGEgc2luZ2xlIEFD TCBydWxlIGNhbid0IGlkZW50aWZ5IGEgY29uc2lzdGFudCBmbG93IGF0IGRpZmZlcmVudCBQRSBk ZXZpY2VzLiBTbyBpbiBJUCBuZXR3b3JrLCBmbG93LXNwZWMgY2FuIG9ubHkgYmUgZGVmaW5lZCB1 c2luZyBJUCByZWxhdGVkIGluZm9ybWF0aW9uLg0KDQpNb3Jlb3ZlciAsIHRoZSBuZXcgQUZJL1NB Rkkgc2hvdWxkIG5vdCBiZSByZXN0cmljdGVkIHRvIEVWUE4sIGFueSBMMiBpbnRlcmZhY2UgbWF5 IGJlIGludGVyZXN0ZWQgYnkgc3VjaCBmaWx0ZXIgKFZQTFMsIGJhc2ljIEwyIHN3aXRjaGluZyAu Li4pLg0KW3dlaWd1b106IFllcywgSSBhZ3JlZS4gRmlyc3RseSBpIHByb3Bvc2UgRXRoZXJuZXQg Zmxvdy1zcGVjIG9ubHkgaW4gRVZQTiBuZXR3b3JrLCBiZWNhdXNlIGZsb3dzLXBlYyByZWxpZXMg b24gQkdQIHByb3RvY29sIGFuZCBFVlBOIGhhcyBCR1AgY29udHJvbCBwbGFuZSwgc28gaXQgd2ls bCBiZSBlYXN5IHRvIGRlcGxveSBCR1AgZmxvd3NwZWMgaW4gRVZQTiBuZXR3b3JrLiBJZiB3ZSB3 YW50IHRvIGRlcGxveSB0aGUgZmxvdy1zcGVjIGluIFZQTFMgbmV0d29yaywgbm9ybWFsbHkgVlBM UyBvbmx5IHJlbGllcyBvbiBMRFAgcHJvdG9jb2wsIGFkZGl0aW9uYWwgcHJvdG9jb2wgb2YgQkdQ IGZsb3ctc3BlYyBzaG91bGQgYmUgZGVwbG95ZWQgZm9yIE1BQyBmaWx0ZXJpbmcuDQpJZiB0aGUg Y29tbXVuaXR5IHRoaW5rcyBpdCBpcyBuZWNlc3NhcnkgdG8gaW50cm9kdWNlIGV0aGVybmV0IGZs b3ctc3BlYyBmb3IgYWxsIEwyIGludGVyZmFjZSwgaSBjYW4gdXBkYXRlIHRoaXMgcGFydCB0byBs ZXQgaXQgbm90IGJlIHJlc3RyaWN0ZWQgdG8gRVZQTi4NCg0KUm91dGUgZGlzdGluZ3Vpc2hlciBt YXkgYmUgaXMgbWlzc2luZyAuLi4NClt3ZWlndW9dOiBSRCB1c2FnZSBoYXMgbm8gZGlmZmVyZW5j ZSB3aXRoIG9yaWdpbmFsIEJHUCBWUE4gZGVmaW5pY2F0aW9uLiBDYW4geW91IGdpdmUgbWUgc29t ZSBtb3JlIGNsYXJpZmljYXRpb25zPw0KDQpOb3cgbW9yZSBnbG9iYWxseSwgbWF5IGJlIGl0J3Mg dGltZSB0byB0aGluayBtb3JlIGdsb2JhbGx5IGFib3V0IHRoZSBldm9sdXRpb24gb2YgRlMuIEkg cHJldHR5IHNlZSBGUyBldm9sdXRpb24gbGFyZ2VseSBiZXlvbmQgRERvUyBkb21haW4uIEZTIGlz IGEgdmVyeSBnb29kIHByb3RvY29sIGZvciBTRE4gYXBwbGljYXRpb25zLiBUaGUgcXVlc3Rpb24g YmVoaW5kIGlzIGRvIHdlIHJlYWxseSBuZWVkIHRvIHdvcmsgd2l0aCBtdWx0aXBsZSBhZGRyZXNz IGZhbWlsaWVzIGZvciBlYWNoIHR5cGUgb2YgInNlcnZpY2UiLyJpbnRlcmZhY2UgdHlwZSIgdG8g ZmlsdGVyIG9yIGRvIHdlIG5lZWQgdG8gaGF2ZSBhIG1vcmUgZ2xvYmFsIG1vZGVsIHdoZXJlIHdl IHdvdWxkIGJlIGFibGUgdG8gcHV0IGFueSB0eXBlIG9mIGZpbHRlciBhbnkgd2hlcmUgYW5kIGFw cGx5IG11bHRpcGxlIGFjdGlvbnMgKG9wZW5mbG93IGxpa2UgRlMpLiBDb21wYXJlZCB0byBvcGVu ZmxvdywgRlMgaGFzIHRoZSBtYWdpYyB0byBlbmFibGUgbXVsdGlwb2ludCBkaXN0cmlidXRpb24g b2YgYWN0aW9ucy4NCg0KW3dlaWd1b106IFllcywgQkdQIGZsb3ctc3BlYyBjYW4gYmUgYXBwbGlj YWJsZSBmb3Igc29tZSBTRE4gYXBwbGljYXRpb25zLiBJdCBoYXMgbW9yZSBwb3RlbnRpYWwgdG8g ZG8gbW9yZSBhdHRhY3RpdmUgdGhpbmdzLg0KDQpCZXN0IFJlZ2FyZHMsDQoNClN0ZXBoYW5lDQoN Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IElkciBbbWFpbHRvOmlkci1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSGFvd2VpZ3VvDQpTZW50OiBUaHVyc2RheSwgQXVn dXN0IDIxLCAyMDE0IDA0OjExDQpUbzogVVRUQVJPLCBKQU1FUzsgJ2lkckBpZXRmLm9yZyc7ICds MnZwbkBpZXRmLm9yZycNCkNjOiBsaXV3ZWloYW5nDQpTdWJqZWN0OiBbSWRyXSC08Li0OiBOZXcg VmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWhhby1pZHItZmxvd3NwZWMtZXZwbi0wMC50 eHQNCg0KSGkgSmltLA0KVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLiBUaGUgQkdQIEZsb3dzcGVj IHByb2NlZHVyZXMgaXMgaWxsdXN0cmF0ZWQgYXMgZm9sbG93aW5nOg0KDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBFVlBOIEZsb3dTcGVjIFNlc3Npb24gICAgICAg ICAgICAgICAgICBFVlBOIEZsb3dTcGVjIFNlc3Npb24NCkRET1MgRGV0ZWN0aW9uIEFwcGxpYW5j ZS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tRWdyZXNzIFBFLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS1JbmdyZXNzIFBFLS0tLS0tQ0UyDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQ0UxIERET1MgRGV0ZWN0aW9uIEFw cGxpYW5jZSBlc3RhYmxpc2hlcyBFVlBOIGZsb3dzcGVjIHNlc3Npb24gd2l0aCBFZ3Jlc3MgUEUs IGl0IGRldGVjdHMgRERPUyBhdHRhY2sgdHJhZmZpYyBhbmQgZ2VuZXJhdGUgQUNMIHJ1bGUsIHRo ZSBBQ0wgcnVsZSBpcyBhbm5vdW5jZWQgdG8gRWdyZXNzIFBFIHRocm91Z2ggRVZQTiBmbG93c3Bl YyBwcm90b2NvbCwgdGhlbiB0aGUgZWdyZXNzIFBFIGFubm91bmNlcyBpdCB0byBpbmdyZXNzIFBF LCBmaW5hbGx5IGluZ3Jlc3MgUEUgaW5zdGFsbHMgdGhlIEFDTCBydWxlIGZvciB0cmFmZmljIGZp bHRlcmluZy4NCkRET1MgRGV0ZWN0aW9uIEFwcGxpYW5jZSBvbmx5IG5lZWRzIHRvIHN1cHBvcnQg RVZQTiBmbG93c3BlYyBmdW5jdGlvbiwgaXQgZG9lc24ndCBuZWVkIHRvIHN1cHBvcnQgYmFzaWMg RVZQTiBmdW5jdGlvbi4NClRoYW5rcw0Kd2VpZ3VvDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQq3orz+yMs6IFVUVEFSTywgSkFNRVMgW2p1MTczOEBhdHQuY29tXQ0K t6LLzcqxvOQ6IDIwMTTE6jjUwjIxyNUgMDoyOQ0KytW8/sjLOiBIYW93ZWlndW87ICdpZHJAaWV0 Zi5vcmcnOyAnbDJ2cG5AaWV0Zi5vcmcnDQqzrcvNOiBsaXV3ZWloYW5nDQrW98ziOiBSRTogTmV3 IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1oYW8taWRyLWZsb3dzcGVjLWV2cG4tMDAu dHh0DQoNCldlaWd1bywNCg0KICAgICAgICBJIHdvdWxkIGxpa2UgdG8gYmV0dGVyIHVuZGVyc3Rh bmQgaG93IGEgcmVtb3RlIFBFIHdpbGwgImxlYXJuIiB0aGF0IGl0IG5lZWRzIHRvIGRlbGl2ZXIg YSBGUyBwYXRoIHRvIHRoZSBpbmdyZXNzIFBFPz8gSXQgY2Fubm90IGNvbWUgZnJvbSB0aGUgQ0Ug YXMgdGhhdCBpcyBkYXRhIHBsYW5lIGxlYXJuaW5nLiBJIHdvdWxkIHRoaW5rIHRoYXQgYWxsIEZT IHBhdGhzIGhhdmUgdG8gYmUgZGlzc2VtaW5hdGVkIGJ5IGEgY2VudHJhbGl6ZWQgY29udHJvbGxl ci4NCg0KSmltIFV0dGFybw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSWRy IFttYWlsdG86aWRyLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBIYW93ZWlndW8NClNl bnQ6IFR1ZXNkYXksIEF1Z3VzdCAxOSwgMjAxNCA4OjMxIFBNDQpUbzogaWRyQGlldGYub3JnOyBs MnZwbkBpZXRmLm9yZw0KQ2M6IGxpdXdlaWhhbmcNClN1YmplY3Q6IFtJZHJdILTwuLQ6IE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaGFvLWlkci1mbG93c3BlYy1ldnBuLTAwLnR4 dA0KDQpIaSBBbGwsDQpXZSBoYXZlIHN1Ym1pdHRlZCBhIGRyYWZ0IG9mICIgRGlzc2VtaW5hdGlv biBvZiBGbG93IFNwZWNpZmljYXRpb24gUnVsZXMgZm9yIEVWUE4iLiAgSSB3aWxsIGFwcHJpY2lh dGUgaWYgeW91IGNhbiBnaXZlIHVzIHNvbWUgc3VnZ2VzdGlvbnMgYW5kIGNvbW1lbnRzLg0KVGhh bmtzDQp3ZWlndW8NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K t6K8/sjLOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW2ludGVybmV0LWRyYWZ0c0BpZXRmLm9y Z10NCreiy83KsbzkOiAyMDE0xOo41MIyMMjVIDg6MjANCsrVvP7IyzogWmh1YW5nc2h1bndhbjsg SGFvd2VpZ3VvOyBsaXV3ZWloYW5nOyBaaHVhbmdzaHVud2FuOyBsaXV3ZWloYW5nOyBIYW93ZWln dW8NCtb3zOI6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaGFvLWlkci1mbG93 c3BlYy1ldnBuLTAwLnR4dA0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaGFvLWlkci1m bG93c3BlYy1ldnBuLTAwLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBX ZWlndW8gSGFvIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZTogICAg ICAgICAgIGRyYWZ0LWhhby1pZHItZmxvd3NwZWMtZXZwbg0KUmV2aXNpb246ICAgICAgIDAwDQpU aXRsZTogICAgICAgICAgRGlzc2VtaW5hdGlvbiBvZiBGbG93IFNwZWNpZmljYXRpb24gUnVsZXMg Zm9yIEVWUE4NCkRvY3VtZW50IGRhdGU6ICAyMDE0LTA4LTIwDQpHcm91cDogICAgICAgICAgSW5k aXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczogICAgICAgICAgNw0KVVJMOiAgICAgICAgICAgIGh0 dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWhhby1pZHItZmxvd3NwZWMt ZXZwbi0wMC50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1oYW8taWRyLWZsb3dzcGVjLWV2cG4vDQpIdG1saXplZDogICAgICAgaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaGFvLWlkci1mbG93c3BlYy1ldnBuLTAwDQoNCg0K QWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IGRlZmluZXMgQkdQIGZsb3ctc3BlYyBleHRlbnNp b24gZm9yIEV0aGVybmV0IHRyYWZmaWMNCiAgIGZpbHRlcmluZyBpbiBFVlBOIG5ldHdvcmsuIEEg bmV3IEJHUCBOTFJJIHR5cGUgKEFGST0yNSwgU0FGST1UQkQpDQogICB2YWx1ZSBpcyBwcm9wb3Nl ZCB0byBpZGVudGlmeSBFVlBOIGZsb3ctc3BlYyBhcHBsaWNhdGlvbi4gQSBuZXcNCiAgIHN1YnNl dCBvZiBjb21wb25lbnQgdHlwZXMgYW5kIGV4dGVuZGVkIGNvbW11bml0eSBhbHNvIGFyZSBkZWZp bmVkLg0KDQoNCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1p bnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJz aW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRG IFNlY3JldGFyaWF0DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KSWRyIG1haWxpbmcgbGlzdA0KSWRyQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2lkcg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCklkciBtYWlsaW5nIGxpc3QNCklkckBpZXRmLm9yZw0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZHINCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpDZSBtZXNzYWdl IGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMg Y29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMgcGFzIGV0 cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZv dXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIg YSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRl cy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJh dGlvbiwgT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBh IGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KDQpUaGlzIG1lc3NhZ2Ug YW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdl ZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3OyB0aGV5IHNob3VsZCBu b3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4N CklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkg dGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0K QXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2Fn ZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KVGhhbmsg eW91Lg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQoNCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZl bnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdp ZWVzIGV0IG5lIGRvaXZlbnQgZG9uYyBwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNv cGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIg ZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlciBhIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWly ZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVl cyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLCBPcmFuZ2UgZGVjbGluZSB0b3V0ZSBy ZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxz aWZpZS4gTWVyY2kuDQoNClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250 YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHBy b3RlY3RlZCBieSBsYXc7IHRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBj b3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBl bWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBt ZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9y YW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwg Y2hhbmdlZCBvciBmYWxzaWZpZWQuDQpUaGFuayB5b3UuDQoKX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBl dCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNv bmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJl IGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3Vz IGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEg bCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMu IExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRp b24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBl dGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQg aXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGlu Zm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBi ZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5 b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBz ZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1h aWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhh dCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= From nobody Mon Sep 1 11:05:47 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 969071A0660 for ; Mon, 1 Sep 2014 11:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pGsS619__ReV for ; Mon, 1 Sep 2014 11:05:39 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0184.outbound.protection.outlook.com [207.46.163.184]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76F821A064C for ; Mon, 1 Sep 2014 11:05:38 -0700 (PDT) Received: from hannes-mba.local (193.110.55.13) by CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) with Microsoft SMTP Server (TLS) id 15.0.1019.16; Mon, 1 Sep 2014 18:05:35 +0000 Received: from juniper.net (localhost [IPv6:::1]) by hannes-mba.local (Postfix) with ESMTP id EDABA2A1218; Mon, 1 Sep 2014 20:05:18 +0200 (CEST) Date: Mon, 1 Sep 2014 20:05:18 +0200 From: Hannes Gredler To: Uma Chunduri Message-ID: <20140901180518.GA34789@juniper.net> References: <025201cfc15c$bbe17260$33a45720$@ndzh.com> <1B502206DFA0C544B7A60469152008633F364057@eusaamb105.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <1B502206DFA0C544B7A60469152008633F364057@eusaamb105.ericsson.se> User-Agent: Mutt/1.5.23 (2014-03-12) X-Originating-IP: [193.110.55.13] X-ClientProxiedBy: DB4PR04CA0021.eurprd04.prod.outlook.com (25.160.41.31) To CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;UriScan:; X-Forefront-PRVS: 03218BFD9F X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(377454003)(24454002)(189002)(199003)(50466002)(36756003)(54356999)(4396001)(99396002)(46102001)(15202345003)(46406003)(105586002)(76176999)(95666004)(50986999)(77982001)(31966008)(76482001)(23726002)(77096002)(74662001)(74502001)(76506005)(79102001)(64706001)(47776003)(20776003)(86362001)(15975445006)(21056001)(83506001)(107046002)(101416001)(81342001)(87976001)(81542001)(92566001)(97756001)(80022001)(92726001)(66066001)(33656002)(85852003)(83072002)(102836001)(90102001)(230783001)(19580405001)(110136001)(83322001)(106356001)(19580395003)(85306004)(579124003); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB442; H:hannes-mba.local; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/idr/jTwNCs-rdWtDN3oJx96J7NTzKBI Cc: "idr@ietf.org" , "'John G. Scudder'" , Susan Hares Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-ietf-idr-ls-distribut-impl X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2014 18:05:45 -0000 hi uma, see comments/responses inline: On Wed, Aug 27, 2014 at 11:07:01AM +0000, Uma Chunduri wrote: | Support. | | I see, hierarchy is WELL defined when multiple instances of IGP with | multiple AFs are running. Good work. | | | | Have following Qs: | | 1. Any discussion of the delay introduced by BGP (packing, update | generation, processing etc..) to transport the LS information | | especially, when LSDB is changing faster perhaps with large number of | nodes/links inside an AS and with multiple ASes) to the controller will be | useful. this is highly implementation dependent; - some vendors do the packaging of BGP updates entirely event-driven and others pack things up and have a worst case delay between the trigger event and the BGP update. the protocol itself does not prohibit/limit the propagation speed. (in fact it can be shown that sometimes updates travel faster on the (dataplane forwarded) iBGP mesh, rather than propgate using the hop-by-hop control-plane flooding protocol) | A note on the sensitivity of this delay to the consumer | (applications) at the controller can be helpful. I saw very little | discussion in Section 6 (6.1.5) difficiult - its hard to have some sort of general comment as things are highly implementation dependent. | 2. This document encompasses pretty much both OSPF and ISIS | extensions done till date. How it will keep up with future extensions in | OSPF/ISIS. we have set up an IANA registries for the carriers of information. it is expected by authors of "topological relevant" IGP extensions to supply also BGP-LS extensions. | A mechanism in place would be helpful. My suggestion would be- the | respective IGP documents should assess the impact and define | | corresponding new TLVs for BGP LS? But how this can be enforced? i have no idea - today its entirely voluntary. | 3. Section 4, gives glimpse what's possible and the node aggregating | the links obviously need to tinker the LSDB to represent the same | correctly. | | Some more details would be helpful to represent the changes on | aggregation/de-aggregation subsequently. this may quickly get you into the "abstracted topology models" discussion that keeps emerging periodically. - we did not want to stop progress on the protocol by arguing "whats the right abstraction model" and have agreed on the minimalistic nature of the section as-is. | 4. Section 6.2 has empty sub-sections and TBDs. right ... so suggest to remove section 6.2 altogether. | 5. It's good to see Implementation report shed light on performance | seen with multiple ASes. | | 6. It's good to see if any application of policy on LSDB is done | (one of the primary drivers of the specification). thanks, /hannes | | From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares | Sent: Tuesday, August 26, 2014 11:37 AM | To: idr@ietf.org | Cc: 'John G. Scudder'; shares@ndzh.com | Subject: [Idr] WG LC for draft-ietf-idr-ls-distribution and | draft-ietf-idr-ls-distribut-impl | | | | This is a WG LC for | | | | [1]http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/ | | [2]http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution-impl/ | | | | Please respond with comments and "support or no support." This WG LC also | includes a request for the authors to provide IPR on the subject. | | | | Please note: due to the European vacations in August, we are bundling | these three reviews into the next two weeks (these two drafts and | draft-ietf-as-migration). The chairs would like feedback (list or | private email) whether the three WG LC s impact anyone's ability to review | these drafts carefully. | | | | Thank you, | | | | Sue Hares and John Scudder | | References | | Visible links | 1. http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/ | 2. http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution-impl/ | _______________________________________________ | Idr mailing list | Idr@ietf.org | https://www.ietf.org/mailman/listinfo/idr From nobody Mon Sep 1 23:44:24 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC3F1A0031 for ; Mon, 1 Sep 2014 23:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.254 X-Spam-Level: X-Spam-Status: No, score=0.254 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0zad0R7tQvfw for ; Mon, 1 Sep 2014 23:44:18 -0700 (PDT) Received: from cmccmta3.chinamobile.com (cmccmta3.chinamobile.com [221.176.66.81]) by ietfa.amsl.com (Postfix) with SMTP id 0192C1A0013 for ; Mon, 1 Sep 2014 23:44:17 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.121.1]) by rmmx-syy-dmz-app10-12010 (RichMail) with SMTP id 2eea54056740171-5d2ca; Tue, 02 Sep 2014 14:44:16 +0800 (CST) X-RM-TRANSID: 2eea54056740171-5d2ca X-RM-SPAM-FLAG: 00000000 Received: from lizhenqiang (unknown[10.2.52.185]) by rmsmtp-syy-appsvr01-12001 (RichMail) with SMTP id 2ee15405673e4fa-a7857; Tue, 02 Sep 2014 14:44:16 +0800 (CST) X-RM-TRANSID: 2ee15405673e4fa-a7857 Date: Tue, 2 Sep 2014 14:44:36 +0800 From: "lizhenqiang@chinamobile.com" To: "Hannes Gredler" , "Uma Chunduri" References: <025201cfc15c$bbe17260$33a45720$@ndzh.com>, <1B502206DFA0C544B7A60469152008633F364057@eusaamb105.ericsson.se>, <20140901180518.GA34789@juniper.net> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 5, 140[cn] Mime-Version: 1.0 Message-ID: <2014090214443576954410@chinamobile.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart677805815441_=----" Archived-At: http://mailarchive.ietf.org/arch/msg/idr/wjNQLgkd8kx-QWUUaOF7-_LmgnI Cc: 'idr wg' , Susan Hares , "'John G. Scudder'" Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-ietf-idr-ls-distribut-impl X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 06:44:23 -0000 This is a multi-part message in MIME format. ------=_001_NextPart677805815441_=---- Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 T25lIHF1ZXN0aW9uIGFib3V0IHRoZSBWUE4gTGluay1TdGF0ZSBOTFJJIGluIHNlY3Rpb24gMy4y LiBXaHkgZG8geW91IHB1dCB0aGUgUkQgYmVmb3JlIGxpbmsgc3RhdGUgTlJMST8gV2h5IGRvJ3Qg eW91IHB1dCBSRCBpbiBJUCBSZWFjaGFiaWxpdHkgSW5mb3JtYXRpb24sIGp1c3QgcHJlcHJlbmRp bmcgUkQgd2l0aCBJUCBwcmVmaXggYXMgUkZDNDM2NCBzcGVjaWZpZXMuDQoNCg0KDQoNCmxpemhl bnFpYW5nQGNoaW5hbW9iaWxlLmNvbQ0KIA0KRnJvbTogSGFubmVzIEdyZWRsZXINCkRhdGU6IDIw MTQtMDktMDIgMDI6MDUNClRvOiBVbWEgQ2h1bmR1cmkNCkNDOiBpZHJAaWV0Zi5vcmc7ICdKb2hu IEcuIFNjdWRkZXInOyBTdXNhbiBIYXJlcw0KU3ViamVjdDogUmU6IFtJZHJdIFdHIExDIGZvciBk cmFmdC1pZXRmLWlkci1scy1kaXN0cmlidXRpb24gYW5kIGRyYWZ0LWlldGYtaWRyLWxzLWRpc3Ry aWJ1dC1pbXBsDQpoaSB1bWEsDQogDQpzZWUgY29tbWVudHMvcmVzcG9uc2VzIGlubGluZToNCiAN Ck9uIFdlZCwgQXVnIDI3LCAyMDE0IGF0IDExOjA3OjAxQU0gKzAwMDAsIFVtYSBDaHVuZHVyaSB3 cm90ZToNCnwgICAgU3VwcG9ydC4NCnwgDQp8ICAgIEkgc2VlLCBoaWVyYXJjaHkgaXMgV0VMTCAg ZGVmaW5lZCB3aGVuIG11bHRpcGxlIGluc3RhbmNlcyBvZiBJR1Agd2l0aA0KfCAgICBtdWx0aXBs ZSBBRnMgYXJlIHJ1bm5pbmcuIEdvb2Qgd29yay4NCnwgDQp8IA0KfCANCnwgICAgSGF2ZSBmb2xs b3dpbmcgUXM6DQp8IA0KfCAgICAxLiAgICAgICBBbnkgZGlzY3Vzc2lvbiBvZiB0aGUgZGVsYXkg aW50cm9kdWNlZCBieSBCR1AgKHBhY2tpbmcsIHVwZGF0ZQ0KfCAgICBnZW5lcmF0aW9uLCBwcm9j ZXNzaW5nIGV0Yy4uKSB0byB0cmFuc3BvcnQgdGhlIExTIGluZm9ybWF0aW9uDQp8IA0KfCAgICBl c3BlY2lhbGx5LCB3aGVuIExTREIgaXMgY2hhbmdpbmcgZmFzdGVyIHBlcmhhcHMgd2l0aCBsYXJn ZSBudW1iZXIgb2YNCnwgICAgbm9kZXMvbGlua3MgaW5zaWRlIGFuIEFTIGFuZCB3aXRoIG11bHRp cGxlIEFTZXMpIHRvIHRoZSBjb250cm9sbGVyIHdpbGwgYmUNCnwgICAgdXNlZnVsLg0KIA0KdGhp cyBpcyBoaWdobHkgaW1wbGVtZW50YXRpb24gZGVwZW5kZW50OyAtIA0Kc29tZSB2ZW5kb3JzIGRv IHRoZSBwYWNrYWdpbmcgb2YgQkdQIHVwZGF0ZXMgZW50aXJlbHkgZXZlbnQtZHJpdmVuDQphbmQg b3RoZXJzIHBhY2sgdGhpbmdzIHVwIGFuZCBoYXZlIGEgd29yc3QgY2FzZSBkZWxheSBiZXR3ZWVu DQp0aGUgdHJpZ2dlciBldmVudCBhbmQgdGhlIEJHUCB1cGRhdGUuIHRoZSBwcm90b2NvbA0KaXRz ZWxmIGRvZXMgbm90IHByb2hpYml0L2xpbWl0IHRoZSBwcm9wYWdhdGlvbiBzcGVlZC4NCihpbiBm YWN0IGl0IGNhbiBiZSBzaG93biB0aGF0IHNvbWV0aW1lcyB1cGRhdGVzDQp0cmF2ZWwgZmFzdGVy IG9uIHRoZSAoZGF0YXBsYW5lIGZvcndhcmRlZCkgaUJHUCBtZXNoLA0KcmF0aGVyIHRoYW4gcHJv cGdhdGUgdXNpbmcgdGhlIGhvcC1ieS1ob3AgY29udHJvbC1wbGFuZSBmbG9vZGluZw0KcHJvdG9j b2wpDQogDQp8ICAgICAgICAgICAgICAgICBBIG5vdGUgb24gdGhlIHNlbnNpdGl2aXR5IG9mIHRo aXMgZGVsYXkgdG8gdGhlIGNvbnN1bWVyDQp8ICAgIChhcHBsaWNhdGlvbnMpIGF0IHRoZSBjb250 cm9sbGVyICBjYW4gYmUgaGVscGZ1bC4gSSBzYXcgdmVyeSBsaXR0bGUNCnwgICAgZGlzY3Vzc2lv biBpbiBTZWN0aW9uIDYgKDYuMS41KQ0KIA0KZGlmZmljaXVsdCAtIGl0cyBoYXJkIHRvIGhhdmUg c29tZSBzb3J0IG9mIGdlbmVyYWwgY29tbWVudCBhcyB0aGluZ3MgYXJlDQpoaWdobHkgaW1wbGVt ZW50YXRpb24gZGVwZW5kZW50Lg0KIA0KIA0KfCAgICAyLiAgICAgICBUaGlzIGRvY3VtZW50IGVu Y29tcGFzc2VzIHByZXR0eSBtdWNoIGJvdGggT1NQRiBhbmQgSVNJUw0KfCAgICBleHRlbnNpb25z IGRvbmUgdGlsbCBkYXRlLiBIb3cgaXQgd2lsbCBrZWVwIHVwIHdpdGggZnV0dXJlIGV4dGVuc2lv bnMgaW4NCnwgICAgT1NQRi9JU0lTLg0KIA0Kd2UgaGF2ZSBzZXQgdXAgYW4gSUFOQSByZWdpc3Ry aWVzIGZvciB0aGUgY2FycmllcnMgb2YgaW5mb3JtYXRpb24uDQppdCBpcyBleHBlY3RlZCBieSBh dXRob3JzIG9mICJ0b3BvbG9naWNhbCByZWxldmFudCIgSUdQIGV4dGVuc2lvbnMNCnRvIHN1cHBs eSBhbHNvIEJHUC1MUyBleHRlbnNpb25zLg0KIA0KfCAgICBBIG1lY2hhbmlzbSBpbiBwbGFjZSB3 b3VsZCBiZSBoZWxwZnVsLiBNeSBzdWdnZXN0aW9uIHdvdWxkIGJlLSAgdGhlDQp8ICAgIHJlc3Bl Y3RpdmUgSUdQIGRvY3VtZW50cyBzaG91bGQgYXNzZXNzIHRoZSBpbXBhY3QgYW5kIGRlZmluZQ0K fCANCnwgICAgY29ycmVzcG9uZGluZyBuZXcgVExWcyBmb3IgQkdQIExTPyBCdXQgaG93IHRoaXMg Y2FuIGJlIGVuZm9yY2VkPw0KIA0KaSBoYXZlIG5vIGlkZWEgLSB0b2RheSBpdHMgZW50aXJlbHkg dm9sdW50YXJ5Lg0KIA0KfCAgICAzLiAgICAgICBTZWN0aW9uIDQsIGdpdmVzIGdsaW1wc2Ugd2hh dCdzIHBvc3NpYmxlIGFuZCB0aGUgbm9kZSBhZ2dyZWdhdGluZw0KfCAgICB0aGUgbGlua3Mgb2J2 aW91c2x5IG5lZWQgdG8gdGlua2VyIHRoZSBMU0RCIHRvIHJlcHJlc2VudCB0aGUgc2FtZQ0KfCAg ICBjb3JyZWN0bHkuDQp8IA0KfCAgICBTb21lIG1vcmUgZGV0YWlscyB3b3VsZCBiZSBoZWxwZnVs IHRvIHJlcHJlc2VudCB0aGUgY2hhbmdlcyBvbg0KfCAgICBhZ2dyZWdhdGlvbi9kZS1hZ2dyZWdh dGlvbiBzdWJzZXF1ZW50bHkuDQogDQp0aGlzIG1heSBxdWlja2x5IGdldCB5b3UgaW50byB0aGUg ImFic3RyYWN0ZWQgdG9wb2xvZ3kgbW9kZWxzIg0KZGlzY3Vzc2lvbiB0aGF0IGtlZXBzIGVtZXJn aW5nICBwZXJpb2RpY2FsbHkuIC0NCndlIGRpZCBub3Qgd2FudCB0byBzdG9wIHByb2dyZXNzIG9u IHRoZSBwcm90b2NvbCBieSBhcmd1aW5nDQoid2hhdHMgdGhlIHJpZ2h0IGFic3RyYWN0aW9uIG1v ZGVsIiBhbmQgaGF2ZSBhZ3JlZWQNCm9uIHRoZSBtaW5pbWFsaXN0aWMgbmF0dXJlIG9mIHRoZSBz ZWN0aW9uIGFzLWlzLg0KIA0KIA0KfCAgICA0LiAgICAgICBTZWN0aW9uIDYuMiBoYXMgZW1wdHkg c3ViLXNlY3Rpb25zIGFuZCBUQkRzLg0KIA0KcmlnaHQgLi4uIHNvIHN1Z2dlc3QgdG8gcmVtb3Zl IHNlY3Rpb24gNi4yIGFsdG9nZXRoZXIuDQogDQp8ICAgIDUuICAgICAgIEl0J3MgZ29vZCB0byBz ZWUgSW1wbGVtZW50YXRpb24gcmVwb3J0IHNoZWQgbGlnaHQgb24gcGVyZm9ybWFuY2UNCnwgICAg c2VlbiB3aXRoIG11bHRpcGxlIEFTZXMuDQp8IA0KfCAgICA2LiAgICAgICBJdCdzIGdvb2QgdG8g c2VlIGlmIGFueSBhcHBsaWNhdGlvbiBvZiBwb2xpY3kgb24gTFNEQiBpcyBkb25lDQp8ICAgIChv bmUgb2YgdGhlIHByaW1hcnkgZHJpdmVycyBvZiB0aGUgc3BlY2lmaWNhdGlvbikuDQogDQogDQp0 aGFua3MsDQogDQogDQovaGFubmVzDQogDQp8IA0KfCAgICBGcm9tOiBJZHIgW21haWx0bzppZHIt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFN1c2FuIEhhcmVzDQp8ICAgIFNlbnQ6IFR1 ZXNkYXksIEF1Z3VzdCAyNiwgMjAxNCAxMTozNyBBTQ0KfCAgICBUbzogaWRyQGlldGYub3JnDQp8 ICAgIENjOiAnSm9obiBHLiBTY3VkZGVyJzsgc2hhcmVzQG5kemguY29tDQp8ICAgIFN1YmplY3Q6 IFtJZHJdIFdHIExDIGZvciBkcmFmdC1pZXRmLWlkci1scy1kaXN0cmlidXRpb24gYW5kDQp8ICAg IGRyYWZ0LWlldGYtaWRyLWxzLWRpc3RyaWJ1dC1pbXBsDQp8IA0KfCANCnwgDQp8ICAgIFRoaXMg aXMgYSBXRyBMQyBmb3INCnwgDQp8IA0KfCANCnwgICAgICBbMV1odHRwOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaWRyLWxzLWRpc3RyaWJ1dGlvbi8NCnwgDQp8ICAgICAg WzJdaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWlkci1scy1kaXN0 cmlidXRpb24taW1wbC8NCnwgDQp8IA0KfCANCnwgICAgUGxlYXNlIHJlc3BvbmQgd2l0aCBjb21t ZW50cyBhbmQgInN1cHBvcnQgb3Igbm8gc3VwcG9ydC4iICBUaGlzIFdHIExDIGFsc28NCnwgICAg aW5jbHVkZXMgYSByZXF1ZXN0IGZvciB0aGUgYXV0aG9ycyB0byBwcm92aWRlIElQUiBvbiB0aGUg c3ViamVjdC4NCnwgDQp8IA0KfCANCnwgICAgUGxlYXNlIG5vdGU6IGR1ZSB0byB0aGUgRXVyb3Bl YW4gdmFjYXRpb25zIGluIEF1Z3VzdCwgd2UgYXJlIGJ1bmRsaW5nDQp8ICAgIHRoZXNlIHRocmVl IHJldmlld3MgaW50byB0aGUgbmV4dCB0d28gd2Vla3MgKHRoZXNlIHR3byBkcmFmdHMgYW5kDQp8 ICAgIGRyYWZ0LWlldGYtYXMtbWlncmF0aW9uKS4gICBUaGUgY2hhaXJzIHdvdWxkIGxpa2UgZmVl ZGJhY2sgKGxpc3Qgb3INCnwgICAgcHJpdmF0ZSBlbWFpbCkgd2hldGhlciB0aGUgdGhyZWUgV0cg TEMgcyBpbXBhY3QgYW55b25lJ3MgYWJpbGl0eSB0byByZXZpZXcNCnwgICAgdGhlc2UgZHJhZnRz IGNhcmVmdWxseS4NCnwgDQp8IA0KfCANCnwgICAgVGhhbmsgeW91LA0KfCANCnwgDQp8IA0KfCAg ICBTdWUgSGFyZXMgYW5kIEpvaG4gU2N1ZGRlcg0KfCANCnwgUmVmZXJlbmNlcw0KfCANCnwgICAg VmlzaWJsZSBsaW5rcw0KfCAgICAxLiBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWlldGYtaWRyLWxzLWRpc3RyaWJ1dGlvbi8NCnwgICAgMi4gaHR0cDovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWlkci1scy1kaXN0cmlidXRpb24taW1wbC8NCiANCnwg X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnwgSWRyIG1h aWxpbmcgbGlzdA0KfCBJZHJAaWV0Zi5vcmcNCnwgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9pZHINCiANCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpJZHIgbWFpbGluZyBsaXN0DQpJZHJAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRyDQogDQo= ------=_001_NextPart677805815441_=---- Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =0A
One question about the VPN Li= nk-State NLRI in section 3.2. Why do you put the RD before link state NRLI= ? Why do't you put RD in IP Reachability Inform= ation, just preprending RD with IP prefix as RFC4364 specifies.

=0A

=0A
=0A
lizhe= nqiang@chinamobile.com
=0A
 
Date: 2014-09-02 0= 2:05
Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-ietf-= idr-ls-distribut-impl
hi uma,
=0A
&nbs= p;
=0A
see comments/responses inline:
=0A
 
= =0A
On Wed, Aug 27, 2014 at 11:07:01AM +0000, Uma Chunduri wrote:=0A
|    Support.
=0A
|
=0A
| =    I see, hierarchy is WELL  defined when multiple instance= s of IGP with
=0A
|    multiple AFs are running. G= ood work.
=0A
|
=0A
|
=0A
|
=0A
|&n= bsp;   Have following Qs:
=0A
|
=0A
| &n= bsp;  1.       Any discussion of the de= lay introduced by BGP (packing, update
=0A
|    ge= neration, processing etc..) to transport the LS information
=0A
|=
=0A
|    especially, when LSDB is changing faste= r perhaps with large number of
=0A
|    nodes/link= s inside an AS and with multiple ASes) to the controller will be
=0A<= div>|    useful.
=0A
 
=0A
this is h= ighly implementation dependent; -
=0A
some vendors do the packag= ing of BGP updates entirely event-driven
=0A
and others pack thin= gs up and have a worst case delay between
=0A
the trigger event a= nd the BGP update. the protocol
=0A
itself does not prohibit/limi= t the propagation speed.
=0A
(in fact it can be shown that someti= mes updates
=0A
travel faster on the (dataplane forwarded) iBGP m= esh,
=0A
rather than propgate using the hop-by-hop control-plane = flooding
=0A
protocol)
=0A
 
=0A
| &n= bsp;           &nbs= p;   A note on the sensitivity of this delay to the consumer=0A
|    (applications) at the controller  can b= e helpful. I saw very little
=0A
|    discussion i= n Section 6 (6.1.5)
=0A
 
=0A
difficiult - its hard= to have some sort of general comment as things are
=0A
highly im= plementation dependent.
=0A
 
=0A
 
=0A|    2.       This documen= t encompasses pretty much both OSPF and ISIS
=0A
|  &nb= sp; extensions done till date. How it will keep up with future extensions = in
=0A
|    OSPF/ISIS.
=0A
 
= =0A
we have set up an IANA registries for the carriers of information.=
=0A
it is expected by authors of "topological relevant" IGP exte= nsions
=0A
to supply also BGP-LS extensions.
=0A
 <= /div>=0A
|    A mechanism in place would be helpful. My= suggestion would be-  the
=0A
|    respectiv= e IGP documents should assess the impact and define
=0A
|
= =0A
|    corresponding new TLVs for BGP LS? But how thi= s can be enforced?
=0A
 
=0A
i have no idea - today= its entirely voluntary.
=0A
 
=0A
|  &nb= sp; 3.       Section 4, gives glimpse what's= possible and the node aggregating
=0A
|    the li= nks obviously need to tinker the LSDB to represent the same
=0A
|=     correctly.
=0A
|
=0A
|  &n= bsp; Some more details would be helpful to represent the changes on
= =0A
|    aggregation/de-aggregation subsequently.
= =0A
 
=0A
this may quickly get you into the "abstracted = topology models"
=0A
discussion that keeps emerging  periodi= cally. -
=0A
we did not want to stop progress on the protocol by = arguing
=0A
"whats the right abstraction model" and have agreed=0A
on the minimalistic nature of the section as-is.
=0A
=  
=0A
 
=0A
|    4.  =      Section 6.2 has empty sub-sections and TBDs.=0A
 
=0A
right ... so suggest to remove section 6.2 al= together.
=0A
 
=0A
|    5. &nb= sp;     It's good to see Implementation report shed li= ght on performance
=0A
|    seen with multiple ASe= s.
=0A
|
=0A
|    6.   &n= bsp;   It's good to see if any application of policy on LSDB is = done
=0A
|    (one of the primary drivers of the s= pecification).
=0A
 
=0A
 
=0A
thanks= ,
=0A
 
=0A
 
=0A
/hannes
=0A 
=0A
|
=0A
|    From: Idr [mailt= o:idr-bounces@ietf.org] On Behalf Of Susan Hares
=0A
|  = ;  Sent: Tuesday, August 26, 2014 11:37 AM
=0A
|  =   To: idr@ietf.org
=0A
|    Cc: 'John G. Scud= der'; shares@ndzh.com
=0A
|    Subject: [Idr] WG L= C for draft-ietf-idr-ls-distribution and
=0A
|    = draft-ietf-idr-ls-distribut-impl
=0A
|
=0A
|
=0A<= div>|
=0A
|    This is a WG LC for
=0A
|=
=0A
|
=0A
|
=0A
|    &n= bsp; [1]http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/=0A
|
=0A
|      [2]http://datat= racker.ietf.org/doc/draft-ietf-idr-ls-distribution-impl/
=0A
| =0A
|
=0A
|
=0A
|    Please res= pond with comments and "support or no support."  This WG LC also=0A
|    includes a request for the authors to provide= IPR on the subject.
=0A
|
=0A
|
=0A
|
= =0A
|    Please note: due to the European vacations in = August, we are bundling
=0A
|    these three revie= ws into the next two weeks (these two drafts and
=0A
|  = ;  draft-ietf-as-migration).   The chairs would like feedba= ck (list or
=0A
|    private email) whether the th= ree WG LC s impact anyone's ability to review
=0A
|  &n= bsp; these drafts carefully.
=0A
|
=0A
|
=0A
= |
=0A
|    Thank you,
=0A
|
=0A|
=0A
|
=0A
|    Sue Hares and John S= cudder
=0A
|
=0A
| References
=0A
|
=0A<= div>|    Visible links
=0A
|    1. = http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/
=0A|    2. http://datatracker.ietf.org/doc/draft-ietf-idr-l= s-distribution-impl/
=0A
 
=0A
| __________________= _____________________________
=0A
| Idr mailing list
=0A| Idr@ietf.org
=0A
| https://www.ietf.org/mailman/listinfo/idr=0A
 
=0A
__________________________________________= _____
=0A
Idr mailing list
=0A
Idr@ietf.org
=0Ahttps://www.ietf.org/mailman/listinfo/idr
=0A
 
=0A
=0A ------=_001_NextPart677805815441_=------ From nobody Tue Sep 2 00:29:43 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AD661A86E8 for ; Tue, 2 Sep 2014 00:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pqj_YKjqUkCW for ; Tue, 2 Sep 2014 00:29:39 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0184.outbound.protection.outlook.com [207.46.163.184]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48D871A86E7 for ; Tue, 2 Sep 2014 00:29:34 -0700 (PDT) Received: from CO1PR05MB444.namprd05.prod.outlook.com (10.141.73.140) by CO1PR05MB410.namprd05.prod.outlook.com (10.141.74.151) with Microsoft SMTP Server (TLS) id 15.0.1015.19; Tue, 2 Sep 2014 07:29:31 +0000 Received: from CO1PR05MB443.namprd05.prod.outlook.com (10.141.73.152) by CO1PR05MB444.namprd05.prod.outlook.com (10.141.73.140) with Microsoft SMTP Server (TLS) id 15.0.1019.16; Tue, 2 Sep 2014 07:29:29 +0000 Received: from CO1PR05MB443.namprd05.prod.outlook.com ([169.254.12.11]) by CO1PR05MB443.namprd05.prod.outlook.com ([169.254.12.11]) with mapi id 15.00.1019.015; Tue, 2 Sep 2014 07:29:28 +0000 From: Hannes Gredler To: "lizhenqiang@chinamobile.com" , Uma Chunduri Thread-Topic: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-ietf-idr-ls-distribut-impl Thread-Index: AQHPxnlY3KNqoWEkWEWbmYI34Eme3pvtbn6B Date: Tue, 2 Sep 2014 07:29:28 +0000 Message-ID: <1409642967216.58954@juniper.net> References: <025201cfc15c$bbe17260$33a45720$@ndzh.com>, <1B502206DFA0C544B7A60469152008633F364057@eusaamb105.ericsson.se>, <20140901180518.GA34789@juniper.net>, <2014090214443576954410@chinamobile.com> In-Reply-To: <2014090214443576954410@chinamobile.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [193.110.55.13] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:;UriScan:; x-forefront-prvs: 0322B4EDE1 x-forefront-antispam-report: SFV:NSPM; SFS:(24454002)(189002)(377454003)(377424004)(199003)(87936001)(31966008)(2656002)(230783001)(36756003)(81342001)(15975445006)(83322001)(19580395003)(19580405001)(85852003)(83072002)(74502001)(74662001)(92566001)(77096002)(92726001)(95666004)(107046002)(99286002)(106116001)(77982001)(105586002)(19627405001)(106356001)(46102001)(76482001)(85306004)(4396001)(15202345003)(90102001)(117636001)(93886004)(99396002)(50986999)(21056001)(81542001)(80022001)(64706001)(19625215002)(86362001)(20776003)(16236675004)(101416001)(66066001)(54356999)(2501002)(76176999)(579124003); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB444; H:CO1PR05MB443.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_140964296721658954junipernet_" MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/idr/L6BENsKr-HmsIUHQcwUbCwaQ-GU Cc: 'idr wg' , Susan Hares , "'John G. Scudder'" Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-ietf-idr-ls-distribut-impl X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 07:29:41 -0000 --_000_140964296721658954junipernet_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hi zhenqiang, The Route-distinguisher's purpose is to add 64-bits of disambiguating entr= opy to the NLRI, such that the route-reflectors do not "swallow" that path as part of the best-pa= th election procedure. The link-state NLRI (encapsulated in MP_REACH/ MP UNREACH PA) is a RD-less version of the vpn-link-state NLRI. In a certain way these correspond to RFC3107 / RFC4364 NLRI formats. The former is a RD-less version of the latter. On your question "Why do't you put RD in IP Reachability Information, just = prepending RD with IP prefix as RFC4364 specifies." - This is actually what= we *are* doing - we put the RD before the link-state NLRI inside the MP_RE= ACH/MP_UNREACH Attribute. HTH, /hannes ________________________________ From: lizhenqiang@chinamobile.com Sent: Tuesday, September 02, 2014 8:44 To: Hannes Gredler; Uma Chunduri Cc: 'idr wg'; 'John G. Scudder'; Susan Hares Subject: Re: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-i= etf-idr-ls-distribut-impl One question about the VPN Link-State NLRI in section 3.2. Why do you put t= he RD before link state NRLI? Why do't you put RD in IP Reachability Inform= ation, just preprending RD with IP prefix as RFC4364 specifies. ________________________________ lizhenqiang@chinamobile.com From: Hannes Gredler Date: 2014-09-02 02:05 To: Uma Chunduri CC: idr@ietf.org; 'John G. Scudder'= ; Susan Hares Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-ietf-= idr-ls-distribut-impl hi uma, see comments/responses inline: On Wed, Aug 27, 2014 at 11:07:01AM +0000, Uma Chunduri wrote: | Support. | | I see, hierarchy is WELL defined when multiple instances of IGP with | multiple AFs are running. Good work. | | | | Have following Qs: | | 1. Any discussion of the delay introduced by BGP (packing, updat= e | generation, processing etc..) to transport the LS information | | especially, when LSDB is changing faster perhaps with large number of | nodes/links inside an AS and with multiple ASes) to the controller wil= l be | useful. this is highly implementation dependent; - some vendors do the packaging of BGP updates entirely event-driven and others pack things up and have a worst case delay between the trigger event and the BGP update. the protocol itself does not prohibit/limit the propagation speed. (in fact it can be shown that sometimes updates travel faster on the (dataplane forwarded) iBGP mesh, rather than propgate using the hop-by-hop control-plane flooding protocol) | A note on the sensitivity of this delay to the consumer | (applications) at the controller can be helpful. I saw very little | discussion in Section 6 (6.1.5) difficiult - its hard to have some sort of general comment as things are highly implementation dependent. | 2. This document encompasses pretty much both OSPF and ISIS | extensions done till date. How it will keep up with future extensions = in | OSPF/ISIS. we have set up an IANA registries for the carriers of information. it is expected by authors of "topological relevant" IGP extensions to supply also BGP-LS extensions. | A mechanism in place would be helpful. My suggestion would be- the | respective IGP documents should assess the impact and define | | corresponding new TLVs for BGP LS? But how this can be enforced? i have no idea - today its entirely voluntary. | 3. Section 4, gives glimpse what's possible and the node aggrega= ting | the links obviously need to tinker the LSDB to represent the same | correctly. | | Some more details would be helpful to represent the changes on | aggregation/de-aggregation subsequently. this may quickly get you into the "abstracted topology models" discussion that keeps emerging periodically. - we did not want to stop progress on the protocol by arguing "whats the right abstraction model" and have agreed on the minimalistic nature of the section as-is. | 4. Section 6.2 has empty sub-sections and TBDs. right ... so suggest to remove section 6.2 altogether. | 5. It's good to see Implementation report shed light on performa= nce | seen with multiple ASes. | | 6. It's good to see if any application of policy on LSDB is done | (one of the primary drivers of the specification). thanks, /hannes | | From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares | Sent: Tuesday, August 26, 2014 11:37 AM | To: idr@ietf.org | Cc: 'John G. Scudder'; shares@ndzh.com | Subject: [Idr] WG LC for draft-ietf-idr-ls-distribution and | draft-ietf-idr-ls-distribut-impl | | | | This is a WG LC for | | | | [1]http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/ | | [2]http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution-im= pl/ | | | | Please respond with comments and "support or no support." This WG LC = also | includes a request for the authors to provide IPR on the subject. | | | | Please note: due to the European vacations in August, we are bundling | these three reviews into the next two weeks (these two drafts and | draft-ietf-as-migration). The chairs would like feedback (list or | private email) whether the three WG LC s impact anyone's ability to re= view | these drafts carefully. | | | | Thank you, | | | | Sue Hares and John Scudder | | References | | Visible links | 1. http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/ | 2. http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution-impl= / | _______________________________________________ | Idr mailing list | Idr@ietf.org | https://www.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr --_000_140964296721658954junipernet_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

hi zhenqiang,


The Route-distinguisher's purpose is to add 64-bits of  disambiguat= ing entropy to the NLRI, such

that the route-reflectors do not "swallow" that path as part o= f the best-path election

procedure. The link-state NLRI (encapsulated in MP_REACH/ MP UNREACH PA)=

is a RD-less version of the vpn-link-state NLRI.

In a certain way thes= e correspond to RFC3107 / RFC4364 NLRI formats.

The former is a RD-le= ss version of the latter.


On your question &quo= t;Why do't you put RD in IP Reachability Information, just prepending RD with IP prefix as RFC4364 spe= cifies." - This is actually what we *are* doing - we put t= he RD before the link-state NLRI inside the MP_REACH/MP_UNREACH Attribute.<= /span>


HTH,


/hannes


From: lizhenqiang@chinamobi= le.com <lizhenqiang@chinamobile.com>
Sent: Tuesday, September 02, 2014 8:44
To: Hannes Gredler; Uma Chunduri
Cc: 'idr wg'; 'John G. Scudder'; Susan Hares
Subject: Re: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and = draft-ietf-idr-ls-distribut-impl
 
One question about the VPN Link-State NLRI in section 3.2. Why do you put the RD before li= nk state NRLI? Why do't you put RD in IP Reachability Information, just preprending RD with IP prefix as RFC4364 specifies.


lizhenqiang@chinamobile.com
 
Date: 2014-09-02 02:05
CC: idr@ietf.org; 'John G. Scudder'; Susan Hares
Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-distributio= n and draft-ietf-idr-ls-distribut-impl
hi uma,
 
see comments/responses inline:
 
On Wed, Aug 27, 2014 at 11:07:01AM +0000, Uma Chunduri wrote:
|    Support.
|
|    I see, hierarchy is WELL  defined when multip= le instances of IGP with
|    multiple AFs are running. Good work.
|
|
|
|    Have following Qs:
|
|    1.       Any discuss= ion of the delay introduced by BGP (packing, update
|    generation, processing etc..) to transport the LS = information
|
|    especially, when LSDB is changing faster perhaps w= ith large number of
|    nodes/links inside an AS and with multiple ASes) t= o the controller will be
|    useful.
 
this is highly implementation dependent; -
some vendors do the packaging of BGP updates entirely event-driven
and others pack things up and have a worst case delay between
the trigger event and the BGP update. the protocol
itself does not prohibit/limit the propagation speed.
(in fact it can be shown that sometimes updates
travel faster on the (dataplane forwarded) iBGP mesh,
rather than propgate using the hop-by-hop control-plane flooding
protocol)
 
|           &nb= sp;     A note on the sensitivity of this delay to the = consumer
|    (applications) at the controller  can be help= ful. I saw very little
|    discussion in Section 6 (6.1.5)
 
difficiult - its hard to have some sort of general comment as things a= re
highly implementation dependent.
 
 
|    2.       This docume= nt encompasses pretty much both OSPF and ISIS
|    extensions done till date. How it will keep up wit= h future extensions in
|    OSPF/ISIS.
 
we have set up an IANA registries for the carriers of information.
it is expected by authors of "topological relevant" IGP exte= nsions
to supply also BGP-LS extensions.
 
|    A mechanism in place would be helpful. My suggesti= on would be-  the
|    respective IGP documents should assess the impact = and define
|
|    corresponding new TLVs for BGP LS? But how this ca= n be enforced?
 
i have no idea - today its entirely voluntary.
 
|    3.       Section 4, = gives glimpse what's possible and the node aggregating
|    the links obviously need to tinker the LSDB to rep= resent the same
|    correctly.
|
|    Some more details would be helpful to represent th= e changes on
|    aggregation/de-aggregation subsequently.
 
this may quickly get you into the "abstracted topology models&quo= t;
discussion that keeps emerging  periodically. -
we did not want to stop progress on the protocol by arguing
"whats the right abstraction model" and have agreed
on the minimalistic nature of the section as-is.
 
 
|    4.       Section 6.2= has empty sub-sections and TBDs.
 
right ... so suggest to remove section 6.2 altogether.
 
|    5.       It's good t= o see Implementation report shed light on performance
|    seen with multiple ASes.
|
|    6.       It's good t= o see if any application of policy on LSDB is done
|    (one of the primary drivers of the specification).=
 
 
thanks,
 
 
/hannes
 
|
|    From: Idr [mailto:idr-bounces@ietf.org] On Behalf = Of Susan Hares
|    Sent: Tuesday, August 26, 2014 11:37 AM
|    To: idr@ietf.org
|    Cc: 'John G. Scudder'; shares@ndzh.com
|    Subject: [Idr] WG LC for draft-ietf-idr-ls-distrib= ution and
|    draft-ietf-idr-ls-distribut-impl
|
|
|
|    This is a WG LC for
|
|
|
|      [1]http://datatracker.ietf.org/doc/dra= ft-ietf-idr-ls-distribution/
|
|      [2]http://datatracker.ietf.org/doc/dra= ft-ietf-idr-ls-distribution-impl/
|
|
|
|    Please respond with comments and "support or = no support."  This WG LC also
|    includes a request for the authors to provide IPR = on the subject.
|
|
|
|    Please note: due to the European vacations in Augu= st, we are bundling
|    these three reviews into the next two weeks (these= two drafts and
|    draft-ietf-as-migration).   The chairs w= ould like feedback (list or
|    private email) whether the three WG LC s impact an= yone's ability to review
|    these drafts carefully.
|
|
|
|    Thank you,
|
|
|
|    Sue Hares and John Scudder
|
| References
|
|    Visible links
|    1. http://datatracker.ietf.org/doc/draft-ietf-idr-= ls-distribution/
|    2. http://datatracker.ietf.org/doc/draft-ietf-idr-= ls-distribution-impl/
 
| _______________________________________________
| Idr mailing list
| Idr@ietf.org
| https://www.ietf.org/mailman/listinfo/idr
 
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr
 
--_000_140964296721658954junipernet_-- From nobody Tue Sep 2 01:12:56 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 370371A011D for ; Tue, 2 Sep 2014 01:12:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.255 X-Spam-Level: X-Spam-Status: No, score=0.255 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbzNOIQeFknU for ; Tue, 2 Sep 2014 01:12:46 -0700 (PDT) Received: from cmccmta1.chinamobile.com (cmccmta1.chinamobile.com [221.176.66.79]) by ietfa.amsl.com (Postfix) with SMTP id 6DACF1A010F for ; Tue, 2 Sep 2014 01:12:41 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.121.1]) by rmmx-syy-dmz-app02-12002 (RichMail) with SMTP id 2ee254057bf7687-a76be; Tue, 02 Sep 2014 16:12:39 +0800 (CST) X-RM-TRANSID: 2ee254057bf7687-a76be X-RM-SPAM-FLAG: 00000000 Received: from lizhenqiang (unknown[10.2.52.185]) by rmsmtp-syy-appsvr01-12001 (RichMail) with SMTP id 2ee154057bf5ffc-aaa13; Tue, 02 Sep 2014 16:12:39 +0800 (CST) X-RM-TRANSID: 2ee154057bf5ffc-aaa13 Date: Tue, 2 Sep 2014 16:12:58 +0800 From: "lizhenqiang@chinamobile.com" To: "Hannes Gredler" , "Uma Chunduri" References: <025201cfc15c$bbe17260$33a45720$@ndzh.com>, <1B502206DFA0C544B7A60469152008633F364057@eusaamb105.ericsson.se>, <20140901180518.GA34789@juniper.net>, <2014090214443576954410@chinamobile.com>, <1409642967216.58954@juniper.net> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 5, 140[cn] Mime-Version: 1.0 Message-ID: <2014090216125846667724@chinamobile.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart538267056525_=----" Archived-At: http://mailarchive.ietf.org/arch/msg/idr/Jt6hgA04Gu8oW20Jg2ZLIqZoeNs Cc: 'idr wg' , Susan Hares , "'John G. Scudder'" Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-ietf-idr-ls-distribut-impl X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 08:12:49 -0000 This is a multi-part message in MIME format. ------=_001_NextPart538267056525_=---- Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 VGhhbmtzIEhhbm5lcywNCg0KVHdvIHR5cGVzIG9mIGxpbmsgc3RhdGUgTkxSSXMgYXJlIGRlZmlu ZWQgaW4gc2VjdGlvbiAzLjIgb2YgdGhpcyBkcmFmdCwgQUZJIDE2Mzg4IC8gU0FGSSA3MSBmb3Ig bm9uLVZQTiwgQUZJIDE2Mzg4IC8gU0FGSSAxMjggZm9yIFZQTi4NCk15IHF1ZXN0aW9uIGlzIGFi b3V0IEFGSSAxNjM4OCAvIFNBRkkgMTI4IE5MUkkuIEZyb20gdGhlIGZpZ3VyZSBpbiBwYWdlIDkg b2YgZHJhZnQgdmVyc2lvbiA1LCB3ZSBjYW4gc2VlIHRoYXQgUkQgaXMgcHV0IGJlZm9yZSBsaW5r IHN0YXRlIE5MUkkuIFRoZSBsaW5rIHN0YXRlIE5MUkkgZmllbGQgaW4gdGhpcyBmaWd1cmUgY29u dGFpbnMgdGhlIElQIHByZWZpeC4gQXMgUkZDNDM2NCBzcGVjaWZpZXMsIHRoZSBWUE4gcm91dGVz IHNob3VsZCBiZSBjYXJyaWVkIGluIHRoZSBOTFJJIHByZXBlbmRpbmcgd2l0aCBSRC4NCg0KDQoN CmxpemhlbnFpYW5nQGNoaW5hbW9iaWxlLmNvbQ0KIA0KRnJvbTogSGFubmVzIEdyZWRsZXINCkRh dGU6IDIwMTQtMDktMDIgMTU6MjkNClRvOiBsaXpoZW5xaWFuZ0BjaGluYW1vYmlsZS5jb207IFVt YSBDaHVuZHVyaQ0KQ0M6ICdpZHIgd2cnOyAnSm9obiBHLiBTY3VkZGVyJzsgU3VzYW4gSGFyZXMN ClN1YmplY3Q6IFJFOiBSZTogW0lkcl0gV0cgTEMgZm9yIGRyYWZ0LWlldGYtaWRyLWxzLWRpc3Ry aWJ1dGlvbiBhbmQgZHJhZnQtaWV0Zi1pZHItbHMtZGlzdHJpYnV0LWltcGwNCmhpIHpoZW5xaWFu ZywNCg0KVGhlIFJvdXRlLWRpc3Rpbmd1aXNoZXIncyBwdXJwb3NlIGlzIHRvIGFkZCA2NC1iaXRz IG9mICBkaXNhbWJpZ3VhdGluZyBlbnRyb3B5IHRvIHRoZSBOTFJJLCBzdWNoDQp0aGF0IHRoZSBy b3V0ZS1yZWZsZWN0b3JzIGRvIG5vdCAic3dhbGxvdyIgdGhhdCBwYXRoIGFzIHBhcnQgb2YgdGhl IGJlc3QtcGF0aCBlbGVjdGlvbg0KcHJvY2VkdXJlLiBUaGUgbGluay1zdGF0ZSBOTFJJIChlbmNh cHN1bGF0ZWQgaW4gTVBfUkVBQ0gvIE1QIFVOUkVBQ0ggUEEpDQppcyBhIFJELWxlc3MgdmVyc2lv biBvZiB0aGUgdnBuLWxpbmstc3RhdGUgTkxSSS4NCkluIGEgY2VydGFpbiB3YXkgdGhlc2UgY29y cmVzcG9uZCB0byBSRkMzMTA3IC8gUkZDNDM2NCBOTFJJIGZvcm1hdHMuDQpUaGUgZm9ybWVyIGlz IGEgUkQtbGVzcyB2ZXJzaW9uIG9mIHRoZSBsYXR0ZXIuDQoNCk9uIHlvdXIgcXVlc3Rpb24gIldo eSBkbyd0IHlvdSBwdXQgUkQgaW4gSVAgUmVhY2hhYmlsaXR5IEluZm9ybWF0aW9uLCBqdXN0IHBy ZXBlbmRpbmcgUkQgd2l0aCBJUCBwcmVmaXggYXMgUkZDNDM2NCBzcGVjaWZpZXMuIiAtIFRoaXMg aXMgYWN0dWFsbHkgd2hhdCB3ZSAqYXJlKiBkb2luZyAtIHdlIHB1dCB0aGUgUkQgYmVmb3JlIHRo ZSBsaW5rLXN0YXRlIE5MUkkgaW5zaWRlIHRoZSBNUF9SRUFDSC9NUF9VTlJFQUNIIEF0dHJpYnV0 ZS4NCg0KSFRILA0KDQovaGFubmVzDQoNCg0KDQpGcm9tOiBsaXpoZW5xaWFuZ0BjaGluYW1vYmls ZS5jb20gPGxpemhlbnFpYW5nQGNoaW5hbW9iaWxlLmNvbT4NClNlbnQ6IFR1ZXNkYXksIFNlcHRl bWJlciAwMiwgMjAxNCA4OjQ0DQpUbzogSGFubmVzIEdyZWRsZXI7IFVtYSBDaHVuZHVyaQ0KQ2M6 ICdpZHIgd2cnOyAnSm9obiBHLiBTY3VkZGVyJzsgU3VzYW4gSGFyZXMNClN1YmplY3Q6IFJlOiBS ZTogW0lkcl0gV0cgTEMgZm9yIGRyYWZ0LWlldGYtaWRyLWxzLWRpc3RyaWJ1dGlvbiBhbmQgZHJh ZnQtaWV0Zi1pZHItbHMtZGlzdHJpYnV0LWltcGwgDQogDQpPbmUgcXVlc3Rpb24gYWJvdXQgdGhl IFZQTiBMaW5rLVN0YXRlIE5MUkkgaW4gc2VjdGlvbiAzLjIuIFdoeSBkbyB5b3UgcHV0IHRoZSBS RCBiZWZvcmUgbGluayBzdGF0ZSBOUkxJPyBXaHkgZG8ndCB5b3UgcHV0IFJEIGluIElQIFJlYWNo YWJpbGl0eSBJbmZvcm1hdGlvbiwganVzdCBwcmVwcmVuZGluZyBSRCB3aXRoIElQIHByZWZpeCBh cyBSRkM0MzY0IHNwZWNpZmllcy4NCg0KDQoNCg0KbGl6aGVucWlhbmdAY2hpbmFtb2JpbGUuY29t DQogDQpGcm9tOiBIYW5uZXMgR3JlZGxlcg0KRGF0ZTogMjAxNC0wOS0wMiAwMjowNQ0KVG86IFVt YSBDaHVuZHVyaQ0KQ0M6IGlkckBpZXRmLm9yZzsgJ0pvaG4gRy4gU2N1ZGRlcic7IFN1c2FuIEhh cmVzDQpTdWJqZWN0OiBSZTogW0lkcl0gV0cgTEMgZm9yIGRyYWZ0LWlldGYtaWRyLWxzLWRpc3Ry aWJ1dGlvbiBhbmQgZHJhZnQtaWV0Zi1pZHItbHMtZGlzdHJpYnV0LWltcGwNCmhpIHVtYSwNCiAN CnNlZSBjb21tZW50cy9yZXNwb25zZXMgaW5saW5lOg0KIA0KT24gV2VkLCBBdWcgMjcsIDIwMTQg YXQgMTE6MDc6MDFBTSArMDAwMCwgVW1hIENodW5kdXJpIHdyb3RlOg0KfCAgICBTdXBwb3J0Lg0K fCANCnwgICAgSSBzZWUsIGhpZXJhcmNoeSBpcyBXRUxMICBkZWZpbmVkIHdoZW4gbXVsdGlwbGUg aW5zdGFuY2VzIG9mIElHUCB3aXRoDQp8ICAgIG11bHRpcGxlIEFGcyBhcmUgcnVubmluZy4gR29v ZCB3b3JrLg0KfCANCnwgDQp8IA0KfCAgICBIYXZlIGZvbGxvd2luZyBRczoNCnwgDQp8ICAgIDEu ICAgICAgIEFueSBkaXNjdXNzaW9uIG9mIHRoZSBkZWxheSBpbnRyb2R1Y2VkIGJ5IEJHUCAocGFj a2luZywgdXBkYXRlDQp8ICAgIGdlbmVyYXRpb24sIHByb2Nlc3NpbmcgZXRjLi4pIHRvIHRyYW5z cG9ydCB0aGUgTFMgaW5mb3JtYXRpb24NCnwgDQp8ICAgIGVzcGVjaWFsbHksIHdoZW4gTFNEQiBp cyBjaGFuZ2luZyBmYXN0ZXIgcGVyaGFwcyB3aXRoIGxhcmdlIG51bWJlciBvZg0KfCAgICBub2Rl cy9saW5rcyBpbnNpZGUgYW4gQVMgYW5kIHdpdGggbXVsdGlwbGUgQVNlcykgdG8gdGhlIGNvbnRy b2xsZXIgd2lsbCBiZQ0KfCAgICB1c2VmdWwuDQogDQp0aGlzIGlzIGhpZ2hseSBpbXBsZW1lbnRh dGlvbiBkZXBlbmRlbnQ7IC0gDQpzb21lIHZlbmRvcnMgZG8gdGhlIHBhY2thZ2luZyBvZiBCR1Ag dXBkYXRlcyBlbnRpcmVseSBldmVudC1kcml2ZW4NCmFuZCBvdGhlcnMgcGFjayB0aGluZ3MgdXAg YW5kIGhhdmUgYSB3b3JzdCBjYXNlIGRlbGF5IGJldHdlZW4NCnRoZSB0cmlnZ2VyIGV2ZW50IGFu ZCB0aGUgQkdQIHVwZGF0ZS4gdGhlIHByb3RvY29sDQppdHNlbGYgZG9lcyBub3QgcHJvaGliaXQv bGltaXQgdGhlIHByb3BhZ2F0aW9uIHNwZWVkLg0KKGluIGZhY3QgaXQgY2FuIGJlIHNob3duIHRo YXQgc29tZXRpbWVzIHVwZGF0ZXMNCnRyYXZlbCBmYXN0ZXIgb24gdGhlIChkYXRhcGxhbmUgZm9y d2FyZGVkKSBpQkdQIG1lc2gsDQpyYXRoZXIgdGhhbiBwcm9wZ2F0ZSB1c2luZyB0aGUgaG9wLWJ5 LWhvcCBjb250cm9sLXBsYW5lIGZsb29kaW5nDQpwcm90b2NvbCkNCiANCnwgICAgICAgICAgICAg ICAgIEEgbm90ZSBvbiB0aGUgc2Vuc2l0aXZpdHkgb2YgdGhpcyBkZWxheSB0byB0aGUgY29uc3Vt ZXINCnwgICAgKGFwcGxpY2F0aW9ucykgYXQgdGhlIGNvbnRyb2xsZXIgIGNhbiBiZSBoZWxwZnVs LiBJIHNhdyB2ZXJ5IGxpdHRsZQ0KfCAgICBkaXNjdXNzaW9uIGluIFNlY3Rpb24gNiAoNi4xLjUp DQogDQpkaWZmaWNpdWx0IC0gaXRzIGhhcmQgdG8gaGF2ZSBzb21lIHNvcnQgb2YgZ2VuZXJhbCBj b21tZW50IGFzIHRoaW5ncyBhcmUNCmhpZ2hseSBpbXBsZW1lbnRhdGlvbiBkZXBlbmRlbnQuDQog DQogDQp8ICAgIDIuICAgICAgIFRoaXMgZG9jdW1lbnQgZW5jb21wYXNzZXMgcHJldHR5IG11Y2gg Ym90aCBPU1BGIGFuZCBJU0lTDQp8ICAgIGV4dGVuc2lvbnMgZG9uZSB0aWxsIGRhdGUuIEhvdyBp dCB3aWxsIGtlZXAgdXAgd2l0aCBmdXR1cmUgZXh0ZW5zaW9ucyBpbg0KfCAgICBPU1BGL0lTSVMu DQogDQp3ZSBoYXZlIHNldCB1cCBhbiBJQU5BIHJlZ2lzdHJpZXMgZm9yIHRoZSBjYXJyaWVycyBv ZiBpbmZvcm1hdGlvbi4NCml0IGlzIGV4cGVjdGVkIGJ5IGF1dGhvcnMgb2YgInRvcG9sb2dpY2Fs IHJlbGV2YW50IiBJR1AgZXh0ZW5zaW9ucw0KdG8gc3VwcGx5IGFsc28gQkdQLUxTIGV4dGVuc2lv bnMuDQogDQp8ICAgIEEgbWVjaGFuaXNtIGluIHBsYWNlIHdvdWxkIGJlIGhlbHBmdWwuIE15IHN1 Z2dlc3Rpb24gd291bGQgYmUtICB0aGUNCnwgICAgcmVzcGVjdGl2ZSBJR1AgZG9jdW1lbnRzIHNo b3VsZCBhc3Nlc3MgdGhlIGltcGFjdCBhbmQgZGVmaW5lDQp8IA0KfCAgICBjb3JyZXNwb25kaW5n IG5ldyBUTFZzIGZvciBCR1AgTFM/IEJ1dCBob3cgdGhpcyBjYW4gYmUgZW5mb3JjZWQ/DQogDQpp IGhhdmUgbm8gaWRlYSAtIHRvZGF5IGl0cyBlbnRpcmVseSB2b2x1bnRhcnkuDQogDQp8ICAgIDMu ICAgICAgIFNlY3Rpb24gNCwgZ2l2ZXMgZ2xpbXBzZSB3aGF0J3MgcG9zc2libGUgYW5kIHRoZSBu b2RlIGFnZ3JlZ2F0aW5nDQp8ICAgIHRoZSBsaW5rcyBvYnZpb3VzbHkgbmVlZCB0byB0aW5rZXIg dGhlIExTREIgdG8gcmVwcmVzZW50IHRoZSBzYW1lDQp8ICAgIGNvcnJlY3RseS4NCnwgDQp8ICAg IFNvbWUgbW9yZSBkZXRhaWxzIHdvdWxkIGJlIGhlbHBmdWwgdG8gcmVwcmVzZW50IHRoZSBjaGFu Z2VzIG9uDQp8ICAgIGFnZ3JlZ2F0aW9uL2RlLWFnZ3JlZ2F0aW9uIHN1YnNlcXVlbnRseS4NCiAN CnRoaXMgbWF5IHF1aWNrbHkgZ2V0IHlvdSBpbnRvIHRoZSAiYWJzdHJhY3RlZCB0b3BvbG9neSBt b2RlbHMiDQpkaXNjdXNzaW9uIHRoYXQga2VlcHMgZW1lcmdpbmcgIHBlcmlvZGljYWxseS4gLQ0K d2UgZGlkIG5vdCB3YW50IHRvIHN0b3AgcHJvZ3Jlc3Mgb24gdGhlIHByb3RvY29sIGJ5IGFyZ3Vp bmcNCiJ3aGF0cyB0aGUgcmlnaHQgYWJzdHJhY3Rpb24gbW9kZWwiIGFuZCBoYXZlIGFncmVlZA0K b24gdGhlIG1pbmltYWxpc3RpYyBuYXR1cmUgb2YgdGhlIHNlY3Rpb24gYXMtaXMuDQogDQogDQp8 ICAgIDQuICAgICAgIFNlY3Rpb24gNi4yIGhhcyBlbXB0eSBzdWItc2VjdGlvbnMgYW5kIFRCRHMu DQogDQpyaWdodCAuLi4gc28gc3VnZ2VzdCB0byByZW1vdmUgc2VjdGlvbiA2LjIgYWx0b2dldGhl ci4NCiANCnwgICAgNS4gICAgICAgSXQncyBnb29kIHRvIHNlZSBJbXBsZW1lbnRhdGlvbiByZXBv cnQgc2hlZCBsaWdodCBvbiBwZXJmb3JtYW5jZQ0KfCAgICBzZWVuIHdpdGggbXVsdGlwbGUgQVNl cy4NCnwgDQp8ICAgIDYuICAgICAgIEl0J3MgZ29vZCB0byBzZWUgaWYgYW55IGFwcGxpY2F0aW9u IG9mIHBvbGljeSBvbiBMU0RCIGlzIGRvbmUNCnwgICAgKG9uZSBvZiB0aGUgcHJpbWFyeSBkcml2 ZXJzIG9mIHRoZSBzcGVjaWZpY2F0aW9uKS4NCiANCiANCnRoYW5rcywNCiANCiANCi9oYW5uZXMN CiANCnwgDQp8ICAgIEZyb206IElkciBbbWFpbHRvOmlkci1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgU3VzYW4gSGFyZXMNCnwgICAgU2VudDogVHVlc2RheSwgQXVndXN0IDI2LCAyMDE0 IDExOjM3IEFNDQp8ICAgIFRvOiBpZHJAaWV0Zi5vcmcNCnwgICAgQ2M6ICdKb2huIEcuIFNjdWRk ZXInOyBzaGFyZXNAbmR6aC5jb20NCnwgICAgU3ViamVjdDogW0lkcl0gV0cgTEMgZm9yIGRyYWZ0 LWlldGYtaWRyLWxzLWRpc3RyaWJ1dGlvbiBhbmQNCnwgICAgZHJhZnQtaWV0Zi1pZHItbHMtZGlz dHJpYnV0LWltcGwNCnwgDQp8IA0KfCANCnwgICAgVGhpcyBpcyBhIFdHIExDIGZvcg0KfCANCnwg DQp8IA0KfCAgICAgIFsxXWh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0 Zi1pZHItbHMtZGlzdHJpYnV0aW9uLw0KfCANCnwgICAgICBbMl1odHRwOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaWRyLWxzLWRpc3RyaWJ1dGlvbi1pbXBsLw0KfCANCnwg DQp8IA0KfCAgICBQbGVhc2UgcmVzcG9uZCB3aXRoIGNvbW1lbnRzIGFuZCAic3VwcG9ydCBvciBu byBzdXBwb3J0LiIgIFRoaXMgV0cgTEMgYWxzbw0KfCAgICBpbmNsdWRlcyBhIHJlcXVlc3QgZm9y IHRoZSBhdXRob3JzIHRvIHByb3ZpZGUgSVBSIG9uIHRoZSBzdWJqZWN0Lg0KfCANCnwgDQp8IA0K fCAgICBQbGVhc2Ugbm90ZTogZHVlIHRvIHRoZSBFdXJvcGVhbiB2YWNhdGlvbnMgaW4gQXVndXN0 LCB3ZSBhcmUgYnVuZGxpbmcNCnwgICAgdGhlc2UgdGhyZWUgcmV2aWV3cyBpbnRvIHRoZSBuZXh0 IHR3byB3ZWVrcyAodGhlc2UgdHdvIGRyYWZ0cyBhbmQNCnwgICAgZHJhZnQtaWV0Zi1hcy1taWdy YXRpb24pLiAgIFRoZSBjaGFpcnMgd291bGQgbGlrZSBmZWVkYmFjayAobGlzdCBvcg0KfCAgICBw cml2YXRlIGVtYWlsKSB3aGV0aGVyIHRoZSB0aHJlZSBXRyBMQyBzIGltcGFjdCBhbnlvbmUncyBh YmlsaXR5IHRvIHJldmlldw0KfCAgICB0aGVzZSBkcmFmdHMgY2FyZWZ1bGx5Lg0KfCANCnwgDQp8 IA0KfCAgICBUaGFuayB5b3UsDQp8IA0KfCANCnwgDQp8ICAgIFN1ZSBIYXJlcyBhbmQgSm9obiBT Y3VkZGVyDQp8IA0KfCBSZWZlcmVuY2VzDQp8IA0KfCAgICBWaXNpYmxlIGxpbmtzDQp8ICAgIDEu IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pZHItbHMtZGlzdHJp YnV0aW9uLw0KfCAgICAyLiBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll dGYtaWRyLWxzLWRpc3RyaWJ1dGlvbi1pbXBsLw0KIA0KfCBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KfCBJZHIgbWFpbGluZyBsaXN0DQp8IElkckBpZXRm Lm9yZw0KfCBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkcg0KIA0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklkciBtYWlsaW5n IGxpc3QNCklkckBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9pZHINCiANCg== ------=_001_NextPart538267056525_=---- Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =0A
= Thanks Hannes,

Two types of link state NLR= Is are defined in section 3.2 of this draft, AFI 16388= / SAFI 71 for non-VPN, AFI 16388 / SAFI 128 fo= r VPN.
My question is about AFI 16388 / SAFI 12= 8 NLRI. From the figure in page 9 of draft version 5, we can see that RD i= s put before link state NLRI. The link state NLRI field i= n this figure contains the IP prefix. As RFC4364 specifies, = the VPN routes should be carried in the NLRI prepending with RD.=0A

=0A
=0A
lizhenqiang@chinamobile.com
=0A
 
Date: 2014-09-02 15:29
Subject: RE: Re: [Idr] WG LC for dr= aft-ietf-idr-ls-distribution and draft-ietf-idr-ls-distribut-impl
=0A

hi zhenqiang,
=0A

=0A


=0A

=0A

The Route-distinguisher's purpose is to add 64= -bits of  disambiguating entropy to the NLRI, such
=0A

=0A=

that the route-reflector= s do not "swallow" that path as part of the best-path election
=0A

= =0A

procedure. The link-s= tate NLRI (encapsulated in MP_REACH/ MP UNREACH PA)

=0A

is a RD-less version of the vpn-lin= k-state NLRI.

=0A

In a certain way these corr= espond to R= FC3107 / RFC4364 NLRI formats.

=0A

The former is a RD-= less version of the latter.

=0A


= =0A

=0A

On your question "Why do't you put RD in IP=0A Reacha= bility Information, just prepending RD with IP prefix as RFC4364 specifies= ." - This is actually what we *are* doing - we put the RD befo= re the link-state NLRI inside the MP_REACH/MP_UNREACH Attribute.=0A


=0A

=0A

HTH,
=0A

=0A


=0A

=0A

/hannes
=0A

=0A


=0A

=0A

=0A
=0A
=0A
From: lizhenqiang@chinamobile.com <lizhen= qiang@chinamobile.com>
=0ASent: Tuesday, September 02, 2014 8= :44
=0ATo: Hannes Gredler; Uma Chunduri
=0ACc: 'idr wg= '; 'John G. Scudder'; Susan Hares
=0ASubject: Re: Re: [Idr] WG L= C for draft-ietf-idr-ls-distribution and draft-ietf-idr-ls-distribut-impl<= /font>=0A
 
=0A
=0A
=0A
One question about the = VPN Link-State NLRI= in section 3.2. Why do you put the RD before link state NRLI? Why do't yo= u put RD in = IP Reachability Information,=0A just preprending RD with IP prefix as RFC4= 364 specifies.
=0A

=0A
=0A

=0A
=0A
=0A
=0A
=0A
lizhenqia= ng@chinamobile.com
=0A
=0A
=0A
=0A
 =0A= =0A
=0A
hi uma,
=0A
 
=0A
see comments/resp= onses inline:
=0A
 
=0A
On Wed, Aug 27, 2014 at 11:= 07:01AM +0000, Uma Chunduri wrote:
=0A
|    Suppor= t.
=0A
|
=0A
|    I see, hierarchy is WE= LL  defined when multiple instances of IGP with
=0A
| &= nbsp;  multiple AFs are running. Good work.
=0A
|
=0A<= div>|
=0A
|
=0A
|    Have following Qs:=
=0A
|
=0A
|    1.   &nbs= p;   Any discussion of the delay introduced by BGP (packing, upd= ate
=0A
|    generation, processing etc..) to tran= sport the LS information
=0A
|
=0A
|    = especially, when LSDB is changing faster perhaps with large number of=0A
|    nodes/links inside an AS and with multiple AS= es) to the controller will be
=0A
|    useful.=0A
 
=0A
this is highly implementation dependent; - <= /div>=0A
some vendors do the packaging of BGP updates entirely event-d= riven
=0A
and others pack things up and have a worst case delay b= etween
=0A
the trigger event and the BGP update. the protocol=0A
itself does not prohibit/limit the propagation speed.
=0A(in fact it can be shown that sometimes updates
=0A
travel fas= ter on the (dataplane forwarded) iBGP mesh,
=0A
rather than propg= ate using the hop-by-hop control-plane flooding
=0A
protocol)=0A
 
=0A
|       &= nbsp;         A note on the sensit= ivity of this delay to the consumer
=0A
|    (appl= ications) at the controller  can be helpful. I saw very little
= =0A
|    discussion in Section 6 (6.1.5)
=0A
&= nbsp;
=0A
difficiult - its hard to have some sort of general comm= ent as things are
=0A
highly implementation dependent.
=0A 
=0A
 
=0A
|    2. &nb= sp;     This document encompasses pretty much both OSP= F and ISIS
=0A
|    extensions done till date. How= it will keep up with future extensions in
=0A
|   = ; OSPF/ISIS.
=0A
 
=0A
we have set up an IANA regis= tries for the carriers of information.
=0A
it is expected by auth= ors of "topological relevant" IGP extensions
=0A
to supply also B= GP-LS extensions.
=0A
 
=0A
|    A m= echanism in place would be helpful. My suggestion would be-  the=0A
|    respective IGP documents should assess the im= pact and define
=0A
|
=0A
|    correspon= ding new TLVs for BGP LS? But how this can be enforced?
=0A
 = ;
=0A
i have no idea - today its entirely voluntary.
=0A 
=0A
|    3.     &= nbsp; Section 4, gives glimpse what's possible and the node aggregating=0A
|    the links obviously need to tinker the LSDB= to represent the same
=0A
|    correctly.
= =0A
|
=0A
|    Some more details would be hel= pful to represent the changes on
=0A
|    aggregat= ion/de-aggregation subsequently.
=0A
 
=0A
this may= quickly get you into the "abstracted topology models"
=0A
discus= sion that keeps emerging  periodically. -
=0A
we did not wan= t to stop progress on the protocol by arguing
=0A
"whats the righ= t abstraction model" and have agreed
=0A
on the minimalistic natu= re of the section as-is.
=0A
 
=0A
 
=0A<= div>|    4.       Section 6.2= has empty sub-sections and TBDs.
=0A
 
=0A
right .= .. so suggest to remove section 6.2 altogether.
=0A
 
= =0A
|    5.       It's go= od to see Implementation report shed light on performance
=0A
|&n= bsp;   seen with multiple ASes.
=0A
|
=0A
|&n= bsp;   6.       It's good to see i= f any application of policy on LSDB is done
=0A
|  &nbs= p; (one of the primary drivers of the specification).
=0A
 <= /div>=0A
 
=0A
thanks,
=0A
 
=0A
=  
=0A
/hannes
=0A
 
=0A
|
=0A|    From: Idr [mailto:idr-bounces@ietf.org] On Behalf O= f Susan Hares
=0A
|    Sent: Tuesday, August 26, 2= 014 11:37 AM
=0A
|    To: idr@ietf.org
=0A|    Cc: 'John G. Scudder'; shares@ndzh.com
=0A
= |    Subject: [Idr] WG LC for draft-ietf-idr-ls-distributio= n and
=0A
|    draft-ietf-idr-ls-distribut-impl=0A
|
=0A
|
=0A
|
=0A
|  &n= bsp; This is a WG LC for
=0A
|
=0A
|
=0A
| =0A
|      [1]http://datatracker.ietf.org= /doc/draft-ietf-idr-ls-distribution/
=0A
|
=0A
| &= nbsp;    [2]http://datatracker.ietf.org/doc/draft-ietf-idr-= ls-distribution-impl/
=0A
|
=0A
|
=0A
| =0A
|    Please respond with comments and "support or = no support."  This WG LC also
=0A
|    includ= es a request for the authors to provide IPR on the subject.
=0A
|=
=0A
|
=0A
|
=0A
|    Please = note: due to the European vacations in August, we are bundling
=0A|    these three reviews into the next two weeks (these t= wo drafts and
=0A
|    draft-ietf-as-migration).&n= bsp;  The chairs would like feedback (list or
=0A
| &nb= sp;  private email) whether the three WG LC s impact anyone's ability= to review
=0A
|    these drafts carefully.
= =0A
|
=0A
|
=0A
|
=0A
|   = ; Thank you,
=0A
|
=0A
|
=0A
|
=0A
= |    Sue Hares and John Scudder
=0A
|
=0A| References
=0A
|
=0A
|    Visible li= nks
=0A
|    1. http://datatracker.ietf.org/doc/dr= aft-ietf-idr-ls-distribution/
=0A
|    2. http://d= atatracker.ietf.org/doc/draft-ietf-idr-ls-distribution-impl/
=0A
=  
=0A
| _______________________________________________=0A
| Idr mailing list
=0A
| Idr@ietf.org
=0A
| htt= ps://www.ietf.org/mailman/listinfo/idr
=0A
 
=0A
__= _____________________________________________
=0A
Idr mailing lis= t
=0A
Idr@ietf.org
=0A
https://www.ietf.org/mailman/list= info/idr
=0A
 
=0A
=0A
=0A
=0A=0A
=0A ------=_001_NextPart538267056525_=------ From nobody Tue Sep 2 01:35:53 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E60D1A0175 for ; Tue, 2 Sep 2014 01:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nTZZtgWzKOAu for ; Tue, 2 Sep 2014 01:35:49 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0212.outbound.protection.outlook.com [207.46.163.212]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E08261A013B for ; Tue, 2 Sep 2014 01:35:48 -0700 (PDT) Received: from CO1PR05MB443.namprd05.prod.outlook.com (10.141.73.152) by CO1PR05MB281.namprd05.prod.outlook.com (10.141.70.155) with Microsoft SMTP Server (TLS) id 15.0.1015.19; Tue, 2 Sep 2014 08:35:47 +0000 Received: from hannes-mba.local (193.110.55.13) by CO1PR05MB443.namprd05.prod.outlook.com (10.141.73.152) with Microsoft SMTP Server (TLS) id 15.0.1019.16; Tue, 2 Sep 2014 08:35:45 +0000 Received: from juniper.net (localhost [IPv6:::1]) by hannes-mba.local (Postfix) with ESMTP id 76E782A70DB; Tue, 2 Sep 2014 10:35:27 +0200 (CEST) Date: Tue, 2 Sep 2014 10:35:27 +0200 From: Hannes Gredler To: "lizhenqiang@chinamobile.com" Message-ID: <20140902083527.GC39341@juniper.net> References: <025201cfc15c$bbe17260$33a45720$@ndzh.com> <1B502206DFA0C544B7A60469152008633F364057@eusaamb105.ericsson.se> <20140901180518.GA34789@juniper.net> <2014090214443576954410@chinamobile.com> <1409642967216.58954@juniper.net> <2014090216125846667724@chinamobile.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <2014090216125846667724@chinamobile.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Originating-IP: [193.110.55.13] X-ClientProxiedBy: DB4PR04CA0007.eurprd04.prod.outlook.com (25.160.41.17) To CO1PR05MB443.namprd05.prod.outlook.com (10.141.73.152) X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;UriScan:;UriScan:; X-Forefront-PRVS: 0322B4EDE1 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(24454002)(189002)(199003)(377424004)(377454003)(105586002)(74502001)(23726002)(106356001)(4396001)(2501002)(77982001)(76506005)(77096002)(31966008)(74662001)(86362001)(2351001)(87976001)(46406003)(102836001)(46102001)(33656002)(95666004)(107046002)(230783001)(92726001)(50466002)(15975445006)(15202345003)(47776003)(50986999)(21056001)(85306004)(54356999)(76176999)(93886004)(83506001)(83322001)(80022001)(76482001)(101416001)(92566001)(19580395003)(110136001)(19580405001)(81542001)(97756001)(83072002)(85852003)(90102001)(99396002)(64706001)(20776003)(66066001)(36756003)(81342001)(579124003); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB443; H:hannes-mba.local; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/idr/wkwU_cT6x7-D7RC-LpQr6kr5LG8 Cc: 'idr wg' , Susan Hares , "'John G. Scudder'" Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-ietf-idr-ls-distribut-impl X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 08:35:51 -0000 hi zhenqiang, On Tue, Sep 02, 2014 at 04:12:58PM +0800, lizhenqiang@chinamobile.com wrote: | Two types of link state NLRIs are defined in section 3.2 of this | draft, AFI 16388 / SAFI 71 for non-VPN, AFI 16388 / SAFI 128 for VPN. correct; | My question is about AFI 16388 / SAFI 128 NLRI. From the figure in page 9 | of draft version 5, we can see that RD is put before link state NLRI. from http://tools.ietf.org/html/draft-ietf-idr-ls-distribution-05#section-3.2 this is the NLRI format for AFI 16388 / SAFI 71 (unicast) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NLRI Type | Total NLRI Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Link-State NLRI (variable) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ and this is the NLRI format for AFI 16388 / SAFI 128 (VPN-unicast) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NLRI Type | Total NLRI Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Route Distinguisher + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Link-State NLRI (variable) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | The link state NLRI field in this figure contains the IP prefix. As RFC4364 | specifies, the VPN routes should be carried in the NLRI prepending with | RD. that is what we do - i fail to see the offending part with respect to RFC4364. /hannes | | From: [1]Hannes Gredler | Date: 2014-09-02 15:29 | To: [2]lizhenqiang@chinamobile.com; [3]Uma Chunduri | CC: [4]'idr wg'; [5]'John G. Scudder'; [6]Susan Hares | Subject: RE: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and | draft-ietf-idr-ls-distribut-impl | | hi zhenqiang, | | The Route-distinguisher's purpose is to add 64-bits of disambiguating | entropy to the NLRI, such | | that the route-reflectors do not "swallow" that path as part of the | best-path election | | procedure. The link-state NLRI (encapsulated in MP_REACH/ MP UNREACH PA) | | is a RD-less version of the vpn-link-state NLRI. | | In a certain way these correspond to RFC3107 / RFC4364 NLRI formats. | | The former is a RD-less version of the latter. | | On your question "Why do't you put RD in IP Reachability Information, | just prepending RD with IP prefix as RFC4364 specifies." - This is | actually what we *are* doing - we put the RD before the link-state NLRI | inside the MP_REACH/MP_UNREACH Attribute. | | HTH, | | /hannes | | -------------------------------------------------------------------------- | | From: lizhenqiang@chinamobile.com | Sent: Tuesday, September 02, 2014 8:44 | To: Hannes Gredler; Uma Chunduri | Cc: 'idr wg'; 'John G. Scudder'; Susan Hares | Subject: Re: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and | draft-ietf-idr-ls-distribut-impl | | One question about the VPN Link-State NLRI in section 3.2. Why do you | put the RD before link state NRLI? Why do't you put RD in IP | Reachability Information, just preprending RD with IP prefix as RFC4364 | specifies. | | -------------------------------------------------------------------------- | | lizhenqiang@chinamobile.com | | | From: [7]Hannes Gredler | Date: 2014-09-02 02:05 | To: [8]Uma Chunduri | CC: [9]idr@ietf.org; [10]'John G. Scudder'; [11]Susan Hares | Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and | draft-ietf-idr-ls-distribut-impl | hi uma, | | see comments/responses inline: | | On Wed, Aug 27, 2014 at 11:07:01AM +0000, Uma Chunduri wrote: | | Support. | | | | I see, hierarchy is WELL defined when multiple instances of IGP | with | | multiple AFs are running. Good work. | | | | | | | | Have following Qs: | | | | 1. Any discussion of the delay introduced by BGP (packing, | update | | generation, processing etc..) to transport the LS information | | | | especially, when LSDB is changing faster perhaps with large | number of | | nodes/links inside an AS and with multiple ASes) to the | controller will be | | useful. | | this is highly implementation dependent; - | some vendors do the packaging of BGP updates entirely event-driven | and others pack things up and have a worst case delay between | the trigger event and the BGP update. the protocol | itself does not prohibit/limit the propagation speed. | (in fact it can be shown that sometimes updates | travel faster on the (dataplane forwarded) iBGP mesh, | rather than propgate using the hop-by-hop control-plane flooding | protocol) | | | A note on the sensitivity of this delay to the | consumer | | (applications) at the controller can be helpful. I saw very | little | | discussion in Section 6 (6.1.5) | | difficiult - its hard to have some sort of general comment as things | are | highly implementation dependent. | | | | 2. This document encompasses pretty much both OSPF and ISIS | | extensions done till date. How it will keep up with future | extensions in | | OSPF/ISIS. | | we have set up an IANA registries for the carriers of information. | it is expected by authors of "topological relevant" IGP extensions | to supply also BGP-LS extensions. | | | A mechanism in place would be helpful. My suggestion would be- | the | | respective IGP documents should assess the impact and define | | | | corresponding new TLVs for BGP LS? But how this can be enforced? | | i have no idea - today its entirely voluntary. | | | 3. Section 4, gives glimpse what's possible and the node | aggregating | | the links obviously need to tinker the LSDB to represent the same | | correctly. | | | | Some more details would be helpful to represent the changes on | | aggregation/de-aggregation subsequently. | | this may quickly get you into the "abstracted topology models" | discussion that keeps emerging periodically. - | we did not want to stop progress on the protocol by arguing | "whats the right abstraction model" and have agreed | on the minimalistic nature of the section as-is. | | | | 4. Section 6.2 has empty sub-sections and TBDs. | | right ... so suggest to remove section 6.2 altogether. | | | 5. It's good to see Implementation report shed light on | performance | | seen with multiple ASes. | | | | 6. It's good to see if any application of policy on LSDB is | done | | (one of the primary drivers of the specification). | | | thanks, | | | /hannes | | | | | From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares | | Sent: Tuesday, August 26, 2014 11:37 AM | | To: idr@ietf.org | | Cc: 'John G. Scudder'; shares@ndzh.com | | Subject: [Idr] WG LC for draft-ietf-idr-ls-distribution and | | draft-ietf-idr-ls-distribut-impl | | | | | | | | This is a WG LC for | | | | | | | | | [1]http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/ | | | | | [2]http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution-impl/ | | | | | | | | Please respond with comments and "support or no support." This | WG LC also | | includes a request for the authors to provide IPR on the subject. | | | | | | | | Please note: due to the European vacations in August, we are | bundling | | these three reviews into the next two weeks (these two drafts and | | draft-ietf-as-migration). The chairs would like feedback (list | or | | private email) whether the three WG LC s impact anyone's ability | to review | | these drafts carefully. | | | | | | | | Thank you, | | | | | | | | Sue Hares and John Scudder | | | | References | | | | Visible links | | 1. | http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/ | | 2. | http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution-impl/ | | | _______________________________________________ | | Idr mailing list | | Idr@ietf.org | | https://www.ietf.org/mailman/listinfo/idr | | _______________________________________________ | Idr mailing list | Idr@ietf.org | https://www.ietf.org/mailman/listinfo/idr | | | References | | Visible links | 1. mailto:hannes@juniper.net | 2. mailto:lizhenqiang@chinamobile.com | 3. mailto:uma.chunduri@ericsson.com | 4. mailto:idr@ietf.org | 5. mailto:jgs@bgp.nu | 6. mailto:shares@ndzh.com | 7. mailto:hannes@juniper.net | 8. mailto:uma.chunduri@ericsson.com | 9. mailto:idr@ietf.org | 10. mailto:jgs@bgp.nu | 11. mailto:shares@ndzh.com From nobody Tue Sep 2 04:21:14 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B17C1A0196 for ; Tue, 2 Sep 2014 04:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.254 X-Spam-Level: X-Spam-Status: No, score=0.254 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-VR6AwJ6IIZ for ; Tue, 2 Sep 2014 04:21:07 -0700 (PDT) Received: from cmccmta1.chinamobile.com (cmccmta1.chinamobile.com [221.176.66.79]) by ietfa.amsl.com (Postfix) with SMTP id 183AC1A0164 for ; Tue, 2 Sep 2014 04:21:05 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.121.19]) by rmmx-syy-dmz-app03-12003 (RichMail) with SMTP id 2ee35405a820f8c-650e9; Tue, 02 Sep 2014 19:21:04 +0800 (CST) X-RM-TRANSID: 2ee35405a820f8c-650e9 X-RM-SPAM-FLAG: 00000000 Received: from lizhenqiang (unknown[183.244.251.195]) by rmsmtp-syy-appsvr10-12010 (RichMail) with SMTP id 2eea5405a81e3df-a89f5; Tue, 02 Sep 2014 19:21:04 +0800 (CST) X-RM-TRANSID: 2eea5405a81e3df-a89f5 Date: Tue, 2 Sep 2014 19:21:24 +0800 From: "lizhenqiang@chinamobile.com" To: "Hannes Gredler" References: <025201cfc15c$bbe17260$33a45720$@ndzh.com>, <1B502206DFA0C544B7A60469152008633F364057@eusaamb105.ericsson.se>, <20140901180518.GA34789@juniper.net>, <2014090214443576954410@chinamobile.com>, <1409642967216.58954@juniper.net>, <2014090216125846667724@chinamobile.com>, <20140902083527.GC39341@juniper.net> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 5, 140[cn] Mime-Version: 1.0 Message-ID: <2014090219212399332244@chinamobile.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart360370131358_=----" Archived-At: http://mailarchive.ietf.org/arch/msg/idr/sM52NbabtmF3UB9GrcC9ejYrkP8 Cc: 'idr wg' , Susan Hares , "'John G. Scudder'" Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-ietf-idr-ls-distribut-impl X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 11:21:11 -0000 This is a multi-part message in MIME format. ------=_001_NextPart360370131358_=---- Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 SGkgSGFubmVzLA0KDQpPbmUgZXhhbXBsZSB0byBleHBsYWluIHRoZSBkaWZmZXJlbmNlcy4gT25l IFZQTiByb3V0ZSB3aXRoIHByZWZpeCBsZW5ndGggMjQgaXMgY2FycmllZCBpbiB0aGUgTlJMSS4N Cg0KVGhlIGZvcm1hdCB0aGlzIGRyYWZ0IHNwZWNpZmllZCBpcyBhcyBmb2xsb3dzLg0KKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSsNCiB8ICAgICAgICAgICAgTkxSSSBUeXBlID0gMyAgICAgICAgIHwgICAgIFRvdGFsIE5MUkkg TGVuZ3RoICAgICAgICAgfA0KKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiB8ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KKyAgICAgICAgICAgICAgICAg ICAgICAgUm91dGUgRGlzdGluZ3Vpc2hlciAgICAgICAgICAgICAgICAgICAgICsNCiB8ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg fA0KKy0rLSstKy0rLSstKy0rLSsgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSsNCnwgUHJvdG9jb2wtSUQgfCANCistKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rIA0KfCBJZGVudGlmaWVyIHwgDQp8ICg2 NCBiaXRzKSB8IA0KKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSsgDQovLyBMb2NhbCBOb2RlIERlc2NyaXB0b3IgKHZhcmlhYmxl KSAvLyANCistKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rIA0KfCBUeXBlID0gMjY1ICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwgTGVuZ3RoIHwgDQorLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKyANCnwgUHJlZml4IExlbmd0aCA9IDI0IHwgSVAgUHJlZml4 ICh2YXJpYWJsZSkgLy8gDQorLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KDQoNClRoZSBmb3JtYXQgUkZDNDM2MyBzcGVjaWZp ZWQgaXMgYXMgZm9sbG93cy4NCistLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0rIA0KfCBBZGRyZXNzIEZhbWlseSBJZGVudGlmaWVyICgyIG9j dGV0cykgfCANCistLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0rIA0KfCBTdWJzZXF1ZW50IEFkZHJlc3MgRmFtaWx5IElkZW50aWZpZXIgKDEg b2N0ZXQpIHwgDQorLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tKyANCnwgTGVuZ3RoIG9mIE5leHQgSG9wIE5ldHdvcmsgQWRkcmVzcyAoMSBv Y3RldCkgfCANCistLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0rIA0KfCBOZXR3b3JrIEFkZHJlc3Mgb2YgTmV4dCBIb3AgKHZhcmlhYmxlKSB8 IA0KKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSsgDQp8IFJlc2VydmVkICgxIG9jdGV0KSB8IA0KKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsgDQp8IFByZWZpeCBMZW5ndGggPSA4 OCB8ICBJUCBQcmVmaXggKHZhcmlhYmxlKSA9IFJEIGZvbGxvd2VkIGJ5IElQIHByZWZpeCAvLyAN CistKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rKw0KDQoNCg0KbGl6aGVucWlhbmdAY2hpbmFtb2JpbGUuY29tDQogDQpGcm9tOiBI YW5uZXMgR3JlZGxlcg0KRGF0ZTogMjAxNC0wOS0wMiAxNjozNQ0KVG86IGxpemhlbnFpYW5nQGNo aW5hbW9iaWxlLmNvbQ0KQ0M6IFVtYSBDaHVuZHVyaTsgJ2lkciB3Zyc7ICdKb2huIEcuIFNjdWRk ZXInOyBTdXNhbiBIYXJlcw0KU3ViamVjdDogUmU6IFJFOiBbSWRyXSBXRyBMQyBmb3IgZHJhZnQt aWV0Zi1pZHItbHMtZGlzdHJpYnV0aW9uIGFuZCBkcmFmdC1pZXRmLWlkci1scy1kaXN0cmlidXQt aW1wbA0KaGkgemhlbnFpYW5nLA0KIA0KT24gVHVlLCBTZXAgMDIsIDIwMTQgYXQgMDQ6MTI6NThQ TSArMDgwMCwgbGl6aGVucWlhbmdAY2hpbmFtb2JpbGUuY29tIHdyb3RlOg0KfCAgICBUd28gdHlw ZXMgb2YgbGluayBzdGF0ZSBOTFJJcyBhcmUgZGVmaW5lZCBpbiBzZWN0aW9uIDMuMiBvZiB0aGlz DQp8ICAgIGRyYWZ0LCBBRkkgMTYzODggLyBTQUZJIDcxIGZvciBub24tVlBOLCBBRkkgMTYzODgg LyBTQUZJIDEyOCBmb3IgVlBOLg0KIA0KY29ycmVjdDsNCiANCnwgICAgTXkgcXVlc3Rpb24gaXMg YWJvdXQgQUZJIDE2Mzg4IC8gU0FGSSAxMjggTkxSSS4gRnJvbSB0aGUgZmlndXJlIGluIHBhZ2Ug OQ0KfCAgICBvZiBkcmFmdCB2ZXJzaW9uIDUsIHdlIGNhbiBzZWUgdGhhdCBSRCBpcyBwdXQgYmVm b3JlIGxpbmsgc3RhdGUgTkxSSS4NCiANCiANCmZyb20gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1pZHItbHMtZGlzdHJpYnV0aW9uLTA1I3NlY3Rpb24tMy4yDQogDQp0aGlz IGlzIHRoZSBOTFJJIGZvcm1hdCBmb3IgQUZJIDE2Mzg4IC8gU0FGSSA3MSAodW5pY2FzdCkNCiAN CiAgICAwICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAg ICAgICAgICAzDQogICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAg MSAyIDMgNCA1IDYgNyA4IDkgMCAxDQogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgfCAgICAgICAgICAgIE5MUkkg VHlwZSAgICAgICAgICB8ICAgICBUb3RhbCBOTFJJIExlbmd0aCAgICAgICAgIHwNCiAgICstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rDQogICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgfA0KICAgLy8gICAgICAgICAgICAgICAgICBMaW5rLVN0YXRlIE5MUkkg KHZhcmlhYmxlKSAgICAgICAgICAgICAgICAgLy8NCiAgIHwgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICArLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0K IA0KYW5kIHRoaXMgaXMgdGhlIE5MUkkgZm9ybWF0IGZvciBBRkkgMTYzODggLyBTQUZJIDEyOCAo VlBOLXVuaWNhc3QpDQogDQogICAgMCAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAg ICAgIDIgICAgICAgICAgICAgICAgICAgMw0KICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIg MyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0KICAgKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgIHwg ICAgICAgICAgICBOTFJJIFR5cGUgICAgICAgICAgfCAgICAgVG90YWwgTkxSSSBMZW5ndGggICAg ICAgICB8DQogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKw0KICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICsgICAgICAgICAgICAgICAgICAg ICAgIFJvdXRlIERpc3Rpbmd1aXNoZXIgICAgICAgICAgICAgICAgICAgICArDQogICB8ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg fA0KICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSsNCiAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAvLyAgICAgICAgICAgICAgICAgIExpbmst U3RhdGUgTkxSSSAodmFyaWFibGUpICAgICAgICAgICAgICAgICAvLw0KICAgfCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAg ICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rDQogDQogDQogDQp8ICAgIFRoZSBsaW5rIHN0YXRlIE5MUkkgZmllbGQgaW4gdGhp cyBmaWd1cmUgY29udGFpbnMgdGhlIElQIHByZWZpeC4gQXMgUkZDNDM2NA0KfCAgICBzcGVjaWZp ZXMsIHRoZSBWUE4gcm91dGVzIHNob3VsZCBiZSBjYXJyaWVkIGluIHRoZSBOTFJJIHByZXBlbmRp bmcgd2l0aA0KfCAgICBSRC4NCiANCnRoYXQgaXMgd2hhdCB3ZSBkbyAtIGkgZmFpbCB0byBzZWUg dGhlIG9mZmVuZGluZyBwYXJ0IHdpdGggcmVzcGVjdCB0byBSRkM0MzY0Lg0KIA0KL2hhbm5lcw0K IA0KfCANCnwgICAgICBGcm9tOiBbMV1IYW5uZXMgR3JlZGxlcg0KfCAgICAgIERhdGU6IDIwMTQt MDktMDIgMTU6MjkNCnwgICAgICBUbzogWzJdbGl6aGVucWlhbmdAY2hpbmFtb2JpbGUuY29tOyBb M11VbWEgQ2h1bmR1cmkNCnwgICAgICBDQzogWzRdJ2lkciB3Zyc7IFs1XSdKb2huIEcuIFNjdWRk ZXInOyBbNl1TdXNhbiBIYXJlcw0KfCAgICAgIFN1YmplY3Q6IFJFOiBSZTogW0lkcl0gV0cgTEMg Zm9yIGRyYWZ0LWlldGYtaWRyLWxzLWRpc3RyaWJ1dGlvbiBhbmQNCnwgICAgICBkcmFmdC1pZXRm LWlkci1scy1kaXN0cmlidXQtaW1wbA0KfCANCnwgICAgICBoaSB6aGVucWlhbmcsDQp8IA0KfCAg ICAgIFRoZSBSb3V0ZS1kaXN0aW5ndWlzaGVyJ3MgcHVycG9zZSBpcyB0byBhZGQgNjQtYml0cyBv ZiAgZGlzYW1iaWd1YXRpbmcNCnwgICAgICBlbnRyb3B5IHRvIHRoZSBOTFJJLCBzdWNoDQp8IA0K fCAgICAgIHRoYXQgdGhlIHJvdXRlLXJlZmxlY3RvcnMgZG8gbm90ICJzd2FsbG93IiB0aGF0IHBh dGggYXMgcGFydCBvZiB0aGUNCnwgICAgICBiZXN0LXBhdGggZWxlY3Rpb24NCnwgDQp8ICAgICAg cHJvY2VkdXJlLiBUaGUgbGluay1zdGF0ZSBOTFJJIChlbmNhcHN1bGF0ZWQgaW4gTVBfUkVBQ0gv IE1QIFVOUkVBQ0ggUEEpDQp8IA0KfCAgICAgIGlzIGEgUkQtbGVzcyB2ZXJzaW9uIG9mIHRoZSB2 cG4tbGluay1zdGF0ZSBOTFJJLg0KfCANCnwgICAgICBJbiBhIGNlcnRhaW4gd2F5IHRoZXNlIGNv cnJlc3BvbmQgdG8gUkZDMzEwNyAvIFJGQzQzNjQgTkxSSSBmb3JtYXRzLg0KfCANCnwgICAgICBU aGUgZm9ybWVyIGlzIGEgUkQtbGVzcyB2ZXJzaW9uIG9mIHRoZSBsYXR0ZXIuDQp8IA0KfCAgICAg IE9uIHlvdXIgcXVlc3Rpb24gIldoeSBkbyd0IHlvdSBwdXQgUkQgaW4gSVAgUmVhY2hhYmlsaXR5 IEluZm9ybWF0aW9uLA0KfCAgICAgIGp1c3QgcHJlcGVuZGluZyBSRCB3aXRoIElQIHByZWZpeCBh cyBSRkM0MzY0IHNwZWNpZmllcy4iIC0gVGhpcyBpcw0KfCAgICAgIGFjdHVhbGx5IHdoYXQgd2Ug KmFyZSogZG9pbmcgLSB3ZSBwdXQgdGhlIFJEIGJlZm9yZSB0aGUgbGluay1zdGF0ZSBOTFJJDQp8 ICAgICAgaW5zaWRlIHRoZSBNUF9SRUFDSC9NUF9VTlJFQUNIIEF0dHJpYnV0ZS4NCnwgDQp8ICAg ICAgSFRILA0KfCANCnwgICAgICAvaGFubmVzDQp8IA0KfCAgICAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K fCANCnwgICAgICBGcm9tOiBsaXpoZW5xaWFuZ0BjaGluYW1vYmlsZS5jb20gPGxpemhlbnFpYW5n QGNoaW5hbW9iaWxlLmNvbT4NCnwgICAgICBTZW50OiBUdWVzZGF5LCBTZXB0ZW1iZXIgMDIsIDIw MTQgODo0NA0KfCAgICAgIFRvOiBIYW5uZXMgR3JlZGxlcjsgVW1hIENodW5kdXJpDQp8ICAgICAg Q2M6ICdpZHIgd2cnOyAnSm9obiBHLiBTY3VkZGVyJzsgU3VzYW4gSGFyZXMNCnwgICAgICBTdWJq ZWN0OiBSZTogUmU6IFtJZHJdIFdHIExDIGZvciBkcmFmdC1pZXRmLWlkci1scy1kaXN0cmlidXRp b24gYW5kDQp8ICAgICAgZHJhZnQtaWV0Zi1pZHItbHMtZGlzdHJpYnV0LWltcGwNCnwgDQp8ICAg ICAgT25lIHF1ZXN0aW9uIGFib3V0IHRoZSBWUE4gTGluay1TdGF0ZSBOTFJJIGluIHNlY3Rpb24g My4yLiBXaHkgZG8geW91DQp8ICAgICAgcHV0IHRoZSBSRCBiZWZvcmUgbGluayBzdGF0ZSBOUkxJ PyBXaHkgZG8ndCB5b3UgcHV0IFJEIGluIElQDQp8ICAgICAgUmVhY2hhYmlsaXR5IEluZm9ybWF0 aW9uLCBqdXN0IHByZXByZW5kaW5nIFJEIHdpdGggSVAgcHJlZml4IGFzIFJGQzQzNjQNCnwgICAg ICBzcGVjaWZpZXMuDQp8IA0KfCAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KfCANCnwgICAgICBsaXpo ZW5xaWFuZ0BjaGluYW1vYmlsZS5jb20NCnwgDQp8IA0KfCAgICAgICAgRnJvbTogWzddSGFubmVz IEdyZWRsZXINCnwgICAgICAgIERhdGU6IDIwMTQtMDktMDIgMDI6MDUNCnwgICAgICAgIFRvOiBb OF1VbWEgQ2h1bmR1cmkNCnwgICAgICAgIENDOiBbOV1pZHJAaWV0Zi5vcmc7IFsxMF0nSm9obiBH LiBTY3VkZGVyJzsgWzExXVN1c2FuIEhhcmVzDQp8ICAgICAgICBTdWJqZWN0OiBSZTogW0lkcl0g V0cgTEMgZm9yIGRyYWZ0LWlldGYtaWRyLWxzLWRpc3RyaWJ1dGlvbiBhbmQNCnwgICAgICAgIGRy YWZ0LWlldGYtaWRyLWxzLWRpc3RyaWJ1dC1pbXBsDQp8ICAgICAgICBoaSB1bWEsDQp8IA0KfCAg ICAgICAgc2VlIGNvbW1lbnRzL3Jlc3BvbnNlcyBpbmxpbmU6DQp8IA0KfCAgICAgICAgT24gV2Vk LCBBdWcgMjcsIDIwMTQgYXQgMTE6MDc6MDFBTSArMDAwMCwgVW1hIENodW5kdXJpIHdyb3RlOg0K fCAgICAgICAgfCAgICBTdXBwb3J0Lg0KfCAgICAgICAgfA0KfCAgICAgICAgfCAgICBJIHNlZSwg aGllcmFyY2h5IGlzIFdFTEwgIGRlZmluZWQgd2hlbiBtdWx0aXBsZSBpbnN0YW5jZXMgb2YgSUdQ DQp8ICAgICAgICB3aXRoDQp8ICAgICAgICB8ICAgIG11bHRpcGxlIEFGcyBhcmUgcnVubmluZy4g R29vZCB3b3JrLg0KfCAgICAgICAgfA0KfCAgICAgICAgfA0KfCAgICAgICAgfA0KfCAgICAgICAg fCAgICBIYXZlIGZvbGxvd2luZyBRczoNCnwgICAgICAgIHwNCnwgICAgICAgIHwgICAgMS4gICAg ICAgQW55IGRpc2N1c3Npb24gb2YgdGhlIGRlbGF5IGludHJvZHVjZWQgYnkgQkdQIChwYWNraW5n LA0KfCAgICAgICAgdXBkYXRlDQp8ICAgICAgICB8ICAgIGdlbmVyYXRpb24sIHByb2Nlc3Npbmcg ZXRjLi4pIHRvIHRyYW5zcG9ydCB0aGUgTFMgaW5mb3JtYXRpb24NCnwgICAgICAgIHwNCnwgICAg ICAgIHwgICAgZXNwZWNpYWxseSwgd2hlbiBMU0RCIGlzIGNoYW5naW5nIGZhc3RlciBwZXJoYXBz IHdpdGggbGFyZ2UNCnwgICAgICAgIG51bWJlciBvZg0KfCAgICAgICAgfCAgICBub2Rlcy9saW5r cyBpbnNpZGUgYW4gQVMgYW5kIHdpdGggbXVsdGlwbGUgQVNlcykgdG8gdGhlDQp8ICAgICAgICBj b250cm9sbGVyIHdpbGwgYmUNCnwgICAgICAgIHwgICAgdXNlZnVsLg0KfCANCnwgICAgICAgIHRo aXMgaXMgaGlnaGx5IGltcGxlbWVudGF0aW9uIGRlcGVuZGVudDsgLQ0KfCAgICAgICAgc29tZSB2 ZW5kb3JzIGRvIHRoZSBwYWNrYWdpbmcgb2YgQkdQIHVwZGF0ZXMgZW50aXJlbHkgZXZlbnQtZHJp dmVuDQp8ICAgICAgICBhbmQgb3RoZXJzIHBhY2sgdGhpbmdzIHVwIGFuZCBoYXZlIGEgd29yc3Qg Y2FzZSBkZWxheSBiZXR3ZWVuDQp8ICAgICAgICB0aGUgdHJpZ2dlciBldmVudCBhbmQgdGhlIEJH UCB1cGRhdGUuIHRoZSBwcm90b2NvbA0KfCAgICAgICAgaXRzZWxmIGRvZXMgbm90IHByb2hpYml0 L2xpbWl0IHRoZSBwcm9wYWdhdGlvbiBzcGVlZC4NCnwgICAgICAgIChpbiBmYWN0IGl0IGNhbiBi ZSBzaG93biB0aGF0IHNvbWV0aW1lcyB1cGRhdGVzDQp8ICAgICAgICB0cmF2ZWwgZmFzdGVyIG9u IHRoZSAoZGF0YXBsYW5lIGZvcndhcmRlZCkgaUJHUCBtZXNoLA0KfCAgICAgICAgcmF0aGVyIHRo YW4gcHJvcGdhdGUgdXNpbmcgdGhlIGhvcC1ieS1ob3AgY29udHJvbC1wbGFuZSBmbG9vZGluZw0K fCAgICAgICAgcHJvdG9jb2wpDQp8IA0KfCAgICAgICAgfCAgICAgICAgICAgICAgICAgQSBub3Rl IG9uIHRoZSBzZW5zaXRpdml0eSBvZiB0aGlzIGRlbGF5IHRvIHRoZQ0KfCAgICAgICAgY29uc3Vt ZXINCnwgICAgICAgIHwgICAgKGFwcGxpY2F0aW9ucykgYXQgdGhlIGNvbnRyb2xsZXIgIGNhbiBi ZSBoZWxwZnVsLiBJIHNhdyB2ZXJ5DQp8ICAgICAgICBsaXR0bGUNCnwgICAgICAgIHwgICAgZGlz Y3Vzc2lvbiBpbiBTZWN0aW9uIDYgKDYuMS41KQ0KfCANCnwgICAgICAgIGRpZmZpY2l1bHQgLSBp dHMgaGFyZCB0byBoYXZlIHNvbWUgc29ydCBvZiBnZW5lcmFsIGNvbW1lbnQgYXMgdGhpbmdzDQp8 ICAgICAgICBhcmUNCnwgICAgICAgIGhpZ2hseSBpbXBsZW1lbnRhdGlvbiBkZXBlbmRlbnQuDQp8 IA0KfCANCnwgICAgICAgIHwgICAgMi4gICAgICAgVGhpcyBkb2N1bWVudCBlbmNvbXBhc3NlcyBw cmV0dHkgbXVjaCBib3RoIE9TUEYgYW5kIElTSVMNCnwgICAgICAgIHwgICAgZXh0ZW5zaW9ucyBk b25lIHRpbGwgZGF0ZS4gSG93IGl0IHdpbGwga2VlcCB1cCB3aXRoIGZ1dHVyZQ0KfCAgICAgICAg ZXh0ZW5zaW9ucyBpbg0KfCAgICAgICAgfCAgICBPU1BGL0lTSVMuDQp8IA0KfCAgICAgICAgd2Ug aGF2ZSBzZXQgdXAgYW4gSUFOQSByZWdpc3RyaWVzIGZvciB0aGUgY2FycmllcnMgb2YgaW5mb3Jt YXRpb24uDQp8ICAgICAgICBpdCBpcyBleHBlY3RlZCBieSBhdXRob3JzIG9mICJ0b3BvbG9naWNh bCByZWxldmFudCIgSUdQIGV4dGVuc2lvbnMNCnwgICAgICAgIHRvIHN1cHBseSBhbHNvIEJHUC1M UyBleHRlbnNpb25zLg0KfCANCnwgICAgICAgIHwgICAgQSBtZWNoYW5pc20gaW4gcGxhY2Ugd291 bGQgYmUgaGVscGZ1bC4gTXkgc3VnZ2VzdGlvbiB3b3VsZCBiZS0NCnwgICAgICAgIHRoZQ0KfCAg ICAgICAgfCAgICByZXNwZWN0aXZlIElHUCBkb2N1bWVudHMgc2hvdWxkIGFzc2VzcyB0aGUgaW1w YWN0IGFuZCBkZWZpbmUNCnwgICAgICAgIHwNCnwgICAgICAgIHwgICAgY29ycmVzcG9uZGluZyBu ZXcgVExWcyBmb3IgQkdQIExTPyBCdXQgaG93IHRoaXMgY2FuIGJlIGVuZm9yY2VkPw0KfCANCnwg ICAgICAgIGkgaGF2ZSBubyBpZGVhIC0gdG9kYXkgaXRzIGVudGlyZWx5IHZvbHVudGFyeS4NCnwg DQp8ICAgICAgICB8ICAgIDMuICAgICAgIFNlY3Rpb24gNCwgZ2l2ZXMgZ2xpbXBzZSB3aGF0J3Mg cG9zc2libGUgYW5kIHRoZSBub2RlDQp8ICAgICAgICBhZ2dyZWdhdGluZw0KfCAgICAgICAgfCAg ICB0aGUgbGlua3Mgb2J2aW91c2x5IG5lZWQgdG8gdGlua2VyIHRoZSBMU0RCIHRvIHJlcHJlc2Vu dCB0aGUgc2FtZQ0KfCAgICAgICAgfCAgICBjb3JyZWN0bHkuDQp8ICAgICAgICB8DQp8ICAgICAg ICB8ICAgIFNvbWUgbW9yZSBkZXRhaWxzIHdvdWxkIGJlIGhlbHBmdWwgdG8gcmVwcmVzZW50IHRo ZSBjaGFuZ2VzIG9uDQp8ICAgICAgICB8ICAgIGFnZ3JlZ2F0aW9uL2RlLWFnZ3JlZ2F0aW9uIHN1 YnNlcXVlbnRseS4NCnwgDQp8ICAgICAgICB0aGlzIG1heSBxdWlja2x5IGdldCB5b3UgaW50byB0 aGUgImFic3RyYWN0ZWQgdG9wb2xvZ3kgbW9kZWxzIg0KfCAgICAgICAgZGlzY3Vzc2lvbiB0aGF0 IGtlZXBzIGVtZXJnaW5nICBwZXJpb2RpY2FsbHkuIC0NCnwgICAgICAgIHdlIGRpZCBub3Qgd2Fu dCB0byBzdG9wIHByb2dyZXNzIG9uIHRoZSBwcm90b2NvbCBieSBhcmd1aW5nDQp8ICAgICAgICAi d2hhdHMgdGhlIHJpZ2h0IGFic3RyYWN0aW9uIG1vZGVsIiBhbmQgaGF2ZSBhZ3JlZWQNCnwgICAg ICAgIG9uIHRoZSBtaW5pbWFsaXN0aWMgbmF0dXJlIG9mIHRoZSBzZWN0aW9uIGFzLWlzLg0KfCAN CnwgDQp8ICAgICAgICB8ICAgIDQuICAgICAgIFNlY3Rpb24gNi4yIGhhcyBlbXB0eSBzdWItc2Vj dGlvbnMgYW5kIFRCRHMuDQp8IA0KfCAgICAgICAgcmlnaHQgLi4uIHNvIHN1Z2dlc3QgdG8gcmVt b3ZlIHNlY3Rpb24gNi4yIGFsdG9nZXRoZXIuDQp8IA0KfCAgICAgICAgfCAgICA1LiAgICAgICBJ dCdzIGdvb2QgdG8gc2VlIEltcGxlbWVudGF0aW9uIHJlcG9ydCBzaGVkIGxpZ2h0IG9uDQp8ICAg ICAgICBwZXJmb3JtYW5jZQ0KfCAgICAgICAgfCAgICBzZWVuIHdpdGggbXVsdGlwbGUgQVNlcy4N CnwgICAgICAgIHwNCnwgICAgICAgIHwgICAgNi4gICAgICAgSXQncyBnb29kIHRvIHNlZSBpZiBh bnkgYXBwbGljYXRpb24gb2YgcG9saWN5IG9uIExTREIgaXMNCnwgICAgICAgIGRvbmUNCnwgICAg ICAgIHwgICAgKG9uZSBvZiB0aGUgcHJpbWFyeSBkcml2ZXJzIG9mIHRoZSBzcGVjaWZpY2F0aW9u KS4NCnwgDQp8IA0KfCAgICAgICAgdGhhbmtzLA0KfCANCnwgDQp8ICAgICAgICAvaGFubmVzDQp8 IA0KfCAgICAgICAgfA0KfCAgICAgICAgfCAgICBGcm9tOiBJZHIgW21haWx0bzppZHItYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFN1c2FuIEhhcmVzDQp8ICAgICAgICB8ICAgIFNlbnQ6 IFR1ZXNkYXksIEF1Z3VzdCAyNiwgMjAxNCAxMTozNyBBTQ0KfCAgICAgICAgfCAgICBUbzogaWRy QGlldGYub3JnDQp8ICAgICAgICB8ICAgIENjOiAnSm9obiBHLiBTY3VkZGVyJzsgc2hhcmVzQG5k emguY29tDQp8ICAgICAgICB8ICAgIFN1YmplY3Q6IFtJZHJdIFdHIExDIGZvciBkcmFmdC1pZXRm LWlkci1scy1kaXN0cmlidXRpb24gYW5kDQp8ICAgICAgICB8ICAgIGRyYWZ0LWlldGYtaWRyLWxz LWRpc3RyaWJ1dC1pbXBsDQp8ICAgICAgICB8DQp8ICAgICAgICB8DQp8ICAgICAgICB8DQp8ICAg ICAgICB8ICAgIFRoaXMgaXMgYSBXRyBMQyBmb3INCnwgICAgICAgIHwNCnwgICAgICAgIHwNCnwg ICAgICAgIHwNCnwgICAgICAgIHwNCnwgICAgICAgIFsxXWh0dHA6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtaWV0Zi1pZHItbHMtZGlzdHJpYnV0aW9uLw0KfCAgICAgICAgfA0KfCAg ICAgICAgfA0KfCAgICAgICAgWzJdaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1pZXRmLWlkci1scy1kaXN0cmlidXRpb24taW1wbC8NCnwgICAgICAgIHwNCnwgICAgICAgIHwN CnwgICAgICAgIHwNCnwgICAgICAgIHwgICAgUGxlYXNlIHJlc3BvbmQgd2l0aCBjb21tZW50cyBh bmQgInN1cHBvcnQgb3Igbm8gc3VwcG9ydC4iICBUaGlzDQp8ICAgICAgICBXRyBMQyBhbHNvDQp8 ICAgICAgICB8ICAgIGluY2x1ZGVzIGEgcmVxdWVzdCBmb3IgdGhlIGF1dGhvcnMgdG8gcHJvdmlk ZSBJUFIgb24gdGhlIHN1YmplY3QuDQp8ICAgICAgICB8DQp8ICAgICAgICB8DQp8ICAgICAgICB8 DQp8ICAgICAgICB8ICAgIFBsZWFzZSBub3RlOiBkdWUgdG8gdGhlIEV1cm9wZWFuIHZhY2F0aW9u cyBpbiBBdWd1c3QsIHdlIGFyZQ0KfCAgICAgICAgYnVuZGxpbmcNCnwgICAgICAgIHwgICAgdGhl c2UgdGhyZWUgcmV2aWV3cyBpbnRvIHRoZSBuZXh0IHR3byB3ZWVrcyAodGhlc2UgdHdvIGRyYWZ0 cyBhbmQNCnwgICAgICAgIHwgICAgZHJhZnQtaWV0Zi1hcy1taWdyYXRpb24pLiAgIFRoZSBjaGFp cnMgd291bGQgbGlrZSBmZWVkYmFjayAobGlzdA0KfCAgICAgICAgb3INCnwgICAgICAgIHwgICAg cHJpdmF0ZSBlbWFpbCkgd2hldGhlciB0aGUgdGhyZWUgV0cgTEMgcyBpbXBhY3QgYW55b25lJ3Mg YWJpbGl0eQ0KfCAgICAgICAgdG8gcmV2aWV3DQp8ICAgICAgICB8ICAgIHRoZXNlIGRyYWZ0cyBj YXJlZnVsbHkuDQp8ICAgICAgICB8DQp8ICAgICAgICB8DQp8ICAgICAgICB8DQp8ICAgICAgICB8 ICAgIFRoYW5rIHlvdSwNCnwgICAgICAgIHwNCnwgICAgICAgIHwNCnwgICAgICAgIHwNCnwgICAg ICAgIHwgICAgU3VlIEhhcmVzIGFuZCBKb2huIFNjdWRkZXINCnwgICAgICAgIHwNCnwgICAgICAg IHwgUmVmZXJlbmNlcw0KfCAgICAgICAgfA0KfCAgICAgICAgfCAgICBWaXNpYmxlIGxpbmtzDQp8 ICAgICAgICB8ICAgIDEuDQp8ICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWlldGYtaWRyLWxzLWRpc3RyaWJ1dGlvbi8NCnwgICAgICAgIHwgICAgMi4NCnwgICAg ICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pZHItbHMtZGlz dHJpYnV0aW9uLWltcGwvDQp8IA0KfCAgICAgICAgfCBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KfCAgICAgICAgfCBJZHIgbWFpbGluZyBsaXN0DQp8ICAg ICAgICB8IElkckBpZXRmLm9yZw0KfCAgICAgICAgfCBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2lkcg0KfCANCnwgICAgICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQp8ICAgICAgICBJZHIgbWFpbGluZyBsaXN0DQp8ICAgICAg ICBJZHJAaWV0Zi5vcmcNCnwgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vaWRyDQp8IA0KfCANCnwgUmVmZXJlbmNlcw0KfCANCnwgICAgVmlzaWJsZSBsaW5rcw0K fCAgICAxLiBtYWlsdG86aGFubmVzQGp1bmlwZXIubmV0DQp8ICAgIDIuIG1haWx0bzpsaXpoZW5x aWFuZ0BjaGluYW1vYmlsZS5jb20NCnwgICAgMy4gbWFpbHRvOnVtYS5jaHVuZHVyaUBlcmljc3Nv bi5jb20NCnwgICAgNC4gbWFpbHRvOmlkckBpZXRmLm9yZw0KfCAgICA1LiBtYWlsdG86amdzQGJn cC5udQ0KfCAgICA2LiBtYWlsdG86c2hhcmVzQG5kemguY29tDQp8ICAgIDcuIG1haWx0bzpoYW5u ZXNAanVuaXBlci5uZXQNCnwgICAgOC4gbWFpbHRvOnVtYS5jaHVuZHVyaUBlcmljc3Nvbi5jb20N CnwgICAgOS4gbWFpbHRvOmlkckBpZXRmLm9yZw0KfCAgIDEwLiBtYWlsdG86amdzQGJncC5udQ0K fCAgIDExLiBtYWlsdG86c2hhcmVzQG5kemguY29tDQogDQo= ------=_001_NextPart360370131358_=---- Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =0A
Hi Hannes,

One example t= o explain the differences. One VPN route with prefix length 24 is carried = in the NRLI.

The format this draft specified is a= s follows.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+
 |      &nb= sp;     NLRI Type =3D 3         |&= nbsp;    Total NLRI Length     &nb= sp;   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+
 |      &= nbsp;           &nb= sp;            = ;            &= nbsp;           &nb= sp;       |
+   &nb= sp;            = ;       Route Distinguisher   = ;            &= nbsp;     +
 |    &= nbsp;           &nb= sp;            = ;            &= nbsp;           &nb= sp;         |
+-+-+-+-+-+-+-+-+ +-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol-ID |=0A
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A
| Identifier |=0A
| (64 bits) = |=0A
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= =0A
// Local Node Descriptor (variable) //=0A
+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A
= | Type =3D 265   =                     &nbs= p;    | Length |=0A
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+=0A
| Prefix Length =3D 24 | IP Prefix (variabl= e) //=0A
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+
=0A


The format RFC4363 s= pecified is as follows.
+---------------------------------------------------------+=0A=
| Address Family Identifier (2 octets) |=0A
+----------------------= -----------------------------------+=0A
| Subsequent Address Family Ide= ntifier (1 octet) |=0A
+-----------------------------------------------= ----------+=0A
| Length of Next Hop Network Address (1 octet) |=0A
+= ---------------------------------------------------------+=0A
| Network= Address of Next Hop (variable) |=0A
+---------------------------------= ------------------------+=0A
| Reserved (1 octet) |=0A
+------------= ---------------------------------------------+=0A
| Prefix Lengt= h =3D 88 |  IP Prefix (variable) =3D RD followed by IP prefix // = ;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++

=0A
=0A
lizhenqiang@chinamobile.com
=0A
 
Subject: Re: RE: [Idr] WG LC for draft-ie= tf-idr-ls-distribution and draft-ietf-idr-ls-distribut-impl
hi zhenqiang,
=0A
 
=0A
On Tue, Sep 02= , 2014 at 04:12:58PM +0800, lizhenqiang@chinamobile.com wrote:
=0A|    Two types of link state NLRIs are defined in section= 3.2 of this
=0A
|    draft, AFI 16388 / SAFI 71 f= or non-VPN, AFI 16388 / SAFI 128 for VPN.
=0A
 
=0Acorrect;
=0A
 
=0A
|    My question= is about AFI 16388 / SAFI 128 NLRI. From the figure in page 9
=0A|    of draft version 5, we can see that RD is put before= link state NLRI.
=0A
 
=0A
 
=0A
fro= m http://tools.ietf.org/html/draft-ietf-idr-ls-distribution-05#section-3.2=
=0A
 
=0A
this is the NLRI format for AFI 16388 / = SAFI 71 (unicast)
=0A
 
=0A
    0&nb= sp;            = ;      1       = ;            2 = ;            &= nbsp;     3
=0A
    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
=0A
 &= nbsp; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A
   |        &= nbsp;   NLRI Type        = ;  |     Total NLRI Length    = ;     |
=0A
   +-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=0A
   |&= nbsp;           &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ; |
=0A
   //       =            Link-State NL= RI (variable)          &= nbsp;      //
=0A
   | &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            |=0A
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+
=0A
 
=0A
and this is the NLRI forma= t for AFI 16388 / SAFI 128 (VPN-unicast)
=0A
 
=0A
=     0         =           1   =             &n= bsp;   2         &n= bsp;         3
=0A
 =    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
=0A
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
=0A
   |    &n= bsp;       NLRI Type    =       |     Total NLRI Length=          |
=0A
 &nbs= p; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= =0A
   |        &nbs= p;            =             &n= bsp;           &nbs= p;            =      |
=0A
   +   &n= bsp;           &nbs= p;       Route Distinguisher  &nbs= p;            =       +
=0A
   |  &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;           |
=0A<= div>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
=0A
   |      &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;       |
=0A
   // = ;            &= nbsp;    Link-State NLRI (variable)    =              /= /
=0A
   |       &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;      |
=0A
   +-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=0A
 =0A
 
=0A
 
=0A
|    The= link state NLRI field in this figure contains the IP prefix. As RFC4364=0A
|    specifies, the VPN routes should be carrie= d in the NLRI prepending with
=0A
|    RD.
= =0A
 
=0A
that is what we do - i fail to see the offendi= ng part with respect to RFC4364.
=0A
 
=0A
/hannes<= /div>=0A
 
=0A
|
=0A
|    =   From: [1]Hannes Gredler
=0A
|     = ; Date: 2014-09-02 15:29
=0A
|      To: = [2]lizhenqiang@chinamobile.com; [3]Uma Chunduri
=0A
|  =     CC: [4]'idr wg'; [5]'John G. Scudder'; [6]Susan Hares=0A
|      Subject: RE: Re: [Idr] WG LC f= or draft-ietf-idr-ls-distribution and
=0A
|   &nbs= p;  draft-ietf-idr-ls-distribut-impl
=0A
|
=0A
|&n= bsp;     hi zhenqiang,
=0A
|
=0A
|&= nbsp;     The Route-distinguisher's purpose is to add = 64-bits of  disambiguating
=0A
|    &nbs= p; entropy to the NLRI, such
=0A
|
=0A
|  &nb= sp;   that the route-reflectors do not "swallow" that path as pa= rt of the
=0A
|      best-path election<= /div>=0A
|
=0A
|      procedure. Th= e link-state NLRI (encapsulated in MP_REACH/ MP UNREACH PA)
=0A
|=
=0A
|      is a RD-less version of the= vpn-link-state NLRI.
=0A
|
=0A
|   &nbs= p;  In a certain way these correspond to RFC3107 / RFC4364 NLRI forma= ts.
=0A
|
=0A
|      The forme= r is a RD-less version of the latter.
=0A
|
=0A
| =      On your question "Why do't you put RD in IP Reach= ability Information,
=0A
|      just pre= pending RD with IP prefix as RFC4364 specifies." - This is
=0A
|&= nbsp;     actually what we *are* doing - we put the RD= before the link-state NLRI
=0A
|      i= nside the MP_REACH/MP_UNREACH Attribute.
=0A
|
=0A
|&nb= sp;     HTH,
=0A
|
=0A
|  = ;    /hannes
=0A
|
=0A
|  &nbs= p; -----------------------------------------------------------------------= ---
=0A
|
=0A
|      From: liz= henqiang@chinamobile.com <lizhenqiang@chinamobile.com>
=0A
= |      Sent: Tuesday, September 02, 2014 8:44=0A
|      To: Hannes Gredler; Uma Chunduri=
=0A
|      Cc: 'idr wg'; 'John G. Scudd= er'; Susan Hares
=0A
|      Subject: Re:= Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and
=0A
|&nbs= p;     draft-ietf-idr-ls-distribut-impl
=0A
|=
=0A
|      One question about the VPN = Link-State NLRI in section 3.2. Why do you
=0A
|   = ;   put the RD before link state NRLI? Why do't you put RD in IP=
=0A
|      Reachability Information, ju= st preprending RD with IP prefix as RFC4364
=0A
|  &nbs= p;   specifies.
=0A
|
=0A
|   = -------------------------------------------------------------------------= -
=0A
|
=0A
|      lizhenqiang= @chinamobile.com
=0A
|
=0A
|
=0A
|  = ;      From: [7]Hannes Gredler
=0A
|&nbs= p;       Date: 2014-09-02 02:05
=0A|        To: [8]Uma Chunduri
=0A<= div>|        CC: [9]idr@ietf.org; [10]'= John G. Scudder'; [11]Susan Hares
=0A
|    &n= bsp;   Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-distributi= on and
=0A
|        draft-ietf= -idr-ls-distribut-impl
=0A
|      &= nbsp; hi uma,
=0A
|
=0A
|     =    see comments/responses inline:
=0A
|
=0A
|=         On Wed, Aug 27, 2014 at 11:07:0= 1AM +0000, Uma Chunduri wrote:
=0A
|     = ;   |    Support.
=0A
|   = ;     |
=0A
|     &n= bsp;  |    I see, hierarchy is WELL  defined when= multiple instances of IGP
=0A
|     &nb= sp;  with
=0A
|        |&= nbsp;   multiple AFs are running. Good work.
=0A
| = ;       |
=0A
|   &n= bsp;    |
=0A
|      = ;  |
=0A
|        | =    Have following Qs:
=0A
|    &nbs= p;   |
=0A
|        = |    1.       Any discussion = of the delay introduced by BGP (packing,
=0A
|   &= nbsp;    update
=0A
|     = ;   |    generation, processing etc..) to transpo= rt the LS information
=0A
|      &n= bsp; |
=0A
|        | &nb= sp;  especially, when LSDB is changing faster perhaps with large=0A
|        number of
=0A|        |    nodes/li= nks inside an AS and with multiple ASes) to the
=0A
|  =       controller will be
=0A
| &nbs= p;      |    useful.
=0A
= |
=0A
|        this is highly= implementation dependent; -
=0A
|     &= nbsp;  some vendors do the packaging of BGP updates entirely event-dr= iven
=0A
|        and others p= ack things up and have a worst case delay between
=0A
| &nbs= p;      the trigger event and the BGP update. the= protocol
=0A
|        itself = does not prohibit/limit the propagation speed.
=0A
|  &= nbsp;     (in fact it can be shown that sometimes upda= tes
=0A
|        travel faster= on the (dataplane forwarded) iBGP mesh,
=0A
|   &= nbsp;    rather than propgate using the hop-by-hop control-= plane flooding
=0A
|        pr= otocol)
=0A
|
=0A
|      =   |           =       A note on the sensitivity of this delay to = the
=0A
|        consumer=0A
|        |    (= applications) at the controller  can be helpful. I saw very
=0A<= div>|        little
=0A
| = ;       |    discussion in Se= ction 6 (6.1.5)
=0A
|
=0A
|    &nbs= p;   difficiult - its hard to have some sort of general comment = as things
=0A
|        are=0A
|        highly implementatio= n dependent.
=0A
|
=0A
|
=0A
|  &nb= sp;     |    2.    =    This document encompasses pretty much both OSPF and ISIS=0A
|        |    e= xtensions done till date. How it will keep up with future
=0A
|&n= bsp;       extensions in
=0A
| = ;       |    OSPF/ISIS.
= =0A
|
=0A
|        we hav= e set up an IANA registries for the carriers of information.
=0A
= |        it is expected by authors of "= topological relevant" IGP extensions
=0A
|    = ;    to supply also BGP-LS extensions.
=0A
| =0A
|        |    A= mechanism in place would be helpful. My suggestion would be-
=0A|        the
=0A
|  = ;      |    respective IGP documen= ts should assess the impact and define
=0A
|   &nb= sp;    |
=0A
|      =   |    corresponding new TLVs for BGP LS? But how this= can be enforced?
=0A
|
=0A
|    &n= bsp;   i have no idea - today its entirely voluntary.
=0A|
=0A
|        | &nbs= p;  3.       Section 4, gives glimpse w= hat's possible and the node
=0A
|     &n= bsp;  aggregating
=0A
|      &= nbsp; |    the links obviously need to tinker the LSDB to r= epresent the same
=0A
|       = |    correctly.
=0A
|    &nbs= p;   |
=0A
|        = |    Some more details would be helpful to represent the ch= anges on
=0A
|        | &= nbsp;  aggregation/de-aggregation subsequently.
=0A
|
= =0A
|        this may quickly get y= ou into the "abstracted topology models"
=0A
|   &= nbsp;    discussion that keeps emerging  periodically.= -
=0A
|        we did not wan= t to stop progress on the protocol by arguing
=0A
|  &n= bsp;     "whats the right abstraction model" and have = agreed
=0A
|        on the min= imalistic nature of the section as-is.
=0A
|
=0A
| =0A
|        |    = 4.       Section 6.2 has empty sub-sections = and TBDs.
=0A
|
=0A
|     &nbs= p;  right ... so suggest to remove section 6.2 altogether.
=0A|
=0A
|        | &nbs= p;  5.       It's good to see Implement= ation report shed light on
=0A
|     &nb= sp;  performance
=0A
|      &n= bsp; |    seen with multiple ASes.
=0A
| &nbs= p;      |
=0A
|    &= nbsp;   |    6.     &nbs= p; It's good to see if any application of policy on LSDB is
=0A
|=         done
=0A
|  =       |    (one of the primary dri= vers of the specification).
=0A
|
=0A
|
=0A
|=         thanks,
=0A
|
= =0A
|
=0A
|        /hanne= s
=0A
|
=0A
|       = |
=0A
|        |  &= nbsp; From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares=0A
|        |    = Sent: Tuesday, August 26, 2014 11:37 AM
=0A
|   &n= bsp;    |    To: idr@ietf.org
=0A
|=         |    Cc: 'John G= . Scudder'; shares@ndzh.com
=0A
|     &n= bsp;  |    Subject: [Idr] WG LC for draft-ietf-idr-ls-= distribution and
=0A
|        = |    draft-ietf-idr-ls-distribut-impl
=0A
| &= nbsp;      |
=0A
|   &nbs= p;    |
=0A
|      &= nbsp; |
=0A
|        | &n= bsp;  This is a WG LC for
=0A
|     = ;   |
=0A
|        |=
=0A
|        |
=0A
|=         |
=0A
|  &nb= sp;     [1]http://datatracker.ietf.org/doc/draft-ietf-= idr-ls-distribution/
=0A
|      &nb= sp; |
=0A
|        |
=0A<= div>|        [2]http://datatracker.ietf= .org/doc/draft-ietf-idr-ls-distribution-impl/
=0A
|  &n= bsp;     |
=0A
|     = ;   |
=0A
|        |=
=0A
|        |  &nb= sp; Please respond with comments and "support or no support."  This=0A
|        WG LC also
= =0A
|        |    in= cludes a request for the authors to provide IPR on the subject.
=0A|        |
=0A
|  = ;      |
=0A
|    &n= bsp;   |
=0A
|       = ; |    Please note: due to the European vacations in August= , we are
=0A
|        bundling=
=0A
|        |  &nb= sp; these three reviews into the next two weeks (these two drafts and=0A
|        |    d= raft-ietf-as-migration).   The chairs would like feedback (list<= /div>=0A
|        or
=0A
|=         |    private ema= il) whether the three WG LC s impact anyone's ability
=0A
| =        to review
=0A
|  &= nbsp;     |    these drafts carefully.<= /div>=0A
|        |
=0A
|&= nbsp;       |
=0A
|  &nbs= p;     |
=0A
|     &= nbsp;  |    Thank you,
=0A
|   = ;     |
=0A
|     &n= bsp;  |
=0A
|        |=0A
|        |   = Sue Hares and John Scudder
=0A
|     &n= bsp;  |
=0A
|        | Re= ferences
=0A
|        |
= =0A
|        |    Vi= sible links
=0A
|        |&nbs= p;   1.
=0A
|       = http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/
=0A<= div>|        |    2.=0A
|        http://datatracker.i= etf.org/doc/draft-ietf-idr-ls-distribution-impl/
=0A
|
=0A<= div>|        | ________________________= _______________________
=0A
|      =   | Idr mailing list
=0A
|     &nbs= p;  | Idr@ietf.org
=0A
|      =   | https://www.ietf.org/mailman/listinfo/idr
=0A
|
= =0A
|        ______________________= _________________________
=0A
|     &nbs= p;  Idr mailing list
=0A
|     &nbs= p;  Idr@ietf.org
=0A
|      &n= bsp; https://www.ietf.org/mailman/listinfo/idr
=0A
|
=0A|
=0A
| References
=0A
|
=0A
|  &= nbsp; Visible links
=0A
|    1. mailto:hannes@juni= per.net
=0A
|    2. mailto:lizhenqiang@chinamobile= .com
=0A
|    3. mailto:uma.chunduri@ericsson.com<= /div>=0A
|    4. mailto:idr@ietf.org
=0A
|&nbs= p;   5. mailto:jgs@bgp.nu
=0A
|    6. ma= ilto:shares@ndzh.com
=0A
|    7. mailto:hannes@jun= iper.net
=0A
|    8. mailto:uma.chunduri@ericsson.= com
=0A
|    9. mailto:idr@ietf.org
=0A
|=    10. mailto:jgs@bgp.nu
=0A
|   11. mailto:s= hares@ndzh.com
=0A
 
=0A
=0A ------=_001_NextPart360370131358_=------ From nobody Tue Sep 2 05:00:09 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B6701A028A for ; Tue, 2 Sep 2014 05:00:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.301 X-Spam-Level: X-Spam-Status: No, score=-0.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_SHOP=2.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nh1aB_BqdMA5 for ; Tue, 2 Sep 2014 05:00:06 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5BB81A0282 for ; Tue, 2 Sep 2014 05:00:05 -0700 (PDT) X-AuditID: c618062d-f79206d0000014d2-cb-54055c304bb0 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id ED.80.05330.03C55045; Tue, 2 Sep 2014 07:57:05 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0174.001; Tue, 2 Sep 2014 08:00:02 -0400 From: Uma Chunduri To: Hannes Gredler Thread-Topic: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-ietf-idr-ls-distribut-impl Thread-Index: Ac/BW2lXGFeOO91XQC6F7jVfIRzoQgAhYZXAARP4RQAAHMM1YA== Date: Tue, 2 Sep 2014 12:00:01 +0000 Message-ID: <1B502206DFA0C544B7A60469152008633F36B2A5@eusaamb105.ericsson.se> References: <025201cfc15c$bbe17260$33a45720$@ndzh.com> <1B502206DFA0C544B7A60469152008633F364057@eusaamb105.ericsson.se> <20140901180518.GA34789@juniper.net> In-Reply-To: <20140901180518.GA34789@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKLMWRmVeSWpSXmKPExsUyuXRPiK5hDGuIwYUFUhb9956wWby6/YzJ YuP/HewWf968YnFg8VjS/Z7JY8mSn0we15uusnvMfn2dNYAlissmJTUnsyy1SN8ugSvj4q9u toLNWhXX71k1MK5T6GLk5JAQMJE4OP8xC4QtJnHh3nq2LkYuDiGBo4wSx+7tYYJwljFKfF90 iBmkik1AT+Lj1J/sILaIgLrEwkl3weLMAikSH58uB7OFBZIkNu/YywxRkyxx8fs8FgjbSeL2 96+MIDaLgIpEy5GFTCA2r4CvxP+PV5ghli1klDi57hlYglPAUGLXmclgDYxA530/tYYJYpm4 xK0n85kgzhaQWLLnPDOELSrx8vE/VghbSeLj7/nsEPU6Egt2f2KDsLUlli18zQyxWFDi5Mwn LBMYxWYhGTsLScssJC2zkLQsYGRZxchRWpxalptuZLCJERhPxyTYdHcw7nlpeYhRgINRiYdX YQtLiBBrYllxZe4hRmkOFiVx3lm184KFBNITS1KzU1MLUovii0pzUosPMTJxcEo1ME460siq 8d5sXa/I9sKDLIldPnETA5pfxaZ/CePoYO87v/6JiMs9tkUHd8YcZ/a+6m0f3cv3bV8v19R1 +pyrVstf7oxMWrLXZdL179fbkpujX5v3yCx5ZzF5qjPDnZzSD033VteevOW6RTbVg1vopd3t 0HsbnjeH/YhX9u+1fX77jHaWfI1LhxJLcUaioRZzUXEiAPSy9qGIAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/idr/UIEECYNNQT3sSl_kxexoiUg7yyk Cc: "idr@ietf.org" , "'John G. Scudder'" , Susan Hares Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-ietf-idr-ls-distribut-impl X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 12:00:07 -0000 Hi Hannes, On #1 =3D=3D> Sure. Delay could be from Update generation not on transmission= . Though it's one hop from RR to Controller it's hop-by-hop= till that point to the IGP on RR! In general, TE Metric extensions on LS could very sensiti= ve to this delay (link delay/bandwidth).=20 Some generic comment on this would be useful for future r= eaders. #2 =3D=3D> So it's on IGP folk who are proposing extensions - may = be a note would be good here too on what kind of changes you are seeking/in= terested. Thx. =20 -- Uma C. -----Original Message----- From: Hannes Gredler [mailto:hannes@juniper.net]=20 Sent: Monday, September 01, 2014 11:05 AM To: Uma Chunduri Cc: Susan Hares; idr@ietf.org; 'John G. Scudder' Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-ietf-= idr-ls-distribut-impl hi uma, see comments/responses inline: On Wed, Aug 27, 2014 at 11:07:01AM +0000, Uma Chunduri wrote: | Support. |=20 | I see, hierarchy is WELL defined when multiple instances of IGP with | multiple AFs are running. Good work. |=20 |=20 |=20 | Have following Qs: |=20 | 1. Any discussion of the delay introduced by BGP (packing, updat= e | generation, processing etc..) to transport the LS information |=20 | especially, when LSDB is changing faster perhaps with large number of | nodes/links inside an AS and with multiple ASes) to the controller wil= l be | useful. this is highly implementation dependent; - some vendors do the packaging of= BGP updates entirely event-driven and others pack things up and have a wor= st case delay between the trigger event and the BGP update. the protocol it= self does not prohibit/limit the propagation speed. (in fact it can be shown that sometimes updates travel faster on the (datap= lane forwarded) iBGP mesh, rather than propgate using the hop-by-hop contro= l-plane flooding protocol) | A note on the sensitivity of this delay to the consumer | (applications) at the controller can be helpful. I saw very little | discussion in Section 6 (6.1.5) difficiult - its hard to have some sort of general comment as things are hi= ghly implementation dependent. | 2. This document encompasses pretty much both OSPF and ISIS | extensions done till date. How it will keep up with future extensions = in | OSPF/ISIS. we have set up an IANA registries for the carriers of information. it is expected by authors of "topological relevant" IGP extensions to suppl= y also BGP-LS extensions. | A mechanism in place would be helpful. My suggestion would be- the | respective IGP documents should assess the impact and define |=20 | corresponding new TLVs for BGP LS? But how this can be enforced? i have no idea - today its entirely voluntary. | 3. Section 4, gives glimpse what's possible and the node aggrega= ting | the links obviously need to tinker the LSDB to represent the same | correctly. |=20 | Some more details would be helpful to represent the changes on | aggregation/de-aggregation subsequently. this may quickly get you into the "abstracted topology models" discussion that keeps emerging periodically. - we did not want to stop pro= gress on the protocol by arguing "whats the right abstraction model" and ha= ve agreed on the minimalistic nature of the section as-is. | 4. Section 6.2 has empty sub-sections and TBDs. right ... so suggest to remove section 6.2 altogether. | 5. It's good to see Implementation report shed light on performa= nce | seen with multiple ASes. |=20 | 6. It's good to see if any application of policy on LSDB is done | (one of the primary drivers of the specification). thanks, /hannes |=20 | From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares | Sent: Tuesday, August 26, 2014 11:37 AM | To: idr@ietf.org | Cc: 'John G. Scudder'; shares@ndzh.com | Subject: [Idr] WG LC for draft-ietf-idr-ls-distribution and | draft-ietf-idr-ls-distribut-impl |=20 |=20 |=20 | This is a WG LC for |=20 |=20 |=20 | =20 | [1]http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/ |=20 | =20 | [2]http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution-impl | / |=20 |=20 |=20 | Please respond with comments and "support or no support." This WG LC = also | includes a request for the authors to provide IPR on the subject. |=20 |=20 |=20 | Please note: due to the European vacations in August, we are bundling | these three reviews into the next two weeks (these two drafts and | draft-ietf-as-migration). The chairs would like feedback (list or | private email) whether the three WG LC s impact anyone's ability to re= view | these drafts carefully. |=20 |=20 |=20 | Thank you, |=20 |=20 |=20 | Sue Hares and John Scudder |=20 | References |=20 | Visible links | 1. http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/ | 2.=20 | http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution-impl/ | _______________________________________________ | Idr mailing list | Idr@ietf.org | https://www.ietf.org/mailman/listinfo/idr From nobody Tue Sep 2 05:57:15 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71C3A1A030B; Tue, 2 Sep 2014 05:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.081 X-Spam-Level: * X-Spam-Status: No, score=1.081 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wm4CHU_ZpYxP; Tue, 2 Sep 2014 05:57:06 -0700 (PDT) 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 931061A02FC; Tue, 2 Sep 2014 05:57:05 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BMA66191; Tue, 02 Sep 2014 12:57:04 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 2 Sep 2014 13:57:03 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.209]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Tue, 2 Sep 2014 20:56:53 +0800 From: Haoweiguo To: "stephane.litkowski@orange.com" , "UTTARO, JAMES" , "'idr@ietf.org'" , "'l2vpn@ietf.org'" Thread-Topic: New Version Notification for draft-hao-idr-flowspec-evpn-00.txt Thread-Index: AQHPvAyV6atOnhH9DE6j9dLImcRrM5vYoV9zgADsHqCAAMQoQIAB9eqQgAF7eR6ADczLAIAAqdxw//+4+oCAAeojsA== Date: Tue, 2 Sep 2014 12:56:53 +0000 Message-ID: References: <20140820002030.18902.50278.idtracker@ietfa.amsl.com> , , <29476_1408695761_53F6FDD1_29476_12929_1_9E32478DFA9976438E7A22F69B08FF9207DB14@OPEXCLILM34.corporate.adroot.infra.ftgroup> , <28799_1409563679_54043C1F_28799_2589_1_9E32478DFA9976438E7A22F69B08FF92080C92@OPEXCLILM34.corporate.adroot.infra.ftgroup> , <25521_1409584904_54048F08_25521_750_1_9E32478DFA9976438E7A22F69B08FF920810A4@OPEXCLILM34.corporate.adroot.infra.ftgroup> In-Reply-To: <25521_1409584904_54048F08_25521_750_1_9E32478DFA9976438E7A22F69B08FF920810A4@OPEXCLILM34.corporate.adroot.infra.ftgroup> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.23.94] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/idr/rCi8pvMZ9gksXr0udgknJ_SUPTM Cc: liuweihang Subject: [Idr] =?gb2312?b?tPC4tDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBk?= =?gb2312?b?cmFmdC1oYW8taWRyLWZsb3dzcGVjLWV2cG4tMDAudHh0?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 12:57:09 -0000 SGkgU3RlcGhhbmUsDQpQbHMgc2VlIGlubGluZSB3aXRoIFt3ZWlndW8zXS4NClRoYW5rcw0Kd2Vp Z3VvDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCreivP7Iyzog c3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb20gW3N0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2Uu Y29tXQ0Kt6LLzcqxvOQ6IDIwMTTE6jnUwjHI1SAyMzoyMQ0KytW8/sjLOiBIYW93ZWlndW87IFVU VEFSTywgSkFNRVM7ICdpZHJAaWV0Zi5vcmcnOyAnbDJ2cG5AaWV0Zi5vcmcnDQqzrcvNOiBsaXV3 ZWloYW5nDQrW98ziOiBSRTogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1oYW8t aWRyLWZsb3dzcGVjLWV2cG4tMDAudHh0DQoNClt3ZWlndW8yXTogSSBrbm93IHdoYXQgeW91IHNh aWQuIFllcywgSW4gSVJCIHNjZW5hcmlvLCBub3Qgb25seSBldGhlcm5ldCBoZWFkZXIgYnV0IGFs c28gSVAgaGVhZGVyIGNhbiBiZSB1c2VkIGZvciB0cmFmZmljIGZpbHRlcmluZy4gIEkgdGhpbmsg b3VyIGRyYWZ0IGNhbiBjb3ZlciB0aGlzIHNjZW5hcmlvLiBJbiB0aGUgZHJhZnQsIGNvbXBvbmVu dCB0eXBlcyBpbmNsdWRlIGJvdGggSVAgYW5kIGV0aGVybmV0IHBhcnQsIElQIGNvbXBvbmVudCB0 eXBlcyBhcmUgaW5oZXJpdGVkIGZyb20gUkZDWzU1NzVdLCBNQUMgY29tcG9uZXQgdHlwZXMgYXJl IG5ld2x5IGRlZmluZWQuIFNvIG9ubHkgb25lIGFkZHJlc3MgZmFtaWx5IGlzIG5lZWRlZCBmb3Ig SVAgYW5kIEV0aGVybmV0IHRyYWZmaWMgZmlsdGVyaW5nLg0KDQpbU0xJXSBSaWdodCwgdGhhdCdz IG9uZSBwb3NzaWJpbGl0eSwgdGhlIG90aGVyIG9uZSBjb3VsZCBiZSB0byBub3QgY3JlYXRlIGEg bmV3IEFGIGZvciBNQUMgRlMgYnV0IGp1c3QgZXh0ZW5kIHRoZSBjdXJyZW50IEZTIGFkZHJlc3Mt ZmFtaWxpZXMgKFZQTiBhbmQgbm9uIFZQTikgd2l0aCBNQUMgY29tcG9uZW50IHR5cGVzIGFuZCBu ZXcgYWN0aW9ucy4NClRoZSBtYWluIHF1ZXN0aW9uIGluIHRlcm0gb2YgcHJvdG9jb2wgZGVzaWdu IGlzIHRvIHdlIHdhbnQgdG8ga2VlcCBmaWx0ZXJpbmcgQUYgYWdub3N0aWMgKHNpbmdsZSBGUyBB RiBmb3IgYWxsIHR5cGUgb2YgZmxvd3MpIG9yIGRvIHdlIG5lZWQgdG8ga2VlcCBzZXBhcmF0ZSBG UyBBRnMgPw0KVGhlIHdheSB0YWtlbiBmb3IgdGhlIG1vbWVudCBpcyB0byBoYXZlIHNlcGFyYXRl IG9uZXMsIHdlIGNhbiBzZWUgdGhhdCBJUHY2IEZTIGlzIGN1cnJlbnRseSBkZWZpbmVkIGFzIGEg bmV3IGNvdXBsZSBvZiBBRkkvU0FGSSBidXQgaXMgaXQgdGhlIGdvb2Qgd2F5IHRvIGRvID8gSSBk b24ndCByZW1lbWJlciBpZiB0aGlzIGhhcyBiZWVuIGRpc2N1c3NlZCBvciBub3Qgd2hlbiBkZWZp bmluZyBGUyBJUHY2ID8NCkknbSB3b25kZXJpbmcgaWYgd2UgY2Fubm90IG1ha2UgRmxvd1NwZWMg d29ya2luZyBhcyBJUEZJWCBmb3IgdGhlIGZsb3cgZGVmaW5pdGlvbi4NCg0KW3dlaWd1bzNdOlll cywgaWYgYXBwbGljYXRpb24gUlQgbGlrZSBMMlZQTiBhbmQgTDNWUE4gUlQgZG9uJ3Qgb3Zlcmxh cCwgdGhlb3JldGljYWxseSBzaW5nbGUgRlMgQUYgY2FuIGJlIHVzZWQgZm9yIGFsbCB0eXBlIG9m IGZsb3dzLkJ1dCBpZiB3ZSBrZWVwIHNlcGFyYXRlIEZTIEFGcywgaXQgd2lsbCBtb3JlIHNpbWls YXIgdG8gdHJhZGl0b25hbCBCR1AgZGVzaWduIHN0eWxlIGFuZCBubyBleHRyYSBwcm9ibGVtcyB3 aWxsIGJlIGluY3VycmVkLiBXaGV0aGVyIHVzaW5nIHNpbmdsZSBBRiBvciBzZXBhcmF0ZSBBRnMs IGkgd291bGQgbGlrZSB0byBoZWFyIHRoZSBXRydzIG9waW5pb24uDQoNCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IEhhb3dlaWd1byBbbWFpbHRvOmhhb3dlaWd1b0BodWF3ZWku Y29tXQ0KU2VudDogTW9uZGF5LCBTZXB0ZW1iZXIgMDEsIDIwMTQgMTM6NTENClRvOiBMSVRLT1dT S0kgU3RlcGhhbmUgU0NFL0lCTkY7IFVUVEFSTywgSkFNRVM7ICdpZHJAaWV0Zi5vcmcnOyAnbDJ2 cG5AaWV0Zi5vcmcnDQpDYzogbGl1d2VpaGFuZw0KU3ViamVjdDogtPC4tDogTmV3IFZlcnNpb24g Tm90aWZpY2F0aW9uIGZvciBkcmFmdC1oYW8taWRyLWZsb3dzcGVjLWV2cG4tMDAudHh0DQoNCkhp IFN0ZXBoYW5lLA0KUGxzIHNlZSBteSByZXBseSBpbmxpbmUgd2l0aCBbd2VpZ3VvMl0gYmVsb3cu DQpUaGFua3MNCndlaWd1bw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQq3orz+yMs6IHN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tIFtzdGVwaGFuZS5saXRr b3dza2lAb3JhbmdlLmNvbV0NCreiy83KsbzkOiAyMDE0xOo51MIxyNUgMTc6MjcNCsrVvP7Iyzog SGFvd2VpZ3VvOyBVVFRBUk8sIEpBTUVTOyAnaWRyQGlldGYub3JnJzsgJ2wydnBuQGlldGYub3Jn Jw0Ks63LzTogbGl1d2VpaGFuZw0K1vfM4jogUkU6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBm b3IgZHJhZnQtaGFvLWlkci1mbG93c3BlYy1ldnBuLTAwLnR4dA0KDQpbd2VpZ3VvXTogVGhhbmtz LiBCdXQgTUFDIGZpbHRlcnMgbWF5YmUgbm90IGFwcGxpY2FibGUgdG8gSVBWNCAmVlBOdjQsIGJl Y2F1c2UgaW4gdGhpcyBjYXNlLCBNQUMgaW5mb3JtYXRpb24gd2lsbCBiZSBjaGFuZ2VkIG9uIGRp ZmZlcmVudCBQRSBkZXZpY2VzLCBhIHNpbmdsZSBBQ0wgcnVsZSBjYW4ndCBpZGVudGlmeSBhIGNv bnNpc3RhbnQgZmxvdyBhdCBkaWZmZXJlbnQgUEUgZGV2aWNlcy4gU28gaW4gSVAgbmV0d29yaywg Zmxvdy1zcGVjIGNhbiBvbmx5IGJlIGRlZmluZWQgdXNpbmcgSVAgcmVsYXRlZCBpbmZvcm1hdGlv bi4NCltTTEldIEkgYWdyZWUgd2l0aCB5b3VyIHBvaW50IGJ1dCBJIHdhcyB0aGlua2luZyBhYm91 dCBhIGZ1dHVyZSAoaG9wZSBpdCB3aWxsIGhhcHBlbiA6KSB3aGVuIHdlIHdpbGwgYmUgYWJsZSB0 byBvZmZlciBMMiBhbmQgTDMgc2VydmljZXMgb24gdGhlIHNhbWUgcGx1ZyAoaW5jbHVkaW5nIHNh bWUgVkxBTiwgc29ydCBvZiBjb25jdXJyZW50IHJvdXRpbmcgJiBicmlkZ2luZyBpbnRlcmZhY2Up LiBJbiB0aGlzIHNpdHVhdGlvbiwgaXMgaXQgZ29vZCB0byB1c2UgdHdvIGFkZHJlc3MgZmFtaWxp ZXMgdG8gZmlsdGVyIHRoZSBkaWZmZXJlbnQgc2VydmljZXMgPyBXaHkgbm90IHVzaW5nIG9ubHkg b25lIC4uLg0KDQpbd2VpZ3VvMl06IEkga25vdyB3aGF0IHlvdSBzYWlkLiBZZXMsIEluIElSQiBz Y2VuYXJpbywgbm90IG9ubHkgZXRoZXJuZXQgaGVhZGVyIGJ1dCBhbHNvIElQIGhlYWRlciBjYW4g YmUgdXNlZCBmb3IgdHJhZmZpYyBmaWx0ZXJpbmcuICBJIHRoaW5rIG91ciBkcmFmdCBjYW4gY292 ZXIgdGhpcyBzY2VuYXJpby4gSW4gdGhlIGRyYWZ0LCBjb21wb25lbnQgdHlwZXMgaW5jbHVkZSBi b3RoIElQIGFuZCBldGhlcm5ldCBwYXJ0LCBJUCBjb21wb25lbnQgdHlwZXMgYXJlIGluaGVyaXRl ZCBmcm9tIFJGQ1s1NTc1XSwgTUFDIGNvbXBvbmV0IHR5cGVzIGFyZSBuZXdseSBkZWZpbmVkLiBT byBvbmx5IG9uZSBhZGRyZXNzIGZhbWlseSBpcyBuZWVkZWQgZm9yIElQIGFuZCBFdGhlcm5ldCB0 cmFmZmljIGZpbHRlcmluZy4NCg0KW3dlaWd1b106IFJEIHVzYWdlIGhhcyBubyBkaWZmZXJlbmNl IHdpdGggb3JpZ2luYWwgQkdQIFZQTiBkZWZpbmljYXRpb24uIENhbiB5b3UgZ2l2ZSBtZSBzb21l IG1vcmUgY2xhcmlmaWNhdGlvbnM/DQpbU0xJXSBSaWdodCwgYnV0IFJGQzU1NzUgcHJlY2lzZXMg dGhhdCBSRCBpcyBwYXJ0IG9mIE5MUkkgZm9yIFZQTiA6DQoiVGhlIE5MUkkgZm9ybWF0IGZvciB0 aGlzIGFkZHJlc3MgZmFtaWx5IGNvbnNpc3RzIG9mIGEgZml4ZWQtbGVuZ3RoDQogICBSb3V0ZSBE aXN0aW5ndWlzaGVyIGZpZWxkICg4IGJ5dGVzKSBmb2xsb3dlZCBieSBhIGZsb3cgc3BlY2lmaWNh dGlvbiwNCiAgIGZvbGxvd2luZyB0aGUgZW5jb2RpbmcgZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50 LiAgVGhlIE5MUkkgbGVuZ3RoDQogICBmaWVsZCBzaGFsbCBpbmNsdWRlIGJvdGggdGhlIDggYnl0 ZXMgb2YgdGhlIFJvdXRlIERpc3Rpbmd1aXNoZXIgYXMNCiAgIHdlbGwgYXMgdGhlIHN1YnNlcXVl bnQgZmxvdyBzcGVjaWZpY2F0aW9uLg0KIg0KSW4geW91ciBkb2N1bWVudCAsIEkgY2FuJ3Qgc2Vl IHRoaXMgLi4uIGFzIHlvdSBhcmUgZGVmaW5pbmcgYSBuZXcgTkxSSSwgeW91IG5lZWQgdG8gcHJl Y2lzZSB0aGUgZm9ybWF0Lg0KDQpbd2VpZ3VvMl06IE9LLiBJbiBvdXIgZHJhZnQsIHRoZSBmb3Jt YXQgaXMgc2FtZSB3aXRoIFJGQzU1NzUsIEkgY2FuIGFkZCB0aGUgc2FtZSBkZXNjcmlwdGlvbiB0 byBtYWtlIGl0IG1vcmUgY2xlYXIuDQoNCg0KU3RlcGhhbmUNCg0KDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBIYW93ZWlndW8gW21haWx0bzpoYW93ZWlndW9AaHVhd2VpLmNv bV0NClNlbnQ6IFNhdHVyZGF5LCBBdWd1c3QgMjMsIDIwMTQgMDk6MDgNClRvOiBMSVRLT1dTS0kg U3RlcGhhbmUgU0NFL0lCTkY7IFVUVEFSTywgSkFNRVM7ICdpZHJAaWV0Zi5vcmcnOyAnbDJ2cG5A aWV0Zi5vcmcnDQpDYzogbGl1d2VpaGFuZw0KU3ViamVjdDogtPC4tDogTmV3IFZlcnNpb24gTm90 aWZpY2F0aW9uIGZvciBkcmFmdC1oYW8taWRyLWZsb3dzcGVjLWV2cG4tMDAudHh0DQoNCkhpIFN0 ZXBoYW5lLA0KVGhhbmtzIGZvciB5b3VyIGRldGFpbCBjb21tZW50cy4gUGxzIHNlZSBteSByZXBs eSBpbmxpbmUgd2l0aCBbd2VpZ3VvXSBiZWxvdy4NCndlaWd1bw0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6IHN0ZXBoYW5lLmxpdGtvd3NraUBvcmFu Z2UuY29tIFtzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbV0NCreiy83KsbzkOiAyMDE0xOo4 1MIyMsjVIDE2OjIyDQrK1bz+yMs6IEhhb3dlaWd1bzsgVVRUQVJPLCBKQU1FUzsgJ2lkckBpZXRm Lm9yZyc7ICdsMnZwbkBpZXRmLm9yZycNCrOty806IGxpdXdlaWhhbmcNCtb3zOI6IFJFOiBOZXcg VmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWhhby1pZHItZmxvd3NwZWMtZXZwbi0wMC50 eHQNCg0KSGksDQoNCkkgdGhpbmsgdGhpcyBpcyBhIHZhbHVhYmxlIGFkZGl0aW9uLCBidXQgSSB3 b3VsZCBsaWtlIHRvIHNlZSB0aGVzZSBNQUMgZmlsdGVycyBiZWluZyBhcHBsaWNhYmxlIGFsc28g dG8gSVB2NCBwbHVncyAoRlMgSVB2NCAmIFZQTnY0KQ0KW3dlaWd1b106IFRoYW5rcy4gQnV0IE1B QyBmaWx0ZXJzIG1heWJlIG5vdCBhcHBsaWNhYmxlIHRvIElQVjQgJlZQTnY0LCBiZWNhdXNlIGlu IHRoaXMgY2FzZSwgTUFDIGluZm9ybWF0aW9uIHdpbGwgYmUgY2hhbmdlZCBvbiBkaWZmZXJlbnQg UEUgZGV2aWNlcywgYSBzaW5nbGUgQUNMIHJ1bGUgY2FuJ3QgaWRlbnRpZnkgYSBjb25zaXN0YW50 IGZsb3cgYXQgZGlmZmVyZW50IFBFIGRldmljZXMuIFNvIGluIElQIG5ldHdvcmssIGZsb3ctc3Bl YyBjYW4gb25seSBiZSBkZWZpbmVkIHVzaW5nIElQIHJlbGF0ZWQgaW5mb3JtYXRpb24uDQoNCk1v cmVvdmVyICwgdGhlIG5ldyBBRkkvU0FGSSBzaG91bGQgbm90IGJlIHJlc3RyaWN0ZWQgdG8gRVZQ TiwgYW55IEwyIGludGVyZmFjZSBtYXkgYmUgaW50ZXJlc3RlZCBieSBzdWNoIGZpbHRlciAoVlBM UywgYmFzaWMgTDIgc3dpdGNoaW5nIC4uLikuDQpbd2VpZ3VvXTogWWVzLCBJIGFncmVlLiBGaXJz dGx5IGkgcHJvcG9zZSBFdGhlcm5ldCBmbG93LXNwZWMgb25seSBpbiBFVlBOIG5ldHdvcmssIGJl Y2F1c2UgZmxvd3MtcGVjIHJlbGllcyBvbiBCR1AgcHJvdG9jb2wgYW5kIEVWUE4gaGFzIEJHUCBj b250cm9sIHBsYW5lLCBzbyBpdCB3aWxsIGJlIGVhc3kgdG8gZGVwbG95IEJHUCBmbG93c3BlYyBp biBFVlBOIG5ldHdvcmsuIElmIHdlIHdhbnQgdG8gZGVwbG95IHRoZSBmbG93LXNwZWMgaW4gVlBM UyBuZXR3b3JrLCBub3JtYWxseSBWUExTIG9ubHkgcmVsaWVzIG9uIExEUCBwcm90b2NvbCwgYWRk aXRpb25hbCBwcm90b2NvbCBvZiBCR1AgZmxvdy1zcGVjIHNob3VsZCBiZSBkZXBsb3llZCBmb3Ig TUFDIGZpbHRlcmluZy4NCklmIHRoZSBjb21tdW5pdHkgdGhpbmtzIGl0IGlzIG5lY2Vzc2FyeSB0 byBpbnRyb2R1Y2UgZXRoZXJuZXQgZmxvdy1zcGVjIGZvciBhbGwgTDIgaW50ZXJmYWNlLCBpIGNh biB1cGRhdGUgdGhpcyBwYXJ0IHRvIGxldCBpdCBub3QgYmUgcmVzdHJpY3RlZCB0byBFVlBOLg0K DQpSb3V0ZSBkaXN0aW5ndWlzaGVyIG1heSBiZSBpcyBtaXNzaW5nIC4uLg0KW3dlaWd1b106IFJE IHVzYWdlIGhhcyBubyBkaWZmZXJlbmNlIHdpdGggb3JpZ2luYWwgQkdQIFZQTiBkZWZpbmljYXRp b24uIENhbiB5b3UgZ2l2ZSBtZSBzb21lIG1vcmUgY2xhcmlmaWNhdGlvbnM/DQoNCk5vdyBtb3Jl IGdsb2JhbGx5LCBtYXkgYmUgaXQncyB0aW1lIHRvIHRoaW5rIG1vcmUgZ2xvYmFsbHkgYWJvdXQg dGhlIGV2b2x1dGlvbiBvZiBGUy4gSSBwcmV0dHkgc2VlIEZTIGV2b2x1dGlvbiBsYXJnZWx5IGJl eW9uZCBERG9TIGRvbWFpbi4gRlMgaXMgYSB2ZXJ5IGdvb2QgcHJvdG9jb2wgZm9yIFNETiBhcHBs aWNhdGlvbnMuIFRoZSBxdWVzdGlvbiBiZWhpbmQgaXMgZG8gd2UgcmVhbGx5IG5lZWQgdG8gd29y ayB3aXRoIG11bHRpcGxlIGFkZHJlc3MgZmFtaWxpZXMgZm9yIGVhY2ggdHlwZSBvZiAic2Vydmlj ZSIvImludGVyZmFjZSB0eXBlIiB0byBmaWx0ZXIgb3IgZG8gd2UgbmVlZCB0byBoYXZlIGEgbW9y ZSBnbG9iYWwgbW9kZWwgd2hlcmUgd2Ugd291bGQgYmUgYWJsZSB0byBwdXQgYW55IHR5cGUgb2Yg ZmlsdGVyIGFueSB3aGVyZSBhbmQgYXBwbHkgbXVsdGlwbGUgYWN0aW9ucyAob3BlbmZsb3cgbGlr ZSBGUykuIENvbXBhcmVkIHRvIG9wZW5mbG93LCBGUyBoYXMgdGhlIG1hZ2ljIHRvIGVuYWJsZSBt dWx0aXBvaW50IGRpc3RyaWJ1dGlvbiBvZiBhY3Rpb25zLg0KDQpbd2VpZ3VvXTogWWVzLCBCR1Ag Zmxvdy1zcGVjIGNhbiBiZSBhcHBsaWNhYmxlIGZvciBzb21lIFNETiBhcHBsaWNhdGlvbnMuIEl0 IGhhcyBtb3JlIHBvdGVudGlhbCB0byBkbyBtb3JlIGF0dGFjdGl2ZSB0aGluZ3MuDQoNCkJlc3Qg UmVnYXJkcywNCg0KU3RlcGhhbmUNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv bTogSWRyIFttYWlsdG86aWRyLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBIYW93ZWln dW8NClNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMjEsIDIwMTQgMDQ6MTENClRvOiBVVFRBUk8sIEpB TUVTOyAnaWRyQGlldGYub3JnJzsgJ2wydnBuQGlldGYub3JnJw0KQ2M6IGxpdXdlaWhhbmcNClN1 YmplY3Q6IFtJZHJdILTwuLQ6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaGFv LWlkci1mbG93c3BlYy1ldnBuLTAwLnR4dA0KDQpIaSBKaW0sDQpUaGFua3MgZm9yIHlvdXIgY29t bWVudHMuIFRoZSBCR1AgRmxvd3NwZWMgcHJvY2VkdXJlcyBpcyBpbGx1c3RyYXRlZCBhcyBmb2xs b3dpbmc6DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEVWUE4g Rmxvd1NwZWMgU2Vzc2lvbiAgICAgICAgICAgICAgICAgIEVWUE4gRmxvd1NwZWMgU2Vzc2lvbg0K RERPUyBEZXRlY3Rpb24gQXBwbGlhbmNlLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS1FZ3Jlc3Mg UEUtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLUluZ3Jlc3MgUEUtLS0tLS1DRTINCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBDRTEgRERPUyBEZXRlY3Rpb24gQXBwbGlhbmNlIGVzdGFibGlzaGVzIEVWUE4gZmxvd3NwZWMg c2Vzc2lvbiB3aXRoIEVncmVzcyBQRSwgaXQgZGV0ZWN0cyBERE9TIGF0dGFjayB0cmFmZmljIGFu ZCBnZW5lcmF0ZSBBQ0wgcnVsZSwgdGhlIEFDTCBydWxlIGlzIGFubm91bmNlZCB0byBFZ3Jlc3Mg UEUgdGhyb3VnaCBFVlBOIGZsb3dzcGVjIHByb3RvY29sLCB0aGVuIHRoZSBlZ3Jlc3MgUEUgYW5u b3VuY2VzIGl0IHRvIGluZ3Jlc3MgUEUsIGZpbmFsbHkgaW5ncmVzcyBQRSBpbnN0YWxscyB0aGUg QUNMIHJ1bGUgZm9yIHRyYWZmaWMgZmlsdGVyaW5nLg0KRERPUyBEZXRlY3Rpb24gQXBwbGlhbmNl IG9ubHkgbmVlZHMgdG8gc3VwcG9ydCBFVlBOIGZsb3dzcGVjIGZ1bmN0aW9uLCBpdCBkb2Vzbid0 IG5lZWQgdG8gc3VwcG9ydCBiYXNpYyBFVlBOIGZ1bmN0aW9uLg0KVGhhbmtzDQp3ZWlndW8NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCreivP7IyzogVVRUQVJPLCBK QU1FUyBbanUxNzM4QGF0dC5jb21dDQq3osvNyrG85DogMjAxNMTqONTCMjHI1SAwOjI5DQrK1bz+ yMs6IEhhb3dlaWd1bzsgJ2lkckBpZXRmLm9yZyc7ICdsMnZwbkBpZXRmLm9yZycNCrOty806IGxp dXdlaWhhbmcNCtb3zOI6IFJFOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWhh by1pZHItZmxvd3NwZWMtZXZwbi0wMC50eHQNCg0KV2VpZ3VvLA0KDQogICAgICAgIEkgd291bGQg bGlrZSB0byBiZXR0ZXIgdW5kZXJzdGFuZCBob3cgYSByZW1vdGUgUEUgd2lsbCAibGVhcm4iIHRo YXQgaXQgbmVlZHMgdG8gZGVsaXZlciBhIEZTIHBhdGggdG8gdGhlIGluZ3Jlc3MgUEU/PyBJdCBj YW5ub3QgY29tZSBmcm9tIHRoZSBDRSBhcyB0aGF0IGlzIGRhdGEgcGxhbmUgbGVhcm5pbmcuIEkg d291bGQgdGhpbmsgdGhhdCBhbGwgRlMgcGF0aHMgaGF2ZSB0byBiZSBkaXNzZW1pbmF0ZWQgYnkg YSBjZW50cmFsaXplZCBjb250cm9sbGVyLg0KDQpKaW0gVXR0YXJvDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBJZHIgW21haWx0bzppZHItYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIEhhb3dlaWd1bw0KU2VudDogVHVlc2RheSwgQXVndXN0IDE5LCAyMDE0IDg6MzEg UE0NClRvOiBpZHJAaWV0Zi5vcmc7IGwydnBuQGlldGYub3JnDQpDYzogbGl1d2VpaGFuZw0KU3Vi amVjdDogW0lkcl0gtPC4tDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1oYW8t aWRyLWZsb3dzcGVjLWV2cG4tMDAudHh0DQoNCkhpIEFsbCwNCldlIGhhdmUgc3VibWl0dGVkIGEg ZHJhZnQgb2YgIiBEaXNzZW1pbmF0aW9uIG9mIEZsb3cgU3BlY2lmaWNhdGlvbiBSdWxlcyBmb3Ig RVZQTiIuICBJIHdpbGwgYXBwcmljaWF0ZSBpZiB5b3UgY2FuIGdpdmUgdXMgc29tZSBzdWdnZXN0 aW9ucyBhbmQgY29tbWVudHMuDQpUaGFua3MNCndlaWd1bw0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBb aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0Kt6LLzcqxvOQ6IDIwMTTE6jjUwjIwyNUgODoyMA0K ytW8/sjLOiBaaHVhbmdzaHVud2FuOyBIYW93ZWlndW87IGxpdXdlaWhhbmc7IFpodWFuZ3NodW53 YW47IGxpdXdlaWhhbmc7IEhhb3dlaWd1bw0K1vfM4jogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9u IGZvciBkcmFmdC1oYW8taWRyLWZsb3dzcGVjLWV2cG4tMDAudHh0DQoNCkEgbmV3IHZlcnNpb24g b2YgSS1ELCBkcmFmdC1oYW8taWRyLWZsb3dzcGVjLWV2cG4tMDAudHh0DQpoYXMgYmVlbiBzdWNj ZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFdlaWd1byBIYW8gYW5kIHBvc3RlZCB0byB0aGUgSUVURiBy ZXBvc2l0b3J5Lg0KDQpOYW1lOiAgICAgICAgICAgZHJhZnQtaGFvLWlkci1mbG93c3BlYy1ldnBu DQpSZXZpc2lvbjogICAgICAgMDANClRpdGxlOiAgICAgICAgICBEaXNzZW1pbmF0aW9uIG9mIEZs b3cgU3BlY2lmaWNhdGlvbiBSdWxlcyBmb3IgRVZQTg0KRG9jdW1lbnQgZGF0ZTogIDIwMTQtMDgt MjANCkdyb3VwOiAgICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOiAgICAgICAg ICA3DQpVUkw6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv ZHJhZnQtaGFvLWlkci1mbG93c3BlYy1ldnBuLTAwLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWhhby1pZHItZmxvd3NwZWMtZXZwbi8N Ckh0bWxpemVkOiAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1oYW8taWRy LWZsb3dzcGVjLWV2cG4tMDANCg0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5l cyBCR1AgZmxvdy1zcGVjIGV4dGVuc2lvbiBmb3IgRXRoZXJuZXQgdHJhZmZpYw0KICAgZmlsdGVy aW5nIGluIEVWUE4gbmV0d29yay4gQSBuZXcgQkdQIE5MUkkgdHlwZSAoQUZJPTI1LCBTQUZJPVRC RCkNCiAgIHZhbHVlIGlzIHByb3Bvc2VkIHRvIGlkZW50aWZ5IEVWUE4gZmxvdy1zcGVjIGFwcGxp Y2F0aW9uLiBBIG5ldw0KICAgc3Vic2V0IG9mIGNvbXBvbmVudCB0eXBlcyBhbmQgZXh0ZW5kZWQg Y29tbXVuaXR5IGFsc28gYXJlIGRlZmluZWQuDQoNCg0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQg bWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24g dW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29s cy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJZHIgbWFpbGluZyBsaXN0DQpJZHJAaWV0Zi5v cmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRyDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSWRyIG1haWxpbmcgbGlzdA0K SWRyQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkcg0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQoNCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29u dGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0 IG5lIGRvaXZlbnQgZG9uYyBwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBz YW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVy LCB2ZXVpbGxleiBsZSBzaWduYWxlciBhIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5z aSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFu dCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLCBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25z YWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4g TWVyY2kuDQoNClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNv bmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3Rl ZCBieSBsYXc7IHRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQg d2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBp biBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdl IGFuZCBpdHMgYXR0YWNobWVudHMuDQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBp cyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdl ZCBvciBmYWxzaWZpZWQuDQpUaGFuayB5b3UuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KQ2UgbWVzc2FnZSBldCBz ZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZp ZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jIHBhcyBldHJlIGRp ZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2 ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyIGEgbCdl eHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExl cyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24s IE9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUg YWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCg0KVGhpcyBtZXNzYWdlIGFuZCBp dHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5m b3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsgdGhleSBzaG91bGQgbm90IGJl IGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQpJZiB5 b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBz ZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCkFzIGVt YWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRo YXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NClRoYW5rIHlvdS4N Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KDQpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNv bnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBl dCBuZSBkb2l2ZW50IGRvbmMNCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVz IHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJl dXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyDQphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBh aW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBl dGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLA0KT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVz cG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lm aWUuIE1lcmNpLg0KDQpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFp biBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90 ZWN0ZWQgYnkgbGF3Ow0KdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNv cGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVt YWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1l c3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3Jh bmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBj aGFuZ2VkIG9yIGZhbHNpZmllZC4NClRoYW5rIHlvdS4= From nobody Tue Sep 2 06:21:16 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 688B81A026F; Tue, 2 Sep 2014 06:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.719 X-Spam-Level: X-Spam-Status: No, score=-12.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hXmUARQ0il4g; Tue, 2 Sep 2014 06:21:08 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25CB21A031F; Tue, 2 Sep 2014 06:20:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20892; q=dns/txt; s=iport; t=1409664027; x=1410873627; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Eder2vyzH8RLkn9EmccQFhzvUC0k2KEp5Adz+PTdpEY=; b=dHKvxfdNvUOuUhpqMJThudHiJ0I2QhfoM9cgDXukvhKkoTuG6I2eQwy5 C1WLP7ajM3iOOpOvK9OmINXkZIIyAxoeb/VMzVHS3Q367aun3queYVoum 5dz758XuxBK5lubbIcD3wEv81kHJQblaVzVnoNbwX2jDfmJhCC/5B5Or9 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AigFAB/DBVStJA2B/2dsb2JhbABPCoMNU1cEgnjFDwqHTAEZdxZ3hAMBAQEEAQEBMTkBCQIMBAIBBgIRBAEBBQYdBQICJQsUCQgCBAENBQgBCweIJw2JH5w3CJRdAReBKIhYhGsGBQYBHw8HGwcGgm86gR0BBIYUix2ELohYk0OBZwgWgVxsAYEGCBcigQcBAQE X-IronPort-AV: E=Sophos;i="5.04,449,1406592000"; d="scan'208";a="74225459" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-4.cisco.com with ESMTP; 02 Sep 2014 13:20:26 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s82DKPAw030313 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Sep 2014 13:20:25 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.41]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Tue, 2 Sep 2014 08:20:25 -0500 From: "Bertrand Duvivier (bduvivie)" To: Haoweiguo , "stephane.litkowski@orange.com" , "UTTARO, JAMES" , "'idr@ietf.org'" , "'l2vpn@ietf.org'" , "Keyur Patel (keyupate)" Thread-Topic: New Version Notification for draft-hao-idr-flowspec-evpn-00.txt Thread-Index: AQHPxq15MTiaKxqdokC+l/dROzU6aJvtz64w Date: Tue, 2 Sep 2014 13:20:24 +0000 Message-ID: <5F1FD493E541C642ABBC18EDC327C82F1FECE5CF@xmb-aln-x11.cisco.com> References: <20140820002030.18902.50278.idtracker@ietfa.amsl.com> , , <29476_1408695761_53F6FDD1_29476_12929_1_9E32478DFA9976438E7A22F69B08FF9207DB14@OPEXCLILM34.corporate.adroot.infra.ftgroup> , <28799_1409563679_54043C1F_28799_2589_1_9E32478DFA9976438E7A22F69B08FF92080C92@OPEXCLILM34.corporate.adroot.infra.ftgroup> , <25521_1409584904_54048F08_25521_750_1_9E32478DFA9976438E7A22F69B08FF920810A4@OPEXCLILM34.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.113.243] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/cNJVKdlpxEd-fYHt8KP09RPWM4U Cc: liuweihang Subject: Re: [Idr] New Version Notification for draft-hao-idr-flowspec-evpn-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 13:21:11 -0000 SGkgV2FpZ3VvLA0KDQoxLiBFVlBOIGFzIGRlZmluZWQgdG9kYXkgY291bGQgYmUgdXNlZCB0byBz aWduYWwgSVAgb25seSwgTUFDIG9ubHkgb3IgYm90aCB0aHVzIGl0J3Mgbm8gbG9uZ2VyIGp1c3Qg YSBMMlZQTiBvbmx5IHNvbHV0aW9uIGJ1dCBMMlZQTiBhbmQvb3IgTDNWUE4gc29sdXRpb24sIHRo dXMgSSB0aGluayB3ZSBzaG91bGQgc3RheSB3aXRoIGV4aXN0aW5nIFNBRkkgMTM0IGZvciBFVlBO Lg0KDQoyLiBXaGF0IHdlIG5lZWQgaXMgdG8gaGF2ZSBuZXdlciBCR1AgRlMgdHlwZSB0byBtYWN0 aCBvbiBmb3IgTDIsIGFuZCBmb3IgdGhpcyB3ZSBoYXZlIDIgb3B0aW9ucw0KCUE+IGNyZWF0ZSBu ZXdlciBCR1AgRlMgdHlwZSBjb2RlIHBvaW50LCBhbmQgSSBzdWdnZXN0IHRvIGxpbWl0IGl0IGlm IHdlIG5lZWQgdG8gZGVmaW5lIGEgcmFuZ2Ugb2YgdmFsdWUNCglCPiBSZXVzZSB3aGF0IGhhdmUg YmVlbiBhbHJlYWR5IGRlZmluZWQgaW4gSVBGSVggZW5jb2RpbmcgKGZvciBzaW5nbGUgdmFsdWUg bGlrZSBNQUMpDQoNCkFzc3VtaW5nIElBTkEgZGVmaW5lIEJHUCBGUyB0eXBlIHZhbHVlIDI1NSA9 IElQRklYIGVuY29kaW5nIA0KDQpUaGVuIHRvIG1hY3RoIG9uIFNvdXJjZSBNYWMgMDAwYy4xMjM0 LjU2Nzggd2Ugd2lsbCBoYXZlIGZvbGxvd2luZyBlbmNvZGluZyAgDQpCR1AgRlMgdHlwZSA9IDI1 NSAJCSMgSVBGSVggZW5jb2RpbmcNCklQIEZJWCB0eXBlID0gNTYJCQkjIFNvdXJjZU1hY0FkZHJl c3MNCklQIEZJWCB2YWx1ZSA9IDAwMGMuMTIzNC41Njc4CSMgTWFjIFZhbHVlDQoNCklQRklYIGVu Y29kaW5nIGlzIHF1aXRlIHJpY2ggYWxyZWFkeQ0KaHR0cDovL3d3dy5pYW5hLm9yZy9hc3NpZ25t ZW50cy9pcGZpeC9pcGZpeC54aHRtbA0KDQpCZXN0IFJlZ2FyZHMgQmVydHJhbmQgRHV2aXZpZXIN CklQIHJvdXRpbmcgUHJvZHVjdCBNYW5hZ2VyDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IElkciBbbWFpbHRvOmlkci1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg SGFvd2VpZ3VvDQpTZW50OiBtYXJkaSAyIHNlcHRlbWJyZSAyMDE0IDE0OjU3DQpUbzogc3RlcGhh bmUubGl0a293c2tpQG9yYW5nZS5jb207IFVUVEFSTywgSkFNRVM7ICdpZHJAaWV0Zi5vcmcnOyAn bDJ2cG5AaWV0Zi5vcmcnDQpDYzogbGl1d2VpaGFuZw0KU3ViamVjdDogW0lkcl0gtPC4tDogTmV3 IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1oYW8taWRyLWZsb3dzcGVjLWV2cG4tMDAu dHh0DQoNCkhpIFN0ZXBoYW5lLA0KUGxzIHNlZSBpbmxpbmUgd2l0aCBbd2VpZ3VvM10uDQpUaGFu a3MNCndlaWd1bw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQq3 orz+yMs6IHN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tIFtzdGVwaGFuZS5saXRrb3dza2lA b3JhbmdlLmNvbV0NCreiy83KsbzkOiAyMDE0xOo51MIxyNUgMjM6MjENCsrVvP7IyzogSGFvd2Vp Z3VvOyBVVFRBUk8sIEpBTUVTOyAnaWRyQGlldGYub3JnJzsgJ2wydnBuQGlldGYub3JnJw0Ks63L zTogbGl1d2VpaGFuZw0K1vfM4jogUkU6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJh ZnQtaGFvLWlkci1mbG93c3BlYy1ldnBuLTAwLnR4dA0KDQpbd2VpZ3VvMl06IEkga25vdyB3aGF0 IHlvdSBzYWlkLiBZZXMsIEluIElSQiBzY2VuYXJpbywgbm90IG9ubHkgZXRoZXJuZXQgaGVhZGVy IGJ1dCBhbHNvIElQIGhlYWRlciBjYW4gYmUgdXNlZCBmb3IgdHJhZmZpYyBmaWx0ZXJpbmcuICBJ IHRoaW5rIG91ciBkcmFmdCBjYW4gY292ZXIgdGhpcyBzY2VuYXJpby4gSW4gdGhlIGRyYWZ0LCBj b21wb25lbnQgdHlwZXMgaW5jbHVkZSBib3RoIElQIGFuZCBldGhlcm5ldCBwYXJ0LCBJUCBjb21w b25lbnQgdHlwZXMgYXJlIGluaGVyaXRlZCBmcm9tIFJGQ1s1NTc1XSwgTUFDIGNvbXBvbmV0IHR5 cGVzIGFyZSBuZXdseSBkZWZpbmVkLiBTbyBvbmx5IG9uZSBhZGRyZXNzIGZhbWlseSBpcyBuZWVk ZWQgZm9yIElQIGFuZCBFdGhlcm5ldCB0cmFmZmljIGZpbHRlcmluZy4NCg0KW1NMSV0gUmlnaHQs IHRoYXQncyBvbmUgcG9zc2liaWxpdHksIHRoZSBvdGhlciBvbmUgY291bGQgYmUgdG8gbm90IGNy ZWF0ZSBhIG5ldyBBRiBmb3IgTUFDIEZTIGJ1dCBqdXN0IGV4dGVuZCB0aGUgY3VycmVudCBGUyBh ZGRyZXNzLWZhbWlsaWVzIChWUE4gYW5kIG5vbiBWUE4pIHdpdGggTUFDIGNvbXBvbmVudCB0eXBl cyBhbmQgbmV3IGFjdGlvbnMuDQpUaGUgbWFpbiBxdWVzdGlvbiBpbiB0ZXJtIG9mIHByb3RvY29s IGRlc2lnbiBpcyB0byB3ZSB3YW50IHRvIGtlZXAgZmlsdGVyaW5nIEFGIGFnbm9zdGljIChzaW5n bGUgRlMgQUYgZm9yIGFsbCB0eXBlIG9mIGZsb3dzKSBvciBkbyB3ZSBuZWVkIHRvIGtlZXAgc2Vw YXJhdGUgRlMgQUZzID8NClRoZSB3YXkgdGFrZW4gZm9yIHRoZSBtb21lbnQgaXMgdG8gaGF2ZSBz ZXBhcmF0ZSBvbmVzLCB3ZSBjYW4gc2VlIHRoYXQgSVB2NiBGUyBpcyBjdXJyZW50bHkgZGVmaW5l ZCBhcyBhIG5ldyBjb3VwbGUgb2YgQUZJL1NBRkkgYnV0IGlzIGl0IHRoZSBnb29kIHdheSB0byBk byA/IEkgZG9uJ3QgcmVtZW1iZXIgaWYgdGhpcyBoYXMgYmVlbiBkaXNjdXNzZWQgb3Igbm90IHdo ZW4gZGVmaW5pbmcgRlMgSVB2NiA/DQpJJ20gd29uZGVyaW5nIGlmIHdlIGNhbm5vdCBtYWtlIEZs b3dTcGVjIHdvcmtpbmcgYXMgSVBGSVggZm9yIHRoZSBmbG93IGRlZmluaXRpb24uDQoNClt3ZWln dW8zXTpZZXMsIGlmIGFwcGxpY2F0aW9uIFJUIGxpa2UgTDJWUE4gYW5kIEwzVlBOIFJUIGRvbid0 IG92ZXJsYXAsIHRoZW9yZXRpY2FsbHkgc2luZ2xlIEZTIEFGIGNhbiBiZSB1c2VkIGZvciBhbGwg dHlwZSBvZiBmbG93cy5CdXQgaWYgd2Uga2VlcCBzZXBhcmF0ZSBGUyBBRnMsIGl0IHdpbGwgbW9y ZSBzaW1pbGFyIHRvIHRyYWRpdG9uYWwgQkdQIGRlc2lnbiBzdHlsZSBhbmQgbm8gZXh0cmEgcHJv YmxlbXMgd2lsbCBiZSBpbmN1cnJlZC4gV2hldGhlciB1c2luZyBzaW5nbGUgQUYgb3Igc2VwYXJh dGUgQUZzLCBpIHdvdWxkIGxpa2UgdG8gaGVhciB0aGUgV0cncyBvcGluaW9uLg0KDQoNCi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBIYW93ZWlndW8gW21haWx0bzpoYW93ZWlndW9A aHVhd2VpLmNvbV0NClNlbnQ6IE1vbmRheSwgU2VwdGVtYmVyIDAxLCAyMDE0IDEzOjUxDQpUbzog TElUS09XU0tJIFN0ZXBoYW5lIFNDRS9JQk5GOyBVVFRBUk8sIEpBTUVTOyAnaWRyQGlldGYub3Jn JzsgJ2wydnBuQGlldGYub3JnJw0KQ2M6IGxpdXdlaWhhbmcNClN1YmplY3Q6ILTwuLQ6IE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaGFvLWlkci1mbG93c3BlYy1ldnBuLTAwLnR4 dA0KDQpIaSBTdGVwaGFuZSwNClBscyBzZWUgbXkgcmVwbHkgaW5saW5lIHdpdGggW3dlaWd1bzJd IGJlbG93Lg0KVGhhbmtzDQp3ZWlndW8NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0Kt6K8/sjLOiBzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbSBbc3RlcGhh bmUubGl0a293c2tpQG9yYW5nZS5jb21dDQq3osvNyrG85DogMjAxNMTqOdTCMcjVIDE3OjI3DQrK 1bz+yMs6IEhhb3dlaWd1bzsgVVRUQVJPLCBKQU1FUzsgJ2lkckBpZXRmLm9yZyc7ICdsMnZwbkBp ZXRmLm9yZycNCrOty806IGxpdXdlaWhhbmcNCtb3zOI6IFJFOiBOZXcgVmVyc2lvbiBOb3RpZmlj YXRpb24gZm9yIGRyYWZ0LWhhby1pZHItZmxvd3NwZWMtZXZwbi0wMC50eHQNCg0KW3dlaWd1b106 IFRoYW5rcy4gQnV0IE1BQyBmaWx0ZXJzIG1heWJlIG5vdCBhcHBsaWNhYmxlIHRvIElQVjQgJlZQ TnY0LCBiZWNhdXNlIGluIHRoaXMgY2FzZSwgTUFDIGluZm9ybWF0aW9uIHdpbGwgYmUgY2hhbmdl ZCBvbiBkaWZmZXJlbnQgUEUgZGV2aWNlcywgYSBzaW5nbGUgQUNMIHJ1bGUgY2FuJ3QgaWRlbnRp ZnkgYSBjb25zaXN0YW50IGZsb3cgYXQgZGlmZmVyZW50IFBFIGRldmljZXMuIFNvIGluIElQIG5l dHdvcmssIGZsb3ctc3BlYyBjYW4gb25seSBiZSBkZWZpbmVkIHVzaW5nIElQIHJlbGF0ZWQgaW5m b3JtYXRpb24uDQpbU0xJXSBJIGFncmVlIHdpdGggeW91ciBwb2ludCBidXQgSSB3YXMgdGhpbmtp bmcgYWJvdXQgYSBmdXR1cmUgKGhvcGUgaXQgd2lsbCBoYXBwZW4gOikgd2hlbiB3ZSB3aWxsIGJl IGFibGUgdG8gb2ZmZXIgTDIgYW5kIEwzIHNlcnZpY2VzIG9uIHRoZSBzYW1lIHBsdWcgKGluY2x1 ZGluZyBzYW1lIFZMQU4sIHNvcnQgb2YgY29uY3VycmVudCByb3V0aW5nICYgYnJpZGdpbmcgaW50 ZXJmYWNlKS4gSW4gdGhpcyBzaXR1YXRpb24sIGlzIGl0IGdvb2QgdG8gdXNlIHR3byBhZGRyZXNz IGZhbWlsaWVzIHRvIGZpbHRlciB0aGUgZGlmZmVyZW50IHNlcnZpY2VzID8gV2h5IG5vdCB1c2lu ZyBvbmx5IG9uZSAuLi4NCg0KW3dlaWd1bzJdOiBJIGtub3cgd2hhdCB5b3Ugc2FpZC4gWWVzLCBJ biBJUkIgc2NlbmFyaW8sIG5vdCBvbmx5IGV0aGVybmV0IGhlYWRlciBidXQgYWxzbyBJUCBoZWFk ZXIgY2FuIGJlIHVzZWQgZm9yIHRyYWZmaWMgZmlsdGVyaW5nLiAgSSB0aGluayBvdXIgZHJhZnQg Y2FuIGNvdmVyIHRoaXMgc2NlbmFyaW8uIEluIHRoZSBkcmFmdCwgY29tcG9uZW50IHR5cGVzIGlu Y2x1ZGUgYm90aCBJUCBhbmQgZXRoZXJuZXQgcGFydCwgSVAgY29tcG9uZW50IHR5cGVzIGFyZSBp bmhlcml0ZWQgZnJvbSBSRkNbNTU3NV0sIE1BQyBjb21wb25ldCB0eXBlcyBhcmUgbmV3bHkgZGVm aW5lZC4gU28gb25seSBvbmUgYWRkcmVzcyBmYW1pbHkgaXMgbmVlZGVkIGZvciBJUCBhbmQgRXRo ZXJuZXQgdHJhZmZpYyBmaWx0ZXJpbmcuDQoNClt3ZWlndW9dOiBSRCB1c2FnZSBoYXMgbm8gZGlm ZmVyZW5jZSB3aXRoIG9yaWdpbmFsIEJHUCBWUE4gZGVmaW5pY2F0aW9uLiBDYW4geW91IGdpdmUg bWUgc29tZSBtb3JlIGNsYXJpZmljYXRpb25zPw0KW1NMSV0gUmlnaHQsIGJ1dCBSRkM1NTc1IHBy ZWNpc2VzIHRoYXQgUkQgaXMgcGFydCBvZiBOTFJJIGZvciBWUE4gOg0KIlRoZSBOTFJJIGZvcm1h dCBmb3IgdGhpcyBhZGRyZXNzIGZhbWlseSBjb25zaXN0cyBvZiBhIGZpeGVkLWxlbmd0aA0KICAg Um91dGUgRGlzdGluZ3Vpc2hlciBmaWVsZCAoOCBieXRlcykgZm9sbG93ZWQgYnkgYSBmbG93IHNw ZWNpZmljYXRpb24sDQogICBmb2xsb3dpbmcgdGhlIGVuY29kaW5nIGRlZmluZWQgaW4gdGhpcyBk b2N1bWVudC4gIFRoZSBOTFJJIGxlbmd0aA0KICAgZmllbGQgc2hhbGwgaW5jbHVkZSBib3RoIHRo ZSA4IGJ5dGVzIG9mIHRoZSBSb3V0ZSBEaXN0aW5ndWlzaGVyIGFzDQogICB3ZWxsIGFzIHRoZSBz dWJzZXF1ZW50IGZsb3cgc3BlY2lmaWNhdGlvbi4NCiINCkluIHlvdXIgZG9jdW1lbnQgLCBJIGNh bid0IHNlZSB0aGlzIC4uLiBhcyB5b3UgYXJlIGRlZmluaW5nIGEgbmV3IE5MUkksIHlvdSBuZWVk IHRvIHByZWNpc2UgdGhlIGZvcm1hdC4NCg0KW3dlaWd1bzJdOiBPSy4gSW4gb3VyIGRyYWZ0LCB0 aGUgZm9ybWF0IGlzIHNhbWUgd2l0aCBSRkM1NTc1LCBJIGNhbiBhZGQgdGhlIHNhbWUgZGVzY3Jp cHRpb24gdG8gbWFrZSBpdCBtb3JlIGNsZWFyLg0KDQoNClN0ZXBoYW5lDQoNCg0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSGFvd2VpZ3VvIFttYWlsdG86aGFvd2VpZ3VvQGh1 YXdlaS5jb21dDQpTZW50OiBTYXR1cmRheSwgQXVndXN0IDIzLCAyMDE0IDA5OjA4DQpUbzogTElU S09XU0tJIFN0ZXBoYW5lIFNDRS9JQk5GOyBVVFRBUk8sIEpBTUVTOyAnaWRyQGlldGYub3JnJzsg J2wydnBuQGlldGYub3JnJw0KQ2M6IGxpdXdlaWhhbmcNClN1YmplY3Q6ILTwuLQ6IE5ldyBWZXJz aW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaGFvLWlkci1mbG93c3BlYy1ldnBuLTAwLnR4dA0K DQpIaSBTdGVwaGFuZSwNClRoYW5rcyBmb3IgeW91ciBkZXRhaWwgY29tbWVudHMuIFBscyBzZWUg bXkgcmVwbHkgaW5saW5lIHdpdGggW3dlaWd1b10gYmVsb3cuDQp3ZWlndW8NCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kt6K8/sjLOiBzdGVwaGFuZS5saXRrb3dz a2lAb3JhbmdlLmNvbSBbc3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb21dDQq3osvNyrG85Dog MjAxNMTqONTCMjLI1SAxNjoyMg0KytW8/sjLOiBIYW93ZWlndW87IFVUVEFSTywgSkFNRVM7ICdp ZHJAaWV0Zi5vcmcnOyAnbDJ2cG5AaWV0Zi5vcmcnDQqzrcvNOiBsaXV3ZWloYW5nDQrW98ziOiBS RTogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1oYW8taWRyLWZsb3dzcGVjLWV2 cG4tMDAudHh0DQoNCkhpLA0KDQpJIHRoaW5rIHRoaXMgaXMgYSB2YWx1YWJsZSBhZGRpdGlvbiwg YnV0IEkgd291bGQgbGlrZSB0byBzZWUgdGhlc2UgTUFDIGZpbHRlcnMgYmVpbmcgYXBwbGljYWJs ZSBhbHNvIHRvIElQdjQgcGx1Z3MgKEZTIElQdjQgJiBWUE52NCkNClt3ZWlndW9dOiBUaGFua3Mu IEJ1dCBNQUMgZmlsdGVycyBtYXliZSBub3QgYXBwbGljYWJsZSB0byBJUFY0ICZWUE52NCwgYmVj YXVzZSBpbiB0aGlzIGNhc2UsIE1BQyBpbmZvcm1hdGlvbiB3aWxsIGJlIGNoYW5nZWQgb24gZGlm ZmVyZW50IFBFIGRldmljZXMsIGEgc2luZ2xlIEFDTCBydWxlIGNhbid0IGlkZW50aWZ5IGEgY29u c2lzdGFudCBmbG93IGF0IGRpZmZlcmVudCBQRSBkZXZpY2VzLiBTbyBpbiBJUCBuZXR3b3JrLCBm bG93LXNwZWMgY2FuIG9ubHkgYmUgZGVmaW5lZCB1c2luZyBJUCByZWxhdGVkIGluZm9ybWF0aW9u Lg0KDQpNb3Jlb3ZlciAsIHRoZSBuZXcgQUZJL1NBRkkgc2hvdWxkIG5vdCBiZSByZXN0cmljdGVk IHRvIEVWUE4sIGFueSBMMiBpbnRlcmZhY2UgbWF5IGJlIGludGVyZXN0ZWQgYnkgc3VjaCBmaWx0 ZXIgKFZQTFMsIGJhc2ljIEwyIHN3aXRjaGluZyAuLi4pLg0KW3dlaWd1b106IFllcywgSSBhZ3Jl ZS4gRmlyc3RseSBpIHByb3Bvc2UgRXRoZXJuZXQgZmxvdy1zcGVjIG9ubHkgaW4gRVZQTiBuZXR3 b3JrLCBiZWNhdXNlIGZsb3dzLXBlYyByZWxpZXMgb24gQkdQIHByb3RvY29sIGFuZCBFVlBOIGhh cyBCR1AgY29udHJvbCBwbGFuZSwgc28gaXQgd2lsbCBiZSBlYXN5IHRvIGRlcGxveSBCR1AgZmxv d3NwZWMgaW4gRVZQTiBuZXR3b3JrLiBJZiB3ZSB3YW50IHRvIGRlcGxveSB0aGUgZmxvdy1zcGVj IGluIFZQTFMgbmV0d29yaywgbm9ybWFsbHkgVlBMUyBvbmx5IHJlbGllcyBvbiBMRFAgcHJvdG9j b2wsIGFkZGl0aW9uYWwgcHJvdG9jb2wgb2YgQkdQIGZsb3ctc3BlYyBzaG91bGQgYmUgZGVwbG95 ZWQgZm9yIE1BQyBmaWx0ZXJpbmcuDQpJZiB0aGUgY29tbXVuaXR5IHRoaW5rcyBpdCBpcyBuZWNl c3NhcnkgdG8gaW50cm9kdWNlIGV0aGVybmV0IGZsb3ctc3BlYyBmb3IgYWxsIEwyIGludGVyZmFj ZSwgaSBjYW4gdXBkYXRlIHRoaXMgcGFydCB0byBsZXQgaXQgbm90IGJlIHJlc3RyaWN0ZWQgdG8g RVZQTi4NCg0KUm91dGUgZGlzdGluZ3Vpc2hlciBtYXkgYmUgaXMgbWlzc2luZyAuLi4NClt3ZWln dW9dOiBSRCB1c2FnZSBoYXMgbm8gZGlmZmVyZW5jZSB3aXRoIG9yaWdpbmFsIEJHUCBWUE4gZGVm aW5pY2F0aW9uLiBDYW4geW91IGdpdmUgbWUgc29tZSBtb3JlIGNsYXJpZmljYXRpb25zPw0KDQpO b3cgbW9yZSBnbG9iYWxseSwgbWF5IGJlIGl0J3MgdGltZSB0byB0aGluayBtb3JlIGdsb2JhbGx5 IGFib3V0IHRoZSBldm9sdXRpb24gb2YgRlMuIEkgcHJldHR5IHNlZSBGUyBldm9sdXRpb24gbGFy Z2VseSBiZXlvbmQgRERvUyBkb21haW4uIEZTIGlzIGEgdmVyeSBnb29kIHByb3RvY29sIGZvciBT RE4gYXBwbGljYXRpb25zLiBUaGUgcXVlc3Rpb24gYmVoaW5kIGlzIGRvIHdlIHJlYWxseSBuZWVk IHRvIHdvcmsgd2l0aCBtdWx0aXBsZSBhZGRyZXNzIGZhbWlsaWVzIGZvciBlYWNoIHR5cGUgb2Yg InNlcnZpY2UiLyJpbnRlcmZhY2UgdHlwZSIgdG8gZmlsdGVyIG9yIGRvIHdlIG5lZWQgdG8gaGF2 ZSBhIG1vcmUgZ2xvYmFsIG1vZGVsIHdoZXJlIHdlIHdvdWxkIGJlIGFibGUgdG8gcHV0IGFueSB0 eXBlIG9mIGZpbHRlciBhbnkgd2hlcmUgYW5kIGFwcGx5IG11bHRpcGxlIGFjdGlvbnMgKG9wZW5m bG93IGxpa2UgRlMpLiBDb21wYXJlZCB0byBvcGVuZmxvdywgRlMgaGFzIHRoZSBtYWdpYyB0byBl bmFibGUgbXVsdGlwb2ludCBkaXN0cmlidXRpb24gb2YgYWN0aW9ucy4NCg0KW3dlaWd1b106IFll cywgQkdQIGZsb3ctc3BlYyBjYW4gYmUgYXBwbGljYWJsZSBmb3Igc29tZSBTRE4gYXBwbGljYXRp b25zLiBJdCBoYXMgbW9yZSBwb3RlbnRpYWwgdG8gZG8gbW9yZSBhdHRhY3RpdmUgdGhpbmdzLg0K DQpCZXN0IFJlZ2FyZHMsDQoNClN0ZXBoYW5lDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IElkciBbbWFpbHRvOmlkci1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg SGFvd2VpZ3VvDQpTZW50OiBUaHVyc2RheSwgQXVndXN0IDIxLCAyMDE0IDA0OjExDQpUbzogVVRU QVJPLCBKQU1FUzsgJ2lkckBpZXRmLm9yZyc7ICdsMnZwbkBpZXRmLm9yZycNCkNjOiBsaXV3ZWlo YW5nDQpTdWJqZWN0OiBbSWRyXSC08Li0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRy YWZ0LWhhby1pZHItZmxvd3NwZWMtZXZwbi0wMC50eHQNCg0KSGkgSmltLA0KVGhhbmtzIGZvciB5 b3VyIGNvbW1lbnRzLiBUaGUgQkdQIEZsb3dzcGVjIHByb2NlZHVyZXMgaXMgaWxsdXN0cmF0ZWQg YXMgZm9sbG93aW5nOg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBFVlBOIEZsb3dTcGVjIFNlc3Npb24gICAgICAgICAgICAgICAgICBFVlBOIEZsb3dTcGVjIFNl c3Npb24NCkRET1MgRGV0ZWN0aW9uIEFwcGxpYW5jZS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t RWdyZXNzIFBFLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS1JbmdyZXNzIFBFLS0tLS0tQ0Uy DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgQ0UxIERET1MgRGV0ZWN0aW9uIEFwcGxpYW5jZSBlc3RhYmxpc2hlcyBFVlBOIGZs b3dzcGVjIHNlc3Npb24gd2l0aCBFZ3Jlc3MgUEUsIGl0IGRldGVjdHMgRERPUyBhdHRhY2sgdHJh ZmZpYyBhbmQgZ2VuZXJhdGUgQUNMIHJ1bGUsIHRoZSBBQ0wgcnVsZSBpcyBhbm5vdW5jZWQgdG8g RWdyZXNzIFBFIHRocm91Z2ggRVZQTiBmbG93c3BlYyBwcm90b2NvbCwgdGhlbiB0aGUgZWdyZXNz IFBFIGFubm91bmNlcyBpdCB0byBpbmdyZXNzIFBFLCBmaW5hbGx5IGluZ3Jlc3MgUEUgaW5zdGFs bHMgdGhlIEFDTCBydWxlIGZvciB0cmFmZmljIGZpbHRlcmluZy4NCkRET1MgRGV0ZWN0aW9uIEFw cGxpYW5jZSBvbmx5IG5lZWRzIHRvIHN1cHBvcnQgRVZQTiBmbG93c3BlYyBmdW5jdGlvbiwgaXQg ZG9lc24ndCBuZWVkIHRvIHN1cHBvcnQgYmFzaWMgRVZQTiBmdW5jdGlvbi4NClRoYW5rcw0Kd2Vp Z3VvDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6IFVU VEFSTywgSkFNRVMgW2p1MTczOEBhdHQuY29tXQ0Kt6LLzcqxvOQ6IDIwMTTE6jjUwjIxyNUgMDoy OQ0KytW8/sjLOiBIYW93ZWlndW87ICdpZHJAaWV0Zi5vcmcnOyAnbDJ2cG5AaWV0Zi5vcmcnDQqz rcvNOiBsaXV3ZWloYW5nDQrW98ziOiBSRTogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBk cmFmdC1oYW8taWRyLWZsb3dzcGVjLWV2cG4tMDAudHh0DQoNCldlaWd1bywNCg0KICAgICAgICBJ IHdvdWxkIGxpa2UgdG8gYmV0dGVyIHVuZGVyc3RhbmQgaG93IGEgcmVtb3RlIFBFIHdpbGwgImxl YXJuIiB0aGF0IGl0IG5lZWRzIHRvIGRlbGl2ZXIgYSBGUyBwYXRoIHRvIHRoZSBpbmdyZXNzIFBF Pz8gSXQgY2Fubm90IGNvbWUgZnJvbSB0aGUgQ0UgYXMgdGhhdCBpcyBkYXRhIHBsYW5lIGxlYXJu aW5nLiBJIHdvdWxkIHRoaW5rIHRoYXQgYWxsIEZTIHBhdGhzIGhhdmUgdG8gYmUgZGlzc2VtaW5h dGVkIGJ5IGEgY2VudHJhbGl6ZWQgY29udHJvbGxlci4NCg0KSmltIFV0dGFybw0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSWRyIFttYWlsdG86aWRyLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBIYW93ZWlndW8NClNlbnQ6IFR1ZXNkYXksIEF1Z3VzdCAxOSwgMjAx NCA4OjMxIFBNDQpUbzogaWRyQGlldGYub3JnOyBsMnZwbkBpZXRmLm9yZw0KQ2M6IGxpdXdlaWhh bmcNClN1YmplY3Q6IFtJZHJdILTwuLQ6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJh ZnQtaGFvLWlkci1mbG93c3BlYy1ldnBuLTAwLnR4dA0KDQpIaSBBbGwsDQpXZSBoYXZlIHN1Ym1p dHRlZCBhIGRyYWZ0IG9mICIgRGlzc2VtaW5hdGlvbiBvZiBGbG93IFNwZWNpZmljYXRpb24gUnVs ZXMgZm9yIEVWUE4iLiAgSSB3aWxsIGFwcHJpY2lhdGUgaWYgeW91IGNhbiBnaXZlIHVzIHNvbWUg c3VnZ2VzdGlvbnMgYW5kIGNvbW1lbnRzLg0KVGhhbmtzDQp3ZWlndW8NCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kt6K8/sjLOiBpbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmcgW2ludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10NCreiy83KsbzkOiAyMDE0xOo41MIyMMjV IDg6MjANCsrVvP7IyzogWmh1YW5nc2h1bndhbjsgSGFvd2VpZ3VvOyBsaXV3ZWloYW5nOyBaaHVh bmdzaHVud2FuOyBsaXV3ZWloYW5nOyBIYW93ZWlndW8NCtb3zOI6IE5ldyBWZXJzaW9uIE5vdGlm aWNhdGlvbiBmb3IgZHJhZnQtaGFvLWlkci1mbG93c3BlYy1ldnBuLTAwLnR4dA0KDQpBIG5ldyB2 ZXJzaW9uIG9mIEktRCwgZHJhZnQtaGFvLWlkci1mbG93c3BlYy1ldnBuLTAwLnR4dA0KaGFzIGJl ZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBXZWlndW8gSGFvIGFuZCBwb3N0ZWQgdG8gdGhl IElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZTogICAgICAgICAgIGRyYWZ0LWhhby1pZHItZmxvd3Nw ZWMtZXZwbg0KUmV2aXNpb246ICAgICAgIDAwDQpUaXRsZTogICAgICAgICAgRGlzc2VtaW5hdGlv biBvZiBGbG93IFNwZWNpZmljYXRpb24gUnVsZXMgZm9yIEVWUE4NCkRvY3VtZW50IGRhdGU6ICAy MDE0LTA4LTIwDQpHcm91cDogICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczog ICAgICAgICAgNw0KVVJMOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzL2RyYWZ0LWhhby1pZHItZmxvd3NwZWMtZXZwbi0wMC50eHQNClN0YXR1czogICAgICAg ICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1oYW8taWRyLWZsb3dzcGVj LWV2cG4vDQpIdG1saXplZDogICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aGFvLWlkci1mbG93c3BlYy1ldnBuLTAwDQoNCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50 IGRlZmluZXMgQkdQIGZsb3ctc3BlYyBleHRlbnNpb24gZm9yIEV0aGVybmV0IHRyYWZmaWMNCiAg IGZpbHRlcmluZyBpbiBFVlBOIG5ldHdvcmsuIEEgbmV3IEJHUCBOTFJJIHR5cGUgKEFGST0yNSwg U0FGST1UQkQpDQogICB2YWx1ZSBpcyBwcm9wb3NlZCB0byBpZGVudGlmeSBFVlBOIGZsb3ctc3Bl YyBhcHBsaWNhdGlvbi4gQSBuZXcNCiAgIHN1YnNldCBvZiBjb21wb25lbnQgdHlwZXMgYW5kIGV4 dGVuZGVkIGNvbW11bml0eSBhbHNvIGFyZSBkZWZpbmVkLg0KDQoNCg0KDQpQbGVhc2Ugbm90ZSB0 aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJt aXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUg YXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSWRyIG1haWxpbmcgbGlzdA0KSWRy QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkcg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklkciBtYWlsaW5n IGxpc3QNCklkckBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9pZHINCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KDQpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2 ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVn aWVlcyBldCBuZSBkb2l2ZW50IGRvbmMgcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBj b3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFy IGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIgYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVp cmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1 ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwgT3JhbmdlIGRlY2xpbmUgdG91dGUg cmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFs c2lmaWUuIE1lcmNpLg0KDQpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29u dGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBw cm90ZWN0ZWQgYnkgbGF3OyB0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3Ig Y29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMg ZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMg bWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBP cmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQs IGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KVGhhbmsgeW91Lg0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkNlIG1lc3Nh Z2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9u cyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYyBwYXMg ZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kg dm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxl ciBhIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2lu dGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRl cmF0aW9uLCBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdl IGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQoNClRoaXMgbWVzc2Fn ZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxl Z2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7IHRoZXkgc2hvdWxk IG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9u Lg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlm eSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMu DQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNz YWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQpUaGFu ayB5b3UuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCg0KQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1 dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxl Z2llZXMgZXQgbmUgZG9pdmVudCBkb25jIHBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3Ug Y29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBh ciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyIGEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1 aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlx dWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sIE9yYW5nZSBkZWNsaW5lIHRvdXRl IHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZh bHNpZmllLiBNZXJjaS4NCg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNv bnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUg cHJvdGVjdGVkIGJ5IGxhdzsgdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9y IGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlz IGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlz IG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwg T3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVk LCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NClRoYW5rIHlvdS4NCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJZHIgbWFpbGluZyBsaXN0DQpJZHJAaWV0Zi5v cmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRyDQo= From nobody Tue Sep 2 07:06:57 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE2C71A6F67; Tue, 2 Sep 2014 07:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.418 X-Spam-Level: X-Spam-Status: No, score=-2.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CTvKyw0dD0IB; Tue, 2 Sep 2014 07:06:43 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05A9F1A872E; Tue, 2 Sep 2014 07:06:42 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id 3fec5045.2b40cba38940.4793635.00-2403.13292751.nbfkord-smmo05.seg.att.com (envelope-from ); Tue, 02 Sep 2014 14:06:43 +0000 (UTC) X-MXL-Hash: 5405cef350b1450e-437d922bb40d55f05ce1b4b95b4b1431ff99a400 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id 8dec5045.0.4793351.00-2393.13291921.nbfkord-smmo05.seg.att.com (envelope-from ); Tue, 02 Sep 2014 14:06:23 +0000 (UTC) X-MXL-Hash: 5405cedf17e68e10-6a8df509ebf5aa575508a87f34de5b072bb6842d Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s82E6FW1016794; Tue, 2 Sep 2014 10:06:16 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s82E62Ea016607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Sep 2014 10:06:07 -0400 Received: from MISOUT7MSGHUBAD.ITServices.sbc.com (MISOUT7MSGHUBAD.itservices.sbc.com [130.9.129.148]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Tue, 2 Sep 2014 14:05:49 GMT Received: from MISOUT7MSGUSRCD.ITServices.sbc.com ([169.254.4.175]) by MISOUT7MSGHUBAD.ITServices.sbc.com ([130.9.129.148]) with mapi id 14.03.0195.001; Tue, 2 Sep 2014 10:05:49 -0400 From: "UTTARO, JAMES" To: "'stephane.litkowski@orange.com'" , "'Haoweiguo'" , "'idr@ietf.org'" , "'l2vpn@ietf.org'" Thread-Topic: New Version Notification for draft-hao-idr-flowspec-evpn-00.txt Thread-Index: AQHPvAyV6atOnhH9DE6j9dLImcRrM5vsDntggAByWYCAADr/gIABOfiA Date: Tue, 2 Sep 2014 14:05:49 +0000 Message-ID: References: <20140820002030.18902.50278.idtracker@ietfa.amsl.com> , , <29476_1408695761_53F6FDD1_29476_12929_1_9E32478DFA9976438E7A22F69B08FF9207DB14@OPEXCLILM34.corporate.adroot.infra.ftgroup> , <28799_1409563679_54043C1F_28799_2589_1_9E32478DFA9976438E7A22F69B08FF92080C92@OPEXCLILM34.corporate.adroot.infra.ftgroup> <25521_1409584904_54048F08_25521_750_1_9E32478DFA9976438E7A22F69B08FF920810A4@OPEXCLILM34.corporate.adroot.infra.ftgroup> In-Reply-To: <25521_1409584904_54048F08_25521_750_1_9E32478DFA9976438E7A22F69B08FF920810A4@OPEXCLILM34.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.76.224] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=DNk4FVxb c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=BkmQ29wua40A:10 a=rWzP-OcooDEA:10 a=ofMgfj31e3cA:10 a=a6l] X-AnalysisOut: [YbgGDhh4A:10 a=BLceEmwcHowA:10 a=_l4uJm6h9gAA:10 a=zQP7CpK] X-AnalysisOut: [OAAAA:8 a=XIqpo32RAAAA:8 a=z9tbli-vAAAA:8 a=48vgC7mUAAAA:8] X-AnalysisOut: [ a=i0EeH86SAAAA:8 a=_UE5Tu_C8BPtyhQDaIAA:9 a=mFyHDrcPJccA:] X-AnalysisOut: [10 a=oAXR_kdF8uMA:10 a=lZB815dzVvQA:10 a=hPjdaMEvmhQA:10 a] X-AnalysisOut: [=Hz7IrDYlS0cA:10 a=wCVxXG-rUqldA-S3:21 a=hBFWNrukdwS1x7qo:] X-AnalysisOut: [21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/idr/rAHZ_pYPk9Zay_gh0ddNazdzXFw Cc: 'liuweihang' Subject: Re: [Idr] New Version Notification for draft-hao-idr-flowspec-evpn-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 14:06:52 -0000 Q29tbWVudHMgSW4tTGluZQ0KDQpKaW0gVXR0YXJvDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbSBbbWFpbHRvOnN0ZXBoYW5l LmxpdGtvd3NraUBvcmFuZ2UuY29tXSANClNlbnQ6IE1vbmRheSwgU2VwdGVtYmVyIDAxLCAyMDE0 IDExOjIyIEFNDQpUbzogSGFvd2VpZ3VvOyBVVFRBUk8sIEpBTUVTOyAnaWRyQGlldGYub3JnJzsg J2wydnBuQGlldGYub3JnJw0KQ2M6IGxpdXdlaWhhbmcNClN1YmplY3Q6IFJFOiBOZXcgVmVyc2lv biBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWhhby1pZHItZmxvd3NwZWMtZXZwbi0wMC50eHQNCg0K W3dlaWd1bzJdOiBJIGtub3cgd2hhdCB5b3Ugc2FpZC4gWWVzLCBJbiBJUkIgc2NlbmFyaW8sIG5v dCBvbmx5IGV0aGVybmV0IGhlYWRlciBidXQgYWxzbyBJUCBoZWFkZXIgY2FuIGJlIHVzZWQgZm9y IHRyYWZmaWMgZmlsdGVyaW5nLiAgSSB0aGluayBvdXIgZHJhZnQgY2FuIGNvdmVyIHRoaXMgc2Nl bmFyaW8uIEluIHRoZSBkcmFmdCwgY29tcG9uZW50IHR5cGVzIGluY2x1ZGUgYm90aCBJUCBhbmQg ZXRoZXJuZXQgcGFydCwgSVAgY29tcG9uZW50IHR5cGVzIGFyZSBpbmhlcml0ZWQgZnJvbSBSRkNb NTU3NV0sIE1BQyBjb21wb25ldCB0eXBlcyBhcmUgbmV3bHkgZGVmaW5lZC4gU28gb25seSBvbmUg YWRkcmVzcyBmYW1pbHkgaXMgbmVlZGVkIGZvciBJUCBhbmQgRXRoZXJuZXQgdHJhZmZpYyBmaWx0 ZXJpbmcuDQoNCltTTEldIFJpZ2h0LCB0aGF0J3Mgb25lIHBvc3NpYmlsaXR5LCB0aGUgb3RoZXIg b25lIGNvdWxkIGJlIHRvIG5vdCBjcmVhdGUgYSBuZXcgQUYgZm9yIE1BQyBGUyBidXQganVzdCBl eHRlbmQgdGhlIGN1cnJlbnQgRlMgYWRkcmVzcy1mYW1pbGllcyAoVlBOIGFuZCBub24gVlBOKSB3 aXRoIE1BQyBjb21wb25lbnQgdHlwZXMgYW5kIG5ldyBhY3Rpb25zLg0KVGhlIG1haW4gcXVlc3Rp b24gaW4gdGVybSBvZiBwcm90b2NvbCBkZXNpZ24gaXMgdG8gd2Ugd2FudCB0byBrZWVwIGZpbHRl cmluZyBBRiBhZ25vc3RpYyAoc2luZ2xlIEZTIEFGIGZvciBhbGwgdHlwZSBvZiBmbG93cykgb3Ig ZG8gd2UgbmVlZCB0byBrZWVwIHNlcGFyYXRlIEZTIEFGcyA/DQpbSmltIFU+XSBUaGlzIGNvbWVz IGJhY2sgdG8gYSBtb3JlIGJhc2ljIHF1ZXN0aW9uLiBTaG91bGQgYW4gQUYgYmUgZGVmaW5lZCB0 aGF0IGNvbW11bmljYXRlcyBub24tcm91dGluZyBzdGF0ZT8gQXMgYW4gZXgsIFZQTFMgQkdQLCBG UywgUlRDIHRoZSBsaXN0IGdvZXMgb24gYXJlIGFsbCBkZWxpbmVhdGVkIGJ5IEFGLi4gQXQgc29t ZSBwb2ludCB3ZSBuZWVkIHRvIGFja25vd2xlZGdlIHRoYXQgd2UgYXJlIHVzaW5nIEJHUCBhcyBh IGdlbmVyYWwgZGlzdHJpYnV0aW9uIHByb3RvY29sIGFuZCBoYXZlIHRoZSBkZXNpZ24vc3BlYyBy ZWZsZWN0IHRoYXQuIElNTyB0aGlzIG1lYW5zIHNlcGFyYXRpbmcgYnkgY29uZmlndXJhdGlvbiB0 eXBlIG9mIGFjdGlvbnMgdGhhdCBkbyBub3QgcmVxdWlyZSBhIGdsb2JhbCBpbnZhcmlhbnQgYW5k IHJvdXRpbmcgd2hpY2ggZG9lcy4NClRoZSB3YXkgdGFrZW4gZm9yIHRoZSBtb21lbnQgaXMgdG8g aGF2ZSBzZXBhcmF0ZSBvbmVzLCB3ZSBjYW4gc2VlIHRoYXQgSVB2NiBGUyBpcyBjdXJyZW50bHkg ZGVmaW5lZCBhcyBhIG5ldyBjb3VwbGUgb2YgQUZJL1NBRkkgYnV0IGlzIGl0IHRoZSBnb29kIHdh eSB0byBkbyA/IEkgZG9uJ3QgcmVtZW1iZXIgaWYgdGhpcyBoYXMgYmVlbiBkaXNjdXNzZWQgb3Ig bm90IHdoZW4gZGVmaW5pbmcgRlMgSVB2NiA/DQpJJ20gd29uZGVyaW5nIGlmIHdlIGNhbm5vdCBt YWtlIEZsb3dTcGVjIHdvcmtpbmcgYXMgSVBGSVggZm9yIHRoZSBmbG93IGRlZmluaXRpb24uDQoN Cg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSGFvd2VpZ3VvIFttYWlsdG86 aGFvd2VpZ3VvQGh1YXdlaS5jb21dIA0KU2VudDogTW9uZGF5LCBTZXB0ZW1iZXIgMDEsIDIwMTQg MTM6NTENClRvOiBMSVRLT1dTS0kgU3RlcGhhbmUgU0NFL0lCTkY7IFVUVEFSTywgSkFNRVM7ICdp ZHJAaWV0Zi5vcmcnOyAnbDJ2cG5AaWV0Zi5vcmcnDQpDYzogbGl1d2VpaGFuZw0KU3ViamVjdDog tPC4tDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1oYW8taWRyLWZsb3dzcGVj LWV2cG4tMDAudHh0DQoNCkhpIFN0ZXBoYW5lLA0KUGxzIHNlZSBteSByZXBseSBpbmxpbmUgd2l0 aCBbd2VpZ3VvMl0gYmVsb3cuDQpUaGFua3MNCndlaWd1bw0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6IHN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2Uu Y29tIFtzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbV0NCreiy83KsbzkOiAyMDE0xOo51MIx yNUgMTc6MjcNCsrVvP7IyzogSGFvd2VpZ3VvOyBVVFRBUk8sIEpBTUVTOyAnaWRyQGlldGYub3Jn JzsgJ2wydnBuQGlldGYub3JnJw0Ks63LzTogbGl1d2VpaGFuZw0K1vfM4jogUkU6IE5ldyBWZXJz aW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaGFvLWlkci1mbG93c3BlYy1ldnBuLTAwLnR4dA0K DQpbd2VpZ3VvXTogVGhhbmtzLiBCdXQgTUFDIGZpbHRlcnMgbWF5YmUgbm90IGFwcGxpY2FibGUg dG8gSVBWNCAmVlBOdjQsIGJlY2F1c2UgaW4gdGhpcyBjYXNlLCBNQUMgaW5mb3JtYXRpb24gd2ls bCBiZSBjaGFuZ2VkIG9uIGRpZmZlcmVudCBQRSBkZXZpY2VzLCBhIHNpbmdsZSBBQ0wgcnVsZSBj YW4ndCBpZGVudGlmeSBhIGNvbnNpc3RhbnQgZmxvdyBhdCBkaWZmZXJlbnQgUEUgZGV2aWNlcy4g U28gaW4gSVAgbmV0d29yaywgZmxvdy1zcGVjIGNhbiBvbmx5IGJlIGRlZmluZWQgdXNpbmcgSVAg cmVsYXRlZCBpbmZvcm1hdGlvbi4NCltTTEldIEkgYWdyZWUgd2l0aCB5b3VyIHBvaW50IGJ1dCBJ IHdhcyB0aGlua2luZyBhYm91dCBhIGZ1dHVyZSAoaG9wZSBpdCB3aWxsIGhhcHBlbiA6KSB3aGVu IHdlIHdpbGwgYmUgYWJsZSB0byBvZmZlciBMMiBhbmQgTDMgc2VydmljZXMgb24gdGhlIHNhbWUg cGx1ZyAoaW5jbHVkaW5nIHNhbWUgVkxBTiwgc29ydCBvZiBjb25jdXJyZW50IHJvdXRpbmcgJiBi cmlkZ2luZyBpbnRlcmZhY2UpLiBJbiB0aGlzIHNpdHVhdGlvbiwgaXMgaXQgZ29vZCB0byB1c2Ug dHdvIGFkZHJlc3MgZmFtaWxpZXMgdG8gZmlsdGVyIHRoZSBkaWZmZXJlbnQgc2VydmljZXMgPyBX aHkgbm90IHVzaW5nIG9ubHkgb25lIC4uLg0KDQpbd2VpZ3VvMl06IEkga25vdyB3aGF0IHlvdSBz YWlkLiBZZXMsIEluIElSQiBzY2VuYXJpbywgbm90IG9ubHkgZXRoZXJuZXQgaGVhZGVyIGJ1dCBh bHNvIElQIGhlYWRlciBjYW4gYmUgdXNlZCBmb3IgdHJhZmZpYyBmaWx0ZXJpbmcuICBJIHRoaW5r IG91ciBkcmFmdCBjYW4gY292ZXIgdGhpcyBzY2VuYXJpby4gSW4gdGhlIGRyYWZ0LCBjb21wb25l bnQgdHlwZXMgaW5jbHVkZSBib3RoIElQIGFuZCBldGhlcm5ldCBwYXJ0LCBJUCBjb21wb25lbnQg dHlwZXMgYXJlIGluaGVyaXRlZCBmcm9tIFJGQ1s1NTc1XSwgTUFDIGNvbXBvbmV0IHR5cGVzIGFy ZSBuZXdseSBkZWZpbmVkLiBTbyBvbmx5IG9uZSBhZGRyZXNzIGZhbWlseSBpcyBuZWVkZWQgZm9y IElQIGFuZCBFdGhlcm5ldCB0cmFmZmljIGZpbHRlcmluZy4NCg0KW3dlaWd1b106IFJEIHVzYWdl IGhhcyBubyBkaWZmZXJlbmNlIHdpdGggb3JpZ2luYWwgQkdQIFZQTiBkZWZpbmljYXRpb24uIENh biB5b3UgZ2l2ZSBtZSBzb21lIG1vcmUgY2xhcmlmaWNhdGlvbnM/DQpbU0xJXSBSaWdodCwgYnV0 IFJGQzU1NzUgcHJlY2lzZXMgdGhhdCBSRCBpcyBwYXJ0IG9mIE5MUkkgZm9yIFZQTiA6DQoiVGhl IE5MUkkgZm9ybWF0IGZvciB0aGlzIGFkZHJlc3MgZmFtaWx5IGNvbnNpc3RzIG9mIGEgZml4ZWQt bGVuZ3RoDQogICBSb3V0ZSBEaXN0aW5ndWlzaGVyIGZpZWxkICg4IGJ5dGVzKSBmb2xsb3dlZCBi eSBhIGZsb3cgc3BlY2lmaWNhdGlvbiwNCiAgIGZvbGxvd2luZyB0aGUgZW5jb2RpbmcgZGVmaW5l ZCBpbiB0aGlzIGRvY3VtZW50LiAgVGhlIE5MUkkgbGVuZ3RoDQogICBmaWVsZCBzaGFsbCBpbmNs dWRlIGJvdGggdGhlIDggYnl0ZXMgb2YgdGhlIFJvdXRlIERpc3Rpbmd1aXNoZXIgYXMNCiAgIHdl bGwgYXMgdGhlIHN1YnNlcXVlbnQgZmxvdyBzcGVjaWZpY2F0aW9uLg0KIg0KSW4geW91ciBkb2N1 bWVudCAsIEkgY2FuJ3Qgc2VlIHRoaXMgLi4uIGFzIHlvdSBhcmUgZGVmaW5pbmcgYSBuZXcgTkxS SSwgeW91IG5lZWQgdG8gcHJlY2lzZSB0aGUgZm9ybWF0Lg0KDQpbd2VpZ3VvMl06IE9LLiBJbiBv dXIgZHJhZnQsIHRoZSBmb3JtYXQgaXMgc2FtZSB3aXRoIFJGQzU1NzUsIEkgY2FuIGFkZCB0aGUg c2FtZSBkZXNjcmlwdGlvbiB0byBtYWtlIGl0IG1vcmUgY2xlYXIuDQoNCg0KU3RlcGhhbmUNCg0K DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBIYW93ZWlndW8gW21haWx0bzpo YW93ZWlndW9AaHVhd2VpLmNvbV0NClNlbnQ6IFNhdHVyZGF5LCBBdWd1c3QgMjMsIDIwMTQgMDk6 MDgNClRvOiBMSVRLT1dTS0kgU3RlcGhhbmUgU0NFL0lCTkY7IFVUVEFSTywgSkFNRVM7ICdpZHJA aWV0Zi5vcmcnOyAnbDJ2cG5AaWV0Zi5vcmcnDQpDYzogbGl1d2VpaGFuZw0KU3ViamVjdDogtPC4 tDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1oYW8taWRyLWZsb3dzcGVjLWV2 cG4tMDAudHh0DQoNCkhpIFN0ZXBoYW5lLA0KVGhhbmtzIGZvciB5b3VyIGRldGFpbCBjb21tZW50 cy4gUGxzIHNlZSBteSByZXBseSBpbmxpbmUgd2l0aCBbd2VpZ3VvXSBiZWxvdy4NCndlaWd1bw0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6IHN0ZXBo YW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tIFtzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbV0N Creiy83KsbzkOiAyMDE0xOo41MIyMsjVIDE2OjIyDQrK1bz+yMs6IEhhb3dlaWd1bzsgVVRUQVJP LCBKQU1FUzsgJ2lkckBpZXRmLm9yZyc7ICdsMnZwbkBpZXRmLm9yZycNCrOty806IGxpdXdlaWhh bmcNCtb3zOI6IFJFOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWhhby1pZHIt Zmxvd3NwZWMtZXZwbi0wMC50eHQNCg0KSGksDQoNCkkgdGhpbmsgdGhpcyBpcyBhIHZhbHVhYmxl IGFkZGl0aW9uLCBidXQgSSB3b3VsZCBsaWtlIHRvIHNlZSB0aGVzZSBNQUMgZmlsdGVycyBiZWlu ZyBhcHBsaWNhYmxlIGFsc28gdG8gSVB2NCBwbHVncyAoRlMgSVB2NCAmIFZQTnY0KQ0KW3dlaWd1 b106IFRoYW5rcy4gQnV0IE1BQyBmaWx0ZXJzIG1heWJlIG5vdCBhcHBsaWNhYmxlIHRvIElQVjQg JlZQTnY0LCBiZWNhdXNlIGluIHRoaXMgY2FzZSwgTUFDIGluZm9ybWF0aW9uIHdpbGwgYmUgY2hh bmdlZCBvbiBkaWZmZXJlbnQgUEUgZGV2aWNlcywgYSBzaW5nbGUgQUNMIHJ1bGUgY2FuJ3QgaWRl bnRpZnkgYSBjb25zaXN0YW50IGZsb3cgYXQgZGlmZmVyZW50IFBFIGRldmljZXMuIFNvIGluIElQ IG5ldHdvcmssIGZsb3ctc3BlYyBjYW4gb25seSBiZSBkZWZpbmVkIHVzaW5nIElQIHJlbGF0ZWQg aW5mb3JtYXRpb24uDQoNCk1vcmVvdmVyICwgdGhlIG5ldyBBRkkvU0FGSSBzaG91bGQgbm90IGJl IHJlc3RyaWN0ZWQgdG8gRVZQTiwgYW55IEwyIGludGVyZmFjZSBtYXkgYmUgaW50ZXJlc3RlZCBi eSBzdWNoIGZpbHRlciAoVlBMUywgYmFzaWMgTDIgc3dpdGNoaW5nIC4uLikuDQpbd2VpZ3VvXTog WWVzLCBJIGFncmVlLiBGaXJzdGx5IGkgcHJvcG9zZSBFdGhlcm5ldCBmbG93LXNwZWMgb25seSBp biBFVlBOIG5ldHdvcmssIGJlY2F1c2UgZmxvd3MtcGVjIHJlbGllcyBvbiBCR1AgcHJvdG9jb2wg YW5kIEVWUE4gaGFzIEJHUCBjb250cm9sIHBsYW5lLCBzbyBpdCB3aWxsIGJlIGVhc3kgdG8gZGVw bG95IEJHUCBmbG93c3BlYyBpbiBFVlBOIG5ldHdvcmsuIElmIHdlIHdhbnQgdG8gZGVwbG95IHRo ZSBmbG93LXNwZWMgaW4gVlBMUyBuZXR3b3JrLCBub3JtYWxseSBWUExTIG9ubHkgcmVsaWVzIG9u IExEUCBwcm90b2NvbCwgYWRkaXRpb25hbCBwcm90b2NvbCBvZiBCR1AgZmxvdy1zcGVjIHNob3Vs ZCBiZSBkZXBsb3llZCBmb3IgTUFDIGZpbHRlcmluZy4NCklmIHRoZSBjb21tdW5pdHkgdGhpbmtz IGl0IGlzIG5lY2Vzc2FyeSB0byBpbnRyb2R1Y2UgZXRoZXJuZXQgZmxvdy1zcGVjIGZvciBhbGwg TDIgaW50ZXJmYWNlLCBpIGNhbiB1cGRhdGUgdGhpcyBwYXJ0IHRvIGxldCBpdCBub3QgYmUgcmVz dHJpY3RlZCB0byBFVlBOLg0KDQpSb3V0ZSBkaXN0aW5ndWlzaGVyIG1heSBiZSBpcyBtaXNzaW5n IC4uLg0KW3dlaWd1b106IFJEIHVzYWdlIGhhcyBubyBkaWZmZXJlbmNlIHdpdGggb3JpZ2luYWwg QkdQIFZQTiBkZWZpbmljYXRpb24uIENhbiB5b3UgZ2l2ZSBtZSBzb21lIG1vcmUgY2xhcmlmaWNh dGlvbnM/DQoNCk5vdyBtb3JlIGdsb2JhbGx5LCBtYXkgYmUgaXQncyB0aW1lIHRvIHRoaW5rIG1v cmUgZ2xvYmFsbHkgYWJvdXQgdGhlIGV2b2x1dGlvbiBvZiBGUy4gSSBwcmV0dHkgc2VlIEZTIGV2 b2x1dGlvbiBsYXJnZWx5IGJleW9uZCBERG9TIGRvbWFpbi4gRlMgaXMgYSB2ZXJ5IGdvb2QgcHJv dG9jb2wgZm9yIFNETiBhcHBsaWNhdGlvbnMuIFRoZSBxdWVzdGlvbiBiZWhpbmQgaXMgZG8gd2Ug cmVhbGx5IG5lZWQgdG8gd29yayB3aXRoIG11bHRpcGxlIGFkZHJlc3MgZmFtaWxpZXMgZm9yIGVh Y2ggdHlwZSBvZiAic2VydmljZSIvImludGVyZmFjZSB0eXBlIiB0byBmaWx0ZXIgb3IgZG8gd2Ug bmVlZCB0byBoYXZlIGEgbW9yZSBnbG9iYWwgbW9kZWwgd2hlcmUgd2Ugd291bGQgYmUgYWJsZSB0 byBwdXQgYW55IHR5cGUgb2YgZmlsdGVyIGFueSB3aGVyZSBhbmQgYXBwbHkgbXVsdGlwbGUgYWN0 aW9ucyAob3BlbmZsb3cgbGlrZSBGUykuIENvbXBhcmVkIHRvIG9wZW5mbG93LCBGUyBoYXMgdGhl IG1hZ2ljIHRvIGVuYWJsZSBtdWx0aXBvaW50IGRpc3RyaWJ1dGlvbiBvZiBhY3Rpb25zLg0KDQpb d2VpZ3VvXTogWWVzLCBCR1AgZmxvdy1zcGVjIGNhbiBiZSBhcHBsaWNhYmxlIGZvciBzb21lIFNE TiBhcHBsaWNhdGlvbnMuIEl0IGhhcyBtb3JlIHBvdGVudGlhbCB0byBkbyBtb3JlIGF0dGFjdGl2 ZSB0aGluZ3MuDQoNCkJlc3QgUmVnYXJkcywNCg0KU3RlcGhhbmUNCg0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogSWRyIFttYWlsdG86aWRyLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBIYW93ZWlndW8NClNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMjEsIDIwMTQgMDQ6 MTENClRvOiBVVFRBUk8sIEpBTUVTOyAnaWRyQGlldGYub3JnJzsgJ2wydnBuQGlldGYub3JnJw0K Q2M6IGxpdXdlaWhhbmcNClN1YmplY3Q6IFtJZHJdILTwuLQ6IE5ldyBWZXJzaW9uIE5vdGlmaWNh dGlvbiBmb3IgZHJhZnQtaGFvLWlkci1mbG93c3BlYy1ldnBuLTAwLnR4dA0KDQpIaSBKaW0sDQpU aGFua3MgZm9yIHlvdXIgY29tbWVudHMuIFRoZSBCR1AgRmxvd3NwZWMgcHJvY2VkdXJlcyBpcyBp bGx1c3RyYXRlZCBhcyBmb2xsb3dpbmc6DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIEVWUE4gRmxvd1NwZWMgU2Vzc2lvbiAgICAgICAgICAgICAgICAgIEVWUE4g Rmxvd1NwZWMgU2Vzc2lvbg0KRERPUyBEZXRlY3Rpb24gQXBwbGlhbmNlLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS1FZ3Jlc3MgUEUtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLUluZ3Jlc3Mg UEUtLS0tLS1DRTINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBDRTEgRERPUyBEZXRlY3Rpb24gQXBwbGlhbmNlIGVzdGFibGlz aGVzIEVWUE4gZmxvd3NwZWMgc2Vzc2lvbiB3aXRoIEVncmVzcyBQRSwgaXQgZGV0ZWN0cyBERE9T IGF0dGFjayB0cmFmZmljIGFuZCBnZW5lcmF0ZSBBQ0wgcnVsZSwgdGhlIEFDTCBydWxlIGlzIGFu bm91bmNlZCB0byBFZ3Jlc3MgUEUgdGhyb3VnaCBFVlBOIGZsb3dzcGVjIHByb3RvY29sLCB0aGVu IHRoZSBlZ3Jlc3MgUEUgYW5ub3VuY2VzIGl0IHRvIGluZ3Jlc3MgUEUsIGZpbmFsbHkgaW5ncmVz cyBQRSBpbnN0YWxscyB0aGUgQUNMIHJ1bGUgZm9yIHRyYWZmaWMgZmlsdGVyaW5nLg0KRERPUyBE ZXRlY3Rpb24gQXBwbGlhbmNlIG9ubHkgbmVlZHMgdG8gc3VwcG9ydCBFVlBOIGZsb3dzcGVjIGZ1 bmN0aW9uLCBpdCBkb2Vzbid0IG5lZWQgdG8gc3VwcG9ydCBiYXNpYyBFVlBOIGZ1bmN0aW9uLg0K VGhhbmtzDQp3ZWlndW8NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CreivP7IyzogVVRUQVJPLCBKQU1FUyBbanUxNzM4QGF0dC5jb21dDQq3osvNyrG85DogMjAxNMTq ONTCMjHI1SAwOjI5DQrK1bz+yMs6IEhhb3dlaWd1bzsgJ2lkckBpZXRmLm9yZyc7ICdsMnZwbkBp ZXRmLm9yZycNCrOty806IGxpdXdlaWhhbmcNCtb3zOI6IFJFOiBOZXcgVmVyc2lvbiBOb3RpZmlj YXRpb24gZm9yIGRyYWZ0LWhhby1pZHItZmxvd3NwZWMtZXZwbi0wMC50eHQNCg0KV2VpZ3VvLA0K DQogICAgICAgIEkgd291bGQgbGlrZSB0byBiZXR0ZXIgdW5kZXJzdGFuZCBob3cgYSByZW1vdGUg UEUgd2lsbCAibGVhcm4iIHRoYXQgaXQgbmVlZHMgdG8gZGVsaXZlciBhIEZTIHBhdGggdG8gdGhl IGluZ3Jlc3MgUEU/PyBJdCBjYW5ub3QgY29tZSBmcm9tIHRoZSBDRSBhcyB0aGF0IGlzIGRhdGEg cGxhbmUgbGVhcm5pbmcuIEkgd291bGQgdGhpbmsgdGhhdCBhbGwgRlMgcGF0aHMgaGF2ZSB0byBi ZSBkaXNzZW1pbmF0ZWQgYnkgYSBjZW50cmFsaXplZCBjb250cm9sbGVyLg0KDQpKaW0gVXR0YXJv DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBJZHIgW21haWx0bzppZHItYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEhhb3dlaWd1bw0KU2VudDogVHVlc2RheSwgQXVn dXN0IDE5LCAyMDE0IDg6MzEgUE0NClRvOiBpZHJAaWV0Zi5vcmc7IGwydnBuQGlldGYub3JnDQpD YzogbGl1d2VpaGFuZw0KU3ViamVjdDogW0lkcl0gtPC4tDogTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvciBkcmFmdC1oYW8taWRyLWZsb3dzcGVjLWV2cG4tMDAudHh0DQoNCkhpIEFsbCwNCldl IGhhdmUgc3VibWl0dGVkIGEgZHJhZnQgb2YgIiBEaXNzZW1pbmF0aW9uIG9mIEZsb3cgU3BlY2lm aWNhdGlvbiBSdWxlcyBmb3IgRVZQTiIuICBJIHdpbGwgYXBwcmljaWF0ZSBpZiB5b3UgY2FuIGdp dmUgdXMgc29tZSBzdWdnZXN0aW9ucyBhbmQgY29tbWVudHMuDQpUaGFua3MNCndlaWd1bw0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6IGludGVybmV0 LWRyYWZ0c0BpZXRmLm9yZyBbaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0Kt6LLzcqxvOQ6IDIw MTTE6jjUwjIwyNUgODoyMA0KytW8/sjLOiBaaHVhbmdzaHVud2FuOyBIYW93ZWlndW87IGxpdXdl aWhhbmc7IFpodWFuZ3NodW53YW47IGxpdXdlaWhhbmc7IEhhb3dlaWd1bw0K1vfM4jogTmV3IFZl cnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1oYW8taWRyLWZsb3dzcGVjLWV2cG4tMDAudHh0 DQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1oYW8taWRyLWZsb3dzcGVjLWV2cG4tMDAu dHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFdlaWd1byBIYW8gYW5kIHBv c3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOiAgICAgICAgICAgZHJhZnQtaGFv LWlkci1mbG93c3BlYy1ldnBuDQpSZXZpc2lvbjogICAgICAgMDANClRpdGxlOiAgICAgICAgICBE aXNzZW1pbmF0aW9uIG9mIEZsb3cgU3BlY2lmaWNhdGlvbiBSdWxlcyBmb3IgRVZQTg0KRG9jdW1l bnQgZGF0ZTogIDIwMTQtMDgtMjANCkdyb3VwOiAgICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Np b24NClBhZ2VzOiAgICAgICAgICA3DQpVUkw6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9y Zy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaGFvLWlkci1mbG93c3BlYy1ldnBuLTAwLnR4dA0KU3Rh dHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWhhby1p ZHItZmxvd3NwZWMtZXZwbi8NCkh0bWxpemVkOiAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1oYW8taWRyLWZsb3dzcGVjLWV2cG4tMDANCg0KDQpBYnN0cmFjdDoNCiAgIFRo aXMgZG9jdW1lbnQgZGVmaW5lcyBCR1AgZmxvdy1zcGVjIGV4dGVuc2lvbiBmb3IgRXRoZXJuZXQg dHJhZmZpYw0KICAgZmlsdGVyaW5nIGluIEVWUE4gbmV0d29yay4gQSBuZXcgQkdQIE5MUkkgdHlw ZSAoQUZJPTI1LCBTQUZJPVRCRCkNCiAgIHZhbHVlIGlzIHByb3Bvc2VkIHRvIGlkZW50aWZ5IEVW UE4gZmxvdy1zcGVjIGFwcGxpY2F0aW9uLiBBIG5ldw0KICAgc3Vic2V0IG9mIGNvbXBvbmVudCB0 eXBlcyBhbmQgZXh0ZW5kZWQgY29tbXVuaXR5IGFsc28gYXJlIGRlZmluZWQuDQoNCg0KDQoNClBs ZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0 aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJl IGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJZHIgbWFpbGlu ZyBsaXN0DQpJZHJAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vaWRyDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K SWRyIG1haWxpbmcgbGlzdA0KSWRyQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2lkcg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBq b2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMg b3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYyBwYXMgZXRyZSBkaWZmdXNlcywgZXhw bG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2Ug bWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlciBhIGwnZXhwZWRpdGV1ciBl dCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMg ZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLCBPcmFuZ2UgZGVj bGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVm b3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQoNClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1l bnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRo YXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7IHRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRl ZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KSWYgeW91IGhhdmUgcmVj ZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBk ZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQpBcyBlbWFpbHMgbWF5IGJl IGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVl biBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQpUaGFuayB5b3UuDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cg0KQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMg aW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVu dCBkb25jIHBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jp c2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6 IGxlIHNpZ25hbGVyIGEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMg cGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRp YmxlcyBkJ2FsdGVyYXRpb24sIE9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNp IGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCg0K VGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFs IG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsg dGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1 dGhvcmlzYXRpb24uDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBw bGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBh dHRhY2htZW50cy4NCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFi bGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNp ZmllZC4NClRoYW5rIHlvdS4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMg am9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVz IG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMNCnBhcyBldHJlIGRpZmZ1c2VzLCBl eHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBj ZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyDQphIGwnZXhwZWRpdGV1 ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2Fn ZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLA0KT3Jhbmdl IGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUs IGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KDQpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRh Y2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlv biB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Ow0KdGhleSBzaG91bGQgbm90IGJlIGRpc3Ry aWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQpJZiB5b3UgaGF2 ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIg YW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCkFzIGVtYWlscyBt YXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2 ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NClRoYW5rIHlvdS4NCg0K From nobody Tue Sep 2 07:20:10 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1A311A03ED for ; Tue, 2 Sep 2014 07:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.236 X-Spam-Level: X-Spam-Status: No, score=-2.236 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q0y6PrDCsZAg for ; Tue, 2 Sep 2014 07:20:05 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id CBC0E1A03BA for ; Tue, 2 Sep 2014 07:20:05 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 85556C259; Tue, 2 Sep 2014 10:20:05 -0400 (EDT) Date: Tue, 2 Sep 2014 10:20:05 -0400 From: Jeffrey Haas To: Susan Hares Message-ID: <20140902142005.GB7736@pfrc> References: <018e01cfc146$4be6c480$e3b44d80$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <018e01cfc146$4be6c480$e3b44d80$@ndzh.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/l-kiw39PZcVUbUmqdDT-uzDc4Cc Cc: idr wg , Alia Atlas Subject: Re: [Idr] WG LC X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 14:20:08 -0000 On Tue, Aug 26, 2014 at 11:56:27AM -0400, Susan Hares wrote: > This is a 2 week WGT LC on draft-ietf-idr-as-migration starting 8/26/2014 > and ending 9/6/2014. > > > > The draft can be accessed at: > > > > http://datatracker.ietf.org/doc/draft-ietf-idr-as-migration/ > > > > Please include in your call "support or no support". This call also ask > the authors to indicate if there is any IPR related to the draft. Support. -- Jeff From nobody Tue Sep 2 07:46:46 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FC8A1A8732; Tue, 2 Sep 2014 07:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Z9G7aqjETPw; Tue, 2 Sep 2014 07:46:32 -0700 (PDT) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B5121A700F; Tue, 2 Sep 2014 07:46:32 -0700 (PDT) Received: by mail-ig0-f171.google.com with SMTP id l13so14306322iga.4 for ; Tue, 02 Sep 2014 07:46:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=kQWW1ooIzaGJi5GWw6XVtac+c0Eme7Lgvs1SdG1c5YU=; b=0qIdjrgdkrBNvTWYBgghi0hVF4+hthrSBu5o65yb/9rB8pzpJnKyNqYK1AYbWA1Iap Jfw1RIxg7RKjC94KaZiQJMTs7oNwXE9DEruxj0PgabTMVVH/KPHMYBGVESpZkyssfIZV PTTB34OdaJ4/dB5DVheKDI1sHXnIURP/iLktR1OjcfQx+YktCpgRhYT62Jz21OlQWveN vPFk/tUlwWyVts4l1wxBwR3KfRBmELHTeRZVk//FSxnAFTnaOv35RwDtMHlr2usxqNiu pRE5/6avvu5DYawj55BEbr/Olj5fWbQTqM77ZdL9+4vfNFNHRSK5I9tEkEPT8fKu+Z9A yOWw== MIME-Version: 1.0 X-Received: by 10.42.249.20 with SMTP id mi20mr1191340icb.90.1409669191443; Tue, 02 Sep 2014 07:46:31 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.107.32.141 with HTTP; Tue, 2 Sep 2014 07:46:31 -0700 (PDT) Received: by 10.107.32.141 with HTTP; Tue, 2 Sep 2014 07:46:31 -0700 (PDT) In-Reply-To: References: <20140820002030.18902.50278.idtracker@ietfa.amsl.com> <29476_1408695761_53F6FDD1_29476_12929_1_9E32478DFA9976438E7A22F69B08FF9207DB14@OPEXCLILM34.corporate.adroot.infra.ftgroup> <28799_1409563679_54043C1F_28799_2589_1_9E32478DFA9976438E7A22F69B08FF92080C92@OPEXCLILM34.corporate.adroot.infra.ftgroup> <25521_1409584904_54048F08_25521_750_1_9E32478DFA9976438E7A22F69B08FF920810A4@OPEXCLILM34.corporate.adroot.infra.ftgroup> Date: Tue, 2 Sep 2014 16:46:31 +0200 X-Google-Sender-Auth: XPXjAh9ONGrbnJ9QJMigdgDPrTc Message-ID: From: Robert Raszuk To: "UTTARO, JAMES" Content-Type: multipart/alternative; boundary=20cf3011e125682cac0502162f46 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/yH0U73F-x2tdpBRNcjyPR_gKLR0 Cc: l2vpn@ietf.org, liuweihang , "idr@ietf.org" Subject: Re: [Idr] New Version Notification for draft-hao-idr-flowspec-evpn-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 14:46:41 -0000 --20cf3011e125682cac0502162f46 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Jim, It is ok to use bgp as database distribution protocol and to carry more then pure routing/reachability state. We are indeed past that point. But only to the extend where distributed information is usefull at multiple end points. However I do not see p2mp nature of BGP distribution to generally fit policy or configuration needs. Those are very often targeted to specific end point and I do not think that sending them to all or for that matter filtering from all-1 with say RTC is really a wise approach. Rgs, R. On Sep 2, 2014 7:06 AM, "UTTARO, JAMES" wrote: > Comments In-Line > > Jim Uttaro > > -----Original Message----- > From: stephane.litkowski@orange.com [mailto:stephane.litkowski@orange.com= ] > Sent: Monday, September 01, 2014 11:22 AM > To: Haoweiguo; UTTARO, JAMES; 'idr@ietf.org'; 'l2vpn@ietf.org' > Cc: liuweihang > Subject: RE: New Version Notification for > draft-hao-idr-flowspec-evpn-00.txt > > [weiguo2]: I know what you said. Yes, In IRB scenario, not only ethernet > header but also IP header can be used for traffic filtering. I think our > draft can cover this scenario. In the draft, component types include both > IP and ethernet part, IP component types are inherited from RFC[5575], MA= C > componet types are newly defined. So only one address family is needed fo= r > IP and Ethernet traffic filtering. > > [SLI] Right, that's one possibility, the other one could be to not create > a new AF for MAC FS but just extend the current FS address-families (VPN > and non VPN) with MAC component types and new actions. > The main question in term of protocol design is to we want to keep > filtering AF agnostic (single FS AF for all type of flows) or do we need = to > keep separate FS AFs ? > [Jim U>] This comes back to a more basic question. Should an AF be define= d > that communicates non-routing state? As an ex, VPLS BGP, FS, RTC the list > goes on are all delineated by AF.. At some point we need to acknowledge > that we are using BGP as a general distribution protocol and have the > design/spec reflect that. IMO this means separating by configuration type > of actions that do not require a global invariant and routing which does. > The way taken for the moment is to have separate ones, we can see that > IPv6 FS is currently defined as a new couple of AFI/SAFI but is it the go= od > way to do ? I don't remember if this has been discussed or not when > defining FS IPv6 ? > I'm wondering if we cannot make FlowSpec working as IPFIX for the flow > definition. > > > > -----Original Message----- > From: Haoweiguo [mailto:haoweiguo@huawei.com] > Sent: Monday, September 01, 2014 13:51 > To: LITKOWSKI Stephane SCE/IBNF; UTTARO, JAMES; 'idr@ietf.org'; ' > l2vpn@ietf.org' > Cc: liuweihang > Subject: =E7=AD=94=E5=A4=8D: New Version Notification for > draft-hao-idr-flowspec-evpn-00.txt > > Hi Stephane, > Pls see my reply inline with [weiguo2] below. > Thanks > weiguo > > ________________________________________ > =E5=8F=91=E4=BB=B6=E4=BA=BA: stephane.litkowski@orange.com [stephane.litk= owski@orange.com] > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2014=E5=B9=B49=E6=9C=881=E6=97=A5 1= 7:27 > =E6=94=B6=E4=BB=B6=E4=BA=BA: Haoweiguo; UTTARO, JAMES; 'idr@ietf.org'; 'l= 2vpn@ietf.org' > =E6=8A=84=E9=80=81: liuweihang > =E4=B8=BB=E9=A2=98: RE: New Version Notification for draft-hao-idr-flowsp= ec-evpn-00.txt > > [weiguo]: Thanks. But MAC filters maybe not applicable to IPV4 &VPNv4, > because in this case, MAC information will be changed on different PE > devices, a single ACL rule can't identify a consistant flow at different = PE > devices. So in IP network, flow-spec can only be defined using IP related > information. > [SLI] I agree with your point but I was thinking about a future (hope it > will happen :) when we will be able to offer L2 and L3 services on the sa= me > plug (including same VLAN, sort of concurrent routing & bridging > interface). In this situation, is it good to use two address families to > filter the different services ? Why not using only one ... > > [weiguo2]: I know what you said. Yes, In IRB scenario, not only ethernet > header but also IP header can be used for traffic filtering. I think our > draft can cover this scenario. In the draft, component types include both > IP and ethernet part, IP component types are inherited from RFC[5575], MA= C > componet types are newly defined. So only one address family is needed fo= r > IP and Ethernet traffic filtering. > > [weiguo]: RD usage has no difference with original BGP VPN definication. > Can you give me some more clarifications? > [SLI] Right, but RFC5575 precises that RD is part of NLRI for VPN : > "The NLRI format for this address family consists of a fixed-length > Route Distinguisher field (8 bytes) followed by a flow specification, > following the encoding defined in this document. The NLRI length > field shall include both the 8 bytes of the Route Distinguisher as > well as the subsequent flow specification. > " > In your document , I can't see this ... as you are defining a new NLRI, > you need to precise the format. > > [weiguo2]: OK. In our draft, the format is same with RFC5575, I can add > the same description to make it more clear. > > > Stephane > > > > -----Original Message----- > From: Haoweiguo [mailto:haoweiguo@huawei.com] > Sent: Saturday, August 23, 2014 09:08 > To: LITKOWSKI Stephane SCE/IBNF; UTTARO, JAMES; 'idr@ietf.org'; ' > l2vpn@ietf.org' > Cc: liuweihang > Subject: =E7=AD=94=E5=A4=8D: New Version Notification for > draft-hao-idr-flowspec-evpn-00.txt > > Hi Stephane, > Thanks for your detail comments. Pls see my reply inline with [weiguo] > below. > weiguo > > ________________________________________ > =E5=8F=91=E4=BB=B6=E4=BA=BA: stephane.litkowski@orange.com [stephane.litk= owski@orange.com] > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2014=E5=B9=B48=E6=9C=8822=E6=97=A5 = 16:22 > =E6=94=B6=E4=BB=B6=E4=BA=BA: Haoweiguo; UTTARO, JAMES; 'idr@ietf.org'; 'l= 2vpn@ietf.org' > =E6=8A=84=E9=80=81: liuweihang > =E4=B8=BB=E9=A2=98: RE: New Version Notification for draft-hao-idr-flowsp= ec-evpn-00.txt > > Hi, > > I think this is a valuable addition, but I would like to see these MAC > filters being applicable also to IPv4 plugs (FS IPv4 & VPNv4) > [weiguo]: Thanks. But MAC filters maybe not applicable to IPV4 &VPNv4, > because in this case, MAC information will be changed on different PE > devices, a single ACL rule can't identify a consistant flow at different = PE > devices. So in IP network, flow-spec can only be defined using IP related > information. > > Moreover , the new AFI/SAFI should not be restricted to EVPN, any L2 > interface may be interested by such filter (VPLS, basic L2 switching ...)= . > [weiguo]: Yes, I agree. Firstly i propose Ethernet flow-spec only in EVPN > network, because flows-pec relies on BGP protocol and EVPN has BGP contro= l > plane, so it will be easy to deploy BGP flowspec in EVPN network. If we > want to deploy the flow-spec in VPLS network, normally VPLS only relies o= n > LDP protocol, additional protocol of BGP flow-spec should be deployed for > MAC filtering. > If the community thinks it is necessary to introduce ethernet flow-spec > for all L2 interface, i can update this part to let it not be restricted = to > EVPN. > > Route distinguisher may be is missing ... > [weiguo]: RD usage has no difference with original BGP VPN definication. > Can you give me some more clarifications? > > Now more globally, may be it's time to think more globally about the > evolution of FS. I pretty see FS evolution largely beyond DDoS domain. FS > is a very good protocol for SDN applications. The question behind is do w= e > really need to work with multiple address families for each type of > "service"/"interface type" to filter or do we need to have a more global > model where we would be able to put any type of filter any where and appl= y > multiple actions (openflow like FS). Compared to openflow, FS has the mag= ic > to enable multipoint distribution of actions. > > [weiguo]: Yes, BGP flow-spec can be applicable for some SDN applications. > It has more potential to do more attactive things. > > Best Regards, > > Stephane > > > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Haoweiguo > Sent: Thursday, August 21, 2014 04:11 > To: UTTARO, JAMES; 'idr@ietf.org'; 'l2vpn@ietf.org' > Cc: liuweihang > Subject: [Idr] =E7=AD=94=E5=A4=8D: New Version Notification for > draft-hao-idr-flowspec-evpn-00.txt > > Hi Jim, > Thanks for your comments. The BGP Flowspec procedures is illustrated as > following: > > EVPN FlowSpec Session > EVPN FlowSpec Session > DDOS Detection Appliance--------------------------Egress > PE-----------------------------Ingress PE------CE2 > > | > > CE1 DDOS Detection Appliance establishes EVPN flowspec sessio= n > with Egress PE, it detects DDOS attack traffic and generate ACL rule, the > ACL rule is announced to Egress PE through EVPN flowspec protocol, then t= he > egress PE announces it to ingress PE, finally ingress PE installs the ACL > rule for traffic filtering. > DDOS Detection Appliance only needs to support EVPN flowspec function, it > doesn't need to support basic EVPN function. > Thanks > weiguo > ________________________________________ > =E5=8F=91=E4=BB=B6=E4=BA=BA: UTTARO, JAMES [ju1738@att.com] > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2014=E5=B9=B48=E6=9C=8821=E6=97=A5 = 0:29 > =E6=94=B6=E4=BB=B6=E4=BA=BA: Haoweiguo; 'idr@ietf.org'; 'l2vpn@ietf.org' > =E6=8A=84=E9=80=81: liuweihang > =E4=B8=BB=E9=A2=98: RE: New Version Notification for draft-hao-idr-flowsp= ec-evpn-00.txt > > Weiguo, > > I would like to better understand how a remote PE will "learn" > that it needs to deliver a FS path to the ingress PE?? It cannot come fro= m > the CE as that is data plane learning. I would think that all FS paths ha= ve > to be disseminated by a centralized controller. > > Jim Uttaro > > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Haoweiguo > Sent: Tuesday, August 19, 2014 8:31 PM > To: idr@ietf.org; l2vpn@ietf.org > Cc: liuweihang > Subject: [Idr] =E7=AD=94=E5=A4=8D: New Version Notification for > draft-hao-idr-flowspec-evpn-00.txt > > Hi All, > We have submitted a draft of " Dissemination of Flow Specification Rules > for EVPN". I will appriciate if you can give us some suggestions and > comments. > Thanks > weiguo > > ________________________________________ > =E5=8F=91=E4=BB=B6=E4=BA=BA: internet-drafts@ietf.org [internet-drafts@ie= tf.org] > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2014=E5=B9=B48=E6=9C=8820=E6=97=A5 = 8:20 > =E6=94=B6=E4=BB=B6=E4=BA=BA: Zhuangshunwan; Haoweiguo; liuweihang; Zhuang= shunwan; liuweihang; > Haoweiguo > =E4=B8=BB=E9=A2=98: New Version Notification for draft-hao-idr-flowspec-e= vpn-00.txt > > A new version of I-D, draft-hao-idr-flowspec-evpn-00.txt > has been successfully submitted by Weiguo Hao and posted to the IETF > repository. > > Name: draft-hao-idr-flowspec-evpn > Revision: 00 > Title: Dissemination of Flow Specification Rules for EVPN > Document date: 2014-08-20 > Group: Individual Submission > Pages: 7 > URL: > http://www.ietf.org/internet-drafts/draft-hao-idr-flowspec-evpn-00.txt > Status: > https://datatracker.ietf.org/doc/draft-hao-idr-flowspec-evpn/ > Htmlized: http://tools.ietf.org/html/draft-hao-idr-flowspec-evpn-00 > > > Abstract: > This document defines BGP flow-spec extension for Ethernet traffic > filtering in EVPN network. A new BGP NLRI type (AFI=3D25, SAFI=3DTBD) > value is proposed to identify EVPN flow-spec application. A new > subset of component types and extended community also are defined. > > > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org. > > The IETF Secretariat > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > exploites ou copies sans autorisation. Si vous avez recu ce message par > erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les > pieces jointes. Les messages electroniques etant susceptibles d'alteratio= n, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; they should not be distributed, > used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n > modified, changed or falsified. > Thank you. > > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > exploites ou copies sans autorisation. Si vous avez recu ce message par > erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les > pieces jointes. Les messages electroniques etant susceptibles d'alteratio= n, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; they should not be distributed, > used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n > modified, changed or falsified. > Thank you. > > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n > modified, changed or falsified. > Thank you. > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --20cf3011e125682cac0502162f46 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Jim,

It is ok to use bgp as database distribution protocol and to= carry more then pure routing/reachability state. We are indeed past that p= oint. But only to the extend where distributed information is usefull at mu= ltiple end points.

However I do not see p2mp nature of BGP distribution to gene= rally fit policy or configuration needs.

Those are very often targeted to specific end point and I do= not think that sending them to all or for that matter filtering from all-1= with say RTC is really a wise approach.

Rgs,
R.

On Sep 2, 2014 7:06 AM, "UTTARO, JAMES"= ; <ju1738@att.com> wrote:
Comments In-Line

Jim Uttaro

-----Original Message-----
From: stephane.litkowski@o= range.com [mailto:step= hane.litkowski@orange.com]
Sent: Monday, September 01, 2014 11:22 AM
To: Haoweiguo; UTTARO, JAMES; 'idr@ietf= .org'; 'l2vpn@ietf.org= 9;
Cc: liuweihang
Subject: RE: New Version Notification for draft-hao-idr-flowspec-evpn-00.tx= t

[weiguo2]: I know what you said. Yes, In IRB scenario, not only ethernet he= ader but also IP header can be used for traffic filtering.=C2=A0 I think ou= r draft can cover this scenario. In the draft, component types include both= IP and ethernet part, IP component types are inherited from RFC[5575], MAC= componet types are newly defined. So only one address family is needed for= IP and Ethernet traffic filtering.

[SLI] Right, that's one possibility, the other one could be to not crea= te a new AF for MAC FS but just extend the current FS address-families (VPN= and non VPN) with MAC component types and new actions.
The main question in term of protocol design is to we want to keep filterin= g AF agnostic (single FS AF for all type of flows) or do we need to keep se= parate FS AFs ?
[Jim U>] This comes back to a more basic question. Should an AF be defin= ed that communicates non-routing state? As an ex, VPLS BGP, FS, RTC the lis= t goes on are all delineated by AF.. At some point we need to acknowledge t= hat we are using BGP as a general distribution protocol and have the design= /spec reflect that. IMO this means separating by configuration type of acti= ons that do not require a global invariant and routing which does.
The way taken for the moment is to have separate ones, we can see that IPv6= FS is currently defined as a new couple of AFI/SAFI but is it the good way= to do ? I don't remember if this has been discussed or not when defini= ng FS IPv6 ?
I'm wondering if we cannot make FlowSpec working as IPFIX for the flow = definition.



-----Original Message-----
From: Haoweiguo [mailto:haoweiguo@h= uawei.com]
Sent: Monday, September 01, 2014 13:51
To: LITKOWSKI Stephane SCE/IBNF; UTTARO, JAMES; 'idr@ietf.org'; 'l2v= pn@ietf.org'
Cc: liuweihang
Subject: =E7=AD=94=E5=A4=8D: New Version Notification for draft-hao-idr-flo= wspec-evpn-00.txt

Hi Stephane,
Pls see my reply inline with [weiguo2] below.
Thanks
weiguo

________________________________________
=E5=8F=91=E4=BB=B6=E4=BA=BA: stephane.litkowski@orange.com [stephane.litkowski@orange.com]
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2014=E5=B9=B49=E6=9C=881=E6=97=A5 17:= 27
=E6=94=B6=E4=BB=B6=E4=BA=BA: Haoweiguo; UTTARO, JAMES; 'idr@ietf.org'; 'l2vpn@ietf.org'
=E6=8A=84=E9=80=81: liuweihang
=E4=B8=BB=E9=A2=98: RE: New Version Notification for draft-hao-idr-flowspec= -evpn-00.txt

[weiguo]: Thanks. But MAC filters maybe not applicable to IPV4 &VPNv4, = because in this case, MAC information will be changed on different PE devic= es, a single ACL rule can't identify a consistant flow at different PE = devices. So in IP network, flow-spec can only be defined using IP related i= nformation.
[SLI] I agree with your point but I was thinking about a future (hope it wi= ll happen :) when we will be able to offer L2 and L3 services on the same p= lug (including same VLAN, sort of concurrent routing & bridging interfa= ce). In this situation, is it good to use two address families to filter th= e different services ? Why not using only one ...

[weiguo2]: I know what you said. Yes, In IRB scenario, not only ethernet he= ader but also IP header can be used for traffic filtering.=C2=A0 I think ou= r draft can cover this scenario. In the draft, component types include both= IP and ethernet part, IP component types are inherited from RFC[5575], MAC= componet types are newly defined. So only one address family is needed for= IP and Ethernet traffic filtering.

[weiguo]: RD usage has no difference with original BGP VPN definication. Ca= n you give me some more clarifications?
[SLI] Right, but RFC5575 precises that RD is part of NLRI for VPN :
"The NLRI format for this address family consists of a fixed-length =C2=A0 =C2=A0Route Distinguisher field (8 bytes) followed by a flow specifi= cation,
=C2=A0 =C2=A0following the encoding defined in this document.=C2=A0 The NLR= I length
=C2=A0 =C2=A0field shall include both the 8 bytes of the Route Distinguishe= r as
=C2=A0 =C2=A0well as the subsequent flow specification.
"
In your document , I can't see this ... as you are defining a new NLRI,= you need to precise the format.

[weiguo2]: OK. In our draft, the format is same with RFC5575, I can add the= same description to make it more clear.


Stephane



-----Original Message-----
From: Haoweiguo [mailto:haoweiguo@h= uawei.com]
Sent: Saturday, August 23, 2014 09:08
To: LITKOWSKI Stephane SCE/IBNF; UTTARO, JAMES; 'idr@ietf.org'; 'l2v= pn@ietf.org'
Cc: liuweihang
Subject: =E7=AD=94=E5=A4=8D: New Version Notification for draft-hao-idr-flo= wspec-evpn-00.txt

Hi Stephane,
Thanks for your detail comments. Pls see my reply inline with [weiguo] belo= w.
weiguo

________________________________________
=E5=8F=91=E4=BB=B6=E4=BA=BA: stephane.litkowski@orange.com [stephane.litkowski@orange.com]
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2014=E5=B9=B48=E6=9C=8822=E6=97=A5 16= :22
=E6=94=B6=E4=BB=B6=E4=BA=BA: Haoweiguo; UTTARO, JAMES; 'idr@ietf.org'; 'l2vpn@ietf.org'
=E6=8A=84=E9=80=81: liuweihang
=E4=B8=BB=E9=A2=98: RE: New Version Notification for draft-hao-idr-flowspec= -evpn-00.txt

Hi,

I think this is a valuable addition, but I would like to see these MAC filt= ers being applicable also to IPv4 plugs (FS IPv4 & VPNv4)
[weiguo]: Thanks. But MAC filters maybe not applicable to IPV4 &VPNv4, = because in this case, MAC information will be changed on different PE devic= es, a single ACL rule can't identify a consistant flow at different PE = devices. So in IP network, flow-spec can only be defined using IP related i= nformation.

Moreover , the new AFI/SAFI should not be restricted to EVPN, any L2 interf= ace may be interested by such filter (VPLS, basic L2 switching ...).
[weiguo]: Yes, I agree. Firstly i propose Ethernet flow-spec only in EVPN n= etwork, because flows-pec relies on BGP protocol and EVPN has BGP control p= lane, so it will be easy to deploy BGP flowspec in EVPN network. If we want= to deploy the flow-spec in VPLS network, normally VPLS only relies on LDP = protocol, additional protocol of BGP flow-spec should be deployed for MAC f= iltering.
If the community thinks it is necessary to introduce ethernet flow-spec for= all L2 interface, i can update this part to let it not be restricted to EV= PN.

Route distinguisher may be is missing ...
[weiguo]: RD usage has no difference with original BGP VPN definication. Ca= n you give me some more clarifications?

Now more globally, may be it's time to think more globally about the ev= olution of FS. I pretty see FS evolution largely beyond DDoS domain. FS is = a very good protocol for SDN applications. The question behind is do we rea= lly need to work with multiple address families for each type of "serv= ice"/"interface type" to filter or do we need to have a more= global model where we would be able to put any type of filter any where an= d apply multiple actions (openflow like FS). Compared to openflow, FS has t= he magic to enable multipoint distribution of actions.

[weiguo]: Yes, BGP flow-spec can be applicable for some SDN applications. I= t has more potential to do more attactive things.

Best Regards,

Stephane


-----Original Message-----
From: Idr [mailto:idr-bounces@ietf.= org] On Behalf Of Haoweiguo
Sent: Thursday, August 21, 2014 04:11
To: UTTARO, JAMES; 'idr@ietf.org= 9;; 'l2vpn@ietf.org'
Cc: liuweihang
Subject: [Idr] =E7=AD=94=E5=A4=8D: New Version Notification for draft-hao-i= dr-flowspec-evpn-00.txt

Hi Jim,
Thanks for your comments. The BGP Flowspec procedures is illustrated as fol= lowing:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 E= VPN FlowSpec Session=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 EVPN FlowSpec Session
DDOS Detection Appliance--------------------------Egress PE----------------= -------------Ingress PE------CE2
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 CE1 DDOS Detection Appliance establishes EVPN flowspec session with = Egress PE, it detects DDOS attack traffic and generate ACL rule, the ACL ru= le is announced to Egress PE through EVPN flowspec protocol, then the egres= s PE announces it to ingress PE, finally ingress PE installs the ACL rule f= or traffic filtering.
DDOS Detection Appliance only needs to support EVPN flowspec function, it d= oesn't need to support basic EVPN function.
Thanks
weiguo
________________________________________
=E5=8F=91=E4=BB=B6=E4=BA=BA: UTTARO, JAMES [ju1738@att.com]
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2014=E5=B9=B48=E6=9C=8821=E6=97=A5 0:= 29
=E6=94=B6=E4=BB=B6=E4=BA=BA: Haoweiguo; 'idr@ietf.org'; 'l2vpn@ietf.= org'
=E6=8A=84=E9=80=81: liuweihang
=E4=B8=BB=E9=A2=98: RE: New Version Notification for draft-hao-idr-flowspec= -evpn-00.txt

Weiguo,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 I would like to better understand how a remote = PE will "learn" that it needs to deliver a FS path to the ingress= PE?? It cannot come from the CE as that is data plane learning. I would th= ink that all FS paths have to be disseminated by a centralized controller.<= br>
Jim Uttaro

-----Original Message-----
From: Idr [mailto:idr-bounces@ietf.= org] On Behalf Of Haoweiguo
Sent: Tuesday, August 19, 2014 8:31 PM
To: idr@ietf.org; l2vpn@ietf.org
Cc: liuweihang
Subject: [Idr] =E7=AD=94=E5=A4=8D: New Version Notification for draft-hao-i= dr-flowspec-evpn-00.txt

Hi All,
We have submitted a draft of " Dissemination of Flow Specification Rul= es for EVPN".=C2=A0 I will appriciate if you can give us some suggesti= ons and comments.
Thanks
weiguo

________________________________________
=E5=8F=91=E4=BB=B6=E4=BA=BA: in= ternet-drafts@ietf.org [int= ernet-drafts@ietf.org]
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2014=E5=B9=B48=E6=9C=8820=E6=97=A5 8:= 20
=E6=94=B6=E4=BB=B6=E4=BA=BA: Zhuangshunwan; Haoweiguo; liuweihang; Zhuangsh= unwan; liuweihang; Haoweiguo
=E4=B8=BB=E9=A2=98: New Version Notification for draft-hao-idr-flowspec-evp= n-00.txt

A new version of I-D, draft-hao-idr-flowspec-evpn-00.txt
has been successfully submitted by Weiguo Hao and posted to the IETF reposi= tory.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-hao-idr-flowspec-evpn Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Dissemination of Flow Specificatio= n Rules for EVPN
Document date:=C2=A0 2014-08-20
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 7
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 htt= p://www.ietf.org/internet-drafts/draft-hao-idr-flowspec-evpn-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatrack= er.ietf.org/doc/draft-hao-idr-flowspec-evpn/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0http://tools.ietf.org/html= /draft-hao-idr-flowspec-evpn-00


Abstract:
=C2=A0 =C2=A0This document defines BGP flow-spec extension for Ethernet tra= ffic
=C2=A0 =C2=A0filtering in EVPN network. A new BGP NLRI type (AFI=3D25, SAFI= =3DTBD)
=C2=A0 =C2=A0value is proposed to identify EVPN flow-spec application. A ne= w
=C2=A0 =C2=A0subset of component types and extended community also are defi= ned.




Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat
_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr
_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr

___________________________________________________________________________= ______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou = copies sans autorisation. Si vous avez recu ce message par erreur, veuillez= le signaler a l'expediteur et le detruire ainsi que les pieces jointes= . Les messages electroniques etant susceptibles d'alteration, Orange de= cline toute responsabilite si ce message a ete altere, deforme ou falsifie.= Merci.

This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used= or copied without authorisation.
If you have received this email in error, please notify the sender and dele= te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified.
Thank you.

___________________________________________________________________________= ______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou = copies sans autorisation. Si vous avez recu ce message par erreur, veuillez= le signaler a l'expediteur et le detruire ainsi que les pieces jointes= . Les messages electroniques etant susceptibles d'alteration, Orange de= cline toute responsabilite si ce message a ete altere, deforme ou falsifie.= Merci.

This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used= or copied without authorisation.
If you have received this email in error, please notify the sender and dele= te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified.
Thank you.

___________________________________________________________________________= ______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les message= s electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci.

This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele= te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified.
Thank you.

_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr
--20cf3011e125682cac0502162f46-- From nobody Tue Sep 2 07:53:50 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B87D1A8758 for ; Tue, 2 Sep 2014 07:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.236 X-Spam-Level: X-Spam-Status: No, score=-2.236 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0RHB2Ge6Wz-J for ; Tue, 2 Sep 2014 07:53:47 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 401241A8752 for ; Tue, 2 Sep 2014 07:53:47 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 02D21C259; Tue, 2 Sep 2014 10:53:47 -0400 (EDT) Date: Tue, 2 Sep 2014 10:53:46 -0400 From: Jeffrey Haas To: Susan Hares Message-ID: <20140902145346.GD7736@pfrc> References: <025201cfc15c$bbe17260$33a45720$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <025201cfc15c$bbe17260$33a45720$@ndzh.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/Q1MqbmCS-GkC79GHXGrZfIM_EUU Cc: idr@ietf.org, "'John G. Scudder'" Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-ietf-idr-ls-distribut-impl X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 14:53:48 -0000 On Tue, Aug 26, 2014 at 02:37:04PM -0400, Susan Hares wrote: > This is a WG LC for > > > > http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/ > > http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution-impl/ > > > > Please respond with comments and "support or no support." This WG LC also > includes a request for the authors to provide IPR on the subject. I support this draft being published. One nit noted during review is that the various figures do not have any labeling but are at some points in the HTML document referred to by number. E.g. "figure 33". -- Jeff From nobody Tue Sep 2 11:56:09 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85EB71A0663 for ; Tue, 2 Sep 2014 11:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ZENOodKnFg7 for ; Tue, 2 Sep 2014 11:56:06 -0700 (PDT) Received: from mail-we0-f175.google.com (mail-we0-f175.google.com [74.125.82.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C12A1A0658 for ; Tue, 2 Sep 2014 11:56:05 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id k48so7412180wev.34 for ; Tue, 02 Sep 2014 11:56:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=csCkUKGfegKhLnf76N4BQsl8E+eTyyQn4gX2SJG0bfQ=; b=GROE8EOxmHERGq2QFzs5JgVRURqUR36HyVUGKz1GkBxxQua5G4oURXBTzPOYoSkyNT tKZhohDKnt0tJGdQp1MIZ0Y5ZJvw4o79YvaI2avv3pfoW83h6jIKNagRTtJHm/cLwGzJ b0CUA2H5oprfnZSdtpEgF4bW5iCtHkLUAC69B0WIJQNBIpZMTselaPJ7wOZlVSZBV0mF PAb/gHt3/irpCmGBVMELcfV/3ryERGr/GokGzpdPRiP0t97mXilfKiO1yxP+OSZ01YLk D+e2FHTAuqzWFgNkgjvZQS3Q+vBXiL5HEwOPOVwMLtGWg0HhOpKcBRppZSsRB51SZe/N 5AEQ== X-Gm-Message-State: ALoCoQk65EvCRbKysPKlUxnmsibMd/66XqfR+sF/xum+DPOEBDLp4dR8BQMUktdAHISgXWZ5ostg MIME-Version: 1.0 X-Received: by 10.194.191.165 with SMTP id gz5mr41142344wjc.16.1409684164043; Tue, 02 Sep 2014 11:56:04 -0700 (PDT) Received: by 10.194.62.39 with HTTP; Tue, 2 Sep 2014 11:56:03 -0700 (PDT) In-Reply-To: <018e01cfc146$4be6c480$e3b44d80$@ndzh.com> References: <018e01cfc146$4be6c480$e3b44d80$@ndzh.com> Date: Tue, 2 Sep 2014 14:56:03 -0400 Message-ID: From: Warren Kumari To: Susan Hares Content-Type: multipart/alternative; boundary=047d7b873878d7fe15050219ab76 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/QaaHQJvc7eYw-CMsA9r5od-BK2Q Cc: idr wg , Alia Atlas Subject: Re: [Idr] WG LC X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 18:56:07 -0000 --047d7b873878d7fe15050219ab76 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Support. Eom W On Tuesday, August 26, 2014, Susan Hares wrote: > This is a 2 week WGT LC on draft-ietf-idr-as-migration starting 8/26/2014 > and ending 9/6/2014. > > > > The draft can be accessed at: > > > > http://datatracker.ietf.org/doc/draft-ietf-idr-as-migration/ > > > > Please include in your call =E2=80=9Csupport or no support=E2=80=9D. Th= is call also ask > the authors to indicate if there is any IPR related to the draft. > > > > Sue > --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf --047d7b873878d7fe15050219ab76 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Support.

Eom
W

On Tuesday,= August 26, 2014, Susan Hares <shares= @ndzh.com> wrote:

This is a 2 week WGT LC on draft-ietf-idr-as-migration starting 8/26/20= 14 and ending 9/6/2014.

=C2= =A0

The draft can be accessed at:

=C2=A0

http://datatracker.ietf.org/doc/draft-ietf-idr-as-migration/

=C2=A0

Pleas= e include in your call =E2=80=9Csupport or no support=E2=80=9D.=C2=A0=C2=A0= This call also ask the authors to indicate if there is any IPR related to = the draft.

=C2=A0

Sue

=


--
I don't think the execution is = relevant when it was obviously a bad idea in the first place.
This is li= ke putting rabid weasels in your pants, and later expressing regret at havi= ng chosen those particular rabid weasels and that pair of pants.
=C2=A0 =C2=A0---maf
--047d7b873878d7fe15050219ab76-- From nobody Tue Sep 2 14:03:38 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 442641A069B for ; Tue, 2 Sep 2014 14:03:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.568 X-Spam-Level: X-Spam-Status: No, score=-14.568 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, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OdBtpx-ciF9v for ; Tue, 2 Sep 2014 14:03:31 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 724DB1A06EB for ; Tue, 2 Sep 2014 14:03:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=52283; q=dns/txt; s=iport; t=1409691810; x=1410901410; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=0TPqNI3VlfI6q28ecSTFV50YAKXA7iM0dA48lR/dPXw=; b=fSGKqJhdtuBWXHQQEyAYXiHBaJkUTb6pbsugTboGoAmRAh6pspd9ceUB s2+bS+JWyLPOf8Y7P7jzXI8Tm2cuguxiVfPFMEZ+s1j6X9Z1rRb7ENIUy 9q08SuSznGfB7sPTxuc3JnXIHEIUkRO06cDcDDQrJFR5xvBD7AnqhxMAQ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQGACswBlStJV2R/2dsb2JhbABagkdGU1cEhBSuS5NcgV8BC4dKAYETFneEAwEBAQQBAQEXTQcLEAIBCBEDAQEBIQEGBycLFAkIAgQBDQWIQg28ewEXjmsLBgE+AQcGBAYBhEwFgViEPIkJghSELoZ9gVuKcIhTgW8WFoFGbAGBBggXIoEHAQEB X-IronPort-AV: E=Sophos; i="5.04,451,1406592000"; d="scan'208,217"; a="74354237" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-4.cisco.com with ESMTP; 02 Sep 2014 21:03:28 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s82L3Sfp025854 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Sep 2014 21:03:28 GMT Received: from xmb-rcd-x13.cisco.com ([169.254.3.228]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0195.001; Tue, 2 Sep 2014 16:03:27 -0500 From: "Saikat Ray (sairay)" To: "lizhenqiang@chinamobile.com" , "Hannes Gredler" Thread-Topic: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-ietf-idr-ls-distribut-impl Thread-Index: AQHPxoW/KyLgv7j6UUmOKYCHg5K+6pvt2HeA///alIeAAIEOgA== Date: Tue, 2 Sep 2014 21:03:27 +0000 Message-ID: References: <025201cfc15c$bbe17260$33a45720$@ndzh.com> <1B502206DFA0C544B7A60469152008633F364057@eusaamb105.ericsson.se> <20140901180518.GA34789@juniper.net> <2014090214443576954410@chinamobile.com> <1409642967216.58954@juniper.net> <2014090216125846667724@chinamobile.com> <20140902083527.GC39341@juniper.net> <2014090219212399332244@chinamobile.com> In-Reply-To: <2014090219212399332244@chinamobile.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [128.107.165.83] Content-Type: multipart/alternative; boundary="_000_D02B7B901FCFCsairayciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/aJflgXxoY7tuPFUSd8EZPfYHMSk Cc: 'idr wg' , "'John G. Scudder'" , Susan Hares Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-ietf-idr-ls-distribut-impl X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 21:03:35 -0000 --_000_D02B7B901FCFCsairayciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Zhenqiang: For the NLRIs that uses a "type" field, such as MVPN (see RFC6514), the con= vention is to encode the type field before the length field. This allows fo= r greatest flexibility for future extensions. In BGP-LS, we have used the s= ame convention. Other than that, the RD is for the entire bgp-ls object (be it a Node, Link= or Prefix). So placing the RD field before other fields is logically accur= ate. Thanks. From: "lizhenqiang@chinamobile.com" > Date: Tuesday, September 2, 2014 at 4:21 AM To: Hannes Gredler > Cc: "idr@ietf.org" >= , "shares@ndzh.com" >, 'John Scudder' > Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-ietf-= idr-ls-distribut-impl Hi Hannes, One example to explain the differences. One VPN route with prefix length 24= is carried in the NRLI. The format this draft specified is as follows. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NLRI Type =3D 3 | Total NLRI Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Route Distinguisher + | | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | | (64 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Local Node Descriptor (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 265 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length =3D 24 | IP Prefix (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The format RFC4363 specified is as follows. +---------------------------------------------------------+ | Address Family Identifier (2 octets) | +---------------------------------------------------------+ | Subsequent Address Family Identifier (1 octet) | +---------------------------------------------------------+ | Length of Next Hop Network Address (1 octet) | +---------------------------------------------------------+ | Network Address of Next Hop (variable) | +---------------------------------------------------------+ | Reserved (1 octet) | +---------------------------------------------------------+ | Prefix Length =3D 88 | IP Prefix (variable) =3D RD followed by IP prefix= // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ ________________________________ lizhenqiang@chinamobile.com From: Hannes Gredler Date: 2014-09-02 16:35 To: lizhenqiang@chinamobile.com CC: Uma Chunduri; 'idr wg'; 'John G. Scudder'; Susan Hares Subject: Re: RE: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-i= etf-idr-ls-distribut-impl hi zhenqiang, On Tue, Sep 02, 2014 at 04:12:58PM +0800, lizhenqiang@chinamobile.com wrote: | Two types of link state NLRIs are defined in section 3.2 of this | draft, AFI 16388 / SAFI 71 for non-VPN, AFI 16388 / SAFI 128 for VPN. correct; | My question is about AFI 16388 / SAFI 128 NLRI. From the figure in pag= e 9 | of draft version 5, we can see that RD is put before link state NLRI. from http://tools.ietf.org/html/draft-ietf-idr-ls-distribution-05#section-3= .2 this is the NLRI format for AFI 16388 / SAFI 71 (unicast) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NLRI Type | Total NLRI Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Link-State NLRI (variable) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ and this is the NLRI format for AFI 16388 / SAFI 128 (VPN-unicast) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NLRI Type | Total NLRI Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Route Distinguisher + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Link-State NLRI (variable) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | The link state NLRI field in this figure contains the IP prefix. As RF= C4364 | specifies, the VPN routes should be carried in the NLRI prepending wit= h | RD. that is what we do - i fail to see the offending part with respect to RFC43= 64. /hannes | | From: [1]Hannes Gredler | Date: 2014-09-02 15:29 | To: [2]lizhenqiang@chinamobile.com; [3]Uma Chunduri | CC: [4]'idr wg'; [5]'John G. Scudder'; [6]Susan Hares | Subject: RE: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and | draft-ietf-idr-ls-distribut-impl | | hi zhenqiang, | | The Route-distinguisher's purpose is to add 64-bits of disambiguati= ng | entropy to the NLRI, such | | that the route-reflectors do not "swallow" that path as part of the | best-path election | | procedure. The link-state NLRI (encapsulated in MP_REACH/ MP UNREACH= PA) | | is a RD-less version of the vpn-link-state NLRI. | | In a certain way these correspond to RFC3107 / RFC4364 NLRI formats. | | The former is a RD-less version of the latter. | | On your question "Why do't you put RD in IP Reachability Information= , | just prepending RD with IP prefix as RFC4364 specifies." - This is | actually what we *are* doing - we put the RD before the link-state N= LRI | inside the MP_REACH/MP_UNREACH Attribute. | | HTH, | | /hannes | | ----------------------------------------------------------------------= ---- | | From: lizhenqiang@chinamobile.com > | Sent: Tuesday, September 02, 2014 8:44 | To: Hannes Gredler; Uma Chunduri | Cc: 'idr wg'; 'John G. Scudder'; Susan Hares | Subject: Re: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and | draft-ietf-idr-ls-distribut-impl | | One question about the VPN Link-State NLRI in section 3.2. Why do yo= u | put the RD before link state NRLI? Why do't you put RD in IP | Reachability Information, just preprending RD with IP prefix as RFC4= 364 | specifies. | | ----------------------------------------------------------------------= ---- | | lizhenqiang@chinamobile.com | | | From: [7]Hannes Gredler | Date: 2014-09-02 02:05 | To: [8]Uma Chunduri | CC: [9]idr@ietf.org; [10]'John G. Scudder'; [= 11]Susan Hares | Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and | draft-ietf-idr-ls-distribut-impl | hi uma, | | see comments/responses inline: | | On Wed, Aug 27, 2014 at 11:07:01AM +0000, Uma Chunduri wrote: | | Support. | | | | I see, hierarchy is WELL defined when multiple instances of = IGP | with | | multiple AFs are running. Good work. | | | | | | | | Have following Qs: | | | | 1. Any discussion of the delay introduced by BGP (packi= ng, | update | | generation, processing etc..) to transport the LS information | | | | especially, when LSDB is changing faster perhaps with large | number of | | nodes/links inside an AS and with multiple ASes) to the | controller will be | | useful. | | this is highly implementation dependent; - | some vendors do the packaging of BGP updates entirely event-driven | and others pack things up and have a worst case delay between | the trigger event and the BGP update. the protocol | itself does not prohibit/limit the propagation speed. | (in fact it can be shown that sometimes updates | travel faster on the (dataplane forwarded) iBGP mesh, | rather than propgate using the hop-by-hop control-plane flooding | protocol) | | | A note on the sensitivity of this delay to the | consumer | | (applications) at the controller can be helpful. I saw very | little | | discussion in Section 6 (6.1.5) | | difficiult - its hard to have some sort of general comment as thin= gs | are | highly implementation dependent. | | | | 2. This document encompasses pretty much both OSPF and = ISIS | | extensions done till date. How it will keep up with future | extensions in | | OSPF/ISIS. | | we have set up an IANA registries for the carriers of information. | it is expected by authors of "topological relevant" IGP extensions | to supply also BGP-LS extensions. | | | A mechanism in place would be helpful. My suggestion would be= - | the | | respective IGP documents should assess the impact and define | | | | corresponding new TLVs for BGP LS? But how this can be enforc= ed? | | i have no idea - today its entirely voluntary. | | | 3. Section 4, gives glimpse what's possible and the nod= e | aggregating | | the links obviously need to tinker the LSDB to represent the = same | | correctly. | | | | Some more details would be helpful to represent the changes o= n | | aggregation/de-aggregation subsequently. | | this may quickly get you into the "abstracted topology models" | discussion that keeps emerging periodically. - | we did not want to stop progress on the protocol by arguing | "whats the right abstraction model" and have agreed | on the minimalistic nature of the section as-is. | | | | 4. Section 6.2 has empty sub-sections and TBDs. | | right ... so suggest to remove section 6.2 altogether. | | | 5. It's good to see Implementation report shed light on | performance | | seen with multiple ASes. | | | | 6. It's good to see if any application of policy on LSD= B is | done | | (one of the primary drivers of the specification). | | | thanks, | | | /hannes | | | | | From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Ha= res | | Sent: Tuesday, August 26, 2014 11:37 AM | | To: idr@ietf.org | | Cc: 'John G. Scudder'; shares@ndzh.com | | Subject: [Idr] WG LC for draft-ietf-idr-ls-distribution and | | draft-ietf-idr-ls-distribut-impl | | | | | | | | This is a WG LC for | | | | | | | | | [1]http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/ | | | | | [2]http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution-= impl/ | | | | | | | | Please respond with comments and "support or no support." Th= is | WG LC also | | includes a request for the authors to provide IPR on the subj= ect. | | | | | | | | Please note: due to the European vacations in August, we are | bundling | | these three reviews into the next two weeks (these two drafts= and | | draft-ietf-as-migration). The chairs would like feedback (l= ist | or | | private email) whether the three WG LC s impact anyone's abil= ity | to review | | these drafts carefully. | | | | | | | | Thank you, | | | | | | | | Sue Hares and John Scudder | | | | References | | | | Visible links | | 1. | http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/ | | 2. | http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution-imp= l/ | | | _______________________________________________ | | Idr mailing list | | Idr@ietf.org | | https://www.ietf.org/mailman/listinfo/idr | | _______________________________________________ | Idr mailing list | Idr@ietf.org | https://www.ietf.org/mailman/listinfo/idr | | | References | | Visible links | 1. mailto:hannes@juniper.net | 2. mailto:lizhenqiang@chinamobile.com | 3. mailto:uma.chunduri@ericsson.com | 4. mailto:idr@ietf.org | 5. mailto:jgs@bgp.nu | 6. mailto:shares@ndzh.com | 7. mailto:hannes@juniper.net | 8. mailto:uma.chunduri@ericsson.com | 9. mailto:idr@ietf.org | 10. mailto:jgs@bgp.nu | 11. mailto:shares@ndzh.com --_000_D02B7B901FCFCsairayciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <42F6C8216C9C3B459A7A5265575B9694@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Zhenqiang:=

For the NLRIs that uses a "type" field, such as MVPN (see RFC6514= ), the convention is to encode the type field before the length field. This= allows for greatest flexibility for future extensions. In BGP-LS, we have = used the same convention.

Other than that, the RD is for the entire bgp-ls object (be it a Node, Link= or Prefix). So placing the RD field before other fields is logically accur= ate.

Thanks.

From: "lizhenqiang@chinamobile.com" <lizhenqiang@chinamobile.com>=
Date: Tuesday, September 2, 2014 at= 4:21 AM
To: Hannes Gredler <hannes@juniper.net>
Cc: "idr@ietf.org" <idr@ietf.= org>, "shares@ndzh.com&q= uot; <shares@ndzh.com>, 'John Scudder' <jgs@bgp.nu>
Subject: Re: [Idr] WG LC for draft-= ietf-idr-ls-distribution and draft-ietf-idr-ls-distribut-impl

Hi Hannes,

One example to explain the differences. One VPN route with prefix leng= th 24 is carried in the NRLI.

The format this draft specified is as follows.
+-+-+-+-+-+-+-+-+-+-+-+= ;-+-+-+-+-+-+-+-+-+-+-+-+-&= #43;-+-+-+-+-+-+-+-+
 |          &nb= sp; NLRI Type =3D 3         |     T= otal NLRI Length         |
+-+-+-+-+-+-+-+-+-+-+-+= ;-+-+-+-+-+-+-+-+-+-+-+-+-&= #43;-+-+-+-+-+-+-+-+
 |          &nb= sp;            =             &nb= sp;            =             &nb= sp;  |
+           = ;            Route D= istinguisher          &nb= sp;          +
 |          &nb= sp;            =             &nb= sp;            =             &nb= sp;  |
+-+-+-= +-+-+-+-+-+ +-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+=
| Protocol-ID |
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
| Identifier |
| (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
// Local Node Descriptor (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
| Type =3D 265 &nb= sp;                     &= nbsp;    | Length |
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
| Prefix Length =3D 24 | IP Prefix (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+


The format RFC4363 specified is as follows.
+-------------= --------------------------------------------+
| Address Family Identifier (2 octets) |
+---------------------------------------------------------+
| Subsequent Address Family Identifier (1 octet) |
+---------------------------------------------------------+
| Length of Next Hop Network Address (1 octet) |
+---------------------------------------------------------+
| Network Address of Next Hop (variable) |
+---------------------------------------------------------+
| Reserved (1 octet) |
+---------------------------------------------------------+
| Prefix Length =3D 88 |  IP Prefix (variable) =3D RD followed = by IP prefix // 
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-++

 
Date: 2014-09-02 16:35
Subject: Re: RE: [Idr] WG LC for draft-ietf-idr-ls-distrib= ution and draft-ietf-idr-ls-distribut-impl
hi zhenqiang,
 
On Tue, Sep 02, 2014 at 04:12:58PM +0800, lizhenqiang@chinamobile.com wrote:
|    Two types of link state NLRIs are defined in secti= on 3.2 of this
|    draft, AFI 16388 / SAFI 71 for non-VPN, AFI 16388 = / SAFI 128 for VPN.
 
correct;
 
|    My question is about AFI 16388 / SAFI 128 NLRI. Fr= om the figure in page 9
|    of draft version 5, we can see that RD is put befo= re link state NLRI.
 
 
 
this is the NLRI format for AFI 16388 / SAFI 71 (unicast)
 
    0        &n= bsp;          1  &nb= sp;            =     2         &= nbsp;         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
   +-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+
   |         &n= bsp;  NLRI Type          = |     Total NLRI Length     &n= bsp;   |
   +-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+
   |         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;   |
   //         &= nbsp;        Link-State NLRI (variable)&= nbsp;           &nbs= p;    //
   |         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;   |
   +-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+
 
and this is the NLRI format for AFI 16388 / SAFI 128 (VPN-unicast)
 
    0        &n= bsp;          1  &nb= sp;            =     2         &= nbsp;         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
   +-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+
   |         &n= bsp;  NLRI Type          = |     Total NLRI Length     &n= bsp;   |
   +-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+
   |         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;   |
   +        &nbs= p;            &= nbsp; Route Distinguisher        &n= bsp;            += ;
   |         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;   |
   +-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+
   |         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;   |
   //         &= nbsp;        Link-State NLRI (variable)&= nbsp;           &nbs= p;    //
   |         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;   |
   +-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+
 
 
 
|    The link state NLRI field in this figure contains = the IP prefix. As RFC4364
|    specifies, the VPN routes should be carried in the= NLRI prepending with
|    RD.
 
that is what we do - i fail to see the offending part with respect to = RFC4364.
 
/hannes
 
|
|      From: [1]Hannes Gredler
|      Date: 2014-09-02 15:29
|      CC: [4]'idr wg'; [5]'John G. Scudder';= [6]Susan Hares
|      Subject: RE: Re: [Idr] WG LC for draft= -ietf-idr-ls-distribution and
|      draft-ietf-idr-ls-distribut-impl
|
|      hi zhenqiang,
|
|      The Route-distinguisher's purpose is t= o add 64-bits of  disambiguating
|      entropy to the NLRI, such
|
|      that the route-reflectors do not "= ;swallow" that path as part of the
|      best-path election
|
|      procedure. The link-state NLRI (encaps= ulated in MP_REACH/ MP UNREACH PA)
|
|      is a RD-less version of the vpn-link-s= tate NLRI.
|
|      In a certain way these correspond to R= FC3107 / RFC4364 NLRI formats.
|
|      The former is a RD-less version of the= latter.
|
|      On your question "Why do't you pu= t RD in IP Reachability Information,
|      just prepending RD with IP prefix as R= FC4364 specifies." - This is
|      actually what we *are* doing - we put = the RD before the link-state NLRI
|      inside the MP_REACH/MP_UNREACH Attribu= te.
|
|      HTH,
|
|      /hannes
|
|    --------------------------------------------------= ------------------------
|
|      Sent: Tuesday, September 02, 2014 8:44=
|      To: Hannes Gredler; Uma Chunduri
|      Cc: 'idr wg'; 'John G. Scudder'; Susan= Hares
|      Subject: Re: Re: [Idr] WG LC for draft= -ietf-idr-ls-distribution and
|      draft-ietf-idr-ls-distribut-impl
|
|      One question about the VPN Link-State = NLRI in section 3.2. Why do you
|      put the RD before link state NRLI? Why= do't you put RD in IP
|      Reachability Information, just prepren= ding RD with IP prefix as RFC4364
|      specifies.
|
|    --------------------------------------------------= ------------------------
|
|
|
|        From: [7]Hannes Gredler
|        Date: 2014-09-02 02:05
|        To: [8]Uma Chunduri
|        CC: [9]idr@ietf.org; [10]'John G. Scudder'; [11]Susan Hares
|        Subject: Re: [Idr] WG LC f= or draft-ietf-idr-ls-distribution and
|        draft-ietf-idr-ls-distribu= t-impl
|        hi uma,
|
|        see comments/responses inl= ine:
|
|        On Wed, Aug 27, 2014 at 11= :07:01AM +0000, Uma Chunduri wrote:
|        |    Suppor= t.
|        |
|        |    I see,= hierarchy is WELL  defined when multiple instances of IGP
|        with
|        |    multip= le AFs are running. Good work.
|        |
|        |
|        |
|        |    Have f= ollowing Qs:
|        |
|        |    1.&nbs= p;      Any discussion of the delay introduced by = BGP (packing,
|        update
|        |    genera= tion, processing etc..) to transport the LS information
|        |
|        |    especi= ally, when LSDB is changing faster perhaps with large
|        number of
|        |    nodes/= links inside an AS and with multiple ASes) to the
|        controller will be
|        |    useful= .
|
|        this is highly implementat= ion dependent; -
|        some vendors do the packag= ing of BGP updates entirely event-driven
|        and others pack things up = and have a worst case delay between
|        the trigger event and the = BGP update. the protocol
|        itself does not prohibit/l= imit the propagation speed.
|        (in fact it can be shown t= hat sometimes updates
|        travel faster on the (data= plane forwarded) iBGP mesh,
|        rather than propgate using= the hop-by-hop control-plane flooding
|        protocol)
|
|        |    &= nbsp;            A n= ote on the sensitivity of this delay to the
|        consumer
|        |    (appli= cations) at the controller  can be helpful. I saw very
|        little
|        |    discus= sion in Section 6 (6.1.5)
|
|        difficiult - its hard to h= ave some sort of general comment as things
|        are
|        highly implementation depe= ndent.
|
|
|        |    2.&nbs= p;      This document encompasses pretty much both= OSPF and ISIS
|        |    extens= ions done till date. How it will keep up with future
|        extensions in
|        |    OSPF/I= SIS.
|
|        we have set up an IANA reg= istries for the carriers of information.
|        it is expected by authors = of "topological relevant" IGP extensions
|        to supply also BGP-LS exte= nsions.
|
|        |    A mech= anism in place would be helpful. My suggestion would be-
|        the
|        |    respec= tive IGP documents should assess the impact and define
|        |
|        |    corres= ponding new TLVs for BGP LS? But how this can be enforced?
|
|        i have no idea - today its= entirely voluntary.
|
|        |    3.&nbs= p;      Section 4, gives glimpse what's possible a= nd the node
|        aggregating
|        |    the li= nks obviously need to tinker the LSDB to represent the same
|        |    correc= tly.
|        |
|        |    Some m= ore details would be helpful to represent the changes on
|        |    aggreg= ation/de-aggregation subsequently.
|
|        this may quickly get you i= nto the "abstracted topology models"
|        discussion that keeps emer= ging  periodically. -
|        we did not want to stop pr= ogress on the protocol by arguing
|        "whats the right abst= raction model" and have agreed
|        on the minimalistic nature= of the section as-is.
|
|
|        |    4.&nbs= p;      Section 6.2 has empty sub-sections and TBD= s.
|
|        right ... so suggest to re= move section 6.2 altogether.
|
|        |    5.&nbs= p;      It's good to see Implementation report she= d light on
|        performance
|        |    seen w= ith multiple ASes.
|        |
|        |    6.&nbs= p;      It's good to see if any application of pol= icy on LSDB is
|        done
|        |    (one o= f the primary drivers of the specification).
|
|
|        thanks,
|
|
|        /hannes
|
|        |
|        |    From: = Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
|        |    Sent: = Tuesday, August 26, 2014 11:37 AM
|        |    Cc: 'J= ohn G. Scudder'; shares@ndzh.com
|        |    Subjec= t: [Idr] WG LC for draft-ietf-idr-ls-distribution and
|        |    draft-= ietf-idr-ls-distribut-impl
|        |
|        |
|        |
|        |    This i= s a WG LC for
|        |
|        |
|        |
|        |
|        |
|        |
|        |
|        |
|        |
|        |    Please= respond with comments and "support or no support."  This
|        WG LC also
|        |    includ= es a request for the authors to provide IPR on the subject.
|        |
|        |
|        |
|        |    Please= note: due to the European vacations in August, we are
|        bundling
|        |    these = three reviews into the next two weeks (these two drafts and
|        |    draft-= ietf-as-migration).   The chairs would like feedback (list
|        or
|        |    privat= e email) whether the three WG LC s impact anyone's ability
|        to review
|        |    these = drafts carefully.
|        |
|        |
|        |
|        |    Thank = you,
|        |
|        |
|        |
|        |    Sue Ha= res and John Scudder
|        |
|        | References
|        |
|        |    Visibl= e links
|        |    1.
|        |    2.
|        http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution-impl/
|
|        | ________________________= _______________________
|        | Idr mailing list
|        | Idr@ietf.org
|
|        __________________________= _____________________
|        Idr mailing list
|        Idr@ietf.org
 --_000_D02B7B901FCFCsairayciscocom_-- From nobody Tue Sep 2 19:18:43 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86D661A8968 for ; Tue, 2 Sep 2014 19:18:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.255 X-Spam-Level: X-Spam-Status: No, score=0.255 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5zGdg51m7fFs for ; Tue, 2 Sep 2014 19:18:34 -0700 (PDT) Received: from cmccmta1.chinamobile.com (cmccmta1.chinamobile.com [221.176.66.79]) by ietfa.amsl.com (Postfix) with SMTP id 075551A8967 for ; Tue, 2 Sep 2014 19:18:32 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.121.9]) by rmmx-syy-dmz-app03-12003 (RichMail) with SMTP id 2ee354067a7605c-6f1c9; Wed, 03 Sep 2014 10:18:30 +0800 (CST) X-RM-TRANSID: 2ee354067a7605c-6f1c9 X-RM-SPAM-FLAG: 00000000 Received: from lizhenqiang (unknown[10.2.52.185]) by rmsmtp-syy-appsvr05-12005 (RichMail) with SMTP id 2ee554067a75966-ba510; Wed, 03 Sep 2014 10:18:30 +0800 (CST) X-RM-TRANSID: 2ee554067a75966-ba510 Date: Wed, 3 Sep 2014 10:18:50 +0800 From: "lizhenqiang@chinamobile.com" To: "Saikat Ray (sairay)" , "Hannes Gredler" References: <025201cfc15c$bbe17260$33a45720$@ndzh.com>, <1B502206DFA0C544B7A60469152008633F364057@eusaamb105.ericsson.se>, <20140901180518.GA34789@juniper.net>, <2014090214443576954410@chinamobile.com>, <1409642967216.58954@juniper.net>, <2014090216125846667724@chinamobile.com>, <20140902083527.GC39341@juniper.net>, <2014090219212399332244@chinamobile.com>, X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 5, 140[cn] Mime-Version: 1.0 Message-ID: <2014090310185037697516@chinamobile.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart671221528844_=----" Archived-At: http://mailarchive.ietf.org/arch/msg/idr/bVS1nC8YGB47ZC20yEB6eeuN3E0 Cc: 'idr wg' , "'John G. Scudder'" , Susan Hares Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-ietf-idr-ls-distribut-impl X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 02:18:38 -0000 This is a multi-part message in MIME format. ------=_001_NextPart671221528844_=---- Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 UGxhY2luZyB0aGUgdHlwZSBmaWVsZCBiZWZvcmUgdGhlIGxlbmd0aCBmaWVsZCBpcyBmaW5lIGZv ciBtZS4NCg0KVGhlIGVuY29kaW5nIGZvcm1hdCBmb3IgUkQgaW4gdGhpcyBkcmFmdCBpcyBub3Qg Y29uc2lzdGVudCB3aXRoIFJGQzQzNjQuIFRoaXMgaXMgdGhlIHF1ZXN0aW9uLiBSRkM2NTE0IHNh eXMgIlRoZSBSb3V0ZSBEaXN0aW5ndWlzaGVyIChSRCkgaXMgZW5jb2RlZCBhcyBkZXNjcmliZWQg aW4gW1JGQzQzNjRdIiwgcGxlYXNlIHNlZSBzZWN0aW9uIDQgb2YgUkZDNjUxNC4NCg0KSSBhZ3Jl ZSB3aXRoIHlvdSBmb3IgdGhlIGFkdmFudGFnZSB0byBwdXQgdGhlIFJEIGJlZm9yZSBvdGhlciBm aWVsZHMuIEkgcmFpc2UgdGhpcyBxdWVzaXRvbiBqdXN0IGZvciBjbGFyaWZpY2F0aW9uLg0KDQoN Cg0KbGl6aGVucWlhbmdAY2hpbmFtb2JpbGUuY29tDQogDQpGcm9tOiBTYWlrYXQgUmF5IChzYWly YXkpDQpEYXRlOiAyMDE0LTA5LTAzIDA1OjAzDQpUbzogbGl6aGVucWlhbmdAY2hpbmFtb2JpbGUu Y29tOyBIYW5uZXMgR3JlZGxlcg0KQ0M6ICdpZHIgd2cnOyBTdXNhbiBIYXJlczsgJ0pvaG4gRy4g U2N1ZGRlcicNClN1YmplY3Q6IFJlOiBbSWRyXSBXRyBMQyBmb3IgZHJhZnQtaWV0Zi1pZHItbHMt ZGlzdHJpYnV0aW9uIGFuZCBkcmFmdC1pZXRmLWlkci1scy1kaXN0cmlidXQtaW1wbA0KSGkgWmhl bnFpYW5nOg0KDQpGb3IgdGhlIE5MUklzIHRoYXQgdXNlcyBhICJ0eXBlIiBmaWVsZCwgc3VjaCBh cyBNVlBOIChzZWUgUkZDNjUxNCksIHRoZSBjb252ZW50aW9uIGlzIHRvIGVuY29kZSB0aGUgdHlw ZSBmaWVsZCBiZWZvcmUgdGhlIGxlbmd0aCBmaWVsZC4gVGhpcyBhbGxvd3MgZm9yIGdyZWF0ZXN0 IGZsZXhpYmlsaXR5IGZvciBmdXR1cmUgZXh0ZW5zaW9ucy4gSW4gQkdQLUxTLCB3ZSBoYXZlIHVz ZWQgdGhlIHNhbWUgY29udmVudGlvbi4NCg0KT3RoZXIgdGhhbiB0aGF0LCB0aGUgUkQgaXMgZm9y IHRoZSBlbnRpcmUgYmdwLWxzIG9iamVjdCAoYmUgaXQgYSBOb2RlLCBMaW5rIG9yIFByZWZpeCku IFNvIHBsYWNpbmcgdGhlIFJEIGZpZWxkIGJlZm9yZSBvdGhlciBmaWVsZHMgaXMgbG9naWNhbGx5 IGFjY3VyYXRlLg0KDQpUaGFua3MuDQoNCkZyb206ICJsaXpoZW5xaWFuZ0BjaGluYW1vYmlsZS5j b20iIDxsaXpoZW5xaWFuZ0BjaGluYW1vYmlsZS5jb20+DQpEYXRlOiBUdWVzZGF5LCBTZXB0ZW1i ZXIgMiwgMjAxNCBhdCA0OjIxIEFNDQpUbzogSGFubmVzIEdyZWRsZXIgPGhhbm5lc0BqdW5pcGVy Lm5ldD4NCkNjOiAiaWRyQGlldGYub3JnIiA8aWRyQGlldGYub3JnPiwgInNoYXJlc0BuZHpoLmNv bSIgPHNoYXJlc0BuZHpoLmNvbT4sICdKb2huIFNjdWRkZXInIDxqZ3NAYmdwLm51Pg0KU3ViamVj dDogUmU6IFtJZHJdIFdHIExDIGZvciBkcmFmdC1pZXRmLWlkci1scy1kaXN0cmlidXRpb24gYW5k IGRyYWZ0LWlldGYtaWRyLWxzLWRpc3RyaWJ1dC1pbXBsDQoNCkhpIEhhbm5lcywNCg0KT25lIGV4 YW1wbGUgdG8gZXhwbGFpbiB0aGUgZGlmZmVyZW5jZXMuIE9uZSBWUE4gcm91dGUgd2l0aCBwcmVm aXggbGVuZ3RoIDI0IGlzIGNhcnJpZWQgaW4gdGhlIE5STEkuDQoNClRoZSBmb3JtYXQgdGhpcyBk cmFmdCBzcGVjaWZpZWQgaXMgYXMgZm9sbG93cy4NCistKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogfCAgICAgICAgICAgIE5M UkkgVHlwZSA9IDMgICAgICAgICB8ICAgICBUb3RhbCBOTFJJIExlbmd0aCAgICAgICAgIHwNCist Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rDQogfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwNCisgICAgICAgICAgICAgICAgICAgICAgIFJvdXRlIERpc3Rpbmd1 aXNoZXIgICAgICAgICAgICAgICAgICAgICArDQogfCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCistKy0rLSstKy0rLSstKy0r ICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQp8IFByb3RvY29sLUlE IHwgDQorLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKyANCnwgSWRlbnRpZmllciB8IA0KfCAoNjQgYml0cykgfCANCistKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r IA0KLy8gTG9jYWwgTm9kZSBEZXNjcmlwdG9yICh2YXJpYWJsZSkgLy8gDQorLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyANCnwg VHlwZSA9IDI2NSAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IExlbmd0aCB8IA0KKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSsgDQp8IFByZWZpeCBMZW5ndGggPSAyNCB8IElQIFByZWZpeCAodmFyaWFibGUpIC8vIA0KKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSsNCg0KDQpUaGUgZm9ybWF0IFJGQzQzNjMgc3BlY2lmaWVkIGlzIGFzIGZvbGxvd3MuDQor LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t KyANCnwgQWRkcmVzcyBGYW1pbHkgSWRlbnRpZmllciAoMiBvY3RldHMpIHwgDQorLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKyANCnwgU3Vi c2VxdWVudCBBZGRyZXNzIEZhbWlseSBJZGVudGlmaWVyICgxIG9jdGV0KSB8IA0KKy0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsgDQp8IExl bmd0aCBvZiBOZXh0IEhvcCBOZXR3b3JrIEFkZHJlc3MgKDEgb2N0ZXQpIHwgDQorLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKyANCnwgTmV0 d29yayBBZGRyZXNzIG9mIE5leHQgSG9wICh2YXJpYWJsZSkgfCANCistLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rIA0KfCBSZXNlcnZlZCAo MSBvY3RldCkgfCANCistLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0rIA0KfCBQcmVmaXggTGVuZ3RoID0gODggfCAgSVAgUHJlZml4ICh2YXJp YWJsZSkgPSBSRCBmb2xsb3dlZCBieSBJUCBwcmVmaXggLy8gDQorLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKysNCg0KDQoNCmxp emhlbnFpYW5nQGNoaW5hbW9iaWxlLmNvbQ0KIA0KRnJvbTogSGFubmVzIEdyZWRsZXINCkRhdGU6 IDIwMTQtMDktMDIgMTY6MzUNClRvOiBsaXpoZW5xaWFuZ0BjaGluYW1vYmlsZS5jb20NCkNDOiBV bWEgQ2h1bmR1cmk7ICdpZHIgd2cnOyAnSm9obiBHLiBTY3VkZGVyJzsgU3VzYW4gSGFyZXMNClN1 YmplY3Q6IFJlOiBSRTogW0lkcl0gV0cgTEMgZm9yIGRyYWZ0LWlldGYtaWRyLWxzLWRpc3RyaWJ1 dGlvbiBhbmQgZHJhZnQtaWV0Zi1pZHItbHMtZGlzdHJpYnV0LWltcGwNCmhpIHpoZW5xaWFuZywN CiANCk9uIFR1ZSwgU2VwIDAyLCAyMDE0IGF0IDA0OjEyOjU4UE0gKzA4MDAsIGxpemhlbnFpYW5n QGNoaW5hbW9iaWxlLmNvbSB3cm90ZToNCnwgICAgVHdvIHR5cGVzIG9mIGxpbmsgc3RhdGUgTkxS SXMgYXJlIGRlZmluZWQgaW4gc2VjdGlvbiAzLjIgb2YgdGhpcw0KfCAgICBkcmFmdCwgQUZJIDE2 Mzg4IC8gU0FGSSA3MSBmb3Igbm9uLVZQTiwgQUZJIDE2Mzg4IC8gU0FGSSAxMjggZm9yIFZQTi4N CiANCmNvcnJlY3Q7DQogDQp8ICAgIE15IHF1ZXN0aW9uIGlzIGFib3V0IEFGSSAxNjM4OCAvIFNB RkkgMTI4IE5MUkkuIEZyb20gdGhlIGZpZ3VyZSBpbiBwYWdlIDkNCnwgICAgb2YgZHJhZnQgdmVy c2lvbiA1LCB3ZSBjYW4gc2VlIHRoYXQgUkQgaXMgcHV0IGJlZm9yZSBsaW5rIHN0YXRlIE5MUkku DQogDQogDQpmcm9tIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtaWRyLWxz LWRpc3RyaWJ1dGlvbi0wNSNzZWN0aW9uLTMuMg0KIA0KdGhpcyBpcyB0aGUgTkxSSSBmb3JtYXQg Zm9yIEFGSSAxNjM4OCAvIFNBRkkgNzEgKHVuaWNhc3QpDQogDQogICAgMCAgICAgICAgICAgICAg ICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAgMw0KICAgIDAgMSAy IDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAg MQ0KICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSsNCiAgIHwgICAgICAgICAgICBOTFJJIFR5cGUgICAgICAgICAgfCAgICAg VG90YWwgTkxSSSBMZW5ndGggICAgICAgICB8DQogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgfCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAg IC8vICAgICAgICAgICAgICAgICAgTGluay1TdGF0ZSBOTFJJICh2YXJpYWJsZSkgICAgICAgICAg ICAgICAgIC8vDQogICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgfA0KICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiANCmFuZCB0aGlzIGlzIHRoZSBO TFJJIGZvcm1hdCBmb3IgQUZJIDE2Mzg4IC8gU0FGSSAxMjggKFZQTi11bmljYXN0KQ0KIA0KICAg IDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAg ICAgIDMNCiAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIg MyA0IDUgNiA3IDggOSAwIDENCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICB8ICAgICAgICAgICAgTkxSSSBUeXBl ICAgICAgICAgIHwgICAgIFRvdGFsIE5MUkkgTGVuZ3RoICAgICAgICAgfA0KICAgKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsN CiAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8DQogICArICAgICAgICAgICAgICAgICAgICAgICBSb3V0ZSBEaXN0aW5ndWlz aGVyICAgICAgICAgICAgICAgICAgICAgKw0KICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICB8 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfA0KICAgLy8gICAgICAgICAgICAgICAgICBMaW5rLVN0YXRlIE5MUkkgKHZhcmlhYmxl KSAgICAgICAgICAgICAgICAgLy8NCiAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICArLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KIA0KIA0KIA0K fCAgICBUaGUgbGluayBzdGF0ZSBOTFJJIGZpZWxkIGluIHRoaXMgZmlndXJlIGNvbnRhaW5zIHRo ZSBJUCBwcmVmaXguIEFzIFJGQzQzNjQNCnwgICAgc3BlY2lmaWVzLCB0aGUgVlBOIHJvdXRlcyBz aG91bGQgYmUgY2FycmllZCBpbiB0aGUgTkxSSSBwcmVwZW5kaW5nIHdpdGgNCnwgICAgUkQuDQog DQp0aGF0IGlzIHdoYXQgd2UgZG8gLSBpIGZhaWwgdG8gc2VlIHRoZSBvZmZlbmRpbmcgcGFydCB3 aXRoIHJlc3BlY3QgdG8gUkZDNDM2NC4NCiANCi9oYW5uZXMNCiANCnwgDQp8ICAgICAgRnJvbTog WzFdSGFubmVzIEdyZWRsZXINCnwgICAgICBEYXRlOiAyMDE0LTA5LTAyIDE1OjI5DQp8ICAgICAg VG86IFsyXWxpemhlbnFpYW5nQGNoaW5hbW9iaWxlLmNvbTsgWzNdVW1hIENodW5kdXJpDQp8ICAg ICAgQ0M6IFs0XSdpZHIgd2cnOyBbNV0nSm9obiBHLiBTY3VkZGVyJzsgWzZdU3VzYW4gSGFyZXMN CnwgICAgICBTdWJqZWN0OiBSRTogUmU6IFtJZHJdIFdHIExDIGZvciBkcmFmdC1pZXRmLWlkci1s cy1kaXN0cmlidXRpb24gYW5kDQp8ICAgICAgZHJhZnQtaWV0Zi1pZHItbHMtZGlzdHJpYnV0LWlt cGwNCnwgDQp8ICAgICAgaGkgemhlbnFpYW5nLA0KfCANCnwgICAgICBUaGUgUm91dGUtZGlzdGlu Z3Vpc2hlcidzIHB1cnBvc2UgaXMgdG8gYWRkIDY0LWJpdHMgb2YgIGRpc2FtYmlndWF0aW5nDQp8 ICAgICAgZW50cm9weSB0byB0aGUgTkxSSSwgc3VjaA0KfCANCnwgICAgICB0aGF0IHRoZSByb3V0 ZS1yZWZsZWN0b3JzIGRvIG5vdCAic3dhbGxvdyIgdGhhdCBwYXRoIGFzIHBhcnQgb2YgdGhlDQp8 ICAgICAgYmVzdC1wYXRoIGVsZWN0aW9uDQp8IA0KfCAgICAgIHByb2NlZHVyZS4gVGhlIGxpbmst c3RhdGUgTkxSSSAoZW5jYXBzdWxhdGVkIGluIE1QX1JFQUNILyBNUCBVTlJFQUNIIFBBKQ0KfCAN CnwgICAgICBpcyBhIFJELWxlc3MgdmVyc2lvbiBvZiB0aGUgdnBuLWxpbmstc3RhdGUgTkxSSS4N CnwgDQp8ICAgICAgSW4gYSBjZXJ0YWluIHdheSB0aGVzZSBjb3JyZXNwb25kIHRvIFJGQzMxMDcg LyBSRkM0MzY0IE5MUkkgZm9ybWF0cy4NCnwgDQp8ICAgICAgVGhlIGZvcm1lciBpcyBhIFJELWxl c3MgdmVyc2lvbiBvZiB0aGUgbGF0dGVyLg0KfCANCnwgICAgICBPbiB5b3VyIHF1ZXN0aW9uICJX aHkgZG8ndCB5b3UgcHV0IFJEIGluIElQIFJlYWNoYWJpbGl0eSBJbmZvcm1hdGlvbiwNCnwgICAg ICBqdXN0IHByZXBlbmRpbmcgUkQgd2l0aCBJUCBwcmVmaXggYXMgUkZDNDM2NCBzcGVjaWZpZXMu IiAtIFRoaXMgaXMNCnwgICAgICBhY3R1YWxseSB3aGF0IHdlICphcmUqIGRvaW5nIC0gd2UgcHV0 IHRoZSBSRCBiZWZvcmUgdGhlIGxpbmstc3RhdGUgTkxSSQ0KfCAgICAgIGluc2lkZSB0aGUgTVBf UkVBQ0gvTVBfVU5SRUFDSCBBdHRyaWJ1dGUuDQp8IA0KfCAgICAgIEhUSCwNCnwgDQp8ICAgICAg L2hhbm5lcw0KfCANCnwgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCnwgDQp8ICAgICAgRnJvbTogbGl6 aGVucWlhbmdAY2hpbmFtb2JpbGUuY29tIDxsaXpoZW5xaWFuZ0BjaGluYW1vYmlsZS5jb20+DQp8 ICAgICAgU2VudDogVHVlc2RheSwgU2VwdGVtYmVyIDAyLCAyMDE0IDg6NDQNCnwgICAgICBUbzog SGFubmVzIEdyZWRsZXI7IFVtYSBDaHVuZHVyaQ0KfCAgICAgIENjOiAnaWRyIHdnJzsgJ0pvaG4g Ry4gU2N1ZGRlcic7IFN1c2FuIEhhcmVzDQp8ICAgICAgU3ViamVjdDogUmU6IFJlOiBbSWRyXSBX RyBMQyBmb3IgZHJhZnQtaWV0Zi1pZHItbHMtZGlzdHJpYnV0aW9uIGFuZA0KfCAgICAgIGRyYWZ0 LWlldGYtaWRyLWxzLWRpc3RyaWJ1dC1pbXBsDQp8IA0KfCAgICAgIE9uZSBxdWVzdGlvbiBhYm91 dCB0aGUgVlBOIExpbmstU3RhdGUgTkxSSSBpbiBzZWN0aW9uIDMuMi4gV2h5IGRvIHlvdQ0KfCAg ICAgIHB1dCB0aGUgUkQgYmVmb3JlIGxpbmsgc3RhdGUgTlJMST8gV2h5IGRvJ3QgeW91IHB1dCBS RCBpbiBJUA0KfCAgICAgIFJlYWNoYWJpbGl0eSBJbmZvcm1hdGlvbiwganVzdCBwcmVwcmVuZGlu ZyBSRCB3aXRoIElQIHByZWZpeCBhcyBSRkM0MzY0DQp8ICAgICAgc3BlY2lmaWVzLg0KfCANCnwg ICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCnwgDQp8ICAgICAgbGl6aGVucWlhbmdAY2hpbmFtb2JpbGUu Y29tDQp8IA0KfCANCnwgICAgICAgIEZyb206IFs3XUhhbm5lcyBHcmVkbGVyDQp8ICAgICAgICBE YXRlOiAyMDE0LTA5LTAyIDAyOjA1DQp8ICAgICAgICBUbzogWzhdVW1hIENodW5kdXJpDQp8ICAg ICAgICBDQzogWzldaWRyQGlldGYub3JnOyBbMTBdJ0pvaG4gRy4gU2N1ZGRlcic7IFsxMV1TdXNh biBIYXJlcw0KfCAgICAgICAgU3ViamVjdDogUmU6IFtJZHJdIFdHIExDIGZvciBkcmFmdC1pZXRm LWlkci1scy1kaXN0cmlidXRpb24gYW5kDQp8ICAgICAgICBkcmFmdC1pZXRmLWlkci1scy1kaXN0 cmlidXQtaW1wbA0KfCAgICAgICAgaGkgdW1hLA0KfCANCnwgICAgICAgIHNlZSBjb21tZW50cy9y ZXNwb25zZXMgaW5saW5lOg0KfCANCnwgICAgICAgIE9uIFdlZCwgQXVnIDI3LCAyMDE0IGF0IDEx OjA3OjAxQU0gKzAwMDAsIFVtYSBDaHVuZHVyaSB3cm90ZToNCnwgICAgICAgIHwgICAgU3VwcG9y dC4NCnwgICAgICAgIHwNCnwgICAgICAgIHwgICAgSSBzZWUsIGhpZXJhcmNoeSBpcyBXRUxMICBk ZWZpbmVkIHdoZW4gbXVsdGlwbGUgaW5zdGFuY2VzIG9mIElHUA0KfCAgICAgICAgd2l0aA0KfCAg ICAgICAgfCAgICBtdWx0aXBsZSBBRnMgYXJlIHJ1bm5pbmcuIEdvb2Qgd29yay4NCnwgICAgICAg IHwNCnwgICAgICAgIHwNCnwgICAgICAgIHwNCnwgICAgICAgIHwgICAgSGF2ZSBmb2xsb3dpbmcg UXM6DQp8ICAgICAgICB8DQp8ICAgICAgICB8ICAgIDEuICAgICAgIEFueSBkaXNjdXNzaW9uIG9m IHRoZSBkZWxheSBpbnRyb2R1Y2VkIGJ5IEJHUCAocGFja2luZywNCnwgICAgICAgIHVwZGF0ZQ0K fCAgICAgICAgfCAgICBnZW5lcmF0aW9uLCBwcm9jZXNzaW5nIGV0Yy4uKSB0byB0cmFuc3BvcnQg dGhlIExTIGluZm9ybWF0aW9uDQp8ICAgICAgICB8DQp8ICAgICAgICB8ICAgIGVzcGVjaWFsbHks IHdoZW4gTFNEQiBpcyBjaGFuZ2luZyBmYXN0ZXIgcGVyaGFwcyB3aXRoIGxhcmdlDQp8ICAgICAg ICBudW1iZXIgb2YNCnwgICAgICAgIHwgICAgbm9kZXMvbGlua3MgaW5zaWRlIGFuIEFTIGFuZCB3 aXRoIG11bHRpcGxlIEFTZXMpIHRvIHRoZQ0KfCAgICAgICAgY29udHJvbGxlciB3aWxsIGJlDQp8 ICAgICAgICB8ICAgIHVzZWZ1bC4NCnwgDQp8ICAgICAgICB0aGlzIGlzIGhpZ2hseSBpbXBsZW1l bnRhdGlvbiBkZXBlbmRlbnQ7IC0NCnwgICAgICAgIHNvbWUgdmVuZG9ycyBkbyB0aGUgcGFja2Fn aW5nIG9mIEJHUCB1cGRhdGVzIGVudGlyZWx5IGV2ZW50LWRyaXZlbg0KfCAgICAgICAgYW5kIG90 aGVycyBwYWNrIHRoaW5ncyB1cCBhbmQgaGF2ZSBhIHdvcnN0IGNhc2UgZGVsYXkgYmV0d2Vlbg0K fCAgICAgICAgdGhlIHRyaWdnZXIgZXZlbnQgYW5kIHRoZSBCR1AgdXBkYXRlLiB0aGUgcHJvdG9j b2wNCnwgICAgICAgIGl0c2VsZiBkb2VzIG5vdCBwcm9oaWJpdC9saW1pdCB0aGUgcHJvcGFnYXRp b24gc3BlZWQuDQp8ICAgICAgICAoaW4gZmFjdCBpdCBjYW4gYmUgc2hvd24gdGhhdCBzb21ldGlt ZXMgdXBkYXRlcw0KfCAgICAgICAgdHJhdmVsIGZhc3RlciBvbiB0aGUgKGRhdGFwbGFuZSBmb3J3 YXJkZWQpIGlCR1AgbWVzaCwNCnwgICAgICAgIHJhdGhlciB0aGFuIHByb3BnYXRlIHVzaW5nIHRo ZSBob3AtYnktaG9wIGNvbnRyb2wtcGxhbmUgZmxvb2RpbmcNCnwgICAgICAgIHByb3RvY29sKQ0K fCANCnwgICAgICAgIHwgICAgICAgICAgICAgICAgIEEgbm90ZSBvbiB0aGUgc2Vuc2l0aXZpdHkg b2YgdGhpcyBkZWxheSB0byB0aGUNCnwgICAgICAgIGNvbnN1bWVyDQp8ICAgICAgICB8ICAgIChh cHBsaWNhdGlvbnMpIGF0IHRoZSBjb250cm9sbGVyICBjYW4gYmUgaGVscGZ1bC4gSSBzYXcgdmVy eQ0KfCAgICAgICAgbGl0dGxlDQp8ICAgICAgICB8ICAgIGRpc2N1c3Npb24gaW4gU2VjdGlvbiA2 ICg2LjEuNSkNCnwgDQp8ICAgICAgICBkaWZmaWNpdWx0IC0gaXRzIGhhcmQgdG8gaGF2ZSBzb21l IHNvcnQgb2YgZ2VuZXJhbCBjb21tZW50IGFzIHRoaW5ncw0KfCAgICAgICAgYXJlDQp8ICAgICAg ICBoaWdobHkgaW1wbGVtZW50YXRpb24gZGVwZW5kZW50Lg0KfCANCnwgDQp8ICAgICAgICB8ICAg IDIuICAgICAgIFRoaXMgZG9jdW1lbnQgZW5jb21wYXNzZXMgcHJldHR5IG11Y2ggYm90aCBPU1BG IGFuZCBJU0lTDQp8ICAgICAgICB8ICAgIGV4dGVuc2lvbnMgZG9uZSB0aWxsIGRhdGUuIEhvdyBp dCB3aWxsIGtlZXAgdXAgd2l0aCBmdXR1cmUNCnwgICAgICAgIGV4dGVuc2lvbnMgaW4NCnwgICAg ICAgIHwgICAgT1NQRi9JU0lTLg0KfCANCnwgICAgICAgIHdlIGhhdmUgc2V0IHVwIGFuIElBTkEg cmVnaXN0cmllcyBmb3IgdGhlIGNhcnJpZXJzIG9mIGluZm9ybWF0aW9uLg0KfCAgICAgICAgaXQg aXMgZXhwZWN0ZWQgYnkgYXV0aG9ycyBvZiAidG9wb2xvZ2ljYWwgcmVsZXZhbnQiIElHUCBleHRl bnNpb25zDQp8ICAgICAgICB0byBzdXBwbHkgYWxzbyBCR1AtTFMgZXh0ZW5zaW9ucy4NCnwgDQp8 ICAgICAgICB8ICAgIEEgbWVjaGFuaXNtIGluIHBsYWNlIHdvdWxkIGJlIGhlbHBmdWwuIE15IHN1 Z2dlc3Rpb24gd291bGQgYmUtDQp8ICAgICAgICB0aGUNCnwgICAgICAgIHwgICAgcmVzcGVjdGl2 ZSBJR1AgZG9jdW1lbnRzIHNob3VsZCBhc3Nlc3MgdGhlIGltcGFjdCBhbmQgZGVmaW5lDQp8ICAg ICAgICB8DQp8ICAgICAgICB8ICAgIGNvcnJlc3BvbmRpbmcgbmV3IFRMVnMgZm9yIEJHUCBMUz8g QnV0IGhvdyB0aGlzIGNhbiBiZSBlbmZvcmNlZD8NCnwgDQp8ICAgICAgICBpIGhhdmUgbm8gaWRl YSAtIHRvZGF5IGl0cyBlbnRpcmVseSB2b2x1bnRhcnkuDQp8IA0KfCAgICAgICAgfCAgICAzLiAg ICAgICBTZWN0aW9uIDQsIGdpdmVzIGdsaW1wc2Ugd2hhdCdzIHBvc3NpYmxlIGFuZCB0aGUgbm9k ZQ0KfCAgICAgICAgYWdncmVnYXRpbmcNCnwgICAgICAgIHwgICAgdGhlIGxpbmtzIG9idmlvdXNs eSBuZWVkIHRvIHRpbmtlciB0aGUgTFNEQiB0byByZXByZXNlbnQgdGhlIHNhbWUNCnwgICAgICAg IHwgICAgY29ycmVjdGx5Lg0KfCAgICAgICAgfA0KfCAgICAgICAgfCAgICBTb21lIG1vcmUgZGV0 YWlscyB3b3VsZCBiZSBoZWxwZnVsIHRvIHJlcHJlc2VudCB0aGUgY2hhbmdlcyBvbg0KfCAgICAg ICAgfCAgICBhZ2dyZWdhdGlvbi9kZS1hZ2dyZWdhdGlvbiBzdWJzZXF1ZW50bHkuDQp8IA0KfCAg ICAgICAgdGhpcyBtYXkgcXVpY2tseSBnZXQgeW91IGludG8gdGhlICJhYnN0cmFjdGVkIHRvcG9s b2d5IG1vZGVscyINCnwgICAgICAgIGRpc2N1c3Npb24gdGhhdCBrZWVwcyBlbWVyZ2luZyAgcGVy aW9kaWNhbGx5LiAtDQp8ICAgICAgICB3ZSBkaWQgbm90IHdhbnQgdG8gc3RvcCBwcm9ncmVzcyBv biB0aGUgcHJvdG9jb2wgYnkgYXJndWluZw0KfCAgICAgICAgIndoYXRzIHRoZSByaWdodCBhYnN0 cmFjdGlvbiBtb2RlbCIgYW5kIGhhdmUgYWdyZWVkDQp8ICAgICAgICBvbiB0aGUgbWluaW1hbGlz dGljIG5hdHVyZSBvZiB0aGUgc2VjdGlvbiBhcy1pcy4NCnwgDQp8IA0KfCAgICAgICAgfCAgICA0 LiAgICAgICBTZWN0aW9uIDYuMiBoYXMgZW1wdHkgc3ViLXNlY3Rpb25zIGFuZCBUQkRzLg0KfCAN CnwgICAgICAgIHJpZ2h0IC4uLiBzbyBzdWdnZXN0IHRvIHJlbW92ZSBzZWN0aW9uIDYuMiBhbHRv Z2V0aGVyLg0KfCANCnwgICAgICAgIHwgICAgNS4gICAgICAgSXQncyBnb29kIHRvIHNlZSBJbXBs ZW1lbnRhdGlvbiByZXBvcnQgc2hlZCBsaWdodCBvbg0KfCAgICAgICAgcGVyZm9ybWFuY2UNCnwg ICAgICAgIHwgICAgc2VlbiB3aXRoIG11bHRpcGxlIEFTZXMuDQp8ICAgICAgICB8DQp8ICAgICAg ICB8ICAgIDYuICAgICAgIEl0J3MgZ29vZCB0byBzZWUgaWYgYW55IGFwcGxpY2F0aW9uIG9mIHBv bGljeSBvbiBMU0RCIGlzDQp8ICAgICAgICBkb25lDQp8ICAgICAgICB8ICAgIChvbmUgb2YgdGhl IHByaW1hcnkgZHJpdmVycyBvZiB0aGUgc3BlY2lmaWNhdGlvbikuDQp8IA0KfCANCnwgICAgICAg IHRoYW5rcywNCnwgDQp8IA0KfCAgICAgICAgL2hhbm5lcw0KfCANCnwgICAgICAgIHwNCnwgICAg ICAgIHwgICAgRnJvbTogSWRyIFttYWlsdG86aWRyLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBTdXNhbiBIYXJlcw0KfCAgICAgICAgfCAgICBTZW50OiBUdWVzZGF5LCBBdWd1c3QgMjYs IDIwMTQgMTE6MzcgQU0NCnwgICAgICAgIHwgICAgVG86IGlkckBpZXRmLm9yZw0KfCAgICAgICAg fCAgICBDYzogJ0pvaG4gRy4gU2N1ZGRlcic7IHNoYXJlc0BuZHpoLmNvbQ0KfCAgICAgICAgfCAg ICBTdWJqZWN0OiBbSWRyXSBXRyBMQyBmb3IgZHJhZnQtaWV0Zi1pZHItbHMtZGlzdHJpYnV0aW9u IGFuZA0KfCAgICAgICAgfCAgICBkcmFmdC1pZXRmLWlkci1scy1kaXN0cmlidXQtaW1wbA0KfCAg ICAgICAgfA0KfCAgICAgICAgfA0KfCAgICAgICAgfA0KfCAgICAgICAgfCAgICBUaGlzIGlzIGEg V0cgTEMgZm9yDQp8ICAgICAgICB8DQp8ICAgICAgICB8DQp8ICAgICAgICB8DQp8ICAgICAgICB8 DQp8ICAgICAgICBbMV1odHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYt aWRyLWxzLWRpc3RyaWJ1dGlvbi8NCnwgICAgICAgIHwNCnwgICAgICAgIHwNCnwgICAgICAgIFsy XWh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pZHItbHMtZGlzdHJp YnV0aW9uLWltcGwvDQp8ICAgICAgICB8DQp8ICAgICAgICB8DQp8ICAgICAgICB8DQp8ICAgICAg ICB8ICAgIFBsZWFzZSByZXNwb25kIHdpdGggY29tbWVudHMgYW5kICJzdXBwb3J0IG9yIG5vIHN1 cHBvcnQuIiAgVGhpcw0KfCAgICAgICAgV0cgTEMgYWxzbw0KfCAgICAgICAgfCAgICBpbmNsdWRl cyBhIHJlcXVlc3QgZm9yIHRoZSBhdXRob3JzIHRvIHByb3ZpZGUgSVBSIG9uIHRoZSBzdWJqZWN0 Lg0KfCAgICAgICAgfA0KfCAgICAgICAgfA0KfCAgICAgICAgfA0KfCAgICAgICAgfCAgICBQbGVh c2Ugbm90ZTogZHVlIHRvIHRoZSBFdXJvcGVhbiB2YWNhdGlvbnMgaW4gQXVndXN0LCB3ZSBhcmUN CnwgICAgICAgIGJ1bmRsaW5nDQp8ICAgICAgICB8ICAgIHRoZXNlIHRocmVlIHJldmlld3MgaW50 byB0aGUgbmV4dCB0d28gd2Vla3MgKHRoZXNlIHR3byBkcmFmdHMgYW5kDQp8ICAgICAgICB8ICAg IGRyYWZ0LWlldGYtYXMtbWlncmF0aW9uKS4gICBUaGUgY2hhaXJzIHdvdWxkIGxpa2UgZmVlZGJh Y2sgKGxpc3QNCnwgICAgICAgIG9yDQp8ICAgICAgICB8ICAgIHByaXZhdGUgZW1haWwpIHdoZXRo ZXIgdGhlIHRocmVlIFdHIExDIHMgaW1wYWN0IGFueW9uZSdzIGFiaWxpdHkNCnwgICAgICAgIHRv IHJldmlldw0KfCAgICAgICAgfCAgICB0aGVzZSBkcmFmdHMgY2FyZWZ1bGx5Lg0KfCAgICAgICAg fA0KfCAgICAgICAgfA0KfCAgICAgICAgfA0KfCAgICAgICAgfCAgICBUaGFuayB5b3UsDQp8ICAg ICAgICB8DQp8ICAgICAgICB8DQp8ICAgICAgICB8DQp8ICAgICAgICB8ICAgIFN1ZSBIYXJlcyBh bmQgSm9obiBTY3VkZGVyDQp8ICAgICAgICB8DQp8ICAgICAgICB8IFJlZmVyZW5jZXMNCnwgICAg ICAgIHwNCnwgICAgICAgIHwgICAgVmlzaWJsZSBsaW5rcw0KfCAgICAgICAgfCAgICAxLg0KfCAg ICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWlkci1scy1k aXN0cmlidXRpb24vDQp8ICAgICAgICB8ICAgIDIuDQp8ICAgICAgICBodHRwOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaWRyLWxzLWRpc3RyaWJ1dGlvbi1pbXBsLw0KfCAN CnwgICAgICAgIHwgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCnwgICAgICAgIHwgSWRyIG1haWxpbmcgbGlzdA0KfCAgICAgICAgfCBJZHJAaWV0Zi5vcmcN CnwgICAgICAgIHwgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZHINCnwg DQp8ICAgICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KfCAgICAgICAgSWRyIG1haWxpbmcgbGlzdA0KfCAgICAgICAgSWRyQGlldGYub3JnDQp8ICAg ICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkcg0KfCANCnwgDQp8 IFJlZmVyZW5jZXMNCnwgDQp8ICAgIFZpc2libGUgbGlua3MNCnwgICAgMS4gbWFpbHRvOmhhbm5l c0BqdW5pcGVyLm5ldA0KfCAgICAyLiBtYWlsdG86bGl6aGVucWlhbmdAY2hpbmFtb2JpbGUuY29t DQp8ICAgIDMuIG1haWx0bzp1bWEuY2h1bmR1cmlAZXJpY3Nzb24uY29tDQp8ICAgIDQuIG1haWx0 bzppZHJAaWV0Zi5vcmcNCnwgICAgNS4gbWFpbHRvOmpnc0BiZ3AubnUNCnwgICAgNi4gbWFpbHRv OnNoYXJlc0BuZHpoLmNvbQ0KfCAgICA3LiBtYWlsdG86aGFubmVzQGp1bmlwZXIubmV0DQp8ICAg IDguIG1haWx0bzp1bWEuY2h1bmR1cmlAZXJpY3Nzb24uY29tDQp8ICAgIDkuIG1haWx0bzppZHJA aWV0Zi5vcmcNCnwgICAxMC4gbWFpbHRvOmpnc0BiZ3AubnUNCnwgICAxMS4gbWFpbHRvOnNoYXJl c0BuZHpoLmNvbQ0KIA0K ------=_001_NextPart671221528844_=---- Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =0A
Placing the type field befo= re the length field is fine for me.

The encoding = format for RD in this draft is not consistent with RFC4364. This is the qu= estion. RFC6514 says "The Route Distinguisher (RD) is encod= ed as described in [RFC4364]", please see section 4 of RFC6514= .

I agree with you for the advantage to pu= t the RD before other fields. I raise this quesiton just for clarification= .
=0A

=0A
=0A
lizhenqiang@chinamobile.com
=0A
 
Subject: Re: [Idr] WG LC for draf= t-ietf-idr-ls-distribution and draft-ietf-idr-ls-distribut-impl
=0A
Hi Zhenqiang:
= =0A
=0A
=0A
=0A
=0AFor the NLRIs tha= t uses a "type" field, such as MVPN (see RFC6514), the convention is to en= code the type field before the length field. This allows for greatest flex= ibility for future extensions. In BGP-LS, we have used the same convention= .
=0A
=0A
=0A
=0A
=0AOther than= that, the RD is for the entire bgp-ls object (be it a Node, Link or Prefi= x). So placing the RD field before other fields is logically accurate.=0A
=0A
=0A
=0A
=0AThanks.
= =0A
=0A
=0A
=0A=0A
=0AFrom: "lizhenqiang@chinamobile.com" <lizhenqiang@chinamobile.com>
=0ADate: Tuesday, September 2, 2014 at 4:21 AM=0ATo: Hannes Gredler <hannes@juniper.net>
=0ACc: "idr@ie= tf.org" <idr@ietf.org>, "shares@ndzh.com" <shares@ndzh.com>, 'John=0A Scudder' <jgs@bgp.nu>
=0ASubject: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution = and draft-ietf-idr-ls-distribut-impl
=0A
=0A

=0A
=0A<= div>=0A
=0A
Hi Hannes,
=0A

=0A
=0A<= div>One example to explain the differences. One VPN route with prefix leng= th 24 is carried in the NRLI.
=0A

=0A
=0A
The format= this draft specified is as follows.
=0A
=0A
+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=0A
 |&nbs= p;           NLRI Type = =3D 3         |     Total NLRI Len= gth         |
=0A
+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=0A
&n= bsp;|           &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;  |
=0A
+        &n= bsp;           &nbs= p;  Route Distinguisher       &nbs= p;            = +
=0A
 |        &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;     |
=0A
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+
= =0A| Protocol-ID |
=0A+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+
=0A| Identifier |
=0A| (64 bits) |
=0A+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=0A// Loca= l Node Descriptor (variable) //
=0A+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=0A
=0A
=0A
| Type =3D 265    =                     &nb= sp;  | Length |=0A
=0A+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+
=0A| Prefix Length =3D 24 | IP Prefix (variable)= //
=0A+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+
=0A

=0A
=0A

=0A
=0A
The forma= t RFC4363 specified is as follows.
=0A
+-----------------------------------------------= ----------+=0A
=0A| Address Family Identifier (2 octets) |
=0A+----= -----------------------------------------------------+
=0A| Subsequent= Address Family Identifier (1 octet) |
=0A+---------------------------= ------------------------------+
=0A| Length of Next Hop Network Addres= s (1 octet) |
=0A+----------------------------------------------------= -----+
=0A| Network Address of Next Hop (variable) |
=0A+---------= ------------------------------------------------+
=0A| Reserved (1 oct= et) |
=0A+---------------------------------------------------------+ <= br>=0A| Prefix Length =3D 88 |  IP Prefix (variable) =3D RD fo= llowed by IP prefix // 
=0A+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-++
=0A

=0A
=0A
=0A=0A
=0A
 
=0A
=0A
=0A=0A
Date: 2014-09-02 16= :35
=0A=0A=0ASubject: Re: RE: [Idr] WG LC for draft-ietf-idr-ls-distribu= tion and draft-ietf-idr-ls-distribut-impl
=0A
=0A
=0A
= =0A
hi zhenqiang,
=0A
 
=0A
On Tue, Sep 02, 201= 4 at 04:12:58PM +0800, =0Al= izhenqiang@chinamobile.com wrote:
=0A
|    Two= types of link state NLRIs are defined in section 3.2 of this
=0A|    draft, AFI 16388 / SAFI 71 for non-VPN, AFI 16388 / S= AFI 128 for VPN.
=0A
 
=0A
correct;
=0A
&n= bsp;
=0A
|    My question is about AFI 16388 / SAF= I 128 NLRI. From the figure in page 9
=0A
|    of = draft version 5, we can see that RD is put before link state NLRI.
= =0A
 
=0A
 
=0A
from =0Ahttp://= tools.ietf.org/html/draft-ietf-idr-ls-distribution-05#section-3.2=0A
 
=0A
this is the NLRI format for AFI 16388 / SAFI = 71 (unicast)
=0A
 
=0A
    0 &n= bsp;           &nbs= p;     1       &nbs= p;           2 &nbs= p;            =      3
=0A
    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
=0A
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= =0A
   |        &nbs= p;   NLRI Type        &n= bsp; |     Total NLRI Length    &n= bsp;    |
=0A
   +-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=0A
   |&nbs= p;            =             &n= bsp;           &nbs= p;            =              |=
=0A
   //       &nb= sp;          Link-State NLRI = (variable)          &nbs= p;      //
=0A
   |  = ;            &= nbsp;           &nb= sp;            = ;            &= nbsp;           |
= =0A
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+
=0A
 
=0A
and this is the NLRI format = for AFI 16388 / SAFI 128 (VPN-unicast)
=0A
 
=0A
&n= bsp;   0         &n= bsp;         1   &n= bsp;           &nbs= p;   2         &nbs= p;         3
=0A
 &n= bsp;  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=
=0A
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+
=0A
   |    &nbs= p;       NLRI Type    &n= bsp;     |     Total NLRI Length&n= bsp;        |
=0A
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= =0A
   |        &nbs= p;            =             &n= bsp;           &nbs= p;            =      |
=0A
   +   &n= bsp;           &nbs= p;       Route Distinguisher  &nbs= p;            =       +
=0A
   |  &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;           |
=0A<= div>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
=0A
   |      &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;       |
=0A
   // = ;            &= nbsp;    Link-State NLRI (variable)    =              /= /
=0A
   |       &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;      |
=0A
   +-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=0A
 =0A
 
=0A
 
=0A
|    The= link state NLRI field in this figure contains the IP prefix. As RFC4364=0A
|    specifies, the VPN routes should be carrie= d in the NLRI prepending with
=0A
|    RD.
= =0A
 
=0A
that is what we do - i fail to see the offendi= ng part with respect to RFC4364.
=0A
 
=0A
/hannes<= /div>=0A
 
=0A
|
=0A
|    =   From: [1]Hannes Gredler
=0A
|     = ; Date: 2014-09-02 15:29
=0A
|      To: = [2]lizhenqiang@chinamobile.= com; [3]Uma Chunduri
=0A
|      CC: = [4]'idr wg'; [5]'John G. Scudder'; [6]Susan Hares
=0A
| &nbs= p;    Subject: RE: Re: [Idr] WG LC for draft-ietf-idr-ls-di= stribution and
=0A
|      draft-ietf-idr= -ls-distribut-impl
=0A
|
=0A
|    &= nbsp; hi zhenqiang,
=0A
|
=0A
|    =   The Route-distinguisher's purpose is to add 64-bits of  disamb= iguating
=0A
|      entropy to the NLRI,= such
=0A
|
=0A
|      that th= e route-reflectors do not "swallow" that path as part of the
=0A
= |      best-path election
=0A
|
= =0A
|      procedure. The link-state NLRI (en= capsulated in MP_REACH/ MP UNREACH PA)
=0A
|
=0A
| = ;     is a RD-less version of the vpn-link-state NLRI.=
=0A
|
=0A
|      In a certain= way these correspond to RFC3107 / RFC4364 NLRI formats.
=0A
| =0A
|      The former is a RD-less versio= n of the latter.
=0A
|
=0A
|    &nb= sp; On your question "Why do't you put RD in IP Reachability Information,<= /div>=0A
|      just prepending RD with IP pr= efix as RFC4364 specifies." - This is
=0A
|   &nbs= p;  actually what we *are* doing - we put the RD before the link-stat= e NLRI
=0A
|      inside the MP_REACH/MP= _UNREACH Attribute.
=0A
|
=0A
|    =   HTH,
=0A
|
=0A
|      /= hannes
=0A
|
=0A
|    ------------------= --------------------------------------------------------
=0A
| =0A= =0A
|      Sent: Tuesday, September 02, 2014 = 8:44
=0A
|      To: Hannes Gredler; Uma = Chunduri
=0A
|      Cc: 'idr wg'; 'John = G. Scudder'; Susan Hares
=0A
|      Subj= ect: Re: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and
=0A|      draft-ietf-idr-ls-distribut-impl
= =0A
|
=0A
|      One question about= the VPN Link-State NLRI in section 3.2. Why do you
=0A
| &n= bsp;    put the RD before link state NRLI? Why do't you put= RD in IP
=0A
|      Reachability Inform= ation, just preprending RD with IP prefix as RFC4364
=0A
| &= nbsp;    specifies.
=0A
|
=0A
| &nb= sp;  ----------------------------------------------------------------= ----------
=0A
|
=0A
|      lizhenqiang@chinamobile.com
=0A
|
=0A
|
=0A
|    &= nbsp;   From: [7]Hannes Gredler
=0A
|   =      Date: 2014-09-02 02:05
=0A
|  =       To: [8]Uma Chunduri
=0A
| &nb= sp;      CC: [9]i= dr@ietf.org; [10]'John G. Scudder'; [11]Susan Hares
=0A
|&nbs= p;       Subject: Re: [Idr] WG LC for draft-= ietf-idr-ls-distribution and
=0A
|     &= nbsp;  draft-ietf-idr-ls-distribut-impl
=0A
|  &nb= sp;     hi uma,
=0A
|
=0A
| &n= bsp;      see comments/responses inline:
=0A=
|
=0A
|        On Wed, A= ug 27, 2014 at 11:07:01AM +0000, Uma Chunduri wrote:
=0A
| &= nbsp;      |    Support.
=0A<= div>|        |
=0A
| &nbs= p;      |    I see, hierarchy is W= ELL  defined when multiple instances of IGP
=0A
|  = ;      with
=0A
|    = ;    |    multiple AFs are running. Good wor= k.
=0A
|        |
=0A|        |
=0A
|  &= nbsp;     |
=0A
|    &nbs= p;   |    Have following Qs:
=0A
| =        |
=0A
|   &nb= sp;    |    1.     =   Any discussion of the delay introduced by BGP (packing,
=0A|        update
=0A
| &= nbsp;      |    generation, proces= sing etc..) to transport the LS information
=0A
|  &nbs= p;     |
=0A
|     &= nbsp;  |    especially, when LSDB is changing faster p= erhaps with large
=0A
|       = number of
=0A
|        | = ;   nodes/links inside an AS and with multiple ASes) to the=0A
|        controller will be=0A
|        |   = useful.
=0A
|
=0A
|      = ;  this is highly implementation dependent; -
=0A
| &nb= sp;      some vendors do the packaging of BGP upd= ates entirely event-driven
=0A
|     &nb= sp;  and others pack things up and have a worst case delay between=0A
|        the trigger event a= nd the BGP update. the protocol
=0A
|    &nbs= p;   itself does not prohibit/limit the propagation speed.
= =0A
|        (in fact it can be sho= wn that sometimes updates
=0A
|     &nbs= p;  travel faster on the (dataplane forwarded) iBGP mesh,
=0A|        rather than propgate using t= he hop-by-hop control-plane flooding
=0A
|    = ;    protocol)
=0A
|
=0A
|  &n= bsp;     |       &n= bsp;         A note on the sensiti= vity of this delay to the
=0A
|     &nbs= p;  consumer
=0A
|       = |    (applications) at the controller  can be helpful= . I saw very
=0A
|        litt= le
=0A
|        |  &= nbsp; discussion in Section 6 (6.1.5)
=0A
|
=0A
| =        difficiult - its hard to have some so= rt of general comment as things
=0A
|    &nbs= p;   are
=0A
|       = ; highly implementation dependent.
=0A
|
=0A
|
= =0A
|        |    2.=        This document encompasses pretty much= both OSPF and ISIS
=0A
|      &nbs= p; |    extensions done till date. How it will keep up with= future
=0A
|        extension= s in
=0A
|        |  = ;  OSPF/ISIS.
=0A
|
=0A
|    &= nbsp;   we have set up an IANA registries for the carriers of in= formation.
=0A
|        it is = expected by authors of "topological relevant" IGP extensions
=0A
= |        to supply also BGP-LS extensio= ns.
=0A
|
=0A
|      &nbs= p; |    A mechanism in place would be helpful. My suggestio= n would be-
=0A
|        the=0A
|        |   = ; respective IGP documents should assess the impact and define
=0A|        |
=0A
|  =       |    corresponding new TLVs = for BGP LS? But how this can be enforced?
=0A
|
=0A
|&n= bsp;       i have no idea - today its entire= ly voluntary.
=0A
|
=0A
|     =    |    3.       Se= ction 4, gives glimpse what's possible and the node
=0A
| &n= bsp;      aggregating
=0A
|  &= nbsp;     |    the links obviously need= to tinker the LSDB to represent the same
=0A
|   =      |    correctly.
=0A
|&nbs= p;       |
=0A
|   &= nbsp;    |    Some more details would be hel= pful to represent the changes on
=0A
|    &nb= sp;   |    aggregation/de-aggregation subsequentl= y.
=0A
|
=0A
|       = ; this may quickly get you into the "abstracted topology models"
=0A<= div>|        discussion that keeps emer= ging  periodically. -
=0A
|     &nb= sp;  we did not want to stop progress on the protocol by arguing=0A
|        "whats the right abst= raction model" and have agreed
=0A
|     = ;   on the minimalistic nature of the section as-is.
=0A|
=0A
|
=0A
|      &nb= sp; |    4.       Section 6.2= has empty sub-sections and TBDs.
=0A
|
=0A
| &nbs= p;      right ... so suggest to remove section 6.= 2 altogether.
=0A
|
=0A
|     =    |    5.       It= 's good to see Implementation report shed light on
=0A
| &nb= sp;      performance
=0A
|  &n= bsp;     |    seen with multiple ASes.<= /div>=0A
|        |
=0A
|&= nbsp;       |    6. &nbs= p;     It's good to see if any application of policy o= n LSDB is
=0A
|        done=0A
|        |   = (one of the primary drivers of the specification).
=0A
|
= =0A
|
=0A
|        thanks= ,
=0A
|
=0A
|
=0A
|    &n= bsp;   /hannes
=0A
|
=0A
|   &= nbsp;    |
=0A
|     &nbs= p;  |    From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
=0A|        |    Sent: T= uesday, August 26, 2014 11:37 AM
=0A
|    &nb= sp;   |    To: id= r@ietf.org
=0A
|        |&= nbsp;   Cc: 'John G. Scudder'; shares@ndzh.com
=0A
|      &n= bsp; |    Subject: [Idr] WG LC for draft-ietf-idr-ls-distri= bution and
=0A
|        | = ;   draft-ietf-idr-ls-distribut-impl
=0A
|  &= nbsp;     |
=0A
|    &nbs= p;   |
=0A
|        = |
=0A
|        |  &n= bsp; This is a WG LC for
=0A
|      = ;  |
=0A
|        |
= =0A
|        |
=0A
| =        |
=0A=0A
|      &nb= sp; |
=0A
|        |
=0A<= div>|        [2]http://datatrack= er.ietf.org/doc/draft-ietf-idr-ls-distribution-impl/
=0A
|&nb= sp;       |
=0A
|   =      |
=0A
|     &nb= sp;  |
=0A
|        |&nbs= p;   Please respond with comments and "support or no support."&n= bsp; This
=0A
|        WG LC a= lso
=0A
|        |  =   includes a request for the authors to provide IPR on the subject.=0A
|        |
=0A
|&n= bsp;       |
=0A
|   = ;     |
=0A
|     &n= bsp;  |    Please note: due to the European vacations = in August, we are
=0A
|       = bundling
=0A
|        | =    these three reviews into the next two weeks (these two drafts= and
=0A
|        |  = ;  draft-ietf-as-migration).   The chairs would like feedba= ck (list
=0A
|        or
= =0A
|        |    pr= ivate email) whether the three WG LC s impact anyone's ability
=0A|        to review
=0A
|&nbs= p;       |    these drafts ca= refully.
=0A
|        |
= =0A
|        |
=0A
| =        |
=0A
|   &nb= sp;    |    Thank you,
=0A
| &= nbsp;      |
=0A
|   &nbs= p;    |
=0A
|      &= nbsp; |
=0A
|        | &n= bsp;  Sue Hares and John Scudder
=0A
|   &nbs= p;    |
=0A
|      &= nbsp; | References
=0A
|       = ; |
=0A
|        |  =   Visible links
=0A
|      &nb= sp; |    1.
=0A=0A
|        | &= nbsp;  2.
=0A
|        =0Ahttp://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution-imp= l/
=0A
|
=0A
|      &= nbsp; | _______________________________________________
=0A
|&nbs= p;       | Idr mailing list
=0A
|&n= bsp;       | Idr@ietf.org
=0A=0A
|
=0A
|  &nb= sp;     ______________________________________________= _
=0A
|        Idr mailing lis= t
=0A
|        Idr@ietf.org
=0A=0A
|
=0A
| =
=0A
| References
=0A
|
=0A
|   = ; Visible links
=0A=0A=0A=0A|    4. mailto:idr@ietf.= org
=0A=0A=0A
|  &n= bsp; 7. mailto:hannes@juniper.net
=0A=0A
|  &n= bsp; 9. mailto:idr@ietf.org
=0A|   10. mailto:jgs@bgp.nu=0A=0A
 
=0A
=0A
=0A=0A
=0A=0A
=0A ------=_001_NextPart671221528844_=------ From nobody Tue Sep 2 19:24:36 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B0F51A896F for ; Tue, 2 Sep 2014 19:24:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.567 X-Spam-Level: X-Spam-Status: No, score=-14.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vdbqZZ1XteIo for ; Tue, 2 Sep 2014 19:24:29 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45FAB1A897D for ; Tue, 2 Sep 2014 19:24:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=58029; q=dns/txt; s=iport; t=1409711069; x=1410920669; h=from:to:cc:subject:date:message-id:mime-version; bh=5RADy1FAplsjaaS5wsRHlWgCk/aSbL4kG/guFoHaNSA=; b=PQo4HFlbP66s+O5mQ90tzfXB0ASwEs9eDSbIZlX3cDlc4yaFgEvuI2qT E8tu+ySHw05rEGpQYfPEtq5rqYGsHDbTR8Kj/SoAc5uHgO47DMnrLVMNQ j/tVrqHjHr3n8HU7QrTgFFBwz+BxeCUWbLkazdQTf0ufer3vQ7ShaCnfC w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQGACd7BlStJA2G/2dsb2JhbABagkdGU1cEhBSud5NcgV8BC4dKAYESFneEAwEBAQQBAQEXTQcLEgEIEQMBAQEhAQYuCxQJCgQBDQWIQg29HgEXjmsLBgE+AQcGBAaETQWBWIQ8iQmCFIQuhn2BW4pwiFOBZwgWFoFGbAGBBggXIoEHAQEB X-IronPort-AV: E=Sophos; i="5.04,453,1406592000"; d="scan'208,217"; a="74427672" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-4.cisco.com with ESMTP; 03 Sep 2014 02:24:28 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s832ORba028669 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 3 Sep 2014 02:24:27 GMT Received: from xmb-rcd-x13.cisco.com ([169.254.3.228]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Tue, 2 Sep 2014 21:24:27 -0500 From: "Saikat Ray (sairay)" To: "lizhenqiang@chinamobile.com" , "Hannes Gredler" Thread-Topic: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-ietf-idr-ls-distribut-impl Thread-Index: AQHPxx4uKyLgv7j6UUmOKYCHg5K+6g== Date: Wed, 3 Sep 2014 02:24:27 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [128.107.165.83] Content-Type: multipart/alternative; boundary="_000_D02BC9221FD45sairayciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/ysEWX9nqafzF0zKn0KGaxHFa9O0 Cc: 'idr wg' , "'John G. Scudder'" , Susan Hares Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-ietf-idr-ls-distribut-impl X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 02:24:33 -0000 --_000_D02BC9221FD45sairayciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: "lizhenqiang@chinamobile.com" > Date: Tuesday, September 2, 2014 at 7:18 PM To: sairay >, Hannes Gredler > Cc: "idr@ietf.org" >= , "shares@ndzh.com" >, 'John Scudder' > Subject: Re: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-i= etf-idr-ls-distribut-impl Placing the type field before the length field is fine for me. The encoding format for RD in this draft is not consistent with RFC4364. Th= is is the question. RFC6514 says "The Route Distinguisher (RD) is encoded a= s described in [RFC4364]", please see section 4 of RFC6514. [SR] That statement in RFC6514 refers to how the 8 bytes of the route-disti= nguisher field are encoded (different RD types, values, etc.), not to the p= osition of RD field in the NLRI. I agree with you for the advantage to put the RD before other fields. I rai= se this quesiton just for clarification. ________________________________ lizhenqiang@chinamobile.com From: Saikat Ray (sairay) Date: 2014-09-03 05:03 To: lizhenqiang@chinamobile.com; Hannes= Gredler CC: 'idr wg'; Susan Hares; 'Jo= hn G. Scudder' Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-ietf-= idr-ls-distribut-impl Hi Zhenqiang: For the NLRIs that uses a "type" field, such as MVPN (see RFC6514), the con= vention is to encode the type field before the length field. This allows fo= r greatest flexibility for future extensions. In BGP-LS, we have used the s= ame convention. Other than that, the RD is for the entire bgp-ls object (be it a Node, Link= or Prefix). So placing the RD field before other fields is logically accur= ate. Thanks. From: "lizhenqiang@chinamobile.com" > Date: Tuesday, September 2, 2014 at 4:21 AM To: Hannes Gredler > Cc: "idr@ietf.org" >= , "shares@ndzh.com" >, 'John Scudder' > Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-ietf-= idr-ls-distribut-impl Hi Hannes, One example to explain the differences. One VPN route with prefix length 24= is carried in the NRLI. The format this draft specified is as follows. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NLRI Type =3D 3 | Total NLRI Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Route Distinguisher + | | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | | (64 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Local Node Descriptor (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 265 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length =3D 24 | IP Prefix (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The format RFC4363 specified is as follows. +---------------------------------------------------------+ | Address Family Identifier (2 octets) | +---------------------------------------------------------+ | Subsequent Address Family Identifier (1 octet) | +---------------------------------------------------------+ | Length of Next Hop Network Address (1 octet) | +---------------------------------------------------------+ | Network Address of Next Hop (variable) | +---------------------------------------------------------+ | Reserved (1 octet) | +---------------------------------------------------------+ | Prefix Length =3D 88 | IP Prefix (variable) =3D RD followed by IP prefix= // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ ________________________________ lizhenqiang@chinamobile.com From: Hannes Gredler Date: 2014-09-02 16:35 To: lizhenqiang@chinamobile.com CC: Uma Chunduri; 'idr wg'; 'John G. Scudder'; Susan Hares Subject: Re: RE: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-i= etf-idr-ls-distribut-impl hi zhenqiang, On Tue, Sep 02, 2014 at 04:12:58PM +0800, lizhenqiang@chinamobile.com wrote: | Two types of link state NLRIs are defined in section 3.2 of this | draft, AFI 16388 / SAFI 71 for non-VPN, AFI 16388 / SAFI 128 for VPN. correct; | My question is about AFI 16388 / SAFI 128 NLRI. From the figure in pag= e 9 | of draft version 5, we can see that RD is put before link state NLRI. from http://tools.ietf.org/html/draft-ietf-idr-ls-distribution-05#section-3= .2 this is the NLRI format for AFI 16388 / SAFI 71 (unicast) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NLRI Type | Total NLRI Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Link-State NLRI (variable) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ and this is the NLRI format for AFI 16388 / SAFI 128 (VPN-unicast) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NLRI Type | Total NLRI Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Route Distinguisher + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Link-State NLRI (variable) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | The link state NLRI field in this figure contains the IP prefix. As RF= C4364 | specifies, the VPN routes should be carried in the NLRI prepending wit= h | RD. that is what we do - i fail to see the offending part with respect to RFC43= 64. /hannes | | From: [1]Hannes Gredler | Date: 2014-09-02 15:29 | To: [2]lizhenqiang@chinamobile.com; [3]Uma Chunduri | CC: [4]'idr wg'; [5]'John G. Scudder'; [6]Susan Hares | Subject: RE: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and | draft-ietf-idr-ls-distribut-impl | | hi zhenqiang, | | The Route-distinguisher's purpose is to add 64-bits of disambiguati= ng | entropy to the NLRI, such | | that the route-reflectors do not "swallow" that path as part of the | best-path election | | procedure. The link-state NLRI (encapsulated in MP_REACH/ MP UNREACH= PA) | | is a RD-less version of the vpn-link-state NLRI. | | In a certain way these correspond to RFC3107 / RFC4364 NLRI formats. | | The former is a RD-less version of the latter. | | On your question "Why do't you put RD in IP Reachability Information= , | just prepending RD with IP prefix as RFC4364 specifies." - This is | actually what we *are* doing - we put the RD before the link-state N= LRI | inside the MP_REACH/MP_UNREACH Attribute. | | HTH, | | /hannes | | ----------------------------------------------------------------------= ---- | | From: lizhenqiang@chinamobile.com > | Sent: Tuesday, September 02, 2014 8:44 | To: Hannes Gredler; Uma Chunduri | Cc: 'idr wg'; 'John G. Scudder'; Susan Hares | Subject: Re: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and | draft-ietf-idr-ls-distribut-impl | | One question about the VPN Link-State NLRI in section 3.2. Why do yo= u | put the RD before link state NRLI? Why do't you put RD in IP | Reachability Information, just preprending RD with IP prefix as RFC4= 364 | specifies. | | ----------------------------------------------------------------------= ---- | | lizhenqiang@chinamobile.com | | | From: [7]Hannes Gredler | Date: 2014-09-02 02:05 | To: [8]Uma Chunduri | CC: [9]idr@ietf.org; [10]'John G. Scudder'; [= 11]Susan Hares | Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and | draft-ietf-idr-ls-distribut-impl | hi uma, | | see comments/responses inline: | | On Wed, Aug 27, 2014 at 11:07:01AM +0000, Uma Chunduri wrote: | | Support. | | | | I see, hierarchy is WELL defined when multiple instances of = IGP | with | | multiple AFs are running. Good work. | | | | | | | | Have following Qs: | | | | 1. Any discussion of the delay introduced by BGP (packi= ng, | update | | generation, processing etc..) to transport the LS information | | | | especially, when LSDB is changing faster perhaps with large | number of | | nodes/links inside an AS and with multiple ASes) to the | controller will be | | useful. | | this is highly implementation dependent; - | some vendors do the packaging of BGP updates entirely event-driven | and others pack things up and have a worst case delay between | the trigger event and the BGP update. the protocol | itself does not prohibit/limit the propagation speed. | (in fact it can be shown that sometimes updates | travel faster on the (dataplane forwarded) iBGP mesh, | rather than propgate using the hop-by-hop control-plane flooding | protocol) | | | A note on the sensitivity of this delay to the | consumer | | (applications) at the controller can be helpful. I saw very | little | | discussion in Section 6 (6.1.5) | | difficiult - its hard to have some sort of general comment as thin= gs | are | highly implementation dependent. | | | | 2. This document encompasses pretty much both OSPF and = ISIS | | extensions done till date. How it will keep up with future | extensions in | | OSPF/ISIS. | | we have set up an IANA registries for the carriers of information. | it is expected by authors of "topological relevant" IGP extensions | to supply also BGP-LS extensions. | | | A mechanism in place would be helpful. My suggestion would be= - | the | | respective IGP documents should assess the impact and define | | | | corresponding new TLVs for BGP LS? But how this can be enforc= ed? | | i have no idea - today its entirely voluntary. | | | 3. Section 4, gives glimpse what's possible and the nod= e | aggregating | | the links obviously need to tinker the LSDB to represent the = same | | correctly. | | | | Some more details would be helpful to represent the changes o= n | | aggregation/de-aggregation subsequently. | | this may quickly get you into the "abstracted topology models" | discussion that keeps emerging periodically. - | we did not want to stop progress on the protocol by arguing | "whats the right abstraction model" and have agreed | on the minimalistic nature of the section as-is. | | | | 4. Section 6.2 has empty sub-sections and TBDs. | | right ... so suggest to remove section 6.2 altogether. | | | 5. It's good to see Implementation report shed light on | performance | | seen with multiple ASes. | | | | 6. It's good to see if any application of policy on LSD= B is | done | | (one of the primary drivers of the specification). | | | thanks, | | | /hannes | | | | | From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Ha= res | | Sent: Tuesday, August 26, 2014 11:37 AM | | To: idr@ietf.org | | Cc: 'John G. Scudder'; shares@ndzh.com | | Subject: [Idr] WG LC for draft-ietf-idr-ls-distribution and | | draft-ietf-idr-ls-distribut-impl | | | | | | | | This is a WG LC for | | | | | | | | | [1]http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/ | | | | | [2]http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution-= impl/ | | | | | | | | Please respond with comments and "support or no support." Th= is | WG LC also | | includes a request for the authors to provide IPR on the subj= ect. | | | | | | | | Please note: due to the European vacations in August, we are | bundling | | these three reviews into the next two weeks (these two drafts= and | | draft-ietf-as-migration). The chairs would like feedback (l= ist | or | | private email) whether the three WG LC s impact anyone's abil= ity | to review | | these drafts carefully. | | | | | | | | Thank you, | | | | | | | | Sue Hares and John Scudder | | | | References | | | | Visible links | | 1. | http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/ | | 2. | http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution-imp= l/ | | | _______________________________________________ | | Idr mailing list | | Idr@ietf.org | | https://www.ietf.org/mailman/listinfo/idr | | _______________________________________________ | Idr mailing list | Idr@ietf.org | https://www.ietf.org/mailman/listinfo/idr | | | References | | Visible links | 1. mailto:hannes@juniper.net | 2. mailto:lizhenqiang@chinamobile.com | 3. mailto:uma.chunduri@ericsson.com | 4. mailto:idr@ietf.org | 5. mailto:jgs@bgp.nu | 6. mailto:shares@ndzh.com | 7. mailto:hannes@juniper.net | 8. mailto:uma.chunduri@ericsson.com | 9. mailto:idr@ietf.org | 10. mailto:jgs@bgp.nu | 11. mailto:shares@ndzh.com --_000_D02BC9221FD45sairayciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <422FE22DBA7E204BA1DD9D3A79556DBF@emea.cisco.com> Content-Transfer-Encoding: quoted-printable

From: "lizhenqiang@chinamobile.com" <lizhenqiang@chinamobile.com>=
Date: Tuesday, September 2, 2014 at= 7:18 PM
To: sairay <sairay@cisco.com>, Hannes Gredler <hannes@juniper.net>
Cc: "idr@ietf.org" <idr@ietf.= org>, "shares@ndzh.com&q= uot; <shares@ndzh.com>, 'John Scudder' <jgs@bgp.nu>
Subject: Re: Re: [Idr] WG LC for dr= aft-ietf-idr-ls-distribution and draft-ietf-idr-ls-distribut-impl

Placing the type field before the length field is fine fo= r me.

The encoding format for RD in this draft is not consistent with RFC436= 4. This is the question. RFC6514 says "The Route Disting= uisher (RD) is encoded as described in [RFC4364]", please see section 4 of RFC6514.

[SR] That statement in RFC6514 refers to how the 8 bytes of the route-= distinguisher field are encoded (different RD types, values, etc.), not to = the position of RD field in the NLRI.

I agree with you for the advantage to put the RD before other fields. = I raise this quesiton just for clarification.

 
Date: 2014-09-03 05:03
Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-distributio= n and draft-ietf-idr-ls-distribut-impl
Hi Zhenqiang:=

For the NLRIs that uses a "type" field, such as MVPN (see RFC6514= ), the convention is to encode the type field before the length field. This= allows for greatest flexibility for future extensions. In BGP-LS, we have = used the same convention.

Other than that, the RD is for the entire bgp-ls object (be it a Node, Link= or Prefix). So placing the RD field before other fields is logically accur= ate.

Thanks.

From: "lizhenqiang@chinamobile.com" <lizhenqiang@chinamobile.com>=
Date: Tuesday, September 2, 2014 at= 4:21 AM
To: Hannes Gredler <hannes@juniper.net>
Cc: "idr@ietf.org" <idr@ietf.= org>, "shares@ndzh.com&q= uot; <shares@ndzh.com>, 'John Scudder' <jgs@bgp.nu>
Subject: Re: [Idr] WG LC for draft-= ietf-idr-ls-distribution and draft-ietf-idr-ls-distribut-impl

Hi Hannes,

One example to explain the differences. One VPN route with prefix leng= th 24 is carried in the NRLI.

The format this draft specified is as follows.
+-+-+-+-+-+-+-+-+-+-+-+= ;-+-+-+-+-+-+-+-+-+-+-+-+-&= #43;-+-+-+-+-+-+-+-+
 |          &nb= sp; NLRI Type =3D 3         |     T= otal NLRI Length         |
+-+-+-+-+-+-+-+-+-+-+-+= ;-+-+-+-+-+-+-+-+-+-+-+-+-&= #43;-+-+-+-+-+-+-+-+
 |          &nb= sp;            =             &nb= sp;            =             &nb= sp;  |
+           = ;            Route D= istinguisher          &nb= sp;          +
 |          &nb= sp;            =             &nb= sp;            =             &nb= sp;  |
+-+-+-= +-+-+-+-+-+ +-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+=
| Protocol-ID |
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
| Identifier |
| (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
// Local Node Descriptor (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
| Type =3D 265 &nb= sp;                     &= nbsp;    | Length |
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
| Prefix Length =3D 24 | IP Prefix (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+


The format RFC4363 specified is as follows.
+-------------= --------------------------------------------+
| Address Family Identifier (2 octets) |
+---------------------------------------------------------+
| Subsequent Address Family Identifier (1 octet) |
+---------------------------------------------------------+
| Length of Next Hop Network Address (1 octet) |
+---------------------------------------------------------+
| Network Address of Next Hop (variable) |
+---------------------------------------------------------+
| Reserved (1 octet) |
+---------------------------------------------------------+
| Prefix Length =3D 88 |  IP Prefix (variable) =3D RD followed = by IP prefix // 
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-++

 
Date: 2014-09-02 16:35
Subject: Re: RE: [Idr] WG LC for draft-ietf-idr-ls-distrib= ution and draft-ietf-idr-ls-distribut-impl
hi zhenqiang,
 
On Tue, Sep 02, 2014 at 04:12:58PM +0800, lizhenqiang@chinamobile.com wrote:
|    Two types of link state NLRIs are defined in secti= on 3.2 of this
|    draft, AFI 16388 / SAFI 71 for non-VPN, AFI 16388 = / SAFI 128 for VPN.
 
correct;
 
|    My question is about AFI 16388 / SAFI 128 NLRI. Fr= om the figure in page 9
|    of draft version 5, we can see that RD is put befo= re link state NLRI.
 
 
 
this is the NLRI format for AFI 16388 / SAFI 71 (unicast)
 
    0        &n= bsp;          1  &nb= sp;            =     2         &= nbsp;         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
   +-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+
   |         &n= bsp;  NLRI Type          = |     Total NLRI Length     &n= bsp;   |
   +-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+
   |         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;   |
   //         &= nbsp;        Link-State NLRI (variable)&= nbsp;           &nbs= p;    //
   |         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;   |
   +-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+
 
and this is the NLRI format for AFI 16388 / SAFI 128 (VPN-unicast)
 
    0        &n= bsp;          1  &nb= sp;            =     2         &= nbsp;         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
   +-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+
   |         &n= bsp;  NLRI Type          = |     Total NLRI Length     &n= bsp;   |
   +-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+
   |         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;   |
   +        &nbs= p;            &= nbsp; Route Distinguisher        &n= bsp;            += ;
   |         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;   |
   +-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+
   |         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;   |
   //         &= nbsp;        Link-State NLRI (variable)&= nbsp;           &nbs= p;    //
   |         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;   |
   +-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+
 
 
 
|    The link state NLRI field in this figure contains = the IP prefix. As RFC4364
|    specifies, the VPN routes should be carried in the= NLRI prepending with
|    RD.
 
that is what we do - i fail to see the offending part with respect to = RFC4364.
 
/hannes
 
|
|      From: [1]Hannes Gredler
|      Date: 2014-09-02 15:29
|      CC: [4]'idr wg'; [5]'John G. Scudder';= [6]Susan Hares
|      Subject: RE: Re: [Idr] WG LC for draft= -ietf-idr-ls-distribution and
|      draft-ietf-idr-ls-distribut-impl
|
|      hi zhenqiang,
|
|      The Route-distinguisher's purpose is t= o add 64-bits of  disambiguating
|      entropy to the NLRI, such
|
|      that the route-reflectors do not "= ;swallow" that path as part of the
|      best-path election
|
|      procedure. The link-state NLRI (encaps= ulated in MP_REACH/ MP UNREACH PA)
|
|      is a RD-less version of the vpn-link-s= tate NLRI.
|
|      In a certain way these correspond to R= FC3107 / RFC4364 NLRI formats.
|
|      The former is a RD-less version of the= latter.
|
|      On your question "Why do't you pu= t RD in IP Reachability Information,
|      just prepending RD with IP prefix as R= FC4364 specifies." - This is
|      actually what we *are* doing - we put = the RD before the link-state NLRI
|      inside the MP_REACH/MP_UNREACH Attribu= te.
|
|      HTH,
|
|      /hannes
|
|    --------------------------------------------------= ------------------------
|
|      Sent: Tuesday, September 02, 2014 8:44=
|      To: Hannes Gredler; Uma Chunduri
|      Cc: 'idr wg'; 'John G. Scudder'; Susan= Hares
|      Subject: Re: Re: [Idr] WG LC for draft= -ietf-idr-ls-distribution and
|      draft-ietf-idr-ls-distribut-impl
|
|      One question about the VPN Link-State = NLRI in section 3.2. Why do you
|      put the RD before link state NRLI? Why= do't you put RD in IP
|      Reachability Information, just prepren= ding RD with IP prefix as RFC4364
|      specifies.
|
|    --------------------------------------------------= ------------------------
|
|
|
|        From: [7]Hannes Gredler
|        Date: 2014-09-02 02:05
|        To: [8]Uma Chunduri
|        CC: [9]idr@ietf.org; [10]'John G. Scudder'; [11]Susan Hares
|        Subject: Re: [Idr] WG LC f= or draft-ietf-idr-ls-distribution and
|        draft-ietf-idr-ls-distribu= t-impl
|        hi uma,
|
|        see comments/responses inl= ine:
|
|        On Wed, Aug 27, 2014 at 11= :07:01AM +0000, Uma Chunduri wrote:
|        |    Suppor= t.
|        |
|        |    I see,= hierarchy is WELL  defined when multiple instances of IGP
|        with
|        |    multip= le AFs are running. Good work.
|        |
|        |
|        |
|        |    Have f= ollowing Qs:
|        |
|        |    1.&nbs= p;      Any discussion of the delay introduced by = BGP (packing,
|        update
|        |    genera= tion, processing etc..) to transport the LS information
|        |
|        |    especi= ally, when LSDB is changing faster perhaps with large
|        number of
|        |    nodes/= links inside an AS and with multiple ASes) to the
|        controller will be
|        |    useful= .
|
|        this is highly implementat= ion dependent; -
|        some vendors do the packag= ing of BGP updates entirely event-driven
|        and others pack things up = and have a worst case delay between
|        the trigger event and the = BGP update. the protocol
|        itself does not prohibit/l= imit the propagation speed.
|        (in fact it can be shown t= hat sometimes updates
|        travel faster on the (data= plane forwarded) iBGP mesh,
|        rather than propgate using= the hop-by-hop control-plane flooding
|        protocol)
|
|        |    &= nbsp;            A n= ote on the sensitivity of this delay to the
|        consumer
|        |    (appli= cations) at the controller  can be helpful. I saw very
|        little
|        |    discus= sion in Section 6 (6.1.5)
|
|        difficiult - its hard to h= ave some sort of general comment as things
|        are
|        highly implementation depe= ndent.
|
|
|        |    2.&nbs= p;      This document encompasses pretty much both= OSPF and ISIS
|        |    extens= ions done till date. How it will keep up with future
|        extensions in
|        |    OSPF/I= SIS.
|
|        we have set up an IANA reg= istries for the carriers of information.
|        it is expected by authors = of "topological relevant" IGP extensions
|        to supply also BGP-LS exte= nsions.
|
|        |    A mech= anism in place would be helpful. My suggestion would be-
|        the
|        |    respec= tive IGP documents should assess the impact and define
|        |
|        |    corres= ponding new TLVs for BGP LS? But how this can be enforced?
|
|        i have no idea - today its= entirely voluntary.
|
|        |    3.&nbs= p;      Section 4, gives glimpse what's possible a= nd the node
|        aggregating
|        |    the li= nks obviously need to tinker the LSDB to represent the same
|        |    correc= tly.
|        |
|        |    Some m= ore details would be helpful to represent the changes on
|        |    aggreg= ation/de-aggregation subsequently.
|
|        this may quickly get you i= nto the "abstracted topology models"
|        discussion that keeps emer= ging  periodically. -
|        we did not want to stop pr= ogress on the protocol by arguing
|        "whats the right abst= raction model" and have agreed
|        on the minimalistic nature= of the section as-is.
|
|
|        |    4.&nbs= p;      Section 6.2 has empty sub-sections and TBD= s.
|
|        right ... so suggest to re= move section 6.2 altogether.
|
|        |    5.&nbs= p;      It's good to see Implementation report she= d light on
|        performance
|        |    seen w= ith multiple ASes.
|        |
|        |    6.&nbs= p;      It's good to see if any application of pol= icy on LSDB is
|        done
|        |    (one o= f the primary drivers of the specification).
|
|
|        thanks,
|
|
|        /hannes
|
|        |
|        |    From: = Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
|        |    Sent: = Tuesday, August 26, 2014 11:37 AM
|        |    Cc: 'J= ohn G. Scudder'; shares@ndzh.com
|        |    Subjec= t: [Idr] WG LC for draft-ietf-idr-ls-distribution and
|        |    draft-= ietf-idr-ls-distribut-impl
|        |
|        |
|        |
|        |    This i= s a WG LC for
|        |
|        |
|        |
|        |
|        |
|        |
|        |
|        |
|        |
|        |    Please= respond with comments and "support or no support."  This
|        WG LC also
|        |    includ= es a request for the authors to provide IPR on the subject.
|        |
|        |
|        |
|        |    Please= note: due to the European vacations in August, we are
|        bundling
|        |    these = three reviews into the next two weeks (these two drafts and
|        |    draft-= ietf-as-migration).   The chairs would like feedback (list
|        or
|        |    privat= e email) whether the three WG LC s impact anyone's ability
|        to review
|        |    these = drafts carefully.
|        |
|        |
|        |
|        |    Thank = you,
|        |
|        |
|        |
|        |    Sue Ha= res and John Scudder
|        |
|        | References
|        |
|        |    Visibl= e links
|        |    1.
|        |    2.
|        http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution-impl/
|
|        | ________________________= _______________________
|        | Idr mailing list
|        | Idr@ietf.org
|
|        __________________________= _____________________
|        Idr mailing list
|        Idr@ietf.org
 --_000_D02BC9221FD45sairayciscocom_-- From nobody Tue Sep 2 19:39:23 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 665F01A6F58 for ; Tue, 2 Sep 2014 19:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.255 X-Spam-Level: X-Spam-Status: No, score=0.255 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y40SiBn-wyEd for ; Tue, 2 Sep 2014 19:39:16 -0700 (PDT) Received: from cmccmta3.chinamobile.com (cmccmta3.chinamobile.com [221.176.66.81]) by ietfa.amsl.com (Postfix) with SMTP id 349A11A0AF6 for ; Tue, 2 Sep 2014 19:39:13 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.121.3]) by rmmx-syy-dmz-app12-12012 (RichMail) with SMTP id 2eec54067f4a680-737ff; Wed, 03 Sep 2014 10:39:06 +0800 (CST) X-RM-TRANSID: 2eec54067f4a680-737ff X-RM-SPAM-FLAG: 00000000 Received: from lizhenqiang (unknown[10.2.52.185]) by rmsmtp-syy-appsvr02-12002 (RichMail) with SMTP id 2ee254067f48e5c-bbb12; Wed, 03 Sep 2014 10:39:06 +0800 (CST) X-RM-TRANSID: 2ee254067f48e5c-bbb12 Date: Wed, 3 Sep 2014 10:39:25 +0800 From: "lizhenqiang@chinamobile.com" To: "Saikat Ray (sairay)" , "Hannes Gredler" References: X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 5, 140[cn] Mime-Version: 1.0 Message-ID: <2014090310392500535322@chinamobile.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart460147110622_=----" Archived-At: http://mailarchive.ietf.org/arch/msg/idr/Wab6hK9RnebMioQeyCIYCXNHDtY Cc: 'idr wg' , "'John G. Scudder'" , Susan Hares Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-ietf-idr-ls-distribut-impl X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 02:39:21 -0000 This is a multi-part message in MIME format. ------=_001_NextPart460147110622_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpCdXQgdGhlIHBvc3Rpb24gb2YgUkQgaW4gUkZDNjUxNCBpcyBBRlRFUiB0eXBlIGZpZWxkIGFu ZCBsZW5ndGggZmllbGQsIG5vdCBiZWZvcmUgdGhvc2UgZmllbGRzLiBUYWtlbiBJbnRyYS1BUyBJ LVBNU0kgQS1EIFJvdXRlIGFzIGFuIGV4YW1wbGUsDQoNCistLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLSsgDQp8IFJvdXRlIFR5cGUgKDEgb2N0ZXQpID0gMSAgfCANCistLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsgDQp8IExlbmd0aCAoMSBvY3RldCkgfCANCist LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsgDQp8IFJEICg4IG9jdGV0cykgfCAN CistLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsgDQp8IE9yaWdpbmF0aW5nIFJv dXRlcuKAmXMgSVAgQWRkciB8IA0KKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t Kw0KDQoNCg0KbGl6aGVucWlhbmdAY2hpbmFtb2JpbGUuY29tDQogDQpGcm9tOiBTYWlrYXQgUmF5 IChzYWlyYXkpDQpEYXRlOiAyMDE0LTA5LTAzIDEwOjI0DQpUbzogbGl6aGVucWlhbmdAY2hpbmFt b2JpbGUuY29tOyBIYW5uZXMgR3JlZGxlcg0KQ0M6ICdpZHIgd2cnOyBTdXNhbiBIYXJlczsgJ0pv aG4gRy4gU2N1ZGRlcicNClN1YmplY3Q6IFJlOiBbSWRyXSBXRyBMQyBmb3IgZHJhZnQtaWV0Zi1p ZHItbHMtZGlzdHJpYnV0aW9uIGFuZCBkcmFmdC1pZXRmLWlkci1scy1kaXN0cmlidXQtaW1wbA0K DQpGcm9tOiAibGl6aGVucWlhbmdAY2hpbmFtb2JpbGUuY29tIiA8bGl6aGVucWlhbmdAY2hpbmFt b2JpbGUuY29tPg0KRGF0ZTogVHVlc2RheSwgU2VwdGVtYmVyIDIsIDIwMTQgYXQgNzoxOCBQTQ0K VG86IHNhaXJheSA8c2FpcmF5QGNpc2NvLmNvbT4sIEhhbm5lcyBHcmVkbGVyIDxoYW5uZXNAanVu aXBlci5uZXQ+DQpDYzogImlkckBpZXRmLm9yZyIgPGlkckBpZXRmLm9yZz4sICJzaGFyZXNAbmR6 aC5jb20iIDxzaGFyZXNAbmR6aC5jb20+LCAnSm9obiBTY3VkZGVyJyA8amdzQGJncC5udT4NClN1 YmplY3Q6IFJlOiBSZTogW0lkcl0gV0cgTEMgZm9yIGRyYWZ0LWlldGYtaWRyLWxzLWRpc3RyaWJ1 dGlvbiBhbmQgZHJhZnQtaWV0Zi1pZHItbHMtZGlzdHJpYnV0LWltcGwNCg0KUGxhY2luZyB0aGUg dHlwZSBmaWVsZCBiZWZvcmUgdGhlIGxlbmd0aCBmaWVsZCBpcyBmaW5lIGZvciBtZS4NCg0KVGhl IGVuY29kaW5nIGZvcm1hdCBmb3IgUkQgaW4gdGhpcyBkcmFmdCBpcyBub3QgY29uc2lzdGVudCB3 aXRoIFJGQzQzNjQuIFRoaXMgaXMgdGhlIHF1ZXN0aW9uLiBSRkM2NTE0IHNheXMgIlRoZSBSb3V0 ZSBEaXN0aW5ndWlzaGVyIChSRCkgaXMgZW5jb2RlZCBhcyBkZXNjcmliZWQgaW4gW1JGQzQzNjRd IiwgcGxlYXNlIHNlZSBzZWN0aW9uIDQgb2YgUkZDNjUxNC4NCg0KW1NSXSBUaGF0IHN0YXRlbWVu dCBpbiBSRkM2NTE0IHJlZmVycyB0byBob3cgdGhlIDggYnl0ZXMgb2YgdGhlIHJvdXRlLWRpc3Rp bmd1aXNoZXIgZmllbGQgYXJlIGVuY29kZWQgKGRpZmZlcmVudCBSRCB0eXBlcywgdmFsdWVzLCBl dGMuKSwgbm90IHRvIHRoZSBwb3NpdGlvbiBvZiBSRCBmaWVsZCBpbiB0aGUgTkxSSS4NCg0KSSBh Z3JlZSB3aXRoIHlvdSBmb3IgdGhlIGFkdmFudGFnZSB0byBwdXQgdGhlIFJEIGJlZm9yZSBvdGhl ciBmaWVsZHMuIEkgcmFpc2UgdGhpcyBxdWVzaXRvbiBqdXN0IGZvciBjbGFyaWZpY2F0aW9uLg0K DQoNCg0KbGl6aGVucWlhbmdAY2hpbmFtb2JpbGUuY29tDQogDQpGcm9tOiBTYWlrYXQgUmF5IChz YWlyYXkpDQpEYXRlOiAyMDE0LTA5LTAzIDA1OjAzDQpUbzogbGl6aGVucWlhbmdAY2hpbmFtb2Jp bGUuY29tOyBIYW5uZXMgR3JlZGxlcg0KQ0M6ICdpZHIgd2cnOyBTdXNhbiBIYXJlczsgJ0pvaG4g Ry4gU2N1ZGRlcicNClN1YmplY3Q6IFJlOiBbSWRyXSBXRyBMQyBmb3IgZHJhZnQtaWV0Zi1pZHIt bHMtZGlzdHJpYnV0aW9uIGFuZCBkcmFmdC1pZXRmLWlkci1scy1kaXN0cmlidXQtaW1wbA0KSGkg WmhlbnFpYW5nOg0KDQpGb3IgdGhlIE5MUklzIHRoYXQgdXNlcyBhICJ0eXBlIiBmaWVsZCwgc3Vj aCBhcyBNVlBOIChzZWUgUkZDNjUxNCksIHRoZSBjb252ZW50aW9uIGlzIHRvIGVuY29kZSB0aGUg dHlwZSBmaWVsZCBiZWZvcmUgdGhlIGxlbmd0aCBmaWVsZC4gVGhpcyBhbGxvd3MgZm9yIGdyZWF0 ZXN0IGZsZXhpYmlsaXR5IGZvciBmdXR1cmUgZXh0ZW5zaW9ucy4gSW4gQkdQLUxTLCB3ZSBoYXZl IHVzZWQgdGhlIHNhbWUgY29udmVudGlvbi4NCg0KT3RoZXIgdGhhbiB0aGF0LCB0aGUgUkQgaXMg Zm9yIHRoZSBlbnRpcmUgYmdwLWxzIG9iamVjdCAoYmUgaXQgYSBOb2RlLCBMaW5rIG9yIFByZWZp eCkuIFNvIHBsYWNpbmcgdGhlIFJEIGZpZWxkIGJlZm9yZSBvdGhlciBmaWVsZHMgaXMgbG9naWNh bGx5IGFjY3VyYXRlLg0KDQpUaGFua3MuDQoNCkZyb206ICJsaXpoZW5xaWFuZ0BjaGluYW1vYmls ZS5jb20iIDxsaXpoZW5xaWFuZ0BjaGluYW1vYmlsZS5jb20+DQpEYXRlOiBUdWVzZGF5LCBTZXB0 ZW1iZXIgMiwgMjAxNCBhdCA0OjIxIEFNDQpUbzogSGFubmVzIEdyZWRsZXIgPGhhbm5lc0BqdW5p cGVyLm5ldD4NCkNjOiAiaWRyQGlldGYub3JnIiA8aWRyQGlldGYub3JnPiwgInNoYXJlc0BuZHpo LmNvbSIgPHNoYXJlc0BuZHpoLmNvbT4sICdKb2huIFNjdWRkZXInIDxqZ3NAYmdwLm51Pg0KU3Vi amVjdDogUmU6IFtJZHJdIFdHIExDIGZvciBkcmFmdC1pZXRmLWlkci1scy1kaXN0cmlidXRpb24g YW5kIGRyYWZ0LWlldGYtaWRyLWxzLWRpc3RyaWJ1dC1pbXBsDQoNCkhpIEhhbm5lcywNCg0KT25l IGV4YW1wbGUgdG8gZXhwbGFpbiB0aGUgZGlmZmVyZW5jZXMuIE9uZSBWUE4gcm91dGUgd2l0aCBw cmVmaXggbGVuZ3RoIDI0IGlzIGNhcnJpZWQgaW4gdGhlIE5STEkuDQoNClRoZSBmb3JtYXQgdGhp cyBkcmFmdCBzcGVjaWZpZWQgaXMgYXMgZm9sbG93cy4NCistKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogfCAgICAgICAgICAg IE5MUkkgVHlwZSA9IDMgICAgICAgICB8ICAgICBUb3RhbCBOTFJJIExlbmd0aCAgICAgICAgIHwN CistKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rDQogfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHwNCisgICAgICAgICAgICAgICAgICAgICAgIFJvdXRlIERpc3Rp bmd1aXNoZXIgICAgICAgICAgICAgICAgICAgICArDQogfCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCistKy0rLSstKy0rLSst Ky0rICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQp8IFByb3RvY29s LUlEIHwgDQorLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKyANCnwgSWRlbnRpZmllciB8IA0KfCAoNjQgYml0cykgfCANCistKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rIA0KLy8gTG9jYWwgTm9kZSBEZXNjcmlwdG9yICh2YXJpYWJsZSkgLy8gDQorLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyAN CnwgVHlwZSA9IDI2NSAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IExlbmd0aCB8IA0KKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSsgDQp8IFByZWZpeCBMZW5ndGggPSAyNCB8IElQIFByZWZpeCAodmFyaWFibGUpIC8vIA0K Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSsNCg0KDQpUaGUgZm9ybWF0IFJGQzQzNjMgc3BlY2lmaWVkIGlzIGFzIGZvbGxvd3Mu DQorLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tKyANCnwgQWRkcmVzcyBGYW1pbHkgSWRlbnRpZmllciAoMiBvY3RldHMpIHwgDQorLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKyANCnwg U3Vic2VxdWVudCBBZGRyZXNzIEZhbWlseSBJZGVudGlmaWVyICgxIG9jdGV0KSB8IA0KKy0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsgDQp8 IExlbmd0aCBvZiBOZXh0IEhvcCBOZXR3b3JrIEFkZHJlc3MgKDEgb2N0ZXQpIHwgDQorLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKyANCnwg TmV0d29yayBBZGRyZXNzIG9mIE5leHQgSG9wICh2YXJpYWJsZSkgfCANCistLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rIA0KfCBSZXNlcnZl ZCAoMSBvY3RldCkgfCANCistLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0rIA0KfCBQcmVmaXggTGVuZ3RoID0gODggfCAgSVAgUHJlZml4ICh2 YXJpYWJsZSkgPSBSRCBmb2xsb3dlZCBieSBJUCBwcmVmaXggLy8gDQorLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKysNCg0KDQoN CmxpemhlbnFpYW5nQGNoaW5hbW9iaWxlLmNvbQ0KIA0KRnJvbTogSGFubmVzIEdyZWRsZXINCkRh dGU6IDIwMTQtMDktMDIgMTY6MzUNClRvOiBsaXpoZW5xaWFuZ0BjaGluYW1vYmlsZS5jb20NCkND OiBVbWEgQ2h1bmR1cmk7ICdpZHIgd2cnOyAnSm9obiBHLiBTY3VkZGVyJzsgU3VzYW4gSGFyZXMN ClN1YmplY3Q6IFJlOiBSRTogW0lkcl0gV0cgTEMgZm9yIGRyYWZ0LWlldGYtaWRyLWxzLWRpc3Ry aWJ1dGlvbiBhbmQgZHJhZnQtaWV0Zi1pZHItbHMtZGlzdHJpYnV0LWltcGwNCmhpIHpoZW5xaWFu ZywNCiANCk9uIFR1ZSwgU2VwIDAyLCAyMDE0IGF0IDA0OjEyOjU4UE0gKzA4MDAsIGxpemhlbnFp YW5nQGNoaW5hbW9iaWxlLmNvbSB3cm90ZToNCnwgICAgVHdvIHR5cGVzIG9mIGxpbmsgc3RhdGUg TkxSSXMgYXJlIGRlZmluZWQgaW4gc2VjdGlvbiAzLjIgb2YgdGhpcw0KfCAgICBkcmFmdCwgQUZJ IDE2Mzg4IC8gU0FGSSA3MSBmb3Igbm9uLVZQTiwgQUZJIDE2Mzg4IC8gU0FGSSAxMjggZm9yIFZQ Ti4NCiANCmNvcnJlY3Q7DQogDQp8ICAgIE15IHF1ZXN0aW9uIGlzIGFib3V0IEFGSSAxNjM4OCAv IFNBRkkgMTI4IE5MUkkuIEZyb20gdGhlIGZpZ3VyZSBpbiBwYWdlIDkNCnwgICAgb2YgZHJhZnQg dmVyc2lvbiA1LCB3ZSBjYW4gc2VlIHRoYXQgUkQgaXMgcHV0IGJlZm9yZSBsaW5rIHN0YXRlIE5M UkkuDQogDQogDQpmcm9tIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtaWRy LWxzLWRpc3RyaWJ1dGlvbi0wNSNzZWN0aW9uLTMuMg0KIA0KdGhpcyBpcyB0aGUgTkxSSSBmb3Jt YXQgZm9yIEFGSSAxNjM4OCAvIFNBRkkgNzEgKHVuaWNhc3QpDQogDQogICAgMCAgICAgICAgICAg ICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAgMw0KICAgIDAg MSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5 IDAgMQ0KICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSsNCiAgIHwgICAgICAgICAgICBOTFJJIFR5cGUgICAgICAgICAgfCAg ICAgVG90YWwgTkxSSSBMZW5ndGggICAgICAgICB8DQogICArLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgfCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwN CiAgIC8vICAgICAgICAgICAgICAgICAgTGluay1TdGF0ZSBOTFJJICh2YXJpYWJsZSkgICAgICAg ICAgICAgICAgIC8vDQogICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiANCmFuZCB0aGlzIGlzIHRo ZSBOTFJJIGZvcm1hdCBmb3IgQUZJIDE2Mzg4IC8gU0FGSSAxMjggKFZQTi11bmljYXN0KQ0KIA0K ICAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAg ICAgICAgIDMNCiAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAx IDIgMyA0IDUgNiA3IDggOSAwIDENCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICB8ICAgICAgICAgICAgTkxSSSBU eXBlICAgICAgICAgIHwgICAgIFRvdGFsIE5MUkkgTGVuZ3RoICAgICAgICAgfA0KICAgKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSsNCiAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB8DQogICArICAgICAgICAgICAgICAgICAgICAgICBSb3V0ZSBEaXN0aW5n dWlzaGVyICAgICAgICAgICAgICAgICAgICAgKw0KICAgfCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQog ICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfA0KICAgLy8gICAgICAgICAgICAgICAgICBMaW5rLVN0YXRlIE5MUkkgKHZhcmlh YmxlKSAgICAgICAgICAgICAgICAgLy8NCiAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICArLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KIA0KIA0K IA0KfCAgICBUaGUgbGluayBzdGF0ZSBOTFJJIGZpZWxkIGluIHRoaXMgZmlndXJlIGNvbnRhaW5z IHRoZSBJUCBwcmVmaXguIEFzIFJGQzQzNjQNCnwgICAgc3BlY2lmaWVzLCB0aGUgVlBOIHJvdXRl cyBzaG91bGQgYmUgY2FycmllZCBpbiB0aGUgTkxSSSBwcmVwZW5kaW5nIHdpdGgNCnwgICAgUkQu DQogDQp0aGF0IGlzIHdoYXQgd2UgZG8gLSBpIGZhaWwgdG8gc2VlIHRoZSBvZmZlbmRpbmcgcGFy dCB3aXRoIHJlc3BlY3QgdG8gUkZDNDM2NC4NCiANCi9oYW5uZXMNCiANCnwgDQp8ICAgICAgRnJv bTogWzFdSGFubmVzIEdyZWRsZXINCnwgICAgICBEYXRlOiAyMDE0LTA5LTAyIDE1OjI5DQp8ICAg ICAgVG86IFsyXWxpemhlbnFpYW5nQGNoaW5hbW9iaWxlLmNvbTsgWzNdVW1hIENodW5kdXJpDQp8 ICAgICAgQ0M6IFs0XSdpZHIgd2cnOyBbNV0nSm9obiBHLiBTY3VkZGVyJzsgWzZdU3VzYW4gSGFy ZXMNCnwgICAgICBTdWJqZWN0OiBSRTogUmU6IFtJZHJdIFdHIExDIGZvciBkcmFmdC1pZXRmLWlk ci1scy1kaXN0cmlidXRpb24gYW5kDQp8ICAgICAgZHJhZnQtaWV0Zi1pZHItbHMtZGlzdHJpYnV0 LWltcGwNCnwgDQp8ICAgICAgaGkgemhlbnFpYW5nLA0KfCANCnwgICAgICBUaGUgUm91dGUtZGlz dGluZ3Vpc2hlcidzIHB1cnBvc2UgaXMgdG8gYWRkIDY0LWJpdHMgb2YgIGRpc2FtYmlndWF0aW5n DQp8ICAgICAgZW50cm9weSB0byB0aGUgTkxSSSwgc3VjaA0KfCANCnwgICAgICB0aGF0IHRoZSBy b3V0ZS1yZWZsZWN0b3JzIGRvIG5vdCAic3dhbGxvdyIgdGhhdCBwYXRoIGFzIHBhcnQgb2YgdGhl DQp8ICAgICAgYmVzdC1wYXRoIGVsZWN0aW9uDQp8IA0KfCAgICAgIHByb2NlZHVyZS4gVGhlIGxp bmstc3RhdGUgTkxSSSAoZW5jYXBzdWxhdGVkIGluIE1QX1JFQUNILyBNUCBVTlJFQUNIIFBBKQ0K fCANCnwgICAgICBpcyBhIFJELWxlc3MgdmVyc2lvbiBvZiB0aGUgdnBuLWxpbmstc3RhdGUgTkxS SS4NCnwgDQp8ICAgICAgSW4gYSBjZXJ0YWluIHdheSB0aGVzZSBjb3JyZXNwb25kIHRvIFJGQzMx MDcgLyBSRkM0MzY0IE5MUkkgZm9ybWF0cy4NCnwgDQp8ICAgICAgVGhlIGZvcm1lciBpcyBhIFJE LWxlc3MgdmVyc2lvbiBvZiB0aGUgbGF0dGVyLg0KfCANCnwgICAgICBPbiB5b3VyIHF1ZXN0aW9u ICJXaHkgZG8ndCB5b3UgcHV0IFJEIGluIElQIFJlYWNoYWJpbGl0eSBJbmZvcm1hdGlvbiwNCnwg ICAgICBqdXN0IHByZXBlbmRpbmcgUkQgd2l0aCBJUCBwcmVmaXggYXMgUkZDNDM2NCBzcGVjaWZp ZXMuIiAtIFRoaXMgaXMNCnwgICAgICBhY3R1YWxseSB3aGF0IHdlICphcmUqIGRvaW5nIC0gd2Ug cHV0IHRoZSBSRCBiZWZvcmUgdGhlIGxpbmstc3RhdGUgTkxSSQ0KfCAgICAgIGluc2lkZSB0aGUg TVBfUkVBQ0gvTVBfVU5SRUFDSCBBdHRyaWJ1dGUuDQp8IA0KfCAgICAgIEhUSCwNCnwgDQp8ICAg ICAgL2hhbm5lcw0KfCANCnwgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCnwgDQp8ICAgICAgRnJvbTog bGl6aGVucWlhbmdAY2hpbmFtb2JpbGUuY29tIDxsaXpoZW5xaWFuZ0BjaGluYW1vYmlsZS5jb20+ DQp8ICAgICAgU2VudDogVHVlc2RheSwgU2VwdGVtYmVyIDAyLCAyMDE0IDg6NDQNCnwgICAgICBU bzogSGFubmVzIEdyZWRsZXI7IFVtYSBDaHVuZHVyaQ0KfCAgICAgIENjOiAnaWRyIHdnJzsgJ0pv aG4gRy4gU2N1ZGRlcic7IFN1c2FuIEhhcmVzDQp8ICAgICAgU3ViamVjdDogUmU6IFJlOiBbSWRy XSBXRyBMQyBmb3IgZHJhZnQtaWV0Zi1pZHItbHMtZGlzdHJpYnV0aW9uIGFuZA0KfCAgICAgIGRy YWZ0LWlldGYtaWRyLWxzLWRpc3RyaWJ1dC1pbXBsDQp8IA0KfCAgICAgIE9uZSBxdWVzdGlvbiBh Ym91dCB0aGUgVlBOIExpbmstU3RhdGUgTkxSSSBpbiBzZWN0aW9uIDMuMi4gV2h5IGRvIHlvdQ0K fCAgICAgIHB1dCB0aGUgUkQgYmVmb3JlIGxpbmsgc3RhdGUgTlJMST8gV2h5IGRvJ3QgeW91IHB1 dCBSRCBpbiBJUA0KfCAgICAgIFJlYWNoYWJpbGl0eSBJbmZvcm1hdGlvbiwganVzdCBwcmVwcmVu ZGluZyBSRCB3aXRoIElQIHByZWZpeCBhcyBSRkM0MzY0DQp8ICAgICAgc3BlY2lmaWVzLg0KfCAN CnwgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCnwgDQp8ICAgICAgbGl6aGVucWlhbmdAY2hpbmFtb2Jp bGUuY29tDQp8IA0KfCANCnwgICAgICAgIEZyb206IFs3XUhhbm5lcyBHcmVkbGVyDQp8ICAgICAg ICBEYXRlOiAyMDE0LTA5LTAyIDAyOjA1DQp8ICAgICAgICBUbzogWzhdVW1hIENodW5kdXJpDQp8 ICAgICAgICBDQzogWzldaWRyQGlldGYub3JnOyBbMTBdJ0pvaG4gRy4gU2N1ZGRlcic7IFsxMV1T dXNhbiBIYXJlcw0KfCAgICAgICAgU3ViamVjdDogUmU6IFtJZHJdIFdHIExDIGZvciBkcmFmdC1p ZXRmLWlkci1scy1kaXN0cmlidXRpb24gYW5kDQp8ICAgICAgICBkcmFmdC1pZXRmLWlkci1scy1k aXN0cmlidXQtaW1wbA0KfCAgICAgICAgaGkgdW1hLA0KfCANCnwgICAgICAgIHNlZSBjb21tZW50 cy9yZXNwb25zZXMgaW5saW5lOg0KfCANCnwgICAgICAgIE9uIFdlZCwgQXVnIDI3LCAyMDE0IGF0 IDExOjA3OjAxQU0gKzAwMDAsIFVtYSBDaHVuZHVyaSB3cm90ZToNCnwgICAgICAgIHwgICAgU3Vw cG9ydC4NCnwgICAgICAgIHwNCnwgICAgICAgIHwgICAgSSBzZWUsIGhpZXJhcmNoeSBpcyBXRUxM ICBkZWZpbmVkIHdoZW4gbXVsdGlwbGUgaW5zdGFuY2VzIG9mIElHUA0KfCAgICAgICAgd2l0aA0K fCAgICAgICAgfCAgICBtdWx0aXBsZSBBRnMgYXJlIHJ1bm5pbmcuIEdvb2Qgd29yay4NCnwgICAg ICAgIHwNCnwgICAgICAgIHwNCnwgICAgICAgIHwNCnwgICAgICAgIHwgICAgSGF2ZSBmb2xsb3dp bmcgUXM6DQp8ICAgICAgICB8DQp8ICAgICAgICB8ICAgIDEuICAgICAgIEFueSBkaXNjdXNzaW9u IG9mIHRoZSBkZWxheSBpbnRyb2R1Y2VkIGJ5IEJHUCAocGFja2luZywNCnwgICAgICAgIHVwZGF0 ZQ0KfCAgICAgICAgfCAgICBnZW5lcmF0aW9uLCBwcm9jZXNzaW5nIGV0Yy4uKSB0byB0cmFuc3Bv cnQgdGhlIExTIGluZm9ybWF0aW9uDQp8ICAgICAgICB8DQp8ICAgICAgICB8ICAgIGVzcGVjaWFs bHksIHdoZW4gTFNEQiBpcyBjaGFuZ2luZyBmYXN0ZXIgcGVyaGFwcyB3aXRoIGxhcmdlDQp8ICAg ICAgICBudW1iZXIgb2YNCnwgICAgICAgIHwgICAgbm9kZXMvbGlua3MgaW5zaWRlIGFuIEFTIGFu ZCB3aXRoIG11bHRpcGxlIEFTZXMpIHRvIHRoZQ0KfCAgICAgICAgY29udHJvbGxlciB3aWxsIGJl DQp8ICAgICAgICB8ICAgIHVzZWZ1bC4NCnwgDQp8ICAgICAgICB0aGlzIGlzIGhpZ2hseSBpbXBs ZW1lbnRhdGlvbiBkZXBlbmRlbnQ7IC0NCnwgICAgICAgIHNvbWUgdmVuZG9ycyBkbyB0aGUgcGFj a2FnaW5nIG9mIEJHUCB1cGRhdGVzIGVudGlyZWx5IGV2ZW50LWRyaXZlbg0KfCAgICAgICAgYW5k IG90aGVycyBwYWNrIHRoaW5ncyB1cCBhbmQgaGF2ZSBhIHdvcnN0IGNhc2UgZGVsYXkgYmV0d2Vl bg0KfCAgICAgICAgdGhlIHRyaWdnZXIgZXZlbnQgYW5kIHRoZSBCR1AgdXBkYXRlLiB0aGUgcHJv dG9jb2wNCnwgICAgICAgIGl0c2VsZiBkb2VzIG5vdCBwcm9oaWJpdC9saW1pdCB0aGUgcHJvcGFn YXRpb24gc3BlZWQuDQp8ICAgICAgICAoaW4gZmFjdCBpdCBjYW4gYmUgc2hvd24gdGhhdCBzb21l dGltZXMgdXBkYXRlcw0KfCAgICAgICAgdHJhdmVsIGZhc3RlciBvbiB0aGUgKGRhdGFwbGFuZSBm b3J3YXJkZWQpIGlCR1AgbWVzaCwNCnwgICAgICAgIHJhdGhlciB0aGFuIHByb3BnYXRlIHVzaW5n IHRoZSBob3AtYnktaG9wIGNvbnRyb2wtcGxhbmUgZmxvb2RpbmcNCnwgICAgICAgIHByb3RvY29s KQ0KfCANCnwgICAgICAgIHwgICAgICAgICAgICAgICAgIEEgbm90ZSBvbiB0aGUgc2Vuc2l0aXZp dHkgb2YgdGhpcyBkZWxheSB0byB0aGUNCnwgICAgICAgIGNvbnN1bWVyDQp8ICAgICAgICB8ICAg IChhcHBsaWNhdGlvbnMpIGF0IHRoZSBjb250cm9sbGVyICBjYW4gYmUgaGVscGZ1bC4gSSBzYXcg dmVyeQ0KfCAgICAgICAgbGl0dGxlDQp8ICAgICAgICB8ICAgIGRpc2N1c3Npb24gaW4gU2VjdGlv biA2ICg2LjEuNSkNCnwgDQp8ICAgICAgICBkaWZmaWNpdWx0IC0gaXRzIGhhcmQgdG8gaGF2ZSBz b21lIHNvcnQgb2YgZ2VuZXJhbCBjb21tZW50IGFzIHRoaW5ncw0KfCAgICAgICAgYXJlDQp8ICAg ICAgICBoaWdobHkgaW1wbGVtZW50YXRpb24gZGVwZW5kZW50Lg0KfCANCnwgDQp8ICAgICAgICB8 ICAgIDIuICAgICAgIFRoaXMgZG9jdW1lbnQgZW5jb21wYXNzZXMgcHJldHR5IG11Y2ggYm90aCBP U1BGIGFuZCBJU0lTDQp8ICAgICAgICB8ICAgIGV4dGVuc2lvbnMgZG9uZSB0aWxsIGRhdGUuIEhv dyBpdCB3aWxsIGtlZXAgdXAgd2l0aCBmdXR1cmUNCnwgICAgICAgIGV4dGVuc2lvbnMgaW4NCnwg ICAgICAgIHwgICAgT1NQRi9JU0lTLg0KfCANCnwgICAgICAgIHdlIGhhdmUgc2V0IHVwIGFuIElB TkEgcmVnaXN0cmllcyBmb3IgdGhlIGNhcnJpZXJzIG9mIGluZm9ybWF0aW9uLg0KfCAgICAgICAg aXQgaXMgZXhwZWN0ZWQgYnkgYXV0aG9ycyBvZiAidG9wb2xvZ2ljYWwgcmVsZXZhbnQiIElHUCBl eHRlbnNpb25zDQp8ICAgICAgICB0byBzdXBwbHkgYWxzbyBCR1AtTFMgZXh0ZW5zaW9ucy4NCnwg DQp8ICAgICAgICB8ICAgIEEgbWVjaGFuaXNtIGluIHBsYWNlIHdvdWxkIGJlIGhlbHBmdWwuIE15 IHN1Z2dlc3Rpb24gd291bGQgYmUtDQp8ICAgICAgICB0aGUNCnwgICAgICAgIHwgICAgcmVzcGVj dGl2ZSBJR1AgZG9jdW1lbnRzIHNob3VsZCBhc3Nlc3MgdGhlIGltcGFjdCBhbmQgZGVmaW5lDQp8 ICAgICAgICB8DQp8ICAgICAgICB8ICAgIGNvcnJlc3BvbmRpbmcgbmV3IFRMVnMgZm9yIEJHUCBM Uz8gQnV0IGhvdyB0aGlzIGNhbiBiZSBlbmZvcmNlZD8NCnwgDQp8ICAgICAgICBpIGhhdmUgbm8g aWRlYSAtIHRvZGF5IGl0cyBlbnRpcmVseSB2b2x1bnRhcnkuDQp8IA0KfCAgICAgICAgfCAgICAz LiAgICAgICBTZWN0aW9uIDQsIGdpdmVzIGdsaW1wc2Ugd2hhdCdzIHBvc3NpYmxlIGFuZCB0aGUg bm9kZQ0KfCAgICAgICAgYWdncmVnYXRpbmcNCnwgICAgICAgIHwgICAgdGhlIGxpbmtzIG9idmlv dXNseSBuZWVkIHRvIHRpbmtlciB0aGUgTFNEQiB0byByZXByZXNlbnQgdGhlIHNhbWUNCnwgICAg ICAgIHwgICAgY29ycmVjdGx5Lg0KfCAgICAgICAgfA0KfCAgICAgICAgfCAgICBTb21lIG1vcmUg ZGV0YWlscyB3b3VsZCBiZSBoZWxwZnVsIHRvIHJlcHJlc2VudCB0aGUgY2hhbmdlcyBvbg0KfCAg ICAgICAgfCAgICBhZ2dyZWdhdGlvbi9kZS1hZ2dyZWdhdGlvbiBzdWJzZXF1ZW50bHkuDQp8IA0K fCAgICAgICAgdGhpcyBtYXkgcXVpY2tseSBnZXQgeW91IGludG8gdGhlICJhYnN0cmFjdGVkIHRv cG9sb2d5IG1vZGVscyINCnwgICAgICAgIGRpc2N1c3Npb24gdGhhdCBrZWVwcyBlbWVyZ2luZyAg cGVyaW9kaWNhbGx5LiAtDQp8ICAgICAgICB3ZSBkaWQgbm90IHdhbnQgdG8gc3RvcCBwcm9ncmVz cyBvbiB0aGUgcHJvdG9jb2wgYnkgYXJndWluZw0KfCAgICAgICAgIndoYXRzIHRoZSByaWdodCBh YnN0cmFjdGlvbiBtb2RlbCIgYW5kIGhhdmUgYWdyZWVkDQp8ICAgICAgICBvbiB0aGUgbWluaW1h bGlzdGljIG5hdHVyZSBvZiB0aGUgc2VjdGlvbiBhcy1pcy4NCnwgDQp8IA0KfCAgICAgICAgfCAg ICA0LiAgICAgICBTZWN0aW9uIDYuMiBoYXMgZW1wdHkgc3ViLXNlY3Rpb25zIGFuZCBUQkRzLg0K fCANCnwgICAgICAgIHJpZ2h0IC4uLiBzbyBzdWdnZXN0IHRvIHJlbW92ZSBzZWN0aW9uIDYuMiBh bHRvZ2V0aGVyLg0KfCANCnwgICAgICAgIHwgICAgNS4gICAgICAgSXQncyBnb29kIHRvIHNlZSBJ bXBsZW1lbnRhdGlvbiByZXBvcnQgc2hlZCBsaWdodCBvbg0KfCAgICAgICAgcGVyZm9ybWFuY2UN CnwgICAgICAgIHwgICAgc2VlbiB3aXRoIG11bHRpcGxlIEFTZXMuDQp8ICAgICAgICB8DQp8ICAg ICAgICB8ICAgIDYuICAgICAgIEl0J3MgZ29vZCB0byBzZWUgaWYgYW55IGFwcGxpY2F0aW9uIG9m IHBvbGljeSBvbiBMU0RCIGlzDQp8ICAgICAgICBkb25lDQp8ICAgICAgICB8ICAgIChvbmUgb2Yg dGhlIHByaW1hcnkgZHJpdmVycyBvZiB0aGUgc3BlY2lmaWNhdGlvbikuDQp8IA0KfCANCnwgICAg ICAgIHRoYW5rcywNCnwgDQp8IA0KfCAgICAgICAgL2hhbm5lcw0KfCANCnwgICAgICAgIHwNCnwg ICAgICAgIHwgICAgRnJvbTogSWRyIFttYWlsdG86aWRyLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBTdXNhbiBIYXJlcw0KfCAgICAgICAgfCAgICBTZW50OiBUdWVzZGF5LCBBdWd1c3Qg MjYsIDIwMTQgMTE6MzcgQU0NCnwgICAgICAgIHwgICAgVG86IGlkckBpZXRmLm9yZw0KfCAgICAg ICAgfCAgICBDYzogJ0pvaG4gRy4gU2N1ZGRlcic7IHNoYXJlc0BuZHpoLmNvbQ0KfCAgICAgICAg fCAgICBTdWJqZWN0OiBbSWRyXSBXRyBMQyBmb3IgZHJhZnQtaWV0Zi1pZHItbHMtZGlzdHJpYnV0 aW9uIGFuZA0KfCAgICAgICAgfCAgICBkcmFmdC1pZXRmLWlkci1scy1kaXN0cmlidXQtaW1wbA0K fCAgICAgICAgfA0KfCAgICAgICAgfA0KfCAgICAgICAgfA0KfCAgICAgICAgfCAgICBUaGlzIGlz IGEgV0cgTEMgZm9yDQp8ICAgICAgICB8DQp8ICAgICAgICB8DQp8ICAgICAgICB8DQp8ICAgICAg ICB8DQp8ICAgICAgICBbMV1odHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll dGYtaWRyLWxzLWRpc3RyaWJ1dGlvbi8NCnwgICAgICAgIHwNCnwgICAgICAgIHwNCnwgICAgICAg IFsyXWh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pZHItbHMtZGlz dHJpYnV0aW9uLWltcGwvDQp8ICAgICAgICB8DQp8ICAgICAgICB8DQp8ICAgICAgICB8DQp8ICAg ICAgICB8ICAgIFBsZWFzZSByZXNwb25kIHdpdGggY29tbWVudHMgYW5kICJzdXBwb3J0IG9yIG5v IHN1cHBvcnQuIiAgVGhpcw0KfCAgICAgICAgV0cgTEMgYWxzbw0KfCAgICAgICAgfCAgICBpbmNs dWRlcyBhIHJlcXVlc3QgZm9yIHRoZSBhdXRob3JzIHRvIHByb3ZpZGUgSVBSIG9uIHRoZSBzdWJq ZWN0Lg0KfCAgICAgICAgfA0KfCAgICAgICAgfA0KfCAgICAgICAgfA0KfCAgICAgICAgfCAgICBQ bGVhc2Ugbm90ZTogZHVlIHRvIHRoZSBFdXJvcGVhbiB2YWNhdGlvbnMgaW4gQXVndXN0LCB3ZSBh cmUNCnwgICAgICAgIGJ1bmRsaW5nDQp8ICAgICAgICB8ICAgIHRoZXNlIHRocmVlIHJldmlld3Mg aW50byB0aGUgbmV4dCB0d28gd2Vla3MgKHRoZXNlIHR3byBkcmFmdHMgYW5kDQp8ICAgICAgICB8 ICAgIGRyYWZ0LWlldGYtYXMtbWlncmF0aW9uKS4gICBUaGUgY2hhaXJzIHdvdWxkIGxpa2UgZmVl ZGJhY2sgKGxpc3QNCnwgICAgICAgIG9yDQp8ICAgICAgICB8ICAgIHByaXZhdGUgZW1haWwpIHdo ZXRoZXIgdGhlIHRocmVlIFdHIExDIHMgaW1wYWN0IGFueW9uZSdzIGFiaWxpdHkNCnwgICAgICAg IHRvIHJldmlldw0KfCAgICAgICAgfCAgICB0aGVzZSBkcmFmdHMgY2FyZWZ1bGx5Lg0KfCAgICAg ICAgfA0KfCAgICAgICAgfA0KfCAgICAgICAgfA0KfCAgICAgICAgfCAgICBUaGFuayB5b3UsDQp8 ICAgICAgICB8DQp8ICAgICAgICB8DQp8ICAgICAgICB8DQp8ICAgICAgICB8ICAgIFN1ZSBIYXJl cyBhbmQgSm9obiBTY3VkZGVyDQp8ICAgICAgICB8DQp8ICAgICAgICB8IFJlZmVyZW5jZXMNCnwg ICAgICAgIHwNCnwgICAgICAgIHwgICAgVmlzaWJsZSBsaW5rcw0KfCAgICAgICAgfCAgICAxLg0K fCAgICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWlkci1s cy1kaXN0cmlidXRpb24vDQp8ICAgICAgICB8ICAgIDIuDQp8ICAgICAgICBodHRwOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaWRyLWxzLWRpc3RyaWJ1dGlvbi1pbXBsLw0K fCANCnwgICAgICAgIHwgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCnwgICAgICAgIHwgSWRyIG1haWxpbmcgbGlzdA0KfCAgICAgICAgfCBJZHJAaWV0Zi5v cmcNCnwgICAgICAgIHwgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZHIN CnwgDQp8ICAgICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KfCAgICAgICAgSWRyIG1haWxpbmcgbGlzdA0KfCAgICAgICAgSWRyQGlldGYub3JnDQp8 ICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkcg0KfCANCnwg DQp8IFJlZmVyZW5jZXMNCnwgDQp8ICAgIFZpc2libGUgbGlua3MNCnwgICAgMS4gbWFpbHRvOmhh bm5lc0BqdW5pcGVyLm5ldA0KfCAgICAyLiBtYWlsdG86bGl6aGVucWlhbmdAY2hpbmFtb2JpbGUu Y29tDQp8ICAgIDMuIG1haWx0bzp1bWEuY2h1bmR1cmlAZXJpY3Nzb24uY29tDQp8ICAgIDQuIG1h aWx0bzppZHJAaWV0Zi5vcmcNCnwgICAgNS4gbWFpbHRvOmpnc0BiZ3AubnUNCnwgICAgNi4gbWFp bHRvOnNoYXJlc0BuZHpoLmNvbQ0KfCAgICA3LiBtYWlsdG86aGFubmVzQGp1bmlwZXIubmV0DQp8 ICAgIDguIG1haWx0bzp1bWEuY2h1bmR1cmlAZXJpY3Nzb24uY29tDQp8ICAgIDkuIG1haWx0bzpp ZHJAaWV0Zi5vcmcNCnwgICAxMC4gbWFpbHRvOmpnc0BiZ3AubnUNCnwgICAxMS4gbWFpbHRvOnNo YXJlc0BuZHpoLmNvbQ0KIA0K ------=_001_NextPart460147110622_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =0A

But the postion of RD in RFC6514 is AFTER type field and l= ength field, not before those fields. Taken Intra-AS I= -PMSI A-D Route as an example,

+---= --------------------------------+=0A
| Route Type (1 octet) =3D 1  = ;|=0A
+-----------------------------------+=0A
| Length (1 octet) |= =0A
+-----------------------------------+=0A
| RD (8 octets) |= =0A
+-----------------------------------+=0A
| Originating Router=E2= =80=99s IP Addr |=0A
+-----------------------------------+
=0A
=0A
=0A
lizhenqiang@chinamobile.com
=0A
 
D= ate: 2014-09-03 10:24
Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-= distribution and draft-ietf-idr-ls-distribut-impl
=0A

=0A
=0A=0A
=0AFrom: "lizhenqiang@chinamobile.com" <lizhenqiang@chinamobile.com>=0ADate: Tuesday, September 2, 2= 014 at 7:18 PM
=0ATo: sairay &l= t;sairay@cisco.com>, Hannes Gre= dler <hannes@juniper.net><= br>=0ACc: "idr@ietf.org" <idr@ietf.or= g>, "shares@ndzh.com" <shares@ndzh.com>, 'John=0A Scudder= ' <jgs@bgp.nu>
=0ASubject: Re: Re: [Idr] WG LC for draft-ietf-i= dr-ls-distribution and draft-ietf-idr-ls-distribut-impl
=0A
=0A
=0A
=0A
=0A
=0A
Placing the type field= before the length field is fine for me.
=0A

=0A
=0AThe encoding format for RD in this draft is not consistent with RFC4364. = This is the question. RFC6514 says "The Route Distinguisher= (RD) is encoded as described in=0A [RFC4364]", please see sec= tion 4 of RFC6514.
=0A
=0A
=0A=0A

=0A=
=0A
[SR] That statement in RFC6514 refers to how the 8 bytes of = the route-distinguisher field are encoded (different RD types, values, etc= .), not to the position of RD field in the NLRI.
=0A=0A
=0A
=0A

=0A
=0A
I agree with= you for the advantage to put the RD before other fields. I raise this que= siton just for clarification.
=0A

=0A
=0A
=0A<= div>=0A=0A
=0A
=0A
 
=0A
=0A=0A
Date: 2014-09-03&= nbsp;05:03
=0A=0A=0A<= div>Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-distributio= n and draft-ietf-idr-ls-distribut-impl
=0A
=0A
=0A
=0A<= div class=3D"FoxDiv20140903093606456737" style=3D"word-wrap: break-word; -= webkit-line-break: after-white-space;">=0A
Hi Zhenqiang:
=0A
=0A
=0A
=0A
=0AFor the NLRIs that uses a "type" fi= eld, such as MVPN (see RFC6514), the convention is to encode the type fiel= d before the length field. This allows for greatest flexibility for future= extensions. In BGP-LS, we have used the same convention.
=0A
=0A
=0A
=0A
=0AOther than that, the RD is f= or the entire bgp-ls object (be it a Node, Link or Prefix). So placing the= RD field before other fields is logically accurate.
=0A
=0A
=0A
=0A
=0AThanks.
=0A
= =0A
=0A
=0A=0A
=0AFrom: "lizhenqia= ng@chinamobile.com" <lizhenqiang@chinamobile.com>
=0ADate: Tuesday, September 2, 2014 at 4:21 AM
=0ATo: Hannes Gredler <hannes@juniper.net>
=0ACc: "idr@ietf.org" <idr@ietf.org>, "shares@ndzh.com" <sh= ares@ndzh.com>, 'John=0A Scudder' <jgs@bgp.nu>
=0ASubject: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-ietf-idr-ls-= distribut-impl
=0A
=0A

=0A
=0A
=0A
=0A
Hi Hannes,
=0A

=0A
=0A
One example to exp= lain the differences. One VPN route with prefix length 24 is carried in th= e NRLI.
=0A

=0A
=0A
The format this draft specified = is as follows.
=0A
=0A
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+
=0A
 |    &n= bsp;       NLRI Type =3D 3     &nb= sp;   |     Total NLRI Length   &n= bsp;     |
=0A
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=0A
 |   =             &n= bsp;           &nbs= p;            =             &n= bsp;          |
=0A
= +            &= nbsp;          Route Distingu= isher           &nb= sp;         +
=0A
 |=             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p; |
=0A
+-+-= +-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=0A| Protocol-ID |
= =0A+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= =0A| Identifier |
=0A| (64 bits) |
=0A+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=0A// Local Node Descriptor (var= iable) //
=0A+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
=0A
=0A
=0A
| Type =3D 265           =                  | Length |= =0A
=0A+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +
=0A| Prefix Length =3D 24 | IP Prefix (variable) //
=0A+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=0A
=0A
=0A

=0A
=0A
The format RFC4363 specified = is as follows.
=0A
+---------------------------------------------------------+=0A
= =0A| Address Family Identifier (2 octets) |
=0A+----------------------= -----------------------------------+
=0A| Subsequent Address Family Id= entifier (1 octet) |
=0A+---------------------------------------------= ------------+
=0A| Length of Next Hop Network Address (1 octet) |
= =0A+---------------------------------------------------------+
=0A| Ne= twork Address of Next Hop (variable) |
=0A+---------------------------= ------------------------------+
=0A| Reserved (1 octet) |
=0A+----= -----------------------------------------------------+
=0A| Pre= fix Length =3D 88 |  IP Prefix (variable) =3D RD followed by IP prefi= x // 
=0A+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-++
= =0A

=0A
=0A
=0A= =0A
=0A
 
=0A
=0A
=0A=0A
Date: 2014-09-02 16:35
=0A=0A=0A
Subject:&n= bsp;Re: RE: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-ietf-= idr-ls-distribut-impl
=0A
=0A
=0A
=0A
hi zhenqiang,=
=0A
 
=0A
On Tue, Sep 02, 2014 at 04:12:58PM +0800= , =0Alizhenqiang@chinamobil= e.com wrote:
=0A
|    Two types of link state = NLRIs are defined in section 3.2 of this
=0A
|    = draft, AFI 16388 / SAFI 71 for non-VPN, AFI 16388 / SAFI 128 for VPN.=0A
 
=0A
correct;
=0A
 
=0A
|&n= bsp;   My question is about AFI 16388 / SAFI 128 NLRI. From the = figure in page 9
=0A
|    of draft version 5, we c= an see that RD is put before link state NLRI.
=0A
 
=0A=
 
=0A=0A
 
= =0A
this is the NLRI format for AFI 16388 / SAFI 71 (unicast)
=0A=
 
=0A
    0     = ;            &= nbsp; 1           &= nbsp;       2     &= nbsp;           &nb= sp; 3
=0A
    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
=0A
   +-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=0A
   |&= nbsp;           NLRI Typ= e          |   = ;  Total NLRI Length         = |
=0A
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+
=0A
   |    &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;         |
=0A
 &nb= sp; //           &n= bsp;      Link-State NLRI (variable)  &= nbsp;           &nb= sp;  //
=0A
   |     &nbs= p;            =             &n= bsp;           &nbs= p;            =         |
=0A
   +-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=0A 
=0A
and this is the NLRI format for AFI 16388 / SAFI 128= (VPN-unicast)
=0A
 
=0A
    0 =             &n= bsp;     1       &n= bsp;           2 &n= bsp;           &nbs= p;     3
=0A
    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
=0A
 &nbs= p; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= =0A
   |        &nbs= p;   NLRI Type        &n= bsp; |     Total NLRI Length    &n= bsp;    |
=0A
   +-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=0A
   |&nbs= p;            =             &n= bsp;           &nbs= p;            =              |=
=0A
   +       &nbs= p;            =    Route Distinguisher       =             &n= bsp; +
=0A
   |      &nbs= p;            =             &n= bsp;           &nbs= p;            =        |
=0A
   +-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=0A
&nbs= p;  |          &nbs= p;            =             &n= bsp;           &nbs= p;            =    |
=0A
   //     &= nbsp;            Li= nk-State NLRI (variable)        &n= bsp;        //
=0A
  = ; |            = ;            &= nbsp;           &nb= sp;            = ;            &= nbsp; |
=0A
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+
=0A
 
=0A
 
=0A=
 
=0A
|    The link state NLRI field in = this figure contains the IP prefix. As RFC4364
=0A
|  &= nbsp; specifies, the VPN routes should be carried in the NLRI prepending w= ith
=0A
|    RD.
=0A
 
=0A
= that is what we do - i fail to see the offending part with respect to RFC4= 364.
=0A
 
=0A
/hannes
=0A
 
=0A=
|
=0A
|      From: [1]Hannes Gredl= er
=0A
|      Date: 2014-09-02 15:29=0A
|      To: [2]lizhenqiang@chinamobile.com; [3]Uma Chunduri=0A
|      CC: [4]'idr wg'; [5]'John G. Scu= dder'; [6]Susan Hares
=0A
|      Subject= : RE: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and
=0A
= |      draft-ietf-idr-ls-distribut-impl
=0A<= div>|
=0A
|      hi zhenqiang,
=0A=
|
=0A
|      The Route-distinguish= er's purpose is to add 64-bits of  disambiguating
=0A
| = ;     entropy to the NLRI, such
=0A
|
= =0A
|      that the route-reflectors do not "= swallow" that path as part of the
=0A
|    &n= bsp; best-path election
=0A
|
=0A
|   &n= bsp;  procedure. The link-state NLRI (encapsulated in MP_REACH/ MP UN= REACH PA)
=0A
|
=0A
|      is = a RD-less version of the vpn-link-state NLRI.
=0A
|
=0A|      In a certain way these correspond to RFC3= 107 / RFC4364 NLRI formats.
=0A
|
=0A
|  &nbs= p;   The former is a RD-less version of the latter.
=0A|
=0A
|      On your question "Why do'= t you put RD in IP Reachability Information,
=0A
|  &nb= sp;   just prepending RD with IP prefix as RFC4364 specifies." -= This is
=0A
|      actually what we *ar= e* doing - we put the RD before the link-state NLRI
=0A
| &n= bsp;    inside the MP_REACH/MP_UNREACH Attribute.
=0A<= div>|
=0A
|      HTH,
=0A
| =0A
|      /hannes
=0A
|
= =0A
|    ----------------------------------------------= ----------------------------
=0A
|
=0A=0A
|   &n= bsp;  Sent: Tuesday, September 02, 2014 8:44
=0A
| &nbs= p;    To: Hannes Gredler; Uma Chunduri
=0A
| =      Cc: 'idr wg'; 'John G. Scudder'; Susan Hares=0A
|      Subject: Re: Re: [Idr] WG LC for = draft-ietf-idr-ls-distribution and
=0A
|    &= nbsp; draft-ietf-idr-ls-distribut-impl
=0A
|
=0A
| = ;     One question about the VPN Link-State NLRI in se= ction 3.2. Why do you
=0A
|      put the= RD before link state NRLI? Why do't you put RD in IP
=0A
| =      Reachability Information, just preprending RD wit= h IP prefix as RFC4364
=0A
|      specif= ies.
=0A
|
=0A
|    --------------------= ------------------------------------------------------
=0A
| =0A=0A
|
=0A|
=0A
|        From: [7]Han= nes Gredler
=0A
|        Date:= 2014-09-02 02:05
=0A
|       = To: [8]Uma Chunduri
=0A
|      &nb= sp; CC: [9]idr@ietf.org; [10]'John G. = Scudder'; [11]Susan Hares
=0A
|     &nbs= p;  Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and=0A
|        draft-ietf-idr-ls-= distribut-impl
=0A
|        hi= uma,
=0A
|
=0A
|      &n= bsp; see comments/responses inline:
=0A
|
=0A
| &n= bsp;      On Wed, Aug 27, 2014 at 11:07:01AM +000= 0, Uma Chunduri wrote:
=0A
|      &= nbsp; |    Support.
=0A
|    &= nbsp;   |
=0A
|      &nbs= p; |    I see, hierarchy is WELL  defined when multipl= e instances of IGP
=0A
|       = ; with
=0A
|        | &nb= sp;  multiple AFs are running. Good work.
=0A
|  &= nbsp;     |
=0A
|    &nbs= p;   |
=0A
|        = |
=0A
|        |  &n= bsp; Have following Qs:
=0A
|      =   |
=0A
|        | &= nbsp;  1.       Any discussion of the d= elay introduced by BGP (packing,
=0A
|    &nb= sp;   update
=0A
|      &= nbsp; |    generation, processing etc..) to transport the L= S information
=0A
|        |=0A
|        |   = ; especially, when LSDB is changing faster perhaps with large
=0A|        number of
=0A
| = ;       |    nodes/links insi= de an AS and with multiple ASes) to the
=0A
|   &n= bsp;    controller will be
=0A
|   =      |    useful.
=0A
|
= =0A
|        this is highly impleme= ntation dependent; -
=0A
|      &nb= sp; some vendors do the packaging of BGP updates entirely event-driven=0A
|        and others pack thin= gs up and have a worst case delay between
=0A
|   =      the trigger event and the BGP update. the protoco= l
=0A
|        itself does not= prohibit/limit the propagation speed.
=0A
|   &nb= sp;    (in fact it can be shown that sometimes updates=0A
|        travel faster on the = (dataplane forwarded) iBGP mesh,
=0A
|    &nb= sp;   rather than propgate using the hop-by-hop control-plane fl= ooding
=0A
|        protocol)<= /div>=0A
|
=0A
|        |=             &n= bsp;    A note on the sensitivity of this delay to the=0A
|        consumer
=0A|        |    (applicat= ions) at the controller  can be helpful. I saw very
=0A
|&nb= sp;       little
=0A
|  &= nbsp;     |    discussion in Section 6 = (6.1.5)
=0A
|
=0A
|      =   difficiult - its hard to have some sort of general comment as thing= s
=0A
|        are
=0A|        highly implementation depend= ent.
=0A
|
=0A
|
=0A
|    = ;    |    2.     &n= bsp; This document encompasses pretty much both OSPF and ISIS
=0A|        |    extension= s done till date. How it will keep up with future
=0A
| &nbs= p;      extensions in
=0A
|  &= nbsp;     |    OSPF/ISIS.
=0A
= |
=0A
|        we have set up= an IANA registries for the carriers of information.
=0A
| &= nbsp;      it is expected by authors of "topologi= cal relevant" IGP extensions
=0A
|     &= nbsp;  to supply also BGP-LS extensions.
=0A
|
=0A|        |    A mechani= sm in place would be helpful. My suggestion would be-
=0A
| =        the
=0A
|   &= nbsp;    |    respective IGP documents shoul= d assess the impact and define
=0A
|     = ;   |
=0A
|        |=     corresponding new TLVs for BGP LS? But how this can be = enforced?
=0A
|
=0A
|     &nbs= p;  i have no idea - today its entirely voluntary.
=0A
| =0A
|        |   = 3.       Section 4, gives glimpse what's po= ssible and the node
=0A
|      &nbs= p; aggregating
=0A
|        |&= nbsp;   the links obviously need to tinker the LSDB to represent= the same
=0A
|        | =    correctly.
=0A
|      =   |
=0A
|        | &= nbsp;  Some more details would be helpful to represent the changes on=
=0A
|        |  &nb= sp; aggregation/de-aggregation subsequently.
=0A
|
=0A
= |        this may quickly get you into = the "abstracted topology models"
=0A
|    &nb= sp;   discussion that keeps emerging  periodically. -
= =0A
|        we did not want to sto= p progress on the protocol by arguing
=0A
|   &nbs= p;    "whats the right abstraction model" and have agreed=0A
|        on the minimalisti= c nature of the section as-is.
=0A
|
=0A
|
=0A|        |    4. =       Section 6.2 has empty sub-sections and TBDs= .
=0A
|
=0A
|       = right ... so suggest to remove section 6.2 altogether.
=0A
| =0A
|        |   = 5.       It's good to see Implementation re= port shed light on
=0A
|       = ; performance
=0A
|        |&n= bsp;   seen with multiple ASes.
=0A
|   =      |
=0A
|     &nb= sp;  |    6.       It's = good to see if any application of policy on LSDB is
=0A
| &n= bsp;      done
=0A
|   &n= bsp;    |    (one of the primary drivers of = the specification).
=0A
|
=0A
|
=0A
| &n= bsp;      thanks,
=0A
|
=0A
| =
=0A
|        /hannes
=0A=
|
=0A
|        |
= =0A
|        |    Fr= om: Idr [mailto:idr-bounces@ietf.o= rg] On Behalf Of Susan Hares
=0A
|    &nb= sp;   |    Sent: Tuesday, August 26, 2014 11:37 A= M
=0A
|        |  &n= bsp; To: idr@ietf.org
=0A
|&n= bsp;       |    Cc: 'John G. = Scudder'; shares@ndzh.com
=0A<= div>|        |    Subjec= t: [Idr] WG LC for draft-ietf-idr-ls-distribution and
=0A
| =        |    draft-ietf-idr-ls= -distribut-impl
=0A
|        |=
=0A
|        |
=0A
|=         |
=0A
|  &nb= sp;     |    This is a WG LC for
= =0A
|        |
=0A
| =        |
=0A
|   &nb= sp;    |
=0A
|      =   |
=0A=0A<= div>|        |
=0A
| &nbs= p;      |
=0A=0A
|     &nb= sp;  |
=0A
|        |=0A
|        |
=0A
|&nbs= p;       |    Please respond = with comments and "support or no support."  This
=0A
| =        WG LC also
=0A
|  =       |    includes a request for = the authors to provide IPR on the subject.
=0A
|   = ;     |
=0A
|     &n= bsp;  |
=0A
|        |=0A
|        |   = Please note: due to the European vacations in August, we are
=0A|        bundling
=0A
| =        |    these three revie= ws into the next two weeks (these two drafts and
=0A
|  = ;      |    draft-ietf-as-migratio= n).   The chairs would like feedback (list
=0A
| &= nbsp;      or
=0A
|   &nb= sp;    |    private email) whether the three= WG LC s impact anyone's ability
=0A
|    &nb= sp;   to review
=0A
|     &nbs= p;  |    these drafts carefully.
=0A
| &= nbsp;      |
=0A
|   &nbs= p;    |
=0A
|      &= nbsp; |
=0A
|        | &n= bsp;  Thank you,
=0A
|      &n= bsp; |
=0A
|        |
=0A=
|        |
=0A
| &nb= sp;      |    Sue Hares and John S= cudder
=0A
|        |
=0A=
|        | References
=0A|        |
=0A
|  &= nbsp;     |    Visible links
=0A|        |    1.=0A=0A
| &n= bsp;      |    2.
=0A=0A
|
=0A=
|        | _______________________= ________________________
=0A
|      = ;  | Idr mailing list
=0A
|     &nb= sp;  | Idr@ietf.org
=0A
= |        | https://www.ietf.org/mailman/listinfo/idr=0A
|
=0A
|        ___= ____________________________________________
=0A
|  &nb= sp;     Idr mailing list
=0A
|  &nb= sp;     Idr@ietf.org
=0A=0A
|
=0A
|
=0A
| References=0A
|
=0A
|    Visible links
=0A=0A=0A|    3. mail= to:uma.chunduri@ericsson.com
=0A=0A
| &nb= sp;  5. mailto:jgs@bgp.nu
=0A<= div>|    6. mailto:share= s@ndzh.com
=0A=0A=0A=0A=0A
|   11. <= a href=3D"mailto:shares@ndzh.com">mailto:shares@ndzh.com
=0A
=  
=0A
=0A=0A
=0A
=0A
=0A=
=0A=0A
=0A
=0A=0A
=0A ------=_001_NextPart460147110622_=------ From nobody Tue Sep 2 20:23:28 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6E211A6F7D for ; Tue, 2 Sep 2014 20:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.567 X-Spam-Level: X-Spam-Status: No, score=-14.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sAsBY8cNx6g8 for ; Tue, 2 Sep 2014 20:23:19 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 720911A0371 for ; Tue, 2 Sep 2014 20:23:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=67007; q=dns/txt; s=iport; t=1409714601; x=1410924201; h=from:to:cc:subject:date:message-id:mime-version; bh=2U8OWxzhJiYKXmSK2ma6QVTB4aCSFR20H2+bvhpQPCk=; b=eloh+AQ5uwPbM3JgFW0Ku9An2wJLGH+wR98uBOv9kXZQQqnE1J1g3P7h TV0R4I0PWp6lTP4+d44BcBK8ESyzYJLCGVv8U0Izk0KKSGLYMsufJsRc+ TafhHipUhNDJ3/QKpOlXeLV9la4x2NbjvKGSERSjxmmEzocaYEkGeU3C9 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQGAK2IBlStJA2L/2dsb2JhbABagkdGU1cEhBSvBZNcgV8BC4dKAYESFneEAwEBAQQBAQEXTQcLEgEIEQMBAQEhAQYuCxQJCgQBDQWIQg29JwEXjmsLBgE+AQcGBAaETQWBWIQ8iQmCFIQuhn2BW4pwiFOBZwgWFoFGbAGBBggXIoEHAQEB X-IronPort-AV: E=Sophos;i="5.04,454,1406592000"; d="scan'208,217";a="351920726" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-1.cisco.com with ESMTP; 03 Sep 2014 03:23:19 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s833NHmN001461 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 3 Sep 2014 03:23:17 GMT Received: from xmb-rcd-x13.cisco.com ([169.254.3.228]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Tue, 2 Sep 2014 22:23:17 -0500 From: "Saikat Ray (sairay)" To: "lizhenqiang@chinamobile.com" , "Hannes Gredler" Thread-Topic: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-ietf-idr-ls-distribut-impl Thread-Index: AQHPxyZnKyLgv7j6UUmOKYCHg5K+6g== Date: Wed, 3 Sep 2014 03:23:17 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [10.21.93.170] Content-Type: multipart/alternative; boundary="_000_D02BD7511FD54sairayciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/XpvjLnODNh6XIonw_w_gnZoMqpA Cc: 'idr wg' , "'John G. Scudder'" , Susan Hares Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-ietf-idr-ls-distribut-impl X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 03:23:23 -0000 --_000_D02BD7511FD54sairayciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Sorry, I do not understand your point. In BGP-LS as well, the RD field is r= ight after the route-type and the length: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NLRI Type | Total NLRI Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Route Distinguisher + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Link-State NLRI (variable) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ From: "lizhenqiang@chinamobile.com" > Date: Tuesday, September 2, 2014 at 7:39 PM To: sairay >, Hannes Gredler > Cc: "idr@ietf.org" >= , "shares@ndzh.com" >, 'John Scudder' > Subject: Re: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-i= etf-idr-ls-distribut-impl But the postion of RD in RFC6514 is AFTER type field and length field, not = before those fields. Taken Intra-AS I-PMSI A-D Route as an example, +-----------------------------------+ | Route Type (1 octet) =3D 1 | +-----------------------------------+ | Length (1 octet) | +-----------------------------------+ | RD (8 octets) | +-----------------------------------+ | Originating Router=92s IP Addr | +-----------------------------------+ ________________________________ lizhenqiang@chinamobile.com From: Saikat Ray (sairay) Date: 2014-09-03 10:24 To: lizhenqiang@chinamobile.com; Hannes= Gredler CC: 'idr wg'; Susan Hares; 'Jo= hn G. Scudder' Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-ietf-= idr-ls-distribut-impl From: "lizhenqiang@chinamobile.com" > Date: Tuesday, September 2, 2014 at 7:18 PM To: sairay >, Hannes Gredler > Cc: "idr@ietf.org" >= , "shares@ndzh.com" >, 'John Scudder' > Subject: Re: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-i= etf-idr-ls-distribut-impl Placing the type field before the length field is fine for me. The encoding format for RD in this draft is not consistent with RFC4364. Th= is is the question. RFC6514 says "The Route Distinguisher (RD) is encoded a= s described in [RFC4364]", please see section 4 of RFC6514. [SR] That statement in RFC6514 refers to how the 8 bytes of the route-disti= nguisher field are encoded (different RD types, values, etc.), not to the p= osition of RD field in the NLRI. I agree with you for the advantage to put the RD before other fields. I rai= se this quesiton just for clarification. ________________________________ lizhenqiang@chinamobile.com From: Saikat Ray (sairay) Date: 2014-09-03 05:03 To: lizhenqiang@chinamobile.com; Hannes= Gredler CC: 'idr wg'; Susan Hares; 'Jo= hn G. Scudder' Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-ietf-= idr-ls-distribut-impl Hi Zhenqiang: For the NLRIs that uses a "type" field, such as MVPN (see RFC6514), the con= vention is to encode the type field before the length field. This allows fo= r greatest flexibility for future extensions. In BGP-LS, we have used the s= ame convention. Other than that, the RD is for the entire bgp-ls object (be it a Node, Link= or Prefix). So placing the RD field before other fields is logically accur= ate. Thanks. From: "lizhenqiang@chinamobile.com" > Date: Tuesday, September 2, 2014 at 4:21 AM To: Hannes Gredler > Cc: "idr@ietf.org" >= , "shares@ndzh.com" >, 'John Scudder' > Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-ietf-= idr-ls-distribut-impl Hi Hannes, One example to explain the differences. One VPN route with prefix length 24= is carried in the NRLI. The format this draft specified is as follows. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NLRI Type =3D 3 | Total NLRI Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Route Distinguisher + | | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | | (64 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Local Node Descriptor (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 265 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length =3D 24 | IP Prefix (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The format RFC4363 specified is as follows. +---------------------------------------------------------+ | Address Family Identifier (2 octets) | +---------------------------------------------------------+ | Subsequent Address Family Identifier (1 octet) | +---------------------------------------------------------+ | Length of Next Hop Network Address (1 octet) | +---------------------------------------------------------+ | Network Address of Next Hop (variable) | +---------------------------------------------------------+ | Reserved (1 octet) | +---------------------------------------------------------+ | Prefix Length =3D 88 | IP Prefix (variable) =3D RD followed by IP prefix= // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ ________________________________ lizhenqiang@chinamobile.com From: Hannes Gredler Date: 2014-09-02 16:35 To: lizhenqiang@chinamobile.com CC: Uma Chunduri; 'idr wg'; 'John G. Scudder'; Susan Hares Subject: Re: RE: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-i= etf-idr-ls-distribut-impl hi zhenqiang, On Tue, Sep 02, 2014 at 04:12:58PM +0800, lizhenqiang@chinamobile.com wrote: | Two types of link state NLRIs are defined in section 3.2 of this | draft, AFI 16388 / SAFI 71 for non-VPN, AFI 16388 / SAFI 128 for VPN. correct; | My question is about AFI 16388 / SAFI 128 NLRI. From the figure in pag= e 9 | of draft version 5, we can see that RD is put before link state NLRI. from http://tools.ietf.org/html/draft-ietf-idr-ls-distribution-05#section-3= .2 this is the NLRI format for AFI 16388 / SAFI 71 (unicast) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NLRI Type | Total NLRI Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Link-State NLRI (variable) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ and this is the NLRI format for AFI 16388 / SAFI 128 (VPN-unicast) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NLRI Type | Total NLRI Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Route Distinguisher + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Link-State NLRI (variable) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | The link state NLRI field in this figure contains the IP prefix. As RF= C4364 | specifies, the VPN routes should be carried in the NLRI prepending wit= h | RD. that is what we do - i fail to see the offending part with respect to RFC43= 64. /hannes | | From: [1]Hannes Gredler | Date: 2014-09-02 15:29 | To: [2]lizhenqiang@chinamobile.com; [3]Uma Chunduri | CC: [4]'idr wg'; [5]'John G. Scudder'; [6]Susan Hares | Subject: RE: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and | draft-ietf-idr-ls-distribut-impl | | hi zhenqiang, | | The Route-distinguisher's purpose is to add 64-bits of disambiguati= ng | entropy to the NLRI, such | | that the route-reflectors do not "swallow" that path as part of the | best-path election | | procedure. The link-state NLRI (encapsulated in MP_REACH/ MP UNREACH= PA) | | is a RD-less version of the vpn-link-state NLRI. | | In a certain way these correspond to RFC3107 / RFC4364 NLRI formats. | | The former is a RD-less version of the latter. | | On your question "Why do't you put RD in IP Reachability Information= , | just prepending RD with IP prefix as RFC4364 specifies." - This is | actually what we *are* doing - we put the RD before the link-state N= LRI | inside the MP_REACH/MP_UNREACH Attribute. | | HTH, | | /hannes | | ----------------------------------------------------------------------= ---- | | From: lizhenqiang@chinamobile.com > | Sent: Tuesday, September 02, 2014 8:44 | To: Hannes Gredler; Uma Chunduri | Cc: 'idr wg'; 'John G. Scudder'; Susan Hares | Subject: Re: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and | draft-ietf-idr-ls-distribut-impl | | One question about the VPN Link-State NLRI in section 3.2. Why do yo= u | put the RD before link state NRLI? Why do't you put RD in IP | Reachability Information, just preprending RD with IP prefix as RFC4= 364 | specifies. | | ----------------------------------------------------------------------= ---- | | lizhenqiang@chinamobile.com | | | From: [7]Hannes Gredler | Date: 2014-09-02 02:05 | To: [8]Uma Chunduri | CC: [9]idr@ietf.org; [10]'John G. Scudder'; [= 11]Susan Hares | Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and | draft-ietf-idr-ls-distribut-impl | hi uma, | | see comments/responses inline: | | On Wed, Aug 27, 2014 at 11:07:01AM +0000, Uma Chunduri wrote: | | Support. | | | | I see, hierarchy is WELL defined when multiple instances of = IGP | with | | multiple AFs are running. Good work. | | | | | | | | Have following Qs: | | | | 1. Any discussion of the delay introduced by BGP (packi= ng, | update | | generation, processing etc..) to transport the LS information | | | | especially, when LSDB is changing faster perhaps with large | number of | | nodes/links inside an AS and with multiple ASes) to the | controller will be | | useful. | | this is highly implementation dependent; - | some vendors do the packaging of BGP updates entirely event-driven | and others pack things up and have a worst case delay between | the trigger event and the BGP update. the protocol | itself does not prohibit/limit the propagation speed. | (in fact it can be shown that sometimes updates | travel faster on the (dataplane forwarded) iBGP mesh, | rather than propgate using the hop-by-hop control-plane flooding | protocol) | | | A note on the sensitivity of this delay to the | consumer | | (applications) at the controller can be helpful. I saw very | little | | discussion in Section 6 (6.1.5) | | difficiult - its hard to have some sort of general comment as thin= gs | are | highly implementation dependent. | | | | 2. This document encompasses pretty much both OSPF and = ISIS | | extensions done till date. How it will keep up with future | extensions in | | OSPF/ISIS. | | we have set up an IANA registries for the carriers of information. | it is expected by authors of "topological relevant" IGP extensions | to supply also BGP-LS extensions. | | | A mechanism in place would be helpful. My suggestion would be= - | the | | respective IGP documents should assess the impact and define | | | | corresponding new TLVs for BGP LS? But how this can be enforc= ed? | | i have no idea - today its entirely voluntary. | | | 3. Section 4, gives glimpse what's possible and the nod= e | aggregating | | the links obviously need to tinker the LSDB to represent the = same | | correctly. | | | | Some more details would be helpful to represent the changes o= n | | aggregation/de-aggregation subsequently. | | this may quickly get you into the "abstracted topology models" | discussion that keeps emerging periodically. - | we did not want to stop progress on the protocol by arguing | "whats the right abstraction model" and have agreed | on the minimalistic nature of the section as-is. | | | | 4. Section 6.2 has empty sub-sections and TBDs. | | right ... so suggest to remove section 6.2 altogether. | | | 5. It's good to see Implementation report shed light on | performance | | seen with multiple ASes. | | | | 6. It's good to see if any application of policy on LSD= B is | done | | (one of the primary drivers of the specification). | | | thanks, | | | /hannes | | | | | From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Ha= res | | Sent: Tuesday, August 26, 2014 11:37 AM | | To: idr@ietf.org | | Cc: 'John G. Scudder'; shares@ndzh.com | | Subject: [Idr] WG LC for draft-ietf-idr-ls-distribution and | | draft-ietf-idr-ls-distribut-impl | | | | | | | | This is a WG LC for | | | | | | | | | [1]http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/ | | | | | [2]http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution-= impl/ | | | | | | | | Please respond with comments and "support or no support." Th= is | WG LC also | | includes a request for the authors to provide IPR on the subj= ect. | | | | | | | | Please note: due to the European vacations in August, we are | bundling | | these three reviews into the next two weeks (these two drafts= and | | draft-ietf-as-migration). The chairs would like feedback (l= ist | or | | private email) whether the three WG LC s impact anyone's abil= ity | to review | | these drafts carefully. | | | | | | | | Thank you, | | | | | | | | Sue Hares and John Scudder | | | | References | | | | Visible links | | 1. | http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/ | | 2. | http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution-imp= l/ | | | _______________________________________________ | | Idr mailing list | | Idr@ietf.org | | https://www.ietf.org/mailman/listinfo/idr | | _______________________________________________ | Idr mailing list | Idr@ietf.org | https://www.ietf.org/mailman/listinfo/idr | | | References | | Visible links | 1. mailto:hannes@juniper.net | 2. mailto:lizhenqiang@chinamobile.com | 3. mailto:uma.chunduri@ericsson.com | 4. mailto:idr@ietf.org | 5. mailto:jgs@bgp.nu | 6. mailto:shares@ndzh.com | 7. mailto:hannes@juniper.net | 8. mailto:uma.chunduri@ericsson.com | 9. mailto:idr@ietf.org | 10. mailto:jgs@bgp.nu | 11. mailto:shares@ndzh.com --_000_D02BD7511FD54sairayciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <2CB738F9A39B9846AE9417B169FA8927@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Sorry, I do not understand your point. In BGP-LS as well, the RD field= is right after the route-type and the length:

  +-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+
   |            NLRI Type &nbs= p;        |     Total NLRI Length   &nbs= p;     |
   +-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+
   |                =                     &nbs= p;                     &n= bsp;   |
   +               &n= bsp;       Route Distinguisher         &= nbsp;           +
   |                =                     &nbs= p;                     &n= bsp;   |
   +-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+
   |                =                     &nbs= p;                     &n= bsp;   |
   //                = ;  Link-State NLRI (variable)            = ;     //
   |                =                     &nbs= p;                     &n= bsp;   |
   +-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+

From: "lizhenqiang@chinamobile.com" <lizhenqiang@chinamobile.com>=
Date: Tuesday, September 2, 2014 at= 7:39 PM
To: sairay <sairay@cisco.com>, Hannes Gredler <hannes@juniper.net>
Cc: "idr@ietf.org" <idr@ietf.= org>, "shares@ndzh.com&q= uot; <shares@ndzh.com>, 'John Scudder' <jgs@bgp.nu>
Subject: Re: Re: [Idr] WG LC for dr= aft-ietf-idr-ls-distribution and draft-ietf-idr-ls-distribut-impl


But the postion of RD in RFC6514 is AFTER type field and length field,= not before those fields. Taken Intra-AS I-PMSI A-D Rout= e as an example,

+-----------------------------------+
| Route Type (1 octet) =3D 1  |
+-----------------------------------+
| Length (1 octet) |
+-----------------------------------+
| RD (8 octets) |
+-----------------------------------+
| Originating Router=92s IP Addr |
+-----------------------------------+

 
Date: 2014-09-03 10:24
Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-distributio= n and draft-ietf-idr-ls-distribut-impl

From: "lizhenqiang@chinamobile.com" <lizhenqiang@chinamobile.com>=
Date: Tuesday, September 2, 2014 at= 7:18 PM
To: sairay <sairay@cisco.com>, Hannes Gredler <hannes@juniper.net>
Cc: "idr@ietf.org" <idr@ietf.= org>, "shares@ndzh.com&q= uot; <shares@ndzh.com>, 'John Scudder' <jgs@bgp.nu>
Subject: Re: Re: [Idr] WG LC for dr= aft-ietf-idr-ls-distribution and draft-ietf-idr-ls-distribut-impl

Placing the type field before the length field is fine fo= r me.

The encoding format for RD in this draft is not consistent with RFC436= 4. This is the question. RFC6514 says "The Route Disting= uisher (RD) is encoded as described in [RFC4364]", please see section 4 of RFC6514.

[SR] That statement in RFC6514 refers to how the 8 bytes of the route-= distinguisher field are encoded (different RD types, values, etc.), not to = the position of RD field in the NLRI.

I agree with you for the advantage to put the RD before other fields. = I raise this quesiton just for clarification.

 
Date: 2014-09-03 05:03
Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-distributio= n and draft-ietf-idr-ls-distribut-impl
Hi Zhenqiang:=

For the NLRIs that uses a "type" field, such as MVPN (see RFC6514= ), the convention is to encode the type field before the length field. This= allows for greatest flexibility for future extensions. In BGP-LS, we have = used the same convention.

Other than that, the RD is for the entire bgp-ls object (be it a Node, Link= or Prefix). So placing the RD field before other fields is logically accur= ate.

Thanks.

From: "lizhenqiang@chinamobile.com" <lizhenqiang@chinamobile.com>=
Date: Tuesday, September 2, 2014 at= 4:21 AM
To: Hannes Gredler <hannes@juniper.net>
Cc: "idr@ietf.org" <idr@ietf.= org>, "shares@ndzh.com&q= uot; <shares@ndzh.com>, 'John Scudder' <jgs@bgp.nu>
Subject: Re: [Idr] WG LC for draft-= ietf-idr-ls-distribution and draft-ietf-idr-ls-distribut-impl

Hi Hannes,

One example to explain the differences. One VPN route with prefix leng= th 24 is carried in the NRLI.

The format this draft specified is as follows.
+-+-+-+-+-+-+-+-+-+-+-+= ;-+-+-+-+-+-+-+-+-+-+-+-+-&= #43;-+-+-+-+-+-+-+-+
 |          &nb= sp; NLRI Type =3D 3         |     T= otal NLRI Length         |
+-+-+-+-+-+-+-+-+-+-+-+= ;-+-+-+-+-+-+-+-+-+-+-+-+-&= #43;-+-+-+-+-+-+-+-+
 |          &nb= sp;            =             &nb= sp;            =             &nb= sp;  |
+           = ;            Route D= istinguisher          &nb= sp;          +
 |          &nb= sp;            =             &nb= sp;            =             &nb= sp;  |
+-+-+-= +-+-+-+-+-+ +-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+=
| Protocol-ID |
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
| Identifier |
| (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
// Local Node Descriptor (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
| Type =3D 265 &nb= sp;                     &= nbsp;    | Length |
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
| Prefix Length =3D 24 | IP Prefix (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+


The format RFC4363 specified is as follows.
+-------------= --------------------------------------------+
| Address Family Identifier (2 octets) |
+---------------------------------------------------------+
| Subsequent Address Family Identifier (1 octet) |
+---------------------------------------------------------+
| Length of Next Hop Network Address (1 octet) |
+---------------------------------------------------------+
| Network Address of Next Hop (variable) |
+---------------------------------------------------------+
| Reserved (1 octet) |
+---------------------------------------------------------+
| Prefix Length =3D 88 |  IP Prefix (variable) =3D RD followed = by IP prefix // 
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-++

 
Date: 2014-09-02 16:35
Subject: Re: RE: [Idr] WG LC for draft-ietf-idr-ls-distrib= ution and draft-ietf-idr-ls-distribut-impl
hi zhenqiang,
 
On Tue, Sep 02, 2014 at 04:12:58PM +0800, lizhenqiang@chinamobile.com wrote:
|    Two types of link state NLRIs are defined in secti= on 3.2 of this
|    draft, AFI 16388 / SAFI 71 for non-VPN, AFI 16388 = / SAFI 128 for VPN.
 
correct;
 
|    My question is about AFI 16388 / SAFI 128 NLRI. Fr= om the figure in page 9
|    of draft version 5, we can see that RD is put befo= re link state NLRI.
 
 
 
this is the NLRI format for AFI 16388 / SAFI 71 (unicast)
 
    0        &n= bsp;          1  &nb= sp;            =     2         &= nbsp;         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
   +-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+
   |         &n= bsp;  NLRI Type          = |     Total NLRI Length     &n= bsp;   |
   +-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+
   |         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;   |
   //         &= nbsp;        Link-State NLRI (variable)&= nbsp;           &nbs= p;    //
   |         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;   |
   +-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+
 
and this is the NLRI format for AFI 16388 / SAFI 128 (VPN-unicast)
 
    0        &n= bsp;          1  &nb= sp;            =     2         &= nbsp;         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
   +-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+
   |         &n= bsp;  NLRI Type          = |     Total NLRI Length     &n= bsp;   |
   +-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+
   |         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;   |
   +        &nbs= p;            &= nbsp; Route Distinguisher        &n= bsp;            += ;
   |         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;   |
   +-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+
   |         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;   |
   //         &= nbsp;        Link-State NLRI (variable)&= nbsp;           &nbs= p;    //
   |         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;   |
   +-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+
 
 
 
|    The link state NLRI field in this figure contains = the IP prefix. As RFC4364
|    specifies, the VPN routes should be carried in the= NLRI prepending with
|    RD.
 
that is what we do - i fail to see the offending part with respect to = RFC4364.
 
/hannes
 
|
|      From: [1]Hannes Gredler
|      Date: 2014-09-02 15:29
|      CC: [4]'idr wg'; [5]'John G. Scudder';= [6]Susan Hares
|      Subject: RE: Re: [Idr] WG LC for draft= -ietf-idr-ls-distribution and
|      draft-ietf-idr-ls-distribut-impl
|
|      hi zhenqiang,
|
|      The Route-distinguisher's purpose is t= o add 64-bits of  disambiguating
|      entropy to the NLRI, such
|
|      that the route-reflectors do not "= ;swallow" that path as part of the
|      best-path election
|
|      procedure. The link-state NLRI (encaps= ulated in MP_REACH/ MP UNREACH PA)
|
|      is a RD-less version of the vpn-link-s= tate NLRI.
|
|      In a certain way these correspond to R= FC3107 / RFC4364 NLRI formats.
|
|      The former is a RD-less version of the= latter.
|
|      On your question "Why do't you pu= t RD in IP Reachability Information,
|      just prepending RD with IP prefix as R= FC4364 specifies." - This is
|      actually what we *are* doing - we put = the RD before the link-state NLRI
|      inside the MP_REACH/MP_UNREACH Attribu= te.
|
|      HTH,
|
|      /hannes
|
|    --------------------------------------------------= ------------------------
|
|      Sent: Tuesday, September 02, 2014 8:44=
|      To: Hannes Gredler; Uma Chunduri
|      Cc: 'idr wg'; 'John G. Scudder'; Susan= Hares
|      Subject: Re: Re: [Idr] WG LC for draft= -ietf-idr-ls-distribution and
|      draft-ietf-idr-ls-distribut-impl
|
|      One question about the VPN Link-State = NLRI in section 3.2. Why do you
|      put the RD before link state NRLI? Why= do't you put RD in IP
|      Reachability Information, just prepren= ding RD with IP prefix as RFC4364
|      specifies.
|
|    --------------------------------------------------= ------------------------
|
|
|
|        From: [7]Hannes Gredler
|        Date: 2014-09-02 02:05
|        To: [8]Uma Chunduri
|        CC: [9]idr@ietf.org; [10]'John G. Scudder'; [11]Susan Hares
|        Subject: Re: [Idr] WG LC f= or draft-ietf-idr-ls-distribution and
|        draft-ietf-idr-ls-distribu= t-impl
|        hi uma,
|
|        see comments/responses inl= ine:
|
|        On Wed, Aug 27, 2014 at 11= :07:01AM +0000, Uma Chunduri wrote:
|        |    Suppor= t.
|        |
|        |    I see,= hierarchy is WELL  defined when multiple instances of IGP
|        with
|        |    multip= le AFs are running. Good work.
|        |
|        |
|        |
|        |    Have f= ollowing Qs:
|        |
|        |    1.&nbs= p;      Any discussion of the delay introduced by = BGP (packing,
|        update
|        |    genera= tion, processing etc..) to transport the LS information
|        |
|        |    especi= ally, when LSDB is changing faster perhaps with large
|        number of
|        |    nodes/= links inside an AS and with multiple ASes) to the
|        controller will be
|        |    useful= .
|
|        this is highly implementat= ion dependent; -
|        some vendors do the packag= ing of BGP updates entirely event-driven
|        and others pack things up = and have a worst case delay between
|        the trigger event and the = BGP update. the protocol
|        itself does not prohibit/l= imit the propagation speed.
|        (in fact it can be shown t= hat sometimes updates
|        travel faster on the (data= plane forwarded) iBGP mesh,
|        rather than propgate using= the hop-by-hop control-plane flooding
|        protocol)
|
|        |    &= nbsp;            A n= ote on the sensitivity of this delay to the
|        consumer
|        |    (appli= cations) at the controller  can be helpful. I saw very
|        little
|        |    discus= sion in Section 6 (6.1.5)
|
|        difficiult - its hard to h= ave some sort of general comment as things
|        are
|        highly implementation depe= ndent.
|
|
|        |    2.&nbs= p;      This document encompasses pretty much both= OSPF and ISIS
|        |    extens= ions done till date. How it will keep up with future
|        extensions in
|        |    OSPF/I= SIS.
|
|        we have set up an IANA reg= istries for the carriers of information.
|        it is expected by authors = of "topological relevant" IGP extensions
|        to supply also BGP-LS exte= nsions.
|
|        |    A mech= anism in place would be helpful. My suggestion would be-
|        the
|        |    respec= tive IGP documents should assess the impact and define
|        |
|        |    corres= ponding new TLVs for BGP LS? But how this can be enforced?
|
|        i have no idea - today its= entirely voluntary.
|
|        |    3.&nbs= p;      Section 4, gives glimpse what's possible a= nd the node
|        aggregating
|        |    the li= nks obviously need to tinker the LSDB to represent the same
|        |    correc= tly.
|        |
|        |    Some m= ore details would be helpful to represent the changes on
|        |    aggreg= ation/de-aggregation subsequently.
|
|        this may quickly get you i= nto the "abstracted topology models"
|        discussion that keeps emer= ging  periodically. -
|        we did not want to stop pr= ogress on the protocol by arguing
|        "whats the right abst= raction model" and have agreed
|        on the minimalistic nature= of the section as-is.
|
|
|        |    4.&nbs= p;      Section 6.2 has empty sub-sections and TBD= s.
|
|        right ... so suggest to re= move section 6.2 altogether.
|
|        |    5.&nbs= p;      It's good to see Implementation report she= d light on
|        performance
|        |    seen w= ith multiple ASes.
|        |
|        |    6.&nbs= p;      It's good to see if any application of pol= icy on LSDB is
|        done
|        |    (one o= f the primary drivers of the specification).
|
|
|        thanks,
|
|
|        /hannes
|
|        |
|        |    From: = Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
|        |    Sent: = Tuesday, August 26, 2014 11:37 AM
|        |    Cc: 'J= ohn G. Scudder'; shares@ndzh.com
|        |    Subjec= t: [Idr] WG LC for draft-ietf-idr-ls-distribution and
|        |    draft-= ietf-idr-ls-distribut-impl
|        |
|        |
|        |
|        |    This i= s a WG LC for
|        |
|        |
|        |
|        |
|        |
|        |
|        |
|        |
|        |
|        |    Please= respond with comments and "support or no support."  This
|        WG LC also
|        |    includ= es a request for the authors to provide IPR on the subject.
|        |
|        |
|        |
|        |    Please= note: due to the European vacations in August, we are
|        bundling
|        |    these = three reviews into the next two weeks (these two drafts and
|        |    draft-= ietf-as-migration).   The chairs would like feedback (list
|        or
|        |    privat= e email) whether the three WG LC s impact anyone's ability
|        to review
|        |    these = drafts carefully.
|        |
|        |
|        |
|        |    Thank = you,
|        |
|        |
|        |
|        |    Sue Ha= res and John Scudder
|        |
|        | References
|        |
|        |    Visibl= e links
|        |    1.
|        |    2.
|        http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution-impl/
|
|        | ________________________= _______________________
|        | Idr mailing list
|        | Idr@ietf.org
|
|        __________________________= _____________________
|        Idr mailing list
|        Idr@ietf.org
 --_000_D02BD7511FD54sairayciscocom_-- From nobody Tue Sep 2 20:41:28 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E8271A89B3 for ; Tue, 2 Sep 2014 20:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.255 X-Spam-Level: X-Spam-Status: No, score=0.255 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0c_kq7cYXKfI for ; Tue, 2 Sep 2014 20:41:21 -0700 (PDT) Received: from cmccmta2.chinamobile.com (cmccmta2.chinamobile.com [221.176.66.80]) by ietfa.amsl.com (Postfix) with SMTP id BB15F1A89B0 for ; Tue, 2 Sep 2014 20:41:19 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.121.1]) by rmmx-syy-dmz-app06-12006 (RichMail) with SMTP id 2ee654068ddeea0-72002; Wed, 03 Sep 2014 11:41:18 +0800 (CST) X-RM-TRANSID: 2ee654068ddeea0-72002 X-RM-SPAM-FLAG: 00000000 Received: from lizhenqiang (unknown[10.2.52.185]) by rmsmtp-syy-appsvr01-12001 (RichMail) with SMTP id 2ee154068ddcdbe-bdf81; Wed, 03 Sep 2014 11:41:18 +0800 (CST) X-RM-TRANSID: 2ee154068ddcdbe-bdf81 Date: Wed, 3 Sep 2014 11:41:38 +0800 From: "lizhenqiang@chinamobile.com" To: "Saikat Ray (sairay)" , "Hannes Gredler" References: X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 5, 140[cn] Mime-Version: 1.0 Message-ID: <2014090311413770655136@chinamobile.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart143176840625_=----" Archived-At: http://mailarchive.ietf.org/arch/msg/idr/Z3UbnNWvzsdbehpDwS4v_xm19L4 Cc: 'idr wg' , "'John G. Scudder'" , Susan Hares Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-ietf-idr-ls-distribut-impl X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 03:41:26 -0000 This is a multi-part message in MIME format. ------=_001_NextPart143176840625_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UkQgc2hvdWxkIGJlIGZvbGxvd2VkIGJ5IHRoZSBJUCBwcmVmaXggYXMgc3BlY2lmaWVkIGluIFJG QzQzNjQuDQoNCkhlcmUgaW4gdGhpcyBkcmFmdCwgUkQgaXMgZm9sbHdlZCBieSB0aGUgbGluayBz dGF0ZSBOTFJJLiBMaW5rIHN0YXRlIE5MUkkgaGFzIGl0cyBvd24gZm9ybWF0LiBTZWUgdGhlIGZv bGxvd2luZyBleGFtcGxlLCB0aGUgMjQtYml0LWxvbmcgSVAgcHJlZml4IGlzIGZhciBhd2F5IGZy b20gUkQuDQoNCistKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rDQogfCAgICAgICAgICAgIE5MUkkgVHlwZSA9IDMgICAgICAgICB8 ICAgICBUb3RhbCBOTFJJIExlbmd0aCAgICAgICAgIHwNCistKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogfCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCisg ICAgICAgICAgICAgICAgICAgICAgIFJvdXRlIERpc3Rpbmd1aXNoZXIgICAgICAgICAgICAgICAg ICAgICArDQogfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwNCistKy0rLSstKy0rLSstKy0rICstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rDQp8IFByb3RvY29sLUlEIHwgDQorLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyANCnwgSWRl bnRpZmllciB8IA0KfCAoNjQgYml0cykgfCANCistKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rIA0KLy8gTG9jYWwgTm9kZSBEZXNj cmlwdG9yICh2YXJpYWJsZSkgLy8gDQorLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyANCnwgVHlwZSA9IDI2NSAgICAgICAgICAg ICAgICAgICAgICAgICAgICB8IExlbmd0aCB8IA0KKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgDQp8IFByZWZpeCBMZW5ndGgg PSAyNCB8IElQIFByZWZpeCAodmFyaWFibGUpIC8vIA0KKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCg0KDQpUaGUgZm9sbG93 aW5nIGZvcm1hdCBmb3IgdGhlIGFib3ZlIGV4YW1wbGUgaXMgY29uc2lzdGVudCB3aXRoIFJGQzQz NjQgaW4gbXkgb3Bpbmlvbi4NCistKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogfCAgICAgICAgICAgIE5MUkkgVHlwZSA9IDMg ICAgICAgICB8ICAgICBUb3RhbCBOTFJJIExlbmd0aCAgICAgICAgIHwNCistKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQp8IFBy b3RvY29sLUlEIHwgDQorLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKyANCnwgSWRlbnRpZmllciB8IA0KfCAoNjQgYml0cykgfCAN CistKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rIA0KLy8gTG9jYWwgTm9kZSBEZXNjcmlwdG9yICh2YXJpYWJsZSkgLy8gDQorLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKyANCnwgVHlwZSA9IDI2NSAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IExlbmd0aCB8 IA0KKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSsgDQp8IFByZWZpeCBMZW5ndGggPSA4OCB8IElQIFByZWZpeCAodmFyaWFibGUp ID0gUkQgZm9sbG93ZWQgYnkgdGhlIDI0LWJpdC1sb25nIHByZWZpeCAvLyANCistKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQoN Cg0KDQpsaXpoZW5xaWFuZ0BjaGluYW1vYmlsZS5jb20NCiANCkZyb206IFNhaWthdCBSYXkgKHNh aXJheSkNCkRhdGU6IDIwMTQtMDktMDMgMTE6MjMNClRvOiBsaXpoZW5xaWFuZ0BjaGluYW1vYmls ZS5jb207IEhhbm5lcyBHcmVkbGVyDQpDQzogJ2lkciB3Zyc7IFN1c2FuIEhhcmVzOyAnSm9obiBH LiBTY3VkZGVyJw0KU3ViamVjdDogUmU6IFtJZHJdIFdHIExDIGZvciBkcmFmdC1pZXRmLWlkci1s cy1kaXN0cmlidXRpb24gYW5kIGRyYWZ0LWlldGYtaWRyLWxzLWRpc3RyaWJ1dC1pbXBsDQpTb3Jy eSwgSSBkbyBub3QgdW5kZXJzdGFuZCB5b3VyIHBvaW50LiBJbiBCR1AtTFMgYXMgd2VsbCwgdGhl IFJEIGZpZWxkIGlzIHJpZ2h0IGFmdGVyIHRoZSByb3V0ZS10eXBlIGFuZCB0aGUgbGVuZ3RoOg0K DQogICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rDQogICB8ICAgICAgICAgICAgTkxSSSBUeXBlICAgICAgICAgIHwgICAgIFRv dGFsIE5MUkkgTGVuZ3RoICAgICAgICAgfA0KICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgIHwgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAr ICAgICAgICAgICAgICAgICAgICAgICBSb3V0ZSBEaXN0aW5ndWlzaGVyICAgICAgICAgICAgICAg ICAgICAgKw0KICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHwNCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICB8ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgLy8gICAg ICAgICAgICAgICAgICBMaW5rLVN0YXRlIE5MUkkgKHZhcmlhYmxlKSAgICAgICAgICAgICAgICAg Ly8NCiAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB8DQogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KDQpGcm9tOiAibGl6aGVucWlhbmdAY2hpbmFt b2JpbGUuY29tIiA8bGl6aGVucWlhbmdAY2hpbmFtb2JpbGUuY29tPg0KRGF0ZTogVHVlc2RheSwg U2VwdGVtYmVyIDIsIDIwMTQgYXQgNzozOSBQTQ0KVG86IHNhaXJheSA8c2FpcmF5QGNpc2NvLmNv bT4sIEhhbm5lcyBHcmVkbGVyIDxoYW5uZXNAanVuaXBlci5uZXQ+DQpDYzogImlkckBpZXRmLm9y ZyIgPGlkckBpZXRmLm9yZz4sICJzaGFyZXNAbmR6aC5jb20iIDxzaGFyZXNAbmR6aC5jb20+LCAn Sm9obiBTY3VkZGVyJyA8amdzQGJncC5udT4NClN1YmplY3Q6IFJlOiBSZTogW0lkcl0gV0cgTEMg Zm9yIGRyYWZ0LWlldGYtaWRyLWxzLWRpc3RyaWJ1dGlvbiBhbmQgZHJhZnQtaWV0Zi1pZHItbHMt ZGlzdHJpYnV0LWltcGwNCg0KDQpCdXQgdGhlIHBvc3Rpb24gb2YgUkQgaW4gUkZDNjUxNCBpcyBB RlRFUiB0eXBlIGZpZWxkIGFuZCBsZW5ndGggZmllbGQsIG5vdCBiZWZvcmUgdGhvc2UgZmllbGRz LiBUYWtlbiBJbnRyYS1BUyBJLVBNU0kgQS1EIFJvdXRlIGFzIGFuIGV4YW1wbGUsDQoNCistLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsgDQp8IFJvdXRlIFR5cGUgKDEgb2N0ZXQp ID0gMSAgfCANCistLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsgDQp8IExlbmd0 aCAoMSBvY3RldCkgfCANCistLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsgDQp8 IFJEICg4IG9jdGV0cykgfCANCistLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsg DQp8IE9yaWdpbmF0aW5nIFJvdXRlcuKAmXMgSVAgQWRkciB8IA0KKy0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tKw0KDQoNCg0KbGl6aGVucWlhbmdAY2hpbmFtb2JpbGUuY29tDQog DQpGcm9tOiBTYWlrYXQgUmF5IChzYWlyYXkpDQpEYXRlOiAyMDE0LTA5LTAzIDEwOjI0DQpUbzog bGl6aGVucWlhbmdAY2hpbmFtb2JpbGUuY29tOyBIYW5uZXMgR3JlZGxlcg0KQ0M6ICdpZHIgd2cn OyBTdXNhbiBIYXJlczsgJ0pvaG4gRy4gU2N1ZGRlcicNClN1YmplY3Q6IFJlOiBbSWRyXSBXRyBM QyBmb3IgZHJhZnQtaWV0Zi1pZHItbHMtZGlzdHJpYnV0aW9uIGFuZCBkcmFmdC1pZXRmLWlkci1s cy1kaXN0cmlidXQtaW1wbA0KDQpGcm9tOiAibGl6aGVucWlhbmdAY2hpbmFtb2JpbGUuY29tIiA8 bGl6aGVucWlhbmdAY2hpbmFtb2JpbGUuY29tPg0KRGF0ZTogVHVlc2RheSwgU2VwdGVtYmVyIDIs IDIwMTQgYXQgNzoxOCBQTQ0KVG86IHNhaXJheSA8c2FpcmF5QGNpc2NvLmNvbT4sIEhhbm5lcyBH cmVkbGVyIDxoYW5uZXNAanVuaXBlci5uZXQ+DQpDYzogImlkckBpZXRmLm9yZyIgPGlkckBpZXRm Lm9yZz4sICJzaGFyZXNAbmR6aC5jb20iIDxzaGFyZXNAbmR6aC5jb20+LCAnSm9obiBTY3VkZGVy JyA8amdzQGJncC5udT4NClN1YmplY3Q6IFJlOiBSZTogW0lkcl0gV0cgTEMgZm9yIGRyYWZ0LWll dGYtaWRyLWxzLWRpc3RyaWJ1dGlvbiBhbmQgZHJhZnQtaWV0Zi1pZHItbHMtZGlzdHJpYnV0LWlt cGwNCg0KUGxhY2luZyB0aGUgdHlwZSBmaWVsZCBiZWZvcmUgdGhlIGxlbmd0aCBmaWVsZCBpcyBm aW5lIGZvciBtZS4NCg0KVGhlIGVuY29kaW5nIGZvcm1hdCBmb3IgUkQgaW4gdGhpcyBkcmFmdCBp cyBub3QgY29uc2lzdGVudCB3aXRoIFJGQzQzNjQuIFRoaXMgaXMgdGhlIHF1ZXN0aW9uLiBSRkM2 NTE0IHNheXMgIlRoZSBSb3V0ZSBEaXN0aW5ndWlzaGVyIChSRCkgaXMgZW5jb2RlZCBhcyBkZXNj cmliZWQgaW4gW1JGQzQzNjRdIiwgcGxlYXNlIHNlZSBzZWN0aW9uIDQgb2YgUkZDNjUxNC4NCg0K W1NSXSBUaGF0IHN0YXRlbWVudCBpbiBSRkM2NTE0IHJlZmVycyB0byBob3cgdGhlIDggYnl0ZXMg b2YgdGhlIHJvdXRlLWRpc3Rpbmd1aXNoZXIgZmllbGQgYXJlIGVuY29kZWQgKGRpZmZlcmVudCBS RCB0eXBlcywgdmFsdWVzLCBldGMuKSwgbm90IHRvIHRoZSBwb3NpdGlvbiBvZiBSRCBmaWVsZCBp biB0aGUgTkxSSS4NCg0KSSBhZ3JlZSB3aXRoIHlvdSBmb3IgdGhlIGFkdmFudGFnZSB0byBwdXQg dGhlIFJEIGJlZm9yZSBvdGhlciBmaWVsZHMuIEkgcmFpc2UgdGhpcyBxdWVzaXRvbiBqdXN0IGZv ciBjbGFyaWZpY2F0aW9uLg0KDQoNCg0KbGl6aGVucWlhbmdAY2hpbmFtb2JpbGUuY29tDQogDQpG cm9tOiBTYWlrYXQgUmF5IChzYWlyYXkpDQpEYXRlOiAyMDE0LTA5LTAzIDA1OjAzDQpUbzogbGl6 aGVucWlhbmdAY2hpbmFtb2JpbGUuY29tOyBIYW5uZXMgR3JlZGxlcg0KQ0M6ICdpZHIgd2cnOyBT dXNhbiBIYXJlczsgJ0pvaG4gRy4gU2N1ZGRlcicNClN1YmplY3Q6IFJlOiBbSWRyXSBXRyBMQyBm b3IgZHJhZnQtaWV0Zi1pZHItbHMtZGlzdHJpYnV0aW9uIGFuZCBkcmFmdC1pZXRmLWlkci1scy1k aXN0cmlidXQtaW1wbA0KSGkgWmhlbnFpYW5nOg0KDQpGb3IgdGhlIE5MUklzIHRoYXQgdXNlcyBh ICJ0eXBlIiBmaWVsZCwgc3VjaCBhcyBNVlBOIChzZWUgUkZDNjUxNCksIHRoZSBjb252ZW50aW9u IGlzIHRvIGVuY29kZSB0aGUgdHlwZSBmaWVsZCBiZWZvcmUgdGhlIGxlbmd0aCBmaWVsZC4gVGhp cyBhbGxvd3MgZm9yIGdyZWF0ZXN0IGZsZXhpYmlsaXR5IGZvciBmdXR1cmUgZXh0ZW5zaW9ucy4g SW4gQkdQLUxTLCB3ZSBoYXZlIHVzZWQgdGhlIHNhbWUgY29udmVudGlvbi4NCg0KT3RoZXIgdGhh biB0aGF0LCB0aGUgUkQgaXMgZm9yIHRoZSBlbnRpcmUgYmdwLWxzIG9iamVjdCAoYmUgaXQgYSBO b2RlLCBMaW5rIG9yIFByZWZpeCkuIFNvIHBsYWNpbmcgdGhlIFJEIGZpZWxkIGJlZm9yZSBvdGhl ciBmaWVsZHMgaXMgbG9naWNhbGx5IGFjY3VyYXRlLg0KDQpUaGFua3MuDQoNCkZyb206ICJsaXpo ZW5xaWFuZ0BjaGluYW1vYmlsZS5jb20iIDxsaXpoZW5xaWFuZ0BjaGluYW1vYmlsZS5jb20+DQpE YXRlOiBUdWVzZGF5LCBTZXB0ZW1iZXIgMiwgMjAxNCBhdCA0OjIxIEFNDQpUbzogSGFubmVzIEdy ZWRsZXIgPGhhbm5lc0BqdW5pcGVyLm5ldD4NCkNjOiAiaWRyQGlldGYub3JnIiA8aWRyQGlldGYu b3JnPiwgInNoYXJlc0BuZHpoLmNvbSIgPHNoYXJlc0BuZHpoLmNvbT4sICdKb2huIFNjdWRkZXIn IDxqZ3NAYmdwLm51Pg0KU3ViamVjdDogUmU6IFtJZHJdIFdHIExDIGZvciBkcmFmdC1pZXRmLWlk ci1scy1kaXN0cmlidXRpb24gYW5kIGRyYWZ0LWlldGYtaWRyLWxzLWRpc3RyaWJ1dC1pbXBsDQoN CkhpIEhhbm5lcywNCg0KT25lIGV4YW1wbGUgdG8gZXhwbGFpbiB0aGUgZGlmZmVyZW5jZXMuIE9u ZSBWUE4gcm91dGUgd2l0aCBwcmVmaXggbGVuZ3RoIDI0IGlzIGNhcnJpZWQgaW4gdGhlIE5STEku DQoNClRoZSBmb3JtYXQgdGhpcyBkcmFmdCBzcGVjaWZpZWQgaXMgYXMgZm9sbG93cy4NCistKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rDQogfCAgICAgICAgICAgIE5MUkkgVHlwZSA9IDMgICAgICAgICB8ICAgICBUb3RhbCBOTFJJ IExlbmd0aCAgICAgICAgIHwNCistKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogfCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCisgICAgICAgICAgICAgICAg ICAgICAgIFJvdXRlIERpc3Rpbmd1aXNoZXIgICAgICAgICAgICAgICAgICAgICArDQogfCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwNCistKy0rLSstKy0rLSstKy0rICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rDQp8IFByb3RvY29sLUlEIHwgDQorLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyANCnwgSWRlbnRpZmllciB8IA0KfCAo NjQgYml0cykgfCANCistKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rIA0KLy8gTG9jYWwgTm9kZSBEZXNjcmlwdG9yICh2YXJpYWJs ZSkgLy8gDQorLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKyANCnwgVHlwZSA9IDI2NSAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8IExlbmd0aCB8IA0KKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSsgDQp8IFByZWZpeCBMZW5ndGggPSAyNCB8IElQIFByZWZp eCAodmFyaWFibGUpIC8vIA0KKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCg0KDQpUaGUgZm9ybWF0IFJGQzQzNjMgc3BlY2lm aWVkIGlzIGFzIGZvbGxvd3MuDQorLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tKyANCnwgQWRkcmVzcyBGYW1pbHkgSWRlbnRpZmllciAoMiBv Y3RldHMpIHwgDQorLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tKyANCnwgU3Vic2VxdWVudCBBZGRyZXNzIEZhbWlseSBJZGVudGlmaWVyICgx IG9jdGV0KSB8IA0KKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLSsgDQp8IExlbmd0aCBvZiBOZXh0IEhvcCBOZXR3b3JrIEFkZHJlc3MgKDEg b2N0ZXQpIHwgDQorLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tKyANCnwgTmV0d29yayBBZGRyZXNzIG9mIE5leHQgSG9wICh2YXJpYWJsZSkg fCANCistLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0rIA0KfCBSZXNlcnZlZCAoMSBvY3RldCkgfCANCistLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rIA0KfCBQcmVmaXggTGVuZ3RoID0g ODggfCAgSVAgUHJlZml4ICh2YXJpYWJsZSkgPSBSRCBmb2xsb3dlZCBieSBJUCBwcmVmaXggLy8g DQorLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKysNCg0KDQoNCmxpemhlbnFpYW5nQGNoaW5hbW9iaWxlLmNvbQ0KIA0KRnJvbTog SGFubmVzIEdyZWRsZXINCkRhdGU6IDIwMTQtMDktMDIgMTY6MzUNClRvOiBsaXpoZW5xaWFuZ0Bj aGluYW1vYmlsZS5jb20NCkNDOiBVbWEgQ2h1bmR1cmk7ICdpZHIgd2cnOyAnSm9obiBHLiBTY3Vk ZGVyJzsgU3VzYW4gSGFyZXMNClN1YmplY3Q6IFJlOiBSRTogW0lkcl0gV0cgTEMgZm9yIGRyYWZ0 LWlldGYtaWRyLWxzLWRpc3RyaWJ1dGlvbiBhbmQgZHJhZnQtaWV0Zi1pZHItbHMtZGlzdHJpYnV0 LWltcGwNCmhpIHpoZW5xaWFuZywNCiANCk9uIFR1ZSwgU2VwIDAyLCAyMDE0IGF0IDA0OjEyOjU4 UE0gKzA4MDAsIGxpemhlbnFpYW5nQGNoaW5hbW9iaWxlLmNvbSB3cm90ZToNCnwgICAgVHdvIHR5 cGVzIG9mIGxpbmsgc3RhdGUgTkxSSXMgYXJlIGRlZmluZWQgaW4gc2VjdGlvbiAzLjIgb2YgdGhp cw0KfCAgICBkcmFmdCwgQUZJIDE2Mzg4IC8gU0FGSSA3MSBmb3Igbm9uLVZQTiwgQUZJIDE2Mzg4 IC8gU0FGSSAxMjggZm9yIFZQTi4NCiANCmNvcnJlY3Q7DQogDQp8ICAgIE15IHF1ZXN0aW9uIGlz IGFib3V0IEFGSSAxNjM4OCAvIFNBRkkgMTI4IE5MUkkuIEZyb20gdGhlIGZpZ3VyZSBpbiBwYWdl IDkNCnwgICAgb2YgZHJhZnQgdmVyc2lvbiA1LCB3ZSBjYW4gc2VlIHRoYXQgUkQgaXMgcHV0IGJl Zm9yZSBsaW5rIHN0YXRlIE5MUkkuDQogDQogDQpmcm9tIGh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtaWRyLWxzLWRpc3RyaWJ1dGlvbi0wNSNzZWN0aW9uLTMuMg0KIA0KdGhp cyBpcyB0aGUgTkxSSSBmb3JtYXQgZm9yIEFGSSAxNjM4OCAvIFNBRkkgNzEgKHVuaWNhc3QpDQog DQogICAgMCAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAg ICAgICAgICAgMw0KICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAw IDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0KICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgIHwgICAgICAgICAgICBOTFJJ IFR5cGUgICAgICAgICAgfCAgICAgVG90YWwgTkxSSSBMZW5ndGggICAgICAgICB8DQogICArLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKw0KICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwNCiAgIC8vICAgICAgICAgICAgICAgICAgTGluay1TdGF0ZSBOTFJJ ICh2YXJpYWJsZSkgICAgICAgICAgICAgICAgIC8vDQogICB8ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsN CiANCmFuZCB0aGlzIGlzIHRoZSBOTFJJIGZvcm1hdCBmb3IgQUZJIDE2Mzg4IC8gU0FGSSAxMjgg KFZQTi11bmljYXN0KQ0KIA0KICAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAg ICAgICAyICAgICAgICAgICAgICAgICAgIDMNCiAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAy IDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDENCiAgICstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICB8 ICAgICAgICAgICAgTkxSSSBUeXBlICAgICAgICAgIHwgICAgIFRvdGFsIE5MUkkgTGVuZ3RoICAg ICAgICAgfA0KICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSsNCiAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICArICAgICAgICAgICAgICAgICAg ICAgICBSb3V0ZSBEaXN0aW5ndWlzaGVyICAgICAgICAgICAgICAgICAgICAgKw0KICAgfCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwNCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rDQogICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgLy8gICAgICAgICAgICAgICAgICBMaW5r LVN0YXRlIE5MUkkgKHZhcmlhYmxlKSAgICAgICAgICAgICAgICAgLy8NCiAgIHwgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQog ICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKw0KIA0KIA0KIA0KfCAgICBUaGUgbGluayBzdGF0ZSBOTFJJIGZpZWxkIGluIHRo aXMgZmlndXJlIGNvbnRhaW5zIHRoZSBJUCBwcmVmaXguIEFzIFJGQzQzNjQNCnwgICAgc3BlY2lm aWVzLCB0aGUgVlBOIHJvdXRlcyBzaG91bGQgYmUgY2FycmllZCBpbiB0aGUgTkxSSSBwcmVwZW5k aW5nIHdpdGgNCnwgICAgUkQuDQogDQp0aGF0IGlzIHdoYXQgd2UgZG8gLSBpIGZhaWwgdG8gc2Vl IHRoZSBvZmZlbmRpbmcgcGFydCB3aXRoIHJlc3BlY3QgdG8gUkZDNDM2NC4NCiANCi9oYW5uZXMN CiANCnwgDQp8ICAgICAgRnJvbTogWzFdSGFubmVzIEdyZWRsZXINCnwgICAgICBEYXRlOiAyMDE0 LTA5LTAyIDE1OjI5DQp8ICAgICAgVG86IFsyXWxpemhlbnFpYW5nQGNoaW5hbW9iaWxlLmNvbTsg WzNdVW1hIENodW5kdXJpDQp8ICAgICAgQ0M6IFs0XSdpZHIgd2cnOyBbNV0nSm9obiBHLiBTY3Vk ZGVyJzsgWzZdU3VzYW4gSGFyZXMNCnwgICAgICBTdWJqZWN0OiBSRTogUmU6IFtJZHJdIFdHIExD IGZvciBkcmFmdC1pZXRmLWlkci1scy1kaXN0cmlidXRpb24gYW5kDQp8ICAgICAgZHJhZnQtaWV0 Zi1pZHItbHMtZGlzdHJpYnV0LWltcGwNCnwgDQp8ICAgICAgaGkgemhlbnFpYW5nLA0KfCANCnwg ICAgICBUaGUgUm91dGUtZGlzdGluZ3Vpc2hlcidzIHB1cnBvc2UgaXMgdG8gYWRkIDY0LWJpdHMg b2YgIGRpc2FtYmlndWF0aW5nDQp8ICAgICAgZW50cm9weSB0byB0aGUgTkxSSSwgc3VjaA0KfCAN CnwgICAgICB0aGF0IHRoZSByb3V0ZS1yZWZsZWN0b3JzIGRvIG5vdCAic3dhbGxvdyIgdGhhdCBw YXRoIGFzIHBhcnQgb2YgdGhlDQp8ICAgICAgYmVzdC1wYXRoIGVsZWN0aW9uDQp8IA0KfCAgICAg IHByb2NlZHVyZS4gVGhlIGxpbmstc3RhdGUgTkxSSSAoZW5jYXBzdWxhdGVkIGluIE1QX1JFQUNI LyBNUCBVTlJFQUNIIFBBKQ0KfCANCnwgICAgICBpcyBhIFJELWxlc3MgdmVyc2lvbiBvZiB0aGUg dnBuLWxpbmstc3RhdGUgTkxSSS4NCnwgDQp8ICAgICAgSW4gYSBjZXJ0YWluIHdheSB0aGVzZSBj b3JyZXNwb25kIHRvIFJGQzMxMDcgLyBSRkM0MzY0IE5MUkkgZm9ybWF0cy4NCnwgDQp8ICAgICAg VGhlIGZvcm1lciBpcyBhIFJELWxlc3MgdmVyc2lvbiBvZiB0aGUgbGF0dGVyLg0KfCANCnwgICAg ICBPbiB5b3VyIHF1ZXN0aW9uICJXaHkgZG8ndCB5b3UgcHV0IFJEIGluIElQIFJlYWNoYWJpbGl0 eSBJbmZvcm1hdGlvbiwNCnwgICAgICBqdXN0IHByZXBlbmRpbmcgUkQgd2l0aCBJUCBwcmVmaXgg YXMgUkZDNDM2NCBzcGVjaWZpZXMuIiAtIFRoaXMgaXMNCnwgICAgICBhY3R1YWxseSB3aGF0IHdl ICphcmUqIGRvaW5nIC0gd2UgcHV0IHRoZSBSRCBiZWZvcmUgdGhlIGxpbmstc3RhdGUgTkxSSQ0K fCAgICAgIGluc2lkZSB0aGUgTVBfUkVBQ0gvTVBfVU5SRUFDSCBBdHRyaWJ1dGUuDQp8IA0KfCAg ICAgIEhUSCwNCnwgDQp8ICAgICAgL2hhbm5lcw0KfCANCnwgICAgLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N CnwgDQp8ICAgICAgRnJvbTogbGl6aGVucWlhbmdAY2hpbmFtb2JpbGUuY29tIDxsaXpoZW5xaWFu Z0BjaGluYW1vYmlsZS5jb20+DQp8ICAgICAgU2VudDogVHVlc2RheSwgU2VwdGVtYmVyIDAyLCAy MDE0IDg6NDQNCnwgICAgICBUbzogSGFubmVzIEdyZWRsZXI7IFVtYSBDaHVuZHVyaQ0KfCAgICAg IENjOiAnaWRyIHdnJzsgJ0pvaG4gRy4gU2N1ZGRlcic7IFN1c2FuIEhhcmVzDQp8ICAgICAgU3Vi amVjdDogUmU6IFJlOiBbSWRyXSBXRyBMQyBmb3IgZHJhZnQtaWV0Zi1pZHItbHMtZGlzdHJpYnV0 aW9uIGFuZA0KfCAgICAgIGRyYWZ0LWlldGYtaWRyLWxzLWRpc3RyaWJ1dC1pbXBsDQp8IA0KfCAg ICAgIE9uZSBxdWVzdGlvbiBhYm91dCB0aGUgVlBOIExpbmstU3RhdGUgTkxSSSBpbiBzZWN0aW9u IDMuMi4gV2h5IGRvIHlvdQ0KfCAgICAgIHB1dCB0aGUgUkQgYmVmb3JlIGxpbmsgc3RhdGUgTlJM ST8gV2h5IGRvJ3QgeW91IHB1dCBSRCBpbiBJUA0KfCAgICAgIFJlYWNoYWJpbGl0eSBJbmZvcm1h dGlvbiwganVzdCBwcmVwcmVuZGluZyBSRCB3aXRoIElQIHByZWZpeCBhcyBSRkM0MzY0DQp8ICAg ICAgc3BlY2lmaWVzLg0KfCANCnwgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCnwgDQp8ICAgICAgbGl6 aGVucWlhbmdAY2hpbmFtb2JpbGUuY29tDQp8IA0KfCANCnwgICAgICAgIEZyb206IFs3XUhhbm5l cyBHcmVkbGVyDQp8ICAgICAgICBEYXRlOiAyMDE0LTA5LTAyIDAyOjA1DQp8ICAgICAgICBUbzog WzhdVW1hIENodW5kdXJpDQp8ICAgICAgICBDQzogWzldaWRyQGlldGYub3JnOyBbMTBdJ0pvaG4g Ry4gU2N1ZGRlcic7IFsxMV1TdXNhbiBIYXJlcw0KfCAgICAgICAgU3ViamVjdDogUmU6IFtJZHJd IFdHIExDIGZvciBkcmFmdC1pZXRmLWlkci1scy1kaXN0cmlidXRpb24gYW5kDQp8ICAgICAgICBk cmFmdC1pZXRmLWlkci1scy1kaXN0cmlidXQtaW1wbA0KfCAgICAgICAgaGkgdW1hLA0KfCANCnwg ICAgICAgIHNlZSBjb21tZW50cy9yZXNwb25zZXMgaW5saW5lOg0KfCANCnwgICAgICAgIE9uIFdl ZCwgQXVnIDI3LCAyMDE0IGF0IDExOjA3OjAxQU0gKzAwMDAsIFVtYSBDaHVuZHVyaSB3cm90ZToN CnwgICAgICAgIHwgICAgU3VwcG9ydC4NCnwgICAgICAgIHwNCnwgICAgICAgIHwgICAgSSBzZWUs IGhpZXJhcmNoeSBpcyBXRUxMICBkZWZpbmVkIHdoZW4gbXVsdGlwbGUgaW5zdGFuY2VzIG9mIElH UA0KfCAgICAgICAgd2l0aA0KfCAgICAgICAgfCAgICBtdWx0aXBsZSBBRnMgYXJlIHJ1bm5pbmcu IEdvb2Qgd29yay4NCnwgICAgICAgIHwNCnwgICAgICAgIHwNCnwgICAgICAgIHwNCnwgICAgICAg IHwgICAgSGF2ZSBmb2xsb3dpbmcgUXM6DQp8ICAgICAgICB8DQp8ICAgICAgICB8ICAgIDEuICAg ICAgIEFueSBkaXNjdXNzaW9uIG9mIHRoZSBkZWxheSBpbnRyb2R1Y2VkIGJ5IEJHUCAocGFja2lu ZywNCnwgICAgICAgIHVwZGF0ZQ0KfCAgICAgICAgfCAgICBnZW5lcmF0aW9uLCBwcm9jZXNzaW5n IGV0Yy4uKSB0byB0cmFuc3BvcnQgdGhlIExTIGluZm9ybWF0aW9uDQp8ICAgICAgICB8DQp8ICAg ICAgICB8ICAgIGVzcGVjaWFsbHksIHdoZW4gTFNEQiBpcyBjaGFuZ2luZyBmYXN0ZXIgcGVyaGFw cyB3aXRoIGxhcmdlDQp8ICAgICAgICBudW1iZXIgb2YNCnwgICAgICAgIHwgICAgbm9kZXMvbGlu a3MgaW5zaWRlIGFuIEFTIGFuZCB3aXRoIG11bHRpcGxlIEFTZXMpIHRvIHRoZQ0KfCAgICAgICAg Y29udHJvbGxlciB3aWxsIGJlDQp8ICAgICAgICB8ICAgIHVzZWZ1bC4NCnwgDQp8ICAgICAgICB0 aGlzIGlzIGhpZ2hseSBpbXBsZW1lbnRhdGlvbiBkZXBlbmRlbnQ7IC0NCnwgICAgICAgIHNvbWUg dmVuZG9ycyBkbyB0aGUgcGFja2FnaW5nIG9mIEJHUCB1cGRhdGVzIGVudGlyZWx5IGV2ZW50LWRy aXZlbg0KfCAgICAgICAgYW5kIG90aGVycyBwYWNrIHRoaW5ncyB1cCBhbmQgaGF2ZSBhIHdvcnN0 IGNhc2UgZGVsYXkgYmV0d2Vlbg0KfCAgICAgICAgdGhlIHRyaWdnZXIgZXZlbnQgYW5kIHRoZSBC R1AgdXBkYXRlLiB0aGUgcHJvdG9jb2wNCnwgICAgICAgIGl0c2VsZiBkb2VzIG5vdCBwcm9oaWJp dC9saW1pdCB0aGUgcHJvcGFnYXRpb24gc3BlZWQuDQp8ICAgICAgICAoaW4gZmFjdCBpdCBjYW4g YmUgc2hvd24gdGhhdCBzb21ldGltZXMgdXBkYXRlcw0KfCAgICAgICAgdHJhdmVsIGZhc3RlciBv biB0aGUgKGRhdGFwbGFuZSBmb3J3YXJkZWQpIGlCR1AgbWVzaCwNCnwgICAgICAgIHJhdGhlciB0 aGFuIHByb3BnYXRlIHVzaW5nIHRoZSBob3AtYnktaG9wIGNvbnRyb2wtcGxhbmUgZmxvb2RpbmcN CnwgICAgICAgIHByb3RvY29sKQ0KfCANCnwgICAgICAgIHwgICAgICAgICAgICAgICAgIEEgbm90 ZSBvbiB0aGUgc2Vuc2l0aXZpdHkgb2YgdGhpcyBkZWxheSB0byB0aGUNCnwgICAgICAgIGNvbnN1 bWVyDQp8ICAgICAgICB8ICAgIChhcHBsaWNhdGlvbnMpIGF0IHRoZSBjb250cm9sbGVyICBjYW4g YmUgaGVscGZ1bC4gSSBzYXcgdmVyeQ0KfCAgICAgICAgbGl0dGxlDQp8ICAgICAgICB8ICAgIGRp c2N1c3Npb24gaW4gU2VjdGlvbiA2ICg2LjEuNSkNCnwgDQp8ICAgICAgICBkaWZmaWNpdWx0IC0g aXRzIGhhcmQgdG8gaGF2ZSBzb21lIHNvcnQgb2YgZ2VuZXJhbCBjb21tZW50IGFzIHRoaW5ncw0K fCAgICAgICAgYXJlDQp8ICAgICAgICBoaWdobHkgaW1wbGVtZW50YXRpb24gZGVwZW5kZW50Lg0K fCANCnwgDQp8ICAgICAgICB8ICAgIDIuICAgICAgIFRoaXMgZG9jdW1lbnQgZW5jb21wYXNzZXMg cHJldHR5IG11Y2ggYm90aCBPU1BGIGFuZCBJU0lTDQp8ICAgICAgICB8ICAgIGV4dGVuc2lvbnMg ZG9uZSB0aWxsIGRhdGUuIEhvdyBpdCB3aWxsIGtlZXAgdXAgd2l0aCBmdXR1cmUNCnwgICAgICAg IGV4dGVuc2lvbnMgaW4NCnwgICAgICAgIHwgICAgT1NQRi9JU0lTLg0KfCANCnwgICAgICAgIHdl IGhhdmUgc2V0IHVwIGFuIElBTkEgcmVnaXN0cmllcyBmb3IgdGhlIGNhcnJpZXJzIG9mIGluZm9y bWF0aW9uLg0KfCAgICAgICAgaXQgaXMgZXhwZWN0ZWQgYnkgYXV0aG9ycyBvZiAidG9wb2xvZ2lj YWwgcmVsZXZhbnQiIElHUCBleHRlbnNpb25zDQp8ICAgICAgICB0byBzdXBwbHkgYWxzbyBCR1At TFMgZXh0ZW5zaW9ucy4NCnwgDQp8ICAgICAgICB8ICAgIEEgbWVjaGFuaXNtIGluIHBsYWNlIHdv dWxkIGJlIGhlbHBmdWwuIE15IHN1Z2dlc3Rpb24gd291bGQgYmUtDQp8ICAgICAgICB0aGUNCnwg ICAgICAgIHwgICAgcmVzcGVjdGl2ZSBJR1AgZG9jdW1lbnRzIHNob3VsZCBhc3Nlc3MgdGhlIGlt cGFjdCBhbmQgZGVmaW5lDQp8ICAgICAgICB8DQp8ICAgICAgICB8ICAgIGNvcnJlc3BvbmRpbmcg bmV3IFRMVnMgZm9yIEJHUCBMUz8gQnV0IGhvdyB0aGlzIGNhbiBiZSBlbmZvcmNlZD8NCnwgDQp8 ICAgICAgICBpIGhhdmUgbm8gaWRlYSAtIHRvZGF5IGl0cyBlbnRpcmVseSB2b2x1bnRhcnkuDQp8 IA0KfCAgICAgICAgfCAgICAzLiAgICAgICBTZWN0aW9uIDQsIGdpdmVzIGdsaW1wc2Ugd2hhdCdz IHBvc3NpYmxlIGFuZCB0aGUgbm9kZQ0KfCAgICAgICAgYWdncmVnYXRpbmcNCnwgICAgICAgIHwg ICAgdGhlIGxpbmtzIG9idmlvdXNseSBuZWVkIHRvIHRpbmtlciB0aGUgTFNEQiB0byByZXByZXNl bnQgdGhlIHNhbWUNCnwgICAgICAgIHwgICAgY29ycmVjdGx5Lg0KfCAgICAgICAgfA0KfCAgICAg ICAgfCAgICBTb21lIG1vcmUgZGV0YWlscyB3b3VsZCBiZSBoZWxwZnVsIHRvIHJlcHJlc2VudCB0 aGUgY2hhbmdlcyBvbg0KfCAgICAgICAgfCAgICBhZ2dyZWdhdGlvbi9kZS1hZ2dyZWdhdGlvbiBz dWJzZXF1ZW50bHkuDQp8IA0KfCAgICAgICAgdGhpcyBtYXkgcXVpY2tseSBnZXQgeW91IGludG8g dGhlICJhYnN0cmFjdGVkIHRvcG9sb2d5IG1vZGVscyINCnwgICAgICAgIGRpc2N1c3Npb24gdGhh dCBrZWVwcyBlbWVyZ2luZyAgcGVyaW9kaWNhbGx5LiAtDQp8ICAgICAgICB3ZSBkaWQgbm90IHdh bnQgdG8gc3RvcCBwcm9ncmVzcyBvbiB0aGUgcHJvdG9jb2wgYnkgYXJndWluZw0KfCAgICAgICAg IndoYXRzIHRoZSByaWdodCBhYnN0cmFjdGlvbiBtb2RlbCIgYW5kIGhhdmUgYWdyZWVkDQp8ICAg ICAgICBvbiB0aGUgbWluaW1hbGlzdGljIG5hdHVyZSBvZiB0aGUgc2VjdGlvbiBhcy1pcy4NCnwg DQp8IA0KfCAgICAgICAgfCAgICA0LiAgICAgICBTZWN0aW9uIDYuMiBoYXMgZW1wdHkgc3ViLXNl Y3Rpb25zIGFuZCBUQkRzLg0KfCANCnwgICAgICAgIHJpZ2h0IC4uLiBzbyBzdWdnZXN0IHRvIHJl bW92ZSBzZWN0aW9uIDYuMiBhbHRvZ2V0aGVyLg0KfCANCnwgICAgICAgIHwgICAgNS4gICAgICAg SXQncyBnb29kIHRvIHNlZSBJbXBsZW1lbnRhdGlvbiByZXBvcnQgc2hlZCBsaWdodCBvbg0KfCAg ICAgICAgcGVyZm9ybWFuY2UNCnwgICAgICAgIHwgICAgc2VlbiB3aXRoIG11bHRpcGxlIEFTZXMu DQp8ICAgICAgICB8DQp8ICAgICAgICB8ICAgIDYuICAgICAgIEl0J3MgZ29vZCB0byBzZWUgaWYg YW55IGFwcGxpY2F0aW9uIG9mIHBvbGljeSBvbiBMU0RCIGlzDQp8ICAgICAgICBkb25lDQp8ICAg ICAgICB8ICAgIChvbmUgb2YgdGhlIHByaW1hcnkgZHJpdmVycyBvZiB0aGUgc3BlY2lmaWNhdGlv bikuDQp8IA0KfCANCnwgICAgICAgIHRoYW5rcywNCnwgDQp8IA0KfCAgICAgICAgL2hhbm5lcw0K fCANCnwgICAgICAgIHwNCnwgICAgICAgIHwgICAgRnJvbTogSWRyIFttYWlsdG86aWRyLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTdXNhbiBIYXJlcw0KfCAgICAgICAgfCAgICBTZW50 OiBUdWVzZGF5LCBBdWd1c3QgMjYsIDIwMTQgMTE6MzcgQU0NCnwgICAgICAgIHwgICAgVG86IGlk ckBpZXRmLm9yZw0KfCAgICAgICAgfCAgICBDYzogJ0pvaG4gRy4gU2N1ZGRlcic7IHNoYXJlc0Bu ZHpoLmNvbQ0KfCAgICAgICAgfCAgICBTdWJqZWN0OiBbSWRyXSBXRyBMQyBmb3IgZHJhZnQtaWV0 Zi1pZHItbHMtZGlzdHJpYnV0aW9uIGFuZA0KfCAgICAgICAgfCAgICBkcmFmdC1pZXRmLWlkci1s cy1kaXN0cmlidXQtaW1wbA0KfCAgICAgICAgfA0KfCAgICAgICAgfA0KfCAgICAgICAgfA0KfCAg ICAgICAgfCAgICBUaGlzIGlzIGEgV0cgTEMgZm9yDQp8ICAgICAgICB8DQp8ICAgICAgICB8DQp8 ICAgICAgICB8DQp8ICAgICAgICB8DQp8ICAgICAgICBbMV1odHRwOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaWRyLWxzLWRpc3RyaWJ1dGlvbi8NCnwgICAgICAgIHwNCnwg ICAgICAgIHwNCnwgICAgICAgIFsyXWh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaWV0Zi1pZHItbHMtZGlzdHJpYnV0aW9uLWltcGwvDQp8ICAgICAgICB8DQp8ICAgICAgICB8 DQp8ICAgICAgICB8DQp8ICAgICAgICB8ICAgIFBsZWFzZSByZXNwb25kIHdpdGggY29tbWVudHMg YW5kICJzdXBwb3J0IG9yIG5vIHN1cHBvcnQuIiAgVGhpcw0KfCAgICAgICAgV0cgTEMgYWxzbw0K fCAgICAgICAgfCAgICBpbmNsdWRlcyBhIHJlcXVlc3QgZm9yIHRoZSBhdXRob3JzIHRvIHByb3Zp ZGUgSVBSIG9uIHRoZSBzdWJqZWN0Lg0KfCAgICAgICAgfA0KfCAgICAgICAgfA0KfCAgICAgICAg fA0KfCAgICAgICAgfCAgICBQbGVhc2Ugbm90ZTogZHVlIHRvIHRoZSBFdXJvcGVhbiB2YWNhdGlv bnMgaW4gQXVndXN0LCB3ZSBhcmUNCnwgICAgICAgIGJ1bmRsaW5nDQp8ICAgICAgICB8ICAgIHRo ZXNlIHRocmVlIHJldmlld3MgaW50byB0aGUgbmV4dCB0d28gd2Vla3MgKHRoZXNlIHR3byBkcmFm dHMgYW5kDQp8ICAgICAgICB8ICAgIGRyYWZ0LWlldGYtYXMtbWlncmF0aW9uKS4gICBUaGUgY2hh aXJzIHdvdWxkIGxpa2UgZmVlZGJhY2sgKGxpc3QNCnwgICAgICAgIG9yDQp8ICAgICAgICB8ICAg IHByaXZhdGUgZW1haWwpIHdoZXRoZXIgdGhlIHRocmVlIFdHIExDIHMgaW1wYWN0IGFueW9uZSdz IGFiaWxpdHkNCnwgICAgICAgIHRvIHJldmlldw0KfCAgICAgICAgfCAgICB0aGVzZSBkcmFmdHMg Y2FyZWZ1bGx5Lg0KfCAgICAgICAgfA0KfCAgICAgICAgfA0KfCAgICAgICAgfA0KfCAgICAgICAg fCAgICBUaGFuayB5b3UsDQp8ICAgICAgICB8DQp8ICAgICAgICB8DQp8ICAgICAgICB8DQp8ICAg ICAgICB8ICAgIFN1ZSBIYXJlcyBhbmQgSm9obiBTY3VkZGVyDQp8ICAgICAgICB8DQp8ICAgICAg ICB8IFJlZmVyZW5jZXMNCnwgICAgICAgIHwNCnwgICAgICAgIHwgICAgVmlzaWJsZSBsaW5rcw0K fCAgICAgICAgfCAgICAxLg0KfCAgICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1pZXRmLWlkci1scy1kaXN0cmlidXRpb24vDQp8ICAgICAgICB8ICAgIDIuDQp8ICAg ICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaWRyLWxzLWRp c3RyaWJ1dGlvbi1pbXBsLw0KfCANCnwgICAgICAgIHwgX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCnwgICAgICAgIHwgSWRyIG1haWxpbmcgbGlzdA0KfCAg ICAgICAgfCBJZHJAaWV0Zi5vcmcNCnwgICAgICAgIHwgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9pZHINCnwgDQp8ICAgICAgICBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KfCAgICAgICAgSWRyIG1haWxpbmcgbGlzdA0KfCAgICAg ICAgSWRyQGlldGYub3JnDQp8ICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2lkcg0KfCANCnwgDQp8IFJlZmVyZW5jZXMNCnwgDQp8ICAgIFZpc2libGUgbGlua3MN CnwgICAgMS4gbWFpbHRvOmhhbm5lc0BqdW5pcGVyLm5ldA0KfCAgICAyLiBtYWlsdG86bGl6aGVu cWlhbmdAY2hpbmFtb2JpbGUuY29tDQp8ICAgIDMuIG1haWx0bzp1bWEuY2h1bmR1cmlAZXJpY3Nz b24uY29tDQp8ICAgIDQuIG1haWx0bzppZHJAaWV0Zi5vcmcNCnwgICAgNS4gbWFpbHRvOmpnc0Bi Z3AubnUNCnwgICAgNi4gbWFpbHRvOnNoYXJlc0BuZHpoLmNvbQ0KfCAgICA3LiBtYWlsdG86aGFu bmVzQGp1bmlwZXIubmV0DQp8ICAgIDguIG1haWx0bzp1bWEuY2h1bmR1cmlAZXJpY3Nzb24uY29t DQp8ICAgIDkuIG1haWx0bzppZHJAaWV0Zi5vcmcNCnwgICAxMC4gbWFpbHRvOmpnc0BiZ3AubnUN CnwgICAxMS4gbWFpbHRvOnNoYXJlc0BuZHpoLmNvbQ0KIA0K ------=_001_NextPart143176840625_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =0A
RD should be followed by the IP prefix as specified in RFC4364.

Here in this draft, RD is follwed by the link state NLRI. = Link state NLRI has its own format. See the following example, the 24-bit-= long IP prefix is far away from RD.
=0A

+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;|            NLRI= Type =3D 3         |     Total NL= RI Length         |
+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&n= bsp;|           &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;  |
+         = ;            &= nbsp; Route Distinguisher        &= nbsp;            +<= /div>
 |         &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;    |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+
| Protocol-= ID | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+ 
| Identifier | 
| (64 bits) | 
+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
// Local No= de Descriptor (variable) // 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Type =3D 265       &nbs= p;                    | = Length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+ 
| Prefix Length =3D 24 | IP Prefix (variable) // <= br>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


= The following format f= or the above example is consistent with RFC4364 in my opinion.
=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +
 |         &= nbsp;  NLRI Type =3D 3         |   = ;  Total NLRI Length         = |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+
| Protocol-ID | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Identifier | 
| (= 64 bits) | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+ 
// Local Node Descriptor (variable) // 
+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| = Type =3D 265                  = ;          | Length | 
+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Prefix Length = =3D 88 | IP Prefix (variable) =3D RD followed by the 24-bit-long prefix //=  
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +
=0A
=0A
lizhenqiang@chinamobile.com
=0A
 
From:&nb= sp;Saikat Ray (sairay)
<= b>Date: 2014-09-03 11:23
To: lizhenqiang@chinamobile.com; <= a href=3D"mailto:hannes@juniper.net">Hannes Gredler
Subject: Re: [Idr] WG LC for draft-ietf-id= r-ls-distribution and draft-ietf-idr-ls-distribut-impl
=0A
Sorry, I do not under= stand your point. In BGP-LS as well, the RD field is right after the route= -type and the length:
=0A

=0A
=0A
=0A
  +-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=0A   |            NLRI Type  =        |     Total NLRI Length    = ;     |
=0A
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=0A
   |   &nb= sp;                     =                     &nbs= p;                 |
=0A
=    +                 &nb= sp;     Route Distinguisher           &= nbsp;         +
=0A
   |   &nb= sp;                     =                     &nbs= p;                 |
=0A
=    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+
=0A
   |            =                     &nb= sp;                     =         |
=0A
   //     &= nbsp;            Link-State NLRI (variable) =                 //
=0A
&n= bsp;  |                  = ;                     &n= bsp;                    =   |
=0A
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+
=0A
=0A

=0A
=0A=0A
=0AFrom: "lizhenqiang@chinamobile.com" <lizhenqiang@chinamobile.com>=0ADate: Tuesday, September 2, 2= 014 at 7:39 PM
=0ATo: sairay &l= t;sairay@cisco.com>, Hannes Gre= dler <hannes@juniper.net><= br>=0ACc: "idr@ietf.org" <idr@ietf.or= g>, "shares@ndzh.com" <shares@ndzh.com>, 'John=0A Scudder= ' <jgs@bgp.nu>
=0ASubject: Re: Re: [Idr] WG LC for draft-ietf-i= dr-ls-distribution and draft-ietf-idr-ls-distribut-impl
=0A
=0A
=0A
=0A
=0A
=0A

=0A
=0A
B= ut the postion of RD in RFC6514 is AFTER type field and length field, not = before those fields. Taken Intra-AS I-PMSI A-D Route a= s an example,
=0A

=0A
=0A+-----------= ------------------------+
=0A| Route Type (1 octet) =3D 1  |
= =0A+-----------------------------------+
=0A| Length (1 octet) |
= =0A
+-----------------------------------+
=0A| RD (8 octets) | =0A+-----------------------------------+
=0A| Originating Router=E2= =80=99s IP Addr |
=0A+-----------------------------------+
=0A
=0A
=0A
=0A=0A=0A
=0A
From:&= nbsp;Saikat Ray (sairay)
=0A<= div>Date: 2014-09-03 10:24
=0A
To: <= a href=3D"mailto:lizhenqiang@chinamobile.com">lizhenqiang@chinamobile.com<= /a>;=0AHannes Gredler
=0ACC: 'idr wg'; =0ASusan Hares; 'John G. Scudder'
=0A
Subject: Re: [Idr] WG L= C for draft-ietf-idr-ls-distribution and draft-ietf-idr-ls-distribut-impl<= /div>=0A
=0A
=0A
=0A
=0A

=0A
=0A=0A
=0AFrom: "lizhenqiang@= chinamobile.com" <li= zhenqiang@chinamobile.com>
=0AD= ate: Tuesday, September 2, 2014 at 7:18 PM
=0ATo: sairay <s= airay@cisco.com>, Hannes Gredler <hannes@juniper.net>
=0A= Cc: "idr@ietf.org" <idr@ietf.org>, "shares@ndzh.com" <share= s@ndzh.com>, 'John=0A Scudder' <jg= s@bgp.nu>
=0ASubject: Re= : Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-ietf-idr-ls= -distribut-impl
=0A
=0A

=0A
=0A
=0A
=0A
<= span>Placing the type field before the length field is fine for me.=
=0A

=0A
=0A
The encoding format for RD in this draf= t is not consistent with RFC4364. This is the question. RFC6514 says "The Route Distinguisher (RD) is encoded as described in=0A [RFC= 4364]", please see section 4 of RFC6514.
=0A
= =0A
=0A=0A

=0A
=0A
[SR] That statement in RFC= 6514 refers to how the 8 bytes of the route-distinguisher field are encode= d (different RD types, values, etc.), not to the position of RD field in t= he NLRI.
=0A=0A
=0A
=0A
=0A
=0A
I agree with you for the advantage to put the RD bef= ore other fields. I raise this quesiton just for clarification.
=0A
=0A
=0A
=0A=0A=0A
 
=0A
=0A
=0A=0A=
Date: 2014-09-03 05:03
=0A=0A<= div>CC: 'idr wg'; =0ASusan Hares; 'John G. Scudder'
=0A
Subject: Re: [Idr] WG L= C for draft-ietf-idr-ls-distribution and draft-ietf-idr-ls-distribut-impl<= /div>=0A
=0A
=0A
=0A
= =0A
Hi Zhenqi= ang:
=0A
=0A
=0A
=0A
=0A= For the NLRIs that uses a "type" field, such as MVPN (see RFC6514), the co= nvention is to encode the type field before the length field. This allows = for greatest flexibility for future extensions. In BGP-LS, we have used th= e same convention.
=0A
=0A
=0A
=0A
=0AOther than that, the RD is for the entire bgp-ls object (be it a = Node, Link or Prefix). So placing the RD field before other fields is logi= cally accurate.
=0A
=0A
=0A
=0A
=0AThanks.
=0A
=0A
=0A
=0A=0A
=0AFrom: "lizhenqiang@chinamobile.com" <lizhenqiang@chinamobile.com>=0ADate: Tuesday, September 2, 2= 014 at 4:21 AM
=0ATo: Hannes Gr= edler <hannes@juniper.net>=
=0ACc: "idr@ietf.org" <idr@ietf.o= rg>, "shares@ndzh.com" <<= a href=3D"mailto:shares@ndzh.com">shares@ndzh.com>, 'John=0A Scudde= r' <jgs@bgp.nu>
=0ASubject: Re: [Idr] WG LC for draft-ietf-idr-l= s-distribution and draft-ietf-idr-ls-distribut-impl
=0A
=0A
=0A
=0A
=0A
=0A
Hi Hannes,
=0A
=0A
=0A
One example to explain the differences. One VPN route w= ith prefix length 24 is carried in the NRLI.
=0A

=0A
=0A=
The format this draft specified is as follows.
=0A
=0A
+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=0A<= div> |          &nb= sp; NLRI Type =3D 3         |     = Total NLRI Length         |
= =0A
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /div>=0A
 |         =             &n= bsp;           &nbs= p;            =             &n= bsp;    |
=0A
+      = ;            &= nbsp;    Route Distinguisher     &= nbsp;           &nb= sp;   +
=0A
 |      =             &n= bsp;           &nbs= p;            =             &n= bsp;       |
=0A
+-+-+-+-+-+-+-+-+ +-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=0A| Protocol-ID |
=0A+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=0A| Identifier |
=0A| (64 bits) | =
=0A+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <= br>=0A// Local Node Descriptor (variable) //
=0A+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=0A
=0A
= =0A
| Type =3D 265=                     &nb= sp;      | Length |=0A
=0A+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=0A| Prefix Length =3D 24 | IP Pre= fix (variable) //
=0A+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+
=0A

=0A
=0A

=0A
=0A=
The format RFC4363 specified is as follows.
=0A
+--------------------------------= -------------------------+=0A
=0A| Address Family Identifier (2 octets)= |
=0A+---------------------------------------------------------+
= =0A| Subsequent Address Family Identifier (1 octet) |
=0A+------------= ---------------------------------------------+
=0A| Length of Next Hop= Network Address (1 octet) |
=0A+-------------------------------------= --------------------+
=0A| Network Address of Next Hop (variable) | =0A+---------------------------------------------------------+
=0A| = Reserved (1 octet) |
=0A+---------------------------------------------= ------------+
=0A| Prefix Length =3D 88 |  IP Prefix (vari= able) =3D RD followed by IP prefix // 
=0A+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++
=0A

=0A
=0A
=0A=0A
=0A
lizhenqiang@chinamobile.com
=0A
=0A
=0A
=0A
 
=0A
= =0A=0A=0A
=0A
hi zhenqiang,
=0A
 
=0A=0A
| &nbs= p;  Two types of link state NLRIs are defined in section 3.2 of this<= /div>=0A
|    draft, AFI 16388 / SAFI 71 for non-VPN, A= FI 16388 / SAFI 128 for VPN.
=0A
 
=0A
correct;=0A
 
=0A
|    My question is about AFI= 16388 / SAFI 128 NLRI. From the figure in page 9
=0A
| &nbs= p;  of draft version 5, we can see that RD is put before link state N= LRI.
=0A
 
=0A
 
=0A=0A
 
=0A
this is the NLRI format for AFI 163= 88 / SAFI 71 (unicast)
=0A
 
=0A
   = 0            =        1      =              2=             &n= bsp;      3
=0A
    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
=0A
&n= bsp;  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+
=0A
   |       &n= bsp;    NLRI Type       =    |     Total NLRI Length   =       |
=0A
   +-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=0A
 &nbs= p; |           &nbs= p;            =             &n= bsp;           &nbs= p;            =   |
=0A
   //      &= nbsp;           Link-Sta= te NLRI (variable)         &n= bsp;       //
=0A
   |&nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;             = |
=0A
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+
=0A
 
=0A
and this is the NLRI = format for AFI 16388 / SAFI 128 (VPN-unicast)
=0A
 
=0A=
    0        &= nbsp;          1  &= nbsp;           &nb= sp;    2        &nb= sp;          3
=0A
&= nbsp;   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
=0A
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+
=0A
   |   &nb= sp;        NLRI Type   &= nbsp;      |     Total NLRI L= ength         |
=0A
 = ;  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /div>=0A
   |        = ;            &= nbsp;           &nb= sp;            = ;            &= nbsp;     |
=0A
   +  &nb= sp;            = ;        Route Distinguisher  = ;            &= nbsp;      +
=0A
   | &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;            |=0A
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+
=0A
   |     &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;        |
=0A
   //=             &n= bsp;     Link-State NLRI (variable)   &= nbsp;           &nb= sp; //
=0A
   |      &nbs= p;            =             &n= bsp;           &nbs= p;            =        |
=0A
   +-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=0A
&nbs= p;
=0A
 
=0A
 
=0A
|   = ; The link state NLRI field in this figure contains the IP prefix. As RFC4= 364
=0A
|    specifies, the VPN routes should be c= arried in the NLRI prepending with
=0A
|    RD.=0A
 
=0A
that is what we do - i fail to see the offe= nding part with respect to RFC4364.
=0A
 
=0A
/hann= es
=0A
 
=0A
|
=0A
|   &nb= sp;  From: [1]Hannes Gredler
=0A
|    &n= bsp; Date: 2014-09-02 15:29
=0A
|      T= o: [2]lizhenqiang@chinamobi= le.com; [3]Uma Chunduri
=0A
|      C= C: [4]'idr wg'; [5]'John G. Scudder'; [6]Susan Hares
=0A
| &= nbsp;    Subject: RE: Re: [Idr] WG LC for draft-ietf-idr-ls= -distribution and
=0A
|      draft-ietf-= idr-ls-distribut-impl
=0A
|
=0A
|   &nbs= p;  hi zhenqiang,
=0A
|
=0A
|   &nb= sp;  The Route-distinguisher's purpose is to add 64-bits of  dis= ambiguating
=0A
|      entropy to the NL= RI, such
=0A
|
=0A
|      that= the route-reflectors do not "swallow" that path as part of the
=0A|      best-path election
=0A
| =0A
|      procedure. The link-state NLRI (e= ncapsulated in MP_REACH/ MP UNREACH PA)
=0A
|
=0A
|&nbs= p;     is a RD-less version of the vpn-link-state NLRI= .
=0A
|
=0A
|      In a certai= n way these correspond to RFC3107 / RFC4364 NLRI formats.
=0A
| <= /div>=0A
|      The former is a RD-less versi= on of the latter.
=0A
|
=0A
|    &n= bsp; On your question "Why do't you put RD in IP Reachability Information,=
=0A
|      just prepending RD with IP p= refix as RFC4364 specifies." - This is
=0A
|   &nb= sp;  actually what we *are* doing - we put the RD before the link-sta= te NLRI
=0A
|      inside the MP_REACH/M= P_UNREACH Attribute.
=0A
|
=0A
|    = ;  HTH,
=0A
|
=0A
|      = /hannes
=0A
|
=0A
|    -----------------= ---------------------------------------------------------
=0A
| <= /div>=0A= =0A
|      Sent: Tuesday, September 02, 2014 = 8:44
=0A
|      To: Hannes Gredler; Uma = Chunduri
=0A
|      Cc: 'idr wg'; 'John = G. Scudder'; Susan Hares
=0A
|      Subj= ect: Re: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and
=0A|      draft-ietf-idr-ls-distribut-impl
= =0A
|
=0A
|      One question about= the VPN Link-State NLRI in section 3.2. Why do you
=0A
| &n= bsp;    put the RD before link state NRLI? Why do't you put= RD in IP
=0A
|      Reachability Inform= ation, just preprending RD with IP prefix as RFC4364
=0A
| &= nbsp;    specifies.
=0A
|
=0A
| &nb= sp;  ----------------------------------------------------------------= ----------
=0A
|
=0A
|      lizhenqiang@chinamobile.com
=0A
|
=0A
|
=0A
|    &= nbsp;   From: [7]Hannes Gredler
=0A
|   =      Date: 2014-09-02 02:05
=0A
|  =       To: [8]Uma Chunduri
=0A
| &nb= sp;      CC: [9]i= dr@ietf.org; [10]'John G. Scudder'; [11]Susan Hares
=0A
|&nbs= p;       Subject: Re: [Idr] WG LC for draft-= ietf-idr-ls-distribution and
=0A
|     &= nbsp;  draft-ietf-idr-ls-distribut-impl
=0A
|  &nb= sp;     hi uma,
=0A
|
=0A
| &n= bsp;      see comments/responses inline:
=0A=
|
=0A
|        On Wed, A= ug 27, 2014 at 11:07:01AM +0000, Uma Chunduri wrote:
=0A
| &= nbsp;      |    Support.
=0A<= div>|        |
=0A
| &nbs= p;      |    I see, hierarchy is W= ELL  defined when multiple instances of IGP
=0A
|  = ;      with
=0A
|    = ;    |    multiple AFs are running. Good wor= k.
=0A
|        |
=0A|        |
=0A
|  &= nbsp;     |
=0A
|    &nbs= p;   |    Have following Qs:
=0A
| =        |
=0A
|   &nb= sp;    |    1.     =   Any discussion of the delay introduced by BGP (packing,
=0A|        update
=0A
| &= nbsp;      |    generation, proces= sing etc..) to transport the LS information
=0A
|  &nbs= p;     |
=0A
|     &= nbsp;  |    especially, when LSDB is changing faster p= erhaps with large
=0A
|       = number of
=0A
|        | = ;   nodes/links inside an AS and with multiple ASes) to the=0A
|        controller will be=0A
|        |   = useful.
=0A
|
=0A
|      = ;  this is highly implementation dependent; -
=0A
| &nb= sp;      some vendors do the packaging of BGP upd= ates entirely event-driven
=0A
|     &nb= sp;  and others pack things up and have a worst case delay between=0A
|        the trigger event a= nd the BGP update. the protocol
=0A
|    &nbs= p;   itself does not prohibit/limit the propagation speed.
= =0A
|        (in fact it can be sho= wn that sometimes updates
=0A
|     &nbs= p;  travel faster on the (dataplane forwarded) iBGP mesh,
=0A|        rather than propgate using t= he hop-by-hop control-plane flooding
=0A
|    = ;    protocol)
=0A
|
=0A
|  &n= bsp;     |       &n= bsp;         A note on the sensiti= vity of this delay to the
=0A
|     &nbs= p;  consumer
=0A
|       = |    (applications) at the controller  can be helpful= . I saw very
=0A
|        litt= le
=0A
|        |  &= nbsp; discussion in Section 6 (6.1.5)
=0A
|
=0A
| =        difficiult - its hard to have some so= rt of general comment as things
=0A
|    &nbs= p;   are
=0A
|       = ; highly implementation dependent.
=0A
|
=0A
|
= =0A
|        |    2.=        This document encompasses pretty much= both OSPF and ISIS
=0A
|      &nbs= p; |    extensions done till date. How it will keep up with= future
=0A
|        extension= s in
=0A
|        |  = ;  OSPF/ISIS.
=0A
|
=0A
|    &= nbsp;   we have set up an IANA registries for the carriers of in= formation.
=0A
|        it is = expected by authors of "topological relevant" IGP extensions
=0A
= |        to supply also BGP-LS extensio= ns.
=0A
|
=0A
|      &nbs= p; |    A mechanism in place would be helpful. My suggestio= n would be-
=0A
|        the=0A
|        |   = ; respective IGP documents should assess the impact and define
=0A|        |
=0A
|  =       |    corresponding new TLVs = for BGP LS? But how this can be enforced?
=0A
|
=0A
|&n= bsp;       i have no idea - today its entire= ly voluntary.
=0A
|
=0A
|     =    |    3.       Se= ction 4, gives glimpse what's possible and the node
=0A
| &n= bsp;      aggregating
=0A
|  &= nbsp;     |    the links obviously need= to tinker the LSDB to represent the same
=0A
|   =      |    correctly.
=0A
|&nbs= p;       |
=0A
|   &= nbsp;    |    Some more details would be hel= pful to represent the changes on
=0A
|    &nb= sp;   |    aggregation/de-aggregation subsequentl= y.
=0A
|
=0A
|       = ; this may quickly get you into the "abstracted topology models"
=0A<= div>|        discussion that keeps emer= ging  periodically. -
=0A
|     &nb= sp;  we did not want to stop progress on the protocol by arguing=0A
|        "whats the right abst= raction model" and have agreed
=0A
|     = ;   on the minimalistic nature of the section as-is.
=0A|
=0A
|
=0A
|      &nb= sp; |    4.       Section 6.2= has empty sub-sections and TBDs.
=0A
|
=0A
| &nbs= p;      right ... so suggest to remove section 6.= 2 altogether.
=0A
|
=0A
|     =    |    5.       It= 's good to see Implementation report shed light on
=0A
| &nb= sp;      performance
=0A
|  &n= bsp;     |    seen with multiple ASes.<= /div>=0A
|        |
=0A
|&= nbsp;       |    6. &nbs= p;     It's good to see if any application of policy o= n LSDB is
=0A
|        done=0A
|        |   = (one of the primary drivers of the specification).
=0A
|
= =0A
|
=0A
|        thanks= ,
=0A
|
=0A
|
=0A
|    &n= bsp;   /hannes
=0A
|
=0A
|   &= nbsp;    |
=0A
|     &nbs= p;  |    From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
=0A|        |    Sent: T= uesday, August 26, 2014 11:37 AM
=0A
|    &nb= sp;   |    To: id= r@ietf.org
=0A
|        |&= nbsp;   Cc: 'John G. Scudder'; shares@ndzh.com
=0A
|      &n= bsp; |    Subject: [Idr] WG LC for draft-ietf-idr-ls-distri= bution and
=0A
|        | = ;   draft-ietf-idr-ls-distribut-impl
=0A
|  &= nbsp;     |
=0A
|    &nbs= p;   |
=0A
|        = |
=0A
|        |  &n= bsp; This is a WG LC for
=0A
|      = ;  |
=0A
|        |
= =0A
|        |
=0A
| =        |
=0A=0A
|      &nb= sp; |
=0A
|        |
=0A<= div>|        [2]http://datatrack= er.ietf.org/doc/draft-ietf-idr-ls-distribution-impl/
=0A
|&nb= sp;       |
=0A
|   =      |
=0A
|     &nb= sp;  |
=0A
|        |&nbs= p;   Please respond with comments and "support or no support."&n= bsp; This
=0A
|        WG LC a= lso
=0A
|        |  =   includes a request for the authors to provide IPR on the subject.=0A
|        |
=0A
|&n= bsp;       |
=0A
|   = ;     |
=0A
|     &n= bsp;  |    Please note: due to the European vacations = in August, we are
=0A
|       = bundling
=0A
|        | =    these three reviews into the next two weeks (these two drafts= and
=0A
|        |  = ;  draft-ietf-as-migration).   The chairs would like feedba= ck (list
=0A
|        or
= =0A
|        |    pr= ivate email) whether the three WG LC s impact anyone's ability
=0A|        to review
=0A
|&nbs= p;       |    these drafts ca= refully.
=0A
|        |
= =0A
|        |
=0A
| =        |
=0A
|   &nb= sp;    |    Thank you,
=0A
| &= nbsp;      |
=0A
|   &nbs= p;    |
=0A
|      &= nbsp; |
=0A
|        | &n= bsp;  Sue Hares and John Scudder
=0A
|   &nbs= p;    |
=0A
|      &= nbsp; | References
=0A
|       = ; |
=0A
|        |  =   Visible links
=0A
|      &nb= sp; |    1.
=0A=0A
|        | &= nbsp;  2.
=0A
|        =0Ahttp://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution-imp= l/
=0A
|
=0A
|      &= nbsp; | _______________________________________________
=0A
|&nbs= p;       | Idr mailing list
=0A
|&n= bsp;       | Idr@ietf.org
=0A=0A
|
=0A
|  &nb= sp;     ______________________________________________= _
=0A
|        Idr mailing lis= t
=0A
|        Idr@ietf.org
=0A=0A
|
=0A
| =
=0A
| References
=0A
|
=0A
|   = ; Visible links
=0A=0A=0A=0A|    4. mailto:idr@ietf.= org
=0A=0A=0A
|  &n= bsp; 7. mailto:hannes@juniper.net
=0A=0A
|  &n= bsp; 9. mailto:idr@ietf.org
=0A|   10. mailto:jgs@bgp.nu=0A=0A
 
=0A
=0A
=0A=0A
=0A
=0A
=0A=0A
=0A
=0A=
=0A
=0A=0A=0A=0A=0A=0A ------=_001_NextPart143176840625_=------ From nobody Tue Sep 2 20:57:48 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BEF01A89C3 for ; Tue, 2 Sep 2014 20:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.567 X-Spam-Level: X-Spam-Status: No, score=-14.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QpLx8AMjwAZU for ; Tue, 2 Sep 2014 20:57:41 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF2891A89B0 for ; Tue, 2 Sep 2014 20:57:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=81976; q=dns/txt; s=iport; t=1409716660; x=1410926260; h=from:to:cc:subject:date:message-id:mime-version; bh=splNOM4andrY1bU58HwTrFjgVFjKfoIAGw4J3IBy1V0=; b=TQcXga6GhEu2IPArv6Xc2SaP1JuUWOoWk8KS92OSu3cmuauGpT/XAx3G mlvwjzELn6++W0zab13q1a3UKetyFwEFZspgZgloDD5P3Zi5an+DzA00M o1tXT98u0AVqjK8smWuTLiuoqjZuIAQHj4pkHnOjMMBlSnLuh+iwT1Bcg g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvYVAKmQBlStJV2b/2dsb2JhbABagWwCAVhGU1cEhBSvCJNcgV8BC4dKAYELFneEAwEBAQQBAQEXAUwHCxIBCBEDAQEBIQEGLgsUCQoEAQ0FiEINvSgBF45rCwYBPgEHBgQGhE0FgViEPIkJghSELoZ9gVuKcIhTgWcIFhaBRmwBgQYIFyKBBwEBAQ X-IronPort-AV: E=Sophos; i="5.04,454,1406592000"; d="scan'208,217"; a="74429387" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-3.cisco.com with ESMTP; 03 Sep 2014 03:57:39 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s833vdKa026852 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 3 Sep 2014 03:57:39 GMT Received: from xmb-rcd-x13.cisco.com ([169.254.3.228]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0195.001; Tue, 2 Sep 2014 22:57:39 -0500 From: "Saikat Ray (sairay)" To: "lizhenqiang@chinamobile.com" , "Hannes Gredler" Thread-Topic: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-ietf-idr-ls-distribut-impl Thread-Index: AQHPxyszKyLgv7j6UUmOKYCHg5K+6g== Date: Wed, 3 Sep 2014 03:57:38 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [10.21.93.170] Content-Type: multipart/alternative; boundary="_000_D02BDC7D1FD5Bsairayciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/dB7O2glmuicYLv1C0tY6jMT3f8k Cc: 'idr wg' , "'John G. Scudder'" , Susan Hares Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-ietf-idr-ls-distribut-impl X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 03:57:46 -0000 --_000_D02BDC7D1FD5Bsairayciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Sorry, I still do not see what is the point you are trying to make. Having = the RD field anywhere in the NLRI works. So there isn't any technical issue= here. BGP-LS follows the existing convention of placing the RD field right= after the NLRI type and the NLRI field. The same convention is used in RFC= 6514 (MVPN), draft-ietf-l2vpn-evpn-07 (EVPN draft), to name a couple. Are y= ou claiming that RFC6514 violates RFC4364? Also not all BGP-LS NLRIs have IP prefix (there are three types of NLRIs: N= ode, Link and Prefix). Assuming that you are not asking to move the RD fiel= d for the Node and Link NLRIs, why would you want to have a different encod= ing for Prefix NLRIs? From: "lizhenqiang@chinamobile.com" > Date: Tuesday, September 2, 2014 at 8:41 PM To: sairay >, Hannes Gredler > Cc: "idr@ietf.org" >= , "shares@ndzh.com" >, 'John Scudder' > Subject: Re: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-i= etf-idr-ls-distribut-impl RD should be followed by the IP prefix as specified in RFC4364. Here in this draft, RD is follwed by the link state NLRI. Link state NLRI h= as its own format. See the following example, the 24-bit-long IP prefix is = far away from RD. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NLRI Type =3D 3 | Total NLRI Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Route Distinguisher + | | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | | (64 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Local Node Descriptor (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 265 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length =3D 24 | IP Prefix (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The following format for the above example is consistent with RFC4364 in my= opinion. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NLRI Type =3D 3 | Total NLRI Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | | (64 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Local Node Descriptor (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 265 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length =3D 88 | IP Prefix (variable) =3D RD followed by the 24-bit= -long prefix // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ________________________________ lizhenqiang@chinamobile.com From: Saikat Ray (sairay) Date: 2014-09-03 11:23 To: lizhenqiang@chinamobile.com; Hannes= Gredler CC: 'idr wg'; Susan Hares; 'Jo= hn G. Scudder' Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-ietf-= idr-ls-distribut-impl Sorry, I do not understand your point. In BGP-LS as well, the RD field is r= ight after the route-type and the length: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NLRI Type | Total NLRI Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Route Distinguisher + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Link-State NLRI (variable) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ From: "lizhenqiang@chinamobile.com" > Date: Tuesday, September 2, 2014 at 7:39 PM To: sairay >, Hannes Gredler > Cc: "idr@ietf.org" >= , "shares@ndzh.com" >, 'John Scudder' > Subject: Re: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-i= etf-idr-ls-distribut-impl But the postion of RD in RFC6514 is AFTER type field and length field, not = before those fields. Taken Intra-AS I-PMSI A-D Route as an example, +-----------------------------------+ | Route Type (1 octet) =3D 1 | +-----------------------------------+ | Length (1 octet) | +-----------------------------------+ | RD (8 octets) | +-----------------------------------+ | Originating Router=92s IP Addr | +-----------------------------------+ ________________________________ lizhenqiang@chinamobile.com From: Saikat Ray (sairay) Date: 2014-09-03 10:24 To: lizhenqiang@chinamobile.com; Hannes= Gredler CC: 'idr wg'; Susan Hares; 'Jo= hn G. Scudder' Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-ietf-= idr-ls-distribut-impl From: "lizhenqiang@chinamobile.com" > Date: Tuesday, September 2, 2014 at 7:18 PM To: sairay >, Hannes Gredler > Cc: "idr@ietf.org" >= , "shares@ndzh.com" >, 'John Scudder' > Subject: Re: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-i= etf-idr-ls-distribut-impl Placing the type field before the length field is fine for me. The encoding format for RD in this draft is not consistent with RFC4364. Th= is is the question. RFC6514 says "The Route Distinguisher (RD) is encoded a= s described in [RFC4364]", please see section 4 of RFC6514. [SR] That statement in RFC6514 refers to how the 8 bytes of the route-disti= nguisher field are encoded (different RD types, values, etc.), not to the p= osition of RD field in the NLRI. I agree with you for the advantage to put the RD before other fields. I rai= se this quesiton just for clarification. ________________________________ lizhenqiang@chinamobile.com From: Saikat Ray (sairay) Date: 2014-09-03 05:03 To: lizhenqiang@chinamobile.com; Hannes= Gredler CC: 'idr wg'; Susan Hares; 'Jo= hn G. Scudder' Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-ietf-= idr-ls-distribut-impl Hi Zhenqiang: For the NLRIs that uses a "type" field, such as MVPN (see RFC6514), the con= vention is to encode the type field before the length field. This allows fo= r greatest flexibility for future extensions. In BGP-LS, we have used the s= ame convention. Other than that, the RD is for the entire bgp-ls object (be it a Node, Link= or Prefix). So placing the RD field before other fields is logically accur= ate. Thanks. From: "lizhenqiang@chinamobile.com" > Date: Tuesday, September 2, 2014 at 4:21 AM To: Hannes Gredler > Cc: "idr@ietf.org" >= , "shares@ndzh.com" >, 'John Scudder' > Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-ietf-= idr-ls-distribut-impl Hi Hannes, One example to explain the differences. One VPN route with prefix length 24= is carried in the NRLI. The format this draft specified is as follows. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NLRI Type =3D 3 | Total NLRI Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Route Distinguisher + | | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | | (64 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Local Node Descriptor (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 265 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length =3D 24 | IP Prefix (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The format RFC4363 specified is as follows. +---------------------------------------------------------+ | Address Family Identifier (2 octets) | +---------------------------------------------------------+ | Subsequent Address Family Identifier (1 octet) | +---------------------------------------------------------+ | Length of Next Hop Network Address (1 octet) | +---------------------------------------------------------+ | Network Address of Next Hop (variable) | +---------------------------------------------------------+ | Reserved (1 octet) | +---------------------------------------------------------+ | Prefix Length =3D 88 | IP Prefix (variable) =3D RD followed by IP prefix= // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ ________________________________ lizhenqiang@chinamobile.com From: Hannes Gredler Date: 2014-09-02 16:35 To: lizhenqiang@chinamobile.com CC: Uma Chunduri; 'idr wg'; 'John G. Scudder'; Susan Hares Subject: Re: RE: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-i= etf-idr-ls-distribut-impl hi zhenqiang, On Tue, Sep 02, 2014 at 04:12:58PM +0800, lizhenqiang@chinamobile.com wrote: | Two types of link state NLRIs are defined in section 3.2 of this | draft, AFI 16388 / SAFI 71 for non-VPN, AFI 16388 / SAFI 128 for VPN. correct; | My question is about AFI 16388 / SAFI 128 NLRI. From the figure in pag= e 9 | of draft version 5, we can see that RD is put before link state NLRI. from http://tools.ietf.org/html/draft-ietf-idr-ls-distribution-05#section-3= .2 this is the NLRI format for AFI 16388 / SAFI 71 (unicast) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NLRI Type | Total NLRI Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Link-State NLRI (variable) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ and this is the NLRI format for AFI 16388 / SAFI 128 (VPN-unicast) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NLRI Type | Total NLRI Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Route Distinguisher + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Link-State NLRI (variable) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | The link state NLRI field in this figure contains the IP prefix. As RF= C4364 | specifies, the VPN routes should be carried in the NLRI prepending wit= h | RD. that is what we do - i fail to see the offending part with respect to RFC43= 64. /hannes | | From: [1]Hannes Gredler | Date: 2014-09-02 15:29 | To: [2]lizhenqiang@chinamobile.com; [3]Uma Chunduri | CC: [4]'idr wg'; [5]'John G. Scudder'; [6]Susan Hares | Subject: RE: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and | draft-ietf-idr-ls-distribut-impl | | hi zhenqiang, | | The Route-distinguisher's purpose is to add 64-bits of disambiguati= ng | entropy to the NLRI, such | | that the route-reflectors do not "swallow" that path as part of the | best-path election | | procedure. The link-state NLRI (encapsulated in MP_REACH/ MP UNREACH= PA) | | is a RD-less version of the vpn-link-state NLRI. | | In a certain way these correspond to RFC3107 / RFC4364 NLRI formats. | | The former is a RD-less version of the latter. | | On your question "Why do't you put RD in IP Reachability Information= , | just prepending RD with IP prefix as RFC4364 specifies." - This is | actually what we *are* doing - we put the RD before the link-state N= LRI | inside the MP_REACH/MP_UNREACH Attribute. | | HTH, | | /hannes | | ----------------------------------------------------------------------= ---- | | From: lizhenqiang@chinamobile.com > | Sent: Tuesday, September 02, 2014 8:44 | To: Hannes Gredler; Uma Chunduri | Cc: 'idr wg'; 'John G. Scudder'; Susan Hares | Subject: Re: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and | draft-ietf-idr-ls-distribut-impl | | One question about the VPN Link-State NLRI in section 3.2. Why do yo= u | put the RD before link state NRLI? Why do't you put RD in IP | Reachability Information, just preprending RD with IP prefix as RFC4= 364 | specifies. | | ----------------------------------------------------------------------= ---- | | lizhenqiang@chinamobile.com | | | From: [7]Hannes Gredler | Date: 2014-09-02 02:05 | To: [8]Uma Chunduri | CC: [9]idr@ietf.org; [10]'John G. Scudder'; [= 11]Susan Hares | Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and | draft-ietf-idr-ls-distribut-impl | hi uma, | | see comments/responses inline: | | On Wed, Aug 27, 2014 at 11:07:01AM +0000, Uma Chunduri wrote: | | Support. | | | | I see, hierarchy is WELL defined when multiple instances of = IGP | with | | multiple AFs are running. Good work. | | | | | | | | Have following Qs: | | | | 1. Any discussion of the delay introduced by BGP (packi= ng, | update | | generation, processing etc..) to transport the LS information | | | | especially, when LSDB is changing faster perhaps with large | number of | | nodes/links inside an AS and with multiple ASes) to the | controller will be | | useful. | | this is highly implementation dependent; - | some vendors do the packaging of BGP updates entirely event-driven | and others pack things up and have a worst case delay between | the trigger event and the BGP update. the protocol | itself does not prohibit/limit the propagation speed. | (in fact it can be shown that sometimes updates | travel faster on the (dataplane forwarded) iBGP mesh, | rather than propgate using the hop-by-hop control-plane flooding | protocol) | | | A note on the sensitivity of this delay to the | consumer | | (applications) at the controller can be helpful. I saw very | little | | discussion in Section 6 (6.1.5) | | difficiult - its hard to have some sort of general comment as thin= gs | are | highly implementation dependent. | | | | 2. This document encompasses pretty much both OSPF and = ISIS | | extensions done till date. How it will keep up with future | extensions in | | OSPF/ISIS. | | we have set up an IANA registries for the carriers of information. | it is expected by authors of "topological relevant" IGP extensions | to supply also BGP-LS extensions. | | | A mechanism in place would be helpful. My suggestion would be= - | the | | respective IGP documents should assess the impact and define | | | | corresponding new TLVs for BGP LS? But how this can be enforc= ed? | | i have no idea - today its entirely voluntary. | | | 3. Section 4, gives glimpse what's possible and the nod= e | aggregating | | the links obviously need to tinker the LSDB to represent the = same | | correctly. | | | | Some more details would be helpful to represent the changes o= n | | aggregation/de-aggregation subsequently. | | this may quickly get you into the "abstracted topology models" | discussion that keeps emerging periodically. - | we did not want to stop progress on the protocol by arguing | "whats the right abstraction model" and have agreed | on the minimalistic nature of the section as-is. | | | | 4. Section 6.2 has empty sub-sections and TBDs. | | right ... so suggest to remove section 6.2 altogether. | | | 5. It's good to see Implementation report shed light on | performance | | seen with multiple ASes. | | | | 6. It's good to see if any application of policy on LSD= B is | done | | (one of the primary drivers of the specification). | | | thanks, | | | /hannes | | | | | From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Ha= res | | Sent: Tuesday, August 26, 2014 11:37 AM | | To: idr@ietf.org | | Cc: 'John G. Scudder'; shares@ndzh.com | | Subject: [Idr] WG LC for draft-ietf-idr-ls-distribution and | | draft-ietf-idr-ls-distribut-impl | | | | | | | | This is a WG LC for | | | | | | | | | [1]http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/ | | | | | [2]http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution-= impl/ | | | | | | | | Please respond with comments and "support or no support." Th= is | WG LC also | | includes a request for the authors to provide IPR on the subj= ect. | | | | | | | | Please note: due to the European vacations in August, we are | bundling | | these three reviews into the next two weeks (these two drafts= and | | draft-ietf-as-migration). The chairs would like feedback (l= ist | or | | private email) whether the three WG LC s impact anyone's abil= ity | to review | | these drafts carefully. | | | | | | | | Thank you, | | | | | | | | Sue Hares and John Scudder | | | | References | | | | Visible links | | 1. | http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/ | | 2. | http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution-imp= l/ | | | _______________________________________________ | | Idr mailing list | | Idr@ietf.org | | https://www.ietf.org/mailman/listinfo/idr | | _______________________________________________ | Idr mailing list | Idr@ietf.org | https://www.ietf.org/mailman/listinfo/idr | | | References | | Visible links | 1. mailto:hannes@juniper.net | 2. mailto:lizhenqiang@chinamobile.com | 3. mailto:uma.chunduri@ericsson.com | 4. mailto:idr@ietf.org | 5. mailto:jgs@bgp.nu | 6. mailto:shares@ndzh.com | 7. mailto:hannes@juniper.net | 8. mailto:uma.chunduri@ericsson.com | 9. mailto:idr@ietf.org | 10. mailto:jgs@bgp.nu | 11. mailto:shares@ndzh.com --_000_D02BDC7D1FD5Bsairayciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <0F3085F3A6A3C84DAB7B79F78DB424E4@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Sorry, I still do not see what is the point you are trying to make. Ha= ving the RD field anywhere in the NLRI works. So there isn't any technical = issue here. BGP-LS follows the existing convention of placing the RD field right after the NL= RI type and the NLRI field. The same convention is used in RFC6514 (MVPN),&= nbsp;draft-ietf-l2vpn-evpn-07 (EVPN draft), to name a couple. Are you claim= ing that RFC6514 violates RFC4364?

Also not all BGP-LS NLRIs have IP prefix (there are three types of NLR= Is: Node, Link and Prefix). Assuming that you are not asking to move the RD= field for the Node and Link NLRIs, why would you want to have a different = encoding for Prefix NLRIs?

From: "lizhenqiang@chinamobile.com" <lizhenqiang@chinamobile.com>=
Date: Tuesday, September 2, 2014 at= 8:41 PM
To: sairay <sairay@cisco.com>, Hannes Gredler <hannes@juniper.net>
Cc: "idr@ietf.org" <idr@ietf.= org>, "shares@ndzh.com&q= uot; <shares@ndzh.com>, 'John Scudder' <jgs@bgp.nu>
Subject: Re: Re: [Idr] WG LC for dr= aft-ietf-idr-ls-distribution and draft-ietf-idr-ls-distribut-impl

RD should be followed by the IP prefix as specified in RF= C4364.

Here in this draft, RD is follwed by the link state NLRI. Link state N= LRI has its own format. See the following example, the 24-bit-long IP prefi= x is far away from RD.

+-+-+-+-+-+-+-+-+-+-+-+= ;-+-+-+-+-+-+-+-+-+-+-+-+-&= #43;-+-+-+-+-+-+-+-+
 |          &nb= sp; NLRI Type =3D 3         |     T= otal NLRI Length         |
+-+-+-+-+-+-+-+-+-+-+-+= ;-+-+-+-+-+-+-+-+-+-+-+-+-&= #43;-+-+-+-+-+-+-+-+
 |          &nb= sp;            =             &nb= sp;            =             &nb= sp;  |
+           = ;            Route D= istinguisher          &nb= sp;          +
 |          &nb= sp;            =             &nb= sp;            =             &nb= sp;  |
+-+-+-= +-+-+-+-+-+ +-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+=
| Protocol-ID | 
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+ 
| Identifier | 
| (64 bits) | 
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+ 
// Local Node Descriptor (variable) // 
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+ 
| Type =3D 265   &nb= sp;                     &= nbsp;  | Length | 
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+ 
| Prefix Length =3D 24 | IP Prefix (variable) // 
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+


The following format for = the above example is consistent with RFC4364 in my opinion.
+-+-+-+-+-+-+-+-+-+-+-+= ;-+-+-+-+-+-+-+-+-+-+-+-+-&= #43;-+-+-+-+-+-+-+-+
 |          &nb= sp; NLRI Type =3D 3         |     T= otal NLRI Length         |
+-+-+-+-+-+-+-+-+-+-+-+= ;-+-+-+-+-+-+-+-+-+-+-+-+-&= #43;-+-+-+-+-+-+-+-+
| Protocol-ID | 
+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+ 
| Identifier | 
| (64 bits) | 
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+ 
// Local Node Descriptor (variable) // 
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+ 
| Type =3D 265 &nb= sp;                     &= nbsp;    | Length | 
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+ 
| Prefix Length =3D 88 | IP Prefix (variable) =3D RD followed by the 24-bit= -long prefix // 
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+

 
Date: 2014-09-03 11:23
Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-distributio= n and draft-ietf-idr-ls-distribut-impl
Sorry, I do not understand your point. In BGP-LS as well, the RD field= is right after the route-type and the length:

  +-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+
   |            NLRI Type &nbs= p;        |     Total NLRI Length   &nbs= p;     |
   +-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+
   |                =                     &nbs= p;                     &n= bsp;   |
   +               &n= bsp;       Route Distinguisher         &= nbsp;           +
   |                =                     &nbs= p;                     &n= bsp;   |
   +-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+
   |                =                     &nbs= p;                     &n= bsp;   |
   //                = ;  Link-State NLRI (variable)            = ;     //
   |                =                     &nbs= p;                     &n= bsp;   |
   +-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+

From: "lizhenqiang@chinamobile.com" <lizhenqiang@chinamobile.com>=
Date: Tuesday, September 2, 2014 at= 7:39 PM
To: sairay <sairay@cisco.com>, Hannes Gredler <hannes@juniper.net>
Cc: "idr@ietf.org" <idr@ietf.= org>, "shares@ndzh.com&q= uot; <shares@ndzh.com>, 'John Scudder' <jgs@bgp.nu>
Subject: Re: Re: [Idr] WG LC for dr= aft-ietf-idr-ls-distribution and draft-ietf-idr-ls-distribut-impl


But the postion of RD in RFC6514 is AFTER type field and length field,= not before those fields. Taken Intra-AS I-PMSI A-D Rout= e as an example,

+-----------------------------------+
| Route Type (1 octet) =3D 1  |
+-----------------------------------+
| Length (1 octet) |
+-----------------------------------+
| RD (8 octets) |
+-----------------------------------+
| Originating Router=92s IP Addr |
+-----------------------------------+

 
Date: 2014-09-03 10:24
Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-distributio= n and draft-ietf-idr-ls-distribut-impl

From: "lizhenqiang@chinamobile.com" <lizhenqiang@chinamobile.com>=
Date: Tuesday, September 2, 2014 at= 7:18 PM
To: sairay <sairay@cisco.com>, Hannes Gredler <hannes@juniper.net>
Cc: "idr@ietf.org" <idr@ietf.= org>, "shares@ndzh.com&q= uot; <shares@ndzh.com>, 'John Scudder' <jgs@bgp.nu>
Subject: Re: Re: [Idr] WG LC for dr= aft-ietf-idr-ls-distribution and draft-ietf-idr-ls-distribut-impl

Placing the type field before the length field is fine fo= r me.

The encoding format for RD in this draft is not consistent with RFC436= 4. This is the question. RFC6514 says "The Route Disting= uisher (RD) is encoded as described in [RFC4364]", please see section 4 of RFC6514.

[SR] That statement in RFC6514 refers to how the 8 bytes of the route-= distinguisher field are encoded (different RD types, values, etc.), not to = the position of RD field in the NLRI.

I agree with you for the advantage to put the RD before other fields. = I raise this quesiton just for clarification.

 
Date: 2014-09-03 05:03
Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-distributio= n and draft-ietf-idr-ls-distribut-impl
Hi Zhenqiang:=

For the NLRIs that uses a "type" field, such as MVPN (see RFC6514= ), the convention is to encode the type field before the length field. This= allows for greatest flexibility for future extensions. In BGP-LS, we have = used the same convention.

Other than that, the RD is for the entire bgp-ls object (be it a Node, Link= or Prefix). So placing the RD field before other fields is logically accur= ate.

Thanks.

From: "lizhenqiang@chinamobile.com" <lizhenqiang@chinamobile.com>=
Date: Tuesday, September 2, 2014 at= 4:21 AM
To: Hannes Gredler <hannes@juniper.net>
Cc: "idr@ietf.org" <idr@ietf.= org>, "shares@ndzh.com&q= uot; <shares@ndzh.com>, 'John Scudder' <jgs@bgp.nu>
Subject: Re: [Idr] WG LC for draft-= ietf-idr-ls-distribution and draft-ietf-idr-ls-distribut-impl

Hi Hannes,

One example to explain the differences. One VPN route with prefix leng= th 24 is carried in the NRLI.

The format this draft specified is as follows.
+-+-+-+-+-+-+-+-+-+-+-+= ;-+-+-+-+-+-+-+-+-+-+-+-+-&= #43;-+-+-+-+-+-+-+-+
 |          &nb= sp; NLRI Type =3D 3         |     T= otal NLRI Length         |
+-+-+-+-+-+-+-+-+-+-+-+= ;-+-+-+-+-+-+-+-+-+-+-+-+-&= #43;-+-+-+-+-+-+-+-+
 |          &nb= sp;            =             &nb= sp;            =             &nb= sp;  |
+           = ;            Route D= istinguisher          &nb= sp;          +
 |          &nb= sp;            =             &nb= sp;            =             &nb= sp;  |
+-+-+-= +-+-+-+-+-+ +-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+=
| Protocol-ID |
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
| Identifier |
| (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
// Local Node Descriptor (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
| Type =3D 265 &nb= sp;                     &= nbsp;    | Length |
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
| Prefix Length =3D 24 | IP Prefix (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+


The format RFC4363 specified is as follows.
+-------------= --------------------------------------------+
| Address Family Identifier (2 octets) |
+---------------------------------------------------------+
| Subsequent Address Family Identifier (1 octet) |
+---------------------------------------------------------+
| Length of Next Hop Network Address (1 octet) |
+---------------------------------------------------------+
| Network Address of Next Hop (variable) |
+---------------------------------------------------------+
| Reserved (1 octet) |
+---------------------------------------------------------+
| Prefix Length =3D 88 |  IP Prefix (variable) =3D RD followed = by IP prefix // 
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-++

 
Date: 2014-09-02 16:35
Subject: Re: RE: [Idr] WG LC for draft-ietf-idr-ls-distrib= ution and draft-ietf-idr-ls-distribut-impl
hi zhenqiang,
 
On Tue, Sep 02, 2014 at 04:12:58PM +0800, lizhenqiang@chinamobile.com wrote:
|    Two types of link state NLRIs are defined in secti= on 3.2 of this
|    draft, AFI 16388 / SAFI 71 for non-VPN, AFI 16388 = / SAFI 128 for VPN.
 
correct;
 
|    My question is about AFI 16388 / SAFI 128 NLRI. Fr= om the figure in page 9
|    of draft version 5, we can see that RD is put befo= re link state NLRI.
 
 
 
this is the NLRI format for AFI 16388 / SAFI 71 (unicast)
 
    0        &n= bsp;          1  &nb= sp;            =     2         &= nbsp;         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
   +-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+
   |         &n= bsp;  NLRI Type          = |     Total NLRI Length     &n= bsp;   |
   +-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+
   |         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;   |
   //         &= nbsp;        Link-State NLRI (variable)&= nbsp;           &nbs= p;    //
   |         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;   |
   +-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+
 
and this is the NLRI format for AFI 16388 / SAFI 128 (VPN-unicast)
 
    0        &n= bsp;          1  &nb= sp;            =     2         &= nbsp;         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
   +-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+
   |         &n= bsp;  NLRI Type          = |     Total NLRI Length     &n= bsp;   |
   +-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+
   |         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;   |
   +        &nbs= p;            &= nbsp; Route Distinguisher        &n= bsp;            += ;
   |         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;   |
   +-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+
   |         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;   |
   //         &= nbsp;        Link-State NLRI (variable)&= nbsp;           &nbs= p;    //
   |         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;   |
   +-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+
 
 
 
|    The link state NLRI field in this figure contains = the IP prefix. As RFC4364
|    specifies, the VPN routes should be carried in the= NLRI prepending with
|    RD.
 
that is what we do - i fail to see the offending part with respect to = RFC4364.
 
/hannes
 
|
|      From: [1]Hannes Gredler
|      Date: 2014-09-02 15:29
|      CC: [4]'idr wg'; [5]'John G. Scudder';= [6]Susan Hares
|      Subject: RE: Re: [Idr] WG LC for draft= -ietf-idr-ls-distribution and
|      draft-ietf-idr-ls-distribut-impl
|
|      hi zhenqiang,
|
|      The Route-distinguisher's purpose is t= o add 64-bits of  disambiguating
|      entropy to the NLRI, such
|
|      that the route-reflectors do not "= ;swallow" that path as part of the
|      best-path election
|
|      procedure. The link-state NLRI (encaps= ulated in MP_REACH/ MP UNREACH PA)
|
|      is a RD-less version of the vpn-link-s= tate NLRI.
|
|      In a certain way these correspond to R= FC3107 / RFC4364 NLRI formats.
|
|      The former is a RD-less version of the= latter.
|
|      On your question "Why do't you pu= t RD in IP Reachability Information,
|      just prepending RD with IP prefix as R= FC4364 specifies." - This is
|      actually what we *are* doing - we put = the RD before the link-state NLRI
|      inside the MP_REACH/MP_UNREACH Attribu= te.
|
|      HTH,
|
|      /hannes
|
|    --------------------------------------------------= ------------------------
|
|      Sent: Tuesday, September 02, 2014 8:44=
|      To: Hannes Gredler; Uma Chunduri
|      Cc: 'idr wg'; 'John G. Scudder'; Susan= Hares
|      Subject: Re: Re: [Idr] WG LC for draft= -ietf-idr-ls-distribution and
|      draft-ietf-idr-ls-distribut-impl
|
|      One question about the VPN Link-State = NLRI in section 3.2. Why do you
|      put the RD before link state NRLI? Why= do't you put RD in IP
|      Reachability Information, just prepren= ding RD with IP prefix as RFC4364
|      specifies.
|
|    --------------------------------------------------= ------------------------
|
|
|
|        From: [7]Hannes Gredler
|        Date: 2014-09-02 02:05
|        To: [8]Uma Chunduri
|        CC: [9]idr@ietf.org; [10]'John G. Scudder'; [11]Susan Hares
|        Subject: Re: [Idr] WG LC f= or draft-ietf-idr-ls-distribution and
|        draft-ietf-idr-ls-distribu= t-impl
|        hi uma,
|
|        see comments/responses inl= ine:
|
|        On Wed, Aug 27, 2014 at 11= :07:01AM +0000, Uma Chunduri wrote:
|        |    Suppor= t.
|        |
|        |    I see,= hierarchy is WELL  defined when multiple instances of IGP
|        with
|        |    multip= le AFs are running. Good work.
|        |
|        |
|        |
|        |    Have f= ollowing Qs:
|        |
|        |    1.&nbs= p;      Any discussion of the delay introduced by = BGP (packing,
|        update
|        |    genera= tion, processing etc..) to transport the LS information
|        |
|        |    especi= ally, when LSDB is changing faster perhaps with large
|        number of
|        |    nodes/= links inside an AS and with multiple ASes) to the
|        controller will be
|        |    useful= .
|
|        this is highly implementat= ion dependent; -
|        some vendors do the packag= ing of BGP updates entirely event-driven
|        and others pack things up = and have a worst case delay between
|        the trigger event and the = BGP update. the protocol
|        itself does not prohibit/l= imit the propagation speed.
|        (in fact it can be shown t= hat sometimes updates
|        travel faster on the (data= plane forwarded) iBGP mesh,
|        rather than propgate using= the hop-by-hop control-plane flooding
|        protocol)
|
|        |    &= nbsp;            A n= ote on the sensitivity of this delay to the
|        consumer
|        |    (appli= cations) at the controller  can be helpful. I saw very
|        little
|        |    discus= sion in Section 6 (6.1.5)
|
|        difficiult - its hard to h= ave some sort of general comment as things
|        are
|        highly implementation depe= ndent.
|
|
|        |    2.&nbs= p;      This document encompasses pretty much both= OSPF and ISIS
|        |    extens= ions done till date. How it will keep up with future
|        extensions in
|        |    OSPF/I= SIS.
|
|        we have set up an IANA reg= istries for the carriers of information.
|        it is expected by authors = of "topological relevant" IGP extensions
|        to supply also BGP-LS exte= nsions.
|
|        |    A mech= anism in place would be helpful. My suggestion would be-
|        the
|        |    respec= tive IGP documents should assess the impact and define
|        |
|        |    corres= ponding new TLVs for BGP LS? But how this can be enforced?
|
|        i have no idea - today its= entirely voluntary.
|
|        |    3.&nbs= p;      Section 4, gives glimpse what's possible a= nd the node
|        aggregating
|        |    the li= nks obviously need to tinker the LSDB to represent the same
|        |    correc= tly.
|        |
|        |    Some m= ore details would be helpful to represent the changes on
|        |    aggreg= ation/de-aggregation subsequently.
|
|        this may quickly get you i= nto the "abstracted topology models"
|        discussion that keeps emer= ging  periodically. -
|        we did not want to stop pr= ogress on the protocol by arguing
|        "whats the right abst= raction model" and have agreed
|        on the minimalistic nature= of the section as-is.
|
|
|        |    4.&nbs= p;      Section 6.2 has empty sub-sections and TBD= s.
|
|        right ... so suggest to re= move section 6.2 altogether.
|
|        |    5.&nbs= p;      It's good to see Implementation report she= d light on
|        performance
|        |    seen w= ith multiple ASes.
|        |
|        |    6.&nbs= p;      It's good to see if any application of pol= icy on LSDB is
|        done
|        |    (one o= f the primary drivers of the specification).
|
|
|        thanks,
|
|
|        /hannes
|
|        |
|        |    From: = Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
|        |    Sent: = Tuesday, August 26, 2014 11:37 AM
|        |    Cc: 'J= ohn G. Scudder'; shares@ndzh.com
|        |    Subjec= t: [Idr] WG LC for draft-ietf-idr-ls-distribution and
|        |    draft-= ietf-idr-ls-distribut-impl
|        |
|        |
|        |
|        |    This i= s a WG LC for
|        |
|        |
|        |
|        |
|        |
|        |
|        |
|        |
|        |
|        |    Please= respond with comments and "support or no support."  This
|        WG LC also
|        |    includ= es a request for the authors to provide IPR on the subject.
|        |
|        |
|        |
|        |    Please= note: due to the European vacations in August, we are
|        bundling
|        |    these = three reviews into the next two weeks (these two drafts and
|        |    draft-= ietf-as-migration).   The chairs would like feedback (list
|        or
|        |    privat= e email) whether the three WG LC s impact anyone's ability
|        to review
|        |    these = drafts carefully.
|        |
|        |
|        |
|        |    Thank = you,
|        |
|        |
|        |
|        |    Sue Ha= res and John Scudder
|        |
|        | References
|        |
|        |    Visibl= e links
|        |    1.
|        |    2.
|        http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution-impl/
|
|        | ________________________= _______________________
|        | Idr mailing list
|        | Idr@ietf.org
|
|        __________________________= _____________________
|        Idr mailing list
|        Idr@ietf.org
 --_000_D02BDC7D1FD5Bsairayciscocom_-- From nobody Tue Sep 2 20:59:57 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC501A89C4 for ; Tue, 2 Sep 2014 20:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.567 X-Spam-Level: X-Spam-Status: No, score=-14.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W0qIVYb-9S8o for ; Tue, 2 Sep 2014 20:59:50 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EBCE1A89C3 for ; Tue, 2 Sep 2014 20:59:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=85272; q=dns/txt; s=iport; t=1409716790; x=1410926390; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=bNS0Vg67oWEHYwXUvgqP7xrKxy5TdxB4E/nZskm4MtA=; b=IfoiXfMo1oPuB5PzRReC2tve9CoOS8h9dJUejarI195dpXCnj8SG9CkE yvOW4SYgUy12RfqEvAswLhkwhcBeHITwOtZyxn69LeuXuFfxhGYBztakh qzpVm2Qg4cf02kuESWqY9VvWSX9r2hN7Ew/2VMsK5rBGjmKu8RG4WQviy o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArYaANSRBlStJA2H/2dsb2JhbABagWwCAVhGU04JBIQUrwqTXIFfAQuHSgGBCxZ3hAMBAQEEAQEBFwFMBwsQAgEIEQMBAQEhAQYHJwsUCQgCBAENBYhCDb0oAReOawsGAT4BBwYEBgGETAWBWIQ8iQmCFIQuhn2BW4pwiFOBZwgWFoFGbAGBBggXIoEHAQEB X-IronPort-AV: E=Sophos; i="5.04,454,1406592000"; d="scan'208,217"; a="74438381" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-5.cisco.com with ESMTP; 03 Sep 2014 03:59:43 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s833xhPn001826 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 3 Sep 2014 03:59:43 GMT Received: from xmb-rcd-x13.cisco.com ([169.254.3.228]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Tue, 2 Sep 2014 22:59:42 -0500 From: "Saikat Ray (sairay)" To: "Saikat Ray (sairay)" , "lizhenqiang@chinamobile.com" , Hannes Gredler Thread-Topic: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-ietf-idr-ls-distribut-impl Thread-Index: AQHPxyszKyLgv7j6UUmOKYCHg5K+6pvupxsA Date: Wed, 3 Sep 2014 03:59:42 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [10.21.93.170] Content-Type: multipart/alternative; boundary="_000_D02BE0041FD79sairayciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/9e8zJGHwtZiDPKyBXBFJiKlCrkE Cc: 'idr wg' , Susan Hares , "'John G. Scudder'" Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-ietf-idr-ls-distribut-impl X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 03:59:55 -0000 --_000_D02BE0041FD79sairayciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable From: sairay > Date: Tuesday, September 2, 2014 at 8:57 PM To: "lizhenqiang@chinamobile.com" >, Hannes Gredle= r > Cc: "idr@ietf.org" >= , 'John Scudder' >, "shares@ndzh.com" > Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-ietf-= idr-ls-distribut-impl Sorry, I still do not see what is the point you are trying to make. Having = the RD field anywhere in the NLRI works. So there isn't any technical issue= here. BGP-LS follows the existing convention of placing the RD field right after the NLRI type and the NLRI field. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [SR] "...right after the NLRI type and the NLRI length fields". The same convention is used in RFC6514 (MVPN), draft-ietf-l2vpn-evpn-07 (EV= PN draft), to name a couple. Are you claiming that RFC6514 violates RFC4364= ? Also not all BGP-LS NLRIs have IP prefix (there are three types of NLRIs: N= ode, Link and Prefix). Assuming that you are not asking to move the RD fiel= d for the Node and Link NLRIs, why would you want to have a different encod= ing for Prefix NLRIs? From: "lizhenqiang@chinamobile.com" > Date: Tuesday, September 2, 2014 at 8:41 PM To: sairay >, Hannes Gredler > Cc: "idr@ietf.org" >= , "shares@ndzh.com" >, 'John Scudder' > Subject: Re: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-i= etf-idr-ls-distribut-impl RD should be followed by the IP prefix as specified in RFC4364. Here in this draft, RD is follwed by the link state NLRI. Link state NLRI h= as its own format. See the following example, the 24-bit-long IP prefix is = far away from RD. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NLRI Type =3D 3 | Total NLRI Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Route Distinguisher + | | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | | (64 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Local Node Descriptor (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 265 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length =3D 24 | IP Prefix (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The following format for the above example is consistent with RFC4364 in my= opinion. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NLRI Type =3D 3 | Total NLRI Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | | (64 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Local Node Descriptor (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 265 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length =3D 88 | IP Prefix (variable) =3D RD followed by the 24-bit= -long prefix // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ________________________________ lizhenqiang@chinamobile.com From: Saikat Ray (sairay) Date: 2014-09-03 11:23 To: lizhenqiang@chinamobile.com; Hannes= Gredler CC: 'idr wg'; Susan Hares; 'Jo= hn G. Scudder' Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-ietf-= idr-ls-distribut-impl Sorry, I do not understand your point. In BGP-LS as well, the RD field is r= ight after the route-type and the length: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NLRI Type | Total NLRI Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Route Distinguisher + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Link-State NLRI (variable) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ From: "lizhenqiang@chinamobile.com" > Date: Tuesday, September 2, 2014 at 7:39 PM To: sairay >, Hannes Gredler > Cc: "idr@ietf.org" >= , "shares@ndzh.com" >, 'John Scudder' > Subject: Re: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-i= etf-idr-ls-distribut-impl But the postion of RD in RFC6514 is AFTER type field and length field, not = before those fields. Taken Intra-AS I-PMSI A-D Route as an example, +-----------------------------------+ | Route Type (1 octet) =3D 1 | +-----------------------------------+ | Length (1 octet) | +-----------------------------------+ | RD (8 octets) | +-----------------------------------+ | Originating Router=92s IP Addr | +-----------------------------------+ ________________________________ lizhenqiang@chinamobile.com From: Saikat Ray (sairay) Date: 2014-09-03 10:24 To: lizhenqiang@chinamobile.com; Hannes= Gredler CC: 'idr wg'; Susan Hares; 'Jo= hn G. Scudder' Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-ietf-= idr-ls-distribut-impl From: "lizhenqiang@chinamobile.com" > Date: Tuesday, September 2, 2014 at 7:18 PM To: sairay >, Hannes Gredler > Cc: "idr@ietf.org" >= , "shares@ndzh.com" >, 'John Scudder' > Subject: Re: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-i= etf-idr-ls-distribut-impl Placing the type field before the length field is fine for me. The encoding format for RD in this draft is not consistent with RFC4364. Th= is is the question. RFC6514 says "The Route Distinguisher (RD) is encoded a= s described in [RFC4364]", please see section 4 of RFC6514. [SR] That statement in RFC6514 refers to how the 8 bytes of the route-disti= nguisher field are encoded (different RD types, values, etc.), not to the p= osition of RD field in the NLRI. I agree with you for the advantage to put the RD before other fields. I rai= se this quesiton just for clarification. ________________________________ lizhenqiang@chinamobile.com From: Saikat Ray (sairay) Date: 2014-09-03 05:03 To: lizhenqiang@chinamobile.com; Hannes= Gredler CC: 'idr wg'; Susan Hares; 'Jo= hn G. Scudder' Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-ietf-= idr-ls-distribut-impl Hi Zhenqiang: For the NLRIs that uses a "type" field, such as MVPN (see RFC6514), the con= vention is to encode the type field before the length field. This allows fo= r greatest flexibility for future extensions. In BGP-LS, we have used the s= ame convention. Other than that, the RD is for the entire bgp-ls object (be it a Node, Link= or Prefix). So placing the RD field before other fields is logically accur= ate. Thanks. From: "lizhenqiang@chinamobile.com" > Date: Tuesday, September 2, 2014 at 4:21 AM To: Hannes Gredler > Cc: "idr@ietf.org" >= , "shares@ndzh.com" >, 'John Scudder' > Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-ietf-= idr-ls-distribut-impl Hi Hannes, One example to explain the differences. One VPN route with prefix length 24= is carried in the NRLI. The format this draft specified is as follows. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NLRI Type =3D 3 | Total NLRI Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Route Distinguisher + | | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | | (64 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Local Node Descriptor (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 265 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length =3D 24 | IP Prefix (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The format RFC4363 specified is as follows. +---------------------------------------------------------+ | Address Family Identifier (2 octets) | +---------------------------------------------------------+ | Subsequent Address Family Identifier (1 octet) | +---------------------------------------------------------+ | Length of Next Hop Network Address (1 octet) | +---------------------------------------------------------+ | Network Address of Next Hop (variable) | +---------------------------------------------------------+ | Reserved (1 octet) | +---------------------------------------------------------+ | Prefix Length =3D 88 | IP Prefix (variable) =3D RD followed by IP prefix= // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ ________________________________ lizhenqiang@chinamobile.com From: Hannes Gredler Date: 2014-09-02 16:35 To: lizhenqiang@chinamobile.com CC: Uma Chunduri; 'idr wg'; 'John G. Scudder'; Susan Hares Subject: Re: RE: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-i= etf-idr-ls-distribut-impl hi zhenqiang, On Tue, Sep 02, 2014 at 04:12:58PM +0800, lizhenqiang@chinamobile.com wrote: | Two types of link state NLRIs are defined in section 3.2 of this | draft, AFI 16388 / SAFI 71 for non-VPN, AFI 16388 / SAFI 128 for VPN. correct; | My question is about AFI 16388 / SAFI 128 NLRI. From the figure in pag= e 9 | of draft version 5, we can see that RD is put before link state NLRI. from http://tools.ietf.org/html/draft-ietf-idr-ls-distribution-05#section-3= .2 this is the NLRI format for AFI 16388 / SAFI 71 (unicast) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NLRI Type | Total NLRI Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Link-State NLRI (variable) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ and this is the NLRI format for AFI 16388 / SAFI 128 (VPN-unicast) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NLRI Type | Total NLRI Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Route Distinguisher + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Link-State NLRI (variable) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | The link state NLRI field in this figure contains the IP prefix. As RF= C4364 | specifies, the VPN routes should be carried in the NLRI prepending wit= h | RD. that is what we do - i fail to see the offending part with respect to RFC43= 64. /hannes | | From: [1]Hannes Gredler | Date: 2014-09-02 15:29 | To: [2]lizhenqiang@chinamobile.com; [3]Uma Chunduri | CC: [4]'idr wg'; [5]'John G. Scudder'; [6]Susan Hares | Subject: RE: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and | draft-ietf-idr-ls-distribut-impl | | hi zhenqiang, | | The Route-distinguisher's purpose is to add 64-bits of disambiguati= ng | entropy to the NLRI, such | | that the route-reflectors do not "swallow" that path as part of the | best-path election | | procedure. The link-state NLRI (encapsulated in MP_REACH/ MP UNREACH= PA) | | is a RD-less version of the vpn-link-state NLRI. | | In a certain way these correspond to RFC3107 / RFC4364 NLRI formats. | | The former is a RD-less version of the latter. | | On your question "Why do't you put RD in IP Reachability Information= , | just prepending RD with IP prefix as RFC4364 specifies." - This is | actually what we *are* doing - we put the RD before the link-state N= LRI | inside the MP_REACH/MP_UNREACH Attribute. | | HTH, | | /hannes | | ----------------------------------------------------------------------= ---- | | From: lizhenqiang@chinamobile.com > | Sent: Tuesday, September 02, 2014 8:44 | To: Hannes Gredler; Uma Chunduri | Cc: 'idr wg'; 'John G. Scudder'; Susan Hares | Subject: Re: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and | draft-ietf-idr-ls-distribut-impl | | One question about the VPN Link-State NLRI in section 3.2. Why do yo= u | put the RD before link state NRLI? Why do't you put RD in IP | Reachability Information, just preprending RD with IP prefix as RFC4= 364 | specifies. | | ----------------------------------------------------------------------= ---- | | lizhenqiang@chinamobile.com | | | From: [7]Hannes Gredler | Date: 2014-09-02 02:05 | To: [8]Uma Chunduri | CC: [9]idr@ietf.org; [10]'John G. Scudder'; [= 11]Susan Hares | Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and | draft-ietf-idr-ls-distribut-impl | hi uma, | | see comments/responses inline: | | On Wed, Aug 27, 2014 at 11:07:01AM +0000, Uma Chunduri wrote: | | Support. | | | | I see, hierarchy is WELL defined when multiple instances of = IGP | with | | multiple AFs are running. Good work. | | | | | | | | Have following Qs: | | | | 1. Any discussion of the delay introduced by BGP (packi= ng, | update | | generation, processing etc..) to transport the LS information | | | | especially, when LSDB is changing faster perhaps with large | number of | | nodes/links inside an AS and with multiple ASes) to the | controller will be | | useful. | | this is highly implementation dependent; - | some vendors do the packaging of BGP updates entirely event-driven | and others pack things up and have a worst case delay between | the trigger event and the BGP update. the protocol | itself does not prohibit/limit the propagation speed. | (in fact it can be shown that sometimes updates | travel faster on the (dataplane forwarded) iBGP mesh, | rather than propgate using the hop-by-hop control-plane flooding | protocol) | | | A note on the sensitivity of this delay to the | consumer | | (applications) at the controller can be helpful. I saw very | little | | discussion in Section 6 (6.1.5) | | difficiult - its hard to have some sort of general comment as thin= gs | are | highly implementation dependent. | | | | 2. This document encompasses pretty much both OSPF and = ISIS | | extensions done till date. How it will keep up with future | extensions in | | OSPF/ISIS. | | we have set up an IANA registries for the carriers of information. | it is expected by authors of "topological relevant" IGP extensions | to supply also BGP-LS extensions. | | | A mechanism in place would be helpful. My suggestion would be= - | the | | respective IGP documents should assess the impact and define | | | | corresponding new TLVs for BGP LS? But how this can be enforc= ed? | | i have no idea - today its entirely voluntary. | | | 3. Section 4, gives glimpse what's possible and the nod= e | aggregating | | the links obviously need to tinker the LSDB to represent the = same | | correctly. | | | | Some more details would be helpful to represent the changes o= n | | aggregation/de-aggregation subsequently. | | this may quickly get you into the "abstracted topology models" | discussion that keeps emerging periodically. - | we did not want to stop progress on the protocol by arguing | "whats the right abstraction model" and have agreed | on the minimalistic nature of the section as-is. | | | | 4. Section 6.2 has empty sub-sections and TBDs. | | right ... so suggest to remove section 6.2 altogether. | | | 5. It's good to see Implementation report shed light on | performance | | seen with multiple ASes. | | | | 6. It's good to see if any application of policy on LSD= B is | done | | (one of the primary drivers of the specification). | | | thanks, | | | /hannes | | | | | From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Ha= res | | Sent: Tuesday, August 26, 2014 11:37 AM | | To: idr@ietf.org | | Cc: 'John G. Scudder'; shares@ndzh.com | | Subject: [Idr] WG LC for draft-ietf-idr-ls-distribution and | | draft-ietf-idr-ls-distribut-impl | | | | | | | | This is a WG LC for | | | | | | | | | [1]http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/ | | | | | [2]http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution-= impl/ | | | | | | | | Please respond with comments and "support or no support." Th= is | WG LC also | | includes a request for the authors to provide IPR on the subj= ect. | | | | | | | | Please note: due to the European vacations in August, we are | bundling | | these three reviews into the next two weeks (these two drafts= and | | draft-ietf-as-migration). The chairs would like feedback (l= ist | or | | private email) whether the three WG LC s impact anyone's abil= ity | to review | | these drafts carefully. | | | | | | | | Thank you, | | | | | | | | Sue Hares and John Scudder | | | | References | | | | Visible links | | 1. | http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/ | | 2. | http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution-imp= l/ | | | _______________________________________________ | | Idr mailing list | | Idr@ietf.org | | https://www.ietf.org/mailman/listinfo/idr | | _______________________________________________ | Idr mailing list | Idr@ietf.org | https://www.ietf.org/mailman/listinfo/idr | | | References | | Visible links | 1. mailto:hannes@juniper.net | 2. mailto:lizhenqiang@chinamobile.com | 3. mailto:uma.chunduri@ericsson.com | 4. mailto:idr@ietf.org | 5. mailto:jgs@bgp.nu | 6. mailto:shares@ndzh.com | 7. mailto:hannes@juniper.net | 8. mailto:uma.chunduri@ericsson.com | 9. mailto:idr@ietf.org | 10. mailto:jgs@bgp.nu | 11. mailto:shares@ndzh.com --_000_D02BE0041FD79sairayciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <1FA3B9B29CD9DB43B469956C6756B0E5@emea.cisco.com> Content-Transfer-Encoding: quoted-printable

From: sairay <sairay@cisco.com>
Date: Tuesday, September 2, 2014 at= 8:57 PM
To: "lizhenqiang@chinamobile.com" <lizhenqiang@chinamobile.com>, Ha= nnes Gredler <hannes@juniper.net>
Cc: "idr@ietf.org" <idr@ietf.= org>, 'John Scudder' <jgs@bgp.nu>, "shares@ndzh.com" <shares@ndzh.com>
Subject: Re: [Idr] WG LC for draft-= ietf-idr-ls-distribution and draft-ietf-idr-ls-distribut-impl

Sorry, I still do not see what is the point you are trying to make. Ha= ving the RD field anywhere in the NLRI works. So there isn't any technical = issue here. BGP-LS follows the existing convention of placing the RD field

right after the NLRI type and the NLRI field.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[SR] "...right after the NLRI type and the NLRI length fields&quo= t;.

The same convention is used in RFC6514 (MVPN), = draft-ietf-l2vpn-evpn-07 (EVPN draft), to name a couple. Are you claiming t= hat RFC6514 violates RFC4364?

Also not all BGP-LS NLRIs have IP prefix (there are three types of NLR= Is: Node, Link and Prefix). Assuming that you are not asking to move the RD= field for the Node and Link NLRIs, why would you want to have a different = encoding for Prefix NLRIs?

From: "lizhenqiang@chinamobile.com" <lizhenqiang@chinamobile.com>=
Date: Tuesday, September 2, 2014 at= 8:41 PM
To: sairay <sairay@cisco.com>, Hannes Gredler <hannes@juniper.net>
Cc: "idr@ietf.org" <idr@ietf.= org>, "shares@ndzh.com&q= uot; <shares@ndzh.com>, 'John Scudder' <jgs@bgp.nu>
Subject: Re: Re: [Idr] WG LC for dr= aft-ietf-idr-ls-distribution and draft-ietf-idr-ls-distribut-impl

RD should be followed by the IP prefix as specified in RF= C4364.

Here in this draft, RD is follwed by the link state NLRI. Link state N= LRI has its own format. See the following example, the 24-bit-long IP prefi= x is far away from RD.

+-+-+-+-+-+-+-+-+-+-+-+= ;-+-+-+-+-+-+-+-+-+-+-+-+-&= #43;-+-+-+-+-+-+-+-+
 |          &nb= sp; NLRI Type =3D 3         |     T= otal NLRI Length         |
+-+-+-+-+-+-+-+-+-+-+-+= ;-+-+-+-+-+-+-+-+-+-+-+-+-&= #43;-+-+-+-+-+-+-+-+
 |          &nb= sp;            =             &nb= sp;            =             &nb= sp;  |
+           = ;            Route D= istinguisher          &nb= sp;          +
 |          &nb= sp;            =             &nb= sp;            =             &nb= sp;  |
+-+-+-= +-+-+-+-+-+ +-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+=
| Protocol-ID | 
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+ 
| Identifier | 
| (64 bits) | 
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+ 
// Local Node Descriptor (variable) // 
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+ 
| Type =3D 265   &nb= sp;                     &= nbsp;  | Length | 
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+ 
| Prefix Length =3D 24 | IP Prefix (variable) // 
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+


The following format for = the above example is consistent with RFC4364 in my opinion.
+-+-+-+-+-+-+-+-+-+-+-+= ;-+-+-+-+-+-+-+-+-+-+-+-+-&= #43;-+-+-+-+-+-+-+-+
 |          &nb= sp; NLRI Type =3D 3         |     T= otal NLRI Length         |
+-+-+-+-+-+-+-+-+-+-+-+= ;-+-+-+-+-+-+-+-+-+-+-+-+-&= #43;-+-+-+-+-+-+-+-+
| Protocol-ID | 
+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+ 
| Identifier | 
| (64 bits) | 
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+ 
// Local Node Descriptor (variable) // 
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+ 
| Type =3D 265 &nb= sp;                     &= nbsp;    | Length | 
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+ 
| Prefix Length =3D 88 | IP Prefix (variable) =3D RD followed by the 24-bit= -long prefix // 
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+

 
Date: 2014-09-03 11:23
Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-distributio= n and draft-ietf-idr-ls-distribut-impl
Sorry, I do not understand your point. In BGP-LS as well, the RD field= is right after the route-type and the length:

  +-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+
   |            NLRI Type &nbs= p;        |     Total NLRI Length   &nbs= p;     |
   +-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+
   |                =                     &nbs= p;                     &n= bsp;   |
   +               &n= bsp;       Route Distinguisher         &= nbsp;           +
   |                =                     &nbs= p;                     &n= bsp;   |
   +-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+
   |                =                     &nbs= p;                     &n= bsp;   |
   //                = ;  Link-State NLRI (variable)            = ;     //
   |                =                     &nbs= p;                     &n= bsp;   |
   +-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+

From: "lizhenqiang@chinamobile.com" <lizhenqiang@chinamobile.com>=
Date: Tuesday, September 2, 2014 at= 7:39 PM
To: sairay <sairay@cisco.com>, Hannes Gredler <hannes@juniper.net>
Cc: "idr@ietf.org" <idr@ietf.= org>, "shares@ndzh.com&q= uot; <shares@ndzh.com>, 'John Scudder' <jgs@bgp.nu>
Subject: Re: Re: [Idr] WG LC for dr= aft-ietf-idr-ls-distribution and draft-ietf-idr-ls-distribut-impl


But the postion of RD in RFC6514 is AFTER type field and length field,= not before those fields. Taken Intra-AS I-PMSI A-D Rout= e as an example,

+-----------------------------------+
| Route Type (1 octet) =3D 1  |
+-----------------------------------+
| Length (1 octet) |
+-----------------------------------+
| RD (8 octets) |
+-----------------------------------+
| Originating Router=92s IP Addr |
+-----------------------------------+

 
Date: 2014-09-03 10:24
Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-distributio= n and draft-ietf-idr-ls-distribut-impl

From: "lizhenqiang@chinamobile.com" <lizhenqiang@chinamobile.com>=
Date: Tuesday, September 2, 2014 at= 7:18 PM
To: sairay <sairay@cisco.com>, Hannes Gredler <hannes@juniper.net>
Cc: "idr@ietf.org" <idr@ietf.= org>, "shares@ndzh.com&q= uot; <shares@ndzh.com>, 'John Scudder' <jgs@bgp.nu>
Subject: Re: Re: [Idr] WG LC for dr= aft-ietf-idr-ls-distribution and draft-ietf-idr-ls-distribut-impl

Placing the type field before the length field is fine fo= r me.

The encoding format for RD in this draft is not consistent with RFC436= 4. This is the question. RFC6514 says "The Route Disting= uisher (RD) is encoded as described in [RFC4364]", please see section 4 of RFC6514.

[SR] That statement in RFC6514 refers to how the 8 bytes of the route-= distinguisher field are encoded (different RD types, values, etc.), not to = the position of RD field in the NLRI.

I agree with you for the advantage to put the RD before other fields. = I raise this quesiton just for clarification.

 
Date: 2014-09-03 05:03
Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-distributio= n and draft-ietf-idr-ls-distribut-impl
Hi Zhenqiang:=

For the NLRIs that uses a "type" field, such as MVPN (see RFC6514= ), the convention is to encode the type field before the length field. This= allows for greatest flexibility for future extensions. In BGP-LS, we have = used the same convention.

Other than that, the RD is for the entire bgp-ls object (be it a Node, Link= or Prefix). So placing the RD field before other fields is logically accur= ate.

Thanks.

From: "lizhenqiang@chinamobile.com" <lizhenqiang@chinamobile.com>=
Date: Tuesday, September 2, 2014 at= 4:21 AM
To: Hannes Gredler <hannes@juniper.net>
Cc: "idr@ietf.org" <idr@ietf.= org>, "shares@ndzh.com&q= uot; <shares@ndzh.com>, 'John Scudder' <jgs@bgp.nu>
Subject: Re: [Idr] WG LC for draft-= ietf-idr-ls-distribution and draft-ietf-idr-ls-distribut-impl

Hi Hannes,

One example to explain the differences. One VPN route with prefix leng= th 24 is carried in the NRLI.

The format this draft specified is as follows.
+-+-+-+-+-+-+-+-+-+-+-+= ;-+-+-+-+-+-+-+-+-+-+-+-+-&= #43;-+-+-+-+-+-+-+-+
 |          &nb= sp; NLRI Type =3D 3         |     T= otal NLRI Length         |
+-+-+-+-+-+-+-+-+-+-+-+= ;-+-+-+-+-+-+-+-+-+-+-+-+-&= #43;-+-+-+-+-+-+-+-+
 |          &nb= sp;            =             &nb= sp;            =             &nb= sp;  |
+           = ;            Route D= istinguisher          &nb= sp;          +
 |          &nb= sp;            =             &nb= sp;            =             &nb= sp;  |
+-+-+-= +-+-+-+-+-+ +-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+=
| Protocol-ID |
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
| Identifier |
| (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
// Local Node Descriptor (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
| Type =3D 265 &nb= sp;                     &= nbsp;    | Length |
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
| Prefix Length =3D 24 | IP Prefix (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+


The format RFC4363 specified is as follows.
+-------------= --------------------------------------------+
| Address Family Identifier (2 octets) |
+---------------------------------------------------------+
| Subsequent Address Family Identifier (1 octet) |
+---------------------------------------------------------+
| Length of Next Hop Network Address (1 octet) |
+---------------------------------------------------------+
| Network Address of Next Hop (variable) |
+---------------------------------------------------------+
| Reserved (1 octet) |
+---------------------------------------------------------+
| Prefix Length =3D 88 |  IP Prefix (variable) =3D RD followed = by IP prefix // 
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-++

 
Date: 2014-09-02 16:35
Subject: Re: RE: [Idr] WG LC for draft-ietf-idr-ls-distrib= ution and draft-ietf-idr-ls-distribut-impl
hi zhenqiang,
 
On Tue, Sep 02, 2014 at 04:12:58PM +0800, lizhenqiang@chinamobile.com wrote:
|    Two types of link state NLRIs are defined in secti= on 3.2 of this
|    draft, AFI 16388 / SAFI 71 for non-VPN, AFI 16388 = / SAFI 128 for VPN.
 
correct;
 
|    My question is about AFI 16388 / SAFI 128 NLRI. Fr= om the figure in page 9
|    of draft version 5, we can see that RD is put befo= re link state NLRI.
 
 
 
this is the NLRI format for AFI 16388 / SAFI 71 (unicast)
 
    0        &n= bsp;          1  &nb= sp;            =     2         &= nbsp;         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
   +-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+
   |         &n= bsp;  NLRI Type          = |     Total NLRI Length     &n= bsp;   |
   +-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+
   |         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;   |
   //         &= nbsp;        Link-State NLRI (variable)&= nbsp;           &nbs= p;    //
   |         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;   |
   +-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+
 
and this is the NLRI format for AFI 16388 / SAFI 128 (VPN-unicast)
 
    0        &n= bsp;          1  &nb= sp;            =     2         &= nbsp;         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
   +-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+
   |         &n= bsp;  NLRI Type          = |     Total NLRI Length     &n= bsp;   |
   +-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+
   |         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;   |
   +        &nbs= p;            &= nbsp; Route Distinguisher        &n= bsp;            += ;
   |         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;   |
   +-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+
   |         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;   |
   //         &= nbsp;        Link-State NLRI (variable)&= nbsp;           &nbs= p;    //
   |         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;   |
   +-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+
 
 
 
|    The link state NLRI field in this figure contains = the IP prefix. As RFC4364
|    specifies, the VPN routes should be carried in the= NLRI prepending with
|    RD.
 
that is what we do - i fail to see the offending part with respect to = RFC4364.
 
/hannes
 
|
|      From: [1]Hannes Gredler
|      Date: 2014-09-02 15:29
|      CC: [4]'idr wg'; [5]'John G. Scudder';= [6]Susan Hares
|      Subject: RE: Re: [Idr] WG LC for draft= -ietf-idr-ls-distribution and
|      draft-ietf-idr-ls-distribut-impl
|
|      hi zhenqiang,
|
|      The Route-distinguisher's purpose is t= o add 64-bits of  disambiguating
|      entropy to the NLRI, such
|
|      that the route-reflectors do not "= ;swallow" that path as part of the
|      best-path election
|
|      procedure. The link-state NLRI (encaps= ulated in MP_REACH/ MP UNREACH PA)
|
|      is a RD-less version of the vpn-link-s= tate NLRI.
|
|      In a certain way these correspond to R= FC3107 / RFC4364 NLRI formats.
|
|      The former is a RD-less version of the= latter.
|
|      On your question "Why do't you pu= t RD in IP Reachability Information,
|      just prepending RD with IP prefix as R= FC4364 specifies." - This is
|      actually what we *are* doing - we put = the RD before the link-state NLRI
|      inside the MP_REACH/MP_UNREACH Attribu= te.
|
|      HTH,
|
|      /hannes
|
|    --------------------------------------------------= ------------------------
|
|      Sent: Tuesday, September 02, 2014 8:44=
|      To: Hannes Gredler; Uma Chunduri
|      Cc: 'idr wg'; 'John G. Scudder'; Susan= Hares
|      Subject: Re: Re: [Idr] WG LC for draft= -ietf-idr-ls-distribution and
|      draft-ietf-idr-ls-distribut-impl
|
|      One question about the VPN Link-State = NLRI in section 3.2. Why do you
|      put the RD before link state NRLI? Why= do't you put RD in IP
|      Reachability Information, just prepren= ding RD with IP prefix as RFC4364
|      specifies.
|
|    --------------------------------------------------= ------------------------
|
|
|
|        From: [7]Hannes Gredler
|        Date: 2014-09-02 02:05
|        To: [8]Uma Chunduri
|        CC: [9]idr@ietf.org; [10]'John G. Scudder'; [11]Susan Hares
|        Subject: Re: [Idr] WG LC f= or draft-ietf-idr-ls-distribution and
|        draft-ietf-idr-ls-distribu= t-impl
|        hi uma,
|
|        see comments/responses inl= ine:
|
|        On Wed, Aug 27, 2014 at 11= :07:01AM +0000, Uma Chunduri wrote:
|        |    Suppor= t.
|        |
|        |    I see,= hierarchy is WELL  defined when multiple instances of IGP
|        with
|        |    multip= le AFs are running. Good work.
|        |
|        |
|        |
|        |    Have f= ollowing Qs:
|        |
|        |    1.&nbs= p;      Any discussion of the delay introduced by = BGP (packing,
|        update
|        |    genera= tion, processing etc..) to transport the LS information
|        |
|        |    especi= ally, when LSDB is changing faster perhaps with large
|        number of
|        |    nodes/= links inside an AS and with multiple ASes) to the
|        controller will be
|        |    useful= .
|
|        this is highly implementat= ion dependent; -
|        some vendors do the packag= ing of BGP updates entirely event-driven
|        and others pack things up = and have a worst case delay between
|        the trigger event and the = BGP update. the protocol
|        itself does not prohibit/l= imit the propagation speed.
|        (in fact it can be shown t= hat sometimes updates
|        travel faster on the (data= plane forwarded) iBGP mesh,
|        rather than propgate using= the hop-by-hop control-plane flooding
|        protocol)
|
|        |    &= nbsp;            A n= ote on the sensitivity of this delay to the
|        consumer
|        |    (appli= cations) at the controller  can be helpful. I saw very
|        little
|        |    discus= sion in Section 6 (6.1.5)
|
|        difficiult - its hard to h= ave some sort of general comment as things
|        are
|        highly implementation depe= ndent.
|
|
|        |    2.&nbs= p;      This document encompasses pretty much both= OSPF and ISIS
|        |    extens= ions done till date. How it will keep up with future
|        extensions in
|        |    OSPF/I= SIS.
|
|        we have set up an IANA reg= istries for the carriers of information.
|        it is expected by authors = of "topological relevant" IGP extensions
|        to supply also BGP-LS exte= nsions.
|
|        |    A mech= anism in place would be helpful. My suggestion would be-
|        the
|        |    respec= tive IGP documents should assess the impact and define
|        |
|        |    corres= ponding new TLVs for BGP LS? But how this can be enforced?
|
|        i have no idea - today its= entirely voluntary.
|
|        |    3.&nbs= p;      Section 4, gives glimpse what's possible a= nd the node
|        aggregating
|        |    the li= nks obviously need to tinker the LSDB to represent the same
|        |    correc= tly.
|        |
|        |    Some m= ore details would be helpful to represent the changes on
|        |    aggreg= ation/de-aggregation subsequently.
|
|        this may quickly get you i= nto the "abstracted topology models"
|        discussion that keeps emer= ging  periodically. -
|        we did not want to stop pr= ogress on the protocol by arguing
|        "whats the right abst= raction model" and have agreed
|        on the minimalistic nature= of the section as-is.
|
|
|        |    4.&nbs= p;      Section 6.2 has empty sub-sections and TBD= s.
|
|        right ... so suggest to re= move section 6.2 altogether.
|
|        |    5.&nbs= p;      It's good to see Implementation report she= d light on
|        performance
|        |    seen w= ith multiple ASes.
|        |
|        |    6.&nbs= p;      It's good to see if any application of pol= icy on LSDB is
|        done
|        |    (one o= f the primary drivers of the specification).
|
|
|        thanks,
|
|
|        /hannes
|
|        |
|        |    From: = Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
|        |    Sent: = Tuesday, August 26, 2014 11:37 AM
|        |    Cc: 'J= ohn G. Scudder'; shares@ndzh.com
|        |    Subjec= t: [Idr] WG LC for draft-ietf-idr-ls-distribution and
|        |    draft-= ietf-idr-ls-distribut-impl
|        |
|        |
|        |
|        |    This i= s a WG LC for
|        |
|        |
|        |
|        |
|        |
|        |
|        |
|        |
|        |
|        |    Please= respond with comments and "support or no support."  This
|        WG LC also
|        |    includ= es a request for the authors to provide IPR on the subject.
|        |
|        |
|        |
|        |    Please= note: due to the European vacations in August, we are
|        bundling
|        |    these = three reviews into the next two weeks (these two drafts and
|        |    draft-= ietf-as-migration).   The chairs would like feedback (list
|        or
|        |    privat= e email) whether the three WG LC s impact anyone's ability
|        to review
|        |    these = drafts carefully.
|        |
|        |
|        |
|        |    Thank = you,
|        |
|        |
|        |
|        |    Sue Ha= res and John Scudder
|        |
|        | References
|        |
|        |    Visibl= e links
|        |    1.
|        |    2.
|        http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution-impl/
|
|        | ________________________= _______________________
|        | Idr mailing list
|        | Idr@ietf.org
|
|        __________________________= _____________________
|        Idr mailing list
|        Idr@ietf.org
 --_000_D02BE0041FD79sairayciscocom_-- From nobody Tue Sep 2 23:22:00 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DDE41A7D83 for ; Tue, 2 Sep 2014 23:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.255 X-Spam-Level: X-Spam-Status: No, score=0.255 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pnljzQBHo-Ue for ; Tue, 2 Sep 2014 23:21:53 -0700 (PDT) Received: from cmccmta2.chinamobile.com (cmccmta2.chinamobile.com [221.176.66.80]) by ietfa.amsl.com (Postfix) with SMTP id E6F451A6F81 for ; Tue, 2 Sep 2014 23:21:51 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.121.5]) by rmmx-syy-dmz-app07-12007 (RichMail) with SMTP id 2ee75406b37eaf8-25c49; Wed, 03 Sep 2014 14:21:50 +0800 (CST) X-RM-TRANSID: 2ee75406b37eaf8-25c49 X-RM-SPAM-FLAG: 00000000 Received: from lizhenqiang (unknown[10.2.52.185]) by rmsmtp-syy-appsvr03-12003 (RichMail) with SMTP id 2ee35406b375629-c0429; Wed, 03 Sep 2014 14:21:50 +0800 (CST) X-RM-TRANSID: 2ee35406b375629-c0429 Date: Wed, 3 Sep 2014 14:22:03 +0800 From: "lizhenqiang@chinamobile.com" To: "Saikat Ray (sairay)" , "Hannes Gredler" References: , X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 5, 140[cn] Mime-Version: 1.0 Message-ID: <2014090314220325424041@chinamobile.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart208724880862_=----" Archived-At: http://mailarchive.ietf.org/arch/msg/idr/TGiDn3CT_gVGI2DrtfrbEur9F08 Cc: 'idr wg' , Susan Hares , "'John G. Scudder'" Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-ietf-idr-ls-distribut-impl X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 06:21:58 -0000 This is a multi-part message in MIME format. ------=_001_NextPart208724880862_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIGVuY29kaW5nIGZvcm1hdCBzcGVjaWZpZWQgYnkgdGhpcyBkcmFmdCBkb2VzIHdvcmsuIEkg dG90YWxseSBhZ3JlZS4NCg0KSSByYWlzZSB0aGlzIHF1ZXN0aW9uIGp1c3QgZm9yIGNvbnNpc3Rl bmNlIGNsYXJpZmljYXRpb24uDQoNCg0KDQpsaXpoZW5xaWFuZ0BjaGluYW1vYmlsZS5jb20NCiAN CkZyb206IFNhaWthdCBSYXkgKHNhaXJheSkNCkRhdGU6IDIwMTQtMDktMDMgMTE6NTkNClRvOiBT YWlrYXQgUmF5IChzYWlyYXkpOyBsaXpoZW5xaWFuZ0BjaGluYW1vYmlsZS5jb207IEhhbm5lcyBH cmVkbGVyDQpDQzogJ2lkciB3Zyc7ICdKb2huIEcuIFNjdWRkZXInOyBTdXNhbiBIYXJlcw0KU3Vi amVjdDogUmU6IFtJZHJdIFdHIExDIGZvciBkcmFmdC1pZXRmLWlkci1scy1kaXN0cmlidXRpb24g YW5kIGRyYWZ0LWlldGYtaWRyLWxzLWRpc3RyaWJ1dC1pbXBsDQoNCkZyb206IHNhaXJheSA8c2Fp cmF5QGNpc2NvLmNvbT4NCkRhdGU6IFR1ZXNkYXksIFNlcHRlbWJlciAyLCAyMDE0IGF0IDg6NTcg UE0NClRvOiAibGl6aGVucWlhbmdAY2hpbmFtb2JpbGUuY29tIiA8bGl6aGVucWlhbmdAY2hpbmFt b2JpbGUuY29tPiwgSGFubmVzIEdyZWRsZXIgPGhhbm5lc0BqdW5pcGVyLm5ldD4NCkNjOiAiaWRy QGlldGYub3JnIiA8aWRyQGlldGYub3JnPiwgJ0pvaG4gU2N1ZGRlcicgPGpnc0BiZ3AubnU+LCAi c2hhcmVzQG5kemguY29tIiA8c2hhcmVzQG5kemguY29tPg0KU3ViamVjdDogUmU6IFtJZHJdIFdH IExDIGZvciBkcmFmdC1pZXRmLWlkci1scy1kaXN0cmlidXRpb24gYW5kIGRyYWZ0LWlldGYtaWRy LWxzLWRpc3RyaWJ1dC1pbXBsDQoNClNvcnJ5LCBJIHN0aWxsIGRvIG5vdCBzZWUgd2hhdCBpcyB0 aGUgcG9pbnQgeW91IGFyZSB0cnlpbmcgdG8gbWFrZS4gSGF2aW5nIHRoZSBSRCBmaWVsZCBhbnl3 aGVyZSBpbiB0aGUgTkxSSSB3b3Jrcy4gU28gdGhlcmUgaXNuJ3QgYW55IHRlY2huaWNhbCBpc3N1 ZSBoZXJlLiBCR1AtTFMgZm9sbG93cyB0aGUgZXhpc3RpbmcgY29udmVudGlvbiBvZiBwbGFjaW5n IHRoZSBSRCBmaWVsZCANCg0KcmlnaHQgYWZ0ZXIgdGhlIE5MUkkgdHlwZSBhbmQgdGhlIE5MUkkg ZmllbGQuIA0KXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eDQpbU1JdICIuLi5y aWdodCBhZnRlciB0aGUgTkxSSSB0eXBlIGFuZCB0aGUgTkxSSSBsZW5ndGggZmllbGRzIi4NCg0K VGhlIHNhbWUgY29udmVudGlvbiBpcyB1c2VkIGluIFJGQzY1MTQgKE1WUE4pLCBkcmFmdC1pZXRm LWwydnBuLWV2cG4tMDcgKEVWUE4gZHJhZnQpLCB0byBuYW1lIGEgY291cGxlLiBBcmUgeW91IGNs YWltaW5nIHRoYXQgUkZDNjUxNCB2aW9sYXRlcyBSRkM0MzY0Pw0KDQpBbHNvIG5vdCBhbGwgQkdQ LUxTIE5MUklzIGhhdmUgSVAgcHJlZml4ICh0aGVyZSBhcmUgdGhyZWUgdHlwZXMgb2YgTkxSSXM6 IE5vZGUsIExpbmsgYW5kIFByZWZpeCkuIEFzc3VtaW5nIHRoYXQgeW91IGFyZSBub3QgYXNraW5n IHRvIG1vdmUgdGhlIFJEIGZpZWxkIGZvciB0aGUgTm9kZSBhbmQgTGluayBOTFJJcywgd2h5IHdv dWxkIHlvdSB3YW50IHRvIGhhdmUgYSBkaWZmZXJlbnQgZW5jb2RpbmcgZm9yIFByZWZpeCBOTFJJ cz8NCg0KRnJvbTogImxpemhlbnFpYW5nQGNoaW5hbW9iaWxlLmNvbSIgPGxpemhlbnFpYW5nQGNo aW5hbW9iaWxlLmNvbT4NCkRhdGU6IFR1ZXNkYXksIFNlcHRlbWJlciAyLCAyMDE0IGF0IDg6NDEg UE0NClRvOiBzYWlyYXkgPHNhaXJheUBjaXNjby5jb20+LCBIYW5uZXMgR3JlZGxlciA8aGFubmVz QGp1bmlwZXIubmV0Pg0KQ2M6ICJpZHJAaWV0Zi5vcmciIDxpZHJAaWV0Zi5vcmc+LCAic2hhcmVz QG5kemguY29tIiA8c2hhcmVzQG5kemguY29tPiwgJ0pvaG4gU2N1ZGRlcicgPGpnc0BiZ3AubnU+ DQpTdWJqZWN0OiBSZTogUmU6IFtJZHJdIFdHIExDIGZvciBkcmFmdC1pZXRmLWlkci1scy1kaXN0 cmlidXRpb24gYW5kIGRyYWZ0LWlldGYtaWRyLWxzLWRpc3RyaWJ1dC1pbXBsDQoNClJEIHNob3Vs ZCBiZSBmb2xsb3dlZCBieSB0aGUgSVAgcHJlZml4IGFzIHNwZWNpZmllZCBpbiBSRkM0MzY0Lg0K DQpIZXJlIGluIHRoaXMgZHJhZnQsIFJEIGlzIGZvbGx3ZWQgYnkgdGhlIGxpbmsgc3RhdGUgTkxS SS4gTGluayBzdGF0ZSBOTFJJIGhhcyBpdHMgb3duIGZvcm1hdC4gU2VlIHRoZSBmb2xsb3dpbmcg ZXhhbXBsZSwgdGhlIDI0LWJpdC1sb25nIElQIHByZWZpeCBpcyBmYXIgYXdheSBmcm9tIFJELg0K DQorLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKw0KIHwgICAgICAgICAgICBOTFJJIFR5cGUgPSAzICAgICAgICAgfCAgICAgVG90 YWwgTkxSSSBMZW5ndGggICAgICAgICB8DQorLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KIHwgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQorICAgICAgICAg ICAgICAgICAgICAgICBSb3V0ZSBEaXN0aW5ndWlzaGVyICAgICAgICAgICAgICAgICAgICAgKw0K IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB8DQorLSstKy0rLSstKy0rLSstKyArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKw0KfCBQcm90b2NvbC1JRCB8IA0KKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgDQp8IElkZW50aWZpZXIg fCANCnwgKDY0IGJpdHMpIHwgDQorLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyANCi8vIExvY2FsIE5vZGUgRGVzY3JpcHRvciAo dmFyaWFibGUpIC8vIA0KKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSsgDQp8IFR5cGUgPSAyNjUgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfCBMZW5ndGggfCANCistKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rIA0KfCBQcmVmaXggTGVuZ3RoID0gMjQgfCBJ UCBQcmVmaXggKHZhcmlhYmxlKSAvLyANCistKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQoNCg0KVGhlIGZvbGxvd2luZyBmb3Jt YXQgZm9yIHRoZSBhYm92ZSBleGFtcGxlIGlzIGNvbnNpc3RlbnQgd2l0aCBSRkM0MzY0IGluIG15 IG9waW5pb24uDQorLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKw0KIHwgICAgICAgICAgICBOTFJJIFR5cGUgPSAzICAgICAgICAg fCAgICAgVG90YWwgTkxSSSBMZW5ndGggICAgICAgICB8DQorLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KfCBQcm90b2NvbC1J RCB8IA0KKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSsgDQp8IElkZW50aWZpZXIgfCANCnwgKDY0IGJpdHMpIHwgDQorLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst KyANCi8vIExvY2FsIE5vZGUgRGVzY3JpcHRvciAodmFyaWFibGUpIC8vIA0KKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgDQp8 IFR5cGUgPSAyNjUgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCBMZW5ndGggfCANCistKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rIA0KfCBQcmVmaXggTGVuZ3RoID0gODggfCBJUCBQcmVmaXggKHZhcmlhYmxlKSA9IFJEIGZv bGxvd2VkIGJ5IHRoZSAyNC1iaXQtbG9uZyBwcmVmaXggLy8gDQorLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KDQoNCg0KbGl6 aGVucWlhbmdAY2hpbmFtb2JpbGUuY29tDQogDQpGcm9tOiBTYWlrYXQgUmF5IChzYWlyYXkpDQpE YXRlOiAyMDE0LTA5LTAzIDExOjIzDQpUbzogbGl6aGVucWlhbmdAY2hpbmFtb2JpbGUuY29tOyBI YW5uZXMgR3JlZGxlcg0KQ0M6ICdpZHIgd2cnOyBTdXNhbiBIYXJlczsgJ0pvaG4gRy4gU2N1ZGRl cicNClN1YmplY3Q6IFJlOiBbSWRyXSBXRyBMQyBmb3IgZHJhZnQtaWV0Zi1pZHItbHMtZGlzdHJp YnV0aW9uIGFuZCBkcmFmdC1pZXRmLWlkci1scy1kaXN0cmlidXQtaW1wbA0KU29ycnksIEkgZG8g bm90IHVuZGVyc3RhbmQgeW91ciBwb2ludC4gSW4gQkdQLUxTIGFzIHdlbGwsIHRoZSBSRCBmaWVs ZCBpcyByaWdodCBhZnRlciB0aGUgcm91dGUtdHlwZSBhbmQgdGhlIGxlbmd0aDoNCg0KICArLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKw0KICAgfCAgICAgICAgICAgIE5MUkkgVHlwZSAgICAgICAgICB8ICAgICBUb3RhbCBOTFJJ IExlbmd0aCAgICAgICAgIHwNCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICB8ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgKyAgICAgICAg ICAgICAgICAgICAgICAgUm91dGUgRGlzdGluZ3Vpc2hlciAgICAgICAgICAgICAgICAgICAgICsN CiAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8DQogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgIC8vICAgICAgICAgICAg ICAgICAgTGluay1TdGF0ZSBOTFJJICh2YXJpYWJsZSkgICAgICAgICAgICAgICAgIC8vDQogICB8 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfA0KICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSsNCg0KRnJvbTogImxpemhlbnFpYW5nQGNoaW5hbW9iaWxlLmNv bSIgPGxpemhlbnFpYW5nQGNoaW5hbW9iaWxlLmNvbT4NCkRhdGU6IFR1ZXNkYXksIFNlcHRlbWJl ciAyLCAyMDE0IGF0IDc6MzkgUE0NClRvOiBzYWlyYXkgPHNhaXJheUBjaXNjby5jb20+LCBIYW5u ZXMgR3JlZGxlciA8aGFubmVzQGp1bmlwZXIubmV0Pg0KQ2M6ICJpZHJAaWV0Zi5vcmciIDxpZHJA aWV0Zi5vcmc+LCAic2hhcmVzQG5kemguY29tIiA8c2hhcmVzQG5kemguY29tPiwgJ0pvaG4gU2N1 ZGRlcicgPGpnc0BiZ3AubnU+DQpTdWJqZWN0OiBSZTogUmU6IFtJZHJdIFdHIExDIGZvciBkcmFm dC1pZXRmLWlkci1scy1kaXN0cmlidXRpb24gYW5kIGRyYWZ0LWlldGYtaWRyLWxzLWRpc3RyaWJ1 dC1pbXBsDQoNCg0KQnV0IHRoZSBwb3N0aW9uIG9mIFJEIGluIFJGQzY1MTQgaXMgQUZURVIgdHlw ZSBmaWVsZCBhbmQgbGVuZ3RoIGZpZWxkLCBub3QgYmVmb3JlIHRob3NlIGZpZWxkcy4gVGFrZW4g SW50cmEtQVMgSS1QTVNJIEEtRCBSb3V0ZSBhcyBhbiBleGFtcGxlLA0KDQorLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rIA0KfCBSb3V0ZSBUeXBlICgxIG9jdGV0KSA9IDEgIHwg DQorLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rIA0KfCBMZW5ndGggKDEgb2N0 ZXQpIHwgDQorLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rIA0KfCBSRCAoOCBv Y3RldHMpIHwgDQorLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rIA0KfCBPcmln aW5hdGluZyBSb3V0ZXLigJlzIElQIEFkZHIgfCANCistLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSsNCg0KDQoNCmxpemhlbnFpYW5nQGNoaW5hbW9iaWxlLmNvbQ0KIA0KRnJvbTog U2Fpa2F0IFJheSAoc2FpcmF5KQ0KRGF0ZTogMjAxNC0wOS0wMyAxMDoyNA0KVG86IGxpemhlbnFp YW5nQGNoaW5hbW9iaWxlLmNvbTsgSGFubmVzIEdyZWRsZXINCkNDOiAnaWRyIHdnJzsgU3VzYW4g SGFyZXM7ICdKb2huIEcuIFNjdWRkZXInDQpTdWJqZWN0OiBSZTogW0lkcl0gV0cgTEMgZm9yIGRy YWZ0LWlldGYtaWRyLWxzLWRpc3RyaWJ1dGlvbiBhbmQgZHJhZnQtaWV0Zi1pZHItbHMtZGlzdHJp YnV0LWltcGwNCg0KRnJvbTogImxpemhlbnFpYW5nQGNoaW5hbW9iaWxlLmNvbSIgPGxpemhlbnFp YW5nQGNoaW5hbW9iaWxlLmNvbT4NCkRhdGU6IFR1ZXNkYXksIFNlcHRlbWJlciAyLCAyMDE0IGF0 IDc6MTggUE0NClRvOiBzYWlyYXkgPHNhaXJheUBjaXNjby5jb20+LCBIYW5uZXMgR3JlZGxlciA8 aGFubmVzQGp1bmlwZXIubmV0Pg0KQ2M6ICJpZHJAaWV0Zi5vcmciIDxpZHJAaWV0Zi5vcmc+LCAi c2hhcmVzQG5kemguY29tIiA8c2hhcmVzQG5kemguY29tPiwgJ0pvaG4gU2N1ZGRlcicgPGpnc0Bi Z3AubnU+DQpTdWJqZWN0OiBSZTogUmU6IFtJZHJdIFdHIExDIGZvciBkcmFmdC1pZXRmLWlkci1s cy1kaXN0cmlidXRpb24gYW5kIGRyYWZ0LWlldGYtaWRyLWxzLWRpc3RyaWJ1dC1pbXBsDQoNClBs YWNpbmcgdGhlIHR5cGUgZmllbGQgYmVmb3JlIHRoZSBsZW5ndGggZmllbGQgaXMgZmluZSBmb3Ig bWUuDQoNClRoZSBlbmNvZGluZyBmb3JtYXQgZm9yIFJEIGluIHRoaXMgZHJhZnQgaXMgbm90IGNv bnNpc3RlbnQgd2l0aCBSRkM0MzY0LiBUaGlzIGlzIHRoZSBxdWVzdGlvbi4gUkZDNjUxNCBzYXlz ICJUaGUgUm91dGUgRGlzdGluZ3Vpc2hlciAoUkQpIGlzIGVuY29kZWQgYXMgZGVzY3JpYmVkIGlu IFtSRkM0MzY0XSIsIHBsZWFzZSBzZWUgc2VjdGlvbiA0IG9mIFJGQzY1MTQuDQoNCltTUl0gVGhh dCBzdGF0ZW1lbnQgaW4gUkZDNjUxNCByZWZlcnMgdG8gaG93IHRoZSA4IGJ5dGVzIG9mIHRoZSBy b3V0ZS1kaXN0aW5ndWlzaGVyIGZpZWxkIGFyZSBlbmNvZGVkIChkaWZmZXJlbnQgUkQgdHlwZXMs IHZhbHVlcywgZXRjLiksIG5vdCB0byB0aGUgcG9zaXRpb24gb2YgUkQgZmllbGQgaW4gdGhlIE5M UkkuDQoNCkkgYWdyZWUgd2l0aCB5b3UgZm9yIHRoZSBhZHZhbnRhZ2UgdG8gcHV0IHRoZSBSRCBi ZWZvcmUgb3RoZXIgZmllbGRzLiBJIHJhaXNlIHRoaXMgcXVlc2l0b24ganVzdCBmb3IgY2xhcmlm aWNhdGlvbi4NCg0KDQoNCmxpemhlbnFpYW5nQGNoaW5hbW9iaWxlLmNvbQ0KIA0KRnJvbTogU2Fp a2F0IFJheSAoc2FpcmF5KQ0KRGF0ZTogMjAxNC0wOS0wMyAwNTowMw0KVG86IGxpemhlbnFpYW5n QGNoaW5hbW9iaWxlLmNvbTsgSGFubmVzIEdyZWRsZXINCkNDOiAnaWRyIHdnJzsgU3VzYW4gSGFy ZXM7ICdKb2huIEcuIFNjdWRkZXInDQpTdWJqZWN0OiBSZTogW0lkcl0gV0cgTEMgZm9yIGRyYWZ0 LWlldGYtaWRyLWxzLWRpc3RyaWJ1dGlvbiBhbmQgZHJhZnQtaWV0Zi1pZHItbHMtZGlzdHJpYnV0 LWltcGwNCkhpIFpoZW5xaWFuZzoNCg0KRm9yIHRoZSBOTFJJcyB0aGF0IHVzZXMgYSAidHlwZSIg ZmllbGQsIHN1Y2ggYXMgTVZQTiAoc2VlIFJGQzY1MTQpLCB0aGUgY29udmVudGlvbiBpcyB0byBl bmNvZGUgdGhlIHR5cGUgZmllbGQgYmVmb3JlIHRoZSBsZW5ndGggZmllbGQuIFRoaXMgYWxsb3dz IGZvciBncmVhdGVzdCBmbGV4aWJpbGl0eSBmb3IgZnV0dXJlIGV4dGVuc2lvbnMuIEluIEJHUC1M Uywgd2UgaGF2ZSB1c2VkIHRoZSBzYW1lIGNvbnZlbnRpb24uDQoNCk90aGVyIHRoYW4gdGhhdCwg dGhlIFJEIGlzIGZvciB0aGUgZW50aXJlIGJncC1scyBvYmplY3QgKGJlIGl0IGEgTm9kZSwgTGlu ayBvciBQcmVmaXgpLiBTbyBwbGFjaW5nIHRoZSBSRCBmaWVsZCBiZWZvcmUgb3RoZXIgZmllbGRz IGlzIGxvZ2ljYWxseSBhY2N1cmF0ZS4NCg0KVGhhbmtzLg0KDQpGcm9tOiAibGl6aGVucWlhbmdA Y2hpbmFtb2JpbGUuY29tIiA8bGl6aGVucWlhbmdAY2hpbmFtb2JpbGUuY29tPg0KRGF0ZTogVHVl c2RheSwgU2VwdGVtYmVyIDIsIDIwMTQgYXQgNDoyMSBBTQ0KVG86IEhhbm5lcyBHcmVkbGVyIDxo YW5uZXNAanVuaXBlci5uZXQ+DQpDYzogImlkckBpZXRmLm9yZyIgPGlkckBpZXRmLm9yZz4sICJz aGFyZXNAbmR6aC5jb20iIDxzaGFyZXNAbmR6aC5jb20+LCAnSm9obiBTY3VkZGVyJyA8amdzQGJn cC5udT4NClN1YmplY3Q6IFJlOiBbSWRyXSBXRyBMQyBmb3IgZHJhZnQtaWV0Zi1pZHItbHMtZGlz dHJpYnV0aW9uIGFuZCBkcmFmdC1pZXRmLWlkci1scy1kaXN0cmlidXQtaW1wbA0KDQpIaSBIYW5u ZXMsDQoNCk9uZSBleGFtcGxlIHRvIGV4cGxhaW4gdGhlIGRpZmZlcmVuY2VzLiBPbmUgVlBOIHJv dXRlIHdpdGggcHJlZml4IGxlbmd0aCAyNCBpcyBjYXJyaWVkIGluIHRoZSBOUkxJLg0KDQpUaGUg Zm9ybWF0IHRoaXMgZHJhZnQgc3BlY2lmaWVkIGlzIGFzIGZvbGxvd3MuDQorLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KIHwg ICAgICAgICAgICBOTFJJIFR5cGUgPSAzICAgICAgICAgfCAgICAgVG90YWwgTkxSSSBMZW5ndGgg ICAgICAgICB8DQorLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKw0KIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQorICAgICAgICAgICAgICAgICAgICAgICBS b3V0ZSBEaXN0aW5ndWlzaGVyICAgICAgICAgICAgICAgICAgICAgKw0KIHwgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQorLSst Ky0rLSstKy0rLSstKyArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0K fCBQcm90b2NvbC1JRCB8IA0KKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgDQp8IElkZW50aWZpZXIgfCANCnwgKDY0IGJpdHMp IHwgDQorLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKyANCi8vIExvY2FsIE5vZGUgRGVzY3JpcHRvciAodmFyaWFibGUpIC8vIA0K Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSsgDQp8IFR5cGUgPSAyNjUgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCBMZW5n dGggfCANCistKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rIA0KfCBQcmVmaXggTGVuZ3RoID0gMjQgfCBJUCBQcmVmaXggKHZhcmlh YmxlKSAvLyANCistKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rDQoNCg0KVGhlIGZvcm1hdCBSRkM0MzYzIHNwZWNpZmllZCBpcyBh cyBmb2xsb3dzLg0KKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLSsgDQp8IEFkZHJlc3MgRmFtaWx5IElkZW50aWZpZXIgKDIgb2N0ZXRzKSB8 IA0KKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSsgDQp8IFN1YnNlcXVlbnQgQWRkcmVzcyBGYW1pbHkgSWRlbnRpZmllciAoMSBvY3RldCkg fCANCistLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0rIA0KfCBMZW5ndGggb2YgTmV4dCBIb3AgTmV0d29yayBBZGRyZXNzICgxIG9jdGV0KSB8 IA0KKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSsgDQp8IE5ldHdvcmsgQWRkcmVzcyBvZiBOZXh0IEhvcCAodmFyaWFibGUpIHwgDQorLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKyAN CnwgUmVzZXJ2ZWQgKDEgb2N0ZXQpIHwgDQorLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKyANCnwgUHJlZml4IExlbmd0aCA9IDg4IHwgIElQ IFByZWZpeCAodmFyaWFibGUpID0gUkQgZm9sbG93ZWQgYnkgSVAgcHJlZml4IC8vIA0KKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSsrDQoNCg0KDQpsaXpoZW5xaWFuZ0BjaGluYW1vYmlsZS5jb20NCiANCkZyb206IEhhbm5lcyBH cmVkbGVyDQpEYXRlOiAyMDE0LTA5LTAyIDE2OjM1DQpUbzogbGl6aGVucWlhbmdAY2hpbmFtb2Jp bGUuY29tDQpDQzogVW1hIENodW5kdXJpOyAnaWRyIHdnJzsgJ0pvaG4gRy4gU2N1ZGRlcic7IFN1 c2FuIEhhcmVzDQpTdWJqZWN0OiBSZTogUkU6IFtJZHJdIFdHIExDIGZvciBkcmFmdC1pZXRmLWlk ci1scy1kaXN0cmlidXRpb24gYW5kIGRyYWZ0LWlldGYtaWRyLWxzLWRpc3RyaWJ1dC1pbXBsDQpo aSB6aGVucWlhbmcsDQogDQpPbiBUdWUsIFNlcCAwMiwgMjAxNCBhdCAwNDoxMjo1OFBNICswODAw LCBsaXpoZW5xaWFuZ0BjaGluYW1vYmlsZS5jb20gd3JvdGU6DQp8ICAgIFR3byB0eXBlcyBvZiBs aW5rIHN0YXRlIE5MUklzIGFyZSBkZWZpbmVkIGluIHNlY3Rpb24gMy4yIG9mIHRoaXMNCnwgICAg ZHJhZnQsIEFGSSAxNjM4OCAvIFNBRkkgNzEgZm9yIG5vbi1WUE4sIEFGSSAxNjM4OCAvIFNBRkkg MTI4IGZvciBWUE4uDQogDQpjb3JyZWN0Ow0KIA0KfCAgICBNeSBxdWVzdGlvbiBpcyBhYm91dCBB RkkgMTYzODggLyBTQUZJIDEyOCBOTFJJLiBGcm9tIHRoZSBmaWd1cmUgaW4gcGFnZSA5DQp8ICAg IG9mIGRyYWZ0IHZlcnNpb24gNSwgd2UgY2FuIHNlZSB0aGF0IFJEIGlzIHB1dCBiZWZvcmUgbGlu ayBzdGF0ZSBOTFJJLg0KIA0KIA0KZnJvbSBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLWlkci1scy1kaXN0cmlidXRpb24tMDUjc2VjdGlvbi0zLjINCiANCnRoaXMgaXMgdGhl IE5MUkkgZm9ybWF0IGZvciBBRkkgMTYzODggLyBTQUZJIDcxICh1bmljYXN0KQ0KIA0KICAgIDAg ICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAg IDMNCiAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0 IDUgNiA3IDggOSAwIDENCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICB8ICAgICAgICAgICAgTkxSSSBUeXBlICAg ICAgICAgIHwgICAgIFRvdGFsIE5MUkkgTGVuZ3RoICAgICAgICAgfA0KICAgKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAg IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB8DQogICAvLyAgICAgICAgICAgICAgICAgIExpbmstU3RhdGUgTkxSSSAodmFyaWFi bGUpICAgICAgICAgICAgICAgICAvLw0KICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogDQphbmQg dGhpcyBpcyB0aGUgTkxSSSBmb3JtYXQgZm9yIEFGSSAxNjM4OCAvIFNBRkkgMTI4IChWUE4tdW5p Y2FzdCkNCiANCiAgICAwICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAgMiAg ICAgICAgICAgICAgICAgICAzDQogICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2 IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxDQogICArLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgfCAgICAgICAg ICAgIE5MUkkgVHlwZSAgICAgICAgICB8ICAgICBUb3RhbCBOTFJJIExlbmd0aCAgICAgICAgIHwN CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rDQogICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgKyAgICAgICAgICAgICAgICAgICAgICAgUm91 dGUgRGlzdGluZ3Vpc2hlciAgICAgICAgICAgICAgICAgICAgICsNCiAgIHwgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAr LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKw0KICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHwNCiAgIC8vICAgICAgICAgICAgICAgICAgTGluay1TdGF0ZSBO TFJJICh2YXJpYWJsZSkgICAgICAgICAgICAgICAgIC8vDQogICB8ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSsNCiANCiANCiANCnwgICAgVGhlIGxpbmsgc3RhdGUgTkxSSSBmaWVsZCBpbiB0aGlzIGZpZ3Vy ZSBjb250YWlucyB0aGUgSVAgcHJlZml4LiBBcyBSRkM0MzY0DQp8ICAgIHNwZWNpZmllcywgdGhl IFZQTiByb3V0ZXMgc2hvdWxkIGJlIGNhcnJpZWQgaW4gdGhlIE5MUkkgcHJlcGVuZGluZyB3aXRo DQp8ICAgIFJELg0KIA0KdGhhdCBpcyB3aGF0IHdlIGRvIC0gaSBmYWlsIHRvIHNlZSB0aGUgb2Zm ZW5kaW5nIHBhcnQgd2l0aCByZXNwZWN0IHRvIFJGQzQzNjQuDQogDQovaGFubmVzDQogDQp8IA0K fCAgICAgIEZyb206IFsxXUhhbm5lcyBHcmVkbGVyDQp8ICAgICAgRGF0ZTogMjAxNC0wOS0wMiAx NToyOQ0KfCAgICAgIFRvOiBbMl1saXpoZW5xaWFuZ0BjaGluYW1vYmlsZS5jb207IFszXVVtYSBD aHVuZHVyaQ0KfCAgICAgIENDOiBbNF0naWRyIHdnJzsgWzVdJ0pvaG4gRy4gU2N1ZGRlcic7IFs2 XVN1c2FuIEhhcmVzDQp8ICAgICAgU3ViamVjdDogUkU6IFJlOiBbSWRyXSBXRyBMQyBmb3IgZHJh ZnQtaWV0Zi1pZHItbHMtZGlzdHJpYnV0aW9uIGFuZA0KfCAgICAgIGRyYWZ0LWlldGYtaWRyLWxz LWRpc3RyaWJ1dC1pbXBsDQp8IA0KfCAgICAgIGhpIHpoZW5xaWFuZywNCnwgDQp8ICAgICAgVGhl IFJvdXRlLWRpc3Rpbmd1aXNoZXIncyBwdXJwb3NlIGlzIHRvIGFkZCA2NC1iaXRzIG9mICBkaXNh bWJpZ3VhdGluZw0KfCAgICAgIGVudHJvcHkgdG8gdGhlIE5MUkksIHN1Y2gNCnwgDQp8ICAgICAg dGhhdCB0aGUgcm91dGUtcmVmbGVjdG9ycyBkbyBub3QgInN3YWxsb3ciIHRoYXQgcGF0aCBhcyBw YXJ0IG9mIHRoZQ0KfCAgICAgIGJlc3QtcGF0aCBlbGVjdGlvbg0KfCANCnwgICAgICBwcm9jZWR1 cmUuIFRoZSBsaW5rLXN0YXRlIE5MUkkgKGVuY2Fwc3VsYXRlZCBpbiBNUF9SRUFDSC8gTVAgVU5S RUFDSCBQQSkNCnwgDQp8ICAgICAgaXMgYSBSRC1sZXNzIHZlcnNpb24gb2YgdGhlIHZwbi1saW5r LXN0YXRlIE5MUkkuDQp8IA0KfCAgICAgIEluIGEgY2VydGFpbiB3YXkgdGhlc2UgY29ycmVzcG9u ZCB0byBSRkMzMTA3IC8gUkZDNDM2NCBOTFJJIGZvcm1hdHMuDQp8IA0KfCAgICAgIFRoZSBmb3Jt ZXIgaXMgYSBSRC1sZXNzIHZlcnNpb24gb2YgdGhlIGxhdHRlci4NCnwgDQp8ICAgICAgT24geW91 ciBxdWVzdGlvbiAiV2h5IGRvJ3QgeW91IHB1dCBSRCBpbiBJUCBSZWFjaGFiaWxpdHkgSW5mb3Jt YXRpb24sDQp8ICAgICAganVzdCBwcmVwZW5kaW5nIFJEIHdpdGggSVAgcHJlZml4IGFzIFJGQzQz NjQgc3BlY2lmaWVzLiIgLSBUaGlzIGlzDQp8ICAgICAgYWN0dWFsbHkgd2hhdCB3ZSAqYXJlKiBk b2luZyAtIHdlIHB1dCB0aGUgUkQgYmVmb3JlIHRoZSBsaW5rLXN0YXRlIE5MUkkNCnwgICAgICBp bnNpZGUgdGhlIE1QX1JFQUNIL01QX1VOUkVBQ0ggQXR0cmlidXRlLg0KfCANCnwgICAgICBIVEgs DQp8IA0KfCAgICAgIC9oYW5uZXMNCnwgDQp8ICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQp8IA0KfCAg ICAgIEZyb206IGxpemhlbnFpYW5nQGNoaW5hbW9iaWxlLmNvbSA8bGl6aGVucWlhbmdAY2hpbmFt b2JpbGUuY29tPg0KfCAgICAgIFNlbnQ6IFR1ZXNkYXksIFNlcHRlbWJlciAwMiwgMjAxNCA4OjQ0 DQp8ICAgICAgVG86IEhhbm5lcyBHcmVkbGVyOyBVbWEgQ2h1bmR1cmkNCnwgICAgICBDYzogJ2lk ciB3Zyc7ICdKb2huIEcuIFNjdWRkZXInOyBTdXNhbiBIYXJlcw0KfCAgICAgIFN1YmplY3Q6IFJl OiBSZTogW0lkcl0gV0cgTEMgZm9yIGRyYWZ0LWlldGYtaWRyLWxzLWRpc3RyaWJ1dGlvbiBhbmQN CnwgICAgICBkcmFmdC1pZXRmLWlkci1scy1kaXN0cmlidXQtaW1wbA0KfCANCnwgICAgICBPbmUg cXVlc3Rpb24gYWJvdXQgdGhlIFZQTiBMaW5rLVN0YXRlIE5MUkkgaW4gc2VjdGlvbiAzLjIuIFdo eSBkbyB5b3UNCnwgICAgICBwdXQgdGhlIFJEIGJlZm9yZSBsaW5rIHN0YXRlIE5STEk/IFdoeSBk byd0IHlvdSBwdXQgUkQgaW4gSVANCnwgICAgICBSZWFjaGFiaWxpdHkgSW5mb3JtYXRpb24sIGp1 c3QgcHJlcHJlbmRpbmcgUkQgd2l0aCBJUCBwcmVmaXggYXMgUkZDNDM2NA0KfCAgICAgIHNwZWNp Zmllcy4NCnwgDQp8ICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQp8IA0KfCAgICAgIGxpemhlbnFpYW5n QGNoaW5hbW9iaWxlLmNvbQ0KfCANCnwgDQp8ICAgICAgICBGcm9tOiBbN11IYW5uZXMgR3JlZGxl cg0KfCAgICAgICAgRGF0ZTogMjAxNC0wOS0wMiAwMjowNQ0KfCAgICAgICAgVG86IFs4XVVtYSBD aHVuZHVyaQ0KfCAgICAgICAgQ0M6IFs5XWlkckBpZXRmLm9yZzsgWzEwXSdKb2huIEcuIFNjdWRk ZXInOyBbMTFdU3VzYW4gSGFyZXMNCnwgICAgICAgIFN1YmplY3Q6IFJlOiBbSWRyXSBXRyBMQyBm b3IgZHJhZnQtaWV0Zi1pZHItbHMtZGlzdHJpYnV0aW9uIGFuZA0KfCAgICAgICAgZHJhZnQtaWV0 Zi1pZHItbHMtZGlzdHJpYnV0LWltcGwNCnwgICAgICAgIGhpIHVtYSwNCnwgDQp8ICAgICAgICBz ZWUgY29tbWVudHMvcmVzcG9uc2VzIGlubGluZToNCnwgDQp8ICAgICAgICBPbiBXZWQsIEF1ZyAy NywgMjAxNCBhdCAxMTowNzowMUFNICswMDAwLCBVbWEgQ2h1bmR1cmkgd3JvdGU6DQp8ICAgICAg ICB8ICAgIFN1cHBvcnQuDQp8ICAgICAgICB8DQp8ICAgICAgICB8ICAgIEkgc2VlLCBoaWVyYXJj aHkgaXMgV0VMTCAgZGVmaW5lZCB3aGVuIG11bHRpcGxlIGluc3RhbmNlcyBvZiBJR1ANCnwgICAg ICAgIHdpdGgNCnwgICAgICAgIHwgICAgbXVsdGlwbGUgQUZzIGFyZSBydW5uaW5nLiBHb29kIHdv cmsuDQp8ICAgICAgICB8DQp8ICAgICAgICB8DQp8ICAgICAgICB8DQp8ICAgICAgICB8ICAgIEhh dmUgZm9sbG93aW5nIFFzOg0KfCAgICAgICAgfA0KfCAgICAgICAgfCAgICAxLiAgICAgICBBbnkg ZGlzY3Vzc2lvbiBvZiB0aGUgZGVsYXkgaW50cm9kdWNlZCBieSBCR1AgKHBhY2tpbmcsDQp8ICAg ICAgICB1cGRhdGUNCnwgICAgICAgIHwgICAgZ2VuZXJhdGlvbiwgcHJvY2Vzc2luZyBldGMuLikg dG8gdHJhbnNwb3J0IHRoZSBMUyBpbmZvcm1hdGlvbg0KfCAgICAgICAgfA0KfCAgICAgICAgfCAg ICBlc3BlY2lhbGx5LCB3aGVuIExTREIgaXMgY2hhbmdpbmcgZmFzdGVyIHBlcmhhcHMgd2l0aCBs YXJnZQ0KfCAgICAgICAgbnVtYmVyIG9mDQp8ICAgICAgICB8ICAgIG5vZGVzL2xpbmtzIGluc2lk ZSBhbiBBUyBhbmQgd2l0aCBtdWx0aXBsZSBBU2VzKSB0byB0aGUNCnwgICAgICAgIGNvbnRyb2xs ZXIgd2lsbCBiZQ0KfCAgICAgICAgfCAgICB1c2VmdWwuDQp8IA0KfCAgICAgICAgdGhpcyBpcyBo aWdobHkgaW1wbGVtZW50YXRpb24gZGVwZW5kZW50OyAtDQp8ICAgICAgICBzb21lIHZlbmRvcnMg ZG8gdGhlIHBhY2thZ2luZyBvZiBCR1AgdXBkYXRlcyBlbnRpcmVseSBldmVudC1kcml2ZW4NCnwg ICAgICAgIGFuZCBvdGhlcnMgcGFjayB0aGluZ3MgdXAgYW5kIGhhdmUgYSB3b3JzdCBjYXNlIGRl bGF5IGJldHdlZW4NCnwgICAgICAgIHRoZSB0cmlnZ2VyIGV2ZW50IGFuZCB0aGUgQkdQIHVwZGF0 ZS4gdGhlIHByb3RvY29sDQp8ICAgICAgICBpdHNlbGYgZG9lcyBub3QgcHJvaGliaXQvbGltaXQg dGhlIHByb3BhZ2F0aW9uIHNwZWVkLg0KfCAgICAgICAgKGluIGZhY3QgaXQgY2FuIGJlIHNob3du IHRoYXQgc29tZXRpbWVzIHVwZGF0ZXMNCnwgICAgICAgIHRyYXZlbCBmYXN0ZXIgb24gdGhlIChk YXRhcGxhbmUgZm9yd2FyZGVkKSBpQkdQIG1lc2gsDQp8ICAgICAgICByYXRoZXIgdGhhbiBwcm9w Z2F0ZSB1c2luZyB0aGUgaG9wLWJ5LWhvcCBjb250cm9sLXBsYW5lIGZsb29kaW5nDQp8ICAgICAg ICBwcm90b2NvbCkNCnwgDQp8ICAgICAgICB8ICAgICAgICAgICAgICAgICBBIG5vdGUgb24gdGhl IHNlbnNpdGl2aXR5IG9mIHRoaXMgZGVsYXkgdG8gdGhlDQp8ICAgICAgICBjb25zdW1lcg0KfCAg ICAgICAgfCAgICAoYXBwbGljYXRpb25zKSBhdCB0aGUgY29udHJvbGxlciAgY2FuIGJlIGhlbHBm dWwuIEkgc2F3IHZlcnkNCnwgICAgICAgIGxpdHRsZQ0KfCAgICAgICAgfCAgICBkaXNjdXNzaW9u IGluIFNlY3Rpb24gNiAoNi4xLjUpDQp8IA0KfCAgICAgICAgZGlmZmljaXVsdCAtIGl0cyBoYXJk IHRvIGhhdmUgc29tZSBzb3J0IG9mIGdlbmVyYWwgY29tbWVudCBhcyB0aGluZ3MNCnwgICAgICAg IGFyZQ0KfCAgICAgICAgaGlnaGx5IGltcGxlbWVudGF0aW9uIGRlcGVuZGVudC4NCnwgDQp8IA0K fCAgICAgICAgfCAgICAyLiAgICAgICBUaGlzIGRvY3VtZW50IGVuY29tcGFzc2VzIHByZXR0eSBt dWNoIGJvdGggT1NQRiBhbmQgSVNJUw0KfCAgICAgICAgfCAgICBleHRlbnNpb25zIGRvbmUgdGls bCBkYXRlLiBIb3cgaXQgd2lsbCBrZWVwIHVwIHdpdGggZnV0dXJlDQp8ICAgICAgICBleHRlbnNp b25zIGluDQp8ICAgICAgICB8ICAgIE9TUEYvSVNJUy4NCnwgDQp8ICAgICAgICB3ZSBoYXZlIHNl dCB1cCBhbiBJQU5BIHJlZ2lzdHJpZXMgZm9yIHRoZSBjYXJyaWVycyBvZiBpbmZvcm1hdGlvbi4N CnwgICAgICAgIGl0IGlzIGV4cGVjdGVkIGJ5IGF1dGhvcnMgb2YgInRvcG9sb2dpY2FsIHJlbGV2 YW50IiBJR1AgZXh0ZW5zaW9ucw0KfCAgICAgICAgdG8gc3VwcGx5IGFsc28gQkdQLUxTIGV4dGVu c2lvbnMuDQp8IA0KfCAgICAgICAgfCAgICBBIG1lY2hhbmlzbSBpbiBwbGFjZSB3b3VsZCBiZSBo ZWxwZnVsLiBNeSBzdWdnZXN0aW9uIHdvdWxkIGJlLQ0KfCAgICAgICAgdGhlDQp8ICAgICAgICB8 ICAgIHJlc3BlY3RpdmUgSUdQIGRvY3VtZW50cyBzaG91bGQgYXNzZXNzIHRoZSBpbXBhY3QgYW5k IGRlZmluZQ0KfCAgICAgICAgfA0KfCAgICAgICAgfCAgICBjb3JyZXNwb25kaW5nIG5ldyBUTFZz IGZvciBCR1AgTFM/IEJ1dCBob3cgdGhpcyBjYW4gYmUgZW5mb3JjZWQ/DQp8IA0KfCAgICAgICAg aSBoYXZlIG5vIGlkZWEgLSB0b2RheSBpdHMgZW50aXJlbHkgdm9sdW50YXJ5Lg0KfCANCnwgICAg ICAgIHwgICAgMy4gICAgICAgU2VjdGlvbiA0LCBnaXZlcyBnbGltcHNlIHdoYXQncyBwb3NzaWJs ZSBhbmQgdGhlIG5vZGUNCnwgICAgICAgIGFnZ3JlZ2F0aW5nDQp8ICAgICAgICB8ICAgIHRoZSBs aW5rcyBvYnZpb3VzbHkgbmVlZCB0byB0aW5rZXIgdGhlIExTREIgdG8gcmVwcmVzZW50IHRoZSBz YW1lDQp8ICAgICAgICB8ICAgIGNvcnJlY3RseS4NCnwgICAgICAgIHwNCnwgICAgICAgIHwgICAg U29tZSBtb3JlIGRldGFpbHMgd291bGQgYmUgaGVscGZ1bCB0byByZXByZXNlbnQgdGhlIGNoYW5n ZXMgb24NCnwgICAgICAgIHwgICAgYWdncmVnYXRpb24vZGUtYWdncmVnYXRpb24gc3Vic2VxdWVu dGx5Lg0KfCANCnwgICAgICAgIHRoaXMgbWF5IHF1aWNrbHkgZ2V0IHlvdSBpbnRvIHRoZSAiYWJz dHJhY3RlZCB0b3BvbG9neSBtb2RlbHMiDQp8ICAgICAgICBkaXNjdXNzaW9uIHRoYXQga2VlcHMg ZW1lcmdpbmcgIHBlcmlvZGljYWxseS4gLQ0KfCAgICAgICAgd2UgZGlkIG5vdCB3YW50IHRvIHN0 b3AgcHJvZ3Jlc3Mgb24gdGhlIHByb3RvY29sIGJ5IGFyZ3VpbmcNCnwgICAgICAgICJ3aGF0cyB0 aGUgcmlnaHQgYWJzdHJhY3Rpb24gbW9kZWwiIGFuZCBoYXZlIGFncmVlZA0KfCAgICAgICAgb24g dGhlIG1pbmltYWxpc3RpYyBuYXR1cmUgb2YgdGhlIHNlY3Rpb24gYXMtaXMuDQp8IA0KfCANCnwg ICAgICAgIHwgICAgNC4gICAgICAgU2VjdGlvbiA2LjIgaGFzIGVtcHR5IHN1Yi1zZWN0aW9ucyBh bmQgVEJEcy4NCnwgDQp8ICAgICAgICByaWdodCAuLi4gc28gc3VnZ2VzdCB0byByZW1vdmUgc2Vj dGlvbiA2LjIgYWx0b2dldGhlci4NCnwgDQp8ICAgICAgICB8ICAgIDUuICAgICAgIEl0J3MgZ29v ZCB0byBzZWUgSW1wbGVtZW50YXRpb24gcmVwb3J0IHNoZWQgbGlnaHQgb24NCnwgICAgICAgIHBl cmZvcm1hbmNlDQp8ICAgICAgICB8ICAgIHNlZW4gd2l0aCBtdWx0aXBsZSBBU2VzLg0KfCAgICAg ICAgfA0KfCAgICAgICAgfCAgICA2LiAgICAgICBJdCdzIGdvb2QgdG8gc2VlIGlmIGFueSBhcHBs aWNhdGlvbiBvZiBwb2xpY3kgb24gTFNEQiBpcw0KfCAgICAgICAgZG9uZQ0KfCAgICAgICAgfCAg ICAob25lIG9mIHRoZSBwcmltYXJ5IGRyaXZlcnMgb2YgdGhlIHNwZWNpZmljYXRpb24pLg0KfCAN CnwgDQp8ICAgICAgICB0aGFua3MsDQp8IA0KfCANCnwgICAgICAgIC9oYW5uZXMNCnwgDQp8ICAg ICAgICB8DQp8ICAgICAgICB8ICAgIEZyb206IElkciBbbWFpbHRvOmlkci1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgU3VzYW4gSGFyZXMNCnwgICAgICAgIHwgICAgU2VudDogVHVlc2Rh eSwgQXVndXN0IDI2LCAyMDE0IDExOjM3IEFNDQp8ICAgICAgICB8ICAgIFRvOiBpZHJAaWV0Zi5v cmcNCnwgICAgICAgIHwgICAgQ2M6ICdKb2huIEcuIFNjdWRkZXInOyBzaGFyZXNAbmR6aC5jb20N CnwgICAgICAgIHwgICAgU3ViamVjdDogW0lkcl0gV0cgTEMgZm9yIGRyYWZ0LWlldGYtaWRyLWxz LWRpc3RyaWJ1dGlvbiBhbmQNCnwgICAgICAgIHwgICAgZHJhZnQtaWV0Zi1pZHItbHMtZGlzdHJp YnV0LWltcGwNCnwgICAgICAgIHwNCnwgICAgICAgIHwNCnwgICAgICAgIHwNCnwgICAgICAgIHwg ICAgVGhpcyBpcyBhIFdHIExDIGZvcg0KfCAgICAgICAgfA0KfCAgICAgICAgfA0KfCAgICAgICAg fA0KfCAgICAgICAgfA0KfCAgICAgICAgWzFdaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1pZXRmLWlkci1scy1kaXN0cmlidXRpb24vDQp8ICAgICAgICB8DQp8ICAgICAgICB8 DQp8ICAgICAgICBbMl1odHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYt aWRyLWxzLWRpc3RyaWJ1dGlvbi1pbXBsLw0KfCAgICAgICAgfA0KfCAgICAgICAgfA0KfCAgICAg ICAgfA0KfCAgICAgICAgfCAgICBQbGVhc2UgcmVzcG9uZCB3aXRoIGNvbW1lbnRzIGFuZCAic3Vw cG9ydCBvciBubyBzdXBwb3J0LiIgIFRoaXMNCnwgICAgICAgIFdHIExDIGFsc28NCnwgICAgICAg IHwgICAgaW5jbHVkZXMgYSByZXF1ZXN0IGZvciB0aGUgYXV0aG9ycyB0byBwcm92aWRlIElQUiBv biB0aGUgc3ViamVjdC4NCnwgICAgICAgIHwNCnwgICAgICAgIHwNCnwgICAgICAgIHwNCnwgICAg ICAgIHwgICAgUGxlYXNlIG5vdGU6IGR1ZSB0byB0aGUgRXVyb3BlYW4gdmFjYXRpb25zIGluIEF1 Z3VzdCwgd2UgYXJlDQp8ICAgICAgICBidW5kbGluZw0KfCAgICAgICAgfCAgICB0aGVzZSB0aHJl ZSByZXZpZXdzIGludG8gdGhlIG5leHQgdHdvIHdlZWtzICh0aGVzZSB0d28gZHJhZnRzIGFuZA0K fCAgICAgICAgfCAgICBkcmFmdC1pZXRmLWFzLW1pZ3JhdGlvbikuICAgVGhlIGNoYWlycyB3b3Vs ZCBsaWtlIGZlZWRiYWNrIChsaXN0DQp8ICAgICAgICBvcg0KfCAgICAgICAgfCAgICBwcml2YXRl IGVtYWlsKSB3aGV0aGVyIHRoZSB0aHJlZSBXRyBMQyBzIGltcGFjdCBhbnlvbmUncyBhYmlsaXR5 DQp8ICAgICAgICB0byByZXZpZXcNCnwgICAgICAgIHwgICAgdGhlc2UgZHJhZnRzIGNhcmVmdWxs eS4NCnwgICAgICAgIHwNCnwgICAgICAgIHwNCnwgICAgICAgIHwNCnwgICAgICAgIHwgICAgVGhh bmsgeW91LA0KfCAgICAgICAgfA0KfCAgICAgICAgfA0KfCAgICAgICAgfA0KfCAgICAgICAgfCAg ICBTdWUgSGFyZXMgYW5kIEpvaG4gU2N1ZGRlcg0KfCAgICAgICAgfA0KfCAgICAgICAgfCBSZWZl cmVuY2VzDQp8ICAgICAgICB8DQp8ICAgICAgICB8ICAgIFZpc2libGUgbGlua3MNCnwgICAgICAg IHwgICAgMS4NCnwgICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt aWV0Zi1pZHItbHMtZGlzdHJpYnV0aW9uLw0KfCAgICAgICAgfCAgICAyLg0KfCAgICAgICAgaHR0 cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWlkci1scy1kaXN0cmlidXRp b24taW1wbC8NCnwgDQp8ICAgICAgICB8IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQp8ICAgICAgICB8IElkciBtYWlsaW5nIGxpc3QNCnwgICAgICAgIHwg SWRyQGlldGYub3JnDQp8ICAgICAgICB8IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vaWRyDQp8IA0KfCAgICAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCnwgICAgICAgIElkciBtYWlsaW5nIGxpc3QNCnwgICAgICAgIElkckBp ZXRmLm9yZw0KfCAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9p ZHINCnwgDQp8IA0KfCBSZWZlcmVuY2VzDQp8IA0KfCAgICBWaXNpYmxlIGxpbmtzDQp8ICAgIDEu IG1haWx0bzpoYW5uZXNAanVuaXBlci5uZXQNCnwgICAgMi4gbWFpbHRvOmxpemhlbnFpYW5nQGNo aW5hbW9iaWxlLmNvbQ0KfCAgICAzLiBtYWlsdG86dW1hLmNodW5kdXJpQGVyaWNzc29uLmNvbQ0K fCAgICA0LiBtYWlsdG86aWRyQGlldGYub3JnDQp8ICAgIDUuIG1haWx0bzpqZ3NAYmdwLm51DQp8 ICAgIDYuIG1haWx0bzpzaGFyZXNAbmR6aC5jb20NCnwgICAgNy4gbWFpbHRvOmhhbm5lc0BqdW5p cGVyLm5ldA0KfCAgICA4LiBtYWlsdG86dW1hLmNodW5kdXJpQGVyaWNzc29uLmNvbQ0KfCAgICA5 LiBtYWlsdG86aWRyQGlldGYub3JnDQp8ICAgMTAuIG1haWx0bzpqZ3NAYmdwLm51DQp8ICAgMTEu IG1haWx0bzpzaGFyZXNAbmR6aC5jb20NCiANCg== ------=_001_NextPart208724880862_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =0A
The encoding format specified by this draft does work. I totally agree.

I raise this question just for consistence clarifi= cation.
=0A

=0A
=0A
lizhenqiang@chinamobile.com
=0A
 
Date: 2014-09-03 11:59
Subject: Re: [Idr] WG LC for draft-ietf-= idr-ls-distribution and draft-ietf-idr-ls-distribut-impl
=
=0A

=0A
=0A=0A
=0AFrom: sairay <sairay@cisco.com>
=0ADate: Tuesday, September 2, 2014 at 8:57 PM=0ATo: "lizhenqiang@chinamobile.com" <lizhenqiang@chinamobile.com>, Hann= es Gredler <hannes@juniper.net>
=0ACc: "idr@ietf.org" <idr@i= etf.org>, 'John Scudder' <jgs@bgp.= nu>, "shares@ndzh.com"=0A &l= t;shares@ndzh.com>
=0ASubject: Re: [Idr] WG LC for draft-ietf-i= dr-ls-distribution and draft-ietf-idr-ls-distribut-impl
=0A
=0A
=0A
=0A
=0A
=0A
Sorry, I s= till do not see what is the point you are trying to make. Having the RD fi= eld anywhere in the NLRI works. So there isn't any technical issue here.&n= bsp;BGP-LS=0A follows the existing convention of placin= g the RD field
=0A
=0A
=0A=0A

=0A=0A=0A
=0A
=0A
right after the NLRI type and the NLRI f= ield.=0A
=0A
=0A
=0A=0A
^^^^^^^^^^^^^^^^^= ^^^^^^^^^^^^^^^^^^^
=0A
[SR] "...right after the NLRI type and th= e NLRI length fields".
=0A

=0A
=0A=0A
=0A
=0A
The same convention is used in RFC6514 (MVPN), draft-ietf-l2v= pn-evpn-07 (EVPN draft), to name a couple. Are you claiming that RFC6514 v= iolates RFC4364?
=0A

=0A
=0A
Also not all BGP= -LS NLRIs have IP prefix (there are three types of NLRIs: Node, Link and P= refix). Assuming that you are not asking to move the RD field for the Node= and Link NLRIs, why would you want to have a different encoding for Prefi= x NLRIs?
=0A

=0A
=0A= =0A
=0AFrom: "lizhenqiang@chinamobile.com" <lizhenqiang@chinamobile.com>
=0ADate: Tuesday, September 2, 2014 at 8:41 PM
=0ATo: sairay <sairay@cisco.com>, Hannes Gredler <hannes@juniper.net>
=0ACc: "idr@ietf.org"= <idr@ietf.org>, "shares@ndzh.com" <shares@ndzh.com>, 'John=0A Scudder' <jgs@bgp.nu>
=0ASubjec= t: Re: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft= -ietf-idr-ls-distribut-impl
=0A
=0A

=0A
=0A
=0A=0A
RD should be followed by the IP prefix as specifie= d in RFC4364.
=0A

=0A
=0A
Here in this draft, RD is = follwed by the link state NLRI. Link state NLRI has its own format. See th= e following example, the 24-bit-long IP prefix is far away from RD.
= =0A

=0A
=0A
=0A
=0A
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=0A
 |    = ;        NLRI Type =3D 3     =     |     Total NLRI Length   = ;      |
=0A
+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=0A
 |  &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;           |
=0A+           &nbs= p;           Route Disti= nguisher           =           +
=0A
&nbs= p;|            = ;            &= nbsp;           &nb= sp;            = ;            &= nbsp; |
=0A
+= -+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=0A| Protocol-ID |&nbs= p;
=0A+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=  
=0A| Identifier | 
=0A| (64 bits) | 
=0A+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
=0A// L= ocal Node Descriptor (variable) // 
=0A+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
=0A
=0A
= =0A
| Type =3D 265  = ;                     &n= bsp;    | Length | 
=0A+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
=0A| Prefix Length =3D 24 | IP P= refix (variable) // 
=0A+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+
=0A
=0A

=0A
=0A

=0A
=0A
The following format for the above example is con= sistent with RFC4364 in my opinion.
=0A
=0A
=0A
+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=0A
&nb= sp;|            NLR= I Type =3D 3         |     Total N= LRI Length         |
=0A
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=0A=
| Protocol-ID | 
=0A
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
=0A| Identifier | 
=0A| = (64 bits) | 
=0A+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+ 
=0A// Local Node Descriptor (variable) // =0A+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+&nbs= p;
=0A
=0A
=0A
| Type =3D 265             =                | Length | =0A+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = ;
=0A| Prefix Length =3D 88 | IP Prefix (variable) =3D RD followed by t= he 24-bit-long prefix // 
=0A+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+
=0A
=0A

=0A
=0A
=0A
=0A=0A
=0A
 
=0A
=0A<= div style=3D"PADDING-RIGHT: 8px; PADDING-LEFT: 8px; FONT-SIZE: 12px;FONT-F= AMILY:tahoma;COLOR:#000000; BACKGROUND: #efefef; PADDING-BOTTOM: 8px; PADD= ING-TOP: 8px">=0A=0A
Date: 2014-09-03 1= 1:23
=0A=0A=0A
Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and = draft-ietf-idr-ls-distribut-impl
=0A
=0A
=0A
=0A
=0A
Sorry, I do not understand your = point. In BGP-LS as well, the RD field is right after the route-type and t= he length:
=0A

=0A
=0A
=0A
  +-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=0A
  &n= bsp;|            NLRI Type     &nb= sp;    |     Total NLRI Length       &n= bsp; |
=0A
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+
=0A
   |       =                     &nbs= p;                     &= nbsp;             |
=0A
  &nbs= p;+                     =   Route Distinguisher              = ;       +
=0A
   |       =                     &nbs= p;                     &= nbsp;             |
=0A
  &nbs= p;+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= =0A
   |               &n= bsp;                    =                     &nb= sp;     |
=0A
   //       &nbs= p;          Link-State NLRI (variable)   &nb= sp;             //
=0A
   = ;|                     &= nbsp;                    = ;                     |<= /div>=0A
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+
=0A
=0A

=0A
=0A=0A
=0AFrom: "lizhenqiang@chinamobile.com" <lizhenqiang@chinamobile.com>
=0ADate: Tuesday, September 2, 2014 at 7:3= 9 PM
=0ATo: sairay <sairay@cisco.com>, Hannes Gredler <= hannes@juniper.net>
=0ACc: "= idr@ietf.org" <idr@ietf.org>= , "shares@ndzh.com" <shares@ndzh.com>, 'John=0A Scudder' <jgs@bgp.nu>
=0ASubject: Re: Re: [Idr] WG LC for draft-ietf-idr-ls-distr= ibution and draft-ietf-idr-ls-distribut-impl
=0A
=0A

=0A=0A
=0A
=0A

=0A
=0A
But the post= ion of RD in RFC6514 is AFTER type field and length field, not before thos= e fields. Taken Intra-AS I-PMSI A-D Route as an exampl= e,
=0A

=0A
=0A+----------------------= -------------+
=0A| Route Type (1 octet) =3D 1  |
=0A+-------= ----------------------------+
=0A| Length (1 octet) |
=0A
+---= --------------------------------+
=0A| RD (8 octets) |
=0A+-------= ----------------------------+
=0A| Originating Router=E2=80=99s IP Add= r |
=0A+-----------------------------------+
=0A

=0A=0A
=0A=0A
=0A
&nbs= p;
=0A
=0A
=0A=0A
Date:=  2014-09-03 10:24
=0A=0A=0A
Subject: Re: [Idr] WG LC for draft-ie= tf-idr-ls-distribution and draft-ietf-idr-ls-distribut-impl
=0A
= =0A
=0A
=0A
=0A

= =0A
=0A=0A
=0AFrom: "= lizhenqiang@chinamobile.com= " <lizhenqiang@china= mobile.com>
=0ADate: Tue= sday, September 2, 2014 at 7:18 PM
=0A= To: sairay <sairay@cisco.com= >, Hannes Gredler <hannes@= juniper.net>
=0ACc: "idr@ietf.org" <idr@ietf.org>, "shares@= ndzh.com" <shares@ndzh.com&g= t;, 'John=0A Scudder' <jgs@bgp.nu>=
=0ASubject: Re: Re: [Idr] WG L= C for draft-ietf-idr-ls-distribution and draft-ietf-idr-ls-distribut-impl<= br>=0A
=0A

=0A
=0A
=0A
=0A
Plac= ing the type field before the length field is fine for me.
=0A
=0A
=0A
The encoding format for RD in this draft is not consist= ent with RFC4364. This is the question. RFC6514 says "The R= oute Distinguisher (RD) is encoded as described in=0A [RFC4364]", please see section 4 of RFC6514.
=0A
=0A
=0A=0A

=0A
=0A
[SR] That statement in RFC6514 refers to h= ow the 8 bytes of the route-distinguisher field are encoded (different RD = types, values, etc.), not to the position of RD field in the NLRI.
= =0A=0A
=0A
=0A

=0A
= =0A
I agree with you for the advantage to put the RD before other fiel= ds. I raise this quesiton just for clarification.
=0A

=0A=0A
=0A=0A
=0A
&nb= sp;
=0A
=0A
=0A=0A
Date:=  2014-09-03 05:03
=0A=0A=0A
Subject: Re: [Idr] WG LC for draft-ie= tf-idr-ls-distribution and draft-ietf-idr-ls-distribut-impl
=0A
= =0A
=0A
=0A
=0A
Hi Zhenqiang:=0A
=0A
=0A
=0A
=0AFor the NLRIs = that uses a "type" field, such as MVPN (see RFC6514), the convention is to= encode the type field before the length field. This allows for greatest f= lexibility for future extensions. In BGP-LS, we have used the same convent= ion.
=0A
=0A
=0A
=0A
=0AOther t= han that, the RD is for the entire bgp-ls object (be it a Node, Link or Pr= efix). So placing the RD field before other fields is logically accurate.<= /div>=0A
=0A
=0A
=0A
=0AThanks.=0A
=0A
=0A
=0A=0A
=0AFrom: "lizhenqiang@chinamobile.com" <lizhenqiang@chinamobile.com>
=0ADate: Tuesday, September 2, 2014 at 4:21 AM=0ATo: Hannes Gredler <hannes@juniper.net>
=0ACc: "idr@ie= tf.org" <idr@ietf.org>, "shares@ndzh.com" <shares@ndzh.com>, 'John=0A Scudder' <jgs@bgp.nu>
=0ASubject: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution = and draft-ietf-idr-ls-distribut-impl
=0A
=0A

=0A
=0A<= div>=0A
=0A
Hi Hannes,
=0A

=0A
=0A<= div>One example to explain the differences. One VPN route with prefix leng= th 24 is carried in the NRLI.
=0A

=0A
=0A
The format= this draft specified is as follows.
=0A
=0A
+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=0A
 |&nbs= p;           NLRI Type = =3D 3         |     Total NLRI Len= gth         |
=0A
+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=0A
&n= bsp;|           &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;  |
=0A
+        &n= bsp;           &nbs= p;  Route Distinguisher       &nbs= p;            = +
=0A
 |        &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;     |
=0A
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+
= =0A| Protocol-ID |
=0A+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+
=0A| Identifier |
=0A| (64 bits) |
=0A+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=0A// Loca= l Node Descriptor (variable) //
=0A+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=0A
=0A
=0A
| Type =3D 265    =                     &nb= sp;  | Length |=0A
=0A+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+
=0A| Prefix Length =3D 24 | IP Prefix (variable)= //
=0A+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+
=0A

=0A
=0A

=0A
=0A
The forma= t RFC4363 specified is as follows.
=0A
+-----------------------------------------------= ----------+=0A
=0A| Address Family Identifier (2 octets) |
=0A+----= -----------------------------------------------------+
=0A| Subsequent= Address Family Identifier (1 octet) |
=0A+---------------------------= ------------------------------+
=0A| Length of Next Hop Network Addres= s (1 octet) |
=0A+----------------------------------------------------= -----+
=0A| Network Address of Next Hop (variable) |
=0A+---------= ------------------------------------------------+
=0A| Reserved (1 oct= et) |
=0A+---------------------------------------------------------+ <= br>=0A| Prefix Length =3D 88 |  IP Prefix (variable) =3D RD fo= llowed by IP prefix // 
=0A+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-++
=0A

=0A
=0A
=0A=0A
=0A
 
=0A
=0A
=0A=0A
Date: 2014-09-02 16= :35
=0A=0A=0ASubject: Re: RE: [Idr] WG LC for draft-ietf-idr-ls-distribu= tion and draft-ietf-idr-ls-distribut-impl
=0A
=0A
=0A
= =0A
hi zhenqiang,
=0A
 
=0A
On Tue, Sep 02, 201= 4 at 04:12:58PM +0800, =0Al= izhenqiang@chinamobile.com wrote:
=0A
|    Two= types of link state NLRIs are defined in section 3.2 of this
=0A|    draft, AFI 16388 / SAFI 71 for non-VPN, AFI 16388 / S= AFI 128 for VPN.
=0A
 
=0A
correct;
=0A
&n= bsp;
=0A
|    My question is about AFI 16388 / SAF= I 128 NLRI. From the figure in page 9
=0A
|    of = draft version 5, we can see that RD is put before link state NLRI.
= =0A
 
=0A
 
=0A
from =0Ahttp://= tools.ietf.org/html/draft-ietf-idr-ls-distribution-05#section-3.2=0A
 
=0A
this is the NLRI format for AFI 16388 / SAFI = 71 (unicast)
=0A
 
=0A
    0 &n= bsp;           &nbs= p;     1       &nbs= p;           2 &nbs= p;            =      3
=0A
    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
=0A
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= =0A
   |        &nbs= p;   NLRI Type        &n= bsp; |     Total NLRI Length    &n= bsp;    |
=0A
   +-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=0A
   |&nbs= p;            =             &n= bsp;           &nbs= p;            =              |=
=0A
   //       &nb= sp;          Link-State NLRI = (variable)          &nbs= p;      //
=0A
   |  = ;            &= nbsp;           &nb= sp;            = ;            &= nbsp;           |
= =0A
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+
=0A
 
=0A
and this is the NLRI format = for AFI 16388 / SAFI 128 (VPN-unicast)
=0A
 
=0A
&n= bsp;   0         &n= bsp;         1   &n= bsp;           &nbs= p;   2         &nbs= p;         3
=0A
 &n= bsp;  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=
=0A
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+
=0A
   |    &nbs= p;       NLRI Type    &n= bsp;     |     Total NLRI Length&n= bsp;        |
=0A
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= =0A
   |        &nbs= p;            =             &n= bsp;           &nbs= p;            =      |
=0A
   +   &n= bsp;           &nbs= p;       Route Distinguisher  &nbs= p;            =       +
=0A
   |  &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;           |
=0A<= div>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
=0A
   |      &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;       |
=0A
   // = ;            &= nbsp;    Link-State NLRI (variable)    =              /= /
=0A
   |       &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;      |
=0A
   +-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=0A
 =0A
 
=0A
 
=0A
|    The= link state NLRI field in this figure contains the IP prefix. As RFC4364=0A
|    specifies, the VPN routes should be carrie= d in the NLRI prepending with
=0A
|    RD.
= =0A
 
=0A
that is what we do - i fail to see the offendi= ng part with respect to RFC4364.
=0A
 
=0A
/hannes<= /div>=0A
 
=0A
|
=0A
|    =   From: [1]Hannes Gredler
=0A
|     = ; Date: 2014-09-02 15:29
=0A
|      To: = [2]lizhenqiang@chinamobile.= com; [3]Uma Chunduri
=0A
|      CC: = [4]'idr wg'; [5]'John G. Scudder'; [6]Susan Hares
=0A
| &nbs= p;    Subject: RE: Re: [Idr] WG LC for draft-ietf-idr-ls-di= stribution and
=0A
|      draft-ietf-idr= -ls-distribut-impl
=0A
|
=0A
|    &= nbsp; hi zhenqiang,
=0A
|
=0A
|    =   The Route-distinguisher's purpose is to add 64-bits of  disamb= iguating
=0A
|      entropy to the NLRI,= such
=0A
|
=0A
|      that th= e route-reflectors do not "swallow" that path as part of the
=0A
= |      best-path election
=0A
|
= =0A
|      procedure. The link-state NLRI (en= capsulated in MP_REACH/ MP UNREACH PA)
=0A
|
=0A
| = ;     is a RD-less version of the vpn-link-state NLRI.=
=0A
|
=0A
|      In a certain= way these correspond to RFC3107 / RFC4364 NLRI formats.
=0A
| =0A
|      The former is a RD-less versio= n of the latter.
=0A
|
=0A
|    &nb= sp; On your question "Why do't you put RD in IP Reachability Information,<= /div>=0A
|      just prepending RD with IP pr= efix as RFC4364 specifies." - This is
=0A
|   &nbs= p;  actually what we *are* doing - we put the RD before the link-stat= e NLRI
=0A
|      inside the MP_REACH/MP= _UNREACH Attribute.
=0A
|
=0A
|    =   HTH,
=0A
|
=0A
|      /= hannes
=0A
|
=0A
|    ------------------= --------------------------------------------------------
=0A
| =0A= =0A
|      Sent: Tuesday, September 02, 2014 = 8:44
=0A
|      To: Hannes Gredler; Uma = Chunduri
=0A
|      Cc: 'idr wg'; 'John = G. Scudder'; Susan Hares
=0A
|      Subj= ect: Re: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and
=0A|      draft-ietf-idr-ls-distribut-impl
= =0A
|
=0A
|      One question about= the VPN Link-State NLRI in section 3.2. Why do you
=0A
| &n= bsp;    put the RD before link state NRLI? Why do't you put= RD in IP
=0A
|      Reachability Inform= ation, just preprending RD with IP prefix as RFC4364
=0A
| &= nbsp;    specifies.
=0A
|
=0A
| &nb= sp;  ----------------------------------------------------------------= ----------
=0A
|
=0A
|      lizhenqiang@chinamobile.com
=0A
|
=0A
|
=0A
|    &= nbsp;   From: [7]Hannes Gredler
=0A
|   =      Date: 2014-09-02 02:05
=0A
|  =       To: [8]Uma Chunduri
=0A
| &nb= sp;      CC: [9]i= dr@ietf.org; [10]'John G. Scudder'; [11]Susan Hares
=0A
|&nbs= p;       Subject: Re: [Idr] WG LC for draft-= ietf-idr-ls-distribution and
=0A
|     &= nbsp;  draft-ietf-idr-ls-distribut-impl
=0A
|  &nb= sp;     hi uma,
=0A
|
=0A
| &n= bsp;      see comments/responses inline:
=0A=
|
=0A
|        On Wed, A= ug 27, 2014 at 11:07:01AM +0000, Uma Chunduri wrote:
=0A
| &= nbsp;      |    Support.
=0A<= div>|        |
=0A
| &nbs= p;      |    I see, hierarchy is W= ELL  defined when multiple instances of IGP
=0A
|  = ;      with
=0A
|    = ;    |    multiple AFs are running. Good wor= k.
=0A
|        |
=0A|        |
=0A
|  &= nbsp;     |
=0A
|    &nbs= p;   |    Have following Qs:
=0A
| =        |
=0A
|   &nb= sp;    |    1.     =   Any discussion of the delay introduced by BGP (packing,
=0A|        update
=0A
| &= nbsp;      |    generation, proces= sing etc..) to transport the LS information
=0A
|  &nbs= p;     |
=0A
|     &= nbsp;  |    especially, when LSDB is changing faster p= erhaps with large
=0A
|       = number of
=0A
|        | = ;   nodes/links inside an AS and with multiple ASes) to the=0A
|        controller will be=0A
|        |   = useful.
=0A
|
=0A
|      = ;  this is highly implementation dependent; -
=0A
| &nb= sp;      some vendors do the packaging of BGP upd= ates entirely event-driven
=0A
|     &nb= sp;  and others pack things up and have a worst case delay between=0A
|        the trigger event a= nd the BGP update. the protocol
=0A
|    &nbs= p;   itself does not prohibit/limit the propagation speed.
= =0A
|        (in fact it can be sho= wn that sometimes updates
=0A
|     &nbs= p;  travel faster on the (dataplane forwarded) iBGP mesh,
=0A|        rather than propgate using t= he hop-by-hop control-plane flooding
=0A
|    = ;    protocol)
=0A
|
=0A
|  &n= bsp;     |       &n= bsp;         A note on the sensiti= vity of this delay to the
=0A
|     &nbs= p;  consumer
=0A
|       = |    (applications) at the controller  can be helpful= . I saw very
=0A
|        litt= le
=0A
|        |  &= nbsp; discussion in Section 6 (6.1.5)
=0A
|
=0A
| =        difficiult - its hard to have some so= rt of general comment as things
=0A
|    &nbs= p;   are
=0A
|       = ; highly implementation dependent.
=0A
|
=0A
|
= =0A
|        |    2.=        This document encompasses pretty much= both OSPF and ISIS
=0A
|      &nbs= p; |    extensions done till date. How it will keep up with= future
=0A
|        extension= s in
=0A
|        |  = ;  OSPF/ISIS.
=0A
|
=0A
|    &= nbsp;   we have set up an IANA registries for the carriers of in= formation.
=0A
|        it is = expected by authors of "topological relevant" IGP extensions
=0A
= |        to supply also BGP-LS extensio= ns.
=0A
|
=0A
|      &nbs= p; |    A mechanism in place would be helpful. My suggestio= n would be-
=0A
|        the=0A
|        |   = ; respective IGP documents should assess the impact and define
=0A|        |
=0A
|  =       |    corresponding new TLVs = for BGP LS? But how this can be enforced?
=0A
|
=0A
|&n= bsp;       i have no idea - today its entire= ly voluntary.
=0A
|
=0A
|     =    |    3.       Se= ction 4, gives glimpse what's possible and the node
=0A
| &n= bsp;      aggregating
=0A
|  &= nbsp;     |    the links obviously need= to tinker the LSDB to represent the same
=0A
|   =      |    correctly.
=0A
|&nbs= p;       |
=0A
|   &= nbsp;    |    Some more details would be hel= pful to represent the changes on
=0A
|    &nb= sp;   |    aggregation/de-aggregation subsequentl= y.
=0A
|
=0A
|       = ; this may quickly get you into the "abstracted topology models"
=0A<= div>|        discussion that keeps emer= ging  periodically. -
=0A
|     &nb= sp;  we did not want to stop progress on the protocol by arguing=0A
|        "whats the right abst= raction model" and have agreed
=0A
|     = ;   on the minimalistic nature of the section as-is.
=0A|
=0A
|
=0A
|      &nb= sp; |    4.       Section 6.2= has empty sub-sections and TBDs.
=0A
|
=0A
| &nbs= p;      right ... so suggest to remove section 6.= 2 altogether.
=0A
|
=0A
|     =    |    5.       It= 's good to see Implementation report shed light on
=0A
| &nb= sp;      performance
=0A
|  &n= bsp;     |    seen with multiple ASes.<= /div>=0A
|        |
=0A
|&= nbsp;       |    6. &nbs= p;     It's good to see if any application of policy o= n LSDB is
=0A
|        done=0A
|        |   = (one of the primary drivers of the specification).
=0A
|
= =0A
|
=0A
|        thanks= ,
=0A
|
=0A
|
=0A
|    &n= bsp;   /hannes
=0A
|
=0A
|   &= nbsp;    |
=0A
|     &nbs= p;  |    From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
=0A|        |    Sent: T= uesday, August 26, 2014 11:37 AM
=0A
|    &nb= sp;   |    To: id= r@ietf.org
=0A
|        |&= nbsp;   Cc: 'John G. Scudder'; shares@ndzh.com
=0A
|      &n= bsp; |    Subject: [Idr] WG LC for draft-ietf-idr-ls-distri= bution and
=0A
|        | = ;   draft-ietf-idr-ls-distribut-impl
=0A
|  &= nbsp;     |
=0A
|    &nbs= p;   |
=0A
|        = |
=0A
|        |  &n= bsp; This is a WG LC for
=0A
|      = ;  |
=0A
|        |
= =0A
|        |
=0A
| =        |
=0A=0A
|      &nb= sp; |
=0A
|        |
=0A<= div>|        [2]http://datatrack= er.ietf.org/doc/draft-ietf-idr-ls-distribution-impl/
=0A
|&nb= sp;       |
=0A
|   =      |
=0A
|     &nb= sp;  |
=0A
|        |&nbs= p;   Please respond with comments and "support or no support."&n= bsp; This
=0A
|        WG LC a= lso
=0A
|        |  =   includes a request for the authors to provide IPR on the subject.=0A
|        |
=0A
|&n= bsp;       |
=0A
|   = ;     |
=0A
|     &n= bsp;  |    Please note: due to the European vacations = in August, we are
=0A
|       = bundling
=0A
|        | =    these three reviews into the next two weeks (these two drafts= and
=0A
|        |  = ;  draft-ietf-as-migration).   The chairs would like feedba= ck (list
=0A
|        or
= =0A
|        |    pr= ivate email) whether the three WG LC s impact anyone's ability
=0A|        to review
=0A
|&nbs= p;       |    these drafts ca= refully.
=0A
|        |
= =0A
|        |
=0A
| =        |
=0A
|   &nb= sp;    |    Thank you,
=0A
| &= nbsp;      |
=0A
|   &nbs= p;    |
=0A
|      &= nbsp; |
=0A
|        | &n= bsp;  Sue Hares and John Scudder
=0A
|   &nbs= p;    |
=0A
|      &= nbsp; | References
=0A
|       = ; |
=0A
|        |  =   Visible links
=0A
|      &nb= sp; |    1.
=0A=0A
|        | &= nbsp;  2.
=0A
|        =0Ahttp://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution-imp= l/
=0A
|
=0A
|      &= nbsp; | _______________________________________________
=0A
|&nbs= p;       | Idr mailing list
=0A
|&n= bsp;       | Idr@ietf.org
=0A=0A
|
=0A
|  &nb= sp;     ______________________________________________= _
=0A
|        Idr mailing lis= t
=0A
|        Idr@ietf.org
=0A=0A
|
=0A
| =
=0A
| References
=0A
|
=0A
|   = ; Visible links
=0A=0A=0A=0A|    4. mailto:idr@ietf.= org
=0A=0A=0A
|  &n= bsp; 7. mailto:hannes@juniper.net
=0A=0A
|  &n= bsp; 9. mailto:idr@ietf.org
=0A|   10. mailto:jgs@bgp.nu=0A=0A
 
=0A
=0A
=0A=0A
=0A
=0A
=0A
=0A
=0A
=0A=
=0A
=0A=0A
=0A
=0A
= =0A
=0A=0A
=0A
=0A
=0A
=0A=0A=0A ------=_001_NextPart208724880862_=------ From nobody Wed Sep 3 00:17:44 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F1961A0049 for ; Wed, 3 Sep 2014 00:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBvlhxu91MZC for ; Wed, 3 Sep 2014 00:17:37 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0209.outbound.protection.outlook.com [207.46.163.209]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F1881A000C for ; Wed, 3 Sep 2014 00:17:36 -0700 (PDT) Received: from CO1PR05MB443.namprd05.prod.outlook.com (10.141.73.152) by CO1PR05MB521.namprd05.prod.outlook.com (10.141.72.13) with Microsoft SMTP Server (TLS) id 15.0.1019.16; Wed, 3 Sep 2014 07:17:28 +0000 Received: from hannes-mba.local (193.110.55.13) by CO1PR05MB443.namprd05.prod.outlook.com (10.141.73.152) with Microsoft SMTP Server (TLS) id 15.0.1019.16; Wed, 3 Sep 2014 07:17:25 +0000 Received: from juniper.net (localhost [IPv6:::1]) by hannes-mba.local (Postfix) with ESMTP id E33C52AE28F; Wed, 3 Sep 2014 09:17:11 +0200 (CEST) Date: Wed, 3 Sep 2014 09:17:11 +0200 From: Hannes Gredler To: "lizhenqiang@chinamobile.com" Message-ID: <20140903071711.GC44334@juniper.net> References: <2014090311413770655136@chinamobile.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2014090311413770655136@chinamobile.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Originating-IP: [193.110.55.13] X-ClientProxiedBy: AM3PR06CA026.eurprd06.prod.outlook.com (10.141.192.144) To CO1PR05MB443.namprd05.prod.outlook.com (10.141.73.152) X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;UriScan:;UriScan:; X-Forefront-PRVS: 032334F434 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(189002)(199003)(377454003)(377424004)(24454002)(54356999)(76176999)(81542001)(83322001)(83506001)(92726001)(15975445006)(50466002)(230783001)(50986999)(21056001)(85306004)(15202345003)(47776003)(85852003)(83072002)(36756003)(92566001)(66066001)(64706001)(99396002)(90102001)(76482001)(110136001)(20776003)(81342001)(80022001)(101416001)(19580405001)(19580395003)(74662001)(77982001)(31966008)(76506005)(77096002)(74502001)(105586002)(4396001)(2501002)(106356001)(87976001)(2351001)(33656002)(86362001)(46102001)(107046002)(95666004)(102836001)(23676002)(579124003); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB443; H:hannes-mba.local; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/idr/vxFkbBqnws41XRJfBGTtFpu_Ktc Cc: 'idr wg' , "'John G. Scudder'" , Susan Hares Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-ietf-idr-ls-distribut-impl X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 07:17:40 -0000 hi zhenqiang, i am further puzzled by your formulation "IP prefix" - in BGP-LS there is no such thing as an "IP prefix" per se. there is: -node-NLRIs -link-NLRIs -prefix-NLRIs the "prefix-NRLI" is not so much used to advertise a prefix for routing, its being used for advertising an association between a BGP next-hop and a particular node. /hannes On Wed, Sep 03, 2014 at 11:41:38AM +0800, lizhenqiang@chinamobile.com wrote: | RD should be followed by the IP prefix as specified in RFC4364. | Here in this draft, RD is follwed by the link state NLRI. Link state NLRI | has its own format. See the following example, the 24-bit-long IP prefix | is far away from RD. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | NLRI Type = 3 | Total NLRI Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | + Route Distinguisher + | | | | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Protocol-ID | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Identifier | | | (64 bits) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | // Local Node Descriptor (variable) // | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Type = 265 | Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Prefix Length = 24 | IP Prefix (variable) // | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | The following format for the above example is consistent with RFC4364 in | my opinion. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | NLRI Type = 3 | Total NLRI Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Protocol-ID | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Identifier | | | (64 bits) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | // Local Node Descriptor (variable) // | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Type = 265 | Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Prefix Length = 88 | IP Prefix (variable) = RD followed by the | 24-bit-long prefix // | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | -------------------------------------------------------------------------- | | lizhenqiang@chinamobile.com | | | From: [1]Saikat Ray (sairay) | Date: 2014-09-03 11:23 | To: [2]lizhenqiang@chinamobile.com; [3]Hannes Gredler | CC: [4]'idr wg'; [5]Susan Hares; [6]'John G. Scudder' | Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and | draft-ietf-idr-ls-distribut-impl | Sorry, I do not understand your point. In BGP-LS as well, the RD field | is right after the route-type and the length: | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | NLRI Type | Total NLRI Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | + Route Distinguisher + | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | // Link-State NLRI (variable) // | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | From: "[7]lizhenqiang@chinamobile.com" <[8]lizhenqiang@chinamobile.com> | Date: Tuesday, September 2, 2014 at 7:39 PM | To: sairay <[9]sairay@cisco.com>, Hannes Gredler | <[10]hannes@juniper.net> | Cc: "[11]idr@ietf.org" <[12]idr@ietf.org>, "[13]shares@ndzh.com" | <[14]shares@ndzh.com>, 'John Scudder' <[15]jgs@bgp.nu> | Subject: Re: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and | draft-ietf-idr-ls-distribut-impl | But the postion of RD in RFC6514 is AFTER type field and length field, | not before those fields. Taken Intra-AS I-PMSI A-D Route as an example, | +-----------------------------------+ | | Route Type (1 octet) = 1 | | +-----------------------------------+ | | Length (1 octet) | | +-----------------------------------+ | | RD (8 octets) | | +-----------------------------------+ | | Originating Router’s IP Addr | | +-----------------------------------+ | | -------------------------------------------------------------------------- | | [16]lizhenqiang@chinamobile.com | | | From: [17]Saikat Ray (sairay) | Date: 2014-09-03 10:24 | To: [18]lizhenqiang@chinamobile.com; [19]Hannes Gredler | CC: [20]'idr wg'; [21]Susan Hares; [22]'John G. Scudder' | Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and | draft-ietf-idr-ls-distribut-impl | From: "[23]lizhenqiang@chinamobile.com" | <[24]lizhenqiang@chinamobile.com> | Date: Tuesday, September 2, 2014 at 7:18 PM | To: sairay <[25]sairay@cisco.com>, Hannes Gredler | <[26]hannes@juniper.net> | Cc: "[27]idr@ietf.org" <[28]idr@ietf.org>, "[29]shares@ndzh.com" | <[30]shares@ndzh.com>, 'John Scudder' <[31]jgs@bgp.nu> | Subject: Re: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and | draft-ietf-idr-ls-distribut-impl | Placing the type field before the length field is fine for me. | The encoding format for RD in this draft is not consistent with | RFC4364. This is the question. RFC6514 says "The Route Distinguisher | (RD) is encoded as described in [RFC4364]", please see section 4 of | RFC6514. | [SR] That statement in RFC6514 refers to how the 8 bytes of the | route-distinguisher field are encoded (different RD types, values, | etc.), not to the position of RD field in the NLRI. | I agree with you for the advantage to put the RD before other fields. | I raise this quesiton just for clarification. | | -------------------------------------------------------------------------- | | [32]lizhenqiang@chinamobile.com | | | From: [33]Saikat Ray (sairay) | Date: 2014-09-03 05:03 | To: [34]lizhenqiang@chinamobile.com; [35]Hannes Gredler | CC: [36]'idr wg'; [37]Susan Hares; [38]'John G. Scudder' | Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and | draft-ietf-idr-ls-distribut-impl | Hi Zhenqiang: | For the NLRIs that uses a "type" field, such as MVPN (see RFC6514), | the convention is to encode the type field before the length field. | This allows for greatest flexibility for future extensions. In | BGP-LS, we have used the same convention. | Other than that, the RD is for the entire bgp-ls object (be it a | Node, Link or Prefix). So placing the RD field before other fields | is logically accurate. | Thanks. | From: "[39]lizhenqiang@chinamobile.com" | <[40]lizhenqiang@chinamobile.com> | Date: Tuesday, September 2, 2014 at 4:21 AM | To: Hannes Gredler <[41]hannes@juniper.net> | Cc: "[42]idr@ietf.org" <[43]idr@ietf.org>, "[44]shares@ndzh.com" | <[45]shares@ndzh.com>, 'John Scudder' <[46]jgs@bgp.nu> | Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and | draft-ietf-idr-ls-distribut-impl | Hi Hannes, | One example to explain the differences. One VPN route with prefix | length 24 is carried in the NRLI. | The format this draft specified is as follows. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | NLRI Type = 3 | Total NLRI Length | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | + Route Distinguisher + | | | | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Protocol-ID | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Identifier | | | (64 bits) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | // Local Node Descriptor (variable) // | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Type = 265 | Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Prefix Length = 24 | IP Prefix (variable) // | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | The format RFC4363 specified is as follows. | +---------------------------------------------------------+ | | Address Family Identifier (2 octets) | | +---------------------------------------------------------+ | | Subsequent Address Family Identifier (1 octet) | | +---------------------------------------------------------+ | | Length of Next Hop Network Address (1 octet) | | +---------------------------------------------------------+ | | Network Address of Next Hop (variable) | | +---------------------------------------------------------+ | | Reserved (1 octet) | | +---------------------------------------------------------+ | | Prefix Length = 88 | IP Prefix (variable) = RD followed by IP | prefix // | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ | | -------------------------------------------------------------------------- | | [47]lizhenqiang@chinamobile.com | | | From: [48]Hannes Gredler | Date: 2014-09-02 16:35 | To: [49]lizhenqiang@chinamobile.com | CC: [50]Uma Chunduri; [51]'idr wg'; [52]'John G. Scudder'; | [53]Susan Hares | Subject: Re: RE: [Idr] WG LC for draft-ietf-idr-ls-distribution | and draft-ietf-idr-ls-distribut-impl | hi zhenqiang, | | On Tue, Sep 02, 2014 at 04:12:58PM +0800, | [54]lizhenqiang@chinamobile.com wrote: | | Two types of link state NLRIs are defined in section 3.2 of | this | | draft, AFI 16388 / SAFI 71 for non-VPN, AFI 16388 / SAFI 128 | for VPN. | | correct; | | | My question is about AFI 16388 / SAFI 128 NLRI. From the | figure in page 9 | | of draft version 5, we can see that RD is put before link | state NLRI. | | | from | [55]http://tools.ietf.org/html/draft-ietf-idr-ls-distribution-05#section-3.2 | | this is the NLRI format for AFI 16388 / SAFI 71 (unicast) | | 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 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | NLRI Type | Total NLRI Length | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | // Link-State NLRI (variable) | // | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | and this is the NLRI format for AFI 16388 / SAFI 128 (VPN-unicast) | | 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 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | NLRI Type | Total NLRI Length | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | + Route Distinguisher | + | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | // Link-State NLRI (variable) | // | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | The link state NLRI field in this figure contains the IP | prefix. As RFC4364 | | specifies, the VPN routes should be carried in the NLRI | prepending with | | RD. | | that is what we do - i fail to see the offending part with respect | to RFC4364. | | /hannes | | | | | From: [1]Hannes Gredler | | Date: 2014-09-02 15:29 | | To: [2][56]lizhenqiang@chinamobile.com; [3]Uma Chunduri | | CC: [4]'idr wg'; [5]'John G. Scudder'; [6]Susan Hares | | Subject: RE: Re: [Idr] WG LC for | draft-ietf-idr-ls-distribution and | | draft-ietf-idr-ls-distribut-impl | | | | hi zhenqiang, | | | | The Route-distinguisher's purpose is to add 64-bits of | disambiguating | | entropy to the NLRI, such | | | | that the route-reflectors do not "swallow" that path as | part of the | | best-path election | | | | procedure. The link-state NLRI (encapsulated in MP_REACH/ | MP UNREACH PA) | | | | is a RD-less version of the vpn-link-state NLRI. | | | | In a certain way these correspond to RFC3107 / RFC4364 NLRI | formats. | | | | The former is a RD-less version of the latter. | | | | On your question "Why do't you put RD in IP Reachability | Information, | | just prepending RD with IP prefix as RFC4364 specifies." - | This is | | actually what we *are* doing - we put the RD before the | link-state NLRI | | inside the MP_REACH/MP_UNREACH Attribute. | | | | HTH, | | | | /hannes | | | | | -------------------------------------------------------------------------- | | | | From: [57]lizhenqiang@chinamobile.com | <[58]lizhenqiang@chinamobile.com> | | Sent: Tuesday, September 02, 2014 8:44 | | To: Hannes Gredler; Uma Chunduri | | Cc: 'idr wg'; 'John G. Scudder'; Susan Hares | | Subject: Re: Re: [Idr] WG LC for | draft-ietf-idr-ls-distribution and | | draft-ietf-idr-ls-distribut-impl | | | | One question about the VPN Link-State NLRI in section 3.2. | Why do you | | put the RD before link state NRLI? Why do't you put RD in | IP | | Reachability Information, just preprending RD with IP | prefix as RFC4364 | | specifies. | | | | | -------------------------------------------------------------------------- | | | | [59]lizhenqiang@chinamobile.com | | | | | | From: [7]Hannes Gredler | | Date: 2014-09-02 02:05 | | To: [8]Uma Chunduri | | CC: [9][60]idr@ietf.org; [10]'John G. Scudder'; [11]Susan | Hares | | Subject: Re: [Idr] WG LC for | draft-ietf-idr-ls-distribution and | | draft-ietf-idr-ls-distribut-impl | | hi uma, | | | | see comments/responses inline: | | | | On Wed, Aug 27, 2014 at 11:07:01AM +0000, Uma Chunduri | wrote: | | | Support. | | | | | | I see, hierarchy is WELL defined when multiple | instances of IGP | | with | | | multiple AFs are running. Good work. | | | | | | | | | | | | Have following Qs: | | | | | | 1. Any discussion of the delay introduced by | BGP (packing, | | update | | | generation, processing etc..) to transport the LS | information | | | | | | especially, when LSDB is changing faster perhaps | with large | | number of | | | nodes/links inside an AS and with multiple ASes) to | the | | controller will be | | | useful. | | | | this is highly implementation dependent; - | | some vendors do the packaging of BGP updates entirely | event-driven | | and others pack things up and have a worst case delay | between | | the trigger event and the BGP update. the protocol | | itself does not prohibit/limit the propagation speed. | | (in fact it can be shown that sometimes updates | | travel faster on the (dataplane forwarded) iBGP mesh, | | rather than propgate using the hop-by-hop control-plane | flooding | | protocol) | | | | | A note on the sensitivity of this delay | to the | | consumer | | | (applications) at the controller can be helpful. I | saw very | | little | | | discussion in Section 6 (6.1.5) | | | | difficiult - its hard to have some sort of general | comment as things | | are | | highly implementation dependent. | | | | | | | 2. This document encompasses pretty much both | OSPF and ISIS | | | extensions done till date. How it will keep up with | future | | extensions in | | | OSPF/ISIS. | | | | we have set up an IANA registries for the carriers of | information. | | it is expected by authors of "topological relevant" IGP | extensions | | to supply also BGP-LS extensions. | | | | | A mechanism in place would be helpful. My suggestion | would be- | | the | | | respective IGP documents should assess the impact | and define | | | | | | corresponding new TLVs for BGP LS? But how this can | be enforced? | | | | i have no idea - today its entirely voluntary. | | | | | 3. Section 4, gives glimpse what's possible | and the node | | aggregating | | | the links obviously need to tinker the LSDB to | represent the same | | | correctly. | | | | | | Some more details would be helpful to represent the | changes on | | | aggregation/de-aggregation subsequently. | | | | this may quickly get you into the "abstracted topology | models" | | discussion that keeps emerging periodically. - | | we did not want to stop progress on the protocol by | arguing | | "whats the right abstraction model" and have agreed | | on the minimalistic nature of the section as-is. | | | | | | | 4. Section 6.2 has empty sub-sections and | TBDs. | | | | right ... so suggest to remove section 6.2 altogether. | | | | | 5. It's good to see Implementation report shed | light on | | performance | | | seen with multiple ASes. | | | | | | 6. It's good to see if any application of | policy on LSDB is | | done | | | (one of the primary drivers of the specification). | | | | | | thanks, | | | | | | /hannes | | | | | | | | From: Idr [[61]mailto:idr-bounces@ietf.org] On | Behalf Of Susan Hares | | | Sent: Tuesday, August 26, 2014 11:37 AM | | | To: [62]idr@ietf.org | | | Cc: 'John G. Scudder'; [63]shares@ndzh.com | | | Subject: [Idr] WG LC for | draft-ietf-idr-ls-distribution and | | | draft-ietf-idr-ls-distribut-impl | | | | | | | | | | | | This is a WG LC for | | | | | | | | | | | | | | | [1][64]http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/ | | | | | | | | | [2][65]http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution-impl/ | | | | | | | | | | | | Please respond with comments and "support or no | support." This | | WG LC also | | | includes a request for the authors to provide IPR on | the subject. | | | | | | | | | | | | Please note: due to the European vacations in | August, we are | | bundling | | | these three reviews into the next two weeks (these | two drafts and | | | draft-ietf-as-migration). The chairs would like | feedback (list | | or | | | private email) whether the three WG LC s impact | anyone's ability | | to review | | | these drafts carefully. | | | | | | | | | | | | Thank you, | | | | | | | | | | | | Sue Hares and John Scudder From nobody Wed Sep 3 12:27:40 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5C4C1A6F41; Wed, 3 Sep 2014 12:27:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gD7o_cFabcXJ; Wed, 3 Sep 2014 12:27:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6477D1A6F4C; Wed, 3 Sep 2014 12:27:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140903192732.23339.49198.idtracker@ietfa.amsl.com> Date: Wed, 03 Sep 2014 12:27:32 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/rRzsQ56UlYhTTnpD990QS3d4C4o Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-error-handling-14.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 19:27:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Revised Error Handling for BGP UPDATE Messages Authors : Enke Chen John G. Scudder Pradosh Mohapatra Keyur Patel Filename : draft-ietf-idr-error-handling-14.txt Pages : 17 Date : 2014-09-03 Abstract: According to the base BGP specification, a BGP speaker that receives an UPDATE message containing a malformed attribute is required to reset the session over which the offending attribute was received. This behavior is undesirable as a session reset would impact not only routes with the offending attribute, but also other valid routes exchanged over the session. This document partially revises the error handling for UPDATE messages, and provides guidelines for the authors of documents defining new attributes. Finally, it revises the error handling procedures for a number of existing attributes. This document updates error handling for RFCs 1997, 4271, 4360, 4456, 4760, 5543, 5701, 6368 and 6790. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-error-handling/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-error-handling-14 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-error-handling-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Sep 3 12:40:15 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE9971A6F0F for ; Wed, 3 Sep 2014 12:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJ9e0v5gV4SE for ; Wed, 3 Sep 2014 12:40:09 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0237.outbound.protection.outlook.com [207.46.163.237]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE40C1A6EDC for ; Wed, 3 Sep 2014 12:40:05 -0700 (PDT) Received: from [172.29.32.217] (66.129.241.10) by DM2PR05MB736.namprd05.prod.outlook.com (10.141.178.25) with Microsoft SMTP Server (TLS) id 15.0.1019.16; Wed, 3 Sep 2014 19:40:04 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "John G. Scudder" In-Reply-To: <20140903192732.23339.49198.idtracker@ietfa.amsl.com> Date: Wed, 3 Sep 2014 15:39:56 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <6BF003E2-25EB-411F-941F-D0707C9D7BE7@juniper.net> References: <20140903192732.23339.49198.idtracker@ietfa.amsl.com> To: "idr@ietf. org" X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [66.129.241.10] X-ClientProxiedBy: DM2PR11CA0007.namprd11.prod.outlook.com (25.160.91.17) To DM2PR05MB736.namprd05.prod.outlook.com (10.141.178.25) X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;UriScan:; X-Forefront-PRVS: 032334F434 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(6049001)(24454002)(164054003)(377424004)(189002)(51704005)(243025005)(199003)(377454003)(95666004)(81542001)(46102001)(105586002)(33656002)(15975445006)(50986999)(64706001)(77096002)(76176999)(42186005)(77156001)(46406003)(74502001)(31966008)(80022001)(66066001)(83716003)(110136001)(87286001)(20776003)(102836001)(47776003)(104166001)(97756001)(74662001)(15202345003)(82746002)(36756003)(19580395003)(50226001)(19580405001)(99396002)(83322001)(85306004)(81342001)(101416001)(4396001)(107886001)(85852003)(83072002)(93916002)(86362001)(89996001)(77982001)(21056001)(92726001)(92566001)(106356001)(107046002)(62966002)(50466002)(57306001)(88136002)(23726002)(76482001)(90102001)(79102001)(87976001)(230783001)(104396001)(42262002); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR05MB736; H:[172.29.32.217]; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/idr/D8c1nYJXdngCwDUxGXUpUSbPBxU Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-14.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 19:40:12 -0000 Folks, This version of the draft includes the changes that we discussed at the = IETF-90 IDR meeting: http://www.ietf.org/proceedings/90/slides/slides-90-idr-0.pdf http://www.ietf.org/proceedings/90/minutes/minutes-90-idr In short, it removes the discussion of what it means for an NLRI to be = incorrect. Reviewers may want to pay particular attention to S. 7.11. I'm hoping this is now ready to go through WGLC again and be advanced. Thanks, --John On Sep 3, 2014, at 3:27 PM, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Inter-Domain Routing Working Group of = the IETF. >=20 > Title : Revised Error Handling for BGP UPDATE = Messages > Authors : Enke Chen > John G. Scudder > Pradosh Mohapatra > Keyur Patel > Filename : draft-ietf-idr-error-handling-14.txt > Pages : 17 > Date : 2014-09-03 >=20 > Abstract: > According to the base BGP specification, a BGP speaker that receives > an UPDATE message containing a malformed attribute is required to > reset the session over which the offending attribute was received. > This behavior is undesirable as a session reset would impact not = only > routes with the offending attribute, but also other valid routes > exchanged over the session. This document partially revises the > error handling for UPDATE messages, and provides guidelines for the > authors of documents defining new attributes. Finally, it revises > the error handling procedures for a number of existing attributes. >=20 > This document updates error handling for RFCs 1997, 4271, 4360, = 4456, > 4760, 5543, 5701, 6368 and 6790. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-idr-error-handling/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-idr-error-handling-14 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-error-handling-14 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Sep 4 14:44:35 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09CFD1A01A5; Thu, 4 Sep 2014 14:44:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gMlejebDoq4L; Thu, 4 Sep 2014 14:44:31 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C9991A019B; Thu, 4 Sep 2014 14:44:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 528752406A2; Thu, 4 Sep 2014 14:44:31 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-41.clppva.east.verizon.net [70.106.135.41]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id C844724058C; Thu, 4 Sep 2014 14:44:30 -0700 (PDT) Message-ID: <5408DD3F.9060709@joelhalpern.com> Date: Thu, 04 Sep 2014 17:44:31 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "idr@ietf.org List" , "rtg-dir@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/idr/NWWDCtLCw9b5JY1nb1eVfP2iKao Subject: [Idr] QA review of http://tools.ietf.org/html/draft-ietf-idr-error-handling-14 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 21:44:33 -0000 As requested, this is a QA review of the IDR Error Handling revision. This reviewer finds no issues with this document. It seems to be ready for IETF LC. Yours, Joel From nobody Fri Sep 5 01:41:25 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBB291A0672 for ; Fri, 5 Sep 2014 01:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yjIyOypi10RJ for ; Fri, 5 Sep 2014 01:41:21 -0700 (PDT) Received: from nobulus.com (nobulus.com [IPv6:2001:6f8:892:6ff::11:152]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 975991A061D for ; Fri, 5 Sep 2014 01:41:21 -0700 (PDT) Received: from nobulus.com (localhost [127.0.0.1]) by nobulus.com (Postfix) with ESMTP id 86830170D2; Fri, 5 Sep 2014 10:41:19 +0200 (CEST) X-Virus-Scanned: amavisd-new at nobulus.com Received: from nobulus.com ([127.0.0.1]) by nobulus.com (nobulus.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id uEch8L1YyJSH; Fri, 5 Sep 2014 10:41:18 +0200 (CEST) Received: from [10.40.124.121] (unknown [87.84.237.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by nobulus.com (Postfix) with ESMTPSA id EAF40170CC; Fri, 5 Sep 2014 10:41:17 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ilya Varlashkin In-Reply-To: <018e01cfc146$4be6c480$e3b44d80$@ndzh.com> Date: Fri, 5 Sep 2014 09:41:18 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <18B4036D-4428-4401-9A2B-052F443FB720@nobulus.com> References: <018e01cfc146$4be6c480$e3b44d80$@ndzh.com> To: Susan Hares X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/OuBYyfTg6_LaHjke1O-iJSPNSOc Cc: IETF IDR , Alia Atlas Subject: Re: [Idr] WG LC X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 08:41:24 -0000 Support /iLya On 26 Aug 2014, at 16:56, Susan Hares wrote: > This is a 2 week WGT LC on draft-ietf-idr-as-migration starting = 8/26/2014 and ending 9/6/2014. > =20 > The draft can be accessed at: > =20 > http://datatracker.ietf.org/doc/draft-ietf-idr-as-migration/ > =20 > Please include in your call =93support or no support=94. This call = also ask the authors to indicate if there is any IPR related to the = draft. > =20 > Sue > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Mon Sep 8 13:42:22 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15D7B1A0384 for ; Mon, 8 Sep 2014 13:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aFe5L5xiLBnj for ; Mon, 8 Sep 2014 13:42:09 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC4661A037F for ; Mon, 8 Sep 2014 13:42:07 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s88KZWBU026935 for ; Mon, 8 Sep 2014 21:35:33 +0100 Received: from 950129200 (host4-182-static.10-188-b.business.telecomitalia.it [188.10.182.4]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s88KZO0g026773 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 8 Sep 2014 21:35:29 +0100 From: "Adrian Farrel" To: Date: Mon, 8 Sep 2014 21:41:59 +0100 Message-ID: <02bf01cfcba5$5b39a2e0$11ace8a0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac/LpUlUtbw7noH1TjalMIevg4g6nQ== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-20938.002 X-TM-AS-Result: No--14.577-10.0-31-10 X-imss-scan-details: No--14.577-10.0-31-10 X-TMASE-MatchedRID: IuGQX3eS/ETZZ7BZ4UeyMAgKAWhuC2ojCckvlPjoBZErmF9M9Cpdo8Lm p4jPUF8tuenE8eLG9VRp6oZAI2DGjOyt+a9Mtf+eF6z9HGHKwNsk80hXoYXyazdnd59Af7CPs4t AEOEfosHYVph6DzTbB6EqQJ+9+hWw2DBKoUnK0AUdxBAG5/hkW17OZ6hrwwnzIdKvm2xilWAZmY UBcCKclec6r1u0yRCeA4OUKPk+wFgmfxOgBOFpInGBmLio+mJgifgN14P+4s3JyYU2J054Pbt6I p6ECVpCbYBtV6i2qU565rrWKXsbyBNj8dEIVpt0ngIgpj8eDcC063Wh9WVqgqbyPFGTn+O41GcR AJRT6POOhzOa6g8KrVjbiRFUE+ZvoAH2peRVB5pf5ykoVFbZN0fdg4Dhp/20KRpkOuxL+xc= Archived-At: http://mailarchive.ietf.org/arch/msg/idr/dYtpqMqAc-jHxHR-Knl7SZhkA88 Subject: [Idr] Heads up: Last Call: (BGP operations and security) to Best Current Practice X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 20:42:14 -0000 > -----Original Message----- > From: IETF-Announce [mailto:ietf-announce-bounces@ietf.org] On Behalf Of The > IESG > Sent: 08 September 2014 16:42 > To: IETF-Announce > Cc: opsec@ietf.org > Subject: Last Call: (BGP operations and > security) to Best Current Practice > > > The IESG has received a request from the Operational Security > Capabilities for IP Network Infrastructure WG (opsec) to consider the > following document: > - 'BGP operations and security' > as Best Current Practice > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2014-09-22. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > BGP (Border Gateway Protocol) is the protocol almost exclusively used > in the Internet to exchange routing information between network > domains. Due to this central nature, it is important to understand > the security measures that can and should be deployed to prevent > accidental or intentional routing disturbances. > > This document describes measures to protect the BGP sessions itself > (like TTL, TCP-AO, control plane filtering) and to better control the > flow of routing information, using prefix filtering and > automatization of prefix filters, max-prefix filtering, AS path > filtering, route flap dampening and BGP community scrubbing. > > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-opsec-bgp-security/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-opsec-bgp-security/ballot/ > > > No IPR declarations have been submitted directly on this I-D. From nobody Mon Sep 8 13:47:12 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D774D1A0386 for ; Mon, 8 Sep 2014 13:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a0q8gH3C2RWe for ; Mon, 8 Sep 2014 13:47:09 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 796A31A0389 for ; Mon, 8 Sep 2014 13:47:07 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s88Kl5Nl007377 for ; Mon, 8 Sep 2014 21:47:05 +0100 Received: from 950129200 (host4-182-static.10-188-b.business.telecomitalia.it [188.10.182.4]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s88Kl1x5007351 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 8 Sep 2014 21:47:02 +0100 From: "Adrian Farrel" To: Date: Mon, 8 Sep 2014 21:47:02 +0100 Message-ID: <02ca01cfcba6$0d9ac450$28d04cf0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac/LpgnEpzu7LlzHSECykLuIpYtXxQ== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-20938.002 X-TM-AS-Result: No--14.049-10.0-31-10 X-imss-scan-details: No--14.049-10.0-31-10 X-TMASE-MatchedRID: 3Sovwp9/cg/ZZ7BZ4UeyMAgKAWhuC2ojSbdMM+ixeggEgPcpc1tw6MLm p4jPUF8tuenE8eLG9VRp6oZAI2DGjOyt+a9Mtf+eF6z9HGHKwNs7UrmIzxDooBhmH6eMRZd9h8D cCjnwixMJeC/LTkzef+Ykdnyv+ApX2DBKoUnK0AUdxBAG5/hkW17OZ6hrwwnzGfvHtnLRItsnP8 WWLvfAyNIDJyV1VyTwS0mrIcn0eIf1zIImtiPm1XC+Q0h5+aC3ej8QyNOlLR3JyYU2J054Pbt6I p6ECVpC+i5FmTzDfed77384BTKUT74OZz7I17IRU+OjsPhIWDh9LQinZ4QefL6qvLNjDYTwzhtq OA7SSC9X2EquWRGYWAtuKBGekqUpI/NGWt0UYPB8zfhX5T/3rNb2WgAIN/mdgJ8iJ+LkXU+UuTg 8HJFABsTnihm4os/F Archived-At: http://mailarchive.ietf.org/arch/msg/idr/hSGA9N8shze0u02MUXXuYMZKpJw Subject: [Idr] Heads up: Last Call: (Internet Exchange Route Server Operations) to Informational RFC X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 20:47:11 -0000 > -----Original Message----- > From: IETF-Announce [mailto:ietf-announce-bounces@ietf.org] On Behalf Of The > IESG > Sent: 08 September 2014 16:47 > To: IETF-Announce > Cc: grow@ietf.org > Subject: Last Call: > (Internet Exchange Route Server Operations) to Informational RFC > > > The IESG has received a request from the Global Routing Operations WG > (grow) to consider the following document: > - 'Internet Exchange Route Server Operations' > as > Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2014-09-22. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > The popularity of Internet exchange points (IXPs) brings new > challenges to interconnecting networks. While bilateral eBGP > sessions between exchange participants were historically the most > common means of exchanging reachability information over an IXP, the > overhead associated with this interconnection method causes serious > operational and administrative scaling problems for IXP participants. > > Multilateral interconnection using Internet route servers can > dramatically reduce the administrative and operational overhead of > IXP participation and these systems used by many IXP participants as > a preferred means of exchanging routing information. > > This document describes operational considerations for multilateral > interconnections at IXPs. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-grow-ix-bgp-route-server-operations/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-grow-ix-bgp-route-server- > operations/ballot/ > > > No IPR declarations have been submitted directly on this I-D. From drivas@cenit.gob.ve Wed Sep 10 11:50:44 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF7A01A86EB for ; Wed, 10 Sep 2014 11:50:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pwckJH4ggec1 for ; Wed, 10 Sep 2014 11:50:43 -0700 (PDT) Received: from smtp.cenit.gob.ve (smtp.cenit.gob.ve [IPv6:2001:1338:1001:930::12]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7794B1A86E2 for ; Wed, 10 Sep 2014 11:50:43 -0700 (PDT) Received: from [IPv6:2001:1338:1001:971:290:f5ff:fe68:b909] (unknown [IPv6:2001:1338:1001:971:290:f5ff:fe68:b909]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.cenit.gob.ve (Postfix) with ESMTPSA id D9A70361A9 for ; Wed, 10 Sep 2014 14:02:12 -0430 (VET) Message-ID: <54109E89.6040200@cenit.gob.ve> Date: Wed, 10 Sep 2014 14:25:05 -0430 From: Daniela Rivas User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Icedove/24.7.0 MIME-Version: 1.0 To: idr@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/idr/PHf3J3ORRIWVCVsoVeB_uaeixP8 Subject: [Idr] Test X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 18:54:40 -0000 Hello This is a test Have a nice day... From nobody Wed Sep 10 13:57:03 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 297251A0455 for ; Tue, 9 Sep 2014 16:33:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.153 X-Spam-Level: X-Spam-Status: No, score=-16.153 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, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JHhq6Yj5BNbU for ; Tue, 9 Sep 2014 16:33:13 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D69D1A0437 for ; Tue, 9 Sep 2014 16:33:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23664; q=dns/txt; s=iport; t=1410305593; x=1411515193; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=X36hvAlhXQjKviVOYpf9waPBnWq/wR8bO3Ixup6woTs=; b=A+4724od6lfRAwOThKTFEp6ECuClQ0e6v8mgpHhT70SJ+JqXBZMvAxW4 T0yfdc08h0Jf2ms0XipHlxsl3x71JVnS/fADjnuptgMwTFkliOkWIXW5F yoV4SeZdWlhwuZfqa2uH4G0zMeomJmbqidZwStxwOkwjEZgpU1TWkHITR o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggHAAqND1StJV2U/2dsb2JhbABPCoMNU1cBA8oph0yBCxZ4hAoaTRISARxkJwQOIIgnDb0qAReNR4EqBVeDNoEdBZFBhDCCPIRGgV+TT4FnCBaBXG2BBkGBBwEBAQ X-IronPort-AV: E=Sophos;i="5.04,494,1406592000"; d="scan'208";a="76469585" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-4.cisco.com with ESMTP; 09 Sep 2014 23:33:12 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s89NXB78010356 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Sep 2014 23:33:11 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.175]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0195.001; Tue, 9 Sep 2014 18:33:11 -0500 From: "Acee Lindem (acee)" To: Routing ADs Thread-Topic: Routing Directorate Review of draft-ietf-idr-ls-distribution-05.txt Thread-Index: AQHPzIZqlcQBU8P23k+TdKJRNsyzNQ== Date: Tue, 9 Sep 2014 23:33:10 +0000 Message-ID: <55E298DE-B369-493A-84E3-C33CA72689AD@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.152.198] Content-Type: text/plain; charset="Windows-1252" Content-ID: <151D7194FA7E9A439358F75A3889D95D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/hD91bQEJFxruo_0rafXsSEjKUcY X-Mailman-Approved-At: Wed, 10 Sep 2014 13:57:00 -0700 Cc: IDR WG List , Adrian Farrel , Routing Directorate Subject: [Idr] Routing Directorate Review of draft-ietf-idr-ls-distribution-05.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 23:33:17 -0000 Hi, I have been selected as the Routing Directorate reviewer for this draft. Th= e Routing Directorate seeks to review all routing or routing-related drafts= as they pass through IETF last call and IESG review. The purpose of the re= view is to provide assistance to the Routing ADs. For more information abou= t the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/t= rac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it wo= uld be helpful if you could consider them along with any other IETF Last Ca= ll comments that you receive, and strive to resolve them through discussion= or by updating the draft. Document: draft-ietf-idr-ls-distribution-05.txt Reviewer: Acee Lindem Review Date: 09/09/2014 Current IDR WG Document Intended Status: Standards Track Summary: The draft describes encoding for the encoding of the IGP link-stat= e database and TE database in BGP NRLI. This information is advertised in t= o external BGP speakers performing applicaiton such as Path Computation Ele= ment (PCE) servers and Application-Layer Traffic Optimizers (ALTO) servers.= My opinion is that the draft needs significant improvement prior to public= ation.=20 Major Issues: 1. The draft should indicate the overall goal of translating the IGP link= state database and TE Database into a generic representation. It should al= so better enumerate the requirements for this translation.=20 2. The draft includes opaque attribute TLVs for advertising protocol-spec= ific information (node, link, and prefix). However, there is no indication = on how this information is encoded or identified. Hence, there can be no in= teroperability between implementations. 3. The draft is based mainly on ISIS encoding and does a poor job of repr= esenting the OSPF. Examples include:=20 A. Page 10 - There is no protocol-id for OSPFv3.=20 B. Page 11 - Why is RFC 6822 normative and RFC 6549 informational?=20 C. Psuedonode Representation - The absence of a condensed format for th= e pseudonode following the OSPF model. D. Page 15 - Relevant OSPF RFCs should be referenced for TLV code point= s. E. Page 18 - Why an ISIS Area identifier and not an OSPF Area identifie= r? F. Page 18 - 'E' is for an ASBR and 'B' is for ABR. G. Page 19 - RFC 5642 is the OSPF Node Name RFC. H. Page 21 - Should be references to OSPF RFC, RFC 3630, RFC 4203, and = RFC 5329.=20 I. Page 22 - OSPF Link metrics are 2 bytes but OSPF prefix metrics are = 3 bytes. J. Page 25 - OSPF Prefix Options are defined in RFC 5340, A.4.1.1. It n= ot clear which need to be advertised.=20 K. Page 26 - Forwarding Address for OSPFv3 should reference RFC 5340 as= well. 4. Section 3.2.15 - Why do you limit a link or prefix to a single MT-ID? = Links and prefixes can be reachable in multiple topologies with different m= etrics. Is this simply a typo?=20 Minor Issues: 1. Figures and tables are referenced by number, yet those figures and tab= les are not numbered. =20 2. Several acronymns that are not designated as well-known are not expand= ed with the first usage. Examples include LSDB and TED. Refer to http://www= .rfc-editor.org/rfc-style-guide/abbrev.expansion.txt.=20 3. Page 11 - The table mentions L1 optical topology but there are are no = optical attributes. This seems like it should be removed and added when GMP= LS information is defined for BGP LS.=20 4. Page 11 - The BGP-LS Identifier is referenced before it is defined.=20 5. Page 17 - In the context of this NRLI, what purpose does the next hop = address serve? If none, couldn't we just advertise a 0 length network addre= ss?=20 6. Page 18 - Why isn't the IS-IS Area Identifier applicable to prefixes? = OSPF can scope prefixes to areas (unless they AS-External).=20 7. For FQDN node/link name recommendation - should usage dictate "RECOMME= NDED" rather than "recommended=94? 8. Page 21 - Is knowing whether MPLS signaling is enabled on a link all t= hat is needed by the applications? This seems somewhat out of place with th= e LSDB and TE data.=20 Nits:=20 *************** *** 21,27 **** called upon to perform computations based on the network topology and current state of the connections within the network, including traffic engineering information. This is information typically ! distributed by IGP routing protocols within the network =20 This document describes a mechanism by which links state and traffic engineering information can be collected from networks and shared --- 21,27 ---- called upon to perform computations based on the network topology and current state of the connections within the network, including traffic engineering information. This is information typically ! distributed by IGP routing protocols within the network. =20 This document describes a mechanism by which links state and traffic engineering information can be collected from networks and shared *************** *** 246,252 **** routers in a POP. Abstracted topology can also be a mix of physical and virtual nodes and physical and virtual links. Furthermore, the BGP Speaker can apply policy to determine when information is updated ! to the consumer so that there is reduction of information flow form the network to the consumers. Mechanisms through which topologies can be aggregated or virtualized are outside the scope of this document --- 246,252 ---- routers in a POP. Abstracted topology can also be a mix of physical and virtual nodes and physical and virtual links. Furthermore, the BGP Speaker can apply policy to determine when information is updated ! to the consumer so that there is reduction of information flow from the network to the consumers. Mechanisms through which topologies can be aggregated or virtualized are outside the scope of this document *************** *** 267,278 **** policy control and algorithms, and coordination of computation across the whole area. =20 ! o If a router wants to compute a MPLS-TE path across IGP areas its own TED lacks visibility of the complete topology. That means that the router cannot determine the end-to-end path, and cannot even select the right exit router (Area Border Router - ABR) for an optimal path. This is an issue for large-scale networks that ! need to segment their core networks into distinct areas, but which still want to take advantage of MPLS-TE. =20 Previous solutions used per-domain path computation [RFC5152]. The --- 267,279 ---- policy control and algorithms, and coordination of computation across the whole area. =20 ! o If a router wants to compute an MPLS-TE path across multiple IGP=20 ! areas, then its own TED lacks visibility of the complete topology. That means that the router cannot determine the end-to-end path, and cannot even select the right exit router (Area Border Router - ABR) for an optimal path. This is an issue for large-scale networks that ! need to segment their core networks into distinct areas, but still want to take advantage of MPLS-TE. =20 Previous solutions used per-domain path computation [RFC5152]. The *************** *** 426,434 **** (thus a TLV with no value portion would have a length of zero). The TLV is not padded to four-octet alignment. Unrecognized types are preserved and propagated. In order to compare NLRIs with unknown ! TLVs all TLVs MUST be ordered in ascending order. If there are more TLVs of the same type, then the TLVs MUST be ordered in ascending ! order of the TLV value within the set of TLVs with the same type. All TLVs that are not specified as mandatory are considered optional. =20 3.2. The Link-State NLRI --- 427,435 ---- (thus a TLV with no value portion would have a length of zero). The TLV is not padded to four-octet alignment. Unrecognized types are preserved and propagated. In order to compare NLRIs with unknown ! TLVs, all TLVs MUST be in ascending order by TLV type. If there are m= ultiple TLVs of the same type, then the TLVs MUST be ordered in ascending ! order of the TLV value within the TLVs with the same type. All TLVs that are not specified as mandatory are considered optional. =20 3.2. The Link-State NLRI *************** *** 490,496 **** =20 The 'Total NLRI Length' field contains the cumulative length, in octets, of rest of the NLRI not including the NLRI Type field or ! itself. For VPN applications it also includes the length of the Route Distinguisher. =20 The 'NLRI Type' field can contain one of the following values: --- 491,497 ---- =20 The 'Total NLRI Length' field contains the cumulative length, in octets, of rest of the NLRI not including the NLRI Type field or ! itself. For VPN applications, it also includes the length of the Route Distinguisher. =20 The 'NLRI Type' field can contain one of the following values: *************** *** 665,671 **** transitions it may happen that two redundant IGPs are in place. =20 In section Section 3.2.1.4 a set of sub-TLVs is described, which ! allows to specify a flexible key for any given Node/Link information such that global uniqueness of the NLRI is ensured. =20 3.2.1.2. Local Node Descriptors --- 666,672 ---- transitions it may happen that two redundant IGPs are in place. =20 In section Section 3.2.1.4 a set of sub-TLVs is described, which ! allows specification of a flexible key for any given Node/Link informa= tion such that global uniqueness of the NLRI is ensured. =20 3.2.1.2. Local Node Descriptors *************** *** 749,762 **** non-Pseudonode, this contains 6 octet ISO node-ID (ISO system-ID). For an IS-IS Pseudonode corresponding to a LAN, this contains 6 octet ISO node-ID of the "Designated Intermediate System" (DIS) ! followed by one octet nonzero PSN identifier (7 octet in total). ! For an OSPFv2 or OSPFv3 non-"Pseudonode", this contains 4 octet Router-ID. For an OSPFv2 "Pseudonode" representing a LAN, this ! contains 4 octet Router-ID of the designated router (DR) followed ! by 4 octet IPv4 address of the DR's interface to the LAN (8 octet ! in total). Similarly, for an OSPFv3 "Pseudonode", this contains 4 ! octet Router-ID of the DR followed by 4 octet interface identifier ! of the DR's interface to the LAN (8 octet in total). The TLV size in combination with protocol identifier enables the decoder to determine the type of the node. =20 --- 750,763 ---- non-Pseudonode, this contains 6 octet ISO node-ID (ISO system-ID). For an IS-IS Pseudonode corresponding to a LAN, this contains 6 octet ISO node-ID of the "Designated Intermediate System" (DIS) ! followed by one octet nonzero PSN identifier (7 octets in total). ! For an OSPFv2 or OSPFv3 non-"Pseudonode", this contains the 4 octet Router-ID. For an OSPFv2 "Pseudonode" representing a LAN, this ! contains the 4 octet Router-ID of the designated router (DR) follow= ed ! by the 4 octet IPv4 address of the DR's interface to the LAN (8 oct= ets ! in total). Similarly, for an OSPFv3 "Pseudonode", this contains the= 4 ! octet Router-ID of the DR followed by the 4 octet interface identif= ier ! of the DR's interface to the LAN (8 octets in total). The TLV size in combination with protocol identifier enables the decoder to determine the type of the node. =20 *************** *** 770,777 **** =20 =20 There can be at most one instance of each sub-TLV type present in ! any Node Descriptor. The TLV ordering within a Node descriptor ! MUST be kept in order of increasing numeric value of type. This needs to be done in order to compare NLRIs, even when an implementation encounters an unknown sub-TLV. Using stable sorting an implementation can do binary comparison of NLRIs and hence --- 771,778 ---- =20 =20 There can be at most one instance of each sub-TLV type present in ! any Node Descriptor. The sub-TLVs within a Node descriptor ! MUST be arranged in ascending order by sub-TLV type. This needs to be done in order to compare NLRIs, even when an implementation encounters an unknown sub-TLV. Using stable sorting an implementation can do binary comparison of NLRIs and hence *************** *** 804,812 **** carried in the TLV. =20 The MT-ID TLV MAY be present in a Link Descriptor, a Prefix ! Descriptor, or in the BGP-LS attribute of a node NLRI. In Link or ! Prefix Descriptor, only one MT-ID TLV containing only the MT-ID of ! the topology where the link or the prefix belongs is allowed. In the =20 =20 =20 --- 805,813 ---- carried in the TLV. =20 The MT-ID TLV MAY be present in a Link Descriptor, a Prefix ! Descriptor, or in the BGP-LS attribute of a node NLRI. In a Link or ! Prefix Descriptor, only a single MT-ID TLV containing the MT-ID of ! the topology where the link or the prefix is reachable is allowed. In= the =20 =20 =20 *************** *** 828,834 **** Internet-Draft Link-State Info Distribution using BGP May 2014 =20 BGP-LS attribute of a node NLRI, one MT-ID TLV containing the array ! of MT-IDs of all topologies where the node belongs can be present. =20 3.2.2. Link Descriptors =20 --- 829,835 ---- Internet-Draft Link-State Info Distribution using BGP May 2014 =20 BGP-LS attribute of a node NLRI, one MT-ID TLV containing the array ! of MT-IDs of all topologies where the node is reachable is allowed. =20 3.2.2. Link Descriptors =20 *************** *** 838,845 **** links between a pair of anchor routers. A link described by the Link descriptor TLVs actually is a "half-link", a unidirectional representation of a logical link. In order to fully describe a ! single logical link two originating routers advertise a half-link ! each, i.e. two link NLRIs are advertised for a given point-to-point link. =20 The format and semantics of the 'value' fields in most 'Link --- 839,846 ---- links between a pair of anchor routers. A link described by the Link descriptor TLVs actually is a "half-link", a unidirectional representation of a logical link. In order to fully describe a ! single logical link, two originating routers advertise a half-link ! each, i.e., two link NLRIs are advertised for a given point-to-point link. =20 The format and semantics of the 'value' fields in most 'Link *************** *** 888,894 **** =20 If interface and neighbor addresses are not present and the link local/remote identifiers are present, then the link local/remote ! Identifier TLV is included in link descriptor. =20 The Multi-Topology Identifier TLV is included in link descriptor if that information is present. --- 889,895 ---- =20 If interface and neighbor addresses are not present and the link local/remote identifiers are present, then the link local/remote ! Identifier TLV is included in the link descriptor. =20 The Multi-Topology Identifier TLV is included in link descriptor if that information is present. *************** *** 917,924 **** OSPF Route Type is an optional TLV that MAY be present in Prefix NLRIs. It is used to identify the OSPF route-type of the prefix. It is used when an OSPF prefix is advertised in the OSPF domain with ! multiple different route-types. The Route Type TLV allows to ! discriminate these advertisements. The format of the OSPF Route Type TLV is shown in the following figure. =20 0 1 2 3 --- 918,925 ---- OSPF Route Type is an optional TLV that MAY be present in Prefix NLRIs. It is used to identify the OSPF route-type of the prefix. It is used when an OSPF prefix is advertised in the OSPF domain with ! multiple route-types. The Route Type TLV allows discrimination of=20 ! these advertisements. The format of the OSPF Route Type TLV is shown in the following figure. =20 0 1 2 3 *************** *** 957,963 **** =20 The IP Reachability Information is a mandatory TLV that contains one IP address prefix (IPv4 or IPv6) originally advertised in the IGP ! topology. Its purpose is to glue a particular BGP service NLRI vi virtue of its BGP next-hop to a given Node in the LSDB. A router SHOULD advertise an IP Prefix NLRI for each of its BGP Next-hops. The format of the IP Reachability Information TLV is shown in the --- 958,964 ---- =20 The IP Reachability Information is a mandatory TLV that contains one IP address prefix (IPv4 or IPv6) originally advertised in the IGP ! topology. Its purpose is to glue a particular BGP service NLRI by virtue of its BGP next-hop to a given Node in the LSDB. A router SHOULD advertise an IP Prefix NLRI for each of its BGP Next-hops. The format of the IP Reachability Information TLV is shown in the *************** *** 1052,1061 **** 3.3.1.2. IS-IS Area Identifier TLV =20 An IS-IS node can be part of one or more IS-IS areas. Each of these ! area addresses is carried in the IS-IS Area Identifier TLV. If more ! than one Area Addresses are present, multiple TLVs are used to encode them. The IS-IS Area Identifier TLV may be present in the BGP-LS ! attribute only with the Link-State Node NLRI. =20 =20 =20 --- 1053,1062 ---- 3.3.1.2. IS-IS Area Identifier TLV =20 An IS-IS node can be part of one or more IS-IS areas. Each of these ! area addresses is carried in the IS-IS Area Identifier TLV. If multipl= e ! Area Addresses are present, multiple TLVs are used to encode them. The IS-IS Area Identifier TLV may be present in the BGP-LS ! attribute only when advertised in the Link-State Node NLRI. =20 =20 =20 *************** *** 1087,1093 **** ToUnicode algorithm as described in [RFC5890] to achieve the correct format for transmission or display. =20 ! Altough [RFC5301] is a IS-IS specific extension, usage of the Node Name TLV is possible for all protocols. How a router derives and injects node names for e.g. OSPF nodes, is outside of the scope of this document. --- 1088,1094 ---- ToUnicode algorithm as described in [RFC5890] to achieve the correct format for transmission or display. =20 ! Altough [RFC5301] is an IS-IS specific extension, usage of the Node Name TLV is possible for all protocols. How a router derives and injects node names for e.g. OSPF nodes, is outside of the scope of this document. *************** *** 1281,1288 **** The IGP Metric TLV carries the metric for this link. The length of this TLV is variable, depending on the metric width of the underlying protocol. IS-IS small metrics have a length of 1 octet (the two most ! significant bits are ignored). OSPF metrics have a length of two ! octects. IS-IS wide-metrics have a length of three octets. =20 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 --- 1282,1289 ---- The IGP Metric TLV carries the metric for this link. The length of this TLV is variable, depending on the metric width of the underlying protocol. IS-IS small metrics have a length of 1 octet (the two most ! significant bits are ignored). OSPF link metrics have a length of two ! octets. IS-IS wide-metrics have a length of three octets. =20 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 *************** *** 1542,1549 **** =20 BGP link-state information for both IPv4 and IPv6 networks can be carried over either an IPv4 BGP session, or an IPv6 BGP session. If ! IPv4 BGP session is used, then the next hop in the MP_REACH_NLRI ! SHOULD be an IPv4 address. Similarly, if IPv6 BGP session is used, then the next hop in the MP_REACH_NLRI SHOULD be an IPv6 address. Usually the next hop will be set to the local end-point address of the BGP session. The next hop address MUST be encoded as described --- 1543,1550 ---- =20 BGP link-state information for both IPv4 and IPv6 networks can be carried over either an IPv4 BGP session, or an IPv6 BGP session. If ! an IPv4 BGP session is used, then the next hop in the MP_REACH_NLRI ! SHOULD be an IPv4 address. Similarly, if an IPv6 BGP session is used, then the next hop in the MP_REACH_NLRI SHOULD be an IPv6 address. Usually the next hop will be set to the local end-point address of the BGP session. The next hop address MUST be encoded as described *************** *** 1833,1839 **** =20 An implementation SHOULD allow the operator to specify the maximum rate at which Link-State NLRIs will be advertised/withdrawn from ! neighbors =20 An implementation SHOULD allow the operator to specify the maximum number of Link-State NLRIs stored in router's RIB. --- 1834,1840 ---- =20 An implementation SHOULD allow the operator to specify the maximum rate at which Link-State NLRIs will be advertised/withdrawn from ! neighbors. =20 An implementation SHOULD allow the operator to specify the maximum number of Link-State NLRIs stored in router's RIB. *************** *** 1846,1852 **** instance ID. =20 An implementation SHOULD allow the operator to configure a pair of ! ASN and BGP-LS identifier per flooding set the node participates in. =20 6.2.4. Accounting Management =20 --- 1847,1853 ---- instance ID. =20 An implementation SHOULD allow the operator to configure a pair of ! ASN and BGP-LS identifiers per flooding set in which the node particip= ates. =20 6.2.4. Accounting Management =20 *************** *** 1981,1987 **** Speaker. =20 An operator SHOULD employ a mechanism to protect a BGP Speaker ! against DDOS attacks from Consumers. The principal attack a consumer may apply is to attempt to start multiple sessions either sequentially or simultaneously. Protection can be applied by imposing rate limits. --- 1982,1988 ---- Speaker. =20 An operator SHOULD employ a mechanism to protect a BGP Speaker ! against DDoS attacks from Consumers. The principal attack a consumer may apply is to attempt to start multiple sessions either sequentially or simultaneously. Protection can be applied by imposing rate limits. Thanks, Acee=20 From nobody Wed Sep 10 13:57:39 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21D6B1A0648 for ; Wed, 10 Sep 2014 00:22:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NOod_KFdBkfN for ; Wed, 10 Sep 2014 00:22:02 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0723.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::723]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8D8D1A0652 for ; Wed, 10 Sep 2014 00:22:01 -0700 (PDT) Received: from BLUPR05MB435.namprd05.prod.outlook.com (10.141.27.150) by BLUPR05MB403.namprd05.prod.outlook.com (10.141.26.144) with Microsoft SMTP Server (TLS) id 15.0.1024.12; Wed, 10 Sep 2014 07:20:16 +0000 Received: from hannes-mba.local (193.110.55.14) by BLUPR05MB435.namprd05.prod.outlook.com (10.141.27.150) with Microsoft SMTP Server (TLS) id 15.0.1024.12; Wed, 10 Sep 2014 07:20:15 +0000 Received: from hannes-mba.local (localhost [IPv6:::1]) by hannes-mba.local (Postfix) with ESMTP id 494FE2DC557; Wed, 10 Sep 2014 09:20:05 +0200 (CEST) Date: Wed, 10 Sep 2014 09:20:05 +0200 From: Hannes Gredler To: "Acee Lindem (acee)" Message-ID: <20140910072004.GA13913@hannes-mba.local> References: <55E298DE-B369-493A-84E3-C33CA72689AD@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <55E298DE-B369-493A-84E3-C33CA72689AD@cisco.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Originating-IP: [193.110.55.14] X-ClientProxiedBy: DB4PR04CA0023.eurprd04.prod.outlook.com (25.160.41.33) To BLUPR05MB435.namprd05.prod.outlook.com (10.141.27.150) X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;UriScan:;UriScan:; X-Forefront-PRVS: 033054F29A X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019019)(6009001)(24454002)(199003)(52604005)(164054003)(189002)(86362001)(64706001)(92566001)(92726001)(79102001)(54356999)(50986999)(66066001)(106356001)(107046002)(47776003)(46102001)(31966008)(20776003)(95666004)(50466002)(81542001)(105586002)(74502001)(74662001)(81342001)(76482001)(76176999)(21056001)(87976001)(76506005)(77096002)(23676002)(99396002)(101416001)(230783001)(83072002)(85852003)(4396001)(110136001)(80022001)(97736003)(102836001)(85306004)(15202345003)(19580395003)(83322001)(77982001)(33656002)(15975445006)(83506001)(98436002)(90102001)(579124003); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB435; H:hannes-mba.local; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/idr/_SCLEh1BOKlEIvGSLj_kAsGVDQ4 X-Mailman-Approved-At: Wed, 10 Sep 2014 13:57:27 -0700 Cc: IDR WG List , Adrian Farrel , Routing Directorate , Routing ADs Subject: Re: [Idr] Routing Directorate Review of draft-ietf-idr-ls-distribution-05.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 07:22:06 -0000 hi acee, thanks for reviewing the document thoroughly. see comments/responses inline. On Tue, Sep 09, 2014 at 11:33:10PM +0000, Acee Lindem (acee) wrote: | Major Issues: | | 1. The draft should indicate the overall goal of translating the IGP link state database and TE Database into a generic representation. It should also better enumerate the requirements for this translation. main reason is to spare the controllers the need of alwys requiring to understand two protocols. AI: i'll add a note. | 2. The draft includes opaque attribute TLVs for advertising protocol-specific information (node, link, and prefix). However, there is no indication on how this information is encoded or identified. Hence, there can be no interoperability between implementations. we have defined opaque containers for the document lag between defining 1) a new IGP extension 2) the BGP extension being published it is expected that those opaque carriers are only used in vendor private extensions. AI: i'll add a note | 3. The draft is based mainly on ISIS encoding and does a poor job of representing the OSPF. Examples include: the draft is a "protocol neutral" representation of node/links and prefixes. wherever possible we have put in reference to the message format of the original IS-IS spec as we found it generally easier to read (sorry acee). there is no point of adding a second pointer to the relvant OSPF spec. as sometimes the format of those OSPF-TLVs differs from IS-IS | A. Page 10 - There is no protocol-id for OSPFv3. AI: i'll add a protocol code for it. | B. Page 11 - Why is RFC 6822 normative and RFC 6549 informational? AI: i'll move it into normative. | C. Psuedonode Representation - The absence of a condensed format for the pseudonode following the OSPF model. AI: i'll add an OSPF example after section 3.6. | D. Page 15 - Relevant OSPF RFCs should be referenced for TLV code points. there is no single OSPF RFC representing the information which is encoded here. again - this is not a lets wrap OSPF and IS-IS spec - it is a protocol neutral representation of nodes, links and prefixes - if the BGP-LS message format is identical to IS-IS we have picked IS_IS as a reference. | E. Page 18 - Why an ISIS Area identifier and not an OSPF Area identifier? there is - see TLV 514 AI: i'll rename 514 as 'OSPF Area-ID' | F. Page 18 - 'E' is for an ASBR and 'B' is for ABR. AI: change the name but keep the bit value. | G. Page 19 - RFC 5642 is the OSPF Node Name RFC. see answer to comment 3). | H. Page 21 - Should be references to OSPF RFC, RFC 3630, RFC 4203, and RFC 5329. see answer to comment 3). | I. Page 22 - OSPF Link metrics are 2 bytes but OSPF prefix metrics are 3 bytes. thats why the 'IGP metric' is variable length. | J. Page 25 - OSPF Prefix Options are defined in RFC 5340, A.4.1.1. It not clear which need to be advertised. good point - AI: add a reference to rfc5340 and copy teh flags descriptions | K. Page 26 - Forwarding Address for OSPFv3 should reference RFC 5340 as well. AI: add reference | 4. Section 3.2.15 - Why do you limit a link or prefix to a single MT-ID? Links and prefixes can be reachable in multiple topologies with different metrics. Is this simply a typo? there is no limit to a single MT-ID, the provided references as well as the TLV siziing (N* ...) indicate that this is a variable length TLV. AI: add text to say that this TLV is used to advertise memebership in 'one or more' topologies. | Minor Issues: | 1. Figures and tables are referenced by number, yet those figures and tables are not numbered. thats an artifact of xml2rfc on mac - i'll render the next version under unix which has gotten it right. | 2. Several acronymns that are not designated as well-known are not expanded with the first usage. Examples include LSDB and TED. Refer to http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt. AI: let me fix that | 3. Page 11 - The table mentions L1 optical topology but there are are no optical attributes. This seems like it should be removed and added when GMPLS information is defined for BGP LS. we did want to lock the codepoint as some are mocking with BGP-LS as an NNI protocol for optical. - | 4. Page 11 - The BGP-LS Identifier is referenced before it is defined. AI: add a forward reference in section 3.2.1.4 | 5. Page 17 - In the context of this NRLI, what purpose does the next hop address serve? If none, couldn't we just advertise a 0 length network address? AI: add clarification text that the BGP-NH serves solely the purpose of BGP path tie-breaking based on IGP distance. | 6. Page 18 - Why isn't the IS-IS Area Identifier applicable to prefixes? OSPF can scope prefixes to areas (unless they AS-External). different schemas - in IS-IS an Area is an attribute of a node, vs. in OSPF its an attribute of an interface. | 7. For FQDN node/link name recommendation - should usage dictate "RECOMMENDED" rather than "recommended”? AI: RECOMMENDE | 8. Page 21 - Is knowing whether MPLS signaling is enabled on a link all that is needed by the applications? This seems somewhat out of place with the LSDB and TE data. thats use when the BGP-LS data are not generated by redistibution of an LSDB or TED but rather is generated 'direct' (using protocol code 'direct') - i.e. every node ina an IGP domain becomes a publisher of its local link-state data. AI: add a note that this only applies for generation of using protocol 'direct' | Nits: | | *************** | *** 21,27 **** | called upon to perform computations based on the network topology and | current state of the connections within the network, including | traffic engineering information. This is information typically | ! distributed by IGP routing protocols within the network | | This document describes a mechanism by which links state and traffic | engineering information can be collected from networks and shared | --- 21,27 ---- | called upon to perform computations based on the network topology and | current state of the connections within the network, including | traffic engineering information. This is information typically | ! distributed by IGP routing protocols within the network. | | This document describes a mechanism by which links state and traffic | engineering information can be collected from networks and shared | *************** | *** 246,252 **** | routers in a POP. Abstracted topology can also be a mix of physical | and virtual nodes and physical and virtual links. Furthermore, the | BGP Speaker can apply policy to determine when information is updated | ! to the consumer so that there is reduction of information flow form | the network to the consumers. Mechanisms through which topologies | can be aggregated or virtualized are outside the scope of this | document | --- 246,252 ---- | routers in a POP. Abstracted topology can also be a mix of physical | and virtual nodes and physical and virtual links. Furthermore, the | BGP Speaker can apply policy to determine when information is updated | ! to the consumer so that there is reduction of information flow from | the network to the consumers. Mechanisms through which topologies | can be aggregated or virtualized are outside the scope of this | document | *************** | *** 267,278 **** | policy control and algorithms, and coordination of computation | across the whole area. | | ! o If a router wants to compute a MPLS-TE path across IGP areas its | own TED lacks visibility of the complete topology. That means | that the router cannot determine the end-to-end path, and cannot | even select the right exit router (Area Border Router - ABR) for | an optimal path. This is an issue for large-scale networks that | ! need to segment their core networks into distinct areas, but which | still want to take advantage of MPLS-TE. | | Previous solutions used per-domain path computation [RFC5152]. The | --- 267,279 ---- | policy control and algorithms, and coordination of computation | across the whole area. | | ! o If a router wants to compute an MPLS-TE path across multiple IGP | ! areas, then its | own TED lacks visibility of the complete topology. That means | that the router cannot determine the end-to-end path, and cannot | even select the right exit router (Area Border Router - ABR) for | an optimal path. This is an issue for large-scale networks that | ! need to segment their core networks into distinct areas, but | still want to take advantage of MPLS-TE. | | Previous solutions used per-domain path computation [RFC5152]. The | *************** | *** 426,434 **** | (thus a TLV with no value portion would have a length of zero). The | TLV is not padded to four-octet alignment. Unrecognized types are | preserved and propagated. In order to compare NLRIs with unknown | ! TLVs all TLVs MUST be ordered in ascending order. If there are more | TLVs of the same type, then the TLVs MUST be ordered in ascending | ! order of the TLV value within the set of TLVs with the same type. | All TLVs that are not specified as mandatory are considered optional. | | 3.2. The Link-State NLRI | --- 427,435 ---- | (thus a TLV with no value portion would have a length of zero). The | TLV is not padded to four-octet alignment. Unrecognized types are | preserved and propagated. In order to compare NLRIs with unknown | ! TLVs, all TLVs MUST be in ascending order by TLV type. If there are multiple | TLVs of the same type, then the TLVs MUST be ordered in ascending | ! order of the TLV value within the TLVs with the same type. | All TLVs that are not specified as mandatory are considered optional. | | 3.2. The Link-State NLRI | *************** | *** 490,496 **** | | The 'Total NLRI Length' field contains the cumulative length, in | octets, of rest of the NLRI not including the NLRI Type field or | ! itself. For VPN applications it also includes the length of the | Route Distinguisher. | | The 'NLRI Type' field can contain one of the following values: | --- 491,497 ---- | | The 'Total NLRI Length' field contains the cumulative length, in | octets, of rest of the NLRI not including the NLRI Type field or | ! itself. For VPN applications, it also includes the length of the | Route Distinguisher. | | The 'NLRI Type' field can contain one of the following values: | *************** | *** 665,671 **** | transitions it may happen that two redundant IGPs are in place. | | In section Section 3.2.1.4 a set of sub-TLVs is described, which | ! allows to specify a flexible key for any given Node/Link information | such that global uniqueness of the NLRI is ensured. | | 3.2.1.2. Local Node Descriptors | --- 666,672 ---- | transitions it may happen that two redundant IGPs are in place. | | In section Section 3.2.1.4 a set of sub-TLVs is described, which | ! allows specification of a flexible key for any given Node/Link information | such that global uniqueness of the NLRI is ensured. | | 3.2.1.2. Local Node Descriptors | *************** | *** 749,762 **** | non-Pseudonode, this contains 6 octet ISO node-ID (ISO system-ID). | For an IS-IS Pseudonode corresponding to a LAN, this contains 6 | octet ISO node-ID of the "Designated Intermediate System" (DIS) | ! followed by one octet nonzero PSN identifier (7 octet in total). | ! For an OSPFv2 or OSPFv3 non-"Pseudonode", this contains 4 octet | Router-ID. For an OSPFv2 "Pseudonode" representing a LAN, this | ! contains 4 octet Router-ID of the designated router (DR) followed | ! by 4 octet IPv4 address of the DR's interface to the LAN (8 octet | ! in total). Similarly, for an OSPFv3 "Pseudonode", this contains 4 | ! octet Router-ID of the DR followed by 4 octet interface identifier | ! of the DR's interface to the LAN (8 octet in total). The TLV size | in combination with protocol identifier enables the decoder to | determine the type of the node. | | --- 750,763 ---- | non-Pseudonode, this contains 6 octet ISO node-ID (ISO system-ID). | For an IS-IS Pseudonode corresponding to a LAN, this contains 6 | octet ISO node-ID of the "Designated Intermediate System" (DIS) | ! followed by one octet nonzero PSN identifier (7 octets in total). | ! For an OSPFv2 or OSPFv3 non-"Pseudonode", this contains the 4 octet | Router-ID. For an OSPFv2 "Pseudonode" representing a LAN, this | ! contains the 4 octet Router-ID of the designated router (DR) followed | ! by the 4 octet IPv4 address of the DR's interface to the LAN (8 octets | ! in total). Similarly, for an OSPFv3 "Pseudonode", this contains the 4 | ! octet Router-ID of the DR followed by the 4 octet interface identifier | ! of the DR's interface to the LAN (8 octets in total). The TLV size | in combination with protocol identifier enables the decoder to | determine the type of the node. | | *************** | *** 770,777 **** | | | There can be at most one instance of each sub-TLV type present in | ! any Node Descriptor. The TLV ordering within a Node descriptor | ! MUST be kept in order of increasing numeric value of type. This | needs to be done in order to compare NLRIs, even when an | implementation encounters an unknown sub-TLV. Using stable sorting | an implementation can do binary comparison of NLRIs and hence | --- 771,778 ---- | | | There can be at most one instance of each sub-TLV type present in | ! any Node Descriptor. The sub-TLVs within a Node descriptor | ! MUST be arranged in ascending order by sub-TLV type. This | needs to be done in order to compare NLRIs, even when an | implementation encounters an unknown sub-TLV. Using stable sorting | an implementation can do binary comparison of NLRIs and hence | *************** | *** 804,812 **** | carried in the TLV. | | The MT-ID TLV MAY be present in a Link Descriptor, a Prefix | ! Descriptor, or in the BGP-LS attribute of a node NLRI. In Link or | ! Prefix Descriptor, only one MT-ID TLV containing only the MT-ID of | ! the topology where the link or the prefix belongs is allowed. In the | | | | --- 805,813 ---- | carried in the TLV. | | The MT-ID TLV MAY be present in a Link Descriptor, a Prefix | ! Descriptor, or in the BGP-LS attribute of a node NLRI. In a Link or | ! Prefix Descriptor, only a single MT-ID TLV containing the MT-ID of | ! the topology where the link or the prefix is reachable is allowed. In the | | | | *************** | *** 828,834 **** | Internet-Draft Link-State Info Distribution using BGP May 2014 | | BGP-LS attribute of a node NLRI, one MT-ID TLV containing the array | ! of MT-IDs of all topologies where the node belongs can be present. | | 3.2.2. Link Descriptors | | --- 829,835 ---- | Internet-Draft Link-State Info Distribution using BGP May 2014 | | BGP-LS attribute of a node NLRI, one MT-ID TLV containing the array | ! of MT-IDs of all topologies where the node is reachable is allowed. | | 3.2.2. Link Descriptors | | *************** | *** 838,845 **** | links between a pair of anchor routers. A link described by the Link | descriptor TLVs actually is a "half-link", a unidirectional | representation of a logical link. In order to fully describe a | ! single logical link two originating routers advertise a half-link | ! each, i.e. two link NLRIs are advertised for a given point-to-point | link. | | The format and semantics of the 'value' fields in most 'Link | --- 839,846 ---- | links between a pair of anchor routers. A link described by the Link | descriptor TLVs actually is a "half-link", a unidirectional | representation of a logical link. In order to fully describe a | ! single logical link, two originating routers advertise a half-link | ! each, i.e., two link NLRIs are advertised for a given point-to-point | link. | | The format and semantics of the 'value' fields in most 'Link | *************** | *** 888,894 **** | | If interface and neighbor addresses are not present and the link | local/remote identifiers are present, then the link local/remote | ! Identifier TLV is included in link descriptor. | | The Multi-Topology Identifier TLV is included in link descriptor | if that information is present. | --- 889,895 ---- | | If interface and neighbor addresses are not present and the link | local/remote identifiers are present, then the link local/remote | ! Identifier TLV is included in the link descriptor. | | The Multi-Topology Identifier TLV is included in link descriptor | if that information is present. | *************** | *** 917,924 **** | OSPF Route Type is an optional TLV that MAY be present in Prefix | NLRIs. It is used to identify the OSPF route-type of the prefix. It | is used when an OSPF prefix is advertised in the OSPF domain with | ! multiple different route-types. The Route Type TLV allows to | ! discriminate these advertisements. The format of the OSPF Route Type | TLV is shown in the following figure. | | 0 1 2 3 | --- 918,925 ---- | OSPF Route Type is an optional TLV that MAY be present in Prefix | NLRIs. It is used to identify the OSPF route-type of the prefix. It | is used when an OSPF prefix is advertised in the OSPF domain with | ! multiple route-types. The Route Type TLV allows discrimination of | ! these advertisements. The format of the OSPF Route Type | TLV is shown in the following figure. | | 0 1 2 3 | *************** | *** 957,963 **** | | The IP Reachability Information is a mandatory TLV that contains one | IP address prefix (IPv4 or IPv6) originally advertised in the IGP | ! topology. Its purpose is to glue a particular BGP service NLRI vi | virtue of its BGP next-hop to a given Node in the LSDB. A router | SHOULD advertise an IP Prefix NLRI for each of its BGP Next-hops. | The format of the IP Reachability Information TLV is shown in the | --- 958,964 ---- | | The IP Reachability Information is a mandatory TLV that contains one | IP address prefix (IPv4 or IPv6) originally advertised in the IGP | ! topology. Its purpose is to glue a particular BGP service NLRI by | virtue of its BGP next-hop to a given Node in the LSDB. A router | SHOULD advertise an IP Prefix NLRI for each of its BGP Next-hops. | The format of the IP Reachability Information TLV is shown in the | *************** | *** 1052,1061 **** | 3.3.1.2. IS-IS Area Identifier TLV | | An IS-IS node can be part of one or more IS-IS areas. Each of these | ! area addresses is carried in the IS-IS Area Identifier TLV. If more | ! than one Area Addresses are present, multiple TLVs are used to encode | them. The IS-IS Area Identifier TLV may be present in the BGP-LS | ! attribute only with the Link-State Node NLRI. | | | | --- 1053,1062 ---- | 3.3.1.2. IS-IS Area Identifier TLV | | An IS-IS node can be part of one or more IS-IS areas. Each of these | ! area addresses is carried in the IS-IS Area Identifier TLV. If multiple | ! Area Addresses are present, multiple TLVs are used to encode | them. The IS-IS Area Identifier TLV may be present in the BGP-LS | ! attribute only when advertised in the Link-State Node NLRI. | | | | *************** | *** 1087,1093 **** | ToUnicode algorithm as described in [RFC5890] to achieve the correct | format for transmission or display. | | ! Altough [RFC5301] is a IS-IS specific extension, usage of the Node | Name TLV is possible for all protocols. How a router derives and | injects node names for e.g. OSPF nodes, is outside of the scope of | this document. | --- 1088,1094 ---- | ToUnicode algorithm as described in [RFC5890] to achieve the correct | format for transmission or display. | | ! Altough [RFC5301] is an IS-IS specific extension, usage of the Node | Name TLV is possible for all protocols. How a router derives and | injects node names for e.g. OSPF nodes, is outside of the scope of | this document. | *************** | *** 1281,1288 **** | The IGP Metric TLV carries the metric for this link. The length of | this TLV is variable, depending on the metric width of the underlying | protocol. IS-IS small metrics have a length of 1 octet (the two most | ! significant bits are ignored). OSPF metrics have a length of two | ! octects. IS-IS wide-metrics have a length of three octets. | | 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 | --- 1282,1289 ---- | The IGP Metric TLV carries the metric for this link. The length of | this TLV is variable, depending on the metric width of the underlying | protocol. IS-IS small metrics have a length of 1 octet (the two most | ! significant bits are ignored). OSPF link metrics have a length of two | ! octets. IS-IS wide-metrics have a length of three octets. | | 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 | *************** | *** 1542,1549 **** | | BGP link-state information for both IPv4 and IPv6 networks can be | carried over either an IPv4 BGP session, or an IPv6 BGP session. If | ! IPv4 BGP session is used, then the next hop in the MP_REACH_NLRI | ! SHOULD be an IPv4 address. Similarly, if IPv6 BGP session is used, | then the next hop in the MP_REACH_NLRI SHOULD be an IPv6 address. | Usually the next hop will be set to the local end-point address of | the BGP session. The next hop address MUST be encoded as described | --- 1543,1550 ---- | | BGP link-state information for both IPv4 and IPv6 networks can be | carried over either an IPv4 BGP session, or an IPv6 BGP session. If | ! an IPv4 BGP session is used, then the next hop in the MP_REACH_NLRI | ! SHOULD be an IPv4 address. Similarly, if an IPv6 BGP session is used, | then the next hop in the MP_REACH_NLRI SHOULD be an IPv6 address. | Usually the next hop will be set to the local end-point address of | the BGP session. The next hop address MUST be encoded as described | *************** | *** 1833,1839 **** | | An implementation SHOULD allow the operator to specify the maximum | rate at which Link-State NLRIs will be advertised/withdrawn from | ! neighbors | | An implementation SHOULD allow the operator to specify the maximum | number of Link-State NLRIs stored in router's RIB. | --- 1834,1840 ---- | | An implementation SHOULD allow the operator to specify the maximum | rate at which Link-State NLRIs will be advertised/withdrawn from | ! neighbors. | | An implementation SHOULD allow the operator to specify the maximum | number of Link-State NLRIs stored in router's RIB. | *************** | *** 1846,1852 **** | instance ID. | | An implementation SHOULD allow the operator to configure a pair of | ! ASN and BGP-LS identifier per flooding set the node participates in. | | 6.2.4. Accounting Management | | --- 1847,1853 ---- | instance ID. | | An implementation SHOULD allow the operator to configure a pair of | ! ASN and BGP-LS identifiers per flooding set in which the node participates. | | 6.2.4. Accounting Management | | *************** | *** 1981,1987 **** | Speaker. | | An operator SHOULD employ a mechanism to protect a BGP Speaker | ! against DDOS attacks from Consumers. The principal attack a consumer | may apply is to attempt to start multiple sessions either | sequentially or simultaneously. Protection can be applied by | imposing rate limits. | --- 1982,1988 ---- | Speaker. | | An operator SHOULD employ a mechanism to protect a BGP Speaker | ! against DDoS attacks from Consumers. The principal attack a consumer | may apply is to attempt to start multiple sessions either | sequentially or simultaneously. Protection can be applied by | imposing rate limits. | | Thanks, | Acee | From nobody Wed Sep 10 17:46:50 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1C8A1A01C3 for ; Wed, 10 Sep 2014 17:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.153 X-Spam-Level: X-Spam-Status: No, score=-16.153 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, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9klErGYiR2E for ; Wed, 10 Sep 2014 17:46:45 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11FFC1A01A5 for ; Wed, 10 Sep 2014 17:46:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3771; q=dns/txt; s=iport; t=1410396405; x=1411606005; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=h3DeYDlsN04Q36u9Hfb0XfbSevwFRsQdicIvuB4ldBw=; b=S4T+iULB1ULol1nMF5d+7A4B72HsOYPV6j5TmY1bto9zutmtckw0qk5S ti2gA4ahR92xv+hGSTxvQOGhoQkPNMPCLmGHYlxTOJUoVn4vL0Pel26on 8e9YjTr+WKgLMUlzRRya94wCUyAAhrSfWGk5RmPvoSJ+eQq04rDGqR26N k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkYGAJfwEFStJV2Z/2dsb2JhbABggw1TWAPKRodNgRIWeIQKOj8SARwiBT0nBA6IRw2/QgEXjAuBPIIGgzaBHQWRSYQwhwOBX5NaghuBRm2BR4EHAQEB X-IronPort-AV: E=Sophos;i="5.04,502,1406592000"; d="scan'208";a="76844467" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-8.cisco.com with ESMTP; 11 Sep 2014 00:46:42 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s8B0kgOH027822 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 11 Sep 2014 00:46:42 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.175]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Wed, 10 Sep 2014 19:46:42 -0500 From: "Acee Lindem (acee)" To: Routing ADs Thread-Topic: Routing Directorate Review of BGP Link-State Implementation Report - draft-ietf-idr-ls-distribution-impl-00 Thread-Index: AQHPzVnajFAw10UsVkKzKiJRCBO/Dw== Date: Thu, 11 Sep 2014 00:46:41 +0000 Message-ID: <330B37F3-2955-4AB6-A2D7-F9EACAB94CC6@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.152.198] Content-Type: text/plain; charset="us-ascii" Content-ID: <6BB4F85858D20947BDE15B5AA4DBF962@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/Mkh5hJou6grKa_GI19DEUU76SJc Cc: IDR WG List , Routing Directorate Subject: [Idr] Routing Directorate Review of BGP Link-State Implementation Report - draft-ietf-idr-ls-distribution-impl-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 00:46:48 -0000 Hi, I have been selected as the Routing Directorate reviewer for this draft. Th= e Routing Directorate seeks to review all routing or routing-related drafts= as they pass through IETF last call and IESG review. The purpose of the re= view is to provide assistance to the Routing ADs. For more information abou= t the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/t= rac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it wo= uld be helpful if you could consider them along with any other IETF Last Ca= ll comments that you receive, and strive to resolve them through discussion= or by updating the draft. Document: BGP Link-State Information Distribution Implementation Report - = draft-ietf-idr-ls-distribution-impl-00 Reviewer: Acee Lindem Review Date: 09/10/2014 Current WG Document Intended Status: Informational Summary: This is an implementation report for the BGP LS protocol mechanism= s. The vendors were Cisco IOS-XR, Juniper JUNOS, and OpenDayLight. Basicall= y, the document is ready for informational publication.=20 Major Issues: None Minor Issues: =20 It would be good to state the scope of the test in the "Introduction" secti= on. At least, there should be a statement that solely the BGP advertisement= of Link-State information and its successful reception were tested. This i= s apparent from the testing results in the subsequent sections but it would= be good to state this up front.=20 Nits:=20 *** draft-ietf-idr-ls-distribution-impl-00.txt 2014-09-10 18:13:08.0000000= 00 -0400 --- draft-ietf-idr-ls-distribution-impl-acee.txt 2014-09-10 20:22= :21.000000000 -0400 *************** *** 621,627 **** =20 Juniper: The Juniper Networks, Inc. JUNOS implementation should be interoperable with other vendor BGP-LS Protocol implementations. In ! particular, we have tested our interoperability with Cisco Systems, Inc. IOS-XR implementation and the Opendaylight implementation. =20 7.3. OpenDaylight Implementation --- 621,627 ---- =20 Juniper: The Juniper Networks, Inc. JUNOS implementation should be interoperable with other vendor BGP-LS Protocol implementations. In ! particular, we have tested our interoperability with the Cisco Systems= , Inc. IOS-XR implementation and the Opendaylight implementation. =20 7.3. OpenDaylight Implementation *************** *** 630,637 **** with other vendor BGP-LS Protocol implementations. In particular, we have tested our interoperability with Juniper's JUNOS implementation and the Cisco Systems, Inc. IOS-XR implementation. BGP receiver is ! implemented in OpenDaylight Hydrogen release. BGP sender ! functionality is planned in upcoming Helium release. =20 =20 8. IANA Considerations --- 630,637 ---- with other vendor BGP-LS Protocol implementations. In particular, we have tested our interoperability with Juniper's JUNOS implementation and the Cisco Systems, Inc. IOS-XR implementation. BGP receiver is ! implemented in the OpenDaylight Hydrogen release. BGP sender ! functionality is planned in the upcoming Helium release. =20 =20 8. IANA Considerations *************** *** 645,651 **** =20 9. Security considerations =20 ! No new security issues are introduced to the BGP Link-State Information Distribution Protocol defined in [I-D.ietf-idr-ls-distribution]. =20 --- 645,651 ---- =20 9. Security considerations =20 ! No new security issues are introduced by the BGP Link-State Information Distribution Protocol defined in [I-D.ietf-idr-ls-distribution]. Thanks, Acee=20 From nobody Wed Sep 10 17:50:01 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3825E1A0278 for ; Wed, 10 Sep 2014 17:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.153 X-Spam-Level: X-Spam-Status: No, score=-16.153 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, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rVUSTRIW89gn for ; Wed, 10 Sep 2014 17:49:58 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 434361A01C3 for ; Wed, 10 Sep 2014 17:49:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3820; q=dns/txt; s=iport; t=1410396600; x=1411606200; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=MIJXXTQT+VAVDEs9UZ+JwnqihQyhiaB2n55UHRGF1vM=; b=WSmuGpkyH63iEFfoZmvY+GLAktRZ8Bu/e0J0tEwlKCcA5j2WAviS/+ni hdcmLvdhTU+dKoHix2ARJdTE4lip1XJe3OojUONLDH8hl8uUc9U8XeQnU LCFRiyUQasEOMVa6eNblVYiN5pIzmT1PkuHta2Szsixf2lKHEwMyu35sA 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFALDwEFStJV2Z/2dsb2JhbABggw1TW8o8CodNgRIWeIQFAQQBAQE3NAsSARwiBTILJwQOBYhCDb9CAReMC4E8ggaDNoEdBZFJhDCHA4Ffk1qCG4FGbAGBR4EHAQEB X-IronPort-AV: E=Sophos;i="5.04,502,1406592000"; d="scan'208";a="76847260" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-7.cisco.com with ESMTP; 11 Sep 2014 00:49:59 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s8B0nvgs030610 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 11 Sep 2014 00:49:57 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.175]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Wed, 10 Sep 2014 19:49:57 -0500 From: "Acee Lindem (acee)" To: Routing ADs Thread-Topic: [Idr] Routing Directorate Review of BGP Link-State Implementation Report - draft-ietf-idr-ls-distribution-impl-00 (Authors copied) Thread-Index: AQHPzVpOuz3l3Rp4nE6jG0zHGw01Qg== Date: Thu, 11 Sep 2014 00:49:56 +0000 Message-ID: <06858FA6-EE4D-4A42-9E51-51CD061B6BE4@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.152.198] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/3mY4nWkqjz91bHFFEVfSiKEPY58 Cc: IDR WG List , Routing Directorate Subject: [Idr] Routing Directorate Review of BGP Link-State Implementation Report - draft-ietf-idr-ls-distribution-impl-00 (Authors copied) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 00:50:00 -0000 Hi, I have been selected as the Routing Directorate reviewer for this draft. Th= e Routing Directorate seeks to review all routing or routing-related drafts= as they pass through IETF last call and IESG review. The purpose of the re= view is to provide assistance to the Routing ADs. For more information abou= t the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/t= rac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it wo= uld be helpful if you could consider them along with any other IETF Last Ca= ll comments that you receive, and strive to resolve them through discussion= or by updating the draft. Document: BGP Link-State Information Distribution Implementation Report - = draft-ietf-idr-ls-distribution-impl-00 Reviewer: Acee Lindem Review Date: 09/10/2014 Current WG Document Intended Status: Informational Summary: This is an implementation report for the BGP LS protocol mechanism= s. The vendors were Cisco IOS-XR, Juniper JUNOS, and OpenDayLight. Basicall= y, the document is ready for informational publication.=20 Major Issues: None Minor Issues: It would be good to state the scope of the test in the "Introduction" secti= on. At least, there should be a statement that solely the BGP advertisement= of Link-State information and its successful reception were tested. This i= s apparent from the testing results in the subsequent sections but it would= be good to state this up front.=20 Nits:=20 *** draft-ietf-idr-ls-distribution-impl-00.txt 2014-09-10 18:13:08.0000000= 00 -0400 --- draft-ietf-idr-ls-distribution-impl-acee.txt 2014-09-10 20:22= :21.000000000 -0400 *************** *** 621,627 **** Juniper: The Juniper Networks, Inc. JUNOS implementation should be interoperable with other vendor BGP-LS Protocol implementations. In ! particular, we have tested our interoperability with Cisco Systems, Inc. IOS-XR implementation and the Opendaylight implementation. 7.3. OpenDaylight Implementation --- 621,627 ---- Juniper: The Juniper Networks, Inc. JUNOS implementation should be interoperable with other vendor BGP-LS Protocol implementations. In ! particular, we have tested our interoperability with the Cisco Systems= , Inc. IOS-XR implementation and the Opendaylight implementation. 7.3. OpenDaylight Implementation *************** *** 630,637 **** with other vendor BGP-LS Protocol implementations. In particular, we have tested our interoperability with Juniper's JUNOS implementation and the Cisco Systems, Inc. IOS-XR implementation. BGP receiver is ! implemented in OpenDaylight Hydrogen release. BGP sender ! functionality is planned in upcoming Helium release. 8. IANA Considerations --- 630,637 ---- with other vendor BGP-LS Protocol implementations. In particular, we have tested our interoperability with Juniper's JUNOS implementation and the Cisco Systems, Inc. IOS-XR implementation. BGP receiver is ! implemented in the OpenDaylight Hydrogen release. BGP sender ! functionality is planned in the upcoming Helium release. 8. IANA Considerations *************** *** 645,651 **** 9. Security considerations ! No new security issues are introduced to the BGP Link-State Information Distribution Protocol defined in [I-D.ietf-idr-ls-distribution]. --- 645,651 ---- 9. Security considerations ! No new security issues are introduced by the BGP Link-State Information Distribution Protocol defined in [I-D.ietf-idr-ls-distribution]. Thanks, Acee=20 _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From nobody Thu Sep 11 11:34:48 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F25BB1A8A89; Thu, 11 Sep 2014 11:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.153 X-Spam-Level: X-Spam-Status: No, score=-16.153 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, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D2PpfNgzlUcq; Thu, 11 Sep 2014 11:00:12 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D4AB1A8A06; Thu, 11 Sep 2014 10:58:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=38278; q=dns/txt; s=iport; t=1410458317; x=1411667917; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=KL0dmv6rTqe0FesPuoObcY6UFxhzoq5NAG2TFYGIZEg=; b=cWIyhfZ6h8F4m2h0lJJ7okgkpXSnK9cvfxW1lUPQqtqeFdEt2EtTGjZZ jAFjbufKN7I681EGRHtxbCXPyAXUHLm6PVpqt6sbdtxyWf6qdi4MvM7Qm SwIcIiJF6dzqMuMy0dnPq8QcPiCSqm1wTIzECkaldpqe9WKdV26UPkVtR E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFADjiEVStJV2b/2dsb2JhbABVCoMNU1cEgnjFUYdNGngWeIQEAQEEGhozEhIBCBgEKAQwJwQOBRuIJw2MYpw9BpVTAReBJohahHEFJBgbgnqBWQWRS4ZwhEaVO4FnCBYWgUZsAQGBBUGBBwEBAQ X-IronPort-AV: E=Sophos;i="5.04,506,1406592000"; d="scan'208";a="354572052" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 11 Sep 2014 17:58:35 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s8BHwZor022038 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 11 Sep 2014 17:58:35 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.175]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0195.001; Thu, 11 Sep 2014 12:58:35 -0500 From: "Acee Lindem (acee)" To: Hannes Gredler Thread-Topic: Routing Directorate Review of draft-ietf-idr-ls-distribution-05.txt (Reply to this one) Thread-Index: AQHPzeoBVo5C9YidS0GyR46JmNf+XQ== Date: Thu, 11 Sep 2014 17:58:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.152.196] Content-Type: text/plain; charset="euc-kr" Content-ID: <43DF6EB10C3D7348853E1D238E3B21A2@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/MSJH9BLdnbskZamsqPVdXbmc0f8 X-Mailman-Approved-At: Thu, 11 Sep 2014 11:34:46 -0700 Cc: IDR WG List , Routing Directorate , Adrian Farrel , Routing ADs Subject: Re: [Idr] Routing Directorate Review of draft-ietf-idr-ls-distribution-05.txt (Reply to this one) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 18:00:17 -0000 SGkgSGFubmVzLCANCg0KT24gOS8xMC8xNCwgMzoyMCBBTSwgIkhhbm5lcyBHcmVkbGVyIiA8aGFu bmVzQGp1bmlwZXIubmV0PiB3cm90ZToNCg0KPmhpIGFjZWUsDQo+DQo+dGhhbmtzIGZvciByZXZp ZXdpbmcgdGhlIGRvY3VtZW50IHRob3JvdWdobHkuIHNlZSBjb21tZW50cy9yZXNwb25zZXMNCj5p bmxpbmUuDQo+DQo+T24gVHVlLCBTZXAgMDksIDIwMTQgYXQgMTE6MzM6MTBQTSArMDAwMCwgQWNl ZSBMaW5kZW0gKGFjZWUpIHdyb3RlOg0KPnwgTWFqb3IgSXNzdWVzOg0KPnwgDQo+fCAgIDEuIFRo ZSBkcmFmdCBzaG91bGQgaW5kaWNhdGUgdGhlIG92ZXJhbGwgZ29hbCBvZiB0cmFuc2xhdGluZyB0 aGUgSUdQDQo+bGluayBzdGF0ZSBkYXRhYmFzZSBhbmQgVEUgRGF0YWJhc2UgaW50byBhIGdlbmVy aWMgcmVwcmVzZW50YXRpb24uIEl0DQo+c2hvdWxkIGFsc28gYmV0dGVyIGVudW1lcmF0ZSB0aGUg cmVxdWlyZW1lbnRzIGZvciB0aGlzIHRyYW5zbGF0aW9uLg0KPg0KPm1haW4gcmVhc29uIGlzIHRv IHNwYXJlIHRoZSBjb250cm9sbGVycyB0aGUgbmVlZCBvZiBhbHd5cyByZXF1aXJpbmcgdG8NCj51 bmRlcnN0YW5kIHR3byBwcm90b2NvbHMuDQo+QUk6IGknbGwgYWRkIGEgbm90ZS4NCg0KQWxzbywg YSBzaW5nbGUgcmVwcmVzZW50YXRpb24gd2lsbCBlbmFibGUgcG9saWN5IG9uIHRoZSByZWNlaXZl ci4NCg0KDQoNCj4NCj58ICAgMi4gVGhlIGRyYWZ0IGluY2x1ZGVzIG9wYXF1ZSBhdHRyaWJ1dGUg VExWcyBmb3IgYWR2ZXJ0aXNpbmcNCj5wcm90b2NvbC1zcGVjaWZpYyBpbmZvcm1hdGlvbiAobm9k ZSwgbGluaywgYW5kIHByZWZpeCkuIEhvd2V2ZXIsIHRoZXJlIGlzDQo+bm8gaW5kaWNhdGlvbiBv biBob3cgdGhpcyBpbmZvcm1hdGlvbiBpcyBlbmNvZGVkIG9yIGlkZW50aWZpZWQuIEhlbmNlLA0K PnRoZXJlIGNhbiBiZSBubyBpbnRlcm9wZXJhYmlsaXR5IGJldHdlZW4gaW1wbGVtZW50YXRpb25z Lg0KPg0KPndlIGhhdmUgZGVmaW5lZCBvcGFxdWUgY29udGFpbmVycyBmb3IgdGhlIGRvY3VtZW50 IGxhZyBiZXR3ZWVuIGRlZmluaW5nDQo+DQo+MSkgYSBuZXcgSUdQIGV4dGVuc2lvbg0KPjIpIHRo ZSBCR1AgZXh0ZW5zaW9uIGJlaW5nIHB1Ymxpc2hlZA0KPg0KPml0IGlzIGV4cGVjdGVkIHRoYXQg dGhvc2Ugb3BhcXVlIGNhcnJpZXJzIGFyZSBvbmx5IHVzZWQNCj5pbiB2ZW5kb3IgcHJpdmF0ZSBl eHRlbnNpb25zLg0KPkFJOiBpJ2xsIGFkZCBhIG5vdGUNCg0KR3JlYXQuIA0KDQoNCg0KPg0KPnwg ICAzLiBUaGUgZHJhZnQgaXMgYmFzZWQgbWFpbmx5IG9uIElTSVMgZW5jb2RpbmcgYW5kIGRvZXMg YSBwb29yIGpvYiBvZg0KPnJlcHJlc2VudGluZyB0aGUgT1NQRi4gRXhhbXBsZXMgaW5jbHVkZToN Cj4NCj50aGUgZHJhZnQgaXMgYSAicHJvdG9jb2wgbmV1dHJhbCIgcmVwcmVzZW50YXRpb24gb2Yg bm9kZS9saW5rcyBhbmQNCj5wcmVmaXhlcy4NCj53aGVyZXZlciBwb3NzaWJsZSB3ZSBoYXZlIHB1 dCBpbiByZWZlcmVuY2UgdG8gdGhlIG1lc3NhZ2UgZm9ybWF0DQo+b2YgdGhlIG9yaWdpbmFsIElT LUlTIHNwZWMgYXMgd2UgZm91bmQgaXQgZ2VuZXJhbGx5IGVhc2llciB0byByZWFkIChzb3JyeQ0K PmFjZWUpLg0KPnRoZXJlIGlzIG5vIHBvaW50IG9mIGFkZGluZyBhIHNlY29uZCBwb2ludGVyIHRv IHRoZSByZWx2YW50IE9TUEYgc3BlYy4NCj5hcyBzb21ldGltZXMgdGhlIGZvcm1hdCBvZiB0aG9z ZSBPU1BGLVRMVnMgZGlmZmVycyBmcm9tIElTLUlTDQo+DQo+fCAgICAgQS4gUGFnZSAxMCAtIFRo ZXJlIGlzIG5vIHByb3RvY29sLWlkIGZvciBPU1BGdjMuDQo+DQo+QUk6IGknbGwgYWRkIGEgcHJv dG9jb2wgY29kZSBmb3IgaXQuDQo+DQo+fCAgICAgQi4gUGFnZSAxMSAtIFdoeSBpcyBSRkMgNjgy MiBub3JtYXRpdmUgYW5kIFJGQyA2NTQ5IGluZm9ybWF0aW9uYWw/DQo+DQo+QUk6IGknbGwgbW92 ZSBpdCBpbnRvIG5vcm1hdGl2ZS4NCj4NCj58ICAgICBDLiBQc3VlZG9ub2RlIFJlcHJlc2VudGF0 aW9uIC0gVGhlIGFic2VuY2Ugb2YgYSBjb25kZW5zZWQgZm9ybWF0DQo+Zm9yIHRoZSBwc2V1ZG9u b2RlIGZvbGxvd2luZyB0aGUgT1NQRiBtb2RlbC4NCj4NCj5BSTogaSdsbCBhZGQgYW4gT1NQRiBl eGFtcGxlIGFmdGVyIHNlY3Rpb24gMy42Lg0KDQpUaGUgZXhhbXBsZSB3b3VsZCByZXN1bHQgaW4g dGhlIHNhbWUgQkdQIExTLiBNeSBwb2ludCB3YXMgdGhhdCBPU1BGqfZzDQpOZXR3b3JrLUxTQSBy ZXByZXNlbnRhdGlvbiBpcyBzaWduaWZpY2FudGx5IG1vcmUgY29tcGFjdCBhbmQgc2F0aXNmaWVz IHRoZQ0KcHNldWRvbm9kZSByZXF1aXJlbWVudC4NCg0KDQoNCj4NCj58ICAgICBELiBQYWdlIDE1 IC0gUmVsZXZhbnQgT1NQRiBSRkNzIHNob3VsZCBiZSByZWZlcmVuY2VkIGZvciBUTFYgY29kZQ0K PnBvaW50cy4NCj4NCj50aGVyZSBpcyBubyBzaW5nbGUgT1NQRiBSRkMgcmVwcmVzZW50aW5nIHRo ZSBpbmZvcm1hdGlvbiB3aGljaCBpcyBlbmNvZGVkDQo+aGVyZS4NCj5hZ2FpbiAtIHRoaXMgaXMg bm90IGEgbGV0cyB3cmFwIE9TUEYgYW5kIElTLUlTIHNwZWMgLSBpdCBpcyBhIHByb3RvY29sDQo+ bmV1dHJhbCByZXByZXNlbnRhdGlvbiBvZiBub2RlcywgbGlua3MgYW5kIHByZWZpeGVzIC0gaWYg dGhlIEJHUC1MUw0KPm1lc3NhZ2UgZm9ybWF0IGlzIGlkZW50aWNhbCB0byBJUy1JUyB3ZSBoYXZl IHBpY2tlZCBJU19JUyBhcyBhIHJlZmVyZW5jZS4NCj4NCj58ICAgICBFLiBQYWdlIDE4IC0gV2h5 IGFuIElTSVMgQXJlYSBpZGVudGlmaWVyIGFuZCBub3QgYW4gT1NQRiBBcmVhDQo+aWRlbnRpZmll cj8NCj4NCj50aGVyZSBpcyAtIHNlZSBUTFYgNTE0DQo+QUk6IGknbGwgcmVuYW1lIDUxNCBhcyAn T1NQRiBBcmVhLUlEJw0KPg0KPnwgICAgIEYuIFBhZ2UgMTggLSAnRScgaXMgZm9yIGFuIEFTQlIg YW5kICdCJyBpcyBmb3IgQUJSLg0KPg0KPkFJOiBjaGFuZ2UgdGhlIG5hbWUgYnV0IGtlZXAgdGhl IGJpdCB2YWx1ZS4NCg0KU3VyZSAtIHRoZXNlIHNob3VsZCBtYXRjaCBSRkMgMjMyOC4NCg0KPg0K PnwgICAgIEcuIFBhZ2UgMTkgLSBSRkMgNTY0MiBpcyB0aGUgT1NQRiBOb2RlIE5hbWUgUkZDLg0K Pg0KPnNlZSBhbnN3ZXIgdG8gY29tbWVudCAzKS4NCj4NCj58ICAgICBILiBQYWdlIDIxIC0gU2hv dWxkIGJlIHJlZmVyZW5jZXMgdG8gT1NQRiBSRkMsIFJGQyAzNjMwLCBSRkMgNDIwMywNCj5hbmQg UkZDIDUzMjkuIA0KPg0KPnNlZSBhbnN3ZXIgdG8gY29tbWVudCAzKS4NCj4NCj58ICAgICBJLiBQ YWdlIDIyIC0gT1NQRiBMaW5rIG1ldHJpY3MgYXJlIDIgYnl0ZXMgYnV0IE9TUEYgcHJlZml4IG1l dHJpY3MNCj5hcmUgMyBieXRlcy4NCj4NCj50aGF0cyB3aHkgdGhlICdJR1AgbWV0cmljJyBpcyB2 YXJpYWJsZSBsZW5ndGguDQoNClRoYXQgZG9lc26p9nQgbWVhbiB0aGUgZHJhZnQgc2hvdWxkIGhh dmUgaW5jb3JyZWN0IGluZm9ybWF0aW9uLg0KDQoNCg0KPg0KPnwgICAgIEouIFBhZ2UgMjUgLSBP U1BGIFByZWZpeCBPcHRpb25zIGFyZSBkZWZpbmVkIGluIFJGQyA1MzQwLCBBLjQuMS4xLg0KPkl0 IG5vdCBjbGVhciB3aGljaCBuZWVkIHRvIGJlIGFkdmVydGlzZWQuDQo+DQo+Z29vZCBwb2ludCAt IA0KPkFJOiBhZGQgYSByZWZlcmVuY2UgdG8gcmZjNTM0MCBhbmQgY29weSB0ZWggZmxhZ3MgZGVz Y3JpcHRpb25zDQo+DQo+fCAgICAgSy4gUGFnZSAyNiAtIEZvcndhcmRpbmcgQWRkcmVzcyBmb3Ig T1NQRnYzIHNob3VsZCByZWZlcmVuY2UgUkZDDQo+NTM0MCBhcyB3ZWxsLg0KPg0KPkFJOiBhZGQg cmVmZXJlbmNlDQo+DQo+fCAgIDQuIFNlY3Rpb24gMy4yLjE1IC0gV2h5IGRvIHlvdSBsaW1pdCBh IGxpbmsgb3IgcHJlZml4IHRvIGEgc2luZ2xlDQo+TVQtSUQ/IExpbmtzIGFuZCBwcmVmaXhlcyBj YW4gYmUgcmVhY2hhYmxlIGluIG11bHRpcGxlIHRvcG9sb2dpZXMgd2l0aA0KPmRpZmZlcmVudCBt ZXRyaWNzLiBJcyB0aGlzIHNpbXBseSBhIHR5cG8/DQo+DQo+dGhlcmUgaXMgbm8gbGltaXQgdG8g YSBzaW5nbGUgTVQtSUQsIHRoZSBwcm92aWRlZCByZWZlcmVuY2VzIGFzIHdlbGwNCj5hcyB0aGUg VExWIHNpemlpbmcgKE4qIC4uLikgaW5kaWNhdGUgdGhhdCB0aGlzIGlzIGEgdmFyaWFibGUNCj5s ZW5ndGggVExWLg0KPg0KPkFJOiBhZGQgdGV4dCB0byBzYXkgdGhhdCB0aGlzIFRMViBpcyB1c2Vk IHRvIGFkdmVydGlzZSBtZW1lYmVyc2hpcCBpbg0KPidvbmUgb3IgbW9yZScgDQo+ICAgIHRvcG9s b2dpZXMuDQoNClRoaXMgd2FzIGluIHJlc3BvbnNlIHRvIHRoaXMgdGV4dDoNCg0KICAgVGhlIE1U LUlEIFRMViBNQVkgYmUgcHJlc2VudCBpbiBhIExpbmsgRGVzY3JpcHRvciwgYSBQcmVmaXgNCiAg IERlc2NyaXB0b3IsIG9yIGluIHRoZSBCR1AtTFMgYXR0cmlidXRlIG9mIGEgbm9kZSBOTFJJLiBJ biBMaW5rIG9yDQogICBQcmVmaXggRGVzY3JpcHRvciwgb25seSBvbmUgTVQtSUQgVExWIGNvbnRh aW5pbmcgb25seSB0aGUgTVQtSUQgb2YNCiAgIHRoZSB0b3BvbG9neSB3aGVyZSB0aGUgbGluayBv ciB0aGUgcHJlZml4IGJlbG9uZ3MgaXMgYWxsb3dlZC4NCg0KDQpIb3dldmVyLCBpZiB5b3UgY2hh bmdlIHRoaXMsIGl0IHN0aWxsIGRvZXNuqfZ0IHNvbHZlIHRoZSBzYXRpc2Z5IHRoZQ0KcmVxdWly ZW1lbnQgb2YgYSBzZXBhcmF0ZSBtZXRyaWMgcGVyIHRvcG9sb2d5IGZvciBsaW5rcyBhbmQgcHJl Zml4ZXMuDQoNCj4NCj58IE1pbm9yIElzc3VlczoNCj58ICAgMS4gRmlndXJlcyBhbmQgdGFibGVz IGFyZSByZWZlcmVuY2VkIGJ5IG51bWJlciwgeWV0IHRob3NlIGZpZ3VyZXMgYW5kDQo+dGFibGVz IGFyZSBub3QgbnVtYmVyZWQuDQo+DQo+dGhhdHMgYW4gYXJ0aWZhY3Qgb2YgeG1sMnJmYyBvbiBt YWMgLSBpJ2xsIHJlbmRlciB0aGUgbmV4dCB2ZXJzaW9uIHVuZGVyDQo+dW5peCB3aGljaCBoYXMg Z290dGVuIGl0IHJpZ2h0Lg0KDQpJIGRvbqn2dCB0aGluayB0aGlzIGlzIGEgcHJvYmxlbSB3aXRo IG1hYyAtIGl0IGlzIGp1c3QgYSB0Y2wgc2NyaXB0LiBTbywNCnVubGVzcyB5b3UgaGF2ZSBhIHZl cnkgb2xkIFhjb2RlIHBhY2thZ2UgaW5zdGFsbGVkIGFuZCB0aGVyZSBpcyBhIHRjbCBidWcsDQpp dCBpcyBzaG91bGQgbm90IGJlIGEgcHJvYmxlbS4gWW91IGNhbiBkb3dubG9hZCB0aGUgbGF0ZXN0 IHZlcnNpb24gb2YNCnhtbDJyZmMgdGhvdWdoLiANCg0KDQo+DQo+fCAgIDIuIFNldmVyYWwgYWNy b255bW5zIHRoYXQgYXJlIG5vdCBkZXNpZ25hdGVkIGFzIHdlbGwta25vd24gYXJlIG5vdA0KPmV4 cGFuZGVkIHdpdGggdGhlIGZpcnN0IHVzYWdlLiBFeGFtcGxlcyBpbmNsdWRlIExTREIgYW5kIFRF RC4gUmVmZXIgdG8NCj5odHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3JmYy1zdHlsZS1ndWlkZS9h YmJyZXYuZXhwYW5zaW9uLnR4dC4NCj4NCj5BSTogbGV0IG1lIGZpeCB0aGF0DQo+DQo+fCAgIDMu IFBhZ2UgMTEgLSBUaGUgdGFibGUgbWVudGlvbnMgTDEgb3B0aWNhbCB0b3BvbG9neSBidXQgdGhl cmUgYXJlIGFyZQ0KPm5vIG9wdGljYWwgYXR0cmlidXRlcy4gVGhpcyBzZWVtcyBsaWtlIGl0IHNo b3VsZCBiZSByZW1vdmVkIGFuZCBhZGRlZA0KPndoZW4gR01QTFMgaW5mb3JtYXRpb24gaXMgZGVm aW5lZCBmb3IgQkdQIExTLg0KPg0KPndlIGRpZCB3YW50IHRvIGxvY2sgdGhlIGNvZGVwb2ludCBh cyBzb21lIGFyZSBtb2NraW5nIHdpdGggQkdQLUxTIGFzIGFuDQo+Tk5JIHByb3RvY29sIA0KPmZv ciBvcHRpY2FsLiAtDQoNClRoZW4geW91IHNob3VsZCBhZGQgYSByZWdpc3RyeSBmb3IgdGhlIHBy b3RvY29sIElEcy4gU2luY2UgdGhpcyBpcyBhIG5ldw0KZmllbGQsIHlvdSBkb26p9nQgaGF2ZSB0 byB3b3JyeSBhYm91dCBvdGhlcnMgYXNzaWduaW5nIHZhbHVlcy4NCg0KDQoNCj4gDQo+DQo+fCAg IDQuIFBhZ2UgMTEgLSBUaGUgQkdQLUxTIElkZW50aWZpZXIgaXMgcmVmZXJlbmNlZCBiZWZvcmUg aXQgaXMNCj5kZWZpbmVkLiANCj4NCj5BSTogYWRkIGEgZm9yd2FyZCByZWZlcmVuY2UgaW4gc2Vj dGlvbiAzLjIuMS40DQo+DQo+fCAgIDUuIFBhZ2UgMTcgLSBJbiB0aGUgY29udGV4dCBvZiB0aGlz IE5STEksIHdoYXQgcHVycG9zZSBkb2VzIHRoZSBuZXh0DQo+aG9wIGFkZHJlc3Mgc2VydmU/IElm IG5vbmUsIGNvdWxkbid0IHdlIGp1c3QgYWR2ZXJ0aXNlIGEgMCBsZW5ndGggbmV0d29yaw0KPmFk ZHJlc3M/IA0KPg0KPkFJOiBhZGQgY2xhcmlmaWNhdGlvbiB0ZXh0IHRoYXQgdGhlIEJHUC1OSCBz ZXJ2ZXMgc29sZWx5IHRoZSBwdXJwb3NlIG9mDQo+QkdQIHBhdGggdGllLWJyZWFraW5nDQo+ICAg IGJhc2VkIG9uIElHUCBkaXN0YW5jZS4NCj4NCj58ICAgNi4gUGFnZSAxOCAtIFdoeSBpc24ndCB0 aGUgSVMtSVMgQXJlYSBJZGVudGlmaWVyIGFwcGxpY2FibGUgdG8NCj5wcmVmaXhlcz8gT1NQRiBj YW4gc2NvcGUgcHJlZml4ZXMgdG8gYXJlYXMgKHVubGVzcyB0aGV5IEFTLUV4dGVybmFsKS4NCj4N Cj5kaWZmZXJlbnQgc2NoZW1hcyAtIGluIElTLUlTIGFuIEFyZWEgaXMgYW4gYXR0cmlidXRlIG9m IGEgbm9kZSwgdnMuIGluDQo+T1NQRiBpdHMgYW4gYXR0cmlidXRlIG9mIGFuIGludGVyZmFjZS4N Cg0KQnV0IGFib3ZlIHlvdSBzYWlkIHlvdSB3ZXJlIGdvaW5nIHRvIG1ha2UgdGhpcyBhbiBPU1BG IEFyZWEgSUQgVExWPw0KDQoNCj4NCj58ICAgNy4gRm9yIEZRRE4gbm9kZS9saW5rIG5hbWUgcmVj b21tZW5kYXRpb24gLSBzaG91bGQgdXNhZ2UgZGljdGF0ZQ0KPiJSRUNPTU1FTkRFRCIgcmF0aGVy IHRoYW4gInJlY29tbWVuZGVkqfc/DQo+DQo+QUk6IFJFQ09NTUVOREUNCj4NCj58ICAgOC4gUGFn ZSAyMSAtIElzIGtub3dpbmcgd2hldGhlciBNUExTIHNpZ25hbGluZyBpcyBlbmFibGVkIG9uIGEg bGluaw0KPmFsbCB0aGF0IGlzIG5lZWRlZCBieSB0aGUgYXBwbGljYXRpb25zPyBUaGlzIHNlZW1z IHNvbWV3aGF0IG91dCBvZiBwbGFjZQ0KPndpdGggdGhlIExTREIgYW5kIFRFIGRhdGEuDQo+DQo+ dGhhdHMgdXNlIHdoZW4gdGhlIEJHUC1MUyBkYXRhIGFyZSBub3QgZ2VuZXJhdGVkIGJ5IHJlZGlz dGlidXRpb24gb2YgYW4NCj5MU0RCIG9yIFRFRCBidXQNCj5yYXRoZXIgaXMgZ2VuZXJhdGVkICdk aXJlY3QnICh1c2luZyBwcm90b2NvbCBjb2RlICdkaXJlY3QnKSAtIGkuZS4gZXZlcnkNCj5ub2Rl DQo+aW5hIGFuIElHUCBkb21haW4gYmVjb21lcyBhIHB1Ymxpc2hlciBvZiBpdHMgbG9jYWwgbGlu ay1zdGF0ZSBkYXRhLg0KPg0KPkFJOiBhZGQgYSBub3RlIHRoYXQgdGhpcyBvbmx5IGFwcGxpZXMg Zm9yIGdlbmVyYXRpb24gb2YgdXNpbmcgcHJvdG9jb2wNCj4nZGlyZWN0Jw0KDQpPaw0KDQpUaGFu a3MsDQpBY2VlIA0KDQoNCg0KPg0KPnwgTml0czogDQo+fCANCj58ICoqKioqKioqKioqKioqKg0K PnwgKioqIDIxLDI3ICoqKioNCj58ICAgICAgY2FsbGVkIHVwb24gdG8gcGVyZm9ybSBjb21wdXRh dGlvbnMgYmFzZWQgb24gdGhlIG5ldHdvcmsgdG9wb2xvZ3kNCj5hbmQNCj58ICAgICAgY3VycmVu dCBzdGF0ZSBvZiB0aGUgY29ubmVjdGlvbnMgd2l0aGluIHRoZSBuZXR3b3JrLCBpbmNsdWRpbmcN Cj58ICAgICAgdHJhZmZpYyBlbmdpbmVlcmluZyBpbmZvcm1hdGlvbi4gIFRoaXMgaXMgaW5mb3Jt YXRpb24gdHlwaWNhbGx5DQo+fCAhICAgIGRpc3RyaWJ1dGVkIGJ5IElHUCByb3V0aW5nIHByb3Rv Y29scyB3aXRoaW4gdGhlIG5ldHdvcmsNCj58ICAgDQo+fCAgICAgIFRoaXMgZG9jdW1lbnQgZGVz Y3JpYmVzIGEgbWVjaGFuaXNtIGJ5IHdoaWNoIGxpbmtzIHN0YXRlIGFuZA0KPnRyYWZmaWMNCj58 ICAgICAgZW5naW5lZXJpbmcgaW5mb3JtYXRpb24gY2FuIGJlIGNvbGxlY3RlZCBmcm9tIG5ldHdv cmtzIGFuZCBzaGFyZWQNCj58IC0tLSAyMSwyNyAtLS0tDQo+fCAgICAgIGNhbGxlZCB1cG9uIHRv IHBlcmZvcm0gY29tcHV0YXRpb25zIGJhc2VkIG9uIHRoZSBuZXR3b3JrIHRvcG9sb2d5DQo+YW5k DQo+fCAgICAgIGN1cnJlbnQgc3RhdGUgb2YgdGhlIGNvbm5lY3Rpb25zIHdpdGhpbiB0aGUgbmV0 d29yaywgaW5jbHVkaW5nDQo+fCAgICAgIHRyYWZmaWMgZW5naW5lZXJpbmcgaW5mb3JtYXRpb24u ICBUaGlzIGlzIGluZm9ybWF0aW9uIHR5cGljYWxseQ0KPnwgISAgICBkaXN0cmlidXRlZCBieSBJ R1Agcm91dGluZyBwcm90b2NvbHMgd2l0aGluIHRoZSBuZXR3b3JrLg0KPnwgICANCj58ICAgICAg VGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBtZWNoYW5pc20gYnkgd2hpY2ggbGlua3Mgc3RhdGUg YW5kDQo+dHJhZmZpYw0KPnwgICAgICBlbmdpbmVlcmluZyBpbmZvcm1hdGlvbiBjYW4gYmUgY29s bGVjdGVkIGZyb20gbmV0d29ya3MgYW5kIHNoYXJlZA0KPnwgKioqKioqKioqKioqKioqDQo+fCAq KiogMjQ2LDI1MiAqKioqDQo+fCAgICAgIHJvdXRlcnMgaW4gYSBQT1AuIEFic3RyYWN0ZWQgdG9w b2xvZ3kgY2FuIGFsc28gYmUgYSBtaXggb2YgcGh5c2ljYWwNCj58ICAgICAgYW5kIHZpcnR1YWwg bm9kZXMgYW5kIHBoeXNpY2FsIGFuZCB2aXJ0dWFsIGxpbmtzLiAgRnVydGhlcm1vcmUsIHRoZQ0K PnwgICAgICBCR1AgU3BlYWtlciBjYW4gYXBwbHkgcG9saWN5IHRvIGRldGVybWluZSB3aGVuIGlu Zm9ybWF0aW9uIGlzDQo+dXBkYXRlZA0KPnwgISAgICB0byB0aGUgY29uc3VtZXIgc28gdGhhdCB0 aGVyZSBpcyByZWR1Y3Rpb24gb2YgaW5mb3JtYXRpb24gZmxvdyBmb3JtDQo+fCAgICAgIHRoZSBu ZXR3b3JrIHRvIHRoZSBjb25zdW1lcnMuICBNZWNoYW5pc21zIHRocm91Z2ggd2hpY2ggdG9wb2xv Z2llcw0KPnwgICAgICBjYW4gYmUgYWdncmVnYXRlZCBvciB2aXJ0dWFsaXplZCBhcmUgb3V0c2lk ZSB0aGUgc2NvcGUgb2YgdGhpcw0KPnwgICAgICBkb2N1bWVudA0KPnwgLS0tIDI0NiwyNTIgLS0t LQ0KPnwgICAgICByb3V0ZXJzIGluIGEgUE9QLiBBYnN0cmFjdGVkIHRvcG9sb2d5IGNhbiBhbHNv IGJlIGEgbWl4IG9mIHBoeXNpY2FsDQo+fCAgICAgIGFuZCB2aXJ0dWFsIG5vZGVzIGFuZCBwaHlz aWNhbCBhbmQgdmlydHVhbCBsaW5rcy4gIEZ1cnRoZXJtb3JlLCB0aGUNCj58ICAgICAgQkdQIFNw ZWFrZXIgY2FuIGFwcGx5IHBvbGljeSB0byBkZXRlcm1pbmUgd2hlbiBpbmZvcm1hdGlvbiBpcw0K PnVwZGF0ZWQNCj58ICEgICAgdG8gdGhlIGNvbnN1bWVyIHNvIHRoYXQgdGhlcmUgaXMgcmVkdWN0 aW9uIG9mIGluZm9ybWF0aW9uIGZsb3cgZnJvbQ0KPnwgICAgICB0aGUgbmV0d29yayB0byB0aGUg Y29uc3VtZXJzLiAgTWVjaGFuaXNtcyB0aHJvdWdoIHdoaWNoIHRvcG9sb2dpZXMNCj58ICAgICAg Y2FuIGJlIGFnZ3JlZ2F0ZWQgb3IgdmlydHVhbGl6ZWQgYXJlIG91dHNpZGUgdGhlIHNjb3BlIG9m IHRoaXMNCj58ICAgICAgZG9jdW1lbnQNCj58ICoqKioqKioqKioqKioqKg0KPnwgKioqIDI2Nywy NzggKioqKg0KPnwgICAgICAgICBwb2xpY3kgY29udHJvbCBhbmQgYWxnb3JpdGhtcywgYW5kIGNv b3JkaW5hdGlvbiBvZiBjb21wdXRhdGlvbg0KPnwgICAgICAgICBhY3Jvc3MgdGhlIHdob2xlIGFy ZWEuDQo+fCAgIA0KPnwgISAgICBvICBJZiBhIHJvdXRlciB3YW50cyB0byBjb21wdXRlIGEgTVBM Uy1URSBwYXRoIGFjcm9zcyBJR1AgYXJlYXMgaXRzDQo+fCAgICAgICAgIG93biBURUQgbGFja3Mg dmlzaWJpbGl0eSBvZiB0aGUgY29tcGxldGUgdG9wb2xvZ3kuICBUaGF0IG1lYW5zDQo+fCAgICAg ICAgIHRoYXQgdGhlIHJvdXRlciBjYW5ub3QgZGV0ZXJtaW5lIHRoZSBlbmQtdG8tZW5kIHBhdGgs IGFuZCBjYW5ub3QNCj58ICAgICAgICAgZXZlbiBzZWxlY3QgdGhlIHJpZ2h0IGV4aXQgcm91dGVy IChBcmVhIEJvcmRlciBSb3V0ZXIgLSBBQlIpIGZvcg0KPnwgICAgICAgICBhbiBvcHRpbWFsIHBh dGguICBUaGlzIGlzIGFuIGlzc3VlIGZvciBsYXJnZS1zY2FsZSBuZXR3b3JrcyB0aGF0DQo+fCAh ICAgICAgIG5lZWQgdG8gc2VnbWVudCB0aGVpciBjb3JlIG5ldHdvcmtzIGludG8gZGlzdGluY3Qg YXJlYXMsIGJ1dA0KPndoaWNoDQo+fCAgICAgICAgIHN0aWxsIHdhbnQgdG8gdGFrZSBhZHZhbnRh Z2Ugb2YgTVBMUy1URS4NCj58ICAgDQo+fCAgICAgIFByZXZpb3VzIHNvbHV0aW9ucyB1c2VkIHBl ci1kb21haW4gcGF0aCBjb21wdXRhdGlvbiBbUkZDNTE1Ml0uICBUaGUNCj58IC0tLSAyNjcsMjc5 IC0tLS0NCj58ICAgICAgICAgcG9saWN5IGNvbnRyb2wgYW5kIGFsZ29yaXRobXMsIGFuZCBjb29y ZGluYXRpb24gb2YgY29tcHV0YXRpb24NCj58ICAgICAgICAgYWNyb3NzIHRoZSB3aG9sZSBhcmVh Lg0KPnwgICANCj58ICEgICAgbyAgSWYgYSByb3V0ZXIgd2FudHMgdG8gY29tcHV0ZSBhbiBNUExT LVRFIHBhdGggYWNyb3NzIG11bHRpcGxlDQo+SUdQIA0KPnwgISAgICAgICBhcmVhcywgdGhlbiBp dHMNCj58ICAgICAgICAgb3duIFRFRCBsYWNrcyB2aXNpYmlsaXR5IG9mIHRoZSBjb21wbGV0ZSB0 b3BvbG9neS4gIFRoYXQgbWVhbnMNCj58ICAgICAgICAgdGhhdCB0aGUgcm91dGVyIGNhbm5vdCBk ZXRlcm1pbmUgdGhlIGVuZC10by1lbmQgcGF0aCwgYW5kIGNhbm5vdA0KPnwgICAgICAgICBldmVu IHNlbGVjdCB0aGUgcmlnaHQgZXhpdCByb3V0ZXIgKEFyZWEgQm9yZGVyIFJvdXRlciAtIEFCUikg Zm9yDQo+fCAgICAgICAgIGFuIG9wdGltYWwgcGF0aC4gIFRoaXMgaXMgYW4gaXNzdWUgZm9yIGxh cmdlLXNjYWxlIG5ldHdvcmtzIHRoYXQNCj58ICEgICAgICAgbmVlZCB0byBzZWdtZW50IHRoZWly IGNvcmUgbmV0d29ya3MgaW50byBkaXN0aW5jdCBhcmVhcywgYnV0DQo+fCAgICAgICAgIHN0aWxs IHdhbnQgdG8gdGFrZSBhZHZhbnRhZ2Ugb2YgTVBMUy1URS4NCj58ICAgDQo+fCAgICAgIFByZXZp b3VzIHNvbHV0aW9ucyB1c2VkIHBlci1kb21haW4gcGF0aCBjb21wdXRhdGlvbiBbUkZDNTE1Ml0u ICBUaGUNCj58ICoqKioqKioqKioqKioqKg0KPnwgKioqIDQyNiw0MzQgKioqKg0KPnwgICAgICAo dGh1cyBhIFRMViB3aXRoIG5vIHZhbHVlIHBvcnRpb24gd291bGQgaGF2ZSBhIGxlbmd0aCBvZiB6 ZXJvKS4gVGhlDQo+fCAgICAgIFRMViBpcyBub3QgcGFkZGVkIHRvIGZvdXItb2N0ZXQgYWxpZ25t ZW50LiAgVW5yZWNvZ25pemVkIHR5cGVzIGFyZQ0KPnwgICAgICBwcmVzZXJ2ZWQgYW5kIHByb3Bh Z2F0ZWQuICBJbiBvcmRlciB0byBjb21wYXJlIE5MUklzIHdpdGggdW5rbm93bg0KPnwgISAgICBU TFZzIGFsbCBUTFZzIE1VU1QgYmUgb3JkZXJlZCBpbiBhc2NlbmRpbmcgb3JkZXIuICBJZiB0aGVy ZSBhcmUNCj5tb3JlDQo+fCAgICAgIFRMVnMgb2YgdGhlIHNhbWUgdHlwZSwgdGhlbiB0aGUgVExW cyBNVVNUIGJlIG9yZGVyZWQgaW4gYXNjZW5kaW5nDQo+fCAhICAgIG9yZGVyIG9mIHRoZSBUTFYg dmFsdWUgd2l0aGluIHRoZSBzZXQgb2YgVExWcyB3aXRoIHRoZSBzYW1lIHR5cGUuDQo+fCAgICAg IEFsbCBUTFZzIHRoYXQgYXJlIG5vdCBzcGVjaWZpZWQgYXMgbWFuZGF0b3J5IGFyZSBjb25zaWRl cmVkDQo+b3B0aW9uYWwuDQo+fCAgIA0KPnwgICAzLjIuICBUaGUgTGluay1TdGF0ZSBOTFJJDQo+ fCAtLS0gNDI3LDQzNSAtLS0tDQo+fCAgICAgICh0aHVzIGEgVExWIHdpdGggbm8gdmFsdWUgcG9y dGlvbiB3b3VsZCBoYXZlIGEgbGVuZ3RoIG9mIHplcm8pLiBUaGUNCj58ICAgICAgVExWIGlzIG5v dCBwYWRkZWQgdG8gZm91ci1vY3RldCBhbGlnbm1lbnQuICBVbnJlY29nbml6ZWQgdHlwZXMgYXJl DQo+fCAgICAgIHByZXNlcnZlZCBhbmQgcHJvcGFnYXRlZC4gIEluIG9yZGVyIHRvIGNvbXBhcmUg TkxSSXMgd2l0aCB1bmtub3duDQo+fCAhICAgIFRMVnMsIGFsbCBUTFZzIE1VU1QgYmUgaW4gYXNj ZW5kaW5nIG9yZGVyIGJ5IFRMViB0eXBlLiAgSWYgdGhlcmUNCj5hcmUgbXVsdGlwbGUNCj58ICAg ICAgVExWcyBvZiB0aGUgc2FtZSB0eXBlLCB0aGVuIHRoZSBUTFZzIE1VU1QgYmUgb3JkZXJlZCBp biBhc2NlbmRpbmcNCj58ICEgICAgb3JkZXIgb2YgdGhlIFRMViB2YWx1ZSB3aXRoaW4gdGhlIFRM VnMgd2l0aCB0aGUgc2FtZSB0eXBlLg0KPnwgICAgICBBbGwgVExWcyB0aGF0IGFyZSBub3Qgc3Bl Y2lmaWVkIGFzIG1hbmRhdG9yeSBhcmUgY29uc2lkZXJlZA0KPm9wdGlvbmFsLg0KPnwgICANCj58 ICAgMy4yLiAgVGhlIExpbmstU3RhdGUgTkxSSQ0KPnwgKioqKioqKioqKioqKioqDQo+fCAqKiog NDkwLDQ5NiAqKioqDQo+fCAgIA0KPnwgICAgICBUaGUgJ1RvdGFsIE5MUkkgTGVuZ3RoJyBmaWVs ZCBjb250YWlucyB0aGUgY3VtdWxhdGl2ZSBsZW5ndGgsIGluDQo+fCAgICAgIG9jdGV0cywgb2Yg cmVzdCBvZiB0aGUgTkxSSSBub3QgaW5jbHVkaW5nIHRoZSBOTFJJIFR5cGUgZmllbGQgb3INCj58 ICEgICAgaXRzZWxmLiAgRm9yIFZQTiBhcHBsaWNhdGlvbnMgaXQgYWxzbyBpbmNsdWRlcyB0aGUg bGVuZ3RoIG9mIHRoZQ0KPnwgICAgICBSb3V0ZSBEaXN0aW5ndWlzaGVyLg0KPnwgICANCj58ICAg ICAgVGhlICdOTFJJIFR5cGUnIGZpZWxkIGNhbiBjb250YWluIG9uZSBvZiB0aGUgZm9sbG93aW5n IHZhbHVlczoNCj58IC0tLSA0OTEsNDk3IC0tLS0NCj58ICAgDQo+fCAgICAgIFRoZSAnVG90YWwg TkxSSSBMZW5ndGgnIGZpZWxkIGNvbnRhaW5zIHRoZSBjdW11bGF0aXZlIGxlbmd0aCwgaW4NCj58 ICAgICAgb2N0ZXRzLCBvZiByZXN0IG9mIHRoZSBOTFJJIG5vdCBpbmNsdWRpbmcgdGhlIE5MUkkg VHlwZSBmaWVsZCBvcg0KPnwgISAgICBpdHNlbGYuICBGb3IgVlBOIGFwcGxpY2F0aW9ucywgaXQg YWxzbyBpbmNsdWRlcyB0aGUgbGVuZ3RoIG9mIHRoZQ0KPnwgICAgICBSb3V0ZSBEaXN0aW5ndWlz aGVyLg0KPnwgICANCj58ICAgICAgVGhlICdOTFJJIFR5cGUnIGZpZWxkIGNhbiBjb250YWluIG9u ZSBvZiB0aGUgZm9sbG93aW5nIHZhbHVlczoNCj58ICoqKioqKioqKioqKioqKg0KPnwgKioqIDY2 NSw2NzEgKioqKg0KPnwgICAgICB0cmFuc2l0aW9ucyBpdCBtYXkgaGFwcGVuIHRoYXQgdHdvIHJl ZHVuZGFudCBJR1BzIGFyZSBpbiBwbGFjZS4NCj58ICAgDQo+fCAgICAgIEluIHNlY3Rpb24gU2Vj dGlvbiAzLjIuMS40IGEgc2V0IG9mIHN1Yi1UTFZzIGlzIGRlc2NyaWJlZCwgd2hpY2gNCj58ICEg ICAgYWxsb3dzIHRvIHNwZWNpZnkgYSBmbGV4aWJsZSBrZXkgZm9yIGFueSBnaXZlbiBOb2RlL0xp bmsNCj5pbmZvcm1hdGlvbg0KPnwgICAgICBzdWNoIHRoYXQgZ2xvYmFsIHVuaXF1ZW5lc3Mgb2Yg dGhlIE5MUkkgaXMgZW5zdXJlZC4NCj58ICAgDQo+fCAgIDMuMi4xLjIuICBMb2NhbCBOb2RlIERl c2NyaXB0b3JzDQo+fCAtLS0gNjY2LDY3MiAtLS0tDQo+fCAgICAgIHRyYW5zaXRpb25zIGl0IG1h eSBoYXBwZW4gdGhhdCB0d28gcmVkdW5kYW50IElHUHMgYXJlIGluIHBsYWNlLg0KPnwgICANCj58 ICAgICAgSW4gc2VjdGlvbiBTZWN0aW9uIDMuMi4xLjQgYSBzZXQgb2Ygc3ViLVRMVnMgaXMgZGVz Y3JpYmVkLCB3aGljaA0KPnwgISAgICBhbGxvd3Mgc3BlY2lmaWNhdGlvbiBvZiBhIGZsZXhpYmxl IGtleSBmb3IgYW55IGdpdmVuIE5vZGUvTGluaw0KPmluZm9ybWF0aW9uDQo+fCAgICAgIHN1Y2gg dGhhdCBnbG9iYWwgdW5pcXVlbmVzcyBvZiB0aGUgTkxSSSBpcyBlbnN1cmVkLg0KPnwgICANCj58 ICAgMy4yLjEuMi4gIExvY2FsIE5vZGUgRGVzY3JpcHRvcnMNCj58ICoqKioqKioqKioqKioqKg0K PnwgKioqIDc0OSw3NjIgKioqKg0KPnwgICAgICAgICBub24tUHNldWRvbm9kZSwgdGhpcyBjb250 YWlucyA2IG9jdGV0IElTTyBub2RlLUlEIChJU08NCj5zeXN0ZW0tSUQpLg0KPnwgICAgICAgICBG b3IgYW4gSVMtSVMgUHNldWRvbm9kZSBjb3JyZXNwb25kaW5nIHRvIGEgTEFOLCB0aGlzIGNvbnRh aW5zIDYNCj58ICAgICAgICAgb2N0ZXQgSVNPIG5vZGUtSUQgb2YgdGhlICJEZXNpZ25hdGVkIElu dGVybWVkaWF0ZSBTeXN0ZW0iIChESVMpDQo+fCAhICAgICAgIGZvbGxvd2VkIGJ5IG9uZSBvY3Rl dCBub256ZXJvIFBTTiBpZGVudGlmaWVyICg3IG9jdGV0IGluIHRvdGFsKS4NCj58ICEgICAgICAg Rm9yIGFuIE9TUEZ2MiBvciBPU1BGdjMgbm9uLSJQc2V1ZG9ub2RlIiwgdGhpcyBjb250YWlucyA0 IG9jdGV0DQo+fCAgICAgICAgIFJvdXRlci1JRC4gIEZvciBhbiBPU1BGdjIgIlBzZXVkb25vZGUi IHJlcHJlc2VudGluZyBhIExBTiwgdGhpcw0KPnwgISAgICAgICBjb250YWlucyA0IG9jdGV0IFJv dXRlci1JRCBvZiB0aGUgZGVzaWduYXRlZCByb3V0ZXIgKERSKQ0KPmZvbGxvd2VkDQo+fCAhICAg ICAgIGJ5IDQgb2N0ZXQgSVB2NCBhZGRyZXNzIG9mIHRoZSBEUidzIGludGVyZmFjZSB0byB0aGUg TEFOICg4DQo+b2N0ZXQNCj58ICEgICAgICAgaW4gdG90YWwpLiBTaW1pbGFybHksIGZvciBhbiBP U1BGdjMgIlBzZXVkb25vZGUiLCB0aGlzIGNvbnRhaW5zDQo+NA0KPnwgISAgICAgICBvY3RldCBS b3V0ZXItSUQgb2YgdGhlIERSIGZvbGxvd2VkIGJ5IDQgb2N0ZXQgaW50ZXJmYWNlDQo+aWRlbnRp Zmllcg0KPnwgISAgICAgICBvZiB0aGUgRFIncyBpbnRlcmZhY2UgdG8gdGhlIExBTiAoOCBvY3Rl dCBpbiB0b3RhbCkuIFRoZSBUTFYNCj5zaXplDQo+fCAgICAgICAgIGluIGNvbWJpbmF0aW9uIHdp dGggcHJvdG9jb2wgaWRlbnRpZmllciBlbmFibGVzIHRoZSBkZWNvZGVyIHRvDQo+fCAgICAgICAg IGRldGVybWluZSB0aGUgdHlwZSBvZiB0aGUgbm9kZS4NCj58ICAgDQo+fCAtLS0gNzUwLDc2MyAt LS0tDQo+fCAgICAgICAgIG5vbi1Qc2V1ZG9ub2RlLCB0aGlzIGNvbnRhaW5zIDYgb2N0ZXQgSVNP IG5vZGUtSUQgKElTTw0KPnN5c3RlbS1JRCkuDQo+fCAgICAgICAgIEZvciBhbiBJUy1JUyBQc2V1 ZG9ub2RlIGNvcnJlc3BvbmRpbmcgdG8gYSBMQU4sIHRoaXMgY29udGFpbnMgNg0KPnwgICAgICAg ICBvY3RldCBJU08gbm9kZS1JRCBvZiB0aGUgIkRlc2lnbmF0ZWQgSW50ZXJtZWRpYXRlIFN5c3Rl bSIgKERJUykNCj58ICEgICAgICAgZm9sbG93ZWQgYnkgb25lIG9jdGV0IG5vbnplcm8gUFNOIGlk ZW50aWZpZXIgKDcgb2N0ZXRzIGluDQo+dG90YWwpLg0KPnwgISAgICAgICBGb3IgYW4gT1NQRnYy IG9yIE9TUEZ2MyBub24tIlBzZXVkb25vZGUiLCB0aGlzIGNvbnRhaW5zIHRoZSA0DQo+b2N0ZXQN Cj58ICAgICAgICAgUm91dGVyLUlELiAgRm9yIGFuIE9TUEZ2MiAiUHNldWRvbm9kZSIgcmVwcmVz ZW50aW5nIGEgTEFOLCB0aGlzDQo+fCAhICAgICAgIGNvbnRhaW5zIHRoZSA0IG9jdGV0IFJvdXRl ci1JRCBvZiB0aGUgZGVzaWduYXRlZCByb3V0ZXIgKERSKQ0KPmZvbGxvd2VkDQo+fCAhICAgICAg IGJ5IHRoZSA0IG9jdGV0IElQdjQgYWRkcmVzcyBvZiB0aGUgRFIncyBpbnRlcmZhY2UgdG8gdGhl IExBTiAoOA0KPm9jdGV0cw0KPnwgISAgICAgICBpbiB0b3RhbCkuIFNpbWlsYXJseSwgZm9yIGFu IE9TUEZ2MyAiUHNldWRvbm9kZSIsIHRoaXMgY29udGFpbnMNCj50aGUgNA0KPnwgISAgICAgICBv Y3RldCBSb3V0ZXItSUQgb2YgdGhlIERSIGZvbGxvd2VkIGJ5IHRoZSA0IG9jdGV0IGludGVyZmFj ZQ0KPmlkZW50aWZpZXINCj58ICEgICAgICAgb2YgdGhlIERSJ3MgaW50ZXJmYWNlIHRvIHRoZSBM QU4gKDggb2N0ZXRzIGluIHRvdGFsKS4gVGhlIFRMVg0KPnNpemUNCj58ICAgICAgICAgaW4gY29t YmluYXRpb24gd2l0aCBwcm90b2NvbCBpZGVudGlmaWVyIGVuYWJsZXMgdGhlIGRlY29kZXIgdG8N Cj58ICAgICAgICAgZGV0ZXJtaW5lIHRoZSB0eXBlIG9mIHRoZSBub2RlLg0KPnwgICANCj58ICoq KioqKioqKioqKioqKg0KPnwgKioqIDc3MCw3NzcgKioqKg0KPnwgICANCj58ICAgDQo+fCAgICAg ICAgIFRoZXJlIGNhbiBiZSBhdCBtb3N0IG9uZSBpbnN0YW5jZSBvZiBlYWNoIHN1Yi1UTFYgdHlw ZSBwcmVzZW50DQo+aW4NCj58ICEgICAgICAgYW55IE5vZGUgRGVzY3JpcHRvci4gIFRoZSBUTFYg b3JkZXJpbmcgd2l0aGluIGEgTm9kZSBkZXNjcmlwdG9yDQo+fCAhICAgICAgIE1VU1QgYmUga2Vw dCBpbiBvcmRlciBvZiBpbmNyZWFzaW5nIG51bWVyaWMgdmFsdWUgb2YgdHlwZS4gIFRoaXMNCj58 ICAgICAgICAgbmVlZHMgdG8gYmUgZG9uZSBpbiBvcmRlciB0byBjb21wYXJlIE5MUklzLCBldmVu IHdoZW4gYW4NCj58ICAgICAgICAgaW1wbGVtZW50YXRpb24gZW5jb3VudGVycyBhbiB1bmtub3du IHN1Yi1UTFYuIFVzaW5nIHN0YWJsZQ0KPnNvcnRpbmcNCj58ICAgICAgICAgYW4gaW1wbGVtZW50 YXRpb24gY2FuIGRvIGJpbmFyeSBjb21wYXJpc29uIG9mIE5MUklzIGFuZCBoZW5jZQ0KPnwgLS0t IDc3MSw3NzggLS0tLQ0KPnwgICANCj58ICAgDQo+fCAgICAgICAgIFRoZXJlIGNhbiBiZSBhdCBt b3N0IG9uZSBpbnN0YW5jZSBvZiBlYWNoIHN1Yi1UTFYgdHlwZSBwcmVzZW50DQo+aW4NCj58ICEg ICAgICAgYW55IE5vZGUgRGVzY3JpcHRvci4gIFRoZSBzdWItVExWcyB3aXRoaW4gYSBOb2RlIGRl c2NyaXB0b3INCj58ICEgICAgICAgTVVTVCBiZSBhcnJhbmdlZCBpbiBhc2NlbmRpbmcgb3JkZXIg Ynkgc3ViLVRMViB0eXBlLiBUaGlzDQo+fCAgICAgICAgIG5lZWRzIHRvIGJlIGRvbmUgaW4gb3Jk ZXIgdG8gY29tcGFyZSBOTFJJcywgZXZlbiB3aGVuIGFuDQo+fCAgICAgICAgIGltcGxlbWVudGF0 aW9uIGVuY291bnRlcnMgYW4gdW5rbm93biBzdWItVExWLiBVc2luZyBzdGFibGUNCj5zb3J0aW5n DQo+fCAgICAgICAgIGFuIGltcGxlbWVudGF0aW9uIGNhbiBkbyBiaW5hcnkgY29tcGFyaXNvbiBv ZiBOTFJJcyBhbmQgaGVuY2UNCj58ICoqKioqKioqKioqKioqKg0KPnwgKioqIDgwNCw4MTIgKioq Kg0KPnwgICAgICBjYXJyaWVkIGluIHRoZSBUTFYuDQo+fCAgIA0KPnwgICAgICBUaGUgTVQtSUQg VExWIE1BWSBiZSBwcmVzZW50IGluIGEgTGluayBEZXNjcmlwdG9yLCBhIFByZWZpeA0KPnwgISAg ICBEZXNjcmlwdG9yLCBvciBpbiB0aGUgQkdQLUxTIGF0dHJpYnV0ZSBvZiBhIG5vZGUgTkxSSS4g SW4gTGluayBvcg0KPnwgISAgICBQcmVmaXggRGVzY3JpcHRvciwgb25seSBvbmUgTVQtSUQgVExW IGNvbnRhaW5pbmcgb25seSB0aGUgTVQtSUQgb2YNCj58ICEgICAgdGhlIHRvcG9sb2d5IHdoZXJl IHRoZSBsaW5rIG9yIHRoZSBwcmVmaXggYmVsb25ncyBpcyBhbGxvd2VkLiAgSW4NCj50aGUNCj58 ICAgDQo+fCAgIA0KPnwgICANCj58IC0tLSA4MDUsODEzIC0tLS0NCj58ICAgICAgY2FycmllZCBp biB0aGUgVExWLg0KPnwgICANCj58ICAgICAgVGhlIE1ULUlEIFRMViBNQVkgYmUgcHJlc2VudCBp biBhIExpbmsgRGVzY3JpcHRvciwgYSBQcmVmaXgNCj58ICEgICAgRGVzY3JpcHRvciwgb3IgaW4g dGhlIEJHUC1MUyBhdHRyaWJ1dGUgb2YgYSBub2RlIE5MUkkuIEluIGEgTGluayBvcg0KPnwgISAg ICBQcmVmaXggRGVzY3JpcHRvciwgb25seSBhIHNpbmdsZSBNVC1JRCBUTFYgY29udGFpbmluZyB0 aGUgTVQtSUQgb2YNCj58ICEgICAgdGhlIHRvcG9sb2d5IHdoZXJlIHRoZSBsaW5rIG9yIHRoZSBw cmVmaXggaXMgcmVhY2hhYmxlIGlzIGFsbG93ZWQuDQo+IEluIHRoZQ0KPnwgICANCj58ICAgDQo+ fCAgIA0KPnwgKioqKioqKioqKioqKioqDQo+fCAqKiogODI4LDgzNCAqKioqDQo+fCAgIEludGVy bmV0LURyYWZ0ICAgTGluay1TdGF0ZSBJbmZvIERpc3RyaWJ1dGlvbiB1c2luZyBCR1AgICAgICAg ICBNYXkNCj4yMDE0DQo+fCAgIA0KPnwgICAgICBCR1AtTFMgYXR0cmlidXRlIG9mIGEgbm9kZSBO TFJJLCBvbmUgTVQtSUQgVExWIGNvbnRhaW5pbmcgdGhlIGFycmF5DQo+fCAhICAgIG9mIE1ULUlE cyBvZiBhbGwgdG9wb2xvZ2llcyB3aGVyZSB0aGUgbm9kZSBiZWxvbmdzIGNhbiBiZSBwcmVzZW50 Lg0KPnwgICANCj58ICAgMy4yLjIuICBMaW5rIERlc2NyaXB0b3JzDQo+fCAgIA0KPnwgLS0tIDgy OSw4MzUgLS0tLQ0KPnwgICBJbnRlcm5ldC1EcmFmdCAgIExpbmstU3RhdGUgSW5mbyBEaXN0cmli dXRpb24gdXNpbmcgQkdQICAgICAgICAgTWF5DQo+MjAxNA0KPnwgICANCj58ICAgICAgQkdQLUxT IGF0dHJpYnV0ZSBvZiBhIG5vZGUgTkxSSSwgb25lIE1ULUlEIFRMViBjb250YWluaW5nIHRoZSBh cnJheQ0KPnwgISAgICBvZiBNVC1JRHMgb2YgYWxsIHRvcG9sb2dpZXMgd2hlcmUgdGhlIG5vZGUg aXMgcmVhY2hhYmxlIGlzIGFsbG93ZWQuDQo+fCAgIA0KPnwgICAzLjIuMi4gIExpbmsgRGVzY3Jp cHRvcnMNCj58ICAgDQo+fCAqKioqKioqKioqKioqKioNCj58ICoqKiA4MzgsODQ1ICoqKioNCj58 ICAgICAgbGlua3MgYmV0d2VlbiBhIHBhaXIgb2YgYW5jaG9yIHJvdXRlcnMuICBBIGxpbmsgZGVz Y3JpYmVkIGJ5IHRoZQ0KPkxpbmsNCj58ICAgICAgZGVzY3JpcHRvciBUTFZzIGFjdHVhbGx5IGlz IGEgImhhbGYtbGluayIsIGEgdW5pZGlyZWN0aW9uYWwNCj58ICAgICAgcmVwcmVzZW50YXRpb24g b2YgYSBsb2dpY2FsIGxpbmsuICBJbiBvcmRlciB0byBmdWxseSBkZXNjcmliZSBhDQo+fCAhICAg IHNpbmdsZSBsb2dpY2FsIGxpbmsgdHdvIG9yaWdpbmF0aW5nIHJvdXRlcnMgYWR2ZXJ0aXNlIGEg aGFsZi1saW5rDQo+fCAhICAgIGVhY2gsIGkuZS4gIHR3byBsaW5rIE5MUklzIGFyZSBhZHZlcnRp c2VkIGZvciBhIGdpdmVuDQo+cG9pbnQtdG8tcG9pbnQNCj58ICAgICAgbGluay4NCj58ICAgDQo+ fCAgICAgIFRoZSBmb3JtYXQgYW5kIHNlbWFudGljcyBvZiB0aGUgJ3ZhbHVlJyBmaWVsZHMgaW4g bW9zdCAnTGluaw0KPnwgLS0tIDgzOSw4NDYgLS0tLQ0KPnwgICAgICBsaW5rcyBiZXR3ZWVuIGEg cGFpciBvZiBhbmNob3Igcm91dGVycy4gIEEgbGluayBkZXNjcmliZWQgYnkgdGhlDQo+TGluaw0K PnwgICAgICBkZXNjcmlwdG9yIFRMVnMgYWN0dWFsbHkgaXMgYSAiaGFsZi1saW5rIiwgYSB1bmlk aXJlY3Rpb25hbA0KPnwgICAgICByZXByZXNlbnRhdGlvbiBvZiBhIGxvZ2ljYWwgbGluay4gIElu IG9yZGVyIHRvIGZ1bGx5IGRlc2NyaWJlIGENCj58ICEgICAgc2luZ2xlIGxvZ2ljYWwgbGluaywg dHdvIG9yaWdpbmF0aW5nIHJvdXRlcnMgYWR2ZXJ0aXNlIGEgaGFsZi1saW5rDQo+fCAhICAgIGVh Y2gsIGkuZS4sIHR3byBsaW5rIE5MUklzIGFyZSBhZHZlcnRpc2VkIGZvciBhIGdpdmVuDQo+cG9p bnQtdG8tcG9pbnQNCj58ICAgICAgbGluay4NCj58ICAgDQo+fCAgICAgIFRoZSBmb3JtYXQgYW5k IHNlbWFudGljcyBvZiB0aGUgJ3ZhbHVlJyBmaWVsZHMgaW4gbW9zdCAnTGluaw0KPnwgKioqKioq KioqKioqKioqDQo+fCAqKiogODg4LDg5NCAqKioqDQo+fCAgIA0KPnwgICAgICAgICBJZiBpbnRl cmZhY2UgYW5kIG5laWdoYm9yIGFkZHJlc3NlcyBhcmUgbm90IHByZXNlbnQgYW5kIHRoZSBsaW5r DQo+fCAgICAgICAgIGxvY2FsL3JlbW90ZSBpZGVudGlmaWVycyBhcmUgcHJlc2VudCwgdGhlbiB0 aGUgbGluayBsb2NhbC9yZW1vdGUNCj58ICEgICAgICAgSWRlbnRpZmllciBUTFYgaXMgaW5jbHVk ZWQgaW4gbGluayBkZXNjcmlwdG9yLg0KPnwgICANCj58ICAgICAgICAgVGhlIE11bHRpLVRvcG9s b2d5IElkZW50aWZpZXIgVExWIGlzIGluY2x1ZGVkIGluIGxpbmsgZGVzY3JpcHRvcg0KPnwgICAg ICAgICBpZiB0aGF0IGluZm9ybWF0aW9uIGlzIHByZXNlbnQuDQo+fCAtLS0gODg5LDg5NSAtLS0t DQo+fCAgIA0KPnwgICAgICAgICBJZiBpbnRlcmZhY2UgYW5kIG5laWdoYm9yIGFkZHJlc3NlcyBh cmUgbm90IHByZXNlbnQgYW5kIHRoZSBsaW5rDQo+fCAgICAgICAgIGxvY2FsL3JlbW90ZSBpZGVu dGlmaWVycyBhcmUgcHJlc2VudCwgdGhlbiB0aGUgbGluayBsb2NhbC9yZW1vdGUNCj58ICEgICAg ICAgSWRlbnRpZmllciBUTFYgaXMgaW5jbHVkZWQgaW4gdGhlIGxpbmsgZGVzY3JpcHRvci4NCj58 ICAgDQo+fCAgICAgICAgIFRoZSBNdWx0aS1Ub3BvbG9neSBJZGVudGlmaWVyIFRMViBpcyBpbmNs dWRlZCBpbiBsaW5rIGRlc2NyaXB0b3INCj58ICAgICAgICAgaWYgdGhhdCBpbmZvcm1hdGlvbiBp cyBwcmVzZW50Lg0KPnwgKioqKioqKioqKioqKioqDQo+fCAqKiogOTE3LDkyNCAqKioqDQo+fCAg ICAgIE9TUEYgUm91dGUgVHlwZSBpcyBhbiBvcHRpb25hbCBUTFYgdGhhdCBNQVkgYmUgcHJlc2Vu dCBpbiBQcmVmaXgNCj58ICAgICAgTkxSSXMuICBJdCBpcyB1c2VkIHRvIGlkZW50aWZ5IHRoZSBP U1BGIHJvdXRlLXR5cGUgb2YgdGhlIHByZWZpeC4NCj5JdA0KPnwgICAgICBpcyB1c2VkIHdoZW4g YW4gT1NQRiBwcmVmaXggaXMgYWR2ZXJ0aXNlZCBpbiB0aGUgT1NQRiBkb21haW4gd2l0aA0KPnwg ISAgICBtdWx0aXBsZSBkaWZmZXJlbnQgcm91dGUtdHlwZXMuICBUaGUgUm91dGUgVHlwZSBUTFYg YWxsb3dzIHRvDQo+fCAhICAgIGRpc2NyaW1pbmF0ZSB0aGVzZSBhZHZlcnRpc2VtZW50cy4gIFRo ZSBmb3JtYXQgb2YgdGhlIE9TUEYgUm91dGUNCj5UeXBlDQo+fCAgICAgIFRMViBpcyBzaG93biBp biB0aGUgZm9sbG93aW5nIGZpZ3VyZS4NCj58ICAgDQo+fCAgICAgICAwICAgICAgICAgICAgICAg ICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAgICAgICAgICAzDQo+fCAtLS0gOTE4 LDkyNSAtLS0tDQo+fCAgICAgIE9TUEYgUm91dGUgVHlwZSBpcyBhbiBvcHRpb25hbCBUTFYgdGhh dCBNQVkgYmUgcHJlc2VudCBpbiBQcmVmaXgNCj58ICAgICAgTkxSSXMuICBJdCBpcyB1c2VkIHRv IGlkZW50aWZ5IHRoZSBPU1BGIHJvdXRlLXR5cGUgb2YgdGhlIHByZWZpeC4NCj5JdA0KPnwgICAg ICBpcyB1c2VkIHdoZW4gYW4gT1NQRiBwcmVmaXggaXMgYWR2ZXJ0aXNlZCBpbiB0aGUgT1NQRiBk b21haW4gd2l0aA0KPnwgISAgICBtdWx0aXBsZSByb3V0ZS10eXBlcy4gIFRoZSBSb3V0ZSBUeXBl IFRMViBhbGxvd3MgZGlzY3JpbWluYXRpb24gb2YNCj58ICEgICAgdGhlc2UgYWR2ZXJ0aXNlbWVu dHMuICBUaGUgZm9ybWF0IG9mIHRoZSBPU1BGIFJvdXRlIFR5cGUNCj58ICAgICAgVExWIGlzIHNo b3duIGluIHRoZSBmb2xsb3dpbmcgZmlndXJlLg0KPnwgICANCj58ICAgICAgIDAgICAgICAgICAg ICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMNCj58ICoq KioqKioqKioqKioqKg0KPnwgKioqIDk1Nyw5NjMgKioqKg0KPnwgICANCj58ICAgICAgVGhlIElQ IFJlYWNoYWJpbGl0eSBJbmZvcm1hdGlvbiBpcyBhIG1hbmRhdG9yeSBUTFYgdGhhdCBjb250YWlu cw0KPm9uZQ0KPnwgICAgICBJUCBhZGRyZXNzIHByZWZpeCAoSVB2NCBvciBJUHY2KSBvcmlnaW5h bGx5IGFkdmVydGlzZWQgaW4gdGhlIElHUA0KPnwgISAgICB0b3BvbG9neS4gIEl0cyBwdXJwb3Nl IGlzIHRvIGdsdWUgYSBwYXJ0aWN1bGFyIEJHUCBzZXJ2aWNlIE5MUkkgdmkNCj58ICAgICAgdmly dHVlIG9mIGl0cyBCR1AgbmV4dC1ob3AgdG8gYSBnaXZlbiBOb2RlIGluIHRoZSBMU0RCLiBBIHJv dXRlcg0KPnwgICAgICBTSE9VTEQgYWR2ZXJ0aXNlIGFuIElQIFByZWZpeCBOTFJJIGZvciBlYWNo IG9mIGl0cyBCR1AgTmV4dC1ob3BzLg0KPnwgICAgICBUaGUgZm9ybWF0IG9mIHRoZSBJUCBSZWFj aGFiaWxpdHkgSW5mb3JtYXRpb24gVExWIGlzIHNob3duIGluIHRoZQ0KPnwgLS0tIDk1OCw5NjQg LS0tLQ0KPnwgICANCj58ICAgICAgVGhlIElQIFJlYWNoYWJpbGl0eSBJbmZvcm1hdGlvbiBpcyBh IG1hbmRhdG9yeSBUTFYgdGhhdCBjb250YWlucw0KPm9uZQ0KPnwgICAgICBJUCBhZGRyZXNzIHBy ZWZpeCAoSVB2NCBvciBJUHY2KSBvcmlnaW5hbGx5IGFkdmVydGlzZWQgaW4gdGhlIElHUA0KPnwg ISAgICB0b3BvbG9neS4gIEl0cyBwdXJwb3NlIGlzIHRvIGdsdWUgYSBwYXJ0aWN1bGFyIEJHUCBz ZXJ2aWNlIE5MUkkgYnkNCj58ICAgICAgdmlydHVlIG9mIGl0cyBCR1AgbmV4dC1ob3AgdG8gYSBn aXZlbiBOb2RlIGluIHRoZSBMU0RCLiBBIHJvdXRlcg0KPnwgICAgICBTSE9VTEQgYWR2ZXJ0aXNl IGFuIElQIFByZWZpeCBOTFJJIGZvciBlYWNoIG9mIGl0cyBCR1AgTmV4dC1ob3BzLg0KPnwgICAg ICBUaGUgZm9ybWF0IG9mIHRoZSBJUCBSZWFjaGFiaWxpdHkgSW5mb3JtYXRpb24gVExWIGlzIHNo b3duIGluIHRoZQ0KPnwgKioqKioqKioqKioqKioqDQo+fCAqKiogMTA1MiwxMDYxICoqKioNCj58 ICAgMy4zLjEuMi4gIElTLUlTIEFyZWEgSWRlbnRpZmllciBUTFYNCj58ICAgDQo+fCAgICAgIEFu IElTLUlTIG5vZGUgY2FuIGJlIHBhcnQgb2Ygb25lIG9yIG1vcmUgSVMtSVMgYXJlYXMuICBFYWNo IG9mDQo+dGhlc2UNCj58ICEgICAgYXJlYSBhZGRyZXNzZXMgaXMgY2FycmllZCBpbiB0aGUgSVMt SVMgQXJlYSBJZGVudGlmaWVyIFRMVi4gSWYgbW9yZQ0KPnwgISAgICB0aGFuIG9uZSBBcmVhIEFk ZHJlc3NlcyBhcmUgcHJlc2VudCwgbXVsdGlwbGUgVExWcyBhcmUgdXNlZCB0bw0KPmVuY29kZQ0K PnwgICAgICB0aGVtLiAgVGhlIElTLUlTIEFyZWEgSWRlbnRpZmllciBUTFYgbWF5IGJlIHByZXNl bnQgaW4gdGhlIEJHUC1MUw0KPnwgISAgICBhdHRyaWJ1dGUgb25seSB3aXRoIHRoZSBMaW5rLVN0 YXRlIE5vZGUgTkxSSS4NCj58ICAgDQo+fCAgIA0KPnwgICANCj58IC0tLSAxMDUzLDEwNjIgLS0t LQ0KPnwgICAzLjMuMS4yLiAgSVMtSVMgQXJlYSBJZGVudGlmaWVyIFRMVg0KPnwgICANCj58ICAg ICAgQW4gSVMtSVMgbm9kZSBjYW4gYmUgcGFydCBvZiBvbmUgb3IgbW9yZSBJUy1JUyBhcmVhcy4g IEVhY2ggb2YNCj50aGVzZQ0KPnwgISAgICBhcmVhIGFkZHJlc3NlcyBpcyBjYXJyaWVkIGluIHRo ZSBJUy1JUyBBcmVhIElkZW50aWZpZXIgVExWLiBJZg0KPm11bHRpcGxlDQo+fCAhICAgIEFyZWEg QWRkcmVzc2VzIGFyZSBwcmVzZW50LCBtdWx0aXBsZSBUTFZzIGFyZSB1c2VkIHRvIGVuY29kZQ0K PnwgICAgICB0aGVtLiAgVGhlIElTLUlTIEFyZWEgSWRlbnRpZmllciBUTFYgbWF5IGJlIHByZXNl bnQgaW4gdGhlIEJHUC1MUw0KPnwgISAgICBhdHRyaWJ1dGUgb25seSB3aGVuIGFkdmVydGlzZWQg aW4gdGhlIExpbmstU3RhdGUgTm9kZSBOTFJJLg0KPnwgICANCj58ICAgDQo+fCAgIA0KPnwgKioq KioqKioqKioqKioqDQo+fCAqKiogMTA4NywxMDkzICoqKioNCj58ICAgICAgVG9Vbmljb2RlIGFs Z29yaXRobSBhcyBkZXNjcmliZWQgaW4gW1JGQzU4OTBdIHRvIGFjaGlldmUgdGhlDQo+Y29ycmVj dA0KPnwgICAgICBmb3JtYXQgZm9yIHRyYW5zbWlzc2lvbiBvciBkaXNwbGF5Lg0KPnwgICANCj58 ICEgICAgQWx0b3VnaCBbUkZDNTMwMV0gaXMgYSBJUy1JUyBzcGVjaWZpYyBleHRlbnNpb24sIHVz YWdlIG9mIHRoZSBOb2RlDQo+fCAgICAgIE5hbWUgVExWIGlzIHBvc3NpYmxlIGZvciBhbGwgcHJv dG9jb2xzLiAgSG93IGEgcm91dGVyIGRlcml2ZXMgYW5kDQo+fCAgICAgIGluamVjdHMgbm9kZSBu YW1lcyBmb3IgZS5nLiAgT1NQRiBub2RlcywgaXMgb3V0c2lkZSBvZiB0aGUgc2NvcGUgb2YNCj58 ICAgICAgdGhpcyBkb2N1bWVudC4NCj58IC0tLSAxMDg4LDEwOTQgLS0tLQ0KPnwgICAgICBUb1Vu aWNvZGUgYWxnb3JpdGhtIGFzIGRlc2NyaWJlZCBpbiBbUkZDNTg5MF0gdG8gYWNoaWV2ZSB0aGUN Cj5jb3JyZWN0DQo+fCAgICAgIGZvcm1hdCBmb3IgdHJhbnNtaXNzaW9uIG9yIGRpc3BsYXkuDQo+ fCAgIA0KPnwgISAgICBBbHRvdWdoIFtSRkM1MzAxXSBpcyBhbiBJUy1JUyBzcGVjaWZpYyBleHRl bnNpb24sIHVzYWdlIG9mIHRoZSBOb2RlDQo+fCAgICAgIE5hbWUgVExWIGlzIHBvc3NpYmxlIGZv ciBhbGwgcHJvdG9jb2xzLiAgSG93IGEgcm91dGVyIGRlcml2ZXMgYW5kDQo+fCAgICAgIGluamVj dHMgbm9kZSBuYW1lcyBmb3IgZS5nLiAgT1NQRiBub2RlcywgaXMgb3V0c2lkZSBvZiB0aGUgc2Nv cGUgb2YNCj58ICAgICAgdGhpcyBkb2N1bWVudC4NCj58ICoqKioqKioqKioqKioqKg0KPnwgKioq IDEyODEsMTI4OCAqKioqDQo+fCAgICAgIFRoZSBJR1AgTWV0cmljIFRMViBjYXJyaWVzIHRoZSBt ZXRyaWMgZm9yIHRoaXMgbGluay4gIFRoZSBsZW5ndGggb2YNCj58ICAgICAgdGhpcyBUTFYgaXMg dmFyaWFibGUsIGRlcGVuZGluZyBvbiB0aGUgbWV0cmljIHdpZHRoIG9mIHRoZQ0KPnVuZGVybHlp bmcNCj58ICAgICAgcHJvdG9jb2wuICBJUy1JUyBzbWFsbCBtZXRyaWNzIGhhdmUgYSBsZW5ndGgg b2YgMSBvY3RldCAodGhlIHR3bw0KPm1vc3QNCj58ICEgICAgc2lnbmlmaWNhbnQgYml0cyBhcmUg aWdub3JlZCkuICBPU1BGIG1ldHJpY3MgaGF2ZSBhIGxlbmd0aCBvZiB0d28NCj58ICEgICAgb2N0 ZWN0cy4gIElTLUlTIHdpZGUtbWV0cmljcyBoYXZlIGEgbGVuZ3RoIG9mIHRocmVlIG9jdGV0cy4N Cj58ICAgDQo+fCAgICAgICAwICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAg MiAgICAgICAgICAgICAgICAgICAzDQo+fCAgICAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAy IDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDENCj58IC0tLSAxMjgyLDEyODkg LS0tLQ0KPnwgICAgICBUaGUgSUdQIE1ldHJpYyBUTFYgY2FycmllcyB0aGUgbWV0cmljIGZvciB0 aGlzIGxpbmsuICBUaGUgbGVuZ3RoIG9mDQo+fCAgICAgIHRoaXMgVExWIGlzIHZhcmlhYmxlLCBk ZXBlbmRpbmcgb24gdGhlIG1ldHJpYyB3aWR0aCBvZiB0aGUNCj51bmRlcmx5aW5nDQo+fCAgICAg IHByb3RvY29sLiAgSVMtSVMgc21hbGwgbWV0cmljcyBoYXZlIGEgbGVuZ3RoIG9mIDEgb2N0ZXQg KHRoZSB0d28NCj5tb3N0DQo+fCAhICAgIHNpZ25pZmljYW50IGJpdHMgYXJlIGlnbm9yZWQpLiAg T1NQRiBsaW5rIG1ldHJpY3MgaGF2ZSBhIGxlbmd0aCBvZg0KPnR3bw0KPnwgISAgICBvY3RldHMu ICBJUy1JUyB3aWRlLW1ldHJpY3MgaGF2ZSBhIGxlbmd0aCBvZiB0aHJlZSBvY3RldHMuDQo+fCAg IA0KPnwgICAgICAgMCAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAg ICAgICAgICAgICAgICAgMw0KPnwgICAgICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQg NSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxDQo+fCAqKioqKioqKioqKioqKioNCj58 ICoqKiAxNTQyLDE1NDkgKioqKg0KPnwgICANCj58ICAgICAgQkdQIGxpbmstc3RhdGUgaW5mb3Jt YXRpb24gZm9yIGJvdGggSVB2NCBhbmQgSVB2NiBuZXR3b3JrcyBjYW4gYmUNCj58ICAgICAgY2Fy cmllZCBvdmVyIGVpdGhlciBhbiBJUHY0IEJHUCBzZXNzaW9uLCBvciBhbiBJUHY2IEJHUCBzZXNz aW9uLg0KPklmDQo+fCAhICAgIElQdjQgQkdQIHNlc3Npb24gaXMgdXNlZCwgdGhlbiB0aGUgbmV4 dCBob3AgaW4gdGhlIE1QX1JFQUNIX05MUkkNCj58ICEgICAgU0hPVUxEIGJlIGFuIElQdjQgYWRk cmVzcy4gIFNpbWlsYXJseSwgaWYgSVB2NiBCR1Agc2Vzc2lvbiBpcyB1c2VkLA0KPnwgICAgICB0 aGVuIHRoZSBuZXh0IGhvcCBpbiB0aGUgTVBfUkVBQ0hfTkxSSSBTSE9VTEQgYmUgYW4gSVB2NiBh ZGRyZXNzLg0KPnwgICAgICBVc3VhbGx5IHRoZSBuZXh0IGhvcCB3aWxsIGJlIHNldCB0byB0aGUg bG9jYWwgZW5kLXBvaW50IGFkZHJlc3Mgb2YNCj58ICAgICAgdGhlIEJHUCBzZXNzaW9uLiAgVGhl IG5leHQgaG9wIGFkZHJlc3MgTVVTVCBiZSBlbmNvZGVkIGFzIGRlc2NyaWJlZA0KPnwgLS0tIDE1 NDMsMTU1MCAtLS0tDQo+fCAgIA0KPnwgICAgICBCR1AgbGluay1zdGF0ZSBpbmZvcm1hdGlvbiBm b3IgYm90aCBJUHY0IGFuZCBJUHY2IG5ldHdvcmtzIGNhbiBiZQ0KPnwgICAgICBjYXJyaWVkIG92 ZXIgZWl0aGVyIGFuIElQdjQgQkdQIHNlc3Npb24sIG9yIGFuIElQdjYgQkdQIHNlc3Npb24uDQo+ SWYNCj58ICEgICAgYW4gSVB2NCBCR1Agc2Vzc2lvbiBpcyB1c2VkLCB0aGVuIHRoZSBuZXh0IGhv cCBpbiB0aGUgTVBfUkVBQ0hfTkxSSQ0KPnwgISAgICBTSE9VTEQgYmUgYW4gSVB2NCBhZGRyZXNz LiAgU2ltaWxhcmx5LCBpZiBhbiBJUHY2IEJHUCBzZXNzaW9uIGlzDQo+dXNlZCwNCj58ICAgICAg dGhlbiB0aGUgbmV4dCBob3AgaW4gdGhlIE1QX1JFQUNIX05MUkkgU0hPVUxEIGJlIGFuIElQdjYg YWRkcmVzcy4NCj58ICAgICAgVXN1YWxseSB0aGUgbmV4dCBob3Agd2lsbCBiZSBzZXQgdG8gdGhl IGxvY2FsIGVuZC1wb2ludCBhZGRyZXNzIG9mDQo+fCAgICAgIHRoZSBCR1Agc2Vzc2lvbi4gIFRo ZSBuZXh0IGhvcCBhZGRyZXNzIE1VU1QgYmUgZW5jb2RlZCBhcyBkZXNjcmliZWQNCj58ICoqKioq KioqKioqKioqKg0KPnwgKioqIDE4MzMsMTgzOSAqKioqDQo+fCAgIA0KPnwgICAgICBBbiBpbXBs ZW1lbnRhdGlvbiBTSE9VTEQgYWxsb3cgdGhlIG9wZXJhdG9yIHRvIHNwZWNpZnkgdGhlIG1heGlt dW0NCj58ICAgICAgcmF0ZSBhdCB3aGljaCBMaW5rLVN0YXRlIE5MUklzIHdpbGwgYmUgYWR2ZXJ0 aXNlZC93aXRoZHJhd24gZnJvbQ0KPnwgISAgICBuZWlnaGJvcnMNCj58ICAgDQo+fCAgICAgIEFu IGltcGxlbWVudGF0aW9uIFNIT1VMRCBhbGxvdyB0aGUgb3BlcmF0b3IgdG8gc3BlY2lmeSB0aGUg bWF4aW11bQ0KPnwgICAgICBudW1iZXIgb2YgTGluay1TdGF0ZSBOTFJJcyBzdG9yZWQgaW4gcm91 dGVyJ3MgUklCLg0KPnwgLS0tIDE4MzQsMTg0MCAtLS0tDQo+fCAgIA0KPnwgICAgICBBbiBpbXBs ZW1lbnRhdGlvbiBTSE9VTEQgYWxsb3cgdGhlIG9wZXJhdG9yIHRvIHNwZWNpZnkgdGhlIG1heGlt dW0NCj58ICAgICAgcmF0ZSBhdCB3aGljaCBMaW5rLVN0YXRlIE5MUklzIHdpbGwgYmUgYWR2ZXJ0 aXNlZC93aXRoZHJhd24gZnJvbQ0KPnwgISAgICBuZWlnaGJvcnMuDQo+fCAgIA0KPnwgICAgICBB biBpbXBsZW1lbnRhdGlvbiBTSE9VTEQgYWxsb3cgdGhlIG9wZXJhdG9yIHRvIHNwZWNpZnkgdGhl IG1heGltdW0NCj58ICAgICAgbnVtYmVyIG9mIExpbmstU3RhdGUgTkxSSXMgc3RvcmVkIGluIHJv dXRlcidzIFJJQi4NCj58ICoqKioqKioqKioqKioqKg0KPnwgKioqIDE4NDYsMTg1MiAqKioqDQo+ fCAgICAgIGluc3RhbmNlIElELg0KPnwgICANCj58ICAgICAgQW4gaW1wbGVtZW50YXRpb24gU0hP VUxEIGFsbG93IHRoZSBvcGVyYXRvciB0byBjb25maWd1cmUgYSBwYWlyIG9mDQo+fCAhICAgIEFT TiBhbmQgQkdQLUxTIGlkZW50aWZpZXIgcGVyIGZsb29kaW5nIHNldCB0aGUgbm9kZSBwYXJ0aWNp cGF0ZXMNCj5pbi4NCj58ICAgDQo+fCAgIDYuMi40LiAgQWNjb3VudGluZyBNYW5hZ2VtZW50DQo+ fCAgIA0KPnwgLS0tIDE4NDcsMTg1MyAtLS0tDQo+fCAgICAgIGluc3RhbmNlIElELg0KPnwgICAN Cj58ICAgICAgQW4gaW1wbGVtZW50YXRpb24gU0hPVUxEIGFsbG93IHRoZSBvcGVyYXRvciB0byBj b25maWd1cmUgYSBwYWlyIG9mDQo+fCAhICAgIEFTTiBhbmQgQkdQLUxTIGlkZW50aWZpZXJzIHBl ciBmbG9vZGluZyBzZXQgaW4gd2hpY2ggdGhlIG5vZGUNCj5wYXJ0aWNpcGF0ZXMuDQo+fCAgIA0K PnwgICA2LjIuNC4gIEFjY291bnRpbmcgTWFuYWdlbWVudA0KPnwgICANCj58ICoqKioqKioqKioq KioqKg0KPnwgKioqIDE5ODEsMTk4NyAqKioqDQo+fCAgICAgIFNwZWFrZXIuDQo+fCAgIA0KPnwg ICAgICBBbiBvcGVyYXRvciBTSE9VTEQgZW1wbG95IGEgbWVjaGFuaXNtIHRvIHByb3RlY3QgYSBC R1AgU3BlYWtlcg0KPnwgISAgICBhZ2FpbnN0IERET1MgYXR0YWNrcyBmcm9tIENvbnN1bWVycy4g IFRoZSBwcmluY2lwYWwgYXR0YWNrIGENCj5jb25zdW1lcg0KPnwgICAgICBtYXkgYXBwbHkgaXMg dG8gYXR0ZW1wdCB0byBzdGFydCBtdWx0aXBsZSBzZXNzaW9ucyBlaXRoZXINCj58ICAgICAgc2Vx dWVudGlhbGx5IG9yIHNpbXVsdGFuZW91c2x5LiAgUHJvdGVjdGlvbiBjYW4gYmUgYXBwbGllZCBi eQ0KPnwgICAgICBpbXBvc2luZyByYXRlIGxpbWl0cy4NCj58IC0tLSAxOTgyLDE5ODggLS0tLQ0K PnwgICAgICBTcGVha2VyLg0KPnwgICANCj58ICAgICAgQW4gb3BlcmF0b3IgU0hPVUxEIGVtcGxv eSBhIG1lY2hhbmlzbSB0byBwcm90ZWN0IGEgQkdQIFNwZWFrZXINCj58ICEgICAgYWdhaW5zdCBE RG9TIGF0dGFja3MgZnJvbSBDb25zdW1lcnMuICBUaGUgcHJpbmNpcGFsIGF0dGFjayBhDQo+Y29u c3VtZXINCj58ICAgICAgbWF5IGFwcGx5IGlzIHRvIGF0dGVtcHQgdG8gc3RhcnQgbXVsdGlwbGUg c2Vzc2lvbnMgZWl0aGVyDQo+fCAgICAgIHNlcXVlbnRpYWxseSBvciBzaW11bHRhbmVvdXNseS4g IFByb3RlY3Rpb24gY2FuIGJlIGFwcGxpZWQgYnkNCj58ICAgICAgaW1wb3NpbmcgcmF0ZSBsaW1p dHMuDQo+fCANCj58IFRoYW5rcywNCj58IEFjZWUgDQo+fCANCg0KDQo= From nobody Fri Sep 12 02:38:53 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07BD51A06C3; Fri, 12 Sep 2014 02:38:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id flLpp4YsV6UX; Fri, 12 Sep 2014 02:38:49 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B21C31A069A; Fri, 12 Sep 2014 02:38:48 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id em10so257404wid.12 for ; Fri, 12 Sep 2014 02:38:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:content-type:content-transfer-encoding; bh=VvddJCbRB49QZzfq0edJwMnI/PTbuEFojH3oJCpJBvc=; b=lCg/EjY+CcrjIHbnYQrJD1RxZ69hVdcQvk99pfp5ig2UISASaQpdaYZRho0bYn5McJ ykqII12t13+udgqhAvqD1FwT9i9PgPhClkOVksA7f/IgEJI/mZqlnl/M6GB33Vi7V5SI 8e8jKqEV0DPthd7e/zDLvPI3/K/opJU6ShDMR9G9eIeAldLG2DR1QEWTSDrouqoE3mPY 2bpjyJWMuIej+GFbgcjqyP+ECqCeRGIGKjhqkVhjiV0b9O3GSsbcbarrxQ3uIdvbujLu FS4efSvYPu10kgfoyuaTBbc1AGNQ71ADOsx+5JaHyoZHfTg9EJ433F5Jw5tA8ouyeWhf CIVA== X-Received: by 10.194.172.137 with SMTP id bc9mr9659116wjc.72.1410514725085; Fri, 12 Sep 2014 02:38:45 -0700 (PDT) Received: from [127.0.0.1] (ARennes-652-1-175-135.w81-53.abo.wanadoo.fr. [81.53.190.135]) by mx.google.com with ESMTPSA id y5sm3928321wje.32.2014.09.12.02.38.43 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Sep 2014 02:38:44 -0700 (PDT) Sender: Thomas Morin Message-ID: <5412BF1F.7030206@orange.com> Date: Fri, 12 Sep 2014 11:38:39 +0200 From: Thomas Morin Organization: Orange User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: idr@ietf.org, "rtg-ads@tools.ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/idr/v2-NqtLGlL5cooKH4Im_m_Bsszg Cc: "rtg-dir@ietf.org" , draft-ietf-idr-as-migration.all@tools.ietf.org Subject: [Idr] RtgDir review: draft-ietf-idr-as-migration-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 09:38:52 -0000 Hello, In the context of Routing Area QA reviews (see https://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa ), I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​ http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-idr-as-migration-02 Reviewer: Thomas Morin Review Date: 2014-09-11 Intended Status: standards track *Summary:* I have some minor concerns about this document that I think should be resolved before publication. *Comments: * This is overall a very well written document, with a clear goal and concisely addressing its target goal.* * Although it is all about local behavior, it makes sense to make a standard track document that (a) can be used as a reference for implementors and deployers to implement this properly, and (b) keep track of these features in future evolutions of the protocol (as motivated in the Conclusion section of the document).* * *Major Issues:* No major issues found *Minor Issues: * A) The introduction says: In particular the ISP would have to encourage those customers to change their CE router configs to use the new ASN in a very short period of time, when the customer has no business incentive to do so. Thus, it becomes critical to allow the ISP to make this process a bit more asymmetric, so that it could seamlessly migrate the ASN within its network(s), but not disturb existing customers, and allow the customers to gradually migrate to the ISP's new ASN at their leisure. However, I did not understand which part of the specs would allow the customer to change its CE configuration without coordinating a maintenance window with the ISP. Procedures in section 3, as described, won't let the customer CE connect to the router with the new ASN. See, in particular in the second § of section 3.3: "The speaker MUST NOT use the ASN configured globally within the BGP process as the value sent in MY ASN in the OPEN message. ". It seems that the goal specified in the intro will thus not be met fully. Two things would be possible: fixing the intro to state a slightly different goal, or change the procedures to let a router establish a session with the globally assigned new AS, even when 'local-as old-AS" is configured. I'm not expert enough to know if the latter would work. B) still about the intro: it seems that this intro is focused on the motivation for eBGP-related features described in section 3, but silent on iBGP and section 4 C) in section 3, second §, there is a discussion about changing the AS_PATH length ; it seems to me that there is a hidden assumption on what interconnection exist between ISP A and ISP B prior to the migration ; the text says "whereas the same RIB on ISP A' would contain AS_PATH: 64510 64496, which is an increase in AS_PATH length from previously" which seems to indicate that ISP A and ISP B are peering with each other. If this is correct, this should be stated clearly in section 2, and not be a hidden assumption. D) in section 3: " Thus, within Loc-RIB on ISP B' the AS_PATH toward customer C would appear as: 64510". I would have thought that the AS_PATH of routes learned by PE routers of ISP B in this situation (if local-as no-prepend is not used), would be "64496" or "64510 64496" rather than "64510" alone... but I could just be wrong. E) In section 2, third paragraph: First, ISP B, will change the global BGP ASN used by a PE router, from ASN 64510 to 64500. At this point, the router will no longer be able to establish eBGP sessions toward the existing CE devices that are attached to it and still using AS 64510. Second, ISP B will configure two separate, but related ASN migration features discussed in this document on all eBGP sessions toward all CE devices. These features modify the AS_PATH attribute received from a CE device when advertising it further, and modify AS_PATH when transmitted toward CE devices to achieve the desired effect of not increasing the length of the AS_PATH. This high level description of the procedures in 3 is I think missing a description of the fact that, among the features of step 2 there is also a feature, not related to fixing the as path, that aims at allowing BGP sessions to be established using ASN 64510. I would suggest rewriting the last sentence as: These features allow the establishment of sessions with the legacy ASN 64510, modify the AS_PATH attribute received from a CE device when advertising it further, and modify AS_PATH when transmitted toward CE devices to achieve the desired effect of not increasing the length of the AS_PATH. F) section 3.1: it would be worth mentioning it explicitly, at the end of the first paragraph, that alone, this change results in an interruption of service G) the naming given to ASs and routers along the document**could I think be largely improved to make the document easier to read. I would suggest the following: * In the figures 3 and 4 of section 3.1 and 3.2: invert the figure left-right to have AS64499 on the left like in figures 1 and 2 * In the figures 3 and 4 of section 3.1 and 3.2, and associated text: instead of naming the PEs and CEs with 1 and 2, name them with A and B to match the ISP they are into (PE-A,CE-A,PE-B,CE-B instead of PE-2,CE-2,PE-1,CE-1) * modify figures 1 and 2 to make PE-A,CE-A,PE-B,CE-B appear on the figures * preferring "ISP A PE routers" to "ISP A's PE routers" to increase readability, or just "PE-A" or "PE-B" which is even shorter and less confusing (as an illustration section 3.2 says "Specifically, with 'Local AS No Prepend' enabled on ISP A's PE-1, it automatically causes..." , but does it mean "ISP A PE-1" or "ISP A' PE-1"...? given that PE-1 is actually in ISP B (==ISP A'), this is probably the second which is true, but here incorrectly written as "ISP A's PE-1"...) * section 3.1 mentions ISP B' ("within Loc-RIB on ISP B' the AS_PATH toward...") , but what ISP B' can only be guessed, you may want to define it in section 2(the set of routers in ISP B after the AS migration) H) section 3.2 says "Instead, only the historical (or legacy) AS will be prepended in the outbound BGP UPDATE toward customer's network, restoring the AS_PATH length to what it what was before AS Migration occurred." ; I would suggest adding ", as configured with the 'Local AS' feature described in section 3.1," before "will be prepended" I) I know the 'PE'/'CE' terminology to be widely used in the context of BPG-based VPNs, but, unless it is also widely used for non-VPN use cases, I would think that defining these terms would make sense (I don't know these terms to be widely used outside VPN use cases, but well, they might be in which case nothing is needed) J) the last § of section 3.1 looks to me as very much redundant to what is said in the rest of the section K) section 4.1 "NB: Cisco doesn't have an exact equivalent to "Internal BGP Alias", but the combination of the Cisco features iBGP local-AS and dual-as provides similar functionality." -- This sentence would be better-placed in section 10, IMO. L) section 4.1, itemized list, item 4: a reference to section 3 would be nice M) section 10: it would be interesting to indicate, for each vendor, what are the feature names corresponding to what is described in sections 3.1, 3.2 and 4 *Nits:* - In the abstract: s/feaures/features/ - In the abstract: the title would be more readable without "(AS)"; introducing this acronym, along with "ASN" can be done for instance in the introduction - in 3.1: "ISP B needs to do this without coordinating the change of its ASN with all of its eBGP peers, simultaneously." is not very easy to read (maybe "ISP B needs to be able to do this without coordinating a simultaneous change... peers" would be better?) - in 3.1: "Within the context of ISP B's PE router, The second effect ..." -> s/The/the/ Best, -Thomas From nobody Mon Sep 15 03:09:51 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB0D1A0AD6 for ; Mon, 15 Sep 2014 03:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.853 X-Spam-Level: X-Spam-Status: No, score=-5.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id paX16bFIO1nh for ; Mon, 15 Sep 2014 03:09:47 -0700 (PDT) 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 E40391A0715 for ; Mon, 15 Sep 2014 03:09:46 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJK71179; Mon, 15 Sep 2014 10:09:45 +0000 (GMT) Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 15 Sep 2014 11:09:44 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.18]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Mon, 15 Sep 2014 18:09:40 +0800 From: Xuxiaohu To: "idr@ietf. org" Thread-Topic: New Version Notification for draft-xu-idr-performance-routing-01.txt Thread-Index: AQHPzipqTcwoiQ4Ta0eXNTYbhuUGH5wB+wCg Date: Mon, 15 Sep 2014 10:09:40 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082B689B@NKGEML512-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/idr/r4_LRb7VQiEV_ZDXPoOdPLre1eI Cc: "draft-xu-idr-performance-routing-01@tools.ietf.org" Subject: [Idr] FW: New Version Notification for draft-xu-idr-performance-routing-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 10:09:49 -0000 SGkgYWxsLA0KDQpNYWpvciBjaGFuZ2VzIG9mIHRoaXMgcmV2aXNpb24gaW5jbHVkZToNCg0KMSkg dXNlIGEgVExWIG9mIHRoZSBBSUdQIGF0dHJpYnV0ZSByYXRoZXIgdGhhbiBhIG5ldyBwYXRoIGF0 dHJpYnV0ZSB0byBjYXJyeSB0aGUgTkVUV09SS19MQVRFTkNZIG1ldHJpYyBhY2NvcmRpbmcgdG8g c3VnZ2VzdGlvbnMgZnJvbSBtYW55IHBlb3BsZS4NCjIpIGFkZCB0d28gbmV3IGNvLWF1dGhvcnMg KFlpbWluIGFuZCBVbWEpLg0KDQpBbnkgZnVydGhlciBjb21tZW50cyBhbmQgc3VnZ2VzdGlvbnMg YXJlIHdlbGNvbWUuDQoNCkJlc3QgcmVnYXJkcywNClhpYW9odQ0KDQo+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+IEZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10NCj4gU2VudDogRnJpZGF5LCBTZXB0ZW1iZXIgMTIsIDIw MTQgOTozOSBBTQ0KPiBUbzogWWltaW4gU2hlbjsgVW1hIENodW5kdXJpOyBVbWEgQ2h1bmR1cmk7 IFh1eGlhb2h1OyBOaWh1aSAobmlodWksDQo+IFZSUERlc2lnbik7IE5paHVpIChuaWh1aSwgVlJQ RGVzaWduKTsgTmluZyBTbzsgWHV4aWFvaHU7IFlvbmdiaW5nIEZhbjsNCj4gQ2hyaXN0aWFuIEph Y3F1ZW5ldDsgTW9oYW1lZCBCb3VjYWRhaXI7IENocmlzdGlhbiBKYWNxdWVuZXQ7IE5pbmcgU287 IFlpbWluDQo+IFNoZW47IE1vaGFtZWQgQm91Y2FkYWlyOyBGYW4gWW9uZ2JpbmcNCj4gU3ViamVj dDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC14dS1pZHItcGVyZm9ybWFuY2Ut cm91dGluZy0wMS50eHQNCj4gDQo+IA0KPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQteHUt aWRyLXBlcmZvcm1hbmNlLXJvdXRpbmctMDEudHh0DQo+IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBz dWJtaXR0ZWQgYnkgWGlhb2h1IFh1IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4N Cj4gDQo+IE5hbWU6CQlkcmFmdC14dS1pZHItcGVyZm9ybWFuY2Utcm91dGluZw0KPiBSZXZpc2lv bjoJMDENCj4gVGl0bGU6CQlQZXJmb3JtYW5jZS1iYXNlZCBCR1AgUm91dGluZyBNZWNoYW5pc20N Cj4gRG9jdW1lbnQgZGF0ZToJMjAxNC0wOS0xMQ0KPiBHcm91cDoJCUluZGl2aWR1YWwgU3VibWlz c2lvbg0KPiBQYWdlczoJCTkNCj4gVVJMOg0KPiBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy9kcmFmdC14dS1pZHItcGVyZm9ybWFuY2Utcm91dGluZy0wMS50eHQNCj4gU3RhdHVz Og0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC14dS1pZHItcGVyZm9y bWFuY2Utcm91dGluZy8NCj4gSHRtbGl6ZWQ6DQo+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LXh1LWlkci1wZXJmb3JtYW5jZS1yb3V0aW5nLTAxDQo+IERpZmY6DQo+IGh0dHA6Ly93 d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXh1LWlkci1wZXJmb3JtYW5jZS1yb3V0aW5n LTAxDQo+IA0KPiBBYnN0cmFjdDoNCj4gICAgVGhlIGN1cnJlbnQgQkdQIHNwZWNpZmljYXRpb24g ZG9lc24ndCB1c2UgbmV0d29yayBwZXJmb3JtYW5jZSBtZXRyaWNzDQo+ICAgIChlLmcuLCBuZXR3 b3JrIGxhdGVuY3kpIGluIHRoZSByb3V0ZSBzZWxlY3Rpb24gZGVjaXNpb24gcHJvY2Vzcy4NCj4g ICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBwZXJmb3JtYW5jZS1iYXNlZCBCR1Agcm91dGlu ZyBtZWNoYW5pc20gaW4NCj4gICAgd2hpY2ggbmV0d29yayBsYXRlbmN5IG1ldHJpYyBpcyB0YWtl biBhcyBvbmUgb2YgdGhlIHJvdXRlIHNlbGVjdGlvbg0KPiAgICBjcml0ZXJpYS4gIFRoaXMgcm91 dGluZyBtZWNoYW5pc20gaXMgdXNlZnVsIGZvciB0aG9zZSBzZXJ2ZXINCj4gICAgcHJvdmlkZXJz IHdpdGggZ2xvYmFsIHJlYWNoIHRvIGRlbGl2ZXIgbG93LWxhdGVuY3kgbmV0d29yaw0KPiAgICBj b25uZWN0aXZpdHkgc2VydmljZXMgdG8gdGhlaXIgY3VzdG9tZXJzLg0KPiANCj4gDQo+IA0KPiAN Cj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20g dGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KPiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQg ZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPiANCj4gVGhlIElFVEYgU2Vj cmV0YXJpYXQNCg0K From nobody Mon Sep 15 07:43:59 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 007BA1A036A; Mon, 15 Sep 2014 07:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.321 X-Spam-Level: X-Spam-Status: No, score=-1.321 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-1.652, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l8NgaB8fqWNq; Mon, 15 Sep 2014 07:43:54 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 4453D1A036B; Mon, 15 Sep 2014 07:43:53 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 85A76C245; Mon, 15 Sep 2014 10:43:52 -0400 (EDT) Date: Mon, 15 Sep 2014 10:43:52 -0400 From: Jeffrey Haas To: Thomas Morin Message-ID: <20140915144352.GC14947@pfrc> References: <5412BF1F.7030206@orange.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5412BF1F.7030206@orange.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/D29_9ObNpN14cwfQJOEsgZaIGko Cc: idr@ietf.org, draft-ietf-idr-as-migration.all@tools.ietf.org, "rtg-dir@ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [Idr] RtgDir review: draft-ietf-idr-as-migration-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 14:43:56 -0000 On Fri, Sep 12, 2014 at 11:38:39AM +0200, Thomas Morin wrote: > Although it is all about local behavior, it makes sense to make a > standard track document that (a) can be used as a reference for > implementors and deployers to implement this properly, and (b) keep > track of these features in future evolutions of the protocol (as > motivated in the Conclusion section of the document).* My personal concern about making this a proposed standard is several of these mechanisms are not fully implemented even across the surveyed vendors. In many cases, there are differing implementations that serve similar needs but are slightly different to accommodate the implementation. This is despite the fact that, from a vendor standpoint, the features are internally mature. If there were strong motivations to move to a specific other-vendor transitional mechanism, it likely would have been done by now. To some extent, a proposed standard suggests that a given mechanism should be implemented. The current informational status says "this is what has been done". -- Jeff From nobody Mon Sep 15 08:02:18 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62C0A1A036A; Mon, 15 Sep 2014 08:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.117 X-Spam-Level: X-Spam-Status: No, score=-2.117 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qvrK2xEl8cfe; Mon, 15 Sep 2014 08:02:15 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 949101A037D; Mon, 15 Sep 2014 08:02:15 -0700 (PDT) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.04,528,1406606400"; d="scan'208";a="516702003" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 15 Sep 2014 10:59:47 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Mon, 15 Sep 2014 11:02:14 -0400 From: "George, Wes" To: Jeffrey Haas , Thomas Morin Date: Mon, 15 Sep 2014 11:02:13 -0400 Thread-Topic: [Idr] RtgDir review: draft-ietf-idr-as-migration-02 Thread-Index: Ac/Q9giEOLBKG/g3SxOVXm/nCMrgMw== Message-ID: References: <5412BF1F.7030206@orange.com> <20140915144352.GC14947@pfrc> In-Reply-To: <20140915144352.GC14947@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/EQ3zC7XnAU4-tg_6Sh4W_IJqHlY Cc: "idr@ietf.org" , "rtg-ads@tools.ietf.org" , "draft-ietf-idr-as-migration.all@tools.ietf.org" , "rtg-dir@ietf.org" Subject: Re: [Idr] RtgDir review: draft-ietf-idr-as-migration-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 15:02:17 -0000 T24gOS8xNS8xNCwgMTA6NDMgQU0sICJKZWZmcmV5IEhhYXMiIDxqaGFhc0BwZnJjLm9yZz4gd3Jv dGU6DQoNCg0KPk15IHBlcnNvbmFsIGNvbmNlcm4gYWJvdXQgbWFraW5nIHRoaXMgYSBwcm9wb3Nl ZCBzdGFuZGFyZCBpcyBzZXZlcmFsIG9mDQo+dGhlc2UgbWVjaGFuaXNtcyBhcmUgbm90IGZ1bGx5 IGltcGxlbWVudGVkIGV2ZW4gYWNyb3NzIHRoZSBzdXJ2ZXllZA0KPnZlbmRvcnMuDQo+SW4gbWFu eSBjYXNlcywgdGhlcmUgYXJlIGRpZmZlcmluZyBpbXBsZW1lbnRhdGlvbnMgdGhhdCBzZXJ2ZSBz aW1pbGFyDQo+bmVlZHMNCj5idXQgYXJlIHNsaWdodGx5IGRpZmZlcmVudCB0byBhY2NvbW1vZGF0 ZSB0aGUgaW1wbGVtZW50YXRpb24uICBUaGlzIGlzDQo+ZGVzcGl0ZSB0aGUgZmFjdCB0aGF0LCBm cm9tIGEgdmVuZG9yIHN0YW5kcG9pbnQsIHRoZSBmZWF0dXJlcyBhcmUNCj5pbnRlcm5hbGx5DQo+ bWF0dXJlLiAgSWYgdGhlcmUgd2VyZSBzdHJvbmcgbW90aXZhdGlvbnMgdG8gbW92ZSB0byBhIHNw ZWNpZmljDQo+b3RoZXItdmVuZG9yDQo+dHJhbnNpdGlvbmFsIG1lY2hhbmlzbSwgaXQgbGlrZWx5 IHdvdWxkIGhhdmUgYmVlbiBkb25lIGJ5IG5vdy4NCj4NCj5UbyBzb21lIGV4dGVudCwgYSBwcm9w b3NlZCBzdGFuZGFyZCBzdWdnZXN0cyB0aGF0IGEgZ2l2ZW4gbWVjaGFuaXNtIHNob3VsZA0KPmJl IGltcGxlbWVudGVkLiAgVGhlIGN1cnJlbnQgaW5mb3JtYXRpb25hbCBzdGF0dXMgc2F5cyAidGhp cyBpcyB3aGF0IGhhcw0KPmJlZW4gZG9uZSIuDQoNCldHXSBJJ3ZlIHN0cnVnZ2xlZCB3aXRoIHRo aXMgcHJvYmxlbSB0aHJvdWdob3V0IHRoZSB3cml0aW5nIG9mIHRoaXMgZHJhZnQuDQpBcyBJIG5v dGVkIGluIFRvcm9udG8sIHRoZXJlIHdhcyBzaWduaWZpY2FudCBkaXNjdXNzaW9uIGFtb25nIGEg Y291cGxlIG9mDQpteSBvZmZsaW5lIHJldmlld2VycyBhYm91dCB0aGUgdGVybWlub2xvZ3kgdXNl ZCwgc2luY2Ugc29tZSBvZiBpdCBpcw0Kc3BlY2lmaWMgdG8gb25lIHZlbmRvciB2cyBhbm90aGVy LiBJIGJlbGlldmUgdGhlIGRvY3VtZW50IGNhcHR1cmVzIHdoYXQNCndvdWxkIGJlIG5lY2Vzc2Fy eSBmb3IgYSAqbmV3KiBpbXBsZW1lbnRhdGlvbi4gV2hpbGUgbm90IGFsbCBleGlzdGluZw0KaW1w bGVtZW50YXRpb25zIG1heSBoYXZlIGltcGxlbWVudGVkIGFsbCBvZiB0aGUgZmVhdHVyZXMgZXhh Y3RseSBhcw0KZGVzY3JpYmVkIGhlcmUsIGlmIG9uZSB3ZXJlIGltcGxlbWVudGluZyBmcm9tIHNj cmF0Y2gsIGl0IG1heSBiZSBlYXNpZXIgdG8NCnVzZSB0aGlzIGFzIGEgYmFzZWxpbmUgaW5zdGVh ZCBvZiB0cnlpbmcgdG8gY29weSBvciByZXZlcnNlLWVuZ2luZWVyIGENCnZlbmRvci1zcGVjZmlj IGltcGxlbWVudGF0aW9uLg0KSSdtIG9wZW4gdG8gYWRkaW5nIHNvbWUgYWRkaXRpb25hbCB0ZXh0 IHRvIG1ha2UgaXQgY2xlYXIgdGhhdCB0aGlzIGlzDQpzaW1wbHkgZG9jdW1lbnRpbmcgYSByZWZl cmVuY2UgaW1wbGVtZW50YXRpb24gdGhhdCBjYW4gYmUgdXNlZCBmb3IgbmV3DQppbXBsZW1lbnRh dGlvbnMsIGJ1dCB0aGF0IGl0IGRvZXMgbm90IGltcGx5IGEgcmVxdWlyZW1lbnQgdG8gbW9kaWZ5 DQpleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMgdG8gaGFybW9uaXplIHRoZW0gd2l0aCB0aGlzIHN0 YW5kYXJkLg0KVGhlIGRvY3VtZW50IGRvZXMgc2F5IGluIG1vcmUgdGhhbiBvbmUgcGxhY2UgdGhh dCBpbnRlcm9wZXJhYmlsaXR5IGlzIG5vdA0KYSByZXF1aXJlbWVudCBiZWNhdXNlIHRoZSBmZWF0 dXJlcyBhcmUgYWxsIGxvY2FsbHkgc2lnbmlmaWNhbnQsIGJ1dCBpZiB5b3UNCmhhdmUgYSBzdWdn ZXN0aW9uIGZvciB0ZXh0IHRvIG1ha2UgdGhpcyBjbGVhcmVyLCBJJ20gaGFwcHkgdG8gaW5jb3Jw b3JhdGUNCml0Lg0KVGhlIG9ubHkgb3RoZXIgdGhpbmcgSSBjYW4gdGhpbmsgb2YgaGVyZSB3b3Vs ZCBiZSB0byBoYXZlIGEgbW9yZSBpbi1kZXB0aA0KY29tcGFyaXNvbiBiZXR3ZWVuIHRoZSBkaWZm ZXJlbnQgdmVuZG9yIGltcGxlbWVudGF0aW9ucywgYnV0IEkgZG9uJ3Qgc2VlDQp0aGUgcG9pbnQg aW4gZG9pbmcgdGhhdCBzaW5jZSBJJ20gYWxyZWFkeSBwb2ludGluZyB0byB0aGUgdmVuZG9yDQpk b2N1bWVudGF0aW9uLCBhbmQgY29tcGFyaW5nIGltcGxlbWVudGF0aW9ucyBkb2Vzbid0IHNlZW0g YXBwcm9wcmlhdGUgZm9yDQphIGRvY3VtZW50IGxpa2UgdGhpcy4NCg0KVGhhbmtzLA0KDQpXZXMN Cg0KDQpBbnl0aGluZyBiZWxvdyB0aGlzIGxpbmUgaGFzIGJlZW4gYWRkZWQgYnkgbXkgY29tcGFu eeKAmXMgbWFpbCBzZXJ2ZXIsIEkNCmhhdmUgbm8gY29udHJvbCBvdmVyIGl0Lg0KLS0tLS0tLS0t LS0NCg0KDQoNCg0KDQoNCg0KDQoNClRoaXMgRS1tYWlsIGFuZCBhbnkgb2YgaXRzIGF0dGFjaG1l bnRzIG1heSBjb250YWluIFRpbWUgV2FybmVyIENhYmxlIHByb3ByaWV0YXJ5IGluZm9ybWF0aW9u LCB3aGljaCBpcyBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWwsIG9yIHN1YmplY3QgdG8gY29weXJp Z2h0IGJlbG9uZ2luZyB0byBUaW1lIFdhcm5lciBDYWJsZS4gVGhpcyBFLW1haWwgaXMgaW50ZW5k ZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aGlj aCBpdCBpcyBhZGRyZXNzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQg b2YgdGhpcyBFLW1haWwsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWlu YXRpb24sIGRpc3RyaWJ1dGlvbiwgY29weWluZywgb3IgYWN0aW9uIHRha2VuIGluIHJlbGF0aW9u IHRvIHRoZSBjb250ZW50cyBvZiBhbmQgYXR0YWNobWVudHMgdG8gdGhpcyBFLW1haWwgaXMgc3Ry aWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgaGF2ZSByZWNlaXZl ZCB0aGlzIEUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0 ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUgdGhlIG9yaWdpbmFsIGFuZCBhbnkgY29weSBvZiB0 aGlzIEUtbWFpbCBhbmQgYW55IHByaW50b3V0Lg0K From nobody Mon Sep 15 10:24:11 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F34F11A0699; Mon, 15 Sep 2014 10:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.117 X-Spam-Level: X-Spam-Status: No, score=-2.117 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EyD8qEpYTtNg; Mon, 15 Sep 2014 10:23:59 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 799AA1A700C; Mon, 15 Sep 2014 09:44:37 -0700 (PDT) X-SENDER-IP: 10.136.163.13 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.04,529,1406606400"; d="scan'208";a="516818528" Received: from unknown (HELO PRVPEXHUB04.corp.twcable.com) ([10.136.163.13]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 15 Sep 2014 12:42:08 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB04.corp.twcable.com ([10.136.163.13]) with mapi; Mon, 15 Sep 2014 12:44:36 -0400 From: "George, Wes" To: Thomas Morin , "idr@ietf.org" , "rtg-ads@tools.ietf.org" Date: Mon, 15 Sep 2014 12:44:36 -0400 Thread-Topic: [Idr] RtgDir review: draft-ietf-idr-as-migration-02 Thread-Index: Ac/RBFWUjh2dA4e9Qpyu+3t3ycoanQ== Message-ID: References: <5412BF1F.7030206@orange.com> In-Reply-To: <5412BF1F.7030206@orange.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/AYh3IvdrqPqx9YrgqKNkGPnVFDs Cc: "rtg-dir@ietf.org" , "draft-ietf-idr-as-migration.all@tools.ietf.org" Subject: Re: [Idr] RtgDir review: draft-ietf-idr-as-migration-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 17:24:05 -0000 VGhhbmtzIGZvciB0aGUgdGhvcm91Z2ggcmV2aWV3LiBNeSByZXNwb25zZXMgYmVsb3cgaW5saW5l Lg0KDQpPbiA5LzEyLzE0LCA1OjM4IEFNLCAiVGhvbWFzIE1vcmluIiA8dGhvbWFzLm1vcmluQG9y YW5nZS5jb20+IHdyb3RlOg0KDQoNCj5BKSBUaGUgaW50cm9kdWN0aW9uIHNheXM6DQo+DQo+ICAg IEluIHBhcnRpY3VsYXINCj4gICAgdGhlIElTUCB3b3VsZCBoYXZlIHRvIGVuY291cmFnZSB0aG9z ZSBjdXN0b21lcnMgdG8gY2hhbmdlIHRoZWlyIENFDQo+ICAgIHJvdXRlciBjb25maWdzIHRvIHVz ZSB0aGUgbmV3IEFTTiBpbiBhIHZlcnkgc2hvcnQgcGVyaW9kIG9mIHRpbWUsDQo+ICAgIHdoZW4g dGhlIGN1c3RvbWVyIGhhcyBubyBidXNpbmVzcyBpbmNlbnRpdmUgdG8gZG8gc28uICBUaHVzLCBp dA0KPiAgICBiZWNvbWVzIGNyaXRpY2FsIHRvIGFsbG93IHRoZSBJU1AgdG8gbWFrZSB0aGlzIHBy b2Nlc3MgYSBiaXQgbW9yZQ0KPiAgICBhc3ltbWV0cmljLCBzbyB0aGF0IGl0IGNvdWxkIHNlYW1s ZXNzbHkgbWlncmF0ZSB0aGUgQVNOIHdpdGhpbiBpdHMNCj4gICAgbmV0d29yayhzKSwgYnV0IG5v dCBkaXN0dXJiIGV4aXN0aW5nIGN1c3RvbWVycywgYW5kIGFsbG93IHRoZQ0KPiAgICBjdXN0b21l cnMgdG8gZ3JhZHVhbGx5IG1pZ3JhdGUgdG8gdGhlIElTUCdzIG5ldyBBU04gYXQgdGhlaXIgbGVp c3VyZS4NCj4NCj5Ib3dldmVyLCBJIGRpZCBub3QgdW5kZXJzdGFuZCB3aGljaCBwYXJ0IG9mIHRo ZSBzcGVjcyB3b3VsZCBhbGxvdyB0aGUNCj5jdXN0b21lciB0byBjaGFuZ2UgaXRzIENFDQo+Y29u ZmlndXJhdGlvbiB3aXRob3V0IGNvb3JkaW5hdGluZyBhIG1haW50ZW5hbmNlIHdpbmRvdyB3aXRo IHRoZSBJU1AuDQoNCldHXSB3ZWxsLCB0aGF0IGlzIG5vdCBleGFjdGx5IHdoYXQgdGhlIGFib3Zl IHNheXMuIFRoZSBpZGVhIHdhcyB0byBtYWtlIGENCmRpc3RpbmN0aW9uIGJldHdlZW4gYSBnbG9i YWxseSBjb29yZGluYXRlZCB3aW5kb3cgYmV0d2VlbiBhbGwgY3VzdG9tZXJzIG9uDQp0aGUgcm91 dGVyIChzeW1tZXRyaWMgY2hhbmdlKSB2cyBiZWluZyBhYmxlIHRvIGNvb3JkaW5hdGUgaW5kaXZp ZHVhbGx5DQooYXN5bW1ldHJpYykuIEkgZG8gc2VlIHlvdXIgcG9pbnQgdGhvdWdoLCBhbmQgSSBj YW4gbWFrZSBpdCBtb3JlIGV4cGxpY2l0Lg0KDQo+DQo+UHJvY2VkdXJlcyBpbiBzZWN0aW9uIDMs IGFzICBkZXNjcmliZWQsIHdvbid0IGxldCB0aGUgY3VzdG9tZXIgQ0UNCj5jb25uZWN0IHRvIHRo ZSByb3V0ZXIgd2l0aCB0aGUgbmV3IEFTTi4gU2VlLCBpbiBwYXJ0aWN1bGFyIGluIHRoZSBzZWNv bmQNCj7CpyBvZiBzZWN0aW9uIDMuMzogIlRoZSBzcGVha2VyIE1VU1QgTk9UIHVzZSB0aGUgQVNO IGNvbmZpZ3VyZWQgZ2xvYmFsbHkNCj53aXRoaW4gdGhlIEJHUCBwcm9jZXNzIGFzIHRoZSB2YWx1 ZSBzZW50IGluIE1ZIEFTTiBpbiB0aGUgT1BFTiBtZXNzYWdlLg0KPiIuIEl0IHNlZW1zIHRoYXQg dGhlIGdvYWwgc3BlY2lmaWVkIGluIHRoZSBpbnRybyB3aWxsIHRodXMgbm90IGJlIG1ldA0KPmZ1 bGx5Lg0KPg0KPlR3byB0aGluZ3Mgd291bGQgYmUgcG9zc2libGU6IGZpeGluZyB0aGUgaW50cm8g dG8gc3RhdGUgYSBzbGlnaHRseQ0KPmRpZmZlcmVudCBnb2FsLCBvciBjaGFuZ2UgdGhlIHByb2Nl ZHVyZXMgdG8gbGV0IGEgcm91dGVyIGVzdGFibGlzaCBhDQo+c2Vzc2lvbiB3aXRoIHRoZSBnbG9i YWxseSBhc3NpZ25lZCBuZXcgQVMsIGV2ZW4gd2hlbiAnbG9jYWwtYXMgb2xkLUFTIg0KPmlzIGNv bmZpZ3VyZWQuIEknbSBub3QgZXhwZXJ0IGVub3VnaCB0byBrbm93IGlmIHRoZSBsYXR0ZXIgd291 bGQgd29yay4NCg0KV0ddIEknZCByZWZlciB5b3UgdG8gc2VjdGlvbiA0LjIsIHdoaWNoIGFsbG93 cyBhIG1vcmUgZmxleGlibGUNCmNvbmZpZ3VyYXRpb24gdGhhdCBjYW4gZXN0YWJsaXNoIGEgc2Vz c2lvbiB1c2luZyBlaXRoZXIgb2xkIG9yIG5ldyBBU04uDQpXaGlsZSBpdCdzIGRpc2N1c3NlZCBp biB0aGUgaUJHUCBzZWN0aW9uLCB0aGUgdGV4dCBkb2VzIG5vdGUgdGhhdCB0aGlzDQpjb3VsZCBi ZSBkb25lIHdoZXRoZXIgaW4gaUJHUCBvciBlQkdQLg0KDQoNCj4NCj5CKSBzdGlsbCBhYm91dCB0 aGUgaW50cm86IGl0IHNlZW1zIHRoYXQgdGhpcyBpbnRybyBpcyBmb2N1c2VkIG9uIHRoZQ0KPm1v dGl2YXRpb24gZm9yIGVCR1AtcmVsYXRlZCBmZWF0dXJlcyBkZXNjcmliZWQgaW4gc2VjdGlvbiAz LCBidXQgc2lsZW50DQo+b24gaUJHUCBhbmQgc2VjdGlvbiA0DQpXR10gSW4gbXkgbWluZCwgZUJH UCBpcyB0aGUgcHJpbWFyeSBtb3RpdmF0b3IgZm9yIHRoaXMgZHJhZnQgZHVlIHRvIHRoZQ0KZXh0 ZXJuYWwgY29vcmRpbmF0aW9uL0FTLXBhdGggbGVuZ3RoZW5pbmcgcHJvYmxlbXMuIGlCR1AgaXMg YSBoYXBweSB1cHNob3QNCnRvIHRoZSBmdW5jdGlvbmFsaXR5LCBzbyBJIGRpZG4ndCBzZWUgdGhl IG5lZWQgdG8gYWRkIHRoYXQgaW4gdGhlIGludHJvLg0KSSdsbCBtYWtlIGEgcGFzcyB0aHJvdWdo IHRvIHNlZSBpZiBJIGNhbiBmaXggdGhpcyB3aXRoIGEgbWluaW1hbCBhZGRpdGlvbi4NCg0KPg0K PkMpIGluIHNlY3Rpb24gMywgc2Vjb25kIMKnLCB0aGVyZSBpcyBhIGRpc2N1c3Npb24gYWJvdXQg Y2hhbmdpbmcgdGhlDQo+QVNfUEFUSCBsZW5ndGggOyBpdCBzZWVtcyB0byBtZSB0aGF0IHRoZXJl IGlzIGEgaGlkZGVuIGFzc3VtcHRpb24gb24NCj53aGF0IGludGVyY29ubmVjdGlvbiBleGlzdCBi ZXR3ZWVuIElTUCBBIGFuZCBJU1AgQiBwcmlvciB0byB0aGUNCj5taWdyYXRpb24gOyB0aGUgdGV4 dCBzYXlzICJ3aGVyZWFzIHRoZSBzYW1lIFJJQiBvbiBJU1AgQScgd291bGQgY29udGFpbg0KPkFT X1BBVEg6IDY0NTEwIDY0NDk2LCB3aGljaCBpcyBhbiBpbmNyZWFzZSBpbiBBU19QQVRIIGxlbmd0 aCBmcm9tDQo+cHJldmlvdXNseSIgd2hpY2ggc2VlbXMgdG8gaW5kaWNhdGUgdGhhdCBJU1AgQSBh bmQgSVNQIEIgYXJlIHBlZXJpbmcNCj53aXRoIGVhY2ggb3RoZXIuIElmIHRoaXMgaXMgY29ycmVj dCwgdGhpcyBzaG91bGQgYmUgc3RhdGVkIGNsZWFybHkgaW4NCj5zZWN0aW9uIDIsIGFuZCBub3Qg YmUgYSBoaWRkZW4gYXNzdW1wdGlvbi4NCg0KV0ddIGFjaywgbmVlZCB0byBtYWtlIGl0IGNsZWFy IHdoYXQgd2UgbWVhbiBieSAicHJldmlvdXNseSINCg0KPg0KPkQpIGluIHNlY3Rpb24gMzogIiBU aHVzLCB3aXRoaW4gTG9jLVJJQiBvbiBJU1AgQicgdGhlIEFTX1BBVEggdG93YXJkDQo+Y3VzdG9t ZXIgQyB3b3VsZCBhcHBlYXIgYXM6IDY0NTEwIi4gSSB3b3VsZCBoYXZlIHRob3VnaHQgdGhhdCB0 aGUNCj5BU19QQVRIIG9mIHJvdXRlcyBsZWFybmVkIGJ5IFBFIHJvdXRlcnMgb2YgSVNQIEIgaW4g dGhpcyBzaXR1YXRpb24gKGlmDQo+bG9jYWwtYXMgbm8tcHJlcGVuZCBpcyBub3QgdXNlZCksIHdv dWxkIGJlICI2NDQ5NiIgb3IgIjY0NTEwIDY0NDk2Ig0KPnJhdGhlciB0aGFuICI2NDUxMCIgYWxv bmUuLi4gYnV0IEkgY291bGQganVzdCBiZSB3cm9uZy4NCg0KV0ddIFRoaXMgaXMgZGVzY3JpYmlu ZyB0aGUgQVNfUEFUSCBwcmUtbWlncmF0aW9uLCBhbmQgdGhlbiBzaG93aW5nIHdoYXQNCmhhcHBl bnMgZHVyaW5nIG1pZ3JhdGlvbi4gSSB0aGluayBJIGNhbiBjbGFyaWZ5Lg0KDQo+DQo+RSkgSW4g c2VjdGlvbiAyLCB0aGlyZCBwYXJhZ3JhcGg6DQo+DQo+VGhpcyBoaWdoIGxldmVsIGRlc2NyaXB0 aW9uIG9mIHRoZSBwcm9jZWR1cmVzIGluIDMgaXMgSSB0aGluayBtaXNzaW5nIGENCj5kZXNjcmlw dGlvbiBvZiB0aGUgZmFjdCB0aGF0LCBhbW9uZyB0aGUgZmVhdHVyZXMgb2Ygc3RlcCAyIHRoZXJl IGlzIGFsc28NCj5hIGZlYXR1cmUsIG5vdCByZWxhdGVkIHRvIGZpeGluZyB0aGUgYXMgcGF0aCwg dGhhdCBhaW1zIGF0IGFsbG93aW5nIEJHUA0KPnNlc3Npb25zIHRvIGJlIGVzdGFibGlzaGVkIHVz aW5nIEFTTiA2NDUxMC4NCj5JIHdvdWxkIHN1Z2dlc3QgcmV3cml0aW5nIHRoZSBsYXN0IHNlbnRl bmNlIGFzOg0KPg0KPiAgICBUaGVzZSBmZWF0dXJlcyBhbGxvdyB0aGUgZXN0YWJsaXNobWVudCBv ZiBzZXNzaW9ucyB3aXRoIHRoZSBsZWdhY3kNCj5BU04gNjQ1MTAsDQo+ICAgIG1vZGlmeSB0aGUg QVNfUEFUSCBhdHRyaWJ1dGUgcmVjZWl2ZWQgZnJvbSBhIENFIGRldmljZSB3aGVuDQo+YWR2ZXJ0 aXNpbmcgaXQgZnVydGhlciwNCj4gICAgYW5kIG1vZGlmeSBBU19QQVRIIHdoZW4gdHJhbnNtaXR0 ZWQgdG93YXJkIENFIGRldmljZXMgdG8gYWNoaWV2ZSB0aGUNCj5kZXNpcmVkIGVmZmVjdCBvZiBu b3QNCj4gICAgaW5jcmVhc2luZyB0aGUgbGVuZ3RoIG9mIHRoZSBBU19QQVRILg0KDQpXR10gYWNr DQo+DQo+Rikgc2VjdGlvbiAzLjE6IGl0IHdvdWxkIGJlIHdvcnRoIG1lbnRpb25pbmcgaXQgZXhw bGljaXRseSwgYXQgdGhlIGVuZA0KPm9mIHRoZSBmaXJzdCBwYXJhZ3JhcGgsIHRoYXQgYWxvbmUs IHRoaXMgY2hhbmdlIHJlc3VsdHMgaW4gYW4NCj5pbnRlcnJ1cHRpb24gb2Ygc2VydmljZQ0KDQpX R10gYWNrDQo+DQo+RykgdGhlIG5hbWluZyBnaXZlbiB0byBBU3MgYW5kIHJvdXRlcnMgYWxvbmcg dGhlIGRvY3VtZW50Kipjb3VsZCBJIHRoaW5rDQo+YmUgbGFyZ2VseSBpbXByb3ZlZCB0byBtYWtl IHRoZSBkb2N1bWVudCBlYXNpZXIgdG8gcmVhZC4gSSB3b3VsZCBzdWdnZXN0DQo+dGhlIGZvbGxv d2luZzoNCj4qIEluIHRoZSBmaWd1cmVzIDMgYW5kIDQgb2Ygc2VjdGlvbiAzLjEgYW5kIDMuMjog IGludmVydCB0aGUgZmlndXJlDQo+bGVmdC1yaWdodCB0byBoYXZlIEFTNjQ0OTkgb24gdGhlIGxl ZnQgbGlrZSBpbiBmaWd1cmVzIDEgYW5kIDINCldHXSBJIHVuZGVyc3RhbmQgdGhlIHBhcmFsbGVs aXNtL3N5bW1ldHJ5IHRoYXQgeW91J3JlIHN1Z2dlc3RpbmcsIGJ1dA0KZmxpcHBpbmcgdGhlIEFT TnMgd291bGQgcmVxdWlyZSByZXdyaXRpbmcgYSBzdWJzdGFudGlhbCBhbW91bnQgb2YgdGhlDQpl eGFtcGxlLiBJIHRoaW5rIHlvdSdyZSBzdWdnZXN0aW5nIG1pcnJvciBpbWFnZSwgd2hpY2ggd291 bGQgbGVhdmUgdGhlDQpleGFtcGxlIHRleHQgdW5jaGFuZ2VkLCBidXQgYXNzdW1lcyB0aGF0IGV2 ZXJ5b25lIGlzIG9rIHdpdGggdGhlIGFycm93cw0KcG9pbnRpbmcgcmlnaHQgdG8gbGVmdCBpbiBm aWcgMywgYW5kIHRoZW4gbGVmdCB0byByaWdodCBpbiBmaWcgNCwgYXMgd2VsbA0KYXMgUEUyL0NF MiBzaG93aW5nIG9uIHRoZSBsZWZ0LCBQRTEvQ0UxIG9uIHRoZSByaWdodCBpbiBib3RoLCB3aGlj aCBpcw0Kc29ydCBvZiBiYWNrd2FyZCBmcm9tIHdlc3Rlcm4gY29udmVudGlvbiBhbmQgY29uZnVz aW5nIGZvciBhIGRpZmZlcmVudA0KcmVhc29uLiBJIHRoaW5rIEknbSBnb2luZyB0byBvZmZlbmQg YSBkaWZmZXJlbnQgc2V0IG9mIGFlc3RoZXRpY3Mgd2l0aA0KZWl0aGVyIG9uZSwgYW5kIEknbSBu b3Qgc3VyZSBpdCBtYWtlcyBhIGdyZWF0IGRlYWwgb2YgZGlmZmVyZW5jZSBpbiB0aGUNCnJlYWRh YmlsaXR5IG9mIHRoZSBmaWd1cmVzLiBPcGVuIGZvciBmdXJ0aGVyIGRpc2N1c3Npb24uDQoNCj4q IEluIHRoZSBmaWd1cmVzIDMgYW5kIDQgb2Ygc2VjdGlvbiAzLjEgYW5kIDMuMiwgYW5kIGFzc29j aWF0ZWQgdGV4dDoNCj5pbnN0ZWFkIG9mIG5hbWluZyB0aGUgUEVzIGFuZCBDRXMgIHdpdGggMSBh bmQgMiwgbmFtZSB0aGVtIHdpdGggQSBhbmQgQg0KPnRvIG1hdGNoIHRoZSBJU1AgdGhleSBhcmUg aW50byAoUEUtQSxDRS1BLFBFLUIsQ0UtQiBpbnN0ZWFkIG9mDQo+UEUtMixDRS0yLFBFLTEsQ0Ut MSkNCj4qIG1vZGlmeSBmaWd1cmVzIDEgYW5kIDIgdG8gbWFrZSBQRS1BLENFLUEsUEUtQixDRS1C IGFwcGVhciBvbiB0aGUgZmlndXJlcw0KDQpXR10gSSBkb24ndCB0aGluayB0aGF0IHRoaXMgd291 bGQgYmUgaGVscGZ1bCBzaW5jZSB5b3UncmUgbm90IGNvbnNpc3RlbnRseQ0KZGVhbGluZyB3aXRo IElTUCBBIG9yIEIgZHVyaW5nIHRoZSBtaWdyYXRpb24sIGJ1dCByYXRoZXIgQScsIHdoaWNoIGlz IGFuDQphbWFsZ2FtIG9mIGFsbCBvZiBJU1AgQSBhbmQgdGhlIHBhcnQgb2YgSVNQIEIgdGhhdCBo YXMgYmVlbiBzdWJzdW1lZCBieQ0KSVNQIEEuIEkgdGhpbmsgdXNpbmcgQSBvciBCIHdvdWxkIGNv bmZ1c2UgdGhpbmdzLCBzaW5jZSBpbiBwb3N0LW1pZ3JhdGlvbg0Kd2hhdCB5b3UgZW5kIHVwIHdp dGggaXMgMiBQRXMgaW4gdGhlIHNhbWUgSVNQLg0KDQoNCj4qIHByZWZlcnJpbmcgIklTUCBBIFBF IHJvdXRlcnMiIHRvICAiSVNQIEEncyBQRSByb3V0ZXJzIiB0byBpbmNyZWFzZQ0KPnJlYWRhYmls aXR5LCBvciBqdXN0ICJQRS1BIiBvciAiUEUtQiIgIHdoaWNoIGlzIGV2ZW4gc2hvcnRlciBhbmQg bGVzcw0KPmNvbmZ1c2luZyAgKGFzIGFuIGlsbHVzdHJhdGlvbiBzZWN0aW9uIDMuMiBzYXlzICJT cGVjaWZpY2FsbHksIHdpdGgNCj4nTG9jYWwgQVMgTm8gUHJlcGVuZCcgZW5hYmxlZCBvbiBJU1Ag QSdzIFBFLTEsIGl0IGF1dG9tYXRpY2FsbHkNCj5jYXVzZXMuLi4iICwgYnV0IGRvZXMgaXQgbWVh biAiSVNQIEEgUEUtMSIgb3IgIklTUCBBJyBQRS0xIi4uLj8gZ2l2ZW4NCj50aGF0IFBFLTEgaXMg YWN0dWFsbHkgaW4gSVNQIEIgKD09SVNQIEEnKSwgdGhpcyBpcyBwcm9iYWJseSB0aGUgc2Vjb25k DQo+d2hpY2ggaXMgdHJ1ZSwgYnV0IGhlcmUgaW5jb3JyZWN0bHkgd3JpdHRlbiBhcyAiSVNQIEEn cyBQRS0xIi4uLikNCldHXSBnb29kIHBvaW50LiBJJ2xsIG1ha2UgYSBwYXNzIHRocm91Z2ggdG8g ZWxpbWluYXRlIHRoZSB1c2Ugb2YNCnBvc3Nlc3NpdmUgKEEncykgd2hlbiBJJ20gYWxzbyB0YWxr aW5nIGFib3V0IElTUCBBIHByaW1lIChBJykgdG8gcmVkdWNlDQp0aGUgY29uZnVzaW9uLg0KDQo+ KiBzZWN0aW9uIDMuMSBtZW50aW9ucyBJU1AgQicgKCJ3aXRoaW4gTG9jLVJJQiBvbiBJU1AgQicg dGhlIEFTX1BBVEgNCj50b3dhcmQuLi4iKSAsIGJ1dCB3aGF0IElTUCBCJyBjYW4gb25seSBiZSBn dWVzc2VkLCB5b3UgbWF5IHdhbnQgdG8NCj5kZWZpbmUgaXQgaW4gc2VjdGlvbiAyKHRoZSBzZXQg b2Ygcm91dGVycyBpbiBJU1AgQiBhZnRlciB0aGUgQVMgbWlncmF0aW9uKQ0KDQpXR10gdGhhdCdz IGFuIGVkaXRpbmcgZXJyb3IsIG9yaWdpbmFsbHkgdGhlIHNlbnRlbmNlIHdhcyAiSVNQIEIncy4u LiINCihwb3NzZXNzaXZlKSBhbmQgdGhlIGFwb3N0cm9waGUgYXBwZWFycyB0byBoYXZlIGJlZW4g bGVmdCBiZWhpbmQgd2hlbiB0aGUNCnNlbnRlbmNlIHdhcyByZXdvcmRlZCB0byBlbGltaW5hdGUg dGhlIHBvc3Nlc3NpdmUuDQoNCj4NCj5IKSBzZWN0aW9uIDMuMiBzYXlzICJJbnN0ZWFkLCBvbmx5 IHRoZSBoaXN0b3JpY2FsIChvciBsZWdhY3kpIEFTIHdpbGwgYmUNCj5wcmVwZW5kZWQgaW4gdGhl IG91dGJvdW5kIEJHUCBVUERBVEUgdG93YXJkIGN1c3RvbWVyJ3MgbmV0d29yaywNCj5yZXN0b3Jp bmcgdGhlIEFTX1BBVEggbGVuZ3RoIHRvIHdoYXQgaXQgd2hhdCB3YXMgYmVmb3JlIEFTIE1pZ3Jh dGlvbg0KPm9jY3VycmVkLiIgOyBJIHdvdWxkIHN1Z2dlc3QgYWRkaW5nICIsIGFzIGNvbmZpZ3Vy ZWQgd2l0aCB0aGUgJ0xvY2FsIEFTJw0KPmZlYXR1cmUgZGVzY3JpYmVkIGluIHNlY3Rpb24gMy4x LCIgICBiZWZvcmUgIndpbGwgYmUgcHJlcGVuZGVkIg0KV0ddIGFjaw0KPg0KPkkpIEkga25vdyB0 aGUgJ1BFJy8nQ0UnIHRlcm1pbm9sb2d5IHRvIGJlIHdpZGVseSB1c2VkIGluIHRoZSBjb250ZXh0 IG9mDQo+QlBHLWJhc2VkIFZQTnMsIGJ1dCwgdW5sZXNzIGl0IGlzIGFsc28gd2lkZWx5IHVzZWQg Zm9yIG5vbi1WUE4gdXNlDQo+Y2FzZXMsIEkgd291bGQgdGhpbmsgdGhhdCBkZWZpbmluZyB0aGVz ZSB0ZXJtcyB3b3VsZCBtYWtlIHNlbnNlIChJIGRvbid0DQo+a25vdyB0aGVzZSB0ZXJtcyB0byBi ZSB3aWRlbHkgdXNlZCBvdXRzaWRlIFZQTiB1c2UgY2FzZXMsIGJ1dCB3ZWxsLCB0aGV5DQo+bWln aHQgYmUgaW4gd2hpY2ggY2FzZSBub3RoaW5nIGlzIG5lZWRlZCkNCldHXSBJIGNhbiBjZXJ0YWlu bHkgZXhwbG9kZSB0aGUgYWNyb255bSBvbiBmaXJzdCB1c2UgKGluIHNlY3Rpb24gMikgYnV0DQp0 aGUgdXNlIG9mIHRob3NlIHRlcm1zIGlzbid0IGludGVuZGVkIHRvIGludm9rZSBhbnkgc3BlY2lh bCBWUE4gZnVuY3Rpb25zLA0KbWVyZWx5IHRvIHJlcHJlc2VudCB0aGUgZGlmZmVyZW5jZSBiZXR3 ZWVuIHRoZSBwcm92aWRlcidzIHJvdXRlciAoUHJvdmlkZXINCkVkZ2UpIGFuZCB0aGUgY3VzdG9t ZXIncyAoQ3VzdG9tZXIgRWRnZSkuIElzIHRoZXJlIGFuIGFsdGVybmF0ZSBzZXQgb2YNCnRlcm1z IHRoYXQgd291bGQgYmUgbW9yZSBhcHByb3ByaWF0ZT8NCg0KPg0KPkopIHRoZSBsYXN0IMKnIG9m IHNlY3Rpb24gMy4xIGxvb2tzIHRvIG1lIGFzIHZlcnkgbXVjaCByZWR1bmRhbnQgdG8gd2hhdA0K PmlzIHNhaWQgaW4gdGhlIHJlc3Qgb2YgdGhlIHNlY3Rpb24NCldHXSBJIGNvbnNpZGVyIHRoaXMg KCJBcyBhIHJlc3VsdC4uLiIpIHBhcnQgb2YgdGhlIGV4YW1wbGUgYW5kIHRleHQNCnN1cHBvcnRp bmcgdGhlIGZpZ3VyZSwgc28gSSB0aGluayBpdCBzaG91bGQgcHJvYmFibHkgc3RheSB0aGVyZS4g SSBkbyBzZWUNCnRoZSByZXBldGl0aW9uIHdpdGggdGhlIGVhcmxpZXIgcGFyYWdyYXBoIChiZWdp bm5pbmcgd2l0aCAiQXMgc3RhdGVkDQpwcmV2aW91c2x5Li4uIikgc28gSSB0aGluayBhY3R1YWxs eSBJIHNob3VsZCBwdWxsIHRoZSAiQXMgc3RhdGVkDQpwcmV2aW91c2x5IiBwYXJhZ3JhcGggaW5z dGVhZC4gSSBnb3Qgc29tZSBvZmZsaW5lIGZlZWRiYWNrIHRoYXQgdGhpcyBkcmFmdA0KaXMgd29y ZHksIHNvIEkgd2lsbCB0cnkgdG8gbWFrZSBhbiBlZGl0aW5nIHBhc3Mgd2l0aCB0aGlzIGluIG1p bmQgb25jZQ0KSSd2ZSBpbmNvcnBvcmF0ZWQgdGhlIG90aGVyIGZlZWRiYWNrLg0KDQo+DQo+Sykg c2VjdGlvbiA0LjEgICJOQjogQ2lzY28gZG9lc24ndCBoYXZlIGFuIGV4YWN0IGVxdWl2YWxlbnQg dG8gIkludGVybmFsDQo+QkdQIEFsaWFzIiwgYnV0IHRoZSBjb21iaW5hdGlvbiBvZiB0aGUgQ2lz Y28gZmVhdHVyZXMgaUJHUCBsb2NhbC1BUyBhbmQNCj5kdWFsLWFzIHByb3ZpZGVzIHNpbWlsYXIg ZnVuY3Rpb25hbGl0eS4iICAtLSBUaGlzIHNlbnRlbmNlIHdvdWxkIGJlDQo+YmV0dGVyLXBsYWNl ZCBpbiBzZWN0aW9uIDEwLCBJTU8uDQpXR10gdGhpcyBpcyBjYWxsZWQgb3V0IGhlcmUgZm9yIGNs YXJpZmljYXRpb24gYmVjYXVzZSBpbiBtYW55IG9mIHRoZQ0KZXhhbXBsZXMsIGNpc2NvIHRlcm1p bm9sb2d5IGFuZCBDTEkgYXJlIHVzZWQsIGJ1dCBjb3VsZCBub3QgYmUgdXNlZCBoZXJlLg0KDQo+ DQo+TCkgc2VjdGlvbiA0LjEsIGl0ZW1pemVkIGxpc3QsIGl0ZW0gNDogYSByZWZlcmVuY2UgdG8g c2VjdGlvbiAzIHdvdWxkIGJlDQo+bmljZQ0KV0ddIGFjaw0KPg0KPk0pIHNlY3Rpb24gMTA6IGl0 IHdvdWxkIGJlIGludGVyZXN0aW5nIHRvIGluZGljYXRlLCBmb3IgZWFjaCB2ZW5kb3IsDQo+d2hh dCBhcmUgdGhlIGZlYXR1cmUgbmFtZXMgY29ycmVzcG9uZGluZyB0byB3aGF0IGlzIGRlc2NyaWJl ZCBpbg0KPnNlY3Rpb25zIDMuMSwgMy4yIGFuZCA0DQpXR10gaW50ZXJlc3RpbmcgcGVyaGFwcywg YnV0IHVubGVzcyB0aGUgV0cgcmVhbGx5IGJlbGlldmVzIGl0J3MgbmVjZXNzYXJ5LA0KSSBkb24n dCB0aGluayB0aGF0J3Mgc29tZXRoaW5nIEkgd2FudCB0byB1bmRlcnRha2UgaGVyZSwgc2luY2Ug SU1PIGl0IGFkZHMNCmxpdHRsZSB0byB0aGUgb2JqZWN0aXZlIG9mIHRoZSBkcmFmdCAoZG9jdW1l bnRpbmcgdGhlIGZlYXR1cmUgc28gdGhhdCBpdA0KY291bGQgYmUgaW1wbGVtZW50ZWQgYnkgc29t ZW9uZSB0aGF0IGRvZXNuJ3QgaGF2ZSBhbiBpbXBsZW1lbnRhdGlvbg0KYWxyZWFkeSwgYW5kIGZv cm1hbGl6aW5nIGl0IGFzIGEgcGFydCBvZiBCR1Agc28gdGhlIGZlYXR1cmUgZG9lc24ndCBnZXQN CmJyb2tlbiBieSBmdXR1cmUgY2hhbmdlcyB0byBCR1ApLiBUaGUgdmVuZG9ycyBhcmUgb2YgY291 cnNlIGZyZWUgdG8gZWl0aGVyDQp3cml0ZSB0aGVpciBvd24gZG9jdW1lbnRhdGlvbiBtYXBwaW5n IHRoaW5ncyB0byB0aGlzIGRvY3VtZW50LCBvciB0bw0KcHJvdmlkZSB0ZXh0IGZvciBtZSB0byBh ZGQgaGVyZSA7LSkNCg0KPg0KPipOaXRzOioNCj4NCj4tIEluIHRoZSBhYnN0cmFjdDogcy9mZWF1 cmVzL2ZlYXR1cmVzLw0KPi0gSW4gdGhlIGFic3RyYWN0OiB0aGUgdGl0bGUgd291bGQgYmUgbW9y ZSByZWFkYWJsZSB3aXRob3V0ICIoQVMpIjsNCj5pbnRyb2R1Y2luZyB0aGlzIGFjcm9ueW0sIGFs b25nIHdpdGggIkFTTiIgY2FuIGJlIGRvbmUgZm9yIGluc3RhbmNlIGluDQo+dGhlIGludHJvZHVj dGlvbg0KPi0gaW4gMy4xOiAgIklTUCBCIG5lZWRzIHRvIGRvIHRoaXMgd2l0aG91dCBjb29yZGlu YXRpbmcgdGhlIGNoYW5nZSBvZg0KPml0cyBBU04gd2l0aCBhbGwgb2YgaXRzIGVCR1AgcGVlcnMs IHNpbXVsdGFuZW91c2x5LiIgIGlzIG5vdCB2ZXJ5IGVhc3kNCj50byByZWFkIChtYXliZSAiSVNQ IEIgbmVlZHMgdG8gYmUgYWJsZSB0byBkbyB0aGlzIHdpdGhvdXQgY29vcmRpbmF0aW5nIGENCj5z aW11bHRhbmVvdXMgY2hhbmdlLi4uIHBlZXJzIiB3b3VsZCBiZSBiZXR0ZXI/KQ0KPi0gaW4gMy4x OiAiV2l0aGluIHRoZSBjb250ZXh0IG9mIElTUCBCJ3MgUEUgcm91dGVyLCBUaGUgc2Vjb25kIGVm ZmVjdA0KPi4uLiIgIC0+IHMvVGhlL3RoZS8NCldHXSBhY2sNCg0KDQoNClRoYW5rcywNCg0KV2Vz IEdlb3JnZQ0KDQpBbnl0aGluZyBiZWxvdyB0aGlzIGxpbmUgaGFzIGJlZW4gYWRkZWQgYnkgbXkg Y29tcGFueeKAmXMgbWFpbCBzZXJ2ZXIsIEkNCmhhdmUgbm8gY29udHJvbCBvdmVyIGl0Lg0KLS0t LS0tLS0tLS0NCg0KDQpUaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0cyBhdHRhY2htZW50cyBtYXkg Y29udGFpbiBUaW1lIFdhcm5lciBDYWJsZSBwcm9wcmlldGFyeSBpbmZvcm1hdGlvbiwgd2hpY2gg aXMgcHJpdmlsZWdlZCwgY29uZmlkZW50aWFsLCBvciBzdWJqZWN0IHRvIGNvcHlyaWdodCBiZWxv bmdpbmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1tYWlsIGlzIGludGVuZGVkIHNvbGVs eSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hpY2ggaXQgaXMg YWRkcmVzc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IG9mIHRoaXMg RS1tYWlsLCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0aW9uLCBk aXN0cmlidXRpb24sIGNvcHlpbmcsIG9yIGFjdGlvbiB0YWtlbiBpbiByZWxhdGlvbiB0byB0aGUg Y29udGVudHMgb2YgYW5kIGF0dGFjaG1lbnRzIHRvIHRoaXMgRS1tYWlsIGlzIHN0cmljdGx5IHBy b2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBF LW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQg cGVybWFuZW50bHkgZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYW55IGNvcHkgb2YgdGhpcyBFLW1h aWwgYW5kIGFueSBwcmludG91dC4NCg== From nobody Tue Sep 16 02:13:25 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90CE91A048D; Tue, 16 Sep 2014 02:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q8ZDhw966ugM; Tue, 16 Sep 2014 02:13:20 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A3801A0484; Tue, 16 Sep 2014 02:12:54 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id x13so5086583wgg.11 for ; Tue, 16 Sep 2014 02:12:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=drOcZLKsdZGztCTXrYagsSJLu8uFB8S4vk3/8vwwnqY=; b=lceTGj74a5413GKoc44jXUclKY1K6ir28TE6jDttUKDEfMv8z21LcN0Flzhc/w1RQb szhY9zikPyc8gxoKhPRA80iSCooYHn4+9EbZP6T4RG0/DdHtdDH4ki9aD6vkCYmqrxrH dJyPcM/TJ/wqXn6DNzBxPII0FbTnhwUGfV6DTmQ9D9Qf902EdQA9Y/qrPK3E3gA676Qx PbJY4jv9YVcb6D5XwCUOAc3zaglJehuq74hNABEDxPEbxE9rDn6w2MEPT7PmAbAcj2Gl /3HCGglM/YlT9UHXFgTxPTWfs9KUS7/PZpHwpcKZ1QR8Nm65g3p0krRj3C5Aim90zuc9 f0wg== X-Received: by 10.194.122.6 with SMTP id lo6mr40893419wjb.17.1410858771832; Tue, 16 Sep 2014 02:12:51 -0700 (PDT) Received: from [127.0.0.1] (ARennes-652-1-59-226.w2-11.abo.wanadoo.fr. [2.11.58.226]) by mx.google.com with ESMTPSA id lq8sm17628480wjb.49.2014.09.16.02.12.50 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Sep 2014 02:12:51 -0700 (PDT) Sender: Thomas Morin Message-ID: <5417FF0F.9040506@orange.com> Date: Tue, 16 Sep 2014 11:12:47 +0200 From: Thomas Morin Organization: Orange User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: "George, Wes" , "idr@ietf.org" , "rtg-ads@tools.ietf.org" References: <5412BF1F.7030206@orange.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/idr/XqW4INnpFDAKzqoYydEhHZmAvMY Cc: "rtg-dir@ietf.org" , "draft-ietf-idr-as-migration.all@tools.ietf.org" Subject: Re: [Idr] RtgDir review: draft-ietf-idr-as-migration-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 09:13:22 -0000 Hi George, 2014-09-15, George, Wes: > Thanks for the thorough review. My responses below inline. Comments below. (skipping stuff that is ok already) > On 9/12/14, 5:38 AM, "Thomas Morin" wrote: >> A) The introduction says: >> >> In particular >> the ISP would have to encourage those customers to change their CE >> router configs to use the new ASN in a very short period of time, >> when the customer has no business incentive to do so. Thus, it >> becomes critical to allow the ISP to make this process a bit more >> asymmetric, so that it could seamlessly migrate the ASN within its >> network(s), but not disturb existing customers, and allow the >> customers to gradually migrate to the ISP's new ASN at their leisure. >> >> However, I did not understand which part of the specs would allow the >> customer to change its CE >> configuration without coordinating a maintenance window with the ISP. > > WG] well, that is not exactly what the above says. The idea was to make a > distinction between a globally coordinated window between all customers on > the router (symmetric change) vs being able to coordinate individually > (asymmetric). I do see your point though, and I can make it more explicit. > >> Procedures in section 3, as described, won't let the customer CE >> connect to the router with the new ASN. See, in particular in the second >> § of section 3.3: "The speaker MUST NOT use the ASN configured globally >> within the BGP process as the value sent in MY ASN in the OPEN message. >> ". It seems that the goal specified in the intro will thus not be met >> fully. >> >> Two things would be possible: fixing the intro to state a slightly >> different goal, or change the procedures to let a router establish a >> session with the globally assigned new AS, even when 'local-as old-AS" >> is configured. I'm not expert enough to know if the latter would work. > > WG] I'd refer you to section 4.2, which allows a more flexible > configuration that can establish a session using either old or new ASN. > While it's discussed in the iBGP section, the text does note that this > could be done whether in iBGP or eBGP. Well, referring me, in this email, to section 4.2 won't improve the document itself. :) This question of avoiding any coordinated maintenance window between two eBGP peers is I think important enough to deserve being explicitly addressed as a target in the intro, and with a solution mentioned in section 3 (which could say, at the right place: "At this step, to let CEs still configured with the legacy ASN establish sessions, the PE can be configured to enable the 'Internal BGP Alias' function described in section 4.2"). >> D) in section 3: " Thus, within Loc-RIB on ISP B' the AS_PATH toward >> customer C would appear as: 64510". I would have thought that the >> AS_PATH of routes learned by PE routers of ISP B in this situation (if >> local-as no-prepend is not used), would be "64496" or "64510 64496" >> rather than "64510" alone... but I could just be wrong. > > WG] This is describing the AS_PATH pre-migration, and then showing what > happens during migration. I think I can clarify. (Note that given the position in the text, the context of this quoted does *not* seem to be pre-migration, but rather during migration.) >> G) the naming given to ASs and routers along the document**could I think >> be largely improved to make the document easier to read. I would suggest >> the following: >> * In the figures 3 and 4 of section 3.1 and 3.2: invert the figure >> left-right to have AS64499 on the left like in figures 1 and 2 > > WG] I understand the parallelism/symmetry that you're suggesting, but > flipping the ASNs would require rewriting a substantial amount of the > example. I think you're suggesting mirror image, which would leave the > example text unchanged, but assumes that everyone is ok with the arrows > pointing right to left in fig 3, and then left to right in fig 4, as well > as PE2/CE2 showing on the left, PE1/CE1 on the right in both, which is > sort of backward from western convention and confusing for a different > reason. I think I'm going to offend a different set of aesthetics with > either one, and I'm not sure it makes a great deal of difference in the > readability of the figures. Open for further discussion. If I may insist: having left and right inverted between fig 1/2 and fig 3/4 is (a) really confusing at first, (b) independent of any left-to-right convention, and (c) bogus for every reasonable sense of aesthetics. Inverting left-to-right in fig.1 and fig.2 would just consist in changing 8 chars total, and would fix that. (changing the direction of arrows in 3.1 and 3.2 would be IMHO an acceptable alternative: I don't think there's anything backward wrt. to any western convention in that) >> * In the figures 3 and 4 of section 3.1 and 3.2, and associated text: >> instead of naming the PEs and CEs with 1 and 2, name them with A and B >> to match the ISP they are into (PE-A,CE-A,PE-B,CE-B instead of >> PE-2,CE-2,PE-1,CE-1) >> * modify figures 1 and 2 to make PE-A,CE-A,PE-B,CE-B appear on the figures > > WG] I don't think that this would be helpful since you're not consistently > dealing with ISP A or B during the migration, but rather A', which is an > amalgam of all of ISP A and the part of ISP B that has been subsumed by > ISP A. I think using A or B would confuse things, since in post-migration > what you end up with is 2 PEs in the same ISP. Having to refer to the figure, while reading the text, to find out which of PE1/PE2 was in ISP B/ISP A was a significant overhead for me. If it is written clearly that PE-A/PE-B are respectively PEs that were before migration in ISP A/ISP-B, I think the confusion with respect to the ISP A' notation will go away. >> * preferring "ISP A PE routers" to "ISP A's PE routers" to increase >> readability, or just "PE-A" or "PE-B" which is even shorter and less >> confusing (as an illustration section 3.2 says "Specifically, with >> 'Local AS No Prepend' enabled on ISP A's PE-1, it automatically >> causes..." , but does it mean "ISP A PE-1" or "ISP A' PE-1"...? given >> that PE-1 is actually in ISP B (==ISP A'), this is probably the second >> which is true, but here incorrectly written as "ISP A's PE-1"...) > > WG] good point. I'll make a pass through to eliminate the use of > possessive (A's) when I'm also talking about ISP A prime (A') to reduce > the confusion. I think you should remove the possessive "'s" in all occurrences . >> I) I know the 'PE'/'CE' terminology to be widely used in the context of >> BPG-based VPNs, but, unless it is also widely used for non-VPN use >> cases, I would think that defining these terms would make sense (I don't >> know these terms to be widely used outside VPN use cases, but well, they >> might be in which case nothing is needed) > > WG] I can certainly explode the acronym on first use (in section 2) but > the use of those terms isn't intended to invoke any special VPN functions, > merely to represent the difference between the provider's router (Provider > Edge) and the customer's (Customer Edge). Is there an alternate set of > terms that would be more appropriate? I guess the right term would be ASBR, but that is symmetric, and not a helpful terminology for your examples. Expanding on first use, and explaining that you re-use terminology from RFC4364 by convenience would I think be good enough. >> J) the last § of section 3.1 looks to me as very much redundant to what >> is said in the rest of the section > > WG] I consider this ("As a result...") part of the example and text > supporting the figure, so I think it should probably stay there. I do see > the repetition with the earlier paragraph (beginning with "As stated > previously...") so I think actually I should pull the "As stated > previously" paragraph instead. I got some offline feedback that this draft > is wordy, so I will try to make an editing pass with this in mind once > I've incorporated the other feedback. Yes, these sections are very wordy; the document will be better if you can avoid repeats. >> K) section 4.1 "NB: Cisco doesn't have an exact equivalent to "Internal >> BGP Alias", but the combination of the Cisco features iBGP local-AS and >> dual-as provides similar functionality." -- This sentence would be >> better-placed in section 10, IMO. > > WG] this is called out here for clarification because in many of the > examples, cisco terminology and CLI are used, but could not be used here. If I read correctly, section 3 uses a Cisco feature name "local-as" and section 4 a Juniper feature name. However, Section 2 says "The examples cited below use Cisco IOS CLI for ease of illustration purposes only.". You could sort this out by saying, section 2 "The examples cited below use specfic vendors CLI feature names for ease of illustration purposes only (Cisco IOS in Section 3, Juniper JunOS in Section 4)". And then move the "NB" note in section 10... ? >> M) section 10: it would be interesting to indicate, for each vendor, >> what are the feature names corresponding to what is described in >> sections 3.1, 3.2 and 4 > WG] interesting perhaps, but unless the WG really believes it's necessary, > I don't think that's something I want to undertake here, since IMO it adds > little to the objective of the draft (documenting the feature so that it > could be implemented by someone that doesn't have an implementation > already, and formalizing it as a part of BGP so the feature doesn't get > broken by future changes to BGP). The vendors are of course free to either > write their own documentation mapping things to this document, or to > provide text for me to add here ;-) Ok, fair enough. -Thomas From nobody Tue Sep 16 10:28:04 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E237E1A8844; Tue, 16 Sep 2014 10:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wgtutFGjKzS5; Tue, 16 Sep 2014 10:28:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 287FF1A6FD5; Tue, 16 Sep 2014 10:27:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140916172759.13163.78515.idtracker@ietfa.amsl.com> Date: Tue, 16 Sep 2014 10:27:59 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/61YAOXGoF94jWGHq6-e6jJWGWq4 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-ls-distribution-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 17:28:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : North-Bound Distribution of Link-State and TE Information using BGP Authors : Hannes Gredler Jan Medved Stefano Previdi Adrian Farrel Saikat Ray Filename : draft-ietf-idr-ls-distribution-06.txt Pages : 44 Date : 2014-09-16 Abstract: In a number of environments, a component external to a network is called upon to perform computations based on the network topology and current state of the connections within the network, including traffic engineering information. This is information typically distributed by IGP routing protocols within the network. This document describes a mechanism by which links state and traffic engineering information can be collected from networks and shared with external components using the BGP routing protocol. This is achieved using a new BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism is applicable to physical and virtual IGP links. The mechanism described is subject to policy control. Applications of this technique include Application Layer Traffic Optimization (ALTO) servers, and Path Computation Elements (PCEs). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-ls-distribution-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-ls-distribution-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Sep 16 11:50:09 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 697E91A6EFF; Tue, 16 Sep 2014 11:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3kTFJ_t57eC; Tue, 16 Sep 2014 11:50:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A85341A6F28; Tue, 16 Sep 2014 11:50:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140916185001.5982.49790.idtracker@ietfa.amsl.com> Date: Tue, 16 Sep 2014 11:50:01 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/vQGTAS9-0VD1sHuRGcABm0CImbM Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-ls-distribution-impl-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 18:50:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : BGP Link-State Information Distribution Implementation Report Authors : Hannes Gredler Balaji Rajagopalan Chris Bowers Saikat Ray Manish Bhardwaj Filename : draft-ietf-idr-ls-distribution-impl-01.txt Pages : 12 Date : 2014-09-16 Abstract: This document is an implementation report for the BGP Link-State Information Distribution protocol as defined in [I-D.ietf-idr-ls-distribution]. The editors did not verify the accuracy of the information provided by respondents. The respondents are experts with the implementations they reported on, and their responses are considered authoritative for the implementations for which their responses represent. Respondents were asked to only use the YES answer if the feature had at least been tested in the lab. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution-impl/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-ls-distribution-impl-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-ls-distribution-impl-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Sep 19 01:17:15 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D48FC1A0016 for ; Fri, 19 Sep 2014 01:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.097 X-Spam-Level: X-Spam-Status: No, score=0.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iiu-As92grVx for ; Fri, 19 Sep 2014 01:17:04 -0700 (PDT) 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 23A081A0015 for ; Fri, 19 Sep 2014 01:17:04 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BMT90126; Fri, 19 Sep 2014 08:17:02 +0000 (GMT) Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 19 Sep 2014 09:17:02 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.21]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Fri, 19 Sep 2014 16:16:51 +0800 From: Haoweiguo To: "idr@ietf.org" Thread-Topic: New Version Notification for draft-hao-idr-flowspec-evpn-01.txt Thread-Index: AQHP09+DwnlTV8t4Zk+iAS4SRMRiYJwIF3vR Date: Fri, 19 Sep 2014 08:16:51 +0000 Message-ID: References: <20140919075823.17163.36114.idtracker@ietfa.amsl.com> In-Reply-To: <20140919075823.17163.36114.idtracker@ietfa.amsl.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.23.94] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/idr/d9L6b2aiNJDJ73oKqb0jmqlBvmM Cc: liuweihang Subject: [Idr] =?gb2312?b?tPC4tDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBk?= =?gb2312?b?cmFmdC1oYW8taWRyLWZsb3dzcGVjLWV2cG4tMDEudHh0?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 08:17:07 -0000 SGkgQWxsLA0KQmFzZWQgb24gdGhlIHByZXZpb3VzIGNvbW1lbnRzIGFuZCBzdWdnZXN0aW9ucyBm cm9tIGluZHVzdHJpYWwgZXhwZXJ0cywgd2UgaGF2ZSB1cGRhdGVkIHRoZSBkcmFmdC4gIE1haW5s eSBjaGFuZ2VzIGluY2x1ZGU6DQoxLiBFdGhlcm5ldCBmbG93LXNwZWMgc2hvdWxkbid0IGJlIHJl c3RyaWN0ZWQgdG8gRVZQTiBvbmx5IG5ldHdvcmssIGl0IGNhbiBiZSBhcHBsaWVkIHRvIGFsbCBr aW5kcyBvZiBMMlZQTiBuZXR3b3JrLiANCjIuIE5ldyBhZGRlZCBjby1hdXRob3JzOiBKYW1lcyBV dHRhcm8gYW5kIFN0ZXBoYW5lIExpdGtvd3NraS4NCkFueSBmdXJ0aGVyIGNvbW1lbnRzIGFuZCBz dWdnZXN0aW9ucyBhcmUgYXBwcmVjaWF0ZWQuDQpUaGFua3MNCndlaWd1bw0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6IGludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZyBbaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0Kt6LLzcqxvOQ6IDIwMTTE6jnUwjE5 yNUgMTU6NTgNCsrVvP7IyzogbGl1d2VpaGFuZzsgSGFvd2VpZ3VvOyBaaHVhbmdzaHVud2FuOyBT dGVwaGFuZSBMaXRrb3dza2k7IFpodWFuZ3NodW53YW47IGxpdXdlaWhhbmc7IFN0ZXBoYW5lIExp dGtvd3NraTsgSGFvd2VpZ3VvDQrW98ziOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRy YWZ0LWhhby1pZHItZmxvd3NwZWMtZXZwbi0wMS50eHQNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQs IGRyYWZ0LWhhby1pZHItZmxvd3NwZWMtZXZwbi0wMS50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxs eSBzdWJtaXR0ZWQgYnkgV2VpZ3VvIEhhbyBhbmQgcG9zdGVkIHRvIHRoZQ0KSUVURiByZXBvc2l0 b3J5Lg0KDQpOYW1lOiAgICAgICAgICAgZHJhZnQtaGFvLWlkci1mbG93c3BlYy1ldnBuDQpSZXZp c2lvbjogICAgICAgMDENClRpdGxlOiAgICAgICAgICBEaXNzZW1pbmF0aW9uIG9mIEZsb3cgU3Bl Y2lmaWNhdGlvbiBSdWxlcyBmb3IgTDIgVlBODQpEb2N1bWVudCBkYXRlOiAgMjAxNC0wOS0xOQ0K R3JvdXA6ICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6ICAgICAgICAgIDgN ClVSTDogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFm dC1oYW8taWRyLWZsb3dzcGVjLWV2cG4tMDEudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaGFvLWlkci1mbG93c3BlYy1ldnBuLw0KSHRt bGl6ZWQ6ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWhhby1pZHItZmxv d3NwZWMtZXZwbi0wMQ0KRGlmZjogICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlm Zj91cmwyPWRyYWZ0LWhhby1pZHItZmxvd3NwZWMtZXZwbi0wMQ0KDQpBYnN0cmFjdDoNCiAgIFRo aXMgZG9jdW1lbnQgZGVmaW5lcyBCR1AgZmxvdy1zcGVjIGV4dGVuc2lvbiBmb3IgRXRoZXJuZXQg dHJhZmZpYw0KICAgZmlsdGVyaW5nIGluIEwyIFZQTiBuZXR3b3JrLiBBIG5ldyBCR1AgTkxSSSB0 eXBlIChBRkk9MjUsIFNBRkk9VEJEKQ0KICAgdmFsdWUgaXMgcHJvcG9zZWQgdG8gaWRlbnRpZnkg TDIgVlBOIGZsb3ctc3BlYyBhcHBsaWNhdGlvbi4gQSBuZXcNCiAgIHN1YnNldCBvZiBjb21wb25l bnQgdHlwZXMgYW5kIGV4dGVuZGVkIGNvbW11bml0eSBhbHNvIGFyZSBkZWZpbmVkLg0KDQoNCg0K DQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0 aGUgdGltZSBvZiBzdWJtaXNzaW9uDQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlm ZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlh dA== From nobody Fri Sep 19 15:33:52 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 904EB1A88EA; Fri, 19 Sep 2014 15:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wu03P7TqL6p0; Fri, 19 Sep 2014 15:33:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 836FA1A6F2C; Fri, 19 Sep 2014 15:33:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: keyupate@cisco.com,enkechen@cisco.com,balaji_pv@hotmail.com X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140919223349.27277.50465.idtracker@ietfa.amsl.com> Date: Fri, 19 Sep 2014 15:33:49 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/AuM9BslKmXpu8ZmmWpAth-HiBz4 Cc: idr@ietf.org, shares@ndzh.com, ipr-announce@ietf.org Subject: [Idr] IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to RFC 7313 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 22:33:50 -0000 Dear Keyur Patel, Enke Chen, Balaji Venkatachalapathy: An IPR disclosure that pertains to your RFC entitled "Enhanced Route Refresh Capability for BGP-4" (RFC7313) was submitted to the IETF Secretariat on 2014-09-19 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2437/). The title of the IPR disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR related to RFC 7313.""); The IETF Secretariat From nobody Mon Sep 22 00:19:55 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 840FE1A1A42; Mon, 22 Sep 2014 00:19:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.833 X-Spam-Level: X-Spam-Status: No, score=-2.833 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_BELOW2=2.154, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DMydZZtYJIqN; Mon, 22 Sep 2014 00:19:47 -0700 (PDT) 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 04C481A1A40; Mon, 22 Sep 2014 00:19:46 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJR91121; Mon, 22 Sep 2014 07:19:45 +0000 (GMT) Received: from SZXEMA403-HUB.china.huawei.com (10.82.72.35) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 22 Sep 2014 08:19:43 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.131]) by SZXEMA403-HUB.china.huawei.com ([10.82.72.35]) with mapi id 14.03.0158.001; Mon, 22 Sep 2014 15:19:40 +0800 From: Mach Chen To: "idr@ietf.org" , "draft-ietf-idr-bgp-gr-notification@tools.ietf.org" Thread-Topic: RtgDir QA review on draft-ietf-idr-bgp-gr-notification-03 Thread-Index: Ac/WNY9hijUo731zTvqx4ERfOezi8Q== Date: Mon, 22 Sep 2014 07:19:39 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/idr/_rTf5Ir7VEeHVhyf_lQ0oIP3lJ4 Cc: "rtg-dir@ietf.org" , "rtg-ads@tools.ietf.org" Subject: [Idr] RtgDir QA review on draft-ietf-idr-bgp-gr-notification-03 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 07:19:50 -0000 Hi Authors, I was assigned to do a QA review on draft-ietf-idr-bgp-gr-notification-03. = For more detail what's is RtgDir QA review, please refer to https://trac.to= ols.ietf.org/area/rtg/trac/wiki/RtgDirDocQa=20 Overall, the document is well-written and clear, after review, I have the f= ollowing comments.=20 1. Abstract s/BGP NOTIFICATION Message/ BGP NOTIFICATION message; 2. Section 2: " Flags for Address Family: This field contains bit flags relating to routes that were advertised with the given AFI and SAFI. 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |F|N| Reserved | +-+-+-+-+-+-+-+-+ The usage of second most significant bit "N" is deprecated. This bit MUST be advertised as 0 and MUST be ignored upon receipt. " The "N" bit was firstly introduced in a previous version of this document, = but deprecated in later version. I don't understand why a document need dep= recate a functionality introduced by itself, why not just remove it? In addition, since there is no changes to the AF related flags, the last se= ntence of the first paragraph of section 2 should be changed as bellow: OLD: "the Restart flags field and the Flags field for Address Family are augment= ed as follows:" New: "the Restart flags field are augmented as follows:" 3. Section 3.1 "Subcode is a BGP Error Subcode (as documented in the IANA BGP Error Subcodes registry) as appropriate for the ErrCode. Similarly, Data is as appropriate for the ErrCode and Subcode." This is just an introduction to the Subcode itself, it's better to explicit= ly state that the subcode should be set to the Hard Reset (9). 4. Section 4 "Once the session is re-established, both BGP speakers SHOULD set their "Forwarding State" bit to 1." Here it implies that the speakers are required to set the "Forwarding State= " no matter what the speakers have the ability to preserve the forwarding s= tate. Is it the intention? =20 I guess it's not, if so, some text may needed to clarify this. 5. I run idnits tool and found the following nits: =3D=3D Unused Reference: 'RFC3392' is defined on line 269, but no explicit = reference was found in the text. Best regards, Mach From nobody Thu Sep 25 11:39:41 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA7F1A86F9; Thu, 25 Sep 2014 09:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uHNcM-B479z2; Thu, 25 Sep 2014 09:40:03 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6A511A86E9; Thu, 25 Sep 2014 09:40:02 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s8PGe0cg004315; Thu, 25 Sep 2014 17:40:00 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s8PGdwgo004304 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 25 Sep 2014 17:39:59 +0100 From: "Adrian Farrel" To: Date: Thu, 25 Sep 2014 17:39:55 +0100 Message-ID: <026001cfd8df$571fc440$055f4cc0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac/Y31PDbwg0+jQHTsCj10YZo9E84A== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-20976.000 X-TM-AS-Result: No--8.038-10.0-31-10 X-imss-scan-details: No--8.038-10.0-31-10 X-TMASE-MatchedRID: Pg8dl0A/1xTDkHnJwIRKW5mug812qIbzH181YDtIVaoifM7JMNHW63w9 3dJCnn/Pj7t4VaG2jYxZKgjvZO8woTZQQocM3TDMQVWLLVSdiGsZYA38gj3BxMKQkd8YrGEvUpN 5b4Xd/F3ofwk6BENqtzIO2PPoSTg7AMFp5W5WHQKeAiCmPx4NwLTrdaH1ZWqCmBlD3TjdXl76C0 ePs7A07Y6HM5rqDwqtuo5OMxWPiCb6SDeK1T+MjqUUhjuyPfy3/UDb+ZigOvEGwS4YI+T41w== Archived-At: http://mailarchive.ietf.org/arch/msg/idr/tmyzBojn3zLEWh_gqVxqQGhjCuw X-Mailman-Approved-At: Thu, 25 Sep 2014 11:39:39 -0700 Subject: [Idr] Proposal for a charter for BESS X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 16:40:04 -0000 Hi, L3VPN, L2VPN, IDR, MPLS, NVO3, and PWE3 are all Bcc'd. Please send your responses on the routing-discussion list. We have been working on a draft charter for the "BGP Enabled Services" working group (BESS) that will take over the BGP VPN work from L3VPN, L2VPN, and NVO3. You can see the working copy of this charter at https://datatracker.ietf.org/doc/charter-ietf-bess/ We will need to make specific decisions about which documents go where, but that will (hopefully) not change the discussion of the charter text. To move this forward, the IESG will consider this on 2nd October with a view to sending it out for formal IETF review. So your review comments now would be really helpful. Thanks, Adrian From nobody Fri Sep 26 14:25:36 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A71191A037E; Fri, 26 Sep 2014 14:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9TMwEO-tLzAV; Fri, 26 Sep 2014 14:19:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B8E6A1A0359; Fri, 26 Sep 2014 14:19:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: svshah@cisco.com, keyupate@cisco.com, sbajaj@juniper.net, luis.tomotaki@verizon.com, mohamed.boucadair@orange.com X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140926211949.18797.28246.idtracker@ietfa.amsl.com> Date: Fri, 26 Sep 2014 14:19:49 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/rPvMVsFcM4xOm1Vz_HNdAM3P250 X-Mailman-Approved-At: Fri, 26 Sep 2014 14:25:30 -0700 Cc: idr@ietf.org, shares@ndzh.com, ipr-announce@ietf.org Subject: [Idr] IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-idr-sla-exchange-03 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Sep 2014 21:19:54 -0000 Dear Shitanshu Shah, Keyur Patel, Sandeep Bajaj, Luis Tomotaki, Mohamed Boucadair: An IPR disclosure that pertains to your Internet-Draft entitled "Inter-domain SLA Exchange" (draft-ietf-idr-sla-exchange) was submitted to the IETF Secretariat on 2014-09-26 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2443/). The title of the IPR disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-idr-sla-exchange-03.""); The IETF Secretariat From nobody Mon Sep 29 06:37:25 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B062C1A1A6E; Mon, 29 Sep 2014 06:37:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mHwMjTAmcPPR; Mon, 29 Sep 2014 06:37:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 74FF41A6FAE; Mon, 29 Sep 2014 06:37:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140929133712.4521.79551.idtracker@ietfa.amsl.com> Date: Mon, 29 Sep 2014 06:37:12 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/NkSlQ4x1zq5K0jDu_TkMeAOt46o Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-as-migration-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 13:37:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Autonomous System Migration Features and Their Effects on the BGP AS_PATH Attribute Authors : Wesley George Shane Amante Filename : draft-ietf-idr-as-migration-03.txt Pages : 16 Date : 2014-09-29 Abstract: This draft discusses some BGP features for ASN migration that, while commonly used, are not formally part of the BGP4 protocol specification and may be vendor-specific in exact implementation. It is necessary to document these de facto standards to ensure that they are properly supported in future BGP protocol work such as BGPSec. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-as-migration/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-as-migration-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-as-migration-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Sep 29 06:44:02 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 085741A1AE2 for ; Mon, 29 Sep 2014 06:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.251 X-Spam-Level: X-Spam-Status: No, score=-1.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xp_ngY0vJncq for ; Mon, 29 Sep 2014 06:43:59 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 21E461A1A6E for ; Mon, 29 Sep 2014 06:43:58 -0700 (PDT) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.04,620,1406606400"; d="scan'208";a="530969867" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 29 Sep 2014 09:40:19 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.79]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Mon, 29 Sep 2014 09:43:58 -0400 From: "George, Wes" To: "idr@ietf.org" Date: Mon, 29 Sep 2014 09:44:30 -0400 Thread-Topic: [Idr] I-D Action: draft-ietf-idr-as-migration-03.txt Thread-Index: Ac/b62rxDJ1CPYU9SYS/ZVCXEGgTJw== Message-ID: References: <20140929133712.4521.79551.idtracker@ietfa.amsl.com> In-Reply-To: <20140929133712.4521.79551.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/gzbm5B0puE9yiFTTms0DHKBg-4c Subject: Re: [Idr] I-D Action: draft-ietf-idr-as-migration-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 13:44:01 -0000 SSBiZWxpZXZlIHRoYXQgdGhpcyB2ZXJzaW9uIHJlc29sdmVzIHRoZSBjb21tZW50cyByZWNlaXZl ZCBib3RoIG9uIGFuZCBvZmYNCmxpc3QgZHVyaW5nIFdHTEMuIEluIGFkZGl0aW9uIHRvIHRoZSB0 aGluZ3MgdGhhdCB0aGUgcm91dGluZyBkaXJlY3RvcmF0ZQ0KcmV2aWV3IGhpZ2hsaWdodGVkLCBJ IG1hZGUgYW4gZWRpdGluZyBwYXNzIGluIGFuIGF0dGVtcHQgdG8gY29uc29saWRhdGUNCmFuZCBz dHJlYW1saW5lIHRoZSB0ZXh0IGFuZCBlbGltaW5hdGUgc29tZSBvZiB0aGUgb3ZlcmxhcCBiZXR3 ZWVuDQpzZWN0aW9ucy4gSSB0aGluayBpdCdzIGluIGdvb2QgZW5vdWdoIGNvbmRpdGlvbiBub3cg Zm9yIElFVEYgTEMsIGJ1dCBhcw0KYWx3YXlzLCBJIHdlbGNvbWUgZmVlZGJhY2suDQoNClRoYW5r cywNCg0KV2VzDQoNCg0KT24gOS8yOS8xNCwgOTozNyBBTSwgImludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZyIgPGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4NCndyb3RlOg0KDQo+DQo+QSBOZXcgSW50 ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRz DQo+ZGlyZWN0b3JpZXMuDQo+IFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIEludGVy LURvbWFpbiBSb3V0aW5nIFdvcmtpbmcgR3JvdXAgb2YNCj50aGUgSUVURi4NCj4NCj4gICAgICAg IFRpdGxlICAgICAgICAgICA6IEF1dG9ub21vdXMgU3lzdGVtIE1pZ3JhdGlvbiBGZWF0dXJlcyBh bmQgVGhlaXINCj5FZmZlY3RzIG9uIHRoZSBCR1AgQVNfUEFUSCBBdHRyaWJ1dGUNCj4gICAgICAg IEF1dGhvcnMgICAgICAgICA6IFdlc2xleSBHZW9yZ2UNCj4gICAgICAgICAgICAgICAgICAgICAg ICAgIFNoYW5lIEFtYW50ZQ0KPiAgICAgICBGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLWlk ci1hcy1taWdyYXRpb24tMDMudHh0DQo+ICAgICAgIFBhZ2VzICAgICAgICAgICA6IDE2DQo+ICAg ICAgIERhdGUgICAgICAgICAgICA6IDIwMTQtMDktMjkNCj4NCj5BYnN0cmFjdDoNCj4gICBUaGlz IGRyYWZ0IGRpc2N1c3NlcyBzb21lIEJHUCBmZWF0dXJlcyBmb3IgQVNOIG1pZ3JhdGlvbiB0aGF0 LCB3aGlsZQ0KPiAgIGNvbW1vbmx5IHVzZWQsIGFyZSBub3QgZm9ybWFsbHkgcGFydCBvZiB0aGUg QkdQNCBwcm90b2NvbA0KPiAgIHNwZWNpZmljYXRpb24gYW5kIG1heSBiZSB2ZW5kb3Itc3BlY2lm aWMgaW4gZXhhY3QgaW1wbGVtZW50YXRpb24uICBJdA0KPiAgIGlzIG5lY2Vzc2FyeSB0byBkb2N1 bWVudCB0aGVzZSBkZSBmYWN0byBzdGFuZGFyZHMgdG8gZW5zdXJlIHRoYXQgdGhleQ0KPiAgIGFy ZSBwcm9wZXJseSBzdXBwb3J0ZWQgaW4gZnV0dXJlIEJHUCBwcm90b2NvbCB3b3JrIHN1Y2ggYXMg QkdQU2VjLg0KPg0KPg0KPlRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlz IGRyYWZ0IGlzOg0KPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYt aWRyLWFzLW1pZ3JhdGlvbi8NCj4NCj5UaGVyZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2 YWlsYWJsZSBhdDoNCj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWlkci1h cy1taWdyYXRpb24tMDMNCj4NCj5BIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBh dmFpbGFibGUgYXQ6DQo+aHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0 Zi1pZHItYXMtbWlncmF0aW9uLTAzDQo+DQo+DQo+UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFr ZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCj5zdWJtaXNzaW9uDQo+dW50 aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5p ZXRmLm9yZy4NCj4NCj5JbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255 bW91cyBGVFAgYXQ6DQo+ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4NCj5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPklkciBtYWls aW5nIGxpc3QNCj5JZHJAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2lkcg0KDQoNClRoaXMgRS1tYWlsIGFuZCBhbnkgb2YgaXRzIGF0dGFjaG1lbnRzIG1h eSBjb250YWluIFRpbWUgV2FybmVyIENhYmxlIHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uLCB3aGlj aCBpcyBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWwsIG9yIHN1YmplY3QgdG8gY29weXJpZ2h0IGJl bG9uZ2luZyB0byBUaW1lIFdhcm5lciBDYWJsZS4gVGhpcyBFLW1haWwgaXMgaW50ZW5kZWQgc29s ZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aGljaCBpdCBp cyBhZGRyZXNzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhp cyBFLW1haWwsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRpb24s IGRpc3RyaWJ1dGlvbiwgY29weWluZywgb3IgYWN0aW9uIHRha2VuIGluIHJlbGF0aW9uIHRvIHRo ZSBjb250ZW50cyBvZiBhbmQgYXR0YWNobWVudHMgdG8gdGhpcyBFLW1haWwgaXMgc3RyaWN0bHkg cHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlz IEUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFu ZCBwZXJtYW5lbnRseSBkZWxldGUgdGhlIG9yaWdpbmFsIGFuZCBhbnkgY29weSBvZiB0aGlzIEUt bWFpbCBhbmQgYW55IHByaW50b3V0Lg0K