From nobody Wed Jul 1 11:27: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 38BA61ACE5A; Wed, 1 Jul 2015 11:27:47 -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 VVWzBT45NVgO; Wed, 1 Jul 2015 11:27:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EF3391AC3BB; Wed, 1 Jul 2015 11:27:45 -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.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150701182745.8452.91056.idtracker@ietfa.amsl.com> Date: Wed, 01 Jul 2015 11:27:45 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-rs-bfd-00.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, 01 Jul 2015 18:27:47 -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 : Making Route Servers Aware of Data Link Failures at IXPs Authors : Randy Bush Jeffrey Haas John G. Scudder Arnold Nipper Thomas King Filename : draft-ietf-idr-rs-bfd-00.txt Pages : 8 Date : 2015-07-01 Abstract: When route servers are used, the data plane is not congruent with the control plane. Therefore, the peers on the Internet exchange can lose data connectivity without the control plane being aware of it, and packets are dropped on the floor. This document proposes the use of BFD between the two peering routers to detect a data plane failure, and then uses BGP next hop cost to signal the state of the data link to the route server(s). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-rs-bfd/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-rs-bfd-00 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 Jul 1 19:16: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 5AB251A0423; Wed, 1 Jul 2015 19:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.21 X-Spam-Level: X-Spam-Status: No, score=-104.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, 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 3UpcXC-w3L7U; Wed, 1 Jul 2015 19:16:02 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 8F3681A014D; Wed, 1 Jul 2015 19:14:34 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 8E3A5989AC244; Thu, 2 Jul 2015 10:14:30 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 2161A4B26CF83; Thu, 2 Jul 2015 10:14:30 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id t622E1I3031163; Thu, 2 Jul 2015 10:14:01 +0800 (GMT-8) (envelope-from peng.shaofu@zte.com.cn) To: hannes@juniper.net MIME-Version: 1.0 Sensitivity: X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: peng.shaofu@zte.com.cn Date: Thu, 2 Jul 2015 10:13:57 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2015-07-02 10:14:01, Serialize complete at 2015-07-02 10:14:01 Content-Type: multipart/alternative; boundary="=_alternative 000C453348257E76_=" X-MAIL: mse01.zte.com.cn t622E1I3031163 Archived-At: Cc: idr@ietf.org, spring@ietf.org, isis-wg@ietf.org Subject: [Idr] questions about draft-ietf-idr-ls-distribution-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, 02 Jul 2015 02:16:05 -0000 This is a multipart message in MIME format. --=_alternative 000C453348257E76_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 aGkgaGFubmVzICYgb3RoZXIgYXV0aG9ycw0KDQpBcyBkZXNjcmliZWQgaW4gW0xpbmstU3RhdGUg SW5mbyBEaXN0cmlidXRpb24gdXNpbmcgQkdQXSAoc2VlIFNlY3Rpb24gDQozLjIuMiwgobBMaW5r IERlc2NyaXB0b3JzobEpLCB0aGUgSVAgYWRkcmVzcyBUTFZzIChUTFYgY29kZSAyNTktMjYyKSBv ciANCnRoZSBsaW5rIGxvY2FsL3JlbW90ZSBJZGVudGlmaWVyIFRMViAoVExWIGNvZGUgMjU4KSBh cmUgaW5jbHVkZWQgaW4gdGhlIA0KbGluayBkZXNjcmlwdG9yLiANCqGwVGhlIGluZm9ybWF0aW9u IGFib3V0IGEgbGluayBwcmVzZW50IGluIHRoZSBMU0EvTFNQIG9yaWdpbmF0ZWQgYnkgdGhlIA0K bG9jYWwgbm9kZSBvZiB0aGUgbGluayBkZXRlcm1pbmVzIHRoZSBzZXQgb2YgVExWcyBpbiB0aGUg TGluayBEZXNjcmlwdG9yIA0Kb2YgdGhlIGxpbmsuDQogICAgICBJZiBpbnRlcmZhY2UgYW5kIG5l aWdoYm9yIGFkZHJlc3NlcywgZWl0aGVyIElQdjQgb3IgSVB2NiwgYXJlIA0KcHJlc2VudCwgdGhl biB0aGUgSVAgYWRkcmVzcyBUTFZzIGFyZSBpbmNsdWRlZCBpbiB0aGUgbGluayBkZXNjcmlwdG9y LCBidXQgDQpub3QgdGhlIGxpbmsgbG9jYWwvcmVtb3RlIElkZW50aWZpZXIgVExWLiAgVGhlICAg ICAgbGluayBsb2NhbC9yZW1vdGUgDQppZGVudGlmaWVycyBNQVkgYmUgaW5jbHVkZWQgaW4gdGhl IGxpbmsgYXR0cmlidXRlLg0KICAgICAgSWYgaW50ZXJmYWNlIGFuZCBuZWlnaGJvciBhZGRyZXNz ZXMgYXJlIG5vdCBwcmVzZW50IGFuZCB0aGUgbGluayANCmxvY2FsL3JlbW90ZSBpZGVudGlmaWVy cyBhcmUgcHJlc2VudCwgdGhlbiB0aGUgbGluayBsb2NhbC9yZW1vdGUgDQpJZGVudGlmaWVyIFRM ViBpcyBpbmNsdWRlZCBpbiB0aGUgbGluayBkZXNjcmlwdG9yLqGxDQoNCldoZW4gdGhlIHVuZGVy bHlpbmcgSUdQIGlzIElTLUlTLCBMU1Agb3JpZ2luYXRlZCBieSB0aGUgbG9jYWwgbm9kZSBvZiB0 aGUgDQpsaW5rIE1BWSBOT1QgaW5jbHVkZSBJUHY0IGludGVyZmFjZSBhZGRyZXNzL0lQdjQgbmVp Z2hib3IgYWRkcmVzcyBvciBMaW5rIA0KTG9jYWwvUmVtb3RlIElkZW50aWZpZXJzIHN1Yi1UTFYg aW4gdGhlIChtYWluKSBJUyByZWFjaGFiaWxpdHkgVExWIHdoZW4gDQpNUExTIFRyYWZmaWMgRW5n aW5lZXJpbmcgaXMgbm90IGNvbmZpZ3VyZWQgZm9yIElTLUlTIChzZWUgU2VjdGlvbiAzLjIsIKGw DQpTdWItVExWIDY6IElQdjQgSW50ZXJmYWNlIEFkZHJlc3OhsSwgb2YgW1JGQzUzMDVdIGFuZCBT ZWN0aW9uIDEuMSwgobBMaW5rIA0KTG9jYWwvUmVtb3RlIElkZW50aWZpZXJzobEsIG9mIFtSRkM1 MzA3XSwgcmVzcGVjdGl2ZWx5KS4gDQoNClRodXMsIEJHUC1MUyBzcGVha2VyIE1BWSBsZWFybiB0 aGUgbWVudGlvbmVkIGxpbmsgaW5mb3JtYXRpb24sIGZyb20gTFNQIA0KZmxvb2RpbmcgcHJvY2Vz cywgd2l0aG91dCBkZXRhaWxlZCBpbnRlcmZhY2UgSVAvSUQgaW5mb3JtYXRpb24gb2YgYWxsIElH UCANCm5vZGVzIGluIHRoZSBCR1AtTFMgZG9tYWluLiAgSWYgQ09OU1VNRVIgY29sbGVjdCBsaW5r LXN0YXRlIGluZm9ybWF0aW9uIG9mIA0Kd2hvbGUgZG9tYWluIG9ubHkgZnJvbSBvbmUgQkdQLUxT IHNwZWFrZXIsIGl0IGNhbiBvbmx5IGVzdGFibGlzaCBvbmUgU1BUICwgDQp3aGljaCByb290IGlz IHRoZSBCR1AtTFMgc3BlYWtlci4gSW4gc29tZSBjYXNlLCBDT05TVU1FUiBuZWVkIGNyZWF0ZSAN CmRpZmZlcmVudCBTUFQgZm9yIGRpZmZlcmVudCBkZXZpY2UuIEZvciBleGFtcGxlLCBpbiBjZW50 cmFsIHNwcmluZyANCm5ldHdvcmssIHRoZSBDT05UUk9MTEVSIG5lZWQgZG93bmxvYWQgSUxNIGVu dHJ5IGZvciBhIGdsb2JhbCBsYWJlbCB0byBlYWNoIA0Kcm91dGVyLCB0aGUgSUxNIGZvcndhcmRp bmcgaW5mb3JtYXRpb24gaXMgZGVjaWRlZCBieSBlYWNoIHJvdXRlcidzIFNQVC4gSXQgDQppcyBk aWZmZXJlbnQgZm9yIGRpZmZlcmVudCByb3V0ZXIuDQogDQpzb21lIHNvbHV0aW9ucyBjb3VsZCBi ZToNCjEpIGFsbCBJR1Agbm9kZXMgaW4gdGhlIEJHUC1MUyBkb21haW4gYXJlIEJHUC1MUyBzcGVh a2Vycywgd2hlcmUgb25seSANCmxvY2FsIGxpbmsgaW5mb3JtYXRpb24gbmVlZCB0byBiZSBjb2xs ZWN0ZWQgYW5kIHNlbnQgdG8gQ09OU1VNRVIuIA0KMikgb25lIEJHUC1MUyBzcGVha2VyLCBidXQg YWxsIGxpbmsgYXJlIGNvbmZpZ3VyZWQgTVBMUyBUcmFmZmljIA0KRW5naW5lZXJpbmcobm90IGNl cnRhaW5seSBpbmNsdWRpbmcgc2lnbmFsIGNvbmZpZ3VyYXRpb24pLg0KDQpEbyB5b3UgaGF2ZSBh bnkgc3VnZ2VzdGlvbnMgYWJvdXQgdGhpcyBpc3N1ZT8gDQoNCnRoYW5rcw0KZGVjY2FuDQoNCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpa VEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVk IGluIHRoaXMgbWFpbCAoYW5kIGFueSBhdHRhY2htZW50IHRyYW5zbWl0dGVkIGhlcmV3aXRoKSBp cyBwcml2aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIGZvciB0aGUgZXhj bHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVzc2VlKHMpLiAgSWYgeW91IGFyZSBub3QgYW4gaW50ZW5k ZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBkaXN0cmlidXRpb24g b3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5l ZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtYWls IGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMgaW1tZWRpYXRlbHkuDQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K WlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5l ZCBpbiB0aGlzIG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0aCkg aXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4 Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZShzKS4gIElmIHlvdSBhcmUgbm90IGFuIGludGVu ZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgZGlzdHJpYnV0aW9u IG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiBjb250YWlu ZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWFp bCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5IHVzIGltbWVkaWF0ZWx5Lg0K --=_alternative 000C453348257E76_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8ZGl2Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPmhpIGhhbm5l cyAmYW1wOyBvdGhlciBhdXRob3JzPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MyBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPkFzIGRlc2NyaWJlZCBpbiBbTGluay1TdGF0ZSBJbmZvDQpEaXN0 cmlidXRpb24gdXNpbmcgQkdQXSAoc2VlIFNlY3Rpb24gMy4yLjIsIKGwTGluayBEZXNjcmlwdG9y c6GxKSwgdGhlDQpJUCBhZGRyZXNzIFRMVnMgKFRMViBjb2RlIDI1OS0yNjIpIG9yIHRoZSBsaW5r IGxvY2FsL3JlbW90ZSBJZGVudGlmaWVyDQpUTFYgKFRMViBjb2RlIDI1OCkgYXJlIGluY2x1ZGVk IGluIHRoZSBsaW5rIGRlc2NyaXB0b3IuIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0i VGltZXMgTmV3IFJvbWFuIj48aT6hsFRoZSBpbmZvcm1hdGlvbiBhYm91dCBhIGxpbmsNCnByZXNl bnQgaW4gdGhlIExTQS9MU1Agb3JpZ2luYXRlZCBieSB0aGUgbG9jYWwgbm9kZSBvZiB0aGUgbGlu ayBkZXRlcm1pbmVzDQp0aGUgc2V0IG9mIFRMVnMgaW4gdGhlIExpbmsgRGVzY3JpcHRvciBvZiB0 aGUgbGluay48L2k+PC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9t YW4iPjxpPiZuYnNwOyAmbmJzcDsgJm5ic3A7IElmIGludGVyZmFjZQ0KYW5kIG5laWdoYm9yIGFk ZHJlc3NlcywgZWl0aGVyIElQdjQgb3IgSVB2NiwgYXJlIHByZXNlbnQsIHRoZW4gdGhlIElQIGFk ZHJlc3MNClRMVnMgYXJlIGluY2x1ZGVkIGluIHRoZSBsaW5rIGRlc2NyaXB0b3IsIGJ1dCBub3Qg dGhlIGxpbmsgbG9jYWwvcmVtb3RlDQpJZGVudGlmaWVyIFRMVi4gJm5ic3A7VGhlICZuYnNwOyAm bmJzcDsgJm5ic3A7bGluayBsb2NhbC9yZW1vdGUgaWRlbnRpZmllcnMNCk1BWSBiZSBpbmNsdWRl ZCBpbiB0aGUgbGluayBhdHRyaWJ1dGUuPC9pPjwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIj48aT4mbmJzcDsgJm5ic3A7ICZuYnNwOyBJZiBpbnRlcmZhY2UN CmFuZCBuZWlnaGJvciBhZGRyZXNzZXMgYXJlIG5vdCBwcmVzZW50IGFuZCB0aGUgbGluayBsb2Nh bC9yZW1vdGUgaWRlbnRpZmllcnMNCmFyZSBwcmVzZW50LCB0aGVuIHRoZSBsaW5rIGxvY2FsL3Jl bW90ZSBJZGVudGlmaWVyIFRMViBpcyBpbmNsdWRlZCBpbiB0aGUNCmxpbmsgZGVzY3JpcHRvci6h sTwvaT48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21h biI+V2hlbiB0aGUgdW5kZXJseWluZyBJR1AgaXMgSVMtSVMsDQpMU1Agb3JpZ2luYXRlZCBieSB0 aGUgbG9jYWwgbm9kZSBvZiB0aGUgbGluayBNQVkgTk9UIGluY2x1ZGUgSVB2NCBpbnRlcmZhY2UN CmFkZHJlc3MvSVB2NCBuZWlnaGJvciBhZGRyZXNzIG9yIExpbmsgTG9jYWwvUmVtb3RlIElkZW50 aWZpZXJzIHN1Yi1UTFYNCmluIHRoZSAobWFpbikgSVMgcmVhY2hhYmlsaXR5IFRMViB3aGVuIE1Q TFMgVHJhZmZpYyBFbmdpbmVlcmluZyBpcyBub3QNCmNvbmZpZ3VyZWQgZm9yIElTLUlTIChzZWUg U2VjdGlvbiAzLjIsIKGwU3ViLVRMViA2OiBJUHY0IEludGVyZmFjZSBBZGRyZXNzobEsDQpvZiBb UkZDNTMwNV0gYW5kIFNlY3Rpb24gMS4xLCChsExpbmsgTG9jYWwvUmVtb3RlIElkZW50aWZpZXJz obEsIG9mIFtSRkM1MzA3XSwNCnJlc3BlY3RpdmVseSkuIDwvZm9udD4NCjxicj4NCjxicj48Zm9u dCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5UaHVzLCBCR1AtTFMgc3BlYWtlciBNQVkg bGVhcm4NCnRoZSBtZW50aW9uZWQgbGluayBpbmZvcm1hdGlvbiwgZnJvbSBMU1AgZmxvb2Rpbmcg cHJvY2Vzcywgd2l0aG91dCBkZXRhaWxlZA0KaW50ZXJmYWNlIElQL0lEIGluZm9ybWF0aW9uIG9m IGFsbCBJR1Agbm9kZXMgaW4gdGhlIEJHUC1MUyBkb21haW4uICZuYnNwO0lmDQpDT05TVU1FUiBj b2xsZWN0IGxpbmstc3RhdGUgaW5mb3JtYXRpb24gb2Ygd2hvbGUgZG9tYWluIG9ubHkgZnJvbSBv bmUgQkdQLUxTDQpzcGVha2VyLCBpdCBjYW4gb25seSBlc3RhYmxpc2ggb25lIFNQVCAsIHdoaWNo IHJvb3QgaXMgdGhlIEJHUC1MUyBzcGVha2VyLg0KSW4gc29tZSBjYXNlLCBDT05TVU1FUiBuZWVk IGNyZWF0ZSBkaWZmZXJlbnQgU1BUIGZvciBkaWZmZXJlbnQgZGV2aWNlLg0KRm9yIGV4YW1wbGUs IGluIGNlbnRyYWwgc3ByaW5nIG5ldHdvcmssIHRoZSBDT05UUk9MTEVSIG5lZWQgZG93bmxvYWQg SUxNDQplbnRyeSBmb3IgYSBnbG9iYWwgbGFiZWwgdG8gZWFjaCByb3V0ZXIsIHRoZSBJTE0gZm9y d2FyZGluZyBpbmZvcm1hdGlvbg0KaXMgZGVjaWRlZCBieSBlYWNoIHJvdXRlcidzIFNQVC4gSXQg aXMgZGlmZmVyZW50IGZvciBkaWZmZXJlbnQgcm91dGVyLjwvZm9udD4NCjxicj48Zm9udCBzaXpl PTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0z IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+c29tZSBzb2x1dGlvbnMgY291bGQgYmU6PC9mb250Pg0K PGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjEpIGFsbCBJR1Agbm9kZXMg aW4gdGhlIEJHUC1MUw0KZG9tYWluIGFyZSBCR1AtTFMgc3BlYWtlcnMsIHdoZXJlIG9ubHkgbG9j YWwgbGluayBpbmZvcm1hdGlvbiBuZWVkIHRvIGJlDQpjb2xsZWN0ZWQgYW5kIHNlbnQgdG8gQ09O U1VNRVIuIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4y KSBvbmUgQkdQLUxTIHNwZWFrZXIsIGJ1dCBhbGwNCmxpbmsgYXJlIGNvbmZpZ3VyZWQgTVBMUyBU cmFmZmljIEVuZ2luZWVyaW5nKG5vdCBjZXJ0YWlubHkgaW5jbHVkaW5nIHNpZ25hbA0KY29uZmln dXJhdGlvbikuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcg Um9tYW4iPkRvIHlvdSBoYXZlIGFueSBzdWdnZXN0aW9ucyBhYm91dA0KdGhpcyBpc3N1ZT8gPC9m b250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj50aGFua3M8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmRlY2NhbjwvZm9udD4NCjxi cj48L2Rpdj4NCg0KPGJyPjxwcmU+PGZvbnQgY29sb3I9ImJsdWUiPg0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlv biBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWls IChhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQg YW5kIGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9m IHRoZSBhZGRyZXNzZWUocykuICBJZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQs IGFueSBkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBvdGhlciBkaXNz ZW1pbmF0aW9uIG9yIHVzZSBvZiB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlzIHN0cmljdGx5 IHByb2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1haWwgaW4gZXJyb3IsIHBs ZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1lZGlhdGVseS4NCg0KPC9mb250PjwvcHJl Pjxicj4NCg0KPGJyPjxwcmU+PGZvbnQgY29sb3I9ImJsdWUiPg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBT ZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIChh bmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5k IGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRo ZSBhZGRyZXNzZWUocykuICBJZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIGFu eSBkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBvdGhlciBkaXNzZW1p bmF0aW9uIG9yIHVzZSBvZiB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlzIHN0cmljdGx5IHBy b2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFz ZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1lZGlhdGVseS4NCg0KPC9mb250PjwvcHJlPjxi cj4NCg== --=_alternative 000C453348257E76_=-- From nobody Thu Jul 2 07:34: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 682C21A88BA for ; Thu, 2 Jul 2015 07:34:23 -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 24KwR2t0am3P for ; Thu, 2 Jul 2015 07:34:21 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0136.outbound.protection.outlook.com [207.46.100.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE7E91A88C8 for ; Thu, 2 Jul 2015 07:34:13 -0700 (PDT) Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none; Received: from mguglani-sslvpn-nc.jnpr.net (66.129.241.14) by CY1PR0501MB1835.namprd05.prod.outlook.com (10.163.141.149) with Microsoft SMTP Server (TLS) id 15.1.195.15; Thu, 2 Jul 2015 14:34:10 +0000 From: "John G. Scudder" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 2 Jul 2015 10:33:51 -0400 References: <20150702142348.4291.10005.idtracker@ietfa.amsl.com> To: "idr@ietf. org" Message-ID: <7C5305E5-69BF-4796-900A-726FFE4B2EEE@juniper.net> MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) X-Mailer: Apple Mail (2.2102) X-Originating-IP: [66.129.241.14] X-ClientProxiedBy: CY1PR17CA0042.namprd17.prod.outlook.com (25.163.68.52) To CY1PR0501MB1835.namprd05.prod.outlook.com (25.163.141.149) X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1835; 2:7rFgyc3noqWRGECgAMUh+lYMPfzIJR+YWD/9sMJjRe8ClzWlu8KjwV6glhCxUMD+; 3:phGym3YTk/trP/6+7BrCSkfmGGNmVMukgmuetPL1noNTHzuCiWXgW3vvpKZg1hJZib4PFzL1hadOPyTSlGFI/HzUIoOilRZr6YQYCQ1RDYb9VJoHKjSoWnOvRjZvesqJ6GJnVKif77GC7CbQPFvMNA==; 20:a+SLUqAdCGfBpqM1WnN5NNZHEwLkNEKSMQMr9aP/hreNNE99GJm6A1GLAQikNy5xSeMWD6CPzTwsuBaokAPmNs1UkVsUg6G6ANzOh+r6TrJ0+hXqBMsD23ynWT6WI38SX+rnXhIRZII1uZYj0TKt6JvHv0ZzI/N9MgR2uwRgIsa1mvr8364Se1KzjMtcP2OW0JRKnH7U790/Hr0bW+0n3Fu6ZWapUj4nJGwOmsMOryag9PQttnIRjDl+sWZR2VdW6jnM8yLErdu9elBBMlNP/hf0mPc9POqeIfHCFlRlmnDutF8WsuW5sUro/UI8lhxZY2GM+JiDapuz61TVH5bWSBZNjYHOOabYgppZ0RpJ8GYz6jKgiTrBAeL+hewVwiM0xJtheYPLIuQ1Tu0leNGp59h4a/laDJyUQh8mK86KUDqvZRwWebrDR193YBEXPaxAJ8Bpkygw5jm+svSFpaLJqlpqgW7iKuGa1+hvtFSUKEnSGr9r1VwLZYsbipSMFOrn X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1835; 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:CY1PR0501MB1835; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1835; X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1835; 4:YYRa7u6XQFGihU3mimBDRWGuik3H4PB0Z/yuhGV9Ztc2/XDK86cS281KQFmcyNcckkq96jsZcBsxFvf7btWqqAsQIoQJ2JUrq2XU+kmLYHPRoK9XqoF8hPZtHJyzct/JVtom1dfpjCjvNWFQ0k/w8uPisOKuk637LNJ2RluLXBFYLga5wlOQ1m0axhz2MHsIpwlQhgBhBUnL2P4SZFwEWUqd81VqmGIvEL5A9h4qiVTyY4XTdJFIqmQNP0HQ6p2vZ55+u3YnQAX54l7ThPvcpoj3ZSqBECvV0dp1yFLLPb8= X-Forefront-PRVS: 06259BA5A2 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(377454003)(51704005)(2473001)(377424004)(53754006)(23726002)(5001960100002)(46406003)(53416004)(110136002)(36756003)(50466002)(57306001)(230783001)(107886002)(189998001)(42186005)(77156002)(40100003)(50226001)(97756001)(15975445007)(86362001)(87976001)(46102003)(77096005)(83716003)(82746002)(92566002)(122386002)(62966003)(33656002)(19580395003)(19580405001)(450100001)(47776003)(76176999)(50986999)(66066001)(42262002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1835; H:mguglani-sslvpn-nc.jnpr.net; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR0501MB1835; 23:XnxQn8gA5MQbqFLJ0gIs8E8BcQoqYKPMY+3jRuc?= =?us-ascii?Q?38lSwHDqnKyWeyik91sIJmaGAnjpePjiEm/WFFm7yUmiVWpE4Aa/VmRAnPGD?= =?us-ascii?Q?yttraGtHVySEwXJzC2LAS5PCce2WaO+1dzpXWQ+ch4PEEE/1AWZi5PYOovy7?= =?us-ascii?Q?9tAF5EilQ9S5h2VcHa8o/FJcgPaIS37imYgiTaS07L1pEqntpJWeY8O522Rq?= =?us-ascii?Q?VaiIqbxzpjNzbS8iFa3xH/i0decxYrQb0h4kx/x6sL/qlIat2CQCLmLMD1an?= =?us-ascii?Q?PWwfj0A+hhcfyO2PlR3JuR30xUrZH7F5jxSPa3Ldp+habwCXnS3pdewCllNp?= =?us-ascii?Q?CI6UtBGFVTjIVE5CKtoIiuW2Jc5wbDs0EJj4CqVVJLCvtodl1Ohm+KbJPjEG?= =?us-ascii?Q?j5AmUQk4uEtqUq95R1TrVDs3Vnih7ZbU5fyFBvro3qk9IPVW7DolGIrE0+fk?= =?us-ascii?Q?jT9aXx2EYywTLTqCC7KTc117ctn10dmn5vbzSj1W2OyMNvoOS5IpfiCAIU/1?= =?us-ascii?Q?ZbkE0Pw35WGBi5RCZDCBrtvxnYIGil9YqYvAQ1zg0v1v3JIB5K1quHZFU6B8?= =?us-ascii?Q?ctTNfJoi7WlI+IldsCLvSwHxiDeCR+4ITJIjdmRcF3ntGJR8rvcMX+c8M+3S?= =?us-ascii?Q?c/wC0Um15ZBCltyA5/e4P7Uhei+mefF9vosg1kgiDRau33QyhfQ0xZlFOLVn?= =?us-ascii?Q?IRqzOIuzGTciJE6N8x5Y8B8gLYhyWfA5zxbE37GWlyIPazBeoQgxBrZceJCV?= =?us-ascii?Q?RkAcmKCChX/wDMpIIxt31mLVt6esAYI0NEi7ePFPsw9GKzXNOllutSQM7qmp?= =?us-ascii?Q?h/ZfkdOHty91+ZPrDPo1kibrWwBeH9sJ+DG9AKcP7CjxER2PQohgZbXmyhvT?= =?us-ascii?Q?MVkWlhtnZjco2PB+aUFM2XCY+oC3zIx4+FV71YTJGupKs7ihtyKPy3L4anVS?= =?us-ascii?Q?W2ohGk5aZG+LYIY/NvWN1h1eUY6vZIFaWZp29U1mFm1WHMBAyfAuRenYHNkL?= =?us-ascii?Q?pSSU6E52ryTHi5w5NEhiqQwMlGceu1djU+3drdIv7FmUyNNQX2DgXPwSwLrm?= =?us-ascii?Q?a/8HQteiKjgrK08o1+PFmrzu56ubfdv+qPLFxGJY4phPLMGy86ZcJXQ8b3wM?= =?us-ascii?Q?p6YBmBZBXZfo=3D?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1835; 5:97Wql33Vgaar9s5zzCCYdHZ64PWiRRfHo+HHclWKTzbZJvoSwMlefxJ9dx8eHbPX0UZeQVXzoG6zSxh5i4jScCfhJ3noibiqfcYZvg2R1fyM/ZaxHbiS4NRcMREoB+eCCDY9SFWVstPYjYJ1HsE4Uw==; 24:DmeiNBh6JoXH//Cl+K+fuRjyTY2iyFY/NrovZLHpHW4vmOIiYFCFTHaEg2ROwQf966pQV43qE5QAkbpsydL5vnDpUWXipr8d+BB9z6vPzOo=; 20:ld0qZZdXrq/CqqeVwAkhRI08RqJKQ5kP6+vtm8ZgFUSkWz7RQAV90SPguhN36QXrgoLuna6x1jXthcyaRiN3Ow== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Jul 2015 14:34:10.0960 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1835 Archived-At: Subject: [Idr] Fwd: New Version Notification for draft-scudder-idr-capabilities-registry-change-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 14:34:23 -0000 Hi Everybody, I was looking at the registration procedures for Capability codes = recently, and they are not what I would have picked if specifying = Capabilities today. In order to revise the procedures, IANA requires an = RFC. Accordingly, I've written a very short Internet Draft and would = like to propose it as a working group item. It's so short that I'll = paste the entire meat of it here: [RFC5492] designates the range of Capability Codes 128-255 as "Reserved for Private Use". Subsequent experience has shown this to be not only useless, but actively confusing to implementors. BGP Capability Codes do not meet the criteria for "Reserved for Private Use" described in [RFC5226] S. 4.1. An example of a legitimate "private use" code point might be a BGP community [RFC1997] value assigned for use within a given AS, but no analogous use of Capabilities exists. Accordingly, this document revises the registration procedures for the range 128-255, as follows, using the terminology defined in [RFC5226]: 128-250: Standards Action 251-254: Experimental Use 255: Reserved The procedures for the ranges 1-63 and 64-127 are unchanged, remaining "IETF Review" and "First Come First Served" respectively. That's it. Even with boilerplate and some explanatory text the whole = thing comes to just over 3 pages. I'm not wedded to the exact ranges and = policies I put in the document, I just needed something as a stake in = the ground. I put in a section with my reasoning, though, and here's a = little more: Q: Why Standards Action? A: we already have a decent-sized FCFS range. Standards Action precludes = any risk of a "run on the bank" exhausting the number space. We can = always reclassify it again in the future if we need to. Q: Why Experimental Use? A: There is a legitimate need for temporary code points to be used = during internal development. It's better to have these come from an = identifiable "swamp" than it is to have developers squat on random code = points. Q: Why Reserved? A: No very compelling reason other than that reserving the all-ones = value is kind of traditional and there doesn't seem to be a strong = reason not to. It's true that the all-zeroes value is already reserved, = so the need for reserving all-ones is questionable, but OTOH it also = seems harmless to do it, especially given that again, we can always = reclassify it in the future if needed.=20 There are currently no registrations in the range 128-255, so hopefully = this change should create no issues. However, if someone is currently = squatting on a code point in this range, now would be a good time to = come in out of the cold so we can consider grandfathering their usage if = warranted. I think given the previous designation as "private use" it = would be hard to fault anyone for having mistakenly made use of a number = in this range.=20 Thanks, --John > Begin forwarded message: >=20 > From: > Subject: New Version Notification for = draft-scudder-idr-capabilities-registry-change-00.txt > Date: July 2, 2015 at 10:23:48 AM EDT > To: John Scudder , John Scudder >=20 >=20 > A new version of I-D, = draft-scudder-idr-capabilities-registry-change-00.txt > has been successfully submitted by John Scudder and posted to the > IETF repository. >=20 > Name: draft-scudder-idr-capabilities-registry-change > Revision: 00 > Title: Revision to Capability Codes Registration = Procedures > Document date: 2015-07-02 > Group: Individual Submission > Pages: 4 > URL: = https://www.ietf.org/internet-drafts/draft-scudder-idr-capabilities-regist= ry-change-00.txt > Status: = https://datatracker.ietf.org/doc/draft-scudder-idr-capabilities-registry-c= hange/ > Htmlized: = https://tools.ietf.org/html/draft-scudder-idr-capabilities-registry-change= -00 >=20 >=20 > Abstract: > This document updates RFC 5492 by making a change to the = registration > procedures for BGP Capability Codes. Specifically, the range > formerly designated "Reserved for Private Use" is divided into three > new ranges, respectively designated as "Standards Action", > "Experimental" and "Reserved". >=20 >=20 >=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 > The IETF Secretariat >=20 From nobody Thu Jul 2 07:50: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 5619C1A897A for ; Thu, 2 Jul 2015 07:50:04 -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 vXo0EHKxe1Qs for ; Thu, 2 Jul 2015 07:49:58 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id B64C01A8979 for ; Thu, 2 Jul 2015 07:49:57 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 8C1461E430; Thu, 2 Jul 2015 10:51:30 -0400 (EDT) Date: Thu, 2 Jul 2015 10:51:30 -0400 From: Jeffrey Haas To: "John G. Scudder" Message-ID: <20150702145130.GE29902@pfrc.org> References: <20150702142348.4291.10005.idtracker@ietfa.amsl.com> <7C5305E5-69BF-4796-900A-726FFE4B2EEE@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7C5305E5-69BF-4796-900A-726FFE4B2EEE@juniper.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "idr@ietf. org" Subject: Re: [Idr] Fwd: New Version Notification for draft-scudder-idr-capabilities-registry-change-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 14:50:04 -0000 On Thu, Jul 02, 2015 at 10:33:51AM -0400, John G. Scudder wrote: > I was looking at the registration procedures for Capability codes > recently, and they are not what I would have picked if specifying > Capabilities today. In order to revise the procedures, IANA requires an > RFC. Accordingly, I've written a very short Internet Draft and would like > to propose it as a working group item. It's so short that I'll paste the > entire meat of it here: I'm supportive of this proposal. -- Jeff From nobody Thu Jul 2 14: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 709AC1A1A78; Thu, 2 Jul 2015 14:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MezCSeg5H1R0; Thu, 2 Jul 2015 14:09:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 77E8A1A1ABC; Thu, 2 Jul 2015 14:08:59 -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.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150702210859.31105.70475.idtracker@ietfa.amsl.com> Date: Thu, 02 Jul 2015 14:08:59 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-optimal-route-reflection-10.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, 02 Jul 2015 21:09:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : 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-10.txt Pages : 9 Date : 2015-07-02 Abstract: This document proposes a solution for BGP route reflectors to facilitate the application of closest exit point policy (hot potato routing) without requiring further state or any new features to be placed on the RR clients. This solution is primarily applicable in deployments using centralized route reflectors. The solution relies upon all route reflectors learning all paths which are eligible for consideration for hot potato routing. Best path selection is performed in each route reflector based on a configured virtual location in the IGP. The location can be the same for all clients or different per peer/update group or per neighbour. 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: https://tools.ietf.org/html/draft-ietf-idr-bgp-optimal-route-reflection-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-optimal-route-reflection-10 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 Jul 2 16:33: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 506D91ACDCD for ; Thu, 2 Jul 2015 16:33:54 -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 g2kAiWw4NOOS for ; Thu, 2 Jul 2015 16:33:53 -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 6DAFA1ACDCB for ; Thu, 2 Jul 2015 16:33:53 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1ZAnzK-0008Og-Tr; Thu, 02 Jul 2015 23:33:51 +0000 Date: Fri, 03 Jul 2015 08:33:49 +0900 Message-ID: From: Randy Bush To: "John G. Scudder" In-Reply-To: <7C5305E5-69BF-4796-900A-726FFE4B2EEE@juniper.net> References: <20150702142348.4291.10005.idtracker@ietfa.amsl.com> <7C5305E5-69BF-4796-900A-726FFE4B2EEE@juniper.net> 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 Subject: Re: [Idr] Fwd: New Version Notification for draft-scudder-idr-capabilities-registry-change-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 23:33:54 -0000 have read. support adoption. randy From nobody Fri Jul 3 01:29: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 74BE21ABD3F for ; Fri, 3 Jul 2015 01:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=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 DxtgXvJlNPDQ for ; Fri, 3 Jul 2015 01:29:29 -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 5C7B41ABD3E for ; Fri, 3 Jul 2015 01:29:29 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 1D36118C2E2; Fri, 3 Jul 2015 10:29:28 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.41]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id F359323807B; Fri, 3 Jul 2015 10:29:27 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM31.corporate.adroot.infra.ftgroup ([fe80::2cc9:4bac:7b7d:229d%19]) with mapi id 14.03.0235.001; Fri, 3 Jul 2015 10:29:27 +0200 From: To: "John G. Scudder" Thread-Topic: [Idr] Fwd: New Version Notification for draft-scudder-idr-capabilities-registry-change-00.txt Thread-Index: AQHQtR+dVPYPLH8uQkahhyHYsy6rep3JY01A Date: Fri, 3 Jul 2015 08:29:26 +0000 Message-ID: <14990_1435912168_559647E8_14990_2582_1_53C29892C857584299CBF5D05346208A0F5DA6ED@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <20150702142348.4291.10005.idtracker@ietfa.amsl.com> <7C5305E5-69BF-4796-900A-726FFE4B2EEE@juniper.net> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.7.3.81516 Archived-At: Cc: idr wg list Subject: Re: [Idr] Fwd: New Version Notification for draft-scudder-idr-capabilities-registry-change-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2015 08:29:31 -0000 > From: Randy Bush > Sent: Friday, July 03, 2015 1:34 AM >=20 > have read. support adoption. +1 Please find below 1 comment=20 > From: John G. Scudder > Sent: Thursday, July 02, 2015 4:34 PM [...] > There are currently no registrations in the range 128-255, so hopefully t= his > change should create no issues. There are no IANA registrations because they can't be: "128-255 Reserved f= or Private Use IANA does not assign" A priori there are no other non-official registries, so we can't really kno= w (for sure) whether some code points are used. > However, if someone is currently squatting > on a code point in this range, now would be a good time to come in out of > the cold so we can consider grandfathering their usage if warranted. I th= ink > given the previous designation as "private use" it would be hard to fault > anyone for having mistakenly made use of a number in this range. In the worst case where multiple people use the same code point, it seems a= lso possible to register multiple use or even private use for such code poi= nt. Given that the most probable code point (possibly) picked are likely to be = 128 and 255, that's one more reason to have 255 reserved. To be on the extr= a safe side, I would propose to also have 128 reserved. 1 last question. IINM we would have the following registration policies: "1-63 IETF Review=20=09 64-127 First Come First Served 128-250: Standards Action 251-254: Experimental Use 255: Reserved" Then let's suppose that a new STD track RFC ask the IANA for a code point. = A priori such RFC is eligible for all ranges. Which range would the IANA (t= ypically) pick the value from? One option is to pick in the "strongest" ran= ge. In which case, we introduce a (very low) probability of code point coll= ision for the most "official" code points. I don't feel that this is desira= ble. An option would be to move the FCFS policy to this 128-250 range, and use S= tandards Action for 64-127. Thanks, /Bruno =20 > Thanks, >=20 > --John >=20 > > Begin forwarded message: > > > > From: > > Subject: New Version Notification for > > draft-scudder-idr-capabilities-registry-change-00.txt > > Date: July 2, 2015 at 10:23:48 AM EDT > > To: John Scudder , John Scudder > > > > > > A new version of I-D, > > draft-scudder-idr-capabilities-registry-change-00.txt > > has been successfully submitted by John Scudder and posted to the IETF > > repository. > > > > Name: draft-scudder-idr-capabilities-registry-change > > Revision: 00 > > Title: Revision to Capability Codes Registration Procedures > > Document date: 2015-07-02 > > Group: Individual Submission > > Pages: 4 > > URL: https://www.ietf.org/internet-drafts/draft-scudder-idr- > capabilities-registry-change-00.txt > > Status: https://datatracker.ietf.org/doc/draft-scudder-idr-capa= bilities- > registry-change/ > > Htmlized: https://tools.ietf.org/html/draft-scudder-idr-capabilit= ies- > registry-change-00 > > > > > > Abstract: > > This document updates RFC 5492 by making a change to the registration > > procedures for BGP Capability Codes. Specifically, the range > > formerly designated "Reserved for Private Use" is divided into three > > new ranges, respectively designated as "Standards Action", > > "Experimental" and "Reserved". > > > > > > > > > > Please note that it may take a couple of minutes from the time of > > submission until the htmlized version and diff are available at > tools.ietf.org. > > > > The IETF Secretariat > > >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 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. From nobody Fri Jul 3 02:28: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 7A24F1B2A11 for ; Fri, 3 Jul 2015 02:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y61zhs5-Pvxw for ; Fri, 3 Jul 2015 02:28:26 -0700 (PDT) Received: from out-1.mail.exa.net.uk (out-1.mail.exa.net.uk [82.219.4.129]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EDD61B2A0C for ; Fri, 3 Jul 2015 02:28:25 -0700 (PDT) Received: from smtp-1.mail.exa.net.uk (smtp-1.mail.exa.net.uk [82.219.5.1]) by out-1.mail.exa.net.uk (ExaSMTPD) with ESMTP id E7CE11C0087 for ; Fri, 3 Jul 2015 10:28:23 +0100 (BST) Received: from smtp-1.mail.exa.net.uk (localhost [127.0.0.1]) by smtp-1.mail.exa.net.uk (ExaSMTPD) with ESMTP id D17F92211FC for ; Fri, 3 Jul 2015 10:28:23 +0100 (BST) Received: from [192.0.2.63] (office.exa-networks.co.uk [82.219.212.253]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: thomas@mangin.com) by smtp-1.mail.exa.net.uk (ExaSMTPD) with ESMTPSA for ; Fri, 3 Jul 2015 10:28:23 +0100 (BST) From: "Thomas Mangin" To: "idr@ietf. org" Date: Fri, 03 Jul 2015 10:28:23 +0100 Message-ID: In-Reply-To: <7C5305E5-69BF-4796-900A-726FFE4B2EEE@juniper.net> References: <20150702142348.4291.10005.idtracker@ietfa.amsl.com> <7C5305E5-69BF-4796-900A-726FFE4B2EEE@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: MailMate (1.9.1r5084) X-Virus-Scanned: clamav-milter 0.98.7 at out-2-2.mail.exa.net.uk X-Virus-Status: Clean Archived-At: Subject: Re: [Idr] New Version Notification for draft-scudder-idr-capabilities-registry-change-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2015 09:28:29 -0000 Hello John, If I understand your draft correctly ( it is a big assumption ) the new = proposal would seem to make it much harder to experiment: Only allowing = 4 code for experimental use means that no more than 4 new features can = be tested simultaneously by a single vendor ( and less if two or more = vendors want to collaborate on a feature together ). This seems to me to = be quite on the very low side, I would feel better if this number was to = be raised. Therefore I would like to know if the authors would consider raising the = number from 4 and make a distinction between private for internal use = only ( most likely going to be used by a single vendor ) and private for = interop testing ( when two vendor who implemented the same draft may = want to check all is fine before getting a code and going to production = / IANA allocation process). I am also unsure if code 128 ( CISCO Route-Refresh ) and 131 ( CISCO = multi-session ) are still found in production networks ( AFAIK it was = the case a few years ago ), and if so, if this situation require = formalising. ExaBGP also use the following code in the 128+ range: 184, cumulus = hostname draft; 185, operational draft. Would you expect me to relocate = these code into the new 251-254 range ? Other codes may be found in production =E2=80=9Calive and kicking=E2=80=9D= in the = 128+ range too. I am not sure how much of a problem (if any) it is. Sincerely, Thomas http://exa.net.uk/about/contact-us On 2 Jul 2015, at 15:33, John G. Scudder wrote: > Hi Everybody, > > I was looking at the registration procedures for Capability codes = > recently, and they are not what I would have picked if specifying = > Capabilities today. In order to revise the procedures, IANA requires = > an RFC. Accordingly, I've written a very short Internet Draft and = > would like to propose it as a working group item. It's so short that = > I'll paste the entire meat of it here: > > [RFC5492] designates the range of Capability Codes 128-255 as > "Reserved for Private Use". Subsequent experience has shown this to > be not only useless, but actively confusing to implementors. BGP > Capability Codes do not meet the criteria for "Reserved for Private > Use" described in [RFC5226] S. 4.1. An example of a legitimate > "private use" code point might be a BGP community [RFC1997] value > assigned for use within a given AS, but no analogous use of > Capabilities exists. > > Accordingly, this document revises the registration procedures for > the range 128-255, as follows, using the terminology defined in > [RFC5226]: > > 128-250: Standards Action > > 251-254: Experimental Use > > 255: Reserved > > The procedures for the ranges 1-63 and 64-127 are unchanged, > remaining "IETF Review" and "First Come First Served" respectively. > > That's it. Even with boilerplate and some explanatory text the whole = > thing comes to just over 3 pages. I'm not wedded to the exact ranges = > and policies I put in the document, I just needed something as a stake = > in the ground. I put in a section with my reasoning, though, and = > here's a little more: > > Q: Why Standards Action? > A: we already have a decent-sized FCFS range. Standards Action = > precludes any risk of a "run on the bank" exhausting the number space. = > We can always reclassify it again in the future if we need to. > > Q: Why Experimental Use? > A: There is a legitimate need for temporary code points to be used = > during internal development. It's better to have these come from an = > identifiable "swamp" than it is to have developers squat on random = > code points. > > Q: Why Reserved? > A: No very compelling reason other than that reserving the all-ones = > value is kind of traditional and there doesn't seem to be a strong = > reason not to. It's true that the all-zeroes value is already = > reserved, so the need for reserving all-ones is questionable, but OTOH = > it also seems harmless to do it, especially given that again, we can = > always reclassify it in the future if needed. > > There are currently no registrations in the range 128-255, so = > hopefully this change should create no issues. However, if someone is = > currently squatting on a code point in this range, now would be a good = > time to come in out of the cold so we can consider grandfathering = > their usage if warranted. I think given the previous designation as = > "private use" it would be hard to fault anyone for having mistakenly = > made use of a number in this range. > > Thanks, > > --John > >> Begin forwarded message: >> >> From: >> Subject: New Version Notification for = >> draft-scudder-idr-capabilities-registry-change-00.txt >> Date: July 2, 2015 at 10:23:48 AM EDT >> To: John Scudder , John Scudder >> >> >> A new version of I-D, = >> draft-scudder-idr-capabilities-registry-change-00.txt >> has been successfully submitted by John Scudder and posted to the >> IETF repository. >> >> Name: draft-scudder-idr-capabilities-registry-change >> Revision: 00 >> Title: Revision to Capability Codes Registration Procedures >> Document date: 2015-07-02 >> Group: Individual Submission >> Pages: 4 >> URL: = >> https://www.ietf.org/internet-drafts/draft-scudder-idr-capabilities-re= gistry-change-00.txt >> Status: = >> https://datatracker.ietf.org/doc/draft-scudder-idr-capabilities-regist= ry-change/ >> Htmlized: = >> https://tools.ietf.org/html/draft-scudder-idr-capabilities-registry-ch= ange-00 >> >> >> Abstract: >> This document updates RFC 5492 by making a change to the registration >> procedures for BGP Capability Codes. Specifically, the range >> formerly designated "Reserved for Private Use" is divided into three >> new ranges, respectively designated as "Standards Action", >> "Experimental" and "Reserved". >> >> >> >> >> Please note that it may take a couple of minutes from the time of = >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Fri Jul 3 10:32: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 7EBE71A0123 for ; Fri, 3 Jul 2015 10:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.74 X-Spam-Level: * X-Spam-Status: No, score=1.74 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, 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 FBFFbw-mbPxw for ; Fri, 3 Jul 2015 10:32:48 -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 831421A0108 for ; Fri, 3 Jul 2015 10:32:47 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BUR51143; Fri, 03 Jul 2015 17:32:46 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 3 Jul 2015 18:32:45 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.135]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Sat, 4 Jul 2015 01:32:41 +0800 From: Lizhenbin To: "erosen@juniper.net" Thread-Topic: draft-rosen-tunnel-encaps-00.txt Thread-Index: AQHQspeo/crwlAlUjU+qaPs2zIJpIp3KAmh0 Date: Fri, 3 Jul 2015 17:32:40 +0000 Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D8C9FF3F5@nkgeml506-mbx.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.46.219.96] Content-Type: multipart/alternative; boundary="_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D8C9FF3F5nkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "Keyur Patel \(keyupate\)" , "idr@ietf.org" Subject: [Idr] =?gb2312?b?tPC4tDogZHJhZnQtcm9zZW4tdHVubmVsLWVuY2Fwcy0wMC50?= =?gb2312?b?eHQ=?= 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, 03 Jul 2015 17:32:49 -0000 --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D8C9FF3F5nkgeml506mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgRXJpYywNCg0KSSB0aGluayB0aGUgZHJhZnQgaXMgdXNlZnVsIGluIG1hbnkgYXBwbGljYXRp b24gc2NlbmFyaW9zLiBJbiBmYWN0LCB3ZSBoYXZlIHByb3Bvc2VkIHRoZSBkcmFmdCBkcmFmdC1s aS1pZHItbXBscy1wYXRoLXByb2dyYW1taW5nLTAxIGluIHdoaWNoIHdlIGFsc28gd2FudGVkIHRv DQoNCmludHJvZHVjZSB0aGUgdHVubmVsIGF0dHJpYnV0ZXMgd2hpY2ggY2FuIGJlIGFwcGxpZWQg dG8gbXVsdGlwbGUgQkdQIEFGSS9TQUZJcy4gQWNjb3JkaW5nIHRvIG91ciB1c2VjYXNlLCB0aGUg dHVubmVsIGNvbnNpZGVyZWQgaW4gdGhlIGRyYWZ0IGFyZSBhbG1vc3QgTVBMUyB0dW5uZWxzLg0K DQpBY2NvcmRpbmcgdG8gbXkgdW5kZXJzdGFuZGluZywgZm9yIHRoZSBkcmFmdCBkcmFmdC1yb3Nl bi10dW5uZWwtZW5jYXBzLTAwIEkgdGhpbmsgdGhlIHR1bm5lbCB0eXBlcyBkZWZpbmVkIGhlcmUg YXJlIGFsbW9zdCBJUCB0dW5uZWxzIHVzZWQgZm9yIGRhdGEgY2VudGVyIHNjZW5hcmlvcy4NCg0K V2hlbiBJIHRyYWNrZWQgdG8gUkZDIDU1MTIsIGl0IGFsc28gb25seSBkZWZpbmVkIElQIHR1bm5l bHMuIEkgYW0gbm90IGZhbWlsaWFyIHdpdGggdGhlIGhpc3Rvcnkgb2YgdGhlIFJGQy4gIENvdWxk IHlvdSBoZWxwIGV4cGxhaW4gd2h5IE1QTFMgdHVubmVscyBhcmUgbm90IHRha2VuDQoNCmludG8g YWNjb3VudCBhdCB0aGF0IHRpbWUgb3IgbWF5YmUgTVBMUyB0dW5uZWxzIGFyZSBjb25zaWRlcmVk IGluIG90aGVyIGRyYWZ0cy9SRkNzPw0KDQoNCg0KDQoNClRoYW5rcyAmIFJlZ2FyZHMsDQoNClpo ZW5iaW4oUm9iaW4pDQoNCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0Kt6K8/sjLOiBJZHIgW2lkci1ib3VuY2VzQGlldGYub3JnXSC0+rHtIEtleXVyIFBhdGVsIChr ZXl1cGF0ZSkgW2tleXVwYXRlQGNpc2NvLmNvbV0NCreiy83KsbzkOiAyMDE1xOo21MIzMMjVIDI6 MTYNCsrVvP7IyzogaWRyQGlldGYub3JnDQrW98ziOiBbSWRyXSBkcmFmdC1yb3Nlbi10dW5uZWwt ZW5jYXBzLTAwLnR4dA0KDQpGb2xrcywNCg0KV2UgaGF2ZSBwb3N0ZWQgYSBuZXcgdHVubmVsIGVu Y2Fwc3VsYXRpb24gYXR0cmlidXRlIGRyYWZ0IGtub3duIGFzIGRyYWZ0LXJvc2VuLXR1bm5lbC1l bmNhcHMtMDAudHh0Lg0KDQpUaGlzIGRyYWZ0IGFkZHJlc3NlcyBhbGwgdGhlIGNvbmNlcm5zIGFu ZCBxdWVzdGlvbnMgdGhhdCB3ZXJlIHJhaXNlZCBkdXJpbmcgdGhlIFdHIGFjY2VwdGFuY2UgY2Fs bCBvZiBkcmFmdC12YW5kZXZlbGRlLWlkci1yZW1vdGUtbmV4dC1ob3AuDQoNClBsZWFzZSBwcm92 aWRlIGNvbW1lbnRzL3N1Z2dlc3Rpb25zLg0KDQpCZXN0IFJlZ2FyZHMsDQpLZXl1cg0KDQoNCmh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1yb3Nlbi1pZHItdHVubmVsLWVuY2Fwcy0w MA0KDQo= --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D8C9FF3F5nkgeml506mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Eric,

I think the draft is useful in many application scenarios. In fact, we h= ave proposed the draft draft-li-idr-mpls-path-programming-01 in which we al= so wanted to

introduce the tunnel attributes which can be applied to multiple BGP AFI= /SAFIs. According to our usecase, the tunnel considered in the draft are al= most MPLS tunnels.

According to my understanding, for the draft draft-rosen-tunnel-encaps-0= 0 I think the tunnel types defined here are almost IP tunnels used for data= center scenarios.

When I tracked to RFC 5512, it also only defined IP tunnels. I am n= ot familiar with the history of the RFC.  Could you help explain why M= PLS tunnels are not taken

into account at that time or maybe MPLS tunnels are considered in other = drafts/RFCs?

 

 

Thanks & Regards,

Zhenbin(Robin)

 

 

=B7=A2=BC=FE=C8=CB: Idr [idr-bounces@ietf.= org] =B4=FA=B1=ED Keyur Patel (keyupate) [keyupate@cisco.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2015=C4=EA6=D4=C230=C8=D5 2:16
=CA=D5=BC=FE=C8=CB: idr@ietf.org
=D6=F7=CC=E2: [Idr] draft-rosen-tunnel-encaps-00.txt

Folks,

We have posted a new tunnel encapsulation attribute draft known as dra= ft-rosen-tunnel-encaps-00.txt.  

This draft addresses all the concerns and questions that were raised d= uring the WG acceptance call of draft-vandevelde-idr-remote-next-hop.<= /div>

Please provide comments/suggestions.

Best Regards,
Keyur


https://tools.ietf.org/html/draft-rosen-idr-tunnel-encaps-00

--_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D8C9FF3F5nkgeml506mbxchi_-- From nobody Fri Jul 3 11:10: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 BBC421AD082 for ; Fri, 3 Jul 2015 11:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.74 X-Spam-Level: * X-Spam-Status: No, score=1.74 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, 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 ACh-nxBjZXqA for ; Fri, 3 Jul 2015 11:10:13 -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 B5E821AD071 for ; Fri, 3 Jul 2015 11:08:51 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BYH80865; Fri, 03 Jul 2015 18:08:50 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 3 Jul 2015 19:08:47 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.135]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Sat, 4 Jul 2015 02:08:42 +0800 From: Lizhenbin To: "Keyur Patel (keyupate)" , "erosen@juniper.net" , "gunter.van_de_velde@alcatel-lucent.com" Thread-Topic: draft-rosen-tunnel-encaps-00.txt Thread-Index: AQHQspeo/crwlAlUjU+qaPs2zIJpIp3KB35N Date: Fri, 3 Jul 2015 18:08:41 +0000 Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D8C9FF41D@nkgeml506-mbx.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.46.219.96] Content-Type: multipart/alternative; boundary="_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D8C9FF41Dnkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "idr@ietf.org" Subject: [Idr] =?gb2312?b?tPC4tDogZHJhZnQtcm9zZW4tdHVubmVsLWVuY2Fwcy0wMC50?= =?gb2312?b?eHQ=?= 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, 03 Jul 2015 18:10:14 -0000 --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D8C9FF41Dnkgeml506mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgQXV0aG9ycywNCg0KSSBoYXZlIGZvbGxvd2luZyBjb21tZW50cyByZWdhcmRpbmcgdGhlIGRy YWZ0Og0KDQoxLiBDYW4geW91IHByb3Bvc2Ugb25lIHNlY3Rpb24gdG8gaW50cm9kdWNlIHRoZSB1 c2VjYXNlcyBvciByZXF1aXJlbWVudHMgZm9yIHRoZXNlIEJHUCBleHRlbnNpb25zIHByb3Bvc2Vk IGJ5IHRoZSBkcmFmdD8NCg0KDQoNCjIuIEZvciB0aGUgUmVtb3RlIEVuZHBvaW50IFN1Yi1UTFYg aW4gU2VjdGlvbiAyLjEsIHdoeSBpcyB0aGUgQVMgbnVtYmVyIHN1Yi1maWVsZCBpcyBpbnRyb2R1 Y2VkPyBJIHRoaW5rIGluIG1vc3QgY2FzZXMgbWF5YmUgdGhlIEFTIG51bWJlciBpcyBub3QgbmVj ZXNzYXJ5Lg0KDQoNCg0KMy4gU2VjdGlvbiAyLjE6ICIgICBUaGVyZSBpcyBvbmUgc3BlY2lhbCBj YXNlOiB0aGUgUmVtb3RlIEVuZHBvaW50IHN1Yi1UTFYgTUFZIGhhdmUgYQ0KICAgdmFsdWUgZmll bGQgY29uc2lzdGluZyBlbnRpcmVseSBvZiB6ZXJvZXMuICBUaGlzIG1lYW5zIHRoYXQgdGhlDQog ICB0dW5uZWwncyByZW1vdGUgZW5kcG9pbnQgaXMgdGhlIFVQREFURSdzIEJHUCBuZXh0IGhvcC4i DQoNCkkgdGhpbmsgdGhlIHNwZWNpYWwgY2FzZSBtYXkgYmUganVzdCB0byB3YXN0ZSBwcm9jZXNz LiBDYW4gaXQgYmUgcmVtb3ZlZD8NCg0KDQoNCjQuIEZvciB0aGUgTVBMUy1pbi1HUkUgaW4gc2Vj dGlvbiAyLjIuNSwgdGhlIGRyYWZ0IGludHJvZHVjZWQgdGhhdCBpdCBpcyBlcXVpdmFsZW50IHRv ICBpbmNsdWRpbmcgYSBUTFYgb2YgdGhlIEdSRSB0dW5uZWwgdHlwZSB0aGF0DQogICBhbHNvIGlu Y2x1ZGVzIGEgUHJvdG9jb2wgVHlwZSBzdWItVExWIChbUkZDNTUxMl0pIHNwZWNpZnlpbmcgTVBM UyBhcyB0aGUgcHJvdG9jb2wgdG8gYmUgZW5jYXBzdWxhdGVkLiAgSSB0aGluayB0aGUgZXF1aXZh bGVuY2UgaXMgYmV0dGVyLg0KDQogICBXZSBzaG91bGQgbm90IGRlZmluZSB0dW5uZWwgdHlwZXMg Y29tYmluaW5nIHRoZSB0dW5uZWwgdHlwZXMgYW5kIHRoZSBwcm90b2NvbCB0eXBlcyBlbmNhcHN1 bGF0ZWQuIEl0IGlzIGFwcGFyZW50IHRoYXQgdGhlIE1QTFMtaW4tR1JFIHR1bm5lbCB0eXBlcw0K DQogICBkZWZpbml0aW9uIGlzIGRpZmZlcmVudCBmcm9tIG90aGVyIHR1bm5lbCB0eXBlcy4gQW5k IGJ5IGRlZmluaW5nIHR1bm5lbCB0eXBlcyBjb21iaW5pbmcgdGhlIHR1bm5lbCB0eXBlcyBhbmQg dGhlIHByb3RvY29sIHR5cGVzIGVuY2Fwc3VsYXRlZCwgaXQgbWF5IGludHJvZHVjZSBtb3JlDQoN CiAgIHR1bm5lbCB0eXBlcyB3aGljaCB3aWxsIHByb3Bvc2UgdW5uZWNlc3NhcnkgZGViYXRlcy4N Cg0KDQoNCjUuIFJlZ2FyZGluZyBJQU5BIENvbnNpZGVyYXRpb25zIGluIHNlY3Rpb24gMTAgIklB TkEgaXMgcmVxdWVzdGVkIHRvIGFkZCB0aGlzIGRvY3VtZW50IGFzIGEgcmVmZXJlbmNlIGZvciB0 dW5uZWwNCiAgIHR5cGVzIDgtMTMgaW4gdGhlICJCR1AgVHVubmVsIEVuY2Fwc3VsYXRpb24gVHVu bmVsIFR5cGVzIiByZWdpc3RyeS4iLCBpbiB0aGUgZHJhZnQgSSBoYXZlIG5vdCBzZWVuIHdoYXQg dHVubmVsIHR5cGVzIGRvIHRoZSBudW1iZXIgOC0xMyBpbmRpY2F0ZWQgaW4gdGhlIGRyYWZ0Lg0K DQogICBNYXliZSBJIG1pc3NlZCBzb21ldGhpbmcuDQoNCg0KDQoNCg0KQmVzdCBSZWdhcmRzLA0K DQpaaGVuYmluKFJvYmluKQ0KDQoNCg0KDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCreivP7IyzogSWRyIFtpZHItYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBLZXl1 ciBQYXRlbCAoa2V5dXBhdGUpIFtrZXl1cGF0ZUBjaXNjby5jb21dDQq3osvNyrG85DogMjAxNcTq NtTCMzDI1SAyOjE2DQrK1bz+yMs6IGlkckBpZXRmLm9yZw0K1vfM4jogW0lkcl0gZHJhZnQtcm9z ZW4tdHVubmVsLWVuY2Fwcy0wMC50eHQNCg0KRm9sa3MsDQoNCldlIGhhdmUgcG9zdGVkIGEgbmV3 IHR1bm5lbCBlbmNhcHN1bGF0aW9uIGF0dHJpYnV0ZSBkcmFmdCBrbm93biBhcyBkcmFmdC1yb3Nl bi10dW5uZWwtZW5jYXBzLTAwLnR4dC4NCg0KVGhpcyBkcmFmdCBhZGRyZXNzZXMgYWxsIHRoZSBj b25jZXJucyBhbmQgcXVlc3Rpb25zIHRoYXQgd2VyZSByYWlzZWQgZHVyaW5nIHRoZSBXRyBhY2Nl cHRhbmNlIGNhbGwgb2YgZHJhZnQtdmFuZGV2ZWxkZS1pZHItcmVtb3RlLW5leHQtaG9wLg0KDQpQ bGVhc2UgcHJvdmlkZSBjb21tZW50cy9zdWdnZXN0aW9ucy4NCg0KQmVzdCBSZWdhcmRzLA0KS2V5 dXINCg0KDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcm9zZW4taWRyLXR1bm5l bC1lbmNhcHMtMDANCg0K --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D8C9FF41Dnkgeml506mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Authors,

I have following comments regarding the draft:

1. Can you propose one section to introduce the usecases or requirements= for these BGP extensions proposed by the draft?

 

2. For the Remote Endpoint Sub-TLV in Section 2.1, why is the AS number = sub-field is introduced? I think in most cases maybe the AS number is not n= ecessary.

 

3. Section 2.1: "   There is one special case: the Remote= Endpoint sub-TLV MAY have a
   value field consisting entirely of zeroes.  This means th= at the
   tunnel's remote endpoint is the UPDATE's BGP next hop."

I think the special case may be just to waste process. Can it be re= moved?

 

4. For the MPLS-in-GRE in section 2.2.5, the draft introduced that = it is equivalent to  including a TLV of the GRE tunnel type that<= br>    also includes a Protocol Type sub-TLV ([RFC5512]) specifying M= PLS as the protocol to be encapsulated.  I think the&nb= sp;equivalence is better.

   We should not define tunnel types combining the tunnel= types and the protocol types encapsulated. It is apparent that the MPLS-in= -GRE tunnel types

   definition is different from other tunnel types. And by def= ining tunnel types combining the tunnel types and the protocol types encaps= ulated, it may introduce more

   tunnel types which will propose unnecessary debates.

 

5. Regarding IANA Considerations in section 10 "IANA is requested t= o add this document as a reference for tunnel
   types 8-13 in the "BGP Tunnel Encapsulation Tunnel Types&= quot; registry.", in the draft I have not seen what tunnel types do th= e number 8-13 indicated in the draft.

   Maybe I missed something.

 

 

Best Regards,

Zhenbin(Robin)





 

 

=B7=A2=BC=FE=C8=CB: Idr [idr-bounces@ietf.= org] =B4=FA=B1=ED Keyur Patel (keyupate) [keyupate@cisco.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2015=C4=EA6=D4=C230=C8=D5 2:16
=CA=D5=BC=FE=C8=CB: idr@ietf.org
=D6=F7=CC=E2: [Idr] draft-rosen-tunnel-encaps-00.txt

Folks,

We have posted a new tunnel encapsulation attribute draft known as dra= ft-rosen-tunnel-encaps-00.txt.  

This draft addresses all the concerns and questions that were raised d= uring the WG acceptance call of draft-vandevelde-idr-remote-next-hop.<= /div>

Please provide comments/suggestions.

Best Regards,
Keyur


https://tools.ietf.org/html/draft-rosen-idr-tunnel-encaps-00

--_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D8C9FF41Dnkgeml506mbxchi_-- From nobody Fri Jul 3 17:19: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 CCC1E1A913B for ; Fri, 3 Jul 2015 17:19:31 -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 T258EiElyI3T for ; Fri, 3 Jul 2015 17:19:30 -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 2AD541A9136 for ; Fri, 3 Jul 2015 17:19:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2674; q=dns/txt; s=iport; t=1435969170; x=1437178770; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=tcGoHoK159InFPWHPEyTCIyF0KefBMxKJNLldjNPpFU=; b=GTwR+wT41khoC5ZLWW/CZr8KPBZX9Bb/+d9k8/KzT+eRzC0GTAfxDAfA 1KO+i1v2+K1kRd4NLCmg+3Ef6fSg2WBguw45zTubfLT/N92akpf8zUwPr /RKYQg5wLz7y7NCLIvr41InWIgy9LJiP5Ofj7sNTC7ZFd1W95sCA3wBDh 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AABQCdJZdV/4UNJK1bgxJUYAa/LwqFdwKBLTsRAQEBAQEBAYEKhCQBAQMBAQEBawYFBQsCAQhGJwslAQEEAQ0FG4gMCA3KcwEBAQEBAQEBAQEBAQEBAQEBAQEBARMEi0uENAEBBRgzB4MXgRQFkTGCZAGHOoQtgTqEFYMPjBuDXSaDe2+BDTqBBAEBAQ X-IronPort-AV: E=Sophos;i="5.15,403,1432598400"; d="scan'208";a="8796365" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-6.cisco.com with ESMTP; 04 Jul 2015 00:19:29 +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 t640JTt8026072 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 4 Jul 2015 00:19:29 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.112]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Fri, 3 Jul 2015 19:19:28 -0500 From: "Jerome Durand (jerduran)" To: "idr@ietf.org" , Susan Hares Thread-Topic: [Idr] draft-jdurand-auto-bfd-00 Thread-Index: AdCyhNrQT6K0GX6ITHiyQ7RgDJ0QsQDlCRWA Date: Sat, 4 Jul 2015 00:19:28 +0000 Message-ID: <55490D92-7506-42C4-B279-430D7F18C89A@cisco.com> References: <00a901d0b285$b6637430$232a5c90$@ndzh.com> In-Reply-To: <00a901d0b285$b6637430$232a5c90$@ndzh.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.82.71] Content-Type: text/plain; charset="Windows-1252" Content-ID: <0A0F52772683A745B4F539C6F97908A5@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: David Freedman Subject: Re: [Idr] draft-jdurand-auto-bfd-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: Sat, 04 Jul 2015 00:19:32 -0000 Hi all, > Acee and Jeff Haas find this to be a useful solution to consider for FRR = and BGP. Thanks a lot for the discussion during the call it was interesting. > At the interim, it was suggested it would be useful for you to discuss on= the mail list: > =B7 The differences between (draft-ietf-idrrs-bfd/draft-ymk-idr-b= fd) with your draft on the mail list? The main difference I believe is that draft-jdurand-auto-bfd-00 targets a s= olution without any requirement on the IXP route server. As the goal is to = have a way to react when there are problems on an IXP we thought it was bet= ter not to rely on anything from the IXP, and give IXP members full capabil= ity to detect issues and implement solutions on their own. Very briefly (I=92ll let author give more info), draft-ietf-idr-rs-bfd uses= BGP NH-SAFI on RS and client routers to share information of all client ro= uters. Client routers then know about eachothers and setup BFD sessions to = test their mutual reachability. Results of the tests are sent to RS (again = using NH-SAFI). Policy can be applied on RS. draft-jdurand-auto-bfd proposes that members simply setup BFD sessions with= all BGP next-hops seen through the RS, and implement policy for received r= outes based on BFD session state. No requirement on the IXP. IXP members ar= e autonomous. The 2 drafts are quite short and I=92d encourage people interested to read = in order to see the other differences. > =B7 Any conflict between protection a BGP session at an IXP and p= rotecting the connectivity of a prefix? Well at this stage I don=92t see any conflict but I haven=92t spent much ti= me studying this. I=92m happy to hear from the group. > =B7 Any way this proposed standard changes BFD. As we don=92t want to keep BFD sessions forever in case we don=92t need the= m anymore we spent quite some time studying session ageing. If member A doe= s not receive routes from B (via RS), it would desire to stop BFD session. = But we cannot do that if for some reason B receives routes from A (B would = still need the BFD session with A). We propose to use BFD.Localdiag to sign= al interest in continuing BFD. Feedback from BFD people welcome here. Please give us feedback! > I=92m sure I missed a few other valuable questions, but there seems to be= real interest in you leading a discussion on this point. You can lead th= is discussion on this thread or on the WG Adoption thread. > =20 > Sue > =20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Sat Jul 4 03:42:49 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 C4B4F1ACEEC for ; Sat, 4 Jul 2015 03:42:47 -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 rK-ILggw_eEP for ; Sat, 4 Jul 2015 03:42:45 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (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 468C11ACEEF for ; Sat, 4 Jul 2015 03:42:41 -0700 (PDT) Received: by wiga1 with SMTP id a1so193983580wig.0 for ; Sat, 04 Jul 2015 03:42:40 -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=q5Ugev9up2zTbZjEeWtb6bnLUdZ9YffpbhejIhQ6OH0=; b=nKMoBGxb/crLT/7PZSJ4q1fxWttfNaYmHv3FgIPgxh5NHMZLbxJjpDLMDmqEMFRg7n WdvjHP2s4bRYfx7OQXptxBloyfK5z0CGlZ2PWPpaiLDVsErpwngr0NRtNhIxEbjCYEsE vRUpOGCQPQPcuee0SXRPMBxcMOC8OE9SDSybYxRKnCUlipFwNi1xIDMGBMcxjNipoFMo 8s1wE5QmSZubi/5sa2R/Q56NQgYM822SUXLrqlI91Qh2nNFUAGDsJSNV4/Bg/sFAvHds j8Qr5zpdp2+kXqHfSATLrCld/EQernDIo2DVaEqM7gfGdg2/5nOw27aaj1fkM6XYyaHv r/YA== MIME-Version: 1.0 X-Received: by 10.194.187.51 with SMTP id fp19mr71936805wjc.67.1436006560029; Sat, 04 Jul 2015 03:42:40 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.28.45.88 with HTTP; Sat, 4 Jul 2015 03:42:39 -0700 (PDT) In-Reply-To: <55490D92-7506-42C4-B279-430D7F18C89A@cisco.com> References: <00a901d0b285$b6637430$232a5c90$@ndzh.com> <55490D92-7506-42C4-B279-430D7F18C89A@cisco.com> Date: Sat, 4 Jul 2015 12:42:39 +0200 X-Google-Sender-Auth: U5Ax039E8tRFODrGPOJlm8XQjHo Message-ID: From: Robert Raszuk To: "Jerome Durand (jerduran)" Content-Type: multipart/alternative; boundary=047d7bb03dcee7e23e051a0a542c Archived-At: Cc: "idr@ietf.org" , David Freedman , Susan Hares Subject: Re: [Idr] draft-jdurand-auto-bfd-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: Sat, 04 Jul 2015 10:42:47 -0000 --047d7bb03dcee7e23e051a0a542c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello Jerome, I read your draft and I would like to express strong support for it. In fact I can see number of use cases completely outside of IX space too. Three minor comments: 1. "routers can automatically try to establish a new adjacency for every new BGP next-hop." Comment: Imagine that you are receiving 10 or 20 paths for a given net (obviously each with different next hop). Does it make sense to establish BFD session to all of those next hops if you are not doing ECMP load balancing actively to all of them ? Perhaps a comment in the draft on that would be helpful. 2. "If next-hops for the remote system are no longer being received, the following occurs:" Comment: I am a bit not clear on your notion of next hops being received or not being received. If you have session established you have updates and withdraws. If you received the update most likely (well except some new SAFIs which do not enforce next hop) you also get next hops. If you get withdraw you remove them. So to me the new flag "Continuing Auto-BFD" is really not needed and could be just removed or if needed (which I doubt) replaced by a simple timer saying that after last withdraw for a given NH you bring BFD down in X sec. That would also allow to move the draft to informational status and perhaps progress is faster :) 3. In case you have an implementation which already supports today establishing a session to BGP peering address perhaps a deployment consideration could be added to discuss the recommended prefernece .. ie. show advantage to have a session to next hops if for example GR is enabled. In any case great idea and I would say it is one of those low hanging fruits :) Cheers, R. On Sat, Jul 4, 2015 at 2:19 AM, Jerome Durand (jerduran) wrote: > Hi all, > > > Acee and Jeff Haas find this to be a useful solution to consider for FR= R > and BGP. > > Thanks a lot for the discussion during the call it was interesting. > > > At the interim, it was suggested it would be useful for you to discuss > on the mail list: > > =C2=B7 The differences between > (draft-ietf-idrrs-bfd/draft-ymk-idr-bfd) with your draft on the mail list= ? > > The main difference I believe is that draft-jdurand-auto-bfd-00 targets a > solution without any requirement on the IXP route server. As the goal is = to > have a way to react when there are problems on an IXP we thought it was > better not to rely on anything from the IXP, and give IXP members full > capability to detect issues and implement solutions on their own. > > Very briefly (I=E2=80=99ll let author give more info), draft-ietf-idr-rs-= bfd uses > BGP NH-SAFI on RS and client routers to share information of all client > routers. Client routers then know about eachothers and setup BFD sessions > to test their mutual reachability. Results of the tests are sent to RS > (again using NH-SAFI). Policy can be applied on RS. > > draft-jdurand-auto-bfd proposes that members simply setup BFD sessions > with all BGP next-hops seen through the RS, and implement policy for > received routes based on BFD session state. No requirement on the IXP. IX= P > members are autonomous. > > The 2 drafts are quite short and I=E2=80=99d encourage people interested = to read > in order to see the other differences. > > > =C2=B7 Any conflict between protection a BGP session at an IXP = and > protecting the connectivity of a prefix? > > Well at this stage I don=E2=80=99t see any conflict but I haven=E2=80=99t= spent much time > studying this. I=E2=80=99m happy to hear from the group. > > > =C2=B7 Any way this proposed standard changes BFD. > > As we don=E2=80=99t want to keep BFD sessions forever in case we don=E2= =80=99t need them > anymore we spent quite some time studying session ageing. If member A doe= s > not receive routes from B (via RS), it would desire to stop BFD session. > But we cannot do that if for some reason B receives routes from A (B woul= d > still need the BFD session with A). We propose to use BFD.Localdiag to > signal interest in continuing BFD. Feedback from BFD people welcome here. > > Please give us feedback! > > > > > > I=E2=80=99m sure I missed a few other valuable questions, but there see= ms to be > real interest in you leading a discussion on this point. You can lead > this discussion on this thread or on the WG Adoption thread. > > > > Sue > > > > _______________________________________________ > > 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 > --047d7bb03dcee7e23e051a0a542c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Jerome,
<= br>
I read your draft and I would like to express s= trong support for it.=C2=A0

In fact I can see number of use cases completely outside of IX space = too.

Three minor com= ments:

1.=C2=A0
<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ;font-size:small">
"routers can automatica= lly try to establish a new adjacency
for every new BGP next-hop."

Comment: Imagine that yo= u are receiving 10 or 20 paths for a given net (obviously each with differe= nt next hop). Does it make sense to establish BFD session to all of those n= ext hops if you are not doing ECMP load balancing actively to all of them ?= Perhaps a comment in the draft on that would be helpful.=C2=A0

2.=C2=A0

"If next-hops for the remote system are no long= er being received,
the following occurs:&= quot;


Comment: I am a bit not clear on= your notion of next hops being received or not being received. If you have= session established you have updates and withdraws. If you received the up= date most likely (well except some new SAFIs which do not enforce next hop)= you also get next hops. If you get withdraw you remove them.=C2=A0

So to me = the new flag =C2=A0"Continuing Auto-BFD" is really not needed and= could be just removed or if needed (which I doubt) replaced by a simple ti= mer saying that after last withdraw for a given NH you bring BFD down in X = sec. That would also allow to move the draft to informational status and pe= rhaps progress is faster :)=C2=A0

3.=C2=A0
=
In case you have an implementation w= hich already supports today establishing a session to BGP peering address p= erhaps a deployment consideration could be added to discuss the recommended= prefernece .. ie. show advantage to have a session to next hops if for exa= mple GR is enabled.=C2=A0


In any case = great idea and I would say it is one of those low hanging fruits :)=C2=A0

Che= ers,
R.

On Sat, Jul 4, 2015 at 2:19 AM, Jerome Durand (jerduran) <= span dir=3D"ltr"><jerduran@cisco.com> wrote:

> Acee and Jeff Haas find this to be a useful solution to consider for F= RR and BGP.

Thanks a lot for the discussion during the call it was interesting.<= br>
> At the interim, it was suggested it would be useful for you to discuss= on the mail list:
> =C2=B7=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The differences between (draft= -ietf-idrrs-bfd/draft-ymk-idr-bfd) with your draft on the mail list?

The main difference I believe is that draft-jdurand-auto-bfd-00 targ= ets a solution without any requirement on the IXP route server. As the goal= is to have a way to react when there are problems on an IXP we thought it = was better not to rely on anything from the IXP, and give IXP members full = capability to detect issues and implement solutions on their own.

Very briefly (I=E2=80=99ll let author give more info), draft-ietf-idr-rs-bf= d uses BGP NH-SAFI on RS and client routers to share information of all cli= ent routers. Client routers then know about eachothers and setup BFD sessio= ns to test their mutual reachability. Results of the tests are sent to RS (= again using NH-SAFI). Policy can be applied on RS.

draft-jdurand-auto-bfd proposes that members simply setup BFD sessions with= all BGP next-hops seen through the RS, and implement policy for received r= outes based on BFD session state. No requirement on the IXP. IXP members ar= e autonomous.

The 2 drafts are quite short and I=E2=80=99d encourage people interested to= read in order to see the other differences.

> =C2=B7=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Any conflict between protectio= n a BGP session at an IXP and protecting the connectivity of a prefix?

Well at this stage I don=E2=80=99t see any conflict but I haven=E2=80=99t s= pent much time studying this. I=E2=80=99m happy to hear from the group.

> =C2=B7=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Any way this proposed standard= changes BFD.

As we don=E2=80=99t want to keep BFD sessions forever in case we don=E2=80= =99t need them anymore we spent quite some time studying session ageing. If= member A does not receive routes from B (via RS), it would desire to stop = BFD session. But we cannot do that if for some reason B receives routes fro= m A (B would still need the BFD session with A). We propose to use BFD.Loca= ldiag to signal interest in continuing BFD. Feedback from BFD people welcom= e here.

Please give us feedback!




> I=E2=80=99m sure I missed a few other valuable questions, but there se= ems to be real interest in you leading a discussion on this point.=C2=A0 = =C2=A0You can lead this discussion on this thread or on the WG Adoption thr= ead.
>
> Sue
>
> _______________________________________________
> 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

--047d7bb03dcee7e23e051a0a542c-- From nobody Sat Jul 4 04:14: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 25EFE1A1A96 for ; Sat, 4 Jul 2015 04:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 ceiKqtQSa3cM for ; Sat, 4 Jul 2015 04:14:28 -0700 (PDT) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.107]) by ietfa.amsl.com (Postfix) with ESMTP id E84F61A1A6A for ; Sat, 4 Jul 2015 04:14:27 -0700 (PDT) Received: from [193.109.255.99] by server-3.bemta-14.messagelabs.com id 99/E3-18676-110C7955; Sat, 04 Jul 2015 11:14:25 +0000 X-Env-Sender: david.freedman@uk.clara.net X-Msg-Ref: server-12.tower-48.messagelabs.com!1436008465!15939157!1 X-Originating-IP: [80.168.41.244] X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32006 invoked from network); 4 Jul 2015 11:14:25 -0000 Received: from staff02.mail.eu.clara.net (HELO staff02.mail.eu.clara.net) (80.168.41.244) by server-12.tower-48.messagelabs.com with SMTP; 4 Jul 2015 11:14:25 -0000 Received: from [80.168.41.252] (port=60130 helo=SRVGREXCAS02.claranet.local) by staff02.mail.eu.clara.net (staff02.mail.eu.clara.net [80.168.41.244]:25) with esmtps (TLS-1.0:RSA_AES_128_CBC_SHA1:16) id 1ZBLOr-00011Y-7M (return-path ); Sat, 04 Jul 2015 11:14:25 +0000 Received: from SRVGREXMB01.claranet.local ([fe80::64bc:5d10:5203:a830]) by SRVGREXCAS02.claranet.local ([::1]) with mapi id 14.03.0235.001; Sat, 4 Jul 2015 12:11:59 +0100 From: David Freedman To: Robert Raszuk , "Jerome Durand (jerduran)" Thread-Topic: [Idr] draft-jdurand-auto-bfd-00 Thread-Index: AdCyhNrQT6K0GX6ITHiyQ7RgDJ0QsQDlCRWAAAkxMYAAAyDKgA== Date: Sat, 4 Jul 2015 11:11:58 +0000 Message-ID: References: <00a901d0b285$b6637430$232a5c90$@ndzh.com> <55490D92-7506-42C4-B279-430D7F18C89A@cisco.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.150618 x-originating-ip: [172.26.6.254] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "idr@ietf.org" , Susan Hares Subject: Re: [Idr] draft-jdurand-auto-bfd-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: Sat, 04 Jul 2015 11:14:30 -0000 SGkgDQoNCj5Db21tZW50OiBJIGFtIGEgYml0IG5vdCBjbGVhciBvbiB5b3VyIG5vdGlvbiBvZiBu ZXh0IGhvcHMgYmVpbmcgcmVjZWl2ZWQgb3Igbm90IGJlaW5nIHJlY2VpdmVkLiBJZiB5b3UgaGF2 ZSBzZXNzaW9uIGVzdGFibGlzaGVkIHlvdSBoYXZlIHVwZGF0ZXMgYW5kIHdpdGhkcmF3cy4gSWYg PnlvdSByZWNlaXZlZCB0aGUgdXBkYXRlIG1vc3QgbGlrZWx5ICh3ZWxsIGV4Y2VwdCBzb21lIG5l dyBTQUZJcyB3aGljaCBkbyBub3QgZW5mb3JjZSBuZXh0IGhvcCkgeW91IGFsc28gZ2V0IG5leHQg aG9wcy4gSWYgeW91IGdldCB3aXRoZHJhdyB5b3UgcmVtb3ZlIHRoZW0uDQo+U28gdG8gbWUgdGhl IG5ldyBmbGFnICAiQ29udGludWluZyBBdXRvLUJGRCIgaXMgcmVhbGx5IG5vdCBuZWVkZWQgYW5k IGNvdWxkIGJlIGp1c3QgcmVtb3ZlZCBvciBpZiBuZWVkZWQgKHdoaWNoIEkgZG91YnQpIHJlcGxh Y2VkIGJ5IGEgc2ltcGxlIHRpbWVyIHNheWluZyB0aGF0IGFmdGVyID5sYXN0IHdpdGhkcmF3IGZv ciBhIGdpdmVuIE5IIHlvdSBicmluZyBCRkQgZG93biBpbiBYIHNlYy4gVGhhdCB3b3VsZCBhbHNv IGFsbG93IHRvIG1vdmUgdGhlIGRyYWZ0IHRvIGluZm9ybWF0aW9uYWwgc3RhdHVzIGFuZCBwZXJo YXBzIHByb2dyZXNzIGlzIGZhc3RlciA6KQ0KDQpXZWxsLCB0aGlzIHdhcyBkZXNpZ25lZCB0byBh ZGRyZXNzIHRoZSBwcm9ibGVtIG9mIGFzeW1tZXRyeSAoSS5lLCB0byBtYWtlIHRoZSBCRkQgc3lt bWV0cmljKSwgaW4gdGhlIGNhc2UgdGhhdCB3ZSBubyBsb25nZXIgc2VlIHByZWZpeGVzIGF0dGFj aGVkIHRvIGEgbmV4dCBob3AgKGkuZSwgYW5vdGhlciBJWFAgcGFydGljaXBhbnQpLCB3ZSBtYXkg c3RpbGwgYmUgYWR2ZXJ0aXNpbmcgcHJlZml4ZXMgd2l0aCBvdXJzZWx2ZXMgYXMgYSBuZXh0IGhv cCAoaS5lLCB0aHJvdWdoIHRoZSBSUywgdG8gdGhlbSkgYW5kIG1heSB3YW50IHRvIGtlZXAgdGhl IHNlc3Npb24gZnJvbSBiZWluZyB0b3JuIGRvd24gYmV0d2VlbiB0aGUgcGFpciBvZiB1cyBhcyBh IHJlc3VsdC4gVGhlIGZsYWcgaXMgdGhlcmUgcmVhbGx5IGZvciB0aGUgcGFydG5lciB0byBsZXQg dXMga25vdyB0aGF0IGl0IGlzIHN0aWxsIHNlZWluZyByb3V0ZXMgZnJvbSB1cyAoc2luY2Ugd2Ug aGF2ZSBubyBpZGVhIHdoZXJlIHRoZXkgYXJlIGJlaW5nIHNlbnQpLCBhbmQgdGhhdCB3ZSBzaG91 bGQgbm90IHBydW5lIHRoZSBzZXNzaW9uIGJldHdlZW4gdXMsIHNpbXBseSBiZWNhdXNlIHdlIHNl ZSBubyByb3V0ZXMgZnJvbSBoaW0uICANCiANCkRhdmUuDQoNCg0KDQoNCg0K From nobody Sat Jul 4 16:30:49 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 AC28A1A894A for ; Sat, 4 Jul 2015 16:30:47 -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 abkYDXDtRg4y for ; Sat, 4 Jul 2015 16:30:46 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D81C1A8946 for ; Sat, 4 Jul 2015 16:30:46 -0700 (PDT) Received: by wgck11 with SMTP id k11so112744030wgc.0 for ; Sat, 04 Jul 2015 16:30:44 -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=ht1+eHexIkwqzCm1CUwoM9WTURx6NzIqj5wmZNb1dYo=; b=t1c1quggXTPLfU98wQDPFzXg5pSH4/3TXmzZAOc4ClFSrCx0DbzrtqKeqYW6zU2yE4 KbsQVeJss746z/bwH/JvqQYV4gAXLGz0GIdOKXMQHXaGH5AazHl/eAGN3tr1BRG9Ax1p B4cOW8X02BSeT9IU198rD+gmiXUFP3XSdbCUVOToYtXRRD2HFgTIhDP6PlEGQ0X0MVPp cPwZhsWgOStW7Wewun0OJUWKAgrIPdPMuXiEETSmHgoQrFnO8wf8kRzERCBExFFQ7xgT gOkj6fcrs6m0Y/n+9P6+/IFVL8GtHnBqYkSSZ6i6MDwMC7pDu+7YJj2mtbyPzpQhnNK5 KYLg== MIME-Version: 1.0 X-Received: by 10.180.75.15 with SMTP id y15mr72043692wiv.51.1436052644914; Sat, 04 Jul 2015 16:30:44 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.28.45.88 with HTTP; Sat, 4 Jul 2015 16:30:44 -0700 (PDT) In-Reply-To: References: <00a901d0b285$b6637430$232a5c90$@ndzh.com> <55490D92-7506-42C4-B279-430D7F18C89A@cisco.com> Date: Sun, 5 Jul 2015 01:30:44 +0200 X-Google-Sender-Auth: 34qWIkJdmouOAC-GWoByTLhmHi0 Message-ID: From: Robert Raszuk To: David Freedman Content-Type: multipart/alternative; boundary=bcaec54fb2c4c769c4051a150f57 Archived-At: Cc: "idr@ietf.org" , Susan Hares Subject: Re: [Idr] draft-jdurand-auto-bfd-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: Sat, 04 Jul 2015 23:30:47 -0000 --bcaec54fb2c4c769c4051a150f57 Content-Type: text/plain; charset=UTF-8 Hi David, Why do you need full BFD for auto-bfd as opposed to utilize S-BFD (Seamless BFD) which is effectively unidirectional ? Thx, R. On Saturday, July 4, 2015, David Freedman wrote: > Hi > > >Comment: I am a bit not clear on your notion of next hops being received > or not being received. If you have session established you have updates and > withdraws. If >you received the update most likely (well except some new > SAFIs which do not enforce next hop) you also get next hops. If you get > withdraw you remove them. > >So to me the new flag "Continuing Auto-BFD" is really not needed and > could be just removed or if needed (which I doubt) replaced by a simple > timer saying that after >last withdraw for a given NH you bring BFD down in > X sec. That would also allow to move the draft to informational status and > perhaps progress is faster :) > > Well, this was designed to address the problem of asymmetry (I.e, to make > the BFD symmetric), in the case that we no longer see prefixes attached to > a next hop (i.e, another IXP participant), we may still be advertising > prefixes with ourselves as a next hop (i.e, through the RS, to them) and > may want to keep the session from being torn down between the pair of us as > a result. The flag is there really for the partner to let us know that it > is still seeing routes from us (since we have no idea where they are being > sent), and that we should not prune the session between us, simply because > we see no routes from him. > > Dave. > > > > > > --bcaec54fb2c4c769c4051a150f57 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi David,

Why do you need full BFD for auto-bfd=C2=A0as = opposed to utilize S-BFD (Seamless BFD)=C2=A0which is effectively unidirect= ional ?

Thx,
R.

On Saturday, July= 4, 2015, David Freedman <david.freedman@uk.clara.net> wrote:
Hi

>Comment: I am a bit not clear on your notion of next hops being receive= d or not being received. If you have session established you have updates a= nd withdraws. If >you received the update most likely (well except some = new SAFIs which do not enforce next hop) you also get next hops. If you get= withdraw you remove them.
>So to me the new flag=C2=A0 "Continuing Auto-BFD" is really n= ot needed and could be just removed or if needed (which I doubt) replaced b= y a simple timer saying that after >last withdraw for a given NH you bri= ng BFD down in X sec. That would also allow to move the draft to informatio= nal status and perhaps progress is faster :)

Well, this was designed to address the problem of asymmetry (I.e, to make t= he BFD symmetric), in the case that we no longer see prefixes attached to a= next hop (i.e, another IXP participant), we may still be advertising prefi= xes with ourselves as a next hop (i.e, through the RS, to them) and may wan= t to keep the session from being torn down between the pair of us as a resu= lt. The flag is there really for the partner to let us know that it is stil= l seeing routes from us (since we have no idea where they are being sent), = and that we should not prune the session between us, simply because we see = no routes from him.

Dave.





--bcaec54fb2c4c769c4051a150f57-- From nobody Sat Jul 4 16:58:59 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 E2AF51A9073 for ; Sat, 4 Jul 2015 16:58:57 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 aZ3GSSaJOS9r for ; Sat, 4 Jul 2015 16:58:56 -0700 (PDT) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.119]) by ietfa.amsl.com (Postfix) with ESMTP id 236B41A9072 for ; Sat, 4 Jul 2015 16:58:55 -0700 (PDT) Received: from [193.109.254.3] by server-15.bemta-14.messagelabs.com id 72/E2-18947-E3378955; Sat, 04 Jul 2015 23:58:54 +0000 X-Env-Sender: david.freedman@uk.clara.net X-Msg-Ref: server-16.tower-184.messagelabs.com!1436054334!15089413!1 X-Originating-IP: [80.168.41.244] X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9984 invoked from network); 4 Jul 2015 23:58:54 -0000 Received: from staff02.mail.eu.clara.net (HELO staff02.mail.eu.clara.net) (80.168.41.244) by server-16.tower-184.messagelabs.com with SMTP; 4 Jul 2015 23:58:54 -0000 Received: from [80.168.41.252] (port=52562 helo=SRVGREXCAS02.claranet.local) by staff02.mail.eu.clara.net (staff02.mail.eu.clara.net [80.168.41.244]:25) with esmtps (TLS-1.0:RSA_AES_128_CBC_SHA1:16) id 1ZBXKg-0005tv-6u (return-path ); Sat, 04 Jul 2015 23:58:54 +0000 Received: from SRVGREXMB01.claranet.local ([fe80::64bc:5d10:5203:a830]) by SRVGREXCAS02.claranet.local ([::1]) with mapi id 14.03.0235.001; Sun, 5 Jul 2015 00:56:41 +0100 From: David Freedman To: Robert Raszuk Thread-Topic: [Idr] draft-jdurand-auto-bfd-00 Thread-Index: AdCyhNrQT6K0GX6ITHiyQ7RgDJ0QsQDlCRWAAAkxMYAAAyDKgAAXsmoAAAMC1oA= Date: Sat, 4 Jul 2015 23:56:40 +0000 Message-ID: References: <00a901d0b285$b6637430$232a5c90$@ndzh.com> <55490D92-7506-42C4-B279-430D7F18C89A@cisco.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.150618 x-originating-ip: [172.26.6.254] Content-Type: multipart/alternative; boundary="_000_A7D16C0ED97D48B6926A56D66A1CEF5Eukclaranet_" MIME-Version: 1.0 Archived-At: Cc: "idr@ietf.org" , Susan Hares Subject: Re: [Idr] draft-jdurand-auto-bfd-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: Sat, 04 Jul 2015 23:58:58 -0000 --_000_A7D16C0ED97D48B6926A56D66A1CEF5Eukclaranet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PldoeSAgZG8geW91IG5lZWQgZnVsbCBCRkQgZm9yIGF1dG8tYmZkIGFzIG9wcG9zZWQgdG8gdXRp bGl6ZSBTLUJGRCAoU2VhbWxlc3MgQkZEKSB3aGljaCBpcyBlZmZlY3RpdmVseSB1bmlkaXJlY3Rp b25hbCA/DQoNCldlIGRvbid0IChuZWVkIHRoaXMpIGF0IGFsbCwgYnV0IGF1dG8tYmZkIHdhcyBu b3Qgd3JpdHRlbiB3aXRoIHNlYW1sZXNzIEJGRCBpbiBtaW5kIChzaW5jZSBjbGFzc2ljYWwgQkZE IGlzIHdoYXQgaXMgb3V0IGluIHRoZSBmaWVsZCBub3cpLA0KYnV0IEkgdGFrZSB5b3VyIHBvaW50 LCBwZXJoYXBzIHdlIHNob3VsZCBpbmNsdWRlIHRoZSBjYXNlIHdoZXJlIFMtQkZEIHdpbGwgYmUg dXNlZCwgaW4gc3VjaCBjYXNlLCBvZiBjb3Vyc2UsIHRoZSBmbGFnIGNhbg0KYmUgZGlzcGVuc2Vk IHdpdGguDQoNCkRhdmUuDQo= --_000_A7D16C0ED97D48B6926A56D66A1CEF5Eukclaranet_ Content-Type: text/html; charset="utf-8" Content-ID: <8797B7C4BD4E6647900D210D78EBC7E4@claranet.local> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+Jmd0 O1doeSAmbmJzcDtkbyB5b3UgbmVlZCBmdWxsIEJGRCBmb3IgYXV0by1iZmQmbmJzcDthcyBvcHBv c2VkIHRvIHV0aWxpemUgUy1CRkQgKFNlYW1sZXNzIEJGRCkmbmJzcDt3aGljaCBpcyBlZmZlY3Rp dmVseSB1bmlkaXJlY3Rpb25hbCA/PC9kaXY+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8 c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdj4NCjxkaXY+V2UgZG9uJ3QgKG5l ZWQgdGhpcykgYXQgYWxsLCBidXQgYXV0by1iZmQgd2FzIG5vdCB3cml0dGVuIHdpdGggc2VhbWxl c3MgQkZEIGluIG1pbmQgKHNpbmNlIGNsYXNzaWNhbCBCRkQgaXMgd2hhdCBpcyBvdXQgaW4gdGhl IGZpZWxkIG5vdyksDQo8L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPg0KPGRpdj5idXQgSSB0YWtlIHlv dXIgcG9pbnQsIHBlcmhhcHMgd2Ugc2hvdWxkIGluY2x1ZGUgdGhlIGNhc2Ugd2hlcmUgUy1CRkQg d2lsbCBiZSB1c2VkLCBpbiBzdWNoIGNhc2UsIG9mIGNvdXJzZSwgdGhlIGZsYWcgY2FuJm5ic3A7 PC9kaXY+DQo8ZGl2PmJlIGRpc3BlbnNlZCB3aXRoLiZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8 L2Rpdj4NCjxkaXY+RGF2ZS48L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_A7D16C0ED97D48B6926A56D66A1CEF5Eukclaranet_-- From nobody Sun Jul 5 05:26: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 92D3E1A1BF4; Sun, 5 Jul 2015 05:26:40 -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 sNIe53KJMtWx; Sun, 5 Jul 2015 05:26:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 52B441A1EF6; Sun, 5 Jul 2015 05:26:38 -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.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150705122638.1407.6424.idtracker@ietfa.amsl.com> Date: Sun, 05 Jul 2015 05:26:38 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-sriram-idr-route-leak-detection-mitigation-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2015 12:26:40 -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 : Methods for Detection and Mitigation of BGP Route Leaks Authors : Kotikalapudi Sriram Doug Montgomery Brian Dickson Filename : draft-sriram-idr-route-leak-detection-mitigation-01.txt Pages : 17 Date : 2015-07-05 Abstract: In [I-D.ietf-grow-route-leak-problem-definition], the authors have provided a definition of the route leak problem, and also enumerated several types of route leaks. In this document, we first examine which of those route-leak types are detected and mitigated by the existing origin validation (OV) [RFC 6811] and BGPSEC path validation [I-D.ietf-sidr-bgpsec-protocol]. Where the current OV and BGPSEC protocols don't offer a solution, this document suggests an enhancement that would extend the route-leak detection and mitigation capability of BGPSEC. The solution can be implemented in BGP without necessarily tying it to BGPSEC. Incorporating the solution in BGPSEC is one way of implementing it in a secure way. We do not claim to have provided a solution for all possible types of route leaks, but the solution covers several, especially considering some significant route-leak attacks or occurrences that have been observed in recent years. The document also includes a stopgap method for detection and mitigation of route leaks for the phase when BGPSEC (path validation) is not yet deployed but only origin validation is deployed. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-sriram-idr-route-leak-detection-mitigation/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-sriram-idr-route-leak-detection-mitigation-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-sriram-idr-route-leak-detection-mitigation-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jul 5 06: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 0C16D1A88C8 for ; Sun, 5 Jul 2015 06:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d7ODdHoY9pTv for ; Sun, 5 Jul 2015 06:39:03 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0793.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:793]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5458A1A88C6 for ; Sun, 5 Jul 2015 06:39:03 -0700 (PDT) Received: from CY1PR09MB0793.namprd09.prod.outlook.com (10.163.43.143) by CY1PR09MB0793.namprd09.prod.outlook.com (10.163.43.143) with Microsoft SMTP Server (TLS) id 15.1.207.19; Sun, 5 Jul 2015 13:38:44 +0000 Received: from CY1PR09MB0793.namprd09.prod.outlook.com ([10.163.43.143]) by CY1PR09MB0793.namprd09.prod.outlook.com ([10.163.43.143]) with mapi id 15.01.0207.004; Sun, 5 Jul 2015 13:38:44 +0000 From: "Sriram, Kotikalapudi" To: "idr@ietf.org wg" Thread-Topic: New Version Notification for draft-sriram-idr-route-leak-detection-mitigation-01 Thread-Index: AQHQtyfpDU8TLSohskOiYmZoVpjb0Q== Date: Sun, 5 Jul 2015 13:38:44 +0000 Message-ID: References: <20150705122638.1407.91341.idtracker@ietfa.amsl.com> In-Reply-To: <20150705122638.1407.91341.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ndzh.com; dkim=none (message not signed) header.d=none; x-originating-ip: [129.6.218.169] x-microsoft-exchange-diagnostics: 1; CY1PR09MB0793; 5:7oO2uaxTCuu0b/aeb8sUOEAPufo2b2vaxmw9wgrBwBlut6UjaZtnGRXB4wVw2DcIEfmZzC5ctRLP3nA+ejWjZ1oX0PMjHYxB0IDTPAnuiqP3e+cWVfF9KNWB687Fb5oxtV4RCjbklij5oXmUCNPiLg==; 24:HuzHmpg0OMFPNtGMva6JbZP771be5AhCLh0gv6P83Mk3z09V1qNsHcpJwWRoRa3jTdzF0zxECK3pr+0bkPGQUpZBzYVAY4Bex7b9ra+zJrk=; 20:5eznSWnRUY5tgY4l9Q6dH0LlkWnk25qRvKw0QBvE2jI6FbD4BKAXbGisGP2FzFkAnpXPyfgeTLosxFFrEKMNmQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0793; 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:CY1PR09MB0793; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0793; x-forefront-prvs: 062899525A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(243025005)(377454003)(377424004)(92566002)(106116001)(76576001)(33656002)(122556002)(66066001)(62966003)(40100003)(46102003)(77156002)(74316001)(99286002)(5002640100001)(76176999)(54356999)(19580395003)(5001960100002)(50986999)(19580405001)(110136002)(86362001)(2900100001)(2950100001)(230783001)(77096005)(2420400003)(102836002)(15975445007)(2656002)(189998001)(87936001)(5003600100002)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0793; H:CY1PR09MB0793.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jul 2015 13:38:44.7236 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0793 Archived-At: Cc: Susan Hares Subject: [Idr] Fw: New Version Notification for draft-sriram-idr-route-leak-detection-mitigation-01 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, 05 Jul 2015 13:39:06 -0000 We (the authors) have just submitted an updated -01 version: https://www.ietf.org/internet-drafts/draft-sriram-idr-route-leak-detection-= mitigation-01.txt =20 Sue had posted a WG adoption call request (with -00 version): =20 http://www.ietf.org/mail-archive/web/idr/current/msg14550.html =20 Please take a look at the updated version. The diff can be viewed at: https://www.ietf.org/rfcdiff?url2=3Ddraft-sriram-idr-route-leak-detection-m= itigation-01=20 Key changes (in -01 version relative to -00): * Section 2 - Related Prior Work - has been newly added * There is substantial new material in Section 5: Design Rationale and Dis= cussion. * Many useful changes have been made to improve the presentation and clarit= y. * Brian Dickson has been added as a co-author. This work was presented in Dallas, and again an updated version was present= ed in the IDR interim meeting on June 29. The slides of the presentation are at: http://www.ietf.org/proceedings/interim/2015/06/29/idr/slides/slides-interi= m-2015-idr-7-0.pdf =20 Comments/questions would be very much appreciated. Sriram =20 ________________________________________ From: internet-drafts@ietf.org Sent: Sunday, July 5, 2015 8:26 AM A new version of I-D, draft-sriram-idr-route-leak-detection-mitigation-01.t= xt has been successfully submitted by Kotikalapudi Sriram and posted to the IETF repository. Name: draft-sriram-idr-route-leak-detection-mitigation Revision: 01 Title: Methods for Detection and Mitigation of BGP Route Leaks Document date: 2015-07-05 Group: idr Pages: 17 URL: https://www.ietf.org/internet-drafts/draft-sriram-idr-route= -leak-detection-mitigation-01.txt Status: https://datatracker.ietf.org/doc/draft-sriram-idr-route-lea= k-detection-mitigation/ Htmlized: https://tools.ietf.org/html/draft-sriram-idr-route-leak-det= ection-mitigation-01 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-sriram-idr-route-= leak-detection-mitigation-01 Abstract: In [I-D.ietf-grow-route-leak-problem-definition], the authors have provided a definition of the route leak problem, and also enumerated several types of route leaks. In this document, we first examine which of those route-leak types are detected and mitigated by the existing origin validation (OV) [RFC 6811] and BGPSEC path validation [I-D.ietf-sidr-bgpsec-protocol]. Where the current OV and BGPSEC protocols don't offer a solution, this document suggests an enhancement that would extend the route-leak detection and mitigation capability of BGPSEC. The solution can be implemented in BGP without necessarily tying it to BGPSEC. Incorporating the solution in BGPSEC is one way of implementing it in a secure way. We do not claim to have provided a solution for all possible types of route leaks, but the solution covers several, especially considering some significant route-leak attacks or occurrences that have been observed in recent years. The document also includes a stopgap method for detection and mitigation of route leaks for the phase when BGPSEC (path validation) is not yet deployed but only origin validation is deployed. From nobody Sun Jul 5 08:29: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 76A331A9067 for ; Sun, 5 Jul 2015 08:29:47 -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 TZjp-vlalyAj for ; Sun, 5 Jul 2015 08:29:45 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (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 4D9A71A908D for ; Sun, 5 Jul 2015 08:29:45 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.203.226; From: "Susan Hares" To: "'Sriram, Kotikalapudi'" , References: <20150705122638.1407.91341.idtracker@ietfa.amsl.com> In-Reply-To: Date: Sun, 5 Jul 2015 11:29:39 -0400 Message-ID: <001b01d0b737$687f1e70$397d5b50$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_001C_01D0B715.E16F0510" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJkIFeXttsDiKru3LvVQKWhTGjkLgG9G8iwnJhEsNA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] Fw: New Version Notification for draft-sriram-idr-route-leak-detection-mitigation-01 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, 05 Jul 2015 15:29:47 -0000 This is a multipart message in MIME format. ------=_NextPart_000_001C_01D0B715.E16F0510 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sriram: Here's an ASPath ORF draft that Keyur and I think might help the non-BGPSEC version of the route leaks. The ORF filters the ASPATH. It's not secure like the BGPSEC - but perhaps it will help. Sue -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Sriram, Kotikalapudi Sent: Sunday, July 05, 2015 9:39 AM To: idr@ietf.org wg Cc: Susan Hares Subject: [Idr] Fw: New Version Notification for draft-sriram-idr-route-leak-detection-mitigation-01 We (the authors) have just submitted an updated -01 version: https://www.ietf.org/internet-drafts/draft-sriram-idr-route-leak-detection-m itigation-01.txt Sue had posted a WG adoption call request (with -00 version): http://www.ietf.org/mail-archive/web/idr/current/msg14550.html Please take a look at the updated version. The diff can be viewed at: https://www.ietf.org/rfcdiff?url2=draft-sriram-idr-route-leak-detection-miti gation-01 Key changes (in -01 version relative to -00): * Section 2 - Related Prior Work - has been newly added * There is substantial new material in Section 5: Design Rationale and Discussion. * Many useful changes have been made to improve the presentation and clarity. * Brian Dickson has been added as a co-author. This work was presented in Dallas, and again an updated version was presented in the IDR interim meeting on June 29. The slides of the presentation are at: http://www.ietf.org/proceedings/interim/2015/06/29/idr/slides/slides-interim -2015-idr-7-0.pdf Comments/questions would be very much appreciated. Sriram ________________________________________ From: internet-drafts@ietf.org Sent: Sunday, July 5, 2015 8:26 AM A new version of I-D, draft-sriram-idr-route-leak-detection-mitigation-01.txt has been successfully submitted by Kotikalapudi Sriram and posted to the IETF repository. Name: draft-sriram-idr-route-leak-detection-mitigation Revision: 01 Title: Methods for Detection and Mitigation of BGP Route Leaks Document date: 2015-07-05 Group: idr Pages: 17 URL: https://www.ietf.org/internet-drafts/draft-sriram-idr-route-leak-detection-m itigation-01.txt Status: https://datatracker.ietf.org/doc/draft-sriram-idr-route-leak-detection-mitig ation/ Htmlized: https://tools.ietf.org/html/draft-sriram-idr-route-leak-detection-mitigation -01 Diff: https://www.ietf.org/rfcdiff?url2=draft-sriram-idr-route-leak-detection-miti gation-01 Abstract: In [I-D.ietf-grow-route-leak-problem-definition], the authors have provided a definition of the route leak problem, and also enumerated several types of route leaks. In this document, we first examine which of those route-leak types are detected and mitigated by the existing origin validation (OV) [RFC 6811] and BGPSEC path validation [I-D.ietf-sidr-bgpsec-protocol]. Where the current OV and BGPSEC protocols don't offer a solution, this document suggests an enhancement that would extend the route-leak detection and mitigation capability of BGPSEC. The solution can be implemented in BGP without necessarily tying it to BGPSEC. Incorporating the solution in BGPSEC is one way of implementing it in a secure way. We do not claim to have provided a solution for all possible types of route leaks, but the solution covers several, especially considering some significant route-leak attacks or occurrences that have been observed in recent years. The document also includes a stopgap method for detection and mitigation of route leaks for the phase when BGPSEC (path validation) is not yet deployed but only origin validation is deployed. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr ------=_NextPart_000_001C_01D0B715.E16F0510 Content-Type: application/pdf; name="draft-ietf-idr-aspath-orf.txt.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="draft-ietf-idr-aspath-orf.txt.pdf" JVBERi0xLjQKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyIC9GbGF0ZURlY29k ZT4+CnN0cmVhbQp4nKVWTVMiSRC98ysyPOxoBB+iq85483PHGXeGFW7rHorubKixu6qnqlrg3+/L okBAI4ydhQgb6cqXL1++TPonHXb7dCjvdM2qVu/hjCa+dUiT1s9WP96kdMkquhzhwEfqH9GoaC1j +nR0TGfHn2hUtfbvrh/o/7yGXfqsHPuD0Y9W/5hG94A0gZ3h0Ll2qgi/Avq5UTPWBx+WWCbnnHxQ ofHnNAzK5MrlnkZOZU/vIX3t0kAFLgXrZl5rMD2nL8o0yi3otE1Hh/3T/0DsSvvMCtavVLV6fWnK BZ3E3CfAkkbcv4V4YVS58NqTLehmrn3QZkIz656osI7ujr4NbxGeRH8rUS76dzSHoqNz11G+VmHa sa7o9A+7YR4QfXQaoy/GPkDOkEobTZE1t1lTsQmUc6ENe1JkeEbfmzC2jcnpwTboM93qUi5hUXPk dfnHoL1FC3crNHDvIqbfiU/he20KUxUoU4bGTI1HQLBUswNklVgt+dNYyV0Xo4sYDV26ifT3h9tO pOKburYu+K2oBLQTiyM047KUq+NJUypHPK9hFa+tSfkqFbIpDrelyBWhPJdDNAFg7bsvcg6jWaVv kdSfXNlNZXcGBN/4ZlzpEJBHGyoacMmskdKVyZhmGgWEKW/JWjv7rIVgzHN5NaCzj4TZWH78tMEG h7czQhTH0UlS/arPEQdZ1ofpxkzQ+KjRVuqR8k90ax2oPe7f3YxuHw+g/zcLUWMXLVBcUgXCLUiV 3lIOBzs9hvRJi9cE1K42PvaVqUSs0Msa58SS61MJKpUFJZF+GkJ93uvlCl2QHcGuKzPQtW7SiyPh ewmn975KMWCD4rMqdR6NrlDaXFdNJcS8nlNlTZj6LaWkHyKAeLoGIc7bsFhdqkw+AcSOvS1ZGj9e JN025AgAWKQSg64YatxFv2ijahigdlqJ6FYm5jV9sXPBKDRbSQ4Xo52qlNSIynRsGVcpNbpnJGwv bhlYETkmYvHu3pZQb7l4puFajiuWMDU7O1aE3r+y9cLpyTSIV/Sa1MvXj/vZ40HciyS2wopvfIgi ii+xDbzYXedQRxcaooHr7lys15ZqwtQ6cdAFmMUEIohn98x593U968DlPP7gLIhGG5MVh2PN64On e56ociv74GUqH7hUcWUDJEZdrxqb6n7cT04NAsf84tIS4hjPHY0dAEHQCC4K4QNhhYQ4Ca5LOHUz RgBy4W4c4Y1iUP2gZGwwVP6ssb4Rjn/yHSoZrC5rZ9FOki6w9X2GcWVa2Mat5BMVICHmOAuxyLia 8E3N6x8PlLtL4crmjD9VbU00Ns/jrw0aWDhbbR+nCmIkKG2yskHoUFd1uez45fCa7pfy4JdlHoTv imrcnkOO1Oj3bpLo9CQ2Jz6l0G/Lx4HNX8n0WPDeU8HfAzVh6v8DxJtR6y+8/wXjTdXqZW5kc3Ry ZWFtCmVuZG9iago2IDAgb2JqCjEwNjYKZW5kb2JqCjEyIDAgb2JqCjw8L0xlbmd0aCAxMyAwIFIv RmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nKVWTW/iSBC9+1eUOOwEiWHBbCCRViuRhMxm lMmw4MtqmENjF+CddtvpjzD8+61q24NNIq2YNQfjdvereuVXr/sZBv0hDPhX3eMs+HUxga0JBrAN noOhfwnVLc7gJqIJVzAMIdoE5ZohhCOYTK4gyoKLB2VRK7Tv77TYWGheD+HT8h4+iAKEEvJgUgOv ro9OHiAcDC+70T/B6Bqix+CChu0OIdLOWHjErZAw1/lLatJcGcJKQGiEgocSTGCf2l3uLOyF1kLZ AwjTfRcMRzVWgibW6ZpmpsoDL9OskOkmpZGb5R08pjEqg31aFI79okisJUK+gduc2CnLeIw07BMp ZXWeuNhSMgD9M38AYSu3kIamy0LYHXxe3L+PDgX+FCJjjVpYgCrOk1Rtz8IaVVi/0cOtKMQ6lSlV dFlgTAWLhWe9yTVVJi9Q0/MLgqbqI2xSSUrggPxBKhy+qpzOrtVpTpdtfp+EjXfn8htXWGN6mGlN RHakJ8kwZ+dVY03oYYmx01wpUowhVWpfKXM21hVzjL+pfC8x2WLG4jsvsyPWNat1+jT9uZzaWMNB /39znNRY1EZPuc5K8Sxwg5q0imfwPGJNHfW+Nu9gmiQajTkHpYlVNf5pg1dRIjKNpuA/O7vOHfnQ wiv//ofyGy2T4CZV3nNaDf9lcX97GV6HX2v/IkODDGOSYWoy31oCbj7MwRQovqEGm4NBCkX3lLRA r6qkCkSea9CyU72ZkoHVBbWKWXXJ94SFWChYIzhDea0PjNfEoghlD/tAeQ3I3c3cXJEIS+nSNDbR Kr+Ga/pCkccneexK4ZY1YIYK997gLBsckyQePaBYGaXSKbu6Vac3+RCdowGsup3ea1qUHX0mipCR V1Ts5rxiLfj1iVX1y2/bcBXjiiLXlPt0CX7Qr6iAjhYnDOxRSr5zMTRunRQa8HvBKmSTLONltUlR RhWIKJUKW0IuTKN+b+wFDf2d7hJCynxPn0khc64C82vjtzmqrGFdVJm1atvIkjfTmqly2Zo042tC VU1Nj4RwlGk9zROrEjspJy1QsXR+1/nPkrSVQ54SY2Ed0aINXLU3MqsPELPpGOtJcclp+5aJgd+X +OzYPnotin5z6NHhQW0t3aeG0f5oh6wK26kROiUmEWfB+mKU+jLl7of1t5beBVrx6Mp1UmqjStCn /XZEn10d7oi+3yEt5KCUQsma/nTms8Wnh6hD4n8R0r2KO1h1exQcOnezp79/zILhqsvB+ZRGU/+k E5OBX7gVUDbPX7PvRcqvPgrlBAUc9/g0Nj49pn2Ziy1C+JUQZ1HwF/3+BUu6xcRlbmRzdHJlYW0K ZW5kb2JqCjEzIDAgb2JqCjk4NwplbmRvYmoKMTcgMCBvYmoKPDwvTGVuZ3RoIDE4IDAgUi9GaWx0 ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicpVZtb9MwEP6eX3HqB9jENtaEdTAhpG0wXsTLWPON 8cFNLqnBsTPbaVeJH8/ZSZoXigCRqGqT8z13fu6ec+/g+GgKx+5uvpMieHxzCrkJjiEP7oKpN0Lz lRRwEdOCpzANIc6C2mcKYQSnp08hLoK9t9KilmgPX2qWWehfb8OP8yt4zUpgkomN4QZ+ud5VYgPh 8fRkP/4WRM8gfh/s1ZZ4iTB5jzK3ywlkHEUKXKY8YRYNWDIKbwOVwfkcSkY/NeaVYHr/YTCNekh4 X2o0hisJxmou8yNaEc7GsZhxIG2sREnLuDSU+xi/D0jRmRwHZGnq7JBrVZU7g9UxJnO8q1AmOAHu A1XS8FxiClEIC25hxUSFRz2XcaQtQSP/6Wy3f7dL50BoDc6Kac4WYkvqEu9ZigkvmGg524my5kLA AjugTAmh1pTBYgMoVZUvwWrGBSG4jKhyCgr2HcmYOvJqvIwRDLHpqWyQVGLRwkJVMmV6Q+E/KotU eGZ99f3WHMIQnpsOgWuNAldM2l4NIkI6n/tyfrq5ojQSlZJ34xUPkOmB1hzGm5I2rrR/0fnW74nH 5/HFyxdHDcK5HMJbvXFrfByihZmGItMQOvnAbLLtujrqoMq/QHDpE9nlSF1bFMRjybSFLzdXlyfh s/DrQZMaI8rdIo0FdbajzPua1vm3kdxGGwxTUldkPPEhJr3tnNGCgX4BHh3+4Xo0bmeAH/RpVQG3 e0/qNjC3+93I+NFV+C9jDNBrxdCP272wRu+D/y/6uReGRx+LyoX5d/RudDT9j1CLzyv4L4QL66Uy rX1AOAGkmHFZq7XhxbdETy9PqE8vWckWJDK7gXlTf2bd9HOiuFSqRE3PK+osVVk3IwSdCT40J8Ra Dq08TNtCdX/1vW+895X37pqXNnnx+tp50djQfgCMd+GmkAtHs0Vjgg6rFR+nwyLTqgA3HEpEfQCU 8wCyycxPlrWqSEyC04AiMOOGVB+J3rU4NORXqC03/jTizrYFwnoFkVoZnxe9+d1Gnb3Hb+Xw2sEs ce0TTTq74yWKiJdt6YYSHJw0PVwn6DOIuvbr2erWONv20s5Ffiqe0ZBGR2Ch9HZE1tHdPhqaXB6z E5/HG0YHITyAazq1RU9l8Oq+5M70jsmKxjvMDty/gBmMri/XLEeIvhLiqzj4TPdPW16GCGVuZHN0 cmVhbQplbmRvYmoKMTggMCBvYmoKODgyCmVuZG9iagoyMiAwIG9iago8PC9MZW5ndGggMjMgMCBS L0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJztVk1z2kAMvftX6NTCpHGwSSDNLW3jlkyG puBb6WFty7CtvQu7a4hn8uMr23wYKCmdMtNL5YMHy9J7TyvJzKBlO9AqruU9TK2LQRfG2mrB2JpZ TumE5S1M4Z1PL1yD44IfW1WMA24but1r8FOr0RMGlUBz/kGx2EDdem5/6MFHNgUmWJJrrmHP7rMk B7flXDX971b7LfgPVqPynJ3/sZ01X1tOu5bjGW6jSKHW4LGUE1IvQmF4zFHBqOGCDA0aPWpuUXqm LH/HYY0+QI1qjhGBORXYDta+nRB9mAUaZxkpfrEMdWYnRO9naUD5ZQyfB54+qgInRCdM8PMp/qPK o4guBhginx/L4ITotm3/Rur/up8Q3e3UNs7aPD6GSxvesykLeMJNDihCGXExppDNovMnCJlG2pAR pMgE+YuRMRPaHEADmkQamCK/hlgmiVzom13Il2b71uuNmhuFJSCt4TIxhEwpjroAA15GEcsKHNgy aVwljaUqHu/uV7I+moVUP+CB5YQ4VdLIUCbEV8uQM0O7b8HNpMy5enVF2EyY2eK2VGjvKjxykQ1L tTeH5BK3OcnUhTZuuKRvEnBBylJW/AIWyMyURE3RwDL+hdq6jErxAFk4WR1xr5auqm5EEMvKbbIw YxQPMoN7SreWZjlI+uDpSWEYF9XxiXWcxxP6IFehYCQECAnXpiRyQFBV9qLzqobbY7XichSVOUuy onrU0utAexNZH1F62rkqcT5Rj2t4BY/UMUl9jO6eprxw3TORMZVD503xb6GzO8VfH9kY4fIbZbzz rS90/QRAZBeTZW5kc3RyZWFtCmVuZG9iagoyMyAwIG9iago2MDYKZW5kb2JqCjI3IDAgb2JqCjw8 L0xlbmd0aCAyOCAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nIVVbW/aMBD+nl9x qqoNOkIJqPRFYlK7la3ttHXAh0pAJZM4xKtjp45Dy7/f2QGa0EAvgkD8+Lm75+6cZ2g1PWiZa3X3 Y+d4cArz1GnB3Hl2PLsIq5sfw9UIAWfgtWEUOvkeD9odOD09g1Hs1G6EpkpQ7X5XJNRQtJv272Ef fpAEiCB8mbIU3tltxpfQbnkn9dE/p3MOo19ObbM4inBLyCgPgImA+UTTFF4iqiOqAL8gpSLAn4ia 1MikDi+McybmoGX9s+N1ymyK+pQtKPwZ9IEKrRiShUrGwHQKCUWeSW1BeEbBm9Qb+GdmGGWG3jl7 ojnpG53xXeLS8j1T2zBJ899HspnU0WapM6mX+EKZ52QoR8sE/UVE41PO5UvaRGi7W87nRlh8liTo cGZcy9A+GWJkx4NVtrOlpvaplgneFaUWW6FPRBY5MvdpdKTClwH+uIBxv9+/u7sbDqamAMqSYCug 8mYHp6EuJRPLVBtIVdx2/0UJjjaEng3c5m+0uBwmREfbsAHCBoVC7kZitIgl0LGh5l2kaErVggZ2 W5jpDBOhrwkRKZPCyKfoPONEVaiDhkgksNCAhSFmIXysOxMmkqpM0VA2jMLGYItYWkS72pZxI10D p6bY90T4kVRYjOrgTEdqorPKVtly18OPCyxOuJ2BjHN0LebYnKv816nudIU2qSGYvpoGt52KOVhG H11sYjWaXg7vsTxAjFIVCqAdPOaYw4N9saNteF1XSOEWJane8PgA7sq+wgM0j/YgD4vQnbg3Qgts Hu2hXavtFdROiNKMcJTDNC1YDRv5DWKyxMNin+gGIaTOZzVPP92pmXHvrXsrZkHAaaGx9HrloHlg Ds7AJyrY6VviIUO0VE2A8Tc8H4g21b3mNMbjb/pRy3l5y7mFdtaKBEzjLBktEtM3RK+GEAPapwE2 0jrcBjB6YROIifYjOyVLSDE0TNWPiCI+vp2Qs7o++StEw7jlnsP0w8Hx8lIWsyi7xlZ3bVW1fKLi eF8SGFa8Lrsh6fVKiqwWTGDTL0aN7okl+klwLOET4LRQXuS7fk2YWbolIiNqCd2Geat2t92O78mc wokp2PXI+YvXf963EJBlbmRzdHJlYW0KZW5kb2JqCjI4IDAgb2JqCjgyNQplbmRvYmoKMzIgMCBv YmoKPDwvTGVuZ3RoIDMzIDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicfVXBUuNG EL37K7o4ZKHKOLYpbEhVDoaFXUhCCHZVDiyHsdSSJoxmxMzIxn+fNyMJLELFPkBZ3a+733vdeqHx aELj8G3/JuXg54c55W4wpnzwMpjEh9T+SUq6WCHgjCZTWmWDJmdC0xOaz89oVQ4Ob7Rnq9kff7Ui 87T/uZneLa/pm6hIaKF2Tjr6z+e2VjuajienR6t/BifntPp9cPgh5EJ6mhKSfcFkZV54Ko3ztJZ+ COSUpE5lIjw3EQePTwdHXwaTk8+wTMVWeGNpW7DlXxA3nX0W91b2V8x7vFdBG0+uripjPadI/5/E SS+xTRoSj/IRPY6Pz59C+umIaLGshC/oz4dr+kP4pJA6b5FvNIk0lV4aTd7E8XLWGEFR2UaSrRXg U86k5sAFPT5cX55Oz6dPwx4Njjcxca+aqziRmUw+ggnLb4DCUWaUMls36rF144MklXFOrhWjNeFj f8AUzwyCTa1SKsSGoZaNAZqM5r36vfZYe7trYGI3rZrW1J5HkYn4LBGOG5kzaZ0/jrEHse+WM1FV SrJDziokSDeM8WHepsZWonxstRQK40JQfqlZJ0y6LtdsO6DSgBGExOA3ijog1PhxFDhIjHYyhZ0i WRHYqDZh2GEFm/qWlJSxMiXYDS5EvH2flFwRQ9YM4aGXl47TD8RnQNu98ZyavivBUCXWUsE0wXWN wmhtHcjlHuWWE5YoQusa6V5i0hThKQevgRexVtI1VGFGzUnwYcNml9qOBxb4FaWwE9GnVminYPsY u1hSVNxyXithQ6Rl2Aa0daaW3rVIPw476C+R3nBdEO5F3AGTfYoC2rtFCxvQQsW+OzJ2IE2bGiKX EG+P0RmMcmUtTgIMmqr33YPO8Lc1m0CI1JmxZdNE9GFe42esRu1rmNsxyut8GJmEOj2a4bKQjNaC dUCVk2WFq1dKB3EpkwozBmftFRlFnXur0vL8htYIITycuG6cE6zaYsM/qXSJsGnPPnPgLjmpbSDk svVtLNjxvyqilp61a4/Oxbf7d5MlIClvZK01ctUuNO46SExUczwUh2fhsCXP2mwVp3lkvavxN3fq kaltvAzP0QoLnVre0r2wXsBoi41mhgGXIilS3uAHxUmP2vuwSS6Y8ko/M10WjH9vTaHpOwuneDek r8ZKXJ7fZBmX8MLW2PPLsKCg8d0p0sLjZexyj6/zoMPibvE5V3emecivEkcEcAACe6lJ6s5kk8k8 An3HSXX0E0bzrPZfFlevlQyPboWuBY7TbBjehrOP75THewHaZ+GVcbUa/IXvv3ENZkNlbmRzdHJl YW0KZW5kb2JqCjMzIDAgb2JqCjk3MAplbmRvYmoKMzcgMCBvYmoKPDwvTGVuZ3RoIDM4IDAgUi9G aWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicdZRNc9owEIbv/hXv5NCQGeP6g8+eCpQE0iSl mB46SQ6KLUCNkYkkQ+iv78qYDjSNfDCDd/d99t21X+B7AXx7Vfdk5XyctrHQjo+F8+IE5UNUt2SF /owCOghCzObOPidAGKHd7mC2cmpjabiS3NS/KDY3OD7j8C6+xBVbg0mW7bTQeHOui2yH0A+aF7Nf TtTF7MapBb4HxDwplDA7DHKpRcoVM4J+XZw7YauMouS7HPoQlpyEgSkOITd5tuEptsIswbA4IvGo UC0IPFtErShpwzHlc664TLhVsfXvp5eDMAi6j0BfsVRy5SL2XJx95Ttsc5VqzHOFQlstULCGyTGW qUiY4VQkiA6oR2fKXwqh+IpLgxu+4Zk+c9EfTBA0XFsEVtLFLVPJEkG32/ZOmrZQUdQNCWqwZDJV jLI8aizFtYc4KdLUcp4N2Jo9iUwYwTV66YYrI3Sp+h5YaVP/alJvnO1BrIxLBm346okrGpMfvmVp hO3g0Xb1vDRW+CcZdCNczOhuoWIPI5qGJqQe+mQaVboie7Zs9x7IROUmT/IMDTzUSqCHiwrJqrm4 ZrJgyi6O33pL1Awrd7h0MfQOFDGTi0xYjDQlHl2fKD4Xr/U+07Qj3wrzlBcyfXdqeWE4LkVGTZZT PzbKKrroFYtCGwvVOYLqFWaZK32OSvbvdsWFZnLvzYnoqGBbLqqgdqMZYSSS55zaHYksOySzTEhO WzIGGp2g3ar+/xH3TvwYrpjIPkEvrcxnmf5eekm+opDqXaMQWuZCYUIjyU44BkIneVX2lhZpLQyj KQ56QLfpR83/6TxTrTVV+pzY5EoqjBplWNkqPuyljr0dvq6FfXQYa8u1n4TWv9+K+wlbcLQfqeRw 5nyn6w/nj0NIZW5kc3RyZWFtCmVuZG9iagozOCAwIG9iago2NjUKZW5kb2JqCjQgMCBvYmoKPDwv VHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgov UmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDkgMCBSCi9Gb250IDEw IDAgUgo+PgovQ29udGVudHMgNSAwIFIKPj4KZW5kb2JqCjExIDAgb2JqCjw8L1R5cGUvUGFnZS9N ZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8 L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAxNCAwIFIKL0ZvbnQgMTUgMCBSCj4+Ci9D b250ZW50cyAxMiAwIFIKPj4KZW5kb2JqCjE2IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBb MCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRb L1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAxOSAwIFIKL0ZvbnQgMjAgMCBSCj4+Ci9Db250ZW50cyAx NyAwIFIKPj4KZW5kb2JqCjIxIDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4 NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4 dF0KL0V4dEdTdGF0ZSAyNCAwIFIKL0ZvbnQgMjUgMCBSCj4+Ci9Db250ZW50cyAyMiAwIFIKPj4K ZW5kb2JqCjI2IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3Rh dGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdT dGF0ZSAyOSAwIFIKL0ZvbnQgMzAgMCBSCj4+Ci9Db250ZW50cyAyNyAwIFIKPj4KZW5kb2JqCjMx IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJl bnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAzNCAw IFIKL0ZvbnQgMzUgMCBSCj4+Ci9Db250ZW50cyAzMiAwIFIKPj4KZW5kb2JqCjM2IDAgb2JqCjw8 L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIK L1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAzOSAwIFIKL0ZvbnQg NDAgMCBSCj4+Ci9Db250ZW50cyAzNyAwIFIKPj4KZW5kb2JqCjMgMCBvYmoKPDwgL1R5cGUgL1Bh Z2VzIC9LaWRzIFsKNCAwIFIKMTEgMCBSCjE2IDAgUgoyMSAwIFIKMjYgMCBSCjMxIDAgUgozNiAw IFIKXSAvQ291bnQgNwo+PgplbmRvYmoKMSAwIG9iago8PC9UeXBlIC9DYXRhbG9nIC9QYWdlcyAz IDAgUgovTWV0YWRhdGEgNDEgMCBSCj4+CmVuZG9iago3IDAgb2JqCjw8L1R5cGUvRXh0R1N0YXRl Ci9PUE0gMT4+ZW5kb2JqCjkgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKMTAgMCBvYmoKPDwv UjgKOCAwIFI+PgplbmRvYmoKMTQgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKMTUgMCBvYmoK PDwvUjgKOCAwIFI+PgplbmRvYmoKMTkgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKMjAgMCBv YmoKPDwvUjgKOCAwIFI+PgplbmRvYmoKMjQgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKMjUg MCBvYmoKPDwvUjgKOCAwIFI+PgplbmRvYmoKMjkgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoK MzAgMCBvYmoKPDwvUjgKOCAwIFI+PgplbmRvYmoKMzQgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRv YmoKMzUgMCBvYmoKPDwvUjgKOCAwIFI+PgplbmRvYmoKMzkgMCBvYmoKPDwvUjcKNyAwIFI+Pgpl bmRvYmoKNDAgMCBvYmoKPDwvUjgKOCAwIFI+PgplbmRvYmoKOCAwIG9iago8PC9CYXNlRm9udC9D b3VyaWVyL1R5cGUvRm9udAovU3VidHlwZS9UeXBlMT4+CmVuZG9iago0MSAwIG9iago8PC9UeXBl L01ldGFkYXRhCi9TdWJ0eXBlL1hNTC9MZW5ndGggMTM1ND4+c3RyZWFtCjw/eHBhY2tldCBiZWdp bj0n77u/JyBpZD0nVzVNME1wQ2VoaUh6cmVTek5UY3prYzlkJz8+Cjw/YWRvYmUteGFwLWZpbHRl cnMgZXNjPSJDUkxGIj8+Cjx4OnhtcG1ldGEgeG1sbnM6eD0nYWRvYmU6bnM6bWV0YS8nIHg6eG1w dGs9J1hNUCB0b29sa2l0IDIuOS4xLTEzLCBmcmFtZXdvcmsgMS42Jz4KPHJkZjpSREYgeG1sbnM6 cmRmPSdodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjJyB4bWxuczpp WD0naHR0cDovL25zLmFkb2JlLmNvbS9pWC8xLjAvJz4KPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJv dXQ9J3V1aWQ6NDZlZTg3ODktNWI0Ni0xMWYwLTAwMDAtOTUxOGU1MjM3NmJhJyB4bWxuczpwZGY9 J2h0dHA6Ly9ucy5hZG9iZS5jb20vcGRmLzEuMy8nIHBkZjpQcm9kdWNlcj0nR1BMIEdob3N0c2Ny aXB0IDkuMDYnLz4KPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9J3V1aWQ6NDZlZTg3ODktNWI0 Ni0xMWYwLTAwMDAtOTUxOGU1MjM3NmJhJyB4bWxuczp4bXA9J2h0dHA6Ly9ucy5hZG9iZS5jb20v eGFwLzEuMC8nPjx4bXA6TW9kaWZ5RGF0ZT4yMDE1LTA3LTA1VDA4OjIzOjAzLTA3OjAwPC94bXA6 TW9kaWZ5RGF0ZT4KPHhtcDpDcmVhdGVEYXRlPjIwMTUtMDctMDVUMDg6MjM6MDMtMDc6MDA8L3ht cDpDcmVhdGVEYXRlPgo8eG1wOkNyZWF0b3JUb29sPkdOVSBFbnNjcmlwdCAxLjYuNS45MDwveG1w OkNyZWF0b3JUb29sPjwvcmRmOkRlc2NyaXB0aW9uPgo8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91 dD0ndXVpZDo0NmVlODc4OS01YjQ2LTExZjAtMDAwMC05NTE4ZTUyMzc2YmEnIHhtbG5zOnhhcE1N PSdodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvbW0vJyB4YXBNTTpEb2N1bWVudElEPSd1dWlk OjQ2ZWU4Nzg5LTViNDYtMTFmMC0wMDAwLTk1MThlNTIzNzZiYScvPgo8cmRmOkRlc2NyaXB0aW9u IHJkZjphYm91dD0ndXVpZDo0NmVlODc4OS01YjQ2LTExZjAtMDAwMC05NTE4ZTUyMzc2YmEnIHht bG5zOmRjPSdodHRwOi8vcHVybC5vcmcvZGMvZWxlbWVudHMvMS4xLycgZGM6Zm9ybWF0PSdhcHBs aWNhdGlvbi9wZGYnPjxkYzp0aXRsZT48cmRmOkFsdD48cmRmOmxpIHhtbDpsYW5nPSd4LWRlZmF1 bHQnPkVuc2NyaXB0IE91dHB1dDwvcmRmOmxpPjwvcmRmOkFsdD48L2RjOnRpdGxlPjwvcmRmOkRl c2NyaXB0aW9uPgo8L3JkZjpSREY+CjwveDp4bXBtZXRhPgogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgCjw/eHBhY2tldCBlbmQ9J3cnPz4KZW5kc3RyZWFtCmVuZG9iagoyIDAgb2JqCjw8 L1Byb2R1Y2VyKEdQTCBHaG9zdHNjcmlwdCA5LjA2KQovQ3JlYXRpb25EYXRlKEQ6MjAxNTA3MDUw ODIzMDMtMDcnMDAnKQovTW9kRGF0ZShEOjIwMTUwNzA1MDgyMzAzLTA3JzAwJykKL1RpdGxlKEVu c2NyaXB0IE91dHB1dCkKL0NyZWF0b3IoR05VIEVuc2NyaXB0IDEuNi41LjkwKT4+ZW5kb2JqCnhy ZWYKMCA0MgowMDAwMDAwMDAwIDY1NTM1IGYgCjAwMDAwMDc4OTAgMDAwMDAgbiAKMDAwMDAwOTkw OCAwMDAwMCBuIAowMDAwMDA3Nzg5IDAwMDAwIG4gCjAwMDAwMDY2NTggMDAwMDAgbiAKMDAwMDAw MDAxNSAwMDAwMCBuIAowMDAwMDAxMTUxIDAwMDAwIG4gCjAwMDAwMDc5NTUgMDAwMDAgbiAKMDAw MDAwODQxNSAwMDAwMCBuIAowMDAwMDA3OTk2IDAwMDAwIG4gCjAwMDAwMDgwMjUgMDAwMDAgbiAK MDAwMDAwNjgxNyAwMDAwMCBuIAowMDAwMDAxMTcxIDAwMDAwIG4gCjAwMDAwMDIyMzAgMDAwMDAg biAKMDAwMDAwODA1NSAwMDAwMCBuIAowMDAwMDA4MDg1IDAwMDAwIG4gCjAwMDAwMDY5NzkgMDAw MDAgbiAKMDAwMDAwMjI1MCAwMDAwMCBuIAowMDAwMDAzMjA0IDAwMDAwIG4gCjAwMDAwMDgxMTUg MDAwMDAgbiAKMDAwMDAwODE0NSAwMDAwMCBuIAowMDAwMDA3MTQxIDAwMDAwIG4gCjAwMDAwMDMy MjQgMDAwMDAgbiAKMDAwMDAwMzkwMiAwMDAwMCBuIAowMDAwMDA4MTc1IDAwMDAwIG4gCjAwMDAw MDgyMDUgMDAwMDAgbiAKMDAwMDAwNzMwMyAwMDAwMCBuIAowMDAwMDAzOTIyIDAwMDAwIG4gCjAw MDAwMDQ4MTkgMDAwMDAgbiAKMDAwMDAwODIzNSAwMDAwMCBuIAowMDAwMDA4MjY1IDAwMDAwIG4g CjAwMDAwMDc0NjUgMDAwMDAgbiAKMDAwMDAwNDgzOSAwMDAwMCBuIAowMDAwMDA1ODgxIDAwMDAw IG4gCjAwMDAwMDgyOTUgMDAwMDAgbiAKMDAwMDAwODMyNSAwMDAwMCBuIAowMDAwMDA3NjI3IDAw MDAwIG4gCjAwMDAwMDU5MDEgMDAwMDAgbiAKMDAwMDAwNjYzOCAwMDAwMCBuIAowMDAwMDA4MzU1 IDAwMDAwIG4gCjAwMDAwMDgzODUgMDAwMDAgbiAKMDAwMDAwODQ3NyAwMDAwMCBuIAp0cmFpbGVy Cjw8IC9TaXplIDQyIC9Sb290IDEgMCBSIC9JbmZvIDIgMCBSCi9JRCBbPEMxRTI4RUJDNjM2OTk0 QjE1OEI5MEVFQzlCODQwMzBFPjxDMUUyOEVCQzYzNjk5NEIxNThCOTBFRUM5Qjg0MDMwRT5dCj4+ CnN0YXJ0eHJlZgoxMDA4NwolJUVPRgo= ------=_NextPart_000_001C_01D0B715.E16F0510-- From nobody Sun Jul 5 09:06: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 99DDC1A8978 for ; Sun, 5 Jul 2015 09:06:21 -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 Hk9zCT7ySBE1 for ; Sun, 5 Jul 2015 09:06:19 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0135.outbound.protection.outlook.com [65.55.169.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C64E1AC411 for ; Sun, 5 Jul 2015 09:06:19 -0700 (PDT) Received: from CY1PR09MB0793.namprd09.prod.outlook.com (10.163.43.143) by BLUPR09MB007.namprd09.prod.outlook.com (10.255.211.150) with Microsoft SMTP Server (TLS) id 15.1.213.10; Sun, 5 Jul 2015 16:06:17 +0000 Received: from CY1PR09MB0793.namprd09.prod.outlook.com ([10.163.43.143]) by CY1PR09MB0793.namprd09.prod.outlook.com ([10.163.43.143]) with mapi id 15.01.0207.004; Sun, 5 Jul 2015 16:06:16 +0000 From: "Sriram, Kotikalapudi" To: Susan Hares , 'idr wg' Thread-Topic: Route Leaks and solutions Thread-Index: AdCygvgZdEuODf/jSQ2DVCW8x4wMngEnwHhu Date: Sun, 5 Jul 2015 16:06:16 +0000 Message-ID: References: <005901d0b283$ea07bd20$be173760$@ndzh.com> In-Reply-To: <005901d0b283$ea07bd20$be173760$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: nist.gov; dkim=none (message not signed) header.d=none; x-originating-ip: [129.6.218.169] x-microsoft-exchange-diagnostics: 1; BLUPR09MB007; 5:+pbmO41D07vafgE5qcv34HyIi57iMabdkUoTpa6PBKOF4IXrCUWhI3OTDVwnwvUYBKR9MQwzM0bCrw6PYw89s5DiwM6YV84tz2eNH/IoWpvATJsVwpGHXGHaGURnoKrdjAA03FnpYCwy7ja+mEa1Yw==; 24:kjPQBq36o6MgHeiZKRArozFfeRZnUtvyfEw9CnX5ohXoE1DLMn4uI/5ujXEcnNKP1qtCDAvEhjIZDM5qSUunf9Vo9pNk+1rbaomOgIkDAGA=; 20:Tf9H/ixtotFa2n5erUUUXcyr7x5PwMn80jTIYAVVrhAhWd/LpemYnf1jBd+ZInLs7VYQLCQb/l1acIrjiZP4bg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR09MB007; blupr09mb007: X-MS-Exchange-Organization-RulesExecuted 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:BLUPR09MB007; BCL:0; PCL:0; RULEID:; SRVR:BLUPR09MB007; x-forefront-prvs: 062899525A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(50986999)(54356999)(189998001)(76176999)(74316001)(5001960100002)(99286002)(33656002)(5003600100002)(19580405001)(19580395003)(5002640100001)(46102003)(66066001)(87936001)(2656002)(77156002)(62966003)(2900100001)(2950100001)(122556002)(86362001)(15975445007)(102836002)(76576001)(5001770100001)(40100003)(92566002)(77096005)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR09MB007; H:CY1PR09MB0793.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jul 2015 16:06:16.3977 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR09MB007 Archived-At: Cc: "Montgomery, Douglas" , "bdickson@twitter.com" Subject: Re: [Idr] Route Leaks and solutions 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, 05 Jul 2015 16:06:21 -0000 Sue, Thanks for this summary and questions based on the IDR interim (6/29) prese= ntation/discussion. Responses follow inline below. >Sriram and Doug:=20 >During the interim the following questions asked about the solution in=20 >draft-sriram-idr-route-leak-detection-mitigation-00 > 1. Does the IDR WG think Route leaks should be deployed in two modes: > With BGPSEC and without BGPSEC? > Without BGPSEC, Sriram suggested that it could accidental route leaks, b= ut not malicious route leaks.=20 > Is this useful to operators? In the updated draft (-01 version) that we just posted, we have talked abou= t of deploying it 'without BGPSEC' and then advancing further to 'with BGPSEC= '. Randy asked on the IDR list if "without bgpsec, is it an attack vector?" IMHO, the worst case damage of using it as an attack vector is quite limite= d,=20 especially when weighed against the benefit.=20 We have tried to discuss this question carefully in Section 5.1 of the upda= ted -01 version: https://tools.ietf.org/html/draft-sriram-idr-route-leak-detection-mitigatio= n-01#section-5 =20 As Jeff Haas rightly pointed out during the interim (6/29): Realistically, = BGPSEC may take=20 a much longer time being deployed than origin validation (OV).=20 So if the operators, already actively engaged in preventing mis-originatio= ns=20 and route leaks using prefix filters and OV, express a further sense of urg= ency for a substantial route leak solution (with OV, without BGPSEC),=20 then yes, there would be a need to work on it now.=20 Danny McPherson had strongly urged for a solution for route leaks: http://www.ietf.org/mail-archive/web/sidr/current/msg00920.html Jared Mauch had also expressed strong concerns about route leaks in the sam= e thread. Plus, we regularly see trade-press and mainstream news headlines (route lea= ks related): "What caused the Google service interruption" March 2015 "Massive route leak causes Internet slowdown" June 2015 "Why Far-Flung Parts of the Internet Broke Today" September 2014 "The New Threat: Targeted Internet Traffic Misdirection" November 2013 "How did Dodo break the internet?" February 2012 So, possibly operators would want to use a route leak solution (without the= BGPSEC protections) for the interim. But yes, it would be good to hear from them directly! > 2. If we think it is useful without BGPSEC, should it be deployed in both= forms (BGPSEC and non-BGPSEC) I think this is already addressed above. 3. Would deploying ROA and route filtering, find this another useful additi= on? By "this" I think you mean a solution without BGPSEC for interim use. I think operators would want to combine it with any existing solutions based on deploying ROA-based origin validation (OV) and route fil= tering. I think deploying OV and route filtering would be very useful but=20 not adequate to solve the route leaks problem, as discussed in Section 5.2: https://tools.ietf.org/html/draft-sriram-idr-route-leak-detection-mitigatio= n-01#section-5 =20 We've also discussed the utility of AS path ORF in Sections 4 and 5. Sriram =A0=20 =A0 From: Susan Hares Sent: Monday, June 29, 2015 11:54 AM To: 'idr wg' Cc: Sriram, Kotikalapudi; Montgomery, Douglas Subject: Route Leaks and solutions=20 =A0=20 Sriram and Doug:=20 =A0 During the interim the following questions asked about the solution in draf= t-sriram-idr-route-leak-detection-mitigation-00 =A0 1.=A0=A0=A0=A0=A0=A0 Does the IDR WG think Route leaks should be deployed i= n two modes:=A0 With BGPSEC and without BGPSEC? =A0 Without BGPSEC, Sriram suggested that =A0it could accidental route leaks, b= ut not malicious route leaks. Is this useful to operators?=20 =A0 Without BGPSEC, this could be deployed as an optional transitive path attri= bute or an extended community. =A0 With BGPSEC, this information could be part of the signed path attributes.= =20 =A0 2.=A0=A0=A0=A0=A0=A0 If we think it is useful without BGPSEC, should it be = deployed in both forms (BGPSEC and non-BGPSEC) 3.=A0=A0=A0=A0=A0=A0 Would deploying ROA and route filtering, find this ano= ther useful addition? =A0 Could you comment on these questions and discuss the value of route leaks o= n the list?=20 =A0 Sue Hares = From nobody Sun Jul 5 13:50: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 855041ACEBB for ; Sun, 5 Jul 2015 13:50:16 -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 HdKMLxCm-T87 for ; Sun, 5 Jul 2015 13:50:12 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0742.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::742]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64C451ACEBF for ; Sun, 5 Jul 2015 13:50:12 -0700 (PDT) Received: from CY1PR09MB0793.namprd09.prod.outlook.com (10.163.43.143) by BN1PR09MB011.namprd09.prod.outlook.com (10.255.201.147) with Microsoft SMTP Server (TLS) id 15.1.207.12; Sun, 5 Jul 2015 20:49:55 +0000 Received: from CY1PR09MB0793.namprd09.prod.outlook.com ([10.163.43.143]) by CY1PR09MB0793.namprd09.prod.outlook.com ([10.163.43.143]) with mapi id 15.01.0207.004; Sun, 5 Jul 2015 20:49:54 +0000 From: "Sriram, Kotikalapudi" To: Susan Hares , "idr@ietf.org" Thread-Topic: [Idr] Fw: New Version Notification for draft-sriram-idr-route-leak-detection-mitigation-01 Thread-Index: AQHQtyfpDU8TLSohskOiYmZoVpjb0Z3NAICAgABJ/6E= Date: Sun, 5 Jul 2015 20:49:54 +0000 Message-ID: References: <20150705122638.1407.91341.idtracker@ietfa.amsl.com> , <001b01d0b737$687f1e70$397d5b50$@ndzh.com> In-Reply-To: <001b01d0b737$687f1e70$397d5b50$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cisco.com; dkim=none (message not signed) header.d=none; x-originating-ip: [129.6.218.169] x-microsoft-exchange-diagnostics: 1; BN1PR09MB011; 5:8HmT/VVyAH7MSwBzECOj/UyXhgkLA2NjqwpRpep/keoxdAXWJ7pSl9YUCHeLXhvKPqrftthT/CSA/nctjt8PzSGG31jf1lNnVTmKnH0nl483z4hUKPCj/TEIqfRCOgVRIhCb7WNQBWTPCpQePUAGCw==; 24:o8HDozLNQ1HLRbWH8LM4W2EiZQKIhLTNpPOk8iOdQLOKsiVEttkbnrw6453KVikMgdhZfoP0GRQ/7uGwlmW2EI8o8O6fcTgbrKXctdpdAgk=; 20:hj2h6epLiDlOk6f1F2uU1pUJHdP7OLb6WWu+6FYCntSBDyrX5lSy2U+cktMtZNdfFA4s7zaGEd2inn4Xic0RVQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR09MB011; 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:BN1PR09MB011; BCL:0; PCL:0; RULEID:; SRVR:BN1PR09MB011; x-forefront-prvs: 062899525A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(2950100001)(62966003)(87936001)(19580405001)(2501003)(230783001)(86362001)(5003600100002)(5002640100001)(106116001)(5001770100001)(2656002)(19580395003)(92566002)(102836002)(99286002)(77096005)(77156002)(2900100001)(122556002)(5890100001)(40100003)(5001960100002)(66066001)(76576001)(189998001)(54356999)(33656002)(46102003)(107886002)(76176999)(50986999)(74316001)(4001430100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB011; H:CY1PR09MB0793.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jul 2015 20:49:54.2484 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR09MB011 Archived-At: Cc: "Keyur Patel \(keyupate\)" , "Montgomery, Douglas" , "bdickson@twitter.com" Subject: Re: [Idr] Fw: New Version Notification for draft-sriram-idr-route-leak-detection-mitigation-01 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, 05 Jul 2015 20:50:16 -0000 Sue, The pdf you attached seems to be version -10 of the ASPath ORF draft.=20 We referenced version-09 and discussed its applicability in the updated rou= te leak draft in Sections 4 and 5. Content wise, version -10 of ASPath ORF draft is very close to version -09.= =20 But we'll update our reference list anyway in the next spin. Will be happy to discuss it further with you and Keyur in Prague. BTW, version -10 of the ASPath ORF draft is titled "Analysis of Existing wo= rk for I2NSF"... typo? Sriram=20 ________________________________________ From: Susan Hares Sent: Sunday, July 5, 2015 11:29 AM To: Sriram, Kotikalapudi; idr@ietf.org Subject: RE: [Idr] Fw: New Version Notification for draft-sriram-idr-route-= leak-detection-mitigation-01 Sriram: Here's an ASPath ORF draft that Keyur and I think might help the non-BGPSEC version of the route leaks. The ORF filters the ASPATH. It's not secure like the BGPSEC - but perhaps it will help. Sue From nobody Sun Jul 5 14:10: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 D61FE1A00B0 for ; Sun, 5 Jul 2015 14:10:23 -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 q1uhKTxwRV37 for ; Sun, 5 Jul 2015 14:10:21 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0734.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::734]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4A8C1A006D for ; Sun, 5 Jul 2015 14:10:21 -0700 (PDT) Received: from CY1PR09MB0793.namprd09.prod.outlook.com (10.163.43.143) by BLUPR09MB005.namprd09.prod.outlook.com (10.255.211.143) with Microsoft SMTP Server (TLS) id 15.1.213.10; Sun, 5 Jul 2015 21:10:16 +0000 Received: from CY1PR09MB0793.namprd09.prod.outlook.com ([10.163.43.143]) by CY1PR09MB0793.namprd09.prod.outlook.com ([10.163.43.143]) with mapi id 15.01.0207.004; Sun, 5 Jul 2015 21:10:16 +0000 From: "Sriram, Kotikalapudi" To: Randy Bush , Susan Hares Thread-Topic: [Idr] Route Leaks and solutions Thread-Index: AQHQst/YBwy3rwbYakKgtnDiHnHcZp3NZLUJ Date: Sun, 5 Jul 2015 21:10:15 +0000 Message-ID: References: <005901d0b283$ea07bd20$be173760$@ndzh.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-originating-ip: [129.6.218.169] x-microsoft-exchange-diagnostics: 1; BLUPR09MB005; 5:ri7reYeRqSLtsAlEY0ck/Z8c19miiH3Xjktyfvn9SFyvu0bgflJD5cNtnR2dpUTFqP1uK5NsxgAeniGdit9y3zrfdxg2OcuedSSMdy69o8sGavy0z1ZeM/HLNPRTOrsgMSH8ftstbxODaH00K8foUQ==; 24:UG7yRXb8LWIJTNlNa4gVpzRj3N/lvtl3B6rPdd5j8tv392OjKfNGnfdSHCBGk9NJfD+g4myB+oA1JMLaKcI9tDzPJv/oUypZiR+bBxdDyWs=; 20:3XRYju3QIngBFQGa57kyhVMRhrsH1qRwWHCQW5pA8nERutVtfaYCA4N5W2+fydOj9i2N8mrNRHm+79ZG4TaffA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR09MB005; blupr09mb005: X-MS-Exchange-Organization-RulesExecuted 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:BLUPR09MB005; BCL:0; PCL:0; RULEID:; SRVR:BLUPR09MB005; x-forefront-prvs: 062899525A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(92566002)(5001770100001)(76576001)(106116001)(122556002)(40100003)(66066001)(33656002)(46102003)(77156002)(62966003)(99286002)(74316001)(54356999)(76176999)(19580395003)(5002640100001)(50986999)(86362001)(2950100001)(5001960100002)(102836002)(77096005)(87936001)(15975445007)(189998001)(2656002)(5003600100002)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR09MB005; H:CY1PR09MB0793.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jul 2015 21:10:15.6868 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR09MB005 Archived-At: Cc: 'idr wg' , "Montgomery, Douglas" , "bdickson@twitter.com" Subject: Re: [Idr] Route Leaks and solutions 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, 05 Jul 2015 21:10:24 -0000 Randy, > 1. Does the IDR WG think Route leaks should be deployed in two modes: > With BGPSEC and without BGPSEC? >without bgpsec, is it an attack vector? We have tried to address this question in some detail in Section 5.1 of the= updated version: https://tools.ietf.org/html/draft-sriram-idr-route-leak-detection-mitigatio= n-01#section-5=20 Please let us know if that seems reasonable or would like to add anything t= o that discussion. Sriram =20 From nobody Sun Jul 5 14:41: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 96F5B1A0233 for ; Sun, 5 Jul 2015 14:41:46 -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 BzpjLOw6Cd39 for ; Sun, 5 Jul 2015 14:41:45 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (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 6AB5B1A001B for ; Sun, 5 Jul 2015 14:41:45 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.203.226; From: "Susan Hares" To: "'Sriram, Kotikalapudi'" , References: <20150705122638.1407.91341.idtracker@ietfa.amsl.com> , <001b01d0b737$687f1e70$397d5b50$@ndzh.com> In-Reply-To: Date: Sun, 5 Jul 2015 17:41:36 -0400 Message-ID: <000e01d0b76b$5f3f9310$1dbeb930$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJkIFeXttsDiKru3LvVQKWhTGjkLgG9G8iwAgoNAMoBM3eT0Jx+wDsQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: "'Keyur Patel \(keyupate\)'" , "'Montgomery, Douglas'" , bdickson@twitter.com Subject: Re: [Idr] Fw: New Version Notification for draft-sriram-idr-route-leak-detection-mitigation-01 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, 05 Jul 2015 21:41:46 -0000 Sriram: You are correct. I sent you an updated version of the ASPath ORF. I included the -10 version because it has the error condition handling section. Let me know if you think the error handling of the ORF will cause any security issues. Sue PS - Version -10 is not posted yet due to a slight problem with posting. -----Original Message----- From: Sriram, Kotikalapudi [mailto:kotikalapudi.sriram@nist.gov] Sent: Sunday, July 05, 2015 4:50 PM To: Susan Hares; idr@ietf.org Cc: Keyur Patel (keyupate); bdickson@twitter.com; Montgomery, Douglas Subject: Re: [Idr] Fw: New Version Notification for draft-sriram-idr-route-leak-detection-mitigation-01 Sue, The pdf you attached seems to be version -10 of the ASPath ORF draft. We referenced version-09 and discussed its applicability in the updated route leak draft in Sections 4 and 5. Content wise, version -10 of ASPath ORF draft is very close to version -09. But we'll update our reference list anyway in the next spin. Will be happy to discuss it further with you and Keyur in Prague. BTW, version -10 of the ASPath ORF draft is titled "Analysis of Existing work for I2NSF"... typo? Sriram ________________________________________ From: Susan Hares Sent: Sunday, July 5, 2015 11:29 AM To: Sriram, Kotikalapudi; idr@ietf.org Subject: RE: [Idr] Fw: New Version Notification for draft-sriram-idr-route-leak-detection-mitigation-01 Sriram: Here's an ASPath ORF draft that Keyur and I think might help the non-BGPSEC version of the route leaks. The ORF filters the ASPATH. It's not secure like the BGPSEC - but perhaps it will help. Sue From nobody Sun Jul 5 16:50: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 309391A8794 for ; Sun, 5 Jul 2015 16:50:12 -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 7Gfa40rCWXiU for ; Sun, 5 Jul 2015 16:50:11 -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 0242A1A8785 for ; Sun, 5 Jul 2015 16:50:11 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1ZBtfk-000365-Bb; Sun, 05 Jul 2015 23:50:08 +0000 Date: Mon, 06 Jul 2015 08:50:06 +0900 Message-ID: From: Randy Bush To: Kotikalapudi Sriram In-Reply-To: References: <005901d0b283$ea07bd20$be173760$@ndzh.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 Subject: Re: [Idr] Route Leaks and solutions 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, 05 Jul 2015 23:50:12 -0000 >>> 1. Does the IDR WG think Route leaks should be deployed in two modes: >>> With BGPSEC and without BGPSEC? >> without bgpsec, is it an attack vector? > > We have tried to address this question in some detail in Section 5.1 > of the updated version: > https://tools.ietf.org/html/draft-sriram-idr-route-leak-detection-mitigation-01#section-5 > > Please let us know if that seems reasonable or would like to add > anything to that discussion. my read of 5.1 is that it says, yes, it is a new attack vector. so we agree. you left out the attack where it A's customer uses it to poison a prefix so that A does not pass it to A's peer B. there might be others, but i am on my first cup of coffee. i am unsure whether these issues are sufficiently critical to discourage use of rlp bits without bgpsec. but at least they're coming out in the open. randy From nobody Sun Jul 5 19:42: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 D57EB1B2A3A for ; Sun, 5 Jul 2015 19:42:25 -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 y8jugK3Y8nSu for ; Sun, 5 Jul 2015 19:42:24 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0119.outbound.protection.outlook.com [65.55.169.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD7521B2A1A for ; Sun, 5 Jul 2015 19:41:16 -0700 (PDT) Received: from CY1PR09MB0796.namprd09.prod.outlook.com (10.163.43.146) by CY1PR09MB0694.namprd09.prod.outlook.com (10.161.172.28) with Microsoft SMTP Server (TLS) id 15.1.201.16; Mon, 6 Jul 2015 02:41:14 +0000 Received: from CY1PR09MB0793.namprd09.prod.outlook.com (10.163.43.143) by CY1PR09MB0796.namprd09.prod.outlook.com (10.163.43.146) with Microsoft SMTP Server (TLS) id 15.1.207.19; Mon, 6 Jul 2015 02:41:14 +0000 Received: from CY1PR09MB0793.namprd09.prod.outlook.com ([10.163.43.143]) by CY1PR09MB0793.namprd09.prod.outlook.com ([10.163.43.143]) with mapi id 15.01.0207.004; Mon, 6 Jul 2015 02:41:14 +0000 From: "Sriram, Kotikalapudi" To: Randy Bush Thread-Topic: [Idr] Route Leaks and solutions Thread-Index: AQHQst/YBwy3rwbYakKgtnDiHnHcZp3NZLUJgAAwLgCAACk92A== Date: Mon, 6 Jul 2015 02:41:13 +0000 Message-ID: References: <005901d0b283$ea07bd20$be173760$@ndzh.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-originating-ip: [129.6.223.194] x-microsoft-exchange-diagnostics: 1; CY1PR09MB0796; 24:UNYCxQKR4N/7hrNE/8d5rd1r/PCN3zpuEGKuHEh6gxtH7ORcLU1U103dSgmS2WZbvTfDQPkAEat5QwNwEZaz++kcdomtF9+eZSEdmC+mPhw=; 20:QW1AAJ3SOTgp1ENqGEN+MhMl8Hedb6oMzR7CjY9epeMPjiagd9QDdArl4qgAoLM6C3+hup8mqSlMbgmpXIG1oQ== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0796; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0694; 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:CY1PR09MB0796; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0796; x-forefront-prvs: 06290ECA9D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(106116001)(5003600100002)(40100003)(77156002)(33656002)(189998001)(62966003)(92566002)(5002640100001)(76576001)(122556002)(5001960100002)(110136002)(74316001)(5001920100001)(66066001)(46102003)(86362001)(2900100001)(102836002)(2950100001)(50986999)(77096005)(2656002)(87936001)(76176999)(54356999); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0796; H:CY1PR09MB0793.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jul 2015 02:41:13.1368 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0796 X-Microsoft-Exchange-Diagnostics: 1; CY1PR09MB0694; 2:u8Ohph95uwuRy6iafo+tIlfNcI9dW9e4Zi/ZRvN4mkTiH44zmNoVRCZbig0TY+e9; 3:RdUcUrX689JVJysKdqq5jgbfI/7elJ7o9iHo5gI1K0t4g0mHlWaPhZbRPjy0VGJPxxqFcL9d/fA4Wz4wrKZVXE2tulJHU6jNc9Kps6eHYZGOssPjkFpT41JKUQCTapAI7B5eXFOKNHH/ElIOTym4ow==; 25:m4EGIR50rO2lxiZ6FGibMcKGm+xwjyv6HpnUY7D3CsKhX2XWw8bd/d1AtD5SWk4sEsp0O4R2QUpKUbu9NsnuO4SBS3e3ZC7Qlg1t2nV20o6JPp4wDgb4o/IA2adorGdIwQAvL271iyEyD+WD8ZHs9Y+ucoa6cDVs3Hw7818pam7uzCYDt7Zdb2Y552D3cu347TcKR5L2Iqwg2zaQjpuGsZTqjpNV6C9vmDosmO26jdc53xLiepdGTo9ptNkCgO0+e136zO9vi7bGgUOW3BJVcg==; 23:g92X/URg7imJq6ikeyhm2k0PK7GevboYZk11y+Jbdl3l/ygJiVkjlvMcnM31AGCXEKymuqlfVC7ExNjvZDFKGCOgJLLgIihXhL/MOKJgNpopJaqWP6gKZCHEDHVqFZJm1YcjNeUn7adaBXd4o7knoj1bLURp+wams8P+FB8O6szX8DK+554/EW/f5hJOmEevcdwwKDcuKa/ZNh7KQq1WLN0gTTvBCJlmwMfY/vl7u+EeRoCNGyAZAVm6us8WdfGX X-OriginatorOrg: nist.gov Archived-At: Cc: idr wg list Subject: Re: [Idr] Route Leaks and solutions 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 Jul 2015 02:42:26 -0000 >my read of 5.1 is that it says, yes, it is a new attack vector. so we agr= ee. Yes, but I think even the worst case exploitation of the attack vector is n= ot looking terrible. >you left out the attack where it A's customer uses it to poison a prefix >so that A does not pass it to A's peer B. there might be others, but i >am on my first cup of coffee. If A's customer C does not want A to propagate, then C has a choice not to = send=20 the prefix-route to A in the first place.=20 Given that choice, why would C instead choose to poison or downgrade by alt= ering RLP bits? >i am unsure whether these issues are sufficiently critical to discourage >use of rlp bits without bgpsec. but at least they're coming out in the op= en. Sriram From nobody Sun Jul 5 19:47: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 C87771B2A20 for ; Sun, 5 Jul 2015 19:47:11 -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 lYKrchtWhboj for ; Sun, 5 Jul 2015 19:47:11 -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 023BE1B2A1F for ; Sun, 5 Jul 2015 19:47:11 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1ZBwR2-0003nu-Pf; Mon, 06 Jul 2015 02:47:09 +0000 Date: Mon, 06 Jul 2015 11:47:07 +0900 Message-ID: From: Randy Bush To: "Sriram, Kotikalapudi" In-Reply-To: References: <005901d0b283$ea07bd20$be173760$@ndzh.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 Subject: Re: [Idr] Route Leaks and solutions 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 Jul 2015 02:47:11 -0000 > If A's customer C does not want A to propagate, then C has a choice not to send > the prefix-route to A in the first place. not propagate to peer. get traffic from A's cust cone and upstream. From nobody Sun Jul 5 20:16: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 565DA1B2A5B for ; Sun, 5 Jul 2015 20:16:26 -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 LTWJFtiB4Fe3 for ; Sun, 5 Jul 2015 20:16:25 -0700 (PDT) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) (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 301E21B2A5A for ; Sun, 5 Jul 2015 20:16:25 -0700 (PDT) Received: by ykeo3 with SMTP id o3so16818822yke.0 for ; Sun, 05 Jul 2015 20:16:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=NsBjmuJOTKUgllkL/kVL0rOywMtyUGZ5bk0p2lQ3kxE=; b=NVfUqvrR05Ron8jscuZNND3tloECCo4TAoi83Y+Z/9VdDb7lDzTMsv+S9m0Qw0AvAX T7OiHnZ5PdAr2W+PMIfiIZ+22kjSQh5OGe3KSkk6A4kfWS6GhYvoPq5U9G90Hw9nE4ao oKrBp9DgyeSJwRCzUmafbECJy9MO/LeWOTCoXOS6a/3u5yZ3mHXxkY5Nu0x658Y49QLf N9x5sN3sTibhFb6w9y2Lx91dVhL8raCQdzDm6DuY9LqFp/mgwsn2l/w7R99UiMfQwpTe jLmPcJNeH2BWpx/oA8ymPqwkqbGA+qXq4a/Lb+RbbWezblxcK2MlTEUr/4/egvIDczjI MlxA== MIME-Version: 1.0 X-Received: by 10.129.137.4 with SMTP id z4mr53551468ywf.145.1436152584530; Sun, 05 Jul 2015 20:16:24 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.13.228.196 with HTTP; Sun, 5 Jul 2015 20:16:24 -0700 (PDT) In-Reply-To: References: <005901d0b283$ea07bd20$be173760$@ndzh.com> Date: Sun, 5 Jul 2015 23:16:24 -0400 X-Google-Sender-Auth: XBpBb_3NcklYxNNCxeW-M4cKWPE Message-ID: From: Christopher Morrow To: "Sriram, Kotikalapudi" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: idr wg list Subject: Re: [Idr] Route Leaks and solutions 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 Jul 2015 03:16:26 -0000 On Sun, Jul 5, 2015 at 10:41 PM, Sriram, Kotikalapudi wrote: > If A's customer C does not want A to propagate, then C has a choice not to send > the prefix-route to A in the first place. > Given that choice, why would C instead choose to poison or downgrade by altering RLP bits? Q: why do people poison routes by jamming in to the aspath ASN which they want to ignore their prefix/announcement? A: because knob. From nobody Sun Jul 5 20:20: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 DA1971B2A5D for ; Sun, 5 Jul 2015 20:20:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 q1dfCRXYLe7q for ; Sun, 5 Jul 2015 20:19:55 -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 2A4CA1A906E for ; Sun, 5 Jul 2015 20:19:55 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BUS97268; Mon, 06 Jul 2015 03:19:53 +0000 (GMT) Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 6 Jul 2015 04:19:53 +0100 Received: from NKGEML509-MBS.china.huawei.com ([169.254.2.184]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Mon, 6 Jul 2015 11:19:48 +0800 From: Youjianjie To: "idr@ietf.org" Thread-Topic: New Version Notification for draft-liang-idr-bgp-flowspec-label-00.txt Thread-Index: AQHQt5kMpWvrh8jwykyrh4glNHfQJJ3NxLwQ Date: Mon, 6 Jul 2015 03:19:48 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.173] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Idr] Fwd: New Version Notification for draft-liang-idr-bgp-flowspec-label-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 03:20:06 -0000 RGVhciBhbGwsDQoNClRoaXMgZG9jdW1lbnQgYWRkcyBsYWJlbChzKSBpbnRvIEZsb3dTcGVjIHJ1 bGUgW1JGQzc3NV0sIGluIG9yZGVyIHRvIGZhY2lsaXRhdGUgbW9uaXRvcmluZyBhbmQgdHJhZmZp YyBzdGF0aXN0aWNzLiBUaGUgcmVxdWlyZW1lbnQgaXMgZnJvbSA1NTc1LCBzZWN0aW9uIDkuDQpB bm90aGVyIGFkdmFudGFnZSBpcyB1c2luZyBsYWJlbCBjYW4gaW1wcm92ZSBmb3J3YXJkaW5nIHBl cmZvcm1hbmNlIGluIEJHUCBWUE4vTVBMUyBuZXR3b3Jrcy4NCllvdXIgY29tbWVudHMgYXJlIGFw cHJlY2lhdGVkLiANCg0KVGhhbmtzLA0KSmlhbmppZQ0KDQotLS0tLemCruS7tuWOn+S7ti0tLS0t DQrlj5Hku7bkuro6IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRy YWZ0c0BpZXRmLm9yZ10gDQrlj5HpgIHml7bpl7Q6IDIwMTXlubQ35pyINuaXpSAxMTowOA0K5pS2 5Lu25Lq6OiBZb3VqaWFuamllOyBZb3VqaWFuamllOyBMaWFuZ3FpYW5kZW5nOyBMaWFuZ3FpYW5k ZW5nDQrkuLvpopg6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbGlhbmctaWRy LWJncC1mbG93c3BlYy1sYWJlbC0wMC50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJh ZnQtbGlhbmctaWRyLWJncC1mbG93c3BlYy1sYWJlbC0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3Nm dWxseSBzdWJtaXR0ZWQgYnkgSmlhbmppZSBZb3UgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBv c2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQtbGlhbmctaWRyLWJncC1mbG93c3BlYy1sYWJlbA0KUmV2 aXNpb246CTAwDQpUaXRsZToJCUNhcnJ5aW5nIExhYmVsIEluZm9ybWF0aW9uIGZvciBCR1AgRmxv d1NwZWMNCkRvY3VtZW50IGRhdGU6CTIwMTUtMDctMDUNCkdyb3VwOgkJSW5kaXZpZHVhbCBTdWJt aXNzaW9uDQpQYWdlczoJCTcNClVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9p bnRlcm5ldC1kcmFmdHMvZHJhZnQtbGlhbmctaWRyLWJncC1mbG93c3BlYy1sYWJlbC0wMC50eHQN ClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1s aWFuZy1pZHItYmdwLWZsb3dzcGVjLWxhYmVsLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1saWFuZy1pZHItYmdwLWZsb3dzcGVjLWxhYmVsLTAwDQoN Cg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBhIG1ldGhvZCBpbiB3aGlj aCB0aGUgbGFiZWwgbWFwcGluZw0KICAgaW5mb3JtYXRpb24gZm9yIGEgcGFydGljdWxhciBGbG93 U3BlYyBydWxlIGlzIHBpZ2d5YmFja2VkIGluIHRoZSBzYW1lDQogICBCb3JkZXIgR2F0ZXdheSBQ cm90b2NvbCAoQkdQKSBVcGRhdGUgbWVzc2FnZSB0aGF0IGlzIHVzZWQgdG8NCiAgIGRpc3RyaWJ1 dGUgdGhlIEZsb3dTcGVjIHJ1bGUuICBCYXNlZCBvbiB0aGUgcHJvcG9zZWQgbWV0aG9kLCB0aGUN CiAgIExhYmVsIFN3aXRjaGluZyBSb3V0ZXJzIChMU1JzKSAoZXhjZXB0IHRoZSBpbmdyZXNzIExT Uikgb24gdGhlIExhYmVsDQogICBTd2l0Y2hlZCBQYXRoIChMU1ApIGNhbiB1c2UgbGFiZWwgdG8g aW5kZW50aWZ5IHRoZSB0cmFmZmljIG1hdGNoaW5nIGENCiAgIHBhcnRpY3VsYXIgRmxvd1NwZWMg cnVsZTsgdGhpcyBmYWNpbGl0YXRlcyBtb25pdG9yaW5nIGFuZCB0cmFmZmljDQogICBzdGF0aXN0 aWNzIGZvciBGbG93U3BlYyBydWxlcy4gIE1lYW53aGlsZSwgdXNpbmcgbGFiZWwgZm9yIEZsb3dT cGVjDQogICBydWxlIGNhbiBpbXByb3ZlIGZvcndhcmRpbmcgcGVyZm9ybWFuY2UgaW4gQkdQIFZQ Ti9NUExTIG5ldHdvcmtzLg0KDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVh c2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGlt ZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBh dmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Sun Jul 5 21:06: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 3922C1A1EFF for ; Sun, 5 Jul 2015 21:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 aJiqSLXnvjj7 for ; Sun, 5 Jul 2015 21:06:21 -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 4E8761A21A5 for ; Sun, 5 Jul 2015 21:06:21 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BYJ34369; Mon, 06 Jul 2015 04:06:19 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 6 Jul 2015 05:06:18 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.233]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Mon, 6 Jul 2015 12:06:06 +0800 From: Haoweiguo To: "idr@ietf.org" Thread-Topic: New Version Notification for draft-hao-idr-flowspec-nvo3-00.txt Thread-Index: AQHQt6DSSu1zxiyKh0yfTw+XQQERNJ3N0nEj Date: Mon, 6 Jul 2015 04:06:06 +0000 Message-ID: References: <20150706040235.25331.39854.idtracker@ietfa.amsl.com> In-Reply-To: <20150706040235.25331.39854.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.23.94] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Idr] New Version Notification for draft-hao-idr-flowspec-nvo3-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 04:06:23 -0000 Hi All, We have posted the draft of "BGP flow-spec for NVO3" just now. Your comment= s and suggestions are appreciated. Thanks, weiguo ________________________________________ From: internet-drafts@ietf.org [internet-drafts@ietf.org] Sent: Monday, July 06, 2015 12:02 To: Lizhenbin; Zhuangshunwan; Haoweiguo; Zhuangshunwan; Haoweiguo; Lizhenbi= n Subject: New Version Notification for draft-hao-idr-flowspec-nvo3-00.txt A new version of I-D, draft-hao-idr-flowspec-nvo3-00.txt has been successfully submitted by Weiguo Hao and posted to the IETF repository. Name: draft-hao-idr-flowspec-nvo3 Revision: 00 Title: Dissemination of Flow Specification Rules for NVO3 Document date: 2015-07-06 Group: Individual Submission Pages: 10 URL: https://www.ietf.org/internet-drafts/draft-hao-idr-flowspec= -nvo3-00.txt Status: https://datatracker.ietf.org/doc/draft-hao-idr-flowspec-nvo= 3/ Htmlized: https://tools.ietf.org/html/draft-hao-idr-flowspec-nvo3-00 Abstract: This document defines BGP flow-spec extension for NVO3. A Flag in BGP Path Attribute is introduced to indicate the Flow-spec rules imposing on NVO3 outer or inner layer. A new subset of NVO3 specific component types and extended community also are defined. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat= From nobody Mon Jul 6 05:10: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 33E4D1ACE68 for ; Mon, 6 Jul 2015 05:10:53 -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 AUy7zb_02LA7 for ; Mon, 6 Jul 2015 05:10:48 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0125.outbound.protection.outlook.com [207.46.100.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 745A51ACE50 for ; Mon, 6 Jul 2015 05:10:48 -0700 (PDT) Received: from CY1PR09MB0793.namprd09.prod.outlook.com (10.163.43.143) by CY1PR09MB0794.namprd09.prod.outlook.com (10.163.43.144) with Microsoft SMTP Server (TLS) id 15.1.207.19; Mon, 6 Jul 2015 12:10:47 +0000 Received: from CY1PR09MB0793.namprd09.prod.outlook.com ([10.163.43.143]) by CY1PR09MB0793.namprd09.prod.outlook.com ([10.163.43.143]) with mapi id 15.01.0207.004; Mon, 6 Jul 2015 12:10:47 +0000 From: "Sriram, Kotikalapudi" To: Randy Bush Thread-Topic: [Idr] Route Leaks and solutions Thread-Index: AQHQst/YBwy3rwbYakKgtnDiHnHcZp3NZLUJgAAwLgCAACk92IAACDiAgACWq4A= Date: Mon, 6 Jul 2015 12:10:47 +0000 Message-ID: References: <005901d0b283$ea07bd20$be173760$@ndzh.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-originating-ip: [129.6.223.194] x-microsoft-exchange-diagnostics: 1; CY1PR09MB0794; 24:uxPmb9dPX6uZMJXptq9gdSHuGpyeccqtHoTvWJG1hDDkTEYX1X8aPWTe5zIhNZp3yZug8OGg+f5kvUkhcsA/XDrjAwX81dsKtgTEmlIlcXE=; 20:0j2w91Ine78Zl53u4oGJ4Knp+PC6fe2UcjqB0yl+ZegJZOC2na6Um/pFHGjZmzhYMsvnhj9SpvrihzpkoAZEmw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0794; 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:CY1PR09MB0794; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0794; x-forefront-prvs: 06290ECA9D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(77096005)(54356999)(189998001)(106116001)(76176999)(110136002)(74316001)(33656002)(5003600100002)(46102003)(5002640100001)(5001960100002)(87936001)(66066001)(2656002)(50986999)(77156002)(62966003)(2950100001)(86362001)(2900100001)(92566002)(122556002)(102836002)(76576001)(40100003); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0794; H:CY1PR09MB0793.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jul 2015 12:10:47.3029 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0794 Archived-At: Cc: idr wg list Subject: Re: [Idr] Route Leaks and solutions 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 Jul 2015 12:10:53 -0000 >> If A's customer C does not want A to propagate, then C has a choice not = to send >> the prefix-route to A in the first place. >not propagate to peer. get traffic from A's cust cone and upstream. Trying to understand ... C makes an update it sends to A look like a route leak (by altering RLP bit= s). =20 A detects and "marks" the update as a route leak. Now it is entirely up to A to apply whatever mitigation and forwarding poli= cy it chooses. (i.e. C is not a position to influence A's policy about what A does with a = "marked" update.) Typically, A's mitigation policy would be to choose an alternate route for = the prefix that is not marked as route leak. In that case, C would not get any traffic for that prefix from A. Am I missing something here? =20 Sriram =20 From nobody Mon Jul 6 07:10: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 630991A21B5; Mon, 6 Jul 2015 07:10:19 -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 zuY60dr7hHU9; Mon, 6 Jul 2015 07:10:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 21FF71A1A73; Mon, 6 Jul 2015 07:10: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.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150706141017.31158.42788.idtracker@ietfa.amsl.com> Date: Mon, 06 Jul 2015 07:10:17 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-aspath-orf-10.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, 06 Jul 2015 14:10:19 -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 : Analysis of Existing work for I2NSF Authors : Susan Hares Keyur Patel Filename : draft-ietf-idr-aspath-orf-10.txt Pages : 7 Date : 2015-07-05 Abstract: This document defines a new Outbound Router Filter type for BGP, termed "Aspath Outbound Route Filter", that can be used to perform aspath based route filtering. This ORF-type supports aspath based route filtering as well as regular expression based matching, for address groups. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-aspath-orf/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-aspath-orf-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-aspath-orf-10 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 Jul 6 08:33: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 9D6601B2C1D; Mon, 6 Jul 2015 08:33:48 -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 YpCF8nhkDPfO; Mon, 6 Jul 2015 08:33:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 80E581B2C1E; Mon, 6 Jul 2015 08:31:49 -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.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150706153149.29583.37991.idtracker@ietfa.amsl.com> Date: Mon, 06 Jul 2015 08:31:49 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-as-migration-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, 06 Jul 2015 15:33:48 -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-06.txt Pages : 16 Date : 2015-07-06 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-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-as-migration-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 Jul 6 09:29: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 B16311B2F87 for ; Mon, 6 Jul 2015 09:29:16 -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 XGfYqPN5HmnA for ; Mon, 6 Jul 2015 09:29:15 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id E685D1B2F90 for ; Mon, 6 Jul 2015 09:29:14 -0700 (PDT) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.15,415,1432612800"; d="scan'208";a="904939777" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 06 Jul 2015 12:23:51 -0400 Received: from PRVPEXVS10.corp.twcable.com ([10.136.163.41]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Mon, 6 Jul 2015 12:29:13 -0400 From: "George, Wes" To: "idr@ietf.org" Date: Mon, 6 Jul 2015 12:29:13 -0400 Thread-Topic: [Idr] I-D Action: draft-ietf-idr-as-migration-06.txt Thread-Index: AdC4COUnsMpzAa1CTZmynT4AX1A+9Q== Message-ID: References: <20150706153149.29583.37991.idtracker@ietfa.amsl.com> In-Reply-To: <20150706153149.29583.37991.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.5.2.150604 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-06.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, 06 Jul 2015 16:29:16 -0000 VGhpcyB2ZXJzaW9uIGFkZHJlc3NlcyBBbHZhcm8ncyBMQyByZXZpZXcsIGFzIHdlbGwgYXMgSm9o biBTY3VkZGVyJ3MNCmNvbW1lbnRzIG1hZGUgdG8gbWUgcHJpdmF0ZWx5LiBJIGJlbGlldmUgdGhh dCB0aGlzIHZlcnNpb24gaXMgcmVhZHkgZm9yDQpJRVNHIGV2YWx1YXRpb24uDQpNeSBhcG9sb2dp ZXMgZm9yIG5vdCBnZXR0aW5nIGl0IGRvbmUgdW50aWwgdGhlIGhlaWdodCBvZiB0aGUgcHJlLW1l ZXRpbmcNCmNydXNoLg0KDQpUaGFua3MsDQoNCldlcw0KDQoNCg0KT24gNy82LzE1LCAxMTozMSBB TSwgIklkciBvbiBiZWhhbGYgb2YgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIg0KPGlkci1ib3Vu Y2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IHdyb3Rl Og0KDQo+DQo+QSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxp bmUgSW50ZXJuZXQtRHJhZnRzDQo+ZGlyZWN0b3JpZXMuDQo+IFRoaXMgZHJhZnQgaXMgYSB3b3Jr IGl0ZW0gb2YgdGhlIEludGVyLURvbWFpbiBSb3V0aW5nIFdvcmtpbmcgR3JvdXAgb2YNCj50aGUg SUVURi4NCj4NCj4gICAgICAgIFRpdGxlICAgICAgICAgICA6IEF1dG9ub21vdXMgU3lzdGVtIE1p Z3JhdGlvbiBNZWNoYW5pc21zIGFuZA0KPlRoZWlyIEVmZmVjdHMgb24gdGhlIEJHUCBBU19QQVRI IEF0dHJpYnV0ZQ0KPiAgICAgICAgQXV0aG9ycyAgICAgICAgIDogV2VzbGV5IEdlb3JnZQ0KPiAg ICAgICAgICAgICAgICAgICAgICAgICAgU2hhbmUgQW1hbnRlDQo+ICAgICAgIEZpbGVuYW1lICAg ICAgICA6IGRyYWZ0LWlldGYtaWRyLWFzLW1pZ3JhdGlvbi0wNi50eHQNCj4gICAgICAgUGFnZXMg ICAgICAgICAgIDogMTYNCj4gICAgICAgRGF0ZSAgICAgICAgICAgIDogMjAxNS0wNy0wNg0KPg0K PkFic3RyYWN0Og0KPiAgIFRoaXMgZHJhZnQgZGlzY3Vzc2VzIHNvbWUgZXhpc3RpbmcgY29tbW9u bHktdXNlZCBCR1AgbWVjaGFuaXNtcyBmb3INCj4gICBBU04gbWlncmF0aW9uIHRoYXQgYXJlIG5v dCBmb3JtYWxseSBwYXJ0IG9mIHRoZSBCR1A0IHByb3RvY29sDQo+ICAgc3BlY2lmaWNhdGlvbi4g IEl0IGlzIG5lY2Vzc2FyeSB0byBkb2N1bWVudCB0aGVzZSBkZSBmYWN0byBzdGFuZGFyZHMNCj4g ICB0byBlbnN1cmUgdGhhdCB0aGV5IGFyZSBwcm9wZXJseSBzdXBwb3J0ZWQgaW4gZnV0dXJlIEJH UCBwcm90b2NvbA0KPiAgIHdvcmsuDQo+DQo+DQo+VGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVz IHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtaWV0Zi1pZHItYXMtbWlncmF0aW9uLw0KPg0KPlRoZXJlJ3MgYWxzbyBhIGh0bWxp emVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLWlkci1hcy1taWdyYXRpb24tMDYNCj4NCj5BIGRpZmYgZnJvbSB0aGUgcHJldmlv dXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlm Zj91cmwyPWRyYWZ0LWlldGYtaWRyLWFzLW1pZ3JhdGlvbi0wNg0KPg0KPg0KPlBsZWFzZSBub3Rl IHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mDQo+ c3VibWlzc2lvbg0KPnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFp bGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+DQo+SW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2 YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj5JZHIgbWFpbGluZyBsaXN0DQo+SWRyQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZHINCg0KDQpUaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0 cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBUaW1lIFdhcm5lciBDYWJsZSBwcm9wcmlldGFyeSBp bmZvcm1hdGlvbiwgd2hpY2ggaXMgcHJpdmlsZWdlZCwgY29uZmlkZW50aWFsLCBvciBzdWJqZWN0 IHRvIGNvcHlyaWdodCBiZWxvbmdpbmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1tYWls IGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRp dHkgdG8gd2hpY2ggaXQgaXMgYWRkcmVzc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQg cmVjaXBpZW50IG9mIHRoaXMgRS1tYWlsLCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFu eSBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIGNvcHlpbmcsIG9yIGFjdGlvbiB0YWtlbiBp biByZWxhdGlvbiB0byB0aGUgY29udGVudHMgb2YgYW5kIGF0dGFjaG1lbnRzIHRvIHRoaXMgRS1t YWlsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGhh dmUgcmVjZWl2ZWQgdGhpcyBFLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRl ciBpbW1lZGlhdGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYW55 IGNvcHkgb2YgdGhpcyBFLW1haWwgYW5kIGFueSBwcmludG91dC4NCg== From nobody Mon Jul 6 11:03: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 8BEAE1A1B6E; Mon, 6 Jul 2015 11:03:46 -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 6PKsw-9AZx97; Mon, 6 Jul 2015 11:03:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E9E61A6F13; Mon, 6 Jul 2015 11:03: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.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150706180341.13233.57914.idtracker@ietfa.amsl.com> Date: Mon, 06 Jul 2015 11:03:41 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-rs-bfd-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 18:03:46 -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 : Making Route Servers Aware of Data Link Failures at IXPs Authors : Randy Bush Jeffrey Haas John G. Scudder Arnold Nipper Thomas King Filename : draft-ietf-idr-rs-bfd-01.txt Pages : 10 Date : 2015-07-06 Abstract: When route servers are used, the data plane is not congruent with the control plane. Therefore, the peers on the Internet exchange can lose data connectivity without the control plane being aware of it, and packets are dropped on the floor. This document proposes the use of BFD between the two peering routers to detect a data plane failure, and then uses BGP next hop cost to signal the state of the data link to the route server(s). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-rs-bfd/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-rs-bfd-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-rs-bfd-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 6 11:06: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 CA9E71A1BF4 for ; Mon, 6 Jul 2015 11:06:33 -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 X5KiQXTminXt for ; Mon, 6 Jul 2015 11:06:31 -0700 (PDT) Received: from de-cix.net (relay4.de-cix.net [IPv6:2a02:c50:0:1e::4:1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 339D31A1B6E for ; Mon, 6 Jul 2015 11:06:29 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.15,416,1432591200"; d="p7s'?scan'208"; a="2406494" Received: from smtp.de-cix.net ([192.168.65.10]) by mailgw012.de-cix.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Jul 2015 20:06:27 +0200 Received: from MS-EXCHANGE.for-the-inter.net (ms-exchange.for-the-inter.net [192.168.49.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by smtp.de-cix.net (Postfix) with ESMTPS id 3B86FB0096 for ; Mon, 6 Jul 2015 20:06:27 +0200 (CEST) Received: from MS-EXCHANGE.for-the-inter.net (192.168.49.2) by MS-EXCHANGE.for-the-inter.net (192.168.49.2) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Mon, 6 Jul 2015 20:06:26 +0200 Received: from MS-EXCHANGE.for-the-inter.net ([fe80::9449:4d85:69bf:3d4c]) by MS-EXCHANGE.for-the-inter.net ([fe80::9449:4d85:69bf:3d4c%12]) with mapi id 15.00.1076.000; Mon, 6 Jul 2015 20:06:26 +0200 From: Thomas King To: "idr@ietf.org" Thread-Topic: [Idr] I-D Action: draft-ietf-idr-rs-bfd-01.txt Thread-Index: AQHQuBYo5BUDIl4z80CEsVR/GlJsIp3Om0yA Date: Mon, 6 Jul 2015 18:06:26 +0000 Message-ID: <849418BE-22F3-4085-8944-3BB8559CD3F2@de-cix.net> References: <20150706180341.13233.57914.idtracker@ietfa.amsl.com> In-Reply-To: <20150706180341.13233.57914.idtracker@ietfa.amsl.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2102) x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.168.141.121] Content-Type: multipart/signed; boundary="Apple-Mail=_607F3DDE-9BC3-4CAB-9938-7304A23D1969"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 18:06:34 -0000 --Apple-Mail=_607F3DDE-9BC3-4CAB-9938-7304A23D1969 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all, this version addresses the switch from NH-Cost to BGP-LS. Best regards, Thomas > On 6 Jul 2015, at 20:03, 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 : Making Route Servers Aware of Data Link = Failures at IXPs > Authors : Randy Bush > Jeffrey Haas > John G. Scudder > Arnold Nipper > Thomas King > Filename : draft-ietf-idr-rs-bfd-01.txt > Pages : 10 > Date : 2015-07-06 >=20 > Abstract: > When route servers are used, the data plane is not congruent with = the > control plane. Therefore, the peers on the Internet exchange can > lose data connectivity without the control plane being aware of it, > and packets are dropped on the floor. This document proposes the = use > of BFD between the two peering routers to detect a data plane > failure, and then uses BGP next hop cost to signal the state of the > data link to the route server(s). >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-idr-rs-bfd/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-idr-rs-bfd-01 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-rs-bfd-01 >=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 --=20 Dr. Thomas King Manager Research & Development DE-CIX Management GmbH | Lindleystra=C3=9Fe 12 | 60314 Frankfurt am Main = | Germany | www.de-cix.net | Phone +49 69 1730902 87 | Mobile +49 175 1161428 | Fax +49 69 4056 2716 = | thomas.king@de-cix.net | Geschaeftsfuehrer Harald A. Summa | Registergericht AG Koeln HRB 51135 --Apple-Mail=_607F3DDE-9BC3-4CAB-9938-7304A23D1969 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCCBBcw ggL/oAMCAQICCwQAAAAAATGJxjDEMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNp Z24gUm9vdCBDQSAtIFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWdu MB4XDTExMDgwMjEwMDAwMFoXDTE5MDgwMjEwMDAwMFowXTELMAkGA1UEBhMCQkUxGTAXBgNVBAoT EEdsb2JhbFNpZ24gbnYtc2ExMzAxBgNVBAMTKkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIDIgQ0Eg LSBTSEEyNTYgLSBHMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKYBOgY+TD0lJ71l 7FcN0/Nzj61Z4eB/NxJMsSxhevgtUUcwxyWYkoHDl+FoQMXe8JSYraOIN7UpZvvDa9fVVpouxlnk 1upfRTHJRpU636SlHTEE5ZnXTYWQ3pTL51oEoPL4fL4OIHHO8Xe0H7X/9nw+N8tNxCCiGKRBMCcH HXuJLeW3pFUISGaVwfc2mye8mjIw+bjIJ6gtjK66WaUW6fWY323qkkS8W9uzdCXKVpGPkZUhsmqW fGlg2msfbx3O8to8LaCk0RqlVvV+g7ZrY7xBwdWGfZKCRd5R1kt2QBYOBtZfRBV7dfPMsjI4XcQU uKyTYpccj7VTvLdaf+B+TZkCAwEAAaOB6DCB5TAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgw BgEB/wIBADAdBgNVHQ4EFgQUP2xXRJ5Xn339aDnLufEa5Ll2UDgwRwYDVR0gBEAwPjA8BgRVHSAA MDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8vd3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDYG A1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvcm9vdC1yMy5jcmwwHwYD VR0jBBgwFoAUj/BLf6guRSSuTVD6Y5qL3uLdG7wwDQYJKoZIhvcNAQELBQADggEBAEWk43dt8+mP vv8ou8ZzoNxtjS0WuP0v/qiu9VX/JBjb+7X1tiWtGc2UqaUO+Y4irbiawHdgYnAXDNW1h8pCog+u z7kVIYegYhBWyQhlrn3c2sjXK+aRVFe44Ygfdmgcrj1Y7E6g9YvaGOhwZsr1IyQYkgejewpRDb+O B+3Cr5JtwJYuar3TNXrzOZnDnZSqOkvSASOlk1m5fPCYam4MdSTCJQRtz9Apcz3zcaJmlBkQsSix LzUqfPpTjheBjLoMJzhnRpZnOZiwe6J4LDrXyZqNSB5MCUIdCxWQlrt6ed8y07KPueYXPlZh0iUt vUEdL6Et8YULkFMQqQ7aAZtxBYMwggUgMIIECKADAgECAhEA2O44+rO7W3RMNf2nPhVNvTANBgkq hkiG9w0BAQsFADBdMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEzMDEG A1UEAxMqR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gMiBDQSAtIFNIQTI1NiAtIEcyMB4XDTE0MTIx NzE0MDMwNVoXDTE3MTIxNzE0MDMwNVowgaExCzAJBgNVBAYTAkRFMQwwCgYDVQQIEwNOUlcxEDAO BgNVBAcTB0NvbG9nbmUxHzAdBgNVBAoTFkRFLUNJWCBNYW5hZ2VtZW50IEdtYkgxFDASBgNVBAsT C0VuZ2luZWVyaW5nMRQwEgYDVQQDEwtUaG9tYXMgS2luZzElMCMGCSqGSIb3DQEJARYWdGhvbWFz LmtpbmdAZGUtY2l4Lm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOP1el+NQvS5 4TU/sO77bxd2pGMFw15OZIPm4ggIanvFGMo/UqUEpq4eOSQp7qhyYr4ROr1bbTGkPNEnsXn1Ogoa 0/xt2mQhpWlO4IykBN9eo09ZSuiQEWGHnKWNUevDRQpbkugZuvla8MVCWhIuDyc3JlzA8SaCVooj aKltl5qqLYf4yln61tvu44ByaKMniTzHrUvSPeEntr9ZkN477MCL3h4tp38vyvGvzEJTPv2x/i5v S2kFxNl7oSdd3TcBsevz5ui3XxXy1isO05KrVD6JTkXbZejsPRPEa6VsgeR6Q0FP833K/+7/EiYO tHfwiIAydO9wK6/u5mUX6n9MGJsCAwEAAaOCAZQwggGQMA4GA1UdDwEB/wQEAwIFoDBNBgNVHSAE RjBEMEIGCisGAQQBoDIBKAowNDAyBggrBgEFBQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5j b20vcmVwb3NpdG9yeS8wIQYDVR0RBBowGIEWdGhvbWFzLmtpbmdAZGUtY2l4Lm5ldDAJBgNVHRME AjAAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDBHBgNVHR8EQDA+MDygOqA4hjZodHRw Oi8vY3JsLmdsb2JhbHNpZ24uY29tL2dzL2dzcGVyc29uYWxzaWduMnNoYTJnMi5jcmwwWQYIKwYB BQUHAQEETTBLMEkGCCsGAQUFBzAChj1odHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2Vy dC9nc3BlcnNvbmFsc2lnbjJzaGEyZzIuY3J0MB0GA1UdDgQWBBRWuQrVK+3zTtZn1ORSIsFcQJX+ 2jAfBgNVHSMEGDAWgBQ/bFdEnlefff1oOcu58RrkuXZQODANBgkqhkiG9w0BAQsFAAOCAQEAoMDH FHReZqkQtBmjceWw09VArN6a8h4GXRRJ+Tmv3ia2u66bgBRBtmE1vEeIPoS4OtoJSbAG0WUIVucW N9HgTJS7Cq1BvjHOaW5H0qxIViY67Re0coWnWhFdlQlCcZHTHDhgejZUhOdON3wLxzAkzctT/ACp 3SYBBGyqGo+XEPITbeqN33kf29qAjd+4kNuyLrF71I60wPwnNOCZxgKqxl0mLlcYU1XSz49rqk1N xko/OnrEY5w6brxIBABdOWe4b/He596QBdum0xq9CdHIRabYRzsKvChrT+TVkEI9pRRl2zsoNg+h JKWTGgLZHpnnq/3Ktc0z3xUiJtUvyz67nDGCAwQwggMAAgEBMHIwXTELMAkGA1UEBhMCQkUxGTAX BgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExMzAxBgNVBAMTKkdsb2JhbFNpZ24gUGVyc29uYWxTaWdu IDIgQ0EgLSBTSEEyNTYgLSBHMgIRANjuOPqzu1t0TDX9pz4VTb0wCQYFKw4DAhoFAKCCAWcwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTUwNzA2MTgwNjM3WjAjBgkq hkiG9w0BCQQxFgQUQQ6zjJz004iRmOJaj/A5j+kQfTUwgYEGCSsGAQQBgjcQBDF0MHIwXTELMAkG A1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExMzAxBgNVBAMTKkdsb2JhbFNpZ24g UGVyc29uYWxTaWduIDIgQ0EgLSBTSEEyNTYgLSBHMgIRANjuOPqzu1t0TDX9pz4VTb0wgYMGCyqG SIb3DQEJEAILMXSgcjBdMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEz MDEGA1UEAxMqR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gMiBDQSAtIFNIQTI1NiAtIEcyAhEA2O44 +rO7W3RMNf2nPhVNvTANBgkqhkiG9w0BAQEFAASCAQA8zQqvSkWTsx3iZOIp5puCJEQ0C7UQcVDu bTTfKThodQNBBlQPsRY+r6G2bQlfMTXJIOCPr/dscVZL1vrfdjVzx0K/cgVmumGjJ5ALjiQ4nXOX //LU/BA4zNCt8I6vt3Fbhti2y4D7O2ZI6vFBXRLLEKixLYLvSGIQnLbML5jd0laZt7LNwCRT8p7H ZCOTjk/vrHhZHe0T4Tg/91odaVEqG/q13LIC1FwMxQHgpIJXMccPOE5HHgbtxLnY5W3CeWSPnFd0 sjucwVBccmlrPx67fpckFX6zBD23zb+eWHXzfYslefZpd3iDlQCHYqljin9cC5ehH+HZ2G85ZTf2 owIhAAAAAAAA --Apple-Mail=_607F3DDE-9BC3-4CAB-9938-7304A23D1969-- From nobody Mon Jul 6 12:34: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 C828A1B30B8; Mon, 6 Jul 2015 12:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gkVww4eGOE-v; Mon, 6 Jul 2015 12:34:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EDB31B30BB; Mon, 6 Jul 2015 12:34: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.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150706193401.4967.9031.idtracker@ietfa.amsl.com> Date: Mon, 06 Jul 2015 12:34:01 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-model-00.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, 06 Jul 2015 19:34:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : BGP Model for Service Provider Networks Authors : Anees Shaikh Rob Shakir Keyur Patel Susan Hares Kevin D'Souza Deepak Bansal Alexander Clemm Aleksandr Zhdankin Mahesh Jethanandani Xyfeng Liu Filename : draft-ietf-idr-bgp-model-00.txt Pages : 76 Date : 2015-07-06 Abstract: This document defines a YANG data model for configuring and managing BGP, including protocol, policy, and operational aspects based on data center, carrier and content provider operational requirements. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-model/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-bgp-model-00 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 Jul 6 13:13: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 15FCA1B31C3 for ; Mon, 6 Jul 2015 13:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=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 4F_K9TRGgsjA for ; Mon, 6 Jul 2015 13:13:53 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3B391B31B8 for ; Mon, 6 Jul 2015 13:13:52 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 27D3322C0EA for ; Mon, 6 Jul 2015 22:13:51 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.60]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 0DDD1238059 for ; Mon, 6 Jul 2015 22:13:51 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM7F.corporate.adroot.infra.ftgroup ([fe80::c1d7:e278:e357:11ad%19]) with mapi id 14.03.0235.001; Mon, 6 Jul 2015 22:13:50 +0200 From: To: idr wg list Thread-Topic: draft-decraene-idr-next-hop-capability-01.txt Thread-Index: AdC4JKDYgB3/Q9Q9R2OEO/XZ5rMOTw== Date: Mon, 6 Jul 2015 20:13:50 +0000 Message-ID: <29278_1436213631_559AE17F_29278_100_1_53C29892C857584299CBF5D05346208A0F5DF256@OPEXCLILM21.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.168.234.5] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.7.2.125417 Archived-At: Subject: [Idr] draft-decraene-idr-next-hop-capability-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 20:13:55 -0000 SGkgYWxsLA0KDQpQbGVhc2UgZmluZCBiZWxvdyBhbiB1cGRhdGVkIHZlcnNpb24gb2YgdGhlIGRy YWZ0IHByZXNlbnRlZCBpbiBEYWxsYXMuDQoNCk1haW4gY2hhbmdlcyBhcmUgdGhlIGZvbGxvd2lu ZzoNCi0gTmV3IGNvLWF1dGhvcnM6IEtpcmVldGkgS29tcGVsbGEsICBXaW0gSGVuZGVyaWNreA0K LSBTbGlnaHRseSBpbXByb3ZlZCAiZXJyb3IgaGFuZGxpbmciIHNlY3Rpb24gb2YgdGhlIEJHUCBh dHRyaWJ1dGUNCi0gTmV3IHNlY3Rpb24gZGVmaW5pbmcgdGhlICJlcnJvciBoYW5kbGluZyIgb2Yg dGhlIE1QTFMgRW50cm9weSBMYWJlbCBCR1AgTmV4dC1Ib3AgQ2FwYWJpbGl0eS4NCi0gU29tZSBy ZS1yZXdvcmRpbmcgb2YgdGhlICJFbnRyb3B5IExhYmVsIE5leHQtSG9wIENhcGFiaWxpdHkiIHNl Y3Rpb24NCgktIC0wMCB3YXMgbW9zdGx5IGEgY29weSBwYXN0IGZyb20gUkZDIDY3OTAgKHdoaWNo IGRlZmluZXMgdGhlIE1QTFMgRW50cm9weSBMYWJlbCAmIHRoZSBvcmlnaW5hbCBhbmQgbm93IGRl cHJlY2F0ZWQgQkdQIGF0dHJpYnV0ZSkNCgktIC0wMSBpcyBleHBlY3RlZCB0byBiZSBtb3JlIHBy ZWNpc2UgdGhhbmtzIHRvIGNvbW1lbnRzIGZyb20gRXJpYyBSb3NlbiAobWFueSB0aGFua3MpDQot IE5ldyBzZWN0aW9uIDQgIkJHUCBOZXh0LUhvcCBDYXBhYmlsaXR5IENvZGUgT3BlcmF0aW9uIg0K CS0gTm90aGluZyBvdXRzdGFuZGluZywgYnV0IGJldHRlciB3aGVuIGV4cGxpY2l0bHkgc3RhdGVk CSANCi0gQWRkaXRpb24gb2YgdGhlIG9wdGlvbmFsIGFiaWxpdHkgdG8gYWR2ZXJ0aXNlIHRoZSAi UmVhZGFibGUgTGFiZWwgRGVwdGgiIG9mIHRoZSBMU1AocykgYWR2ZXJ0aXNlZCBpbiB0aGUgTkxS SQ0KCS0gU3RpbGwgbmVlZCBzb21lIHBvbGlzaGluZw0KLSBJbXByb3ZlZCB3b3JkaW5nLCBzb21l IHR5cG8gY29ycmVjdGVkDQoNCg0KRGlmZjogICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3Jn L3JmY2RpZmY/dXJsMj1kcmFmdC1kZWNyYWVuZS1pZHItbmV4dC1ob3AtY2FwYWJpbGl0eS0wMQ0K DQoNCkNvbW1lbnRzIHdlbGNvbWVkLg0KDQpJbiBwYXJ0aWN1bGFyLCB0aGUgbmFtZSBvZiB0aGUg QkdQIEF0dHJpYnV0ZSBjb3VsZCBoYXZlIGEgYmV0dGVyIG5hbWUgKHRvIGJlIHByb3Bvc2VkKToN CgktIEN1cnJlbnRseSBjYWxsZWQgTmV4dC1Ib3AgQ2FwYWJpbGl0eQ0KCS0gQnV0IHRoZSBjYXBh YmlsaXR5IGlzIG5vdCBvbmx5IE5leHQtSG9wIHNwZWNpZmljIGJ1dCBtb3JlIHByZWNpc2VseSBO ZXh0LUhvcCBBTkQgcGF0aCBzcGVjaWZpYy4gSW4gcGFydGljdWxhciwgZm9yIGRpZmZlcmVudCBV UERBVEUgaGF2aW5nIHRoZSBzYW1lIE5leHQtSG9wLCB0aGUgY2FwYWJpbGl0eSBtYXkgYmUgZGlm ZmVyZW50Lg0KCS0gSeKAmWQgd2VsY29tZSBhbnkgc3VnZ2VzdGlvbiBvZiBuYW1lLg0KCQktIFdl IHByb2JhYmx5IHdhbnQgdG8ga2VlcCB0aGUgdGVybSAiTmV4dC1Ib3AiIHNvbWV3aGVyZSBhcyB0 aGlzIGlzIGEga2V5IHByb3BlcnR5IG9mIHRoZSBCR1AgYXR0cmlidXRlIHdoaWNoIGlzIHJlbW92 ZWQgd2hlbiB0aGUgTmV4dC1Ib3AgaXMgY2hhbmdlZC4NCg0KDQpUaGFua3MsDQpSZWdhcmRzLA0K QnJ1bm8NCg0KUFM6IGxvbmcgKGJvcmluZykgZW1haWwsIGJ1dCB5b3Ugc2F2ZWQgYSAoYm9yaW5n KSBwcmVzZW50YXRpb24gaW4gUHJhZ3Vlcw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K RnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGll dGYub3JnXSANClNlbnQ6IE1vbmRheSwgSnVseSAwNiwgMjAxNSA5OjQ2IFBNDQpUbzogV2ltIEhl bmRlcmlja3g7IEtpcmVldGkgS29tcGVsbGE7IEtpcmVldGkgS29tcGVsbGE7IERFQ1JBRU5FIEJy dW5vIElNVC9PTE47IFdpbSBIZW5kZXJpY2t4OyBERUNSQUVORSBCcnVubyBJTVQvT0xODQpTdWJq ZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWRlY3JhZW5lLWlkci1uZXh0 LWhvcC1jYXBhYmlsaXR5LTAxLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1k ZWNyYWVuZS1pZHItbmV4dC1ob3AtY2FwYWJpbGl0eS0wMS50eHQNCmhhcyBiZWVuIHN1Y2Nlc3Nm dWxseSBzdWJtaXR0ZWQgYnkgQnJ1bm8gRGVjcmFlbmUgYW5kIHBvc3RlZCB0byB0aGUgSUVURiBy ZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQtZGVjcmFlbmUtaWRyLW5leHQtaG9wLWNhcGFiaWxp dHkNClJldmlzaW9uOgkwMQ0KVGl0bGU6CQlCR1AgTmV4dC1Ib3AgQ2FwYWJpbGl0aWVzDQpEb2N1 bWVudCBkYXRlOgkyMDE1LTA3LTA2DQpHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFn ZXM6CQkxMA0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRy YWZ0cy9kcmFmdC1kZWNyYWVuZS1pZHItbmV4dC1ob3AtY2FwYWJpbGl0eS0wMS50eHQNClN0YXR1 czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1kZWNyYWVu ZS1pZHItbmV4dC1ob3AtY2FwYWJpbGl0eS8NCkh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtZGVjcmFlbmUtaWRyLW5leHQtaG9wLWNhcGFiaWxpdHktMDEN CkRpZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQt ZGVjcmFlbmUtaWRyLW5leHQtaG9wLWNhcGFiaWxpdHktMDENCg0KQWJzdHJhY3Q6DQogICBSRkMg NTQ5MiBkZWZpbmVzIGNhcGFiaWxpdGllcyBhZHZlcnRpc2VtZW50IGZvciB0aGUgQkdQIHBlZXIu ICBJbg0KICAgYWRkaXRpb24sIGl0IGlzIHVzZWZ1bCB0byBrbm93IHRoZSBjYXBhYmlsaXRpZXMg b2YgdGhlIEJHUCBOZXh0LUhvcCwNCiAgIGluIHBhcnRpY3VsYXIgZm9yIGZvcndhcmRpbmcgcGxh bmUgZmVhdHVyZXMuICBSRkMgNTQ5MiBpcyBub3QNCiAgIGFwcGxpY2FibGUgYmVjYXVzZSB0aGUg QkdQIHBlZXIgbWF5IGJlIGRpZmZlcmVudCBmcm9tIHRoZSBCR1AgTmV4dC0NCiAgIEhvcCwgaW4g cGFydGljdWxhciB3aGVuIEJHUCBSb3V0ZSBSZWZsZWN0aW9uIGlzIHVzZWQuICBUaGlzIGRvY3Vt ZW50DQogICBkZWZpbmVzIGEgbWVjaGFuaXNtIHRvIGFkdmVydGlzZSBzdWNoIEJHUCBOZXh0IEhv cCBDYXBhYmlsaXRpZXMuDQoNCiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIG5ldyBCR1Agbm9u LXRyYW5zaXRpdmUgYXR0cmlidXRlIHRvIGNhcnJ5DQogICBOZXh0LUhvcCBDYXBhYmlsaXRpZXMu ICBUaGlzIGF0dHJpYnV0ZSBpcyBkZWxldGVkIHdoZW4gdGhlIEJHUCBOZXh0DQogICBIb3AgaXMg Y2hhbmdlZC4NCg0KICAgVGhpcyBkb2N1bWVudCBhbHNvIGRlZmluZXMgYSBOZXh0LUhvcCBjYXBh YmlsaXR5IHRvIGFkdmVydGlzZSB0aGUNCiAgIGFiaWxpdHkgdG8gaGFuZGxlIHRoZSBFbnRyb3B5 IExhYmVsIGRlZmluZWQgaW4gUkZDIDY3OTAuDQoNCg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBm cm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5k IGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0 YXJpYXQNCg0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZl bnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdp ZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNv cGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIg ZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWly ZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVl cyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSBy ZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxz aWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFp biBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90 ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29w aWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFp bCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNz YWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3Jhbmdl IGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFu Z2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK From nobody Mon Jul 6 13:36: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 335801B3202; Mon, 6 Jul 2015 13:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ij1y4VHKfAql; Mon, 6 Jul 2015 13:36:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA8A1B320F; Mon, 6 Jul 2015 13:36:50 -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.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150706203650.6815.83256.idtracker@ietfa.amsl.com> Date: Mon, 06 Jul 2015 13:36:50 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-extended-messages-10.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, 06 Jul 2015 20:36:53 -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 : Extended Message support for BGP Authors : Keyur Patel Dave Ward Randy Bush Filename : draft-ietf-idr-bgp-extended-messages-10.txt Pages : 5 Date : 2015-07-06 Abstract: The BGP specification mandates a maximum BGP message size of 4096 octets. As BGP is extended to support newer AFI/SAFIs, there is a need to extend the maximum message size beyond 4096 octets. This document updates [RFC4271] by providing an extension to BGP to extend its current message size from 4096 octets to 65535 octets. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-bgp-extended-messages-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-extended-messages-10 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 Jul 6 13:43: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 361911B3230 for ; Mon, 6 Jul 2015 13:43:23 -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 6nj8nMTFu7jJ for ; Mon, 6 Jul 2015 13:43:22 -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 4DC2B1B3228 for ; Mon, 6 Jul 2015 13:43:22 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1ZCDEW-0006ic-T4 for idr@ietf.org; Mon, 06 Jul 2015 20:43:21 +0000 Date: Tue, 07 Jul 2015 05:43:19 +0900 Message-ID: From: Randy Bush To: idr wg list In-Reply-To: <20150706203650.6815.83256.idtracker@ietfa.amsl.com> References: <20150706203650.6815.83256.idtracker@ietfa.amsl.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: Subject: Re: [Idr] I-D Action: draft-ietf-idr-bgp-extended-messages-10.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, 06 Jul 2015 20:43:23 -0000 no change, just a refresh From nobody Mon Jul 6 14:02:02 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 DA07F1B3250 for ; Mon, 6 Jul 2015 14:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.212 X-Spam-Level: X-Spam-Status: No, score=-4.212 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 vdybukdXcWw3 for ; Mon, 6 Jul 2015 14:01:59 -0700 (PDT) Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF1C91B3241 for ; Mon, 6 Jul 2015 14:01:59 -0700 (PDT) Received: by guelah.shrubbery.net (Postfix, from userid 7053) id 3BA9284203; Mon, 6 Jul 2015 21:01:59 +0000 (UTC) Date: Mon, 6 Jul 2015 21:01:59 +0000 From: heasley To: Randy Bush Message-ID: <20150706210159.GC13743@shrubbery.net> References: <20150706203650.6815.83256.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc X-note: live free, or die! X-homer: i just want to have a beer while i am caring. X-Claimation: an engineer needs a manager like a fish needs a bicycle X-reality: only YOU can put an end to the embarrassment that is Tom Cruise User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: idr wg list Subject: Re: [Idr] I-D Action: draft-ietf-idr-bgp-extended-messages-10.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, 06 Jul 2015 21:02:01 -0000 Tue, Jul 07, 2015 at 05:43:19AM +0900, Randy Bush: > no change, just a refresh why has this not yet graduated to rfc? From nobody Mon Jul 6 14:04: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 C05761B328A for ; Mon, 6 Jul 2015 14:04:48 -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 Zy3cmNRvA-hE for ; Mon, 6 Jul 2015 14:04:47 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (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 7F6FC1B3278 for ; Mon, 6 Jul 2015 14:04:47 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.203.226; From: "Susan Hares" To: "'heasley'" , "'Randy Bush'" References: <20150706203650.6815.83256.idtracker@ietfa.amsl.com> <20150706210159.GC13743@shrubbery.net> In-Reply-To: <20150706210159.GC13743@shrubbery.net> Date: Mon, 6 Jul 2015 17:04:41 -0400 Message-ID: <027801d0b82f$60ad05b0$22071110$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGBfyn0a/XgdWqa5S7LQAUhGp5VDwJoZzRkAL6c2DyeVCgogA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'idr wg list' Subject: Re: [Idr] I-D Action: draft-ietf-idr-bgp-extended-messages-10.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, 06 Jul 2015 21:04:48 -0000 Dave: It is waiting for 2 implementations. If you know of the 2 implementations, I will start the process. Sue -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of heasley Sent: Monday, July 06, 2015 5:02 PM To: Randy Bush Cc: idr wg list Subject: Re: [Idr] I-D Action: draft-ietf-idr-bgp-extended-messages-10.txt Tue, Jul 07, 2015 at 05:43:19AM +0900, Randy Bush: > no change, just a refresh why has this not yet graduated to rfc? _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From nobody Mon Jul 6 18:07: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 B52F61A87D1 for ; Mon, 6 Jul 2015 18:07:37 -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 TxCcQSdSgDII for ; Mon, 6 Jul 2015 18:07:36 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (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 573521A87C9 for ; Mon, 6 Jul 2015 18:07:36 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.203.226; From: "Susan Hares" To: "'idr wg list'" Date: Mon, 6 Jul 2015 21:07:34 -0400 Message-ID: <02ce01d0b851$4ecec5a0$ec6c50e0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02CF_01D0B82F.C7C032E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdC4UJG6Pj+U9ACORa+TFqfDTB54Dg== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: "'Keyur Patel \(keyupate\)'" Subject: [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00.txt (7/6 to 7/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 Jul 2015 01:07:37 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02CF_01D0B82F.C7C032E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This begins a 2 week adoption call on draft-rosen-idr-tunnel-encaps-00.txt (7/6 to 7/20/2015). The draft can be found at: https://www.ietf.org/internet-drafts/draft-rosen-idr-tunnel-encaps-00.txt In your response, discuss why this draft proposal for encapsulation: a) [operators] will help deployed networks, b) Solves know problems with other tunnel encapsulation, and c) Provides a way to manage the matrix of tunnels. We will have a status report at IDR on 7/20 on this Working group adoption call. Sue Hares and John Scudder ------=_NextPart_000_02CF_01D0B82F.C7C032E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This begins a 2 week adoption call on = draft-rosen-idr-tunnel-encaps-00.txt (7/6 to = 7/20/2015).

The draft can be found at:

 

https://www.ietf.org/internet-drafts/draft-rosen-idr-tunnel-enc= aps-00.txt

 =

In your = response, discuss why this draft proposal for = encapsulation:

a)      = [operators]= will help deployed networks,

b)      = Solves = know problems with other tunnel encapsulation, and =

c)       = Provides a = way to manage the matrix of tunnels.

 =

 =

We will = have a status report at IDR on 7/20 on this Working group adoption call. =

 =

Sue Hares = and John Scudder

------=_NextPart_000_02CF_01D0B82F.C7C032E0-- From nobody Mon Jul 6 18:15: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 024801A8831 for ; Mon, 6 Jul 2015 18:15:37 -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 RfKiuopaEoup for ; Mon, 6 Jul 2015 18:15:36 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (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 775251A87E2 for ; Mon, 6 Jul 2015 18:15:35 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.203.226; From: "Susan Hares" To: "'idr wg list'" Date: Mon, 6 Jul 2015 21:15:35 -0400 Message-ID: <02f801d0b852$6dca2de0$495e89a0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02F9_01D0B830.E6B90310" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdC4UkgAnN4c3NfvQwCXd3kJpkw/Pw== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [Idr] Agenda for IETF 93 is online 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 Jul 2015 01:15:37 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02F9_01D0B830.E6B90310 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The agenda for IDR at IETF 93 is online. There are 3 slots available on Friday (11:50-13:20). Sue ------=_NextPart_000_02F9_01D0B830.E6B90310 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The agenda = for IDR at IETF 93 is online.  There are 3 slots available on = Friday (11:50-13:20).

 

Sue =

------=_NextPart_000_02F9_01D0B830.E6B90310-- From nobody Mon Jul 6 19:46: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 96FC81A8712 for ; Mon, 6 Jul 2015 19:45:59 -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 mJzVbYr55Pqb for ; Mon, 6 Jul 2015 19:45:58 -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 0477F1A873A for ; Mon, 6 Jul 2015 19:45:57 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BUU05254; Tue, 07 Jul 2015 02:45:56 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 7 Jul 2015 03:45:55 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.233]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Tue, 7 Jul 2015 10:45:52 +0800 From: Haoweiguo To: Susan Hares , "'idr wg list'" Thread-Topic: [Idr] Agenda for IETF 93 is online Thread-Index: AdC4UkgAnN4c3NfvQwCXd3kJpkw/PwAC/7NO Date: Tue, 7 Jul 2015 02:45:51 +0000 Message-ID: References: <02f801d0b852$6dca2de0$495e89a0$@ndzh.com> In-Reply-To: <02f801d0b852$6dca2de0$495e89a0$@ndzh.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.23.94] Content-Type: multipart/alternative; boundary="_000_DD5FC8DE455C3348B94340C0AB5517334F87F692nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Idr] Agenda for IETF 93 is online 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 Jul 2015 02:45:59 -0000 --_000_DD5FC8DE455C3348B94340C0AB5517334F87F692nkgeml501mbschi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Sue, I would like to request three sessions as follows: 1. draft-hao-idr-ls-trill-01 Slot: 10 mins Presenter: Donald Eastlake 2. draft-hao-idr-flowspec-nvo3-00 Slot: 5 mins Presenter: Weiguo Hao 3. draft-ietf-idr-flowspec-l2vpn-01 Slot: 5 mins Presenter: Weiguo Hao Thanks, weiguo ________________________________ From: Idr [idr-bounces@ietf.org] on behalf of Susan Hares [shares@ndzh.com] Sent: Tuesday, July 07, 2015 9:15 To: 'idr wg list' Subject: [Idr] Agenda for IETF 93 is online The agenda for IDR at IETF 93 is online. There are 3 slots available on Fr= iday (11:50-13:20). Sue --_000_DD5FC8DE455C3348B94340C0AB5517334F87F692nkgeml501mbschi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Sue,

I would like to request three sessions= as follows:

1. draft-hao-idr-ls-trill-01  

     Slot: 10= mins

     Presenter: Do= nald Eastlake

2. draft-hao-idr-flowspec-nvo3-= 00

     Slot: 5 mins<= /font>

     Presenter: We= iguo Hao

3. draft-ietf-idr-flowspec-l2vpn-01

    Slot: 5 mins=

    Presenter: Weiguo H= ao

 

Thanks,

weiguo

From: Idr [idr-bounces@ietf.org] on behalf= of Susan Hares [shares@ndzh.com]
Sent: Tuesday, July 07, 2015 9:15
To: 'idr wg list'
Subject: [Idr] Agenda for IETF 93 is online

The agenda for IDR at IETF 93 is online.  There= are 3 slots available on Friday (11:50-13:20).

 

Sue

--_000_DD5FC8DE455C3348B94340C0AB5517334F87F692nkgeml501mbschi_-- From nobody Tue Jul 7 01:22: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 94F3D1A1BC9; Tue, 7 Jul 2015 01:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.86 X-Spam-Level: X-Spam-Status: No, score=-96.86 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 f4UHDIcU0F44; Tue, 7 Jul 2015 01:21:59 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id C62D01A1BB1; Tue, 7 Jul 2015 01:21:58 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 9271C55D7464F; Tue, 7 Jul 2015 16:18:13 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id D1FE62C6B3F93; Tue, 7 Jul 2015 16:21:52 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id t678DIFn006630; Tue, 7 Jul 2015 16:13:22 +0800 (GMT-8) (envelope-from zhang.zheng@zte.com.cn) In-Reply-To: <02f801d0b852$6dca2de0$495e89a0$@ndzh.com> To: "Susan Hares" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: zhang.zheng@zte.com.cn Date: Tue, 7 Jul 2015 16:13:08 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2015-07-07 16:13:06, Serialize complete at 2015-07-07 16:13:06 Content-Type: multipart/alternative; boundary="=_alternative 002D28AB48257E7B_=" X-MAIL: mse01.zte.com.cn t678DIFn006630 Archived-At: Cc: 'idr wg list' , Idr Subject: [Idr] =?gb2312?b?tPC4tDogIEFnZW5kYSBmb3IgSUVURiA5MyBpcyBvbmxpbmU=?= 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 Jul 2015 08:22:00 -0000 This is a multipart message in MIME format. --=_alternative 002D28AB48257E7B_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgU3VlLA0KICAgIEkgd291bGQgbGlrZSB0byByZXF1ZXN0IG9uZSBzZXNzaW9uOg0KICAgZHJh ZnQtemhhbmctaWRyLXVwc3RyZWFtLWFzc2lnbmVkLWxhYmVsLXNvbHV0aW9uLTAwIA0KICAgU2xv dDogMTAgbWlucw0KICAgUHJlc2VudGVyOiBTYW5keSBaaGFuZw0KVGhhbmtzLA0KU2FuZHkNCg0K DQoNCg0KDQoiU3VzYW4gSGFyZXMiIDxzaGFyZXNAbmR6aC5jb20+IA0Kt6K8/sjLOiAgIklkciIg PGlkci1ib3VuY2VzQGlldGYub3JnPg0KMjAxNS8wNy8wNyAwOToxNQ0KDQrK1bz+yMsNCiInaWRy IHdnIGxpc3QnIiA8aWRyQGlldGYub3JnPg0Ks63LzQ0KDQrW98ziDQpbSWRyXSBBZ2VuZGEgZm9y IElFVEYgOTMgaXMgb25saW5lDQoNCg0KDQoNCg0KDQpUaGUgYWdlbmRhIGZvciBJRFIgYXQgSUVU RiA5MyBpcyBvbmxpbmUuICBUaGVyZSBhcmUgMyBzbG90cyBhdmFpbGFibGUgb24gDQpGcmlkYXkg KDExOjUwLTEzOjIwKS4gDQogDQpTdWUgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCklkciBtYWlsaW5nIGxpc3QNCklkckBpZXRmLm9yZw0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZHINCg0KDQo= --=_alternative 002D28AB48257E7B_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPkhpIFN1ZSw8L2ZvbnQ+DQo8cD48Zm9u dCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7ICZuYnNwOyBJIHdvdWxkIGxpa2UgdG8gcmVx dWVzdCBvbmUNCnNlc3Npb246PC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmki PiZuYnNwOyAmbmJzcDtkcmFmdC16aGFuZy1pZHItdXBzdHJlYW0tYXNzaWduZWQtbGFiZWwtc29s dXRpb24tMDANCiZuYnNwOyA8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+ Jm5ic3A7ICZuYnNwO1Nsb3Q6IDEwIG1pbnM8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTIgZmFjZT0i Q2FsaWJyaSI+Jm5ic3A7ICZuYnNwO1ByZXNlbnRlcjogU2FuZHkgWmhhbmc8L2ZvbnQ+DQo8cD48 Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+VGhhbmtzLDwvZm9udD4NCjxwPjxmb250IHNpemU9 MiBmYWNlPSJDYWxpYnJpIj5TYW5keTwvZm9udD4NCjxwPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJy Pg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0zNiU+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPiZxdW90O1N1c2FuIEhhcmVzJnF1b3Q7DQom bHQ7c2hhcmVzQG5kemguY29tJmd0OzwvYj4gPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNl PSJzYW5zLXNlcmlmIj63orz+yMs6ICZuYnNwOyZxdW90O0lkciZxdW90OyAmbHQ7aWRyLWJvdW5j ZXNAaWV0Zi5vcmcmZ3Q7PC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi PjIwMTUvMDcvMDcgMDk6MTU8L2ZvbnQ+DQo8dGQgd2lkdGg9NjMlPg0KPHRhYmxlIHdpZHRoPTEw MCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7J2lkciB3ZyBsaXN0JyZxdW90OyAmbHQ7aWRyQGlldGYu b3JnJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD4NCjx0 ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fu cy1zZXJpZiI+W0lkcl0gQWdlbmRhIGZvciBJRVRGIDkzIGlzIG9ubGluZTwvZm9udD48L3RhYmxl Pg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxi cj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5U aGUgYWdlbmRhIGZvciBJRFIgYXQgSUVURiA5MyBpcyBvbmxpbmUuDQombmJzcDtUaGVyZSBhcmUg MyBzbG90cyBhdmFpbGFibGUgb24gRnJpZGF5ICgxMTo1MC0xMzoyMCkuIDwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJDYWxpYnJpIj5TdWUgPC9mb250Pjxmb250IHNpemU9Mj48dHQ+X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpJZHIgbWFpbGluZyBsaXN0 PGJyPg0KSWRyQGlldGYub3JnPGJyPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9pZHI8YnI+DQo8L3R0PjwvZm9udD4NCjxicj4NCg== --=_alternative 002D28AB48257E7B_=-- From nobody Tue Jul 7 06:33: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 4E3E81A8895; Tue, 7 Jul 2015 06:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -93.104 X-Spam-Level: X-Spam-Status: No, score=-93.104 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, 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 ItOskSnPgbYt; Tue, 7 Jul 2015 06:33:42 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (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 7E1AC1A8879; Tue, 7 Jul 2015 06:33:42 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.203.226; From: "Susan Hares" To: References: <02f801d0b852$6dca2de0$495e89a0$@ndzh.com> In-Reply-To: Date: Tue, 7 Jul 2015 09:33:33 -0400 Message-ID: <043801d0b8b9$852bdfd0$8f839f70$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0439_01D0B897.FE1D4D10" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGhH78XsApT/oLXjKdpAq0H2eXAXJ4vM2lw Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'idr wg list' , 'Idr' Subject: Re: [Idr] =?gb2312?b?tPC4tDogIEFnZW5kYSBmb3IgSUVURiA5MyBpcyBvbmxpbmU=?= 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 Jul 2015 13:33:44 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0439_01D0B897.FE1D4D10 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: quoted-printable Sandy: =20 I have assigned you a time slot on Friday 7/25/2015. =20 Sue=20 =20 From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of = zhang.zheng@zte.com.cn Sent: Tuesday, July 07, 2015 4:13 AM To: Susan Hares Cc: 'idr wg list'; Idr Subject: [Idr] =B4=F0=B8=B4: Agenda for IETF 93 is online =20 Hi Sue,=20 I would like to request one session:=20 draft-zhang-idr-upstream-assigned-label-solution-00 =20 Slot: 10 mins=20 Presenter: Sandy Zhang=20 Thanks,=20 Sandy=20 "Susan Hares" =20 =B7=A2=BC=FE=C8=CB: "Idr" =20 2015/07/07 09:15=20 =CA=D5=BC=FE=C8=CB "'idr wg list'" =20 =B3=AD=CB=CD =09 =D6=F7=CC=E2 [Idr] Agenda for IETF 93 is online =20 =09 The agenda for IDR at IETF 93 is online. There are 3 slots available on Friday (11:50-13:20).=20 =20 Sue _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr ------=_NextPart_000_0439_01D0B897.FE1D4D10 Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: quoted-printable

Sandy:

 

I have assigned you a time slot on Friday = 7/25/2015.

 

Sue

 

From:= = Idr [mailto:idr-bounces@ietf.org] On Behalf Of = zhang.zheng@zte.com.cn
Sent: Tuesday, July 07, 2015 4:13 = AM
To: Susan Hares
Cc: 'idr wg list'; = Idr
Subject: [Idr] =B4=F0=B8=B4: Agenda = for IETF 93 is online

 


Hi = Sue,

  =   I would like to request one session: =

  =  draft-zhang-idr-upstream-assigned-label-solution-00   =

  =  Slot: 10 mins

  =  Presenter: Sandy Zhang

Thanks,

Sandy




"Susan = Hares" <shares@ndzh.com> =
=B7=A2=BC=FE=C8=CB: =  "Idr" <idr-bounces@ietf.org> =

2015/07/07 = 09:15

"'idr wg = list'" <idr@ietf.org> =

=CA=D5=BC=FE=C8=CB

=B3=AD=CB=CD

=D6=F7=CC=E2

[Idr] Agenda = for IETF 93 is online

 




The agenda = for IDR at IETF 93 is online.  There are 3 slots available on = Friday (11:50-13:20).
 
Sue = _______________________________________________
Id= r mailing list
Idr@ietf.org
https://www.ietf.org/m= ailman/listinfo/idr

------=_NextPart_000_0439_01D0B897.FE1D4D10-- From nobody Tue Jul 7 06:48: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 C0CCA1A9037 for ; Tue, 7 Jul 2015 06:48:18 -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, 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 DlvItOtBfN_Z for ; Tue, 7 Jul 2015 06:48:11 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DB8A1A0266 for ; Tue, 7 Jul 2015 06:48:11 -0700 (PDT) X-Envelope-To: Received: from crumpet.local (089-101-195154.ntlworld.ie [89.101.195.154] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.1/8.14.9) with ESMTPSA id t67Dm9BN027817 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 7 Jul 2015 14:48:09 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host 089-101-195154.ntlworld.ie [89.101.195.154] (may be forged) claimed to be crumpet.local To: IETF IDR Working Group From: Nick Hilliard X-Enigmail-Draft-Status: N1110 Message-ID: <559BD899.7030701@foobar.org> Date: Tue, 7 Jul 2015 14:48:09 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [Idr] draft-ietf-idr-ix-bgp-route-server 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 Jul 2015 13:48:18 -0000 Hi, draft-ietf-idr-ix-bgp-route-server seems to have been stuck in "Waiting for Write-Up" state since last March. Is there any chance of getting the ID unstuck from this state? Nick From nobody Tue Jul 7 06:50:49 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 A00931A90B2 for ; Tue, 7 Jul 2015 06:50:47 -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 jWB3dYyDBdJ2 for ; Tue, 7 Jul 2015 06:50:46 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (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 9D1F31A8763 for ; Tue, 7 Jul 2015 06:50:46 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.203.226; From: "Susan Hares" To: "'idr wg list'" Date: Tue, 7 Jul 2015 09:50:47 -0400 Message-ID: <046d01d0b8bb$edbd84c0$c9388e40$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_046E_01D0B89A.66ABE4C0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdC4u7j7lQiDcrFIQ7qvk2S+fmPV7w== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [Idr] New Agenda posted for IDR at IETF 93 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 Jul 2015 13:50:47 -0000 This is a multipart message in MIME format. ------=_NextPart_000_046E_01D0B89A.66ABE4C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I've posted a new agenda for IDR at IETF. For those who requested a time slot, please review the schedule. Let me know if you are missing from the agenda. Sue Hares ------=_NextPart_000_046E_01D0B89A.66ABE4C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’ve = posted a new agenda for IDR at IETF. 

 

For those = who requested a time slot, please review the schedule. Let me know if = you are missing from the agenda.

 

Sue Hares =

------=_NextPart_000_046E_01D0B89A.66ABE4C0-- From nobody Tue Jul 7 06:52: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 8A87D1A8763 for ; Tue, 7 Jul 2015 06:51:58 -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 xKfkorYJIC-K for ; Tue, 7 Jul 2015 06:51:54 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (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 3A6771A01EC for ; Tue, 7 Jul 2015 06:51:54 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.203.226; From: "Susan Hares" To: "'Nick Hilliard'" , "'IETF IDR Working Group'" References: <559BD899.7030701@foobar.org> In-Reply-To: <559BD899.7030701@foobar.org> Date: Tue, 7 Jul 2015 09:51:44 -0400 Message-ID: <047e01d0b8bc$102c8560$30859020$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMD1r97tJd1Evpq5wGOKO2ncSdQwJtpymkw Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] draft-ietf-idr-ix-bgp-route-server 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 Jul 2015 13:51:58 -0000 Nick: I apologize. This one is my fault. It is my goal today to get it unstuck by writing that report. Sue -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Nick Hilliard Sent: Tuesday, July 07, 2015 9:48 AM To: IETF IDR Working Group Subject: [Idr] draft-ietf-idr-ix-bgp-route-server Hi, draft-ietf-idr-ix-bgp-route-server seems to have been stuck in "Waiting for Write-Up" state since last March. Is there any chance of getting the ID unstuck from this state? Nick _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From nobody Tue Jul 7 06:56:02 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 9605D1AC3CF for ; Tue, 7 Jul 2015 06:56:01 -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 Bhv4zkkj7Ngn for ; Tue, 7 Jul 2015 06:55:59 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0102.outbound.protection.outlook.com [65.55.169.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 034451A902A for ; Tue, 7 Jul 2015 06:55:58 -0700 (PDT) Received: from BLUPR05MB562.namprd05.prod.outlook.com (10.141.202.141) by BLUPR05MB563.namprd05.prod.outlook.com (10.141.202.144) with Microsoft SMTP Server (TLS) id 15.1.207.19; Tue, 7 Jul 2015 13:55:57 +0000 Received: from BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) by BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) with mapi id 15.01.0207.004; Tue, 7 Jul 2015 13:55:57 +0000 From: John E Drake To: Susan Hares , 'idr wg list' Thread-Topic: [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00.txt (7/6 to 7/20/2015) Thread-Index: AdC4UJG6Pj+U9ACORa+TFqfDTB54DgAbAbRw Date: Tue, 7 Jul 2015 13:55:57 +0000 Message-ID: References: <02ce01d0b851$4ecec5a0$ec6c50e0$@ndzh.com> In-Reply-To: <02ce01d0b851$4ecec5a0$ec6c50e0$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ndzh.com; dkim=none (message not signed) header.d=none; x-originating-ip: [66.129.241.12] x-microsoft-exchange-diagnostics: 1; BLUPR05MB563; 5:WC6ryuHwg62I5O6uGzCQ80L9AhwDnVXm9yC2LUuVdyODjKY2OTnKgKzSRA4qu/8TcOy7p/DbSdEMDlzVGjcFUoNtW8LM5hygbQnsDPV6ZNWQHtZ67UEyZ11pgEcMxwInEnnLgtc71BV+tfilzlA1fg==; 24:WPewsMzSn/kHF3mlkS8aHJYI9TTeN/+ydAnQ0ew1s4T+38BiEw51RWllA6WInWM3nsXvx9ZYEw8inLhOdvf9lRPfeI3pDaFWlaNjTfcIE1w=; 20:MTuopq+vZCsq90WK+9gsWzdmn73ouPwUBwrEElKphTd5t5QLx+nLL9IV/+kbnuxHNdVUuVBxJQuUSf2AbEJMQA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB563; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BLUPR05MB563; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB563; x-forefront-prvs: 0630013541 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(479174004)(5423002)(19580395003)(50986999)(19300405004)(19609705001)(19580405001)(66066001)(46102003)(76176999)(74316001)(33656002)(230783001)(19617315012)(19625215002)(561944003)(54356999)(2656002)(86362001)(2900100001)(87936001)(15975445007)(102836002)(2950100001)(40100003)(99286002)(5001960100002)(5002640100001)(122556002)(77096005)(16236675004)(5003600100002)(189998001)(77156002)(62966003)(76576001)(92566002)(5001770100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB563; H:BLUPR05MB562.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_BLUPR05MB5629FCC80101A3C08A8787EC7920BLUPR05MB562namprd_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jul 2015 13:55:57.4788 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB563 Archived-At: Cc: "'Keyur Patel \(keyupate\)'" Subject: Re: [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00.txt (7/6 to 7/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 Jul 2015 13:56:01 -0000 --_000_BLUPR05MB5629FCC80101A3C08A8787EC7920BLUPR05MB562namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support Yours Irrespectively, John From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Monday, July 06, 2015 9:08 PM To: 'idr wg list' Cc: 'Keyur Patel (keyupate)' Subject: [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00.txt= (7/6 to 7/20/2015) This begins a 2 week adoption call on draft-rosen-idr-tunnel-encaps-00.txt = (7/6 to 7/20/2015). The draft can be found at: https://www.ietf.org/internet-drafts/draft-rosen-idr-tunnel-encaps-00.txt In your response, discuss why this draft proposal for encapsulation: a) [operators] will help deployed networks, b) Solves know problems with other tunnel encapsulation, and c) Provides a way to manage the matrix of tunnels. We will have a status report at IDR on 7/20 on this Working group adoption = call. Sue Hares and John Scudder --_000_BLUPR05MB5629FCC80101A3C08A8787EC7920BLUPR05MB562namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support

 

Yours Irrespectively,

 

John

 

From: Idr [mailto:idr-bounces@ietf.o= rg] On Behalf Of Susan Hares
Sent: Monday, July 06, 2015 9:08 PM
To: 'idr wg list'
Cc: 'Keyur Patel (keyupate)'
Subject: [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps= -00.txt (7/6 to 7/20/2015)

 

This begins a 2 week adoption call on d= raft-rosen-idr-tunnel-encaps-00.txt (7/6 to 7/20/2015).

The draft can be found at:

 

https://www.ietf.org/internet-drafts/dra= ft-rosen-idr-tunnel-encaps-00.txt

 

In your response, discuss why this draft proposal f= or encapsulation:

a)      [operators] will help deployed networks,

b)      Solves know problems with other tunnel enca= psulation, and

c)     &= nbsp; Provides a way to manage the matrix of tunn= els.

 

 

We will have a status report at IDR on 7/20 on this= Working group adoption call.

 

Sue Hares and John Scudder

--_000_BLUPR05MB5629FCC80101A3C08A8787EC7920BLUPR05MB562namprd_-- From nobody Tue Jul 7 07:18: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 CE7451AC3F5 for ; Tue, 7 Jul 2015 07:18:29 -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 fdsFktGQwu0J for ; Tue, 7 Jul 2015 07:18:28 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CB351AC3EF for ; Tue, 7 Jul 2015 07:18:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10482; q=dns/txt; s=iport; t=1436278708; x=1437488308; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ss5eWfpVKBCe8Gc5otL7J6wyCGqNbmchBXUgENELofg=; b=EWs46lGVjNwt+VYfsxVP9fb1RtS5j0pIrcUO53ewaOqizzoiYR43wTWC xDYLh6xi4QlabEhtTyyj+Kp0kLHuXM1BqIxFlvfyOYOWYfvkhI0jyokfy t/MGbd3iDwawAU4SAXVoqb6M7wLuoaP8/appc/3UKhnSWLqruiXq66X9A I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BwAwB+3ptV/4MNJK1cgkVNVGC9bAmBZQELhXUCgVI4FAEBAQEBAQGBCoQjAQEBBAEBARoQQQsQAgEIEQQBASgHJwsUCQgBAQQOBYguDcwFAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLS4UCBAYBgxeBFAWUGAGLaIE6k0ODXSaCPYE+bwGCSgEBAQ X-IronPort-AV: E=Sophos;i="5.15,423,1432598400"; d="scan'208,217";a="165977178" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-2.cisco.com with ESMTP; 07 Jul 2015 14:18:27 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t67EIRdR022175 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 7 Jul 2015 14:18:27 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.83]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Tue, 7 Jul 2015 09:18:26 -0500 From: "Gaurav Dawra (gdawra)" To: John E Drake Thread-Topic: [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00.txt (7/6 to 7/20/2015) Thread-Index: AdC4UJG6Pj+U9ACORa+TFqfDTB54DgAbAbRwAADMVm4= Date: Tue, 7 Jul 2015 14:18:26 +0000 Message-ID: References: <02ce01d0b851$4ecec5a0$ec6c50e0$@ndzh.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_B510BE9A08E44DE096FE7491DE581124ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "Keyur Patel \(keyupate\)" , idr wg list , Susan Hares Subject: Re: [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00.txt (7/6 to 7/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 Jul 2015 14:18:30 -0000 --_000_B510BE9A08E44DE096FE7491DE581124ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support Regards, On Jul 7, 2015, at 6:56 AM, John E Drake > wrote: Support Yours Irrespectively, John From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Monday, July 06, 2015 9:08 PM To: 'idr wg list' Cc: 'Keyur Patel (keyupate)' Subject: [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00.txt= (7/6 to 7/20/2015) This begins a 2 week adoption call on draft-rosen-idr-tunnel-encaps-00.txt = (7/6 to 7/20/2015). The draft can be found at: https://www.ietf.org/internet-drafts/draft-rosen-idr-tunnel-encaps-00.txt In your response, discuss why this draft proposal for encapsulation: a) [operators] will help deployed networks, b) Solves know problems with other tunnel encapsulation, and c) Provides a way to manage the matrix of tunnels. We will have a status report at IDR on 7/20 on this Working group adoption = call. Sue Hares and John Scudder _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr --_000_B510BE9A08E44DE096FE7491DE581124ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Support

Regards,


On Jul 7, 2015, at 6:56 AM, John E Drake <jdrake@juniper.net> wrote:

Support

 

Yours Irrespectively,

 

John

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Monday, July 06, 2015 9:08 PM
To: 'idr wg list'
Cc: 'Keyur Patel (keyupate)'
Subject: [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps= -00.txt (7/6 to 7/20/2015)

 

This begins a 2 week adoption call on d= raft-rosen-idr-tunnel-encaps-00.txt (7/6 to 7/20/2015).

The draft can be found at:

 

https://www.ietf.org/internet-drafts/dra= ft-rosen-idr-tunnel-encaps-00.txt

 

In your response, discuss why this draft proposal f= or encapsulation:

a)    &nb= sp; [operators] will help deployed networks= ,

b)    &nb= sp; Solves know problems with other tunnel = encapsulation, and

c)    &nb= sp;  Provides a way to manage the matrix of = tunnels.

 

 

We will have a status report at IDR on 7/20 on this= Working group adoption call.

 

Sue Hares and John Scudder

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.iet= f.org/mailman/listinfo/idr
--_000_B510BE9A08E44DE096FE7491DE581124ciscocom_-- From nobody Tue Jul 7 07:29: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 C11261AC442 for ; Tue, 7 Jul 2015 07:29:10 -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 txpkEDflz-H9 for ; Tue, 7 Jul 2015 07:29:09 -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 47DDF1ACC8B for ; Tue, 7 Jul 2015 07:28:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13393; q=dns/txt; s=iport; t=1436279287; x=1437488887; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=oz1/hH0e0VUHKs40LdCX1+tnmbUYgkN/DcQShsGLKHY=; b=lqieEWENvsEkEL1Iyh7iBdoFxYNWKOfxIS3/HzpFtFXla+cUd6ORUE9x lHW51MgZn34mG5oI/Krl8vU9W41hyRUYUQ3kIAyWlpflbO86JjvJxpGmp RFvb7053R/3q/6djYmM0d/06Qk8Ei+Hl0MNdJMWFuXPXqnK9+unB/sHLj s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BwAwCh4JtV/4MNJK1cgkVNVGAGvWYJgXGFdQIcgTY4FAEBAQEBAQGBCoQjAQEBBB0GCkwQAgEIDgMDAQIoAwICAjAUCQgBAQQBDQUbiBMNtQOWdAEBAQEBAQEBAQEBAQEBAQEBAQEBARMEi0uEdQ0EB4JogUMFlBgBi2iBOpNDg10mgj2BPm8BgUaBBAEBAQ X-IronPort-AV: E=Sophos;i="5.15,423,1432598400"; d="scan'208,217";a="166349495" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Jul 2015 14:28:06 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t67ES6UD031381 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 7 Jul 2015 14:28:06 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.208]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0195.001; Tue, 7 Jul 2015 09:28:06 -0500 From: "Acee Lindem (acee)" To: Susan Hares , "'idr wg list'" Thread-Topic: [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00.txt (7/6 to 7/20/2015) Thread-Index: AdC4UJG6Pj+U9ACORa+TFqfDTB54DgAePMWA Date: Tue, 7 Jul 2015 14:28:05 +0000 Message-ID: References: <02ce01d0b851$4ecec5a0$ec6c50e0$@ndzh.com> In-Reply-To: <02ce01d0b851$4ecec5a0$ec6c50e0$@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_D1C1595626114aceeciscocom_" MIME-Version: 1.0 Archived-At: Cc: "Keyur Patel \(keyupate\)" Subject: Re: [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00.txt (7/6 to 7/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 Jul 2015 14:29:10 -0000 --_000_D1C1595626114aceeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBzdXBwb3J0IHRoaXMgd29yayBhcyBpdCBwcm92aWRlcyBhIGdlbmVyYWxpemVkIHNvbHV0aW9u IGZvciBwcm92aWRpbmcgYW55IEJHUCBhZHZlcnRpc2VkIHNlcnZpY2Ugb3ZlciBhbGwgdGhlIGNv bW1vbiB1bmRlcmxheSB0ZWNobm9sb2dpZXMuDQpUaGFua3MsDQpBY2VlDQoNCkZyb206IElkciA8 aWRyLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmlkci1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVo YWxmIG9mIFN1c2FuIEhhcmVzIDxzaGFyZXNAbmR6aC5jb208bWFpbHRvOnNoYXJlc0BuZHpoLmNv bT4+DQpEYXRlOiBNb25kYXksIEp1bHkgNiwgMjAxNSBhdCA5OjA3IFBNDQpUbzogJ2lkciB3ZyBs aXN0JyA8aWRyQGlldGYub3JnPG1haWx0bzppZHJAaWV0Zi5vcmc+Pg0KQ2M6ICJLZXl1ciBQYXRl bCAoa2V5dXBhdGUpIiA8a2V5dXBhdGVAY2lzY28uY29tPG1haWx0bzprZXl1cGF0ZUBjaXNjby5j b20+Pg0KU3ViamVjdDogW0lkcl0gMiB3ZWVrIGFkb3B0aW9uIGNhbGwgZm9yIGRyYWZ0LXJvc2Vu LWlkci10dW5uZWwtZW5hcHMtMDAudHh0ICg3LzYgdG8gNy8yMC8yMDE1KQ0KDQpUaGlzIGJlZ2lu cyBhIDIgd2VlayBhZG9wdGlvbiBjYWxsIG9uIGRyYWZ0LXJvc2VuLWlkci10dW5uZWwtZW5jYXBz LTAwLnR4dCAoNy82IHRvIDcvMjAvMjAxNSkuDQpUaGUgZHJhZnQgY2FuIGJlIGZvdW5kIGF0Og0K DQpodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtcm9zZW4taWRyLXR1 bm5lbC1lbmNhcHMtMDAudHh0DQoNCkluIHlvdXIgcmVzcG9uc2UsIGRpc2N1c3Mgd2h5IHRoaXMg ZHJhZnQgcHJvcG9zYWwgZm9yIGVuY2Fwc3VsYXRpb246DQoNCmEpICAgICAgW29wZXJhdG9yc10g d2lsbCBoZWxwIGRlcGxveWVkIG5ldHdvcmtzLA0KDQpiKSAgICAgIFNvbHZlcyBrbm93IHByb2Js ZW1zIHdpdGggb3RoZXIgdHVubmVsIGVuY2Fwc3VsYXRpb24sIGFuZA0KDQpjKSAgICAgICBQcm92 aWRlcyBhIHdheSB0byBtYW5hZ2UgdGhlIG1hdHJpeCBvZiB0dW5uZWxzLg0KDQoNCldlIHdpbGwg aGF2ZSBhIHN0YXR1cyByZXBvcnQgYXQgSURSIG9uIDcvMjAgb24gdGhpcyBXb3JraW5nIGdyb3Vw IGFkb3B0aW9uIGNhbGwuDQoNClN1ZSBIYXJlcyBhbmQgSm9obiBTY3VkZGVyDQo= --_000_D1C1595626114aceeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <98B19D505F50E245851D4C9F79F7C819@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5JIHN1cHBvcnQg dGhpcyB3b3JrIGFzIGl0IHByb3ZpZGVzIGEgZ2VuZXJhbGl6ZWQgc29sdXRpb24gZm9yIHByb3Zp ZGluZyBhbnkgQkdQIGFkdmVydGlzZWQgc2VydmljZSBvdmVyIGFsbCB0aGUgY29tbW9uIHVuZGVy bGF5IHRlY2hub2xvZ2llcy4mbmJzcDs8L2Rpdj4NCjxkaXY+VGhhbmtzLDwvZGl2Pg0KPGRpdj5B Y2VlJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9E WV9TRUNUSU9OIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZTox MXB0OyB0ZXh0LWFsaWduOmxlZnQ7IGNvbG9yOmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRpdW0g bm9uZTsgQk9SREVSLUxFRlQ6IG1lZGl1bSBub25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQQURE SU5HLUxFRlQ6IDBpbjsgUEFERElORy1SSUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFw dCBzb2xpZDsgQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8 c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTogPC9zcGFuPklkciAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmlkci1ib3VuY2VzQGlldGYub3JnIj5pZHItYm91bmNlc0BpZXRmLm9yZzwvYT4m Z3Q7IG9uIGJlaGFsZiBvZiBTdXNhbiBIYXJlcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNoYXJlc0Bu ZHpoLmNvbSI+c2hhcmVzQG5kemguY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13 ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9zcGFuPk1vbmRheSwgSnVseSA2LCAyMDE1IGF0IDk6MDcgUE08 YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bhbj4naWRyIHdnIGxp c3QnICZsdDs8YSBocmVmPSJtYWlsdG86aWRyQGlldGYub3JnIj5pZHJAaWV0Zi5vcmc8L2E+Jmd0 Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5DYzogPC9zcGFuPiZxdW90O0tl eXVyIFBhdGVsIChrZXl1cGF0ZSkmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzprZXl1cGF0ZUBj aXNjby5jb20iPmtleXVwYXRlQGNpc2NvLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZv bnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5bSWRyXSAyIHdlZWsgYWRvcHRpb24gY2Fs bCBmb3IgZHJhZnQtcm9zZW4taWRyLXR1bm5lbC1lbmFwcy0wMC50eHQgKDcvNiB0byA3LzIwLzIw MTUpPGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgaWQ9Ik1BQ19P VVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVGVDogI2I1YzRk ZiA1IHNvbGlkOyBQQURESU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+DQo8ZGl2IHhtbG5z OnY9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206dm1sIiB4bWxuczpvPSJ1cm46c2NoZW1hcy1t aWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiIHhtbG5zOnc9InVybjpzY2hlbWFzLW1pY3Jvc29m dC1jb206b2ZmaWNlOndvcmQiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20v b2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1s NDAiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNCAo ZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQg NSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNv TGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47 DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDou NWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2lu OjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3Qt aWQ6MjAyMzc3NjAwMjsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0 ZS1pZHM6MTM2MjMxMTkwIDY3Njk4NzExIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4 NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0IGwwOmxldmVs MQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGV4 dDoiJTFcKSI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4t bG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3Qg bDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJ dGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBo YS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsOQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05 LjBwdDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBp bjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8ZGl2IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBj b2xvcjogYmxhY2s7Ij5UaGlzIGJlZ2lucyBhIDIgd2VlayBhZG9wdGlvbiBjYWxsIG9uIGRyYWZ0 LXJvc2VuLWlkci10dW5uZWwtZW5jYXBzLTAwLnR4dCAoNy82IHRvIDcvMjAvMjAxNSkuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IGJs YWNrOyI+VGhlIGRyYWZ0IGNhbiBiZSBmb3VuZCBhdDoNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiBibGFjazsiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+PGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXJvc2VuLWlkci10dW5u ZWwtZW5jYXBzLTAwLnR4dCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry YWZ0LXJvc2VuLWlkci10dW5uZWwtZW5jYXBzLTAwLnR4dDwvYT48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7 IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+SW4geW91ciByZXNwb25zZSwgZGlz Y3VzcyB3aHkgdGhpcyBkcmFmdCBwcm9wb3NhbCBmb3IgZW5jYXBzdWxhdGlvbjo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5k ZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCEtLVtpZiAhc3VwcG9ydExpc3Rz XS0tPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Okln bm9yZSI+YSk8c3BhbiBzdHlsZT0iZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5v cm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgZm9udC1zaXplOiA3cHQ7IGxpbmUtaGVpZ2h0OiBu b3JtYWw7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCEtLVtlbmRpZl0tLT48c3BhbiBz dHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsi PltvcGVyYXRvcnNdIHdpbGwgaGVscCBkZXBsb3llZCBuZXR3b3JrcywNCjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6 LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IS0tW2lmICFzdXBwb3J0TGlzdHNdLS0+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3Jl Ij5iKTxzcGFuIHN0eWxlPSJmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFs OyBmb250LXdlaWdodDogbm9ybWFsOyBmb250LXNpemU6IDdwdDsgbGluZS1oZWlnaHQ6IG5vcm1h bDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IS0tW2VuZGlmXS0tPjxzcGFuIHN0eWxl PSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+U29s dmVzIGtub3cgcHJvYmxlbXMgd2l0aCBvdGhlciB0dW5uZWwgZW5jYXBzdWxhdGlvbiwgYW5kDQo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9 InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCEtLVtpZiAhc3Vw cG9ydExpc3RzXS0tPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PHNwYW4gc3R5bGU9Im1z by1saXN0Oklnbm9yZSI+Yyk8c3BhbiBzdHlsZT0iZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZh cmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgZm9udC1zaXplOiA3cHQ7IGxpbmUt aGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCEtLVtl bmRpZl0tLT48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJy aSwgc2Fucy1zZXJpZjsiPlByb3ZpZGVzIGEgd2F5IHRvIG1hbmFnZSB0aGUgbWF0cml4IG9mIHR1 bm5lbHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl cmlmOyI+V2Ugd2lsbCBoYXZlIGEgc3RhdHVzIHJlcG9ydCBhdCBJRFIgb24gNy8yMCBvbiB0aGlz IFdvcmtpbmcgZ3JvdXAgYWRvcHRpb24gY2FsbC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFt aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1m YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij5TdWUgSGFyZXMgYW5kIEpvaG4gU2N1ZGRlcjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvc3Bhbj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_D1C1595626114aceeciscocom_-- From nobody Tue Jul 7 10:23: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 7764B1ACECC for ; Tue, 7 Jul 2015 10:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.048 X-Spam-Level: **** X-Spam-Status: No, score=4.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k4O_QAHtBiox for ; Tue, 7 Jul 2015 10:23:07 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0116.outbound.protection.outlook.com [65.55.169.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6C321ACED7 for ; Tue, 7 Jul 2015 10:23:06 -0700 (PDT) Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none; Received: from [172.29.32.214] (66.129.241.12) by BN3PR0501MB1089.namprd05.prod.outlook.com (10.160.113.11) with Microsoft SMTP Server (TLS) id 15.1.207.19; Tue, 7 Jul 2015 17:23:04 +0000 Message-ID: <559C0AF3.5000301@juniper.net> Date: Tue, 7 Jul 2015 13:22:59 -0400 From: Eric C Rosen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Lizhenbin References: <5A5B4DE12C0DAC44AF501CD9A2B01A8D8C9FF3F5@nkgeml506-mbx.china.huawei.com> In-Reply-To: <5A5B4DE12C0DAC44AF501CD9A2B01A8D8C9FF3F5@nkgeml506-mbx.china.huawei.com> Content-Type: text/plain; charset="gbk"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.12] X-ClientProxiedBy: BLUPR0401CA0021.namprd04.prod.outlook.com (25.162.114.159) To BN3PR0501MB1089.namprd05.prod.outlook.com (25.160.113.11) X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1089; 2:P8YdT4m0fcOVC2NWQ8ZfPAQ4NRTsKdN+u5zlWxCs9qnAwrAYu+2ZVrIMBW2Ft8MI; 3:vKim+xiXPkZrbl6RSpiXyBLKWd9Uy3y1UWzUKwxbbE5AEfb+T0qtJMfSTgxQr8FyBhWpo9WXPBpdTXiyCW3ISwXDDBjXJzlP4IfVG3n5BZCeq+xdREkAMMjQI5FcOorsNuMc3AAUnlLy/qCL9MNoIQ==; 25:rcUlOmrdBFJDY8WeZJidyDB0oiY9xeYabnG/3kMpBzPI2DRm76EfCiWPFR0ZqLmg4CW8E38srZVVnRBmzDXKSzeg/MLaGk9KJq7K7jDVotJnNyMwcZhULfVrpv00Y2sYbTjHjr6TJvrOR3OcPJ5SQ4lfbbW6sAIcoZE9Pq0sysY6eZf1UduPu/RjqtY6b00QVLwzE9E8iRO8YN6n+kPmxo0bc9I4W8kMA0Se3HWtx0w0AWMRPODWD6fS1AnWT5tAmBzpjy/1lfO/TWSfIHnP9w== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1089; X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1089; 20:uefp0GekLqSjJKy3HWUNwmFbOEwFlTLEtgundaoThMr9lfd70dLUgTrBYHE057QKKW5OgU0FGuSzeJH+t4HeixYF67f5fmuQmeJWA8QY6qS2bzJ8X6VpFT6UoopCj2Z2631ogeq3yRcWToirbTENlxQ8VE4nXzIZzk58b6gyJfx4erNCo+TBcJ8vrbNLOZxIj0lyfoy4gV3cbmR/LvJB5kkEBDHRcUHRJ10WOBQKYhoO95cilmaUZ2oxmJnvbteK6FNKpeZ7sgx6JEVeRacBA+KumjD/XoMIHnCqUB9oJkWLDnn41KP0N0W8PuXTY/wkhDnjLCLXg05RLFAyX8jvhsQQqGYkApQtPxmygpWB3hDUSialSWZlFWGi03ONYjpQPJVUVyvS85QI2KWhwQ75PjSULgKdzBfQsBpkR1OIV9HRy8o6uhS+kZczDEh4Mr0GS9VIdTGkkHj+6uewr6GCRch0FClN/ujhbmvgCvVDF58udx0js49kLAGTISrVRLma; 4:mlCqqtKcfB4wUo63Qdn1U2cZEWwebEvF7qlhXRLuLI3nyGjjRUL+uHRaJ8IXCB9Du8zC6LgEH/MBXEtCDqORaNN4Cp6BpEQishaZuJbuVgT190/+s5Bh8ZhbrDnLHxRoRSFoToc4vY8k8cc78u9XRQvRSvsj6rwMuTtV0iDN06AZgqLF8qzeKwL9lNWMpNhF5+hKdI9JeSm6hf27cbIwTqPooBliV1imO9swseeW2bZP26EQ+TJNfBo1swDBfmB2bKYc5+K8y56lN+jJm4sjBPC7EsZxEs3do9euK4pW5js= 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:BN3PR0501MB1089; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1089; X-Forefront-PRVS: 0630013541 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(6009001)(51704005)(24454002)(479174004)(377454003)(36756003)(87976001)(62966003)(59896002)(64126003)(80316001)(92566002)(4001350100001)(230783001)(33656002)(122386002)(224303003)(189998001)(110136002)(40100003)(5001960100002)(77156002)(42186005)(54356999)(46102003)(23696002)(66066001)(47776003)(65806001)(65816999)(50986999)(65956001)(50466002)(87266999)(2950100001)(86362001)(76176999)(83506001)(77096005); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1089; H:[172.29.32.214]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?gb2312?B?MTtCTjNQUjA1MDFNQjEwODk7MjM6RHpWSmQzRjF3V0l0c3prei94OXJDVE1L?= =?gb2312?B?cVJQZWM2S2VOa0locTdkSnRBdXA5TEUxQWtxMGNDcmlVQmtvMzUveFNYd0dB?= =?gb2312?B?cGw4cFBINXRFQUI4c083bWZCNm1rUnpKc3ZNWitSVFl5MzMwaTFOTm5meVpM?= =?gb2312?B?bHhmZ1JaUU5WTGl5ZHlxbTljc2l4Y0prS2pFWGo1enFsZmZ0QzU4VzJ1RjU0?= =?gb2312?B?NW1JZk1scXVjcXpFb1EyRTQ0UTBjWjl1UjZOeUdBbmNWVkw4Vkh5cGIyVi9C?= =?gb2312?B?V0RvQVlGelAybE84Z2d6ZXA4M2ZvL2NYeEI2OUVyZE1TNDFseWVsZndQOXAz?= =?gb2312?B?U3pMZWh5VngvKzJlNnFtVnVwaUU3WDE2UHRSVnhFOU11bFFneW9SZlFkdEZL?= =?gb2312?B?TTI5RE8vaDZQSG5veWxEeXhZb1NYTmR2clRLOFhTQm1GZ0JOSTBQREVCNEZo?= =?gb2312?B?ZUtCUVZxTEtJMC9BV09jemJjejNCbVI4SDFVK3pzbE1uZDhiWjZVYkJlM1VS?= =?gb2312?B?c3kvRERwT29VcGlNL0FMWGIvM09vWVZ5aitnSTZ1SENKNkdGeHQxYjhLUmZC?= =?gb2312?B?OU1qZzZKVVhEbDNnZ2UwTzlPTVMvamlsa01ZTlZSbDZRMlY5RUo5SUJseVl1?= =?gb2312?B?K3p5ZjRuaTNlNGV6QUdmWVlPcE8xOEhWVnBzMkN2Q3lZemZzdkdpNTRqYkVj?= =?gb2312?B?cTlVR0FMcG1DZDlWV2ptVEJlZiszWEl5NFE3S09YZTNwaDhSSHh6R1RYTHdL?= =?gb2312?B?Zlg5S0N4c1RFZi9kbDNBK2VTRUE0RTM1UDZIRXRmVGNVOEo1b2pyVUpEaXNl?= =?gb2312?B?cVhFcURsTjVUWXdvN295NURydHFOOERBTGg4RHJKck9kc01xOFlTWHRSa2dW?= =?gb2312?B?VVFnY3JjV1dicE9lRzBoZ1FPRzFYMGJORkNrMUpQMmYvcCtMMCtZOVdPUC85?= =?gb2312?B?N1EvOVFHUjQvTDhVdWMxRzN1QnpmcHpTUXI0VXRyUVdFWVFaK1hsM3p5ZEFC?= =?gb2312?B?SGlKb3kyR0lEVzZVK1VyWm1EejAxcTRXZnpHUVpscnYzUFNRT040cTdSV2Vi?= =?gb2312?B?NUowTFNKWHk1Rjc2bjlLVjhCM0tORFRhMFBGN2N1SFFReDY5ZExsNmFYVUpi?= =?gb2312?B?MHd6Q3FQeTQvM1R0Rk1wbkEzdGpQa2NvejRHUFEyQURMOGhqY2ZSaWZUb2N4?= =?gb2312?B?cnJReDEyL1d0cDZpTW91NWxTUldZYi85cmVleHRya2NqNXVyWHVpWk5ORzJX?= =?gb2312?B?SmI2b21RZXh1QUVJckNPTjllYTc1WWUwUDgybUpINlozY1owdjQ0c3pXMUFY?= =?gb2312?B?RHBMSkxLNXVua09mMHBLMlJUT0xIVlBBSURqZk8rRVhERFdDMStWcUNCa0Yv?= =?gb2312?B?SUU5Sm4wS0NLdnF1RHZNK2d1SUxsL29hRzE2OWZUdXc9PQ==?= X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1089; 5:HW5Roxt8LebmRZ5LQLpHj+Q+0uqGkGzKdlRpuuaQTw12lTI4mz09b8t+OVpjVMLOpTVoXnM7uf4rBkLQtKisNDKDc6ahDv+YMoqDIhoArB5xI8/uaxUYhaeWHHegGDqUUR/AXdu5D+Dy6IHz+LtdeA==; 24:lu9jfF95b+tBNyEwGlutzWBaRZd5hHZzd3uoEIan15Bv2X7rRvg/H2Njl02x1aF1o61q/owqPNRX9g5TR8/PyiU1pjt1Cxl2XkOMhY+Tz1Q=; 20:LvTqDczbShqFRwZwlTLaepJTiNdDt8L+9caqezO4nl3+z1utQ2dhVZ20rB3PlbyH4Fmk/FU9EBxopcuQ42vQZQ== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Jul 2015 17:23:04.7468 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1089 Archived-At: Cc: "Keyur Patel \(keyupate\)" , "idr@ietf.org" Subject: Re: [Idr] =?gbk?q?=B4=F0=B8=B4=3A_draft-rosen-tunnel-encaps-00=2Etxt?= 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 Jul 2015 17:23:08 -0000 On 7/3/2015 1:32 PM, Lizhenbin wrote: > According to my understanding, for the draft > draft-rosen-tunnel-encaps-00 I think the tunnel types defined here > are almost all IP tunnels used for data center scenarios. > > When I tracked to RFC 5512, it also only defined IP tunnels. I am > not familiar with the history of the RFC. RFC 5565 ("Softwire Mesh Framework") describes the use cases that we were thinking about at the time RFC 5512 was written. > Could you help explain why MPLS tunnels are not taken BGP and LDP already have widely deployed methods of distributing "service labels" for MPLS-based applications. Typically MPLS-based applications run over an infrastructure where MPLS is enabled for transport and used by default. So there is no need for the egress node to use BGP to signal that it wants the ingress node to use an MPLS tunnel. Note that the scenarios discussed in RFC 5565 could easily have been handled with existing MPLS techniques ("6PE", "4PE"), but there was a requirement to use non-MPLS tunnels for some reason. > For the Remote Endpoint Sub-TLV in Section 2.1, why is the AS number > sub-field is introduced? To support the security techniques discussed in section 11 of the draft. > Section 2.1: " There is one special case: the Remote Endpoint > sub-TLV MAY have a value field consisting entirely of zeroes. This > means that the tunnel's remote endpoint is the UPDATE's BGP next > hop." > > I think the special case may be just to waste process. Can it be > removed? You might be right, but the thinking here is that it is good to have a special value of the Remote Endpoint sub-TLV that just means "next hop address". One alternative would be to omit the sub-TLV entirely if you want the tunnel to go to the next hop. However, that would complicate the error processing (ability to detect malformed TLVs). Another alternative would be to encode the IP address of the next hop in the sub-TLV. But that introduces some issues if the next hop is changed while the route is being distributed. BTW, the format of the Remote Endpoint sub-TLV has been changed in the latest rev, in order to explicitly indicate the address family of the remote endpoint address. > For the MPLS-in-GRE in section 2.2.5, the draft introduced that it is > equivalent to including a TLV of the GRE tunnel type that also > includes a Protocol Type sub-TLV ([RFC5512]) specifying MPLS as the > protocol to be encapsulated. I think the equivalence is better. > > We should not define tunnel types combining the tunnel types and the > protocol types encapsulated. It is apparent that the MPLS-in-GRE > tunnel types definition is different from other tunnel types. And by > defining tunnel types combining the tunnel types and the protocol > types encapsulated, it may introduce more tunnel types which will > propose unnecessary debates. I agree with you, but I didn't win that argument ;-) I suspect that folks want to be able to say "of course we can encapsulate MPLS in GRE; we even have a tunnel type specifically for doing that." > Regarding IANA Considerations in section 10 "IANA is requested to add > this document as a reference for tunnel types 8-13 in the "BGP Tunnel > Encapsulation Tunnel Types" registry.", in the draft I have not seen > what tunnel types do the number 8-13 indicated in the draft. These codepoints have already been allocated by IANA and can be found in the BGP Tunnel Encapsulation Tunnel Types registry. I've changed the text to the following: IANA is requested to add this document as a reference for tunnel types 8 (VXLAN), 9 (NVGRE), 11 (MPLS-in-GRE), and 12 (VXLAN-GPE) in the "BGP Tunnel Encapsulation Tunnel Types" registry. From nobody Thu Jul 9 04:55: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 8C3351A888F for ; Thu, 9 Jul 2015 04:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.61 X-Spam-Level: X-Spam-Status: No, score=-3.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, 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 w2PFecUpim2f for ; Thu, 9 Jul 2015 04:55:49 -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 E2D9E1A0146 for ; Thu, 9 Jul 2015 04:55:48 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BYO48918; Thu, 09 Jul 2015 11:55:47 +0000 (GMT) Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 9 Jul 2015 12:55:46 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.233]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Thu, 9 Jul 2015 19:55:41 +0800 From: Haoweiguo To: "Acee Lindem (acee)" , Susan Hares , "'idr wg list'" Thread-Topic: [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00.txt (7/6 to 7/20/2015) Thread-Index: AdC4UJG6Pj+U9ACORa+TFqfDTB54DgAePMWAAF0Dgoc= Date: Thu, 9 Jul 2015 11:55:40 +0000 Message-ID: References: <02ce01d0b851$4ecec5a0$ec6c50e0$@ndzh.com>, In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.23.94] Content-Type: multipart/alternative; boundary="_000_DD5FC8DE455C3348B94340C0AB5517334F8822C1nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "Keyur Patel \(keyupate\)" Subject: Re: [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00.txt (7/6 to 7/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: Thu, 09 Jul 2015 11:55:51 -0000 --_000_DD5FC8DE455C3348B94340C0AB5517334F8822C1nkgeml501mbschi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi co-authors, I think this work is useful to support more tunnel types among BGP PEs. For= NVO3 network, VXLAN,NVGRE,VXLAN-GPE tunnel types are included in this draf= t. There are also other candidate tunnel encapsulation such as GENEVE and GUE = which are in progress. I am wondering why these tunnel types are not includ= ed in this draft? Thanks, weiguo ________________________________ From: Idr [idr-bounces@ietf.org] on behalf of Acee Lindem (acee) [acee@cisc= o.com] Sent: Tuesday, July 07, 2015 22:28 To: Susan Hares; 'idr wg list' Cc: Keyur Patel (keyupate) Subject: Re: [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00= .txt (7/6 to 7/20/2015) I support this work as it provides a generalized solution for providing any= BGP advertised service over all the common underlay technologies. Thanks, Acee From: Idr > on behalf of = Susan Hares > Date: Monday, July 6, 2015 at 9:07 PM To: 'idr wg list' > Cc: "Keyur Patel (keyupate)" = > Subject: [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00.txt= (7/6 to 7/20/2015) This begins a 2 week adoption call on draft-rosen-idr-tunnel-encaps-00.txt = (7/6 to 7/20/2015). The draft can be found at: https://www.ietf.org/internet-drafts/draft-rosen-idr-tunnel-encaps-00.txt In your response, discuss why this draft proposal for encapsulation: a) [operators] will help deployed networks, b) Solves know problems with other tunnel encapsulation, and c) Provides a way to manage the matrix of tunnels. We will have a status report at IDR on 7/20 on this Working group adoption = call. Sue Hares and John Scudder --_000_DD5FC8DE455C3348B94340C0AB5517334F8822C1nkgeml501mbschi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi co-authors,

I think this work is useful to support more tunnel type= s among BGP PEs. For NVO3 network, VXLAN,NVGRE,VXLAN-GPE tunnel types are i= ncluded in this draft.

There are also other candidate tunnel encapsulation suc= h as GENEVE and GUE which are in progress. I am wondering why these tunnel = types are not included in this draft?

Thanks,

weiguo

From: Idr [idr-bounces@ietf.org] on behalf = of Acee Lindem (acee) [acee@cisco.com]
Sent: Tuesday, July 07, 2015 22:28
To: Susan Hares; 'idr wg list'
Cc: Keyur Patel (keyupate)
Subject: Re: [Idr] 2 week adoption call for draft-rosen-idr-tunnel-e= naps-00.txt (7/6 to 7/20/2015)

I support this work as it provides a generalized solution for providin= g any BGP advertised service over all the common underlay technologies.&nbs= p;
Thanks,
Acee 

From: Idr <idr-bounces@ietf.org> on behal= f of Susan Hares <s= hares@ndzh.com>
Date: Monday, July 6, 2015 at 9:07= PM
To: 'idr wg list' <idr@ietf.org>
Cc: "Keyur Patel (keyupate)&q= uot; <keyupate@c= isco.com>
Subject: [Idr] 2 week adoption cal= l for draft-rosen-idr-tunnel-enaps-00.txt (7/6 to 7/20/2015)

This begins a 2 week adoption call on draft-ro= sen-idr-tunnel-encaps-00.txt (7/6 to 7/20/2015).

The draft can be found at:

 

https://www.ietf.org/internet-dra= fts/draft-rosen-idr-tunnel-encaps-00.txt

 

In your response, discuss why this draft proposal for encapsul= ation:

a)      [operators] will help deployed networks,

b)      Solves know problems with other tunnel encapsulation, and

c)       Provides a way to manage the matrix of tunnels.

 

 

We will have a status report at IDR on 7/20 on this Working gr= oup adoption call.

 

Sue Hares and John Scudder

--_000_DD5FC8DE455C3348B94340C0AB5517334F8822C1nkgeml501mbschi_-- From nobody Thu Jul 9 08:10: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 3C2091B2A59 for ; Thu, 9 Jul 2015 08:10:49 -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 wvU7WUtcpKrK for ; Thu, 9 Jul 2015 08:10:47 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0753.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:753]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 931CC1AC3E5 for ; Thu, 9 Jul 2015 08:10:47 -0700 (PDT) Authentication-Results: cisco.com; dkim=none (message not signed) header.d=none; Received: from [172.29.36.144] (66.129.241.11) by DM2PR0501MB1102.namprd05.prod.outlook.com (10.160.245.12) with Microsoft SMTP Server (TLS) id 15.1.207.19; Thu, 9 Jul 2015 15:10:27 +0000 Message-ID: <559E8ED3.5010208@juniper.net> Date: Thu, 9 Jul 2015 11:10:11 -0400 From: Eric C Rosen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Haoweiguo , "Acee Lindem (acee)" , Susan Hares , 'idr wg list' References: <02ce01d0b851$4ecec5a0$ec6c50e0$@ndzh.com>, In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.11] X-ClientProxiedBy: BLUPR0401CA0026.namprd04.prod.outlook.com (25.162.114.164) To DM2PR0501MB1102.namprd05.prod.outlook.com (25.160.245.12) X-Microsoft-Exchange-Diagnostics: 1; DM2PR0501MB1102; 2:DeuqQ48cVknjGsRq/8ay87m7tiAaKTn10hOi1OZgkXJRgmW3hoXJ5WiUMDsu1nZK; 3:SzuBhTA7VIyNq2GbS9uqp/aNxbFkC5GjAJ0LIMRo1fwqwBbJxfmhasGdER1vLG+To9pdTZg4xeKp5gDt3Ti8Wz8NTDJF3RiVQXWcTlzCmFhr+WDkLw8ZRj+5COYQa4Y99bqsbzd9mPKQRqbdW5pxug==; 25:POzYwnHkRnD0084W6ClEz4Y7hqNImkdqdeTVZhe9TIyJ3bBuUpvy9+QVL3CsvG/FPj4dRrKA8BYHSS54dvsbriJTTPg4RNy+12QAA/ygED7cgaSKmY/Q3n5ny7R+9gp6pscrr75jeD/R6ppw7rzxlxXgmnnLwVxv1HgY5pnFexf/bP7tNsK+4f9rjIptzbUMwMeZSGNYKo5lOPD6lASL2kWVuJeXVoxJMKr2booy6UjN5FdD9QNvhSQAgjVWOneEWiGkOpGBu1InozmRDEUNbA== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0501MB1102; X-Microsoft-Exchange-Diagnostics: 1; DM2PR0501MB1102; 20:M6oXkEqOdiHio8JmXXQLcdPr3shUVP+atwFmH1X6gv5HjVJzORih4vWbkVq7rkJNprhLrEJs2+It/t4OsfLkjtkWgv753kOyLWKOEtN/ZnJyKjg8ivSjpugd5zzd8imt0vC6KjVLgnFzFymuh25EGSKa3J9N57WgpBuHKGimQaz9bFbLu4Gb4Q7gavm/UX6GnOevLu5vKWGXAJkUqqFH7hnPtxjWGrYOUYAVZZ7NBq8Vr1bRiAQq3g0+49N5qEPlM0kaZOVdJJ+wkkBC7XtIhvUKDIK/St5AG8c7MPuP6N+Tf0ND4zqi69GOz3Fd3iir8g6Py3Hxua8wPOOusevyVgDbt/YXYDQGdsHIA/QbAbLcgDPXCU1wfyJGXwSkBgBvZ4I17sU51wspHxidWoj1QMdFHG6jWWlZriuoqTepxY4qJY3wjTFruOcw/f8JT9+mYYhaIfJZc6BcWCacK5WOWY7Y0WbN6btrCYeo1K4T7BIEuP25bcfMvlgfF8naTcjd; 4:G76CxwmFGjcjtTkYc+ZnsR/ipni2QY/V2Y3aN9zs9MbbpRFAaSZIDR4vP4CJgIPfp4BOVOMzWU3wNvWTe/tYjI+IPGAFPKfKXG2FIE+1VakmVDPSPbNUVhEuK4nd4Up/YdXIUNlOTpOe03gFDu39xleXeUr16XtPpXZ4tzU64q1GqDywVF8eqZeULGd6Yj1RGFovio/TZ59vr5lgejocAmXj5sr06I+cNbutHussfHG8g8quigaBHcxbtt8riFu0d82vezoaMl6h+Prc4wK6u6EEYbjIWtYm+9397iqw9JE= 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:DM2PR0501MB1102; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0501MB1102; X-Forefront-PRVS: 0632519F33 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(6049001)(479174004)(24454002)(5423002)(377454003)(4001350100001)(5001770100001)(65956001)(86362001)(66066001)(65816999)(54356999)(76176999)(87266999)(87976001)(50986999)(40100003)(5001960100002)(36756003)(77156002)(122386002)(189998001)(62966003)(2950100001)(42186005)(77096005)(83506001)(230783001)(92566002)(46102003)(64126003)(33656002)(50466002)(23746002)(80316001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0501MB1102; H:[172.29.36.144]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; DM2PR0501MB1102; 23:Pg9rKPoqjqvge2vEKHs5ufaE63ftl9HMUgd?= =?Windows-1252?Q?nounH3vIQ7Y+6pajzXxAEVIzlvtm+pUOQa7boSPlfFEkbDtUOFTytdf5?= =?Windows-1252?Q?9DfAAD6EQP3Yrg/r938PzOgwG7xqiQ5rX6ISEBxRo+3nOmFP1pKF8nrc?= =?Windows-1252?Q?XMKwsEwZblJ6v/FxUd+2mQb/Isnx5grBsbd343rER6b6iCx9CoF4+h/K?= =?Windows-1252?Q?lEwnMZVScImzyX1ULlxbZQ6kR9YK8sMYK/nvYaIbxmRbLdTq/9Kcs9B5?= =?Windows-1252?Q?Jnm8GypSV5RKFlIsGYtMLVljYaeq+DP/wsuLnlPK0EGZLK9BRv5AaRsa?= =?Windows-1252?Q?9/WIaPxddpBO/NbSTBvNpW2ytQC3sjvZwud6OdCsmPpFHMWBsTCWXQ38?= =?Windows-1252?Q?BiR7bdA+AjcB4BCgiISGo62iz+cyUHxUZQJysvYwiSftC8aUDa1ZQaNU?= =?Windows-1252?Q?o3qEFKzCTAniJTExNCjPtcPiwCHpkwd56DEL8snCjao4ramkq33i0hpQ?= =?Windows-1252?Q?pA6H/GSDlTTQ2BvXdQPAkFunNJS1oEAzHhsYWocJILAvhfaHcKxJklii?= =?Windows-1252?Q?4qbYD1XfdWcrNY45u6pieRuyTQnqDRDHKRWS6B2eqdQcAqNTbPi0LWEc?= =?Windows-1252?Q?ir2Xy5RQUOeDNRSzKoFVmsPN/Jq4RjtDlZV0eebktT/ODm1v5nrci5DQ?= =?Windows-1252?Q?XmhR6Is5EHuT0MfuYDa5TU1Z2duFYPU8qex+eebZuW2m/efEY+nAng6w?= =?Windows-1252?Q?UBV/HLPe4BeK97GAkm66TG7QNeGyXL9fvoY6YNR4M/MgkBrhsPClKkjr?= =?Windows-1252?Q?1+zzH3X4xvzFWEFOUvsW74Ui70IfhxWMDxB2rAdKYBXep54OfDRLsabq?= =?Windows-1252?Q?5SPNiLCfFGWV3ezke8K9C2WLfgdsTEpUgUZh0yQWmicnNDtJshn7j/Oj?= =?Windows-1252?Q?Sgb1Yf+fEJiPa+YTxt+yqoHCgshHDJ3PzgKtgV93K1g9EQ2GNoApkWYe?= =?Windows-1252?Q?2bKkrZSUbdODxGap1x72g2rG6s2gx7RYAL2QjL7Geh+MJWOoMqA=3D?= =?Windows-1252?Q?=3D?= X-Microsoft-Exchange-Diagnostics: 1; DM2PR0501MB1102; 5:LnR+/VrBU4JlKudQBP8PU2kDf8MuQ1qTA1BhPBmFetuf9s1jz/InBRy1w3rCbQkSOOK26AHDFaxgyklu2WHlGnWcbyJTTssap1PKV8EaLF9RTg+7U5eQ2mRrWTyoxa3smlD6hzGCb0cVdJtL9g0I1g==; 24:NTsI9fiI0G6EjExPIydICh28BNg4ux7u6g1g2CKjvoV+/7t2HnsuRJyCZS85ym0PDXhUFFM610NWROOdIiSSV+W7uqXJJal8bvLkFNLhhfg=; 20:3ndaVWhvgBIH/i6uV2/u99NKIiGzDAMyQdvGSjA/kv+IDf+RiqH4kaXaorJVv7OrvQLfQJG4beHfMiy5vjcv+g== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Jul 2015 15:10:27.6070 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0501MB1102 Archived-At: Cc: "Keyur Patel \(keyupate\)" Subject: Re: [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00.txt (7/6 to 7/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: Thu, 09 Jul 2015 15:10:49 -0000 On 7/9/2015 7:55 AM, Haoweiguo wrote: > There are also other candidate tunnel encapsulation such as GENEVE and > GUE which are in progress. I am wondering why these tunnel types are not > included in this draft? The set of tunnel types mentioned in the draft is not meant to be exhaustive; it really just reflects the interests of the authors and/or their customers. No matter how many encapsulations one includes, there are always more ;-) But they don't all have to be described in the same draft. From nobody Thu Jul 9 09:20: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 9DC981B2AC6 for ; Thu, 9 Jul 2015 09:20:24 -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 gjhhA2svov6x for ; Thu, 9 Jul 2015 09:20:23 -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 4EEC21B2AB9 for ; Thu, 9 Jul 2015 09:20:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=597; q=dns/txt; s=iport; t=1436458823; x=1437668423; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=+B6mc2Rgc30RVL3/hvg58IGB9U36U6pY67EojX5wLvU=; b=GRhjLq9ZvqTuPfGFRli/oLPsx9kbHqYmKJm6hD4OeaiYm6bUbwqHtdgw B6JDvqQZZeZG8hT5txxEp5e4XlQrskaewufPFgDWr9ngWHbFS62Fa0iGH 69wt7DqjdwS7hQALLThyTwmvDz/qlQMN20CcbXt+n0k+X7o9MEh3UYA3I E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BEBQDGnp5V/4oNJK1bgxKBNAbDDAKBWTsRAQEBAQEBAYEKhCQBAQR5EAIBCEYyJQIEDgWILs8lAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4tLhFMzB4MXgRQBBIxihGOCaAGLf4E9k0uDXyaDe28BgUaBBAEBAQ X-IronPort-AV: E=Sophos;i="5.15,441,1432598400"; d="scan'208";a="14023638" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-1.cisco.com with ESMTP; 09 Jul 2015 16:20:22 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t69GKMIq030602 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 Jul 2015 16:20:22 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.136]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Thu, 9 Jul 2015 11:20:22 -0500 From: "Jerome Durand (jerduran)" To: "idr@ietf.org" Thread-Topic: [Idr] draft-jdurand-auto-bfd-00 Thread-Index: AdCyhNrQT6K0GX6ITHiyQ7RgDJ0QsQDlCRWAABXD2IAAAQYdAAAZzRYAAADn3QAA64ZrgA== Date: Thu, 9 Jul 2015 16:20:21 +0000 Message-ID: <8274F17D-5EDB-4CAE-8B8F-C0FA052B831B@cisco.com> References: <00a901d0b285$b6637430$232a5c90$@ndzh.com> <55490D92-7506-42C4-B279-430D7F18C89A@cisco.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.104.42] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <6CC0D31A22A52643AF96AE330CDC8995@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: David Freedman , Susan Hares Subject: Re: [Idr] draft-jdurand-auto-bfd-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 16:20:24 -0000 Any other comment from the group? Thanks! Jerome Le 5 juil. 2015 =E0 01:56, David Freedman a = =E9crit : > >Why do you need full BFD for auto-bfd as opposed to utilize S-BFD (Seam= less BFD) which is effectively unidirectional ? >=20 > We don't (need this) at all, but auto-bfd was not written with seamless B= FD in mind (since classical BFD is what is out in the field now), > but I take your point, perhaps we should include the case where S-BFD wil= l be used, in such case, of course, the flag can=20 > be dispensed with.=20 >=20 > Dave. From nobody Thu Jul 9 10:14:37 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 2044F1B2B0E; Thu, 9 Jul 2015 10:14:34 -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 SQnIzLLFdlXs; Thu, 9 Jul 2015 10:14:32 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0128.outbound.protection.outlook.com [207.46.100.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF90B1B2B0C; Thu, 9 Jul 2015 10:14:31 -0700 (PDT) Received: from CY1PR09MB0793.namprd09.prod.outlook.com (10.163.43.143) by BLUPR09MB005.namprd09.prod.outlook.com (10.255.211.143) with Microsoft SMTP Server (TLS) id 15.1.213.10; Thu, 9 Jul 2015 17:14:30 +0000 Received: from CY1PR09MB0793.namprd09.prod.outlook.com ([10.163.43.143]) by CY1PR09MB0793.namprd09.prod.outlook.com ([10.163.43.143]) with mapi id 15.01.0207.004; Thu, 9 Jul 2015 17:14:30 +0000 From: "Sriram, Kotikalapudi" To: Christopher Morrow Thread-Topic: [Idr] Route Leaks and solutions Thread-Index: AQHQst/YBwy3rwbYakKgtnDiHnHcZp3NZLUJgAAwLgCAACk92IAAEGcAgAWPDmA= Date: Thu, 9 Jul 2015 17:14:29 +0000 Message-ID: References: <005901d0b283$ea07bd20$be173760$@ndzh.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none; x-originating-ip: [129.6.140.100] x-microsoft-exchange-diagnostics: 1; BLUPR09MB005; 5:ih8u81BoV3woSLXhF3yPH10mfk1mIa6HfA/RZsAZ3maYGW1GeAKu7wuanrxjFclaLm7G6mqFX0AatZj+4gDBwTSq4ikpbnvQ6O1DUraYIFmNj30rlftCG08RsrXshAzKUmoWasjkV7lx/lRqtjWAeA==; 24:hssFmOkpYs3qXfQsCW2Bcn1attXGIVdajk1GwdpVHWa4LGnudqyy7lqjRhExwIrs/QSvvVKzLGGhypdwjXyfD479dhCDTx7PGIqujWhPwjg=; 20:91lTiIHdlyfPJu2bnt3NBF7e8v8GGWgR3si5CTD560hKv/WpBBOKQgvbw7XiukKK+X8fbXoiRCd/Z1wAPiF0EQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR09MB005; blupr09mb005: X-MS-Exchange-Organization-RulesExecuted 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:BLUPR09MB005; BCL:0; PCL:0; RULEID:; SRVR:BLUPR09MB005; x-forefront-prvs: 0632519F33 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(87936001)(106116001)(5003600100002)(86362001)(76576001)(62966003)(46102003)(99286002)(2656002)(66066001)(77156002)(76176999)(54356999)(50986999)(5002640100001)(2950100001)(33656002)(2900100001)(102836002)(110136002)(74316001)(77096005)(189998001)(5001960100002)(93886004)(92566002)(122556002)(40100003); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR09MB005; H:CY1PR09MB0793.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jul 2015 17:14:30.0377 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR09MB005 Archived-At: Cc: idr wg list , "sidr wg list \(sidr@ietf.org\)" Subject: Re: [Idr] Route Leaks and solutions 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 Jul 2015 17:14:34 -0000 KENjJ2luZyBzaWRyIGxpc3QgYWxzbyBzaW5jZSB0aGVyZSBpcyBpbnRlcmVzdCB0aGVyZSB0b28g aW4gdGhpcyB0b3BpYy4pDQoNCj4+IElmIEEncyBjdXN0b21lciBDIGRvZXMgbm90IHdhbnQgQSB0 byBwcm9wYWdhdGUsIHRoZW4gQyBoYXMgYSBjaG9pY2Ugbm90IHRvIHNlbmQNCj4+IHRoZSBwcmVm aXgtcm91dGUgdG8gQSBpbiB0aGUgZmlyc3QgcGxhY2UuDQo+PiBHaXZlbiB0aGF0IGNob2ljZSwg d2h5IHdvdWxkIEMgaW5zdGVhZCBjaG9vc2UgdG8gcG9pc29uIG9yIGRvd25ncmFkZSBieSBhbHRl cmluZyBSTFAgYml0cz8NCg0KPlE6IHdoeSBkbyBwZW9wbGUgcG9pc29uIHJvdXRlcyBieSBqYW1t aW5nIGluIHRvIHRoZSBhc3BhdGggQVNOIHdoaWNoDQo+dGhleSB3YW50IHRvIGlnbm9yZSB0aGVp ciBwcmVmaXgvYW5ub3VuY2VtZW50Pw0KPkE6IGJlY2F1c2Uga25vYi4NCg0KU2VjdGlvbiA1LjEg aW4gdGhlIHJvdXRlIGxlYWtzIHNvbHV0aW9uIGRyYWZ0IGFscmVhZHkgZGlzY3Vzc2VzIHBvc3Np YmxlIGFidXNlIA0Kb2YgdGhlIGtub2IgKHdpdGhvdXQgc2VjdXJpdHkgLyBiZ3BzZWMpLg0KUmFu ZHkgYW5kIEkgd2VyZSB0cnlpbmcgdG8gY29tZSB1cCB3aXRoIG1vcmUgZXhhbXBsZXMgKGJlc2lk ZXMgd2hhdCBpcyBpbiBTZWMuIDUuMSkuDQpJIHdpbGwgaW5jbHVkZSBSYW5keSdzIGFkZGl0aW9u YWwgZXhhbXBsZSAodGhhdCB3ZSBoYXZlIGRpc2N1c3NlZCBoZXJlKSBhbHNvIGluIFNlY3Rpb24g NS4xLiANCkJ1dCwgSU1ITywgc28gZmFyIG5vbmUgb2YgdGhlc2UgYWJ1c2VzIHNlZW1zIGVncmVn aW91cy4NClNvIHRoZSBiZW5lZml0IHNlZW1zIHRvIG91dHdlaWdoIHRoZSAnbmV3IGF0dGFjayB2 ZWN0b3InIGRpc2FkdmFudGFnZS4gRXhwbGFpbmVkIGZ1cnRoZXIgYmVsb3cuDQoNCkV2ZW4gd2l0 aCBST0Egb3JpZ2luIHZhbGlkYXRpb24sIHRoZXJlIGlzIHRoZSBmYWtlLW9yaWdpbi1BUyBhdHRh Y2sgdmVjdG9yICh3aXRob3V0IGJncHNlYyksDQpidXQgd2UgcmVjb2duaXplIHRoYXQgUk9BIG9y aWdpbiB2YWxpZGF0aW9uIHN0b3BzIGFsbCBhY2NpZGVudGFsIG1pcy1vcmlnaW5hdGlvbnMuIFNv IGl0IGlzIHdvcnRoIGl0LiAgDQpUaGUgZGV0ZXJtaW5lZCBhdHRhY2tlciBtYXkgc3RpbGwgdXNl IGZha2Utb3JpZ2luLUFTIGF0dGFjazsgDQpidXQgdGhhdCB3b3VsZCBiZSBtaXRpZ2F0ZWQgYnkg Ymdwc2VjICh3aGVuIGl0IGlzIGRlcGxveWVkKS4gDQogDQpMaWtld2lzZSwgdGhlIGV2b2x1dGlv biBwYXRoIGZvciByb3V0ZSBsZWFrcyBzb2x1dGlvbiBjb3VsZCBiZSBhcyBmb2xsb3dzOg0KDQpD dXJyZW50IEJHUCAod2l0aG91dCByb3V0ZSBsZWFrIHNvbHV0aW9uOyBhc3N1bWluZyBwcmVmaXgg L0FTIHBhdGggZmlsdGVycyBhcmVu4oCZdCBkb2luZyBqb2IgYWRlcXVhdGVseSkNCg0KLS0tIFZ1 bG5lcmFibGUgdG8gYWNjaWRlbnRhbCBhbmQgbWFsaWNpb3VzIHJvdXRlIGxlYWtzDQoNCi0tLSBM ZXQgdXMgc2F5IDk5JSBhcmUgYWNjaWRlbnRhbCBhbmQgMSUgbWFsaWNpb3VzICh5b3UgY2FuIHN1 YnN0aXR1dGUgeW91ciBudW1iZXJzKQ0KICANCiAgfA0KICB8DQogIFwvDQoNCkJHUCB3aXRoIHBy b3Bvc2VkIHJvdXRlIGxlYWsgc29sdXRpb24gKHdpdGhvdXQgYmdwc2VjKQ0KDQotLS0gRGV0ZWN0 cy9taXRpZ2F0ZXMgdGhlIDk5JSBidXQgbm90IHRoZSAxJQ0KDQogIHwNCiAgfA0KICBcLw0KICAN ClByb3Bvc2VkIHJvdXRlIGxlYWsgc29sdXRpb24gd2l0aCBiZ3BzZWMNCiAgICAgICANCi0tLSBE ZXRlY3RzL21pdGlnYXRlcyB0aGUgOTklIGFzIHdlbGwgYXMgdGhlIDElDQoNClNyaXJhbQ0KDQog ICAgIA0K From nobody Thu Jul 9 11:18: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 D874E1A1BCA; Thu, 9 Jul 2015 11:18: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 29lLR2mENrYb; Thu, 9 Jul 2015 11:18:12 -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 83F871B2ADE; Thu, 9 Jul 2015 11:18:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1493; q=dns/txt; s=iport; t=1436465893; x=1437675493; h=from:to:cc:subject:date:message-id:mime-version; bh=8kaoBADaaa2/6tWNUCykQivRjyeYbce0eInr5Fr2zWs=; b=ABcuCjKxvWFZmBCcYS4PDse/UMH9NpnkD18ZAZ4wIWcL+oo78HCY//jB 9vMJXrSogd46iI8Ow2jjPgwgQe75ER/PKaoR6ktrtA9s1w8QejgyqdAoK ExhuM97900MhQZdO7rjDvW049vNW8lwtnDPWet8N0EAENK6GrLJfTBLTc 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0APCACAup5V/5NdJa1bgkVNgTqHD7QXh2iBYDoSAQEBAQEBAYEKhBoMBHkSAQsBdCcEDhmIGs9KAQEBAQEFAQEBAQEBAQEakFGEMgWRRYJoAYt/gT2EGIMPh3eIDCaDe4I2gQQBAQE X-IronPort-AV: E=Sophos;i="5.15,441,1432598400"; d="scan'208,217";a="167193420" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Jul 2015 18:18:07 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t69II6oA000448 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 Jul 2015 18:18:06 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.203]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Thu, 9 Jul 2015 13:18:06 -0500 From: "Alvaro Retana (aretana)" To: "draft-ietf-idr-flowspec-redirect-rt-bis@tools.ietf.org" Thread-Topic: AD Review of draft-ietf-idr-flowspec-redirect-rt-bis Thread-Index: AQHQunOZfr+4VuOFo0WZcugScMbDug== Date: Thu, 9 Jul 2015 18:18:05 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.241.51] Content-Type: multipart/alternative; boundary="_000_D1C423FFBF9DAaretanaciscocom_" MIME-Version: 1.0 Archived-At: Cc: "idr-chairs@ietf.org" , "idr@ietf.org" Subject: [Idr] AD Review of draft-ietf-idr-flowspec-redirect-rt-bis 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 Jul 2015 18:18:19 -0000 --_000_D1C423FFBF9DAaretanaciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi! Just read this draft, and I only have a small nit to talk about: In sectio= n 2, please add a subsection for the "BGP Transitive Extended Community Typ= es=94 update. Right now the update text is in 2.1. I=92ll go ahead and start the IETF Last Call and put the document on the ne= xt Telechat. Thanks! Alvaro. --_000_D1C423FFBF9DAaretanaciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <6B948F7D51BB0845B9A7633194A96978@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi!

Just read this draft, and I only have a small nit to talk about:  = ;In section 2, please add a subsection for the "BGP Transitive Extende= d Community Types=94 update.  Right now the update text is in 2.1.

I=92ll go ahead and start the IETF Last Call and put the document on t= he next Telechat.

Thanks!

Alvaro.
--_000_D1C423FFBF9DAaretanaciscocom_-- From nobody Thu Jul 9 11:27:57 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 A5AB21B2AB8; Thu, 9 Jul 2015 11:27:55 -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 cMVVigUG4nmA; Thu, 9 Jul 2015 11:27:54 -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 DF7BF1A1BCD; Thu, 9 Jul 2015 11:27:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2370; q=dns/txt; s=iport; t=1436466473; x=1437676073; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=23aoV2ZAudGH44N9Auy3oZgpAo2dKGhKNzNne0IaWcE=; b=gsF0dVWEfbezXYxKQ5RLwwkCCPiNElVnMsK2+u2NVrqWPum+M0RvkN9h FYQkwtImHNY5iI1tnHEc1c+Ayt/FI1eMhpeD/Z23CKY3JJsH3rCzMN64Q oJhUhYoe0GTlfc7kEs+yF4GY2qTZrbeRj/RvX1Bn5+E61Ld3AkTt8dpGW U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BFBQBGvJ5V/4oNJK1bgkVNgTQGuyaHaAKBXjkTAQEBAQEBAYEKhCQBAQR5EAIBCAQBOgcyFBECBA4FFIgaz00BAQEBAQEBAwEBAQEBAQEBAQEBF4tLhQYHhCsBBJFFgmgBi3+BPYQYgw+Hd4gMJoN7b4FHgQQBAQE X-IronPort-AV: E=Sophos; i="5.15,441,1432598400"; d="scan'208,217"; a="14064888" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-2.cisco.com with ESMTP; 09 Jul 2015 18:27:53 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t69IRqsk015117 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 Jul 2015 18:27:53 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.203]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Thu, 9 Jul 2015 13:27:52 -0500 From: "Alvaro Retana (aretana)" To: "draft-ietf-idr-flowspec-redirect-rt-bis@tools.ietf.org" Thread-Topic: AD Review of draft-ietf-idr-flowspec-redirect-rt-bis Thread-Index: AQHQunOZfr+4VuOFo0WZcugScMbDup3ThcUA Date: Thu, 9 Jul 2015 18:27:52 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.241.51] Content-Type: multipart/alternative; boundary="_000_D1C433ECBFA1Daretanaciscocom_" MIME-Version: 1.0 Archived-At: Cc: "idr-chairs@ietf.org" , "idr@ietf.org" Subject: Re: [Idr] AD Review of draft-ietf-idr-flowspec-redirect-rt-bis 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 Jul 2015 18:27:55 -0000 --_000_D1C433ECBFA1Daretanaciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On 7/9/15, 2:18 PM, "Alvaro Retana (aretana)" > wrote: Just read this draft, and I only have a small nit to talk about: In sectio= n 2, please add a subsection for the "BGP Transitive Extended Community Typ= es=94 update. Right now the update text is in 2.1. I actually have another nit: I don=92t see rfc5668 and rfc7153 as normative= for this draft and should be informational. Just a nit.. Thanks! Alvaro. --_000_D1C433ECBFA1Daretanaciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <90AA22F04AB7C5409A66F83AEED536EA@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
On 7/9/15, 2:18 PM, "Alvaro Retana (aretana)" <aretana@cisco.com> wrote:

Just read this draft, and I only have a small nit to talk about:  In s= ection 2, please add a subsection for the "BGP Transitive Extended Com= munity Types=94 update.  Right now the update text is in 2.1.

I actually have another nit: I don=92t see rfc5668 and rfc7153 as norm= ative for this draft and should be informational.  Just a nit..

Thanks!

Alvaro.
--_000_D1C433ECBFA1Daretanaciscocom_-- From nobody Thu Jul 9 11:55: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 968191B2B49; Thu, 9 Jul 2015 11:55:38 -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 unpoHe_4TTKs; Thu, 9 Jul 2015 11:55:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 75F3F1B2B44; Thu, 9 Jul 2015 11:55:37 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p3 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150709185537.10941.38566.idtracker@ietfa.amsl.com> Date: Thu, 09 Jul 2015 11:55:37 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] 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: ietf@ietf.org List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 18:55:38 -0000 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-07-23. 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 updates RFC 5575 (Dissemination of Flow Specification Rules) to clarify the formatting of the the BGP Flowspec Redirect Extended Community. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-redirect-rt-bis/ IESG discussion can be tracked via https://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 Thu Jul 9 11:57: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 6B72A1A6EDC; Thu, 9 Jul 2015 11:49:29 -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 ByXp9DrFL4za; Thu, 9 Jul 2015 11:49:28 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0121.outbound.protection.outlook.com [207.46.100.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE8A21B2B2E; Thu, 9 Jul 2015 11:49:27 -0700 (PDT) Authentication-Results: cisco.com; dkim=none (message not signed) header.d=none; Received: from mcorbin-sslvpn-nc.jnpr.net (66.129.241.10) by BN1PR05MB153.namprd05.prod.outlook.com (10.255.205.18) with Microsoft SMTP Server (TLS) id 15.1.207.19; Thu, 9 Jul 2015 18:49:25 +0000 MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_20E3B644-7F42-4422-B763-988057A6F884" From: Jeff Haas In-Reply-To: Date: Thu, 9 Jul 2015 14:49:16 -0400 Message-ID: References: To: "Alvaro Retana (aretana)" X-Mailer: Apple Mail (2.2098) X-Originating-IP: [66.129.241.10] X-ClientProxiedBy: DM2PR11CA0036.namprd11.prod.outlook.com (25.160.91.46) To BN1PR05MB153.namprd05.prod.outlook.com (10.255.205.18) X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB153; 2:0behZ1+3k8cr26G+pBltuc6y/M+UXYHzltag7++EyWBbLFFB3aiSaDW0xoqx/cWU; 3:w5/42L6y8CiRP0tImI8WtXBT7p88GMHg1tfjgS6tb3qDTFxU+Bn+TpXFvpr+IawcbOUGOumz3uEtzaDhBSMi4uLotRBmvHwGlyTw1iszg3xy6hkfZWvREarl/XlyNCkjfp39wlk+1qysrYnrN5AeFQ==; 25:0zJSl0KU+VW8dx6kDk5lDAR0vVbCYtb2eGc2EEk4Nssj6Z8h0m3OCVhomWWzSyTXTA/qGpLqW3cEo8T1CG963ryO79B1M7xGBtpP0TKJo91rzLwo53ytK7z8LRRufUJnRQpMSYtL/gdatcTuqRkL7l7S7rVDKQFxP6yRnscXFE8Je7DCOp5EaYHLWohYkRvd3hmFf8SD8c1aoyGakIsi0NHV5Kc+91nNcErIuAiRtEdNa11NTh/GzenAe/7SeqAuWLb5KL81dT475h3ezkvX0A== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB153; X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB153; 20:mfPvIf6UhAKXpYN5zkxGoU+6qH8wusySnZeu3r18KMB+++NbBngUw2zJtCFe+WQ6Cger9hyC7tslQx8K+4eEkM3wZVYREkCeh+ID2HM79OOOQaUlf54+0a3SunQPi8pY/h2Hq6JHEar6IHZHNkx5fbRWztSR8sfisU2q9dNtTBppdPeTcgK/TZ8Ls7Yz2+/rzov7Dd6DhWg6synkDskmQceE8Vz4L2eYL87trrahqngrArxwShcOAw/nHU8e/YOsDy/R0sdbeHlmaQftZueEDRm6hPu4avPIxKaL0OdnGJgzf/PzIOtuFG564eXUxbu5bxeaBYeDg8GdovuLkiBUgbi79d95U5asaRkt5aNv6IVnHYTewaXn47TmfW+WwTDmbQa5mPw8PqBiWXYvyOjvTghMgNhUVTiFdlcHUaTyRK6BdhOlB7F/D6xgVpIXsX7WvO0q87TBxaoLdwuWdegV8kGsC263YSlZTy3SmJGwwH4DmFzcHcocaIe9OU5mEm00; 4:iwJPMed1eVYTeks5+vrabJlvyTHRIpasgFIU9QLIIVQEkcB6WHHJ6PLosFcD7UpLma1DWMQ1RgOCl0cVb/mkZLWeVPTTXxucxc88+XcrWAQ7TGYROwFdZf3i+SA8eYTlP3Bz8wnRUWl3yswa6D21fAyW5sKYbnfh2tHWo+9jSwJKREDh2w3BUfIuj9A+lHSQKJ/HUwqce4JyvajFXgm2jEMLkZBmLenXi0ZgT9vZfcpgdIdQu6AGOpbJObYh9FPD03xGtsagj0D5W37vmaLs76gvZWbGPjeJxfAAN8iB5bk= 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:BN1PR05MB153; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB153; X-Forefront-PRVS: 0632519F33 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(377454003)(51704005)(24454002)(479174004)(33656002)(76176999)(50226001)(42186005)(87976001)(83716003)(50986999)(66066001)(53416004)(82746002)(5001920100001)(77096005)(62966003)(122386002)(19580405001)(84326002)(36756003)(19580395003)(2950100001)(57306001)(5001960100002)(46102003)(110136002)(189998001)(512944002)(92566002)(40100003)(230783001)(86362001)(77156002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB153; H:mcorbin-sslvpn-nc.jnpr.net; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB153; 23:IA3nKryUJ6ppRi/dEwIGuHcK5kuxLIjPOUoZiVxvUO+xKHHZx9CbVr08qcjwDwMwaesjkSSr+Zp+PiZHyd7ceNAgk9vdS/SD0OLNsEkaOJhuIj5nC3XYEHHWwiCc7ldq+g7y/KWiqryBMTM7byY/VbYyJ3pmEnDnaVgMsPymF1sfFQsYQtQSWa2mVpT+z6bFgYw36zC61aso/GvBVSBDGkMgi3Dt62Md9hztAIBI7Jp1K1h0wfU5Lblfgqr7scAk+Ob4FWYZS+vrIVPyuxaopYsqCx9IP2mJJ7LQ82PbEkGIWWeHu/q3BTAtnxl0/wpnwWgakCIntE9cJCswtWfVHOZzEfEoqYTG0wpYG7m80en9kGWKf/DPqAgz7cO15E590LtCnTvGELrp80yMkhY7G1uGfNGJuzkj5tJ43ntL+DMAn6Fo+wgY5o3sESPerhQZ00LEHyFABpC9sEoTV/DtxZWw4q4rGOY5m35Ep4zsYq6PJmU+df0b26ncWpgKvSJloLJPsvilgw57+p/27SES6lsNz9EwXWSEyXEEOjXpl5Z90lcyKOhzA/I+8NKtvCCfjhHmiwVJj4Z4Wv+7FX9O3uF8GsdGlZRDuSoc8PY6sXrI/UfxUh868K6K6CMnSrNv2x3udDnrF/OuAL4NRkydwhOzm6QCs+CVSJmRCLXg3viUSv3PzXPWUC+iYewhWbRDoybp4HJd+PCMRnToUQ3lijxe0Mc+KQOJXRP9LLHNTMfGa3DK0EUNq218Dc3Yo3CumikRkyXhFcz3LUEYf4lxkbdmz5Tnrsa2BSXUfwoZy4nyLsP7jtw5EuBP1P24gSIwn0V3v842l/nGRebSnA4yR9SitRqlkADsqt5OIc4e8CLxg9erd1QzUNqXNluwHZI4SBYsuf+fJ+3IgTdarlMrqfAJpOcgJGEH8KakzKo7Z1EdAuA8IalsNjUym8FI2NP7 X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB153; 5:FNtO3qBmEs7m4WXO/w8JRAwAmtR509xWByYe8agj14w23h3lJoNq+MCCtLA1ACeXcmfOmcTB/xk8JKG5zr9oyiOVBlY6BgBiVmlBBnLdOZHTPGRK4Tv8vdsL6JnN7Z3/x99Qle36kQ4fEkxTxXkpeg==; 24:Lx0Xfrg7J6HlC7DWXKItSMspLDOD1f7JPVPOo+KZWANsgusC9dpeyT87haxGTxS0mJz2+MOrKn71+xs6dVbv8BSWfDkAWQBUAVch3MLiKq4=; 20:e6/s+wJTMWOY/1aHz3/PDpE+AsNhYuLejB1ZzMzTxCR9rPbGLoKyPjRQVeKR+lwxjCE3FCzHxCd25k4ClEu77A== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Jul 2015 18:49:25.5150 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB153 Archived-At: X-Mailman-Approved-At: Thu, 09 Jul 2015 11:57:45 -0700 Cc: "idr-chairs@ietf.org" , "draft-ietf-idr-flowspec-redirect-rt-bis@tools.ietf.org" , "idr@ietf.org" Subject: Re: [Idr] AD Review of draft-ietf-idr-flowspec-redirect-rt-bis 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 Jul 2015 18:49:29 -0000 --Apple-Mail=_20E3B644-7F42-4422-B763-988057A6F884 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="windows-1252" > On Jul 9, 2015, at 2:27 PM, Alvaro Retana (aretana) = wrote: >=20 > On 7/9/15, 2:18 PM, "Alvaro Retana (aretana)" > wrote: >=20 > Just read this draft, and I only have a small nit to talk about: In = section 2, please add a subsection for the "BGP Transitive Extended = Community Types=94 update. Right now the update text is in 2.1. >=20 > I actually have another nit: I don=92t see rfc5668 and rfc7153 as = normative for this draft and should be informational. Just a nit.. I will push mildly for normative. Understanding of the encoding formats = in those documents is necessary context for the related encoding in this = document. -- Jeff >=20 > Thanks! >=20 > Alvaro. --Apple-Mail=_20E3B644-7F42-4422-B763-988057A6F884 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="windows-1252"
On Jul 9, 2015, at 2:27 PM, Alvaro Retana (aretana) <aretana@cisco.com> = wrote:

On 7/9/15, 2:18 PM, "Alvaro Retana (aretana)" <aretana@cisco.com> = wrote:

Just read this draft, and I only have a small nit to talk about: =  In section 2, please add a subsection for the "BGP Transitive = Extended Community Types=94 update.  Right now the update text is = in 2.1.

I actually have another nit: I don=92t see rfc5668 and = rfc7153 as normative for this draft and should be informational. =  Just a nit..

I will push mildly for normative.  Understanding = of the encoding formats in those documents is necessary context for the = related encoding in this document.

-- = Jeff


Thanks!

Alvaro.

= --Apple-Mail=_20E3B644-7F42-4422-B763-988057A6F884-- From nobody Thu Jul 9 13:24: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 7D2E61A011D for ; Thu, 9 Jul 2015 13:24:12 -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 Q2f7uu2Hmp1t for ; Thu, 9 Jul 2015 13:24:11 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7931A0115 for ; Thu, 9 Jul 2015 13:24:11 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id B71A81E433; Thu, 9 Jul 2015 16:25:54 -0400 (EDT) Date: Thu, 9 Jul 2015 16:25:54 -0400 From: Jeffrey Haas To: idr@ietf.org Message-ID: <20150709202554.GC13783@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: draft-vandevelde-idr-ipv6-flowspec-imp@tools.ietf.org Subject: [Idr] Comments on draft-vandevelde-idr-ipv6-flowspec-imp 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 Jul 2015 20:24:12 -0000 I would like to encourage the authors to clarify interop point E3: o E3: Extended Community - redirect In particular, this is because redirect communities have gotten some recent scrutiny. draft-ietf-idr-flow-spec-v6-06 adds support for RFC 5701 with a new redirect community. draft-ietf-idr-flowspec-redirect-rt-bis-04, which is in IETF Last Call, clarifies existing redirect behaviors. Finally, the interop report itself seems to include a redirect example that appears to be an instance of draft-ietf-idr-flowspec-redirect-ip-02. As an early data point, Juniper does not currently support VRFs using IPv6-specific route-targets, nor the IPv6-specific community referenced in the flowspec-v6 draft. -- Jeff ----- Forwarded message from IETF Secretariat ----- Date: Thu, 02 Jul 2015 08:25:01 -0700 From: IETF Secretariat To: jhaas@pfrc.org Subject: Personal ID list of jhaas@pfrc.org notification: Changes on draft-vandevelde-idr-ipv6-flowspec-imp Hello, This is a notification from the Personal ID list of jhaas@pfrc.org. Document: draft-vandevelde-idr-ipv6-flowspec-imp, https://datatracker.ietf.org/doc/draft-vandevelde-idr-ipv6-flowspec-imp Change: New version available: *draft-vandevelde-idr-ipv6-flowspec-imp-02.txt* Best regards, The datatracker draft tracking service (for the IETF Secretariat) ----- End forwarded message ----- From nobody Thu Jul 9 15:16: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 D5EE01A1B05 for ; Thu, 9 Jul 2015 15:16: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, 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 Ea5ay1CCzty0 for ; Thu, 9 Jul 2015 15:16:21 -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 D58D21A1AFC for ; Thu, 9 Jul 2015 15:16:20 -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 BYO93089; Thu, 09 Jul 2015 22:16:19 +0000 (GMT) Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 9 Jul 2015 23:16:19 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml702-chm ([10.193.5.72]) with mapi id 14.03.0235.001; Thu, 9 Jul 2015 15:16:06 -0700 From: Lucy yong To: Susan Hares , "'idr wg list'" Thread-Topic: [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00.txt (7/6 to 7/20/2015) Thread-Index: AdC4UJG6Pj+U9ACORa+TFqfDTB54DgCOU6eA Date: Thu, 9 Jul 2015 22:16:05 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D571ADA7E@dfweml701-chm> References: <02ce01d0b851$4ecec5a0$ec6c50e0$@ndzh.com> In-Reply-To: <02ce01d0b851$4ecec5a0$ec6c50e0$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.158.168] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D571ADA7Edfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "'Keyur Patel \(keyupate\)'" Subject: Re: [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00.txt (7/6 to 7/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: Thu, 09 Jul 2015 22:16:24 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D571ADA7Edfweml701chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support WG adoption! This is very useful work. The need for BGP next hop an= d tunnel EP separation has been talked for a while. The draft is quite new. We need think more on the mechanism and rules. For example, is it necessary to require specifying a sub-TLV for each encap= sulation type? Comments: Why does VXLAN encapsulation sub-TLV contain a MAC address, isn't the MAC c= arried by the NLRI? It should support tunnel stitching at a router, i.e. the tunnel endpoint; u= pon receiving a UPDATE, the router removes the tunnel encapsulation TLV and= /or sub-TLV on the UPDATE and inserts a new one prior to sending it out. In the case of recursive next hop, does it require tunnel ingress router ha= ve the reachable for all the remote end points? IMO: it shouldn't. Cheers, Lucy From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Monday, July 06, 2015 8:08 PM To: 'idr wg list' Cc: 'Keyur Patel (keyupate)' Subject: [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00.txt= (7/6 to 7/20/2015) This begins a 2 week adoption call on draft-rosen-idr-tunnel-encaps-00.txt = (7/6 to 7/20/2015). The draft can be found at: https://www.ietf.org/internet-drafts/draft-rosen-idr-tunnel-encaps-00.txt In your response, discuss why this draft proposal for encapsulation: a) [operators] will help deployed networks, b) Solves know problems with other tunnel encapsulation, and c) Provides a way to manage the matrix of tunnels. We will have a status report at IDR on 7/20 on this Working group adoption = call. Sue Hares and John Scudder --_000_2691CE0099834E4A9C5044EEC662BB9D571ADA7Edfweml701chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support WG adoption! This= is very useful work. The need for BGP next hop and tunnel EP separation ha= s been talked for a while.

 <= /p>

The draft is quite new. W= e need think more on the mechanism and rules.

 <= /p>

For example, is it necess= ary to require specifying a sub-TLV for each encapsulation type?

 <= /p>

Comments:

Why does VXLAN encapsulat= ion sub-TLV contain a MAC address, isn’t the MAC carried by the NLRI?

It should support tunnel = stitching at a router, i.e. the tunnel endpoint; upon receiving a UPDATE, t= he router removes the tunnel encapsulation TLV and/or sub-TLV on the UPDATE and inserts a new one prior to sending it out.

In the case of recursive = next hop, does it require tunnel ingress router have the reachable for all = the remote end points? IMO: it shouldn’t.

 <= /p>

Cheers,=

Lucy

 <= /p>

 <= /p>

 <= /p>

 <= /p>

From: Idr [mai= lto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Monday, July 06, 2015 8:08 PM
To: 'idr wg list'
Cc: 'Keyur Patel (keyupate)'
Subject: [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps= -00.txt (7/6 to 7/20/2015)

 

This begins a 2 week adopti= on call on draft-rosen-idr-tunnel-encaps-00.txt (7/6 to 7/20/2015).

The draft can be found at:

 

https://www.ietf.org/interne= t-drafts/draft-rosen-idr-tunnel-encaps-00.txt

 

In your response, discuss why this draf= t proposal for encapsulation:

a= )   &= nbsp;  [operators] will help deployed = networks,

b= )   &= nbsp;  Solves know problems with other= tunnel encapsulation, and

c= )   &= nbsp;   Provides a way to manage the ma= trix of tunnels.

 

 

We will have a status report at IDR on = 7/20 on this Working group adoption call.

 

Sue Hares and John Scudder

--_000_2691CE0099834E4A9C5044EEC662BB9D571ADA7Edfweml701chm_-- From nobody Thu Jul 9 19:00: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 39EEA1A6F12 for ; Thu, 9 Jul 2015 19:00:40 -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 m4qAkjApOQLR for ; Thu, 9 Jul 2015 19:00:37 -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 D581E1A1BEC for ; Thu, 9 Jul 2015 19:00:36 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BYP03322; Fri, 10 Jul 2015 02:00:35 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 10 Jul 2015 03:00:34 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.233]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Fri, 10 Jul 2015 10:00:26 +0800 From: Haoweiguo To: Lucy yong , Susan Hares , "'idr wg list'" Thread-Topic: [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00.txt (7/6 to 7/20/2015) Thread-Index: AdC4UJG6Pj+U9ACORa+TFqfDTB54DgCOU6eAAApncwI= Date: Fri, 10 Jul 2015 02:00:26 +0000 Message-ID: References: <02ce01d0b851$4ecec5a0$ec6c50e0$@ndzh.com>, <2691CE0099834E4A9C5044EEC662BB9D571ADA7E@dfweml701-chm> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D571ADA7E@dfweml701-chm> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.23.94] Content-Type: multipart/alternative; boundary="_000_DD5FC8DE455C3348B94340C0AB5517334F882423nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "'Keyur Patel \(keyupate\)'" Subject: Re: [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00.txt (7/6 to 7/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: Fri, 10 Jul 2015 02:00:40 -0000 --_000_DD5FC8DE455C3348B94340C0AB5517334F882423nkgeml501mbschi_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable As for the MAC address advertisement mode, this draft seems to be conflicte= d with EVPN draft-ietf-bess-evpn-inter-subnet-forwarding-00. In the EVPN dr= aft, if VXLAN/NVGRE tunnel is used, the remote NVE advertises its MAC throu= gh Router's MAC Extended Community, the MAC will be used as inner destinati= on MAC for inter-subnet traffic forwarding. Thanks, weiguo ________________________________ From: Idr [idr-bounces@ietf.org] on behalf of Lucy yong [lucy.yong@huawei.c= om] Sent: Friday, July 10, 2015 6:16 To: Susan Hares; 'idr wg list' Cc: 'Keyur Patel (keyupate)' Subject: Re: [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00= .txt (7/6 to 7/20/2015) Support WG adoption! This is very useful work. The need for BGP next hop an= d tunnel EP separation has been talked for a while. The draft is quite new. We need think more on the mechanism and rules. For example, is it necessary to require specifying a sub-TLV for each encap= sulation type? Comments: Why does VXLAN encapsulation sub-TLV contain a MAC address, isn=92t the MAC= carried by the NLRI? It should support tunnel stitching at a router, i.e. the tunnel endpoint; u= pon receiving a UPDATE, the router removes the tunnel encapsulation TLV and= /or sub-TLV on the UPDATE and inserts a new one prior to sending it out. In the case of recursive next hop, does it require tunnel ingress router ha= ve the reachable for all the remote end points? IMO: it shouldn=92t. Cheers, Lucy From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Monday, July 06, 2015 8:08 PM To: 'idr wg list' Cc: 'Keyur Patel (keyupate)' Subject: [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00.txt= (7/6 to 7/20/2015) This begins a 2 week adoption call on draft-rosen-idr-tunnel-encaps-00.txt = (7/6 to 7/20/2015). The draft can be found at: https://www.ietf.org/internet-drafts/draft-rosen-idr-tunnel-encaps-00.txt In your response, discuss why this draft proposal for encapsulation: a) [operators] will help deployed networks, b) Solves know problems with other tunnel encapsulation, and c) Provides a way to manage the matrix of tunnels. We will have a status report at IDR on 7/20 on this Working group adoption = call. Sue Hares and John Scudder --_000_DD5FC8DE455C3348B94340C0AB5517334F882423nkgeml501mbschi_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

As for the MAC address advertisement m= ode, this draft seems to be conflicted with EVPN draft-ietf-bess-evpn-inter= -subnet-forwarding-00. In the EVPN draft, if VXLAN/NVGRE tunnel is used, th= e remote NVE advertises its MAC through Router's MAC Extended Community, the MAC will be used as inner dest= ination MAC for inter-subnet traffic forwarding.

Thanks,

weiguo

From: Idr [idr-bounces@ietf.org] on behalf= of Lucy yong [lucy.yong@huawei.com]
Sent: Friday, July 10, 2015 6:16
To: Susan Hares; 'idr wg list'
Cc: 'Keyur Patel (keyupate)'
Subject: Re: [Idr] 2 week adoption call for draft-rosen-idr-tunnel-e= naps-00.txt (7/6 to 7/20/2015)

Support WG adoption! This is very useful w= ork. The need for BGP next hop and tunnel EP separation has been talked for= a while.

 

The draft is quite new. We need think more= on the mechanism and rules.

 

For example, is it necessary to require sp= ecifying a sub-TLV for each encapsulation type?

 

Comments:

Why does VXLAN encapsulation sub-TLV conta= in a MAC address, isn=92t the MAC carried by the NLRI?

It should support tunnel stitching at a ro= uter, i.e. the tunnel endpoint; upon receiving a UPDATE, the router removes= the tunnel encapsulation TLV and/or sub-TLV on the UPDATE and inserts a new one prior to sending it out.

In the case of recursive next hop, does it= require tunnel ingress router have the reachable for all the remote end po= ints? IMO: it shouldn=92t.

 

Cheers,

Lucy

 

 

 

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Monday, July 06, 2015 8:08 PM
To: 'idr wg list'
Cc: 'Keyur Patel (keyupate)'
Subject: [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps= -00.txt (7/6 to 7/20/2015)

 

This begins a 2 week adoption call on draf= t-rosen-idr-tunnel-encaps-00.txt (7/6 to 7/20/2015).

The draft can be found at:

 

https://www.ietf.org/internet= -drafts/draft-rosen-idr-tunnel-encaps-00.txt

 

In your response, discuss why this draft proposal for enca= psulation:

a)      [operators] will help deployed networks,

b)      Solves know problems with other tunnel encapsulation, and

c)       Provides a way to manage the matrix of tunnels.

 

 

We will have a status report at IDR on 7/20 on this Workin= g group adoption call.

 

Sue Hares and John Scudder

--_000_DD5FC8DE455C3348B94340C0AB5517334F882423nkgeml501mbschi_-- From nobody Fri Jul 10 01:03: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 8D6EE1A8968 for ; Fri, 10 Jul 2015 01:03:03 -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 8BZChfgaeJNU for ; Fri, 10 Jul 2015 01:03:01 -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 1288D1A8967 for ; Fri, 10 Jul 2015 01:03:01 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id C1C839778EC12; Fri, 10 Jul 2015 08:02:57 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t6A82v0l004281 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 10 Jul 2015 10:02:57 +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; Fri, 10 Jul 2015 10:02:57 +0200 From: "Henderickx, Wim (Wim)" To: Lucy yong , Susan Hares , "'idr wg list'" Thread-Topic: [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00.txt (7/6 to 7/20/2015) Thread-Index: AdC4UJG6Pj+U9ACORa+TFqfDTB54DgCOU6eAABc7fQA= Date: Fri, 10 Jul 2015 08:02:56 +0000 Message-ID: <0675CC78-A117-49C8-AFD5-D35CF64E2557@alcatel-lucent.com> References: <02ce01d0b851$4ecec5a0$ec6c50e0$@ndzh.com> <2691CE0099834E4A9C5044EEC662BB9D571ADA7E@dfweml701-chm> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D571ADA7E@dfweml701-chm> Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.150618 x-originating-ip: [135.239.27.40] Content-Type: multipart/alternative; boundary="_000_0675CC78A11749C8AFD5D35CF64E2557alcatellucentcom_" MIME-Version: 1.0 Archived-At: Cc: "'Keyur Patel \(keyupate\)'" Subject: Re: [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00.txt (7/6 to 7/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: Fri, 10 Jul 2015 08:03:03 -0000 --_000_0675CC78A11749C8AFD5D35CF64E2557alcatellucentcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSB0aGF0IHdlIG5lZWQgc29tZSBjbGFyaWZpY2F0aW9uIG9uIFZYTEFOIGVuY2Fwc3Vs YXRpb24gc2luY2UgdGhlIE1BQyBkb2VzIG5vdCBtYWtlIHNlbnNlIGRlcGVuZGluZyBvbiB0aGUg c2NlbmFyaW8uIEUuZy4gSW4gbW9zdCBFVlBOIHlvdSBkb27igJl0IHdhbnQgYW55IE1BQyBlbmNv ZGluZyBpbiB0aGlzIG5ldyBhdHRyaWJ1dGUuIEluIG90aGVyIHNjZW5hcmlv4oCZcyBpdCBtaWdo dCBtYWtlIG1vcmUgc2Vuc2UgdG8gaW5jbHVkZSBpdA0KDQpGcm9tOiBJZHIgb24gYmVoYWxmIG9m IEx1Y3kgeW9uZw0KRGF0ZTogRnJpZGF5IDEwIEp1bHkgMjAxNSAwMDoxNg0KVG86IFN1c2FuIEhh cmVzLCAnaWRyIHdnIGxpc3QnDQpDYzogS2V5dXIgUGF0ZWwNClN1YmplY3Q6IFJlOiBbSWRyXSAy IHdlZWsgYWRvcHRpb24gY2FsbCBmb3IgZHJhZnQtcm9zZW4taWRyLXR1bm5lbC1lbmFwcy0wMC50 eHQgKDcvNiB0byA3LzIwLzIwMTUpDQoNClN1cHBvcnQgV0cgYWRvcHRpb24hIFRoaXMgaXMgdmVy eSB1c2VmdWwgd29yay4gVGhlIG5lZWQgZm9yIEJHUCBuZXh0IGhvcCBhbmQgdHVubmVsIEVQIHNl cGFyYXRpb24gaGFzIGJlZW4gdGFsa2VkIGZvciBhIHdoaWxlLg0KDQpUaGUgZHJhZnQgaXMgcXVp dGUgbmV3LiBXZSBuZWVkIHRoaW5rIG1vcmUgb24gdGhlIG1lY2hhbmlzbSBhbmQgcnVsZXMuDQoN CkZvciBleGFtcGxlLCBpcyBpdCBuZWNlc3NhcnkgdG8gcmVxdWlyZSBzcGVjaWZ5aW5nIGEgc3Vi LVRMViBmb3IgZWFjaCBlbmNhcHN1bGF0aW9uIHR5cGU/DQoNCkNvbW1lbnRzOg0KV2h5IGRvZXMg VlhMQU4gZW5jYXBzdWxhdGlvbiBzdWItVExWIGNvbnRhaW4gYSBNQUMgYWRkcmVzcywgaXNu4oCZ dCB0aGUgTUFDIGNhcnJpZWQgYnkgdGhlIE5MUkk/DQpJdCBzaG91bGQgc3VwcG9ydCB0dW5uZWwg c3RpdGNoaW5nIGF0IGEgcm91dGVyLCBpLmUuIHRoZSB0dW5uZWwgZW5kcG9pbnQ7IHVwb24gcmVj ZWl2aW5nIGEgVVBEQVRFLCB0aGUgcm91dGVyIHJlbW92ZXMgdGhlIHR1bm5lbCBlbmNhcHN1bGF0 aW9uIFRMViBhbmQvb3Igc3ViLVRMViBvbiB0aGUgVVBEQVRFIGFuZCBpbnNlcnRzIGEgbmV3IG9u ZSBwcmlvciB0byBzZW5kaW5nIGl0IG91dC4NCkluIHRoZSBjYXNlIG9mIHJlY3Vyc2l2ZSBuZXh0 IGhvcCwgZG9lcyBpdCByZXF1aXJlIHR1bm5lbCBpbmdyZXNzIHJvdXRlciBoYXZlIHRoZSByZWFj aGFibGUgZm9yIGFsbCB0aGUgcmVtb3RlIGVuZCBwb2ludHM/IElNTzogaXQgc2hvdWxkbuKAmXQu DQoNCkNoZWVycywNCkx1Y3kNCg0KDQoNCg0KRnJvbTogSWRyIFttYWlsdG86aWRyLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTdXNhbiBIYXJlcw0KU2VudDogTW9uZGF5LCBKdWx5IDA2 LCAyMDE1IDg6MDggUE0NClRvOiAnaWRyIHdnIGxpc3QnDQpDYzogJ0tleXVyIFBhdGVsIChrZXl1 cGF0ZSknDQpTdWJqZWN0OiBbSWRyXSAyIHdlZWsgYWRvcHRpb24gY2FsbCBmb3IgZHJhZnQtcm9z ZW4taWRyLXR1bm5lbC1lbmFwcy0wMC50eHQgKDcvNiB0byA3LzIwLzIwMTUpDQoNClRoaXMgYmVn aW5zIGEgMiB3ZWVrIGFkb3B0aW9uIGNhbGwgb24gZHJhZnQtcm9zZW4taWRyLXR1bm5lbC1lbmNh cHMtMDAudHh0ICg3LzYgdG8gNy8yMC8yMDE1KS4NClRoZSBkcmFmdCBjYW4gYmUgZm91bmQgYXQ6 DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1yb3Nlbi1pZHIt dHVubmVsLWVuY2Fwcy0wMC50eHQNCg0KSW4geW91ciByZXNwb25zZSwgZGlzY3VzcyB3aHkgdGhp cyBkcmFmdCBwcm9wb3NhbCBmb3IgZW5jYXBzdWxhdGlvbjoNCg0KYSkgICAgICBbb3BlcmF0b3Jz XSB3aWxsIGhlbHAgZGVwbG95ZWQgbmV0d29ya3MsDQoNCmIpICAgICAgU29sdmVzIGtub3cgcHJv YmxlbXMgd2l0aCBvdGhlciB0dW5uZWwgZW5jYXBzdWxhdGlvbiwgYW5kDQoNCmMpICAgICAgIFBy b3ZpZGVzIGEgd2F5IHRvIG1hbmFnZSB0aGUgbWF0cml4IG9mIHR1bm5lbHMuDQoNCg0KV2Ugd2ls bCBoYXZlIGEgc3RhdHVzIHJlcG9ydCBhdCBJRFIgb24gNy8yMCBvbiB0aGlzIFdvcmtpbmcgZ3Jv dXAgYWRvcHRpb24gY2FsbC4NCg0KU3VlIEhhcmVzIGFuZCBKb2huIFNjdWRkZXINCg== --_000_0675CC78A11749C8AFD5D35CF64E2557alcatellucentcom_ Content-Type: text/html; charset="utf-8" Content-ID: <2C8916740838BB4D9B4AC71CB09CBAEF@exchange.lucent.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2PkkgYWdyZWUgdGhhdCB3ZSBuZWVkIHNvbWUgY2xhcmlmaWNhdGlvbiBvbiBWWExBTiBlbmNh cHN1bGF0aW9uIHNpbmNlIHRoZSBNQUMgZG9lcyBub3QgbWFrZSBzZW5zZSBkZXBlbmRpbmcgb24g dGhlIHNjZW5hcmlvLiBFLmcuIEluIG1vc3QgRVZQTiB5b3UgZG9u4oCZdCB3YW50IGFueSBNQUMg ZW5jb2RpbmcgaW4gdGhpcyBuZXcgYXR0cmlidXRlLiBJbiBvdGhlciBzY2VuYXJpb+KAmXMgaXQg bWlnaHQgbWFrZSBtb3JlIHNlbnNlIHRvIGluY2x1ZGUNCiBpdDwvZGl2Pg0KPGRpdj4NCjxkaXYg aWQ9Ik1BQ19PVVRMT09LX1NJR05BVFVSRSI+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxk aXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMnB0OyB0ZXh0LWFsaWdu OmxlZnQ7IGNvbG9yOmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxF RlQ6IG1lZGl1bSBub25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxFRlQ6IDBpbjsg UEFERElORy1SSUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9SREVS LVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBzdHlsZT0iZm9u dC13ZWlnaHQ6Ym9sZCI+RnJvbTogPC9zcGFuPklkciBvbiBiZWhhbGYgb2YgTHVjeSB5b25nPGJy Pg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5GcmlkYXkgMTAg SnVseSAyMDE1IDAwOjE2PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8 L3NwYW4+U3VzYW4gSGFyZXMsICdpZHIgd2cgbGlzdCc8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13 ZWlnaHQ6Ym9sZCI+Q2M6IDwvc3Bhbj5LZXl1ciBQYXRlbDxicj4NCjxzcGFuIHN0eWxlPSJmb250 LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+UmU6IFtJZHJdIDIgd2VlayBhZG9wdGlvbiBj YWxsIGZvciBkcmFmdC1yb3Nlbi1pZHItdHVubmVsLWVuYXBzLTAwLnR4dCAoNy82IHRvIDcvMjAv MjAxNSk8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2IHhtbG5zOnY9InVybjpz Y2hlbWFzLW1pY3Jvc29mdC1jb206dm1sIiB4bWxuczpvPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQt Y29tOm9mZmljZTpvZmZpY2UiIHhtbG5zOnc9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOndvcmQiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vb2ZmaWNlLzIw MDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpTaW1TdW47DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIg NCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0K CXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IlxAU2ltU3VuIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAx O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBk aXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgs IGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1w cmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdp bi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNl cmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0K c3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlk OjIwMjM3NzYwMDI7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUt aWRzOjEzNjIzMTE5MCA2NzY5ODcxMSA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcx MyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMDpsZXZlbDEN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRleHQ6 IiUxXCkiOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxv d2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGww OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRl eHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEt bG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4w cHQ7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47 fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm XS0tPg0KPGRpdiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9y OiByZ2IoMzEsIDczLCAxMjUpOyI+U3VwcG9ydCBXRyBhZG9wdGlvbiEgVGhpcyBpcyB2ZXJ5IHVz ZWZ1bCB3b3JrLiBUaGUgbmVlZCBmb3IgQkdQIG5leHQgaG9wIGFuZCB0dW5uZWwgRVAgc2VwYXJh dGlvbiBoYXMgYmVlbiB0YWxrZWQgZm9yIGEgd2hpbGUuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250 LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsg Y29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij5UaGUgZHJhZnQgaXMgcXVpdGUgbmV3LiBXZSBuZWVk IHRoaW5rIG1vcmUgb24gdGhlIG1lY2hhbmlzbSBhbmQgcnVsZXMuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsg Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUp OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy aWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+Rm9yIGV4YW1wbGUsIGlzIGl0IG5lY2Vzc2Fy eSB0byByZXF1aXJlIHNwZWNpZnlpbmcgYSBzdWItVExWIGZvciBlYWNoIGVuY2Fwc3VsYXRpb24g dHlwZT8NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQt ZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPkNv bW1lbnRzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPldoeSBkb2VzIFZYTEFOIGVuY2Fwc3VsYXRpb24g c3ViLVRMViBjb250YWluIGEgTUFDIGFkZHJlc3MsIGlzbuKAmXQgdGhlIE1BQyBjYXJyaWVkIGJ5 IHRoZSBOTFJJPw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+SXQgc2hvdWxkIHN1cHBvcnQgdHVubmVs IHN0aXRjaGluZyBhdCBhIHJvdXRlciwgaS5lLiB0aGUgdHVubmVsIGVuZHBvaW50OyB1cG9uIHJl Y2VpdmluZyBhIFVQREFURSwgdGhlIHJvdXRlciByZW1vdmVzIHRoZSB0dW5uZWwgZW5jYXBzdWxh dGlvbiBUTFYNCiBhbmQvb3Igc3ViLVRMViBvbiB0aGUgVVBEQVRFIGFuZCBpbnNlcnRzIGEgbmV3 IG9uZSBwcmlvciB0byBzZW5kaW5nIGl0IG91dC4gPG86cD4NCjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij5JbiB0 aGUgY2FzZSBvZiByZWN1cnNpdmUgbmV4dCBob3AsIGRvZXMgaXQgcmVxdWlyZSB0dW5uZWwgaW5n cmVzcyByb3V0ZXIgaGF2ZSB0aGUgcmVhY2hhYmxlIGZvciBhbGwgdGhlIHJlbW90ZSBlbmQgcG9p bnRzPyBJTU86IGl0IHNob3VsZG7igJl0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBD YWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdi KDMxLCA3MywgMTI1KTsiPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij5MdWN5PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEs IDczLCAxMjUpOyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmks IHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTog MTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDcz LCAxMjUpOyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBUYWhv bWEsIHNhbnMtc2VyaWY7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTog MTBwdDsgZm9udC1mYW1pbHk6IFRhaG9tYSwgc2Fucy1zZXJpZjsiPiBJZHIgWzxhIGhyZWY9Im1h aWx0bzppZHItYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmlkci1ib3VuY2VzQGlldGYub3JnPC9h Pl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+U3VzYW4gSGFyZXM8YnI+DQo8Yj5TZW50OjwvYj4gTW9u ZGF5LCBKdWx5IDA2LCAyMDE1IDg6MDggUE08YnI+DQo8Yj5Ubzo8L2I+ICdpZHIgd2cgbGlzdCc8 YnI+DQo8Yj5DYzo8L2I+ICdLZXl1ciBQYXRlbCAoa2V5dXBhdGUpJzxicj4NCjxiPlN1YmplY3Q6 PC9iPiBbSWRyXSAyIHdlZWsgYWRvcHRpb24gY2FsbCBmb3IgZHJhZnQtcm9zZW4taWRyLXR1bm5l bC1lbmFwcy0wMC50eHQgKDcvNiB0byA3LzIwLzIwMTUpPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IGJsYWNrOyI+VGhpcyBiZWdp bnMgYSAyIHdlZWsgYWRvcHRpb24gY2FsbCBvbiBkcmFmdC1yb3Nlbi1pZHItdHVubmVsLWVuY2Fw cy0wMC50eHQgKDcvNiB0byA3LzIwLzIwMTUpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1p bHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiBibGFjazsiPlRoZSBkcmFmdCBjYW4gYmUg Zm91bmQgYXQ6DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyBjb2xvcjogYmxhY2s7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWls eTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2lu dGVybmV0LWRyYWZ0cy9kcmFmdC1yb3Nlbi1pZHItdHVubmVsLWVuY2Fwcy0wMC50eHQiPmh0dHBz Oi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1yb3Nlbi1pZHItdHVubmVsLWVu Y2Fwcy0wMC50eHQ8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwg c2Fucy1zZXJpZjsiPkluIHlvdXIgcmVzcG9uc2UsIGRpc2N1c3Mgd2h5IHRoaXMgZHJhZnQgcHJv cG9zYWwgZm9yIGVuY2Fwc3VsYXRpb246PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAg bGV2ZWwxIGxmbzIiPjwhLS1baWYgIXN1cHBvcnRMaXN0c10tLT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPmEpPHNwYW4gc3R5bGU9ImZv bnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3Jt YWw7IGZvbnQtc2l6ZTogN3B0OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogJ1Rp bWVzIE5ldyBSb21hbic7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48 L3NwYW4+PC9zcGFuPjwhLS1bZW5kaWZdLS0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsg Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij5bb3BlcmF0b3JzXSB3aWxsIGhlbHAg ZGVwbG95ZWQgbmV0d29ya3MsDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv TGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZl bDEgbGZvMiI+PCEtLVtpZiAhc3VwcG9ydExpc3RzXS0tPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+Yik8c3BhbiBzdHlsZT0iZm9udC1z dHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsg Zm9udC1zaXplOiA3cHQ7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiAnVGltZXMg TmV3IFJvbWFuJzsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bh bj48L3NwYW4+PCEtLVtlbmRpZl0tLT48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250 LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPlNvbHZlcyBrbm93IHByb2JsZW1zIHdpdGgg b3RoZXIgdHVubmVsIGVuY2Fwc3VsYXRpb24sIGFuZA0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNv LWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPjwhLS1baWYgIXN1cHBvcnRMaXN0c10tLT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPmMpPHNwYW4g c3R5bGU9ImZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2Vp Z2h0OiBub3JtYWw7IGZvbnQtc2l6ZTogN3B0OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZh bWlseTogJ1RpbWVzIE5ldyBSb21hbic7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhLS1bZW5kaWZdLS0+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij5Qcm92aWRl cyBhIHdheSB0byBtYW5hZ2UgdGhlIG1hdHJpeCBvZiB0dW5uZWxzLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7 IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFw dDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAx MXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPldlIHdpbGwgaGF2ZSBhIHN0 YXR1cyByZXBvcnQgYXQgSURSIG9uIDcvMjAgb24gdGhpcyBXb3JraW5nIGdyb3VwIGFkb3B0aW9u IGNhbGwuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl cmlmOyI+U3VlIEhhcmVzIGFuZCBKb2huIFNjdWRkZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_0675CC78A11749C8AFD5D35CF64E2557alcatellucentcom_-- From nobody Fri Jul 10 06:53: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 7F1001A8948 for ; Fri, 10 Jul 2015 06:53:51 -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 a-4jMx0-haXD for ; Fri, 10 Jul 2015 06:53:47 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0725.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::725]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72FCA1ACE51 for ; Fri, 10 Jul 2015 06:53:47 -0700 (PDT) Received: from BLUPR05MB562.namprd05.prod.outlook.com (10.141.202.141) by BLUPR05MB563.namprd05.prod.outlook.com (10.141.202.144) with Microsoft SMTP Server (TLS) id 15.1.207.19; Fri, 10 Jul 2015 13:53:28 +0000 Received: from BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) by BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) with mapi id 15.01.0207.004; Fri, 10 Jul 2015 13:53:27 +0000 From: John E Drake To: Haoweiguo , Lucy yong , "Susan Hares" , 'idr wg list' Thread-Topic: [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00.txt (7/6 to 7/20/2015) Thread-Index: AdC4UJG6Pj+U9ACORa+TFqfDTB54DgCOU6eAAApncwIAGNjS8A== Date: Fri, 10 Jul 2015 13:53:27 +0000 Message-ID: References: <02ce01d0b851$4ecec5a0$ec6c50e0$@ndzh.com>, <2691CE0099834E4A9C5044EEC662BB9D571ADA7E@dfweml701-chm> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: huawei.com; dkim=none (message not signed) header.d=none; x-originating-ip: [66.129.241.13] x-microsoft-exchange-diagnostics: 1; BLUPR05MB563; 5:S6ChZ563AZTHn7oE/m+6T0PuYc9jM09W/0nT2AT6s38Jvhhv8dsl+DDRW3Pf/xv+E6BaOzs5Ob+SccDwLMjD6wcek3CRhvi5GvZaPxecK6buAa6ynm6XnXZ+TnARYxDZwdxje3ULRD0Lpv/67u1zEw==; 24:t4if4ah3o9HpR2pPPMMbO+LXxbzWO+0gbHkYsKehBdtn43NwRXdLqbbD6+3uX0MbRHeLuCYOK884sdiK7ZjZx13hbG781FY/MuONbJGAUlY=; 20:+tgglRurmnAxUq0lez2qe4jh6J+0DE38NJnqea6EBhHwV4B54JsCym4iOI9kR4ojo805EWFTVTwBvloqj5b4aQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB563; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BLUPR05MB563; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB563; x-forefront-prvs: 06339BAE63 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(5423002)(479174004)(377454003)(164054003)(5001770100001)(46102003)(19617315012)(230783001)(92566002)(2656002)(76576001)(86362001)(19609705001)(50986999)(87936001)(66066001)(16236675004)(54356999)(76176999)(19300405004)(19580395003)(189998001)(19580405001)(40100003)(99286002)(19625215002)(5002640100001)(5003600100002)(77096005)(561944003)(15975445007)(102836002)(2950100001)(77156002)(33656002)(62966003)(74316001)(5001960100002)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB563; H:BLUPR05MB562.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_BLUPR05MB562CE6F2B312FC9BDAB331EC79F0BLUPR05MB562namprd_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jul 2015 13:53:27.5568 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB563 Archived-At: Cc: "'Keyur Patel \(keyupate\)'" Subject: Re: [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00.txt (7/6 to 7/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: Fri, 10 Jul 2015 13:53:51 -0000 --_000_BLUPR05MB562CE6F2B312FC9BDAB331EC79F0BLUPR05MB562namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Weiguo, A number of the EVPN drafts use the RFC 5512 extended community and they wi= ll continue to do so. As I'm sure you're aware, there is not a lot of room= in an extended community, and this draft is intended to be used for future= applications, e.g., EVPN, L3VPN, or Softwires, that need more room or mor= e capabilities. This is the same positioning that we used with the previous remote next hop= draft which this draft replaces. Yours Irrespectively, John From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Haoweiguo Sent: Thursday, July 09, 2015 10:00 PM To: Lucy yong; Susan Hares; 'idr wg list' Cc: 'Keyur Patel (keyupate)' Subject: Re: [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00= .txt (7/6 to 7/20/2015) As for the MAC address advertisement mode, this draft seems to be conflicte= d with EVPN draft-ietf-bess-evpn-inter-subnet-forwarding-00. In the EVPN dr= aft, if VXLAN/NVGRE tunnel is used, the remote NVE advertises its MAC throu= gh Router's MAC Extended Community, the MAC will be used as inner destinati= on MAC for inter-subnet traffic forwarding. Thanks, weiguo ________________________________ From: Idr [idr-bounces@ietf.org] on behalf of Lucy yong [lucy.yong@huawei.c= om] Sent: Friday, July 10, 2015 6:16 To: Susan Hares; 'idr wg list' Cc: 'Keyur Patel (keyupate)' Subject: Re: [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00= .txt (7/6 to 7/20/2015) Support WG adoption! This is very useful work. The need for BGP next hop an= d tunnel EP separation has been talked for a while. The draft is quite new. We need think more on the mechanism and rules. For example, is it necessary to require specifying a sub-TLV for each encap= sulation type? Comments: Why does VXLAN encapsulation sub-TLV contain a MAC address, isn't the MAC c= arried by the NLRI? It should support tunnel stitching at a router, i.e. the tunnel endpoint; u= pon receiving a UPDATE, the router removes the tunnel encapsulation TLV and= /or sub-TLV on the UPDATE and inserts a new one prior to sending it out. In the case of recursive next hop, does it require tunnel ingress router ha= ve the reachable for all the remote end points? IMO: it shouldn't. Cheers, Lucy From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Monday, July 06, 2015 8:08 PM To: 'idr wg list' Cc: 'Keyur Patel (keyupate)' Subject: [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00.txt= (7/6 to 7/20/2015) This begins a 2 week adoption call on draft-rosen-idr-tunnel-encaps-00.txt = (7/6 to 7/20/2015). The draft can be found at: https://www.ietf.org/internet-drafts/draft-rosen-idr-tunnel-encaps-00.txt In your response, discuss why this draft proposal for encapsulation: a) [operators] will help deployed networks, b) Solves know problems with other tunnel encapsulation, and c) Provides a way to manage the matrix of tunnels. We will have a status report at IDR on 7/20 on this Working group adoption = call. Sue Hares and John Scudder --_000_BLUPR05MB562CE6F2B312FC9BDAB331EC79F0BLUPR05MB562namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Weiguo,

 

A number of the EVPN drafts use the R= FC 5512 extended community and they will continue to do so.  As I̵= 7;m sure you’re aware, there is not a lot of room in an extended community, and this draft is intended to be used for future applications, = e.g.,  EVPN, L3VPN, or Softwires, that need more room or more capabili= ties.

 

This is the same positioning that we = used with the previous remote next hop draft which this draft replaces.&nbs= p;

 

Yours Irrespectively,

 

John

 

From: Idr [mailto:idr-bounces@ietf.o= rg] On Behalf Of Haoweiguo
Sent: Thursday, July 09, 2015 10:00 PM
To: Lucy yong; Susan Hares; 'idr wg list'
Cc: 'Keyur Patel (keyupate)'
Subject: Re: [Idr] 2 week adoption call for draft-rosen-idr-tunnel-e= naps-00.txt (7/6 to 7/20/2015)

 

A= s for the MAC address advertisement mode, this draft seems to be conflicted= with EVPN draft-ietf-bess-evpn-inter-subnet-forwarding-00. In the EVPN dra= ft, if VXLAN/NVGRE tunnel is used, the remote NVE advertises its MAC through Router's MAC Extended Community, the MAC will be us= ed as inner destination MAC for inter-subnet traffic forwarding.

Thanks,

weiguo

From:<= /span> Idr [idr-bounces@ietf.org] on behalf of Lucy yong [lucy.yong@huawei.com]
Sent: Friday, July 10, 2015 6:16
To: Susan Hares; 'idr wg list'
Cc: 'Keyur Patel (keyupate)'
Subject: Re: [Idr] 2 week adoption call for draft-rosen-idr-tunnel-e= naps-00.txt (7/6 to 7/20/2015)

Support WG adoption! This is very use= ful work. The need for BGP next hop and tunnel EP separation has been talke= d for a while.

 =

The draft is quite new. We need think= more on the mechanism and rules.

 =

For example, is it necessary to requi= re specifying a sub-TLV for each encapsulation type?

 =

Comments:

Why does VXLAN encapsulation sub-TLV = contain a MAC address, isn’t the MAC carried by the NLRI?

It should support tunnel stitching at= a router, i.e. the tunnel endpoint; upon receiving a UPDATE, the router re= moves the tunnel encapsulation TLV and/or sub-TLV on the UPDATE and inserts a new one prior to sending it out.

In the case of recursive next hop, do= es it require tunnel ingress router have the reachable for all the remote e= nd points? IMO: it shouldn’t.=

 =

Cheers,

Lucy

 =

 =

 =

 =

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Monday, July 06, 2015 8:08 PM
To: 'idr wg list'
Cc: 'Keyur Patel (keyupate)'
Subject: [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps= -00.txt (7/6 to 7/20/2015)

 =

This begins a 2 week adoption call on d= raft-rosen-idr-tunnel-encaps-00.txt (7/6 to 7/20/2015).

The draft can be found at:

 =

https://ww= w.ietf.org/internet-drafts/draft-rosen-idr-tunnel-encaps-00.txt<= span style=3D"color:black">

 =

In your response, discuss why this draf= t proposal for encapsulation:=

a)<= /span>    &= nbsp; [operators] will help deployed networks,

b)<= /span>    &= nbsp; Solves know problems with other tunnel encapsulation, a= nd

c)<= /span>    &= nbsp;  Provides a way to manage the matrix of tunnels.<= span style=3D"color:black">

 =

 =

We will have a status report at IDR on = 7/20 on this Working group adoption call.

 =

Sue Hares and John Scudder

--_000_BLUPR05MB562CE6F2B312FC9BDAB331EC79F0BLUPR05MB562namprd_-- From nobody Fri Jul 10 12:20: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 553FF1B2A8A for ; Fri, 10 Jul 2015 12:20:44 -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 sCq-xc29aAB6 for ; Fri, 10 Jul 2015 12:20:43 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 201A51B2A89 for ; Fri, 10 Jul 2015 12:20:43 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 1798F1E434; Fri, 10 Jul 2015 15:22:28 -0400 (EDT) Date: Fri, 10 Jul 2015 15:22:28 -0400 From: Jeffrey Haas To: Susan Hares Message-ID: <20150710192227.GP13783@pfrc.org> References: <20150706203650.6815.83256.idtracker@ietfa.amsl.com> <20150706210159.GC13743@shrubbery.net> <027801d0b82f$60ad05b0$22071110$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <027801d0b82f$60ad05b0$22071110$@ndzh.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: 'heasley' , 'idr wg list' Subject: Re: [Idr] I-D Action: draft-ietf-idr-bgp-extended-messages-10.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: Fri, 10 Jul 2015 19:20:44 -0000 On Mon, Jul 06, 2015 at 05:04:41PM -0400, Susan Hares wrote: > Dave: > > It is waiting for 2 implementations. If you know of the 2 implementations, > I will start the process. Juniper has one in the queue for release scheduled this year. If there's a second implementation we could probably do the necessary interop work once we're into the appropriate bit of the QA cycle. -- Jeff From nobody Fri Jul 10 12:26: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 540A71B2A65 for ; Fri, 10 Jul 2015 12:26:54 -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 spSCE5v0PGNl for ; Fri, 10 Jul 2015 12:26:53 -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 667CA1AC3B3 for ; Fri, 10 Jul 2015 12:26:53 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1ZDdwh-0002FE-Ik; Fri, 10 Jul 2015 19:26:51 +0000 Date: Fri, 10 Jul 2015 12:26:49 -0700 Message-ID: From: Randy Bush To: Jeffrey Haas In-Reply-To: <20150710192227.GP13783@pfrc.org> References: <20150706203650.6815.83256.idtracker@ietfa.amsl.com> <20150706210159.GC13743@shrubbery.net> <027801d0b82f$60ad05b0$22071110$@ndzh.com> <20150710192227.GP13783@pfrc.org> 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 Subject: Re: [Idr] I-D Action: draft-ietf-idr-bgp-extended-messages-10.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: Fri, 10 Jul 2015 19:26:54 -0000 >> It is waiting for 2 implementations. If you know of the 2 implementations, >> I will start the process. > > Juniper has one in the queue for release scheduled this year. cool beans, as heas would say > If there's a second implementation we could probably do the necessary > interop work once we're into the appropriate bit of the QA cycle. if another iron vendor is , we can find a quagga or bird to bounce with you. we need it for bgpsec testing anyway. randy From nobody Fri Jul 10 12:35: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 A9D5B1B2A8A for ; Fri, 10 Jul 2015 12:35:15 -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 PtgNkjBVYSUD for ; Fri, 10 Jul 2015 12:35:15 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 921D21B2AA4 for ; Fri, 10 Jul 2015 12:35:12 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 7B2821E434; Fri, 10 Jul 2015 15:36:57 -0400 (EDT) Date: Fri, 10 Jul 2015 15:36:57 -0400 From: Jeffrey Haas To: "George, Wes" Message-ID: <20150710193657.GQ13783@pfrc.org> References: <20150706153149.29583.37991.idtracker@ietfa.amsl.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" Subject: Re: [Idr] I-D Action: draft-ietf-idr-as-migration-06.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: Fri, 10 Jul 2015 19:35:15 -0000 On Mon, Jul 06, 2015 at 12:29:13PM -0400, George, Wes wrote: > This version addresses Alvaro's LC review, as well as John Scudder's > comments made to me privately. I believe that this version is ready for > IESG evaluation. > My apologies for not getting it done until the height of the pre-meeting > crush. This version provides the appropriate semantic wiggle room to make me happy. Ship it. :-) -- Jeff From nobody Fri Jul 10 12:46: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 409C41B2AAA; Fri, 10 Jul 2015 12:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L0-NeW3LLll1; Fri, 10 Jul 2015 12:46:43 -0700 (PDT) Received: from out-1.mail.exa.net.uk (out-1.mail.exa.net.uk [82.219.4.129]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 082A51B2AA5; Fri, 10 Jul 2015 12:46:42 -0700 (PDT) Received: from smtp-2.mail.exa.net.uk (smtp-2.mail.exa.net.uk [82.219.5.2]) by out-1.mail.exa.net.uk (ExaSMTPD) with ESMTP id 281551C0075; Fri, 10 Jul 2015 20:46:40 +0100 (BST) Received: from smtp-2.mail.exa.net.uk (localhost [127.0.0.1]) by smtp-2.mail.exa.net.uk (ExaSMTPD) with ESMTP id 150AA4027B; Fri, 10 Jul 2015 20:46:40 +0100 (BST) Received: from [192.168.1.234] (ptr-34.212.219.82.rev.exa.net.uk [82.219.212.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: thomas@mangin.com) by smtp-2.mail.exa.net.uk (ExaSMTPD) with ESMTPSA; Fri, 10 Jul 2015 20:46:39 +0100 (BST) From: "Thomas Mangin" To: idr-bounces@ietf.org Date: Fri, 10 Jul 2015 20:46:39 +0100 Message-ID: In-Reply-To: <20150710192227.GP13783@pfrc.org> References: <20150706203650.6815.83256.idtracker@ietfa.amsl.com> <20150706210159.GC13743@shrubbery.net> <027801d0b82f$60ad05b0$22071110$@ndzh.com> <20150710192227.GP13783@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.1r5084) X-Virus-Scanned: clamav-milter 0.98.7 at out-2-2.mail.exa.net.uk X-Virus-Status: Clean Archived-At: Cc: heasley , idr wg list , Susan Hares Subject: Re: [Idr] I-D Action: draft-ietf-idr-bgp-extended-messages-10.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: Fri, 10 Jul 2015 19:46:45 -0000 I will happily add support in ExaBGP as soon as the capability number is assigned. Thomas http://exa.net.uk/about/contact-us On 10 Jul 2015, at 20:22, Jeffrey Haas wrote: > On Mon, Jul 06, 2015 at 05:04:41PM -0400, Susan Hares wrote: >> Dave: >> >> It is waiting for 2 implementations. If you know of the 2 >> implementations, >> I will start the process. > > Juniper has one in the queue for release scheduled this year. > > If there's a second implementation we could probably do the necessary > interop work once we're into the appropriate bit of the QA cycle. > > -- Jeff > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Fri Jul 10 12:57: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 365D21B2ABE for ; Fri, 10 Jul 2015 12:57:46 -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 AjkWxlULFCaF for ; Fri, 10 Jul 2015 12:57:45 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 8D0621B2AA5 for ; Fri, 10 Jul 2015 12:57:45 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 545771E434; Fri, 10 Jul 2015 15:59:30 -0400 (EDT) Date: Fri, 10 Jul 2015 15:59:30 -0400 From: Jeffrey Haas To: Susan Hares Message-ID: <20150710195930.GR13783@pfrc.org> References: <015c01d0af6e$b4fd58f0$1ef80ad0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <015c01d0af6e$b4fd58f0$1ef80ad0$@ndzh.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: 'idr wg' , dougm@nist.gov, ksriram@nist.gov Subject: Re: [Idr] 2 week adoption call for - draft-sriram-idr-route-leak-detection-mitigation-00 (6/25 to 7/9/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: Fri, 10 Jul 2015 19:57:46 -0000 On Thu, Jun 25, 2015 at 01:45:20PM -0400, Susan Hares wrote: > This begins a 2 week adoption call for > > draft-sriram-idr-route-leak-detection-mitigation-00 I support adoption of this draft. > This is an informational draft regarding route-leak mitigation. For this WG > adoption call please include in your response: > > > > a) Who will desire to read this informational draft now and in 1 year > from now>? I find it likely that the document will have an extended lifetime in IDR and SIDR as the mechanism is refined and implemented. > b) Is this informational draft's description of route-leak types and > mitigated by the origin validation [RFC 6811] and BGPSEC path validation > > [draft-ietf-sidr-bgpsec-protocol] are correct? Better than most. > c) It is necessary to solve the route-leak problems not covered by > origin validation and BGPSEC path validation? Yes. > d) Do you think the solution suggested for the extension of BGPSEC will > fix these unsolved route-leak problems? I believe so, but require more time to re-read the bgpsec protocol and think about it. -- Jeff From nobody Fri Jul 10 13:07: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 53F7D1B2ACD for ; Fri, 10 Jul 2015 13:07:33 -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 Nd06eo6iWWlK for ; Fri, 10 Jul 2015 13:07:32 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 9E2461B2AC5 for ; Fri, 10 Jul 2015 13:07:32 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 9702B1E434; Fri, 10 Jul 2015 16:09:17 -0400 (EDT) Date: Fri, 10 Jul 2015 16:09:17 -0400 From: Jeffrey Haas To: Thomas Mangin Message-ID: <20150710200917.GS13783@pfrc.org> References: <20150702142348.4291.10005.idtracker@ietfa.amsl.com> <7C5305E5-69BF-4796-900A-726FFE4B2EEE@juniper.net> 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" Subject: Re: [Idr] New Version Notification for draft-scudder-idr-capabilities-registry-change-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 20:07:33 -0000 Thomas, On Fri, Jul 03, 2015 at 10:28:23AM +0100, Thomas Mangin wrote: > If I understand your draft correctly ( it is a big assumption ) the > new proposal would seem to make it much harder to experiment: Only > allowing 4 code for experimental use means that no more than 4 new > features can be tested simultaneously by a single vendor ( and less > if two or more vendors want to collaborate on a feature together ). > This seems to me to be quite on the very low side, I would feel > better if this number was to be raised. While I also think that the number is a little low, there remain 64 code points that are first-come, first-served. Any experiment that proceeds to the point of desired interop is probably ready for a real code point. > I am also unsure if code 128 ( CISCO Route-Refresh ) and 131 ( CISCO > multi-session ) are still found in production networks ( AFAIK it > was the case a few years ago ), and if so, if this situation require > formalising. I would suggest that it would. Since old BGP implementations tend to linger for a *very* long time, these code points are effectively poisoned. > ExaBGP also use the following code in the 128+ range: 184, cumulus > hostname draft; 185, operational draft. Would you expect me to > relocate these code into the new 251-254 range ? Or the FCFS if you think the proposals are mature enough. Alternatively, see RFC 7120. -- Jeff From nobody Fri Jul 10 13:09: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 80F1C1B2AF3; Fri, 10 Jul 2015 13:09:54 -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 Th7J_HuN0l8T; Fri, 10 Jul 2015 13:09:54 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id E50051B2ADF; Fri, 10 Jul 2015 13:09:53 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id F28E41E434; Fri, 10 Jul 2015 16:11:38 -0400 (EDT) Date: Fri, 10 Jul 2015 16:11:38 -0400 From: Jeffrey Haas To: Thomas Mangin Message-ID: <20150710201138.GT13783@pfrc.org> References: <20150706203650.6815.83256.idtracker@ietfa.amsl.com> <20150706210159.GC13743@shrubbery.net> <027801d0b82f$60ad05b0$22071110$@ndzh.com> <20150710192227.GP13783@pfrc.org> 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: heasley , idr wg list , idr-bounces@ietf.org, Susan Hares Subject: Re: [Idr] I-D Action: draft-ietf-idr-bgp-extended-messages-10.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: Fri, 10 Jul 2015 20:09:54 -0000 On Fri, Jul 10, 2015 at 08:46:39PM +0100, Thomas Mangin wrote: > I will happily add support in ExaBGP as soon as the capability > number is assigned. And here's where I must retract my comment as having read too many documents in too short an order. Juniper will have an implementation of draft-ietf-idr-ext-opt-param, not the extended message type. (Although we have some old prototype code for the extended message type kicking around...) -- Jeff From nobody Fri Jul 10 13:12: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 908A71B2B00 for ; Fri, 10 Jul 2015 13:12:55 -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 ksrJdYmm9rY2 for ; Fri, 10 Jul 2015 13:12:54 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0103.outbound.protection.outlook.com [207.46.100.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11B921B2AFA for ; Fri, 10 Jul 2015 13:12:53 -0700 (PDT) Authentication-Results: cisco.com; dkim=none (message not signed) header.d=none; Received: from [172.29.36.144] (66.129.241.11) by BY1PR0501MB1093.namprd05.prod.outlook.com (10.160.103.139) with Microsoft SMTP Server (TLS) id 15.1.213.14; Fri, 10 Jul 2015 20:12:50 +0000 Message-ID: <55A0273D.4020608@juniper.net> Date: Fri, 10 Jul 2015 16:12:45 -0400 From: Eric C Rosen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Lucy yong , Susan Hares , "'idr wg list'" , Haoweiguo , "Henderickx, Wim (Wim)" References: <02ce01d0b851$4ecec5a0$ec6c50e0$@ndzh.com> <2691CE0099834E4A9C5044EEC662BB9D571ADA7E@dfweml701-chm> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D571ADA7E@dfweml701-chm> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [66.129.241.11] X-ClientProxiedBy: SN1PR06CA0018.namprd06.prod.outlook.com (25.163.69.28) To BY1PR0501MB1093.namprd05.prod.outlook.com (25.160.103.139) X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1093; 2:aCUPG1Ui6MivFuhSgGms2xhFPJ2bEk9suip3iTDG8L2VOHeQ57nPQaFhFiBOjeK0; 3:9VIJjIucMZbcAT48yw++4JAOJYoEOqxBj85gTwNX28RnlUy4RyBItYizyKDJ/enfNW7D88r9Gq4msy9eqKYQFdMxEunDNX3tKFEiqTJV73jY/oWozZsDAKoikCFDbnQJE34oDl7Vjq7p5Nnr8DpNKg==; 25:R68eOTMbgT+Mw/azrwK4NJwUjCD9+l1dTn8zKdp0C6y/h881MSZLL/EREt3tfKbuFlFcH7mbnFslX9TWU2dSmgGDAC+pcwnPyw8aJR3ZBw2YuVg099LZwVNpza5tYcOjjvJRGfT8Ct9gPt7N99Weu7wX69cxGsjrTfa6WgzUP4D/wY9NQnYkskZ02ZmK91bx8L7RAH5uL8B6qP7JM1HoCnJ2rd39I2sdSFVMaA5EWpmSb3/obIfbU1MYFUtR4UH4PjfdCR+Y6rtHpxZqA/nTHw== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1093; X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1093; 20:1UPjKygkv+oiMyj98+WW/0vn/3BDwY9OeTfm7qZ7I3qds+ciTSpx8NuW/zjCjmZD2ehqYkaXVwdYC/KwMqCpKqsP2OfgC2+Vm6EHdj7/TALiylpPy04CeGasHgIKJSB1N4fbv6ZFlQJUE2YrEJuQoo5/VlU7DGwLkAUls+BtHZplpfItzmHAxtkoDdYn+rPBNvt1Ew8LwAXHnFEs1mkSqZbLc8qXq7I02He4XYzczCeUsxniYo+OGBujiNqpacsgO6PUYWnZt8mPutn8x4Mr6Ktu7/ppVlKlcEkwysX7tOU/j59WLTWpuqfWuHX19Dyvt885SGmm5tbiKQCKd/VXW+DYvERJaYORpuuE6zc/4oyos6iV3Ko05tX5TEXUWvW1wBe4pHm8XFR3og7vkENzA0ZCrNwqN2fEle3acURik9OLBIMzXqAEF6hiYTbV3KmVsszPtWT8AuS3yWzytgIpS3CODHNEoMKF6rGutkExPIf2+zIGpkdRk2xRN6ZKM0jO; 4:2F3kKZjycMhI1rPdDYkSIzfL2wL1o7KBD8nhHrGukkPJW3+AMzG/PEn4XakLXVMfC3PmJLcH/C9DIwGTSo35YrjLKoUWK+rdmIpD+5rUbc76rdtlQP+6UWL93vt78wCnRi+9BEHaco999b3Yp2DhKTb77UFRAKo6oJi/dd3drhrOAbw0rEjLIFgfCWqESg8JjVyUfVK/sWANjuxkv90QNmPsSNNylI6AHQxTK8YR4mO4b8tUb9M0USYev2inYPBhcVEJRwDFHzsZjOR06xNtQ6CnGI1lNlY8P9Q5gqUdpkA= BY1PR0501MB1093: X-MS-Exchange-Organization-RulesExecuted 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:BY1PR0501MB1093; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1093; X-Forefront-PRVS: 06339BAE63 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(6049001)(5423002)(122386002)(33656002)(50466002)(87976001)(80316001)(230783001)(4001350100001)(66066001)(5001960100002)(5001770100001)(76176999)(86362001)(23746002)(42186005)(189998001)(77156002)(65806001)(87266999)(62966003)(5890100001)(47776003)(59896002)(2950100001)(92566002)(40100003)(77096005)(64126003)(54356999)(36756003)(46102003)(65816999)(83506001)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1093; H:[172.29.36.144]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; BY1PR0501MB1093; 23:1RbG2SX9rrrNDHzNLi8a1zAVG5PjvFB1GvZ?= =?Windows-1252?Q?JAHuWnzzv2RgSBsnDW9Nd07mAmittOVuVHgHv2CizWnaZOiAm+othfg1?= =?Windows-1252?Q?BLpm/CeMbW1Zjoe3abqVhoC+O/fDOnBcxU0TC2Vkcm+EqHIqtcSlCbgF?= =?Windows-1252?Q?JAPHATjv7RrMYAqu1/2fweQySQdITo07a2Ro8lWUIOxldEjgz9OmUAdp?= =?Windows-1252?Q?rafcr/WN/84LxckftGXMN6D1J1Bw5kZcEdCEzjgf5nrEkcbUd6FYgNYh?= =?Windows-1252?Q?+mbbbO1gBTjBEf89m5etGV9burA/9A3czdLtQIUQdigUvpHRHXPl23qv?= =?Windows-1252?Q?s5rHZOEiaTR37U4AEVNloBwJ+7gzrq/1LRbgghniKsX910MZoRHpjTUN?= =?Windows-1252?Q?bfwwJclPSmsT753PD0hYi7ADsl17DEMPNAhjDpBtRTCoD+NCU4CygljT?= =?Windows-1252?Q?ePiMoeyJZC19ZNpgb35PFXs/n4TDRbHhA48m3NfgogPoZ6kjEuJlIKfD?= =?Windows-1252?Q?TOI4WYeltCVPT8GER8b2+KSRbEfrFCVf6QsJDruIg5VgZHySjH9B3Dcy?= =?Windows-1252?Q?ilUyNId8CVHv8wFXCuEBFmD2/MUWDsv+mRkN9rD7ozjXyIhFxYFU36kV?= =?Windows-1252?Q?HsG/9S6GYF7Iy6q2xNCkto/evcC3gLEwRKkAEnSGpyKGyuBXyWCGkzxD?= =?Windows-1252?Q?BXBuyOs5ij73O12Emav43rvDVActd5993/P/Zy+QX36wwlzt4nwd5G8T?= =?Windows-1252?Q?/gxjKqprJbJA0lwhXDs3z/5x3/9BMlgUa9mXoTp75zDCUImHUyyiU7Jn?= =?Windows-1252?Q?iWvTboqllWAKI08bdl8eaZAfjrSUSJhkkqVGx4uEkYIDIDLz+RukdDCs?= =?Windows-1252?Q?oAv4VprEErniEJi89VY0Bb27ZQz4JW/9lxwm1Hn1iXzDsBsxNjRH2Cq1?= =?Windows-1252?Q?GZJyHc1Dq14vUzPXBPGky3Z8JiN7VZKdwdi8mnCwENZ5pdhxFiBE2+yK?= =?Windows-1252?Q?Bn/8MbjKZP+teBu3aVuEYMSbWpALf8L3nmHhDfYsFnajFvX1h4Q=3D?= =?Windows-1252?Q?=3D?= X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1093; 5:LJUIfRFiS9I9d46ZOJebuaW/90I9w0AZf4Zfy4WMWC5WPxTyrxx4YMV5BtkrDQd2TwRFqFbp/t5dNTwezL0sqF0/JmkoQhtx8MZqtYOm9nVJp3KsCJNDDud4cqb3HKaYmDOssqcUdN6OgjGe8nbpSA==; 24:ODLnvsf+9nIjJbuRhXdPKCs0ui4DI0WNd+ZeZVFlnYo3H6D4OoCLCGQ9HVjRnTepofcAyAAlJKPc4KbD0rrbKtfIxmwvhMuwpij/Tugq3A0=; 20:6sJ4qnuwU3S7jpJCtGq3Lo/Y71VsLi2HNW1mdUI+H+FhGv66bAKjSUkyhVp4vdknm1f6/01Srhp8F3zrsxiLog== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Jul 2015 20:12:50.8190 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1093 Archived-At: Cc: "'Keyur Patel \(keyupate\)'" Subject: Re: [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00.txt (7/6 to 7/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: Fri, 10 Jul 2015 20:12:55 -0000 > [Lucy] is it necessary to require specifying a sub-TLV for each > encapsulation type? No, it's not necessary for every tunnel type to have an encapsulation sub-TLV. > [Lucy] Why does VXLAN encapsulation sub-TLV contain a MAC address, isn’t the > MAC carried by the NLRI? Consider the case where the application is L3VPN, but one wants to use VXLAN tunnels instead of MPLS tunnels. You could signal this by attaching a Tunnel Encapsulation attribute to a VPN-IP route, where the attribute contains a TLV specifying a VXLAN tunnel. But the NLRI of the VPN-IP route does not contain a MAC address. > [Wim] In most EVPN you don’t want any MAC encoding in this new attribute There is a provision for omitting the MAC address in the VXLAN Encapsulation sub-TLV. However, the text saying what to do if this MAC address is omitted seems to need correction. > [Weiguo] As for the MAC address advertisement mode, this draft seems > to be conflicted with EVPN > draft-ietf-bess-evpn-inter-subnet-forwarding-00. In the EVPN draft, > if VXLAN/NVGRE tunnel is used, the remote NVE advertises its MAC > through Router's MAC Extended Community, the MAC will be used as > inner destination MAC for inter-subnet traffic forwarding. If I understand correctly, that draft uses the "Tunnel Type extended community" to signal that a VXLAN tunnel is needed, and then uses the "Router's MAC extended community" to signal the inner MAC DA. If one attaches the Tunnel Encapsulation attribute to a particular UPDATE, one doesn't really need to also attach either of those two extended communities. However, the tunnel encapsulation draft should say something about the case where both the Tunnel Encapsulation attribute (specifying a VXLAN tunnel) and the Router's MAC extended community are present. Whether a particular application uses one way of signaling or the other is outside the scope of the tunnel encapsulation draft. > [Lucy] It should support tunnel stitching at a router, i.e. the tunnel > endpoint; upon receiving a UPDATE, the router removes the tunnel > encapsulation TLV and/or sub-TLV on the UPDATE and inserts a new one > prior to sending it out. If some router is the receiving endpoint of one tunnel and the transmitting endpoint of another, I don't think anything in the draft prevents it from doing this sort of stitching. Do you think additional mechanisms are needed? > [Lucy] In the case of recursive next hop, does it require tunnel ingress router > have the reachable for all the remote end points? IMO: it shouldn’t. Do you have a particular scenario in mind? I think the only requirement imposed by the draft is that you shouldn't try to use a particular tunnel if its remote endpoint is not reachable. From nobody Fri Jul 10 14:00: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 5BD731B2B05 for ; Fri, 10 Jul 2015 14:00:24 -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 WZkOAr1oDJ01 for ; Fri, 10 Jul 2015 14:00:23 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id CB6971B2D11 for ; Fri, 10 Jul 2015 13:59:26 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id C6CF01E434; Fri, 10 Jul 2015 17:01:11 -0400 (EDT) Date: Fri, 10 Jul 2015 17:01:11 -0400 From: Jeffrey Haas To: idr@ietf.org Message-ID: <20150710210111.GU13783@pfrc.org> References: <20150706141017.31158.42788.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150706141017.31158.42788.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: [Idr] Comments on draft-ietf-idr-aspath-orf-10.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: Fri, 10 Jul 2015 21:00:24 -0000 I must admit to being somewhat dismayed by seeing this draft resurrected. It's been a while since this draft has been discussed, so I'll fully list my concerns: The ORF mechanism is very heavy weight. Once the ORF has been updated, a full route-refresh is required in order to apply its changes. Contrast this to the lighter weight incremental updates done by RT-Constrain. ORFs are AFI/SAFI specific. AS_PATH filters are often address family agnostic. This means we not only burn a large part of our capabilities potentially for the union of all AFI/SAFI to be exchanged. (ext-opt-param addresses this point). But it does mean that we need to exchange potentially the full set of AS_PATH ORFs redundantly, stretching out any reconfiguration. ORFs were originally designed to limit incoming resource impact by pushing one router's import filters into another router's export path. Many routers attempt to optimize outbound route queueing through peer-groups and ORFs inherently make this messier. The same issue does hold for RT-Constrain as well, but I'll argue regex is more costly. :-) Editorial comments: Rather than hexadecimal string, I'd suggest either byte string or OCTET string. (The latter will be familiar to the SNMP folk.) The length field seems to imply that it's a bit-length field. I'm not sure this makes sense; it probably should be bytes and thus "trailing bits" would be irrelevant. For the anchoring description, it's unclear to me what anchoring vs. non-anchoring mean based on the examples. Is the intent to say that the tokens '^' and '$' are available to anchor the regex? For the collating element, is the intent to say that the space character is matched by the '.' token when Bit 1 is 0? Or is the intent of the two options to indicate whether or not the '.' token represents a integer character vs. an integer string? The section on regular expresses is extremely incomplete and is need of significant expansion: - How are route AS_PATHs canonicalized? I.e. single spaces between AS numbers? - Are AS segment types represented in the canonicalized form? - When AS segment types are canonicalized, is there any intersection with standard regex operators vs. the AS_PATH canonicalized string? E.g. '[]' is used for AS_SET representation in some implementations. - How are 4-byte ASes canonicalized? asplain? (See RFC 5396) - For Bit2 - [] - is the implication that we're doing integer character range matching or integer string range matching? Do we support the NOT range, i.e. [^0]? - Is regex alternation, i.e. '|', permitted? - Is grouping, i.e. '()', permitted? Does it conflict with canonicalized output? What about backreferences? - What about ranges, e.g. "1 2{2,4} 3"? What the encoding is for the string? US-ASCII? If not and a multi-byte character set is used, how does this mechanism behave when there's an encoding failure? What happens if a character outside the accepted set is included? Nit: It looks like an I2NSF draft's XML was used for this document. I'm sure it'll be better next time. :-) While I'm sure we could eventually address all of the technical issues in the draft, I'd much rather see it be retired and removed from the charter. It's a very clunky hammer. If there's a use case for it, let's discuss that and see if something else fits better. -- Jeff On Mon, Jul 06, 2015 at 07:10:17AM -0700, 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 : Analysis of Existing work for I2NSF > Authors : Susan Hares > Keyur Patel > Filename : draft-ietf-idr-aspath-orf-10.txt > Pages : 7 > Date : 2015-07-05 > > Abstract: > This document defines a new Outbound Router Filter type for BGP, > termed "Aspath Outbound Route Filter", that can be used to perform > aspath based route filtering. This ORF-type supports aspath based > route filtering as well as regular expression based matching, for > address groups. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-idr-aspath-orf/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-idr-aspath-orf-10 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-aspath-orf-10 > > > 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 Fri Jul 10 14:22: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 AD4491B2B2D for ; Fri, 10 Jul 2015 14:22:13 -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 qRPnxsKEcElm for ; Fri, 10 Jul 2015 14:22:12 -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 1EF1D1B2B2C for ; Fri, 10 Jul 2015 14:22:12 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1ZDfkI-0002pR-V4; Fri, 10 Jul 2015 21:22:11 +0000 Date: Fri, 10 Jul 2015 14:22:10 -0700 Message-ID: From: Randy Bush To: Jeffrey Haas In-Reply-To: <20150710210111.GU13783@pfrc.org> References: <20150706141017.31158.42788.idtracker@ietfa.amsl.com> <20150710210111.GU13783@pfrc.org> 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 Subject: Re: [Idr] Comments on draft-ietf-idr-aspath-orf-10.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: Fri, 10 Jul 2015 21:22:13 -0000 > I must admit to being somewhat dismayed by seeing this draft resurrected. what gets me is the threat model. you can trust me to tell you what you can trust from me. randy From nobody Sat Jul 11 00:43: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 8F8DE1A873E for ; Sat, 11 Jul 2015 00:43:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 WPTtbXjKtPSM for ; Sat, 11 Jul 2015 00:43:03 -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 E2F261A873D for ; Sat, 11 Jul 2015 00:43:02 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 78D3F7D03BF44; Sat, 11 Jul 2015 07:42:58 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t6B7gxKd000452 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 11 Jul 2015 09:42:59 +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; Sat, 11 Jul 2015 09:42:59 +0200 From: "Henderickx, Wim (Wim)" To: Eric C Rosen , Lucy yong , "Susan Hares" , "'idr wg list'" , Haoweiguo Thread-Topic: [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00.txt (7/6 to 7/20/2015) Thread-Index: AdC4UJG6Pj+U9ACORa+TFqfDTB54DgC/EbEDABgOrgA= Date: Sat, 11 Jul 2015 07:42:58 +0000 Message-ID: References: <02ce01d0b851$4ecec5a0$ec6c50e0$@ndzh.com> <2691CE0099834E4A9C5044EEC662BB9D571ADA7E@dfweml701-chm> <55A0273D.4020608@juniper.net> In-Reply-To: <55A0273D.4020608@juniper.net> Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.150618 x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="utf-8" Content-ID: <2B90D7D74709EE40AC0685D0569C929C@exchange.lucent.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "'Keyur Patel \(keyupate\)'" Subject: Re: [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00.txt (7/6 to 7/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: Sat, 11 Jul 2015 07:43:04 -0000 PHNuaXA+DQo+ICBbV2ltXSBJbiBtb3N0IEVWUE4geW91IGRvbuKAmXQgd2FudCBhbnkgTUFDIGVu Y29kaW5nIGluIHRoaXMgbmV3IGF0dHJpYnV0ZQ0KDQpUaGVyZSBpcyBhIHByb3Zpc2lvbiBmb3Ig b21pdHRpbmcgdGhlIE1BQyBhZGRyZXNzIGluIHRoZSBWWExBTiANCkVuY2Fwc3VsYXRpb24gc3Vi LVRMVi4gICBIb3dldmVyLCB0aGUgdGV4dCBzYXlpbmcgd2hhdCB0byBkbyBpZiB0aGlzIE1BQyAN CmFkZHJlc3MgaXMgb21pdHRlZCBzZWVtcyB0byBuZWVkIGNvcnJlY3Rpb24uDQoNCg0KV0g+IHRo aXMgaXMgdGhlIHBhcnQgdGhhdCBJIGFtIHRhbGtpbmcgYWJvdXQgaW5kZWVkIGFuZCB3ZSBuZWVk IHRvIGNsYXJpZnkgYSBiaXQgdGhlIHNjZW5hcmlv4oCZcyBoZXJlIHN1Y2ggdGhhdCB3ZSBhcmUg Y2xlYXIgd2hhdCB0byBkby4gVGh4DQoNCjxzbmlwPg0KDQoNCg0KDQpPbiAxMC8wNy8xNSAyMjox MiwgIkVyaWMgQyBSb3NlbiIgPGVyb3NlbkBqdW5pcGVyLm5ldD4gd3JvdGU6DQoNCj4+IFtMdWN5 XSBpcyBpdCBuZWNlc3NhcnkgdG8gcmVxdWlyZSBzcGVjaWZ5aW5nIGEgc3ViLVRMViBmb3IgZWFj aA0KPj4gZW5jYXBzdWxhdGlvbiB0eXBlPw0KPg0KPk5vLCBpdCdzIG5vdCBuZWNlc3NhcnkgZm9y IGV2ZXJ5IHR1bm5lbCB0eXBlIHRvIGhhdmUgYW4gZW5jYXBzdWxhdGlvbiANCj5zdWItVExWLg0K Pg0KPj4gW0x1Y3ldIFdoeSBkb2VzIFZYTEFOIGVuY2Fwc3VsYXRpb24gc3ViLVRMViBjb250YWlu IGEgTUFDIGFkZHJlc3MsIGlzbuKAmXQgdGhlDQo+PiBNQUMgY2FycmllZCBieSB0aGUgTkxSST8N Cj4NCj5Db25zaWRlciB0aGUgY2FzZSB3aGVyZSB0aGUgYXBwbGljYXRpb24gaXMgTDNWUE4sIGJ1 dCBvbmUgd2FudHMgdG8gdXNlIA0KPlZYTEFOIHR1bm5lbHMgaW5zdGVhZCBvZiBNUExTIHR1bm5l bHMuICBZb3UgY291bGQgc2lnbmFsIHRoaXMgYnkgDQo+YXR0YWNoaW5nIGEgVHVubmVsIEVuY2Fw c3VsYXRpb24gYXR0cmlidXRlIHRvIGEgVlBOLUlQIHJvdXRlLCB3aGVyZSB0aGUgDQo+YXR0cmli dXRlIGNvbnRhaW5zIGEgVExWIHNwZWNpZnlpbmcgYSBWWExBTiB0dW5uZWwuICBCdXQgdGhlIE5M Ukkgb2YgdGhlIA0KPlZQTi1JUCByb3V0ZSBkb2VzIG5vdCBjb250YWluIGEgTUFDIGFkZHJlc3Mu DQo+DQo+PiAgW1dpbV0gSW4gbW9zdCBFVlBOIHlvdSBkb27igJl0IHdhbnQgYW55IE1BQyBlbmNv ZGluZyBpbiB0aGlzIG5ldyBhdHRyaWJ1dGUNCj4NCj5UaGVyZSBpcyBhIHByb3Zpc2lvbiBmb3Ig b21pdHRpbmcgdGhlIE1BQyBhZGRyZXNzIGluIHRoZSBWWExBTiANCj5FbmNhcHN1bGF0aW9uIHN1 Yi1UTFYuICAgSG93ZXZlciwgdGhlIHRleHQgc2F5aW5nIHdoYXQgdG8gZG8gaWYgdGhpcyBNQUMg DQo+YWRkcmVzcyBpcyBvbWl0dGVkIHNlZW1zIHRvIG5lZWQgY29ycmVjdGlvbi4NCj4NCj4+IFtX ZWlndW9dIEFzIGZvciB0aGUgTUFDIGFkZHJlc3MgYWR2ZXJ0aXNlbWVudCBtb2RlLCB0aGlzIGRy YWZ0IHNlZW1zDQo+PiB0byBiZSBjb25mbGljdGVkIHdpdGggRVZQTg0KPj4gZHJhZnQtaWV0Zi1i ZXNzLWV2cG4taW50ZXItc3VibmV0LWZvcndhcmRpbmctMDAuIEluIHRoZSBFVlBOIGRyYWZ0LA0K Pj4gaWYgVlhMQU4vTlZHUkUgdHVubmVsIGlzIHVzZWQsIHRoZSByZW1vdGUgTlZFIGFkdmVydGlz ZXMgaXRzIE1BQw0KPj4gdGhyb3VnaCBSb3V0ZXIncyBNQUMgRXh0ZW5kZWQgQ29tbXVuaXR5LCB0 aGUgTUFDIHdpbGwgYmUgdXNlZCBhcw0KPj4gaW5uZXIgZGVzdGluYXRpb24gTUFDIGZvciBpbnRl ci1zdWJuZXQgdHJhZmZpYyBmb3J3YXJkaW5nLg0KPg0KPklmIEkgdW5kZXJzdGFuZCBjb3JyZWN0 bHksIHRoYXQgZHJhZnQgdXNlcyB0aGUgIlR1bm5lbCBUeXBlIGV4dGVuZGVkIA0KPmNvbW11bml0 eSIgdG8gc2lnbmFsIHRoYXQgYSBWWExBTiB0dW5uZWwgaXMgbmVlZGVkLCBhbmQgdGhlbiB1c2Vz IHRoZSANCj4iUm91dGVyJ3MgTUFDIGV4dGVuZGVkIGNvbW11bml0eSIgdG8gc2lnbmFsIHRoZSBp bm5lciBNQUMgREEuICBJZiBvbmUgDQo+YXR0YWNoZXMgdGhlIFR1bm5lbCBFbmNhcHN1bGF0aW9u IGF0dHJpYnV0ZSB0byBhIHBhcnRpY3VsYXIgVVBEQVRFLCBvbmUgDQo+ZG9lc24ndCByZWFsbHkg bmVlZCB0byBhbHNvIGF0dGFjaCBlaXRoZXIgb2YgdGhvc2UgdHdvIGV4dGVuZGVkIA0KPmNvbW11 bml0aWVzLiAgSG93ZXZlciwgdGhlIHR1bm5lbCBlbmNhcHN1bGF0aW9uIGRyYWZ0IHNob3VsZCBz YXkgDQo+c29tZXRoaW5nIGFib3V0IHRoZSBjYXNlIHdoZXJlIGJvdGggdGhlIFR1bm5lbCBFbmNh cHN1bGF0aW9uIGF0dHJpYnV0ZSANCj4oc3BlY2lmeWluZyBhIFZYTEFOIHR1bm5lbCkgYW5kIHRo ZSBSb3V0ZXIncyBNQUMgZXh0ZW5kZWQgY29tbXVuaXR5IGFyZSANCj5wcmVzZW50Lg0KPg0KPldo ZXRoZXIgYSBwYXJ0aWN1bGFyIGFwcGxpY2F0aW9uIHVzZXMgb25lIHdheSBvZiBzaWduYWxpbmcg b3IgdGhlIG90aGVyIA0KPmlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoZSB0dW5uZWwgZW5jYXBz dWxhdGlvbiBkcmFmdC4NCj4NCj4+IFtMdWN5XSBJdCBzaG91bGQgc3VwcG9ydCB0dW5uZWwgc3Rp dGNoaW5nIGF0IGEgcm91dGVyLCBpLmUuIHRoZSB0dW5uZWwNCj4+IGVuZHBvaW50OyB1cG9uIHJl Y2VpdmluZyBhIFVQREFURSwgdGhlIHJvdXRlciByZW1vdmVzIHRoZSB0dW5uZWwNCj4+IGVuY2Fw c3VsYXRpb24gVExWIGFuZC9vciBzdWItVExWIG9uIHRoZSBVUERBVEUgYW5kIGluc2VydHMgYSBu ZXcgb25lDQo+PiBwcmlvciB0byBzZW5kaW5nIGl0IG91dC4NCj4NCj5JZiBzb21lIHJvdXRlciBp cyB0aGUgcmVjZWl2aW5nIGVuZHBvaW50IG9mIG9uZSB0dW5uZWwgYW5kIHRoZSANCj50cmFuc21p dHRpbmcgZW5kcG9pbnQgb2YgYW5vdGhlciwgSSBkb24ndCB0aGluayBhbnl0aGluZyBpbiB0aGUg ZHJhZnQgDQo+cHJldmVudHMgaXQgZnJvbSBkb2luZyB0aGlzIHNvcnQgb2Ygc3RpdGNoaW5nLiAg RG8geW91IHRoaW5rIGFkZGl0aW9uYWwgDQo+bWVjaGFuaXNtcyBhcmUgbmVlZGVkPw0KPg0KPj4g W0x1Y3ldIEluIHRoZSBjYXNlIG9mIHJlY3Vyc2l2ZSBuZXh0IGhvcCwgZG9lcyBpdCByZXF1aXJl IHR1bm5lbCBpbmdyZXNzIHJvdXRlcg0KPj4gaGF2ZSB0aGUgcmVhY2hhYmxlIGZvciBhbGwgdGhl IHJlbW90ZSBlbmQgcG9pbnRzPyBJTU86IGl0IHNob3VsZG7igJl0Lg0KPg0KPkRvIHlvdSBoYXZl IGEgcGFydGljdWxhciBzY2VuYXJpbyBpbiBtaW5kPyAgSSB0aGluayB0aGUgb25seSByZXF1aXJl bWVudCANCj5pbXBvc2VkIGJ5IHRoZSBkcmFmdCBpcyB0aGF0IHlvdSBzaG91bGRuJ3QgdHJ5IHRv IHVzZSBhIHBhcnRpY3VsYXIgDQo+dHVubmVsIGlmIGl0cyByZW1vdGUgZW5kcG9pbnQgaXMgbm90 IHJlYWNoYWJsZS4NCj4NCj4NCg== From nobody Sun Jul 12 13:12: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 55A721A8928 for ; Sun, 12 Jul 2015 13:12:39 -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 lR_S1-7Xhomo for ; Sun, 12 Jul 2015 13:12:38 -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 669E91A8925 for ; Sun, 12 Jul 2015 13:12:38 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1ZENc2-0004iT-Cp; Sun, 12 Jul 2015 20:12:34 +0000 Date: Sun, 12 Jul 2015 13:12:33 -0700 Message-ID: From: Randy Bush To: Ondrej Zajicek In-Reply-To: <20150712200048.GA21130@varda.crfreenet.org> References: <20150706203650.6815.83256.idtracker@ietfa.amsl.com> <20150706210159.GC13743@shrubbery.net> <027801d0b82f$60ad05b0$22071110$@ndzh.com> <20150710192227.GP13783@pfrc.org> <20150712200048.GA21130@varda.crfreenet.org> 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 Subject: Re: [Idr] I-D Action: draft-ietf-idr-bgp-extended-messages-10.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 Jul 2015 20:12:39 -0000 > I just implemented the draft-ietf-idr-bgp-extended-messages to BIRD. > Currently it is a private patch, when the capability number will be > assigned, it could be a part of the next official release. oh idr chairs, this is the second request for the capability. iff we want this to progress, we either need to talk to the iana or agree on some disgusting temp hack. your call, it's process. randy From nobody Sun Jul 12 15:15: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 5E8751A8870 for ; Sun, 12 Jul 2015 15:15: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 aksi0PpApYiL for ; Sun, 12 Jul 2015 15:15:45 -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 DE9FD1A8884 for ; Sun, 12 Jul 2015 15:15:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1208; q=dns/txt; s=iport; t=1436739345; x=1437948945; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Pl/PCeL3K9de2jNJDefU6eO0KVeRxwZXxE29HyQRaio=; b=E4YBw5X2QaP2p7chOFv2Iw5cRdv07gFs6epJjNFa6GFhYmllpbqKBlHN rUXVeUPXP9WhOQRXrMbPYPb8I+/04kPfdlUSSvXrOW9zKpPkSSKngoa01 Mss93FQXegCZDXDI3Yt1sOMLkOZOV9qu820LseaYofX7dE5XJ8dC/q61D 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BqAwCu5qJV/5xdJa1bgxRUaQaDHLgVCYFpCoV3AhyBCDgUAQEBAQEBAYEKhCQBAQMBAQEBIBE6CxACAQgaAiYCAgIlCxUQAgQBDQWIJggNsVmVYwEBAQEBAQEBAQEBAQEBAQEBAQEBARMEgSKKKoUGB4JogUMBBJQxAYwDgT+TTYNfJoN7bwGBRoEEAQEB X-IronPort-AV: E=Sophos;i="5.15,458,1432598400"; d="scan'208";a="14770926" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 12 Jul 2015 22:15:42 +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 t6CMFgcq024510 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 12 Jul 2015 22:15:42 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.208]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Sun, 12 Jul 2015 17:14:54 -0500 From: "Acee Lindem (acee)" To: Randy Bush , Ondrej Zajicek Thread-Topic: [Idr] I-D Action: draft-ietf-idr-bgp-extended-messages-10.txt Thread-Index: AQHQuCuFeXhtQ0gVtkOfuKEnBEqrtp3PPEKAgAAFN4CAAADBgIAGLMUAgAABN4CAAt20WIAAMtqA Date: Sun, 12 Jul 2015 22:14:51 +0000 Message-ID: References: <20150706203650.6815.83256.idtracker@ietfa.amsl.com> <20150706210159.GC13743@shrubbery.net> <027801d0b82f$60ad05b0$22071110$@ndzh.com> <20150710192227.GP13783@pfrc.org> <20150712200048.GA21130@varda.crfreenet.org> 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.198] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: idr wg list Subject: Re: [Idr] I-D Action: draft-ietf-idr-bgp-extended-messages-10.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 Jul 2015 22:15:46 -0000 SXQgc2VlbXMgdGhhdCB0aGVyZSBpcyBlbm91Z2ggaW50ZXJlc3QgYW5kIGltcGxlbWVudGF0aW9u IHRyYWN0aW9uIHRvDQpyZXF1ZXN0IGVhcmx5IElBTkEgYWxsb2NhdGlvbiBmb3IgdGhlIGNhcGFi aWxpdHkgKGFzIGRlc2NyaWJlZCBpbiBSRkMgNzEyMA0KLSBodHRwczovL3d3dy5yZmMtZWRpdG9y Lm9yZy9yZmMvcmZjNzEyMC50eHQpLg0KVGhhbmtzLA0KQWNlZSAgDQoNCg0KT24gNy8xMi8xNSwg NDoxMiBQTSwgIklkciBvbiBiZWhhbGYgb2YgUmFuZHkgQnVzaCIgPGlkci1ib3VuY2VzQGlldGYu b3JnDQpvbiBiZWhhbGYgb2YgcmFuZHlAcHNnLmNvbT4gd3JvdGU6DQoNCj4+IEkganVzdCBpbXBs ZW1lbnRlZCB0aGUgZHJhZnQtaWV0Zi1pZHItYmdwLWV4dGVuZGVkLW1lc3NhZ2VzIHRvIEJJUkQu DQo+PiBDdXJyZW50bHkgaXQgaXMgYSBwcml2YXRlIHBhdGNoLCB3aGVuIHRoZSBjYXBhYmlsaXR5 IG51bWJlciB3aWxsIGJlDQo+PiBhc3NpZ25lZCwgaXQgY291bGQgYmUgYSBwYXJ0IG9mIHRoZSBu ZXh0IG9mZmljaWFsIHJlbGVhc2UuDQo+DQo+b2ggaWRyIGNoYWlycywgdGhpcyBpcyB0aGUgc2Vj b25kIHJlcXVlc3QgZm9yIHRoZSBjYXBhYmlsaXR5LiAgaWZmIHdlDQo+d2FudCB0aGlzIHRvIHBy b2dyZXNzLCB3ZSBlaXRoZXIgbmVlZCB0byB0YWxrIHRvIHRoZSBpYW5hIG9yIGFncmVlIG9uDQo+ c29tZSBkaXNndXN0aW5nIHRlbXAgaGFjay4gIHlvdXIgY2FsbCwgaXQncyBwcm9jZXNzLg0KPg0K PnJhbmR5DQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj5JZHIgbWFpbGluZyBsaXN0DQo+SWRyQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9pZHINCg0K From nobody Sun Jul 12 15:18: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 0BC001A88FC for ; Sun, 12 Jul 2015 15:18:40 -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 mP4bhnL6BZKb for ; Sun, 12 Jul 2015 15:18:39 -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 1A8481A88D7 for ; Sun, 12 Jul 2015 15:18:39 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1ZEPZz-0005IR-JN; Sun, 12 Jul 2015 22:18:35 +0000 Date: Sun, 12 Jul 2015 15:18:34 -0700 Message-ID: From: Randy Bush To: Acee Lindem In-Reply-To: References: <20150706203650.6815.83256.idtracker@ietfa.amsl.com> <20150706210159.GC13743@shrubbery.net> <027801d0b82f$60ad05b0$22071110$@ndzh.com> <20150710192227.GP13783@pfrc.org> <20150712200048.GA21130@varda.crfreenet.org> 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 Subject: Re: [Idr] I-D Action: draft-ietf-idr-bgp-extended-messages-10.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 Jul 2015 22:18:40 -0000 in private email, jgs pointed out there is an fcfs range for cap codes. who's gonna be first? :) randy From nobody Sun Jul 12 18:12: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 716B81ABD37 for ; Sun, 12 Jul 2015 18:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.51 X-Spam-Level: X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 9Mq2QksBAYwQ for ; Sun, 12 Jul 2015 18:12:14 -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 DD0B91ABC74 for ; Sun, 12 Jul 2015 18:12:12 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BVC05167; Mon, 13 Jul 2015 01:12:11 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 13 Jul 2015 02:12:10 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.10]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Mon, 13 Jul 2015 09:11:57 +0800 From: Haoweiguo To: John E Drake , Lucy yong , Susan Hares , "'idr wg list'" , "erosen@juniper.net" Thread-Topic: [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00.txt (7/6 to 7/20/2015) Thread-Index: AdC4UJG6Pj+U9ACORa+TFqfDTB54DgCOU6eAAApncwIAGNjS8AB77xcT Date: Mon, 13 Jul 2015 01:11:57 +0000 Message-ID: References: <02ce01d0b851$4ecec5a0$ec6c50e0$@ndzh.com>, <2691CE0099834E4A9C5044EEC662BB9D571ADA7E@dfweml701-chm> , In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.23.94] Content-Type: multipart/alternative; boundary="_000_DD5FC8DE455C3348B94340C0AB5517334F88AF61nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "'Keyur Patel \(keyupate\)'" Subject: Re: [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00.txt (7/6 to 7/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, 13 Jul 2015 01:12:16 -0000 --_000_DD5FC8DE455C3348B94340C0AB5517334F88AF61nkgeml501mbschi_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi John, I agree with you, the MAC extended community doesn't have sufficient room t= o carry more tunnel information. For current VXLAN and NVGRE tunnel encapsu= lation, the MAC extended community solution is applicable. Just as Eric poi= nts out, in the future, if both the Tunnel Encapsulation attribute (specify= ing a VXLAN tunnel) and the Router's MAC extended community are present in= a UPDATE, how to tackle this situation should be clearly defined in this d= raft, eg. the MAC extended community has more preference, or other recommen= dations. Thanks, weiguo ________________________________ From: John E Drake [jdrake@juniper.net] Sent: Friday, July 10, 2015 21:53 To: Haoweiguo; Lucy yong; Susan Hares; 'idr wg list' Cc: 'Keyur Patel (keyupate)' Subject: RE: [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00= .txt (7/6 to 7/20/2015) Weiguo, A number of the EVPN drafts use the RFC 5512 extended community and they wi= ll continue to do so. As I=92m sure you=92re aware, there is not a lot of = room in an extended community, and this draft is intended to be used for fu= ture applications, e.g., EVPN, L3VPN, or Softwires, that need more room or= more capabilities. This is the same positioning that we used with the previous remote next hop= draft which this draft replaces. Yours Irrespectively, John From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Haoweiguo Sent: Thursday, July 09, 2015 10:00 PM To: Lucy yong; Susan Hares; 'idr wg list' Cc: 'Keyur Patel (keyupate)' Subject: Re: [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00= .txt (7/6 to 7/20/2015) As for the MAC address advertisement mode, this draft seems to be conflicte= d with EVPN draft-ietf-bess-evpn-inter-subnet-forwarding-00. In the EVPN dr= aft, if VXLAN/NVGRE tunnel is used, the remote NVE advertises its MAC throu= gh Router's MAC Extended Community, the MAC will be used as inner destinati= on MAC for inter-subnet traffic forwarding. Thanks, weiguo ________________________________ From: Idr [idr-bounces@ietf.org] on behalf of Lucy yong [lucy.yong@huawei.c= om] Sent: Friday, July 10, 2015 6:16 To: Susan Hares; 'idr wg list' Cc: 'Keyur Patel (keyupate)' Subject: Re: [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00= .txt (7/6 to 7/20/2015) Support WG adoption! This is very useful work. The need for BGP next hop an= d tunnel EP separation has been talked for a while. The draft is quite new. We need think more on the mechanism and rules. For example, is it necessary to require specifying a sub-TLV for each encap= sulation type? Comments: Why does VXLAN encapsulation sub-TLV contain a MAC address, isn=92t the MAC= carried by the NLRI? It should support tunnel stitching at a router, i.e. the tunnel endpoint; u= pon receiving a UPDATE, the router removes the tunnel encapsulation TLV and= /or sub-TLV on the UPDATE and inserts a new one prior to sending it out. In the case of recursive next hop, does it require tunnel ingress router ha= ve the reachable for all the remote end points? IMO: it shouldn=92t. Cheers, Lucy From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Monday, July 06, 2015 8:08 PM To: 'idr wg list' Cc: 'Keyur Patel (keyupate)' Subject: [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00.txt= (7/6 to 7/20/2015) This begins a 2 week adoption call on draft-rosen-idr-tunnel-encaps-00.txt = (7/6 to 7/20/2015). The draft can be found at: https://www.ietf.org/internet-drafts/draft-rosen-idr-tunnel-encaps-00.txt In your response, discuss why this draft proposal for encapsulation: a) [operators] will help deployed networks, b) Solves know problems with other tunnel encapsulation, and c) Provides a way to manage the matrix of tunnels. We will have a status report at IDR on 7/20 on this Working group adoption = call. Sue Hares and John Scudder --_000_DD5FC8DE455C3348B94340C0AB5517334F88AF61nkgeml501mbschi_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi John,

I agree with you, the MAC extended com= munity doesn't have sufficient room to carry more tunnel information. For c= urrent VXLAN and NVGRE tunnel encapsulation, the MAC extended community sol= ution is applicable. Just as Eric points out, in the future, if both the T= unnel Encapsulation attribute (specifying a VXLAN tunnel) and the Router's = MAC extended community  are present in a UPDATE, how to tackle this si= tuation should be clearly defined in this draft, eg. the MAC extended community has more preference, or other r= ecommendations.

 

Thanks,

weiguo

From: John E Drake [jdrake@juniper.net] Sent: Friday, July 10, 2015 21:53
To: Haoweiguo; Lucy yong; Susan Hares; 'idr wg list'
Cc: 'Keyur Patel (keyupate)'
Subject: RE: [Idr] 2 week adoption call for draft-rosen-idr-tunnel-e= naps-00.txt (7/6 to 7/20/2015)

Weiguo,

 

A number of the EVPN drafts use the RFC 5512= extended community and they will continue to do so.  As I=92m sure yo= u=92re aware, there is not a lot of room in an extended community, and this draft is intended to be used for future appli= cations, e.g.,  EVPN, L3VPN, or Softwires, that need more room or more= capabilities.

 

This is the same positioning that we used wi= th the previous remote next hop draft which this draft replaces. 

 

Yours Irrespectively,

 

John

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Haoweiguo
Sent: Thursday, July 09, 2015 10:00 PM
To: Lucy yong; Susan Hares; 'idr wg list'
Cc: 'Keyur Patel (keyupate)'
Subject: Re: [Idr] 2 week adoption call for draft-rosen-idr-tunnel-e= naps-00.txt (7/6 to 7/20/2015)

 

As for t= he MAC address advertisement mode, this draft seems to be conflicted with E= VPN draft-ietf-bess-evpn-inter-subnet-forwarding-00. In the EVPN draft, if = VXLAN/NVGRE tunnel is used, the remote NVE advertises its MAC through Router's MAC Extended Community, the MAC will be used as inn= er destination MAC for inter-subnet traffic forwarding.

= Thanks,

= weiguo

From: Idr [idr-bounces@ietf.org] on behalf of Lucy yong [lucy.yong@huawei.com]
Sent: Friday, July 10, 2015 6:16
To: Susan Hares; 'idr wg list'
Cc: 'Keyur Patel (keyupate)'
Subject: Re: [Idr] 2 week adoption call for draft-rosen-idr-tunnel-e= naps-00.txt (7/6 to 7/20/2015)

Support WG adoption! This is very useful wor= k. The need for BGP next hop and tunnel EP separation has been talked for a= while.

 

The draft is quite new. We need think more o= n the mechanism and rules.

 

For example, is it necessary to require spec= ifying a sub-TLV for each encapsulation type?

 

Comments:

Why does VXLAN encapsulation sub-TLV contain= a MAC address, isn=92t the MAC carried by the NLRI?

It should support tunnel stitching at a rout= er, i.e. the tunnel endpoint; upon receiving a UPDATE, the router removes t= he tunnel encapsulation TLV and/or sub-TLV on the UPDATE and inserts a new one prior to sending it out.

In the case of recursive next hop, does it r= equire tunnel ingress router have the reachable for all the remote end poin= ts? IMO: it shouldn=92t.

 

Cheers,<= /span>

Lucy

 

 

 

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Monday, July 06, 2015 8:08 PM
To: 'idr wg list'
Cc: 'Keyur Patel (keyupate)'
Subject: [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps= -00.txt (7/6 to 7/20/2015)

 

This begins a 2 week adoption call on draft-= rosen-idr-tunnel-encaps-00.txt (7/6 to 7/20/2015).

The draft can be found at:

 

https://www.ietf.= org/internet-drafts/draft-rosen-idr-tunnel-encaps-00.txt

 

In your response, discuss why this draft propo= sal for encapsulation:

a)     = ; [operators] will help deployed networks,

b)     = ; Solves know problems with other tunnel encapsulation, and

c)     = ;  Provides a way to manage the matrix of tunnels.

 

 

We will have a status report at IDR on 7/20 on= this Working group adoption call.

 

Sue Hares and John Scudder

--_000_DD5FC8DE455C3348B94340C0AB5517334F88AF61nkgeml501mbschi_-- From nobody Mon Jul 13 08:29: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 189751B2B9A for ; Mon, 13 Jul 2015 08:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 rgcychfkv9i1 for ; Mon, 13 Jul 2015 08:29:04 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC9281B2B8F for ; Mon, 13 Jul 2015 08:29:03 -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 BYS09484; Mon, 13 Jul 2015 15:29:02 +0000 (GMT) Received: from DFWEML706-CHM.china.huawei.com (10.193.5.225) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 13 Jul 2015 16:29:00 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml706-chm ([10.193.5.225]) with mapi id 14.03.0235.001; Mon, 13 Jul 2015 08:28:45 -0700 From: Lucy yong To: Eric C Rosen , Susan Hares , "'idr wg list'" , Haoweiguo , "Henderickx, Wim (Wim)" Thread-Topic: [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00.txt (7/6 to 7/20/2015) Thread-Index: AQHQu0zIPj+U9ACORa+TFqfDTB54Dp3ZgA9g Date: Mon, 13 Jul 2015 15:28:45 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D571B77BF@dfweml701-chm> References: <02ce01d0b851$4ecec5a0$ec6c50e0$@ndzh.com> <2691CE0099834E4A9C5044EEC662BB9D571ADA7E@dfweml701-chm> <55A0273D.4020608@juniper.net> In-Reply-To: <55A0273D.4020608@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.145.254] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "'Keyur Patel \(keyupate\)'" Subject: Re: [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00.txt (7/6 to 7/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, 13 Jul 2015 15:29:10 -0000 Hi Eric, Please see inline below. -----Original Message----- From: Eric C Rosen [mailto:erosen@juniper.net]=20 Sent: Friday, July 10, 2015 3:13 PM To: Lucy yong; Susan Hares; 'idr wg list'; Haoweiguo; Henderickx, Wim (Wim) Cc: erosen@juniper.net; 'Keyur Patel (keyupate)' Subject: Re: [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00= .txt (7/6 to 7/20/2015) > [Lucy] is it necessary to require specifying a sub-TLV for each=20 > encapsulation type? No, it's not necessary for every tunnel type to have an encapsulation sub-T= LV. [Lucy] Will each potential used encapsulation need a sub-TLV? If not, why s= ome are required and some are not, do we need a code point for these that a= re not required? > [Lucy] Why does VXLAN encapsulation sub-TLV contain a MAC address,=20 > isn't the MAC carried by the NLRI? Consider the case where the application is L3VPN, but one wants to use VXLA= N tunnels instead of MPLS tunnels. You could signal this by attaching a Tu= nnel Encapsulation attribute to a VPN-IP route, where the attribute contain= s a TLV specifying a VXLAN tunnel. But the NLRI of the VPN-IP route does n= ot contain a MAC address. [Lucy] I see. Do we want to open the door for this or require using other e= ncapsulation type for L3VPN? > [Wim] In most EVPN you don't want any MAC encoding in this new=20 > attribute There is a provision for omitting the MAC address in the VXLAN=20 Encapsulation sub-TLV. However, the text saying what to do if this MAC=20 address is omitted seems to need correction. [Lucy] yes. If the flag is clear, the corresponding field MUST NOT be prese= nt. > [Weiguo] As for the MAC address advertisement mode, this draft seems=20 > to be conflicted with EVPN=20 > draft-ietf-bess-evpn-inter-subnet-forwarding-00. In the EVPN draft, if=20 > VXLAN/NVGRE tunnel is used, the remote NVE advertises its MAC through=20 > Router's MAC Extended Community, the MAC will be used as inner=20 > destination MAC for inter-subnet traffic forwarding. If I understand correctly, that draft uses the "Tunnel Type extended commun= ity" to signal that a VXLAN tunnel is needed, and then uses the "Router's M= AC extended community" to signal the inner MAC DA. If one attaches the Tun= nel Encapsulation attribute to a particular UPDATE, one doesn't really need= to also attach either of those two extended communities. However, the tun= nel encapsulation draft should say something about the case where both the = Tunnel Encapsulation attribute (specifying a VXLAN tunnel) and the Router's= MAC extended community are present. [Lucy] Should we consider deprecate "Tunnel Type extended community"? Whether a particular application uses one way of signaling or the other is = outside the scope of the tunnel encapsulation draft. > [Lucy] It should support tunnel stitching at a router, i.e. the tunnel=20 > endpoint; upon receiving a UPDATE, the router removes the tunnel=20 > encapsulation TLV and/or sub-TLV on the UPDATE and inserts a new one=20 > prior to sending it out. If some router is the receiving endpoint of one tunnel and the transmitting= endpoint of another, I don't think anything in the draft prevents it from = doing this sort of stitching. Do you think additional mechanisms are neede= d? [Lucy] There are two scenarios: 1) if the receiving endpoint of a tunnel ha= s the capability for overlay routing/forwarding, the endpoint can set itsel= f as transmitting endpoint of another; 2) if the receiving endpoint of a tu= nnel does not have capability for overlay routing/forwarding, in order to s= et itself as transmitting endpoint of another, it needs to allocate an IP a= ddress that is associated to the previous tunnel transmitting endpoint and = insert this IP address as the transmitting endpoint of another. Please see = draft-hao-bess-inter-nvo3-vpn. It is good for the draft to describe these m= echanisms at a router. =20 > [Lucy] In the case of recursive next hop, does it require tunnel=20 > ingress router have the reachable for all the remote end points? IMO: it = shouldn't. Do you have a particular scenario in mind? I think the only requirement im= posed by the draft is that you shouldn't try to use a particular tunnel if = its remote endpoint is not reachable. [Lucy] This can be applied to the case as of Inter-AS option C. But use one= BGP protocol to establish tunnels instead of two BGPs (EBGP and MP-BGP). L= et's talk more offline. Thanks, Lucy=20 From nobody Mon Jul 13 12:40: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 CA2011B2D2F for ; Mon, 13 Jul 2015 12:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.178 X-Spam-Level: X-Spam-Status: No, score=-0.178 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 PkiF4rFshjpo for ; Mon, 13 Jul 2015 12:40:24 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 395DD1A87DB for ; Mon, 13 Jul 2015 12:40:24 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 714121E434; Mon, 13 Jul 2015 15:42:13 -0400 (EDT) Date: Mon, 13 Jul 2015 15:42:13 -0400 From: Jeffrey Haas To: Randy Bush Message-ID: <20150713194213.GY13783@pfrc.org> References: <20150706141017.31158.42788.idtracker@ietfa.amsl.com> <20150710210111.GU13783@pfrc.org> 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 list Subject: Re: [Idr] Comments on draft-ietf-idr-aspath-orf-10.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, 13 Jul 2015 19:40:24 -0000 On Fri, Jul 10, 2015 at 02:22:10PM -0700, Randy Bush wrote: > > I must admit to being somewhat dismayed by seeing this draft resurrected. > > what gets me is the threat model. you can trust me to tell you what you > can trust from me. There's perhaps an amusing element of "trust, but verify" to ORFs. In theory, they may be generated by your inbound policy sent out as an ORF. This doesn't mean you shut off your inbound policy, just that you hope that by pushing it outward you have to do less work. -- Jeff From nobody Mon Jul 13 12:54: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 88A4D1B2DF5 for ; Mon, 13 Jul 2015 12:54:38 -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 EUbDS6tGJuIJ for ; Mon, 13 Jul 2015 12:54:37 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0122.outbound.protection.outlook.com [65.55.169.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD2191B2DEF for ; Mon, 13 Jul 2015 12:54:31 -0700 (PDT) Authentication-Results: pfrc.org; dkim=none (message not signed) header.d=none; Received: from kblanc-sslvpn-nc.jnpr.net (66.129.241.11) by BLUPR0501MB1825.namprd05.prod.outlook.com (10.163.121.148) with Microsoft SMTP Server (TLS) id 15.1.213.14; Mon, 13 Jul 2015 19:54:30 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: "John G. Scudder" In-Reply-To: <20150713194213.GY13783@pfrc.org> Date: Mon, 13 Jul 2015 15:54:20 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20150706141017.31158.42788.idtracker@ietfa.amsl.com> <20150710210111.GU13783@pfrc.org> <20150713194213.GY13783@pfrc.org> To: Jeffrey Haas X-Mailer: Apple Mail (2.2102) X-Originating-IP: [66.129.241.11] X-ClientProxiedBy: BN3PR09CA0002.namprd09.prod.outlook.com (25.160.111.140) To BLUPR0501MB1825.namprd05.prod.outlook.com (25.163.121.148) X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB1825; 2:cyAVgVCmS7blFbuqcn4CUk3J6M3pj+RByHZpCuQ/NGmfKPptWCz1whxxWIaUHiuu; 3:amw2kYrapv7ckJT9uyN+652KPNh1jiD/IfTgLqr+YbVaVWd7B3vBIY3bTUzu6SHMT8YtLs+vnwByYrYjE932HvpCDtmozU0Ktdyb57RonzdgCdjBNHKUWQt3t29jkRD9DaGKVVzsVqQcrH92SZ7FLA==; 25:J4DeHyRZ7HLqBTGYiLATmqNEucqDAvIX1dMNiFwUb+WEu6Wcoe6JqTjOPSHrg8e/WtCcrPl/aRJoEdcD8iHlVpMYIcdD0/gDI7CUmrC6gLjiM1p4KIAEuOELki3vqCPk7Kps5pOoxIxH7SsgOvjg0RUFRW6858gdXU1fw/94L1QZIU79GxnETG2XWYDdltVrVG8zIbnKfp6YL2WGcxFVRukDzvTUYLrq2w/j/XDh8y7GiRhJKWevj8Z1QJ4OPWZRkYK3x/xj8baeDrNUbLojgw== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR0501MB1825; X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB1825; 20:t/1kLuUSgj9nzD419CRNzOaGnhPkN1LoTPzoJdLv8g7bp5gzQ6ycAl3o1v5KG3C/9BYaYV1HYkNXP/n6esyk3sHtFZMdgR+v5GimnqKKPVW02zOVSw0hSTqpXqaZrABudST063oR1tU/7YVaRHHTZcM5Dk+K/6Zx4jI8eR/ba/MWM6wDfks20hGu723d5rlSSYZPoe5KoOQj5RnaAZMf5DYee5evISLCC56xKvn7N5ciYcLlK2/QVG3U9zBTsPX+lYXF4PENIIngml7zjZpOrEvlLHpZyhWprRuJa2cp9H41YSewVZskTDJDRzWDVSKKHpV2qgX/xz8eQQoacYj3aqTnSUxU7P5qx3vR+XQAZB/MCjlld7fzxCcqAzAO64Q4ODG+iivWN2o7UQs04piy35SM8LsN+0dp2i1Hw6rm67me2dGZzr0LSSotnEGcUKiE1xsqqEoOAys0Rwz7INOQKbbHrtQ1mAPwfuvgS822GawPUGvpVE4uu7tWjbjLIOnb; 4:hq+Ay9u7eoIy06oFI71aebiodvAFNqio+5KjgJboyGmJi66qY03OwP493iCy4b7Fs0dhmnPpby80NW9EKxT2C6hHOzTp5Jcx1h0ySRjhpjNBb3/qRkGJBgT81EZU4X+z9CdrCIGyGbCj/HY8sOYr4EeWghvWEXRA3cd3t8PAJA8uQ6AlJIeT51S44DcCDWgng+TOaeMchavbirlzffSBjw1/JO2Yytqzy+mutNKvlckihs3DhaXQbKTREEEH4vZjNSKPH2y7U5QNKzgvrax/jZXCMM6k8ePdyBlViC8YxWo= BLUPR0501MB1825: X-MS-Exchange-Organization-RulesExecuted 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:BLUPR0501MB1825; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB1825; X-Forefront-PRVS: 0636271852 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(24454002)(377454003)(19580405001)(19580395003)(87976001)(46102003)(46406003)(53416004)(23726002)(83716003)(230783001)(76176999)(97756001)(86362001)(66066001)(47776003)(36756003)(93886004)(42186005)(77156002)(92566002)(62966003)(50226001)(2950100001)(82746002)(110136002)(122386002)(50986999)(40100003)(189998001)(5001960100002)(50466002)(33656002)(77096005)(57306001)(42262002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB1825; H:kblanc-sslvpn-nc.jnpr.net; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BLUPR0501MB1825; 23:eRh4Y+RyXI84vdB037ENT17v/7yt7jZZ5Se4ElM?= =?us-ascii?Q?l1JakaasLogAH46TdcDypjZRdTUg9H03eMJI/hTRAA4aN6B9KXH2M7lLsI6i?= =?us-ascii?Q?BLbSK5JJLfNNyXD81FBxZonYGn4UCAL9IrYrUjpPoSLkvy//meRijVjj7S/f?= =?us-ascii?Q?dp+RnHUDjNy/vV1tZgCoVdgvV1eKZjEpX1GyKGc5ilGfj98BWdogLf5K6os6?= =?us-ascii?Q?NGqCQ0kOgLU9HDgozFZmE+2eKMMJncxlgDCeNuJA20zqq0a4sGnQkZwSixpw?= =?us-ascii?Q?XyQZLiMxytaRBusA7/iCSCjBDvKh20qbUsQaSYXhy1c/cP95p46y0yPUYoWm?= =?us-ascii?Q?6cN5dFn5fyZ9SKpvlOZ887NoGbaE9QSr16VUzj27ifGKUcPW9E5JDXfgmZb7?= =?us-ascii?Q?pVlM4piwyP1ZrG1O6GBIV1S7+0HaRdz9eLiu+1yx3/InclJwmDRtrAmJZcd3?= =?us-ascii?Q?rVD7gf0MtscnUivcDAFdV9qqLqO365yNOcivQ/00kMFuvqdSUKpru/dZlDkO?= =?us-ascii?Q?hecd/tGRChw3JoD1uM1sxp3pNngA0GdjdwpnOIXMaihqSfw9G4udP9m6hS3N?= =?us-ascii?Q?6TNefDXlVoOnqxR3I36Kr+hTxIzIBbyOZxUHKtJHkFiQIh68PubH6MvpqC5e?= =?us-ascii?Q?uhugwbLoeLCuggeGOI9XudWTRa6tBSEMNfzOwz+l2JUrbERkl6HGQNxYXGQw?= =?us-ascii?Q?pqnjyMODmrRxNspP4/1aHw/bDzf/vRskZ2F1uYlG6J1f02kmjgkhqsOJg2AM?= =?us-ascii?Q?BghBTM54hOxtt0uf7oP8R7DEQ/2kaQ9XawDT7a8z5I8moSiRd1jTCvdy7HXZ?= =?us-ascii?Q?LTypNfx8ZXUWhIWfe9myMksdwyzddJf4682BsWov5A8iw2w5UVV09eyCB/jK?= =?us-ascii?Q?4AESrkRWYbSdcJELUTpbhYGng3iWvl0Y7cLrUwS2ZUpuuRj6FgWsdkmG7b34?= =?us-ascii?Q?4nXOcUk7x1BRd1nz/cCP79KswrIyGVbxwntRuodR+91xZbZATscUFibDU39w?= =?us-ascii?Q?Mr08fM2z6I362Sma/Iy+sEhZ+?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB1825; 5:Jkh2iupmD9sgOxkteUMH6SCy+U5oPYaonDDTUd8yrvE2Gq/F6NxjMcdni97ZSiHFFt//HNqLnbpzjMdsz40EMLJszdPIXguQGOYpcSPom9seoDgTfJBm0qO9eWfPt/PyevQyZJBeZGG8RuAZv2f5nw==; 24:zSAzQf0ZCkA6SzDJLiqZfNVel6JNCffq8DZN2URlYZERaXlTKjJF4u9h7/A4PcJuTZwHELD2LWTs0vbjilh0YKWBckYpa248cX1s17fGtNk=; 20:K+1JyTiO/cM8QRklu1DPlGqtfxgdk8BopsKcrD2zuelLygDe6VBWLk9K+8FDqv4WZhUdvxDfOSinYJkLxcgwbQ== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jul 2015 19:54:30.2132 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB1825 Archived-At: Cc: idr wg list Subject: Re: [Idr] Comments on draft-ietf-idr-aspath-orf-10.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, 13 Jul 2015 19:54:38 -0000 On Jul 13, 2015, at 3:42 PM, Jeffrey Haas wrote: >=20 > On Fri, Jul 10, 2015 at 02:22:10PM -0700, Randy Bush wrote: >>> I must admit to being somewhat dismayed by seeing this draft = resurrected. >>=20 >> what gets me is the threat model. you can trust me to tell you what = you >> can trust from me. >=20 > There's perhaps an amusing element of "trust, but verify" to ORFs. In > theory, they may be generated by your inbound policy sent out as an = ORF. > This doesn't mean you shut off your inbound policy, just that you hope = that > by pushing it outward you have to do less work. ... and you can argue that the cost to the sending router ends up being = low, nil or even negative, making it a win-win. This is because, while = on the one hand the sending router has to evaluate extra policy, on the = other hand it may construct and transmit fewer updates. Of course = whether this ends up being borne out in practice depends on details of = the implementation and the contents of the Loc-RIB and the ORFs. --John= From nobody Mon Jul 13 12:57: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 463261B2DD9 for ; Mon, 13 Jul 2015 12:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.321 X-Spam-Level: X-Spam-Status: No, score=0.321 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 3cValPZs-LxU for ; Mon, 13 Jul 2015 12:57:54 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 5E8051B2DCD for ; Mon, 13 Jul 2015 12:57:54 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id C159A1E435; Mon, 13 Jul 2015 15:59:43 -0400 (EDT) Date: Mon, 13 Jul 2015 15:59:43 -0400 From: Jeffrey Haas To: "Jerome Durand (jerduran)" Message-ID: <20150713195943.GB13783@pfrc.org> References: <00a901d0b285$b6637430$232a5c90$@ndzh.com> <55490D92-7506-42C4-B279-430D7F18C89A@cisco.com> <8274F17D-5EDB-4CAE-8B8F-C0FA052B831B@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <8274F17D-5EDB-4CAE-8B8F-C0FA052B831B@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "idr@ietf.org" , David Freedman , Susan Hares Subject: Re: [Idr] draft-jdurand-auto-bfd-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: Mon, 13 Jul 2015 19:57:55 -0000 [re-ordering the top posting to bottom] On Thu, Jul 09, 2015 at 04:20:21PM +0000, Jerome Durand (jerduran) wrote: > Le 5 juil. 2015 à 01:56, David Freedman a écrit : > > > >Why do you need full BFD for auto-bfd as opposed to utilize S-BFD (Seamless BFD) which is effectively unidirectional ? > > > > We don't (need this) at all, but auto-bfd was not written with seamless BFD in mind (since classical BFD is what is out in the field now), > > but I take your point, perhaps we should include the case where S-BFD will be used, in such case, of course, the flag can > > be dispensed with. > > > > Dave. > > Any other comment from the group? S-BFD isn't fully uni-directional, otherwise it wouldn't be bi-directional. :-) The important property from S-BFD is that no specific session needs to be provisioned. Regular BFD would still need to have a session bootstrapped from gleaned information - BGP nexthops in our discussions. It really should be understood that plain BFD can't quite do what this draft intends to do since it requires alterations in the Diag code behavior for signaling. I'm going to suggest again wearing my BFD hat that this is not a good idea in trying to move a BFD version of this proposal along. But as noted above, S-BFD won't have this particular issue. The main issue is that S-BFD is a very new feature and that it's going to take a while to deploy. I'm going to make a point I made in an earlier response: The general behavior of using BFD for BGP nexthops is covered in both proposals. The impact of permitting BFD on those nexthops to influence BGP route selection is appropriately standardizable in IDR. There's the related impact on BFD for multiple sessions that will require some discussion in BFD that both drafts will have to accommodate. The RS-notification behavior, perhaps, can be made a separate issue. It's still valuable, but there's still room for discussion on the signaling. I'd suggest this is a good discussion to have at IETF-93. -- Jeff From nobody Mon Jul 13 13:39:16 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 4F7C71A88CA for ; Mon, 13 Jul 2015 13:39:14 -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_40=-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 kXMQNTxBqfgX for ; Mon, 13 Jul 2015 13:39:11 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0116.outbound.protection.outlook.com [207.46.100.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 237591A88C3 for ; Mon, 13 Jul 2015 13:39:10 -0700 (PDT) Authentication-Results: exa-networks.co.uk; dkim=none (message not signed) header.d=none; Received: from kblanc-sslvpn-nc.jnpr.net (66.129.241.11) by SN1PR0501MB1840.namprd05.prod.outlook.com (10.163.131.150) with Microsoft SMTP Server (TLS) id 15.1.213.14; Mon, 13 Jul 2015 20:39:08 +0000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: "John G. Scudder" In-Reply-To: Date: Mon, 13 Jul 2015 16:38:59 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20150702142348.4291.10005.idtracker@ietfa.amsl.com> <7C5305E5-69BF-4796-900A-726FFE4B2EEE@juniper.net> To: Thomas Mangin X-Mailer: Apple Mail (2.2102) X-Originating-IP: [66.129.241.11] X-ClientProxiedBy: BY2PR08CA062.namprd08.prod.outlook.com (10.141.248.180) To SN1PR0501MB1840.namprd05.prod.outlook.com (25.163.131.150) X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB1840; 2:bR//vVANAyI/6wTcjsh5477IYi9JLK9f/Hqb2UnA4cNL1qRyZmdPhkRr9gk+StDG; 3:6RBz4OQ6fi8ZGFFJlpw+pGVlHkYpGs1em3sDJr9GDdxIHOvT/RennMzZh9s1zLc6uGDO82NvxoznVrJ4nxxmKpOIvrxk06qXYE8cVPytr6kvD1m0mwkmuUiyR5itSbLsqXNJxBztp2MbZ7h9gLybuA==; 25:TRyabtd8ciqiNgWgHwNDBvZ7H2wgy1FMXvan5ZLUscuT0kcGjnWgX1rsYQ8ZjhKN+3Qd3GjBjelCt99e4YHC1Y3jHsB7SgDj5lTOKXgnuboVy7Hf+AlKwf6rgAUtKTlzm0hqnKfSzn88ubBjsrnbXswRwx2AjImbgQ2t64Wb/pVUf7cq9lE0dbpAgfpcFSsfHQpyCFUlbzB01Y7GnBnRLrw50QhwocKNLb/03Te0x9qmX2L3Cx7+VfXLdgSqybUIQYDUboq+3+8scbkF64sG+g== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0501MB1840; X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB1840; 20:4p4D/rl2C5TUPfU1avBuPz3ZICFzeSzTfwc7Q76pDkf9IV2Iz/DClgiYEeCQ/yFh88nAVxxtSQUU6uw41QdDkCsshyGU7VHRNoeO1AGdBZ+YlZhv5FNP5K8KCXBO+bJkohcSEB9Lub1MJ9pTcif21ITCUAf6qqXXfYjJl8MV9Ky9ELp9Hpc5dQVNSDmXL6J3NNUtPPL1g3xc7n+4sP1cqyMRnULzbrc0ai0hn/MZ/OOoZzQ2nOmy+JXAAAaJR1utND0JOImAxR4lrLJpxS3B/mXJPwAmp90yKrI0f+puB+vhXLiEF6ioO91M5uRdYCCNz8fIhnMusJXas8m4fLpnnBTqovomF788jgHBxzZECGlYEH8OyRZHr4uCovVFrK6CRoK/KpzHNF8ohLKLwJuRAw9YrpNSktxh2Po5PHGt0/NoJg4UMHc2yAQyfU26wAYoC9oNjYj2oSJjnWys2I792hevQl8MVdWhxTQyXfjbhBByVXx8T2b3F9GNdEiidRUV; 4:HronbU0bJ7adMLTkIvoCsiH9HKpFYg0d7Mg5q2c8UBBddz19qJ8Wl+FKXH3PPW76QeE89XdXAKF2wLP1JpyFxELJzxvblrYUMQF2lE3QUFK07+v1pCPwQKiqBjdkf3qEGMibn43/QBx5PSjl0XwQ/Ah3GU5oVxtPza3jDRpFVb85swJSxyybUmRiuEvHa2Efg9QHWJ6LTjYbwvPhHLyuv8vwXjLsJpQ07s2xhPd4OxMeXyfaYm5vOQrlpDKgshAxXhGT3uhp4ja+NJLa2/3gzgRiVtBaP2xAw1lvkWJ72yg= SN1PR0501MB1840: X-MS-Exchange-Organization-RulesExecuted 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:SN1PR0501MB1840; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0501MB1840; X-Forefront-PRVS: 0636271852 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(164054003)(53754006)(24454002)(377424004)(51704005)(50226001)(50466002)(33656002)(42186005)(2950100001)(5001960100002)(7110500001)(57306001)(66066001)(15975445007)(77156002)(47776003)(62966003)(1720100001)(53416004)(2420400003)(189998001)(110136002)(77096005)(46102003)(92566002)(86362001)(561944003)(40100003)(19580395003)(83716003)(36756003)(87976001)(19580405001)(122386002)(82746002)(50986999)(23676002)(230783001)(76176999)(42262002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0501MB1840; H:kblanc-sslvpn-nc.jnpr.net; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtTTjFQUjA1MDFNQjE4NDA7MjM6N3JTZzYxUEZFT2lGQlhiWjhoUjBOdFo3?= =?utf-8?B?alZyYVdxKzJBa3RDcmwvVXB0Z1gzSkpHbEJaenR5TENXNWdBbXYzSDFDZ2tZ?= =?utf-8?B?UE1ydndGZjhMb1pFOVZ5TklnRkthTGtYai9IZCtTc3F3MzgvNUtuWWthM2NO?= =?utf-8?B?Q2RTWW42TmZDLzR6R2lPT29PelI2dW5xRFZWUVdKMk9iK3lGRGdrZGlxTnU1?= =?utf-8?B?akExSlJ0U1I2STc4NlZkQXl5ZjFMUlVZb3ZIdmh2R1kzamNLRUdGL3ZCdU9E?= =?utf-8?B?TnhvMlY3eklGYlFMejNVaGU2aml4ajV0Z01BbllwMkhUcWl2NnVqYmR2U3d1?= =?utf-8?B?ZVptb0NmbFAyd1Z0OXcwTUsxa1NoVmI3c1gyRmo5aVNRbVQzTjZMZzFFM3U0?= =?utf-8?B?TDd4SkJkS1JaMTMxVWV3eG9WbHcrYkEvMkVMZzg0RlZFRE5ZaUFWVjhpNWlQ?= =?utf-8?B?aGVYSGxybmxhVXVGQzB2di9zVjZwWCt5eXBBckpwUTBUQ1NGSGJDZ29GYUFn?= =?utf-8?B?SmhoZUxuNkE2ZklrVTg3TDV3OFVuaUpJVXR2K2d3MG5leTJFZW11cFR3SmVM?= =?utf-8?B?Tldha0k5OG1YVDMzUnp3ajlvQ3JQMXBvY3lyQ0EzeGFPdnZ4aHV3a3JrSkIx?= =?utf-8?B?YzBUS1JSblRNLy9pd2dMT2YxcDFTakJQbUtjUTNSMGsrcUxiU3JaenZoNXZW?= =?utf-8?B?N0tqeGw4Z1ZVNkZXd3VMTDd0NEI3alZReXpLRGppdlAwUmJoMWRjazlKamQ3?= =?utf-8?B?aFUvY1FWMzhjVHdzSkhHeW0veWFXV2lya2t2bnMzZGdTWjRPRjQzaHlkdEYx?= =?utf-8?B?a21nbk9KVmszVkZIelhRZXJCOGc1U0FNc1RiMnU5MythTkJ0cllEbS84TVkx?= =?utf-8?B?QTl4RGc2MTFqUjNyTlZLZHlHTVNlVFNYTjJESm9XbGJ4SlB0dW5pUmgwYnps?= =?utf-8?B?OTkwK0lubmVOK2trRXh6dHE4UFBrbW1LRmNuTi81ZjNXNzloMTc4cVMzNzBY?= =?utf-8?B?eGcvdUV1RnhDWGMzd0hGSldNVm1UL2ZVdGJoTUhkdTZqbmJXN3h4SjVZMEF4?= =?utf-8?B?VTNnSnRySzRZT082eDYzakZncXZOV05PVGYzLzdkVzNwR1lGRExyVVdLNDBm?= =?utf-8?B?OWpCVGdHSHEyeisvNXQzWmhHV003UzRhcU1EN1JobUl4aG9uZjduM2t0S2lL?= =?utf-8?B?cm9kUkcxL0pHS3c1OFMxUXEycXora3k5bkNFQ21uQkVlcFlicStQdi9tcEVp?= =?utf-8?B?a2xVN01idU5OSUdLYmlrODFCUm9udVRwTy8rTnp4SHBIME53WlMxUk13SXlB?= =?utf-8?B?dnBlVnRLZlFyTjFpejZFcmlyNUIyNzcwaEl5Sm9Zb3ltclFZOG1qSmU3b09D?= =?utf-8?B?cnBxMzZNR1ZBcll3Ly8wakl4aWwxT3VTcDkwWHV2cHU3MlFCMkUwOXpNRlNs?= =?utf-8?B?VTZja3RQZUNIcnJ6YXNvQmNSTEhORUpJUUdITFBuNnhIOGV0REpIdHU3RTdi?= =?utf-8?B?TjU2SlhJOTFNUWx2VmhxU1FpYUtZZ2JHcURkYVVJSnZwNHZTNmE3cjI3OTZQ?= =?utf-8?Q?a0H?= X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB1840; 5:RG+2KFS3sz0UJ1N68RCTvh3NtWOTSqNhg/P3+PcwRF6hYSU9Xa/R+TlMK/Rphj2Z+4nEnfLBXFWhXfuXapSLjmCmBM4CQePFnQUVaMY1Xl4muKkIiwnJXoydvZUUioVeNA+PYDnsfgXnn009G+ChRg==; 24:NIuMCEDH+1HfrwnhawHFeumtGrvfjP65dMQUXvAbehFBYCglxt8FrTr0FuiiynY6p9BGMP8nnkCxbQGVs/MKONkYXhQwhDu6JPbVxquItf4=; 20:LQ/p4sPTX/II0CX9HSboFxUyS0pKgG44Ma/Dw9oNygpv/gPHmJJ9ABGF0LSR4KHG488JthuVybxGZQMu2EPeFQ== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jul 2015 20:39:08.4351 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0501MB1840 Archived-At: Cc: "idr@ietf. org" Subject: Re: [Idr] New Version Notification for draft-scudder-idr-capabilities-registry-change-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2015 20:39:14 -0000 Thomas, Let me start by agreeing with the points Jeff made. More in-line below. > On Jul 3, 2015, at 5:28 AM, Thomas Mangin = wrote: >=20 > Hello John, >=20 > If I understand your draft correctly ( it is a big assumption ) the = new proposal would seem to make it much harder to experiment: Only = allowing 4 code for experimental use means that no more than 4 new = features can be tested simultaneously by a single vendor ( and less if = two or more vendors want to collaborate on a feature together ). This = seems to me to be quite on the very low side, I would feel better if = this number was to be raised. >=20 > Therefore I would like to know if the authors would consider raising = the number from 4 I don't object to increasing it if there is WG consensus to do so. The = number 4 reflects a starting point and was chosen according to my own = judgement that on one hand, there is a need for a BGP developer to have = the ability to have several features in development, but on the other = hand, those features should really not be released from the lab still = using experimental code points -- they should use an allocated code = point. I see the use of "experimental" as virtually being limited to = "give me a code point that's I can use to verify my implementation = builds and runs in the lab, but at the same time can be marked as = 'toxic' by my release tools to ensure that I do *not* accidentally = release into the network any software that doesn't have a = properly-allocated code point." It might even be reasonable for = commercial test suites to verify that experimental code points are not = in use, when doing validation tests. > and make a distinction between private for internal use only ( most = likely going to be used by a single vendor ) and private for interop = testing ( when two vendor who implemented the same draft may want to = check all is fine before getting a code and going to production / IANA = allocation process). I don't see the need for the distinction between these two. But then = again, I don't see the value of 'private' code points at all in this = context, only 'experimental' whose applicability is more limited than = 'private'. You'll see in RFC 5226 'private use' has a defined meaning: Private Use - For private or local use only, with the type and purpose defined by the local site. No attempt is made to prevent multiple sites from using the same value in different (and incompatible) ways. There is no need for IANA to review such assignments (since IANA does not record them) and assignments are not generally useful for broad interoperability. It is the responsibility of the sites making use of the Private Use range to ensure that no conflicts occur (within the intended scope of use). Examples: Site-specific options in DHCP [DHCP-IANA], Fibre Channel Port Type Registry [RFC4044], Exchange Types in the IKEv2 header [RFC4306]. An example in the BGP context is (RFC 1997-style) AS-specific = communities. "The semantics of the final two octets may be defined by = the autonomous system" is exactly what's meant by "private use". The = thing is, although we do use Communities that way, we don't use = Capabilities that way. I suppose we could introduce such a thing = (composable pluggable BGP implementations with user-defined type codes) = but so far, I'm not aware of such, and it's a bit of a stretch seeing = user management of type codes being better than registered type codes. = Such things haven't even caught on for UDP and TCP port numbers AFAIK, = where it's a lot easier to manage. > I am also unsure if code 128 ( CISCO Route-Refresh ) and 131 ( CISCO = multi-session ) are still found in production networks ( AFAIK it was = the case a few years ago ), and if so, if this situation require = formalising. Even if they are no longer in use (one would hope they are now using 2 = or 68, respectively) they should probably be registered as "deprecated" = for the reason Jeff mentioned.=20 > ExaBGP also use the following code in the 128+ range: 184, cumulus = hostname draft; 185, operational draft. Would you expect me to relocate = these code into the new 251-254 range ? In general I think the right thing to do is, use experimental codes when = developing, use registered codes when an experiment becomes mature = enough to want to use it in the network. If the experiment is = standardized sometimes the semantics will remain the same and the type = code can continue, in other cases the semantics will change and a new = type code will have to be allocated and the old one deprecated. I'm sure = our perspectives differ somewhat because I've spent years in = environments where there's a high cost to deprecate or change a code = point. You have probably got an enviably low cost to do this with = ExaBGP. In the end, the answer to your question is, do what is in your users' = (and the Internet's) best interests.=20 > Other codes may be found in production =E2=80=9Calive and kicking=E2=80=9D= in the 128+ range too. I am not sure how much of a problem (if any) it = is. Ask yourself whether the outcome would be acceptable if those codes find = themselves trying to interoperate with some other implementation using = that type code for a different specification. It's hard to see the = outcome being anything desirable. Whether it would be a disaster or = merely annoying is anyone's guess, but I can see no reason to run the = risk when doing so is completely unnecessary. Regards, --John >=20 > Sincerely, >=20 > Thomas >=20 >=20 > http://exa.net.uk/about/contact-us > On 2 Jul 2015, at 15:33, John G. Scudder wrote: >=20 >> Hi Everybody, >>=20 >> I was looking at the registration procedures for Capability codes = recently, and they are not what I would have picked if specifying = Capabilities today. In order to revise the procedures, IANA requires an = RFC. Accordingly, I've written a very short Internet Draft and would = like to propose it as a working group item. It's so short that I'll = paste the entire meat of it here: >>=20 >> [RFC5492] designates the range of Capability Codes 128-255 as >> "Reserved for Private Use". Subsequent experience has shown this to >> be not only useless, but actively confusing to implementors. BGP >> Capability Codes do not meet the criteria for "Reserved for Private >> Use" described in [RFC5226] S. 4.1. An example of a legitimate >> "private use" code point might be a BGP community [RFC1997] value >> assigned for use within a given AS, but no analogous use of >> Capabilities exists. >>=20 >> Accordingly, this document revises the registration procedures for >> the range 128-255, as follows, using the terminology defined in >> [RFC5226]: >>=20 >> 128-250: Standards Action >>=20 >> 251-254: Experimental Use >>=20 >> 255: Reserved >>=20 >> The procedures for the ranges 1-63 and 64-127 are unchanged, >> remaining "IETF Review" and "First Come First Served" respectively. >>=20 >> That's it. Even with boilerplate and some explanatory text the whole = thing comes to just over 3 pages. I'm not wedded to the exact ranges and = policies I put in the document, I just needed something as a stake in = the ground. I put in a section with my reasoning, though, and here's a = little more: >>=20 >> Q: Why Standards Action? >> A: we already have a decent-sized FCFS range. Standards Action = precludes any risk of a "run on the bank" exhausting the number space. = We can always reclassify it again in the future if we need to. >>=20 >> Q: Why Experimental Use? >> A: There is a legitimate need for temporary code points to be used = during internal development. It's better to have these come from an = identifiable "swamp" than it is to have developers squat on random code = points. >>=20 >> Q: Why Reserved? >> A: No very compelling reason other than that reserving the all-ones = value is kind of traditional and there doesn't seem to be a strong = reason not to. It's true that the all-zeroes value is already reserved, = so the need for reserving all-ones is questionable, but OTOH it also = seems harmless to do it, especially given that again, we can always = reclassify it in the future if needed. >>=20 >> There are currently no registrations in the range 128-255, so = hopefully this change should create no issues. However, if someone is = currently squatting on a code point in this range, now would be a good = time to come in out of the cold so we can consider grandfathering their = usage if warranted. I think given the previous designation as "private = use" it would be hard to fault anyone for having mistakenly made use of = a number in this range. >>=20 >> Thanks, >>=20 >> --John >>=20 >>> Begin forwarded message: >>>=20 >>> From: >>> Subject: New Version Notification for = draft-scudder-idr-capabilities-registry-change-00.txt >>> Date: July 2, 2015 at 10:23:48 AM EDT >>> To: John Scudder , John Scudder >>>=20 >>>=20 >>> A new version of I-D, = draft-scudder-idr-capabilities-registry-change-00.txt >>> has been successfully submitted by John Scudder and posted to the >>> IETF repository. >>>=20 >>> Name: draft-scudder-idr-capabilities-registry-change >>> Revision: 00 >>> Title: Revision to Capability Codes Registration = Procedures >>> Document date: 2015-07-02 >>> Group: Individual Submission >>> Pages: 4 >>> URL: = https://www.ietf.org/internet-drafts/draft-scudder-idr-capabilities-regist= ry-change-00.txt >>> Status: = https://datatracker.ietf.org/doc/draft-scudder-idr-capabilities-registry-c= hange/ >>> Htmlized: = https://tools.ietf.org/html/draft-scudder-idr-capabilities-registry-change= -00 >>>=20 >>>=20 >>> Abstract: >>> This document updates RFC 5492 by making a change to the = registration >>> procedures for BGP Capability Codes. Specifically, the range >>> formerly designated "Reserved for Private Use" is divided into three >>> new ranges, respectively designated as "Standards Action", >>> "Experimental" and "Reserved". >>>=20 >>>=20 >>>=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 >>> The IETF Secretariat >>>=20 >>=20 >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Mon Jul 13 13:42: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 00A921A88CE for ; Mon, 13 Jul 2015 13:42:22 -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 Ml3FqN1zaBec for ; Mon, 13 Jul 2015 13:42:21 -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 23BB71A88B9 for ; Mon, 13 Jul 2015 13:42:21 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1ZEkYN-0003d9-VF; Mon, 13 Jul 2015 20:42:20 +0000 Date: Mon, 13 Jul 2015 13:42:19 -0700 Message-ID: From: Randy Bush To: Jeffrey Haas In-Reply-To: <20150713194213.GY13783@pfrc.org> References: <20150706141017.31158.42788.idtracker@ietfa.amsl.com> <20150710210111.GU13783@pfrc.org> <20150713194213.GY13783@pfrc.org> 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 Subject: Re: [Idr] Comments on draft-ietf-idr-aspath-orf-10.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, 13 Jul 2015 20:42:22 -0000 > There's perhaps an amusing element of "trust, but verify" to ORFs. as the recipient, how do i verify in a fashion, and at a cost, that does not essentially obviate the orf data? randy From nobody Mon Jul 13 16:46:37 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 365CF1A87C2 for ; Mon, 13 Jul 2015 16:46:36 -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 cUE7w0AibZY1 for ; Mon, 13 Jul 2015 16:46:35 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (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 E5F081A87BD for ; Mon, 13 Jul 2015 16:46:34 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.34; From: "Susan Hares" To: "'Randy Bush'" , "'Ondrej Zajicek'" References: <20150706203650.6815.83256.idtracker@ietfa.amsl.com> <20150706210159.GC13743@shrubbery.net> <027801d0b82f$60ad05b0$22071110$@ndzh.com> <20150710192227.GP13783@pfrc.org> <20150712200048.GA21130@varda.crfreenet.org> In-Reply-To: Date: Mon, 13 Jul 2015 19:46:26 -0400 Message-ID: <004b01d0bdc6$221d8a80$66589f80$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGBfyn0a/XgdWqa5S7LQAUhGp5VDwJoZzRkAL6c2DwCuEQnVgI+2y9SAchfrQoCNhVKSwGg/0M8ngqg8uA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'idr wg list' Subject: Re: [Idr] I-D Action: draft-ietf-idr-bgp-extended-messages-10.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, 13 Jul 2015 23:46:36 -0000 Randy: My apologies for missing the early capability request. I will circle with Alvaro Sunday at IETF to see if I can get this done quickly. Sue -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Randy Bush Sent: Sunday, July 12, 2015 4:13 PM To: Ondrej Zajicek Cc: idr wg list Subject: Re: [Idr] I-D Action: draft-ietf-idr-bgp-extended-messages-10.txt > I just implemented the draft-ietf-idr-bgp-extended-messages to BIRD. > Currently it is a private patch, when the capability number will be > assigned, it could be a part of the next official release. oh idr chairs, this is the second request for the capability. iff we want this to progress, we either need to talk to the iana or agree on some disgusting temp hack. your call, it's process. randy _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From nobody Mon Jul 13 16: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 E08E31A87D2 for ; Mon, 13 Jul 2015 16:52:39 -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 4kRS8eox1asw for ; Mon, 13 Jul 2015 16:52:39 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (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 C61241A87CD for ; Mon, 13 Jul 2015 16:52:38 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.34; From: "Susan Hares" To: "'Acee Lindem \(acee\)'" , "'Randy Bush'" , "'Ondrej Zajicek'" References: <20150706203650.6815.83256.idtracker@ietfa.amsl.com> <20150706210159.GC13743@shrubbery.net> <027801d0b82f$60ad05b0$22071110$@ndzh.com> <20150710192227.GP13783@pfrc.org> <20150712200048.GA21130@varda.crfreenet.org> In-Reply-To: Date: Mon, 13 Jul 2015 19:52:33 -0400 Message-ID: <004d01d0bdc6$fced0370$f6c70a50$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGBfyn0a/XgdWqa5S7LQAUhGp5VDwJoZzRkAL6c2DwCuEQnVgI+2y9SAchfrQoCNhVKSwGg/0M8AixGYHyd+UAiAA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'idr wg list' Subject: Re: [Idr] I-D Action: draft-ietf-idr-bgp-extended-messages-10.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, 13 Jul 2015 23:52:40 -0000 Acee, Randy and Ondrej: I agree there is enough interest for an early allocation. I will kick this off this week. The process is that I write a shepherd's report (will do by Saturday pm), and then we talk to the responsible AD about approving this work. I think I can do my part by Sunday (7/19). And with everyone in the same place, maybe it can go really fast. Sue -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Acee Lindem (acee) Sent: Sunday, July 12, 2015 6:15 PM To: Randy Bush; Ondrej Zajicek Cc: idr wg list Subject: Re: [Idr] I-D Action: draft-ietf-idr-bgp-extended-messages-10.txt It seems that there is enough interest and implementation traction to request early IANA allocation for the capability (as described in RFC 7120 - https://www.rfc-editor.org/rfc/rfc7120.txt). Thanks, Acee On 7/12/15, 4:12 PM, "Idr on behalf of Randy Bush" wrote: >> I just implemented the draft-ietf-idr-bgp-extended-messages to BIRD. >> Currently it is a private patch, when the capability number will be >> assigned, it could be a part of the next official release. > >oh idr chairs, this is the second request for the capability. iff we >want this to progress, we either need to talk to the iana or agree on >some disgusting temp hack. your call, it's process. > >randy > >_______________________________________________ >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 Jul 13 17:34: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 CFDAF1A889A for ; Mon, 13 Jul 2015 17:34:00 -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 XL9C9LMB5Eu9 for ; Mon, 13 Jul 2015 17:34:00 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (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 CCBA41A8898 for ; Mon, 13 Jul 2015 17:33:59 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.34; From: "Susan Hares" To: "'idr wg list'" Date: Mon, 13 Jul 2015 20:33:56 -0400 Message-ID: <00b401d0bdcc$c572af70$50580e50$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B5_01D0BDAB.3E610F70" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdC9zIA6IsgS2qSWRSuk7TkZG2I4zw== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [Idr] Some delays in email this week 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, 14 Jul 2015 00:34:01 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00B5_01D0BDAB.3E610F70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit IDR WG: You may experience bursts of email this week. I have one of my PhD "must-do" exams occur this week on Wednesday and Thursday. I am in the processing of cramming for these exams, and then taking them. Sue ------=_NextPart_000_00B5_01D0BDAB.3E610F70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

IDR WG: =

 

You may experience bursts of email this week.  =

 

I have one of my PhD “must-do” exams occur = this week on Wednesday and Thursday.   I am in the processing = of cramming for these exams, and then taking them.  =

 

Sue

 

------=_NextPart_000_00B5_01D0BDAB.3E610F70-- From nobody Mon Jul 13 18:40: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 2C79B1A88C4 for ; Mon, 13 Jul 2015 18:40: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 ZhuQGK7Nd1uT for ; Mon, 13 Jul 2015 18:40:47 -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 273151A88BD for ; Mon, 13 Jul 2015 18:40:47 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1ZEpD7-000583-Kl; Tue, 14 Jul 2015 01:40:41 +0000 Date: Mon, 13 Jul 2015 18:40:40 -0700 Message-ID: From: Randy Bush To: "Susan Hares" In-Reply-To: <004b01d0bdc6$221d8a80$66589f80$@ndzh.com> References: <20150706203650.6815.83256.idtracker@ietfa.amsl.com> <20150706210159.GC13743@shrubbery.net> <027801d0b82f$60ad05b0$22071110$@ndzh.com> <20150710192227.GP13783@pfrc.org> <20150712200048.GA21130@varda.crfreenet.org> <004b01d0bdc6$221d8a80$66589f80$@ndzh.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' Subject: Re: [Idr] I-D Action: draft-ietf-idr-bgp-extended-messages-10.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, 14 Jul 2015 01:40:48 -0000 > My apologies for missing the early capability request. I will circle with > Alvaro Sunday at IETF to see if I can get this done quickly. sue: as jgs pointed out, capabilities have a fcfs temp allocation method. but if you want to go through the pain of getting an assignment, don't let me stop you. randy From nobody Mon Jul 13 19:17: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 B54761A894C for ; Mon, 13 Jul 2015 19:17:08 -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 Qkuk1rmIdfFS for ; Mon, 13 Jul 2015 19:17:07 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (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 76C121A8944 for ; Mon, 13 Jul 2015 19:17:07 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.34; From: "Susan Hares" To: "'Randy Bush'" References: <20150706203650.6815.83256.idtracker@ietfa.amsl.com> <20150706210159.GC13743@shrubbery.net> <027801d0b82f$60ad05b0$22071110$@ndzh.com> <20150710192227.GP13783@pfrc.org> <20150712200048.GA21130@varda.crfreenet.org> <004b01d0bdc6$221d8a80$66589f80$@ndzh.com> In-Reply-To: Date: Mon, 13 Jul 2015 22:17:06 -0400 Message-ID: <019401d0bddb$2e7bb0d0$8b731270$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGBfyn0a/XgdWqa5S7LQAUhGp5VDwJoZzRkAL6c2DwCuEQnVgI+2y9SAchfrQoCNhVKSwGg/0M8AgghTBICT1vSA53oDuww Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'idr wg list' Subject: Re: [Idr] I-D Action: draft-ietf-idr-bgp-extended-messages-10.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, 14 Jul 2015 02:17:08 -0000 Randy: Do you want a standard's early allocation or a FCFS allocation? It is your choice. The pain is not that bad since the Routing AD can approve it now. Sue -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Randy Bush Sent: Monday, July 13, 2015 9:41 PM To: Susan Hares Cc: 'idr wg list' Subject: Re: [Idr] I-D Action: draft-ietf-idr-bgp-extended-messages-10.txt > My apologies for missing the early capability request. I will circle > with Alvaro Sunday at IETF to see if I can get this done quickly. sue: as jgs pointed out, capabilities have a fcfs temp allocation method. but if you want to go through the pain of getting an assignment, don't let me stop you. randy _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From nobody Mon Jul 13 19:22: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 A866F1A896F for ; Mon, 13 Jul 2015 19:22:30 -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 WKWHFkNjn2WH for ; Mon, 13 Jul 2015 19:22:29 -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 C17911A896D for ; Mon, 13 Jul 2015 19:22:29 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1ZEprY-0005K3-8Z; Tue, 14 Jul 2015 02:22:28 +0000 Date: Mon, 13 Jul 2015 19:22:27 -0700 Message-ID: From: Randy Bush To: "Susan Hares" In-Reply-To: <019401d0bddb$2e7bb0d0$8b731270$@ndzh.com> References: <20150706203650.6815.83256.idtracker@ietfa.amsl.com> <20150706210159.GC13743@shrubbery.net> <027801d0b82f$60ad05b0$22071110$@ndzh.com> <20150710192227.GP13783@pfrc.org> <20150712200048.GA21130@varda.crfreenet.org> <004b01d0bdc6$221d8a80$66589f80$@ndzh.com> <019401d0bddb$2e7bb0d0$8b731270$@ndzh.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' Subject: Re: [Idr] I-D Action: draft-ietf-idr-bgp-extended-messages-10.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, 14 Jul 2015 02:22:30 -0000 sue > Do you want a standard's early allocation or a FCFS allocation? It is your > choice. The pain is not that bad since the Routing AD can approve it now. i personally do not care. the implementors and early deployers may so they do not get a compatibility issue should this become an rfc. randy From nobody Tue Jul 14 01:08: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 C8D8A1A904F for ; Tue, 14 Jul 2015 01:08:03 -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 aCLSXUwqSJob for ; Tue, 14 Jul 2015 01:08:02 -0700 (PDT) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::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 C8DEF1A9050 for ; Tue, 14 Jul 2015 01:08:01 -0700 (PDT) Received: by wgkl9 with SMTP id l9so2157447wgk.1 for ; Tue, 14 Jul 2015 01:08:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:message-id:date:user-agent:mime-version :content-type; bh=zm0VINNbQ8fqHjTQfhsmjGrHdC7EjecOo3aXjrXisYc=; b=Gw6MgKmp96S3lCDU1wp9yfe0IuNsyKePwFzPiKG4KIz+ro+5+IDe6o4DKlT6hFKvSu +YKiD22fNoTaOmtH7j3QUm5Y0AbaFidUSWZl8AhAVok0+B+2GRxdX1h0Qaa6VI/5omaB m4vAfmWb8BabTL+iSJfA0Z0hjgGaEOE2jOxU9KEHv72JtJ8E/YAZQSS16CsXBcYuOJ+u gJGDTo9a7xqaG0crB4UJVfd+843OutMtLIBtWzZ5wtAq2EPoy+Pv6+Pp6Li9I8D/nkHv V9LvOZTJwnUyK98i1I8VjMjzxO2+pbvZDcuwt7qjTRSwYMRUi3qpU+Q363ztY/nvEnfT pwPQ== X-Received: by 10.180.88.8 with SMTP id bc8mr2874455wib.19.1436861280265; Tue, 14 Jul 2015 01:08:00 -0700 (PDT) Received: from ISOC-A1FD58.local ([92.109.76.43]) by smtp.googlemail.com with ESMTPSA id pf4sm488950wjb.23.2015.07.14.01.07.58 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Jul 2015 01:07:59 -0700 (PDT) To: "idr@ietf.org List" From: Andrei Robachevsky X-Enigmail-Draft-Status: N1110 Message-ID: <55A4C35D.5060908@gmail.com> Date: Tue, 14 Jul 2015 10:07:57 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="k6QpbSsD2IW57F0fGFvsP7EvlmgMNL62F" Archived-At: Subject: Re: [Idr] 2 week adoption call for - draft-sriram-idr-route-leak-detection-mitigation-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: Tue, 14 Jul 2015 08:08:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --k6QpbSsD2IW57F0fGFvsP7EvlmgMNL62F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable [Apologies for missing the deadline] > IDR Working group: >=20 > =20 >=20 > This begins a 2 week adoption call for=20 >=20 > draft-sriram-idr-route-leak-detection-mitigation-00 >=20 > =20 I support adoption of this draft as a WG document. >=20 > a) Who will desire to read this informational draft now and in 1 y= ear from now>? > I suspect it will take some time to develop and implement a solution. > b) Is this informational draft=E2=80=99s description of route-leak= types and mitigated by the origin validation [RFC 6811] and BGPSEC path = validation =20 >=20 > [draft-ietf-sidr-bgpsec-protocol] are correct? >=20 Yes, there is a companion document in the GROW WG: draft-ietf-grow-route-leak-problem-definition, containing more detailed discussion of the definition of the problem. > c) It is necessary to solve the route-leak problems not covered b= y origin validation and BGPSEC path validation? >=20 Yes. > d) Do you think the solution suggested for the extension of BGPSEC= will fix these unsolved route-leak problems? > I hope. Regards, Andrei > =20 >=20 > Sue Hares and John Scudder =20 --k6QpbSsD2IW57F0fGFvsP7EvlmgMNL62F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - https://gpgtools.org iEYEARECAAYFAlWkw14ACgkQljz5tZmtij+XoQCfXt49oj5sEIAjNkcBLk+goMEp W9gAn1Ke3Yd1QC6hPewPtoAlzMohXBZd =9K+0 -----END PGP SIGNATURE----- --k6QpbSsD2IW57F0fGFvsP7EvlmgMNL62F-- From nobody Tue Jul 14 01:14: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 A0BCB1A9081 for ; Tue, 14 Jul 2015 01:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qHdBXGquh998 for ; Tue, 14 Jul 2015 01:14:37 -0700 (PDT) Received: from out-1.mail.exa.net.uk (out-1.mail.exa.net.uk [82.219.4.129]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E83671A906B for ; Tue, 14 Jul 2015 01:14:30 -0700 (PDT) Received: from smtp-2.mail.exa.net.uk (smtp-2.mail.exa.net.uk [82.219.5.2]) by out-1.mail.exa.net.uk (ExaSMTPD) with ESMTP id 432E21C00A1; Tue, 14 Jul 2015 09:14:28 +0100 (BST) Received: from smtp-2.mail.exa.net.uk (localhost [127.0.0.1]) by smtp-2.mail.exa.net.uk (ExaSMTPD) with ESMTP id 2F4474026C; Tue, 14 Jul 2015 09:14:28 +0100 (BST) Received: from [192.168.1.234] (ptr-34.212.219.82.rev.exa.net.uk [82.219.212.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: thomas@mangin.com) by smtp-2.mail.exa.net.uk (ExaSMTPD) with ESMTPSA; Tue, 14 Jul 2015 09:14:28 +0100 (BST) From: "Thomas Mangin" To: "John G. Scudder" Date: Tue, 14 Jul 2015 09:14:23 +0100 Message-ID: <4DA34703-7130-4612-AED6-58991575C7DF@exa-networks.co.uk> In-Reply-To: References: <20150702142348.4291.10005.idtracker@ietfa.amsl.com> <7C5305E5-69BF-4796-900A-726FFE4B2EEE@juniper.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_3B1B9F88-C932-4BD0-B1A1-B7E440454002_="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Mailer: MailMate (1.9.1r5084) X-Virus-Scanned: clamav-milter 0.98.7 at out-2-2.mail.exa.net.uk X-Virus-Status: Clean Archived-At: Cc: "idr@ietf. org" Subject: Re: [Idr] New Version Notification for draft-scudder-idr-capabilities-registry-change-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 08:14:39 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_3B1B9F88-C932-4BD0-B1A1-B7E440454002_= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello John, > I don't object to increasing it if there is WG consensus to do so. The = number 4 reflects a starting point and was chosen according to my own jud= gement that on one hand, there is a need for a BGP developer to have the = ability to have several features in development, but on the other hand, t= hose features should really not be released from the lab still using expe= rimental code points -- they should use an allocated code point. I appreciate that 4 is a sensible pick, but I would feel constrained by i= t. With two code already being used by ExaBGP current implementation (onc= e migrated), I would need to be careful in picking what I shall implement= next when I rather like to not have to worry about it. > I don't see the need for the distinction between these two. Fair enough. if no one else does think it is worth it, I am happy to drop= this distinction. >> I am also unsure if code 128 ( CISCO Route-Refresh ) and 131 ( CISCO m= ulti-session ) are still found in production networks ( AFAIK it was the = case a few years ago ), and if so, if this situation require formalising.= > > Even if they are no longer in use (one would hope they are now using 2 = or 68, respectively) they should probably be registered as "deprecated" f= or the reason Jeff mentioned. It seems we all agree. > In the end, the answer to your question is, do what is in your users' (= and the Internet's) best interests. I appreciate my enviable position and will change the codes in the new ra= nge for everyone=E2=80=99s benefit. And simply as ExaBGP users can change= one line in the code to restore compatibility. Thomas --=_MailMate_3B1B9F88-C932-4BD0-B1A1-B7E440454002_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlWkxN8ACgkQA/52wvuLgaFRVQCfYjgXiqQxykF0jbsjcB1MI9Sk OZ4AoKofnu0zA8dhLVVJQKb/PS0l/l7j =SjPR -----END PGP SIGNATURE----- --=_MailMate_3B1B9F88-C932-4BD0-B1A1-B7E440454002_=-- From nobody Tue Jul 14 01:29:16 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 BDB381A907B for ; Tue, 14 Jul 2015 01:29:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 a74dA9EvusmT for ; Tue, 14 Jul 2015 01:29:12 -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 72B571A9079 for ; Tue, 14 Jul 2015 01:29:11 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BVD50850; Tue, 14 Jul 2015 08:29:09 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 14 Jul 2015 09:29:07 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.69]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Tue, 14 Jul 2015 16:28:59 +0800 From: "Dongjie (Jimmy)" To: "bruno.decraene@orange.com" , idr wg list Thread-Topic: draft-decraene-idr-next-hop-capability-01.txt Thread-Index: AdC4JKDYgB3/Q9Q9R2OEO/XZ5rMOTwF5qxMQ Date: Tue, 14 Jul 2015 08:28:58 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C92774298311@nkgeml512-mbx.china.huawei.com> References: <29278_1436213631_559AE17F_29278_100_1_53C29892C857584299CBF5D05346208A0F5DF256@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: <29278_1436213631_559AE17F_29278_100_1_53C29892C857584299CBF5D05346208A0F5DF256@OPEXCLILM21.corporate.adroot.infra.ftgroup> 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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Idr] draft-decraene-idr-next-hop-capability-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 08:29:14 -0000 SGkgQnJ1bm8sIA0KDQpJJ3ZlIHJlYWQgdGhpcyBkcmFmdCBhbmQgaGVyZSBhcmUgc29tZSBjb21t ZW50czoNCg0Kc2VjdGlvbiAxLiANCg0KQ3VycmVudGx5IGl0IHNheXMgIiBUaGlzIGF0dHJpYnV0 ZSBpcyBkZWxldGVkIHdoZW4gdGhlIEJHUCBOZXh0IEhvcCBpcyBjaGFuZ2VkLiIgDQoNCkFjY29y ZGluZyB0byB0aGUgc3BlY2lmaWNhdGlvbiBpbiBzZWN0aW9uIDMsIHRvIG1ha2UgaXQgY29tcGxl dGUgaXQgaXMgYmV0dGVyIHRvIGFkZCAiQSBuZXcgTmV4dC1Ib3AgQ2FwYWJpbGl0aWVzIGF0dHJp YnV0ZSBNQVkgYmUgYWRkZWQgZWFjaCB0aW1lIHRoZSBCR1AgTmV4dCBIb3AgaXMgY2hhbmdlZCB0 byByZWZsZWN0IHRoZSBjYXBhYmlsaXRpZXMgb2YgdGhlIG5ldyBOZXh0IEhvcC4iDQoNCnNlY3Rp b24gNi4gDQoNCkl0IHNheXMgIkEgQkdQIHNwZWFrZXIgUyB0aGF0IHNlbmRzIGFuIFVQREFURSB3 aXRoIHRoZSBCR1AgTmV4dC1Ib3AgTkggTUFZIGluY2x1ZGUgdGhlIEVudHJvcHkgTGFiZWwgTmV4 dC1Ib3AgQ2FwYWJpbGl0eSBvbmx5IGlmIC4uLiINCg0KQWNjb3JkaW5nIHRvIHRoZSBjb25kaXRp b25zIG9mIGluY2x1ZGluZyB0aGUgZW50cm9weSBsYWJlbCBuZXh0IGhvcCBjYXBhYmlsaXR5LCBp dCBhY3R1YWxseSByZWZsZWN0cyB0aGUgZW50cm9weSBsYWJlbCBjYXBhYmlsaXR5IG9mIHRoZSB3 aG9sZSBkb3duc3RyZWFtIHBhdGguIFRvIG1ha2UgdGhpcyB3b3JrLCBpdCB3b3VsZCByZXF1aXJl IHRoYXQgZWFjaCBob3AgYWxvbmcgdGhlIHBhdGggaW5jbHVkZSB0aGUgRW50cm9weSBMYWJlbCBO ZXh0LUhvcCBDYXBhYmlsaXR5IGluIGl0cyB1cGRhdGUgaWYgaXQgbWVldHMgdGhlc2UgY29uZGl0 aW9ucy4gVGh1cyBJJ2Qgc3VnZ2VzdCB0byByZXBsYWNlIHRoZSAiTUFZIiBoZXJlIHdpdGggIk1V U1QiIG9yICJTSE9VTEQiLg0KDQpzZWN0aW9uIDYuMQ0KDQpUaGUgInJlYWRhYmxlIGxhYmVsIGRl cHRoIiBjYW4gYmUgcmVnYXJkZWQgYXMgYW5vdGhlciBmb3J3YXJkaW5nIHBsYW5lIGZlYXR1cmUs IHdoaWNoIG1heSBiZSB1c2VkIGluZGVwZW5kZW50IG9mIHRoZSBlbnRyb3B5IGxhYmVsIGNhcGFi aWxpdHkuIFRodXMgSSdkIHN1Z2dlc3QgdG8gYWxsb2NhdGUgYSBkZWRpY2F0ZWQgTmV4dC1ob3Ag Y2FwYWJpbGl0eSBjb2RlIGZvciBpdC4NCg0KQXMgZm9yIHRoZSBuYW1lIG9mIHRoaXMgbmV3IGF0 dHJpYnV0ZSwgSSBhZ3JlZSBpdCBpcyBOZXh0LUhvcCBBTkQgcGF0aCBzcGVjaWZpYy4gUGVyc29u YWxseSBJIHRoaW5rICJOZXh0LUhvcCBjYXBhYmlsaXR5IiBpcyBPSywgc2luY2UgaXQgaXMgY2Fs bGVkIGEgQkdQIFBhdGggQXR0cmlidXRlLCB3aGljaCBpbXBsaWVzIHRoYXQgaXQgY291bGQgYmUg cGF0aC1zcGVjaWZpYzopLg0KDQpCZXN0IHJlZ2FyZHMsDQpKaWUNCg0KPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBJZHIgW21haWx0bzppZHItYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mDQo+IGJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb20NCj4gU2VudDogVHVlc2Rh eSwgSnVseSAwNywgMjAxNSA0OjE0IEFNDQo+IFRvOiBpZHIgd2cgbGlzdA0KPiBTdWJqZWN0OiBb SWRyXSBkcmFmdC1kZWNyYWVuZS1pZHItbmV4dC1ob3AtY2FwYWJpbGl0eS0wMS50eHQNCj4gDQo+ IEhpIGFsbCwNCj4gDQo+IFBsZWFzZSBmaW5kIGJlbG93IGFuIHVwZGF0ZWQgdmVyc2lvbiBvZiB0 aGUgZHJhZnQgcHJlc2VudGVkIGluIERhbGxhcy4NCj4gDQo+IE1haW4gY2hhbmdlcyBhcmUgdGhl IGZvbGxvd2luZzoNCj4gLSBOZXcgY28tYXV0aG9yczogS2lyZWV0aSBLb21wZWxsYSwgIFdpbSBI ZW5kZXJpY2t4DQo+IC0gU2xpZ2h0bHkgaW1wcm92ZWQgImVycm9yIGhhbmRsaW5nIiBzZWN0aW9u IG9mIHRoZSBCR1AgYXR0cmlidXRlDQo+IC0gTmV3IHNlY3Rpb24gZGVmaW5pbmcgdGhlICJlcnJv ciBoYW5kbGluZyIgb2YgdGhlIE1QTFMgRW50cm9weSBMYWJlbCBCR1ANCj4gTmV4dC1Ib3AgQ2Fw YWJpbGl0eS4NCj4gLSBTb21lIHJlLXJld29yZGluZyBvZiB0aGUgIkVudHJvcHkgTGFiZWwgTmV4 dC1Ib3AgQ2FwYWJpbGl0eSIgc2VjdGlvbg0KPiAJLSAtMDAgd2FzIG1vc3RseSBhIGNvcHkgcGFz dCBmcm9tIFJGQyA2NzkwICh3aGljaCBkZWZpbmVzIHRoZSBNUExTDQo+IEVudHJvcHkgTGFiZWwg JiB0aGUgb3JpZ2luYWwgYW5kIG5vdyBkZXByZWNhdGVkIEJHUCBhdHRyaWJ1dGUpDQo+IAktIC0w MSBpcyBleHBlY3RlZCB0byBiZSBtb3JlIHByZWNpc2UgdGhhbmtzIHRvIGNvbW1lbnRzIGZyb20g RXJpYyBSb3Nlbg0KPiAobWFueSB0aGFua3MpDQo+IC0gTmV3IHNlY3Rpb24gNCAiQkdQIE5leHQt SG9wIENhcGFiaWxpdHkgQ29kZSBPcGVyYXRpb24iDQo+IAktIE5vdGhpbmcgb3V0c3RhbmRpbmcs IGJ1dCBiZXR0ZXIgd2hlbiBleHBsaWNpdGx5IHN0YXRlZA0KPiAtIEFkZGl0aW9uIG9mIHRoZSBv cHRpb25hbCBhYmlsaXR5IHRvIGFkdmVydGlzZSB0aGUgIlJlYWRhYmxlIExhYmVsIERlcHRoIiBv ZiB0aGUNCj4gTFNQKHMpIGFkdmVydGlzZWQgaW4gdGhlIE5MUkkNCj4gCS0gU3RpbGwgbmVlZCBz b21lIHBvbGlzaGluZw0KPiAtIEltcHJvdmVkIHdvcmRpbmcsIHNvbWUgdHlwbyBjb3JyZWN0ZWQN Cj4gDQo+IA0KPiBEaWZmOg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJh ZnQtZGVjcmFlbmUtaWRyLW5leHQtaG9wLWNhcGFiaWxpdHktMDENCj4gDQo+IA0KPiBDb21tZW50 cyB3ZWxjb21lZC4NCj4gDQo+IEluIHBhcnRpY3VsYXIsIHRoZSBuYW1lIG9mIHRoZSBCR1AgQXR0 cmlidXRlIGNvdWxkIGhhdmUgYSBiZXR0ZXIgbmFtZSAodG8gYmUNCj4gcHJvcG9zZWQpOg0KPiAJ LSBDdXJyZW50bHkgY2FsbGVkIE5leHQtSG9wIENhcGFiaWxpdHkNCj4gCS0gQnV0IHRoZSBjYXBh YmlsaXR5IGlzIG5vdCBvbmx5IE5leHQtSG9wIHNwZWNpZmljIGJ1dCBtb3JlIHByZWNpc2VseQ0K PiBOZXh0LUhvcCBBTkQgcGF0aCBzcGVjaWZpYy4gSW4gcGFydGljdWxhciwgZm9yIGRpZmZlcmVu dCBVUERBVEUgaGF2aW5nIHRoZSBzYW1lDQo+IE5leHQtSG9wLCB0aGUgY2FwYWJpbGl0eSBtYXkg YmUgZGlmZmVyZW50Lg0KPiAJLSBJ4oCZZCB3ZWxjb21lIGFueSBzdWdnZXN0aW9uIG9mIG5hbWUu DQo+IAkJLSBXZSBwcm9iYWJseSB3YW50IHRvIGtlZXAgdGhlIHRlcm0gIk5leHQtSG9wIiBzb21l d2hlcmUgYXMgdGhpcyBpcw0KPiBhIGtleSBwcm9wZXJ0eSBvZiB0aGUgQkdQIGF0dHJpYnV0ZSB3 aGljaCBpcyByZW1vdmVkIHdoZW4gdGhlIE5leHQtSG9wIGlzDQo+IGNoYW5nZWQuDQo+IA0KPiAN Cj4gVGhhbmtzLA0KPiBSZWdhcmRzLA0KPiBCcnVubw0KPiANCj4gUFM6IGxvbmcgKGJvcmluZykg ZW1haWwsIGJ1dCB5b3Ugc2F2ZWQgYSAoYm9yaW5nKSBwcmVzZW50YXRpb24gaW4gUHJhZ3Vlcw0K PiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogaW50ZXJuZXQtZHJhZnRz QGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0KPiBTZW50OiBNb25k YXksIEp1bHkgMDYsIDIwMTUgOTo0NiBQTQ0KPiBUbzogV2ltIEhlbmRlcmlja3g7IEtpcmVldGkg S29tcGVsbGE7IEtpcmVldGkgS29tcGVsbGE7IERFQ1JBRU5FIEJydW5vDQo+IElNVC9PTE47IFdp bSBIZW5kZXJpY2t4OyBERUNSQUVORSBCcnVubyBJTVQvT0xODQo+IFN1YmplY3Q6IE5ldyBWZXJz aW9uIE5vdGlmaWNhdGlvbiBmb3INCj4gZHJhZnQtZGVjcmFlbmUtaWRyLW5leHQtaG9wLWNhcGFi aWxpdHktMDEudHh0DQo+IA0KPiANCj4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWRlY3Jh ZW5lLWlkci1uZXh0LWhvcC1jYXBhYmlsaXR5LTAxLnR4dA0KPiBoYXMgYmVlbiBzdWNjZXNzZnVs bHkgc3VibWl0dGVkIGJ5IEJydW5vIERlY3JhZW5lIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYNCj4g cmVwb3NpdG9yeS4NCj4gDQo+IE5hbWU6CQlkcmFmdC1kZWNyYWVuZS1pZHItbmV4dC1ob3AtY2Fw YWJpbGl0eQ0KPiBSZXZpc2lvbjoJMDENCj4gVGl0bGU6CQlCR1AgTmV4dC1Ib3AgQ2FwYWJpbGl0 aWVzDQo+IERvY3VtZW50IGRhdGU6CTIwMTUtMDctMDYNCj4gR3JvdXA6CQlJbmRpdmlkdWFsIFN1 Ym1pc3Npb24NCj4gUGFnZXM6CQkxMA0KPiBVUkw6DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL2lu dGVybmV0LWRyYWZ0cy9kcmFmdC1kZWNyYWVuZS1pZHItbmV4dC1ob3AtY2FwYWJpbGl0eS0wMQ0K PiAudHh0DQo+IFN0YXR1czoNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtZGVjcmFlbmUtaWRyLW5leHQtaG9wLWNhcGFiaWxpdHkvDQo+IEh0bWxpemVkOg0KPiBodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZGVjcmFlbmUtaWRyLW5leHQtaG9wLWNhcGFi aWxpdHktMDENCj4gRGlmZjoNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRy YWZ0LWRlY3JhZW5lLWlkci1uZXh0LWhvcC1jYXBhYmlsaXR5LTAxDQo+IA0KPiBBYnN0cmFjdDoN Cj4gICAgUkZDIDU0OTIgZGVmaW5lcyBjYXBhYmlsaXRpZXMgYWR2ZXJ0aXNlbWVudCBmb3IgdGhl IEJHUCBwZWVyLiAgSW4NCj4gICAgYWRkaXRpb24sIGl0IGlzIHVzZWZ1bCB0byBrbm93IHRoZSBj YXBhYmlsaXRpZXMgb2YgdGhlIEJHUCBOZXh0LUhvcCwNCj4gICAgaW4gcGFydGljdWxhciBmb3Ig Zm9yd2FyZGluZyBwbGFuZSBmZWF0dXJlcy4gIFJGQyA1NDkyIGlzIG5vdA0KPiAgICBhcHBsaWNh YmxlIGJlY2F1c2UgdGhlIEJHUCBwZWVyIG1heSBiZSBkaWZmZXJlbnQgZnJvbSB0aGUgQkdQIE5l eHQtDQo+ICAgIEhvcCwgaW4gcGFydGljdWxhciB3aGVuIEJHUCBSb3V0ZSBSZWZsZWN0aW9uIGlz IHVzZWQuICBUaGlzIGRvY3VtZW50DQo+ICAgIGRlZmluZXMgYSBtZWNoYW5pc20gdG8gYWR2ZXJ0 aXNlIHN1Y2ggQkdQIE5leHQgSG9wIENhcGFiaWxpdGllcy4NCj4gDQo+ICAgIFRoaXMgZG9jdW1l bnQgZGVmaW5lcyBhIG5ldyBCR1Agbm9uLXRyYW5zaXRpdmUgYXR0cmlidXRlIHRvIGNhcnJ5DQo+ ICAgIE5leHQtSG9wIENhcGFiaWxpdGllcy4gIFRoaXMgYXR0cmlidXRlIGlzIGRlbGV0ZWQgd2hl biB0aGUgQkdQIE5leHQNCj4gICAgSG9wIGlzIGNoYW5nZWQuDQo+IA0KPiAgICBUaGlzIGRvY3Vt ZW50IGFsc28gZGVmaW5lcyBhIE5leHQtSG9wIGNhcGFiaWxpdHkgdG8gYWR2ZXJ0aXNlIHRoZQ0K PiAgICBhYmlsaXR5IHRvIGhhbmRsZSB0aGUgRW50cm9weSBMYWJlbCBkZWZpbmVkIGluIFJGQyA2 NzkwLg0KPiANCj4gDQo+IA0KPiANCj4gDQo+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2Ug YSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCj4gdW50aWwg dGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRm Lm9yZy4NCj4gDQo+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQo+IA0KPiANCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gDQo+IENlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIg ZGVzIGluZm9ybWF0aW9ucw0KPiBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5l IGRvaXZlbnQgZG9uYw0KPiBwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBz YW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UNCj4gbWVzc2FnZSBwYXIgZXJy ZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcg0KPiBhIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWly ZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMNCj4gZWxlY3Ryb25p cXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLA0KPiBPcmFuZ2UgZGVjbGluZSB0 b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBv dQ0KPiBmYWxzaWZpZS4gTWVyY2kuDQo+IA0KPiBUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2ht ZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZA0KPiBpbmZvcm1hdGlv biB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Ow0KPiB0aGV5IHNob3VsZCBub3QgYmUgZGlz dHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCj4gSWYgeW91 IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2Vu ZGVyIGFuZCBkZWxldGUgdGhpcw0KPiBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQo+IEFz IGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2Vz IHRoYXQgaGF2ZSBiZWVuDQo+IG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NCj4gVGhh bmsgeW91Lg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gSWRyIG1haWxpbmcgbGlzdA0KPiBJZHJAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZHINCg== From nobody Tue Jul 14 01:43: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 715D51A90AD; Tue, 14 Jul 2015 01:43:13 -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 3wBYBBOCbHJq; Tue, 14 Jul 2015 01:43:11 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F6DD1A909A; Tue, 14 Jul 2015 01:43:11 -0700 (PDT) Received: by wgmn9 with SMTP id n9so2898513wgm.0; Tue, 14 Jul 2015 01:43:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type; bh=4LFAXgYSjdZ+eVViHky0QFdjlooTOlqjIkjEbhrbAf8=; b=Frt4DO3eAgg7C4ll1V5ewfO9klvJbPvDP9X8cVq9pJOgten5Sj0tCCLUk3WFgsihxg aAOaWJVdb7RMYk9WnpXfBx2AMGqqR8cY5qUu4Cq73XxakW5TgPcXRB/Qx3gtqJRw6kVz QeVCB/3AOnWCttMLGLyuKHjMAbMDebx3jFP1AbGi9VwRon30ZW+p1KBYjlgcCX+dQ9wU 8D2Dm8QUWRXCrCwmiyTPkViA9UAwGFAgEY7HO56iSeUx33GBwfbnJfpQtLtj+uz3Ae1Q qRH1mObNMv5hpqGyyNrjmdHTyRrLiCFY5kdCWJOVYsHCXHBpPJFXh8EzVvJroFwxiX4k kBdA== X-Received: by 10.194.205.101 with SMTP id lf5mr81050135wjc.37.1436863389851; Tue, 14 Jul 2015 01:43:09 -0700 (PDT) Received: from ISOC-A1FD58.local ([92.109.76.43]) by smtp.googlemail.com with ESMTPSA id gw7sm19422423wib.15.2015.07.14.01.43.08 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Jul 2015 01:43:09 -0700 (PDT) To: "Sriram, Kotikalapudi" References: <005901d0b283$ea07bd20$be173760$@ndzh.com> From: Andrei Robachevsky X-Enigmail-Draft-Status: N1110 Message-ID: <55A4CB9B.2050207@gmail.com> Date: Tue, 14 Jul 2015 10:43:07 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Tr7L8mupREAFb7Qt6BRiRwwhU5o0R3EEr" Archived-At: Cc: idr wg list , "sidr wg list \(sidr@ietf.org\)" Subject: [Idr] draft-sriram-idr-route-leak-detection-mitigation: difference between a peer and a customer 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, 14 Jul 2015 08:43:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Tr7L8mupREAFb7Qt6BRiRwwhU5o0R3EEr Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, Sriram, could you please elaborate what the difference is between the route-leak detection (and action) for customers and peers. It seems to me that sections 3.2.1. and 3.2.2. propose the same algorithm (modulo the BGP neighbor is a customer or a peer). The difference in the "possible actions" (3.3.) is not clear to me either. Finally, what is the proposed action when an RLP-marked update is received from an upstream? Thanks, Andrei --Tr7L8mupREAFb7Qt6BRiRwwhU5o0R3EEr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - https://gpgtools.org iEYEARECAAYFAlWky5wACgkQljz5tZmtij8o9ACg5GNN3ZG0Efa28nJPCxsipsay EpEAmQF5bSon1aF04k5HHHy7u1l+iZKM =oZZy -----END PGP SIGNATURE----- --Tr7L8mupREAFb7Qt6BRiRwwhU5o0R3EEr-- From nobody Tue Jul 14 02:52: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 74F2D1A9134 for ; Tue, 14 Jul 2015 02:52:51 -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 Y4kvbN6BNmF8 for ; Tue, 14 Jul 2015 02:52:50 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 069B51A00DD for ; Tue, 14 Jul 2015 02:52:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1332; q=dns/txt; s=iport; t=1436867569; x=1438077169; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=YjtsypMWnf2J/yTM+9oHNgkznJA3+iVLsuR6KvCqN2M=; b=TPqDTigZGGnLogSFcT9vR5Cew1IRR6p4kOBR/Gi3MIzbHxN+7IVwXScz HnbOzXum/bucVt6i5wO5ILz3opFkoXNCfSubbS0bIW7ZYVzVEMWj5NVXr 0aqPaLOdB4K4QCBxy9HfHju18F/2Q7aZGvo9s4TR/sRy2ViF2oJZiisip g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BJAwBm26RV/4gNJK1bgxNUaQaDHrgqCYFqCoV3AhyBKDgUAQEBAQEBAYEKhCQBAQQBAQEgEToLEAIBCBoCJgICAiULFRACBAENBYguDbYllkIBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIEiiiqEUzMHgmiBQwEElDIBjAWBQJNPg18mg3tvgUeBBAEBAQ X-IronPort-AV: E=Sophos;i="5.15,470,1432598400"; d="scan'208";a="11495241" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-5.cisco.com with ESMTP; 14 Jul 2015 09:52:49 +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 t6E9qnKK023775 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 14 Jul 2015 09:52:49 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.208]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Tue, 14 Jul 2015 04:52:49 -0500 From: "Acee Lindem (acee)" To: Randy Bush , Susan Hares Thread-Topic: [Idr] I-D Action: draft-ietf-idr-bgp-extended-messages-10.txt Thread-Index: AQHQuCuFeXhtQ0gVtkOfuKEnBEqrtp3PPEKAgAAFN4CAAADBgIAGLMUAgAABN4CAAt20WIACIdMAgAAf6wCAAAouAIAAAX+AgAA6ygA= Date: Tue, 14 Jul 2015 09:52:48 +0000 Message-ID: References: <20150706203650.6815.83256.idtracker@ietfa.amsl.com> <20150706210159.GC13743@shrubbery.net> <027801d0b82f$60ad05b0$22071110$@ndzh.com> <20150710192227.GP13783@pfrc.org> <20150712200048.GA21130@varda.crfreenet.org> <004b01d0bdc6$221d8a80$66589f80$@ndzh.com> <019401d0bddb$2e7bb0d0$8b731270$@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.116.152.198] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: 'idr wg list' Subject: Re: [Idr] I-D Action: draft-ietf-idr-bgp-extended-messages-10.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, 14 Jul 2015 09:52:51 -0000 SGkgUmFuZHksIFN1ZSwgDQpJZiBhbGwgb25lIHdhbnRzIHRvIGRvIGlzIGV4cGVyaW1lbnRhdGlv biBmb3IgaW50ZXJvcGVyYWJpbGl0eSwgdGhlbiBGQ0ZTDQppcyBmaW5lLiBIb3dldmVyLCBpZiB0 aGUgaW1wbGVtZW50YXRpb24gaXMgdG8gYmUgc3VwcG9ydGVkLCBpdCBpcyBhIHJlYWwNCnBhaW4g Zm9yIHRoZSBjb2RlIHBvaW50IHRvIGNoYW5nZS4gSeKAmWQgc2F5IHRoYXQgZWFybHkgYWxsb2Nh dGlvbiBpcyBhbHdheXMNCmEgZ29vZCBpZGVhIGZvciBkcmFmdHMgdGhhdCB0aGUgV0cgZXhwZWN0 cyB0byBiZSBzdWJtaXR0ZWQgdG8gdGhlIElFU0cgZm9yDQpwdWJsaWNhdGlvbiB3aXRoaW4gdGhl IDEgeWVhciBJQU5BIGFsbG9jYXRpb24gcGVyaW9kLg0KVGhhbmtzLA0KQWNlZQ0KDQoNCk9uIDcv MTMvMTUsIDEwOjIyIFBNLCAiSWRyIG9uIGJlaGFsZiBvZiBSYW5keSBCdXNoIiA8aWRyLWJvdW5j ZXNAaWV0Zi5vcmcNCm9uIGJlaGFsZiBvZiByYW5keUBwc2cuY29tPiB3cm90ZToNCg0KPnN1ZQ0K Pg0KPj4gRG8geW91IHdhbnQgYSBzdGFuZGFyZCdzIGVhcmx5IGFsbG9jYXRpb24gb3IgYSBGQ0ZT IGFsbG9jYXRpb24/ICBJdCBpcw0KPj55b3VyDQo+PiBjaG9pY2UuICBUaGUgcGFpbiBpcyBub3Qg dGhhdCBiYWQgc2luY2UgdGhlIFJvdXRpbmcgQUQgY2FuIGFwcHJvdmUgaXQNCj4+bm93LiANCj4N Cj5pIHBlcnNvbmFsbHkgZG8gbm90IGNhcmUuICB0aGUgaW1wbGVtZW50b3JzIGFuZCBlYXJseSBk ZXBsb3llcnMgbWF5IHNvDQo+dGhleSBkbyBub3QgZ2V0IGEgY29tcGF0aWJpbGl0eSBpc3N1ZSBz aG91bGQgdGhpcyBiZWNvbWUgYW4gcmZjLg0KPg0KPnJhbmR5IA0KPg0KPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+SWRyIG1haWxpbmcgbGlzdA0KPklk ckBpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRyDQoN Cg== From nobody Tue Jul 14 07:58: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 56F191ACE42 for ; Tue, 14 Jul 2015 07:58:41 -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 fG9pWmMQ1_rW for ; Tue, 14 Jul 2015 07:58:40 -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 C3F881ACE08 for ; Tue, 14 Jul 2015 07:58:39 -0700 (PDT) Authentication-Results: exa-networks.co.uk; dkim=none (message not signed) header.d=none; Received: from kblanc-sslvpn-nc.jnpr.net (66.129.241.11) by BLUPR0501MB1826.namprd05.prod.outlook.com (10.163.121.149) with Microsoft SMTP Server (TLS) id 15.1.213.14; Tue, 14 Jul 2015 14:58:37 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: John Scudder In-Reply-To: <4DA34703-7130-4612-AED6-58991575C7DF@exa-networks.co.uk> Date: Tue, 14 Jul 2015 10:58:29 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <9842C3C0-287E-4C2A-BCA7-1D07C6135240@juniper.net> References: <20150702142348.4291.10005.idtracker@ietfa.amsl.com> <7C5305E5-69BF-4796-900A-726FFE4B2EEE@juniper.net> <4DA34703-7130-4612-AED6-58991575C7DF@exa-networks.co.uk> To: Thomas Mangin X-Mailer: Apple Mail (2.2102) X-Originating-IP: [66.129.241.11] X-ClientProxiedBy: SN1PR05CA0007.namprd05.prod.outlook.com (25.163.68.145) To BLUPR0501MB1826.namprd05.prod.outlook.com (25.163.121.149) X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB1826; 2:Jz+41kB+KLm6fkJVJeGACvkv5eipIxBEq9MQi61Bl3SaDxfHwk4bhOlM+vmPiVbO; 3:eW+eoDuYDDDgPLsSskaNIu+9mrm4l8tcoR5+BNONQDp+p6bylGheeLtexJ5tt0v4X9FTXpHqCTUlVV5iR+U80F/vUFsvAvegw0nDHDCFK06z9Ouj9WGkM4BI1TIpLTIp7uPK3gJnuwwqLNuG2F8UMA==; 25:6QL+QJH0E2/zE6PI3YVoQavNHkyik+K0gqNiiAjMXYgrTVhQvSOlUdc07dmiuLQJ4ZlxUyQTrVzSGxgJSuEsIKG6JtNmIP4X8jaUi/Qs54ONpjdqmXSnDYoYN9+rxWDrEcK6M6ZL4U1COK4M9ytmImQBGqRUfaZikafJFChqbFk+cQf++F3d/423Vz8K0/uQdPQMACbQWRQ8/wt9oVH3b/f1hbqODwE9h4goth2jIyxajSLaFwbWvdk1UCQH2Xa+ X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR0501MB1826; X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB1826; 20:Xt5kY4zXpqE5hjbgFPj8MviVt54KEKvSRFFD1PADSxjqikFi1Y6FuO4Q5GLXm1sM36u1ma6tJtgvpIOwQdEHSS1d50NSssh6iK+O0LWgtUzu95wRRt4ZqQCiPSrQRKufhLtnLnsmlR0nuGxGQqEcpKhLgZN5iW4Wehyn6i6TDblj2crHUXBN/xAqTtu7vmRRhCmrFvRwyiqFVEzc0amwKrpmcJfjwS18NgY6cYfT6ZAD/mvgQxMm3I6hSzw/mzcbDIt5a31UkquHbf5qoHYSyQCADNrSzkbuamulKstub1evv7iJNyDKI0BdEXMN4zy7g0/TfxLqtkEX67N3Zr77CEKILrBnRZhsjDnlRdxE/CN5Yu+ARBTkruvwzNz0fKLOksABVGpAsRvWv1g+J/hyMxAABYxCID5/N+pV17kexB2IcvB5fl7XZjbfZHOumfclOtm8LigyXjtWEZBgNjiiDtKDodLauuX/rU3OKDt5z21Mx1Jo6AEEQGVne7PT6PhS; 4:vG+XHkikkeU4xuAC30dqGFfCCSdQn5SeBSb/SIFOwHvwe6no0H0KFxH9tuMFSxOdojE/yDbw9gBhnJ1LmPcRuVFxT3/DwktGT8bqfs64QzNUvgsRuET7fP8HI/S9RpxB15DMqud6lDlgACg2DXrwTrqrlRVrdAd/dzPLM1Lg7K2JXJuW7Rq95I/zH00NQy6CFS7cYRfEYWr3yTslQMuuadIb2sFjh0JBxkZOZ+YWruY6WNvzxWk3jEjteDprJ6UGKjCTpRv9ayWilXByCG+9L/f+S5pifgOg85WjmrS7sxw= BLUPR0501MB1826: X-MS-Exchange-Organization-RulesExecuted 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:BLUPR0501MB1826; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB1826; X-Forefront-PRVS: 0637FCE711 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(377454003)(83716003)(53416004)(76176999)(77096005)(82746002)(46406003)(93886004)(42186005)(36756003)(50466002)(87976001)(2950100001)(23726002)(97756001)(86362001)(230783001)(77156002)(62966003)(40100003)(122386002)(189998001)(66066001)(33656002)(46102003)(50986999)(92566002)(57306001)(5001960100002)(110136002)(50226001)(47776003)(19580405001)(19580395003)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB1826; H:kblanc-sslvpn-nc.jnpr.net; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BLUPR0501MB1826; 23:xttsrCBIiX5NeEaTZjS/uCUJc+SZ/y/ze4R1TAQ?= =?us-ascii?Q?x0EerOskbBqsXCQxvn1vo2OE7yvGHqcmMDEUMEEgVlmBeBV+aTLH2Wstxja0?= =?us-ascii?Q?vlGPGiw5TlwpfpDi7OfjthmNFUBWTnA4LCjxBe3SVSth9Lb5tfpJ7t1142X2?= =?us-ascii?Q?ZWjTW+HQRfiX12R0ij8lf1TIaic/nZox0OFCVjzTqY9e9psJ9cFYgtUOv33S?= =?us-ascii?Q?6GBjVQGehTzJ4e0+LwDM59mqeUTB6s/DOqdyFBugtCTr1itZIwU9MYgaNqhp?= =?us-ascii?Q?Z6EyUzMuoFYQKzqoAlAkT31YcMWH9G+W9yrNqTwSvYBprXTUMrZOWW21dRA0?= =?us-ascii?Q?Q3ByI0i82WHl0LODjh8YRwT/hlHUBAEV1iVcqm7V2WbMZ5Mb71NoSIfoSUwy?= =?us-ascii?Q?+ioR6tvDgqkdZ4xn+s5toVsBBej9NhuwKjJzcqwfCZeFMfjSmDvSgMUkh3lt?= =?us-ascii?Q?dV/4nwvPWDwcEAdPoL0SxV/AveU5EXhQXn5y+yYR5g+Bl2hw6xbJeXpaHwJE?= =?us-ascii?Q?Tl8oow8GoG1WD1cGDd+g5kNKUsZYkGR+byBJDOBEhdYcoR56y0jzTiQgifrf?= =?us-ascii?Q?wD7IWQyG27JxZwuZtqzNYSEd/M+Fq5z8GPxQQO9C/KPHmb3IPNurZMfWOcOV?= =?us-ascii?Q?jaBM91e1qpvwH4gYu+S7APHm83ipRFD2svOoEeEpcL2uxMiV1Gl58piRg6+Q?= =?us-ascii?Q?bkT3ucjUYkgA1sC0CP01xBdeEGTDgNyq2R4dF5zodNp7ov9wKblgPfyratm9?= =?us-ascii?Q?WPVXpRlytsRIdMjs0xBKWi2x2pJ685zOIJTwxOOrrHSelINcbuTOVdoqKpqR?= =?us-ascii?Q?OPB+vkTmDngSEgmLc0EQLxycI3J8neLRLTiNZ4EeIgoxTlUs5li+4SFuIts6?= =?us-ascii?Q?seKkYQiwHSgJ/imMsYdPmuTY7Nite6EkM4v5y1jMo8Mh5gyIkPKurwPO0Vku?= =?us-ascii?Q?0P9PeOWzNU/6jKxhhmWN8r/peJ8f5oDd6QZvxgA3+rRGMV9QgMB3gUosnnMN?= =?us-ascii?Q?n7QY=3D?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB1826; 5:cOb/QWlL+eB8xTo2iWV2HUbtSsqFao8SoadqPxI0QiNvD+mwVXYk7TIDQHQrQ4GE3UgnsH4kRKvtJd/hVDDFtQ29qg2BYiGkfrqNBc+32C6wHamJqSuYyb97u0Ijepu9PE2Z+Kt53oHK6g1LPt1bbQ==; 24:lbTnuzgIwDFV4LbIq9w1Ue6PUKxw1ucW/czbPUUeFtIlHdIfohWr4ICdzKeKOwwNN2mKvNdJEVUdvx5MPa2862b4dJvf6DC60EXUyRq758w=; 20:oz37rxsgxdxmhALoJksndKYVLi/C0U09wpBCf9unuKzwZKir57H4Y8uJq62hsw5s/fqWuZOgdPkDkufh4Q0rNA== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Jul 2015 14:58:37.4057 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB1826 Archived-At: Cc: "idr@ietf. org" Subject: Re: [Idr] New Version Notification for draft-scudder-idr-capabilities-registry-change-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 14:58:41 -0000 On Jul 14, 2015, at 4:14 AM, Thomas Mangin = wrote: > I appreciate that 4 is a sensible pick, but I would feel constrained = by it. With two code already being used by ExaBGP current implementation = (once migrated), I would need to be careful in picking what I shall = implement next when I rather like to not have to worry about it. OK, what's a good number? 5? 7? 11? 13? 127? Pick a value and I'll = update the draft and we can see what the rest of the WG thinks. Keep in = mind though that anything we allocate to this range becomes "toxic" and = can't easily be repurposed in the future, unlike the rest of the = registry. To me, that suggests a bias for keeping the experimental range = smallish. --John= From nobody Tue Jul 14 08:19: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 39E4F1ACEDB for ; Tue, 14 Jul 2015 08:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mf4Ui1abNTxD for ; Tue, 14 Jul 2015 08:18:56 -0700 (PDT) Received: from out-1.mail.exa.net.uk (out-1.mail.exa.net.uk [82.219.4.129]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34C761ACEBA for ; Tue, 14 Jul 2015 08:18:55 -0700 (PDT) Received: from smtp-5.exa.net.uk (unknown [82.219.5.5]) by out-1.mail.exa.net.uk (ExaSMTPD) with ESMTP id 810F21C0155; Tue, 14 Jul 2015 16:18:53 +0100 (BST) Received: from smtp-5.exa.net.uk (localhost [127.0.0.1]) by smtp-5.exa.net.uk (ExaSMTPD) with ESMTP id 6EE3B40258; Tue, 14 Jul 2015 16:18:53 +0100 (BST) Received: from [10.37.129.2] (office.exa-networks.co.uk [82.219.212.253]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: thomas@mangin.com) by smtp-5.exa.net.uk (ExaSMTPD) with ESMTPSA; Tue, 14 Jul 2015 16:18:53 +0100 (BST) From: "Thomas Mangin" To: "John Scudder" Date: Tue, 14 Jul 2015 16:18:50 +0100 Message-ID: <25B66A5F-6F34-405C-B3B0-69F962E8E19F@exa-networks.co.uk> In-Reply-To: <9842C3C0-287E-4C2A-BCA7-1D07C6135240@juniper.net> References: <20150702142348.4291.10005.idtracker@ietfa.amsl.com> <7C5305E5-69BF-4796-900A-726FFE4B2EEE@juniper.net> <4DA34703-7130-4612-AED6-58991575C7DF@exa-networks.co.uk> <9842C3C0-287E-4C2A-BCA7-1D07C6135240@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5107) X-Virus-Scanned: ClamAV using ClamSMTP Archived-At: Cc: org Subject: Re: [Idr] New Version Notification for draft-scudder-idr-capabilities-registry-change-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 15:18:58 -0000 > On Jul 14, 2015, at 4:14 AM, Thomas Mangin > wrote: >> I appreciate that 4 is a sensible pick, but I would feel constrained >> by it. With two code already being used by ExaBGP current >> implementation (once migrated), I would need to be careful in picking >> what I shall implement next when I rather like to not have to worry >> about it. > > OK, what's a good number? 5? 7? 11? 13? 127? Pick a value and I'll > update the draft and we can see what the rest of the WG thinks. Keep > in mind though that anything we allocate to this range becomes "toxic" > and can't easily be repurposed in the future, unlike the rest of the > registry. To me, that suggests a bias for keeping the experimental > range smallish. I agree with keeping the range small. As I do not like prime numbers, and PI my favourite number is too small, it would then seem that 42 would be the obvious answer .. which I assume we should really write 4^2 or 16 .. :-) More seriously anything between 8 and 16 would be fine with me, 12 would be 5% (rounded). Anyway, if/when we are getting toward the last 20 capabilities code, I assume it will be time to write a draft to extend the numbering space to two bytes anyway. IP, ASN, Capability .. p Thomas From nobody Wed Jul 15 06:04: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 06D931A8F35; Wed, 15 Jul 2015 06:04:03 -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 vVHewsS34m_4; Wed, 15 Jul 2015 06:04:00 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0732.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:732]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 991F71A8F33; Wed, 15 Jul 2015 06:04:00 -0700 (PDT) Received: from SN1PR09MB0799.namprd09.prod.outlook.com (10.162.101.145) by SN1PR09MB0797.namprd09.prod.outlook.com (10.162.101.143) with Microsoft SMTP Server (TLS) id 15.1.213.14; Wed, 15 Jul 2015 13:03:39 +0000 Received: from SN1PR09MB0799.namprd09.prod.outlook.com ([10.162.101.145]) by SN1PR09MB0799.namprd09.prod.outlook.com ([10.162.101.145]) with mapi id 15.01.0213.000; Wed, 15 Jul 2015 13:03:39 +0000 From: "Sriram, Kotikalapudi" To: Andrei Robachevsky Thread-Topic: draft-sriram-idr-route-leak-detection-mitigation: difference between a peer and a customer Thread-Index: AQHQvhEfZNxwzI8V2ECO5TICdbuD2Z3cfN/4 Date: Wed, 15 Jul 2015 13:03:39 +0000 Message-ID: References: <005901d0b283$ea07bd20$be173760$@ndzh.com> , <55A4CB9B.2050207@gmail.com> In-Reply-To: <55A4CB9B.2050207@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-originating-ip: [129.6.222.120] x-microsoft-exchange-diagnostics: 1; SN1PR09MB0797; 5:EkXjRldeuVlA2N1ATiFWoxuUwYA/wE15+ebirxO9qv5A9o3XPUSiv+FmdbZ8q1Tpxr2rVaS9aA4IINnGlh+j6DHgw64WwRgF7futAmQLwfScewYg9+TwpMKsxiwPjOYYnANsNgF8g9n/aHQRsL0IWg==; 24:4caH0F+rzJyAeXbP37RlhgUP9KyBCHUuNk4AnO3bzTBWH/nxKRn9oFNr91d+B3sqHQ2Ni+rbBmGbTm5Bjw1pMGOMpVEzsEcMpByc+sbCyRI=; 20:GhyJ6z7Mun7fC444iMfLElnFsxbnoqk5P4fGDxotpqXSsikbukG9Nuw/TXYpwIHZpOT6RfrXjY0RwVRrtffcFw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR09MB0797; sn1pr09mb0797: X-MS-Exchange-Organization-RulesExecuted 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:SN1PR09MB0797; BCL:0; PCL:0; RULEID:; SRVR:SN1PR09MB0797; x-forefront-prvs: 0638FD5066 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189998001)(87936001)(33656002)(2656002)(93886004)(5003600100002)(5002640100001)(122556002)(62966003)(76176999)(5001960100002)(40100003)(50986999)(66066001)(86362001)(230783001)(46102003)(2900100001)(106116001)(110136002)(77096005)(92566002)(77156002)(54356999)(99286002)(76576001)(74316001)(561944003)(102836002)(2950100001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR09MB0797; H:SN1PR09MB0799.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jul 2015 13:03:39.5657 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR09MB0797 Archived-At: Cc: idr wg list , "sidr wg list \(sidr@ietf.org\)" Subject: Re: [Idr] draft-sriram-idr-route-leak-detection-mitigation: difference between a peer and a customer 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 Jul 2015 13:04:03 -0000 Andrei, Thank you for reading the draft and offering comments -- certainly very hel= pful towards refining the proposal as well adding greater clarity in the documen= t. >It seems to me that sections 3.2.1. and 3.2.2. propose the same >algorithm (modulo the BGP neighbor is a customer or a peer).=20 Your observation is correct. It has to do with the semantics of RLP bits. For now, we have RLP =3D 00 (default; nothing said) and RLP =3D 01 ('do not= propagate up'). 'Do not propagate up' certainly means that the update should not subsequent= ly=20 propagate from a customer to its provider. However, a receiver can (at its own discretion) interpret RLP =3D 01 more s= trictly=20 to mean 'do not propagate to provider or peer'.=20 That is because if an ISP is not supposed to forward an update with RLP =3D= 01=20 'up' to a provider, then normally it should not forward it 'laterally' to a= peer either. So we have separated the receiver detection procedures for=20 (a) when the update comes from a *customer* (section 3.2.1), and=20 vs. (b) when it comes from a *peer* (section 3.2.2). The difference is the stricter interpretation (in Section 3.2.2) of RLP =3D= 01. Initially the attempt is to see if we can keep the RLP semantics simple, and still accomplish the detection objectives w.r.t. customer/peer.=20 These two section can be merged into one if, for example,=20 RLP =3D 01 is specified to denote 'do not propagate to provider or peer'. = =20 >The difference in the "possible actions" (3.3.) is not clear to me either. When an update is detected and 'marked' as 'route leak' (based on section 3= .2.1 or 3.2.2 detection), then the same/similar method(s) of mitigation can be applied (in the two ca= ses).=20 The draft should not specify a mitigation method because that is left to op= erator policy. So we describe only an *example* policy: Suspend the "prefer customer" poli= cy; i.e. instead of a 'marked' update from a customer, prefer an 'unmarked' update from a provider or peer. Some similar policy can be applied for a pe= er.=20 Let the operator decide the actual policy to be used in each case. >Finally, what is the proposed action when an RLP-marked update is >received from an upstream? Good point. The draft currently does not discuss this. If the customer is single-homed and does not have any alternate path for the prefix, then it would install the route learned from its sole provider even if it i= s 'marked'. If the customer is multi-homed, it should prefer an 'unmarked' update from= =20 one provider over a 'marked' update from another provider. Etc. Again these actions/methods are left to operator policy. However, in the next revision, we will include a subsection to outline this= . =20 Sriram From nobody Wed Jul 15 08:00: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 00FE71ACC88; Wed, 15 Jul 2015 08:00:31 -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 SEwBKZu-d1K0; Wed, 15 Jul 2015 08:00:27 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::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 DDD1E1ACC81; Wed, 15 Jul 2015 08:00:26 -0700 (PDT) Received: by widjy10 with SMTP id jy10so2294328wid.1; Wed, 15 Jul 2015 08:00:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type; bh=5MTJwI3qr3FS/9n+9dq0ooOnLcuvN/FTueKJNTYABFo=; b=axU3VsHDHITxsJT0i/TmPdSVsPIaZ6trwVeDecc8T7BddggOTQxUKvtpJI4HbA+1Ri QU3HcEpMWr7jXBmzU2Ub2JpYWsZfWbrlSj2wbpBq+bLBe8nhS/2A3xSEqcLg/FGPODNJ tMGNWgh0tVTLGsydp0amCuD6qyNjxqiz3e2JNDbu+WNI3wkuhfwWQYzXbAKDCJiN3shG gqUgcpsW/qH+PZoDD0OxOZBdm+bA915OHiQ3yvcWk0m3H407XxVjCXYF5wh0psbhY0hM 1tdg1o0uu/uJSotM8SdGC+cvLM+djV4hSiYI+oK9gv2tsadGbyJ1GxmKMvLhl3LuHrT6 /KcA== X-Received: by 10.194.94.101 with SMTP id db5mr9066079wjb.91.1436972425596; Wed, 15 Jul 2015 08:00:25 -0700 (PDT) Received: from ISOC-A1FD58.local ([92.109.76.43]) by smtp.googlemail.com with ESMTPSA id jy6sm8352902wjc.4.2015.07.15.08.00.23 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Jul 2015 08:00:24 -0700 (PDT) To: "Sriram, Kotikalapudi" References: <005901d0b283$ea07bd20$be173760$@ndzh.com> <55A4CB9B.2050207@gmail.com> From: Andrei Robachevsky X-Enigmail-Draft-Status: N1110 Message-ID: <55A67586.6050604@gmail.com> Date: Wed, 15 Jul 2015 17:00:22 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rb8bjcPqK7w9r3rRQLBw7WkpwPpbVVpMl" Archived-At: Cc: idr wg list , "sidr wg list \(sidr@ietf.org\)" Subject: Re: [Idr] draft-sriram-idr-route-leak-detection-mitigation: difference between a peer and a customer 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 Jul 2015 15:00:32 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --rb8bjcPqK7w9r3rRQLBw7WkpwPpbVVpMl Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thank you for your response, Sriram. Let me understand the semantics of the RLP field better. I am assuming that it indicates that a leak happened somewhere in the path, not necessarily at the adjacent AS (your customer or your peer). If this is indeed so, the only case I can think of when an RLP-marked update is not a leak, is when it came from the upstream. And if we follow the same logic an RLP-marked update from the upstream can still be a leak (and not just downstream announcements), but I think it would be difficult to distinguish between the two. If my considerations are correct, there are only two cases - upstreams/transit providers, for which RLP doesn't matter, and others (customers and peers) where an RLP indicates a leak and has to be dealt accordingly. Related to the latter - what would be in your opinion a reason to accept a leaked route? Is it just for reachability (i.e. only one route to the destination), or are there "legitimate" cases for route leaks? Thanks, Andrei Sriram, Kotikalapudi wrote on 15/07/15 15:03: > Andrei, >=20 > Thank you for reading the draft and offering comments -- certainly very= helpful > towards refining the proposal as well adding greater clarity in the doc= ument. >=20 >> It seems to me that sections 3.2.1. and 3.2.2. propose the same >> algorithm (modulo the BGP neighbor is a customer or a peer).=20 >=20 > Your observation is correct. It has to do with the semantics of RLP bit= s. > For now, we have RLP =3D 00 (default; nothing said) and RLP =3D 01 ('do= not propagate up'). > 'Do not propagate up' certainly means that the update should not subseq= uently=20 > propagate from a customer to its provider. > However, a receiver can (at its own discretion) interpret RLP =3D 01 mo= re strictly=20 > to mean 'do not propagate to provider or peer'.=20 > That is because if an ISP is not supposed to forward an update with RLP= =3D 01=20 > 'up' to a provider, then normally it should not forward it 'laterally' = to a peer either. > So we have separated the receiver detection procedures for=20 > (a) when the update comes from a *customer* (section 3.2.1), and=20 > vs. (b) when it comes from a *peer* (section 3.2.2). > The difference is the stricter interpretation (in Section 3.2.2) of RLP= =3D 01. > Initially the attempt is to see if we can keep the RLP semantics simple= , > and still accomplish the detection objectives w.r.t. customer/peer.=20 > These two section can be merged into one if, for example,=20 > RLP =3D 01 is specified to denote 'do not propagate to provider or peer= '. =20 >=20 >> The difference in the "possible actions" (3.3.) is not clear to me eit= her. >=20 > When an update is detected and 'marked' as 'route leak' (based on secti= on 3.2.1 or 3.2.2 detection), > then the same/similar method(s) of mitigation can be applied (in the tw= o cases).=20 > The draft should not specify a mitigation method because that is left t= o operator policy. > So we describe only an *example* policy: Suspend the "prefer customer" = policy; > i.e. instead of a 'marked' update from a customer, prefer an 'unmarked'= > update from a provider or peer. Some similar policy can be applied for = a peer.=20 > Let the operator decide the actual policy to be used in each case. >=20 >> Finally, what is the proposed action when an RLP-marked update is >> received from an upstream? >=20 > Good point. The draft currently does not discuss this. If the customer > is single-homed and does not have any alternate path for the prefix, > then it would install the route learned from its sole provider even if = it is 'marked'. > If the customer is multi-homed, it should prefer an 'unmarked' update f= rom=20 > one provider over a 'marked' update from another provider. Etc. > Again these actions/methods are left to operator policy. > However, in the next revision, we will include a subsection to outline = this. =20 >=20 > Sriram >=20 --rb8bjcPqK7w9r3rRQLBw7WkpwPpbVVpMl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - https://gpgtools.org iEYEARECAAYFAlWmdYcACgkQljz5tZmtij924ACgs6hMN15YAZHGUC20R2GeqrLX o70AoMmjnz+XiWAofKN0hMt7UiX72f2O =ZeeR -----END PGP SIGNATURE----- --rb8bjcPqK7w9r3rRQLBw7WkpwPpbVVpMl-- From nobody Wed Jul 15 14:21: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 B22E81A8851; Wed, 15 Jul 2015 14:21:01 -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 Lo6k6XRTwlAV; Wed, 15 Jul 2015 14:20:59 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0771.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::771]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63E441A873C; Wed, 15 Jul 2015 14:20:59 -0700 (PDT) Received: from CY1PR09MB0795.namprd09.prod.outlook.com (10.163.43.145) by CY1PR09MB0377.namprd09.prod.outlook.com (10.160.147.14) with Microsoft SMTP Server (TLS) id 15.1.213.14; Wed, 15 Jul 2015 21:20:39 +0000 Received: from CY1PR09MB0793.namprd09.prod.outlook.com (10.163.43.143) by CY1PR09MB0795.namprd09.prod.outlook.com (10.163.43.145) with Microsoft SMTP Server (TLS) id 15.1.213.14; Wed, 15 Jul 2015 21:20:38 +0000 Received: from CY1PR09MB0793.namprd09.prod.outlook.com ([10.163.43.143]) by CY1PR09MB0793.namprd09.prod.outlook.com ([10.163.43.143]) with mapi id 15.01.0219.000; Wed, 15 Jul 2015 21:20:38 +0000 From: "Sriram, Kotikalapudi" To: Andrei Robachevsky Thread-Topic: draft-sriram-idr-route-leak-detection-mitigation: difference between a peer and a customer Thread-Index: AQHQvhEfZNxwzI8V2ECO5TICdbuD2Z3cfN/4gAAk8ACAAGNnMA== Date: Wed, 15 Jul 2015 21:20:38 +0000 Message-ID: References: <005901d0b283$ea07bd20$be173760$@ndzh.com> <55A4CB9B.2050207@gmail.com> <55A67586.6050604@gmail.com> In-Reply-To: <55A67586.6050604@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none; x-originating-ip: [129.6.140.100] x-microsoft-exchange-diagnostics: 1; CY1PR09MB0795; 24:SLWKECSJpE7V9pVNXfLI17B9A/SsI4LK5nIxK3AOGakzFAsnsCaSBg5Z1IOnAw/ooZN2W/eoFgVdDD05AU2TcjDGUDr3aqTySzM0Ya3Cz+A=; 20:sOJr3S0yz5tagYHdgQh5mGfeGB/PYHRjyLq9QYN+d4/wzWdJOpEjHLmmp7eyK3dRMuHnBIb7jyXbh0xVakiAGA== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0795; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0377; cy1pr09mb0795: X-MS-Exchange-Organization-RulesExecuted 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: 0638FD5066 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(122556002)(189998001)(40100003)(74316001)(2656002)(86362001)(87936001)(62966003)(77156002)(106116001)(92566002)(5001960100002)(66066001)(5002640100001)(46102003)(93886004)(77096005)(33656002)(102836002)(2900100001)(2950100001)(50986999)(230783001)(54356999)(76176999)(76576001)(5003600100002); 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-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jul 2015 21:20:38.2873 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0795 X-Microsoft-Exchange-Diagnostics: 1; CY1PR09MB0377; 2:pbOJ3YoSkywa2XNrIGKi3DpxY8/J0uSJZCaJ/HzYm3q/V8kLx47n1dL8qe10zqV1; 3:qlH7jr6CtaK2xlw3V1DKvEqwyF0rADFadkTY+VygURecjko0YYz3yOlwC7jywwVUk3WFOTdywV8rLTkXUGuJyiYfCkwuVNhYG7wS2A+PglNoSVxrYhjEeKdUk4jBFcyvf0bKYabhExkrWzYmlpqEyQ==; 25:HCPx1MxiqyjUa2lBthc3Pelrtw5vsbEQNpbbMpKRnKIE6i58PvMvN0mOkcUyzJ1IqswBVDxeV3LhjEZZC/ZgLv2gLMPK8C3pwWtcMJ6LS9CGUgckPN6F4VwFjL868wNkYE2R/3YoblFVM06kLTMJHtYsT+CxiG1wf9xVP4wfyIugt5n90AvBocqNnpxYpsI/l9n9ebkb+FE+LYJXNOyD1ea7RcT9rBTk2eqSc8GAvwtTK3CM66+GK8soK8Njncc63DAgjMqt6e1iTQim2aqL2Q==; 20:BnQCZ0tbt/kgJi7t3Zs/c3ak6KTj3KJPOCSIHqrbO2zupnibBT2dY92/q/966Rvcg4KTIT+Tv78n25icB5+9jg==; 23:H6ye0PB/Khn4ENnv6VdNfNsC9Yc6I4W24vznwjQEQIqcZR/Y/UoNcv/DzpHHT5W8+DSBdslyp0MJL0pV514qa2deDBW4aUehPWy7DcJ4/LC7LCQFLSljZkEp5/BRXTgpy9t72uTtq/+uBplpeqJfncIz47CXLZLEr+KyHu3WNXuQk4RYVDANd8X6QHGtiHQtPknK6sKItweUk/tvbrqvy/lKOBs1LBUBgy5I9he/S1YI5l0rkCEckoc27GCYpvtk CY1PR09MB0377: X-MS-Exchange-Organization-RulesExecuted X-OriginatorOrg: nist.gov Archived-At: Cc: idr wg list , "sidr wg list \(sidr@ietf.org\)" Subject: Re: [Idr] draft-sriram-idr-route-leak-detection-mitigation: difference between a peer and a customer 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 Jul 2015 21:21:01 -0000 >Let me understand the semantics of the RLP field better. I am assuming >that it indicates that a leak happened somewhere in the path,=20 RLP field does not indicate (or encode) that a *leak happened*. It merely facilitates a receiving router to detect if an update from a sending router (an adjacent AS) is a route leak.=20 Example 1: Route for prefix P propagates as follows:=20 P---AS A ---{ RLP(AB) =3D 01 }---> AS B (cust. of A) ---{ RLP(BC) =3D 01,= RLP(AB) =3D 01 }---> AS C (cust. of B)=20 Sequentially, B is a customer of A, and C is a customer of B. =20 The expression in wiggly brackets {} shows the RLP values in the prefix upd= ate. A transitive RLP field is added in the update for each hop in the path.=20 Each AS sets an RLP value for its hop to the next AS for the route it forwa= rds for prefix P. RLP =3D 01 indicates that the update SHOULD NOT be sent 'up' to a provider = (or=20 'laterally' to a peer), but it is allowed to forward the update to a custom= er. So no one in this Example 1 detects a route leak. There is no route leak.=20 Example 2: P---AS A ---{ RLP(AB) =3D01 } ---> AS B (cust. of A) --- { RLP(AB) =3D01,= RLP(BC) =3D00) } ---> AS C (provider of B) B (in the middle) has two providers A and C. B learned a route from A and is leaking the route to C, and C detects it. C looks at RLP(AB) =3D 01, and therefore it knows that B's update is a leak= . So C marks B's update as a route leak. =20 >not necessarily at the adjacent AS (your customer or your peer).=20 As in the examples above, the receiver is only detecting if the update from= =20 its adjacent router is a route leak. It does so by looking=20 at NOT the RLP field value set by the adjacent router=20 but the RLP field values set by the ASes that preceded it. >If this is indeed so, the only case I can think of when an RLP-marked upda= te is not >a leak, is when it came from the upstream. May be this question goes away in light of the proper understanding=20 of RLP field values provided above. It is true that an upstream provider cannot leak any prefix route to its customer by definition. Any prefix routes that the upstream has accepted=20 (after applying route leak detection/mitigation etc.), the upstream usually= send all those routes to its customer (except those learned from that customer).=20 So in general, a customer need not try to detect route leak from its upstre= am provider (keep in mind that we are talking about the relationships on per prefix bas= is). (Please ignore what I said in my previous reply to you about detecting rout= e leaks from a provider; the last paragraph.) We have not used the term "RLP-marked" anywhere in the draft. So I don't know what exactly you mean by it. But hopefully the above explanations clarify things for you. When we say an update is 'marked', it simply means that it was detected=20 to be a route leak (as it was received from a neighbor AS).=20 >And if we follow the same logic an RLP-marked update from the upstream >can still be a leak (and not just downstream announcements), but I think >it would be difficult to distinguish between the two. > >If my considerations are correct, there are only two cases - >upstreams/transit providers, for which RLP doesn't matter, and others >(customers and peers) where an RLP indicates a leak and has to be dealt >accordingly. Yes, I agree that detecting route leaks from customers/peers matters. Detecting route leaks from upstreams/transit providers does not really matt= er (as explained above). >Related to the latter - what would be in your opinion a reason to accept >a leaked route? Is it just for reachability (i.e. only one route to the >destination), or are there "legitimate" cases for route leaks? In this discussion and the draft, we have not called anything a "legitimate" route leak. But some customer ASes could make mistakes. For example, if X is single-homed stub customer of Y and Y is a customer of= Z, and if X sets RLP =3D 01 by mistake in its prefix update to Y, then Z detec= ts and marks the prefix route from Y as a route leak.=20 Z will not have any alternate path for that prefix because X is single-home= d stub. In this case, Z may accept the update for reachability even though it was detected to be route leak. Again, we don't specify this.=20 We only specify the detection method, not the mitigation policy. =20 Thank you. Sriram From nobody Wed Jul 15 14:59: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 0559B1B3306 for ; Wed, 15 Jul 2015 14:59:02 -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 kCi9CHs2NZBN for ; Wed, 15 Jul 2015 14:59:00 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (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 88BAC1B3505 for ; Wed, 15 Jul 2015 14:59:00 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=98.174.216.229; From: "Susan Hares" To: "'Acee Lindem \(acee\)'" , "'Randy Bush'" References: <20150706203650.6815.83256.idtracker@ietfa.amsl.com> <20150706210159.GC13743@shrubbery.net> <027801d0b82f$60ad05b0$22071110$@ndzh.com> <20150710192227.GP13783@pfrc.org> <20150712200048.GA21130@varda.crfreenet.org> <004b01d0bdc6$221d8a80$66589f80$@ndzh.com> <019401d0bddb$2e7bb0d0$8b731270$@ndzh.com> In-Reply-To: Date: Wed, 15 Jul 2015 17:58:53 -0400 Message-ID: <020301d0bf49$710eaf50$532c0df0$@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: AQGBfyn0a/XgdWqa5S7LQAUhGp5VDwJoZzRkAL6c2DwCuEQnVgI+2y9SAchfrQoCNhVKSwGg/0M8AgghTBICT1vSAwIHNAExAiP1VJkBqR8ItJ28SZMg Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'idr wg list' Subject: Re: [Idr] I-D Action: draft-ietf-idr-bgp-extended-messages-10.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, 15 Jul 2015 21:59:02 -0000 Acee:=20 I will go for the early adoption request.=20 Sue=20 -----Original Message----- From: Acee Lindem (acee) [mailto:acee@cisco.com]=20 Sent: Tuesday, July 14, 2015 5:53 AM To: Randy Bush; Susan Hares Cc: 'idr wg list' Subject: Re: [Idr] I-D Action: = draft-ietf-idr-bgp-extended-messages-10.txt Hi Randy, Sue, If all one wants to do is experimentation for interoperability, then = FCFS is fine. However, if the implementation is to be supported, it is a = real pain for the code point to change. I=E2=80=99d say that early = allocation is always a good idea for drafts that the WG expects to be = submitted to the IESG for publication within the 1 year IANA allocation = period. Thanks, Acee On 7/13/15, 10:22 PM, "Idr on behalf of Randy Bush" = wrote: >sue > >> Do you want a standard's early allocation or a FCFS allocation? It = is >>your >> choice. The pain is not that bad since the Routing AD can approve it >>now.=20 > >i personally do not care. the implementors and early deployers may so >they do not get a compatibility issue should this become an rfc. > >randy=20 > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr From nobody Wed Jul 15 15:02: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 C34FB1B2D62 for ; Wed, 15 Jul 2015 15:02: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 cvZ-qoNB4U4f for ; Wed, 15 Jul 2015 15:02:37 -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 005B81B2D61 for ; Wed, 15 Jul 2015 15:02:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1992; q=dns/txt; s=iport; t=1436997757; x=1438207357; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=3Ss64JB96eVEBPNNMh21UMaenNzkNVQJcBtYBo8LLag=; b=c+E7ybV8/ETyC5eozPzLL7qOY4AIU/edSUHvaKpFx/ByIyfvdVvATb/+ t6AJO+hAZ2U+rtyn702YNFhV98eeaQ9VxsKtCFAXAWg825JOsQ3J9KLxL yNdeV/GIkcCposHY70H1VaNKy54SKy6k7Wdb7phW5+FWiOer2b5kptD5m 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ArAwAn2KZV/5tdJa1bgxNUaQaDHbgQCYFsCoV3AhyBJTgUAQEBAQEBAYEKhCMBAQEEAQEBIBE6CwwEAgEIDgMEAQEBAgIjAwICAiULFAEICAIEAQ0FiC4NuWuWNwEBAQEBAQEBAQEBAQEBAQEBAQEBARMEgSKKKoRTMwcGgmKBQwWUPQGMDYFAk1WDYSaDfG+BR4EEAQEB X-IronPort-AV: E=Sophos;i="5.15,483,1432598400"; d="scan'208";a="168977059" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-6.cisco.com with ESMTP; 15 Jul 2015 22:02:27 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t6FM2RKq026899 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 15 Jul 2015 22:02:27 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.37]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0195.001; Wed, 15 Jul 2015 17:02:27 -0500 From: "Acee Lindem (acee)" To: Susan Hares , "'Randy Bush'" Thread-Topic: [Idr] I-D Action: draft-ietf-idr-bgp-extended-messages-10.txt Thread-Index: AQHQuCuFeXhtQ0gVtkOfuKEnBEqrtp3PPEKAgAAFN4CAAADBgIAGLMUAgAABN4CAAt20WIACIdMAgAAf6wCAAAouAIAAAX+AgAA6ygCAAqA8gP//vfqA Date: Wed, 15 Jul 2015 22:02:26 +0000 Message-ID: References: <20150706203650.6815.83256.idtracker@ietfa.amsl.com> <20150706210159.GC13743@shrubbery.net> <027801d0b82f$60ad05b0$22071110$@ndzh.com> <20150710192227.GP13783@pfrc.org> <20150712200048.GA21130@varda.crfreenet.org> <004b01d0bdc6$221d8a80$66589f80$@ndzh.com> <019401d0bddb$2e7bb0d0$8b731270$@ndzh.com> <020301d0bf49$710eaf50$532c0df0$@ndzh.com> In-Reply-To: <020301d0bf49$710eaf50$532c0df0$@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: text/plain; charset="utf-8" Content-ID: <5F6151B7229A5F42A8911BB7B1092D01@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: 'idr wg list' Subject: Re: [Idr] I-D Action: draft-ietf-idr-bgp-extended-messages-10.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, 15 Jul 2015 22:02:38 -0000 VGhhbmtzIFN1ZSAtIHdlIG1heSBoYXZlIGEgcHJvdG90eXBlIGZvciB0ZXN0aW5nIGFzIHdlbGwu DQpBY2VlIA0KDQpPbiA3LzE1LzE1LCA1OjU4IFBNLCAiU3VzYW4gSGFyZXMiIDxzaGFyZXNAbmR6 aC5jb20+IHdyb3RlOg0KDQo+QWNlZTogDQo+DQo+SSB3aWxsIGdvIGZvciB0aGUgZWFybHkgYWRv cHRpb24gcmVxdWVzdC4NCj4NCj5TdWUgDQo+DQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj5Gcm9tOiBBY2VlIExpbmRlbSAoYWNlZSkgW21haWx0bzphY2VlQGNpc2NvLmNvbV0NCj5TZW50 OiBUdWVzZGF5LCBKdWx5IDE0LCAyMDE1IDU6NTMgQU0NCj5UbzogUmFuZHkgQnVzaDsgU3VzYW4g SGFyZXMNCj5DYzogJ2lkciB3ZyBsaXN0Jw0KPlN1YmplY3Q6IFJlOiBbSWRyXSBJLUQgQWN0aW9u OiBkcmFmdC1pZXRmLWlkci1iZ3AtZXh0ZW5kZWQtbWVzc2FnZXMtMTAudHh0DQo+DQo+SGkgUmFu ZHksIFN1ZSwNCj5JZiBhbGwgb25lIHdhbnRzIHRvIGRvIGlzIGV4cGVyaW1lbnRhdGlvbiBmb3Ig aW50ZXJvcGVyYWJpbGl0eSwgdGhlbiBGQ0ZTDQo+aXMgZmluZS4gSG93ZXZlciwgaWYgdGhlIGlt cGxlbWVudGF0aW9uIGlzIHRvIGJlIHN1cHBvcnRlZCwgaXQgaXMgYSByZWFsDQo+cGFpbiBmb3Ig dGhlIGNvZGUgcG9pbnQgdG8gY2hhbmdlLiBJ4oCZZCBzYXkgdGhhdCBlYXJseSBhbGxvY2F0aW9u IGlzDQo+YWx3YXlzIGEgZ29vZCBpZGVhIGZvciBkcmFmdHMgdGhhdCB0aGUgV0cgZXhwZWN0cyB0 byBiZSBzdWJtaXR0ZWQgdG8gdGhlDQo+SUVTRyBmb3IgcHVibGljYXRpb24gd2l0aGluIHRoZSAx IHllYXIgSUFOQSBhbGxvY2F0aW9uIHBlcmlvZC4NCj5UaGFua3MsDQo+QWNlZQ0KPg0KPg0KPk9u IDcvMTMvMTUsIDEwOjIyIFBNLCAiSWRyIG9uIGJlaGFsZiBvZiBSYW5keSBCdXNoIiA8aWRyLWJv dW5jZXNAaWV0Zi5vcmcNCj5vbiBiZWhhbGYgb2YgcmFuZHlAcHNnLmNvbT4gd3JvdGU6DQo+DQo+ PnN1ZQ0KPj4NCj4+PiBEbyB5b3Ugd2FudCBhIHN0YW5kYXJkJ3MgZWFybHkgYWxsb2NhdGlvbiBv ciBhIEZDRlMgYWxsb2NhdGlvbj8gIEl0IGlzDQo+Pj55b3VyDQo+Pj4gY2hvaWNlLiAgVGhlIHBh aW4gaXMgbm90IHRoYXQgYmFkIHNpbmNlIHRoZSBSb3V0aW5nIEFEIGNhbiBhcHByb3ZlIGl0DQo+ Pj5ub3cuIA0KPj4NCj4+aSBwZXJzb25hbGx5IGRvIG5vdCBjYXJlLiAgdGhlIGltcGxlbWVudG9y cyBhbmQgZWFybHkgZGVwbG95ZXJzIG1heSBzbw0KPj50aGV5IGRvIG5vdCBnZXQgYSBjb21wYXRp YmlsaXR5IGlzc3VlIHNob3VsZCB0aGlzIGJlY29tZSBhbiByZmMuDQo+Pg0KPj5yYW5keSANCj4+ DQo+Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pklk ciBtYWlsaW5nIGxpc3QNCj4+SWRyQGlldGYub3JnDQo+Pmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vaWRyDQo+DQo+DQoNCg== From nobody Thu Jul 16 01:14:03 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 340CA1B3754; Thu, 16 Jul 2015 01:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.3 X-Spam-Level: X-Spam-Status: No, score=0.3 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, MANGLED_TOOL=2.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7c71zW9pAUPn; Thu, 16 Jul 2015 01:14:01 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (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 BD8C21B3752; Thu, 16 Jul 2015 01:14:00 -0700 (PDT) Received: by wgkl9 with SMTP id l9so51846567wgk.1; Thu, 16 Jul 2015 01:13:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type; bh=vTQ57BLBTJoi6YMKiB0evw0PY+AxnyQ6fAbpR1FBd8M=; b=Er/TrzCoUDYd/Lh5jrND1gqDYg1+6Ci5NjXMUN3gOQ8cAgBW2E6VD7F5D4mVgbikgq V3F2jeljaRr3hYuvTBasSOgp88V9KMHd7Qdiny4Q9IVbQCtPIytdPcid8+7JG/tF3Cod 4NLAav1ivMqtc+V4nGKPt0qsA7+6EXuue+bdF9ZAvsgcOmjWtPxJIy1Bn/d7pVDglZmZ acAQO73H1Q9UNbq/T5FKhYSJvoKW9pbmVHBxaM5vQ664VL4gIKGfMBhScZJAVE5VDc5N NxWX1GwjnFsJuRZQMzWKdkm7WIyTOznmyI5TmUdXVZpM2Qgla7A5QsIfdTLz18FEBj2B i+zA== X-Received: by 10.194.78.14 with SMTP id x14mr17096642wjw.48.1437034439551; Thu, 16 Jul 2015 01:13:59 -0700 (PDT) Received: from ISOC-A1FD58.local ([92.109.76.43]) by smtp.googlemail.com with ESMTPSA id ec19sm2297181wic.0.2015.07.16.01.13.58 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Jul 2015 01:13:58 -0700 (PDT) To: "Sriram, Kotikalapudi" References: <005901d0b283$ea07bd20$be173760$@ndzh.com> <55A4CB9B.2050207@gmail.com> <55A67586.6050604@gmail.com> From: Andrei Robachevsky X-Enigmail-Draft-Status: N1110 Message-ID: <55A767C5.3090805@gmail.com> Date: Thu, 16 Jul 2015 10:13:57 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1JxceUR20vfWJapxxd97CeQKnOLX3EI1b" Archived-At: Cc: idr wg list , "sidr wg list \(sidr@ietf.org\)" Subject: Re: [Idr] draft-sriram-idr-route-leak-detection-mitigation: difference between a peer and a customer 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 Jul 2015 08:14:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1JxceUR20vfWJapxxd97CeQKnOLX3EI1b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Sriram, Your explanations make it very clear, thanks. Sriram, Kotikalapudi wrote on 15/07/15 23:20: > Example 2: >=20 > P---AS A ---{ RLP(AB) =3D01 } ---> AS B (cust. of A) --- { RLP(AB) =3D= 01, RLP(BC) =3D00) } ---> AS C (provider of B) >=20 > B (in the middle) has two providers A and C. > B learned a route from A and is leaking the route to C, and C detects i= t. > C looks at RLP(AB) =3D 01, and therefore it knows that B's update is a = leak. > So C marks B's update as a route leak. =20 >=20 >> not necessarily at the adjacent AS (your customer or your peer).=20 >=20 Yes. What I meant here is a case when you extend your example to AS D (a peer or a provider of AS C). Assuming that AS C has no route-leak mitigation policy and propagates the update further, AS D may detect the leak, which happened somewhere in the path (where precisely - D does not know and does not need to know). The only thing that matters is that the update has the RLP field set to '01' indication for one or more hops (excluding the most recent) in the AS path (that is what I called the RLP-marked in my note) *and* it does not come from the upstream/transit provider. [...] >> >> If my considerations are correct, there are only two cases - >> upstreams/transit providers, for which RLP doesn't matter, and others >> (customers and peers) where an RLP indicates a leak and has to be deal= t >> accordingly. >=20 > Yes, I agree that detecting route leaks from customers/peers matters. > Detecting route leaks from upstreams/transit providers does not really = matter > (as explained above). I guess what I am arguing for is that the semantics of RLP 01 should be "propagate only down" rather than "do not propagate up" and any updates with the RLP field set from a peer or a customer should be treated as a leak. Thanks, Andrei --1JxceUR20vfWJapxxd97CeQKnOLX3EI1b Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - https://gpgtools.org iEYEARECAAYFAlWnZ8UACgkQljz5tZmtij/k8gCdGZaHhTy9JZV8OKsEkshVpmAl MKoAnjGca9PvMLxNTTWrDqVF8Eaphx5u =eCHk -----END PGP SIGNATURE----- --1JxceUR20vfWJapxxd97CeQKnOLX3EI1b-- From nobody Thu Jul 16 15:14: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 DA0AB1A90A2 for ; Thu, 16 Jul 2015 15:14:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 kXuHOty37YFv for ; Thu, 16 Jul 2015 15:14:07 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (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 53B261A90A0 for ; Thu, 16 Jul 2015 15:14:07 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=166.177.185.185; Date: Thu, 16 Jul 2015 18:07:06 -0400 Message-ID: Importance: normal From: Sue Hares To: idr@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.android.email_2642098617078690" X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [Idr] Slides for the Monday session are due on Sunday by 5pm prague time 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 Jul 2015 22:14:10 -0000 ----_com.android.email_2642098617078690 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 UGxlYXNlIHNlbmQgc2xpZGVzIGJ5IFN1bmRheSBmb3IgTW9uZGF5J3MgSURSIFdHIG1lZXRpbmcu IMKgCgpTdWUKCgpTZW50IHZpYSB0aGUgU2Ftc3VuZyBHQUxBWFkgU8KuNCwgYW4gQVQmVCA0RyBM VEUgc21hcnRwaG9uZQ== ----_com.android.email_2642098617078690 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSA+PGRpdj5QbGVhc2Ugc2VuZCBzbGlk ZXMgYnkgU3VuZGF5IGZvciBNb25kYXkncyBJRFIgV0cgbWVldGluZy4gJm5ic3A7PC9kaXY+PGRp dj48YnI+PC9kaXY+PGRpdj5TdWU8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48 ZGl2PjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTo5cHg7Y29sb3I6IzU3NTc1NyI+U2VudCB2aWEgdGhl IFNhbXN1bmcgR0FMQVhZIFPCrjQsIGFuIEFUJmFtcDtUIDRHIExURSBzbWFydHBob25lPC9kaXY+ PC9kaXY+PC9ib2R5PjwvaHRtbD4= ----_com.android.email_2642098617078690-- From nobody Fri Jul 17 06:40: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 7EFDE1B33AD; Fri, 17 Jul 2015 06:40:44 -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 Vs3DMlBfteVw; Fri, 17 Jul 2015 06:40:43 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0762.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::762]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 973771B33E9; Fri, 17 Jul 2015 06:40:42 -0700 (PDT) Received: from CY1PR09MB0795.namprd09.prod.outlook.com (10.163.43.145) by CY1PR09MB0377.namprd09.prod.outlook.com (10.160.147.14) with Microsoft SMTP Server (TLS) id 15.1.213.14; Fri, 17 Jul 2015 13:40:38 +0000 Received: from CY1PR09MB0793.namprd09.prod.outlook.com (10.163.43.143) by CY1PR09MB0795.namprd09.prod.outlook.com (10.163.43.145) with Microsoft SMTP Server (TLS) id 15.1.219.17; Fri, 17 Jul 2015 13:40:37 +0000 Received: from CY1PR09MB0793.namprd09.prod.outlook.com ([10.163.43.143]) by CY1PR09MB0793.namprd09.prod.outlook.com ([10.163.43.143]) with mapi id 15.01.0219.000; Fri, 17 Jul 2015 13:40:37 +0000 From: "Sriram, Kotikalapudi" To: Andrei Robachevsky Thread-Topic: draft-sriram-idr-route-leak-detection-mitigation: difference between a peer and a customer Thread-Index: AQHQvhEfZNxwzI8V2ECO5TICdbuD2Z3cfN/4gAAk8ACAAGNnMIAAvWGAgAHfYks= Date: Fri, 17 Jul 2015 13:40:37 +0000 Message-ID: References: <005901d0b283$ea07bd20$be173760$@ndzh.com> <55A4CB9B.2050207@gmail.com> <55A67586.6050604@gmail.com> , <55A767C5.3090805@gmail.com> In-Reply-To: <55A767C5.3090805@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-originating-ip: [129.6.220.66] x-microsoft-exchange-diagnostics: 1; CY1PR09MB0795; 5:qXPBUM/eWZOjRi+xfysoNRStpXKd+Ym/paV3PnDw5EvOwFpQTDNwKFt2hOs6IpMshqD4DrQ5JhEMm/JQmzPRlHccW9jc3YnsXKjOtfi7dZlWyFe2BD6apS1S67MECVPFs+VI1h7jSohUEj/M5y/Cfw==; 24:N/LR0ZTDdPcquP5vQEwKqcP55Hl2d8gMFgoMiDr5z/Us64guBSQLd2h37UvXiBJChQT7030CD1tLnMQPqpQL7nd6ChYGw9FF/dd5OI7XLkM=; 20:KmSIltxeAqqYJOJTl8jCDwMGgtRhrMmji+dWiCJ/cz6SA9EpA+5HpveK/s85JWgaq25Eq7LgW3pJ9cUkwJVPZw== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0795; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0377; cy1pr09mb0795: X-MS-Exchange-Organization-RulesExecuted 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: 06400060E1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(2656002)(62966003)(77156002)(46102003)(93886004)(74316001)(122556002)(106116001)(99286002)(40100003)(5003600100002)(230783001)(102836002)(54356999)(92566002)(77096005)(5001920100001)(33656002)(5002640100001)(5001960100002)(110136002)(66066001)(87936001)(76176999)(76576001)(50986999)(189998001)(86362001)(2900100001)(2950100001); 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jul 2015 13:40:37.6313 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0795 X-Microsoft-Exchange-Diagnostics: 1; CY1PR09MB0377; 2:ebhUe5LMQm3zPMxTQRRp9OFxVzuC+w+2pKZeW/Z15pFWIwWbe4tKeARDTBTSCRnr; 3:H0LmVNBU/qEuSY+z7s9aoJ2dBsVrk1oGiAoLfoVytqUMUcHXLnmsJEGCAQ9/uHdsOZY8X+nnG5Nylwb349YwnrIgXfjUHc9fqq2JV4+dNd8QZ8xaDvE1brupkH83+Hp3hiMS4NfJ71e+1+GXFsXTIA==; 25:3+EtKf8vQuQjuKopyjMi+AS4meqOkU+rmwRNg3JIbzKZ34WAKvtk7fb2/SY0FWJbYcSxvY1bYooC2/eDU5UJQWbbVpiOZxSgDeiSBfaby+f58WIdGq0n1vG7r4TwV1BDJHmYiXWvkVgDfQjeOL3TT6lLLLkkLFb5Eric9KglNzHc1nfesvfYFxjwzKTrpBvZQdsQ+Z4lpdZ4wCn6CtEcSWn6MKAOLgiCQlVojZjzmEfcUBcCL9TQ7MUtFhfu6eJwh2bQgrbVTxFXtKJPI5fmTw==; 20:DPsoAkzX5KVRjOIQ1Ph2ka+ETbrrSFQ9nVLVEsGphE7l9Qlx94gwRlwl6HkwkBib62/63JkRsqBvlfT9a9m4ug==; 23:5zJUVQ56bGGg/BybalJQZdLQDk0ZrzeMsKFkfjyCeHeIA+shn1mnoBQ5NfWs7uVGjxXPSRggZG3eTqjr3tHoLrMK743jq4flHxSyR7paZkjnWj2/KbzpiDTD0kL/Yd7mBUMRDInMOY66wDnxa8mJbXpfvr7NnqmtcZ8v3Cu5mW277/LuIuFInFJ4vMopDpxhNEQ50TSCDm89uSGrO0v2bnKVlCMyRUZHu8CwiGRrJ0/XuFTWgnXXtUNV2ILNq+Gm CY1PR09MB0377: X-MS-Exchange-Organization-RulesExecuted X-OriginatorOrg: nist.gov Archived-At: Cc: idr wg list , "sidr wg list \(sidr@ietf.org\)" Subject: Re: [Idr] draft-sriram-idr-route-leak-detection-mitigation: difference between a peer and a customer 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, 17 Jul 2015 13:40:44 -0000 >Your explanations make it very clear, thanks. Thanks, Andrei.=20 Looks like we've converged on pretty much all issues that we've discussed s= o far in this thread. One comment inline below. [...] >>> If my considerations are correct, there are only two cases - >>> upstreams/transit providers, for which RLP doesn't matter, and others >>> (customers and peers) where an RLP indicates a leak and has to be dealt >>> accordingly. >> >> Yes, I agree that detecting route leaks from customers/peers matters. >> Detecting route leaks from upstreams/transit providers does not really m= atter >> (as explained above). >I guess what I am arguing for is that the semantics of RLP 01 should be >"propagate only down" rather than "do not propagate up" and any updates >with the RLP field set from a peer or a customer should be treated as a >leak. OK, I see now what you meant. Your suggestion is good.=20 In the draft, currently in Section 3.2.2 "do not propagate up"=20 is interpreted (implicitly) as "propagate only down" for a peer. =20 But with this change (as suggested above by you) , we no longer have to=20 make that distinction. The semantics of RLP 01 would be the same=20 whether an update is received from a customer or a peer.=20 Then route leak detection algorithm would be the same for customer or peer, and sections 3.2.1 and 3.2.2 can be merged into one. Thanks. Sriram =20 From nobody Sat Jul 18 01:46:02 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 D67681ACD80 for ; Sat, 18 Jul 2015 01:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.156 X-Spam-Level: X-Spam-Status: No, score=-97.156 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 TazGnESfyK2R for ; Sat, 18 Jul 2015 01:46:00 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (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 D6D821ACD77 for ; Sat, 18 Jul 2015 01:45:59 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=31.133.137.143; From: "Susan Hares" To: "'idr wg list'" References: <02ce01d0b851$4ecec5a0$ec6c50e0$@ndzh.com> <2691CE0099834E4A9C5044EEC662BB9D571ADA7E@dfweml701-chm> <55A0273D.4020608@juniper.net> <2691CE0099834E4A9C5044EEC662BB9D571B77BF@dfweml701-chm> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D571B77BF@dfweml701-chm> Date: Sat, 18 Jul 2015 04:45:53 -0400 Message-ID: <001001d0c136$290061b0$7b012510$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH70WLjtgamLeCG30q/4qcocfnXPQJQIfwEAl0AufUB1hMIgp1Wr3YQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: "'Keyur Patel \(keyupate\)'" Subject: Re: [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00.txt (7/6 to 7/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: Sat, 18 Jul 2015 08:46:01 -0000 Based on the BESS chairs request this adoption call will be extended 2 weeks to 7/31 for BESS WG membesr to comment. Sue Hares From nobody Sat Jul 18 19:31: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 185241A1A62 for ; Sat, 18 Jul 2015 19:31:32 -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 TltFA9UwxkpW for ; Sat, 18 Jul 2015 19:31:30 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (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 AC7211A1A5A for ; Sat, 18 Jul 2015 19:31:30 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=31.133.137.143; From: "Susan Hares" To: "'idr wg list'" Date: Sat, 18 Jul 2015 22:31:08 -0400 Message-ID: <005401d0c1ca$f9cb4ff0$ed61efd0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0055_01D0C1A9.72B9AFF0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdDBvhFFKlL7V5QzSBinuzWU8bfnGw== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: "'Keyur Patel \(keyupate\)'" , draft-ietf-idr-bgp-extended-messages@tools.ietf.org Subject: [Idr] Early allocation WG Review Call draft-ietf (7/19 to 8/2) - WG LC X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2015 02:31:32 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0055_01D0C1A9.72B9AFF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The authors have requested early allocation for the draft-ietf-idr-bgp-extended-messages which you can find at: http://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/ The authors should to this Early Adoption WG LC to the list to indicate if they know of any IPR. Juniper has one implementation for this draft. Sue Hares ------=_NextPart_000_0055_01D0C1A9.72B9AFF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The = authors have requested early allocation for the = draft-ietf-idr-bgp-extended-messages which you can find = at:

 

http://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-message= s/

 

The authors should to this Early Adoption WG LC to the = list to indicate if they know of any IPR.   Juniper has one = implementation for this draft. 

 

Sue Hares =

 

 

=   

------=_NextPart_000_0055_01D0C1A9.72B9AFF0-- From nobody Sat Jul 18 19:55: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 E01031A1B81 for ; Sat, 18 Jul 2015 19:55:51 -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 a2DlvrcToCXX for ; Sat, 18 Jul 2015 19:55:50 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0138.outbound.protection.outlook.com [207.46.100.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A1CA1A1A6C for ; Sat, 18 Jul 2015 19:55:50 -0700 (PDT) Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none; Received: from [172.29.64.139] (193.110.55.14) by CY1PR0501MB1836.namprd05.prod.outlook.com (10.163.141.15) with Microsoft SMTP Server (TLS) id 15.1.219.17; Sun, 19 Jul 2015 02:55:48 +0000 From: "John G. Scudder" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 19 Jul 2015 04:55:34 +0200 References: To: "idr@ietf. org" Message-ID: MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) X-Mailer: Apple Mail (2.2102) X-Originating-IP: [193.110.55.14] X-ClientProxiedBy: DB4PR04CA0027.eurprd04.prod.outlook.com (25.160.41.37) To CY1PR0501MB1836.namprd05.prod.outlook.com (25.163.141.15) X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1836; 2:GoZ2ib0hEm+nkT4m+jNA9VzOQiuvUlPomotY1NasxRDiwiGor+zGQLE7xK75EEGS; 3:XzipE/CEBytKaUotz1C9iCZqWr3Q3OqiZ5YWn6ZJhU1doR8oZ6N6kKCaN7PPxJ+GguLj8rxG2c9JgF3fZ308uisG71RLciNaJu/E2EIWgWMZRSi7Q6HGEEkG0VfYrIBFPXK4OBhbSFVseh8Sn5+t4Q==; 25:zQP+OK9pQ8t4ulYlSMTaUdj9pfM0kHMrMaXLE8nOq0sERUbgwsafFml8yApK4yeGmarT+Lf/ORdxjyqh6T1DUnxzmOE98LtEm8pNWcG5zR2TaXght9fwRPsOvkAYgapy0StyQQK+li0be1kpA/M6ChbrRLyYNqPtDiI7SXSWXEaC3AnuXfBO8+/zA/ANJFfEwR0s5cW9FBN/X00fg/zX3HaMVVSvHPy4Pj8YJkkweXXVX4+3lYFTByqEUNLcQWrOZOpbYwBPoiVAsBMA62rCjg== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1836; X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1836; 20:Urhuw0GenTwkNEuRXxKzUD4oDZ09BrLtbPc0nntZMbGc06HzdvrLK7LQncH3zxH8GX1lJfmZzIP6WI/lcwTtSiVV2v9zWFmYdbp3JQfg6+/bykbPp4NhmZQm5/5MQxiR162h3Zfg5zFXvUtxsuCnTqHojdm6ISwyQk/YtHwa/fkxFw8fg2Sr/iBCoq1De/q/9DdyNvtY+LHHwHLoHTt9exKjEzCRDB4HFE3ifbROXPbbwIHcHVH037D9QeYqhhD19EFOuwoVsGm185peoHaRK7rsO+g22Ij/mfh8feth9s+hOmSbBdWLvuhnv/LbTCPn+40U0Ly+g2TfwagcWIl0UdDuOEptHoPuIY0I59sn34Yb7K/+arQJWMpcDbdZ57bd8VEwA4HFnvWqrfgep3HmJqeF2C8CrOfQIKqRPwnkGvU8HOuQ9nTlBYKtbhc9KuOimGcpsuezaZsla+17LPiMR1xyWXVqT2TGrc9BDJMCoOcPJJ5UvWtGZ4r93Vn/mMQf; 4:mn2Xtiqf8PMZeHEjoa9Z4NMXC6JHitouP9ANhJggMR3ZsDC+4ojxkHYj0rtnJcfItbnBqY3VXzTyHZw+ZDfNuQKOR2wFYUwwEtdaLlhTKDG4XRBDfZkswsgYA7o7Yvy1vCDli9nMZw7SyP6kS1btFVjt7ooLH4QFrV38Kxnp1DZOoEI6pPa30omOKCEnuM5mtQ3sGyASvZZrdyIq+OvYPMyRTZ9pTHc5RPMi6sxndUZDnbcnEVUH1/QRyOgTtxi+lVkCJVbEM0JVOi0R89MtgkXsCAX+p276RKGQoEXGzb0= CY1PR0501MB1836: X-MS-Exchange-Organization-RulesExecuted 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:CY1PR0501MB1836; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1836; X-Forefront-PRVS: 0642A5E7BA X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(6009001)(69234005)(377454003)(479174004)(2473001)(5423002)(122386002)(77156002)(19580395003)(86362001)(83716003)(66066001)(46406003)(19580405001)(230783001)(50226001)(50466002)(450100001)(62966003)(47776003)(97756001)(92566002)(57306001)(33656002)(87976001)(77096005)(5001960100002)(50986999)(76176999)(42186005)(107886002)(40100003)(46102003)(23726002)(110136002)(82746002)(36756003)(15975445007)(189998001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1836; H:[172.29.64.139]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR0501MB1836; 23:z/l5fMh5NXjhiUE9i5mRlfOn3aT/FdAJmoJDvYr?= =?us-ascii?Q?dw6dXl3kR375OlUUUdtWZ8jvveqnfsOdSQgoIWZChTjuRM+TX0CUK0H9NlON?= =?us-ascii?Q?cHEaH+Q4RMFqoLMuWbfYGJDrsb4thyBqTWf5H7KuGVzAPcMSCau5r0pCpuZZ?= =?us-ascii?Q?pjO8/lSbnxqRRhYRyw1/3+DBxGXyxxafCEHsuZrqFOmBKCYS6dR3Ej+cNoBz?= =?us-ascii?Q?5MA6ypF0F3+lEeD++CP2IYBKa0D0wEQxA0ua6JxYZDHonK1uVa16oipLilYq?= =?us-ascii?Q?1Tyh+PfYHZrp4P+li0N/BfXLKipp4OGJw1v4tNunMp8WPHncl3LEs04vAyaw?= =?us-ascii?Q?G85g3boHSxodpB1C6sqX3h1Cui10n5U5pGnWjXFDZSZc1PhghWR+D6mqx79H?= =?us-ascii?Q?lNC+1ch7wMTS/NTP6k0Jc/zx4DPrzhjQuTJ+2EmAm5ynyqDtSuNwnvnBEvdG?= =?us-ascii?Q?8fem5bSj8FOWgk1ERqV7ygfqYELi4sgQF9sBZ+XOb59ozlNazWg94ZSOVmrP?= =?us-ascii?Q?Qp0cNAN+1WxcXmPntvfYjILBuKma2G7eOO9BiYlKMLK7b4H2CaLEr4Skjkts?= =?us-ascii?Q?jfqlC4MxBJduIeECml3xsxv94Zo9pUB8oknjGZr1s5OD9C1xJ2dNmS/ZyhpX?= =?us-ascii?Q?ZyixC0rpmDaDMHonwqD7smwLjqI2pprY1IBDpWvF1vg5P6vZBKdEUz92Dq8Y?= =?us-ascii?Q?ihV8No9xn9C++6ZTjbzQuWS4l0fWjIBoK28/fqv1y0HM+KFJ9hCR1ScLBjTd?= =?us-ascii?Q?o3kQh3jfokghD0NAmURlzU7+OdzIJnyx9M0eoX+kucyFATzd/67tnylF3/di?= =?us-ascii?Q?+AhYv46nYyHOcGhYEf6szC7VjMgsW0kt9vlpOvlbFQIf0EsmyiC/AfWPgPf4?= =?us-ascii?Q?R6hvFQqKJ5HWy2yg7ucr2dgb2QBmyOqa1lJZvIsipQrYRD/ly+/l43cTZpyE?= =?us-ascii?Q?JPtyv/s/TxdKwJqrZoc585QtworP1SjWG5Og18Em1JZIbHDGIqsU8qT6DFkF?= =?us-ascii?Q?1uqGpSYlE0itz5BvcJeM2X2NnCXacX8t/zvY8+uZ2vuuTcma38Y9AAQv74MO?= =?us-ascii?Q?roghhJIk=3D?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1836; 5:U5U5DB7mILdR5q+1t/Ztlv79dMrkDQoUT5e+AOgJ/yE/9IcYqdkSMQzIcODJVKXZT7zo4ln0hpcefhxYAnvqSaQFzICsykUbKUTSk0yPzbzm1SL4cI7jyp+u3/9mML4xP1xXIQQS/h7Km5BptxJgEw==; 24:ewoXTAtyzZKEAaxw+nWGJuDEYub5Q4/vaBFTJQsJvltPgXXjm4c9AOwAaPVdMFhrVLphygoxibRfgp4nQYdWOnzxgwhwOm/om9JSlnZ1Ark=; 20:W1nbilpwD3vcArnz/XT470gyS11DB7iOQ+rZgAnJPxUifkJTCKXrd2pGU4fkz3i8sYcrzAgdioY34Lr27/4dWA== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Jul 2015 02:55:48.7653 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1836 Archived-At: Subject: [Idr] Fwd: [GROW] WGLC: draft-ietf-grow-bmp - ENDS: 8/7/2015 (aug 7 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: Sun, 19 Jul 2015 02:55:52 -0000 FYI, WGLC for BMP in GROW to begin shortly. Regards, --John > Begin forwarded message: >=20 > From: Christopher Morrow > Subject: [GROW] WGLC: draft-ietf-grow-bmp - ENDS: 8/7/2015 (aug 7 = 2015) > Date: July 19, 2015 at 1:05:26 AM GMT+2 > To: "grow-ads@tools.ietf.org" , = "grow-chairs@ietf.org" , "grow@ietf.org = grow@ietf.org" , draft-ietf-grow-bmp@tools.ietf.org >=20 > Howdy Grow folk, > I think at the meeting in 48hrs time Jon Scudder plans to ask (again) > for WGLC for: draft-ietf-grow-bmp > (https://www.ietf.org/internet-drafts/draft-ietf-grow-bmp-09.txt) >=20 > Let's all have read through ,decide if we're happy and get this > pushed along to the IESG for review/pulication. This is the abstract > of the document: >=20 > "This document defines a protocol, BMP, that can be used to monitor > BGP sessions. BMP is intended to provide a more convenient = interface > for obtaining route views for research purpose than the screen- > scraping approach in common use today. The design goals are to keep > BMP simple, useful, easily implemented, and minimally service- > affecting. BMP is not suitable for use as a routing protocol." >=20 > Thanks! > -chris morrow > (co-chair 1 or 2) >=20 > _______________________________________________ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow From nobody Sat Jul 18 21:48: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 18B4A1A6F20 for ; Sat, 18 Jul 2015 21:48: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 RL310YohlOsj for ; Sat, 18 Jul 2015 21:48:07 -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 B03D21A1A6D for ; Sat, 18 Jul 2015 21:48:06 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1ZGgWC-0000Cf-R6; Sun, 19 Jul 2015 04:48:05 +0000 Date: Sun, 19 Jul 2015 06:48:03 +0200 Message-ID: From: Randy Bush To: Susan Hares In-Reply-To: <005401d0c1ca$f9cb4ff0$ed61efd0$@ndzh.com> References: <005401d0c1ca$f9cb4ff0$ed61efd0$@ndzh.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 Subject: Re: [Idr] Early allocation WG Review Call draft-ietf (7/19 to 8/2) - WG LC X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2015 04:48:08 -0000 > The authors should to this Early Adoption WG LC to the list to indicate if > they know of any IPR. i am not aware of ipr relating to this draft randy From nobody Sat Jul 18 22:36: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 0E7361A8775 for ; Sat, 18 Jul 2015 22:36:30 -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 qcrCGRwUFkm7 for ; Sat, 18 Jul 2015 22:36:27 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (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 7ECD71A8769 for ; Sat, 18 Jul 2015 22:36:27 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=31.133.137.143; From: "Susan Hares" To: "'idr wg list'" Date: Sun, 19 Jul 2015 01:36:16 -0400 Message-ID: <007001d0c1e4$d68a8190$839f84b0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0071_01D0C1C3.4F7A6830" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdDB1sY7ary6ok+VToCMege+YMSMwA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: nbakker@akamai.com, nick@inex.ie, draft-ietf-idr-ix-bgp-route-server@tools.ietf.org, elisa@bigwaveit.org, robert@raszuk.net Subject: [Idr] 2 week adoption call for draft-jasinska-ix-bgp-route-server-implementation (7/19 to 8/2) 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, 19 Jul 2015 05:36:30 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0071_01D0C1C3.4F7A6830 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This begins a 2 week adoption call for draft-jasinka-ix-bgp-route-server-implementations (7/19 to 8/2). Please review this route server report and comment on the accuracy of the report. Please note that past IDR implementation reports will adopted, but not forwarded to the IESG. The reports also exist on the IDR wiki at: http://trac.tools.ietf.org/wg/idr/trac/wiki Click on the implementation reports - and you will find the implementation reports for this draft. If you know if any errors, please annotate the errors with your name and indicate why the report is in error. The authors of the base draft (draft-ietf-idr-ix-bgp-route-server-07) and the author of the implementation report are requested to indicate whether they know of any IPR for this draft. Sue Hares ------=_NextPart_000_0071_01D0C1C3.4F7A6830 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This = begins a 2 week adoption call for = draft-jasinka-ix-bgp-route-server-implementations (7/19 to 8/2). =  Please review this route  server report and comment on the = accuracy of the report.  Please note that past IDR implementation = reports will adopted, but not forwarded to the IESG. =  

 

The reports also exist on the IDR wiki at: =

 

http://trac.tools.ie= tf.org/wg/idr/trac/wiki

 

Click on the = implementation reports – and you will find the implementation = reports for this draft. 

If you = know if any errors, please annotate the errors with your name and = indicate why the report is in error.

 

The authors = of the base draft (draft-ietf-idr-ix-bgp-route-server-07) and the author = of the implementation report are requested to indicate whether they know = of any IPR for this draft.

 

Sue Hares =

------=_NextPart_000_0071_01D0C1C3.4F7A6830-- From nobody Sun Jul 19 03:45: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 E91241AC40A for ; Sun, 19 Jul 2015 03:45:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.161 X-Spam-Level: X-Spam-Status: No, score=-1.161 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, 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 XKF7XsTIVOjq for ; Sun, 19 Jul 2015 03:45:35 -0700 (PDT) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 68E411AC3FB for ; Sun, 19 Jul 2015 03:45:35 -0700 (PDT) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) for idr@ietf.org with esmtp (envelope-from ) id <1ZGm69-002Arz-Pz>; Sun, 19 Jul 2015 12:45:33 +0200 Received: from dhcp-9c64.meeting.ietf.org ([31.133.156.100] helo=mw-PC.meeting.ietf.org) by inpost2.zedat.fu-berlin.de (Exim 4.85) for idr@ietf.org with esmtpsa (envelope-from ) id <1ZGm69-001z6F-Gd>; Sun, 19 Jul 2015 12:45:33 +0200 Date: Sun, 19 Jul 2015 12:42:40 +0200 From: Matthias Waehlisch To: idr wg list In-Reply-To: Message-ID: References: , User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) X-X-Sender: waehl@mail.zedat.fu-berlin.de MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="269854628-17335-1437302343=:3980" Content-ID: X-Originating-IP: 31.133.156.100 Archived-At: Subject: Re: [Idr] 2 week adoption call for - draft-sriram-idr-route-leak-detection-mitigation-00 (6/25 to 7/9/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: Sun, 19 Jul 2015 10:45:37 -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. --269854628-17335-1437302343=:3980 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-7 Content-Transfer-Encoding: 8BIT Content-ID: Hi, +1. Sorry for the delay matthias > ----------------------------------------- > > [Apologies for missing the deadline] > > > IDR Working group: > > > > > > > > This begins a 2 week adoption call for > > > > draft-sriram-idr-route-leak-detection-mitigation-00 > > > > > > I support adoption of this draft as a WG document. > > > > > a) Who will desire to read this informational draft now and in 1 year from now>? > > > > I suspect it will take some time to develop and implement a solution. > > > b) Is this informational draft¢s description of route-leak types and mitigated by the origin validation [RFC 6811] and BGPSEC path validation > > > > [draft-ietf-sidr-bgpsec-protocol] are correct? > > > > Yes, there is a companion document in the GROW WG: > draft-ietf-grow-route-leak-problem-definition, containing more detailed > discussion of the definition of the problem. > > > c) It is necessary to solve the route-leak problems not covered by origin validation and BGPSEC path validation? > > > > Yes. > > > d) Do you think the solution suggested for the extension of BGPSEC will fix these unsolved route-leak problems? > > > > I hope. > > Regards, > > Andrei > -- Matthias Waehlisch . Freie Universitaet Berlin, Inst. fuer Informatik, AG CST . Takustr. 9, D-14195 Berlin, Germany .. mailto:waehlisch@ieee.org .. http://www.inf.fu-berlin.de/~waehl :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net --269854628-17335-1437302343=:3980-- From nobody Sun Jul 19 13:02: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 C90281A8860 for ; Sun, 19 Jul 2015 13:02:04 -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, 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 3fGOJD2HYx51 for ; Sun, 19 Jul 2015 13:02:03 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF7861A8853 for ; Sun, 19 Jul 2015 13:02:02 -0700 (PDT) X-Envelope-To: idr@ietf.org Received: from cupcake.foobar.org (089-101-070076.ntlworld.ie [89.101.70.76] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.1/8.14.9) with ESMTPSA id t6JK1hKJ030455 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 19 Jul 2015 21:01:43 +0100 (IST) (envelope-from nick@inex.ie) X-Authentication-Warning: cheesecake.netability.ie: Host 089-101-070076.ntlworld.ie [89.101.70.76] (may be forged) claimed to be cupcake.foobar.org Message-ID: <55AC0227.5030202@inex.ie> Date: Sun, 19 Jul 2015 21:01:43 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Susan Hares , "'idr wg list'" References: <007001d0c1e4$d68a8190$839f84b0$@ndzh.com> In-Reply-To: <007001d0c1e4$d68a8190$839f84b0$@ndzh.com> X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: nbakker@akamai.com, draft-ietf-idr-ix-bgp-route-server@tools.ietf.org, elisa@bigwaveit.org, robert@raszuk.net Subject: Re: [Idr] 2 week adoption call for draft-jasinska-ix-bgp-route-server-implementation (7/19 to 8/2) 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, 19 Jul 2015 20:02:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 19/07/2015 06:36, Susan Hares wrote: > The authors of the base draft (draft-ietf-idr-ix-bgp-route-server-07) > and the author of the implementation report are requested to indicate > whether they know of any IPR for this draft. I'm not aware of any IPR concerning this draft or its contents. Nick -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVrAInAAoJECOxk/MZgyq9ar0IAJk/G1nk0yZDPSMY/+hM9yY1 hGQEZk/vvkMeV6qBjdK1niEFsX9TlHQK0mrT4eKa46qJskN/0EiDLf4hYSe5dig1 wAUm/uWA6GmgKw1lpxKzNbhO7VCxjfbjCS+wkySVXCKd/BeAknx8iR4W3kVeTzJY dgqTbBxTbNSbzFCc5roiODbbZ3gvzrh402kqGcZ/ASy+6CjBOJh735UrQbKb3nPP vlBQOJae5P0bIy9AEE/guXLILGya5IY4AjQGLY1MKxQX/l0foO8v8y2AWvNld12v +5d+DNRdwKY/Ynzxerf/+HWvVPtZIBBvfXn6RdU5w1TW4UR82tXFvItr3KeOi9M= =obbf -----END PGP SIGNATURE----- From nobody Sun Jul 19 13:38: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 C85581B2BCB for ; Sun, 19 Jul 2015 13:38:26 -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 Gk8k2AYwxAQs for ; Sun, 19 Jul 2015 13:38:25 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (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 2711A1B2C03 for ; Sun, 19 Jul 2015 13:38:24 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so10601157wib.1 for ; Sun, 19 Jul 2015 13:38:22 -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=eMukVpUz4MLaqeVq4kervlyuEjn5JdDT8CEfZhqPQVo=; b=byaDP6vfIQfUPgIoS60i121x2zklAsz0X4HoWMkkZlThMf53FEuC3jc0kltiJ6mBIz bDiPiv0IRAIgI46WybCVgjEJFVKjVs9V6GP5zqYoHoPzFgCvOEd8oHNi5NSc1y8Zc9RJ R4qNweC82GxE7qWee6vBc7vgIv1kazwqm3JZqm3My1uDYjY4j64Hmbg4mKEO5pMBc/+W BPrAcFGfvuMViOc0HdSa9dhcA2KwGvsG+jyjGFgoZ51Sy1glAjFnb4mNG+9FMBcnGRIf wEcsMkpnmHUZxTg2llOuLSbf4bzRNznsCwCuyzACf6vQomO0CQlgtvAb0ioop8GQXbW+ J2SQ== MIME-Version: 1.0 X-Received: by 10.180.186.35 with SMTP id fh3mr15146363wic.7.1437338302843; Sun, 19 Jul 2015 13:38:22 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.194.95.168 with HTTP; Sun, 19 Jul 2015 13:38:22 -0700 (PDT) In-Reply-To: <007001d0c1e4$d68a8190$839f84b0$@ndzh.com> References: <007001d0c1e4$d68a8190$839f84b0$@ndzh.com> Date: Sun, 19 Jul 2015 22:38:22 +0200 X-Google-Sender-Auth: pwJS3Rg9J79esuGGgvHjQMnpHdw Message-ID: From: Robert Raszuk To: Susan Hares Content-Type: multipart/alternative; boundary=001a11c26120f6917a051b40664a Archived-At: Cc: idr wg list , Nick Hilliard , draft-ietf-idr-ix-bgp-route-server@tools.ietf.org, elisa@bigwaveit.org, nbakker@akamai.com Subject: Re: [Idr] 2 week adoption call for draft-jasinska-ix-bgp-route-server-implementation (7/19 to 8/2) 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, 19 Jul 2015 20:38:26 -0000 --001a11c26120f6917a051b40664a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sue, I am not aware of any IPR related to draft-ietf-idr-ix-bgp-route-server. Thx, R. On Sun, Jul 19, 2015 at 7:36 AM, Susan Hares wrote: > This begins a 2 week adoption call for > draft-jasinka-ix-bgp-route-server-implementations (7/19 to 8/2). Please > review this route server report and comment on the accuracy of the > report. Please note that past IDR implementation reports will adopted, b= ut > not forwarded to the IESG. > > > > The reports also exist on the IDR wiki at: > > > > http://trac.tools.ietf.org/wg/idr/trac/wiki > > > > Click on the implementation reports =E2=80=93 and you will find the imple= mentation > reports for this draft. > > If you know if any errors, please annotate the errors with your name and > indicate why the report is in error. > > > > The authors of the base draft (draft-ietf-idr-ix-bgp-route-server-07) and > the author of the implementation report are requested to indicate whether > they know of any IPR for this draft. > > > > Sue Hares > --001a11c26120f6917a051b40664a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sue,

=
I am not aware of any IPR related to=C2=A0draft-ietf-id= r-ix-bgp-route-server.

Thx,
R.<= /div>

On Sun= , Jul 19, 2015 at 7:36 AM, Susan Hares <shares@ndzh.com> wrote= :

This begins a 2 week adoption call = for draft-jasinka-ix-bgp-route-server-implementations (7/19 to 8/2).=C2=A0 = Please review this route=C2=A0 server report and comment on the accuracy of= the report.=C2=A0 Please note that past IDR implementation reports will ad= opted, but not forwarded to the IESG. =C2=A0

=C2=A0

The reports also e= xist on the IDR wiki at:

= =C2=A0

http://trac.tools.ietf.org/wg/idr/tr= ac/wiki

=C2=A0

Click on the implementation reports =E2=80=93 and y= ou will find the implementation reports for this draft.=C2=A0

If you know if any errors, please annotate the = errors with your name and indicate why the report is in error.

=C2=A0

The authors of the base draft (draft-ietf-idr-ix-bgp-route-server-07) and = the author of the implementation report are requested to indicate whether t= hey know of any IPR for this draft.

=C2=A0

Sue Hares


--001a11c26120f6917a051b40664a-- From nobody Sun Jul 19 14:17: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 90E6B1B2BCB for ; Sun, 19 Jul 2015 13:36:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 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_LOW=-0.7, 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 0OwkxO-NxMob for ; Sun, 19 Jul 2015 13:36:34 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id B6E8D1B2C03 for ; Sun, 19 Jul 2015 13:36:32 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 5253F74000B; Sun, 19 Jul 2015 20:36:32 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 3B62E740008; Sun, 19 Jul 2015 20:36:32 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=akamai.com; s=a1; t=1437338192; bh=hLJEMa7K+0eJTytuTZL6DFXvVnTwHgm/G/zjW/aY0ME=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=QQhDy5U0J4g3iP/6IMTRM+Nn+ruF7HvMCWTAvFoLnVp8SeaUBVCo/IL2UgEX2xhIk Wt4aoFm3f20nvvAN7c4uLv7bg6nWm1X7RW7ES4Wzdp16c7EePSpmyDSLiHcaDRP5n6 E5GAC949qEC0a9KWJH3bgK4sxQd/s5fIFW2sjhj8= Received: from email.msg.corp.akamai.com (ustx2ex-cas4.msg.corp.akamai.com [172.27.25.33]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 358A198088; Sun, 19 Jul 2015 20:36:32 +0000 (GMT) Received: from USTX2EX-DAG1MB4.msg.corp.akamai.com (172.27.27.104) by ustx2ex-dag1mb2.msg.corp.akamai.com (172.27.27.102) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Sun, 19 Jul 2015 15:36:31 -0500 Received: from USTX2EX-DAG1MB4.msg.corp.akamai.com ([172.27.6.134]) by ustx2ex-dag1mb4.msg.corp.akamai.com ([172.27.6.134]) with mapi id 15.00.1076.000; Sun, 19 Jul 2015 15:36:31 -0500 From: "Bakker, Niels" To: Nick Hilliard Thread-Topic: 2 week adoption call for draft-jasinska-ix-bgp-route-server-implementation (7/19 to 8/2) Thread-Index: AQHQwl3GfPSxFBE6m02JKT9f4Ehq3p3jQHVL Date: Sun, 19 Jul 2015 20:36:31 +0000 Message-ID: <52BA2437-4D33-4D93-8DA1-8BE6390EE9DA@akamai.com> References: <007001d0c1e4$d68a8190$839f84b0$@ndzh.com>, <55AC0227.5030202@inex.ie> In-Reply-To: <55AC0227.5030202@inex.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Sun, 19 Jul 2015 14:17:52 -0700 Cc: idr wg list , "robert@raszuk.net" , "draft-ietf-idr-ix-bgp-route-server@tools.ietf.org" , "elisa@bigwaveit.org" , Susan Hares Subject: Re: [Idr] 2 week adoption call for draft-jasinska-ix-bgp-route-server-implementation (7/19 to 8/2) 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, 19 Jul 2015 20:36:35 -0000 > On 19 jul. 2015, at 22:02, Nick Hilliard wrote: >=20 >> On 19/07/2015 06:36, Susan Hares wrote: >> The authors of the base draft (draft-ietf-idr-ix-bgp-route-server-07) >> and the author of the implementation report are requested to indicate >> whether they know of any IPR for this draft. >=20 > I'm not aware of any IPR concerning this draft or its contents. Likewise. Regards, Niels From nobody Sun Jul 19 18:24: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 B39071B2EF3 for ; Sun, 19 Jul 2015 18:24:32 -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 ZzcLXsc52mPL for ; Sun, 19 Jul 2015 18:24:31 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (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 65FDF1A883C for ; Sun, 19 Jul 2015 18:24:31 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=31.133.143.63; From: "Susan Hares" To: "'Bakker, Niels'" , "'Nick Hilliard'" References: <007001d0c1e4$d68a8190$839f84b0$@ndzh.com>, <55AC0227.5030202@inex.ie> <52BA2437-4D33-4D93-8DA1-8BE6390EE9DA@akamai.com> In-Reply-To: <52BA2437-4D33-4D93-8DA1-8BE6390EE9DA@akamai.com> Date: Sun, 19 Jul 2015 21:24:18 -0400 Message-ID: <00ac01d0c28a$cf4cb2d0$6de61870$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJUzM2M8XtJTCyFkroSuzNGqZxjigIAvKaJAQy+dJqcww/PgA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'idr wg list' , draft-ietf-idr-ix-bgp-route-server@tools.ietf.org, elisa@bigwaveit.org, robert@raszuk.net Subject: Re: [Idr] 2 week adoption call for draft-jasinska-ix-bgp-route-server-implementation (7/19 to 8/2) 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 Jul 2015 01:24:32 -0000 Niels, Nick, Elisa, and Robert: want to thank each of your for providing the IPR statements so quickly. Sue -----Original Message----- From: Bakker, Niels [mailto:nbakker@akamai.com] Sent: Sunday, July 19, 2015 4:37 PM To: Nick Hilliard Cc: Susan Hares; idr wg list; draft-ietf-idr-ix-bgp-route-server@tools.ietf.org; elisa@bigwaveit.org; robert@raszuk.net Subject: Re: 2 week adoption call for draft-jasinska-ix-bgp-route-server-implementation (7/19 to 8/2) > On 19 jul. 2015, at 22:02, Nick Hilliard wrote: > >> On 19/07/2015 06:36, Susan Hares wrote: >> The authors of the base draft (draft-ietf-idr-ix-bgp-route-server-07) >> and the author of the implementation report are requested to indicate >> whether they know of any IPR for this draft. > > I'm not aware of any IPR concerning this draft or its contents. Likewise. Regards, Niels From nobody Sun Jul 19 19:32:29 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 0C9861ACF08 for ; Sun, 19 Jul 2015 19:32:28 -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 LtfJ12KfWnjN for ; Sun, 19 Jul 2015 19:32:27 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (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 CB5CD1ACE77 for ; Sun, 19 Jul 2015 19:32:26 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=31.133.143.63; From: "Susan Hares" To: "'idr wg list'" Date: Sun, 19 Jul 2015 22:32:21 -0400 Message-ID: <00bd01d0c294$4f215fc0$ed641f40$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00BE_01D0C272.C80FBFC0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdDClDbjvnswpZcmTJu5MY8Tyw2VFg== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [Idr] draft-sriram-idr-route-leak-detection-mitigation - WG adopted 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 Jul 2015 02:32:28 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00BE_01D0C272.C80FBFC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This draft has been adopted as a WG draft. The authors should submit this as draft-ietf-idr-route-lead-detection-mitigation-00.txt. Sue Hares ------=_NextPart_000_00BE_01D0C272.C80FBFC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This draft = has been adopted as a WG draft. 

 

The authors = should submit this as = draft-ietf-idr-route-lead-detection-mitigation-00.txt.

 

Sue Hares =

 

------=_NextPart_000_00BE_01D0C272.C80FBFC0-- From nobody Mon Jul 20 07:22: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 1A5091A897B; Mon, 20 Jul 2015 07:22:11 -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 G9K2PIjj8C3q; Mon, 20 Jul 2015 07:22:10 -0700 (PDT) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::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 D5DBE1A8974; Mon, 20 Jul 2015 07:22:09 -0700 (PDT) Received: by ykax123 with SMTP id x123so140041961yka.1; Mon, 20 Jul 2015 07:22:09 -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=ZS8uBIy39oIHPOnxSQyTg3xqMquaYNtX6h63IWp7mqk=; b=UTJknqCSMcqVOb8jZiMGS0hucT5zeS5Ksm0HRgJxxn7USUId6U9xf1MOmzJG43FeA8 8G43FlOY6lKndkfEgU0q9Ec7o8p8DcWjGf++Cn81zEl46Q/nbx9QGE4RGMuXSMIRY4BO RnPbS04Yo8puCtVgMQ6tPA5zcsAKGKoD6Kmt1zYasFUR9nuKlPvO3ELfBsEP2o9HsCvc N3abJr1BE7G5S7Wbj1oHKR6Lt8SNWGofeg3jP7YB31xWRSwLpbSoT/+hX7WSCG18M1b5 Fix02ahT5W7gAitoEMHg50HZsBGkMgQClEq5JafWSPiqJAwrw7vLo1ERAJJHIdhyBPuB +eWw== MIME-Version: 1.0 X-Received: by 10.13.236.5 with SMTP id v5mr28516053ywe.138.1437402129199; Mon, 20 Jul 2015 07:22:09 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.13.228.196 with HTTP; Mon, 20 Jul 2015 07:22:09 -0700 (PDT) In-Reply-To: References: <005901d0b283$ea07bd20$be173760$@ndzh.com> Date: Mon, 20 Jul 2015 10:22:09 -0400 X-Google-Sender-Auth: _wHo3cPH6zn29CLZRF5n8Pnr8eM Message-ID: From: Christopher Morrow To: "Sriram, Kotikalapudi" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: idr wg list , "sidr wg list \(sidr@ietf.org\)" Subject: Re: [Idr] Route Leaks and solutions 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 Jul 2015 14:22:11 -0000 I think I see the current plan as a it challenging to depend upon... If the RLP bit is dependent upon ops folks getting the right config-bit set for each customer we would want that to be as much automated as possible so there would be the least chance for 'forgot to set the bit' or 'set bit incorrectly'. I'm worried that I can't tell reliably what the bit was 2 as-hops away, did they mean 'customer' ? or was that a mistake? Did someone change it mid-path to me? Did the implementation of their vendor gear change/set the wrong attribute value? There seem to be a bunch of uncertainties with this, in my mind. I guess that with bgpsec signing this attribute at least 'joe really meant that jim was his customer', and you can't change the value on a bgpsec path. If we want that, I think having the attribute where it can get changed (not-bgpsec secured paths) is a real problem, or opens up some pretty large problems... From nobody Mon Jul 20 08:25: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 1801A1A8ADC for ; Mon, 20 Jul 2015 08:25:09 -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 rvKTWo9UX1RJ for ; Mon, 20 Jul 2015 08:25:07 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0134.outbound.protection.outlook.com [65.55.169.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BED8C1A89C4 for ; Mon, 20 Jul 2015 08:23:24 -0700 (PDT) Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none; Received: from [172.29.32.144] (66.129.241.12) by BY1PR0501MB1096.namprd05.prod.outlook.com (10.160.103.142) with Microsoft SMTP Server (TLS) id 15.1.213.14; Mon, 20 Jul 2015 15:23:22 +0000 Message-ID: <55AD1265.7090901@juniper.net> Date: Mon, 20 Jul 2015 11:23:17 -0400 From: Eric C Rosen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: IDR WG Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.12] X-ClientProxiedBy: BY1PR0201CA0042.namprd02.prod.outlook.com (25.160.191.180) To BY1PR0501MB1096.namprd05.prod.outlook.com (25.160.103.142) X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1096; 2:wrdoCE2U/g1VG58b/5cpIlJIu+JxJCsiWQtrax/MxDz75aAWPCUBv4PwNRhVP4US; 3:FWDTyh7wYDRKLP7mzNHsM+cp2gO1uF6EkRCT10TSswHHkrRzQiZxJ0Da8Zz6sr106BUqMxbLvc2Yo/olwP/B8OqrmGTqIq7BdZYjALJQdYSW7ag32Ooruf7TFoj6GPH8Nxq2SsxsFviud1uVrPZfeg==; 25:4DIOfYJsy/OaH9YEf4v1lnYSBOHTNdM3WO0zvH4wjhnEsLV6e+RzpkJffS+sIQCHGCrzPAEYjjxzgOb7AZ38yvjjbp1SuNO7NHcdYDmCYI1iMltrNj5MvOGvidg8VQBXVgjKoDBkUY3aQI52uYdjfPys6b6c8iTjDsnNKVlZIyiQAeMXnjUTP2iS0qMJXBHj/D04BgJsJuq47C90stXXZ0rSefJ6CaZ+IJetVNXnO1xJj0ggLFL/v7lX2uqbVD3dcryvR8NYsdk08EBSk6SvpQ== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1096; X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1096; 20:sh3jBPM6+EKeTbtywHh9/33qUWfFvXz7jdgIVN9hMc/05uFXmUNHqubSe1o3dkNiTJ3X5oj8pNmBEYiEd6vVM3UnnIQmB/8pkZBJ0Flnrx5H7znHouVvDXZf7rb2L9wayor/zqOvsCIWhj60+nSciQflmvswTksRnI5+f/dTS+XSR/+GQ1NRkiA4ed0ZlsE4uNlfrqJKgPMCMOd19icPFvU2C+doAimJ8qrF9eTIaJih55p9zPUNfewLd8egW/Jio0Gh6ZAPzBgNWjO0GxyOj2oUK0ScSRUGETHmM4+22SNlOoTUfjmVlxxSfrjXQiQiFlTnORPk7I3ev6O31yX3k0zyn8SIDrUkmzgYH4cEIPfTYZWn7SHjRRFLcJzH1A1oNT2EOuYjJXBIPALFiWBktKBjBYAMcvFOvZLd+GiCp1cX24lJxBWrCTsJmVwaphhcM56wNVOFbWdcsFetohSaJoxp+lqBKKpZjWyMeoPVwvQrTKrcBUH9qvOagAWs1XJ0; 4:ugruh6hDDS2upxQbyBsthmzvBmvfeqFrHZ/4g3gADvkeyZSRAs3wcEmFS/W4NeJhvb85KjeemVMs1tbylFkBW8J028jtFz6shuuzvYnFY4o3nZ9CBrNWCYbE+LgylHDALpfYtqE8OrdnFZMdWEDwNyPJoiDRijwbWlgyYMc7mhANo7RBFUeHL7fAhq0s+4uOvs0GXoh0SSbLb5v4P4e2VtQwX6u2vO8rRE6bg+Z4VT5RZ7XgiBDtVXf2pyEDRwhls2lJQW60Vea2G6+CiWkCmbqF175h+hp0yWOD91laC80= BY1PR0501MB1096: X-MS-Exchange-Organization-RulesExecuted 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:BY1PR0501MB1096; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1096; X-Forefront-PRVS: 0643BDA83C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(6049001)(37854004)(52034003)(50986999)(87266999)(33656002)(83506001)(23676002)(66066001)(65816999)(42186005)(86362001)(65956001)(54356999)(87976001)(229853001)(50466002)(65806001)(47776003)(450100001)(77096005)(40100003)(92566002)(36756003)(77156002)(46102003)(5001960100002)(107886002)(122386002)(5001920100001)(62966003)(110136002)(59896002)(80316001)(4001350100001)(189998001)(230783001)(4001430100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1096; H:[172.29.32.144]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCWTFQUjA1MDFNQjEwOTY7MjM6Y0IwN0FYVlFSYTFmOXI2WGloT3JZNzNi?= =?utf-8?B?aW9LczQ4NklJV0tvQ0pJRXFEOVlhWVV0c1ZpUG5jZWlMencrQnFSNnFIR3o4?= =?utf-8?B?L2YzQlhTUmF1TzJNVHR1WHlscFJ1enRIbTNudU84bzBkK0Nmc2dwZGFKQ1g3?= =?utf-8?B?azlDdGZiekNPd2FQaEtuck8wWVB4OWppWFZrbnZlVG5PMnFDWFZaR0kwYi9y?= =?utf-8?B?ei94WHkrcll4RFVaNnRmaExVYUdQZjJkWHpYZVZXUXgzMlZOb1VuNHdoYXk4?= =?utf-8?B?SWZBYlB1c2psVy81QllOM3lTZDZUWkw0cFZibUlrSFh1RGFscDRxRGVKdWgr?= =?utf-8?B?cllWV01sd3dwaU03RUNQaHpKaXFxSmg1WVhLTkoyY2ljSk13REsyYm14bDI4?= =?utf-8?B?K0hqWXFjWHRWSE9NOXpKZWtsTXNBQzBwNFVTTFhEelpLMnJmWlhXeVFURkdw?= =?utf-8?B?cXFOMHFwOU5MaE1ydFQ4TG5QM3hqSHVRUzB2dWErUkNoRGJXeVRjcjFkellZ?= =?utf-8?B?R0dlZ0QrMGxBOTNFTktSZlpQSmU0WUNKeTJ4Y1QxRG9oSHM1allMQ1hNQWY5?= =?utf-8?B?eFRsUUo5Z0ViZnZVZWJwYm1EdjgrK3Y4Slc1Z1BLMnFGRGNhNFF0UENLNTJJ?= =?utf-8?B?Y1NBd0tsbmFOZ1JJeVdNUk41L2UzTUVBT01aWFNuT2RDUmUrNHdRUHAyYzF4?= =?utf-8?B?akZBdWJ4UWVHKzU3N3JsZU5JUHl0OEYwZGlRck56MXBvRkZuWlRuNHlJSU5r?= =?utf-8?B?Y3dKZ2FkNDlkb1Vqa2FLTGRTWnk4RHZyWU5pSWdqQ3czWnNKUlg2eXBqdWtB?= =?utf-8?B?dzFERDhCa3lldDFmVDFnK0ZMS01yOHE4SzdiSVNhdVZGSjhzbVJqMFFGUTRK?= =?utf-8?B?dk1oYXhxVjdBUlE0eXBUYThqTUN1RmtpYmNQM0RYbCsvRWhyS0FLUVk5aXo0?= =?utf-8?B?eHBtOGdiZGhkVTRKNzRTeW5kak5UcXBEcnI2eVU0Uy8zQ1ZlTERyRDhwbU9o?= =?utf-8?B?MzMyWUFhd3pMcXQ4ejlyQkw1eHdLRkJ5ZktWOENvTEhtOEVFaEg5b0V5V2R2?= =?utf-8?B?Zk9uT0o1VG14TlpKZTQ3L2xiV1JFNEFHQlVJaDBYN3JLdnJidHF3UGxlL25I?= =?utf-8?B?Tm0zUWg1cmJDdHFlRDlrVjU2czZjLzlzOUpzYnNidmhVdko2Sm1tcFRQQ1ZZ?= =?utf-8?B?ZnNOY1ZzUkUzTXdPamYyY0JtWDdQRmlyaHAvcVNYNEtGVXVIMlFRUWoxU21N?= =?utf-8?B?N0J2ZUVPV2xXWHJKaEdhaSthZVduaHhka0s3L281Tkh6aURFZ1JyNm9DTGZa?= =?utf-8?B?N1ZaejNXdjhBbDdCaytha1VqMkxJK21RUHpTaWQ2YUpmc1FwWnZGa3ppSHUv?= =?utf-8?B?bDZGcXk4YndQckFkQWF3ZVpmNDhHS2RzaXNRNncyWkE9PQ==?= X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1096; 5:ymSQPth2gGpMemvGbCkMp+LVgLR7A3JqjzBf0X5vp9Sr7WCaX1TNDBGA8D/co42JlTuvNJou2imp0v3tHizrWdCkxk1K6YGdrmyFdIu0bXwyVs+vLYHBJJdL1n0ZKmKzbALfsePMEx8bBWhR6rg/ig==; 24:dUU2tkKnV+yWuHGqL045FiB+UrVAbtmkrIngia+AuWt6YobVJbqsDbJOZcVgQvpKD5ybdPIRQnqOAn3YNLf2jjNX51RYkvTbcBUbn+O7jU0=; 20:z5oXrOHC9+urLTF1YV1qEAK6u1L2Mgp70kPycch5PZ43Y0S619Avsh54fznYvwXARyVIg+Dg4d83+E/xfegCFQ== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jul 2015 15:23:22.3767 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1096 Archived-At: Subject: [Idr] Comment on draft-zhang-idr-upstream-assigned-label-solution 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 Jul 2015 15:25:09 -0000 I see that draft-zhang-idr-upstream-assigned-label-solution ("Upstream Assigned Label Collision Solution") is on the IDR agenda, so I'd like to make a comment. The draft talks about the use of "upstream-assigned labels" in the MVPN application, and discusses the problem of "collisions" when multiple routers independently assign upstream-assigned labels. However, collisions in the assignment of upstream-assigned labels are not possible, because every router assigns them from its own 20-bit per-router label space. Thus every assignment is unique in the context of the router that made the assignment. In the MVPN application, if a multicast data packet is carrying an upstream-assigned label and is traveling on a P2MP LSP, the packet will have at least two labels. The top label, probably assigned by mLDP or RSVP-TE-P2MP, is an ordinary downstream-assigned label that identifies the P2MP LSP. The upstream-assigned label would be the second label. The upstream-assigned label is always assigned by the router that is the root of the P2MP LSP. Thus one can infer from the top label the identity of the router that assigned the second label. Since the top label provides the context in which the second label is interpreted, no ambiguity (or collision) is possible, and there is no need to introduce procedures to coordinate label assignment among the routers. I suspect the authors are really thinking about "domain-wide labels", where multiple routers have to interpret labels from a single label space. If multiple routers are independently and dynamically assigning labels from a single label space, collisions are of course possible. But this is not a problem for an application, like MVPN, that doesn't use domain-wide labels. By the way, IDR actually doesn't seem like the most appropriate WG for this topic; I'd have thought it more relevant to MPLS, BESS, or SPRING. From nobody Mon Jul 20 09:29: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 8505E1A8AA8 for ; Mon, 20 Jul 2015 09:29:08 -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 Bq05At8LV-Sm for ; Mon, 20 Jul 2015 09:29:07 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (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 13CF01A8974 for ; Mon, 20 Jul 2015 09:29:07 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=31.133.162.2; From: "Susan Hares" To: "'idr wg list'" Date: Mon, 20 Jul 2015 12:29:03 -0400 Message-ID: <006001d0c309$3164b570$942e2050$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0061_01D0C2E7.AA549C10" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdDDCCVopVW2zsHRQQyjyfYUMCM6Vw== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [Idr] WG Adoption call - draft-keyupate-idr-bgp-prefix-sid (7/20 to 8/3) 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 Jul 2015 16:29:08 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0061_01D0C2E7.AA549C10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This begins a 2 week WG Adoption call for draft-keyupate-idr-bgp-prefix-sid (7/20 to 8/3/2015). http://datatracker.ietf.org/doc/draft-keyupate-idr-bgp-prefix-sid/ The authors should indicate if there is any IPR related to the draft. We would appreciate if you would answer the following questions: 1) Do you know of networks where this new BGP feature would useful? 2) Do you know of any technical issues with this draft? In your discussion, please include whether you support the draft or not? Sue Hares and John Scudder ------=_NextPart_000_0061_01D0C2E7.AA549C10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This = begins a 2 week WG Adoption call for draft-keyupate-idr-bgp-prefix-sid = (7/20 to 8/3/2015). 

http://datatracker.ietf.org/doc/draft-keyupate-idr-bgp-prefix-sid/=

 

The authors should indicate if there is any IPR = related to the draft.

 

We would = appreciate if you would answer the following questions: =

1)      = Do you know of networks where this new BGP = feature would useful?

2)      = Do you know of any technical issues with this = draft?

 

In your discussion, please include whether you support = the draft or not?

 

Sue Hares = and John Scudder

------=_NextPart_000_0061_01D0C2E7.AA549C10-- From nobody Mon Jul 20 09:58: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 487241AD378 for ; Mon, 20 Jul 2015 09:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.212 X-Spam-Level: X-Spam-Status: No, score=-4.212 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 xFAM7Gab9l5L for ; Mon, 20 Jul 2015 09:58:10 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by ietfa.amsl.com (Postfix) with ESMTP id 49BBB1AD066 for ; Mon, 20 Jul 2015 09:58:10 -0700 (PDT) Received: from dhcp-b1b3.meeting.ietf.org (dhcp-b1b3.meeting.ietf.org [31.133.177.179]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id 336785405D4; Mon, 20 Jul 2015 12:58:08 -0400 (EDT) From: Jared Mauch Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Jul 2015 12:58:06 -0400 To: idr wg list Message-Id: Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3067\)) X-Mailer: Apple Mail (2.3067) Archived-At: Subject: [Idr] draft-mauch-bgp-reject 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 Jul 2015 16:58:13 -0000 One of the major challenges that we face as a network operator is some = of the legacy posture left in internet connected devices. We=E2=80=99ve = seen this history play out with many other protocols and services, such = as enabling chargen, echo and other services on devices. Having SMTP = open relays, etc. It=E2=80=99s time to document the changes and require them as part of = the standard behavior of all BGP speaking devices. https://tools.ietf.org/html/draft-mauch-bgp-reject Is an attempt to capture the change that may be required by some = implementors. Already Juniper and IOS-XR have this default behavior of not sending any = routes unless explicit policy is configured. It=E2=80=99s my = understanding that it=E2=80=99s also the default in BIRD but I have not = validated this myself. I=E2=80=99m interested in discussion and feedback on this document. - Jared= From nobody Mon Jul 20 10:11: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 00FAB1B2C78 for ; Mon, 20 Jul 2015 10:11:20 -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 eyHF4It-Jcvm for ; Mon, 20 Jul 2015 10:11:18 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4724A1B29BD for ; Mon, 20 Jul 2015 10:11:18 -0700 (PDT) X-AuditID: c618062d-f799e6d00000329e-4c-55accfe41459 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 3D.7B.12958.4EFCCA55; Mon, 20 Jul 2015 12:39:32 +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; Mon, 20 Jul 2015 13:11:15 -0400 From: Jeff Tantsura To: Jared Mauch , idr wg list Thread-Topic: [Idr] draft-mauch-bgp-reject Thread-Index: AQHQww1Jq4DdMHXuUUCVlYpqLquDV53kZcAA Date: Mon, 20 Jul 2015 17:11:14 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <8EB949FD99FD5E49B52BBBF804D6F1E0@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyuXRPoO6T82tCDV5sMbJ4dfsZk8WVRXfY HZg8liz5yeTR2zSNMYApissmJTUnsyy1SN8ugStj6kPfgnauilnLupgbGJdwdDFyckgImEj8 mnaWBcIWk7hwbz1bFyMXh5DAUUaJtzN+s0A4yxklbr09xQZSxSZgIPH/23GwDhEBZ4mOZydZ QWxhAU2JCaePMELEtSS6n75khbCNJA51NrGD2CwCqhIrT7eD9fIKmEt8+7aGuYuRA2iBk8T7 x1wgYU6gkedb7oC1MgId9P3UGiYQm1lAXOLWk/lMEIcKSCzZc54ZwhaVePn4H1i9qICexMrr TWwQcSWJOa+vMUP06kncmDqFDcK2lti0cRMLhK0tsWzha2aIcwQlTs58wjKBUXwWknWzkLTP QtI+C0n7LCTtCxhZVzFylBanluWmGxlsYgTG1DEJNt0djHteWh5iFOBgVOLhVQhbEyrEmlhW XJl7iFGag0VJnNcxKi9USCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA2M3v/c8N2m/v2Gyy57O PPBmOYurZ9u6KWF/VkwpiplTHjxjcco5jpWeFe0cxxQOfHzT6vi61PK73aLF3h8N5wr0Hdn2 0/hEs+T35YoBO/dt+Z/OPt3Z8VTq2ZrvJfYL5RKaOU38qrgSD6nuCvESiyosniDy0j1DtuCt XdaDgDd6j077C+aoH1FiKc5INNRiLipOBAAqxK3CigIAAA== Archived-At: Subject: Re: [Idr] draft-mauch-bgp-reject 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 Jul 2015 17:11:20 -0000 Jared, Really useful! BCP seems to be more appropriate track though. Cheers, Jeff -----Original Message----- From: Jared Mauch Date: Monday, July 20, 2015 at 9:58 AM To: idr wg list Subject: [Idr] draft-mauch-bgp-reject >One of the major challenges that we face as a network operator is some of >the legacy posture left in internet connected devices. We=B9ve seen this >history play out with many other protocols and services, such as enabling >chargen, echo and other services on devices. Having SMTP open relays, >etc. > >It=B9s time to document the changes and require them as part of the >standard behavior of all BGP speaking devices. > >https://tools.ietf.org/html/draft-mauch-bgp-reject > >Is an attempt to capture the change that may be required by some >implementors. > >Already Juniper and IOS-XR have this default behavior of not sending any >routes unless explicit policy is configured. It=B9s my understanding that >it=B9s also the default in BIRD but I have not validated this myself. > >I=B9m interested in discussion and feedback on this document. > >- Jared >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr From nobody Mon Jul 20 10:18:57 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 433341B2C9E for ; Mon, 20 Jul 2015 10:18:56 -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 Kg17Oo9HM1Aa for ; Mon, 20 Jul 2015 10:18:55 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 3F2AE1B2CB8 for ; Mon, 20 Jul 2015 10:17:45 -0700 (PDT) Received: from dhcp-b1b3.meeting.ietf.org (dhcp-b1b3.meeting.ietf.org [31.133.177.179]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id 5546C5406C5; Mon, 20 Jul 2015 13:16:49 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3067\)) Content-Type: text/plain; charset=iso-8859-1 From: Jared Mauch In-Reply-To: Date: Mon, 20 Jul 2015 13:16:47 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <16F8DEDB-BA31-48CD-AAEF-6DED58850B09@puck.nether.net> References: To: Jeff Tantsura X-Mailer: Apple Mail (2.3067) Archived-At: Cc: idr wg list Subject: Re: [Idr] draft-mauch-bgp-reject 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 Jul 2015 17:18:56 -0000 Thanks. This is trying to capture a well known issue and my first attempt at editing XML myself directly, so please be a wee bit kind when it comes to the formatting and such. I am happy to take flames as well, including in-person should someone have concerns on this. This is mostly documenting the existing behavior by vendors to keep the routing ecosystem secured and stable. - jared > On Jul 20, 2015, at 1:11 PM, Jeff Tantsura = wrote: >=20 > Jared, >=20 > Really useful! > BCP seems to be more appropriate track though. >=20 > Cheers, > Jeff >=20 >=20 > -----Original Message----- > From: Jared Mauch > Date: Monday, July 20, 2015 at 9:58 AM > To: idr wg list > Subject: [Idr] draft-mauch-bgp-reject >=20 >> One of the major challenges that we face as a network operator is = some of >> the legacy posture left in internet connected devices. We=B9ve seen = this >> history play out with many other protocols and services, such as = enabling >> chargen, echo and other services on devices. Having SMTP open = relays, >> etc. >>=20 >> It=B9s time to document the changes and require them as part of the >> standard behavior of all BGP speaking devices. >>=20 >> https://tools.ietf.org/html/draft-mauch-bgp-reject >>=20 >> Is an attempt to capture the change that may be required by some >> implementors. >>=20 >> Already Juniper and IOS-XR have this default behavior of not sending = any >> routes unless explicit policy is configured. It=B9s my understanding = that >> it=B9s also the default in BIRD but I have not validated this myself. >>=20 >> I=B9m interested in discussion and feedback on this document. >>=20 >> - Jared >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr From nobody Mon Jul 20 10:24: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 AB71F1B2CDA for ; Mon, 20 Jul 2015 10:24:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UdRl0-Gnnu4H for ; Mon, 20 Jul 2015 10:24:33 -0700 (PDT) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (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 0747A1B2CB7 for ; Mon, 20 Jul 2015 10:24:32 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so32887947wib.1 for ; Mon, 20 Jul 2015 10:24:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=LZN8Rlx0ytU6NrSFPjXuwq6s8JIeIcd8SSwp6NFgcK8=; b=UMmphi/SI/OA+PWcUlmB0/PibHeKGdvRXFefQxNGxK7Cbijfovz7UTOIqd3xyea5TN gytGhOA045SfX+aTFasQXQ058hiTnA/9FmULD3enkIpOR5KdfspO65OICLE+qPH3R+UH NlQ4+X4ZsYRIJgEEmiw1HRfDiI23wGbrbm0+2bmK+6Oozab3C6tfNnIkSmqK8b9y5GOg 59vMHdBn4JvoBbP5nRfOncfFit/Umfxh493H4K34AKQCKQdXyNyunMmCQVQ9VahTkUZS HLRrV8K0a6+S+hBJx97bntx8JFtCQXVdh4g1x6bEuZEh6UiLK/LUKMX5XezsvUNckzx7 vqIw== X-Gm-Message-State: ALoCoQm3FiuN+Ln3/hFeAFJXMi312Cg/E2wiEMLTkyMdrxlhnECMsGJKII/B1rqbnCfgMfnGDeqW X-Received: by 10.180.103.42 with SMTP id ft10mr16669952wib.43.1437413071514; Mon, 20 Jul 2015 10:24:31 -0700 (PDT) Received: from localhost ([2001:67c:370:136:9092:4ba:f777:85a7]) by smtp.gmail.com with ESMTPSA id eu2sm12774161wic.8.2015.07.20.10.24.29 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Jul 2015 10:24:30 -0700 (PDT) Date: Mon, 20 Jul 2015 19:24:27 +0200 From: Job Snijders To: Jared Mauch Message-ID: <20150720172427.GA65805@dhcp-a1b1.meeting.ietf.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: idr wg list Subject: Re: [Idr] draft-mauch-bgp-reject 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 Jul 2015 17:24:34 -0000 Hi Jared, On Mon, Jul 20, 2015 at 12:58:06PM -0400, Jared Mauch wrote: > Already Juniper and IOS-XR have this default behavior of not sending > any routes unless explicit policy is configured. It’s my understanding > that it’s also the default in BIRD but I have not validated this > myself. I double checked, BIRD is halfway compliant with the draft, the default is to accept anything and announce nothing: $ sudo birdc6 show protocols all | grep filter Input filter: ACCEPT Output filter: REJECT I'll make an inventory of commonly used platforms. Kind regards, Job From nobody Mon Jul 20 10:29: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 9A2B51B2CF4 for ; Mon, 20 Jul 2015 10:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, 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 pPvBlnmUR98f for ; Mon, 20 Jul 2015 10:29:13 -0700 (PDT) Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) by ietfa.amsl.com (Postfix) with SMTP id C89C11B2CF5 for ; Mon, 20 Jul 2015 10:29:13 -0700 (PDT) Received: (qmail 16166 invoked by uid 0); 20 Jul 2015 17:29:11 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy6.mail.unifiedlayer.com with SMTP; 20 Jul 2015 17:29:11 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id uhV31q00n2SSUrH01hV6pS; Mon, 20 Jul 2015 11:29:10 -0600 X-Authority-Analysis: v=2.1 cv=NJxGpSKg c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=JAI3OqB5mnwA:10 a=N659UExz7-8A:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=zOBTXjUuO1YA:10 a=48vgC7mUAAAA:8 a=i0EeH86SAAAA:8 a=Cn5AcPyW0ndq2X1GiJkA:9 a=e-zEULZ_eyy6L8p_:21 a=GsqymHoUDRrEKx_t:21 a=pILNOxqGKmIA:10 a=jM_x9b4JT8QA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=HXAWOxtX0arv9NsVtTziJY0rrmjo/fOjApBsB6Sehj4=; b=SOXqNuKYUUXY8xcq0/FCZYXWg/itnaQS7PRKtS0y1X6IGlpKv3KZ/1JAOq3JFOi2IgH8/fG0BB2QcrnA1PdbQS7DAL2IZcf6oUNwxn5KvYiWU8tLnY/UdyWahQHAx93B; Received: from box313.bluehost.com ([69.89.31.113]:51536 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZHEsB-0001vB-Tz; Mon, 20 Jul 2015 11:29:04 -0600 To: "Dongjie (Jimmy)" , "draft-ietf-idr-te-lsp-distribution@ietf.org" References: <20150507092713.29688.3632.idtracker@ietfa.amsl.com> <554B7098.1090101@labn.net> <76CD132C3ADEF848BD84D028D243C92757D10DAB@nkgeml512-mbx.china.huawei.com> <14d33532e98.276d.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <76CD132C3ADEF848BD84D028D243C92757D11D2B@nkgeml512-mbx.china.huawei.com> From: Lou Berger X-Enigmail-Draft-Status: N1110 Message-ID: <55AD2FD2.4070605@labn.net> Date: Mon, 20 Jul 2015 19:28:50 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <76CD132C3ADEF848BD84D028D243C92757D11D2B@nkgeml512-mbx.china.huawei.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] I-D Action: draft-ietf-idr-te-lsp-distribution-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 17:29:15 -0000 I see I missed this message -- sorry. On 5/13/2015 9:38 AM, Dongjie (Jimmy) wrote: > Hi Lou, > > Thanks for your replies, and please see inline below: > >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: Friday, May 08, 2015 7:40 PM >> To: Dongjie (Jimmy); draft-ietf-idr-te-lsp-distribution@ietf.org >> Cc: idr@ietf.org >> Subject: RE: [Idr] I-D Action: draft-ietf-idr-te-lsp-distribution-03.txt >> >> Jie, >> >> See in line below. >> >> >> On May 8, 2015 6:04:33 AM "Dongjie (Jimmy)" wrote: >> >>> Hi Lou, >>> >>> Thanks a lot for your comments, and please see my replies inline: >>> >>>> -----Original Message----- >>>> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Lou Berger >>>> Sent: Thursday, May 07, 2015 10:03 PM >>>> To: draft-ietf-idr-te-lsp-distribution@ietf.org >>>> Cc: idr@ietf.org >>>> Subject: Re: [Idr] I-D Action: >>>> draft-ietf-idr-te-lsp-distribution-03.txt >>>> >>>> Hi, >>>> I have a couple of questions on this draft: >>>> >>>>> The 64-Bit 'Identifier' field is used to discriminate between >>>>> instances with different LSP technologies. The default identifier >>>>> "0" identifies the instance for packet switched LSPs. >>>>> A new >>>>> identifier TBD is used to identify the instance of optical layer >>>>> LSPs. >>>> Doesn't it make more sense to just carry the values used in LSP >>>> switching >>> type >>>> (See rfc3473/7074) for the non-zero case? >>> I agree with your point that this document could cover LSPs with >>> different switching types. As for using the switching type values >>> directly as identifier, we coauthors will discuss it and then feedback to you. >>> >> Sure, but unless there's a substantive justification, I really don't think we need >> another name/number space for the same thing. > What about we use another way to specify the LSP switching type: include the Generalized Label Request Object in the LSP State Information TLVs, as the switching type is one of the attributes of the LSP. The NLRI is used to specify the identifiers of the LSP. So does this mean you'd drop the Identifier from the TE LSP NLRI? > > This would not require the assignment of several well-known values from the identifier registry. Our concern is that this identifier field and registry is generic for all BGP-LS NLRIs, and making reservations for some specific NLRIs may restrict the usage of such values. I've read this a few times and concluded I don't really understand what you're proposing. Can you try stating it a different way? Perhaps just send the changes that you'd make. > If you agree with this method, we can add the corresponding specifications in next revision. >>>>> Currently the TE LSP Objects that can be carried in the LSP State TLV >>>>> include: >>>> How do you distinguish between RSVP and PCEP objects? >>> Good question. My understanding is for the same information, the >>> format of RSVP and PCEP objects usually are compatible. In case there >>> is some discrepancy, the current strategy is, for information which >>> has corresponding RSVP object, the RSVP object is used, otherwise the >>> PCEP object is used. Or do you have some suggestions about this? >>> >> There is collision/ambiguity so I'd use a different type or add a subtype. > Our intention was to re-use the existing registries of LSP objects and avoid defining a new one. The advantage is every time some new object is defined in RSVP or PCEP, this BGP-LS specification does not need to be revised. This makes sense > > That said, I'd agree that the ambiguity between RSVP and PCEP objects needs to be solved. yup, you currently have collision of values between protocols. > One possible solution for this is to make the LSP State information TLVs hierarchical. We can define a set of top level TLVs, each one identifies the source/format of the information carried. For example, we can define a top-level sub-TLV for RSVP, which consists of the existing RSVP objects. Similarly, define another top level sub-TLV for PCEP, which carries the existing PCEP objects. We may also define a new top level sub-TLV for LSP information derived from other sources. This way we can solve the ambiguity without assigning new type values for every existing object. Hope this is in line with your proposal "add a subtype". Yes, a mean a subtype = {RSVP|PCEP} not defining new values for all objects. Lou > Best regards, > Jie > >> Lou >> >>> Best regards, >>> Jie >>> >>>> Lou >>>> >>>> On 5/7/2015 5:27 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 : Distribution of MPLS Traffic Engineering (TE) >> LSP >>>> State using BGP >>>>> Authors : Jie Dong >>>>> Mach(Guoyi) Chen >>>>> Hannes Gredler >>>>> Stefano Previdi >>>>> Jeff Tantsura >>>>> Filename : draft-ietf-idr-te-lsp-distribution-03.txt >>>>> Pages : 12 >>>>> Date : 2015-05-07 >>>>> >>>>> Abstract: >>>>> This document describes a mechanism to collect the Traffic >>>>> Engineering (TE) LSP information using BGP. Such information can be >>>>> used by external components for path reoptimization, service >>>>> placement and network visualization. >>>>> >>>>> >>>>> >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-idr-te-lsp-distributio >>>>> n/ >>>>> >>>>> There's also a htmlized version available at: >>>>> https://tools.ietf.org/html/draft-ietf-idr-te-lsp-distribution-03 >>>>> >>>>> A diff from the previous version is available at: >>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-te-lsp-distributi >>>>> on-0 >>>>> 3 >>>>> >>>>> >>>>> 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 >>>>> >>>> >>>> _______________________________________________ >>>> Idr mailing list >>>> Idr@ietf.org >>>> https://www.ietf.org/mailman/listinfo/idr > From nobody Mon Jul 20 10:34: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 88C471B2D30 for ; Mon, 20 Jul 2015 10:34:35 -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 5zOzEXPlKd4A for ; Mon, 20 Jul 2015 10:34:30 -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 CFA421B2D3A for ; Mon, 20 Jul 2015 10:34:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=431; q=dns/txt; s=iport; t=1437413669; x=1438623269; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Rvyeg5bE9UIlQp5H+YhUViwNbE8kFlorITbt+6DqduE=; b=P2Onhn20aPbbqIFf8jaVk/tNK0DKvvBGK6Z7WCASP7Nwvr/ZAxnaGo4X coo3cS873Hw7PMN5KSRTqwLL9eboAfzWK3O0Ue7kaUsGvtks8ppwknkSk um/72mYFZGC7nxKT0fdIHvRLAbE3aXMKx8CFvs9cnk7r1oaUZAj1Jm5pF Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AeAwAzMK1V/5xdJa1cgxNUaQa7ZwmBawqFdwKBLzgUAQEBAQEBAYEKhCQBAQMBAQEBNzQLEAIBCDYQJwslAgQBDQWIJggNyCgBAQEBAQEBAQEBAQEBAQEBAQEBAQETBItMhQYHhCsBBJRSAYwgmQcmg3xvgUeBBAEBAQ X-IronPort-AV: E=Sophos;i="5.15,509,1432598400"; d="scan'208";a="13351043" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 20 Jul 2015 17:34:29 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t6KHYT8o029215 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 20 Jul 2015 17:34:29 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.112]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0195.001; Mon, 20 Jul 2015 12:34:28 -0500 From: "Keyur Patel (keyupate)" To: Randy Bush , Susan Hares Thread-Topic: [Idr] Early allocation WG Review Call draft-ietf (7/19 to 8/2) - WG LC Thread-Index: AQHQwxJUhVGEbmUIyUivlIuHoFQyzQ== Date: Mon, 20 Jul 2015 17:34:27 +0000 Message-ID: References: <005401d0c1ca$f9cb4ff0$ed61efd0$@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 x-originating-ip: [10.155.32.223] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: idr wg list Subject: Re: [Idr] Early allocation WG Review Call draft-ietf (7/19 to 8/2) - WG LC X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 17:34:35 -0000 I am not aware of any ipr related to this draft. Regards, Keyur On 7/18/15, 9:48 PM, "Randy Bush" wrote: >> The authors should to this Early Adoption WG LC to the list to indicate >>if >> they know of any IPR. > >i am not aware of ipr relating to this draft > >randy > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr From nobody Mon Jul 20 14:08: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 E32391B2C64 for ; Mon, 20 Jul 2015 14:08:11 -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 A4siQWx22Q3t for ; Mon, 20 Jul 2015 14:08:10 -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 203451B31EA for ; Mon, 20 Jul 2015 14:08:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14243; q=dns/txt; s=iport; t=1437426489; x=1438636089; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=XHwSR96TEPt9M8KNbscU6YZO/m0GHivkfk0EXRsaHIM=; b=XX3s/YF+Z/8/vfIaByuSj2gbBV8vnVAT00p0/5+FqvJNjM2WyfVGarU3 xNk59/jJC97bv0mMC5bfbVtr0WhthPZeofbrbyOUImhw33M3w/OkX7H6B 0mdby0PoY20se9J4kYLDIYpOvl1JVV8+BZiHFFRrYBo4e48pNAHQ7ZwRL 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ABBgAgYq1V/4wNJK1cgkZNVGkGgxypQI5iKgmBdYYBAhyBFDgUAQEBAQEBAYEKhCMBAQEEHQYKXAIBCA4DAwECKAMCAgIwFAkIAgQBEoguDbJ0licBAQEBAQEBAQEBAQEBAQEBAQEBAQEXi0yELUgYgmiBQwWRW4J3AYRuhzKBQ0aDVI9Jg2ERFYINHIFTb4EEQ4EEAQEB X-IronPort-AV: E=Sophos; i="5.15,510,1432598400"; d="scan'208,217"; a="13389993" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-6.cisco.com with ESMTP; 20 Jul 2015 21:08:07 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t6KL86VG026267 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 20 Jul 2015 21:08:06 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.37]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Mon, 20 Jul 2015 16:08:06 -0500 From: "Acee Lindem (acee)" To: Susan Hares , "'idr wg list'" Thread-Topic: [Idr] WG Adoption call - draft-keyupate-idr-bgp-prefix-sid (7/20 to 8/3) Thread-Index: AQHQwzAsTfKpZVlwz0C5SOw0Gp8odg== Date: Mon, 20 Jul 2015 21:08:06 +0000 Message-ID: References: <006001d0c309$3164b570$942e2050$@ndzh.com> In-Reply-To: <006001d0c309$3164b570$942e2050$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.49.129] Content-Type: multipart/alternative; boundary="_000_D1D2FEC428BC6aceeciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] WG Adoption call - draft-keyupate-idr-bgp-prefix-sid (7/20 to 8/3) 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 Jul 2015 21:08:12 -0000 --_000_D1D2FEC428BC6aceeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU3VlLA0KDQpJIHN1cHBvcnQgV0cgYWRvcHRpb24uDQoNCkZyb206IElkciA8aWRyLWJvdW5j ZXNAaWV0Zi5vcmc8bWFpbHRvOmlkci1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mIFN1 c2FuIEhhcmVzIDxzaGFyZXNAbmR6aC5jb208bWFpbHRvOnNoYXJlc0BuZHpoLmNvbT4+DQpEYXRl OiBNb25kYXksIEp1bHkgMjAsIDIwMTUgYXQgMTI6MjkgUE0NClRvOiAnaWRyIHdnIGxpc3QnIDxp ZHJAaWV0Zi5vcmc8bWFpbHRvOmlkckBpZXRmLm9yZz4+DQpTdWJqZWN0OiBbSWRyXSBXRyBBZG9w dGlvbiBjYWxsIC0gZHJhZnQta2V5dXBhdGUtaWRyLWJncC1wcmVmaXgtc2lkICg3LzIwIHRvIDgv MykNCg0KVGhpcyBiZWdpbnMgYSAyIHdlZWsgV0cgQWRvcHRpb24gY2FsbCBmb3IgZHJhZnQta2V5 dXBhdGUtaWRyLWJncC1wcmVmaXgtc2lkICg3LzIwIHRvIDgvMy8yMDE1KS4NCmh0dHA6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQta2V5dXBhdGUtaWRyLWJncC1wcmVmaXgtc2lkLw0K DQpUaGUgYXV0aG9ycyBzaG91bGQgaW5kaWNhdGUgaWYgdGhlcmUgaXMgYW55IElQUiByZWxhdGVk IHRvIHRoZSBkcmFmdC4NCg0KV2Ugd291bGQgYXBwcmVjaWF0ZSBpZiB5b3Ugd291bGQgYW5zd2Vy IHRoZSBmb2xsb3dpbmcgcXVlc3Rpb25zOg0KDQoxKSAgICAgIERvIHlvdSBrbm93IG9mIG5ldHdv cmtzIHdoZXJlIHRoaXMgbmV3IEJHUCBmZWF0dXJlIHdvdWxkIHVzZWZ1bD8NCg0KR2l2ZW4gdGhh dCB3ZSBoYXZlIHNlZ21lbnQgcm91dGluZyBmb3IgdGhlIElHUHMsIGl0IGlzIHJlcXVpcmVkIGlu IERDIG5ldHdvcmtzIHRoYXQgdXNlIEJHUCBhcyB0aGVpciBJR1AgYXMgaXMgYmVpbmcgZGlzY3Vz c2VkIGluIFJURyBXRy4NCg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt aWV0Zi1ydGd3Zy1iZ3Atcm91dGluZy1sYXJnZS1kYy8NCg0KSG93ZXZlciwgdGhlIGZlYXR1cmUg aXMgY2VydGFpbmx5ICBub3QgbGltaXRlZCB0byB0aGlzIHR5cGUgb2YgbmV0d29yay4NCg0KVGhh bmtzLA0KQWNlZQ0KDQoNCg0KMikgICAgICBEbyB5b3Uga25vdyBvZiBhbnkgdGVjaG5pY2FsIGlz c3VlcyB3aXRoIHRoaXMgZHJhZnQ/DQoNCg0KSW4geW91ciBkaXNjdXNzaW9uLCBwbGVhc2UgaW5j bHVkZSB3aGV0aGVyIHlvdSBzdXBwb3J0IHRoZSBkcmFmdCBvciBub3Q/DQoNClN1ZSBIYXJlcyBh bmQgSm9obiBTY3VkZGVyDQo= --_000_D1D2FEC428BC6aceeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAw KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0K SGkgU3VlLCZuYnNwOzwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KPGJyPg0K PC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQpJIHN1cHBvcnQgV0cgYWRvcHRp b24uJm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8YnI+DQo8L2Rp dj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiIgc3R5bGU9ImNvbG9yOiByZ2IoMCwg MCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7 Ij4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMXB0OyB0ZXh0 LWFsaWduOmxlZnQ7IGNvbG9yOmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9S REVSLUxFRlQ6IG1lZGl1bSBub25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxFRlQ6 IDBpbjsgUEFERElORy1SSUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsg Qk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBzdHls ZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTogPC9zcGFuPklkciAmbHQ7PGEgaHJlZj0ibWFpbHRv Omlkci1ib3VuY2VzQGlldGYub3JnIj5pZHItYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJl aGFsZiBvZiBTdXNhbiBIYXJlcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNoYXJlc0BuZHpoLmNvbSI+ c2hhcmVzQG5kemguY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9s ZCI+RGF0ZTogPC9zcGFuPk1vbmRheSwgSnVseSAyMCwgMjAxNSBhdCAxMjoyOSBQTTxicj4NCjxz cGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPidpZHIgd2cgbGlzdCcgJmx0 OzxhIGhyZWY9Im1haWx0bzppZHJAaWV0Zi5vcmciPmlkckBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0K PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5bSWRyXSBXRyBB ZG9wdGlvbiBjYWxsIC0gZHJhZnQta2V5dXBhdGUtaWRyLWJncC1wcmVmaXgtc2lkICg3LzIwIHRv IDgvMyk8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBpZD0iTUFD X09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVj NGRmIDUgc29saWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXYgeG1s bnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVybjpzY2hlbWFz LW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNv bS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvVFIvUkVDLWh0 bWw0MCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDE0 IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICov DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIg NCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0K CXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29M aXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsN CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41 aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4w aW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDox NzU3NDQxMTQwOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlk czo4NjQ1NzExMDggLTMxNDM5MzA3MCA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcx MyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMDpsZXZlbDEN Cgl7bXNvLWxldmVsLXRleHQ6IiUxXCkiOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoyMC4yNXB0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjU2LjI1cHQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpy b21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOnJpZ2h0Ow0KCW1hcmdpbi1sZWZ0OjkyLjI1cHQ7DQoJdGV4dC1pbmRlbnQ6LTku MHB0O30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MTI4LjI1cHQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MTY0LjI1cHQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpy b21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOnJpZ2h0Ow0KCW1hcmdpbi1sZWZ0OjIwMC4yNXB0Ow0KCXRleHQtaW5kZW50Oi05 LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjIzNi4yNXB0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjI3Mi4yNXB0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpyaWdodDsNCgltYXJnaW4tbGVmdDozMDguMjVwdDsNCgl0ZXh0LWluZGVudDot OS4wcHQ7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTow aW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPGRpdiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBiZWdp bnMgYSAyIHdlZWsgV0cgQWRvcHRpb24gY2FsbCBmb3IgZHJhZnQta2V5dXBhdGUtaWRyLWJncC1w cmVmaXgtc2lkICg3LzIwIHRvIDgvMy8yMDE1KS4mbmJzcDsNCjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1rZXl1cGF0ZS1pZHItYmdwLXByZWZpeC1zaWQvIj5odHRwOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWtleXVwYXRlLWlkci1iZ3AtcHJlZml4LXNpZC88L2E+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBhdXRob3JzIHNob3VsZCBpbmRpY2F0ZSBpZiB0aGVyZSBp cyBhbnkgSVBSIHJlbGF0ZWQgdG8gdGhlIGRyYWZ0Lg0KPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PldlIHdvdWxkIGFwcHJlY2lhdGUgaWYgeW91IHdvdWxkIGFuc3dlciB0aGUgZm9sbG93aW5nIHF1 ZXN0aW9uczoNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0 eWxlPSJtYXJnaW4tbGVmdDoyMC4yNXB0O3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBs ZXZlbDEgbGZvMSI+DQo8IS0tW2lmICFzdXBwb3J0TGlzdHNdLS0+PHNwYW4gc3R5bGU9Im1zby1s aXN0Oklnbm9yZSI+MSk8c3BhbiBzdHlsZT0iZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlh bnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgZm9udC1zaXplOiA3cHQ7IGxpbmUtaGVp Z2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48IS0tW2VuZGlmXS0tPkRvIHlvdSBr bm93IG9mIG5ldHdvcmtzIHdoZXJlIHRoaXMgbmV3IEJHUCBmZWF0dXJlIHdvdWxkIHVzZWZ1bD88 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+DQo8ZGl2 IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z ZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9y OiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNp emU6IDE0cHg7Ij4NCkdpdmVuIHRoYXQgd2UgaGF2ZSBzZWdtZW50IHJvdXRpbmcgZm9yIHRoZSBJ R1BzLCBpdCBpcyByZXF1aXJlZCBpbiBEQyBuZXR3b3JrcyB0aGF0IHVzZSBCR1AgYXMgdGhlaXIg SUdQIGFzIGlzIGJlaW5nIGRpc2N1c3NlZCBpbiBSVEcgV0cuJm5ic3A7PC9kaXY+DQo8ZGl2IHN0 eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8YnI+DQo8L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2Fs aWJyaSxzYW5zLXNlcmlmIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1p ZXRmLXJ0Z3dnLWJncC1yb3V0aW5nLWxhcmdlLWRjLzwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQg ZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj48YnI+DQo8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250 IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+SG93ZXZlciwgdGhlIGZlYXR1cmUgaXMgY2VydGFp bmx5ICZuYnNwO25vdCBsaW1pdGVkIHRvIHRoaXMgdHlwZSBvZiBuZXR3b3JrLiZuYnNwOzwvZm9u dD48L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBD YWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxicj4NCjwvZGl2Pg0KPGRp diBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KVGhhbmtzLDwvZGl2Pg0KPGRpdiBzdHlsZT0iY29s b3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQt c2l6ZTogMTRweDsiPg0KQWNlZSZuYnNwOzwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigw LCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRw eDsiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250 LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8YnI+DQo8 L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiIgc3R5bGU9ImNvbG9yOiByZ2Io MCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0 cHg7Ij4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RF IiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElORzowIDAgMCA1OyBN QVJHSU46MCAwIDAgNTsiPg0KPGRpdiB4bWxuczp2PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29t OnZtbCIgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxkaXYgbGFuZz0iRU4tVVMiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MjAuMjVwdDt0ZXh0LWlu ZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjIwLjI1cHQ7dGV4 dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjwhLS1baWYgIXN1cHBv cnRMaXN0c10tLT48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4yKTxzcGFuIHN0eWxlPSJm b250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9y bWFsOyBmb250LXNpemU6IDdwdDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6ICdU aW1lcyBOZXcgUm9tYW4nOyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+ PC9zcGFuPjwhLS1bZW5kaWZdLS0+RG8geW91IGtub3cgb2YgYW55IHRlY2huaWNhbCBpc3N1ZXMg d2l0aCB0aGlzIGRyYWZ0PzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3Jh cGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoyMC4yNXB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkluIHlvdXIgZGlzY3Vzc2lvbiwgcGxlYXNlIGluY2x1ZGUgd2hl dGhlciB5b3Ugc3VwcG9ydCB0aGUgZHJhZnQgb3Igbm90Pw0KPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlN1ZSBIYXJlcyBhbmQgSm9obiBTY3VkZGVyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_D1D2FEC428BC6aceeciscocom_-- From stecheun@cisco.com Mon Jul 20 17:03:03 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 CD4811A1ABC for ; Mon, 20 Jul 2015 17:03: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 xmBo-_B963eb for ; Mon, 20 Jul 2015 17:03:02 -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 39BFD1A0368 for ; Mon, 20 Jul 2015 17:03:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4713; q=dns/txt; s=iport; t=1437436982; x=1438646582; h=from:to:subject:date:message-id:mime-version; bh=inKwG8gF06QsPcjyx1NADqK9r9szEMfLFvESsj2Ku/k=; b=V5IUY3P9xVWhsnuhS3ahiNZki0IS56++hsxHHssR8LTAEu+1B2EnEscL 5xY9fanx2VE27UC4jJU3lkwt2wIl5R89/tRipA+XvCDFNtNV4h72MYuaS Iq9lhuGspS4WzkPBu2w8R7r+q4Qs3kCjAtXWeAIglyfj4yAEspMlj4atG 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CqAwBLi61V/4UNJK1cgkZNVGkGu2wJgXeHMTgUAQEBAQEBAYEKhCQCBB1uAQh4JwQTiC4NozGmHgEBAQEGAQEBAQEZBItMiTgFlFMBhHOHNYFDk2iDYSaCPoE+bwGBRoEEAQEB X-IronPort-AV: E=Sophos; i="5.15,511,1432598400"; d="scan'208,217"; a="13438628" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-6.cisco.com with ESMTP; 21 Jul 2015 00:03:01 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t6L031c1028270 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 21 Jul 2015 00:03:01 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.112]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Mon, 20 Jul 2015 19:03:01 -0500 From: "Steven Cheung (stecheun)" To: "idr@ietf.org" Thread-Topic: [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00.txt (7/6 to 7/20/2015) Thread-Index: AQHQw0ibnISemuSca0q0ckCFa+2m1g== Date: Tue, 21 Jul 2015 00:03:00 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.154.208.101] Content-Type: multipart/alternative; boundary="_000_D1D2DA425A284stecheunciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00.txt (7/6 to 7/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 Jul 2015 00:04:03 -0000 --_000_D1D2DA425A284stecheunciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support -Steven [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00.txt (7/6 to = 7/20/2015) "Susan Hares" Tue, 07 July 2015 01:07 UTCShow header This begins a 2 week adoption call on draft-rosen-idr-tunnel-encaps-00.txt (7/6 to 7/20/2015). The draft can be found at: https://www.ietf.org/internet-drafts/draft-rosen-idr-tunnel-encaps-00.txt In your response, discuss why this draft proposal for encapsulation: a) [operators] will help deployed networks, b) Solves know problems with other tunnel encapsulation, and c) Provides a way to manage the matrix of tunnels. We will have a status report at IDR on 7/20 on this Working group adoption call. Sue Hares and John Scudder --_000_D1D2DA425A284stecheunciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <2299266620186F45AA1349598FB8BE35@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Support

-Steven


[Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00.txt (7/6 to = 7/20/2015)

"Susan Hares" <shares@ndzh.com> Tue, 07 July 2015 01:07 UTCShow header

This begins a 2 week adoption call on draft-rosen-idr-tunnel-encaps-00.=
txt
(7/6 to 7/20/2015).

The draft can be found at:=20

=20

https://www.ietf.org/internet-drafts/draft-rosen-idr-tunnel-encaps-00.txt

=20

In your response, discuss why this draft proposal for encapsulation:

a)      [operators] will help deployed networks,=20

b)      Solves know problems with other tunnel encapsulation, and=20

c)       Provides a way to manage the matrix of tunnels.

=20

=20

We will have a status report at IDR on 7/20 on this Working group adoption
call.=20

=20

Sue Hares and John Scudder

--_000_D1D2DA425A284stecheunciscocom_-- From nobody Tue Jul 21 00:23: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 2ED341AD190 for ; Tue, 21 Jul 2015 00:23:43 -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 bcsqUUyxYw56 for ; Tue, 21 Jul 2015 00:23:37 -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 7CBFA1AD0D0 for ; Tue, 21 Jul 2015 00:23:37 -0700 (PDT) Received: from dhcp-8833.meeting.ietf.org ([31.133.136.51]:62946 helo=RussPC) by server.riw.us with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.85) (envelope-from ) id 1ZHRtm-00019Y-HH; Tue, 21 Jul 2015 07:23:35 +0000 From: "Russ White" To: "'Jared Mauch'" , "'idr wg list'" References: In-Reply-To: Date: Tue, 21 Jul 2015 03:23:25 -0400 Message-ID: <292d01d0c386$27b67f90$77237eb0$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQL9+Y+QLUdWaRXf/S8kSbnlJNrJ7ZuLGQLg 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] draft-mauch-bgp-reject 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 Jul 2015 07:23:43 -0000 > It=E2=80=99s time to document the changes and require them as part of = the standard > behavior of all BGP speaking devices. >=20 > https://tools.ietf.org/html/draft-mauch-bgp-reject Very useful -- I would strongly support this for BCP. :-) Russ From nobody Tue Jul 21 01:06: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 0558B1B29CD; Tue, 21 Jul 2015 01:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 8UypA1wDE6dB; Tue, 21 Jul 2015 01:06:52 -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 99C141B29BB; Tue, 21 Jul 2015 01:06:51 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BVK21969; Tue, 21 Jul 2015 08:06:49 +0000 (GMT) Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 21 Jul 2015 09:06:48 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.227]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Tue, 21 Jul 2015 16:06:42 +0800 From: "Dongjie (Jimmy)" To: Lou Berger , "draft-ietf-idr-te-lsp-distribution@ietf.org" Thread-Topic: [Idr] I-D Action: draft-ietf-idr-te-lsp-distribution-03.txt Thread-Index: AQHQiKgJCwRPna3Z/k6au5osFnF6jJ1wBaYAgAHJJ3D//6E6gIBzoeB3gABHm44= Date: Tue, 21 Jul 2015 08:06:42 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C927742E4C72@nkgeml512-mbx.china.huawei.com> References: <20150507092713.29688.3632.idtracker@ietfa.amsl.com> <554B7098.1090101@labn.net> <76CD132C3ADEF848BD84D028D243C92757D10DAB@nkgeml512-mbx.china.huawei.com> <14d33532e98.276d.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <76CD132C3ADEF848BD84D028D243C92757D11D2B@nkgeml512-mbx.china.huawei.com>, <55AD2FD2.4070605@labn.net> In-Reply-To: <55AD2FD2.4070605@labn.net> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.72.147] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] I-D Action: draft-ietf-idr-te-lsp-distribution-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: Tue, 21 Jul 2015 08:06:55 -0000 Hi Lou,=20 Thanks for your response, and please see my replies inlined with [Jie]: ________________________________________ From: Lou Berger [lberger@labn.net] Sent: Tuesday, July 21, 2015 1:28 To: Dongjie (Jimmy); draft-ietf-idr-te-lsp-distribution@ietf.org Cc: idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-te-lsp-distribution-03.txt I see I missed this message -- sorry. On 5/13/2015 9:38 AM, Dongjie (Jimmy) wrote: > Hi Lou, > > Thanks for your replies, and please see inline below: > >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: Friday, May 08, 2015 7:40 PM >> To: Dongjie (Jimmy); draft-ietf-idr-te-lsp-distribution@ietf.org >> Cc: idr@ietf.org >> Subject: RE: [Idr] I-D Action: draft-ietf-idr-te-lsp-distribution-03.txt >> >> Jie, >> >> See in line below. >> >> >> On May 8, 2015 6:04:33 AM "Dongjie (Jimmy)" wrote: >> >>> Hi Lou, >>> >>> Thanks a lot for your comments, and please see my replies inline: >>> >>>> -----Original Message----- >>>> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Lou Berger >>>> Sent: Thursday, May 07, 2015 10:03 PM >>>> To: draft-ietf-idr-te-lsp-distribution@ietf.org >>>> Cc: idr@ietf.org >>>> Subject: Re: [Idr] I-D Action: >>>> draft-ietf-idr-te-lsp-distribution-03.txt >>>> >>>> Hi, >>>> I have a couple of questions on this draft: >>>> >>>>> The 64-Bit 'Identifier' field is used to discriminate between >>>>> instances with different LSP technologies. The default identifier >>>>> "0" identifies the instance for packet switched LSPs. >>>>> A new >>>>> identifier TBD is used to identify the instance of optical layer >>>>> LSPs. >>>> Doesn't it make more sense to just carry the values used in LSP >>>> switching >>> type >>>> (See rfc3473/7074) for the non-zero case? >>> I agree with your point that this document could cover LSPs with >>> different switching types. As for using the switching type values >>> directly as identifier, we coauthors will discuss it and then feedback = to you. >>> >> Sure, but unless there's a substantive justification, I really don't thi= nk we need >> another name/number space for the same thing. > What about we use another way to specify the LSP switching type: include = the Generalized Label Request Object in the LSP State Information TLVs, as = the switching type is one of the attributes of the LSP. The NLRI is used to= specify the identifiers of the LSP. So does this mean you'd drop the Identifier from the TE LSP NLRI? [Jie] Not exactly. As defined in draft-ietf-idr-ls-distribution, the identi= fier is used to identify the "routing universe" where the NLRI belongs. My = suggestion is to not change the usage of this field. And if it is not appli= cable in some cases, it could be set to some default value. > > This would not require the assignment of several well-known values from t= he identifier registry. Our concern is that this identifier field and regis= try is generic for all BGP-LS NLRIs, and making reservations for some speci= fic NLRIs may restrict the usage of such values. I've read this a few times and concluded I don't really understand what you're proposing. Can you try stating it a different way? Perhaps just send the changes that you'd make. [Jie] Let me try to explain this. The above sentence was to specify the rea= sons of not allocating some specific identifier values to represent switchi= ng types. As I said in the previous response, the values of the identifier = field should be applicable to all NLRI types, so the definition and allocat= ion of the identifier values are better not be restricted to only applicabl= e to a specific NLRI type (e.g. the TE LSP NLRI). The proposed method is to= reflect the LSP switchig type by including the Generalized Label Request O= bject in the LSP State TLV. > If you agree with this method, we can add the corresponding specification= s in next revision. >>>>> Currently the TE LSP Objects that can be carried in the LSP State T= LV >>>>> include: >>>> How do you distinguish between RSVP and PCEP objects? >>> Good question. My understanding is for the same information, the >>> format of RSVP and PCEP objects usually are compatible. In case there >>> is some discrepancy, the current strategy is, for information which >>> has corresponding RSVP object, the RSVP object is used, otherwise the >>> PCEP object is used. Or do you have some suggestions about this? >>> >> There is collision/ambiguity so I'd use a different type or add a subtyp= e. > Our intention was to re-use the existing registries of LSP objects and av= oid defining a new one. The advantage is every time some new object is defi= ned in RSVP or PCEP, this BGP-LS specification does not need to be revised. This makes sense [Jie] Glad that we agreed on this. > > That said, I'd agree that the ambiguity between RSVP and PCEP objects nee= ds to be solved. yup, you currently have collision of values between protocols. > One possible solution for this is to make the LSP State information TLVs = hierarchical. We can define a set of top level TLVs, each one identifies th= e source/format of the information carried. For example, we can define a to= p-level sub-TLV for RSVP, which consists of the existing RSVP objects. Simi= larly, define another top level sub-TLV for PCEP, which carries the existin= g PCEP objects. We may also define a new top level sub-TLV for LSP informat= ion derived from other sources. This way we can solve the ambiguity without= assigning new type values for every existing object. Hope this is in line = with your proposal "add a subtype". Yes, a mean a subtype =3D {RSVP|PCEP} not defining new values for all objec= ts. [Jie] Good, so we are in sync on the solution to this issue.=20 Best regards, Jie Lou > Best regards, > Jie > >> Lou >> >>> Best regards, >>> Jie >>> >>>> Lou >>>> >>>> On 5/7/2015 5:27 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 : Distribution of MPLS Traffic Engineering (T= E) >> LSP >>>> State using BGP >>>>> Authors : Jie Dong >>>>> Mach(Guoyi) Chen >>>>> Hannes Gredler >>>>> Stefano Previdi >>>>> Jeff Tantsura >>>>> Filename : draft-ietf-idr-te-lsp-distribution-03.txt >>>>> Pages : 12 >>>>> Date : 2015-05-07 >>>>> >>>>> Abstract: >>>>> This document describes a mechanism to collect the Traffic >>>>> Engineering (TE) LSP information using BGP. Such information can = be >>>>> used by external components for path reoptimization, service >>>>> placement and network visualization. >>>>> >>>>> >>>>> >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-idr-te-lsp-distributio >>>>> n/ >>>>> >>>>> There's also a htmlized version available at: >>>>> https://tools.ietf.org/html/draft-ietf-idr-te-lsp-distribution-03 >>>>> >>>>> A diff from the previous version is available at: >>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-te-lsp-distributi >>>>> on-0 >>>>> 3 >>>>> >>>>> >>>>> 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 >>>>> >>>> >>>> _______________________________________________ >>>> Idr mailing list >>>> Idr@ietf.org >>>> https://www.ietf.org/mailman/listinfo/idr >= From nobody Tue Jul 21 07:29: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 4BCC91B2E87 for ; Tue, 21 Jul 2015 07:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 33HcmBc5jSfN for ; Tue, 21 Jul 2015 07:29:30 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A5AB1B2E8B for ; Tue, 21 Jul 2015 07:29:30 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 3F8442030E for ; Tue, 21 Jul 2015 10:29:29 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Tue, 21 Jul 2015 10:29:29 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=castlepoint.net; h=content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=wsS4RmtnyBcMgiPRmo1rJh6VHks=; b=QQJQpV sgRpU/6TnbozhEgg+M7n+5WDDMV7GGYGDYreuhQOhDmTCSJpB3Natdpwq+v5RBJ5 aG6JN8rGsvJ7tdKZd0QglXapn6/1NOthi/WodRfN6Uzu8RiOkpYswDPmfgcbGUrh K8FNDcYVECCMQRUNfAl40i14aMq9Ah+AvbQhI= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=wsS4RmtnyBcMgiP Rmo1rJh6VHks=; b=gCwklf9jhr7RHzUsMrKqMnfpKqKXM/Az2uWzdJW+RpOKjBn JZwZNFXx9EpgIDW7grxpAqpldG3TOkQsJELcVFHfx4YZMAVy5VNkRSZx2sbCoouv U46/5tEfJ/E6R7zQEyiCm8Kdv6RwiGd7oPuZ0MULq1TIlyoIs+DeFbyMI7X0= Received: by web5.nyi.internal (Postfix, from userid 99) id 11E76A77A7A; Tue, 21 Jul 2015 10:29:29 -0400 (EDT) Message-Id: <1437488969.3167944.329199849.26B6E5D7@webmail.messagingengine.com> X-Sasl-Enc: cDtd6rBLDJonoR9Fo38gCE+RFZjXX7oAFKimQpIfvuEV 1437488969 From: Shane Amante To: idr@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-63a5d8c6 In-Reply-To: References: Date: Tue, 21 Jul 2015 08:29:29 -0600 Archived-At: Subject: Re: [Idr] draft-mauch-bgp-reject 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 Jul 2015 14:29:32 -0000 Jared, This is a good draft ...=20 Here's a suggestion to consider (or not). I think you may should be more specific and prescribe (to BGP implementors) what it means to for "an operator configuring a policy" to allow receipt or sending of routes. Perhaps you wish to say that the routes need to be marked as "unfeasible" (as per RFC 4271) and thus not considered by BGP for path selection and potential subsequent advertisement in or beyond the receiving ASN. And, now for a more controversial recommendation. More specifically, perhaps it's time to (more seriously) consider additional, default fail-safe mechanism(s) in BGP. Specifically, what if the _default_ behavior for eBGP learned routes was to tag all received routes with the standard BGP NO_EXPORT community? In theory, that would obligate an operator to configure a policy that matched on routes and stripped NO_EXPORT at eBGP boundaries to send routes to neighboring ASN's. I can already hear vociferous complaints the above is much too heavy of a hammer, particularly when it comes to incremental software upgrades in large ASN's and the subsequent negative ramifications to operators that don't read Release Notes, etc. If that's the case, then what if instead there was a proposal for a new, standard BGP community called, i.e.: NEW_NO_EXPORT, which would have a different code point from NO_EXPORT, but the same properties as NO_EXPORT? IOW, legacy BGP implementations would not notice and act upon the NEW_NO_EXPORT community, thus not creating a dramatic "surprise" on operators. However, as new routing SW with NEW_NO_EXPORT gets deployed we incrementally accrue the proper scoping of routes within an ASN and more gradual improvement in routing hygiene. -shane On Mon, Jul 20, 2015, at 10:58 AM, Jared Mauch wrote: > One of the major challenges that we face as a network operator is some of > the legacy posture left in internet connected devices. We=E2=80=99ve see= n this > history play out with many other protocols and services, such as enabling > chargen, echo and other services on devices. Having SMTP open relays, > etc. >=20 > It=E2=80=99s time to document the changes and require them as part of the > standard behavior of all BGP speaking devices. >=20 > https://tools.ietf.org/html/draft-mauch-bgp-reject >=20 > Is an attempt to capture the change that may be required by some > implementors. >=20 > Already Juniper and IOS-XR have this default behavior of not sending any > routes unless explicit policy is configured. It=E2=80=99s my understandin= g that > it=E2=80=99s also the default in BIRD but I have not validated this mysel= f. >=20 > I=E2=80=99m interested in discussion and feedback on this document. >=20 > - Jared > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Tue Jul 21 09:57: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 38D401ACD4E; Tue, 21 Jul 2015 09:57:05 -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 nDPTTg-WEeQL; Tue, 21 Jul 2015 09:57:02 -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 980671ACD2B; Tue, 21 Jul 2015 09:57:02 -0700 (PDT) Received: from SN1PR09MB0799.namprd09.prod.outlook.com (10.162.101.145) by SN1PR09MB0797.namprd09.prod.outlook.com (10.162.101.143) with Microsoft SMTP Server (TLS) id 15.1.219.17; Tue, 21 Jul 2015 16:56:45 +0000 Received: from SN1PR09MB0799.namprd09.prod.outlook.com ([10.162.101.145]) by SN1PR09MB0799.namprd09.prod.outlook.com ([10.162.101.145]) with mapi id 15.01.0219.018; Tue, 21 Jul 2015 16:56:45 +0000 From: "Sriram, Kotikalapudi" To: Christopher Morrow Thread-Topic: [Idr] Route Leaks and solutions Thread-Index: AQHQst/YBwy3rwbYakKgtnDiHnHcZp3NZLUJgAAwLgCAACk92IAAEGcAgAWPDmCAESuXgIABuyOo Date: Tue, 21 Jul 2015 16:56:45 +0000 Message-ID: References: <005901d0b283$ea07bd20$be173760$@ndzh.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: psg.com; dkim=none (message not signed) header.d=none; x-originating-ip: [2001:67c:370:160:21f3:a411:d0d1:8b05] x-microsoft-exchange-diagnostics: 1; SN1PR09MB0797; 24:/77ZeFBfFegWrvDTxkEQXgJ+esN/Eim5SCvH8/8LU8qm3uyvsjOtMnuwQ1TQMZmlrs/mSsYiP4JKpMXSGsbwzwkRZHb40vuEHAY3ZLeHxXU=; 20:oyS4iah/bGn9eMJg7MegUyMQGwcsBrVVieZhftVFIUshSqhazKPP2AHdUF5OArKjivBB9O05F/WVABEvDe/tMQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR09MB0797; sn1pr09mb0797: X-MS-Exchange-Organization-RulesExecuted 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:SN1PR09MB0797; BCL:0; PCL:0; RULEID:; SRVR:SN1PR09MB0797; x-forefront-prvs: 0644578634 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(62966003)(87936001)(189998001)(77156002)(19580395003)(110136002)(106116001)(86362001)(5001960100002)(99286002)(92566002)(102836002)(2950100001)(2656002)(76576001)(77096005)(15975445007)(74316001)(5003600100002)(54356999)(40100003)(33656002)(76176999)(46102003)(50986999)(122556002)(5002640100001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR09MB0797; H:SN1PR09MB0799.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jul 2015 16:56:45.8133 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR09MB0797 Archived-At: Cc: idr wg list , "sidr wg list \(sidr@ietf.org\)" Subject: Re: [Idr] Route Leaks and solutions 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 Jul 2015 16:57:05 -0000 >If the RLP bit is dependent upon ops folks getting the right >config-bit set for each customer we would want that to be as much >automated as possible so there would be the least chance for 'forgot >to set the bit' or 'set bit incorrectly'. Some sort of mapping of a prefix-route to eBGP neighbors to who it will be = sent to,=20 namely, customers, peers, providers, isn=92t that done already in a routers= currently? >I'm worried that I can't tell reliably what the bit was 2 as-hops >away, did they mean 'customer' ? or was that a mistake? Did someone >change it mid-path to me? Did the implementation of their vendor gear >change/set the wrong attribute value? Initially, only the big ISPs have to get it right (setting the RLP bits).=20 That itself would help reap the benefit substantially. Basically, then one big ISP=92s prefix-routes sent to its customer cannot m= ake =20 a U-turn (route leak) somewhere in its customer cone and be accepted by ano= ther big ISP, even if the ASes in between are not doing it (or they make mistakes with th= eir=20 RLP bits) as long as they do not change any preceding ASs' RLP fields. =20 >There seem to be a bunch of uncertainties with this, in my mind. I >guess that with bgpsec signing this attribute at least 'joe really >meant that jim was his customer', and you can't change the value on a >bgpsec path. > >If we want that, I think having the attribute where it can get changed >(not-bgpsec secured paths) is a real problem, or opens up some pretty >large problems... Like I said in my talk in GROW yesterday, without bgpsec (RLP bits secured)= ,=20 the 99% accidental leaks are detected/mitigated but not the 1% malicious. = =20 With bgpsec (RLP bits secured), the 1% malicious are also detected/mitigate= d. =20 See slide 5: https://www.ietf.org/proceedings/93/slides/slides-93-grow-4.pdf=20 Prior to bgpsec protection, there are two types of attacks that are possible on unprotected RLP bits: 1. Upgrade attack (RLP =3D 01 is altered to RLP =3D 00) to avoid route-leak= detection.=20 That falls in the 1% malicious category (undetected) but no other=20 more egregious damage occurs as a result of this upgrade attack. See more discussion of this in Section 5.1. of the draft: https://www.ietf.org/id/draft-sriram-idr-route-leak-detection-mitigation-01= .txt=20 2. Downgrade attack: (RLP =3D 00 is altered to RLP =3D 01)=20 This does not matter in the 'down' direction because RLP =3D01=20 always allows propagation of the prefix-route in 'down' direction. So this attack (RLP =3D 00 --> RLP =3D 01) matters only when update propaga= tes=20 in the up or lateral peer direction. That would only mean that an alternate update that is not labeled a route l= eak=20 would be preferred by the (provider or peer) over this one. And if there is no alternate update, then for reachability, the only prefix-route that seems like a leak might still be accepted. But this is left up to operator policy. =20 Sriram= From nobody Tue Jul 21 12:37: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 3F5C21B2B20 for ; Tue, 21 Jul 2015 12:37:18 -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 izxoXleylWyn for ; Tue, 21 Jul 2015 12:37:16 -0700 (PDT) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 661A11B2AA4 for ; Tue, 21 Jul 2015 12:37:02 -0700 (PDT) Received: by ykax123 with SMTP id x123so175037736yka.1 for ; Tue, 21 Jul 2015 12:37:01 -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=QUiVpfFDCywHVbDB5oz4O2EZgUGCIU/CraUrj3Ubx+0=; b=LpFJgDLWCQ9YqAXkLtfBuCHi53yzjeIjQ4F7kgI1DuEbUOeYHThVZdBW5ZcEmYvaQ9 yXV2O6XSVyJyiuRos3n3VDyepD46mqds3R38jJRFQa+EyscjxalgV6iBsc3048bbpZDA jF4jBzcF01SmeQ8tpL1pGeLoaUamcBwqX17WUKNQbEiUzBlzd3D4f0dFMGjxRpJ8gBRU BLhA/8aGsuYMX6ETyQNOqNdtSvt7EMuI4x6WtJ7gL0QiC5vdP5aDbGlf73o5T+VUwP/j 0icpHTRLYiWoVnl5cGKxE9CavGxck9QICCsiw09q6itI72KmtKlm1uZGjemwa7eNdUlG +BiQ== MIME-Version: 1.0 X-Received: by 10.170.124.138 with SMTP id q132mr34543674ykb.52.1437507421823; Tue, 21 Jul 2015 12:37:01 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.13.228.196 with HTTP; Tue, 21 Jul 2015 12:37:01 -0700 (PDT) In-Reply-To: <1437488969.3167944.329199849.26B6E5D7@webmail.messagingengine.com> References: <1437488969.3167944.329199849.26B6E5D7@webmail.messagingengine.com> Date: Tue, 21 Jul 2015 15:37:01 -0400 X-Google-Sender-Auth: qZjLdAlldTptybacV7mcvuESIn8 Message-ID: From: Christopher Morrow To: Shane Amante Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "idr@ietf.org List" Subject: Re: [Idr] draft-mauch-bgp-reject 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 Jul 2015 19:37:18 -0000 (in general I like the proposal as is, shane makes a fun second option, more below) On Tue, Jul 21, 2015 at 10:29 AM, Shane Amante wrote: > > And, now for a more controversial recommendation. More specifically, > perhaps it's time to (more seriously) consider additional, default > fail-safe mechanism(s) in BGP. Specifically, what if the _default_ > behavior for eBGP learned routes was to tag all received routes with the > standard BGP NO_EXPORT community? In theory, that would obligate an why not 'no_advertise' ? why even let the listener send it beyond itself at all? It's pretty clearn when your whole AS can't hear the new peer that you messed up. (slice/dice with NEW_No_Advertise as you will...) note that any of these solutions does mean that me seeing 'no-export' to you (or the ability of me to do that that already exists and might already be used) means policy bits get 'more complicated' because now: "if no-export; set no-export internal-community etc... else; delete no-export done' which seems weird... maybe the proposal is some 'hidden' policy such that once ANY policy exists 'no-export' is just regular no-export... that seems sane enough. From nobody Tue Jul 21 12:46:02 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 099931B2B47 for ; Tue, 21 Jul 2015 12:46:01 -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 kAgjv_z3oXvA for ; Tue, 21 Jul 2015 12:45:59 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::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 356AC1A1B7B for ; Tue, 21 Jul 2015 12:45:59 -0700 (PDT) Received: by wibud3 with SMTP id ud3so125833832wib.1 for ; Tue, 21 Jul 2015 12:45:58 -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=VJP1LU+D8rMtRyoLgKY/hjAVrtoze6UvRWITnUK/wVQ=; b=EitceI+CRxFqdHJTVJyWcOJd4XXdrb01RETLyaWwHycVqa3hQmLu/T6ZGABMkMtTxv Lz/MySnWdt4HVqtzha4RUplq9ascXTOeAZJ/QxXwdaGaTHBhQGRNSp74WelntT52Shcx 1zf06BKi/vJrzDJT4KoBErCxzk7pjwNiya8KH+crAZu/7Phhz1xt/CLEZg3ORcTqKf8X 5nvFPkmXRkikSlxHDrW38NLXozFjpCTINjUnLTTtg7kUJnipA89mgW7BLs4SaYByK2R4 emr+vjh2qr7juEretOzGCNfKwnZrTGaDv09Y7va+ppuTHJT5qYbxXpMBOe2TTR79rN9n XM8w== MIME-Version: 1.0 X-Received: by 10.180.80.229 with SMTP id u5mr33113399wix.92.1437507957987; Tue, 21 Jul 2015 12:45:57 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.194.95.168 with HTTP; Tue, 21 Jul 2015 12:45:57 -0700 (PDT) In-Reply-To: References: <1437488969.3167944.329199849.26B6E5D7@webmail.messagingengine.com> Date: Tue, 21 Jul 2015 21:45:57 +0200 X-Google-Sender-Auth: NutFmE80io-vRSb-vR7vQT-eDx8 Message-ID: From: Robert Raszuk To: Christopher Morrow Content-Type: multipart/alternative; boundary=f46d04428e4032a054051b67e7e6 Archived-At: Cc: Shane Amante , "idr@ietf.org List" Subject: Re: [Idr] draft-mauch-bgp-reject 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 Jul 2015 19:46:01 -0000 --f46d04428e4032a054051b67e7e6 Content-Type: text/plain; charset=UTF-8 I guess one needs to first answer what does it mean to configure a policy ? I can already see sys-wish requests for global knob: *"bgp policy [send | receive | both] all" * just like we have been typing "no synchronization" for ages. If not vendor knobs YANG will likely have such construct either standardized or developed in house. Assume such knob will show up - how much does this help to the original issue ? Thx, Robert. On Tue, Jul 21, 2015 at 9:37 PM, Christopher Morrow wrote: > (in general I like the proposal as is, shane makes a fun second > option, more below) > > On Tue, Jul 21, 2015 at 10:29 AM, Shane Amante > wrote: > > > > And, now for a more controversial recommendation. More specifically, > > perhaps it's time to (more seriously) consider additional, default > > fail-safe mechanism(s) in BGP. Specifically, what if the _default_ > > behavior for eBGP learned routes was to tag all received routes with the > > standard BGP NO_EXPORT community? In theory, that would obligate an > > why not 'no_advertise' ? why even let the listener send it beyond > itself at all? It's pretty clearn when your whole AS can't hear the > new peer that you messed up. > > (slice/dice with NEW_No_Advertise as you will...) > > note that any of these solutions does mean that me seeing 'no-export' > to you (or the ability of me to do that that already exists and might > already be used) means policy bits get 'more complicated' because now: > "if no-export; > set no-export internal-community etc... > else; > delete no-export > done' > > > which seems weird... maybe the proposal is some 'hidden' policy such > that once ANY policy exists 'no-export' is just regular no-export... > that seems sane enough. > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --f46d04428e4032a054051b67e7e6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I guess on= e needs to first answer what does it mean to configure a policy ?=C2=A0

I can already see sys-wis= h requests for global knob:

"bgp policy [send | receive | both] all"=C2=A0
=

just like we have been typi= ng "no synchronization" for ages. If not vendor knobs YANG will l= ikely have such construct either standardized or developed in house.
<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ;font-size:small">
Assume such knob will show u= p - how much does this help to the original issue ?

Thx,
Robert.


On Tue, Jul 21, 2015 at 9:37 PM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
(in general I like the proposal as is, shane makes a fun second
option, more below)

On Tue, Jul 21, 2015 at 10:29 AM, Shane Amante <shane@castlepoint.net> wrote:
>
> And, now for a more controversial recommendation.=C2=A0 More specifica= lly,
> perhaps it's time to (more seriously) consider additional, default=
> fail-safe mechanism(s) in BGP.=C2=A0 Specifically, what if the _defaul= t_
> behavior for eBGP learned routes was to tag all received routes with t= he
> standard BGP NO_EXPORT community? In theory, that would obligate an
why not 'no_advertise' ? why even let the listener send it b= eyond
itself at all? It's pretty clearn when your whole AS can't hear the=
new peer that you messed up.

(slice/dice with NEW_No_Advertise as you will...)

note that any of these solutions does mean that me seeing 'no-export= 9;
to you (or the ability of me to do that that already exists and might
already be used) means policy bits get 'more complicated' because n= ow:
=C2=A0 "if no-export;
=C2=A0 =C2=A0 =C2=A0set no-export internal-community etc...
=C2=A0 else;
=C2=A0 =C2=A0 =C2=A0delete no-export
=C2=A0 done'


which seems weird... maybe the proposal is some 'hidden' policy suc= h
that once ANY policy exists 'no-export' is just regular no-export..= .
that seems sane enough.

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

--f46d04428e4032a054051b67e7e6-- From nobody Tue Jul 21 14:34:49 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 E6FAF1B30CE for ; Tue, 21 Jul 2015 14:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iNo6G_JkttBD for ; Tue, 21 Jul 2015 14:34:46 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F5F41B30B9 for ; Tue, 21 Jul 2015 14:34:45 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 8DCC32071E for ; Tue, 21 Jul 2015 17:34:44 -0400 (EDT) Received: from web2 ([10.202.2.212]) by compute5.internal (MEProxy); Tue, 21 Jul 2015 17:34:44 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=castlepoint.net; h=content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=i3D1kC9xcx2T0chgC8Ro45lF24c=; b=IVJs2i BBq+r1M1URMZD6JFrgO4toYOQ0Pbir/gNgcM7szMiR1W6Nlk3klvpoctyS1ESlYu kNtofE//ZS4mXpQ67mx2vATr6uRDKdyOIMSsBcT9rp+NZ+8xCWI9bQ3heYFoPrfK pnsfznAcoZXJK9Q3AtYN8JlmLISD5glfHiKP8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=i3D1kC9xcx2T0ch gC8Ro45lF24c=; b=WuZIYtawGwHw80kn5av5/42oZMOhOYKNalzp2wN9K8dRnPD z1/hRVd0HiE824Tgg2bw4x1xys1fLf0mJ72JOyXDH/ToMk8bC0Qe7TjQaZ2GQtyv xMjFu9eix/hftE6r8ggVpdQVyXGdiqlaf3eIvVqCq6b3cxNfRD9xOijtvoDs= Received: by web2.nyi.internal (Postfix, from userid 99) id 61E00541845; Tue, 21 Jul 2015 17:34:44 -0400 (EDT) Message-Id: <1437514484.536600.329607921.1B4BFD01@webmail.messagingengine.com> X-Sasl-Enc: ewIjkBggqvVBh5EydgTseGctgmQAcCPaAbueFZo4FHmG 1437514484 From: Shane Amante To: idr@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-63a5d8c6 Date: Tue, 21 Jul 2015 15:34:44 -0600 In-Reply-To: References: <1437488969.3167944.329199849.26B6E5D7@webmail.messagingengine.com> Archived-At: Subject: Re: [Idr] draft-mauch-bgp-reject 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 Jul 2015 21:34:48 -0000 Chris, On Tue, Jul 21, 2015, at 01:37 PM, Christopher Morrow wrote: > (in general I like the proposal as is, shane makes a fun second > option, more below) > > On Tue, Jul 21, 2015 at 10:29 AM, Shane Amante > wrote: > > > > And, now for a more controversial recommendation. More specifically, > > perhaps it's time to (more seriously) consider additional, default > > fail-safe mechanism(s) in BGP. Specifically, what if the _default_ > > behavior for eBGP learned routes was to tag all received routes with the > > standard BGP NO_EXPORT community? In theory, that would obligate an > > why not 'no_advertise' ? why even let the listener send it beyond > itself at all? It's pretty clearn when your whole AS can't hear the > new peer that you messed up. IMHO, I think declaring the route as "unfeasible" means it's not even used for forwarding by the local router that first receives it without an explicit action on the part of the operator to enable it to be advertised further within their ASN. > (slice/dice with NEW_No_Advertise as you will...) > > note that any of these solutions does mean that me seeing 'no-export' > to you (or the ability of me to do that that already exists and might > already be used) means policy bits get 'more complicated' because now: > "if no-export; > set no-export internal-community etc... > else; > delete no-export > done' Good point. This may another reason why we want to define NEW_NO_EXPORT that is specific to this new default policy of not advertising routes learned by your ASN, from external peers, to propagate outside your ASN, toward external peers. -shane > which seems weird... maybe the proposal is some 'hidden' policy such > that once ANY policy exists 'no-export' is just regular no-export... > that seems sane enough. > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Tue Jul 21 14:43:37 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 7FDDC1B30BA for ; Tue, 21 Jul 2015 14:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.212 X-Spam-Level: X-Spam-Status: No, score=-4.212 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 q8e4ymRFO22Q for ; Tue, 21 Jul 2015 14:43:34 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by ietfa.amsl.com (Postfix) with ESMTP id 76F1A1B2B47 for ; Tue, 21 Jul 2015 14:43:34 -0700 (PDT) Received: by puck.nether.net (Postfix, from userid 162) id AF88A5409BE; Tue, 21 Jul 2015 17:43:33 -0400 (EDT) Date: Tue, 21 Jul 2015 17:43:33 -0400 From: Jared Mauch To: Robert Raszuk Message-ID: <20150721214333.GC11661@puck.nether.net> References: <1437488969.3167944.329199849.26B6E5D7@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: Shane Amante , "idr@ietf.org List" Subject: Re: [Idr] draft-mauch-bgp-reject 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 Jul 2015 21:43:36 -0000 On Tue, Jul 21, 2015 at 09:45:57PM +0200, Robert Raszuk wrote: > I guess one needs to first answer what does it mean to configure a policy ? > > I can already see sys-wish requests for global knob: > > *"bgp policy [send | receive | both] all" * Something as simple as: route-policy accept-all pass end-policy policy-statement accept-all { then accept; } I'm not asking this be complex. As mentioned IOS-XR already has a directive to disable the default secure behavior. I think it's clear this is not recommended by the command name: bgp unsafe-ebgp-policy >From the Cisco documentation: --snip-- External BGP (eBGP) neighbors must have an inbound and outbound policy configured. If no policy is configured, no routes are accepted from the neighbor, nor are any routes advertised to it. This added security measure ensures that routes cannot accidentally be accepted or advertised in the case of a configuration omission error. --snip -- My intent is to codify this has part of the BGP standard. Knowing that Cisco, Juniper and others already recognise the security risk is critical guidance for other implementors. > just like we have been typing "no synchronization" for ages. If not vendor > knobs YANG will likely have such construct either standardized or developed > in house. Sure, or things like "bgp redistribute-internal" which are undesirable in many environments but may be necessary for network transitions. > Assume such knob will show up - how much does this help to the original > issue ? I'm not sure what your proposed knob is as this is documenting the default for IOS-XR, JunOS and others that have recognised this risk. A common issue we see is customers having no policy configured and reflecting the full table back to us, or sending us the full table of their other upstreams as a result. Examples of this are observed in data over the past 8 years collected and documented as part of the route leaks draft. - Jared > > Thx, > Robert. > > > On Tue, Jul 21, 2015 at 9:37 PM, Christopher Morrow > wrote: > > > (in general I like the proposal as is, shane makes a fun second > > option, more below) > > > > On Tue, Jul 21, 2015 at 10:29 AM, Shane Amante > > wrote: > > > > > > And, now for a more controversial recommendation. More specifically, > > > perhaps it's time to (more seriously) consider additional, default > > > fail-safe mechanism(s) in BGP. Specifically, what if the _default_ > > > behavior for eBGP learned routes was to tag all received routes with the > > > standard BGP NO_EXPORT community? In theory, that would obligate an > > > > why not 'no_advertise' ? why even let the listener send it beyond > > itself at all? It's pretty clearn when your whole AS can't hear the > > new peer that you messed up. > > > > (slice/dice with NEW_No_Advertise as you will...) > > > > note that any of these solutions does mean that me seeing 'no-export' > > to you (or the ability of me to do that that already exists and might > > already be used) means policy bits get 'more complicated' because now: > > "if no-export; > > set no-export internal-community etc... > > else; > > delete no-export > > done' > > > > > > which seems weird... maybe the proposal is some 'hidden' policy such > > that once ANY policy exists 'no-export' is just regular no-export... > > that seems sane enough. > > > > _______________________________________________ > > 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 -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From nobody Tue Jul 21 14:49: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 852E21B30D6 for ; Tue, 21 Jul 2015 14:49:18 -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 DnoaT9iw8OuW for ; Tue, 21 Jul 2015 14:49:16 -0700 (PDT) Received: from thorn.blackrose.org (thorn.blackrose.org [192.131.22.7]) by ietfa.amsl.com (Postfix) with ESMTP id C948F1B30D3 for ; Tue, 21 Jul 2015 14:49:16 -0700 (PDT) Received: from [10.0.1.3] (c-68-49-163-78.hsd1.mi.comcast.net [68.49.163.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by thorn.blackrose.org (Postfix) with ESMTP id F118B1AA8045; Tue, 21 Jul 2015 17:49:15 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) Content-Type: multipart/signed; boundary="Apple-Mail=_F24E1194-F92D-476C-B52F-BAE3A3662649"; protocol="application/pkcs7-signature"; micalg=sha1 From: Dorian Kim In-Reply-To: <1437514484.536600.329607921.1B4BFD01@webmail.messagingengine.com> Date: Tue, 21 Jul 2015 17:49:14 -0400 Message-Id: References: <1437488969.3167944.329199849.26B6E5D7@webmail.messagingengine.com> <1437514484.536600.329607921.1B4BFD01@webmail.messagingengine.com> To: Shane Amante X-Mailer: Apple Mail (2.2102) Archived-At: Cc: idr@ietf.org Subject: Re: [Idr] draft-mauch-bgp-reject 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 Jul 2015 21:49:18 -0000 --Apple-Mail=_F24E1194-F92D-476C-B52F-BAE3A3662649 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Shane and Chris, > On Jul 21, 2015, at 5:34 PM, Shane Amante = wrote: >=20 > Chris, >=20 > On Tue, Jul 21, 2015, at 01:37 PM, Christopher Morrow wrote: >>=20 >> On Tue, Jul 21, 2015 at 10:29 AM, Shane Amante = >> wrote: >>>=20 >>> And, now for a more controversial recommendation. More = specifically, >>> perhaps it's time to (more seriously) consider additional, default >>> fail-safe mechanism(s) in BGP. Specifically, what if the _default_ >>> behavior for eBGP learned routes was to tag all received routes with = the >>> standard BGP NO_EXPORT community? In theory, that would obligate an >>=20 >> why not 'no_advertise' ? why even let the listener send it beyond >> itself at all? It's pretty clearn when your whole AS can't hear the >> new peer that you messed up. >=20 > IMHO, I think declaring the route as "unfeasible" means it's not even > used for forwarding by the local router that first receives it without > an explicit action on the part of the operator to enable it to be > advertised further within their ASN. =20 >=20 >> (slice/dice with NEW_No_Advertise as you will...) >>=20 >> note that any of these solutions does mean that me seeing 'no-export' >> to you (or the ability of me to do that that already exists and might >> already be used) means policy bits get 'more complicated' because = now: >> "if no-export; >> set no-export internal-community etc... >> else; >> delete no-export >> done' >=20 > Good point. This may another reason why we want to define = NEW_NO_EXPORT > that is specific to this new default policy of not advertising routes > learned by your ASN, from external peers, to propagate outside your = ASN, > toward external peers. Since the semantics of NO_EXPORT is well established and the behavior = you=E2=80=99d want here is orthogonal to the behavior the existing NO_EXPORT community, I = think you=E2=80=99d want to come up with a complete new community label such as SUPPRESS or = REJECT. I don=E2=80=99t think we have anything to gain from overloading an = existing label with a new behavior or meaning. One advantage I can think of with your idea compared to the original is = that if you advertise routes with a tag that declares them unfeasible, the peer can still = potentially see the misbehavior without have that negatively effect their forwarding and = perhaps poll/monitor for such to for human intervention. Having said that I=E2=80=99m ambivalent as to whether this is a better = option than the original=20 proposal. -dorian= --Apple-Mail=_F24E1194-F92D-476C-B52F-BAE3A3662649 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMZjCCBiow ggUSoAMCAQICAw7AwjANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTE1MDcxOTA1NTcxMloXDTE2MDcxOTAzMzExM1owRDEdMBsGA1UEAwwUZG9yaWFuQGJsYWNr cm9zZS5vcmcxIzAhBgkqhkiG9w0BCQEWFGRvcmlhbkBibGFja3Jvc2Uub3JnMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyBljJix+2u/w0TvjmLDTI2t3jfU1u1Qx/5VDUCEH5pZfDs+K O1nC+8KqBXvjAM6UJkI2OhK/S2yu9GxyoiFqa08Fl4v9TGYsUyf/s6B1BHNQ9IRyvoNzUxh9vsf0 BCR9WJ6mrKwgzahPLBYK70oZkU9ZlVrP3qES6NesKu1+53ifggH/2DnhHzuVrttH4YZhIIqrJCkA +vXzHZ9DEapFvknCJVAcZfkDvZP5ZGTXRydfEMhwN/Qa8ul5O1qOkV27RWwhRyR1ejDXDjJyYhZa 5/LbZajbRHiKZUOM/v47ZBY5bZRW9tzNoc7dZL2eeJRmwkeWjPeRTx9nHln4E9Uf/wIDAQABo4IC 2jCCAtYwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUF BwMEMB0GA1UdDgQWBBQ77OMGX4LoF4Y3uMuaZ3IqaY/bmTAfBgNVHSMEGDAWgBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHREEGDAWgRRkb3JpYW5AYmxhY2tyb3NlLm9yZzCCAUwGA1UdIASCAUMw ggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9u IEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0 byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0Eg cG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlh bmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVo dHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkG CCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2Ew QgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xp ZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcN AQEFBQADggEBAMYR3D1OHIoL+rcSoGK/viTRuIeuWS4+qhswoxxZmF7mXSrLiBYc4IqTR+4Go5+w kRvLxyTZCzIMr0RheS+ljwa93Uqwu9zN9vrUVe1P9iPpRObuJxSgAucqiwsRWo15zSrH3D4YlKg1 k97hv2Ey3q+x79HRbw9C6BI17pXCBKMCZB4iYeBDixNcd+uXG/7iMf1Hbol/uvqaS+fTMNUesUFx TxkY1HVjYvcXWSbPzEVRo/Im0KPinr7t1Mk0llSAKF9JUmv5H7np6V/QL7E96lrgPk2HirFofcY6 SPiDSB9oCKdpDJhzcFBt41+SyhpaZQ6+CM16z/Lq5zHnwdeTx3gwggY0MIIEHKADAgECAgEeMA0G CSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVa MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJl IERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQ cmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zP f1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR /wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm 6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHwYD VR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsGAQUFBzAB hhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3Rh cnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDCB gAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9p bnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9eKssBly4Y4xerhy5I3dNoXHY fYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qe tbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoed O61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MX U91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3 OHQgWI270g+5MYA8GfgI/EPT5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8 MQ+Z77U1uL7TelWO5lApsbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/Q vVNKbb43A43ny076khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv 9ePsXklAxtm8J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj /cIq7JRXun0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jGCA28wggNrAgEBMIGUMIGMMQswCQYD VQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwg Q2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IElu dGVybWVkaWF0ZSBDbGllbnQgQ0ECAw7AwjAJBgUrDgMCGgUAoIIBrzAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTA3MjEyMTQ5MTVaMCMGCSqGSIb3DQEJBDEWBBSw QVWbGARjkNolqnVrzVRweM0nJjCBpQYJKwYBBAGCNxAEMYGXMIGUMIGMMQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNh dGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0ECAw7AwjCBpwYLKoZIhvcNAQkQAgsxgZeggZQwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQIDDsDCMA0GCSqGSIb3DQEBAQUABIIBACOLgSoC9wcVG30rvlDyb3MxN2I9h7sK woY17X6KxbJl5oPMJVSSrp9HbhhywROKPdgBkZdXlnRdXu8xRUz1+ThdOmLvuo3cdZkwY3GSaKTY zpM9eSld5P/HNEiJ2volU8q3dQidVYjfg1dTTcPRpRkyFlkZiB2IgIJN7Xk2JxmHHIHcwHzHJmQB 1nHNIVLvJAYPUmhPKPJstJ4Hhr8GEU4l/WM3i93sZygI4jEu8p0B81h27a5x+Tgo8YBA+KoOb+Oe nf/ut+C1xRBwc6Oxm7jqWdNN6rykFm+vyEds8qSVkVE6Ky2ytFPACfc5ixyJlwOUvTHVnM9rI9vY eymYT40AAAAAAAA= --Apple-Mail=_F24E1194-F92D-476C-B52F-BAE3A3662649-- From nobody Tue Jul 21 14:50:03 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 A08041B30D4 for ; Tue, 21 Jul 2015 14:50:01 -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 TUlM1vPDgSRF for ; Tue, 21 Jul 2015 14:50:00 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::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 597B51A88D5 for ; Tue, 21 Jul 2015 14:50:00 -0700 (PDT) Received: by wicmv11 with SMTP id mv11so56809963wic.0 for ; Tue, 21 Jul 2015 14:49:59 -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=cyHRXPl9u/eH1ZMaxsi+zfrhx9ivbLQw/IG0zwiUTCk=; b=xEaFl3GVvyQw1/iuMe1jX+gwxkLH9+HktAoHPkPUH/tEFCgbUMo3U4qizECp+BSmNs SOfZR23lFGlpqz1BaPvDuoXSBrZqRbPennS9M6vFeONE8SFzQzLuJWKnxErDTmJUS2QR 5M5Ch/7bi80SelOBKJKbluc8TLHm6dzv+HHhTFNB4oFIjBWgttTTM2FO5SIskexQKumv y5do7kk1IMZwpoDh1XGK4BW/MnLWQTNOfuJdM4d+b8+b55FhaX1jQ5GSgQHRgMfibC0g n8l/oRBHEYdV0F0nQj1TFKQVzektK4CTmResVjLj8n2Ne+vShJ3/Dy1KbicG6cWnn80G plMw== MIME-Version: 1.0 X-Received: by 10.180.80.229 with SMTP id u5mr33835066wix.92.1437515399166; Tue, 21 Jul 2015 14:49:59 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.194.95.168 with HTTP; Tue, 21 Jul 2015 14:49:59 -0700 (PDT) In-Reply-To: <20150721214333.GC11661@puck.nether.net> References: <1437488969.3167944.329199849.26B6E5D7@webmail.messagingengine.com> <20150721214333.GC11661@puck.nether.net> Date: Tue, 21 Jul 2015 23:49:59 +0200 X-Google-Sender-Auth: ETpMheXYiyCetWWicm6nNmzitGg Message-ID: From: Robert Raszuk To: Jared Mauch Content-Type: multipart/alternative; boundary=f46d04428e40ba00e6051b69a271 Archived-At: Cc: Shane Amante , "idr@ietf.org List" Subject: Re: [Idr] draft-mauch-bgp-reject 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 Jul 2015 21:50:01 -0000 --f46d04428e40ba00e6051b69a271 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =E2=80=8BHi Jared,=E2=80=8B > A common issue we see is customers having no policy configured > and reflecting the full table back to us, or sending us the full table > of their other upstreams as a result. Examples of this are observed in > data over the past 8 years collected and documented as part of the > route leaks draft. > =E2=80=8BNo doubt. I am also very much aware about difference of XR/JUNOS vs IOS-XE BGP behavior. But my point was that those who do not care to filter =E2=80=8Bwill just li= kely configure a global knob so you will still be receiving full tables of their upstreams. So while I am all for documenting it in IETF and even more in Nanog/RIPE/*NOGs perhaps we need to try to go a bit further and apply penalty to sessions which send you junk and you recognize it. Thx, r. --f46d04428e40ba00e6051b69a271 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=E2=80=8BHi Jared,=E2=80=8B
=C2=A0
<= /div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 A common is= sue we see is customers having no policy configured
and reflecting the full table back to us, or sending us the full table
of their other upstreams as a result.=C2=A0 Examples of this are observed i= n
data over the past 8 years collected and documented as part of the
route leaks draft.

= =E2=80=8BNo doubt.=C2=A0

I am also very much aware about difference of XR/JUNOS vs IOS-XE BGP beh= avior.=C2=A0

But my po= int was that those who do not care to filter =E2=80=8Bwill just likely conf= igure a global knob so you will still be receiving full tables of their ups= treams.=C2=A0

So w= hile I am all for documenting it in IETF and even more in Nanog/RIPE/*NOGs = perhaps we need to try to go a bit further and apply penalty to sessions wh= ich send you junk and you recognize it.=C2=A0

<= /div>
Thx,
r.


=C2=A0
--f46d04428e40ba00e6051b69a271-- From nobody Tue Jul 21 14:57:03 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 7BF3A1B2FB1 for ; Tue, 21 Jul 2015 14:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.212 X-Spam-Level: X-Spam-Status: No, score=-4.212 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 mVpAaYbzbb-x for ; Tue, 21 Jul 2015 14:56:57 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by ietfa.amsl.com (Postfix) with ESMTP id 1E50F1B2F1F for ; Tue, 21 Jul 2015 14:56:57 -0700 (PDT) Received: by puck.nether.net (Postfix, from userid 162) id BF6CB5409E9; Tue, 21 Jul 2015 17:56:56 -0400 (EDT) Date: Tue, 21 Jul 2015 17:56:56 -0400 From: Jared Mauch To: Robert Raszuk Message-ID: <20150721215656.GA19579@puck.nether.net> References: <1437488969.3167944.329199849.26B6E5D7@webmail.messagingengine.com> <20150721214333.GC11661@puck.nether.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: Shane Amante , "idr@ietf.org List" Subject: Re: [Idr] draft-mauch-bgp-reject 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 Jul 2015 21:57:01 -0000 On Tue, Jul 21, 2015 at 11:49:59PM +0200, Robert Raszuk wrote: > ​Hi Jared,​ > > > > A common issue we see is customers having no policy configured > > and reflecting the full table back to us, or sending us the full table > > of their other upstreams as a result. Examples of this are observed in > > data over the past 8 years collected and documented as part of the > > route leaks draft. > > > > ​No doubt. > > I am also very much aware about difference of XR/JUNOS vs IOS-XE BGP > behavior. It would be my contention that software which is not adhering to this best practice SHOULD adopt this measure, at least for newly configured devices. This is nothing new for vendors having lived through the BGP_REORG days of IOS to end with the now more robust multi-afi support. The systems know the difference between an old config and a new device without a config and result with different configuration directives and defaults as a result which do not compromise the operation of these networks. > But my point was that those who do not care to filter ​will just likely > configure a global knob so you will still be receiving full tables of their > upstreams. People often drive without insurance or go outside in weather improperly prepared. We can't help people who ice fish and cut the hole around their own feet. > So while I am all for documenting it in IETF and even more in > Nanog/RIPE/*NOGs perhaps we need to try to go a bit further and apply > penalty to sessions which send you junk and you recognize it. I'm glad you support this effort. We do our best to filter customer sessions despite some attacks on my $dayjob network for being recently involved in routing leaks. We all have troubles and reducing the default behavior impact will make BGP more robust and easier to troubleshoot across implementations. - Jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From nobody Tue Jul 21 15:03: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 67B7E1B300E for ; Tue, 21 Jul 2015 15:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.212 X-Spam-Level: X-Spam-Status: No, score=-4.212 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ANeCvJ6t9FHV for ; Tue, 21 Jul 2015 15:03:32 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by ietfa.amsl.com (Postfix) with ESMTP id 7CA4B1B2F63 for ; Tue, 21 Jul 2015 15:03:32 -0700 (PDT) Received: by puck.nether.net (Postfix, from userid 162) id 1961F5409E2; Tue, 21 Jul 2015 18:03:32 -0400 (EDT) Date: Tue, 21 Jul 2015 18:03:32 -0400 From: Jared Mauch To: Dorian Kim Message-ID: <20150721220331.GB19579@puck.nether.net> References: <1437488969.3167944.329199849.26B6E5D7@webmail.messagingengine.com> <1437514484.536600.329607921.1B4BFD01@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: Shane Amante , idr@ietf.org Subject: [Idr] NO_EXPORT Re: draft-mauch-bgp-reject 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 Jul 2015 22:03:34 -0000 On Tue, Jul 21, 2015 at 05:49:14PM -0400, Dorian Kim wrote: > Shane and Chris, > > > On Jul 21, 2015, at 5:34 PM, Shane Amante wrote: > > > > Chris, > > > > On Tue, Jul 21, 2015, at 01:37 PM, Christopher Morrow wrote: > >> > >> On Tue, Jul 21, 2015 at 10:29 AM, Shane Amante > >> wrote: > >>> > >>> And, now for a more controversial recommendation. More specifically, > >>> perhaps it's time to (more seriously) consider additional, default > >>> fail-safe mechanism(s) in BGP. Specifically, what if the _default_ > >>> behavior for eBGP learned routes was to tag all received routes with the > >>> standard BGP NO_EXPORT community? In theory, that would obligate an > >> > >> why not 'no_advertise' ? why even let the listener send it beyond > >> itself at all? It's pretty clearn when your whole AS can't hear the > >> new peer that you messed up. > > > > IMHO, I think declaring the route as "unfeasible" means it's not even > > used for forwarding by the local router that first receives it without > > an explicit action on the part of the operator to enable it to be > > advertised further within their ASN. > > > >> (slice/dice with NEW_No_Advertise as you will...) > >> > >> note that any of these solutions does mean that me seeing 'no-export' > >> to you (or the ability of me to do that that already exists and might > >> already be used) means policy bits get 'more complicated' because now: > >> "if no-export; > >> set no-export internal-community etc... > >> else; > >> delete no-export > >> done' > > > > Good point. This may another reason why we want to define NEW_NO_EXPORT > > that is specific to this new default policy of not advertising routes > > learned by your ASN, from external peers, to propagate outside your ASN, > > toward external peers. > > Since the semantics of NO_EXPORT is well established and the behavior you’d want > here is orthogonal to the behavior the existing NO_EXPORT community, I think you’d > want to come up with a complete new community label such as SUPPRESS or REJECT. > I don’t think we have anything to gain from overloading an existing label with a new > behavior or meaning. One common frustration I personally have with NO_EXPORT is that on (for example IOS) when processing communities received by a peer or customer, if you set any of your own communities and do not specify "additive" it clears the NO_EXPORT community which is often not what a operator expects. I received feedback releated to the default-reject stance that other things should be default-on, such as send-community and other directives that are often part of configuration guides. If we believe there should be directives to developers for additional default behaviors, there is perhaps more work here we can undertake. The lack of predictibility in implementations does lead to operator confusion. - Jared > One advantage I can think of with your idea compared to the original is that if you advertise > routes with a tag that declares them unfeasible, the peer can still potentially see the > misbehavior without have that negatively effect their forwarding and perhaps poll/monitor > for such to for human intervention. > > Having said that I’m ambivalent as to whether this is a better option than the original > proposal. > > -dorian > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From nobody Tue Jul 21 23:40:57 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 C03041ACD7B for ; Tue, 21 Jul 2015 23:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.212 X-Spam-Level: X-Spam-Status: No, score=-4.212 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 przNbu2MiI5u for ; Tue, 21 Jul 2015 23:40:54 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by ietfa.amsl.com (Postfix) with ESMTP id 8AA6C1A8999 for ; Tue, 21 Jul 2015 23:40:54 -0700 (PDT) Received: by puck.nether.net (Postfix, from userid 507) id C99A35408A1; Wed, 22 Jul 2015 02:40:53 -0400 (EDT) Date: Wed, 22 Jul 2015 02:40:53 -0400 From: Jon Mitchell To: Susan Hares Message-ID: <20150722064053.GA23496@puck.nether.net> References: <006001d0c309$3164b570$942e2050$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <006001d0c309$3164b570$942e2050$@ndzh.com> User-Agent: Mutt/1.5.23+102 (2ca89bed6448) (2014-03-12) Archived-At: Cc: 'idr wg list' Subject: Re: [Idr] WG Adoption call - draft-keyupate-idr-bgp-prefix-sid (7/20 to 8/3) 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 Jul 2015 06:40:55 -0000 On 20/07/15 12:29 -0400, Susan Hares wrote: > This begins a 2 week WG Adoption call for draft-keyupate-idr-bgp-prefix-sid > (7/20 to 8/3/2015). > > http://datatracker.ietf.org/doc/draft-keyupate-idr-bgp-prefix-sid/ > > We would appreciate if you would answer the following questions: > > 1) Do you know of networks where this new BGP feature would useful? Yes > > 2) Do you know of any technical issues with this draft? > No > In your discussion, please include whether you support the draft or not? Support. -Jon From nobody Wed Jul 22 00:33: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 594881B2CDE for ; Wed, 22 Jul 2015 00:33:43 -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 b-Rc733IXuEm for ; Wed, 22 Jul 2015 00:33:42 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id CD4141B2CE1 for ; Wed, 22 Jul 2015 00:33:40 -0700 (PDT) Received: by puck.nether.net (Postfix, from userid 507) id 73F195406F2; Wed, 22 Jul 2015 03:33:40 -0400 (EDT) Date: Wed, 22 Jul 2015 03:33:40 -0400 From: Jon Mitchell To: Shane Amante Message-ID: <20150722073340.GA30425@puck.nether.net> References: <1437488969.3167944.329199849.26B6E5D7@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1437488969.3167944.329199849.26B6E5D7@webmail.messagingengine.com> User-Agent: Mutt/1.5.23+102 (2ca89bed6448) (2014-03-12) Archived-At: Cc: idr@ietf.org Subject: Re: [Idr] draft-mauch-bgp-reject 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 Jul 2015 07:33:43 -0000 On 21/07/15 08:29 -0600, Shane Amante wrote: > Jared, > > This is a good draft ... Agreed and support pursueing this as a BCP. > don't read Release Notes, etc. If that's the case, then what if instead > there was a proposal for a new, standard BGP community called, i.e.: > NEW_NO_EXPORT, which would have a different code point from NO_EXPORT, > but the same properties as NO_EXPORT? IOW, legacy BGP implementations > would not notice and act upon the NEW_NO_EXPORT community, thus not > creating a dramatic "surprise" on operators. However, as new routing SW > with NEW_NO_EXPORT gets deployed we incrementally accrue the proper > scoping of routes within an ASN and more gradual improvement in routing > hygiene. I think this different proposal has limited additional benefit due to it's added implementation and operations complexity. The implementations work to support this is more complex and since it targets the same fix as making default behavior on TX/RX to be REJECT (cause user to apply policy with proper intent) the value is very limited. If an operator would have this proposal after already their implementation supports Jared's proposal, the only additional protection this provides is they applied the wrong policy on inbound peering. Since an ASN does not actually align with organizational boundaries in many cases (Private ASN's, etc..) there are many cases where a large number of their policies will start with the removal of this community on inbound and tag with a "send to internal/customers" or "send to peers/transit" community (unless you are also supposing that an operator can only manipulate this on TX). If so, this only protects you from using the wrong policy if it doesn't contain strip of the added community. Also, for the most basic of BGP users, having to do community manipulation at all seems a bit problematic if their policies today are only aspath or prefix based (which is a perfectly legitimate way to do filtering). -Jon From nobody Wed Jul 22 05:58:59 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 CBC601B3042 for ; Wed, 22 Jul 2015 05:58:56 -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 lc2h2kAVCadP for ; Wed, 22 Jul 2015 05:58:55 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::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 100461A03C7 for ; Wed, 22 Jul 2015 05:58:55 -0700 (PDT) Received: by oibn4 with SMTP id n4so143088313oib.3 for ; Wed, 22 Jul 2015 05:58:54 -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=I+wLwy2isqRHhb9f7FlbjliYF1+7ovEiqIVZq0dayDM=; b=GgufbAt2KM6WnirCfPVGaWts/NtVP8ebUIvfpHyyYOHg2fJsfZORVxT860DAH9mvy8 RnsPR3BXs/OLZmz2e4WAcpRyD979mt7NF70EqzahhOUxbvIHsrctGgFcPP4Tyagj4geA Sv+sTD/1ONNoZZWF2buTn9bNbq7AxFMCTnViF6UB0DTBhfAuaLjHeGvn0g9kSqrfcFsT iPhXdrmoT0D0Wqtmy+vyW+Kq1tzZBz034vPbdFgmP8HAQ1nJT1BLeavwyrtJjNg2rET3 qZCrYhFVXxfG89sM17Z6aFU3EJYQL8GFTr1XI/adNeb1bs0RMQ9fXi+0TbBOgxWtcQyN CKcg== MIME-Version: 1.0 X-Received: by 10.182.230.70 with SMTP id sw6mr2301886obc.48.1437569934551; Wed, 22 Jul 2015 05:58:54 -0700 (PDT) Received: by 10.202.220.87 with HTTP; Wed, 22 Jul 2015 05:58:54 -0700 (PDT) In-Reply-To: <006001d0c309$3164b570$942e2050$@ndzh.com> References: <006001d0c309$3164b570$942e2050$@ndzh.com> Date: Wed, 22 Jul 2015 08:58:54 -0400 Message-ID: From: Mohan Nanduri To: Susan Hares Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: idr wg list Subject: Re: [Idr] WG Adoption call - draft-keyupate-idr-bgp-prefix-sid (7/20 to 8/3) 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 Jul 2015 12:58:57 -0000 1) Do you know of networks where this new BGP feature would useful? Yes. 2) Do you know of any technical issues with this draft? No. In your discussion, please include whether you support the draft or not? Support the draft. Cheers, -Mohan On Mon, Jul 20, 2015 at 12:29 PM, Susan Hares wrote: > This begins a 2 week WG Adoption call for draft-keyupate-idr-bgp-prefix-sid > (7/20 to 8/3/2015). > > http://datatracker.ietf.org/doc/draft-keyupate-idr-bgp-prefix-sid/ > > > > The authors should indicate if there is any IPR related to the draft. > > > > We would appreciate if you would answer the following questions: > > 1) Do you know of networks where this new BGP feature would useful? > > 2) Do you know of any technical issues with this draft? > > > > In your discussion, please include whether you support the draft or not? > > > > Sue Hares and John Scudder > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > From nobody Wed Jul 22 08:12: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 5E4701A0396 for ; Wed, 22 Jul 2015 08:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.02 X-Spam-Level: X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 EUgRkB1wtLWE for ; Wed, 22 Jul 2015 08:12:34 -0700 (PDT) Received: from smtpcmd02111.aruba.it (smtpcmd02111.aruba.it [62.149.158.111]) by ietfa.amsl.com (Postfix) with ESMTP id BC15F1A040C for ; Wed, 22 Jul 2015 08:12:22 -0700 (PDT) Received: from dell-tcastaldi ([31.130.224.109]) by smtpcmd02.ad.aruba.it with bizsmtp id vTCM1q00Q2NEPrz01TCMrt; Wed, 22 Jul 2015 17:12:22 +0200 Date: Wed, 22 Jul 2015 17:12:22 +0200 (CEST) From: Meetecho Team To: idr@ietf.org Message-ID: <2123841289.17.1437577942858.JavaMail.tcastaldi@dell-tcastaldi> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_16_330675554.1437577942857" Archived-At: Subject: [Idr] Meetecho recordings of IDR WG session 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 Jul 2015 15:12:35 -0000 ------=_Part_16_330675554.1437577942857 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, the full recording (synchronized video, audio, slides and jabber room) of the IDR WG session at IETF 93 is available at the following URL: http://ietf93.conf.meetecho.com/index.php/Recorded_Sessions#IDR In case of problems with the playout, just drop an e-mail to ietf-support@meetecho.com. For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. Cheers, the Meetecho Team ------=_Part_16_330675554.1437577942857-- From nobody Wed Jul 22 11:25: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 569D31A1F73 for ; Wed, 22 Jul 2015 11:25:47 -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 sf3iyFNrQv8q for ; Wed, 22 Jul 2015 11:25:46 -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 BC24C1A1EFD for ; Wed, 22 Jul 2015 11:25:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=938; q=dns/txt; s=iport; t=1437589546; x=1438799146; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=rfy9apkqd3XX1LtKwlCmsba2Hzrc/4PuK4FJxOq7Mzg=; b=dzQYJE154LdpHq7BJMLBV2Xv7d+Kgj9plAvQK3SqHtnD9ZVTOzLdOWc/ eEOcO26tILfzAGU4SOzd5yvUiJisz+dfzPAipzKa8r9tcJWGi8/1SEthT dKjmPeaRp/UbfbJ9Dwl4CjGkVLvK2Y/5aHbPMn/NUkdwGFZ5sdTXDtJbp Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AeAwBX369V/4sNJK1bgxVUaQa7dwmBawqGAQKBUDgUAQEBAQEBAYEKhCMBAQEDAQEBARodNAsFCwIBCA4KHhAnCyUCBA4FiCYIDc1mAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4tMhFMzB4MXgRQFlFcBhHSHPYFDRoNXj1GDYSaCDRyBU2+BR4EEAQEB X-IronPort-AV: E=Sophos;i="5.15,524,1432598400"; d="scan'208";a="171338419" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-5.cisco.com with ESMTP; 22 Jul 2015 18:25:45 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t6MIPj0H010226 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Jul 2015 18:25:45 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.72]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Wed, 22 Jul 2015 13:25:44 -0500 From: "Stefano Previdi (sprevidi)" To: Susan Hares Thread-Topic: [Idr] WG Adoption call - draft-keyupate-idr-bgp-prefix-sid (7/20 to 8/3) Thread-Index: AQHQxKvSye2MXy3Rs0SMr4KxDZooMg== Date: Wed, 22 Jul 2015 18:25:44 +0000 Message-ID: <40C9243B-A6A6-4CE1-95F2-7898E6C7CAAA@cisco.com> References: <006001d0c309$3164b570$942e2050$@ndzh.com> In-Reply-To: <006001d0c309$3164b570$942e2050$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.67.209] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: idr wg list Subject: Re: [Idr] WG Adoption call - draft-keyupate-idr-bgp-prefix-sid (7/20 to 8/3) 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 Jul 2015 18:25:47 -0000 On Jul 20, 2015, at 6:29 PM, Susan Hares wrote: > This begins a 2 week WG Adoption call for draft-keyupate-idr-bgp-prefix-s= id (7/20 to 8/3/2015).=20 > http://datatracker.ietf.org/doc/draft-keyupate-idr-bgp-prefix-sid/ > =20 > The authors should indicate if there is any IPR related to the draft. as co-author I support the adoption of this document as WG item and I'm not= aware of any IPR related to it. > We would appreciate if you would answer the following questions: > 1) Do you know of networks where this new BGP feature would useful? yes > 2) Do you know of any technical issues with this draft? no=20 s. > =20 > In your discussion, please include whether you support the draft or not? > =20 > Sue Hares and John Scudder > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Wed Jul 22 12:36: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 19D6B1ACE53 for ; Wed, 22 Jul 2015 12:36:50 -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 UVzWx6LjvHUu for ; Wed, 22 Jul 2015 12:36:48 -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 967471ACE49 for ; Wed, 22 Jul 2015 12:36:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=987; q=dns/txt; s=iport; t=1437593808; x=1438803408; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Z0A9LFYlawYa4q0rQUjcNa6RTJzozDOmr88YwJbcaJ4=; b=co+LHISwOO7kTYk+loUi2wnv8eexof4I5jCO//FYc8MIl1UT1sBK51Pz cyb7TvO7hSdgCJ1UpPDMo3VwuNyJm6M31tMtBstGbwJpTxe5KVMD5Zat5 mhA9Vk6jeqJ7NDVejOe5JSNne69ZxP2koWOSWNcRLBLC1XdPmkgDSib5n c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AeAwD0769V/5FdJa1bgxVUaQa7dwmBawqGAQKBUzgUAQEBAQEBAYEKhCQBAQQBAQEaHTQLEAIBCA4KHhAnCyUCBA4FiC4NzWQBAQEBAQEBAQEBAQEBAQEBAQEBAQEXi0yFBgeEKwWUVwGEdIc9gUNGg1ePUYNhJoINHIFTb4FHgQQBAQE X-IronPort-AV: E=Sophos;i="5.15,525,1432598400"; d="scan'208";a="171249600" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-6.cisco.com with ESMTP; 22 Jul 2015 19:36:47 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t6MJalIh001459 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Jul 2015 19:36:47 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.38]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Wed, 22 Jul 2015 14:36:46 -0500 From: "Bertrand Duvivier (bduvivie)" To: Susan Hares Thread-Topic: [Idr] WG Adoption call - draft-keyupate-idr-bgp-prefix-sid (7/20 to 8/3) Thread-Index: AQHQxLW+mCqs94jyJ0GsBtHYQS7WZg== Date: Wed, 22 Jul 2015 19:36:45 +0000 Message-ID: References: <006001d0c309$3164b570$942e2050$@ndzh.com> <40C9243B-A6A6-4CE1-95F2-7898E6C7CAAA@cisco.com> In-Reply-To: <40C9243B-A6A6-4CE1-95F2-7898E6C7CAAA@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-originating-ip: [10.61.192.114] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: idr wg list Subject: Re: [Idr] WG Adoption call - draft-keyupate-idr-bgp-prefix-sid (7/20 to 8/3) 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 Jul 2015 19:36:50 -0000 I do support the draft 1> YES, more than one. 2> NO >On Jul 20, 2015, at 6:29 PM, Susan Hares wrote: >> This begins a 2 week WG Adoption call for >>draft-keyupate-idr-bgp-prefix-sid (7/20 to 8/3/2015). >> http://datatracker.ietf.org/doc/draft-keyupate-idr-bgp-prefix-sid/ >> =20 >> The authors should indicate if there is any IPR related to the draft. >> We would appreciate if you would answer the following questions: >> 1) Do you know of networks where this new BGP feature would useful? >> 2) Do you know of any technical issues with this draft? >> =20 >> In your discussion, please include whether you support the draft or not? >> =20 >> Sue Hares and John Scudder >> _______________________________________________ >> 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 Wed Jul 22 12:37: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 0C2791A8932 for ; Wed, 22 Jul 2015 12:37:41 -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 yiS86euW9Ohe for ; Wed, 22 Jul 2015 12:37:39 -0700 (PDT) Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BAFA1A0093 for ; Wed, 22 Jul 2015 12:37:39 -0700 (PDT) Received: by ykfw194 with SMTP id w194so121472446ykf.0 for ; Wed, 22 Jul 2015 12:37:38 -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=16h+ahpAmfrcFtwsTqrjhiY3ISBy+qpJ/eG1jbyBcWM=; b=Yhj3dIvmLXvQLr7N7MjWWRZYvi1mc659+hivtF14quPyfYBch1Ug1vthZXX3+ZJ3Nd YumZ2ybcO9rKKKm9UfMNTBrUmcSeSs+SdFmihzzGb6CX9k3ReaFTHe3iPI+gFsMxZ3K9 Nua6bPGyZ7HI59lChLDInT6mTlzVfCt8uDWTT5e12vPsIr8Y4zI17rhnkzJqBvXxYWlv DQNOCI6ie4qyBXns0oVsNxdhHsIduNVIvFtcT3VxlJzX0gMchp17zReNPLM+siUtcBRg ZwDYUstI+EAf1SVaRA71ezWANEKmE+MZSE/QpZR1+fmvXVpVFTUyNbCQpUPXIaY2x42Y eC4A== MIME-Version: 1.0 X-Received: by 10.170.161.4 with SMTP id c4mr4221805ykd.55.1437593858563; Wed, 22 Jul 2015 12:37:38 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.13.228.196 with HTTP; Wed, 22 Jul 2015 12:37:38 -0700 (PDT) In-Reply-To: <1437514484.536600.329607921.1B4BFD01@webmail.messagingengine.com> References: <1437488969.3167944.329199849.26B6E5D7@webmail.messagingengine.com> <1437514484.536600.329607921.1B4BFD01@webmail.messagingengine.com> Date: Wed, 22 Jul 2015 15:37:38 -0400 X-Google-Sender-Auth: D6UJtquGwrDEG_3TDiT_D-Jcomc Message-ID: From: Christopher Morrow To: Shane Amante Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "idr@ietf.org List" Subject: Re: [Idr] draft-mauch-bgp-reject 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 Jul 2015 19:37:41 -0000 On Tue, Jul 21, 2015 at 5:34 PM, Shane Amante wrote: > Chris, > > On Tue, Jul 21, 2015, at 01:37 PM, Christopher Morrow wrote: >> (in general I like the proposal as is, shane makes a fun second >> option, more below) >> >> On Tue, Jul 21, 2015 at 10:29 AM, Shane Amante >> wrote: >> > >> > And, now for a more controversial recommendation. More specifically, >> > perhaps it's time to (more seriously) consider additional, default >> > fail-safe mechanism(s) in BGP. Specifically, what if the _default_ >> > behavior for eBGP learned routes was to tag all received routes with the >> > standard BGP NO_EXPORT community? In theory, that would obligate an >> >> why not 'no_advertise' ? why even let the listener send it beyond >> itself at all? It's pretty clearn when your whole AS can't hear the >> new peer that you messed up. > > IMHO, I think declaring the route as "unfeasible" means it's not even > used for forwarding by the local router that first receives it without > an explicit action on the part of the operator to enable it to be > advertised further within their ASN. ok, sure, but 'no-export' really means 'send to your whole ASN and use (if appropriate) but don't pass outside your asn' ... unless you mean the route is percieved by the receiver as 'has no-export already so should be infeasible'. which is another level of cranking the lever over 'no-advertise'. > >> (slice/dice with NEW_No_Advertise as you will...) >> >> note that any of these solutions does mean that me seeing 'no-export' >> to you (or the ability of me to do that that already exists and might >> already be used) means policy bits get 'more complicated' because now: >> "if no-export; >> set no-export internal-community etc... >> else; >> delete no-export >> done' > > Good point. This may another reason why we want to define NEW_NO_EXPORT > that is specific to this new default policy of not advertising routes > learned by your ASN, from external peers, to propagate outside your ASN, > toward external peers. > I'm open to discussion, yup.... I think there are likely lots of ways to solve this, though I bet we don't want 'least surprise' problems... your comment about infeasible is intriguing, what if all routes were simply 'infeasible' if there were no policy on the ebgp peering? (still a naive user might look at 'show bgp neighor' and 'show route received-protocol bgp' and ... wonder why: "I see routes, why no routes accepted?" -chris > -shane > > >> which seems weird... maybe the proposal is some 'hidden' policy such >> that once ANY policy exists 'no-export' is just regular no-export... >> that seems sane enough. >> >> _______________________________________________ >> 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 Wed Jul 22 12:49: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 721BF1ACE4B for ; Wed, 22 Jul 2015 12:49:17 -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 wRLcWmoMJt4g for ; Wed, 22 Jul 2015 12:49:16 -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 514671ACE3C for ; Wed, 22 Jul 2015 12:49:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9029; q=dns/txt; s=iport; t=1437594555; x=1438804155; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=tN9MnMYnW65xvUwRjIb2Hxi/BuzVXeoPDhDg4bS6DL0=; b=W4WOJsa75JnTCUPZCboPBqVlRLBjbKh2soEbUjykOK+3yUbR9lGXg+Pm Bp4/GNCJZZVITHZHYJ0xH3KdPqHNk8DGi22q8Z5PY+kOyo4MTrm6uIlov s6sjv+vVbLPLKmdyB6kQNAoEQ3Ezk51FJvJl589qCOkMiL+VvFI4N/6jk o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AlBQA7869V/49dJa1bgkhNVGkGrFqOcyoJgXWGAQKBVTgUAQEBAQEBAYEKhCMBAQEEHRBcAgEIDgMDAQIoBzIUCQgCBAESiC4NzVcBAQEBAQEBAQEBAQEBAQEBAQEBGYtMhHUYhCsFlFcBhHSHPYFDRoNXj1GDYREVgg0cgVNvgUeBBAEBAQ X-IronPort-AV: E=Sophos;i="5.15,525,1432598400"; d="scan'208,217";a="171363322" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-5.cisco.com with ESMTP; 22 Jul 2015 19:49:14 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t6MJnE5I016008 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Jul 2015 19:49:14 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.112]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Wed, 22 Jul 2015 14:49:14 -0500 From: "Keyur Patel (keyupate)" To: Susan Hares , "'idr wg list'" Thread-Topic: [Idr] WG Adoption call - draft-keyupate-idr-bgp-prefix-sid (7/20 to 8/3) Thread-Index: AQHQxLd8+3TsO7RdC0awPb1Uwz125w== Date: Wed, 22 Jul 2015 19:49:14 +0000 Message-ID: References: <006001d0c309$3164b570$942e2050$@ndzh.com> In-Reply-To: <006001d0c309$3164b570$942e2050$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-originating-ip: [10.155.32.214] Content-Type: multipart/alternative; boundary="_000_D1D541881EA1Bkeyupateciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] WG Adoption call - draft-keyupate-idr-bgp-prefix-sid (7/20 to 8/3) 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 Jul 2015 19:49:17 -0000 --_000_D1D541881EA1Bkeyupateciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support as a co-author. Few more comments inlined #Keyur. From: Susan Hares > Date: Monday, July 20, 2015 at 9:29 AM To: 'idr wg list' > Subject: [Idr] WG Adoption call - draft-keyupate-idr-bgp-prefix-sid (7/20 t= o 8/3) This begins a 2 week WG Adoption call for draft-keyupate-idr-bgp-prefix-sid= (7/20 to 8/3/2015). http://datatracker.ietf.org/doc/draft-keyupate-idr-bgp-prefix-sid/ The authors should indicate if there is any IPR related to the draft. We would appreciate if you would answer the following questions: 1) Do you know of networks where this new BGP feature would useful? #Keyur: Yep. 2) Do you know of any technical issues with this draft? #Keyur: No. Regards, Keyur In your discussion, please include whether you support the draft or not? Sue Hares and John Scudder --_000_D1D541881EA1Bkeyupateciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <9ECCAEAEA84EBB4CAFD564307E765E8C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Support as a co-author.

Few more comments inlined #Keyur.

From: Susan Hares <shares@ndzh.com>
Date: Monday, July 20, 2015 at 9:29= AM
To: 'idr wg list' <idr@ietf.org>
Subject: [Idr] WG Adoption call - d= raft-keyupate-idr-bgp-prefix-sid (7/20 to 8/3)

This begins a 2 week WG Adoption call for draft-keyu= pate-idr-bgp-prefix-sid (7/20 to 8/3/2015). 

http://datatracker.ietf.org/doc/draft-keyupate-i= dr-bgp-prefix-sid/

 

The authors should indicate if there is any IPR rela= ted to the draft.

 

We would appreciate if you would answer the followin= g questions:

1)   =    Do you know of networks where this new BGP feat= ure would useful?

#Keyur: Yep.

2)   =    Do you know of any technical issues with this d= raft?


#Keyur: No.

Regards,
Keyur

 

In your discussion, please include whether you suppo= rt the draft or not?

 

Sue Hares and John Scudder

 --_000_D1D541881EA1Bkeyupateciscocom_-- From nobody Wed Jul 22 14:54: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 BEFF91B2F33 for ; Wed, 22 Jul 2015 14:54:39 -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 CIFGYFhHNBdV for ; Wed, 22 Jul 2015 14:54:37 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 900901ACD7D for ; Wed, 22 Jul 2015 14:54:37 -0700 (PDT) Received: by puck.nether.net (Postfix, from userid 162) id 3EED3540B68; Wed, 22 Jul 2015 17:54:37 -0400 (EDT) Date: Wed, 22 Jul 2015 17:54:37 -0400 From: Jared Mauch To: Christopher Morrow Message-ID: <20150722215437.GA9764@puck.nether.net> References: <1437488969.3167944.329199849.26B6E5D7@webmail.messagingengine.com> <1437514484.536600.329607921.1B4BFD01@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23+102 (2ca89bed6448) (2014-03-12) Archived-At: Cc: Shane Amante , "idr@ietf.org List" Subject: Re: [Idr] draft-mauch-bgp-reject 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 Jul 2015 21:54:39 -0000 On Wed, Jul 22, 2015 at 03:37:38PM -0400, Christopher Morrow wrote: > On Tue, Jul 21, 2015 at 5:34 PM, Shane Amante wrote: > > Chris, > > > > On Tue, Jul 21, 2015, at 01:37 PM, Christopher Morrow wrote: > >> (in general I like the proposal as is, shane makes a fun second > >> option, more below) > >> > >> On Tue, Jul 21, 2015 at 10:29 AM, Shane Amante > >> wrote: > >> > > >> > And, now for a more controversial recommendation. More specifically, > >> > perhaps it's time to (more seriously) consider additional, default > >> > fail-safe mechanism(s) in BGP. Specifically, what if the _default_ > >> > behavior for eBGP learned routes was to tag all received routes with the > >> > standard BGP NO_EXPORT community? In theory, that would obligate an > >> > >> why not 'no_advertise' ? why even let the listener send it beyond > >> itself at all? It's pretty clearn when your whole AS can't hear the > >> new peer that you messed up. > > > > IMHO, I think declaring the route as "unfeasible" means it's not even > > used for forwarding by the local router that first receives it without > > an explicit action on the part of the operator to enable it to be > > advertised further within their ASN. > > ok, sure, but 'no-export' really means 'send to your whole ASN and use > (if appropriate) but don't pass outside your asn' ... unless you mean > the route is percieved by the receiver as 'has no-export already so > should be infeasible'. > > which is another level of cranking the lever over 'no-advertise'. Yes, but this is certainly drifting OT from the draft in the subject line. My goal is to specify for developers the default operation of a BGP speaking device to start in a secure/safe operating mode. Too often we face peering partners who turn up a new device missing policy which has dire consequences. There have been several recent issues that appeared in operator forums as a consequence of these unsafe defaults. This necessitates informing the developers of the risks and fail-closed/fail-secure mode necessary. Even IOS Clasic/IOS-XE has an open defect to change this operation to make this the case. > >> (slice/dice with NEW_No_Advertise as you will...) > >> > >> note that any of these solutions does mean that me seeing 'no-export' > >> to you (or the ability of me to do that that already exists and might > >> already be used) means policy bits get 'more complicated' because now: > >> "if no-export; > >> set no-export internal-community etc... > >> else; > >> delete no-export > >> done' > > > > Good point. This may another reason why we want to define NEW_NO_EXPORT > > that is specific to this new default policy of not advertising routes > > learned by your ASN, from external peers, to propagate outside your ASN, > > toward external peers. > > > > I'm open to discussion, yup.... I think there are likely lots of ways > to solve this, though I bet we don't want 'least surprise' problems... > your comment about infeasible is intriguing, what if all routes were > simply 'infeasible' if there were no policy on the ebgp peering? > (still a naive user might look at 'show bgp neighor' and 'show route > received-protocol bgp' and ... wonder why: "I see routes, why no > routes accepted?" This is not a new problem as customers without the unsafe-ebgp knob or similar need to solve. I'm sure the training courses and examples on the websites will help the operator, as well as professional services. That does seem outside the scope as that is not a new problem. -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From nobody Wed Jul 22 22:29:02 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 EE5E01A1DBC for ; Wed, 22 Jul 2015 22:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 p8Pd9Txtkg5s for ; Wed, 22 Jul 2015 22:28:57 -0700 (PDT) Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) by ietfa.amsl.com (Postfix) with SMTP id 900891A1BC8 for ; Wed, 22 Jul 2015 22:28:57 -0700 (PDT) Received: (qmail 30037 invoked by uid 0); 23 Jul 2015 05:28:49 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy7.mail.unifiedlayer.com with SMTP; 23 Jul 2015 05:28:49 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id vnUf1q00d2SSUrH01nUiyG; Thu, 23 Jul 2015 05:28:48 -0600 X-Authority-Analysis: v=2.1 cv=Qc314Krv c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=JAI3OqB5mnwA:10 a=N659UExz7-8A:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=zOBTXjUuO1YA:10 a=48vgC7mUAAAA:8 a=UZP4iMJKw0QuO7UDobwA:9 a=pILNOxqGKmIA:10 a=jM_x9b4JT8QA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=fue/U/UlyKRutg9nz/i1mgdFJR3EtEllR+rlVzuCEJ8=; b=mtYY/Hd/z5m0/tIXkfoqZ9N1fO2fF+B1ryjvSh/RjXyw5Ri9irBLSshDJTeHtWXP+OExbewTPkQajgFDroiZBUgMiAHGrMdQAD00gQy9EMvFXpph3Kl0YpP+gPNgX5yu; Received: from box313.bluehost.com ([69.89.31.113]:48602 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZI93g-0006gq-5P; Wed, 22 Jul 2015 23:28:40 -0600 To: "Dongjie (Jimmy)" , "draft-ietf-idr-te-lsp-distribution@ietf.org" References: <20150507092713.29688.3632.idtracker@ietfa.amsl.com> <554B7098.1090101@labn.net> <76CD132C3ADEF848BD84D028D243C92757D10DAB@nkgeml512-mbx.china.huawei.com> <14d33532e98.276d.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <76CD132C3ADEF848BD84D028D243C92757D11D2B@nkgeml512-mbx.china.huawei.com> <55AD2FD2.4070605@labn.net> <76CD132C3ADEF848BD84D028D243C927742E4C72@nkgeml512-mbx.china.huawei.com> From: Lou Berger X-Enigmail-Draft-Status: N1110 Message-ID: <55B07B80.6030302@labn.net> Date: Thu, 23 Jul 2015 07:28:32 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <76CD132C3ADEF848BD84D028D243C927742E4C72@nkgeml512-mbx.china.huawei.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] I-D Action: draft-ietf-idr-te-lsp-distribution-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: Thu, 23 Jul 2015 05:29:01 -0000 Jie, See below. On 7/21/2015 10:06 AM, Dongjie (Jimmy) wrote: > Hi Lou, > > Thanks for your response, and please see my replies inlined with [Jie]: > > ... >>>>>> The 64-Bit 'Identifier' field is used to discriminate between >>>>>> instances with different LSP technologies. The default identifier >>>>>> "0" identifies the instance for packet switched LSPs. >>>>>> A new >>>>>> identifier TBD is used to identify the instance of optical layer >>>>>> LSPs. >>>>> Doesn't it make more sense to just carry the values used in LSP >>>>> switching >>>> type >>>>> (See rfc3473/7074) for the non-zero case? >>>> I agree with your point that this document could cover LSPs with >>>> different switching types. As for using the switching type values >>>> directly as identifier, we coauthors will discuss it and then feedback to you. >>>> >>> Sure, but unless there's a substantive justification, I really don't think we need >>> another name/number space for the same thing. >> What about we use another way to specify the LSP switching type: include the Generalized Label Request Object in the LSP State Information TLVs, as the switching type is one of the attributes of the LSP. The NLRI is used to specify the identifiers of the LSP. > So does this mean you'd drop the Identifier from the TE LSP NLRI? > > [Jie] Not exactly. As defined in draft-ietf-idr-ls-distribution, the identifier is used to identify the "routing universe" where the NLRI belongs. My suggestion is to not change the usage of this field. And if it is not applicable in some cases, it could be set to some default value. Ahh. So the use of identifier in draft-ietf-idr-ls-distribution, which basically identifies a routing instance, seems a bit different in your document which says: The default identifier "0" identifies the instance for packet switched LSPs. A new identifier TBD is used to identify the instance of optical layer LSPs. So I read this as a technology identifier not an instance identifier. Perhaps this text needs to be revised? Or am I still missing something? >> This would not require the assignment of several well-known values from the identifier registry. Our concern is that this identifier field and registry is generic for all BGP-LS NLRIs, and making reservations for some specific NLRIs may restrict the usage of such values. > I've read this a few times and concluded I don't really understand what > you're proposing. Can you try stating it a different way? Perhaps just > send the changes that you'd make. > > [Jie] Let me try to explain this. The above sentence was to specify the reasons of not allocating some specific identifier values to represent switching types. As I said in the previous response, the values of the identifier field should be applicable to all NLRI types, so the definition and allocation of the identifier values are better not be restricted to only applicable to a specific NLRI type (e.g. the TE LSP NLRI). My point was pretty simple: if the values match, and always should match, a list of values already maintained by IANA, I think pointing to that list rather than trying to create a new one makes the most sense. It sounds like you don't think there's a good list (registry) to leverage. > The proposed method is to reflect the LSP switchig type by including the Generalized Label Request Object in the LSP State TLV. This should work >> If you agree with this method, we can add the corresponding specifications in next revision. -- I'll keep an eye out for it in the next version. >>>>>> Currently the TE LSP Objects that can be carried in the LSP State TLV >>>>>> include: >>>>> How do you distinguish between RSVP and PCEP objects? >>>> Good question. My understanding is for the same information, the >>>> format of RSVP and PCEP objects usually are compatible. In case there >>>> is some discrepancy, the current strategy is, for information which >>>> has corresponding RSVP object, the RSVP object is used, otherwise the >>>> PCEP object is used. Or do you have some suggestions about this? >>>> >>> There is collision/ambiguity so I'd use a different type or add a subtype. >> Our intention was to re-use the existing registries of LSP objects and avoid defining a new one. The advantage is every time some new object is defined in RSVP or PCEP, this BGP-LS specification does not need to be revised. > This makes sense > > [Jie] Glad that we agreed on this. > >> That said, I'd agree that the ambiguity between RSVP and PCEP objects needs to be solved. > yup, you currently have collision of values between protocols. > >> One possible solution for this is to make the LSP State information TLVs hierarchical. We can define a set of top level TLVs, each one identifies the source/format of the information carried. For example, we can define a top-level sub-TLV for RSVP, which consists of the existing RSVP objects. Similarly, define another top level sub-TLV for PCEP, which carries the existing PCEP objects. We may also define a new top level sub-TLV for LSP information derived from other sources. This way we can solve the ambiguity without assigning new type values for every existing object. Hope this is in line with your proposal "add a subtype". > Yes, a mean a subtype = {RSVP|PCEP} not defining new values for all objects. > > [Jie] Good, so we are in sync on the solution to this issue. Okay -- I'll also look for this change in the next version. Thanks, Lou > Best regards, > Jie > > Lou >> Best regards, >> Jie >> >>> Lou >>> >>>> Best regards, >>>> Jie >>>> >>>>> Lou >>>>> >>>>> On 5/7/2015 5:27 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 : Distribution of MPLS Traffic Engineering (TE) >>> LSP >>>>> State using BGP >>>>>> Authors : Jie Dong >>>>>> Mach(Guoyi) Chen >>>>>> Hannes Gredler >>>>>> Stefano Previdi >>>>>> Jeff Tantsura >>>>>> Filename : draft-ietf-idr-te-lsp-distribution-03.txt >>>>>> Pages : 12 >>>>>> Date : 2015-05-07 >>>>>> >>>>>> Abstract: >>>>>> This document describes a mechanism to collect the Traffic >>>>>> Engineering (TE) LSP information using BGP. Such information can be >>>>>> used by external components for path reoptimization, service >>>>>> placement and network visualization. >>>>>> >>>>>> >>>>>> >>>>>> The IETF datatracker status page for this draft is: >>>>>> https://datatracker.ietf.org/doc/draft-ietf-idr-te-lsp-distributio >>>>>> n/ >>>>>> >>>>>> There's also a htmlized version available at: >>>>>> https://tools.ietf.org/html/draft-ietf-idr-te-lsp-distribution-03 >>>>>> >>>>>> A diff from the previous version is available at: >>>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-te-lsp-distributi >>>>>> on-0 >>>>>> 3 >>>>>> >>>>>> >>>>>> 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 >>>>>> >>>>> _______________________________________________ >>>>> Idr mailing list >>>>> Idr@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/idr From nobody Wed Jul 22 22:53: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 D02941A6FEF for ; Wed, 22 Jul 2015 22:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wu2tTPFmkqwD for ; Wed, 22 Jul 2015 22:53:08 -0700 (PDT) Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (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 24A771A6F28 for ; Wed, 22 Jul 2015 22:53:07 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so132263923wib.1 for ; Wed, 22 Jul 2015 22:53:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=7j650923TDqKTrssbqGPXoceeLda/U/jnjWiBndB3aQ=; b=Lut7f9R/5r9csWD1c4xp81Pdl45VmhgM5XkMzTTPAQ2QxQaT26uvU6X3yZc00gIrFo HaemIMyxmqZFlQex0b5Nt9C/Tjo2vRxX9EJGOq5JY4fP4+MQRg5FfZlifj9YuQX7lj9b tUjm5LCcTOAu5tXHr2iIFUPhcyoDRN7vuqwxWxoC5e77fO5lkTqqm9mp3uPADDkENq3J D6x88Veyphp0YTxtP+xZx/8mg1Y6xcCqxJyXhdArufRhLxLeYwyQrl4q3zZyTpqB0aZU JqX8tWQfP4JHlTGqwBZYi83rZewuXoBeuv1fIEGxu6hbrNqKM2qxuG0KoEIFmEyvmFwm fjuA== X-Gm-Message-State: ALoCoQkz9zqeSw+/O8ZciqJQ1qbQm6NW5CoH6KHNW9rzbJigfRkJ732NMecqSzyoHwJAj2rn7Z4+ X-Received: by 10.180.90.209 with SMTP id by17mr48636804wib.2.1437630786750; Wed, 22 Jul 2015 22:53:06 -0700 (PDT) Received: from localhost ([2001:67c:370:136:d1ce:3fe7:3556:c379]) by smtp.gmail.com with ESMTPSA id n6sm6769390wix.1.2015.07.22.22.53.00 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Jul 2015 22:53:05 -0700 (PDT) Date: Thu, 23 Jul 2015 07:52:39 +0200 From: Job Snijders To: Christopher Morrow Message-ID: <20150723055239.GP65805@dhcp-a1b1.meeting.ietf.org> References: <1437488969.3167944.329199849.26B6E5D7@webmail.messagingengine.com> <1437514484.536600.329607921.1B4BFD01@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: Shane Amante , "idr@ietf.org List" Subject: Re: [Idr] draft-mauch-bgp-reject 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 Jul 2015 05:53:10 -0000 On Wed, Jul 22, 2015 at 03:37:38PM -0400, Christopher Morrow wrote: > > Good point. This may another reason why we want to define > > NEW_NO_EXPORT that is specific to this new default policy of not > > advertising routes learned by your ASN, from external peers, to > > propagate outside your ASN, toward external peers. > > > > I'm open to discussion, yup.... I think there are likely lots of ways > to solve this, though I bet we don't want 'least surprise' problems... > your comment about infeasible is intriguing, what if all routes were > simply 'infeasible' if there were no policy on the ebgp peering? Yes, you could store the information received from the BGP peer in Adj-RIB-In and mark it as 'not valid'. To me that is the same as rejecting. I am not in favor of using NO_EXPORT / NO_ADVERTISE in this context, either one hints towards "kind of accepting" rather then rejection. Kind regards, Job From nobody Thu Jul 23 01:25: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 3CF211A8988; Thu, 23 Jul 2015 01:25:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zsjLJ_538WRv; Thu, 23 Jul 2015 01:25:16 -0700 (PDT) Received: from out-1.mail.exa.net.uk (out-1.mail.exa.net.uk [82.219.4.129]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 670D11A0231; Thu, 23 Jul 2015 01:25:15 -0700 (PDT) Received: from smtp-1.mail.exa.net.uk (smtp-1.mail.exa.net.uk [82.219.5.1]) by out-1.mail.exa.net.uk (ExaSMTPD) with ESMTP id C9C9C1C0048; Thu, 23 Jul 2015 09:25:13 +0100 (BST) Received: from smtp-1.mail.exa.net.uk (localhost [127.0.0.1]) by smtp-1.mail.exa.net.uk (ExaSMTPD) with ESMTP id B71632212DF; Thu, 23 Jul 2015 09:25:13 +0100 (BST) Received: from [172.26.58.92] (oag3.wlan.daa.dublin.eircom.net [83.71.193.228]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: thomas@mangin.com) by smtp-1.mail.exa.net.uk (ExaSMTPD) with ESMTPSA; Thu, 23 Jul 2015 09:25:13 +0100 (BST) From: "Thomas Mangin" To: idr-bounces@ietf.org Date: Thu, 23 Jul 2015 09:25:12 +0100 Message-ID: <4D73D843-66CA-42D1-B834-BE98D4A4B664@exa-networks.co.uk> In-Reply-To: <20150723055239.GP65805@dhcp-a1b1.meeting.ietf.org> References: <1437488969.3167944.329199849.26B6E5D7@webmail.messagingengine.com> <1437514484.536600.329607921.1B4BFD01@webmail.messagingengine.com> <20150723055239.GP65805@dhcp-a1b1.meeting.ietf.org> MIME-Version: 1.0 X-Mailer: MailMate (1.9.2r5107) X-Virus-Scanned: clamav-milter 0.98.7 at out-2-2.mail.exa.net.uk X-Virus-Status: Clean Archived-At: Cc: Shane Amante , List Subject: Re: [Idr] draft-mauch-bgp-reject 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 Jul 2015 08:25:18 -0000 > Yes, you could store the information received from the BGP peer in > Adj-RIB-In and mark it as 'not valid'. To me that is the same as > rejecting. I prefer this behaviour to not accepting the routes at all. > I am not in favor of using NO_EXPORT / NO_ADVERTISE in this context, > either one hints towards "kind of accepting" rather then rejection. I agree with this position. Thomas From nobody Thu Jul 23 01:47: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 BC8471A8A1A; Thu, 23 Jul 2015 01:47:37 -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 9nuj4KIjISes; Thu, 23 Jul 2015 01:47:35 -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 11E221A036C; Thu, 23 Jul 2015 01:47:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12022; q=dns/txt; s=iport; t=1437641255; x=1438850855; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=IHWLyVoIySJ2o8bxAm/a5EWcrpMwjUpYv4K1rhIOXRw=; b=WGexzvU8DyJLTgYT0C/VpEof+tpbvClXNSDQpwJtUumnqYs/Zh2o8891 WNymDP+xRQub3ULAXBNiiXpanydYGbZ9ocgPKwAnM0qig3lRKv7uRY9E8 gaTdCgiaKiVMyADTFEdsCjnFKtFg56imGVfRCCduEelH04jwvVxUCVLXa E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AkAwBtqbBV/5tdJa1RCoMVVGkGgx24KwmBawqGAQIcgTg4FAEBAQEBAQGBCoQkAQEEAQEBIBEzBwsQAgEIDgoCAiYCAgIlCxUQAgQBDQUJEogTDbVjlh0BAQEBAQEBAQEBAQEBAQEBAQEBAQEXgSKJKIEChClCGweCaYFDBYw/hSWCfAGEdYdEgURGg1eDEIkMgz2DYSaCDRyBU28BgUaBBAEBAQ X-IronPort-AV: E=Sophos;i="5.15,529,1432598400"; d="scan'208";a="171487199" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-8.cisco.com with ESMTP; 23 Jul 2015 08:47:33 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t6N8lXu5017717 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 Jul 2015 08:47:33 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.37]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Thu, 23 Jul 2015 03:47:33 -0500 From: "Acee Lindem (acee)" To: Lou Berger , "Dongjie (Jimmy)" , "draft-ietf-idr-te-lsp-distribution@ietf.org" Thread-Topic: [Idr] I-D Action: draft-ietf-idr-te-lsp-distribution-03.txt Thread-Index: AQHQwxGnatgEK/e6RUaTJUM83JslVJ3l5gkAgAL4eQCAAFkjAA== Date: Thu, 23 Jul 2015 08:47:33 +0000 Message-ID: References: <20150507092713.29688.3632.idtracker@ietfa.amsl.com> <554B7098.1090101@labn.net> <76CD132C3ADEF848BD84D028D243C92757D10DAB@nkgeml512-mbx.china.huawei.com> <14d33532e98.276d.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <76CD132C3ADEF848BD84D028D243C92757D11D2B@nkgeml512-mbx.china.huawei.com> <55AD2FD2.4070605@labn.net> <76CD132C3ADEF848BD84D028D243C927742E4C72@nkgeml512-mbx.china.huawei.com> <55B07B80.6030302@labn.net> In-Reply-To: <55B07B80.6030302@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.241.178] Content-Type: text/plain; charset="utf-8" Content-ID: <50A5A82BC1718F4E960FA3747A353C36@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] I-D Action: draft-ietf-idr-te-lsp-distribution-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: Thu, 23 Jul 2015 08:47:38 -0000 SGkgSmllLCBMb3UsIA0KDQpTZWUgb25lIGlubGluZS4NCg0KT24gNy8yMy8xNSwgNzoyOCBBTSwg IklkciBvbiBiZWhhbGYgb2YgTG91IEJlcmdlciIgPGlkci1ib3VuY2VzQGlldGYub3JnDQpvbiBi ZWhhbGYgb2YgbGJlcmdlckBsYWJuLm5ldD4gd3JvdGU6DQoNCj5KaWUsDQo+U2VlIGJlbG93Lg0K Pg0KPk9uIDcvMjEvMjAxNSAxMDowNiBBTSwgRG9uZ2ppZSAoSmltbXkpIHdyb3RlOg0KPj4gSGkg TG91LCANCj4+DQo+PiBUaGFua3MgZm9yIHlvdXIgcmVzcG9uc2UsIGFuZCBwbGVhc2Ugc2VlIG15 IHJlcGxpZXMgaW5saW5lZCB3aXRoIFtKaWVdOg0KPj4NCj4+IC4uLg0KPj4+Pj4+PiAgICBUaGUg NjQtQml0ICdJZGVudGlmaWVyJyBmaWVsZCBpcyB1c2VkIHRvIGRpc2NyaW1pbmF0ZSBiZXR3ZWVu DQo+Pj4+Pj4+ICAgIGluc3RhbmNlcyB3aXRoIGRpZmZlcmVudCBMU1AgdGVjaG5vbG9naWVzLiAg VGhlIGRlZmF1bHQNCj4+Pj4+Pj5pZGVudGlmaWVyDQo+Pj4+Pj4+ICAgICIwIiBpZGVudGlmaWVz IHRoZSBpbnN0YW5jZSBmb3IgcGFja2V0IHN3aXRjaGVkIExTUHMuDQo+Pj4+Pj4+IEEgbmV3DQo+ Pj4+Pj4+ICAgIGlkZW50aWZpZXIgVEJEIGlzIHVzZWQgdG8gaWRlbnRpZnkgdGhlIGluc3RhbmNl IG9mIG9wdGljYWwgbGF5ZXINCj4+Pj4+Pj4gICAgTFNQcy4NCj4+Pj4+PiBEb2Vzbid0IGl0IG1h a2UgbW9yZSBzZW5zZSB0byBqdXN0IGNhcnJ5IHRoZSB2YWx1ZXMgdXNlZCBpbiBMU1ANCj4+Pj4+ PiBzd2l0Y2hpbmcNCj4+Pj4+IHR5cGUNCj4+Pj4+PiAoU2VlIHJmYzM0NzMvNzA3NCkgZm9yIHRo ZSBub24temVybyAgY2FzZT8NCj4+Pj4+IEkgYWdyZWUgd2l0aCB5b3VyIHBvaW50IHRoYXQgdGhp cyBkb2N1bWVudCBjb3VsZCBjb3ZlciBMU1BzIHdpdGgNCj4+Pj4+IGRpZmZlcmVudCBzd2l0Y2hp bmcgdHlwZXMuIEFzIGZvciB1c2luZyB0aGUgc3dpdGNoaW5nIHR5cGUgdmFsdWVzDQo+Pj4+PiBk aXJlY3RseSBhcyBpZGVudGlmaWVyLCB3ZSBjb2F1dGhvcnMgd2lsbCBkaXNjdXNzIGl0IGFuZCB0 aGVuDQo+Pj4+PmZlZWRiYWNrIHRvIHlvdS4NCj4+Pj4+DQo+Pj4+IFN1cmUsIGJ1dCB1bmxlc3Mg dGhlcmUncyBhIHN1YnN0YW50aXZlIGp1c3RpZmljYXRpb24sIEkgcmVhbGx5IGRvbid0DQo+Pj4+ dGhpbmsgd2UgbmVlZA0KPj4+PiBhbm90aGVyIG5hbWUvbnVtYmVyIHNwYWNlIGZvciB0aGUgc2Ft ZSB0aGluZy4NCj4+PiBXaGF0IGFib3V0IHdlIHVzZSBhbm90aGVyIHdheSB0byBzcGVjaWZ5IHRo ZSBMU1Agc3dpdGNoaW5nIHR5cGU6DQo+Pj5pbmNsdWRlIHRoZSBHZW5lcmFsaXplZCBMYWJlbCBS ZXF1ZXN0IE9iamVjdCBpbiB0aGUgTFNQIFN0YXRlDQo+Pj5JbmZvcm1hdGlvbiBUTFZzLCBhcyB0 aGUgc3dpdGNoaW5nIHR5cGUgaXMgb25lIG9mIHRoZSBhdHRyaWJ1dGVzIG9mIHRoZQ0KPj4+TFNQ LiBUaGUgTkxSSSBpcyB1c2VkIHRvIHNwZWNpZnkgdGhlIGlkZW50aWZpZXJzIG9mIHRoZSBMU1Au DQo+PiBTbyBkb2VzIHRoaXMgbWVhbiB5b3UnZCBkcm9wIHRoZSBJZGVudGlmaWVyIGZyb20gdGhl IFRFIExTUCBOTFJJPw0KPj4NCj4+IFtKaWVdIE5vdCBleGFjdGx5LiBBcyBkZWZpbmVkIGluIGRy YWZ0LWlldGYtaWRyLWxzLWRpc3RyaWJ1dGlvbiwgdGhlDQo+PmlkZW50aWZpZXIgaXMgdXNlZCB0 byBpZGVudGlmeSB0aGUgInJvdXRpbmcgdW5pdmVyc2UiIHdoZXJlIHRoZSBOTFJJDQo+PmJlbG9u Z3MuIE15IHN1Z2dlc3Rpb24gaXMgdG8gbm90IGNoYW5nZSB0aGUgdXNhZ2Ugb2YgdGhpcyBmaWVs ZC4gQW5kIGlmDQo+Pml0IGlzIG5vdCBhcHBsaWNhYmxlIGluIHNvbWUgY2FzZXMsIGl0IGNvdWxk IGJlIHNldCB0byBzb21lIGRlZmF1bHQNCj4+dmFsdWUuDQo+QWhoLiAgU28gdGhlIHVzZSBvZiBp ZGVudGlmaWVyIGluIGRyYWZ0LWlldGYtaWRyLWxzLWRpc3RyaWJ1dGlvbiwgd2hpY2gNCj5iYXNp Y2FsbHkgaWRlbnRpZmllcyBhIHJvdXRpbmcgaW5zdGFuY2UsIHNlZW1zIGEgYml0IGRpZmZlcmVu dCBpbiB5b3VyDQo+ZG9jdW1lbnQgd2hpY2ggc2F5czoNCj4NCj4gICBUaGUgZGVmYXVsdCBpZGVu dGlmaWVyDQo+ICAgIjAiIGlkZW50aWZpZXMgdGhlIGluc3RhbmNlIGZvciBwYWNrZXQgc3dpdGNo ZWQgTFNQcy4gIEEgbmV3DQo+ICAgaWRlbnRpZmllciBUQkQgaXMgdXNlZCB0byBpZGVudGlmeSB0 aGUgaW5zdGFuY2Ugb2Ygb3B0aWNhbCBsYXllcg0KPiAgIExTUHMuDQo+DQo+U28gSSByZWFkIHRo aXMgYXMgYSB0ZWNobm9sb2d5IGlkZW50aWZpZXIgbm90IGFuIGluc3RhbmNlIGlkZW50aWZpZXIu DQo+UGVyaGFwcyB0aGlzIHRleHQgbmVlZHMgdG8gYmUgcmV2aXNlZD8gIE9yIGFtIEkgc3RpbGwg bWlzc2luZyBzb21ldGhpbmc/DQoNClRoaXMgaXMgZnJvbSBhbiBvbGRlciB2ZXJzaW9uIG9mIGRy YWZ0LWlldGYtaWRyLWxzLWRpc3RyaWJ1dGlvbi4gSSB3YXMgdGhlDQpyb3V0aW5nIGRpcmVjdG9y YXRlIHJldmlld2VyIGFuZCBhc2tlZCB0aGF0IGl0IGJlIGNoYW5nZWQuIFlvdSBjYW4ganVzdA0K dGFrZSB0aGUgZGVmaW5pdGlvbiBmcm9tIHRoZSBsYXRlc3QgdmVyc2lvbi4NCg0KVGhhbmtzLCAN CkFjZWUNCg0KDQoNCj4NCj4NCj4+PiBUaGlzIHdvdWxkIG5vdCByZXF1aXJlIHRoZSBhc3NpZ25t ZW50IG9mIHNldmVyYWwgd2VsbC1rbm93biB2YWx1ZXMNCj4+PmZyb20gdGhlIGlkZW50aWZpZXIg cmVnaXN0cnkuIE91ciBjb25jZXJuIGlzIHRoYXQgdGhpcyBpZGVudGlmaWVyIGZpZWxkDQo+Pj5h bmQgcmVnaXN0cnkgaXMgZ2VuZXJpYyBmb3IgYWxsIEJHUC1MUyBOTFJJcywgYW5kIG1ha2luZyBy ZXNlcnZhdGlvbnMNCj4+PmZvciBzb21lIHNwZWNpZmljIE5MUklzIG1heSByZXN0cmljdCB0aGUg dXNhZ2Ugb2Ygc3VjaCB2YWx1ZXMuDQo+PiBJJ3ZlIHJlYWQgdGhpcyBhIGZldyB0aW1lcyBhbmQg Y29uY2x1ZGVkIEkgZG9uJ3QgcmVhbGx5IHVuZGVyc3RhbmQgd2hhdA0KPj4geW91J3JlIHByb3Bv c2luZy4gIENhbiB5b3UgdHJ5IHN0YXRpbmcgaXQgYSBkaWZmZXJlbnQgd2F5PyAgUGVyaGFwcyBq dXN0DQo+PiBzZW5kIHRoZSBjaGFuZ2VzIHRoYXQgeW91J2QgbWFrZS4NCj4+DQo+PiBbSmllXSBM ZXQgbWUgdHJ5IHRvIGV4cGxhaW4gdGhpcy4gVGhlIGFib3ZlIHNlbnRlbmNlIHdhcyB0byBzcGVj aWZ5IHRoZQ0KPj5yZWFzb25zIG9mIG5vdCBhbGxvY2F0aW5nIHNvbWUgc3BlY2lmaWMgaWRlbnRp ZmllciB2YWx1ZXMgdG8gcmVwcmVzZW50DQo+PnN3aXRjaGluZyB0eXBlcy4gQXMgSSBzYWlkIGlu IHRoZSBwcmV2aW91cyByZXNwb25zZSwgdGhlIHZhbHVlcyBvZiB0aGUNCj4+aWRlbnRpZmllciBm aWVsZCBzaG91bGQgYmUgYXBwbGljYWJsZSB0byBhbGwgTkxSSSB0eXBlcywgc28gdGhlDQo+PmRl ZmluaXRpb24gYW5kIGFsbG9jYXRpb24gb2YgdGhlIGlkZW50aWZpZXIgdmFsdWVzIGFyZSBiZXR0 ZXIgbm90IGJlDQo+PnJlc3RyaWN0ZWQgdG8gb25seSBhcHBsaWNhYmxlIHRvIGEgc3BlY2lmaWMg TkxSSSB0eXBlIChlLmcuIHRoZSBURSBMU1ANCj4+TkxSSSkuIA0KPk15IHBvaW50IHdhcyBwcmV0 dHkgc2ltcGxlOiBpZiB0aGUgdmFsdWVzIG1hdGNoLCBhbmQgYWx3YXlzIHNob3VsZA0KPm1hdGNo LCBhIGxpc3Qgb2YgdmFsdWVzIGFscmVhZHkgbWFpbnRhaW5lZCBieSBJQU5BLCBJIHRoaW5rIHBv aW50aW5nIHRvDQo+dGhhdCBsaXN0IHJhdGhlciB0aGFuIHRyeWluZyB0byBjcmVhdGUgYSBuZXcg b25lIG1ha2VzIHRoZSBtb3N0IHNlbnNlLg0KPkl0IHNvdW5kcyBsaWtlIHlvdSBkb24ndCB0aGlu ayB0aGVyZSdzIGEgZ29vZCBsaXN0IChyZWdpc3RyeSkgdG8gbGV2ZXJhZ2UuDQo+DQo+PiBUaGUg cHJvcG9zZWQgbWV0aG9kIGlzIHRvIHJlZmxlY3QgdGhlIExTUCBzd2l0Y2hpZyB0eXBlIGJ5IGlu Y2x1ZGluZw0KPj50aGUgR2VuZXJhbGl6ZWQgTGFiZWwgUmVxdWVzdCBPYmplY3QgaW4gdGhlIExT UCBTdGF0ZSBUTFYuDQo+VGhpcyBzaG91bGQgd29yaw0KPg0KPj4+IElmIHlvdSBhZ3JlZSB3aXRo IHRoaXMgbWV0aG9kLCB3ZSBjYW4gYWRkIHRoZSBjb3JyZXNwb25kaW5nDQo+Pj5zcGVjaWZpY2F0 aW9ucyBpbiBuZXh0IHJldmlzaW9uLg0KPi0tIEknbGwga2VlcCBhbiBleWUgb3V0IGZvciBpdCBp biB0aGUgbmV4dCB2ZXJzaW9uLg0KPj4+Pj4+PiAgIEN1cnJlbnRseSB0aGUgVEUgTFNQIE9iamVj dHMgdGhhdCBjYW4gYmUgY2FycmllZCBpbiB0aGUgTFNQDQo+Pj4+Pj4+U3RhdGUgVExWDQo+Pj4+ Pj4+ICAgaW5jbHVkZToNCj4+Pj4+PiBIb3cgZG8geW91IGRpc3Rpbmd1aXNoIGJldHdlZW4gUlNW UCBhbmQgUENFUCBvYmplY3RzPw0KPj4+Pj4gR29vZCBxdWVzdGlvbi4gTXkgdW5kZXJzdGFuZGlu ZyBpcyBmb3IgdGhlIHNhbWUgaW5mb3JtYXRpb24sIHRoZQ0KPj4+Pj4gZm9ybWF0IG9mIFJTVlAg YW5kIFBDRVAgb2JqZWN0cyB1c3VhbGx5IGFyZSBjb21wYXRpYmxlLiBJbiBjYXNlIHRoZXJlDQo+ Pj4+PiBpcyBzb21lIGRpc2NyZXBhbmN5LCB0aGUgY3VycmVudCBzdHJhdGVneSBpcywgZm9yIGlu Zm9ybWF0aW9uIHdoaWNoDQo+Pj4+PiBoYXMgY29ycmVzcG9uZGluZyBSU1ZQIG9iamVjdCwgdGhl IFJTVlAgb2JqZWN0IGlzIHVzZWQsIG90aGVyd2lzZSB0aGUNCj4+Pj4+IFBDRVAgb2JqZWN0IGlz IHVzZWQuIE9yIGRvIHlvdSBoYXZlIHNvbWUgc3VnZ2VzdGlvbnMgYWJvdXQgdGhpcz8NCj4+Pj4+ DQo+Pj4+IFRoZXJlIGlzIGNvbGxpc2lvbi9hbWJpZ3VpdHkgc28gSSdkIHVzZSBhIGRpZmZlcmVu dCB0eXBlIG9yIGFkZCBhDQo+Pj4+c3VidHlwZS4NCj4+PiBPdXIgaW50ZW50aW9uIHdhcyB0byBy ZS11c2UgdGhlIGV4aXN0aW5nIHJlZ2lzdHJpZXMgb2YgTFNQIG9iamVjdHMgYW5kDQo+Pj5hdm9p ZCBkZWZpbmluZyBhIG5ldyBvbmUuIFRoZSBhZHZhbnRhZ2UgaXMgZXZlcnkgdGltZSBzb21lIG5l dyBvYmplY3QNCj4+PmlzIGRlZmluZWQgaW4gUlNWUCBvciBQQ0VQLCB0aGlzIEJHUC1MUyBzcGVj aWZpY2F0aW9uIGRvZXMgbm90IG5lZWQgdG8NCj4+PmJlIHJldmlzZWQuDQo+PiBUaGlzIG1ha2Vz IHNlbnNlDQo+Pg0KPj4gW0ppZV0gR2xhZCB0aGF0IHdlIGFncmVlZCBvbiB0aGlzLg0KPj4NCj4+ PiBUaGF0IHNhaWQsIEknZCBhZ3JlZSB0aGF0IHRoZSBhbWJpZ3VpdHkgYmV0d2VlbiBSU1ZQIGFu ZCBQQ0VQIG9iamVjdHMNCj4+Pm5lZWRzIHRvIGJlIHNvbHZlZC4NCj4+IHl1cCwgeW91IGN1cnJl bnRseSBoYXZlIGNvbGxpc2lvbiBvZiB2YWx1ZXMgYmV0d2VlbiBwcm90b2NvbHMuDQo+Pg0KPj4+ IE9uZSBwb3NzaWJsZSBzb2x1dGlvbiBmb3IgdGhpcyBpcyB0byBtYWtlIHRoZSBMU1AgU3RhdGUg aW5mb3JtYXRpb24NCj4+PlRMVnMgaGllcmFyY2hpY2FsLiBXZSBjYW4gZGVmaW5lIGEgc2V0IG9m IHRvcCBsZXZlbCBUTFZzLCBlYWNoIG9uZQ0KPj4+aWRlbnRpZmllcyB0aGUgc291cmNlL2Zvcm1h dCBvZiB0aGUgaW5mb3JtYXRpb24gY2FycmllZC4gRm9yIGV4YW1wbGUsDQo+Pj53ZSBjYW4gZGVm aW5lIGEgdG9wLWxldmVsIHN1Yi1UTFYgZm9yIFJTVlAsIHdoaWNoIGNvbnNpc3RzIG9mIHRoZQ0K Pj4+ZXhpc3RpbmcgUlNWUCBvYmplY3RzLiBTaW1pbGFybHksIGRlZmluZSBhbm90aGVyIHRvcCBs ZXZlbCBzdWItVExWIGZvcg0KPj4+UENFUCwgd2hpY2ggY2FycmllcyB0aGUgZXhpc3RpbmcgUENF UCBvYmplY3RzLiBXZSBtYXkgYWxzbyBkZWZpbmUgYSBuZXcNCj4+PnRvcCBsZXZlbCBzdWItVExW IGZvciBMU1AgaW5mb3JtYXRpb24gZGVyaXZlZCBmcm9tIG90aGVyIHNvdXJjZXMuIFRoaXMNCj4+ PndheSB3ZSBjYW4gc29sdmUgdGhlIGFtYmlndWl0eSB3aXRob3V0IGFzc2lnbmluZyBuZXcgdHlw ZSB2YWx1ZXMgZm9yDQo+Pj5ldmVyeSBleGlzdGluZyBvYmplY3QuIEhvcGUgdGhpcyBpcyBpbiBs aW5lIHdpdGggeW91ciBwcm9wb3NhbCAiYWRkIGENCj4+PnN1YnR5cGUiLg0KPj4gWWVzLCBhIG1l YW4gYSBzdWJ0eXBlID0ge1JTVlB8UENFUH0gbm90IGRlZmluaW5nIG5ldyB2YWx1ZXMgZm9yIGFs bA0KPj5vYmplY3RzLg0KPj4NCj4+IFtKaWVdIEdvb2QsIHNvIHdlIGFyZSBpbiBzeW5jIG9uIHRo ZSBzb2x1dGlvbiB0byB0aGlzIGlzc3VlLg0KPg0KPk9rYXkgLS0gSSdsbCBhbHNvIGxvb2sgZm9y IHRoaXMgY2hhbmdlIGluIHRoZSBuZXh0IHZlcnNpb24uDQo+DQo+VGhhbmtzLA0KPkxvdQ0KPg0K Pj4gQmVzdCByZWdhcmRzLA0KPj4gSmllDQo+Pg0KPj4gTG91DQo+Pj4gQmVzdCByZWdhcmRzLA0K Pj4+IEppZQ0KPj4+DQo+Pj4+IExvdQ0KPj4+Pg0KPj4+Pj4gQmVzdCByZWdhcmRzLA0KPj4+Pj4g SmllDQo+Pj4+Pg0KPj4+Pj4+IExvdQ0KPj4+Pj4+DQo+Pj4+Pj4gT24gNS83LzIwMTUgNToyNyBB TSwgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIHdyb3RlOg0KPj4+Pj4+PiBBIE5ldyBJbnRlcm5l dC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMNCj4+ Pj4+IGRpcmVjdG9yaWVzLg0KPj4+Pj4+PiAgVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0 aGUgSW50ZXItRG9tYWluIFJvdXRpbmcgV29ya2luZw0KPj4+Pj4+PiBHcm91cCBvZiB0aGUNCj4+ Pj4+PiBJRVRGLg0KPj4+Pj4+PiAgICAgICAgIFRpdGxlICAgICAgICAgICA6IERpc3RyaWJ1dGlv biBvZiBNUExTIFRyYWZmaWMgRW5naW5lZXJpbmcNCj4+Pj4+Pj4oVEUpDQo+Pj4+IExTUA0KPj4+ Pj4+IFN0YXRlIHVzaW5nIEJHUA0KPj4+Pj4+PiAgICAgICAgIEF1dGhvcnMgICAgICAgICA6IEpp ZSBEb25nDQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgTWFjaChHdW95aSkgQ2hl bg0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgIEhhbm5lcyBHcmVkbGVyDQo+Pj4+ Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgU3RlZmFubyBQcmV2aWRpDQo+Pj4+Pj4+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgSmVmZiBUYW50c3VyYQ0KPj4+Pj4+PiAgIEZpbGVuYW1l ICAgICAgICA6IGRyYWZ0LWlldGYtaWRyLXRlLWxzcC1kaXN0cmlidXRpb24tMDMudHh0DQo+Pj4+ Pj4+ICAgUGFnZXMgICAgICAgICAgIDogMTINCj4+Pj4+Pj4gICBEYXRlICAgICAgICAgICAgOiAy MDE1LTA1LTA3DQo+Pj4+Pj4+DQo+Pj4+Pj4+IEFic3RyYWN0Og0KPj4+Pj4+PiAgICBUaGlzIGRv Y3VtZW50IGRlc2NyaWJlcyBhIG1lY2hhbmlzbSB0byBjb2xsZWN0IHRoZSBUcmFmZmljDQo+Pj4+ Pj4+ICAgIEVuZ2luZWVyaW5nIChURSkgTFNQIGluZm9ybWF0aW9uIHVzaW5nIEJHUC4gIFN1Y2gg aW5mb3JtYXRpb24NCj4+Pj4+Pj5jYW4gYmUNCj4+Pj4+Pj4gICAgdXNlZCBieSBleHRlcm5hbCBj b21wb25lbnRzIGZvciBwYXRoIHJlb3B0aW1pemF0aW9uLCBzZXJ2aWNlDQo+Pj4+Pj4+ICAgIHBs YWNlbWVudCBhbmQgbmV0d29yayB2aXN1YWxpemF0aW9uLg0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+ Pj4+Pg0KPj4+Pj4+PiBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBk cmFmdCBpczoNCj4+Pj4+Pj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt aWV0Zi1pZHItdGUtbHNwLWRpc3RyaWJ1dGlvDQo+Pj4+Pj4+IG4vDQo+Pj4+Pj4+DQo+Pj4+Pj4+ IFRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KPj4+Pj4+PiBo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1pZHItdGUtbHNwLWRpc3RyaWJ1 dGlvbi0wMw0KPj4+Pj4+Pg0KPj4+Pj4+PiBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lv biBpcyBhdmFpbGFibGUgYXQ6DQo+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/ dXJsMj1kcmFmdC1pZXRmLWlkci10ZS1sc3AtZGlzdHJpYnV0aQ0KPj4+Pj4+PiBvbi0wDQo+Pj4+ Pj4+IDMNCj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkg dGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCj4+Pj4+Pj4gc3VibWlz c2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0 DQo+Pj4+PiB0b29scy5pZXRmLm9yZy4NCj4+Pj4+Pj4gSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNv IGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPj4+Pj4+PiBmdHA6Ly9mdHAuaWV0Zi5v cmcvaW50ZXJuZXQtZHJhZnRzLw0KPj4+Pj4+Pg0KPj4+Pj4+PiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+PiBJLUQtQW5ub3VuY2UgbWFpbGlu ZyBsaXN0DQo+Pj4+Pj4+IEktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KPj4+Pj4+PiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ktZC1hbm5vdW5jZQ0KPj4+Pj4+PiBJbnRlcm5l dC1EcmFmdCBkaXJlY3RvcmllczogaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbCBvcg0K Pj4+Pj4+PiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0KPj4+Pj4+ Pg0KPj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+Pj4+Pj4gSWRyIG1haWxpbmcgbGlzdA0KPj4+Pj4+IElkckBpZXRmLm9yZw0KPj4+Pj4+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRyDQo+DQo+DQo+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5JZHIgbWFpbGluZyBsaXN0 DQo+SWRyQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9p ZHINCg0K From nobody Thu Jul 23 01:53:16 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 B31791A870E for ; Thu, 23 Jul 2015 01:53:14 -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 mBLmMq4F-ZCR for ; Thu, 23 Jul 2015 01:53:13 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 886A51A86F7 for ; Thu, 23 Jul 2015 01:53:00 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so198130037wib.0 for ; Thu, 23 Jul 2015 01:52:59 -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=HXN2pRItnb8d96pY6YI5ynC0zBYRO47Gq0ik2lNG0Ek=; b=L+OPBILLasNzuFRY9lykmy0yWxZcs+hg13/zfIostgHL6uMaS8haniER6BDf3ByO3d gry+EY26R9D/tZz9dmpd3dv9VDP+jqS/sFqnHVyLNOQujTnBETONsmQ0UGBa/gWvpHoZ t8KWNkm3iBckkOnUuYnzIlImp17QeD7gbNhKIPqI95p/b+v4GOJDi/buK+5H3zf4fWnP IETffLWJE+am71p6qFs2Im0eMQ7Si/yc5c46pUTytI5cTTmzr/2W8J9KQ6YWGPyTKFgp yMVBM9vc+CYGswc5qvCqBZ3TCPvrR7bG1ve7lzG6o+Loyu4sJEgbeSRm0QQM1ueVrqa2 d0MA== MIME-Version: 1.0 X-Received: by 10.180.109.6 with SMTP id ho6mr50927900wib.58.1437641579285; Thu, 23 Jul 2015 01:52:59 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.194.95.168 with HTTP; Thu, 23 Jul 2015 01:52:59 -0700 (PDT) In-Reply-To: References: Date: Thu, 23 Jul 2015 10:52:59 +0200 X-Google-Sender-Auth: V8BOH41VJf_591DfsKGArL7P5tE Message-ID: From: Robert Raszuk To: Jared Mauch Content-Type: multipart/alternative; boundary=e89a8f3ba5f3a5d75c051b870343 Archived-At: Cc: idr wg list Subject: Re: [Idr] draft-mauch-bgp-reject 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 Jul 2015 08:53:14 -0000 --e89a8f3ba5f3a5d75c051b870343 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Jared, Two more comments ... 1. I think your section 3 should explicitly state that this recommendation/bcp applies only to SAFI 1 (maybe also SAFI 2). In other words if I peer eBGP VPNv4 the policy is build into the SAFI 128 of rejecting on intersecting RTs. Likewise if I eBGP peer with RTC or FlowSpec it would be either interesting to come up with interesting inbound/outbound policy unless it would be send/receive all. And there is many more SAFIs where constructing policy may require a BCP on its own ;-) 2. What would be example of inbound policy in case to peering with route server in IX ? Thx, R. On Mon, Jul 20, 2015 at 6:58 PM, Jared Mauch wrote: > One of the major challenges that we face as a network operator is some of > the legacy posture left in internet connected devices. We=E2=80=99ve see= n this > history play out with many other protocols and services, such as enabling > chargen, echo and other services on devices. Having SMTP open relays, et= c. > > It=E2=80=99s time to document the changes and require them as part of the= standard > behavior of all BGP speaking devices. > > https://tools.ietf.org/html/draft-mauch-bgp-reject > > Is an attempt to capture the change that may be required by some > implementors. > > Already Juniper and IOS-XR have this default behavior of not sending any > routes unless explicit policy is configured. It=E2=80=99s my understandin= g that > it=E2=80=99s also the default in BIRD but I have not validated this mysel= f. > > I=E2=80=99m interested in discussion and feedback on this document. > > - Jared > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --e89a8f3ba5f3a5d75c051b870343 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Jared,

<= /div>
Two more comments ...

<= /div>
1.=C2=A0

I think your section 3 should explicitly state that this recomme= ndation/bcp applies only to SAFI 1 (maybe also SAFI 2).=C2=A0

In other words if I peer eBGP VPNv4= the policy is build into the SAFI 128 of rejecting on intersecting RTs.=C2= =A0

Likewise if I eBGP= peer with RTC or FlowSpec it would be either interesting to come up with i= nteresting inbound/outbound policy unless it would be send/receive all.=C2= =A0

And there is many = more SAFIs where constructing policy may require a BCP on its own ;-)
=

2.=C2=A0

What would be example of inbound pol= icy in case to peering with route server in IX ?
Thx,
R.


On Mon, Jul 20, 2015 at 6:58 PM, Jared Mauch <= jared@puck.nethe= r.net> wrote:
One of the ma= jor challenges that we face as a network operator is some of the legacy pos= ture left in internet connected devices.=C2=A0 We=E2=80=99ve seen this hist= ory play out with many other protocols and services, such as enabling charg= en, echo and other services on devices.=C2=A0 Having SMTP open relays, etc.=

It=E2=80=99s time to document the changes and require them as part of the s= tandard behavior of all BGP speaking devices.

https://tools.ietf.org/html/draft-mauch-bgp-reject=

Is an attempt to capture the change that may be required by some implemento= rs.

Already Juniper and IOS-XR have this default behavior of not sending any ro= utes unless explicit policy is configured. It=E2=80=99s my understanding th= at it=E2=80=99s also the default in BIRD but I have not validated this myse= lf.

I=E2=80=99m interested in discussion and feedback on this document.

- Jared
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

--e89a8f3ba5f3a5d75c051b870343-- From nobody Thu Jul 23 01:58: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 1875E1A8701 for ; Thu, 23 Jul 2015 01:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NA3F71TeyaJf for ; Thu, 23 Jul 2015 01:58:10 -0700 (PDT) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (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 0B9071A00F0 for ; Thu, 23 Jul 2015 01:58:01 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so198314114wib.0 for ; Thu, 23 Jul 2015 01:57:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=+hiSZ6AeMYMtfHFLvjxYuYcQwRthoA4wHrxo5ZiqGJs=; b=a2ZYK7DL32ydpHW0Cs8DBwjmF2G8Hcdt30p+A1wyWTLsSDSVkwZ4YeEf63MDKf96N1 FlP9ppH53lqTTin4NYCjGC9lDVay/R8gPzSog/KEKRhbM2IxgeLrUly3YAi+1KN+Z4za i3oxJPb0zyD/k8Ed9dLZV3dcb1yuRRq91B+hVqu7RR6rI98wQcewTjrr/8dOBR2bc35T bw8vIyazSFAygxVgeQzzKOCW5UlFv19nchN9XaB1N9IIj6WfLzJsQi07L3qEuUdFAoxr FzKsV8jDJKAMeRwrlJCRvZiv3VUgxTukYbrNP9skBQ7I1Dtc86xr4S3PX72db9tDEiur qW4g== X-Gm-Message-State: ALoCoQnn/hZJzbF2vrMrb5ZkQ2koHL2Uxxo2lxyeoXDddhvWzG3IArJ/Ns9v65MuAqsbwLo7TJju X-Received: by 10.195.11.202 with SMTP id ek10mr14022915wjd.12.1437641879812; Thu, 23 Jul 2015 01:57:59 -0700 (PDT) Received: from localhost ([213.175.62.36]) by smtp.gmail.com with ESMTPSA id b13sm7438961wic.15.2015.07.23.01.57.57 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Jul 2015 01:57:58 -0700 (PDT) Date: Thu, 23 Jul 2015 10:57:56 +0200 From: Job Snijders To: Robert Raszuk Message-ID: <20150723085756.GR65805@dhcp-a1b1.meeting.ietf.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: idr wg list Subject: Re: [Idr] draft-mauch-bgp-reject 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 Jul 2015 08:58:16 -0000 On Thu, Jul 23, 2015 at 10:52:59AM +0200, Robert Raszuk wrote: > 2. > > What would be example of inbound policy in case to peering with route > server in IX ? Same as with any other eBGP session: If the IX operator did not configure any policy: reject all import/export. Do you feel this is a different scenario that deserves different approach? Kind regards, Job From nobody Thu Jul 23 02:06: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 643681AC3F2 for ; Thu, 23 Jul 2015 02:06:42 -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 9Z5NAE7HmBz9 for ; Thu, 23 Jul 2015 02:06:41 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F13991A1B5D for ; Thu, 23 Jul 2015 02:06:40 -0700 (PDT) Received: by wibud3 with SMTP id ud3so208767448wib.0 for ; Thu, 23 Jul 2015 02:06:39 -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=c1ZzSiMIeGXN/xouScTJF39desxPorJROVki13N2ht8=; b=gx5zgQy0aEbKG2I7hzMuvnnQpj+vtXHmhNOQutiPo+G74IA6aklvRi710uVovePDW9 TZ9mbizZjzaGAiyPnMDEUBlBNrMUirsoJv1xLZkFqKrO1stxMDgHvdRTn/pj02lTXnze chFz+R/poafW7csRzJlJbhNf1Rl5whyEhUDDRei3cDy5ULH05I6I8f1XOazU5P9jhqpT TcaYlMd+DKSnxucwfv/upk5w/igAQ7dp34eGdMoxRdrLkkmWo6duq+yNfNVxg5Em3ecJ sfk6Uy8atDpAuNQTV0Px/Bv9OoOh1GuvAPOSd3cFYs8DI2zd31jqV96mGs/azBHpgAGU 9Qxg== MIME-Version: 1.0 X-Received: by 10.180.109.6 with SMTP id ho6mr51040042wib.58.1437642399767; Thu, 23 Jul 2015 02:06:39 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.194.95.168 with HTTP; Thu, 23 Jul 2015 02:06:39 -0700 (PDT) In-Reply-To: <20150723085756.GR65805@dhcp-a1b1.meeting.ietf.org> References: <20150723085756.GR65805@dhcp-a1b1.meeting.ietf.org> Date: Thu, 23 Jul 2015 11:06:39 +0200 X-Google-Sender-Auth: QweejIOaeo_PCHaxH0dV1XcorDw Message-ID: From: Robert Raszuk To: Job Snijders Content-Type: multipart/alternative; boundary=e89a8f3ba5f38d634c051b873437 Archived-At: Cc: idr wg list Subject: Re: [Idr] draft-mauch-bgp-reject 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 Jul 2015 09:06:42 -0000 --e89a8f3ba5f38d634c051b873437 Content-Type: text/plain; charset=UTF-8 Job, But we are not talking about rejection based on the peer's policy being present or not. It is presence of your inbound policy statement which will trigger the rejection. You really do not know if peer has any policy or not. /* For a moment I was thinking about adding capability but dropped that I think IX is a bit different as if you are plugged in to optimize traffic where you can via shortcut, have no peering relation with the other side eBGP (skip transparent RS from the picture) then I am not sure how much you can control inbound what you expect to get. Best, r On Thu, Jul 23, 2015 at 10:57 AM, Job Snijders wrote: > On Thu, Jul 23, 2015 at 10:52:59AM +0200, Robert Raszuk wrote: > > 2. > > > > What would be example of inbound policy in case to peering with route > > server in IX ? > > Same as with any other eBGP session: If the IX operator did not > configure any policy: reject all import/export. Do you feel this is a > different scenario that deserves different approach? > > Kind regards, > > Job > --e89a8f3ba5f38d634c051b873437 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Job,

=
But we are not talking about rejection based on the peer= 's policy being present or not. It is presence of your inbound policy s= tatement which will trigger the rejection. You really do not know if peer h= as any policy or not.

= /* For a moment I was thinking about adding capability but dropped that=C2= =A0

I think IX is a bi= t different as if you are plugged in to optimize traffic where you can via = shortcut, have no peering relation with the other side eBGP (skip transpare= nt RS from the picture) then I am not sure how much you can control inbound= what you expect to get.

Best,
r



On Thu, Jul 23, 2015 at 10:57 AM, Job Snijders <job@instituut= .net> wrote:
On Thu, Jul 23, 2015 at 10:52:59AM +0200, Robert Raszuk wrote:
> 2.
>
> What would be example of inbound policy in case to peering with route<= br> > server in IX ?

Same as with any other eBGP session: If the IX operator did not
configure any policy: reject all import/export. Do you feel this is a
different scenario that deserves different approach?

Kind regards,

Job

--e89a8f3ba5f38d634c051b873437-- From nobody Thu Jul 23 02:22: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 8A8221AC409 for ; Thu, 23 Jul 2015 02:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9yKaAm8m176u for ; Thu, 23 Jul 2015 02:22:27 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (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 691D61A8F46 for ; Thu, 23 Jul 2015 02:22:27 -0700 (PDT) Received: by wicmv11 with SMTP id mv11so15090131wic.0 for ; Thu, 23 Jul 2015 02:22:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=FwnlbkINt2B+n7/ucTMrL/BK/eu/TBJQfTlUOl+NCe8=; b=eK3X2etRdBksZTywBZMbaxzctukpA1A6DMZWNUpCGZEZW4smNxSRfP2VsKK9RD6J3Z AP/DG0FEYDmFB/VKaobsw+taQrF2w85w+3LqoIFtG0Q4raYXH1N2gOB3NKVFaNgRR8dQ dorNDjfYX65S/rWKbyOLzsZ2nwdIO/444pDexc3zg9As/uAVFJ8B9ofOmDmo7pjJyfwq mEwUbjbrqG0VVV3GkoEdr7MG54h4cF3xJabGRs2BGMi9VqxH8U2Nbag7c1MLMXwBNn0+ E4DQSI2v7M25ASpNBJYscLri3XClk9Gr2t+4eA9xlKG6CXxZkiIQYkHvdMzFDTElqEhQ oxoA== X-Gm-Message-State: ALoCoQkivJvbdl+FDb7u/j2udnu/v2vhkP59udiwLiQ0/zfeCW4U3gcvTc2/S1Ar2KXHl3xDjo99 X-Received: by 10.194.93.226 with SMTP id cx2mr13651259wjb.28.1437643346023; Thu, 23 Jul 2015 02:22:26 -0700 (PDT) Received: from localhost ([213.175.62.36]) by smtp.gmail.com with ESMTPSA id l2sm7548679wib.11.2015.07.23.02.22.24 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Jul 2015 02:22:24 -0700 (PDT) Date: Thu, 23 Jul 2015 11:22:22 +0200 From: Job Snijders To: Robert Raszuk Message-ID: <20150723092222.GS65805@dhcp-a1b1.meeting.ietf.org> References: <20150723085756.GR65805@dhcp-a1b1.meeting.ietf.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: idr wg list Subject: Re: [Idr] draft-mauch-bgp-reject 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 Jul 2015 09:22:31 -0000 On Thu, Jul 23, 2015 at 11:06:39AM +0200, Robert Raszuk wrote: > But we are not talking about rejection based on the peer's policy > being present or not. It is presence of your inbound policy statement > which will trigger the rejection. You really do not know if peer has > any policy or not. > > /* For a moment I was thinking about adding capability but dropped that > > I think IX is a bit different as if you are plugged in to optimize > traffic where you can via shortcut, have no peering relation with the > other side eBGP (skip transparent RS from the picture) then I am not > sure how much you can control inbound what you expect to get. This proposal does not require communication between peers about whether policy is present or not. If I connect a device to any eBGP speaker, and I did not configure any policy applied to that neighbor, my device MUST not accept or advertise any routes. This principle applies to all BGP speakers (including a Route Server). It is a local (to the device) decision only. Kind regards, Job From nobody Thu Jul 23 02:24: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 6E0431AC405 for ; Thu, 23 Jul 2015 02:24:04 -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 fZJ-aR8R3BvR for ; Thu, 23 Jul 2015 02:24:03 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c: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 EDC461A8870 for ; Thu, 23 Jul 2015 02:23:59 -0700 (PDT) Received: by wicgb10 with SMTP id gb10so133981084wic.1 for ; Thu, 23 Jul 2015 02:23:58 -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=smU3UmInMSv+XkAEDvXLZLDDbpJ/XCv5jAy1R9I8OVU=; b=KKJyLZsdciZFfAKtWDlIrWHRZ15XCPl0qgexI15G+MEKXSz9mgZa4F1fuR4DUe5ZI7 /zSgXmb6H25nOQy6tE5itM5JOHPsPLfIXkt6d53LhbhHsj9hkP8zMNbZjUTfYV6uhh4o Xx7ctBtZXb34iAU5p9zmfFsRfNELbL1uQ5SNOyt5+xdnWss35wAho5qTLoaXPZn0BdJy eSJ4OtsK+1R1pUf233iiMtFflA4k11QUSpdmHoHyZfqvBEDIFQ0WSOzqctOhw1IgkdIj lihDAZDZrIIH9dW65g/Q/QbktE3oNym7/J0MKeMHTBlNfUU7SfKnEC2fIyanjqtjmyxf qM0w== MIME-Version: 1.0 X-Received: by 10.194.120.198 with SMTP id le6mr13742029wjb.133.1437643438769; Thu, 23 Jul 2015 02:23:58 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.194.95.168 with HTTP; Thu, 23 Jul 2015 02:23:58 -0700 (PDT) In-Reply-To: <20150723092222.GS65805@dhcp-a1b1.meeting.ietf.org> References: <20150723085756.GR65805@dhcp-a1b1.meeting.ietf.org> <20150723092222.GS65805@dhcp-a1b1.meeting.ietf.org> Date: Thu, 23 Jul 2015 11:23:58 +0200 X-Google-Sender-Auth: CuZXZ_3RY0MxOYvD4CzXrQy-riw Message-ID: From: Robert Raszuk To: Job Snijders Content-Type: multipart/alternative; boundary=089e011600027b4d07051b87725d Archived-At: Cc: idr wg list Subject: Re: [Idr] draft-mauch-bgp-reject 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 Jul 2015 09:24:04 -0000 --089e011600027b4d07051b87725d Content-Type: text/plain; charset=UTF-8 Of course. I was just commenting on your sentence: "If the IX operator did not configure any policy: reject all import/export." Cheers, R. On Thu, Jul 23, 2015 at 11:22 AM, Job Snijders wrote: > On Thu, Jul 23, 2015 at 11:06:39AM +0200, Robert Raszuk wrote: > > But we are not talking about rejection based on the peer's policy > > being present or not. It is presence of your inbound policy statement > > which will trigger the rejection. You really do not know if peer has > > any policy or not. > > > > /* For a moment I was thinking about adding capability but dropped that > > > > I think IX is a bit different as if you are plugged in to optimize > > traffic where you can via shortcut, have no peering relation with the > > other side eBGP (skip transparent RS from the picture) then I am not > > sure how much you can control inbound what you expect to get. > > This proposal does not require communication between peers about whether > policy is present or not. If I connect a device to any eBGP speaker, and > I did not configure any policy applied to that neighbor, my device MUST > not accept or advertise any routes. This principle applies to all BGP > speakers (including a Route Server). It is a local (to the device) > decision only. > > Kind regards, > > Job > --089e011600027b4d07051b87725d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Of course.=C2=A0

I was just commenting on your sentence:=C2= =A0

"If the IX op= erator did not=C2=A0configure any policy: reject all import/export.&q= uot;

Cheer= s,
R.


On Thu, Jul 23, 2015 at 11:22 = AM, Job Snijders <job@instituut.net> wrote:
On Thu, Jul 23, 2015 at 11:06:39AM +0200= , Robert Raszuk wrote:
> But we are not talking about rejection based on the peer's policy<= br> > being present or not. It is presence of your inbound policy statement<= br> > which will trigger the rejection. You really do not know if peer has > any policy or not.
>
> /* For a moment I was thinking about adding capability but dropped tha= t
>
> I think IX is a bit different as if you are plugged in to optimize
> traffic where you can via shortcut, have no peering relation with the<= br> > other side eBGP (skip transparent RS from the picture) then I am not > sure how much you can control inbound what you expect to get.

This proposal does not require communication between peers about whe= ther
policy is present or not. If I connect a device to any eBGP speaker, and I did not configure any policy applied to that neighbor, my device MUST
not accept or advertise any routes. This principle applies to all BGP
speakers (including a Route Server). It is a local (to the device)
decision only.

Kind regards,

Job

--089e011600027b4d07051b87725d-- From nobody Thu Jul 23 02:31: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 126901A1A57 for ; Thu, 23 Jul 2015 02:31:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-Whd_N89ghj for ; Thu, 23 Jul 2015 02:31:23 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (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 AC8A81A0122 for ; Thu, 23 Jul 2015 02:31:23 -0700 (PDT) Received: by wicmv11 with SMTP id mv11so15412912wic.0 for ; Thu, 23 Jul 2015 02:31:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=0VYJtYoq0IP72tQOGaJtGq8/Sw/TBZ+yo5GRoUIgx0M=; b=XQ4H/8ol9qgIP/MmEXM6Ya9Iv0pVggLN1GAk+aI6RSdhCLGFCY/1xvwKQ3LDSx8/jQ gXi2/R0HJ+uO5TPQkLZP57qf1M7YunnwUoxm0DlxOeYEzfdwNxD70jTp8sTHlU/jEMD8 pjc61SsgwL6aVGRXCv6R6dM4FDeq4yCgm54iPb2GY2YXKYWmOiKkT1pQtB0jvfxSwAgn vu8Da3YE2/OvurhVH8lO6lyDo4op3FpLZjJNf/cNlUkbG2A1rPl2XNEbfEhqOUN4QIKA q3ECEcpxJmFu+lPkSd3/bHwN8EhdLYCdyN1oGdKR4PfJKcG7Oi+JOrWO5Tg2NsoYbRFy FqHw== X-Gm-Message-State: ALoCoQn4Dpt/9GbkWW1pHn2VC4GgvYyhF4A7cDPqkd6BSfqpVBXf9fEwTZ7/NjqLQg/t+z9R64Q0 X-Received: by 10.194.157.165 with SMTP id wn5mr14820951wjb.69.1437643881778; Thu, 23 Jul 2015 02:31:21 -0700 (PDT) Received: from localhost ([213.175.62.36]) by smtp.gmail.com with ESMTPSA id ev8sm6587108wjb.8.2015.07.23.02.31.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Jul 2015 02:31:20 -0700 (PDT) Date: Thu, 23 Jul 2015 11:31:18 +0200 From: Job Snijders To: Robert Raszuk Message-ID: <20150723093118.GT65805@dhcp-a1b1.meeting.ietf.org> References: <20150723085756.GR65805@dhcp-a1b1.meeting.ietf.org> <20150723092222.GS65805@dhcp-a1b1.meeting.ietf.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: idr wg list Subject: Re: [Idr] draft-mauch-bgp-reject 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 Jul 2015 09:31:25 -0000 On Thu, Jul 23, 2015 at 11:23:58AM +0200, Robert Raszuk wrote: > Of course. > > I was just commenting on your sentence: > > "If the IX operator did not configure any policy: reject all > import/export." Good to hear we are on the same page. A Route Server without any policy sounds like a dangerous thing, I strongly suspect every route server deployments in the wild has /some/ policy applied to all peers, if only to offer the participants a degree of propagation control. IX operators use BIRD or Quagga, and therefor imho just fall in the "BGP speakers" category, like any router. Kind regards, Job From nobody Thu Jul 23 02:34: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 7F9811A1B77 for ; Thu, 23 Jul 2015 02:34:43 -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 3HaWXZlpLgtA for ; Thu, 23 Jul 2015 02:34:42 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 345B21A009D for ; Thu, 23 Jul 2015 02:34:42 -0700 (PDT) Received: by wibud3 with SMTP id ud3so15528082wib.1 for ; Thu, 23 Jul 2015 02:34:40 -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=q+jOZyOvZ40jrzZKiDWJEitVuVRoDSEYvruvp2lHr+A=; b=auMEHk6/b4BvwWXwT+eLFrOWVhuTe3e72SR+tPdUju/9JgUXYwk7fpM8MtazLyYHgG 5MB+Z2nenGiyliadQo3IiYFtW49n6lbENOuWgcBLGBItPECSOD7BZiyzpuoK97Pazsuj uCHLvzOQF5Rd3aoKABU7gFvyEKJu2bGseoZh0FvRSFSZrkZUoslF/JFvsrPlVki+LiWN 5SEM1iP0ypqDnKLZEbDNbSgOJCCRK4yQV4F6AJwISQdFYMLddr61iytQOwU5MjNggJWP hqIXna0NHAm8whecsMEEl2UMNDtvfKaPt1HljjkVWzTyMXNnzRQvr/4/7dJ2npaqcitm jiYQ== MIME-Version: 1.0 X-Received: by 10.181.13.195 with SMTP id fa3mr14912205wid.7.1437644080893; Thu, 23 Jul 2015 02:34:40 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.194.95.168 with HTTP; Thu, 23 Jul 2015 02:34:40 -0700 (PDT) In-Reply-To: <20150723093118.GT65805@dhcp-a1b1.meeting.ietf.org> References: <20150723085756.GR65805@dhcp-a1b1.meeting.ietf.org> <20150723092222.GS65805@dhcp-a1b1.meeting.ietf.org> <20150723093118.GT65805@dhcp-a1b1.meeting.ietf.org> Date: Thu, 23 Jul 2015 11:34:40 +0200 X-Google-Sender-Auth: CyXAXz1yRakSWyNYoSbgTAE9VR4 Message-ID: From: Robert Raszuk To: Job Snijders Content-Type: multipart/alternative; boundary=f46d043c07d4c15bf4051b879827 Archived-At: Cc: idr wg list Subject: Re: [Idr] draft-mauch-bgp-reject 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 Jul 2015 09:34:43 -0000 --f46d043c07d4c15bf4051b879827 Content-Type: text/plain; charset=UTF-8 But I am not talking about RS in the point #2 at all :) I am talking about the client side connected via such transparent RS to a some unknown peers in the IX "cloud" ... and asking what such realistic inbound policy on the RS clients may be. RS is a topic on its own. Best, R. On Thu, Jul 23, 2015 at 11:31 AM, Job Snijders wrote: > On Thu, Jul 23, 2015 at 11:23:58AM +0200, Robert Raszuk wrote: > > Of course. > > > > I was just commenting on your sentence: > > > > "If the IX operator did not configure any policy: reject all > > import/export." > > Good to hear we are on the same page. > > A Route Server without any policy sounds like a dangerous thing, I > strongly suspect every route server deployments in the wild has /some/ > policy applied to all peers, if only to offer the participants a degree > of propagation control. IX operators use BIRD or Quagga, and therefor > imho just fall in the "BGP speakers" category, like any router. > > Kind regards, > > Job > --f46d043c07d4c15bf4051b879827 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

But I am n= ot talking about RS in the point #2 at all :)=C2=A0

I am talking about the client side connected = via such transparent RS to a some unknown peers in the IX "cloud"= ... and asking what such realistic inbound policy on the RS clients may be= .=C2=A0

RS is a topic = on its own.

Best,
R.





On Thu, Jul 23, = 2015 at 11:31 AM, Job Snijders <job@instituut.net> wrote:
On Thu, Jul 23, 2015 at 11= :23:58AM +0200, Robert Raszuk wrote:
> Of course.
>
> I was just commenting on your sentence:
>
> "If the IX operator did not configure any policy: reject all
> import/export."

Good to hear we are on the same page.

A Route Server without any policy sounds like a dangerous thing, I
strongly suspect every route server deployments in the wild has /some/
policy applied to all peers, if only to offer the participants a degree
of propagation control. IX operators use BIRD or Quagga, and therefor
imho just fall in the "BGP speakers" category, like any router.
Kind regards,

Job

--f46d043c07d4c15bf4051b879827-- From nobody Thu Jul 23 04:55: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 3E05A1A914F for ; Thu, 23 Jul 2015 04:55: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 V3NpHGq3zVu5 for ; Thu, 23 Jul 2015 04:55:30 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (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 C86B11A88A3 for ; Thu, 23 Jul 2015 04:55:29 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=31.133.178.123; From: "Susan Hares" To: "'idr wg list'" Date: Thu, 23 Jul 2015 07:55:24 -0400 Message-ID: <00cb01d0c53e$7685f880$6391e980$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CC_01D0C51C.EF75DF20" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdDFPeYxiITU7QjNTzqOIRqcIQe1LQ== Content-Language: en-us X-Authenticated-User: skh@ndzh.com X-IsFriend: Archived-At: Cc: shares@ndzh.com Subject: [Idr] Friday's Agenda and Slides are up 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 Jul 2015 11:55:31 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00CC_01D0C51C.EF75DF20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Friday's agenda and slides are online. The chairs would appreciate if the presenters would check the agenda and their slides. If there is an error, please John and Sue. By the way, all corrections should be sent to both of the chairs. Sue and John ------=_NextPart_000_00CC_01D0C51C.EF75DF20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Friday’s agenda and slides are = online.  

 

The chairs = would appreciate if the presenters would check the agenda and their = slides.  If there is an error, please John and Sue.  By the = way, all corrections should be sent to both of the chairs. =

 

Sue and John

------=_NextPart_000_00CC_01D0C51C.EF75DF20-- From nobody Thu Jul 23 05:33: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 DDE2E1A00AC for ; Thu, 23 Jul 2015 05:33:06 -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 pPCOivx3s7fO for ; Thu, 23 Jul 2015 05:33:05 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by ietfa.amsl.com (Postfix) with ESMTP id 4D74E1AC39C for ; Thu, 23 Jul 2015 05:33:01 -0700 (PDT) Received: from [IPv6:2001:67c:370:176:d46b:b88a:e6af:d41f] (unknown [IPv6:2001:67c:370:176:d46b:b88a:e6af:d41f]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id BA28E540AEC; Thu, 23 Jul 2015 08:32:59 -0400 (EDT) References: <20150723085756.GR65805@dhcp-a1b1.meeting.ietf.org> <20150723092222.GS65805@dhcp-a1b1.meeting.ietf.org> <20150723093118.GT65805@dhcp-a1b1.meeting.ietf.org> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-FCC5EC1B-25D0-46BC-88B9-F89D61FBC93E Content-Transfer-Encoding: 7bit Message-Id: <21738A36-55A4-4AC8-A994-27C82D9955AF@puck.nether.net> X-Mailer: iPhone Mail (12H143) From: Jon Mitchell Date: Thu, 23 Jul 2015 14:32:57 +0200 To: Robert Raszuk Archived-At: Cc: idr wg list Subject: Re: [Idr] draft-mauch-bgp-reject 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 Jul 2015 12:33:07 -0000 --Apple-Mail-FCC5EC1B-25D0-46BC-88B9-F89D61FBC93E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > On Jul 23, 2015, at 11:34 AM, Robert Raszuk wrote: >=20 >=20 > But I am not talking about RS in the point #2 at all :)=20 >=20 > I am talking about the client side connected via such transparent RS to a s= ome unknown peers in the IX "cloud" ... and asking what such realistic inbou= nd policy on the RS clients may be.=20 There are plenty of things worth filtering even from IX RS that I don't thin= k that this needs to be called out specifically in the draft. -Jon --Apple-Mail-FCC5EC1B-25D0-46BC-88B9-F89D61FBC93E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


On Jul 23, 2015, at= 11:34 AM, Robert Raszuk <robert@ras= zuk.net> wrote:


But I am not talking abo= ut RS in the point #2 at all :) 

I am talking about the client side connected via such transparen= t RS to a some unknown peers in the IX "cloud" ... and asking what such real= istic inbound policy on the RS clients may be. 

There are plenty of things worth filtering even from I= X RS that I don't think that this needs to be called out specifically in the= draft.

-Jon

= --Apple-Mail-FCC5EC1B-25D0-46BC-88B9-F89D61FBC93E-- From nobody Thu Jul 23 06:35: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 8F78A1A00B9 for ; Thu, 23 Jul 2015 06:35:24 -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 PhKdY1aBeQBb for ; Thu, 23 Jul 2015 06:35:18 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c: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 EFCC21A1A3B for ; Thu, 23 Jul 2015 06:35:17 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so208827098wib.0 for ; Thu, 23 Jul 2015 06:35:16 -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=MJRquMYk4+j7uwvWZFdrO719uHlFVNX9SMyGD9YEc/E=; b=0kCmwrD7FdamgIajoHBOEEPpV0cuD0bU0Mw+5d/7ZqlzO/pmQXQez99d81tM01o1XH zPux9Gyv8/GIVpzFVrrFu1oUvv56xZnnD3qZouMD4eJ928oNz4kzZqUFBobq2U7JI3Je S9nqN6SY81a3aDB90lCiehH656683CBIfdxpvBgzSF4Q0PodL/E8bupx7tMnk1lcUl8Z k+SdopzgBXoybigAQDTPow5rJni/Fa00+pGMDAKbCXP1mbRkUqWKd3I+IIAJU1FzfEsD UF+IQUMsOaZBVBAt7roqXJit6PvY1x+uV8nCfoqV26i38qNW6kPujYvaIgetNw/1X0Qw ElHA== MIME-Version: 1.0 X-Received: by 10.181.13.195 with SMTP id fa3mr16934468wid.7.1437658516767; Thu, 23 Jul 2015 06:35:16 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.194.95.168 with HTTP; Thu, 23 Jul 2015 06:35:16 -0700 (PDT) In-Reply-To: <21738A36-55A4-4AC8-A994-27C82D9955AF@puck.nether.net> References: <20150723085756.GR65805@dhcp-a1b1.meeting.ietf.org> <20150723092222.GS65805@dhcp-a1b1.meeting.ietf.org> <20150723093118.GT65805@dhcp-a1b1.meeting.ietf.org> <21738A36-55A4-4AC8-A994-27C82D9955AF@puck.nether.net> Date: Thu, 23 Jul 2015 15:35:16 +0200 X-Google-Sender-Auth: f5Ik0W4n_Hxa6lXRByH2I59Fta4 Message-ID: From: Robert Raszuk To: Jon Mitchell Content-Type: multipart/alternative; boundary=f46d043c07d4334b20051b8af5a0 Archived-At: Cc: idr wg Subject: Re: [Idr] draft-mauch-bgp-reject 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 Jul 2015 13:35:24 -0000 --f46d043c07d4334b20051b8af5a0 Content-Type: text/plain; charset=UTF-8 Well I wasn't asking to add it to the draft .. but just share on the list. But I get your point ... it is a good practice to say always filter inbound for example bogons. Thx, r. On Thu, Jul 23, 2015 at 2:32 PM, Jon Mitchell wrote: > > > On Jul 23, 2015, at 11:34 AM, Robert Raszuk wrote: > > > But I am not talking about RS in the point #2 at all :) > > I am talking about the client side connected via such transparent RS to a > some unknown peers in the IX "cloud" ... and asking what such realistic > inbound policy on the RS clients may be. > > > There are plenty of things worth filtering even from IX RS that I don't > think that this needs to be called out specifically in the draft. > > -Jon > > --f46d043c07d4334b20051b8af5a0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Well I wasn't asking to add it to t= he draft .. but just share on the list.=C2=A0

<= /div>
But I get your point ... it is a good practice to s= ay always filter inbound for example bogons.=C2=A0
=
Thx,
r.



On Thu, Jul 23, 2015 at 2:32 PM, Jo= n Mitchell <jrmitche@puck.nether.net> wrote:


On Jul 23, 2015, at 11:34 AM, Robert Raszuk <robert@raszuk.net> wrote:
<= br>

But I am not talking about RS in the point #2= at all :)=C2=A0

I am = talking about the client side connected via such transparent RS to a some u= nknown peers in the IX "cloud" ... and asking what such realistic= inbound policy on the RS clients may be.=C2=A0

There are plenty of things worth filtering even fr= om IX RS that I don't think that this needs to be called out specifical= ly in the draft.

-Jon

--f46d043c07d4334b20051b8af5a0-- From nobody Thu Jul 23 07:21: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 A95111ACE31; Thu, 23 Jul 2015 07:21:55 -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 AA0JBjkWuYr2; Thu, 23 Jul 2015 07:21:52 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0700.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::700]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 755BE1ACDE7; Thu, 23 Jul 2015 07:21:52 -0700 (PDT) Authentication-Results: pi.nu; dkim=none (message not signed) header.d=none; Received: from [172.29.64.169] (193.110.55.14) by BLUPR0501MB1825.namprd05.prod.outlook.com (10.163.121.148) with Microsoft SMTP Server (TLS) id 15.1.219.17; Thu, 23 Jul 2015 14:21:36 +0000 From: "John G. Scudder" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 23 Jul 2015 16:21:30 +0200 Message-ID: <87AB3A9A-0774-47FF-B48D-268BE4F1F2AF@juniper.net> To: Loa Andersson MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) X-Mailer: Apple Mail (2.2102) X-Originating-IP: [193.110.55.14] X-ClientProxiedBy: BLUPR07CA0041.namprd07.prod.outlook.com (10.255.223.154) To BLUPR0501MB1825.namprd05.prod.outlook.com (25.163.121.148) X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB1825; 2:fdqW9qGs78reMYXKPRyGR48J2WgvmNtDWUzG+un2jqypAOj5ygbpl8axHwZlm/cn; 3:sl7DK7fu3PNEHRWe7dxxfdQmM3whFmJdRNByM8NyKJkS7rj3GTA1vT+0Is1IM5FlkyoJwLBKJasRMtPS7WKtEAcXch+cxo58wIsC87cpBI1u6UUu3773cIYUjfBWnrutLX36/ZE94LiCUTJ0YuIZFw==; 25:4CocKd+9imvGdiLNjZcHr/Ngup8PsnKVr/Egaa894/G7yEbRJR7tG0v8nRh99gePMVAj7HUJOCmSWVq6DgFtOoqvmQjZn7nH636ygfPIIC5TfzS0wnfb+Fh7sLPQUxuNG3SlDSRBMB9uzNk4NoYCFY8iWu7zrBL+biaLUXRRgjJbyi7+Vfko0Meayg3S+cDRhMOYqF4mfgbZyrT3DUtuYO2tjgTKAX/8DquYmb7XkWkcHP18vwkYsx+MBplYa8jBWVBnLjw5t9XsWoTKhyVskw== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR0501MB1825; X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB1825; 20:RSWv3AMWjJ2lkMcRdSRqdrcNPx5TfYsQ82TthoukEXbLiLg+UTXoSbyRAe/YBaZ8fognzhjgOcHSe9EXOzFJlgtt6DwMLRvNlMGSFVYAZW5tEiZIvgRlIHUe+4MCNlrlhZHl3OJ0+NUNcA9c2z4yKw+F+MRvVXMvdA49YF4CWPGePYqyGKHCag59R5eg3IDxe49gBVBTeUFuY4w6wYouOuDg3CIrGi/MvdyRCSCA2KK/fKXehABzddkf9aVQcf7Z3XKjKZaBbflnWMsXI6kPzNDJiexH6NMqU1bxWPpCrVLK3X0FN2XnIQQjHthrHk7ZxmkuX1tfj+otKGKzxLXP8/1c3ZTd9wUpME6Pd/geP81BKQU1OS/a7e12DXGv1Qh8XVgy4W5f2iKEnGKZzm0NrmhdujZZJoiAwXgbLJxwcQt4usbL30ANbPqEVsc6stqsu/cjYLCfm8dKRjAEPMAZUaxnNw/MWlHkFARDVh+BvtqVYrfcF9L7RyCpWMAUEI0u; 4:vXNHTw8zft7CR1j1L76I/XtE7MpM9uAtXTyQL8sEGZFjH09/qNJcljFSJygUKoWmHIMMqxboY20700dFdfsWkZtXXjwihjevWt27JAXAq+g9ZmN84i6NDiLnfPpj17FiOZ4GAgeR7YL5S0fKXwmFN9ezHObE9pbkJVaGMN6PQxMkpVG8eH/zr0CkvHtpQtGTC8AxxFv4b8RL4l0AMElLOq0TsbLSovNOhUcVHthY7d/MEJecmg04TBe96UxS/4ea3M7QTNaqe/yLB4B8HJ6p4TtO3Z9wvpC6d00dHAse3k4= BLUPR0501MB1825: X-MS-Exchange-Organization-RulesExecuted 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:BLUPR0501MB1825; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB1825; X-Forefront-PRVS: 06469BCC91 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(6049001)(62966003)(47776003)(66066001)(97756001)(83716003)(92566002)(46406003)(122386002)(40100003)(77156002)(5001960100002)(42186005)(110136002)(50466002)(87976001)(33656002)(50986999)(23726002)(230783001)(57306001)(229853001)(82746002)(77096005)(189998001)(86362001)(46102003)(36756003)(50226001)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB1825; H:[172.29.64.169]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB1825; 23:CeVc2832W+klKtjiJc32k405a4YMfSsE+IrML2T6olPUv3nOoPwefbPinQ52rxvjK3wegqlmSN7OrFSIVPNz1akWkaIoc8J/GXt28Yum0J+nS6hcW+weMeYdgtp1KbDTrERdchkCSyz2yLEBo7ReIZR7Ybkhdu7RLEoW2zbII2kWUBCWNxzE8uQM2OpeWn0PMZaTF80qNUOC6w2q7pIz7gvSSRCO1trnTMhS/3vMiw0IBK7O20juoTtYsU+9ggW8JWos17VdPstNH4Q71mVOpVFZrK4eaCsrRyrrsr5u6FQX0Booq2pxVi+dYb5C/FbYTibfveRc5QZqHcC3vGHPPPlG5kVFBfsmbF43hEct0HU4i1cBMj4q0ARk6goLiB967bSGEcXHoDou+Jk03YfQFNIyW5C2FKL6Uz/HVYI7y+QbKEIAoWM7jh2FuG+T54rfCz46ZRRYOtaExQ3XobSJGz0XkosSRYT2TZ9Wqp5On1REy6rluvjfiPWchA0fOKwvM+LxuF0hh3qCWzi+5e5iFfrwYC0vnlMAvnQsQIxx4KiOt5nQUteDz+F8frdVTtAd/a72ONRV9Utc7l0nPahPCOjLfBCZIorb4TnC8/sLVmfdtG908opplczcStL9AfzHYK/S1qqTP1b9x3UM87GIA/p66bqdEPQtRIEwE8qgIRoZYWJpdRWYR7fQAQMuAtieFY1uCXf1+s1n/z6OEJCXQdopKhcHo3xxxVvJdWDw+u4Bt344WP40y/xhi9QES3OrbPmXhGW610SzlAyPEyOhQj3pCxNDna+fWNCxeJQ5yC+djLlNqH9gYPpp2Lc+79Wd/tbA8uNfsLn0N5Is8xsGAqt0DKFPWChkofvGbJ/+Vd4= X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB1825; 5:TCJlz0/H4BW+LgAFhiwt1eDW/uoDDeWflOAA+kEF1UceAo/0AA9quJVJPRrzVJyq6Mc+Y6bCj22GL09b05f27rvR9nOwUm+G5gU8sS5KBknD9UKxE2/Ud7Ks2PwLpSLrfqS3fY1giYrFKFto1bAExg==; 24:jXFtlZ3GoDx46ec664xtAgP/LGLmtmi3s21BkihUzykWaLRk04yuXyCxiTI+rhzm1dID7ba0N5OKFhBYWi86XyzyFzDXBgfGkB+DKy9ZPUU=; 20:aqKDkdnd6gi0JLKwvqEmmn1LG7vQ4Qe86v+V32GjpJo6I0nhOl/pPZs9up5ZU030zbGjEM8Ly4kQpG1QtThUwQ== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Jul 2015 14:21:36.5829 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB1825 Archived-At: Cc: "" , mpls@ietf.org, "idr@ietf. org" Subject: [Idr] disposition of draft-decraene-idr-next-hop-capability 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 Jul 2015 14:21:55 -0000 TL;DR: BGP infrastructure should be standardized in IDR, not in MPLS. Long form: Since Loa asked for this on the list... I generally agree that, assuming draft-decraene-idr-next-hop-capability = is progressed [*] it should be done in IDR. As someone else said at the = mic in the MPLS meeting just now, the reason is that the draft defines a = generic container, one application of which is Entropy Label, but whose = future uses are by no means limited to MPLS applications. The options = would seem to be: 1. Progress in IDR, with input from and joint last call with MPLS owing = to the EL part, 2. Progress in MPLS, with input from and joint last call with IDR owing = to the generic container part, 3. Split into a base document defining the container, to be progressed = in IDR, and an application document that specs EL using the container, = to be progressed in MPLS. Of these, I prefer 1 or 3. I prefer 1 over 2 because (as the speaker at = the mic said) the IDR questions and applicability seem broader than the = MPLS ones, in this case. 3 is probably a more formally proper = decomposition, but requires something like 2x the administrative = overhead. I am OK with that if either or both WGs prefer it that way, = and if the authors are willing to split it into two documents and = progress both.=20 HTH, --John [*] (which speaking with no WG chair hats on I think it should be)=20= From nobody Thu Jul 23 07:46: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 379781A8720; Thu, 23 Jul 2015 07:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=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 JoqYAcqraixv; Thu, 23 Jul 2015 07:46:08 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2797F1A8758; Thu, 23 Jul 2015 07:45:55 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 622AE2DC6D3; Thu, 23 Jul 2015 16:45:53 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 37C882380DB; Thu, 23 Jul 2015 16:45:53 +0200 (CEST) Received: from [10.193.116.37] (10.197.38.5) by PEXCVZYH02.corporate.adroot.infra.ftgroup (10.114.1.183) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 23 Jul 2015 16:45:52 +0200 References: <02ce01d0b851$4ecec5a0$ec6c50e0$@ndzh.com> <2691CE0099834E4A9C5044EEC662BB9D571ADA7E@dfweml701-chm> <55A0273D.4020608@juniper.net> <2691CE0099834E4A9C5044EEC662BB9D571B77BF@dfweml701-chm> <001001d0c136$290061b0$7b012510$@ndzh.com> From: Organization: Orange To: "idr@ietf.org" , BESS Message-ID: <10393_1437662753_55B0FE21_10393_2369_1_55B0FE1E.40600@orange.com> Date: Thu, 23 Jul 2015 16:45:50 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <001001d0c136$290061b0$7b012510$@ndzh.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.197.38.5] X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.7.23.142416 Archived-At: Cc: draft-ietf-bess-evpn-overlay@tools.ietf.org, draft-rosen-idr-tunnel-encaps@tools.ietf.org Subject: Re: [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00.txt (7/6 to 7/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: Thu, 23 Jul 2015 14:46:10 -0000 Hi, I think this draft will be a very useful tool to address different topics, in particular topics related to we integrate encapsulations over an IP transit with BGP VPNs, and I support its adoption by IDR. That said, I have the following comments that need to be addressed: * to allow multicast support in the context of RFC6514/6513, RFC7117, and RFC7432 with a consistent way of advertising the encapsulations, I think that draft-rosen-idr-tunnel-encaps-00 section 2.4 should also consider as a "labelled address family" an AFI/SAFI that may be associated to a PMSI Tunnel attribute, in which case the "embedded label" is the Label in the PMSI Tunnel Attribute * consistently with the above, 1/5 and 25/8 should also be added as authorized families in section 3 * draft-ietf-bess-evpn-overlay currently relies on the Tunnel Encap Extended Community to advertise the use of MPLS-over-GRE or VXLAN or NVGRE, and section 5.1.3 of that draft specifies that the VNI to use is the value in the Label field of the route -- this is I believe /nearly/ inline with draft-rosen-idr-tunnel-encaps, but the devil is in the details: if I read correctly draft-rosen-idr-tunnel-encaps-01 Section 7.2, the behavior consisting in using the embedded label as the VNI requires advertising a BGP Tunnel Encap Attribute with an Embedded Label Handling Sub-TLV with value 2, or not advertising a BGP Tunnel Encap at all (nor using the Tunnel Encapsulation ExtendedCommunity which is made semantically equivalent by section 6) --- it thus seems to me that one of the two drafts needs something to allow proper compatibility With a lesser priority, I have a few other comments as well: * I think the intent of the MPLS codepoint 10 for tunnel type, as defined in draft-ietf-bess-evpn-overlay, intends to indicate the ability to receive plain MPLS in a context where other encaps are advertised (if you advertise only one non-MPLS encap, it means you support this encap but not MPLS) -- this I think would be nice to capture in draft-rosen-idr-tunnel-encaps * about the Remote Endpoint sub-TLV: why allow that an AF of 0 means "use next-hop address", but still require the presence of the TLV ? it seems that its absence could conveniently be interpreted as "use next-hop address", like what's done for the Tunnel Encap EC in section 6 * section 6 should say that, associated to a labelled address family, the Tunnel Encap EC of value GRE (2) means the same as MPLS-in-GRE (value 11) (like section 2.2.5 does for the attribute) And my second head, the one trying to fill my BESS co-chair hat, can't help adding that addressing some of the above will require keeping the BESS working group involved all along the life of this draft. Best, -Thomas Susan Hares: > Based on the BESS chairs request this adoption call will be extended 2 weeks > to 7/31 for BESS WG membesr to comment. > > Sue Hares > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'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 information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. From nobody Fri Jul 24 00:57: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 00E3B1B3010 for ; Fri, 24 Jul 2015 00:57:08 -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 1B-iFtIreO08 for ; Fri, 24 Jul 2015 00:57:06 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (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 7F4DA1B3008 for ; Fri, 24 Jul 2015 00:57:06 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=31.133.178.123; From: "Susan Hares" To: "'Eric C Rosen'" , "'IDR WG'" References: <55AD1265.7090901@juniper.net> In-Reply-To: <55AD1265.7090901@juniper.net> Date: Fri, 24 Jul 2015 03:57:02 -0400 Message-ID: <025401d0c5e6$546d65f0$fd4831d0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFdi6kSVgCKVGBASXBVroJeKRCYX57QtTNw Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] Comment on draft-zhang-idr-upstream-assigned-label-solution 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, 24 Jul 2015 07:57:08 -0000 Eric: Thank you for your feedback on this draft. I look forward to the author's response to you. Sue -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Eric C Rosen Sent: Monday, July 20, 2015 11:23 AM To: IDR WG Subject: [Idr] Comment on draft-zhang-idr-upstream-assigned-label-solution I see that draft-zhang-idr-upstream-assigned-label-solution ("Upstream Assigned Label Collision Solution") is on the IDR agenda, so I'd like to make a comment. The draft talks about the use of "upstream-assigned labels" in the MVPN application, and discusses the problem of "collisions" when multiple routers independently assign upstream-assigned labels. However, collisions in the assignment of upstream-assigned labels are not possible, because every router assigns them from its own 20-bit per-router label space. Thus every assignment is unique in the context of the router that made the assignment. In the MVPN application, if a multicast data packet is carrying an upstream-assigned label and is traveling on a P2MP LSP, the packet will have at least two labels. The top label, probably assigned by mLDP or RSVP-TE-P2MP, is an ordinary downstream-assigned label that identifies the P2MP LSP. The upstream-assigned label would be the second label. The upstream-assigned label is always assigned by the router that is the root of the P2MP LSP. Thus one can infer from the top label the identity of the router that assigned the second label. Since the top label provides the context in which the second label is interpreted, no ambiguity (or collision) is possible, and there is no need to introduce procedures to coordinate label assignment among the routers. I suspect the authors are really thinking about "domain-wide labels", where multiple routers have to interpret labels from a single label space. If multiple routers are independently and dynamically assigning labels from a single label space, collisions are of course possible. But this is not a problem for an application, like MVPN, that doesn't use domain-wide labels. By the way, IDR actually doesn't seem like the most appropriate WG for this topic; I'd have thought it more relevant to MPLS, BESS, or SPRING. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From nobody Fri Jul 24 01:04: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 53F681B3027 for ; Fri, 24 Jul 2015 01:04:28 -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 n8t7ZWZZUPUH for ; Fri, 24 Jul 2015 01:04:26 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0772.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:772]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D608B1B301D for ; Fri, 24 Jul 2015 01:04:25 -0700 (PDT) Received: from CO1PR05MB441.namprd05.prod.outlook.com (10.141.73.147) by CO1PR05MB539.namprd05.prod.outlook.com (10.141.73.26) with Microsoft SMTP Server (TLS) id 15.1.219.17; Fri, 24 Jul 2015 08:04:04 +0000 Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none; Received: from hannes-mba.local (193.110.55.11) by CO1PR05MB441.namprd05.prod.outlook.com (10.141.73.147) with Microsoft SMTP Server (TLS) id 15.1.219.17; Fri, 24 Jul 2015 08:04:03 +0000 Received: from hannes-mba.local (localhost [IPv6:::1]) by hannes-mba.local (Postfix) with ESMTP id 76A5C155BE82; Fri, 24 Jul 2015 10:03:49 +0200 (CEST) Date: Fri, 24 Jul 2015 10:03:49 +0200 From: Hannes Gredler To: Susan Hares , idr wg list Message-ID: <20150724080349.GB18234@hannes-mba.local> References: <006001d0c309$3164b570$942e2050$@ndzh.com> <40C9243B-A6A6-4CE1-95F2-7898E6C7CAAA@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Originating-IP: [193.110.55.11] X-ClientProxiedBy: VI1PR02CA0042.eurprd02.prod.outlook.com (25.162.7.180) To CO1PR05MB441.namprd05.prod.outlook.com (10.141.73.147) X-Microsoft-Exchange-Diagnostics: 1; CO1PR05MB441; 2:D/45OfetbLoKEfQVpv5T0JgwoZ0zWlMRrgxOvNfbxCOkyU2F/RiZeDZmq+IMZhPL; 3:0baT6cLnUL0bLDWNdzzLjl1Ecvc3eaFDVWEn6GY20vwXpslS/QV4t1YKNZaZQfPGK76xYUnqtcdB3pyU2+Y4armspRNyOhBHgRqGdhzE7JPzUp+oACBv4WIgSPNLxddN0bAVSuKr1JuqKWNmIrO++A==; 25:gWYxgf/USKQ8Xn8f41Q37TU8auG6nssL0wldn1cQBXqYHMtp2A0TaSyfpNcLSvahyj+SsfBZ1kpMSPFMwB+Cm9x4DuToOpO20kyei8iyLEFKAZ531P1wXqIoE1UjwUU01s1Kybjbw+OBquGDytXcW4e8B6t3Fg3N/5VEbN3vBKy0FfgZKlpnQJYTc2JwV9ZasHMNCmPUWDensE6dI07Tw+yhH24/m2qbwgLc9AadOEwGTHs0ygLQbRWQb0ESfwvGZb195yzPhUBC3OXVTqpRGA== X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB441; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB539; X-Microsoft-Exchange-Diagnostics: 1; CO1PR05MB441; 20:xrj7M5sJl46bjG8HL5kFGm74NkJqrQdqZobTUb/TusJnYkatHLSMB9v98NbXFUkIYRGgec5BGqQZ5K6yLZUI9TyMunNSp8o7EIEn8Ruh7d2iHzV5n2v8XzaM0JLZJQJJpDqlydrsT44T7vpQ2NC3PA7H/krzGSzTO0tDKyyKDgij7yUixke0TM7DLd4P4BIXrUzzBmfaOPBGRzunlS5+jO1l0nBMPSZjYSZG/h9hEJmA1aUmg1jjB1TCNrE2SqIdZ2Tw9TMI3Fdy+W8wQYJUedDtXd0d0GNqj4+pUyzkab/pa8EHRdFtLyheoEbHnf+AB2PVVvoKBcowjMsePgkVD6rLl3I/tqBlGRtY23UmNzFraZYV2IejkEXBGDY0OYOOIYX89tqeCm3mt9dB5c+wlcamN5FCThdyA2QEGxlVWFpibRbfdYJ9xkxtbL0ql3F2ZDqYD9RegHZDqe5KadAMC2m66Qxz2CU+mU/voz/eI6nty2vbJXCQyjiCjFlKkKWA; 4:Gm0OPanHM9aKpRhUk7aHC7i1IWDbLQzm3zfScShKM4VHg5RdrSJRiSrwDX1hrR3NjSFPzbtlX63yy50Z/KQgZtxrVdMnBly/+N4a2SzIS+5EOENXvAwgnzxT7wjRXSSJ9EfkHcVjmOPgBtPzHRKGhGtJuE3F8DZpEI0pxamErtWLxOd0xz4bT/mem4P3OEPTiQKQxvOXZN4RuJA6pB26OEGyea8m3rIF2b93rqZjAbXjkl9/jS/MA/Z0O1Cnfe7cE0teVwqFbkSGrO5VRPDuugFjvnF1nb9aTKWTtF0b8ss= CO1PR05MB441: X-MS-Exchange-Organization-RulesExecuted 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:CO1PR05MB441; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB441; X-Forefront-PRVS: 0647963F84 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(24454002)(501624003)(479174004)(230783001)(40100003)(46406003)(46102003)(92566002)(66066001)(47776003)(77156002)(122386002)(76506005)(86362001)(87976001)(5003600100002)(50986999)(97756001)(5001960100002)(4001350100001)(62966003)(76176999)(23726002)(189998001)(122856001)(5001770100001)(98436002)(107886002)(54356999)(2950100001)(50466002)(77096005)(83506001)(15975445007)(33656002)(19580395003)(19580405001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB441; H:hannes-mba.local; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CO1PR05MB441; 23:OE3qH9lKrP5qonqtWeU2KJhg51EqWQue6dVybDI3wq?= =?us-ascii?Q?0OTv8kDyPped9TJl1GZgVBlxelpYZasu6mxjFcoAsPrpCgWFOq+c9379niOB?= =?us-ascii?Q?S2guQExlZiQhhgIqwr/lJe7Adi3UkiKiW+CoTIQECXTky9lf4I1dMG2PkMK9?= =?us-ascii?Q?FOW3PG85mQ5gX7no/uM1VGlGoRE1W997rBdy/boZKBGOKor2s+/GhApta/lz?= =?us-ascii?Q?iOmc6xnSsFTLUDS60+O2soXm20475RUvBUJmLmUaBVabLNwcC0rT9mCk00l5?= =?us-ascii?Q?klEIEauaZyPT8KTb0uNbgqGkzocqbsiPdblFolqtotLvGgRog7GQyFndZ0dm?= =?us-ascii?Q?HRsujKy3u0EejZwL9VlPV9vrVBcT9L6MK42nMFqFYe0RJS9/e4l0BAjpHNfe?= =?us-ascii?Q?RAT5xUqwfsu1lx1V1nOBsXPI4yDDFa/HscUwkvNgFFLkmMS+VeEGGCafuDMW?= =?us-ascii?Q?GBiZ0lupIGhVRmyR36ypziUSB/ofkZUc8+zJUGI316gyCW/JTssJVv89f8cQ?= =?us-ascii?Q?J6HKvqt4zrad5lzCa95dx7j1Eq/BNSc2gKgra7bHNgdZ1/G4w8iJ7FWUclKy?= =?us-ascii?Q?c3DpuWpGPJNuLFODN/J6TfRElFVYNEqJ15/HNjBblNqPbjYqTxI9gtcXRqma?= =?us-ascii?Q?luVOnM5lXoPy2ScnRPX0QrRVIBaipgE0vC+dY85tnU/IR3gDIgA0kGojZQA8?= =?us-ascii?Q?bH8ynyAgxkZKd0QJ6KY0ykOVt3Poo6V/rSFUFKUxPEvp9vNYSlp5nHyBhUh+?= =?us-ascii?Q?43VZTyFM33/IG8/JvXqBoUcXErX6ONbQSpPYx84H1PPZwMtzqRw1iRgPSgAr?= =?us-ascii?Q?7/stGFKco5Z4i2H86j8gaGv7zAZafigCT/bAUWAUjJSkAEpwIj7U5q36qFi5?= =?us-ascii?Q?Igzg4K/pNdParou2sJZaqatB9VBuglb1eiLkrJGto7xS5YhAmpVcU1xj4DdX?= =?us-ascii?Q?q1CljMy/SmDKA15htE2xr5yspuKBChnn22KSNEEQ0nvaxr0DoU1U/PNdg8CD?= =?us-ascii?Q?xnXKkK016Mbvz9S/92s6A2thacz3oGW4PIdQJ/kdK+GQO3q+crejOqU9pS3Y?= =?us-ascii?Q?JXPdk=3D?= X-Microsoft-Exchange-Diagnostics: 1; CO1PR05MB441; 5:2o+6fMnrX5pSYpobz5k1D11tyu41SjOYQTa+6yAOQyogKzrf0C0uFicWRtHbwk7IFMl1z9bQL+lLjFrHzHN3Kx8OS0TnT9oChp0LK7hhKfoUS7QFxO/AwsOY6shrLea0iCymmTI5Dr9KKp80VlCbuQ==; 24:hETgJA+lTev+Y4TGUhnk6Y7MWJvAMwKq77FQb87upVVFAyLzDXmSftGwnw0SO5926xuFDL8aNLI5PuOHClaEvBdqYmy1oexPkjM+brpq2uU=; 20:gB6bQ7rgdYMH8wvNYIvOFMeIjlEKI+kd/CgZRDG3KnFQRF4UK4vv7gdhggFiVygDu5/lZWo6E12IuLeaoFuOmw== X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Jul 2015 08:04:03.3082 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB441 X-Microsoft-Exchange-Diagnostics: 1; CO1PR05MB539; 2:UDS4nrvWlD1NJyXljaG8rbav7yQ5SwVqVEaHfGZl5IT0MTV2M9aLJq/99Vlvu2/Q; 3:vuaL0Yohvu9ZXFMXtv/Bxi0YnkXTI0GN3DEYmAMkavC8XP/ynfXGbXwF0W4kxO+ffvfttw2Sl/fHo0ZKGKQieedfUImVaalVFn7+CfsnlcInLbD5pyzafJNfpOhXRvMRThDPTqMAE1YTtvPoAlOZvw==; 25:m9M8/X9a1R2HMC1ADHL9/HfR1DZfWUD1lsFRbb20vVvYtlAhWQR9vKxg8qJPJ7pbIc6wHVQ/y92HZELkQD8Yp6aMIE6kRrheNggxtmH/JHoMW084PsfjbIk1pECROpGSystZnbp/lbVAOvt6mfcIZr/IqwMlSLnCjC9Y5qnsWJe3AbgQIR8XFV2R9QM++ddEdoNS6Owh5SUAhPSptlznZ0oHCiiq+xJHK22vaE6PsXYWERq9mVIR4iQWgGXeNJ+uVwgJ4W7jrZgkQDRXrTrsvw==; 20:0QplK/qZqVdxqwOvW2Fu2vBFse2NLXnMYxk/Hpfr2j1XhcVVLJ0/VhVK1s+cza2M0b2t7CuS2R5Ov2t4TmJSaw==; 23:P3mqY0QrA4PbYkYrsFZYS5bNsCpukAJw/VrJq6uPD9Az2GUE54KJ51IIjae4VvMZp2nnE384QVuIwmDJbe67wL/AwukXFvN4xUa+cqMRFw5860HmYG573EtUMQ7suVSAk6tqGOEgnqcF5HiyeVcmWjBZK6FqenARaQb03KFbRevejMVwiHLlIZko6zS4QwvQjroeNqU7cYiRgxwCkyFsu4hSxBAkw/szm3R60htumYy72lLM1nIulDjT4ZG7S5Ia CO1PR05MB539: X-MS-Exchange-Organization-RulesExecuted X-OriginatorOrg: juniper.net Archived-At: Subject: Re: [Idr] WG Adoption call - draft-keyupate-idr-bgp-prefix-sid (7/20 to 8/3) 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, 24 Jul 2015 08:04:28 -0000 support as co-author; i am not aware of IPR; 1) yes more than one. 2) all my technical concerns have been cleared with rev -05, so no /hannes | >On Jul 20, 2015, at 6:29 PM, Susan Hares wrote: | >> This begins a 2 week WG Adoption call for | >>draft-keyupate-idr-bgp-prefix-sid (7/20 to 8/3/2015). | >> http://datatracker.ietf.org/doc/draft-keyupate-idr-bgp-prefix-sid/ | >> | >> The authors should indicate if there is any IPR related to the draft. | >> We would appreciate if you would answer the following questions: | >> 1) Do you know of networks where this new BGP feature would useful? | >> 2) Do you know of any technical issues with this draft? | >> | >> In your discussion, please include whether you support the draft or not? | >> | >> Sue Hares and John Scudder | >> _______________________________________________ | >> 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 | | _______________________________________________ | Idr mailing list | Idr@ietf.org | https://www.ietf.org/mailman/listinfo/idr From nobody Fri Jul 24 01:40: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 A4C3B1A1AAD; Fri, 24 Jul 2015 01:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.761 X-Spam-Level: X-Spam-Status: No, score=-1.761 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_CHARSET_FARAWAY=2.45, 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 a7dfzP9GV5Uz; Fri, 24 Jul 2015 01:40:26 -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 0375D1A0231; Fri, 24 Jul 2015 01:40:24 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BVN43901; Fri, 24 Jul 2015 08:40:23 +0000 (GMT) Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 24 Jul 2015 09:40:22 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.210]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Fri, 24 Jul 2015 16:40:18 +0800 From: Xuxiaohu To: "thomas.morin@orange.com" , "idr@ietf.org" , BESS Thread-Topic: [bess] [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00.txt (7/6 to 7/20/2015) Thread-Index: AdC4UJG6Pj+U9ACORa+TFqfDTB54DgCOU6eAAB/2g4AAjPSngADtYxyAAQgHOAAANXKtPg== Date: Fri, 24 Jul 2015 08:40:17 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB01880@NKGEML512-MBS.china.huawei.com> References: <02ce01d0b851$4ecec5a0$ec6c50e0$@ndzh.com> <2691CE0099834E4A9C5044EEC662BB9D571ADA7E@dfweml701-chm> <55A0273D.4020608@juniper.net> <2691CE0099834E4A9C5044EEC662BB9D571B77BF@dfweml701-chm> <001001d0c136$290061b0$7b012510$@ndzh.com>, <10393_1437662753_55B0FE21_10393_2369_1_55B0FE1E.40600@orange.com> In-Reply-To: <10393_1437662753_55B0FE21_10393_2369_1_55B0FE1E.40600@orange.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.66.180] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "draft-ietf-bess-evpn-overlay@tools.ietf.org" , "draft-rosen-idr-tunnel-encaps@tools.ietf.org" Subject: Re: [Idr] [bess] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00.txt (7/6 to 7/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: Fri, 24 Jul 2015 08:40:31 -0000 SGkgYWxsLA0KDQpUaGUgbWFqb3IgcmF0aW9uYWxlIG9mIHRoZSBCR1AgRW5jYXAgU0FGSSBpcyBh cyBmb2xsb3dzOg0KDQogICJTaW5jZSB0aGUgZW5jYXBzdWxhdGlvbiBpbmZvcm1hdGlvbiBpcyBj b2RlZCBhcyBhbiBhdHRyaWJ1dGUsIG9uZQ0KICAgY291bGQgYXNrIHdoZXRoZXIgYSBuZXcgU0FG SSBpcyByZWFsbHkgcmVxdWlyZWQuICBBZnRlciBhbGwsIGEgQkdQDQogICBzcGVha2VyIGNvdWxk IHNpbXBseSBhdHRhY2ggdGhlIHR1bm5lbCBlbmNhcHN1bGF0aW9uIGF0dHJpYnV0ZSB0bw0KICAg ZWFjaCBwcmVmaXggKGxpa2UgUSBpbiBvdXIgZXhhbXBsZSkgdGhhdCBpdCBhZHZlcnRpc2VzLiAg QnV0IHdpdGgNCiAgIHRoYXQgdGVjaG5pcXVlLCBhbnkgY2hhbmdlIGluIHRoZSBlbmNhcHN1bGF0 aW9uIGluZm9ybWF0aW9uIHdvdWxkDQogICBjYXVzZSBhIHZlcnkgbGFyZ2UgbnVtYmVyIG9mIHVw ZGF0ZXMuICBVbmxlc3Mgb25lIHJlYWxseSB3YW50cyB0bw0KICAgc3BlY2lmeSBkaWZmZXJlbnQg ZW5jYXBzdWxhdGlvbiBpbmZvcm1hdGlvbiBmb3IgZWFjaCBwcmVmaXgsIGl0IGlzDQogICBtdWNo IGJldHRlciB0byBoYXZlIGEgbWVjaGFuaXNtIGluIHdoaWNoIGEgY2hhbmdlIGluIHRoZQ0KICAg ZW5jYXBzdWxhdGlvbiBpbmZvcm1hdGlvbiBjYXVzZXMgYSBCR1Agc3BlYWtlciB0byBhZHZlcnRp c2Ugb25seSBhDQogICBzaW5nbGUgdXBkYXRlLiAgQ29udmVyc2VseSwgd2hlbiBwcmVmaXhlcyBn ZXQgbW9kaWZpZWQsIHRoZSB0dW5uZWwNCiAgIGVuY2Fwc3VsYXRpb24gaW5mb3JtYXRpb24gbmVl ZCBub3QgYmUgZXhjaGFuZ2VkLiItLS1SRkM1NTEyDQoNCk5vdyBpdCBzZWVtcyB0aGF0IHRoZSBh Ym92ZSByYXRpb25hbGUgaGFzIGJlZW4gc2hha2VkIGJ5IHRoaXMgZHJhZnQuIEZ1dGhlcm1vcmUs IHNpbmNlIGl0IGFsbG93cyB0byBhdHRhY2ggQkdQIEVuY2FwIGF0dHJpYnV0ZXMgdG8gcm91dGVz IG5vdywgdGhlIEJHUCBlbmNhcHN1bGF0aW9uIGV4dGVuZGVkIGNvbW11bml0eSBjYW4gbm93IGJl IHNhZmVseSByZXBsYWNlZCBieSBCR1AgRW5jYXAgYXR0cmlidXRlLiBUaGVyZWZvcmUsIEkgd29u ZGVyIHdoZXRoZXIgUkZDNTUxMiB3b3VsZCBiZSBvYnNvbGV0ZWQgYnkgdGhpcyBkcmFmdCBpbiB0 aGUgZW5kLg0KDQpTaW5jZSBCR1AgZW5jYXBzdWxhdGlvbiBhdHRyaWJ1dGVzIGFyZSBub3cgYXR0 YWNoZWQgdG8gcm91dGVzLCB0aGUgQUZJL1NBRkkgb2YgdGhlIE5MUkkgaXMgYWxyZWFkeSBjYXBh YmxlIG9mIGluZGljYXRpbmcgdGhlIHBheWxvYWQgdHlwZSBvZiB0aGUgYWR2ZXJ0aXNlZCB0dW5u ZWwgcHJvdG9jb2wuIEZvciBleGFtcGxlLCBpZiBhIEJHUCBlbmNhcHN1bGF0aW9uIGF0dHJpYnV0 ZSBpbmRpY2F0aW5nIHRoZSBVRFAgdHVubmVsIGlzIGF0dGFjaGVkIHRvIGEgbGFiZWxlZCByb3V0 ZSwgaXQgd291bGQgYmUgb2J2aW91cyB0aGF0IE1QTFMtaW4tVURQIGlzIHN1cHBvcnRlZCBieSB0 aGUgb3JpZ2luYXRvciBvZiB0aGF0IHJvdXRlLiBJZiB0aGF0IHBhcnRpY3VsYXIgYXR0cmlidXRl IGlzIGF0dGFjaGVkIHRvIGEgdW5sYWJlbGVkIHJvdXRlLCBpdCBvYnZpb3VzbHkgaW5kaWNhdGVz IHRoYXQgSVAtaW4tVURQIGlzIHN1cHBvcnRlZC4gQXMgc3VjaCwgaXQgc2VlbXMgdW5uZWNlc3Nh cnkgdG8gYWxsb2NhdGUgdHdvIGFkZGl0aW9uYWwgdHlwZSBjb2RlcyBmb3IgTVBMUy1pbi1VRFAg YW5kIElQLWluLVVEUC4NCg0KQmVzdCByZWdhcmRzLA0KWGlhb2h1DQoNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kt6K8/sjLOiBCRVNTIFtiZXNzLWJvdW5jZXNA aWV0Zi5vcmddILT6se0gdGhvbWFzLm1vcmluQG9yYW5nZS5jb20gW3Rob21hcy5tb3JpbkBvcmFu Z2UuY29tXQ0Kt6LLzcqxvOQ6IDIwMTXE6jfUwjIzyNUgMjI6NDUNCsrVvP7IyzogaWRyQGlldGYu b3JnOyBCRVNTDQqzrcvNOiBkcmFmdC1pZXRmLWJlc3MtZXZwbi1vdmVybGF5QHRvb2xzLmlldGYu b3JnOyBkcmFmdC1yb3Nlbi1pZHItdHVubmVsLWVuY2Fwc0B0b29scy5pZXRmLm9yZw0K1vfM4jog UmU6IFtiZXNzXSBbSWRyXSAyIHdlZWsgYWRvcHRpb24gY2FsbCBmb3IgZHJhZnQtcm9zZW4taWRy LXR1bm5lbC1lbmFwcy0wMC50eHQgKDcvNiB0byA3LzIwLzIwMTUpDQoNCkhpLA0KDQpJIHRoaW5r IHRoaXMgZHJhZnQgd2lsbCBiZSBhIHZlcnkgdXNlZnVsIHRvb2wgdG8gYWRkcmVzcyBkaWZmZXJl bnQNCnRvcGljcywgaW4gcGFydGljdWxhciB0b3BpY3MgcmVsYXRlZCB0byB3ZSBpbnRlZ3JhdGUg ZW5jYXBzdWxhdGlvbnMgb3Zlcg0KYW4gSVAgdHJhbnNpdCB3aXRoIEJHUCBWUE5zLCBhbmQgSSBz dXBwb3J0IGl0cyBhZG9wdGlvbiBieSBJRFIuDQoNClRoYXQgc2FpZCwgSSBoYXZlIHRoZSBmb2xs b3dpbmcgY29tbWVudHMgdGhhdCBuZWVkIHRvIGJlIGFkZHJlc3NlZDoNCg0KKiB0byBhbGxvdyBt dWx0aWNhc3Qgc3VwcG9ydCBpbiB0aGUgY29udGV4dCBvZiBSRkM2NTE0LzY1MTMsIFJGQzcxMTcs DQphbmQgUkZDNzQzMiB3aXRoIGEgY29uc2lzdGVudCB3YXkgb2YgYWR2ZXJ0aXNpbmcgdGhlIGVu Y2Fwc3VsYXRpb25zLCBJDQp0aGluayB0aGF0ICBkcmFmdC1yb3Nlbi1pZHItdHVubmVsLWVuY2Fw cy0wMCBzZWN0aW9uIDIuNCBzaG91bGQgYWxzbw0KY29uc2lkZXIgYXMgYSAibGFiZWxsZWQgYWRk cmVzcyBmYW1pbHkiIGFuIEFGSS9TQUZJIHRoYXQgbWF5IGJlDQphc3NvY2lhdGVkIHRvIGEgUE1T SSBUdW5uZWwgYXR0cmlidXRlLCBpbiB3aGljaCBjYXNlIHRoZSAiZW1iZWRkZWQNCmxhYmVsIiBp cyB0aGUgTGFiZWwgaW4gdGhlIFBNU0kgVHVubmVsIEF0dHJpYnV0ZQ0KDQoqIGNvbnNpc3RlbnRs eSB3aXRoIHRoZSBhYm92ZSwgIDEvNSBhbmQgMjUvOCBzaG91bGQgYWxzbyBiZSBhZGRlZCBhcw0K YXV0aG9yaXplZCBmYW1pbGllcyBpbiBzZWN0aW9uIDMNCg0KKiBkcmFmdC1pZXRmLWJlc3MtZXZw bi1vdmVybGF5IGN1cnJlbnRseSByZWxpZXMgb24gdGhlIFR1bm5lbCBFbmNhcA0KRXh0ZW5kZWQg Q29tbXVuaXR5IHRvIGFkdmVydGlzZSB0aGUgdXNlIG9mIE1QTFMtb3Zlci1HUkUgb3IgVlhMQU4g b3INCk5WR1JFLCBhbmQgc2VjdGlvbiA1LjEuMyBvZiB0aGF0IGRyYWZ0IHNwZWNpZmllcyB0aGF0 IHRoZSBWTkkgdG8gdXNlIGlzDQp0aGUgdmFsdWUgaW4gdGhlIExhYmVsIGZpZWxkIG9mIHRoZSBy b3V0ZSAtLSB0aGlzIGlzIEkgYmVsaWV2ZSAvbmVhcmx5Lw0KaW5saW5lIHdpdGggZHJhZnQtcm9z ZW4taWRyLXR1bm5lbC1lbmNhcHMsIGJ1dCB0aGUgZGV2aWwgaXMgaW4gdGhlDQpkZXRhaWxzOiAg IGlmIEkgcmVhZCBjb3JyZWN0bHkgZHJhZnQtcm9zZW4taWRyLXR1bm5lbC1lbmNhcHMtMDEgU2Vj dGlvbg0KNy4yLCB0aGUgYmVoYXZpb3IgY29uc2lzdGluZyBpbiB1c2luZyB0aGUgZW1iZWRkZWQg bGFiZWwgYXMgdGhlIFZOSQ0KcmVxdWlyZXMgYWR2ZXJ0aXNpbmcgYSBCR1AgVHVubmVsIEVuY2Fw ICBBdHRyaWJ1dGUgd2l0aCBhbiBFbWJlZGRlZA0KTGFiZWwgSGFuZGxpbmcgU3ViLVRMViB3aXRo IHZhbHVlIDIsIG9yIG5vdCBhZHZlcnRpc2luZyBhIEJHUCBUdW5uZWwNCkVuY2FwIGF0IGFsbCAo bm9yIHVzaW5nIHRoZSBUdW5uZWwgRW5jYXBzdWxhdGlvbiBFeHRlbmRlZENvbW11bml0eSB3aGlj aA0KaXMgbWFkZSBzZW1hbnRpY2FsbHkgZXF1aXZhbGVudCBieSBzZWN0aW9uIDYpIC0tLSAgaXQg dGh1cyBzZWVtcyB0byBtZQ0KdGhhdCBvbmUgb2YgdGhlIHR3byBkcmFmdHMgbmVlZHMgc29tZXRo aW5nIHRvIGFsbG93IHByb3BlciBjb21wYXRpYmlsaXR5DQoNCg0KV2l0aCBhIGxlc3NlciBwcmlv cml0eSwgSSBoYXZlIGEgZmV3IG90aGVyIGNvbW1lbnRzIGFzIHdlbGw6DQoNCiogSSB0aGluayB0 aGUgaW50ZW50IG9mIHRoZSBNUExTIGNvZGVwb2ludCAxMCBmb3IgdHVubmVsIHR5cGUsIGFzDQpk ZWZpbmVkIGluIGRyYWZ0LWlldGYtYmVzcy1ldnBuLW92ZXJsYXksIGludGVuZHMgdG8gaW5kaWNh dGUgdGhlIGFiaWxpdHkNCnRvIHJlY2VpdmUgcGxhaW4gTVBMUyBpbiBhIGNvbnRleHQgd2hlcmUg b3RoZXIgZW5jYXBzIGFyZSBhZHZlcnRpc2VkIChpZg0KeW91IGFkdmVydGlzZSBvbmx5IG9uZSBu b24tTVBMUyBlbmNhcCwgaXQgbWVhbnMgeW91IHN1cHBvcnQgdGhpcyBlbmNhcA0KYnV0IG5vdCBN UExTKSAtLSB0aGlzIEkgdGhpbmsgd291bGQgYmUgbmljZSB0byBjYXB0dXJlIGluDQpkcmFmdC1y b3Nlbi1pZHItdHVubmVsLWVuY2Fwcw0KDQoqIGFib3V0IHRoZSBSZW1vdGUgRW5kcG9pbnQgc3Vi LVRMVjogd2h5IGFsbG93IHRoYXQgYW4gQUYgb2YgMCBtZWFucw0KInVzZSBuZXh0LWhvcCBhZGRy ZXNzIiwgYnV0IHN0aWxsIHJlcXVpcmUgdGhlIHByZXNlbmNlIG9mIHRoZSBUTFYgPyAgaXQNCnNl ZW1zIHRoYXQgaXRzIGFic2VuY2UgY291bGQgY29udmVuaWVudGx5IGJlIGludGVycHJldGVkIGFz ICJ1c2UNCm5leHQtaG9wIGFkZHJlc3MiLCBsaWtlIHdoYXQncyBkb25lIGZvciB0aGUgVHVubmVs IEVuY2FwIEVDIGluIHNlY3Rpb24gNg0KDQoqIHNlY3Rpb24gNiBzaG91bGQgc2F5IHRoYXQsIGFz c29jaWF0ZWQgdG8gYSBsYWJlbGxlZCBhZGRyZXNzIGZhbWlseSwNCnRoZSBUdW5uZWwgRW5jYXAg RUMgb2YgdmFsdWUgR1JFICgyKSBtZWFucyB0aGUgc2FtZSBhcyBNUExTLWluLUdSRQ0KKHZhbHVl IDExKSAobGlrZSBzZWN0aW9uIDIuMi41IGRvZXMgZm9yIHRoZSBhdHRyaWJ1dGUpDQoNCg0KQW5k IG15IHNlY29uZCBoZWFkLCB0aGUgb25lIHRyeWluZyB0byBmaWxsIG15IEJFU1MgY28tY2hhaXIg aGF0LCBjYW4ndA0KaGVscCBhZGRpbmcgdGhhdCBhZGRyZXNzaW5nIHNvbWUgb2YgdGhlIGFib3Zl IHdpbGwgcmVxdWlyZSBrZWVwaW5nIHRoZQ0KQkVTUyB3b3JraW5nIGdyb3VwIGludm9sdmVkIGFs bCBhbG9uZyB0aGUgbGlmZSBvZiB0aGlzIGRyYWZ0Lg0KDQpCZXN0LA0KDQotVGhvbWFzDQoNCg0K U3VzYW4gSGFyZXM6DQo+IEJhc2VkIG9uIHRoZSBCRVNTIGNoYWlycyByZXF1ZXN0IHRoaXMgYWRv cHRpb24gY2FsbCB3aWxsIGJlIGV4dGVuZGVkIDIgd2Vla3MNCj4gdG8gNy8zMSBmb3IgQkVTUyBX RyBtZW1iZXNyIHRvIGNvbW1lbnQuDQo+DQo+IFN1ZSBIYXJlcw0KPg0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBJZHIgbWFpbGluZyBsaXN0DQo+ IElkckBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lk cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkNlIG1lc3NhZ2UgZXQgc2VzIHBp ZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRp ZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYw0KcGFzIGV0cmUgZGlmZnVz ZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiBy ZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXINCmEgbCdleHBl ZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBt ZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sDQpP cmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFs dGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQoNClRoaXMgbWVzc2FnZSBhbmQgaXRz IGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9y bWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7DQp0aGV5IHNob3VsZCBub3QgYmUg ZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCklmIHlv dSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNl bmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KQXMgZW1h aWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhh dCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KVGhhbmsgeW91Lg0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KQkVTUyBt YWlsaW5nIGxpc3QNCkJFU1NAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vYmVzcw== From nobody Fri Jul 24 01:47: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 9D0081A00A1; Fri, 24 Jul 2015 01:47:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 8WNurMAgGCMn; Fri, 24 Jul 2015 01:47:16 -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 CC1991A1B0C; Fri, 24 Jul 2015 01:47:12 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BZC68593; Fri, 24 Jul 2015 08:47:11 +0000 (GMT) Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 24 Jul 2015 09:47:09 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.227]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Fri, 24 Jul 2015 16:47:01 +0800 From: "Dongjie (Jimmy)" To: "Acee Lindem (acee)" , Lou Berger , "draft-ietf-idr-te-lsp-distribution@ietf.org" Thread-Topic: [Idr] I-D Action: draft-ietf-idr-te-lsp-distribution-03.txt Thread-Index: AQHQiKgJCwRPna3Z/k6au5osFnF6jJ1wBaYAgAHJJ3D//6E6gIBzoeB3gABHm46AAx/lAIAAN5uAgAIXz6I= Date: Fri, 24 Jul 2015 08:47:01 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C927742EC1E5@nkgeml512-mbx.china.huawei.com> References: <20150507092713.29688.3632.idtracker@ietfa.amsl.com> <554B7098.1090101@labn.net> <76CD132C3ADEF848BD84D028D243C92757D10DAB@nkgeml512-mbx.china.huawei.com> <14d33532e98.276d.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <76CD132C3ADEF848BD84D028D243C92757D11D2B@nkgeml512-mbx.china.huawei.com> <55AD2FD2.4070605@labn.net> <76CD132C3ADEF848BD84D028D243C927742E4C72@nkgeml512-mbx.china.huawei.com> <55B07B80.6030302@labn.net>, In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.67.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] I-D Action: draft-ietf-idr-te-lsp-distribution-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: Fri, 24 Jul 2015 08:47:18 -0000 Hi Acee,=20 Thanks for pointing out this. Will check the definition in the latest veris= on.=20 Best regards, Jie ________________________________________ From: Acee Lindem (acee) [acee@cisco.com] Sent: Thursday, July 23, 2015 16:47 To: Lou Berger; Dongjie (Jimmy); draft-ietf-idr-te-lsp-distribution@ietf.or= g Cc: idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-te-lsp-distribution-03.txt Hi Jie, Lou, See one inline. On 7/23/15, 7:28 AM, "Idr on behalf of Lou Berger" wrote: >Jie, >See below. > >On 7/21/2015 10:06 AM, Dongjie (Jimmy) wrote: >> Hi Lou, >> >> Thanks for your response, and please see my replies inlined with [Jie]: >> >> ... >>>>>>> The 64-Bit 'Identifier' field is used to discriminate between >>>>>>> instances with different LSP technologies. The default >>>>>>>identifier >>>>>>> "0" identifies the instance for packet switched LSPs. >>>>>>> A new >>>>>>> identifier TBD is used to identify the instance of optical layer >>>>>>> LSPs. >>>>>> Doesn't it make more sense to just carry the values used in LSP >>>>>> switching >>>>> type >>>>>> (See rfc3473/7074) for the non-zero case? >>>>> I agree with your point that this document could cover LSPs with >>>>> different switching types. As for using the switching type values >>>>> directly as identifier, we coauthors will discuss it and then >>>>>feedback to you. >>>>> >>>> Sure, but unless there's a substantive justification, I really don't >>>>think we need >>>> another name/number space for the same thing. >>> What about we use another way to specify the LSP switching type: >>>include the Generalized Label Request Object in the LSP State >>>Information TLVs, as the switching type is one of the attributes of the >>>LSP. The NLRI is used to specify the identifiers of the LSP. >> So does this mean you'd drop the Identifier from the TE LSP NLRI? >> >> [Jie] Not exactly. As defined in draft-ietf-idr-ls-distribution, the >>identifier is used to identify the "routing universe" where the NLRI >>belongs. My suggestion is to not change the usage of this field. And if >>it is not applicable in some cases, it could be set to some default >>value. >Ahh. So the use of identifier in draft-ietf-idr-ls-distribution, which >basically identifies a routing instance, seems a bit different in your >document which says: > > The default identifier > "0" identifies the instance for packet switched LSPs. A new > identifier TBD is used to identify the instance of optical layer > LSPs. > >So I read this as a technology identifier not an instance identifier. >Perhaps this text needs to be revised? Or am I still missing something? This is from an older version of draft-ietf-idr-ls-distribution. I was the routing directorate reviewer and asked that it be changed. You can just take the definition from the latest version. Thanks, Acee > > >>> This would not require the assignment of several well-known values >>>from the identifier registry. Our concern is that this identifier field >>>and registry is generic for all BGP-LS NLRIs, and making reservations >>>for some specific NLRIs may restrict the usage of such values. >> I've read this a few times and concluded I don't really understand what >> you're proposing. Can you try stating it a different way? Perhaps just >> send the changes that you'd make. >> >> [Jie] Let me try to explain this. The above sentence was to specify the >>reasons of not allocating some specific identifier values to represent >>switching types. As I said in the previous response, the values of the >>identifier field should be applicable to all NLRI types, so the >>definition and allocation of the identifier values are better not be >>restricted to only applicable to a specific NLRI type (e.g. the TE LSP >>NLRI). >My point was pretty simple: if the values match, and always should >match, a list of values already maintained by IANA, I think pointing to >that list rather than trying to create a new one makes the most sense. >It sounds like you don't think there's a good list (registry) to leverage. > >> The proposed method is to reflect the LSP switchig type by including >>the Generalized Label Request Object in the LSP State TLV. >This should work > >>> If you agree with this method, we can add the corresponding >>>specifications in next revision. >-- I'll keep an eye out for it in the next version. >>>>>>> Currently the TE LSP Objects that can be carried in the LSP >>>>>>>State TLV >>>>>>> include: >>>>>> How do you distinguish between RSVP and PCEP objects? >>>>> Good question. My understanding is for the same information, the >>>>> format of RSVP and PCEP objects usually are compatible. In case there >>>>> is some discrepancy, the current strategy is, for information which >>>>> has corresponding RSVP object, the RSVP object is used, otherwise the >>>>> PCEP object is used. Or do you have some suggestions about this? >>>>> >>>> There is collision/ambiguity so I'd use a different type or add a >>>>subtype. >>> Our intention was to re-use the existing registries of LSP objects and >>>avoid defining a new one. The advantage is every time some new object >>>is defined in RSVP or PCEP, this BGP-LS specification does not need to >>>be revised. >> This makes sense >> >> [Jie] Glad that we agreed on this. >> >>> That said, I'd agree that the ambiguity between RSVP and PCEP objects >>>needs to be solved. >> yup, you currently have collision of values between protocols. >> >>> One possible solution for this is to make the LSP State information >>>TLVs hierarchical. We can define a set of top level TLVs, each one >>>identifies the source/format of the information carried. For example, >>>we can define a top-level sub-TLV for RSVP, which consists of the >>>existing RSVP objects. Similarly, define another top level sub-TLV for >>>PCEP, which carries the existing PCEP objects. We may also define a new >>>top level sub-TLV for LSP information derived from other sources. This >>>way we can solve the ambiguity without assigning new type values for >>>every existing object. Hope this is in line with your proposal "add a >>>subtype". >> Yes, a mean a subtype =3D {RSVP|PCEP} not defining new values for all >>objects. >> >> [Jie] Good, so we are in sync on the solution to this issue. > >Okay -- I'll also look for this change in the next version. > >Thanks, >Lou > >> Best regards, >> Jie >> >> Lou >>> Best regards, >>> Jie >>> >>>> Lou >>>> >>>>> Best regards, >>>>> Jie >>>>> >>>>>> Lou >>>>>> >>>>>> On 5/7/2015 5:27 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 : Distribution of MPLS Traffic Engineering >>>>>>>(TE) >>>> LSP >>>>>> State using BGP >>>>>>> Authors : Jie Dong >>>>>>> Mach(Guoyi) Chen >>>>>>> Hannes Gredler >>>>>>> Stefano Previdi >>>>>>> Jeff Tantsura >>>>>>> Filename : draft-ietf-idr-te-lsp-distribution-03.txt >>>>>>> Pages : 12 >>>>>>> Date : 2015-05-07 >>>>>>> >>>>>>> Abstract: >>>>>>> This document describes a mechanism to collect the Traffic >>>>>>> Engineering (TE) LSP information using BGP. Such information >>>>>>>can be >>>>>>> used by external components for path reoptimization, service >>>>>>> placement and network visualization. >>>>>>> >>>>>>> >>>>>>> >>>>>>> The IETF datatracker status page for this draft is: >>>>>>> https://datatracker.ietf.org/doc/draft-ietf-idr-te-lsp-distributio >>>>>>> n/ >>>>>>> >>>>>>> There's also a htmlized version available at: >>>>>>> https://tools.ietf.org/html/draft-ietf-idr-te-lsp-distribution-03 >>>>>>> >>>>>>> A diff from the previous version is available at: >>>>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-te-lsp-distribut= i >>>>>>> on-0 >>>>>>> 3 >>>>>>> >>>>>>> >>>>>>> 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 >>>>>>> >>>>>> _______________________________________________ >>>>>> 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 Fri Jul 24 01:54: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 C50521A1DBE; Fri, 24 Jul 2015 01:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.712 X-Spam-Level: X-Spam-Status: No, score=-99.712 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_FUTURE_24_48=2.048, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 WBMy06XDTP6c; Fri, 24 Jul 2015 01:53:53 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 8B23C1A1B19; Fri, 24 Jul 2015 01:53:53 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id EE1A039767ECB; Fri, 24 Jul 2015 16:48:49 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 15928ACE2D789; Fri, 24 Jul 2015 16:53:47 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id t6O8rBPu075431; Fri, 24 Jul 2015 16:53:11 +0800 (GMT-8) (envelope-from zhang.zheng@zte.com.cn) In-Reply-To: <025401d0c5e6$546d65f0$fd4831d0$@ndzh.com> References: <55AD1265.7090901@juniper.net> <025401d0c5e6$546d65f0$fd4831d0$@ndzh.com> To: "'Eric C Rosen'" , "Susan Hares" MIME-Version: 1.0 X-KeepSent: 690ED0BF:FD1E83D5-48257E8C:002E34EA; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: zhang.zheng@zte.com.cn Date: Sun, 26 Jul 2015 00:45:33 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2015-07-24 16:53:11, Serialize complete at 2015-07-24 16:53:11 Content-Type: multipart/alternative; boundary="=_alternative 0072CFE648257E8B_=" X-MAIL: mse01.zte.com.cn t6O8rBPu075431 Archived-At: Cc: 'IDR WG' , Idr Subject: Re: [Idr] Comment on draft-zhang-idr-upstream-assigned-label-solution 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, 24 Jul 2015 08:53:56 -0000 This is a multipart message in MIME format. --=_alternative 0072CFE648257E8B_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgUm9zZW4sIGhpIFN1ZSwNCg0KICAgIFRoYW5rcyBmb3IgcmVhZGluZyBvZiB0aGUgZHJhZnQu IFRoZXNlIHNjZW5lcyB0aGF0IGFyZSBtZW50aW9uZWQNCmJ5IFJvc2VuIGFyZSBub3QgY292ZXIg YWxsIHNpdHVhdGlvbnMuDQoNCiAgICBSb3V0ZXJzIGZvcndhcmQgTVZQTiBmbG93cyBieSBQMk1Q IExTUCwgYnV0IGFsc28gcm91dGVycw0KY2FuIGZvcndhcmQgTVZQTiBmbG93cyBieSBNUDJNUCBM U1AuIEFuZCBhcyBzb29uIGFzIHJvdXRlcnMgbWl4IHNldmVyYWwNCk1WUE4gZmxvd3MgaW50byBh IHNpbmdsZSBMU1AsIGNvbGxpc2lvbiB3aWxsIGhhcHBlbiwgYW5kIGl0IHdpbGwNCmluZmx1ZW5j ZSBkYXRhIGZvcndhcmRpbmcuDQogDQogICAgU28gSSB0aGluayBpdCBpcyBzdGlsbCBhIHByb2Js ZW0sIGlzbid0IGl0PyBmdXJ0aGVyIGRpc2N1c3Npb24gaXMgDQp3ZWxjb21lZC4NCiAgICBUaGFu a3MhDQoNClNhbmR5DQoNCg0KIklkciIgPGlkci1ib3VuY2VzQGlldGYub3JnPiDQtNPaIDIwMTUt MDctMjQgz8LO5yAwMzo1NzowMjoNCg0KPiAiU3VzYW4gSGFyZXMiIDxzaGFyZXNAbmR6aC5jb20+ IA0KPiC3orz+yMs6ICAiSWRyIiA8aWRyLWJvdW5jZXNAaWV0Zi5vcmc+DQo+IA0KPiAyMDE1LTA3 LTI0IM/CzucgMDM6NTcNCj4gDQo+IMrVvP7Iyw0KPiANCj4gIidFcmljIEMgUm9zZW4nIiA8ZXJv c2VuQGp1bmlwZXIubmV0PiwgIidJRFIgV0cnIiA8aWRyQGlldGYub3JnPiwgDQo+IA0KPiCzrcvN DQo+IA0KPiDW98ziDQo+IA0KPiBSZTogW0lkcl0gQ29tbWVudCBvbiBkcmFmdC16aGFuZy1pZHIt dXBzdHJlYW0tYXNzaWduZWQtbGFiZWwtc29sdXRpb24NCj4gDQo+IEVyaWM6IA0KPiANCj4gVGhh bmsgeW91IGZvciB5b3VyIGZlZWRiYWNrIG9uIHRoaXMgZHJhZnQuICAgSSBsb29rIGZvcndhcmQg dG8gdGhlIA0KYXV0aG9yJ3MNCj4gcmVzcG9uc2UgdG8geW91LiANCj4gDQo+IFN1ZSANCj4gDQo+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IElkciBbbWFpbHRvOmlkci1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRXJpYyBDIFJvc2VuDQo+IFNlbnQ6IE1vbmRheSwg SnVseSAyMCwgMjAxNSAxMToyMyBBTQ0KPiBUbzogSURSIFdHDQo+IFN1YmplY3Q6IFtJZHJdIENv bW1lbnQgb24gDQpkcmFmdC16aGFuZy1pZHItdXBzdHJlYW0tYXNzaWduZWQtbGFiZWwtc29sdXRp b24NCj4gDQo+IEkgc2VlIHRoYXQgZHJhZnQtemhhbmctaWRyLXVwc3RyZWFtLWFzc2lnbmVkLWxh YmVsLXNvbHV0aW9uICgiVXBzdHJlYW0NCj4gQXNzaWduZWQgTGFiZWwgQ29sbGlzaW9uIFNvbHV0 aW9uIikgaXMgb24gdGhlIElEUiBhZ2VuZGEsIHNvIEknZCBsaWtlIHRvDQo+IG1ha2UgYSBjb21t ZW50Lg0KPiANCj4gVGhlIGRyYWZ0IHRhbGtzIGFib3V0IHRoZSB1c2Ugb2YgInVwc3RyZWFtLWFz c2lnbmVkIGxhYmVscyIgaW4gdGhlIE1WUE4NCj4gYXBwbGljYXRpb24sIGFuZCBkaXNjdXNzZXMg dGhlIHByb2JsZW0gb2YgImNvbGxpc2lvbnMiIHdoZW4gbXVsdGlwbGUgDQpyb3V0ZXJzDQo+IGlu ZGVwZW5kZW50bHkgYXNzaWduIHVwc3RyZWFtLWFzc2lnbmVkIGxhYmVscy4NCj4gDQo+IEhvd2V2 ZXIsIGNvbGxpc2lvbnMgaW4gdGhlIGFzc2lnbm1lbnQgb2YgdXBzdHJlYW0tYXNzaWduZWQgbGFi ZWxzIGFyZSANCm5vdA0KPiBwb3NzaWJsZSwgYmVjYXVzZSBldmVyeSByb3V0ZXIgYXNzaWducyB0 aGVtIGZyb20gaXRzIG93biAyMC1iaXQgDQpwZXItcm91dGVyDQo+IGxhYmVsIHNwYWNlLiAgVGh1 cyBldmVyeSBhc3NpZ25tZW50IGlzIHVuaXF1ZSBpbiB0aGUgY29udGV4dCBvZiB0aGUgDQpyb3V0 ZXINCj4gdGhhdCBtYWRlIHRoZSBhc3NpZ25tZW50LiAgSW4gdGhlIE1WUE4gYXBwbGljYXRpb24s IGlmIGEgbXVsdGljYXN0IGRhdGENCj4gcGFja2V0IGlzIGNhcnJ5aW5nIGFuIHVwc3RyZWFtLWFz c2lnbmVkIGxhYmVsIGFuZCBpcyB0cmF2ZWxpbmcgb24gYSBQMk1QDQo+IExTUCwgdGhlIHBhY2tl dCB3aWxsIGhhdmUgYXQgbGVhc3QgdHdvIGxhYmVscy4gIFRoZSB0b3AgbGFiZWwsIHByb2JhYmx5 DQo+IGFzc2lnbmVkIGJ5IG1MRFAgb3IgUlNWUC1URS1QMk1QLCBpcyBhbiBvcmRpbmFyeSBkb3du c3RyZWFtLWFzc2lnbmVkIA0KbGFiZWwNCj4gdGhhdCBpZGVudGlmaWVzIHRoZSBQMk1QIExTUC4g IFRoZSB1cHN0cmVhbS1hc3NpZ25lZCBsYWJlbCB3b3VsZCBiZSB0aGUNCj4gc2Vjb25kIGxhYmVs LiAgVGhlIHVwc3RyZWFtLWFzc2lnbmVkIGxhYmVsIGlzIGFsd2F5cyBhc3NpZ25lZCBieSB0aGUg DQpyb3V0ZXINCj4gdGhhdCBpcyB0aGUgcm9vdCBvZiB0aGUgUDJNUCBMU1AuICBUaHVzIG9uZSBj YW4gaW5mZXIgZnJvbSB0aGUgdG9wIGxhYmVsIA0KdGhlDQo+IGlkZW50aXR5IG9mIHRoZSByb3V0 ZXIgdGhhdCBhc3NpZ25lZCB0aGUgc2Vjb25kIGxhYmVsLiAgU2luY2UgdGhlIHRvcCANCmxhYmVs DQo+IHByb3ZpZGVzIHRoZSBjb250ZXh0IGluIHdoaWNoIHRoZSBzZWNvbmQgbGFiZWwgaXMgaW50 ZXJwcmV0ZWQsIG5vIA0KYW1iaWd1aXR5DQo+IChvciBjb2xsaXNpb24pIGlzIHBvc3NpYmxlLCBh bmQgdGhlcmUgaXMgbm8gbmVlZCB0byBpbnRyb2R1Y2UgcHJvY2VkdXJlcyANCnRvDQo+IGNvb3Jk aW5hdGUgbGFiZWwgYXNzaWdubWVudCBhbW9uZyB0aGUgcm91dGVycy4NCj4gDQo+IEkgc3VzcGVj dCB0aGUgYXV0aG9ycyBhcmUgcmVhbGx5IHRoaW5raW5nIGFib3V0ICJkb21haW4td2lkZSBsYWJl bHMiLCANCndoZXJlDQo+IG11bHRpcGxlIHJvdXRlcnMgaGF2ZSB0byBpbnRlcnByZXQgbGFiZWxz IGZyb20gYSBzaW5nbGUgbGFiZWwgc3BhY2UuICBJZg0KPiBtdWx0aXBsZSByb3V0ZXJzIGFyZSBp bmRlcGVuZGVudGx5IGFuZCBkeW5hbWljYWxseSBhc3NpZ25pbmcgbGFiZWxzIGZyb20gDQphDQo+ IHNpbmdsZSBsYWJlbCBzcGFjZSwgY29sbGlzaW9ucyBhcmUgb2YgY291cnNlIHBvc3NpYmxlLiAN Cj4gQnV0IHRoaXMgaXMgbm90IGEgcHJvYmxlbSBmb3IgYW4gYXBwbGljYXRpb24sIGxpa2UgTVZQ TiwgdGhhdCBkb2Vzbid0IA0KdXNlDQo+IGRvbWFpbi13aWRlIGxhYmVscy4NCj4gDQo+IEJ5IHRo ZSB3YXksIElEUiBhY3R1YWxseSBkb2Vzbid0IHNlZW0gbGlrZSB0aGUgbW9zdCBhcHByb3ByaWF0 ZSBXRyBmb3IgDQp0aGlzDQo+IHRvcGljOyBJJ2QgaGF2ZSB0aG91Z2h0IGl0IG1vcmUgcmVsZXZh bnQgdG8gTVBMUywgQkVTUywgb3IgU1BSSU5HLg0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IElkciBtYWlsaW5nIGxpc3QNCj4gSWRy QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRyDQo+ IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBJ ZHIgbWFpbGluZyBsaXN0DQo+IElkckBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2lkcg0KDQo= --=_alternative 0072CFE648257E8B_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIFJvc2VuLCBoaSBTdWUsPC9mb250Pg0K PGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7IFRo YW5rcyBmb3IgcmVhZGluZyBvZg0KdGhlIGRyYWZ0LiBUaGVzZSBzY2VuZXMgdGhhdCBhcmUgbWVu dGlvbmVkPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5ieSBSb3Nl biBhcmUgbm90IGNvdmVyIGFsbCBzaXR1YXRpb25zLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyBSb3V0ZXJzIGZvcndhcmQgTVZQ TiBmbG93cw0KYnkgUDJNUCBMU1AsIGJ1dCBhbHNvIHJvdXRlcnM8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmNhbiBmb3J3YXJkIE1WUE4gZmxvd3MgYnkgTVAyTVAg TFNQLg0KQW5kIGFzIHNvb24gYXMgcm91dGVycyBtaXggc2V2ZXJhbDwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+TVZQTiBmbG93cyBpbnRvIGEgc2luZ2xlIExTUCwg Y29sbGlzaW9uDQp3aWxsIGhhcHBlbiwgYW5kIGl0IHdpbGw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmluZmx1ZW5jZSBkYXRhIGZvcndhcmRpbmcuPC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7IDwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyBTbyBJIHRo aW5rIGl0IGlzIHN0aWxsDQphIHByb2JsZW0sIGlzbid0IGl0PyBmdXJ0aGVyIGRpc2N1c3Npb24g aXMgd2VsY29tZWQuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4m bmJzcDsgJm5ic3A7IFRoYW5rcyE8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPlNhbmR5PGJyPg0KPC9mb250Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXpl PTI+JnF1b3Q7SWRyJnF1b3Q7ICZsdDtpZHItYm91bmNlc0BpZXRmLm9yZyZndDsg0LTT2g0KMjAx NS0wNy0yNCDPws7nIDAzOjU3OjAyOjxicj4NCjxicj4NCiZndDsgJnF1b3Q7U3VzYW4gSGFyZXMm cXVvdDsgJmx0O3NoYXJlc0BuZHpoLmNvbSZndDsgPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250 IHNpemU9Mj4mZ3Q7ILeivP7IyzogJm5ic3A7JnF1b3Q7SWRyJnF1b3Q7ICZsdDtpZHItYm91bmNl c0BpZXRmLm9yZyZndDs8YnI+DQomZ3Q7IDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXpl PTI+Jmd0OyAyMDE1LTA3LTI0IM/CzucgMDM6NTc8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQg c2l6ZT0yPiZndDsgPGJyPg0KJmd0OyDK1bz+yMs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQg c2l6ZT0yPiZndDsgPGJyPg0KJmd0OyAmcXVvdDsnRXJpYyBDIFJvc2VuJyZxdW90OyAmbHQ7ZXJv c2VuQGp1bmlwZXIubmV0Jmd0OywgJnF1b3Q7J0lEUg0KV0cnJnF1b3Q7ICZsdDtpZHJAaWV0Zi5v cmcmZ3Q7LCA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0 OyCzrcvNPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsg 1vfM4jwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IFJl OiBbSWRyXSBDb21tZW50IG9uIGRyYWZ0LXpoYW5nLWlkci11cHN0cmVhbS1hc3NpZ25lZC1sYWJl bC1zb2x1dGlvbjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQom Z3Q7IEVyaWM6IDxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGFuayB5b3UgZm9yIHlvdXIgZmVlZGJh Y2sgb24gdGhpcyBkcmFmdC4gJm5ic3A7IEkgbG9vayBmb3J3YXJkIHRvDQp0aGUgYXV0aG9yJ3M8 YnI+DQomZ3Q7IHJlc3BvbnNlIHRvIHlvdS4gJm5ic3A7PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFN1 ZSA8YnI+DQomZ3Q7IDxicj4NCiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQom Z3Q7IEZyb206IElkciBbPC9mb250PjwvdHQ+PGEgaHJlZj0ibWFpbHRvOmlkci1ib3VuY2VzQGll dGYub3JnIj48dHQ+PGZvbnQgc2l6ZT0yPm1haWx0bzppZHItYm91bmNlc0BpZXRmLm9yZzwvZm9u dD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0yPl0NCk9uIEJlaGFsZiBPZiBFcmljIEMgUm9zZW48 YnI+DQomZ3Q7IFNlbnQ6IE1vbmRheSwgSnVseSAyMCwgMjAxNSAxMToyMyBBTTxicj4NCiZndDsg VG86IElEUiBXRzxicj4NCiZndDsgU3ViamVjdDogW0lkcl0gQ29tbWVudCBvbiBkcmFmdC16aGFu Zy1pZHItdXBzdHJlYW0tYXNzaWduZWQtbGFiZWwtc29sdXRpb248YnI+DQomZ3Q7IDxicj4NCiZn dDsgSSBzZWUgdGhhdCBkcmFmdC16aGFuZy1pZHItdXBzdHJlYW0tYXNzaWduZWQtbGFiZWwtc29s dXRpb24gKCZxdW90O1Vwc3RyZWFtPGJyPg0KJmd0OyBBc3NpZ25lZCBMYWJlbCBDb2xsaXNpb24g U29sdXRpb24mcXVvdDspIGlzIG9uIHRoZSBJRFIgYWdlbmRhLCBzbw0KSSdkIGxpa2UgdG88YnI+ DQomZ3Q7IG1ha2UgYSBjb21tZW50Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGUgZHJhZnQgdGFs a3MgYWJvdXQgdGhlIHVzZSBvZiAmcXVvdDt1cHN0cmVhbS1hc3NpZ25lZCBsYWJlbHMmcXVvdDsN CmluIHRoZSBNVlBOPGJyPg0KJmd0OyBhcHBsaWNhdGlvbiwgYW5kIGRpc2N1c3NlcyB0aGUgcHJv YmxlbSBvZiAmcXVvdDtjb2xsaXNpb25zJnF1b3Q7IHdoZW4NCm11bHRpcGxlIHJvdXRlcnM8YnI+ DQomZ3Q7IGluZGVwZW5kZW50bHkgYXNzaWduIHVwc3RyZWFtLWFzc2lnbmVkIGxhYmVscy48YnI+ DQomZ3Q7IDxicj4NCiZndDsgSG93ZXZlciwgY29sbGlzaW9ucyBpbiB0aGUgYXNzaWdubWVudCBv ZiB1cHN0cmVhbS1hc3NpZ25lZCBsYWJlbHMNCmFyZSBub3Q8YnI+DQomZ3Q7IHBvc3NpYmxlLCBi ZWNhdXNlIGV2ZXJ5IHJvdXRlciBhc3NpZ25zIHRoZW0gZnJvbSBpdHMgb3duIDIwLWJpdCBwZXIt cm91dGVyPGJyPg0KJmd0OyBsYWJlbCBzcGFjZS4gJm5ic3A7VGh1cyBldmVyeSBhc3NpZ25tZW50 IGlzIHVuaXF1ZSBpbiB0aGUgY29udGV4dA0Kb2YgdGhlIHJvdXRlcjxicj4NCiZndDsgdGhhdCBt YWRlIHRoZSBhc3NpZ25tZW50LiAmbmJzcDtJbiB0aGUgTVZQTiBhcHBsaWNhdGlvbiwgaWYgYSBt dWx0aWNhc3QNCmRhdGE8YnI+DQomZ3Q7IHBhY2tldCBpcyBjYXJyeWluZyBhbiB1cHN0cmVhbS1h c3NpZ25lZCBsYWJlbCBhbmQgaXMgdHJhdmVsaW5nIG9uDQphIFAyTVA8YnI+DQomZ3Q7IExTUCwg dGhlIHBhY2tldCB3aWxsIGhhdmUgYXQgbGVhc3QgdHdvIGxhYmVscy4gJm5ic3A7VGhlIHRvcCBs YWJlbCwNCnByb2JhYmx5PGJyPg0KJmd0OyBhc3NpZ25lZCBieSBtTERQIG9yIFJTVlAtVEUtUDJN UCwgaXMgYW4gb3JkaW5hcnkgZG93bnN0cmVhbS1hc3NpZ25lZA0KbGFiZWw8YnI+DQomZ3Q7IHRo YXQgaWRlbnRpZmllcyB0aGUgUDJNUCBMU1AuICZuYnNwO1RoZSB1cHN0cmVhbS1hc3NpZ25lZCBs YWJlbCB3b3VsZA0KYmUgdGhlPGJyPg0KJmd0OyBzZWNvbmQgbGFiZWwuICZuYnNwO1RoZSB1cHN0 cmVhbS1hc3NpZ25lZCBsYWJlbCBpcyBhbHdheXMgYXNzaWduZWQNCmJ5IHRoZSByb3V0ZXI8YnI+ DQomZ3Q7IHRoYXQgaXMgdGhlIHJvb3Qgb2YgdGhlIFAyTVAgTFNQLiAmbmJzcDtUaHVzIG9uZSBj YW4gaW5mZXIgZnJvbSB0aGUNCnRvcCBsYWJlbCB0aGU8YnI+DQomZ3Q7IGlkZW50aXR5IG9mIHRo ZSByb3V0ZXIgdGhhdCBhc3NpZ25lZCB0aGUgc2Vjb25kIGxhYmVsLiAmbmJzcDtTaW5jZQ0KdGhl IHRvcCBsYWJlbDxicj4NCiZndDsgcHJvdmlkZXMgdGhlIGNvbnRleHQgaW4gd2hpY2ggdGhlIHNl Y29uZCBsYWJlbCBpcyBpbnRlcnByZXRlZCwgbm8NCmFtYmlndWl0eTxicj4NCiZndDsgKG9yIGNv bGxpc2lvbikgaXMgcG9zc2libGUsIGFuZCB0aGVyZSBpcyBubyBuZWVkIHRvIGludHJvZHVjZSBw cm9jZWR1cmVzDQp0bzxicj4NCiZndDsgY29vcmRpbmF0ZSBsYWJlbCBhc3NpZ25tZW50IGFtb25n IHRoZSByb3V0ZXJzLjxicj4NCiZndDsgPGJyPg0KJmd0OyBJIHN1c3BlY3QgdGhlIGF1dGhvcnMg YXJlIHJlYWxseSB0aGlua2luZyBhYm91dCAmcXVvdDtkb21haW4td2lkZQ0KbGFiZWxzJnF1b3Q7 LCB3aGVyZTxicj4NCiZndDsgbXVsdGlwbGUgcm91dGVycyBoYXZlIHRvIGludGVycHJldCBsYWJl bHMgZnJvbSBhIHNpbmdsZSBsYWJlbCBzcGFjZS4NCiZuYnNwO0lmPGJyPg0KJmd0OyBtdWx0aXBs ZSByb3V0ZXJzIGFyZSBpbmRlcGVuZGVudGx5IGFuZCBkeW5hbWljYWxseSBhc3NpZ25pbmcgbGFi ZWxzDQpmcm9tIGE8YnI+DQomZ3Q7IHNpbmdsZSBsYWJlbCBzcGFjZSwgY29sbGlzaW9ucyBhcmUg b2YgY291cnNlIHBvc3NpYmxlLiA8YnI+DQomZ3Q7IEJ1dCB0aGlzIGlzIG5vdCBhIHByb2JsZW0g Zm9yIGFuIGFwcGxpY2F0aW9uLCBsaWtlIE1WUE4sIHRoYXQgZG9lc24ndA0KdXNlPGJyPg0KJmd0 OyBkb21haW4td2lkZSBsYWJlbHMuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEJ5IHRoZSB3YXksIElE UiBhY3R1YWxseSBkb2Vzbid0IHNlZW0gbGlrZSB0aGUgbW9zdCBhcHByb3ByaWF0ZSBXRw0KZm9y IHRoaXM8YnI+DQomZ3Q7IHRvcGljOyBJJ2QgaGF2ZSB0aG91Z2h0IGl0IG1vcmUgcmVsZXZhbnQg dG8gTVBMUywgQkVTUywgb3IgU1BSSU5HLjxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0 OyBJZHIgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyBJZHJAaWV0Zi5vcmc8YnI+DQomZ3Q7IDwvZm9u dD48L3R0PjxhIGhyZWY9aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZHI+ PHR0Pjxmb250IHNpemU9Mj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lk cjwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCiZndDsgPGJyPg0KJmd0OyBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsg SWRyIG1haWxpbmcgbGlzdDxicj4NCiZndDsgSWRyQGlldGYub3JnPGJyPg0KJmd0OyA8L2ZvbnQ+ PC90dD48YSBocmVmPWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRyPjx0 dD48Zm9udCBzaXplPTI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZHI8 L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNpemU9Mj48YnI+DQo8L2ZvbnQ+PC90dD4NCg== --=_alternative 0072CFE648257E8B_=-- From nobody Fri Jul 24 02:09: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 E267D1A87DB; Fri, 24 Jul 2015 02:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 BsVBTQLkru_a; Fri, 24 Jul 2015 02:09:53 -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 53C6D1A87E0; Fri, 24 Jul 2015 02:09:51 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BZC71307; Fri, 24 Jul 2015 09:09:50 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 24 Jul 2015 10:09:48 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.227]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Fri, 24 Jul 2015 17:09:43 +0800 From: "Dongjie (Jimmy)" To: Lou Berger , "draft-ietf-idr-te-lsp-distribution@ietf.org" Thread-Topic: [Idr] I-D Action: draft-ietf-idr-te-lsp-distribution-03.txt Thread-Index: AQHQiKgJCwRPna3Z/k6au5osFnF6jJ1wBaYAgAHJJ3D//6E6gIBzoeB3gABHm46AAx/lAIACUeiv Date: Fri, 24 Jul 2015 09:09:43 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C927742EC307@nkgeml512-mbx.china.huawei.com> References: <20150507092713.29688.3632.idtracker@ietfa.amsl.com> <554B7098.1090101@labn.net> <76CD132C3ADEF848BD84D028D243C92757D10DAB@nkgeml512-mbx.china.huawei.com> <14d33532e98.276d.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <76CD132C3ADEF848BD84D028D243C92757D11D2B@nkgeml512-mbx.china.huawei.com> <55AD2FD2.4070605@labn.net> <76CD132C3ADEF848BD84D028D243C927742E4C72@nkgeml512-mbx.china.huawei.com>, <55B07B80.6030302@labn.net> In-Reply-To: <55B07B80.6030302@labn.net> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.67.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] I-D Action: draft-ietf-idr-te-lsp-distribution-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: Fri, 24 Jul 2015 09:09:57 -0000 Hi Lou,=20 Please see my replies inlined with [Jie#2]: Best regards, Jie ________________________________________ From: Lou Berger [lberger@labn.net] Sent: Thursday, July 23, 2015 13:28 To: Dongjie (Jimmy); draft-ietf-idr-te-lsp-distribution@ietf.org Cc: idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-te-lsp-distribution-03.txt Jie, See below. On 7/21/2015 10:06 AM, Dongjie (Jimmy) wrote: > Hi Lou, > > Thanks for your response, and please see my replies inlined with [Jie]: > > ... >>>>>> The 64-Bit 'Identifier' field is used to discriminate between >>>>>> instances with different LSP technologies. The default identifie= r >>>>>> "0" identifies the instance for packet switched LSPs. >>>>>> A new >>>>>> identifier TBD is used to identify the instance of optical layer >>>>>> LSPs. >>>>> Doesn't it make more sense to just carry the values used in LSP >>>>> switching >>>> type >>>>> (See rfc3473/7074) for the non-zero case? >>>> I agree with your point that this document could cover LSPs with >>>> different switching types. As for using the switching type values >>>> directly as identifier, we coauthors will discuss it and then feedback= to you. >>>> >>> Sure, but unless there's a substantive justification, I really don't th= ink we need >>> another name/number space for the same thing. >> What about we use another way to specify the LSP switching type: include= the Generalized Label Request Object in the LSP State Information TLVs, as= the switching type is one of the attributes of the LSP. The NLRI is used t= o specify the identifiers of the LSP. > So does this mean you'd drop the Identifier from the TE LSP NLRI? > > [Jie] Not exactly. As defined in draft-ietf-idr-ls-distribution, the iden= tifier is used to identify the "routing universe" where the NLRI belongs. M= y suggestion is to not change the usage of this field. And if it is not app= licable in some cases, it could be set to some default value. Ahh. So the use of identifier in draft-ietf-idr-ls-distribution, which basically identifies a routing instance, seems a bit different in your document which says: The default identifier "0" identifies the instance for packet switched LSPs. A new identifier TBD is used to identify the instance of optical layer LSPs. So I read this as a technology identifier not an instance identifier. Perhaps this text needs to be revised? Or am I still missing something? [Jie#2]: Agree that the text about the default identifier needs to be revis= ed. Will make the change in next revision.=20 >> This would not require the assignment of several well-known values from = the identifier registry. Our concern is that this identifier field and regi= stry is generic for all BGP-LS NLRIs, and making reservations for some spec= ific NLRIs may restrict the usage of such values. > I've read this a few times and concluded I don't really understand what > you're proposing. Can you try stating it a different way? Perhaps just > send the changes that you'd make. > > [Jie] Let me try to explain this. The above sentence was to specify the r= easons of not allocating some specific identifier values to represent switc= hing types. As I said in the previous response, the values of the identifie= r field should be applicable to all NLRI types, so the definition and alloc= ation of the identifier values are better not be restricted to only applica= ble to a specific NLRI type (e.g. the TE LSP NLRI). My point was pretty simple: if the values match, and always should match, a list of values already maintained by IANA, I think pointing to that list rather than trying to create a new one makes the most sense. It sounds like you don't think there's a good list (registry) to leverage. [Jie#2]: I totally agree with your idea of pointing to the existing registr= ies. That's why I suggest to reuse the Generalized Label Request Object to = reflect the switching type of the LSPs. And as you said, the identifier fie= ld is basically an instance identifier, so we will not use it as technology= identifier. > The proposed method is to reflect the LSP switchig type by including the = Generalized Label Request Object in the LSP State TLV. This should work [Jie#2]: Good we are agreed on this. >> If you agree with this method, we can add the corresponding specificatio= ns in next revision. -- I'll keep an eye out for it in the next version. [Jie#2]: OK. We will make the change and submit a new revision after the me= eting.=20 >>>>>> Currently the TE LSP Objects that can be carried in the LSP State = TLV >>>>>> include: >>>>> How do you distinguish between RSVP and PCEP objects? >>>> Good question. My understanding is for the same information, the >>>> format of RSVP and PCEP objects usually are compatible. In case there >>>> is some discrepancy, the current strategy is, for information which >>>> has corresponding RSVP object, the RSVP object is used, otherwise the >>>> PCEP object is used. Or do you have some suggestions about this? >>>> >>> There is collision/ambiguity so I'd use a different type or add a subty= pe. >> Our intention was to re-use the existing registries of LSP objects and a= void defining a new one. The advantage is every time some new object is def= ined in RSVP or PCEP, this BGP-LS specification does not need to be revised= . > This makes sense > > [Jie] Glad that we agreed on this. > >> That said, I'd agree that the ambiguity between RSVP and PCEP objects ne= eds to be solved. > yup, you currently have collision of values between protocols. > >> One possible solution for this is to make the LSP State information TLVs= hierarchical. We can define a set of top level TLVs, each one identifies t= he source/format of the information carried. For example, we can define a t= op-level sub-TLV for RSVP, which consists of the existing RSVP objects. Sim= ilarly, define another top level sub-TLV for PCEP, which carries the existi= ng PCEP objects. We may also define a new top level sub-TLV for LSP informa= tion derived from other sources. This way we can solve the ambiguity withou= t assigning new type values for every existing object. Hope this is in line= with your proposal "add a subtype". > Yes, a mean a subtype =3D {RSVP|PCEP} not defining new values for all obj= ects. > > [Jie] Good, so we are in sync on the solution to this issue. Okay -- I'll also look for this change in the next version. [Jie#2]: Thanks. We will make the change and submit a new revision after th= e meeting.=20 Thanks, Lou > Best regards, > Jie > > Lou >> Best regards, >> Jie >> >>> Lou >>> >>>> Best regards, >>>> Jie >>>> >>>>> Lou >>>>> >>>>> On 5/7/2015 5:27 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 : Distribution of MPLS Traffic Engineering (= TE) >>> LSP >>>>> State using BGP >>>>>> Authors : Jie Dong >>>>>> Mach(Guoyi) Chen >>>>>> Hannes Gredler >>>>>> Stefano Previdi >>>>>> Jeff Tantsura >>>>>> Filename : draft-ietf-idr-te-lsp-distribution-03.txt >>>>>> Pages : 12 >>>>>> Date : 2015-05-07 >>>>>> >>>>>> Abstract: >>>>>> This document describes a mechanism to collect the Traffic >>>>>> Engineering (TE) LSP information using BGP. Such information can= be >>>>>> used by external components for path reoptimization, service >>>>>> placement and network visualization. >>>>>> >>>>>> >>>>>> >>>>>> The IETF datatracker status page for this draft is: >>>>>> https://datatracker.ietf.org/doc/draft-ietf-idr-te-lsp-distributio >>>>>> n/ >>>>>> >>>>>> There's also a htmlized version available at: >>>>>> https://tools.ietf.org/html/draft-ietf-idr-te-lsp-distribution-03 >>>>>> >>>>>> A diff from the previous version is available at: >>>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-te-lsp-distributi >>>>>> on-0 >>>>>> 3 >>>>>> >>>>>> >>>>>> 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 >>>>>> >>>>> _______________________________________________ >>>>> Idr mailing list >>>>> Idr@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/idr= From nobody Fri Jul 24 04:15: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 DC4BA1A8980 for ; Fri, 24 Jul 2015 04:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.044 X-Spam-Level: X-Spam-Status: No, score=-99.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, T_HTML_ATTACH=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 gYqY1kBtTRDj for ; Fri, 24 Jul 2015 04:15:00 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (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 EBBBE1A0470 for ; Fri, 24 Jul 2015 04:14:59 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=31.133.178.123; From: "Susan Hares" To: "'IDR WG'" Date: Fri, 24 Jul 2015 07:14:55 -0400 Message-ID: <003e01d0c601$f92a24a0$eb7e6de0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_003F_01D0C5E0.72199610" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdDGASXjeqbcQmu/Rx+Kk+oHXEc0xA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [Idr] Rough notes for IDR 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, 24 Jul 2015 11:15:03 -0000 This is a multipart message in MIME format. ------=_NextPart_000_003F_01D0C5E0.72199610 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0040_01D0C5E0.72199610" ------=_NextPart_001_0040_01D0C5E0.72199610 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all: This is the rough notes for the IDR for Friday. Being the chair, I missed several pieces of the conversation. Sue ------=_NextPart_001_0040_01D0C5E0.72199610 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all: =

 

This is the rough notes for the IDR for Friday.  = Being the chair, I missed several pieces of the conversation. =

 

Sue

------=_NextPart_001_0040_01D0C5E0.72199610-- ------=_NextPart_000_003F_01D0C5E0.72199610 Content-Type: text/html; name="notes-ietf-93-idr.html" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="notes-ietf-93-idr.html" =0A= =0A= =0A= notes-ietf-93-idr=0A= =0A= =0A= =0A= IDR IETF 93 (Friday 7/24/2015)


  • draft-ietf-idr-flowspec-l2vpn-01 [Weiguo = Hao] 
    • Discussion: = [None]

  •  draft-hao-ls-trill-01   = [Donald Eastlake]
    • Discussion:  
      • John: A show of hands for those who read the = draft?  (5)
      • John: Who wants to approve the draft? = (5) 
      • John: Please request adoption on the = draft? 

  •  draft-hao-idr-flowspec-nv03-00 
    • Discussion: = [None] 


  • draft-li-idr-flowspec-rpd  [Eric = Wu] 
  Discussion: 
  •  Rudieger Volk: You had a customer with two = ASes. Which one did your customer AS? - 
  • Eric: ISP 100 is = your customer?  
  •  Acee Linden: The situation is = the same a segment routing. You are talking about  putting the = information on the policy on flow specification?  Could you = just  just control this with MED?
  • Eric: = (missed)
  •  John (WG member): Flow specification has been = about effecting the forwarding plane you are proposing to effect it for = the forwarding plane. You are arguing this is the only way to impact my = forwarding plane.  Why you discuss it, it is hard.  Policy has = is hard to do.  I2RS has taken on the approach with the policy. I = think you should take this to policy to the I2RS container which = is  based on this point. We've had a hard time to do even = one.  
  • Eric: I2RS is doing the = policy.  
  • Robin: We have done a policy work done in = lot of IETF work.  The policy work has been done in the IETF.  = The dynamic protocol will provide the policy is difficult to deploy at = this point.  We discuss with the customer on the policy = work.  
  • Acee: I think you need to do is to document = your assumptions.  I think you want the policy control to get the = route as well. You have to be co-resident with the routing so you can = set policy. The policy is controller must be  
  • Eric: I = lost some of your words.  Can we do this on the list? I will = respond. 
  • Acee: You can only set these flow specifications = for reachable information.  
  • Jeff: I shared = John's opinion that this is the wrong place. I think that = flow  specification.  I have concerns that BGP is being used = to transmit between routers. I am concerned that if you distributed with = the RR of BGP,  then the BGP peers will distribute to peers that do = not care.  Please join I2RS to discuss this within I2RS.  I = believe the  modelling work in yang. Robin: We also proposed other = yang models in the rtc = model.  
draft-liang-idr-bgp-flowspec-label = [Jianjie = You] 
Discussion: 
  • Jeff Haas: I apologize that have not read your = draft. These comments are based on your presentation.  The = draft-ietf-idr-flowspec-redirect-ip-02has covered the redirecting of = next hop. I think there is a link betweenthis and your request to link = flow-spec to RFC3107? Do you thinkthis would satisfy the requirements = you wish to specify?  I will copy my response to the = list. 

draft-wu-idr-flowspec-yang-cfg &nbs= p; [Aseem Choudary]

  • Jeff: You = did a nice job on separating this. I will be sending comments regarding = this model to the list. For the operational state,  you may not = have the state you have.  It may have difficulty mapping to = it.  
  • Aseem: Many times we have to map things to the = yang models.  This yang model may have to come from all the = vendors. 
  • Jeff: It is case for the vendors, packets will be = counted in  buckets that do not match your = work.  
  • Aseem: We have firewall rules and = (other)rules.  
  • Jeff: It is a nice model for flow = specification. #1 - It distributes firewall rules via BGP.  #2 - As = we our model this is a goodmodel for the adjRib In. This may be needed = in other models. The firewall rules may be useful for other = WGs. 
  • Sue: Let me take this in reverse order to make sure I = understand your comments. We have not included in the BGPmodel the = AdjRIB in. This model would be a good templatefor this addition. On the = second point, I understand that otherworking groups (such as I2NSF)are = adopting firewall filters, and we shouldlet them know about this = point. 
  • Aseem Choudary: The drafts for the distribution = were used for firewall rules. 
  • Jeff: This may be useful. = Rhis is associated with IDR, but it can be used for both. IGP are doing = flow specification within IGPs. While this mayseem a little weird, it = shows the within BGP  
  • Robin: According to my draft is = the configure and operational state.  
  • Aseem: = (missed) 
  •  Robin: Did you modify this from your = original draft.  Assem: We = did. 

 draft-zhang-idr-upstream-assigned-label-sol= ution-00     [Sandy = Zhang] 
         &nb= sp;      
[zzz]: Why not use router-id = and have simple record? You need a simply deterministic = manner? 
[Robin, Huawei]: You are using a tunnel from PE2 to = PE3.
[Sandy]: The tunnels from PE1-PE3 and PE2-PE3 are two different = tunnels. 
[Robin]: These have two sets of label space, and these = are different labels. 
[Sandy]: The tunnels (missed the = comments) 
[John]: Eric Rosen made the same point.  Did you = reply to his email.
[Sandy]: I answer this point. 
[George]: = The multiple point mpls being worked on.  
[John]: This is = work is  best done in MPLS. 
[George]: I think that the = BESS WG is already commented on = it. 

    

=0A= =0A= ------=_NextPart_000_003F_01D0C5E0.72199610-- From nobody Fri Jul 24 04:19: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 9D69B1A9059 for ; Fri, 24 Jul 2015 04:19:19 -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 lx8A57E8ok_S for ; Fri, 24 Jul 2015 04:19:18 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (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 750231A87D1 for ; Fri, 24 Jul 2015 04:19:15 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=31.133.178.123; From: "Susan Hares" To: "'IDR WG'" Date: Fri, 24 Jul 2015 07:19:09 -0400 Message-ID: <005a01d0c602$9085dab0$b1919010$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005B_01D0C5E1.097747F0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdDGAooCVjoUbTlHScuKHX2Qj5Rezw== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: "'John G. Scudder'" Subject: [Idr] Monday (7/21/2015) - nodes for IDR - Rought 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, 24 Jul 2015 11:19:19 -0000 This is a multipart message in MIME format. ------=_NextPart_000_005B_01D0C5E1.097747F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Admin Trivia ============ Agenda Bashing and Status Q&A 3 minutes Due to the short IDR meetings. The status is online. http://trac.tools.ietf.org/wg/idr/trac/wiki/idr-draft-status The chairs will answer questions on status on Monday. Existing Work: [30 minutes ] ============== draft-ietf-idr-bgpls-segment-routing-epe. 3 minutes (Stefano Previdi) [17:40-17:45] Discussion: None draft-ietf-idr-te-lsp-distribution 7 minutes (Jie Dong) [17:45-17:52] Discussion: None draft-ietf-idr-bgp-optimal-route-reflection 5 minutes (Bruno Decraene) [17:55-18:00] Discussion: none ietf-rs-bfd [18:00-18:10] 5 minutes [Discussion: None ] draft-jdurand-auto-bfd-00 3 minutes [not attending] Update on proposed drafts [30 minutes] ======================== [18:20-18:50] draft-keyupate-idr-bgp-prefix-sid 5 minutes (Stefano Previdi)[18:10-18:15] Discussion: Stefano: We want to have WG adoption call? John: How many have read the draft? [~25 people] John: How many think this is ready for adoption [~20 draft] Sue: We will do a WG adoptioin call. draft-walton-bgp-hostname-capability-00 10 minutes (Daniel Walton) [18:15-18:25] Discussion: 1) Joe Sideck: I provided feedback that this is not the best idea. Daniel: Some people liked it. Joe: We did reverse DNS. Daniel: We cannot do reverse DNS. xxx: (problem with the draft ) Daniel: Please detail this on the mailer. Jared: You should not use link-local address for the BGP. Using this provides a non-discriminate address. You can make one mistake and you will get into difficulties with the. Setting up the reverse DNS is not hard. You can get help with it. A lot of these routes are linux basis may sent out email. Having the DNS can help you with the transmission of the log files. I do know have experience you have with networks. Daniel: We have many customers. They do not type out the link-local address. John: Is the router exposed to the Internet network. Most of these are in the DC. Jared: Is the Data Center connected to the INternet. Rudieger: Add a column for summary, and instead of what you are putting out - add another one. Put the router-id out. Your identifier should be very clear. Jeff: The IESG wants to have interoperable situations. You do not want to use DNS. Expanded into the ____. John: Any further comments or fun. draft-fang-idr-bgplu-for-hsdn 20 minutes [Luyuan Fang] [18:20-18:40] Lucy: Is this allocation for any type of package? Is there multicast? Luyuan: We are just using the pipeline? ------=_NextPart_000_005B_01D0C5E1.097747F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Admin = Trivia

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Agenda Bashing and Status Q&A 3 = minutes

Due to the short IDR = meetings.

 The status is = online.

 http://trac.tools.ietf.org/wg/idr/trac/wiki/idr-d= raft-status

 The chairs will answer questions on status on = Monday. 

 

Existing = Work: [30 minutes ]

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

draft-ietf-idr-bgpls-segment-routing-epe. 3 = minutes

(Stefano Previdi) = [17:40-17:45]

 

Discussion: None

draft-ietf-idr-te-lsp-distribution   &nb= sp;    7 minutes

 (Jie = Dong)        = [17:45-17:52]

Discussion: None =

 

draft-ietf-idr-bgp-optimal-route-reflection 5 minutes =

 (Bruno Decraene) [17:55-18:00] =

 Discussion: none =

         &= nbsp;           &n= bsp;

ietf-rs-bfd       = [18:00-18:10]          = 5 minutes

[Discussion: None = ]

draft-jdurand-auto-bfd-00     =             3 = minutes 

[not attending] =

 

 

Update on = proposed drafts [30 minutes]

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D  [18:20-18:50]

= draft-keyupate-idr-bgp-prefix-sid      &nbs= p; 5 minutes

 (Stefano = Previdi)[18:10-18:15]

Discussion: =

 Stefano: We want to have WG = adoption call?

 John: How many = have read the draft? [~25 people]

= John: How many think this is ready for adoption [~20 = draft]

Sue: We will do a WG = adoptioin call.

 

 draft-walton-bgp-hostname-capability-00  10 = minutes

 (Daniel Walton)  = [18:15-18:25]

Discussion: =

 1) Joe Sideck: I provided = feedback that this is not the best idea.

Daniel: Some people liked it.

 Joe: We did reverse DNS.

 Daniel: We cannot do reverse DNS. =

 xxx: (problem with the draft = )

Daniel: Please detail this on the = mailer.

 Jared: You should not = use link-local address for the BGP.

 Using this provides a non-discriminate = address.  You can make one mistake

and you will get into difficulties with = the.

Setting up the reverse DNS is = not hard.  You can get help with it.

 A lot of these routes are linux basis may sent = out email.

 Having the DNS can = help you with the transmission of the log files.

 I do know have experience you have with = networks.

 Daniel: We have many = customers. They do not type out the link-local address.

John: Is the router exposed to the Internet = network.  Most of these

 are in the DC.

 Jared: Is the Data Center connected to the = INternet.

 Rudieger:  Add = a column for summary, and instead of what you are

 putting out - add another one.  Put the = router-id out. Your

identifier = should be very clear.

 Jeff: = The IESG wants to have interoperable situations.

 You do not want to use DNS. Expanded into the = ____.

 John: Any further = comments or fun.

  

 draft-fang-idr-bgplu-for-hsdn   &n= bsp;        20 minutes =

 [Luyuan = Fang]    [18:20-18:40]

Lucy: Is this allocation for any type of package? Is = there multicast?

 Luyuan: We = are just using the pipeline?

------=_NextPart_000_005B_01D0C5E1.097747F0-- From nobody Fri Jul 24 08:50: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 707BE1A1AB6; Fri, 24 Jul 2015 08:50:47 -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 uwzD9lecsIsf; Fri, 24 Jul 2015 08:50:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 34B341A1AE8; Fri, 24 Jul 2015 08:50:45 -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.1.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150724155045.28572.13507.idtracker@ietfa.amsl.com> Date: Fri, 24 Jul 2015 08:50:45 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-extended-messages-11.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: Fri, 24 Jul 2015 15:50:47 -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 : Extended Message support for BGP Authors : Keyur Patel Dave Ward Randy Bush Filename : draft-ietf-idr-bgp-extended-messages-11.txt Pages : 5 Date : 2015-07-24 Abstract: The BGP specification mandates a maximum BGP message size of 4096 octets. As BGP is extended to support newer AFI/SAFIs, there is a need to extend the maximum message size beyond 4096 octets. This document updates the BGP specification in RFC4271 by providing an extension to BGP to extend its current message size from 4096 octets to 65535 octets. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-bgp-extended-messages-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-extended-messages-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 24 12:24: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 793F41ACD9A; Fri, 24 Jul 2015 12:24:30 -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 quE7czWebxiw; Fri, 24 Jul 2015 12:24:28 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0787.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:787]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 168321ACD57; Fri, 24 Jul 2015 12:24:27 -0700 (PDT) Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none; Received: from [172.29.32.141] (66.129.241.14) by BN3PR0501MB1090.namprd05.prod.outlook.com (10.160.113.12) with Microsoft SMTP Server (TLS) id 15.1.219.17; Fri, 24 Jul 2015 19:24:07 +0000 To: , Susan Hares References: <55AD1265.7090901@juniper.net> <025401d0c5e6$546d65f0$fd4831d0$@ndzh.com> From: Eric C Rosen Message-ID: <55B290D2.20409@juniper.net> Date: Fri, 24 Jul 2015 15:24:02 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="gbk"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.14] X-ClientProxiedBy: BLUPR0601CA0025.namprd06.prod.outlook.com (25.163.210.35) To BN3PR0501MB1090.namprd05.prod.outlook.com (25.160.113.12) X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1090; 2:3/HQYUVLiQbgnRjbPv0bUN2unlkKuE1GQU2jZcC1cPmLs5dJiS3fgW6tKMxUrhDx; 3:Uqvu6xe5XF54wyhSujVln72s1jMrVL2/T5wmhBPd0ga5hOvQoanX1nN1xCPOENa5hYoTDxrHr+eK6NujRrc4k3SthfPVgNr2LDhjGCrsUaso6Jz8976NvSGvV47mkN/bCw8vXOaHylwl5tkMuhZHQQ==; 25:ywjw6Y2anG+XDKZmj1TF4N4NiRbXZkGaWCq7bO9Vz6YxpvJLCM0t7DA5bI0hG//e/iCqwNLLI6IIGRJfG8XpVdeYgbXWQwPTC+PK8n59anok7mrFwauEjQ/Czh2A6jjCg2kRgm2cCn/UQi2i2XzZS24kZ3d/IGEalTlq70X4/4uOEUtwHDY8QjYrPaX5HcCgRVmtXQkq4ta8jJjaQ7ew1MPZjWVvZP/bfU9ftZFx035PrXsT90XlnQFUi/YjImRn X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1090; X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1090; 20:krm3rMJLoF23OYzy6HSHhaTuYDj7p8oOUHLmKNIVBKp929L7w9Fio5AfYCyget6av8Ojwm5ZI8SqH5a97aCIkqE7jshj7KIrqWSs1dOEWvKEn/3zD03VSCIoGf3r86qpjHSlq98OgCvR9V+rAMuEny8G8bW1THonvqO07rl4lQIdZATXefKdWSj9O4hl7VqK2ZsDqnK/lDKY8jWm2xRFy9zLpCAA0u00w/n4yQG51rwg7mNWH7RAL1fgXqQN6hUhhDxRHd6ZRTmNI60/r0IFWOURVTslCpDbBQuSCR45B+bmqYwhWnl1T8jWIa6tzpPOf2ae1NzZkD2xvu4qhF39p8JlWoJtesu1szdVdu8TRq0MwR/8rVIvdw7xDqb0kHHysgEv38Q8mnWz+kHh8fGvSGRicJy2kkWQjPMzFXoky+vjCAW/MdTa6QCG/RR94mCgU0YZzN8fJkVxBXXxR55wIa2YD87AIH8x6OqEuOljA7PQlEEeSeDc1/BrKFKmNG+r; 4:H0NEBN8UOtzvWUumeI5nUwH/GvgSjaT/Hc5yDwyM2I58uJufSpT2/yi3Y7DG/XmuE+R9gnC43Z6r9r+fVJVBiSeav/ZjA8eH8Ut235Sch7gSwo/NmGcMzM/KtdEQpXfnubwbbfJIwrMJILjSqtrALw3A3RN90Yn2rxa40wHyuQbn5gUpWQNzBO3VcTx+TJdLgOnhdHvmbEroi6MIiyZURbvh8aRPLl+XBMG6AkiRtA6RWLx2sDk5w49vuZ/rNr9bpcQuhlmMUOcgP4IQKI2/7smXt6m5DPXlnykoEMFabLQ= BN3PR0501MB1090: X-MS-Exchange-Organization-RulesExecuted 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:BN3PR0501MB1090; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1090; X-Forefront-PRVS: 0647963F84 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(6049001)(377454003)(479174004)(24454002)(86362001)(122386002)(47776003)(189998001)(5001770100001)(46102003)(5001960100002)(4001350100001)(230783001)(40100003)(62966003)(77156002)(87976001)(42186005)(36756003)(65806001)(23696002)(33656002)(66066001)(50986999)(65956001)(77096005)(54356999)(19580405001)(19580395003)(92566002)(76176999)(65816999)(83506001)(2950100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1090; H:[172.29.32.141]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1090; 23:PbwyYpn/6CZpPOGeECYedSJE6rN/CL9aOiddzf6NXxRHHOcGfkYCgNr93QF2G6nGHDxllEDXkIcRA7UFoAsHlyo7iAImGG2nj+KqNPB6hlD14KlBVcVBYWlKPqUrs6hcO6Edzm/r1xKHEH6FjliBZjFFvr4LNeNCDulmvZcn3Op0Ec21RzEuJG/jxZd6qUEpsevRgMlJLUXw9kzYvXgkTNY27avt9zo933IP8I3w84bAtOo3YEu7cuda8+7jGS3jzdp2MOztoWep83uRdd+vpmmk2qxDtmrv7Y8CIUv7RaP7Jvyfq1q0UIVTF1iNxb/YVTVnR/jahpKZP776f+LijXL9up0Sfqr4TptZCuobGqPDVKVbuzYjjgxuPlhAjBA7xyG3XaIsFLqoS8jRMMrIRUhfVDcZ1eI+anidbr9WWBxyR669Pc3oeu96bDeUszTyGKqwwWL3V8F9oD2wt1m+8nXKQOYIubL6mWjs+PH9unV2jFY5ynB/aY6MD+WQZJtydkBhcHLRQ5OfubpovZOHHH20pH8VgUlnOgpb/U63e8QlTtT4ANpoOBCEQofYaNV7N19E2n21KOBQXWSYRFWkZnfZtxbzeV9M7rsUld1IwmM6YiWDc4hfhjFuEy4x0CMtT4NIgrU3pZUTtyXHk2vu8xZvFZ0MFmPx5hhZPWAfEysINV5yw6ZYAV4HcTFeNYLKk9c2AJBxPtVVJkn+8dSbf9bEizAlTFGQvL2PxuNLI2hJoHjqipPyA7bzaMffBoXgAIJaEq+g0s4nGxhn1h1XuiraYu/rVEmEIhoyiThPcZRcoW4CWuChwFPGckQIc9rp7Gu4Adswe5A2vPgFI32Sv6Vzhl3cUJFZIoKs/6RMn8G2Zycvwtp5MygutNKnjyu7ME0TG0qMP1oLWbLYOEmVB/6PJ5upcbRKGmtxWaN7wHQxw3nxzaf2aSuflOqTqDP6 X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1090; 5:z8ZHXulNK0oG7SlfoU2GdiPsRB3jx38JY/HvxT7aXyEj4wd6uTEufMXpNSdoB07k4wVFMMZfu40RhmMx72CvwgMcmgHvSogCWwUA1/PIrbe4djEtD3YS6DokSLYp7QfKQW/pvSVw0wd8Sbj4xbbRSA==; 24:qj6FOQWpvCors9NGIfe05V1FmS4ArYHSclOtpSovZXcSRAf6P7/3k4SUpuWrk2mSr4J0B/I1MwycJkvXvdFSRg5b3drN0xRxpHNI+yanxR0=; 20:uL2Iy33vzlpYzylKlE5YHd7ovjtig4NxxV/j+7NibmtqUVlTROXIBI8Rgjzk5ZOjpkqYPs0HkpYqlLtue0Kn9w== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Jul 2015 19:24:07.0507 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1090 Archived-At: Cc: 'IDR WG' , Idr Subject: Re: [Idr] Comment on draft-zhang-idr-upstream-assigned-label-solution 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, 24 Jul 2015 19:24:30 -0000 On 7/25/2015 12:45 PM, zhang.zheng@zte.com.cn wrote: > Routers forward MVPN flows by P2MP LSP, but also routers > can forward MVPN flows by MP2MP LSP. And as soon as routers mix several > MVPN flows into a single LSP, collision will happen, and it will > influence data forwarding. An MP2MP LSP has a single root node, and that root node would be responsible for assigning any upstream-assigned labels that are used within that LSP. Just for clarity, the upstream-assigned label in the PMSI Tunnel attribute is not needed when multiple flows are being transmitted on a single LSP, it is needed only when flows from multiple VPNs are are transmitted on a single LSP. I have to admit that using a single MP2MP LSP to carry traffic of several different VPNs is not a scenario that has been given a lot of attention, and will probably only work if (a) the hierarchical partitioned method (see RFC 7582) is used, and (b) all those VPNs have VRFs at the root node. But it's not clear that there's any real value to multiplexing several VPNs onto a single MP2MP LSP. There is another use of upstream-assigned labels described in RFC 7582 ("PE Distinguisher labels"), and those are always assigned by the root node of the MP2MP LSP. From nobody Sat Jul 25 18:21: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 BF14C1ACD98 for ; Sat, 25 Jul 2015 18:21:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.364 X-Spam-Level: **** X-Spam-Status: No, score=4.364 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FH_RELAY_NODNS=1.451, HELO_EQ_MODEMCABLE=0.768, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, 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 ObSyjqGikIvL for ; Sat, 25 Jul 2015 18:21:03 -0700 (PDT) Received: from cdcipgw01.twcable.com (unknown [165.237.91.110]) by ietfa.amsl.com (Postfix) with ESMTP id 7390B1ACD94 for ; Sat, 25 Jul 2015 18:21:03 -0700 (PDT) X-SENDER-IP: 10.136.163.13 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.15,544,1432612800"; d="scan'208";a="337351806" Received: from unknown (HELO PRVPEXHUB04.corp.twcable.com) ([10.136.163.13]) by cdcipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 25 Jul 2015 21:17:51 -0400 Received: from PRVPEXVS10.corp.twcable.com ([10.136.163.41]) by PRVPEXHUB04.corp.twcable.com ([10.136.163.13]) with mapi; Sat, 25 Jul 2015 21:21:01 -0400 From: "George, Wes" To: Jared Mauch , idr wg list Date: Sat, 25 Jul 2015 21:21:01 -0400 Thread-Topic: [Idr] draft-mauch-bgp-reject Thread-Index: AdDHQVVOICtOwukER+GBiPiyPNfolg== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.3.150624 acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] draft-mauch-bgp-reject 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 Jul 2015 01:21:06 -0000 SSBzdXBwb3J0IHRoZSBpZGVhIG9mIHRoaXMgZHJhZnQuIEkgYWdyZWUgdGhhdCBpdCBoYXMgYW4g dXBoaWxsIGNsaW1iIHdoZW4NCml0IGNvbWVzIHRvIGltcGxlbWVudGF0aW9uIGR1ZSB0byB0aGUg aW1wYWN0IG9mIHBlb3BsZSB3aG8gZG9uJ3QgcmVhZA0KcmVsZWFzZSBub3RlcyBhbmQgaGF2ZSBh IGJ1bmNoIG9mIEJHUCBzdG9wIHdvcmtpbmcgd2hlbiB0aGV5IHVwZ3JhZGUgY29kZQ0KKG9yIG5l dmVyIHNlZSB0aGUgY2hhbmdlIGJlY2F1c2UgdGhleSBkb24ndCB1cGdyYWRlIGNvZGUpLCBidXQg SSBzZWUgdGhlDQp2YWx1ZSBpbiBoYXJtb25pemluZyB0aGUgZGVmYXVsdCBiZWhhdmlvciB0byBz b21ldGhpbmcgdGhhdCBwcm92aWRlcyBhDQpsaXR0bGUgYmV0dGVyIHByb3RlY3Rpb24uDQoNClRo YXQgc2FpZCwgSSB0aGluayB0aGF0IHdlIG1heSBoYXZlIGFuIG9wcG9ydHVuaXR5IHRvIGdvIGZ1 cnRoZXIuIFBvbGljeQ0KaXMgb25seSBhcyBnb29kIGFzIHRoZSBkYXRhIGZlZWRpbmcgaXQsIGFu ZCB0aGVyZSBhcmUgcGxlbnR5IG9mIHdheXMgdG8NCmhhdmUgb3Zlcmx5IHBlcm1pc3NpdmUgcG9s aWN5IG9uY2UgaXQncyBjb25maWd1cmVkIC0gdGhpcyBkcmFmdCdzDQpzdWdnZXN0aW9uIGlzIG9u bHkgZ29pbmcgdG8gcHJvdGVjdCBhZ2FpbnN0ICJJIGZvcmdvdCB0byBhcHBseSBteSBwb2xpY3ki DQpub3QgIkkgcmVmdXNlIHRvIHB1dCBhbnkgZWZmb3J0IGludG8gd3JpdGluZyBwb2xpY3kiDQoN Cm1heCBwcmVmaXggaXMgb2Z0ZW4gdGhlIGZpcnN0IGNpcmN1aXQgYnJlYWtlciBiZWZvcmUgeW91 IGV2ZW4gZ2V0IHRvDQpwb2xpY3ksIGJ1dCBpdCdzIG5vdCBjb25zaXN0ZW50bHkgYXBwbGllZCBl aXRoZXIuIFRvIHRoYXQgZW5kLQ0KMSkgTWFrZSBtYXggcHJlZml4IGEgUkVRVUlSRUQgcGFyYW1l dGVyIG9uIGFuIGVCR1Agc2Vzc2lvbi4gKG9yIGRvIHRoaXMNCmltcGxpY2l0bHkgYnkgcmVjb21t ZW5kaW5nIHRoYXQgdGhlIGRlZmF1bHQgZm9yIGFuIGVCR1AgbmVpZ2hib3Igd2l0aG91dCBhDQpj b25maWd1cmVkIG1heCBwcmVmaXggYmUgYW4gb2JzY2VuZWx5IGxvdyBudW1iZXIgc3VjaCBhcyAy LCBvciA1MDAgb3INCnNvbWV0aGluZywgc28gdGhhdCBzbWFsbCBuZWlnaGJvcnMgc3RpbGwgZG9u J3QgaGF2ZSB0byBkbyBhbnl0aGluZyBidXQgYXJlDQpwcm90ZWN0ZWQuIFdhcm4gaW4gdGhlIGxv Z3MgaWYgdGhlIG1heCBpcyBjbG9zZSBqdXN0IGxpa2UgdG9kYXkuIFllcywNCnBlb3BsZSBjYW4g c3RpbGwgc2V0IGFuIGFyYml0cmFyaWx5IGhpZ2ggbWF4IHByZWZpeCBieSBkZWZhdWx0IHRvIGRl ZmVhdA0KdGhpcyBidXQgSSdtIGhvcGluZyB0aGF0IGF0IGxlYXN0IGluIHNvbWUgY2FzZXMgdGhl IHJpZ2h0IHRoaW5nIGhhcHBlbnMuDQoyKSBTaW5jZSBwYXJ0IG9mIHRoZSBwcm9ibGVtIHdpdGgg bWF4IHByZWZpeCBpcyB0aGF0IGl0IGNhbiBiZSBzZXQgZmFyIHRvbw0KaGlnaCB0byBiZSBlZmZl Y3RpdmUsIG9yIHNvbWVvbmUgaGFzIHRvIGJlIHN0YXJpbmcgYXQgdGhlIGxvZyB0byBzdGF5DQph aGVhZCBvZiBpdCBpZiBpdCBncmFkdWFsbHkgZ3Jvd3MsIGltcGxlbWVudCBhbiBvbi1ieS1kZWZh dWx0IHNsaWRpbmcNCndpbmRvdyAibWF4LXByZWZpeCBhdXRvIiB0aGF0IGxvb2tzIGF0IHRoZSBs YXN0IFggc2l6ZXMgb2YgdGhlIHJvdXRlDQphbm5vdW5jZW1lbnRzIGZyb20gYSBuZWlnaGJvciwg YW5kIHNldHMgYSBmbG9hdGluZyBtYXggcHJlZml4IGF0IGENCnVzZXItY29uZmlndXJhYmxlIGxp bWl0IGFib3ZlIGl0LiBCYXNpY2FsbHksIGl0J3Mgd2F0Y2hpbmcgZm9yIGEgc3VkZGVuDQppbmNy ZWFzZSBvZiByb3V0ZXMsIGNvdWxkIGJlIGFzIGxvdyBhcyAyNSUsIGNvdWxkIGJlIGFzIGhpZ2gg YXMgMTUwJSBvcg0KZXZlbiA1MDAlLCBkZXBlbmRpbmcgb24gdGhlIHNpemUgb2YgdGhlIG5laWdo Ym9yIGFuZCBob3cgaGFpci10cmlnZ2VyIHlvdQ0Kd2FudGVkIGl0IHRvIGJlLiBJdCBjb3VsZCBl dmVuIGhhdmUgYSBtb2RlIHdoZXJlIGl0IHNpbXBseSBkYW1wZW5zIHRob3NlDQpyb3V0ZXMgd2l0 aCBhIGhpZ2ggcGVuYWx0eSByYXRoZXIgdGhhbiB0ZWFyaW5nIGRvd24gdGhlIHNlc3Npb24gY29t cGxldGVseQ0KYXMgd2l0aCBhIG5vcm1hbCBtYXgtcHJlZml4IGxpbWl0IGV4Y2VlZGVkLiBXZSdy ZSBhbHJlYWR5IHNvcnQgb2YgZG9pbmcNCnRoaXMgZmxvYXRpbmcgbWF4IHByZWZpeCB3aGVuIHdl IHNldCBtYXggcHJlZml4IHRvIGEgY2FsY3VsYXRlZCBhbW91bnQNCmFib3ZlIGN1cnJlbnQgc3Rl YWR5IHN0YXRlLCBhbmQgdGhlbiBpbmNyZWFzaW5nIGl0IHdoZW4gaXQgd2FybnMgaW4gdGhlDQps b2cgdGhhdCBpdCdzIGdldHRpbmcgY2xvc2UgdG8gbWF4IHByZWZpeC4gVGhpcyBpcyB2ZXJ5IHRv cC1vZi1teS1oZWFkIGF0DQp0aGUgbW9tZW50LCBhbmQgd2UnZCBwcm9iYWJseSBuZWVkIGxvZ2lj IHRvIHByZXZlbnQgZmFsc2UgcG9zaXRpdmVzIHdoZXJlDQp5b3UgaGF2ZSBhbiBldmVudCB0aGF0 IHRyaWdnZXJzIGEgbGFyZ2Ugd2l0aGRyYXcgc28gdGhhdCB0aGUgcm91dGVzIGFyZQ0KbG93ZXIg dGhhbiB1c3VhbCwgYW5kIHRoZW4gc2hvcnRseSBhZnRlciB0aG9zZSByb3V0ZXMgYXJlIHJlc3Rv cmVkLA0KbG9va2luZyBsaWtlIGEgc3Bpa2UgaW4gcm91dGUgYW5ub3VuY2VtZW50cy4gTWlnaHQg bmVlZCB0byBkbyBpdCBhcyBhIDI0DQpob3VyIGhpZ2gtd2F0ZXItbWFyayBvciBzb21ldGhpbmcu DQoNClRoZSBzYW1lIHNsaWRpbmcgd2luZG93IGxpbWl0ZXIgY291bGQgYmUgYXBwbGllZCB0byBv dXRib3VuZCBlQkdQDQphbm5vdW5jZW1lbnRzIGFuZCBiZSB1c2VkIHRvIGFwcGx5IHBvbGljeSBs aWtlIG90aGVycyBoYXZlIHN1Z2dlc3RlZCBzdWNoDQphcyBOT0FDQ0VQVCBvciBOT0VYUE9SVC4N Cg0KVGhhbmtzLA0KDQpXZXMgR2VvcmdlDQoNCg0KDQpPbiA3LzIwLzE1LCAxMjo1OCBQTSwgIklk ciBvbiBiZWhhbGYgb2YgSmFyZWQgTWF1Y2giIDxpZHItYm91bmNlc0BpZXRmLm9yZw0Kb24gYmVo YWxmIG9mIGphcmVkQHB1Y2submV0aGVyLm5ldD4gd3JvdGU6DQoNCj5PbmUgb2YgdGhlIG1ham9y IGNoYWxsZW5nZXMgdGhhdCB3ZSBmYWNlIGFzIGEgbmV0d29yayBvcGVyYXRvciBpcyBzb21lIG9m DQo+dGhlIGxlZ2FjeSBwb3N0dXJlIGxlZnQgaW4gaW50ZXJuZXQgY29ubmVjdGVkIGRldmljZXMu ICBXZeKAmXZlIHNlZW4gdGhpcw0KPmhpc3RvcnkgcGxheSBvdXQgd2l0aCBtYW55IG90aGVyIHBy b3RvY29scyBhbmQgc2VydmljZXMsIHN1Y2ggYXMgZW5hYmxpbmcNCj5jaGFyZ2VuLCBlY2hvIGFu ZCBvdGhlciBzZXJ2aWNlcyBvbiBkZXZpY2VzLiAgSGF2aW5nIFNNVFAgb3BlbiByZWxheXMsDQo+ ZXRjLg0KPg0KPkl04oCZcyB0aW1lIHRvIGRvY3VtZW50IHRoZSBjaGFuZ2VzIGFuZCByZXF1aXJl IHRoZW0gYXMgcGFydCBvZiB0aGUNCj5zdGFuZGFyZCBiZWhhdmlvciBvZiBhbGwgQkdQIHNwZWFr aW5nIGRldmljZXMuDQo+DQo+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1hdWNo LWJncC1yZWplY3QNCj4NCj5JcyBhbiBhdHRlbXB0IHRvIGNhcHR1cmUgdGhlIGNoYW5nZSB0aGF0 IG1heSBiZSByZXF1aXJlZCBieSBzb21lDQo+aW1wbGVtZW50b3JzLg0KPg0KPkFscmVhZHkgSnVu aXBlciBhbmQgSU9TLVhSIGhhdmUgdGhpcyBkZWZhdWx0IGJlaGF2aW9yIG9mIG5vdCBzZW5kaW5n IGFueQ0KPnJvdXRlcyB1bmxlc3MgZXhwbGljaXQgcG9saWN5IGlzIGNvbmZpZ3VyZWQuIEl04oCZ cyBteSB1bmRlcnN0YW5kaW5nIHRoYXQNCj5pdOKAmXMgYWxzbyB0aGUgZGVmYXVsdCBpbiBCSVJE IGJ1dCBJIGhhdmUgbm90IHZhbGlkYXRlZCB0aGlzIG15c2VsZi4NCj4NCj5J4oCZbSBpbnRlcmVz dGVkIGluIGRpc2N1c3Npb24gYW5kIGZlZWRiYWNrIG9uIHRoaXMgZG9jdW1lbnQuDQo+DQo+LSBK YXJlZA0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ SWRyIG1haWxpbmcgbGlzdA0KPklkckBpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vaWRyDQoNCg0KVGhpcyBFLW1haWwgYW5kIGFueSBvZiBpdHMgYXR0YWNo bWVudHMgbWF5IGNvbnRhaW4gVGltZSBXYXJuZXIgQ2FibGUgcHJvcHJpZXRhcnkgaW5mb3JtYXRp b24sIHdoaWNoIGlzIHByaXZpbGVnZWQsIGNvbmZpZGVudGlhbCwgb3Igc3ViamVjdCB0byBjb3B5 cmlnaHQgYmVsb25naW5nIHRvIFRpbWUgV2FybmVyIENhYmxlLiBUaGlzIEUtbWFpbCBpcyBpbnRl bmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdo aWNoIGl0IGlzIGFkZHJlc3NlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVu dCBvZiB0aGlzIEUtbWFpbCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzc2Vt aW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBjb3B5aW5nLCBvciBhY3Rpb24gdGFrZW4gaW4gcmVsYXRp b24gdG8gdGhlIGNvbnRlbnRzIG9mIGFuZCBhdHRhY2htZW50cyB0byB0aGlzIEUtbWFpbCBpcyBz dHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBoYXZlIHJlY2Vp dmVkIHRoaXMgRS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRp YXRlbHkgYW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kIGFueSBjb3B5IG9m IHRoaXMgRS1tYWlsIGFuZCBhbnkgcHJpbnRvdXQuDQo= From nobody Sun Jul 26 13:43:57 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 899811A0078 for ; Sun, 26 Jul 2015 13:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.597 X-Spam-Level: **** X-Spam-Status: No, score=4.597 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, MANGLED_BODY=2.3, MANGLED_LIST=2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWs_zEG4AoZG for ; Sun, 26 Jul 2015 13:43:53 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0747.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::747]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13DE61A00BD for ; Sun, 26 Jul 2015 13:43:53 -0700 (PDT) Received: from AMSPR03MB599.eurprd03.prod.outlook.com (10.242.106.142) by HE1PR03MB1228.eurprd03.prod.outlook.com (10.163.174.154) with Microsoft SMTP Server (TLS) id 15.1.225.19; Sun, 26 Jul 2015 20:43:35 +0000 Received: from AMSPR03MB599.eurprd03.prod.outlook.com ([10.242.106.142]) by AMSPR03MB599.eurprd03.prod.outlook.com ([10.242.106.142]) with mapi id 15.01.0225.018; Sun, 26 Jul 2015 20:43:35 +0000 From: Cameron Gray To: "idr@ietf.org" Thread-Topic: draft-cgray-ietf-bgp-exceptions Thread-Index: AQHQx+O9+E3EewISdUWMFoyIzzpmWg== Date: Sun, 26 Jul 2015 20:43:35 +0000 Message-ID: <7D9A3D68-2FBC-4A3C-9BB5-66E531CD22D9@bangor.ac.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2102) authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2.127.88.100] x-microsoft-exchange-diagnostics: 1; HE1PR03MB1228; 5:BPc+46MBsAo67sE3cimwv9sbJ7E6ywGIOj0CZjcbMVCUW0iAT43fZWa7xGSosjaARYMnWYHD9Nq8RBzO6hDxOl5uJNvlabChrfkKPoJ0rHyqAFNFY6yRR4K5G72kwP/nyqtzAfGGmHsupEf32gPxsw==; 24:Uy26u7LFDM/m5yL+yXBe5zv2cogBTWC44FeNBVcRjBr05zxWDvRB7jTiqse0Jre0WriXS7etwQ4lCJ5XnxorIb8FYdu1/Jsjl50Rl2zH4nM=; 20:MC50Jj1fggATr+ROBEu99PvkdAfSsZ9gQV28N9MZdlyr/ZrHtu3cclfJlGSVxL27Rr2TyV+L3t33DSYFAviGQg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR03MB1228; he1pr03mb1228: X-MS-Exchange-Organization-RulesExecuted 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:HE1PR03MB1228; BCL:0; PCL:0; RULEID:; SRVR:HE1PR03MB1228; x-forefront-prvs: 064903DDDC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(252514010)(189998001)(50226001)(2351001)(229853001)(82746002)(5002640100001)(19580405001)(19580395003)(57306001)(77096005)(106116001)(2501003)(5001920100001)(40100003)(33656002)(5890100001)(122556002)(77156002)(50986999)(450100001)(66066001)(86362001)(62966003)(5001960100002)(2656002)(107886002)(87936001)(110136002)(92566002)(83716003)(2900100001)(46102003)(15975445007)(74482002)(102836002)(36756003)(230783001)(4001430100001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR03MB1228; H:AMSPR03MB599.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: bangor.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jul 2015 20:43:35.2275 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c6474c55-a923-4d2a-9bd4-ece37148dbb2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR03MB1228 Archived-At: Cc: Saad Mansoor Subject: [Idr] draft-cgray-ietf-bgp-exceptions 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 Jul 2015 20:43:55 -0000 My PhD work surrounds applying traditional graph theory to Internet Securit= y. One of the ideas so far, is the concept of Exceptions. A routing messa= ge designed to prevent traffic matching the NLRI information from reaching = the destination. Effectively, allowing the BGP infrastructure to be used a= s a collaborative, distributed packet filter. This could mean (after a suc= cessful deployment to a critical mass) the end of traditional packet based = attacks by stopping them at (or as close as reasonably possible) the source= . I have submitted a personal Internet Draft for adding such a capability to = BGP-4; https://tools.ietf.org/html/draft-cgray-ietf-bgpexceptions-00 taking all that I could reasonable foresee into account. I welcome all fee= dback and discussion on this draft. There is further work to be completed (by me) for a protocol to offload cal= culation of the Exceptions required to a general-purpose server as Clique D= etection and other graph solutions are NP-Hard. Additionally I will create= the prototype implementation, most likely using Quagga as a basis. Thank you all for your time and consideration. Cameron Gray Doctoral Student School of Computer Science Email: c.gray@bangor.ac.uk Bangor University, Bangor, Gwynedd, LL57 2DG, UK. Rhif Elusen Gofrestredig 1141565 - Registered Charity No. 1141565 Gall y neges e-bost hon, ac unrhyw atodiadau a anfonwyd gyda hi, gynnwys de= unydd cyfrinachol ac wedi eu bwriadu i'w defnyddio'n unig gan y sawl y caws= ant eu cyfeirio ato (atynt). Os ydych wedi derbyn y neges e-bost hon trwy g= amgymeriad, rhowch wybod i'r anfonwr ar unwaith a dilewch y neges. Os na fw= riadwyd anfon y neges atoch chi, rhaid i chi beidio a defnyddio, cadw neu d= datgelu unrhyw wybodaeth a gynhwysir ynddi. Mae unrhyw farn neu safbwynt yn= eiddo i'r sawl a'i hanfonodd yn unig ac nid yw o anghenraid yn cynrychioli= barn Prifysgol Bangor. Nid yw Prifysgol Bangor yn gwarantu bod y neges e-b= ost hon neu unrhyw atodiadau yn rhydd rhag firysau neu 100% yn ddiogel. Oni= bai fod hyn wedi ei ddatgan yn uniongyrchol yn nhestun yr e-bost, nid bwri= ad y neges e-bost hon yw ffurfio contract rhwymol - mae rhestr o lofnodwyr = awdurdodedig ar gael o Swyddfa Cyllid Prifysgol Bangor. This email and any attachments may contain confidential material and is sol= ely for the use of the intended recipient(s). If you have received this ema= il in error, please notify the sender immediately and delete this email. If= you are not the intended recipient(s), you must not use, retain or disclos= e any information contained in this email. Any views or opinions are solely= those of the sender and do not necessarily represent those of Bangor Unive= rsity. Bangor University does not guarantee that this email or any attachme= nts are free from viruses or 100% secure. Unless expressly stated in the bo= dy of the text of the email, this email is not intended to form a binding c= ontract - a list of authorised signatories is available from the Bangor Uni= versity Finance Office. From nobody Sun Jul 26 22:28: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 737F51A896F for ; Sun, 26 Jul 2015 22:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.297 X-Spam-Level: ** X-Spam-Status: No, score=2.297 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, MANGLED_BODY=2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lgJFrkEaV7SC for ; Sun, 26 Jul 2015 22:27:58 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0732.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::732]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD4AB1A8978 for ; Sun, 26 Jul 2015 22:27:57 -0700 (PDT) Received: from AMSPR03MB599.eurprd03.prod.outlook.com (10.242.106.142) by AMSPR03MB597.eurprd03.prod.outlook.com (10.242.106.11) with Microsoft SMTP Server (TLS) id 15.1.225.19; Mon, 27 Jul 2015 05:27:36 +0000 Received: from AMSPR03MB599.eurprd03.prod.outlook.com ([10.242.106.142]) by AMSPR03MB599.eurprd03.prod.outlook.com ([10.242.106.142]) with mapi id 15.01.0225.018; Mon, 27 Jul 2015 05:27:36 +0000 From: Cameron Gray To: "Mike Dubrovskiy (mdubrovs)" Thread-Topic: [Idr] draft-cgray-ietf-bgp-exceptions Thread-Index: AQHQyAp2wd520c9vvkyyd0OZ/VCmBZ3uycwA Date: Mon, 27 Jul 2015 05:27:36 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2102) authentication-results: cisco.com; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2.127.88.100] x-microsoft-exchange-diagnostics: 1; AMSPR03MB597; 5:hGYJOFGnONrT3P9+pd471KVQ8MS86dEAVe+Rj0l7dmkGjrwU9C2mA1B0O6iaA310fkr7LkS7MXjKOJ3Uw9608sRRePPZ1g0JQTJ6CQjmMSrsabCNBIdATj/PL5YOiElEabJR418FK8ztxhP4l+GrHQ==; 24:Is0+87/GvWDOySN4wui2wSPmOB8xg1m8NtEE6oluvsShwYxM3zdhMmCziuh5h5QK5eFUKEV98wpvUWldPlkaEA9PAU1QRoTyEirrQjhxYj0=; 20:WTBXIyz4SgdLs9iKDTydjMPeevIMxvGXHeMecGvZHaKvV/XrvoWDGzVAYNGpgRlOCuZQ1z9eT6X9hTpjGwClXw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR03MB597; amspr03mb597: X-MS-Exchange-Organization-RulesExecuted 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:AMSPR03MB597; BCL:0; PCL:0; RULEID:; SRVR:AMSPR03MB597; x-forefront-prvs: 0650714AAA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(57306001)(15975445007)(110136002)(102836002)(122556002)(50986999)(5002640100001)(189998001)(77156002)(33656002)(87936001)(82746002)(66066001)(83716003)(77096005)(230783001)(74482002)(62966003)(40100003)(2950100001)(5001960100002)(2656002)(2900100001)(50226001)(76176999)(46102003)(106116001)(5890100001)(19580405001)(19580395003)(86362001)(36756003)(92566002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:AMSPR03MB597; H:AMSPR03MB599.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: <9185C7358EF7A744AB4D79E33FC360C7@eurprd03.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: bangor.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jul 2015 05:27:36.4089 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c6474c55-a923-4d2a-9bd4-ece37148dbb2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR03MB597 Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] draft-cgray-ietf-bgp-exceptions 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 Jul 2015 05:28:00 -0000 > On 27 Jul 2015, at 02:20, Mike Dubrovskiy (mdubrovs) = wrote: > > Look at > https://tools.ietf.org/html/rfc5575 Mike, Thank you for replying. I am indeed aware of FlowSpec, however despite bei= ng put forward as a proposed standard in 2009 almost zero commercial provid= ers will offer it (at least in the UK/EU and nLayer/GTT removed support for= it August 2013). I was trying to propose something more lightweight that = could gain critical mass more quickly to gain its utility. My solution is closer to RTBH than anything else, but RTBH has no formal sp= ecification - all RFCs are informational (3882, 5635). Regards, Cameron Rhif Elusen Gofrestredig 1141565 - Registered Charity No. 1141565 Gall y neges e-bost hon, ac unrhyw atodiadau a anfonwyd gyda hi, gynnwys de= unydd cyfrinachol ac wedi eu bwriadu i'w defnyddio'n unig gan y sawl y caws= ant eu cyfeirio ato (atynt). Os ydych wedi derbyn y neges e-bost hon trwy g= amgymeriad, rhowch wybod i'r anfonwr ar unwaith a dilewch y neges. Os na fw= riadwyd anfon y neges atoch chi, rhaid i chi beidio a defnyddio, cadw neu d= datgelu unrhyw wybodaeth a gynhwysir ynddi. Mae unrhyw farn neu safbwynt yn= eiddo i'r sawl a'i hanfonodd yn unig ac nid yw o anghenraid yn cynrychioli= barn Prifysgol Bangor. Nid yw Prifysgol Bangor yn gwarantu bod y neges e-b= ost hon neu unrhyw atodiadau yn rhydd rhag firysau neu 100% yn ddiogel. Oni= bai fod hyn wedi ei ddatgan yn uniongyrchol yn nhestun yr e-bost, nid bwri= ad y neges e-bost hon yw ffurfio contract rhwymol - mae rhestr o lofnodwyr = awdurdodedig ar gael o Swyddfa Cyllid Prifysgol Bangor. This email and any attachments may contain confidential material and is sol= ely for the use of the intended recipient(s). If you have received this ema= il in error, please notify the sender immediately and delete this email. If= you are not the intended recipient(s), you must not use, retain or disclos= e any information contained in this email. Any views or opinions are solely= those of the sender and do not necessarily represent those of Bangor Unive= rsity. Bangor University does not guarantee that this email or any attachme= nts are free from viruses or 100% secure. Unless expressly stated in the bo= dy of the text of the email, this email is not intended to form a binding c= ontract - a list of authorised signatories is available from the Bangor Uni= versity Finance Office. From nobody Mon Jul 27 00:50: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 9106B1ACF55 for ; Mon, 27 Jul 2015 00:50:50 -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, MANGLED_BODY=2.3, MANGLED_LIST=2.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FfzxY6LGLufs for ; Mon, 27 Jul 2015 00:50:46 -0700 (PDT) Received: from out-1.mail.exa.net.uk (out-1.mail.exa.net.uk [82.219.4.129]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 173A01AD06A for ; Mon, 27 Jul 2015 00:50:45 -0700 (PDT) Received: from smtp-5.exa.net.uk (unknown [82.219.5.5]) by out-1.mail.exa.net.uk (ExaSMTPD) with ESMTP id 937D41C0061; Mon, 27 Jul 2015 08:50:43 +0100 (BST) Received: from smtp-5.exa.net.uk (localhost [127.0.0.1]) by smtp-5.exa.net.uk (ExaSMTPD) with ESMTP id 8070E40257; Mon, 27 Jul 2015 08:50:43 +0100 (BST) Received: from [192.168.1.234] (ABayonne-652-1-470-27.w86-221.abo.wanadoo.fr [86.221.127.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: thomas@mangin.com) by smtp-5.exa.net.uk (ExaSMTPD) with ESMTPSA; Mon, 27 Jul 2015 08:50:43 +0100 (BST) From: "Thomas Mangin" To: idr@ietf.org, "Saad Mansoor" Date: Mon, 27 Jul 2015 08:50:39 +0100 Message-ID: <125BB0B3-79F2-4863-872A-7B70E8204116@exa-networks.co.uk> In-Reply-To: <7D9A3D68-2FBC-4A3C-9BB5-66E531CD22D9@bangor.ac.uk> References: <7D9A3D68-2FBC-4A3C-9BB5-66E531CD22D9@bangor.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5107) X-Virus-Scanned: ClamAV using ClamSMTP Archived-At: Subject: Re: [Idr] draft-cgray-ietf-bgp-exceptions 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 Jul 2015 07:50:50 -0000 Hello Cameron, Small things : > This attribute is a single 6-bit unsigned value (0-127) .. This should read 7-bit or (0-63) I am not sure the encoding example is clear enough / right. Could you please also explain why this proposal is superior to the already widely deployed RTBH. https://tools.ietf.org/rfc/rfc3882.txt and https://tools.ietf.org/html/rfc5635 I fail to grasp the advantage of your solution. Thomas http://exa.net.uk/about/contact-us On 26 Jul 2015, at 21:43, Cameron Gray wrote: > My PhD work surrounds applying traditional graph theory to Internet > Security. One of the ideas so far, is the concept of Exceptions. A > routing message designed to prevent traffic matching the NLRI > information from reaching the destination. Effectively, allowing the > BGP infrastructure to be used as a collaborative, distributed packet > filter. This could mean (after a successful deployment to a critical > mass) the end of traditional packet based attacks by stopping them at > (or as close as reasonably possible) the source. > > I have submitted a personal Internet Draft for adding such a > capability to BGP-4; > https://tools.ietf.org/html/draft-cgray-ietf-bgpexceptions-00 > taking all that I could reasonable foresee into account. I welcome > all feedback and discussion on this draft. > > There is further work to be completed (by me) for a protocol to > offload calculation of the Exceptions required to a general-purpose > server as Clique Detection and other graph solutions are NP-Hard. > Additionally I will create the prototype implementation, most likely > using Quagga as a basis. > > Thank you all for your time and consideration. > > Cameron Gray > Doctoral Student > School of Computer Science > > Email: c.gray@bangor.ac.uk > > Bangor University, Bangor, Gwynedd, LL57 2DG, UK. > > > Rhif Elusen Gofrestredig 1141565 - Registered Charity No. 1141565 > > Gall y neges e-bost hon, ac unrhyw atodiadau a anfonwyd gyda hi, > gynnwys deunydd cyfrinachol ac wedi eu bwriadu i'w defnyddio'n unig > gan y sawl y cawsant eu cyfeirio ato (atynt). Os ydych wedi derbyn y > neges e-bost hon trwy gamgymeriad, rhowch wybod i'r anfonwr ar unwaith > a dilewch y neges. Os na fwriadwyd anfon y neges atoch chi, rhaid i > chi beidio a defnyddio, cadw neu ddatgelu unrhyw wybodaeth a gynhwysir > ynddi. Mae unrhyw farn neu safbwynt yn eiddo i'r sawl a'i hanfonodd yn > unig ac nid yw o anghenraid yn cynrychioli barn Prifysgol Bangor. Nid > yw Prifysgol Bangor yn gwarantu bod y neges e-bost hon neu unrhyw > atodiadau yn rhydd rhag firysau neu 100% yn ddiogel. Oni bai fod hyn > wedi ei ddatgan yn uniongyrchol yn nhestun yr e-bost, nid bwriad y > neges e-bost hon yw ffurfio contract rhwymol - mae rhestr o lofnodwyr > awdurdodedig ar gael o Swyddfa Cyllid Prifysgol Bangor. > > This email and any attachments may contain confidential material and > is solely for the use of the intended recipient(s). If you have > received this email in error, please notify the sender immediately and > delete this email. If you are not the intended recipient(s), you must > not use, retain or disclose any information contained in this email. > Any views or opinions are solely those of the sender and do not > necessarily represent those of Bangor University. Bangor University > does not guarantee that this email or any attachments are free from > viruses or 100% secure. Unless expressly stated in the body of the > text of the email, this email is not intended to form a binding > contract - a list of authorised signatories is available from the > Bangor University Finance Office. > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Mon Jul 27 01:06: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 D72E61AD0A5 for ; Mon, 27 Jul 2015 01:06:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.398 X-Spam-Level: X-Spam-Status: No, score=0.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_BODY=2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XGeQliJYku0k for ; Mon, 27 Jul 2015 01:06:34 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0776.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::776]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C383F1AD0A2 for ; Mon, 27 Jul 2015 01:06:33 -0700 (PDT) Received: from AMSPR03MB599.eurprd03.prod.outlook.com (10.242.106.142) by VI1PR03MB1229.eurprd03.prod.outlook.com (10.163.165.26) with Microsoft SMTP Server (TLS) id 15.1.225.19; Mon, 27 Jul 2015 08:06:14 +0000 Received: from AMSPR03MB599.eurprd03.prod.outlook.com ([10.242.106.142]) by AMSPR03MB599.eurprd03.prod.outlook.com ([10.242.106.142]) with mapi id 15.01.0225.018; Mon, 27 Jul 2015 08:06:14 +0000 From: Cameron Gray To: Thomas Mangin Thread-Topic: [Idr] draft-cgray-ietf-bgp-exceptions Thread-Index: AQHQx+O+/GFKufSTsUyndWukg8RNQ53u8hSAgAAEWYA= Date: Mon, 27 Jul 2015 08:06:14 +0000 Message-ID: References: <7D9A3D68-2FBC-4A3C-9BB5-66E531CD22D9@bangor.ac.uk> <125BB0B3-79F2-4863-872A-7B70E8204116@exa-networks.co.uk> In-Reply-To: <125BB0B3-79F2-4863-872A-7B70E8204116@exa-networks.co.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2102) authentication-results: exa-networks.co.uk; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [80.76.208.201] x-microsoft-exchange-diagnostics: 1; VI1PR03MB1229; 5:sqU31K50vtIDtkxotYAszaLYQygpBzAWDmtse31C9BAxRtTmyEVHqioKZPFoXurCtOrCs5hBam9TmbeJoVN29CiEir7fhtl/nWy05lnPHtZ4QAh+9q0jNqODh3wjTLz7gI9wPIKqtCgn/AGLQbBUKA==; 24:Do/rbNU2mxQuICtD2+41BUBP99V6GThBKmyR0mLNeQ0EmGsN4rwru5m6RAtKHbU5DsO9TGUIEDxDh7K90OiuZBniBToi/6tO28vM7XCS6xE=; 20:BuqPFIq+l+pFsf3+lYVn4/MaEw12J16majmXqLEB5YjzEGffF0YMki0qxjU7hAxutWXEXC6dadX5UmXpiSG66w== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR03MB1229; vi1pr03mb1229: X-MS-Exchange-Organization-RulesExecuted 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:VI1PR03MB1229; BCL:0; PCL:0; RULEID:; SRVR:VI1PR03MB1229; x-forefront-prvs: 0650714AAA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(561944003)(5001960100002)(50986999)(15975445007)(122556002)(86362001)(36756003)(46102003)(2656002)(5890100001)(2900100001)(87936001)(77096005)(102836002)(19580395003)(110136002)(2950100001)(82746002)(106116001)(5001920100001)(76176999)(50226001)(230783001)(74482002)(77156002)(33656002)(107886002)(19580405001)(62966003)(92566002)(66066001)(189998001)(40100003)(5002640100001)(83716003)(4001430100001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR03MB1229; H:AMSPR03MB599.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: bangor.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jul 2015 08:06:14.4938 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c6474c55-a923-4d2a-9bd4-ece37148dbb2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB1229 Archived-At: Cc: "idr@ietf.org" , Saad Mansoor Subject: Re: [Idr] draft-cgray-ietf-bgp-exceptions 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 Jul 2015 08:06:36 -0000 DQo+IE9uIDI3IEp1bCAyMDE1LCBhdCAwODo1MCwgVGhvbWFzIE1hbmdpbiA8dGhvbWFzLm1hbmdp bkBleGEtbmV0d29ya3MuY28udWs+IHdyb3RlOg0KPg0KPiBIZWxsbyBDYW1lcm9uLA0KPg0KPiBT bWFsbCB0aGluZ3MgOg0KPj4gVGhpcyBhdHRyaWJ1dGUgaXMgYSBzaW5nbGUgNi1iaXQgdW5zaWdu ZWQgdmFsdWUgKDAtMTI3KSAuLg0KPiBUaGlzIHNob3VsZCByZWFkIDctYml0IG9yICgwLTYzKQ0K DQpPb3BzLCBxdWl0ZSBjb3JyZWN0LiAgSSB3aWxsIGFtZW5kIHRoZSB0eXBvLg0KDQo+IEkgYW0g bm90IHN1cmUgdGhlIGVuY29kaW5nIGV4YW1wbGUgaXMgY2xlYXIgZW5vdWdoIC8gcmlnaHQuDQoN CkRvIHlvdSBoYXZlIGFueSBzdWdnZXN0aW9uIG9uIGhvdyB0byBtYWtlIGl0IGNsZWFyZXI/DQoN Cj4gQ291bGQgeW91IHBsZWFzZSBhbHNvIGV4cGxhaW4gd2h5IHRoaXMgcHJvcG9zYWwgaXMgc3Vw ZXJpb3IgdG8gdGhlIGFscmVhZHkgd2lkZWx5IGRlcGxveWVkIFJUQkguDQo+IGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvcmZjL3JmYzM4ODIudHh0IGFuZCBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvcmZjNTYzNQ0KPg0KPiBJIGZhaWwgdG8gZ3Jhc3AgdGhlIGFkdmFudGFnZSBvZiB5b3VyIHNv bHV0aW9uLg0KDQpSVEJIIGlzIChhdCBsZWFzdCB3aXRoIG15IHVwc3RyZWFtcyA8LUFTMjk1Mjcp IGhhbXBlcmVkIGJ5IHByZWZpeCBsZW5ndGggbGltaXRzIHJlcXVpcmluZyBhdCBsZWFzdCBhIHdp ZGVyIGJsb2NrIHRoYW4gaW50ZW5kZWQuICBJdCBhbHNvIGlzIHByZWRpY2F0ZWQgb24gcHNldWRv LXdlbGwta25vd24gY29tbXVuaXR5IHRhZ3MgYW5kIGZ1cnRoZXIgdXBzdHJlYW1zL3BlZXJzIHRy YW5zbGF0aW5nIHRoZW0gYXBwcm9wcmlhdGVseS4gIEkgaGF2ZSB5ZXQgdG8gYmUgcmVxdWVzdGVk IHRvIG9yIHJlcXVpcmUgb2YgbXkgcGVlcnMgdG8gYWRkIFJUQkggY29tbXVuaXR5IGhhbmRsaW5n IHdoaWNoIGF0IHRoZSB2ZXJ5IGxlYXN0IGNvdWxkIGJlIGEgbGVhayBwb2ludC4NCg0KUlRCSCBp cyBlZmZlY3RpdmVseSBlcXVpdmFsZW50IHRvIGEgbGVzcyBmb3JtYWxpc2VkIHZlcnNpb24gb2Yg dGhlIEdsb2JhbCBCbG9jayBvcGVyYXRpb24gbW9kZSBJIHByb3Bvc2UuICBUaGUgQUMgYW5kIEhU IG9wZXJhdGlvbiBtb2RlcyBvZmZlciBhIG1vcmUgdGFyZ2V0ZWQgc29sdXRpb24gdG8gb25seSBi bG9jayB0cmFmZmljIGF0IGdpdmVuIHBvaW50cyBhbmQgcmVkdWNpbmcgdGhlIG5lZWQgZm9yIHRh YmxlIGdyb3d0aCBldmVyeXdoZXJlIGVsc2UuICBBZGRpdGlvbmFsbHkgbXkgcHJvcG9zYWwgaGFz IGJ1aWx0IGluIHNlY3VyaXR5IHJlcXVpcmVtZW50cyBiZXlvbmQg4oCYZG8gdGhlIHJpZ2h0IHRo aW5n4oCZIG5vdGVkIGluIDM4ODIgYW5kIDU2MzUsIHJlcXVpcmluZyB0aGUgdXNlIG9mIFJQS0kg dG8gc2VjdXJlIHRoZSBhbm5vdW5jZW1lbnRzIGFnYWluc3QgZmFsc2UgYWR2ZXJ0aXNlbWVudHMu DQoNCknigJltIG1vcmUgdGhhbiBoYXBweSB0byBleHRlbmQgb3IgYW1lbmQgd2hlcmUgbmVjZXNz YXJ5IGJ1dCBJIGNhbiBzZWUgdGhlIG5lZWQgZm9yIHRyZWF0aW5nIHRoZXNlIGFzIGEgZm9ybSBv ZiBvdmVybGF5IG5ldHdvcmsgcmF0aGVyIHRoYW4ganVzdCBhbm90aGVyIGFubm91bmNlbWVudC4N Cg0KVGhhbmsgeW91IGZvciB0YWtpbmcgdGhlIHRpbWUgdG8gY29uc2lkZXIgdGhlIHByb3Bvc2Fs LCByZWdhcmRzLA0KDQpDYW1lcm9uDQoNCg0KUmhpZiBFbHVzZW4gR29mcmVzdHJlZGlnIDExNDE1 NjUgLSBSZWdpc3RlcmVkIENoYXJpdHkgTm8uIDExNDE1NjUNCg0KR2FsbCB5IG5lZ2VzIGUtYm9z dCBob24sIGFjIHVucmh5dyBhdG9kaWFkYXUgYSBhbmZvbnd5ZCBneWRhIGhpLCBneW5ud3lzIGRl dW55ZGQgY3lmcmluYWNob2wgYWMgd2VkaSBldSBid3JpYWR1IGkndyBkZWZueWRkaW8nbiB1bmln IGdhbiB5IHNhd2wgeSBjYXdzYW50IGV1IGN5ZmVpcmlvIGF0byAoYXR5bnQpLiBPcyB5ZHljaCB3 ZWRpIGRlcmJ5biB5IG5lZ2VzIGUtYm9zdCBob24gdHJ3eSBnYW1neW1lcmlhZCwgcmhvd2NoIHd5 Ym9kIGknciBhbmZvbndyIGFyIHVud2FpdGggYSBkaWxld2NoIHkgbmVnZXMuIE9zIG5hIGZ3cmlh ZHd5ZCBhbmZvbiB5IG5lZ2VzIGF0b2NoIGNoaSwgcmhhaWQgaSBjaGkgYmVpZGlvIGEgZGVmbnlk ZGlvLCBjYWR3IG5ldSBkZGF0Z2VsdSB1bnJoeXcgd3lib2RhZXRoIGEgZ3luaHd5c2lyIHluZGRp LiBNYWUgdW5yaHl3IGZhcm4gbmV1IHNhZmJ3eW50IHluIGVpZGRvIGknciBzYXdsIGEnaSBoYW5m b25vZGQgeW4gdW5pZyBhYyBuaWQgeXcgbyBhbmdoZW5yYWlkIHluIGN5bnJ5Y2hpb2xpIGJhcm4g UHJpZnlzZ29sIEJhbmdvci4gTmlkIHl3IFByaWZ5c2dvbCBCYW5nb3IgeW4gZ3dhcmFudHUgYm9k IHkgbmVnZXMgZS1ib3N0IGhvbiBuZXUgdW5yaHl3IGF0b2RpYWRhdSB5biByaHlkZCByaGFnIGZp cnlzYXUgbmV1IDEwMCUgeW4gZGRpb2dlbC4gT25pIGJhaSBmb2QgaHluIHdlZGkgZWkgZGRhdGdh biB5biB1bmlvbmd5cmNob2wgeW4gbmhlc3R1biB5ciBlLWJvc3QsIG5pZCBid3JpYWQgeSBuZWdl cyBlLWJvc3QgaG9uIHl3IGZmdXJmaW8gY29udHJhY3Qgcmh3eW1vbCAtIG1hZSByaGVzdHIgbyBs b2Zub2R3eXIgYXdkdXJkb2RlZGlnIGFyIGdhZWwgbyBTd3lkZGZhIEN5bGxpZCBQcmlmeXNnb2wg QmFuZ29yLg0KDQpUaGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29u ZmlkZW50aWFsIG1hdGVyaWFsIGFuZCBpcyBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGludGVu ZGVkIHJlY2lwaWVudChzKS4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJv ciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkZWxldGUgdGhpcyBl bWFpbC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKSwgeW91IG11c3Qg bm90IHVzZSwgcmV0YWluIG9yIGRpc2Nsb3NlIGFueSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4g dGhpcyBlbWFpbC4gQW55IHZpZXdzIG9yIG9waW5pb25zIGFyZSBzb2xlbHkgdGhvc2Ugb2YgdGhl IHNlbmRlciBhbmQgZG8gbm90IG5lY2Vzc2FyaWx5IHJlcHJlc2VudCB0aG9zZSBvZiBCYW5nb3Ig VW5pdmVyc2l0eS4gQmFuZ29yIFVuaXZlcnNpdHkgZG9lcyBub3QgZ3VhcmFudGVlIHRoYXQgdGhp cyBlbWFpbCBvciBhbnkgYXR0YWNobWVudHMgYXJlIGZyZWUgZnJvbSB2aXJ1c2VzIG9yIDEwMCUg c2VjdXJlLiBVbmxlc3MgZXhwcmVzc2x5IHN0YXRlZCBpbiB0aGUgYm9keSBvZiB0aGUgdGV4dCBv ZiB0aGUgZW1haWwsIHRoaXMgZW1haWwgaXMgbm90IGludGVuZGVkIHRvIGZvcm0gYSBiaW5kaW5n IGNvbnRyYWN0IC0gYSBsaXN0IG9mIGF1dGhvcmlzZWQgc2lnbmF0b3JpZXMgaXMgYXZhaWxhYmxl IGZyb20gdGhlIEJhbmdvciBVbml2ZXJzaXR5IEZpbmFuY2UgT2ZmaWNlLg0KDQo= From nobody Mon Jul 27 02:37: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 BC2001B2A45 for ; Mon, 27 Jul 2015 02:37:32 -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 rzzFw0yZRn6Q for ; Mon, 27 Jul 2015 02:37:31 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (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 7B3AF1B2A33 for ; Mon, 27 Jul 2015 02:37:31 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so103866500wib.0 for ; Mon, 27 Jul 2015 02:37:30 -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=AVATH6Tvj/LZZDKVdC2sJb8YrRGwrWAJANM484lpy7E=; b=fnFfWZ1Uvch4HRdfdj+XbDPOcnPpn/NKim8JzLxnU2PzC5/ky5D4p4DU8Btm3MKyFY 53u+6EoFW0AyKWM+IkwOlp+m6U3NyjPueDDjeNQzLNt3hD6hUH3ejpJuHNWNfhayOf1t U/b8jp7dPQp9ApscTcgUk+N20hFlxih7j7isMRfKQIgi3oo8V0xe0cOs/iuXKdTkBElF xLX2T1zQqZ9DShsWj8vpg6CWxEuQbqZfYoZT7YN5X46ftaUN4SezuyFRvFZZiDgn8FBt 5royFFTn7tH8nE7JVUgvarRhq4U5MdFZm1hno1m8o2K2nU2SEW2pMMAFkINhqooD1YIZ 4VnQ== MIME-Version: 1.0 X-Received: by 10.194.120.198 with SMTP id le6mr52596594wjb.133.1437989850264; Mon, 27 Jul 2015 02:37:30 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.194.95.168 with HTTP; Mon, 27 Jul 2015 02:37:30 -0700 (PDT) In-Reply-To: References: Date: Mon, 27 Jul 2015 11:37:30 +0200 X-Google-Sender-Auth: 8IvOj9f_zaIpLtxpi7JYFK8cRys Message-ID: From: Robert Raszuk To: Cameron Gray Content-Type: multipart/alternative; boundary=089e01160002373cef051bd81ae5 Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] draft-cgray-ietf-bgp-exceptions 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 Jul 2015 09:37:32 -0000 --089e01160002373cef051bd81ae5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =E2=80=8BCameron,=E2=80=8B > Thank you for replying. I am indeed aware of FlowSpec, however despite > being put forward as a proposed standard in 2009 almost zero commercial > providers will offer it (at least in the UK/EU and nLayer/GTT removed > support for it August 2013). I was trying to propose something more > lightweight that could gain critical mass more quickly to gain its utilit= y. > Have you =E2=80=8Bdone analysis and comparison of flowspec with your soluti= on to establish the base for the assertion that your solution is: a) "more lightweight" then RFC5575 b) will be deployed more quickly then RFC5575 c) is as secure as RFC5575 with automatic validation I would love to see such data. Likewise in fact it would be helpful to also compare your solution with RTBH. Best regards, Robert. --089e01160002373cef051bd81ae5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=E2=80=8BCameron,=E2=80=8B
=C2=A0
=
Thank you for replying.=C2=A0 I am indeed aw= are of FlowSpec, however despite being put forward as a proposed standard i= n 2009 almost zero commercial providers will offer it (at least in the UK/E= U and nLayer/GTT removed support for it August 2013).=C2=A0 I was trying to= propose something more lightweight that could gain critical mass more quic= kly to gain its utility.

Have you =E2=80=8Bdone analysis and comparison of flowspec with your s= olution to establish the base for the assertion that your solution is:

a) "more lightweight&= quot; then RFC5575=C2=A0

b) will be deployed more quickly then RFC5575
c) is as secure as RFC5575 with automatic valida= tion

I would love to= see such data.

Likewi= se in fact it would be helpful to also compare your solution with RTBH.

Best regards,
Robert.

--089e01160002373cef051bd81ae5-- From nobody Mon Jul 27 05:02: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 9D5381B2B59 for ; Mon, 27 Jul 2015 04:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 R7VCoY-k4OVz for ; Mon, 27 Jul 2015 04:53:31 -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 BFAB71B2C03 for ; Mon, 27 Jul 2015 04:53:31 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 855E7EE5B949A; Mon, 27 Jul 2015 11:53:27 +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 t6RBrTDw017732 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 Jul 2015 13:53:29 +0200 Received: from FR711WXCHMBA06.zeu.alcatel-lucent.com ([169.254.2.12]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Mon, 27 Jul 2015 13:53:29 +0200 From: "VAN DE VELDE, Gunter (Gunter)" To: Jeffrey Haas , "idr@ietf.org" Thread-Topic: Comments on draft-vandevelde-idr-ipv6-flowspec-imp Thread-Index: AQHQuoVDjsKZS9ZnKkGFoZY78MZ60Z3vUKkA Date: Mon, 27 Jul 2015 11:53:28 +0000 Message-ID: References: <20150709202554.GC13783@pfrc.org> In-Reply-To: <20150709202554.GC13783@pfrc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="utf-8" Content-ID: <04A590509B46984AA40C32C206690D37@exchange.lucent.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Mon, 27 Jul 2015 05:02:47 -0700 Cc: "draft-vandevelde-idr-ipv6-flowspec-imp@tools.ietf.org" Subject: Re: [Idr] Comments on draft-vandevelde-idr-ipv6-flowspec-imp 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 Jul 2015 11:53:33 -0000 SGkgSmVmZiwNCg0KVGhlIGltcGxlbWVudGF0aW9uIGRyYWZ0IHdoZW4gY3JlYXRlZCBvcmlnaW5h bGx5IHdhcyBmb2N1c3NlZCBhcm91bmQgZHJhZnQtaWV0Zi1pZHItZmxvdy1zcGVjLXY2LTA2IGlt cGxlbWVudGF0aW9uIGFuZCBjb21wYXRpYmlsaXR5IHRlc3RpbmcgdG8gYWlkIGluIHByb2dyZXNz IG9mIHRoaXMgcHJvcG9zZWQgc3RhbmRhcmQgdHJhY2sgZG9jdW1lbnQuIE1haW4gZ29hbCBpcyB0 byB0ZXN0IHRoYXQgdGhlIE5MUkkgZXhjaGFuZ2VkIHdvcmtzIGFuZCB0aGF0IHRoZSByb3V0ZXJz IGNhbiBzZWUgdGhlIGNvbnRlbnQgb2YgdGhlIGluZm9ybWF0aW9uIGV4Y2hhbmdlZC4NCg0KTXkg aWRlYSB3YXMgdGhhdCB3ZSBjb3VsZCBkbyBhIGFkZGl0aW9uYWwgZG9jdW1lbnQgZm9yIGRyYWZ0 LWlldGYtaWRyLWZsb3dzcGVjLXJlZGlyZWN0LXJ0LWJpcy0wNCBpZiB0aGF0IG1ha2VzIHNlbnNl IHRvIHByb2NlZWQ/ICh0aGF0IHdvdWxkIGxlYWQgdG8gb25lIHByb3Bvc2VkIHN0YW5kYXJkIGRv Y3VtZW50IHdpdGggaXRzIGltcGxlbWVudGF0aW9uIHJlcG9ydCBkb2N1bWVudCkNCg0KDQpCZSB3 ZWxsLA0KRy8NCg0KT24gMDkvMDcvMTUgMjI6MjUsICJKZWZmcmV5IEhhYXMiIDxqaGFhc0BwZnJj Lm9yZz4gd3JvdGU6DQoNCj5JIHdvdWxkIGxpa2UgdG8gZW5jb3VyYWdlIHRoZSBhdXRob3JzIHRv IGNsYXJpZnkgaW50ZXJvcCBwb2ludCBFMzoNCj4gICBvICBFMzogRXh0ZW5kZWQgQ29tbXVuaXR5 IC0gcmVkaXJlY3QNCj4NCj5JbiBwYXJ0aWN1bGFyLCB0aGlzIGlzIGJlY2F1c2UgcmVkaXJlY3Qg Y29tbXVuaXRpZXMgaGF2ZSBnb3R0ZW4gc29tZSByZWNlbnQNCj5zY3J1dGlueS4gIGRyYWZ0LWll dGYtaWRyLWZsb3ctc3BlYy12Ni0wNiBhZGRzIHN1cHBvcnQgZm9yIFJGQyA1NzAxIHdpdGggYSAN Cj5uZXcgcmVkaXJlY3QgY29tbXVuaXR5LiBkcmFmdC1pZXRmLWlkci1mbG93c3BlYy1yZWRpcmVj dC1ydC1iaXMtMDQsIHdoaWNoIGlzDQo+aW4gSUVURiBMYXN0IENhbGwsIGNsYXJpZmllcyBleGlz dGluZyByZWRpcmVjdCBiZWhhdmlvcnMuICBGaW5hbGx5LCB0aGUNCj5pbnRlcm9wIHJlcG9ydCBp dHNlbGYgc2VlbXMgdG8gaW5jbHVkZSBhIHJlZGlyZWN0IGV4YW1wbGUgdGhhdCBhcHBlYXJzIHRv IGJlDQo+YW4gaW5zdGFuY2Ugb2YgZHJhZnQtaWV0Zi1pZHItZmxvd3NwZWMtcmVkaXJlY3QtaXAt MDIuDQo+DQo+QXMgYW4gZWFybHkgZGF0YSBwb2ludCwgSnVuaXBlciBkb2VzIG5vdCBjdXJyZW50 bHkgc3VwcG9ydCBWUkZzIHVzaW5nDQo+SVB2Ni1zcGVjaWZpYyByb3V0ZS10YXJnZXRzLCBub3Ig dGhlIElQdjYtc3BlY2lmaWMgY29tbXVuaXR5IHJlZmVyZW5jZWQgaW4NCj50aGUgZmxvd3NwZWMt djYgZHJhZnQuDQo+DQo+LS0gSmVmZg0KPg0KPg0KPi0tLS0tIEZvcndhcmRlZCBtZXNzYWdlIGZy b20gSUVURiBTZWNyZXRhcmlhdCA8aWV0Zi1zZWNyZXRhcmlhdC1yZXBseUBpZXRmLm9yZz4gLS0t LS0NCj4NCj5EYXRlOiBUaHUsIDAyIEp1bCAyMDE1IDA4OjI1OjAxIC0wNzAwDQo+RnJvbTogSUVU RiBTZWNyZXRhcmlhdCA8aWV0Zi1zZWNyZXRhcmlhdC1yZXBseUBpZXRmLm9yZz4NCj5Ubzogamhh YXNAcGZyYy5vcmcNCj5TdWJqZWN0OiBQZXJzb25hbCBJRCBsaXN0IG9mIGpoYWFzQHBmcmMub3Jn IG5vdGlmaWNhdGlvbjogQ2hhbmdlcyBvbiBkcmFmdC12YW5kZXZlbGRlLWlkci1pcHY2LWZsb3dz cGVjLWltcA0KPg0KPg0KPkhlbGxvLA0KPg0KPlRoaXMgaXMgYSBub3RpZmljYXRpb24gZnJvbSB0 aGUgUGVyc29uYWwgSUQgbGlzdCBvZiBqaGFhc0BwZnJjLm9yZy4NCj4NCj5Eb2N1bWVudDogZHJh ZnQtdmFuZGV2ZWxkZS1pZHItaXB2Ni1mbG93c3BlYy1pbXAsDQo+aHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtdmFuZGV2ZWxkZS1pZHItaXB2Ni1mbG93c3BlYy1pbXANCj4N Cj5DaGFuZ2U6DQo+TmV3IHZlcnNpb24gYXZhaWxhYmxlOiAqZHJhZnQtdmFuZGV2ZWxkZS1pZHIt aXB2Ni1mbG93c3BlYy1pbXAtMDIudHh0Kg0KPg0KPkJlc3QgcmVnYXJkcywNCj4NCj4gICAgICAg IFRoZSBkYXRhdHJhY2tlciBkcmFmdCB0cmFja2luZyBzZXJ2aWNlDQo+ICAgICAgICAoZm9yIHRo ZSBJRVRGIFNlY3JldGFyaWF0KQ0KPg0KPi0tLS0tIEVuZCBmb3J3YXJkZWQgbWVzc2FnZSAtLS0t LQ0K From nobody Mon Jul 27 13:20: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 6C5631B3379; Mon, 27 Jul 2015 13:20:16 -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 gaQ0RmwLRNoo; Mon, 27 Jul 2015 13:20:14 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0118.outbound.protection.outlook.com [207.46.100.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE08C1B2C21; Mon, 27 Jul 2015 13:20:14 -0700 (PDT) Received: from BY2PR05MB029.namprd05.prod.outlook.com (10.242.34.139) by BY2PR05MB1926.namprd05.prod.outlook.com (10.163.32.140) with Microsoft SMTP Server (TLS) id 15.1.225.19; Mon, 27 Jul 2015 20:20:13 +0000 Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none; Received: from cbarth-sslvpn-nc.jnpr.net (66.129.241.14) by BY2PR05MB029.namprd05.prod.outlook.com (10.242.34.139) with Microsoft SMTP Server (TLS) id 15.1.219.17; Mon, 27 Jul 2015 20:20:13 +0000 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Jeff Haas In-Reply-To: Date: Mon, 27 Jul 2015 16:20:05 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <1CFCED74-91B4-4D48-BC4E-6803FD252248@juniper.net> References: To: Jeffrey Haas X-Mailer: Apple Mail (2.2102) X-Originating-IP: [66.129.241.14] X-ClientProxiedBy: CY1PR15CA0008.namprd15.prod.outlook.com (25.163.14.18) To BY2PR05MB029.namprd05.prod.outlook.com (10.242.34.139) X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB029; 2:aK3sX2GWZ+ivR0ar53mpKB0VqH2Tz3S6YXyaR3l8KS26YBKcR8frdris3a9FaoNJ; 3:bTUzmRg3a07ZX3fSZ8O0hOHPhK59Lkkg4fQ8x9ghr5lMwHrjATz3FU6b4bfx2v9+L7rcCDv+F5+DuRFaFZfLhNQAF1xygSjrhvSnYM2aDYL5oBbiBEDK7Fz9dZFLkFME9BaPgzqdqArBAiajDRxz1g==; 25:qNKsPnT0hAn+gHdhggoH+j5OX/zFwN1UtoBmYblKXk8KNyLH9nMf/GPMN/36txW93iRvQs4HuC/ry9ewBl4m9AYwGzxaYP7jBDS33oU6Ujd/CGZgnH9EJN1VV0MTAhEFKyU1rmSBABAOEIc4arlRW6bwZXNEiUXqkod+mVZxdvcmoAp8xEV6PEzD2ZwEHlAfS2K8bUpDNUenTbc21A7mnsHUw+bV6HF/W93p4GTNtTIctdTXb74Ert5kWcNGj6lRMe/piS1Q9VyNA1rdcAdw6g== X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BY2PR05MB029; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BY2PR05MB1926; X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB029; 20:pRjwQ4EHwdJECcks6D9OHjFc6U4sQkHqCDO23m4S+KNBHHNicc5QZZi68kah5YAIg/reziv1DcJMqqpa0X5nnitgUXKlT7usZD+FEnBmLY7BGgd3K7E2dqH/Me7TH8JaLjb6oSZdJcPsvDYONdaWMeqkIug4Tva8RMWWEz6adWoEudtNdJhdP4ZA88ZtJlaGzcFnUiNypdfVGSvVLXzKGeY/gCt0CiezWnXJEzltPphVUEaA8tECCTThTe2FO9tHhyAQkCHqv+iw2WpviyEA92VKumKllakvVuMmOwjYpTDdobgWgJOIhr0SryIlwqosOyo2RCxI2zi6846OQNlPY5T28t32O1UBNiNzJoZOLSkY0S0ptM2K+DiaC7X2pSkdwuFV+iuFBRai/gooCDCo6niXDW+1nynAvVPRU/P7V4kex9n8od55ysVCYt/306EhnXwyzVuoSz9EjhelE0yNBpA9LW2V7i47G9R+1r8wcdWQOYIPX3mTI40jzOyaUn8e; 4:+wbmIe+ek+Wr+Foazef1Ed4kAgasyW6V0g5Tbj065tPcmhJmCVupnWNmMIaHdKRFAJx75/EC4+eoDEVt8l5HBvE+Mfn0IoLbet5HSxfqNygMCj39L2JLrXYxBBssbihQNjWg08hJSDhqnfEuqEt/NW6OjvssKJhKR5yknPhDEWuzJBdGSmeFokPq2BYzKgZDJa6M12yau1MWXtyp4zYf7wtwBBFEEo+zcqbGjKDJpR8HR9Ef+o0xyVMwTGML9N6tgIiMohTj0uMuD2VJBhEfhgWFHB39A2Awy/MzTU/jSs4= BY2PR05MB029: X-MS-Exchange-Organization-RulesExecuted 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:BY2PR05MB029; BCL:0; PCL:0; RULEID:; SRVR:BY2PR05MB029; X-Forefront-PRVS: 0650714AAA X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(377454003)(479174004)(50226001)(33656002)(50466002)(86362001)(87976001)(110136002)(189998001)(5001960100002)(4001450100002)(6200100001)(66066001)(2950100001)(47776003)(77096005)(82746002)(42186005)(53416004)(92566002)(19580405001)(83716003)(62966003)(46102003)(77156002)(76176999)(122386002)(50986999)(40100003)(36756003)(230783001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR05MB029; H:cbarth-sslvpn-nc.jnpr.net; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB029; 23:0ZP5U5C4HsdMfLXoxfEyc+BOuNvgAIXNbbV5T0u3qpFZb1w6c7o/4kwpRG3vPxNUPdXH637QoIgkMPO+WZs9Jt8pgIUJzqLlO3gOv+sHbnaW9GyWyNdTnoR+WEIBkiosWJQ7iyGiXr+uW+viFJESwaKbZUltgN/f2XoTq0BkESLrwgAi4oaK8C0tg3I9Mn78qZFdZQFn84xEPxopEPGWaGJxqCnArCu0AKRewq+gt09T3/8M3pdO5/GVP8qjmzrKY2PuS8yDNXDrRDvWN/4R721dYYh0kepazgEKGatFhL/vHOexoqjaeVZGQbUirZSQLH+50+zki+qhT3tIhIOE+rgCk0uHwyob23ddUM/rI0k6ps0U83FCpI8sKVJHFsLORETT5guXVcfvv4NJdzmWEsqkU8fs/HzZcBWTZ2cedzAT44pOzSmj6GKKVZV24NZPi5xhQdfMeqMfHqqTY6WQE5roYP4NnoCjDGnOMK5aIxOvanbXnG7azUUvWNrWwSKeBqASC1i2q0QvVQ8rqGD7QSqGzKC1fCEE+p2C9EXLK17DcYDOo9VL2I9WvI5Kf+kL+Y7rfoqoWU318dOj38iXH4o1Hs8Okcty2lz8K1UDZWW8ogyLCzZlSMFTwYWJr/1TJYApJiyq9cc+RJmsVkgdZi08IFRwvPmFd7nDD+9vAfuT8YW8ogTZiUJTyLeS5h46fjf8dzWA2YrHWuKfhOmlSxKmcOuVQp8SFid6u3HrsqVsvgutvHCzyLk8d7D2C3DdKnkm9hlxfhNHu3JUPz9AuLPkQeBEGC2xjL9MLtv8nqVRoi4J1XC3zeoEtJ8AHGWvpSPPUFta4lFazsIRl3S07q4dWBHXcsjYzjoFOAc03K7VbfBlCN8vgLepw2RTOaky/JarjQzUzOnYZCOgraIJcw== X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB029; 5:Z63In4j1GPbp7sYOgCF6WvIKdj6etE41KjfEHrpRtf4mtd2O7YkZOa+xe6OOWGueqB5pLTIcy0ALWGhplQA8fpYnTb08EDHWDEAYCwp8aUl1kYzEVqsgEyVnkJ2x9aM3nwvd91V9biKVmbYn3F+DwA==; 24:PMXMoTiICRfot/gKTyprWCDX4FOMEKBLEbU1wW1azYRAn1BIxSiA93w+Ynt43hSuis1iJnQ8Pf4JaMGH8qzpuyprdLEMKcfdPay44FFb3RE=; 20:RJaHW6LWiA/Vdjyml1JkT6ENgwAgVf7b3I2P1VZu0oQYh27+Se2PzTauXzj98TDSuf/YUOgfBBT9iPKGp5FAgg== X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jul 2015 20:20:13.0898 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB029 X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB1926; 2:2MlhcYwVxAsrsIC5fdU2TtmEImO13bP8YhgKqLzcN3gw/HzP1JA4sL9RSy1DzwSBQk26aoGVdflcM2rk3YFREZqN4rsfWHy/tpmYV2kA3ndL/gAZ3/0T0WVNpTuRi1u//G8t/ooYtNSv0FmBxx+FAO2p2+pzhk4ANqM811f0nRs=; 3:5ZpZuBwoVr2pcU7DbbMGOZRBmtmDcAxWUhfl6CyDWokHyxZeXWrBINOpAXxdfNplloVsU37Le5l5E5n3dIWRmJRlP/n0guk4tmQ1V7mSri66s4pDS+z8FAivc5NopEPNuUkw1eTr2ASfyuNCUPUWgw==; 25:z3sfPM0CHu4FADq1WNa0P1OS+s1q92cj5wxpd8kUNGSnNyZsfProYI0Dm59hSCDIdgZjXCJjpgMtTTZFLBi9OjeB0MpIzgXmB5OXarA44EU41ZMAQTbUt9kBc41ftrHRiWzcGSaG2rj1RgERlsZT/CRhfEx7Jc1xFg9k0vGCxeeqesvvVQFSvvrvnSBv5dezit6YI94w4Ebh2ulDoUw6jVsfsHraRHzNyUdHZpwQC4WjtvqBQoaLC+985Neb2yM3ye7c4sdyRU/HTmAqlHEw5w==; 20:hsl+TJNXo5Pu4qodDSMR4UCn4WuHZzCOMvE2BN/1yGOnpYUsi86n4yEpa2Z/fUyuYW1D/IjPIbgFCovgwn4SHw==; 23:97cbr3Wc3o5ZcRfhP8EJAoa1FK7dJl/wKiW4dshbl89IJvB8IjelrW21ooYl/L7dwDSQwyXgDCg40lN9t82fcOHxs12BLbwceOFG0eh/Rbw4oPujyY4ixNUPYWwM0jPxtguddK0fFKUvcEi18c48QDk9DHNeQ561ohqnnVgBmyiNvtInbTZmZwpybFYQzbln03lpTaeNtosL/QhVPWcbUET8wZm6c8mi+qfJiPn6HZ61oygONRzZQqQSFMiod9rq BY2PR05MB1926: X-MS-Exchange-Organization-RulesExecuted X-OriginatorOrg: juniper.net Archived-At: Cc: "draft-ietf-idr-flowspec-redirect-rt-bis@tools.ietf.org" , "idr@ietf.org" , "idr-chairs@ietf.org" Subject: Re: [Idr] AD Review of draft-ietf-idr-flowspec-redirect-rt-bis 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 Jul 2015 20:20:16 -0000 > On Jul 9, 2015, at 2:49 PM, Jeff Haas wrote: >=20 >=20 >> On Jul 9, 2015, at 2:27 PM, Alvaro Retana (aretana) = wrote: >>=20 >> On 7/9/15, 2:18 PM, "Alvaro Retana (aretana)" = wrote: >>=20 >> Just read this draft, and I only have a small nit to talk about: In = section 2, please add a subsection for the "BGP Transitive Extended = Community Types=94 update. Right now the update text is in 2.1. >>=20 >> I actually have another nit: I don=92t see rfc5668 and rfc7153 as = normative for this draft and should be informational. Just a nit.. >=20 > I will push mildly for normative. Understanding of the encoding = formats in those documents is necessary context for the related encoding = in this document. >=20 >=20 Note that you didn't acknowledge this was okay. I will defer = publication of -05 a day to give you a chance to respond. -- Jeff From nobody Mon Jul 27 13:40: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 05CE41B33BA; Mon, 27 Jul 2015 13:40: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 3A5PYynRpl9Q; Mon, 27 Jul 2015 13:40:45 -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 DD05C1B33B8; Mon, 27 Jul 2015 13:40:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=558; q=dns/txt; s=iport; t=1438029644; x=1439239244; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=CCyih3cTLGL1WpqbY8zsORWQd2dLOvJ/4fnPDMOToH8=; b=Mucbl4HyiKSVHyvOvaX0CsqdEgEn9QI2JVBL45Xb6/iZ2193HK0EIC77 T4206E+etGlta9+VUtKJApnsi0+NP8U9hrHPWWZL/1vMLnMV8WyGoyIP5 NtUtVDdAgt7DDDCr6RSjuRo1vgaumXr+OpuP0ZRTHN//Pcvu2usc6U7hT Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A0BQAUlrZV/51dJa1bgxWBPQa8HodmCgKBRzoSAQEBAQEBAYEKhCQBAQR5EAIBCA44MiUCBA4FiC7RNgEBAQEBAQEBAQEBAQEBAQEBAQEZi06FBweELAEEjH2Eb4J9AYxAmSYmg31vgUiBBAEBAQ X-IronPort-AV: E=Sophos;i="5.15,557,1432598400"; d="scan'208";a="172846430" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-6.cisco.com with ESMTP; 27 Jul 2015 20:40:44 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t6RKeiqh013129 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 Jul 2015 20:40:44 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.225]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Mon, 27 Jul 2015 15:40:43 -0500 From: "Alvaro Retana (aretana)" To: Jeff Haas Thread-Topic: AD Review of draft-ietf-idr-flowspec-redirect-rt-bis Thread-Index: AQHQunOZfr+4VuOFo0WZcugScMbDup3ThcUAgBxYpsGAABZwgA== Date: Mon, 27 Jul 2015 20:40:43 +0000 Message-ID: References: <1CFCED74-91B4-4D48-BC4E-6803FD252248@juniper.net> In-Reply-To: <1CFCED74-91B4-4D48-BC4E-6803FD252248@juniper.net> 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: text/plain; charset="iso-8859-1" Content-ID: <194874A576960B4289ACA641EBDB1562@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "idr-chairs@ietf.org" , "draft-ietf-idr-flowspec-redirect-rt-bis@tools.ietf.org" , "idr@ietf.org" Subject: Re: [Idr] AD Review of draft-ietf-idr-flowspec-redirect-rt-bis 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 Jul 2015 20:40:46 -0000 That=B9s fine with me. Thanks! Alvaro. On 7/27/15, 4:20 PM, "Jeff Haas" wrote: >>>I actually have another nit: I don=B9t see rfc5668 and rfc7153 as >>>normative for this draft and should be informational. Just a nit.. >>I will push mildly for normative. Understanding of the encoding formats >>in those documents is necessary context for the related encoding in this >>document. > >Note that you didn't acknowledge this was okay. I will defer publication >of -05 a day to give you a chance to respond. > >-- Jeff From nobody Mon Jul 27 14:40: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 42B0E1B3258; Mon, 27 Jul 2015 14:40:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 9bxGlzjf-G55; Mon, 27 Jul 2015 14:40:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D67BA1B3266; Mon, 27 Jul 2015 14:40:49 -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.2.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150727214049.21703.43068.idtracker@ietfa.amsl.com> Date: Mon, 27 Jul 2015 14:40:49 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-flowspec-redirect-rt-bis-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 Jul 2015 21:40:52 -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-05.txt Pages : 7 Date : 2015-07-27 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: https://tools.ietf.org/html/draft-ietf-idr-flowspec-redirect-rt-bis-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-flowspec-redirect-rt-bis-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 Jul 27 14: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 5ACD81B326F; Mon, 27 Jul 2015 14:41:52 -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 iZnvUWubHvas; Mon, 27 Jul 2015 14:41:51 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 56BD11B3258; Mon, 27 Jul 2015 14:41:51 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id A7C821E378; Mon, 27 Jul 2015 17:44:01 -0400 (EDT) Date: Mon, 27 Jul 2015 17:44:01 -0400 From: Jeffrey Haas To: idr@ietf.org Message-ID: <20150727214401.GD16809@pfrc.org> References: <20150727214049.21703.43068.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150727214049.21703.43068.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: idr@ietf.org, i-d-announce@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-flowspec-redirect-rt-bis-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: Mon, 27 Jul 2015 21:41:52 -0000 This version addresses the remaining nit from Alvaro. No further feedback was supplied as part of IETF last call. -- Jeff On Mon, Jul 27, 2015 at 02:40:49PM -0700, 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-05.txt > Pages : 7 > Date : 2015-07-27 > > 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: > https://tools.ietf.org/html/draft-ietf-idr-flowspec-redirect-rt-bis-05 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-flowspec-redirect-rt-bis-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/ > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Mon Jul 27 19:38:02 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 AF0301A702C for ; Mon, 27 Jul 2015 19:38:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 c99y13c2Sq-4 for ; Mon, 27 Jul 2015 19:37:58 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55FEC1A7026 for ; Mon, 27 Jul 2015 19:37:58 -0700 (PDT) Received: from 172.18.9.243 (EHLO lhreml403-hub.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CPK91119; Mon, 27 Jul 2015 21:37:57 -0500 (CDT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 28 Jul 2015 03:37:56 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.10]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Tue, 28 Jul 2015 10:37:51 +0800 From: Haoweiguo To: "'idr wg list'" Thread-Topic: New Version Notification for draft-hao-idr-ls-trill-02.txt Thread-Index: AQHQyNjgVkOFLYk1uUeAV/tDBWiTPp3wKVj7 Date: Tue, 28 Jul 2015 02:37:51 +0000 Message-ID: References: <20150728015726.18488.57665.idtracker@ietfa.amsl.com> In-Reply-To: <20150728015726.18488.57665.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.23.94] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "Donald E. Eastlake" , Susan Hares Subject: Re: [Idr] New Version Notification for draft-hao-idr-ls-trill-02.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, 28 Jul 2015 02:38:00 -0000 Hi Folks, The draft was updated to make some futher clear descriptions. Your further = comments and suggestions are welcomed. Thanks, weiguo ________________________________________ From: internet-drafts@ietf.org [internet-drafts@ietf.org] Sent: Tuesday, July 28, 2015 9:57 To: Susan Hares; Haoweiguo; Donald E. Eastlake; Susan K. Hares; Donald E. E= astlake 3rd; Haoweiguo Subject: New Version Notification for draft-hao-idr-ls-trill-02.txt A new version of I-D, draft-hao-idr-ls-trill-02.txt has been successfully submitted by Weiguo Hao and posted to the IETF repository. Name: draft-hao-idr-ls-trill Revision: 02 Title: Distribution of TRILL Link-State using BGP Document date: 2015-07-28 Group: Individual Submission Pages: 12 URL: https://www.ietf.org/internet-drafts/draft-hao-idr-ls-trill= -02.txt Status: https://datatracker.ietf.org/doc/draft-hao-idr-ls-trill/ Htmlized: https://tools.ietf.org/html/draft-hao-idr-ls-trill-02 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-hao-idr-ls-trill-= 02 Abstract: This draft describes a TRILL link state and MAC address reachability information distribution mechanism using a BGP LS extension. External components such as an SDN Controller can use the information for topology visibility, troubleshooting, network automation, etc. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat= From nobody Tue Jul 28 09:09: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 E53BA1ACD7D; Tue, 28 Jul 2015 09:09:05 -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 ODh_yXSPeNlH; Tue, 28 Jul 2015 09:09:03 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0705.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::705]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83AC61ACD92; Tue, 28 Jul 2015 09:08:46 -0700 (PDT) Authentication-Results: tools.ietf.org; dkim=none (message not signed) header.d=none; Received: from [172.29.35.108] (66.129.241.14) by BN3PR0501MB1089.namprd05.prod.outlook.com (10.160.113.11) with Microsoft SMTP Server (TLS) id 15.1.225.19; Tue, 28 Jul 2015 16:08:24 +0000 To: , "idr@ietf.org" , BESS References: <02ce01d0b851$4ecec5a0$ec6c50e0$@ndzh.com> <2691CE0099834E4A9C5044EEC662BB9D571ADA7E@dfweml701-chm> <55A0273D.4020608@juniper.net> <2691CE0099834E4A9C5044EEC662BB9D571B77BF@dfweml701-chm> <001001d0c136$290061b0$7b012510$@ndzh.com> <10393_1437662753_55B0FE21_10393_2369_1_55B0FE1E.40600@orange.com> From: Eric C Rosen Message-ID: <55B7A8F2.1090901@juniper.net> Date: Tue, 28 Jul 2015 12:08:18 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <10393_1437662753_55B0FE21_10393_2369_1_55B0FE1E.40600@orange.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.14] X-ClientProxiedBy: SN1PR16CA0025.namprd16.prod.outlook.com (25.169.34.35) To BN3PR0501MB1089.namprd05.prod.outlook.com (25.160.113.11) X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1089; 2:r86OChnMWkoxRoOFW8iSh2x8xyKluZhnfOvXbk3PPjuONOpoNya+eWG4k2S+K0yOxi7lG08f3awVxUSrMXk0EbF4TGax6ikpMgdOPdsQjeGJHDOk8NximrDqAFeY/5BwDyp8cc4gbBkqnRqPwGb1MmMpuySpawxrAZOWzOhpfA0=; 3:UZcqkAqSJJj71Q7zTGoji9AwEBYs4kLL08QvQpvhxb8IZb6VyNXADmvb1wMAmlJ7H3sQr1wldj/98T0E1XJwbJw+xNnwri4ZODoeBzZLBM1hkTpdfmpJXAvrsS7hHS7yLhg6Dp10ljjycw26oIBMMw==; 25:K+55XlKTeJugjf1YfszUUdZchQ/hON2gT51odAsCL6XmSZRrL4gP+jqPXF2TCXrHMJFbNLJXrrXii/1O9oTwOuSthP3J5GxLOAKwrw+z9IScjBy3P7vOBB9k7rDVoLG0JIAY96rA8R+Ix0uangfQBYXOlcGzQukgcLHxvIU5XZWly+rfK5Ho+7X7zFwsTNcc63k/mfnps/mSLMJRyJX0F/GETkuc5UvQX+djQ06EvQZgDzIaQIF3rjwYgsBFGYPGwh2dya5APwbJnwYJZ9WSPw== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1089; X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1089; 20:rDahk5ReSiEVBcC7pJ7LGH/9JEMbF9TUkmDDMad/F/1zTxl3mAkKjygihVw9jO9qND5qmsaC1j9jXhOYqrff3rgzHsz34Dbnh8t8JhzplmnqxLQV7UmqW7YXLJJX9+5UX6vP7dbpUtcnzhlnDfPLRmN5aju1fEmCpZG6dgmPjXEoWXFUAcdvsrfjxCtCNLtCnu2/9HtqWVhs4ez4m+AdVPPV9HyRRoJCol8/7gjFYHGW4EKjPgJilKNijIqFtjKasPIxZAdr3UI92ThJTyVOh7RB7KoPpBoAz5V+gg7iTNw3swbaNld5t6GFHHeMwmLXjl1tGVtNYPnOFddtLEgeuuW30xksswT5C/ShcEStvr23G0eEiZy3moaus+i5yK/Pndl48QZZfgE0uWVpz6Vu0lVlnozAx2TYNmYEw3W71RQ0Bq4nMIVZfddNJKWTOLDbhXOlquYvOspUa/gJkhqlKYo6Qc2gvyfMTXVVtRIq2UWFlqu066UIDFroPOfGRRj7; 4:2lWIMxJ+Z17dL/vspRB/h4bu5pSvllk1IqOZRpc33Rju+XRp/t06Ht+v3UIenTbYnTRvI0HRGiRkomJA2OLHqsqBEmoHKzrobVk3UI4GUDPAvPQZmQ7Fsj+gcl/76tCEii3UNNSKWxB9nXcYAJwKweMhb0CVXlBnX8Z4hpZ1GQzMdMo7MabRiSVVdSWFXXVKBj/oBBNHiuGtSYpWle/UObHrQRYNDIqSRqbVFqY4wG3KwN2g53hNXw9fbLC0tpClmFfTwB7ivz6jWuaKnUaVvMGa+zLuCLevNRCM9006UJw= BN3PR0501MB1089: X-MS-Exchange-Organization-RulesExecuted 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:BN3PR0501MB1089; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1089; X-Forefront-PRVS: 06515DA04B X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(6009001)(51444003)(5423002)(66066001)(93886004)(33656002)(86362001)(59896002)(230783001)(5001960100002)(42186005)(83506001)(65806001)(80316001)(47776003)(46102003)(65956001)(92566002)(23746002)(77156002)(62966003)(2950100001)(50986999)(77096005)(64126003)(189998001)(65816999)(5001770100001)(2501003)(5001920100001)(87266999)(76176999)(4001350100001)(54356999)(36756003)(40100003)(122386002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1089; H:[172.29.35.108]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; BN3PR0501MB1089; 23:QXcGYnDG6+nnAxei/9te7Po5UyiwmDEjRNi?= =?Windows-1252?Q?rhQ77C77+vkFMg3+5lC1kQJ0ywaM8vA/RfKlVRn10tzrFhL1MDgjlyUI?= =?Windows-1252?Q?Gn0S2RzbPWHH8qVv/gSs2Kxa4Me5Wgwex6O8YAj+d1/EMhSHPsODGsLu?= =?Windows-1252?Q?asITQc+fxynUtPaXcwqvncGTxNWnn8VSOPB7KGxjJfNsXEdRWPl+6i5l?= =?Windows-1252?Q?JXHJmXivMUo4GZbkk6h3Lr5vHrecXYKB/BFiFajXK7254baiXS3O572B?= =?Windows-1252?Q?ez8SQvDtNR/mqa1NXUTeQH41+a6pJ38+zQ2c0zg6a5i79Blqoj24gTf9?= =?Windows-1252?Q?UsNV2IwelP69Gw5Ch0MVv2uXgFETqM+LLYkm02kbc2NuvyQ3lIZpFl/7?= =?Windows-1252?Q?jqU7b9bGKS851iT0RPMV5tp1T1sy0APfdWfg4+Hae5HeENVeYyu2EbmB?= =?Windows-1252?Q?/eLV4tN6DW/45ConPlcJDaQ8IFXxrnyrOJNpYXXUVIZ9vTvsPv9WeCxK?= =?Windows-1252?Q?of2jULdtE782RmQXoFJwgtApjn0pJVwfEH8W6aNYcC/UsMw8lmCQ4liR?= =?Windows-1252?Q?GFeyeHvAV7ZH38mlTkUSryqVBc8VIGgwIViohqjskvjIMt7QYEWd0+Kc?= =?Windows-1252?Q?7mDPgVKxuD5jWnf9ozmDpl0pjauUM6gCaobkaDMeMECgDj8kKm5UWenB?= =?Windows-1252?Q?z2wOjbzLDx2w1myPuKVV1IRlu/KQ+RMJ44fHRyFXMelWlys8Mcsihhv0?= =?Windows-1252?Q?r6GyPIki3xmGRSe0/lA+P0lLvsXaau2pS7//2cAfT0+TFJ4DQsgMpWnu?= =?Windows-1252?Q?MTSVle65UcP1JEbnPq5RMDbfv0QJPKpmceHPSch4xix/vRSeSCb3+GoZ?= =?Windows-1252?Q?LwIG/ZpYnQ0xZulxRaAIarmzb3lzLMd2qXtgh1kkgeEz2CNFxdHSnvjI?= =?Windows-1252?Q?H4wJZ0EAZjHc60kG2qFLuoXzzkR7kHHhCxrlV3A848QJYVrIDTUyk8Td?= =?Windows-1252?Q?ycqzrDfB+yoyOInvmW3RwjFwjaq51p/FjTofK3xugu/clXyn+mx7AexF?= =?Windows-1252?Q?N3V1qpSncz+KdHzlN7wQ/1LeTNZHi1AQeF8hX?= X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1089; 5:2Mu6afNfPhM9cnjX2x387eEs9UrOyuCniVj7ENXPwsK4s49r4BO8jR6s2bj6P/yRBqPCUrgjG0T0Rqs98UvH6nPnQmeXgTWZ3N3BBf4o2ZjhEjUI4i6qMEDAHFkSOW0fcw3i02xk3yciUKl+C4waLA==; 24:meF8G+IYjj58wvdcrN/DY5XxVOHx3d8pz/Fk8vd0fr/vl/ewgeNsShEG4SVBnADPpJEYVM4Mkxzh0w6JPUlP7cICN+gU27/g3Nzvmto7+Vo=; 20:cGxfx6HD/7WjMb0Un9LYUmGWOxDhwVGrIpxovwKLMPmDr93LbzxmWjmkF2qlUIQuEGgHgEYFKENVqnTTLLui0A== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jul 2015 16:08:24.5828 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1089 Archived-At: Cc: draft-ietf-bess-evpn-overlay@tools.ietf.org, draft-rosen-idr-tunnel-encaps@tools.ietf.org Subject: Re: [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00.txt (7/6 to 7/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, 28 Jul 2015 16:09:06 -0000 > * to allow multicast support in the context of RFC6514/6513, RFC7117, > and RFC7432 with a consistent way of advertising the encapsulations,I > think that draft-rosen-idr-tunnel-encaps-00 section 2.4 should also > consider as a "labelled address family" an AFI/SAFI that may be > associated to a PMSI Tunnel attribute, in which case the "embedded > label" is the Label in the PMSI Tunnel Attribute > > * consistently with the above, 1/5 and 25/8 should also be added as > authorized families in section 3 In the particular case where (a) the PMSI Tunnel attribute specifies "Ingress Replication", and (b) the PMSI Tunnel attribute carries an MPLS label, then I think it might well make sense to include a Tunnel Encapsulation attribute. This would allow one to use an MPLS-in-something-else encapsulation to do ingress replication. In other cases, I don't really know what it would mean to have both a PMSI Tunnel attribute and a Tunnel Encapsulation attribute on the same route. Suppose the PMSI Tunnel attribute specifies an mLDP-created P2MP LSP, and the Tunnel Encapsulation attribute specifies a VXLAN tunnel. What would that mean? Another issue is the following. In MVPN the transmitter specifies the tunnel type, but the Tunnel Encapsulation attribute is most useful in scenarios where the receiver needs to specify the tunnel type. (Ingress replication is an exception, since it requires both a multipoint tunnel and a set of unicast tunnels, as is discussed in draft-ietf-bess-ir. So in that particular case, it makes sense for the transmitter to specify the former and the receivers to specify the latter.) It's also worth noting that except for ingress replication, a label is specified in the PMSI Tunnel attribute only if traffic from multiple VPNs is going to share the same multicast tunnel; this is not really analogous to the label that is embedded in the case of SAFI 4 ("Labeled IP Unicast") or SAFI 128 ("Labeled VPN-IP unicast"). > > * draft-ietf-bess-evpn-overlay currently relies on the Tunnel Encap > Extended Community to advertise the use of MPLS-over-GRE or VXLAN or > NVGRE, and section 5.1.3 of that draft specifies that the VNI to use is > the value in the Label field of the route -- this is I believe /nearly/ > inline with draft-rosen-idr-tunnel-encaps, but the devil is in the > details: if I read correctly draft-rosen-idr-tunnel-encaps-01 Section > 7.2, the behavior consisting in using the embedded label as the VNI > requires advertising a BGP Tunnel Encap Attribute with an Embedded > Label Handling Sub-TLV with value 2, or not advertising a BGP Tunnel > Encap at all (nor using the Tunnel Encapsulation ExtendedCommunity which > is made semantically equivalent by section 6) --- it thus seems to me > that one of the two drafts needs something to allow proper compatibility Right now the Tunnel Encaps draft specifies that omitting the Embedded Label Handling Sub-TLV is equivalent to including an Embedded Label Handling Sub-TLV with value 1. The simplest fix would be to change this so that omitting the Sub-TLV is equivalent to including a Sub-TLV with value 2. Or would this introduce an incompatibility with some other EVPN draft? ;-) > > > With a lesser priority, I have a few other comments as well: > > * I think the intent of the MPLS codepoint 10 for tunnel type, as > defined in draft-ietf-bess-evpn-overlay, intends to indicate the ability > to receive plain MPLS in a context where other encaps are advertised (if > you advertise only one non-MPLS encap, it means you support this encap > but not MPLS) -- this I think would be nice to capture in > draft-rosen-idr-tunnel-encaps I think that makes sense. > > * about the Remote Endpoint sub-TLV: why allow that an AF of 0 means > "use next-hop address", but still require the presence of the TLV ? it > seems that its absence could conveniently be interpreted as "use > next-hop address", like what's done for the Tunnel Encap EC in section 6 Some folks have expressed the opinion that the BGP procedures for handling errors in this attribute will be simplified if the Remote Endpoint Sub-TLV is always required to be present. I don't have a strong opinion about that myself. > > * section 6 should say that, associated to a labelled address family, > the Tunnel Encap EC of value GRE (2) means the same as MPLS-in-GRE > (value 11) (like section 2.2.5 does for the attribute) Makes sense. > > And my second head, the one trying to fill my BESS co-chair hat, can't > help adding that addressing some of the above will require keeping the > BESS working group involved all along the life of this draft. No problem. From nobody Tue Jul 28 09:35:37 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 4E1C41ACE3A; Tue, 28 Jul 2015 09:35: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, 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 mOxwthaEorG0; Tue, 28 Jul 2015 09:35:35 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0144.outbound.protection.outlook.com [207.46.100.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 A8CD31ACE37; Tue, 28 Jul 2015 09:35:35 -0700 (PDT) Authentication-Results: tools.ietf.org; dkim=none (message not signed) header.d=none; Received: from [172.29.35.108] (66.129.241.14) by BN3PR0501MB1089.namprd05.prod.outlook.com (10.160.113.11) with Microsoft SMTP Server (TLS) id 15.1.225.19; Tue, 28 Jul 2015 16:35:32 +0000 To: Xuxiaohu , "thomas.morin@orange.com" , "idr@ietf.org" , BESS References: <02ce01d0b851$4ecec5a0$ec6c50e0$@ndzh.com> <2691CE0099834E4A9C5044EEC662BB9D571ADA7E@dfweml701-chm> <55A0273D.4020608@juniper.net> <2691CE0099834E4A9C5044EEC662BB9D571B77BF@dfweml701-chm> <001001d0c136$290061b0$7b012510$@ndzh.com> <10393_1437662753_55B0FE21_10393_2369_1_55B0FE1E.40600@orange.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB01880@NKGEML512-MBS.china.huawei.com> From: Eric C Rosen Message-ID: <55B7AF51.4040900@juniper.net> Date: Tue, 28 Jul 2015 12:35:29 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB01880@NKGEML512-MBS.china.huawei.com> Content-Type: text/plain; charset="gbk"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.14] X-ClientProxiedBy: SN1PR0501CA0009.namprd05.prod.outlook.com (25.163.126.147) To BN3PR0501MB1089.namprd05.prod.outlook.com (25.160.113.11) X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1089; 2:cl/JUIjRYYhhEZuYVNWBs/dc9LFIPwIGDJ2hd13p5O2Qfs/6WopAADKXWtuCTPjTXfZm8mEs6pIoOZw5u40IXvCmiZVO06Zr0zaaqQxRB6Y46U0aZ2AddsK0eeRfMPXdZ/5GGzTdd51XXvZRWFhlfw28fwnNCE2N+zW+4HG1SgI=; 3:hq1MM78hY7XmkAbF+bHISmgTe8J6JAEfizQ0K+UlSjCJyRjU24NA0MzSJ2aL2YXwZMUOm5RwVTtf3Xd1h7Z8RHgFrsPFfQ2jpFsrYWLdEKYXRDReQzMyrl4uim6UCA1MhDcyCDLkQUqOPgLQtPnSUQ==; 25:jn7xTYOo3SHzsUkK1bUYaUKaRHctS5dA39LYS17pKyHfUvj97xy31Ixyqe5Tleiu6idc4+jufK+SIRxwvKNNk3kLOUmzXN8NSzXLjfcwORYBaN30GW++SIAswOUl94QHN98bCjGzKaUDKKI1Bs5pblbKxVR/9zG+NnYqRcNprTfcBMtY63xq4yJgKd6N2T6mxF6G4rWkqgbsJdUigecPC1UcM2545OzTH2X2jt9c6GkJnHbRWOnZbOV1R/fYhSyL X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1089; X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1089; 20:TjR6jkrxXws5EBGGESfXNQj2Oh2GTRssr4SgF8uJEUSPx+gknOJQMMQ/W2QGb5LrrpU+UID/vhVRUHexKnM8WblN6E4jGXUnRUk9PHBTuzNCj3nWj7hvui4Ue/D7bpYq8qvnEV5+wmdu3kJEANBGHSDqGdLjAeCLSGZ+d0My6YLYx2VhjcF6NVn6EUDLugVyKbfNdLlWG1j8SMArulM6n1zN3XlYlkskV3lUfujdYBYK4Z4QkeUfE+/YU7meRuiFpNoDHNCcThfYnQJEs0XpJQ5wUvuw0g9iSqUFuuGlrEuaxLT/DIVaaIswF1vz+DFvi3d6VRz+6vYLh4DMY5vQD1SOAFVrcqcltlAt83fw3Zdb00sWHMV9Zcgv9NWetslhWp5+Zl1v+0fXX/nz44c7IGsGcY1sczZyGdMLfoyMLQCFfrgBl8fuUEDWL6C6bqnG8L3Qk1QOzNH4SU6ysmoQN6oAPywmaG0giOVTDvNcHDMvKWudzmCCxVSWJ50lkMg5; 4:P59deDcfG28hyGk3N3wzFMnc0WZBeTQSuP1Hg8+uzdX69lFDjV38VyNqMnfmFa41Dfrx1gcPNihKn867xzDFC3cYML1EjV2R16+1XnIKPyZp4nVPazogz50bKQrucDI0olQ4rrpgYJseqj1L4RWPYaeCUwfOnakcL2WDLmuO8PFtp05nHlsIhtF0ZQ32dFIWJOoiWBBcdYgy4u1Sp2/t0bK7sAvFbMJjNGqnKXnrtUA9fSmAMOTLdlgNUh6xSUw5l62wbSO7FFp0IHivNvK6KwUgkkFXS8+8iRDSUFnlJ/g= BN3PR0501MB1089: X-MS-Exchange-Organization-RulesExecuted 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:BN3PR0501MB1089; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1089; X-Forefront-PRVS: 06515DA04B X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(6049001)(377454003)(479174004)(24454002)(5423002)(66066001)(93886004)(33656002)(86362001)(59896002)(230783001)(5001960100002)(42186005)(83506001)(65806001)(80316001)(47776003)(46102003)(65956001)(2201001)(92566002)(77156002)(62966003)(2950100001)(23696002)(77096005)(50986999)(64126003)(189998001)(5890100001)(65816999)(5001770100001)(2501003)(5001920100001)(87266999)(76176999)(4001350100001)(54356999)(36756003)(40100003)(122386002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1089; H:[172.29.35.108]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?gb2312?B?MTtCTjNQUjA1MDFNQjEwODk7MjM6RmZodHVkNEdaM3ZISC9OM2Q0ZWN3RGw3?= =?gb2312?B?bExjTUFTYlVKaXdsMll6UEZLK0wrMXp3UkxkazR3RUFPRmFIUi9XSWZSWTZO?= =?gb2312?B?MVB5ME43T3k2RHB6NWxBcjRwcGZQN2RFaCtMc0dXYThZR1NSU1hvbTIwREJz?= =?gb2312?B?RTFGUWNoS3NHY1FmZmE4MW9SSXZwYXBmdXBEWnNTTkJwMjZIM25Xa3pmL1lT?= =?gb2312?B?RXRaejlpWWU4N3U2ZWtzYklvbk9UbnVhV1hXU3Fsc0RMRElqa1pleHZXem52?= =?gb2312?B?T0lXUEtQYnBXYUhvMG15RnhtM1RvOG5WWklTeFBBekVKb3lXalNyMWp6b0RP?= =?gb2312?B?TUJyZEFCTThKUjFQZjIwU3VIRnlhYi9kbzdzTHpzdW83SktHNjhUUGkrditx?= =?gb2312?B?VlZqaXhLdmRoY1dBUE11VkRwZlNDSG5uS1VGc2J1Uk5LZ2Z5TFk0UkRFMXVD?= =?gb2312?B?bjIzMGZUbUdPRzNXamZGSVFSRG8xU1Q1L2tNekdpbzdNZTRHT09SQzRFR1NF?= =?gb2312?B?V3VBeURKekhTWVhBUysrQWI3bmQxSmY5djlHajc0UVkvblpwM2N5b0VPdGFX?= =?gb2312?B?SkNxN2RpSjAxM1UvcG94TUxpdDRwTkxndncrQXJQK2ZzUi9wR0FvaUZucmRF?= =?gb2312?B?bHQ1NmpMVlpWUVc4azdSYm52c0IwejIxV3o0dTNUZzk2L0Z6dkhKVmdFYlZ6?= =?gb2312?B?Y08yYWhYdUNhdTVKZzRDVUdHK25ubnRBVW93aWJKenMrTlpEeDYxVm1KNkRw?= =?gb2312?B?Um5zVVVJdnFYUDNBS0F2ZGFLZXRkczBGeUthWCt0UHA4Y1pYNXczRmpjQWNT?= =?gb2312?B?eWR4WXkyWDRIemJ5Y0dhOEZlYjA0bmxROW9UR3RKNWQ5WStpd1pmME9XU2Jl?= =?gb2312?B?V3hucE9oMmJiTFRhdG40Y1RRL2UzWkZDbTVrYkJ4M01WTTRwTzRKczd5Rjdi?= =?gb2312?B?RU8wRG5IMTVzRHZOcUoyeTZTMGxQcmpDQXFGbUVJeWhkK21UMlJUaUJacXcy?= =?gb2312?B?U29pa3h4QTBrcks5MzdtREJVeE5mUWdTa1VLakRBcHFPSjE1cU50L0hFUmZY?= =?gb2312?B?NnBuSGd2eE45MkZVVFRyTXNwNysrZ0xHVnFjemU1K0NxR0tUNk1BaDBIYThS?= =?gb2312?B?aTBMY2wwV3hGVENYMTdRL1cxUzl2bTFsRjZTb0FJYW9WTTdMNHl6M2cwSHdu?= =?gb2312?B?WndGdXZtWFVJdndyUzBKODNQcGw4M2tOc3FDMzhqWUZBUWlsZzlnbFk2SGNV?= =?gb2312?B?djRYbkpOdkMzVWRxc2pqb1dINXRHZ1ZzMzZENXluNys4Vm0yMVdmaFAwcHNm?= =?gb2312?B?cCs3eTNtS1ZsbjlRVTQ1Skl6VkJoelJ4VXFZM21ESmZEQzc3aU1lVnZYdFBw?= =?gb2312?B?NloyTnFxdmRNb3ZFOHVGMlBVRW93USsxYmdhRFd1bEFBWjlXUGJQTVM0WTI4?= =?gb2312?B?TjFvYjNGYWlyKzdwUE9DRFBPV3Y3YUI1TzN0azNrVWpENDVsSmp3bzY3UXlN?= =?gb2312?B?eS8rYXRBPT0=?= X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1089; 5:aRa55MI5iRaiSuiPwndOaq39lRq0RtsaAsVjoKW/m9qavZt2nrfs5/wnA0T7SsmEWUDjvJuMo48rEELvl8uM/4KMeKxDbDI3SuwfHlDn5n4pCLls7KaXDmLjzHzQA8ww+CfjddsLO5oS4Nu9T5zX2Q==; 24:JKVzyGm+eRe3cl+X4Mirn2IN2ZGYUXQbY+VFG4EJcFLvdMIXGhxCOFLC4Og/H4MObyeH+IofK8vyjQ88LCrgspuTm1Jm3yUwmLNIdWAMn5k=; 20:RybDbu4JFlm8iM3B1cOmoo58HXo1cTtNvY0yRshasVjx5NjbieAf5reRhVQ1i/Any3KhFyHzFy+xORoqfsSBqw== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jul 2015 16:35:32.5420 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1089 Archived-At: Cc: "draft-ietf-bess-evpn-overlay@tools.ietf.org" , "draft-rosen-idr-tunnel-encaps@tools.ietf.org" Subject: Re: [Idr] [bess] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00.txt (7/6 to 7/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, 28 Jul 2015 16:35:37 -0000 On 7/24/2015 4:40 AM, Xuxiaohu wrote: > Now it seems that the above rationale has been shaken by this draft. > The argument in favor of the Encapsulation-SAFI doesn't seem to have been as persuasive to everyone else as it was to the authors of RFC 5512 ;-) > Futhermore, since it allows to attach BGP Encap attributes to routes > now, the BGP encapsulation extended community can now be safely > replaced by BGP Encap attribute. Therefore, I wonder whether RFC5512 > would be obsoleted by this draft in the end. Quite a few people have suggested that RFC5512 should be obsoleted by the tunnel encaps draft; this is worth considering. However, I think we need to maintain compatibility with the parts of RFC5512 that have actually been implemented, such as the encapsulation EC. > Since BGP encapsulation attributes are now attached to routes, the > AFI/SAFI of the NLRI is already capable of indicating the payload > type of the advertised tunnel protocol. I don't think the payload type can necessarily be inferred from the AFI/SAFI of the UPDATE that is carrying the Tunnel Encapsulation attribute. Consider, for instance, a case where the next hop is not of the same address family as the NLRI, but the route to the next hop is the route carrying the Tunnel Encapsulation attribute. > it seems unnecessary to allocate two additional type codes for > MPLS-in-UDP and IP-in-UDP. I think I could argue this point either way: - On the one hand ... When you are about to sending a particular payload packet through a tunnel, you know whether the packet is MPLS or IP, so you know enough to form the encapsulation correctly. - On the other hand ... if you want the control plane to form the rewrite string in advance, you might want to form a different rewrite string for MPLS-in-GRE than for IP-in-GRE. I would be good if we had some general rules for when it is good to define a new tunnel type and when it is good to reuse an existing tunnel type. Of course, we still need to maintain compatibility with the tunnel types that are already defined. From nobody Tue Jul 28 20:01: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 06FB01A21C3; Tue, 28 Jul 2015 20:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 hJZ70keZj2n0; Tue, 28 Jul 2015 20:01:17 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF9101A6FF6; Tue, 28 Jul 2015 20:01:12 -0700 (PDT) Received: from 172.18.9.243 (EHLO lhreml401-hub.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGQ43469; Tue, 28 Jul 2015 22:01:11 -0500 (CDT) Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 29 Jul 2015 04:00:04 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.210]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Wed, 29 Jul 2015 11:00:00 +0800 From: Xuxiaohu To: Eric C Rosen , "thomas.morin@orange.com" , "idr@ietf.org" , BESS Thread-Topic: [Idr] [bess] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00.txt (7/6 to 7/20/2015) Thread-Index: AQHQyVN4eBT2e60pOEms8vmRfzXbLp3xv0Jg Date: Wed, 29 Jul 2015 02:59:59 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB02833@NKGEML512-MBS.china.huawei.com> References: <02ce01d0b851$4ecec5a0$ec6c50e0$@ndzh.com> <2691CE0099834E4A9C5044EEC662BB9D571ADA7E@dfweml701-chm> <55A0273D.4020608@juniper.net> <2691CE0099834E4A9C5044EEC662BB9D571B77BF@dfweml701-chm> <001001d0c136$290061b0$7b012510$@ndzh.com> <10393_1437662753_55B0FE21_10393_2369_1_55B0FE1E.40600@orange.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB01880@NKGEML512-MBS.china.huawei.com> <55B7AF51.4040900@juniper.net> In-Reply-To: <55B7AF51.4040900@juniper.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "draft-ietf-bess-evpn-overlay@tools.ietf.org" , "draft-rosen-idr-tunnel-encaps@tools.ietf.org" Subject: Re: [Idr] [bess] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00.txt (7/6 to 7/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: Wed, 29 Jul 2015 03:01:19 -0000 Hi Eric, > -----Original Message----- > From: Eric C Rosen [mailto:erosen@juniper.net] > Sent: Wednesday, July 29, 2015 12:35 AM > To: Xuxiaohu; thomas.morin@orange.com; idr@ietf.org; BESS > Cc: erosen@juniper.net; draft-ietf-bess-evpn-overlay@tools.ietf.org; > draft-rosen-idr-tunnel-encaps@tools.ietf.org > Subject: Re: [Idr] [bess] 2 week adoption call for > draft-rosen-idr-tunnel-enaps-00.txt (7/6 to 7/20/2015) >=20 > On 7/24/2015 4:40 AM, Xuxiaohu wrote: > > Now it seems that the above rationale has been shaken by this draft. > > > The argument in favor of the Encapsulation-SAFI doesn't seem to have been= as > persuasive to everyone else as it was to the authors of RFC 5512 ;-) >=20 > > Futhermore, since it allows to attach BGP Encap attributes to routes > > now, the BGP encapsulation extended community can now be safely > > replaced by BGP Encap attribute. Therefore, I wonder whether RFC5512 > > would be obsoleted by this draft in the end. >=20 > Quite a few people have suggested that RFC5512 should be obsoleted by the > tunnel encaps draft; this is worth considering. >=20 > However, I think we need to maintain compatibility with the parts of > RFC5512 that have actually been implemented, such as the encapsulation EC= . >=20 > > Since BGP encapsulation attributes are now attached to routes, the > > AFI/SAFI of the NLRI is already capable of indicating the payload type > > of the advertised tunnel protocol. >=20 > I don't think the payload type can necessarily be inferred from the AFI/S= AFI of > the UPDATE that is carrying the Tunnel Encapsulation attribute. Consider= , for > instance, a case where the next hop is not of the same address family as = the NLRI, > but the route to the next hop is the route carrying the Tunnel Encapsulat= ion > attribute. It seems that the example that you had mentioned is the usage of the Tunnel= Encapsulation attribute e as described in RFC5512, rather than the usage o= f the Tunnel Encapsulation attribute as proposed by this draft:) > > it seems unnecessary to allocate two additional type codes for > > MPLS-in-UDP and IP-in-UDP. >=20 > I think I could argue this point either way: >=20 > - On the one hand ... When you are about to sending a particular payload = packet > through a tunnel, you know whether the packet is MPLS or IP, so you know > enough to form the encapsulation correctly. >=20 > - On the other hand ... if you want the control plane to form the rewrite= string in > advance, you might want to form a different rewrite string for MPLS-in-GR= E > than for IP-in-GRE. If the Tunnel Encapsulation attribute associated with a labeled unicast rou= te indicates UDP tunnels, should it be obvious that MPLS-in-UDP is supporte= d by the originator of that labeled unicast route? Similarly, If the Tunnel= Encapsulation attribute associated with a unlabeled IPvx unicast route ind= icates UDP tunnels, should it be obvious that IPvx-in-UDP is supported by t= he originator of that unlabeled unicast route? Best regards, Xiaohu > I would be good if we had some general rules for when it is good to defin= e a new > tunnel type and when it is good to reuse an existing tunnel type. Of cou= rse, we > still need to maintain compatibility with the tunnel types that are alrea= dy > defined. From elisa@dyinggiraffe.org Tue Jul 28 18:59: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 8068A1B3151 for ; Tue, 28 Jul 2015 18:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id roQTtnBAlzQd for ; Tue, 28 Jul 2015 18:58:59 -0700 (PDT) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) (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 B2AEC1B2CCF for ; Tue, 28 Jul 2015 18:58:58 -0700 (PDT) Received: by lbbqi7 with SMTP id qi7so86247075lbb.3 for ; Tue, 28 Jul 2015 18:58:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=h9plFiiz1vJCU0IX60uA5Mw+BshBueKpPWLPSctRpVU=; b=IPPq1WNBXjDW3vDY7Crj1nrH/2PtjvqV3Iu7dqhZw3AnrHQ9fPvzdTj/cSLqikCa5Q 6Xfm0VFYwzcHwrFIAIermzFsovi9ai+HIf87/v5LdCaU+vihoUdpwYp65aPTYK4Nz348 6pr3/M7F2FM674x0T34mKxqqxyJ2ZE+2sPMRj6K/hN2ylw2P4YX3U+vls14PQWrkBBbo LPfNxZAjr4nFgiuQ51lhCko2jWEo3jbuHcxrGcpMls9JqxbwVkzQ17v/9Or4F7Rsajw8 bfy1ch0LGSJnD828lN4PR2A0poIR52UA3Sz9swdU0W6CrvWrCWIq0Ih1Jkvtv3sbCpi0 BAoA== X-Gm-Message-State: ALoCoQmSzY7c4lKwPMSm7jr5yVBriz9fZQ7tGDzJ8v5ObBZQwMS8auiqsg2E+Atrl7FqwTaV0jJp MIME-Version: 1.0 X-Received: by 10.152.28.105 with SMTP id a9mr36624240lah.9.1438135136919; Tue, 28 Jul 2015 18:58:56 -0700 (PDT) Received: by 10.25.163.75 with HTTP; Tue, 28 Jul 2015 18:58:56 -0700 (PDT) In-Reply-To: <00ac01d0c28a$cf4cb2d0$6de61870$@ndzh.com> References: <007001d0c1e4$d68a8190$839f84b0$@ndzh.com> <55AC0227.5030202@inex.ie> <52BA2437-4D33-4D93-8DA1-8BE6390EE9DA@akamai.com> <00ac01d0c28a$cf4cb2d0$6de61870$@ndzh.com> Date: Wed, 29 Jul 2015 03:58:56 +0200 Message-ID: From: Elisa Jasinska To: Susan Hares Content-Type: multipart/alternative; boundary=089e0160a240f9ba96051bf9ed09 Archived-At: X-Mailman-Approved-At: Tue, 28 Jul 2015 23:58:51 -0700 Cc: "Bakker, Niels" , Nick Hilliard , draft-ietf-idr-ix-bgp-route-server@tools.ietf.org, robert@raszuk.net, idr wg list Subject: Re: [Idr] 2 week adoption call for draft-jasinska-ix-bgp-route-server-implementation (7/19 to 8/2) 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 Jul 2015 02:00:26 -0000 --089e0160a240f9ba96051bf9ed09 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable And back from vacation I also confirm that I am not aware of any IPR concerning this draft or its contents. Thanks! Elisa On Mon, Jul 20, 2015 at 3:24 AM, Susan Hares wrote: > Niels, Nick, Elisa, and Robert: > > want to thank each of your for providing the IPR statements so quickly. > > Sue > > -----Original Message----- > From: Bakker, Niels [mailto:nbakker@akamai.com] > Sent: Sunday, July 19, 2015 4:37 PM > To: Nick Hilliard > Cc: Susan Hares; idr wg list; > draft-ietf-idr-ix-bgp-route-server@tools.ietf.org; elisa@bigwaveit.org; > robert@raszuk.net > Subject: Re: 2 week adoption call for > draft-jasinska-ix-bgp-route-server-implementation (7/19 to 8/2) > > > On 19 jul. 2015, at 22:02, Nick Hilliard wrote: > > > >> On 19/07/2015 06:36, Susan Hares wrote: > >> The authors of the base draft (draft-ietf-idr-ix-bgp-route-server-07) > >> and the author of the implementation report are requested to indicate > >> whether they know of any IPR for this draft. > > > > I'm not aware of any IPR concerning this draft or its contents. > > Likewise. > > Regards, > Niels > > --=20 Elisa Jasi=C5=84ska BigWave IT t: +48 880 859 988 e: elisa@bigwaveit.org --089e0160a240f9ba96051bf9ed09 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
And back from vacation I also confirm that=C2=A0I am not aware of any IPR concerning this draft or its= contents.

= Thanks!
Elisa=C2=A0

On Mon, Jul 20, 2015 at 3:24 AM, Susan Hares <share= s@ndzh.com> wrote:
Niels, N= ick, Elisa, and Robert:

=C2=A0want to thank each of your for providing the IPR statements so quickl= y.

Sue

-----Original Message-----
From: Bakker, Niels [mailto:nbakker@a= kamai.com]
Sent: Sunday, July 19, 2015 4:37 PM
To: Nick Hilliard
Cc: Susan Hares; idr wg list;
draft-= ietf-idr-ix-bgp-route-server@tools.ietf.org; elisa@bigwaveit.org;
robert@raszuk.net
Subject: Re: 2 week adoption call for
draft-jasinska-ix-bgp-route-server-implementation (7/19 to 8/2)

> On 19 jul. 2015, at 22:02, Nick Hilliard <nick@inex.ie> wrote:
>
>> On 19/07/2015 06:36, Susan Hares wrote:
>> The authors of the base draft (draft-ietf-idr-ix-bgp-route-server-= 07)
>> and the author of the implementation report are requested to indic= ate
>> whether they know of any IPR for this draft.
>
> I'm not aware of any IPR concerning this draft or its contents.
Likewise.

Regards,
Niels




--
=
=
Elisa Jasi=C5=84ska=
BigWave IT

t:=C2=A0= +48 880 859 988
e:=C2=A0elisa@bigwaveit.org=C2=A0
--089e0160a240f9ba96051bf9ed09-- From nobody Wed Jul 29 02:44: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 4D31B1A0130; Wed, 29 Jul 2015 02:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=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 dzEAEUi5pIrL; Wed, 29 Jul 2015 02:44:28 -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 962E81A0126; Wed, 29 Jul 2015 02:44:27 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id E492922C8C1; Wed, 29 Jul 2015 11:44:25 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id B9C152380B3; Wed, 29 Jul 2015 11:44:25 +0200 (CEST) Received: from [10.193.71.165] (10.197.38.5) by PEXCVZYH01.corporate.adroot.infra.ftgroup (10.114.1.186) with Microsoft SMTP Server (TLS) id 14.3.248.2; Wed, 29 Jul 2015 11:44:25 +0200 To: Eric C Rosen , "idr@ietf.org" , BESS References: <02ce01d0b851$4ecec5a0$ec6c50e0$@ndzh.com> <2691CE0099834E4A9C5044EEC662BB9D571ADA7E@dfweml701-chm> <55A0273D.4020608@juniper.net> <2691CE0099834E4A9C5044EEC662BB9D571B77BF@dfweml701-chm> <001001d0c136$290061b0$7b012510$@ndzh.com> <10393_1437662753_55B0FE21_10393_2369_1_55B0FE1E.40600@orange.com> <55B7A8F2.1090901@juniper.net> From: Organization: Orange Message-ID: <9202_1438163065_55B8A079_9202_262_1_55B8A078.1000209@orange.com> Date: Wed, 29 Jul 2015 11:44:24 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <55B7A8F2.1090901@juniper.net> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.197.38.5] X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.7.16.85415 Archived-At: Cc: draft-ietf-bess-evpn-overlay@tools.ietf.org, draft-rosen-idr-tunnel-encaps@tools.ietf.org Subject: Re: [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00.txt (7/6 to 7/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: Wed, 29 Jul 2015 09:44:30 -0000 Hi Eric, 2015-07-28, Eric C Rosen: >> * to allow multicast support in the context of RFC6514/6513, >> RFC7117, and RFC7432 with a consistent way of advertising the >> encapsulations,I think that draft-rosen-idr-tunnel-encaps-00 >> section 2.4 should also consider as a "labelled address family" an >> AFI/SAFI that may be associated to a PMSI Tunnel attribute, in >> which case the "embedded label" is the Label in the PMSI Tunnel >> Attribute >> >> * consistently with the above, 1/5 and 25/8 should also be added >> as authorized families in section 3 > > In the particular case where (a) the PMSI Tunnel attribute specifies > "Ingress Replication", and (b) the PMSI Tunnel attribute carries an > MPLS label, then I think it might well make sense to include a > Tunnel Encapsulation attribute. This would allow one to use an > MPLS-in-something-else encapsulation to do ingress replication. Or even a payload-in-something-else, but yes, we agree: covering ingress replication with the BGP Tunnel Encap makes sense (and will actually be required by draft-ietf-bess-evpn-overlay). > In other cases, I don't really know what it would mean to have both > a PMSI Tunnel attribute and a Tunnel Encapsulation attribute on the > same route. Suppose the PMSI Tunnel attribute specifies an > mLDP-created P2MP LSP, and the Tunnel Encapsulation attribute > specifies a VXLAN tunnel. What would that mean? For sake of simplicity I omitted that aspect in my initial comment, but yes indeed, not everything does make sense. I think that in the case where the Tunnel Type is an IP Multicast tree *without* the PMSI Tunnel Attribute Label field being set, jointly advertising a BGP Tunnel Encap attribute could be defined, for the MPLS-in-UDP or VXLAN types, as meaning "I will send PMSI traffic as MPLS-in-UDP or VXLAN" (rather than the GRE default). > Another issue is the following. In MVPN the transmitter specifies > the tunnel type, but the Tunnel Encapsulation attribute is most > useful in scenarios where the receiver needs to specify the tunnel > type. (Ingress replication is an exception, since it requires both a > multipoint tunnel and a set of unicast tunnels, as is discussed in > draft-ietf-bess-ir. So in that particular case, it makes sense for > the transmitter to specify the former and the receivers to specify > the latter.) > > It's also worth noting that except for ingress replication, a label > is specified in the PMSI Tunnel attribute only if traffic from > multiple VPNs is going to share the same multicast tunnel; this is > not really analogous to the label that is embedded in the case of > SAFI 4 ("Labeled IP Unicast") or SAFI 128 ("Labeled VPN-IP > unicast"). A possibility would be to state that if Tunnel Type is an IP Multicast tree *with* the PMSI Tunnel Attribute Label field set, jointly advertising a BGP Tunnel Encap attribute could be used to allow MPLS-in-GRE (or UDP, or VXLAN) and hence allow carrying the multicast traffic of multiple VPNs in one IP multicast tree. These proposals would allow to give a meaningful semantic to the BGP Tunnel Encap attribute with mVPN or E-VPN PMSI routes, independently of any consideration on how relevant these encapsulations would be. >> * draft-ietf-bess-evpn-overlay currently relies on the Tunnel >> Encap Extended Community to advertise the use of MPLS-over-GRE or >> VXLAN or NVGRE, and section 5.1.3 of that draft specifies that the >> VNI to use is the value in the Label field of the route -- this is >> I believe /nearly/ inline with draft-rosen-idr-tunnel-encaps, but >> the devil is in the details: if I read correctly >> draft-rosen-idr-tunnel-encaps-01 Section 7.2, the behavior >> consisting in using the embedded label as the VNI requires >> advertising a BGP Tunnel Encap Attribute with an Embedded Label >> Handling Sub-TLV with value 2, or not advertising a BGP Tunnel >> Encap at all (nor using the Tunnel Encapsulation ExtendedCommunity >> which is made semantically equivalent by section 6) --- it thus >> seems to me that one of the two drafts needs something to allow >> proper compatibility > > Right now the Tunnel Encaps draft specifies that omitting the > Embedded Label Handling Sub-TLV is equivalent to including an > Embedded Label Handling Sub-TLV with value 1. The simplest fix would > be to change this so that omitting the Sub-TLV is equivalent to > including a Sub-TLV with value 2. I think this is a good idea. > Or would this introduce an incompatibility with some other EVPN > draft? ;-) None that I'm aware of. >> With a lesser priority, I have a few other comments as well: >> >> * I think the intent of the MPLS codepoint 10 for tunnel type, as >> defined in draft-ietf-bess-evpn-overlay, intends to indicate the >> ability to receive plain MPLS in a context where other encaps are >> advertised (if you advertise only one non-MPLS encap, it means you >> support this encap but not MPLS) -- this I think would be nice to >> capture in draft-rosen-idr-tunnel-encaps > > I think that makes sense. Ok. >> * about the Remote Endpoint sub-TLV: why allow that an AF of 0 >> means "use next-hop address", but still require the presence of the >> TLV ? it seems that its absence could conveniently be interpreted >> as "use next-hop address", like what's done for the Tunnel Encap EC >> in section 6 > > Some folks have expressed the opinion that the BGP procedures for > handling errors in this attribute will be simplified if the Remote > Endpoint Sub-TLV is always required to be present. I don't have a > strong opinion about that myself. This does not seem consistent with allowing that the use of the Tunnel Encap EC with a semantic of an implicit BGP Tunnel Encap attribute with w.y.z TLVs/sub-TLVs. >> * section 6 should say that, associated to a labelled address >> family, the Tunnel Encap EC of value GRE (2) means the same as >> MPLS-in-GRE (value 11) (like section 2.2.5 does for the attribute) > > Makes sense. Ok. >> And my second head, the one trying to fill my BESS co-chair hat, >> can't help adding that addressing some of the above will require >> keeping the BESS working group involved all along the life of this >> draft. > > No problem. Thank you, -Thomas _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. From nobody Wed Jul 29 08:35: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 849F71A905D; Wed, 29 Jul 2015 08:35:07 -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 nvJEEBOKNXxG; Wed, 29 Jul 2015 08:35:05 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0777.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::777]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48C351AC39F; Wed, 29 Jul 2015 08:27:50 -0700 (PDT) Authentication-Results: tools.ietf.org; dkim=none (message not signed) header.d=none; Received: from [172.29.35.108] (66.129.241.14) by CY1PR0501MB1097.namprd05.prod.outlook.com (10.160.144.139) with Microsoft SMTP Server (TLS) id 15.1.225.19; Wed, 29 Jul 2015 15:27:25 +0000 To: Xuxiaohu , "thomas.morin@orange.com" , "idr@ietf.org" , BESS References: <02ce01d0b851$4ecec5a0$ec6c50e0$@ndzh.com> <2691CE0099834E4A9C5044EEC662BB9D571ADA7E@dfweml701-chm> <55A0273D.4020608@juniper.net> <2691CE0099834E4A9C5044EEC662BB9D571B77BF@dfweml701-chm> <001001d0c136$290061b0$7b012510$@ndzh.com> <10393_1437662753_55B0FE21_10393_2369_1_55B0FE1E.40600@orange.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB01880@NKGEML512-MBS.china.huawei.com> <55B7AF51.4040900@juniper.net> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB02833@NKGEML512-MBS.china.huawei.com> From: Eric C Rosen Message-ID: <55B8F0D7.6090200@juniper.net> Date: Wed, 29 Jul 2015 11:27:19 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB02833@NKGEML512-MBS.china.huawei.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.14] X-ClientProxiedBy: CY1PR1201CA0009.namprd12.prod.outlook.com (25.169.17.147) To CY1PR0501MB1097.namprd05.prod.outlook.com (25.160.144.139) X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1097; 2:znC74VOcEnmf5oBP3yZvfY3y2jC7FWP744Khm3BRCclr3RkAnwpewZjPbD2PmQ+oAiWgxtxFjp/HldfU0U69iwDfKY8o2v3glJCu5RqFU03hJaiZL9mMBSXirghFT5yhHCjxXgeZbkX3oHv2tymlHGC3885ZMvJl2jW2cQubDZs=; 3:mXlRvXqye+AGo2W7yFNXpKqdQUnnsdWsLr2PKzZqML8Ywum7rB3ZucI60YD0WzaXBXHFOqDWg+xDfrTLY00T3YiBTdaBb//EMKwsdCHYfF94GJ9tSlUcNiZj1eScVv/CJS45doY6aatSOgZBHORNnQ==; 25:wpu0fvdQZybzm68D/F3LjcA0+Q9rdcTsUSLU+p4HW8H7L5mJAJK54jdVJB4uQ0wVavm8k8TbivmWUOGTPqot3F5Cfd+fB0ctrrL6OPhybBbU10NTQuxZso1jAG5YRN51AAfi8NNcVE9fSTr/4aAPVWvwV6wWKJJWbyBAC9fddz93K05Ps+C96dTe/XIwPAD4j1otsmhJoygs9OKLR11s3IUV2ZwYz5xTcvdEw7+Zyg4lEpK8POdVoFobQBs/pg+mStlOiywADFKthA+GoPCXbQ== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1097; X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1097; 20:Hna/s9Fy5X4Zpe+t76F6RlTtjBZ29DkS0j4dA7r6reL0g1x2xfT0dozWVn7X29jhmYZofuxAKZEto6dNCmrjowXQlujaKw0jEKuEgPK14/QlXbd6NBLwNF9cZlcND1qsW7U4nXuRFBico0DYOzNhI9sHxj37JKAAzmCeNqIDwgX3DTttU53OGJC++DXsyHvRA1tGBLygKZJx5lyzkoLANhc/eDOm5TnGEUOMOetGpfB0GfrIy7xJg5ALXQ2c2IO8jSs4nUU6jwhQ4vIMGAE26qH5aK9eLXa7l6+r8EMndn7BvwoD1X6u/Mv+U4IGzPXoFsXCCtZQ/DaSR6/HtMVSD6hdRbS7s/toXRyYE3rTk/GRv25rdaXqDFego4qE2V7kypfglm30YLSy5kNg0cXYbXOzOYxh1wbtE/0bpB2cXGA3FhCfeO6KF1P6oZ9n5AF3eHgYjXTDOmElGeB7frF96dSDbjpNNLz4f0yqZDezYs0cC/2qNJvEJAGzEPrCTw2z; 4:U5xm9ef2+GJL1fQq5CRf24KEU5W/UwCxOqhLPB6nkXdXgkrCjfpZFHZmjcqNDi6eUnFEu84KNtnl8APDicjAYJ1aLE6QRm85q8QU4S8lrEwQIWUDHRDcxoifzkxt6ZYg75G5DxjukOeBpHT3PT/8+HqULA5hKMZFwGWaZTDZ0a8tEkdwH6ryR5blt52a2FNYvVkbAuQj7YHouugnHFQgTnFPTkXrLSjCdT+ORWB2iRg5DnlIvx2Nx03TXi37frpiCfOpsHZk2XoloxjYIOwM0qqKy73of/lrs4pCnNbfqVY= 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:CY1PR0501MB1097; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1097; X-Forefront-PRVS: 0652EA5565 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(6049001)(5423002)(86362001)(46102003)(4001350100001)(50466002)(80316001)(54356999)(47776003)(93886004)(76176999)(83506001)(42186005)(230783001)(50986999)(65956001)(36756003)(65806001)(66066001)(40100003)(122386002)(2501003)(2201001)(23746002)(92566002)(77096005)(33656002)(77156002)(189998001)(62966003)(2950100001)(5001960100002)(5001920100001)(5001770100001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1097; H:[172.29.35.108]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1097; 23:VKtOU0tRER0DbUyrEY6UYohaJ4/vkc4V5XBeKfEtL8Wx9cH5qREwKz0lSgwHLoT668SaXH9fSqrxhfizpq0LptiV1aRlk413pwGMxZd+/wDl0Px+Hi75r0OjBMsvaDJdQxKe87M/0e7BxYLr5o7i5dfflStYRlrFW1ezY9g2ZvZEnjzThVjtUB290MnOIRCILSzV1kyyRrvHvUc52H0phqnbGj18x9LeCZZlp2N7NcxMTmTevQh2pPT7gSqL30E8z6toOr/IYwKuvfKOzAxsD5d6dL2kXeaOMAwQYlhZGvN4G4ROMOguBDtxNZcDuso6sq2n2UFGE+TgGoWyeEGjyPgvs6ClBK6I+zzVpObefwNyJRKMFgO5q0Ns58L2n8FW+Wgp1hBBTX5WQ7JFldOQRj+pMUFhyZ3ScqXTyv3guWY5Na1PJ6r5MFsDGwxRjXrCnpgK6R2undv5fXnGxnfVNq3D9Zn9PDdgO5ZL0bwP+6mqks/fgvcgvJHwNp5dlDRMtuHSlzjUgSZ8+nk/b8k2Hjm4jf7sz2qPZvogmlocD7MeE7/IeRNTQiVAzEHkuVittvidTrTPcB2bYkdpiNOU3vT/JFXc4gwo0i+QtOOgZxSJnhB0ygtcjYyTRmSTJRslOvf3rqtuAbnFJk0snnw/TBAdy3tRvPxhi6J/KwcR7zq7Efa/24CfD398HHU47BVahZHBr65cUIxbFMFuZ40WXhV6idfpr2wpDMqer6hW8v3BdpGJUlzOdheURexjnXcteW9YpBLMenYqXSFpzUiZc0FI3SLKPqvQ3gQlXhQ9OYgIcKfM++ziDX1kdPyoSewcscTmMcbnzs+YO+HwzNogn+OxcjpdvhdDN8D/kE02rfEPjd3xmlsbXo4DTDgupnIA6x2cS5Z2TBYDZJJRQRKBWk3iMQj71w2oyUgOZlOpv/nwo6RLm9rXMIlT+y+y35mJ X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1097; 5:6FwtTEAdY0H9MBmmBgr3u3c+8+D+E56i29tPAGyPSDO14DFDvLTAoEBlQwgcqjuZ2//fb2Mi3MDWLJELSGt2H+P/aLhd9PepL84vBELKyuGgRjgYBrTQ4ipePY9zo6KUUccmVtlfiMBBpGc6MkhsHg==; 24:vNi/bXoBAT3klRw8gK/Vl694zD23TWy2nLwbCxb6dUgdSLVtPZ+5GcoXRL+gHEfWIuhaEngXO6P9TVJXRqa717cpIYpbmCZq2cg4V9qZE+c=; 20:C6DHbpjm5+yJt83K4iKa3M5k5LK4EdUuc/jc8CtA2Ir4iJp7qbuRxAVXxAZt1qYrA52DjVHuYuasqxrzCA9qQg== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jul 2015 15:27:25.0670 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1097 Archived-At: Cc: "draft-ietf-bess-evpn-overlay@tools.ietf.org" , "draft-rosen-idr-tunnel-encaps@tools.ietf.org" Subject: Re: [Idr] [bess] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00.txt (7/6 to 7/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: Wed, 29 Jul 2015 15:35:07 -0000 >> [Eric] I don't think the payload type can necessarily be inferred >> from the AFI/SAFI of the UPDATE that is carrying the Tunnel >> Encapsulation attribute. Consider, for instance, a case where the >> next hop is not of the same address family as the NLRI, but the >> route to the next hop is the route carrying the Tunnel >> Encapsulation attribute. > [Xiaohu] It seems that the example that you had mentioned is the > usage of the Tunnel Encapsulation attribute e as described in > RFC5512, rather than the usage of the Tunnel Encapsulation attribute > as proposed by this draft:) No; see section 5 ("Recursive Next Hop Resolution") of the new draft. I think there are other examples where one might not be able to infer the type of the payload from the AFI/SAFI of the route. Suppose you use BGP as your only routing algorithm, and you use only the unlabeled address families (AFI/SAFI = 1/1 or 2/1). But you use LDP (or SDN or something else) to assign labels to prefixes. In this case, your data traffic might be MPLS, but there is no use of the labeled address families (AFI/SAFI = 1/4, 2/4, 1/128, or 2/128). If you use the Tunnel Encapsulation attribute to specify a GRE tunnel for some route, you could end up having to do an MPLS-in-GRE encapsulation. I'm not sure whether there is a real use case for this, but I'm not also not sure that we want to rule it out. From nobody Thu Jul 30 02:38: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 6379D1A0217 for ; Thu, 30 Jul 2015 02:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 YeD7m9nPWayM for ; Thu, 30 Jul 2015 02:38:37 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A615D1A0231 for ; Thu, 30 Jul 2015 02:38:37 -0700 (PDT) Received: from 172.18.9.243 (EHLO lhreml402-hub.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CPO43938; Thu, 30 Jul 2015 04:38:36 -0500 (CDT) Received: from SZXEMA411-HUB.china.huawei.com (10.82.72.70) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 30 Jul 2015 10:37:05 +0100 Received: from SZXEMA508-MBX.china.huawei.com ([169.254.7.70]) by szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id 14.03.0158.001; Thu, 30 Jul 2015 17:36:58 +0800 From: "Wunan (Eric)" To: "Acee Lindem (acee)" Thread-Topic: Comment on flow-spec Routing Policy Distribution (RPD) from IDR WG Meeting Thread-Index: AQHQyT1rGpHY1z5y1kqapqkMXiFqnZ3zp1/w Date: Thu, 30 Jul 2015 09:36:58 +0000 Message-ID: <0F26584357FD124DB93F1535E4B0A6505FC18F65@szxema508-mbx.china.huawei.com> References: <60FE2F7A-8C22-4732-8691-36D3903BDCDB@cisco.com> In-Reply-To: <60FE2F7A-8C22-4732-8691-36D3903BDCDB@cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.156.105] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] Comment on flow-spec Routing Policy Distribution (RPD) from IDR WG Meeting 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 Jul 2015 09:38:40 -0000 QWNlZSwNCg0KVGhhbmsgeW91IHNvIHRob3VnaHRmdWxseSB0byBwdXQgdGhpcyBvbiB0aGUgbGlz dCwgc29ycnkgZm9yIGRpZG4ndCB0YWtlIGFsbCB5b3VyIHBvaW50cyBkdXJpbmcgSURSIG1lZXRp bmcuDQpUaGF0IGlzIHRoZSByZWFzb24gd2h5IGl0IHdpbGwgYmUgYmV0dGVyIHRvIGhhdmUgdGhl IGRpYWxvZ3VlIGRpc3BsYXllZCBhdCB0aGUgc2NyZWVuIGJvdHRvbSB3aGVuIHlvdSBhcmUgd2F0 Y2hpbmcgYSBUViBzaG93Lg0KDQpZb3VyIG9ic2VydmF0aW9uIG9uIG91dGJvdW5kIGlzIGNvcnJl Y3QsIGFuZCB5ZXMsIGl0IGlzIGEgZGlmZmVyZW50IHNjZW5hcmlvIGZyb20gRERPUy4NClRoZSBt b3RpdmF0aW9uIGJlaGluZCB0aGlzIGRyYWZ0IGlzIHRoYXQgd2UgbWF5IG5lZWQgb25lIG1lY2hh bmlzbSB0byBzb2x2ZSBib3RoIG91dGJvdW5kIGFuZCBpbmJvdW5kIHRyYWZmaWMgZW5naW5lZXJp bmcgb24gZGlmZmVyZW50IG5ldHdvcmtzLCBldmVuIHRob3NlIHdpdGhvdXQgTVBMUyBkYXRhcGxh bmUuDQoNCkJ5IHRoZSB3YXksIEkgY2hhbmdlZCBjYyBmcm9tIGlkci1yZXF1ZXN0QGlldGYub3Jn IHRvIGlkckBpZXRmLm9yZy4gSSBhc3N1bWVkIHRoaXMgaXMgYSB0eXBvIHNpbmNlIHlvdXIgbWFp bCBkaWRuJ3Qgc2hvdyBpbiB0aGUgbGlzdC4NCg0KUmVnYXJkcw0KRXJpYw0KDQotLS0tLemCruS7 tuWOn+S7ti0tLS0tDQrlj5Hku7bkuro6IEFjZWUgTGluZGVtIChhY2VlKSBbbWFpbHRvOmFjZWVA Y2lzY28uY29tXSANCuWPkemAgeaXtumXtDogMjAxNeW5tDfmnIgyOOaXpSAyMTo1OA0K5pS25Lu2 5Lq6OiBXdW5hbiAoRXJpYykNCuaKhOmAgTogaWRyLXJlcXVlc3RAaWV0Zi5vcmcNCuS4u+mimDog Q29tbWVudCBvbiBmbG93LXNwZWMgUm91dGluZyBQb2xpY3kgRGlzdHJpYnV0aW9uIChSUEQpIGZy b20gSURSIFdHIE1lZXRpbmcgDQoNCkhpIEVyaWMsIA0KDQpMZXQgbWUgZXhwbGFpbiB0aGUgY29t bWVudCBJIHdhcyB0cnlpbmcgdG8gYXJ0aWN1bGF0ZSBpbiBJRFIgbWVldGluZy4gRmxvdyBTcGVj IE5MUkkgaGFzIHRyYWRpdGlvbmFsbHkgYmVlbiB1c2VkIGZvciB0cmFmZmljIGZpbHRlcmluZyB0 byBtaXRpZ2F0ZSBERE9TIGF0dGFja3MuICBOb3cgdGhhdCBpdCBpcyBiZWluZyBwcm9wb3NlZCBm b3Igb3V0Ym91bmQgdHJhZmZpYyBjb250cm9sLCB0aGUgcG9saWN5IGNvbnRyb2xsZXIgd2lsbCBh bHNvIG5lZWQgdG8gcGVlciB3aXRoIGFsbCB0aGUgZWdyZXNzIHJvdXRlcnMgdG8gbGVhcm4gdGhl IGF2YWlsYWJsZSBJUHY0L0lQdjYgcGF0aHMuIFRoaXMgaXMgbmVjZXNzYXJ5IHNvIHRoYXQgdGhl IHBvbGljeSBjb250cm9sbGVyIGRvZXNu4oCZdCBpbnN0YWxsIGEgZmlsZXIgcnVsZSB0aGF0IHdp bGwgYmxhY2tob2xlIHRyYWZmaWMuIFRoaXMgbWF5IHNlZW0gb2J2aW91cyBidXQgdGhlIGl0IGlz IGEgZGlmZmVyZW50IHNjZW5hcmlvIGZyb20gdG9kYXnigJlzIFJGQyA1NTc1IGRlcGxveW1lbnRz LiANCg0KSSB0aGluayBzZWdtZW50IHJvdXRpbmcgaXMgYSBiZXR0ZXIgd2F5IHRvIHNvbHZlIHRo aXMgcHJvYmxlbSBidXQgdGhlbiB0aGlzIGlzIG5vdCBhbiBlbnRpcmVseSB1bmJpYXNlZCBvcGlu aW9uIHNpbmNlIEnigJltIHdvcmtpbmcgb24gc2VnbWVudCByb3V0aW5nLiANCg0KVGhhbmtzLA0K QWNlZSANCg== From nobody Thu Jul 30 02:43: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 15C5E1A01EA; Thu, 30 Jul 2015 02:43:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.26 X-Spam-Level: X-Spam-Status: No, score=-98.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 Poni7tl4-Pd7; Thu, 30 Jul 2015 02:43:16 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id E44CF1A03A1; Thu, 30 Jul 2015 02:43:15 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 2B07014352F73; Thu, 30 Jul 2015 17:43:11 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 98CB11EE70DDE; Thu, 30 Jul 2015 17:43:11 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id t6U9h3Vo008190; Thu, 30 Jul 2015 17:43:03 +0800 (GMT-8) (envelope-from zhang.zheng@zte.com.cn) In-Reply-To: <55B290D2.20409@juniper.net> To: Eric C Rosen MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: zhang.zheng@zte.com.cn Date: Thu, 30 Jul 2015 17:42:53 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2015-07-30 17:43:02, Serialize complete at 2015-07-30 17:43:02 Content-Type: multipart/alternative; boundary="=_alternative 0035618048257E92_=" X-MAIL: mse01.zte.com.cn t6U9h3Vo008190 Archived-At: Cc: 'IDR WG' , Idr , Susan Hares Subject: [Idr] =?gb2312?b?tPC4tDogUmU6ICBDb21tZW50IG9uIGRyYWZ0LXpoYW5nLWlk?= =?gb2312?b?ci11cHN0cmVhbS1hc3NpZ25lZC1sYWJlbC1zb2x1dGlvbg==?= 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 Jul 2015 09:43:19 -0000 This is a multipart message in MIME format. --=_alternative 0035618048257E92_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgRXJpYywNCg0KICAgIFJlZmVyIHRvIFJGQzUzMzEsIHRoZSBjb250ZXh0LXNwZWNpZmljIGxh YmVsIGNhbiBiZSBhdXRvIGdlbmVyYXRlZCBvciANCm1hbnVhbGx5IGNvbmZpZ3VyZWQuIEluIElQ djYgZW52aXJvbm1lbnQsIG1hbnVhbGx5IGNvbnRyb2wgaXMgcmVxdWlyZWQuIA0KQW5kIHRoZSBu ZXR3b3JrIHNlcnZpY2UgdGhhdCBpcyBzdXBwb3NlZCBieSBMM1ZQTiwgbm90IG9ubHkgaW5jbHVk ZSBNVlBOLCANCmJ1dCBhbHNvIGluY2x1ZGUgRVZQTiwgREMgaW50ZXJjb25uZWN0aW9uLCBhbmQg c28gb24uIEZvciB0aGUgdXNlIG9mIA0KdXBzdHJlYW0gYXNzaWduZWQgbGFiZWwsIHRoZSBDb250 ZXh0LVNwZWNpZmljIGxhYmVsIG5lZWQgYSBsYWJlbCByYW5nZSANCnNwYWNlLiBJdCBpcyBkaWZm aWN1bHQgdG8gY29udHJvbCBtYW51YWxseSwgZXNwZWNpYWxseSBmb3IgdGhlIGFidW5kYW5jZSAN Cm9mIHNlcnZpY2VzLiBTbyB0aGUgbGFiZWwgc3BhY2UgbWF5IGhhdmUgYSBjb2xsaXNpb24uIEV2 ZW4gaWYgdGhlIA0KY29udGV4dC1zcGVjaWZpYyBsYWJlbCBpcyB0YWtlbiBieSBwMm1wIG9yIG1w Mm1wIHR1bm5lbCwgdGhlcmUgbWF5IA0KaGF2ZSBhIGNvbGxpc2lvbi4NCg0KICAgIEFuZCB0aGUg cDJtcCBhbmQgbXAybXAgdHVubmVsIG1heSBiZSB1c2VkIHRvIHRyYW5zZmVyIGV4dHJhbmV0IGZs b3cuIA0KV2hlbiANCmRpZmZlcmVudCBtdWx0aWNhc3QgZmxvd3Mgd2hpY2ggYXJlIGZvcndhcmRl ZCB0byByZWNlaXZlcnMgaW4gZGlmZmVyZW50IA0KVlBOIA0KYXJlIG1peGVkIGludG8gb25lIFAt dHVubmVsLCBhcmUgdGhlcmUgbW9yZSBjb25mbGljdD8NCg0KU2FuZHkNCg0KDQpFcmljIEMgUm9z ZW4gPGVyb3NlbkBqdW5pcGVyLm5ldD4g0LTT2iAyMDE1LzA3LzI1IDAzOjI0OjAyOg0KDQo+IE9u IDcvMjUvMjAxNSAxMjo0NSBQTSwgemhhbmcuemhlbmdAenRlLmNvbS5jbiB3cm90ZToNCj4gPiBS b3V0ZXJzIGZvcndhcmQgTVZQTiBmbG93cyBieSBQMk1QIExTUCwgYnV0IGFsc28gcm91dGVycw0K PiA+IGNhbiBmb3J3YXJkIE1WUE4gZmxvd3MgYnkgTVAyTVAgTFNQLiBBbmQgYXMgc29vbiBhcyBy b3V0ZXJzIG1peCANCnNldmVyYWwNCj4gPiBNVlBOIGZsb3dzIGludG8gYSBzaW5nbGUgTFNQLCBj b2xsaXNpb24gd2lsbCBoYXBwZW4sIGFuZCBpdCB3aWxsDQo+ID4gaW5mbHVlbmNlIGRhdGEgZm9y d2FyZGluZy4NCj4gDQo+IEFuIE1QMk1QIExTUCBoYXMgYSBzaW5nbGUgcm9vdCBub2RlLCBhbmQg dGhhdCByb290IG5vZGUgd291bGQgYmUgDQo+IHJlc3BvbnNpYmxlIGZvciBhc3NpZ25pbmcgYW55 IHVwc3RyZWFtLWFzc2lnbmVkIGxhYmVscyB0aGF0IGFyZSB1c2VkIA0KPiB3aXRoaW4gdGhhdCBM U1AuDQo+IA0KPiBKdXN0IGZvciBjbGFyaXR5LCB0aGUgdXBzdHJlYW0tYXNzaWduZWQgbGFiZWwg aW4gdGhlIFBNU0kgVHVubmVsIA0KPiBhdHRyaWJ1dGUgaXMgbm90IG5lZWRlZCB3aGVuIG11bHRp cGxlIGZsb3dzIGFyZSBiZWluZyB0cmFuc21pdHRlZCBvbiBhIA0KPiBzaW5nbGUgTFNQLCBpdCBp cyBuZWVkZWQgb25seSB3aGVuIGZsb3dzIGZyb20gbXVsdGlwbGUgVlBOcyBhcmUgYXJlIA0KPiB0 cmFuc21pdHRlZCBvbiBhIHNpbmdsZSBMU1AuICBJIGhhdmUgdG8gYWRtaXQgdGhhdCB1c2luZyBh IHNpbmdsZSBNUDJNUCANCj4gTFNQIHRvIGNhcnJ5IHRyYWZmaWMgb2Ygc2V2ZXJhbCBkaWZmZXJl bnQgVlBOcyBpcyBub3QgYSBzY2VuYXJpbyB0aGF0IA0KPiBoYXMgYmVlbiBnaXZlbiBhIGxvdCBv ZiBhdHRlbnRpb24sIGFuZCB3aWxsIHByb2JhYmx5IG9ubHkgd29yayBpZiAoYSkgDQo+IHRoZSBo aWVyYXJjaGljYWwgcGFydGl0aW9uZWQgbWV0aG9kIChzZWUgUkZDIDc1ODIpIGlzIHVzZWQsIGFu ZCAoYikgYWxsIA0KPiB0aG9zZSBWUE5zIGhhdmUgVlJGcyBhdCB0aGUgcm9vdCBub2RlLiAgQnV0 IGl0J3Mgbm90IGNsZWFyIHRoYXQgdGhlcmUncyANCj4gYW55IHJlYWwgdmFsdWUgdG8gbXVsdGlw bGV4aW5nIHNldmVyYWwgVlBOcyBvbnRvIGEgc2luZ2xlIE1QMk1QIExTUC4NCj4gDQo+IFRoZXJl IGlzIGFub3RoZXIgdXNlIG9mIHVwc3RyZWFtLWFzc2lnbmVkIGxhYmVscyBkZXNjcmliZWQgaW4g UkZDIDc1ODIgDQo+ICgiUEUgRGlzdGluZ3Vpc2hlciBsYWJlbHMiKSwgYW5kIHRob3NlIGFyZSBh bHdheXMgYXNzaWduZWQgYnkgdGhlIHJvb3QgDQo+IG5vZGUgb2YgdGhlIE1QMk1QIExTUC4NCg0K --=_alternative 0035618048257E92_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEVyaWMsPC9mb250Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7IFJlZmVy IHRvIFJGQzUzMzEsIHRoZQ0KY29udGV4dC1zcGVjaWZpYyBsYWJlbCBjYW4gYmUgYXV0byBnZW5l cmF0ZWQgb3IgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5tYW51 YWxseSBjb25maWd1cmVkLiBJbiBJUHY2IGVudmlyb25tZW50LA0KbWFudWFsbHkgY29udHJvbCBp cyByZXF1aXJlZC4gPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5B bmQgdGhlIG5ldHdvcmsgc2VydmljZSB0aGF0IGlzIHN1cHBvc2VkDQpieSBMM1ZQTiwgbm90IG9u bHkgaW5jbHVkZSBNVlBOLCA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPmJ1dCBhbHNvIGluY2x1ZGUgRVZQTiwgREMgaW50ZXJjb25uZWN0aW9uLA0KYW5kIHNvIG9u LiBGb3IgdGhlIHVzZSBvZiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPnVwc3RyZWFtIGFzc2lnbmVkIGxhYmVsLCB0aGUgQ29udGV4dC1TcGVjaWZpYw0KbGFiZWwg bmVlZCBhIGxhYmVsIHJhbmdlIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+c3BhY2UuIEl0IGlzIGRpZmZpY3VsdCB0byBjb250cm9sIG1hbnVhbGx5LA0KZXNwZWNp YWxseSBmb3IgdGhlIGFidW5kYW5jZSA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPm9mIHNlcnZpY2VzLiBTbyB0aGUgbGFiZWwgc3BhY2UgbWF5DQpoYXZlIGEgY29s bGlzaW9uLiBFdmVuIGlmIHRoZSA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPmNvbnRleHQtc3BlY2lmaWMgbGFiZWwgaXMgdGFrZW4gYnkgcDJtcA0Kb3IgbXAybXAg dHVubmVsLCB0aGVyZSBtYXkgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj5oYXZlIGEgY29sbGlzaW9uLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyBBbmQgdGhlIHAybXAgYW5kIG1wMm1wDQp0dW5u ZWwgbWF5IGJlIHVzZWQgdG8gdHJhbnNmZXIgZXh0cmFuZXQgZmxvdy4gV2hlbiA8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmRpZmZlcmVudCBtdWx0aWNhc3QgZmxv d3Mgd2hpY2ggYXJlDQpmb3J3YXJkZWQgdG8gcmVjZWl2ZXJzIGluIGRpZmZlcmVudCBWUE4gPC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5hcmUgbWl4ZWQgaW50byBv bmUgUC10dW5uZWwsIGFyZSB0aGVyZQ0KbW9yZSBjb25mbGljdD88L2ZvbnQ+DQo8YnI+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlNhbmR5PGJyPg0KPC9mb250Pg0KPGJyPg0K PGJyPjxmb250IHNpemU9Mj48dHQ+RXJpYyBDIFJvc2VuICZsdDtlcm9zZW5AanVuaXBlci5uZXQm Z3Q7INC009ogMjAxNS8wNy8yNQ0KMDM6MjQ6MDI6PGJyPg0KPGJyPg0KJmd0OyBPbiA3LzI1LzIw MTUgMTI6NDUgUE0sIHpoYW5nLnpoZW5nQHp0ZS5jb20uY24gd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7 IFJvdXRlcnMgZm9yd2FyZCBNVlBOIGZsb3dzIGJ5IFAyTVAgTFNQLCBidXQgYWxzbyByb3V0ZXJz PGJyPg0KJmd0OyAmZ3Q7IGNhbiBmb3J3YXJkIE1WUE4gZmxvd3MgYnkgTVAyTVAgTFNQLiBBbmQg YXMgc29vbiBhcyByb3V0ZXJzIG1peA0Kc2V2ZXJhbDxicj4NCiZndDsgJmd0OyBNVlBOIGZsb3dz IGludG8gYSBzaW5nbGUgTFNQLCBjb2xsaXNpb24gd2lsbCBoYXBwZW4sIGFuZCBpdCB3aWxsPGJy Pg0KJmd0OyAmZ3Q7IGluZmx1ZW5jZSBkYXRhIGZvcndhcmRpbmcuPGJyPg0KJmd0OyA8YnI+DQom Z3Q7IEFuIE1QMk1QIExTUCBoYXMgYSBzaW5nbGUgcm9vdCBub2RlLCBhbmQgdGhhdCByb290IG5v ZGUgd291bGQgYmUgPGJyPg0KJmd0OyByZXNwb25zaWJsZSBmb3IgYXNzaWduaW5nIGFueSB1cHN0 cmVhbS1hc3NpZ25lZCBsYWJlbHMgdGhhdCBhcmUgdXNlZA0KPGJyPg0KJmd0OyB3aXRoaW4gdGhh dCBMU1AuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEp1c3QgZm9yIGNsYXJpdHksIHRoZSB1cHN0cmVh bS1hc3NpZ25lZCBsYWJlbCBpbiB0aGUgUE1TSSBUdW5uZWwgPGJyPg0KJmd0OyBhdHRyaWJ1dGUg aXMgbm90IG5lZWRlZCB3aGVuIG11bHRpcGxlIGZsb3dzIGFyZSBiZWluZyB0cmFuc21pdHRlZA0K b24gYSA8YnI+DQomZ3Q7IHNpbmdsZSBMU1AsIGl0IGlzIG5lZWRlZCBvbmx5IHdoZW4gZmxvd3Mg ZnJvbSBtdWx0aXBsZSBWUE5zIGFyZSBhcmUNCjxicj4NCiZndDsgdHJhbnNtaXR0ZWQgb24gYSBz aW5nbGUgTFNQLiAmbmJzcDtJIGhhdmUgdG8gYWRtaXQgdGhhdCB1c2luZyBhIHNpbmdsZQ0KTVAy TVAgPGJyPg0KJmd0OyBMU1AgdG8gY2FycnkgdHJhZmZpYyBvZiBzZXZlcmFsIGRpZmZlcmVudCBW UE5zIGlzIG5vdCBhIHNjZW5hcmlvIHRoYXQNCjxicj4NCiZndDsgaGFzIGJlZW4gZ2l2ZW4gYSBs b3Qgb2YgYXR0ZW50aW9uLCBhbmQgd2lsbCBwcm9iYWJseSBvbmx5IHdvcmsgaWYNCihhKSA8YnI+ DQomZ3Q7IHRoZSBoaWVyYXJjaGljYWwgcGFydGl0aW9uZWQgbWV0aG9kIChzZWUgUkZDIDc1ODIp IGlzIHVzZWQsIGFuZCAoYikNCmFsbCA8YnI+DQomZ3Q7IHRob3NlIFZQTnMgaGF2ZSBWUkZzIGF0 IHRoZSByb290IG5vZGUuICZuYnNwO0J1dCBpdCdzIG5vdCBjbGVhciB0aGF0DQp0aGVyZSdzIDxi cj4NCiZndDsgYW55IHJlYWwgdmFsdWUgdG8gbXVsdGlwbGV4aW5nIHNldmVyYWwgVlBOcyBvbnRv IGEgc2luZ2xlIE1QMk1QIExTUC48YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhlcmUgaXMgYW5vdGhl ciB1c2Ugb2YgdXBzdHJlYW0tYXNzaWduZWQgbGFiZWxzIGRlc2NyaWJlZCBpbiBSRkMNCjc1ODIg PGJyPg0KJmd0OyAoJnF1b3Q7UEUgRGlzdGluZ3Vpc2hlciBsYWJlbHMmcXVvdDspLCBhbmQgdGhv c2UgYXJlIGFsd2F5cyBhc3NpZ25lZA0KYnkgdGhlIHJvb3QgPGJyPg0KJmd0OyBub2RlIG9mIHRo ZSBNUDJNUCBMU1AuPGJyPg0KPC90dD48L2ZvbnQ+DQo= --=_alternative 0035618048257E92_=-- From nobody Thu Jul 30 02:43: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 A25801A03A9; Thu, 30 Jul 2015 02:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.76 X-Spam-Level: X-Spam-Status: No, score=-101.76 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 jlNfUKyjZu2p; Thu, 30 Jul 2015 02:43:45 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id E2FC81A039A; Thu, 30 Jul 2015 02:43:44 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 5B755945017D0; Thu, 30 Jul 2015 17:43:40 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id CB40765C77F0; Thu, 30 Jul 2015 17:43:40 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id t6U9hUWM009832; Thu, 30 Jul 2015 17:43:30 +0800 (GMT-8) (envelope-from zhang.zheng@zte.com.cn) In-Reply-To: <55B290D2.20409@juniper.net> To: Eric C Rosen MIME-Version: 1.0 Sensitivity: X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: zhang.zheng@zte.com.cn Date: Thu, 30 Jul 2015 17:43:20 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2015-07-30 17:43:29, Serialize complete at 2015-07-30 17:43:29 Content-Type: multipart/alternative; boundary="=_alternative 00356C1448257E92_=" X-MAIL: mse01.zte.com.cn t6U9hUWM009832 Archived-At: Cc: 'IDR WG' , Idr , Susan Hares Subject: Re: [Idr] Comment on draft-zhang-idr-upstream-assigned-label-solution 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 Jul 2015 09:43:46 -0000 This is a multipart message in MIME format. --=_alternative 00356C1448257E92_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgRXJpYywNCg0KICAgIFJlZmVyIHRvIFJGQzUzMzEsIHRoZSBjb250ZXh0LXNwZWNpZmljIGxh YmVsIGNhbiBiZSBhdXRvIGdlbmVyYXRlZCBvciANCm1hbnVhbGx5IGNvbmZpZ3VyZWQuIEluIElQ djYgZW52aXJvbm1lbnQsIG1hbnVhbGx5IGNvbnRyb2wgaXMgcmVxdWlyZWQuIA0KQW5kIHRoZSBu ZXR3b3JrIHNlcnZpY2UgdGhhdCBpcyBzdXBwb3NlZCBieSBMM1ZQTiwgbm90IG9ubHkgaW5jbHVk ZSBNVlBOLCANCmJ1dCBhbHNvIGluY2x1ZGUgRVZQTiwgREMgaW50ZXJjb25uZWN0aW9uLCBhbmQg c28gb24uIEZvciB0aGUgdXNlIG9mIA0KdXBzdHJlYW0gYXNzaWduZWQgbGFiZWwsIHRoZSBDb250 ZXh0LVNwZWNpZmljIGxhYmVsIG5lZWQgYSBsYWJlbCByYW5nZSANCnNwYWNlLiBJdCBpcyBkaWZm aWN1bHQgdG8gY29udHJvbCBtYW51YWxseSwgZXNwZWNpYWxseSBmb3IgdGhlIGFidW5kYW5jZSAN Cm9mIHNlcnZpY2VzLiBTbyB0aGUgbGFiZWwgc3BhY2UgbWF5IGhhdmUgYSBjb2xsaXNpb24uIEV2 ZW4gaWYgdGhlIA0KY29udGV4dC1zcGVjaWZpYyBsYWJlbCBpcyB0YWtlbiBieSBwMm1wIG9yIG1w Mm1wIHR1bm5lbCwgdGhlcmUgbWF5IA0KaGF2ZSBhIGNvbGxpc2lvbi4NCg0KICAgIEFuZCB0aGUg cDJtcCBhbmQgbXAybXAgdHVubmVsIG1heSBiZSB1c2VkIHRvIHRyYW5zZmVyIGV4dHJhbmV0IGZs b3cuIA0KV2hlbiANCmRpZmZlcmVudCBtdWx0aWNhc3QgZmxvd3Mgd2hpY2ggYXJlIGZvcndhcmRl ZCB0byByZWNlaXZlcnMgaW4gZGlmZmVyZW50IA0KVlBOIA0KYXJlIG1peGVkIGludG8gb25lIFAt dHVubmVsLCBhcmUgdGhlcmUgbW9yZSBjb25mbGljdD8NCg0KU2FuZHkNCg0KDQpFcmljIEMgUm9z ZW4gPGVyb3NlbkBqdW5pcGVyLm5ldD4g0LTT2iAyMDE1LzA3LzI1IDAzOjI0OjAyOg0KDQo+IE9u IDcvMjUvMjAxNSAxMjo0NSBQTSwgemhhbmcuemhlbmdAenRlLmNvbS5jbiB3cm90ZToNCj4gPiBS b3V0ZXJzIGZvcndhcmQgTVZQTiBmbG93cyBieSBQMk1QIExTUCwgYnV0IGFsc28gcm91dGVycw0K PiA+IGNhbiBmb3J3YXJkIE1WUE4gZmxvd3MgYnkgTVAyTVAgTFNQLiBBbmQgYXMgc29vbiBhcyBy b3V0ZXJzIG1peCANCnNldmVyYWwNCj4gPiBNVlBOIGZsb3dzIGludG8gYSBzaW5nbGUgTFNQLCBj b2xsaXNpb24gd2lsbCBoYXBwZW4sIGFuZCBpdCB3aWxsDQo+ID4gaW5mbHVlbmNlIGRhdGEgZm9y d2FyZGluZy4NCj4gDQo+IEFuIE1QMk1QIExTUCBoYXMgYSBzaW5nbGUgcm9vdCBub2RlLCBhbmQg dGhhdCByb290IG5vZGUgd291bGQgYmUgDQo+IHJlc3BvbnNpYmxlIGZvciBhc3NpZ25pbmcgYW55 IHVwc3RyZWFtLWFzc2lnbmVkIGxhYmVscyB0aGF0IGFyZSB1c2VkIA0KPiB3aXRoaW4gdGhhdCBM U1AuDQo+IA0KPiBKdXN0IGZvciBjbGFyaXR5LCB0aGUgdXBzdHJlYW0tYXNzaWduZWQgbGFiZWwg aW4gdGhlIFBNU0kgVHVubmVsIA0KPiBhdHRyaWJ1dGUgaXMgbm90IG5lZWRlZCB3aGVuIG11bHRp cGxlIGZsb3dzIGFyZSBiZWluZyB0cmFuc21pdHRlZCBvbiBhIA0KPiBzaW5nbGUgTFNQLCBpdCBp cyBuZWVkZWQgb25seSB3aGVuIGZsb3dzIGZyb20gbXVsdGlwbGUgVlBOcyBhcmUgYXJlIA0KPiB0 cmFuc21pdHRlZCBvbiBhIHNpbmdsZSBMU1AuICBJIGhhdmUgdG8gYWRtaXQgdGhhdCB1c2luZyBh IHNpbmdsZSBNUDJNUCANCj4gTFNQIHRvIGNhcnJ5IHRyYWZmaWMgb2Ygc2V2ZXJhbCBkaWZmZXJl bnQgVlBOcyBpcyBub3QgYSBzY2VuYXJpbyB0aGF0IA0KPiBoYXMgYmVlbiBnaXZlbiBhIGxvdCBv ZiBhdHRlbnRpb24sIGFuZCB3aWxsIHByb2JhYmx5IG9ubHkgd29yayBpZiAoYSkgDQo+IHRoZSBo aWVyYXJjaGljYWwgcGFydGl0aW9uZWQgbWV0aG9kIChzZWUgUkZDIDc1ODIpIGlzIHVzZWQsIGFu ZCAoYikgYWxsIA0KPiB0aG9zZSBWUE5zIGhhdmUgVlJGcyBhdCB0aGUgcm9vdCBub2RlLiAgQnV0 IGl0J3Mgbm90IGNsZWFyIHRoYXQgdGhlcmUncyANCj4gYW55IHJlYWwgdmFsdWUgdG8gbXVsdGlw bGV4aW5nIHNldmVyYWwgVlBOcyBvbnRvIGEgc2luZ2xlIE1QMk1QIExTUC4NCj4gDQo+IFRoZXJl IGlzIGFub3RoZXIgdXNlIG9mIHVwc3RyZWFtLWFzc2lnbmVkIGxhYmVscyBkZXNjcmliZWQgaW4g UkZDIDc1ODIgDQo+ICgiUEUgRGlzdGluZ3Vpc2hlciBsYWJlbHMiKSwgYW5kIHRob3NlIGFyZSBh bHdheXMgYXNzaWduZWQgYnkgdGhlIHJvb3QgDQo+IG5vZGUgb2YgdGhlIE1QMk1QIExTUC4NCg0K --=_alternative 00356C1448257E92_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEVyaWMsPC9mb250Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7IFJlZmVy IHRvIFJGQzUzMzEsIHRoZQ0KY29udGV4dC1zcGVjaWZpYyBsYWJlbCBjYW4gYmUgYXV0byBnZW5l cmF0ZWQgb3IgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5tYW51 YWxseSBjb25maWd1cmVkLiBJbiBJUHY2IGVudmlyb25tZW50LA0KbWFudWFsbHkgY29udHJvbCBp cyByZXF1aXJlZC4gPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5B bmQgdGhlIG5ldHdvcmsgc2VydmljZSB0aGF0IGlzIHN1cHBvc2VkDQpieSBMM1ZQTiwgbm90IG9u bHkgaW5jbHVkZSBNVlBOLCA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPmJ1dCBhbHNvIGluY2x1ZGUgRVZQTiwgREMgaW50ZXJjb25uZWN0aW9uLA0KYW5kIHNvIG9u LiBGb3IgdGhlIHVzZSBvZiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPnVwc3RyZWFtIGFzc2lnbmVkIGxhYmVsLCB0aGUgQ29udGV4dC1TcGVjaWZpYw0KbGFiZWwg bmVlZCBhIGxhYmVsIHJhbmdlIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+c3BhY2UuIEl0IGlzIGRpZmZpY3VsdCB0byBjb250cm9sIG1hbnVhbGx5LA0KZXNwZWNp YWxseSBmb3IgdGhlIGFidW5kYW5jZSA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPm9mIHNlcnZpY2VzLiBTbyB0aGUgbGFiZWwgc3BhY2UgbWF5DQpoYXZlIGEgY29s bGlzaW9uLiBFdmVuIGlmIHRoZSA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPmNvbnRleHQtc3BlY2lmaWMgbGFiZWwgaXMgdGFrZW4gYnkgcDJtcA0Kb3IgbXAybXAg dHVubmVsLCB0aGVyZSBtYXkgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj5oYXZlIGEgY29sbGlzaW9uLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyBBbmQgdGhlIHAybXAgYW5kIG1wMm1wDQp0dW5u ZWwgbWF5IGJlIHVzZWQgdG8gdHJhbnNmZXIgZXh0cmFuZXQgZmxvdy4gV2hlbiA8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmRpZmZlcmVudCBtdWx0aWNhc3QgZmxv d3Mgd2hpY2ggYXJlDQpmb3J3YXJkZWQgdG8gcmVjZWl2ZXJzIGluIGRpZmZlcmVudCBWUE4gPC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5hcmUgbWl4ZWQgaW50byBv bmUgUC10dW5uZWwsIGFyZSB0aGVyZQ0KbW9yZSBjb25mbGljdD88L2ZvbnQ+DQo8YnI+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlNhbmR5PGJyPg0KPC9mb250Pg0KPGJyPg0K PGJyPjxmb250IHNpemU9Mj48dHQ+RXJpYyBDIFJvc2VuICZsdDtlcm9zZW5AanVuaXBlci5uZXQm Z3Q7INC009ogMjAxNS8wNy8yNQ0KMDM6MjQ6MDI6PGJyPg0KPGJyPg0KJmd0OyBPbiA3LzI1LzIw MTUgMTI6NDUgUE0sIHpoYW5nLnpoZW5nQHp0ZS5jb20uY24gd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7 IFJvdXRlcnMgZm9yd2FyZCBNVlBOIGZsb3dzIGJ5IFAyTVAgTFNQLCBidXQgYWxzbyByb3V0ZXJz PGJyPg0KJmd0OyAmZ3Q7IGNhbiBmb3J3YXJkIE1WUE4gZmxvd3MgYnkgTVAyTVAgTFNQLiBBbmQg YXMgc29vbiBhcyByb3V0ZXJzIG1peA0Kc2V2ZXJhbDxicj4NCiZndDsgJmd0OyBNVlBOIGZsb3dz IGludG8gYSBzaW5nbGUgTFNQLCBjb2xsaXNpb24gd2lsbCBoYXBwZW4sIGFuZCBpdCB3aWxsPGJy Pg0KJmd0OyAmZ3Q7IGluZmx1ZW5jZSBkYXRhIGZvcndhcmRpbmcuPGJyPg0KJmd0OyA8YnI+DQom Z3Q7IEFuIE1QMk1QIExTUCBoYXMgYSBzaW5nbGUgcm9vdCBub2RlLCBhbmQgdGhhdCByb290IG5v ZGUgd291bGQgYmUgPGJyPg0KJmd0OyByZXNwb25zaWJsZSBmb3IgYXNzaWduaW5nIGFueSB1cHN0 cmVhbS1hc3NpZ25lZCBsYWJlbHMgdGhhdCBhcmUgdXNlZA0KPGJyPg0KJmd0OyB3aXRoaW4gdGhh dCBMU1AuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEp1c3QgZm9yIGNsYXJpdHksIHRoZSB1cHN0cmVh bS1hc3NpZ25lZCBsYWJlbCBpbiB0aGUgUE1TSSBUdW5uZWwgPGJyPg0KJmd0OyBhdHRyaWJ1dGUg aXMgbm90IG5lZWRlZCB3aGVuIG11bHRpcGxlIGZsb3dzIGFyZSBiZWluZyB0cmFuc21pdHRlZA0K b24gYSA8YnI+DQomZ3Q7IHNpbmdsZSBMU1AsIGl0IGlzIG5lZWRlZCBvbmx5IHdoZW4gZmxvd3Mg ZnJvbSBtdWx0aXBsZSBWUE5zIGFyZSBhcmUNCjxicj4NCiZndDsgdHJhbnNtaXR0ZWQgb24gYSBz aW5nbGUgTFNQLiAmbmJzcDtJIGhhdmUgdG8gYWRtaXQgdGhhdCB1c2luZyBhIHNpbmdsZQ0KTVAy TVAgPGJyPg0KJmd0OyBMU1AgdG8gY2FycnkgdHJhZmZpYyBvZiBzZXZlcmFsIGRpZmZlcmVudCBW UE5zIGlzIG5vdCBhIHNjZW5hcmlvIHRoYXQNCjxicj4NCiZndDsgaGFzIGJlZW4gZ2l2ZW4gYSBs b3Qgb2YgYXR0ZW50aW9uLCBhbmQgd2lsbCBwcm9iYWJseSBvbmx5IHdvcmsgaWYNCihhKSA8YnI+ DQomZ3Q7IHRoZSBoaWVyYXJjaGljYWwgcGFydGl0aW9uZWQgbWV0aG9kIChzZWUgUkZDIDc1ODIp IGlzIHVzZWQsIGFuZCAoYikNCmFsbCA8YnI+DQomZ3Q7IHRob3NlIFZQTnMgaGF2ZSBWUkZzIGF0 IHRoZSByb290IG5vZGUuICZuYnNwO0J1dCBpdCdzIG5vdCBjbGVhciB0aGF0DQp0aGVyZSdzIDxi cj4NCiZndDsgYW55IHJlYWwgdmFsdWUgdG8gbXVsdGlwbGV4aW5nIHNldmVyYWwgVlBOcyBvbnRv IGEgc2luZ2xlIE1QMk1QIExTUC48YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhlcmUgaXMgYW5vdGhl ciB1c2Ugb2YgdXBzdHJlYW0tYXNzaWduZWQgbGFiZWxzIGRlc2NyaWJlZCBpbiBSRkMNCjc1ODIg PGJyPg0KJmd0OyAoJnF1b3Q7UEUgRGlzdGluZ3Vpc2hlciBsYWJlbHMmcXVvdDspLCBhbmQgdGhv c2UgYXJlIGFsd2F5cyBhc3NpZ25lZA0KYnkgdGhlIHJvb3QgPGJyPg0KJmd0OyBub2RlIG9mIHRo ZSBNUDJNUCBMU1AuPGJyPg0KPC90dD48L2ZvbnQ+DQo= --=_alternative 00356C1448257E92_=-- From nobody Thu Jul 30 07:27: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 AA2BE1A1A5B for ; Thu, 30 Jul 2015 07:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.597 X-Spam-Level: **** X-Spam-Status: No, score=4.597 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, MANGLED_BODY=2.3, MANGLED_LIST=2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id crgtTb7TeZrQ for ; Thu, 30 Jul 2015 07:27:34 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0743.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::743]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 424AB1A0218 for ; Thu, 30 Jul 2015 07:27:33 -0700 (PDT) Received: from AMSPR03MB599.eurprd03.prod.outlook.com (10.242.106.142) by AMSPR03MB597.eurprd03.prod.outlook.com (10.242.106.11) with Microsoft SMTP Server (TLS) id 15.1.225.19; Thu, 30 Jul 2015 14:27:13 +0000 Received: from AMSPR03MB599.eurprd03.prod.outlook.com ([10.242.106.142]) by AMSPR03MB599.eurprd03.prod.outlook.com ([10.242.106.142]) with mapi id 15.01.0225.018; Thu, 30 Jul 2015 14:27:14 +0000 From: Cameron Gray To: Robert Raszuk Thread-Topic: [Idr] draft-cgray-ietf-bgp-exceptions Thread-Index: AQHQyAp2wd520c9vvkyyd0OZ/VCmBZ3uycwAgABF1QCABQfxgA== Date: Thu, 30 Jul 2015 14:27:13 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2102) authentication-results: raszuk.net; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [80.76.208.201] x-microsoft-exchange-diagnostics: 1; AMSPR03MB597; 5:vBbgtnPQxa5A5gU8TwupCOx7E5YGvXnGBqrwOi+sjLqi2YVMt5351k46hWYAV/flXUCCBjmlhyr5C/oUZMjSPTc68WjNw/EiiqCdgH5QalQw2KIub/8jTkN77R37V5AnwXuy4qL5exx6SnyTkIvahQ==; 24:2tEYiPYIh/AIc43CdQeuPrNb+rd7up4+xfOlO8xpy43jo91NjLpOMuB/oR2mLbR9aOy2rJlr9H71VFVfDHNmM4/7tgzltmAHHaicvWxyXL8=; 20:zgLiNicYzaYMH6gXg/8dzjmXYMLRlRcOGUYQQd1PyT8RYa43/sOvbC76Id3yIJYEGkrFJZF925G694NAmH9ATg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR03MB597; amspr03mb597: X-MS-Exchange-Organization-RulesExecuted 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:AMSPR03MB597; BCL:0; PCL:0; RULEID:; SRVR:AMSPR03MB597; x-forefront-prvs: 06530126A4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(252514010)(5890100001)(50226001)(33656002)(110136002)(230783001)(5002640100001)(83716003)(62966003)(87936001)(102836002)(77156002)(74482002)(77096005)(66066001)(82746002)(2950100001)(50986999)(40100003)(76176999)(106116001)(19580395003)(86362001)(122556002)(2900100001)(92566002)(19580405001)(189998001)(46102003)(5001960100002)(36756003)(2656002); DIR:OUT; SFP:1102; SCL:1; SRVR:AMSPR03MB597; H:AMSPR03MB599.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: bangor.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jul 2015 14:27:13.9664 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c6474c55-a923-4d2a-9bd4-ece37148dbb2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR03MB597 Archived-At: Cc: "idr@ietf.org" , Cameron Gray Subject: Re: [Idr] draft-cgray-ietf-bgp-exceptions 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 Jul 2015 14:27:37 -0000 DQo+IE9uIDI3IEp1bCAyMDE1LCBhdCAxMDozNywgUm9iZXJ0IFJhc3p1ayA8cm9iZXJ0QHJhc3p1 ay5uZXQ+IHdyb3RlOg0KPg0KPiDigItDYW1lcm9uLOKAiw0KPg0KPiBUaGFuayB5b3UgZm9yIHJl cGx5aW5nLiAgSSBhbSBpbmRlZWQgYXdhcmUgb2YgRmxvd1NwZWMsIGhvd2V2ZXIgZGVzcGl0ZSBi ZWluZyBwdXQgZm9yd2FyZCBhcyBhIHByb3Bvc2VkIHN0YW5kYXJkIGluIDIwMDkgYWxtb3N0IHpl cm8gY29tbWVyY2lhbCBwcm92aWRlcnMgd2lsbCBvZmZlciBpdCAoYXQgbGVhc3QgaW4gdGhlIFVL L0VVIGFuZCBuTGF5ZXIvR1RUIHJlbW92ZWQgc3VwcG9ydCBmb3IgaXQgQXVndXN0IDIwMTMpLiAg SSB3YXMgdHJ5aW5nIHRvIHByb3Bvc2Ugc29tZXRoaW5nIG1vcmUgbGlnaHR3ZWlnaHQgdGhhdCBj b3VsZCBnYWluIGNyaXRpY2FsIG1hc3MgbW9yZSBxdWlja2x5IHRvIGdhaW4gaXRzIHV0aWxpdHku DQo+DQo+IEhhdmUgeW91IOKAi2RvbmUgYW5hbHlzaXMgYW5kIGNvbXBhcmlzb24gb2YgZmxvd3Nw ZWMgd2l0aCB5b3VyIHNvbHV0aW9uIHRvIGVzdGFibGlzaCB0aGUgYmFzZSBmb3IgdGhlIGFzc2Vy dGlvbiB0aGF0IHlvdXIgc29sdXRpb24gaXM6DQo+DQo+IGEpICJtb3JlIGxpZ2h0d2VpZ2h0IiB0 aGVuIFJGQzU1NzUNCj4NCj4gYikgd2lsbCBiZSBkZXBsb3llZCBtb3JlIHF1aWNrbHkgdGhlbiBS RkM1NTc1DQo+DQo+IGMpIGlzIGFzIHNlY3VyZSBhcyBSRkM1NTc1IHdpdGggYXV0b21hdGljIHZh bGlkYXRpb24NCj4NCj4gSSB3b3VsZCBsb3ZlIHRvIHNlZSBzdWNoIGRhdGEuDQo+DQo+IExpa2V3 aXNlIGluIGZhY3QgaXQgd291bGQgYmUgaGVscGZ1bCB0byBhbHNvIGNvbXBhcmUgeW91ciBzb2x1 dGlvbiB3aXRoIFJUQkguDQoNClNvcnJ5IHRvIHJlcGx5IGxhdGUgdG8gdGhpcywgSSBoYXZlIGJl Z3VuIHdvcmsgb24gdGhpcyBjb21wYXJpc29uIGJ1dCBpbiB0aGUgZm9ybSBvZiBhbiBhY2FkZW1p YyBwYXBlciB0byBhaWQgd2VpZ2h0IHRvIG15IHN0dWRpZXMuICBJIHdpbGwgc2hhcmUgdGhlIHJl c3VsdHMgb2YgdGhpcyB3aXRoIHRoZSBncm91cCBhcyBzb29uIGFzIGl0IGlzIGNvbXBsZXRlZC4N Cg0KUmVnYXJkcywNCg0KQ2FtZXJvbiBHcmF5DQpEb2N0b3JhbCBTdHVkZW50DQpTY2hvb2wgb2Yg Q29tcHV0ZXIgU2NpZW5jZQ0KDQpFbWFpbDogYy5ncmF5QGJhbmdvci5hYy51aw0KDQpCYW5nb3Ig VW5pdmVyc2l0eSwgQmFuZ29yLCBHd3luZWRkLCBMTDU3IDJERw0KDQoNClJoaWYgRWx1c2VuIEdv ZnJlc3RyZWRpZyAxMTQxNTY1IC0gUmVnaXN0ZXJlZCBDaGFyaXR5IE5vLiAxMTQxNTY1DQoNCkdh bGwgeSBuZWdlcyBlLWJvc3QgaG9uLCBhYyB1bnJoeXcgYXRvZGlhZGF1IGEgYW5mb253eWQgZ3lk YSBoaSwgZ3lubnd5cyBkZXVueWRkIGN5ZnJpbmFjaG9sIGFjIHdlZGkgZXUgYndyaWFkdSBpJ3cg ZGVmbnlkZGlvJ24gdW5pZyBnYW4geSBzYXdsIHkgY2F3c2FudCBldSBjeWZlaXJpbyBhdG8gKGF0 eW50KS4gT3MgeWR5Y2ggd2VkaSBkZXJieW4geSBuZWdlcyBlLWJvc3QgaG9uIHRyd3kgZ2FtZ3lt ZXJpYWQsIHJob3djaCB3eWJvZCBpJ3IgYW5mb253ciBhciB1bndhaXRoIGEgZGlsZXdjaCB5IG5l Z2VzLiBPcyBuYSBmd3JpYWR3eWQgYW5mb24geSBuZWdlcyBhdG9jaCBjaGksIHJoYWlkIGkgY2hp IGJlaWRpbyBhIGRlZm55ZGRpbywgY2FkdyBuZXUgZGRhdGdlbHUgdW5yaHl3IHd5Ym9kYWV0aCBh IGd5bmh3eXNpciB5bmRkaS4gTWFlIHVucmh5dyBmYXJuIG5ldSBzYWZid3ludCB5biBlaWRkbyBp J3Igc2F3bCBhJ2kgaGFuZm9ub2RkIHluIHVuaWcgYWMgbmlkIHl3IG8gYW5naGVucmFpZCB5biBj eW5yeWNoaW9saSBiYXJuIFByaWZ5c2dvbCBCYW5nb3IuIE5pZCB5dyBQcmlmeXNnb2wgQmFuZ29y IHluIGd3YXJhbnR1IGJvZCB5IG5lZ2VzIGUtYm9zdCBob24gbmV1IHVucmh5dyBhdG9kaWFkYXUg eW4gcmh5ZGQgcmhhZyBmaXJ5c2F1IG5ldSAxMDAlIHluIGRkaW9nZWwuIE9uaSBiYWkgZm9kIGh5 biB3ZWRpIGVpIGRkYXRnYW4geW4gdW5pb25neXJjaG9sIHluIG5oZXN0dW4geXIgZS1ib3N0LCBu aWQgYndyaWFkIHkgbmVnZXMgZS1ib3N0IGhvbiB5dyBmZnVyZmlvIGNvbnRyYWN0IHJod3ltb2wg LSBtYWUgcmhlc3RyIG8gbG9mbm9kd3lyIGF3ZHVyZG9kZWRpZyBhciBnYWVsIG8gU3d5ZGRmYSBD eWxsaWQgUHJpZnlzZ29sIEJhbmdvci4NCg0KVGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRz IG1heSBjb250YWluIGNvbmZpZGVudGlhbCBtYXRlcmlhbCBhbmQgaXMgc29sZWx5IGZvciB0aGUg dXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRo aXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBh bmQgZGVsZXRlIHRoaXMgZW1haWwuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGll bnQocyksIHlvdSBtdXN0IG5vdCB1c2UsIHJldGFpbiBvciBkaXNjbG9zZSBhbnkgaW5mb3JtYXRp b24gY29udGFpbmVkIGluIHRoaXMgZW1haWwuIEFueSB2aWV3cyBvciBvcGluaW9ucyBhcmUgc29s ZWx5IHRob3NlIG9mIHRoZSBzZW5kZXIgYW5kIGRvIG5vdCBuZWNlc3NhcmlseSByZXByZXNlbnQg dGhvc2Ugb2YgQmFuZ29yIFVuaXZlcnNpdHkuIEJhbmdvciBVbml2ZXJzaXR5IGRvZXMgbm90IGd1 YXJhbnRlZSB0aGF0IHRoaXMgZW1haWwgb3IgYW55IGF0dGFjaG1lbnRzIGFyZSBmcmVlIGZyb20g dmlydXNlcyBvciAxMDAlIHNlY3VyZS4gVW5sZXNzIGV4cHJlc3NseSBzdGF0ZWQgaW4gdGhlIGJv ZHkgb2YgdGhlIHRleHQgb2YgdGhlIGVtYWlsLCB0aGlzIGVtYWlsIGlzIG5vdCBpbnRlbmRlZCB0 byBmb3JtIGEgYmluZGluZyBjb250cmFjdCAtIGEgbGlzdCBvZiBhdXRob3Jpc2VkIHNpZ25hdG9y aWVzIGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBCYW5nb3IgVW5pdmVyc2l0eSBGaW5hbmNlIE9mZmlj ZS4NCg0K From nobody Thu Jul 30 08:35: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 8BD1F1AC41D for ; Thu, 30 Jul 2015 08:35: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 br5y35EpVeBF for ; Thu, 30 Jul 2015 08:35:37 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 265031A9059 for ; Thu, 30 Jul 2015 08:35:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2780; q=dns/txt; s=iport; t=1438270537; x=1439480137; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=R7JthfzfAOwIzjNvw4GohQJjJiW/fWvFOn/Qj0yXHQQ=; b=JMDM9Liaq5qZ55SWyy/arNXKKreTnHWA1/YWsiAoFQ15ej0w422Y5DW0 9vGx1si6g8FoO2xDJ4rjN0uQ4yOLrebt+sXp+qIRQys/xkiJ8Eq48S8r4 1PqNy6GWLxj4+qiMPr7kUKGYqhuTdZQYGBiuTmvBOl/wKb/YpXIq/rgw6 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A1AwAuQ7pV/4YNJK1bgxqBPQaDHbh5CYd8AhyBHjgUAQEBAQEBAYEKhCMBAQEDASMRRQULAgEGAhgCAiMDAgICMBQBEAIEDgWIJgibeZ0ZlgwBAQEBAQEBAQEBAQEBAQEBAQEBAQEXgSKKLIQ1AQFQB4JpL4EUAQSUdwGKGoIugUcVk3mDZCaDfW+BDjqBBAEBAQ X-IronPort-AV: E=Sophos;i="5.15,577,1432598400"; d="scan'208";a="173947240" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-4.cisco.com with ESMTP; 30 Jul 2015 15:35:36 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t6UFZa9U026025 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 Jul 2015 15:35:36 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.37]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0195.001; Thu, 30 Jul 2015 10:35:36 -0500 From: "Acee Lindem (acee)" To: Eric Wu Thread-Topic: Comment on flow-spec Routing Policy Distribution (RPD) from IDR WG Meeting Thread-Index: AQHQyT1rvD/ETjWosE+dlnbCcyOtB530F+UAgABkMoA= Date: Thu, 30 Jul 2015 15:35:36 +0000 Message-ID: <35B52CA6-D07D-47BB-AA00-5DE7C99FE12C@cisco.com> References: <60FE2F7A-8C22-4732-8691-36D3903BDCDB@cisco.com> <0F26584357FD124DB93F1535E4B0A6505FC18F65@szxema508-mbx.china.huawei.com> In-Reply-To: <0F26584357FD124DB93F1535E4B0A6505FC18F65@szxema508-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.152.204] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: IDR WG List Subject: Re: [Idr] Comment on flow-spec Routing Policy Distribution (RPD) from IDR WG Meeting 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 Jul 2015 15:35:38 -0000 SGkgRXJpYywgDQoNCj4gT24gSnVsIDMwLCAyMDE1LCBhdCA1OjM2IEFNLCBXdW5hbiAoRXJpYykg PGVyaWMud3VAaHVhd2VpLmNvbT4gd3JvdGU6DQo+IA0KPiBBY2VlLA0KPiANCj4gVGhhbmsgeW91 IHNvIHRob3VnaHRmdWxseSB0byBwdXQgdGhpcyBvbiB0aGUgbGlzdCwgc29ycnkgZm9yIGRpZG4n dCB0YWtlIGFsbCB5b3VyIHBvaW50cyBkdXJpbmcgSURSIG1lZXRpbmcuDQo+IFRoYXQgaXMgdGhl IHJlYXNvbiB3aHkgaXQgd2lsbCBiZSBiZXR0ZXIgdG8gaGF2ZSB0aGUgZGlhbG9ndWUgZGlzcGxh eWVkIGF0IHRoZSBzY3JlZW4gYm90dG9tIHdoZW4geW91IGFyZSB3YXRjaGluZyBhIFRWIHNob3cu DQo+IA0KPiBZb3VyIG9ic2VydmF0aW9uIG9uIG91dGJvdW5kIGlzIGNvcnJlY3QsIGFuZCB5ZXMs IGl0IGlzIGEgZGlmZmVyZW50IHNjZW5hcmlvIGZyb20gRERPUy4NCj4gVGhlIG1vdGl2YXRpb24g YmVoaW5kIHRoaXMgZHJhZnQgaXMgdGhhdCB3ZSBtYXkgbmVlZCBvbmUgbWVjaGFuaXNtIHRvIHNv bHZlIGJvdGggb3V0Ym91bmQgYW5kIGluYm91bmQgdHJhZmZpYyBlbmdpbmVlcmluZyBvbiBkaWZm ZXJlbnQgbmV0d29ya3MsIGV2ZW4gdGhvc2Ugd2l0aG91dCBNUExTIGRhdGEgcGxhbmUuDQoNClRo YXQgaXMgaG93IEkgdW5kZXJzdG9vZCB0aGUgc3VpdGUgb2YgZHJhZnRzIHByZXNlbnRlZCBvbiBG cmlkYXkgLSBiYXNpY2FsbHkgdXNpbmcgdGhlIEZsb3ctU3BlYyBTQUZJIGZvciBUcmFmZmljIEVu Z2luZWVyaW5nLiANCg0KDQo+IA0KPiBCeSB0aGUgd2F5LCBJIGNoYW5nZWQgY2MgZnJvbSBpZHIt cmVxdWVzdEBpZXRmLm9yZyB0byBpZHJAaWV0Zi5vcmcuIEkgYXNzdW1lZCB0aGlzIGlzIGEgdHlw byBzaW5jZSB5b3VyIG1haWwgZGlkbid0IHNob3cgaW4gdGhlIGxpc3QuDQoNClllcyAtIGRpZG7i gJl0IG5vdGljZSB0aGUgYXV0by1jb21wbGV0aW9uIG9mIHRoZSB3cm9uZyBsaXN0LiANCg0KVGhh bmtzLA0KQWNlZSANCg0KDQo+IA0KPiBSZWdhcmRzDQo+IEVyaWMNCj4gDQo+IC0tLS0t6YKu5Lu2 5Y6f5Lu2LS0tLS0NCj4g5Y+R5Lu25Lq6OiBBY2VlIExpbmRlbSAoYWNlZSkgW21haWx0bzphY2Vl QGNpc2NvLmNvbV0gDQo+IOWPkemAgeaXtumXtDogMjAxNeW5tDfmnIgyOOaXpSAyMTo1OA0KPiDm lLbku7bkuro6IFd1bmFuIChFcmljKQ0KPiDmioTpgIE6IGlkci1yZXF1ZXN0QGlldGYub3JnDQo+ IOS4u+mimDogQ29tbWVudCBvbiBmbG93LXNwZWMgUm91dGluZyBQb2xpY3kgRGlzdHJpYnV0aW9u IChSUEQpIGZyb20gSURSIFdHIE1lZXRpbmcgDQo+IA0KPiBIaSBFcmljLCANCj4gDQo+IExldCBt ZSBleHBsYWluIHRoZSBjb21tZW50IEkgd2FzIHRyeWluZyB0byBhcnRpY3VsYXRlIGluIElEUiBt ZWV0aW5nLiBGbG93IFNwZWMgTkxSSSBoYXMgdHJhZGl0aW9uYWxseSBiZWVuIHVzZWQgZm9yIHRy YWZmaWMgZmlsdGVyaW5nIHRvIG1pdGlnYXRlIERET1MgYXR0YWNrcy4gIE5vdyB0aGF0IGl0IGlz IGJlaW5nIHByb3Bvc2VkIGZvciBvdXRib3VuZCB0cmFmZmljIGNvbnRyb2wsIHRoZSBwb2xpY3kg Y29udHJvbGxlciB3aWxsIGFsc28gbmVlZCB0byBwZWVyIHdpdGggYWxsIHRoZSBlZ3Jlc3Mgcm91 dGVycyB0byBsZWFybiB0aGUgYXZhaWxhYmxlIElQdjQvSVB2NiBwYXRocy4gVGhpcyBpcyBuZWNl c3Nhcnkgc28gdGhhdCB0aGUgcG9saWN5IGNvbnRyb2xsZXIgZG9lc27igJl0IGluc3RhbGwgYSBm aWxlciBydWxlIHRoYXQgd2lsbCBibGFja2hvbGUgdHJhZmZpYy4gVGhpcyBtYXkgc2VlbSBvYnZp b3VzIGJ1dCB0aGUgaXQgaXMgYSBkaWZmZXJlbnQgc2NlbmFyaW8gZnJvbSB0b2RheeKAmXMgUkZD IDU1NzUgZGVwbG95bWVudHMuIA0KPiANCj4gSSB0aGluayBzZWdtZW50IHJvdXRpbmcgaXMgYSBi ZXR0ZXIgd2F5IHRvIHNvbHZlIHRoaXMgcHJvYmxlbSBidXQgdGhlbiB0aGlzIGlzIG5vdCBhbiBl bnRpcmVseSB1bmJpYXNlZCBvcGluaW9uIHNpbmNlIEnigJltIHdvcmtpbmcgb24gc2VnbWVudCBy b3V0aW5nLiANCj4gDQo+IFRoYW5rcywNCj4gQWNlZSANCg0K From nobody Fri Jul 31 02:34: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 9A7311A0078; Fri, 31 Jul 2015 02:34:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -81.76 X-Spam-Level: X-Spam-Status: No, score=-81.76 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLACK=20, 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 NidH5DQb4G5a; Fri, 31 Jul 2015 02:34:24 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id D4B8E1A0074; Fri, 31 Jul 2015 02:34:23 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 95FD869038489; Fri, 31 Jul 2015 17:34:19 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id E39036C8F80CE; Fri, 31 Jul 2015 17:34:18 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id t6V9Y6Jk092811; Fri, 31 Jul 2015 17:34:06 +0800 (GMT-8) (envelope-from zhang.zheng@zte.com.cn) In-Reply-To: <55BA41A8.1050305@juniper.net> To: Eric C Rosen MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: zhang.zheng@zte.com.cn Date: Fri, 31 Jul 2015 17:33:54 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2015-07-31 17:34:06, Serialize complete at 2015-07-31 17:34:06 Content-Type: multipart/alternative; boundary="=_alternative 00348EE148257E93_=" X-MAIL: mse01.zte.com.cn t6V9Y6Jk092811 Archived-At: Cc: 'IDR WG' , Idr , Susan Hares Subject: Re: [Idr] Comment on draft-zhang-idr-upstream-assigned-label-solution 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, 31 Jul 2015 09:34:25 -0000 This is a multipart message in MIME format. --=_alternative 00348EE148257E93_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgRXJpYywNCg0KDQpFcmljIEMgUm9zZW4gPGVyb3NlbkBqdW5pcGVyLm5ldD4g0LTT2iAyMDE1 LzA3LzMwIDIzOjI0OjI0Og0KDQo+IE9uIDcvMzAvMjAxNSA1OjQyIEFNLCB6aGFuZy56aGVuZ0B6 dGUuY29tLmNuIHdyb3RlOg0KPiANCj4gPiAgICAgIFJlZmVyIHRvIFJGQzUzMzEsIHRoZSBjb250 ZXh0LXNwZWNpZmljIGxhYmVsIGNhbiBiZSBhdXRvIA0KZ2VuZXJhdGVkIG9yDQo+ID4gbWFudWFs bHkgY29uZmlndXJlZC4gSW4gSVB2NiBlbnZpcm9ubWVudCwgbWFudWFsbHkgY29udHJvbCBpcyAN CnJlcXVpcmVkLg0KPiANCj4gQXJlIHlvdSByZWZlcnJpbmcgdG8gU2VjdGlvbiA4IG9mIFJGQyA1 MzMxLCAiQ29udGV4dCBMYWJlbCBvbiBMQU5zIj8gDQo+IFRoZSBsYWJlbHMgZGlzY3Vzc2VkIHRo ZXJlIGFyZSAyMC1iaXQgdmFsdWVzIHRoYXQgdW5pcXVlbHkgaWRlbnRpZnkgYSANCj4gcm91dGVy IHdpdGhpbiB0aGUgY29udGV4dCBvZiBhIHBhcnRpY3VsYXIgTEFOLiAgVGhlc2UgYXJlIHJlYWxs eSBhIGZvcm0gDQo+IG9mIGRvbWFpbi13aWRlIGxhYmVsLCB3aXRoIHRoZSAiZG9tYWluIiBiZWlu ZyBhIHNpbmdsZSBMQU4uICBBcyBJIHNhaWQgDQo+IGVhcmxpZXIsIHlvdXIgZHJhZnQgcmVhbGx5 IHNlZW1zIGFpbWVkIGF0IHRoZSBwcm9ibGVtIG9mIGR5bmFtaWNhbGx5IA0KPiBhc3NpZ25pbmcg ZG9tYWluLXdpZGUgdW5pcXVlIGxhYmVscywgc28gSSB3b3VsZCBhZ3JlZSB0aGF0IGFzc2lnbmlu ZyANCj4gY29udGV4dCBsYWJlbHMgb24gTEFOcyBpcyBhIHBvc3NpYmxlIGFwcGxpY2F0aW9uLg0K PiANCj4gTm90ZSB0aGF0IHRoZSBtYXRlcmlhbCBmcm9tIFNlY3Rpb24gOCBvZiBSRkMgNTMzMSBp cyBvbmx5IGFwcGxpY2FibGUgaWYgDQo+IHlvdSBhcmUgdXNpbmcgZXRoZXJuZXQgbXVsdGljYXN0 IGZyYW1lcyB0byBjYXJyeSBNUExTIG11bHRpY2FzdCBwYWNrZXRzLiANCg0KPiAgIEknbSBub3Qg c3VyZSB3aGV0aGVyIHRoZXJlIGFyZSBhY3R1YWxseSBhbnkgZGVwbG95bWVudHMgb2YgdGhhdC4N Cj4gDQo+ID4gQW5kIHRoZSBuZXR3b3JrIHNlcnZpY2UgdGhhdCBpcyBzdXBwb3NlZCBieSBMM1ZQ Tiwgbm90IG9ubHkgaW5jbHVkZSANCk1WUE4sDQo+ID4gYnV0IGFsc28gaW5jbHVkZSBFVlBOLCBE QyBpbnRlcmNvbm5lY3Rpb24sIGFuZCBzbyBvbi4NCj4gDQo+IFRoZSBMQU4gY29udGV4dCBsYWJl bCBvbmx5IGlkZW50aWZpZXMgYSByb3V0ZXIsIGl0IGlzIG5vdCANCj4gc2VydmljZS1zcGVjaWZp Yy4gIFNvIHlvdSBvbmx5IG5lZWQgb25lIHBlciBub2RlIHBlciBMQU4uICAgIChJIHRoaW5rIA0K PiBpdCdzIGEgbG90IGxpa2UgYSAibm9kZSBTSUQiIGluIFNQUklORyBvciBhICJCRklSLWlkIiBp biBCSUVSLikNCj4gDQotLS1JIGRvbid0IHRoaW5rIHRoYXQgdGhlIGNvbnRleHQgbGFiZWwgaXMg YSBsb3QgbGlrZSBTSUQgb3IgQkZSLWlkLiBUaGUgDQpjb250ZXh0IA0KbGFiZWwgY2FuIGJlIHVz ZWQgdG8gZGlzdGluZ3Vpc2ggdGhlIHNlcnZpY2UsIHN1Y2ggbGlrZSBNVlBOLCBFVlBOLCBEQyAN CmludGVyY29ubmVjdGlvbiwgVnhMQU4gYW5kIHNvIG9uLiBTbyBvbmx5IG9uZSBjb250ZXh0IGxh YmVsIGlkZW50aWZpZXMgYSANCnJvdXRlcg0KaXMgbm90IGVub3VnaC4gTW9yZSBjb250ZXh0IGxh YmVscyBhcmUgbmVlZGVkIGZvciBkaWZmZXJlbnQgc2VydmljZXMgb24gYSANCnJvdXRlci4NCg0K PiBUaGUgaXNzdWUgb2YgaG93IGJlc3QgdG8gYXNzaWduIGFuIGlkZW50aWZpZXIgdGhhdCBpcyB1 bmlxdWUgd2l0aGluIGEgDQo+IGNlcnRhaW4gc2NvcGUgaXMgYW4gaXNzdWUgdGhhdCBjb21lcyB1 cCBpbiBtYW55IGNvbnRleHRzLCB0aG91Z2ggdXN1YWxseSANCg0KPiBpdCBpcyBJUCBhZGRyZXNz ZXMgcmF0aGVyIHRoYW4gMjAtYml0IGlkZW50aWZpZXJzIHRoYXQgbmVlZCB0byBiZSANCj4gYXNz aWduZWQuICBUaGVyZSBhcmUgYSBsb3Qgb2YgcHJpb3Igc29sdXRpb25zIHRoYXQgY291bGQgYmUg Y29uc2lkZXJlZCwgDQo+IGdlbmVyYWxseSBub3QgcmVxdWlyaW5nIGVpdGhlciBCR1Agb3IgdGlt ZSBzeW5jaHJvbml6YXRpb24uDQo+IA0KPiA+IEFuZCB0aGUgcDJtcCBhbmQgbXAybXAgdHVubmVs IG1heSBiZSB1c2VkIHRvIHRyYW5zZmVyIGV4dHJhbmV0DQo+ID4gZmxvdy4gV2hlbg0KPiA+IGRp ZmZlcmVudCBtdWx0aWNhc3QgZmxvd3Mgd2hpY2ggYXJlIGZvcndhcmRlZCB0byByZWNlaXZlcnMg aW4gDQpkaWZmZXJlbnQgVlBODQo+ID4gYXJlIG1peGVkIGludG8gb25lIFAtdHVubmVsLCBhcmUg dGhlcmUgbW9yZSBjb25mbGljdD8NCj4gDQo+IE1WUE4gZXh0cmFuZXQgZG9lcyBub3QgaW1wb3Nl IGFueSBwYXJ0aWN1bGFyIHJlcXVpcmVtZW50IGZvciANCj4gdXBzdHJlYW0tYXNzaWduZWQgbGFi ZWxzIG9yIGRvbWFpbi13aWRlIGxhYmVscy4NCg0KLS0tVGhlIGRpZmZlcmVudCBmbG93cyBzaGFy ZSBvbmUgUC10dW5uZWwsIHRoYXQgd2lsbCBkZWNyZWFzZSB0aGUgbnVtYmVyIA0Kb2YgUC10dW5u ZWxzLg0KQW5kIGl0IHdpbGwgbWFrZSBtb3JlIGVhc2llciBmb3Igc2VydmljZSBhbmQgcG9saWN5 IGRlcGxveW1lbnQgb2YgDQpvcGVyYXRvcnMuIE1heWJlIE1WUE4NCmV4dHJhbmV0IHNob3VsZCBj b25zaWRlciB0aGUgdXNlIG9mIHVwc3RyZWFtLWFzc2lnbmVkIGxhYmVscy4gDQoNClNhbmR5DQoN Cg== --=_alternative 00348EE148257E93_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEVyaWMsPGJyPg0KPC9mb250 Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mj48dHQ+RXJpYyBDIFJvc2VuICZsdDtlcm9zZW5AanVu aXBlci5uZXQmZ3Q7INC009ogMjAxNS8wNy8zMA0KMjM6MjQ6MjQ6PGJyPg0KPGJyPg0KJmd0OyBP biA3LzMwLzIwMTUgNTo0MiBBTSwgemhhbmcuemhlbmdAenRlLmNvbS5jbiB3cm90ZTo8YnI+DQom Z3Q7IDxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwO1JlZmVyIHRvIFJGQzUzMzEs IHRoZSBjb250ZXh0LXNwZWNpZmljIGxhYmVsDQpjYW4gYmUgYXV0byBnZW5lcmF0ZWQgb3I8YnI+ DQomZ3Q7ICZndDsgbWFudWFsbHkgY29uZmlndXJlZC4gSW4gSVB2NiBlbnZpcm9ubWVudCwgbWFu dWFsbHkgY29udHJvbCBpcw0KcmVxdWlyZWQuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEFyZSB5b3Ug cmVmZXJyaW5nIHRvIFNlY3Rpb24gOCBvZiBSRkMgNTMzMSwgJnF1b3Q7Q29udGV4dCBMYWJlbCBv bg0KTEFOcyZxdW90Oz8gPGJyPg0KJmd0OyBUaGUgbGFiZWxzIGRpc2N1c3NlZCB0aGVyZSBhcmUg MjAtYml0IHZhbHVlcyB0aGF0IHVuaXF1ZWx5IGlkZW50aWZ5DQphIDxicj4NCiZndDsgcm91dGVy IHdpdGhpbiB0aGUgY29udGV4dCBvZiBhIHBhcnRpY3VsYXIgTEFOLiAmbmJzcDtUaGVzZSBhcmUg cmVhbGx5DQphIGZvcm0gPGJyPg0KJmd0OyBvZiBkb21haW4td2lkZSBsYWJlbCwgd2l0aCB0aGUg JnF1b3Q7ZG9tYWluJnF1b3Q7IGJlaW5nIGEgc2luZ2xlIExBTi4NCiZuYnNwO0FzIEkgc2FpZCA8 YnI+DQomZ3Q7IGVhcmxpZXIsIHlvdXIgZHJhZnQgcmVhbGx5IHNlZW1zIGFpbWVkIGF0IHRoZSBw cm9ibGVtIG9mIGR5bmFtaWNhbGx5DQo8YnI+DQomZ3Q7IGFzc2lnbmluZyBkb21haW4td2lkZSB1 bmlxdWUgbGFiZWxzLCBzbyBJIHdvdWxkIGFncmVlIHRoYXQgYXNzaWduaW5nDQo8YnI+DQomZ3Q7 IGNvbnRleHQgbGFiZWxzIG9uIExBTnMgaXMgYSBwb3NzaWJsZSBhcHBsaWNhdGlvbi48YnI+DQom Z3Q7IDxicj4NCiZndDsgTm90ZSB0aGF0IHRoZSBtYXRlcmlhbCBmcm9tIFNlY3Rpb24gOCBvZiBS RkMgNTMzMSBpcyBvbmx5IGFwcGxpY2FibGUNCmlmIDxicj4NCiZndDsgeW91IGFyZSB1c2luZyBl dGhlcm5ldCBtdWx0aWNhc3QgZnJhbWVzIHRvIGNhcnJ5IE1QTFMgbXVsdGljYXN0IHBhY2tldHMu DQo8YnI+DQomZ3Q7ICZuYnNwOyBJJ20gbm90IHN1cmUgd2hldGhlciB0aGVyZSBhcmUgYWN0dWFs bHkgYW55IGRlcGxveW1lbnRzIG9mDQp0aGF0Ljxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7IEFu ZCB0aGUgbmV0d29yayBzZXJ2aWNlIHRoYXQgaXMgc3VwcG9zZWQgYnkgTDNWUE4sIG5vdCBvbmx5 IGluY2x1ZGUNCk1WUE4sPGJyPg0KJmd0OyAmZ3Q7IGJ1dCBhbHNvIGluY2x1ZGUgRVZQTiwgREMg aW50ZXJjb25uZWN0aW9uLCBhbmQgc28gb24uPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoZSBMQU4g Y29udGV4dCBsYWJlbCBvbmx5IGlkZW50aWZpZXMgYSByb3V0ZXIsIGl0IGlzIG5vdCA8YnI+DQom Z3Q7IHNlcnZpY2Utc3BlY2lmaWMuICZuYnNwO1NvIHlvdSBvbmx5IG5lZWQgb25lIHBlciBub2Rl IHBlciBMQU4uICZuYnNwOw0KJm5ic3A7KEkgdGhpbmsgPGJyPg0KJmd0OyBpdCdzIGEgbG90IGxp a2UgYSAmcXVvdDtub2RlIFNJRCZxdW90OyBpbiBTUFJJTkcgb3IgYSAmcXVvdDtCRklSLWlkJnF1 b3Q7DQppbiBCSUVSLik8YnI+DQomZ3Q7IDwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj48 dHQ+LS0tSSBkb24ndCB0aGluayB0aGF0IHRoZSBjb250ZXh0IGxhYmVsIGlzIGEgbG90IGxpa2UN ClNJRCBvciBCRlItaWQuIFRoZSBjb250ZXh0IDwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9 Mj48dHQ+bGFiZWwgY2FuIGJlIHVzZWQgdG8gZGlzdGluZ3Vpc2ggdGhlIHNlcnZpY2UsIHN1Y2gN Cmxpa2UgTVZQTiwgRVZQTiwgREMgPC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD5p bnRlcmNvbm5lY3Rpb24sIFZ4TEFOIGFuZCBzbyBvbi4gU28gb25seSBvbmUgY29udGV4dA0KbGFi ZWwgaWRlbnRpZmllcyBhIHJvdXRlcjwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+ aXMgbm90IGVub3VnaC4gTW9yZSBjb250ZXh0IGxhYmVscyBhcmUgbmVlZGVkIGZvcg0KZGlmZmVy ZW50IHNlcnZpY2VzIG9uIGEgcm91dGVyLjwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj48 dHQ+PGJyPg0KJmd0OyBUaGUgaXNzdWUgb2YgaG93IGJlc3QgdG8gYXNzaWduIGFuIGlkZW50aWZp ZXIgdGhhdCBpcyB1bmlxdWUgd2l0aGluDQphIDxicj4NCiZndDsgY2VydGFpbiBzY29wZSBpcyBh biBpc3N1ZSB0aGF0IGNvbWVzIHVwIGluIG1hbnkgY29udGV4dHMsIHRob3VnaCB1c3VhbGx5DQo8 YnI+DQomZ3Q7IGl0IGlzIElQIGFkZHJlc3NlcyByYXRoZXIgdGhhbiAyMC1iaXQgaWRlbnRpZmll cnMgdGhhdCBuZWVkIHRvIGJlDQo8YnI+DQomZ3Q7IGFzc2lnbmVkLiAmbmJzcDtUaGVyZSBhcmUg YSBsb3Qgb2YgcHJpb3Igc29sdXRpb25zIHRoYXQgY291bGQgYmUgY29uc2lkZXJlZCwNCjxicj4N CiZndDsgZ2VuZXJhbGx5IG5vdCByZXF1aXJpbmcgZWl0aGVyIEJHUCBvciB0aW1lIHN5bmNocm9u aXphdGlvbi48YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0OyBBbmQgdGhlIHAybXAgYW5kIG1wMm1w IHR1bm5lbCBtYXkgYmUgdXNlZCB0byB0cmFuc2ZlciBleHRyYW5ldDxicj4NCiZndDsgJmd0OyBm bG93LiBXaGVuPGJyPg0KJmd0OyAmZ3Q7IGRpZmZlcmVudCBtdWx0aWNhc3QgZmxvd3Mgd2hpY2gg YXJlIGZvcndhcmRlZCB0byByZWNlaXZlcnMgaW4NCmRpZmZlcmVudCBWUE48YnI+DQomZ3Q7ICZn dDsgYXJlIG1peGVkIGludG8gb25lIFAtdHVubmVsLCBhcmUgdGhlcmUgbW9yZSBjb25mbGljdD88 YnI+DQomZ3Q7IDxicj4NCiZndDsgTVZQTiBleHRyYW5ldCBkb2VzIG5vdCBpbXBvc2UgYW55IHBh cnRpY3VsYXIgcmVxdWlyZW1lbnQgZm9yIDxicj4NCiZndDsgdXBzdHJlYW0tYXNzaWduZWQgbGFi ZWxzIG9yIGRvbWFpbi13aWRlIGxhYmVscy48L3R0PjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBz aXplPTI+PHR0Pi0tLVRoZSBkaWZmZXJlbnQgZmxvd3Mgc2hhcmUgb25lIFAtdHVubmVsLCB0aGF0 IHdpbGwNCmRlY3JlYXNlIHRoZSBudW1iZXIgb2YgUC10dW5uZWxzLjwvdHQ+PC9mb250Pg0KPGJy Pjxmb250IHNpemU9Mj48dHQ+QW5kIGl0IHdpbGwgbWFrZSBtb3JlIGVhc2llciBmb3Igc2Vydmlj ZSBhbmQgcG9saWN5DQpkZXBsb3ltZW50IG9mIG9wZXJhdG9ycy4gTWF5YmUgTVZQTjwvdHQ+PC9m b250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+ZXh0cmFuZXQgc2hvdWxkIGNvbnNpZGVyIHRoZSB1 c2Ugb2YgdXBzdHJlYW0tYXNzaWduZWQNCmxhYmVscy4gPC90dD48L2ZvbnQ+DQo8YnI+DQo8YnI+ PGZvbnQgc2l6ZT0yPjx0dD5TYW5keTxicj4NCjwvdHQ+PC9mb250Pg0K --=_alternative 00348EE148257E93_=-- From nobody Fri Jul 31 07: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 2DE901A889D for ; Fri, 31 Jul 2015 07:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=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 GjeYi94yzpkJ for ; Fri, 31 Jul 2015 07:03:54 -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 F416E1A8898 for ; Fri, 31 Jul 2015 07:03:53 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 50B592AC555; Fri, 31 Jul 2015 16:03:52 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.31]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 31B3838407D; Fri, 31 Jul 2015 16:03:52 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM22.corporate.adroot.infra.ftgroup ([fe80::8c90:f4e9:be28:2a1%19]) with mapi id 14.03.0248.002; Fri, 31 Jul 2015 16:03:52 +0200 From: To: "Dongjie (Jimmy)" Thread-Topic: draft-decraene-idr-next-hop-capability-01.txt Thread-Index: AdC4JKDYgB3/Q9Q9R2OEO/XZ5rMOTwF5qxMQA2KvBIA= Date: Fri, 31 Jul 2015 14:03:52 +0000 Message-ID: <31030_1438351432_55BB8048_31030_12466_1_53C29892C857584299CBF5D05346208A0F616998@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <29278_1436213631_559AE17F_29278_100_1_53C29892C857584299CBF5D05346208A0F5DF256@OPEXCLILM21.corporate.adroot.infra.ftgroup> <76CD132C3ADEF848BD84D028D243C92774298311@nkgeml512-mbx.china.huawei.com> In-Reply-To: <76CD132C3ADEF848BD84D028D243C92774298311@nkgeml512-mbx.china.huawei.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.7.31.132415 Archived-At: Cc: idr wg list Subject: Re: [Idr] draft-decraene-idr-next-hop-capability-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 14:03:57 -0000 SGkgSmllLA0KDQpUaGFua3MgZm9yIHlvdXIgY2FyZWZ1bCByZWFkaW5nIGFuZCBmZWVkYmFja3Mu DQpTb3JyeSBmb3IgdGhlIGRlbGF5Lg0KDQpQbGVhc2Ugc2VlIGlubGluZSBbQnJ1bm9dDQoNCj4g RnJvbTogRG9uZ2ppZSAoSmltbXkpIFttYWlsdG86amllLmRvbmdAaHVhd2VpLmNvbV0gPiBTZW50 OiBUdWVzZGF5LCBKdWx5IDE0LCAyMDE1IDEwOjI5IEFNDQo+IA0KPiBIaSBCcnVubywNCj4gDQo+ IEkndmUgcmVhZCB0aGlzIGRyYWZ0IGFuZCBoZXJlIGFyZSBzb21lIGNvbW1lbnRzOg0KPiANCj4g c2VjdGlvbiAxLg0KPiANCj4gQ3VycmVudGx5IGl0IHNheXMgIiBUaGlzIGF0dHJpYnV0ZSBpcyBk ZWxldGVkIHdoZW4gdGhlIEJHUCBOZXh0IEhvcCBpcw0KPiBjaGFuZ2VkLiINCj4gDQo+IEFjY29y ZGluZyB0byB0aGUgc3BlY2lmaWNhdGlvbiBpbiBzZWN0aW9uIDMsIHRvIG1ha2UgaXQgY29tcGxl dGUgaXQgaXMgYmV0dGVyIHRvDQo+IGFkZCAiQSBuZXcgTmV4dC1Ib3AgQ2FwYWJpbGl0aWVzIGF0 dHJpYnV0ZSBNQVkgYmUgYWRkZWQgZWFjaCB0aW1lIHRoZQ0KPiBCR1AgTmV4dCBIb3AgaXMgY2hh bmdlZCB0byByZWZsZWN0IHRoZSBjYXBhYmlsaXRpZXMgb2YgdGhlIG5ldyBOZXh0IEhvcC4iDQoN CltCcnVub10gWW91IGFyZSBjb3JyZWN0Lg0KUHJvcG9zZWQgbmV3IHRleHQ6ICJXaGVuIHRoZSBC R1AgTmV4dCBIb3AgaXMgY2hhbmdlZCwgdGhpcyBhdHRyaWJ1dGUgaXMgZGVsZXRlZCBvciBwb3Nz aWJseSBtb2RpZmllZCB0byB0YWtlIGludG8gYWNjb3VudCB0aGUgY2FwYWJpbGl0aWVzIG9mIHRo ZSBuZXcgQkdQIE5leHQtSG9wLiINCiANCj4gc2VjdGlvbiA2Lg0KPiANCj4gSXQgc2F5cyAiQSBC R1Agc3BlYWtlciBTIHRoYXQgc2VuZHMgYW4gVVBEQVRFIHdpdGggdGhlIEJHUCBOZXh0LUhvcCBO SA0KPiBNQVkgaW5jbHVkZSB0aGUgRW50cm9weSBMYWJlbCBOZXh0LUhvcCBDYXBhYmlsaXR5IG9u bHkgaWYgLi4uIg0KPiANCj4gQWNjb3JkaW5nIHRvIHRoZSBjb25kaXRpb25zIG9mIGluY2x1ZGlu ZyB0aGUgZW50cm9weSBsYWJlbCBuZXh0IGhvcCBjYXBhYmlsaXR5LA0KPiBpdCBhY3R1YWxseSBy ZWZsZWN0cyB0aGUgZW50cm9weSBsYWJlbCBjYXBhYmlsaXR5IG9mIHRoZSB3aG9sZSBkb3duc3Ry ZWFtDQo+IHBhdGguDQoNCltCcnVub10gWW91IGFyZSBjb3JyZWN0Lg0KVGhpcyBpcyBpbmxpbmUg d2l0aCB3aGF0IFJGQyA2NzkwIG9yaWdpbmFsbHkgZGVmaW5lZCBmb3IgdGhlIEJHUCBFbnRyb3B5 IExhYmVsIENhcGFiaWxpdHkgYXR0cmlidXRlIChsYXRlciBkZXByZWNhdGVkIGluIFJGQyA3NDQ3 KQ0KDQo+IFRvIG1ha2UgdGhpcyB3b3JrLCBpdCB3b3VsZCByZXF1aXJlIHRoYXQgZWFjaCBob3Ag YWxvbmcgdGhlIHBhdGgNCj4gaW5jbHVkZSB0aGUgRW50cm9weSBMYWJlbCBOZXh0LUhvcCBDYXBh YmlsaXR5IGluIGl0cyB1cGRhdGUgaWYgaXQgbWVldHMgdGhlc2UNCj4gY29uZGl0aW9ucy4gVGh1 cyBJJ2Qgc3VnZ2VzdCB0byByZXBsYWNlIHRoZSAiTUFZIiBoZXJlIHdpdGggIk1VU1QiIG9yDQo+ ICJTSE9VTEQiLg0KDQpbQnJ1bm9dICJNVVNUIiBpcyBub3QgbmVlZGVkIGFzIHRoaXMgaXMgbm90 IGFuIGludGVyb3BlcmFiaWx0eSBpc3N1ZS4gQmVzaWRlcywgYmV0d2VlbiBBU2VzLCBvbmUgbWF5 IHdhbnQgdG8gZmlsdGVyIHRoaXMgY2FwYWJpbGl0eSB3aGljaCBhZHZlcnRpc2VzIGNhcGFiaWxp dHkgb2YgeW91ciBvd24gQVMuDQoiU0hPVUxEIiBpcyBkZWJhdGFibGUuIFRoaXMgaXMgYSBjb25m aWd1cmF0aW9uL3BvbGljeSBjaG9pY2UuDQoNCk5vdGUgdGhhdCByZWdhcmRpbmcgdGhlIEVudHJv cHkgTGFiZWwgcGFydCwgYXMgcHJpb3J5IEkgZmVsdCB0aGF0IHRoZSByaWdodCBvcHRpb24gd2Fz IHRvIHNwZWNpZnkgdGhlIHNhbWUgYmVoYXZpb3IgYXMgb3JpZ2luYWxseSBkZWZpbmVkIGluIFJG QyA2NzkwLiBPbiB0aGlzIHNwZWNpZmljIHBvaW50IFJGQyA2NzkwIHVzZWQgYXMgTUFZOg0KIkhv d2V2ZXIsIGlmIFQgY2hhbmdlcyB0aGUgTkVYVF9IT1AgYXR0cmlidXRlIGZvciBVIGFuZCBpbiB0 aGUgZGF0YSBwbGFuZSBwb3BzIHRoZSBlbnRpcmUgbGFiZWwgc3RhY2sgdG8gcHJvY2VzcyB0aGUg cGF5bG9hZCwgVCBNQVkgaW5jbHVkZSBhbiBFTEMgYXR0cmlidXRlIGZvciBVUERBVEUgVScgaWYg Ym90aCBvZiB0aGUgZm9sbG93aW5nIGFyZSB0cnVlOiINCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9yZmM2NzkwI3NlY3Rpb24tNS4yDQoNCiANCj4gc2VjdGlvbiA2LjENCj4gDQo+IFRoZSAi cmVhZGFibGUgbGFiZWwgZGVwdGgiIGNhbiBiZSByZWdhcmRlZCBhcyBhbm90aGVyIGZvcndhcmRp bmcgcGxhbmUNCj4gZmVhdHVyZSwgd2hpY2ggbWF5IGJlIHVzZWQgaW5kZXBlbmRlbnQgb2YgdGhl IGVudHJvcHkgbGFiZWwgY2FwYWJpbGl0eS4NCj4gVGh1cyBJJ2Qgc3VnZ2VzdCB0byBhbGxvY2F0 ZSBhIGRlZGljYXRlZCBOZXh0LWhvcCBjYXBhYmlsaXR5IGNvZGUgZm9yIGl0Lg0KDQpbQnJ1bm9d IEdvb2QgcG9pbnQuDQpJbiB0aGVvcnksIHlvdSBhcmUgcmlnaHQuIEluIHByYWN0aWNlLCB0aGlz IHJlYWxseSBkZXBlbmRzIGhvdyB0aGUgInJlYWRhYmxlIGxhYmVsIGRlcHRoIiBpcyBzcGVjaWZp ZWQuDQpJbiBkcmFmdC1pZXRmLW1wbHMtc3ByaW5nLWVudHJvcHktbGFiZWwsIGl0IGlzIHNwZWNp ZmllZCBpbiB0aGUgY29udGV4dCBvZiB0aGUgRW50cm9weSBMYWJlbCwgaGVuY2UgdGhlIHByZXNl bmNlIG9mIHRoZSBFbnRyb3B5IExhYmVscyBpcyBhc3N1bWVkLg0KSG93ZXZlciwgeW91IGFyZSBw ZXJmZWN0bHkgcmlnaHQgdGhhdCB0aGUgY29uY2VwdCBjb3VsZCBiZSBnZW5lcmFsaXplZCB0byBk aWZmZXJlbnQgd2F5cyBvZiBkb2luZyB0aGUgbG9hZC1iYWxhbmNpbmcuIChlLmcuIG9uIHRoZSBJ UC9jdXN0b21lciBwYWNrZXQpLg0KSSdsbCB0aGluayBtb3JlIGFib3V0IHRoaXMgcG9pbnQuIElu IHRoZSBtZWFudGltZSwgZmVlbCBmcmVlIHRvIGV4cHJlc3MgeW91ciBjb21tZW50IHRvIHRoZSBh dXRob3JzIG9mIGRyYWZ0LWlldGYtbXBscy1zcHJpbmctZW50cm9weS1sYWJlbCA7LSkNCg0KIA0K PiBBcyBmb3IgdGhlIG5hbWUgb2YgdGhpcyBuZXcgYXR0cmlidXRlLCBJIGFncmVlIGl0IGlzIE5l eHQtSG9wIEFORCBwYXRoDQo+IHNwZWNpZmljLiBQZXJzb25hbGx5IEkgdGhpbmsgIk5leHQtSG9w IGNhcGFiaWxpdHkiIGlzIE9LLCBzaW5jZSBpdCBpcyBjYWxsZWQgYQ0KPiBCR1AgUGF0aCBBdHRy aWJ1dGUsIHdoaWNoIGltcGxpZXMgdGhhdCBpdCBjb3VsZCBiZSBwYXRoLXNwZWNpZmljOikuDQoN CltCcnVub10gVGhhbmtzIGZvciB0aGUgZmVlZGJhY2suDQooYSBuYW1pbmcgb3B0aW9uIGlzICJO ZXh0LUhvcCBkZXBlbmRhbnQiIHdoaWNoIGlzIG1vcmUgYWNjdXJhdGUgYnV0IGxvbmdlcikNCg0K TWFueSB0aGFua3MsDQpCZXN0IHJlZ2FyZHMsDQpCcnVubyANCg0KPiBCZXN0IHJlZ2FyZHMsDQo+ IEppZQ0KPiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IElkciBb bWFpbHRvOmlkci1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YNCj4gPiBicnVuby5kZWNy YWVuZUBvcmFuZ2UuY29tDQo+ID4gU2VudDogVHVlc2RheSwgSnVseSAwNywgMjAxNSA0OjE0IEFN DQo+ID4gVG86IGlkciB3ZyBsaXN0DQo+ID4gU3ViamVjdDogW0lkcl0gZHJhZnQtZGVjcmFlbmUt aWRyLW5leHQtaG9wLWNhcGFiaWxpdHktMDEudHh0DQo+ID4NCj4gPiBIaSBhbGwsDQo+ID4NCj4g PiBQbGVhc2UgZmluZCBiZWxvdyBhbiB1cGRhdGVkIHZlcnNpb24gb2YgdGhlIGRyYWZ0IHByZXNl bnRlZCBpbiBEYWxsYXMuDQo+ID4NCj4gPiBNYWluIGNoYW5nZXMgYXJlIHRoZSBmb2xsb3dpbmc6 DQo+ID4gLSBOZXcgY28tYXV0aG9yczogS2lyZWV0aSBLb21wZWxsYSwgIFdpbSBIZW5kZXJpY2t4 DQo+ID4gLSBTbGlnaHRseSBpbXByb3ZlZCAiZXJyb3IgaGFuZGxpbmciIHNlY3Rpb24gb2YgdGhl IEJHUCBhdHRyaWJ1dGUNCj4gPiAtIE5ldyBzZWN0aW9uIGRlZmluaW5nIHRoZSAiZXJyb3IgaGFu ZGxpbmciIG9mIHRoZSBNUExTIEVudHJvcHkgTGFiZWwNCj4gPiBCR1AgTmV4dC1Ib3AgQ2FwYWJp bGl0eS4NCj4gPiAtIFNvbWUgcmUtcmV3b3JkaW5nIG9mIHRoZSAiRW50cm9weSBMYWJlbCBOZXh0 LUhvcCBDYXBhYmlsaXR5IiBzZWN0aW9uDQo+ID4gCS0gLTAwIHdhcyBtb3N0bHkgYSBjb3B5IHBh c3QgZnJvbSBSRkMgNjc5MCAod2hpY2ggZGVmaW5lcyB0aGUNCj4gTVBMUw0KPiA+IEVudHJvcHkg TGFiZWwgJiB0aGUgb3JpZ2luYWwgYW5kIG5vdyBkZXByZWNhdGVkIEJHUCBhdHRyaWJ1dGUpDQo+ ID4gCS0gLTAxIGlzIGV4cGVjdGVkIHRvIGJlIG1vcmUgcHJlY2lzZSB0aGFua3MgdG8gY29tbWVu dHMgZnJvbSBFcmljDQo+ID4gUm9zZW4gKG1hbnkgdGhhbmtzKQ0KPiA+IC0gTmV3IHNlY3Rpb24g NCAiQkdQIE5leHQtSG9wIENhcGFiaWxpdHkgQ29kZSBPcGVyYXRpb24iDQo+ID4gCS0gTm90aGlu ZyBvdXRzdGFuZGluZywgYnV0IGJldHRlciB3aGVuIGV4cGxpY2l0bHkgc3RhdGVkDQo+ID4gLSBB ZGRpdGlvbiBvZiB0aGUgb3B0aW9uYWwgYWJpbGl0eSB0byBhZHZlcnRpc2UgdGhlICJSZWFkYWJs ZSBMYWJlbA0KPiA+IERlcHRoIiBvZiB0aGUNCj4gPiBMU1AocykgYWR2ZXJ0aXNlZCBpbiB0aGUg TkxSSQ0KPiA+IAktIFN0aWxsIG5lZWQgc29tZSBwb2xpc2hpbmcNCj4gPiAtIEltcHJvdmVkIHdv cmRpbmcsIHNvbWUgdHlwbyBjb3JyZWN0ZWQNCj4gPg0KPiA+DQo+ID4gRGlmZjoNCj4gPiBodHRw czovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtZGVjcmFlbmUtaWRyLW5leHQtaG9w LWNhcGFiaWxpDQo+ID4gdHktMDENCj4gPg0KPiA+DQo+ID4gQ29tbWVudHMgd2VsY29tZWQuDQo+ ID4NCj4gPiBJbiBwYXJ0aWN1bGFyLCB0aGUgbmFtZSBvZiB0aGUgQkdQIEF0dHJpYnV0ZSBjb3Vs ZCBoYXZlIGEgYmV0dGVyIG5hbWUNCj4gPiAodG8gYmUNCj4gPiBwcm9wb3NlZCk6DQo+ID4gCS0g Q3VycmVudGx5IGNhbGxlZCBOZXh0LUhvcCBDYXBhYmlsaXR5DQo+ID4gCS0gQnV0IHRoZSBjYXBh YmlsaXR5IGlzIG5vdCBvbmx5IE5leHQtSG9wIHNwZWNpZmljIGJ1dCBtb3JlIHByZWNpc2VseQ0K PiA+IE5leHQtSG9wIEFORCBwYXRoIHNwZWNpZmljLiBJbiBwYXJ0aWN1bGFyLCBmb3IgZGlmZmVy ZW50IFVQREFURSBoYXZpbmcNCj4gPiB0aGUgc2FtZSBOZXh0LUhvcCwgdGhlIGNhcGFiaWxpdHkg bWF5IGJlIGRpZmZlcmVudC4NCj4gPiAJLSBJ4oCZZCB3ZWxjb21lIGFueSBzdWdnZXN0aW9uIG9m IG5hbWUuDQo+ID4gCQktIFdlIHByb2JhYmx5IHdhbnQgdG8ga2VlcCB0aGUgdGVybSAiTmV4dC1I b3AiDQo+IHNvbWV3aGVyZSBhcyB0aGlzIGlzDQo+ID4gYSBrZXkgcHJvcGVydHkgb2YgdGhlIEJH UCBhdHRyaWJ1dGUgd2hpY2ggaXMgcmVtb3ZlZCB3aGVuIHRoZSBOZXh0LUhvcA0KPiA+IGlzIGNo YW5nZWQuDQo+ID4NCj4gPg0KPiA+IFRoYW5rcywNCj4gPiBSZWdhcmRzLA0KPiA+IEJydW5vDQo+ ID4NCj4gPiBQUzogbG9uZyAoYm9yaW5nKSBlbWFpbCwgYnV0IHlvdSBzYXZlZCBhIChib3Jpbmcp IHByZXNlbnRhdGlvbiBpbg0KPiA+IFByYWd1ZXMNCj4gPg0KPiA+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+ID4gRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0KPiA+IFNlbnQ6IE1vbmRheSwgSnVseSAwNiwgMjAxNSA5 OjQ2IFBNDQo+ID4gVG86IFdpbSBIZW5kZXJpY2t4OyBLaXJlZXRpIEtvbXBlbGxhOyBLaXJlZXRp IEtvbXBlbGxhOyBERUNSQUVORSBCcnVubw0KPiA+IElNVC9PTE47IFdpbSBIZW5kZXJpY2t4OyBE RUNSQUVORSBCcnVubyBJTVQvT0xODQo+ID4gU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvcg0KPiA+IGRyYWZ0LWRlY3JhZW5lLWlkci1uZXh0LWhvcC1jYXBhYmlsaXR5LTAxLnR4 dA0KPiA+DQo+ID4NCj4gPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtZGVjcmFlbmUtaWRy LW5leHQtaG9wLWNhcGFiaWxpdHktMDEudHh0DQo+ID4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1 Ym1pdHRlZCBieSBCcnVubyBEZWNyYWVuZSBhbmQgcG9zdGVkIHRvIHRoZQ0KPiA+IElFVEYgcmVw b3NpdG9yeS4NCj4gPg0KPiA+IE5hbWU6CQlkcmFmdC1kZWNyYWVuZS1pZHItbmV4dC1ob3AtY2Fw YWJpbGl0eQ0KPiA+IFJldmlzaW9uOgkwMQ0KPiA+IFRpdGxlOgkJQkdQIE5leHQtSG9wIENhcGFi aWxpdGllcw0KPiA+IERvY3VtZW50IGRhdGU6CTIwMTUtMDctMDYNCj4gPiBHcm91cDoJCUluZGl2 aWR1YWwgU3VibWlzc2lvbg0KPiA+IFBhZ2VzOgkJMTANCj4gPiBVUkw6DQo+ID4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWRlY3JhZW5lLWlkci1uZXh0LWhvcC1j YXBhYg0KPiA+IGlsaXR5LTAxDQo+ID4gLnR4dA0KPiA+IFN0YXR1czoNCj4gPiBodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1kZWNyYWVuZS1pZHItbmV4dC1ob3AtY2FwYWJp bGl0DQo+ID4geS8NCj4gPiBIdG1saXplZDoNCj4gPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtZGVjcmFlbmUtaWRyLW5leHQtaG9wLWNhcGFiaWxpdHktMDENCj4gPiBEaWZmOg0K PiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1kZWNyYWVuZS1pZHIt bmV4dC1ob3AtY2FwYWJpbGkNCj4gPiB0eS0wMQ0KPiA+DQo+ID4gQWJzdHJhY3Q6DQo+ID4gICAg UkZDIDU0OTIgZGVmaW5lcyBjYXBhYmlsaXRpZXMgYWR2ZXJ0aXNlbWVudCBmb3IgdGhlIEJHUCBw ZWVyLiAgSW4NCj4gPiAgICBhZGRpdGlvbiwgaXQgaXMgdXNlZnVsIHRvIGtub3cgdGhlIGNhcGFi aWxpdGllcyBvZiB0aGUgQkdQIE5leHQtSG9wLA0KPiA+ICAgIGluIHBhcnRpY3VsYXIgZm9yIGZv cndhcmRpbmcgcGxhbmUgZmVhdHVyZXMuICBSRkMgNTQ5MiBpcyBub3QNCj4gPiAgICBhcHBsaWNh YmxlIGJlY2F1c2UgdGhlIEJHUCBwZWVyIG1heSBiZSBkaWZmZXJlbnQgZnJvbSB0aGUgQkdQIE5l eHQtDQo+ID4gICAgSG9wLCBpbiBwYXJ0aWN1bGFyIHdoZW4gQkdQIFJvdXRlIFJlZmxlY3Rpb24g aXMgdXNlZC4gIFRoaXMgZG9jdW1lbnQNCj4gPiAgICBkZWZpbmVzIGEgbWVjaGFuaXNtIHRvIGFk dmVydGlzZSBzdWNoIEJHUCBOZXh0IEhvcCBDYXBhYmlsaXRpZXMuDQo+ID4NCj4gPiAgICBUaGlz IGRvY3VtZW50IGRlZmluZXMgYSBuZXcgQkdQIG5vbi10cmFuc2l0aXZlIGF0dHJpYnV0ZSB0byBj YXJyeQ0KPiA+ICAgIE5leHQtSG9wIENhcGFiaWxpdGllcy4gIFRoaXMgYXR0cmlidXRlIGlzIGRl bGV0ZWQgd2hlbiB0aGUgQkdQIE5leHQNCj4gPiAgICBIb3AgaXMgY2hhbmdlZC4NCj4gPg0KPiA+ ICAgIFRoaXMgZG9jdW1lbnQgYWxzbyBkZWZpbmVzIGEgTmV4dC1Ib3AgY2FwYWJpbGl0eSB0byBh ZHZlcnRpc2UgdGhlDQo+ID4gICAgYWJpbGl0eSB0byBoYW5kbGUgdGhlIEVudHJvcHkgTGFiZWwg ZGVmaW5lZCBpbiBSRkMgNjc5MC4NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4gUGxlYXNl IG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUg b2YNCj4gPiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFy ZSBhdmFpbGFibGUgYXQNCj4gdG9vbHMuaWV0Zi5vcmcuDQo+ID4NCj4gPiBUaGUgSUVURiBTZWNy ZXRhcmlhdA0KPiA+DQo+ID4NCj4gPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBfXw0KPiA+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+DQo+ID4gQ2Ug bWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3Jt YXRpb25zDQo+ID4gY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50 IGRvbmMgcGFzIGV0cmUgZGlmZnVzZXMsDQo+ID4gZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1 dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZQ0KPiA+IHBhciBlcnJldXIs IHZldWlsbGV6IGxlIHNpZ25hbGVyIGEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNp DQo+ID4gcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMg ZXRhbnQgc3VzY2VwdGlibGVzDQo+ID4gZCdhbHRlcmF0aW9uLCBPcmFuZ2UgZGVjbGluZSB0b3V0 ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlDQo+ID4gYWx0ZXJlLCBkZWZvcm1l IG91IGZhbHNpZmllLiBNZXJjaS4NCj4gPg0KPiA+IFRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFj aG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvcg0KPiA+IHByaXZpbGVnZWQgaW5mb3Jt YXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsgdGhleSBzaG91bGQgbm90DQo+ID4g YmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCj4g PiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5 IHRoZSBzZW5kZXIgYW5kDQo+ID4gZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1l bnRzLg0KPiA+IEFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUg Zm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZQ0KPiA+IGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFs c2lmaWVkLg0KPiA+IFRoYW5rIHlvdS4NCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gSWRyIG1haWxpbmcgbGlzdA0KPiA+IElkckBp ZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRyDQoK X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5p ciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUg ZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMg YXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZl dWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1 ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1 c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmls aXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJj aS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVu dGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBs YXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91 dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9y LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0 cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxp YWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFs c2lmaWVkLgpUaGFuayB5b3UuCgo= From nobody Fri Jul 31 08:35: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 DD02F1B2BEB; Fri, 31 Jul 2015 08:35:24 -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 hs7t_xR2kgU8; Fri, 31 Jul 2015 08:35:20 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0738.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:738]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B72AB1B2BE3; Fri, 31 Jul 2015 08:35:19 -0700 (PDT) Authentication-Results: ndzh.com; dkim=none (message not signed) header.d=none; Received: from [172.29.33.58] (66.129.241.12) by BY1PR0501MB1093.namprd05.prod.outlook.com (10.160.103.139) with Microsoft SMTP Server (TLS) id 15.1.225.19; Fri, 31 Jul 2015 15:35:02 +0000 To: References: From: Eric C Rosen Message-ID: <55BB95A0.4030603@juniper.net> Date: Fri, 31 Jul 2015 11:34:56 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="gbk"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.12] X-ClientProxiedBy: SN1PR06CA0038.namprd06.prod.outlook.com (25.163.69.48) To BY1PR0501MB1093.namprd05.prod.outlook.com (25.160.103.139) X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1093; 2:MDGldAmb3KG5glV0lDM6PY+We3Spl3m1sJOQtg6gTfQTi0uaXssHsvHNYbo8wzXiSJWtsPQHDX95wi4lPCBGq5EfFXFLdTBKbXTLK1Jf9vo+Z71Oa21QUL7s62Ve3KdCsxTDxkzhRBKvaXZvkYDU76fwr7QZ3HI2sftQterUvCQ=; 3:bwBX3wgavtsqNeAbDYTN+Nqp7jPrqJGW6u7Q/S58CE42IOTkddjwDis/B4ft8s0OzH+o3oppzT4a02xD1DprTDZsT6bUDCf52ECazAugQjL8wXoWP7IJ35dq6PrA/Q+eDJEMaA0E6JRSEeQj8kpYSw==; 25:et/zAH+bc4tW1uWKnKn4EvEkI+CU9CQItUjU2SM/Jk+DiF/p/N4dMN2kYB7jBxD5gbU41gq+zyVTUc3NVUBrcXDu782Of2qBbubPNQFILUdOwYIloxLzO9fI1bCXwl1bBwzZRkK4hGOyFS21yLDQo/yre6zQEO3omYjnCDEZZVpwpiy1qs9GnT7MfQsBtXDNsu9BTGxjxbJPjBVJJSHdaT0jcBPBKwSE/te/0BDyQ1V4LhehZh2BLPze8ENO55ir X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1093; X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1093; 20:IgmsOUBCZDVxBXf7MZQ8I4je95Msid4YNLKLMgnp+85c3yYurpaqrjfnaA8h70/96EpNrW4/SlkKmo1VjAOs2ldwUhUQIX/qrXEqsvB8E7jCQu3UjRQ0d8Vxq3N84L1+hdHncSIY+NcouIClVnHzQdEDm4zpi+6viUXXm+KNA7/73ygxa8ViyWQoodXoDvndXJOynWro0xJfcalgFaMqN6YT3Py2c1i+3i+opUOwJrBYt5BeNpOfm6jBlaFZHX4Y7dWeUyVHeD7MEh6iPyy7h3IaRAdw/d93wxO2YtwkQn/YCSFOSzib9UR9xNFA0v00tq1HlgGPXOD2sAgu6ReF2GS3meT6VsllV10S2k1ZtEBDD75d3VqOVE3Q3ZFWshWh5BnzFuYkCsXBxwXbXsCbccNli4fbLhp+gmlmwbl5fcyTzfRafaqb4wGeSYKxVrLFHFYub/XcI8UDqtM/iwds5kb2C8E476FMWD6yPlaN5scLNn4Ga+XW1qS8Kb5+uysO; 4:bqmpl4tlzHpfkBabEwZNiDEp6IxW2tRgrMoUFBlz4FXtt0GlHPMk5/z4HWqYI0zq6Q0u9NmqtUlDVbY6Gn8AudnTpn1tXe5XwwMujW6MMN+b0wzCRHow7uqP8UHLM2tjanIKlXuuzt0HPrdG5M1VYsa2nS129DTTSFhhhgC3BfeXoHMRwUCeuK4Pz2JZEB/rYjYG3BdtcKI4KW3R0mlD1p1wcGdr/Dg8UL29B0eQyKR+60hhMpwvVVj/5nNfKTDdek2V88cXRq1lsNDj+V+76sNsYz/84asWwwCZQPYlPxU= 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:BY1PR0501MB1093; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1093; X-Forefront-PRVS: 0654257CF5 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(6009001)(46102003)(36756003)(23696002)(64126003)(65956001)(5001960100002)(65806001)(66066001)(110136002)(47776003)(4001350100001)(86362001)(65816999)(50466002)(54356999)(230783001)(87976001)(50986999)(83506001)(80316001)(87266999)(76176999)(122386002)(106356001)(42186005)(92566002)(40100003)(33656002)(2351001)(62966003)(77096005)(2950100001)(189998001)(77156002)(59896002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1093; H:[172.29.33.58]; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:en; X-Microsoft-Exchange-Diagnostics: =?gb2312?B?MTtCWTFQUjA1MDFNQjEwOTM7MjM6TzlhQnpQczNqcGF5Vk9vNVplUllIdUtS?= =?gb2312?B?QlZSNVk4RjFnVllpWmNVdlVXV1dmeFhacEw1UGw3WFM4WHBHZ2doMmNWTzcz?= =?gb2312?B?bjNNNDlXS3puWm1Vai8xUHYweEwreTk2UEhxRXpwVWVSR0xwYWhxQ2xaUFZP?= =?gb2312?B?bXJDdDJhM09pUEE0aTd5cUNWS1h5UHV6VmVKQTdCVGIwV1R4ZTVVZ1owL3dY?= =?gb2312?B?U1VvMzBjZjRxZ2l1ZUZRRTJqeVgwbjJ0VGFpSk1mMCtqNEpNQzZkZGpHdDZE?= =?gb2312?B?S2lrT3p0aVozLzNzS1BBT1Y5Wlp2STZwVklXMElJeUU4b0JWS1J1bVpUb3B4?= =?gb2312?B?TmNBOTg4YTR3RU1aZXZ3R3dzMTFmRU5kVXlMdFdtTDMvQUVjN24rbXNaL2xh?= =?gb2312?B?RGwxTnNtd3lRWnl6MHJ0S1RscURSL2laa1RvcDE3dXdqb2Vkd3MxaEJwVTgz?= =?gb2312?B?T0lSKzUwRWJGVHltSjdiQUZLam13bC80UE94amFCSmpvL0VOM3J4TzJITnJJ?= =?gb2312?B?VkFrMVZoZFFHVlNvaXV0MVR1Rnk1U1Vuc0szaXBDbEoyYmVhV3RDcitLOTRa?= =?gb2312?B?QXVrMFA2bTFUb3RJblpmTlgwNUhUWnI2enFHRGFIVE1aMVN3YlNLUVpIUjlH?= =?gb2312?B?NC80YkU0NERPaEFmUExUVktXQ2MzRnoybXl6R3V0SjFlc1grbTU0N2tzYzlt?= =?gb2312?B?TlBjKzR6djY5c1ZvSCtsMERHeHdSSGUyM25mVm1kM3orZVZsZDMzejhJR1RX?= =?gb2312?B?VEdIbjMxR05RYkMraTFuYVl6eDBUS2k2Q2tHTUQ4ZDZqQlhoUjQ3UTR2QTFZ?= =?gb2312?B?SWRpWkdPOHN0YWFBa1k4UHkrVlJ6enhGQ1c1cFFmNENBS0RjQW1nOVBLZ1NN?= =?gb2312?B?a2NXQ0t5NXk4Vy9ta2ZyNExpNktIYkNuNmFodjhOTnkzT20veXBKN1VnV1dR?= =?gb2312?B?SWNsVDdwREdma1ZLdDRSVFRZQzVKOWRBbUxCMXdPeGFaUFZMTmFPeUgyMmxz?= =?gb2312?B?d3BCRnZCWm1YK3FMQUJFKzBsdlFHM3pyYWMzSUIvU05yL3Z3eUJPaEFjREZl?= =?gb2312?B?dkc1WE5XSXpjWGNRMXh4V0hoWjR0d0J2YWNYd1h6anlNdW5VTndDTUxUQmFE?= =?gb2312?B?RXBMYWltVjY0N1ZSeEFqdExVc1E3UnhkUjI1VDdrVm1td0Q0alBwc05PNnUv?= =?gb2312?B?NzV5eVhha2o1eGtMMFIyZHZvS0Z6Ry9vM3VCRUF1RFRsM0dtemROU281RGp0?= =?gb2312?B?bGQraGkzb0UwRlZSMkE2dHE5UDFZSDRRR21BUVEwcElKcm5xZVMwT3NzTzIw?= =?gb2312?B?UjBzV3pRSjZxa2ViUT09?= X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1093; 5:boic6/r65TZ+nReh2KkfcEhwXfihvtQq7bmG8lhjn4/3tQc2w6AV9J8+Ys4+dND+I61+0rXmg4w+tmmrEow2z1zuZFAc8gNiPvlOij5k5/6eW8Y+/Lqw4kwsuxBsOC3IxCdMqxWd/OZe+qG8mHVz6A==; 24:ubCpYBnLI7azlPxMlvsWTqojedALzhyppLuHbG6XH9ZCAWXVOQrfUBaZsnkc58QAhMjfAIssTNnVavoWJJd2CVYLchazFV0L2iFuH/nnfUI=; 20:X1V3pBVa/32BA728tNxA4jTbMgk1vW7mxw9ujJcPttMvtKTqS8rSL6llOYpd+q6aEZz8dMUMd188P7t8PUq7kA== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Jul 2015 15:35:02.3201 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1093 Archived-At: Cc: 'IDR WG' , Idr , Susan Hares Subject: Re: [Idr] Comment on draft-zhang-idr-upstream-assigned-label-solution 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, 31 Jul 2015 15:35:25 -0000 > The different flows share one P-tunnel, that will decrease the > number of P-tunnels. And it will make more easier for service and > policy deployment of operators. Maybe MVPN extranet should consider > the use of upstream-assigned labels. Per draft-ietf-bess-mvpn-extranet, multiple flows can already share a single P-tunnel, without the use of upstream-assigned labels. As discussed, in MVPN, when upstream-assigned labels are used, the tunnel provides the context for the upstream-assigned label, so there is no issue of collisions when selecting a "context label". (In MVPN/BIER, the BFIR-id provides the context.) > The context label can be used to distinguish the service, such like > MVPN, EVPN, DC interconnection, VxLAN and so on. So only one context > label identifies a router is not enough. More context labels are > needed for different services on a router You mentioned RFC 5331, but there is no suggestion in that RFC that the routers on a LAN need multiple context labels per LAN. It is certainly conceivable that there is a problem whose solution requires the dynamic assignment of domain-wide unique labels. If we were trying to solve such a problem, your solution might be one of the alternatives to be considered. Right now, I don't really see what more can be said about it.