From nobody Wed Apr 1 10:00:28 2015 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 75BF31A87C7; Wed, 1 Apr 2015 10:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KX8RcWioaR0C; Wed, 1 Apr 2015 10:00:23 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0761.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:761]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C23371A01E7; Wed, 1 Apr 2015 10:00:22 -0700 (PDT) Received: from BN1PR05MB535.namprd05.prod.outlook.com (10.141.65.155) by BN1PR05MB437.namprd05.prod.outlook.com (10.141.58.11) with Microsoft SMTP Server (TLS) id 15.1.118.21; Wed, 1 Apr 2015 17:00:16 +0000 Received: from BN1PR05MB535.namprd05.prod.outlook.com ([169.254.8.244]) by BN1PR05MB535.namprd05.prod.outlook.com ([169.254.8.244]) with mapi id 15.01.0118.022; Wed, 1 Apr 2015 17:00:16 +0000 From: Balaji Rajagopalan To: "ietf@ietf.org" , Hannes Gredler Thread-Topic: [Idr] REVISED Last Call: (North-Bound Distribution of Link-State and TE Information using BGP) to Proposed Standard Thread-Index: AQHQYbN1sBT99RQ7ME2g+UypTJek+p04078A Date: Wed, 1 Apr 2015 17:00:15 +0000 Message-ID: References: <20150318194048.32558.12168.idtracker@ietfa.amsl.com> In-Reply-To: <20150318194048.32558.12168.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.8.150116 x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [116.197.184.11] authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB437; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(377454003)(15975445007)(2950100001)(2900100001)(122556002)(50986999)(102836002)(106116001)(86362001)(54356999)(77156002)(87936001)(92566002)(19617315012)(450100001)(2501003)(99286002)(83506001)(19580395003)(230783001)(36756003)(46102003)(62966003)(76176999)(40100003)(16236675004)(19580405001)(2656002)(66066001)(24704002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB437; H:BN1PR05MB535.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:BN1PR05MB437; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB437; x-forefront-prvs: 053315510E Content-Type: multipart/alternative; boundary="_000_D141DAC412D74balajirjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Apr 2015 17:00:15.7024 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB437 Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] REVISED Last Call: (North-Bound Distribution of Link-State and TE Information using BGP) to Proposed Standard 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, 01 Apr 2015 17:00:26 -0000 --_000_D141DAC412D74balajirjunipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBzZWVrIGEgY29ycmVjdGlvbiB0byB0aGUgZm9sbG93aW5nIHRleHQgaW4gc2VjdGlvbiAzLjIu MS40Lg0KDQoiDQpJR1AgUm91dGVyIElEOiA8c25pcD4gRm9yIGFuIE9TUEZ2MiAiUHNldWRvbm9k ZSIgcmVwcmVzZW50aW5nIGEgTEFOLA0KDQogICAgICB0aGlzIGNvbnRhaW5zIHRoZSA0IG9jdGV0 IFJvdXRlci1JRCBvZiB0aGUgZGVzaWduYXRlZCByb3V0ZXIgKERSKQ0KICAgICAgZm9sbG93ZWQg YnkgdGhlIDQgb2N0ZXQgSVB2NCBhZGRyZXNzIG9mIHRoZSBEUidzIGludGVyZmFjZSB0byB0aGUN CiAgICAgIExBTiAoOCBvY3RldHMgaW4gdG90YWwpIDxzbmlwPiINCg0KDQpUaGUgcmVhc29uIEkg c2VlayB0aGlzIGNoYW5nZSBpcywgdGhlIHRyYW5zaXQgbGluayByZXByZXNlbnRhdGlvbiBpbiBP U1BGdjIgcm91dGVyLUxTQSBkb2VzIG5vdCBjb250YWluIHRoZSByb3V0ZXItaWQgb2YgdGhlIERS IChzZWN0aW9uIDEyLjQuMS4yIG9mIFJGQzIzMjgpLiBTbywgQkdQLUxTIGhhcyBub3doZXJlIHRv IGRlcml2ZSBSb3V0ZXItSUQgZnJvbS4NCg0KDQpCZWxvdyBhcmUgbW9yZSBkZXRhaWxzIHdpdGgg YW4gZXhhbXBsZS4NCg0KDQpUaGUgJ0lHUCByb3V0ZXIgSUQnIGZpZWxkIGNhbiBhcHBlYXIgZWl0 aGVyIGluIOKAmExvY2FsIE5vZGUgRGVzY3JpcHRvcuKAmSBvciDigJhSZW1vdGUgTm9kZSBEZXNj cmlwdG9y4oCZLiBMZXTigJlzIGNvbnNpZGVyIHRoZSBjYXNlIGluIHdoaWNoIHRoaXMgZmllbGQg YXBwZWFycyBpbiDigJhSZW1vdGUgTm9kZSBEZXNjcmlwdG9y4oCZIGluIHRoZSBmb2xsb3dpbmcg dG9wb2xvZ3kuDQoNCg0KUjEoMS4xLjEuMTo6MTAuMTAuMTAuMSkgPC0tLS1MMS0tLS0+IFIyICgy LjIuMi4yOjoxMC4xMC4xMC4yKQ0KDQpXaGVyZSwNClIxJ3Mgcm91dGVyLWlkIGlzIDEuMS4xLjEs IGFuZCBMMSBpbnRlcmZhY2UgSVAgYWRkcmVzcyBpcyAxMC4xMC4xMC4xLg0KUjIncyByb3V0ZXIt aWQgaXMgMi4yLjIuMiwgYW5kIEwxIGludGVyZmFjZSBJUCBhZGRyZXNzIGlzIDEwLjEwLjEwLjIu DQpMMSBpcyBhIExBTi4NClIxIGlzIGVsZWN0ZWQgYXMgdGhlIERSIGZvciBMMS4NCg0KVGhlcmUg YXJlIGZvdXIgZGlzdGluY3QgdW5pZGlyZWN0aW9uYWwgbGlua3MgaW4gdGhlIHRvcG9sb2d5IGFi b3ZlOiBSMS0+RFIsIERSLT5SMSwgUjItPkRSLCBhbmQgRFItPlIyLiBMZXTigJlzIGNvbnNpZGVy IHRoZSBsaW5rIFIyLT5EUi4gUjLigJlzIHJvdXRlciBMU0EgcmVwcmVzZW50cyBSMi0+RFIgbGlu ayBhcyBmb2xsb3dzOiAtDQoNCkFkdmVydGlzaW5nIHJvdXRlcjoyLjIuMi4yDQogICBMaW5rIElE OiAxMC4xMC4xMC4xDQogICBMaW5rIGRhdGE6MTAuMTAuMTAuMg0KICAgVHlwZToyIChUcmFuc2l0 KQ0KDQpOb3RlIHRoYXQgdGhlIE9TUEYgbGluayByZXByZXNlbnRhdGlvbiBhYm92ZSBkb2VzIG5v dCBpbmNsdWRlIHRoZSByb3V0ZXItaWQgb2YgdGhlIERSLCB3aGljaCBpcyAxLjEuMS4xLg0KDQoN CkFjY29yZGluZyB0byB0aGUgdGV4dCBpbiBzZWN0aW9uIDMuMi4xLjQsIEJHUC1MUyByZXF1aXJl cyB1cyB0byByZXByZXNlbnQgUjItPkRSIGxpbmsgYXMgZm9sbG93cyAoY29uc2lkZXJpbmcgb25s eSBub2RlIGRlc2NyaXB0b3JzIG9mIHJlbGV2YW5jZSB0byB0aGlzIGRpc2N1c3Npb24sIGFuZCBp Z25vcmluZyB0aGUgcmVtYWluaW5nIGZpZWxkcykgOiAtDQoNCkxvY2FsIE5vZGUoSUdQLVJvdXRl ci1JZDoyLjIuMi4yKSAtPiBSZW1vdGUgTm9kZShJR1AtUm91dGVyLUlkOjEuMS4xLjEtMTAuMTAu MTAuMSkNCg0KDQpIb3dldmVyLCB0aGUgT1NQRiByZXByZXNlbnRhdGlvbiBvZiB0aGUgYWJvdmUg bGluayBpbiBSMuKAmXMgcm91dGVyIExTQSBkb2VzIG5vdCBjb250YWluIDEuMS4xLjEgYXQgYWxs LiBUaGVyZWZvcmUsIEJHUC1MUyBoYXMgbm93aGVyZSB0byBkZXJpdmUg4oCYMS4xLjEuMeKAmSBm cm9tLCBmb3IgdGhlIGxpbmsgUjItPkRSLg0KDQpUaGUgZXhhbXBsZSBpbiBzZWN0aW9uIDMuNyBp cyBhdCBvZGRzIHdpdGggdGhlIHRleHQgaW4gc2VjdGlvbiAzLjIuMS40LCBhbmQgcmVwcmVzZW50 cyB0aGUgbGluayBhcyBmb2xsb3dzICh3aGljaCB3b3JrcyBwZXJmZWN0bHkpOiAtDQoNCg0KTG9j YWwgTm9kZShJR1AtUm91dGVyLUlkOjIuMi4yLjIpIC0+IFJlbW90ZSBOb2RlKElHUC1Sb3V0ZXIt SWQ6MTAuMTAuMTAuMS0xMC4xMC4xMC4xKQ0KDQoNCkkgc3VnZ2VzdCByZXdvcmRpbmcgdGhlIHRl eHQgaW4gMy4yLjEuNCBhcyBmb2xsb3dzOg0KDQoiDQpJR1AgUm91dGVyIElEOiA8c25pcD4gRm9y IGFuIE9TUEZ2MiAiUHNldWRvbm9kZSIgcmVwcmVzZW50aW5nIGEgTEFOLA0KDQogICAgICB0aGlz IGNvbnRhaW5zIHRoZSA0IG9jdGV0IElQdjQgYWRkcmVzcyBvZiB0aGUgRFIncyBpbnRlcmZhY2Ug dG8gdGhlDQogICAgICBMQU4sIGZvbGxvd2VkIGJ5IGFueSBub24temVybyA0LW9jdGV0IG51bWJl ciAoOCBvY3RldHMgaW4gdG90YWwpIDxzbmlwPuKAnQ0KDQoNCuKAlA0KQmFsYWppIFJhamFnb3Bh bGFuDQoNCg0KDQoNCkZyb206IFRoZSBJRVNHIDxpZXNnLXNlY3JldGFyeUBpZXRmLm9yZzxtYWls dG86aWVzZy1zZWNyZXRhcnlAaWV0Zi5vcmc+Pg0KUmVwbHktVG86ICJpZXRmQGlldGYub3JnPG1h aWx0bzppZXRmQGlldGYub3JnPiIgPGlldGZAaWV0Zi5vcmc8bWFpbHRvOmlldGZAaWV0Zi5vcmc+ Pg0KRGF0ZTogVGh1cnNkYXksIE1hcmNoIDE5LCAyMDE1IGF0IDE6MTAgQU0NClRvOiBJRVRGLUFu bm91bmNlIDxpZXRmLWFubm91bmNlQGlldGYub3JnPG1haWx0bzppZXRmLWFubm91bmNlQGlldGYu b3JnPj4NCkNjOiAiaWRyQGlldGYub3JnPG1haWx0bzppZHJAaWV0Zi5vcmc+IiA8aWRyQGlldGYu b3JnPG1haWx0bzppZHJAaWV0Zi5vcmc+Pg0KU3ViamVjdDogW0lkcl0gUkVWSVNFRCBMYXN0IENh bGw6IDxkcmFmdC1pZXRmLWlkci1scy1kaXN0cmlidXRpb24tMTAudHh0PiAoTm9ydGgtQm91bmQg RGlzdHJpYnV0aW9uIG9mIExpbmstU3RhdGUgYW5kIFRFIEluZm9ybWF0aW9uIHVzaW5nIEJHUCkg dG8gUHJvcG9zZWQgU3RhbmRhcmQNCg0KDQpUaGUgSUVTRyBoYXMgcmVjZWl2ZWQgYSByZXF1ZXN0 IGZyb20gdGhlIEludGVyLURvbWFpbiBSb3V0aW5nIFdHIChpZHIpIHRvDQpjb25zaWRlciB0aGUg Zm9sbG93aW5nIGRvY3VtZW50Og0KLSAnTm9ydGgtQm91bmQgRGlzdHJpYnV0aW9uIG9mIExpbmst U3RhdGUgYW5kIFRFIEluZm9ybWF0aW9uIHVzaW5nIEJHUCcNCiAgPGRyYWZ0LWlldGYtaWRyLWxz LWRpc3RyaWJ1dGlvbi0xMC50eHQ+IGFzIFByb3Bvc2VkIFN0YW5kYXJkDQoNClRoZSBJRVNHIHBs YW5zIHRvIG1ha2UgYSBkZWNpc2lvbiBpbiB0aGUgbmV4dCBmZXcgd2Vla3MsIGFuZCBzb2xpY2l0 cw0KZmluYWwgY29tbWVudHMgb24gdGhpcyBhY3Rpb24uIFBsZWFzZSBzZW5kIHN1YnN0YW50aXZl IGNvbW1lbnRzIHRvIHRoZQ0KaWV0ZkBpZXRmLm9yZzxtYWlsdG86aWV0ZkBpZXRmLm9yZz4gbWFp bGluZyBsaXN0cyBieSAyMDE1LTA0LTA4LiBFeGNlcHRpb25hbGx5LCBjb21tZW50cyBtYXkgYmUN CnNlbnQgdG8gaWVzZ0BpZXRmLm9yZzxtYWlsdG86aWVzZ0BpZXRmLm9yZz4gaW5zdGVhZC4gSW4g ZWl0aGVyIGNhc2UsIHBsZWFzZSByZXRhaW4gdGhlDQpiZWdpbm5pbmcgb2YgdGhlIFN1YmplY3Qg bGluZSB0byBhbGxvdyBhdXRvbWF0ZWQgc29ydGluZy4NCg0KQWJzdHJhY3QNCg0KDQogICBJbiBh IG51bWJlciBvZiBlbnZpcm9ubWVudHMsIGEgY29tcG9uZW50IGV4dGVybmFsIHRvIGEgbmV0d29y ayBpcw0KICAgY2FsbGVkIHVwb24gdG8gcGVyZm9ybSBjb21wdXRhdGlvbnMgYmFzZWQgb24gdGhl IG5ldHdvcmsgdG9wb2xvZ3kgYW5kDQogICBjdXJyZW50IHN0YXRlIG9mIHRoZSBjb25uZWN0aW9u cyB3aXRoaW4gdGhlIG5ldHdvcmssIGluY2x1ZGluZw0KICAgdHJhZmZpYyBlbmdpbmVlcmluZyBp bmZvcm1hdGlvbi4gIFRoaXMgaXMgaW5mb3JtYXRpb24gdHlwaWNhbGx5DQogICBkaXN0cmlidXRl ZCBieSBJR1Agcm91dGluZyBwcm90b2NvbHMgd2l0aGluIHRoZSBuZXR3b3JrLg0KDQogICBUaGlz IGRvY3VtZW50IGRlc2NyaWJlcyBhIG1lY2hhbmlzbSBieSB3aGljaCBsaW5rcyBzdGF0ZSBhbmQg dHJhZmZpYw0KICAgZW5naW5lZXJpbmcgaW5mb3JtYXRpb24gY2FuIGJlIGNvbGxlY3RlZCBmcm9t IG5ldHdvcmtzIGFuZCBzaGFyZWQNCiAgIHdpdGggZXh0ZXJuYWwgY29tcG9uZW50cyB1c2luZyB0 aGUgQkdQIHJvdXRpbmcgcHJvdG9jb2wuICBUaGlzIGlzDQogICBhY2hpZXZlZCB1c2luZyBhIG5l dyBCR1AgTmV0d29yayBMYXllciBSZWFjaGFiaWxpdHkgSW5mb3JtYXRpb24NCiAgIChOTFJJKSBl bmNvZGluZyBmb3JtYXQuICBUaGUgbWVjaGFuaXNtIGlzIGFwcGxpY2FibGUgdG8gcGh5c2ljYWwg YW5kDQogICB2aXJ0dWFsIElHUCBsaW5rcy4gIFRoZSBtZWNoYW5pc20gZGVzY3JpYmVkIGlzIHN1 YmplY3QgdG8gcG9saWN5DQogICBjb250cm9sLg0KDQogICBBcHBsaWNhdGlvbnMgb2YgdGhpcyB0 ZWNobmlxdWUgaW5jbHVkZSBBcHBsaWNhdGlvbiBMYXllciBUcmFmZmljDQogICBPcHRpbWl6YXRp b24gKEFMVE8pIHNlcnZlcnMsIGFuZCBQYXRoIENvbXB1dGF0aW9uIEVsZW1lbnRzIChQQ0VzKS4N Cg0KDQoNCg0KDQpUaGUgZmlsZSBjYW4gYmUgb2J0YWluZWQgdmlhDQpodHRwOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaWRyLWxzLWRpc3RyaWJ1dGlvbi8NCg0KSUVTRyBk aXNjdXNzaW9uIGNhbiBiZSB0cmFja2VkIHZpYQ0KaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1pZXRmLWlkci1scy1kaXN0cmlidXRpb24vYmFsbG90Lw0KDQoNClRoZSBmb2xs b3dpbmcgSVBSIERlY2xhcmF0aW9ucyBtYXkgYmUgcmVsYXRlZCB0byB0aGlzIEktRDoNCg0KICAg aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2lwci8xODY0Lw0KDQoNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklkciBtYWlsaW5nIGxpc3QNCklk ckBpZXRmLm9yZzxtYWlsdG86SWRyQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9pZHINCg0K --_000_D141DAC412D74balajirjunipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <239A24F0AB62DD47AF5298BD957B5B19@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAw KTsgZm9udC1mYW1pbHk6IENvbnNvbGFzLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE1cHg7Ij4N Ckkgc2VlayBhIGNvcnJlY3Rpb24gdG8gdGhlIGZvbGxvd2luZyB0ZXh0IGluIHNlY3Rpb24gMy4y LjEuNC48L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5 OiBDb25zb2xhcywgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNXB4OyI+DQo8YnI+DQo8L2Rpdj4N CjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDb25zb2xhcywg c2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNXB4OyI+DQomcXVvdDs8L2Rpdj4NCjxkaXYgc3R5bGU9 ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDb25zb2xhcywgc2Fucy1zZXJpZjsg Zm9udC1zaXplOiAxNXB4OyI+DQpJR1AgUm91dGVyIElEOiAmbHQ7c25pcCZndDsmbmJzcDs8c3Bh biBzdHlsZT0ibGluZS1oZWlnaHQ6IDEuMmVtOyI+Rm9yIGFuIE9TUEZ2MiAmcXVvdDtQc2V1ZG9u b2RlJnF1b3Q7IHJlcHJlc2VudGluZyBhIExBTiw8L3NwYW4+PC9kaXY+DQo8cHJlIHN0eWxlPSJj b2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ29uc29sYXMsIHNhbnMtc2VyaWY7IGZv bnQtc2l6ZTogMTVweDsgbGluZS1oZWlnaHQ6IDEuMmVtOyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdp bi1ib3R0b206IDBweDsiPjxmb250IGZhY2U9IkNvbnNvbGFzIj4gICAgICB0aGlzIGNvbnRhaW5z IHRoZSA0IG9jdGV0IFJvdXRlci1JRCBvZiB0aGUgZGVzaWduYXRlZCByb3V0ZXIgKERSKQ0KICAg ICAgZm9sbG93ZWQgYnkgdGhlIDQgb2N0ZXQgSVB2NCBhZGRyZXNzIG9mIHRoZSBEUidzIGludGVy ZmFjZSB0byB0aGUNCiAgICAgIExBTiAoOCBvY3RldHMgaW4gdG90YWwpICZsdDtzbmlwJmd0OyZx dW90OzwvZm9udD48L3ByZT4NCjxwcmUgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQt ZmFtaWx5OiBDb25zb2xhcywgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNXB4OyBsaW5lLWhlaWdo dDogMS4yZW07IG1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyI+PGJyPjwvcHJl Pg0KPHByZSBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENvbnNvbGFz LCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE1cHg7IG1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJv dHRvbTogMHB4OyI+PGZvbnQgZmFjZT0iQ29uc29sYXMiPjxzcGFuIHN0eWxlPSJsaW5lLWhlaWdo dDogMThweDsiPlRoZSByZWFzb24gSSBzZWVrIHRoaXMgY2hhbmdlIGlzLCB0PC9zcGFuPjwvZm9u dD48Zm9udCBmYWNlPSJDb25zb2xhcyIgc3R5bGU9ImZvbnQtc2l6ZTogMTVweDsgbGluZS1oZWln aHQ6IDEuMmVtOyI+aGUgdHJhbnNpdCBsaW5rIHJlcHJlc2VudGF0aW9uIGluIE9TUEZ2MiByb3V0 ZXItTFNBIGRvZXMgbm90IGNvbnRhaW4gdGhlIHJvdXRlci1pZCBvZiB0aGUgRFIgPC9mb250Pjxz cGFuIHN0eWxlPSJmb250LXNpemU6IDE1cHg7IGxpbmUtaGVpZ2h0OiAxLjJlbTsgZm9udC1mYW1p bHk6IENvbnNvbGFzOyI+KHNlY3Rpb24gMTIuNC4xLjIgb2YgUkZDMjMyOCk8L3NwYW4+PGZvbnQg ZmFjZT0iQ29uc29sYXMiPjxzcGFuIHN0eWxlPSJsaW5lLWhlaWdodDogMS4yZW07Ij4uJm5ic3A7 U28sIEJHUC1MUyBoYXMgbm93aGVyZSB0byBkZXJpdmUgUm91dGVyLUlEIGZyb20uPC9zcGFuPjwv Zm9udD48L3ByZT4NCjxwcmUgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5 OiBDb25zb2xhcywgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNXB4OyBsaW5lLWhlaWdodDogMS4y ZW07IG1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiBDb25zb2xhczsgbGluZS1oZWlnaHQ6IDEuMmVtOyI+PGJyPjwvc3Bhbj48L3By ZT4NCjxwcmUgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDb25zb2xh cywgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNXB4OyBsaW5lLWhlaWdodDogMS4yZW07IG1hcmdp bi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiBDb25zb2xhczsgbGluZS1oZWlnaHQ6IDEuMmVtOyI+QmVsb3cgYXJlIG1vcmUgZGV0YWlscyB3 aXRoIGFuIGV4YW1wbGUuPC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0iY29sb3I6IHJnYigwLCAw LCAwKTsgZm9udC1mYW1pbHk6IENvbnNvbGFzLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE1cHg7 IGxpbmUtaGVpZ2h0OiAxLjJlbTsgbWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7 Ij48Zm9udCBmYWNlPSJDb25zb2xhcyI+PGJyPjwvZm9udD48L3ByZT4NCjxwcmUgc3R5bGU9ImNv bG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDb25zb2xhcywgc2Fucy1zZXJpZjsgZm9u dC1zaXplOiAxNXB4OyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsiPjxmb250 IGZhY2U9IkNvbnNvbGFzIj48c3BhbiBzdHlsZT0ibGluZS1oZWlnaHQ6IDEuMmVtOyI+VGhlICdJ R1Agcm91dGVyIElEJyBmaWVsZCBjYW4gYXBwZWFyIGVpdGhlciBpbiDigJhMb2NhbCBOb2RlIERl c2NyaXB0b3LigJkgb3Ig4oCYUmVtb3RlIE5vZGUgRGVzY3JpcHRvcuKAmS4gTGV0PC9zcGFuPjxz cGFuIHN0eWxlPSJsaW5lLWhlaWdodDogMThweDsiPuKAmTwvc3Bhbj48c3BhbiBzdHlsZT0ibGlu ZS1oZWlnaHQ6IDEuMmVtOyI+cyBjb25zaWRlciB0aGUgY2FzZSBpbiB3aGljaCB0aGlzIGZpZWxk IGFwcGVhcnMgaW4gPC9zcGFuPjxzcGFuIHN0eWxlPSJsaW5lLWhlaWdodDogMThweDsiPuKAmDwv c3Bhbj48c3BhbiBzdHlsZT0ibGluZS1oZWlnaHQ6IDEuMmVtOyI+UmVtb3RlIE5vZGUgRGVzY3Jp cHRvcjwvc3Bhbj48c3BhbiBzdHlsZT0ibGluZS1oZWlnaHQ6IDE4cHg7Ij7igJkgaW4gdGhlIGZv bGxvd2luZyB0b3BvbG9neS48L3NwYW4+PC9mb250PjwvcHJlPg0KPHByZSBzdHlsZT0iY29sb3I6 IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENvbnNvbGFzLCBzYW5zLXNlcmlmOyBmb250LXNp emU6IDE1cHg7IG1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyI+PGZvbnQgZmFj ZT0iQ29uc29sYXMiPjxzcGFuIHN0eWxlPSJsaW5lLWhlaWdodDogMThweDsiPjxicj48L3NwYW4+ PC9mb250PjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9t OiAwcHg7Ij48ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ29u c29sYXMsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTVweDsgd2hpdGUtc3BhY2U6IG5vcm1hbDsi PlIxKDEuMS4xLjE6OjEwLjEwLjEwLjEpICZsdDstLS0tTDEtLS0tJmd0OyBSMiAoMi4yLjIuMjo6 MTAuMTAuMTAuMik8L2Rpdj48ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZh bWlseTogQ29uc29sYXMsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTVweDsgd2hpdGUtc3BhY2U6 IG5vcm1hbDsiPjxicj48L2Rpdj48ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250 LWZhbWlseTogQ29uc29sYXMsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTVweDsgd2hpdGUtc3Bh Y2U6IG5vcm1hbDsiPldoZXJlLDwvZGl2PjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7 IGZvbnQtZmFtaWx5OiBDb25zb2xhcywgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNXB4OyB3aGl0 ZS1zcGFjZTogbm9ybWFsOyI+UjEncyByb3V0ZXItaWQgaXMgMS4xLjEuMSwgYW5kIEwxIGludGVy ZmFjZSBJUCBhZGRyZXNzIGlzIDEwLjEwLjEwLjEuPC9kaXY+PGRpdiBzdHlsZT0iY29sb3I6IHJn YigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENvbnNvbGFzLCBzYW5zLXNlcmlmOyBmb250LXNpemU6 IDE1cHg7IHdoaXRlLXNwYWNlOiBub3JtYWw7Ij5SMidzIHJvdXRlci1pZCBpcyAyLjIuMi4yLCBh bmQgTDEgaW50ZXJmYWNlIElQIGFkZHJlc3MgaXMgMTAuMTAuMTAuMi48L2Rpdj48ZGl2IHN0eWxl PSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ29uc29sYXMsIHNhbnMtc2VyaWY7 IGZvbnQtc2l6ZTogMTVweDsgd2hpdGUtc3BhY2U6IG5vcm1hbDsiPkwxIGlzIGEgTEFOLjwvZGl2 PjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDb25zb2xhcywg c2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNXB4OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyI+UjEgaXMg ZWxlY3RlZCBhcyB0aGUgRFIgZm9yIEwxLjwvZGl2PjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwg MCwgMCk7IGZvbnQtZmFtaWx5OiBDb25zb2xhcywgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNXB4 OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyI+PGJyPjwvZGl2PjxkaXYgc3R5bGU9ImNvbG9yOiByZ2Io MCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDb25zb2xhcywgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAx NXB4OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyI+VGhlcmUgYXJlIGZvdXIgZGlzdGluY3QgdW5pZGly ZWN0aW9uYWwgbGlua3MgaW4gdGhlIHRvcG9sb2d5IGFib3ZlOiBSMS0mZ3Q7RFIsIERSLSZndDtS MSwgUjItJmd0O0RSLCBhbmQgRFItJmd0O1IyLiBMZXTigJlzIGNvbnNpZGVyIHRoZSBsaW5rIFIy LSZndDtEUi4gUjLigJlzIHJvdXRlciBMU0EgcmVwcmVzZW50cyBSMi0mZ3Q7RFIgbGluayBhcyBm b2xsb3dzOiAtPC9kaXY+PHByZSBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1p bHk6IENvbnNvbGFzLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE1cHg7IG1hcmdpbi10b3A6IDBw eDsgbWFyZ2luLWJvdHRvbTogMHB4OyI+PGRpdiBzdHlsZT0id2hpdGUtc3BhY2U6IG5vcm1hbDsi Pjxicj48L2Rpdj48ZGl2IHN0eWxlPSJ3aGl0ZS1zcGFjZTogbm9ybWFsOyI+QWR2ZXJ0aXNpbmcg cm91dGVyOjIuMi4yLjI8L2Rpdj48ZGl2IHN0eWxlPSJ3aGl0ZS1zcGFjZTogbm9ybWFsOyI+Jm5i c3A7ICZuYnNwO0xpbmsgSUQ6IDEwLjEwLjEwLjE8L2Rpdj48ZGl2IHN0eWxlPSJ3aGl0ZS1zcGFj ZTogbm9ybWFsOyI+Jm5ic3A7ICZuYnNwO0xpbmsgZGF0YToxMC4xMC4xMC4yPC9kaXY+PGRpdiBz dHlsZT0id2hpdGUtc3BhY2U6IG5vcm1hbDsiPiZuYnNwOyAmbmJzcDtUeXBlOjIgKFRyYW5zaXQp PC9kaXY+PC9wcmU+PGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6 IENvbnNvbGFzLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE1cHg7IHdoaXRlLXNwYWNlOiBub3Jt YWw7Ij48YnI+PC9kaXY+PGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1p bHk6IENvbnNvbGFzLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE1cHg7IHdoaXRlLXNwYWNlOiBu b3JtYWw7Ij5Ob3RlIHRoYXQgdGhlIE9TUEYgbGluayByZXByZXNlbnRhdGlvbiBhYm92ZSBkb2Vz IG5vdCBpbmNsdWRlIHRoZSByb3V0ZXItaWQgb2YgdGhlIERSLCB3aGljaCBpcyAxLjEuMS4xLjwv ZGl2PjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDb25zb2xh cywgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNXB4OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyI+PGJy PjwvZGl2PjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDb25z b2xhcywgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNXB4OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyI+ PHByZSBzdHlsZT0ibWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7Ij48ZGl2IHN0 eWxlPSJmb250LWZhbWlseTogQ29uc29sYXMsIHNhbnMtc2VyaWY7IHdoaXRlLXNwYWNlOiBub3Jt YWw7Ij5BY2NvcmRpbmcgdG8gdGhlIHRleHQgaW4gc2VjdGlvbiAzLjIuMS40LCBCR1AtTFMgcmVx dWlyZXMgdXMgdG8gcmVwcmVzZW50IFIyLSZndDtEUiBsaW5rIGFzIGZvbGxvd3MgKGNvbnNpZGVy aW5nIG9ubHkgbm9kZSBkZXNjcmlwdG9ycyBvZiByZWxldmFuY2UgdG8gdGhpcyBkaXNjdXNzaW9u LCBhbmQgaWdub3JpbmcgdGhlIHJlbWFpbmluZyBmaWVsZHMpIDogLTwvZGl2PjxkaXYgc3R5bGU9 ImZvbnQtZmFtaWx5OiBDb25zb2xhcywgc2Fucy1zZXJpZjsgd2hpdGUtc3BhY2U6IG5vcm1hbDsi Pjxicj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ29uc29sYXMsIHNhbnMtc2VyaWY7 IHdoaXRlLXNwYWNlOiBub3JtYWw7Ij5Mb2NhbCBOb2RlKElHUC1Sb3V0ZXItSWQ6Mi4yLjIuMikg LSZndDsgUmVtb3RlIE5vZGUoSUdQLVJvdXRlci1JZDoxLjEuMS4xLTEwLjEwLjEwLjEpPC9kaXY+ PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENvbnNvbGFzLCBzYW5zLXNlcmlmOyB3aGl0ZS1zcGFj ZTogbm9ybWFsOyI+PGJyPjwvZGl2PjwvcHJlPjwvZGl2PjxkaXYgc3R5bGU9ImNvbG9yOiByZ2Io MCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDb25zb2xhcywgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAx NXB4OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyI+SG93ZXZlciwgdGhlIE9TUEYgcmVwcmVzZW50YXRp b24gb2YgdGhlIGFib3ZlIGxpbmsgaW4gUjLigJlzIHJvdXRlciBMU0EgZG9lcyBub3QgY29udGFp biAxLjEuMS4xIGF0IGFsbC4gVGhlcmVmb3JlLCBCR1AtTFMgaGFzIG5vd2hlcmUgdG8gZGVyaXZl IOKAmDEuMS4xLjHigJkgZnJvbSwgZm9yIHRoZSBsaW5rIFIyLSZndDtEUi48L2Rpdj48ZGl2IHN0 eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ29uc29sYXMsIHNhbnMtc2Vy aWY7IGZvbnQtc2l6ZTogMTVweDsgd2hpdGUtc3BhY2U6IG5vcm1hbDsiPjxicj48L2Rpdj48ZGl2 IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ29uc29sYXMsIHNhbnMt c2VyaWY7IGZvbnQtc2l6ZTogMTVweDsgd2hpdGUtc3BhY2U6IG5vcm1hbDsiPlRoZSBleGFtcGxl IGluIHNlY3Rpb24gMy43IGlzIGF0IG9kZHMgd2l0aCB0aGUgdGV4dCBpbiBzZWN0aW9uIDMuMi4x LjQsIGFuZCByZXByZXNlbnRzIHRoZSBsaW5rIGFzIGZvbGxvd3MgKHdoaWNoIHdvcmtzIHBlcmZl Y3RseSk6IC08L2Rpdj48ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWls eTogQ29uc29sYXMsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTVweDsgd2hpdGUtc3BhY2U6IG5v cm1hbDsiPjxicj48L2Rpdj48ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZh bWlseTogQ29uc29sYXMsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTVweDsgd2hpdGUtc3BhY2U6 IG5vcm1hbDsiPjxwcmUgc3R5bGU9Im1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4 OyI+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENvbnNvbGFzLCBzYW5zLXNlcmlmOyB3aGl0ZS1z cGFjZTogbm9ybWFsOyI+TG9jYWwgTm9kZShJR1AtUm91dGVyLUlkOjIuMi4yLjIpIC0mZ3Q7IFJl bW90ZSBOb2RlKElHUC1Sb3V0ZXItSWQ6MTAuMTAuMTAuMS0xMC4xMC4xMC4xKTwvZGl2PjxkaXY+ PGJyPjwvZGl2PjwvcHJlPjwvZGl2PjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZv bnQtZmFtaWx5OiBDb25zb2xhcywgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNXB4OyB3aGl0ZS1z cGFjZTogbm9ybWFsOyI+SSBzdWdnZXN0IHJld29yZGluZyB0aGUgdGV4dCBpbiAzLjIuMS40IGFz IGZvbGxvd3M6Jm5ic3A7PC9kaXY+PGRpdj48cHJlIHN0eWxlPSJtYXJnaW4tdG9wOiAwcHg7IG1h cmdpbi1ib3R0b206IDBweDsiPjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQt ZmFtaWx5OiBDb25zb2xhcywgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNXB4OyB3aGl0ZS1zcGFj ZTogbm9ybWFsOyI+PGJyPjwvZGl2PjxkaXY+PGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAw KTsgZm9udC1mYW1pbHk6IENvbnNvbGFzLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE1cHg7IHdo aXRlLXNwYWNlOiBub3JtYWw7Ij4mcXVvdDs8L2Rpdj48ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAs IDAsIDApOyBmb250LWZhbWlseTogQ29uc29sYXMsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTVw eDsgd2hpdGUtc3BhY2U6IG5vcm1hbDsiPklHUCBSb3V0ZXIgSUQ6ICZsdDtzbmlwJmd0OyZuYnNw OzxzcGFuIHN0eWxlPSJsaW5lLWhlaWdodDogMS4yZW07Ij5Gb3IgYW4gT1NQRnYyICZxdW90O1Bz ZXVkb25vZGUmcXVvdDsgcmVwcmVzZW50aW5nIGEgTEFOLDwvc3Bhbj48L2Rpdj48cHJlIHN0eWxl PSJtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsiPjxmb250IGZhY2U9IkNvbnNv bGFzIiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENvbnNvbGFzLCBz YW5zLXNlcmlmOyBmb250LXNpemU6IDE1cHg7IGxpbmUtaGVpZ2h0OiAxLjJlbTsgd2hpdGUtc3Bh Y2U6IG5vcm1hbDsiPiAgICAgIHRoaXMgY29udGFpbnMgdGhlIDQgb2N0ZXQgSVB2NCBhZGRyZXNz IG9mIHRoZSBEUidzIGludGVyZmFjZSB0byB0aGUNCiAgICAgIExBTiwgZm9sbG93ZWQgYnkgYW55 IG5vbi16ZXJvIDQtb2N0ZXQgbnVtYmVyICg4IG9jdGV0cyBpbiB0b3RhbCkgJmx0O3NuaXAmZ3Q7 PC9mb250Pjxmb250IGZhY2U9IkNvbnNvbGFzIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxNXB4 OyBsaW5lLWhlaWdodDogMThweDsiPuKAnTwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZSBzdHlsZT0i Y29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENvbnNvbGFzLCBzYW5zLXNlcmlmOyBm b250LXNpemU6IDE1cHg7IHdoaXRlLXNwYWNlOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiAxLjJlbTsg bWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7Ij48Zm9udCBmYWNlPSJDb25zb2xh cyI+PGJyPjwvZm9udD48L3ByZT48L2Rpdj48L3ByZT48L2Rpdj48ZGl2IHN0eWxlPSJjb2xvcjog cmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ29uc29sYXMsIHNhbnMtc2VyaWY7IGZvbnQtc2l6 ZTogMTVweDsgd2hpdGUtc3BhY2U6IG5vcm1hbDsiPuKAlDwvZGl2PjxkaXYgc3R5bGU9ImNvbG9y OiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDb25zb2xhcywgc2Fucy1zZXJpZjsgZm9udC1z aXplOiAxNXB4OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyI+QmFsYWppIFJhamFnb3BhbGFuPC9kaXY+ PGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENvbnNvbGFzLCBz YW5zLXNlcmlmOyBmb250LXNpemU6IDE1cHg7IHdoaXRlLXNwYWNlOiBub3JtYWw7Ij48YnI+PC9k aXY+PGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENvbnNvbGFz LCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE1cHg7IHdoaXRlLXNwYWNlOiBub3JtYWw7Ij48YnI+ PC9kaXY+PC9wcmU+DQo8cHJlIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWls eTogQ29uc29sYXMsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTVweDsgbGluZS1oZWlnaHQ6IDEu MmVtOyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsiPjxicj48L3ByZT4NCjxk aXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDb25zb2xhcywgc2Fu cy1zZXJpZjsgZm9udC1zaXplOiAxNXB4OyI+DQo8YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtf U1JDX0JPRFlfU0VDVElPTiIgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5 OiBDb25zb2xhcywgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNXB4OyI+DQo8ZGl2IHN0eWxlPSJm b250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTFwdDsgdGV4dC1hbGlnbjpsZWZ0OyBjb2xv cjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0g bm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1MRUZUOiAwaW47IFBBRERJTkctUklH SFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdIVDogbWVk aXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJv bGQiPkZyb206IDwvc3Bhbj5UaGUgSUVTRyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmllc2ctc2VjcmV0 YXJ5QGlldGYub3JnIj5pZXNnLXNlY3JldGFyeUBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHNwYW4g c3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlJlcGx5LVRvOiA8L3NwYW4+JnF1b3Q7PGEgaHJlZj0i bWFpbHRvOmlldGZAaWV0Zi5vcmciPmlldGZAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVm PSJtYWlsdG86aWV0ZkBpZXRmLm9yZyI+aWV0ZkBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHNwYW4g c3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5UaHVyc2RheSwgTWFyY2ggMTks IDIwMTUgYXQgMToxMCBBTTxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Ubzog PC9zcGFuPklFVEYtQW5ub3VuY2UgJmx0OzxhIGhyZWY9Im1haWx0bzppZXRmLWFubm91bmNlQGll dGYub3JnIj5pZXRmLWFubm91bmNlQGlldGYub3JnPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0i Zm9udC13ZWlnaHQ6Ym9sZCI+Q2M6IDwvc3Bhbj4mcXVvdDs8YSBocmVmPSJtYWlsdG86aWRyQGll dGYub3JnIj5pZHJAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86aWRyQGll dGYub3JnIj5pZHJAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdo dDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+W0lkcl0gUkVWSVNFRCBMYXN0IENhbGw6ICZsdDtkcmFm dC1pZXRmLWlkci1scy1kaXN0cmlidXRpb24tMTAudHh0Jmd0OyAoTm9ydGgtQm91bmQgRGlzdHJp YnV0aW9uIG9mIExpbmstU3RhdGUgYW5kIFRFIEluZm9ybWF0aW9uIHVzaW5nIEJHUCkgdG8gUHJv cG9zZWQgU3RhbmRhcmQ8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1M RUZUOiAjYjVjNGRmIDUgc29saWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhlIElFU0cgaGFzIHJlY2Vp dmVkIGEgcmVxdWVzdCBmcm9tIHRoZSBJbnRlci1Eb21haW4gUm91dGluZyBXRyAoaWRyKSB0bzwv ZGl2Pg0KPGRpdj5jb25zaWRlciB0aGUgZm9sbG93aW5nIGRvY3VtZW50OjwvZGl2Pg0KPGRpdj4t ICdOb3J0aC1Cb3VuZCBEaXN0cmlidXRpb24gb2YgTGluay1TdGF0ZSBhbmQgVEUgSW5mb3JtYXRp b24gdXNpbmcgQkdQJzwvZGl2Pg0KPGRpdj4mbmJzcDsmbmJzcDsmbHQ7ZHJhZnQtaWV0Zi1pZHIt bHMtZGlzdHJpYnV0aW9uLTEwLnR4dCZndDsgYXMgUHJvcG9zZWQgU3RhbmRhcmQ8L2Rpdj4NCjxk aXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoZSBJRVNHIHBsYW5zIHRvIG1ha2UgYSBkZWNpc2lvbiBp biB0aGUgbmV4dCBmZXcgd2Vla3MsIGFuZCBzb2xpY2l0czwvZGl2Pg0KPGRpdj5maW5hbCBjb21t ZW50cyBvbiB0aGlzIGFjdGlvbi4gUGxlYXNlIHNlbmQgc3Vic3RhbnRpdmUgY29tbWVudHMgdG8g dGhlPC9kaXY+DQo8ZGl2PjxhIGhyZWY9Im1haWx0bzppZXRmQGlldGYub3JnIj5pZXRmQGlldGYu b3JnPC9hPiBtYWlsaW5nIGxpc3RzIGJ5IDIwMTUtMDQtMDguIEV4Y2VwdGlvbmFsbHksIGNvbW1l bnRzIG1heSBiZTwvZGl2Pg0KPGRpdj5zZW50IHRvIDxhIGhyZWY9Im1haWx0bzppZXNnQGlldGYu b3JnIj5pZXNnQGlldGYub3JnPC9hPiBpbnN0ZWFkLiBJbiBlaXRoZXIgY2FzZSwgcGxlYXNlIHJl dGFpbiB0aGU8L2Rpdj4NCjxkaXY+YmVnaW5uaW5nIG9mIHRoZSBTdWJqZWN0IGxpbmUgdG8gYWxs b3cgYXV0b21hdGVkIHNvcnRpbmcuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5BYnN0 cmFjdDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PiZu YnNwOyZuYnNwOyBJbiBhIG51bWJlciBvZiBlbnZpcm9ubWVudHMsIGEgY29tcG9uZW50IGV4dGVy bmFsIHRvIGEgbmV0d29yayBpczwvZGl2Pg0KPGRpdj4mbmJzcDsmbmJzcDsgY2FsbGVkIHVwb24g dG8gcGVyZm9ybSBjb21wdXRhdGlvbnMgYmFzZWQgb24gdGhlIG5ldHdvcmsgdG9wb2xvZ3kgYW5k PC9kaXY+DQo8ZGl2PiZuYnNwOyZuYnNwOyBjdXJyZW50IHN0YXRlIG9mIHRoZSBjb25uZWN0aW9u cyB3aXRoaW4gdGhlIG5ldHdvcmssIGluY2x1ZGluZzwvZGl2Pg0KPGRpdj4mbmJzcDsmbmJzcDsg dHJhZmZpYyBlbmdpbmVlcmluZyBpbmZvcm1hdGlvbi4mbmJzcDsmbmJzcDtUaGlzIGlzIGluZm9y bWF0aW9uIHR5cGljYWxseTwvZGl2Pg0KPGRpdj4mbmJzcDsmbmJzcDsgZGlzdHJpYnV0ZWQgYnkg SUdQIHJvdXRpbmcgcHJvdG9jb2xzIHdpdGhpbiB0aGUgbmV0d29yay48L2Rpdj4NCjxkaXY+PGJy Pg0KPC9kaXY+DQo8ZGl2PiZuYnNwOyZuYnNwOyBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIG1l Y2hhbmlzbSBieSB3aGljaCBsaW5rcyBzdGF0ZSBhbmQgdHJhZmZpYzwvZGl2Pg0KPGRpdj4mbmJz cDsmbmJzcDsgZW5naW5lZXJpbmcgaW5mb3JtYXRpb24gY2FuIGJlIGNvbGxlY3RlZCBmcm9tIG5l dHdvcmtzIGFuZCBzaGFyZWQ8L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7IHdpdGggZXh0ZXJuYWwg Y29tcG9uZW50cyB1c2luZyB0aGUgQkdQIHJvdXRpbmcgcHJvdG9jb2wuJm5ic3A7Jm5ic3A7VGhp cyBpczwvZGl2Pg0KPGRpdj4mbmJzcDsmbmJzcDsgYWNoaWV2ZWQgdXNpbmcgYSBuZXcgQkdQIE5l dHdvcmsgTGF5ZXIgUmVhY2hhYmlsaXR5IEluZm9ybWF0aW9uPC9kaXY+DQo8ZGl2PiZuYnNwOyZu YnNwOyAoTkxSSSkgZW5jb2RpbmcgZm9ybWF0LiZuYnNwOyZuYnNwO1RoZSBtZWNoYW5pc20gaXMg YXBwbGljYWJsZSB0byBwaHlzaWNhbCBhbmQ8L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7IHZpcnR1 YWwgSUdQIGxpbmtzLiZuYnNwOyZuYnNwO1RoZSBtZWNoYW5pc20gZGVzY3JpYmVkIGlzIHN1Ympl Y3QgdG8gcG9saWN5PC9kaXY+DQo8ZGl2PiZuYnNwOyZuYnNwOyBjb250cm9sLjwvZGl2Pg0KPGRp dj48YnI+DQo8L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7IEFwcGxpY2F0aW9ucyBvZiB0aGlzIHRl Y2huaXF1ZSBpbmNsdWRlIEFwcGxpY2F0aW9uIExheWVyIFRyYWZmaWM8L2Rpdj4NCjxkaXY+Jm5i c3A7Jm5ic3A7IE9wdGltaXphdGlvbiAoQUxUTykgc2VydmVycywgYW5kIFBhdGggQ29tcHV0YXRp b24gRWxlbWVudHMgKFBDRXMpLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8ZGl2PlRoZSBmaWxlIGNhbiBiZSBvYnRhaW5lZCB2aWE8L2Rpdj4NCjxkaXY+PGEg aHJlZj0iaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWlkci1scy1k aXN0cmlidXRpb24vIj5odHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYt aWRyLWxzLWRpc3RyaWJ1dGlvbi88L2E+PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5J RVNHIGRpc2N1c3Npb24gY2FuIGJlIHRyYWNrZWQgdmlhPC9kaXY+DQo8ZGl2PjxhIGhyZWY9Imh0 dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pZHItbHMtZGlzdHJpYnV0 aW9uL2JhbGxvdC8iPmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1p ZHItbHMtZGlzdHJpYnV0aW9uL2JhbGxvdC88L2E+PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0K PGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhlIGZvbGxvd2luZyBJUFIgRGVjbGFyYXRpb25zIG1h eSBiZSByZWxhdGVkIHRvIHRoaXMgSS1EOjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+ Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9pcHIvMTg2 NC8iPmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9pcHIvMTg2NC88L2E+PC9kaXY+DQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2 Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9kaXY+DQo8 ZGl2PklkciBtYWlsaW5nIGxpc3Q8L2Rpdj4NCjxkaXY+PGEgaHJlZj0ibWFpbHRvOklkckBpZXRm Lm9yZyI+SWRyQGlldGYub3JnPC9hPjwvZGl2Pg0KPGRpdj48YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkciI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9pZHI8L2E+PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_D141DAC412D74balajirjunipernet_-- From nobody Wed Apr 1 10:41:58 2015 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 9F10B1A1A9C; Wed, 1 Apr 2015 10:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lFScJBUu3-q4; Wed, 1 Apr 2015 10:41:53 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6912F1A0419; Wed, 1 Apr 2015 10:41:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=31765; q=dns/txt; s=iport; t=1427910114; x=1429119714; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=HwC52T0FhtFWwmsRWobtFCuqh39DEM92zLWHI3QfVHI=; b=PYw99+olBlJx6nP+b3wx507/Unu6Dw52TDk38nfWX9Nd5BW1gPDMoYUN E5+UuikTMPvs5NaYO3IvLNxLDTsaM1J4vvgojFeix5N0WWrgQv00eW5iD sGDpG9VN0bJm0kcpq9J0SAnm7mJpd7vO7VAAl4pB6aya/0ZxCt5Q6I2Oo c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BSBgALLRxV/4UNJK1cgkNDUlwFgxCyXo1rgXYBCYVzAhyBKUwBAQEBAQF9hBQBAQEEAQEBIARHCxACAQgRAwECIQMEAwICAiULFAkIAgQBDQWILw21WpkKAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4sphF4KDQQHgmiBRQWOVIIPg3KGBIEdOoJ4jCmDSCKCMoE8b4FEfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,504,1422921600"; d="scan'208,217";a="137409817" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-6.cisco.com with ESMTP; 01 Apr 2015 17:41:53 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t31Hfqt2014043 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 1 Apr 2015 17:41:52 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.236]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Wed, 1 Apr 2015 12:41:52 -0500 From: "Acee Lindem (acee)" To: Balaji Rajagopalan , "ietf@ietf.org" , Hannes Gredler Thread-Topic: [Idr] REVISED Last Call: (North-Bound Distribution of Link-State and TE Information using BGP) to Proposed Standard Thread-Index: AQHQYbN1sBT99RQ7ME2g+UypTJek+p04078A//+/7IA= Date: Wed, 1 Apr 2015 17:41:51 +0000 Message-ID: References: <20150318194048.32558.12168.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.152.196] Content-Type: multipart/alternative; boundary="_000_D141A386143CFaceeciscocom_" MIME-Version: 1.0 Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] REVISED Last Call: (North-Bound Distribution of Link-State and TE Information using BGP) to Proposed Standard 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, 01 Apr 2015 17:41:56 -0000 --_000_D141A386143CFaceeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QmFsYWppLA0KDQpUaGlzIGlzIGFuIGltcGxlbWVudGF0aW9uIGlzc3VlIGJhc2VkIG9uIHRoZSBm YWN0IHRoYXQgeW91IGFyZSBkZXJpdmluZyB0aGUgQkdQIExTIGluZm9ybWF0aW9uIGZyb20gdGhl IExTQXMgcmF0aGVyIHRoYW4gaGF2aW5nIHRoZSBJR1AgaW5zdGFsbCB0aGUgbm9ybWFsaXplZCBk cmFmdC1pZXRmLWlkci1scy1kaXN0cmlidXRpb24gbGlua3MuIEdpdmVuIHRoYXQgdGhlIGRyYWZ0 IGlzIHdpdGggdGhlIElFU0csIEnigJltIG5vdCBzdXJlIHdlIHdhbnQgdG8gYXR0ZW1wdCB0byBv cHRpbWl6ZSBpdCB0byB5b3VyIGltcGxlbWVudGF0aW9uIGFuZCBkaXNydXB0aXZlIGV2ZXJ5b25l IGVsc2XigJlzLiBJZiB5b3UgYXJlIG1haW50YWluaW5nIHRoZSBMU0FzIGluIGFuIE9TUEYgTFNE QiB0eXBlIHN0cnVjdHVyZSBpbiBCR1AsIHlvdSBlYXNpbHkgZmluZCB0aGUgTmV0d29yayBMU0Eg YW5kIGV4dHJhY3QgdGhlIGFkdmVydGlzaW5nIHJvdXRlci4NCg0KVGhhbmtzLA0KQWNlZQ0KDQpG cm9tOiBCYWxhamkgUmFqYWdvcGFsYW4gPGJhbGFqaXJAanVuaXBlci5uZXQ8bWFpbHRvOmJhbGFq aXJAanVuaXBlci5uZXQ+Pg0KRGF0ZTogV2VkbmVzZGF5LCBBcHJpbCAxLCAyMDE1IGF0IDE6MDAg UE0NClRvOiAiaWV0ZkBpZXRmLm9yZzxtYWlsdG86aWV0ZkBpZXRmLm9yZz4iIDxpZXRmQGlldGYu b3JnPG1haWx0bzppZXRmQGlldGYub3JnPj4sIEhhbm5lcyBHcmVkbGVyIDxoYW5uZXNAanVuaXBl ci5uZXQ8bWFpbHRvOmhhbm5lc0BqdW5pcGVyLm5ldD4+DQpDYzogImlkckBpZXRmLm9yZzxtYWls dG86aWRyQGlldGYub3JnPiIgPGlkckBpZXRmLm9yZzxtYWlsdG86aWRyQGlldGYub3JnPj4NClN1 YmplY3Q6IFJlOiBbSWRyXSBSRVZJU0VEIExhc3QgQ2FsbDogPGRyYWZ0LWlldGYtaWRyLWxzLWRp c3RyaWJ1dGlvbi0xMC50eHQ+IChOb3J0aC1Cb3VuZCBEaXN0cmlidXRpb24gb2YgTGluay1TdGF0 ZSBhbmQgVEUgSW5mb3JtYXRpb24gdXNpbmcgQkdQKSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KDQpJ IHNlZWsgYSBjb3JyZWN0aW9uIHRvIHRoZSBmb2xsb3dpbmcgdGV4dCBpbiBzZWN0aW9uIDMuMi4x LjQuDQoNCiINCklHUCBSb3V0ZXIgSUQ6IDxzbmlwPiBGb3IgYW4gT1NQRnYyICJQc2V1ZG9ub2Rl IiByZXByZXNlbnRpbmcgYSBMQU4sDQoNCiAgICAgIHRoaXMgY29udGFpbnMgdGhlIDQgb2N0ZXQg Um91dGVyLUlEIG9mIHRoZSBkZXNpZ25hdGVkIHJvdXRlciAoRFIpDQogICAgICBmb2xsb3dlZCBi eSB0aGUgNCBvY3RldCBJUHY0IGFkZHJlc3Mgb2YgdGhlIERSJ3MgaW50ZXJmYWNlIHRvIHRoZQ0K ICAgICAgTEFOICg4IG9jdGV0cyBpbiB0b3RhbCkgPHNuaXA+Ig0KDQoNClRoZSByZWFzb24gSSBz ZWVrIHRoaXMgY2hhbmdlIGlzLCB0aGUgdHJhbnNpdCBsaW5rIHJlcHJlc2VudGF0aW9uIGluIE9T UEZ2MiByb3V0ZXItTFNBIGRvZXMgbm90IGNvbnRhaW4gdGhlIHJvdXRlci1pZCBvZiB0aGUgRFIg KHNlY3Rpb24gMTIuNC4xLjIgb2YgUkZDMjMyOCkuIFNvLCBCR1AtTFMgaGFzIG5vd2hlcmUgdG8g ZGVyaXZlIFJvdXRlci1JRCBmcm9tLg0KDQoNCkJlbG93IGFyZSBtb3JlIGRldGFpbHMgd2l0aCBh biBleGFtcGxlLg0KDQoNClRoZSAnSUdQIHJvdXRlciBJRCcgZmllbGQgY2FuIGFwcGVhciBlaXRo ZXIgaW4g4oCYTG9jYWwgTm9kZSBEZXNjcmlwdG9y4oCZIG9yIOKAmFJlbW90ZSBOb2RlIERlc2Ny aXB0b3LigJkuIExldOKAmXMgY29uc2lkZXIgdGhlIGNhc2UgaW4gd2hpY2ggdGhpcyBmaWVsZCBh cHBlYXJzIGluIOKAmFJlbW90ZSBOb2RlIERlc2NyaXB0b3LigJkgaW4gdGhlIGZvbGxvd2luZyB0 b3BvbG9neS4NCg0KDQpSMSgxLjEuMS4xOjoxMC4xMC4xMC4xKSA8LS0tLUwxLS0tLT4gUjIgKDIu Mi4yLjI6OjEwLjEwLjEwLjIpDQoNCldoZXJlLA0KUjEncyByb3V0ZXItaWQgaXMgMS4xLjEuMSwg YW5kIEwxIGludGVyZmFjZSBJUCBhZGRyZXNzIGlzIDEwLjEwLjEwLjEuDQpSMidzIHJvdXRlci1p ZCBpcyAyLjIuMi4yLCBhbmQgTDEgaW50ZXJmYWNlIElQIGFkZHJlc3MgaXMgMTAuMTAuMTAuMi4N CkwxIGlzIGEgTEFOLg0KUjEgaXMgZWxlY3RlZCBhcyB0aGUgRFIgZm9yIEwxLg0KDQpUaGVyZSBh cmUgZm91ciBkaXN0aW5jdCB1bmlkaXJlY3Rpb25hbCBsaW5rcyBpbiB0aGUgdG9wb2xvZ3kgYWJv dmU6IFIxLT5EUiwgRFItPlIxLCBSMi0+RFIsIGFuZCBEUi0+UjIuIExldOKAmXMgY29uc2lkZXIg dGhlIGxpbmsgUjItPkRSLiBSMuKAmXMgcm91dGVyIExTQSByZXByZXNlbnRzIFIyLT5EUiBsaW5r IGFzIGZvbGxvd3M6IC0NCg0KQWR2ZXJ0aXNpbmcgcm91dGVyOjIuMi4yLjINCiAgIExpbmsgSUQ6 IDEwLjEwLjEwLjENCiAgIExpbmsgZGF0YToxMC4xMC4xMC4yDQogICBUeXBlOjIgKFRyYW5zaXQp DQoNCk5vdGUgdGhhdCB0aGUgT1NQRiBsaW5rIHJlcHJlc2VudGF0aW9uIGFib3ZlIGRvZXMgbm90 IGluY2x1ZGUgdGhlIHJvdXRlci1pZCBvZiB0aGUgRFIsIHdoaWNoIGlzIDEuMS4xLjEuDQoNCg0K QWNjb3JkaW5nIHRvIHRoZSB0ZXh0IGluIHNlY3Rpb24gMy4yLjEuNCwgQkdQLUxTIHJlcXVpcmVz IHVzIHRvIHJlcHJlc2VudCBSMi0+RFIgbGluayBhcyBmb2xsb3dzIChjb25zaWRlcmluZyBvbmx5 IG5vZGUgZGVzY3JpcHRvcnMgb2YgcmVsZXZhbmNlIHRvIHRoaXMgZGlzY3Vzc2lvbiwgYW5kIGln bm9yaW5nIHRoZSByZW1haW5pbmcgZmllbGRzKSA6IC0NCg0KTG9jYWwgTm9kZShJR1AtUm91dGVy LUlkOjIuMi4yLjIpIC0+IFJlbW90ZSBOb2RlKElHUC1Sb3V0ZXItSWQ6MS4xLjEuMS0xMC4xMC4x MC4xKQ0KDQoNCkhvd2V2ZXIsIHRoZSBPU1BGIHJlcHJlc2VudGF0aW9uIG9mIHRoZSBhYm92ZSBs aW5rIGluIFIy4oCZcyByb3V0ZXIgTFNBIGRvZXMgbm90IGNvbnRhaW4gMS4xLjEuMSBhdCBhbGwu IFRoZXJlZm9yZSwgQkdQLUxTIGhhcyBub3doZXJlIHRvIGRlcml2ZSDigJgxLjEuMS4x4oCZIGZy b20sIGZvciB0aGUgbGluayBSMi0+RFIuDQoNClRoZSBleGFtcGxlIGluIHNlY3Rpb24gMy43IGlz IGF0IG9kZHMgd2l0aCB0aGUgdGV4dCBpbiBzZWN0aW9uIDMuMi4xLjQsIGFuZCByZXByZXNlbnRz IHRoZSBsaW5rIGFzIGZvbGxvd3MgKHdoaWNoIHdvcmtzIHBlcmZlY3RseSk6IC0NCg0KDQpMb2Nh bCBOb2RlKElHUC1Sb3V0ZXItSWQ6Mi4yLjIuMikgLT4gUmVtb3RlIE5vZGUoSUdQLVJvdXRlci1J ZDoxMC4xMC4xMC4xLTEwLjEwLjEwLjEpDQoNCg0KSSBzdWdnZXN0IHJld29yZGluZyB0aGUgdGV4 dCBpbiAzLjIuMS40IGFzIGZvbGxvd3M6DQoNCiINCklHUCBSb3V0ZXIgSUQ6IDxzbmlwPiBGb3Ig YW4gT1NQRnYyICJQc2V1ZG9ub2RlIiByZXByZXNlbnRpbmcgYSBMQU4sDQoNCiAgICAgIHRoaXMg Y29udGFpbnMgdGhlIDQgb2N0ZXQgSVB2NCBhZGRyZXNzIG9mIHRoZSBEUidzIGludGVyZmFjZSB0 byB0aGUNCiAgICAgIExBTiwgZm9sbG93ZWQgYnkgYW55IG5vbi16ZXJvIDQtb2N0ZXQgbnVtYmVy ICg4IG9jdGV0cyBpbiB0b3RhbCkgPHNuaXA+4oCdDQoNCg0K4oCUDQpCYWxhamkgUmFqYWdvcGFs YW4NCg0KDQoNCg0KRnJvbTogVGhlIElFU0cgPGllc2ctc2VjcmV0YXJ5QGlldGYub3JnPG1haWx0 bzppZXNnLXNlY3JldGFyeUBpZXRmLm9yZz4+DQpSZXBseS1UbzogImlldGZAaWV0Zi5vcmc8bWFp bHRvOmlldGZAaWV0Zi5vcmc+IiA8aWV0ZkBpZXRmLm9yZzxtYWlsdG86aWV0ZkBpZXRmLm9yZz4+ DQpEYXRlOiBUaHVyc2RheSwgTWFyY2ggMTksIDIwMTUgYXQgMToxMCBBTQ0KVG86IElFVEYtQW5u b3VuY2UgPGlldGYtYW5ub3VuY2VAaWV0Zi5vcmc8bWFpbHRvOmlldGYtYW5ub3VuY2VAaWV0Zi5v cmc+Pg0KQ2M6ICJpZHJAaWV0Zi5vcmc8bWFpbHRvOmlkckBpZXRmLm9yZz4iIDxpZHJAaWV0Zi5v cmc8bWFpbHRvOmlkckBpZXRmLm9yZz4+DQpTdWJqZWN0OiBbSWRyXSBSRVZJU0VEIExhc3QgQ2Fs bDogPGRyYWZ0LWlldGYtaWRyLWxzLWRpc3RyaWJ1dGlvbi0xMC50eHQ+IChOb3J0aC1Cb3VuZCBE aXN0cmlidXRpb24gb2YgTGluay1TdGF0ZSBhbmQgVEUgSW5mb3JtYXRpb24gdXNpbmcgQkdQKSB0 byBQcm9wb3NlZCBTdGFuZGFyZA0KDQoNClRoZSBJRVNHIGhhcyByZWNlaXZlZCBhIHJlcXVlc3Qg ZnJvbSB0aGUgSW50ZXItRG9tYWluIFJvdXRpbmcgV0cgKGlkcikgdG8NCmNvbnNpZGVyIHRoZSBm b2xsb3dpbmcgZG9jdW1lbnQ6DQotICdOb3J0aC1Cb3VuZCBEaXN0cmlidXRpb24gb2YgTGluay1T dGF0ZSBhbmQgVEUgSW5mb3JtYXRpb24gdXNpbmcgQkdQJw0KICA8ZHJhZnQtaWV0Zi1pZHItbHMt ZGlzdHJpYnV0aW9uLTEwLnR4dD4gYXMgUHJvcG9zZWQgU3RhbmRhcmQNCg0KVGhlIElFU0cgcGxh bnMgdG8gbWFrZSBhIGRlY2lzaW9uIGluIHRoZSBuZXh0IGZldyB3ZWVrcywgYW5kIHNvbGljaXRz DQpmaW5hbCBjb21tZW50cyBvbiB0aGlzIGFjdGlvbi4gUGxlYXNlIHNlbmQgc3Vic3RhbnRpdmUg Y29tbWVudHMgdG8gdGhlDQppZXRmQGlldGYub3JnPG1haWx0bzppZXRmQGlldGYub3JnPiBtYWls aW5nIGxpc3RzIGJ5IDIwMTUtMDQtMDguIEV4Y2VwdGlvbmFsbHksIGNvbW1lbnRzIG1heSBiZQ0K c2VudCB0byBpZXNnQGlldGYub3JnPG1haWx0bzppZXNnQGlldGYub3JnPiBpbnN0ZWFkLiBJbiBl aXRoZXIgY2FzZSwgcGxlYXNlIHJldGFpbiB0aGUNCmJlZ2lubmluZyBvZiB0aGUgU3ViamVjdCBs aW5lIHRvIGFsbG93IGF1dG9tYXRlZCBzb3J0aW5nLg0KDQpBYnN0cmFjdA0KDQoNCiAgIEluIGEg bnVtYmVyIG9mIGVudmlyb25tZW50cywgYSBjb21wb25lbnQgZXh0ZXJuYWwgdG8gYSBuZXR3b3Jr IGlzDQogICBjYWxsZWQgdXBvbiB0byBwZXJmb3JtIGNvbXB1dGF0aW9ucyBiYXNlZCBvbiB0aGUg bmV0d29yayB0b3BvbG9neSBhbmQNCiAgIGN1cnJlbnQgc3RhdGUgb2YgdGhlIGNvbm5lY3Rpb25z IHdpdGhpbiB0aGUgbmV0d29yaywgaW5jbHVkaW5nDQogICB0cmFmZmljIGVuZ2luZWVyaW5nIGlu Zm9ybWF0aW9uLiAgVGhpcyBpcyBpbmZvcm1hdGlvbiB0eXBpY2FsbHkNCiAgIGRpc3RyaWJ1dGVk IGJ5IElHUCByb3V0aW5nIHByb3RvY29scyB3aXRoaW4gdGhlIG5ldHdvcmsuDQoNCiAgIFRoaXMg ZG9jdW1lbnQgZGVzY3JpYmVzIGEgbWVjaGFuaXNtIGJ5IHdoaWNoIGxpbmtzIHN0YXRlIGFuZCB0 cmFmZmljDQogICBlbmdpbmVlcmluZyBpbmZvcm1hdGlvbiBjYW4gYmUgY29sbGVjdGVkIGZyb20g bmV0d29ya3MgYW5kIHNoYXJlZA0KICAgd2l0aCBleHRlcm5hbCBjb21wb25lbnRzIHVzaW5nIHRo ZSBCR1Agcm91dGluZyBwcm90b2NvbC4gIFRoaXMgaXMNCiAgIGFjaGlldmVkIHVzaW5nIGEgbmV3 IEJHUCBOZXR3b3JrIExheWVyIFJlYWNoYWJpbGl0eSBJbmZvcm1hdGlvbg0KICAgKE5MUkkpIGVu Y29kaW5nIGZvcm1hdC4gIFRoZSBtZWNoYW5pc20gaXMgYXBwbGljYWJsZSB0byBwaHlzaWNhbCBh bmQNCiAgIHZpcnR1YWwgSUdQIGxpbmtzLiAgVGhlIG1lY2hhbmlzbSBkZXNjcmliZWQgaXMgc3Vi amVjdCB0byBwb2xpY3kNCiAgIGNvbnRyb2wuDQoNCiAgIEFwcGxpY2F0aW9ucyBvZiB0aGlzIHRl Y2huaXF1ZSBpbmNsdWRlIEFwcGxpY2F0aW9uIExheWVyIFRyYWZmaWMNCiAgIE9wdGltaXphdGlv biAoQUxUTykgc2VydmVycywgYW5kIFBhdGggQ29tcHV0YXRpb24gRWxlbWVudHMgKFBDRXMpLg0K DQoNCg0KDQoNClRoZSBmaWxlIGNhbiBiZSBvYnRhaW5lZCB2aWENCmh0dHA6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pZHItbHMtZGlzdHJpYnV0aW9uLw0KDQpJRVNHIGRp c2N1c3Npb24gY2FuIGJlIHRyYWNrZWQgdmlhDQpodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWlldGYtaWRyLWxzLWRpc3RyaWJ1dGlvbi9iYWxsb3QvDQoNCg0KVGhlIGZvbGxv d2luZyBJUFIgRGVjbGFyYXRpb25zIG1heSBiZSByZWxhdGVkIHRvIHRoaXMgSS1EOg0KDQogICBo dHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvaXByLzE4NjQvDQoNCg0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSWRyIG1haWxpbmcgbGlzdA0KSWRy QGlldGYub3JnPG1haWx0bzpJZHJAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2lkcg0KDQo= --_000_D141A386143CFaceeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <3ECB60DCB565DD448CC251BD073F7307@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5CYWxhamksJm5i c3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGlzIGlzIGFuIGltcGxlbWVudGF0 aW9uIGlzc3VlIGJhc2VkIG9uIHRoZSBmYWN0IHRoYXQgeW91IGFyZSBkZXJpdmluZyB0aGUgQkdQ IExTIGluZm9ybWF0aW9uIGZyb20gdGhlIExTQXMgcmF0aGVyIHRoYW4gaGF2aW5nIHRoZSBJR1Ag aW5zdGFsbCB0aGUgbm9ybWFsaXplZCBkcmFmdC1pZXRmLWlkci1scy1kaXN0cmlidXRpb24gbGlu a3MuIEdpdmVuIHRoYXQgdGhlIGRyYWZ0IGlzIHdpdGggdGhlIElFU0csIEnigJltIG5vdCBzdXJl IHdlDQogd2FudCB0byBhdHRlbXB0IHRvIG9wdGltaXplIGl0IHRvIHlvdXIgaW1wbGVtZW50YXRp b24gYW5kIGRpc3J1cHRpdmUgZXZlcnlvbmUgZWxzZeKAmXMuIElmIHlvdSBhcmUgbWFpbnRhaW5p bmcgdGhlIExTQXMgaW4gYW4gT1NQRiBMU0RCIHR5cGUgc3RydWN0dXJlIGluIEJHUCwgeW91IGVh c2lseSBmaW5kIHRoZSBOZXR3b3JrIExTQSBhbmQgZXh0cmFjdCB0aGUgYWR2ZXJ0aXNpbmcgcm91 dGVyLiZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhhbmtzLDwvZGl2Pg0K PGRpdj5BY2VlJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19T UkNfQk9EWV9TRUNUSU9OIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7IGZvbnQt c2l6ZToxMXB0OyB0ZXh0LWFsaWduOmxlZnQ7IGNvbG9yOmJsYWNrOyBCT1JERVItQk9UVE9NOiBt ZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6IG1lZGl1bSBub25lOyBQQURESU5HLUJPVFRPTTogMGlu OyBQQURESU5HLUxFRlQ6IDBpbjsgUEFERElORy1SSUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVj NGRmIDFwdCBzb2xpZDsgQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNw dCI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTogPC9zcGFuPkJhbGFqaSBS YWphZ29wYWxhbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJhbGFqaXJAanVuaXBlci5uZXQiPmJhbGFq aXJAanVuaXBlci5uZXQ8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xk Ij5EYXRlOiA8L3NwYW4+V2VkbmVzZGF5LCBBcHJpbCAxLCAyMDE1IGF0IDE6MDAgUE08YnI+DQo8 c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bhbj4mcXVvdDs8YSBocmVmPSJt YWlsdG86aWV0ZkBpZXRmLm9yZyI+aWV0ZkBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9 Im1haWx0bzppZXRmQGlldGYub3JnIj5pZXRmQGlldGYub3JnPC9hPiZndDssIEhhbm5lcyBHcmVk bGVyICZsdDs8YSBocmVmPSJtYWlsdG86aGFubmVzQGp1bmlwZXIubmV0Ij5oYW5uZXNAanVuaXBl ci5uZXQ8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5DYzogPC9z cGFuPiZxdW90OzxhIGhyZWY9Im1haWx0bzppZHJAaWV0Zi5vcmciPmlkckBpZXRmLm9yZzwvYT4m cXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzppZHJAaWV0Zi5vcmciPmlkckBpZXRmLm9yZzwvYT4m Z3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5S ZTogW0lkcl0gUkVWSVNFRCBMYXN0IENhbGw6ICZsdDtkcmFmdC1pZXRmLWlkci1scy1kaXN0cmli dXRpb24tMTAudHh0Jmd0OyAoTm9ydGgtQm91bmQgRGlzdHJpYnV0aW9uIG9mIExpbmstU3RhdGUg YW5kIFRFIEluZm9ybWF0aW9uIHVzaW5nIEJHUCkgdG8gUHJvcG9zZWQgU3RhbmRhcmQ8YnI+DQo8 L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRU UklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUgc29saWQ7 IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJ3 b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1s aW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigw LCAwLCAwKTsgZm9udC1mYW1pbHk6IENvbnNvbGFzLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE1 cHg7Ij4NCkkgc2VlayBhIGNvcnJlY3Rpb24gdG8gdGhlIGZvbGxvd2luZyB0ZXh0IGluIHNlY3Rp b24gMy4yLjEuNC48L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQt ZmFtaWx5OiBDb25zb2xhcywgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNXB4OyI+DQo8YnI+DQo8 L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDb25z b2xhcywgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNXB4OyI+DQomcXVvdDs8L2Rpdj4NCjxkaXYg c3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDb25zb2xhcywgc2Fucy1z ZXJpZjsgZm9udC1zaXplOiAxNXB4OyI+DQpJR1AgUm91dGVyIElEOiAmbHQ7c25pcCZndDsmbmJz cDs8c3BhbiBzdHlsZT0ibGluZS1oZWlnaHQ6IDEuMmVtOyI+Rm9yIGFuIE9TUEZ2MiAmcXVvdDtQ c2V1ZG9ub2RlJnF1b3Q7IHJlcHJlc2VudGluZyBhIExBTiw8L3NwYW4+PC9kaXY+DQo8cHJlIHN0 eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ29uc29sYXMsIHNhbnMtc2Vy aWY7IGZvbnQtc2l6ZTogMTVweDsgbGluZS1oZWlnaHQ6IDEuMmVtOyBtYXJnaW4tdG9wOiAwcHg7 IG1hcmdpbi1ib3R0b206IDBweDsiPjxmb250IGZhY2U9IkNvbnNvbGFzIj4gICAgICB0aGlzIGNv bnRhaW5zIHRoZSA0IG9jdGV0IFJvdXRlci1JRCBvZiB0aGUgZGVzaWduYXRlZCByb3V0ZXIgKERS KQ0KICAgICAgZm9sbG93ZWQgYnkgdGhlIDQgb2N0ZXQgSVB2NCBhZGRyZXNzIG9mIHRoZSBEUidz IGludGVyZmFjZSB0byB0aGUNCiAgICAgIExBTiAoOCBvY3RldHMgaW4gdG90YWwpICZsdDtzbmlw Jmd0OyZxdW90OzwvZm9udD48L3ByZT4NCjxwcmUgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7 IGZvbnQtZmFtaWx5OiBDb25zb2xhcywgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNXB4OyBsaW5l LWhlaWdodDogMS4yZW07IG1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyI+PGJy PjwvcHJlPg0KPHByZSBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENv bnNvbGFzLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE1cHg7IG1hcmdpbi10b3A6IDBweDsgbWFy Z2luLWJvdHRvbTogMHB4OyI+PGZvbnQgZmFjZT0iQ29uc29sYXMiPjxzcGFuIHN0eWxlPSJsaW5l LWhlaWdodDogMThweDsiPlRoZSByZWFzb24gSSBzZWVrIHRoaXMgY2hhbmdlIGlzLCB0PC9zcGFu PjwvZm9udD48Zm9udCBmYWNlPSJDb25zb2xhcyIgc3R5bGU9ImZvbnQtc2l6ZTogMTVweDsgbGlu ZS1oZWlnaHQ6IDEuMmVtOyI+aGUgdHJhbnNpdCBsaW5rIHJlcHJlc2VudGF0aW9uIGluIE9TUEZ2 MiByb3V0ZXItTFNBIGRvZXMgbm90IGNvbnRhaW4gdGhlIHJvdXRlci1pZCBvZiB0aGUgRFIgPC9m b250PjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDE1cHg7IGxpbmUtaGVpZ2h0OiAxLjJlbTsgZm9u dC1mYW1pbHk6IENvbnNvbGFzOyI+KHNlY3Rpb24gMTIuNC4xLjIgb2YgUkZDMjMyOCk8L3NwYW4+ PGZvbnQgZmFjZT0iQ29uc29sYXMiPjxzcGFuIHN0eWxlPSJsaW5lLWhlaWdodDogMS4yZW07Ij4u Jm5ic3A7U28sIEJHUC1MUyBoYXMgbm93aGVyZSB0byBkZXJpdmUgUm91dGVyLUlEIGZyb20uPC9z cGFuPjwvZm9udD48L3ByZT4NCjxwcmUgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQt ZmFtaWx5OiBDb25zb2xhcywgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNXB4OyBsaW5lLWhlaWdo dDogMS4yZW07IG1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiBDb25zb2xhczsgbGluZS1oZWlnaHQ6IDEuMmVtOyI+PGJyPjwvc3Bh bj48L3ByZT4NCjxwcmUgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBD b25zb2xhcywgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNXB4OyBsaW5lLWhlaWdodDogMS4yZW07 IG1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiBDb25zb2xhczsgbGluZS1oZWlnaHQ6IDEuMmVtOyI+QmVsb3cgYXJlIG1vcmUgZGV0 YWlscyB3aXRoIGFuIGV4YW1wbGUuPC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0iY29sb3I6IHJn YigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENvbnNvbGFzLCBzYW5zLXNlcmlmOyBmb250LXNpemU6 IDE1cHg7IGxpbmUtaGVpZ2h0OiAxLjJlbTsgbWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9t OiAwcHg7Ij48Zm9udCBmYWNlPSJDb25zb2xhcyI+PGJyPjwvZm9udD48L3ByZT4NCjxwcmUgc3R5 bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDb25zb2xhcywgc2Fucy1zZXJp ZjsgZm9udC1zaXplOiAxNXB4OyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsi Pjxmb250IGZhY2U9IkNvbnNvbGFzIj48c3BhbiBzdHlsZT0ibGluZS1oZWlnaHQ6IDEuMmVtOyI+ VGhlICdJR1Agcm91dGVyIElEJyBmaWVsZCBjYW4gYXBwZWFyIGVpdGhlciBpbiDigJhMb2NhbCBO b2RlIERlc2NyaXB0b3LigJkgb3Ig4oCYUmVtb3RlIE5vZGUgRGVzY3JpcHRvcuKAmS4gTGV0PC9z cGFuPjxzcGFuIHN0eWxlPSJsaW5lLWhlaWdodDogMThweDsiPuKAmTwvc3Bhbj48c3BhbiBzdHls ZT0ibGluZS1oZWlnaHQ6IDEuMmVtOyI+cyBjb25zaWRlciB0aGUgY2FzZSBpbiB3aGljaCB0aGlz IGZpZWxkIGFwcGVhcnMgaW4gPC9zcGFuPjxzcGFuIHN0eWxlPSJsaW5lLWhlaWdodDogMThweDsi PuKAmDwvc3Bhbj48c3BhbiBzdHlsZT0ibGluZS1oZWlnaHQ6IDEuMmVtOyI+UmVtb3RlIE5vZGUg RGVzY3JpcHRvcjwvc3Bhbj48c3BhbiBzdHlsZT0ibGluZS1oZWlnaHQ6IDE4cHg7Ij7igJkgaW4g dGhlIGZvbGxvd2luZyB0b3BvbG9neS48L3NwYW4+PC9mb250PjwvcHJlPg0KPHByZSBzdHlsZT0i Y29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENvbnNvbGFzLCBzYW5zLXNlcmlmOyBm b250LXNpemU6IDE1cHg7IG1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyI+PGZv bnQgZmFjZT0iQ29uc29sYXMiPjxzcGFuIHN0eWxlPSJsaW5lLWhlaWdodDogMThweDsiPjxicj48 L3NwYW4+PC9mb250PjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLXRvcDogMHB4OyBtYXJnaW4t Ym90dG9tOiAwcHg7Ij48ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWls eTogQ29uc29sYXMsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTVweDsgd2hpdGUtc3BhY2U6IG5v cm1hbDsiPlIxKDEuMS4xLjE6OjEwLjEwLjEwLjEpICZsdDstLS0tTDEtLS0tJmd0OyBSMiAoMi4y LjIuMjo6MTAuMTAuMTAuMik8L2Rpdj48ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBm b250LWZhbWlseTogQ29uc29sYXMsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTVweDsgd2hpdGUt c3BhY2U6IG5vcm1hbDsiPjxicj48L2Rpdj48ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDAp OyBmb250LWZhbWlseTogQ29uc29sYXMsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTVweDsgd2hp dGUtc3BhY2U6IG5vcm1hbDsiPldoZXJlLDwvZGl2PjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwg MCwgMCk7IGZvbnQtZmFtaWx5OiBDb25zb2xhcywgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNXB4 OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyI+UjEncyByb3V0ZXItaWQgaXMgMS4xLjEuMSwgYW5kIEwx IGludGVyZmFjZSBJUCBhZGRyZXNzIGlzIDEwLjEwLjEwLjEuPC9kaXY+PGRpdiBzdHlsZT0iY29s b3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENvbnNvbGFzLCBzYW5zLXNlcmlmOyBmb250 LXNpemU6IDE1cHg7IHdoaXRlLXNwYWNlOiBub3JtYWw7Ij5SMidzIHJvdXRlci1pZCBpcyAyLjIu Mi4yLCBhbmQgTDEgaW50ZXJmYWNlIElQIGFkZHJlc3MgaXMgMTAuMTAuMTAuMi48L2Rpdj48ZGl2 IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ29uc29sYXMsIHNhbnMt c2VyaWY7IGZvbnQtc2l6ZTogMTVweDsgd2hpdGUtc3BhY2U6IG5vcm1hbDsiPkwxIGlzIGEgTEFO LjwvZGl2PjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDb25z b2xhcywgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNXB4OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyI+ UjEgaXMgZWxlY3RlZCBhcyB0aGUgRFIgZm9yIEwxLjwvZGl2PjxkaXYgc3R5bGU9ImNvbG9yOiBy Z2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDb25zb2xhcywgc2Fucy1zZXJpZjsgZm9udC1zaXpl OiAxNXB4OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyI+PGJyPjwvZGl2PjxkaXYgc3R5bGU9ImNvbG9y OiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDb25zb2xhcywgc2Fucy1zZXJpZjsgZm9udC1z aXplOiAxNXB4OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyI+VGhlcmUgYXJlIGZvdXIgZGlzdGluY3Qg dW5pZGlyZWN0aW9uYWwgbGlua3MgaW4gdGhlIHRvcG9sb2d5IGFib3ZlOiBSMS0mZ3Q7RFIsIERS LSZndDtSMSwgUjItJmd0O0RSLCBhbmQgRFItJmd0O1IyLiBMZXTigJlzIGNvbnNpZGVyIHRoZSBs aW5rIFIyLSZndDtEUi4gUjLigJlzIHJvdXRlciBMU0EgcmVwcmVzZW50cyBSMi0mZ3Q7RFIgbGlu ayBhcyBmb2xsb3dzOiAtPC9kaXY+PHByZSBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9u dC1mYW1pbHk6IENvbnNvbGFzLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE1cHg7IG1hcmdpbi10 b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyI+PGRpdiBzdHlsZT0id2hpdGUtc3BhY2U6IG5v cm1hbDsiPjxicj48L2Rpdj48ZGl2IHN0eWxlPSJ3aGl0ZS1zcGFjZTogbm9ybWFsOyI+QWR2ZXJ0 aXNpbmcgcm91dGVyOjIuMi4yLjI8L2Rpdj48ZGl2IHN0eWxlPSJ3aGl0ZS1zcGFjZTogbm9ybWFs OyI+Jm5ic3A7ICZuYnNwO0xpbmsgSUQ6IDEwLjEwLjEwLjE8L2Rpdj48ZGl2IHN0eWxlPSJ3aGl0 ZS1zcGFjZTogbm9ybWFsOyI+Jm5ic3A7ICZuYnNwO0xpbmsgZGF0YToxMC4xMC4xMC4yPC9kaXY+ PGRpdiBzdHlsZT0id2hpdGUtc3BhY2U6IG5vcm1hbDsiPiZuYnNwOyAmbmJzcDtUeXBlOjIgKFRy YW5zaXQpPC9kaXY+PC9wcmU+PGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1m YW1pbHk6IENvbnNvbGFzLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE1cHg7IHdoaXRlLXNwYWNl OiBub3JtYWw7Ij48YnI+PC9kaXY+PGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9u dC1mYW1pbHk6IENvbnNvbGFzLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE1cHg7IHdoaXRlLXNw YWNlOiBub3JtYWw7Ij5Ob3RlIHRoYXQgdGhlIE9TUEYgbGluayByZXByZXNlbnRhdGlvbiBhYm92 ZSBkb2VzIG5vdCBpbmNsdWRlIHRoZSByb3V0ZXItaWQgb2YgdGhlIERSLCB3aGljaCBpcyAxLjEu MS4xLjwvZGl2PjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBD b25zb2xhcywgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNXB4OyB3aGl0ZS1zcGFjZTogbm9ybWFs OyI+PGJyPjwvZGl2PjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5 OiBDb25zb2xhcywgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNXB4OyB3aGl0ZS1zcGFjZTogbm9y bWFsOyI+PHByZSBzdHlsZT0ibWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7Ij48 ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ29uc29sYXMsIHNhbnMtc2VyaWY7IHdoaXRlLXNwYWNl OiBub3JtYWw7Ij5BY2NvcmRpbmcgdG8gdGhlIHRleHQgaW4gc2VjdGlvbiAzLjIuMS40LCBCR1At TFMgcmVxdWlyZXMgdXMgdG8gcmVwcmVzZW50IFIyLSZndDtEUiBsaW5rIGFzIGZvbGxvd3MgKGNv bnNpZGVyaW5nIG9ubHkgbm9kZSBkZXNjcmlwdG9ycyBvZiByZWxldmFuY2UgdG8gdGhpcyBkaXNj dXNzaW9uLCBhbmQgaWdub3JpbmcgdGhlIHJlbWFpbmluZyBmaWVsZHMpIDogLTwvZGl2PjxkaXYg c3R5bGU9ImZvbnQtZmFtaWx5OiBDb25zb2xhcywgc2Fucy1zZXJpZjsgd2hpdGUtc3BhY2U6IG5v cm1hbDsiPjxicj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ29uc29sYXMsIHNhbnMt c2VyaWY7IHdoaXRlLXNwYWNlOiBub3JtYWw7Ij5Mb2NhbCBOb2RlKElHUC1Sb3V0ZXItSWQ6Mi4y LjIuMikgLSZndDsgUmVtb3RlIE5vZGUoSUdQLVJvdXRlci1JZDoxLjEuMS4xLTEwLjEwLjEwLjEp PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENvbnNvbGFzLCBzYW5zLXNlcmlmOyB3aGl0 ZS1zcGFjZTogbm9ybWFsOyI+PGJyPjwvZGl2PjwvcHJlPjwvZGl2PjxkaXYgc3R5bGU9ImNvbG9y OiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDb25zb2xhcywgc2Fucy1zZXJpZjsgZm9udC1z aXplOiAxNXB4OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyI+SG93ZXZlciwgdGhlIE9TUEYgcmVwcmVz ZW50YXRpb24gb2YgdGhlIGFib3ZlIGxpbmsgaW4gUjLigJlzIHJvdXRlciBMU0EgZG9lcyBub3Qg Y29udGFpbiAxLjEuMS4xIGF0IGFsbC4gVGhlcmVmb3JlLCBCR1AtTFMgaGFzIG5vd2hlcmUgdG8g ZGVyaXZlIOKAmDEuMS4xLjHigJkgZnJvbSwgZm9yIHRoZSBsaW5rIFIyLSZndDtEUi48L2Rpdj48 ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ29uc29sYXMsIHNh bnMtc2VyaWY7IGZvbnQtc2l6ZTogMTVweDsgd2hpdGUtc3BhY2U6IG5vcm1hbDsiPjxicj48L2Rp dj48ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ29uc29sYXMs IHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTVweDsgd2hpdGUtc3BhY2U6IG5vcm1hbDsiPlRoZSBl eGFtcGxlIGluIHNlY3Rpb24gMy43IGlzIGF0IG9kZHMgd2l0aCB0aGUgdGV4dCBpbiBzZWN0aW9u IDMuMi4xLjQsIGFuZCByZXByZXNlbnRzIHRoZSBsaW5rIGFzIGZvbGxvd3MgKHdoaWNoIHdvcmtz IHBlcmZlY3RseSk6IC08L2Rpdj48ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250 LWZhbWlseTogQ29uc29sYXMsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTVweDsgd2hpdGUtc3Bh Y2U6IG5vcm1hbDsiPjxicj48L2Rpdj48ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBm b250LWZhbWlseTogQ29uc29sYXMsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTVweDsgd2hpdGUt c3BhY2U6IG5vcm1hbDsiPjxwcmUgc3R5bGU9Im1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRv bTogMHB4OyI+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENvbnNvbGFzLCBzYW5zLXNlcmlmOyB3 aGl0ZS1zcGFjZTogbm9ybWFsOyI+TG9jYWwgTm9kZShJR1AtUm91dGVyLUlkOjIuMi4yLjIpIC0m Z3Q7IFJlbW90ZSBOb2RlKElHUC1Sb3V0ZXItSWQ6MTAuMTAuMTAuMS0xMC4xMC4xMC4xKTwvZGl2 PjxkaXY+PGJyPjwvZGl2PjwvcHJlPjwvZGl2PjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwg MCk7IGZvbnQtZmFtaWx5OiBDb25zb2xhcywgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNXB4OyB3 aGl0ZS1zcGFjZTogbm9ybWFsOyI+SSBzdWdnZXN0IHJld29yZGluZyB0aGUgdGV4dCBpbiAzLjIu MS40IGFzIGZvbGxvd3M6Jm5ic3A7PC9kaXY+PGRpdj48cHJlIHN0eWxlPSJtYXJnaW4tdG9wOiAw cHg7IG1hcmdpbi1ib3R0b206IDBweDsiPjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7 IGZvbnQtZmFtaWx5OiBDb25zb2xhcywgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNXB4OyB3aGl0 ZS1zcGFjZTogbm9ybWFsOyI+PGJyPjwvZGl2PjxkaXY+PGRpdiBzdHlsZT0iY29sb3I6IHJnYigw LCAwLCAwKTsgZm9udC1mYW1pbHk6IENvbnNvbGFzLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE1 cHg7IHdoaXRlLXNwYWNlOiBub3JtYWw7Ij4mcXVvdDs8L2Rpdj48ZGl2IHN0eWxlPSJjb2xvcjog cmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ29uc29sYXMsIHNhbnMtc2VyaWY7IGZvbnQtc2l6 ZTogMTVweDsgd2hpdGUtc3BhY2U6IG5vcm1hbDsiPklHUCBSb3V0ZXIgSUQ6ICZsdDtzbmlwJmd0 OyZuYnNwOzxzcGFuIHN0eWxlPSJsaW5lLWhlaWdodDogMS4yZW07Ij5Gb3IgYW4gT1NQRnYyICZx dW90O1BzZXVkb25vZGUmcXVvdDsgcmVwcmVzZW50aW5nIGEgTEFOLDwvc3Bhbj48L2Rpdj48cHJl IHN0eWxlPSJtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsiPjxmb250IGZhY2U9 IkNvbnNvbGFzIiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENvbnNv bGFzLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE1cHg7IGxpbmUtaGVpZ2h0OiAxLjJlbTsgd2hp dGUtc3BhY2U6IG5vcm1hbDsiPiAgICAgIHRoaXMgY29udGFpbnMgdGhlIDQgb2N0ZXQgSVB2NCBh ZGRyZXNzIG9mIHRoZSBEUidzIGludGVyZmFjZSB0byB0aGUNCiAgICAgIExBTiwgZm9sbG93ZWQg YnkgYW55IG5vbi16ZXJvIDQtb2N0ZXQgbnVtYmVyICg4IG9jdGV0cyBpbiB0b3RhbCkgJmx0O3Nu aXAmZ3Q7PC9mb250Pjxmb250IGZhY2U9IkNvbnNvbGFzIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OiAxNXB4OyBsaW5lLWhlaWdodDogMThweDsiPuKAnTwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZSBz dHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENvbnNvbGFzLCBzYW5zLXNl cmlmOyBmb250LXNpemU6IDE1cHg7IHdoaXRlLXNwYWNlOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiAx LjJlbTsgbWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7Ij48Zm9udCBmYWNlPSJD b25zb2xhcyI+PGJyPjwvZm9udD48L3ByZT48L2Rpdj48L3ByZT48L2Rpdj48ZGl2IHN0eWxlPSJj b2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ29uc29sYXMsIHNhbnMtc2VyaWY7IGZv bnQtc2l6ZTogMTVweDsgd2hpdGUtc3BhY2U6IG5vcm1hbDsiPuKAlDwvZGl2PjxkaXYgc3R5bGU9 ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDb25zb2xhcywgc2Fucy1zZXJpZjsg Zm9udC1zaXplOiAxNXB4OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyI+QmFsYWppIFJhamFnb3BhbGFu PC9kaXY+PGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENvbnNv bGFzLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE1cHg7IHdoaXRlLXNwYWNlOiBub3JtYWw7Ij48 YnI+PC9kaXY+PGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENv bnNvbGFzLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE1cHg7IHdoaXRlLXNwYWNlOiBub3JtYWw7 Ij48YnI+PC9kaXY+PC9wcmU+DQo8cHJlIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250 LWZhbWlseTogQ29uc29sYXMsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTVweDsgbGluZS1oZWln aHQ6IDEuMmVtOyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsiPjxicj48L3By ZT4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDb25zb2xh cywgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNXB4OyI+DQo8YnI+DQo8L2Rpdj4NCjxzcGFuIGlk PSJPTEtfU1JDX0JPRFlfU0VDVElPTiIgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQt ZmFtaWx5OiBDb25zb2xhcywgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNXB4OyI+DQo8ZGl2IHN0 eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTFwdDsgdGV4dC1hbGlnbjpsZWZ0 OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBt ZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1MRUZUOiAwaW47IFBBRERJ TkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdI VDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2Vp Z2h0OmJvbGQiPkZyb206IDwvc3Bhbj5UaGUgSUVTRyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmllc2ct c2VjcmV0YXJ5QGlldGYub3JnIj5pZXNnLXNlY3JldGFyeUBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0K PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlJlcGx5LVRvOiA8L3NwYW4+JnF1b3Q7PGEg aHJlZj0ibWFpbHRvOmlldGZAaWV0Zi5vcmciPmlldGZAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8 YSBocmVmPSJtYWlsdG86aWV0ZkBpZXRmLm9yZyI+aWV0ZkBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0K PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5UaHVyc2RheSwgTWFy Y2ggMTksIDIwMTUgYXQgMToxMCBBTTxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xk Ij5UbzogPC9zcGFuPklFVEYtQW5ub3VuY2UgJmx0OzxhIGhyZWY9Im1haWx0bzppZXRmLWFubm91 bmNlQGlldGYub3JnIj5pZXRmLWFubm91bmNlQGlldGYub3JnPC9hPiZndDs8YnI+DQo8c3BhbiBz dHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+Q2M6IDwvc3Bhbj4mcXVvdDs8YSBocmVmPSJtYWlsdG86 aWRyQGlldGYub3JnIj5pZHJAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86 aWRyQGlldGYub3JnIj5pZHJAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250 LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+W0lkcl0gUkVWSVNFRCBMYXN0IENhbGw6ICZs dDtkcmFmdC1pZXRmLWlkci1scy1kaXN0cmlidXRpb24tMTAudHh0Jmd0OyAoTm9ydGgtQm91bmQg RGlzdHJpYnV0aW9uIG9mIExpbmstU3RhdGUgYW5kIFRFIEluZm9ybWF0aW9uIHVzaW5nIEJHUCkg dG8gUHJvcG9zZWQgU3RhbmRhcmQ8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJP UkRFUi1MRUZUOiAjYjVjNGRmIDUgc29saWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAw IDU7Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhlIElFU0cgaGFz IHJlY2VpdmVkIGEgcmVxdWVzdCBmcm9tIHRoZSBJbnRlci1Eb21haW4gUm91dGluZyBXRyAoaWRy KSB0bzwvZGl2Pg0KPGRpdj5jb25zaWRlciB0aGUgZm9sbG93aW5nIGRvY3VtZW50OjwvZGl2Pg0K PGRpdj4tICdOb3J0aC1Cb3VuZCBEaXN0cmlidXRpb24gb2YgTGluay1TdGF0ZSBhbmQgVEUgSW5m b3JtYXRpb24gdXNpbmcgQkdQJzwvZGl2Pg0KPGRpdj4mbmJzcDsmbmJzcDsmbHQ7ZHJhZnQtaWV0 Zi1pZHItbHMtZGlzdHJpYnV0aW9uLTEwLnR4dCZndDsgYXMgUHJvcG9zZWQgU3RhbmRhcmQ8L2Rp dj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoZSBJRVNHIHBsYW5zIHRvIG1ha2UgYSBkZWNp c2lvbiBpbiB0aGUgbmV4dCBmZXcgd2Vla3MsIGFuZCBzb2xpY2l0czwvZGl2Pg0KPGRpdj5maW5h bCBjb21tZW50cyBvbiB0aGlzIGFjdGlvbi4gUGxlYXNlIHNlbmQgc3Vic3RhbnRpdmUgY29tbWVu dHMgdG8gdGhlPC9kaXY+DQo8ZGl2PjxhIGhyZWY9Im1haWx0bzppZXRmQGlldGYub3JnIj5pZXRm QGlldGYub3JnPC9hPiBtYWlsaW5nIGxpc3RzIGJ5IDIwMTUtMDQtMDguIEV4Y2VwdGlvbmFsbHks IGNvbW1lbnRzIG1heSBiZTwvZGl2Pg0KPGRpdj5zZW50IHRvIDxhIGhyZWY9Im1haWx0bzppZXNn QGlldGYub3JnIj5pZXNnQGlldGYub3JnPC9hPiBpbnN0ZWFkLiBJbiBlaXRoZXIgY2FzZSwgcGxl YXNlIHJldGFpbiB0aGU8L2Rpdj4NCjxkaXY+YmVnaW5uaW5nIG9mIHRoZSBTdWJqZWN0IGxpbmUg dG8gYWxsb3cgYXV0b21hdGVkIHNvcnRpbmcuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRp dj5BYnN0cmFjdDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8 ZGl2PiZuYnNwOyZuYnNwOyBJbiBhIG51bWJlciBvZiBlbnZpcm9ubWVudHMsIGEgY29tcG9uZW50 IGV4dGVybmFsIHRvIGEgbmV0d29yayBpczwvZGl2Pg0KPGRpdj4mbmJzcDsmbmJzcDsgY2FsbGVk IHVwb24gdG8gcGVyZm9ybSBjb21wdXRhdGlvbnMgYmFzZWQgb24gdGhlIG5ldHdvcmsgdG9wb2xv Z3kgYW5kPC9kaXY+DQo8ZGl2PiZuYnNwOyZuYnNwOyBjdXJyZW50IHN0YXRlIG9mIHRoZSBjb25u ZWN0aW9ucyB3aXRoaW4gdGhlIG5ldHdvcmssIGluY2x1ZGluZzwvZGl2Pg0KPGRpdj4mbmJzcDsm bmJzcDsgdHJhZmZpYyBlbmdpbmVlcmluZyBpbmZvcm1hdGlvbi4mbmJzcDsmbmJzcDtUaGlzIGlz IGluZm9ybWF0aW9uIHR5cGljYWxseTwvZGl2Pg0KPGRpdj4mbmJzcDsmbmJzcDsgZGlzdHJpYnV0 ZWQgYnkgSUdQIHJvdXRpbmcgcHJvdG9jb2xzIHdpdGhpbiB0aGUgbmV0d29yay48L2Rpdj4NCjxk aXY+PGJyPg0KPC9kaXY+DQo8ZGl2PiZuYnNwOyZuYnNwOyBUaGlzIGRvY3VtZW50IGRlc2NyaWJl cyBhIG1lY2hhbmlzbSBieSB3aGljaCBsaW5rcyBzdGF0ZSBhbmQgdHJhZmZpYzwvZGl2Pg0KPGRp dj4mbmJzcDsmbmJzcDsgZW5naW5lZXJpbmcgaW5mb3JtYXRpb24gY2FuIGJlIGNvbGxlY3RlZCBm cm9tIG5ldHdvcmtzIGFuZCBzaGFyZWQ8L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7IHdpdGggZXh0 ZXJuYWwgY29tcG9uZW50cyB1c2luZyB0aGUgQkdQIHJvdXRpbmcgcHJvdG9jb2wuJm5ic3A7Jm5i c3A7VGhpcyBpczwvZGl2Pg0KPGRpdj4mbmJzcDsmbmJzcDsgYWNoaWV2ZWQgdXNpbmcgYSBuZXcg QkdQIE5ldHdvcmsgTGF5ZXIgUmVhY2hhYmlsaXR5IEluZm9ybWF0aW9uPC9kaXY+DQo8ZGl2PiZu YnNwOyZuYnNwOyAoTkxSSSkgZW5jb2RpbmcgZm9ybWF0LiZuYnNwOyZuYnNwO1RoZSBtZWNoYW5p c20gaXMgYXBwbGljYWJsZSB0byBwaHlzaWNhbCBhbmQ8L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7 IHZpcnR1YWwgSUdQIGxpbmtzLiZuYnNwOyZuYnNwO1RoZSBtZWNoYW5pc20gZGVzY3JpYmVkIGlz IHN1YmplY3QgdG8gcG9saWN5PC9kaXY+DQo8ZGl2PiZuYnNwOyZuYnNwOyBjb250cm9sLjwvZGl2 Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7IEFwcGxpY2F0aW9ucyBvZiB0 aGlzIHRlY2huaXF1ZSBpbmNsdWRlIEFwcGxpY2F0aW9uIExheWVyIFRyYWZmaWM8L2Rpdj4NCjxk aXY+Jm5ic3A7Jm5ic3A7IE9wdGltaXphdGlvbiAoQUxUTykgc2VydmVycywgYW5kIFBhdGggQ29t cHV0YXRpb24gRWxlbWVudHMgKFBDRXMpLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+ PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+ PGJyPg0KPC9kaXY+DQo8ZGl2PlRoZSBmaWxlIGNhbiBiZSBvYnRhaW5lZCB2aWE8L2Rpdj4NCjxk aXY+PGEgaHJlZj0iaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWlk ci1scy1kaXN0cmlidXRpb24vIj5odHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWlldGYtaWRyLWxzLWRpc3RyaWJ1dGlvbi88L2E+PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0K PGRpdj5JRVNHIGRpc2N1c3Npb24gY2FuIGJlIHRyYWNrZWQgdmlhPC9kaXY+DQo8ZGl2PjxhIGhy ZWY9Imh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pZHItbHMtZGlz dHJpYnV0aW9uL2JhbGxvdC8iPmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt aWV0Zi1pZHItbHMtZGlzdHJpYnV0aW9uL2JhbGxvdC88L2E+PC9kaXY+DQo8ZGl2Pjxicj4NCjwv ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhlIGZvbGxvd2luZyBJUFIgRGVjbGFyYXRp b25zIG1heSBiZSByZWxhdGVkIHRvIHRoaXMgSS1EOjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N CjxkaXY+Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9p cHIvMTg2NC8iPmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9pcHIvMTg2NC88L2E+PC9kaXY+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+ DQo8ZGl2Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9k aXY+DQo8ZGl2PklkciBtYWlsaW5nIGxpc3Q8L2Rpdj4NCjxkaXY+PGEgaHJlZj0ibWFpbHRvOklk ckBpZXRmLm9yZyI+SWRyQGlldGYub3JnPC9hPjwvZGl2Pg0KPGRpdj48YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkciI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9pZHI8L2E+PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9zcGFuPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_D141A386143CFaceeciscocom_-- From nobody Wed Apr 1 14:28:45 2015 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 0EE1F1A1BBD for ; Wed, 1 Apr 2015 14:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OOMfsH2MUBSY for ; Wed, 1 Apr 2015 14:28:39 -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 C1AC31A19F4 for ; Wed, 1 Apr 2015 14:28:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1314; q=dns/txt; s=iport; t=1427923718; x=1429133318; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=Dwei8TNrNcm49EOT/bzupwjvSXQzhFf831zRKStvBJA=; b=mKFnw0cljC/MLzPnnzSWYQQ+tfToBw33mUGJWQiVafV+mEbNS6rA5fIO jX2JdKpTgUsRf8ClSV6O+VhEdCOzXuo3UBuAxxLzvP5Xjt1EIg5dqa1+X bgiO8eL8dOXOqVYNRXjlB4L9AWd/s+jryJ9KPDQPJMYMzatBHiLIoJM1Z k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A2BQBfYhxV/4wNJK1cgwaBM4MQyF6BI0wBAQEBAQF9hBsjEVcBIgImAgQwFRIEiEKmHI9MmQcBAQEHAgEfgSGRcIFFBZBjiXaUQCKCAhyBUIIzfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,506,1422921600"; d="scan'208";a="137480424" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-5.cisco.com with ESMTP; 01 Apr 2015 21:28:38 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t31LSbbT025835 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 1 Apr 2015 21:28:38 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.236]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Wed, 1 Apr 2015 16:28:37 -0500 From: "Acee Lindem (acee)" To: "idr@ietf.org" Thread-Topic: Comments on draft-gredler-idr-bgp-ls-segment-routing-extension-02 Thread-Index: AQHQbMLQLghwfaicKEW/k6zyKoMwAg== Date: Wed, 1 Apr 2015 21:28:37 +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="utf-8" Content-ID: <6065FB8F680C864181FB9FBA2595B8D6@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [Idr] Comments on draft-gredler-idr-bgp-ls-segment-routing-extension-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: Wed, 01 Apr 2015 21:28:43 -0000 SGkgSGFubmVzLCBldCBhbCwgDQoNClVzaW5nIHRoZSBJUy1JUyBTZWdtZW50IFJvdXRpbmcgZW5j b2RpbmdzIGRpcmVjdGx5IGlzIHByb2JsZW0gc2luY2UgdGhlDQpJUy1JUyBhbmQgT1NQRiBlbmNv ZGluZ3MgYXJlIG5vdCBpZGVudGljYWwuIEluIGZhY3QsIGZvciB0aGUgTEFOIGFkamFjZW5jeQ0K U0lELCB0aGV5IGNhbm5vdCBiZSBpZGVudGljYWwgc2luY2UgdGhlIHByb3RvY29scyBkbyBub3Qg dXNlIHRoZSBzYW1lDQppZGVudGlmaWVycy4gQWRkaXRpb25hbGx5LCBkb2luZyB0aGlzIGludGVy LVdHIHJlYWxseSBkZWZlYXRzIHRoZSBvbmUgb2YNCnRoZSBtYWluIGRlc2lnbiB0ZW5ldHMgb2Yg QkdQIExTIERpc3RyaWJ1dGlvbi4gRXhjZXJwdCBmcm9tIHNlY3Rpb24gMyBvZg0KZHJhZnQtaWV0 Zi1pZHItbHMtZGlzdHJpYnV0aW9uLTEwLnR4dC4NCg0KICAgSXQgaXMgZGVzaXJlZCB0byBrZWVw IHRoZSBkZXBlbmRlbmNpZXMgb24gdGhlIHByb3RvY29sIHNvdXJjZSBvZiB0aGlzDQogICBhdHRy aWJ1dGVzIHRvIGEgbWluaW11bSBhbmQgcmVwcmVzZW50IGFueSBjb250ZW50IGluIGFuIElHUCBu ZXV0cmFsDQogICB3YXksIHN1Y2ggdGhhdCBhcHBsaWNhdGlvbnMgd2hpY2ggZG8gd2FudCB0byBs ZWFybiBhYm91dCBhIExpbmstc3RhdGUNCiAgIHRvcG9sb2d5IGRvIG5vdCBuZWVkIHRvIGtub3cg YWJvdXQgYW55IE9TUEYgb3IgSVMtSVMgcHJvdG9jb2wNCiAgIHNwZWNpZmljcy4NCg0KSSB3b3Vs ZCByZXF1ZXN0IHRoYXQgeW91IGRvIHRoZSBzYW1lIGZvciB0aGUgU2VnbWVudCBSb3V0aW5nIFRM VnMgcmF0aGVyDQp0aGFuIGhhdmluZyB0aGUgbm9ybWF0aXZlIHJlZmVyZW5jZXMgdG8gdGhlIElT LUlTIHNlZ21lbnQgcm91dGluZyBkcmFmdC4gSQ0Kd291bGQgbm90IHN1cHBvcnQgV0cgYWRvcHRp b24gaW4gaXRzIGN1cnJlbnQgZm9ybS4NCg0KVGhhbmtzLA0KQWNlZQ0KDQoNCg0K From nobody Wed Apr 1 20:27:08 2015 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 A1CD01AD2EC; Wed, 1 Apr 2015 20:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YCz2oDvC0ypu; Wed, 1 Apr 2015 20:27:03 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0790.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::790]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C0EA1A86F6; Wed, 1 Apr 2015 20:27:02 -0700 (PDT) Received: from BN1PR05MB535.namprd05.prod.outlook.com (10.141.65.155) by BN1PR05MB440.namprd05.prod.outlook.com (10.141.58.26) with Microsoft SMTP Server (TLS) id 15.1.125.19; Thu, 2 Apr 2015 03:26:43 +0000 Received: from BN1PR05MB535.namprd05.prod.outlook.com ([169.254.8.244]) by BN1PR05MB535.namprd05.prod.outlook.com ([169.254.8.244]) with mapi id 15.01.0118.022; Thu, 2 Apr 2015 03:26:43 +0000 From: Balaji Rajagopalan To: "Acee Lindem (acee)" , "ietf@ietf.org" , Hannes Gredler Thread-Topic: [Idr] REVISED Last Call: (North-Bound Distribution of Link-State and TE Information using BGP) to Proposed Standard Thread-Index: AQHQYbN1sBT99RQ7ME2g+UypTJek+p04078A//+/7ICAAO8fAA== Date: Thu, 2 Apr 2015 03:26:43 +0000 Message-ID: References: <20150318194048.32558.12168.idtracker@ietfa.amsl.com> 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.8.150116 x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [116.197.184.11] authentication-results: cisco.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB440; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(377454003)(164054003)(106116001)(77156002)(62966003)(86362001)(66066001)(83506001)(19617315012)(50986999)(46102003)(2656002)(87936001)(19580395003)(19580405001)(76176999)(54356999)(16236675004)(122556002)(36756003)(92566002)(2900100001)(15975445007)(230783001)(102836002)(2950100001)(2501003)(40100003)(24704002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB440; H:BN1PR05MB535.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:BN1PR05MB440; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB440; x-forefront-prvs: 0534947130 Content-Type: multipart/alternative; boundary="_000_D142ADD412F49balajirjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Apr 2015 03:26:43.6680 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB440 Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] REVISED Last Call: (North-Bound Distribution of Link-State and TE Information using BGP) to Proposed Standard 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, 02 Apr 2015 03:27:07 -0000 --_000_D142ADD412F49balajirjunipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWNlZSwNCg0KSSBhbHNvIHBvaW50ZWQgb3V0IGFuIGluY29uc2lzdGVuY3kgYmV0d2VlbiB0 aGUgZXhhbXBsZSBpbiBzZWN0aW9uIDMuNyBhbmQgdGhlIG5vcm1hdGl2ZSB0ZXh0IGluIHNlY3Rp b24gMy4yLjEuNC4gU28sIHRoZSBkcmFmdCBuZWVkcyBhIGNvcnJlY3Rpb24gYW55d2F5Lg0KDQpU aGUgcXVlc3Rpb24gaXMsIHdoaWNoIG9uZSBuZWVkcyB0byBiZSBjb3JyZWN0ZWQg4oCTIHNlY3Rp b24gMy43LCBvciBzZWN0aW9uIDMuMi4xLjQuDQoNCklNSE8sIHdlIHNob3VsZCBjb3JyZWN0IHRo ZSBub3JtYXRpdmUgdGV4dCBpbiBzZWN0aW9uIDMuMi4xLjQgdG8gYWxpZ24gd2l0aCB0aGUgZXhh bXBsZSBpbiBzZWN0aW9uIDMuNywgYXMgdGhlIGV4YW1wbGUgbW9yZSBjbG9zZWx5IHJlZmxlY3Rz IGhvdyBPU1BGdjIgcmVwcmVzZW50cyB0aGUgbGluay4NCg0K4oCUDQpCYWxhamkgUmFqYWdvcGFs YW4NCg0KDQpGcm9tOiAiQWNlZSBMaW5kZW0gKGFjZWUpIiA8YWNlZUBjaXNjby5jb208bWFpbHRv OmFjZWVAY2lzY28uY29tPj4NCkRhdGU6IFdlZG5lc2RheSwgQXByaWwgMSwgMjAxNSBhdCAxMTox MSBQTQ0KVG86IEJhbGFqaSBSYWphZ29wYWxhbiA8YmFsYWppckBqdW5pcGVyLm5ldDxtYWlsdG86 YmFsYWppckBqdW5pcGVyLm5ldD4+LCAiaWV0ZkBpZXRmLm9yZzxtYWlsdG86aWV0ZkBpZXRmLm9y Zz4iIDxpZXRmQGlldGYub3JnPG1haWx0bzppZXRmQGlldGYub3JnPj4sIEhhbm5lcyBHcmVkbGVy IDxoYW5uZXNAanVuaXBlci5uZXQ8bWFpbHRvOmhhbm5lc0BqdW5pcGVyLm5ldD4+DQpDYzogImlk ckBpZXRmLm9yZzxtYWlsdG86aWRyQGlldGYub3JnPiIgPGlkckBpZXRmLm9yZzxtYWlsdG86aWRy QGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbSWRyXSBSRVZJU0VEIExhc3QgQ2FsbDogPGRyYWZ0 LWlldGYtaWRyLWxzLWRpc3RyaWJ1dGlvbi0xMC50eHQ+IChOb3J0aC1Cb3VuZCBEaXN0cmlidXRp b24gb2YgTGluay1TdGF0ZSBhbmQgVEUgSW5mb3JtYXRpb24gdXNpbmcgQkdQKSB0byBQcm9wb3Nl ZCBTdGFuZGFyZA0KDQpCYWxhamksDQoNClRoaXMgaXMgYW4gaW1wbGVtZW50YXRpb24gaXNzdWUg YmFzZWQgb24gdGhlIGZhY3QgdGhhdCB5b3UgYXJlIGRlcml2aW5nIHRoZSBCR1AgTFMgaW5mb3Jt YXRpb24gZnJvbSB0aGUgTFNBcyByYXRoZXIgdGhhbiBoYXZpbmcgdGhlIElHUCBpbnN0YWxsIHRo ZSBub3JtYWxpemVkIGRyYWZ0LWlldGYtaWRyLWxzLWRpc3RyaWJ1dGlvbiBsaW5rcy4gR2l2ZW4g dGhhdCB0aGUgZHJhZnQgaXMgd2l0aCB0aGUgSUVTRywgSeKAmW0gbm90IHN1cmUgd2Ugd2FudCB0 byBhdHRlbXB0IHRvIG9wdGltaXplIGl0IHRvIHlvdXIgaW1wbGVtZW50YXRpb24gYW5kIGRpc3J1 cHRpdmUgZXZlcnlvbmUgZWxzZeKAmXMuIElmIHlvdSBhcmUgbWFpbnRhaW5pbmcgdGhlIExTQXMg aW4gYW4gT1NQRiBMU0RCIHR5cGUgc3RydWN0dXJlIGluIEJHUCwgeW91IGVhc2lseSBmaW5kIHRo ZSBOZXR3b3JrIExTQSBhbmQgZXh0cmFjdCB0aGUgYWR2ZXJ0aXNpbmcgcm91dGVyLg0KDQpUaGFu a3MsDQpBY2VlDQoNCkZyb206IEJhbGFqaSBSYWphZ29wYWxhbiA8YmFsYWppckBqdW5pcGVyLm5l dDxtYWlsdG86YmFsYWppckBqdW5pcGVyLm5ldD4+DQpEYXRlOiBXZWRuZXNkYXksIEFwcmlsIDEs IDIwMTUgYXQgMTowMCBQTQ0KVG86ICJpZXRmQGlldGYub3JnPG1haWx0bzppZXRmQGlldGYub3Jn PiIgPGlldGZAaWV0Zi5vcmc8bWFpbHRvOmlldGZAaWV0Zi5vcmc+PiwgSGFubmVzIEdyZWRsZXIg PGhhbm5lc0BqdW5pcGVyLm5ldDxtYWlsdG86aGFubmVzQGp1bmlwZXIubmV0Pj4NCkNjOiAiaWRy QGlldGYub3JnPG1haWx0bzppZHJAaWV0Zi5vcmc+IiA8aWRyQGlldGYub3JnPG1haWx0bzppZHJA aWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtJZHJdIFJFVklTRUQgTGFzdCBDYWxsOiA8ZHJhZnQt aWV0Zi1pZHItbHMtZGlzdHJpYnV0aW9uLTEwLnR4dD4gKE5vcnRoLUJvdW5kIERpc3RyaWJ1dGlv biBvZiBMaW5rLVN0YXRlIGFuZCBURSBJbmZvcm1hdGlvbiB1c2luZyBCR1ApIHRvIFByb3Bvc2Vk IFN0YW5kYXJkDQoNCkkgc2VlayBhIGNvcnJlY3Rpb24gdG8gdGhlIGZvbGxvd2luZyB0ZXh0IGlu IHNlY3Rpb24gMy4yLjEuNC4NCg0KIg0KSUdQIFJvdXRlciBJRDogPHNuaXA+IEZvciBhbiBPU1BG djIgIlBzZXVkb25vZGUiIHJlcHJlc2VudGluZyBhIExBTiwNCg0KICAgICAgdGhpcyBjb250YWlu cyB0aGUgNCBvY3RldCBSb3V0ZXItSUQgb2YgdGhlIGRlc2lnbmF0ZWQgcm91dGVyIChEUikNCiAg ICAgIGZvbGxvd2VkIGJ5IHRoZSA0IG9jdGV0IElQdjQgYWRkcmVzcyBvZiB0aGUgRFIncyBpbnRl cmZhY2UgdG8gdGhlDQogICAgICBMQU4gKDggb2N0ZXRzIGluIHRvdGFsKSA8c25pcD4iDQoNCg0K VGhlIHJlYXNvbiBJIHNlZWsgdGhpcyBjaGFuZ2UgaXMsIHRoZSB0cmFuc2l0IGxpbmsgcmVwcmVz ZW50YXRpb24gaW4gT1NQRnYyIHJvdXRlci1MU0EgZG9lcyBub3QgY29udGFpbiB0aGUgcm91dGVy LWlkIG9mIHRoZSBEUiAoc2VjdGlvbiAxMi40LjEuMiBvZiBSRkMyMzI4KS4gU28sIEJHUC1MUyBo YXMgbm93aGVyZSB0byBkZXJpdmUgUm91dGVyLUlEIGZyb20uDQoNCg0KQmVsb3cgYXJlIG1vcmUg ZGV0YWlscyB3aXRoIGFuIGV4YW1wbGUuDQoNCg0KVGhlICdJR1Agcm91dGVyIElEJyBmaWVsZCBj YW4gYXBwZWFyIGVpdGhlciBpbiDigJhMb2NhbCBOb2RlIERlc2NyaXB0b3LigJkgb3Ig4oCYUmVt b3RlIE5vZGUgRGVzY3JpcHRvcuKAmS4gTGV04oCZcyBjb25zaWRlciB0aGUgY2FzZSBpbiB3aGlj aCB0aGlzIGZpZWxkIGFwcGVhcnMgaW4g4oCYUmVtb3RlIE5vZGUgRGVzY3JpcHRvcuKAmSBpbiB0 aGUgZm9sbG93aW5nIHRvcG9sb2d5Lg0KDQoNClIxKDEuMS4xLjE6OjEwLjEwLjEwLjEpIDwtLS0t TDEtLS0tPiBSMiAoMi4yLjIuMjo6MTAuMTAuMTAuMikNCg0KV2hlcmUsDQpSMSdzIHJvdXRlci1p ZCBpcyAxLjEuMS4xLCBhbmQgTDEgaW50ZXJmYWNlIElQIGFkZHJlc3MgaXMgMTAuMTAuMTAuMS4N ClIyJ3Mgcm91dGVyLWlkIGlzIDIuMi4yLjIsIGFuZCBMMSBpbnRlcmZhY2UgSVAgYWRkcmVzcyBp cyAxMC4xMC4xMC4yLg0KTDEgaXMgYSBMQU4uDQpSMSBpcyBlbGVjdGVkIGFzIHRoZSBEUiBmb3Ig TDEuDQoNClRoZXJlIGFyZSBmb3VyIGRpc3RpbmN0IHVuaWRpcmVjdGlvbmFsIGxpbmtzIGluIHRo ZSB0b3BvbG9neSBhYm92ZTogUjEtPkRSLCBEUi0+UjEsIFIyLT5EUiwgYW5kIERSLT5SMi4gTGV0 4oCZcyBjb25zaWRlciB0aGUgbGluayBSMi0+RFIuIFIy4oCZcyByb3V0ZXIgTFNBIHJlcHJlc2Vu dHMgUjItPkRSIGxpbmsgYXMgZm9sbG93czogLQ0KDQpBZHZlcnRpc2luZyByb3V0ZXI6Mi4yLjIu Mg0KICAgTGluayBJRDogMTAuMTAuMTAuMQ0KICAgTGluayBkYXRhOjEwLjEwLjEwLjINCiAgIFR5 cGU6MiAoVHJhbnNpdCkNCg0KTm90ZSB0aGF0IHRoZSBPU1BGIGxpbmsgcmVwcmVzZW50YXRpb24g YWJvdmUgZG9lcyBub3QgaW5jbHVkZSB0aGUgcm91dGVyLWlkIG9mIHRoZSBEUiwgd2hpY2ggaXMg MS4xLjEuMS4NCg0KDQpBY2NvcmRpbmcgdG8gdGhlIHRleHQgaW4gc2VjdGlvbiAzLjIuMS40LCBC R1AtTFMgcmVxdWlyZXMgdXMgdG8gcmVwcmVzZW50IFIyLT5EUiBsaW5rIGFzIGZvbGxvd3MgKGNv bnNpZGVyaW5nIG9ubHkgbm9kZSBkZXNjcmlwdG9ycyBvZiByZWxldmFuY2UgdG8gdGhpcyBkaXNj dXNzaW9uLCBhbmQgaWdub3JpbmcgdGhlIHJlbWFpbmluZyBmaWVsZHMpIDogLQ0KDQpMb2NhbCBO b2RlKElHUC1Sb3V0ZXItSWQ6Mi4yLjIuMikgLT4gUmVtb3RlIE5vZGUoSUdQLVJvdXRlci1JZDox LjEuMS4xLTEwLjEwLjEwLjEpDQoNCg0KSG93ZXZlciwgdGhlIE9TUEYgcmVwcmVzZW50YXRpb24g b2YgdGhlIGFib3ZlIGxpbmsgaW4gUjLigJlzIHJvdXRlciBMU0EgZG9lcyBub3QgY29udGFpbiAx LjEuMS4xIGF0IGFsbC4gVGhlcmVmb3JlLCBCR1AtTFMgaGFzIG5vd2hlcmUgdG8gZGVyaXZlIOKA mDEuMS4xLjHigJkgZnJvbSwgZm9yIHRoZSBsaW5rIFIyLT5EUi4NCg0KVGhlIGV4YW1wbGUgaW4g c2VjdGlvbiAzLjcgaXMgYXQgb2RkcyB3aXRoIHRoZSB0ZXh0IGluIHNlY3Rpb24gMy4yLjEuNCwg YW5kIHJlcHJlc2VudHMgdGhlIGxpbmsgYXMgZm9sbG93cyAod2hpY2ggd29ya3MgcGVyZmVjdGx5 KTogLQ0KDQoNCkxvY2FsIE5vZGUoSUdQLVJvdXRlci1JZDoyLjIuMi4yKSAtPiBSZW1vdGUgTm9k ZShJR1AtUm91dGVyLUlkOjEwLjEwLjEwLjEtMTAuMTAuMTAuMSkNCg0KDQpJIHN1Z2dlc3QgcmV3 b3JkaW5nIHRoZSB0ZXh0IGluIDMuMi4xLjQgYXMgZm9sbG93czoNCg0KIg0KSUdQIFJvdXRlciBJ RDogPHNuaXA+IEZvciBhbiBPU1BGdjIgIlBzZXVkb25vZGUiIHJlcHJlc2VudGluZyBhIExBTiwN Cg0KICAgICAgdGhpcyBjb250YWlucyB0aGUgNCBvY3RldCBJUHY0IGFkZHJlc3Mgb2YgdGhlIERS J3MgaW50ZXJmYWNlIHRvIHRoZQ0KICAgICAgTEFOLCBmb2xsb3dlZCBieSBhbnkgbm9uLXplcm8g NC1vY3RldCBudW1iZXIgKDggb2N0ZXRzIGluIHRvdGFsKSA8c25pcD7igJ0NCg0KDQrigJQNCkJh bGFqaSBSYWphZ29wYWxhbg0KDQoNCg0KDQpGcm9tOiBUaGUgSUVTRyA8aWVzZy1zZWNyZXRhcnlA aWV0Zi5vcmc8bWFpbHRvOmllc2ctc2VjcmV0YXJ5QGlldGYub3JnPj4NClJlcGx5LVRvOiAiaWV0 ZkBpZXRmLm9yZzxtYWlsdG86aWV0ZkBpZXRmLm9yZz4iIDxpZXRmQGlldGYub3JnPG1haWx0bzpp ZXRmQGlldGYub3JnPj4NCkRhdGU6IFRodXJzZGF5LCBNYXJjaCAxOSwgMjAxNSBhdCAxOjEwIEFN DQpUbzogSUVURi1Bbm5vdW5jZSA8aWV0Zi1hbm5vdW5jZUBpZXRmLm9yZzxtYWlsdG86aWV0Zi1h bm5vdW5jZUBpZXRmLm9yZz4+DQpDYzogImlkckBpZXRmLm9yZzxtYWlsdG86aWRyQGlldGYub3Jn PiIgPGlkckBpZXRmLm9yZzxtYWlsdG86aWRyQGlldGYub3JnPj4NClN1YmplY3Q6IFtJZHJdIFJF VklTRUQgTGFzdCBDYWxsOiA8ZHJhZnQtaWV0Zi1pZHItbHMtZGlzdHJpYnV0aW9uLTEwLnR4dD4g KE5vcnRoLUJvdW5kIERpc3RyaWJ1dGlvbiBvZiBMaW5rLVN0YXRlIGFuZCBURSBJbmZvcm1hdGlv biB1c2luZyBCR1ApIHRvIFByb3Bvc2VkIFN0YW5kYXJkDQoNCg0KVGhlIElFU0cgaGFzIHJlY2Vp dmVkIGEgcmVxdWVzdCBmcm9tIHRoZSBJbnRlci1Eb21haW4gUm91dGluZyBXRyAoaWRyKSB0bw0K Y29uc2lkZXIgdGhlIGZvbGxvd2luZyBkb2N1bWVudDoNCi0gJ05vcnRoLUJvdW5kIERpc3RyaWJ1 dGlvbiBvZiBMaW5rLVN0YXRlIGFuZCBURSBJbmZvcm1hdGlvbiB1c2luZyBCR1AnDQogIDxkcmFm dC1pZXRmLWlkci1scy1kaXN0cmlidXRpb24tMTAudHh0PiBhcyBQcm9wb3NlZCBTdGFuZGFyZA0K DQpUaGUgSUVTRyBwbGFucyB0byBtYWtlIGEgZGVjaXNpb24gaW4gdGhlIG5leHQgZmV3IHdlZWtz LCBhbmQgc29saWNpdHMNCmZpbmFsIGNvbW1lbnRzIG9uIHRoaXMgYWN0aW9uLiBQbGVhc2Ugc2Vu ZCBzdWJzdGFudGl2ZSBjb21tZW50cyB0byB0aGUNCmlldGZAaWV0Zi5vcmc8bWFpbHRvOmlldGZA aWV0Zi5vcmc+IG1haWxpbmcgbGlzdHMgYnkgMjAxNS0wNC0wOC4gRXhjZXB0aW9uYWxseSwgY29t bWVudHMgbWF5IGJlDQpzZW50IHRvIGllc2dAaWV0Zi5vcmc8bWFpbHRvOmllc2dAaWV0Zi5vcmc+ IGluc3RlYWQuIEluIGVpdGhlciBjYXNlLCBwbGVhc2UgcmV0YWluIHRoZQ0KYmVnaW5uaW5nIG9m IHRoZSBTdWJqZWN0IGxpbmUgdG8gYWxsb3cgYXV0b21hdGVkIHNvcnRpbmcuDQoNCkFic3RyYWN0 DQoNCg0KICAgSW4gYSBudW1iZXIgb2YgZW52aXJvbm1lbnRzLCBhIGNvbXBvbmVudCBleHRlcm5h bCB0byBhIG5ldHdvcmsgaXMNCiAgIGNhbGxlZCB1cG9uIHRvIHBlcmZvcm0gY29tcHV0YXRpb25z IGJhc2VkIG9uIHRoZSBuZXR3b3JrIHRvcG9sb2d5IGFuZA0KICAgY3VycmVudCBzdGF0ZSBvZiB0 aGUgY29ubmVjdGlvbnMgd2l0aGluIHRoZSBuZXR3b3JrLCBpbmNsdWRpbmcNCiAgIHRyYWZmaWMg ZW5naW5lZXJpbmcgaW5mb3JtYXRpb24uICBUaGlzIGlzIGluZm9ybWF0aW9uIHR5cGljYWxseQ0K ICAgZGlzdHJpYnV0ZWQgYnkgSUdQIHJvdXRpbmcgcHJvdG9jb2xzIHdpdGhpbiB0aGUgbmV0d29y ay4NCg0KICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBtZWNoYW5pc20gYnkgd2hpY2ggbGlu a3Mgc3RhdGUgYW5kIHRyYWZmaWMNCiAgIGVuZ2luZWVyaW5nIGluZm9ybWF0aW9uIGNhbiBiZSBj b2xsZWN0ZWQgZnJvbSBuZXR3b3JrcyBhbmQgc2hhcmVkDQogICB3aXRoIGV4dGVybmFsIGNvbXBv bmVudHMgdXNpbmcgdGhlIEJHUCByb3V0aW5nIHByb3RvY29sLiAgVGhpcyBpcw0KICAgYWNoaWV2 ZWQgdXNpbmcgYSBuZXcgQkdQIE5ldHdvcmsgTGF5ZXIgUmVhY2hhYmlsaXR5IEluZm9ybWF0aW9u DQogICAoTkxSSSkgZW5jb2RpbmcgZm9ybWF0LiAgVGhlIG1lY2hhbmlzbSBpcyBhcHBsaWNhYmxl IHRvIHBoeXNpY2FsIGFuZA0KICAgdmlydHVhbCBJR1AgbGlua3MuICBUaGUgbWVjaGFuaXNtIGRl c2NyaWJlZCBpcyBzdWJqZWN0IHRvIHBvbGljeQ0KICAgY29udHJvbC4NCg0KICAgQXBwbGljYXRp b25zIG9mIHRoaXMgdGVjaG5pcXVlIGluY2x1ZGUgQXBwbGljYXRpb24gTGF5ZXIgVHJhZmZpYw0K ICAgT3B0aW1pemF0aW9uIChBTFRPKSBzZXJ2ZXJzLCBhbmQgUGF0aCBDb21wdXRhdGlvbiBFbGVt ZW50cyAoUENFcykuDQoNCg0KDQoNCg0KVGhlIGZpbGUgY2FuIGJlIG9idGFpbmVkIHZpYQ0KaHR0 cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWlkci1scy1kaXN0cmlidXRp b24vDQoNCklFU0cgZGlzY3Vzc2lvbiBjYW4gYmUgdHJhY2tlZCB2aWENCmh0dHA6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pZHItbHMtZGlzdHJpYnV0aW9uL2JhbGxvdC8N Cg0KDQpUaGUgZm9sbG93aW5nIElQUiBEZWNsYXJhdGlvbnMgbWF5IGJlIHJlbGF0ZWQgdG8gdGhp cyBJLUQ6DQoNCiAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9pcHIvMTg2NC8NCg0KDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJZHIgbWFp bGluZyBsaXN0DQpJZHJAaWV0Zi5vcmc8bWFpbHRvOklkckBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRyDQoNCg== --_000_D142ADD412F49balajirjunipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <5628F8AD60E48C4794430636682B85FA@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NXB4OyBmb250LWZhbWlseTogQ29uc29sYXMsIHNhbnMtc2VyaWY7Ij4NCjxkaXY+SGkgQWNlZSw8 L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkkgYWxzbyBwb2ludGVkIG91dCBhbiBpbmNv bnNpc3RlbmN5IGJldHdlZW4gdGhlIGV4YW1wbGUgaW4gc2VjdGlvbiAzLjcgYW5kIHRoZSBub3Jt YXRpdmUgdGV4dCBpbiBzZWN0aW9uIDMuMi4xLjQuIFNvLCB0aGUgZHJhZnQgbmVlZHMgYSBjb3Jy ZWN0aW9uIGFueXdheS48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoZSBxdWVzdGlv biBpcywgd2hpY2ggb25lIG5lZWRzIHRvIGJlIGNvcnJlY3RlZCDigJMgc2VjdGlvbiAzLjcsIG9y IHNlY3Rpb24gMy4yLjEuNC48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PklNSE8sIHdl IHNob3VsZCBjb3JyZWN0IHRoZSBub3JtYXRpdmUgdGV4dCBpbiBzZWN0aW9uIDMuMi4xLjQgdG8g YWxpZ24gd2l0aCB0aGUgZXhhbXBsZSBpbiBzZWN0aW9uIDMuNywgYXMgdGhlIGV4YW1wbGUgbW9y ZSBjbG9zZWx5IHJlZmxlY3RzIGhvdyBPU1BGdjIgcmVwcmVzZW50cyB0aGUgbGluay48L2Rpdj4N CjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PuKAlDwvZGl2Pg0KPGRpdj5CYWxhamkgUmFqYWdvcGFs YW48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9 Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7 IGZvbnQtc2l6ZToxMXB0OyB0ZXh0LWFsaWduOmxlZnQ7IGNvbG9yOmJsYWNrOyBCT1JERVItQk9U VE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6IG1lZGl1bSBub25lOyBQQURESU5HLUJPVFRP TTogMGluOyBQQURESU5HLUxFRlQ6IDBpbjsgUEFERElORy1SSUdIVDogMGluOyBCT1JERVItVE9Q OiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1U T1A6IDNwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTogPC9zcGFuPiZx dW90O0FjZWUgTGluZGVtIChhY2VlKSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFjZWVAY2lz Y28uY29tIj5hY2VlQGNpc2NvLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2Vp Z2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5XZWRuZXNkYXksIEFwcmlsIDEsIDIwMTUgYXQgMTE6MTEg UE08YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bhbj5CYWxhamkg UmFqYWdvcGFsYW4gJmx0OzxhIGhyZWY9Im1haWx0bzpiYWxhamlyQGp1bmlwZXIubmV0Ij5iYWxh amlyQGp1bmlwZXIubmV0PC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzppZXRmQGlldGYu b3JnIj5pZXRmQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlldGZAaWV0 Zi5vcmciPmlldGZAaWV0Zi5vcmc8L2E+Jmd0OywgSGFubmVzIEdyZWRsZXIgJmx0OzxhIGhyZWY9 Im1haWx0bzpoYW5uZXNAanVuaXBlci5uZXQiPmhhbm5lc0BqdW5pcGVyLm5ldDwvYT4mZ3Q7PGJy Pg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkNjOiA8L3NwYW4+JnF1b3Q7PGEgaHJl Zj0ibWFpbHRvOmlkckBpZXRmLm9yZyI+aWRyQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmlkckBpZXRmLm9yZyI+aWRyQGlldGYub3JnPC9hPiZndDs8YnI+DQo8c3BhbiBz dHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFuPlJlOiBbSWRyXSBSRVZJU0VE IExhc3QgQ2FsbDogJmx0O2RyYWZ0LWlldGYtaWRyLWxzLWRpc3RyaWJ1dGlvbi0xMC50eHQmZ3Q7 IChOb3J0aC1Cb3VuZCBEaXN0cmlidXRpb24gb2YgTGluay1TdGF0ZSBhbmQgVEUgSW5mb3JtYXRp b24gdXNpbmcgQkdQKSB0byBQcm9wb3NlZCBTdGFuZGFyZDxicj4NCjwvZGl2Pg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FV T1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElORzowIDAgMCA1 OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRpdj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWst d29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVy LXdoaXRlLXNwYWNlOyBjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LXNpemU6IDE0cHg7IGZvbnQt ZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+DQo8ZGl2PkJhbGFqaSwmbmJzcDs8L2Rpdj4N CjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoaXMgaXMgYW4gaW1wbGVtZW50YXRpb24gaXNzdWUg YmFzZWQgb24gdGhlIGZhY3QgdGhhdCB5b3UgYXJlIGRlcml2aW5nIHRoZSBCR1AgTFMgaW5mb3Jt YXRpb24gZnJvbSB0aGUgTFNBcyByYXRoZXIgdGhhbiBoYXZpbmcgdGhlIElHUCBpbnN0YWxsIHRo ZSBub3JtYWxpemVkIGRyYWZ0LWlldGYtaWRyLWxzLWRpc3RyaWJ1dGlvbiBsaW5rcy4gR2l2ZW4g dGhhdCB0aGUgZHJhZnQgaXMgd2l0aCB0aGUgSUVTRywgSeKAmW0gbm90IHN1cmUgd2UNCiB3YW50 IHRvIGF0dGVtcHQgdG8gb3B0aW1pemUgaXQgdG8geW91ciBpbXBsZW1lbnRhdGlvbiBhbmQgZGlz cnVwdGl2ZSBldmVyeW9uZSBlbHNl4oCZcy4gSWYgeW91IGFyZSBtYWludGFpbmluZyB0aGUgTFNB cyBpbiBhbiBPU1BGIExTREIgdHlwZSBzdHJ1Y3R1cmUgaW4gQkdQLCB5b3UgZWFzaWx5IGZpbmQg dGhlIE5ldHdvcmsgTFNBIGFuZCBleHRyYWN0IHRoZSBhZHZlcnRpc2luZyByb3V0ZXIuJm5ic3A7 PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGFua3MsPC9kaXY+DQo8ZGl2PkFjZWUm bmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NF Q1RJT04iPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjExcHQ7 IHRleHQtYWxpZ246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25l OyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkct TEVGVDogMGluOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNv bGlkOyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFu IHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+QmFsYWppIFJhamFnb3BhbGFu ICZsdDs8YSBocmVmPSJtYWlsdG86YmFsYWppckBqdW5pcGVyLm5ldCI+YmFsYWppckBqdW5pcGVy Lm5ldDwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwv c3Bhbj5XZWRuZXNkYXksIEFwcmlsIDEsIDIwMTUgYXQgMTowMCBQTTxicj4NCjxzcGFuIHN0eWxl PSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPiZxdW90OzxhIGhyZWY9Im1haWx0bzppZXRm QGlldGYub3JnIj5pZXRmQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmll dGZAaWV0Zi5vcmciPmlldGZAaWV0Zi5vcmc8L2E+Jmd0OywgSGFubmVzIEdyZWRsZXIgJmx0Ozxh IGhyZWY9Im1haWx0bzpoYW5uZXNAanVuaXBlci5uZXQiPmhhbm5lc0BqdW5pcGVyLm5ldDwvYT4m Z3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkNjOiA8L3NwYW4+JnF1b3Q7 PGEgaHJlZj0ibWFpbHRvOmlkckBpZXRmLm9yZyI+aWRyQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmlkckBpZXRmLm9yZyI+aWRyQGlldGYub3JnPC9hPiZndDs8YnI+DQo8 c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFuPlJlOiBbSWRyXSBS RVZJU0VEIExhc3QgQ2FsbDogJmx0O2RyYWZ0LWlldGYtaWRyLWxzLWRpc3RyaWJ1dGlvbi0xMC50 eHQmZ3Q7IChOb3J0aC1Cb3VuZCBEaXN0cmlidXRpb24gb2YgTGluay1TdGF0ZSBhbmQgVEUgSW5m b3JtYXRpb24gdXNpbmcgQkdQKSB0byBQcm9wb3NlZCBTdGFuZGFyZDxicj4NCjwvZGl2Pg0KPGRp dj48YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9C TE9DS1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElORzow IDAgMCA1OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRpdj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDog YnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6 IGFmdGVyLXdoaXRlLXNwYWNlOyI+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBm b250LWZhbWlseTogQ29uc29sYXMsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTVweDsiPg0KSSBz ZWVrIGEgY29ycmVjdGlvbiB0byB0aGUgZm9sbG93aW5nIHRleHQgaW4gc2VjdGlvbiAzLjIuMS40 LjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENv bnNvbGFzLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE1cHg7Ij4NCjxicj4NCjwvZGl2Pg0KPGRp diBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENvbnNvbGFzLCBzYW5z LXNlcmlmOyBmb250LXNpemU6IDE1cHg7Ij4NCiZxdW90OzwvZGl2Pg0KPGRpdiBzdHlsZT0iY29s b3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENvbnNvbGFzLCBzYW5zLXNlcmlmOyBmb250 LXNpemU6IDE1cHg7Ij4NCklHUCBSb3V0ZXIgSUQ6ICZsdDtzbmlwJmd0OyZuYnNwOzxzcGFuIHN0 eWxlPSJsaW5lLWhlaWdodDogMS4yZW07Ij5Gb3IgYW4gT1NQRnYyICZxdW90O1BzZXVkb25vZGUm cXVvdDsgcmVwcmVzZW50aW5nIGEgTEFOLDwvc3Bhbj48L2Rpdj4NCjxwcmUgc3R5bGU9ImNvbG9y OiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDb25zb2xhcywgc2Fucy1zZXJpZjsgZm9udC1z aXplOiAxNXB4OyBsaW5lLWhlaWdodDogMS4yZW07IG1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJv dHRvbTogMHB4OyI+PGZvbnQgZmFjZT0iQ29uc29sYXMiPiAgICAgIHRoaXMgY29udGFpbnMgdGhl IDQgb2N0ZXQgUm91dGVyLUlEIG9mIHRoZSBkZXNpZ25hdGVkIHJvdXRlciAoRFIpDQogICAgICBm b2xsb3dlZCBieSB0aGUgNCBvY3RldCBJUHY0IGFkZHJlc3Mgb2YgdGhlIERSJ3MgaW50ZXJmYWNl IHRvIHRoZQ0KICAgICAgTEFOICg4IG9jdGV0cyBpbiB0b3RhbCkgJmx0O3NuaXAmZ3Q7JnF1b3Q7 PC9mb250PjwvcHJlPg0KPHByZSBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1p bHk6IENvbnNvbGFzLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE1cHg7IGxpbmUtaGVpZ2h0OiAx LjJlbTsgbWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7Ij48YnI+PC9wcmU+DQo8 cHJlIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ29uc29sYXMsIHNh bnMtc2VyaWY7IGZvbnQtc2l6ZTogMTVweDsgbWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9t OiAwcHg7Ij48Zm9udCBmYWNlPSJDb25zb2xhcyI+PHNwYW4gc3R5bGU9ImxpbmUtaGVpZ2h0OiAx OHB4OyI+VGhlIHJlYXNvbiBJIHNlZWsgdGhpcyBjaGFuZ2UgaXMsIHQ8L3NwYW4+PC9mb250Pjxm b250IGZhY2U9IkNvbnNvbGFzIiBzdHlsZT0iZm9udC1zaXplOiAxNXB4OyBsaW5lLWhlaWdodDog MS4yZW07Ij5oZSB0cmFuc2l0IGxpbmsgcmVwcmVzZW50YXRpb24gaW4gT1NQRnYyIHJvdXRlci1M U0EgZG9lcyBub3QgY29udGFpbiB0aGUgcm91dGVyLWlkIG9mIHRoZSBEUiA8L2ZvbnQ+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTogMTVweDsgbGluZS1oZWlnaHQ6IDEuMmVtOyBmb250LWZhbWlseTog Q29uc29sYXM7Ij4oc2VjdGlvbiAxMi40LjEuMiBvZiBSRkMyMzI4KTwvc3Bhbj48Zm9udCBmYWNl PSJDb25zb2xhcyI+PHNwYW4gc3R5bGU9ImxpbmUtaGVpZ2h0OiAxLjJlbTsiPi4mbmJzcDtTbywg QkdQLUxTIGhhcyBub3doZXJlIHRvIGRlcml2ZSBSb3V0ZXItSUQgZnJvbS48L3NwYW4+PC9mb250 PjwvcHJlPg0KPHByZSBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENv bnNvbGFzLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE1cHg7IGxpbmUtaGVpZ2h0OiAxLjJlbTsg bWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7Ij48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6IENvbnNvbGFzOyBsaW5lLWhlaWdodDogMS4yZW07Ij48YnI+PC9zcGFuPjwvcHJlPg0K PHByZSBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENvbnNvbGFzLCBz YW5zLXNlcmlmOyBmb250LXNpemU6IDE1cHg7IGxpbmUtaGVpZ2h0OiAxLjJlbTsgbWFyZ2luLXRv cDogMHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IENv bnNvbGFzOyBsaW5lLWhlaWdodDogMS4yZW07Ij5CZWxvdyBhcmUgbW9yZSBkZXRhaWxzIHdpdGgg YW4gZXhhbXBsZS48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDAp OyBmb250LWZhbWlseTogQ29uc29sYXMsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTVweDsgbGlu ZS1oZWlnaHQ6IDEuMmVtOyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsiPjxm b250IGZhY2U9IkNvbnNvbGFzIj48YnI+PC9mb250PjwvcHJlPg0KPHByZSBzdHlsZT0iY29sb3I6 IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENvbnNvbGFzLCBzYW5zLXNlcmlmOyBmb250LXNp emU6IDE1cHg7IG1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyI+PGZvbnQgZmFj ZT0iQ29uc29sYXMiPjxzcGFuIHN0eWxlPSJsaW5lLWhlaWdodDogMS4yZW07Ij5UaGUgJ0lHUCBy b3V0ZXIgSUQnIGZpZWxkIGNhbiBhcHBlYXIgZWl0aGVyIGluIOKAmExvY2FsIE5vZGUgRGVzY3Jp cHRvcuKAmSBvciDigJhSZW1vdGUgTm9kZSBEZXNjcmlwdG9y4oCZLiBMZXQ8L3NwYW4+PHNwYW4g c3R5bGU9ImxpbmUtaGVpZ2h0OiAxOHB4OyI+4oCZPC9zcGFuPjxzcGFuIHN0eWxlPSJsaW5lLWhl aWdodDogMS4yZW07Ij5zIGNvbnNpZGVyIHRoZSBjYXNlIGluIHdoaWNoIHRoaXMgZmllbGQgYXBw ZWFycyBpbiA8L3NwYW4+PHNwYW4gc3R5bGU9ImxpbmUtaGVpZ2h0OiAxOHB4OyI+4oCYPC9zcGFu PjxzcGFuIHN0eWxlPSJsaW5lLWhlaWdodDogMS4yZW07Ij5SZW1vdGUgTm9kZSBEZXNjcmlwdG9y PC9zcGFuPjxzcGFuIHN0eWxlPSJsaW5lLWhlaWdodDogMThweDsiPuKAmSBpbiB0aGUgZm9sbG93 aW5nIHRvcG9sb2d5Ljwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQo8cHJlIHN0eWxlPSJjb2xvcjogcmdi KDAsIDAsIDApOyBmb250LWZhbWlseTogQ29uc29sYXMsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTog MTVweDsgbWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7Ij48Zm9udCBmYWNlPSJD b25zb2xhcyI+PHNwYW4gc3R5bGU9ImxpbmUtaGVpZ2h0OiAxOHB4OyI+PGJyPjwvc3Bhbj48L2Zv bnQ+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBw eDsiPjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDb25zb2xh cywgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNXB4OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyI+UjEo MS4xLjEuMTo6MTAuMTAuMTAuMSkgJmx0Oy0tLS1MMS0tLS0mZ3Q7IFIyICgyLjIuMi4yOjoxMC4x MC4xMC4yKTwvZGl2PjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5 OiBDb25zb2xhcywgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNXB4OyB3aGl0ZS1zcGFjZTogbm9y bWFsOyI+PGJyPjwvZGl2PjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFt aWx5OiBDb25zb2xhcywgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNXB4OyB3aGl0ZS1zcGFjZTog bm9ybWFsOyI+V2hlcmUsPC9kaXY+PGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9u dC1mYW1pbHk6IENvbnNvbGFzLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE1cHg7IHdoaXRlLXNw YWNlOiBub3JtYWw7Ij5SMSdzIHJvdXRlci1pZCBpcyAxLjEuMS4xLCBhbmQgTDEgaW50ZXJmYWNl IElQIGFkZHJlc3MgaXMgMTAuMTAuMTAuMS48L2Rpdj48ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAs IDAsIDApOyBmb250LWZhbWlseTogQ29uc29sYXMsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTVw eDsgd2hpdGUtc3BhY2U6IG5vcm1hbDsiPlIyJ3Mgcm91dGVyLWlkIGlzIDIuMi4yLjIsIGFuZCBM MSBpbnRlcmZhY2UgSVAgYWRkcmVzcyBpcyAxMC4xMC4xMC4yLjwvZGl2PjxkaXYgc3R5bGU9ImNv bG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDb25zb2xhcywgc2Fucy1zZXJpZjsgZm9u dC1zaXplOiAxNXB4OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyI+TDEgaXMgYSBMQU4uPC9kaXY+PGRp diBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENvbnNvbGFzLCBzYW5z LXNlcmlmOyBmb250LXNpemU6IDE1cHg7IHdoaXRlLXNwYWNlOiBub3JtYWw7Ij5SMSBpcyBlbGVj dGVkIGFzIHRoZSBEUiBmb3IgTDEuPC9kaXY+PGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAw KTsgZm9udC1mYW1pbHk6IENvbnNvbGFzLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE1cHg7IHdo aXRlLXNwYWNlOiBub3JtYWw7Ij48YnI+PC9kaXY+PGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAw LCAwKTsgZm9udC1mYW1pbHk6IENvbnNvbGFzLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE1cHg7 IHdoaXRlLXNwYWNlOiBub3JtYWw7Ij5UaGVyZSBhcmUgZm91ciBkaXN0aW5jdCB1bmlkaXJlY3Rp b25hbCBsaW5rcyBpbiB0aGUgdG9wb2xvZ3kgYWJvdmU6IFIxLSZndDtEUiwgRFItJmd0O1IxLCBS Mi0mZ3Q7RFIsIGFuZCBEUi0mZ3Q7UjIuIExldOKAmXMgY29uc2lkZXIgdGhlIGxpbmsgUjItJmd0 O0RSLiBSMuKAmXMgcm91dGVyIExTQSByZXByZXNlbnRzIFIyLSZndDtEUiBsaW5rIGFzIGZvbGxv d3M6IC08L2Rpdj48cHJlIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTog Q29uc29sYXMsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTVweDsgbWFyZ2luLXRvcDogMHB4OyBt YXJnaW4tYm90dG9tOiAwcHg7Ij48ZGl2IHN0eWxlPSJ3aGl0ZS1zcGFjZTogbm9ybWFsOyI+PGJy PjwvZGl2PjxkaXYgc3R5bGU9IndoaXRlLXNwYWNlOiBub3JtYWw7Ij5BZHZlcnRpc2luZyByb3V0 ZXI6Mi4yLjIuMjwvZGl2PjxkaXYgc3R5bGU9IndoaXRlLXNwYWNlOiBub3JtYWw7Ij4mbmJzcDsg Jm5ic3A7TGluayBJRDogMTAuMTAuMTAuMTwvZGl2PjxkaXYgc3R5bGU9IndoaXRlLXNwYWNlOiBu b3JtYWw7Ij4mbmJzcDsgJm5ic3A7TGluayBkYXRhOjEwLjEwLjEwLjI8L2Rpdj48ZGl2IHN0eWxl PSJ3aGl0ZS1zcGFjZTogbm9ybWFsOyI+Jm5ic3A7ICZuYnNwO1R5cGU6MiAoVHJhbnNpdCk8L2Rp dj48L3ByZT48ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ29u c29sYXMsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTVweDsgd2hpdGUtc3BhY2U6IG5vcm1hbDsi Pjxicj48L2Rpdj48ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTog Q29uc29sYXMsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTVweDsgd2hpdGUtc3BhY2U6IG5vcm1h bDsiPk5vdGUgdGhhdCB0aGUgT1NQRiBsaW5rIHJlcHJlc2VudGF0aW9uIGFib3ZlIGRvZXMgbm90 IGluY2x1ZGUgdGhlIHJvdXRlci1pZCBvZiB0aGUgRFIsIHdoaWNoIGlzIDEuMS4xLjEuPC9kaXY+ PGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENvbnNvbGFzLCBz YW5zLXNlcmlmOyBmb250LXNpemU6IDE1cHg7IHdoaXRlLXNwYWNlOiBub3JtYWw7Ij48YnI+PC9k aXY+PGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENvbnNvbGFz LCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE1cHg7IHdoaXRlLXNwYWNlOiBub3JtYWw7Ij48cHJl IHN0eWxlPSJtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsiPjxkaXYgc3R5bGU9 ImZvbnQtZmFtaWx5OiBDb25zb2xhcywgc2Fucy1zZXJpZjsgd2hpdGUtc3BhY2U6IG5vcm1hbDsi PkFjY29yZGluZyB0byB0aGUgdGV4dCBpbiBzZWN0aW9uIDMuMi4xLjQsIEJHUC1MUyByZXF1aXJl cyB1cyB0byByZXByZXNlbnQgUjItJmd0O0RSIGxpbmsgYXMgZm9sbG93cyAoY29uc2lkZXJpbmcg b25seSBub2RlIGRlc2NyaXB0b3JzIG9mIHJlbGV2YW5jZSB0byB0aGlzIGRpc2N1c3Npb24sIGFu ZCBpZ25vcmluZyB0aGUgcmVtYWluaW5nIGZpZWxkcykgOiAtPC9kaXY+PGRpdiBzdHlsZT0iZm9u dC1mYW1pbHk6IENvbnNvbGFzLCBzYW5zLXNlcmlmOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyI+PGJy PjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDb25zb2xhcywgc2Fucy1zZXJpZjsgd2hp dGUtc3BhY2U6IG5vcm1hbDsiPkxvY2FsIE5vZGUoSUdQLVJvdXRlci1JZDoyLjIuMi4yKSAtJmd0 OyBSZW1vdGUgTm9kZShJR1AtUm91dGVyLUlkOjEuMS4xLjEtMTAuMTAuMTAuMSk8L2Rpdj48ZGl2 IHN0eWxlPSJmb250LWZhbWlseTogQ29uc29sYXMsIHNhbnMtc2VyaWY7IHdoaXRlLXNwYWNlOiBu b3JtYWw7Ij48YnI+PC9kaXY+PC9wcmU+PC9kaXY+PGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAw LCAwKTsgZm9udC1mYW1pbHk6IENvbnNvbGFzLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE1cHg7 IHdoaXRlLXNwYWNlOiBub3JtYWw7Ij5Ib3dldmVyLCB0aGUgT1NQRiByZXByZXNlbnRhdGlvbiBv ZiB0aGUgYWJvdmUgbGluayBpbiBSMuKAmXMgcm91dGVyIExTQSBkb2VzIG5vdCBjb250YWluIDEu MS4xLjEgYXQgYWxsLiBUaGVyZWZvcmUsIEJHUC1MUyBoYXMgbm93aGVyZSB0byBkZXJpdmUg4oCY MS4xLjEuMeKAmSBmcm9tLCBmb3IgdGhlIGxpbmsgUjItJmd0O0RSLjwvZGl2PjxkaXYgc3R5bGU9 ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDb25zb2xhcywgc2Fucy1zZXJpZjsg Zm9udC1zaXplOiAxNXB4OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyI+PGJyPjwvZGl2PjxkaXYgc3R5 bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDb25zb2xhcywgc2Fucy1zZXJp ZjsgZm9udC1zaXplOiAxNXB4OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyI+VGhlIGV4YW1wbGUgaW4g c2VjdGlvbiAzLjcgaXMgYXQgb2RkcyB3aXRoIHRoZSB0ZXh0IGluIHNlY3Rpb24gMy4yLjEuNCwg YW5kIHJlcHJlc2VudHMgdGhlIGxpbmsgYXMgZm9sbG93cyAod2hpY2ggd29ya3MgcGVyZmVjdGx5 KTogLTwvZGl2PjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBD b25zb2xhcywgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNXB4OyB3aGl0ZS1zcGFjZTogbm9ybWFs OyI+PGJyPjwvZGl2PjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5 OiBDb25zb2xhcywgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNXB4OyB3aGl0ZS1zcGFjZTogbm9y bWFsOyI+PHByZSBzdHlsZT0ibWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7Ij48 ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ29uc29sYXMsIHNhbnMtc2VyaWY7IHdoaXRlLXNwYWNl OiBub3JtYWw7Ij5Mb2NhbCBOb2RlKElHUC1Sb3V0ZXItSWQ6Mi4yLjIuMikgLSZndDsgUmVtb3Rl IE5vZGUoSUdQLVJvdXRlci1JZDoxMC4xMC4xMC4xLTEwLjEwLjEwLjEpPC9kaXY+PGRpdj48YnI+ PC9kaXY+PC9wcmU+PC9kaXY+PGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1m YW1pbHk6IENvbnNvbGFzLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE1cHg7IHdoaXRlLXNwYWNl OiBub3JtYWw7Ij5JIHN1Z2dlc3QgcmV3b3JkaW5nIHRoZSB0ZXh0IGluIDMuMi4xLjQgYXMgZm9s bG93czombmJzcDs8L2Rpdj48ZGl2PjxwcmUgc3R5bGU9Im1hcmdpbi10b3A6IDBweDsgbWFyZ2lu LWJvdHRvbTogMHB4OyI+PGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1p bHk6IENvbnNvbGFzLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE1cHg7IHdoaXRlLXNwYWNlOiBu b3JtYWw7Ij48YnI+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBm b250LWZhbWlseTogQ29uc29sYXMsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTVweDsgd2hpdGUt c3BhY2U6IG5vcm1hbDsiPiZxdW90OzwvZGl2PjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwg MCk7IGZvbnQtZmFtaWx5OiBDb25zb2xhcywgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNXB4OyB3 aGl0ZS1zcGFjZTogbm9ybWFsOyI+SUdQIFJvdXRlciBJRDogJmx0O3NuaXAmZ3Q7Jm5ic3A7PHNw YW4gc3R5bGU9ImxpbmUtaGVpZ2h0OiAxLjJlbTsiPkZvciBhbiBPU1BGdjIgJnF1b3Q7UHNldWRv bm9kZSZxdW90OyByZXByZXNlbnRpbmcgYSBMQU4sPC9zcGFuPjwvZGl2PjxwcmUgc3R5bGU9Im1h cmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyI+PGZvbnQgZmFjZT0iQ29uc29sYXMi IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ29uc29sYXMsIHNhbnMt c2VyaWY7IGZvbnQtc2l6ZTogMTVweDsgbGluZS1oZWlnaHQ6IDEuMmVtOyB3aGl0ZS1zcGFjZTog bm9ybWFsOyI+ICAgICAgdGhpcyBjb250YWlucyB0aGUgNCBvY3RldCBJUHY0IGFkZHJlc3Mgb2Yg dGhlIERSJ3MgaW50ZXJmYWNlIHRvIHRoZQ0KICAgICAgTEFOLCBmb2xsb3dlZCBieSBhbnkgbm9u LXplcm8gNC1vY3RldCBudW1iZXIgKDggb2N0ZXRzIGluIHRvdGFsKSAmbHQ7c25pcCZndDs8L2Zv bnQ+PGZvbnQgZmFjZT0iQ29uc29sYXMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDE1cHg7IGxp bmUtaGVpZ2h0OiAxOHB4OyI+4oCdPC9zcGFuPjwvZm9udD48L3ByZT48cHJlIHN0eWxlPSJjb2xv cjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ29uc29sYXMsIHNhbnMtc2VyaWY7IGZvbnQt c2l6ZTogMTVweDsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IDEuMmVtOyBtYXJn aW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsiPjxmb250IGZhY2U9IkNvbnNvbGFzIj48 YnI+PC9mb250PjwvcHJlPjwvZGl2PjwvcHJlPjwvZGl2PjxkaXYgc3R5bGU9ImNvbG9yOiByZ2Io MCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDb25zb2xhcywgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAx NXB4OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyI+4oCUPC9kaXY+PGRpdiBzdHlsZT0iY29sb3I6IHJn YigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENvbnNvbGFzLCBzYW5zLXNlcmlmOyBmb250LXNpemU6 IDE1cHg7IHdoaXRlLXNwYWNlOiBub3JtYWw7Ij5CYWxhamkgUmFqYWdvcGFsYW48L2Rpdj48ZGl2 IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ29uc29sYXMsIHNhbnMt c2VyaWY7IGZvbnQtc2l6ZTogMTVweDsgd2hpdGUtc3BhY2U6IG5vcm1hbDsiPjxicj48L2Rpdj48 ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ29uc29sYXMsIHNh bnMtc2VyaWY7IGZvbnQtc2l6ZTogMTVweDsgd2hpdGUtc3BhY2U6IG5vcm1hbDsiPjxicj48L2Rp dj48L3ByZT4NCjxwcmUgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBD b25zb2xhcywgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNXB4OyBsaW5lLWhlaWdodDogMS4yZW07 IG1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyI+PGJyPjwvcHJlPg0KPGRpdiBz dHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENvbnNvbGFzLCBzYW5zLXNl cmlmOyBmb250LXNpemU6IDE1cHg7Ij4NCjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNf Qk9EWV9TRUNUSU9OIiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENv bnNvbGFzLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE1cHg7Ij4NCjxkaXYgc3R5bGU9ImZvbnQt ZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMXB0OyB0ZXh0LWFsaWduOmxlZnQ7IGNvbG9yOmJs YWNrOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6IG1lZGl1bSBub25l OyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxFRlQ6IDBpbjsgUEFERElORy1SSUdIVDog MGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9SREVSLVJJR0hUOiBtZWRpdW0g bm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+ RnJvbTogPC9zcGFuPlRoZSBJRVNHICZsdDs8YSBocmVmPSJtYWlsdG86aWVzZy1zZWNyZXRhcnlA aWV0Zi5vcmciPmllc2ctc2VjcmV0YXJ5QGlldGYub3JnPC9hPiZndDs8YnI+DQo8c3BhbiBzdHls ZT0iZm9udC13ZWlnaHQ6Ym9sZCI+UmVwbHktVG86IDwvc3Bhbj4mcXVvdDs8YSBocmVmPSJtYWls dG86aWV0ZkBpZXRmLm9yZyI+aWV0ZkBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1h aWx0bzppZXRmQGlldGYub3JnIj5pZXRmQGlldGYub3JnPC9hPiZndDs8YnI+DQo8c3BhbiBzdHls ZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9zcGFuPlRodXJzZGF5LCBNYXJjaCAxOSwgMjAx NSBhdCAxOjEwIEFNPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3Nw YW4+SUVURi1Bbm5vdW5jZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlldGYtYW5ub3VuY2VAaWV0Zi5v cmciPmlldGYtYW5ub3VuY2VAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250 LXdlaWdodDpib2xkIj5DYzogPC9zcGFuPiZxdW90OzxhIGhyZWY9Im1haWx0bzppZHJAaWV0Zi5v cmciPmlkckBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzppZHJAaWV0Zi5v cmciPmlkckBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJv bGQiPlN1YmplY3Q6IDwvc3Bhbj5bSWRyXSBSRVZJU0VEIExhc3QgQ2FsbDogJmx0O2RyYWZ0LWll dGYtaWRyLWxzLWRpc3RyaWJ1dGlvbi0xMC50eHQmZ3Q7IChOb3J0aC1Cb3VuZCBEaXN0cmlidXRp b24gb2YgTGluay1TdGF0ZSBhbmQgVEUgSW5mb3JtYXRpb24gdXNpbmcgQkdQKSB0byBQcm9wb3Nl ZCBTdGFuZGFyZDxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGlk PSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6 ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElORzowIDAgMCA1OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGUgSUVTRyBoYXMgcmVjZWl2ZWQg YSByZXF1ZXN0IGZyb20gdGhlIEludGVyLURvbWFpbiBSb3V0aW5nIFdHIChpZHIpIHRvPC9kaXY+ DQo8ZGl2PmNvbnNpZGVyIHRoZSBmb2xsb3dpbmcgZG9jdW1lbnQ6PC9kaXY+DQo8ZGl2Pi0gJ05v cnRoLUJvdW5kIERpc3RyaWJ1dGlvbiBvZiBMaW5rLVN0YXRlIGFuZCBURSBJbmZvcm1hdGlvbiB1 c2luZyBCR1AnPC9kaXY+DQo8ZGl2PiZuYnNwOyZuYnNwOyZsdDtkcmFmdC1pZXRmLWlkci1scy1k aXN0cmlidXRpb24tMTAudHh0Jmd0OyBhcyBQcm9wb3NlZCBTdGFuZGFyZDwvZGl2Pg0KPGRpdj48 YnI+DQo8L2Rpdj4NCjxkaXY+VGhlIElFU0cgcGxhbnMgdG8gbWFrZSBhIGRlY2lzaW9uIGluIHRo ZSBuZXh0IGZldyB3ZWVrcywgYW5kIHNvbGljaXRzPC9kaXY+DQo8ZGl2PmZpbmFsIGNvbW1lbnRz IG9uIHRoaXMgYWN0aW9uLiBQbGVhc2Ugc2VuZCBzdWJzdGFudGl2ZSBjb21tZW50cyB0byB0aGU8 L2Rpdj4NCjxkaXY+PGEgaHJlZj0ibWFpbHRvOmlldGZAaWV0Zi5vcmciPmlldGZAaWV0Zi5vcmc8 L2E+IG1haWxpbmcgbGlzdHMgYnkgMjAxNS0wNC0wOC4gRXhjZXB0aW9uYWxseSwgY29tbWVudHMg bWF5IGJlPC9kaXY+DQo8ZGl2PnNlbnQgdG8gPGEgaHJlZj0ibWFpbHRvOmllc2dAaWV0Zi5vcmci Pmllc2dAaWV0Zi5vcmc8L2E+IGluc3RlYWQuIEluIGVpdGhlciBjYXNlLCBwbGVhc2UgcmV0YWlu IHRoZTwvZGl2Pg0KPGRpdj5iZWdpbm5pbmcgb2YgdGhlIFN1YmplY3QgbGluZSB0byBhbGxvdyBh dXRvbWF0ZWQgc29ydGluZy48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkFic3RyYWN0 PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+Jm5ic3A7 Jm5ic3A7IEluIGEgbnVtYmVyIG9mIGVudmlyb25tZW50cywgYSBjb21wb25lbnQgZXh0ZXJuYWwg dG8gYSBuZXR3b3JrIGlzPC9kaXY+DQo8ZGl2PiZuYnNwOyZuYnNwOyBjYWxsZWQgdXBvbiB0byBw ZXJmb3JtIGNvbXB1dGF0aW9ucyBiYXNlZCBvbiB0aGUgbmV0d29yayB0b3BvbG9neSBhbmQ8L2Rp dj4NCjxkaXY+Jm5ic3A7Jm5ic3A7IGN1cnJlbnQgc3RhdGUgb2YgdGhlIGNvbm5lY3Rpb25zIHdp dGhpbiB0aGUgbmV0d29yaywgaW5jbHVkaW5nPC9kaXY+DQo8ZGl2PiZuYnNwOyZuYnNwOyB0cmFm ZmljIGVuZ2luZWVyaW5nIGluZm9ybWF0aW9uLiZuYnNwOyZuYnNwO1RoaXMgaXMgaW5mb3JtYXRp b24gdHlwaWNhbGx5PC9kaXY+DQo8ZGl2PiZuYnNwOyZuYnNwOyBkaXN0cmlidXRlZCBieSBJR1Ag cm91dGluZyBwcm90b2NvbHMgd2l0aGluIHRoZSBuZXR3b3JrLjwvZGl2Pg0KPGRpdj48YnI+DQo8 L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7IFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgbWVjaGFu aXNtIGJ5IHdoaWNoIGxpbmtzIHN0YXRlIGFuZCB0cmFmZmljPC9kaXY+DQo8ZGl2PiZuYnNwOyZu YnNwOyBlbmdpbmVlcmluZyBpbmZvcm1hdGlvbiBjYW4gYmUgY29sbGVjdGVkIGZyb20gbmV0d29y a3MgYW5kIHNoYXJlZDwvZGl2Pg0KPGRpdj4mbmJzcDsmbmJzcDsgd2l0aCBleHRlcm5hbCBjb21w b25lbnRzIHVzaW5nIHRoZSBCR1Agcm91dGluZyBwcm90b2NvbC4mbmJzcDsmbmJzcDtUaGlzIGlz PC9kaXY+DQo8ZGl2PiZuYnNwOyZuYnNwOyBhY2hpZXZlZCB1c2luZyBhIG5ldyBCR1AgTmV0d29y ayBMYXllciBSZWFjaGFiaWxpdHkgSW5mb3JtYXRpb248L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7 IChOTFJJKSBlbmNvZGluZyBmb3JtYXQuJm5ic3A7Jm5ic3A7VGhlIG1lY2hhbmlzbSBpcyBhcHBs aWNhYmxlIHRvIHBoeXNpY2FsIGFuZDwvZGl2Pg0KPGRpdj4mbmJzcDsmbmJzcDsgdmlydHVhbCBJ R1AgbGlua3MuJm5ic3A7Jm5ic3A7VGhlIG1lY2hhbmlzbSBkZXNjcmliZWQgaXMgc3ViamVjdCB0 byBwb2xpY3k8L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7IGNvbnRyb2wuPC9kaXY+DQo8ZGl2Pjxi cj4NCjwvZGl2Pg0KPGRpdj4mbmJzcDsmbmJzcDsgQXBwbGljYXRpb25zIG9mIHRoaXMgdGVjaG5p cXVlIGluY2x1ZGUgQXBwbGljYXRpb24gTGF5ZXIgVHJhZmZpYzwvZGl2Pg0KPGRpdj4mbmJzcDsm bmJzcDsgT3B0aW1pemF0aW9uIChBTFRPKSBzZXJ2ZXJzLCBhbmQgUGF0aCBDb21wdXRhdGlvbiBF bGVtZW50cyAoUENFcykuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxkaXY+VGhlIGZpbGUgY2FuIGJlIG9idGFpbmVkIHZpYTwvZGl2Pg0KPGRpdj48YSBocmVm PSJodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaWRyLWxzLWRpc3Ry aWJ1dGlvbi8iPmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pZHIt bHMtZGlzdHJpYnV0aW9uLzwvYT48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PklFU0cg ZGlzY3Vzc2lvbiBjYW4gYmUgdHJhY2tlZCB2aWE8L2Rpdj4NCjxkaXY+PGEgaHJlZj0iaHR0cDov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWlkci1scy1kaXN0cmlidXRpb24v YmFsbG90LyI+aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWlkci1s cy1kaXN0cmlidXRpb24vYmFsbG90LzwvYT48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGUgZm9sbG93aW5nIElQUiBEZWNsYXJhdGlvbnMgbWF5IGJl IHJlbGF0ZWQgdG8gdGhpcyBJLUQ6PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4mbmJz cDsmbmJzcDsgPGEgaHJlZj0iaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2lwci8xODY0LyI+ aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2lwci8xODY0LzwvYT48L2Rpdj4NCjxkaXY+PGJy Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L2Rpdj4NCjxkaXY+ SWRyIG1haWxpbmcgbGlzdDwvZGl2Pg0KPGRpdj48YSBocmVmPSJtYWlsdG86SWRyQGlldGYub3Jn Ij5JZHJAaWV0Zi5vcmc8L2E+PC9kaXY+DQo8ZGl2PjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vaWRyIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2lkcjwvYT48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3Nw YW4+PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_D142ADD412F49balajirjunipernet_-- From nobody Thu Apr 2 06:41:19 2015 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 5660C1A92AD; Thu, 2 Apr 2015 06:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cPgI-zzGnFJQ; Thu, 2 Apr 2015 06:40:55 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B8691A8AD8; Thu, 2 Apr 2015 06:40:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=42585; q=dns/txt; s=iport; t=1427982055; x=1429191655; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ABztSo8BlBoM/NVfpk3B3TRSKOrXiMfNsskNXyuJ/r0=; b=DMmAFu5yDqW2WJZwsO/eaBnvhZgks61PMn6eERbUz4tuyAxQ31EcxZWI T/ly8daFkvel2g8ShKqCT1n+zQu27idAa3qKKiM4ZEp7abGku/I1WJn4H IbuTp/fLu07Wb22Kh0JXfeP1918hufJPRTGuoduAbQ9uKoqjWlOi0HeHt A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CuBgCKRh1V/4oNJK1SCoJFQ1JcBYMQsl2NbYFgGQEJhXMCHIEnTAEBAQEBAX6EHgEBAQQBAQEgBEcLEAIBCBEDAQIhAQIEAwICAiULFAkIAgQBDQWILw21MZgvAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4oqf4QcQgoNBAeCaIFFBY5bgg+DdYYLgR06gnqML4NIIoIygTxvgUR/AQEB X-IronPort-AV: E=Sophos;i="5.11,511,1422921600"; d="scan'208,217";a="137629185" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-1.cisco.com with ESMTP; 02 Apr 2015 13:40:54 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t32Dessx017311 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Apr 2015 13:40:54 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.236]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Thu, 2 Apr 2015 08:40:53 -0500 From: "Acee Lindem (acee)" To: Balaji Rajagopalan , "ietf@ietf.org" , Hannes Gredler Thread-Topic: [Idr] REVISED Last Call: (North-Bound Distribution of Link-State and TE Information using BGP) to Proposed Standard Thread-Index: AQHQYbN1sBT99RQ7ME2g+UypTJek+p04078A//+/7ICAAO8fAIAAX+WA Date: Thu, 2 Apr 2015 13:40:52 +0000 Message-ID: References: <20150318194048.32558.12168.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.152.196] Content-Type: multipart/alternative; boundary="_000_D142BCAB1452Eaceeciscocom_" MIME-Version: 1.0 Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] REVISED Last Call: (North-Bound Distribution of Link-State and TE Information using BGP) to Proposed Standard 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, 02 Apr 2015 13:41:05 -0000 --_000_D142BCAB1452Eaceeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQmFsYWppLA0KDQpBcyB0aGUgSUVURiBSb3V0aW5nIERpcmVjdG9yYXRlIHJldmlld2VyIG9m IHRoZSB0aGlzIGRyYWZ0LCBJIGFncmVlIHRoYXQgaXQgaXMgZmFyIGZyb20gcGVyZmVjdC4gSG93 ZXZlciwgaXQgaXMgdmVyeSBsYXRlIGluIHRoZSByZXZpZXcgY3ljbGUgYW5kIHdlIGhhdmUgc2V2 ZXJhbCBpbXBsZW1lbnRhdGlvbnMgKHJlZmVyIHRvIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWlldGYtaWRyLWxzLWRpc3RyaWJ1dGlvbi1pbXBsLykuIEl0IGlzIG5vdCB0 aGUgdGltZSB0byBjaGFuZ2UgaXQganVzdCB0byBlYXNlIHlvdXIgaW1wbGVtZW50YXRpb24uIFNl ZSBpbmxpbmUuDQoNCkZyb206IEJhbGFqaSBSYWphZ29wYWxhbiA8YmFsYWppckBqdW5pcGVyLm5l dDxtYWlsdG86YmFsYWppckBqdW5pcGVyLm5ldD4+DQpEYXRlOiBXZWRuZXNkYXksIEFwcmlsIDEs IDIwMTUgYXQgMTE6MjYgUE0NClRvOiBBY2VlIExpbmRlbSA8YWNlZUBjaXNjby5jb208bWFpbHRv OmFjZWVAY2lzY28uY29tPj4sICJpZXRmQGlldGYub3JnPG1haWx0bzppZXRmQGlldGYub3JnPiIg PGlldGZAaWV0Zi5vcmc8bWFpbHRvOmlldGZAaWV0Zi5vcmc+PiwgSGFubmVzIEdyZWRsZXIgPGhh bm5lc0BqdW5pcGVyLm5ldDxtYWlsdG86aGFubmVzQGp1bmlwZXIubmV0Pj4NCkNjOiAiaWRyQGll dGYub3JnPG1haWx0bzppZHJAaWV0Zi5vcmc+IiA8aWRyQGlldGYub3JnPG1haWx0bzppZHJAaWV0 Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtJZHJdIFJFVklTRUQgTGFzdCBDYWxsOiA8ZHJhZnQtaWV0 Zi1pZHItbHMtZGlzdHJpYnV0aW9uLTEwLnR4dD4gKE5vcnRoLUJvdW5kIERpc3RyaWJ1dGlvbiBv ZiBMaW5rLVN0YXRlIGFuZCBURSBJbmZvcm1hdGlvbiB1c2luZyBCR1ApIHRvIFByb3Bvc2VkIFN0 YW5kYXJkDQoNCkhpIEFjZWUsDQoNCkkgYWxzbyBwb2ludGVkIG91dCBhbiBpbmNvbnNpc3RlbmN5 IGJldHdlZW4gdGhlIGV4YW1wbGUgaW4gc2VjdGlvbiAzLjcgYW5kIHRoZSBub3JtYXRpdmUgdGV4 dCBpbiBzZWN0aW9uIDMuMi4xLjQuIFNvLCB0aGUgZHJhZnQgbmVlZHMgYSBjb3JyZWN0aW9uIGFu eXdheS4NCg0KVGhlIHF1ZXN0aW9uIGlzLCB3aGljaCBvbmUgbmVlZHMgdG8gYmUgY29ycmVjdGVk IOKAkyBzZWN0aW9uIDMuNywgb3Igc2VjdGlvbiAzLjIuMS40Lg0KDQpTZWN0aW9uIDMuNyBpcyBu b3QgbmVjZXNzYXJpbHkgd3JvbmcuIFdoaWxlIHRoaXMgaXMgbm90IHRoZSBiZXN0IE9TUEYgZXhh bXBsZSwgMTAuMS4xLjEgbWF5IGJlIGJvdGggdGhlIElQIGludGVyZmFjZSBhZGRyZXNzIGFuZCB0 aGUgT1NQRiBSb3V0ZXIgSUQuDQoNCg0KSU1ITywgd2Ugc2hvdWxkIGNvcnJlY3QgdGhlIG5vcm1h dGl2ZSB0ZXh0IGluIHNlY3Rpb24gMy4yLjEuNCB0byBhbGlnbiB3aXRoIHRoZSBleGFtcGxlIGlu IHNlY3Rpb24gMy43LCBhcyB0aGUgZXhhbXBsZSBtb3JlIGNsb3NlbHkgcmVmbGVjdHMgaG93IE9T UEZ2MiByZXByZXNlbnRzIHRoZSBsaW5rLg0KDQpBcmUgeW91IGZhbWlsaWFyIHdpdGggT1NQRnYz PyBJbiBPU1BGdjMsIHRoZSBSb3V0ZXItSUQgaXMgdXNlZCBpbiB0aGUgUm91dGVyLUxTQSB0byBp ZGVudGlmeSB0aGUgRFIuIEhlbmNlLCBpZiB3ZSB3ZXJlIHRvIGNoYW5nZSBpdCwgT1NQRnYzIHdv dWxkIG5lZWQgdG8gYmUgaGFuZGxlZCBzZXBhcmF0ZWx5Lg0KDQpBY2VlDQoNCg0KDQoNCg0KDQri gJQNCkJhbGFqaSBSYWphZ29wYWxhbg0KDQoNCkZyb206ICJBY2VlIExpbmRlbSAoYWNlZSkiIDxh Y2VlQGNpc2NvLmNvbTxtYWlsdG86YWNlZUBjaXNjby5jb20+Pg0KRGF0ZTogV2VkbmVzZGF5LCBB cHJpbCAxLCAyMDE1IGF0IDExOjExIFBNDQpUbzogQmFsYWppIFJhamFnb3BhbGFuIDxiYWxhamly QGp1bmlwZXIubmV0PG1haWx0bzpiYWxhamlyQGp1bmlwZXIubmV0Pj4sICJpZXRmQGlldGYub3Jn PG1haWx0bzppZXRmQGlldGYub3JnPiIgPGlldGZAaWV0Zi5vcmc8bWFpbHRvOmlldGZAaWV0Zi5v cmc+PiwgSGFubmVzIEdyZWRsZXIgPGhhbm5lc0BqdW5pcGVyLm5ldDxtYWlsdG86aGFubmVzQGp1 bmlwZXIubmV0Pj4NCkNjOiAiaWRyQGlldGYub3JnPG1haWx0bzppZHJAaWV0Zi5vcmc+IiA8aWRy QGlldGYub3JnPG1haWx0bzppZHJAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtJZHJdIFJFVklT RUQgTGFzdCBDYWxsOiA8ZHJhZnQtaWV0Zi1pZHItbHMtZGlzdHJpYnV0aW9uLTEwLnR4dD4gKE5v cnRoLUJvdW5kIERpc3RyaWJ1dGlvbiBvZiBMaW5rLVN0YXRlIGFuZCBURSBJbmZvcm1hdGlvbiB1 c2luZyBCR1ApIHRvIFByb3Bvc2VkIFN0YW5kYXJkDQoNCkJhbGFqaSwNCg0KVGhpcyBpcyBhbiBp bXBsZW1lbnRhdGlvbiBpc3N1ZSBiYXNlZCBvbiB0aGUgZmFjdCB0aGF0IHlvdSBhcmUgZGVyaXZp bmcgdGhlIEJHUCBMUyBpbmZvcm1hdGlvbiBmcm9tIHRoZSBMU0FzIHJhdGhlciB0aGFuIGhhdmlu ZyB0aGUgSUdQIGluc3RhbGwgdGhlIG5vcm1hbGl6ZWQgZHJhZnQtaWV0Zi1pZHItbHMtZGlzdHJp YnV0aW9uIGxpbmtzLiBHaXZlbiB0aGF0IHRoZSBkcmFmdCBpcyB3aXRoIHRoZSBJRVNHLCBJ4oCZ bSBub3Qgc3VyZSB3ZSB3YW50IHRvIGF0dGVtcHQgdG8gb3B0aW1pemUgaXQgdG8geW91ciBpbXBs ZW1lbnRhdGlvbiBhbmQgZGlzcnVwdGl2ZSBldmVyeW9uZSBlbHNl4oCZcy4gSWYgeW91IGFyZSBt YWludGFpbmluZyB0aGUgTFNBcyBpbiBhbiBPU1BGIExTREIgdHlwZSBzdHJ1Y3R1cmUgaW4gQkdQ LCB5b3UgZWFzaWx5IGZpbmQgdGhlIE5ldHdvcmsgTFNBIGFuZCBleHRyYWN0IHRoZSBhZHZlcnRp c2luZyByb3V0ZXIuDQoNClRoYW5rcywNCkFjZWUNCg0KRnJvbTogQmFsYWppIFJhamFnb3BhbGFu IDxiYWxhamlyQGp1bmlwZXIubmV0PG1haWx0bzpiYWxhamlyQGp1bmlwZXIubmV0Pj4NCkRhdGU6 IFdlZG5lc2RheSwgQXByaWwgMSwgMjAxNSBhdCAxOjAwIFBNDQpUbzogImlldGZAaWV0Zi5vcmc8 bWFpbHRvOmlldGZAaWV0Zi5vcmc+IiA8aWV0ZkBpZXRmLm9yZzxtYWlsdG86aWV0ZkBpZXRmLm9y Zz4+LCBIYW5uZXMgR3JlZGxlciA8aGFubmVzQGp1bmlwZXIubmV0PG1haWx0bzpoYW5uZXNAanVu aXBlci5uZXQ+Pg0KQ2M6ICJpZHJAaWV0Zi5vcmc8bWFpbHRvOmlkckBpZXRmLm9yZz4iIDxpZHJA aWV0Zi5vcmc8bWFpbHRvOmlkckBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW0lkcl0gUkVWSVNF RCBMYXN0IENhbGw6IDxkcmFmdC1pZXRmLWlkci1scy1kaXN0cmlidXRpb24tMTAudHh0PiAoTm9y dGgtQm91bmQgRGlzdHJpYnV0aW9uIG9mIExpbmstU3RhdGUgYW5kIFRFIEluZm9ybWF0aW9uIHVz aW5nIEJHUCkgdG8gUHJvcG9zZWQgU3RhbmRhcmQNCg0KSSBzZWVrIGEgY29ycmVjdGlvbiB0byB0 aGUgZm9sbG93aW5nIHRleHQgaW4gc2VjdGlvbiAzLjIuMS40Lg0KDQoiDQpJR1AgUm91dGVyIElE OiA8c25pcD4gRm9yIGFuIE9TUEZ2MiAiUHNldWRvbm9kZSIgcmVwcmVzZW50aW5nIGEgTEFOLA0K DQogICAgICB0aGlzIGNvbnRhaW5zIHRoZSA0IG9jdGV0IFJvdXRlci1JRCBvZiB0aGUgZGVzaWdu YXRlZCByb3V0ZXIgKERSKQ0KICAgICAgZm9sbG93ZWQgYnkgdGhlIDQgb2N0ZXQgSVB2NCBhZGRy ZXNzIG9mIHRoZSBEUidzIGludGVyZmFjZSB0byB0aGUNCiAgICAgIExBTiAoOCBvY3RldHMgaW4g dG90YWwpIDxzbmlwPiINCg0KDQpUaGUgcmVhc29uIEkgc2VlayB0aGlzIGNoYW5nZSBpcywgdGhl IHRyYW5zaXQgbGluayByZXByZXNlbnRhdGlvbiBpbiBPU1BGdjIgcm91dGVyLUxTQSBkb2VzIG5v dCBjb250YWluIHRoZSByb3V0ZXItaWQgb2YgdGhlIERSIChzZWN0aW9uIDEyLjQuMS4yIG9mIFJG QzIzMjgpLiBTbywgQkdQLUxTIGhhcyBub3doZXJlIHRvIGRlcml2ZSBSb3V0ZXItSUQgZnJvbS4N Cg0KDQpCZWxvdyBhcmUgbW9yZSBkZXRhaWxzIHdpdGggYW4gZXhhbXBsZS4NCg0KDQpUaGUgJ0lH UCByb3V0ZXIgSUQnIGZpZWxkIGNhbiBhcHBlYXIgZWl0aGVyIGluIOKAmExvY2FsIE5vZGUgRGVz Y3JpcHRvcuKAmSBvciDigJhSZW1vdGUgTm9kZSBEZXNjcmlwdG9y4oCZLiBMZXTigJlzIGNvbnNp ZGVyIHRoZSBjYXNlIGluIHdoaWNoIHRoaXMgZmllbGQgYXBwZWFycyBpbiDigJhSZW1vdGUgTm9k ZSBEZXNjcmlwdG9y4oCZIGluIHRoZSBmb2xsb3dpbmcgdG9wb2xvZ3kuDQoNCg0KUjEoMS4xLjEu MTo6MTAuMTAuMTAuMSkgPC0tLS1MMS0tLS0+IFIyICgyLjIuMi4yOjoxMC4xMC4xMC4yKQ0KDQpX aGVyZSwNClIxJ3Mgcm91dGVyLWlkIGlzIDEuMS4xLjEsIGFuZCBMMSBpbnRlcmZhY2UgSVAgYWRk cmVzcyBpcyAxMC4xMC4xMC4xLg0KUjIncyByb3V0ZXItaWQgaXMgMi4yLjIuMiwgYW5kIEwxIGlu dGVyZmFjZSBJUCBhZGRyZXNzIGlzIDEwLjEwLjEwLjIuDQpMMSBpcyBhIExBTi4NClIxIGlzIGVs ZWN0ZWQgYXMgdGhlIERSIGZvciBMMS4NCg0KVGhlcmUgYXJlIGZvdXIgZGlzdGluY3QgdW5pZGly ZWN0aW9uYWwgbGlua3MgaW4gdGhlIHRvcG9sb2d5IGFib3ZlOiBSMS0+RFIsIERSLT5SMSwgUjIt PkRSLCBhbmQgRFItPlIyLiBMZXTigJlzIGNvbnNpZGVyIHRoZSBsaW5rIFIyLT5EUi4gUjLigJlz IHJvdXRlciBMU0EgcmVwcmVzZW50cyBSMi0+RFIgbGluayBhcyBmb2xsb3dzOiAtDQoNCkFkdmVy dGlzaW5nIHJvdXRlcjoyLjIuMi4yDQogICBMaW5rIElEOiAxMC4xMC4xMC4xDQogICBMaW5rIGRh dGE6MTAuMTAuMTAuMg0KICAgVHlwZToyIChUcmFuc2l0KQ0KDQpOb3RlIHRoYXQgdGhlIE9TUEYg bGluayByZXByZXNlbnRhdGlvbiBhYm92ZSBkb2VzIG5vdCBpbmNsdWRlIHRoZSByb3V0ZXItaWQg b2YgdGhlIERSLCB3aGljaCBpcyAxLjEuMS4xLg0KDQoNCkFjY29yZGluZyB0byB0aGUgdGV4dCBp biBzZWN0aW9uIDMuMi4xLjQsIEJHUC1MUyByZXF1aXJlcyB1cyB0byByZXByZXNlbnQgUjItPkRS IGxpbmsgYXMgZm9sbG93cyAoY29uc2lkZXJpbmcgb25seSBub2RlIGRlc2NyaXB0b3JzIG9mIHJl bGV2YW5jZSB0byB0aGlzIGRpc2N1c3Npb24sIGFuZCBpZ25vcmluZyB0aGUgcmVtYWluaW5nIGZp ZWxkcykgOiAtDQoNCkxvY2FsIE5vZGUoSUdQLVJvdXRlci1JZDoyLjIuMi4yKSAtPiBSZW1vdGUg Tm9kZShJR1AtUm91dGVyLUlkOjEuMS4xLjEtMTAuMTAuMTAuMSkNCg0KDQpIb3dldmVyLCB0aGUg T1NQRiByZXByZXNlbnRhdGlvbiBvZiB0aGUgYWJvdmUgbGluayBpbiBSMuKAmXMgcm91dGVyIExT QSBkb2VzIG5vdCBjb250YWluIDEuMS4xLjEgYXQgYWxsLiBUaGVyZWZvcmUsIEJHUC1MUyBoYXMg bm93aGVyZSB0byBkZXJpdmUg4oCYMS4xLjEuMeKAmSBmcm9tLCBmb3IgdGhlIGxpbmsgUjItPkRS Lg0KDQpUaGUgZXhhbXBsZSBpbiBzZWN0aW9uIDMuNyBpcyBhdCBvZGRzIHdpdGggdGhlIHRleHQg aW4gc2VjdGlvbiAzLjIuMS40LCBhbmQgcmVwcmVzZW50cyB0aGUgbGluayBhcyBmb2xsb3dzICh3 aGljaCB3b3JrcyBwZXJmZWN0bHkpOiAtDQoNCg0KTG9jYWwgTm9kZShJR1AtUm91dGVyLUlkOjIu Mi4yLjIpIC0+IFJlbW90ZSBOb2RlKElHUC1Sb3V0ZXItSWQ6MTAuMTAuMTAuMS0xMC4xMC4xMC4x KQ0KDQoNCkkgc3VnZ2VzdCByZXdvcmRpbmcgdGhlIHRleHQgaW4gMy4yLjEuNCBhcyBmb2xsb3dz Og0KDQoiDQpJR1AgUm91dGVyIElEOiA8c25pcD4gRm9yIGFuIE9TUEZ2MiAiUHNldWRvbm9kZSIg cmVwcmVzZW50aW5nIGEgTEFOLA0KDQogICAgICB0aGlzIGNvbnRhaW5zIHRoZSA0IG9jdGV0IElQ djQgYWRkcmVzcyBvZiB0aGUgRFIncyBpbnRlcmZhY2UgdG8gdGhlDQogICAgICBMQU4sIGZvbGxv d2VkIGJ5IGFueSBub24temVybyA0LW9jdGV0IG51bWJlciAoOCBvY3RldHMgaW4gdG90YWwpIDxz bmlwPuKAnQ0KDQoNCuKAlA0KQmFsYWppIFJhamFnb3BhbGFuDQoNCg0KDQoNCkZyb206IFRoZSBJ RVNHIDxpZXNnLXNlY3JldGFyeUBpZXRmLm9yZzxtYWlsdG86aWVzZy1zZWNyZXRhcnlAaWV0Zi5v cmc+Pg0KUmVwbHktVG86ICJpZXRmQGlldGYub3JnPG1haWx0bzppZXRmQGlldGYub3JnPiIgPGll dGZAaWV0Zi5vcmc8bWFpbHRvOmlldGZAaWV0Zi5vcmc+Pg0KRGF0ZTogVGh1cnNkYXksIE1hcmNo IDE5LCAyMDE1IGF0IDE6MTAgQU0NClRvOiBJRVRGLUFubm91bmNlIDxpZXRmLWFubm91bmNlQGll dGYub3JnPG1haWx0bzppZXRmLWFubm91bmNlQGlldGYub3JnPj4NCkNjOiAiaWRyQGlldGYub3Jn PG1haWx0bzppZHJAaWV0Zi5vcmc+IiA8aWRyQGlldGYub3JnPG1haWx0bzppZHJAaWV0Zi5vcmc+ Pg0KU3ViamVjdDogW0lkcl0gUkVWSVNFRCBMYXN0IENhbGw6IDxkcmFmdC1pZXRmLWlkci1scy1k aXN0cmlidXRpb24tMTAudHh0PiAoTm9ydGgtQm91bmQgRGlzdHJpYnV0aW9uIG9mIExpbmstU3Rh dGUgYW5kIFRFIEluZm9ybWF0aW9uIHVzaW5nIEJHUCkgdG8gUHJvcG9zZWQgU3RhbmRhcmQNCg0K DQpUaGUgSUVTRyBoYXMgcmVjZWl2ZWQgYSByZXF1ZXN0IGZyb20gdGhlIEludGVyLURvbWFpbiBS b3V0aW5nIFdHIChpZHIpIHRvDQpjb25zaWRlciB0aGUgZm9sbG93aW5nIGRvY3VtZW50Og0KLSAn Tm9ydGgtQm91bmQgRGlzdHJpYnV0aW9uIG9mIExpbmstU3RhdGUgYW5kIFRFIEluZm9ybWF0aW9u IHVzaW5nIEJHUCcNCiAgPGRyYWZ0LWlldGYtaWRyLWxzLWRpc3RyaWJ1dGlvbi0xMC50eHQ+IGFz IFByb3Bvc2VkIFN0YW5kYXJkDQoNClRoZSBJRVNHIHBsYW5zIHRvIG1ha2UgYSBkZWNpc2lvbiBp biB0aGUgbmV4dCBmZXcgd2Vla3MsIGFuZCBzb2xpY2l0cw0KZmluYWwgY29tbWVudHMgb24gdGhp cyBhY3Rpb24uIFBsZWFzZSBzZW5kIHN1YnN0YW50aXZlIGNvbW1lbnRzIHRvIHRoZQ0KaWV0ZkBp ZXRmLm9yZzxtYWlsdG86aWV0ZkBpZXRmLm9yZz4gbWFpbGluZyBsaXN0cyBieSAyMDE1LTA0LTA4 LiBFeGNlcHRpb25hbGx5LCBjb21tZW50cyBtYXkgYmUNCnNlbnQgdG8gaWVzZ0BpZXRmLm9yZzxt YWlsdG86aWVzZ0BpZXRmLm9yZz4gaW5zdGVhZC4gSW4gZWl0aGVyIGNhc2UsIHBsZWFzZSByZXRh aW4gdGhlDQpiZWdpbm5pbmcgb2YgdGhlIFN1YmplY3QgbGluZSB0byBhbGxvdyBhdXRvbWF0ZWQg c29ydGluZy4NCg0KQWJzdHJhY3QNCg0KDQogICBJbiBhIG51bWJlciBvZiBlbnZpcm9ubWVudHMs IGEgY29tcG9uZW50IGV4dGVybmFsIHRvIGEgbmV0d29yayBpcw0KICAgY2FsbGVkIHVwb24gdG8g cGVyZm9ybSBjb21wdXRhdGlvbnMgYmFzZWQgb24gdGhlIG5ldHdvcmsgdG9wb2xvZ3kgYW5kDQog ICBjdXJyZW50IHN0YXRlIG9mIHRoZSBjb25uZWN0aW9ucyB3aXRoaW4gdGhlIG5ldHdvcmssIGlu Y2x1ZGluZw0KICAgdHJhZmZpYyBlbmdpbmVlcmluZyBpbmZvcm1hdGlvbi4gIFRoaXMgaXMgaW5m b3JtYXRpb24gdHlwaWNhbGx5DQogICBkaXN0cmlidXRlZCBieSBJR1Agcm91dGluZyBwcm90b2Nv bHMgd2l0aGluIHRoZSBuZXR3b3JrLg0KDQogICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIG1l Y2hhbmlzbSBieSB3aGljaCBsaW5rcyBzdGF0ZSBhbmQgdHJhZmZpYw0KICAgZW5naW5lZXJpbmcg aW5mb3JtYXRpb24gY2FuIGJlIGNvbGxlY3RlZCBmcm9tIG5ldHdvcmtzIGFuZCBzaGFyZWQNCiAg IHdpdGggZXh0ZXJuYWwgY29tcG9uZW50cyB1c2luZyB0aGUgQkdQIHJvdXRpbmcgcHJvdG9jb2wu ICBUaGlzIGlzDQogICBhY2hpZXZlZCB1c2luZyBhIG5ldyBCR1AgTmV0d29yayBMYXllciBSZWFj aGFiaWxpdHkgSW5mb3JtYXRpb24NCiAgIChOTFJJKSBlbmNvZGluZyBmb3JtYXQuICBUaGUgbWVj aGFuaXNtIGlzIGFwcGxpY2FibGUgdG8gcGh5c2ljYWwgYW5kDQogICB2aXJ0dWFsIElHUCBsaW5r cy4gIFRoZSBtZWNoYW5pc20gZGVzY3JpYmVkIGlzIHN1YmplY3QgdG8gcG9saWN5DQogICBjb250 cm9sLg0KDQogICBBcHBsaWNhdGlvbnMgb2YgdGhpcyB0ZWNobmlxdWUgaW5jbHVkZSBBcHBsaWNh dGlvbiBMYXllciBUcmFmZmljDQogICBPcHRpbWl6YXRpb24gKEFMVE8pIHNlcnZlcnMsIGFuZCBQ YXRoIENvbXB1dGF0aW9uIEVsZW1lbnRzIChQQ0VzKS4NCg0KDQoNCg0KDQpUaGUgZmlsZSBjYW4g YmUgb2J0YWluZWQgdmlhDQpodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll dGYtaWRyLWxzLWRpc3RyaWJ1dGlvbi8NCg0KSUVTRyBkaXNjdXNzaW9uIGNhbiBiZSB0cmFja2Vk IHZpYQ0KaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWlkci1scy1k aXN0cmlidXRpb24vYmFsbG90Lw0KDQoNClRoZSBmb2xsb3dpbmcgSVBSIERlY2xhcmF0aW9ucyBt YXkgYmUgcmVsYXRlZCB0byB0aGlzIEktRDoNCg0KICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYu b3JnL2lwci8xODY0Lw0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCklkciBtYWlsaW5nIGxpc3QNCklkckBpZXRmLm9yZzxtYWlsdG86SWRyQGll dGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZHINCg0K --_000_D142BCAB1452Eaceeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <296D2BB713B1FC4680BAA344769C5CC1@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5IaSBCYWxhamks Jm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5BcyB0aGUgSUVURiBSb3V0aW5n IERpcmVjdG9yYXRlIHJldmlld2VyIG9mIHRoZSB0aGlzIGRyYWZ0LCBJIGFncmVlIHRoYXQgaXQg aXMgZmFyIGZyb20gcGVyZmVjdC4gSG93ZXZlciwgaXQgaXMgdmVyeSBsYXRlIGluIHRoZSByZXZp ZXcgY3ljbGUgYW5kIHdlIGhhdmUgc2V2ZXJhbCBpbXBsZW1lbnRhdGlvbnMgKHJlZmVyIHRvIGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaWRyLWxzLWRpc3RyaWJ1 dGlvbi1pbXBsLykuDQogSXQgaXMgbm90IHRoZSB0aW1lIHRvIGNoYW5nZSBpdCBqdXN0IHRvIGVh c2UgeW91ciBpbXBsZW1lbnRhdGlvbi4gU2VlIGlubGluZS4mbmJzcDs8L2Rpdj4NCjxkaXY+PGJy Pg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdiBzdHlsZT0i Zm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjExcHQ7IHRleHQtYWxpZ246bGVmdDsgY29s b3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVItTEVGVDogbWVkaXVt IG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGluOyBQQURESU5HLVJJ R0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JERVItUklHSFQ6IG1l ZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpi b2xkIj5Gcm9tOiA8L3NwYW4+QmFsYWppIFJhamFnb3BhbGFuICZsdDs8YSBocmVmPSJtYWlsdG86 YmFsYWppckBqdW5pcGVyLm5ldCI+YmFsYWppckBqdW5pcGVyLm5ldDwvYT4mZ3Q7PGJyPg0KPHNw YW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5XZWRuZXNkYXksIEFwcmls IDEsIDIwMTUgYXQgMTE6MjYgUE08YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+ VG86IDwvc3Bhbj5BY2VlIExpbmRlbSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFjZWVAY2lzY28uY29t Ij5hY2VlQGNpc2NvLmNvbTwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86aWV0ZkBpZXRm Lm9yZyI+aWV0ZkBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzppZXRmQGll dGYub3JnIj5pZXRmQGlldGYub3JnPC9hPiZndDssIEhhbm5lcyBHcmVkbGVyICZsdDs8YSBocmVm PSJtYWlsdG86aGFubmVzQGp1bmlwZXIubmV0Ij5oYW5uZXNAanVuaXBlci5uZXQ8L2E+Jmd0Ozxi cj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5DYzogPC9zcGFuPiZxdW90OzxhIGhy ZWY9Im1haWx0bzppZHJAaWV0Zi5vcmciPmlkckBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhy ZWY9Im1haWx0bzppZHJAaWV0Zi5vcmciPmlkckBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHNwYW4g c3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5SZTogW0lkcl0gUkVWSVNF RCBMYXN0IENhbGw6ICZsdDtkcmFmdC1pZXRmLWlkci1scy1kaXN0cmlidXRpb24tMTAudHh0Jmd0 OyAoTm9ydGgtQm91bmQgRGlzdHJpYnV0aW9uIG9mIExpbmstU3RhdGUgYW5kIFRFIEluZm9ybWF0 aW9uIHVzaW5nIEJHUCkgdG8gUHJvcG9zZWQgU3RhbmRhcmQ8YnI+DQo8L2Rpdj4NCjxkaXY+PGJy Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tR VU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUgc29saWQ7IFBBRERJTkc6MCAwIDAg NTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFr LXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRl ci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAxNXB4OyBmb250 LWZhbWlseTogQ29uc29sYXMsIHNhbnMtc2VyaWY7Ij4NCjxkaXY+SGkgQWNlZSw8L2Rpdj4NCjxk aXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkkgYWxzbyBwb2ludGVkIG91dCBhbiBpbmNvbnNpc3RlbmN5 IGJldHdlZW4gdGhlIGV4YW1wbGUgaW4gc2VjdGlvbiAzLjcgYW5kIHRoZSBub3JtYXRpdmUgdGV4 dCBpbiBzZWN0aW9uIDMuMi4xLjQuIFNvLCB0aGUgZHJhZnQgbmVlZHMgYSBjb3JyZWN0aW9uIGFu eXdheS48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoZSBxdWVzdGlvbiBpcywgd2hp Y2ggb25lIG5lZWRzIHRvIGJlIGNvcnJlY3RlZCDigJMgc2VjdGlvbiAzLjcsIG9yIHNlY3Rpb24g My4yLjEuNC48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+DQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5TZWN0aW9uIDMuNyBpcyBub3QgbmVjZXNzYXJpbHkgd3Jv bmcuIFdoaWxlIHRoaXMgaXMgbm90IHRoZSBiZXN0IE9TUEYgZXhhbXBsZSwgMTAuMS4xLjEgbWF5 IGJlIGJvdGggdGhlIElQIGludGVyZmFjZSBhZGRyZXNzIGFuZCB0aGUgT1NQRiBSb3V0ZXIgSUQu Jm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9T RUNUSU9OIj4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FV T1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElORzowIDAgMCA1 OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRpdj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWst d29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVy LXdoaXRlLXNwYWNlOyBjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LXNpemU6IDE1cHg7IGZvbnQt ZmFtaWx5OiBDb25zb2xhcywgc2Fucy1zZXJpZjsiPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+ SU1ITywgd2Ugc2hvdWxkIGNvcnJlY3QgdGhlIG5vcm1hdGl2ZSB0ZXh0IGluIHNlY3Rpb24gMy4y LjEuNCB0byBhbGlnbiB3aXRoIHRoZSBleGFtcGxlIGluIHNlY3Rpb24gMy43LCBhcyB0aGUgZXhh bXBsZSBtb3JlIGNsb3NlbHkgcmVmbGVjdHMgaG93IE9TUEZ2MiByZXByZXNlbnRzIHRoZSBsaW5r LjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4NCjxkaXY+PGJy Pg0KPC9kaXY+DQo8ZGl2PkFyZSB5b3UgZmFtaWxpYXIgd2l0aCBPU1BGdjM/IEluIE9TUEZ2Mywg dGhlIFJvdXRlci1JRCBpcyB1c2VkIGluIHRoZSBSb3V0ZXItTFNBIHRvIGlkZW50aWZ5IHRoZSBE Ui4gSGVuY2UsIGlmIHdlIHdlcmUgdG8gY2hhbmdlIGl0LCBPU1BGdjMgd291bGQgbmVlZCB0byBi ZSBoYW5kbGVkIHNlcGFyYXRlbHkuJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRp dj5BY2VlJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N CjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N CjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09V VExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRm IDUgc29saWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsg LXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAw KTsgZm9udC1zaXplOiAxNXB4OyBmb250LWZhbWlseTogQ29uc29sYXMsIHNhbnMtc2VyaWY7Ij4N CjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PuKAlDwvZGl2Pg0KPGRpdj5CYWxhamkgUmFqYWdvcGFs YW48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9 Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7 IGZvbnQtc2l6ZToxMXB0OyB0ZXh0LWFsaWduOmxlZnQ7IGNvbG9yOmJsYWNrOyBCT1JERVItQk9U VE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6IG1lZGl1bSBub25lOyBQQURESU5HLUJPVFRP TTogMGluOyBQQURESU5HLUxFRlQ6IDBpbjsgUEFERElORy1SSUdIVDogMGluOyBCT1JERVItVE9Q OiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1U T1A6IDNwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTogPC9zcGFuPiZx dW90O0FjZWUgTGluZGVtIChhY2VlKSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFjZWVAY2lz Y28uY29tIj5hY2VlQGNpc2NvLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2Vp Z2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5XZWRuZXNkYXksIEFwcmlsIDEsIDIwMTUgYXQgMTE6MTEg UE08YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bhbj5CYWxhamkg UmFqYWdvcGFsYW4gJmx0OzxhIGhyZWY9Im1haWx0bzpiYWxhamlyQGp1bmlwZXIubmV0Ij5iYWxh amlyQGp1bmlwZXIubmV0PC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzppZXRmQGlldGYu b3JnIj5pZXRmQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlldGZAaWV0 Zi5vcmciPmlldGZAaWV0Zi5vcmc8L2E+Jmd0OywgSGFubmVzIEdyZWRsZXIgJmx0OzxhIGhyZWY9 Im1haWx0bzpoYW5uZXNAanVuaXBlci5uZXQiPmhhbm5lc0BqdW5pcGVyLm5ldDwvYT4mZ3Q7PGJy Pg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkNjOiA8L3NwYW4+JnF1b3Q7PGEgaHJl Zj0ibWFpbHRvOmlkckBpZXRmLm9yZyI+aWRyQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmlkckBpZXRmLm9yZyI+aWRyQGlldGYub3JnPC9hPiZndDs8YnI+DQo8c3BhbiBz dHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFuPlJlOiBbSWRyXSBSRVZJU0VE IExhc3QgQ2FsbDogJmx0O2RyYWZ0LWlldGYtaWRyLWxzLWRpc3RyaWJ1dGlvbi0xMC50eHQmZ3Q7 IChOb3J0aC1Cb3VuZCBEaXN0cmlidXRpb24gb2YgTGluay1TdGF0ZSBhbmQgVEUgSW5mb3JtYXRp b24gdXNpbmcgQkdQKSB0byBQcm9wb3NlZCBTdGFuZGFyZDxicj4NCjwvZGl2Pg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FV T1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElORzowIDAgMCA1 OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRpdj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWst d29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVy LXdoaXRlLXNwYWNlOyBjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LXNpemU6IDE0cHg7IGZvbnQt ZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+DQo8ZGl2PkJhbGFqaSwmbmJzcDs8L2Rpdj4N CjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoaXMgaXMgYW4gaW1wbGVtZW50YXRpb24gaXNzdWUg YmFzZWQgb24gdGhlIGZhY3QgdGhhdCB5b3UgYXJlIGRlcml2aW5nIHRoZSBCR1AgTFMgaW5mb3Jt YXRpb24gZnJvbSB0aGUgTFNBcyByYXRoZXIgdGhhbiBoYXZpbmcgdGhlIElHUCBpbnN0YWxsIHRo ZSBub3JtYWxpemVkIGRyYWZ0LWlldGYtaWRyLWxzLWRpc3RyaWJ1dGlvbiBsaW5rcy4gR2l2ZW4g dGhhdCB0aGUgZHJhZnQgaXMgd2l0aCB0aGUgSUVTRywgSeKAmW0gbm90IHN1cmUgd2UNCiB3YW50 IHRvIGF0dGVtcHQgdG8gb3B0aW1pemUgaXQgdG8geW91ciBpbXBsZW1lbnRhdGlvbiBhbmQgZGlz cnVwdGl2ZSBldmVyeW9uZSBlbHNl4oCZcy4gSWYgeW91IGFyZSBtYWludGFpbmluZyB0aGUgTFNB cyBpbiBhbiBPU1BGIExTREIgdHlwZSBzdHJ1Y3R1cmUgaW4gQkdQLCB5b3UgZWFzaWx5IGZpbmQg dGhlIE5ldHdvcmsgTFNBIGFuZCBleHRyYWN0IHRoZSBhZHZlcnRpc2luZyByb3V0ZXIuJm5ic3A7 PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGFua3MsPC9kaXY+DQo8ZGl2PkFjZWUm bmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NF Q1RJT04iPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjExcHQ7 IHRleHQtYWxpZ246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25l OyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkct TEVGVDogMGluOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNv bGlkOyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFu IHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+QmFsYWppIFJhamFnb3BhbGFu ICZsdDs8YSBocmVmPSJtYWlsdG86YmFsYWppckBqdW5pcGVyLm5ldCI+YmFsYWppckBqdW5pcGVy Lm5ldDwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwv c3Bhbj5XZWRuZXNkYXksIEFwcmlsIDEsIDIwMTUgYXQgMTowMCBQTTxicj4NCjxzcGFuIHN0eWxl PSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPiZxdW90OzxhIGhyZWY9Im1haWx0bzppZXRm QGlldGYub3JnIj5pZXRmQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmll dGZAaWV0Zi5vcmciPmlldGZAaWV0Zi5vcmc8L2E+Jmd0OywgSGFubmVzIEdyZWRsZXIgJmx0Ozxh IGhyZWY9Im1haWx0bzpoYW5uZXNAanVuaXBlci5uZXQiPmhhbm5lc0BqdW5pcGVyLm5ldDwvYT4m Z3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkNjOiA8L3NwYW4+JnF1b3Q7 PGEgaHJlZj0ibWFpbHRvOmlkckBpZXRmLm9yZyI+aWRyQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmlkckBpZXRmLm9yZyI+aWRyQGlldGYub3JnPC9hPiZndDs8YnI+DQo8 c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFuPlJlOiBbSWRyXSBS RVZJU0VEIExhc3QgQ2FsbDogJmx0O2RyYWZ0LWlldGYtaWRyLWxzLWRpc3RyaWJ1dGlvbi0xMC50 eHQmZ3Q7IChOb3J0aC1Cb3VuZCBEaXN0cmlidXRpb24gb2YgTGluay1TdGF0ZSBhbmQgVEUgSW5m b3JtYXRpb24gdXNpbmcgQkdQKSB0byBQcm9wb3NlZCBTdGFuZGFyZDxicj4NCjwvZGl2Pg0KPGRp dj48YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9C TE9DS1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElORzow IDAgMCA1OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRpdj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDog YnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6 IGFmdGVyLXdoaXRlLXNwYWNlOyI+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBm b250LWZhbWlseTogQ29uc29sYXMsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTVweDsiPg0KSSBz ZWVrIGEgY29ycmVjdGlvbiB0byB0aGUgZm9sbG93aW5nIHRleHQgaW4gc2VjdGlvbiAzLjIuMS40 LjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENv bnNvbGFzLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE1cHg7Ij4NCjxicj4NCjwvZGl2Pg0KPGRp diBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENvbnNvbGFzLCBzYW5z LXNlcmlmOyBmb250LXNpemU6IDE1cHg7Ij4NCiZxdW90OzwvZGl2Pg0KPGRpdiBzdHlsZT0iY29s b3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENvbnNvbGFzLCBzYW5zLXNlcmlmOyBmb250 LXNpemU6IDE1cHg7Ij4NCklHUCBSb3V0ZXIgSUQ6ICZsdDtzbmlwJmd0OyZuYnNwOzxzcGFuIHN0 eWxlPSJsaW5lLWhlaWdodDogMS4yZW07Ij5Gb3IgYW4gT1NQRnYyICZxdW90O1BzZXVkb25vZGUm cXVvdDsgcmVwcmVzZW50aW5nIGEgTEFOLDwvc3Bhbj48L2Rpdj4NCjxwcmUgc3R5bGU9ImNvbG9y OiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDb25zb2xhcywgc2Fucy1zZXJpZjsgZm9udC1z aXplOiAxNXB4OyBsaW5lLWhlaWdodDogMS4yZW07IG1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJv dHRvbTogMHB4OyI+PGZvbnQgZmFjZT0iQ29uc29sYXMiPiAgICAgIHRoaXMgY29udGFpbnMgdGhl IDQgb2N0ZXQgUm91dGVyLUlEIG9mIHRoZSBkZXNpZ25hdGVkIHJvdXRlciAoRFIpDQogICAgICBm b2xsb3dlZCBieSB0aGUgNCBvY3RldCBJUHY0IGFkZHJlc3Mgb2YgdGhlIERSJ3MgaW50ZXJmYWNl IHRvIHRoZQ0KICAgICAgTEFOICg4IG9jdGV0cyBpbiB0b3RhbCkgJmx0O3NuaXAmZ3Q7JnF1b3Q7 PC9mb250PjwvcHJlPg0KPHByZSBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1p bHk6IENvbnNvbGFzLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE1cHg7IGxpbmUtaGVpZ2h0OiAx LjJlbTsgbWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7Ij48YnI+PC9wcmU+DQo8 cHJlIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ29uc29sYXMsIHNh bnMtc2VyaWY7IGZvbnQtc2l6ZTogMTVweDsgbWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9t OiAwcHg7Ij48Zm9udCBmYWNlPSJDb25zb2xhcyI+PHNwYW4gc3R5bGU9ImxpbmUtaGVpZ2h0OiAx OHB4OyI+VGhlIHJlYXNvbiBJIHNlZWsgdGhpcyBjaGFuZ2UgaXMsIHQ8L3NwYW4+PC9mb250Pjxm b250IGZhY2U9IkNvbnNvbGFzIiBzdHlsZT0iZm9udC1zaXplOiAxNXB4OyBsaW5lLWhlaWdodDog MS4yZW07Ij5oZSB0cmFuc2l0IGxpbmsgcmVwcmVzZW50YXRpb24gaW4gT1NQRnYyIHJvdXRlci1M U0EgZG9lcyBub3QgY29udGFpbiB0aGUgcm91dGVyLWlkIG9mIHRoZSBEUiA8L2ZvbnQ+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTogMTVweDsgbGluZS1oZWlnaHQ6IDEuMmVtOyBmb250LWZhbWlseTog Q29uc29sYXM7Ij4oc2VjdGlvbiAxMi40LjEuMiBvZiBSRkMyMzI4KTwvc3Bhbj48Zm9udCBmYWNl PSJDb25zb2xhcyI+PHNwYW4gc3R5bGU9ImxpbmUtaGVpZ2h0OiAxLjJlbTsiPi4mbmJzcDtTbywg QkdQLUxTIGhhcyBub3doZXJlIHRvIGRlcml2ZSBSb3V0ZXItSUQgZnJvbS48L3NwYW4+PC9mb250 PjwvcHJlPg0KPHByZSBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENv bnNvbGFzLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE1cHg7IGxpbmUtaGVpZ2h0OiAxLjJlbTsg bWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7Ij48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6IENvbnNvbGFzOyBsaW5lLWhlaWdodDogMS4yZW07Ij48YnI+PC9zcGFuPjwvcHJlPg0K PHByZSBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENvbnNvbGFzLCBz YW5zLXNlcmlmOyBmb250LXNpemU6IDE1cHg7IGxpbmUtaGVpZ2h0OiAxLjJlbTsgbWFyZ2luLXRv cDogMHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IENv bnNvbGFzOyBsaW5lLWhlaWdodDogMS4yZW07Ij5CZWxvdyBhcmUgbW9yZSBkZXRhaWxzIHdpdGgg YW4gZXhhbXBsZS48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDAp OyBmb250LWZhbWlseTogQ29uc29sYXMsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTVweDsgbGlu ZS1oZWlnaHQ6IDEuMmVtOyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsiPjxm b250IGZhY2U9IkNvbnNvbGFzIj48YnI+PC9mb250PjwvcHJlPg0KPHByZSBzdHlsZT0iY29sb3I6 IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENvbnNvbGFzLCBzYW5zLXNlcmlmOyBmb250LXNp emU6IDE1cHg7IG1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyI+PGZvbnQgZmFj ZT0iQ29uc29sYXMiPjxzcGFuIHN0eWxlPSJsaW5lLWhlaWdodDogMS4yZW07Ij5UaGUgJ0lHUCBy b3V0ZXIgSUQnIGZpZWxkIGNhbiBhcHBlYXIgZWl0aGVyIGluIOKAmExvY2FsIE5vZGUgRGVzY3Jp cHRvcuKAmSBvciDigJhSZW1vdGUgTm9kZSBEZXNjcmlwdG9y4oCZLiBMZXQ8L3NwYW4+PHNwYW4g c3R5bGU9ImxpbmUtaGVpZ2h0OiAxOHB4OyI+4oCZPC9zcGFuPjxzcGFuIHN0eWxlPSJsaW5lLWhl aWdodDogMS4yZW07Ij5zIGNvbnNpZGVyIHRoZSBjYXNlIGluIHdoaWNoIHRoaXMgZmllbGQgYXBw ZWFycyBpbiA8L3NwYW4+PHNwYW4gc3R5bGU9ImxpbmUtaGVpZ2h0OiAxOHB4OyI+4oCYPC9zcGFu PjxzcGFuIHN0eWxlPSJsaW5lLWhlaWdodDogMS4yZW07Ij5SZW1vdGUgTm9kZSBEZXNjcmlwdG9y PC9zcGFuPjxzcGFuIHN0eWxlPSJsaW5lLWhlaWdodDogMThweDsiPuKAmSBpbiB0aGUgZm9sbG93 aW5nIHRvcG9sb2d5Ljwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQo8cHJlIHN0eWxlPSJjb2xvcjogcmdi KDAsIDAsIDApOyBmb250LWZhbWlseTogQ29uc29sYXMsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTog MTVweDsgbWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7Ij48Zm9udCBmYWNlPSJD b25zb2xhcyI+PHNwYW4gc3R5bGU9ImxpbmUtaGVpZ2h0OiAxOHB4OyI+PGJyPjwvc3Bhbj48L2Zv bnQ+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBw eDsiPjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDb25zb2xh cywgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNXB4OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyI+UjEo MS4xLjEuMTo6MTAuMTAuMTAuMSkgJmx0Oy0tLS1MMS0tLS0mZ3Q7IFIyICgyLjIuMi4yOjoxMC4x MC4xMC4yKTwvZGl2PjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5 OiBDb25zb2xhcywgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNXB4OyB3aGl0ZS1zcGFjZTogbm9y bWFsOyI+PGJyPjwvZGl2PjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFt aWx5OiBDb25zb2xhcywgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNXB4OyB3aGl0ZS1zcGFjZTog bm9ybWFsOyI+V2hlcmUsPC9kaXY+PGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9u dC1mYW1pbHk6IENvbnNvbGFzLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE1cHg7IHdoaXRlLXNw YWNlOiBub3JtYWw7Ij5SMSdzIHJvdXRlci1pZCBpcyAxLjEuMS4xLCBhbmQgTDEgaW50ZXJmYWNl IElQIGFkZHJlc3MgaXMgMTAuMTAuMTAuMS48L2Rpdj48ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAs IDAsIDApOyBmb250LWZhbWlseTogQ29uc29sYXMsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTVw eDsgd2hpdGUtc3BhY2U6IG5vcm1hbDsiPlIyJ3Mgcm91dGVyLWlkIGlzIDIuMi4yLjIsIGFuZCBM MSBpbnRlcmZhY2UgSVAgYWRkcmVzcyBpcyAxMC4xMC4xMC4yLjwvZGl2PjxkaXYgc3R5bGU9ImNv bG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDb25zb2xhcywgc2Fucy1zZXJpZjsgZm9u dC1zaXplOiAxNXB4OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyI+TDEgaXMgYSBMQU4uPC9kaXY+PGRp diBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENvbnNvbGFzLCBzYW5z LXNlcmlmOyBmb250LXNpemU6IDE1cHg7IHdoaXRlLXNwYWNlOiBub3JtYWw7Ij5SMSBpcyBlbGVj dGVkIGFzIHRoZSBEUiBmb3IgTDEuPC9kaXY+PGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAw KTsgZm9udC1mYW1pbHk6IENvbnNvbGFzLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE1cHg7IHdo aXRlLXNwYWNlOiBub3JtYWw7Ij48YnI+PC9kaXY+PGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAw LCAwKTsgZm9udC1mYW1pbHk6IENvbnNvbGFzLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE1cHg7 IHdoaXRlLXNwYWNlOiBub3JtYWw7Ij5UaGVyZSBhcmUgZm91ciBkaXN0aW5jdCB1bmlkaXJlY3Rp b25hbCBsaW5rcyBpbiB0aGUgdG9wb2xvZ3kgYWJvdmU6IFIxLSZndDtEUiwgRFItJmd0O1IxLCBS Mi0mZ3Q7RFIsIGFuZCBEUi0mZ3Q7UjIuIExldOKAmXMgY29uc2lkZXIgdGhlIGxpbmsgUjItJmd0 O0RSLiBSMuKAmXMgcm91dGVyIExTQSByZXByZXNlbnRzIFIyLSZndDtEUiBsaW5rIGFzIGZvbGxv d3M6IC08L2Rpdj48cHJlIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTog Q29uc29sYXMsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTVweDsgbWFyZ2luLXRvcDogMHB4OyBt YXJnaW4tYm90dG9tOiAwcHg7Ij48ZGl2IHN0eWxlPSJ3aGl0ZS1zcGFjZTogbm9ybWFsOyI+PGJy PjwvZGl2PjxkaXYgc3R5bGU9IndoaXRlLXNwYWNlOiBub3JtYWw7Ij5BZHZlcnRpc2luZyByb3V0 ZXI6Mi4yLjIuMjwvZGl2PjxkaXYgc3R5bGU9IndoaXRlLXNwYWNlOiBub3JtYWw7Ij4mbmJzcDsg Jm5ic3A7TGluayBJRDogMTAuMTAuMTAuMTwvZGl2PjxkaXYgc3R5bGU9IndoaXRlLXNwYWNlOiBu b3JtYWw7Ij4mbmJzcDsgJm5ic3A7TGluayBkYXRhOjEwLjEwLjEwLjI8L2Rpdj48ZGl2IHN0eWxl PSJ3aGl0ZS1zcGFjZTogbm9ybWFsOyI+Jm5ic3A7ICZuYnNwO1R5cGU6MiAoVHJhbnNpdCk8L2Rp dj48L3ByZT48ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ29u c29sYXMsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTVweDsgd2hpdGUtc3BhY2U6IG5vcm1hbDsi Pjxicj48L2Rpdj48ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTog Q29uc29sYXMsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTVweDsgd2hpdGUtc3BhY2U6IG5vcm1h bDsiPk5vdGUgdGhhdCB0aGUgT1NQRiBsaW5rIHJlcHJlc2VudGF0aW9uIGFib3ZlIGRvZXMgbm90 IGluY2x1ZGUgdGhlIHJvdXRlci1pZCBvZiB0aGUgRFIsIHdoaWNoIGlzIDEuMS4xLjEuPC9kaXY+ PGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENvbnNvbGFzLCBz YW5zLXNlcmlmOyBmb250LXNpemU6IDE1cHg7IHdoaXRlLXNwYWNlOiBub3JtYWw7Ij48YnI+PC9k aXY+PGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENvbnNvbGFz LCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE1cHg7IHdoaXRlLXNwYWNlOiBub3JtYWw7Ij48cHJl IHN0eWxlPSJtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsiPjxkaXYgc3R5bGU9 ImZvbnQtZmFtaWx5OiBDb25zb2xhcywgc2Fucy1zZXJpZjsgd2hpdGUtc3BhY2U6IG5vcm1hbDsi PkFjY29yZGluZyB0byB0aGUgdGV4dCBpbiBzZWN0aW9uIDMuMi4xLjQsIEJHUC1MUyByZXF1aXJl cyB1cyB0byByZXByZXNlbnQgUjItJmd0O0RSIGxpbmsgYXMgZm9sbG93cyAoY29uc2lkZXJpbmcg b25seSBub2RlIGRlc2NyaXB0b3JzIG9mIHJlbGV2YW5jZSB0byB0aGlzIGRpc2N1c3Npb24sIGFu ZCBpZ25vcmluZyB0aGUgcmVtYWluaW5nIGZpZWxkcykgOiAtPC9kaXY+PGRpdiBzdHlsZT0iZm9u dC1mYW1pbHk6IENvbnNvbGFzLCBzYW5zLXNlcmlmOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyI+PGJy PjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDb25zb2xhcywgc2Fucy1zZXJpZjsgd2hp dGUtc3BhY2U6IG5vcm1hbDsiPkxvY2FsIE5vZGUoSUdQLVJvdXRlci1JZDoyLjIuMi4yKSAtJmd0 OyBSZW1vdGUgTm9kZShJR1AtUm91dGVyLUlkOjEuMS4xLjEtMTAuMTAuMTAuMSk8L2Rpdj48ZGl2 IHN0eWxlPSJmb250LWZhbWlseTogQ29uc29sYXMsIHNhbnMtc2VyaWY7IHdoaXRlLXNwYWNlOiBu b3JtYWw7Ij48YnI+PC9kaXY+PC9wcmU+PC9kaXY+PGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAw LCAwKTsgZm9udC1mYW1pbHk6IENvbnNvbGFzLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE1cHg7 IHdoaXRlLXNwYWNlOiBub3JtYWw7Ij5Ib3dldmVyLCB0aGUgT1NQRiByZXByZXNlbnRhdGlvbiBv ZiB0aGUgYWJvdmUgbGluayBpbiBSMuKAmXMgcm91dGVyIExTQSBkb2VzIG5vdCBjb250YWluIDEu MS4xLjEgYXQgYWxsLiBUaGVyZWZvcmUsIEJHUC1MUyBoYXMgbm93aGVyZSB0byBkZXJpdmUg4oCY MS4xLjEuMeKAmSBmcm9tLCBmb3IgdGhlIGxpbmsgUjItJmd0O0RSLjwvZGl2PjxkaXYgc3R5bGU9 ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDb25zb2xhcywgc2Fucy1zZXJpZjsg Zm9udC1zaXplOiAxNXB4OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyI+PGJyPjwvZGl2PjxkaXYgc3R5 bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDb25zb2xhcywgc2Fucy1zZXJp ZjsgZm9udC1zaXplOiAxNXB4OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyI+VGhlIGV4YW1wbGUgaW4g c2VjdGlvbiAzLjcgaXMgYXQgb2RkcyB3aXRoIHRoZSB0ZXh0IGluIHNlY3Rpb24gMy4yLjEuNCwg YW5kIHJlcHJlc2VudHMgdGhlIGxpbmsgYXMgZm9sbG93cyAod2hpY2ggd29ya3MgcGVyZmVjdGx5 KTogLTwvZGl2PjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBD b25zb2xhcywgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNXB4OyB3aGl0ZS1zcGFjZTogbm9ybWFs OyI+PGJyPjwvZGl2PjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5 OiBDb25zb2xhcywgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNXB4OyB3aGl0ZS1zcGFjZTogbm9y bWFsOyI+PHByZSBzdHlsZT0ibWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7Ij48 ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ29uc29sYXMsIHNhbnMtc2VyaWY7IHdoaXRlLXNwYWNl OiBub3JtYWw7Ij5Mb2NhbCBOb2RlKElHUC1Sb3V0ZXItSWQ6Mi4yLjIuMikgLSZndDsgUmVtb3Rl IE5vZGUoSUdQLVJvdXRlci1JZDoxMC4xMC4xMC4xLTEwLjEwLjEwLjEpPC9kaXY+PGRpdj48YnI+ PC9kaXY+PC9wcmU+PC9kaXY+PGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1m YW1pbHk6IENvbnNvbGFzLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE1cHg7IHdoaXRlLXNwYWNl OiBub3JtYWw7Ij5JIHN1Z2dlc3QgcmV3b3JkaW5nIHRoZSB0ZXh0IGluIDMuMi4xLjQgYXMgZm9s bG93czombmJzcDs8L2Rpdj48ZGl2PjxwcmUgc3R5bGU9Im1hcmdpbi10b3A6IDBweDsgbWFyZ2lu LWJvdHRvbTogMHB4OyI+PGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1p bHk6IENvbnNvbGFzLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE1cHg7IHdoaXRlLXNwYWNlOiBu b3JtYWw7Ij48YnI+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBm b250LWZhbWlseTogQ29uc29sYXMsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTVweDsgd2hpdGUt c3BhY2U6IG5vcm1hbDsiPiZxdW90OzwvZGl2PjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwg MCk7IGZvbnQtZmFtaWx5OiBDb25zb2xhcywgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNXB4OyB3 aGl0ZS1zcGFjZTogbm9ybWFsOyI+SUdQIFJvdXRlciBJRDogJmx0O3NuaXAmZ3Q7Jm5ic3A7PHNw YW4gc3R5bGU9ImxpbmUtaGVpZ2h0OiAxLjJlbTsiPkZvciBhbiBPU1BGdjIgJnF1b3Q7UHNldWRv bm9kZSZxdW90OyByZXByZXNlbnRpbmcgYSBMQU4sPC9zcGFuPjwvZGl2PjxwcmUgc3R5bGU9Im1h cmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyI+PGZvbnQgZmFjZT0iQ29uc29sYXMi IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ29uc29sYXMsIHNhbnMt c2VyaWY7IGZvbnQtc2l6ZTogMTVweDsgbGluZS1oZWlnaHQ6IDEuMmVtOyB3aGl0ZS1zcGFjZTog bm9ybWFsOyI+ICAgICAgdGhpcyBjb250YWlucyB0aGUgNCBvY3RldCBJUHY0IGFkZHJlc3Mgb2Yg dGhlIERSJ3MgaW50ZXJmYWNlIHRvIHRoZQ0KICAgICAgTEFOLCBmb2xsb3dlZCBieSBhbnkgbm9u LXplcm8gNC1vY3RldCBudW1iZXIgKDggb2N0ZXRzIGluIHRvdGFsKSAmbHQ7c25pcCZndDs8L2Zv bnQ+PGZvbnQgZmFjZT0iQ29uc29sYXMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDE1cHg7IGxp bmUtaGVpZ2h0OiAxOHB4OyI+4oCdPC9zcGFuPjwvZm9udD48L3ByZT48cHJlIHN0eWxlPSJjb2xv cjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ29uc29sYXMsIHNhbnMtc2VyaWY7IGZvbnQt c2l6ZTogMTVweDsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IDEuMmVtOyBtYXJn aW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsiPjxmb250IGZhY2U9IkNvbnNvbGFzIj48 YnI+PC9mb250PjwvcHJlPjwvZGl2PjwvcHJlPjwvZGl2PjxkaXYgc3R5bGU9ImNvbG9yOiByZ2Io MCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDb25zb2xhcywgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAx NXB4OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyI+4oCUPC9kaXY+PGRpdiBzdHlsZT0iY29sb3I6IHJn YigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENvbnNvbGFzLCBzYW5zLXNlcmlmOyBmb250LXNpemU6 IDE1cHg7IHdoaXRlLXNwYWNlOiBub3JtYWw7Ij5CYWxhamkgUmFqYWdvcGFsYW48L2Rpdj48ZGl2 IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ29uc29sYXMsIHNhbnMt c2VyaWY7IGZvbnQtc2l6ZTogMTVweDsgd2hpdGUtc3BhY2U6IG5vcm1hbDsiPjxicj48L2Rpdj48 ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ29uc29sYXMsIHNh bnMtc2VyaWY7IGZvbnQtc2l6ZTogMTVweDsgd2hpdGUtc3BhY2U6IG5vcm1hbDsiPjxicj48L2Rp dj48L3ByZT4NCjxwcmUgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBD b25zb2xhcywgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNXB4OyBsaW5lLWhlaWdodDogMS4yZW07 IG1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyI+PGJyPjwvcHJlPg0KPGRpdiBz dHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENvbnNvbGFzLCBzYW5zLXNl cmlmOyBmb250LXNpemU6IDE1cHg7Ij4NCjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNf Qk9EWV9TRUNUSU9OIiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENv bnNvbGFzLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE1cHg7Ij4NCjxkaXYgc3R5bGU9ImZvbnQt ZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMXB0OyB0ZXh0LWFsaWduOmxlZnQ7IGNvbG9yOmJs YWNrOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6IG1lZGl1bSBub25l OyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxFRlQ6IDBpbjsgUEFERElORy1SSUdIVDog MGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9SREVSLVJJR0hUOiBtZWRpdW0g bm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+ RnJvbTogPC9zcGFuPlRoZSBJRVNHICZsdDs8YSBocmVmPSJtYWlsdG86aWVzZy1zZWNyZXRhcnlA aWV0Zi5vcmciPmllc2ctc2VjcmV0YXJ5QGlldGYub3JnPC9hPiZndDs8YnI+DQo8c3BhbiBzdHls ZT0iZm9udC13ZWlnaHQ6Ym9sZCI+UmVwbHktVG86IDwvc3Bhbj4mcXVvdDs8YSBocmVmPSJtYWls dG86aWV0ZkBpZXRmLm9yZyI+aWV0ZkBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1h aWx0bzppZXRmQGlldGYub3JnIj5pZXRmQGlldGYub3JnPC9hPiZndDs8YnI+DQo8c3BhbiBzdHls ZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9zcGFuPlRodXJzZGF5LCBNYXJjaCAxOSwgMjAx NSBhdCAxOjEwIEFNPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3Nw YW4+SUVURi1Bbm5vdW5jZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlldGYtYW5ub3VuY2VAaWV0Zi5v cmciPmlldGYtYW5ub3VuY2VAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250 LXdlaWdodDpib2xkIj5DYzogPC9zcGFuPiZxdW90OzxhIGhyZWY9Im1haWx0bzppZHJAaWV0Zi5v cmciPmlkckBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzppZHJAaWV0Zi5v cmciPmlkckBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJv bGQiPlN1YmplY3Q6IDwvc3Bhbj5bSWRyXSBSRVZJU0VEIExhc3QgQ2FsbDogJmx0O2RyYWZ0LWll dGYtaWRyLWxzLWRpc3RyaWJ1dGlvbi0xMC50eHQmZ3Q7IChOb3J0aC1Cb3VuZCBEaXN0cmlidXRp b24gb2YgTGluay1TdGF0ZSBhbmQgVEUgSW5mb3JtYXRpb24gdXNpbmcgQkdQKSB0byBQcm9wb3Nl ZCBTdGFuZGFyZDxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGlk PSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6 ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElORzowIDAgMCA1OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGUgSUVTRyBoYXMgcmVjZWl2ZWQg YSByZXF1ZXN0IGZyb20gdGhlIEludGVyLURvbWFpbiBSb3V0aW5nIFdHIChpZHIpIHRvPC9kaXY+ DQo8ZGl2PmNvbnNpZGVyIHRoZSBmb2xsb3dpbmcgZG9jdW1lbnQ6PC9kaXY+DQo8ZGl2Pi0gJ05v cnRoLUJvdW5kIERpc3RyaWJ1dGlvbiBvZiBMaW5rLVN0YXRlIGFuZCBURSBJbmZvcm1hdGlvbiB1 c2luZyBCR1AnPC9kaXY+DQo8ZGl2PiZuYnNwOyZuYnNwOyZsdDtkcmFmdC1pZXRmLWlkci1scy1k aXN0cmlidXRpb24tMTAudHh0Jmd0OyBhcyBQcm9wb3NlZCBTdGFuZGFyZDwvZGl2Pg0KPGRpdj48 YnI+DQo8L2Rpdj4NCjxkaXY+VGhlIElFU0cgcGxhbnMgdG8gbWFrZSBhIGRlY2lzaW9uIGluIHRo ZSBuZXh0IGZldyB3ZWVrcywgYW5kIHNvbGljaXRzPC9kaXY+DQo8ZGl2PmZpbmFsIGNvbW1lbnRz IG9uIHRoaXMgYWN0aW9uLiBQbGVhc2Ugc2VuZCBzdWJzdGFudGl2ZSBjb21tZW50cyB0byB0aGU8 L2Rpdj4NCjxkaXY+PGEgaHJlZj0ibWFpbHRvOmlldGZAaWV0Zi5vcmciPmlldGZAaWV0Zi5vcmc8 L2E+IG1haWxpbmcgbGlzdHMgYnkgMjAxNS0wNC0wOC4gRXhjZXB0aW9uYWxseSwgY29tbWVudHMg bWF5IGJlPC9kaXY+DQo8ZGl2PnNlbnQgdG8gPGEgaHJlZj0ibWFpbHRvOmllc2dAaWV0Zi5vcmci Pmllc2dAaWV0Zi5vcmc8L2E+IGluc3RlYWQuIEluIGVpdGhlciBjYXNlLCBwbGVhc2UgcmV0YWlu IHRoZTwvZGl2Pg0KPGRpdj5iZWdpbm5pbmcgb2YgdGhlIFN1YmplY3QgbGluZSB0byBhbGxvdyBh dXRvbWF0ZWQgc29ydGluZy48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkFic3RyYWN0 PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+Jm5ic3A7 Jm5ic3A7IEluIGEgbnVtYmVyIG9mIGVudmlyb25tZW50cywgYSBjb21wb25lbnQgZXh0ZXJuYWwg dG8gYSBuZXR3b3JrIGlzPC9kaXY+DQo8ZGl2PiZuYnNwOyZuYnNwOyBjYWxsZWQgdXBvbiB0byBw ZXJmb3JtIGNvbXB1dGF0aW9ucyBiYXNlZCBvbiB0aGUgbmV0d29yayB0b3BvbG9neSBhbmQ8L2Rp dj4NCjxkaXY+Jm5ic3A7Jm5ic3A7IGN1cnJlbnQgc3RhdGUgb2YgdGhlIGNvbm5lY3Rpb25zIHdp dGhpbiB0aGUgbmV0d29yaywgaW5jbHVkaW5nPC9kaXY+DQo8ZGl2PiZuYnNwOyZuYnNwOyB0cmFm ZmljIGVuZ2luZWVyaW5nIGluZm9ybWF0aW9uLiZuYnNwOyZuYnNwO1RoaXMgaXMgaW5mb3JtYXRp b24gdHlwaWNhbGx5PC9kaXY+DQo8ZGl2PiZuYnNwOyZuYnNwOyBkaXN0cmlidXRlZCBieSBJR1Ag cm91dGluZyBwcm90b2NvbHMgd2l0aGluIHRoZSBuZXR3b3JrLjwvZGl2Pg0KPGRpdj48YnI+DQo8 L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7IFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgbWVjaGFu aXNtIGJ5IHdoaWNoIGxpbmtzIHN0YXRlIGFuZCB0cmFmZmljPC9kaXY+DQo8ZGl2PiZuYnNwOyZu YnNwOyBlbmdpbmVlcmluZyBpbmZvcm1hdGlvbiBjYW4gYmUgY29sbGVjdGVkIGZyb20gbmV0d29y a3MgYW5kIHNoYXJlZDwvZGl2Pg0KPGRpdj4mbmJzcDsmbmJzcDsgd2l0aCBleHRlcm5hbCBjb21w b25lbnRzIHVzaW5nIHRoZSBCR1Agcm91dGluZyBwcm90b2NvbC4mbmJzcDsmbmJzcDtUaGlzIGlz PC9kaXY+DQo8ZGl2PiZuYnNwOyZuYnNwOyBhY2hpZXZlZCB1c2luZyBhIG5ldyBCR1AgTmV0d29y ayBMYXllciBSZWFjaGFiaWxpdHkgSW5mb3JtYXRpb248L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7 IChOTFJJKSBlbmNvZGluZyBmb3JtYXQuJm5ic3A7Jm5ic3A7VGhlIG1lY2hhbmlzbSBpcyBhcHBs aWNhYmxlIHRvIHBoeXNpY2FsIGFuZDwvZGl2Pg0KPGRpdj4mbmJzcDsmbmJzcDsgdmlydHVhbCBJ R1AgbGlua3MuJm5ic3A7Jm5ic3A7VGhlIG1lY2hhbmlzbSBkZXNjcmliZWQgaXMgc3ViamVjdCB0 byBwb2xpY3k8L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7IGNvbnRyb2wuPC9kaXY+DQo8ZGl2Pjxi cj4NCjwvZGl2Pg0KPGRpdj4mbmJzcDsmbmJzcDsgQXBwbGljYXRpb25zIG9mIHRoaXMgdGVjaG5p cXVlIGluY2x1ZGUgQXBwbGljYXRpb24gTGF5ZXIgVHJhZmZpYzwvZGl2Pg0KPGRpdj4mbmJzcDsm bmJzcDsgT3B0aW1pemF0aW9uIChBTFRPKSBzZXJ2ZXJzLCBhbmQgUGF0aCBDb21wdXRhdGlvbiBF bGVtZW50cyAoUENFcykuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxkaXY+VGhlIGZpbGUgY2FuIGJlIG9idGFpbmVkIHZpYTwvZGl2Pg0KPGRpdj48YSBocmVm PSJodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaWRyLWxzLWRpc3Ry aWJ1dGlvbi8iPmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pZHIt bHMtZGlzdHJpYnV0aW9uLzwvYT48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PklFU0cg ZGlzY3Vzc2lvbiBjYW4gYmUgdHJhY2tlZCB2aWE8L2Rpdj4NCjxkaXY+PGEgaHJlZj0iaHR0cDov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWlkci1scy1kaXN0cmlidXRpb24v YmFsbG90LyI+aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWlkci1s cy1kaXN0cmlidXRpb24vYmFsbG90LzwvYT48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGUgZm9sbG93aW5nIElQUiBEZWNsYXJhdGlvbnMgbWF5IGJl IHJlbGF0ZWQgdG8gdGhpcyBJLUQ6PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4mbmJz cDsmbmJzcDsgPGEgaHJlZj0iaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2lwci8xODY0LyI+ aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2lwci8xODY0LzwvYT48L2Rpdj4NCjxkaXY+PGJy Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L2Rpdj4NCjxkaXY+ SWRyIG1haWxpbmcgbGlzdDwvZGl2Pg0KPGRpdj48YSBocmVmPSJtYWlsdG86SWRyQGlldGYub3Jn Ij5JZHJAaWV0Zi5vcmc8L2E+PC9kaXY+DQo8ZGl2PjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vaWRyIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2lkcjwvYT48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3Nw YW4+PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9zcGFuPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_D142BCAB1452Eaceeciscocom_-- From nobody Thu Apr 2 09:52:41 2015 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 4CA071A890F; Thu, 2 Apr 2015 09:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 4TijhSd15PKF; Thu, 2 Apr 2015 09:52:33 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0144.outbound.protection.outlook.com [65.55.169.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC72A1A1A4A; Thu, 2 Apr 2015 09:52:32 -0700 (PDT) Received: from BN1PR05MB535.namprd05.prod.outlook.com (10.141.65.155) by BN1PR05MB438.namprd05.prod.outlook.com (10.141.58.12) with Microsoft SMTP Server (TLS) id 15.1.118.21; Thu, 2 Apr 2015 16:52:30 +0000 Received: from BN1PR05MB535.namprd05.prod.outlook.com ([169.254.8.244]) by BN1PR05MB535.namprd05.prod.outlook.com ([169.254.8.244]) with mapi id 15.01.0118.022; Thu, 2 Apr 2015 16:52:30 +0000 From: Balaji Rajagopalan To: "Acee Lindem (acee)" , "ietf@ietf.org" , Hannes Gredler Thread-Topic: [Idr] REVISED Last Call: (North-Bound Distribution of Link-State and TE Information using BGP) to Proposed Standard Thread-Index: AQHQYbN1sBT99RQ7ME2g+UypTJek+p04078A//+/7ICAAO8fAIAAX+WAgACBQIA= Date: Thu, 2 Apr 2015 16:52:29 +0000 Message-ID: References: <20150318194048.32558.12168.idtracker@ietfa.amsl.com> 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.8.150116 x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [116.197.184.11] authentication-results: cisco.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB438; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(51914003)(377454003)(41574002)(36756003)(46102003)(106116001)(76176999)(230783001)(54356999)(50986999)(15975445007)(102836002)(19617315012)(93886004)(122556002)(62966003)(77156002)(92566002)(99286002)(19580395003)(19580405001)(2950100001)(2900100001)(83506001)(16236675004)(86362001)(2501003)(2656002)(87936001)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB438; H:BN1PR05MB535.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:BN1PR05MB438; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB438; x-forefront-prvs: 0534947130 Content-Type: multipart/alternative; boundary="_000_D14351C71304Abalajirjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Apr 2015 16:52:29.9487 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB438 Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] REVISED Last Call: (North-Bound Distribution of Link-State and TE Information using BGP) to Proposed Standard 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, 02 Apr 2015 16:52:35 -0000 --_000_D14351C71304Abalajirjunipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWNlZSwNCg0KVGhhbmtzIGZvciB0aGUgZGV0YWlsZWQgcmVzcG9uc2UuIFBsZWFzZSBzZWUg aW5saW5lLg0KDQpGcm9tOiAiQWNlZSBMaW5kZW0gKGFjZWUpIiA8YWNlZUBjaXNjby5jb208bWFp bHRvOmFjZWVAY2lzY28uY29tPj4NCkRhdGU6IFRodXJzZGF5LCBBcHJpbCAyLCAyMDE1IGF0IDc6 MTAgUE0NClRvOiBCYWxhamkgUmFqYWdvcGFsYW4gPGJhbGFqaXJAanVuaXBlci5uZXQ8bWFpbHRv OmJhbGFqaXJAanVuaXBlci5uZXQ+PiwgImlldGZAaWV0Zi5vcmc8bWFpbHRvOmlldGZAaWV0Zi5v cmc+IiA8aWV0ZkBpZXRmLm9yZzxtYWlsdG86aWV0ZkBpZXRmLm9yZz4+LCBIYW5uZXMgR3JlZGxl ciA8aGFubmVzQGp1bmlwZXIubmV0PG1haWx0bzpoYW5uZXNAanVuaXBlci5uZXQ+Pg0KQ2M6ICJp ZHJAaWV0Zi5vcmc8bWFpbHRvOmlkckBpZXRmLm9yZz4iIDxpZHJAaWV0Zi5vcmc8bWFpbHRvOmlk ckBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW0lkcl0gUkVWSVNFRCBMYXN0IENhbGw6IDxkcmFm dC1pZXRmLWlkci1scy1kaXN0cmlidXRpb24tMTAudHh0PiAoTm9ydGgtQm91bmQgRGlzdHJpYnV0 aW9uIG9mIExpbmstU3RhdGUgYW5kIFRFIEluZm9ybWF0aW9uIHVzaW5nIEJHUCkgdG8gUHJvcG9z ZWQgU3RhbmRhcmQNCg0KSGkgQmFsYWppLA0KDQpBcyB0aGUgSUVURiBSb3V0aW5nIERpcmVjdG9y YXRlIHJldmlld2VyIG9mIHRoZSB0aGlzIGRyYWZ0LCBJIGFncmVlIHRoYXQgaXQgaXMgZmFyIGZy b20gcGVyZmVjdC4gSG93ZXZlciwgaXQgaXMgdmVyeSBsYXRlIGluIHRoZSByZXZpZXcgY3ljbGUg YW5kIHdlIGhhdmUgc2V2ZXJhbCBpbXBsZW1lbnRhdGlvbnMgKHJlZmVyIHRvIGh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaWRyLWxzLWRpc3RyaWJ1dGlvbi1pbXBs LykuIEl0IGlzIG5vdCB0aGUgdGltZSB0byBjaGFuZ2UgaXQganVzdCB0byBlYXNlIHlvdXIgaW1w bGVtZW50YXRpb24uIFNlZSBpbmxpbmUuDQoNCltCYWxhamldIEZXSVcsIEkgcmVwcmVzZW50ZWQg SlVOT1MgKG9uZSBvZiB0aGUgaW1wbGVtZW50YXRpb25zIGxpc3RlZCBpbiB0aGUgYWJvdmUgZHJh ZnQpIGF0IG9uZSBvZiB0aGUgaW50ZXItb3BzLCB3aGVyZSB3ZSBkaWQgbm90IHRlc3QgT1NQRiBi cm9hZGNhc3QgbmV0d29yayB0eXBlIGR1ZSB0byB0aGUgc2FtZSBpc3N1ZSB3ZeKAmXJlIGRpc2N1 c3Npbmcgbm93OyBJIGhhZCBub3RpZmllZCB0aGUgcHJvdG9jb2wgYXV0aG9yIG9mIHRoaXMgaXNz dWUgYXQgdGhhdCB0aW1lLiBCdXQsIEkgZG8gYWdyZWUgd2l0aCB5b3Ug4oCTIHRoZXJlIGlzIG9u ZSBtb3JlIGltcGxlbWVudGF0aW9uIChPREwpIGxpc3RlZCBpbiB0aGUgZHJhZnQsIGFsdGhvdWdo IEkgZG9u4oCZdCBrbm93IGhvdyBpdCB3YXMgYWxsIHZlcmlmaWVkLCBzaW5jZSBJIHN0aWxsIHNl ZSBhbiBpbmNvbnNpc3RlbmN5IGJldHdlZW4gMy43IGFuZCAzLjIuMS40LiBQbGVhc2Ugc2VlIGJl bG93Lg0KDQoNCkkgYWxzbyBwb2ludGVkIG91dCBhbiBpbmNvbnNpc3RlbmN5IGJldHdlZW4gdGhl IGV4YW1wbGUgaW4gc2VjdGlvbiAzLjcgYW5kIHRoZSBub3JtYXRpdmUgdGV4dCBpbiBzZWN0aW9u IDMuMi4xLjQuIFNvLCB0aGUgZHJhZnQgbmVlZHMgYSBjb3JyZWN0aW9uIGFueXdheS4NCg0KVGhl IHF1ZXN0aW9uIGlzLCB3aGljaCBvbmUgbmVlZHMgdG8gYmUgY29ycmVjdGVkIOKAkyBzZWN0aW9u IDMuNywgb3Igc2VjdGlvbiAzLjIuMS40Lg0KDQpTZWN0aW9uIDMuNyBpcyBub3QgbmVjZXNzYXJp bHkgd3JvbmcuIFdoaWxlIHRoaXMgaXMgbm90IHRoZSBiZXN0IE9TUEYgZXhhbXBsZSwgMTAuMS4x LjEgbWF5IGJlIGJvdGggdGhlIElQIGludGVyZmFjZSBhZGRyZXNzIGFuZCB0aGUgT1NQRiBSb3V0 ZXIgSUQuDQoNCltCYWxhamldIEluIHRoZSBzcGVjaWZpYyBleGFtcGxlIGRlc2NyaWJlZCBpbiBz ZWN0aW9uIDMuNywgdGhlIHJvdXRlci1pZCBpcyBub3QgdGhlIHNhbWUgYXMgdGhlIGludGVyZmFj ZSBJUCBhZGRyZXNzIChhbHRob3VnaCBJIHNlZSB5b3VyIHBvaW50IHRoYXQgdGhleSBtYXkgYmUg dGhlIHNhbWUgaW4gc29tZSBzY2VuYXJpb3MpLiBOb2RlMeKAmXMgcm91dGVyLWlkIGlzIDExLjEx LjExLjExIGFuZCBub2RlMuKAmXMgcm91dGVyLWlkIGlzIDMzLjMzLjMzLjM0LiBJbiB0aGUgZXhh bXBsZSwgdGhlIERSIGlzIHJlcHJlc2VudGVkIGFzIDEwLjEuMS4xOjEwLjEuMS4xLiDigJkxMC4x LjEuMScgaXMgdGhlIGludGVyZmFjZSBJUCBhZGRyZXNzIG9mIHRoZSBEUihOb2RlMSkuDQoNClBl ciBzZWN0aW9uIDMuMi4xLjQsIHRoaXMgZXhhbXBsZSBzaG91bGQgcmVwcmVzZW50IHRoZSBEUiBh cyAxMS4xMS4xMS4xMToxMC4xLjEuMS4xLg0KDQpTbywgSSBiZWxpZXZlIHRoZXJlIGlzIHN0aWxs IGEgbmVlZCB0byByZWNvbmNpbGUgc2VjdGlvbiAzLjcgd2l0aCAzLjIuMS40LiBBbmQsIEnigJlt IHRpbHRpbmcgdG93YXJkcyB0aGUgYmVoYXZpb3IgZGVzY3JpYmVkIGluIHNlY3Rpb24gMy43IDot KQ0KDQoNCg0KSU1ITywgd2Ugc2hvdWxkIGNvcnJlY3QgdGhlIG5vcm1hdGl2ZSB0ZXh0IGluIHNl Y3Rpb24gMy4yLjEuNCB0byBhbGlnbiB3aXRoIHRoZSBleGFtcGxlIGluIHNlY3Rpb24gMy43LCBh cyB0aGUgZXhhbXBsZSBtb3JlIGNsb3NlbHkgcmVmbGVjdHMgaG93IE9TUEZ2MiByZXByZXNlbnRz IHRoZSBsaW5rLg0KDQpBcmUgeW91IGZhbWlsaWFyIHdpdGggT1NQRnYzPyBJbiBPU1BGdjMsIHRo ZSBSb3V0ZXItSUQgaXMgdXNlZCBpbiB0aGUgUm91dGVyLUxTQSB0byBpZGVudGlmeSB0aGUgRFIu IEhlbmNlLCBpZiB3ZSB3ZXJlIHRvIGNoYW5nZSBpdCwgT1NQRnYzIHdvdWxkIG5lZWQgdG8gYmUg aGFuZGxlZCBzZXBhcmF0ZWx5Lg0KDQpbQmFsYWppXSBTaW5jZSBCR1AtTFMgY2FycmllcyB0aGUg 4oCYcHJvdG9jb2zigJkgdHlwZSBpbiB0aGUgTkxSSSAod2hpY2ggaGFzIGRpZmZlcmVudCBjb2Rl cyBmb3IgT1NQRnYyIGFuZCBPU1BGdjMpLCB3ZSBjYW4gbGVhdmUgT1NQRnYzIHJlcHJlc2VudGF0 aW9uIGFzIGl0IGlzLg0KDQpGb3IgdGhhdCBtYXR0ZXIsIEkgYmVsaWV2ZSB0aGF0IEJHUC1MUyBz aG91bGQgcHJlc2VydmUgdGhlIHJlcHJlc2VudGF0aW9uIGluIHRoZSB1bmRlcmx5aW5nIHByb3Rv Y29sLCBpZiB0aGVyZSBpcyBubyBnb29kIHJlYXNvbiB0byBjaGFuZ2UgaXQuIEkgdW5kZXJzdGFu ZCB0aGF0IHRoaXMgaXMgbm90IGFuIGFyZ3VtZW50IHRvIG1ha2UgYXQgdGhpcyBzdGFnZSwgYnV0 IHRoZSBpbmNvbnNpc3RlbmN5IEkgcmVwb3J0ZWQgYWJvdmUgbmVlZHMgdG8gYmUgcmVzb2x2ZWQu IEFuZCwgSSB3b3VsZCBsaWtlIHRvIHJlcXVlc3QgdGhhdCB3ZSByZXNvbHZlIGl0IHVzaW5nIHRo ZSBwcmluY2lwbGUgdGhhdCBCR1AtTFMgc2hvdWxkIG5vdCBjaGFuZ2UgdGhlIHVuZGVybHlpbmcg cHJvdG9jb2zigJlzIHJlcHJlc2VudGF0aW9uIHVubmVjZXNzYXJpbHkuDQoNClRoYW5rcyENCg0K 4oCUDQpCYWxhamkgUmFqYWdvcGFsYW4NCg0K --_000_D14351C71304Abalajirjunipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <7CA463F2BFF1B640AB555BD0D71C4106@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NXB4OyBmb250LWZhbWlseTogQ29uc29sYXMsIHNhbnMtc2VyaWY7Ij4NCjxkaXY+SGkgQWNlZSw8 L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoYW5rcyBmb3IgdGhlIGRldGFpbGVkIHJl c3BvbnNlLiBQbGVhc2Ugc2VlIGlubGluZS48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3Bh biBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2Fs aWJyaTsgZm9udC1zaXplOjExcHQ7IHRleHQtYWxpZ246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRF Ui1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkct Qk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGluOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRF Ui1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURE SU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3Nw YW4+JnF1b3Q7QWNlZSBMaW5kZW0gKGFjZWUpJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86YWNl ZUBjaXNjby5jb20iPmFjZWVAY2lzY28uY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9u dC13ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9zcGFuPlRodXJzZGF5LCBBcHJpbCAyLCAyMDE1IGF0IDc6 MTAgUE08YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bhbj5CYWxh amkgUmFqYWdvcGFsYW4gJmx0OzxhIGhyZWY9Im1haWx0bzpiYWxhamlyQGp1bmlwZXIubmV0Ij5i YWxhamlyQGp1bmlwZXIubmV0PC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzppZXRmQGll dGYub3JnIj5pZXRmQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlldGZA aWV0Zi5vcmciPmlldGZAaWV0Zi5vcmc8L2E+Jmd0OywgSGFubmVzIEdyZWRsZXIgJmx0OzxhIGhy ZWY9Im1haWx0bzpoYW5uZXNAanVuaXBlci5uZXQiPmhhbm5lc0BqdW5pcGVyLm5ldDwvYT4mZ3Q7 PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkNjOiA8L3NwYW4+JnF1b3Q7PGEg aHJlZj0ibWFpbHRvOmlkckBpZXRmLm9yZyI+aWRyQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEg aHJlZj0ibWFpbHRvOmlkckBpZXRmLm9yZyI+aWRyQGlldGYub3JnPC9hPiZndDs8YnI+DQo8c3Bh biBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFuPlJlOiBbSWRyXSBSRVZJ U0VEIExhc3QgQ2FsbDogJmx0O2RyYWZ0LWlldGYtaWRyLWxzLWRpc3RyaWJ1dGlvbi0xMC50eHQm Z3Q7IChOb3J0aC1Cb3VuZCBEaXN0cmlidXRpb24gb2YgTGluay1TdGF0ZSBhbmQgVEUgSW5mb3Jt YXRpb24gdXNpbmcgQkdQKSB0byBQcm9wb3NlZCBTdGFuZGFyZDxicj4NCjwvZGl2Pg0KPGRpdj48 YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9D S1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElORzowIDAg MCA1OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRpdj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJl YWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFm dGVyLXdoaXRlLXNwYWNlOyBjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LXNpemU6IDE0cHg7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+DQo8ZGl2PkhpIEJhbGFqaSwmbmJzcDs8 L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkFzIHRoZSBJRVRGIFJvdXRpbmcgRGlyZWN0 b3JhdGUgcmV2aWV3ZXIgb2YgdGhlIHRoaXMgZHJhZnQsIEkgYWdyZWUgdGhhdCBpdCBpcyBmYXIg ZnJvbSBwZXJmZWN0LiBIb3dldmVyLCBpdCBpcyB2ZXJ5IGxhdGUgaW4gdGhlIHJldmlldyBjeWNs ZSBhbmQgd2UgaGF2ZSBzZXZlcmFsIGltcGxlbWVudGF0aW9ucyAocmVmZXIgdG8NCjxhIGhyZWY9 Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaWRyLWxzLWRpc3Ry aWJ1dGlvbi1pbXBsLyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0 Zi1pZHItbHMtZGlzdHJpYnV0aW9uLWltcGwvPC9hPikuIEl0IGlzIG5vdCB0aGUgdGltZSB0byBj aGFuZ2UgaXQganVzdCB0byBlYXNlIHlvdXIgaW1wbGVtZW50YXRpb24uIFNlZSBpbmxpbmUuJm5i c3A7PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9zcGFuPg0KPGRpdj48 YnI+DQo8L2Rpdj4NCjxkaXY+W0JhbGFqaV0gRldJVywgSSByZXByZXNlbnRlZCBKVU5PUyAob25l IG9mIHRoZSBpbXBsZW1lbnRhdGlvbnMgbGlzdGVkIGluIHRoZSBhYm92ZSBkcmFmdCkgYXQgb25l IG9mIHRoZSBpbnRlci1vcHMsIHdoZXJlIHdlIGRpZCBub3QgdGVzdCBPU1BGIGJyb2FkY2FzdCBu ZXR3b3JrIHR5cGUgZHVlIHRvIHRoZSBzYW1lIGlzc3VlIHdl4oCZcmUgZGlzY3Vzc2luZyBub3c7 IEkgaGFkIG5vdGlmaWVkIHRoZSBwcm90b2NvbCBhdXRob3Igb2YgdGhpcw0KIGlzc3VlIGF0IHRo YXQgdGltZS4gQnV0LCBJIGRvIGFncmVlIHdpdGggeW91IOKAkyB0aGVyZSBpcyBvbmUgbW9yZSBp bXBsZW1lbnRhdGlvbiAoT0RMKSBsaXN0ZWQgaW4gdGhlIGRyYWZ0LCBhbHRob3VnaCBJIGRvbuKA mXQga25vdyBob3cgaXQgd2FzIGFsbCB2ZXJpZmllZCwgc2luY2UgSSBzdGlsbCBzZWUgYW4gaW5j b25zaXN0ZW5jeSBiZXR3ZWVuIDMuNyBhbmQgMy4yLjEuNC4gUGxlYXNlIHNlZSBiZWxvdy48L2Rp dj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0K PGJsb2NrcXVvdGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxl PSJCT1JERVItTEVGVDogI2I1YzRkZiA1IHNvbGlkOyBQQURESU5HOjAgMCAwIDU7IE1BUkdJTjow IDAgMCA1OyI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJz cC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29s b3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAxNHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwg c2Fucy1zZXJpZjsiPg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFj ZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAw LCAwKTsgZm9udC1zaXplOiAxNXB4OyBmb250LWZhbWlseTogQ29uc29sYXMsIHNhbnMtc2VyaWY7 Ij4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkkgYWxzbyBwb2ludGVkIG91dCBhbiBpbmNvbnNp c3RlbmN5IGJldHdlZW4gdGhlIGV4YW1wbGUgaW4gc2VjdGlvbiAzLjcgYW5kIHRoZSBub3JtYXRp dmUgdGV4dCBpbiBzZWN0aW9uIDMuMi4xLjQuIFNvLCB0aGUgZHJhZnQgbmVlZHMgYSBjb3JyZWN0 aW9uIGFueXdheS48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoZSBxdWVzdGlvbiBp cywgd2hpY2ggb25lIG5lZWRzIHRvIGJlIGNvcnJlY3RlZCDigJMgc2VjdGlvbiAzLjcsIG9yIHNl Y3Rpb24gMy4yLjEuNC48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPGRpdj5TZWN0aW9uIDMuNyBpcyBub3QgbmVjZXNzYXJpbHkgd3JvbmcuIFdoaWxl IHRoaXMgaXMgbm90IHRoZSBiZXN0IE9TUEYgZXhhbXBsZSwgMTAuMS4xLjEgbWF5IGJlIGJvdGgg dGhlIElQIGludGVyZmFjZSBhZGRyZXNzIGFuZCB0aGUgT1NQRiBSb3V0ZXIgSUQuJm5ic3A7PC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8 ZGl2PltCYWxhamldIEluIHRoZSBzcGVjaWZpYyBleGFtcGxlIGRlc2NyaWJlZCBpbiBzZWN0aW9u IDMuNywgdGhlIHJvdXRlci1pZCBpcyBub3QgdGhlIHNhbWUgYXMgdGhlIGludGVyZmFjZSBJUCBh ZGRyZXNzIChhbHRob3VnaCBJIHNlZSB5b3VyIHBvaW50IHRoYXQgdGhleSBtYXkgYmUgdGhlIHNh bWUgaW4gc29tZSBzY2VuYXJpb3MpLiBOb2RlMeKAmXMgcm91dGVyLWlkIGlzIDExLjExLjExLjEx IGFuZCBub2RlMuKAmXMgcm91dGVyLWlkIGlzIDMzLjMzLjMzLjM0Lg0KIEluIHRoZSBleGFtcGxl LCB0aGUgRFIgaXMgcmVwcmVzZW50ZWQgYXMgMTAuMS4xLjE6MTAuMS4xLjEuIOKAmTEwLjEuMS4x JyBpcyB0aGUgaW50ZXJmYWNlIElQIGFkZHJlc3Mgb2YgdGhlIERSKE5vZGUxKS48L2Rpdj4NCjxk aXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlBlciBzZWN0aW9uIDMuMi4xLjQsIHRoaXMgZXhhbXBsZSBz aG91bGQgcmVwcmVzZW50IHRoZSBEUiBhcyAxMS4xMS4xMS4xMToxMC4xLjEuMS4xLjwvZGl2Pg0K PGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+U28sIEkgYmVsaWV2ZSB0aGVyZSBpcyBzdGlsbCBhIG5l ZWQgdG8gcmVjb25jaWxlIHNlY3Rpb24gMy43IHdpdGggMy4yLjEuNC4gQW5kLCBJ4oCZbSB0aWx0 aW5nIHRvd2FyZHMgdGhlIGJlaGF2aW9yIGRlc2NyaWJlZCBpbiBzZWN0aW9uIDMuNyA6LSk8L2Rp dj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0K PGJsb2NrcXVvdGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxl PSJCT1JERVItTEVGVDogI2I1YzRkZiA1IHNvbGlkOyBQQURESU5HOjAgMCAwIDU7IE1BUkdJTjow IDAgMCA1OyI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Vi a2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3Bh Y2U7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc2l6ZTogMTRweDsgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7Ij4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NS Q19CT0RZX1NFQ1RJT04iPg0KPGJsb2NrcXVvdGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9O X0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVGVDogI2I1YzRkZiA1IHNvbGlkOyBQQURESU5H OjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0id29yZC13cmFw OiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVh azogYWZ0ZXItd2hpdGUtc3BhY2U7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc2l6ZTogMTVw eDsgZm9udC1mYW1pbHk6IENvbnNvbGFzLCBzYW5zLXNlcmlmOyI+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPGRpdj5JTUhPLCB3ZSBzaG91bGQgY29ycmVjdCB0aGUgbm9ybWF0aXZlIHRleHQgaW4gc2Vj dGlvbiAzLjIuMS40IHRvIGFsaWduIHdpdGggdGhlIGV4YW1wbGUgaW4gc2VjdGlvbiAzLjcsIGFz IHRoZSBleGFtcGxlIG1vcmUgY2xvc2VseSByZWZsZWN0cyBob3cgT1NQRnYyIHJlcHJlc2VudHMg dGhlIGxpbmsuPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9zcGFuPg0K PGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+QXJlIHlvdSBmYW1pbGlhciB3aXRoIE9TUEZ2Mz8gSW4g T1NQRnYzLCB0aGUgUm91dGVyLUlEIGlzIHVzZWQgaW4gdGhlIFJvdXRlci1MU0EgdG8gaWRlbnRp ZnkgdGhlIERSLiBIZW5jZSwgaWYgd2Ugd2VyZSB0byBjaGFuZ2UgaXQsIE9TUEZ2MyB3b3VsZCBu ZWVkIHRvIGJlIGhhbmRsZWQgc2VwYXJhdGVseS4mbmJzcDs8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5bQmFsYWpp XSBTaW5jZSBCR1AtTFMgY2FycmllcyB0aGUg4oCYcHJvdG9jb2zigJkgdHlwZSBpbiB0aGUgTkxS SSAod2hpY2ggaGFzIGRpZmZlcmVudCBjb2RlcyBmb3IgT1NQRnYyIGFuZCBPU1BGdjMpLCB3ZSBj YW4gbGVhdmUgT1NQRnYzIHJlcHJlc2VudGF0aW9uIGFzIGl0IGlzLjwvZGl2Pg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjxkaXY+Rm9yIHRoYXQgbWF0dGVyLCBJIGJlbGlldmUgdGhhdCBCR1AtTFMgc2hv dWxkIHByZXNlcnZlIHRoZSByZXByZXNlbnRhdGlvbiBpbiB0aGUgdW5kZXJseWluZyBwcm90b2Nv bCwgaWYgdGhlcmUgaXMgbm8gZ29vZCByZWFzb24gdG8gY2hhbmdlIGl0LiBJIHVuZGVyc3RhbmQg dGhhdCB0aGlzIGlzIG5vdCBhbiBhcmd1bWVudCB0byBtYWtlIGF0IHRoaXMgc3RhZ2UsIGJ1dCB0 aGUgaW5jb25zaXN0ZW5jeSBJIHJlcG9ydGVkIGFib3ZlIG5lZWRzDQogdG8gYmUgcmVzb2x2ZWQu IEFuZCwgSSB3b3VsZCBsaWtlIHRvIHJlcXVlc3QgdGhhdCB3ZSByZXNvbHZlIGl0IHVzaW5nIHRo ZSBwcmluY2lwbGUgdGhhdCBCR1AtTFMgc2hvdWxkIG5vdCBjaGFuZ2UgdGhlIHVuZGVybHlpbmcg cHJvdG9jb2zigJlzIHJlcHJlc2VudGF0aW9uIHVubmVjZXNzYXJpbHkuPC9kaXY+DQo8ZGl2Pjxi cj4NCjwvZGl2Pg0KPGRpdj5UaGFua3MhPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj7i gJQ8L2Rpdj4NCjxkaXY+QmFsYWppIFJhamFnb3BhbGFuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_D14351C71304Abalajirjunipernet_-- From nobody Mon Apr 6 15:22:15 2015 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 237061A6F0B; Mon, 6 Apr 2015 15:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HfVNYl_D9vMc; Mon, 6 Apr 2015 15:22:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A45C1A6F2F; Mon, 6 Apr 2015 15:22:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF Announcement List" X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150406222212.27839.51258.idtracker@ietfa.amsl.com> Date: Mon, 06 Apr 2015 15:22:12 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] IDR WG Virtual Interim Meetings: April 27, 2015; June 1, 2015; June 15, 2015; June 29, 2015 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 22:22:13 -0000 The Inter-Domain Routing (IDR) WG will hold virtual interim meetings on the following dates: April 27, 2015 Time: 10:00-11:30 AM EDT (14:00-15:30 UTC) Topic: BGP Yang Modules and Route Server June 1, 2015 Time: 10:00-11:30 AM EDT (14:00-15:30 UTC) Topic: Communities drafts + RTC + Flow Specs June 15, 2015 Time: 10:00-11:30 AM EDT (14:00-15:30 UTC) Topic: Next Hop Issues June 29, 2015 Time: 10:00-11:30 AM EDT (14:00-15:30 UTC) Topic: Yang Modules WebEx details will follow on the IDR mailing list. From nobody Mon Apr 6 15:25:05 2015 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 A7DED1A887B for ; Mon, 6 Apr 2015 15:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.354 X-Spam-Level: X-Spam-Status: No, score=-96.354 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 2__PqeLCFNZu for ; Mon, 6 Apr 2015 15:25:02 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 582111A6F3A for ; Mon, 6 Apr 2015 15:25:02 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.142; From: "Susan Hares" To: "idr wg" Date: Mon, 6 Apr 2015 18:25:00 -0400 Message-ID: <000301d070b8$85a8ccf0$90fa66d0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01D07096.FE98DAA0" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AdBwuFOi+PNmnXfYQEG3Ry1KQ3sZCg== X-Authenticated-User: skh@ndzh.com Archived-At: Cc: dbrungard@att.com Subject: [Idr] 2 Week WG LC draft-ietf-idr-add-paths-implementation-00 (4/6 to 4/20/2015) 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, 06 Apr 2015 22:25:03 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0004_01D07096.FE98DAA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This is a 2 week WG last call on the draft-ietf-idr-add-paths-implementation-00. Please in your discussion, please indicate: "support" or "no support" for this WG LC. You can see the draft at: http://datatracker.ietf.org/doc/draft-ietf-idr-add-paths-implementation/ Sue Hares ------=_NextPart_000_0004_01D07096.FE98DAA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

T= his is a 2 week WG last call on the = draft-ietf-idr-add-paths-implementation-00.

<= o:p> 

P= lease in your discussion, please indicate:  “support” = or “no support” for this WG LC.  You can see the draft = at:

&= nbsp;http://datatracker.ietf.org/doc/draft-ietf-idr-add-paths-impleme= ntation/

<= o:p> 

S= ue Hares

 

------=_NextPart_000_0004_01D07096.FE98DAA0-- From nobody Mon Apr 6 15:32:04 2015 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 4B5101A9022 for ; Mon, 6 Apr 2015 15:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QHvXoRE9aQeV for ; Mon, 6 Apr 2015 15:32:01 -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 2E8AD1A8F4F for ; Mon, 6 Apr 2015 15:32:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7109; q=dns/txt; s=iport; t=1428359521; x=1429569121; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=aiXT/Lcn6d4v99+XCFY0R7zOnvFGKxk8EEVAPzQ/vjU=; b=DDo940c++4cbERWrKWeCQuUsvQ4c+h6mgqkYm8oAddTNgV+ng3abOh3A UqorBfkX95ZagUj1pcvpEdXfYBX7dbDSTvCfxpCAgt17iUoybAN6dKvbz EZJ/zzxlz9jFFI5ysmh//VY+pdtNMjKDyOfr0l5767g69pTeXiQeF3H4q 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CKBgATCSNV/4YNJK1cgkNDUlwFgxCyM41tKgmBU4V7AhyBBjgUAQEBAQEBAX2EHgEBAQQjCkwQAgEIDgMDAQIoAwICAjAUCQgBAQQBDQWILw21MZc8AQEBAQEBAQEBAQEBAQEBAQEBAQEBF4sphGgRB4JogUUFjlyCD4N1hg2BHTqCe4w6g0gigjOBPG+BRH8BAQE X-IronPort-AV: E=Sophos;i="5.11,534,1422921600"; d="scan'208,217";a="138691902" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-8.cisco.com with ESMTP; 06 Apr 2015 22:31:40 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t36MVdWG001664 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 6 Apr 2015 22:31:40 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.236]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Mon, 6 Apr 2015 17:31:39 -0500 From: "Acee Lindem (acee)" To: Susan Hares , idr wg Thread-Topic: [Idr] 2 Week WG LC draft-ietf-idr-add-paths-implementation-00 (4/6 to 4/20/2015) Thread-Index: AdBwuFOi+PNmnXfYQEG3Ry1KQ3sZCgACY/EA Date: Mon, 6 Apr 2015 22:31:39 +0000 Message-ID: References: <000301d070b8$85a8ccf0$90fa66d0$@ndzh.com> In-Reply-To: <000301d070b8$85a8ccf0$90fa66d0$@ndzh.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: multipart/alternative; boundary="_000_D148819F15E37aceeciscocom_" MIME-Version: 1.0 Archived-At: Cc: "dbrungard@att.com" Subject: Re: [Idr] 2 Week WG LC draft-ietf-idr-add-paths-implementation-00 (4/6 to 4/20/2015) 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, 06 Apr 2015 22:32:03 -0000 --_000_D148819F15E37aceeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3VwcG9ydC4NCg0KRnJvbTogU3VzYW4gSGFyZXMgPHNoYXJlc0BuZHpoLmNvbTxtYWlsdG86c2hh cmVzQG5kemguY29tPj4NCkRhdGU6IE1vbmRheSwgQXByaWwgNiwgMjAxNSBhdCA2OjI1IFBNDQpU bzogaWRyIHdnIDxpZHJAaWV0Zi5vcmc8bWFpbHRvOmlkckBpZXRmLm9yZz4+DQpDYzogImRicnVu Z2FyZEBhdHQuY29tPG1haWx0bzpkYnJ1bmdhcmRAYXR0LmNvbT4iIDxkYnJ1bmdhcmRAYXR0LmNv bTxtYWlsdG86ZGJydW5nYXJkQGF0dC5jb20+Pg0KU3ViamVjdDogW0lkcl0gMiBXZWVrIFdHIExD IGRyYWZ0LWlldGYtaWRyLWFkZC1wYXRocy1pbXBsZW1lbnRhdGlvbi0wMCAoNC82IHRvIDQvMjAv MjAxNSkNCg0KVGhpcyBpcyBhIDIgd2VlayBXRyBsYXN0IGNhbGwgb24gdGhlIGRyYWZ0LWlldGYt aWRyLWFkZC1wYXRocy1pbXBsZW1lbnRhdGlvbi0wMC4NCg0KUGxlYXNlIGluIHlvdXIgZGlzY3Vz c2lvbiwgcGxlYXNlIGluZGljYXRlOiAg4oCcc3VwcG9ydOKAnSBvciDigJxubyBzdXBwb3J04oCd IGZvciB0aGlzIFdHIExDLiAgWW91IGNhbiBzZWUgdGhlIGRyYWZ0IGF0Og0KIGh0dHA6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pZHItYWRkLXBhdGhzLWltcGxlbWVudGF0 aW9uLw0KDQpTdWUgSGFyZXMNCg0K --_000_D148819F15E37aceeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5TdXBwb3J0LiZu YnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VD VElPTiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTFwdDsg dGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7 IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1M RUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29s aWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4g c3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj5TdXNhbiBIYXJlcyAmbHQ7PGEg aHJlZj0ibWFpbHRvOnNoYXJlc0BuZHpoLmNvbSI+c2hhcmVzQG5kemguY29tPC9hPiZndDs8YnI+ DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9zcGFuPk1vbmRheSwgQXBy aWwgNiwgMjAxNSBhdCA2OjI1IFBNPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQi PlRvOiA8L3NwYW4+aWRyIHdnICZsdDs8YSBocmVmPSJtYWlsdG86aWRyQGlldGYub3JnIj5pZHJA aWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5DYzog PC9zcGFuPiZxdW90OzxhIGhyZWY9Im1haWx0bzpkYnJ1bmdhcmRAYXR0LmNvbSI+ZGJydW5nYXJk QGF0dC5jb208L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86ZGJydW5nYXJkQGF0dC5jb20i PmRicnVuZ2FyZEBhdHQuY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6 Ym9sZCI+U3ViamVjdDogPC9zcGFuPltJZHJdIDIgV2VlayBXRyBMQyBkcmFmdC1pZXRmLWlkci1h ZGQtcGF0aHMtaW1wbGVtZW50YXRpb24tMDAgKDQvNiB0byA0LzIwLzIwMTUpPGJyPg0KPC9kaXY+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVU SU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVGVDogI2I1YzRkZiA1IHNvbGlkOyBQQURE SU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+DQo8ZGl2IHhtbG5zOnY9InVybjpzY2hlbWFz LW1pY3Jvc29mdC1jb206dm1sIiB4bWxuczpvPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9m ZmljZTpvZmZpY2UiIHhtbG5zOnc9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOndv cmQiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vb2ZmaWNlLzIwMDQvMTIv b21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPg0KPG1ldGEgbmFt ZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVt KSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxp Lk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlz aXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFp bFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPGRpdiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIg dmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTogMTBwdDsgZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBjb2xvcjogYmxhY2s7Ij5U aGlzIGlzIGEgMiB3ZWVrIFdHIGxhc3QgY2FsbCBvbiB0aGUgZHJhZnQtaWV0Zi1pZHItYWRkLXBh dGhzLWltcGxlbWVudGF0aW9uLTAwLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBjb2xvcjogYmxhY2s7 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibGluZS1oZWlnaHQ6MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250 LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGNvbG9yOiBibGFjazsiPlBsZWFzZSBpbiB5b3Vy IGRpc2N1c3Npb24sIHBsZWFzZSBpbmRpY2F0ZTombmJzcDsg4oCcc3VwcG9ydOKAnSBvciDigJxu byBzdXBwb3J04oCdIGZvciB0aGlzIFdHIExDLiAmbmJzcDtZb3UgY2FuIHNlZSB0aGUgZHJhZnQg YXQ6DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bGluZS1oZWlnaHQ6MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZh bWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGNvbG9yOiBibGFjazsiPiZuYnNwOzxhIGhyZWY9Imh0 dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pZHItYWRkLXBhdGhzLWlt cGxlbWVudGF0aW9uLyI+aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRm LWlkci1hZGQtcGF0aHMtaW1wbGVtZW50YXRpb24vPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMi4wcHQiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgY29s b3I6IGJsYWNrOyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTog MTBwdDsgZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBjb2xvcjogYmxhY2s7Ij5TdWUg SGFyZXMNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9zcGFuPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_D148819F15E37aceeciscocom_-- From nobody Mon Apr 6 15:32:56 2015 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 B56C61A7022 for ; Mon, 6 Apr 2015 15:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 OgzlGlcL6qG7 for ; Mon, 6 Apr 2015 15:32:53 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D8A61A7D85 for ; Mon, 6 Apr 2015 15:32:53 -0700 (PDT) X-AuditID: c6180641-f790b6d000004359-0a-5522a6fef18d Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 3F.CD.17241.EF6A2255; Mon, 6 Apr 2015 17:32:15 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0210.002; Mon, 6 Apr 2015 18:32:49 -0400 From: Jeff Tantsura To: Susan Hares Thread-Topic: [Idr] 2 Week WG LC draft-ietf-idr-add-paths-implementation-00 (4/6 to 4/20/2015) Thread-Index: AdBwuFOi+PNmnXfYQEG3Ry1KQ3sZCgAAUlac Date: Mon, 6 Apr 2015 22:32:49 +0000 Message-ID: <836F39D0-CBAB-4530-9A28-D46FD2688FDE@ericsson.com> References: <000301d070b8$85a8ccf0$90fa66d0$@ndzh.com> In-Reply-To: <000301d070b8$85a8ccf0$90fa66d0$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_836F39D0CBAB45309A28D46FD2688FDEericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMLMWRmVeSWpSXmKPExsUyuXSPt+7/ZUqhBm+O8lts37mExeLV7WdM Fn/evGJxYPZ42T+H0WPJkp9MHrNfX2cNYI7isklJzcksSy3St0vgyvi+cjZbwXulim2TqxoY F8t3MXJySAiYSLzZ+poFwhaTuHBvPRuILSRwlFHi+42cLkYuIHsZo8S/w8/AitgEDCT+fzsO ZosIKEocubqOHcRmFnCSeNvykBXEFhaIl/h34wNUTYLEhS0TGbsYOYBsI4l7R4RAwiwCKhIn LnWygYR5Bewl5n9Nh1hrJtExcQYjiM0pYC4x++ctMJsR6LTvp9YwQWwSl7j1ZD4TxMkCEkv2 nGeGsEUlXj7+xwpRkyzx8fE/sFd4BQQlTs58wjKBUWQWkvZZSMpmISmDiBtIvD83nxnC1pZY tvA1lK0vsfHLWUZk8QWM7KsYOUqLU8ty040MNzECY+mYBJvjDsYFnywPMQpwMCrx8CZsUAwV Yk0sK67MPcQozcGiJM5bduVgiJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQZGq+MJuxV8w2Ie nK+vmGzCWXD6bc3knrpDwRt7mFY8ejP5Zt2cy773m3wnumnNYr5SdGpylpY/18JFfNWbrhi7 Sla8dBf9ozsvbCqjhrSBd9iEE189rJrvztv1O+hsgO4O3de93F2XPlqXTLhX6KLSdE3s1/TZ eoWPWBfd3JRaVp1v8+1S+7NtSizFGYmGWsxFxYkAzB2DL4YCAAA= Archived-At: Cc: idr wg , "dbrungard@att.com" Subject: Re: [Idr] 2 Week WG LC draft-ietf-idr-add-paths-implementation-00 (4/6 to 4/20/2015) 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, 06 Apr 2015 22:32:54 -0000 --_000_836F39D0CBAB45309A28D46FD2688FDEericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Yes/support Regards, Jeff On Apr 6, 2015, at 7:25 PM, Susan Hares > wrote: This is a 2 week WG last call on the draft-ietf-idr-add-paths-implementatio= n-00. Please in your discussion, please indicate: =93support=94 or =93no support= =94 for this WG LC. You can see the draft at: http://datatracker.ietf.org/doc/draft-ietf-idr-add-paths-implementation/ Sue Hares _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr --_000_836F39D0CBAB45309A28D46FD2688FDEericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Yes/support

Regards,
Jeff

On Apr 6, 2015, at 7:25 PM, Susan Hares <shares@ndzh.com> wrote:

= This is a 2 week WG last call on the draft-ietf-idr-add-paths-implementatio= n-00.

=  

= Please in your discussion, please indicate:  =93support=94 or =93no su= pport=94 for this WG LC.  You can see the draft at:

=  http://datatracker.ietf.org/doc/draft-ietf-idr-add-paths-im= plementation/

=  

= Sue Hares

 

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.iet= f.org/mailman/listinfo/idr
--_000_836F39D0CBAB45309A28D46FD2688FDEericssoncom_-- From nobody Mon Apr 6 15:36:47 2015 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 B860D1A92BC for ; Mon, 6 Apr 2015 15:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.155 X-Spam-Level: X-Spam-Status: No, score=-97.155 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 jjX8QxO_XH6v for ; Mon, 6 Apr 2015 15:36:44 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 7B0FD1A909E for ; Mon, 6 Apr 2015 15:36:44 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=74.43.47.142; From: "Susan Hares" To: "idr wg" Date: Mon, 6 Apr 2015 18:36:41 -0400 Message-ID: <002e01d070ba$275479e0$75fd6da0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002F_01D07098.A0434F10" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AdBwudDRspjI4CwBRnyuVoZtgQp5UQ== X-Authenticated-User: skh@ndzh.com Archived-At: Cc: dbrungard@att.com Subject: [Idr] WG LC for draft-ietf-bgp-route-oscillation-stop (4/6 to 4/20) 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, 06 Apr 2015 22:36:45 -0000 This is a multipart message in MIME format. ------=_NextPart_000_002F_01D07098.A0434F10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This begins a 2 week WG LC for draft-ietf-bgp-route-oscillation. In your comments about the readiness of the draft please include "support" or "no support", and comment about the value of the draft. You can see the draft at: http://datatracker.ietf.org/doc/draft-ietf-idr-route-oscillation-stop/ Sue Hares and John Scudder ------=_NextPart_000_002F_01D07098.A0434F10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This = begins a 2 week WG LC for draft-ietf-bgp-route-oscillation. In your = comments about the readiness of the draft please include = “support” or “no support”, and comment about the = value of the draft.

 

You can see = the draft at:

 

http://datatracker.ietf.org/doc/draft-ietf-idr-route-oscillation-s= top/

 

Sue Hares and John = Scudder

------=_NextPart_000_002F_01D07098.A0434F10-- From nobody Mon Apr 6 16:15:25 2015 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 4AFE91ACE1F for ; Mon, 6 Apr 2015 16:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pOQ6m-cOVByj for ; Mon, 6 Apr 2015 16:15:22 -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 75D431ACE18 for ; Mon, 6 Apr 2015 16:15:18 -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 BUN87087; Mon, 06 Apr 2015 23:15:16 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.212.94.49) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 7 Apr 2015 00:15:15 +0100 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.13]) by SJCEML703-CHM.china.huawei.com ([169.254.5.137]) with mapi id 14.03.0158.001; Mon, 6 Apr 2015 16:15:09 -0700 From: Richard Li To: Susan Hares , idr wg Thread-Topic: [Idr] 2 Week WG LC draft-ietf-idr-add-paths-implementation-00 (4/6 to 4/20/2015) Thread-Index: AdBwuFOi+PNmnXfYQEG3Ry1KQ3sZCgAByXjg Date: Mon, 6 Apr 2015 23:15:07 +0000 Message-ID: References: <000301d070b8$85a8ccf0$90fa66d0$@ndzh.com> In-Reply-To: <000301d070b8$85a8ccf0$90fa66d0$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.48.21] Content-Type: multipart/alternative; boundary="_000_F061CEB6876F904F8EA6D6B92877731C38E466DASJCEML701CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "dbrungard@att.com" Subject: Re: [Idr] 2 Week WG LC draft-ietf-idr-add-paths-implementation-00 (4/6 to 4/20/2015) 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, 06 Apr 2015 23:15:24 -0000 --_000_F061CEB6876F904F8EA6D6B92877731C38E466DASJCEML701CHMchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes/Support. Richard From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Monday, April 06, 2015 3:25 PM To: idr wg Cc: dbrungard@att.com Subject: [Idr] 2 Week WG LC draft-ietf-idr-add-paths-implementation-00 (4/6= to 4/20/2015) This is a 2 week WG last call on the draft-ietf-idr-add-paths-implementatio= n-00. Please in your discussion, please indicate: "support" or "no support" for = this WG LC. You can see the draft at: http://datatracker.ietf.org/doc/draft-ietf-idr-add-paths-implementation/ Sue Hares --_000_F061CEB6876F904F8EA6D6B92877731C38E466DASJCEML701CHMchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes/Support.

 

Richard

 

From: Idr [mai= lto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Monday, April 06, 2015 3:25 PM
To: idr wg
Cc: dbrungard@att.com
Subject: [Idr] 2 Week WG LC draft-ietf-idr-add-paths-implementation-= 00 (4/6 to 4/20/2015)

 

= This is a 2 week WG last call on the draft-ietf-idr-add-paths-implementatio= n-00.

=  

= Please in your discussion, please indicate:  “support” or = “no support” for this WG LC.  You can see the draft at:

=  http://datatracker.ietf.org/doc/draft-ietf-idr-add-paths-im= plementation/

=  

= Sue Hares

 

--_000_F061CEB6876F904F8EA6D6B92877731C38E466DASJCEML701CHMchi_-- From nobody Mon Apr 6 19:15:55 2015 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 B4CA51B2D15 for ; Mon, 6 Apr 2015 19:15:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YWTkFUUX3VSU for ; Mon, 6 Apr 2015 19:15:53 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by ietfa.amsl.com (Postfix) with ESMTP id BDCEC1B2D14 for ; Mon, 6 Apr 2015 19:15:48 -0700 (PDT) Received: from [192.168.1.10] (pool-70-106-220-218.clppva.fios.verizon.net [70.106.220.218]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id 86B6C540517; Mon, 6 Apr 2015 22:15:47 -0400 (EDT) References: <000301d070b8$85a8ccf0$90fa66d0$@ndzh.com> Mime-Version: 1.0 (1.0) In-Reply-To: <000301d070b8$85a8ccf0$90fa66d0$@ndzh.com> Content-Type: multipart/alternative; boundary=Apple-Mail-B192DBB8-3B61-4333-9E0A-5CFF88956DB5 Content-Transfer-Encoding: 7bit Message-Id: <61E39304-8EAB-41FD-BE0F-ECA5CC9524C1@puck.nether.net> X-Mailer: iPhone Mail (12D508) From: Jon Mitchell Date: Mon, 6 Apr 2015 22:15:42 -0400 To: Susan Hares Archived-At: Cc: idr wg , "dbrungard@att.com" Subject: Re: [Idr] 2 Week WG LC draft-ietf-idr-add-paths-implementation-00 (4/6 to 4/20/2015) 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, 07 Apr 2015 02:15:54 -0000 --Apple-Mail-B192DBB8-3B61-4333-9E0A-5CFF88956DB5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Support. -Jon > On Apr 6, 2015, at 6:25 PM, Susan Hares wrote: >=20 > This is a 2 week WG last call on the draft-ietf-idr-add-paths-implementati= on-00. > =20 > Please in your discussion, please indicate: =E2=80=9Csupport=E2=80=9D or =E2= =80=9Cno support=E2=80=9D for this WG LC. You can see the draft at: > http://datatracker.ietf.org/doc/draft-ietf-idr-add-paths-implementation/ > =20 > Sue Hares > =20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr --Apple-Mail-B192DBB8-3B61-4333-9E0A-5CFF88956DB5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Support.

-Jon

On Apr 6, 2015, at 6:25 PM, Susan Hares <shares@ndzh.com> wrote:

This is a 2 week= WG last call on the draft-ietf-idr-add-paths-implementation-00. =

 

Please in your discussion, please indicate= :  =E2=80=9Csupport=E2=80=9D or =E2=80=9Cno support=E2=80=9D for this W= G LC.  You can see the draft at:

 htt= p://datatracker.ietf.org/doc/draft-ietf-idr-add-paths-implementation/

 

Sue Hares

<= p class=3D"MsoNormal"> 

_______________________________________________=
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr
= --Apple-Mail-B192DBB8-3B61-4333-9E0A-5CFF88956DB5-- From nobody Mon Apr 6 19:28:23 2015 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 C8F291B2D6C for ; Mon, 6 Apr 2015 19:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dWzoTYOjt3R9 for ; Mon, 6 Apr 2015 19:28:19 -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 249E11B2D6A for ; Mon, 6 Apr 2015 19:28:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4702; q=dns/txt; s=iport; t=1428373699; x=1429583299; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=AmAI8KihfdQzwAUXawjf9HznETfL5kUtgLyu9vre3lE=; b=hoJmJ8L0PbBChSuIi6/YjqDsj56lY/9lLDuj67J/SYVur45Zu8gny5h4 zJA8sjRcap+aUWfdljxYPYHwEka0L5+1H3BkbKwuSE8AKmsiXDbScBFcr ZmTOIekhKPN7OoMpCHmzQt7v1EbucBLqcXGGu5cmUjKiX4iJcOmrJZPPd Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AQDACaPyNV/5FdJa1cgkVDUlwFtUWNMTyBegELhXsCgSRMAQEBAQEBfoQfAQEEAQEBKkELEAIBCA4xBycLFBEBAQQOBYgvDctoAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4sphHUEB4QtBZBrg3WGDYEdOoJ7jDqDSCKCM4E8b4FEfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,535,1422921600"; d="scan'208,217";a="138848644" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-5.cisco.com with ESMTP; 07 Apr 2015 02:28:18 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t372SI02013264 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 7 Apr 2015 02:28:18 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.154]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.03.0195.001; Mon, 6 Apr 2015 21:28:18 -0500 From: "Bertrand Duvivier (bduvivie)" To: Susan Hares Thread-Topic: [Idr] 2 Week WG LC draft-ietf-idr-add-paths-implementation-00 (4/6 to 4/20/2015) Thread-Index: AdBwuFOi+PNmnXfYQEG3Ry1KQ3sZCgASlSYA//+OKgA= Date: Tue, 7 Apr 2015 02:28:17 +0000 Message-ID: References: <000301d070b8$85a8ccf0$90fa66d0$@ndzh.com> <61E39304-8EAB-41FD-BE0F-ECA5CC9524C1@puck.nether.net> In-Reply-To: <61E39304-8EAB-41FD-BE0F-ECA5CC9524C1@puck.nether.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [10.24.75.80] Content-Type: multipart/alternative; boundary="_000_D1488E1E1562Dbduvivieciscocom_" MIME-Version: 1.0 Archived-At: Cc: idr wg , "dbrungard@att.com" Subject: Re: [Idr] 2 Week WG LC draft-ietf-idr-add-paths-implementation-00 (4/6 to 4/20/2015) 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, 07 Apr 2015 02:28:22 -0000 --_000_D1488E1E1562Dbduvivieciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Support Cisco Product Manager IP routing , =85 On Apr 6, 2015, at 6:25 PM, Susan Hares > wrote: This is a 2 week WG last call on the draft-ietf-idr-add-paths-implementatio= n-00. Please in your discussion, please indicate: =93support=94 or =93no support= =94 for this WG LC. You can see the draft at: http://datatracker.ietf.org/doc/draft-ietf-idr-add-paths-implementation/ Sue Hares _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr --_000_D1488E1E1562Dbduvivieciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <19DECBBC178EAD4791EE6F92DAF9CBAA@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Support

Cisco Product Manager
IP routing , =85 


On Apr 6, 2015, at 6:25 PM, Susan Hares <shares@ndzh.com> wrote:

This is a 2 week WG= last call on the draft-ietf-idr-add-paths-implementation-00.

 

Please in your disc= ussion, please indicate:  =93support=94 or =93no support=94 for this W= G LC.  You can see the draft at:

 htt= p://datatracker.ietf.org/doc/draft-ietf-idr-add-paths-implementation/

 

Sue Hares

 

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.iet= f.org/mailman/listinfo/idr
 --_000_D1488E1E1562Dbduvivieciscocom_-- From nobody Mon Apr 6 21:16:36 2015 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 E201A1AD34D for ; Mon, 6 Apr 2015 21:16:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SLs1xopv2cMS for ; Mon, 6 Apr 2015 21:16:33 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B2A21A702A for ; Mon, 6 Apr 2015 21:16:32 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 547883E2E093B; Tue, 7 Apr 2015 04:16:29 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t374GUJs031920 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 7 Apr 2015 06:16:30 +0200 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.17]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Tue, 7 Apr 2015 06:16:30 +0200 From: "Henderickx, Wim (Wim)" To: Susan Hares , idr wg Thread-Topic: [Idr] 2 Week WG LC draft-ietf-idr-add-paths-implementation-00 (4/6 to 4/20/2015) Thread-Index: AdBwuFOi+PNmnXfYQEG3Ry1KQ3sZCgAMUtOA Date: Tue, 7 Apr 2015 04:16:29 +0000 Message-ID: <7D0268CD-8495-4143-AEC8-9CF8B75037DF@alcatel-lucent.com> References: <000301d070b8$85a8ccf0$90fa66d0$@ndzh.com> In-Reply-To: <000301d070b8$85a8ccf0$90fa66d0$@ndzh.com> Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/15.8.1.150311 x-originating-ip: [135.239.27.39] Content-Type: multipart/alternative; boundary="_000_7D0268CD84954143AEC89CF8B75037DFalcatellucentcom_" MIME-Version: 1.0 Archived-At: Cc: "dbrungard@att.com" Subject: Re: [Idr] 2 Week WG LC draft-ietf-idr-add-paths-implementation-00 (4/6 to 4/20/2015) 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, 07 Apr 2015 04:16:35 -0000 --_000_7D0268CD84954143AEC89CF8B75037DFalcatellucentcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 c3VwcG9ydA0KDQpGcm9tOiBTdXNhbiBIYXJlcw0KRGF0ZTogVHVlc2RheSA3IEFwcmlsIDIwMTUg MDA6MjUNClRvOiBpZHIgd2cNCkNjOiAiZGJydW5nYXJkQGF0dC5jb208bWFpbHRvOmRicnVuZ2Fy ZEBhdHQuY29tPiINClN1YmplY3Q6IFtJZHJdIDIgV2VlayBXRyBMQyBkcmFmdC1pZXRmLWlkci1h ZGQtcGF0aHMtaW1wbGVtZW50YXRpb24tMDAgKDQvNiB0byA0LzIwLzIwMTUpDQoNClRoaXMgaXMg YSAyIHdlZWsgV0cgbGFzdCBjYWxsIG9uIHRoZSBkcmFmdC1pZXRmLWlkci1hZGQtcGF0aHMtaW1w bGVtZW50YXRpb24tMDAuDQoNClBsZWFzZSBpbiB5b3VyIGRpc2N1c3Npb24sIHBsZWFzZSBpbmRp Y2F0ZTogIOKAnHN1cHBvcnTigJ0gb3Ig4oCcbm8gc3VwcG9ydOKAnSBmb3IgdGhpcyBXRyBMQy4g IFlvdSBjYW4gc2VlIHRoZSBkcmFmdCBhdDoNCiBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWlldGYtaWRyLWFkZC1wYXRocy1pbXBsZW1lbnRhdGlvbi8NCg0KU3VlIEhhcmVz DQoNCg== --_000_7D0268CD84954143AEC89CF8B75037DFalcatellucentcom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2PnN1cHBvcnQ8L2Rpdj4NCjxkaXY+DQo8ZGl2IGlkPSJNQUNfT1VUTE9PS19TSUdOQVRVUkUi PjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFu IGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxp YnJpOyBmb250LXNpemU6MTJwdDsgdGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVS LUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1C T1RUT006IDBpbjsgUEFERElORy1MRUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVS LVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJ TkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bh bj5TdXNhbiBIYXJlczxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8 L3NwYW4+VHVlc2RheSA3IEFwcmlsIDIwMTUgMDA6MjU8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13 ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bhbj5pZHIgd2c8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWln aHQ6Ym9sZCI+Q2M6IDwvc3Bhbj4mcXVvdDs8YSBocmVmPSJtYWlsdG86ZGJydW5nYXJkQGF0dC5j b20iPmRicnVuZ2FyZEBhdHQuY29tPC9hPiZxdW90Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdl aWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+W0lkcl0gMiBXZWVrIFdHIExDIGRyYWZ0LWlldGYt aWRyLWFkZC1wYXRocy1pbXBsZW1lbnRhdGlvbi0wMCAoNC82IHRvIDQvMjAvMjAxNSk8YnI+DQo8 L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2IHhtbG5zOnY9InVybjpzY2hlbWFzLW1pY3Jv c29mdC1jb206dm1sIiB4bWxuczpvPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpv ZmZpY2UiIHhtbG5zOnc9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOndvcmQiIHht bG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vb2ZmaWNlLzIwMDQvMTIvb21tbCIg eG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPg0KPG1ldGEgbmFtZT0iR2Vu ZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8 c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIg NCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05v cm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwg c3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29s b3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPGRpdiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9 InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBw dDsgZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBjb2xvcjogYmxhY2s7Ij5UaGlzIGlz IGEgMiB3ZWVrIFdHIGxhc3QgY2FsbCBvbiB0aGUgZHJhZnQtaWV0Zi1pZHItYWRkLXBhdGhzLWlt cGxlbWVudGF0aW9uLTAwLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTog MTBwdDsgZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBjb2xvcjogYmxhY2s7Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGlu ZS1oZWlnaHQ6MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWls eTogQXJpYWwsIHNhbnMtc2VyaWY7IGNvbG9yOiBibGFjazsiPlBsZWFzZSBpbiB5b3VyIGRpc2N1 c3Npb24sIHBsZWFzZSBpbmRpY2F0ZTombmJzcDsg4oCcc3VwcG9ydOKAnSBvciDigJxubyBzdXBw b3J04oCdIGZvciB0aGlzIFdHIExDLiAmbmJzcDtZb3UgY2FuIHNlZSB0aGUgZHJhZnQgYXQ6DQo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1o ZWlnaHQ6MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTog QXJpYWwsIHNhbnMtc2VyaWY7IGNvbG9yOiBibGFjazsiPiZuYnNwOzxhIGhyZWY9Imh0dHA6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pZHItYWRkLXBhdGhzLWltcGxlbWVu dGF0aW9uLyI+aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWlkci1h ZGQtcGF0aHMtaW1wbGVtZW50YXRpb24vPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMi4wcHQiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgY29sb3I6IGJs YWNrOyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImxpbmUtaGVpZ2h0OjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsg Zm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBjb2xvcjogYmxhY2s7Ij5TdWUgSGFyZXMN CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_7D0268CD84954143AEC89CF8B75037DFalcatellucentcom_-- From nobody Mon Apr 6 21:17:04 2015 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 7F1DA1A702A for ; Mon, 6 Apr 2015 21:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7XoqzXzSPsSR for ; Mon, 6 Apr 2015 21:17:00 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CD151AD34F for ; Mon, 6 Apr 2015 21:16:58 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id B49C44A316349; Tue, 7 Apr 2015 04:16:55 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t374Gu37007785 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 7 Apr 2015 06:16:56 +0200 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.17]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Tue, 7 Apr 2015 06:16:56 +0200 From: "Henderickx, Wim (Wim)" To: Susan Hares , idr wg Thread-Topic: [Idr] WG LC for draft-ietf-bgp-route-oscillation-stop (4/6 to 4/20) Thread-Index: AdBwudDRspjI4CwBRnyuVoZtgQp5UQAL90EA Date: Tue, 7 Apr 2015 04:16:55 +0000 Message-ID: <4BA83D7D-1F8F-4B6F-82EF-72B3AF733225@alcatel-lucent.com> References: <002e01d070ba$275479e0$75fd6da0$@ndzh.com> In-Reply-To: <002e01d070ba$275479e0$75fd6da0$@ndzh.com> Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/15.8.1.150311 x-originating-ip: [135.239.27.39] Content-Type: multipart/alternative; boundary="_000_4BA83D7D1F8F4B6F82EF72B3AF733225alcatellucentcom_" MIME-Version: 1.0 Archived-At: Cc: "dbrungard@att.com" Subject: Re: [Idr] WG LC for draft-ietf-bgp-route-oscillation-stop (4/6 to 4/20) 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, 07 Apr 2015 04:17:01 -0000 --_000_4BA83D7D1F8F4B6F82EF72B3AF733225alcatellucentcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 c3VwcG9ydA0KDQpGcm9tOiBTdXNhbiBIYXJlcw0KRGF0ZTogVHVlc2RheSA3IEFwcmlsIDIwMTUg MDA6MzYNClRvOiBpZHIgd2cNCkNjOiAiZGJydW5nYXJkQGF0dC5jb208bWFpbHRvOmRicnVuZ2Fy ZEBhdHQuY29tPiINClN1YmplY3Q6IFtJZHJdIFdHIExDIGZvciBkcmFmdC1pZXRmLWJncC1yb3V0 ZS1vc2NpbGxhdGlvbi1zdG9wICg0LzYgdG8gNC8yMCkNCg0KVGhpcyBiZWdpbnMgYSAyIHdlZWsg V0cgTEMgZm9yIGRyYWZ0LWlldGYtYmdwLXJvdXRlLW9zY2lsbGF0aW9uLiBJbiB5b3VyIGNvbW1l bnRzIGFib3V0IHRoZSByZWFkaW5lc3Mgb2YgdGhlIGRyYWZ0IHBsZWFzZSBpbmNsdWRlIOKAnHN1 cHBvcnTigJ0gb3Ig4oCcbm8gc3VwcG9ydOKAnSwgYW5kIGNvbW1lbnQgYWJvdXQgdGhlIHZhbHVl IG9mIHRoZSBkcmFmdC4NCg0KWW91IGNhbiBzZWUgdGhlIGRyYWZ0IGF0Og0KDQpodHRwOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaWRyLXJvdXRlLW9zY2lsbGF0aW9uLXN0 b3AvDQoNClN1ZSBIYXJlcyBhbmQgSm9obiBTY3VkZGVyDQo= --_000_4BA83D7D1F8F4B6F82EF72B3AF733225alcatellucentcom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2PnN1cHBvcnQ8L2Rpdj4NCjxkaXY+DQo8ZGl2IGlkPSJNQUNfT1VUTE9PS19TSUdOQVRVUkUi PjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFu IGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxp YnJpOyBmb250LXNpemU6MTJwdDsgdGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVS LUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1C T1RUT006IDBpbjsgUEFERElORy1MRUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVS LVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJ TkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bh bj5TdXNhbiBIYXJlczxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8 L3NwYW4+VHVlc2RheSA3IEFwcmlsIDIwMTUgMDA6MzY8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13 ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bhbj5pZHIgd2c8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWln aHQ6Ym9sZCI+Q2M6IDwvc3Bhbj4mcXVvdDs8YSBocmVmPSJtYWlsdG86ZGJydW5nYXJkQGF0dC5j b20iPmRicnVuZ2FyZEBhdHQuY29tPC9hPiZxdW90Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdl aWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+W0lkcl0gV0cgTEMgZm9yIGRyYWZ0LWlldGYtYmdw LXJvdXRlLW9zY2lsbGF0aW9uLXN0b3AgKDQvNiB0byA0LzIwKTxicj4NCjwvZGl2Pg0KPGRpdj48 YnI+DQo8L2Rpdj4NCjxkaXYgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwi IHhtbG5zOm89InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6 dz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDov L3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDov L3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlh IE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8q IFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNv Tm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQphOmxpbmss IHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVy bGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8ZGl2IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGJlZ2lu cyBhIDIgd2VlayBXRyBMQyBmb3IgZHJhZnQtaWV0Zi1iZ3Atcm91dGUtb3NjaWxsYXRpb24uIElu IHlvdXIgY29tbWVudHMgYWJvdXQgdGhlIHJlYWRpbmVzcyBvZiB0aGUgZHJhZnQgcGxlYXNlIGlu Y2x1ZGUg4oCcc3VwcG9ydOKAnSBvciDigJxubyBzdXBwb3J04oCdLCBhbmQgY29tbWVudCBhYm91 dCB0aGUgdmFsdWUgb2YgdGhlIGRyYWZ0Lg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPllvdSBj YW4gc2VlIHRoZSBkcmFmdCBhdDogPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0 dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pZHItcm91dGUtb3NjaWxs YXRpb24tc3RvcC8iPmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1p ZHItcm91dGUtb3NjaWxsYXRpb24tc3RvcC88L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlN1 ZSBIYXJlcyBhbmQgSm9obiBTY3VkZGVyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L3NwYW4+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4BA83D7D1F8F4B6F82EF72B3AF733225alcatellucentcom_-- From nobody Tue Apr 7 11:41:53 2015 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 594141B3A52; Tue, 7 Apr 2015 11:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.19 X-Spam-Level: X-Spam-Status: No, score=-3.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Qi9SE8_Qzww; Tue, 7 Apr 2015 11:41:50 -0700 (PDT) Received: from smtp1.lax.icann.org (smtp01.icann.org [192.0.33.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CC521B3A29; Tue, 7 Apr 2015 11:41:50 -0700 (PDT) Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id t37Ifn6g012667; Tue, 7 Apr 2015 18:41:49 GMT Received: by request3.lax.icann.org (Postfix, from userid 48) id 9118DC2081E; Tue, 7 Apr 2015 18:41:49 +0000 (UTC) RT-Owner: pearl.liang From: "Pearl Liang via RT" In-Reply-To: <20150318203322.17138.21318.idtracker@ietfa.amsl.com> References: <20150318203322.17138.21318.idtracker@ietfa.amsl.com> Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #814082 X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/) X-RT-Originator: pearl.liang@icann.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Tue, 07 Apr 2015 18:41:49 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Cc: idr@ietf.org, draft-ietf-idr-flowspec-redirect-rt-bis@tools.ietf.org, idr-chairs@ietf.org Subject: [Idr] [IANA #814082] Last Call: (Clarification of the Flowspec Redirect Extended Community) to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Reply-To: drafts-lastcall@iana.org List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 18:41:52 -0000 (BEGIN IANA LAST CALL COMMENTS) IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-idr-flowspec-redirect-rt-bis-03. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon as possible. IANA has several questions about some of the actions requested in the IANA Considerations section of this document. We received the following comments/questions from the IANA's reviewer: IANA understands that, upon approval of this document, there are four actions which IANA is required to complete. First, in the Generic Transitive Experimental Use Extended Community Sub-Types subregistry of the Border Gateway Protocol (BGP) Extended Communities registry located at: http://www.iana.org/assignments/bgp-extended-communities/ the existing registration for Type Value 0x08 will have its name updated from: Flow spec redirect to: Flow spec redirect AS-2byte format and have the reference changed to [ RFC-to-be ]. QUESTION: This draft indicates that it updates RFC5575 according to the header information in the draft. Is the author intended to remove the existing defining reference from the registry? Second, in the BGP Transitive Extended Community Types subregistry also in the Border Gateway Protocol (BGP) Extended Communities registry located at: http://www.iana.org/assignments/bgp-extended-communities/ two new registrations will be added as follows: Type Value: 0x81 Name: Generic Transitive Experimental Use Extended Community Part 2 (Sub-Types are defined in the "Generic Transitive Experimental Extended Community Part 2 Sub-Types" Registry) Reference: [ RFC-to-be ] Type Value: 0x82 Name: Generic Transitive Experimental Use Extended Community Part 3 (Sub-Types are defined in the "Generic Transitive Experimental Extended Community Part 3 Sub-Types" Registry) Reference: [ RFC-to-be ] Third, a new registry is to be created called the "Generic Transitive Experimental Use Extended Community Part 2 Sub-Types" registry. IANA QUESTION -> Where should this new registry be located? Is it a néw registry on the IANA Matrix or is it a subregistry of an existing registry? If it is a subregistry of an existing registry, in which registry will it be contained? In the same BGP Extended Communities located at http://www.iana.org/assignments/bgp-extended-communities registry? IANA QUESTION -> What rules should be used for maintenance of this new registry? Please refer to RFC 5226 for guidance on how to select and apply maintenance policy for a new registry. QUESTION: What is the range for this new Part 2 Sub-Types registry? QUESTION: Is the author intended to use the same table format as the existing sub-registry "Generic Transitive Experimental Use Extended Community Sub-Types" which has the following columns: Sub-Type Value, Name, Reference, and (Registration) Date? IANA understands that there is a single initial registration in the new registry as follows: Type Value: 0x08 Name: Flow spec redirect IPv4 format Reference: [ RFC-to-be ] Fourth, a new registry is to be created called the "Generic Transitive Experimental Use Extended Community Part 3 Sub-Types" registry. IANA QUESTION -> Where should this new registry be located? Is it a néw registry on the IANA Matrix or is it a subregistry of an existing registry? If it is a subregistry of an existing registry, in which registry will it be contained? IANA QUESTION -> What rules should be used for maintenance of this new registry? Please refer to RFC 5226 for guidance on how to select and apply maintenance policy for a new registry. QUESTION: What is the range for this new Part 3 Sub-Types registry? QUESTION: Is the author intended to use the same table format as the existing sub-registry "Generic Transitive Experimental Use Extended Community Sub-Types" which has the following columns: Sub-Type Value, Name, Reference, and (Registration) Date? IANA understands that there is a single initial registration in the new registry as follows: Type Value: 0x08 Name: FFlow spec redirect AS-4byte format Reference: [ RFC-to-be ] IANA understands that these four actions are the only ones required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. Please note that IANA cannot reserve specific values. However, early allocation is available for some types of registrations. For more information, please see RFC 7120. Thanks, Pearl Liang ICANN (END IANA LAST CALL COMMENTS) On Wed Mar 18 20:33:49 2015, iesg-secretary@ietf.org wrote: > > The IESG has received a request from the Inter-Domain Routing WG (idr) > to > consider the following document: > - 'Clarification of the Flowspec Redirect Extended Community' > as Proposed > Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2015-04-08. Exceptionally, comments may > be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > This document clarifies the formatting of the the BGP Flowspec > Redirect Extended Community, originally documented in RFC 5575 > (Dissemination of Flow Specification Rules). > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-redirect-rt- > bis/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-redirect-rt- > bis/ballot/ > > > No IPR declarations have been submitted directly on this I-D. From nobody Tue Apr 7 12:05:40 2015 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 A6F941B3AEF; Tue, 7 Apr 2015 12:05:38 -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 2Xvo39eGX9GN; Tue, 7 Apr 2015 12:05:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EDB941B3AF0; Tue, 7 Apr 2015 12:05:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150407190526.13619.33226.idtracker@ietfa.amsl.com> Date: Tue, 07 Apr 2015 12:05:26 -0700 From: IETF Secretariat Archived-At: Subject: [Idr] ID Tracker State Update Notice: 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, 07 Apr 2015 19:05:38 -0000 IANA review state changed to IANA - Not OK ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-redirect-rt-bis/ From nobody Tue Apr 7 17:06:15 2015 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 9A0001ACDCE; Tue, 7 Apr 2015 17:06:13 -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 oGD-eYkZsmJ6; Tue, 7 Apr 2015 17:06:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 663951ACDBF; Tue, 7 Apr 2015 17:06:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150408000612.20634.74830.idtracker@ietfa.amsl.com> Date: Tue, 07 Apr 2015 17:06:12 -0700 From: IETF Secretariat Archived-At: Subject: [Idr] ID Tracker State Update Notice: 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, 08 Apr 2015 00:06:13 -0000 IANA review state changed to IANA - Not OK ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/ From nobody Wed Apr 8 00:09:06 2015 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 6FBEE1A0143; Wed, 8 Apr 2015 00:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NxanreyxDPa5; Wed, 8 Apr 2015 00:09:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E3EE71A0162; Wed, 8 Apr 2015 00:08:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: DraftTracker Mail System To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150408070859.9580.92026.idtracker@ietfa.amsl.com> Date: Wed, 08 Apr 2015 00:08:59 -0700 Archived-At: Cc: iesg-secretary@ietf.org Subject: [Idr] Last Call Expired: 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, 08 Apr 2015 07:09:02 -0000 Please DO NOT reply to this email. I-D: ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/ IETF Last Call has ended, and the state has been changed to Waiting for Writeup. From nobody Wed Apr 8 00:09:14 2015 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 81C391A0194; Wed, 8 Apr 2015 00:09: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, 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 SrMQDbbcq24P; Wed, 8 Apr 2015 00:09:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A2E551A017C; Wed, 8 Apr 2015 00:09:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: DraftTracker Mail System To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150408070900.9580.80169.idtracker@ietfa.amsl.com> Date: Wed, 08 Apr 2015 00:09:00 -0700 Archived-At: Cc: iesg-secretary@ietf.org Subject: [Idr] Last Call Expired: 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, 08 Apr 2015 07:09:04 -0000 Please DO NOT reply to this email. I-D: ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-redirect-rt-bis/ IETF Last Call has ended, and the state has been changed to Waiting for Writeup. From nobody Wed Apr 8 08:11:43 2015 Return-Path: X-Original-To: expand-draft-ietf-idr-ls-distribution.all@virtual.ietf.org Delivered-To: idr@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id F34EE1A870F; Tue, 7 Apr 2015 16:14:39 -0700 (PDT) X-Original-To: xfilter-draft-ietf-idr-ls-distribution.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-idr-ls-distribution.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE80A1A8704 for ; Tue, 7 Apr 2015 16:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.879 X-Spam-Level: X-Spam-Status: No, score=-0.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021] 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 NS4k6raUceq9 for ; Tue, 7 Apr 2015 16:14:37 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A74E1A86E2 for ; Tue, 7 Apr 2015 16:14:37 -0700 (PDT) Received: from smtp01.icann.org ([192.0.33.81]:48408 helo=smtp1.lax.icann.org) by zinfandel.tools.ietf.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YfchY-0005yN-5Q for draft-ietf-idr-ls-distribution.all@tools.ietf.org; Tue, 07 Apr 2015 16:14:36 -0700 Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id t37NEUqv025053; Tue, 7 Apr 2015 23:14:30 GMT Received: by request3.lax.icann.org (Postfix, from userid 48) id 3E94FC20831; Tue, 7 Apr 2015 23:14:30 +0000 (UTC) RT-Owner: amanda.baber From: "Amanda Baber via RT" In-Reply-To: <20150318194048.32558.24468.idtracker@ietfa.amsl.com> References: <20150318194048.32558.24468.idtracker@ietfa.amsl.com> Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #814076 X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/) X-RT-Originator: amanda.baber@icann.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Tue, 07 Apr 2015 23:14:30 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 192.0.33.81 X-SA-Exim-Rcpt-To: draft-ietf-idr-ls-distribution.all@tools.ietf.org X-SA-Exim-Mail-From: iana-shared@icann.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-idr-ls-distribution.all@ietf.org Resent-Message-Id: <20150407231437.0A74E1A86E2@ietfa.amsl.com> Resent-Date: Tue, 7 Apr 2015 16:14:37 -0700 (PDT) Resent-From: iana-shared@icann.org Archived-At: Archived-At: X-Mailman-Approved-At: Wed, 08 Apr 2015 08:11:41 -0700 Cc: draft-ietf-idr-ls-distribution.all@tools.ietf.org, iesg@ietf.org Subject: [Idr] [IANA #814076] REVISED Last Call: (North-Bound Distribution of Link-State and TE Information using BGP) to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Reply-To: drafts-lastcall@iana.org List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 23:14:40 -0000 (BEGIN IANA LAST CALL COMMENTS) IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-idr-ls-distribution-10. Please report any inaccuracies and respond to the questions below as soon as possible. IANA also requests two edits to the document's IANA Considerations section. IANA understands that, upon approval of this document, there are eight actions which IANA is required to complete. First, IANA will update the reference for the following Address Family Number registration at https://www.iana.org/assignments/address-family-numbers: 16388 BGP-LS [RFC-to-be] 2013-03-20 REQUESTED EDIT: Section 5 says, "This document requests a code point from the registry of Address Family Numbers. As per early allocation procedure this is AFI 16388." However, the term "early allocation" doesn't fit here. The "early allocation" procedure is a procedure defined by RFC 7120 that allows for a one-year temporary registration. 16388 was registered before this document was approved, but it's a permanent registration made in accordance with the registry's normal first-come, first-served procedure. Can you change this paragraph to "This document has registered Address Family Number 16388, BGP-LS" or "This document is the reference for Address Family Number 16388, BGP-LS," or something along those lines? Second, IANA will update the reference for the following SAFI Value registration at https://www.iana.org/assignments/safi-namespace: 71 BGP-LS [RFC-to-be] REQUESTED EDIT: As above, this registration was not an early allocation, as defined by RFC 7120. (An example of an early allocation is BGP Path Attribute BGP-LS Attribute, which has an expiration date listed in the registry.) Please change "This document requests a code point from the registry of Subsequent Address Family Numbers named 'BGP-LS'. As per early allocation procedure this is SAFI 71" to remove the reference to early allocation. Third, also in the Subsequent Address Family Identifiers (SAFI) Parameters registry at https://www.iana.org/assignments/safi-namespace/ a new SAFI value will be registered as follows: Value: [ RFC-to-be ] Description: BGP-LS-VPN Reference: [ RFC-to-be ] QUESTION: The document notes that the value doesn't have to come from the 1-63 range, but doesn't specify which range to use. Does the registration belong in the 64-127 "First Come First Served" range, or in the 128-240 range marked "Some recognized assignments below, others Reserved"? Fourth, the early allocation made by this document in the BGP Path Attributes registry at https://www.iana.org/assignments/bgp-parameters/ will be made permanent. Value 29 will have its reference changed to [ RFC-to-be ]. Fifth, a new registry called the BGP-LS NLRI-Types registry will be created in the Border Gateway Protocol - Link State (BGP-LS) Parameters top-level registry at http://www.iana.org/assignments/bgp-ls-parameters/ The registry will be maintained via Specification Required as defined by RFC 5226. Initial registrations: +------+---------------------------+---------------+ | Type | NLRI Type | Reference | +------+---------------------------+---------------+ | 0 | Reserved | [ RFC-to-be ] | | 1 | Node NLRI | [ RFC-to-be ] | | 2 | Link NLRI | [ RFC-to-be ] | | 3 | IPv4 Topology Prefix NLRI | [ RFC-to-be ] | | 4 | IPv6 Topology Prefix NLRI | [ RFC-to-be ] | | 5-65535 | Unassigned +------+---------------------------+---------------+ Sixth, a new registry called the BGP-LS Protocol-IDs registry will be created under the Border Gateway Protocol - Link State (BGP-LS) Parameters heading at http://www.iana.org/assignments/bgp-ls-parameters/ The registry will be maintained via Specification Required as defined by RFC 5226. Initial registrations: +-------------+----------------------------------+---------------+ | Protocol-ID | NLRI information source protocol | Reference | +-------------+----------------------------------+---------------+ | 0 | Reserved | [ RFC-to-be ] | | 1 | IS-IS Level 1 | [ RFC-to-be ] | | 2 | IS-IS Level 2 | [ RFC-to-be ] | | 3 | OSPFv2 | [ RFC-to-be ] | | 4 | Direct | [ RFC-to-be ] | | 5 | Static configuration | [ RFC-to-be ] | | 6 | OSPFv3 | [ RFC-to-be ] | | 7-255 | Unassigned +-------------+----------------------------------+---------------+ Seventh, a new registry called the BGP-LS Well-known Instance-IDs registry will be created under the Border Gateway Protocol - Link State (BGP-LS) Parameters top-level heading at http://www.iana.org/assignments/bgp-ls-parameters/ The registry will be maintained via Specification Required as defined by RFC 5226. Initial registrations: +------------+----------------------------------+---------------+ | Identifier | Routing Universe | Reference: | +------------+----------------------------------+---------------+ | 0 | Default Layer 3 Routing topology | [ RFC-to-be ] | | 1-31 | Reserved | [ RFC-to-be ] | +------------+----------------------------------+---------------+ Eighth, a new registry called the Node Anchor, Link Descriptor and Link Attribute TLVs registry will be created under the Border Gateway Protocol - Link State (BGP-LS) Parameters heading at http://www.iana.org/assignments/bgp-ls-parameters/ The registry will be maintained via Specification Required as defined by RFC 5226. Initial registrations: +-----------+---------------------+---------------+-----------------+ | TLV Code Point | Description | IS-IS TLV/Sub-TLC | Reference | +-----------+---------------------+---------------+-----------------+ | 0-255 | Reserved |[RFC-to-be ] | 256 | Local Node Descriptors | --- | Section 3.2.1.2 | | 257 | Remote Node Descriptors | --- | Section 3.2.1.3 | | 258 | Link Local/Remote Identifiers | 22/4 | [RFC5307]/1.1 | | 259 | IPv4 interface address | 22/6 | [RFC5305]/3.2 | | 260 | IPv4 neighbor address | 22/8 | [RFC5305]/3.3 | | 261 | IPv6 interface address | 22/12 | [RFC6119]/4.2 | | 262 | IPv6 neighbor address | 22/13 | [RFC6119]/4.3 | | 263 | Multi-Topology ID | --- | Section 3.2.1.5 | | 264 | OSPF Route Type | --- | Section 3.2.3 | | 265 | IP Reachability Information | --- | Section 3.2.3 | | 266-511 | Unassigned | 512 | Autonomous System | --- | Section 3.2.1.4 | | 513 | BGP-LS Identifier | --- | Section 3.2.1.4 | | 514 | OSPF Area ID | --- | Section 3.2.1.4 | | 515 | IGP Router-ID | --- | Section 3.2.1.4 | | 516-1023 | Unassigned | 1024 | Node Flag Bits | --- | Section 3.3.1.1 | | 1025 | Opaque Node Properties | --- | Section 3.3.1.5 | | 1026 | Node Name | variable | Section 3.3.1.3 | | 1027 | IS-IS Area Identifier | variable | Section 3.3.1.2 | | 1028 | IPv4 Router-ID of Local Node | 134/--- | [RFC5305]/4.3 | | 1029 | IPv6 Router-ID of Local Node | 140/--- | [RFC6119]/4.1 | | 1030 | IPv4 Router-ID of Remote Node | 134/--- | [RFC5305]/4.3 | | 1031 | IPv6 Router-ID of Remote Node | 140/--- | [RFC6119]/4.1 | | 1032-1087 | Unassigned | 1088 | Administrative group (color) | 22/3 | [RFC5305]/3.1 | | 1089 | Maximum link bandwidth | 22/9 | [RFC5305]/3.3 | | 1090 | Max. reservable link bandwidth | 22/10 | [RFC5305]/3.5 | | 1091 | Unreserved bandwidth | 22/11 | [RFC5305]/3.6 | | 1092 | TE Default Metric | 22/18 | Section 3.3.2.3 | | 1093 | Link Protection Type | 22/20 | [RFC5307]/1.2 | | 1094 | MPLS Protocol Mask | --- | Section 3.3.2.2 | | 1095 | IGP Metric | --- | Section 3.3.2.4 | | 1096 | Shared Risk Link Group | --- | Section 3.3.2.5 | | 1097 | Opaque link attribute | --- | Section 3.3.2.6 | | 1098 | Link Name attribute | --- | Section 3.3.2.7 | | 1099-1151 | Unassigned | 1152 | IGP Flags | --- | Section 3.3.3.1 | | 1153 | Route Tag | --- | [RFC5130] | | 1154 | Extended Tag | --- | [RFC5130] | | 1155 | Prefix Metric | --- | [RFC5305] | | 1156 | OSPF Forwarding Address | --- | [RFC2328] | | 1157 | Opaque Prefix Attribute | --- | Section 3.3.3.6 | | 1158-65535 | Unassigned +-----------+---------------------+---------------+-----------------+ IANA understands that these eight actions are the only ones required upon completion. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. Thanks, Amanda Baber IANA Request Specialist ICANN (END IANA LAST CALL COMMENTS) On Wed Mar 18 19:41:12 2015, iesg-secretary@ietf.org wrote: > > The IESG has received a request from the Inter-Domain Routing WG (idr) to > consider the following document: > - 'North-Bound Distribution of Link-State and TE Information using BGP' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2015-04-08. 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 > > > 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 file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/ballot/ > > > The following IPR Declarations may be related to this I-D: > > http://datatracker.ietf.org/ipr/1864/ > > > From nobody Wed Apr 8 08:11:44 2015 Return-Path: X-Original-To: expand-draft-ietf-idr-flowspec-redirect-rt-bis.all@virtual.ietf.org Delivered-To: idr@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 4AE911B3216; Wed, 8 Apr 2015 08:06:14 -0700 (PDT) X-Original-To: xfilter-draft-ietf-idr-flowspec-redirect-rt-bis.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-idr-flowspec-redirect-rt-bis.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B0991B3204 for ; Wed, 8 Apr 2015 08:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=unavailable 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 eO_t7Lzgzup8 for ; Wed, 8 Apr 2015 08:06:13 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7110B1B3206 for ; Wed, 8 Apr 2015 08:05:59 -0700 (PDT) Received: from ext-bt.isode.com ([217.34.220.158]:1846 helo=statler.isode.com) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YfrYA-00031a-G4 for draft-ietf-idr-flowspec-redirect-rt-bis.all@tools.ietf.org; Wed, 08 Apr 2015 08:05:59 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1428503708; d=isode.com; s=selector; i=@isode.com; bh=ahnQDUMBVgS/lPu/b2JNoigQzobAnhokDY5AIpNlZ+A=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=IqNmO7J8ThO8PxoUCMJGj8Yt13ASzNhUhcmBtw8uLme1H+1DKfJUf5i4VvQ01CJF4Xsszz C16ycWS8+/30/yQ5goFWIfYkueIxuE2E7leS+GuEZ0NRveuvBsUjnloPgmxMYffZuNI2Sm PKbabv7PdFq1fD74uQdTQUEaOCjuBBs=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 8 Apr 2015 15:35:08 +0100 Message-ID: <55253C8D.5070305@isode.com> Date: Wed, 08 Apr 2015 15:34:53 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 To: secdir@ietf.org, draft-ietf-idr-flowspec-redirect-rt-bis.all@tools.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Helo-Check-Failed: Verification failed for HELO statler.isode.com X-SA-Exim-Connect-IP: 217.34.220.158 X-SA-Exim-Rcpt-To: draft-ietf-idr-flowspec-redirect-rt-bis.all@tools.ietf.org X-SA-Exim-Mail-From: alexey.melnikov@isode.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-idr-flowspec-redirect-rt-bis.all@ietf.org Resent-Message-Id: <20150408150559.7110B1B3206@ietfa.amsl.com> Resent-Date: Wed, 8 Apr 2015 08:05:59 -0700 (PDT) Resent-From: alexey.melnikov@isode.com Archived-At: Archived-At: X-Mailman-Approved-At: Wed, 08 Apr 2015 08:11:41 -0700 Subject: [Idr] SecDir review of draft-ietf-idr-flowspec-redirect-rt-bis-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: Wed, 08 Apr 2015 15:06:14 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document clarifies the formatting of the the BGP Flowspec Redirect Extended Community, originally documented in RFC 5575 (Dissemination of Flow Specification Rules). This document is a straightforward clarification to RFC 5575. Documenting existing practice will improve security of implementations. Pointing to the Security Considerations of RFC 5575 is appropriate for this document. I believe that this ID is ready for publication. From nobody Wed Apr 8 14:35:54 2015 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 061F01B36E0; Wed, 8 Apr 2015 14:35:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.155 X-Spam-Level: X-Spam-Status: No, score=-97.155 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 0s_qd_aIpQZr; Wed, 8 Apr 2015 14:35:51 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id C78A61B36DD; Wed, 8 Apr 2015 14:35:50 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=74.43.47.142; From: "Susan Hares" To: Date: Wed, 8 Apr 2015 17:35:48 -0400 Message-ID: <016b01d07243$fb1cd350$f15679f0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_016C_01D07222.740D0810" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdByQ2VhWuYrmNzuQqmqf9ih+sDPtA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: idr wg Subject: [Idr] BGP yang modules 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, 08 Apr 2015 21:35:52 -0000 This is a multipart message in MIME format. ------=_NextPart_000_016C_01D07222.740D0810 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thomas and Martin requested information the status of the base BGP draft. The BGP base yang modules are: draft-shaikh-idr-bgp-model-01 (OpenConfig Draft) draft-zhdankin-idr-bgp-cfg-00 (Cisco and other vendors draft) The authors of these two models are working on collaborating toward a merge in April. The April 27 IDR interim will provide this final merge. These drafts are linked to the policy discussions in the rtgwg for the following drafts: draft-shaikh-rtgwg-policy-model-00 (openConfig draft) draft-yan-rtgwg-routing-policy-yang-00 (other policy draft) Sue ------=_NextPart_000_016C_01D07222.740D0810 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thomas and = Martin requested information the status of the base BGP draft. The BGP = base yang modules are:

 

draft-shaikh-idr-bgp-model-01 (OpenConfig Draft) =

draft-zhdankin-idr-bgp-cfg-00  (Cisco and other = vendors draft)

 

The authors = of these two models are working on collaborating toward a merge in = April.  The April 27 IDR interim will provide this final merge. =

 

These drafts are linked to the policy discussions in = the rtgwg for the following drafts:

 

draft-shaikh-rtgwg-policy-model-00  (openConfig = draft)

draft-yan-rtgwg-routing-policy-yang-00 (other policy = draft)

 

Sue  

------=_NextPart_000_016C_01D07222.740D0810-- From nobody Thu Apr 9 07:02:24 2015 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 1FD141A1B0B; Thu, 9 Apr 2015 07:02: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 g2kUAa32SH8U; Thu, 9 Apr 2015 07:02:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 175EF1A1B86; Thu, 9 Apr 2015 07:02:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150409140218.22830.31521.idtracker@ietfa.amsl.com> Date: Thu, 09 Apr 2015 07:02:18 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-as-migration-04.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: Thu, 09 Apr 2015 14:02:22 -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 Mechanisms and Their Effects on the BGP AS_PATH Attribute Authors : Wesley George Shane Amante Filename : draft-ietf-idr-as-migration-04.txt Pages : 16 Date : 2015-04-09 Abstract: This draft discusses some commonly-used BGP mechanisms for ASN migration that 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. 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-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-as-migration-04 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 Thu Apr 9 07:02:27 2015 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 28F021A1B51; Thu, 9 Apr 2015 07:02:23 -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 48rZs7Ml_fJj; Thu, 9 Apr 2015 07:02:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A38B1A1B92; Thu, 9 Apr 2015 07:02:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150409140218.22830.39086.idtracker@ietfa.amsl.com> Date: Thu, 09 Apr 2015 07:02:18 -0700 Archived-At: Subject: [Idr] New Version Notification - draft-ietf-idr-as-migration-04.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: Thu, 09 Apr 2015 14:02:23 -0000 A new version (-04) has been submitted for draft-ietf-idr-as-migration: http://www.ietf.org/internet-drafts/draft-ietf-idr-as-migration-04.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-as-migration/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-as-migration-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Thu Apr 9 07:13:22 2015 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 5141E1A1B8D for ; Thu, 9 Apr 2015 07:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.475 X-Spam-Level: X-Spam-Status: No, score=-0.475 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 HysOCVir6tG5 for ; Thu, 9 Apr 2015 07:13:19 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 2B38A1A1DE2 for ; Thu, 9 Apr 2015 07:13:15 -0700 (PDT) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.11,550,1422939600"; d="scan'208";a="851801723" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 09 Apr 2015 09:58:51 -0400 Received: from PRVPEXVS10.corp.twcable.com ([10.136.163.40]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Thu, 9 Apr 2015 10:13:14 -0400 From: "George, Wes" To: "idr@ietf.org" , "Alvaro Retana (aretana)" , Alia Atlas , Susan Hares Date: Thu, 9 Apr 2015 10:13:18 -0400 Thread-Topic: [Idr] I-D Action: draft-ietf-idr-as-migration-04.txt Thread-Index: AdByz1Gv6sWygJdjT76TInh4qVQRLA== Message-ID: References: <20150409140218.22830.31521.idtracker@ietfa.amsl.com> In-Reply-To: <20150409140218.22830.31521.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.8.150116 acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-as-migration-04.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: Thu, 09 Apr 2015 14:13:21 -0000 U2hhbmUgYW5kIEkgYmVsaWV2ZSB0aGF0IHRoaXMgcmV2aXNpb24gYWRkcmVzc2VzIHRoZSBtYWpv cml0eSBvZiBjb25jZXJucw0KcmFpc2VkIGR1cmluZyBJRVNHIGV2YWx1YXRpb24sIGluY2x1ZGlu ZyBBbHZhcm8ncyByZXZpZXcuDQoNCkkgZG9uJ3Qga25vdyBpZiB0aGlzIGhhcyB0byBnbyBiYWNr IHRocm91Z2ggV0dMQyBvciBpZiBpdCBjYW4ganVzdCBiZSBwdXQNCmJhY2sgb24gSUVTRyBzY2hl ZHVsZSwgYXMgYSBnb29kIGJpdCBvZiB0aGUgdGV4dCB3YXMgY2hhbmdlZCB0byBhZGRyZXNzDQp0 aGUgY29uY2VybnMgYWJvdXQgdGhpcyBiZWluZyB0b28gdmVuZG9yLXNwZWNpZmljLCBpbmNsdWRp bmcgc29tZSBvZiB0aGUNCm5vcm1hdGl2ZSBsYW5ndWFnZSwgc28gSSdsbCBsZWF2ZSB0aGF0IHRv IHRoZSBjaGFpcnMgYW5kIEFEcyB0byBkZWNpZGUuDQoNClRoYW5rcywNCg0KV2VzDQoNCg0KDQpP biA0LzkvMTUsIDEwOjAyIEFNLCAiaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIiA8aW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnPg0Kd3JvdGU6DQoNCj4NCj5BIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBh dmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMNCj5kaXJlY3Rvcmllcy4N Cj4gVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgSW50ZXItRG9tYWluIFJvdXRpbmcg V29ya2luZyBHcm91cCBvZg0KPnRoZSBJRVRGLg0KPg0KPiAgICAgICAgVGl0bGUgICAgICAgICAg IDogQXV0b25vbW91cyBTeXN0ZW0gTWlncmF0aW9uIE1lY2hhbmlzbXMgYW5kDQo+VGhlaXIgRWZm ZWN0cyBvbiB0aGUgQkdQIEFTX1BBVEggQXR0cmlidXRlDQo+ICAgICAgICBBdXRob3JzICAgICAg ICAgOiBXZXNsZXkgR2VvcmdlDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICBTaGFuZSBBbWFu dGUNCj4gICAgICAgRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1pZHItYXMtbWlncmF0aW9u LTA0LnR4dA0KPiAgICAgICBQYWdlcyAgICAgICAgICAgOiAxNg0KPiAgICAgICBEYXRlICAgICAg ICAgICAgOiAyMDE1LTA0LTA5DQo+DQo+QWJzdHJhY3Q6DQo+ICAgVGhpcyBkcmFmdCBkaXNjdXNz ZXMgc29tZSBjb21tb25seS11c2VkIEJHUCBtZWNoYW5pc21zIGZvciBBU04NCj4gICBtaWdyYXRp b24gdGhhdCBhcmUgbm90IGZvcm1hbGx5IHBhcnQgb2YgdGhlIEJHUDQgcHJvdG9jb2wNCj4gICBz cGVjaWZpY2F0aW9uIGFuZCBtYXkgYmUgdmVuZG9yLXNwZWNpZmljIGluIGV4YWN0IGltcGxlbWVu dGF0aW9uLiAgSXQNCj4gICBpcyBuZWNlc3NhcnkgdG8gZG9jdW1lbnQgdGhlc2UgZGUgZmFjdG8g c3RhbmRhcmRzIHRvIGVuc3VyZSB0aGF0IHRoZXkNCj4gICBhcmUgcHJvcGVybHkgc3VwcG9ydGVk IGluIGZ1dHVyZSBCR1AgcHJvdG9jb2wgd29yay4NCj4NCj4NCj5UaGUgSUVURiBkYXRhdHJhY2tl ciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCj5odHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1pZXRmLWlkci1hcy1taWdyYXRpb24vDQo+DQo+VGhlcmUncyBhbHNv IGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6DQo+aHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi1pZHItYXMtbWlncmF0aW9uLTA0DQo+DQo+QSBkaWZmIGZyb20gdGhl IHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KPmh0dHA6Ly93d3cuaWV0Zi5vcmcv cmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtaWRyLWFzLW1pZ3JhdGlvbi0wNA0KPg0KPg0KPlBsZWFz ZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1l IG9mDQo+c3VibWlzc2lvbg0KPnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFy ZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+DQo+SW50ZXJuZXQtRHJhZnRzIGFyZSBh bHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPmZ0cDovL2Z0cC5pZXRmLm9yZy9p bnRlcm5ldC1kcmFmdHMvDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj5JZHIgbWFpbGluZyBsaXN0DQo+SWRyQGlldGYub3JnDQo+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZHINCg0KDQpUaGlzIEUtbWFpbCBhbmQgYW55 IG9mIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBUaW1lIFdhcm5lciBDYWJsZSBwcm9wcmll dGFyeSBpbmZvcm1hdGlvbiwgd2hpY2ggaXMgcHJpdmlsZWdlZCwgY29uZmlkZW50aWFsLCBvciBz dWJqZWN0IHRvIGNvcHlyaWdodCBiZWxvbmdpbmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMg RS1tYWlsIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBv ciBlbnRpdHkgdG8gd2hpY2ggaXQgaXMgYWRkcmVzc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50 ZW5kZWQgcmVjaXBpZW50IG9mIHRoaXMgRS1tYWlsLCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0 aGF0IGFueSBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIGNvcHlpbmcsIG9yIGFjdGlvbiB0 YWtlbiBpbiByZWxhdGlvbiB0byB0aGUgY29udGVudHMgb2YgYW5kIGF0dGFjaG1lbnRzIHRvIHRo aXMgRS1tYWlsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYg eW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBFLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhl IHNlbmRlciBpbW1lZGlhdGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRoZSBvcmlnaW5hbCBh bmQgYW55IGNvcHkgb2YgdGhpcyBFLW1haWwgYW5kIGFueSBwcmludG91dC4NCg== From nobody Thu Apr 9 08:06:23 2015 Return-Path: X-Original-To: expand-draft-ietf-idr-ls-distribution.all@virtual.ietf.org Delivered-To: idr@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 5E7181A9067; Wed, 8 Apr 2015 15:19:54 -0700 (PDT) X-Original-To: xfilter-draft-ietf-idr-ls-distribution.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-idr-ls-distribution.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA651A9066 for ; Wed, 8 Apr 2015 15:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.2 X-Spam-Level: X-Spam-Status: No, score=-9.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, USER_IN_DEF_DKIM_WL=-7.5] 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 2bDXX22Edouj for ; Wed, 8 Apr 2015 15:19:51 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1013D1A9057 for ; Wed, 8 Apr 2015 15:19:51 -0700 (PDT) Received: from rcdn-iport-4.cisco.com ([173.37.86.75]:7068) by zinfandel.tools.ietf.org with esmtps (TLS1.0:RSA_ARCFOUR_128_SHA1:128) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YfyK5-0004Rb-2u for draft-ietf-idr-ls-distribution.all@tools.ietf.org; Wed, 08 Apr 2015 15:19:50 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2278; q=dns/txt; s=iport; t=1428531589; x=1429741189; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=ju7P58caE8AddNNhGQZ1b6EdvcZIpnPzOspTGWvp9O4=; b=EY0p6ysKhrWtF8ZbIYepXTk5P34N6+z59d+2WZtpVsQgqZZGEjpQ63hj Nj+25aleah+EVgb1a/WeFHwahNfPFRTOlp0mSVOglHt5ERdqnSTIPhNcA adWDaJe8n8FUBANY2xRsiPiPcnJ2CX1/hXIaWm+vbXtavOZb+lGd3Jtnf 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A7BQCsqCVV/4cNJK1cgwhSXAWDEMIqhzNMAQEBAQEBfoRJDwF7AgUhAhECNhYBDAYCAQGIJrZWllkBAQEBAQUBAQEBAQEYBIEhkXWBRQWLJ4lFhg+BHYM3gkKJe4NKIoICHYFvUIFEfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,546,1422921600"; d="scan'208";a="410365429" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-4.cisco.com with ESMTP; 08 Apr 2015 22:19:42 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t38MJgMM003821 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 Apr 2015 22:19:42 GMT Received: from [64.101.72.33] (64.101.72.33) by xhc-aln-x02.cisco.com (173.36.12.76) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 8 Apr 2015 17:19:41 -0500 Message-ID: <5525A97D.70607@cisco.com> Date: Wed, 8 Apr 2015 16:19:41 -0600 From: =?UTF-8?B?4oyYIE1hdHQgTWlsbGVy?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: The IESG , IETF Security Directorate , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [64.101.72.33] X-SA-Exim-Connect-IP: 173.37.86.75 X-SA-Exim-Rcpt-To: draft-ietf-idr-ls-distribution.all@tools.ietf.org X-SA-Exim-Mail-From: mamille2@cisco.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-idr-ls-distribution.all@ietf.org Resent-Message-Id: <20150408221951.1013D1A9057@ietfa.amsl.com> Resent-Date: Wed, 8 Apr 2015 15:19:51 -0700 (PDT) Resent-From: mamille2@cisco.com Archived-At: Archived-At: X-Mailman-Approved-At: Thu, 09 Apr 2015 08:06:20 -0700 Subject: [Idr] secdir review of draft-ietf-idr-ls-distribution 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, 08 Apr 2015 22:19:54 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments that had arrived in a more timely manner. I think the document is ready, but I have a couple of nits. Please note that I am not well versed in the subject of network routing, so these nits might be irrelevant due to my naivete. * Section 6.2.6. is written in terms of what an operator ought to do, but I'm not entirely sure what that means to an implementer. Does that mean the implementer MUST provide some sort of mechanism to allow the operator do follow the SHOULD? I admittedly only glanced through RFC 5706 and RFC 4271, so if this is actually covered more generally then please ignore this item. * In Section 8., second paragraph, are there known cases where it might be ok to accept Consumer peer updates, therefore violating the SHOULD NOT? If there are not, I would think MUST NOT is more appropriate. If there are cases where the SHOULD NOT can be ignored, does it makes sense to briefly describe one or two of them? While there are several places in this document where SHOULD (or SHOULD NOT) is used without any such exceptions described, it seems pertinent to me to describe a case or two for such a SHOULD (NOT) in the Security Considerations. Thank you for your consideration, - -- - - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVJal9AAoJEDWi+S0W7cO1Dc8H/j9UqCwTn+VecPTnd2b5UQ2W mhFM5SGMc+KRpBjriTmxs/snwoLFtuD+u5aGuEEp+mvebR8C2Tg2wDga4TE1R5cu fs+kmmvzgGkoKtQGcg3MfnAp5F+MEKGRh9iLUt6bBzSEZqMjDvchx+Ha9z+Raxs4 W2Paw6UUr6+RIsKgeioRKYjk+hMQHabtSrb9rdJEjSLgcMcOgXPeLwMz/wlq/pVZ j5qPVSYTnOcfDEhRle6K99HZ/MZucGwxAv0fe8ukc0X5Ate9P0HrA3pW2oNyAVSX 4MdTvkxcIHucbeiWKpWMy8LpK+9e9CeVKBmvEitixnvOjqLq3qmS0SBu5O7P+qI= =8yaG -----END PGP SIGNATURE----- From nobody Thu Apr 9 09:44:00 2015 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 872311B2E91 for ; Thu, 9 Apr 2015 09:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.055 X-Spam-Level: X-Spam-Status: No, score=-99.055 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, USER_IN_WHITELIST=-100] 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 ltecC8bLivtH for ; Thu, 9 Apr 2015 09:43:56 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 438CC1B2ED6 for ; Thu, 9 Apr 2015 09:43:34 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.142; From: "Susan Hares" To: "'George, Wes'" , , "'Alvaro Retana \(aretana\)'" , "'Alia Atlas'" References: <20150409140218.22830.31521.idtracker@ietfa.amsl.com> In-Reply-To: Date: Thu, 9 Apr 2015 12:43:29 -0400 Message-ID: <02e401d072e4$4f5a1cc0$ee0e5640$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF4r1Z2HL4YFm8OUbIc3fl4NvJEkQMc7jnKnduBwMA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-as-migration-04.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: Thu, 09 Apr 2015 16:43:57 -0000 George:=20 Let me review the document and query Alvaro to make sure it addresses = his concerns. =20 On re-doing WG LC, we can do this in parallel with the other reviews = I'll need to redo (security directorate, routing directorate, = ops-directorate and gen-art). I'll start both sequences at the same time = once I've heard from Alvaro. =20 Sue=20 -----Original Message----- From: George, Wes [mailto:wesley.george@twcable.com]=20 Sent: Thursday, April 09, 2015 10:13 AM To: idr@ietf.org; Alvaro Retana (aretana); Alia Atlas; Susan Hares Cc: Adrian Farrel Subject: Re: [Idr] I-D Action: draft-ietf-idr-as-migration-04.txt Shane and I believe that this revision addresses the majority of = concerns raised during IESG evaluation, including Alvaro's review. I don't know if this has to go back through WGLC or if it can just be = put back on IESG schedule, as a good bit of the text was changed to = address the concerns about this being too vendor-specific, including = some of the normative language, so I'll leave that to the chairs and ADs = to decide. Thanks, Wes On 4/9/15, 10:02 AM, "internet-drafts@ietf.org" = wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts=20 >directories. > This draft is a work item of the Inter-Domain Routing Working Group of = >the IETF. > > Title : Autonomous System Migration Mechanisms and >Their Effects on the BGP AS_PATH Attribute > Authors : Wesley George > Shane Amante > Filename : draft-ietf-idr-as-migration-04.txt > Pages : 16 > Date : 2015-04-09 > >Abstract: > This draft discusses some commonly-used BGP mechanisms for ASN > migration that 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. > > >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-04 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-as-migration-04 > > >Please note that it may take a couple of minutes from the time of=20 >submission until the htmlized version and diff are available at=20 >tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr This E-mail and any of its attachments may contain Time Warner Cable = proprietary information, which is privileged, confidential, or subject = to copyright belonging to Time Warner Cable. This E-mail is intended = solely for the use of the individual or entity to which it is addressed. = If you are not the intended recipient of this E-mail, you are hereby = notified that any dissemination, distribution, copying, or action taken = in relation to the contents of and attachments to this E-mail is = strictly prohibited and may be unlawful. If you have received this = E-mail in error, please notify the sender immediately and permanently = delete the original and any copy of this E-mail and any printout. From nobody Thu Apr 9 10:48:43 2015 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 D400B1B300F for ; Thu, 9 Apr 2015 10:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-Xv3cPypsyg for ; Thu, 9 Apr 2015 10:48:40 -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 B24901B3002 for ; Thu, 9 Apr 2015 10:48:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=516; q=dns/txt; s=iport; t=1428601704; x=1429811304; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=hgqM+MXho5DTD6GOC9V/w3T52g6sM0BlpdQeqh492WU=; b=ftZsEVpzpqFeBW7Eks7aP2uqdkE/f8oUwVR5z2bBxx4ziMPEm/+BbpD9 JMFey7S1YdIA/37yZ2iKH8atIKLVz1miESJuawo6zJecUPWzf1w9uanKE Ijw3XZ/Jtw4npMgl2awx9hEGiVBTuvrH1kcYK0BM21MOLqYWgue1PoSlH 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AJBQDFuiZV/4MNJK1cgwiBLgXMGwKBREwBAQEBAQF+hCABAQR5EAIBCA44MiUCBA4FiCrOTgEBAQEBAQEBAQEBAQEBAQEBAQEZiyuEfAeELQEEinaDcYITiguBHYYfjSkig29vgUR/AQEB X-IronPort-AV: E=Sophos;i="5.11,551,1422921600"; d="scan'208";a="407426511" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-1.cisco.com with ESMTP; 09 Apr 2015 17:48:24 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t39HmNA0016068 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 Apr 2015 17:48:23 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.109]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Thu, 9 Apr 2015 12:48:23 -0500 From: "Alvaro Retana (aretana)" To: Susan Hares , "'George, Wes'" Thread-Topic: [Idr] I-D Action: draft-ietf-idr-as-migration-04.txt Thread-Index: AQHQcs3TvbL27GkH30+YWmJNQ75P+51FDN0AgAAp9oD//88KgA== Date: Thu, 9 Apr 2015 17:48:23 +0000 Message-ID: References: <20150409140218.22830.31521.idtracker@ietfa.amsl.com> <02e401d072e4$4f5a1cc0$ee0e5640$@ndzh.com> In-Reply-To: <02e401d072e4$4f5a1cc0$ee0e5640$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.15.13] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] I-D Action: draft-ietf-idr-as-migration-04.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: Thu, 09 Apr 2015 17:48:42 -0000 On 4/9/15, 12:43 PM, "Susan Hares" wrote: >Let me review the document and query Alvaro to make sure it addresses his >concerns. =20 > >On re-doing WG LC, we can do this in parallel with the other reviews I'll >need to redo (security directorate, routing directorate, ops-directorate >and gen-art). I'll start both sequences at the same time once I've heard >from Alvaro. =20 I=B9ll go read it, but my gut reaction is that we should go back through (WGLC, etc.). Thanks! Alvaro. From nobody Fri Apr 10 06:45:40 2015 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 3A39C1B35A1 for ; Fri, 10 Apr 2015 06:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.155 X-Spam-Level: X-Spam-Status: No, score=-97.155 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 CIN1UHQqbJZ4 for ; Fri, 10 Apr 2015 06:45:36 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id C306A1ACD9D for ; Fri, 10 Apr 2015 06:45:35 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.142; From: "Susan Hares" To: "idr wg" Date: Fri, 10 Apr 2015 09:45:28 -0400 Message-ID: <003f01d07394$9b5f1c00$d21d5400$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0040_01D07373.14528510" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdBzlDcUkdJmp22uTqShwxbVd0A/Mg== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: amante@apple.com Subject: [Idr] 2 Week WG LC on draft-ietf-idr-as-migration (4/9 to 4/23/2105 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, 10 Apr 2015 13:45:38 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0040_01D07373.14528510 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This is a 2 week WG LC on draft-ietf-as-migration. As discussed in the IETF 92 session, the feedback on this draft ask for a few changes in format and generalization of implementation terms. The authors and shepherd believe this has been accomplish with draft-ietf-as-migration-04.txt. This WG LC is to determine if these revisions are acceptable to the IDR WG. You can see the latest document at: http://datatracker.ietf.org/doc/draft-ietf-idr-as-migration/ Please indicate in your response "support for this version" or "no support". Sue Hares and John Scudder ------=_NextPart_000_0040_01D07373.14528510 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is a = 2 week WG LC on draft-ietf-as-migration.  As discussed in the IETF = 92 session, the feedback on this draft ask for a few changes in format = and generalization of implementation terms.  The authors and = shepherd believe this has been accomplish with = draft-ietf-as-migration-04.txt.   This WG LC is to determine = if these revisions are acceptable to the IDR WG.

 

You can see = the latest document at:

 

htt= p://datatracker.ietf.org/doc/draft-ietf-idr-as-migration/<= /p>

 

Please = indicate in your response “support for this version” or = “no support”.

 

Sue Hares = and John Scudder

------=_NextPart_000_0040_01D07373.14528510-- From nobody Fri Apr 10 07:07:25 2015 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 BF3121B367D for ; Fri, 10 Apr 2015 07:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cv48DBLjiXLn for ; Fri, 10 Apr 2015 07:07:23 -0700 (PDT) Received: from server.riw.us (server.riw.us [162.144.32.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B9BE1B367C for ; Fri, 10 Apr 2015 07:07:23 -0700 (PDT) Received: from 162-229-180-77.lightspeed.rlghnc.sbcglobal.net ([162.229.180.77]:64613 helo=RussPC) by server.riw.us with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.85) (envelope-from ) id 1YgZac-0000Ao-4E for idr@ietf.org; Fri, 10 Apr 2015 14:07:22 +0000 From: "Russ White" To: "'idr wg'" Date: Fri, 10 Apr 2015 10:07:16 -0400 Message-ID: <02a201d07397$a737eae0$f5a7c0a0$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdBzl43Ss1pfx/rWRBSBQpmkBPVfow== Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.riw.us X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Get-Message-Sender-Via: server.riw.us: authenticated_id: russw@riw.us X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: [Idr] Shepherd Writeup for draft-ietf-idr-add-paths-10 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, 10 Apr 2015 14:07:25 -0000 Y'all -- Below is the shepherds writeup for this draft. Comments welcome. Russ == 1. Summary The document shepherd is Russ White. The responsible Area Director is Alvaro Retana. This document extends BGP so a BGP speaker can advertise multiple paths rather than a single best path to peers. It proposes a new NLRI encoding extension to carry a Path Identifier, and a new capability to negotiate the carrying of additional paths. These additional paths are intended to used to eliminate path oscillation, in a number of situations where advertising multiple paths can improve network convergence, and in a number of situations where BGP is used in "high fan out" equal cost multipath network topologies to provide optimal path availability. 2. Review and Consensus The extension to BGP is straightforward; while there has been some difficulty in coming to consensus on the benefits provided versus the difficulty in implementing the extensions, the value of the concept has been proven in deployment scenarios and use cases enough to justify moving forward with this document. The document has passed through ten revisions over a number of years, and has been discussed both on and off the relevant lists by a number of experts in the development and deployment of BGP. The working group has reached concensus on moving this document forward at this point. 3. Intellectual Property Each author has confirmed conformance with BCP 78/79. There are no IPR disclosures on the document. 4. Other Points There are no normative downrefs in this document. There are minimal additions to the YANG model based on the extensions described in this draft; as those models are not yet standardized, it is expected that these will be included in these models as they are standardized. Changes to the IANA registries required for the new options described in the draft have already been properly assigned and recorded. From nobody Fri Apr 10 07:20:22 2015 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 E4EF01B36B5 for ; Fri, 10 Apr 2015 07:20:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eApA8OgkoU7U for ; Fri, 10 Apr 2015 07:20:19 -0700 (PDT) Received: from server.riw.us (server.riw.us [162.144.32.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BC3A1B36B2 for ; Fri, 10 Apr 2015 07:20:19 -0700 (PDT) Received: from 162-229-180-77.lightspeed.rlghnc.sbcglobal.net ([162.229.180.77]:53183 helo=RussPC) by server.riw.us with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.85) (envelope-from ) id 1YgZn5-0000Ip-LG for idr@ietf.org; Fri, 10 Apr 2015 14:20:15 +0000 From: "Russ White" To: "'idr wg'" Date: Fri, 10 Apr 2015 10:20:10 -0400 Message-ID: <02b901d07399$74460200$5cd20600$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQGFJA1PMYtbQ8iGnY6rpqAm20Jpjw== Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.riw.us X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Get-Message-Sender-Via: server.riw.us: authenticated_id: russw@riw.us X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: [Idr] Shepherds Writeup for draft-ietf-idr-add-paths-implementation-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: Fri, 10 Apr 2015 14:20:21 -0000 Y'all -- Shepherds writeup for draft-ietf-idr-add-paths-implementation-00 below. Russ == 1. Summary The document shepherd is Russ White. The responsible Area Director is Alvaro Retana. This document documents the current implementation state for a set of extensions to BGP so a BGP speaker can advertise multiple paths rather than a single best path to peers. These additional paths are intended to used to eliminate path oscillation, in a number of situations where advertising multiple paths can improve network convergence, and in a number of situations where BGP is used in "high fan out" equal cost multipath network topologies to provide optimal path availability. 2. Review and Consensus There has been no controversy over this document, which simply indicates how many implementations of these extensions there are, and which specific capabilities have been included in those implementations. The document shows widespread implementation of the features described. The working group has reached concensus on moving this document forward. 3. Intellectual Property Each author has confirmed conformance with BCP 78/79. There are no IPR disclosures on the document. 4. Other Points There are no normative downrefs in this document. There are no additions to the YANG model based on the extensions described in this draft. There are no changes to any IANA registry as a result of this draft. From nobody Fri Apr 10 07:49:27 2015 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 D3D5F1A03F9 for ; Fri, 10 Apr 2015 07:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kPz-93Yj22WN for ; Fri, 10 Apr 2015 07:49:25 -0700 (PDT) Received: from server.riw.us (server.riw.us [162.144.32.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92D641A036A for ; Fri, 10 Apr 2015 07:49:25 -0700 (PDT) Received: from 162-229-180-77.lightspeed.rlghnc.sbcglobal.net ([162.229.180.77]:50358 helo=RussPC) by server.riw.us with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.85) (envelope-from ) id 1YgaFH-0000ZF-TK; Fri, 10 Apr 2015 14:49:24 +0000 From: "Russ White" To: "'Susan Hares'" , "'idr wg'" References: <003f01d07394$9b5f1c00$d21d5400$@ndzh.com> In-Reply-To: <003f01d07394$9b5f1c00$d21d5400$@ndzh.com> Date: Fri, 10 Apr 2015 10:49:18 -0400 Message-ID: <003001d0739d$8674ddd0$935e9970$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIvj5RIJ2CxkbZYbaeZtvrbxnWMvpyIG9xg Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.riw.us X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Get-Message-Sender-Via: server.riw.us: authenticated_id: russw@riw.us X-Source: X-Source-Args: X-Source-Dir: Archived-At: Cc: amante@apple.com Subject: Re: [Idr] 2 Week WG LC on draft-ietf-idr-as-migration (4/9 to 4/23/2105 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, 10 Apr 2015 14:49:27 -0000 Support. Russ > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares > Sent: Friday, April 10, 2015 9:45 AM > To: idr wg > Cc: amante@apple.com > Subject: [Idr] 2 Week WG LC on draft-ietf-idr-as-migration (4/9 to 4/23/2105 > > This is a 2 week WG LC on draft-ietf-as-migration. As discussed in the IETF 92 > session, the feedback on this draft ask for a few changes in format and > generalization of implementation terms. The authors and shepherd believe > this has been accomplish with > draft-ietf-as-migration-04.txt. This WG LC is to determine if these > revisions are acceptable to the IDR WG. > > > > You can see the latest document at: > > > > http://datatracker.ietf.org/doc/draft-ietf-idr-as-migration/ > > > > Please indicate in your response "support for this version" or "no support". > > > > Sue Hares and John Scudder From nobody Fri Apr 10 13:47:58 2015 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 2EE321A8930; Fri, 10 Apr 2015 13:47:57 -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 BDDTY0xLY-T4; Fri, 10 Apr 2015 13:47:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E5AE1A892E; Fri, 10 Apr 2015 13:47:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , X-Test-IDTracker: no X-IETF-IDTracker: 5.13.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150410204755.1314.46308.idtracker@ietfa.amsl.com> Date: Fri, 10 Apr 2015 13:47:55 -0700 From: IETF Secretariat Archived-At: Subject: [Idr] ID Tracker State Update Notice: 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, 10 Apr 2015 20:47:57 -0000 IESG state changed to AD is watching from Waiting for AD Go-Ahead ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-idr-as-migration/ From nobody Sat Apr 11 05:56:15 2015 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 C4ACE1B2A6E; Sat, 11 Apr 2015 05:56:13 -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 qwLnPZtHEKPp; Sat, 11 Apr 2015 05:56:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D1E3A1B2A84; Sat, 11 Apr 2015 05:56:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.13.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150411125610.29353.16150.idtracker@ietfa.amsl.com> Date: Sat, 11 Apr 2015 05:56:10 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-flowspec-redirect-rt-bis-04.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: Sat, 11 Apr 2015 12:56:14 -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 : Clarification of the Flowspec Redirect Extended Community Author : Jeffrey Haas Filename : draft-ietf-idr-flowspec-redirect-rt-bis-04.txt Pages : 7 Date : 2015-04-11 Abstract: This document updates RFC 5575 (Dissemination of Flow Specification Rules) to clarify the formatting of the the BGP Flowspec Redirect Extended Community. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-redirect-rt-bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-flowspec-redirect-rt-bis-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-flowspec-redirect-rt-bis-04 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 Sat Apr 11 05:56:22 2015 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 C6FAE1B2A8A; Sat, 11 Apr 2015 05:56:15 -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 89SMBvVt5gOT; Sat, 11 Apr 2015 05:56:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E72231B2A86; Sat, 11 Apr 2015 05:56:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.13.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150411125610.29353.31191.idtracker@ietfa.amsl.com> Date: Sat, 11 Apr 2015 05:56:10 -0700 Archived-At: Subject: [Idr] New Version Notification - draft-ietf-idr-flowspec-redirect-rt-bis-04.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: Sat, 11 Apr 2015 12:56:15 -0000 A new version (-04) has been submitted for draft-ietf-idr-flowspec-redirect-rt-bis: http://www.ietf.org/internet-drafts/draft-ietf-idr-flowspec-redirect-rt-bis-04.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-redirect-rt-bis/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-flowspec-redirect-rt-bis-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Sat Apr 11 06:00:35 2015 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 6C4C41B2ABB; Sat, 11 Apr 2015 06:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 OCkvGmZ0aLO0; Sat, 11 Apr 2015 06:00:30 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 2E4921B2ABD; Sat, 11 Apr 2015 06:00:30 -0700 (PDT) Received: from [192.168.1.85] (99-59-192-241.lightspeed.livnmi.sbcglobal.net [99.59.192.241]) by slice.pfrc.org (Postfix) with ESMTPSA id C7771C140; Sat, 11 Apr 2015 09:00:29 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Jeffrey Haas In-Reply-To: <20150411125610.29353.16150.idtracker@ietfa.amsl.com> Date: Sat, 11 Apr 2015 09:00:28 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <71F77327-B704-4242-ADB7-FCAD3CAF9A09@pfrc.org> References: <20150411125610.29353.16150.idtracker@ietfa.amsl.com> To: idr@ietf.org, ietf@ietf.org X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-flowspec-redirect-rt-bis-04.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: Sat, 11 Apr 2015 13:00:31 -0000 IDR Working Group and IETF main mailing list, The following update incorporates changes from directorate reviews and = requests from IANA for clarification for the two new registries = incidentally created to support this work. I have chosen to utilize the = same allocation policy as the existing experimental extended community = registry. =20 Since no allocation policy was previously documented in the earlier = versions of this draft during its last call, the IDR chairs will be = issuing another last call including these changes. This gives the IETF = community appropriate time to comment on the documented policy. -- Jeff > On Apr 11, 2015, at 8:56 AM, internet-drafts@ietf.org wrote: >=20 >=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 : Clarification of the Flowspec Redirect = Extended Community > Author : Jeffrey Haas > Filename : draft-ietf-idr-flowspec-redirect-rt-bis-04.txt > Pages : 7 > Date : 2015-04-11 >=20 > Abstract: > This document updates RFC 5575 (Dissemination of Flow Specification > Rules) to clarify the formatting of the the BGP Flowspec Redirect > Extended Community. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-redirect-rt-bis/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-idr-flowspec-redirect-rt-bis-04 >=20 > A diff from the previous version is available at: > = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-flowspec-redirect-rt-bis= -04 >=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/ >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Sat Apr 11 09:57:47 2015 Return-Path: X-Original-To: expand-draft-ietf-idr-flowspec-redirect-rt-bis.all@virtual.ietf.org Delivered-To: idr@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 395381B2F28; Fri, 10 Apr 2015 18:46:46 -0700 (PDT) X-Original-To: xfilter-draft-ietf-idr-flowspec-redirect-rt-bis.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-idr-flowspec-redirect-rt-bis.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2F51B2F27 for ; Fri, 10 Apr 2015 18:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] 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 sUqq2Zrw8X3d for ; Fri, 10 Apr 2015 18:46:44 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97EBB1B2F25 for ; Fri, 10 Apr 2015 18:46:44 -0700 (PDT) Received: from mail-by2on0103.outbound.protection.outlook.com ([207.46.100.103]:51616 helo=na01-by2-obe.outbound.protection.outlook.com) by zinfandel.tools.ietf.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YgkVQ-0003Yr-1l for draft-ietf-idr-flowspec-redirect-rt-bis.all@tools.ietf.org; Fri, 10 Apr 2015 18:46:44 -0700 Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none; Received: from dmcginniss-sslvpn-nc.jnpr.net (66.129.241.13) by BL2PR05MB145.namprd05.prod.outlook.com (10.242.198.17) with Microsoft SMTP Server (TLS) id 15.1.136.25; Fri, 10 Apr 2015 20:09:40 +0000 MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset="us-ascii" From: Jeff Haas In-Reply-To: <550CF725.1060501@gmail.com> Date: Fri, 10 Apr 2015 16:09:32 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <550CF725.1060501@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [66.129.241.13] X-ClientProxiedBy: BY2PR03CA053.namprd03.prod.outlook.com (10.141.249.26) To BL2PR05MB145.namprd05.prod.outlook.com (10.242.198.17) X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2PR05MB145; X-Forefront-Antispam-Report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(24454002)(377454003)(51704005)(377424004)(42186005)(36756003)(15975445007)(92566002)(83716003)(86362001)(53416004)(82746002)(50986999)(66066001)(19580395003)(19580405001)(2950100001)(62966003)(46406003)(50226001)(230783001)(77096005)(77156002)(47776003)(46102003)(23726002)(76176999)(50466002)(33656002)(97756001)(87976001)(110136001)(57306001)(122386002)(40100003)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR05MB145; H:dmcginniss-sslvpn-nc.jnpr.net; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:BL2PR05MB145; BCL:0; PCL:0; RULEID:; SRVR:BL2PR05MB145; X-Forefront-PRVS: 054231DC40 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Apr 2015 20:09:40.8427 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR05MB145 X-Helo-Check-Failed: Verification failed for HELO na01-by2-obe.outbound.protection.outlook.com X-SA-Exim-Connect-IP: 207.46.100.103 X-SA-Exim-Rcpt-To: draft-ietf-idr-flowspec-redirect-rt-bis.all@tools.ietf.org X-SA-Exim-Mail-From: jhaas@juniper.net X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-idr-flowspec-redirect-rt-bis.all@ietf.org Resent-Message-Id: <20150411014644.97EBB1B2F25@ietfa.amsl.com> Resent-Date: Fri, 10 Apr 2015 18:46:44 -0700 (PDT) Resent-From: jhaas@juniper.net Archived-At: Archived-At: X-Mailman-Approved-At: Sat, 11 Apr 2015 09:57:44 -0700 Cc: General Area Review Team , draft-ietf-idr-flowspec-redirect-rt-bis.all@tools.ietf.org Subject: Re: [Idr] Gen-ART Last Call review of draft-ietf-idr-flowspec-redirect-rt-bis-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: Sat, 11 Apr 2015 01:46:46 -0000 Brian, I'll be dealing with the review comments below in my response to the = Pearl at IANA. I will copy you on that response. -- Jeff On Mar 21, 2015, at 12:44 AM, Brian E Carpenter = wrote: > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > . >=20 > Please resolve these comments along with any other Last Call comments > you may receive. >=20 > Document: draft-ietf-idr-flowspec-redirect-rt-bis-03.txt > Reviewer: Brian Carpenter > Review Date: 2015-03-21 > IETF LC End Date: 2015-04-08 > IESG Telechat date: >=20 > Summary: Almost Ready > -------- >=20 > Minor Issue: > ------------ >=20 > In the IANA Considerations, two new registries are created (below). > For these two registries, the Registration Procedures need to be > defined, presumably on the same model as RFC 7153. >=20 > IANA is requested to create the "Generic Transitive Experimental Use > Extended Community Part 2 Sub-Types" registry. It should be seeded > with the following Sub-Type: >=20 > 0x08 - Flow spec redirect IPv4 format. >=20 > IANA is requested to create the "Generic Transitive Experimental Use > Extended Community Part 3 Sub-Types" registry. It should be seeded > with the following Sub-Type: >=20 > 0x08 - Flow spec redirect AS-4byte format. From nobody Sat Apr 11 09:57:49 2015 Return-Path: X-Original-To: expand-draft-ietf-idr-ls-distribution.all@virtual.ietf.org Delivered-To: idr@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 7CD061AC42D; Sat, 11 Apr 2015 00:26:34 -0700 (PDT) X-Original-To: xfilter-draft-ietf-idr-ls-distribution.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-idr-ls-distribution.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60A0E1AC429 for ; Sat, 11 Apr 2015 00:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.879 X-Spam-Level: X-Spam-Status: No, score=-0.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021] 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 cK285k7dTb1A for ; Sat, 11 Apr 2015 00:26:33 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D69C1AC428 for ; Sat, 11 Apr 2015 00:26:33 -0700 (PDT) Received: from smtp01.icann.org ([192.0.33.81]:34226 helo=smtp1.lax.icann.org) by zinfandel.tools.ietf.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YgpoG-0001Vy-ID for draft-ietf-idr-ls-distribution.all@tools.ietf.org; Sat, 11 Apr 2015 00:26:32 -0700 Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id t3B7QNWZ031090; Sat, 11 Apr 2015 07:26:23 GMT Received: by request3.lax.icann.org (Postfix, from userid 48) id 03FC9C207C5; Sat, 11 Apr 2015 07:26:23 +0000 (UTC) RT-Owner: Nobody From: "Amanda Baber via RT" In-Reply-To: <03d901d072f6$bc560660$35021320$@ndzh.com> References: <20150318194048.32558.24468.idtracker@ietfa.amsl.com> <03d901d072f6$bc560660$35021320$@ndzh.com> Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #818092 X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/) X-RT-Originator: amanda.baber@icann.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Sat, 11 Apr 2015 07:26:22 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 192.0.33.81 X-SA-Exim-Rcpt-To: draft-ietf-idr-ls-distribution.all@tools.ietf.org X-SA-Exim-Mail-From: iana-shared@icann.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-idr-ls-distribution.all@ietf.org Resent-Message-Id: <20150411072633.9D69C1AC428@ietfa.amsl.com> Resent-Date: Sat, 11 Apr 2015 00:26:33 -0700 (PDT) Resent-From: iana-shared@icann.org Archived-At: Archived-At: X-Mailman-Approved-At: Sat, 11 Apr 2015 09:57:44 -0700 Cc: draft-ietf-idr-ls-distribution.all@tools.ietf.org Subject: [Idr] [IANA #818092] RE: REVISED Last Call: (North-Bound Distribution of Link-State and TE Information using BGP) to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Reply-To: drafts-lastcall@iana.org List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2015 07:26:34 -0000 Sue, Jie, Is the shepherd included in the "draft-ietf-idr-ls-distribution.all@tools.ietf.org" alias? Before I send a note asking the authors to confirm the third and sixth actions, a quick note about this one: > On actions 1 and 2: First comment, this did go through the early > allocation procedure, and then into the extension to permanent > approval. However, I have no objection to changing the language to > fit the best text for IANA for the AFI/SAFI below. The RFC 7120 use of the term "early allocation" refers only to temporary assignments made in ranges that don't allow for permanent assignment before approval. It's the RFC 7120 use that we're trying to reserve the term for. Because the authors requested assignment in the registries' First Come, First Served ranges rather than Standards Action ranges, the early allocation process turned out to be unnecessary in those two cases. thanks, Amanda From nobody Sat Apr 11 19:51:01 2015 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 158101B3260 for ; Sat, 11 Apr 2015 19:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ca8RjgzRoIfF for ; Sat, 11 Apr 2015 19:50:59 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 3D9331B3263 for ; Sat, 11 Apr 2015 19:50:59 -0700 (PDT) Received: from [192.168.1.10] (pool-70-106-220-218.clppva.fios.verizon.net [70.106.220.218]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id B9F1C540935; Sat, 11 Apr 2015 22:50:57 -0400 (EDT) References: <003f01d07394$9b5f1c00$d21d5400$@ndzh.com> Mime-Version: 1.0 (1.0) In-Reply-To: <003f01d07394$9b5f1c00$d21d5400$@ndzh.com> Content-Type: multipart/alternative; boundary=Apple-Mail-7BE1BA62-5AEC-49DD-8DA1-A62A00D90DAD Content-Transfer-Encoding: 7bit Message-Id: <98D53A12-B950-48FD-8181-5B7744E64DB0@puck.nether.net> X-Mailer: iPhone Mail (12F70) From: Jon Mitchell Date: Sat, 11 Apr 2015 22:50:56 -0400 To: Susan Hares Archived-At: Cc: idr wg , "amante@apple.com" Subject: Re: [Idr] 2 Week WG LC on draft-ietf-idr-as-migration (4/9 to 4/23/2105 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: Sun, 12 Apr 2015 02:51:01 -0000 --Apple-Mail-7BE1BA62-5AEC-49DD-8DA1-A62A00D90DAD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Support. -Jon > On Apr 10, 2015, at 9:45 AM, Susan Hares wrote: >=20 > This is a 2 week WG LC on draft-ietf-as-migration. As discussed in the IE= TF 92 session, the feedback on this draft ask for a few changes in format an= d generalization of implementation terms. The authors and shepherd believe t= his has been accomplish with draft-ietf-as-migration-04.txt. This WG LC is= to determine if these revisions are acceptable to the IDR WG. > =20 > You can see the latest document at: > =20 > http://datatracker.ietf.org/doc/draft-ietf-idr-as-migration/ > =20 > Please indicate in your response =E2=80=9Csupport for this version=E2=80=9D= or =E2=80=9Cno support=E2=80=9D. > =20 > Sue Hares and John Scudder > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr --Apple-Mail-7BE1BA62-5AEC-49DD-8DA1-A62A00D90DAD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Support.

-Jon

On Apr 10, 2015, at 9:45 AM, Susan Hares <shares@ndzh.com> wrote:

This is a 2 week WG LC on draft-ietf-as-migration.  As discuss= ed in the IETF 92 session, the feedback on this draft ask for a few changes i= n format and generalization of implementation terms.  The authors and s= hepherd believe this has been accomplish with draft-ietf-as-migration-04.txt= .   This WG LC is to determine if these revisions are acceptable t= o the IDR WG.

 

You can see the latest document at:

 

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

 

Please indicate in your r= esponse =E2=80=9Csupport for this version=E2=80=9D or =E2=80=9Cno support=E2= =80=9D.

 

Sue Hares and John Scudder

____________________________________= ___________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr
= --Apple-Mail-7BE1BA62-5AEC-49DD-8DA1-A62A00D90DAD-- From nobody Sun Apr 12 02:09:40 2015 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 E20AF1B2F6E for ; Sun, 12 Apr 2015 02:09:37 -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 iZazxnwgM4mf for ; Sun, 12 Apr 2015 02:09:36 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CF651B2F6D for ; Sun, 12 Apr 2015 02:09:36 -0700 (PDT) Received: by iebrs15 with SMTP id rs15so45487195ieb.3 for ; Sun, 12 Apr 2015 02:09:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Ui4c2ipNCbxFRJFJHa4ldVb7AVBmRUPwOO04dyI0fgA=; b=IWzInFGupzi7ratewp62QtCal7A2wfv2vXFrF7GznEOis1jQ4LzvEsIcXL55y4wLId L2Y6gNvo8mJq2uIzVP6rTUhMyKF3ePtOb4qsw/Gf0sCrBFvCH/z3jk+MMP1YftlU4yr9 ozKDVCbj8cFn0ZEZqSZXcK730L6fvoc3y4N2csCciVj3BeYo6+cyAmkgGOxN56qbgQpP u06mp52F+2NmPQaVTvfG8qhkisWvYvPM/Am/eicPN2W3/6dpDRzIfnMpQGQAa/sVtNaB +RfHd5WNiHvFEfF9fh33QmK6r66mmX9IWPjXojL5H0Es8K5C91oCzxrZNDur1sRgjNQx 9vMw== MIME-Version: 1.0 X-Received: by 10.50.20.233 with SMTP id q9mr9274425ige.9.1428829775842; Sun, 12 Apr 2015 02:09:35 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.107.178.1 with HTTP; Sun, 12 Apr 2015 02:09:35 -0700 (PDT) In-Reply-To: <003f01d07394$9b5f1c00$d21d5400$@ndzh.com> References: <003f01d07394$9b5f1c00$d21d5400$@ndzh.com> Date: Sun, 12 Apr 2015 11:09:35 +0200 X-Google-Sender-Auth: SifMjRZ-R3w5TwxioGf2MFG2s_o Message-ID: From: Robert Raszuk To: Susan Hares Content-Type: multipart/alternative; boundary=047d7bd6bb5a3bd61f0513835b21 Archived-At: Cc: idr wg , Shane Amante Subject: Re: [Idr] 2 Week WG LC on draft-ietf-idr-as-migration (4/9 to 4/23/2105 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: Sun, 12 Apr 2015 09:09:38 -0000 --047d7bd6bb5a3bd61f0513835b21 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable support for this version Thx, r. On Fri, Apr 10, 2015 at 3:45 PM, Susan Hares wrote: > This is a 2 week WG LC on draft-ietf-as-migration. As discussed in the > IETF 92 session, the feedback on this draft ask for a few changes in form= at > and generalization of implementation terms. The authors and shepherd > believe this has been accomplish with draft-ietf-as-migration-04.txt. > This WG LC is to determine if these revisions are acceptable to the IDR > WG. > > > > You can see the latest document at: > > > > http://datatracker.ietf.org/doc/draft-ietf-idr-as-migration/ > > > > Please indicate in your response =E2=80=9Csupport for this version=E2=80= =9D or =E2=80=9Cno > support=E2=80=9D. > > > > Sue Hares and John Scudder > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > --047d7bd6bb5a3bd61f0513835b21 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
support for this version

<= span style=3D"font-family:Calibri,sans-serif;font-size:14.6666669845581px">= Thx,
r.

On Fri, Apr 10, 2015 at 3:4= 5 PM, Susan Hares <shares@ndzh.com> wrote:

This is a 2 week WG LC on draft-ietf-as-migration.=C2=A0= As discussed in the IETF 92 session, the feedback on this draft ask for a = few changes in format and generalization of implementation terms.=C2=A0 The= authors and shepherd believe this has been accomplish with draft-ietf-as-m= igration-04.txt.=C2=A0 =C2=A0This WG LC is to determine if these revisions = are acceptable to the IDR WG.

<= /u>=C2=A0

You can see the latest document = at:

=C2=A0

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

=C2= =A0

Please indicate in your response =E2= =80=9Csupport for this version=E2=80=9D or =E2=80=9Cno support=E2=80=9D.

=C2=A0

Sue Hares and John Scudder


___= ____________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr


--047d7bd6bb5a3bd61f0513835b21-- From nobody Sun Apr 12 09:27:17 2015 Return-Path: X-Original-To: expand-draft-ietf-idr-flowspec-redirect-rt-bis.all@virtual.ietf.org Delivered-To: idr@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 2DDAA1A89A6; Sat, 11 Apr 2015 20:31:38 -0700 (PDT) X-Original-To: xfilter-draft-ietf-idr-flowspec-redirect-rt-bis.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-idr-flowspec-redirect-rt-bis.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10FD51A89A5; Sat, 11 Apr 2015 20:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 CUpJxbbwxHyt; Sat, 11 Apr 2015 20:31:36 -0700 (PDT) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59A041A89A1; Sat, 11 Apr 2015 20:31:36 -0700 (PDT) Received: by pacyx8 with SMTP id yx8so64562983pac.1; Sat, 11 Apr 2015 20:31:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=pzKcUTU5pVXi62bUchmi2q9JSn8uDYQZfeKb2MEZ2yk=; b=tm4lEghQQCGSYD382IU7MhQku6qkgn1W89qJUsZqJfrsjqA20mFP08fzrdcg0dR2Qu SX7L08afPRsdRMlHNxN4SWMVfPYQKuBGSFXZ3QJxWSFH048qntMUiRl05aNPtqnOLN5e T5xIF8BYebz+dv1ZaYD3et/RBnN58NiRvUF1Agh8rlK1QBDLa9Te2XuyYZMlwnVETPxD 0XHx7+DfBaBskO3Nsg6k274wOHWtZNwR37As8hJFKoJy2YSivnwtMa0QuDhssn2sivY9 vRB8q/LJHJUvZbEEnEATHQfZyEprKpbsmUjAJvCoGFOg/bweGrswPgW9alt8fxiJAOWL HPyw== X-Received: by 10.66.90.134 with SMTP id bw6mr14915487pab.131.1428809496027; Sat, 11 Apr 2015 20:31:36 -0700 (PDT) Received: from ?IPv6:2406:e007:533b:1:28cc:dc4c:9703:6781? ([2406:e007:533b:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id li10sm3246388pbc.33.2015.04.11.20.31.32 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 11 Apr 2015 20:31:34 -0700 (PDT) Message-ID: <5529E70C.2090309@gmail.com> Date: Sun, 12 Apr 2015 15:31:24 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: draft-ietf-idr-flowspec-redirect-rt-bis.all@ietf.org, General Area Review Team References: <20150411125610.29353.16150.idtracker@ietfa.amsl.com> <71F77327-B704-4242-ADB7-FCAD3CAF9A09@pfrc.org> In-Reply-To: <71F77327-B704-4242-ADB7-FCAD3CAF9A09@pfrc.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Sun, 12 Apr 2015 09:27:16 -0700 Subject: Re: [Idr] I-D Action: draft-ietf-idr-flowspec-redirect-rt-bis-04.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: Sun, 12 Apr 2015 03:31:38 -0000 >From the viewpoint of my Gen-ART review, this version completely resolves my comment, and if asked to re-review it, the summary will be "Ready". Thanks Brian Carpenter On 12/04/2015 01:00, Jeffrey Haas wrote: > IDR Working Group and IETF main mailing list, > > The following update incorporates changes from directorate reviews and requests from IANA for clarification for the two new registries incidentally created to support this work. I have chosen to utilize the same allocation policy as the existing experimental extended community registry. > > Since no allocation policy was previously documented in the earlier versions of this draft during its last call, the IDR chairs will be issuing another last call including these changes. This gives the IETF community appropriate time to comment on the documented policy. > > -- Jeff > >> On Apr 11, 2015, at 8:56 AM, internet-drafts@ietf.org wrote: >> >> >> 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 : Clarification of the Flowspec Redirect Extended Community >> Author : Jeffrey Haas >> Filename : draft-ietf-idr-flowspec-redirect-rt-bis-04.txt >> Pages : 7 >> Date : 2015-04-11 >> >> Abstract: >> This document updates RFC 5575 (Dissemination of Flow Specification >> Rules) to clarify the formatting of the the BGP Flowspec Redirect >> Extended Community. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-redirect-rt-bis/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-idr-flowspec-redirect-rt-bis-04 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-flowspec-redirect-rt-bis-04 >> >> >> 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/ >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr > > From nobody Mon Apr 13 13:50:46 2015 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 43B761A1A27 for ; Mon, 13 Apr 2015 13:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.611 X-Spam-Level: X-Spam-Status: No, score=-12.611 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5xrOUyePLRui for ; Mon, 13 Apr 2015 13:50:42 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E56C71A0378 for ; Mon, 13 Apr 2015 13:50:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24405; q=dns/txt; s=iport; t=1428958242; x=1430167842; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=yKowrHRUAb5aiZKZsa2Iaf/sn8rLUV60itacV6Y85/o=; b=ZZB4AETVaT5dKQkr4jSqPV2MigmYBEr919JIK1G46eB+hv4On3tTl9ml vh7W+jcGVCT6eoehSvK9o3bnH6jbTO7ZbqmxUHwRHjk3BWJUx/bCQKtth xN3WRCX5WbhyztHLU1NVPGZxwbML0sdMrpKXAtrtC0I49WoDQindb4Nht c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BtBQDhKixV/5ldJa1cgkVHgS4FzGYCgT1MAQEBAQEBfoQgAQEEcgcQAgEIOAcHMhQRAQEEAQ0FiCrNMwEBAQEBAQEBAQEBAQEBAQEBAQEBAReLK4R8B4QtBY5yghqKD4EdgzeJDocKIoNvb4ECBjx/AQEB X-IronPort-AV: E=Sophos;i="5.11,572,1422921600"; d="scan'208,217";a="411876793" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 13 Apr 2015 20:50:40 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t3DKoeFx003073 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 13 Apr 2015 20:50:40 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.6]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0195.001; Mon, 13 Apr 2015 15:50:40 -0500 From: "Alvaro Retana (aretana)" To: "wesley.george@twcable.com" , "amante@apple.com" Thread-Topic: 2 Week WG LC on draft-ietf-idr-as-migration (4/9 to 4/23/2105 Thread-Index: AdBzlDcUkdJmp22uTqShwxbVd0A/MgCn6C+A Date: Mon, 13 Apr 2015 20:50:40 +0000 Message-ID: References: <003f01d07394$9b5f1c00$d21d5400$@ndzh.com> In-Reply-To: <003f01d07394$9b5f1c00$d21d5400$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.15.4] Content-Type: multipart/alternative; boundary="_000_D14DB16FA4767aretanaciscocom_" MIME-Version: 1.0 Archived-At: Cc: Susan Hares , idr wg Subject: Re: [Idr] 2 Week WG LC on draft-ietf-idr-as-migration (4/9 to 4/23/2105 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, 13 Apr 2015 20:50:45 -0000 --_000_D14DB16FA4767aretanaciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On 4/10/15, 9:45 AM, "Susan Hares" = > wrote: Hi! This is a 2 week WG LC on draft-ietf-as-migration. As discussed in the IET= F 92 session, the feedback on this draft ask for a few changes in format an= d generalization of implementation terms. The authors and shepherd believe= this has been accomplish with draft-ietf-as-migration-04.txt. This WG LC= is to determine if these revisions are acceptable to the IDR WG. I believe that the updated document is almost where we want it to be. In g= eneral, there is some tentative language and other things I would like fixe= d (most minor or nits). Please see my comments below. I do have one item that I think may be above =93minor=94: when using =93Loc= al AS=94, when should the ASN be prepended? When sending eBGP-received UPD= ATEs to iBGP neighbors (as it is specified currently), OR, then receiving t= hose eBGP UPDATEs? If it is not done when receiving, then the AS_PATH will= be inconsistent in the AS (the border router will have a shorter AS_PATH).= I think this can lead to inconsistent route selection (given that the att= ributes are inconsistent inside the AS), but that of course may be mitigate= d by the fact that the application of Local AS may be towards stub networks= in many (but not all) cases. I would really like to hear others=92 (beyo= nd the authors) opinions. [My comments #3 and #7 in the Minor section belo= w are related to this.] I support this document moving forward. Wes/Shane: Thanks for the work on this! Alvaro. [BTW, it may look like a lot of comments, but most of them are editorial.] Minor Issues: 1. 3.1 s/Within the Loc-RIB on ISP B prior to the migration, the AS_PATH= toward customer C would appear as: 64510/Within the Loc-RIB on ISP B prior= to the migration, the AS_PATH toward customer C would appear as: 64496 2. The word =93capability=94 is used in several places. While it is use= d correctly (from a language point of view), I think it may cause confusion= with a BGP Capability (for example: =93the "Internal BGP AS Migration" ca= pability is enabled on all iBGP sessions on that device=94). I know that i= n this case there is no negotiation of capabilities; just trying to make th= e text clearer. 3. 3.1 (see comment #7 below) (second paragraph): s/when advertising UPD= ATES received from customer C/when receiving UPDATES from customer C 4. 3.2 s/CE-A would have seen an AS_PATH of: 64496 64510 64500/CE-A woul= d have seen an AS_PATH of: 64500 64510 64496 5. 3.3 "Implementations MAY support a more flexible model..=94 I like t= his, but I wonder about the relationship of this =93MAY=94 with the =93MUST= NOT=94 in "BGP router MUST NOT use the ASN configured globally within the = BGP process=94. It sounds as if there=92s a contradiction: MUST NOT use it= , but you MAY. I think this contradiction can be easily solved by using = =93SHOULD NOT=94 instead of =93MUST NOT=94. 6. This document should be marked as updating rfc4271 because of the pro= cessing of the UPDATEs (section 3.3). 7. 3.3 (See comment #3 above) "the router MUST append the configured "Lo= cal AS" ASN in the AS_PATH attribute before advertising the UPDATE to an iB= GP neighbor.=94 If the Local AS is not appended to the incoming UPDATE, th= en the border router will have a different AS_PATH than the rest of the net= work (which is the reason for my comment #3 above). If you think this is a= valid comment, then there are a couple of places that should be cleaned up= . 8. 3.3 I think that the =93MUSTs=94 in the Local AS description should b= e =93SHOULD=94 given that you later define the options. 9. 4.2 * It may be clearer if instead of "globally configured=94 and "local= ly configured=94, =93New_ASN=94 and =93Old_ASN=94 (or something to that eff= ect) are used. * In 3.3 you talked about the mechanism being available per-neighbor= . Do we need that same granularity here? Nits: 1. Intro: * Take this ("and may be vendor-specific in exact implementation=94)= out. * s/These mechanisms are local to a given BGP Speaker and do not req= uire negotiation with or cooperation of BGP neighbors. The deployment of th= ese mechanisms do not need to interwork with one another to accomplish the = desired results, so slight variations between existing vendor implementatio= ns exist, and will not necessarily be harmonized due to this document. Howe= ver, it is necessary. . ./These mechanisms are local to a given BGP Speaker= and do not require negotiation with or cooperation of BGP neighbors. It i= s necessary. . . 2. 3.1 Take out "usually configured on a per-neighbor basis." 3. 3.2 s/legacy AS, (AS64510)./legacy AS (AS64510). 4. 3.2 Delete the second paragraph, which starts with =93In some existin= g implementations=94. Then for the third paragraph: s/[Third paragraph]/A= tertiary mechanism, referred to as "Replace Old AS=94 is used to prevent r= outers from appending the globally configured ASN in outbound BGP UPDATEs t= oward directly attached eBGP neighbors that are using the "Local AS=94 mech= anism. Instead, only the ASN specified using =93Local AS" will be prepende= d in the outbound BGP UPDATE toward the customer's network, restoring the A= S_PATH length to what it what was before AS Migration occurred. 5. 3.3 Delete the first paragraph. 6. 3.3 s/These mechanisms/The mechanisms introduced in this section 7. 3.3 Is =93peer-group=94 a well known construct for any implementatio= n? If it is, then no change is needed..if not, then maybe saying a =93grou= p of peers=94 might work. 8. 3.3 "When the "Local AS=94 capability is used, a local ASN will be pr= ovided in the configuration that is different from the globally-configured = ASN of the BGP router.=94 Do you want to provide some guidance here? SHOU= LD/MUST it be different? I guess there=92s no real harm (from the point of= view of the mechanisms defined) if it is the same.. [Later in the paragra= ph it says "MUST NOT use the ASN configured globally=94, so I guess it is i= mplicit that it has to be different or nothing should happen.] 9. 3.3 s/using the local ASN configured/using the =93Local AS=94 10. 4.1 s/iBGP session, (using identical ASNs)/iBGP session (i.e. using i= dentical ASNs) 11. 4.1 This sub-section is titled =93BGP Alias=94, but the mechanism is = called "Internal BGP AS Migration=94. Either name is fine with me; you may= want to title the section using the same name as the feature, or (if not u= sing alias) with a more descriptive title. 12. Ordering: Put Section 9 in an actual appendix. It might be nice to p= ut the Acks after the Security Considerations. --_000_D14DB16FA4767aretanaciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
On 4/10/15, 9:45 AM, "Susan Hares" <shares@ndzh.com> wrote:

Hi!

<AD Hat on>

This is a 2 week WG LC on draft-ietf-as-migration.  As discussed in th= e IETF 92 session, the feedback on this draft ask for a few changes in form= at and generalization of implementation terms.  The authors and shephe= rd believe this has been accomplish with draft-ietf-as-migration-04.txt.&nb= sp;  This WG LC is to determine if these revisions are acceptable to the = IDR WG.

I believe that the updated document is almost where we want it to be.  = ;In general, there is some tentative language and other things I would like= fixed (most minor or nits).  Please see my comments below.

I do have one item that I think may be above =93minor=94: when using =93Loc= al AS=94, when should the ASN be prepended?  When sending eBGP-receive= d UPDATEs to iBGP neighbors (as it is specified currently), OR, then receiv= ing those eBGP UPDATEs?  If it is not done when receiving, then the AS_PATH will be inconsistent in the AS (the border rou= ter will have a shorter AS_PATH).  I think this can lead to inconsiste= nt route selection (given that the attributes are inconsistent inside the A= S), but that of course may be mitigated by the fact that the application of Local AS may be towards stub networks = in many (but not all) cases.   I would really like to hear others=92 (= beyond the authors) opinions.  [My comments #3 and #7 in the Minor sec= tion below are related to this.]

I support this document moving forward.

Wes/Shane:  Thanks for the work on this!

Alvaro.


[BTW, it may look like a lot of comments, but most of them are editorial.]<= /div>

Minor Issues:
  1. 3.1 s/Within the = ;Loc-RIB on ISP B = prior to the migration, the AS_PATH toward customer C w= ould appear as: 64510/Within the Loc-RIB on ISP B prior to the migra= tion, the AS_PATH toward customer C would appear as: 64496
  2. The word =93capability=94 is used in several plac= es.  While it is used correctly (from a language point of view), I thi= nk it may cause confusion with a BGP Capability (for example: <= font face=3D"Calibri,sans-serif">=93the "Internal BGP AS Migration"  capability is enabled on all i= BGP sessions on that device= =94).  I know= that in this case there is no negotiation of capabilities; just trying to make the text clearer.
  3. 3.1 (see comment #7 below) (second paragraph): s/when advertising UPDATES r= eceived from customer C/when receiving UPDATES from customer C
  4. 3.2 s/CE-A would have seen an AS_PATH of: 64496 64510 64500/CE-A would have= seen an AS_PATH of: 64500 64510 64496
  5. 3.3 "Implementations MAY support a more flexible model..=94  I like this, but I wonder about the = relationship of this =93MAY=94 with the =93MUST NOT=94 in "<= /font>BGP router MUST NOT use the ASN&nbs= p;configured globally within the B= GP process=94.  It sounds as if there=92s a contradiction: MUST NOT use = it, but you MAY.  I think this contradiction can be easily solved by u= sing =93SHOULD NOT=94 instead of =93MUST NOT=94.
  6. This document should be marked as updatin= g rfc4271 because of the processing of the UPDATEs (section 3.3).
  7. 3.3 (See comment #3 above) "<= /font>the router MUST app= end the configured "Local AS" ASN in the AS_PATH attribute before advertising the UPDATE to an iBGP neighbor.=94  If the Local AS is not ap= pended to the incoming UPDATE, then the border router will have a different= AS_PATH than the rest of the network (which is the reason for my comment #3 above).  If you think this is a valid co= mment, then there are a couple of places that should be cleaned up.<= /li>
  8. 3.3 I think that the =93MUSTs= =94 in the Local AS description should be =93SHOULD=94 given that= you later define the options.
  9. 4.2  
    • It may be clearer if instead of "= ;globally configured=94 and "locally configured=94, =93New_ASN=94= and =93Old_ASN=94 (or something to that effect) are used.=
    • In 3.3 you talked about the mech= anism being available per-neighbor.  Do we need that same granularity = here?

Nits:
  1. Intro: 
    • Take this ("and may be vendor-specific in exact implementation=94) out= .
    • s/These mechanisms are local to a given BGP Speak= er and do not= require negotiation with or cooperation of BGP neighbors. The deployment of these mechanisms do not need to interwork with one another to accomplish = the desired results, so slight variations between existing vendor implementations exist, and will not necessarily be harmonized due to this docume= nt. However, it is nTh= ese mechanisms are local to a given BGP Speaker and do not require negotiation with or coop= eration of BGP neighbors.  It is necessary. . .
  2. usually confi= gured on a pe= r-neighbor basis."
  3. legacy&nbs= p;AS, (AS64510)./legacy=  AS (AS64510)= .
  4. 3.2 Delete the second paragraph, which st= arts with =93In some existing implementations=94.   Then for the = third paragraph: s/[Third paragraph]/A tertiary mechanism, referred to as "Replace Old AS= =94 is used to prevent routers from appending the globally configured ASN in outbound BG= P UPDATEs toward directly attached eBGP neighbors that are using the "Local AS=94 = ;mechanism.  Instead, only th= e ASN specified using =93Local AS" will be prepended in the outbound BGP UPDATE toward the customer's network, restoring the AS_PATH length to what it what was = before AS Migration occurred.
  5. These mechanisms/The mecha= nisms introduced in this section
  6. 3.3  Is =93peer-group=94 a well= known construct for any implementation?  If it is, then no change is = needed..if not, then maybe saying a =93group of peers=94 might work.
  7. 3.3 "When the "Local AS=94 that is different from the globally-c= onfigured ASN of the BGP router.=94  Do you want to provide some guidance here?  SHOULD/MUST it be different? &nb= sp;I guess there=92s no real harm (from the point of view of the mecha= nisms defined) if it is the same..  [Later in the paragraph it says &q= uot;MUST NOT use the ASN configured globally=94, so I guess it is implicit that it has to b= e different or nothing should happen.]
  8. 3.3 s/using the local ASN configured/using the =93Local AS=94
  9. 4.1 s/iBGP session, (using identical ASNs)/iBGP session (i.e. using identical ASNs)
  10. 4.1 This sub-section is titled =93BGP Alias=94, but the mechanism i= s called "Internal BGP AS Mig= ration=94.  Either name is fine with me; you may want to title th= e section using the same name as the feature, or (if not using alias) with a more descriptive title.&nbs= p;
  11. Ordering: Put Section 9= in an actual appendix.  It might be nice to put the Acks after the Se= curity Considerations.


--_000_D14DB16FA4767aretanaciscocom_-- From nobody Wed Apr 15 11:35:27 2015 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 1E4221A07BC for ; Wed, 15 Apr 2015 11:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 Upk0Jw1L-MAe for ; Wed, 15 Apr 2015 11:35:25 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7F641A079D for ; Wed, 15 Apr 2015 11:35:24 -0700 (PDT) X-AuditID: c6180641-f790b6d000004359-7c-552e4c644c6b Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id F6.C0.17241.46C4E255; Wed, 15 Apr 2015 13:32:52 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0210.002; Wed, 15 Apr 2015 14:35:20 -0400 From: Uma Chunduri To: "idr@ietf.org" Thread-Topic: Code points for https://tools.ietf.org/html/draft-ietf-idr-te-pm-bgp-02 Thread-Index: AdB3quye5L8X+ooRQmOPClCVy6aXTA== Date: Wed, 15 Apr 2015 18:35:19 +0000 Message-ID: <1B502206DFA0C544B7A60469152008633F627711@eusaamb105.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: multipart/alternative; boundary="_000_1B502206DFA0C544B7A60469152008633F627711eusaamb105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBLMWRmVeSWpSXmKPExsUyuXSPn26Kj16owfc2E4tXt58xOTB6LFny kymAMYrLJiU1J7MstUjfLoErY9+bz2wFB4QrDp3dytzAuFKwi5GTQ0LAROLCp8OsELaYxIV7 69lAbCGBo4wSK6cVdzFyAdnLGSX+L7vABJJgE9CT+Dj1J3sXIweHiICixMpPySCmsECQxEyQ KCdQNFxi9maIMSJA1dead4PFWQRUJV7tWAxm8wr4SqzfcATMZgRa+/3UGrDpzALiEreezGeC OEdAYsme88wQtqjEy8f/oM5Ukpjz+hozRH2+RNf/SUwQMwUlTs58wjKBUWgWklGzkJTNQlIG EdeRWLD7ExuErS2xbOFrZhj7zIHHTMjiCxjZVzFylBanluWmGxluYgQG/TEJNscdjAs+WR5i FOBgVOLhXRCqGyrEmlhWXJl7iFGag0VJnLfsysEQIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxS DYwFAR+FpwkuPxiU37IxTPauW1ZtRS3rxBu5D612/OB58c9wT9aXj5+9I3xfzfpx6m7K+sMG 5+2VA3Xt7M89Douyq3STsZe4/773Qe3Dq2nyh+cv/MDouuPvPK4I+04h8aSCFTtvdby/MfFT 5pxH9gfXdFyuTT27wtl88aZb9j+VrGR1avQrRYqUWIozEg21mIuKEwHjjGskWwIAAA== Archived-At: Subject: [Idr] Code points for https://tools.ietf.org/html/draft-ietf-idr-te-pm-bgp-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: Wed, 15 Apr 2015 18:35:26 -0000 --_000_1B502206DFA0C544B7A60469152008633F627711eusaamb105erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Authors, It would be good to assign the early allocated IANA code points or suggeste= d values to this document. Thx! -- Uma C. --_000_1B502206DFA0C544B7A60469152008633F627711eusaamb105erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Authors,

 

It would be good to assign the early allocated IANA = code points or suggested values to this document. Thx!

 

--

Uma C.

--_000_1B502206DFA0C544B7A60469152008633F627711eusaamb105erics_-- From nobody Wed Apr 15 13:24:21 2015 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 E959D1A8A13 for ; Wed, 15 Apr 2015 13:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0TyzSoMC7jF0 for ; Wed, 15 Apr 2015 13:24:20 -0700 (PDT) Received: from server.riw.us (server.riw.us [162.144.32.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8CED1A8A0E for ; Wed, 15 Apr 2015 13:24:19 -0700 (PDT) Received: from 162-229-180-77.lightspeed.rlghnc.sbcglobal.net ([162.229.180.77]:53096 helo=RussPC) by server.riw.us with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.85) (envelope-from ) id 1YiTr6-0000ju-NL; Wed, 15 Apr 2015 20:24:16 +0000 From: "Russ White" To: "'Susan Hares'" , "'idr wg'" References: <002e01d070ba$275479e0$75fd6da0$@ndzh.com> In-Reply-To: <002e01d070ba$275479e0$75fd6da0$@ndzh.com> Date: Wed, 15 Apr 2015 16:24:11 -0400 Message-ID: <008301d077ba$22fe06c0$68fa1440$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQKA0fTSmsu+EElIt1Ak1YtdVhgq0Zvt0D4Q Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.riw.us X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Get-Message-Sender-Via: server.riw.us: authenticated_id: russw@riw.us X-Source: X-Source-Args: X-Source-Dir: Archived-At: Cc: dbrungard@att.com Subject: Re: [Idr] WG LC for draft-ietf-bgp-route-oscillation-stop (4/6 to 4/20) 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, 15 Apr 2015 20:24:21 -0000 > This begins a 2 week WG LC for draft-ietf-bgp-route-oscillation. In your > comments about the readiness of the draft please include "support" or "no > support", and comment about the value of the draft. Support -- this draft is a valuable addition to the WG documents. Russ From nobody Wed Apr 15 21:17:43 2015 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 BD4AA1B2D9C for ; Wed, 15 Apr 2015 21:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 152YVASvsLhy for ; Wed, 15 Apr 2015 21:17:40 -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 4E5E01B2D99 for ; Wed, 15 Apr 2015 21:17:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=504; q=dns/txt; s=iport; t=1429157860; x=1430367460; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=ObtNk0wilawdKh4qa4s/OQDLRpSrUpw4yP+NvFnNHbE=; b=a84oABLx1kI0wvxRnyoy1rSFdCN5Yxt2Grfn1LAkMB7D/wPGBn82kXAF vOjjJRQFW6MZP3k94g5TQEvH91izu4p7AlKCEF4/zhgK9qJv1ihXsr16b ELhR8DOzttfK/El1ELH9tkWOHv/bWURa2sZkcztAodrVdtVtd3MUWqjQp g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AUBQAWNy9V/4gNJK1cgwxSXAXHQQqGAwKBPEwBAQEBAQF+hCEBAQMBAQEBNzQbAgEIDigQJwslAQEEARKIIggNxioBAQEBAQEBAQEBAQEBAQEBAQEBFQSLK4UDhC0FkRaKGYEdgzmMWINNIoNvb4FEfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,585,1422921600"; d="scan'208";a="412300122" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-4.cisco.com with ESMTP; 16 Apr 2015 04:17:39 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t3G4HdmA024525 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 16 Apr 2015 04:17:39 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.110]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Wed, 15 Apr 2015 23:17:39 -0500 From: "Yi Yang (yiya)" To: Susan Hares , "'idr wg'" Thread-Topic: [Idr] WG LC for draft-ietf-bgp-route-oscillation-stop (4/6 to 4/20) Thread-Index: AdBwudDRspjI4CwBRnyuVoZtgQp5UQHKjnqAAAgnNQA= Date: Thu, 16 Apr 2015 04:17:38 +0000 Message-ID: References: <002e01d070ba$275479e0$75fd6da0$@ndzh.com> <008301d077ba$22fe06c0$68fa1440$@riw.us> In-Reply-To: <008301d077ba$22fe06c0$68fa1440$@riw.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.255.230] Content-Type: text/plain; charset="us-ascii" Content-ID: <924D6B7301DDE04FA51BF5BFB04224E3@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] WG LC for draft-ietf-bgp-route-oscillation-stop (4/6 to 4/20) 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, 16 Apr 2015 04:17:41 -0000 +1. Yi On 4/15/15, 4:24 PM, "Russ White" wrote: > >> This begins a 2 week WG LC for draft-ietf-bgp-route-oscillation. In your >> comments about the readiness of the draft please include "support" or >>"no >> support", and comment about the value of the draft. > >Support -- this draft is a valuable addition to the WG documents. > >Russ > > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr From nobody Wed Apr 15 23:30:46 2015 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 9AC631B29DE for ; Wed, 15 Apr 2015 23:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 F-7QRLjGJq7D for ; Wed, 15 Apr 2015 23:30:43 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F00B11B29DD for ; Wed, 15 Apr 2015 23:30:42 -0700 (PDT) X-AuditID: c6180641-f790b6d000004359-f5-552ef403a209 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 4A.49.17241.304FE255; Thu, 16 Apr 2015 01:28:04 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0210.002; Thu, 16 Apr 2015 02:30:40 -0400 From: Jeff Tantsura To: 'Susan Hares' , 'idr wg' Thread-Topic: [Idr] WG LC for draft-ietf-bgp-route-oscillation-stop (4/6 to 4/20) Thread-Index: AdBwudDRspjI4CwBRnyuVoZtgQp5UQHIdgmAAAaDJIA= Date: Thu, 16 Apr 2015 06:30:40 +0000 Message-ID: References: <002e01d070ba$275479e0$75fd6da0$@ndzh.com> <008301d077ba$22fe06c0$68fa1440$@riw.us> In-Reply-To: <008301d077ba$22fe06c0$68fa1440$@riw.us> 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: [147.117.188.11] Content-Type: text/plain; charset="us-ascii" Content-ID: <3EE16067523BA545BC1A30B62EC1C29E@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjkeLIzCtJLcpLzFFi42KZXLonUJfli16owbPLbBbbdy5hsXh1+xmT xZ83r1gcmD1e9s9h9Fiy5CeTx+zX11kDmKO4bFJSczLLUov07RK4MmY/72EsuMJcsffSbcYG xj9MXYycHBICJhKHGv5D2WISF+6tZ+ti5OIQEjjKKHHy2DFWCGc5o8Tbk3OYQarYBAwk/n87 zgJiiwjYSOx4cYsNxGYW0JZoerESaBIHh7BAkMTpefEQJcESezu3MkPYVhI77x5hBLFZBFQl lm68BBbnFTCXaL50HiwuJJAocbZvHSuIzSlgKnFn4lmwVYxAx30/tYYJYpW4xK0n86GOFpBY suc8M4QtKvHy8T+wXlEBPYlnGzazQ8SVJD7+ns8O0asjsWD3J6iTrSW2TdjDBHP+soWvoe4R lDg58wnLBEaJWUjWzULSPgtJ+ywk7bOQtC9gZF3FyFFanFqWm25kuIkRGIHHJNgcdzAu+GR5 iFGAg1GJh3dBqG6oEGtiWXFl7iFGaQ4WJXHesisHQ4QE0hNLUrNTUwtSi+KLSnNSiw8xMnFw SjUw8p05+91stZndqeWSFSIJmTMzruRL26+edqWq2jmQfcb5er7MkKfhDQond5Tcep7WaLxb b5LFxEhjGU9+Ye1zj98d2hzXHtMsEm55riLujmHo+r0zsmcWhy7sVdnC93PDH//D28/uubpX MSBiKseGk7oS/47tC+l/zzSxrlhI3ez9nrfMXmIMSizFGYmGWsxFxYkAbgaD76ECAAA= Archived-At: Cc: "dbrungard@att.com" Subject: Re: [Idr] WG LC for draft-ietf-bgp-route-oscillation-stop (4/6 to 4/20) 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, 16 Apr 2015 06:30:44 -0000 Yes/support Cheers, Jeff > >> This begins a 2 week WG LC for draft-ietf-bgp-route-oscillation. In your >> comments about the readiness of the draft please include "support" or >>"no >> support", and comment about the value of the draft. > >Support -- this draft is a valuable addition to the WG documents. > >Russ > > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr From nobody Wed Apr 15 23:35:35 2015 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 73D9C1B29FE for ; Wed, 15 Apr 2015 23:35:33 -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 JWyrnxNT-Yea for ; Wed, 15 Apr 2015 23:35:32 -0700 (PDT) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BFFD1B29F9 for ; Wed, 15 Apr 2015 23:35:32 -0700 (PDT) Received: by igblo3 with SMTP id lo3so43409489igb.0 for ; Wed, 15 Apr 2015 23:35: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=cm1HTQdplAazm2VSHHMfXFdgAvu54WGlyhYTminj3M8=; b=eMtq+Q3e/eO3y7hSqwqszsWzqwk7InYt9HfojrciDTQY0w0jvcpgnNx1LSJXNrWl97 Bk0/4bdAFQCmOe0vzbCMl52wKZT3iKld2xWzKR1j6t+v59oPGz1RWeoA4ojjcBrUZrvq ijuUNNwET6+ZFad/JQQ3H1LPjZYa90CuV1rlIu5O3jAcbx+vs7psWnNEUSYTa0LHGijW X7XzKshGycpgo8vO3esFRWUqV9DH75UqyYQOViIbJpT1kW8LpiQMEVKRDSJ9vXUVXRRw TGbzBYiufpRpVSIYkTLEnj1mcZLSSfZA8aCn3ey6N71SM2PbovZ3V1cqz4O41u0f3g6B hNaw== MIME-Version: 1.0 X-Received: by 10.50.61.130 with SMTP id p2mr3491740igr.9.1429166131759; Wed, 15 Apr 2015 23:35:31 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.107.178.1 with HTTP; Wed, 15 Apr 2015 23:35:31 -0700 (PDT) In-Reply-To: <002e01d070ba$275479e0$75fd6da0$@ndzh.com> References: <002e01d070ba$275479e0$75fd6da0$@ndzh.com> Date: Thu, 16 Apr 2015 08:35:31 +0200 X-Google-Sender-Auth: hr02xXus-Yrtpv204-XIphiVk4s Message-ID: From: Robert Raszuk To: Susan Hares Content-Type: multipart/alternative; boundary=047d7bdcaa0e9bd1760513d1ab9e Archived-At: Cc: idr wg Subject: Re: [Idr] WG LC for draft-ietf-bgp-route-oscillation-stop (4/6 to 4/20) 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, 16 Apr 2015 06:35:33 -0000 --047d7bdcaa0e9bd1760513d1ab9e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Support Best, r. On Tue, Apr 7, 2015 at 12:36 AM, Susan Hares wrote: > This begins a 2 week WG LC for draft-ietf-bgp-route-oscillation. In your > comments about the readiness of the draft please include =E2=80=9Csupport= =E2=80=9D or =E2=80=9Cno > support=E2=80=9D, and comment about the value of the draft. > > > > You can see the draft at: > > > > http://datatracker.ietf.org/doc/draft-ietf-idr-route-oscillation-stop/ > > > > Sue Hares and John Scudder > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > --047d7bdcaa0e9bd1760513d1ab9e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Support

Best,
r.
On Tue, Apr 7, 2015 at 12:36 AM, Susan Hares <= span dir=3D"ltr"><s= hares@ndzh.com> wrote:

= This begins a 2 week WG LC for draft-ietf-bgp-route-oscillation. In your co= mments about the readiness of the draft please include =E2=80=9Csupport=E2= =80=9D or =E2=80=9Cno support=E2=80=9D, and comment about the value of the = draft.

=C2=A0

You can see the draft at:

=C2=A0

http://datatracker.ietf.org/doc/draft-ietf-idr-route-oscillatio= n-stop/

=C2=A0

Sue Hares and John Scudder

<= /div>
_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr


--047d7bdcaa0e9bd1760513d1ab9e-- From nobody Thu Apr 16 01:45:22 2015 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 D430A1B2C5B for ; Thu, 16 Apr 2015 01:45:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eoXa3SEJ4xPB for ; Thu, 16 Apr 2015 01:45:17 -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 92A041B2C58 for ; Thu, 16 Apr 2015 01:45:16 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BUY01950; Thu, 16 Apr 2015 08:45:15 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 16 Apr 2015 09:45:14 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.135]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Thu, 16 Apr 2015 16:45:10 +0800 From: "Dongjie (Jimmy)" To: Susan Hares , idr wg Thread-Topic: [Idr] WG LC for draft-ietf-bgp-route-oscillation-stop (4/6 to 4/20) Thread-Index: AdBwudDRspjI4CwBRnyuVoZtgQp5UQHZlBJw Date: Thu, 16 Apr 2015 08:45:10 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C92757D07F7F@nkgeml512-mbx.china.huawei.com> References: <002e01d070ba$275479e0$75fd6da0$@ndzh.com> In-Reply-To: <002e01d070ba$275479e0$75fd6da0$@ndzh.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.131] Content-Type: multipart/alternative; boundary="_000_76CD132C3ADEF848BD84D028D243C92757D07F7Fnkgeml512mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "dbrungard@att.com" Subject: Re: [Idr] WG LC for draft-ietf-bgp-route-oscillation-stop (4/6 to 4/20) 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, 16 Apr 2015 08:45:21 -0000 --_000_76CD132C3ADEF848BD84D028D243C92757D07F7Fnkgeml512mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support. And one minor comment: In section 3 and section 6 it says: "For the sake of scalability the advertisement of multiple paths should be = limited to those prefixes which are affected by MED-induced route oscillati= on in a network carrying a large number of alternate paths." How do the RRs or confederation ASBRs identify those prefixes affected by M= ED-induced oscillation? Is there some rules or it is operator configuratio= n? Best regards, Jie From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Tuesday, April 07, 2015 6:37 AM To: idr wg Cc: dbrungard@att.com Subject: [Idr] WG LC for draft-ietf-bgp-route-oscillation-stop (4/6 to 4/20= ) This begins a 2 week WG LC for draft-ietf-bgp-route-oscillation. In your co= mments about the readiness of the draft please include "support" or "no sup= port", and comment about the value of the draft. You can see the draft at: http://datatracker.ietf.org/doc/draft-ietf-idr-route-oscillation-stop/ Sue Hares and John Scudder --_000_76CD132C3ADEF848BD84D028D243C92757D07F7Fnkgeml512mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support.

 

And one minor comment:

 

In section 3 and section 6 it says:

 

“For the sake of scalability the advertisement of multiple = paths should be limited to those prefixes which are affected by MED-induced= route oscillation in a network carrying a large number of alternate paths.”

 

How do the RRs or confederation ASBRs identify those prefixes aff= ected by MED-induced oscillation?  Is there some rules or it is operat= or configuration?

 

Best regards,

Jie

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Tuesday, April 07, 2015 6:37 AM
To: idr wg
Cc: dbrungard@att.com
Subject: [Idr] WG LC for draft-ietf-bgp-route-oscillation-stop (4/6 = to 4/20)

 

This begins a 2 week WG LC for = draft-ietf-bgp-route-oscillation. In your comments about the readiness of t= he draft please include “support” or “no support”, = and comment about the value of the draft.

 

You can see the draft at: =

 

http://datatracker.ietf= .org/doc/draft-ietf-idr-route-oscillation-stop/

 

Sue Hares and John Scudder=

--_000_76CD132C3ADEF848BD84D028D243C92757D07F7Fnkgeml512mbxchi_-- From nobody Thu Apr 16 06:44:52 2015 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 D176A1B319A for ; Thu, 16 Apr 2015 06:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, 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 4jhI4qXvaWWA for ; Thu, 16 Apr 2015 06:44:48 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93FB91B3199 for ; Thu, 16 Apr 2015 06:44:48 -0700 (PDT) Received: by iebrs15 with SMTP id rs15so51540210ieb.3 for ; Thu, 16 Apr 2015 06:44:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cumulusnetworks.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EmuQ1ELEom4GfWadeG0MCGRtN+9Hol18TNSHd5Xh6+4=; b=IXbW3qL14vU5hH5Emu67hkE47nx2tHat+znIZ6uj6ZEgex5p7tveRLSEyX1Okx3dtb RZw1QZFTSTjObMzIk2SSiTnSLp7JWn74LoAhX+vz6nGl+X0J6uSS+iDw3GNO2/TskHQx hXCXTDWvaNusDkjdBgvGPyj3fsDkQKqaIAlxI= 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=EmuQ1ELEom4GfWadeG0MCGRtN+9Hol18TNSHd5Xh6+4=; b=URymMh+cU0IqNSkxorKXSLu6Bd0BxPuVUTGThsp0O4dsjW3fB8GkTY0HRG4lhWVaSu YWZFviOIchyTZ1km1K+lkDEdoF/rrKn2qcs3bBh1PEsbabUgbEzQMN3XpJuU63kAjq10 HrlHnv0kdLlgWeMb4o0l9TkTmNMqD8YC6EOQGKKwNPSEz+JitVVwlDfbIkxgmTKUCSFW 4UV6KqpHy70OKYPoIGuV1jEUOeAUP+/hnVh9/zEpy8ms0DVM1FdUwwBqnqq806HaFfxc P1TbhIkYJ6gqzQITmm7hblsEFA21E37mX29qS7vCzKby6tcRKu1jFhwcSf8i/7NA1Ers 43JQ== X-Gm-Message-State: ALoCoQk3opY0NiKXRjwOUAEEr1pu7sHNi3DKQj2PKjrq51GT5tmYVS8Y/DUjEta+MkHvgxJJiZkp MIME-Version: 1.0 X-Received: by 10.42.171.8 with SMTP id h8mr36720321icz.25.1429191888039; Thu, 16 Apr 2015 06:44:48 -0700 (PDT) Received: by 10.107.129.88 with HTTP; Thu, 16 Apr 2015 06:44:47 -0700 (PDT) In-Reply-To: <76CD132C3ADEF848BD84D028D243C92757D07F7F@nkgeml512-mbx.china.huawei.com> References: <002e01d070ba$275479e0$75fd6da0$@ndzh.com> <76CD132C3ADEF848BD84D028D243C92757D07F7F@nkgeml512-mbx.china.huawei.com> Date: Thu, 16 Apr 2015 09:44:47 -0400 Message-ID: From: Daniel Walton To: "Dongjie (Jimmy)" Content-Type: multipart/alternative; boundary=90e6ba613ba6cd7f1f0513d7aa62 Archived-At: Cc: idr wg , "dbrungard@att.com" , Susan Hares Subject: Re: [Idr] WG LC for draft-ietf-bgp-route-oscillation-stop (4/6 to 4/20) 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, 16 Apr 2015 13:44:51 -0000 --90e6ba613ba6cd7f1f0513d7aa62 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > > =E2=80=9CFor the sake of scalability the advertisement of multiple paths = should be > limited to those prefixes which are affected by MED-induced route > oscillation in a network carrying a large number of alternate paths.=E2= =80=9D > > > > How do the RRs or confederation ASBRs identify those prefixes affected by > MED-induced oscillation? Is there some rules or it is operator > configuration? > The easiest way is to monitor how often the bestpath changes for a prefix. If the bestpath for a prefix changes at some consistent interval that is a strong indicator of MED churn. The details for how an implemenation would automaticaly do this are beyond the scope of the draft. If you want to do it manually the easiest way is to do "show ip route | grep " 00:00" which will show you any route that is less than a minute old. Do that a few times and see which prefixes keep popping up. This of course assumes that the box you are on displays how long the route has been in the RIB :) As for what that churn interval typically is, it varies depending on the network. When we first found MED churn we often saw an interval of 60s becuase IOS would recalculate all bestpaths as part of the BGP Scanner process which kicked off every minute by default. Eventually the bestpath recalc was removed from scanner and made event-driven so then the churn would be constant...or as fast as the MRAI timers in the network would allow. Daniel --90e6ba613ba6cd7f1f0513d7aa62 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

=E2=80=9CFor the sake of scalability the advertisement of multiple pat= hs should be limited to those prefixes which are affected by MED-induced ro= ute oscillation in a network carrying a large number of alternate paths.=E2=80=9D

=C2=A0

How do the RRs or confederation ASBRs identify those prefixes aff= ected by MED-induced oscillation?=C2=A0 Is there some rules or it is operat= or configuration?


The easi= est way is to monitor how often the bestpath changes for a prefix.=C2=A0 If= the bestpath for a prefix changes at some consistent interval that is a st= rong indicator of MED churn.=C2=A0 The details for how an implemenation wou= ld automaticaly do this are beyond the scope of the draft.=C2=A0 If you wan= t to do it manually the easiest way is to do "show ip route | grep &qu= ot; 00:00" which will show you any route that is less than a minute ol= d.=C2=A0 Do that a few times and see which prefixes keep popping up.=C2=A0 = This of course assumes that the box you are on displays how long the route = has been in the RIB :)

As for what that churn inte= rval typically is, it varies depending on the network.=C2=A0 When we first = found MED churn we often saw an interval of 60s becuase IOS would recalcula= te all bestpaths as part of the BGP Scanner process which kicked off every = minute by default.=C2=A0 Eventually the bestpath recalc was removed from sc= anner and made event-driven so then the churn would be constant...or as fas= t as the MRAI timers in the network would allow.

D= aniel

=C2=A0
--90e6ba613ba6cd7f1f0513d7aa62-- From nobody Thu Apr 16 14:28:47 2015 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 3D6F61A8ABD for ; Thu, 16 Apr 2015 14:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B--Ht6EoXa9T for ; Thu, 16 Apr 2015 14:28:44 -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 8D2E71A8AB6 for ; Thu, 16 Apr 2015 14:28:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1911; q=dns/txt; s=iport; t=1429219724; x=1430429324; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version:content-id; bh=WeLPBCUm3fz4MnyfyrUL9Pnxou8PonfpJTjTZ8hBQ6A=; b=gRrU7es5W0xU3jwNJ9xB6iPPTP9NbsQAs5V2UJFJWzoU3QmmH3vjF0za Ue6zZRd14IRzon+JX+5QNs9fnNzc0nH1SSkcz+NzPbDSO65b5BfuKkJ9I fR0jZs/8XWULaVGhJDHMQAvR82fTVK6qgdKo2YMAVdr2ZJpWOWn42W97d o=; X-IronPort-AV: E=Sophos;i="5.11,590,1422921600"; d="scan'208";a="141959984" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-7.cisco.com with ESMTP; 16 Apr 2015 21:28:44 +0000 Received: from clubhouse-1.cisco.com (clubhouse-1.cisco.com [64.100.21.13]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t3GLQfTE016967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Apr 2015 21:28:43 GMT Date: Thu, 16 Apr 2015 17:26:36 -0400 (EDT) From: Juan Alcaide To: "Alvaro Retana (aretana)" In-Reply-To: Message-ID: References: <20150409140218.22830.31521.idtracker@ietfa.amsl.com> <02e401d072e4$4f5a1cc0$ee0e5640$@ndzh.com> User-Agent: Alpine 2.00 (GSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-1382141583-1429219391=:17655" Content-ID: Archived-At: Cc: "idr@ietf.org" , jgralak@juniper.net, Susan Hares Subject: Re: [Idr] I-D Action: draft-ietf-idr-as-migration-04.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: Thu, 16 Apr 2015 21:28:46 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-1382141583-1429219391=:17655 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8BIT Content-ID: Hi, Let me chip using a previous discussion inputs. When using local-as, Cisco prepends AS on inbound updates from eBGP peers. I understand Juniper prepends AS on outbounds updates towards eBGP peers. In most cases, Cisco approach is better. > > > > Consider > > > > > > > > R1 (AS1) ----(local-as 2) R2(AS3)--- R3(AS3) --- R4 (AS4) > > > > ebgp iBGP > > > > > > > > Cisco: > > > > > > > > R1: X > > > > R2: 2 X > > > > R3: 2 X > > > > R4: 3 2 X > > > > > > > > Juniper > > > > > > > > R1: X > > > > R2: X > > > > R3: 2 X > > > > R4: 3 2 X > > > > > > > > I think it's prefereable that R2 and R3 have the same AS-PATH. Otherwise > > > > you can have inconsistent best-path decission inside AS3 -Juan On Thu, 9 Apr 2015, Alvaro Retana (aretana) wrote: > On 4/9/15, 12:43 PM, "Susan Hares" wrote: > >> Let me review the document and query Alvaro to make sure it addresses his >> concerns. >> >> On re-doing WG LC, we can do this in parallel with the other reviews I'll >> need to redo (security directorate, routing directorate, ops-directorate >> and gen-art). I'll start both sequences at the same time once I've heard >> from Alvaro. > > I¹ll go read it, but my gut reaction is that we should go back through > (WGLC, etc.). > > Thanks! > > Alvaro. > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > ---559023410-1382141583-1429219391=:17655-- From nobody Sun Apr 19 21:59:32 2015 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 802631ACD35 for ; Sun, 19 Apr 2015 21:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.354 X-Spam-Level: X-Spam-Status: No, score=-96.354 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 mRfd-ECYKiko for ; Sun, 19 Apr 2015 21:59:29 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 8AA461ACD31 for ; Sun, 19 Apr 2015 21:59:29 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=125.205.241.158; From: "Susan Hares" To: "'Daniel Walton'" , "'Dongjie \(Jimmy\)'" References: <002e01d070ba$275479e0$75fd6da0$@ndzh.com> <76CD132C3ADEF848BD84D028D243C92757D07F7F@nkgeml512-mbx.china.huawei.com> In-Reply-To: Date: Mon, 20 Apr 2015 00:59:16 -0400 Message-ID: <001c01d07b26$c2633680$4729a380$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001D_01D07B05.3BBC6640" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKA0fTSmsu+EElIt1Ak1YtdVhgq0QKvu+b/AkzT+XmbzMSOUA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'idr wg' , dbrungard@att.com Subject: Re: [Idr] WG LC for draft-ietf-bgp-route-oscillation-stop (4/6 to 4/20) 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, 20 Apr 2015 04:59:31 -0000 This is a multipart message in MIME format. ------=_NextPart_000_001D_01D07B05.3BBC6640 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Daniel:=20 =20 Do you see any current changes in the churn level? Have you examined = the churn inside of a datacenter? =20 Sue=20 =20 From: Daniel Walton [mailto:dwalton@cumulusnetworks.com]=20 Sent: Thursday, April 16, 2015 9:45 AM To: Dongjie (Jimmy) Cc: Susan Hares; idr wg; dbrungard@att.com Subject: Re: [Idr] WG LC for draft-ietf-bgp-route-oscillation-stop (4/6 = to 4/20) =20 =E2=80=9CFor the sake of scalability the advertisement of multiple paths = should be limited to those prefixes which are affected by MED-induced = route oscillation in a network carrying a large number of alternate = paths.=E2=80=9D =20 How do the RRs or confederation ASBRs identify those prefixes affected = by MED-induced oscillation? Is there some rules or it is operator = configuration? =20 The easiest way is to monitor how often the bestpath changes for a = prefix. If the bestpath for a prefix changes at some consistent = interval that is a strong indicator of MED churn. The details for how = an implemenation would automaticaly do this are beyond the scope of the = draft. If you want to do it manually the easiest way is to do "show ip = route | grep " 00:00" which will show you any route that is less than a = minute old. Do that a few times and see which prefixes keep popping up. = This of course assumes that the box you are on displays how long the = route has been in the RIB :) =20 As for what that churn interval typically is, it varies depending on the = network. When we first found MED churn we often saw an interval of 60s = becuase IOS would recalculate all bestpaths as part of the BGP Scanner = process which kicked off every minute by default. Eventually the = bestpath recalc was removed from scanner and made event-driven so then = the churn would be constant...or as fast as the MRAI timers in the = network would allow. =20 Daniel =20 =20 ------=_NextPart_000_001D_01D07B05.3BBC6640 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Daniel:

 

Do you see any current changes in the churn level?=C2=A0 Have you = examined the churn inside of a datacenter?

 

Sue

 

From:= = Daniel Walton [mailto:dwalton@cumulusnetworks.com]
Sent: = Thursday, April 16, 2015 9:45 AM
To: Dongjie = (Jimmy)
Cc: Susan Hares; idr wg; = dbrungard@att.com
Subject: Re: [Idr] WG LC for = draft-ietf-bgp-route-oscillation-stop (4/6 to = 4/20)

 

=E2=80= =9CFor the sake of scalability the advertisement of multiple paths = should be limited to those prefixes which are affected by MED-induced = route oscillation in a network carrying a large number of alternate = paths.=E2=80=9D

 = ;

How = do the RRs or confederation ASBRs identify those prefixes affected by = MED-induced oscillation?  Is there some rules or it is operator = configuration?

 

The easiest way is to monitor how often the bestpath = changes for a prefix.  If the bestpath for a prefix changes at some = consistent interval that is a strong indicator of MED churn.  The = details for how an implemenation would automaticaly do this are beyond = the scope of the draft.  If you want to do it manually the easiest = way is to do "show ip route | grep " 00:00" which will = show you any route that is less than a minute old.  Do that a few = times and see which prefixes keep popping up.  This of course = assumes that the box you are on displays how long the route has been in = the RIB :)

 

As for what that churn interval typically is, it = varies depending on the network.  When we first found MED churn we = often saw an interval of 60s becuase IOS would recalculate all bestpaths = as part of the BGP Scanner process which kicked off every minute by = default.  Eventually the bestpath recalc was removed from scanner = and made event-driven so then the churn would be constant...or as fast = as the MRAI timers in the network would = allow.

 

Daniel

 

 

------=_NextPart_000_001D_01D07B05.3BBC6640-- From nobody Sun Apr 19 23:55:44 2015 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 981A01A8840 for ; Sun, 19 Apr 2015 23:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.155 X-Spam-Level: X-Spam-Status: No, score=-97.155 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 FcL3oAU_N0tp for ; Sun, 19 Apr 2015 23:55:42 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 1A1691A8766 for ; Sun, 19 Apr 2015 23:55:41 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=125.205.241.158; From: "Susan Hares" To: "'idr wg'" Date: Mon, 20 Apr 2015 02:55:35 -0400 Message-ID: <002701d07b37$0227e0d0$0677a270$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0028_01D07B15.7B17C770" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdB7NwBtvf1gv3VRTkGyFuk2Ylj/EQ== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: jhaas@juniper.net Subject: [Idr] 2 week WG LC on changes to draft-ietf-idr-flowspec-rediret-rt-bis-04.txt (4/20 to 5/4/2015) 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, 20 Apr 2015 06:55:43 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0028_01D07B15.7B17C770 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all: Jeff revised the IANA Section (section 2) of this draft: http://www.ietf.org/internet-drafts/draft-ietf-idr-flowspec-redirect-rt-bis- 04.txt Please review these changes and indicate "support" or "no support" for the new form of the IANA tables. Sue Hares and John Scudder ------=_NextPart_000_0028_01D07B15.7B17C770 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
 
Hi all: 
 
Jeff revised the IANA Section (section 2)  of =
this draft: 
 
http://www.ietf.org/internet-drafts/draft-ietf-idr-flo=
wspec-redirect-rt-bis-04.txt

 

Please = review these changes and indicate “support” or “no = support” for the new form of the IANA tables.

 

Sue Hares = and John Scudder  

------=_NextPart_000_0028_01D07B15.7B17C770-- From nobody Mon Apr 20 00:53:31 2015 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 6A8661ACEAA for ; Mon, 20 Apr 2015 00:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.055 X-Spam-Level: X-Spam-Status: No, score=-99.055 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, USER_IN_WHITELIST=-100] 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 iLLRADoEbjWP for ; Mon, 20 Apr 2015 00:53:29 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 3478C1ACEA9 for ; Mon, 20 Apr 2015 00:53:29 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=125.205.241.158; From: "Susan Hares" To: "'Juan Alcaide'" , "'Alvaro Retana \(aretana\)'" References: <20150409140218.22830.31521.idtracker@ietfa.amsl.com> <02e401d072e4$4f5a1cc0$ee0e5640$@ndzh.com> In-Reply-To: Date: Mon, 20 Apr 2015 03:53:21 -0400 Message-ID: <001f01d07b3f$13ee12f0$3bca38d0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF4r1Z2HL4YFm8OUbIc3fl4NvJEkQMc7jnKAeHZrpYCMURyMwGvlBIDnb4iGXA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: idr@ietf.org, jgralak@juniper.net Subject: Re: [Idr] I-D Action: draft-ietf-idr-as-migration-04.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, 20 Apr 2015 07:53:30 -0000 Juan:=20 Do you think something needs to change in this draft? This is the last = day of the WG adoiption call.=20 Sue=20 -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Juan Alcaide Sent: Thursday, April 16, 2015 5:27 PM To: Alvaro Retana (aretana) Cc: idr@ietf.org; jgralak@juniper.net; Susan Hares Subject: Re: [Idr] I-D Action: draft-ietf-idr-as-migration-04.txt Hi, Let me chip using a previous discussion inputs. When using local-as, Cisco prepends AS on inbound updates from eBGP = peers.=20 I understand Juniper prepends AS on outbounds updates towards eBGP = peers.=20 In most cases, Cisco approach is better. > > > > Consider > > > > > > > > R1 (AS1) ----(local-as 2) R2(AS3)--- R3(AS3) --- R4 (AS4) > > > > ebgp iBGP > > > > > > > > Cisco: > > > > > > > > R1: X > > > > R2: 2 X > > > > R3: 2 X > > > > R4: 3 2 X > > > > > > > > Juniper > > > > > > > > R1: X > > > > R2: X > > > > R3: 2 X > > > > R4: 3 2 X > > > > > > > > I think it's prefereable that R2 and R3 have the same AS-PATH.=20 Otherwise > > > > you can have inconsistent best-path decission inside AS3 -Juan On Thu, 9 Apr 2015, Alvaro Retana (aretana) wrote: > On 4/9/15, 12:43 PM, "Susan Hares" wrote: > >> Let me review the document and query Alvaro to make sure it addresses = >> his concerns. >> >> On re-doing WG LC, we can do this in parallel with the other reviews=20 >> I'll need to redo (security directorate, routing directorate,=20 >> ops-directorate and gen-art). I'll start both sequences at the same=20 >> time once I've heard from Alvaro. > > I=B9ll go read it, but my gut reaction is that we should go back = through=20 > (WGLC, etc.). > > Thanks! > > Alvaro. > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > From nobody Mon Apr 20 00:55:19 2015 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 44B181ACEAD for ; Mon, 20 Apr 2015 00:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.055 X-Spam-Level: X-Spam-Status: No, score=-99.055 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, USER_IN_WHITELIST=-100] 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 TZXWHihVYuOj for ; Mon, 20 Apr 2015 00:55:17 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 0A2CD1ACE9B for ; Mon, 20 Apr 2015 00:55:16 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=125.205.241.158; From: "Susan Hares" To: "'Juan Alcaide'" , "'Alvaro Retana \(aretana\)'" References: <20150409140218.22830.31521.idtracker@ietfa.amsl.com> <02e401d072e4$4f5a1cc0$ee0e5640$@ndzh.com> <001f01d07b3f$13ee12f0$3bca38d0$@ndzh.com> In-Reply-To: <001f01d07b3f$13ee12f0$3bca38d0$@ndzh.com> Date: Mon, 20 Apr 2015 03:55:09 -0400 Message-ID: <002401d07b3f$5433a050$fc9ae0f0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF4r1Z2HL4YFm8OUbIc3fl4NvJEkQMc7jnKAeHZrpYCMURyMwGvlBIDA1ULulydo3pXIA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: idr@ietf.org, jgralak@juniper.net Subject: Re: [Idr] I-D Action: draft-ietf-idr-as-migration-04.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, 20 Apr 2015 07:55:18 -0000 Hi all:=20 It appears that Juan is gone for 1 week, so we will pick-up his comments = on draft-ietf-idr-as-migration-04 during the IESG review time. =20 Sue=20 -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Monday, April 20, 2015 3:53 AM To: 'Juan Alcaide'; 'Alvaro Retana (aretana)' Cc: idr@ietf.org; jgralak@juniper.net Subject: Re: [Idr] I-D Action: draft-ietf-idr-as-migration-04.txt Juan:=20 Do you think something needs to change in this draft? This is the last = day of the WG adoiption call.=20 Sue=20 -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Juan Alcaide Sent: Thursday, April 16, 2015 5:27 PM To: Alvaro Retana (aretana) Cc: idr@ietf.org; jgralak@juniper.net; Susan Hares Subject: Re: [Idr] I-D Action: draft-ietf-idr-as-migration-04.txt Hi, Let me chip using a previous discussion inputs. When using local-as, Cisco prepends AS on inbound updates from eBGP = peers.=20 I understand Juniper prepends AS on outbounds updates towards eBGP = peers.=20 In most cases, Cisco approach is better. > > > > Consider > > > > > > > > R1 (AS1) ----(local-as 2) R2(AS3)--- R3(AS3) --- R4 (AS4) > > > > ebgp iBGP > > > > > > > > Cisco: > > > > > > > > R1: X > > > > R2: 2 X > > > > R3: 2 X > > > > R4: 3 2 X > > > > > > > > Juniper > > > > > > > > R1: X > > > > R2: X > > > > R3: 2 X > > > > R4: 3 2 X > > > > > > > > I think it's prefereable that R2 and R3 have the same AS-PATH.=20 Otherwise > > > > you can have inconsistent best-path decission inside AS3 -Juan On Thu, 9 Apr 2015, Alvaro Retana (aretana) wrote: > On 4/9/15, 12:43 PM, "Susan Hares" wrote: > >> Let me review the document and query Alvaro to make sure it addresses = >> his concerns. >> >> On re-doing WG LC, we can do this in parallel with the other reviews=20 >> I'll need to redo (security directorate, routing directorate,=20 >> ops-directorate and gen-art). I'll start both sequences at the same=20 >> time once I've heard from Alvaro. > > I=B9ll go read it, but my gut reaction is that we should go back = through=20 > (WGLC, etc.). > > Thanks! > > Alvaro. > > _______________________________________________ > 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 From nobody Mon Apr 20 01:01:32 2015 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 92C5B1ACECC for ; Mon, 20 Apr 2015 01:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.354 X-Spam-Level: X-Spam-Status: No, score=-96.354 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 9iDORgefFOFW for ; Mon, 20 Apr 2015 01:01:23 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 5736C1ACECB for ; Mon, 20 Apr 2015 01:01:23 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=125.205.241.158; From: "Susan Hares" To: Date: Mon, 20 Apr 2015 04:01:19 -0400 Message-ID: <002601d07b40$308aa3a0$919feae0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0027_01D07B1E.A97A8A40" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdB7P+Snoc9YjlnKTpCWYhskfHIPQA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] 2 Week WG LC draft-ietf-idr-add-paths-implementation-00 (4/6 to 4/20/2015) 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, 20 Apr 2015 08:01:24 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0027_01D07B1E.A97A8A40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This WG LC is complete, but we need to hear each author with their IPR Statement. Would each author indicated if they know of IPR on this draft. Sue Hares ------=_NextPart_000_0027_01D07B1E.A97A8A40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This WG LC = is complete, but we need to hear each author with their IPR = Statement.   Would each author indicated if they know of IPR = on this draft.

 

Sue Hares =

------=_NextPart_000_0027_01D07B1E.A97A8A40-- From nobody Mon Apr 20 01:18:07 2015 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 D816D1ACEFF for ; Mon, 20 Apr 2015 01:18:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.155 X-Spam-Level: X-Spam-Status: No, score=-97.155 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 64KF7IfF2zU9 for ; Mon, 20 Apr 2015 01:18:01 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id A72891ACEFE for ; Mon, 20 Apr 2015 01:18:01 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=125.205.241.158; From: "Susan Hares" To: Date: Mon, 20 Apr 2015 04:17:53 -0400 Message-ID: <003901d07b42$81726440$84572cc0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003A_01D07B20.FA624AE0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdB7Qe8ANIzRlJptQkiqaEFZTnCC0Q== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] WG LC for draft-ietf-bgp-route-oscillation-stop (4/6 to 4/20) 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, 20 Apr 2015 08:18:03 -0000 This is a multipart message in MIME format. ------=_NextPart_000_003A_01D07B20.FA624AE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The 2 week WG LC for draft-ietf-bgp-route-oscillation-stop has completed. This WG draft has completed WG LC, and WG consensus has been reached. This document will be forwarded toward the IESG with the shepherd's comments (Sue Hares). However, we still the need the authors to publish to the list whether they know of any IPR related to the draft. Sue Hares and John Scudder ------=_NextPart_000_003A_01D07B20.FA624AE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The 2 week = WG LC for draft-ietf-bgp-route-oscillation-stop has completed.  = This WG draft has completed WG LC, and WG consensus has been = reached.   This document will be forwarded toward the IESG = with the shepherd’s comments (Sue Hares).

 

However, we = still the need the authors to publish to the list whether they know of = any IPR related to the draft.

 

Sue Hares = and John Scudder

------=_NextPart_000_003A_01D07B20.FA624AE0-- From nobody Mon Apr 20 01:25:44 2015 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 2C9891ACF1C for ; Mon, 20 Apr 2015 01:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-xMGxpNJkW5 for ; Mon, 20 Apr 2015 01:25:42 -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 150F11ACF19 for ; Mon, 20 Apr 2015 01:25:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1415; q=dns/txt; s=iport; t=1429518342; x=1430727942; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Mfb+eW2e1mOgvZ47Fs4i0We4/Ef4lMBEV+TyiEHIIAo=; b=SeOT6ZNcow24dr0Rf3UMv1ZGC0vaJkjP4H+MXYvMJSgGUK7R3d340lh7 He7J1rc2ykPvk6KMrS8XUE7ma/JWOfPnhyKZaYBd112sefEEjqzwA8bm8 WijtfrUEnJbRetTI8kqHpDiIPCfUZ8SZQtXs43aR1iqDBAUYqxv0nxK3o w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CTBABmtzRV/5xdJa1bgwyBLrUWkDwJh1ICgS44FAEBAQEBAQF9hBcKAQEEeRACAQgDAQoxBzIUEQIEDgWIK8kKAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4s3hQQHgxeBFgWPDYIeiiEBlSEigjeBPG+CRAEBAQ X-IronPort-AV: E=Sophos;i="5.11,608,1422921600"; d="scan'208,217";a="142723183" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-7.cisco.com with ESMTP; 20 Apr 2015 08:25:41 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t3K8PfAS019104 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 20 Apr 2015 08:25:41 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.6]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Mon, 20 Apr 2015 03:25:40 -0500 From: "Alvaro Retana (aretana)" To: Susan Hares Thread-Topic: [Idr] 2 Week WG LC draft-ietf-idr-add-paths-implementation-00 (4/6 to 4/20/2015) Thread-Index: AQHQe0OWJx+S361LU0C3HAqzUWDtaw== Date: Mon, 20 Apr 2015 08:25:41 +0000 Message-ID: References: <002601d07b40$308aa3a0$919feae0$@ndzh.com> In-Reply-To: <002601d07b40$308aa3a0$919feae0$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_EB3C951C9F664BDCA7A40EB9ED216980ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] 2 Week WG LC draft-ietf-idr-add-paths-implementation-00 (4/6 to 4/20/2015) 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, 20 Apr 2015 08:25:43 -0000 --_000_EB3C951C9F664BDCA7A40EB9ED216980ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I don't know of any IPR on this draft. Thanks! Alvaro. Sent from my iPad On Apr 20, 2015, at 4:01 AM, Susan Hares > wrote: This WG LC is complete, but we need to hear each author with their IPR Stat= ement. Would each author indicated if they know of IPR on this draft. --_000_EB3C951C9F664BDCA7A40EB9ED216980ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I don't know of any IPR on this draft.

Thanks!

Alvaro.

Sent from my iPad

On Apr 20, 2015, at 4:01 AM, Susan Hares <shares@ndzh.com> wrote:

This WG LC is complete, but we need to hear each aut= hor with their IPR Statement.   Would each author indicated if th= ey know of IPR on this draft.

 

--_000_EB3C951C9F664BDCA7A40EB9ED216980ciscocom_-- From nobody Mon Apr 20 04:39:07 2015 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 D00AA1B2AE8; Mon, 20 Apr 2015 04:39:05 -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 HV41SJmqQUjT; Mon, 20 Apr 2015 04:39:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DE1941B2AEB; Mon, 20 Apr 2015 04:39:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150420113903.18799.85401.idtracker@ietfa.amsl.com> Date: Mon, 20 Apr 2015 04:39:03 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-custom-decision-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: Mon, 20 Apr 2015 11:39:06 -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 Custom Decision Process Authors : Alvaro Retana Russ White Filename : draft-ietf-idr-custom-decision-06.txt Pages : 9 Date : 2015-04-20 Abstract: The BGP specification defines a Decision Process for installation of routes into the Loc-RIB. This process takes into account an extensive series of path attributes, which can be manipulated to indicate preference for specific paths. It is cumbersome (if at all possible) for the end user to define policies that will select, after partial comparison, a path based on subjective local (domain and/or node) criteria. This document defines a new Extended Community, called the Cost Community, which may be used in tie breaking during the best path selection process. The end result is a local custom decision process. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-custom-decision/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-custom-decision-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-custom-decision-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 Mon Apr 20 05:45:09 2015 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 B30FF1A1E0E for ; Mon, 20 Apr 2015 05:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ye4P_fnl7ZWa for ; Mon, 20 Apr 2015 05:45:06 -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 C8F851A1EF3 for ; Mon, 20 Apr 2015 05:45:05 -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.4-5) with ESMTP id 1d4f4355.2b3bee6a0940.3792130.00-2461.10694720.nbfkord-smmo05.seg.att.com (envelope-from ); Mon, 20 Apr 2015 12:45:05 +0000 (UTC) X-MXL-Hash: 5534f4d13a9b5012-ecbd0d47df91ba29bd9b2179fb5bd6f3bfcd845a Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id 5b4f4355.0.3791910.00-2342.10694053.nbfkord-smmo05.seg.att.com (envelope-from ); Mon, 20 Apr 2015 12:44:38 +0000 (UTC) X-MXL-Hash: 5534f4b60a6e19e8-0a6f4ba3124b1ac6bdf51205086a154438d4f196 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 t3KCiauY016053; Mon, 20 Apr 2015 08:44:37 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t3KCiQQT015885 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 20 Apr 2015 08:44:28 -0400 Received: from MISOUT7MSGHUBAF.ITServices.sbc.com (MISOUT7MSGHUBAF.itservices.sbc.com [130.9.129.150]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Mon, 20 Apr 2015 12:44:15 GMT Received: from MISOUT7MSGUSRCD.ITServices.sbc.com ([169.254.4.140]) by MISOUT7MSGHUBAF.ITServices.sbc.com ([130.9.129.150]) with mapi id 14.03.0224.002; Mon, 20 Apr 2015 08:44:14 -0400 From: "UTTARO, JAMES" To: "'Susan Hares'" , "'Juan Alcaide'" , "'Alvaro Retana (aretana)'" Thread-Topic: [Idr] I-D Action: draft-ietf-idr-as-migration-04.txt Thread-Index: AQHQeIxY0Vfhn9Zqo0KEUv9MXDNa551V0BmAgAAPjvA= Date: Mon, 20 Apr 2015 12:44:14 +0000 Message-ID: References: <20150409140218.22830.31521.idtracker@ietfa.amsl.com> <02e401d072e4$4f5a1cc0$ee0e5640$@ndzh.com> <001f01d07b3f$13ee12f0$3bca38d0$@ndzh.com> In-Reply-To: <001f01d07b3f$13ee12f0$3bca38d0$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.76.236] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=ZfOqwLpA c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=Ctq2v2mG_3QA:10 a=BLceEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=zQP] X-AnalysisOut: [7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=e9J7MTPGsLIA:10 a=48vgC7mUA] X-AnalysisOut: [AAA:8 a=OUXY8nFuAAAA:8 a=1sjgXBK7AAAA:8 a=VHf7hneOlCaFBVei] X-AnalysisOut: [0kQA:9 a=wPNLvfGTeEIA:10 a=kxB0_YFr1TRcXWz5:21 a=Nh_SeFV3p] X-AnalysisOut: [4sk3I-e: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: Cc: "'idr@ietf.org'" , "'jgralak@juniper.net'" Subject: Re: [Idr] I-D Action: draft-ietf-idr-as-migration-04.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, 20 Apr 2015 12:45:07 -0000 What would be great is that the features that are being used are standardiz= ed across vendors. The current approach where each implementation varies in= behavior will make life difficult. =20 Jim Uttaro -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Monday, April 20, 2015 3:53 AM To: 'Juan Alcaide'; 'Alvaro Retana (aretana)' Cc: idr@ietf.org; jgralak@juniper.net Subject: Re: [Idr] I-D Action: draft-ietf-idr-as-migration-04.txt Juan:=20 Do you think something needs to change in this draft? This is the last day of the WG adoiption call.=20 Sue=20 -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Juan Alcaide Sent: Thursday, April 16, 2015 5:27 PM To: Alvaro Retana (aretana) Cc: idr@ietf.org; jgralak@juniper.net; Susan Hares Subject: Re: [Idr] I-D Action: draft-ietf-idr-as-migration-04.txt Hi, Let me chip using a previous discussion inputs. When using local-as, Cisco prepends AS on inbound updates from eBGP peers.= =20 I understand Juniper prepends AS on outbounds updates towards eBGP peers.=20 In most cases, Cisco approach is better. > > > > Consider > > > > > > > > R1 (AS1) ----(local-as 2) R2(AS3)--- R3(AS3) --- R4 (AS4) > > > > ebgp iBGP > > > > > > > > Cisco: > > > > > > > > R1: X > > > > R2: 2 X > > > > R3: 2 X > > > > R4: 3 2 X > > > > > > > > Juniper > > > > > > > > R1: X > > > > R2: X > > > > R3: 2 X > > > > R4: 3 2 X > > > > > > > > I think it's prefereable that R2 and R3 have the same AS-PATH.=20 Otherwise > > > > you can have inconsistent best-path decission inside AS3 -Juan On Thu, 9 Apr 2015, Alvaro Retana (aretana) wrote: > On 4/9/15, 12:43 PM, "Susan Hares" wrote: > >> Let me review the document and query Alvaro to make sure it addresses=20 >> his concerns. >> >> On re-doing WG LC, we can do this in parallel with the other reviews=20 >> I'll need to redo (security directorate, routing directorate,=20 >> ops-directorate and gen-art). I'll start both sequences at the same=20 >> time once I've heard from Alvaro. > > I=B9ll go read it, but my gut reaction is that we should go back through= =20 > (WGLC, etc.). > > Thanks! > > Alvaro. > > _______________________________________________ > 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 From nobody Mon Apr 20 10:46:40 2015 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 3BB081A039B; Mon, 20 Apr 2015 10:46:39 -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 4YSKpulAFurZ; Mon, 20 Apr 2015 10:46:37 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0142.outbound.protection.outlook.com [65.55.169.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A6011A00F6; Mon, 20 Apr 2015 10:46:34 -0700 (PDT) Received: from BLUPR05MB722.namprd05.prod.outlook.com (10.141.207.150) by BLUPR05MB419.namprd05.prod.outlook.com (10.141.27.19) with Microsoft SMTP Server (TLS) id 15.1.136.25; Mon, 20 Apr 2015 17:46:33 +0000 Authentication-Results: cs.tcd.ie; dkim=none (message not signed) header.d=none; Received: from cvincent-sslvpn-nc.jnpr.net (66.129.241.14) by BLUPR05MB722.namprd05.prod.outlook.com (10.141.207.150) with Microsoft SMTP Server (TLS) id 15.1.148.15; Mon, 20 Apr 2015 17:46:29 +0000 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "John G. Scudder" In-Reply-To: <20150310141226.24491.44397.idtracker@ietfa.amsl.com> Date: Mon, 20 Apr 2015 13:46:22 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20150310141226.24491.44397.idtracker@ietfa.amsl.com> To: Stephen Farrell X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [66.129.241.14] X-ClientProxiedBy: CO2PR11CA0012.namprd11.prod.outlook.com (10.141.242.150) To BLUPR05MB722.namprd05.prod.outlook.com (10.141.207.150) X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB722; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB419; X-Forefront-Antispam-Report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(377454003)(51704005)(52314003)(50226001)(19580395003)(36756003)(76176999)(50986999)(110136001)(23746002)(82746002)(53416004)(19580405001)(66066001)(40100003)(47776003)(87976001)(83716003)(2950100001)(46102003)(33656002)(77156002)(57306001)(42186005)(230783001)(86362001)(92566002)(50466002)(62966003)(77096005)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB722; H:cvincent-sslvpn-nc.jnpr.net; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:BLUPR05MB722; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB722; X-Forefront-PRVS: 05529C6FDB X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Apr 2015 17:46:29.8919 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB722 X-OriginatorOrg: juniper.net Archived-At: Cc: "idr@ietf. org" , rob.shakir@bt.com, draft-ietf-idr-error-handling.all@ietf.org, The IESG , idr-chairs@ietf.org Subject: Re: [Idr] Stephen Farrell's No Objection on draft-ietf-idr-error-handling-18: (with COMMENT) 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, 20 Apr 2015 17:46:39 -0000 Hi Stephen, I'm doing a final update of the draft to cover comments in IE SG review. = I'd like to discuss yours a bit. On Mar 10, 2015, at 10:12 AM, Stephen Farrell = wrote: > - There is a perhaps missing security consideration. I think > this kind of protocol behaviour argues that any kind of > BGPSEC encryption needs to use an AEAD ciphersuite. (Which > we'd likely do these days anyway, so that's not a biggie.) > The reason is if say CBC or a stream cipher were used, then > an attacker could play with ciphertext is various ways that > might interact with this error handling behaviour so as to > expose information that is intended to be protected by the > BGPSEC mechanism. Such an attack would probably be > pooh-poohed by all but tin foil hat folks, but it could > still be worth noting (maybe in section 8?) and as we've > seen recently, many of the tin foil hat fears turn out to be > realistic, sadly. Since you balloted "no objection", would I be right to think you won't = have a cow if we don't make this change? I confess to not knowing the = difference between AEAD and a hole in the ground nor do I understand the = attack you allude to, so at the least I would have to find someone to = either educate me or write the text for me. So far we haven't considered = confidentiality to be important for BGP security -- although you = reference encryption in connection with BGPSEC, BGPSEC is actually = entirely about integrity and authenticity and specifically disclaims = confidentiality, see draft-ietf-sidr-bgpsec-threats-09. If you feel strongly about having this covered, I'd appreciate if you = pointed me at someone who could help with education and/or specific = text. > I noted a few nitty nits: >=20 > - section 2: AFI/SAFI are used without expansion Will fix. > - 3.d: "well-known mandatory attributes" sort of yells for a > reference, doesn't it. At first I was going to agree with you, but then I reminded myself that = the entirety of section 3 is a set of amendments to RFC 4271, Section = 6.3, and says so in its first paragraph. As such, one might think the = reference in the first paragraph ought to be sufficient. I'm not dead = set against the extra reference if you feel strongly, but it does seem = redundant so for now I'm not adding it. > - 3.e: "cases that specify" - specify where? I think you > mean in the updated RFCs but it might be nice to say that Actually we mean the cases enumerated in RFC 4271 Section 6.3, again as = indicated in the first paragraph. I do think this would be clear to = someone who had reviewed that reference (which I don't fault you for not = having done) so again, I'm going to refrain from repeating the reference = here unless you want to make a further case for it. > - 5: NRLI is expanded after 1st use Okay. Thanks for the comments, =96 John= From nobody Mon Apr 20 10:54:24 2015 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 855161A8AF7; Mon, 20 Apr 2015 10:54:20 -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 Z1ExeEMWFE_1; Mon, 20 Apr 2015 10:54:19 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0746.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::746]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD7AF1A8AF5; Mon, 20 Apr 2015 10:54:18 -0700 (PDT) Received: from CO2PR05MB730.namprd05.prod.outlook.com (10.141.228.15) by CO2PR05MB666.namprd05.prod.outlook.com (10.141.230.19) with Microsoft SMTP Server (TLS) id 15.1.136.25; Mon, 20 Apr 2015 17:54:00 +0000 Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none; Received: from cvincent-sslvpn-nc.jnpr.net (66.129.241.14) by CO2PR05MB730.namprd05.prod.outlook.com (10.141.228.15) with Microsoft SMTP Server (TLS) id 15.1.136.25; Mon, 20 Apr 2015 17:53:51 +0000 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "John G. Scudder" In-Reply-To: <20150310000753.14666.46982.idtracker@ietfa.amsl.com> Date: Mon, 20 Apr 2015 13:53:44 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20150310000753.14666.46982.idtracker@ietfa.amsl.com> To: Kathleen Moriarty X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [66.129.241.14] X-ClientProxiedBy: BY2PR12CA0017.namprd12.prod.outlook.com (25.160.121.27) To CO2PR05MB730.namprd05.prod.outlook.com (10.141.228.15) X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CO2PR05MB730; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CO2PR05MB666; X-Microsoft-Antispam-PRVS: X-Forefront-Antispam-Report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(377454003)(19580405001)(47776003)(50466002)(87976001)(53416004)(66066001)(19580395003)(46102003)(33656002)(76176999)(57306001)(42186005)(40100003)(83716003)(77096005)(36756003)(77156002)(62966003)(23746002)(230783001)(86362001)(2950100001)(50986999)(110136001)(82746002)(50226001)(92566002)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB730; H:cvincent-sslvpn-nc.jnpr.net; FPR:; SPF:None; MLV:sfv; LANG:en; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:CO2PR05MB730; BCL:0; PCL:0; RULEID:; SRVR:CO2PR05MB730; X-Forefront-PRVS: 05529C6FDB X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Apr 2015 17:53:51.2363 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB730 X-OriginatorOrg: juniper.net Archived-At: Cc: idr@ietf.org, rob.shakir@bt.com, draft-ietf-idr-error-handling.all@ietf.org, The IESG , idr-chairs@ietf.org Subject: Re: [Idr] Kathleen Moriarty's Yes on draft-ietf-idr-error-handling-18: (with COMMENT) 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, 20 Apr 2015 17:54:20 -0000 Hi Kathleen, On Mar 9, 2015, at 8:07 PM, Kathleen Moriarty = wrote: > My only comment would be to see if you could break the first paragraph = of > the security considerations into a few sentences. Maybe getting rid = of > the parens to help break out the additional sentences would help. Good point, thanks. Parentheses are the bane of my existence. How about = this? This specification addresses the vulnerability of a BGP speaker to a potential attack whereby a distant attacker can generate a malformed optional transitive attribute that is not recognized by intervening routers. Since the intervening routers do not recognize the attribute, they propagate it without checking it. When the malformed attribute arrives at a router that does recognize the given attribute type, that router resets the session over which it arrived. Since significant fan-out can occur between the attacker and the routers that do recognize the attribute type, this attack could potentially be particularly harmful. =96 John= From nobody Mon Apr 20 11:05:17 2015 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 E9CAF1B2CD3 for ; Mon, 20 Apr 2015 11:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.055 X-Spam-Level: X-Spam-Status: No, score=-99.055 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, USER_IN_WHITELIST=-100] 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 wPZh7s7lpxdI for ; Mon, 20 Apr 2015 11:05:15 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 03D291B2CCD for ; Mon, 20 Apr 2015 11:05:14 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=222.151.138.72; From: "Susan Hares" To: "'UTTARO, JAMES'" , "'Juan Alcaide'" , "'Alvaro Retana \(aretana\)'" References: <20150409140218.22830.31521.idtracker@ietfa.amsl.com> <02e401d072e4$4f5a1cc0$ee0e5640$@ndzh.com> <001f01d07b3f$13ee12f0$3bca38d0$@ndzh.com> In-Reply-To: Date: Mon, 20 Apr 2015 14:05:06 -0400 Message-ID: <00f701d07b94$89a4ce80$9cee6b80$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF4r1Z2HL4YFm8OUbIc3fl4NvJEkQMc7jnKAeHZrpYCMURyMwGvlBIDA1ULulwCf+QsT52QJdNQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: idr@ietf.org, jgralak@juniper.net Subject: Re: [Idr] I-D Action: draft-ietf-idr-as-migration-04.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, 20 Apr 2015 18:05:17 -0000 James: Can you explain what you'd like to see in the changes?=20 Sue=20 -----Original Message----- From: UTTARO, JAMES [mailto:ju1738@att.com]=20 Sent: Monday, April 20, 2015 8:44 AM To: 'Susan Hares'; 'Juan Alcaide'; 'Alvaro Retana (aretana)' Cc: 'idr@ietf.org'; 'jgralak@juniper.net' Subject: RE: [Idr] I-D Action: draft-ietf-idr-as-migration-04.txt What would be great is that the features that are being used are standardized across vendors. The current approach where each = implementation varies in behavior will make life difficult. =20 Jim Uttaro -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Monday, April 20, 2015 3:53 AM To: 'Juan Alcaide'; 'Alvaro Retana (aretana)' Cc: idr@ietf.org; jgralak@juniper.net Subject: Re: [Idr] I-D Action: draft-ietf-idr-as-migration-04.txt Juan:=20 Do you think something needs to change in this draft? This is the last = day of the WG adoiption call.=20 Sue=20 -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Juan Alcaide Sent: Thursday, April 16, 2015 5:27 PM To: Alvaro Retana (aretana) Cc: idr@ietf.org; jgralak@juniper.net; Susan Hares Subject: Re: [Idr] I-D Action: draft-ietf-idr-as-migration-04.txt Hi, Let me chip using a previous discussion inputs. When using local-as, Cisco prepends AS on inbound updates from eBGP = peers.=20 I understand Juniper prepends AS on outbounds updates towards eBGP = peers.=20 In most cases, Cisco approach is better. > > > > Consider > > > > > > > > R1 (AS1) ----(local-as 2) R2(AS3)--- R3(AS3) --- R4 (AS4) > > > > ebgp iBGP > > > > > > > > Cisco: > > > > > > > > R1: X > > > > R2: 2 X > > > > R3: 2 X > > > > R4: 3 2 X > > > > > > > > Juniper > > > > > > > > R1: X > > > > R2: X > > > > R3: 2 X > > > > R4: 3 2 X > > > > > > > > I think it's prefereable that R2 and R3 have the same AS-PATH.=20 Otherwise > > > > you can have inconsistent best-path decission inside AS3 -Juan On Thu, 9 Apr 2015, Alvaro Retana (aretana) wrote: > On 4/9/15, 12:43 PM, "Susan Hares" wrote: > >> Let me review the document and query Alvaro to make sure it addresses = >> his concerns. >> >> On re-doing WG LC, we can do this in parallel with the other reviews=20 >> I'll need to redo (security directorate, routing directorate,=20 >> ops-directorate and gen-art). I'll start both sequences at the same=20 >> time once I've heard from Alvaro. > > I=B9ll go read it, but my gut reaction is that we should go back = through=20 > (WGLC, etc.). > > Thanks! > > Alvaro. > > _______________________________________________ > 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 From nobody Mon Apr 20 11:32:34 2015 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 3F5581B3014; Mon, 20 Apr 2015 11:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 2X0cgp5IAT2i; Mon, 20 Apr 2015 11:32:28 -0700 (PDT) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7816D1B300B; Mon, 20 Apr 2015 11:32:28 -0700 (PDT) Received: by lbbuc2 with SMTP id uc2so137599581lbb.2; Mon, 20 Apr 2015 11:32:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dO8BG6ftorH4Wly8tCnxT95zgK6MFPwPJE4PYuFJtMQ=; b=m4n1SyrOD/nfdbOQDAXHNEmLPoRoajky2Qbb8sKJRxREgVW142gWmyjJjsXMf7MBB+ 31CJVNl9LyT0yCBaa3vO8RyLpH+EWrQKis6Ir8eUZ3jsC/NQc6jAMyVWUeFMvfHVrwYO 9VG0C3RMR227GXD+6gWp0vYMeb6RGPOplErV9L0wkwF2IaY0UhoHPUmvb3jStlkKJVLh GZ0bGY+aydLBi0CDO50Np7tTNbMJmPcTEgbl9MCmPAC0Gb2XZFFysacp89Z73yjM63rL EDnqvPGfJWYYKjEizFBF2wwxnYtvPqd3tZp2wvKjCo/nUTmclP0/SgGOBUdMfCgTzuth RHew== MIME-Version: 1.0 X-Received: by 10.152.19.199 with SMTP id h7mr17254092lae.32.1429554746958; Mon, 20 Apr 2015 11:32:26 -0700 (PDT) Received: by 10.112.11.199 with HTTP; Mon, 20 Apr 2015 11:32:26 -0700 (PDT) In-Reply-To: References: <20150310000753.14666.46982.idtracker@ietfa.amsl.com> Date: Mon, 20 Apr 2015 14:32:26 -0400 Message-ID: From: Kathleen Moriarty To: "John G. Scudder" Content-Type: multipart/alternative; boundary=089e014942aae1273905142c26c2 Archived-At: Cc: idr@ietf.org, rob.shakir@bt.com, draft-ietf-idr-error-handling.all@ietf.org, The IESG , idr-chairs@ietf.org Subject: Re: [Idr] Kathleen Moriarty's Yes on draft-ietf-idr-error-handling-18: (with COMMENT) 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, 20 Apr 2015 18:32:30 -0000 --089e014942aae1273905142c26c2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi John, On Mon, Apr 20, 2015 at 1:53 PM, John G. Scudder wrote: > Hi Kathleen, > > On Mar 9, 2015, at 8:07 PM, Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> wrote: > > > My only comment would be to see if you could break the first paragraph = of > > the security considerations into a few sentences. Maybe getting rid of > > the parens to help break out the additional sentences would help. > > Good point, thanks. Parentheses are the bane of my existence. How about > this? > > This specification addresses the vulnerability of a BGP speaker to a > potential attack whereby a distant attacker can generate a malformed > optional transitive attribute that is not recognized by intervening > routers. Since the intervening routers do not recognize the > attribute, they propagate it without checking it. When the malformed > attribute arrives at a router that does recognize the given attribute > type, that router resets the session over which it arrived. Since > significant fan-out can occur between the attacker and the routers > that do recognize the attribute type, this attack could potentially > be particularly harmful. > That's much easier to read, thank you! > > =E2=80=93 John --=20 Best regards, Kathleen --089e014942aae1273905142c26c2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi John,

On Mon, Apr 20, 2015 at 1:53 PM, John G. Scudder <jgs@juniper.ne= t> wrote:
Hi Kathleen,

On Mar 9, 2015, at 8:07 PM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:<= br>
> My only comment would be to see if you could break the first paragraph= of
> the security considerations into a few sentences.=C2=A0 Maybe getting = rid of
> the parens to help break out the additional sentences would help.

Good point, thanks. Parentheses are the bane of my existence. How ab= out this?

=C2=A0 =C2=A0This specification addresses the vulnerability of a BGP speake= r to a
=C2=A0 =C2=A0potential attack whereby a distant attacker can generate a mal= formed
=C2=A0 =C2=A0optional transitive attribute that is not recognized by interv= ening
=C2=A0 =C2=A0routers. Since the intervening routers do not recognize the =C2=A0 =C2=A0attribute, they propagate it without checking it. When the mal= formed
=C2=A0 =C2=A0attribute arrives at a router that does recognize the given at= tribute
=C2=A0 =C2=A0type, that router resets the session over which it arrived. Si= nce
=C2=A0 =C2=A0significant fan-out can occur between the attacker and the rou= ters
=C2=A0 =C2=A0that do recognize the attribute type, this attack could potent= ially
=C2=A0 =C2=A0be particularly harmful.

T= hat's much easier to read, thank you!=C2=A0

=E2=80=93 John


<= br>
--

Be= st regards,
Kathleen
--089e014942aae1273905142c26c2-- From nobody Mon Apr 20 11:33:13 2015 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 1063D1B3015 for ; Mon, 20 Apr 2015 11:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.625 X-Spam-Level: * X-Spam-Status: No, score=1.625 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 DYnzpsWHR1Ye for ; Mon, 20 Apr 2015 11:33:10 -0700 (PDT) Received: from cdcipgw01.twcable.com (cdcipgw01.twcable.com [165.237.91.110]) by ietfa.amsl.com (Postfix) with ESMTP id AA33B1B3014 for ; Mon, 20 Apr 2015 11:33:10 -0700 (PDT) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.11,610,1422939600"; d="scan'208";a="286419848" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdcipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 20 Apr 2015 14:24:46 -0400 Received: from PRVPEXVS10.corp.twcable.com ([10.136.163.41]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Mon, 20 Apr 2015 14:33:04 -0400 From: "George, Wes" To: "UTTARO, JAMES" , 'Susan Hares' Date: Mon, 20 Apr 2015 14:33:03 -0400 Thread-Topic: [Idr] I-D Action: draft-ietf-idr-as-migration-04.txt Thread-Index: AdB7mHAuqqjqMItETrybTXE1Lqmasw== Message-ID: References: <20150409140218.22830.31521.idtracker@ietfa.amsl.com> <02e401d072e4$4f5a1cc0$ee0e5640$@ndzh.com> <001f01d07b3f$13ee12f0$3bca38d0$@ndzh.com> 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.9.150325 acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "'idr@ietf.org'" Subject: Re: [Idr] I-D Action: draft-ietf-idr-as-migration-04.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, 20 Apr 2015 18:33:12 -0000 DQpPbiA0LzIwLzE1LCA4OjQ0IEFNLCAiVVRUQVJPLCBKQU1FUyIgPGp1MTczOEBhdHQuY29tPiB3 cm90ZToNCg0KDQo+V2hhdCB3b3VsZCBiZSBncmVhdCBpcyB0aGF0IHRoZSBmZWF0dXJlcyB0aGF0 IGFyZSBiZWluZyB1c2VkIGFyZQ0KPnN0YW5kYXJkaXplZCBhY3Jvc3MgdmVuZG9ycy4gVGhlIGN1 cnJlbnQgYXBwcm9hY2ggd2hlcmUgZWFjaA0KPmltcGxlbWVudGF0aW9uIHZhcmllcyBpbiBiZWhh dmlvciB3aWxsIG1ha2UgbGlmZSBkaWZmaWN1bHQuDQoNCldHXSBXaGlsZSBJIGFncmVlIHRoYXQg dGhpcyBjb3VsZCBwb3RlbnRpYWxseSBzaW1wbGlmeSB0aGluZ3MgZm9yDQpvcGVyYXRvcnMsIHRo ZSBJRVRGIGNhbid0IGZvcmNlIHRoYXQgdG8gaGFwcGVuLiBPbmx5IHRob3NlIHNwZWNpZnlpbmcN CndoaWNoIGZlYXR1cmVzIHRoZXkgcmVxdWlyZSBmcm9tIHRoZWlyIHZlbmRvcnMgYW5kIHNpZ25p bmcgdGhlIGxhcmdlDQpjaGVja3MgdG8gYnV5IHRoZSBraXQgY2FuIGRvIHRoYXQuIEFueW9uZSB3 aG8gd2lzaGVzIHRvIHVzZSBhbiBSRkMgYXMgYQ0KY2x1YiBhZ2FpbnN0IGEgdmVuZG9yIGlzIHdl bGNvbWUgdG8gZG8gc28sIGJ1dCBjaGFuZ2luZyB0aGUgbGFuZ3VhZ2UgaW4NCnRoZSBkb2N1bWVu dCB0byByZXF1aXJlIGNvbXBsaWFuY2Ugd2l0aCBvdXIgdmVyc2lvbiBvZiBhbHJlYWR5LWltcGxl bWVudGVkDQpmZWF0dXJlcyB0aGF0IGlzbid0IHJlcXVpcmVkIGZvciBpbnRlcm9wIHJlYXNvbnMg d2lsbCBub3QgYWN0dWFsbHkgaGF2ZQ0KYW55IGVmZmVjdC4NCg0KDQpUaGFua3MsDQoNCldlcw0K DQoNCkFueXRoaW5nIGJlbG93IHRoaXMgbGluZSBoYXMgYmVlbiBhZGRlZCBieSBteSBjb21wYW55 4oCZcyBtYWlsIHNlcnZlciwgSQ0KaGF2ZSBubyBjb250cm9sIG92ZXIgaXQuDQotLS0tLS0tLS0t LQ0KDQoNCg0KDQpUaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0cyBhdHRhY2htZW50cyBtYXkgY29u dGFpbiBUaW1lIFdhcm5lciBDYWJsZSBwcm9wcmlldGFyeSBpbmZvcm1hdGlvbiwgd2hpY2ggaXMg cHJpdmlsZWdlZCwgY29uZmlkZW50aWFsLCBvciBzdWJqZWN0IHRvIGNvcHlyaWdodCBiZWxvbmdp bmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1tYWlsIGlzIGludGVuZGVkIHNvbGVseSBm b3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hpY2ggaXQgaXMgYWRk cmVzc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IG9mIHRoaXMgRS1t YWlsLCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0aW9uLCBkaXN0 cmlidXRpb24sIGNvcHlpbmcsIG9yIGFjdGlvbiB0YWtlbiBpbiByZWxhdGlvbiB0byB0aGUgY29u dGVudHMgb2YgYW5kIGF0dGFjaG1lbnRzIHRvIHRoaXMgRS1tYWlsIGlzIHN0cmljdGx5IHByb2hp Yml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBFLW1h aWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgcGVy bWFuZW50bHkgZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYW55IGNvcHkgb2YgdGhpcyBFLW1haWwg YW5kIGFueSBwcmludG91dC4NCg== From nobody Mon Apr 20 12:34:30 2015 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 D8F0B1A8782 for ; Mon, 20 Apr 2015 12:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.054 X-Spam-Level: X-Spam-Status: No, score=-99.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 LG-IHX1H_2f3 for ; Mon, 20 Apr 2015 12:34:27 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 24F001A877C for ; Mon, 20 Apr 2015 12:34:26 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=222.151.138.72; From: "Susan Hares" To: Date: Mon, 20 Apr 2015 15:34:19 -0400 Message-ID: <015e01d07ba1$0042bff0$00c83fd0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_015F_01D07B7F.7933B800" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdB7oHZ7MpCy+WliQDeoG6G90Nwn3A== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [Idr] 2 week WG LC for draft-ietf-custom-decision (4/20 to 5/4/2015) 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, 20 Apr 2015 19:34:29 -0000 This is a multipart message in MIME format. ------=_NextPart_000_015F_01D07B7F.7933B800 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This begins a 2 week WG LC for the following draft: http://datatracker.ietf.org/doc/draft-ietf-idr-custom-decision The authors should comment on the existence of IPR on the list, and the availability of implementations. A set of questions for this WG LC are: 1) Is this custom-decision useful in networks? 2) Is there any concern regarding standardization or deployment regarding this standard? 3) Do you know if interoperable implementations? If so, can you share your experience regarding the interoperability. As always, it is important to indicate "support" or "no support" for the WG LC. Sue Hares and John Scudder ------=_NextPart_000_015F_01D07B7F.7933B800 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This = begins a 2 week WG LC for the following draft:

 

h= ttp://datatracker.ietf.org/doc/draft-ietf-idr-custom-decision

 

 

The authors = should comment on the existence of IPR on the list, and the availability = of implementations.  A set of questions for this WG LC are: =

 

1)      = Is this custom-decision useful in networks? =

2)      = Is there any concern regarding standardization = or deployment regarding this standard?

3)      = Do you know if interoperable implementations? If = so, can you share your experience regarding the interoperability. =

 

As always, it is important to indicate = “support” or “no support” for the WG LC. =

 

Sue Hares and John Scudder =  

------=_NextPart_000_015F_01D07B7F.7933B800-- From nobody Mon Apr 20 12:56:24 2015 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 56DF71A87A7; Mon, 20 Apr 2015 12:56:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 90W32i3uaE00; Mon, 20 Apr 2015 12:56:22 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BF2D1A87A4; Mon, 20 Apr 2015 12:56:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id F387FBE98; Mon, 20 Apr 2015 20:56:19 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ChBMIG8fYFYw; Mon, 20 Apr 2015 20:56:18 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.17.62]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E823FBE51; Mon, 20 Apr 2015 20:56:16 +0100 (IST) Message-ID: <553559DB.2030208@cs.tcd.ie> Date: Mon, 20 Apr 2015 20:56:11 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "John G. Scudder" References: <20150310141226.24491.44397.idtracker@ietfa.amsl.com> In-Reply-To: OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "idr@ietf. org" , rob.shakir@bt.com, draft-ietf-idr-error-handling.all@ietf.org, The IESG , idr-chairs@ietf.org Subject: Re: [Idr] Stephen Farrell's No Objection on draft-ietf-idr-error-handling-18: (with COMMENT) 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, 20 Apr 2015 19:56:23 -0000 Hiya, I do not and will not have any cows:-) On 20/04/15 18:46, John G. Scudder wrote: > Hi Stephen, > > I'm doing a final update of the draft to cover comments in IE SG > review. I'd like to discuss yours a bit. > > On Mar 10, 2015, at 10:12 AM, Stephen Farrell > wrote: > >> - There is a perhaps missing security consideration. I think this >> kind of protocol behaviour argues that any kind of BGPSEC >> encryption needs to use an AEAD ciphersuite. (Which we'd likely do >> these days anyway, so that's not a biggie.) The reason is if say >> CBC or a stream cipher were used, then an attacker could play with >> ciphertext is various ways that might interact with this error >> handling behaviour so as to expose information that is intended to >> be protected by the BGPSEC mechanism. Such an attack would probably >> be pooh-poohed by all but tin foil hat folks, but it could still be >> worth noting (maybe in section 8?) and as we've seen recently, many >> of the tin foil hat fears turn out to be realistic, sadly. > > Since you balloted "no objection", would I be right to think you > won't have a cow if we don't make this change? I confess to not > knowing the difference between AEAD and a hole in the ground nor do I > understand the attack you allude to, so at the least I would have to > find someone to either educate me or write the text for me. So far we > haven't considered confidentiality to be important for BGP security > -- although you reference encryption in connection with BGPSEC, > BGPSEC is actually entirely about integrity and authenticity and > specifically disclaims confidentiality, see > draft-ietf-sidr-bgpsec-threats-09. > > If you feel strongly about having this covered, I'd appreciate if you > pointed me at someone who could help with education and/or specific > text. I'd suggest this, but am fine if you prefer to omit it, or edit it: "The improved error handling of this specification could in theory interact badly with some now-known weaker cryptographic mechanisms should such be used in future to secure BGP. For example, if a (fictional) mechanism that did not supply data integrity was used, an attacker could manipulate ciphertext in any attempt to change or observe how the receiver reacts. Absent this specification, the BGP session would have been terminated, while with this specification the attacker could make potentially many attempts. While such a confidentiality-only mechanism would not be defined today, we have in the past seen mechanism definitions that result in similar though not as obviously exploitable vulnerabilities. [RFC7366] The approach recommended today to avoid such issues is to prefer use of Authenticated Encryption with Additional Data (AEAD) ciphers [RFC5116] and (thus) to discard messages that don't verify." Cheers, S. PS: Other stuff below also does not produce bovine reactions. > >> I noted a few nitty nits: >> >> - section 2: AFI/SAFI are used without expansion > > Will fix. > >> - 3.d: "well-known mandatory attributes" sort of yells for a >> reference, doesn't it. > > At first I was going to agree with you, but then I reminded myself > that the entirety of section 3 is a set of amendments to RFC 4271, > Section 6.3, and says so in its first paragraph. As such, one might > think the reference in the first paragraph ought to be sufficient. > I'm not dead set against the extra reference if you feel strongly, > but it does seem redundant so for now I'm not adding it. > >> - 3.e: "cases that specify" - specify where? I think you mean in >> the updated RFCs but it might be nice to say that > > Actually we mean the cases enumerated in RFC 4271 Section 6.3, again > as indicated in the first paragraph. I do think this would be clear > to someone who had reviewed that reference (which I don't fault you > for not having done) so again, I'm going to refrain from repeating > the reference here unless you want to make a further case for it. > >> - 5: NRLI is expanded after 1st use > > Okay. > > Thanks for the comments, > > – John > From nobody Mon Apr 20 13:21:52 2015 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 B14AA1B3079 for ; Mon, 20 Apr 2015 13:21:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9QZzvKmRlrlH for ; Mon, 20 Apr 2015 13:21:47 -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 DE1E51B3070 for ; Mon, 20 Apr 2015 13:21:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4077; q=dns/txt; s=iport; t=1429561301; x=1430770901; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=xrPAXk+SAuX9CJ5b/4WmvimLmIEJOuJ7y+ID293OCbM=; b=LlZ5yq1p72+OJZBTBcUeGFTyoP1ASrcoUWMt7F8t8kOyvRSf6OZTIhfD orUqidPH2+tZETJnpUYNW94Cd2R7kA/nG91oxgShsMC5zpjFkd6oPo+mb BXSSZiGR62ADQjWu0BBYgVN2cB6yEDEPGVM5ou7XUp7Z9WgUyPXSGlHJP 0=; X-IronPort-AV: E=Sophos;i="5.11,610,1422921600"; d="scan'208";a="413421478" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-4.cisco.com with ESMTP; 20 Apr 2015 20:21:40 +0000 Received: from clubhouse-1.cisco.com (clubhouse-1.cisco.com [64.100.21.13]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t3KKLdxn005011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Apr 2015 20:21:40 GMT Date: Mon, 20 Apr 2015 16:21:38 -0400 (EDT) From: Juan Alcaide To: "UTTARO, JAMES" In-Reply-To: Message-ID: References: <20150409140218.22830.31521.idtracker@ietfa.amsl.com> <02e401d072e4$4f5a1cc0$ee0e5640$@ndzh.com> <001f01d07b3f$13ee12f0$3bca38d0$@ndzh.com> User-Agent: Alpine 2.00 (GSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-1691952160-1429561299=:29478" Archived-At: Cc: "'jgralak@juniper.net'" , 'Susan Hares' , "'idr@ietf.org'" Subject: Re: [Idr] I-D Action: draft-ietf-idr-as-migration-04.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, 20 Apr 2015 20:21:48 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-1691952160-1429561299=:29478 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Hi, (on PTO with limitted internet access) Possible updates: - As we discussed, for ebgp incomming updates for local-as it makes more sense to prepend AS on incomming updates. I think we shoudl describe this option as the default one and any other one as a variation. - Cisco plans to implement the internal BGP alias as ibgp local-as dual-as. So perhaps we can choose an agnostic name and explain both Juniper and Cisco names. - About "the speaker SHOULD send BGP OPEN using the globally configured ASN first". I think we should emphasize how the FSM gets modified. It may be implicit, but it may save us from some interoperabilities problems. My ideas: 1) In any case, my-AS and your-AS MUST be equal on any case. 2) Define what to do if you send global-AS but you receive local-AS. Probably respond wiht "Bad Peer AS". But I'd like to understand what Juniper is doing as well. 3) Note that without an agreement of the AS that is used first (both peers could decide to use first the local-as if they are both configured as such). This would happen in 2) -Juan On Mon, 20 Apr 2015, UTTARO, JAMES wrote: > What would be great is that the features that are being used are standardized across vendors. The current approach where each implementation varies in behavior will make life difficult. > > Jim Uttaro > > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares > Sent: Monday, April 20, 2015 3:53 AM > To: 'Juan Alcaide'; 'Alvaro Retana (aretana)' > Cc: idr@ietf.org; jgralak@juniper.net > Subject: Re: [Idr] I-D Action: draft-ietf-idr-as-migration-04.txt > > Juan: > > Do you think something needs to change in this draft? This is the last day > of the WG adoiption call. > > Sue > > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Juan Alcaide > Sent: Thursday, April 16, 2015 5:27 PM > To: Alvaro Retana (aretana) > Cc: idr@ietf.org; jgralak@juniper.net; Susan Hares > Subject: Re: [Idr] I-D Action: draft-ietf-idr-as-migration-04.txt > > Hi, > > Let me chip using a previous discussion inputs. > > When using local-as, Cisco prepends AS on inbound updates from eBGP peers. > I understand Juniper prepends AS on outbounds updates towards eBGP peers. > In most cases, Cisco approach is better. > >>>>> Consider >>>>> >>>>> R1 (AS1) ----(local-as 2) R2(AS3)--- R3(AS3) --- R4 (AS4) >>>>> ebgp iBGP >>>>> >>>>> Cisco: >>>>> >>>>> R1: X >>>>> R2: 2 X >>>>> R3: 2 X >>>>> R4: 3 2 X >>>>> >>>>> Juniper >>>>> >>>>> R1: X >>>>> R2: X >>>>> R3: 2 X >>>>> R4: 3 2 X >>>>> >>>>> I think it's prefereable that R2 and R3 have the same AS-PATH. > Otherwise >>>>> you can have inconsistent best-path decission inside AS3 > > > > -Juan > > On Thu, 9 Apr 2015, Alvaro Retana (aretana) wrote: > >> On 4/9/15, 12:43 PM, "Susan Hares" wrote: >> >>> Let me review the document and query Alvaro to make sure it addresses >>> his concerns. >>> >>> On re-doing WG LC, we can do this in parallel with the other reviews >>> I'll need to redo (security directorate, routing directorate, >>> ops-directorate and gen-art). I'll start both sequences at the same >>> time once I've heard from Alvaro. >> >> I¹ll go read it, but my gut reaction is that we should go back through >> (WGLC, etc.). >> >> Thanks! >> >> Alvaro. >> >> _______________________________________________ >> 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 > ---559023410-1691952160-1429561299=:29478-- From nobody Mon Apr 20 13:59:11 2015 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 6F8251B31B3 for ; Mon, 20 Apr 2015 13:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.054 X-Spam-Level: X-Spam-Status: No, score=-99.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 jLiD0g1sF7rs for ; Mon, 20 Apr 2015 13:59:06 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA691B31AE for ; Mon, 20 Apr 2015 13:59:06 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=222.151.138.72; From: "Susan Hares" To: Date: Mon, 20 Apr 2015 16:58:58 -0400 Message-ID: <01a801d07bac$d4756880$7d603980$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01A9_01D07B8B.4D654F20" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdB7qgBSfoAujn4fTbOJuE6lxY/Vnw== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [Idr] 2 week WG LC for draft-ietf-idr-rtc-no-rt 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, 20 Apr 2015 20:59:08 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01A9_01D07B8B.4D654F20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This begins a 2 week WG LC for draft-ietf-idr-rtc-no-rt (4/20/2015 to 5/4/2015). You can see the draft at: http://datatracker.ietf.org/doc/draft-ietf-idr-rtc-no-rt/ Other current drafts for Route Targets in IDR are: http://datatracker.ietf.org/doc/draft-ietf-idr-rtc-hierarchical-rr/ http://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ipv6-rt-constrain/ Appropriate questions for this WG LC are: 1) Does this default manner handling routes with no RTCs provide good operational BGP for networks you are aware of? 2) Does this method of default work for you: RTC applied + MDT-SAFI (SAFI=66) implies routes without RTs are distributed RTC applied + MCAST-VPN (SAFI=6) implies routes without RTs are distributed RTC applied + any other address family - implies routes without RTs are not distributed Should IANA create a registry which indicates the status of RTC application or is the draft sufficient: Other IDR drafts on RT constraints are: http://datatracker.ietf.org/doc/draft-ietf-idr-rtc-hierarchical-rr/ http://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ipv6-rt-constrain/ Please indicate in your message discussing this approach an indication of "support" or "no support". Sue Hares ------=_NextPart_000_01A9_01D07B8B.4D654F20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

This begins = a 2 week WG LC for draft-ietf-idr-rtc-no-rt (4/20/2015 to = 5/4/2015).  You can see the draft at:

 

http:/= /datatracker.ietf.org/doc/draft-ietf-idr-rtc-no-rt/

 

Other = current drafts for Route Targets in IDR are:

 

http://datatracker.ietf.org/doc/draft-ietf-idr-rtc-hierarchical-rr/

http://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ipv6-rt-constrai= n/

 

Appropriate questions for this WG LC are: =

 

1)      = Does this default manner handling routes with no = RTCs provide good operational BGP for networks you are aware of? =

2)      = Does this method of default work for you: =

 

RTC applied + MDT-SAFI =   (SAFI=3D66) implies routes without RTs are = distributed

         &= nbsp;      RTC applied + MCAST-VPN (SAFI=3D6) = implies routes without RTs are distributed

         &= nbsp;      RTC applied + any other address = family – implies routes without RTs are not = distributed

 

Should IANA create a registry which indicates the = status of RTC application or is the draft sufficient:

 

Other IDR = drafts on RT constraints are:

 

http://datatracker.ietf.org/doc/draft-ietf-idr-rtc-hierarchical-rr/

http://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ipv6-rt-constrai= n/

 

Please indicate in your message discussing this = approach an indication of “support” or “no = support”.

 

Sue Hares =

------=_NextPart_000_01A9_01D07B8B.4D654F20-- From nobody Tue Apr 21 07:05:04 2015 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 E303B1ACD44; Tue, 21 Apr 2015 07:05:02 -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 HLyBT9vGnzBt; Tue, 21 Apr 2015 07:04:56 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0112.outbound.protection.outlook.com [65.55.169.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DD891ACD5A; Tue, 21 Apr 2015 07:04:52 -0700 (PDT) Received: from BLUPR05MB722.namprd05.prod.outlook.com (10.141.207.150) by BLUPR05MB420.namprd05.prod.outlook.com (10.141.27.26) with Microsoft SMTP Server (TLS) id 15.1.136.25; Tue, 21 Apr 2015 14:04:51 +0000 Authentication-Results: cs.tcd.ie; dkim=none (message not signed) header.d=none; Received: from cvincent-sslvpn-nc.jnpr.net (66.129.241.14) by BLUPR05MB722.namprd05.prod.outlook.com (10.141.207.150) with Microsoft SMTP Server (TLS) id 15.1.148.15; Tue, 21 Apr 2015 14:04:47 +0000 Content-Type: multipart/mixed; boundary="Apple-Mail=_2540DD39-1C7B-4883-8DB0-8C09F92C7E8D" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "John G. Scudder" In-Reply-To: <553559DB.2030208@cs.tcd.ie> Date: Tue, 21 Apr 2015 10:04:36 -0400 Message-ID: <06D967F4-BA75-40F1-A1D2-7C081001500E@juniper.net> References: <20150310141226.24491.44397.idtracker@ietfa.amsl.com> <553559DB.2030208@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [66.129.241.14] X-ClientProxiedBy: CO2PR04CA033.namprd04.prod.outlook.com (10.141.240.161) To BLUPR05MB722.namprd05.prod.outlook.com (10.141.207.150) X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB722; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB420; X-Microsoft-Antispam-PRVS: X-Forefront-Antispam-Report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(377454003)(24454002)(51704005)(33656002)(77156002)(87976001)(40100003)(2950100001)(46102003)(83716003)(62966003)(57306001)(92566002)(77096005)(42186005)(5890100001)(36756003)(568964001)(230783001)(86362001)(50226001)(19580395003)(4610100001)(122386002)(84326002)(53416004)(19580405001)(66066001)(512944002)(50986999)(76176999)(82746002)(110136001)(42262002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB722; H:cvincent-sslvpn-nc.jnpr.net; FPR:; SPF:None; MLV:sfv; LANG:en; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:BLUPR05MB722; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB722; X-Forefront-PRVS: 0553CBB77A X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Apr 2015 14:04:47.0292 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB722 X-OriginatorOrg: juniper.net Archived-At: Cc: "idr@ietf. org" , rob.shakir@bt.com, draft-ietf-idr-error-handling.all@ietf.org, The IESG , "" Subject: Re: [Idr] Stephen Farrell's No Objection on draft-ietf-idr-error-handling-18: (with COMMENT) 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, 21 Apr 2015 14:05:03 -0000 --Apple-Mail=_2540DD39-1C7B-4883-8DB0-8C09F92C7E8D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="windows-1252" Stephen, thanks very much for the text. All, unless there are any objections, I'd like to adopt Stephen's text = as written. I've attached a version 19 that I believe takes in all the = requested and agreed-to changes. I'll post it at the end of today unless = there are further comments. =96 John On Apr 20, 2015, at 3:56 PM, Stephen Farrell = wrote: > I'd suggest this, but am fine if you prefer to omit it, or edit it: >=20 > "The improved error handling of this specification could in theory > interact badly with some now-known weaker cryptographic mechanisms > should such be used in future to secure BGP. For example, if a > (fictional) mechanism that did not supply data integrity was used, > an attacker could manipulate ciphertext in any attempt to change > or observe how the receiver reacts. Absent this specification, the > BGP session would have been terminated, while with this specification > the attacker could make potentially many attempts. While such a > confidentiality-only mechanism would not be defined today, we have > in the past seen mechanism definitions that result in similar though > not as obviously exploitable vulnerabilities. [RFC7366] The approach > recommended today to avoid such issues is to prefer use of > Authenticated Encryption with Additional Data (AEAD) ciphers [RFC5116] > and (thus) to discard messages that don't verify." --Apple-Mail=_2540DD39-1C7B-4883-8DB0-8C09F92C7E8D Content-Disposition: attachment; filename="draft-ietf-idr-error-handling-19.txt" Content-Type: text/plain; x-unix-mode=0644; name="draft-ietf-idr-error-handling-19.txt" Content-Transfer-Encoding: quoted-printable Internet Engineering Task Force E. Chen, Ed. Internet-Draft Cisco Systems, Inc. Updates: 1997, 4271, 4360, 4456, 4760, J. Scudder, Ed. 5543, 5701, 6368 (if approved) Juniper Networks Intended status: Standards Track P. Mohapatra Expires: October 23, 2015 Sproute Networks K. Patel Cisco Systems, Inc. April 21, 2015 Revised Error Handling for BGP UPDATE Messages draft-ietf-idr-error-handling-19 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, because 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 and 6368. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on October 23, 2015. Chen, et al. Expires October 23, 2015 [Page 1] =0C Internet-Draft Revised Error Handling for BGP April 2015 Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. Error-Handling Approaches . . . . . . . . . . . . . . . . . . 4 3. Revision to BGP UPDATE Message Error Handling . . . . . . . . 4 4. Attribute Length Fields . . . . . . . . . . . . . . . . . . . 6 5. Parsing of Network Layer Reachability Information (NLRI) Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Encoding NLRI . . . . . . . . . . . . . . . . . . . . . . 7 5.2. Missing NLRI . . . . . . . . . . . . . . . . . . . . . . 7 5.3. Syntactic Correctness of NLRI Fields . . . . . . . . . . 8 5.4. Typed NLRI . . . . . . . . . . . . . . . . . . . . . . . 8 6. Operational Considerations . . . . . . . . . . . . . . . . . 9 7. Error Handling Procedures for Existing Attributes . . . . . . 10 7.1. ORIGIN . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.2. AS_PATH . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.3. NEXT_HOP . . . . . . . . . . . . . . . . . . . . . . . . 11 7.4. MULTI_EXIT_DISC . . . . . . . . . . . . . . . . . . . . . 11 7.5. LOCAL_PREF . . . . . . . . . . . . . . . . . . . . . . . 11 7.6. ATOMIC_AGGREGATE . . . . . . . . . . . . . . . . . . . . 11 Chen, et al. Expires October 23, 2015 [Page 2] =0C Internet-Draft Revised Error Handling for BGP April 2015 7.7. AGGREGATOR . . . . . . . . . . . . . . . . . . . . . . . 12 7.8. Community . . . . . . . . . . . . . . . . . . . . . . . . 12 7.9. ORIGINATOR_ID . . . . . . . . . . . . . . . . . . . . . . 12 7.10. CLUSTER_LIST . . . . . . . . . . . . . . . . . . . . . . 12 7.11. MP_REACH_NLRI . . . . . . . . . . . . . . . . . . . . . . 13 7.12. MP_UNREACH_NLRI . . . . . . . . . . . . . . . . . . . . . 13 7.13. Traffic Engineering path attribute . . . . . . . . . . . 13 7.14. Extended Community . . . . . . . . . . . . . . . . . . . 13 7.15. IPv6 Address Specific BGP Extended Community Attribute . 14 7.16. ATTR_SET . . . . . . . . . . . . . . . . . . . . . . . . 14 8. Guidance for Authors of BGP Specifications . . . . . . . . . 14 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 12.1. Normative References . . . . . . . . . . . . . . . . . . 16 12.2. Informative References . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 1. Introduction According to the base BGP specification [RFC4271], 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, because a session reset impacts not only routes with the offending attribute, but also other, valid routes exchanged over the session. In the case of optional transitive attributes, the behavior is especially troublesome and may present a potential security vulnerability. This is because attributes may have been propagated without being checked by intermediate routers that don't recognize the attributes. In effect, the attributes may have been tunneled; and when they reach a router that recognizes and checks the attributes, the session that is reset may not be associated with the router that is at fault. To make matters worse, in such cases although the problematic attributes may have originated with a single update transmitted by a single BGP speaker, by the time they encounter a router that checks them they may have been replicated many times, and thus may cause the reset of many peering sessions. Thus the damage inflicted may be multiplied manyfold. The goal for revising the error handling for UPDATE messages is to minimize the impact on routing by a malformed UPDATE message, while maintaining protocol correctness to the extent possible. This can be achieved largely by maintaining the established session and keeping the valid routes exchanged, but removing the routes carried in the malformed UPDATE from the routing system. Chen, et al. Expires October 23, 2015 [Page 3] =0C Internet-Draft Revised Error Handling for BGP April 2015 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. Specifically, the error handling procedures of [RFC1997], [RFC4271], [RFC4360], [RFC4456], [RFC4760], [RFC5543], [RFC5701], and [RFC6368] are revised. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Error-Handling Approaches In this document we refer to four different approaches to handle errors found in BGP path attributes. They are as follows (listed in order, from the one with the "strongest" action to the one with the "weakest" action): o Session reset: This is the approach used throughout the base BGP specification [RFC4271], where a NOTIFICATION is sent and the session terminated. o AFI/SAFI disable: [RFC4760] specifies a procedure for disabling a particular AFI/SAFI (Address Family Identifier and Subsequent Address Family Identifier). o Treat-as-withdraw: In this approach, the UPDATE message containing the path attribute in question MUST be treated as though all contained routes had been withdrawn just as if they had been listed in the WITHDRAWN ROUTES field (or in the MP_UNREACH_NLRI attribute if appropriate) of the UPDATE message, thus causing them to be removed from the Adj-RIB-In according to the procedures of [RFC4271]. o Attribute discard: In this approach the malformed attribute MUST be discarded and the UPDATE message continues to be processed. This approach MUST NOT be used except in the case of an attribute that has no effect on route selection or installation. 3. Revision to BGP UPDATE Message Error Handling This specification amends [RFC4271] Section 6.3 in a number of ways. See also Section 7 for treatment of specific path attributes. a. The first paragraph is revised as follows: Chen, et al. Expires October 23, 2015 [Page 4] =0C Internet-Draft Revised Error Handling for BGP April 2015 Old Text: All errors detected while processing the UPDATE message MUST be indicated by sending the NOTIFICATION message with the Error Code UPDATE Message Error. The error subcode elaborates on the specific nature of the error. New Text: An error detected while processing the UPDATE message for which a session reset is specified MUST be indicated by sending the NOTIFICATION message with the Error Code UPDATE Message Error. The error subcode elaborates on the specific nature of the error. b. Error handling for the following case remains unchanged: If the Withdrawn Routes Length or Total Attribute Length is too large (i.e., if Withdrawn Routes Length + Total Attribute Length + 23 exceeds the message Length), then the Error Subcode MUST be set to Malformed Attribute List. c. Attribute Flag error handling is revised as follows: Old Text: If any recognized attribute has Attribute Flags that conflict with the Attribute Type Code, then the Error Subcode MUST be set to Attribute Flags Error. The Data field MUST contain the erroneous attribute (type, length, and value). New Text: If the value of either the Optional or Transitive bits in the Attribute Flags is in conflict with their specified values, then the attribute MUST be treated as malformed and the treat-as-withdraw approach used, unless the specification for the attribute mandates different handling for incorrect Attribute Flags. d. If any of the well-known mandatory attributes are not present in an UPDATE message, then "treat-as-withdraw" MUST be used. (Note that [RFC4760] reclassifies NEXT_HOP as what is effectively discretionary.) Chen, et al. Expires October 23, 2015 [Page 5] =0C Internet-Draft Revised Error Handling for BGP April 2015 e. "Treat-as-withdraw" MUST be used for the cases that specify a session reset and involve any of the attributes ORIGIN, AS_PATH, NEXT_HOP, MULTI_EXIT_DISC, or LOCAL_PREF. f. "Attribute discard" MUST be used for any of the cases that specify a session reset and involve ATOMIC_AGGREGATE or AGGREGATOR. g. If the MP_REACH_NLRI attribute or the MP_UNREACH_NLRI [RFC4760] attribute appears more than once in the UPDATE message, then a NOTIFICATION message MUST be sent with the Error Subcode "Malformed Attribute List". If any other attribute (whether recognized or unrecognized) appears more than once in an UPDATE message, then all the occurrences of the attribute other than the first one SHALL be discarded and the UPDATE message continue to be processed. h. When multiple attribute errors exist in an UPDATE message, if the same approach (either "session reset", "treat-as-withdraw" or "attribute discard") is specified for the handling of these malformed attributes, then the specified approach MUST be used. Otherwise the approach with the strongest action MUST be used. i. The Withdrawn Routes field MUST be checked for syntactic correctness in the same manner as the NLRI (network layer reachability information) field. This is discussed further below, and in Section 5.3. j. Finally, we observe that in order to use the approach of "treat- as-withdraw", the entire NLRI field and/or the MP_REACH_NLRI and MP_UNREACH_NLRI attributes need to be successfully parsed -- what this entails is discussed in more detail in Section 5. If this is not possible, the procedures of [RFC4271] and/or [RFC4760] continue to apply, meaning that the "session reset" approach (or the "AFI/SAFI disable" approach) MUST be followed. 4. Attribute Length Fields There are two error cases in which the Total Attribute Length value can be in conflict with the enclosed path attributes, which themselves carry length values. In the "overrun" case, as the enclosed path attributes are parsed, the length of the last encountered path attribute would cause the Total Attribute Length to be exceeded. In the "underrun" case, as the enclosed path attributes are parsed, after the last successfully-parsed attribute, fewer than three octets remain, or fewer than four octets, if the Attribute Flags field has the Extended Length bit set -- that is, there remains unconsumed data in the path attributes but yet insufficient data to Chen, et al. Expires October 23, 2015 [Page 6] =0C Internet-Draft Revised Error Handling for BGP April 2015 encode a single minimum-sized path attribute. In either of these cases, an error condition exists and the treat-as-withdraw approach MUST be used (unless some other, more severe error is encountered dictating a stronger approach), and the Total Attribute Length MUST be relied upon to enable the beginning of the NLRI field to be located. For all path attributes other than those specified as having an attribute length that may be zero, it SHALL be considered a syntax error for the attribute to have a length of zero. (Of the path attributes considered in this specification, only AS_PATH and ATOMIC_AGGREGATE may validly have an attribute length of zero.) 5. Parsing of Network Layer Reachability Information (NLRI) Fields 5.1. Encoding NLRI To facilitate the determination of the NLRI field in an UPDATE with a malformed attribute: o The MP_REACH_NLRI or MP_UNREACH_NLRI attribute (if present) SHALL be encoded as the very first path attribute in an UPDATE. o An UPDATE message MUST NOT contain more than one of the following: non-empty Withdrawn Routes field, non-empty Network Layer Reachability Information field, MP_REACH_NLRI attribute, and MP_UNREACH_NLRI attribute. Since older BGP speakers may not implement these restrictions, an implementation MUST still be prepared to receive these fields in any position or combination. If the encoding of [RFC4271] is used, the NLRI field for the IPv4 unicast address family is carried immediately following all the attributes in an UPDATE. When such an UPDATE is received, we observe that the NLRI field can be determined using the "Message Length", "Withdrawn Route Length" and "Total Attribute Length" (when they are consistent) carried in the message instead of relying on the length of individual attributes in the message. 5.2. Missing NLRI [RFC4724] specifies an End-of-RIB message ("EoR") that can be encoded as an UPDATE message that contains only a MP_UNREACH_NLRI attribute that encodes no NLRI (it can also be a completely empty UPDATE message in the case of the "legacy" encoding). In all other well- specified cases, an UPDATE either carries only withdrawn routes (either in the Withdrawn Routes field, or the MP_UNREACH_NLRI Chen, et al. Expires October 23, 2015 [Page 7] =0C Internet-Draft Revised Error Handling for BGP April 2015 attribute), or it advertises reachable routes (either in the Network Layer Reachability Information field, or the MP_REACH_NLRI attribute). Thus, if an UPDATE message is encountered that does contain path attributes other than MP_UNREACH_NLRI and doesn't encode any reachable NLRI, we cannot be confident that the NLRI have been successfully parsed as Section 3 (j) requires. For this reason, if any path attribute errors are encountered in such an UPDATE message, and if any encountered error specifies an error-handling approach other than "attribute discard", then the "session reset" approach MUST be used. 5.3. Syntactic Correctness of NLRI Fields The NLRI field or Withdrawn Routes field SHALL be considered "syntactically incorrect" if either of the following are true: o The length of any of the included NLRI is greater than 32, o When parsing NLRI contained in the field, the length of the last NLRI found exceeds the amount of unconsumed data remaining in the field. Similarly, the MP_REACH_NLRI or MP_UNREACH_NLRI attribute of an update SHALL be considered to be incorrect if any of the following are true: o The length of any of the included NLRI is inconsistent with the given AFI/SAFI (for example, if an IPv4 NLRI has a length greater than 32 or an IPv6 NLRI has a length greater than 128), o When parsing NLRI contained in the attribute, the length of the last NLRI found exceeds the amount of unconsumed data remaining in the attribute. o The attribute flags of the attribute are inconsistent with those specified in [RFC4760]. o The length of the MP_UNREACH_NLRI attribute is less than 3, or the length of the MP_REACH_NLRI attribute is less than 5. 5.4. Typed NLRI Certain address families, for example MCAST-VPN [RFC6514], MCAST-VPLS [RFC7117] and EVPN [RFC7432] have NLRI that are typed. Since supported type values within the address family are not expressed in the MP-BGP capability [RFC4760], it is possible for a BGP speaker to Chen, et al. Expires October 23, 2015 [Page 8] =0C Internet-Draft Revised Error Handling for BGP April 2015 advertise support for the given address family and sub-address family while still not supporting a particular type of NLRI within that AFI/ SAFI. A BGP speaker advertising support for such a typed address family MUST handle routes with unrecognized NLRI types within that address family by discarding them, unless the relevant specification for that address family specifies otherwise. 6. Operational Considerations Although the "treat-as-withdraw" error-handling behavior defined in Section 2 makes every effort to preserve BGP's correctness, we note that if an UPDATE received on an IBGP session is subjected to this treatment, inconsistent routing within the affected Autonomous System may result. The consequences of inconsistent routing can include long-lived forwarding loops and black holes. While lamentable, this issue is expected to be rare in practice, and, more importantly, is seen as less problematic than the session-reset behavior it replaces. When a malformed attribute is indeed detected over an IBGP session, we recommend that routes with the malformed attribute be identified and traced back to the ingress router in the network where the routes were sourced or received externally, and then a filter be applied on the ingress router to prevent the routes from being sourced or received. This will help maintain routing consistency in the network. Even if inconsistent routing does not arise, the "treat-as-withdraw" behavior can cause either complete unreachability or sub-optimal routing for the destinations whose routes are carried in the affected UPDATE message. Note that "treat-as-withdraw" is different from discarding an UPDATE message. The latter violates the basic BGP principle of incremental update, and could cause invalid routes to be kept. Because of these potential issues, a BGP speaker must provide debugging facilities to permit issues caused by a malformed attribute to be diagnosed. At a minimum, such facilities must include logging an error listing the NLRI involved, and containing the entire malformed UPDATE message when such an attribute is detected. The malformed UPDATE message should be analyzed, and the root cause should be investigated. Section 8 mentions that attribute discard should not be used in cases where "the attribute in question has or may have an effect on route selection." Although all cases that specify attribute discard in Chen, et al. Expires October 23, 2015 [Page 9] =0C Internet-Draft Revised Error Handling for BGP April 2015 this document do not affect route selection by default, in principle routing policies could be written that affect selection based on such an attribute. Operators should take care when writing such policies to consider the possible consequences of an attribute discard. (In general, as long as such policies are only applied to external BGP sessions, correctness issues are not expected to arise.) 7. Error Handling Procedures for Existing Attributes In the following subsections, we elaborate on the conditions for error-checking various path attributes, and specify what approach(es) should be used to handle malformations. It is possible that implementations may apply other error checks not contemplated here. If so, the error handling approach given here should generally be applied. This section addresses all path attributes that are defined at the time of this writing, that were not defined with error-handling consistent with Section 8, and that are not marked as "deprecated" in [IANA-BGP-ATTRS]. Attributes 17 (AS4_PATH), 18 (AS4_AGGREGATOR), 22 (PMSI_TUNNEL), 23 (Tunnel Encapsulation Attribute), 26 (AIGP), 27 (PE Distinguisher Labels) and 29 (BGP-LS Attribute) do have error- handling consistent with Section 8 and thus are not further discussed herein. Attributes 11 (DPA), 12 (ADVERTISER), 13 (RCID_PATH / CLUSTER_ID), 19 (SAFI Specific Attribute), 20 (Connector Attribute), 21 (AS_PATHLIMIT) and 28 (BGP Entropy Label Capability Attribute) are deprecated and thus are not further discussed herein. 7.1. ORIGIN The attribute is considered malformed if its length is not 1, or it has an undefined value [RFC4271]. An UPDATE message with a malformed ORIGIN attribute SHALL be handled using the approach of "treat-as-withdraw". 7.2. AS_PATH An AS_PATH is considered malformed if an unrecognized segment type is encountered, or if it contains a malformed segment. A segment is considered malformed if any of the following obtains: o There is an overrun, where the path segment length field of the last segment encountered would cause the Attribute Length to be exceeded. o There is an underrun, where after the last successfully-parsed segment, there is only a single octet remaining (that is, there is Chen, et al. Expires October 23, 2015 [Page 10] =0C Internet-Draft Revised Error Handling for BGP April 2015 not enough unconsumed data to provide even an empty segment header). o It has a path segment length field of zero. An UPDATE message with a malformed AS_PATH attribute SHALL be handled using the approach of "treat-as-withdraw". [RFC4271] also says that an implementation optionally "MAY check whether the leftmost ... AS in the AS_PATH attribute is equal to the autonomous system number of the peer that sent the message". A BGP implementation SHOULD also handle routes that violate this check using "treat-as-withdraw", but MAY follow the session reset behavior if configured to do so. 7.3. NEXT_HOP The attribute is considered malformed if its length is not 4 [RFC4271]. An UPDATE message with a malformed NEXT_HOP attribute SHALL be handled using the approach of "treat-as-withdraw". 7.4. MULTI_EXIT_DISC The attribute is considered malformed if its length is not 4 [RFC4271]. An UPDATE message with a malformed MULTI_EXIT_DISC attribute SHALL be handled using the approach of "treat-as-withdraw". 7.5. LOCAL_PREF The error handling of [RFC4271] is revised as follows. o If the LOCAL_PREF attribute is received from an external neighbor, it SHALL be discarded using the approach of "attribute discard", or o if received from an internal neighbor, it SHALL be considered malformed if its length is not equal to 4. If malformed, the UPDATE SHALL be handled using the approach of "treat-as-withdraw". 7.6. ATOMIC_AGGREGATE The attribute SHALL be considered malformed if its length is not 0 [RFC4271]. Chen, et al. Expires October 23, 2015 [Page 11] =0C Internet-Draft Revised Error Handling for BGP April 2015 An UPDATE message with a malformed ATOMIC_AGGREGATE attribute SHALL be handled using the approach of "attribute discard". 7.7. AGGREGATOR The error conditions specified in [RFC4271] for the attribute are revised as follows: The AGGREGATOR attribute SHALL be considered malformed if any of the following applies: o Its length is not 6 (when the "4-octet AS number capability" is not advertised to, or not received from the peer [RFC6793]). o Its length is not 8 (when the "4-octet AS number capability" is both advertised to, and received from the peer). An UPDATE message with a malformed AGGREGATOR attribute SHALL be handled using the approach of "attribute discard". 7.8. Community The error handling of [RFC1997] is revised as follows: The Community attribute SHALL be considered malformed if its length is not a nonzero multiple of 4. An UPDATE message with a malformed Community attribute SHALL be handled using the approach of "treat-as-withdraw". 7.9. ORIGINATOR_ID The error handling of [RFC4456] is revised as follows. o If the ORIGINATOR_ID attribute is received from an external neighbor, it SHALL be discarded using the approach of "attribute discard", or o if received from an internal neighbor, it SHALL be considered malformed if its length is not equal to 4. If malformed, the UPDATE SHALL be handled using the approach of "treat-as-withdraw". 7.10. CLUSTER_LIST The error handling of [RFC4456] is revised as follows. Chen, et al. Expires October 23, 2015 [Page 12] =0C Internet-Draft Revised Error Handling for BGP April 2015 o If the CLUSTER_LIST attribute is received from an external neighbor, it SHALL be discarded using the approach of "attribute discard", or o if received from an internal neighbor, it SHALL be considered malformed if its length is not a nonzero multiple of 4. If malformed, the UPDATE SHALL be handled using the approach of "treat-as-withdraw". 7.11. MP_REACH_NLRI If the Length of Next Hop Network Address field of the MP_REACH attribute is inconsistent with that which was expected, the attribute is considered malformed. Since the next hop precedes the NLRI field in the attribute, in this case it will not be possible to reliably locate the NLRI, and thus the "session reset" or "AFI/SAFI disable" approach MUST be used. "That which was expected", while somewhat vague, is intended to encompass the next hop specified for the Address Family Identifier and Subsequent Address Family Identifier fields and potentially modified by any extensions in use. For example, if [RFC5549] is in use then the next hop would have to have a length of 4 or 16. Section 3 and Section 5 provide further discussion of the handling of this attribute. 7.12. MP_UNREACH_NLRI Section 3 and Section 5 discuss the handling of this attribute. 7.13. Traffic Engineering path attribute We note that [RFC5543] does not detail what constitutes "malformation" for the Traffic Engineering path attribute. A future update to that specification may provide more guidance. In the interim, an implementation that determines (for whatever reason) that an UPDATE message contains a malformed Traffic Engineering path attribute MUST handle it using the approach of "treat-as-withdraw". 7.14. Extended Community The error handling of [RFC4360] is revised as follows: The Extended Community attribute SHALL be considered malformed if its length is not a nonzero multiple of 8. Chen, et al. Expires October 23, 2015 [Page 13] =0C Internet-Draft Revised Error Handling for BGP April 2015 An UPDATE message with a malformed Extended Community attribute SHALL be handled using the approach of "treat-as-withdraw". Note that a BGP speaker MUST NOT treat an unrecognized Extended Community Type or Sub-Type as an error. 7.15. IPv6 Address Specific BGP Extended Community Attribute The error handling of [RFC5701] is revised as follows: The IPv6 Address Specific Extended Community attribute SHALL be considered malformed if its length is not a nonzero multiple of 20. An UPDATE message with a malformed IPv6 Address Specific Extended Community attribute SHALL be handled using the approach of "treat-as- withdraw". Note that a BGP speaker MUST NOT treat an unrecognized IPv6 Address Specific Extended Community Type or Sub-Type as an error. 7.16. ATTR_SET The final paragraph of Section 5 of [RFC6368] is revised as follows: Old Text: An UPDATE message with a malformed ATTR_SET attribute SHALL be handled as follows. If its Partial flag is set and its Neighbor-Complete flag is clear, the UPDATE is treated as a route withdraw as discussed in [OPT-TRANS-BGP]. Otherwise (i.e., Partial flag is clear or Neighbor-Complete is set), the procedures of the BGP-4 base specification [RFC4271] MUST be followed with respect to an Optional Attribute Error. New Text: An UPDATE message with a malformed ATTR_SET attribute SHALL be handled using the approach of "treat as withdraw". Furthermore, the normative reference to [OPT-TRANS-BGP] in [RFC6368] is removed. 8. Guidance for Authors of BGP Specifications A document that specifies a new BGP attribute MUST provide specifics regarding what constitutes an error for that attribute and how that error is to be handled. Allowable error-handling approaches are detailed in Section 2. The treat-as-withdraw approach is generally Chen, et al. Expires October 23, 2015 [Page 14] =0C Internet-Draft Revised Error Handling for BGP April 2015 preferred. The document SHOULD also provide consideration of what debugging facilities may be required to permit issues caused by a malformed attribute to be diagnosed. For any malformed attribute that is handled by the "attribute discard" instead of the "treat-as-withdraw" approach, it is critical to consider the potential impact of doing so. In particular, if the attribute in question has or may have an effect on route selection or installation, the presumption is that discarding it is unsafe, unless careful analysis proves otherwise. The analysis should take into account the tradeoff between preserving connectivity and potential side effects. Authors can refer to Section 7 for examples. 9. IANA Considerations This document makes no request of IANA. 10. Security Considerations This specification addresses the vulnerability of a BGP speaker to a potential attack whereby a distant attacker can generate a malformed optional transitive attribute that is not recognized by intervening routers. Since the intervening routers do not recognize the attribute, they propagate it without checking it. When the malformed attribute arrives at a router that does recognize the given attribute type, that router resets the session over which it arrived. Since significant fan-out can occur between the attacker and the routers that do recognize the attribute type, this attack could potentially be particularly harmful. The improved error handling of this specification could in theory interact badly with some now-known weaker cryptographic mechanisms should such be used in future to secure BGP. For example, if a (fictional) mechanism that did not supply data integrity was used, an attacker could manipulate ciphertext in any attempt to change or observe how the receiver reacts. Absent this specification, the BGP session would have been terminated, while with this specification the attacker could make potentially many attempts. While such a confidentiality-only mechanism would not be defined today, we have in the past seen mechanism definitions that result in similar though not as obviously exploitable vulnerabilities. [RFC7366] The approach recommended today to avoid such issues is to prefer use of Authenticated Encryption with Additional Data (AEAD) ciphers [RFC5116] and (thus) to discard messages that don't verify. Chen, et al. Expires October 23, 2015 [Page 15] =0C Internet-Draft Revised Error Handling for BGP April 2015 In other respects, this specification does not change BGP's security characteristics. 11. Acknowledgements The authors wish to thank Juan Alcaide, Deniz Bahadir, Ron Bonica, Mach Chen, Andy Davidson, Bruno Decraene, Stephen Farrell, Rex Fernando, Jeff Haas, Chris Hall, Joel Halpern, Dong Jie, Akira Kato, Miya Kohno, Warren Kumari, Tony Li, Alton Lo, Shin Miyakawa, Tamas Mondal, Jonathan Oddy, Tony Przygienda, Robert Raszuk, Yakov Rekhter, Eric Rosen, Shyam Sethuram, Rob Shakir, Naiming Shen, Adam Simpson, Ananth Suryanarayana, Kaliraj Vairavakkalai, Lili Wang and Ondrej Zajicek for their observations and discussion of this topic, and review of this document. 12. References 12.1. Normative References [IANA-BGP-ATTRS] "BGP Path Attributes", . [RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP Communities Attribute", RFC 1997, August 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, February 2006. [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)", RFC 4456, April 2006. [RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, January 2007. [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007. Chen, et al. Expires October 23, 2015 [Page 16] =0C Internet-Draft Revised Error Handling for BGP April 2015 [RFC5543] Ould-Brahim, H., Fedyk, D., and Y. Rekhter, "BGP Traffic Engineering Attribute", RFC 5543, May 2009. [RFC5701] Rekhter, Y., "IPv6 Address Specific BGP Extended Community Attribute", RFC 5701, November 2009. [RFC6368] Marques, P., Raszuk, R., Patel, K., Kumaki, K., and T. Yamagata, "Internal BGP as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 6368, September 2011. [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet Autonomous System (AS) Number Space", RFC 6793, December 2012. 12.2. Informative References [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, January 2008. [RFC5549] Le Faucheur, F. and E. Rosen, "Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop", RFC 5549, May 2009. [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 6514, February 2012. [RFC7117] Aggarwal, R., Kamite, Y., Fang, L., Rekhter, Y., and C. Kodeboniya, "Multicast in Virtual Private LAN Service (VPLS)", RFC 7117, February 2014. [RFC7366] Gutmann, P., "Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", RFC 7366, September 2014. [RFC7432] Sajassi, A., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet VPN", RFC 7432, February 2015. Authors' Addresses Enke Chen (editor) Cisco Systems, Inc. Email: enkechen@cisco.com Chen, et al. Expires October 23, 2015 [Page 17] =0C Internet-Draft Revised Error Handling for BGP April 2015 John G. Scudder (editor) Juniper Networks Email: jgs@juniper.net Pradosh Mohapatra Sproute Networks Email: mpradosh@yahoo.com Keyur Patel Cisco Systems, Inc. Email: keyupate@cisco.com Chen, et al. Expires October 23, 2015 [Page 18] --Apple-Mail=_2540DD39-1C7B-4883-8DB0-8C09F92C7E8D-- From nobody Tue Apr 21 07:15:56 2015 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 BDF381AC3FE for ; Tue, 21 Apr 2015 07:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, 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 SC4LTTMVTBHx for ; Tue, 21 Apr 2015 07:15:54 -0700 (PDT) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E53001ACD19 for ; Tue, 21 Apr 2015 07:15:37 -0700 (PDT) Received: by igbhj9 with SMTP id hj9so16378102igb.1 for ; Tue, 21 Apr 2015 07:15:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cumulusnetworks.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7L2vh2nx17JqHNnn2qFs3f8Kt6GAXxwyHTXr+2UXvm0=; b=OF15dwh8PxCYz4Qt2FfERlKL4ayA0xDYt7re7Qu/EaHAy8IItkBbn5Gpz9YUTkkv05 sy2NogvIOZpD6AA6fF5mR+Mg/hwOM/BmMDPNFD2eiUZAzNRH5tOMl4UXbuEGg4+winNh 24bYjC9J2NWdpJ5QsG+2iDBhTJBYBLYETCtA8= 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=7L2vh2nx17JqHNnn2qFs3f8Kt6GAXxwyHTXr+2UXvm0=; b=N2sP1jW+B49R+hAKyMPj/W3Jy6+/Iytgfuc66QH8vT0U9CbAHKcLvX+U/iFe51scHb V5RWZz+PuXV4pa7orFATaCV3q5Iyu9y+cgMqVEcKbs+fJ2LkoaAbAF6C39Syy05zBbMh Ao6pNC9KeQurYWjzoX2L46MkCgeBhqhjvbeb5Rsr11puIXAC/NxQyyyPsJZtbnKcpfgw EiO3S0znxsLWvrn17ZTORT5jKE+Yamp6d3Zyy42/PPE2n2mss+96vlY+W9/HDhBNj87Q F4mgXs21dkn4E9dO1SIozFHuCxh/ljgejg9I9+9ChpG8ysiXLAhdnVRn+EsPcVZLxyfq FtzA== X-Gm-Message-State: ALoCoQkBa3wUbi+e/bPzxUW5DS252R/EjuPQUKNxEHKoMvEOXh/uuIgJPg4vZd6XFyZao1162Rnq MIME-Version: 1.0 X-Received: by 10.42.250.70 with SMTP id mn6mr3739877icb.78.1429625737411; Tue, 21 Apr 2015 07:15:37 -0700 (PDT) Received: by 10.107.129.88 with HTTP; Tue, 21 Apr 2015 07:15:37 -0700 (PDT) In-Reply-To: References: <002601d07b40$308aa3a0$919feae0$@ndzh.com> Date: Tue, 21 Apr 2015 10:15:37 -0400 Message-ID: From: Daniel Walton To: "Alvaro Retana (aretana)" Content-Type: multipart/alternative; boundary=20cf301af9fd3d9d0205143caef3 Archived-At: Cc: "idr@ietf.org" , Susan Hares Subject: Re: [Idr] 2 Week WG LC draft-ietf-idr-add-paths-implementation-00 (4/6 to 4/20/2015) 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, 21 Apr 2015 14:15:55 -0000 --20cf301af9fd3d9d0205143caef3 Content-Type: text/plain; charset=UTF-8 Me neither. Daniel On Mon, Apr 20, 2015 at 4:25 AM, Alvaro Retana (aretana) wrote: > I don't know of any IPR on this draft. > > Thanks! > > Alvaro. > > Sent from my iPad > > On Apr 20, 2015, at 4:01 AM, Susan Hares wrote: > > This WG LC is complete, but we need to hear each author with their IPR > Statement. Would each author indicated if they know of IPR on this draft. > > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > --20cf301af9fd3d9d0205143caef3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Me neither.

Daniel


On Mon, Apr 20, 2015 at= 4:25 AM, Alvaro Retana (aretana) <aretana@cisco.com> wrote:=
I don't know of any IPR on this draft.

Thanks!

Alvaro.

Sent from my iPad

On Apr 20, 2015, at 4:01 AM, Susan Hares <shares@ndzh.com> wrote:

This WG LC is complete, but we need to hear each aut= hor with their IPR Statement.=C2=A0=C2=A0 Would each author indicated if th= ey know of IPR on this draft.

=C2=A0


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


--20cf301af9fd3d9d0205143caef3-- From nobody Tue Apr 21 07:42:26 2015 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 80D101ACDA9 for ; Tue, 21 Apr 2015 07:42:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, 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 eLNm0esCcF96 for ; Tue, 21 Apr 2015 07:42:24 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E17CE1ACDB9 for ; Tue, 21 Apr 2015 07:42:21 -0700 (PDT) Received: by iecrt8 with SMTP id rt8so15234423iec.0 for ; Tue, 21 Apr 2015 07:42:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cumulusnetworks.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+gzFvrh/Aja9Py1bR6LGtR/H5xwa1Uz1xDUZxQ/8eNs=; b=G2q0oxF2A6SLFpS7fnZrSqEJf47oxp/osTnl99RQxi/Gr8s23swRbe01ZCK+7RsBKP zQa7DzTZRU+gfTqcrSHOJMFhCqgyk0SbLbwAFTWODTwlDmDMY2CqBmzl+Ku0YA2A8wfJ wD+EVRktzHtZ1OVHTVVa0NVAydIKqFvILejQ4= 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=+gzFvrh/Aja9Py1bR6LGtR/H5xwa1Uz1xDUZxQ/8eNs=; b=fo6DmnpHPQ0Faa/tp2vaGOtVrA5yxMp74cliyUGWYIwdf6OvjPvbntEvaQCd/rw43G sojP76hozyBXxhtMwx7LZZkSOGGqYbg0m1L1KHDDeWj4VBI6aG+yojsrHpAi8wZ5X3HR x2M2aiv2VSPpsdwplnqwrxoWun6xq+6IOkMw3tLZwS5dRTVOZgeZupnYALPTM6e+Ee8v 9GPzN7d0SkifP0hgtZe2pKGgEjkdP19No79Px1q3pVvocojhkZ1G+26ZpbWzq7J0E86o lZTHVZp1GAtzS18nGGI34CIEseR+uNHwfDd/d9WtyUd5DC+cO2ci3cMo0OXu5xA6mWds QScw== X-Gm-Message-State: ALoCoQny1kKgePSgEW5jilxw6hj36YpUK+IcTqEEoKM3c6Yv8axSqDMlZVHqFN0s8SbqneRmJ3CF MIME-Version: 1.0 X-Received: by 10.43.12.136 with SMTP id pi8mr3813688icb.6.1429627341401; Tue, 21 Apr 2015 07:42:21 -0700 (PDT) Received: by 10.107.129.88 with HTTP; Tue, 21 Apr 2015 07:42:21 -0700 (PDT) In-Reply-To: <001c01d07b26$c2633680$4729a380$@ndzh.com> References: <002e01d070ba$275479e0$75fd6da0$@ndzh.com> <76CD132C3ADEF848BD84D028D243C92757D07F7F@nkgeml512-mbx.china.huawei.com> <001c01d07b26$c2633680$4729a380$@ndzh.com> Date: Tue, 21 Apr 2015 10:42:21 -0400 Message-ID: From: Daniel Walton To: Susan Hares Content-Type: multipart/alternative; boundary=bcaec518242cd88abb05143d0d45 Archived-At: Cc: dbrungard@att.com, idr wg Subject: Re: [Idr] WG LC for draft-ietf-bgp-route-oscillation-stop (4/6 to 4/20) 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, 21 Apr 2015 14:42:25 -0000 --bcaec518242cd88abb05143d0d45 Content-Type: text/plain; charset=UTF-8 On Mon, Apr 20, 2015 at 12:59 AM, Susan Hares wrote: > Daniel: > > > > Do you see any current changes in the churn level? Have you examined the > churn inside of a datacenter? > Most customers I worked with that hit MED churn were hitting the Type I variety (details in rfc3345) and solved it by increasing the IGP metrics between their clusters or confed sub-ASes. UUNET was the big exception, they used confederations and were hitting Type II churn but it wasn't painful enough for them to make changes to stop it as the changes needed were fairly dramatic. UUNET's churn was one of the big drivers for doing add-path. I haven't run into MED churn in the data center yet. Many of our data center customers use BGP without an IGP which eliminates one of the variables needed to cause the churn. Daniel --bcaec518242cd88abb05143d0d45 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Apr 20, 2015 at 12:59 AM, Susan Hares <shares@ndzh.com> wr= ote:

Daniel:

=C2=A0

Do you see any current changes in the churn level?=C2=A0 Have you exami= ned the churn inside of a datacenter?

Most customers I worked with that hit MED churn were hitting th= e Type I variety (details in rfc3345) and solved it by increasing the IGP m= etrics between their clusters or confed sub-ASes.=C2=A0 UUNET was the big e= xception, they used confederations and were hitting Type II churn but it wa= sn't painful enough for them to make changes to stop it as the changes = needed were fairly dramatic. UUNET's churn was one of the big drivers f= or doing add-path.

I haven't run into MED chur= n in the data center yet.=C2=A0 Many of our data center customers use BGP w= ithout an IGP which eliminates one of the variables needed to cause the chu= rn.

Daniel
=C2=A0
--bcaec518242cd88abb05143d0d45-- From nobody Tue Apr 21 12:26:20 2015 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 C78B21A8A5F for ; Tue, 21 Apr 2015 12:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.926 X-Spam-Level: ** X-Spam-Status: No, score=2.926 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 M7_-cmNvgkkD for ; Tue, 21 Apr 2015 12:26:16 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 5741A1B2A53 for ; Tue, 21 Apr 2015 12:26:15 -0700 (PDT) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.11,617,1422939600"; d="scan'208,217";a="677028002" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 21 Apr 2015 15:10:08 -0400 Received: from PRVPEXVS10.corp.twcable.com ([10.136.163.41]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Tue, 21 Apr 2015 15:26:14 -0400 From: "George, Wes" To: "Alvaro Retana (aretana)" , "amante@apple.com" Date: Tue, 21 Apr 2015 15:26:15 -0400 Thread-Topic: 2 Week WG LC on draft-ietf-idr-as-migration (4/9 to 4/23/2105 Thread-Index: AdB8aQgvi8SCNzpRSSeSOBg1Sogvuw== Message-ID: References: <003f01d07394$9b5f1c00$d21d5400$@ndzh.com> 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.9.150325 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D15C183E4E361wesleygeorgetwcablecom_" MIME-Version: 1.0 Archived-At: Cc: Susan Hares , idr wg Subject: Re: [Idr] 2 Week WG LC on draft-ietf-idr-as-migration (4/9 to 4/23/2105 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, 21 Apr 2015 19:26:19 -0000 --_000_D15C183E4E361wesleygeorgetwcablecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWx2YXJvLCB0aGFua3MgZm9yIHRoZSByZXZpZXcsIGEgZmV3IGNvbW1lbnRzIGJlbG93IGlubGlu ZToNCg0KRnJvbTogIkFsdmFybyBSZXRhbmEgKGFyZXRhbmEpIiA8YXJldGFuYUBjaXNjby5jb208 bWFpbHRvOmFyZXRhbmFAY2lzY28uY29tPj4NCkRhdGU6IE1vbmRheSwgQXByaWwgMTMsIDIwMTUg YXQgNDo1MCBQTQ0KVG86ICJHZW9yZ2UsIFdlcyIgPHdlc2xleS5nZW9yZ2VAdHdjYWJsZS5jb208 bWFpbHRvOndlc2xleS5nZW9yZ2VAdHdjYWJsZS5jb20+PiwgImFtYW50ZUBhcHBsZS5jb208bWFp bHRvOmFtYW50ZUBhcHBsZS5jb20+IiA8YW1hbnRlQGFwcGxlLmNvbTxtYWlsdG86YW1hbnRlQGFw cGxlLmNvbT4+DQpDYzogIkpvaG4gRy4gU2N1ZGRlciIgPGpnc0BqdW5pcGVyLm5ldDxtYWlsdG86 amdzQGp1bmlwZXIubmV0Pj4sIElkciA8aWRyQGlldGYub3JnPG1haWx0bzppZHJAaWV0Zi5vcmc+ PiwgU3VzYW4gSGFyZXMgPHNoYXJlc0BuZHpoLmNvbTxtYWlsdG86c2hhcmVzQG5kemguY29tPj4N ClN1YmplY3Q6IFJlOiAyIFdlZWsgV0cgTEMgb24gZHJhZnQtaWV0Zi1pZHItYXMtbWlncmF0aW9u ICg0LzkgdG8gNC8yMy8yMTA1DQoNCg0KSSBkbyBoYXZlIG9uZSBpdGVtIHRoYXQgSSB0aGluayBt YXkgYmUgYWJvdmUg4oCcbWlub3LigJ06IHdoZW4gdXNpbmcg4oCcTG9jYWwgQVPigJ0sIHdoZW4g c2hvdWxkIHRoZSBBU04gYmUgcHJlcGVuZGVkPyAgV2hlbiBzZW5kaW5nIGVCR1AtcmVjZWl2ZWQg VVBEQVRFcyB0byBpQkdQIG5laWdoYm9ycyAoYXMgaXQgaXMgc3BlY2lmaWVkIGN1cnJlbnRseSks IE9SLCB0aGVuIHJlY2VpdmluZyB0aG9zZSBlQkdQIFVQREFURXM/ICBJZiBpdCBpcyBub3QgZG9u ZSB3aGVuIHJlY2VpdmluZywgdGhlbiB0aGUgQVNfUEFUSCB3aWxsIGJlIGluY29uc2lzdGVudCBp biB0aGUgQVMgKHRoZSBib3JkZXIgcm91dGVyIHdpbGwgaGF2ZSBhIHNob3J0ZXIgQVNfUEFUSCku ICBJIHRoaW5rIHRoaXMgY2FuIGxlYWQgdG8gaW5jb25zaXN0ZW50IHJvdXRlIHNlbGVjdGlvbiAo Z2l2ZW4gdGhhdCB0aGUgYXR0cmlidXRlcyBhcmUgaW5jb25zaXN0ZW50IGluc2lkZSB0aGUgQVMp LCBidXQgdGhhdCBvZiBjb3Vyc2UgbWF5IGJlIG1pdGlnYXRlZCBieSB0aGUgZmFjdCB0aGF0IHRo ZSBhcHBsaWNhdGlvbiBvZiBMb2NhbCBBUyBtYXkgYmUgdG93YXJkcyBzdHViIG5ldHdvcmtzIGlu IG1hbnkgKGJ1dCBub3QgYWxsKSBjYXNlcy4gICBJIHdvdWxkIHJlYWxseSBsaWtlIHRvIGhlYXIg b3RoZXJz4oCZIChiZXlvbmQgdGhlIGF1dGhvcnMpIG9waW5pb25zLg0KDQpXR10gU28gaXQgc2Vl bXMgbGlrZSB3ZSBnb3Qgb25seSBvbmUgb3BpbmlvbiBmcm9tIEp1YW4gKHRob3VnaCBpdCB3YXMg Y291Y2hlZCBpbiB0ZXJtcyBvZiAiQyBkb2VzIHRoaXMgYmV0dGVyIHRoYW4gSiIpIHRoYXQgd2Ug c2hvdWxkIGNoYW5nZSB0aGlzIGFuZCByZWNvbW1lbmQgYXBwZW5kaW5nIHdoZW4gcmVjZWl2aW5n LCByYXRoZXIgdGhhbiB3aGVuIHNlbmRpbmcgaW4gb3JkZXIgdG8gbWFpbnRhaW4gcm91dGUgY29u c2lzdGVuY3kuIFRoaXMgbWFrZXMgc2Vuc2UgdG8gbWUuIFNpbmNlIEFsdmFybyBhc2tlZCBmb3Ig b3RoZXIgb3BpbmlvbnMsIGFueSBvcGluaW9ucyB0byB0aGUgY29udHJhcnkgYmVmb3JlIEkgYXNz dW1lIHRoYXQgdGhlIFdHIHN1cHBvcnRzIHRoaXMgYW5kIG1ha2UgdGhlIGNoYW5nZSB0byB0aGUg ZHJhZnQ/IE1heWJlIHNvbWVvbmUgZnJvbSBKdW5pcGVyIHRoYXQgaGFzIGV4cGxhbmF0aW9uIG9u IHdoeSB0aGV5IGRvIGl0IHRoZSBvdGhlciB3YXksIG9yIHdhcyBKdWFuIG1pc3Rha2VuIGluIHRo YXQgYXNzdW1wdGlvbj8NCg0KDQpNaW5vciBJc3N1ZXM6DQoNClRoaXMgZG9jdW1lbnQgc2hvdWxk IGJlIG1hcmtlZCBhcyB1cGRhdGluZyByZmM0MjcxIGJlY2F1c2Ugb2YgdGhlIHByb2Nlc3Npbmcg b2YgdGhlIFVQREFURXMgKHNlY3Rpb24gMy4zKS4NCg0KV0ddIEhhcHB5IHRvIG1ha2UgdGhhdCBj aGFuZ2UsIGJ1dCB0aGUgcmVhc29uIHRoYXQgaXQgd2Fzbid0IHRoZXJlIGlzIHRoYXQgdGhpcyBp c24ndCBtYW5kYXRvcnkgdG8gaW1wbGVtZW50LiBJdCdzIG5vdCBnbG9iYWxseSBjaGFuZ2luZyB0 aGUgYmVoYXZpb3Igb2YgVVBEQVRFcywgYnV0IHJhdGhlciBkb2N1bWVudGluZyBob3cgdGhleSBj aGFuZ2Ugd2hlbiB0aGlzIHNwZWNpZmljIG9wdGlvbmFsIGZlYXR1cmUgc2V0IGlzIGludm9rZWQu IFNvbWVvbmUgcmVjZW50bHkgZ2F2ZSBtZSBndWlkYW5jZSBvbiBhIGRpZmZlcmVudCBkcmFmdCB0 aGF0IGl0IGlzbid0IGFsd2F5cyBhcHByb3ByaWF0ZSB0byBoYXZlIGEgZHJhZnQgdXBkYXRlIGFu IG9sZCBSRkMgaWYgdGhlIG5ldyB0aGluZyBpc24ndCBtYW5kYXRvcnkgdG8gaW1wbGVtZW50IGFz IGEgcGFydCBvZiB0aGUgb2xkIFJGQyBJLmUuIEEgZm9ybWFsIHVwZGF0ZSBpbiB0aGUgbWV0YWRh dGEgbWVhbnMgdGhhdCB0aGUgdHdvIChvciBtb3JlKSBSRkNzIHRvZ2V0aGVyIHJlcHJlc2VudCBh IGNvbXBsZXRlIEJHUCBpbXBsZW1lbnRhdGlvbiwgd2hpbGUgb25seSBpbXBsZW1lbnRpbmcgdGhl IG9yaWdpbmFsIFJGQyAodGhlIG9uZSBiZWluZyB1cGRhdGVkKSB3b3VsZCBiZSBhbiBpbmNvbXBs ZXRlIGltcGxlbWVudGF0aW9uLiBJIGRvbid0IGtub3cgaWYgdGhlcmUgaXMgYW4gb2ZmaWNpYWwg c3RhbmNlIG9uIHRoaXMgYXMgZmFyIGFzIHRoZSBSRkMgc2VyaWVzIGlzIGNvbmNlcm5lZCwgc28g SSdtIG9wZW4gdG8gZG8gaXQgZWl0aGVyIHdheSwgbmVlZCBndWlkYW5jZSBvbiBob3cgdG8gcHJv Y2VlZC4NCg0KTml0czoNCldHXSBzb21lIG9mIHRoZXNlIGFyZSBhIGxpdHRsZSBtb3JlIHRoYW4g bml0cyBnaXZlbiB0aGF0IHlvdSdyZSBzdWdnZXN0aW5nIHJlbW92aW5nIHdob2xlIHBhcmFncmFw aHMuIEknbGwgdGFrZSB0aGVtIHVuZGVyIGFkdmlzZW1lbnQgYW5kIGNvbnN1bHRhdGlvbiB3aXRo IG15IGNvLWF1dGhvci4NCg0KVGhhbmtzLA0KDQpXZXMNCg0KQW55dGhpbmcgYmVsb3cgdGhpcyBs aW5lIGhhcyBiZWVuIGFkZGVkIGJ5IG15IGNvbXBhbnnigJlzIG1haWwgc2VydmVyLCBJIGhhdmUg bm8gY29udHJvbCBvdmVyIGl0Lg0KLS0tLS0tLS0tLS0NCg0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KVGhpcyBFLW1haWwgYW5kIGFueSBvZiBpdHMgYXR0YWNobWVudHMgbWF5 IGNvbnRhaW4gVGltZSBXYXJuZXIgQ2FibGUgcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24sIHdoaWNo IGlzIHByaXZpbGVnZWQsIGNvbmZpZGVudGlhbCwgb3Igc3ViamVjdCB0byBjb3B5cmlnaHQgYmVs b25naW5nIHRvIFRpbWUgV2FybmVyIENhYmxlLiBUaGlzIEUtbWFpbCBpcyBpbnRlbmRlZCBzb2xl bHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNoIGl0IGlz IGFkZHJlc3NlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBvZiB0aGlz IEUtbWFpbCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwg ZGlzdHJpYnV0aW9uLCBjb3B5aW5nLCBvciBhY3Rpb24gdGFrZW4gaW4gcmVsYXRpb24gdG8gdGhl IGNvbnRlbnRzIG9mIGFuZCBhdHRhY2htZW50cyB0byB0aGlzIEUtbWFpbCBpcyBzdHJpY3RseSBw cm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMg RS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5k IHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kIGFueSBjb3B5IG9mIHRoaXMgRS1t YWlsIGFuZCBhbnkgcHJpbnRvdXQuDQo= --_000_D15C183E4E361wesleygeorgetwcablecom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2PkFsdmFybywgdGhhbmtzIGZvciB0aGUgcmV2aWV3LCBhIGZldyBjb21tZW50cyBiZWxvdyBp bmxpbmU6Jm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxz cGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpD YWxpYnJpOyBmb250LXNpemU6MTFwdDsgdGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9S REVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElO Ry1CT1RUT006IDBpbjsgUEFERElORy1MRUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9S REVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBB RERJTkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwv c3Bhbj4mcXVvdDtBbHZhcm8gUmV0YW5hIChhcmV0YW5hKSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFp bHRvOmFyZXRhbmFAY2lzY28uY29tIj5hcmV0YW5hQGNpc2NvLmNvbTwvYT4mZ3Q7PGJyPg0KPHNw YW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5Nb25kYXksIEFwcmlsIDEz LCAyMDE1IGF0IDQ6NTAgUE08YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86 IDwvc3Bhbj4mcXVvdDtHZW9yZ2UsIFdlcyZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOndlc2xl eS5nZW9yZ2VAdHdjYWJsZS5jb20iPndlc2xleS5nZW9yZ2VAdHdjYWJsZS5jb208L2E+Jmd0Oywg JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmFtYW50ZUBhcHBsZS5jb20iPmFtYW50ZUBhcHBsZS5jb208 L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86YW1hbnRlQGFwcGxlLmNvbSI+YW1hbnRlQGFw cGxlLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkNjOiA8 L3NwYW4+JnF1b3Q7Sm9obiBHLiBTY3VkZGVyJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86amdz QGp1bmlwZXIubmV0Ij5qZ3NAanVuaXBlci5uZXQ8L2E+Jmd0OywgSWRyICZsdDs8YSBocmVmPSJt YWlsdG86aWRyQGlldGYub3JnIj5pZHJAaWV0Zi5vcmc8L2E+Jmd0OywgU3VzYW4gSGFyZXMgJmx0 OzxhIGhyZWY9Im1haWx0bzpzaGFyZXNAbmR6aC5jb20iPnNoYXJlc0BuZHpoLmNvbTwvYT4mZ3Q7 PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5SZTog MiBXZWVrIFdHIExDIG9uIGRyYWZ0LWlldGYtaWRyLWFzLW1pZ3JhdGlvbiAoNC85IHRvIDQvMjMv MjEwNQ0KPGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9 IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0 LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyI+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdi KDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAx NHB4OyI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCkkgZG8g aGF2ZSBvbmUgaXRlbSB0aGF0IEkgdGhpbmsgbWF5IGJlIGFib3ZlIOKAnG1pbm9y4oCdOiB3aGVu IHVzaW5nIOKAnExvY2FsIEFT4oCdLCB3aGVuIHNob3VsZCB0aGUgQVNOIGJlIHByZXBlbmRlZD8g Jm5ic3A7V2hlbiBzZW5kaW5nIGVCR1AtcmVjZWl2ZWQgVVBEQVRFcyB0byBpQkdQIG5laWdoYm9y cyAoYXMgaXQgaXMgc3BlY2lmaWVkIGN1cnJlbnRseSksIE9SLCB0aGVuIHJlY2VpdmluZyB0aG9z ZSBlQkdQIFVQREFURXM/ICZuYnNwO0lmIGl0IGlzIG5vdCBkb25lIHdoZW4NCiByZWNlaXZpbmcs IHRoZW4gdGhlIEFTX1BBVEggd2lsbCBiZSBpbmNvbnNpc3RlbnQgaW4gdGhlIEFTICh0aGUgYm9y ZGVyIHJvdXRlciB3aWxsIGhhdmUgYSBzaG9ydGVyIEFTX1BBVEgpLiAmbmJzcDtJIHRoaW5rIHRo aXMgY2FuIGxlYWQgdG8gaW5jb25zaXN0ZW50IHJvdXRlIHNlbGVjdGlvbiAoZ2l2ZW4gdGhhdCB0 aGUgYXR0cmlidXRlcyBhcmUgaW5jb25zaXN0ZW50IGluc2lkZSB0aGUgQVMpLCBidXQgdGhhdCBv ZiBjb3Vyc2UgbWF5IGJlIG1pdGlnYXRlZA0KIGJ5IHRoZSBmYWN0IHRoYXQgdGhlIGFwcGxpY2F0 aW9uIG9mIExvY2FsIEFTIG1heSBiZSB0b3dhcmRzIHN0dWIgbmV0d29ya3MgaW4gbWFueSAoYnV0 IG5vdCBhbGwpIGNhc2VzLiAmbmJzcDsgSSB3b3VsZCByZWFsbHkgbGlrZSB0byBoZWFyIG90aGVy c+KAmSAoYmV5b25kIHRoZSBhdXRob3JzKSBvcGluaW9ucy4gJm5ic3A7PC9kaXY+DQo8ZGl2IHN0 eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiBy Z2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6 IDE0cHg7Ij4NCldHXSBTbyBpdCBzZWVtcyBsaWtlIHdlIGdvdCBvbmx5IG9uZSBvcGluaW9uIGZy b20gSnVhbiAodGhvdWdoIGl0IHdhcyBjb3VjaGVkIGluIHRlcm1zIG9mICZxdW90O0MgZG9lcyB0 aGlzIGJldHRlciB0aGFuIEomcXVvdDspIHRoYXQgd2Ugc2hvdWxkIGNoYW5nZSB0aGlzIGFuZCBy ZWNvbW1lbmQgYXBwZW5kaW5nIHdoZW4gcmVjZWl2aW5nLCByYXRoZXIgdGhhbiB3aGVuIHNlbmRp bmcgaW4gb3JkZXIgdG8gbWFpbnRhaW4gcm91dGUgY29uc2lzdGVuY3kuIFRoaXMgbWFrZXMNCiBz ZW5zZSB0byBtZS4gU2luY2UgQWx2YXJvIGFza2VkIGZvciBvdGhlciBvcGluaW9ucywgYW55IG9w aW5pb25zIHRvIHRoZSBjb250cmFyeSBiZWZvcmUgSSBhc3N1bWUgdGhhdCB0aGUgV0cgc3VwcG9y dHMgdGhpcyBhbmQgbWFrZSB0aGUgY2hhbmdlIHRvIHRoZSBkcmFmdD8gTWF5YmUgc29tZW9uZSBm cm9tIEp1bmlwZXIgdGhhdCBoYXMgZXhwbGFuYXRpb24gb24gd2h5IHRoZXkgZG8gaXQgdGhlIG90 aGVyIHdheSwgb3Igd2FzIEp1YW4gbWlzdGFrZW4NCiBpbiB0aGF0IGFzc3VtcHRpb24/PC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJP TEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7 IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0 ZS1zcGFjZTsiPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KPGJyPg0KPC9kaXY+DQo8 ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQpNaW5vciBJc3N1ZXM6PC9kaXY+DQo8L2Rpdj4N Cjwvc3Bhbj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJ T04iPg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9k ZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7Ij4NCjxkaXY+ VGhpcyBkb2N1bWVudCBzaG91bGQgYmUgbWFya2VkIGFzIHVwZGF0aW5nIHJmYzQyNzEgYmVjYXVz ZSBvZiB0aGUgcHJvY2Vzc2luZyBvZiB0aGUgVVBEQVRFcyAoc2VjdGlvbiAzLjMpLjwvZGl2Pg0K PC9kaXY+DQo8L3NwYW4+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5XR10gSGFwcHkgdG8gbWFr ZSB0aGF0IGNoYW5nZSwgYnV0IHRoZSByZWFzb24gdGhhdCBpdCB3YXNuJ3QgdGhlcmUgaXMgdGhh dCB0aGlzIGlzbid0IG1hbmRhdG9yeSB0byBpbXBsZW1lbnQuIEl0J3Mgbm90IGdsb2JhbGx5IGNo YW5naW5nIHRoZSBiZWhhdmlvciBvZiBVUERBVEVzLCBidXQgcmF0aGVyIGRvY3VtZW50aW5nIGhv dyB0aGV5IGNoYW5nZSB3aGVuIHRoaXMgc3BlY2lmaWMgb3B0aW9uYWwgZmVhdHVyZSBzZXQgaXMg aW52b2tlZC4NCiBTb21lb25lIHJlY2VudGx5IGdhdmUgbWUgZ3VpZGFuY2Ugb24gYSBkaWZmZXJl bnQgZHJhZnQgdGhhdCBpdCBpc24ndCBhbHdheXMgYXBwcm9wcmlhdGUgdG8gaGF2ZSBhIGRyYWZ0 IHVwZGF0ZSBhbiBvbGQgUkZDIGlmIHRoZSBuZXcgdGhpbmcgaXNuJ3QgbWFuZGF0b3J5IHRvIGlt cGxlbWVudCBhcyBhIHBhcnQgb2YgdGhlIG9sZCBSRkMgSS5lLiBBIGZvcm1hbCB1cGRhdGUgaW4g dGhlIG1ldGFkYXRhIG1lYW5zIHRoYXQgdGhlIHR3byAob3IgbW9yZSkNCiBSRkNzIHRvZ2V0aGVy IHJlcHJlc2VudCBhIGNvbXBsZXRlIEJHUCBpbXBsZW1lbnRhdGlvbiwgd2hpbGUgb25seSBpbXBs ZW1lbnRpbmcgdGhlIG9yaWdpbmFsIFJGQyAodGhlIG9uZSBiZWluZyB1cGRhdGVkKSB3b3VsZCBi ZSBhbiBpbmNvbXBsZXRlIGltcGxlbWVudGF0aW9uLiBJIGRvbid0IGtub3cgaWYgdGhlcmUgaXMg YW4gb2ZmaWNpYWwgc3RhbmNlIG9uIHRoaXMgYXMgZmFyIGFzIHRoZSBSRkMgc2VyaWVzIGlzIGNv bmNlcm5lZCwgc28gSSdtDQogb3BlbiB0byBkbyBpdCBlaXRoZXIgd2F5LCBuZWVkIGd1aWRhbmNl IG9uIGhvdyB0byBwcm9jZWVkLiZuYnNwOzwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9T RUNUSU9OIj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNw LW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyI+DQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1m YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KTml0czo8L2Rp dj4NCjwvZGl2Pg0KPC9zcGFuPg0KPGRpdj5XR10gc29tZSBvZiB0aGVzZSBhcmUgYSBsaXR0bGUg bW9yZSB0aGFuIG5pdHMgZ2l2ZW4gdGhhdCB5b3UncmUgc3VnZ2VzdGluZyByZW1vdmluZyB3aG9s ZSBwYXJhZ3JhcGhzLiBJJ2xsIHRha2UgdGhlbSB1bmRlciBhZHZpc2VtZW50IGFuZCBjb25zdWx0 YXRpb24gd2l0aCBteSBjby1hdXRob3IuJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0K PHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDog YnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6 IGFmdGVyLXdoaXRlLXNwYWNlOyI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsiPlRoYW5r cyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBp biAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9u dC1zaXplOiAxMXB0OyI+V2VzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7Ij48YnI+DQo8 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0 OyBmb250LXNpemU6IDExcHQ7Ij48c3BhbiBzdHlsZT0iY29sb3I6IHJnYigxMjcsIDEyNywgMTI3 KTsiPkFueXRoaW5nIGJlbG93IHRoaXMgbGluZSBoYXMgYmVlbiBhZGRlZCBieSBteSBjb21wYW55 4oCZcyBtYWlsIHNlcnZlciwgSSBoYXZlIG5vIGNvbnRyb2wgb3ZlciBpdC48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAu MDAwMXB0OyBmb250LXNpemU6IDExcHQ7Ij48c3BhbiBzdHlsZT0iY29sb3I6IHJnYigxMjcsIDEy NywgMTI3KTsiPi0tLS0tLS0tLS0tPC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pjxz cGFuIHN0eWxlPSJjb2xvcjogcmdiKDEyNywgMTI3LCAxMjcpOyI+PGJyPg0KPC9zcGFuPjwvZGl2 Pg0KPC9kaXY+DQo8L3NwYW4+PGJyPg0KPGhyPg0KPGZvbnQgZmFjZT0iQXJpYWwiIGNvbG9yPSJH cmF5IiBzaXplPSIxIj5UaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0cyBhdHRhY2htZW50cyBtYXkg Y29udGFpbiBUaW1lIFdhcm5lciBDYWJsZSBwcm9wcmlldGFyeSBpbmZvcm1hdGlvbiwgd2hpY2gg aXMgcHJpdmlsZWdlZCwgY29uZmlkZW50aWFsLCBvciBzdWJqZWN0IHRvIGNvcHlyaWdodCBiZWxv bmdpbmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1tYWlsIGlzIGludGVuZGVkIHNvbGVs eQ0KIGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aGljaCBpdCBp cyBhZGRyZXNzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhp cyBFLW1haWwsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRpb24s IGRpc3RyaWJ1dGlvbiwgY29weWluZywgb3IgYWN0aW9uIHRha2VuIGluIHJlbGF0aW9uIHRvIHRo ZSBjb250ZW50cyBvZiBhbmQgYXR0YWNobWVudHMgdG8NCiB0aGlzIEUtbWFpbCBpcyBzdHJpY3Rs eSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRo aXMgRS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkg YW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kIGFueSBjb3B5IG9mIHRoaXMg RS1tYWlsIGFuZCBhbnkgcHJpbnRvdXQuPGJyPg0KPC9mb250Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_D15C183E4E361wesleygeorgetwcablecom_-- From nobody Tue Apr 21 13:26:51 2015 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 338ED1A8A43 for ; Tue, 21 Apr 2015 13:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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-0JcLzW74L7 for ; Tue, 21 Apr 2015 13:26:48 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 645821A8A17 for ; Tue, 21 Apr 2015 13:26:48 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 096F8C19B; Tue, 21 Apr 2015 16:26:48 -0400 (EDT) Date: Tue, 21 Apr 2015 16:26:47 -0400 From: Jeffrey Haas To: Juan Alcaide Message-ID: <20150421202647.GB1600@pfrc> References: <20150409140218.22830.31521.idtracker@ietfa.amsl.com> <02e401d072e4$4f5a1cc0$ee0e5640$@ndzh.com> <001f01d07b3f$13ee12f0$3bca38d0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "'idr@ietf.org'" , "'jgralak@juniper.net'" , "UTTARO, JAMES" , 'Susan Hares' Subject: Re: [Idr] I-D Action: draft-ietf-idr-as-migration-04.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, 21 Apr 2015 20:26:49 -0000 On Mon, Apr 20, 2015 at 04:21:38PM -0400, Juan Alcaide wrote: > - As we discussed, for ebgp incomming updates for local-as it makes > more sense to prepend AS on incomming updates. I think we shoudl > describe this option as the default one and any other one as a > variation. I would say that the "Juniper" behavior has quite a bit of history. Wes and company have done a good job being agnostic about these long-standing behaviors and simply documenting them rather than kicking off a particular religious war on what should be done. It wouldn't surprise me though that the publication of this document as an RFC leads to various vendors implementing versions of the knobs they previously didn't support. > - Cisco plans to implement the internal BGP alias as ibgp local-as > dual-as. So perhaps we can choose an agnostic name and explain both > Juniper and Cisco names. I think it's beyond the scope of any IETF document beyond yang and MIB modules to prescribe the name of a vendor's configuration knob. :-) (The astute reader will note that we'll have to settle on a name in the yang module. See prior comments at the mic during IDR about IETF vendor-registered augmentation modules.) > - About "the speaker SHOULD send BGP OPEN using the globally > configured ASN first". I think we should emphasize how the FSM gets > modified. It may be implicit, but it may save us from some > interoperabilities problems. My ideas: You are welcome to provide text for such a thing but I would suggest it's not worth the review time of IDR. The introduction of the internal toggle would effectively instantiate a sub-state machine within the overall state machine and be quite the mess. I have long since lost my notes on the FSM during RFC 4271 standardization work, but had noted that it had some issues. Feel free to audit the FSM to see if you can find those issues again and see how this would interact with the errata. :-) --Jeff From nobody Tue Apr 21 13:39:20 2015 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 F12681B2B14 for ; Tue, 21 Apr 2015 13:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Bt-dVM7IuaV for ; Tue, 21 Apr 2015 13:39:17 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 627B91B2B0F for ; Tue, 21 Apr 2015 13:39:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4069; q=dns/txt; s=iport; t=1429648754; x=1430858354; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ATUXlPBobpN+iH7bEWcKAz/UQrd9z0rr9QBElzPCywk=; b=O7uXQKcbqBZR1XAtXUPAVC9/V5CJKNcMx8m3asTKdSBdre4fgC4zTEO5 jP0ncAr7YZrVCiVkWeeCdH2QNyprWcGZJGheDavjRvGKLPR1sQfJgUJaz AGkTxgC0ivXIsr2U+OYshRu6u5WMEdF8tAYkE+NX+WBGoTRT5+1d2gmqx k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ASBQAMtDZV/4sNJK1bgkVHgS4FzXACgUZMAQEBAQEBfoQhAQEEeRACAQgEOwcyFBEBAQQBDQWIK8wiAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4s3hQQHhC0FjxOCIIopgSKMcIcbIoNzb4FEgQABAQE X-IronPort-AV: E=Sophos;i="5.11,618,1422921600"; d="scan'208,217";a="413679532" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-6.cisco.com with ESMTP; 21 Apr 2015 20:39:13 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t3LKdDv0027085 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Apr 2015 20:39:13 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.6]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Tue, 21 Apr 2015 15:39:13 -0500 From: "Alvaro Retana (aretana)" To: "George, Wes" , "amante@apple.com" Thread-Topic: 2 Week WG LC on draft-ietf-idr-as-migration (4/9 to 4/23/2105 Thread-Index: AdBzlDcUkdJmp22uTqShwxbVd0A/MgCn6C+AAZfGYoD//6/GgA== Date: Tue, 21 Apr 2015 20:39:12 +0000 Message-ID: References: <003f01d07394$9b5f1c00$d21d5400$@ndzh.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.241.3] Content-Type: multipart/alternative; boundary="_000_D15C10F1A9B95aretanaciscocom_" MIME-Version: 1.0 Archived-At: Cc: Susan Hares , idr wg Subject: Re: [Idr] 2 Week WG LC on draft-ietf-idr-as-migration (4/9 to 4/23/2105 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, 21 Apr 2015 20:39:19 -0000 --_000_D15C10F1A9B95aretanaciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On 4/21/15, 1:26 PM, "George, Wes" > wrote: Wes: Hi! This document should be marked as updating rfc4271 because of the processin= g of the UPDATEs (section 3.3). WG] Happy to make that change, but the reason that it wasn't there is that = this isn't mandatory to implement. It's not globally changing the behavior = of UPDATEs, but rather documenting how they change when this specific optio= nal feature set is invoked. Someone recently gave me guidance on a differen= t draft that it isn't always appropriate to have a draft update an old RFC = if the new thing isn't mandatory to implement as a part of the old RFC I.e.= A formal update in the metadata means that the two (or more) RFCs together= represent a complete BGP implementation, while only implementing the origi= nal RFC (the one being updated) would be an incomplete implementation. I do= n't know if there is an official stance on this as far as the RFC series is= concerned, so I'm open to do it either way, need guidance on how to procee= d. I interpret it the other way: when implementing this optional mechanisms th= e base RFC is updated..and only when the optional mechanisms are implemente= d. Let=92s go with the update marking and we can talk about it in the IESG if = it comes up. Thanks! Alvaro. --_000_D15C10F1A9B95aretanaciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
On 4/21/15, 1:26 PM, "George, Wes" <wesley.george@twcable.com> wrote:

Wes:

Hi!

This document should be marked as updating rfc4271 because of the proc= essing of the UPDATEs (section 3.3).

WG] Happy to make that change, but the reason that it wasn't there is = that this isn't mandatory to implement. It's not globally changing the beha= vior of UPDATEs, but rather documenting how they change when this specific = optional feature set is invoked. Someone recently gave me guidance on a different draft that it isn't alway= s appropriate to have a draft update an old RFC if the new thing isn't mand= atory to implement as a part of the old RFC I.e. A formal update in the met= adata means that the two (or more) RFCs together represent a complete BGP implementation, while only implemen= ting the original RFC (the one being updated) would be an incomplete implem= entation. I don't know if there is an official stance on this as far as the= RFC series is concerned, so I'm open to do it either way, need guidance on how to proceed. 

I interpret it the other way: when implementing this optional mechanis= ms the base RFC is updated..and only when the optional mechanisms are imple= mented.

Let=92s go with the update marking and we can talk about it in the IES= G if it comes up.

Thanks!

Alvaro.
--_000_D15C10F1A9B95aretanaciscocom_-- From nobody Tue Apr 21 13:41:38 2015 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 A589F1B2B21 for ; Tue, 21 Apr 2015 13:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 icEutXVlHksI for ; Tue, 21 Apr 2015 13:41:36 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id B909F1B2B0F for ; Tue, 21 Apr 2015 13:41:36 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 7D59EC19B; Tue, 21 Apr 2015 16:41:36 -0400 (EDT) Date: Tue, 21 Apr 2015 16:41:36 -0400 From: Jeffrey Haas To: "Alvaro Retana (aretana)" Message-ID: <20150421204136.GC1600@pfrc> References: <003f01d07394$9b5f1c00$d21d5400$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: idr wg , "amante@apple.com" , Susan Hares Subject: Re: [Idr] 2 Week WG LC on draft-ietf-idr-as-migration (4/9 to 4/23/2105 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, 21 Apr 2015 20:41:37 -0000 Alvaro, On Mon, Apr 13, 2015 at 08:50:40PM +0000, Alvaro Retana (aretana) wrote: > I do have one item that I think may be above ?minor?: when using ?Local AS?, when should the ASN be prepended? When sending eBGP-received UPDATEs to iBGP neighbors (as it is specified currently), OR, then receiving those eBGP UPDATEs? If it is not done when receiving, then the AS_PATH will be inconsistent in the AS (the border router will have a shorter AS_PATH). I think this can lead to inconsistent route selection (given that the attributes are inconsistent inside the AS), but that of course may be mitigated by the fact that the application of Local AS may be towards stub networks in many (but not all) cases. I would really like to hear others? (beyond the authors) opinions. [My comments #3 and #7 in the Minor section below are related to this.] Obviously there's a long standing history with both variations on the feature along with a number of related but poorly (if ever) documented behaviors to worry about. A few here: RFC 4271, 5.1.2 notes we don't modify the AS_PATH on advertisement to an internal peer. Obviously implementations do that, semantic quibbling about doing it as part of modification of a route in adj-rib-in/loc-rib vs. adj-rib-out aside. Mostly a note of historical significance rather than saying "we shouldn't do that". Somewhat more relevant is in section 9.1.2: : If the AS_PATH attribute of a BGP route contains an AS loop, the BGP : route should be excluded from the Phase 2 decision function. AS loop : detection is done by scanning the full AS path (as specified in the : AS_PATH attribute), and checking that the autonomous system number of : the local system does not appear in the AS path. Operations of a BGP : speaker that is configured to accept routes with its own autonomous : system number in the AS path are outside the scope of this document. That last sentence was provided to provide the little documentation implementations had at the time on local-as. What is not stated is the somewhat problematic issue of the above paragraph. The issue has to do with where an implementation does its loop detection. Some implementations do loop detection at every BGP speaker. Some do them only at an ebgp edge. Some bias this behavior based on local-as being enabled or not. How you do your loop detection and when heavily biases your choice of implementation. In implementations that only requires local-as at your ebgp edges but do loop detection at route reflectors/external confederation routers, adding your local-as as part of import is a problem. So, consistency isn't only a big deal as part of when/where you do your local-as prepend, it's also a matter of where you do loop detection. If implementations in the absence of some "outside the scope" implementation were to pedantically implement the base BGP RFC, the migration mechanisms would be a bit biased to a given solution. -- Jeff From nobody Tue Apr 21 20:33:53 2015 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 38A6F1B30F4 for ; Tue, 21 Apr 2015 20:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFKlxzfE-ZMf for ; Tue, 21 Apr 2015 20:33:52 -0700 (PDT) Received: from server.riw.us (server.riw.us [162.144.32.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 494CC1B30F3 for ; Tue, 21 Apr 2015 20:33:51 -0700 (PDT) Received: from 162-229-180-77.lightspeed.rlghnc.sbcglobal.net ([162.229.180.77]:56706 helo=RussPC) by server.riw.us with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.85) (envelope-from ) id 1YklQ2-0005ro-6K; Wed, 22 Apr 2015 03:33:46 +0000 From: "Russ White" To: "'Susan Hares'" , References: <015e01d07ba1$0042bff0$00c83fd0$@ndzh.com> In-Reply-To: <015e01d07ba1$0042bff0$00c83fd0$@ndzh.com> Date: Tue, 21 Apr 2015 23:33:41 -0400 Message-ID: <002201d07cad$21cd1820$65674860$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQJfn6j0yIiCfADzgOqVipXJ8JqXTJw6Gsfw Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.riw.us X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Get-Message-Sender-Via: server.riw.us: authenticated_id: russw@riw.us X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [Idr] 2 week WG LC for draft-ietf-custom-decision (4/20 to 5/4/2015) 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, 22 Apr 2015 03:33:53 -0000 (noting I am a co-author) > As always, it is important to indicate "support" or "no support" for the WG LC. Support. Russ From nobody Wed Apr 22 02:22:39 2015 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 171E11B3359 for ; Wed, 22 Apr 2015 02:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-RaLv669OxM for ; Wed, 22 Apr 2015 02:22:36 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C04731A1AB3 for ; Wed, 22 Apr 2015 02:22:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2300; q=dns/txt; s=iport; t=1429694550; x=1430904150; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=veWHD0YXBRR2A3HtD4pS/tnsRPS363UFqvXbTqktqYs=; b=H+5VCIrmiDOcl7SeCoxzDw5DGrSMnJpfcrXCq51C71WZ0QFLcPUOHQ8e SpdI7l6+668/bcziecban0Ek3HjxEOHpeD+Fd2AZnGxUEoci1Mccq1ec+ fQ/k33W8HJ8Trm7WnoG8TOnzJ7PYK61XsozojEwdGwl/DSXs7vijzFQlj 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AOBQCSZzdV/5tdJa1bgwzPHQKBM0wBAQEBAQF+hCEBAQMBOAI/BQsLDjhXBog2CMt/AQEBAQEBAQMBAQEBAQEBARqLN4UEB4QtBZx+jHCDTYNOIoQPgVUFgT0BAQE X-IronPort-AV: E=Sophos;i="5.11,623,1422921600"; d="scan'208";a="413761796" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 22 Apr 2015 09:20:49 +0000 Received: from clubhouse-2.cisco.com (clubhouse-2.cisco.com [64.100.21.11]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t3M9KkXX005697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Apr 2015 09:20:48 GMT Date: Wed, 22 Apr 2015 05:20:45 -0400 (EDT) From: Juan Alcaide To: Jeffrey Haas In-Reply-To: <20150421202647.GB1600@pfrc> Message-ID: References: <20150409140218.22830.31521.idtracker@ietfa.amsl.com> <02e401d072e4$4f5a1cc0$ee0e5640$@ndzh.com> <001f01d07b3f$13ee12f0$3bca38d0$@ndzh.com> <20150421202647.GB1600@pfrc> User-Agent: Alpine 2.00 (GSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "'idr@ietf.org'" , "'jgralak@juniper.net'" , "UTTARO, JAMES" , 'Susan Hares' Subject: Re: [Idr] I-D Action: draft-ietf-idr-as-migration-04.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, 22 Apr 2015 09:22:38 -0000 Jeffrey, Inline.. > It wouldn't surprise me though that the publication of this document as an > RFC leads to various vendors implementing versions of the knobs they > previously didn't support. > You mean vendors implementing 'prepend on incomming ebgp update'? Possibly, but we shouldn't describe on a RFC only the suboptimal approach ('prepend on outbound ibgp update') > I think it's beyond the scope of any IETF document beyond yang and MIB > modules to prescribe the name of a vendor's configuration knob. :-) > > (The astute reader will note that we'll have to settle on a name in the yang > module. See prior comments at the mic during IDR about IETF > vendor-registered augmentation modules.) > So internal-alias, besides Juniper naming, is the 'official' name according to the yang module? In anycase, since the draft describes multiple vendors implementations, it may be worth to describe the naming of others. > You are welcome to provide text for such a thing but I would suggest it's > not worth the review time of IDR. The introduction of the internal toggle > would effectively instantiate a sub-state machine within the overall state > machine and be quite the mess. I have long since lost my notes on the FSM > during RFC 4271 standardization work, but had noted that it had some issues. > > Feel free to audit the FSM to see if you can find those issues again and see > how this would interact with the errata. :-) Don't want to do a deep inspection of the FSM ;-) It's something more basic. Consider - You can send only one AS in your open each time you try to establish a new session - The As you send does not depend on the AS you receive (no negotiation) - You can accept received AS to be accepted if it's one of the 2 configured ones - You must force AS you send and AS you receive to be the same. >From the above, it can be deduced that if both speakers have the internal alias feature configured, they must send the same AS ast the first time they try to establish the session. And session must be formed with this AS. Otherwise, AS never match and session cannot be establish. We could do something more complicated, but this would really be beyond the scope of the draft. > > --Jeff > From nobody Wed Apr 22 02:53:50 2015 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 92CC21ACD2D for ; Wed, 22 Apr 2015 02:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 rSAw4e5X8lvf for ; Wed, 22 Apr 2015 02:53:43 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 869EA1ACD18 for ; Wed, 22 Apr 2015 02:53:42 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id BD12E22C66E; Wed, 22 Apr 2015 11:53:40 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 9EBDE27C053; Wed, 22 Apr 2015 11:53:40 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0224.002; Wed, 22 Apr 2015 11:53:40 +0200 From: To: Susan Hares Thread-Topic: [Idr] 2 week WG LC for draft-ietf-custom-decision (4/20 to 5/4/2015) Thread-Index: AdB7oHZ7MpCy+WliQDeoG6G90Nwn3ABMujKQ Date: Wed, 22 Apr 2015 09:53:39 +0000 Message-ID: <25797_1429696420_55376FA4_25797_3139_1_53C29892C857584299CBF5D05346208A0EBAA545@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <015e01d07ba1$0042bff0$00c83fd0$@ndzh.com> In-Reply-To: <015e01d07ba1$0042bff0$00c83fd0$@ndzh.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A0EBAA545PEXCVZYM11corpo_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.4.22.65722 Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] 2 week WG LC for draft-ietf-custom-decision (4/20 to 5/4/2015) 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, 22 Apr 2015 09:53:48 -0000 --_000_53C29892C857584299CBF5D05346208A0EBAA545PEXCVZYM11corpo_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, Please find below some comments on the document: =A7 Abstract *) "It is cumbersome (if at all possible) for the end user to define polici= es that will select, after partial comparison, a path based on subjective l= ocal (domain and/or node) criteria." IMHO the sentence may be reworded. e.g. using a more factual/neutral orient= ation. (Alternatively, the document would need to elaborate on how much "cu= mbersome"/"impossible" is saved by using this new tool. (definitely not all= IMO)). =A7 3. The BGP Cost Community *) "The Point of Insertion sub-field contains the value of the path attribu= te *after* which this community MUST be considered during the best path sel= ection process." - My reading of "value of the path attribute" is http://www.iana.org/assign= ments/bgp-parameters/bgp-parameters.xhtml#bgp-parameters-2 Is this correct= ? Probably not as the IANA section of this draft propose a new/different re= gistry for POI. *) "The high-order bit is reserved to indicate that the Cost Community MUST= replace the path attribute specified by the Point of Insertion during the = best path selection process." "reserved" does not seem to be the best word given that the bit is not rese= rved (for future use) but specified in this document. *) "Multiple Cost Communities may indicate the same Point of Insertion. In= this case, the Cost Community with the lowest Community-ID is considered f= irst." Multiple cost communities may be received with the same Point of Insertion = and the same Community-ID. Please specific which one is to be taken or the = error handling. =A7 5. Deployment Considerations *) "It is important that a consistent path selection process be maintained= across the local Autonomous System to avoid potential routing loops." How much important? Given the (below) use of a few SHOULD (vs MUST) there is no real assurance = that no routing loops will form: - "If a BGP speaker receives a path that contains the Cost Community, it SH= OULD consider its value at the Point of Insertion specified, when calculat= ing the best path" - "if the Cost Community is used, all the nodes in the AS that may have to = consider this new community at any Point of Insertion SHOULD be aware of t= he mechanisms described in this document." IMO, either :s/SHOULD/MUST in the 2 above sentence, or the document must di= scuss the conditions which are safe and the ones which are not. *) "be aware of the mechanisms described in this document" is not enough. = It also needs to support the specific POI used. =A7 6. Security Considerations *) "This document introduces no new security concerns to BGP or other speci= fications referenced in this document." Really?? That sentence would rather make me feel that this document is not = ready for RFC publication. IMO a real consideration of the security aspects should be done. e.g. (for free): a) by default, this mechanism is activated. b) non compliant implementation will accept and pass transitive Opaque comm= unity (0x03) a) + b): anyone in the Internet can influence the routing in my AS; wh= ich is not acceptable. =A7 7. IANA Considerations "Some of the values in this new registry match the values assigned in the B= GP Path Attributes registry [BGP_PAR]. It is RECOMMENDED that an effort be= made to assign the same values in both tables when applicable." If this is the goal - both allocation policies should probably be the same. - IMHO the draft should comment on the POI value already assigned to BGP at= tribute. Should they be considered "reserved" of free to use as "non applic= able"? - it could be discussed that POI 129 "IGP_COST" may best match BG Attribute= 3 NEXT_HOP =A7 Appendix A. Cost Community Point of Insertion Registry *) It looks like this whole section should be in the IANA section, rather t= han an appendix. Thanks, Regards, Bruno From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Monday, April 20, 2015 9:34 PM To: idr@ietf.org Subject: [Idr] 2 week WG LC for draft-ietf-custom-decision (4/20 to 5/4/201= 5) This begins a 2 week WG LC for the following draft: http://datatracker.ietf.org/doc/draft-ietf-idr-custom-decision The authors should comment on the existence of IPR on the list, and the ava= ilability of implementations. A set of questions for this WG LC are: 1) Is this custom-decision useful in networks? 2) Is there any concern regarding standardization or deployment regard= ing this standard? 3) Do you know if interoperable implementations? If so, can you share = your experience regarding the interoperability. As always, it is important to indicate "support" or "no support" for the WG= LC. 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_53C29892C857584299CBF5D05346208A0EBAA545PEXCVZYM11corpo_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all,=

&n= bsp;

Please = find below some comments on the document:

&n= bsp;

=A7 Abs= tract

*) R= 20;It is cumbersome (if at all possible) for the end user to define policie= s that will select, after partial comparison, a path based on subjective lo= cal (domain and/or node) criteria.”

IMHO th= e sentence may be reworded. e.g. using a more factual/neutral orientation. = (Alternatively, the document would need to elaborate on how much “cum= bersome”/”impossible” is saved by using this new tool. (definitely not all IMO)).

&n= bsp;

=A7 3.  The BGP Cost C= ommunity

*) R= 20;The Point of Insertion sub-field contains the value of the path attribut= e *after* which this community MUST be considered during the best path sele= ction process.”

- My re= ading of “value of the path attribute” is http://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#bgp-par= ameters-2  Is this correct? Probably not as the IANA section of th= is draft propose a new/different registry for POI.

&n= bsp;

*) R= 20;The high-order bit is reserved to indicate that the Cost Community MUST = replace the path attribute specified by the Point of Insertion during the b= est path selection process.”

“= reserved” does not seem to be the best word given that the bit is not= reserved (for future use) but specified in this document.

&n= bsp;

*) R= 20;Multiple Cost Communities may indicate the same Point of Insertion. = ; In this case, the Cost Community with the lowest Community-ID is consider= ed first.”

Multipl= e cost communities may be received with the same Point of Insertion and the= same Community-ID. Please specific which one is to be taken or the error h= andling.

&n= bsp;

=A7 5.&= nbsp; Deployment Considerations

*) R= 20;It is important that a  consistent path selection process be mainta= ined across the local  Autonomous System to avoid potential routing lo= ops.”

How muc= h important?

Given t= he (below) use of a few SHOULD (vs MUST) there is no real assurance that no= routing loops will form:

- ̶= 0;If a BGP speaker receives a path that contains the Cost Community, it SHO= ULD consider its value at the Point of Insertion specified, when  calc= ulating the best path”

- ̶= 0;if the Cost Community is used, all the nodes in the AS that may have to c= onsider this new community at any Point of Insertion SHOULD be  aware = of the mechanisms described in this document.”

&n= bsp;

IMO, ei= ther :s/SHOULD/MUST in the 2 above sentence, or the document must discuss t= he conditions which are safe and the ones which are not.<= /p>

&n= bsp;

*) R= 20;be  aware of the mechanisms described in this document” is no= t enough. It also needs to support the specific POI used.=

&n= bsp;

=A7 6.  Security Consi= derations

&n= bsp;

*) R= 20;This document introduces no new security concerns to BGP or other specif= ications referenced in this document.”

Really?= ? That sentence would rather make me feel that this document is not ready f= or RFC publication.

IMO a r= eal consideration of the security aspects should be done.=

&n= bsp;

e.g. (f= or free):

a) by d= efault, this mechanism is activated.

b) non = compliant implementation will accept and pass transitive Opaque community (= 0x03)

&n= bsp;

= a)      + b): anyone in the Internet can influence the routing in my AS; which= is not acceptable.

&n= bsp;

&n= bsp;

=A7 7.&= nbsp; IANA Considerations

“= Some of the values in this new registry match the values assigned in the BG= P Path Attributes registry [BGP_PAR].  It is RECOMMENDED that an effor= t be made to assign the same values in both tables when applicable.”

If this= is the goal

- both = allocation policies should probably be the same.

- IMHO = the draft should comment on the POI value already assigned to BGP attribute= . Should they be considered “reserved” of free to use as “= ;non applicable”?

- it co= uld be discussed that POI 129 “IGP_COST” may best match BG Attr= ibute 3 NEXT_HOP

&n= bsp;

=A7 App= endix A.  Cost Community Point of Insertion Registry=

*) It l= ooks like this whole section should be in the IANA section, rather than an = appendix.

&n= bsp;

&n= bsp;

Thanks,=

Regards= ,

Bruno

&n= bsp;

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Monday, April 20, 2015 9:34 PM
To: idr@ietf.org
Subject: [Idr] 2 week WG LC for draft-ietf-custom-decision (4/20 to = 5/4/2015)

 

This begins a 2 week WG LC for = the following draft:

 

http://datatracker.ietf.org/doc= /draft-ietf-idr-custom-decision

 

 

The authors should comment on t= he existence of IPR on the list, and the availability of implementations.&n= bsp; A set of questions for this WG LC are:

 

1) &nbs= p;    Is this custom-decision= useful in networks?

2) &nbs= p;    Is there any concern re= garding standardization or deployment regarding this standard?

3) &nbs= p;    Do you know if interope= rable implementations? If so, can you share your experience regarding the i= nteroperability.

 

As always, it is important to i= ndicate “support” or “no support” for the WG LC.

 

Sue Hares and John Scudder &nbs= p;

______________________________________________________________________=
___________________________________________________

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_53C29892C857584299CBF5D05346208A0EBAA545PEXCVZYM11corpo_-- From nobody Wed Apr 22 03:16:54 2015 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 7A5711B33BD for ; Wed, 22 Apr 2015 03:16:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 tH7GIS8IeLw0 for ; Wed, 22 Apr 2015 03:16:46 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 122071A1B79 for ; Wed, 22 Apr 2015 03:16:46 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id 1403F1904BF; Wed, 22 Apr 2015 12:16:44 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id E095A1580A0; Wed, 22 Apr 2015 12:16:43 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0224.002; Wed, 22 Apr 2015 12:16:42 +0200 From: To: DECRAENE Bruno IMT/OLN , Susan Hares Thread-Topic: [Idr] 2 week WG LC for draft-ietf-custom-decision (4/20 to 5/4/2015) Thread-Index: AdB7oHZ7MpCy+WliQDeoG6G90Nwn3ABMujKQAARdZdA= Date: Wed, 22 Apr 2015 10:16:41 +0000 Message-ID: <31018_1429697804_5537750B_31018_3979_1_0ca52d77-3fb6-4476-ba8e-e7b49556c17c@PEXCVZYH01.corporate.adroot.infra.ftgroup> References: <015e01d07ba1$0042bff0$00c83fd0$@ndzh.com> <25797_1429696420_55376FA4_25797_3139_1_53C29892C857584299CBF5D05346208A0EBAA545@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: <25797_1429696420_55376FA4_25797_3139_1_53C29892C857584299CBF5D05346208A0EBAA545@PEXCVZYM11.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: multipart/alternative; boundary="_000_0ca52d773fb64476ba8ee7b49556c17cPEXCVZYH01corporateadro_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.4.22.65722 Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] 2 week WG LC for draft-ietf-custom-decision (4/20 to 5/4/2015) 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, 22 Apr 2015 10:16:52 -0000 --_000_0ca52d773fb64476ba8ee7b49556c17cPEXCVZYH01corporateadro_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 1 possible additional comment =A77. IANA Considerations " IANA is asked to assign the type values indicated in Section 3 to the Cos= t Community in the BGP Opaque Extended Community registry [BGP_EXT]. =BB I'm not sure that you need to ask anything to the IANA given that this part= of the registry is First Come First Served and that the values have alread= y been registered: http://www.iana.org/assignments/bgp-extended-communities/bgp-extended-commu= nities.xhtml#trans-opaque http://www.iana.org/assignments/bgp-extended-communities/bgp-extended-commu= nities.xhtml#non-trans-opaque Regards, Bruno From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of bruno.decraene@orange.= com Sent: Wednesday, April 22, 2015 11:54 AM To: Susan Hares Cc: idr@ietf.org Subject: Re: [Idr] 2 week WG LC for draft-ietf-custom-decision (4/20 to 5/4= /2015) Hi all, Please find below some comments on the document: =A7 Abstract *) "It is cumbersome (if at all possible) for the end user to define polici= es that will select, after partial comparison, a path based on subjective l= ocal (domain and/or node) criteria." IMHO the sentence may be reworded. e.g. using a more factual/neutral orient= ation. (Alternatively, the document would need to elaborate on how much "cu= mbersome"/"impossible" is saved by using this new tool. (definitely not all= IMO)). =A7 3. The BGP Cost Community *) "The Point of Insertion sub-field contains the value of the path attribu= te *after* which this community MUST be considered during the best path sel= ection process." - My reading of "value of the path attribute" is http://www.iana.org/assign= ments/bgp-parameters/bgp-parameters.xhtml#bgp-parameters-2 Is this correct= ? Probably not as the IANA section of this draft propose a new/different re= gistry for POI. *) "The high-order bit is reserved to indicate that the Cost Community MUST= replace the path attribute specified by the Point of Insertion during the = best path selection process." "reserved" does not seem to be the best word given that the bit is not rese= rved (for future use) but specified in this document. *) "Multiple Cost Communities may indicate the same Point of Insertion. In= this case, the Cost Community with the lowest Community-ID is considered f= irst." Multiple cost communities may be received with the same Point of Insertion = and the same Community-ID. Please specific which one is to be taken or the = error handling. =A7 5. Deployment Considerations *) "It is important that a consistent path selection process be maintained= across the local Autonomous System to avoid potential routing loops." How much important? Given the (below) use of a few SHOULD (vs MUST) there is no real assurance = that no routing loops will form: - "If a BGP speaker receives a path that contains the Cost Community, it SH= OULD consider its value at the Point of Insertion specified, when calculat= ing the best path" - "if the Cost Community is used, all the nodes in the AS that may have to = consider this new community at any Point of Insertion SHOULD be aware of t= he mechanisms described in this document." IMO, either :s/SHOULD/MUST in the 2 above sentence, or the document must di= scuss the conditions which are safe and the ones which are not. *) "be aware of the mechanisms described in this document" is not enough. = It also needs to support the specific POI used. =A7 6. Security Considerations *) "This document introduces no new security concerns to BGP or other speci= fications referenced in this document." Really?? That sentence would rather make me feel that this document is not = ready for RFC publication. IMO a real consideration of the security aspects should be done. e.g. (for free): a) by default, this mechanism is activated. b) non compliant implementation will accept and pass transitive Opaque comm= unity (0x03) a) + b): anyone in the Internet can influence the routing in my AS; wh= ich is not acceptable. =A7 7. IANA Considerations "Some of the values in this new registry match the values assigned in the B= GP Path Attributes registry [BGP_PAR]. It is RECOMMENDED that an effort be= made to assign the same values in both tables when applicable." If this is the goal - both allocation policies should probably be the same. - IMHO the draft should comment on the POI value already assigned to BGP at= tribute. Should they be considered "reserved" of free to use as "non applic= able"? - it could be discussed that POI 129 "IGP_COST" may best match BG Attribute= 3 NEXT_HOP =A7 Appendix A. Cost Community Point of Insertion Registry *) It looks like this whole section should be in the IANA section, rather t= han an appendix. Thanks, Regards, Bruno From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Monday, April 20, 2015 9:34 PM To: idr@ietf.org Subject: [Idr] 2 week WG LC for draft-ietf-custom-decision (4/20 to 5/4/201= 5) This begins a 2 week WG LC for the following draft: http://datatracker.ietf.org/doc/draft-ietf-idr-custom-decision The authors should comment on the existence of IPR on the list, and the ava= ilability of implementations. A set of questions for this WG LC are: 1) Is this custom-decision useful in networks? 2) Is there any concern regarding standardization or deployment regard= ing this standard? 3) Do you know if interoperable implementations? If so, can you share = your experience regarding the interoperability. As always, it is important to indicate "support" or "no support" for the WG= LC. 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. ___________________________________________________________________________= ______________________________________________ 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_0ca52d773fb64476ba8ee7b49556c17cPEXCVZYH01corporateadro_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

1 possi= ble additional comment

&n= bsp;

=A77.&n= bsp; IANA Considerations

“= IANA is asked to assign the type values indicated in Section 3 to the Cost= Community in the BGP Opaque Extended Community registry [BGP_EXT]. = =BB

&n= bsp;

I’= ;m not sure that you need to ask anything to the IANA given that this part = of the registry is First Come First Served and that the values have already= been registered:

http://www.iana.org/assignments/bgp-extended= -communities/bgp-extended-communities.xhtml#trans-opaque

http://www.iana.org/assignments/bgp-exte= nded-communities/bgp-extended-communities.xhtml#non-trans-opaque

&n= bsp;

Regards= ,

Bruno

&n= bsp;

&n= bsp;

From: Idr [mai= lto:idr-bounces@ietf.org] On Behalf Of bruno.decraene@orange.com
Sent: Wednesday, April 22, 2015 11:54 AM
To: Susan Hares
Cc: idr@ietf.org
Subject: Re: [Idr] 2 week WG LC for draft-ietf-custom-decision (4/20= to 5/4/2015)

 

Hi all,=

&n= bsp;

Please = find below some comments on the document:

&n= bsp;

=A7 Abs= tract

*) R= 20;It is cumbersome (if at all possible) for the end user to define policie= s that will select, after partial comparison, a path based on subjective lo= cal (domain and/or node) criteria.”

IMHO th= e sentence may be reworded. e.g. using a more factual/neutral orientation. = (Alternatively, the document would need to elaborate on how much “cum= bersome”/”impossible” is saved by using this new tool. (definitely not all IMO)).

&n= bsp;

=A7 3.  The BGP Cost Community

*) R= 20;The Point of Insertion sub-field contains the value of the path attribut= e *after* which this community MUST be considered during the best path sele= ction process.”

- My re= ading of “value of the path attribute” is http://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#bgp-par= ameters-2  Is this correct? Probably not as the IANA section of th= is draft propose a new/different registry for POI.

&n= bsp;

*) R= 20;The high-order bit is reserved to indicate that the Cost Community MUST = replace the path attribute specified by the Point of Insertion during the b= est path selection process.”

“= reserved” does not seem to be the best word given that the bit is not= reserved (for future use) but specified in this document.

&n= bsp;

*) R= 20;Multiple Cost Communities may indicate the same Point of Insertion. = ; In this case, the Cost Community with the lowest Community-ID is consider= ed first.”

Multipl= e cost communities may be received with the same Point of Insertion and the= same Community-ID. Please specific which one is to be taken or the error h= andling.

&n= bsp;

=A7 5.&= nbsp; Deployment Considerations

*) R= 20;It is important that a  consistent path selection process be mainta= ined across the local  Autonomous System to avoid potential routing lo= ops.”

How muc= h important?

Given t= he (below) use of a few SHOULD (vs MUST) there is no real assurance that no= routing loops will form:

- ̶= 0;If a BGP speaker receives a path that contains the Cost Community, it SHO= ULD consider its value at the Point of Insertion specified, when  calc= ulating the best path”

- ̶= 0;if the Cost Community is used, all the nodes in the AS that may have to c= onsider this new community at any Point of Insertion SHOULD be  aware = of the mechanisms described in this document.”

&n= bsp;

IMO, ei= ther :s/SHOULD/MUST in the 2 above sentence, or the document must discuss t= he conditions which are safe and the ones which are not.<= /p>

&n= bsp;

*) R= 20;be  aware of the mechanisms described in this document” is no= t enough. It also needs to support the specific POI used.=

&n= bsp;

=A7 6.  Security Considerations

&n= bsp;

*) R= 20;This document introduces no new security concerns to BGP or other specif= ications referenced in this document.”

Really?= ? That sentence would rather make me feel that this document is not ready f= or RFC publication.

IMO a r= eal consideration of the security aspects should be done.=

&n= bsp;

e.g. (f= or free):

a) by d= efault, this mechanism is activated.

b) non = compliant implementation will accept and pass transitive Opaque community (= 0x03)

&n= bsp;

= a)      + b): anyone in the Internet can influence the routing in my AS; which= is not acceptable.

&n= bsp;

&n= bsp;

=A7 7.&= nbsp; IANA Considerations

“= Some of the values in this new registry match the values assigned in the BG= P Path Attributes registry [BGP_PAR].  It is RECOMMENDED that an effor= t be made to assign the same values in both tables when applicable.”

If this= is the goal

- both = allocation policies should probably be the same.

- IMHO = the draft should comment on the POI value already assigned to BGP attribute= . Should they be considered “reserved” of free to use as “= ;non applicable”?

- it co= uld be discussed that POI 129 “IGP_COST” may best match BG Attr= ibute 3 NEXT_HOP

&n= bsp;

=A7 App= endix A.  Cost Community Point of Insertion Registry=

*) It l= ooks like this whole section should be in the IANA section, rather than an = appendix.

&n= bsp;

&n= bsp;

Thanks,=

Regards= ,

Bruno

&n= bsp;

From: Idr [mailto:i= dr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Monday, April 20, 2015 9:34 PM
To: idr@ietf.org
Subject: [Idr] 2 week WG LC for draft-ietf-custom-decision (4/20 to = 5/4/2015)

 

This begins a 2 week WG LC for = the following draft:

 

http://datatracker.ietf.org/doc= /draft-ietf-idr-custom-decision

 

 

The authors should comment on t= he existence of IPR on the list, and the availability of implementations.&n= bsp; A set of questions for this WG LC are:

 

1) &nbs= p;    Is this custom-decision= useful in networks?

2) &nbs= p;    Is there any concern re= garding standardization or deployment regarding this standard?

3) &nbs= p;    Do you know if interope= rable implementations? If so, can you share your experience regarding the i= nteroperability.

 

As always, it is important to i= ndicate “support” or “no support” for the WG LC.

 

Sue Hares and John Scudder &nbs= p;

______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
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 =
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 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_0ca52d773fb64476ba8ee7b49556c17cPEXCVZYH01corporateadro_-- From nobody Wed Apr 22 07:42:51 2015 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 764871ACD2A; Wed, 22 Apr 2015 07:42:49 -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 ALSzK6bA0-fU; Wed, 22 Apr 2015 07:42:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 232DB1ACD85; Wed, 22 Apr 2015 07:42:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150422144241.24850.20359.idtracker@ietfa.amsl.com> Date: Wed, 22 Apr 2015 07:42:41 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-error-handling-19.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, 22 Apr 2015 14:42:49 -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-19.txt Pages : 18 Date : 2015-04-22 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, because 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 and 6368. 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-19 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-error-handling-19 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 Apr 22 14:04:10 2015 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 BE7A31A892E for ; Wed, 22 Apr 2015 14:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.226 X-Spam-Level: X-Spam-Status: No, score=0.226 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 9L-5RsQ6DKr6 for ; Wed, 22 Apr 2015 14:04:07 -0700 (PDT) Received: from cdcipgw02.twcable.com (cdcipgw02.twcable.com [165.237.91.111]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB061A891B for ; Wed, 22 Apr 2015 14:04:01 -0700 (PDT) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.11,626,1422939600"; d="scan'208,217";a="241742787" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdcipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 22 Apr 2015 16:49:35 -0400 Received: from PRVPEXVS10.corp.twcable.com ([10.136.163.41]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Wed, 22 Apr 2015 17:04:00 -0400 From: "George, Wes" To: "Alvaro Retana (aretana)" , "amante@apple.com" Date: Wed, 22 Apr 2015 17:03:59 -0400 Thread-Topic: 2 Week WG LC on draft-ietf-idr-as-migration (4/9 to 4/23/2105 Thread-Index: AdB9P9rR7TKGavUqTfep9b5hlZBVZA== Message-ID: References: <003f01d07394$9b5f1c00$d21d5400$@ndzh.com> 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.9.150325 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D15D82B64E6ABwesleygeorgetwcablecom_" MIME-Version: 1.0 Archived-At: Cc: Susan Hares , idr wg Subject: Re: [Idr] 2 Week WG LC on draft-ietf-idr-as-migration (4/9 to 4/23/2105 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, 22 Apr 2015 21:04:08 -0000 --_000_D15D82B64E6ABwesleygeorgetwcablecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpGcm9tOiAiQWx2YXJvIFJldGFuYSAoYXJldGFuYSkiIDxhcmV0YW5hQGNpc2NvLmNvbTxtYWls dG86YXJldGFuYUBjaXNjby5jb20+Pg0KRGF0ZTogVHVlc2RheSwgQXByaWwgMjEsIDIwMTUgYXQg NDozOSBQTQ0KVG86ICJHZW9yZ2UsIFdlcyIgPHdlc2xleS5nZW9yZ2VAdHdjYWJsZS5jb208bWFp bHRvOndlc2xleS5nZW9yZ2VAdHdjYWJsZS5jb20+PiwgImFtYW50ZUBhcHBsZS5jb208bWFpbHRv OmFtYW50ZUBhcHBsZS5jb20+IiA8YW1hbnRlQGFwcGxlLmNvbTxtYWlsdG86YW1hbnRlQGFwcGxl LmNvbT4+DQpDYzogIkpvaG4gRy4gU2N1ZGRlciIgPGpnc0BqdW5pcGVyLm5ldDxtYWlsdG86amdz QGp1bmlwZXIubmV0Pj4sIElkciA8aWRyQGlldGYub3JnPG1haWx0bzppZHJAaWV0Zi5vcmc+Piwg U3VzYW4gSGFyZXMgPHNoYXJlc0BuZHpoLmNvbTxtYWlsdG86c2hhcmVzQG5kemguY29tPj4NClN1 YmplY3Q6IFJlOiAyIFdlZWsgV0cgTEMgb24gZHJhZnQtaWV0Zi1pZHItYXMtbWlncmF0aW9uICg0 LzkgdG8gNC8yMy8yMTA1DQoNCk9uIDQvMjEvMTUsIDE6MjYgUE0sICJHZW9yZ2UsIFdlcyIgPHdl c2xleS5nZW9yZ2VAdHdjYWJsZS5jb208bWFpbHRvOndlc2xleS5nZW9yZ2VAdHdjYWJsZS5jb20+ PiB3cm90ZToNCg0KVGhpcyBkb2N1bWVudCBzaG91bGQgYmUgbWFya2VkIGFzIHVwZGF0aW5nIHJm YzQyNzEgYmVjYXVzZSBvZiB0aGUgcHJvY2Vzc2luZyBvZiB0aGUgVVBEQVRFcyAoc2VjdGlvbiAz LjMpLg0KDQpXR10gSGFwcHkgdG8gbWFrZSB0aGF0IGNoYW5nZSwgYnV0IHRoZSByZWFzb24gdGhh dCBpdCB3YXNuJ3QgdGhlcmUgaXMgdGhhdCB0aGlzIGlzbid0IG1hbmRhdG9yeSB0byBpbXBsZW1l bnQuIEl0J3Mgbm90IGdsb2JhbGx5IGNoYW5naW5nIHRoZSBiZWhhdmlvciBvZiBVUERBVEVzLCBi dXQgcmF0aGVyIGRvY3VtZW50aW5nIGhvdyB0aGV5IGNoYW5nZSB3aGVuIHRoaXMgc3BlY2lmaWMg b3B0aW9uYWwgZmVhdHVyZSBzZXQgaXMgaW52b2tlZC4gU29tZW9uZSByZWNlbnRseSBnYXZlIG1l IGd1aWRhbmNlIG9uIGEgZGlmZmVyZW50IGRyYWZ0IHRoYXQgaXQgaXNuJ3QgYWx3YXlzIGFwcHJv cHJpYXRlIHRvIGhhdmUgYSBkcmFmdCB1cGRhdGUgYW4gb2xkIFJGQyBpZiB0aGUgbmV3IHRoaW5n IGlzbid0IG1hbmRhdG9yeSB0byBpbXBsZW1lbnQgYXMgYSBwYXJ0IG9mIHRoZSBvbGQgUkZDIEku ZS4gQSBmb3JtYWwgdXBkYXRlIGluIHRoZSBtZXRhZGF0YSBtZWFucyB0aGF0IHRoZSB0d28gKG9y IG1vcmUpIFJGQ3MgdG9nZXRoZXIgcmVwcmVzZW50IGEgY29tcGxldGUgQkdQIGltcGxlbWVudGF0 aW9uLCB3aGlsZSBvbmx5IGltcGxlbWVudGluZyB0aGUgb3JpZ2luYWwgUkZDICh0aGUgb25lIGJl aW5nIHVwZGF0ZWQpIHdvdWxkIGJlIGFuIGluY29tcGxldGUgaW1wbGVtZW50YXRpb24uIEkgZG9u J3Qga25vdyBpZiB0aGVyZSBpcyBhbiBvZmZpY2lhbCBzdGFuY2Ugb24gdGhpcyBhcyBmYXIgYXMg dGhlIFJGQyBzZXJpZXMgaXMgY29uY2VybmVkLCBzbyBJJ20gb3BlbiB0byBkbyBpdCBlaXRoZXIg d2F5LCBuZWVkIGd1aWRhbmNlIG9uIGhvdyB0byBwcm9jZWVkLg0KDQpJIGludGVycHJldCBpdCB0 aGUgb3RoZXIgd2F5OiB3aGVuIGltcGxlbWVudGluZyB0aGlzIG9wdGlvbmFsIG1lY2hhbmlzbXMg dGhlIGJhc2UgUkZDIGlzIHVwZGF0ZWQuLmFuZCBvbmx5IHdoZW4gdGhlIG9wdGlvbmFsIG1lY2hh bmlzbXMgYXJlIGltcGxlbWVudGVkLg0KDQpMZXTigJlzIGdvIHdpdGggdGhlIHVwZGF0ZSBtYXJr aW5nIGFuZCB3ZSBjYW4gdGFsayBhYm91dCBpdCBpbiB0aGUgSUVTRyBpZiBpdCBjb21lcyB1cC4N Cg0KDQpXR10gSSB0aG91Z2h0IHRoYXQgd2FzIHRoZSByaWdodCBpbnRlcnByZXRhdGlvbiB0b28s IGJ1dCBlbm91Z2ggZm9sa3Mgd2hvIGhhdmUgYmVlbiBhdCB0aGlzIGZhciBsb25nZXIgdGhhbiBJ IHRvbGQgbWUgb3RoZXJ3aXNlLiBIYXZlIGEgbG9vayBhdCB0aGlzIHRocmVhZDogaHR0cHM6Ly9t YWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL3NlYXJjaC8/cT1lcnJhdGErcmZjNDY1OQ0KSSB3YXMg bmV2ZXIgYWJsZSB0byBnZXQgYSBzb2xpZCBwb2ludGVyIHRvIEJDUCBvciBub3JtYXRpdmUgdGV4 dCBvciBldmVuIFJGQyBFZGl0b3IgcG9saWN5IHRvIHN1cHBvcnQgZWl0aGVyIGludGVycHJldGF0 aW9uIG9mIHdoYXQgInVwZGF0ZXMiIGFjdHVhbGx5IG1lYW5zIGluIHRoZSBtZXRhZGF0YSBzbyBJ IG5vdyBoYXZlIG5vIG9waW5pb24gb24gdGhlIG1hdHRlciBhbmQgd2lsbCBnbyB3aXRoIHlvdXIg Z3VpZGFuY2UsIGp1c3QgdGhvdWdodCB5b3UnZCB3YW50IHRoZSBiYWNrZ3JvdW5kIG9mIHdoYXQg SSB3YXMgcmVmZXJyaW5nIHRvIGFib3ZlLg0KDQpUaGFua3MNCldlcw0KDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpUaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0cyBhdHRhY2ht ZW50cyBtYXkgY29udGFpbiBUaW1lIFdhcm5lciBDYWJsZSBwcm9wcmlldGFyeSBpbmZvcm1hdGlv biwgd2hpY2ggaXMgcHJpdmlsZWdlZCwgY29uZmlkZW50aWFsLCBvciBzdWJqZWN0IHRvIGNvcHly aWdodCBiZWxvbmdpbmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1tYWlsIGlzIGludGVu ZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hp Y2ggaXQgaXMgYWRkcmVzc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50 IG9mIHRoaXMgRS1tYWlsLCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNzZW1p bmF0aW9uLCBkaXN0cmlidXRpb24sIGNvcHlpbmcsIG9yIGFjdGlvbiB0YWtlbiBpbiByZWxhdGlv biB0byB0aGUgY29udGVudHMgb2YgYW5kIGF0dGFjaG1lbnRzIHRvIHRoaXMgRS1tYWlsIGlzIHN0 cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGhhdmUgcmVjZWl2 ZWQgdGhpcyBFLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlh dGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYW55IGNvcHkgb2Yg dGhpcyBFLW1haWwgYW5kIGFueSBwcmludG91dC4NCg== --_000_D15D82B64E6ABwesleygeorgetwcablecom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAw KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0K PGRpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19T UkNfQk9EWV9TRUNUSU9OIiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KPGRpdiBzdHlsZT0iZm9u dC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjExcHQ7IHRleHQtYWxpZ246bGVmdDsgY29sb3I6 YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVItTEVGVDogbWVkaXVtIG5v bmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGluOyBQQURESU5HLVJJR0hU OiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JERVItUklHSFQ6IG1lZGl1 bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xk Ij5Gcm9tOiA8L3NwYW4+JnF1b3Q7QWx2YXJvIFJldGFuYSAoYXJldGFuYSkmcXVvdDsgJmx0Ozxh IGhyZWY9Im1haWx0bzphcmV0YW5hQGNpc2NvLmNvbSI+YXJldGFuYUBjaXNjby5jb208L2E+Jmd0 Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+VHVlc2Rh eSwgQXByaWwgMjEsIDIwMTUgYXQgNDozOSBQTTxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdo dDpib2xkIj5UbzogPC9zcGFuPiZxdW90O0dlb3JnZSwgV2VzJnF1b3Q7ICZsdDs8YSBocmVmPSJt YWlsdG86d2VzbGV5Lmdlb3JnZUB0d2NhYmxlLmNvbSI+d2VzbGV5Lmdlb3JnZUB0d2NhYmxlLmNv bTwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86YW1hbnRlQGFwcGxlLmNvbSI+YW1hbnRl QGFwcGxlLmNvbTwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzphbWFudGVAYXBwbGUuY29t Ij5hbWFudGVAYXBwbGUuY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6 Ym9sZCI+Q2M6IDwvc3Bhbj4mcXVvdDtKb2huIEcuIFNjdWRkZXImcXVvdDsgJmx0OzxhIGhyZWY9 Im1haWx0bzpqZ3NAanVuaXBlci5uZXQiPmpnc0BqdW5pcGVyLm5ldDwvYT4mZ3Q7LCBJZHIgJmx0 OzxhIGhyZWY9Im1haWx0bzppZHJAaWV0Zi5vcmciPmlkckBpZXRmLm9yZzwvYT4mZ3Q7LCBTdXNh biBIYXJlcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNoYXJlc0BuZHpoLmNvbSI+c2hhcmVzQG5kemgu Y29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDog PC9zcGFuPlJlOiAyIFdlZWsgV0cgTEMgb24gZHJhZnQtaWV0Zi1pZHItYXMtbWlncmF0aW9uICg0 LzkgdG8gNC8yMy8yMTA1DQo8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3Bh Y2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IGNvbG9yOiByZ2IoMCwg MCwgMCk7IGZvbnQtc2l6ZTogMTRweDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7 Ij4NCjxkaXY+T24gNC8yMS8xNSwgMToyNiBQTSwgJnF1b3Q7R2VvcmdlLCBXZXMmcXVvdDsgJmx0 OzxhIGhyZWY9Im1haWx0bzp3ZXNsZXkuZ2VvcmdlQHR3Y2FibGUuY29tIj53ZXNsZXkuZ2Vvcmdl QHR3Y2FibGUuY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNw YW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9P S19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBz b2xpZDsgUEFERElORzowIDAgMCA1OyBNQVJHSU46MCAwIDAgNTsiPg0KPHNwYW4gaWQ9Ik9MS19T UkNfQk9EWV9TRUNUSU9OIj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdl YmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNw YWNlOyI+DQo8ZGl2PlRoaXMgZG9jdW1lbnQgc2hvdWxkIGJlIG1hcmtlZCBhcyB1cGRhdGluZyBy ZmM0MjcxIGJlY2F1c2Ugb2YgdGhlIHByb2Nlc3Npbmcgb2YgdGhlIFVQREFURXMgKHNlY3Rpb24g My4zKS48L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+V0dd IEhhcHB5IHRvIG1ha2UgdGhhdCBjaGFuZ2UsIGJ1dCB0aGUgcmVhc29uIHRoYXQgaXQgd2Fzbid0 IHRoZXJlIGlzIHRoYXQgdGhpcyBpc24ndCBtYW5kYXRvcnkgdG8gaW1wbGVtZW50LiBJdCdzIG5v dCBnbG9iYWxseSBjaGFuZ2luZyB0aGUgYmVoYXZpb3Igb2YgVVBEQVRFcywgYnV0IHJhdGhlciBk b2N1bWVudGluZyBob3cgdGhleSBjaGFuZ2Ugd2hlbiB0aGlzIHNwZWNpZmljIG9wdGlvbmFsIGZl YXR1cmUgc2V0IGlzIGludm9rZWQuDQogU29tZW9uZSByZWNlbnRseSBnYXZlIG1lIGd1aWRhbmNl IG9uIGEgZGlmZmVyZW50IGRyYWZ0IHRoYXQgaXQgaXNuJ3QgYWx3YXlzIGFwcHJvcHJpYXRlIHRv IGhhdmUgYSBkcmFmdCB1cGRhdGUgYW4gb2xkIFJGQyBpZiB0aGUgbmV3IHRoaW5nIGlzbid0IG1h bmRhdG9yeSB0byBpbXBsZW1lbnQgYXMgYSBwYXJ0IG9mIHRoZSBvbGQgUkZDIEkuZS4gQSBmb3Jt YWwgdXBkYXRlIGluIHRoZSBtZXRhZGF0YSBtZWFucyB0aGF0IHRoZSB0d28gKG9yIG1vcmUpDQog UkZDcyB0b2dldGhlciByZXByZXNlbnQgYSBjb21wbGV0ZSBCR1AgaW1wbGVtZW50YXRpb24sIHdo aWxlIG9ubHkgaW1wbGVtZW50aW5nIHRoZSBvcmlnaW5hbCBSRkMgKHRoZSBvbmUgYmVpbmcgdXBk YXRlZCkgd291bGQgYmUgYW4gaW5jb21wbGV0ZSBpbXBsZW1lbnRhdGlvbi4gSSBkb24ndCBrbm93 IGlmIHRoZXJlIGlzIGFuIG9mZmljaWFsIHN0YW5jZSBvbiB0aGlzIGFzIGZhciBhcyB0aGUgUkZD IHNlcmllcyBpcyBjb25jZXJuZWQsIHNvIEknbQ0KIG9wZW4gdG8gZG8gaXQgZWl0aGVyIHdheSwg bmVlZCBndWlkYW5jZSBvbiBob3cgdG8gcHJvY2VlZC4mbmJzcDs8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvc3Bhbj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkkgaW50ZXJwcmV0IGl0IHRoZSBv dGhlciB3YXk6IHdoZW4gaW1wbGVtZW50aW5nIHRoaXMgb3B0aW9uYWwgbWVjaGFuaXNtcyB0aGUg YmFzZSBSRkMgaXMgdXBkYXRlZC4uYW5kIG9ubHkgd2hlbiB0aGUgb3B0aW9uYWwgbWVjaGFuaXNt cyBhcmUgaW1wbGVtZW50ZWQuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5MZXTigJlz IGdvIHdpdGggdGhlIHVwZGF0ZSBtYXJraW5nIGFuZCB3ZSBjYW4gdGFsayBhYm91dCBpdCBpbiB0 aGUgSUVTRyBpZiBpdCBjb21lcyB1cC48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9zcGFuPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1m YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KPGJyPg0KPC9k aXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJy aSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQpXR10gSSB0aG91Z2h0IHRoYXQgd2Fz IHRoZSByaWdodCBpbnRlcnByZXRhdGlvbiB0b28sIGJ1dCBlbm91Z2ggZm9sa3Mgd2hvIGhhdmUg YmVlbiBhdCB0aGlzIGZhciBsb25nZXIgdGhhbiBJIHRvbGQgbWUgb3RoZXJ3aXNlLiBIYXZlIGEg bG9vayBhdCB0aGlzIHRocmVhZDombmJzcDs8YSBocmVmPSJodHRwczovL21haWxhcmNoaXZlLmll dGYub3JnL2FyY2gvc2VhcmNoLz9xPWVycmF0YSYjNDM7cmZjNDY1OSI+aHR0cHM6Ly9tYWlsYXJj aGl2ZS5pZXRmLm9yZy9hcmNoL3NlYXJjaC8/cT1lcnJhdGEmIzQzO3JmYzQ2NTk8L2E+PC9kaXY+ DQo8ZGl2Pkkgd2FzIG5ldmVyIGFibGUgdG8gZ2V0IGEgc29saWQgcG9pbnRlciB0byBCQ1Agb3Ig bm9ybWF0aXZlIHRleHQgb3IgZXZlbiBSRkMgRWRpdG9yIHBvbGljeSB0byBzdXBwb3J0IGVpdGhl ciBpbnRlcnByZXRhdGlvbiBvZiB3aGF0ICZxdW90O3VwZGF0ZXMmcXVvdDsgYWN0dWFsbHkgbWVh bnMgaW4gdGhlIG1ldGFkYXRhIHNvIEkgbm93IGhhdmUgbm8gb3BpbmlvbiBvbiB0aGUgbWF0dGVy IGFuZCB3aWxsIGdvIHdpdGggeW91ciBndWlkYW5jZSwganVzdCB0aG91Z2h0DQogeW91J2Qgd2Fu dCB0aGUgYmFja2dyb3VuZCBvZiB3aGF0IEkgd2FzIHJlZmVycmluZyB0byBhYm92ZS48L2Rpdj4N CjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoYW5rczwvZGl2Pg0KPGRpdj5XZXM8L2Rpdj4NCjxz cGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiIgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7 IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2Rl OiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJn YigwLCAwLCAwKTsgZm9udC1zaXplOiAxNHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z ZXJpZjsiPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+PGJyPg0K PGhyPg0KPGZvbnQgZmFjZT0iQXJpYWwiIGNvbG9yPSJHcmF5IiBzaXplPSIxIj5UaGlzIEUtbWFp bCBhbmQgYW55IG9mIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBUaW1lIFdhcm5lciBDYWJs ZSBwcm9wcmlldGFyeSBpbmZvcm1hdGlvbiwgd2hpY2ggaXMgcHJpdmlsZWdlZCwgY29uZmlkZW50 aWFsLCBvciBzdWJqZWN0IHRvIGNvcHlyaWdodCBiZWxvbmdpbmcgdG8gVGltZSBXYXJuZXIgQ2Fi bGUuIFRoaXMgRS1tYWlsIGlzIGludGVuZGVkIHNvbGVseQ0KIGZvciB0aGUgdXNlIG9mIHRoZSBp bmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aGljaCBpdCBpcyBhZGRyZXNzZWQuIElmIHlvdSBhcmUg bm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhpcyBFLW1haWwsIHlvdSBhcmUgaGVyZWJ5 IG5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgY29weWluZywg b3IgYWN0aW9uIHRha2VuIGluIHJlbGF0aW9uIHRvIHRoZSBjb250ZW50cyBvZiBhbmQgYXR0YWNo bWVudHMgdG8NCiB0aGlzIEUtbWFpbCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUg dW5sYXdmdWwuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgRS1tYWlsIGluIGVycm9yLCBwbGVh c2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0 aGUgb3JpZ2luYWwgYW5kIGFueSBjb3B5IG9mIHRoaXMgRS1tYWlsIGFuZCBhbnkgcHJpbnRvdXQu PGJyPg0KPC9mb250Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_D15D82B64E6ABwesleygeorgetwcablecom_-- From nobody Wed Apr 22 14:11:42 2015 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 30DF71A8983 for ; Wed, 22 Apr 2015 14:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.475 X-Spam-Level: X-Spam-Status: No, score=-0.475 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 DgilqpYizgLa for ; Wed, 22 Apr 2015 14:11:40 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 9DFFF1A8A12 for ; Wed, 22 Apr 2015 14:11:26 -0700 (PDT) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.11,626,1422939600"; d="scan'208";a="857380466" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 22 Apr 2015 16:54:59 -0400 Received: from PRVPEXVS10.corp.twcable.com ([10.136.163.41]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Wed, 22 Apr 2015 17:10:30 -0400 From: "George, Wes" To: Juan Alcaide , Jeffrey Haas Date: Wed, 22 Apr 2015 17:10:29 -0400 Thread-Topic: [Idr] I-D Action: draft-ietf-idr-as-migration-04.txt Thread-Index: AdB9QMNdKC1UINO9QQ+H654k8g4F2w== Message-ID: References: <20150409140218.22830.31521.idtracker@ietfa.amsl.com> <02e401d072e4$4f5a1cc0$ee0e5640$@ndzh.com> <001f01d07b3f$13ee12f0$3bca38d0$@ndzh.com> <20150421202647.GB1600@pfrc> 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.9.150325 acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "'idr@ietf.org'" , "'jgralak@juniper.net'" , "UTTARO, JAMES" , 'Susan Hares' Subject: Re: [Idr] I-D Action: draft-ietf-idr-as-migration-04.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, 22 Apr 2015 21:11:41 -0000 T24gNC8yMi8xNSwgNToyMCBBTSwgIkp1YW4gQWxjYWlkZSIgPGphbGNhaWRlQGNpc2NvLmNvbT4g d3JvdGU6DQoNCg0KPg0KPkluIGFueWNhc2UsIHNpbmNlIHRoZSBkcmFmdCBkZXNjcmliZXMgbXVs dGlwbGUgdmVuZG9ycyBpbXBsZW1lbnRhdGlvbnMsDQo+aXQNCj5tYXkgYmUgd29ydGggdG8gZGVz Y3JpYmUgdGhlIG5hbWluZyBvZiBvdGhlcnMuDQoNCldHXSBJdCBkb2Vzbid0IHJlYWxseSBkZXNj cmliZSBhbnkgdmVuZG9ycycgaW1wbGVtZW50YXRpb25zIGFueW1vcmUsIGJ1dA0KcmF0aGVyIGFu IGFtYWxnYW0gb2YgbXVsdGlwbGUgaW1wbGVtZW50YXRpb25zLCBhbmQgb25lIG9mIHRoZSBvbmx5 IHBsYWNlcw0KdGhhdCBpdCBkb2VzIChzZWN0aW9uIDQuMSB0aXRsZSkgd2FzIGEgbWlzdGFrZSB0 aGF0IEFsdmFybyBjYXVnaHQgYW5kIEkNCmhhdmUgYWxyZWFkeSBmaXhlZCBpbiB0aGUgcGVuZGlu ZyByZXZpc2lvbi4gSSdkIGVuY291cmFnZSB5b3UgdG8gcmUtcmVhZA0KdGhlIGxhdGVzdCBkcmFm dCBhbmQgaWRlbnRpZnkgYW55IHBsYWNlcyB3aGVyZSB3ZSBhcmUgc3RpbGwgbmFtaW5nIG9uZQ0K dmVuZG9yJ3MgaW1wbGVtZW50YXRpb24gc3VjaCB0aGF0IHdlIG5lZWQgdG8gZGlzY3VzcyB0aGUg bmFtaW5nIG9mIG90aGVycywNCmJlY2F1c2Ugd2UgcHJvYmFibHkgbmVlZCB0byBmaXggdGhhdCB0 b28uDQoNCj4NCj4+IFlvdSBhcmUgd2VsY29tZSB0byBwcm92aWRlIHRleHQgZm9yIHN1Y2ggYSB0 aGluZyBidXQgSSB3b3VsZCBzdWdnZXN0DQo+Pml0J3MNCj4+IG5vdCB3b3J0aCB0aGUgcmV2aWV3 IHRpbWUgb2YgSURSLiAgVGhlIGludHJvZHVjdGlvbiBvZiB0aGUgaW50ZXJuYWwNCj4+dG9nZ2xl DQo+PiB3b3VsZCBlZmZlY3RpdmVseSBpbnN0YW50aWF0ZSBhIHN1Yi1zdGF0ZSBtYWNoaW5lIHdp dGhpbiB0aGUgb3ZlcmFsbA0KPj5zdGF0ZQ0KPj4gbWFjaGluZSBhbmQgYmUgcXVpdGUgdGhlIG1l c3MuICBJIGhhdmUgbG9uZyBzaW5jZSBsb3N0IG15IG5vdGVzIG9uIHRoZQ0KPj5GU00NCj4+IGR1 cmluZyBSRkMgNDI3MSBzdGFuZGFyZGl6YXRpb24gd29yaywgYnV0IGhhZCBub3RlZCB0aGF0IGl0 IGhhZCBzb21lDQo+Pmlzc3Vlcy4NCj4+DQo+PiBGZWVsIGZyZWUgdG8gYXVkaXQgdGhlIEZTTSB0 byBzZWUgaWYgeW91IGNhbiBmaW5kIHRob3NlIGlzc3VlcyBhZ2Fpbg0KPj5hbmQgc2VlDQo+PiBo b3cgdGhpcyB3b3VsZCBpbnRlcmFjdCB3aXRoIHRoZSBlcnJhdGEuIDotKQ0KPg0KPkRvbid0IHdh bnQgdG8gZG8gYSBkZWVwIGluc3BlY3Rpb24gb2YgdGhlIEZTTSA7LSkNCj5JdCdzIHNvbWV0aGlu ZyBtb3JlIGJhc2ljLiBDb25zaWRlcg0KPg0KPi0gWW91IGNhbiBzZW5kIG9ubHkgb25lIEFTIGlu IHlvdXIgb3BlbiBlYWNoIHRpbWUgeW91IHRyeSB0byBlc3RhYmxpc2ggYQ0KPm5ldyBzZXNzaW9u DQo+LSBUaGUgQXMgeW91IHNlbmQgZG9lcyBub3QgZGVwZW5kIG9uIHRoZSBBUyB5b3UgcmVjZWl2 ZSAobm8gbmVnb3RpYXRpb24pDQo+LSBZb3UgY2FuIGFjY2VwdCByZWNlaXZlZCBBUyB0byBiZSBh Y2NlcHRlZCBpZiBpdCdzIG9uZSBvZiB0aGUgMg0KPmNvbmZpZ3VyZWQgb25lcw0KPi0gWW91IG11 c3QgZm9yY2UgQVMgeW91IHNlbmQgYW5kIEFTIHlvdSByZWNlaXZlIHRvIGJlIHRoZSBzYW1lLg0K DQpXR10gSSB0aGluayB0aGUgcG9pbnQgaGVyZSBpcyB0aGF0IGV2ZW4gdGhpcyBtb3JlIGJhc2lj IGd1aWRhbmNlIG5lZWRzIHRvDQpiZSBiYXNoZWQgYWdhaW5zdCB3aGF0IHRoZSBGU00gY3VycmVu dGx5IGRvZXMgdnMgd2hhdCB0aGUgc3BlYyBzYXlzIGl0DQpzaG91bGQgZG8gKG9yIHdvcnNlLCB3 aGVyZSB0aGUgc3BlYyBpcyBhbWJpZ3VvdXMgYW5kIGhhcyBsaWtlbHkgYmVlbg0KaGFuZGxlZCBk aWZmZXJlbnQgd2F5cyBieSBkaWZmZXJlbnQgdmVuZG9ycykgYmVmb3JlIHdlIGNhbiBkZXRlcm1p bmUNCndoZXJlL2lmIGl0J3MgYWN0dWFsbHkgbmVjZXNzYXJ5IHRvIHByb3ZpZGUgZXhwbGljaXQg Z3VpZGFuY2Ugb24gdGhlDQptYXR0ZXIuIFRoZSBwaGlsb3NvcGh5IG9mIHRoZSBkcmFmdCBoYXMg Z2VuZXJhbGx5IGJlZW4gdG8gbm90IGJlIG92ZXJseQ0KcHJvc2NyaXB0aXZlIGFuZCBkaXNjdXNz IHRoZSBkZXNpcmVkIGJlaGF2aW9yLCBhbmQgdGhlbiBsZXQgdGhlDQppbXBsZW1lbnRlcnMgZmln dXJlIG91dCBob3cgdGhhdCBoYXMgdG8gd29yayBpbiB0aGUgZ3V0cyBvZiB0aGVpciBCR1ANCmlt cGxlbWVudGF0aW9uLCBzdWNoIGFzIHdpdGhpbiB0aGVpciBpbXBsZW1lbnRhdGlvbiBvZiBGU00u IElmIHlvdSBjYW4NCnBvaW50IHRvIGd1aWRhbmNlIHRoYXQgd2UgbmVlZCB0byBwcm92aWRlIHRv IHByZXZlbnQgdGhlIGRlc2lyZWQgYmVoYXZpb3INCmZyb20gYmVpbmcgY3JpdGljYWxseSBhbHRl cmVkIGlmIGl0IGlzIGluY29ycmVjdGx5IGltcGxlbWVudGVkIGF0IHRoZSBGU00NCmxldmVsIG9y IGl0IG90aGVyd2lzZSBjcmVhdGVzIGludGVyb3BlcmFiaWxpdHkgaXNzdWVzIGZvciBzb21ldGhp bmcgdGhhdA0KaXMgcHJldHR5IG11Y2ggb25seSBsb2NhbGx5IHNpZ25pZmljYW50LCBJIGNhbiBz ZWUgYWJvdXQgYWRkaW5nIGl0LCBidXQNCnlvdSB3aWxsIGRlZmluaXRlbHkgbmVlZCB0byBwcm92 aWRlIHRleHQsIGFzIEkgYW0gYnkgbm8gbWVhbnMgYW4gZXhwZXJ0IG9uDQpob3cgdGhpcyBpbnRl cmFjdHMgd2l0aCB0aGUgRlNNLg0KDQpUaGFua3MNCldlcw0KDQoNClRoaXMgRS1tYWlsIGFuZCBh bnkgb2YgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIFRpbWUgV2FybmVyIENhYmxlIHByb3By aWV0YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBpcyBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWwsIG9y IHN1YmplY3QgdG8gY29weXJpZ2h0IGJlbG9uZ2luZyB0byBUaW1lIFdhcm5lciBDYWJsZS4gVGhp cyBFLW1haWwgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFs IG9yIGVudGl0eSB0byB3aGljaCBpdCBpcyBhZGRyZXNzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBp bnRlbmRlZCByZWNpcGllbnQgb2YgdGhpcyBFLW1haWwsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVk IHRoYXQgYW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgY29weWluZywgb3IgYWN0aW9u IHRha2VuIGluIHJlbGF0aW9uIHRvIHRoZSBjb250ZW50cyBvZiBhbmQgYXR0YWNobWVudHMgdG8g dGhpcyBFLW1haWwgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJ ZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIEUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0 aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUgdGhlIG9yaWdpbmFs IGFuZCBhbnkgY29weSBvZiB0aGlzIEUtbWFpbCBhbmQgYW55IHByaW50b3V0Lg0K From nobody Wed Apr 22 16:36:14 2015 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 573E41B2B71 for ; Wed, 22 Apr 2015 16:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.055 X-Spam-Level: X-Spam-Status: No, score=-99.055 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, USER_IN_WHITELIST=-100] 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 155xSQAPmlkt for ; Wed, 22 Apr 2015 16:36:11 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id C96461A8AD2 for ; Wed, 22 Apr 2015 16:36:10 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=222.151.138.72; From: "Susan Hares" To: "'George, Wes'" , "'Juan Alcaide'" , "'Jeffrey Haas'" References: <20150409140218.22830.31521.idtracker@ietfa.amsl.com> <02e401d072e4$4f5a1cc0$ee0e5640$@ndzh.com> <001f01d07b3f$13ee12f0$3bca38d0$@ndzh.com> <20150421202647.GB1600@pfrc> In-Reply-To: Date: Wed, 22 Apr 2015 19:35:56 -0400 Message-ID: <002d01d07d55$168b3b60$43a1b220$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF4r1Z2HL4YFm8OUbIc3fl4NvJEkQMc7jnKAeHZrpYCMURyMwGvlBIDA1ULulwCf+QsTwNzHXxiAdKlupsCCDW+ewFzkepwnU2aKpA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: idr@ietf.org, jgralak@juniper.net, "'UTTARO, JAMES'" Subject: Re: [Idr] I-D Action: draft-ietf-idr-as-migration-04.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, 22 Apr 2015 23:36:12 -0000 WG, George, Jeff and Juan:=20 A revision to the state machine in BGP is outside the scope of this = draft. For those who want to participate in a revision of the state = machine, please send me your names. I will put you on a design team to = examine the state machine and provide a draft for the WG group.=20 Sue=20 -----Original Message----- From: George, Wes [mailto:wesley.george@twcable.com]=20 Sent: Wednesday, April 22, 2015 5:10 PM To: Juan Alcaide; Jeffrey Haas Cc: 'idr@ietf.org'; 'jgralak@juniper.net'; UTTARO, JAMES; 'Susan Hares' Subject: Re: [Idr] I-D Action: draft-ietf-idr-as-migration-04.txt On 4/22/15, 5:20 AM, "Juan Alcaide" wrote: > >In anycase, since the draft describes multiple vendors implementations, = >it may be worth to describe the naming of others. WG] It doesn't really describe any vendors' implementations anymore, but = rather an amalgam of multiple implementations, and one of the only = places that it does (section 4.1 title) was a mistake that Alvaro caught = and I have already fixed in the pending revision. I'd encourage you to = re-read the latest draft and identify any places where we are still = naming one vendor's implementation such that we need to discuss the = naming of others, because we probably need to fix that too. > >> You are welcome to provide text for such a thing but I would suggest=20 >>it's not worth the review time of IDR. The introduction of the=20 >>internal toggle would effectively instantiate a sub-state machine=20 >>within the overall state machine and be quite the mess. I have long=20 >>since lost my notes on the FSM during RFC 4271 standardization work,=20 >>but had noted that it had some issues. >> >> Feel free to audit the FSM to see if you can find those issues again=20 >>and see how this would interact with the errata. :-) > >Don't want to do a deep inspection of the FSM ;-) It's something more=20 >basic. Consider > >- You can send only one AS in your open each time you try to establish=20 >a new session >- The As you send does not depend on the AS you receive (no=20 >negotiation) >- You can accept received AS to be accepted if it's one of the 2=20 >configured ones >- You must force AS you send and AS you receive to be the same. WG] I think the point here is that even this more basic guidance needs = to be bashed against what the FSM currently does vs what the spec says = it should do (or worse, where the spec is ambiguous and has likely been = handled different ways by different vendors) before we can determine = where/if it's actually necessary to provide explicit guidance on the = matter. The philosophy of the draft has generally been to not be overly = proscriptive and discuss the desired behavior, and then let the = implementers figure out how that has to work in the guts of their BGP = implementation, such as within their implementation of FSM. If you can = point to guidance that we need to provide to prevent the desired = behavior from being critically altered if it is incorrectly implemented = at the FSM level or it otherwise creates interoperability issues for = something that is pretty much only locally significant, I can see about = adding it, but you will definitely need to provide text, as I am by no = means an expert on how this interacts with the FSM. Thanks Wes This E-mail and any of its attachments may contain Time Warner Cable = proprietary information, which is privileged, confidential, or subject = to copyright belonging to Time Warner Cable. This E-mail is intended = solely for the use of the individual or entity to which it is addressed. = If you are not the intended recipient of this E-mail, you are hereby = notified that any dissemination, distribution, copying, or action taken = in relation to the contents of and attachments to this E-mail is = strictly prohibited and may be unlawful. If you have received this = E-mail in error, please notify the sender immediately and permanently = delete the original and any copy of this E-mail and any printout. From nobody Thu Apr 23 05:12:55 2015 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 30C111B3029 for ; Thu, 23 Apr 2015 05:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IkxLAM_jTFF2 for ; Thu, 23 Apr 2015 05:12:51 -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 319031B3050 for ; Thu, 23 Apr 2015 05:12:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=631; q=dns/txt; s=iport; t=1429791141; x=1431000741; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=nRMBj7TKJfi9swQ3V9WaveA9VF4sLQReDC9k0seWrso=; b=JlpJpdUtEUSQJMgMG6WSfu3MnJ7VYv65HW7kRp5HCH9kjiNqIcRcsUNM CVHvVWmDXVr/plYvn1B/LE81/NG2YAIqGr+N353xWFKx2xpwGmO+bJm0y gTHwSP5bfVeLXuv75EHnf83X/OJgaBpioaW5Ji1QCEYGeBTvkcmNH9Yls o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AYBQB74DhV/40NJK1RCoMMUscHgU+GBAKBOTkTAQEBAQEBAYEKhCEBAQMBOAI/EAtGVwaINggNzFIBAQEBAQEBAQEBAQEBAQEBAQEBFQSLN4QnXQeELQWVQodShi6NbCOED4MXAQEB X-IronPort-AV: E=Sophos;i="5.11,630,1422921600"; d="scan'208";a="143828882" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-7.cisco.com with ESMTP; 23 Apr 2015 12:12:20 +0000 Received: from clubhouse-1.cisco.com (clubhouse-1.cisco.com [64.100.21.13]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t3NCCJ27031395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Apr 2015 12:12:20 GMT Date: Thu, 23 Apr 2015 08:12:18 -0400 (EDT) From: Juan Alcaide To: "George, Wes" In-Reply-To: Message-ID: References: <20150409140218.22830.31521.idtracker@ietfa.amsl.com> <02e401d072e4$4f5a1cc0$ee0e5640$@ndzh.com> <001f01d07b3f$13ee12f0$3bca38d0$@ndzh.com> <20150421202647.GB1600@pfrc> User-Agent: Alpine 2.00 (GSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "'idr@ietf.org'" , "'jgralak@juniper.net'" , "UTTARO, JAMES" , 'Susan Hares' Subject: Re: [Idr] I-D Action: draft-ietf-idr-as-migration-04.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: Thu, 23 Apr 2015 12:12:52 -0000 > > WG] It doesn't really describe any vendors' implementations anymore, but > rather an amalgam of multiple implementations, and one of the only places > that it does (section 4.1 title) was a mistake that Alvaro caught and I > have already fixed in the pending revision. I'd encourage you to re-read > the latest draft and identify any places where we are still naming one > vendor's implementation such that we need to discuss the naming of others, > because we probably need to fix that too. My bad then.. I was looking at https://tools.ietf.org/html/draft-ietf-idr-as-migration-04. Where can I find the latest? From nobody Thu Apr 23 05:17:31 2015 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 D3F041B3059 for ; Thu, 23 Apr 2015 05:17:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.801 X-Spam-Level: X-Spam-Status: No, score=-6.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LtjkXfcLhU1V for ; Thu, 23 Apr 2015 05:17:29 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6526D1B3045 for ; Thu, 23 Apr 2015 05:17:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2072; q=dns/txt; s=iport; t=1429791450; x=1431001050; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=4ric1cCojnDNl/AKOkq5SgrEFCbb8DnMPVxishD+EgQ=; b=j2uqm2PNoqFwuWj/yFqGTSCMis9qiKrLcwwlSDRw3TrR5iTrHTEktnFa Ug4PO07LvIZegdlRYQY2/xO2V2dahRCqo0pgkt+pbjn9kyleG8IWVyEn7 c50rfgnIse/hTe5KTMEaPddll3AwrW3699H6lPqIHd10WQHekSa4TprWE Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AYBQCD4jhV/4oNJK1bgwzPLAKBOUwBAQEBAQGBC4QgAQEBAwFrDgULCw44VwaINgjMZQEBAQEBAQEBAQEBAQEBAQEBAQEZizeFBAeELQWdFIM/jQ2DTiOED4MXAQEB X-IronPort-AV: E=Sophos;i="5.11,630,1422921600"; d="scan'208";a="411048351" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-9.cisco.com with ESMTP; 23 Apr 2015 12:17:29 +0000 Received: from clubhouse-1.cisco.com (clubhouse-1.cisco.com [64.100.21.13]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t3NCHRBI025852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Apr 2015 12:17:28 GMT Date: Thu, 23 Apr 2015 08:17:26 -0400 (EDT) From: Juan Alcaide To: Susan Hares In-Reply-To: <002d01d07d55$168b3b60$43a1b220$@ndzh.com> Message-ID: References: <20150409140218.22830.31521.idtracker@ietfa.amsl.com> <02e401d072e4$4f5a1cc0$ee0e5640$@ndzh.com> <001f01d07b3f$13ee12f0$3bca38d0$@ndzh.com> <20150421202647.GB1600@pfrc> <002d01d07d55$168b3b60$43a1b220$@ndzh.com> User-Agent: Alpine 2.00 (GSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-838832689-1429791447=:5542" Archived-At: Cc: idr@ietf.org, jgralak@juniper.net, "'UTTARO, JAMES'" Subject: Re: [Idr] I-D Action: draft-ietf-idr-as-migration-04.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: Thu, 23 Apr 2015 12:17:31 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-838832689-1429791447=:5542 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 8BIT Let me be clear. I don't want to revise the FSM. With the current FSM, internal BGP alias feature will work if we are strict in how it's implemented. Otherwise, we may have interoperability problems. Basically, it needs to be specified with AS is tried first. Just want to make sure the draft says this explicetely (in its current form it is implied). -J > WG, George, Jeff and Juan: > > A revision to the state machine in BGP is outside the scope of this draft. For those who want to participate in a revision of the state machine, please send me your names. I will put you on a design team to examine the state machine and provide a draft for the WG group. > > Sue > > > WG] I think the point here is that even this more basic guidance needs to be bashed against what the FSM currently does vs what the spec says it should do (or worse, where the spec is ambiguous and has likely been handled different ways by different vendors) before we can determine where/if it's actually necessary to provide explicit guidance on the matter. The philosophy of the draft has generally been to not be overly proscriptive and discuss the desired behavior, and then let the implementers figure out how that has to work in the guts of their BGP implementation, such as within their implementation of FSM. If you can point to guidance that we need to provide to prevent the desired behavior from being critically altered if it is incorrectly implemented at the FSM level or it otherwise creates interoperability issues for something that is pretty much only locally significant, I can see about adding it, but you will definitely need to provide text, as I am by no means an expert on how this interacts with the FSM. > ---559023410-838832689-1429791447=:5542-- From nobody Sun Apr 26 04:53:05 2015 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 8750B1ACDE4; Sun, 26 Apr 2015 04:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dr4pTaL8R8PM; Sun, 26 Apr 2015 04:53:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E40351ACDD4; Sun, 26 Apr 2015 04:53:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150426115301.5905.62975.idtracker@ietfa.amsl.com> Date: Sun, 26 Apr 2015 04:53:01 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-optimal-route-reflection-09.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: Sun, 26 Apr 2015 11:53:03 -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 Optimal Route Reflection (BGP-ORR) Authors : Robert Raszuk Christian Cassar Erik Aman Bruno Decraene Stephane Litkowski Filename : draft-ietf-idr-bgp-optimal-route-reflection-09.txt Pages : 9 Date : 2015-04-26 Abstract: [RFC4456] asserts that, because the Interior Gateway Protocol (IGP) cost to a given point in the network will vary across routers, "the route reflection approach may not yield the same route selection result as that of the full IBGP mesh approach." One practical implication of this assertion is that the deployment of route reflection may thwart the ability to achieve hot potato routing. Hot potato routing attempts to direct traffic to the closest AS egress point in cases where no higher priority policy dictates otherwise. As a consequence of the route reflection method, the choice of exit point for a route reflector and its clients will be the egress point closest to the route reflector - and not necessarily closest to the RR clients. Section 11 of [RFC4456] describes a deployment approach and a set of constraints which, if satsified, would result in the deployment of route reflection yielding the same results as the iBGP full mesh approach. Such a deployment approach would make route reflection compatible with the application of hot potato routing policy. As networks evolved to accommodate architectural requirements of new services, tunneled (LSP/IP tunneling) networks with centralized route reflectors became commonplace. This is one type of common deployment where it would be impractical to satisfy the constraints described in Section 11 of [RFC4456]. Yet, in such an environment, hot potato routing policy remains desirable. This document proposes a new solution which can be deployed to facilitate the application of closest exit point policy in centralized route reflection deployments. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-optimal-route-reflection/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-bgp-optimal-route-reflection-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-optimal-route-reflection-09 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 Sun Apr 26 05:00:12 2015 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 07E631ACE26 for ; Sun, 26 Apr 2015 05:00:11 -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 Qru71dEUcbjm for ; Sun, 26 Apr 2015 05:00:09 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48EA51ACE24 for ; Sun, 26 Apr 2015 05:00:09 -0700 (PDT) Received: by iecrt8 with SMTP id rt8so109920156iec.0 for ; Sun, 26 Apr 2015 05:00:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=NmrMnCKcKJ8nSM3bVw3bPnpI+tSBj65RQNpnPjDaTEo=; b=zXFMytVQ/PQJoCsyaY//ypiIQrO5uYVNEoklFomIrEybFsOQ2U5eXTe7a3xZ5939hz apDTwScBayn2WKijduodvUjWtgggFo5baQtaC7LXQqjM0HOWikeS6+Qa5m1gifJPHzPe zbSFELLs3rMwfLhShBBMANwwHG9+wxNgnoLbDcRvrriUN/8OIKuAdupQYvj2YclZBwnS XzwGYmrJAlhMEoTGsr7gD9mi1CREjAp1MHH5CvEXxWE+3NjG095laZrV4jF+FRS5Mpqp JNXnYrcMxPI44nUajVu1r4InQNxCDq3sAJwVcSX0M8pfLUWhbCKHHzkArooJqDmu3x+6 zFOw== MIME-Version: 1.0 X-Received: by 10.107.34.80 with SMTP id i77mr7922272ioi.33.1430049608808; Sun, 26 Apr 2015 05:00:08 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.107.178.1 with HTTP; Sun, 26 Apr 2015 05:00:08 -0700 (PDT) In-Reply-To: <20150426115418.5905.1601.idtracker@ietfa.amsl.com> References: <20150426115418.5905.1601.idtracker@ietfa.amsl.com> Date: Sun, 26 Apr 2015 14:00:08 +0200 X-Google-Sender-Auth: PDEZHwrJmn0xODsg-cj-wtU42nE Message-ID: From: Robert Raszuk To: idr wg Content-Type: multipart/alternative; boundary=001a11407776f1bfc605149f5ede Archived-At: Subject: [Idr] Fwd: I-D Action: draft-raszuk-idr-bgp-pr-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: Sun, 26 Apr 2015 12:00:11 -0000 --001a11407776f1bfc605149f5ede Content-Type: text/plain; charset=UTF-8 ---------- Forwarded message ---------- From: Date: Sun, Apr 26, 2015 at 1:54 PM Subject: I-D Action: draft-raszuk-idr-bgp-pr-03.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : BGP Path Record Attribute Authors : Robert Raszuk Russ White Jie Dong Filename : draft-raszuk-idr-bgp-pr-03.txt Pages : 11 Date : 2015-04-26 Abstract: The BGP protocol contains number of built in mechanisms which records information about the routers which have processed a specific piece of reachability information critical to insuring only loop free paths are chosen by the protocol. For instance, the AS_PATH, CLUSTER_LIST and ORIGINATOR_ID attributes carry information designed to insure permanent routing loops are not formed in the path chosen towards a particular destination. However, there are no provisions to record other useful information along the path, metadata about the routers through which reachability information has passed which can be helpful to the operator in order to enhance end to end visibility of the BGP control plane. In order to solve this problem this document proposes a new single BGP attribute designed as an generic and extensible container to carry number of new optional information corresponding to the BGP speakers given BGP advertisement (or withdraw) message traverses. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-raszuk-idr-bgp-pr/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-raszuk-idr-bgp-pr-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-raszuk-idr-bgp-pr-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --001a11407776f1bfc605149f5ede Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

-------= --- Forwarded message ----------
From: <interne= t-drafts@ietf.org>
Date: Sun, Apr 26, 2015 at 1:54 PM
S= ubject: I-D Action: draft-raszuk-idr-bgp-pr-03.txt
To: i-d-announce@ietf.org

A New Internet-Dra= ft is available from the on-line Internet-Drafts directories.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= BGP Path Record Attribute
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Robe= rt Raszuk
=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 Russ White
=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 Jie Dong
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-ras= zuk-idr-bgp-pr-03.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 11
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2015-04-26

Abstract:
=C2=A0 =C2=A0The BGP protocol contains number of built in mechanisms which = records
=C2=A0 =C2=A0information about the routers which have processed a specific = piece
=C2=A0 =C2=A0of reachability information critical to insuring only loop fre= e paths
=C2=A0 =C2=A0are chosen by the protocol.=C2=A0 For instance, the AS_PATH, C= LUSTER_LIST
=C2=A0 =C2=A0and ORIGINATOR_ID attributes carry information designed to ins= ure
=C2=A0 =C2=A0permanent routing loops are not formed in the path chosen towa= rds a
=C2=A0 =C2=A0particular destination.=C2=A0 However, there are no provisions= to record
=C2=A0 =C2=A0other useful information along the path, metadata about the ro= uters
=C2=A0 =C2=A0through which reachability information has passed which can be=
=C2=A0 =C2=A0helpful to the operator in order to enhance end to end visibil= ity of
=C2=A0 =C2=A0the BGP control plane.

=C2=A0 =C2=A0In order to solve this problem this document proposes a new si= ngle
=C2=A0 =C2=A0BGP attribute designed as an generic and extensible container = to
=C2=A0 =C2=A0carry number of new optional information corresponding to the = BGP
=C2=A0 =C2=A0speakers given BGP advertisement (or withdraw) message travers= es.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-raszuk-idr-bgp-pr/<= br>
There's also a htmlized version available at:
http://tools.ietf.org/html/draft-raszuk-idr-bgp-pr-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-raszuk-idr-bgp-pr= -03


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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d= -announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--001a11407776f1bfc605149f5ede-- From nobody Sun Apr 26 05:01:50 2015 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 B21CA1ACE2E for ; Sun, 26 Apr 2015 05:01:49 -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 FUM7It9YTreg for ; Sun, 26 Apr 2015 05:01:48 -0700 (PDT) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 432A51A86F7 for ; Sun, 26 Apr 2015 05:01:48 -0700 (PDT) Received: by igblo3 with SMTP id lo3so43321579igb.0 for ; Sun, 26 Apr 2015 05:01:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=5/rwXhSAqPMx/WcZtLK6RjWBT9RT+Ig4lIz2YiO/QKk=; b=aMNhUk/QGQey10fS4CO04IwFWv9Vue1YnhP57tBFUe65uY4uhJpQg9h2o/W/iI6dGL 9Sxbbf+OtVI12lv93V7iGWycScvAKDYXDg7mutv70AU2uuzxBSyKdz7iHBfdZbOMSKgH 8pqVsdFI4VitbTu+T6bwrSf+QHid3dzwoaHTR4pIc/yKDpNRzkG4pdJyjkk0xRcRwvLd AGDd9VBOPxDc/oMllGI7AsTq4xujHb6eMa+3gUxVSdPyOoIP7HO/ndNW+965nywmwwaM mYU6oImuO0UCZn3U0kQfW8ely1TKpQR23QYk8h85wvN/Qo1X4P2fIdbu9XTNAjlzFuQW GPjQ== MIME-Version: 1.0 X-Received: by 10.107.34.80 with SMTP id i77mr7929359ioi.33.1430049707822; Sun, 26 Apr 2015 05:01:47 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.107.178.1 with HTTP; Sun, 26 Apr 2015 05:01:47 -0700 (PDT) In-Reply-To: <20150426120107.7083.83652.idtracker@ietfa.amsl.com> References: <20150426120107.7083.83652.idtracker@ietfa.amsl.com> Date: Sun, 26 Apr 2015 14:01:47 +0200 X-Google-Sender-Auth: R-Shsnoq3bHZCXZ-B0P92oyx0K8 Message-ID: From: Robert Raszuk To: idr wg Content-Type: multipart/alternative; boundary=001a11407776d8945d05149f644a Archived-At: Subject: [Idr] Fwd: I-D Action: draft-patel-raszuk-bgp-vector-routing-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: Sun, 26 Apr 2015 12:01:49 -0000 --001a11407776d8945d05149f644a Content-Type: text/plain; charset=UTF-8 ---------- Forwarded message ---------- From: Date: Sun, Apr 26, 2015 at 2:01 PM Subject: I-D Action: draft-patel-raszuk-bgp-vector-routing-05.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : BGP vector routing. Authors : Robert Raszuk Keyur Patel Burjiz Pithawala Ali Sajassi Eric Osborne Luay Jalil James Uttaro Filename : draft-patel-raszuk-bgp-vector-routing-05.txt Pages : 12 Date : 2015-04-26 Abstract: Network architectures have begun to shift from pure destination based routing to service aware routing. Operator requirements in this space include forcing traffic through particular service nodes (e.g. firewall, NAT) or segments. This document proposes an enhancement to BGP to accommodate these new requirements. This document proposes a pure control plane solution which allows traffic to be routed via an ordered set of transit points (links, nodes, or services) on the way to traffic's destination, with no change in the forwarding plane. This approach is in contrast to other proposal in this space which provide similar capabilities via modifications to the forwarding plane. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-patel-raszuk-bgp-vector-routing/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-patel-raszuk-bgp-vector-routing-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-patel-raszuk-bgp-vector-routing-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --001a11407776d8945d05149f644a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

-------= --- Forwarded message ----------
From: <interne= t-drafts@ietf.org>
Date: Sun, Apr 26, 2015 at 2:01 PM
S= ubject: I-D Action: draft-patel-raszuk-bgp-vector-routing-05.txt
To: i-d-announce@ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= BGP vector routing.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Robe= rt Raszuk
=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 Keyur Patel
=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 Burjiz Pithawala
=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 Ali Sajassi
=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 Eric Osborne
=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 Luay Jalil
=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 James Uttaro
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-pat= el-raszuk-bgp-vector-routing-05.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 12
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2015-04-26

Abstract:
=C2=A0 =C2=A0Network architectures have begun to shift from pure destinatio= n based
=C2=A0 =C2=A0routing to service aware routing.=C2=A0 Operator requirements = in this
=C2=A0 =C2=A0space include forcing traffic through particular service nodes= (e.g.
=C2=A0 =C2=A0firewall, NAT) or segments.=C2=A0 This document proposes an en= hancement to
=C2=A0 =C2=A0BGP to accommodate these new requirements.

=C2=A0 =C2=A0This document proposes a pure control plane solution which all= ows
=C2=A0 =C2=A0traffic to be routed via an ordered set of transit points (lin= ks,
=C2=A0 =C2=A0nodes, or services) on the way to traffic's destination, w= ith no
=C2=A0 =C2=A0change in the forwarding plane.=C2=A0 This approach is in cont= rast to
=C2=A0 =C2=A0other proposal in this space which provide similar capabilitie= s via
=C2=A0 =C2=A0modifications to the forwarding plane.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-patel-ras= zuk-bgp-vector-routing/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-patel-raszuk-bgp-ve= ctor-routing-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-pat= el-raszuk-bgp-vector-routing-05


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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d= -announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--001a11407776d8945d05149f644a-- From nobody Sun Apr 26 20:25:28 2015 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 49E4B1A1A10; Sun, 26 Apr 2015 20:25:25 -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 bFD3M-4a8ICM; Sun, 26 Apr 2015 20:25:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E2211AD0C7; Sun, 26 Apr 2015 20:25:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150427032508.18132.16191.idtracker@ietfa.amsl.com> Date: Sun, 26 Apr 2015 20:25:08 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-sla-exchange-05.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, 27 Apr 2015 03:25:25 -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 : Inter-domain SLA Exchange Authors : Shitanshu Shah Keyur Patel Sandeep Bajaj Luis Tomotaki Mohamed Boucadair Filename : draft-ietf-idr-sla-exchange-05.txt Pages : 24 Date : 2015-04-26 Abstract: Network administrators typically enforce Quality of Service (QoS) policies according to Service Level Agreement (SLA) with their providers. The enforcement of such policies often relies upon vendor-specific configuration language. Both learning of SLA, either thru SLA documents or via some other out-of-band method, and translating them to vendor specific configuration language is a complex, many times manual, process and prone to errors. This document proposes an in-band method of SLA signaling which can help to simplify some of the complexities. This document defines an optional transitive attribute to signal SLA details in-band, across administrative boundaries (considered as Autonomous Systems (AS)), thus simplifying and facilitating some of the complex provisioning tasks. Though the use case with the proposed BGP attribute is explicitly defined in this document, purpose of this attribute is not limited to this use case only. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-sla-exchange/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-sla-exchange-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-sla-exchange-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Apr 27 04:59:14 2015 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 D08291B30E2 for ; Mon, 27 Apr 2015 04:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.21 X-Spam-Level: X-Spam-Status: No, score=-6.21 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id imJZYBS-SQgY for ; Mon, 27 Apr 2015 04:59:11 -0700 (PDT) Received: from sjmda11.webex.com (sjmda11.webex.com [64.68.124.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 692A41B30D9 for ; Mon, 27 Apr 2015 04:59:11 -0700 (PDT) Received: from jva2tc212.webex.com (sjc02-wxp00-lbace03-core-vl120-np10-4.webex.com [64.68.121.248]) by sjmda11.webex.com (Postfix) with ESMTP id 0D0CFC1156 for ; Mon, 27 Apr 2015 11:59:11 +0000 (GMT) Received: from jva2tc212.webex.com (localhost [127.0.0.1]) by jva2tc212.webex.com (Postfix) with ESMTP id B4D9D4B for ; Mon, 27 Apr 2015 11:59:10 +0000 (GMT) Date: Mon, 27 Apr 2015 11:59:10 +0000 (GMT) From: IDR Working Group To: idr@ietf.org Message-ID: <1483329691.28115.1430135950737.JavaMail.nobody@jva2tc212.webex.com> MIME-Version: 1.0 Content-Type: multipart/Mixed; boundary="----=_Part_28113_783684226.1430135950736" X-Priority: 3 Importance: normal Archived-At: Subject: [Idr] WebEx meeting invitation: IDR Interim April 27 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: idr-chairs@tools.ietf.org List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 11:59:13 -0000 ------=_Part_28113_783684226.1430135950736 Content-Type: multipart/Alternative; boundary="----=_Part_28114_863579331.1430135950736" ------=_Part_28114_863579331.1430135950736 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: base64 CkhlbGxvLAoKSURSIFdvcmtpbmcgR3JvdXAgaW52aXRlcyB5b3UgdG8gam9pbiB0aGlzIFdlYkV4 IG1lZXRpbmcuCgoKSURSIEludGVyaW0gQXByaWwgMjcKTW9uZGF5LCBBcHJpbCAyNywgMjAxNQox MDowMCBhbSAgfCAgRWFzdGVybiBEYXlsaWdodCBUaW1lIChOZXcgWW9yaywgR01ULTA0OjAwKSAg fCAgMSBociAzMCBtaW5zCgoKSk9JTiBXRUJFWCBNRUVUSU5HCmh0dHBzOi8vaWV0Zi53ZWJleC5j b20vaWV0Zi9qLnBocD9NVElEPW05ODhhZDA0ZTFiZDQwZGI5YmVlOWY4ZjBjNGYyOTVkMwpNZWV0 aW5nIG51bWJlcjogNjQwIDgyMyAxNzAKTWVldGluZyBwYXNzd29yZDogeWFuZ21vZHVsZXMKCg0K Sk9JTiBCWSBQSE9ORQ0KMS04NzctNjY4LTQ0OTMgQ2FsbC1pbiB0b2xsIGZyZWUgbnVtYmVyIChV Uy9DYW5hZGEpIAoxLTY1MC00NzktMzIwOCBDYWxsLWluIHRvbGwgbnVtYmVyIChVUy9DYW5hZGEp CkFjY2VzcyBjb2RlOiA2NDAgODIzIDE3MAoKVG9sbC1mcmVlIGRpYWxpbmcgcmVzdHJpY3Rpb25z OiAKaHR0cDovL3d3dy53ZWJleC5jb20vcGRmL3RvbGxmcmVlX3Jlc3RyaWN0aW9ucy5wZGYNCg0K CkFkZCB0aGlzIG1lZXRpbmcgdG8geW91ciBjYWxlbmRhcjoKaHR0cHM6Ly9pZXRmLndlYmV4LmNv bS9pZXRmL2oucGhwP01USUQ9bTQ0MjBlZWI0MmZlMWJjOWU5YThiNzU0NjY5MzcwMzc3DQoNCgpD YW4ndCBqb2luIHRoZSBtZWV0aW5nPyBDb250YWN0IHN1cHBvcnQgaGVyZToKaHR0cHM6Ly9pZXRm LndlYmV4LmNvbS9pZXRmL21jCgoKSU1QT1JUQU5UIE5PVElDRTogUGxlYXNlIG5vdGUgdGhhdCB0 aGlzIFdlYkV4IHNlcnZpY2UgYWxsb3dzIGF1ZGlvIGFuZCBvdGhlciBpbmZvcm1hdGlvbiBzZW50 IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBiZSByZWNvcmRlZCwgd2hpY2ggbWF5IGJlIGRpc2NvdmVy YWJsZSBpbiBhIGxlZ2FsIG1hdHRlci4gQnkgam9pbmluZyB0aGlzIHNlc3Npb24sIHlvdSBhdXRv bWF0aWNhbGx5IGNvbnNlbnQgdG8gc3VjaCByZWNvcmRpbmdzLiBJZiB5b3UgZG8gbm90IGNvbnNl bnQgdG8gYmVpbmcgcmVjb3JkZWQsIGRpc2N1c3MgeW91ciBjb25jZXJucyB3aXRoIHRoZSBob3N0 IG9yIGRvIG5vdCBqb2luIHRoZSBzZXNzaW9uLgo= ------=_Part_28114_863579331.1430135950736 Content-Type: text/html;charset=UTF-8 Content-Transfer-Encoding: base64 PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPjxtZXRhIG5hbWU9InZpZXdwb3J0IiBjb250ZW50PSJ3aWR0aD1kZXZpY2Utd2lk dGgsIGluaXRpYWwtc2NhbGU9MSIgLz48Ym9keT48c3R5bGUgdHlwZT0idGV4dC9jc3MiPgpkaXYs cCx0ZCxzcGFuIHt3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7d29yZC1icmVhazogbm9ybWFsO30KCnRh YmxlIHtib3JkZXItY29sbGFwc2U6IHNlcGFyYXRlOyBib3JkZXI6IDA7Ym9yZGVyLXNwYWNpbmc6 IDA7Ym9yZGVyLWNvbG9yOiB3aGl0ZTsgd2lkdGg6MTAwJSFpbXBvcnRhbnQ7d2lkdGg6NTI1cHg7 IG1heC13aWR0aDo1MjVweCFpbXBvcnRhbnQ7IG1pbi13aWR0aDogMjc5cHghaW1wb3J0YW50O30K dHIge2xpbmUtaGVpZ2h0OiAyMHB4O30KCnRkLGEge2ZvbnQtc2l6ZTogMTVweDtmb250LWZhbWls eTogQXJpYWw7Y29sb3I6ICM2NjY2NjY7cGFkZGluZzowO30KPC9zdHlsZT4KCjx0YWJsZSBzdHls ZT0icGFkZGluZzowOyBtYXJnaW46MCIgd2lkdGg9IjEwMCUiIGFsaWduPSJsZWZ0Ij4KICAgPHRy PgogICAgICA8dGQgc3R5bGU9InBhZGRpbmctdG9wOjVweDsiPgogICAgICAgIDx0YWJsZSBzdHls ZT0id2lkdGg6IDUyNXB4O21hcmdpbi1sZWZ0OjVweCIgYWxpZ249ImxlZnQiPgoJCQk8dHI+CgkJ CQk8dGQgdmFsaWduPSJ0b3AiPgoKPHRhYmxlPgogICAgICAgPHRyPgogICAgICAgICAgPHRkIHN0 eWxlPSJmb250LXNpemU6IDE1cHg7Zm9udC1mYW1pbHk6IEFyaWFsO2NvbG9yOiM0RDRENEQiPgog ICAgICAgICAgICAgSGVsbG8sCiAgICAgICAgICA8L3RkPgogICAgICAgPC90cj4KICAgICAgIDx0 cj4KICAgICAgICAgICA8dGQgc3R5bGU9ImZvbnQtc2l6ZTogMTVweDtmb250LWZhbWlseTogQXJp YWw7Y29sb3I6IzRENEQ0RDtwYWRkaW5nLXRvcDoxMHB4OyI+CiAgICAgICAgICAgICAgICBJRFIg V29ya2luZyBHcm91cCBpbnZpdGVzIHlvdSB0byBqb2luIHRoaXMgV2ViRXggbWVldGluZy4KICAg ICAgICAgICAgICAgIAkgICAgICAgICAgIDwvdGQ+CiAgICAgIDwvdHI+CjwvdGFibGU+CgoKCgo8 dGFibGU+PHRyIHN0eWxlPSJsaW5lLWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIw cHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPgoJCQkJCQk8dGFibGUgIHdpZHRoPSIxMDAlIj4K CQkJCQkJCTx0cj4KCQkJCQkJCQk8dGQgc3R5bGU9ImZvbnQtc2l6ZToxNnB4OyBjb2xvcjojNEQ0 RDREIj4KCQkJCQkJCQkJPGI+SURSIEludGVyaW0gQXByaWwgMjc8L2I+CgkJCQkJCQkJPC90ZD4K CQkJCQkJCTwvdHI+CgkJCQkJCQk8dHIgc3R5bGU9Im1hcmdpbjowcHgiPgoJCQkJCQkJCTx0ZD5N b25kYXksIEFwcmlsIDI3LCAyMDE1CgkJCQkJCQkJPC90ZD4KCQkJCQkJCTwvdHI+CgkJCQkJCQk8 dHIgc3R5bGU9Im1hcmdpbjowcHgiPgoJCQkJCQkJCTx0ZD4xMDowMCBhbSZuYnNwOyZuYnNwO3wm bmJzcDsmbmJzcDtFYXN0ZXJuIERheWxpZ2h0IFRpbWUgKE5ldyBZb3JrLCBHTVQtMDQ6MDApJm5i c3A7Jm5ic3A7fCZuYnNwOyZuYnNwOzEgaHIgMzAgbWlucwoJCQkJCQkJCTwvdGQ+CgkJCQkJCQk8 L3RyPgoJCQkJCQk8L3RhYmxlPgoKPHRhYmxlPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDIwcHg7 Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90YWJsZT4KCQkJCQkJ PHRhYmxlIHN0eWxlPSJ3aWR0aDphdXRvOyB3aWR0aDphdXRvIWltcG9ydGFudCI+CgkJCQkJCQk8 dHI+CgkJCQkJCQkJPHRkIHN0eWxlPSJjb2xvcjojMDBBRkY5O2ZvbnQtc2l6ZToxNnB4Ij4KCQkJ CQkJCQkJPGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTk4 OGFkMDRlMWJkNDBkYjliZWU5ZjhmMGM0ZjI5NWQzIgoJCQkJCQkJCQkJc3R5bGU9InRleHQtZGVj b3JhdGlvbjpub25lO2ZvbnQtc2l6ZToxNnB4O2NvbG9yOiMwMEFGRjkiPgoJCQkJCQkJCQkJPGI+ Sm9pbiBXZWJFeCBtZWV0aW5nPC9iPgoJCQkJCQkJCQk8L2E+CgkJCQkJCQkJPC90ZD4KCQkJCQkJ CTwvdHI+CgkJCQkJCTwvdGFibGU+CgkJCQkJCTx0YWJsZSBzdHlsZT0id2lkdGg6YXV0bzsgd2lk dGg6YXV0byFpbXBvcnRhbnQiPgoJCQkJCQkJPHRyIHN0eWxlPSJtYXJnaW46MHB4Ij4KCQkJCQkJ CQk8dGQgc3R5bGU9InBhZGRpbmctcmlnaHQ6IDVweDsiPgoJCQkJCQkJCQlNZWV0aW5nIG51bWJl cjoKCQkJCQkJCQk8L3RkPgoJCQkJCQkJCTx0ZD42NDAgODIzIDE3MAoJCQkJCQkJCTwvdGQ+CgkJ CQkJCQk8L3RyPgoJCQkJCQkJPHRyPgoJCQkJCQkJCTx0ZCBzdHlsZT0icGFkZGluZy1yaWdodDog NXB4OyI+TWVldGluZyBwYXNzd29yZDo8L3RkPgoJCQkJCQkJCTx0ZD55YW5nbW9kdWxlczwvdGQ+ CgkJCQkJCQk8L3RyPgoJCQkJCQk8L3RhYmxlPgoKCgoJCgoJPHRhYmxlPjx0ciBzdHlsZT0ibGlu ZS1oZWlnaHQ6MjBweCI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48L3RyPjwv dGFibGU+PHRhYmxlPjx0cj48dGQgc3R5bGU9ImZvbnQtc2l6ZToxNnB4Ij48Yj5Kb2luIGJ5IHBo b25lPC9iPjwvdGQ+PC90cj48dHIgc3R5bGU9Im1hcmdpbjowcHgiPjx0ZD48Yj4xLTg3Ny02Njgt NDQ5MzwvYj4mbmJzcDtDYWxsLWluIHRvbGwgZnJlZSBudW1iZXIgKFVTL0NhbmFkYSk8L3RkPjwv dHI+PHRyIHN0eWxlPSJtYXJnaW46MHB4Ij48dGQ+PGI+MS02NTAtNDc5LTMyMDg8L2I+Jm5ic3A7 Q2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKTwvdGQ+PC90cj48dHIgc3R5bGU9Im1hcmdp bjowcHgiPjx0ZD5BY2Nlc3MgY29kZTombmJzcDs2NDAgODIzIDE3MDwvdGQ+PC90cj48dHIgc3R5 bGU9Im1hcmdpbjowcHgiPjx0ZD48YSBocmVmPSJodHRwOi8vd3d3LndlYmV4LmNvbS9wZGYvdG9s bGZyZWVfcmVzdHJpY3Rpb25zLnBkZiIgc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25lO2ZvbnQt c2l6ZToxM3B4O2NvbG9yOiMwMEFGRjk7Ij5Ub2xsLWZyZWUgY2FsbGluZyByZXN0cmljdGlvbnM8 L2E+PC90ZD48L3RyPjwvdGFibGU+CgoJCQkJCTx0YWJsZT48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0 OjIwcHgiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPjx0 YWJsZT48dHI+PHRkIHN0eWxlPSJmb250LXNpemU6MTNweCI+PGEgaHJlZj0iaHR0cHM6Ly9pZXRm LndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTQ0MjBlZWI0MmZlMWJjOWU5YThiNzU0NjY5Mzcw Mzc3IiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOm5vbmU7Y29sb3I6IzAwQUZGOTsgZm9udC1zaXpl OjEzcHgiPkFkZCB0aGlzIG1lZXRpbmc8L2E+IHRvIHlvdXIgY2FsZW5kYXIuPC90ZD48L3RyPjwv dGFibGU+Cjx0YWJsZT48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJo ZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+Cjx0YWJsZT4KICAgIDx0cj4KICAg ICAgIDx0ZCBzdHlsZT0iZm9udC1zaXplOiAxM3B4O2ZvbnQtZmFtaWx5OiBBcmlhbDtjb2xvcjog IzY2NjY2NjsiPgogICAgICAgIENhbid0IGpvaW4gdGhlIG1lZXRpbmc/CiAgICAgCTxhIGhyZWY9 Imh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9tYyIgc3R5bGU9InRleHQtZGVjb3JhdGlvbjpu b25lO2ZvbnQtc2l6ZToxM3B4O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOiMwMEFGRjk7Zm9udC1j b2xvcjojMDBBRkY5OyI+CiAgICAgICAgCUNvbnRhY3Qgc3VwcG9ydC48L2E+CgkJPC90ZD4KICAg IDwvdHI+CjwvdGFibGU+Cjx0YWJsZT48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAxMHB4OyI+PHRk IHN0eWxlPSJoZWlnaHQ6MTBweCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+CgkJCQkJCTx0YWJs ZT4KCQkJCQkJCTx0cj4KCQkJCQkJCQk8dGQgc3R5bGU9ImZvbnQtc2l6ZToxMnB4O2NvbG9yOiAj QTBBMEEwOyI+CgkJCQkJCQkJCUlNUE9SVEFOVCBOT1RJQ0U6IFBsZWFzZSBub3RlIHRoYXQgdGhp cyBXZWJFeCBzZXJ2aWNlIGFsbG93cyBhdWRpbyBhbmQgb3RoZXIgaW5mb3JtYXRpb24gc2VudCBk dXJpbmcgdGhlIHNlc3Npb24gdG8gYmUgcmVjb3JkZWQsIHdoaWNoIG1heSBiZSBkaXNjb3ZlcmFi bGUgaW4gYSBsZWdhbCBtYXR0ZXIuIEJ5IGpvaW5pbmcgdGhpcyBzZXNzaW9uLCB5b3UgYXV0b21h dGljYWxseSBjb25zZW50IHRvIHN1Y2ggcmVjb3JkaW5ncy4gSWYgeW91IGRvIG5vdCBjb25zZW50 IHRvIGJlaW5nIHJlY29yZGVkLCBkaXNjdXNzIHlvdXIgY29uY2VybnMgd2l0aCB0aGUgaG9zdCBv ciBkbyBub3Qgam9pbiB0aGUgc2Vzc2lvbi48L3RkPgoJCQkJCQkJPC90cj4KCQkJCQkJPC90YWJs ZT4KCQkJCTwvdGQ+CgkJCTwvdHI+CgkJPC90YWJsZT4KCTwvdGQ+CiAgIDwvdHI+CjwvdGFibGU+ Cgo8L2JvZHk+ ------=_Part_28114_863579331.1430135950736-- ------=_Part_28113_783684226.1430135950736 Content-Type: application/octet-stream; name="WebEx_Meeting.ics" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="WebEx_Meeting.ics" QkVHSU46VkNBTEVOREFSClBST0RJRDotLy9NaWNyb3NvZnQgQ29ycG9yYXRpb24vL091dGxvb2sg MTAuMCBNSU1FRElSLy9FTgpWRVJTSU9OOjIuMApNRVRIT0Q6UkVRVUVTVApCRUdJTjpWVElNRVpP TkUKVFpJRDpFYXN0ZXJuIFRpbWUKQkVHSU46U1RBTkRBUkQKRFRTVEFSVDoyMDEzMTEwMVQwMjAw MDAKUlJVTEU6RlJFUT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0xU1U7QllNT05USD0xMQpUWk9G RlNFVEZST006LTA0MDAKVFpPRkZTRVRUTzotMDUwMApUWk5BTUU6U3RhbmRhcmQgVGltZQpFTkQ6 U1RBTkRBUkQKQkVHSU46REFZTElHSFQKRFRTVEFSVDoyMDEzMDMwMVQwMjAwMDAKUlJVTEU6RlJF UT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0yU1U7QllNT05USD0zClRaT0ZGU0VURlJPTTotMDUw MApUWk9GRlNFVFRPOi0wNDAwClRaTkFNRTpEYXlsaWdodCBTYXZpbmdzIFRpbWUKRU5EOkRBWUxJ R0hUCkVORDpWVElNRVpPTkUKQkVHSU46VkVWRU5UCkFUVEVOREVFO0NOPSIiO1JPTEU9UkVRLVBB UlRJQ0lQQU5UO1JTVlA9VFJVRTpNQUlMVE86aWRyQGlldGYub3JnCk9SR0FOSVpFUjtDTj0iSURS IFdvcmtpbmcgR3JvdXAiOk1BSUxUTzppZHItY2hhaXJzQHRvb2xzLmlldGYub3JnCkRUU1RBUlQ7 VFpJRD0iRWFzdGVybiBUaW1lIjoyMDE1MDQyN1QxMDAwMDAKRFRFTkQ7VFpJRD0iRWFzdGVybiBU aW1lIjoyMDE1MDQyN1QxMTMwMDAKTE9DQVRJT046aHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRm ClRSQU5TUDpPUEFRVUUKU0VRVUVOQ0U6MTQzMDEzNTk1MApVSUQ6YWY3Zjg5Y2EtNjkwNC00NzZl LThiNjMtNzJiMTQyNWMyYjhjCkRUU1RBTVA6MjAxNTA0MjdUMTQwMDAwWgpERVNDUklQVElPTjpc blxuXG5KT0lOIFdFQkVYIE1FRVRJTkdcbmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBo cD9NVElEPW00Y2M3OWNjYzVjNGM0NWUyZjNhNDA1ZjU4MmU1MmUwZVxuTWVldGluZyBudW1iZXI6 IDY0MCA4MjMgMTcwXG5NZWV0aW5nIHBhc3N3b3JkOiB5YW5nbW9kdWxlc1xuXG5cbkpPSU4gQlkg UEhPTkVcbjEtODc3LTY2OC00NDkzIENhbGwtaW4gdG9sbCBmcmVlIG51bWJlciAoVVMvQ2FuYWRh KSBcbjEtNjUwLTQ3OS0zMjA4IENhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSlcbkFjY2Vz cyBjb2RlOiA2NDAgODIzIDE3MFxuXG5Ub2xsLWZyZWUgZGlhbGluZyByZXN0cmljdGlvbnM6IFxu aHR0cDovL3d3dy53ZWJleC5jb20vcGRmL3RvbGxmcmVlX3Jlc3RyaWN0aW9ucy5wZGZcblxuXG5c bkNhbid0IGpvaW4gdGhlIG1lZXRpbmc/IENvbnRhY3Qgc3VwcG9ydCBoZXJlOlxuaHR0cHM6Ly9p ZXRmLndlYmV4LmNvbS9pZXRmL21jXG5cblxuSU1QT1JUQU5UIE5PVElDRTogUGxlYXNlIG5vdGUg dGhhdCB0aGlzIFdlYkV4IHNlcnZpY2UgYWxsb3dzIGF1ZGlvIGFuZCBvdGhlciBpbmZvcm1hdGlv biBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBiZSByZWNvcmRlZCwgd2hpY2ggbWF5IGJlIGRp c2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRlci4gQnkgam9pbmluZyB0aGlzIHNlc3Npb24sIHlv dSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQgdG8gc3VjaCByZWNvcmRpbmdzLiBJZiB5b3UgZG8gbm90 IGNvbnNlbnQgdG8gYmVpbmcgcmVjb3JkZWQsIGRpc2N1c3MgeW91ciBjb25jZXJucyB3aXRoIHRo ZSBob3N0IG9yIGRvIG5vdCBqb2luIHRoZSBzZXNzaW9uLlxuClgtQUxULURFU0M7Rk1UVFlQRT10 ZXh0L2h0bWw6CTxGT05UIFNJWkU9IjEiIEZBQ0U9IkFSSUFMIj4mbmJzcDs8QlI+IDxGT05UIFNJ WkU9IjQiIEZBQ0U9IkFSSUFMIj4JCTxhCQkJCQlocmVmPSJodHRwczovL2lldGYud2ViZXguY29t L2lldGYvai5waHA/TVRJRD1tNGNjNzljY2M1YzRjNDVlMmYzYTQwNWY1ODJlNTJlMGUiPjxGT05U IFNJWkU9IjMiIENPTE9SPSIjMDBBRkY5IiBGQUNFPSJBcmlhbCI+Sm9pbiBXZWJFeCBtZWV0aW5n PC9GT05UPjwvYT4JCQk8dGFibGU+CQkJCTx0cj4JCQkJCTx0ZD4JCQkJCQk8Rk9OVCBTSVpFPSIy IiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPk1lZXRpbmcgbnVtYmVyOjwvRk9OVD4JCQkJ CTwvdGQ+CQkJCQk8dGQ+CQkJCQkJPEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9 ImFyaWFsIj42NDAgODIzIDE3MDwvRk9OVD4JCQkJCTwvdGQ+CQkJCTwvdHI+CQkJPC90YWJsZT4J CQk8dGFibGU+PHRyPjx0ZD48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJp YWwiPk1lZXRpbmcgcGFzc3dvcmQ6PC9GT05UPjwvdGQ+PHRkPjxGT05UIFNJWkU9IjIiICBDT0xP Uj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPnlhbmdtb2R1bGVzPC9GT05UPjwvdGQ+PC90cj48L3Rh YmxlPgkJPC9GT05UPjxGT05UIFNJWkU9IjEiIEZBQ0U9IkFSSUFMIj4mbmJzcDs8QlI+Jm5ic3A7 PEJSPjwvRk9OVD48Rk9OVCBTSVpFPSI0IiBGQUNFPSJBUklBTCI+PEZPTlQgU0laRT0iMyIgQ09M T1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5Kb2luIGJ5IHBob25lPC9GT05UPiZuYnNwOyA8QlI+ PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj48c3Ryb25nPjEtODc3 LTY2OC00NDkzPC9zdHJvbmc+Jm5ic3A7Q2FsbC1pbiB0b2xsIGZyZWUgbnVtYmVyIChVUy9DYW5h ZGEpPC9GT05UPiZuYnNwOyA8QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9 ImFyaWFsIj48c3Ryb25nPjEtNjUwLTQ3OS0zMjA4PC9zdHJvbmc+Jm5ic3A7Q2FsbC1pbiB0b2xs IG51bWJlciAoVVMvQ2FuYWRhKTwvRk9OVD4mbmJzcDsgPEJSPjxGT05UIFNJWkU9IjIiIENPTE9S PSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+QWNjZXNzIGNvZGU6IDY0MCA4MjMgMTcwPC9GT05UPiZu YnNwOyA8QlI+PGEgaHJlZj0iaHR0cDovL3d3dy53ZWJleC5jb20vcGRmL3RvbGxmcmVlX3Jlc3Ry aWN0aW9ucy5wZGYiPjxGT05UIFNJWkU9IjEiIENPTE9SPSIjMDBBRkY5IiBGQUNFPSJhcmlhbCI+ VG9sbC1mcmVlIGNhbGxpbmcgcmVzdHJpY3Rpb25zPC9GT05UPjwvYT4gJm5ic3A7IDxCUj48L0ZP TlQ+PEJSPjxCUj4JJm5ic3A7PEJSPgk8Rk9OVCBTSVpFPSIxIiBDT0xPUj0iIzY2NjY2NiIgRkFD RT0iYXJpYWwiPgkJCQlDYW4ndCBqb2luIHRoZSBtZWV0aW5nPzwvRk9OVD4JPGEgaHJlZj0iaHR0 cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL21jIj4JPEZPTlQgU0laRT0iMSIgQ09MT1I9IiMwMEFG RjkiIEZBQ0U9IkFyaWFsIj5Db250YWN0IHN1cHBvcnQuPC9GT05UPjwvYT4JJm5ic3A7PEJSPiZu YnNwOzxCUj48Rk9OVCBDT0xPUj0iI0EwQTBBMCIgc2l6ZT0iMSIgRkFDRT0iYXJpYWwiPklNUE9S VEFOVCBOT1RJQ0U6IFBsZWFzZSBub3RlIHRoYXQgdGhpcyBXZWJFeCBzZXJ2aWNlIGFsbG93cyBh dWRpbyBhbmQgb3RoZXIgaW5mb3JtYXRpb24gc2VudCBkdXJpbmcgdGhlIHNlc3Npb24gdG8gYmUg cmVjb3JkZWQsIHdoaWNoIG1heSBiZSBkaXNjb3ZlcmFibGUgaW4gYSBsZWdhbCBtYXR0ZXIuIEJ5 IGpvaW5pbmcgdGhpcyBzZXNzaW9uLCB5b3UgYXV0b21hdGljYWxseSBjb25zZW50IHRvIHN1Y2gg cmVjb3JkaW5ncy4gSWYgeW91IGRvIG5vdCBjb25zZW50IHRvIGJlaW5nIHJlY29yZGVkLCBkaXNj dXNzIHlvdXIgY29uY2VybnMgd2l0aCB0aGUgaG9zdCBvciBkbyBub3Qgam9pbiB0aGUgc2Vzc2lv bi48L0ZPTlQ+PC9GT05UPgpTVU1NQVJZOklEUiBJbnRlcmltIEFwcmlsIDI3ClBSSU9SSVRZOjUK Q0xBU1M6UFVCTElDCkJFR0lOOlZBTEFSTQpUUklHR0VSOi1QVDVNCkFDVElPTjpESVNQTEFZCkRF U0NSSVBUSU9OOlJlbWluZGVyCkVORDpWQUxBUk0KRU5EOlZFVkVOVApFTkQ6VkNBTEVOREFSCg== ------=_Part_28113_783684226.1430135950736-- From nobody Mon Apr 27 05:07:23 2015 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 C5C891AC426 for ; Mon, 27 Apr 2015 05:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.054 X-Spam-Level: X-Spam-Status: No, score=-101.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SuUOKk3Ap9xL for ; Mon, 27 Apr 2015 05:07:19 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 59CE71AC3DB for ; Mon, 27 Apr 2015 05:07:19 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=74.43.47.61; From: "Susan Hares" To: References: <794795738.28112.1430135950676.JavaMail.nobody@jva2tc212.webex.com> In-Reply-To: <794795738.28112.1430135950676.JavaMail.nobody@jva2tc212.webex.com> Date: Mon, 27 Apr 2015 08:07:18 -0400 Message-ID: <007701d080e2$b5413c60$1fc3b520$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0078_01D080C1.2E343040" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHaydkpquaZfxE6asIfIk5xUQzTU51MMNaQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: idr@ietf.org Subject: [Idr] FW: WebEx meeting invitation: IDR Interim April 27 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, 27 Apr 2015 12:07:21 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0078_01D080C1.2E343040 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0079_01D080C1.2E343040" ------=_NextPart_001_0079_01D080C1.2E343040 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Agenda for the 4/27/2015 meeting:=20 =20 1) IDR Yang modules [10:00 =E2=80=93 10:45] Keyur Patel, Anees Shaikh, Rob Shakir, Sue Hares =20 2) Open Questions on WG LCs [10:45-11:00]=20 =20 Sue Hares=20 =20 =20 =20 From: IDR Working Group [mailto:messenger@webex.com]=20 Sent: Monday, April 27, 2015 7:59 AM To: shares@ndzh.com Subject: WebEx meeting invitation: IDR Interim April 27 =20 Hello,=20 IDR Working Group invites you to join this WebEx meeting.=20 =20 =20 =20 IDR Interim April 27=20 Monday, April 27, 2015=20 10:00 am | Eastern Daylight Time (New York, GMT-04:00) | 1 hr 30 = mins=20 =20 =20 =20 = Join WebEx meeting=20 =20 Meeting number:=20 640 823 170=20 Meeting password: yangmodules =20 =20 =20 Join by phone 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Access code: 640 823 170 Toll-free calling = restrictions =20 =20 =20 = Add this meeting to your calendar. =20 =20 =20 Can't join the meeting? Contact = support.=20 =20 =20 =20 IMPORTANT NOTICE: Please note that this WebEx service allows audio and = other information sent during the session to be recorded, which may be = discoverable in a legal matter. By joining this session, you = automatically consent to such recordings. If you do not consent to being = recorded, discuss your concerns with the host or do not join the = session. =20 ------=_NextPart_001_0079_01D080C1.2E343040 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Agenda for the 4/27/2015 meeting:

 

1)      = IDR Yang modules [10:00 =E2=80=93 10:45]

Keyur Patel, Anees Shaikh, Rob Shakir, Sue = Hares

 

2)      = Open Questions on WG LCs [10:45-11:00]

 

Sue Hares

 

 

 

From:= = IDR Working Group [mailto:messenger@webex.com]
Sent: Monday, = April 27, 2015 7:59 AM
To: shares@ndzh.com
Subject: = WebEx meeting invitation: IDR Interim April = 27

 

Hello,

IDR Working Group invites you to join this WebEx meeting. =

 

 

 

IDR Interim = April 27 =

Monday, April 27, 2015

10:00 am  |  Eastern Daylight Time (New York, = GMT-04:00)  |  1 hr 30 mins =

 

 

 

Join = WebEx meeting =

 

Meeting number:

640 823 170

Meeting password:

yangmodules

 

 

 

Join by = phone

1-877-668-4493 Call-in toll free number = (US/Canada)

1-650-479-3208 Call-in toll number = (US/Canada)

Access code: 640 823 170

Toll-free = calling = restrictions

 

 

 

Add this = meeting to your = calendar.

 

 

 

Can't join the meeting? Contact support. =

 

 

 

= IMPORTANT NOTICE: Please note that this WebEx service allows audio and = other information sent during the session to be recorded, which may be = discoverable in a legal matter. By joining this session, you = automatically consent to such recordings. If you do not consent to being = recorded, discuss your concerns with the host or do not join the = session.

 

------=_NextPart_001_0079_01D080C1.2E343040-- ------=_NextPart_000_0078_01D080C1.2E343040 Content-Type: application/octet-stream; name="WebEx_Meeting.ics" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="WebEx_Meeting.ics" BEGIN:VCALENDAR=0A= PRODID:-//Microsoft Corporation//Outlook 10.0 MIMEDIR//EN=0A= VERSION:2.0=0A= METHOD:REQUEST=0A= BEGIN:VTIMEZONE=0A= TZID:Eastern Time=0A= BEGIN:STANDARD=0A= DTSTART:20131101T020000=0A= RRULE:FREQ=3DYEARLY;INTERVAL=3D1;BYDAY=3D1SU;BYMONTH=3D11=0A= TZOFFSETFROM:-0400=0A= TZOFFSETTO:-0500=0A= TZNAME:Standard Time=0A= END:STANDARD=0A= BEGIN:DAYLIGHT=0A= DTSTART:20130301T020000=0A= RRULE:FREQ=3DYEARLY;INTERVAL=3D1;BYDAY=3D2SU;BYMONTH=3D3=0A= TZOFFSETFROM:-0500=0A= TZOFFSETTO:-0400=0A= TZNAME:Daylight Savings Time=0A= END:DAYLIGHT=0A= END:VTIMEZONE=0A= BEGIN:VEVENT=0A= ATTENDEE;CN=3D"";ROLE=3DREQ-PARTICIPANT;RSVP=3DTRUE:MAILTO:shares@ndzh.co= m=0A= ORGANIZER;CN=3D"IDR Working Group":MAILTO:idr-chairs@tools.ietf.org=0A= DTSTART;TZID=3D"Eastern Time":20150427T100000=0A= DTEND;TZID=3D"Eastern Time":20150427T113000=0A= LOCATION:https://ietf.webex.com/ietf=0A= TRANSP:OPAQUE=0A= SEQUENCE:1430135950=0A= UID:af7f89ca-6904-476e-8b63-72b1425c2b8c=0A= DTSTAMP:20150427T140000Z=0A= DESCRIPTION:\n\n\nJOIN WEBEX = MEETING\nhttps://ietf.webex.com/ietf/j.php?MTID=3Dm4cc79ccc5c4c45e2f3a405= f582e52e0e\nMeeting number: 640 823 170\nMeeting password: = yangmodules\n\n\nJOIN BY PHONE\n1-877-668-4493 Call-in toll free number = (US/Canada) \n1-650-479-3208 Call-in toll number (US/Canada)\nAccess = code: 640 823 170\n\nToll-free dialing restrictions: = \nhttp://www.webex.com/pdf/tollfree_restrictions.pdf\n\n\n\nCan't join = the meeting? Contact support = here:\nhttps://ietf.webex.com/ietf/mc\n\n\nIMPORTANT NOTICE: Please note = that this WebEx service allows audio and other information sent during = the session to be recorded, which may be discoverable in a legal matter. = By joining this session, you automatically consent to such recordings. = If you do not consent to being recorded, discuss your concerns with the = host or do not join the session.\n=0A= X-ALT-DESC;FMTTYPE=3Dtext/html:  
Join WebEx = meeting =
Meeting number: 640 823 = 170
Meeting = password:yangmodules
 
 
Join by = phone 
1-877-668-4493 Call-in toll free = number (US/Canada) 
1-650-479-3208 Call-in toll number = (US/Canada) 
Access code: 640 823 170 
Toll-free calling = restrictions  


 
Can't join the = meeting? Contact support. =  
 
IMPORTANT NOTICE: Please note that this WebEx service = allows audio and other information sent during the session to be = recorded, which may be discoverable in a legal matter. By joining this = session, you automatically consent to such recordings. If you do not = consent to being recorded, discuss your concerns with the host or do not = join the session.=0A= SUMMARY:IDR Interim April 27=0A= PRIORITY:5=0A= CLASS:PUBLIC=0A= BEGIN:VALARM=0A= TRIGGER:-PT5M=0A= ACTION:DISPLAY=0A= DESCRIPTION:Reminder=0A= END:VALARM=0A= END:VEVENT=0A= END:VCALENDAR=0A= ------=_NextPart_000_0078_01D080C1.2E343040-- From nobody Mon Apr 27 10:35:36 2015 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 E6E4D1A9008; Mon, 27 Apr 2015 10:35:32 -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 8ZGpmtaJgr-R; Mon, 27 Apr 2015 10:35:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A49E91A900A; Mon, 27 Apr 2015 10:35:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150427173531.12417.87681.idtracker@ietfa.amsl.com> Date: Mon, 27 Apr 2015 10:35:31 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-gr-notification-04.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, 27 Apr 2015 17:35:33 -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 : Notification Message support for BGP Graceful Restart Authors : Keyur Patel Rex Fernando John Scudder Jeff Haas Filename : draft-ietf-idr-bgp-gr-notification-04.txt Pages : 7 Date : 2015-04-27 Abstract: The current BGP Graceful Restart mechanism limits the usage of BGP Graceful Restart to BGP protocol messages other than a BGP NOTIFICATION message. This document defines an extension to the BGP Graceful Restart that permits the Graceful Restart procedures to be performed when the BGP speaker receives a BGP NOTIFICATION Message. This document also defines a new BGP NOTIFICATION Cease Error subcode to prevent BGP speakers supporting the extension defined in this document from performing a Graceful Restart. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-gr-notification/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-bgp-gr-notification-04 A diff from the previous version is available at: https:https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-gr-notification-04 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 Apr 27 12:09:21 2015 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 B54791A6F10; Mon, 27 Apr 2015 12:09:20 -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 12yjaWufJvDs; Mon, 27 Apr 2015 12:09:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E9DF71AC420; Mon, 27 Apr 2015 12:09:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150427190917.23075.87417.idtracker@ietfa.amsl.com> Date: Mon, 27 Apr 2015 12:09:17 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-gr-notification-05.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, 27 Apr 2015 19:09:20 -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 : Notification Message support for BGP Graceful Restart Authors : Keyur Patel Rex Fernando John Scudder Jeff Haas Filename : draft-ietf-idr-bgp-gr-notification-05.txt Pages : 7 Date : 2015-04-27 Abstract: The current BGP Graceful Restart mechanism limits the usage of BGP Graceful Restart to BGP protocol messages other than a BGP NOTIFICATION message. This document defines an extension to the BGP Graceful Restart that permits the Graceful Restart procedures to be performed when the BGP speaker receives a BGP NOTIFICATION Message. This document also defines a new BGP NOTIFICATION Cease Error subcode to prevent BGP speakers supporting the extension defined in this document from performing a Graceful Restart. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-gr-notification/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-bgp-gr-notification-05 A diff from the previous version is available at: https:https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-gr-notification-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Apr 28 11:02:01 2015 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 D53431A897C; Tue, 28 Apr 2015 11:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.51 X-Spam-Level: X-Spam-Status: No, score=-0.51 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4b9IRDO9QvkB; Tue, 28 Apr 2015 11:01:59 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 285441A8AB5; Tue, 28 Apr 2015 11:01:56 -0700 (PDT) Received: from global-hq.muada.nl (global-hq.muada.nl [IPv6:2001:470:1f15:8b5:a8f7:f4e5:3e8:856e] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id t3SI1Xcs063315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Apr 2015 20:01:35 +0200 (CEST) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Iljitsch van Beijnum In-Reply-To: <91148102-DADB-42E8-96A0-E89120642894@tislabs.com> Date: Tue, 28 Apr 2015 20:01:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C184296-F426-40EF-9DB6-3AE87C42B516@tislabs.com> <91148102-DADB-42E8-96A0-E89120642894@tislabs.com> To: Sandra Murphy X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "idr@ietf.org wg" , ggm@apnic.net, sidr@ietf.org Subject: [Idr] Levels of BGPsec/RPKI validation, was: Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protocol-11 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, 28 Apr 2015 18:02:01 -0000 On 28 Jan 2015, at 23:38, Sandra Murphy wrote: > idr folk, your attention and comments would be appreciated as well. Since you ask... I'm sending this to both idr and sidr as I think this needs broader = input than just sidr. (And it seems I'm no longer on the sidr list.) I read draft-ietf-sidr-bgpsec-protocol-11 and = draft-lepinski-bgpsec-overview-00.txt as well as RFC 6483. I think what's lacking here is any discussion of what happens when = certificates etc expire. Please stay with me for a bit: RFC 6483 talks about RPKI route validation, which suggests that there = are three possible states: valid unknown invalid where valid is preferred over unknown and unknown over invalid, and: "It is a matter of local routing policy as to whether routes with an = "invalid" validity state are considered to be ineligible for further = consideration in a route selection process." Actually, I think the only reasonable approach is to filter out invalids = and prefer valids over unknowns. The important part here is that if = there's a ROA for 193.0.0.0/21 and then someone announces a more = specific like 193.0.7.0/24, that /24 will be "invalid", so even in = partial deployment RPKI users are protected against malicious or = accidental more specifics. But if invalids are accepted, even with a = very low preference, then they still get to divert traffic. So far, so good. But now what if a certificate expires? We know from the web that this is = extremely common. If an expired certificate means the prefixes involved = are marked invalid, this means that filtering invalids becomes very = problematic: not only will prefixes randomly drop off the net as people = forget to generate or install certificates or RPKI caches get stale, but = if things get really bad the resulting lack of connectivity makes it = impossible to correct the problem... So what we need is for expired certificates to make the affected = prefixes revert to unknown rather than invalid. Turns out, that's what = happens today: http://mailman.nanog.org/pipermail/nanog/2014-December/071907.html However, unless this is specified in one of the related documents other = than the three mentioned above, this seems to be an implementation = choice. I think the above issue needs to be discussed in an update of RFC 6483 = or in one of the BGPsec documents. And there's probably a bit more to think about: wouldn't it make sense = to be able to filter on the signature algorithm at some point during the = transition from one algorithm to the next? Or to be able to filter on = "expired" explicitly? A binary valid/invalid isn't enough. = Valid/unknown/invalid is workable, but maybe four or five levels is even = better. (And have a look at how this works in practice: = http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/command/irg-c= r-book/bgp-m1.html search for PEX.) From nobody Tue Apr 28 11:27:46 2015 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 90D161A894A; Tue, 28 Apr 2015 11:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNmAOyluWUtr; Tue, 28 Apr 2015 11:27:43 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC75C1A020A; Tue, 28 Apr 2015 11:27:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9206; q=dns/txt; s=iport; t=1430245659; x=1431455259; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=tMyQI4zm+1eYV//wRpXJg1Zb7NSTI0yvjidpLUXWXC0=; b=PQwGS7qT6Zk1m5sKIzlWJd30Mly92kPXkbEDUZFqzdpPqcIpBvgkn9ZX PkPbo4vSH9toShTnPO0NHuMjovIj7ZJt4rYPPkn4T/6f4tiG6UrIA0YBK 997iTABMJ5yKFRXFD/AY5vldH6+6hPNlNTuyOgPUjBbZT0Qu9rRYxYQ6k 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CiBgCS0D9V/5ldJa1cgkVHU1yFI8EOPIF8AQuGAgKBO0wBAQEBAQGBC4QgAQEBAwEBAQEqQQsFCwIBCBEDAQILGQsnCx0IAgQBDQUIiBsIDcdeAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4s4hFQgDQQHBoMRgRYFhHSKToIjhASEM4IJgSI9gwyCcIZmg1qDUCNggSccFYE8bwGBAySBHQEBAQ X-IronPort-AV: E=Sophos;i="5.11,665,1422921600"; d="scan'208,217";a="412370647" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 28 Apr 2015 18:27:38 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t3SIRaFi004612 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 Apr 2015 18:27:36 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.111]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0195.001; Tue, 28 Apr 2015 13:27:36 -0500 From: "Roque Gagliano (rogaglia)" To: Iljitsch van Beijnum , Sandra Murphy Thread-Topic: [Idr] Levels of BGPsec/RPKI validation, was: Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protocol-11 Thread-Index: AQHQgd2IxBf3Buc8wUqu36ahK1ga251ivkSa Date: Tue, 28 Apr 2015 18:27:35 +0000 Message-ID: References: <4C184296-F426-40EF-9DB6-3AE87C42B516@tislabs.com> <91148102-DADB-42E8-96A0-E89120642894@tislabs.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_EF4348D391D0334996EE9681630C83F02D173BEBxmbrcdx02ciscoc_" MIME-Version: 1.0 Archived-At: Cc: "idr@ietf.org wg" , "ggm@apnic.net" , "sidr@ietf.org" Subject: Re: [Idr] Levels of BGPsec/RPKI validation, was: Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protocol-11 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, 28 Apr 2015 18:27:45 -0000 --_000_EF4348D391D0334996EE9681630C83F02D173BEBxmbrcdx02ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Iljitsu, It is not an implementation choice, it is by design. If a signed object doe= s not validate (based on whatever reason not just expiration), it is like i= f did not existed. I guess your point is covered. Roque Sent from my HTC ----- Reply message ----- From: "Iljitsch van Beijnum" To: "Sandra Murphy" Cc: "idr@ietf.org wg" , "ggm@apnic.net" , "sid= r@ietf.org" Subject: [Idr] Levels of BGPsec/RPKI validation, was: Re: [sidr] wglc for d= raft-ietf-sidr-bgpsec-protocol-11 Date: Tue, Apr 28, 2015 20:02 On 28 Jan 2015, at 23:38, Sandra Murphy wrote: > idr folk, your attention and comments would be appreciated as well. Since you ask... I'm sending this to both idr and sidr as I think this needs broader input t= han just sidr. (And it seems I'm no longer on the sidr list.) I read draft-ietf-sidr-bgpsec-protocol-11 and draft-lepinski-bgpsec-overvie= w-00.txt as well as RFC 6483. I think what's lacking here is any discussion of what happens when certific= ates etc expire. Please stay with me for a bit: RFC 6483 talks about RPKI route validation, which suggests that there are t= hree possible states: valid unknown invalid where valid is preferred over unknown and unknown over invalid, and: "It is a matter of local routing policy as to whether routes with an "inval= id" validity state are considered to be ineligible for further consideratio= n in a route selection process." Actually, I think the only reasonable approach is to filter out invalids an= d prefer valids over unknowns. The important part here is that if there's a= ROA for 193.0.0.0/21 and then someone announces a more specific like 193.0= .7.0/24, that /24 will be "invalid", so even in partial deployment RPKI use= rs are protected against malicious or accidental more specifics. But if inv= alids are accepted, even with a very low preference, then they still get to= divert traffic. So far, so good. But now what if a certificate expires? We know from the web that this is ex= tremely common. If an expired certificate means the prefixes involved are m= arked invalid, this means that filtering invalids becomes very problematic:= not only will prefixes randomly drop off the net as people forget to gener= ate or install certificates or RPKI caches get stale, but if things get rea= lly bad the resulting lack of connectivity makes it impossible to correct t= he problem... So what we need is for expired certificates to make the affected prefixes r= evert to unknown rather than invalid. Turns out, that's what happens today: http://mailman.nanog.org/pipermail/nanog/2014-December/071907.html However, unless this is specified in one of the related documents other tha= n the three mentioned above, this seems to be an implementation choice. I think the above issue needs to be discussed in an update of RFC 6483 or i= n one of the BGPsec documents. And there's probably a bit more to think about: wouldn't it make sense to b= e able to filter on the signature algorithm at some point during the transi= tion from one algorithm to the next? Or to be able to filter on "expired" e= xplicitly? A binary valid/invalid isn't enough. Valid/unknown/invalid is wo= rkable, but maybe four or five levels is even better. (And have a look at how this works in practice: http://www.cisco.com/c/en/u= s/td/docs/ios-xml/ios/iproute_bgp/command/irg-cr-book/bgp-m1.html search fo= r PEX.) _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr --_000_EF4348D391D0334996EE9681630C83F02D173BEBxmbrcdx02ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Iljitsu,

It is not an implementation choice, it is by design. If a signed objec= t does not validate (based on whatever reason not just expiration), it is l= ike if did not existed. 

I guess your point is covered.

Roque

Sent from my HTC

----- Reply message -----
From: "Iljitsch van Beijnum" <iljitsch@muada.com>
To: "Sandra Murphy" <sandy@tislabs.com>
Cc: "idr@ietf.org wg" <idr@ietf.org>, "ggm@apnic.net&q= uot; <ggm@apnic.net>, "sidr@ietf.org" <sidr@ietf.org>=
Subject: [Idr] Levels of BGPsec/RPKI validation, was: Re: [sidr] wglc for d= raft-ietf-sidr-bgpsec-protocol-11
Date: Tue, Apr 28, 2015 20:02

On 28 Jan 2015, at 23:38, Sandra Murphy <sandy@= tislabs.com> wrote:

> idr folk, your attention and comments would be appreciated as well.
Since you ask...

I'm sending this to both idr and sidr as I think this needs broader input t= han just sidr. (And it seems I'm no longer on the sidr list.)

I read draft-ietf-sidr-bgpsec-protocol-11 and draft-lepinski-bgpsec-overvie= w-00.txt as well as RFC 6483.

I think what's lacking here is any discussion of what happens when certific= ates etc expire. Please stay with me for a bit:

RFC 6483 talks about RPKI route validation, which suggests that there are t= hree possible states:

valid
unknown
invalid

where valid is preferred over unknown and unknown over invalid, and:

"It is a matter of local routing policy as to whether routes with an &= quot;invalid" validity state are considered to be ineligible for furth= er consideration in a route selection process."

Actually, I think the only reasonable approach is to filter out invalids an= d prefer valids over unknowns. The important part here is that if there's a= ROA for 193.0.0.0/21 and then someone announces a more specific like 193.0= .7.0/24, that /24 will be "invalid", so even in partial deployment RPKI users are protected against malicious o= r accidental more specifics. But if invalids are accepted, even with a very= low preference, then they still get to divert traffic.

So far, so good.

But now what if a certificate expires? We know from the web that this is ex= tremely common. If an expired certificate means the prefixes involved are m= arked invalid, this means that filtering invalids becomes very problematic:= not only will prefixes randomly drop off the net as people forget to generate or install certificates or R= PKI caches get stale, but if things get really bad the resulting lack of co= nnectivity makes it impossible to correct the problem...

So what we need is for expired certificates to make the affected prefixes r= evert to unknown rather than invalid. Turns out, that's what happens today:=

http://mailman.nanog.org/pipermail/nanog/2014-December/071907.html<= br>
However, unless this is specified in one of the related documents other tha= n the three mentioned above, this seems to be an implementation choice.

I think the above issue needs to be discussed in an update of RFC 6483 or i= n one of the BGPsec documents.

And there's probably a bit more to think about: wouldn't it make sense to b= e able to filter on the signature algorithm at some point during the transi= tion from one algorithm to the next? Or to be able to filter on "expir= ed" explicitly? A binary valid/invalid isn't enough. Valid/unknown/invalid is workable, but maybe four or five le= vels is even better.

(And have a look at how this works in practice: http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/command/irg-cr= -book/bgp-m1.html search for PEX.)

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/= mailman/listinfo/idr
 --_000_EF4348D391D0334996EE9681630C83F02D173BEBxmbrcdx02ciscoc_-- From nobody Tue Apr 28 12:21:51 2015 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 D3EFB1A0250; Tue, 28 Apr 2015 12:21:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aiwj6SVOaPb7; Tue, 28 Apr 2015 12:21:47 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03DCC1A01BA; Tue, 28 Apr 2015 12:21:46 -0700 (PDT) Received: from [192.168.178.25] (5356AD6E.cm-6-7c.dynamic.ziggo.nl [83.86.173.110]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id t3SJLKr0071532 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Apr 2015 21:21:21 +0200 (CEST) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Iljitsch van Beijnum In-Reply-To: Date: Tue, 28 Apr 2015 21:21:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C184296-F426-40EF-9DB6-3AE87C42B516@tislabs.com> <91148102-DADB-42E8-96A0-E89120642894@tislabs.com> To: "Roque Gagliano (rogaglia)" X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "idr@ietf.org wg" , "sidr@ietf.org" , "ggm@apnic.net" Subject: Re: [Idr] Levels of BGPsec/RPKI validation, was: Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protocol-11 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, 28 Apr 2015 19:21:49 -0000 On 28 Apr 2015, at 20:27, Roque Gagliano (rogaglia) = wrote: > It is not an implementation choice, it is by design. If a signed = object does not validate (based on whatever reason not just expiration), = it is like if did not existed.=20 No... Suppose: ROA: 193.0.0.0/21 up to /21 -> AS 3333 not valid after 20150430 BGP table 29 april: 193.0.0.0/21 3333 -> valid 193.0.0.0/21 4444 -> invalid 193.0.7.0/24 3333 -> invalid 192.0.0.0/16 5555 -> unknown But, two days later, after the ROA expires, do we have this: 193.0.0.0/21 3333 -> unknown 193.0.0.0/21 4444 -> unknown 193.0.7.0/24 3333 -> unknown 192.0.0.0/16 5555 -> unknown or this: 193.0.0.0/21 3333 -> invalid 193.0.0.0/21 4444 -> invalid 193.0.7.0/24 3333 -> invalid 192.0.0.0/16 5555 -> unknown ? You seem to be saying the second, but that wouldn't work, as a simple = mistake would make AS 3333 unreachable. And since you need to connect to = the internet in order to get a new certificate/ROA so you can connect to = the internet... The NANOG link I posted says it's the first case, which would be much = more workable in practice: in that case, if a certificate expires before = a new one is installed, you lose security but not connectivity. As we've = successfully run BGP for 25 years without security, that's bad, but = preferable to being unreachable. Note also that the approach suggested in RFC 6483 and Cisco and Juniper = documentation, where valid > unknown > invalid is not workable because = then can still have traffic flow towards more specific prefixes even = though they're invalid and have a very low local preference. The nice = thing about RPKI is that you can deploy it TODAY if you filter invalids = with the huge upside that you get rid of unauthorized more specifics, = incurring only the very small risk that someone creates ROAs that = conflict with their advertisements. But the real issue is that this isn't written down anywhere as far as I = can tell, so we're dependent on implementers all independently coming up = with the preferred way to handle this. That's never good business for a = standards organization.= From nobody Tue Apr 28 12:37:33 2015 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 434411A6FFA; Tue, 28 Apr 2015 12:37:31 -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 M13r9f_r0MCN; Tue, 28 Apr 2015 12:37:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 34E3A1A6FFE; Tue, 28 Apr 2015 12:37:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150428193729.25450.8108.idtracker@ietfa.amsl.com> Date: Tue, 28 Apr 2015 12:37:29 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-as-migration-05.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, 28 Apr 2015 19:37:31 -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 Mechanisms and Their Effects on the BGP AS_PATH Attribute Authors : Wesley George Shane Amante Filename : draft-ietf-idr-as-migration-05.txt Pages : 16 Date : 2015-04-28 Abstract: This draft discusses some existing commonly-used BGP mechanisms for ASN migration that are not formally part of the BGP4 protocol specification. It is necessary to document these de facto standards to ensure that they are properly supported in future BGP protocol work. 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: https://tools.ietf.org/html/draft-ietf-idr-as-migration-05 A diff from the previous version is available at: https:https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-as-migration-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Apr 28 12:44:09 2015 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 135FF1A8747 for ; Tue, 28 Apr 2015 12:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.125 X-Spam-Level: ** X-Spam-Status: No, score=2.125 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 DUTtpy1z4J5I for ; Tue, 28 Apr 2015 12:44:01 -0700 (PDT) Received: from cdcipgw01.twcable.com (cdcipgw01.twcable.com [165.237.91.110]) by ietfa.amsl.com (Postfix) with ESMTP id 935FA1A038F for ; Tue, 28 Apr 2015 12:44:00 -0700 (PDT) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.11,665,1422939600"; d="scan'208,217";a="289843830" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdcipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 28 Apr 2015 15:35:13 -0400 Received: from PRVPEXVS10.corp.twcable.com ([10.136.163.41]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Tue, 28 Apr 2015 15:43:59 -0400 From: "George, Wes" To: "Alvaro Retana (aretana)" , "amante@apple.com" Date: Tue, 28 Apr 2015 15:43:58 -0400 Thread-Topic: 2 Week WG LC on draft-ietf-idr-as-migration (4/9 to 4/23/2105 Thread-Index: AdCB66tUli0wVbRHTlWeTibFqywhCQ== Message-ID: References: <003f01d07394$9b5f1c00$d21d5400$@ndzh.com> 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.9.150325 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D16534674EEFCwesleygeorgetwcablecom_" MIME-Version: 1.0 Archived-At: Cc: Susan Hares , idr wg Subject: Re: [Idr] 2 Week WG LC on draft-ietf-idr-as-migration (4/9 to 4/23/2105 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, 28 Apr 2015 19:44:07 -0000 --_000_D16534674EEFCwesleygeorgetwcablecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWx2YXJvIOKAkyBBIGZldyBvdXRzdGFuZGluZyBpdGVtcyB0aGF0IHdlIG1heSBuZWVkIHRvIGRp c2N1c3MgaW5saW5lIGJlbG93LiBJJ3ZlIHBvc3RlZCBhIOKAkzA1IHRoYXQgSSBiZWxpZXZlIGFk ZHJlc3NlcyB5b3VyIGNvbW1lbnRzIGFuZCBzbmlwcGVkIHRoZW0gb3V0IG9mIG15IHJlc3BvbnNl LCBleGNlcHQgd2hlcmUgbm90ZWQgYmVsb3cuDQoNClRoYW5rcywNCg0KV2VzDQoNCg0KRnJvbTog IkFsdmFybyBSZXRhbmEgKGFyZXRhbmEpIiA8YXJldGFuYUBjaXNjby5jb208bWFpbHRvOmFyZXRh bmFAY2lzY28uY29tPj4NCkRhdGU6IE1vbmRheSwgQXByaWwgMTMsIDIwMTUgYXQgNDo1MCBQTQ0K VG86ICJHZW9yZ2UsIFdlcyIgPHdlc2xleS5nZW9yZ2VAdHdjYWJsZS5jb208bWFpbHRvOndlc2xl eS5nZW9yZ2VAdHdjYWJsZS5jb20+PiwgImFtYW50ZUBhcHBsZS5jb208bWFpbHRvOmFtYW50ZUBh cHBsZS5jb20+IiA8YW1hbnRlQGFwcGxlLmNvbTxtYWlsdG86YW1hbnRlQGFwcGxlLmNvbT4+DQpD YzogIkpvaG4gRy4gU2N1ZGRlciIgPGpnc0BqdW5pcGVyLm5ldDxtYWlsdG86amdzQGp1bmlwZXIu bmV0Pj4sIElkciA8aWRyQGlldGYub3JnPG1haWx0bzppZHJAaWV0Zi5vcmc+PiwgU3VzYW4gSGFy ZXMgPHNoYXJlc0BuZHpoLmNvbTxtYWlsdG86c2hhcmVzQG5kemguY29tPj4NClN1YmplY3Q6IFJl OiAyIFdlZWsgV0cgTEMgb24gZHJhZnQtaWV0Zi1pZHItYXMtbWlncmF0aW9uICg0LzkgdG8gNC8y My8yMTA1DQoNCg0KSSBkbyBoYXZlIG9uZSBpdGVtIHRoYXQgSSB0aGluayBtYXkgYmUgYWJvdmUg 4oCcbWlub3LigJ06IHdoZW4gdXNpbmcg4oCcTG9jYWwgQVPigJ0sIHdoZW4gc2hvdWxkIHRoZSBB U04gYmUgcHJlcGVuZGVkPyAgV2hlbiBzZW5kaW5nIGVCR1AtcmVjZWl2ZWQgVVBEQVRFcyB0byBp QkdQIG5laWdoYm9ycyAoYXMgaXQgaXMgc3BlY2lmaWVkIGN1cnJlbnRseSksIE9SLCB0aGVuIHJl Y2VpdmluZyB0aG9zZSBlQkdQIFVQREFURXM/ICBJZiBpdCBpcyBub3QgZG9uZSB3aGVuIHJlY2Vp dmluZywgdGhlbiB0aGUgQVNfUEFUSCB3aWxsIGJlIGluY29uc2lzdGVudCBpbiB0aGUgQVMgKHRo ZSBib3JkZXIgcm91dGVyIHdpbGwgaGF2ZSBhIHNob3J0ZXIgQVNfUEFUSCkuICBJIHRoaW5rIHRo aXMgY2FuIGxlYWQgdG8gaW5jb25zaXN0ZW50IHJvdXRlIHNlbGVjdGlvbiAoZ2l2ZW4gdGhhdCB0 aGUgYXR0cmlidXRlcyBhcmUgaW5jb25zaXN0ZW50IGluc2lkZSB0aGUgQVMpLCBidXQgdGhhdCBv ZiBjb3Vyc2UgbWF5IGJlIG1pdGlnYXRlZCBieSB0aGUgZmFjdCB0aGF0IHRoZSBhcHBsaWNhdGlv biBvZiBMb2NhbCBBUyBtYXkgYmUgdG93YXJkcyBzdHViIG5ldHdvcmtzIGluIG1hbnkgKGJ1dCBu b3QgYWxsKSBjYXNlcy4gICBJIHdvdWxkIHJlYWxseSBsaWtlIHRvIGhlYXIgb3RoZXJz4oCZIChi ZXlvbmQgdGhlIGF1dGhvcnMpIG9waW5pb25zLiAgW015IGNvbW1lbnRzICMzIGFuZCAjNyBpbiB0 aGUgTWlub3Igc2VjdGlvbiBiZWxvdyBhcmUgcmVsYXRlZCB0byB0aGlzLl0NCg0KV0ddIGluIHRo ZSBhcHByb3ByaWF0ZSBwbGFjZXMgaW4gc2VjdGlvbiAzLjEgYW5kIDMuMywgSSBhZGRlZCAiaW5z dGFsbGluZyB0aGUgcm91dGUiIHRvIGNsYXJpZnkgdGhhdCB0aGUgYmVoYXZpb3IgdGhhdCBpdCBp cyBwcmVzY3JpYmVzIGJlZm9yZSBpdCBzZW5kcyB1cGRhdGVzIGlzIGFsc28gZG9uZSBsb2NhbGx5 LiBJIHRoaW5rIHRoaXMgaXMgcHJvYmFibHkgdGhlIGJlc3QgY29tcHJvbWlzZSBiZXR3ZWVuIHRo ZSB0d28gZGlmZmVyZW50IGltcGxlbWVudGF0aW9ucyB0aGF0IHdlIGNhbiBnaXZlIHNob3J0IG9m IHdyaXRpbmcgYSBsZW5ndGh5IGRpc2N1c3Npb24gYWxvbmcgdGhlIGxpbmVzIG9mIEplZmYncyBl bWFpbCwgaW5jbHVkaW5nIGRpc2N1c3NpbmcgdGhpcyBpbiB0aGUgY29udGV4dCBvZiB3aGVyZSBv bmUgZG9lcyBsb29wIGRldGVjdGlvbiwgYW5kIHRoZSBmYWN0IHRoYXQgaXQncyBhIFNIT1VMRCBn aXZlcyB1cyB0aGUgcmlnaHQgYW1vdW50IG9mIHdpZ2dsZSByb29tLiBMZXQgbWUga25vdyBpZiB5 b3UgdGhpbmsgbW9yZSBjaGFuZ2VzIGFyZSBuZWNlc3NhcnkuDQoNCg0KTWlub3IgSXNzdWVzOg0K DQogMS4gIDMuMSBzL1dpdGhpbiB0aGUgTG9jLVJJQiBvbiBJU1AgQiBwcmlvciB0byB0aGUgbWln cmF0aW9uLCB0aGUgQVNfUEFUSCB0b3dhcmQgY3VzdG9tZXIgQyB3b3VsZCBhcHBlYXIgYXM6IDY0 NTEwL1dpdGhpbiB0aGUgTG9jLVJJQiBvbiBJU1AgQiBwcmlvciB0byB0aGUgbWlncmF0aW9uLCB0 aGUgQVNfUEFUSCB0b3dhcmQgY3VzdG9tZXIgQyB3b3VsZCBhcHBlYXIgYXM6IDY0NDk2DQoNCldH XSAgU2hhbmUgYW5kIEkgYmVsaWV2ZSB0aGF0IHRoZSBjdXJyZW50IHRleHQgaXMgY29ycmVjdC4g Q2FuIHlvdSBleHBsYWluIHdoeSB5b3UgdGhpbmsgdGhpcyBuZWVkcyB0byBiZSBjaGFuZ2VkPw0K DQogMS4gIFRoZSB3b3JkIOKAnGNhcGFiaWxpdHnigJ0gaXMgdXNlZCBpbiBzZXZlcmFsIHBsYWNl cy4gIFdoaWxlIGl0IGlzIHVzZWQgY29ycmVjdGx5IChmcm9tIGEgbGFuZ3VhZ2UgcG9pbnQgb2Yg dmlldyksIEkgdGhpbmsgaXQgbWF5IGNhdXNlIGNvbmZ1c2lvbiB3aXRoIGEgQkdQIENhcGFiaWxp dHkgKGZvciBleGFtcGxlOiDigJx0aGUgIkludGVybmFsIEJHUCBBUyBNaWdyYXRpb24iICBjYXBh YmlsaXR5IGlzIGVuYWJsZWQgb24gYWxsIGlCR1Agc2Vzc2lvbnMgb24gdGhhdCBkZXZpY2XigJ0p LiAgSSBrbm93IHRoYXQgaW4gdGhpcyBjYXNlIHRoZXJlIGlzIG5vIG5lZ290aWF0aW9uIG9mIGNh cGFiaWxpdGllczsganVzdCB0cnlpbmcgdG8gbWFrZSB0aGUgdGV4dCBjbGVhcmVyLg0KDQpXR10g eW91IGhhdmUgYSB2YWxpZCBwb2ludCwgYnV0IHdlIGFyZW4ndCBleGFjdGx5IHN1cmUgd2hhdCBh IGJldHRlciB3b3JkIHdvdWxkIGJlIOKAkyB0b29sPyBTd2l0Y2g/IEZlYXR1cmU/IE9wdGlvbj8N CldlIHRob3VnaHQgZmVhdHVyZSBzb3VuZGVkIHRvbyB2ZW5kb3IteSwgYW5kIG9wdGlvbiB3YXMg YWxyZWFkeSB1c2VkIHRvIGlkZW50aWZ5IHN1YnNldHMgb2YgdGhlIGZlYXR1cmVzIHdlJ3JlIHN0 YW5kYXJkaXppbmcuIEZXSVcsIDQyNzEgdXNlcyBjYXBhYmlsaXR5IGluIGEgc2ltaWxhciB3YXks IEkuZS4gY2FwaXRhbGl6YXRpb24gaXMgaW1wb3J0YW50IHRvIGRpc2FtYmlndWF0ZSBiZXR3ZWVu IHRoZSB0d28uIEkndmUgbGVmdCBpdCBhcy1pcyBmb3Igbm93LCBiZWNhdXNlIEknbSBub3QgY29u dmluY2VkIHRoYXQgYW55IG9mIHRoZSBhbHRlcm5hdGl2ZXMgSSd2ZSBzdWdnZXN0ZWQgYWN0dWFs bHkgd29ya3Mgd2VsbCBlbm91Z2ggdG8gY2hhbmdlIGl0IGdsb2JhbGx5Lg0KDQogMS4gIDQuMg0K IDIuDQogICAgKiAgIEl0IG1heSBiZSBjbGVhcmVyIGlmIGluc3RlYWQgb2YgImdsb2JhbGx5IGNv bmZpZ3VyZWTigJ0gYW5kICJsb2NhbGx5IGNvbmZpZ3VyZWTigJ0sIOKAnE5ld19BU07igJ0gYW5k IOKAnE9sZF9BU07igJ0gKG9yIHNvbWV0aGluZyB0byB0aGF0IGVmZmVjdCkgYXJlIHVzZWQuDQoN CldHXSBTaGFuZSBhbmQgSSBkaXNhZ3JlZS4gV2UgdGhpbmsgdGhhdCBnbG9iYWwgdnMgbG9jYWwg aXMgdXNlZnVsLCBiZWNhdXNlIHRoZXJlIGlzIGEgbm90aW9uIG9mIGEgZ2xvYmFsIEJHUCBjb25m aWcgdGhhdCBhcHBsaWVzIHRvIGFsbCBuZWlnaGJvcnMgdnMgdGhpbmdzIHRoYXQgYXJlIG5laWdo Ym9yLXNwZWNpZmljIGkuZS4gTG9jYWwgdG8gYSBnaXZlbiBuZWlnaGJvci4NCg0KTml0czoNCg0K IDEuICBJbnRybzoNCiAgICAqICAgVGFrZSB0aGlzICgiYW5kIG1heSBiZSB2ZW5kb3Itc3BlY2lm aWMgaW4gZXhhY3QgaW1wbGVtZW50YXRpb27igJ0pIG91dC4NCiAgICAqICAgcy9UaGVzZSBtZWNo YW5pc21zIGFyZSBsb2NhbCB0byBhIGdpdmVuIEJHUCBTcGVha2VyIGFuZCBkbyBub3QgcmVxdWly ZSBuZWdvdGlhdGlvbiB3aXRoIG9yIGNvb3BlcmF0aW9uIG9mIEJHUCBuZWlnaGJvcnMuIFRoZSBk ZXBsb3ltZW50IG9mIHRoZXNlIG1lY2hhbmlzbXMgZG8gbm90IG5lZWQgdG8gaW50ZXJ3b3JrIHdp dGggb25lIGFub3RoZXIgdG8gYWNjb21wbGlzaCB0aGUgZGVzaXJlZCByZXN1bHRzLCBzbyBzbGln aHQgdmFyaWF0aW9ucyBiZXR3ZWVuIGV4aXN0aW5nIHZlbmRvciBpbXBsZW1lbnRhdGlvbnMgZXhp c3QsIGFuZCB3aWxsIG5vdCBuZWNlc3NhcmlseSBiZSBoYXJtb25pemVkIGR1ZSB0byB0aGlzIGRv Y3VtZW50LiBIb3dldmVyLCBpdCBpcyBuZWNlc3NhcnkuIC4gLi9UaGVzZSBtZWNoYW5pc21zIGFy ZSBsb2NhbCB0byBhIGdpdmVuIEJHUCBTcGVha2VyIGFuZCBkbyBub3QgcmVxdWlyZSBuZWdvdGlh dGlvbiB3aXRoIG9yIGNvb3BlcmF0aW9uIG9mIEJHUCBuZWlnaGJvcnMuICBJdCBpcyBuZWNlc3Nh cnkuIC4gLg0KDQpXR10gSSByZW1vdmVkIHRoZSB2ZW5kb3Itc3BlY2lmaWMgcGFydCBmcm9tIHRo ZSBhYnN0cmFjdCBhbmQgaW50cm8sIGJ1dCBJIGJlbGlldmUgdGhhdCB0aGUgb3RoZXIgcGFydCB0 aGF0IHlvdSBzdWdnZXN0IHJlbW92aW5nIGluIHlvdXIgc2Vjb25kIGJ1bGxldCBhYm92ZSBpcyBp bXBvcnRhbnQuIFdlIGNhbid0IGZvcmNlIHZlbmRvcnMgdG8gaW1wbGVtZW50IGV4YWN0bHkgd2hh dCdzIGRvY3VtZW50ZWQgaGVyZSwgZXNwZWNpYWxseSByZXRyb2FjdGl2ZWx5LCBzbyBJIHRoaW5r IGl0J3MgcmVhc29uYWJsZSB0byBhY2tub3dsZWRnZSB0aGlzIGZhY3QuDQoNCiAxLiAgMy4yIERl bGV0ZSB0aGUgc2Vjb25kIHBhcmFncmFwaCwgd2hpY2ggc3RhcnRzIHdpdGgg4oCcSW4gc29tZSBl eGlzdGluZyBpbXBsZW1lbnRhdGlvbnPigJ0uICAgVGhlbiBmb3IgdGhlIHRoaXJkIHBhcmFncmFw aDogcy9bVGhpcmQgcGFyYWdyYXBoXS9BIHRlcnRpYXJ5IG1lY2hhbmlzbSwgcmVmZXJyZWQgdG8g YXMgIlJlcGxhY2UgT2xkIEFT4oCdIGlzIHVzZWQgdG8gcHJldmVudCByb3V0ZXJzIGZyb20gYXBw ZW5kaW5nIHRoZSBnbG9iYWxseSBjb25maWd1cmVkIEFTTiBpbiBvdXRib3VuZCBCR1AgVVBEQVRF cyB0b3dhcmQgZGlyZWN0bHkgYXR0YWNoZWQgZUJHUCBuZWlnaGJvcnMgdGhhdCBhcmUgdXNpbmcg dGhlICJMb2NhbCBBU+KAnSBtZWNoYW5pc20uICBJbnN0ZWFkLCBvbmx5IHRoZSBBU04gc3BlY2lm aWVkIHVzaW5nIOKAnExvY2FsIEFTIiB3aWxsIGJlIHByZXBlbmRlZCBpbiB0aGUgb3V0Ym91bmQg QkdQIFVQREFURSB0b3dhcmQgdGhlIGN1c3RvbWVyJ3MgbmV0d29yaywgcmVzdG9yaW5nIHRoZSBB U19QQVRIIGxlbmd0aCB0byB3aGF0IGl0IHdoYXQgd2FzIGJlZm9yZSBBUyBNaWdyYXRpb24gb2Nj dXJyZWQuDQoNCldHXSB3ZSB0aGluayB0aGF0IHRoZSBzZWNvbmQgcGFyYWdyYXBoIGlzIGRvY3Vt ZW50aW5nIGV4aXN0aW5nIHByYWN0aWNlL2ltcGxlbWVudGF0aW9ucyBkZXBsb3llZCBpbiB0aGUg ZmllbGQgZm9yIHRoZSBwdXJwb3NlIG9mIGNvbnRleHQgYW5kIGJhY2tncm91bmQgYW5kIHRoaW5r IGl0IHNob3VsZCByZW1haW4gaW4gcGxhY2UsIGFuZCB0aHVzIHRoZSBwcm9wb3NlZCBjaGFuZ2Vz IHRvIHRoZSB0aGlyZCBwYXJhZ3JhcGggYXJlIGR1cGxpY2F0aXZlLg0KDQogMS4gIDMuMyAiV2hl biB0aGUgIkxvY2FsIEFT4oCdIGNhcGFiaWxpdHkgaXMgdXNlZCwgYSBsb2NhbCBBU04gd2lsbCBi ZSBwcm92aWRlZCBpbiB0aGUgY29uZmlndXJhdGlvbiB0aGF0IGlzIGRpZmZlcmVudCBmcm9tIHRo ZSBnbG9iYWxseS1jb25maWd1cmVkIEFTTiBvZiB0aGUgQkdQIHJvdXRlci7igJ0gIERvIHlvdSB3 YW50IHRvIHByb3ZpZGUgc29tZSBndWlkYW5jZSBoZXJlPyAgU0hPVUxEL01VU1QgaXQgYmUgZGlm ZmVyZW50PyAgSSBndWVzcyB0aGVyZeKAmXMgbm8gcmVhbCBoYXJtIChmcm9tIHRoZSBwb2ludCBv ZiB2aWV3IG9mIHRoZSBtZWNoYW5pc21zIGRlZmluZWQpIGlmIGl0IGlzIHRoZSBzYW1lLi4gIFtM YXRlciBpbiB0aGUgcGFyYWdyYXBoIGl0IHNheXMgIk1VU1QgTk9UIHVzZSB0aGUgQVNOIGNvbmZp Z3VyZWQgZ2xvYmFsbHnigJ0sIHNvIEkgZ3Vlc3MgaXQgaXMgaW1wbGljaXQgdGhhdCBpdCBoYXMg dG8gYmUgZGlmZmVyZW50IG9yIG5vdGhpbmcgc2hvdWxkIGhhcHBlbi5dDQoNCldHXSBJJ20gbm90 IGluY2xpbmVkIHRvIGV4cGxpY2l0bHkgZGlzYWxsb3cgaXQgdW5sZXNzIHNvbWVvbmUgY2FuIHRo aW5rIG9mIGEgZmFpbHVyZSBjYXNlIHdlJ3JlIHRyeWluZyB0byBhdm9pZC4gT25lIHdvdWxkIHRo aW5rIHRoYXQgbW9zdCBpbXBsZW1lbnRlcnMgd291bGQgYmUgc21hcnQgZW5vdWdoIHRvIGRvIHRo ZSByaWdodCB0aGluZyBoZXJlLCBlc3BlY2lhbGx5IGluIGxpZ2h0IG9mIG91ciBndWlkYW5jZSBp biBhIGZldyBzZW50ZW5jZXMgYWJvdXQgd2hhdCB0byBkbyBpZiB5b3Ugc3VjY2Vzc2Z1bGx5IGVz dGFibGlzaCBhIEJHUCBzZXNzaW9uIHdpdGggdGhlIGdsb2JhbCBBU04NCg0KIDEuICAzLjMgcy91 c2luZyB0aGUgbG9jYWwgQVNOIGNvbmZpZ3VyZWQvdXNpbmcgdGhlIOKAnExvY2FsIEFT4oCdDQoN CldHXSB3ZSBhcmUgbm90IHJlZmVycmluZyB0byB0aGUgY29tbWFuZCAiTG9jYWwgQVMiIGJ1dCBy YXRoZXIgdGhlIGFjdHVhbCBhdXRvbm9tb3VzIHN5c3RlbSBudW1iZXIgcHJvdmlkZWQgYXMgYSBw YXJhbWV0ZXIgZm9yIHRoZSBsb2NhbCAobmVpZ2hib3Itc3BlY2lmaWMpIGNvbmZpZywgc28gSSB0 aGluayB0aGUgb3JpZ2luYWwgdGV4dCBpcyBtb3JlIGFjY3VyYXRlLg0KDQoNCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NClRoaXMgRS1tYWlsIGFuZCBhbnkgb2YgaXRzIGF0dGFj aG1lbnRzIG1heSBjb250YWluIFRpbWUgV2FybmVyIENhYmxlIHByb3ByaWV0YXJ5IGluZm9ybWF0 aW9uLCB3aGljaCBpcyBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWwsIG9yIHN1YmplY3QgdG8gY29w eXJpZ2h0IGJlbG9uZ2luZyB0byBUaW1lIFdhcm5lciBDYWJsZS4gVGhpcyBFLW1haWwgaXMgaW50 ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3 aGljaCBpdCBpcyBhZGRyZXNzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGll bnQgb2YgdGhpcyBFLW1haWwsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc3Nl bWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgY29weWluZywgb3IgYWN0aW9uIHRha2VuIGluIHJlbGF0 aW9uIHRvIHRoZSBjb250ZW50cyBvZiBhbmQgYXR0YWNobWVudHMgdG8gdGhpcyBFLW1haWwgaXMg c3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgaGF2ZSByZWNl aXZlZCB0aGlzIEUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVk aWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUgdGhlIG9yaWdpbmFsIGFuZCBhbnkgY29weSBv ZiB0aGlzIEUtbWFpbCBhbmQgYW55IHByaW50b3V0Lg0K --_000_D16534674EEFCwesleygeorgetwcablecom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2PkFsdmFybyDigJMgQSBmZXcgb3V0c3RhbmRpbmcgaXRlbXMgdGhhdCB3ZSBtYXkgbmVlZCB0 byBkaXNjdXNzIGlubGluZSBiZWxvdy4gSSd2ZSBwb3N0ZWQgYSDigJMwNSB0aGF0IEkgYmVsaWV2 ZSBhZGRyZXNzZXMgeW91ciBjb21tZW50cyBhbmQgc25pcHBlZCB0aGVtIG91dCBvZiBteSByZXNw b25zZSwgZXhjZXB0IHdoZXJlIG5vdGVkIGJlbG93LjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAw MXB0OyBmb250LXNpemU6IDExcHQ7Ij5UaGFua3MsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEx cHQ7Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsiPldlczxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFw dDsgZm9udC1zaXplOiAxMXB0OyI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7 Ij48YnI+DQo8L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19C T0RZX1NFQ1RJT04iPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXpl OjExcHQ7IHRleHQtYWxpZ246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1 bSBub25lOyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBB RERJTkctTEVGVDogMGluOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYg MXB0IHNvbGlkOyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4N CjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+JnF1b3Q7QWx2YXJv IFJldGFuYSAoYXJldGFuYSkmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzphcmV0YW5hQGNpc2Nv LmNvbSI+YXJldGFuYUBjaXNjby5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdl aWdodDpib2xkIj5EYXRlOiA8L3NwYW4+TW9uZGF5LCBBcHJpbCAxMywgMjAxNSBhdCA0OjUwIFBN PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+JnF1b3Q7R2Vv cmdlLCBXZXMmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzp3ZXNsZXkuZ2VvcmdlQHR3Y2FibGUu Y29tIj53ZXNsZXkuZ2VvcmdlQHR3Y2FibGUuY29tPC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1h aWx0bzphbWFudGVAYXBwbGUuY29tIj5hbWFudGVAYXBwbGUuY29tPC9hPiZxdW90OyAmbHQ7PGEg aHJlZj0ibWFpbHRvOmFtYW50ZUBhcHBsZS5jb20iPmFtYW50ZUBhcHBsZS5jb208L2E+Jmd0Ozxi cj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5DYzogPC9zcGFuPiZxdW90O0pvaG4g Ry4gU2N1ZGRlciZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpnc0BqdW5pcGVyLm5ldCI+amdz QGp1bmlwZXIubmV0PC9hPiZndDssIElkciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlkckBpZXRmLm9y ZyI+aWRyQGlldGYub3JnPC9hPiZndDssIFN1c2FuIEhhcmVzICZsdDs8YSBocmVmPSJtYWlsdG86 c2hhcmVzQG5kemguY29tIj5zaGFyZXNAbmR6aC5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxl PSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+UmU6IDIgV2VlayBXRyBMQyBvbiBk cmFmdC1pZXRmLWlkci1hcy1taWdyYXRpb24gKDQvOSB0byA0LzIzLzIxMDUNCjxicj4NCjwvZGl2 Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFr LXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRl ci13aGl0ZS1zcGFjZTsiPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1m YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KPGJyPg0KPC9k aXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJy aSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQpJIGRvIGhhdmUgb25lIGl0ZW0gdGhh dCBJIHRoaW5rIG1heSBiZSBhYm92ZSDigJxtaW5vcuKAnTogd2hlbiB1c2luZyDigJxMb2NhbCBB U+KAnSwgd2hlbiBzaG91bGQgdGhlIEFTTiBiZSBwcmVwZW5kZWQ/ICZuYnNwO1doZW4gc2VuZGlu ZyBlQkdQLXJlY2VpdmVkIFVQREFURXMgdG8gaUJHUCBuZWlnaGJvcnMgKGFzIGl0IGlzIHNwZWNp ZmllZCBjdXJyZW50bHkpLCBPUiwgdGhlbiByZWNlaXZpbmcgdGhvc2UgZUJHUCBVUERBVEVzPyAm bmJzcDtJZiBpdCBpcyBub3QgZG9uZSB3aGVuDQogcmVjZWl2aW5nLCB0aGVuIHRoZSBBU19QQVRI IHdpbGwgYmUgaW5jb25zaXN0ZW50IGluIHRoZSBBUyAodGhlIGJvcmRlciByb3V0ZXIgd2lsbCBo YXZlIGEgc2hvcnRlciBBU19QQVRIKS4gJm5ic3A7SSB0aGluayB0aGlzIGNhbiBsZWFkIHRvIGlu Y29uc2lzdGVudCByb3V0ZSBzZWxlY3Rpb24gKGdpdmVuIHRoYXQgdGhlIGF0dHJpYnV0ZXMgYXJl IGluY29uc2lzdGVudCBpbnNpZGUgdGhlIEFTKSwgYnV0IHRoYXQgb2YgY291cnNlIG1heSBiZSBt aXRpZ2F0ZWQNCiBieSB0aGUgZmFjdCB0aGF0IHRoZSBhcHBsaWNhdGlvbiBvZiBMb2NhbCBBUyBt YXkgYmUgdG93YXJkcyBzdHViIG5ldHdvcmtzIGluIG1hbnkgKGJ1dCBub3QgYWxsKSBjYXNlcy4g Jm5ic3A7IEkgd291bGQgcmVhbGx5IGxpa2UgdG8gaGVhciBvdGhlcnPigJkgKGJleW9uZCB0aGUg YXV0aG9ycykgb3BpbmlvbnMuICZuYnNwO1tNeSBjb21tZW50cyAjMyBhbmQgIzcgaW4gdGhlIE1p bm9yIHNlY3Rpb24gYmVsb3cgYXJlIHJlbGF0ZWQgdG8gdGhpcy5dPC9kaXY+DQo8ZGl2IHN0eWxl PSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsg Zm9udC1zaXplOiAxNHB4OyI+DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+ DQo8ZGl2PldHXSBpbiB0aGUgYXBwcm9wcmlhdGUgcGxhY2VzIGluIHNlY3Rpb24gMy4xIGFuZCAz LjMsIEkgYWRkZWQgJnF1b3Q7aW5zdGFsbGluZyB0aGUgcm91dGUmcXVvdDsgdG8gY2xhcmlmeSB0 aGF0IHRoZSBiZWhhdmlvciB0aGF0IGl0IGlzIHByZXNjcmliZXMgYmVmb3JlIGl0IHNlbmRzIHVw ZGF0ZXMgaXMgYWxzbyBkb25lIGxvY2FsbHkuIEkgdGhpbmsgdGhpcyBpcyBwcm9iYWJseSB0aGUg YmVzdCBjb21wcm9taXNlIGJldHdlZW4gdGhlIHR3byBkaWZmZXJlbnQNCiBpbXBsZW1lbnRhdGlv bnMgdGhhdCB3ZSBjYW4gZ2l2ZSBzaG9ydCBvZiB3cml0aW5nIGEgbGVuZ3RoeSBkaXNjdXNzaW9u IGFsb25nIHRoZSBsaW5lcyBvZiBKZWZmJ3MgZW1haWwsIGluY2x1ZGluZyBkaXNjdXNzaW5nIHRo aXMgaW4gdGhlIGNvbnRleHQgb2Ygd2hlcmUgb25lIGRvZXMgbG9vcCBkZXRlY3Rpb24sIGFuZCB0 aGUgZmFjdCB0aGF0IGl0J3MgYSBTSE9VTEQgZ2l2ZXMgdXMgdGhlIHJpZ2h0IGFtb3VudCBvZiB3 aWdnbGUgcm9vbS4gTGV0DQogbWUga25vdyBpZiB5b3UgdGhpbmsgbW9yZSBjaGFuZ2VzIGFyZSBu ZWNlc3NhcnkuJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19T UkNfQk9EWV9TRUNUSU9OIj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdv cmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13 aGl0ZS1zcGFjZTsiPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1p bHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KPGJyPg0KPC9kaXY+ DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwg c2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQpNaW5vciBJc3N1ZXM6PC9kaXY+DQo8b2w+ DQo8bGkgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBz YW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDAs IDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4 OyI+My4xIHMvPC9zcGFuPjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+V2l0aGluIHRo ZSZuYnNwOzwvZm9udD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy aWY7Ij5Mb2MtUklCIG9uIElTUCBCIHByaW9yIHRvIHRoZSBtaWdyYXRpb24sIHRoZSBBU19QQVRI IHRvd2FyZA0KIGN1c3RvbWVyJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsiPkMgd291bGQgYXBwZWFyIGFzOiA2NDUxMC88L3NwYW4+V2l0 aGluIHRoZSBMb2MtUklCIG9uIElTUCBCIHByaW9yIHRvIHRoZSBtaWdyYXRpb24sIHRoZSBBU19Q QVRIIHRvd2FyZCBjdXN0b21lciBDIHdvdWxkIGFwcGVhciBhczogNjQ0OTY8L2xpPjwvb2w+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPg0KPGRpdj5XR10gJm5ic3A7U2hhbmUgYW5kIEkgYmVsaWV2 ZSB0aGF0IHRoZSBjdXJyZW50IHRleHQgaXMgY29ycmVjdC4gQ2FuIHlvdSBleHBsYWluIHdoeSB5 b3UgdGhpbmsgdGhpcyBuZWVkcyB0byBiZSBjaGFuZ2VkPzwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19T UkNfQk9EWV9TRUNUSU9OIj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdv cmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13 aGl0ZS1zcGFjZTsiPg0KPG9sPg0KPGxpPjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+ VGhlIHdvcmQg4oCcY2FwYWJpbGl0eeKAnSBpcyB1c2VkIGluIHNldmVyYWwgcGxhY2VzLiAmbmJz cDtXaGlsZSBpdCBpcyB1c2VkIGNvcnJlY3RseSAoZnJvbSBhIGxhbmd1YWdlIHBvaW50IG9mIHZp ZXcpLCBJIHRoaW5rIGl0IG1heSBjYXVzZSBjb25mdXNpb24gd2l0aCBhIEJHUCBDYXBhYmlsaXR5 IChmb3IgZXhhbXBsZTombmJzcDs8L2ZvbnQ+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlm Ij7igJx0aGUNCiAmcXVvdDtJbnRlcm5hbCBCR1AgQVMgTWlncmF0aW9uJnF1b3Q7ICZuYnNwO2Nh cGFiaWxpdHkgaXMgZW5hYmxlZCBvbiBhbGwgaUJHUCZuYnNwOzwvZm9udD48Zm9udCBmYWNlPSJD YWxpYnJpLHNhbnMtc2VyaWYiPnNlc3Npb25zIG9uIHRoYXQgZGV2aWNl4oCdKTwvZm9udD48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4uICZuYnNwO0kga25v dyB0aGF0IGluIHRoaXMgY2FzZSB0aGVyZSBpcyBubyBuZWdvdGlhdGlvbiBvZiBjYXBhYmlsaXRp ZXM7IGp1c3QNCiB0cnlpbmcgdG8gbWFrZSB0aGUgdGV4dCBjbGVhcmVyLjwvc3Bhbj48L2xpPjwv b2w+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPg0KPGRpdj5XR10geW91IGhhdmUgYSB2YWxpZCBw b2ludCwgYnV0IHdlIGFyZW4ndCBleGFjdGx5IHN1cmUgd2hhdCBhIGJldHRlciB3b3JkIHdvdWxk IGJlIOKAkyB0b29sPyBTd2l0Y2g/IEZlYXR1cmU/IE9wdGlvbj88L2Rpdj4NCjxkaXY+V2UgdGhv dWdodCBmZWF0dXJlIHNvdW5kZWQgdG9vIHZlbmRvci15LCBhbmQgb3B0aW9uIHdhcyBhbHJlYWR5 IHVzZWQgdG8gaWRlbnRpZnkgc3Vic2V0cyBvZiB0aGUgZmVhdHVyZXMgd2UncmUgc3RhbmRhcmRp emluZy4gRldJVywgNDI3MSB1c2VzIGNhcGFiaWxpdHkgaW4gYSBzaW1pbGFyIHdheSwgSS5lLiBj YXBpdGFsaXphdGlvbiBpcyBpbXBvcnRhbnQgdG8gZGlzYW1iaWd1YXRlIGJldHdlZW4gdGhlIHR3 by4gSSd2ZSBsZWZ0IGl0IGFzLWlzDQogZm9yIG5vdywgYmVjYXVzZSBJJ20gbm90IGNvbnZpbmNl ZCB0aGF0IGFueSBvZiB0aGUgYWx0ZXJuYXRpdmVzIEkndmUgc3VnZ2VzdGVkIGFjdHVhbGx5IHdv cmtzIHdlbGwgZW5vdWdoIHRvIGNoYW5nZSBpdCBnbG9iYWxseS4gJm5ic3A7PC9kaXY+DQo8c3Bh biBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVh ay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7Ij4NCjxvbD4NCjxsaSBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsg Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KNC4y ICZuYnNwOzwvbGk+PGxpPg0KPHVsPg0KPGxpPjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJp ZiI+SXQgbWF5IGJlIGNsZWFyZXIgaWYgaW5zdGVhZCBvZiAmcXVvdDtnbG9iYWxseSBjb25maWd1 cmVk4oCdIGFuZCAmcXVvdDtsb2NhbGx5IGNvbmZpZ3VyZWTigJ0sJm5ic3A74oCcTmV3X0FTTuKA nSBhbmQmbmJzcDvigJxPbGRfQVNO4oCdIChvciZuYnNwO3NvbWV0aGluZyB0byB0aGF0IGVmZmVj dCkgYXJlIHVzZWQuPC9mb250PjwvbGk+PC91bD4NCjwvbGk+PC9vbD4NCjwvZGl2Pg0KPC9zcGFu Pg0KPGRpdj5XR10gU2hhbmUgYW5kIEkgZGlzYWdyZWUuIFdlIHRoaW5rIHRoYXQgZ2xvYmFsIHZz IGxvY2FsIGlzIHVzZWZ1bCwgYmVjYXVzZSB0aGVyZSBpcyBhIG5vdGlvbiBvZiBhIGdsb2JhbCBC R1AgY29uZmlnIHRoYXQgYXBwbGllcyB0byBhbGwgbmVpZ2hib3JzIHZzIHRoaW5ncyB0aGF0IGFy ZSBuZWlnaGJvci1zcGVjaWZpYyBpLmUuIExvY2FsIHRvIGEgZ2l2ZW4gbmVpZ2hib3IuJm5ic3A7 PC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdiBzdHlsZT0id29y ZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGlu ZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7Ij4NCjxkaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQpOaXRzOjwvZGl2Pg0KPG9sPg0K PGxpIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQpJbnRybzombmJzcDsNCjx1bCBzdHlsZT0iY29s b3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQt c2l6ZTogMTRweDsiPg0KPGxpIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWls eTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQpUYWtlIHRoaXMgKCZx dW90O2FuZCBtYXkgYmUgdmVuZG9yLXNwZWNpZmljIGluIGV4YWN0IGltcGxlbWVudGF0aW9u4oCd KSBvdXQuPC9saT48bGk+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj5zLzwvZm9udD48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij5UaGVzZSBtZWNo YW5pc21zIGFyZSBsb2NhbCB0byBhIGdpdmVuIEJHUCBTcGVha2VyJm5ic3A7PC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPmFuZCBkbyBub3QgcmVx dWlyZSBuZWdvdGlhdGlvbiB3aXRoIG9yIGNvb3BlcmF0aW9uIG9mIEJHUCBuZWlnaGJvcnMuJm5i c3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsi PlRoZQ0KIGRlcGxveW1lbnQgb2YgdGhlc2UgbWVjaGFuaXNtcyBkbyBub3QgbmVlZCB0byBpbnRl cndvcmsgd2l0aCBvbmUmbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxp YnJpLCBzYW5zLXNlcmlmOyI+YW5vdGhlciB0byBhY2NvbXBsaXNoIHRoZSBkZXNpcmVkIHJlc3Vs dHMsIHNvIHNsaWdodCB2YXJpYXRpb25zJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPmJldHdlZW4gZXhpc3RpbmcNCiB2ZW5kb3IgaW1w bGVtZW50YXRpb25zIGV4aXN0LCBhbmQgd2lsbCBub3QmbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+bmVjZXNzYXJpbHkgYmUgaGFybW9u aXplZCBkdWUgdG8gdGhpcyBkb2N1bWVudC4gSG93ZXZlciwgaXQgaXMgbjwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij5lY2Vzc2FyeS4gLiAuLzwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij5UaGVz ZQ0KIG1lY2hhbmlzbXMgYXJlIGxvY2FsIHRvIGEgZ2l2ZW4gQkdQIFNwZWFrZXImbmJzcDs8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+YW5kIGRv IG5vdCByZXF1aXJlIG5lZ290aWF0aW9uIHdpdGggb3IgY29vcGVyYXRpb24gb2YgQkdQIG5laWdo Ym9ycy4gJm5ic3A7STwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7Ij50IGlzJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsiPm5lY2Vzc2FyeS4NCiAuIC48L3NwYW4+PC9saT48L3VsPg0KPC9s aT48L29sPg0KPC9kaXY+DQo8L3NwYW4+DQo8ZGl2PldHXSBJIHJlbW92ZWQgdGhlIHZlbmRvci1z cGVjaWZpYyBwYXJ0IGZyb20gdGhlIGFic3RyYWN0IGFuZCBpbnRybywgYnV0IEkgYmVsaWV2ZSB0 aGF0IHRoZSBvdGhlciBwYXJ0IHRoYXQgeW91IHN1Z2dlc3QgcmVtb3ZpbmcgaW4geW91ciBzZWNv bmQgYnVsbGV0IGFib3ZlIGlzIGltcG9ydGFudC4gV2UgY2FuJ3QgZm9yY2UgdmVuZG9ycyB0byBp bXBsZW1lbnQgZXhhY3RseSB3aGF0J3MgZG9jdW1lbnRlZCBoZXJlLCBlc3BlY2lhbGx5IHJldHJv YWN0aXZlbHksDQogc28gSSB0aGluayBpdCdzIHJlYXNvbmFibGUgdG8gYWNrbm93bGVkZ2UgdGhp cyBmYWN0LiZuYnNwOzwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxk aXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNl OyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyI+DQo8b2w+DQo8bGkgc3R5 bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyBmb250LXNpemU6IDE0cHg7Ij4NCjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+My4y IERlbGV0ZSB0aGUgc2Vjb25kIHBhcmFncmFwaCwgd2hpY2ggc3RhcnRzIHdpdGgmbmJzcDvigJxJ biBzb21lIGV4aXN0aW5nIGltcGxlbWVudGF0aW9uc+KAnS4gJm5ic3A7IFRoZW4gZm9yIHRoZSB0 aGlyZCBwYXJhZ3JhcGg6IHMvW1RoaXJkIHBhcmFncmFwaF0vPC9mb250PkEgdGVydGlhcnkgbWVj aGFuaXNtLCByZWZlcnJlZCB0byBhcyZuYnNwOzxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJp ZiI+JnF1b3Q7UmVwbGFjZSBPbGQNCiBBU+KAnSBpcyB1c2VkIHRvIHByZXZlbnQgcm91dGVycyZu YnNwOzwvZm9udD5mcm9tIGFwcGVuZGluZyB0aGUgZ2xvYmFsbHkgY29uZmlndXJlZCBBU04gaW4g b3V0Ym91bmQgQkdQIFVQREFURXMmbmJzcDs8Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYi PnRvd2FyZCBkaXJlY3RseSBhdHRhY2hlZCBlQkdQIG5laWdoYm9ycyB0aGF0IGFyZSB1c2luZyB0 aGUgJnF1b3Q7TG9jYWwgQVPigJ0mbmJzcDs8L2ZvbnQ+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5z LXNlcmlmIj5tZWNoYW5pc20uDQogJm5ic3A7SW5zdGVhZCwgb25seSB0aGUgQVNOIHNwZWNpZmll ZCB1c2luZyZuYnNwO+KAnExvY2FsIEFTJnF1b3Q7IHdpbGwgYmUmbmJzcDs8L2ZvbnQ+cHJlcGVu ZGVkIGluIHRoZSBvdXRib3VuZCBCR1AgVVBEQVRFIHRvd2FyZCB0aGUgY3VzdG9tZXIncyBuZXR3 b3JrLCZuYnNwO3Jlc3RvcmluZyB0aGUgQVNfUEFUSCBsZW5ndGggdG8gd2hhdCBpdCB3aGF0IHdh cyBiZWZvcmUgQVMgTWlncmF0aW9uJm5ic3A7b2NjdXJyZWQuPC9saT48L29sPg0KPC9kaXY+DQo8 L3NwYW4+DQo8ZGl2PldHXSB3ZSB0aGluayB0aGF0IHRoZSBzZWNvbmQgcGFyYWdyYXBoIGlzIGRv Y3VtZW50aW5nIGV4aXN0aW5nIHByYWN0aWNlL2ltcGxlbWVudGF0aW9ucyBkZXBsb3llZCBpbiB0 aGUgZmllbGQgZm9yIHRoZSBwdXJwb3NlIG9mIGNvbnRleHQgYW5kIGJhY2tncm91bmQgYW5kIHRo aW5rIGl0IHNob3VsZCByZW1haW4gaW4gcGxhY2UsIGFuZCB0aHVzIHRoZSBwcm9wb3NlZCBjaGFu Z2VzIHRvIHRoZSB0aGlyZCBwYXJhZ3JhcGggYXJlIGR1cGxpY2F0aXZlLiZuYnNwOzwvZGl2Pg0K PHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDog YnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6 IGFmdGVyLXdoaXRlLXNwYWNlOyI+DQo8b2w+DQo8bGkgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwg MCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4N Cjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+My4zICZxdW90OzwvZm9udD48Zm9udCBm YWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPldoZW4gdGhlICZxdW90O0xvY2FsIEFT4oCdJm5ic3A7 PC9mb250PmNhcGFiaWxpdHkgaXMgdXNlZCwgYSBsb2NhbCBBU04gd2lsbCBiZSBwcm92aWRlZCBp biB0aGUgY29uZmlndXJhdGlvbiZuYnNwOzxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+ dGhhdCBpcyBkaWZmZXJlbnQgZnJvbSB0aGUgZ2xvYmFsbHktY29uZmlndXJlZCBBU04gb2YNCiB0 aGUgQkdQIHJvdXRlci7igJ0gJm5ic3A7RG8geW91IHdhbnQgdG8gcHJvdmlkZSBzb21lIGd1aWRh bmNlIGhlcmU/ICZuYnNwO1NIT1VMRC9NVVNUIGl0IGJlIGRpZmZlcmVudD8gJm5ic3A7SSBndWVz cyB0aGVyZeKAmXMgbm8gcmVhbCBoYXJtIChmcm9tIHRoZSBwb2ludCBvZiB2aWV3IG9mIHRoZSZu YnNwO21lY2hhbmlzbXMgZGVmaW5lZCkgaWYgaXQgaXMgdGhlIHNhbWUuLiAmbmJzcDtbTGF0ZXIg aW4gdGhlIHBhcmFncmFwaCBpdCBzYXlzICZxdW90OzwvZm9udD5NVVNUIE5PVCB1c2UgdGhlIEFT TiZuYnNwO2NvbmZpZ3VyZWQNCiBnbG9iYWxseeKAnSwgc28mbmJzcDtJIGd1ZXNzIGl0IGlzIGlt cGxpY2l0IHRoYXQgaXQgaGFzIHRvIGJlIGRpZmZlcmVudCBvciBub3RoaW5nJm5ic3A7c2hvdWxk IGhhcHBlbi5dPC9saT48L29sPg0KPC9kaXY+DQo8L3NwYW4+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0i IiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7 IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IGZvbnQtc2l6ZTogMTRweDsg Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCjxkaXYgY2xhc3M9IiI+V0ddIEkn bSBub3QgaW5jbGluZWQgdG8gZXhwbGljaXRseSBkaXNhbGxvdyBpdCB1bmxlc3Mgc29tZW9uZSBj YW4gdGhpbmsgb2YgYSBmYWlsdXJlIGNhc2Ugd2UncmUgdHJ5aW5nIHRvIGF2b2lkLiBPbmUgd291 bGQgdGhpbmsgdGhhdCBtb3N0IGltcGxlbWVudGVycyB3b3VsZCBiZSBzbWFydCBlbm91Z2ggdG8g ZG8gdGhlIHJpZ2h0IHRoaW5nIGhlcmUsIGVzcGVjaWFsbHkgaW4gbGlnaHQgb2Ygb3VyIGd1aWRh bmNlIGluIGENCiBmZXcgc2VudGVuY2VzIGFib3V0IHdoYXQgdG8gZG8gaWYgeW91IHN1Y2Nlc3Nm dWxseSBlc3RhYmxpc2ggYSBCR1Agc2Vzc2lvbiB3aXRoIHRoZSBnbG9iYWwgQVNOJm5ic3A7PC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxk aXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNl OyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyI+DQo8b2w+DQo8bGkgc3R5 bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyBmb250LXNpemU6IDE0cHg7Ij4NCjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+My4z IHMvPC9mb250Pjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+dXNpbmcgdGhlIGxvY2Fs IEFTTiBjb25maWd1cmVkL3VzaW5nIHRoZSZuYnNwO+KAnExvY2FsIEFT4oCdPC9mb250PjwvbGk+ PC9vbD4NCjwvZGl2Pg0KPC9zcGFuPg0KPGRpdj5XR10gd2UgYXJlIG5vdCByZWZlcnJpbmcgdG8g dGhlIGNvbW1hbmQgJnF1b3Q7TG9jYWwgQVMmcXVvdDsgYnV0IHJhdGhlciB0aGUgYWN0dWFsIGF1 dG9ub21vdXMgc3lzdGVtIG51bWJlciBwcm92aWRlZCBhcyBhIHBhcmFtZXRlciBmb3IgdGhlIGxv Y2FsIChuZWlnaGJvci1zcGVjaWZpYykgY29uZmlnLCBzbyBJIHRoaW5rIHRoZSBvcmlnaW5hbCB0 ZXh0IGlzIG1vcmUgYWNjdXJhdGUuJm5ic3A7PC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZ X1NFQ1RJT04iPg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5i c3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7Ij4N CjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBz YW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0i Y29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZv bnQtc2l6ZTogMTRweDsiPg0KPGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvc3Bhbj48YnI+DQo8aHI+ DQo8Zm9udCBmYWNlPSJBcmlhbCIgY29sb3I9IkdyYXkiIHNpemU9IjEiPlRoaXMgRS1tYWlsIGFu ZCBhbnkgb2YgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIFRpbWUgV2FybmVyIENhYmxlIHBy b3ByaWV0YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBpcyBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWws IG9yIHN1YmplY3QgdG8gY29weXJpZ2h0IGJlbG9uZ2luZyB0byBUaW1lIFdhcm5lciBDYWJsZS4g VGhpcyBFLW1haWwgaXMgaW50ZW5kZWQgc29sZWx5DQogZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2 aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNoIGl0IGlzIGFkZHJlc3NlZC4gSWYgeW91IGFyZSBub3Qg dGhlIGludGVuZGVkIHJlY2lwaWVudCBvZiB0aGlzIEUtbWFpbCwgeW91IGFyZSBoZXJlYnkgbm90 aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBjb3B5aW5nLCBvciBh Y3Rpb24gdGFrZW4gaW4gcmVsYXRpb24gdG8gdGhlIGNvbnRlbnRzIG9mIGFuZCBhdHRhY2htZW50 cyB0bw0KIHRoaXMgRS1tYWlsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxh d2Z1bC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBFLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBu b3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRoZSBv cmlnaW5hbCBhbmQgYW55IGNvcHkgb2YgdGhpcyBFLW1haWwgYW5kIGFueSBwcmludG91dC48YnI+ DQo8L2ZvbnQ+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_D16534674EEFCwesleygeorgetwcablecom_-- From nobody Tue Apr 28 12:44:45 2015 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 678471A8711 for ; Tue, 28 Apr 2015 12:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YW8YMaB4ln5j for ; Tue, 28 Apr 2015 12:44:40 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0731.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:731]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C703C1A038F for ; Tue, 28 Apr 2015 12:44:39 -0700 (PDT) Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none; Received: from [172.29.35.73] (66.129.241.14) by DM2PR0501MB1104.namprd05.prod.outlook.com (25.160.245.140) with Microsoft SMTP Server (TLS) id 15.1.136.25; Tue, 28 Apr 2015 19:44:21 +0000 Message-ID: <553FE30E.4080902@juniper.net> Date: Tue, 28 Apr 2015 15:44:14 -0400 From: Eric C Rosen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Susan Hares , References: <015e01d07ba1$0042bff0$00c83fd0$@ndzh.com> In-Reply-To: <015e01d07ba1$0042bff0$00c83fd0$@ndzh.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.14] X-ClientProxiedBy: CO2PR06CA022.namprd06.prod.outlook.com (10.141.242.22) To DM2PR0501MB1104.namprd05.prod.outlook.com (25.160.245.140) X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0501MB1104; X-Microsoft-Antispam-PRVS: X-Forefront-Antispam-Report: BMV:1; SFV:NSPM; SFS:(10019020)(6049001)(6009001)(5423002)(77096005)(50986999)(65816999)(2950100001)(66066001)(59896002)(65806001)(87976001)(4001350100001)(54356999)(65956001)(230783001)(47776003)(50466002)(76176999)(92566002)(40100003)(77156002)(36756003)(46102003)(62966003)(86362001)(83506001)(64126003)(87266999)(122386002)(42186005)(5001770100001)(23746002)(33656002)(5890100001)(4001430100001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0501MB1104; H:[172.29.35.73]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010)(3002001); SRVR:DM2PR0501MB1104; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0501MB1104; X-Forefront-PRVS: 0560A2214D X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Apr 2015 19:44:21.0954 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0501MB1104 Archived-At: Subject: Re: [Idr] 2 week WG LC for draft-ietf-custom-decision (4/20 to 5/4/2015) 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, 28 Apr 2015 19:44:43 -0000 I think there are a few issues that should be addressed before publication of this draft is requested. 1. IANA Considerations and Extended Community Sub-Type Registries The document should be brought into conformance with RFC 7153 ("IANA Registries for BGP Extended Communities"). Specifically, I think section 3 should begin something like: "IANA has assigned the codepoint value 1 to 'Cost Community' in both the Transitive Opaque Extended Community Sub-Types registry and the Non-Transitive Opaque Extended Community Sub-Types registry." When a Cost Community is attached to a BGP Update, it is determined by provisioning whether the transitive or the non-transitve Cost Community is used. Then just go on to define the Value field. Similarly, the first paragraph of the IANA Considerations section should be: IANA has assigned the codepoint value 1 to 'Cost Community' in both the Transitive Opaque Extended Community Sub-Types registry and the Non-Transitive Opaque Extended Community Sub-Types registry." 2. Mandatory features? The draft doesn't say anything about which PoIs, if any, are mandatory to implement if Cost Community is supported. Is it the intention that none of the PoIs be mandatory? Whether a given PoI is mandatory or not, is it required that a given PoI not be used in a given AS unless all BGP speakers in that AS support it? If not, how is consistency of routing ensured? 3. Community-ID high order bit "The Community-ID sub-field contains an identifier to distinguish between multiple instances of the Cost Community. The high-order bit is reserved to indicate that the Cost Community MUST replace the path attribute specified by the Point of Insertion during the best path selection process." Before this paragraph, the draft talks about considering the Cost Community AFTER considering the attribute identified by the PoI. This paragraph suggests that if the high-order bit of the Community-ID is set, the Cost Community is considered INSTEAD of the attribute identified by the PoI. It might be better if the previous text in the draft talked about considering the Cost Community "after or instead of ..., depending on the setting of the high-order bit of the Community-ID." However, I don't understand what to do if you are comparing two routes, and for a given PoI and Community-ID, one of them has the high order bit set in the Community-ID and one does not. Similarly, if one route has a particular Community-ID for a given PoI, and another does not have that Community-ID for that PoI, how do we react to the setting of the high-order bit when we compare the two routes? 4. Questions about particular PoIs a. ABSOLUTE_VALUE. Is the intention here that ABSOLUTE_VALUE be used to assign the "degree of preference" (RFC4271 section 9.1.1) to a route, and that LOCAL_PREF, if present, be used as a tie-breaker when all the feasible routes have the same ABSOLUTE_VALUE? If so, it would be good to say that explicitly. Other text in the draft suggests that Cost Community is only used for "breaking a tie among generally equal paths", while text in RFC4271 suggests that LOCAL_PREF is used to assign degree of preference and not to break ties. Is there any signficance to the high-order bit of the Community-ID if the PoI is ABSOLUTE_VALUE? b. EXTERNAL_INTERNAL. I think this needs a better explanation of just when in the decision process it is considered. Does this refer to paragraph d of section 9.1.2.2 of RFC 4271? c. IGP_COST. It's not clear to me whether this PoI has any signficance when AIGP is used. d. AS_PATH. Presumably if the high-order bit of the Community-ID is set, the length of the AS_PATH is not used as a tie breaker, but the AS_PATH would still be used to prevent loops. If this interpretation is correct, that would be good to mention explicitly; othewise someone might assume that the AS_PATH is completely ignored in this case. e LOCAL_PREF. If a route has both a LOCAL_PREF and a Cost Community with the LOCAL_PREF PoI, and if the high-order bit of the Community-ID is set, then the LOCAL_PREF would be ignored. Is there a use case for this particular combination? 5. Security Considerations Considering the havoc that could be wreaked if a Cost Community gets improperly added or modified, through either error or malfeasance, it doesn't seem right to just say "no security considerations". 6. Terminological Consistency It's a bit of a chore to figure out the relationship between "metrics", "attributes", "points of insertion", and "communities". These terms do not appear to be used consistently through the document. Terms like "tie breaker" and "degree of preference" do not appear to be used the same way they are used in RFC 4271. Undefined terms like "generally equal paths" are used freely. I think interoperability will be facilitated by a greater degree of precision and consistency in the terminology. Additional comments interspersed in the text, look for lines beginning with "Eric>". Inter-Domain Routing A. Retana Internet-Draft Cisco Systems, Inc. Intended status: Standards Track R. White Expires: October 22, 2015 Ericsson April 20, 2015 BGP Custom Decision Process draft-ietf-idr-custom-decision-06 Abstract The BGP specification defines a Decision Process for installation of routes into the Loc-RIB. This process takes into account an extensive series of path attributes, which can be manipulated to indicate preference for specific paths. It is cumbersome (if at all possible) for the end user to define policies that will select, after partial comparison, a path based on subjective local (domain and/or node) criteria. Eric> I doubt that "subjective" is what is meant here; generally routing is based on objective criteria. The above also seems to suggest that the criteria can be specific to a particular node; that seems strange, given the need for consistent routing within a domain. This document defines a new Extended Community, called the Cost Community, which may be used in tie breaking during the best path selection process. The end result is a local custom decision process. 1. Introduction There are a number of metrics available within the BGP decision process [RFC4271] which can be used to determine the exit point for traffic, but there is no metric, or combination of metrics, which can be used to break a tie among generally equal paths. Eric> What is meant by "Generally equal paths"? Eric> RFC 4271 section 9.1.2.2 is called "Breaking Ties". Yet the above suggests that there is no way to break ties. o LOCAL_PREF: The LOCAL_PREF is an absolute tie breaker near the Eric> RFC 4271 talks about LOCAL_PREF to establish the degree of preference, not to break ties. In general, the terminology in this draft is not well-aligned with the terminology in section 9.1 of RFC 4271. beginning of the decision process. There is no way to configure the LOCAL_PREF such that the MED, IGP metric, and other metrics are considered before breaking a tie. Eric> I do not understand what this paragraph is trying to say. I thought the whole point of LOCAL_PREF was to establish a degree of preference that does not take these other factors into account. o MED: The MULTI_EXIT_DISC is an indicator of which local entrance point an AS would like a peering AS to use; MED isn't suitable to break the tie between two equal cost paths learned from two peer ASes. MED is also compared before the IGP metric; there is no way to set the MED so a path with a higher IGP metric is preferred over a path with a lower IGP metric. Eric> I don't follow this; if MED is compared before the IGP metric is considered, why can't it cause a route with lower IGP metric to be eliminated from consideration while a route with higher IGP metric continues to be considered? A route via a different peering AS will still be preferred if it has a lower IGP metric; is that what the above is trying to say? o IGP Metric: It is possible, using the IGP metric, to influence individual paths with otherwise equal cost metrics, but only by Eric> It is really not clear what is meant by "otherwise equal cost metrics". changing the next hop towards each path, and configuring the IGP costs of reaching each next hop. This method is cumbersome, and prone to confusion and error. The BGP specification defines a Decision Process for installation of routes into the Loc-RIB. This process takes into account an extensive series of path attributes, which can be manipulated to indicate preference for specific paths. It is cumbersome (if at all possible) for the end user to define policies that will select, after partial comparison, a path based on subjective local (domain and/or node) criteria. Eric> See comment above re "subjective criteria" and "node criteria". ... 3. The BGP Cost Community The BGP Cost Community is an Opaque Extended Community [RFC4360] defined as follows: Type Field: The value of the high-order octet of this Opaque Extended Community is 0x03 or 0x43. The value of the low-order octet of the extended type field for this community is 0x01. Eric> Above should be brought into alignment with RFC 7153, as suggested at the start of this message. Value Field: The Value field contains three distinct sub-fields, described below: +------------------------------+ | Point of Insertion (1 octet) | +------------------------------+ | Community-ID (1 octet) | +------------------------------+ | Cost (4 octets) | +------------------------------+ The Point of Insertion sub-field contains the value of the path attribute *after* which this community MUST be considered during the best path selection process. The BGP decision process includes some steps that do not correspond to any path attribute; the following values are defined: 128 ABSOLUTE_VALUE - Indicates that the Cost Community MUST be considered as the first step in determining the Degree of Preference of a path. 129 IGP_COST - Indicates that the Cost Community MUST be considered after the interior (IGP) distance to the next-hop has been compared. 130 EXTERNAL_INTERNAL - Indicates that the Cost Community MUST be considered after the paths advertised by BGP speakers in a neighboring autonomous system (if any) have been selected. 131 BGP_ID - Indicates that the Cost Community MUST be considered after the BGP Identifier (or ORIGINATOR_ID [RFC4456]) has been compared. The Community-ID sub-field contains an identifier to distinguish between multiple instances of the Cost Community. The high-order bit is reserved to indicate that the Cost Community MUST replace the path attribute specified by the Point of Insertion during the best path selection process. Eric> See above questions about the semantics of the Community-ID sub-field when the high-order bit does not have the same setting for all the communities at a given Point of Insertion. The Cost sub-field contains a value assigned by the network administrator and that is significant to the local autonomous system. The lower cost MUST be preferred. The default value is 0x7FFFFFFF (half the maximum value). Eric> Is this supposed to be a 32-bit unsigned integer? If so, that needs to be said. 4. Operation The network administrator may use the Cost Community to assign a value to a path originated or learned from a peer in any part of the local domain. The Point of Insertion MUST also be specified using the values defined in Appendix A. Eric> Please define "local domain". If a BGP speaker receives a path that contains the Cost Community, it SHOULD consider its value at the Point of Insertion specified, when calculating the best path [RFC4271]. If the Point of Insertion is not valid for the local best path selection implementation, then the Cost Community SHOULD be silently ignored. Paths that do not contain the Cost Community (for a valid, particular Point of Insertion) MUST be considered to have the default value. Eric> If a path has the cost community for a particular PoI, I think the intention is that it is considered to have the default value for all Community-IDs that do not appear in the list of communities for that PoI. This is never actually said anywhere. Multiple Cost Communities may indicate the same Point of Insertion. In this case, the Cost Community with the lowest Community-ID is considered first. In other words, all the Cost Communities for a specific Point of Insertion MUST be considered, starting with the one with the lowest Community-ID. If a range of routes is to be aggregated and the resultant aggregate path attributes do not carry the ATOMIC_AGGREGATE attribute, then the resulting aggregate SHOULD have an Extended Communities path attribute which contains the set union of all the Cost Communities from all of the aggregated routes. If multiple Cost Communities for the same Point of Insertion (and with the same Community-ID) exist, then only the ones with the highest Cost SHOULD be included. If the non-transitive version of a Cost Community is received across an Autonomous System boundary, then the receiver MUST strip it off the BGP update, and ignore it when running the selection process. 5. Deployment Considerations The mechanisms described in this document may be used to modify the BGP path selection process arbitrarily. It is important that a consistent path selection process be maintained across the local Autonomous System to avoid potential routing loops. In other words, if the Cost Community is used, all the nodes in the AS that may have to consider this new community at any Point of Insertion SHOULD be aware of the mechanisms described in this document. Eric> It's not clear what "SHOULD be aware of the mechanisms" means. Do all nodes in a "local domain" have to support the exact same set of PoIs? 6. Security Considerations This document introduces no new security concerns to BGP or other specifications referenced in this document. Eric> This doesn't seem true. 7. IANA Considerations IANA is asked to assign the type values indicated in Section 3 to the Cost Community in the BGP Opaque Extended Community registry [BGP_EXT]. Eric> Align with RFC 7311 as suggested above. Section 3 also defines a series of values to be used to indicate steps in the best path selection process that do not map directly to a path attribute. IANA is expected to maintain a registry for the Cost Community Point of Insertion values. Values 1 through 127 are to be assigned using the "Standards Action" policy or the Early Allocation process [RFC7120]. Values 128 through 191 are to be assigned using the "IETF Consensus" policy. Values 192 through 254 are to be assigned using the "First Come First Served" policy. Values 0 and 255 are reserved for future use and SHOULD NOT be used. Eric> This last sentence should probably just be "Values 0 and 255 are reserved." From nobody Tue Apr 28 14:49:52 2015 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 B251E1A89F5 for ; Tue, 28 Apr 2015 14:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5FSicaw6sk1 for ; Tue, 28 Apr 2015 14:49:47 -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 7386A1A8025 for ; Tue, 28 Apr 2015 14:49:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30333; q=dns/txt; s=iport; t=1430257787; x=1431467387; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=cd79w5bK53fTUYpuH/OlwX55UFnL7gnbcTA9uiWAkNE=; b=JVYORvl7xRLv2JfhNRF9bdvJ0Hf70hmU8oscV3lqp7sWbTaf6DNJx4cZ J/cH9u/L8Gf82q+e+g6B0JKN0hbYCM1IhS+H039J4bNk7Pcj6EhZ1q+Ul rNHLrCysnp5bHVJAa3HRNPY6rWYWXXvXv3ZMgzzPIcvGVkY4mzTo4Aw03 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BTBADm/z9V/5ldJa1SCoJFR4EvBccZCYdXAoE9OBQBAQEBAQEBgQqEIQEBBHkQAgEIOAcHMhQRAQEEAQ0FG4gQx2MBAQEBAQEBAQEBAQEBAQEBAQEBARiKNoEChCIGCwFRB4QtBYZHiHuCI4o/gSONH4Nag1AjgWUiHIFRb4ECBgMXIoEBAQEB X-IronPort-AV: E=Sophos;i="5.11,666,1422921600"; d="scan'208,217";a="145391596" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-5.cisco.com with ESMTP; 28 Apr 2015 21:49:46 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t3SLnk1D000702 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 Apr 2015 21:49:46 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.76]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Tue, 28 Apr 2015 16:49:46 -0500 From: "Alvaro Retana (aretana)" To: "George, Wes" , "amante@apple.com" Thread-Topic: 2 Week WG LC on draft-ietf-idr-as-migration (4/9 to 4/23/2105 Thread-Index: AdBzlDcUkdJmp22uTqShwxbVd0A/MgCn6C+AAvhvAQD//+ARgA== Date: Tue, 28 Apr 2015 21:49:45 +0000 Message-ID: References: <003f01d07394$9b5f1c00$d21d5400$@ndzh.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.15.7] Content-Type: multipart/alternative; boundary="_000_D1656C26AA776aretanaciscocom_" MIME-Version: 1.0 Archived-At: Cc: Susan Hares , idr wg Subject: Re: [Idr] 2 Week WG LC on draft-ietf-idr-as-migration (4/9 to 4/23/2105 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, 28 Apr 2015 21:49:50 -0000 --_000_D1656C26AA776aretanaciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On 4/28/15, 3:43 PM, "George, Wes" > wrote: Wes: Hi! . . . I do have one item that I think may be above =93minor=94: when using =93Loc= al AS=94, when should the ASN be prepended? When sending eBGP-received UPD= ATEs to iBGP neighbors (as it is specified currently), OR, then receiving t= hose eBGP UPDATEs? If it is not done when receiving, then the AS_PATH will= be inconsistent in the AS (the border router will have a shorter AS_PATH).= I think this can lead to inconsistent route selection (given that the att= ributes are inconsistent inside the AS), but that of course may be mitigate= d by the fact that the application of Local AS may be towards stub networks= in many (but not all) cases. I would really like to hear others=92 (beyo= nd the authors) opinions. [My comments #3 and #7 in the Minor section belo= w are related to this.] WG] in the appropriate places in section 3.1 and 3.3, I added "installing t= he route" to clarify that the behavior that it is prescribes before it send= s updates is also done locally. I think this is probably the best compromis= e between the two different implementations that we can give short of writi= ng a lengthy discussion along the lines of Jeff's email, including discussi= ng this in the context of where one does loop detection, and the fact that = it's a SHOULD gives us the right amount of wiggle room. Let me know if you = think more changes are necessary. Honestly, I don=92t like this solution. Your draft shouldn=92t cater to = a specific implementation, which is why it came back to the WG in the first= place. I would prefer to see a definite statement. If you don=92t want to exclude= one of the options then pick one (SHOULD =97 for the "right amount of wigg= le room") and then mention the other as an option (MAY). In the end the ef= fect is the same (no one is excluded), but the answer to =93When should I p= repend?=94 is clearer: do it when you SHOULD (but you MAY also do it at ot= her times). Regardless of which way you go, the text explaining =93No Prepend Inbound= =94 can be simplified (for example, in 3.3): s/MUST NOT append the "Local A= S" ASN value in the AS_PATH attribute when installing the route or advertis= ing that UPDATE to iBGP neighbors, but/MUST NOT append the "Local AS" ASN v= alue in the AS_PATH attribute, but Minor Issues: 1. 3.1 s/Within the Loc-RIB on ISP B prior to the migration, the AS_PATH= toward customer C would appear as: 64510/Within the Loc-RIB on ISP B prior= to the migration, the AS_PATH toward customer C would appear as: 64496 WG] Shane and I believe that the current text is correct. Can you explain = why you think this needs to be changed? Yes. Figure 1 looks like this: ------ ------ / ISP A \ / ISP B \ | AS 64500 | | AS 64510 | \ / \ / ------- ------- | | | | ------------ ------------- | Cust D | | Cust C | | AS 64499 | | AS 64496 | ------------ ------------- Figure 1: Before Migration So "the AS_PATH toward customer C=94 (which I interpret as the path to get = to C) should be simply 64496 (from B=92s point of view). Note that the rest of the sentence reads: "whereas the same RIB on ISP A' (= ISP B routers post-migration) would contain AS_PATH: 64510 64496.=94, which= corresponds to Figure 2: --------------- / \ | ISP A' | | AS 64500 | \ / --------------- / \ / \ | | ------------ ------------- | Cust D | | Cust C | | AS 64499 | | AS 64496 | ------------ ------------- Figure 2: After Migration Where 64510 is the Local AS. 1. The word =93capability=94 is used in several places. While it is use= d correctly (from a language point of view), I think it may cause confusion= with a BGP Capability (for example: =93the "Internal BGP AS Migration" ca= pability is enabled on all iBGP sessions on that device=94). I know that i= n this case there is no negotiation of capabilities; just trying to make th= e text clearer. WG] you have a valid point, but we aren't exactly sure what a better word w= ould be =96 tool? Switch? Feature? Option? We thought feature sounded too vendor-y, and option was already used to ide= ntify subsets of the features we're standardizing. FWIW, 4271 uses capabili= ty in a similar way, I.e. capitalization is important to disambiguate betwe= en the two. I've left it as-is for now, because I'm not convinced that any = of the alternatives I've suggested actually works well enough to change it = globally. Mechanism..? As I said before, just trying to make the text clearer. No one else menti= oned this item (that I know), so it may be clear to everyone else. 1. 4.2 2. * It may be clearer if instead of "globally configured=94 and "local= ly configured=94, =93New_ASN=94 and =93Old_ASN=94 (or something to that eff= ect) are used. WG] Shane and I disagree. We think that global vs local is useful, because = there is a notion of a global BGP config that applies to all neighbors vs t= hings that are neighbor-specific i.e. Local to a given neighbor. I see where you=92re coming from. It would be nice to clarify then what yo= u mean by global and local, maybe in the =93Documentation Note=94 section. Nits: 1. Intro: * Take this ("and may be vendor-specific in exact implementation=94)= out. * s/These mechanisms are local to a given BGP Speaker and do not req= uire negotiation with or cooperation of BGP neighbors. The deployment of th= ese mechanisms do not need to interwork with one another to accomplish the = desired results, so slight variations between existing vendor implementatio= ns exist, and will not necessarily be harmonized due to this document. Howe= ver, it is necessary. . ./These mechanisms are local to a given BGP Speaker= and do not require negotiation with or cooperation of BGP neighbors. It i= s necessary. . . WG] I removed the vendor-specific part from the abstract and intro, but I b= elieve that the other part that you suggest removing in your second bullet = above is important. We can't force vendors to implement exactly what's docu= mented here, especially retroactively, so I think it's reasonable to acknow= ledge this fact. We can=92t force vendors to implement anything exactly as documented, for a= ny case. But we don=92t call that out in all documents. It=92s nit.. I don=92t think that it=92s needed, but it=92s just a nit. 1. 3.2 Delete the second paragraph, which starts with =93In some existin= g implementations=94. Then for the third paragraph: s/[Third paragraph]/A= tertiary mechanism, referred to as "Replace Old AS=94 is used to prevent r= outers from appending the globally configured ASN in outbound BGP UPDATEs t= oward directly attached eBGP neighbors that are using the "Local AS=94 mech= anism. Instead, only the ASN specified using =93Local AS" will be prepende= d in the outbound BGP UPDATE toward the customer's network, restoring the A= S_PATH length to what it what was before AS Migration occurred. WG] we think that the second paragraph is documenting existing practice/imp= lementations deployed in the field for the purpose of context and backgroun= d and think it should remain in place, and thus the proposed changes to the= third paragraph are duplicative. The first paragraph says that ""Local AS" and "No Prepend Inbound", only mo= dify the AS_PATH Attribute received=85=94, which seems to me to be the same= thing as (in the second paragraph) ""Local AS" and "No Prepend Inbound=94 = does not concurrently modify the AS_PATH Attribute for BGP UPDATEs that are= transmitted=94. IOW, first you say that only received is modified, and th= en later say that outbound is not, which of course leads to the problem. To me the second paragraph was the repetitive one and the illustration of t= he problem would be enough without talking about existing implementations. Again, just a nit. Thanks! Alvaro. --_000_D1656C26AA776aretanaciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
On 4/28/15, 3:43 PM, "George, Wes" <wesley.george@twcable.com> wrote:

Wes:

Hi!

. . .
I do have one item that I think may be above =93minor=94: when using =93Loc= al AS=94, when should the ASN be prepended?  When sending eBGP-receive= d UPDATEs to iBGP neighbors (as it is specified currently), OR, then receiv= ing those eBGP UPDATEs?  If it is not done when receiving, then the AS_PATH will be inconsistent in the AS (the border rou= ter will have a shorter AS_PATH).  I think this can lead to inconsiste= nt route selection (given that the attributes are inconsistent inside the A= S), but that of course may be mitigated by the fact that the application of Local AS may be towards stub networks = in many (but not all) cases.   I would really like to hear others=92 (= beyond the authors) opinions.  [My comments #3 and #7 in the Minor sec= tion below are related to this.]
WG] in the appropriate places in section 3.1 and 3.3, I added "in= stalling the route" to clarify that the behavior that it is prescribes= before it sends updates is also done locally. I think this is probably the= best compromise between the two different implementations that we can give short of writing a lengthy discussion alo= ng the lines of Jeff's email, including discussing this in the context of w= here one does loop detection, and the fact that it's a SHOULD gives us the = right amount of wiggle room. Let me know if you think more changes are necessary. 

Honestly, I don=92t like this solution.    Your draft should= n=92t cater to a specific implementation, which is why it came back to the = WG in the first place.

I would p= refer to see a definite statement.  If you don=92t want to exclude one= of the options then pick one (SHOULD =97 for the "right amount of wig= gle room") and then mention the other as an option (MAY).  In the end the effect is the same (no one is excluded), but t= he answer to =93When should I prepend?=94 is clearer:  do it when you = SHOULD (but you MAY also do it at other times).

Reg= ardless of which way you go, the text explaining =93No Prepend Inbound=94 c= an be simplified (for example, in 3.3): s/MUST NOT append the "Local AS" ASN value in the AS_PATH attribute when installing the route or advertising that UPDATE to = iBGP neighbors, but/MU= ST NOT append the "Local AS" ASN value in the AS_PATH attribute, but




Minor Issues:
  1. 3.1 s/Within the = ;Loc-RIB on ISP B = prior to the migration, the AS_PATH toward customer C w= ould appear as: 64510/Within the Loc-RIB on ISP B prior to the migra= tion, the AS_PATH toward customer C would appear as: 64496
WG]  Shane and I believe that the current text is correct. Can yo= u explain why you think this needs to be changed?

Yes.  

Figure 1 looks like this:

         ------  = ;                ------
       / ISP  A \ &nb= sp;            / ISP  B \
      | AS 64500 |    = ;        | AS 64510 |
       \     &nb= sp;  /              \    =    /
        -------   &nb= sp;             -------
           | &nb= sp;                     |=
           | &nb= sp;                     |=
     ------------    =         -------------
     |  Cust D  | &nb= sp;           |  Cust C   |
     | AS 64499 |    =         | AS 64496  |
     ------------    =         -------------

            &nbs= p;           Figure 1: Before Migration

So "the AS_PATH toward customer C=94 (which I interpret as the pa= th to get to C) should be simply 64496 (from B=92s point of view).

Note that the rest of the sentence reads: "whereas the same RIB o= n ISP A' (ISP B routers post-migration) would contain AS_PATH: 64510 64496.= =94, which corresponds to Figure 2:

            &nbs= p;   ---------------
            &nbs= p; /                \
            &nbs= p;|     ISP A'       |
            &nbs= p;|     AS 64500     |
            &nbs= p; \                /
            &nbs= p;   ---------------
            &nbs= p;/                  \<= /div>
           / &nb= sp;                    \<= /font>
          |   &n= bsp;                     = |
     ------------    =         -------------
     |  Cust D  | &nb= sp;           |  Cust C   |
     | AS 64499 |    =         | AS 64496  |
     ------------    =         -------------

            &nbs= p;            Figure 2: After Migration

Where 64510 is the Local AS.



  1. The word =93capability=94 is used in = several places.  While it is used correctly (from a language point of = view), I think it may cause confusion with a BGP Capability (for example:&n= bsp;=93the "Internal BGP AS Migration"  capability is enabled on all i= BGP sessions on that device= =94).  I know= that in this case there is no negotiation of capabilities; just trying to make the text clearer.
WG] you have a valid point, but we aren't exactly sure what a better w= ord would be =96 tool? Switch? Feature? Option?
We thought feature sounded too vendor-y, and option was already used t= o identify subsets of the features we're standardizing. FWIW, 4271 uses cap= ability in a similar way, I.e. capitalization is important to disambiguate = between the two. I've left it as-is for now, because I'm not convinced that any of the alternatives I've sugge= sted actually works well enough to change it globally.  

Mechanism..?

As I said before, just trying to make the text clearer.   No one = else mentioned this item (that I know), so it may be clear to everyone else= .

  1. 4.2  
    • It may be clearer if instead of "= ;globally configured=94 and "locally configured=94, =93New_ASN=94= and =93Old_ASN=94 (or something to that effect) are used.=
WG] Shane and I disagree. We think that global vs local is useful, bec= ause there is a notion of a global BGP config that applies to all neighbors= vs things that are neighbor-specific i.e. Local to a given neighbor. =

I see where you=92re coming from.  It would be nice to clarify th= en what you mean by global and local, maybe in the =93Documentation Note=94= section.


Nits:
  1. Intro: 
    • Take this ("and may be vendor-specific in exact implementation=94) out= .
    • s/These mechanisms are local to a given BGP Speak= er and do not= require negotiation with or cooperation of BGP neighbors. The deployment of these mechanisms do not need to interwork with one another to accomplish = the desired results, so slight variations between existing vendor implementations exist, and will not necessarily be harmonized due to this docume= nt. However, it is nTh= ese mechanisms are local to a given BGP Speaker and do not require negotiation with or coop= eration of BGP neighbors.  It is necessary. . .
WG] I removed the vendor-specific part from the abstract and intro, bu= t I believe that the other part that you suggest removing in your second bu= llet above is important. We can't force vendors to implement exactly what's= documented here, especially retroactively, so I think it's reasonable to acknowledge this fact. 

We can=92t force vendors to implement anything exactly as documented, = for any case.  But we don=92t call that out in all documents.

It=92s nit..  I don=92t think that it=92s needed, but it=92s just= a nit.

  1. 3.2 Delete the second paragraph, which st= arts with =93In some existing implementations=94.   Then for the = third paragraph: s/[Third paragraph]/A tertiary mechanism, referred = to as "Replace Old AS=94 is used to prevent routers from appending the globally c= onfigured ASN in outbound BGP UPDATEs toward directly attached eBGP neighbors that are using the "Local AS= =94 mechanism.  Instead, only the ASN specified using =93Local AS" will be=  prepended in the outbound BGP UPDATE toward the customer's net= work, restoring the AS_PATH length to what it what was before AS Migra= tion occurred.
WG] we think that the second paragraph is documenting existing practic= e/implementations deployed in the field for the purpose of context and back= ground and think it should remain in place, and thus the proposed changes t= o the third paragraph are duplicative. 

The first paragraph says that ""Local AS" and "No = Prepend Inbound", only modify the AS_PATH Attribute received=85=94, wh= ich seems to me to be the same thing as (in the second paragraph) "&qu= ot;Local AS" and "No Prepend Inbound=94 does not concurrently mod= ify the AS_PATH Attribute for BGP UPDATEs that are transmitted=94.  IOW, firs= t you say that only received is modified, and then later say that outbound = is not, which of course leads to the problem.

To me the second paragraph was the repetitive one and the illustration= of the problem would be enough without talking about existing implementati= ons.

Again, just a nit.


Thanks!

Alvaro.
--_000_D1656C26AA776aretanaciscocom_-- From nobody Tue Apr 28 15:48:55 2015 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 8BF7D1A8968; Tue, 28 Apr 2015 15:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gx8xnP_FpyWv; Tue, 28 Apr 2015 15:48:52 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFE7D1A882B; Tue, 28 Apr 2015 15:48:51 -0700 (PDT) Received: from [192.168.178.25] (5356AD6E.cm-6-7c.dynamic.ziggo.nl [83.86.173.110]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id t3SMmX0t092774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Apr 2015 00:48:34 +0200 (CEST) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Iljitsch van Beijnum In-Reply-To: <986c7f50a5300c46ad05afb643be3a1d@mail.mandelberg.org> Date: Wed, 29 Apr 2015 00:48:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4C80F9CE-06F9-4FB7-852B-BF1B205738FC@muada.com> References: <4C184296-F426-40EF-9DB6-3AE87C42B516@tislabs.com> <91148102-DADB-42E8-96A0-E89120642894@tislabs.com> <986c7f50a5300c46ad05afb643be3a1d@mail.mandelberg.org> To: David Mandelberg X-Mailer: Apple Mail (2.2098) Archived-At: Cc: idr@ietf.org, sidr@ietf.org Subject: Re: [Idr] [sidr] Levels of BGPsec/RPKI validation, was: Re: wglc for draft-ietf-sidr-bgpsec-protocol-11 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, 28 Apr 2015 22:48:53 -0000 On 29 Apr 2015, at 0:21, David Mandelberg wrote: > Based on the two snippets above, I do think it's clear enough for = implementations to get it right. Yes, looks like it's indeed in there if you read closely. > However, you asked a good question that other people will probably ask = again. > Do you think it would be helpful to make this case more explicit = somewhere? I think making this more explicit in an update of RFC 6483 would be = helpful. But unless I missed something, the BGPsec drafts don't even talk about = the unknown state: "The validation procedure results in one of two states: 'Valid' and 'Not = Valid'." I don't see any reasonable deployment scenario with only valid and = invalid. I think this needs to be addressed in a BGPsec document.= From nobody Tue Apr 28 15:53:18 2015 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 1D9261A8949; Tue, 28 Apr 2015 15:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5vx8M6NTF75k; Tue, 28 Apr 2015 15:53:14 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F24931A8A48; Tue, 28 Apr 2015 15:53:13 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 4AAA128B0042; Tue, 28 Apr 2015 18:53:13 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 2D2011F8035; Tue, 28 Apr 2015 18:53:13 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_F81E6FD1-B1F5-4596-B2C5-00DF6E3AEACD"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Sandra Murphy In-Reply-To: Date: Tue, 28 Apr 2015 18:53:12 -0400 Message-Id: <30008066-54A7-4545-B947-947669B8EB3E@tislabs.com> References: <4C184296-F426-40EF-9DB6-3AE87C42B516@tislabs.com> <91148102-DADB-42E8-96A0-E89120642894@tislabs.com> To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.1510) Archived-At: Cc: "idr@ietf.org wg" , "sidr@ietf.org" , "ggm@apnic.net" Subject: Re: [Idr] [sidr] Levels of BGPsec/RPKI validation, was: Re: wglc for draft-ietf-sidr-bgpsec-protocol-11 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, 28 Apr 2015 22:53:16 -0000 --Apple-Mail=_F81E6FD1-B1F5-4596-B2C5-00DF6E3AEACD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 speaking as regular ol' member: On Apr 28, 2015, at 3:21 PM, Iljitsch van Beijnum = wrote: > On 28 Apr 2015, at 20:27, Roque Gagliano (rogaglia) = wrote: >=20 >> It is not an implementation choice, it is by design. If a signed = object does not validate (based on whatever reason not just expiration), = it is like if did not existed.=20 >=20 > No... >=20 > Suppose: >=20 > ROA: 193.0.0.0/21 up to /21 -> AS 3333 not valid after 20150430 >=20 > BGP table 29 april: >=20 > 193.0.0.0/21 3333 -> valid > 193.0.0.0/21 4444 -> invalid > 193.0.7.0/24 3333 -> invalid > 192.0.0.0/16 5555 -> unknown >=20 > But, two days later, after the ROA expires, do we have this: >=20 > 193.0.0.0/21 3333 -> unknown > 193.0.0.0/21 4444 -> unknown > 193.0.7.0/24 3333 -> unknown > 192.0.0.0/16 5555 -> unknown >=20 > or this: >=20 > 193.0.0.0/21 3333 -> invalid > 193.0.0.0/21 4444 -> invalid > 193.0.7.0/24 3333 -> invalid > 192.0.0.0/16 5555 -> unknown >=20 > ? >=20 > You seem to be saying the second, but that wouldn't work, as a simple = mistake would make AS 3333 unreachable. And since you need to connect to = the internet in order to get a new certificate/ROA so you can connect to = the internet=85 I think Roque was saying that the first outcome would be the case, not = the second: >> If a signed object does not validate (based on whatever reason not = just expiration), it is like if did not existed. If the ROA's EE certificate expires, then the ROA does not validate, it = is like if the ROA did not exist. Which makes the first outcome, not the second. I'm not sure where you see text that implies that the second outcome = would happen. We have left the idea of how fast expiration takes effect up to = implementation. If the implementation immediately trashes an expired EE = cert, then you lose the ROA, and the 3333 route would be "unknown". If = the implementation keeps the EE cert around (until next clock chime? = next sync interval? until it sees a reissue or a CRL?), then you keep = the ROA, and the 3333 route would be "valid". In neither case does the = 3333 route become "invalid". To get a result of "invalid" for 3333 for the /21 requires that you = found a ROA that authorizes some other AS for the /21 and no ROA that = authorizes 3333 for the /21. >=20 > The NANOG link I posted says it's the first case, which would be much = more workable in practice: in that case, if a certificate expires before = a new one is installed, you lose security but not connectivity.=20 Since that's what I think happens and what you think should happen, = we're good! >=20 > Note also that the approach suggested in RFC 6483 and Cisco and = Juniper documentation, where valid > unknown > invalid is not workable = because then can still have traffic flow towards more specific prefixes = even though they're invalid and have a very low local preference. The = nice thing about RPKI is that you can deploy it TODAY if you filter = invalids with the huge upside that you get rid of unauthorized more = specifics, incurring only the very small risk that someone creates ROAs = that conflict with their advertisements. Some people think depref-ing invalids is a safer alternative than = outright dropping them. There's evidence that people are creating ROAs = for their own announcement but forgetting the more specific prefixes = they've sub allocated to customers, where the customer are announcing = from their own AS but not doing ROAs. The ROA for the aggregate makes = the customer's announcement look invalid. Or maybe that's what you mean = by "get rid of unauthorized more specifics" and you think that's a good = outcome. > As we've successfully run BGP for 25 years without security, that's = bad, but preferable to being unreachable. I'm not sure you'd be unreachable. In this day and age, if there's an = aggregate prefix that includes yours, then you got your prefix from the = holder of the aggregate. And in (most?) cases, you have connectivity to = the holder of the aggregate. So you are reachable through them. (Since = IAmNotAnOperator (IANAO), any remark I make about operations should be = checked with someone who is.) Not reachable through your backup = provider, but that's maybe not so bad. =20 If you took their/your more specific prefix and walked and no longer = have connectivity thru the aggregate holder, well, =85 just deserts? = Speculation on my part. >=20 > But the real issue is that this isn't written down anywhere as far as = I can tell, so we're dependent on implementers all independently coming = up with the preferred way to handle this. That's never good business for = a standards organization. I don't agree that it is not written down anywhere. I think the = certificate checking and the BGP route checking are both clear in the = cases you lay out. --Sandy, speaking as regular ol' member --Apple-Mail=_F81E6FD1-B1F5-4596-B2C5-00DF6E3AEACD Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVQA9YAAoJEHplpQeet0IZfPkP/RZJkH3oE2uoSTxR8MDbKXQX XV88ZesDTCbXtElci6md9+nNQZsfvwgtAE4kb6F/b96xbqj4nTqWafRhb9KPIK+m foRO1zlJfxSP0CjaZwDl6/TDS3ush1ABOyNlwboJbPZjeCaKzYYbDloegOggB0ee H+ezvkMrrnwo7YwT6G0d0R80GMjAwo9UzKpcLedux1Z7RfnTrKX53G5PMwer4/kF eNKh6DEGwuBDoOJ+eyiYvNVp239vwNSQ2Xe5QP5EQlSfwGxTglqnuiFy6nMjq2Ua dFUcIZUTBUw9tjjrByFANtWIe7FNrsRFFteFbazcBqeab2c44b5KwZfiLNHDA7sr 4adpjJqQY9s4VSI1F1tKA3hemr5HvxSKC5MGQpJSF07MoBM1PU1LwH+i22ssxwlC xK+EvzKAxXyOJ74YggPaWNo3d8Q3uM8BAal4R6bY9Qtc3oBbXIWpwbOR9Yyhi4uI YhIygfKQ3cm2wIUu4bW+jMuyR+1cHyxjA5Gu9onyBhjjTy/hdqjN5a1OqLXaORHt tZHXJTMDYssqxtM1FEwBWN+3/wxL7wzXvPGZfibpsFLG7XrG3HkPr4s1cBGwy7W8 MyYdPOFGLTpfLjZmLwx1yIR9bMvYh/JLh0dIWdsdgGRMtTa2W5TzHjA3roEGluOF SWGIHBVmpr8qYMRDroe5 =+rEj -----END PGP SIGNATURE----- --Apple-Mail=_F81E6FD1-B1F5-4596-B2C5-00DF6E3AEACD-- From nobody Tue Apr 28 16:03:58 2015 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 B538B1A8AE6; Tue, 28 Apr 2015 16:03:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ef5sC-QHuBPo; Tue, 28 Apr 2015 16:03:54 -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 51E5B1A9030; Tue, 28 Apr 2015 16:03:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1153; q=dns/txt; s=iport; t=1430262234; x=1431471834; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=PZ0oduq9sF/ElHbNnBMn3RYqjBaEkqAb5RE4zGoglOQ=; b=mre+FT0J8sriD+gIUGpktWUZpSGVVsuwI1s9REufhxTSuJUtBd6GiQWm AXF647tavsNwqoFixxoUDETpa85YxbPwzz2YmgRW57AJdAfk9IuWLt1P2 hEwvtTXPKeg1LOdXxUhG6zodVhqBKE7dymkhh8cbmY0DjLVzvMzj0cpYH g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A6BQDNEEBV/4gNJK1cgwyBNMY3b4dXAoE9OhIBAQEBAQEBgQqEIQEBBHkQAgEGAg4tCzIlAgQBDYgwlXmxGAEBAQEBAQEBAQEBAQEBAQEBAQEBAReLOIUFB4QtAQSGR4seij+VbCNggQVTgTyBcQIeAgQcgQEBAQE X-IronPort-AV: E=Sophos;i="5.11,666,1422921600"; d="scan'208";a="145374057" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-3.cisco.com with ESMTP; 28 Apr 2015 23:03:53 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t3SN3rVg021821 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 Apr 2015 23:03:53 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.111]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Tue, 28 Apr 2015 18:03:53 -0500 From: "Roque Gagliano (rogaglia)" To: Sandra Murphy , Iljitsch van Beijnum Thread-Topic: [sidr] [Idr] Levels of BGPsec/RPKI validation, was: Re: wglc for draft-ietf-sidr-bgpsec-protocol-11 Thread-Index: AQHQggeYX77EfpWBnE20t13GxYDGaw== Date: Tue, 28 Apr 2015 23:03:52 +0000 Message-ID: References: <4C184296-F426-40EF-9DB6-3AE87C42B516@tislabs.com> <91148102-DADB-42E8-96A0-E89120642894@tislabs.com> <30008066-54A7-4545-B947-947669B8EB3E@tislabs.com> In-Reply-To: <30008066-54A7-4545-B947-947669B8EB3E@tislabs.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.5.141003 x-originating-ip: [10.61.85.4] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "idr@ietf.org wg" , "ggm@apnic.net" , "sidr@ietf.org" Subject: Re: [Idr] [sidr] Levels of BGPsec/RPKI validation, was: Re: wglc for draft-ietf-sidr-bgpsec-protocol-11 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, 28 Apr 2015 23:03:55 -0000 >I think Roque was saying that the first outcome would be the case, not >the second: You are correct and IMHO we do not need more documents. The normative text is in RFC 6482 section 4: ----------------------- 4. ROA Validation Before a relying party can use a ROA to validate a routing announcement, the relying party MUST first validate the ROA. To validate a ROA, the relying party MUST perform all the validation checks specified in [RFC6488] as well as the following additional ROA-specific validation step. o The IP address delegation extension [RFC3779] is present in the end-entity (EE) certificate (contained within the ROA), and each IP address prefix(es) in the ROA is contained within the set of IP addresses specified by the EE certificate's IP address delegation extension. =8B=8B=8B=8B=8B=8B=8B=8B=8B=8B=8B Informational text is in RFC6907, section 7.2: 7.2. ROA Expiry or Receipt of a CRL Revoking a ROA Particularly, section 7.2.5 to 7.2.8 covers different expiration circumstances. =8B=8B=8B=8B=8B=8B=8B=8B=8B=8B=8B Regards, Roque From nobody Tue Apr 28 20:07:22 2015 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 CF3591A8720; Tue, 28 Apr 2015 20:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wo3uCgWEa4pj; Tue, 28 Apr 2015 20:07:08 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 669C71A86F7; Tue, 28 Apr 2015 20:07:06 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1YnIL2-0006Qi-Fd; Wed, 29 Apr 2015 03:07:04 +0000 Date: Wed, 29 Apr 2015 12:07:02 +0900 Message-ID: From: Randy Bush To: Roque Gagliano In-Reply-To: References: <4C184296-F426-40EF-9DB6-3AE87C42B516@tislabs.com> <91148102-DADB-42E8-96A0-E89120642894@tislabs.com> <30008066-54A7-4545-B947-947669B8EB3E@tislabs.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: idr wg , sidr wg Subject: Re: [Idr] [sidr] Levels of BGPsec/RPKI validation, was: Re: wglc for draft-ietf-sidr-bgpsec-protocol-11 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, 29 Apr 2015 03:07:15 -0000 ca software should warn the user of upcoming expiration of certs, ee certs, roas, crls, drivers' licenses, ... but what is the user gonna do? they're gonna renew. so maybe renew automagically and tell the user? randy From nobody Tue Apr 28 21:58:17 2015 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 E8A291AC415 for ; Tue, 28 Apr 2015 21:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.801 X-Spam-Level: X-Spam-Status: No, score=-101.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] 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 LdoSGmxF-pYd for ; Tue, 28 Apr 2015 21:58:15 -0700 (PDT) Received: from ia-mailgw.apnic.net (ia-mailgw.apnic.net [IPv6:2001:dd8:a:851::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A09C1AC40B for ; Tue, 28 Apr 2015 21:58:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=c3po; h=received:received:content-type:mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer:return-path: x-originating-ip; bh=JgOOwQe+k5ce77NF9Ne6/zTL2HTqYmqzL4E9knEpjEY=; b=hPRaGbOzpwGUQBmpOy14/vCA/rEYJ5IUOLRq2dlOj43fXY4AbEr9WJrqojr6vrP8Eev+Nv09HlLIP O3zQU9ctQcu0JLJ2FwZuYYpdNcwf+ZJBY5BPaWUDrEymV0G4jxuv7IwMle0qtabDjpPo6mIgolR7Dy ed+k8iWzfcT9Frr0= Received: from NXMDA2.org.apnic.net (unknown [203.119.101.249]) by ia-mailgw.apnic.net (Halon Mail Gateway) with ESMTPS; Wed, 29 Apr 2015 14:58:10 +1000 (AEST) Received: from [192.168.1.47] (203.119.101.249) by NXMDA2.org.apnic.net (203.119.107.21) with Microsoft SMTP Server (TLS) id 14.1.218.12; Wed, 29 Apr 2015 14:59:27 +1000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Geoff Huston In-Reply-To: Date: Wed, 29 Apr 2015 06:57:57 +0200 Content-Transfer-Encoding: quoted-printable Message-ID: References: <4C184296-F426-40EF-9DB6-3AE87C42B516@tislabs.com> <91148102-DADB-42E8-96A0-E89120642894@tislabs.com> To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.2098) X-Originating-IP: [203.119.101.249] Archived-At: Cc: "idr@ietf.org wg" , sidr@ietf.org, George Michaelson Subject: Re: [Idr] Levels of BGPsec/RPKI validation, was: Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protocol-11 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, 29 Apr 2015 04:58:17 -0000 Hi Iljitsch, > But now what if a certificate expires? We know from the web that this = is extremely common. If an expired certificate means the prefixes = involved are marked invalid, this means that filtering invalids becomes = very problematic: not only will prefixes randomly drop off the net as = people forget to generate or install certificates or RPKI caches get = stale, but if things get really bad the resulting lack of connectivity = makes it impossible to correct the problem=E2=80=A6 >=20 > So what we need is for expired certificates to make the affected = prefixes revert to unknown rather than invalid. Turns out, that's what = happens today: >=20 > http://mailman.nanog.org/pipermail/nanog/2014-December/071907.html >=20 yup, becuase an expired certificate is not used for validation of ROAs, = so a route object that is only referred to by a ROA that cannot be = validated is =E2=80=9Cunknown=E2=80=9D in this taxonomy. It is not = =E2=80=9Cinvalid" by virtue of an expired certificate. > However, unless this is specified in one of the related documents = other than the three mentioned above, this seems to be an implementation = choice. to quote RFC6483:=20 "It is assumed here that a relying party (RP) has access to a local cache of the complete set of valid ROAs when performing validation of a route. (Valid ROAs are defined as ROAs that are determined to be syntactically correct and are signed using a signature that can be verified using the RPKI, as described in [RFC6482].) i.e. the route validation process that produces this set of valid, = invalid and unknown outcomes is based on the set of valid ROAs. ROAs = that cannot be validated (i.e. due to expired certificates and other = causes) are not considered in the route validation process described in = RFC6483. =20 >=20 > I think the above issue needs to be discussed in an update of RFC 6483 = or in one of the BGPsec documents. It=E2=80=99s not clear to me that any further text needs to be added to = RFC6483. The underlying process is one based on examination of the route = feed and comparing each received route object to a collection of = attestations and authorities that have been validated by the relying = party as trustable. >=20 > And there's probably a bit more to think about: wouldn't it make sense = to be able to filter on the signature algorithm at some point during the = transition from one algorithm to the next? Or to be able to filter on = "expired" explicitly? A binary valid/invalid isn't enough. = Valid/unknown/invalid is workable, but maybe four or five levels is even = better. >=20 > (And have a look at how this works in practice: = http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/command/irg-c= r-book/bgp-m1.html search for PEX.) >=20 regards, Geoff From nobody Wed Apr 29 08:04:36 2015 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 841021A8BC5 for ; Tue, 28 Apr 2015 15:21:16 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 h0YkBHIQ4ebo for ; Tue, 28 Apr 2015 15:21:14 -0700 (PDT) Received: from nm6-vm6.access.bullet.mail.bf1.yahoo.com (nm6-vm6.access.bullet.mail.bf1.yahoo.com [216.109.114.149]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A667C1A8BB2 for ; Tue, 28 Apr 2015 15:21:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1430259673; bh=6I/k2NQ/CL91na9BrT5QS8KXRA3swNO1TMtoeAfqKlI=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From:Subject; b=SMIiaquxFh6hPXtoJgnke+Hcsv09I3bTb0SaiCpM5RtERtycePzIYlDzvPjFWK692DpNxz87kQxzPGI7vBORtH1UcmQKK1nIIQq4tHGuuKjTcnnQm8nqbJxUOAeS9qXK2V2I4rWGoHkajCwrqI0eGoI8/YfYqkYGJw4Yc5sWo6uiIlXvsqPNitoRlyyfx+XKojXmK5ePXMwrrKaKQ6GESepHJIY+Orqhxa9CQ1AFn1Dmq5s3tGHtcUW+BNB8hjiSuyioMy9bRTJG/HraO4tgsbogsR4mfxc06ts+KGbs9HCQnu1zgtg3gDMZiZLuXJd9xuoGgqnVQ7UodaDppvxmhw== Received: from [66.196.81.156] by nm6.access.bullet.mail.bf1.yahoo.com with NNFMP; 28 Apr 2015 22:21:13 -0000 Received: from [98.138.104.99] by tm2.access.bullet.mail.bf1.yahoo.com with NNFMP; 28 Apr 2015 22:21:13 -0000 Received: from [127.0.0.1] by smtp119.sbc.mail.ne1.yahoo.com with NNFMP; 28 Apr 2015 22:21:13 -0000 X-Yahoo-Newman-Id: 682213.69154.bm@smtp119.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: DWQpn2UVM1lAL_QXtCqVK74Mwm5wL1HTJ9mQAxAFTEt1KTg hTvA_0y5zul1R0ukqK9FnryjFv4klzWST6O2j6hbF31v_wiL8iCDZNbAIj34 67tVo3QrUlD73pelxZMv935fkqlEiiPoeI7iHnWOZX3ljNo5INi__mvtYfVQ j65JzQkPQ9oaLboypRPaEaVfifImQ_jCZ9kNB64m1b9Hf3N0fq6MJhVJpmMa wqcYrMW0lZitA.buzFA76vLY4IPD7bDqNf6LkQc6KduthUtgu.GD5Wx.hLYM u_sxru7VbptDLmXqRh2DpxU6tN1cqxsz383c7lUQHIXfnvn2SjUdRKKtCixv zFuans2FBSWnv7Ou8AJRJCQ0QRWZrVSUSgG4UTs8uZJgRUOxUmN7r2OmiTZu ko8QAKc7CA3LtuKdrC2i8tTYMqiMEc2rCXiht3R6h819QSds.uDqzipdNBB6 MQwcMWYXrfekS6ClaAH_oPmA6oZZEboEThwzmPSn3JyP5CnCkNluogHJCnLN w6gbogsaogizEC.P09yIVoTKlRQ-- X-Yahoo-SMTP: 4kJJK.qswBDPuwyc5wW.BPAQqNXdy5j09UNyeAS0pyOQ708- Received: from secure.mandelberg.org (c-76-24-31-176.hsd1.ma.comcast.net [76.24.31.176]) by uriel.mandelberg.org (Postfix) with ESMTPSA id 4EEE81C6048; Tue, 28 Apr 2015 18:21:12 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 28 Apr 2015 18:21:12 -0400 From: David Mandelberg To: Iljitsch van Beijnum In-Reply-To: References: <4C184296-F426-40EF-9DB6-3AE87C42B516@tislabs.com> <91148102-DADB-42E8-96A0-E89120642894@tislabs.com> Message-ID: <986c7f50a5300c46ad05afb643be3a1d@mail.mandelberg.org> X-Sender: david@mandelberg.org User-Agent: Roundcube Webmail/0.7.2 Archived-At: X-Mailman-Approved-At: Wed, 29 Apr 2015 08:04:35 -0700 Cc: idr@ietf.org, sidr@ietf.org Subject: Re: [Idr] [sidr] Levels of BGPsec/RPKI validation, was: Re: wglc for draft-ietf-sidr-bgpsec-protocol-11 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, 28 Apr 2015 22:21:16 -0000 On 2015-04-28 15:21, Iljitsch van Beijnum wrote: > On 28 Apr 2015, at 20:27, Roque Gagliano (rogaglia) > wrote: > >> It is not an implementation choice, it is by design. If a signed >> object does not validate (based on whatever reason not just >> expiration), it is like if did not existed. > > No... > > Suppose: > > ROA: 193.0.0.0/21 up to /21 -> AS 3333 not valid after 20150430 In your example, is this the only ROA with a prefix that covers 193.0.0.0/21 or is covered by 193.0.0.0/21? Based on the states below, I'm assuming it is. Please correct me if I'm wrong. > BGP table 29 april: > > 193.0.0.0/21 3333 -> valid > 193.0.0.0/21 4444 -> invalid > 193.0.7.0/24 3333 -> invalid > 192.0.0.0/16 5555 -> unknown This part looks right to me. > But, two days later, after the ROA expires, do we have this: > > 193.0.0.0/21 3333 -> unknown > 193.0.0.0/21 4444 -> unknown > 193.0.7.0/24 3333 -> unknown > 192.0.0.0/16 5555 -> unknown > > or this: > > 193.0.0.0/21 3333 -> invalid > 193.0.0.0/21 4444 -> invalid > 193.0.7.0/24 3333 -> invalid > 192.0.0.0/16 5555 -> unknown > > ? [snip] > But the real issue is that this isn't written down anywhere as far as > I can tell, so we're dependent on implementers all independently > coming up with the preferred way to handle this. That's never good > business for a standards organization. It's the first one (all unknowns). I don't think this is written down explicitly, but if implementations follow RFC6483, I don't think there's any way they can get the second result. From RFC6483, Section 2: It is assumed here that a relying party (RP) has access to a local cache of the complete set of valid ROAs when performing validation of a route. (Valid ROAs are defined as ROAs that are determined to be syntactically correct and are signed using a signature that can be verified using the RPKI, as described in [RFC6482].) The RP needs to match a route to one or more valid candidate ROAs in order to determine a validation outcome, which, in turn, can be used to determine the appropriate local actions to perform on the route. This means that only valid (non-expired) ROAs are used for origin validation. Like Roque said, "if a signed object does not validate (based on whatever reason not just expiration), it is like if did not existed." Then, in the next paragraph: However, routes for address prefixes that are not fully described by any single ROA (i.e., those routes whose address prefixes may be an aggregate of address prefixes described in a valid ROA, or have address prefixes where there is no intersection with any valid ROA), and are not matched by any valid ROA and do not have an address prefix that is a more specific address prefix described in any valid ROA, cannot be reliably classified as "invalid" in a partial deployment scenario. Such routes have a validation outcome of "unknown". Since the {AS 3333, 193.0.0.0/21-21} ROA expired, there's no *valid* ROA that intersects any of {193.0.0.0/21, 193.0.0.0/21, 193.0.7.0/24, 192.0.0.0/16}. (See my assumption above about no other ROAs for these prefixes.) Since none of these four prefixes intersect any prefix in any valid ROA, all four routes you gave are unknown. Based on the two snippets above, I do think it's clear enough for implementations to get it right. However, you asked a good question that other people will probably ask again. Do you think it would be helpful to make this case more explicit somewhere? -- David Eric Mandelberg / dseomn http://david.mandelberg.org/ From nobody Wed Apr 29 08:09:00 2015 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 21A3F1A02F1 for ; Wed, 29 Apr 2015 08:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.474 X-Spam-Level: X-Spam-Status: No, score=-0.474 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 CK5GV00BEu8x for ; Wed, 29 Apr 2015 08:08:56 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 3407C1A023E for ; Wed, 29 Apr 2015 08:08:55 -0700 (PDT) X-SENDER-IP: 10.136.163.10 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.11,671,1422939600"; d="scan'208,217";a="860186301" Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 29 Apr 2015 10:52:43 -0400 Received: from PRVPEXVS10.corp.twcable.com ([10.136.163.41]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Wed, 29 Apr 2015 11:08:49 -0400 From: "George, Wes" To: "Alvaro Retana (aretana)" , "amante@apple.com" Date: Wed, 29 Apr 2015 11:08:50 -0400 Thread-Topic: 2 Week WG LC on draft-ietf-idr-as-migration (4/9 to 4/23/2105 Thread-Index: AdCCjmUnlx3oVUbzRuybAY4VSEozKg== Message-ID: References: <003f01d07394$9b5f1c00$d21d5400$@ndzh.com> 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.9.150325 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D16650174F160wesleygeorgetwcablecom_" MIME-Version: 1.0 Archived-At: Cc: idr wg Subject: Re: [Idr] 2 Week WG LC on draft-ietf-idr-as-migration (4/9 to 4/23/2105 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, 29 Apr 2015 15:08:59 -0000 --_000_D16650174F160wesleygeorgetwcablecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpGcm9tOiAiQWx2YXJvIFJldGFuYSAoYXJldGFuYSkiIDxhcmV0YW5hQGNpc2NvLmNvbTxtYWls dG86YXJldGFuYUBjaXNjby5jb20+Pg0KRGF0ZTogVHVlc2RheSwgQXByaWwgMjgsIDIwMTUgYXQg NTo0OSBQTQ0KDQpIb25lc3RseSwgSSBkb27igJl0IGxpa2UgdGhpcyBzb2x1dGlvbi4gICAgWW91 ciBkcmFmdCBzaG91bGRu4oCZdCBjYXRlciB0byBhIHNwZWNpZmljIGltcGxlbWVudGF0aW9uLCB3 aGljaCBpcyB3aHkgaXQgY2FtZSBiYWNrIHRvIHRoZSBXRyBpbiB0aGUgZmlyc3QgcGxhY2UuDQoN CldHXSBJIGRvbid0IHVuZGVyc3RhbmQgaG93IHRoYXQgY2F0ZXJzIHRvIGEgc3BlY2lmaWMgaW1w bGVtZW50YXRpb24sIGVzcGVjaWFsbHkgc2luY2Ugc2V2ZXJhbCBmb2xrcyBpbiB0aGUgV0cgc2Vl bSB0byBhZ3JlZSB0aGF0IHRoZSBiZXR0ZXIgc29sdXRpb24gaXMgdG8gYWRkIHRoZSBBUyBvbiBy ZWNlaXB0IHNvIHRoYXQgdGhlIHJvdXRlIGlzIGNvbnNpc3RlbnQgd2l0aGluIHRoZSBBUyBpbiBv cmRlciB0byBhdm9pZCBsb29wcy4NCg0KSSB3b3VsZCBwcmVmZXIgdG8gc2VlIGEgZGVmaW5pdGUg c3RhdGVtZW50LiAgSWYgeW91IGRvbuKAmXQgd2FudCB0byBleGNsdWRlIG9uZSBvZiB0aGUgb3B0 aW9ucyB0aGVuIHBpY2sgb25lIChTSE9VTEQg4oCUIGZvciB0aGUgInJpZ2h0IGFtb3VudCBvZiB3 aWdnbGUgcm9vbSIpIGFuZCB0aGVuIG1lbnRpb24gdGhlIG90aGVyIGFzIGFuIG9wdGlvbiAoTUFZ KS4gIEluIHRoZSBlbmQgdGhlIGVmZmVjdCBpcyB0aGUgc2FtZSAobm8gb25lIGlzIGV4Y2x1ZGVk KSwgYnV0IHRoZSBhbnN3ZXIgdG8g4oCcV2hlbiBzaG91bGQgSSBwcmVwZW5kP+KAnSBpcyBjbGVh cmVyOiAgZG8gaXQgd2hlbiB5b3UgU0hPVUxEIChidXQgeW91IE1BWSBhbHNvIGRvIGl0IGF0IG90 aGVyIHRpbWVzKS4NCg0KV0ddIFdlbGwsIEknbSB0cnlpbmcgdG8gYXZvaWQgZWl0aGVyIHJlLWhh c2hpbmcgdGhlIGFwcGFyZW50IGRpc2FncmVlbWVudCBiZXR3ZWVuIHRoZSB2ZW5kb3JzLCBoYXZp bmcgdG8gZGlzY3VzcyBkZWVwIGRldGFpbHMgYWJvdXQgbXVsdGlwbGUgdmVuZG9ycycgaW1wbGVt ZW50YXRpb24gY2hvaWNlcyB0byBleHBsYWluIHRoZSBzaG91bGQgdnMgbWF5IGFuZC9vciBiZWlu ZyByZXNwb25zaWJsZSBmb3IgZml4aW5nIGFuIGV4aXN0aW5nIGFtYmlndWl0eSBpbiB0aGUgQkdQ IHNwZWMsIGVzcGVjaWFsbHkgc2luY2UgYXQgbGVhc3Qgb25lIG9mIHRob3NlIHRoaW5ncyBpcywg YXMgeW91IHNhaWQsIHRoZSByZWFzb24gdGhhdCB0aGlzIGRyYWZ0IGNhbWUgYmFjayB0byB0aGUg V0cgaW4gdGhlIGZpcnN0IHBsYWNlLiBTaW5jZSBlbWFpbCBpcyBiYWQgYXQgY29udmV5aW5nIHRv bmUsIEkgc2hvdWxkIGJlIGNsZWFyIHRoYXQgd2hpbGUgSSBhbSBhIGJpdCBmcnVzdHJhdGVkLCBJ J20gbm90IHRyeWluZyB0byBiZSBjb21iYXRpdmUgaGVyZS4gSXQgYXBwZWFycyB0byBtZSB0aGF0 IHRoZXJlIGlzbid0IGEgc2luZ2xlIHJpZ2h0IGFuc3dlciB0byB0aGUgcXVlc3Rpb24geW91J3Jl IHBvc2luZywgc28gSSBkb24ndCByZWFsbHkga25vdyB3aGF0IHRoZSBkZWZpbml0ZSBzdGF0ZW1l bnQgc2hvdWxkIGJlLCB3aGljaCBpcyB3aHkgSSBkaWRuJ3QgbWFrZSBpdC4NCg0KVGhlIGNsb3Nl c3QgSSd2ZSBmb3VuZCBpcyB0aGUgbGFzdCBiaXQgb2YgSmVmZidzIEFwcmlsIDIxIGVtYWlsLCBi dXQgZXZlbiB0aGF0IGlzIG9ubHkgZGlzY3Vzc2luZyB0aGUgZ290Y2hhcywgbm90IG1ha2luZyBh IGRlZmluaXRlIHN0YXRlbWVudDoNCiJUaGUgaXNzdWUgaGFzIHRvIGRvIHdpdGggd2hlcmUgYW4g aW1wbGVtZW50YXRpb24gZG9lcyBpdHMgbG9vcCBkZXRlY3Rpb24uDQpTb21lIGltcGxlbWVudGF0 aW9ucyBkbyBsb29wIGRldGVjdGlvbiBhdCBldmVyeSBCR1Agc3BlYWtlci4gIFNvbWUgZG8gdGhl bQ0Kb25seSBhdCBhbiBlYmdwIGVkZ2UuICBTb21lIGJpYXMgdGhpcyBiZWhhdmlvciBiYXNlZCBv biBsb2NhbC1hcyBiZWluZw0KZW5hYmxlZCBvciBub3QuICBIb3cgeW91IGRvIHlvdXIgbG9vcCBk ZXRlY3Rpb24gYW5kIHdoZW4gaGVhdmlseSBiaWFzZXMgeW91cg0KY2hvaWNlIG9mIGltcGxlbWVu dGF0aW9uLiAgSW4gaW1wbGVtZW50YXRpb25zIHRoYXQgb25seSByZXF1aXJlcyBsb2NhbC1hcyBh dA0KeW91ciBlYmdwIGVkZ2VzIGJ1dCBkbyBsb29wIGRldGVjdGlvbiBhdCByb3V0ZSByZWZsZWN0 b3JzL2V4dGVybmFsIGNvbmZlZGVyYXRpb24NCnJvdXRlcnMsIGFkZGluZyB5b3VyIGxvY2FsLWFz IGFzIHBhcnQgb2YgaW1wb3J0IGlzIGEgcHJvYmxlbS4NCg0KU28sIGNvbnNpc3RlbmN5IGlzbid0 IG9ubHkgYSBiaWcgZGVhbCBhcyBwYXJ0IG9mIHdoZW4vd2hlcmUgeW91IGRvIHlvdXINCmxvY2Fs LWFzIHByZXBlbmQsIGl0J3MgYWxzbyBhIG1hdHRlciBvZiB3aGVyZSB5b3UgZG8gbG9vcCBkZXRl Y3Rpb24uICBJZg0KaW1wbGVtZW50YXRpb25zIGluIHRoZSBhYnNlbmNlIG9mIHNvbWUgIm91dHNp ZGUgdGhlIHNjb3BlIiBpbXBsZW1lbnRhdGlvbg0Kd2VyZSB0byBwZWRhbnRpY2FsbHkgaW1wbGVt ZW50IHRoZSBiYXNlIEJHUCBSRkMsIHRoZSBtaWdyYXRpb24gbWVjaGFuaXNtcw0Kd291bGQgYmUg YSBiaXQgYmlhc2VkIHRvIGEgZ2l2ZW4gc29sdXRpb24uIg0KDQpXb3VsZCBzb21ldGhpbmcgbGlr ZSB0aGlzIHRleHQgYmUgdGhlIHJpZ2h0IGxldmVsIG9mIGJhY2tncm91bmQgaW5mbyB0byBwcm92 aWRlIHVuYW1iaWd1b3VzIGJ1dCB1bmJpYXNlZCBndWlkYW5jZSB3aXRob3V0IHJlcXVpcmluZyBw YWdlcyBvZiBhZGRpdGlvbmFsIGRpc2N1c3Npb24/DQoNCg0KDQpSZWdhcmRsZXNzIG9mIHdoaWNo IHdheSB5b3UgZ28sIHRoZSB0ZXh0IGV4cGxhaW5pbmcg4oCcTm8gUHJlcGVuZCBJbmJvdW5k4oCd IGNhbiBiZSBzaW1wbGlmaWVkIChmb3IgZXhhbXBsZSwgaW4gMy4zKTogcy9NVVNUIE5PVCBhcHBl bmQgdGhlICJMb2NhbCBBUyIgQVNOIHZhbHVlIGluIHRoZSBBU19QQVRIIGF0dHJpYnV0ZSB3aGVu IGluc3RhbGxpbmcgdGhlIHJvdXRlIG9yIGFkdmVydGlzaW5nIHRoYXQgVVBEQVRFIHRvIGlCR1Ag bmVpZ2hib3JzLCBidXQvTVVTVCBOT1QgYXBwZW5kIHRoZSAiTG9jYWwgQVMiIEFTTiB2YWx1ZSBp biB0aGUgQVNfUEFUSCBhdHRyaWJ1dGUsIGJ1dA0KDQpXR10gT2ssIHRoYXQgc2VlbXMgdG8gYmUg YSBwb3RlbnRpYWxseSB1c2VmdWwgY2hhbmdlLiBEb2VzIGl0IGFkZHJlc3MgeW91ciBwcm9ibGVt IHRob3VnaD8gSSdtIGtpbmQgb2YgYXQgYSBsb3NzIG9uIGhvdyB0byBhZGRyZXNzIHRoaXMgYmV0 dGVyICh3aGljaCBpcyB3aHkgSSdtIGZydXN0cmF0ZWQsIG5vdCBiZWNhdXNlIEkgZG9uJ3QgYXBw cmVjaWF0ZSB0aGUgZmVlZGJhY2spLCBhbmQgY291bGQgdXNlIHNvbWUgZmVlZGJhY2sgZnJvbSBz b21lIG90aGVyIFdHIGZvbGsgb24gdGhlIG5ldyB0ZXh0IG9yIHdheXMgdG8gZml4IGl0IHdpdGhv dXQgZHJhbWF0aWNhbGx5IGV4cGFuZGluZyB0aGUgc2NvcGUgb2YgdGhlIGRpc2N1c3Npb24gaW4g dGhpcyBkb2N1bWVudC4NCg0K4oCmDQpTbyAidGhlIEFTX1BBVEggdG93YXJkIGN1c3RvbWVyIEPi gJ0gKHdoaWNoIEkgaW50ZXJwcmV0IGFzIHRoZSBwYXRoIHRvIGdldCB0byBDKSBzaG91bGQgYmUg c2ltcGx5IDY0NDk2IChmcm9tIELigJlzIHBvaW50IG9mIHZpZXcpLg0KDQpXR10gQWguIFRoYXQn cyB0aGUgaXNzdWUuIEl0J3Mgbm90IHRoZSBwYXRoIHRvIGdldCBUTyBDLiBJdCdzIHRoZSBwYXRo IEFOTk9VTkNFRCBieSBCIHRvd2FyZCBDLiBTaW5jZSBpdCdzIGxvb2tpbmcgbGlrZSB0aGVyZSdz IG9uZSBtb3JlIHJldmlzaW9uIGNvbWluZywgSSdsbCAgY2xhcmlmeSB0aGF0Lg0KDQoNCldHXSBJ IHJlbW92ZWQgdGhlIHZlbmRvci1zcGVjaWZpYyBwYXJ0IGZyb20gdGhlIGFic3RyYWN0IGFuZCBp bnRybywgYnV0IEkgYmVsaWV2ZSB0aGF0IHRoZSBvdGhlciBwYXJ0IHRoYXQgeW91IHN1Z2dlc3Qg cmVtb3ZpbmcgaW4geW91ciBzZWNvbmQgYnVsbGV0IGFib3ZlIGlzIGltcG9ydGFudC4gV2UgY2Fu J3QgZm9yY2UgdmVuZG9ycyB0byBpbXBsZW1lbnQgZXhhY3RseSB3aGF0J3MgZG9jdW1lbnRlZCBo ZXJlLCBlc3BlY2lhbGx5IHJldHJvYWN0aXZlbHksIHNvIEkgdGhpbmsgaXQncyByZWFzb25hYmxl IHRvIGFja25vd2xlZGdlIHRoaXMgZmFjdC4NCg0KV2UgY2Fu4oCZdCBmb3JjZSB2ZW5kb3JzIHRv IGltcGxlbWVudCBhbnl0aGluZyBleGFjdGx5IGFzIGRvY3VtZW50ZWQsIGZvciBhbnkgY2FzZS4g IEJ1dCB3ZSBkb27igJl0IGNhbGwgdGhhdCBvdXQgaW4gYWxsIGRvY3VtZW50cy4NCg0KV0ddIG5v LCBidXQgdHlwaWNhbGx5IHdlJ3JlIG5vdCByZXRyb2FjdGl2ZWx5IHN0YW5kYXJkaXppbmcgc29t ZXRoaW5nIHRoYXTigJlzIGFscmVhZHkgaW1wbGVtZW50ZWQsIHNvIGl0J3Mgbm90IG5lY2Vzc2Fy eSB0byBjYWxsIGl0IG91dCBpbiBhbGwgZG9jdW1lbnRzLg0KDQpUaGFua3MNCldlcw0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KVGhpcyBFLW1haWwgYW5kIGFueSBvZiBpdHMg YXR0YWNobWVudHMgbWF5IGNvbnRhaW4gVGltZSBXYXJuZXIgQ2FibGUgcHJvcHJpZXRhcnkgaW5m b3JtYXRpb24sIHdoaWNoIGlzIHByaXZpbGVnZWQsIGNvbmZpZGVudGlhbCwgb3Igc3ViamVjdCB0 byBjb3B5cmlnaHQgYmVsb25naW5nIHRvIFRpbWUgV2FybmVyIENhYmxlLiBUaGlzIEUtbWFpbCBp cyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5 IHRvIHdoaWNoIGl0IGlzIGFkZHJlc3NlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJl Y2lwaWVudCBvZiB0aGlzIEUtbWFpbCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkg ZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBjb3B5aW5nLCBvciBhY3Rpb24gdGFrZW4gaW4g cmVsYXRpb24gdG8gdGhlIGNvbnRlbnRzIG9mIGFuZCBhdHRhY2htZW50cyB0byB0aGlzIEUtbWFp bCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBoYXZl IHJlY2VpdmVkIHRoaXMgRS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIg aW1tZWRpYXRlbHkgYW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kIGFueSBj b3B5IG9mIHRoaXMgRS1tYWlsIGFuZCBhbnkgcHJpbnRvdXQuDQo= --_000_D16650174F160wesleygeorgetwcablecom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlf U0VDVElPTiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTFw dDsgdGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5v bmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElO Ry1MRUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQg c29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNw YW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj4mcXVvdDtBbHZhcm8gUmV0 YW5hIChhcmV0YW5hKSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFyZXRhbmFAY2lzY28uY29t Ij5hcmV0YW5hQGNpc2NvLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0 OmJvbGQiPkRhdGU6IDwvc3Bhbj5UdWVzZGF5LCBBcHJpbCAyOCwgMjAxNSBhdCA1OjQ5IFBNPGJy Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9IndvcmQtd3Jh cDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJl YWs6IGFmdGVyLXdoaXRlLXNwYWNlOyI+DQo8ZGl2PkhvbmVzdGx5LCBJIGRvbuKAmXQgbGlrZSB0 aGlzIHNvbHV0aW9uLiAmbmJzcDsgJm5ic3A7WW91ciBkcmFmdCBzaG91bGRu4oCZdCBjYXRlciB0 byBhIHNwZWNpZmljIGltcGxlbWVudGF0aW9uLCB3aGljaCBpcyB3aHkgaXQgY2FtZSBiYWNrIHRv IHRoZSBXRyBpbiB0aGUgZmlyc3QgcGxhY2UuPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9zcGFu Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+V0ddIEkgZG9uJ3QgdW5kZXJzdGFuZCBob3cgdGhh dCBjYXRlcnMgdG8gYSBzcGVjaWZpYyBpbXBsZW1lbnRhdGlvbiwgZXNwZWNpYWxseSBzaW5jZSBz ZXZlcmFsIGZvbGtzIGluIHRoZSBXRyBzZWVtIHRvIGFncmVlIHRoYXQgdGhlIGJldHRlciBzb2x1 dGlvbiBpcyB0byBhZGQgdGhlIEFTIG9uIHJlY2VpcHQgc28gdGhhdCB0aGUgcm91dGUgaXMgY29u c2lzdGVudCB3aXRoaW4gdGhlIEFTIGluIG9yZGVyIHRvIGF2b2lkIGxvb3BzLjwvZGl2Pg0KPHNw YW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTog MTRweDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij48YnI+DQo8L2Rpdj4NCjxk aXYgc3R5bGU9ImZvbnQtc2l6ZTogMTRweDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy aWY7Ij5JIHdvdWxkIHByZWZlciB0byBzZWUgYSBkZWZpbml0ZSBzdGF0ZW1lbnQuICZuYnNwO0lm IHlvdSBkb27igJl0IHdhbnQgdG8gZXhjbHVkZSBvbmUgb2YgdGhlIG9wdGlvbnMgdGhlbiBwaWNr IG9uZSAoU0hPVUxEIOKAlCBmb3IgdGhlICZxdW90O3JpZ2h0IGFtb3VudCBvZiB3aWdnbGUgcm9v bSZxdW90OykgYW5kIHRoZW4gbWVudGlvbiB0aGUgb3RoZXIgYXMgYW4gb3B0aW9uDQogKE1BWSku ICZuYnNwO0luIHRoZSBlbmQgdGhlIGVmZmVjdCBpcyB0aGUgc2FtZSAobm8gb25lIGlzIGV4Y2x1 ZGVkKSwgYnV0IHRoZSBhbnN3ZXIgdG8g4oCcV2hlbiBzaG91bGQgSSBwcmVwZW5kP+KAnSBpcyBj bGVhcmVyOiAmbmJzcDtkbyBpdCB3aGVuIHlvdSBTSE9VTEQgKGJ1dCB5b3UgTUFZIGFsc28gZG8g aXQgYXQgb3RoZXIgdGltZXMpLjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9zcGFu Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+V0ddIFdlbGwsIEknbSB0cnlpbmcgdG8gYXZvaWQg ZWl0aGVyIHJlLWhhc2hpbmcgdGhlIGFwcGFyZW50IGRpc2FncmVlbWVudCBiZXR3ZWVuIHRoZSB2 ZW5kb3JzLCBoYXZpbmcgdG8gZGlzY3VzcyBkZWVwIGRldGFpbHMgYWJvdXQgbXVsdGlwbGUgdmVu ZG9ycycgaW1wbGVtZW50YXRpb24gY2hvaWNlcyB0byBleHBsYWluIHRoZSBzaG91bGQgdnMgbWF5 IGFuZC9vciBiZWluZyByZXNwb25zaWJsZSBmb3IgZml4aW5nIGFuIGV4aXN0aW5nIGFtYmlndWl0 eQ0KIGluIHRoZSBCR1Agc3BlYywgZXNwZWNpYWxseSBzaW5jZSBhdCBsZWFzdCBvbmUgb2YgdGhv c2UgdGhpbmdzIGlzLCBhcyB5b3Ugc2FpZCwgdGhlIHJlYXNvbiB0aGF0IHRoaXMgZHJhZnQgY2Ft ZSBiYWNrIHRvIHRoZSBXRyBpbiB0aGUgZmlyc3QgcGxhY2UuIFNpbmNlIGVtYWlsIGlzIGJhZCBh dCBjb252ZXlpbmcgdG9uZSwgSSBzaG91bGQgYmUgY2xlYXIgdGhhdCB3aGlsZSBJIGFtIGEgYml0 IGZydXN0cmF0ZWQsIEknbSBub3QgdHJ5aW5nIHRvIGJlDQogY29tYmF0aXZlIGhlcmUuIEl0IGFw cGVhcnMgdG8gbWUgdGhhdCB0aGVyZSBpc24ndCBhIHNpbmdsZSByaWdodCBhbnN3ZXIgdG8gdGhl IHF1ZXN0aW9uIHlvdSdyZSBwb3NpbmcsIHNvIEkgZG9uJ3QgcmVhbGx5IGtub3cgd2hhdCB0aGUg ZGVmaW5pdGUgc3RhdGVtZW50IHNob3VsZCBiZSwgd2hpY2ggaXMgd2h5IEkgZGlkbid0IG1ha2Ug aXQuJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGUgY2xvc2VzdCBJJ3Zl IGZvdW5kIGlzIHRoZSBsYXN0IGJpdCBvZiBKZWZmJ3MgQXByaWwgMjEgZW1haWwsIGJ1dCBldmVu IHRoYXQgaXMgb25seSBkaXNjdXNzaW5nIHRoZSBnb3RjaGFzLCBub3QgbWFraW5nIGEgZGVmaW5p dGUgc3RhdGVtZW50OiZuYnNwOzwvZGl2Pg0KPGRpdj4mcXVvdDs8c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6IENvbnNvbGFzOyBmb250LXNpemU6IG1lZGl1bTsiPlRoZSBpc3N1ZSBoYXMgdG8gZG8g d2l0aCB3aGVyZSBhbiBpbXBsZW1lbnRhdGlvbiBkb2VzIGl0cyBsb29wIGRldGVjdGlvbi48L3Nw YW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ29uc29sYXM7IGZvbnQtc2l6ZTog bWVkaXVtOyI+U29tZSBpbXBsZW1lbnRhdGlvbnMgZG8gbG9vcCBkZXRlY3Rpb24gYXQgZXZlcnkg QkdQIHNwZWFrZXIuJm5ic3A7Jm5ic3A7U29tZSBkbyB0aGVtPC9kaXY+DQo8ZGl2IHN0eWxlPSJm b250LWZhbWlseTogQ29uc29sYXM7IGZvbnQtc2l6ZTogbWVkaXVtOyI+b25seSBhdCBhbiBlYmdw IGVkZ2UuJm5ic3A7Jm5ic3A7U29tZSBiaWFzIHRoaXMgYmVoYXZpb3IgYmFzZWQgb24gbG9jYWwt YXMgYmVpbmc8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDb25zb2xhczsgZm9udC1z aXplOiBtZWRpdW07Ij5lbmFibGVkIG9yIG5vdC4mbmJzcDsmbmJzcDtIb3cgeW91IGRvIHlvdXIg bG9vcCBkZXRlY3Rpb24gYW5kIHdoZW4gaGVhdmlseSBiaWFzZXMgeW91cjwvZGl2Pg0KPGRpdiBz dHlsZT0iZm9udC1mYW1pbHk6IENvbnNvbGFzOyBmb250LXNpemU6IG1lZGl1bTsiPmNob2ljZSBv ZiBpbXBsZW1lbnRhdGlvbi4mbmJzcDsmbmJzcDtJbiBpbXBsZW1lbnRhdGlvbnMgdGhhdCBvbmx5 IHJlcXVpcmVzIGxvY2FsLWFzIGF0PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ29u c29sYXM7IGZvbnQtc2l6ZTogbWVkaXVtOyI+eW91ciBlYmdwIGVkZ2VzIGJ1dCBkbyBsb29wIGRl dGVjdGlvbiBhdCByb3V0ZSByZWZsZWN0b3JzL2V4dGVybmFsIGNvbmZlZGVyYXRpb248L2Rpdj4N CjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDb25zb2xhczsgZm9udC1zaXplOiBtZWRpdW07Ij5y b3V0ZXJzLCBhZGRpbmcgeW91ciBsb2NhbC1hcyBhcyBwYXJ0IG9mIGltcG9ydCBpcyBhIHByb2Js ZW0uPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ29uc29sYXM7IGZvbnQtc2l6ZTog bWVkaXVtOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ29uc29sYXM7 IGZvbnQtc2l6ZTogbWVkaXVtOyI+U28sIGNvbnNpc3RlbmN5IGlzbid0IG9ubHkgYSBiaWcgZGVh bCBhcyBwYXJ0IG9mIHdoZW4vd2hlcmUgeW91IGRvIHlvdXI8L2Rpdj4NCjxkaXYgc3R5bGU9ImZv bnQtZmFtaWx5OiBDb25zb2xhczsgZm9udC1zaXplOiBtZWRpdW07Ij5sb2NhbC1hcyBwcmVwZW5k LCBpdCdzIGFsc28gYSBtYXR0ZXIgb2Ygd2hlcmUgeW91IGRvIGxvb3AgZGV0ZWN0aW9uLiZuYnNw OyZuYnNwO0lmPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ29uc29sYXM7IGZvbnQt c2l6ZTogbWVkaXVtOyI+aW1wbGVtZW50YXRpb25zIGluIHRoZSBhYnNlbmNlIG9mIHNvbWUgJnF1 b3Q7b3V0c2lkZSB0aGUgc2NvcGUmcXVvdDsgaW1wbGVtZW50YXRpb248L2Rpdj4NCjxkaXYgc3R5 bGU9ImZvbnQtZmFtaWx5OiBDb25zb2xhczsgZm9udC1zaXplOiBtZWRpdW07Ij53ZXJlIHRvIHBl ZGFudGljYWxseSBpbXBsZW1lbnQgdGhlIGJhc2UgQkdQIFJGQywgdGhlIG1pZ3JhdGlvbiBtZWNo YW5pc21zPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ29uc29sYXM7IGZvbnQtc2l6 ZTogbWVkaXVtOyI+d291bGQgYmUgYSBiaXQgYmlhc2VkIHRvIGEgZ2l2ZW4gc29sdXRpb24uJnF1 b3Q7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5Xb3VsZCBzb21ldGhpbmcgbGlrZSB0 aGlzIHRleHQgYmUgdGhlIHJpZ2h0IGxldmVsIG9mIGJhY2tncm91bmQgaW5mbyB0byBwcm92aWRl IHVuYW1iaWd1b3VzIGJ1dCB1bmJpYXNlZCBndWlkYW5jZSB3aXRob3V0IHJlcXVpcmluZyBwYWdl cyBvZiBhZGRpdGlvbmFsIGRpc2N1c3Npb24/Jm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9k ZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7Ij4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDE0cHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyI+PGJyPg0KPC9kaXY+DQo8ZGl2PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+UmVnYXJkbGVzcyBvZiB3aGljaCB3 YXkgeW91IGdvLCB0aGUgdGV4dCBleHBsYWluaW5nIOKAnE5vIFByZXBlbmQgSW5ib3VuZOKAnSBj YW4gYmUgc2ltcGxpZmllZCAoZm9yIGV4YW1wbGUsIGluIDMuMyk6IHMvPC9zcGFuPjxmb250IGZh Y2U9IkNhbGlicmksc2Fucy1zZXJpZiI+TVVTVCBOT1QgYXBwZW5kIHRoZSAmcXVvdDtMb2NhbCBB UyZxdW90OyBBU04NCiB2YWx1ZSBpbiB0aGUgQVNfUEFUSCBhdHRyaWJ1dGUmbmJzcDs8L2ZvbnQ+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+d2hlbiBpbnN0 YWxsaW5nIHRoZSByb3V0ZSBvciBhZHZlcnRpc2luZyB0aGF0IFVQREFURSB0byBpQkdQJm5ic3A7 PC9zcGFuPjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+bmVpZ2hib3JzLCBidXQvPC9m b250Pk1VU1QgTk9UIGFwcGVuZCB0aGUgJnF1b3Q7TG9jYWwgQVMmcXVvdDsgQVNOIHZhbHVlIGlu IHRoZQ0KIEFTX1BBVEggYXR0cmlidXRlLCBidXQ8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvc3Bhbj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PldHXSBPaywgdGhhdCBzZWVtcyB0 byBiZSBhIHBvdGVudGlhbGx5IHVzZWZ1bCBjaGFuZ2UuIERvZXMgaXQgYWRkcmVzcyB5b3VyIHBy b2JsZW0gdGhvdWdoPyBJJ20ga2luZCBvZiBhdCBhIGxvc3Mgb24gaG93IHRvIGFkZHJlc3MgdGhp cyBiZXR0ZXIgKHdoaWNoIGlzIHdoeSBJJ20gZnJ1c3RyYXRlZCwgbm90IGJlY2F1c2UgSSBkb24n dCBhcHByZWNpYXRlIHRoZSBmZWVkYmFjayksIGFuZCBjb3VsZCB1c2Ugc29tZSBmZWVkYmFjayBm cm9tDQogc29tZSBvdGhlciBXRyBmb2xrIG9uIHRoZSBuZXcgdGV4dCBvciB3YXlzIHRvIGZpeCBp dCB3aXRob3V0IGRyYW1hdGljYWxseSBleHBhbmRpbmcgdGhlIHNjb3BlIG9mIHRoZSBkaXNjdXNz aW9uIGluIHRoaXMgZG9jdW1lbnQuJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNw YW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJl YWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFm dGVyLXdoaXRlLXNwYWNlOyI+DQo8ZGl2PuKApjwvZGl2Pg0KPGRpdj5TbyAmcXVvdDt0aGUgQVNf UEFUSCB0b3dhcmQgY3VzdG9tZXIgQ+KAnSAod2hpY2ggSSBpbnRlcnByZXQgYXMgdGhlIHBhdGgg dG8gZ2V0IHRvIEMpIHNob3VsZCBiZSBzaW1wbHkgNjQ0OTYgKGZyb20gQuKAmXMgcG9pbnQgb2Yg dmlldykuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5XR10gQWguIFRoYXQncyB0aGUg aXNzdWUuIEl0J3Mgbm90IHRoZSBwYXRoIHRvIGdldCBUTyBDLiBJdCdzIHRoZSBwYXRoIEFOTk9V TkNFRCBieSBCIHRvd2FyZCBDLiBTaW5jZSBpdCdzIGxvb2tpbmcgbGlrZSB0aGVyZSdzIG9uZSBt b3JlIHJldmlzaW9uIGNvbWluZywgSSdsbCAmbmJzcDtjbGFyaWZ5IHRoYXQuJm5ic3A7PC9kaXY+ DQo8L2Rpdj4NCjwvc3Bhbj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19C T0RZX1NFQ1RJT04iPg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0 LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7 Ij4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiIgc3R5bGU9ImNvbG9yOiByZ2IoMCwg MCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7 Ij4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBz dHlsZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElORzowIDAgMCA1OyBNQVJH SU46MCAwIDAgNTsiPg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0 LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7 IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc2l6ZTogMTRweDsgZm9udC1mYW1pbHk6IENhbGli cmksIHNhbnMtc2VyaWY7Ij4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2 IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsg LXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiPg0KPGRpdj4NCjxkaXY+PGJy Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPg0KPGRpdj5XR10gSSByZW1vdmVkIHRo ZSB2ZW5kb3Itc3BlY2lmaWMgcGFydCBmcm9tIHRoZSBhYnN0cmFjdCBhbmQgaW50cm8sIGJ1dCBJ IGJlbGlldmUgdGhhdCB0aGUgb3RoZXIgcGFydCB0aGF0IHlvdSBzdWdnZXN0IHJlbW92aW5nIGlu IHlvdXIgc2Vjb25kIGJ1bGxldCBhYm92ZSBpcyBpbXBvcnRhbnQuIFdlIGNhbid0IGZvcmNlIHZl bmRvcnMgdG8gaW1wbGVtZW50IGV4YWN0bHkgd2hhdCdzIGRvY3VtZW50ZWQgaGVyZSwgZXNwZWNp YWxseSByZXRyb2FjdGl2ZWx5LA0KIHNvIEkgdGhpbmsgaXQncyByZWFzb25hYmxlIHRvIGFja25v d2xlZGdlIHRoaXMgZmFjdC4mbmJzcDs8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9z cGFuPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+V2UgY2Fu4oCZdCBmb3JjZSB2ZW5kb3JzIHRv IGltcGxlbWVudCBhbnl0aGluZyBleGFjdGx5IGFzIGRvY3VtZW50ZWQsIGZvciBhbnkgY2FzZS4g Jm5ic3A7QnV0IHdlIGRvbuKAmXQgY2FsbCB0aGF0IG91dCBpbiBhbGwgZG9jdW1lbnRzLjwvZGl2 Pg0KPC9kaXY+DQo8L3NwYW4+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNf Qk9EWV9TRUNUSU9OIj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtp dC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNl OyI+DQo8ZGl2PldHXSBubywgYnV0IHR5cGljYWxseSB3ZSdyZSBub3QgcmV0cm9hY3RpdmVseSBz dGFuZGFyZGl6aW5nIHNvbWV0aGluZyB0aGF04oCZcyBhbHJlYWR5IGltcGxlbWVudGVkLCBzbyBp dCdzIG5vdCBuZWNlc3NhcnkgdG8gY2FsbCBpdCBvdXQgaW4gYWxsIGRvY3VtZW50cy4mbmJzcDs8 L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhhbmtzPC9k aXY+DQo8ZGl2PldlcyZuYnNwOzwvZGl2Pg0KPGJyPg0KPGhyPg0KPGZvbnQgZmFjZT0iQXJpYWwi IGNvbG9yPSJHcmF5IiBzaXplPSIxIj5UaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0cyBhdHRhY2ht ZW50cyBtYXkgY29udGFpbiBUaW1lIFdhcm5lciBDYWJsZSBwcm9wcmlldGFyeSBpbmZvcm1hdGlv biwgd2hpY2ggaXMgcHJpdmlsZWdlZCwgY29uZmlkZW50aWFsLCBvciBzdWJqZWN0IHRvIGNvcHly aWdodCBiZWxvbmdpbmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1tYWlsIGlzIGludGVu ZGVkIHNvbGVseQ0KIGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3 aGljaCBpdCBpcyBhZGRyZXNzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGll bnQgb2YgdGhpcyBFLW1haWwsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc3Nl bWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgY29weWluZywgb3IgYWN0aW9uIHRha2VuIGluIHJlbGF0 aW9uIHRvIHRoZSBjb250ZW50cyBvZiBhbmQgYXR0YWNobWVudHMgdG8NCiB0aGlzIEUtbWFpbCBp cyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBoYXZlIHJl Y2VpdmVkIHRoaXMgRS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1t ZWRpYXRlbHkgYW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kIGFueSBjb3B5 IG9mIHRoaXMgRS1tYWlsIGFuZCBhbnkgcHJpbnRvdXQuPGJyPg0KPC9mb250Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_D16650174F160wesleygeorgetwcablecom_-- From nobody Wed Apr 29 09:59:10 2015 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 5CAD41A88A5 for ; Wed, 29 Apr 2015 09:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-yzRpny6CJf for ; Wed, 29 Apr 2015 09:59:07 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42E871ACCFE for ; Wed, 29 Apr 2015 09:59:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12334; q=dns/txt; s=iport; t=1430326747; x=1431536347; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=vFyI/QCRUcK+cYoiDqAHdEnZdrvtLGVLwyhw6w2Qx6E=; b=X02ZWNey0cio7N2775Rw7Fn+BoXYT5mYUbfIpoaDM79Upeg0fIQTYWZF wGDjdsBmsL1HCKf6l37K/ywQ96RMFX9kX45oSkPPLIUXH4mbN+G7GCr4S 5lrQGmtqhfoo36aX44SMTAXeK57Y9EVZrPryIePbELcUngeDEuz1qmpQH g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BYBQAwDUFV/5xdJa1cgkVHgS8FzVsCgUNMAQEBAQEBgQuEIQEBBHkQAgEIPwcyFBEBAQQBDQUbiBDHdwEBAQEBAQEBAQEBAQEBAQEBAQEBAReLOIQiEQFRB4QtBY9GgiSGToN6gSODSYlgg1yDUCOCBxyBUW+BCzmBAQEBAQ X-IronPort-AV: E=Sophos;i="5.11,671,1422921600"; d="scan'208,217";a="415779528" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP; 29 Apr 2015 16:59:05 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t3TGx4I4002615 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 Apr 2015 16:59:04 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.76]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Wed, 29 Apr 2015 11:59:04 -0500 From: "Alvaro Retana (aretana)" To: "George, Wes" , "amante@apple.com" Thread-Topic: 2 Week WG LC on draft-ietf-idr-as-migration (4/9 to 4/23/2105 Thread-Index: AdBzlDcUkdJmp22uTqShwxbVd0A/MgCn6C+AAvhvAQD//+ARgIABZWQA///buYA= Date: Wed, 29 Apr 2015 16:59:04 +0000 Message-ID: References: <003f01d07394$9b5f1c00$d21d5400$@ndzh.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.15.7] Content-Type: multipart/alternative; boundary="_000_D1667AA1AAA02aretanaciscocom_" MIME-Version: 1.0 Archived-At: Cc: idr wg Subject: Re: [Idr] 2 Week WG LC on draft-ietf-idr-as-migration (4/9 to 4/23/2105 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, 29 Apr 2015 16:59:09 -0000 --_000_D1667AA1AAA02aretanaciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On 4/29/15, 11:08 AM, "George, Wes" > wrote: Wes: Hi! Thanks for talking this out with me =97 I really appreciate the patience. = As you, I would also like to hear more from others; this is an important do= cument! . . . WG] . . . several folks in the WG seem to agree that the better solution is= to add the AS on receipt so that the route is consistent within the AS in = order to avoid loops. I would prefer to see a definite statement. If you don=92t want to exclude= one of the options then pick one (SHOULD =97 for the "right amount of wigg= le room") and then mention the other as an option (MAY). In the end the ef= fect is the same (no one is excluded), but the answer to =93When should I p= repend?=94 is clearer: do it when you SHOULD (but you MAY also do it at ot= her times). WG] Well, I'm trying to avoid either re-hashing the apparent disagreement b= etween the vendors, having to discuss deep details about multiple vendors' = implementation choices to explain the should vs may and/or being responsibl= e for fixing an existing ambiguity in the BGP spec, especially since at lea= st one of those things is, as you said, the reason that this draft came bac= k to the WG in the first place. Since email is bad at conveying tone, I sho= uld be clear that while I am a bit frustrated, I'm not trying to be combati= ve here. It appears to me that there isn't a single right answer to the que= stion you're posing, so I don't really know what the definite statement sho= uld be, which is why I didn't make it. The closest I've found is the last bit of Jeff's April 21 email, but even t= hat is only discussing the gotchas, not making a definite statement: "The issue has to do with where an implementation does its loop detection. Some implementations do loop detection at every BGP speaker. Some do them only at an ebgp edge. Some bias this behavior based on local-as being enabled or not. How you do your loop detection and when heavily biases you= r choice of implementation. In implementations that only requires local-as a= t your ebgp edges but do loop detection at route reflectors/external confeder= ation routers, adding your local-as as part of import is a problem. So, consistency isn't only a big deal as part of when/where you do your local-as prepend, it's also a matter of where you do loop detection. If implementations in the absence of some "outside the scope" implementation were to pedantically implement the base BGP RFC, the migration mechanisms would be a bit biased to a given solution." Would something like this text be the right level of background info to pro= vide unambiguous but unbiased guidance without requiring pages of additiona= l discussion? Ok..how about this: Internal: the router SHOULD append the configured "Local AS" ASN in the AS_PATH attribute either before installing the route or before advertising the UPDATE to an iBGP neighbor. Please see secti= on 3.3.1 for additional guidance. Then we would need to add a new 3.3.1 section with a short discussion of pr= os/cons related to the consistency and loop detection angles. If this works for you, then we can work on the text that goes there. [I ha= ven=92t looked at Jeff=92s text in detail yet.] Thanks! Alvaro. --_000_D1667AA1AAA02aretanaciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <85C860ADA03911498E1BE148039D296D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
On 4/29/15, 11:08 AM, "George, Wes" <wesley.george@twcable.com> wrote:

Wes:

Hi!

Thanks for talking this out with me =97 I really appreciate the patience. &= nbsp;As you, I would also like to hear more from others; this is an importa= nt document!

. . .
WG] . . . several folks in the WG seem to agree that the better soluti= on is to add the AS on receipt so that the route is consistent within the A= S in order to avoid loops.

I would p= refer to see a definite statement.  If you don=92t want to exclude one= of the options then pick one (SHOULD =97 for the "right amount of wig= gle room") and then mention the other as an option (MAY).  In the end the effect is the same (no one is excluded), but t= he answer to =93When should I prepend?=94 is clearer:  do it when you = SHOULD (but you MAY also do it at other times).

WG] Well, I'm trying to avoid either re-hashing the apparent disagreem= ent between the vendors, having to discuss deep details about multiple vend= ors' implementation choices to explain the should vs may and/or being respo= nsible for fixing an existing ambiguity in the BGP spec, especially since at least one of those things is, as you = said, the reason that this draft came back to the WG in the first place. Si= nce email is bad at conveying tone, I should be clear that while I am a bit= frustrated, I'm not trying to be combative here. It appears to me that there isn't a single right answer to= the question you're posing, so I don't really know what the definite state= ment should be, which is why I didn't make it. 

The closest I've found is the last bit of Jeff's April 21 email, but e= ven that is only discussing the gotchas, not making a definite statement:&n= bsp;
"The is= sue has to do with where an implementation does its loop detection.<= /div>
Some implementatio= ns do loop detection at every BGP speaker.  Some do them
only at an ebgp ed= ge.  Some bias this behavior based on local-as being
enabled or not.&nb= sp; How you do your loop detection and when heavily biases your
choice of implemen= tation.  In implementations that only requires local-as at
your ebgp edges bu= t do loop detection at route reflectors/external confederation
routers, adding yo= ur local-as as part of import is a problem.

So, consistency is= n't only a big deal as part of when/where you do your
local-as prepend, = it's also a matter of where you do loop detection.  If
implementations in= the absence of some "outside the scope" implementation
were to pedantical= ly implement the base BGP RFC, the migration mechanisms
would be a bit bia= sed to a given solution."

Would something like this text be the right level of background info t= o provide unambiguous but unbiased guidance without requiring pages of addi= tional discussion? 

Ok..how about this:   

       Internal: the router SHOULD append the configu= red "Local AS" ASN
       in the AS_PATH attribute either before install= ing the route or
       before advertising = the UPDATE to an iBGP neighbor.  Please see section 3.3.1
       for additional guid= ance.

Then we would need to add a new 3.3.1 section with a short discussion of pr= os/cons related to the consistency and loop detection angles.

If this works for you, then we can work on the text that goes there.  = [I haven=92t looked at Jeff=92s text in detail yet.]

Thanks!

Alvaro.
--_000_D1667AA1AAA02aretanaciscocom_-- From nobody Wed Apr 29 11:46:41 2015 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 D7BA91A8903; Wed, 29 Apr 2015 11:46:37 -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 6J3DbXKOMgJG; Wed, 29 Apr 2015 11:46:35 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0774.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:774]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B50C81A88BE; Wed, 29 Apr 2015 11:46:34 -0700 (PDT) Received: from CY1PR09MB0793.namprd09.prod.outlook.com (25.163.43.143) by CY1PR09MB0795.namprd09.prod.outlook.com (25.163.43.145) with Microsoft SMTP Server (TLS) id 15.1.148.16; Wed, 29 Apr 2015 18:46:18 +0000 Received: from CY1PR09MB0793.namprd09.prod.outlook.com ([25.163.43.143]) by CY1PR09MB0793.namprd09.prod.outlook.com ([25.163.43.143]) with mapi id 15.01.0148.008; Wed, 29 Apr 2015 18:46:18 +0000 From: "Sriram, Kotikalapudi" To: Iljitsch van Beijnum , David Mandelberg Thread-Topic: [sidr] [Idr] Levels of BGPsec/RPKI validation, was: Re: wglc for draft-ietf-sidr-bgpsec-protocol-11 Thread-Index: AQHQgeES7U91mgLFt0G5eeS9M69BR51izU6AgAAyNACAAAewgIABRAfg Date: Wed, 29 Apr 2015 18:46:18 +0000 Message-ID: References: <4C184296-F426-40EF-9DB6-3AE87C42B516@tislabs.com> <91148102-DADB-42E8-96A0-E89120642894@tislabs.com> <986c7f50a5300c46ad05afb643be3a1d@mail.mandelberg.org> <4C80F9CE-06F9-4FB7-852B-BF1B205738FC@muada.com> In-Reply-To: <4C80F9CE-06F9-4FB7-852B-BF1B205738FC@muada.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: muada.com; dkim=none (message not signed) header.d=none; x-originating-ip: [129.6.140.100] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0795; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:CY1PR09MB0795; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0795; x-forefront-prvs: 05610E64EE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(2656002)(99286002)(62966003)(86362001)(77156002)(230783001)(5001770100001)(54356999)(76576001)(93886004)(5001960100002)(76176999)(50986999)(46102003)(92566002)(33656002)(66066001)(2950100001)(2900100001)(102836002)(40100003)(106116001)(87936001)(5001920100001)(122556002)(74316001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0795; H:CY1PR09MB0793.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Apr 2015 18:46:18.1300 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0795 Archived-At: Cc: "idr@ietf.org" , "sidr@ietf.org" Subject: Re: [Idr] [sidr] Levels of BGPsec/RPKI validation, was: Re: wglc for draft-ietf-sidr-bgpsec-protocol-11 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, 29 Apr 2015 18:46:38 -0000 Hi Iljitsch, >But unless I missed something, the BGPsec drafts don't even talk about the= unknown state:=20 >"The validation procedure results in one of two states: 'Valid' and 'Not V= alid'." >I don't see any reasonable deployment scenario with only valid and invalid= . I think this needs to be addressed in a BGPsec document. The validation in the BGPsec draft is only about the AS path signatures in = signed updates. It is talking about the validity of the Secure_Path. =20 If all the signatures in a Signature_Block are valid, then the Signature_Bl= ock (and hence Secure_Path) is 'Valid'; Else, the Signature_Block is 'Not Valid'. If there are two Signature_Blocks (e.g. when two different algorithms are i= n use) in an update,=20 then at least one of them must be 'Valid' in order for the Secure_Path to b= e valid. Separately, prefix-origin validation has three possible outcomes as you hav= e observed already. That is the topic of RFC 6483 (Informational) and RFC 6811 (Standards Track= ). Sriram=20 From nobody Wed Apr 29 12:13:47 2015 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 F03201ACE45; Wed, 29 Apr 2015 12:13:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rae9V4LHveHa; Wed, 29 Apr 2015 12:13:44 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA0921ACE58; Wed, 29 Apr 2015 12:13:40 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1YnXQQ-0000jm-PN; Wed, 29 Apr 2015 19:13:39 +0000 Date: Thu, 30 Apr 2015 04:13:37 +0900 Message-ID: From: Randy Bush To: Kotikalapudi Sriram In-Reply-To: References: <4C184296-F426-40EF-9DB6-3AE87C42B516@tislabs.com> <91148102-DADB-42E8-96A0-E89120642894@tislabs.com> <986c7f50a5300c46ad05afb643be3a1d@mail.mandelberg.org> <4C80F9CE-06F9-4FB7-852B-BF1B205738FC@muada.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: idr wg list , sidr wg list Subject: Re: [Idr] [sidr] Levels of BGPsec/RPKI validation, was: Re: wglc for draft-ietf-sidr-bgpsec-protocol-11 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, 29 Apr 2015 19:13:45 -0000 this is deja vu all over again path validation has three possible results o a signed path validated o a signed path could not be validated o the path was unsigned randy From nobody Wed Apr 29 12:46:53 2015 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 8AFD01A00C8; Wed, 29 Apr 2015 12:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UNMJasPW9raP; Wed, 29 Apr 2015 12:46:49 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 89C5A1A0033; Wed, 29 Apr 2015 12:46:49 -0700 (PDT) Received: from [165.254.18.222] (unknown [165.254.18.222]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id E706A540633; Wed, 29 Apr 2015 15:46:47 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: text/plain; charset=us-ascii From: Jared Mauch In-Reply-To: Date: Wed, 29 Apr 2015 15:46:46 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C184296-F426-40EF-9DB6-3AE87C42B516@tislabs.com> <91148102-DADB-42E8-96A0-E89120642894@tislabs.com> <986c7f50a5300c46ad05afb643be3a1d@mail.mandelberg.org> <4C80F9CE-06F9-4FB7-852B-BF1B205738FC@muada.com> To: Randy Bush X-Mailer: Apple Mail (2.2098) Archived-At: Cc: idr wg list , Kotikalapudi Sriram , sidr wg list Subject: Re: [Idr] [sidr] Levels of BGPsec/RPKI validation, was: Re: wglc for draft-ietf-sidr-bgpsec-protocol-11 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, 29 Apr 2015 19:46:50 -0000 > On Apr 29, 2015, at 3:13 PM, Randy Bush wrote: >=20 > this is deja vu all over again >=20 > path validation has three possible results > o a signed path validated > o a signed path could not be validated > o the path was unsigned I will add one more thing, the path was was signed/validated when it was = checked. Some prefixes are stable for very long periods of time and = therefore the validation may not occur until after the expiration. I generally dislike systems that self-destruct. - Jared= From nobody Wed Apr 29 13:35:48 2015 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 7A9DB1A6F5D; Wed, 29 Apr 2015 13:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s222OUedZOkV; Wed, 29 Apr 2015 13:35:43 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CD5C1A6EF2; Wed, 29 Apr 2015 13:35:42 -0700 (PDT) Received: from global-hq.muada.nl (global-hq.muada.nl [IPv6:2001:470:1f15:8b5:995e:8e8e:2b66:a875] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id t3TKZQ7w011005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Apr 2015 22:35:27 +0200 (CEST) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Iljitsch van Beijnum In-Reply-To: Date: Wed, 29 Apr 2015 22:35:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C184296-F426-40EF-9DB6-3AE87C42B516@tislabs.com> <91148102-DADB-42E8-96A0-E89120642894@tislabs.com> <986c7f50a5300c46ad05afb643be3a1d@mail.mandelberg.org> <4C80F9CE-06F9-4FB7-852B-BF1B205738FC@muada.com> To: "Sriram, Kotikalapudi" X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "idr@ietf.org" , "sidr@ietf.org" , David Mandelberg Subject: Re: [Idr] [sidr] Levels of BGPsec/RPKI validation, was: Re: wglc for draft-ietf-sidr-bgpsec-protocol-11 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, 29 Apr 2015 20:35:46 -0000 On 29 Apr 2015, at 20:46, Sriram, Kotikalapudi = wrote: > The validation in the BGPsec draft is only about the AS path = signatures in signed updates. > It is talking about the validity of the Secure_Path. =20 > If all the signatures in a Signature_Block are valid, then the = Signature_Block (and hence Secure_Path) is 'Valid'; > Else, the Signature_Block is 'Not Valid'. So how does this work when a certificate expires without a new one in = place? Then the signature over a hop in the path and therefore the path and = therefore one or more prefixes are now "Not Valid". This presents us = with two choices: 1. we accept those prefixes in our forwarding tables 2. we don't accept those prefixes in our forwarding tables Obviously 1. can't be the answer, because then BGPsec is pretty much a = NOP. But 2. is not so great either, because now a mistake or delay in = generating and propagating certificates can cause unreachability. So what we need is a third option, that provides better security than 1. = and better reachability than 2. In other words, "couldn't validate because of certificate lifetime" and = "validation failed because of a bad signature or bad certificate chain" = are different enough that we need them to have different effects on the = forwarding tables.= From nobody Wed Apr 29 14:47:35 2015 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 212121A0141; Wed, 29 Apr 2015 14:47: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, 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 kc2WuXSX6kTP; Wed, 29 Apr 2015 14:47:31 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0751.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::751]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF5361A00E6; Wed, 29 Apr 2015 14:47:30 -0700 (PDT) Received: from CY1PR09MB0793.namprd09.prod.outlook.com (25.163.43.143) by CY1PR09MB0795.namprd09.prod.outlook.com (25.163.43.145) with Microsoft SMTP Server (TLS) id 15.1.148.16; Wed, 29 Apr 2015 21:47:08 +0000 Received: from CY1PR09MB0793.namprd09.prod.outlook.com ([25.163.43.143]) by CY1PR09MB0793.namprd09.prod.outlook.com ([25.163.43.143]) with mapi id 15.01.0148.008; Wed, 29 Apr 2015 21:47:09 +0000 From: "Sriram, Kotikalapudi" To: Iljitsch van Beijnum Thread-Topic: [sidr] [Idr] Levels of BGPsec/RPKI validation, was: Re: wglc for draft-ietf-sidr-bgpsec-protocol-11 Thread-Index: AQHQgeES7U91mgLFt0G5eeS9M69BR51izU6AgAAyNACAAAewgIABRAfggAApHYCAABDxMA== Date: Wed, 29 Apr 2015 21:47:08 +0000 Message-ID: References: <4C184296-F426-40EF-9DB6-3AE87C42B516@tislabs.com> <91148102-DADB-42E8-96A0-E89120642894@tislabs.com> <986c7f50a5300c46ad05afb643be3a1d@mail.mandelberg.org> <4C80F9CE-06F9-4FB7-852B-BF1B205738FC@muada.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: muada.com; dkim=none (message not signed) header.d=none; x-originating-ip: [129.6.140.100] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0795; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:CY1PR09MB0795; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0795; x-forefront-prvs: 05610E64EE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(19580395003)(2656002)(99286002)(62966003)(86362001)(230783001)(77156002)(54356999)(76176999)(76576001)(110136002)(93886004)(5001960100002)(46102003)(50986999)(92566002)(33656002)(66066001)(15975445007)(2950100001)(2900100001)(102836002)(106116001)(87936001)(40100003)(5001920100001)(122556002)(74316001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0795; H:CY1PR09MB0793.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Apr 2015 21:47:08.7400 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0795 Archived-At: Cc: "idr@ietf.org" , "sidr@ietf.org" , David Mandelberg Subject: Re: [Idr] [sidr] Levels of BGPsec/RPKI validation, was: Re: wglc for draft-ietf-sidr-bgpsec-protocol-11 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, 29 Apr 2015 21:47:33 -0000 >So what we need is a third option, that provides better security than 1. a= nd better reachability than 2. >In other words, "couldn't validate because of certificate lifetime"=20 >and "validation failed because of a bad signature or bad certificate chain= "=20 >are different enough that we need them to have different effects on the fo= rwarding tables. My thoughts on this: First: There should be operational BCP recommendation based on the principle of ma= ke-before-break ( in doc like https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-ops-05 ): 1. Certificate should be renewed and pre-published in advance of expiry of = the current certificate;=20 There should be overlapping validity period bridging the two (current and n= ew certs). (See https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-rollover-03 and https://www.ietf.org/proceedings/92/slides/slides-92-sidr-5.pdf )=20 2. The update for the prefix should be re-originated (by origin AS) or re-p= ropagated (by a transit AS). Basically, whoever got a new certificate should do this refresh within the = above overlap period.=20 The above two BCP steps, if followed, will help prevent "couldn't validate = because of certificate lifetime". Second: The operational BCP can also say: Allow a certain grace period before you act on the update that became 'Not = Valid' due to cert expiry. (Earlier Sandy also mentioned this.) =20 Your other scenario "validation failed because of a bad signature or bad ce= rtificate chain" is fine.=20 In this scenario, the update is labeled 'Not Valid' for good reason. Sriram =20 From nobody Wed Apr 29 15:24:58 2015 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 7392C1A885C; Wed, 29 Apr 2015 15:24:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jPaLQ_GIita8; Wed, 29 Apr 2015 15:24:55 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 735D51A8855; Wed, 29 Apr 2015 15:24:55 -0700 (PDT) Received: from global-hq.muada.nl (global-hq.muada.nl [IPv6:2001:470:1f15:8b5:995e:8e8e:2b66:a875] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id t3TMOdtq011768 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Apr 2015 00:24:40 +0200 (CEST) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Iljitsch van Beijnum In-Reply-To: Date: Thu, 30 Apr 2015 00:24:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C184296-F426-40EF-9DB6-3AE87C42B516@tislabs.com> <91148102-DADB-42E8-96A0-E89120642894@tislabs.com> <986c7f50a5300c46ad05afb643be3a1d@mail.mandelberg.org> <4C80F9CE-06F9-4FB7-852B-BF1B205738FC@muada.com> To: "Sriram, Kotikalapudi" X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "idr@ietf.org" , "sidr@ietf.org" , David Mandelberg Subject: Re: [Idr] [sidr] Levels of BGPsec/RPKI validation, was: Re: wglc for draft-ietf-sidr-bgpsec-protocol-11 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, 29 Apr 2015 22:24:57 -0000 On 29 Apr 2015, at 23:47, Sriram, Kotikalapudi = wrote: > The above two BCP steps, if followed, will help prevent "couldn't = validate because of certificate lifetime". Of course, most of the time this would happen correctly. People aren't = stupid. But experience with HTTPS has shown that expired certificates = can't be prevented 100%, and with routing the results are much more = severe than with the web, as the user can't decide to go ahead anyway. = The user wouldn't even know what happened. And fixing the problem may = not be possible because of the unreachability caused by the problem. > Second: > The operational BCP can also say: > Allow a certain grace period before you act on the update that became = 'Not Valid' due to cert expiry. > (Earlier Sandy also mentioned this.) =20 Ok. So what do you propose? That a path with signatures based on expired certificates remains = "valid" for some additional grace period? Then you simply postpone the = problem by that period. Or should operators have a way to differentiate between paths that are = actually invalid and paths that are merely affected by expired = certificates? In that case we are saying the same thing. It might even be useful to have valid / expired-but-otherwise-valid / = unknown / invalid rather than valid / unknown / invalid. Or maybe = valid-algo1 / valid-algo2 / expired-but-otherwise-valid / unknown / = invalid, so I can prefer paths protected with the strongest hashing = algorithm over paths protected with a weaker algorithm and those over = paths protected with expired certificates and those over paths not = protected by BGPsec. (IMO invalid paths should not be allowed at all.) Iljitsch= From nobody Wed Apr 29 16:18:48 2015 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 94AF81A8772; Wed, 29 Apr 2015 16:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HmZoQBCFZ4KG; Wed, 29 Apr 2015 16:18:45 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4C621A873C; Wed, 29 Apr 2015 16:18:44 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1YnbFY-0001PA-DO; Wed, 29 Apr 2015 23:18:40 +0000 Date: Thu, 30 Apr 2015 08:18:38 +0900 Message-ID: From: Randy Bush To: "Sriram, Kotikalapudi" In-Reply-To: References: <4C184296-F426-40EF-9DB6-3AE87C42B516@tislabs.com> <91148102-DADB-42E8-96A0-E89120642894@tislabs.com> <986c7f50a5300c46ad05afb643be3a1d@mail.mandelberg.org> <4C80F9CE-06F9-4FB7-852B-BF1B205738FC@muada.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: David Mandelberg , "idr@ietf.org" , "sidr@ietf.org" Subject: Re: [Idr] [sidr] Levels of BGPsec/RPKI validation, was: Re: wglc for draft-ietf-sidr-bgpsec-protocol-11 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, 29 Apr 2015 23:18:46 -0000 > First: > There should be operational BCP recommendation based on the principle of make-before-break > ( in doc like https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-ops-05 ): > 1. Certificate should be renewed and pre-published in advance of expiry of the current certificate; > There should be overlapping validity period bridging the two (current and new certs). > (See https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-rollover-03 and > https://www.ietf.org/proceedings/92/slides/slides-92-sidr-5.pdf ) > 2. The update for the prefix should be re-originated (by origin AS) or re-propagated (by a transit AS). > Basically, whoever got a new certificate should do this refresh within the above overlap period. > > The above two BCP steps, if followed, will help prevent "couldn't validate because of certificate lifetime". > > Second: > The operational BCP can also say: > Allow a certain grace period before you act on the update that became 'Not Valid' due to cert expiry. > (Earlier Sandy also mentioned this.) > > Your other scenario "validation failed because of a bad signature or bad certificate chain" is fine. > In this scenario, the update is labeled 'Not Valid' for good reason. From: Randy Bush Subject: Re: [sidr] [Idr] Levels of BGPsec/RPKI validation, was: Re: wglc for draft-ietf-sidr-bgpsec-protocol-11 To: Roque Gagliano Cc: idr wg , sidr wg Date: Wed, 29 Apr 2015 12:07:02 +0900 ca software should warn the user of upcoming expiration of certs, ee certs, roas, crls, drivers' licenses, ... but what is the user gonna do? they're gonna renew. so maybe renew automagically and tell the user? randy From nobody Thu Apr 30 07:17:41 2015 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 D43EF1ACD8B; Thu, 30 Apr 2015 02:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YIzt6cmYK2nw; Thu, 30 Apr 2015 02:43:05 -0700 (PDT) Received: from koko.ripe.net (koko.ripe.net [IPv6:2001:67c:2e8:11::c100:1348]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DC5A1A90B0; Thu, 30 Apr 2015 02:43:05 -0700 (PDT) Received: from titi.ripe.net ([193.0.23.11]) by koko.ripe.net with esmtps (UNKNOWN:AES256-GCM-SHA384:256) (Exim 4.72) (envelope-from ) id 1Ynkzm-0004Cb-4X; Thu, 30 Apr 2015 11:43:03 +0200 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:5009::151]) by titi.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Ynkzl-0005bH-Vp; Thu, 30 Apr 2015 11:43:02 +0200 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: text/plain; charset=us-ascii From: Tim Bruijnzeels In-Reply-To: Date: Thu, 30 Apr 2015 11:43:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8271CC14-248D-4F65-852E-6436E8DBC935@ripe.net> References: <4C184296-F426-40EF-9DB6-3AE87C42B516@tislabs.com> <91148102-DADB-42E8-96A0-E89120642894@tislabs.com> <986c7f50a5300c46ad05afb643be3a1d@mail.mandelberg.org> <4C80F9CE-06F9-4FB7-852B-BF1B205738FC@muada.com> To: Randy Bush X-Mailer: Apple Mail (2.2098) X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719a20cc706ea76f97e44c3a294f72fb301 Archived-At: X-Mailman-Approved-At: Thu, 30 Apr 2015 07:17:40 -0700 Cc: "sidr@ietf.org" , "idr@ietf.org" , "Sriram, Kotikalapudi" , David Mandelberg Subject: Re: [Idr] [sidr] Levels of BGPsec/RPKI validation, was: Re: wglc for draft-ietf-sidr-bgpsec-protocol-11 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, 30 Apr 2015 09:43:09 -0000 Hi, > On 30 Apr 2015, at 01:18, Randy Bush wrote: >=20 >> First: >> There should be operational BCP recommendation based on the principle = of make-before-break >> ( in doc like = https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-ops-05 ): >> 1. Certificate should be renewed and pre-published in advance of = expiry of the current certificate;=20 >> There should be overlapping validity period bridging the two (current = and new certs). >> (See https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-rollover-03 = and >> https://www.ietf.org/proceedings/92/slides/slides-92-sidr-5.pdf )=20 >> 2. The update for the prefix should be re-originated (by origin AS) = or re-propagated (by a transit AS). >> Basically, whoever got a new certificate should do this refresh = within the above overlap period.=20 >>=20 >> The above two BCP steps, if followed, will help prevent "couldn't = validate because of certificate lifetime". >>=20 >> Second: >> The operational BCP can also say: >> Allow a certain grace period before you act on the update that became = 'Not Valid' due to cert expiry. >> (Earlier Sandy also mentioned this.) =20 >>=20 >> Your other scenario "validation failed because of a bad signature or = bad certificate chain" is fine.=20 >> In this scenario, the update is labeled 'Not Valid' for good reason. >=20 >=20 > From: Randy Bush > Subject: Re: [sidr] [Idr] Levels of BGPsec/RPKI validation, was: Re: = wglc for draft-ietf-sidr-bgpsec-protocol-11 > To: Roque Gagliano > Cc: idr wg , sidr wg > Date: Wed, 29 Apr 2015 12:07:02 +0900 >=20 > ca software should warn the user of upcoming expiration of certs, ee > certs, roas, crls, drivers' licenses, ... >=20 > but what is the user gonna do? they're gonna renew. so maybe renew > automagically and tell the user? For the record in the RIPE NCC software we automagically re-issue CA = certificates to members 6 months before they expire (and log errors in = case of problems, so we have time to respond). Our system currently only = supports non-hosted setups where a member runs their own remote CA in = our pilot environment, but there too we pro-actively re-issue.. we don't = tell the CA because in the provisioning protocol model the child CA can = contact us, but we can't contact them. We do tell them about the new = certificate when the CA queries, as they do regularly. We believe that = this is safe to do. The new certificate is equivalent in every way to = the last requested and issued certificate except that the validity time = is longer, so we don't see any scenario where the child would not agree = to this - i.e. we can be pro-active. For hosted member CAs we also re-issue ROAs 6 months before the expire, = and we re-issue MFTs 16 hours before their 'next update time' and 6 days = and 16 hours before their EE certificate expiration. >=20 > randy >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Thu Apr 30 13:39:52 2015 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 CAD331A009B; Thu, 30 Apr 2015 13:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.11 X-Spam-Level: X-Spam-Status: No, score=-0.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_45=0.6, J_CHICKENPOX_47=0.6, J_CHICKENPOX_65=0.6, T_RP_MATCHES_RCVD=-0.01] 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 1xxJfrLaOFdE; Thu, 30 Apr 2015 13:39:49 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B46B1A0077; Thu, 30 Apr 2015 13:39:48 -0700 (PDT) Received: from [192.168.178.25] (5356AD6E.cm-6-7c.dynamic.ziggo.nl [83.86.173.110]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id t3UKdJCH026323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Apr 2015 22:39:19 +0200 (CEST) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Iljitsch van Beijnum In-Reply-To: Date: Thu, 30 Apr 2015 22:39:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3637DF28-CFC8-46FF-8929-DF88BB91D3AB@muada.com> References: <4C184296-F426-40EF-9DB6-3AE87C42B516@tislabs.com> <91148102-DADB-42E8-96A0-E89120642894@tislabs.com> To: Matthew Lepinski X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "idr@ietf.org wg" , "sidr@ietf.org" Subject: Re: [Idr] [sidr] Levels of BGPsec/RPKI validation, was: Re: wglc for draft-ietf-sidr-bgpsec-protocol-11 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, 30 Apr 2015 20:39:51 -0000 On 30 Apr 2015, at 19:48, Matthew Lepinski = wrote: > For path validation (as opposed to origin validation), the path = validation algorithm returns one of two states. That is, either an = update has a valid signed path or it doesn't. (We discussed previously = in SIDR whether there was a useful third case for path validation, and = the working group wasn't able to come up with one.) I think expired certificates qualifies. And a case can be made for = strong crypto algo vs weak crypto algo is a fourth one. > This means that there are six possible states that come from SIDR = validation (assuming you are using both origin validation and path = validation). That is, three possible origin validation states and two = possible path validation states yields six possible joint states. Actually nine, assuming < 100% BGPsec deployment: 1. BGPsec=3Dvalid, RPKI=3Dvalid 2. BGPsec=3Dvalid, RPKI=3Dunknown 3. BGPsec=3Dvalid, RPKI=3Dinvalid 4. no BGPsec, RPKI=3Dvalid 5. no BGPsec, RPKI=3Dunknown 6. no BGPsecd, RPKI=3Dinvalid 7. BGPsec=3Dnotvalid, RPKI=3Dvalid 8. BGPsec=3Dnotvalid, RPKI=3Dunknown 9. BGPsec=3Dnotvalid, RPKI=3Dinvalid Only with type 1 can we be sure that the prefix is advertised = legitimately. Type 5 indicates no BGPsec or RPKI deployment and may or may not be = legitimate. These should have a lower local_pref than type 1. Type 2 is = strange, but can probably be treated the same as type 5, or perhaps a = loc_pref higher than 5 but lower than 1. Types 3, 6 and 9 are bad news, as they may be unauthorized more = specifics, so it's important to filter these. Type 4 can happen because BGPsec hasn't been fully deployed yet = (remember that the whole path must support it while RPKI can be deployed = by just the "end" AS) but once that's no longer common it will be the = attack vector of choice because it's easy to fake the origin AS if = there's no BGPsec, so at some point, these need to be filtered, too. That leaves 7 and 8, which SHOULD be filtered if they're legitimate = BGPsec validation failures and not incidental mistakes such as expired = certificates. > it is perfectly fine for different operators to handle such cases = differently.) Famous last words. Obviously we don't want to be overly prescriptive, = but I don't think there's as much room for creativity as you suggest. > However, personally, for path validation, I would not recommend = throwing out all route advertisements where path validation returns = invalid. That is, if the only route you know of to get to a particular = block of address space has a signature that doesn't valid (or lack = signatures because someone in the middle doesn't have BGPsec turned on), = I think it is probably a good idea to use that route despite the lack of = valid signature chain. Actually I don't think that case can happen. Consider the following = path: 6 5 4 3 2 1 If AS 4 doesn't support BGPsec but the others do, then AS 3 will convert = the BGPsec_Path to an AS_PATH, removing all the signatures. ASes 5 and 6 = are not in the position to repair this, so as far as they're concerned, = the path is completely unprotected. However, what you say here is problematic: > That is, if the only route you know of to get to a particular block of = address space has a signature that doesn't valid (or lack signatures = because someone in the middle doesn't have BGPsec turned on), I think it = is probably a good idea to use that route despite the lack of valid = signature chain. Considering whether a route is "the only route you know" is explicitly = forbidden by RFC 4271: "The function that calculates the degree of preference for a given route SHALL NOT use any of the following as its inputs: the existence of other routes, the non-existence of other routes, or the path attributes of other routes." However, you can get the same result by simply giving the invalid path a = low local preference. However 2, the real problem with allowing prefixes that don't = RPKI/BGPsec validate is that these invalid prefixes could be more = specifics of legitimate prefixes, and no matter how high the local_pref = of the valid prefixes and low the local_pref of the invalid more = specifics, the packets will be forwarded as per the invalid more = specifics. Therefore, the only workable approach is to completely filter out = prefixes that don't validate. However, the downside of such a strict policy is that if the = certificates used for BGPsec signatures expire, the path will become = notvalid and the associated prefixes disappear from the internet. That's = why we need the ability to treat paths that don't validate because of = expired certificates differently from paths that don't validate for = other reasons.