From nobody Wed Mar 1 10:58:39 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC5651297F3; Wed, 1 Mar 2017 10:58:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PW13wGKNC_WS; Wed, 1 Mar 2017 10:58:37 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 0849712966A; Wed, 1 Mar 2017 10:58:37 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id E87401E32D; Wed, 1 Mar 2017 14:04:25 -0500 (EST) Date: Wed, 1 Mar 2017 14:04:25 -0500 From: Jeffrey Haas To: idr@ietf.org, opsawg@ietf.org Message-ID: <20170301190425.GD17448@pfrc.org> References: <001201d2865a$48899340$d99cb9c0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001201d2865a$48899340$d99cb9c0$@ndzh.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Idr] FW: WG adoption poll for draft-li-opsawg-ipfix-bgp-community-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 18:58:38 -0000 [Please note I am not on the opsawg list.] On Mon, Feb 13, 2017 at 07:35:45PM -0500, Susan Hares wrote: > IDR WG: > > The OPSAWG chairs are reviewing the > draft-li-opsawg-ipfix-bgp-community-02.txt for WG adoption. Please comment > on this OPSAWG list and/or IDR list if you feel this draft should be adopted > on not adopted. I see that the draft was adopted and, as someone who previously worked on flow generators, think it's a potentially useful feature. I have a few brief comments: 1. Is there long-term intent to include other types of community data, such as extended communities or large communities? 2. The density of flow records significant impacts how quickly flow collectors are able to process the information. Unless I'm missing something, the draft doesn't seem to constrain how many communities might be able to be sent as part of the flow record as part of the community list. The authors may want to discuss mechanisms or implementations wherein the number of items in the list *might* be constrained and what to do in reporting if the list is truncated or not. 2a. When it's necessary to truncate sending some of the communities, it might be worth potentially preferring the communities in the well-known space. Knowing that a flow at a given ingress is intended to be constrained downstream may help detecting leaks when performing flow correlation in a network. Aside - 3. It's well known that flow collectors on BGP edge devices that may be distributing traffic over BGP multipaths may not even consistently report BGP data such as peer-as or origin-as for the flows traversing that multipath, despite being part of the existing flow record format. In such situations, the communities are potentially of low value. -- Jeff From nobody Wed Mar 1 20:08:12 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD65012948B for ; Wed, 1 Mar 2017 20:08:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WvwmP2uypLzZ for ; Wed, 1 Mar 2017 20:08:09 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 3D8011293FC for ; Wed, 1 Mar 2017 20:08:09 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 86D3B1E32D; Wed, 1 Mar 2017 23:13:58 -0500 (EST) Date: Wed, 1 Mar 2017 23:13:58 -0500 From: Jeffrey Haas To: idr@ietf.org Message-ID: <20170302041358.GA22854@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: Subject: [Idr] [internet-drafts@ietf.org: I-D Action: draft-haas-idr-extended-experimental-01.txt] X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 04:08:10 -0000 Working Group, I've updated the previously discussed document with some minor fixes, and included working group discussion in the appendices. Errors in the representation of the intent of various feedback is solely my own. -- Jeff ----- Forwarded message from internet-drafts@ietf.org ----- Date: Wed, 01 Mar 2017 20:01:26 -0800 From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-haas-idr-extended-experimental-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Extended Experimental Path Attributes for BGP Author : Jeffrey Haas Filename : draft-haas-idr-extended-experimental-01.txt Pages : 8 Date : 2017-03-01 Abstract: BGP's primary feature extension mechanism, Optional-Transitive Path Attributes, has proven to be a successful mechanism to permit BGP to be extended. In order to ease various issues during the development of new BGP features, this document proposes an extended experimental Path Attribute to carry prototype features. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-haas-idr-extended-experimental/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-haas-idr-extended-experimental-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-haas-idr-extended-experimental-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/ _______________________________________________ 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 ----- End forwarded message ----- From nobody Thu Mar 2 05:48:09 2017 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A2BC312998B; Thu, 2 Mar 2017 05:47:58 -0800 (PST) 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.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148846247866.19611.17441167304517620418.idtracker@ietfa.amsl.com> Date: Thu, 02 Mar 2017 05:47:58 -0800 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-wide-bgp-communities-04.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 13:47:59 -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 of the IETF. Title : BGP Community Container Attribute Authors : Robert Raszuk Jeffrey Haas Andrew Lange Bruno Decraene Shane Amante Paul Jakma Filename : draft-ietf-idr-wide-bgp-communities-04.txt Pages : 25 Date : 2017-03-02 Abstract: Route tagging plays an important role in external BGP [RFC4271] relations, in communicating various routing policies between peers. It is also a very common best practice among operators to propagate various additional information about routes intra-domain. The most common tool used today to attach various information about routes is through the use of BGP communities [RFC1997]. This document defines a new encoding which will enhance and simplify what can be accomplished today with the use of BGP communities. The most important addition this specification makes over currently defined BGP communities is the ability to specify, carry as well as use for execution an operator's defined set of parameters. It also provides an extensible platform for any new community encoding needs in the future. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-wide-bgp-communities/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-wide-bgp-communities-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-wide-bgp-communities-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Mar 2 06:19:41 2017 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AA3821295DB; Thu, 2 Mar 2017 06:19:36 -0800 (PST) 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.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148846437669.19538.15481406939844620255.idtracker@ietfa.amsl.com> Date: Thu, 02 Mar 2017 06:19:36 -0800 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-flowspec-path-redirect-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 14:19:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing of the IETF. Title : Flowspec Indirection-id Redirect Authors : Gunter Van de Velde Keyur Patel Zhenbin Li Filename : draft-ietf-idr-flowspec-path-redirect-01.txt Pages : 13 Date : 2017-03-02 Abstract: Flowspec is an extension to BGP that allows for the dissemination of traffic flow specification rules. This has many possible applications but the primary one for many network operators is the distribution of traffic filtering actions for DDoS mitigation. The flow-spec standard RFC5575 [2] defines a redirect-to-VRF action for policy-based forwarding but this mechanism is not always sufficient, particularly if the redirected traffic needs to be steered into an engineered path or into a service plane. This document defines a new extended community known as redirect-to- indirection-id (32-bit) flowspec action to provide advanced redirection capabilities on flowspec clients. When activated, the flowspec extended community is used by a flowspec client to find the correct next-hop entry within a localised indirection-id mapping table. The functionality present in this draft allows a network controller to decouple flowspec functionality from the creation and maintainance of the network's service plane itself including the setup of tunnels and other service constructs that could be managed by other network devices. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-path-redirect/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-flowspec-path-redirect-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-flowspec-path-redirect-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Mar 3 01:43:39 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7BED12941E for ; Fri, 3 Mar 2017 01:43:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R0bZ9Xf2aDiW for ; Fri, 3 Mar 2017 01:43:34 -0800 (PST) Received: from cmccmta2.chinamobile.com (cmccmta2.chinamobile.com [221.176.66.80]) by ietfa.amsl.com (Postfix) with ESMTP id BC7521293F4 for ; Fri, 3 Mar 2017 01:43:32 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.121.19]) by rmmx-syy-dmz-app05-12005 (RichMail) with SMTP id 2ee558b93abd652-e6cb7; Fri, 03 Mar 2017 17:43:25 +0800 (CST) X-RM-TRANSID: 2ee558b93abd652-e6cb7 X-RM-SPAM-FLAG: 00000000 Received: from cmcc-PC (unknown[223.69.29.1]) by rmsmtp-syy-appsvr10-12010 (RichMail) with SMTP id 2eea58b93abcdfc-16f4a; Fri, 03 Mar 2017 17:43:25 +0800 (CST) X-RM-TRANSID: 2eea58b93abcdfc-16f4a Date: Fri, 3 Mar 2017 17:43:50 +0800 From: "lizhenqiang@chinamobile.com" To: idr References: <148784903318.20350.3977002902067988959.idtracker@ietfa.amsl.com> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 7, 164[cn] Mime-Version: 1.0 Message-ID: <2017030317434995427747@chinamobile.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart515324677571_=----" Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rfc5575bis-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 09:43:38 -0000 This is a multi-part message in MIME format. ------=_001_NextPart515324677571_=---- Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 SGksDQoNCkkgYW0gcmVhZGluZyB0aGlzIGRyYWZ0LiBJIG5vdGljZWQgdGhhdCB0aGVyZSBhcmUg NyBhY3Rpb25zIGxpc3RlZCBpbiB0YWJsZSAyLiBCdXQgT25seSA1IG9mIHRoZW0gYXJlIGlsbHVz dHJhdGVkIGluIHNlY3Rpb24gNy4gQWN0aW9ucyBmb3IgdHlwZSAweDgxMDggYW5kIDB4ODIwOCBh cmUgbm90IGV4cGxhaW5lZCBpbiB0aGlzIHNlY3Rpb24uIE5vIHJlZmVyZW5jZXMgYXJlIGdpdmVu IGhlcmUuIE1heSBJIGtub3cgdGhlIHJlYXNvbj8gVGhhbmtzLg0KDQpCZXN0IFJlZ2FyZHMsDQoN Cg0KbGl6aGVucWlhbmdAY2hpbmFtb2JpbGUuY29tDQogDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmcNCkRhdGU6IDIwMTctMDItMjMgMTk6MjMNClRvOiBpLWQtYW5ub3VuY2VAaWV0Zi5v cmcNCkNDOiBpZHJAaWV0Zi5vcmcNClN1YmplY3Q6IFtJZHJdIEktRCBBY3Rpb246IGRyYWZ0LWll dGYtaWRyLXJmYzU1NzViaXMtMDAudHh0DQogDQpBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFp bGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQpUaGlz IGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBJbnRlci1Eb21haW4gUm91dGluZyBvZiB0aGUg SUVURi4NCiANCiAgICAgICAgVGl0bGUgICAgICAgICAgIDogRGlzc2VtaW5hdGlvbiBvZiBGbG93 IFNwZWNpZmljYXRpb24gUnVsZXMNCiAgICAgICAgQXV0aG9ycyAgICAgICAgIDogU3VzYW4gSGFy ZXMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgUm9iZXJ0IFJhc3p1aw0KICAgICAgICAgICAg ICAgICAgICAgICAgICBEYW5ueSBNY1BoZXJzb24NCiAgICAgICAgICAgICAgICAgICAgICAgICAg Q2hyaXN0b3BoIExvaWJsDQogICAgICAgICAgICAgICAgICAgICAgICAgIE1hcnRpbiBCYWNoZXIN CkZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtaWRyLXJmYzU1NzViaXMtMDAudHh0DQpQYWdl cyAgICAgICAgICAgOiAzMA0KRGF0ZSAgICAgICAgICAgIDogMjAxNy0wMi0yMg0KIA0KQWJzdHJh Y3Q6DQogICBUaGlzIGRvY3VtZW50IHVwZGF0ZXMgUkZDNTU3NSB3aGljaCBkZWZpbmVzIGEgQm9y ZGVyIEdhdGV3YXkgUHJvdG9jb2wNCiAgIE5ldHdvcmsgTGF5ZXIgUmVhY2hhYmlsaXR5IEluZm9y bWF0aW9uIChCR1AgTkxSSSkgZW5jb2RpbmcgZm9ybWF0DQogICB0aGF0IGNhbiBiZSB1c2VkIHRv IGRpc3RyaWJ1dGUgdHJhZmZpYyBmbG93IHNwZWNpZmljYXRpb25zLiAgVGhpcw0KICAgYWxsb3dz IHRoZSByb3V0aW5nIHN5c3RlbSB0byBwcm9wYWdhdGUgaW5mb3JtYXRpb24gcmVnYXJkaW5nIG1v cmUNCiAgIHNwZWNpZmljIGNvbXBvbmVudHMgb2YgdGhlIHRyYWZmaWMgYWdncmVnYXRlIGRlZmlu ZWQgYnkgYW4gSVANCiAgIGRlc3RpbmF0aW9uIHByZWZpeC4gIFRoaXMgZHJhZnQgc3BlY2lmaWVz IElQdjQgdHJhZmZpYyBmbG93DQogICBzcGVjaWZpY2F0aW9ucyB2aWEgYSBCR1AgTkxSSSB3aGlj aCBjYXJyaWVzIHRyYWZmaWMgZmxvdw0KICAgc3BlY2lmaWNhdGlvbiBmaWx0ZXIsIGFuZCBhbiBF eHRlbmRlZCBjb21tdW5pdHkgdmFsdWUgd2hpY2ggZW5jb2Rlcw0KICAgYWN0aW9ucyBhIHJvdXRp bmcgc3lzdGVtIGNhbiB0YWtlIGlmIHRoZSBwYWNrZXQgbWF0Y2hlcyB0aGUgdHJhZmZpYw0KICAg ZmxvdyBmaWx0ZXJzLiAgVGhlIGZsb3cgZmlsdGVycyBhbmQgdGhlIGFjdGlvbnMgYXJlIHByb2Nl c3NlZCBpbiBhDQogICBmaXhlZCBvcmRlci4gIE90aGVyIGRyYWZ0cyBzcGVjaWZ5IElQdjYsIE1Q TFMgYWRkcmVzc2VzLCBMMlZQTg0KICAgYWRkcmVzc2VzLCBhbmQgTlYwMyBlbmNhcHN1bGF0aW9u IG9mIElQIGFkZHJlc3Nlcy4NCiANCiAgIFRoaXMgZG9jdW1lbnQgdXBkYXRlcyBSRkM1NTc1IHRv IGNvcnJlY3QgdW5jbGVhciBzcGVjaWZpY2F0aW9ucyBpbg0KICAgdGhlIGZsb3cgZmlsdGVycyBh bmQgdG8gcHJvdmlkZSBydWxlcyBmb3IgYWN0aW9ucyB3aGljaCBpbnRlcmZlcmUNCiAgIChlLmcu IHJlZGlyZWN0aW9uIG9mIHRyYWZmaWMgYW5kIGZsb3cgZmlsdGVyaW5nKS4NCiANCiAgIEFwcGxp Y2F0aW9ucyB3aGljaCB1c2UgdGhlIGJncCBmbG93IHNwZWNpZmljYXRpb24gYXJlOiAxKSBhcHBs aWNhdGlvbg0KICAgd2hpY2ggYXV0b21hdGUgb2YgaW50ZXItZG9tYWluIGNvb3JkaW5hdGlvbiBv ZiB0cmFmZmljIGZpbHRlcmluZywNCiAgIHN1Y2ggYXMgd2hhdCBpcyByZXF1aXJlZCBpbiBvcmRl ciB0byBtaXRpZ2F0ZSAoZGlzdHJpYnV0ZWQpIGRlbmlhbC0NCiAgIG9mLXNlcnZpY2UgYXR0YWNr czsgMikgYXBwbGljYXRpb24gd2hpY2ggY29udHJvbCB0cmFmZmljIGZpbHRlcmluZyBpbg0KICAg dGhlIGNvbnRleHQgb2YgYSBCR1AvTVBMUyBWUE4gc2VydmljZSwgYW5kIDMpIGFwcGxpY2F0aW9u cyB3aXRoDQogICBjZW50cmFsaXplZCBjb250cm9sIG9mIHRyYWZmaWMgaW4gYSBTRE4gb3IgTkZW IGNvbnRleHQuICBTb21lIG9mDQogICBkZXBsb3ltZW50cyBvZiB0aGVzZSB0aHJlZSBhcHBsaWNh dGlvbnMgY2FuIGJlIGhhbmRsZWQgYnkgdGhlIHN0cmljdA0KICAgb3JkZXJpbmcgb2YgdGhlIEJH UCBOTFJJIHRyYWZmaWMgZmxvdyBmaWx0ZXJzLCBhbmQgdGhlIHN0cmljdCBhY3Rpb25zDQogICBl bmNvZGVkIGluIHRoZSBFeHRlbmRlZCBDb21tdW5pdHkgRmxvdyBTcGVjaWZpY2F0aW9uIGFjdGlv bnMuDQogDQogDQpUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFm dCBpczoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaWRyLXJm YzU1NzViaXMvDQogDQpUaGVyZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBh dDoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWlkci1yZmM1NTc1Ymlz LTAwDQogDQogDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0 ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lv biBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KIA0KSW50ZXJuZXQt RHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KZnRwOi8vZnRw LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCiANCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpJZHIgbWFpbGluZyBsaXN0DQpJZHJAaWV0Zi5vcmcNCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRyDQogDQo= ------=_001_NextPart515324677571_=---- Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =0A
Hi,

I am reading this dr= aft. I noticed that there are 7 actions listed in table 2. But Only 5 of t= hem are illustrated in section 7. Actions for type 0x8108 and 0x8208 are n= ot explained in this section. No references are given here. May I know the= reason? Thanks.
=0A

Best Regards,
=0A
lizhenqiang@chinamobile.com
=0A=
 
Date: 2017-02-23 19:23
Subject: [Idr] I-D Action: draft-ietf-idr-rfc5575bis-00.txt
 
=0A
A New Internet-Draft is availab= le from the on-line Internet-Drafts directories.
=0A
This draft i= s a work item of the Inter-Domain Routing of the IETF.
=0A
 =
=0A
        Title  =          : Dissemination of Flow S= pecification Rules
=0A
       = Authors         : Susan Hares=0A
          &nbs= p;            =    Robert Raszuk
=0A
     &nbs= p;            =         Danny McPherson
=0A
&n= bsp;           &nbs= p;            = Christoph Loibl
=0A
       &n= bsp;           &nbs= p;      Martin Bacher
=0A
Filename = ;       : draft-ietf-idr-rfc5575bis-00.txt=0A
Pages         &n= bsp; : 30
=0A
Date       &nbs= p;    : 2017-02-22
=0A
 
=0A
Abstrac= t:
=0A
   This document updates RFC5575 which defines a= Border Gateway Protocol
=0A
   Network Layer Reachabil= ity Information (BGP NLRI) encoding format
=0A
   that = can be used to distribute traffic flow specifications.  This
=0A=
   allows the routing system to propagate information regar= ding more
=0A
   specific components of the traffic agg= regate defined by an IP
=0A
   destination prefix. = ; This draft specifies IPv4 traffic flow
=0A
   specifi= cations via a BGP NLRI which carries traffic flow
=0A
  = ; specification filter, and an Extended community value which encodes=0A
   actions a routing system can take if the packet matc= hes the traffic
=0A
   flow filters.  The flow fil= ters and the actions are processed in a
=0A
   fixed or= der.  Other drafts specify IPv6, MPLS addresses, L2VPN
=0A
&= nbsp;  addresses, and NV03 encapsulation of IP addresses.
=0A 
=0A
   This document updates RFC5575 to correc= t unclear specifications in
=0A
   the flow filters and= to provide rules for actions which interfere
=0A
   (e= .g. redirection of traffic and flow filtering).
=0A
 
= =0A
   Applications which use the bgp flow specification are= : 1) application
=0A
   which automate of inter-domain = coordination of traffic filtering,
=0A
   such as what = is required in order to mitigate (distributed) denial-
=0A
 =   of-service attacks; 2) application which control traffic filtering = in
=0A
   the context of a BGP/MPLS VPN service, and 3)= applications with
=0A
   centralized control of traffi= c in a SDN or NFV context.  Some of
=0A
   deploym= ents of these three applications can be handled by the strict
=0A   ordering of the BGP NLRI traffic flow filters, and the stric= t actions
=0A
   encoded in the Extended Community Flow= Specification actions.
=0A
 
=0A
 
=0AThe IETF datatracker status page for this draft is:
=0A
https:= //datatracker.ietf.org/doc/draft-ietf-idr-rfc5575bis/
=0A
 <= /div>=0A
There's also a htmlized version available at:
=0A
ht= tps://tools.ietf.org/html/draft-ietf-idr-rfc5575bis-00
=0A
 =
=0A
 
=0A
Please note that it may take a couple of= minutes from the time of submission
=0A
until the htmlized versi= on and diff are available at tools.ietf.org.
=0A
 
=0A<= div>Internet-Drafts are also available by anonymous FTP at:
=0A
f= tp://ftp.ietf.org/internet-drafts/
=0A
 
=0A
______= _________________________________________
=0A
Idr mailing list=0A
Idr@ietf.org
=0A
https://www.ietf.org/mailman/listinfo= /idr
=0A
 
=0A
=0A ------=_001_NextPart515324677571_=------ From nobody Fri Mar 3 02:23:26 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ED79129459 for ; Fri, 3 Mar 2017 02:23:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tUUAhzCHzIck for ; Fri, 3 Mar 2017 02:23:19 -0800 (PST) Received: from mail.hated.at (mail.hated.at [IPv6:2001:858:2:8::235]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 276CF12943E for ; Fri, 3 Mar 2017 02:23:18 -0800 (PST) Received: from 80-110-123-147.cgn.dynamic.surfer.at ([80.110.123.147] helo=[192.168.66.245]) by mail.hated.at with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1cjkBo-0006UT-Sx; Fri, 03 Mar 2017 11:11:57 +0100 Content-Type: multipart/signed; boundary="Apple-Mail=_AAD773C0-1ACC-458F-BD80-7CE0E79EE963"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Christoph Loibl X-Priority: 3 In-Reply-To: <2017030317434995427747@chinamobile.com> Date: Fri, 3 Mar 2017 11:23:12 +0100 Message-Id: References: <148784903318.20350.3977002902067988959.idtracker@ietfa.amsl.com> <2017030317434995427747@chinamobile.com> To: "lizhenqiang@chinamobile.com" X-Mailer: Apple Mail (2.3259) Archived-At: Cc: idr Subject: Re: [Idr] I-D Action: draft-ietf-idr-rfc5575bis-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 10:23:22 -0000 --Apple-Mail=_AAD773C0-1ACC-458F-BD80-7CE0E79EE963 Content-Type: multipart/alternative; boundary="Apple-Mail=_23C66BC7-AD6B-432E-96B1-05BAE4673DBD" --Apple-Mail=_23C66BC7-AD6B-432E-96B1-05BAE4673DBD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, There are 5 basic actions (extended community sub-type 6,7,8,9,TBD =3D = traffic-rate-bytes, traffic-action, redirect, traffic-marking, = traffic-rate-packets). However for the redirect action there exist 3 = different route-target encoding formats (extended community sub-type = 0x08 + type 0x80, 0x81 and 0x82): | 0x8008 | redirect AS-2byte | 2-octet AS, 4-octet value | | 0x8108 | redirect IPv4 | 4-octet IPv4 addres, 2-octet | | | | value | | 0x8208 | redirect AS-4byte | 4-octet AS, 2-octet value | These three encoding formats are explained in our draft section 7.4 (IP = Redirect sub-type 0x08) and basically use the same encoding as described = in RFC 4360 and RFC 5668. Do you think that additional clarification or a cross-reference from the = table to this secion is needed for each action? Cheers, Christoph > On 3 Mar 2017, at 10:43, lizhenqiang@chinamobile.com wrote: >=20 > Hi, >=20 > I am reading this draft. I noticed that there are 7 actions listed in = table 2. But Only 5 of them are illustrated in section 7. Actions for = type 0x8108 and 0x8208 are not explained in this section. No references = are given here. May I know the reason? Thanks. >=20 > Best Regards, > lizhenqiang@chinamobile.com >=20 > From: internet-drafts@ietf.org > Date: 2017-02-23 19:23 > To: i-d-announce@ietf.org > CC: idr@ietf.org > Subject: [Idr] I-D Action: draft-ietf-idr-rfc5575bis-00.txt >=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 of the IETF. >=20 > Title : Dissemination of Flow Specification Rules > Authors : Susan Hares > Robert Raszuk > Danny McPherson > Christoph Loibl > Martin Bacher > Filename : draft-ietf-idr-rfc5575bis-00.txt > Pages : 30 > Date : 2017-02-22 >=20 > Abstract: > This document updates RFC5575 which defines a Border Gateway = Protocol > Network Layer Reachability Information (BGP NLRI) encoding format > that can be used to distribute traffic flow specifications. This > allows the routing system to propagate information regarding more > specific components of the traffic aggregate defined by an IP > destination prefix. This draft specifies IPv4 traffic flow > specifications via a BGP NLRI which carries traffic flow > specification filter, and an Extended community value which encodes > actions a routing system can take if the packet matches the traffic > flow filters. The flow filters and the actions are processed in a > fixed order. Other drafts specify IPv6, MPLS addresses, L2VPN > addresses, and NV03 encapsulation of IP addresses. >=20 > This document updates RFC5575 to correct unclear specifications in > the flow filters and to provide rules for actions which interfere > (e.g. redirection of traffic and flow filtering). >=20 > Applications which use the bgp flow specification are: 1) = application > which automate of inter-domain coordination of traffic filtering, > such as what is required in order to mitigate (distributed) denial- > of-service attacks; 2) application which control traffic filtering = in > the context of a BGP/MPLS VPN service, and 3) applications with > centralized control of traffic in a SDN or NFV context. Some of > deployments of these three applications can be handled by the = strict > ordering of the BGP NLRI traffic flow filters, and the strict = actions > encoded in the Extended Community Flow Specification actions. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-idr-rfc5575bis/ = >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-idr-rfc5575bis-00 = >=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 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr = -- Christoph Loibl c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | = http://www.nextlayer.at --Apple-Mail=_23C66BC7-AD6B-432E-96B1-05BAE4673DBD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi,

There = are 5 basic actions (extended community sub-type 6,7,8,9,TBD =3D = traffic-rate-bytes, traffic-action, redirect, traffic-marking, = traffic-rate-packets). However for the redirect action there exist 3 = different route-target encoding formats (extended community sub-type = 0x08 + type 0x80, 0x81 and 0x82):

| 0x8008 | redirect AS-2byte    | 2-octet AS, 4-octet value         =
|
| 0x8108 | redirect IPv4        | 4-octet IPv4 addres, 2-octet      |
|        |                      | value                             |
| 0x8208 | redirect AS-4byte    | 4-octet AS, 2-octet value         =
|

These three = encoding formats are explained in our draft section 7.4 (IP Redirect = sub-type 0x08) and basically use the same encoding as described in RFC = 4360 and RFC 5668. 

Do you think that additional clarification or a = cross-reference from the table to this secion is needed for each = action?

Cheers, 

Christoph


On 3 Mar 2017, at 10:43, lizhenqiang@chinamobile.com wrote:

Hi,

I am reading this draft. I noticed that there are 7 actions = listed in table 2. But Only 5 of them are illustrated in section 7. = Actions for type 0x8108 and 0x8208 are not explained in this section. No = references are given here. May I know the reason? Thanks.

Best Regards,
 
From: internet-drafts@ietf.org
Date: 2017-02-23 19:23
To: i-d-announce@ietf.org
CC: idr@ietf.org
Subject: [Idr] I-D Action: = draft-ietf-idr-rfc5575bis-00.txt
 
A New Internet-Draft is available = from the on-line Internet-Drafts directories.
This = draft is a work item of the Inter-Domain Routing of the IETF.
 
        = Title           : = Dissemination of Flow Specification Rules
        = Authors         : Susan = Hares
          &nb= sp;            = ;   Robert Raszuk
          &nb= sp;            = ;   Danny McPherson
          &nb= sp;            = ;   Christoph Loibl
          &nb= sp;            = ;   Martin Bacher
Filename        : = draft-ietf-idr-rfc5575bis-00.txt
Pages         &nbs= p; : 30
Date          = ;  : 2017-02-22
 
Abstract:
   This document = updates RFC5575 which defines a Border Gateway Protocol
   Network Layer Reachability Information (BGP = NLRI) encoding format
   that can be used = to distribute traffic flow specifications.  This
   allows the routing system to propagate = information regarding more
   specific = components of the traffic aggregate defined by an IP
   destination prefix.  This draft specifies = IPv4 traffic flow
   specifications via a = BGP NLRI which carries traffic flow
   = specification filter, and an Extended community value which = encodes
   actions a routing system can = take if the packet matches the traffic
   = flow filters.  The flow filters and the actions are processed in = a
   fixed order.  Other drafts = specify IPv6, MPLS addresses, L2VPN
   = addresses, and NV03 encapsulation of IP addresses.
 
   This document = updates RFC5575 to correct unclear specifications in
   the flow filters and to provide rules for = actions which interfere
   (e.g. = redirection of traffic and flow filtering).
 
   Applications which = use the bgp flow specification are: 1) application
   which automate of inter-domain coordination of = traffic filtering,
   such as what is = required in order to mitigate (distributed) denial-
   of-service attacks; 2) application which control = traffic filtering in
   the context of a = BGP/MPLS VPN service, and 3) applications with
   centralized control of traffic in a SDN or NFV = context.  Some of
   deployments of = these three applications can be handled by the strict
   ordering of the BGP NLRI traffic flow filters, = and the strict actions
   encoded in the = Extended Community Flow Specification actions.
 
 
The = IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-idr-rfc5575bis/=
 
There's also a = htmlized version available at:
https://tools.ietf.org/html/draft-ietf-idr-rfc5575bis-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/
 
_______________________________________________
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

-- 
Christoph Loibl
c@tix.at | CL8-RIPE | = PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at

= --Apple-Mail=_23C66BC7-AD6B-432E-96B1-05BAE4673DBD-- --Apple-Mail=_AAD773C0-1ACC-458F-BD80-7CE0E79EE963 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAli5RBMACgkQ0m2Mp0ssAFXN1QCbBdOJvan802aYSgy0KaxY8vv9 uKgAnA6+3ZtuscdJapMVoFXQVGo/0khT =c5Wa -----END PGP SIGNATURE----- --Apple-Mail=_AAD773C0-1ACC-458F-BD80-7CE0E79EE963-- From nobody Fri Mar 3 06:55:49 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5150012958D for ; Fri, 3 Mar 2017 06:55:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7fhRbKVbAGVj for ; Fri, 3 Mar 2017 06:55:42 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0105.outbound.protection.outlook.com [104.47.0.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 734A01295AA for ; Fri, 3 Mar 2017 06:55:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=y1/EQ1PRQPB+X0P3UiLGWSY8GerIs6jxyUBuwrFKKPA=; b=XU/+c43NWvV6DMz4Jk2RsIBiuaTeh+5mlx8/apQxu5uMALo/ehzGW+ciT7YyONvmFbctXS9eQOOdrEh2JKHztNQiouyDXM+RR/BfCyTfPuTz7H5z0KNDOUHKY21bsAcPXpyMITgCrP0DLfcP9Zr31Xz+VVlrJqAzjArlMV5diuw= Received: from AM4PR07MB1715.eurprd07.prod.outlook.com (10.166.133.23) by AM4PR07MB1713.eurprd07.prod.outlook.com (10.166.133.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.2; Fri, 3 Mar 2017 14:55:39 +0000 Received: from AM4PR07MB1715.eurprd07.prod.outlook.com ([10.166.133.23]) by AM4PR07MB1715.eurprd07.prod.outlook.com ([10.166.133.23]) with mapi id 15.01.0947.012; Fri, 3 Mar 2017 14:55:39 +0000 From: "Van De Velde, Gunter (Nokia - BE)" To: idr Thread-Topic: New Version Notification for draft-vandevelde-idr-bgp-ls-segment-routing-rld-01.txt Thread-Index: AQHSlC44kCQCnRFeakuCItibeIgUnw== Date: Fri, 3 Mar 2017 14:55:39 +0000 Message-ID: <4BF12F22-F605-406F-9CD8-ACE350B981D0@alcatel-lucent.com> References: <148854728632.10105.590253116263033290.idtracker@ietfa.amsl.com> In-Reply-To: <148854728632.10105.590253116263033290.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [135.245.240.250] x-ms-office365-filtering-correlation-id: 54ccac15-efe9-45d4-1c9a-08d462455b98 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:AM4PR07MB1713; x-microsoft-exchange-diagnostics: 1; AM4PR07MB1713; 7:ktHZ3rRW+32C2wtNlOjqVd7tSI5+8JYTfnuV2FX06Yy9fJRPzG01io7O+xfSaGQgtpjm17YyCAHxgPdSkU0h1KrYDX1wYasippryBXvW1bxW3B8ejglzRaXcmV+gFv2PDsP86r/A1i+ffevA5A/Gg0A9VYRHSWTVMcwMT83UznjgT52RsSjaEJf/hp1AGcWfvetZ5BrxRFZ6TQStPjFIRMTFn+UAhubYb/OdBoRebCJbGWVtL8oqYn219Bc6sYN7sn455+sOtkwXo6/uUvo8DdUk3cRs0pEDUHi0ZyPxr0znzLzeogBQd1JfiJbstDioj+jMMhlf3/W9m9NCNS2YpQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123558025)(20161123562025)(20161123564025)(20161123560025)(20161123555025)(6072148); SRVR:AM4PR07MB1713; BCL:0; PCL:0; RULEID:; SRVR:AM4PR07MB1713; x-forefront-prvs: 0235CBE7D0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(39860400002)(39840400002)(39850400002)(39410400002)(377424004)(24454002)(6116002)(2906002)(8676002)(106116001)(450100001)(81166006)(83716003)(3280700002)(102836003)(77096006)(8936002)(2900100001)(92566002)(36756003)(122556002)(53546006)(82746002)(5660300001)(76176999)(53936002)(6506006)(3846002)(38730400002)(189998001)(6306002)(54356999)(25786008)(229853002)(9686003)(6486002)(6512007)(86362001)(110136004)(33656002)(99286003)(50986999)(3660700001)(66066001)(2950100002)(305945005)(7736002)(230783001)(6916009)(6436002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR07MB1713; H:AM4PR07MB1715.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <0638F890DC9D3B40B667A49E70B48F78@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Mar 2017 14:55:39.3480 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB1713 Archived-At: Subject: [Idr] FW: New Version Notification for draft-vandevelde-idr-bgp-ls-segment-routing-rld-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 14:55:44 -0000 SGVhZHMtdXDigKYgSGFwcHkgdG8gbGVhcm4gZmVlZGJhY2sgYW5kIGNvbW1lbnRzLg0KDQpUaGlz IGRyYWZ0IGlzIHNob3J0IGFuZCBkZWZpbmVzIHRoZSBhdHRyaWJ1dGUgdG8gdXNlIGZvciBCR1At TFMgdG8gZXhwb3NlIGEgDQpub2RlIFJMRCAiUmVhZGFibGUgTGFiZWwgRGVwdGgiIHRvIGEgY2Vu dHJhbGlzZWQgY29udHJvbGxlciAoUENFL1NETikuDQoNCkcvDQoNCk9uIDAzLzAzLzIwMTcsIDE0 OjIxLCAiaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIiA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn PiB3cm90ZToNCg0KICAgIA0KICAgIEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC12YW5kZXZl bGRlLWlkci1iZ3AtbHMtc2VnbWVudC1yb3V0aW5nLXJsZC0wMS50eHQNCiAgICBoYXMgYmVlbiBz dWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEd1bnRlciBWYW4gZGUgVmVsZGUgYW5kIHBvc3RlZCB0 byB0aGUNCiAgICBJRVRGIHJlcG9zaXRvcnkuDQogICAgDQogICAgTmFtZToJCWRyYWZ0LXZhbmRl dmVsZGUtaWRyLWJncC1scy1zZWdtZW50LXJvdXRpbmctcmxkDQogICAgUmV2aXNpb246CTAxDQog ICAgVGl0bGU6CQlTaWduYWxsaW5nIFJMRCB1c2luZyBCR1AtTFMNCiAgICBEb2N1bWVudCBkYXRl OgkyMDE3LTAzLTAzDQogICAgR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCiAgICBQYWdl czoJCTUNCiAgICBVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzL2RyYWZ0LXZhbmRldmVsZGUtaWRyLWJncC1scy1zZWdtZW50LXJvdXRpbmctcmxkLTAx LnR4dA0KICAgIFN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC12YW5kZXZlbGRlLWlkci1iZ3AtbHMtc2VnbWVudC1yb3V0aW5nLXJsZC8NCiAgICBI dG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXZhbmRldmVs ZGUtaWRyLWJncC1scy1zZWdtZW50LXJvdXRpbmctcmxkLTAxDQogICAgRGlmZjogICAgICAgICAg IGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC12YW5kZXZlbGRlLWlkci1i Z3AtbHMtc2VnbWVudC1yb3V0aW5nLXJsZC0wMQ0KICAgIA0KICAgIEFic3RyYWN0Og0KICAgICAg IFRoaXMgZG9jdW1lbnQgZGVmaW5lcyB0aGUgYXR0cmlidXRlIHRvIHVzZSBmb3IgQkdQLUxTIHRv IGV4cG9zZSBhDQogICAgICAgbm9kZSBSTEQgIlJlYWRhYmxlIExhYmVsIERlcHRoIiB0byBhIGNl bnRyYWxpc2VkIGNvbnRyb2xsZXIgKFBDRS8NCiAgICAgICBTRE4pLg0KICAgIA0KICAgIA0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICANCiAgICANCiAgICBQbGVhc2Ugbm90ZSB0 aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJt aXNzaW9uDQogICAgdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWls YWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCiAgICANCiAgICBUaGUgSUVURiBTZWNyZXRhcmlhdA0K ICAgIA0KICAgIA0KDQo= From nobody Fri Mar 3 12:48:30 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C57FF129602 for ; Fri, 3 Mar 2017 12:48:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bFRny4fYSADk for ; Fri, 3 Mar 2017 12:48:27 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id E50661293E1 for ; Fri, 3 Mar 2017 12:48:26 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 4A2EC1E32F; Fri, 3 Mar 2017 15:54:19 -0500 (EST) Date: Fri, 3 Mar 2017 15:54:19 -0500 From: Jeffrey Haas To: "Van De Velde, Gunter (Nokia - BE)" Message-ID: <20170303205419.GA25052@pfrc.org> References: <148854728632.10105.590253116263033290.idtracker@ietfa.amsl.com> <4BF12F22-F605-406F-9CD8-ACE350B981D0@alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4BF12F22-F605-406F-9CD8-ACE350B981D0@alcatel-lucent.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: idr Subject: Re: [Idr] FW: New Version Notification for draft-vandevelde-idr-bgp-ls-segment-routing-rld-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 20:48:29 -0000 Gunter, On Fri, Mar 03, 2017 at 02:55:39PM +0000, Van De Velde, Gunter (Nokia - BE) wrote: > Heads-up… Happy to learn feedback and comments. > > This draft is short and defines the attribute to use for BGP-LS to expose a > node RLD "Readable Label Depth" to a centralised controller (PCE/SDN). This seems like a good idea. I was not aware of the work in the other area, so I believe my primary commment needs to go elsewhere as well: While it's true that a given node may have a given limit on its readable depth, this may potentially vary on a per interface basis. What's the intent, if any, to accommodate something beyond the least common denominator? Editorial nit, your references point to the ospf document twice. -- Jeff From nobody Fri Mar 3 12:49:05 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFF10129608 for ; Fri, 3 Mar 2017 12:49:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b9BSh8-IEibV for ; Fri, 3 Mar 2017 12:49:02 -0800 (PST) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::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 35948129528 for ; Fri, 3 Mar 2017 12:49:02 -0800 (PST) Received: by mail-pf0-x22d.google.com with SMTP id e66so18083802pfe.1 for ; Fri, 03 Mar 2017 12:49:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:message-id:thread-topic :mime-version:content-transfer-encoding; bh=v/lIHuwk10l5HCbn+iDP1g31LqoeFHbcXB7TfxTPgE4=; b=KpmxLTw3dDRJn5/5vfN0/kN9DDNMtDgeZH4OgPWUpoUpgSj+tj4OVcLn1LVKICZJOz Mudouw1NIFLm2DrC/JuSIXj8GX18uYqPY/M65BobKpFz2LKAGgDsUwd+0h77JGu4qoTu Fei4Q1rOTgBkq/SEVwiPwXUJeWxDnUJuNv/+biErjXi9dx/LTYM1bctl7sTq8MkCTSyy iJdqMUdokbpAM0oL9CnmunVkuuWSz+teSa3ExrweMlm9JoLr6SlkDHivr5WrwbCuCzOI teydHHoRQzHW33rGYJ/SuGR03jk61f7p+gwS7Ai+DzEcCg4l0W4ouOL/6Cg4naQwd9Ps uCmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:mime-version:content-transfer-encoding; bh=v/lIHuwk10l5HCbn+iDP1g31LqoeFHbcXB7TfxTPgE4=; b=D9yawYeb5Ewb9/LO4+IDcdtjhhtxt3/z7VbKZxjgPCR9nWY9fBjXwM1wwf5UIin4in mEeHx0GaYDB2abfCMRS/trPVMxPaOH5tH+kypWUr0cgJuPz5MwgSK1je7CMhH6BikaCO Fi0EmFCEqbWpKozh45V72LAs1FFwT4hFyc6KECAjlBLCXSo+9oNw+2m8ERXgjauXcFCf juso6EHrbeGhjrxJIHEBI6gXe+uoKnq22Kz7WJs1dl7cEg00RXOx5z0Xh4+YbcxFEYLo rcjvqQ/FUDLcpaZ93mNkzF98y2k6JW887heK/bBc07k+30XBmCuuPzaR64G0qx1Fu5iY bKnw== X-Gm-Message-State: AMke39n3YSgJXa0r7SWOyof8NFq6ZdUxg+BzUh0Xw6Uigx4VwoWtTSA54R28f66ETl3QXg== X-Received: by 10.84.231.9 with SMTP id f9mr663478plk.117.1488574141703; Fri, 03 Mar 2017 12:49:01 -0800 (PST) Received: from [192.168.254.57] (107-1-141-74-ip-static.hfc.comcastbusiness.net. [107.1.141.74]) by smtp.gmail.com with ESMTPSA id j62sm25176204pgc.54.2017.03.03.12.49.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Mar 2017 12:49:00 -0800 (PST) User-Agent: Microsoft-MacOutlook/f.1f.0.170216 Date: Fri, 03 Mar 2017 12:48:59 -0800 From: Jeff Tantsura To: "Van De Velde, Gunter (Nokia - BE)" , idr Message-ID: <952FA19E-4DBF-4141-BBAC-AC69E56F0E4F@gmail.com> Thread-Topic: [Idr] FW: New Version Notification for draft-vandevelde-idr-bgp-ls-segment-routing-rld-01.txt Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [Idr] FW: New Version Notification for draft-vandevelde-idr-bgp-ls-segment-routing-rld-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 20:49:04 -0000 Hi Gunter, If it is up to a controller to setup EL, this extension needed, same way as= described in the IGP drafts. I=E2=80=99d questions usefulness of RLD outsldie of Entropy Labels use case. Transit nodes in general are not interested in the full label stack conten= t outside of entropy use case. Even if the node in question can=E2=80=99t read whole stack, it can still proper= ly forward the packet, perhaps with less optimal hasing. Using RLD as a contsrain in path computation doesn=E2=80=99t seem to be a right t= hing to do. Thanks! Cheers, Jeff =20 On 3/3/17, 06:55, "Idr on behalf of Van De Velde, Gunter (Nokia - BE)" wrote: Heads-up=E2=80=A6 Happy to learn feedback and comments. =20 This draft is short and defines the attribute to use for BGP-LS to expo= se a=20 node RLD "Readable Label Depth" to a centralised controller (PCE/SDN). =20 G/ =20 On 03/03/2017, 14:21, "internet-drafts@ietf.org" wrote: =20 =20 A new version of I-D, draft-vandevelde-idr-bgp-ls-segment-routing-r= ld-01.txt has been successfully submitted by Gunter Van de Velde and posted t= o the IETF repository. =20 Name: draft-vandevelde-idr-bgp-ls-segment-routing-rld Revision: 01 Title: Signalling RLD using BGP-LS Document date: 2017-03-03 Group: Individual Submission Pages: 5 URL: https://www.ietf.org/internet-drafts/draft-vandevel= de-idr-bgp-ls-segment-routing-rld-01.txt Status: https://datatracker.ietf.org/doc/draft-vandevelde-i= dr-bgp-ls-segment-routing-rld/ Htmlized: https://tools.ietf.org/html/draft-vandevelde-idr-bg= p-ls-segment-routing-rld-01 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-vandevelde-= idr-bgp-ls-segment-routing-rld-01 =20 Abstract: This document defines the attribute to use for BGP-LS to expose = a node RLD "Readable Label Depth" to a centralised controller (PCE= / SDN). =20 =20 = =20 =20 =20 Please note that it may take a couple of minutes from the time of s= ubmission until the htmlized version and diff are available at tools.ietf.org= . =20 The IETF Secretariat =20 =20 =20 _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr =20 From nobody Fri Mar 3 12:52:04 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5788E129608 for ; Fri, 3 Mar 2017 12:52:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZMrCjqzkhp_s for ; Fri, 3 Mar 2017 12:52:01 -0800 (PST) Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AFC1129528 for ; Fri, 3 Mar 2017 12:52:01 -0800 (PST) Received: by mail-pg0-x233.google.com with SMTP id b129so47524666pgc.2 for ; Fri, 03 Mar 2017 12:52:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version:content-transfer-encoding; bh=rL2d3oHQEMujlhmlYY41MZQ2PCLYYkaaEJOa4JaIaXk=; b=RZLP9X75vstAPLztaxMk9J5IyM2pUvIJ1Myjwa9Jhd1o5+Vc7G1lP5O/ceW/jSDhDt ek7MPiqMsvV1mUp7H1dKIz8uaHzaJBuqEsDUr5ajrc2uxYiSt4SmHwnHpKvlpOcKlnpE jsuEcJn9bHDPWXiWbuOqLQqMp1Is9i73Pk5hBGsifp0M1I4XKwyoOZppwaiG4BiccEKg bxyVUBbHuzxVNzIFmONLR5gNNJrubwO/1ckINWk7JZyQHqjoElpfZA+4K3c8JboTscyd kaCkrY3B4hx7cK8eHl2Lkl3v7WRhI8siLDrUt+vwujCAlL/KiBT1b/tLQPhoQBZ39QHR decw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=rL2d3oHQEMujlhmlYY41MZQ2PCLYYkaaEJOa4JaIaXk=; b=mCPX86gICd9JK4njpUKulMqwjJJ1MdpIxm5i7vY6VoJWq09AYji9tRK7sIrfiwuJ3I eseiXVkc9AUYIPpgRkRRN+ulX/mR7VPpoZrPFnxWO3pXCdjgW2sgek3Z48pk0qw62HHj WrHsDPGb1XLwhegsAqDfeGxRsOg3oR3cHs74LhKWp0apNw2UHKidV3VaBhTeeakMq9jQ 4z/Ui8+rStRbNYzwKmqVtqEdL00FcLB9Yh9Ud7WR1REtl6Edp7P8KafVPSQQt0oVkROG GxJwzi29xufOeNc+pe69uz4dz47plJxonUz0ESOy91FD2reeGGFufdsw9g7eeZouCWFa xLCw== X-Gm-Message-State: AMke39nAkWzvMGti56wIr85IKU01oN2l2n+v5CaeHe9pg51VQUBIkj6Sy5oLRX6ZNbpEPg== X-Received: by 10.98.61.209 with SMTP id x78mr5841716pfj.88.1488574320647; Fri, 03 Mar 2017 12:52:00 -0800 (PST) Received: from [192.168.254.57] (107-1-141-74-ip-static.hfc.comcastbusiness.net. [107.1.141.74]) by smtp.gmail.com with ESMTPSA id j62sm25176204pgc.54.2017.03.03.12.51.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Mar 2017 12:51:59 -0800 (PST) User-Agent: Microsoft-MacOutlook/f.1f.0.170216 Date: Fri, 03 Mar 2017 12:51:59 -0800 From: Jeff Tantsura To: Jeffrey Haas , "Van De Velde, Gunter (Nokia - BE)" Message-ID: <55650B47-5E14-4484-A841-C773CB9F03C2@gmail.com> Thread-Topic: [Idr] FW: New Version Notification for draft-vandevelde-idr-bgp-ls-segment-routing-rld-01.txt References: <148854728632.10105.590253116263033290.idtracker@ietfa.amsl.com> <4BF12F22-F605-406F-9CD8-ACE350B981D0@alcatel-lucent.com> <20170303205419.GA25052@pfrc.org> In-Reply-To: <20170303205419.GA25052@pfrc.org> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Cc: idr Subject: Re: [Idr] FW: New Version Notification for draft-vandevelde-idr-bgp-ls-segment-routing-rld-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 20:52:02 -0000 Jeff, This is the approach taken in MSD (Max SID Depth )drafts (IGPs/BGP), both n= ode and link values can be signaled. =20 Cheers, Jeff =20 On 3/3/17, 12:54, "Idr on behalf of Jeffrey Haas" wrote: Gunter, =20 On Fri, Mar 03, 2017 at 02:55:39PM +0000, Van De Velde, Gunter (Nokia -= BE) wrote: > Heads-up=E2=80=A6 Happy to learn feedback and comments. >=20 > This draft is short and defines the attribute to use for BGP-LS to ex= pose a=20 > node RLD "Readable Label Depth" to a centralised controller (PCE/SDN)= . =20 This seems like a good idea. I was not aware of the work in the other = area, so I believe my primary commment needs to go elsewhere as well: =20 While it's true that a given node may have a given limit on its readabl= e depth, this may potentially vary on a per interface basis. What's the intent, if any, to accommodate something beyond the least common denominator? =20 Editorial nit, your references point to the ospf document twice. =20 -- Jeff =20 _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr =20 From nobody Fri Mar 3 13:24:58 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E5FC129632 for ; Fri, 3 Mar 2017 13:24:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G3-EU7_K7gBm for ; Fri, 3 Mar 2017 13:24:54 -0800 (PST) Received: from st13p11im-asmtp003.me.com (st13p11im-asmtp003.me.com [17.164.40.218]) (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 5C8321294AE for ; Fri, 3 Mar 2017 13:24:47 -0800 (PST) Received: from process-dkim-sign-daemon.st13p11im-asmtp003.me.com by st13p11im-asmtp003.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0OM900C00CP73200@st13p11im-asmtp003.me.com> for idr@ietf.org; Fri, 03 Mar 2017 21:24:46 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=4d515a; t=1488576285; bh=vWuJS/bIBTGW8OCE1kjCnWZ7ZYOcyxvDatzhG5H8lB8=; h=Content-type:MIME-version:Subject:From:Date:Message-id:To; b=OTwfo8uXOFeMNoK0ySQRrdO7YJvRQZ/845YaTVTJwEVANKNFs08yniyECbfuXyYmQ Zz0HPRmjnoxvpfjFgEK4LP6SZsr+csm9BrNBDcWvykO+4wsvZ79/+fBLRtOuDtH2N+ pCpbl+Q+RLmUKU9hiePIAaKYpwKY9Cx9xEh0kTILdWz7tnnxzRWgH9BsMS9YGUpxzX 1Sx9VoVo/dMC7X5DKnimC9Gfj63gvJ05zy4aXN07b0tgtEWJRD4MqBy1T3IIos7e9E Ue7ab7ffFiJ/I+aLIIrB//ZogsqwJu3xL9T0C40keXCqTAh9s93+zMYdUXf1mx6jAz LuT+ipnBv4qow== Received: from icloud.com ([127.0.0.1]) by st13p11im-asmtp003.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTPSA id <0OM900MM7CT7GD50@st13p11im-asmtp003.me.com>; Fri, 03 Mar 2017 21:24:45 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-03-03_16:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1034 suspectscore=3 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1701120000 definitions=main-1703030189 Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Gunter Van De Velde In-reply-to: <20170303205419.GA25052@pfrc.org> Date: Fri, 03 Mar 2017 22:24:42 +0100 Content-transfer-encoding: quoted-printable Message-id: <86F2E6F9-2CCE-4EDC-9323-7DB6A806D603@icloud.com> References: <148854728632.10105.590253116263033290.idtracker@ietfa.amsl.com> <4BF12F22-F605-406F-9CD8-ACE350B981D0@alcatel-lucent.com> <20170303205419.GA25052@pfrc.org> To: Jeffrey Haas X-Mailer: Apple Mail (2.3259) Archived-At: Cc: idr , "Van De Velde, Gunter \(Nokia - BE\)" Subject: Re: [Idr] FW: New Version Notification for draft-vandevelde-idr-bgp-ls-segment-routing-rld-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 21:24:56 -0000 Yes, Indeed we already had a -02 version nearly ready with mentioning = Link also in addition to node. When i was writing the text i was in doubt to add it or not, but now = indeed i think its best to add. G/ > On 3 Mar 2017, at 21:54, Jeffrey Haas wrote: >=20 > Gunter, >=20 > On Fri, Mar 03, 2017 at 02:55:39PM +0000, Van De Velde, Gunter (Nokia = - BE) wrote: >> Heads-up=E2=80=A6 Happy to learn feedback and comments. >>=20 >> This draft is short and defines the attribute to use for BGP-LS to = expose a=20 >> node RLD "Readable Label Depth" to a centralised controller = (PCE/SDN). >=20 > This seems like a good idea. I was not aware of the work in the other = area, > so I believe my primary commment needs to go elsewhere as well: >=20 > While it's true that a given node may have a given limit on its = readable > depth, this may potentially vary on a per interface basis. What's the > intent, if any, to accommodate something beyond the least common > denominator? >=20 > Editorial nit, your references point to the ospf document twice. >=20 > -- Jeff >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Fri Mar 3 13:27:05 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0594112962C for ; Fri, 3 Mar 2017 13:27:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DykkZoxZ0EV3 for ; Fri, 3 Mar 2017 13:27:02 -0800 (PST) Received: from st13p11im-asmtp004.me.com (st13p11im-asmtp004.me.com [17.164.40.219]) (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 569791294AE for ; Fri, 3 Mar 2017 13:27:02 -0800 (PST) Received: from process-dkim-sign-daemon.st13p11im-asmtp004.me.com by st13p11im-asmtp004.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0OM900100CI00I00@st13p11im-asmtp004.me.com> for idr@ietf.org; Fri, 03 Mar 2017 21:27:01 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=4d515a; t=1488576421; bh=mObPLzjhuoq5/sG+xaV54Exu+sI4pLTI9kCoFLj0Lys=; h=Content-type:MIME-version:Subject:From:Date:Message-id:To; b=sTFQmjL5L6l6HiVRylFSknFVv0McF9U89bGNrGIWIBMkbKhCn5QqknGRe8Z5O5POn 6YXXQYru8OFCoUdRnvMkBRB9T83ZQQ/Ye78JIMmaeNTXrxEKU0T/V18mkfBCWCA4t7 uSo1M7bzBPAO40SBoRk497UagAe+sqM4EdnUByhRfkzUOqdNRB/ctnNr+fWmKcMIC6 JRdUhPw/OKzVxZcA3AYwXbfpOMWHNqlWsljXd+zuDdmSSOpF/jmN8IJnanINUUa6Sv mlrXwqAwZIcTJ5zyfO/Nz6KAEov3xGn+9+0AbsVeK5e1A/usK3Gb7Rp2zT2PpLPKSh BxApR52tAeslg== Received: from icloud.com ([127.0.0.1]) by st13p11im-asmtp004.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTPSA id <0OM9009IUCWZEI30@st13p11im-asmtp004.me.com>; Fri, 03 Mar 2017 21:27:01 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-03-03_16:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1034 suspectscore=3 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1701120000 definitions=main-1703030189 Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Gunter Van De Velde In-reply-to: <952FA19E-4DBF-4141-BBAC-AC69E56F0E4F@gmail.com> Date: Fri, 03 Mar 2017 22:26:58 +0100 Content-transfer-encoding: quoted-printable Message-id: <41BA4B21-FA04-4D00-B84D-AF78E17A2898@icloud.com> References: <952FA19E-4DBF-4141-BBAC-AC69E56F0E4F@gmail.com> To: Jeff Tantsura X-Mailer: Apple Mail (2.3259) Archived-At: Cc: idr , "Van De Velde, Gunter \(Nokia - BE\)" Subject: Re: [Idr] FW: New Version Notification for draft-vandevelde-idr-bgp-ls-segment-routing-rld-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 21:27:04 -0000 There is other use case also to do with Synonimous labels and = measurements (Alternate marking for passive measurements) = potentially=E2=80=A6. Maybe i should add that one also to the use cases. G/ > On 3 Mar 2017, at 21:48, Jeff Tantsura = wrote: >=20 > Hi Gunter, >=20 > If it is up to a controller to setup EL, this extension needed, same = way as described in the IGP drafts. >=20 > I=E2=80=99d questions usefulness of RLD outsldie of Entropy Labels use = case. > Transit nodes in general are not interested in the full label stack = content outside of entropy use case. >=20 > Even if the node in question can=E2=80=99t read whole stack, it can = still properly forward the packet, perhaps with less optimal hasing. > Using RLD as a contsrain in path computation doesn=E2=80=99t seem to = be a right thing to do. >=20 > Thanks! >=20 > Cheers, > Jeff >=20 >=20 > On 3/3/17, 06:55, "Idr on behalf of Van De Velde, Gunter (Nokia - BE)" = wrote: >=20 > Heads-up=E2=80=A6 Happy to learn feedback and comments. >=20 > This draft is short and defines the attribute to use for BGP-LS to = expose a=20 > node RLD "Readable Label Depth" to a centralised controller = (PCE/SDN). >=20 > G/ >=20 > On 03/03/2017, 14:21, "internet-drafts@ietf.org" = wrote: >=20 >=20 > A new version of I-D, = draft-vandevelde-idr-bgp-ls-segment-routing-rld-01.txt > has been successfully submitted by Gunter Van de Velde and = posted to the > IETF repository. >=20 > Name: draft-vandevelde-idr-bgp-ls-segment-routing-rld > Revision: 01 > Title: Signalling RLD using BGP-LS > Document date: 2017-03-03 > Group: Individual Submission > Pages: 5 > URL: = https://www.ietf.org/internet-drafts/draft-vandevelde-idr-bgp-ls-segment-r= outing-rld-01.txt > Status: = https://datatracker.ietf.org/doc/draft-vandevelde-idr-bgp-ls-segment-routi= ng-rld/ > Htmlized: = https://tools.ietf.org/html/draft-vandevelde-idr-bgp-ls-segment-routing-rl= d-01 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-vandevelde-idr-bgp-ls-segment-ro= uting-rld-01 >=20 > Abstract: > This document defines the attribute to use for BGP-LS to = expose a > node RLD "Readable Label Depth" to a centralised controller = (PCE/ > SDN). >=20 >=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 >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >=20 >=20 >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Fri Mar 3 13:58:50 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6F60129648 for ; Fri, 3 Mar 2017 13:58:48 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JzWD82DnqcPA for ; Fri, 3 Mar 2017 13:58:46 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0127.outbound.protection.outlook.com [104.47.2.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19D5B12963A for ; Fri, 3 Mar 2017 13:58:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=35Av/x//bJAKlHbD4jBnLcFy+NP+6XgEus8SdY0TmUs=; b=hzFkPhJc5y61xI8JYQvThoDVmK1stwxXnaC2LPJAYCCdOIFmlZdB1uvouSgno0nUSnP0xROmwkvCimMg1M8cAl5ScVHHa/DSJiaFjwqJEyYYYagcXoJWqWeoJuuWIKeF6dJAwIoQvHPKbSYN9jQ1OgugM1RMXWYpeEB1yfeyk9w= Received: from AM4PR07MB1715.eurprd07.prod.outlook.com (10.166.133.23) by AM4PR07MB1713.eurprd07.prod.outlook.com (10.166.133.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.2; Fri, 3 Mar 2017 21:58:43 +0000 Received: from AM4PR07MB1715.eurprd07.prod.outlook.com ([10.166.133.23]) by AM4PR07MB1715.eurprd07.prod.outlook.com ([10.166.133.23]) with mapi id 15.01.0947.018; Fri, 3 Mar 2017 21:58:43 +0000 From: "Van De Velde, Gunter (Nokia - BE)" To: Gunter Van De Velde , Jeff Tantsura Thread-Topic: [Idr] FW: New Version Notification for draft-vandevelde-idr-bgp-ls-segment-routing-rld-01.txt Thread-Index: AQHSlF+VkCQCnRFeakuCItibeIgUn6GDoQcAgAAZoQA= Date: Fri, 3 Mar 2017 21:58:42 +0000 Message-ID: <7949CB98-F75F-4C04-A9B7-A36642A71B9D@alcatel-lucent.com> References: <952FA19E-4DBF-4141-BBAC-AC69E56F0E4F@gmail.com> <41BA4B21-FA04-4D00-B84D-AF78E17A2898@icloud.com> In-Reply-To: <41BA4B21-FA04-4D00-B84D-AF78E17A2898@icloud.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: icloud.com; dkim=none (message not signed) header.d=none;icloud.com; dmarc=none action=none header.from=nokia.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [81.242.21.60] x-ms-office365-filtering-correlation-id: ac03477b-8b1d-4e64-f541-08d46280755c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:AM4PR07MB1713; x-microsoft-exchange-diagnostics: 1; AM4PR07MB1713; 7:pKYAi+LM+V58Z/VGdr1WYsGqEtj8cyGTdbW9K4H89gne02qL8SDM8PG+HtR5f7ja3V8GcV9ybL4PgXw0dzYpXM7Xb8p6R6ou5qDquWpXLNjjjiZX0mGm8+Jfql5ZcLLmfe64+nYvj7l7LLOxFXtEqB9ALufTW7rcfb0u4tghA6kKIgTOCKvzfyjyoiM4mgtfTt12OeYcul/5qYarXuZffgAXVbl2raNtqL7g93dmpDKAodVeQq0WzxfJg7oz9wKcLGsa4azD5aJZi/k/Quolqif2OngzW68WxF1fuNh7t0bG8kfl3WpWmVpwirQ3/HBSk1m1qL3l44S8DfegRjLkLw== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(84792000423722)(120809045254105)(82608151540597); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123558025)(20161123555025)(20161123564025)(20161123560025)(6072148); SRVR:AM4PR07MB1713; BCL:0; PCL:0; RULEID:; SRVR:AM4PR07MB1713; x-forefront-prvs: 0235CBE7D0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(39860400002)(39840400002)(39850400002)(39410400002)(377424004)(24454002)(2906002)(6116002)(8676002)(106116001)(102836003)(83716003)(2900100001)(81166006)(3280700002)(77096006)(33656002)(8936002)(36756003)(92566002)(4326008)(53546006)(68736007)(82746002)(122556002)(76176999)(230783001)(189998001)(5660300001)(39060400002)(3846002)(6506006)(6246003)(53936002)(6306002)(54356999)(38730400002)(229853002)(25786008)(6486002)(8666007)(9686003)(6512007)(99286003)(86362001)(50986999)(66066001)(3660700001)(305945005)(2950100002)(7736002)(6436002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR07MB1713; H:AM4PR07MB1715.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <018C838441A6DA4E806294438A0308E8@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Mar 2017 21:58:42.8882 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB1713 Archived-At: Cc: idr Subject: Re: [Idr] FW: New Version Notification for draft-vandevelde-idr-bgp-ls-segment-routing-rld-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 21:58:49 -0000 Rm9yIGNvbXBsZXRlbmVzcywgSSB3YXMgcmVmZXJyaW5nIHRvIHRoZSBmb2xsb3dpbmcgd29yayBh cyB1c2UgY2FzZSBvZiB0aGUgUkxEIGluZm8gaW4gYWRkaXRpb24gdG8gZW50cm9weSB1c2UtY2Fz ZToNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1icnlhbnQtbXBscy1zZmwtZnJh bWV3b3JrLTAyDQoNCkcvDQoNCk9uIDAzLzAzLzIwMTcsIDIyOjI2LCAiR3VudGVyIFZhbiBEZSBW ZWxkZSIgPGd1bnRlcnZhbmRldmVsZGVjY0BpY2xvdWQuY29tPiB3cm90ZToNCg0KICAgIFRoZXJl IGlzIG90aGVyIHVzZSBjYXNlIGFsc28gdG8gZG8gd2l0aCBTeW5vbmltb3VzIGxhYmVscyBhbmQg bWVhc3VyZW1lbnRzIChBbHRlcm5hdGUgbWFya2luZyBmb3IgcGFzc2l2ZSBtZWFzdXJlbWVudHMp IHBvdGVudGlhbGx54oCmLg0KICAgIE1heWJlIGkgc2hvdWxkIGFkZCB0aGF0IG9uZSBhbHNvIHRv IHRoZSB1c2UgY2FzZXMuDQogICAgDQogICAgRy8NCiAgICANCiAgICA+IE9uIDMgTWFyIDIwMTcs IGF0IDIxOjQ4LCBKZWZmIFRhbnRzdXJhIDxqZWZmdGFudC5pZXRmQGdtYWlsLmNvbT4gd3JvdGU6 DQogICAgPiANCiAgICA+IEhpIEd1bnRlciwNCiAgICA+IA0KICAgID4gSWYgaXQgaXMgdXAgdG8g YSBjb250cm9sbGVyIHRvIHNldHVwIEVMLCB0aGlzIGV4dGVuc2lvbiBuZWVkZWQsIHNhbWUgd2F5 IGFzIGRlc2NyaWJlZCBpbiB0aGUgSUdQIGRyYWZ0cy4NCiAgICA+IA0KICAgID4gSeKAmWQgcXVl c3Rpb25zIHVzZWZ1bG5lc3Mgb2YgUkxEIG91dHNsZGllIG9mIEVudHJvcHkgTGFiZWxzIHVzZSBj YXNlLg0KICAgID4gVHJhbnNpdCBub2RlcyBpbiAgZ2VuZXJhbCBhcmUgbm90IGludGVyZXN0ZWQg aW4gdGhlIGZ1bGwgbGFiZWwgc3RhY2sgY29udGVudCBvdXRzaWRlIG9mIGVudHJvcHkgdXNlIGNh c2UuDQogICAgPiANCiAgICA+IEV2ZW4gaWYgdGhlIG5vZGUgaW4gcXVlc3Rpb24gIGNhbuKAmXQg cmVhZCB3aG9sZSBzdGFjaywgaXQgY2FuIHN0aWxsIHByb3Blcmx5IGZvcndhcmQgdGhlIHBhY2tl dCwgcGVyaGFwcyB3aXRoIGxlc3Mgb3B0aW1hbCBoYXNpbmcuDQogICAgPiBVc2luZyBSTEQgYXMg YSBjb250c3JhaW4gaW4gcGF0aCBjb21wdXRhdGlvbiBkb2VzbuKAmXQgc2VlbSB0byBiZSBhIHJp Z2h0IHRoaW5nIHRvIGRvLg0KICAgID4gDQogICAgPiBUaGFua3MhDQogICAgPiANCiAgICA+IENo ZWVycywNCiAgICA+IEplZmYNCiAgICA+IA0KICAgID4gDQogICAgPiBPbiAzLzMvMTcsIDA2OjU1 LCAiSWRyIG9uIGJlaGFsZiBvZiBWYW4gRGUgVmVsZGUsIEd1bnRlciAoTm9raWEgLSBCRSkiIDxp ZHItYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgZ3VudGVyLnZhbl9kZV92ZWxkZUBub2tp YS5jb20+IHdyb3RlOg0KICAgID4gDQogICAgPiAgICBIZWFkcy11cOKApiBIYXBweSB0byBsZWFy biBmZWVkYmFjayBhbmQgY29tbWVudHMuDQogICAgPiANCiAgICA+ICAgIFRoaXMgZHJhZnQgaXMg c2hvcnQgYW5kIGRlZmluZXMgdGhlIGF0dHJpYnV0ZSB0byB1c2UgZm9yIEJHUC1MUyB0byBleHBv c2UgYSANCiAgICA+ICAgIG5vZGUgUkxEICJSZWFkYWJsZSBMYWJlbCBEZXB0aCIgdG8gYSBjZW50 cmFsaXNlZCBjb250cm9sbGVyIChQQ0UvU0ROKS4NCiAgICA+IA0KICAgID4gICAgRy8NCiAgICA+ IA0KICAgID4gICAgT24gMDMvMDMvMjAxNywgMTQ6MjEsICJpbnRlcm5ldC1kcmFmdHNAaWV0Zi5v cmciIDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IHdyb3RlOg0KICAgID4gDQogICAgPiANCiAg ICA+ICAgICAgICBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtdmFuZGV2ZWxkZS1pZHItYmdw LWxzLXNlZ21lbnQtcm91dGluZy1ybGQtMDEudHh0DQogICAgPiAgICAgICAgaGFzIGJlZW4gc3Vj Y2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBHdW50ZXIgVmFuIGRlIFZlbGRlIGFuZCBwb3N0ZWQgdG8g dGhlDQogICAgPiAgICAgICAgSUVURiByZXBvc2l0b3J5Lg0KICAgID4gDQogICAgPiAgICAgICAg TmFtZToJCWRyYWZ0LXZhbmRldmVsZGUtaWRyLWJncC1scy1zZWdtZW50LXJvdXRpbmctcmxkDQog ICAgPiAgICAgICAgUmV2aXNpb246CTAxDQogICAgPiAgICAgICAgVGl0bGU6CQlTaWduYWxsaW5n IFJMRCB1c2luZyBCR1AtTFMNCiAgICA+ICAgICAgICBEb2N1bWVudCBkYXRlOgkyMDE3LTAzLTAz DQogICAgPiAgICAgICAgR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCiAgICA+ICAgICAg ICBQYWdlczoJCTUNCiAgICA+ICAgICAgICBVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXZhbmRldmVsZGUtaWRyLWJncC1scy1zZWdtZW50 LXJvdXRpbmctcmxkLTAxLnR4dA0KICAgID4gICAgICAgIFN0YXR1czogICAgICAgICBodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC12YW5kZXZlbGRlLWlkci1iZ3AtbHMtc2Vn bWVudC1yb3V0aW5nLXJsZC8NCiAgICA+ICAgICAgICBIdG1saXplZDogICAgICAgaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXZhbmRldmVsZGUtaWRyLWJncC1scy1zZWdtZW50LXJv dXRpbmctcmxkLTAxDQogICAgPiAgICAgICAgRGlmZjogICAgICAgICAgIGh0dHBzOi8vd3d3Lmll dGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC12YW5kZXZlbGRlLWlkci1iZ3AtbHMtc2VnbWVudC1y b3V0aW5nLXJsZC0wMQ0KICAgID4gDQogICAgPiAgICAgICAgQWJzdHJhY3Q6DQogICAgPiAgICAg ICAgICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIHRoZSBhdHRyaWJ1dGUgdG8gdXNlIGZvciBCR1At TFMgdG8gZXhwb3NlIGENCiAgICA+ICAgICAgICAgICBub2RlIFJMRCAiUmVhZGFibGUgTGFiZWwg RGVwdGgiIHRvIGEgY2VudHJhbGlzZWQgY29udHJvbGxlciAoUENFLw0KICAgID4gICAgICAgICAg IFNETikuDQogICAgPiANCiAgICA+IA0KICAgID4gDQogICAgPiANCiAgICA+IA0KICAgID4gICAg ICAgIFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9t IHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCiAgICA+ICAgICAgICB1bnRpbCB0aGUgaHRtbGl6ZWQg dmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KICAgID4g DQogICAgPiAgICAgICAgVGhlIElFVEYgU2VjcmV0YXJpYXQNCiAgICA+IA0KICAgID4gDQogICAg PiANCiAgICA+ICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQogICAgPiAgICBJZHIgbWFpbGluZyBsaXN0DQogICAgPiAgICBJZHJAaWV0Zi5vcmcNCiAg ICA+ICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRyDQogICAgPiAN CiAgICA+IA0KICAgID4gDQogICAgPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KICAgID4gSWRyIG1haWxpbmcgbGlzdA0KICAgID4gSWRyQGlldGYub3Jn DQogICAgPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkcg0KICAgIA0K ICAgIA0KDQo= From nobody Fri Mar 3 14:25:25 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 404D1129644 for ; Fri, 3 Mar 2017 14:25:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dEQRGdAC2lLr for ; Fri, 3 Mar 2017 14:25:19 -0800 (PST) Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e: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 6025712964D for ; Fri, 3 Mar 2017 14:25:19 -0800 (PST) Received: by mail-pg0-x22a.google.com with SMTP id b129so48143149pgc.2 for ; Fri, 03 Mar 2017 14:25:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version:content-transfer-encoding; bh=IdfVRWg469veVVyAQSZYxtStgXrNgh3sZrVh88Nv1Co=; b=fqpJslP/u8Yf7CT+0GH9IRaY2pP62dBdPIMhdcQjG57Guxqb05p8xZC7j3rOvrijrR 0EKKcKSU/PgArOQ1aztkbIpRpH/eukZPTRdWqLX/Ehz9xeMoCr5INIvEvV882YaJaOyM h52ky0wVqI7wByrSxJxchEou6oOMrT99KLuCXV0FgYgPDAWaYBPmXdr1z6lWobmwrilu ITiqkdZdhOVP5yIH/OLpXLFa+OVAYR5ZpQ9yllQkQJeF7eDTHLfg0wqsKFbPDuQLSqFF ThsFF81OKB286LAjffZ2svpaOXNSpv+UxPhaHGNujUZBpIbTvJp3gRI2nYr8xNk0N30z VX8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=IdfVRWg469veVVyAQSZYxtStgXrNgh3sZrVh88Nv1Co=; b=P+Ktl/cBCe1q/disuLU2Bsk4N+6Qu/6/J44oyMjrtN/EsRVlHJ+iLXOSGjtx8szwLs IndLCydYnM5UzQRNlDMwXDig3ZAN982zjLznJ3MGTFoccRu9sEeBvM/CxidouhFBz9xT E+p0+6HxGxFfppJfyry/r2/6hVaPg2vUbFeoRBkrWmTvJiLaWvZ4skLnhAE14TIoHoJe OSjh9VBuAMLruth3xsxWKEJAeMrVN7oiqJE4llu8R1guwChI3wonUyj1uS2bdiTHHBbQ QMq3IZo5omrfKmKY3R5oy6Glm/06iQTX289R5JzOW277Aj5jSJyI1hKGr4O1jSnnKPgP uDUg== X-Gm-Message-State: AMke39misiEIRdQdv7DRMbVRB2nLDq3/y3vvHLGO+qt2RwhZiMMqy9tCVK5Gi62HaMxEPw== X-Received: by 10.98.112.134 with SMTP id l128mr6209329pfc.81.1488579918924; Fri, 03 Mar 2017 14:25:18 -0800 (PST) Received: from [192.168.254.57] (107-1-141-74-ip-static.hfc.comcastbusiness.net. [107.1.141.74]) by smtp.gmail.com with ESMTPSA id a90sm4764920pfg.78.2017.03.03.14.25.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Mar 2017 14:25:17 -0800 (PST) User-Agent: Microsoft-MacOutlook/f.1f.0.170216 Date: Fri, 03 Mar 2017 14:25:16 -0800 From: Jeff Tantsura To: "Van De Velde, Gunter (Nokia - BE)" , Gunter Van De Velde Message-ID: <0D328A1E-5481-46C2-B94F-D52CC61C203C@gmail.com> Thread-Topic: [Idr] FW: New Version Notification for draft-vandevelde-idr-bgp-ls-segment-routing-rld-01.txt References: <952FA19E-4DBF-4141-BBAC-AC69E56F0E4F@gmail.com> <41BA4B21-FA04-4D00-B84D-AF78E17A2898@icloud.com> <7949CB98-F75F-4C04-A9B7-A36642A71B9D@alcatel-lucent.com> In-Reply-To: <7949CB98-F75F-4C04-A9B7-A36642A71B9D@alcatel-lucent.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Cc: idr Subject: Re: [Idr] FW: New Version Notification for draft-vandevelde-idr-bgp-ls-segment-routing-rld-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 22:25:24 -0000 Aren=E2=80=99t Synonimous labels significant on egress only? =20 Cheers, Jeff =20 On 3/3/17, 13:58, "Van De Velde, Gunter (Nokia - BE)" wrote: For completeness, I was referring to the following work as use case of = the RLD info in addition to entropy use-case: https://tools.ietf.org/html/draft-bryant-mpls-sfl-framework-02 =20 G/ =20 On 03/03/2017, 22:26, "Gunter Van De Velde" wrote: =20 There is other use case also to do with Synonimous labels and measu= rements (Alternate marking for passive measurements) potentially=E2=80=A6. Maybe i should add that one also to the use cases. =20 G/ =20 > On 3 Mar 2017, at 21:48, Jeff Tantsura = wrote: >=20 > Hi Gunter, >=20 > If it is up to a controller to setup EL, this extension needed, s= ame way as described in the IGP drafts. >=20 > I=E2=80=99d questions usefulness of RLD outsldie of Entropy Labels use = case. > Transit nodes in general are not interested in the full label st= ack content outside of entropy use case. >=20 > Even if the node in question can=E2=80=99t read whole stack, it can st= ill properly forward the packet, perhaps with less optimal hasing. > Using RLD as a contsrain in path computation doesn=E2=80=99t seem to be= a right thing to do. >=20 > Thanks! >=20 > Cheers, > Jeff >=20 >=20 > On 3/3/17, 06:55, "Idr on behalf of Van De Velde, Gunter (Nokia -= BE)" wrot= e: >=20 > Heads-up=E2=80=A6 Happy to learn feedback and comments. >=20 > This draft is short and defines the attribute to use for BGP-L= S to expose a=20 > node RLD "Readable Label Depth" to a centralised controller (P= CE/SDN). >=20 > G/ >=20 > On 03/03/2017, 14:21, "internet-drafts@ietf.org" wrote: >=20 >=20 > A new version of I-D, draft-vandevelde-idr-bgp-ls-segment-= routing-rld-01.txt > has been successfully submitted by Gunter Van de Velde and= posted to the > IETF repository. >=20 > Name: draft-vandevelde-idr-bgp-ls-segment-routing-rld > Revision: 01 > Title: Signalling RLD using BGP-LS > Document date: 2017-03-03 > Group: Individual Submission > Pages: 5 > URL: https://www.ietf.org/internet-drafts/draft= -vandevelde-idr-bgp-ls-segment-routing-rld-01.txt > Status: https://datatracker.ietf.org/doc/draft-van= develde-idr-bgp-ls-segment-routing-rld/ > Htmlized: https://tools.ietf.org/html/draft-vandevel= de-idr-bgp-ls-segment-routing-rld-01 > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-va= ndevelde-idr-bgp-ls-segment-routing-rld-01 >=20 > Abstract: > This document defines the attribute to use for BGP-LS t= o expose a > node RLD "Readable Label Depth" to a centralised contro= ller (PCE/ > SDN). >=20 >=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 >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >=20 >=20 >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr =20 =20 =20 =20 From nobody Fri Mar 3 14:36:28 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AFC6129657 for ; Fri, 3 Mar 2017 14:36:27 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KmO-WnCS8WdK for ; Fri, 3 Mar 2017 14:36:25 -0800 (PST) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40099.outbound.protection.outlook.com [40.107.4.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75B0E129644 for ; Fri, 3 Mar 2017 14:36:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=7QWfms5xPjA0u2P/zMLkJssJmKoWGpx4uzvNkbhlff0=; b=gysjgqb29DJL0C+LabD2nQ16zl5n0AF4lmOBRC/ywElhQ9Bg/iRCl3nWm11/G7trRPP+6TITD5kERjQEu2aVd74ROFWqOBru8/vYZc6+g6QoQHUKvFz00dyZJiZjSqUl6aGFUBZ/DIgEq+j+EGGXHRlklgfwjwPlDVTV2DydPfo= Received: from AM4PR07MB1715.eurprd07.prod.outlook.com (10.166.133.23) by AM4PR07MB1715.eurprd07.prod.outlook.com (10.166.133.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.2; Fri, 3 Mar 2017 22:36:20 +0000 Received: from AM4PR07MB1715.eurprd07.prod.outlook.com ([10.166.133.23]) by AM4PR07MB1715.eurprd07.prod.outlook.com ([10.166.133.23]) with mapi id 15.01.0947.018; Fri, 3 Mar 2017 22:36:20 +0000 From: "Van De Velde, Gunter (Nokia - BE)" To: Jeff Tantsura , Gunter Van De Velde Thread-Topic: [Idr] FW: New Version Notification for draft-vandevelde-idr-bgp-ls-segment-routing-rld-01.txt Thread-Index: AQHSlF+VkCQCnRFeakuCItibeIgUn6GDoQcAgAAZoQD///apAIAAE9qA Date: Fri, 3 Mar 2017 22:36:20 +0000 Message-ID: <263F8B4F-5749-439E-A6DA-780E57FFB2E2@alcatel-lucent.com> References: <952FA19E-4DBF-4141-BBAC-AC69E56F0E4F@gmail.com> <41BA4B21-FA04-4D00-B84D-AF78E17A2898@icloud.com> <7949CB98-F75F-4C04-A9B7-A36642A71B9D@alcatel-lucent.com> <0D328A1E-5481-46C2-B94F-D52CC61C203C@gmail.com> In-Reply-To: <0D328A1E-5481-46C2-B94F-D52CC61C203C@gmail.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=nokia.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [81.242.21.60] x-ms-office365-filtering-correlation-id: 1b0ade3e-15f2-424d-f533-08d46285b6df x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:AM4PR07MB1715; x-microsoft-exchange-diagnostics: 1; AM4PR07MB1715; 7:YvEbVm5ARNCAxGexeeHouXNogsTJ+hiPLI98H0YxukZNqZKcLY5oT6YUzzTpybUbs7YiNFH9sZX71hjqS52f9uGntFr3FkyUiwxtAOVzOYXo4z0P9h00H0yB8l2DcKx9sI3rm8QIbDAgZyv+cQkhi4+9es7MvqB8qW1NTYcMNPOcJzW4yR8vXlEq+HHVMWQkaYh9SSVFumB5wG3qw1DYV9Bwy8wpqdSybuZBdLaeSVb4DzKWB3/5+c7cWWp8Cn8U8Sar3D/M0p1h6uTY98AWsdeUJ6W1Pe2uMpjh+s0y/4pLiGX8KZYOoal98PtpzILLc6O4F4C/UfpzJ3PKUKpAfg== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(84792000423722)(120809045254105)(82608151540597); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123562025)(20161123564025)(20161123560025)(20161123555025)(20161123558025)(6072148); SRVR:AM4PR07MB1715; BCL:0; PCL:0; RULEID:; SRVR:AM4PR07MB1715; x-forefront-prvs: 0235CBE7D0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(39860400002)(39850400002)(39410400002)(39840400002)(24454002)(377424004)(6506006)(83716003)(5660300001)(39060400002)(6486002)(77096006)(33656002)(6436002)(229853002)(66066001)(82746002)(106116001)(122556002)(92566002)(7736002)(3846002)(102836003)(2900100001)(53936002)(305945005)(6116002)(4326008)(86362001)(9686003)(8676002)(6512007)(81166006)(189998001)(38730400002)(50986999)(8936002)(2950100002)(25786008)(76176999)(54356999)(36756003)(6246003)(53546006)(3660700001)(2906002)(3280700002)(99286003)(6306002)(230783001)(93886004)(68736007)(8666007)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR07MB1715; H:AM4PR07MB1715.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <5D185C7B0C734B48B86E7A0C3F950993@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Mar 2017 22:36:20.2823 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB1715 Archived-At: Cc: idr Subject: Re: [Idr] FW: New Version Notification for draft-vandevelde-idr-bgp-ls-segment-routing-rld-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 22:36:27 -0000 TG9va2luZyBhdCBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1pcHBtLWFs dC1tYXJrLTAyIGFuZCB0aGUgbWFya2luZyBmcmFtZXdvcmsgZGlzY3Vzc2VkIGJ5IEdpdXNlcHBl IEZpb2Njb2xhIGl0IHNlZW1zIHRoYXQgY291bnRpbmcgb2YgcGFja2V0cyB3aXRoIGEgZ2l2ZW4g bWFya2VyIGxhYmVsIChzeW5vbnltb3VzIGxhYmVsKSBpcyBhIGtleSBwYXJhbWV0ZXIgZm9yIHRo ZSBwYXNzaXZlIG1lYXN1cmVtZW50cy4gSW4gdGhhdCBjYXNlIG9uZSBpcyBpbnRlcmVzdGVkIGlu IGJvdGggY291bnRpbmcgcGFja2V0cyBpbmdyZXNzIHRvIHRoZSByb3V0ZXIgYW5kIGVncmVzcyBv ZiBhIHJvdXRlcuKApiBJdCBhbGxvd3MgdW5kZXJzdGFuZGluZyBvZiB0aGUgcGFja2V0cyBsb3N0 IGluIHRoZSByb3V0ZXIgZmFicmljIChvciB3aGF0ZXZlciDigJh0aGluZ+KAmSBpcyBkb2luZyB0 aGUgc3dpdGNoaW5nKQ0KDQpHLw0KDQpPbiAwMy8wMy8yMDE3LCAyMzoyNSwgIkplZmYgVGFudHN1 cmEiIDxqZWZmdGFudC5pZXRmQGdtYWlsLmNvbT4gd3JvdGU6DQoNCiAgICBBcmVu4oCZdCBTeW5v bmltb3VzIGxhYmVscyBzaWduaWZpY2FudCBvbiBlZ3Jlc3Mgb25seT8NCiAgICANCiAgICAgDQog ICAgQ2hlZXJzLA0KICAgIEplZmYNCiAgICAgDQogICAgDQogICAgT24gMy8zLzE3LCAxMzo1OCwg IlZhbiBEZSBWZWxkZSwgR3VudGVyIChOb2tpYSAtIEJFKSIgPGd1bnRlci52YW5fZGVfdmVsZGVA bm9raWEuY29tPiB3cm90ZToNCiAgICANCiAgICAgICAgRm9yIGNvbXBsZXRlbmVzcywgSSB3YXMg cmVmZXJyaW5nIHRvIHRoZSBmb2xsb3dpbmcgd29yayBhcyB1c2UgY2FzZSBvZiB0aGUgUkxEIGlu Zm8gaW4gYWRkaXRpb24gdG8gZW50cm9weSB1c2UtY2FzZToNCiAgICAgICAgaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJyeWFudC1tcGxzLXNmbC1mcmFtZXdvcmstMDINCiAgICAg ICAgDQogICAgICAgIEcvDQogICAgICAgIA0KICAgICAgICBPbiAwMy8wMy8yMDE3LCAyMjoyNiwg Ikd1bnRlciBWYW4gRGUgVmVsZGUiIDxndW50ZXJ2YW5kZXZlbGRlY2NAaWNsb3VkLmNvbT4gd3Jv dGU6DQogICAgICAgIA0KICAgICAgICAgICAgVGhlcmUgaXMgb3RoZXIgdXNlIGNhc2UgYWxzbyB0 byBkbyB3aXRoIFN5bm9uaW1vdXMgbGFiZWxzIGFuZCBtZWFzdXJlbWVudHMgKEFsdGVybmF0ZSBt YXJraW5nIGZvciBwYXNzaXZlIG1lYXN1cmVtZW50cykgcG90ZW50aWFsbHnigKYuDQogICAgICAg ICAgICBNYXliZSBpIHNob3VsZCBhZGQgdGhhdCBvbmUgYWxzbyB0byB0aGUgdXNlIGNhc2VzLg0K ICAgICAgICAgICAgDQogICAgICAgICAgICBHLw0KICAgICAgICAgICAgDQogICAgICAgICAgICA+ IE9uIDMgTWFyIDIwMTcsIGF0IDIxOjQ4LCBKZWZmIFRhbnRzdXJhIDxqZWZmdGFudC5pZXRmQGdt YWlsLmNvbT4gd3JvdGU6DQogICAgICAgICAgICA+IA0KICAgICAgICAgICAgPiBIaSBHdW50ZXIs DQogICAgICAgICAgICA+IA0KICAgICAgICAgICAgPiBJZiBpdCBpcyB1cCB0byBhIGNvbnRyb2xs ZXIgdG8gc2V0dXAgRUwsIHRoaXMgZXh0ZW5zaW9uIG5lZWRlZCwgc2FtZSB3YXkgYXMgZGVzY3Jp YmVkIGluIHRoZSBJR1AgZHJhZnRzLg0KICAgICAgICAgICAgPiANCiAgICAgICAgICAgID4gSeKA mWQgcXVlc3Rpb25zIHVzZWZ1bG5lc3Mgb2YgUkxEIG91dHNsZGllIG9mIEVudHJvcHkgTGFiZWxz IHVzZSBjYXNlLg0KICAgICAgICAgICAgPiBUcmFuc2l0IG5vZGVzIGluICBnZW5lcmFsIGFyZSBu b3QgaW50ZXJlc3RlZCBpbiB0aGUgZnVsbCBsYWJlbCBzdGFjayBjb250ZW50IG91dHNpZGUgb2Yg ZW50cm9weSB1c2UgY2FzZS4NCiAgICAgICAgICAgID4gDQogICAgICAgICAgICA+IEV2ZW4gaWYg dGhlIG5vZGUgaW4gcXVlc3Rpb24gIGNhbuKAmXQgcmVhZCB3aG9sZSBzdGFjaywgaXQgY2FuIHN0 aWxsIHByb3Blcmx5IGZvcndhcmQgdGhlIHBhY2tldCwgcGVyaGFwcyB3aXRoIGxlc3Mgb3B0aW1h bCBoYXNpbmcuDQogICAgICAgICAgICA+IFVzaW5nIFJMRCBhcyBhIGNvbnRzcmFpbiBpbiBwYXRo IGNvbXB1dGF0aW9uIGRvZXNu4oCZdCBzZWVtIHRvIGJlIGEgcmlnaHQgdGhpbmcgdG8gZG8uDQog ICAgICAgICAgICA+IA0KICAgICAgICAgICAgPiBUaGFua3MhDQogICAgICAgICAgICA+IA0KICAg ICAgICAgICAgPiBDaGVlcnMsDQogICAgICAgICAgICA+IEplZmYNCiAgICAgICAgICAgID4gDQog ICAgICAgICAgICA+IA0KICAgICAgICAgICAgPiBPbiAzLzMvMTcsIDA2OjU1LCAiSWRyIG9uIGJl aGFsZiBvZiBWYW4gRGUgVmVsZGUsIEd1bnRlciAoTm9raWEgLSBCRSkiIDxpZHItYm91bmNlc0Bp ZXRmLm9yZyBvbiBiZWhhbGYgb2YgZ3VudGVyLnZhbl9kZV92ZWxkZUBub2tpYS5jb20+IHdyb3Rl Og0KICAgICAgICAgICAgPiANCiAgICAgICAgICAgID4gICAgSGVhZHMtdXDigKYgSGFwcHkgdG8g bGVhcm4gZmVlZGJhY2sgYW5kIGNvbW1lbnRzLg0KICAgICAgICAgICAgPiANCiAgICAgICAgICAg ID4gICAgVGhpcyBkcmFmdCBpcyBzaG9ydCBhbmQgZGVmaW5lcyB0aGUgYXR0cmlidXRlIHRvIHVz ZSBmb3IgQkdQLUxTIHRvIGV4cG9zZSBhIA0KICAgICAgICAgICAgPiAgICBub2RlIFJMRCAiUmVh ZGFibGUgTGFiZWwgRGVwdGgiIHRvIGEgY2VudHJhbGlzZWQgY29udHJvbGxlciAoUENFL1NETiku DQogICAgICAgICAgICA+IA0KICAgICAgICAgICAgPiAgICBHLw0KICAgICAgICAgICAgPiANCiAg ICAgICAgICAgID4gICAgT24gMDMvMDMvMjAxNywgMTQ6MjEsICJpbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmciIDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IHdyb3RlOg0KICAgICAgICAgICAgPiAN CiAgICAgICAgICAgID4gDQogICAgICAgICAgICA+ICAgICAgICBBIG5ldyB2ZXJzaW9uIG9mIEkt RCwgZHJhZnQtdmFuZGV2ZWxkZS1pZHItYmdwLWxzLXNlZ21lbnQtcm91dGluZy1ybGQtMDEudHh0 DQogICAgICAgICAgICA+ICAgICAgICBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5 IEd1bnRlciBWYW4gZGUgVmVsZGUgYW5kIHBvc3RlZCB0byB0aGUNCiAgICAgICAgICAgID4gICAg ICAgIElFVEYgcmVwb3NpdG9yeS4NCiAgICAgICAgICAgID4gDQogICAgICAgICAgICA+ICAgICAg ICBOYW1lOgkJZHJhZnQtdmFuZGV2ZWxkZS1pZHItYmdwLWxzLXNlZ21lbnQtcm91dGluZy1ybGQN CiAgICAgICAgICAgID4gICAgICAgIFJldmlzaW9uOgkwMQ0KICAgICAgICAgICAgPiAgICAgICAg VGl0bGU6CQlTaWduYWxsaW5nIFJMRCB1c2luZyBCR1AtTFMNCiAgICAgICAgICAgID4gICAgICAg IERvY3VtZW50IGRhdGU6CTIwMTctMDMtMDMNCiAgICAgICAgICAgID4gICAgICAgIEdyb3VwOgkJ SW5kaXZpZHVhbCBTdWJtaXNzaW9uDQogICAgICAgICAgICA+ICAgICAgICBQYWdlczoJCTUNCiAg ICAgICAgICAgID4gICAgICAgIFVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9p bnRlcm5ldC1kcmFmdHMvZHJhZnQtdmFuZGV2ZWxkZS1pZHItYmdwLWxzLXNlZ21lbnQtcm91dGlu Zy1ybGQtMDEudHh0DQogICAgICAgICAgICA+ICAgICAgICBTdGF0dXM6ICAgICAgICAgaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdmFuZGV2ZWxkZS1pZHItYmdwLWxzLXNl Z21lbnQtcm91dGluZy1ybGQvDQogICAgICAgICAgICA+ICAgICAgICBIdG1saXplZDogICAgICAg aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXZhbmRldmVsZGUtaWRyLWJncC1scy1z ZWdtZW50LXJvdXRpbmctcmxkLTAxDQogICAgICAgICAgICA+ICAgICAgICBEaWZmOiAgICAgICAg ICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXZhbmRldmVsZGUtaWRy LWJncC1scy1zZWdtZW50LXJvdXRpbmctcmxkLTAxDQogICAgICAgICAgICA+IA0KICAgICAgICAg ICAgPiAgICAgICAgQWJzdHJhY3Q6DQogICAgICAgICAgICA+ICAgICAgICAgICBUaGlzIGRvY3Vt ZW50IGRlZmluZXMgdGhlIGF0dHJpYnV0ZSB0byB1c2UgZm9yIEJHUC1MUyB0byBleHBvc2UgYQ0K ICAgICAgICAgICAgPiAgICAgICAgICAgbm9kZSBSTEQgIlJlYWRhYmxlIExhYmVsIERlcHRoIiB0 byBhIGNlbnRyYWxpc2VkIGNvbnRyb2xsZXIgKFBDRS8NCiAgICAgICAgICAgID4gICAgICAgICAg IFNETikuDQogICAgICAgICAgICA+IA0KICAgICAgICAgICAgPiANCiAgICAgICAgICAgID4gDQog ICAgICAgICAgICA+IA0KICAgICAgICAgICAgPiANCiAgICAgICAgICAgID4gICAgICAgIFBsZWFz ZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1l IG9mIHN1Ym1pc3Npb24NCiAgICAgICAgICAgID4gICAgICAgIHVudGlsIHRoZSBodG1saXplZCB2 ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQogICAgICAg ICAgICA+IA0KICAgICAgICAgICAgPiAgICAgICAgVGhlIElFVEYgU2VjcmV0YXJpYXQNCiAgICAg ICAgICAgID4gDQogICAgICAgICAgICA+IA0KICAgICAgICAgICAgPiANCiAgICAgICAgICAgID4g ICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICAg ICAgICAgID4gICAgSWRyIG1haWxpbmcgbGlzdA0KICAgICAgICAgICAgPiAgICBJZHJAaWV0Zi5v cmcNCiAgICAgICAgICAgID4gICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9pZHINCiAgICAgICAgICAgID4gDQogICAgICAgICAgICA+IA0KICAgICAgICAgICAgPiANCiAg ICAgICAgICAgID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCiAgICAgICAgICAgID4gSWRyIG1haWxpbmcgbGlzdA0KICAgICAgICAgICAgPiBJZHJAaWV0 Zi5vcmcNCiAgICAgICAgICAgID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9pZHINCiAgICAgICAgICAgIA0KICAgICAgICAgICAgDQogICAgICAgIA0KICAgICAgICANCiAg ICANCiAgICANCiAgICANCg0K From nobody Fri Mar 3 15:55:24 2017 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E057F128874; Fri, 3 Mar 2017 15:55:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148858531891.15846.16277084586571197883.idtracker@ietfa.amsl.com> Date: Fri, 03 Mar 2017 15:55:18 -0800 Archived-At: Cc: idr@ietf.org Subject: [Idr] idr - Requested session has been scheduled for IETF 98 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 23:55:19 -0000 Dear Susan Hares, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. idr Session 1 (2:30:00) Friday, Morning Session I 0900-1130 Room Name: Zurich G size: 115 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Inter-Domain Routing Area Name: Routing Area Session Requester: Susan Hares Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: rtgwg netconf netmod spring trill i2nsf i2rs grow Second Priority: bess sidrops Third Priority: detnet dots nfvrg mpls People who must be present: Susan Hares John Scudder Alvaro Retana Resources Requested: Special Requests: --------------------------------------------------------- From nobody Fri Mar 3 16:38:39 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C788E1293E4; Fri, 3 Mar 2017 16:38:31 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=csPdz4Bc; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=rXp6Ltg/ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K_41bx9moLZL; Fri, 3 Mar 2017 16:38:27 -0800 (PST) Received: from esa6.dell-outbound.iphmx.com (esa6.dell-outbound.iphmx.com [68.232.149.229]) (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 53B5D12706D; Fri, 3 Mar 2017 16:38:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1488587907; x=1520123907; h=from:cc:to:subject:date:message-id:references: in-reply-to:mime-version; bh=q7PW85yL+GbZtd7O6fYi9MTQIV+2QzGTVM/stRaOk/Y=; b=csPdz4Bcq5aPmmM8rPkzinnAjXUS7tGTXDYy0iGbwz2oEt6fkMeBWyz2 VMC68JXTs4m1dvieZk/BRRbMqjZwFMolgSo9zxuPpB3lx12nH2JFc3Ref LGJrzuUlCsieZjbMFAH78m+yAkPAy7ANE9QBvIWm87TgKOhgn/0K5Epy/ I=; Received: from esa3.dell-outbound2.iphmx.com ([68.232.154.63]) by esa6.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Mar 2017 18:38:26 -0600 From: "Black, David" Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa3.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Mar 2017 06:37:21 +0600 Received: from maildlpprd51.lss.emc.com (maildlpprd51.lss.emc.com [10.106.48.155]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v240cN3O019994 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 3 Mar 2017 19:38:24 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com v240cN3O019994 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1488587904; bh=N+E+HZVZ5jwA77wVi+Ooc8rq/eM=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=rXp6Ltg/sA1Fo+tPP5Eek4Id+vf5ZHl3dHqWKNF5KVq70uwXPtr4JZQnyhGewH/OT UYiIOiKlPEpLEyi1zub1rtkfkGLR3PNrqzAL9yvhhdW/Mor1JZp/zHuhdV73te0xAH Vxnlz9Ww40ylmv+30KciJQaX0j49uYu01LCmuXIE= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com v240cN3O019994 Received: from mailusrhubprd04.lss.emc.com (mailusrhubprd04.lss.emc.com [10.253.24.22]) by maildlpprd51.lss.emc.com (RSA Interceptor); Fri, 3 Mar 2017 19:37:00 -0500 Received: from MXHUB310.corp.emc.com (MXHUB310.corp.emc.com [10.146.3.36]) by mailusrhubprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v240c5hd012718 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Fri, 3 Mar 2017 19:38:06 -0500 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB310.corp.emc.com ([10.146.3.36]) with mapi id 14.03.0266.001; Fri, 3 Mar 2017 19:38:05 -0500 To: Shitanshu Shah , "tsv-art@ietf.org" Thread-Topic: Review of draft-ietf-idr-sla-exchange-10 Thread-Index: AQHSjn2hotpFQg8pf0qPmuGxW7GZeaF4QrTwgACFLACABFiS0IAB9hiAgATKWFA= Date: Sat, 4 Mar 2017 00:38:05 +0000 Message-ID: References: <148771630812.19122.17152051080250251501.idtracker@ietfa.amsl.com> , , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.45.62] Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D243277949362F8DD70AMX307CL04corpem_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd04.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: "idr@ietf.org" , "Black, David" , "draft-ietf-idr-sla-exchange.all@ietf.org" , "ietf@ietf.org" Subject: Re: [Idr] Review of draft-ietf-idr-sla-exchange-10 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Mar 2017 00:38:32 -0000 --_000_CE03DB3D7B45C245BCA0D243277949362F8DD70AMX307CL04corpem_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Embedded in my question about VPNs is an implicit suggestion (which I'll no= w make explicit ...) -- this L2 overhead parameter would be more robust if = it were defined as the number of octets difference between the full frame t= hat is sent on the wire and the size of the IP packet to which the token b= uckets apply. Even if there are no known current needs to account for anyt= hing other than L2 framing, this approach is robust to future network engin= eering encapsulation "creativity" ;-). Thanks, --David From: Tsv-art [mailto:tsv-art-bounces@ietf.org] On Behalf Of Shitanshu Shah Sent: Tuesday, February 28, 2017 1:24 PM To: Black, David; tsv-art@ietf.org Cc: idr@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; ietf@ietf.org Subject: Re: [Tsv-art] Review of draft-ietf-idr-sla-exchange-10 Hi David, We will add more text to clarify rationale for L2_OVERHEAD. Do you have a preference or suggest a way to specify L2 rates? We will work= on defining 2 TSpecs to specify two rates (min and max). As far as VPN terminating between Consumer and Producer, I am not aware of = use-cases, at least in the context of the deployment scenario considered fo= r the draft. Regards, Shitanshu ________________________________ From: Black, David > Sent: Monday, February 27, 2017 10:42 AM To: Shitanshu Shah; tsv-art@ietf.org Cc: idr@ietf.org; draft-ietf-idr-sla-exchange.all@ietf= .org; ietf@ietf.org; Black, David Subject: RE: Review of draft-ietf-idr-sla-exchange-10 Ok, please make that rationale for the L2_OVERHEAD parameter clear in the d= raft: > Though for the cases where physical links are not to be over-run, and/or,= sla defined are based on l2 rates, the Consumer would > need to know l2 overhead from the Producer. Otherwise 10 byes of l2 overh= ead difference on 64 bytes packets can be significant > compare to on 1400 bytes packets, and thus the Producer does not have a w= ay to convert rates to ip based (this can cause > functional issue), since this has to be per packet consideration. It looks like the result is that if the Producer's L2 overhead is larger th= an the Consumer's, and the token buckets are specified in IP octets, the co= nsumer has to calculate a per-packet charge of the L2 overhead difference a= gainst the IP token bucket (and in the opposite case, there may be a per-pa= cket credit). Are there cases where the overhead is not all L2, e.g., SLA= /TCA Consumer is using a VPN that terminates between Consumer and Producer? Thanks, --David From: Shitanshu Shah [mailto:shitanshu_shah@hotmail.com] Sent: Friday, February 24, 2017 1:05 PM To: Black, David; tsv-art@ietf.org Cc: idr@ietf.org; draft-ietf-idr-sla-exchange.all@ietf= .org; ietf@ietf.org Subject: Re: Review of draft-ietf-idr-sla-exchange-10 Hi David, One response inline ##svshah2 ________________________________ From: Black, David > Sent: Friday, February 24, 2017 8:53 AM To: Shitanshu Shah; tsv-art@ietf.org Cc: idr@ietf.org; draft-ietf-idr-sla-exchange.all@ietf= .org; ietf@ietf.org; Black, David Subject: RE: Review of draft-ietf-idr-sla-exchange-10 David> Inline ... Thanks, --David From: Shitanshu Shah [mailto:shitanshu_shah@hotmail.com] Sent: Friday, February 24, 2017 4:09 AM To: Black, David; tsv-art@ietf.org Cc: idr@ietf.org; draft-ietf-idr-sla-exchange.all@ietf= .org; ietf@ietf.org Subject: Re: Review of draft-ietf-idr-sla-exchange-10 Hi David, Thank you for taking time for the review.. Please find our response inline ##svshah and [Med] Regards, Shitanshu ________________________________ From: David Black > Sent: Tuesday, February 21, 2017 3:31 PM To: tsv-art@ietf.org Cc: idr@ietf.org; draft-ietf-idr-sla-exchange.all@ietf= .org; ietf@ietf.org Subject: Review of draft-ietf-idr-sla-exchange-10 Reviewer: David Black Review result: Not Ready I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. When done at the time of IETF Last Call, the authors should consider this review together with any other last-call comments they receive. Please always CC tsv-art@ietf.org if you reply to or forward this r= eview. Document: draft-ietf-idr-sla-10 Reviewer: David Black Review Date: February 21, 2017 Review result: Not Ready This is an early TSV-ART review of a working group draft, requested by the IDR Working Group. This draft defines an extension to BGP to allow exchange of traffic handling parameters (e.g., configured rates, burst sizes, drop thresholds). While this is a useful area of technology to standardize across network operators, this draft has significant problems, and parts of it could use some serious rethought. This reviewer has discussed small portions of this draft with some of the authors in the past, but this is his first comprehensive reading and review of the draft. Major Issues: [1] The draft is misnamed. This is not an SLA (Service Level Agreement) draft - it's a TCA (Traffic Conditioning Agreement) draft - see the definition of TCA in RFC 2475. This draft should start from that definition and generalize the applicability of TCA beyond Diffserv. Large areas of SLA content are not covered by this draft - for more details, see the Wikipedia article on SLA: https://en.wikipedia.org/wiki/Service-level_agreement . ##svshah, sure, we can change the term to TCA (Traffic Conditioning Agreeme= nt), which fairly represents intention in the draft, if there is no otherwi= se comment from the working group. David> That would be good, thanks. [2] Section 3.3.2.1's reuse of the TSpec construct from RFC 2115 to specify a token bucket is a good idea, but it's not a good idea to respecify that construct in terms of L2 (link-layer, e.g., Ethernet) octets, as the RFC 2115 TSpec is specified in terms of IP octets. This change to specification in terms of L2 octets results in needing the L2_OVERHEAD TLV to cope with the possible differences in L2 (link) framing overhead at sender and receiver of this information. The TSpec should be respecified at the IP layer, with L2 framing overhead left to the Producer and Consumer to factor into their calculations based on each's direct knowledge of L2 functionality and configuration in the local AS. That ought to enable elimination of the L2_OVERHEAD TLV, thereby reducing complexity. ##svshah, the purpose for advertising L2 overhead, from the Producer to the= Consumer, is to make sure traffic is well conditioned, at the egress of th= e Consumer, to avoid possible indiscriminate drops at the ingress of the Pr= oducer. In another words, the Producer is telling the Consumer to ignore it= s own link level overhead, instead use Producer's provided link level overh= ead while running frames through QoS functions (this is relevant in use-cas= es where l2 overhead of the egress link on Consumer and of ingress link on = the Producer are of different size, e.g., in the vpn/tunnel connection betw= een two peer nodes which physically may be multiple hops away). I understand your comments regarding re-using TSpec without any modificatio= n. Do you agree with the use-case of l2 differences? If yes, any suggestion= how to accommodate that? David> Specifying this in terms of IP octets implies that L2 overhead is to= be ignored on both links. That's simpler, and a few sentences of discussi= on about possible L2 framing differences should cover what needs to be done= (e.g., if traffic rates are configured in terms of L2 octets, then explain= how each entity converts between IP traffic and L2 traffic - the draft alr= eady effectively contains that explanation). ##svshah2, just to make sure that some of the real use are not left out.. For the traffic conditioning where sla established is for the ip based rate= s only, it suffices for the Producer to send rates only IP based ignoring a= ny specific of l2 overheads. Though for the cases where physical links are not to be over-run, and/or, s= la defined are based on l2 rates, the Consumer would need to know l2 overhe= ad from the Producer. Otherwise 10 byes of l2 overhead difference on 64 byt= es packets can be significant compare to on 1400 bytes packets, and thus th= e Producer does not have a way to convert rates to ip based (this can cause= functional issue), since this has to be per packet consideration. Regards, Shitanshu [3] A token bucket should have two rate-related marking parameters based on its token fill rate, i.e., min-rate, not the four rate-related marking parameters in this draft. The max-rate parameters in sections 3.3.2.5-6 ought to be specified against a second token bucket. In addition, the handling precedence algorithm in section 3.3.2.7 is an overly complex way to specify the relationship of two token buckets. All of this is even more important, because max-rate, as defined in RFC 2115, is only applicable to bursting - that max-rate for bursting often turns out to be an interface line rate, which is not generally useful for the traffic provisioning purposes of this draft. ##svshah, what you describe below conceptually very much makes sense and th= at is what we attempt to achieve. What is unclear though how to capture tha= t using TSpec definition specified in RFC2215. Since that TSpec definition = has both minimum-rate and maximum-rate, but no in/out profile marking param= eters. Is your proposal below to define two TSpecs using the same definition from = RFC2215? Wouldn't in that case we have min/max specified twice? min/max in = each TSpec? and thus confusing to represent one min and one max through two= TSpecs? David> See RFC 2698 for the desired behavior and the parameters needed to s= pecify it. The current idr-sla draft is not able to represent the traffic = conditioning mechanisms specified in both RFC 2698 and RFC 2697, as each me= chanism requires two token buckets (e.g., there are two burst sizes, but th= e idr-sla draft TSpec only contains one). This deficiency needs to be deal= t with. One possibility for simplification is to drop the max-rate from th= e RFC 2115 TSpec and assume that the max-rate for bursting is the effective= line rate. The following should be done instead: - Define TSpecs for two token buckets, a primary/committed token bu= cket and a secondary/peak token bucket that MUST be nested, i.e.= , traffic that is in-profile for the secondary/peak token bucket is a= lways in-profile for the primary/committed token bucket. Some of= the details of how to specify this are subtle, see RFC 2698 for a worke= d example. Use of a secondary/peak token bucket requires use of the pr= imary/ committed token bucket, but a primary/committed token bucke= t can be used without a secondary/peak token bucket. - For a single token bucket, define two handling TLVs, Committed (i= n profile) and Excess (out of profile). - For two token buckets, define three handling TLVs, Committed (in = profile for both token buckets), Peak (out of profile for primary/committed = token bucket, but in profile for secondary/peak token bucket) and Excess (out of= profile for both token buckets). NB: Could use Green/Yellow/Red terms instead of Committed/Peak/Excess terms. [4] The drop threshold TLV in section 3.3.2.8 is not specified sufficiently to be implemented interoperably. For example, I don't understand what an implementation is supposed to do when it receives 3 drop thresholds. ##svshah, It is around the semantics of a single queue with a different thr= eshold for a set of code-points, where packet for a specific code-point is = to be tail dropped if overall queue-depth hits code-point specific threshol= d at the arrival of that packet. We will add appropriate clarification for this semantics. David> Will look at revision [5] The relative priority TLV in section 3.3.2.9 has the same insufficient specification problem as the drop threshold TLV, compounded by a functional incompleteness problem - if the recipient is using a weighted packet transmission scheduler (e.g., WRR), priorities cannot be used to configure that scheduler. Hence, some specification of weights and scheduling algorithms that use weights needs to be added. ##svshah, Sure. Is following clarification okay? (some of the wordings take= n from RFC2598) " A higher priority class of traffic to be served without pre-empted by lower= priority class of traffic for more than a packet time at the configured ra= te. In the system that implements WRR, the use of relative priority may get res= tricted where a single queue may be used for a higher priority traffic clas= s where that queue is configured for the full share of the output bandwidt= h. " David> Last sentence basically says that WRR weights are out-of-scope. Tha= t seems wrong. Will look at revision. [6] I have no idea what the sub-traffic classes TLV in section 3.3.2.10 is supposed to do, as that TLV is specified based on "Traffic Class TLVs" which is an undefined term in this draft (e.g., that term is not used outside of section 3.3.2.10. ##svshah, They are to facilitate hierarchy. A specific Traffic Class, can f= urther be divided in a multiple subset of Traffic Classes, with their own = Traffic Class Elements and Traffic Class Services. Will correct the wording to remove your this specific concern. David> Will look at revision [7] This draft's QoS contents need to be functionally aligned with work-in-progress on YANG QoS models, in order to provide some assurance that that this draft is implementable for actual network switch/router data paths. The current acknowledgement of the existence of YANG, NETCONF and RESTConf at the end of Section 1 does not suffice. ##svshah, While eventually "Traffic Conditioning Agreement" should be trans= lated to the actual forwarding qos policy on any vendor specific device, TC= A exchange largely carries concepts/semantics that is either standard based= or well understood. While we are not aware of any working group document of QoS Yang Model, we = think that concepts of Traffic Conditioning should be easily adaptable to = any QoS Yang Models since they also have to be defined to support those con= cepts. David> Still want to see cross-check with implementations here. [8] There are significant complexity and correctness problems caused by the option to not specify the Source AS - e.g., Section 3.2 defines an SLA ID as an "identifier which is unique in the scope of Source AS" which is meaningless if there is no Source AS. It would be simpler to always specify Source AS, even in the point-to-point case. ##svshah, okay. Ron Bonica also suggested same in his review earlier. We ha= d chosen a path of optional Source AS to simplify implementations in cases.= Given specification of Source AS always is more clearer in multiple feed-b= ack we have gotten so far, we can modify the specification to incorporate t= hat over the simplicity of implementation for certain cases. David> OK, thanks. [9] In section 3.2, the "intended for the peer receiver of the BGP UPDATE message" text in the specification of bit 0 of the SLA Subtype flags is unclear. I suspect that this is intended to differentiate the two usages described in sections 4.1.1 (Point-to-Point) and 4.1.2 (Multiple Hops), in which case the parenthesized terms (or similar terminology) should be used with cross-references to those two sections. ##svshah, sure will make necessary changes, also in the context of earlier = comment. [10] There needs to be a coherent discussion in one place about how SLA advertisement, update and withdrawal work. A single ADVERTISE method may suffice on the wire, but the details on how initial advertisement, subsequent advertisement (update) and withdrawal work need to be specified in one place. The third paragraph of Section 4 is a start on this material, but it's too terse; [Med] That text is terse because we are reusing the BGP machinery for adver= tising/withdrawing; we only augment it with triggers that are linked to the= SLA information. A new SLA will lead to an update message with ADVERTISE, = an update of an existing SLA will trigger an update message. We do think th= is information is already present in the document. David>This is hard to understand it, as there is no statement that the BGP = machinery is being used, and the material on SLA usage is spread in differe= nt places. I suggest starting section 3 with a discussion of advertisement= /update/withdrawal, and how all three are realized via a single ADVERTISE m= ethod via BGP UPDATE - this was difficult to figure out in reading the curr= ent draft. it should be expanded into its own subsection, and moved earlier to come before the ADVERTISE method in Section 3.2. This text from Section 3.2 should be moved into that new subsection and likewise expanded: [Med] Another option is to move it Section 4. From our standpoint, we do th= ink it is straightforward to describe the behavior once the attributes form= at are defined. David> Ok, that's an editorial choice - I prefer to explain how something w= orks before defining its on-the-wire data format. If an advertised SLA ID is different from earlier advertised one, for the same prefix and from the same Source AS, indicates Source AS is advertising new SLA Content to replace the previous one advertised with the same SLA ID. In addition, I wonder whether functionality should be added to allow withdrawal of an advertisement by specifying its SLA ID, although that was not part of the original design. [Med] The reason we didn't adopted that design is that we don't want to mak= e assumptions on which data the remote peer will be used for enforcing loca= l actions and also because of this text: The SLA ID applies to aggregate traffic to prefixes for a given AFI/SAFI that share the same Source AS and SLA ID. David> That's fine, I wanted to ensure that this had been considered. The = discussion of BGP mechanism reuse will probably help here. [11] Notions of context for interpretation of all the IPFIX parameters in 3.3.1 need to be added, e.g.: - The first three parameters (DSCP, MPLS EXP field in top label, 80= 2.1q priority) can and do vary on a link-by-link or LSP-by-LSP basis along a t= raffic's network path. - The IP address parameters are rather likely to be VPN-specific wh= en there's more than one BGP/MPLS VPN that spans or transits the ASs involv= ed. - The transport port parameters need specification of which transpo= rt header and where it is located (e.g., for TCP traffic carried by in VXLAN, is t= his the inner TCP header or the outer UDP header in VXLAN). There are probably simple approaches to specifying context in all cases, but that context does need to be specified ... in all cases. [Med] We dind't include a context field because we thought that the definit= ion of the IPFIX attributes is sufficient by itself, but if you do think it= is helpful to have such information, we can update the table. David> Really??? Please reread the first comment above: - The first three parameters (DSCP, MPLS EXP field in top label, 80= 2.1q priority) can and do vary on a link-by-link or LSP-by-LSP basis along a t= raffic's network path. David> Taking just DSCP, it can change on a per-link basis, so something h= as to specify which link (between the SLA Producer and SLA Consumer?) is in= volved. It probably suffices to say that it's the link that crosses the re= levant AS boundary, but that does have to be stated, as it's nowhere to be = found in the far more general IPFIX registry. [12] The security considerations (section 10) are severely incomplete and insufficient: David> I stand by this statement and recommend a complete rewrite of the se= curity considerations. - Discussion of possible abuse of this BGP option for denial-of-ser= vice and theft-of-service, needs to be added, including possible countermeasures and m= itigations. [Med] This attack vector is not specific to this attribute; this is valid f= or BGP in general. David> There are additional attacks enabled by this attribute. - This sentence at the end of the second paragraph in Section 10 is= content-free: It is NOT RECOMMENDED to enable this attribute at the scale of the Internet unless if means to prevent leaking= sensitive information are enforced. What exactly is an implementer or admin supposed to do? [Med] An example of what an admin needs to check if this information can be= sent to a given peer or not. Some of the content of the attribute contains= some sensitive information such as contract Id, classes, etc. How does one figure out whether an implementation or deployment is "at = the scale of the Internet" ?? [Med] The idea here is to avoid leaking such data in to the global routing = table. Only entitled peers need receive such information with controlled sc= ope. David> I understand the idea - the problem is that I don't see specificatio= n of what has to be implemented in either the text in the draft or the abov= e explanations. - The next to last paragraph in section 10 is almost content-free, = as it leaves decisions on implementation and deployment of key security = functionality as "an exercise for the reader" - that's not acceptable. [Med] I guess you are referring to the following text. Validation checks ar= e really deployment-specific. The text calls out the issue and recommends a= n action; how to translate this action into detailed actions is realty loca= l to a domain The attribute may be advertised by a misbehaving node to communicate SLA parameters that are not aligned with the SLA agreements. Though the enforcement of SLA parameters is outside the scope of this document, it is RECOMMENDED that the SLA Consumer to enforce a set of validation checks before translating the SLA parameters conveyed in the QoS attributes into provisioning actions. Such validations MAY rely on SLA parameters like the origin AS or SLA ID, like generating SLA ID using pseudo-random schemes [RFC4086]. David> I stand by the "exercise to the reader" criticism - one way to be h= onest about this would be to change the paragraph to: The attribute may be advertised by a misbehaving node to communicat= e SLA parameters that are not aligned with the SLA agreements. The enforcement of SLA parameters is outside the scope of this document. David> That does not change any normative content of the original paragraph= . My view is that the "outside the scope of this document" statement is wr= ong because all of these parameters are being defined in this draft. - Last, but not least, the final paragraph in Section 10 is a joke = that will be lost on a security directorate reviewer - to understand = why, see Section 2 of RFC 6919, and take note of the publication dat= e of RFC 6919. David> For anyone who didn't catch the reference, RFC 6919 is an April 1 RF= C ... and the "SHOULD BE considered" language used in the last security con= siderations paragraph of this draft is accurately characterized as vague in= Section 2 of RFC 6919: The phrase "SHOULD CONSIDER" indicates that the authors of the specification think that implementations should do something, but they're not sure quite what. ------------------------ Having noted a dozen major issues, I'll end the review here for now, as I believe a serious revision of the draft is called for, which would be a better starting point to review for minor issues and editorial items. -------------------------------------------------------- David L. Black, Distinguished Engineer Dell EMC, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 Cell: +1 (978) 394-7754 David.Black@dell.com <=3D=3D=3D NEW =3D=3D=3D -------------------------------------------------------- --_000_CE03DB3D7B45C245BCA0D243277949362F8DD70AMX307CL04corpem_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Embedded in my question a= bout VPNs is an implicit suggestion (which I’ll now make explicit ...= ) -- this L2 overhead parameter would be more robust if it were defined as the number of octets difference between the full frame that is = sent on the wire and the size of the IP packet to which  the token buc= kets apply.  Even if there are no known current needs to account for a= nything other than L2 framing, this approach is robust to future network engineering encapsulation “creativity= 221; ;-).

 <= /p>

Thanks, --David

 <= /p>

From: Tsv-art = [mailto:tsv-art-bounces@ietf.org] On Behalf Of Shitanshu Shah
Sent: Tuesday, February 28, 2017 1:24 PM
To: Black, David; tsv-art@ietf.org
Cc: idr@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; ietf@iet= f.org
Subject: Re: [Tsv-art] Review of draft-ietf-idr-sla-exchange-10=

 

 

Hi David,

 

We will add more text to clarify rationale for L2_OVERHEAD.=

 

Do you have a preference or suggest a way to specify L2 rates? W= e will work on defining 2 TSpecs to specify two rates (min and max). <= o:p>


As far as VPN terminating between Consumer and Producer, I am not aware of = use-cases, at least in the context of the deployment scenario considered fo= r the draft.

 

Regards,

Shitanshu

From: Black, David <= David.Black@dell.com>
Sent: Monday, February 27, 2017 10:42 AM
To: Shitanshu Shah; tsv-art@ietf= .org
Cc: idr@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; ietf@ietf.org; Black, David
Subject: RE: Review of draft-ietf-idr-sla-exchange-10

 

Ok, please make that rationale for the = L2_OVERHEAD parameter clear in the draft:

> Though for the cases where phys= ical links are not to be over-run, and/or, sla defined are b= ased on l2 rates, the Consumer would
> need to know l2 overhead from the Producer. Otherwise 10 byes of l2 ov= erhead difference on 64 bytes packets can be significant
> compare to on 1400 bytes packets, and thus the Producer does not have = a way to convert rates to ip based (this can cause
> functional issue), since this has to be per packet consideration.

It looks like the result is that if the= Producer’s L2 overhead is larger than the Consumer’s, and the token buckets are specified in IP octets, the consumer has to calculat= e a per-packet charge of the L2 overhead difference against the IP token bu= cket (and in the opposite case, there may be a per-packet credit). &nb= sp; Are there cases where the overhead is not all L2, e.g., SLA/TCA Consumer is using a VPN that terminates between = Consumer and Producer?=

 

Thanks, --David

 

From: Shitanshu Shah [mailto:shitanshu_shah@= hotmail.com]
Sent: Friday, February 24, 2017 1:05 PM
To: Black, David; tsv-art@ietf.o= rg
Cc: idr@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; ietf@ietf.org
Subject: Re: Review of draft-ietf-idr-sla-exchange-10

 

 

Hi David,

 

One response inline ##svshah2

 

From: Black, David <David.Black@dell.com= >
Sent: Friday, February 24, 2017 8:53 AM
To: Shitanshu Shah; tsv-art@ietf= .org
Cc: idr@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; ietf@ietf.org; Black, David
Subject: RE: Review of draft-ietf-idr-sla-exchange-10

 

David> Inline ...

 

Thanks, --David

 

From: Shitanshu Shah [mailto:shitanshu_shah@= hotmail.com]
Sent: Friday, February 24, 2017 4:09 AM
To: Black, David; tsv-art@ietf.o= rg
Cc: idr@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; ietf@ietf.org
Subject: Re: Review of draft-ietf-idr-sla-exchange-10

 

 

Hi David,

 

Thank you for taking time for the review..

 

Please find our response inline ##svshah and [Med]

 

Regards,

Shitanshu

From: David Black <david.black@emc.com&g= t;
Sent: Tuesday, February 21, 2017 3:31 PM
To: tsv-art@ietf.org
Cc: idr@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; ietf@ietf.org
Subject: Review of draft-ietf-idr-sla-exchange-10

 

Reviewer: David Black
Review result: Not Ready

I've reviewed this document as part of the transport area
directorate's ongoing effort to review key IETF documents. These
comments were written primarily for the transport area directors, but
are copied to the document's authors for their information and to
allow them to address any issues raised. When done at the time of IETF
Last Call, the authors should consider this review together with any
other last-call comments they receive. Please always CC
tsv-art@ietf.org if you reply to or= forward this review.

Document: draft-ietf-idr-sla-10
Reviewer: David Black
Review Date: February 21, 2017

Review result: Not Ready

This is an early TSV-ART review of a working group draft, requested by
the IDR Working Group.

This draft defines an extension to BGP to allow exchange of traffic
handling parameters (e.g., configured rates, burst sizes, drop
thresholds).  While this is a useful area of technology to standardize=
across network operators, this draft has significant problems, and
parts of it could use some serious rethought.

This reviewer has discussed small portions of this draft with some of
the authors in the past, but this is his first comprehensive reading
and review of the draft.

Major Issues:

[1] The draft is misnamed.  This is not an SLA (Service Level
Agreement) draft - it's a TCA (Traffic Conditioning Agreement) draft -
see the definition of TCA in RFC 2475.  This draft should start from that definition and generalize the applicability of TCA beyond
Diffserv.  Large areas of SLA content are not covered by this draft -<= br> for more details, see the Wikipedia article on SLA:
https://en.wikipedia.org/wiki/Service-level_agreement .

##svshah, sure, we can change the term to TCA (Traffic Conditioning Agreeme= nt), which fairly represents intention in the draft, if there is no otherwi= se comment from the working group.<= /o:p>

 =


David> That would be good, thanks.

[2] Section 3.3.2.1's reuse of the TSpec construct from RFC 2115 to
specify a token bucket is a good idea, but it's not a good idea to
respecify that construct in terms of L2 (link-layer, e.g., Ethernet)
octets, as the RFC 2115 TSpec is specified in terms of IP octets.
This change to specification in terms of L2 octets results in needing
the L2_OVERHEAD TLV to cope with the possible differences in L2 (link)
framing overhead at sender and receiver of this information.  The
TSpec should be respecified at the IP layer, with L2 framing overhead
left to the Producer and Consumer to factor into their calculations
based on each's direct knowledge of L2 functionality and configuration
in the local AS.  That ought to enable elimination of the L2_OVERHEAD<= br> TLV, thereby reducing complexity.

##svshah, the purpose for advertising L2 = overhead, from the Producer to the Consumer, is to make sure traffic is well conditioned, at the egress of the Consumer, to avoid = possible indiscriminate drops at the ingress of the Producer. In another wo= rds, the Producer is telling the Consumer to ignore its own link = level overhead, instead use Producer's provided link level overhead while running frames through QoS functions (this is&nb= sp;relevant in use-cases where l2 overhead of the egress link on Consu= mer and of ingress link on the Producer are of different size, e.g., in the=  vpn/tunnel connection between two peer nodes which physically may be multiple hops away).

I understand your comments regarding re-u= sing TSpec without any modification. Do you agree with the use-case of l2 differences? If yes, any suggestion how to accommodate that= ?

 =

David> Specifying this in terms of I= P octets implies that L2 overhead is to be ignored on both links.  That’s simpler, and a few sentences of discussion about possible L2 = framing differences should cover what needs to be done (e.g., if traffic ra= tes are configured in terms of L2 octets, then explain how each entity conv= erts between IP traffic and L2 traffic - the draft already effectively contains that explanation).

 

##svshah2, just to make sure that some of= the real use are not left out..

 

For the traffic conditioning where sla es= tablished is for the ip based rates only, it suffices for the Producer to send rates only IP based ignoring any specific of l2 = overheads.

 

Though for the cases where physical&= nbsp;links are not to be over-run, and/or, sla defined are based = on l2 rates, the Consumer would need to know l2 overhead from the Produc= er. Otherwise 10 byes of l2 overhead difference on 64 bytes packets can be = significant compare to on 1400 bytes packets, and thus the Producer does no= t have a way to convert rates to ip based (this can cause functional issue), since this has to be per packet conside= ration.

 

Regards,

Shitanshu

 

 

 


[3] A token bucket should have two rate-related marking parameters
based on its token fill rate, i.e., min-rate, not the four
rate-related marking parameters in this draft.  The max-rate
parameters in sections 3.3.2.5-6 ought to be specified against a
second token bucket.  In addition, the handling precedence algorithm in section 3.3.2.7 is an overly complex way to specify the
relationship of two token buckets.  All of this is even more
important, because max-rate, as defined in RFC 2115, is only
applicable to bursting - that max-rate for bursting often turns out to
be an interface line rate, which is not generally useful for the
traffic provisioning purposes of this draft.

 =

##svshah, what you describe below concept= ually very much makes sense and that is what we attempt to achieve. What is unclear though how to capture that using TSpec definition= specified in RFC2215. Since that TSpec definition has both minimum-rate an= d maximum-rate, but no in/out profile marking parameters.

 =

Is your proposal below to define two TSpe= cs using the same definition from RFC2215? Wouldn't in that case we have min/max specified twice? min/max in each TSpec? and thus conf= using to represent one min and one max through two TSpecs?

 =

David> See RFC 2698 for the desired = behavior and the parameters needed to specify it.  The current idr-sla draft is not able to represent the traffic conditioning mechanisms= specified in both RFC 2698 and RFC 2697, as each mechanism requires two to= ken buckets (e.g., there are two burst sizes, but the idr-sla draft TSpec o= nly contains one).  This deficiency needs to be dealt with.  One possibility for simplification is to dro= p the max-rate from the RFC 2115 TSpec and assume that the max-rate for bur= sting is the effective line rate.


The following should be done instead:
        - Define TSpecs for two token bu= ckets, a primary/committed token bucket
            &nb= sp;   and a secondary/peak token bucket that MUST be nested, i.e.= , traffic
            &nb= sp;   that is in-profile for the secondary/peak token bucket is a= lways
            &nb= sp;   in-profile for the primary/committed token bucket.  So= me of the details
            &nb= sp;   of how to specify this are subtle, see RFC 2698 for a worke= d example.
            &nb= sp;   Use of a secondary/peak token bucket requires use of the pr= imary/
            &nb= sp;   committed token bucket, but a primary/committed token bucke= t can be used
            &nb= sp;   without a secondary/peak token bucket.
        - For a single token bucket, def= ine two handling TLVs, Committed (in profile) and
            &nb= sp;   Excess (out of profile).
        - For two token buckets, define = three handling TLVs, Committed (in profile for both
            &nb= sp;   token buckets), Peak (out of profile for primary/committed = token bucket, but in
            &nb= sp;   profile for secondary/peak token bucket) and Excess (out of= profile for both
            &nb= sp;   token buckets).
NB: Could use Green/Yellow/Red terms instead of Committed/Peak/Excess
terms.

[4] The drop threshold TLV in section 3.3.2.8 is not specified
sufficiently to be implemented interoperably.  For example, I don't understand what an implementation is supposed to do when it receives 3
drop thresholds.

##svshah, It is around the semantics= of a single queue with a different threshold for a set of code-points= , where packet for a specific code-point is to be tail dropped if overall qu= eue-depth hits code-point specific threshold at the arrival of that packet.=

We will add appropriate clarification for= this semantics.

 =

David> Will look at revision


[5] The relative priority TLV in section 3.3.2.9 has the same
insufficient specification problem as the drop threshold TLV,
compounded by a functional incompleteness problem - if the recipient
is using a weighted packet transmission scheduler (e.g., WRR),
priorities cannot be used to configure that scheduler.  Hence, some specification of weights and scheduling algorithms that use weights
needs to be added.

##svshah, Sure. Is following clarificatio= n okay? (some of the wordings taken from RFC2598)

 =

"=

A higher priority class of traffic t= o be served without pre-empted by lower priority class of traffic = ;for more than a packet time at the configured rate.

 =

In the system that implements WRR, the us= e of relative priority may get restricted where a single queue may be used for a higher priority traffic class where that queue &nbs= p;is configured for the full share of the output bandwidth.

"=

 =

David> Last sentence basically says that W= RR weights are out-of-scope.  That seems wrong.  Will look at revision.

[6] I have no idea what the sub-traffic classes TLV in section
3.3.2.10 is supposed to do, as that TLV is specified based on "Traffic=
Class TLVs" which is an undefined term in this draft (e.g., that term<= br> is not used outside of section 3.3.2.10.=

##svshah, They are to facilitate hierarch= y. A specific Traffic Class, can further be divided in a multiple  subset of Traffic Classes, with their own Traffic Class Element= s and Traffic Class Services.=

 =

Will correct the wording to remove your t= his specific concern.<= /p>


David> Will look at revision


[7] This draft's QoS contents need to be functionally aligned with
work-in-progress on YANG QoS models, in order to provide some
assurance that that this draft is implementable for actual network
switch/router data paths.  The current acknowledgement of the
existence of YANG, NETCONF and RESTConf at the end of Section 1 does
not suffice.

##svshah, While eventually "Tra= ffic Conditioning Agreement" should be translated to the actual forwar= ding qos policy on any vendor specific device, TCA exchange largely carries con= cepts/semantics that is either standard based or well understood.

 =

While we are not aware of any working gro= up document of QoS Yang Model, we think that  concepts of Traffic Conditioning should be easily adaptable to any QoS Yang Models sin= ce they also have to be defined to support those concepts.

 =

 =

David> Still want to see cross-check= with implementations here.


[8] There are significant complexity and correctness problems caused
by the option to not specify the Source AS - e.g., Section 3.2 defines
an SLA ID as an "identifier which is unique in the scope of Source AS&= quot;
which is meaningless if there is no Source AS.  It would be simpler to=
always specify Source AS, even in the point-to-point case.

##svshah, okay. Ron Bonica also suggested same in his review earlier. We ha= d chosen a path of optional Source AS to simplify implementations in c= ases. Given specification of Source AS always is more clearer in multiple f= eed-back we have gotten so far, we can modify the specification to incorporate that over the simplicity of implem= entation for certain cases.

 

David> OK, thanks.


[9] In section 3.2, the "intended for = the peer receiver of the BGP
UPDATE message" text in the specificat= ion of bit 0 of the SLA Subtype
flags is unclear.  I suspect that this= is intended to differentiate
the two usages described in sections 4.1.1 = (Point-to-Point) and 4.1.2
(Multiple Hops), in which case the parenthe= sized terms (or similar
terminology) should be used with cross-refe= rences to those two
sections.

##svshah, sure will make necessary change= s, also in the context of earlier comment.

 


[10] There needs to be a coherent discussio= n in one place about how
SLA advertisement, update and withdrawal wo= rk.  A single ADVERTISE
method may suffice on the wire, but the det= ails on how initial
advertisement, subsequent advertisement (up= date) and withdrawal work
need to be specified in one place.  Th= e third paragraph of Section 4
is a start on this material, but it's too t= erse; 

 

[Med] That text is terse because we are reusing the BGP mach= inery for advertising/withdrawing; we only augment it with triggers that are linked to the SLA information. A new SLA will le= ad to an update message with ADVERTISE, an update of an existing SLA will t= rigger an update message. We do think this information is already present i= n the document.

 

David>This is hard to understand it,= as there is no statement that the BGP machinery is being used, and the material on SLA usage is spread in different places.  I sugge= st starting section 3 with a discussion of advertisement/update/withdrawal,= and how all three are realized via a single ADVERTISE method via BGP UPDAT= E - this was difficult to figure out in reading the current draft.

 <= /p>

it should be expanded into its own subsection, and moved earlier = to come before the
ADVERTISE method in Section 3.2.  This= text from Section 3.2 should be
moved into that new subsection and likewise= expanded:

[Med] Another option is to move it Section 4. From our standpo= int, we do think it is straightforward to describe the behavior once the at= tributes format are defined. <= /o:p>

 

David> Ok, that’s an editorial= choice - I prefer to explain how something works before defining its on-the-wire data format.

 

      If an adve= rtised SLA ID is different from earlier advertised one,
      for the same= prefix and from the same Source AS, indicates Source
      AS is advert= ising new SLA Content to replace the previous one
      advertised w= ith the same SLA ID.

In addition, I wonder whether functionality= should be added to allow
withdrawal of an advertisement by specifyin= g its SLA ID, although that
was not part of the original design.=

 

<= span style=3D"font-size:10.0pt;font-family:"Courier New";color:bl= ack">[Med] The reason we didn’t adopted that design is that we don= 217;t want to make assumptions on which data the remote peer will be used for enforcing local actions and also because of this text:

  &n= bsp;   The SLA ID applies to aggregate traffic to prefixes for a = given

  &n= bsp;   AFI/SAFI that share the same Source AS and SLA ID.<= span style=3D"font-family:"Calibri","sans-serif";color:= black">

 

David> That’s fine, I wanted to ensu= re that this had been considered.  The discussion of BGP mechanism reuse will probably help here.

[11] Notions of context for interpretation = of all the IPFIX parameters
in 3.3.1 need to be added, e.g.:
        = - The first three parameters (DSCP, MPLS EXP field in top label, 802.1q priority) can
       &= nbsp;        and do vary on a link-by-li= nk or LSP-by-LSP basis along a traffic's network path.
        = - The IP address parameters are rather likely to be VPN-specific when there's more
       &= nbsp;        than one BGP/MPLS VPN that = spans or transits the ASs involved.
        = - The transport port parameters need specification of which transport header and where it
       &= nbsp;        is located (e.g., for TCP t= raffic carried by in VXLAN, is this the inner TCP header
       &= nbsp;        or the outer UDP header in = VXLAN).
There are probably simple approaches to spe= cifying context in all
cases, but that context does need to be spe= cified ... in all cases.

[Med] We dind’t include a context field because we thoug= ht that the definition of the IPFIX attributes is sufficient by itself, but= if you do think it is helpful to have such information, we can update the table.

David>  Really???  Please = reread the first comment above:

 

       = ; - The first three parameters (DSCP, MPLS EXP field in top label, 802.1q p= riority) can
       &= nbsp;        and do vary on a link-by-li= nk or LSP-by-LSP basis along a traffic's network path.

 

David>  Taking just DSCP, it ca= n change on a per-link basis, so something has to specify which link (between the SLA Producer and SLA Consumer?) is involved.  It probabl= y suffices to say that it’s the link that crosses the relevant AS bou= ndary, but that does have to be stated, as it’s nowhere to be found i= n the far more general IPFIX registry.

[12] The security considerations (section 1= 0) are severely incomplete
and insufficient:

 

David> I stand by this statement and= recommend a complete rewrite of the security considerations.


        = - Discussion of possible abuse of this BGP option for denial-of-service and theft-of-service,
       &= nbsp;        needs to be added, includin= g possible countermeasures and mitigations.

[Med] This attack vector is not specific to this attribute; th= is is valid for BGP in general.

 

David> There are additional attacks = enabled by this attribute.


        = - This sentence at the end of the second paragraph in Section 10 is<= span style=3D"font-size:10.0pt;font-family:"Calibri","sans-s= erif";color:#1F497D"> content-free:

       &= nbsp;           It is NOT= RECOMMENDED to enable this attribute at the
       &= nbsp;           scale of = the Internet unless if means to prevent leaking sensitive
       &= nbsp;           informati= on are enforced.

       &= nbsp;        What exactly is an implemen= ter or admin supposed to do? <= /o:p>

 

[Med] An example of what an admin needs to check if this inf= ormation can be sent to a given peer or not. Some of the content of the attribute contains some sensitive information such a= s contract Id, classes, etc.<= /span>

 

How does one
       &= nbsp;        figure out whether an imple= mentation or deployment is  "at the scale
       &= nbsp;        of the Internet" ??

 

[Med] The idea here is to avoid leaking such data in to the = global routing table. Only entitled peers need receive such information with controlled scope.=

 

David> I understand the idea - the problem= is that I don’t see specification of what has to be implemented in either the text in the draft or the above explanations.

        - Th= e next to last paragraph in section 10 is almost content-free, as it leaves
       &= nbsp;        decisions on implementation= and deployment of key security functionality as
       &= nbsp;        "an exercise for the r= eader" - that's not acceptable.

[Med] I guess = you are referring to the following text. Validation checks are really deplo= yment-specific. The text calls out the issue and recommends an action; how to translate this action into detailed actions i= s realty local to a domain

  =
; The attribute may be advertised by a misbehaving node to communicate
  =
; SLA parameters that are not aligned with the SLA agreements.  Though=

  =
; the enforcement of SLA parameters is outside the scope of this
  =
; document, it is RECOMMENDED that the SLA Consumer to enforce a set of
  =
; validation checks before translating the SLA parameters conveyed in
  =
; the QoS attributes into provisioning actions.  Such validations MAY<=
/span>
  =
; rely on SLA parameters like the origin AS or SLA ID, like generating
  =
; SLA ID using pseudo-random schemes [RFC4086].

 

David> I stand by the “exercis= e to the reader”  criticism - one way to be honest about this wo= uld be to change the paragraph to:

 
        =
The attribute may be advertised by a m=
isbehaving node to communicate
  =
; SLA parameters that are not aligned with the SLA agreements.  The
   enforcement of SLA paramete=
rs is outside the scope of this document.
 
David> That does not change any normative content of the =
original paragraph.  My view is that the “outside the scope of t=
his document” statement is wrong because all of these parameters are =
being defined in this draft.<=
/span>


        = - Last, but not least, the final paragraph in Section 10 is a joke that will
       &= nbsp;        be lost on a security direc= torate reviewer - to understand why, see
       &= nbsp;        Section 2 of RFC 6919, and = take note of the publication date of RFC 6919.

David> For anyone who didn’t catch the reference, RFC 6919 is an A= pril 1 RFC ... and the “SHOULD BE considered” language used in = the last security considerations paragraph of this draft is accurately char= acterized as vague in Section 2 of RFC 6919:

   The phrase "SHOULD CONSIDER" indicates that th= e authors of the

   specification think that implementations should do somet= hing, but

   they're not sure quite what.

------------------------

Having noted a dozen major issues, I'll end= the review here for now,
as I believe a serious revision of the draf= t is called for, which
would be a better starting point to review = for minor issues and
editorial items.

-------------------------------------------= -------------
David L. Black, Distinguished Engineer
Dell EMC, 176 South St., Hopkinton, MA = ; 01748
+1 (508) 293-7953   &nbs= p; Cell: +1 (978) 394-7754
Dav= id.Black@dell.com  <=3D=3D=3D NEW =3D=3D=3D -------------------------------------------= -------------

--_000_CE03DB3D7B45C245BCA0D243277949362F8DD70AMX307CL04corpem_-- From nobody Fri Mar 3 17:30:22 2017 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E0CC12958A; Fri, 3 Mar 2017 17:30:17 -0800 (PST) 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.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148859101744.15870.7067472166462988785.idtracker@ietfa.amsl.com> Date: Fri, 03 Mar 2017 17:30:17 -0800 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-shutdown-07.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Mar 2017 01:30:17 -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 of the IETF. Title : BGP Administrative Shutdown Communication Authors : Job Snijders Jakob Heitz John Scudder Filename : draft-ietf-idr-shutdown-07.txt Pages : 6 Date : 2017-03-03 Abstract: This document enhances the BGP Cease NOTIFICATION message "Administrative Shutdown" and "Administrative Reset" subcodes for operators to transmit a short freeform message to describe why a BGP session was shutdown or reset. This document updates RFC 4486. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-shutdown/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-shutdown-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-shutdown-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Mar 3 22:35:41 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5DE5129482 for ; Fri, 3 Mar 2017 22:35:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.369 X-Spam-Level: X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.229, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IxEd9j6Sn4Sc for ; Fri, 3 Mar 2017 22:35:37 -0800 (PST) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::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 B5E0E12947D for ; Fri, 3 Mar 2017 22:35:37 -0800 (PST) Received: by mail-qk0-x233.google.com with SMTP id v125so29296661qkh.2 for ; Fri, 03 Mar 2017 22:35:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=0CbkYfN5no6c3rh7xsZXarsYt9VKokAgzzftxdCfy7E=; b=I8uzptOwND8ANYcTmwy4dRW2AXF5cg/C0v+sqT9fIgbnp0Xxk4B0e2F7tU1pr2fIZ5 Njkm63+2rbs/U4W16wvPUutHemuUDP942+Itxhwmxm4S7H2kSYLPlXao7dzIV6ra1DrL TvM1K4cKDc1fB8G67nA7U+4NpQWn9Ecw96Ytuc6/1E7urihfbhXRDFuKDyPhDLhkAfxI DoOfqc0ERTnneQzspn1WSv98P9DmNFiC0fUiW53xrc2gi2r2hBBGyqFVJzGVazLOUuRu 57pntUJTsiExP1UyNhAFLpUVP8lYgidjfC+Io3BRIXq7cNsxVV3JTfvc2B2tpxU8xD9I cR5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=0CbkYfN5no6c3rh7xsZXarsYt9VKokAgzzftxdCfy7E=; b=RWLLP4Tmwh341KHZR1n9BQ5MZu0Mq8BB+7InVr/LqXmczeJyOeVLgXw/lbgX1K4KsS VdqjVSortYmECePZznj9TgVZ4MKAwbi+YUMujwhpF3SRIbzNzoPIxY30ZCqu8gDrhNZr +aSFXO3x+k+e/gRfoE5wQabBg0vy27dVMs2M1DhvbogbK8r6kpMlhQOlsCh03Pzpe0Fx ZTeZL+U2p4yRd01CXdUZm4UK8PZw1t+51q7wpCGcUqArp5rgfV2zj6ANbXvbdDrolMH9 4+77c573MGhaJXf2oCCJDAajSouJUbAN71C1Su7DtH+MeD0D21U7+V56row5Oh0+/mDD 13iw== X-Gm-Message-State: AMke39mx5gIzWwpVlFdlBZ56N64P6EipcsuMwKs646FSrnvZu9l/W1yjWPvwBXbtMkakDJLbZwBElsppthaZuQ== X-Received: by 10.55.128.66 with SMTP id b63mr6860136qkd.297.1488609336679; Fri, 03 Mar 2017 22:35:36 -0800 (PST) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.140.42.181 with HTTP; Fri, 3 Mar 2017 22:35:36 -0800 (PST) In-Reply-To: <4BF12F22-F605-406F-9CD8-ACE350B981D0@alcatel-lucent.com> References: <148854728632.10105.590253116263033290.idtracker@ietfa.amsl.com> <4BF12F22-F605-406F-9CD8-ACE350B981D0@alcatel-lucent.com> From: Robert Raszuk Date: Sat, 4 Mar 2017 07:35:36 +0100 X-Google-Sender-Auth: yOn0igIg0ZnYscEtqEjlBrxfgEQ Message-ID: To: "Van De Velde, Gunter (Nokia - BE)" Content-Type: multipart/alternative; boundary=94eb2c06654cb904150549e1de64 Archived-At: Cc: idr Subject: Re: [Idr] FW: New Version Notification for draft-vandevelde-idr-bgp-ls-segment-routing-rld-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Mar 2017 06:35:39 -0000 --94eb2c06654cb904150549e1de64 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hey Gunter, Good proposal however why do you only think about labels ? Seriously if this is to move fwd let's add ability to signal also following elements: * ability to punt SR-MPLS to local CPU (slow path) when not handled in hardware (per node basis) * add signalling for number of SRv6 SRHs supported per node/per LC * add signalling for depth per SRH and total of SIDs supported per node/per LC * signal ability to punt to slow path or not for longer then support SRH stack or number of SIDs in each SRH structure. Cheers, Robert. On Fri, Mar 3, 2017 at 3:55 PM, Van De Velde, Gunter (Nokia - BE) < gunter.van_de_velde@nokia.com> wrote: > Heads-up=E2=80=A6 Happy to learn feedback and comments. > > This draft is short and defines the attribute to use for BGP-LS to expose= a > node RLD "Readable Label Depth" to a centralised controller (PCE/SDN). > > G/ > > On 03/03/2017, 14:21, "internet-drafts@ietf.org" > wrote: > > > A new version of I-D, draft-vandevelde-idr-bgp-ls- > segment-routing-rld-01.txt > has been successfully submitted by Gunter Van de Velde and posted to > the > IETF repository. > > Name: draft-vandevelde-idr-bgp-ls-segment-routing-rld > Revision: 01 > Title: Signalling RLD using BGP-LS > Document date: 2017-03-03 > Group: Individual Submission > Pages: 5 > URL: https://www.ietf.org/internet- > drafts/draft-vandevelde-idr-bgp-ls-segment-routing-rld-01.txt > Status: https://datatracker.ietf.org/ > doc/draft-vandevelde-idr-bgp-ls-segment-routing-rld/ > Htmlized: https://tools.ietf.org/html/ > draft-vandevelde-idr-bgp-ls-segment-routing-rld-01 > Diff: https://www.ietf.org/rfcdiff? > url2=3Ddraft-vandevelde-idr-bgp-ls-segment-routing-rld-01 > > Abstract: > This document defines the attribute to use for BGP-LS to expose a > node RLD "Readable Label Depth" to a centralised controller (PCE/ > SDN). > > > > > > 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 > --94eb2c06654cb904150549e1de64 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hey Gunter,
Good proposal however why do you only think about= labels ?

Seriously if= this is to move fwd let's add ability to signal also following element= s:

* ability to punt S= R-MPLS to local CPU (slow path) when not handled in hardware (per node basi= s)

* add signalling fo= r number of SRv6 SRHs supported per node/per LC
* add signalling for depth per SRH and total of S= IDs supported per node/per LC

* signal ability to punt to slow path or not for longer then suppo= rt SRH stack or number of SIDs in each SRH structure.

Cheers,
Robert.
=

O= n Fri, Mar 3, 2017 at 3:55 PM, Van De Velde, Gunter (Nokia - BE) <gunter.van_de_velde@nokia.com> wrote:
Heads-up=E2=80=A6 Happy to learn feedback and comments.

This draft is short and defines the attribute to use for BGP-LS to expose a=
node RLD "Readable Label Depth" to a centralised controller (PCE/= SDN).

G/

On 03/03/2017, 14:21, "int= ernet-drafts@ietf.org" <internet-drafts@ietf.org> wrote:


=C2=A0 =C2=A0 A new version of I-D, draft-vandevelde-idr-bgp-ls-segmen= t-routing-rld-01.txt
=C2=A0 =C2=A0 has been successfully submitted by Gunter Van de Velde and po= sted to the
=C2=A0 =C2=A0 IETF repository.

=C2=A0 =C2=A0 Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0d= raft-vandevelde-idr-bgp-ls-segment-routing-rld
=C2=A0 =C2=A0 Revision:=C2=A0 =C2=A001
=C2=A0 =C2=A0 Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Signal= ling RLD using BGP-LS
=C2=A0 =C2=A0 Document date:=C2=A0 =C2=A0 =C2=A0 2017-03-03
=C2=A0 =C2=A0 Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Indivi= dual Submission
=C2=A0 =C2=A0 Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 5
=C2=A0 =C2=A0 URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/int= ernet-drafts/draft-vandevelde-idr-bgp-ls-segment-routing-rld-01.<= wbr>txt
=C2=A0 =C2=A0 Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/d= raft-vandevelde-idr-bgp-ls-segment-routing-rld/
=C2=A0 =C2=A0 Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-vandevel= de-idr-bgp-ls-segment-routing-rld-01
=C2=A0 =C2=A0 Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?= url2=3Ddraft-vandevelde-idr-bgp-ls-segment-routing-rld-01

=C2=A0 =C2=A0 Abstract:
=C2=A0 =C2=A0 =C2=A0 =C2=A0This document defines the attribute to use for B= GP-LS to expose a
=C2=A0 =C2=A0 =C2=A0 =C2=A0node RLD "Readable Label Depth" to a c= entralised controller (PCE/
=C2=A0 =C2=A0 =C2=A0 =C2=A0SDN).





=C2=A0 =C2=A0 Please note that it may take a couple of minutes from the tim= e of submission
=C2=A0 =C2=A0 until the htmlized version and diff are available at tools.ietf.= org.

=C2=A0 =C2=A0 The IETF Secretariat



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

--94eb2c06654cb904150549e1de64-- From nobody Sat Mar 4 00:41:15 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9BA5126DFB for ; Sat, 4 Mar 2017 00:41:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yI7Ek_2f67Kc for ; Sat, 4 Mar 2017 00:41:10 -0800 (PST) Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::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 9C94D120725 for ; Sat, 4 Mar 2017 00:41:09 -0800 (PST) Received: by mail-wr0-x22b.google.com with SMTP id u48so87167405wrc.0 for ; Sat, 04 Mar 2017 00:41:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JX4qw0qL18oZP1Gtc+BdhMXMqubMev7VUZqdfsKVIVg=; b=ClUlNC2/HnZC2M8tLMWiM5oF8dbN94K2QbxTRyUL73OLczfujEsts/oa3bcepFcctE +cLrFy1zKc5R2znwrdlZrnxEJN0Aqm/mRhyxZChj8fExO52wZK/Ug6hPsptj88T7Memb uszlOuQ4+vSLMwVohVk6uXHUrKkl7jDYFyqZMQMYDgIXZF3AcsQKGMA5h90aCWNttRzI TXQXsNmGRxT8hPrea8B8Y+gYDaFQor12QhsMDSQD+rtZdY3L7iRxoj1WIFpk0b/AiaYN QRVWyViIGAOeWClxrPtUTG5qJaA/4fyIxsrBByT+3LP7btCCpqJCjJo3i28+HbaD53IA miYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JX4qw0qL18oZP1Gtc+BdhMXMqubMev7VUZqdfsKVIVg=; b=KqJeRL9PY1wpU0f9b/WZ92/ZigpE0CxCEWexLSlW9kkJiCv3RpxsNVTjDjxOeoX8zm PFwtzV1Bpy8xAIx0Ppnti4SqmZEobGGaRTImXmJOx/5HHtmBccO/f8rAm6vXa83moOG4 bcH0tMSe3swoBe0cVCdsaJi1tmhxLqGcsz7wxqwzu3M5hAN5W5HY0ocbhCg+NdH8/fjv VycdFIVZ4F6aP2w3ZWM37mkn7kAheRu7Klt+RJdfKnF/lQo72jpfIddK+PnQGO5rlJqU qBXH5EUwMvoUArX6dELXqwRwD6f1F10SOJxFDw1FOLkuhMhukXT46JCQJKO9zsZbc32D 66DA== X-Gm-Message-State: AMke39lNYEocuE3WPjuII7JOr/VT+B1sHjrnDDX6ErPuTAuOUOQQBuh+9kVjQfpaArJpfO6MG/eHMNjU7l1N5A== X-Received: by 10.223.176.225 with SMTP id j30mr5858918wra.25.1488616868118; Sat, 04 Mar 2017 00:41:08 -0800 (PST) MIME-Version: 1.0 References: <148854728632.10105.590253116263033290.idtracker@ietfa.amsl.com> <4BF12F22-F605-406F-9CD8-ACE350B981D0@alcatel-lucent.com> In-Reply-To: From: Jeff Tantsura Date: Sat, 04 Mar 2017 08:40:57 +0000 Message-ID: To: Robert Raszuk , "Van De Velde, Gunter (Nokia - BE)" Content-Type: multipart/alternative; boundary=001a11438d66a183670549e39fa9 Archived-At: Cc: idr Subject: Re: [Idr] FW: New Version Notification for draft-vandevelde-idr-bgp-ls-segment-routing-rld-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Mar 2017 08:41:12 -0000 --001a11438d66a183670549e39fa9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Robert, That's done in MSD drafts. In the recently published isis draft we have also introduced MSD type flag that would be used to signal different types of SID's: recirculated labels, EL's, etc Cheers, Jeff On Fri, Mar 3, 2017 at 22:35 Robert Raszuk wrote: Hey Gunter, Good proposal however why do you only think about labels ? Seriously if this is to move fwd let's add ability to signal also following elements: * ability to punt SR-MPLS to local CPU (slow path) when not handled in hardware (per node basis) * add signalling for number of SRv6 SRHs supported per node/per LC * add signalling for depth per SRH and total of SIDs supported per node/per LC * signal ability to punt to slow path or not for longer then support SRH stack or number of SIDs in each SRH structure. Cheers, Robert. On Fri, Mar 3, 2017 at 3:55 PM, Van De Velde, Gunter (Nokia - BE) < gunter.van_de_velde@nokia.com> wrote: Heads-up=E2=80=A6 Happy to learn feedback and comments. This draft is short and defines the attribute to use for BGP-LS to expose a node RLD "Readable Label Depth" to a centralised controller (PCE/SDN). G/ On 03/03/2017, 14:21, "internet-drafts@ietf.org" wrote: A new version of I-D, draft-vandevelde-idr-bgp-ls-segment-routing-rld-01.txt has been successfully submitted by Gunter Van de Velde and posted to th= e IETF repository. Name: draft-vandevelde-idr-bgp-ls-segment-routing-rld Revision: 01 Title: Signalling RLD using BGP-LS Document date: 2017-03-03 Group: Individual Submission Pages: 5 URL: https://www.ietf.org/internet-drafts/draft-vandevelde-idr-bgp-ls-segment-ro= uting-rld-01.txt Status: https://datatracker.ietf.org/doc/draft-vandevelde-idr-bgp-ls-segment-routin= g-rld/ Htmlized: https://tools.ietf.org/html/draft-vandevelde-idr-bgp-ls-segment-routing-rld= -01 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-vandevelde-idr-bgp-ls-segment-rou= ting-rld-01 Abstract: This document defines the attribute to use for BGP-LS to expose a node RLD "Readable Label Depth" to a centralised controller (PCE/ SDN). Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr --001a11438d66a183670549e39fa9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Robert,

That's done= in MSD drafts.
In the recently published isis draft= we have also introduced MSD type flag that would be used to signal differe= nt types of SID's: recirculated labels, EL's, etc

Cheers,
Jeff

On Fri, Mar 3, 2017 at= 22:35 Robert Raszuk <robert@raszuk.net> wrote:
Hey Gunter,

Good proposal= however why do you only think about labels ?

Seriously i= f this is to move fwd let's add ability to signal also following elemen= ts:

* ability to punt SR-MPLS to local CPU (slow path) wh= en not handled in hardware (per node basis)

* add signall= ing for number of SRv6 SRHs supported per node/per LC

* a= dd signalling for depth per SRH and total of SIDs supported per node/per LC=

* signal ability to punt to slow path or not for longer = then support SRH stack or number of SIDs in each SRH structure.

Cheers,
Robert.


On Fri, Mar= 3, 2017 at 3:55 PM, Van De Velde, Gunter (Nokia - BE) <gunter.van_de_velde@nokia.com> wrote:
Heads-up=E2= =80=A6 Happy to learn feedback and comments.

This draft is short and defines the attribute to use for BGP-LS to expose a=
node RLD "Readable Label Depth" to a centralised controller (PCE/= SDN).

G/

On 03/03/2017, 14:21, "internet-drafts@ietf.org" <<= a href=3D"mailto:internet-drafts@ietf.org" class=3D"gmail_msg" target=3D"_b= lank">internet-drafts@ietf.org> wrote:


=C2=A0 =C2=A0 A new version of I-D, draft-vandevelde-idr-bgp-ls-segment-rou= ting-rld-01.txt
=C2=A0 =C2=A0 has been successfully submitted by Gunter Van de Velde and po= sted to the
=C2=A0 =C2=A0 IETF repository.

=C2=A0 =C2=A0 Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0d= raft-vandevelde-idr-bgp-ls-segment-routing-rld
=C2=A0 =C2=A0 Revision:=C2=A0 =C2=A001
=C2=A0 =C2=A0 Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Signal= ling RLD using BGP-LS
=C2=A0 =C2=A0 Document date:=C2=A0 =C2=A0 =C2=A0 2017-03-03
=C2=A0 =C2=A0 Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Indivi= dual Submission
=C2=A0 =C2=A0 Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 5
=C2=A0 =C2=A0 URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http= s://www.ietf.org/internet-drafts/draft-vandevelde-idr-bgp-ls-segment-routin= g-rld-01.txt
=C2=A0 =C2=A0 Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker= .ietf.org/doc/draft-vandevelde-idr-bgp-ls-segment-routing-rld/
=C2=A0 =C2=A0 Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html= /draft-vandevelde-idr-bgp-ls-segment-routing-rld-01
=C2=A0 =C2=A0 Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://w= ww.ietf.org/rfcdiff?url2=3Ddraft-vandevelde-idr-bgp-ls-segment-routing-rld-= 01

=C2=A0 =C2=A0 Abstract:
=C2=A0 =C2=A0 =C2=A0 =C2=A0This document defines the attribute to use for B= GP-LS to expose a
=C2=A0 =C2=A0 =C2=A0 =C2=A0node RLD "Readable Label Depth" to a c= entralised controller (PCE/
=C2=A0 =C2=A0 =C2=A0 =C2=A0SDN).





=C2=A0 =C2=A0 Please note that it may take a couple of minutes from the tim= e of submission
=C2=A0 =C2=A0 until the htmlized version and diff are available at tools.ietf.org.

=C2=A0 =C2=A0 The IETF Secretariat



_______________________________________________
Idr mailing list
Idr@i= etf.org
https://www.ietf.org/mailman/listinfo/i= dr

_______________________________________________
Idr mailing list
Idr@i= etf.org
https://www.ietf.org/mailman/listinfo/i= dr
--001a11438d66a183670549e39fa9-- From nobody Sat Mar 4 00:54:17 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80D93129430 for ; Sat, 4 Mar 2017 00:54:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.369 X-Spam-Level: X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.229, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3cLdU4L_VYAY for ; Sat, 4 Mar 2017 00:54:14 -0800 (PST) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6527E127077 for ; Sat, 4 Mar 2017 00:54:14 -0800 (PST) Received: by mail-qk0-x232.google.com with SMTP id v125so31409960qkh.2 for ; Sat, 04 Mar 2017 00:54:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=GsLDly7E2p0mHVRK7jmjUpUlIQnDRzN6KAbex7rzxEw=; b=czNynzcKcsjux30z9EOApAPCUNtA7GUXvUqXfNbAZWx2toAl89j0ZvwTAx3CZEKwXf dttx7XKzN6/m5ngSkSUdN9OZqp3MWZhsxX/Iy1ZpUzvrS8TC98HKtb4xekZD5XiP0JUw 7rcyFmBHxUv5EyMP0EXdseh+fAtz7V9JNvaXjOXc5+mk/AqY3cJxrT5wn+9aUnF/IixM sm7tsFy95tGnHxVsF/oNFvoDwhu0tZ2sORTD27BSWyLxKUUHvbsEKUOKb9EEEU6QU09y dg7ozOGeDRqHf9qn4J63/JBLQE8OmU06pC5BrFQXTkO71af9yL8+EeVh3+TgCTe9k0Zv TQpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=GsLDly7E2p0mHVRK7jmjUpUlIQnDRzN6KAbex7rzxEw=; b=VFLohw0TLuxscgGDcBL8/IiXp+0W32ngGUEMUrKlglwRi8t6sxJk1mr9jVY7cwrr/J 32PUiz4hkURkuXevN1gp7HlhKrSDQRLdcrB0B/ibkE26usv/fhndfh+SVptJmRdmoYJH 3acJUqvKfS0aoNtzVFFXB0cygM07jyhz8n4UvaoXcEa+0LOs0yK91k2wSPekK2e8zIXb vxERKSZ1NDJfmH/VBSBak5Ol34syPp9B3y7t5wOZGBS2qVWDPXgEUeBWvK8ZDAEZINGR qMqzUWX5jK5T9dOLTw16em7pYjDJQ0e5gxDtHCd5ql2tJA1GPP768cFCiNfilOr8Gwuu c1GQ== X-Gm-Message-State: AMke39mVSmHPW7hKjt7bNvfiqq3jQt+GthuftSrBDqrmGbdRrChp6pWA1EXRIyL3Zi7oYFVzPtapeXzYIbrYTA== X-Received: by 10.55.128.66 with SMTP id b63mr7231353qkd.297.1488617653502; Sat, 04 Mar 2017 00:54:13 -0800 (PST) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.140.42.181 with HTTP; Sat, 4 Mar 2017 00:54:12 -0800 (PST) Received: by 10.140.42.181 with HTTP; Sat, 4 Mar 2017 00:54:12 -0800 (PST) In-Reply-To: References: <148854728632.10105.590253116263033290.idtracker@ietfa.amsl.com> <4BF12F22-F605-406F-9CD8-ACE350B981D0@alcatel-lucent.com> From: Robert Raszuk Date: Sat, 4 Mar 2017 09:54:12 +0100 X-Google-Sender-Auth: l6XxTTinhb3d5aOg3OrsACAVE1U Message-ID: To: Jeff Tantsura Content-Type: multipart/alternative; boundary=94eb2c06654c71c5ca0549e3ce5c Archived-At: Cc: idr wg , "Van De Velde, Gunter \(Nokia - BE\)" Subject: Re: [Idr] FW: New Version Notification for draft-vandevelde-idr-bgp-ls-segment-routing-rld-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Mar 2017 08:54:16 -0000 --94eb2c06654c71c5ca0549e3ce5c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Jeff, I am talking about max supported depth. If this is already addressed elsewhere (which I doubt) I am not sure why this draft would be needed at all then. But if it has value let's make it complete. Best, R. On Mar 4, 2017 09:41, "Jeff Tantsura" wrote: > Robert, > > That's done in MSD drafts. > In the recently published isis draft we have also introduced MSD type fla= g > that would be used to signal different types of SID's: recirculated label= s, > EL's, etc > > Cheers, > Jeff > > On Fri, Mar 3, 2017 at 22:35 Robert Raszuk wrote: > > Hey Gunter, > > Good proposal however why do you only think about labels ? > > Seriously if this is to move fwd let's add ability to signal also > following elements: > > * ability to punt SR-MPLS to local CPU (slow path) when not handled in > hardware (per node basis) > > * add signalling for number of SRv6 SRHs supported per node/per LC > > * add signalling for depth per SRH and total of SIDs supported per > node/per LC > > * signal ability to punt to slow path or not for longer then support SRH > stack or number of SIDs in each SRH structure. > > Cheers, > Robert. > > > On Fri, Mar 3, 2017 at 3:55 PM, Van De Velde, Gunter (Nokia - BE) < > gunter.van_de_velde@nokia.com> wrote: > > Heads-up=E2=80=A6 Happy to learn feedback and comments. > > This draft is short and defines the attribute to use for BGP-LS to expose= a > node RLD "Readable Label Depth" to a centralised controller (PCE/SDN). > > G/ > > On 03/03/2017, 14:21, "internet-drafts@ietf.org" > wrote: > > > A new version of I-D, draft-vandevelde-idr-bgp-ls- > segment-routing-rld-01.txt > has been successfully submitted by Gunter Van de Velde and posted to > the > IETF repository. > > Name: draft-vandevelde-idr-bgp-ls-segment-routing-rld > Revision: 01 > Title: Signalling RLD using BGP-LS > Document date: 2017-03-03 > Group: Individual Submission > Pages: 5 > URL: https://www.ietf.org/internet- > drafts/draft-vandevelde-idr-bgp-ls-segment-routing-rld-01.txt > Status: https://datatracker.ietf.org/ > doc/draft-vandevelde-idr-bgp-ls-segment-routing-rld/ > Htmlized: https://tools.ietf.org/html/ > draft-vandevelde-idr-bgp-ls-segment-routing-rld-01 > Diff: https://www.ietf.org/rfcdiff? > url2=3Ddraft-vandevelde-idr-bgp-ls-segment-routing-rld-01 > > Abstract: > This document defines the attribute to use for BGP-LS to expose a > node RLD "Readable Label Depth" to a centralised controller (PCE/ > SDN). > > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > --94eb2c06654c71c5ca0549e3ce5c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Jeff,

I am t= alking about max supported depth.

If this is already addressed elsewhere (which I doubt) I am not s= ure why this draft would be needed at all then.

=
But if it has value let's make it complete.

Best,
R.

O= n Mar 4, 2017 09:41, "Jeff Tantsura" <jefftant.ietf@gmail.com> wrote:
Robert,

That's= done in MSD drafts.
In the rec= ently published isis draft we have also introduced MSD type flag that would= be used to signal different types of SID's: recirculated labels, EL&#= 39;s, etc

Cheers,
Jeff

On Fri, = Mar 3, 2017 at 22:35 Robert Raszuk <robert@raszuk.n= et> wrote:
Hey Gunter,

Good proposal however why do you only think about labels= ?

Seriously if this is to move fwd let's add ability to signal= also following elements:

* ability to punt SR-MPLS to local CPU (slo= w path) when not handled in hardware (per node basis)

* add signallin= g for number of SRv6 SRHs supported per node/per LC

* add signallin= g for depth per SRH and total of SIDs supported per node/per LC

* sig= nal ability to punt to slow path or not for longer then support SRH stack o= r number of SIDs in each SRH structure.

Cheers,
Robert.


On Fri, Mar 3, 2017 at 3:55 PM, Van De Velde, Gunter (Nokia - BE) <gunter.van_de_velde@nokia.com> wrote:
Heads-up=E2=80=A6 Happy to learn feedback and comments.
This draft is short and defines the attribute to use for BGP-LS to expose a=
node RLD "Readable Label Depth" to a centralised controller (PCE/= SDN).

G/

On 03/03/2017, 14:21, "internet-drafts@iet= f.org" <internet-drafts@ietf.org> wrote:


=C2=A0 =C2=A0 A new version of I-D, draft-vandevelde-idr-bgp-ls-segmen= t-routing-rld-01.txt
=C2=A0 =C2=A0 has been successfully submitted by Gunter Van de Velde and po= sted to the
=C2=A0 =C2=A0 IETF repository.

=C2=A0 =C2=A0 Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0d= raft-vandevelde-idr-bgp-ls-segment-routing-rld
=C2=A0 =C2=A0 Revision:=C2=A0 =C2=A001
=C2=A0 =C2=A0 Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Signal= ling RLD using BGP-LS
=C2=A0 =C2=A0 Document date:=C2=A0 =C2=A0 =C2=A0 2017-03-03
=C2=A0 =C2=A0 Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Indivi= dual Submission
=C2=A0 =C2=A0 Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 5
=C2=A0 =C2=A0 URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-vandevelde= -idr-bgp-ls-segment-routing-rld-01.txt
=C2=A0 =C2=A0 Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-vandevelde-idr-bgp-ls-se= gment-routing-rld/
=C2=A0 =C2=A0 Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https:= //tools.ietf.org/html/draft-vandevelde-idr-bgp-ls-segment-routing= -rld-01
=C2=A0 =C2=A0 Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-vandevelde-idr-b= gp-ls-segment-routing-rld-01

=C2=A0 =C2=A0 Abstract:
=C2=A0 =C2=A0 =C2=A0 =C2=A0This document defines the attribute to use for B= GP-LS to expose a
=C2=A0 =C2=A0 =C2=A0 =C2=A0node RLD "Readable Label Depth" to a c= entralised controller (PCE/
=C2=A0 =C2=A0 =C2=A0 =C2=A0SDN).





=C2=A0 =C2=A0 Please note that it may take a couple of minutes from the tim= e of submission
=C2=A0 =C2=A0 until the htmlized version and diff are available at tools.ietf.org.

=C2=A0 =C2=A0 The IETF Secretariat



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

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.o= rg/mailman/listinfo/idr
--94eb2c06654c71c5ca0549e3ce5c-- From nobody Sat Mar 4 02:01:42 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0D511294DD for ; Sat, 4 Mar 2017 02:01:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ge-wJoH565mu for ; Sat, 4 Mar 2017 02:01:39 -0800 (PST) Received: from st13p11im-asmtp004.me.com (st13p11im-asmtp004.me.com [17.164.40.219]) (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 E8371129469 for ; Sat, 4 Mar 2017 02:01:38 -0800 (PST) Received: from process-dkim-sign-daemon.st13p11im-asmtp004.me.com by st13p11im-asmtp004.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0OMA00B00BQ31S00@st13p11im-asmtp004.me.com> for idr@ietf.org; Sat, 04 Mar 2017 10:01:38 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=4d515a; t=1488621698; bh=pAVLl3tOKhnPnhloq6xlXxbK7VZ9ssBmyrzCzGFEsPI=; h=From:Message-id:Content-type:MIME-version:Subject:Date:To; b=krLpOmOV+iR4caqhUtOgxK/UkcyEuQw2wHLT6mGBAyWT3UgfPFtUO23APBqf1o85r L0YsK7qyAb/bpVLV42uGLrnsX1lDpLf5uxAwqhJiXExuuUrMTD+wQoo4gUZUCHpgBK zUO8orNHetsuAg6jj/JjoflCKiD/pLn/sEZt48GR+nN2KCg8PQl4/filNdGb+iuOzD vSZoKii96Zxi4HDOllVahVEdEv1j1aUQ6uzaQN6G4Aq1V/3pJFMtUIXk3r6OjMU/Lb 7jGvPr8PTP0ztQ9tXRUndh+zTpqArV568cKpasSKohQmQrdTvt56IJ8cT6JOrMKaSL 9DlCINDkxC+5w== Received: from icloud.com ([127.0.0.1]) by st13p11im-asmtp004.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTPSA id <0OMA008Z0BUM1K20@st13p11im-asmtp004.me.com>; Sat, 04 Mar 2017 10:01:37 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-03-04_04:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1034 suspectscore=3 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1701120000 definitions=main-1703040077 From: Gunter Van De Velde Message-id: Content-type: multipart/alternative; boundary="Apple-Mail=_FDDA7015-D85E-46EF-ADC9-51E7749FA503" MIME-version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Sat, 04 Mar 2017 11:01:33 +0100 In-reply-to: To: Robert Raszuk References: <148854728632.10105.590253116263033290.idtracker@ietfa.amsl.com> <4BF12F22-F605-406F-9CD8-ACE350B981D0@alcatel-lucent.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: idr wg , "Van De Velde, Gunter \(Nokia - BE\)" Subject: Re: [Idr] FW: New Version Notification for draft-vandevelde-idr-bgp-ls-segment-routing-rld-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Mar 2017 10:01:41 -0000 --Apple-Mail=_FDDA7015-D85E-46EF-ADC9-51E7749FA503 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 When i was looking the MSD draft is looking at =E2=80=9CHow Many labels = can device (node/link) impose=E2=80=9D. (look at introduction in section 1 as it is explicitly written in the = text) The RLD draft is about =E2=80=9CHow many labels a device (node/link) can = read=E2=80=9D Even for the IGPs there is are different documents in either OSPF or = ISIS WG: OSPF MSD: = https://tools.ietf.org/html/draft-ietf-ospf-segment-routing-msd-00 = OSPF ELC/RLD: https://tools.ietf.org/html/draft-ietf-ospf-mpls-elc-04 = ISIS MSD: = https://tools.ietf.org/html/draft-ietf-isis-segment-routing-msd-02 = ISIS ELC/RLD: https://tools.ietf.org/html/draft-ietf-isis-mpls-elc-02 = BGP MSD: = https://tools.ietf.org/html/draft-tantsura-bgp-ls-segment-routing-msd-02 = = BGP ELC/RLD: Was MIA =E2=80=A6 so now there is = https://trac.tools.ietf.org/html/draft-vandevelde-idr-bgp-ls-segment-routi= ng-rld-01 = Hence i assumed that there is sense for two drafts in IDR to be in sync = with the IGP capabilities =E2=80=A6 one to make BGP-LS in alignment with = the IGPs for MSD and one to make BGP-LS in alignment with ELC @Robert, I do believe those data-points are of interrest to a network = SDN controller. I am not convinced they all belong in the same document. I think that on shorter term there is need that the IGP LSDB can be = exported to BGP-LS because right now that is not possible for ISIS-ELC = or OSPF-ELC.=20 My understanding is it is potentially worth having a draft on signalling = new functionality beyond the capability to signal it in the IGPs=E2=80=A6 = It is an important deviation from anything that was done before with = BGP-LS because main purpose has been to allow the export of IGP LSDB = into BGP-LS G/ > On 4 Mar 2017, at 09:54, Robert Raszuk wrote: >=20 > Jeff, >=20 > I am talking about max supported depth. >=20 > If this is already addressed elsewhere (which I doubt) I am not sure = why this draft would be needed at all then. >=20 > But if it has value let's make it complete. >=20 > Best, > R. >=20 > On Mar 4, 2017 09:41, "Jeff Tantsura" > wrote: > Robert, >=20 > That's done in MSD drafts. > In the recently published isis draft we have also introduced MSD type = flag that would be used to signal different types of SID's: recirculated = labels, EL's, etc >=20 > Cheers, > Jeff >=20 > On Fri, Mar 3, 2017 at 22:35 Robert Raszuk > wrote: > Hey Gunter, >=20 > Good proposal however why do you only think about labels ? >=20 > Seriously if this is to move fwd let's add ability to signal also = following elements: >=20 > * ability to punt SR-MPLS to local CPU (slow path) when not handled in = hardware (per node basis) >=20 > * add signalling for number of SRv6 SRHs supported per node/per LC >=20 > * add signalling for depth per SRH and total of SIDs supported per = node/per LC >=20 > * signal ability to punt to slow path or not for longer then support = SRH stack or number of SIDs in each SRH structure. >=20 > Cheers, > Robert. >=20 >=20 > On Fri, Mar 3, 2017 at 3:55 PM, Van De Velde, Gunter (Nokia - BE) = > = wrote: > Heads-up=E2=80=A6 Happy to learn feedback and comments. >=20 > This draft is short and defines the attribute to use for BGP-LS to = expose a > node RLD "Readable Label Depth" to a centralised controller (PCE/SDN). >=20 > G/ >=20 > On 03/03/2017, 14:21, "internet-drafts@ietf.org = " > wrote: >=20 >=20 > A new version of I-D, = draft-vandevelde-idr-bgp-ls-segment-routing-rld-01.txt > has been successfully submitted by Gunter Van de Velde and posted = to the > IETF repository. >=20 > Name: = draft-vandevelde-idr-bgp-ls-segment-routing-rld > Revision: 01 > Title: Signalling RLD using BGP-LS > Document date: 2017-03-03 > Group: Individual Submission > Pages: 5 > URL: = https://www.ietf.org/internet-drafts/draft-vandevelde-idr-bgp-ls-segment-r= outing-rld-01.txt = > Status: = https://datatracker.ietf.org/doc/draft-vandevelde-idr-bgp-ls-segment-routi= ng-rld/ = > Htmlized: = https://tools.ietf.org/html/draft-vandevelde-idr-bgp-ls-segment-routing-rl= d-01 = > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-vandevelde-idr-bgp-ls-segment-ro= uting-rld-01 = >=20 > Abstract: > This document defines the attribute to use for BGP-LS to expose = a > node RLD "Readable Label Depth" to a centralised controller = (PCE/ > SDN). >=20 >=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 >=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 = > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr --Apple-Mail=_FDDA7015-D85E-46EF-ADC9-51E7749FA503 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 When i was looking the MSD draft is looking at =E2=80=9CHow = Many labels can device (node/link) impose=E2=80=9D.
(look = at introduction in section 1 as it is explicitly written in the = text)

The RLD = draft is about =E2=80=9CHow many labels a device (node/link) can = read=E2=80=9D

Even for the IGPs there is are different documents in either = OSPF or ISIS WG:
OSPF MSD: https://tools.ietf.org/html/draft-ietf-ospf-segment-routing-msd= -00
OSPF ELC/RLD: https://tools.ietf.org/html/draft-ietf-ospf-mpls-elc-04

ISIS MSD: https://tools.ietf.org/html/draft-ietf-isis-segment-routing-msd= -02
ISIS ELC/RLD: https://tools.ietf.org/html/draft-ietf-isis-mpls-elc-02

BGP MSD: https://tools.ietf.org/html/draft-tantsura-bgp-ls-segment-routi= ng-msd-02
BGP ELC/RLD: Was MIA =E2=80=A6 so now = there is https://trac.tools.ietf.org/html/draft-vandevelde-idr-bgp-ls-se= gment-routing-rld-01

Hence i assumed that there is sense for two drafts in IDR to = be in sync with the IGP capabilities =E2=80=A6 one to make BGP-LS in = alignment with the IGPs for MSD and one to make BGP-LS in alignment with = ELC

@Robert, I = do believe those data-points are of interrest to a network SDN = controller. I am not convinced they all belong in the same = document.
I think that on shorter term there is = need that the IGP LSDB can be exported to BGP-LS because right now that = is not possible for ISIS-ELC or OSPF-ELC. 
My = understanding is it is potentially worth having a draft on signalling = new functionality beyond the capability to signal it in the IGPs=E2=80=A6 = It is an important deviation from anything that was done before with = BGP-LS because main purpose has been to allow the export of IGP LSDB = into BGP-LS

G/






On 4 Mar 2017, at 09:54, Robert Raszuk <robert@raszuk.net> = wrote:

Jeff,

I am talking about max = supported depth.

If this is already = addressed elsewhere (which I doubt) I am not sure why this draft would = be needed at all then.

But if it has value let's = make it complete.

Best,
R.

On Mar 4, 2017 09:41, "Jeff Tantsura" <jefftant.ietf@gmail.com> wrote:
Robert,

That's done in MSD drafts.
In the recently published isis = draft we have also introduced MSD type flag that would be used to signal = different types of SID's: recirculated labels, EL's, etc

Cheers,
Jeff

On Fri, Mar 3, 2017 at 22:35 = Robert Raszuk <robert@raszuk.net> wrote:
Hey = Gunter,

Good = proposal however why do you only think about labels ?

Seriously= if this is to move fwd let's add ability to signal also following = elements:

* = ability to punt SR-MPLS to local CPU (slow path) when not handled in = hardware (per node basis)

* add = signalling for number of SRv6 SRHs supported per node/per LC

* add = signalling for depth per SRH and total of SIDs supported per node/per = LC

* = signal ability to punt to slow path or not for longer then support SRH = stack or number of SIDs in each SRH structure.

Cheers,Robert.


On Fri, Mar 3, 2017 at 3:55 PM, Van De = Velde, Gunter (Nokia - BE) <gunter.van_de_velde@nokia.com> wrote:
Heads-up=E2=80=A6 = Happy to learn feedback and comments.

This draft is short and defines the attribute to use for BGP-LS to = expose a
node RLD "Readable Label Depth" to a centralised controller = (PCE/SDN).

G/

On 03/03/2017, 14:21, "internet-drafts@ietf.org" <internet-drafts@ietf.org> wrote:


    A new version of I-D, draft-vandevelde-idr-bgp-ls-segment-routing-rld-01.txt
    has been successfully submitted by Gunter Van de Velde and = posted to the
    IETF repository.

    Name:              =  draft-vandevelde-idr-bgp-ls-segment-routing-rld
    Revision:   01
    Title:              = Signalling RLD using BGP-LS
    Document date:      2017-03-03
    Group:              = Individual Submission
    Pages:              = 5
    URL:            https://www.ietf.org/internet-drafts/draft-vandevelde-idr-bgp-ls-segment-routing-rld-01.txt
    Status:         https://datatracker.ietf.org/doc/draft-vandevelde-idr-bgp-ls-segment-routing-rld/
    Htmlized:       https://tools.ietf.org/html/draft-vandevelde-idr-bgp-ls-segment-routing-rld-01
    Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-vandevelde-idr-bgp-ls-segment-routing-rld-01

    Abstract:
       This document defines the attribute to use = for BGP-LS to expose a
       node RLD "Readable Label Depth" to a = centralised controller (PCE/
       SDN).





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

    The IETF Secretariat



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

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

= --Apple-Mail=_FDDA7015-D85E-46EF-ADC9-51E7749FA503-- From nobody Sat Mar 4 06:01:07 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5608A1294C1 for ; Sat, 4 Mar 2017 06:01:05 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aHdVmbbhdYpN for ; Sat, 4 Mar 2017 06:01:02 -0800 (PST) Received: from cmccmta1.chinamobile.com (cmccmta1.chinamobile.com [221.176.66.79]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3651293DF for ; Sat, 4 Mar 2017 06:01:00 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.121.19]) by rmmx-syy-dmz-app03-12003 (RichMail) with SMTP id 2ee358bac895f56-f7585; Sat, 04 Mar 2017 22:00:53 +0800 (CST) X-RM-TRANSID: 2ee358bac895f56-f7585 X-RM-SPAM-FLAG: 00000000 Received: from cmcc-PC (unknown[223.72.68.134]) by rmsmtp-syy-appsvr10-12010 (RichMail) with SMTP id 2eea58bac893143-4c296; Sat, 04 Mar 2017 22:00:53 +0800 (CST) X-RM-TRANSID: 2eea58bac893143-4c296 Date: Sat, 4 Mar 2017 22:01:20 +0800 From: "lizhenqiang@chinamobile.com" To: "Christoph Loibl" References: <148784903318.20350.3977002902067988959.idtracker@ietfa.amsl.com>, <2017030317434995427747@chinamobile.com>, X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 7, 164[cn] Mime-Version: 1.0 Message-ID: <2017030422011941402723@chinamobile.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart783784630356_=----" Archived-At: Cc: idr Subject: Re: [Idr] I-D Action: draft-ietf-idr-rfc5575bis-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Mar 2017 14:01:05 -0000 This is a multi-part message in MIME format. ------=_001_NextPart783784630356_=---- Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 SGksDQoNClNpbmNlIHRoZSBzdWIgc2VjdGlvbnMgb2Ygc2VjdGlvbiA3IGluIHRoaXMgZHJhZnQg YXJlIG9yZ2FuaXNlZCBhY2NvcmRpbmcgdG8gdGhlIHN1YiB0eXBlIG9mIHRoZSBleHRlbmRlZCBj b21tdW5pdHksIEkgdGhpbmsgdGhlIGZvbGxvd2luZyB0YWJsZSBmb3JtYXQgZm9yIHRhYmxlIDIg aXMgYmV0dGVyIGFuZCBlYXNpZXIgdG8gcmVhZC4gTWF5YmUgaXQgY2FuIGJlIGZ1cnRoZXIgaW1w cm92ZWQuIENyb3NzIHJlZmVyZW5jZXMgc2hvd24gaW4gdGhlIHRhYmxlIGFyZSBhbHNvIGFjY2Vw dGFibGUuIFlvdSBjYW4gYWxzbyBjb25zaWRlciBjaGFuZ2luZyB0aGUgdGl0bGUgb2Ygc2VjdGlv biA3LjQgZnJvbSBJUCByZWRpcmVjdCB0byBWUkYgcmVkaXJlY3QsIGJlY2F1c2UgdGhlIHRyYWZm aWMgaXMgbm90IHJlZGlyZWN0ZWQgdG8gYW4gSVAgYWRkcmVzcyBidXQgYSBWUkYuIFJlZGlyZWN0 IHRvIElQIGlzIGJlaW5nIGRpc2N1c3NlZCBpbiBhIHNlcGVyYXRlIGRyYWZ0Lg0KDQogICArLS0t LS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLSsKICAgfCB0eXBlICAgfCBleHRlbmRlZCBjb21tdW5pdHkgICB8IGVuY29kaW5nICAg ICAgICAgICAgICAgICAgICAgICAgICB8CiAgICstLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0t LS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwogICB8IDB4ODAwNiB8IHRy YWZmaWMtcmF0ZS1ieXRlcyAgIHwgMi1ieXRlIEFTTiwgNC1ieXRlIGZsb2F0ICAgICAgICAgIHwK ICAgfCAweDgwMDcgfCB0cmFmZmljLWFjdGlvbiAgICAgICB8IGJpdG1hc2sgICAgICAgICAgICAg ICAgICAgICAgICAgICB8CiAgIHwgMHg4MDA4IHwgVlJGLXJlZGlyZWN0ICAgICAgICAgfCAyLW9j dGV0IEFTLCA0LW9jdGV0IHZhbHVlICAgICAgICAgfAogICB8IDB4ODEwOCB8IFZSRi1yZWRpcmVj dCAgICAgICAgIHwgNC1vY3RldCBJUHY0IGFkZHJlcywgMi1vY3RldCAgICAgIHwKICAgfCAgICAg ICAgfCAgICAgICAgICAgICAgICAgICAgICB8IHZhbHVlICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB8CiAgIHwgMHg4MjA4IHwgVlJGLXJlZGlyZWN0ICAgICAgICAgfCA0LW9jdGV0IEFTLCAy LW9jdGV0IHZhbHVlICAgICAgICAgfAogICB8IDB4ODAwOSB8IHRyYWZmaWMtbWFya2luZyAgICAg IHwgRFNDUCB2YWx1ZSAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgfCBUQkQgICAgfCB0cmFm ZmljLXJhdGUtcGFja2V0cyB8IDItYnl0ZSBBU04sIDQtYnl0ZSBmbG9hdCAgICAgICAgICB8CiAg ICstLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tKw0KDQpCZXN0IFJlZ2FyZHMsDQoNCg0KbGl6aGVucWlhbmdAY2hpbmFtb2Jp bGUuY29tDQogDQpGcm9tOiBDaHJpc3RvcGggTG9pYmwNCkRhdGU6IDIwMTctMDMtMDMgMTg6MjMN ClRvOiBsaXpoZW5xaWFuZ0BjaGluYW1vYmlsZS5jb20NCkNDOiBpZHINClN1YmplY3Q6IFJlOiBb SWRyXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWlkci1yZmM1NTc1YmlzLTAwLnR4dA0KSGksIA0K DQpUaGVyZSBhcmUgNSBiYXNpYyBhY3Rpb25zIChleHRlbmRlZCBjb21tdW5pdHkgc3ViLXR5cGUg Niw3LDgsOSxUQkQgPSB0cmFmZmljLXJhdGUtYnl0ZXMsIHRyYWZmaWMtYWN0aW9uLCByZWRpcmVj dCwgdHJhZmZpYy1tYXJraW5nLCB0cmFmZmljLXJhdGUtcGFja2V0cykuIEhvd2V2ZXIgZm9yIHRo ZSByZWRpcmVjdCBhY3Rpb24gdGhlcmUgZXhpc3QgMyBkaWZmZXJlbnQgcm91dGUtdGFyZ2V0IGVu Y29kaW5nIGZvcm1hdHMgKGV4dGVuZGVkIGNvbW11bml0eSBzdWItdHlwZSAweDA4ICsgdHlwZSAw eDgwLCAweDgxIGFuZCAweDgyKToNCg0KfCAweDgwMDggfCByZWRpcmVjdCBBUy0yYnl0ZSAgICB8 IDItb2N0ZXQgQVMsIDQtb2N0ZXQgdmFsdWUgICAgICAgICB8CnwgMHg4MTA4IHwgcmVkaXJlY3Qg SVB2NCAgICAgICAgfCA0LW9jdGV0IElQdjQgYWRkcmVzLCAyLW9jdGV0ICAgICAgfAp8ICAgICAg ICB8ICAgICAgICAgICAgICAgICAgICAgIHwgdmFsdWUgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwKfCAweDgyMDggfCByZWRpcmVjdCBBUy00Ynl0ZSAgICB8IDQtb2N0ZXQgQVMsIDItb2N0 ZXQgdmFsdWUgICAgICAgICB8DQoNClRoZXNlIHRocmVlIGVuY29kaW5nIGZvcm1hdHMgYXJlIGV4 cGxhaW5lZCBpbiBvdXIgZHJhZnQgc2VjdGlvbiA3LjQgKElQIFJlZGlyZWN0IHN1Yi10eXBlIDB4 MDgpIGFuZCBiYXNpY2FsbHkgdXNlIHRoZSBzYW1lIGVuY29kaW5nIGFzIGRlc2NyaWJlZCBpbiBS RkMgNDM2MCBhbmQgUkZDIDU2NjguIA0KDQpEbyB5b3UgdGhpbmsgdGhhdCBhZGRpdGlvbmFsIGNs YXJpZmljYXRpb24gb3IgYSBjcm9zcy1yZWZlcmVuY2UgZnJvbSB0aGUgdGFibGUgdG8gdGhpcyBz ZWNpb24gaXMgbmVlZGVkIGZvciBlYWNoIGFjdGlvbj8NCg0KQ2hlZXJzLCANCg0KQ2hyaXN0b3Bo DQoNCg0KT24gMyBNYXIgMjAxNywgYXQgMTA6NDMsIGxpemhlbnFpYW5nQGNoaW5hbW9iaWxlLmNv bSB3cm90ZToNCg0KSGksDQoNCkkgYW0gcmVhZGluZyB0aGlzIGRyYWZ0LiBJIG5vdGljZWQgdGhh dCB0aGVyZSBhcmUgNyBhY3Rpb25zIGxpc3RlZCBpbiB0YWJsZSAyLiBCdXQgT25seSA1IG9mIHRo ZW0gYXJlIGlsbHVzdHJhdGVkIGluIHNlY3Rpb24gNy4gQWN0aW9ucyBmb3IgdHlwZSAweDgxMDgg YW5kIDB4ODIwOCBhcmUgbm90IGV4cGxhaW5lZCBpbiB0aGlzIHNlY3Rpb24uIE5vIHJlZmVyZW5j ZXMgYXJlIGdpdmVuIGhlcmUuIE1heSBJIGtub3cgdGhlIHJlYXNvbj8gVGhhbmtzLg0KDQpCZXN0 IFJlZ2FyZHMsDQoNCg0KbGl6aGVucWlhbmdAY2hpbmFtb2JpbGUuY29tDQogDQpGcm9tOiBpbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmcNCkRhdGU6IDIwMTctMDItMjMgMTk6MjMNClRvOiBpLWQtYW5u b3VuY2VAaWV0Zi5vcmcNCkNDOiBpZHJAaWV0Zi5vcmcNClN1YmplY3Q6IFtJZHJdIEktRCBBY3Rp b246IGRyYWZ0LWlldGYtaWRyLXJmYzU1NzViaXMtMDAudHh0DQogDQpBIE5ldyBJbnRlcm5ldC1E cmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0 b3JpZXMuDQpUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBJbnRlci1Eb21haW4gUm91 dGluZyBvZiB0aGUgSUVURi4NCiANCiAgICAgICAgVGl0bGUgICAgICAgICAgIDogRGlzc2VtaW5h dGlvbiBvZiBGbG93IFNwZWNpZmljYXRpb24gUnVsZXMNCiAgICAgICAgQXV0aG9ycyAgICAgICAg IDogU3VzYW4gSGFyZXMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgUm9iZXJ0IFJhc3p1aw0K ICAgICAgICAgICAgICAgICAgICAgICAgICBEYW5ueSBNY1BoZXJzb24NCiAgICAgICAgICAgICAg ICAgICAgICAgICAgQ2hyaXN0b3BoIExvaWJsDQogICAgICAgICAgICAgICAgICAgICAgICAgIE1h cnRpbiBCYWNoZXINCkZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtaWRyLXJmYzU1NzViaXMt MDAudHh0DQpQYWdlcyAgICAgICAgICAgOiAzMA0KRGF0ZSAgICAgICAgICAgIDogMjAxNy0wMi0y Mg0KIA0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IHVwZGF0ZXMgUkZDNTU3NSB3aGljaCBk ZWZpbmVzIGEgQm9yZGVyIEdhdGV3YXkgUHJvdG9jb2wNCiAgIE5ldHdvcmsgTGF5ZXIgUmVhY2hh YmlsaXR5IEluZm9ybWF0aW9uIChCR1AgTkxSSSkgZW5jb2RpbmcgZm9ybWF0DQogICB0aGF0IGNh biBiZSB1c2VkIHRvIGRpc3RyaWJ1dGUgdHJhZmZpYyBmbG93IHNwZWNpZmljYXRpb25zLiAgVGhp cw0KICAgYWxsb3dzIHRoZSByb3V0aW5nIHN5c3RlbSB0byBwcm9wYWdhdGUgaW5mb3JtYXRpb24g cmVnYXJkaW5nIG1vcmUNCiAgIHNwZWNpZmljIGNvbXBvbmVudHMgb2YgdGhlIHRyYWZmaWMgYWdn cmVnYXRlIGRlZmluZWQgYnkgYW4gSVANCiAgIGRlc3RpbmF0aW9uIHByZWZpeC4gIFRoaXMgZHJh ZnQgc3BlY2lmaWVzIElQdjQgdHJhZmZpYyBmbG93DQogICBzcGVjaWZpY2F0aW9ucyB2aWEgYSBC R1AgTkxSSSB3aGljaCBjYXJyaWVzIHRyYWZmaWMgZmxvdw0KICAgc3BlY2lmaWNhdGlvbiBmaWx0 ZXIsIGFuZCBhbiBFeHRlbmRlZCBjb21tdW5pdHkgdmFsdWUgd2hpY2ggZW5jb2Rlcw0KICAgYWN0 aW9ucyBhIHJvdXRpbmcgc3lzdGVtIGNhbiB0YWtlIGlmIHRoZSBwYWNrZXQgbWF0Y2hlcyB0aGUg dHJhZmZpYw0KICAgZmxvdyBmaWx0ZXJzLiAgVGhlIGZsb3cgZmlsdGVycyBhbmQgdGhlIGFjdGlv bnMgYXJlIHByb2Nlc3NlZCBpbiBhDQogICBmaXhlZCBvcmRlci4gIE90aGVyIGRyYWZ0cyBzcGVj aWZ5IElQdjYsIE1QTFMgYWRkcmVzc2VzLCBMMlZQTg0KICAgYWRkcmVzc2VzLCBhbmQgTlYwMyBl bmNhcHN1bGF0aW9uIG9mIElQIGFkZHJlc3Nlcy4NCiANCiAgIFRoaXMgZG9jdW1lbnQgdXBkYXRl cyBSRkM1NTc1IHRvIGNvcnJlY3QgdW5jbGVhciBzcGVjaWZpY2F0aW9ucyBpbg0KICAgdGhlIGZs b3cgZmlsdGVycyBhbmQgdG8gcHJvdmlkZSBydWxlcyBmb3IgYWN0aW9ucyB3aGljaCBpbnRlcmZl cmUNCiAgIChlLmcuIHJlZGlyZWN0aW9uIG9mIHRyYWZmaWMgYW5kIGZsb3cgZmlsdGVyaW5nKS4N CiANCiAgIEFwcGxpY2F0aW9ucyB3aGljaCB1c2UgdGhlIGJncCBmbG93IHNwZWNpZmljYXRpb24g YXJlOiAxKSBhcHBsaWNhdGlvbg0KICAgd2hpY2ggYXV0b21hdGUgb2YgaW50ZXItZG9tYWluIGNv b3JkaW5hdGlvbiBvZiB0cmFmZmljIGZpbHRlcmluZywNCiAgIHN1Y2ggYXMgd2hhdCBpcyByZXF1 aXJlZCBpbiBvcmRlciB0byBtaXRpZ2F0ZSAoZGlzdHJpYnV0ZWQpIGRlbmlhbC0NCiAgIG9mLXNl cnZpY2UgYXR0YWNrczsgMikgYXBwbGljYXRpb24gd2hpY2ggY29udHJvbCB0cmFmZmljIGZpbHRl cmluZyBpbg0KICAgdGhlIGNvbnRleHQgb2YgYSBCR1AvTVBMUyBWUE4gc2VydmljZSwgYW5kIDMp IGFwcGxpY2F0aW9ucyB3aXRoDQogICBjZW50cmFsaXplZCBjb250cm9sIG9mIHRyYWZmaWMgaW4g YSBTRE4gb3IgTkZWIGNvbnRleHQuICBTb21lIG9mDQogICBkZXBsb3ltZW50cyBvZiB0aGVzZSB0 aHJlZSBhcHBsaWNhdGlvbnMgY2FuIGJlIGhhbmRsZWQgYnkgdGhlIHN0cmljdA0KICAgb3JkZXJp bmcgb2YgdGhlIEJHUCBOTFJJIHRyYWZmaWMgZmxvdyBmaWx0ZXJzLCBhbmQgdGhlIHN0cmljdCBh Y3Rpb25zDQogICBlbmNvZGVkIGluIHRoZSBFeHRlbmRlZCBDb21tdW5pdHkgRmxvdyBTcGVjaWZp Y2F0aW9uIGFjdGlvbnMuDQogDQogDQpUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBm b3IgdGhpcyBkcmFmdCBpczoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWlldGYtaWRyLXJmYzU1NzViaXMvDQogDQpUaGVyZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9u IGF2YWlsYWJsZSBhdDoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWlk ci1yZmM1NTc1YmlzLTAwDQogDQogDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291 cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQp1bnRpbCB0aGUgaHRt bGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0K IA0KSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0 Og0KZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCiANCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJZHIgbWFpbGluZyBsaXN0DQpJZHJA aWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRyDQogDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSWRyIG1haWxp bmcgbGlzdA0KSWRyQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2lkcg0KDQotLSANCkNocmlzdG9waCBMb2libA0KY0B0aXguYXQgfCBDTDgtUklQRSB8IFBH UC1LZXktSUQ6IDB4NEIyQzAwNTUgfCBodHRwOi8vd3d3Lm5leHRsYXllci5hdA0KDQo= ------=_001_NextPart783784630356_=---- Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =0A
Hi,

Since the sub sections of section 7 in this draft are organised accordin= g to the sub type of the extended community, I think the following table f= ormat for table 2 is better and easier to read. Maybe it can be further im= proved. Cross references shown in the table are also acceptable. You can a= lso consider changing the title of section 7.4 from IP redirect to VRF red= irect, because the traffic is not redirected to an IP address but a VRF. R= edirect to IP is being discussed in a seperate draft.

= 
   +--------+----------------------+--------------=
---------------------+=0A   | type   | extended community   | encoding    =
                      |=0A   +--------+----------------------+------------=
-----------------------+=0A   | 0x8006 | traffic-rate-bytes   | 2-byte ASN=
, 4-byte float          |=0A   | 0x8007 | traffic-action       | bitmask  =
                         |=0A   | 0x8008 | VRF-redirect         | 2-octet =
AS, 4-octet value         |=0A   | 0x8108 | VRF-redirect         | 4-octet=
 IPv4 addres, 2-octet      |=0A   |        |                      | value =
                            |=0A   | 0x8208 | VRF-redirect         | 4-oct=
et AS, 2-octet value         |=0A   | 0x8009 | traffic-marking      | DSCP=
 value                        |=0A   | TBD    | traffic-rate-packets | 2-b=
yte ASN, 4-byte float          |=0A   +--------+----------------------+---=
--------------------------------+

Best R=
egards,

=0A
lizhenqiang@chinamobile.com
=0A=
 
Date: 20= 17-03-03 18:23
CC:&nb= sp;idr
Subject: = Re: [Idr] I-D Action: draft-ietf-idr-rfc5575bis-00.txt
=0AHi,=0A

=0A
=0A
There are 5 basic actions (extended= community sub-type 6,7,8,9,TBD =3D traffic-rate-bytes, traffic-action, re= direct, traffic-marking, traffic-rate-packets). However for the redirect a= ction there exist 3 different route-target encoding formats (extended=0A c= ommunity sub-type 0x08 + type 0x80, 0x81 and 0x82):
=0A

=0A
=0A
=0A
| 0x800=
8 | redirect AS-2byte    | 2-octet AS, 4-octet value         |=0A| 0x8108 =
| redirect IPv4        | 4-octet IPv4 addres, 2-octet      |=0A|        | =
                     | value                             |=0A| 0x8208 | re=
direct AS-4byte    | 4-octet AS, 2-octet value         |
=0A

=0A
=0A
These three encoding for= mats are explained in our draft section 7.4 (IP Redirect sub-type 0x08) an= d basically use the same encoding as described in RFC 4360 and RFC 5668.&n= bsp;
=0A

=0A
=0A
Do= you think that additional clarification or a cross-reference from the tab= le to this secion is needed for each action?
=0A

=0A
=0A
Cheers, 
=0A

=0A
=0A
Christoph
=0A

=0A
=0A

=0A
= =0A
=0A
=0A
On 3 Mar 2017, at 10:43, =0Alizhenqiang@chinamobile.com wrote:=0A
=0A
=0A
=0AHi,
=0A
=0A
=0A
=0A
=0AI am reading= this draft. I noticed that there are 7 actions listed in table 2. But Onl= y 5 of them are illustrated in section 7. Actions for type 0x8108 and 0x82= 08 are not explained in this section. No references are given here. May I = know the reason? Thanks.
=0A
=0A
= =0A
=0A
=0ABest Regards,
=0A
=0A=0A
=0A
 
=0A
=0A
=0A
From: internet-drafts@ietf.org
=0A
Date: 2017-02-23 19= :23
=0A
To: i-d-announce@ietf.org
=0A=0A
Subject:&= nbsp;[Idr] I-D Action: draft-ietf-idr-rfc5575bis-00.txt
=0A
=0A<= /div>=0A
=0A
 
=0A
= A New Internet-Draft is available from the on-line Internet-Drafts directo= ries.
=0A
This draft is a work item of the Inter-Domai= n Routing of the IETF.
=0A
 
=0A
        Title   &n= bsp;       : Dissemination of Flow Specifica= tion Rules
=0A
      &nb= sp; Authors         : Susan Hares<= /div>=0A
        &n= bsp;           &nbs= p;     Robert Raszuk
=0A
 &nb= sp;            = ;            Danny = McPherson
=0A
      &nbs= p;            =        Christoph Loibl
=0A
            = ;            &= nbsp; Martin Bacher
=0A
Filename   &nbs= p;    : draft-ietf-idr-rfc5575bis-00.txt
=0A
Pages           : = 30
=0A
Date       &= nbsp;    : 2017-02-22
=0A
 
= =0A
Abstract:
=0A
   This doc= ument updates RFC5575 which defines a Border Gateway Protocol
=0A   Network Layer Reachability Information (BGP NLRI)= encoding format
=0A
   that can be used to = distribute traffic flow specifications.  This
=0A
   allows the routing system to propagate information regarding= more
=0A
   specific components of the traf= fic aggregate defined by an IP
=0A
   destin= ation prefix.  This draft specifies IPv4 traffic flow
=0A
   specifications via a BGP NLRI which carries traffic = flow
=0A
   specification filter, and an Ext= ended community value which encodes
=0A
   a= ctions a routing system can take if the packet matches the traffic
= =0A
   flow filters.  The flow filters and t= he actions are processed in a
=0A
   fixed o= rder.  Other drafts specify IPv6, MPLS addresses, L2VPN
=0A
   addresses, and NV03 encapsulation of IP addresses.=
=0A
 
=0A
   This = document updates RFC5575 to correct unclear specifications in
=0A   the flow filters and to provide rules for actions= which interfere
=0A
   (e.g. redirection of= traffic and flow filtering).
=0A
 
=0A
   Applications which use the bgp flow specification = are: 1) application
=0A
   which automate of= inter-domain coordination of traffic filtering,
=0A
&= nbsp;  such as what is required in order to mitigate (distributed) de= nial-
=0A
   of-service attacks; 2) applicat= ion which control traffic filtering in
=0A
  = ; the context of a BGP/MPLS VPN service, and 3) applications with
=0A=
   centralized control of traffic in a SDN or NF= V context.  Some of
=0A
   deployments = of these three applications can be handled by the strict
=0A
   ordering of the BGP NLRI traffic flow filters, and the= strict actions
=0A
   encoded in the Extend= ed Community Flow Specification actions.
=0A
 =0A
 
=0A
The IETF datatracker = status page for this draft is:
=0A
https://da= tatracker.ietf.org/doc/draft-ietf-idr-rfc5575bis/
=0A
 
=0A
There's also a htmlized version avail= able at:
=0A
https://tools.ietf.org/html/draft-i= etf-idr-rfc5575bis-00
=0A
 
=0A
 
=0A
Please note that it may take a coupl= e of minutes from the time of submission
=0A
until the= htmlized version and diff are available at tools.ie= tf.org.
=0A
 
=0A
Interne= t-Drafts are also available by anonymous FTP at:
=0A
<= a href=3D"ftp://ftp.ietf.org/internet-drafts/" class=3D"">ftp://ftp.ietf.o= rg/internet-drafts/
=0A
 
=0A
_______________________________________________
=0A
Idr mailing list
=0A
Idr@ietf.org
=0A
https://www.ietf.org/mailm= an/listinfo/idr
=0A
 
=0A
=0A=0A_______________________________________________
=0AIdr= =0A mailing list
=0AIdr@ietf.org=0Ahttps://www.ietf.org/= mailman/listinfo/idr
=0A
=0A
=0A
= =0A
=0A
-- 
=0AChristoph = Loibl
=0Ac@tix.at=  | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at
=0A
=0A
=0A
=0A
=0A ------=_001_NextPart783784630356_=------ From nobody Sat Mar 4 06:24:11 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B63412950E for ; Sat, 4 Mar 2017 06:24:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.369 X-Spam-Level: X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.229, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yUy4byGvSNjE for ; Sat, 4 Mar 2017 06:24:08 -0800 (PST) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::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 987A11294D1 for ; Sat, 4 Mar 2017 06:24:08 -0800 (PST) Received: by mail-qk0-x22f.google.com with SMTP id 1so97794101qkl.3 for ; Sat, 04 Mar 2017 06:24:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=1TSsMy6aHP2IIOSac54XyyKBYtkiPyVcyZ3NoTCjC0k=; b=ncrztgI9cm8J2KY7UJVDLoQTfA2pH7sLvds576eGm7yuIDklXdyuVmB1LOLWErCltj dC/AE2JXBYZTAr30ftWLaznBcEmh4pLL/DQ0SYAW0RRZJvJm2Sxm0TXxbLrLhMbWqBhi jFUvwKcK+jv3DmfHVwlXdHtOIGfONEgyVVDoE0OxbGFxzT1qjk/HG/KiOHcnfH/Jz8rw IDZj01pTbBzZ6CA7VYng298L98NPln0v8G3/3X2Yagz1RjHJeZ9fTBK5o4GQNQCFftbR WLDlqGaIQMC+4FaMntZNlIBPH25l2YIMU+Gh6OgKyHamuTvrUQ0nEKjekUW6EjN10yI5 32Nw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=1TSsMy6aHP2IIOSac54XyyKBYtkiPyVcyZ3NoTCjC0k=; b=O4RKfjnT97C6RY3OLy4fpFhiy59z5DioF2SqJanDNyTpqehv0YCbqXSV09Au9Mpwz2 D+GmU23+V0LWd2YpNlOBer0GOgb1oTRm8qPh5/T81qvGH8D0sU/z0DDW4cMV7iFW96RP uMCd1ejFNhi06LAOdghWybDthlpoouadwEum886odx0A4CUMOVHyTEfdyrZbYJRNc53d T/VWr/WHKxLgAeHlYL5w2n2ncET0+QsLF96TUG51fblj2QgOJjNVmQMffTUiIzxeNJZn mqw2OC4FBM687t2rYfIEZQ67DZTrrjiQEX/wdBY/UiHkeU3TwKU6TFRjxNcRwsk4v/1H 0ZOg== X-Gm-Message-State: AMke39ll3ehIMHxmR4PNWMe4Q6gzBMB1kbJvirJDJPU+XLAgI1FpzY0yamTeI0hNE3BQiQc4yCNqOxwj5raTvg== X-Received: by 10.200.2.150 with SMTP id p22mr8260523qtg.197.1488637447748; Sat, 04 Mar 2017 06:24:07 -0800 (PST) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.140.42.181 with HTTP; Sat, 4 Mar 2017 06:24:06 -0800 (PST) Received: by 10.140.42.181 with HTTP; Sat, 4 Mar 2017 06:24:06 -0800 (PST) In-Reply-To: References: <148854728632.10105.590253116263033290.idtracker@ietfa.amsl.com> <4BF12F22-F605-406F-9CD8-ACE350B981D0@alcatel-lucent.com> From: Robert Raszuk Date: Sat, 4 Mar 2017 15:24:06 +0100 X-Google-Sender-Auth: sqmjRHG7p9M5onDIRSTw5uUQq2g Message-ID: To: Jeff Tantsura Content-Type: multipart/alternative; boundary=f4030435c23445f96b0549e86a6c Archived-At: Cc: idr wg , "Van De Velde, Gunter \(Nokia - BE\)" Subject: Re: [Idr] FW: New Version Notification for draft-vandevelde-idr-bgp-ls-segment-routing-rld-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Mar 2017 14:24:10 -0000 --f4030435c23445f96b0549e86a6c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Jeff, MSD drafts (yours invluded) talks about labels while MSD as such seems to be defined as maximum SID depth. In SRv6 SID is *NOT* a label. So why not to define MSD properly across all SR scenarios? Are we going to have now new zoo of drafts now defining MSD for SRv6 vs current docs just defining MSD for SR-MPLS ? Cheers, R. On Mar 4, 2017 9:41 AM, "Jeff Tantsura" wrote: > Robert, > > That's done in MSD drafts. > In the recently published isis draft we have also introduced MSD type fla= g > that would be used to signal different types of SID's: recirculated label= s, > EL's, etc > > Cheers, > Jeff > > On Fri, Mar 3, 2017 at 22:35 Robert Raszuk wrote: > > Hey Gunter, > > Good proposal however why do you only think about labels ? > > Seriously if this is to move fwd let's add ability to signal also > following elements: > > * ability to punt SR-MPLS to local CPU (slow path) when not handled in > hardware (per node basis) > > * add signalling for number of SRv6 SRHs supported per node/per LC > > * add signalling for depth per SRH and total of SIDs supported per > node/per LC > > * signal ability to punt to slow path or not for longer then support SRH > stack or number of SIDs in each SRH structure. > > Cheers, > Robert. > > > On Fri, Mar 3, 2017 at 3:55 PM, Van De Velde, Gunter (Nokia - BE) < > gunter.van_de_velde@nokia.com> wrote: > > Heads-up=E2=80=A6 Happy to learn feedback and comments. > > This draft is short and defines the attribute to use for BGP-LS to expose= a > node RLD "Readable Label Depth" to a centralised controller (PCE/SDN). > > G/ > > On 03/03/2017, 14:21, "internet-drafts@ietf.org" > wrote: > > > A new version of I-D, draft-vandevelde-idr-bgp-ls- > segment-routing-rld-01.txt > has been successfully submitted by Gunter Van de Velde and posted to > the > IETF repository. > > Name: draft-vandevelde-idr-bgp-ls-segment-routing-rld > Revision: 01 > Title: Signalling RLD using BGP-LS > Document date: 2017-03-03 > Group: Individual Submission > Pages: 5 > URL: https://www.ietf.org/internet- > drafts/draft-vandevelde-idr-bgp-ls-segment-routing-rld-01.txt > Status: https://datatracker.ietf.org/ > doc/draft-vandevelde-idr-bgp-ls-segment-routing-rld/ > Htmlized: https://tools.ietf.org/html/ > draft-vandevelde-idr-bgp-ls-segment-routing-rld-01 > Diff: https://www.ietf.org/rfcdiff? > url2=3Ddraft-vandevelde-idr-bgp-ls-segment-routing-rld-01 > > Abstract: > This document defines the attribute to use for BGP-LS to expose a > node RLD "Readable Label Depth" to a centralised controller (PCE/ > SDN). > > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > --f4030435c23445f96b0549e86a6c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Jeff,

MSD dr= afts (yours invluded) talks about labels while MSD as such seems to be defi= ned as maximum SID depth.

In SRv6 SID is *NOT* a label. So why not to define MSD properly across al= l SR scenarios?

Are we g= oing to have now new zoo of drafts now defining MSD for SRv6 vs current doc= s just defining MSD for SR-MPLS ?

Cheers,
R.



On Mar 4, 2017 9:41 AM, "Jeff Tantsura" <jefftant.ietf@gmail.com> wr= ote:
Robert,
That's done in MSD drafts.
In the recently published isis draft we have also introduced MS= D type flag that would be used to signal different types of SID's: reci= rculated labels, EL's, etc

Cheers,
= Jeff

On Fri, Mar 3, 2017 at 22:35 Robert Raszuk <robert@raszuk.net> wrote:
Hey Gunter,

Good proposal however why do you o= nly think about labels ?

Seriously if this is to move fwd let's a= dd ability to signal also following elements:

* ability to punt SR-MP= LS to local CPU (slow path) when not handled in hardware (per node basis)

* add signalling for number of SRv6 SRHs supported per node/per LC

* add signalling for depth per SRH and total of SIDs supported per node/= per LC

* signal ability to punt to slow path or not for longer then s= upport SRH stack or number of SIDs in each SRH structure.

Cheers,Robert.


On Fri, Mar 3, 2017 at 3:55 PM, Van De Velde, Gunte= r (Nokia - BE) <gunter.van_de_velde@nokia.com>= wrote:
Heads-up=E2=80=A6 Happy to learn fee= dback and comments.

This draft is short and defines the attribute to use for BGP-LS to expose a=
node RLD "Readable Label Depth" to a centralised controller (PCE/= SDN).

G/

On 03/03/2017, 14:21, "internet-drafts@iet= f.org" <internet-drafts@ietf.org> wrote:


=C2=A0 =C2=A0 A new version of I-D, draft-vandevelde-idr-bgp-ls-segmen= t-routing-rld-01.txt
=C2=A0 =C2=A0 has been successfully submitted by Gunter Van de Velde and po= sted to the
=C2=A0 =C2=A0 IETF repository.

=C2=A0 =C2=A0 Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0d= raft-vandevelde-idr-bgp-ls-segment-routing-rld
=C2=A0 =C2=A0 Revision:=C2=A0 =C2=A001
=C2=A0 =C2=A0 Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Signal= ling RLD using BGP-LS
=C2=A0 =C2=A0 Document date:=C2=A0 =C2=A0 =C2=A0 2017-03-03
=C2=A0 =C2=A0 Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Indivi= dual Submission
=C2=A0 =C2=A0 Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 5
=C2=A0 =C2=A0 URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-vandevelde= -idr-bgp-ls-segment-routing-rld-01.txt
=C2=A0 =C2=A0 Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-vandevelde-idr-bgp-ls-se= gment-routing-rld/
=C2=A0 =C2=A0 Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https:= //tools.ietf.org/html/draft-vandevelde-idr-bgp-ls-segment-routing= -rld-01
=C2=A0 =C2=A0 Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-vandevelde-idr-b= gp-ls-segment-routing-rld-01

=C2=A0 =C2=A0 Abstract:
=C2=A0 =C2=A0 =C2=A0 =C2=A0This document defines the attribute to use for B= GP-LS to expose a
=C2=A0 =C2=A0 =C2=A0 =C2=A0node RLD "Readable Label Depth" to a c= entralised controller (PCE/
=C2=A0 =C2=A0 =C2=A0 =C2=A0SDN).





=C2=A0 =C2=A0 Please note that it may take a couple of minutes from the tim= e of submission
=C2=A0 =C2=A0 until the htmlized version and diff are available at tools.ietf.org.

=C2=A0 =C2=A0 The IETF Secretariat



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

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.o= rg/mailman/listinfo/idr
--f4030435c23445f96b0549e86a6c-- From nobody Sat Mar 4 07:36:45 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 622921295D6; Sat, 4 Mar 2017 07:36:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z952LouxYACd; Sat, 4 Mar 2017 07:36:39 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 379591294EE; Sat, 4 Mar 2017 07:36:39 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.90.29; From: "Susan Hares" To: "'Ron Bonica'" , "'Shitanshu Shah'" , , , References: In-Reply-To: Date: Sat, 4 Mar 2017 10:31:46 -0500 Message-ID: <053401d294fc$6f739180$4e5ab480$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0535_01D294D2.869E4CD0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH+U8bIprcHIBv9vIIxWXYNekqkjQJ00uVDAja9hsWhB/SR8A== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Mar 2017 15:36:40 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0535_01D294D2.869E4CD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Shitanshu: Please address Ron's comment about widely deployed. I believe this was part of Alvaro's comments. Sue From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Ron Bonica Sent: Thursday, February 23, 2017 12:07 PM To: Shitanshu Shah; rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; idr@ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 Hello, The draft is internally consistent. But given what is left out of scope, I wonder if the new attributes will ever be widely deployed. Ron This document might benefit from discussion of operational issues. I assume that when a BGP listener learns a route with the SLA Exchange Attribute, it provisions class of service forwarding classes on interfaces. ##svshah, though this is one desired use of exchanging SLA content, the draft focuses on transporting SLA content from the SLA Producer to the SLA Consumer. Processing of the QoS attribute content, at the SLA Consumer, is outside the scope of this document. ##svshah, Let me know if you have a suggestion to make description clearer in Section 1 and 2 to highlight this. I also assume that a) it takes time to provision class of service forwarding classes and b) the number of forwarding classes that can be provisioned are finite. What does the BGP listener do when the number of forwarding classes requested exceeds its capacity to deliver? ##svshah, Since scope of the document is to transport SLA content from the SLA Producer to the SLA Consumer, the document considers error handling in the context of transporting data and thus any formating errors and semantics errors within that context. Any errors in the context of processing QoS attribute content at the SLA Consumer is outside the scope of the document. ------=_NextPart_000_0535_01D294D2.869E4CD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Shitanshu:

 

Please address Ron’s comment about widely deployed.  I = believe this was part of Alvaro’s comments. =

 

Sue

 

From:= = rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Ron = Bonica
Sent: Thursday, February 23, 2017 12:07 = PM
To: Shitanshu Shah; rtg-dir@ietf.org; = draft-ietf-idr-sla-exchange.all@ietf.org; = idr@ietf.org
Subject: Re: [RTG-DIR] RtgDir review: = draft-ietf-idr-sla-exchange-10

 

Hello,

 

The draft is internally consistent. But given what is left out of = scope, I wonder if the new attributes will ever be widely = deployed.

 

           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;       Ron

 

 


This document might benefit from discussion of operational issues. = I assume that when a BGP listener learns a route with the SLA Exchange = Attribute, it provisions class of service forwarding classes on = interfaces.

 

##svshah, though = this is one desired use of exchanging SLA content, the draft focuses on = transporting SLA content from the SLA Producer to the SLA Consumer. = Processing of the QoS attribute content, at the SLA Consumer, is outside = the scope of this document.

 =

##svshah, Let me = know if you have a suggestion to make description clearer in Section 1 = and 2 to highlight this.

 

 

I also assume that a) it takes time to provision class of service = forwarding classes and b) the number of forwarding classes that can be = provisioned are finite. What does the BGP listener do when the number of = forwarding classes requested exceeds its capacity to = deliver? 

 

##svshah, Since = scope of the document is to transport SLA content from the SLA Producer = to the SLA Consumer, the document considers error handling in the = context of transporting data and thus any formating errors and semantics = errors within that context. Any errors in the context of processing QoS = attribute content at the SLA Consumer is outside the scope of the = document.

 =

 

 

------=_NextPart_000_0535_01D294D2.869E4CD0-- From nobody Sat Mar 4 11:08:33 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B67AA129567 for ; Sat, 4 Mar 2017 11:08:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJk6CwXIhaMI for ; Sat, 4 Mar 2017 11:08:26 -0800 (PST) Received: from mail.hated.at (mail.hated.at [IPv6:2001:858:2:8::235]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B303A129563 for ; Sat, 4 Mar 2017 11:08:25 -0800 (PST) Received: from 80-110-123-147.cgn.dynamic.surfer.at ([80.110.123.147] helo=[192.168.66.245]) by mail.hated.at with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1ckErU-0004W7-ED; Sat, 04 Mar 2017 19:57:01 +0100 Content-Type: multipart/signed; boundary="Apple-Mail=_25AB4334-F4EE-47E5-BC68-84A5A09E704F"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Christoph Loibl X-Priority: 3 In-Reply-To: <2017030422011941402723@chinamobile.com> Date: Sat, 4 Mar 2017 20:08:17 +0100 Message-Id: <12F0808C-8AFD-4BD9-A7D6-E493F0833B2E@tix.at> References: <148784903318.20350.3977002902067988959.idtracker@ietfa.amsl.com> <2017030317434995427747@chinamobile.com> <2017030422011941402723@chinamobile.com> To: "lizhenqiang@chinamobile.com" X-Mailer: Apple Mail (2.3259) Archived-At: Cc: idr Subject: Re: [Idr] I-D Action: draft-ietf-idr-rfc5575bis-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Mar 2017 19:08:30 -0000 --Apple-Mail=_25AB4334-F4EE-47E5-BC68-84A5A09E704F Content-Type: multipart/alternative; boundary="Apple-Mail=_EF73AE10-9182-4050-8C75-DB35BDD54432" --Apple-Mail=_EF73AE10-9182-4050-8C75-DB35BDD54432 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Your comment makes sense to me. I collected a few other minor changes = over the last months (that I received as feedback) and added your = comment to this list. In about two weeks I will be ready to upload a new = version of our draft, after discussing that with the other authors. Thanks for your feedback! Cheers Christoph > On 4 Mar 2017, at 15:01, lizhenqiang@chinamobile.com wrote: >=20 > Hi, >=20 > Since the sub sections of section 7 in this draft are organised = according to the sub type of the extended community, I think the = following table format for table 2 is better and easier to read. Maybe = it can be further improved. Cross references shown in the table are also = acceptable. You can also consider changing the title of section 7.4 from = IP redirect to VRF redirect, because the traffic is not redirected to an = IP address but a VRF. Redirect to IP is being discussed in a seperate = draft. >=20 > = +--------+----------------------+-----------------------------------+ > | type | extended community | encoding = | > = +--------+----------------------+-----------------------------------+ > | 0x8006 | traffic-rate-bytes | 2-byte ASN, 4-byte float = | > | 0x8007 | traffic-action | bitmask = | > | 0x8008 | VRF-redirect | 2-octet AS, 4-octet value = | > | 0x8108 | VRF-redirect | 4-octet IPv4 addres, 2-octet = | > | | | value = | > | 0x8208 | VRF-redirect | 4-octet AS, 2-octet value = | > | 0x8009 | traffic-marking | DSCP value = | > | TBD | traffic-rate-packets | 2-byte ASN, 4-byte float = | > = +--------+----------------------+-----------------------------------+ >=20 > Best Regards, >=20 > lizhenqiang@chinamobile.com >=20 > From: Christoph Loibl > Date: 2017-03-03 18:23 > To: lizhenqiang@chinamobile.com > CC: idr > Subject: Re: [Idr] I-D Action: draft-ietf-idr-rfc5575bis-00.txt > Hi, >=20 > There are 5 basic actions (extended community sub-type 6,7,8,9,TBD =3D = traffic-rate-bytes, traffic-action, redirect, traffic-marking, = traffic-rate-packets). However for the redirect action there exist 3 = different route-target encoding formats (extended community sub-type = 0x08 + type 0x80, 0x81 and 0x82): >=20 > | 0x8008 | redirect AS-2byte | 2-octet AS, 4-octet value | > | 0x8108 | redirect IPv4 | 4-octet IPv4 addres, 2-octet | > | | | value | > | 0x8208 | redirect AS-4byte | 4-octet AS, 2-octet value | >=20 > These three encoding formats are explained in our draft section 7.4 = (IP Redirect sub-type 0x08) and basically use the same encoding as = described in RFC 4360 and RFC 5668. >=20 > Do you think that additional clarification or a cross-reference from = the table to this secion is needed for each action? >=20 > Cheers, >=20 > Christoph >=20 >=20 >> On 3 Mar 2017, at 10:43, lizhenqiang@chinamobile.com = wrote: >>=20 >> Hi, >>=20 >> I am reading this draft. I noticed that there are 7 actions listed in = table 2. But Only 5 of them are illustrated in section 7. Actions for = type 0x8108 and 0x8208 are not explained in this section. No references = are given here. May I know the reason? Thanks. >>=20 >> Best Regards, >> lizhenqiang@chinamobile.com >>=20 >> From: internet-drafts@ietf.org >> Date: 2017-02-23 19:23 >> To: i-d-announce@ietf.org >> CC: idr@ietf.org >> Subject: [Idr] I-D Action: draft-ietf-idr-rfc5575bis-00.txt >>=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 of the IETF. >>=20 >> Title : Dissemination of Flow Specification Rules >> Authors : Susan Hares >> Robert Raszuk >> Danny McPherson >> Christoph Loibl >> Martin Bacher >> Filename : draft-ietf-idr-rfc5575bis-00.txt >> Pages : 30 >> Date : 2017-02-22 >>=20 >> Abstract: >> This document updates RFC5575 which defines a Border Gateway = Protocol >> Network Layer Reachability Information (BGP NLRI) encoding format >> that can be used to distribute traffic flow specifications. This >> allows the routing system to propagate information regarding more >> specific components of the traffic aggregate defined by an IP >> destination prefix. This draft specifies IPv4 traffic flow >> specifications via a BGP NLRI which carries traffic flow >> specification filter, and an Extended community value which = encodes >> actions a routing system can take if the packet matches the = traffic >> flow filters. The flow filters and the actions are processed in a >> fixed order. Other drafts specify IPv6, MPLS addresses, L2VPN >> addresses, and NV03 encapsulation of IP addresses. >>=20 >> This document updates RFC5575 to correct unclear specifications in >> the flow filters and to provide rules for actions which interfere >> (e.g. redirection of traffic and flow filtering). >>=20 >> Applications which use the bgp flow specification are: 1) = application >> which automate of inter-domain coordination of traffic filtering, >> such as what is required in order to mitigate (distributed) = denial- >> of-service attacks; 2) application which control traffic filtering = in >> the context of a BGP/MPLS VPN service, and 3) applications with >> centralized control of traffic in a SDN or NFV context. Some of >> deployments of these three applications can be handled by the = strict >> ordering of the BGP NLRI traffic flow filters, and the strict = actions >> encoded in the Extended Community Flow Specification actions. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-idr-rfc5575bis/ = >>=20 >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-idr-rfc5575bis-00 = >>=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 >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr = > -- > Christoph Loibl > c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | = http://www.nextlayer.at -- Christoph Loibl c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | = http://www.nextlayer.at --Apple-Mail=_EF73AE10-9182-4050-8C75-DB35BDD54432 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi,

Your = comment makes sense to me. I collected a few other minor changes over = the last months (that I received as feedback) and added your comment to = this list. In about two weeks I will be ready to upload a new version of = our draft, after discussing that with the other authors.

Thanks for your = feedback!

Cheers 

Christoph

  
On 4 Mar 2017, at 15:01, lizhenqiang@chinamobile.com wrote:

Hi,

Since the sub sections of section 7 in this draft are = organised according to the sub type of the extended community, I think = the following table format for table 2 is better and easier to read. = Maybe it can be further improved. Cross references shown in the table = are also acceptable. You can also consider changing the title of section = 7.4 from IP redirect to VRF redirect, because the traffic is not = redirected to an IP address but a VRF. Redirect to IP is being discussed = in a seperate draft.

   =
+--------+----------------------+-----------------------------------+
   | type   | extended community   | encoding                          |
   +--------+----------------------+-----------------------------------+
   | 0x8006 | traffic-rate-bytes   | 2-byte ASN, 4-byte float          |
   | 0x8007 | traffic-action       | bitmask                           |
   | 0x8008 | VRF-redirect         | 2-octet AS, 4-octet value         |
   | 0x8108 | VRF-redirect         | 4-octet IPv4 addres, 2-octet      |
   |        |                      | value                             |
   | 0x8208 | VRF-redirect         | 4-octet AS, 2-octet value         |
   | 0x8009 | traffic-marking      | DSCP value                        |
   | TBD    | traffic-rate-packets | 2-byte ASN, 4-byte float          |
   =
+--------+----------------------+-----------------------------------+

Best Regards,

 
From: Christoph Loibl
Date: 2017-03-03 18:23
To: lizhenqiang@chinamobile.com
CC: idr
Subject: Re: [Idr] I-D Action: = draft-ietf-idr-rfc5575bis-00.txt
Hi,

There are 5 basic actions (extended = community sub-type 6,7,8,9,TBD =3D traffic-rate-bytes, traffic-action, = redirect, traffic-marking, traffic-rate-packets). However for the = redirect action there exist 3 different route-target encoding formats = (extended community sub-type 0x08 + type 0x80, 0x81 and 0x82):

| 0x8008 | redirect AS-2byte    | 2-octet AS, 4-octet value         =
|
| 0x8108 | redirect IPv4        | 4-octet IPv4 addres, 2-octet      |
|        |                      | value                             |
| 0x8208 | redirect AS-4byte    | 4-octet AS, 2-octet value         =
|

These three = encoding formats are explained in our draft section 7.4 (IP Redirect = sub-type 0x08) and basically use the same encoding as described in RFC = 4360 and RFC 5668. 

Do you think that additional clarification or a = cross-reference from the table to this secion is needed for each = action?

Cheers, 

Christoph


On 3 Mar 2017, at 10:43, lizhenqiang@chinamobile.com wrote:

Hi,

I am reading this draft. I noticed that = there are 7 actions listed in table 2. But Only 5 of them are = illustrated in section 7. Actions for type 0x8108 and 0x8208 are not = explained in this section. No references are given here. May I know the = reason? Thanks.

Best = Regards,
lizhenqiang@chinamobile.com
 
From: internet-drafts@ietf.org
Date: 2017-02-23 19:23
To: i-d-announce@ietf.org
CC: idr@ietf.org
Subject: [Idr] I-D Action: = draft-ietf-idr-rfc5575bis-00.txt
 
A New Internet-Draft is available = from the on-line Internet-Drafts directories.
This = draft is a work item of the Inter-Domain Routing of the IETF.
 
        = Title           : = Dissemination of Flow Specification Rules
        = Authors         : Susan = Hares
          &nb= sp;            = ;   Robert Raszuk
          &nb= sp;            = ;   Danny McPherson
          &nb= sp;            = ;   Christoph Loibl
          &nb= sp;            = ;   Martin Bacher
Filename        : = draft-ietf-idr-rfc5575bis-00.txt
Pages         &nbs= p; : 30
Date          = ;  : 2017-02-22
 
Abstract:
   This document = updates RFC5575 which defines a Border Gateway Protocol
   Network Layer Reachability Information (BGP = NLRI) encoding format
   that can be used = to distribute traffic flow specifications.  This
   allows the routing system to propagate = information regarding more
   specific = components of the traffic aggregate defined by an IP
   destination prefix.  This draft specifies = IPv4 traffic flow
   specifications via a = BGP NLRI which carries traffic flow
   = specification filter, and an Extended community value which = encodes
   actions a routing system can = take if the packet matches the traffic
   = flow filters.  The flow filters and the actions are processed in = a
   fixed order.  Other drafts = specify IPv6, MPLS addresses, L2VPN
   = addresses, and NV03 encapsulation of IP addresses.
 
   This document = updates RFC5575 to correct unclear specifications in
   the flow filters and to provide rules for = actions which interfere
   (e.g. = redirection of traffic and flow filtering).
 
   Applications which = use the bgp flow specification are: 1) application
   which automate of inter-domain coordination of = traffic filtering,
   such as what is = required in order to mitigate (distributed) denial-
   of-service attacks; 2) application which control = traffic filtering in
   the context of a = BGP/MPLS VPN service, and 3) applications with
   centralized control of traffic in a SDN or NFV = context.  Some of
   deployments of = these three applications can be handled by the strict
   ordering of the BGP NLRI traffic flow filters, = and the strict actions
   encoded in the = Extended Community Flow Specification actions.
 
 
The = IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-idr-rfc5575bis/=
 
There's also a = htmlized version available at:
https://tools.ietf.org/html/draft-ietf-idr-rfc5575bis-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/
 
_______________________________________________
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

-- 
Christoph Loibl
c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 = | http://www.nextlayer.at

-- 
Christoph Loibl
c@tix.at | CL8-RIPE | = PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at

= --Apple-Mail=_EF73AE10-9182-4050-8C75-DB35BDD54432-- --Apple-Mail=_25AB4334-F4EE-47E5-BC68-84A5A09E704F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAli7EKUACgkQ0m2Mp0ssAFU8QQCfdAYWUaSk8NdNWmNaUgZg0Fhk QMwAoKbO49i1RzH9XyDaUAWMnO9/5hqH =7y/T -----END PGP SIGNATURE----- --Apple-Mail=_25AB4334-F4EE-47E5-BC68-84A5A09E704F-- From nobody Sat Mar 4 16:21:23 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75F6D1293F8 for ; Sat, 4 Mar 2017 16:21:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7SoJn4lYrF6r for ; Sat, 4 Mar 2017 16:21:20 -0800 (PST) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e: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 D876C120724 for ; Sat, 4 Mar 2017 16:21:19 -0800 (PST) Received: by mail-pg0-x230.google.com with SMTP id 77so10841291pgc.1 for ; Sat, 04 Mar 2017 16:21:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=EF8XG+uXgw6Q76leZfiGegQ38EdUamcrzxaXRP8dhO8=; b=Vy9u+vNpETrKvvj5CI/6sVp5izcK/STD3qt9iBzSGN9b/Kh++47HBixt6pHdRhUSA6 YLox7ATU6vna+U08v++M3S4sgepFFSRNakea+JNIITM5HsOWyQP7Sg7cFUrnkFW+I7aJ vFWhks77TsiQHB6i+wnZYqcecuCjx2PogaoITJuLaHqCSgQnwzEAGtbPRU0rFaWn5dGd dEaOSQ1wLesKv1rwnuLTNmqs0KigRmZfbaEWt0B0KQUT7A8eln4OddjoqBwcx22HP9vz RxJCRiW71MMUk+y6n9b6boxW4Jx86lZ8ESF4wX/Hf9llLnBeEbwbOKMg0bvuMOmbV4Bt qzuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=EF8XG+uXgw6Q76leZfiGegQ38EdUamcrzxaXRP8dhO8=; b=lSMLri6BQ796+DAUlj/e5k/sOnIyv0DiruDYLC7kg1NdwEUZXwGnov7pZ7tKrGcKdx SK5QT5B4QOxIQU9hiSD/C2LKYNYD3mS7/oc7NCMikSJSI+rZ7zNXaQ472G+adDiqD+Hd y/hTUUwrBu1N60v3eO0YWOO1QQkqPpUFQ6uRwocjG2SXAUXnmz41z/VbLqmooR2ZWRIf jwUOyXReWpUDiUjFw8XCi2H1X/0DM/MltLZfiRfC3NULUNi9b7hFkqyyTTaZYAgd5oee P6YKlmyTaFIPvC8ucRF+abnvcB5icEtGa66fnkpipjAxeNJNyOINQdBSWNA1XeNKAFoc x57g== X-Gm-Message-State: AMke39lr+JAZ+ag1VZk3x4bMWi1XJa+ulozhsUM23KNzwD9L/QZsTQQcKSlGUyVgV3LFlw== X-Received: by 10.84.218.205 with SMTP id g13mr14931001plm.78.1488673279383; Sat, 04 Mar 2017 16:21:19 -0800 (PST) Received: from ?IPv6:2607:fb90:2200:1813:3485:a453:869a:d6ce? ([2607:fb90:2200:1813:3485:a453:869a:d6ce]) by smtp.gmail.com with ESMTPSA id e129sm31099169pfe.8.2017.03.04.16.21.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 04 Mar 2017 16:21:17 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-628BC08D-6B2D-407A-995C-58A9006CBD66 Mime-Version: 1.0 (1.0) From: Jeff Tantsura X-Mailer: iPhone Mail (14D27) In-Reply-To: Date: Sat, 4 Mar 2017 16:21:13 -0800 Content-Transfer-Encoding: 7bit Message-Id: <19BCC3A8-48A7-4838-A999-5B304C0C7EED@gmail.com> References: <148854728632.10105.590253116263033290.idtracker@ietfa.amsl.com> <4BF12F22-F605-406F-9CD8-ACE350B981D0@alcatel-lucent.com> To: Robert Raszuk Archived-At: Cc: idr wg , "Van De Velde, Gunter \(Nokia - BE\)" Subject: Re: [Idr] FW: New Version Notification for draft-vandevelde-idr-bgp-ls-segment-routing-rld-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Mar 2017 00:21:21 -0000 --Apple-Mail-628BC08D-6B2D-407A-995C-58A9006CBD66 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Robert, Please take a look at 02 isis draft published yesterday, we have added type f= lag that defines the type of a SID and could be used with v6 dataplane. The limitations wrt label operations are well understood across both custom a= nd merchant silicon and from use case prospective had to be addressed first= . V6 dataplane will be added. Please let me know if this answers your questions and addresses concerns. Regards, Jeff > On Mar 4, 2017, at 06:24, Robert Raszuk wrote: >=20 > Jeff, >=20 > MSD drafts (yours invluded) talks about labels while MSD as such seems to b= e defined as maximum SID depth. >=20 > In SRv6 SID is *NOT* a label. So why not to define MSD properly across all= SR scenarios? >=20 > Are we going to have now new zoo of drafts now defining MSD for SRv6 vs cu= rrent docs just defining MSD for SR-MPLS ? >=20 > Cheers, > R. >=20 >=20 >=20 >> On Mar 4, 2017 9:41 AM, "Jeff Tantsura" wrote: >> Robert, >>=20 >> That's done in MSD drafts. >> In the recently published isis draft we have also introduced MSD type fla= g that would be used to signal different types of SID's: recirculated labels= , EL's, etc >>=20 >> Cheers, >> Jeff >>=20 >> On Fri, Mar 3, 2017 at 22:35 Robert Raszuk wrote: >> Hey Gunter, >>=20 >> Good proposal however why do you only think about labels ? >>=20 >> Seriously if this is to move fwd let's add ability to signal also followi= ng elements: >>=20 >> * ability to punt SR-MPLS to local CPU (slow path) when not handled in ha= rdware (per node basis) >>=20 >> * add signalling for number of SRv6 SRHs supported per node/per LC >>=20 >> * add signalling for depth per SRH and total of SIDs supported per node/p= er LC >>=20 >> * signal ability to punt to slow path or not for longer then support SRH s= tack or number of SIDs in each SRH structure. >>=20 >> Cheers, >> Robert. >>=20 >>=20 >> On Fri, Mar 3, 2017 at 3:55 PM, Van De Velde, Gunter (Nokia - BE) wrote: >> Heads-up=85 Happy to learn feedback and comments. >>=20 >> This draft is short and defines the attribute to use for BGP-LS to expose= a >> node RLD "Readable Label Depth" to a centralised controller (PCE/SDN). >>=20 >> G/ >>=20 >> On 03/03/2017, 14:21, "internet-drafts@ietf.org" wrote: >>=20 >>=20 >> A new version of I-D, draft-vandevelde-idr-bgp-ls-segment-routing-rld= -01.txt >> has been successfully submitted by Gunter Van de Velde and posted to t= he >> IETF repository. >>=20 >> Name: draft-vandevelde-idr-bgp-ls-segment-routing-rld >> Revision: 01 >> Title: Signalling RLD using BGP-LS >> Document date: 2017-03-03 >> Group: Individual Submission >> Pages: 5 >> URL: https://www.ietf.org/internet-drafts/draft-vandevelde= -idr-bgp-ls-segment-routing-rld-01.txt >> Status: https://datatracker.ietf.org/doc/draft-vandevelde-idr= -bgp-ls-segment-routing-rld/ >> Htmlized: https://tools.ietf.org/html/draft-vandevelde-idr-bgp-= ls-segment-routing-rld-01 >> Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-vandevelde-= idr-bgp-ls-segment-routing-rld-01 >>=20 >> Abstract: >> This document defines the attribute to use for BGP-LS to expose a >> node RLD "Readable Label Depth" to a centralised controller (PCE/ >> SDN). >>=20 >>=20 >>=20 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of sub= mission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> The IETF Secretariat >>=20 >>=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 --Apple-Mail-628BC08D-6B2D-407A-995C-58A9006CBD66 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Robert,

Pleas= e take a look at 02 isis draft published yesterday, we have added type flag t= hat defines the type of a SID and could be used with v6 dataplane.
The limitations wrt label operations are well understood across both custom= and merchant  silicon and from use case prospective had to be addresse= d first.
V6 dataplane will be added.

Plea= se let me know if this answers your questions and addresses concerns.
<= div>
Regards,
Jeff

On Mar 4, 2017, at 0= 6:24, Robert Raszuk <robert@raszuk.n= et> wrote:

Jeff,

MSD drafts (yours inv= luded) talks about labels while MSD as such seems to be defined as maximum S= ID depth.

In SRv6 SID is *= NOT* a label. So why not to define MSD properly across all SR scenarios?

Are we going to have now new= zoo of drafts now defining MSD for SRv6 vs current docs just defining MSD f= or SR-MPLS ?

Cheers,
R.


On Ma= r 4, 2017 9:41 AM, "Jeff Tantsura" <jefftant.ietf@gmail.com> wrote:
Robert,

That's done in MSD drafts.<= br class=3D"m_9028297214918060569gmail_msg">In the recently published isis d= raft we have also introduced MSD type flag that would be used to signal diff= erent types of SID's: recirculated labels, EL's, etc

Cheers,
Jeff

On Fri, Mar 3, 2017 at 22:35 Robert Raszuk &= lt;robert@raszuk.net> wrote:
Hey Gunter,

<= div class=3D"gmail_default m_9028297214918060569gmail_msg" style=3D"font-fam= ily:arial,helvetica,sans-serif;font-size:small">Good proposal however why do= you only think about labels ?

Seriously if this is to move fwd let's add a= bility to signal also following elements:

* ability to punt SR-MPLS to loca= l CPU (slow path) when not handled in hardware (per node basis)

* add sign= alling for number of SRv6 SRHs supported per node/per LC

* add signalling fo= r depth per SRH and total of SIDs supported per node/per LC

* signal ability= to punt to slow path or not for longer then support SRH stack or number of S= IDs in each SRH structure.

Cheers,
Robert.


<= div class=3D"gmail_quote m_9028297214918060569gmail_msg">On Fri, Mar 3, 2017= at 3:55 PM, Van De Velde, Gunter (Nokia - BE) <gunter.van_de_velde@no= kia.com> wrote:
Heads-up=E2=80= =A6 Happy to learn feedback and comments.

This draft is short and defines the attribute to use for BGP-LS to expose a<= br class=3D"m_9028297214918060569gmail_msg"> node RLD "Readable Label Depth" to a centralised controller (PCE/SDN).

G/

On 03/03/2017, 14:21, "internet-drafts@ietf.org" <internet-drafts@ietf.org> wrote:

    A new version of I-D, draft-vandevelde-idr-bgp-ls-segment= -routing-rld-01.txt
    has been successfully submitted by Gunter Van de Velde and pos= ted to the
    IETF repository.

    Name:               dr= aft-vandevelde-idr-bgp-ls-segment-routing-rld
    Revision:   01
    Title:              Signall= ing RLD using BGP-LS
    Document date:      2017-03-03
    Group:              Individ= ual Submission
    Pages:              5
    URL:            https://www.ietf.org/internet-drafts/draft-vandevelde-idr= -bgp-ls-segment-routing-rld-01.txt
    Status:         h= ttps://datatracker.ietf.org/doc/draft-vandevelde-idr-bgp-ls-segmen= t-routing-rld/
    Htmlized:       https://t= ools.ietf.org/html/draft-vandevelde-idr-bgp-ls-segment-routing-rld= -01
    Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-vandevelde-idr-bgp-<= wbr>ls-segment-routing-rld-01

    Abstract:
       This document defines the attribute to use for BG= P-LS to expose a
       node RLD "Readable Label Depth" to a centralised c= ontroller (PCE/
       SDN).





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

    The IETF Secretariat



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

_______________________________________________
Idr mailing list
Idr@ietf.org
= https://www.ietf.org= /mailman/listinfo/idr
= --Apple-Mail-628BC08D-6B2D-407A-995C-58A9006CBD66-- From nobody Sat Mar 4 23:40:34 2017 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4622E1293EB; Sat, 4 Mar 2017 23:40:29 -0800 (PST) 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.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148869962928.23395.17714511113395724295.idtracker@ietfa.amsl.com> Date: Sat, 04 Mar 2017 23:40:29 -0800 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-extended-messages-21.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Mar 2017 07:40:29 -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 of the IETF. Title : Extended Message support for BGP Authors : Randy Bush Keyur Patel Dave Ward Filename : draft-ietf-idr-bgp-extended-messages-21.txt Pages : 6 Date : 2017-03-04 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 RFC4271 by providing an extension to BGP to extend its current maximum 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-21 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-extended-messages-21 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Mar 4 23:46:52 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3460D12946E; Sat, 4 Mar 2017 23:46:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xtd0ICBtaTVH; Sat, 4 Mar 2017 23:46:48 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 9FC6E126BF6; Sat, 4 Mar 2017 23:46:48 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1ckQsP-0005JL-Q9; Sun, 05 Mar 2017 07:46:46 +0000 Date: Sun, 05 Mar 2017 16:46:42 +0900 Message-ID: From: Randy Bush To: "Alvaro Retana (aretana)" In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=BIG5 Content-Transfer-Encoding: base64 Archived-At: Cc: "idr-chairs@ietf.org" , "draft-ietf-idr-bgp-extended-messages@ietf.org" , Susan Hares , "idr@ietf.org" Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Mar 2017 07:46:50 -0000 cXVpdGUgdGhlIHJldmlldy4gIGRlY2lkZWQgdG8gZWFybiB5b3VyIGRpbm5lciwgZWg/ICBvd2Ug eW91IG9uZS4gIHlvdQ0KY2FuIGNvbGxlY3QgaW4gY2hpY2Fnby4NCg0KPiBNMS4gU2VjdGlvbiA0 LiAoT3BlcmF0aW9uKTogoadBbiBpbXBsZW1lbnRhdGlvbiB0aGF0IHN1cHBvcnRzIHRoZSBCR1AN Cj4gRXh0ZW5kZWQgTWVzc2FnZXMgTVVTVCBiZSBwcmVwYXJlZCB0byByZWNlaXZlIGFuIFVQREFU RSBtZXNzYWdlIHRoYXQNCj4gaXMgbGFyZ2VyIHRoYW4gNDA5NiBieXRlcy6hpyBPbmx5IFVQREFU RXM/DQoNCnllcy4gIHNlZSBqZWZmJ3MgbWVzc2FnZS4NCg0KPiBJIGtub3cgdGhhdCB0aGUgbW9z dCBsaWtlbHkgY2FzZSBmb3IgZXhjZWVkaW5nIHRoZSA0ayBzaXplIGlzIGFuDQo+IFVQREFURSwg YnV0IHdoeSBhcmUgdGhlIG90aGVyIG1lc3NhZ2VzIG5vdCBjb25zaWRlcmVkPw0KDQpyYXRoZXIg YXNrIHdoeSB0aGV5IHNob3VsZCBiZS4gIGkga25vdyB0aGlzIGlzIGJncCwgYnV0IGRvIHdlIHJl YWxseQ0KbmVlZCB0byBjb21wbGljYXRlIGxpZmU/DQoNCmFuZCB0aGVyZSBpcyBhIGJpdCBvZiBh IHJlY3Vyc2lvbiBwcm9ibGVtIGlmIHlvdSB0cnkgdG8gZXh0ZW5kZWQgT1BFTi4NCg0KPiB3aGF0 IGRvZXMgoadwcmVwYXJlZCB0byByZWNlaXZloaggbWVhbiwgYW5kIGhvdyBjYW4goadNVVNUIGJl IHByZXBhcmVkIHRvDQo+IHJlY2VpdmWhqCBiZSBlbmZvcmNlZD8NCg0KICAgQW4gaW1wbGVtZW50 YXRpb24gdGhhdCBhZHZlcnRpc2VzIHN1cHBvcnQgZm9yIEJHUCBFeHRlbmRlZCBNZXNzYWdlcw0K ICAgTVVTVCBiZSBjYXBhYmxlIG9mIHJlY2VpdmluZyBhbiBVUERBVEUgbWVzc2FnZSB3aXRoIGEg bGVuZ3RoIHVwIHRvDQogICBhbmQgaW5jbHVkaW5nIDY1NTM1IG9jdGV0cy4NCg0KbGlrZSBtYW55 IE1VU1RzLCB0aGVyZSBpcyBubyBkaXJlY3QgZW5mb3JjZW1lbnQsIG9ubHkgdGhlIGFiaWxpdHkg dG8NCmRpYWdub3NlIGJsYW1lIGluIHRoZSBjYXNlIG9mIGZhaWx1cmUgYW5kIGhhdmUgdGhlIHJl c3VsdGluZyB0YWMgdGlja2V0DQpiZSBjbGFzc2lmaWVkIGFzIGFuIGVuaGFuY2VtZW50IHJlcXVl c3QgOikNCg0KPiBHaXZlbiB0aGUgZGlzY3Vzc2lvbiBpbiBTZWN0aW9uIDUgKEVycm9yIEhhbmRs aW5nKSwgeW91IG1pZ2h0IHdhbnQgdG8NCj4gYWRkIHNvbWV0aGluZyBsaWtlIKGnoUtldmVuIGlm IHRoZSBDYXBhYmlsaXR5IGlzIG5vdCBhZHZlcnRpc2VkoaguDQoNCnRoaXMgc2VjdGlvbiBpcyBw cmVkaWNhdGVkIG9uIGFkdmVydGlzZW1lbnQuICBwZXJzb25hbGx5LCBhcyBhIGxvbmcgdGVybQ0K bmFnZ3VtaXRlICh5ZXMsIGRyIHBvc3RlbCBhbmQgaSBhcmd1ZWQgYWJvdXQgdGhpcyksIGkgdGhp bmsgdGhlIHdob2xlDQpzZW5kL3JlY2VpdmUgd2l0aG91dCBhZHZlcnRpc2VtZW50IGlzIGEgdXNl bGVzcyBzbGlwcGVyeSBzbG9wZSBhbmQgaQ0Kd291bGQgYmUgaGFwcHkgdG8gdG9zcyBpdC4NCg0K PiBNMi4gU2VjdGlvbiA1IChFcnJvciBIYW5kbGluZykuICChp0EgQkdQIHNwZWFrZXIgdGhhdCBo YXMgdGhlIGFiaWxpdHkNCj4gdG8gdXNlIGV4dGVuZGVkIG1lc3NhZ2VzIGJ1dCBoYXMgbm90IGFk dmVydGlzZWQgdGhlIEJHUCBFeHRlbmRlZA0KPiBNZXNzYWdlcyBjYXBhYmlsaXR5LCBwcmVzdW1h Ymx5IGR1ZSB0byBjb25maWd1cmF0aW9uLCBTSE9VTEQgTk9UDQo+IGFjY2VwdCBhbiBleHRlbmRl ZCBtZXNzYWdlLiAgQSBzcGVha2VyIE1BWSBpbXBsZW1lbnQgYSBtb3JlIGxpYmVyYWwNCj4gcG9s aWN5IGFuZCBhY2NlcHQgZXh0ZW5kZWQgbWVzc2FnZXMgZXZlbiBmcm9tIGEgcGVlciB0aGF0IGhh cyBub3QNCj4gYWR2ZXJ0aXNlZCB0aGUgY2FwYWJpbGl0eS6hqCAgVGhpcyBwYXJhZ3JhcGggdHJv dWJsZXMgbWUgYSBsb3QgYmVjYXVzZQ0KPiBpdCBpcyBpbiBkaXJlY3QgY29udHJhY3Rpb24gd2l0 aCBTZWN0aW9uIDM6IKGnQSBwZWVyIHdoaWNoIGRvZXMgbm90DQo+IGFkdmVydGlzZSB0aGlzIGNh cGFiaWxpdHkgTVVTVCBOT1Qgc2VuZCBCR1AgRXh0ZW5kZWQgTWVzc2FnZXMsIGFuZCBCR1ANCj4g RXh0ZW5kZWQgTWVzc2FnZXMgTVVTVCBOT1QgYmUgc2VudCB0byBpdC6hqC4gIEhvd2V2ZXIsIEkg dGhpbmsgdGhhdA0KPiBKb2huIFNjdWRkZXKhpnMgcmVhc29uaW5nIFszXSBtYWtlcyBzZW5zZSAo ImtlZXAgdGhlIHNlc3Npb24gdXAgYXQNCj4gKGFsbW9zdCkgYWxsIGNvc3RzIiwgYW5kIHRoZXJl oaZzIGNsZWFyIHByZWNlZGVuY2UgaW4gdGhlIFdHKSBmb3IgdGhlDQo+IGNhc2Ugd2hlcmUgdGhl IHNlbmRlciBkaWQgYWR2ZXJ0aXNlIHRoZSBDYXBhYmlsaXR5LCBidXQgSaGmbSBub3QNCj4gY29u dmluY2VkIG9uIHRoZSBjYXNlIHdoZXJlIGl0IGRpZG6hpnQgoVYgcGxlYXNlIGluY2x1ZGUgc29t ZXRoaW5nIGxpa2UNCj4gSm9obqGmcyBleHBsYW5hdGlvbiBpbiB0aGUgdGV4dC4NCg0KeW91IGRp ZCBzZWUgd2hlcmUgam9obiB3ZW50IG9uIHRvIHNheSAiSSBhY2tub3dsZWRnZSB0aGlzIGNob2lj ZSB3b3VsZA0KYmUgZmFpcmx5IGRpc2d1c3RpbmcsIGFuZCBJIHVuZGVyc3RhbmQgd2h5IHRoZSBh dXRob3JzIGRpZG4ndCBtYWtlIGl0LiINCg0KYnV0LCBpZiB3ZSBrZWVwIHRoZSBNQVksIHRoZW4g aSBndWVzcyB0aHJvd2luZyBpbiBqZ3MncyBleGN1c2UgaXMNCndvcnRod2hpbGUuDQoNCiAgIEEg QkdQIHNwZWFrZXIgdGhhdCBoYXMgdGhlIGFiaWxpdHkgdG8gdXNlIGV4dGVuZGVkIG1lc3NhZ2Vz IGJ1dCBoYXMNCiAgIG5vdCBhZHZlcnRpc2VkIHRoZSBCR1AgRXh0ZW5kZWQgTWVzc2FnZXMgY2Fw YWJpbGl0eSwgcHJlc3VtYWJseSBkdWUNCiAgIHRvIGNvbmZpZ3VyYXRpb24sIFNIT1VMRCBOT1Qg YWNjZXB0IGFuIGV4dGVuZGVkIG1lc3NhZ2UuICBBIHNwZWFrZXINCiAgIE1BWSBpbXBsZW1lbnQg YSBtb3JlIGxpYmVyYWwgcG9saWN5IGFuZCBhY2NlcHQgZXh0ZW5kZWQgbWVzc2FnZXMsDQogICBl dmVuIGZyb20gYSBwZWVyIHRvIHdoaWNoIGl0IGhhcyBub3QgYWR2ZXJ0aXNlZCB0aGUgY2FwYWJp bGl0eSwgaW4NCiAgIHRoZSBpbnRlcmVzdCBvZiBwcmVzZXJ2aW5nIHRoZSBCR1Agc2Vzc2lvbiBp ZiBhdCBhbGwgcG9zc2liZS4NCg0KPiBNMi4xLiAgRXZlbiB3aXRoIEpvaG6hpnMgZXhwbGFuYXRp b24sIEkgZmluZCBteXNlbGYgdGhpbmtpbmcgdGhhdCB0aGlzDQo+IHNwZWNpZmljYXRpb24gY291 bGQgcmVzdWx0IGluIHNvbWUgc2xvcHB5IGltcGxlbWVudGF0aW9uczogaWYgSSBuZWVkDQo+IHRv IGFjY291bnQgZm9yIHJlY2VpdmluZyB1bmV4cGVjdGVkIEV4dGVuZGVkIE1lc3NhZ2VzIGluIG15 IGNvZGUsIHRoZW4NCj4gbWF5YmUgSSB3b26hpnQgd29ycnkgdG9vIG11Y2ggYWJvdXQgY29udHJv bGxpbmcgd2hhdCB0byBzZW5kIHRvIG15DQo+IHBlZXJzIKFWIHNwZWNpYWxseSBpbiBjYXNlcyB3 aGVyZSBpdCB3b3VsZCBiZSBlYXN5IHRvIGp1c3QgcmVwbGljYXRlIGFuDQo+IFVQREFURSAobGlr ZSBpbiBhIHBlZXItZ3JvdXApIGFuZCBub3Qgd29ycnkgYWJvdXQgcG9zc2libGUgZXhjZXB0aW9u cy4NCj4gSSBrbm93IHRoYXQgd2UgY2FuoaZ0IGF2b2lkIGJhZCBpbXBsZW1lbnRhdGlvbnMsIG5v IG1hdHRlciB3aGF0IHRleHQgaXMNCj4gYWRkZWQgoVYgYnV0IEkgdGhpbmsgdGhhdCByZWNvZ25p emluZyB0aGUgdGhyZWF0IChtYXliZSBpbiB0aGUgU2VjdXJpdHkNCj4gQ29uc2lkZXJhdGlvbnMg c2VjdGlvbikgb2Ygc29tZW9uZSByZWNlaXZpbmcgYW4gRXh0ZW5kZWQgTWVzc2FnZSB3aGVuDQo+ IHRoZXkgZG9uoaZ0IHN1cHBvcnQgaXQgd291bGQgYmUgZ29vZC4gIEkga25vdyB0aGF0IHRoZXJl oaZzIHRleHQgaW4gdGhlDQo+IGRvY3VtZW50IGFscmVhZHkgd2hpY2ggdGFsa3MgYWJvdXQgd2hh dCB0byBkbyBpZiB0aGUgcmVjZWl2ZXIgZG9lc26hpnQNCj4gc3VwcG9ydCBFeHRlbmRlZCBNZXNz YWdlcyChViBJoaZtIGp1c3Qgd29ycmllZCBhYm91dCBwb3RlbnRpYWwgaXNzdWVzDQo+IHdpdGgg bWVtb3J5IGFsbG9jYXRpb24gaWYgdGhlIHJlY2VpdmVyIHdhcyBub3QgcmVhZHmhSw0KDQppbiB0 aGUgYWJzZW5zZSBvZiBhbiBBRCB3aXRoIHRoZSBndXRzIHRvIGxldCBtZSB0ZWFyIHRoYXQgb3V0 LCBpJ2xsIHB1dA0KYSBub3RlIGluIHNlYyBjb25zLiA6KQ0KDQogICBTZWN0aW9uIDUgYWxsb3dl ZCBhIHJlY2VpdmVyIHRvIGFjY2VwdCBhbiBleHRlbmRlZCBtZXNzYWdlIGV2ZW4NCiAgIHRob3Vn aCB0aGV5IGhhZCBub3QgYWR2ZXJ0aXNlZCB0aGUgY2FwYWJpbGl0eS4gIFRoaXMgc2xpcHBlcnkg c2xvcGUNCiAgIHdpbGwgc3VyZWx5IGxlYWQgdG8gc2xvcHB5IGltcGxlbWVudGF0aW9ucyBzZW5k aW5nIGV4dGVuZGVkIG1lc3NhZ2VzDQogICB3aGVuIHRoZSByZWNlaXZlciBpcyBub3QgcHJlcGFy ZWQgdG8gZGVhbCB3aXRoIHRoZW0sIGUuZy4gdG8gcGVlcg0KICAgZ3JvdXBzLiAgQXQgYmVzdCwg dGhpcyB3aWxsIHJlc3VsdCBpbiBlcnJvZXM7IGF0IHdvcnN0LCBidWZmZXINCiAgIG92ZXJmbG93 cy4NCg0KPiBNMy4gU2VjdGlvbiA1IChFcnJvciBIYW5kbGluZykuICChp6FLcmVzZXQgdGhlIHNl c3Npb24gd2l0aCBhIEJhZA0KPiBNZXNzYWdlIExlbmd0aCBOT1RJRklDQVRJT06hS6GoIFBsZWFz ZSBiZSBjbGVhciBhbmQgc3BlY2lmaWM6IChzb21ldGhpbmcNCj4gbGlrZSB0aGlzIHdvdWxkIGJl IG1vcmUgcHJlY2lzZSkgoacuLi5zZW5kIGEgTk9USUZJQ0FUSU9OIG1lc3NhZ2Ugd2l0aA0KPiB0 aGUgRXJyb3IgQ29kZSBzZXQgdG8gTWVzc2FnZSBIZWFkZXIgRXJyb3IgYW5kIHRoZSBFcnJvciBT dWJjb2RlIHNldA0KPiB0byBCYWQgTWVzc2FnZSBUeXBlLCBhbmQgY2xvc2UgdGhlIHNlc3Npb26h qC4gIEFsdGVybmF0aXZlbHksIHlvdSBjYW4NCj4ganVzdCByZW1vdmUgdGhlIHRleHQgKGFmdGVy IHRoZSByZWZlcmVuY2UgdG8gcmZjNDI3MSkgYXMgdGhhdCBpcyB3aGF0DQo+IHJmYzQyNzEgYWxy ZWFkeSBzYXlzIGFuZCB0aGVyZaGmcyBubyBuZWVkIHRvIHJlcGVhdCBpdCBoZXJlIGFuZCByaXNr DQo+IG5vdCBiZWluZyBwcmVjaXNloUsNCg0KaSBsaWtlIHJlbW92aW5nIHRleHQhDQoNCj4gTTQu IFNlY3Rpb24gNSAoRXJyb3IgSGFuZGxpbmcpLiAgoadTaW1pbGFybHksIGFueSBzcGVha2VyIHRo YXQgdHJlYXRzDQo+IGFuIGltcHJvcGVyIGV4dGVuZGVkIG1lc3NhZ2UgYXMgYSBmYXRhbCBlcnJv ciwgTVVTVCBkbyBsaWtld2lzZS6hqCAgSXQNCj4gc291bmRzIHRoYXQgeW91oaZyZSBzYXlpbmcg dGhhdCBhbnkgZmF0YWwgZXJyb3Igd2lsbCByZXN1bHQgaW4gYSChp0JhZA0KPiBNZXNzYWdlIExl bmd0aCBOT1RJRklDQVRJT06hqC4gIEkgaG9wZSB0aGF0IGlzIG5vdCB3aGF0IHlvdSBtZWFudCCh ViBhbmQNCj4gdGhhdCBvdGhlciBlcnJvcnMgc2hvdWxkIHJlc3VsdCBpbiB0aGUgYXBwcm9wcmlh dGUgYWN0aW9uIGZyb20NCj4gcmZjNDI3MS9yZmM3NjA2LiAgSU9XLCB0aGUgZXJyb3IgY2hlY2tp bmcgZm9yIHRoZSBtZXNzYWdlIChiZXNpZGVzIGRlDQo+IGxlbmd0aCkgZG9lc26hpnQgY2hhbmdl LCByaWdodD8NCg0Kb2ssIGpncywgd2hhdCBkaWQgeW91IG1lYW4gYnkgImFueSBzcGVha2VyIHRo YXQgdHJlYXRzIGFuIGltcHJvcGVyDQpleHRlbmRlZCBtZXNzYWdlIGFzIGEgZmF0YWwgZXJyb3Is IiBhbmQgd2hhdCBkaWQgeW91IHRoaW5rIHdlIHNob3VsZA0KZG8gYWJvdXQgaXQuICBuZWl0aGVy IDQyNzEgbm90IDc2MDYgdGVsbCB3aGF0IHRvIGRvIHdpdGggYSBmYXRhbCBlcnJvcg0KcGVyIHNl Lg0KDQpzYXlpbmcgdHJlYXQgaXQgYXMgYW4gYXMgYW4gVVBEQVRFIE1lc3NhZ2UgRXJyb3IgcGVy IFJGQzQyNzEgaXMgbm90DQpwZXJmZWN0LCBhcyBpdCBjb3VsZCBiZSBhbiBvdmVybHkgbG9uZyBt ZXNzYWdlIG9mIGEgZGlmZmVyZW50IHR5cGUuDQoNCmNsdWUgYmF0LCBwbGVhc2UuDQoNCj4gTTUu IFNlY3Rpb24gNSAoRXJyb3IgSGFuZGxpbmcpLiAgoadUaGUgaW5jb25zaXN0ZW5jeSBiZXR3ZWVu IHRoZSBsb2NhbA0KPiBhbmQgcmVtb3RlIEJHUCBzcGVha2VycyBNVVNUIGJlIHJlcG9ydGVkIHZp YSBzeXNsb2cgYW5kL29yIFNOTVAuoagNCj4gU05NUD8gIEFGQUlLLCB0aGVyZaGmcyBubyBvYmpl Y3QgdGhhdCBjYW4gcmVwb3J0IHRoaXMgaW5jb25zaXN0ZW5jeQ0KPiBzaW5jZSB0aGVyZaGmcyBu byBOT1RJRklDQVRJT04gZ2VuZXJhdGVkLiAgSW4gdGhlIHByb3Bvc2VkIHRleHQgYnkNCj4gR3Vu dGVyIFZhbiBEZSBWZWxkZSBbNF0sIFNOTVAgYW5kIHN5c2xvZyB3ZXJlIG1lbnRpb25lZCBhcyBl eGFtcGxlcyChVg0KPiBJIHN1Z2dlc3QgeW91IGZvbGxvdyB0aGF0IHBhdGggKG5vIG5lZWQgZm9y IGFsbCB0aGUgoadmbG93ZXJ5DQo+IGxhbmd1YWdloagpIGFuZCBqdXN0IHJlZmVyZW5jZSBtZWNo YW5pc21zIGJ5IGV4YW1wbGUgdG8gYXZvaWQgaGF2aW5nIHRvDQo+IHBvaW50IGF0IGhvdyBpdCB3 b3VsZCBiZSBkb25lLg0KPg0KPiBNNS4xLiBbbWlub3JdIEd1bnRlciBoYWQgb3JpZ2luYWxseSBz dWdnZXN0ZWQgdGhhdCB0aGUgbWVzc2FnZSB0aGF0DQo+IGNhdXNlZCB0aGUgaW5jb25zaXN0ZW5j eSBiZSBpbmNsdWRlZCBpbiB0aGUgcmVwb3J0LiAgQXJlIHlvdSBleHBlY3RpbmcNCj4gdGhlIGlu Y29uc2lzdGVuY3kgcmVwb3J0IHRvIGp1c3QgYmUgYSChp0JvYiBzZW50IG1lIGFuIEV4dGVuZGVk DQo+IE1lc3NhZ2UsIGJ1dCBJIGRpZG6hpnQgYWR2ZXJ0aXNlIHRoZSBDYXBhYmlsaXR5IHRvIGhp baGoLXR5cGUgbWVzc2FnZSwNCj4gb3Igc29tZXRoaW5nIG1vcmU/ICBJdCBtaWdodCBiZSB1c2Vm dWwgdG8gcHJvdmlkZSBzb21lIGd1aWRhbmNlDQo+IGluZGljYXRpbmcgd2hhdCB0eXBlIG9mIGlu Zm9ybWF0aW9uIG1pZ2h0IGJlIHVzZWZ1bC9pbnRlcmVzdGluZy4NCg0KICAgVGhlIGluY29uc2lz dGVuY3kgYmV0d2VlbiB0aGUgbG9jYWwgYW5kIHJlbW90ZSBCR1Agc3BlYWtlcnMgTVVTVCBiZQ0K ICAgZmxhZ2dlZCB0byB0aGUgbmV0d29yayBvcGVyYXRvciB0aHJvdWdoIHN0YW5kYXJkIG9wZXJh dGlvbmFsDQogICBpbnRlcmZhY2VzLiAgVGhlIGluZm9ybWF0aW9uIHNob3VsZCBpbmNsdWRlIHRo ZSBOTFJJIGFuZCBhcyBtdWNoDQogICByZWxldmFudCBpbmZvcm1hdGlvbiBhcyByZWFzb25hYmx5 IHBvc3NpYmxlLg0KDQo+IE02LiBVcGRhdGVzIHRvIHJmYzQyNzEuICBUaGUgQWJzdHJhY3QvSW50 cm9kdWN0aW9uIGNvcnJlY3RseSBtZW50aW9uDQo+IHRoYXQgdGhpcyBkb2N1bWVudCBVcGRhdGVz IHJmYzQyNzEuICBCdXQgSSB0aGluayB3ZSBuZWVkIHRvIGJlIG1vcmUNCj4gc3BlY2lmaWMsIHNw ZWNpYWxseSB3aGVyZSByZmM0MjcxIGNoYW5nZXMgYW5kIHRoZXJlIGlzIG5vcm1hdGl2ZQ0KPiBs YW5ndWFnZSBpbnZvbHZlZC4gIEkgZm91bmQgdHdvIGNhc2VzOg0KPiANCj4gTTYuMS4gU2VjdGlv biA1IGRvZXNuoaZ0IGRlc2NyaWJlIHRoZSBiZWhhdmlvciBpZiB0aGUgbWVzc2FnZSBpcyBsb25n ZXINCj4gdGhhbiA2NTUzNS4gIFBsZWFzZSBpbmNsdWRlIGVpdGhlciBhbiBleHBsaWNpdCB1cGRh dGUgdG8NCj4gcmZjNDI3MS9TZWN0aW9uIDYuMSBmb3IgdGhlIHVzZSBvZiBFeHRlbmRlZCBNZXNz YWdlcywgb3IgdGhlIHNwZWNpZmljDQo+IHByb2Nlc3MgaGVyZS4NCj4gDQo+IE02LjIuIHJmYzQy NzE6IKGnVGhlIHZhbHVlIG9mIHRoZSBMZW5ndGggZmllbGQgTVVTVCBhbHdheXMgYmUgYXQgbGVh c3QNCj4gMTkgYW5kIG5vIGdyZWF0ZXIgdGhhbiA0MDk2oaggVGhhdCBuZWVkcyB0byBiZSB1cGRh dGVkIHRvIDY1NTM1Lg0KDQo2LiAgQ2hhbmdlcyB0byBSRkM0MjcxDQoNCiAgIFtSRkM0MjcxXSBz dGF0ZXMgIlRoZSB2YWx1ZSBvZiB0aGUgTGVuZ3RoIGZpZWxkIE1VU1QgYWx3YXlzIGJlIGF0DQog ICBsZWFzdCA+IDE5IGFuZCBubyBncmVhdGVyIHRoYW4gNDA5Ni4iICBUaGlzIGRvY3VtZW50IGNo YW5nZXMgdGhlDQogICBsYXR0ZXIgbnVtYmVyIHRvIDY1NTM1IGZvciBVUERBVEUgbWVzc2FnZXMu DQoNCiAgIFtSRkM0MjcxXSBTZWMgNi4xLCBzcGVjaWZpZXMgcmFpc2luZyBhbiBlcnJvciBpZiB0 aGUgbGVuZ3RoIG9mIGENCiAgIG1lc3NhZ2UgaXMgb3ZlciA0MDk2IG9jdGV0cy4gIEZvciBVUERB VEUgbWVzc2FnZXMsIGlmZiB0aGUgcmVjZWl2ZXINCiAgIGhhcyBhZHZlcnRpc2VkIHRoZSBjYXBh YmlsaXR5IHRvIHJlY2VpdmUgZXh0ZW5kZWQgbWVzc2FnZXMsIHRoaXMNCiAgIGRvY3VtZW50IHJh aXNlcyB0aGF0IGxpbWl0IHRvIDY1NTM1Lg0KDQo+IE03LiBXaGF0IGFib3V0IHRyYW5zaXRpb24v bWlncmF0aW9uL3BhcnRpYWwgZGVwbG95bWVudD8gIFdoYXQgc2hvdWxkDQo+IHRoZSBiZWhhdmlv ciBiZSBpZiwgZm9yIGV4YW1wbGUsIGFuIEV4dGVuZGVkIE1lc3NhZ2UgVVBEQVRFIGlzDQo+IHJl Y2VpdmVkIGZyb20gYSBwZWVyLCBidXQgY2FuoaZ0IGJlIHByb3BhZ2F0ZWQgdG8gb3RoZXJzIGJl Y2F1c2UgdGhleQ0KPiBkb26hpnQgc3VwcG9ydCBFeHRlbmRlZCBNZXNzYWdlcw0KDQppZiB0aGV5 IGRvIG5vdCBzdXBwb3J0IGV4dGVuZGVkIG1lc3NhZ2VzLCB0aGVuIHRoZXkgY2FuIG5vdCBiZSBi Z3BzZWMNCnNwZWFrZXJzLiAgc28gdGhlIHdob2xlIGJncHNlYyBwYXRoIHN0cmlwcGluZyBhcHBs aWVzIGFuZCB0aGUgbWVzc2FnZQ0KYmVjb21lcyBzaG9ydC4NCg0KPiBUaGVyZSBzaG91bGQgYmUg c29tZSBndWlkYW5jZSBmb3IgdGhlIGdlbmVyYWwgY2FzZSAoaS5lLiB3aGVuIHRoZQ0KPiB0b3Rh bCBzaXplIGlzID40ayBkdWUgc2ltcGx5IHRvIHRoZSB0b3RhbCBhbW91bnQgb2YgaW5mb3JtYXRp b24sIGFuZA0KPiBub3QgYmVjYXVzZSBhIHNpbmdsZSBhdHRyaWJ1dGUsIGZvciBleGFtcGxlLCBp cyByZWFsbHkgYmlnKQ0KDQpob3cgYWJvdXQgImRvIG5vdCBkbyB0aGlzPyINCg0KaSBiZWxpZXZl IHlvdSBoYXZlIGVudGVyZWQgYSB0d2lzdHkgbWF6ZSBpbiB3aGljaCBhbGwgcm9vbXMgZG8gbm90 IGhhdmUNCnBhdGgocykgdG8gdGhlIGV4aXQuDQoNCjQuICBPcGVyYXRpb24NCi4uLg0KICAgQSBC R1AgYW5ub3VuY2VtZW50IHdpbGwsIGluIHRoZSBub3JtYWwgY2FzZSwgcHJvcGFnYXRlIHRocm91 Z2hvdXQgdGhlDQogICBCR1Agc3BlYWtpbmcgSW50ZXJuZXQ7IGFuZCB0aGVyZSB3aWxsIHVuZG91 YnRlZGx5IGJlIEJHUCBzcGVha2Vycw0KICAgd2hpY2ggZG8gbm90IGhhdmUgdGhlIEV4dGVuZGVk IE1lc3NhZ2UgY2FwYWJpbGl0eS4gIFRoZXJlZm9yZSBwdXR0aW5nDQogICBhbiBhdHRyaWJ1dGUg d2hpY2ggY2FuIG5vdCBiZSBkZWNvbXBvc2VkIHRvIDQwOTYgb2N0ZXRzIG9yIGxlc3MgaW4gYW4N CiAgIEV4dGVuZGVkIE1lc3NhZ2UgaXMgYSBzdXJlIHBhdGggdG8gcm91dGluZyBmYWlsdXJlLg0K DQo+IFAxLiBBYnN0cmFjdDogcy9leHRlbmQgaXRzIGN1cnJlbnQgbWVzc2FnZSBzaXplIGZyb20g NDA5Ni9leHRlbmQgaXRzDQo+IGN1cnJlbnQgbWF4aW11bSBtZXNzYWdlIHNpemUgZnJvbSA0MDk2 DQoNCmFjaw0KDQo+IFAyLiBzL0ktRC5pZXRmLXNpZHItYmdwc2VjLW92ZXJ2aWV3L0ktRC5pZXRm LXNpZHItYmdwc2VjLXByb3RvY29sDQoNCmFjaw0KDQo+IFAzLiBJQU5BIGFscmVhZHkgYXNzaWdu ZWQgQ29kZSA2IGZvciB0aGUgQ2FwYWJpbGl0eS4gIFBsZWFzZSB1c2UgdGhhdA0KPiB2YWx1ZSBh bmQgcmVtaW5kIElBTkEgb2YgdGhlIGVhcmx5IGFsbG9jYXRpb24gaW4gdGhlIElBTkENCj4gQ29u c2lkZXJhdGlvbnMgc2VjdGlvbi4NCg0KYWNrDQoNCj4gUDQuIEkgZG9uoaZ0IHVuZGVyc3RhbmQg d2hhdCB0aGlzIG1lYW5zOiChp0FwcGxpY2F0aW9ucyBnZW5lcmF0aW5nDQo+IG1lc3NhZ2VzIHdo aWNoIG1pZ2h0IGJlIGVuY2Fwc3VsYXRlZCB3aXRoaW4gQkdQIG1lc3NhZ2VzIE1VU1QgbGltaXQN Cj4gdGhlIHNpemUgb2YgdGhlaXIgcGF5bG9hZCB0byB0YWtlIGludG8gYWNjb3VudCB0aGUgbWF4 aW11bSBtZXNzYWdlDQo+IHNpemUuoagNCg0KZ2l2ZW4gdGhhdCB3ZSByZXN0cmljdCB0byBVUERB VEUsIGkgZG8gbm90IGtub3cgd2hhdCB0aGlzIG1lYW5zIGF0IGFsbA0KOikNCg0KPiBQNS4gU2Vj dXJpdHkgQ29uc2lkZXJhdGlvbnM6IEkgdGhpbmsgaXQgd291bGQgYmUgZ29vZCB0byBhbHNvDQo+ IHJlZmVyZW5jZSByZmM0MjcyIChCR1AgU2VjdXJpdHkgVnVsbmVyYWJpbGl0aWVzIEFuYWx5c2lz KSBpbiB0aGlzDQo+IHNlY3Rpb24uDQoNCnN1cmUNCg0KPiBOMS4goadJdCBkb2VzIGVuYWJsZSBs YXJnZSBCR1BzZWMgQkdQU0VDX1BBVEhzLCBzZWUNCj4gW0ktRC5pZXRmLXNpZHItYmdwc2VjLXBy b3RvY29sXS6hqCAgTmljZSwgYnV0IHN1cGVyZmx1b3VzIGFzIGl0IHJlZmVycw0KPiB0byB0aGlz IGRvY3VtZW50LiAgWzIgPHRleHQvaHRtbDsgdXRmLTggKGJhc2U2NCk+XQ0KDQphY2sNCg0KcmFu ZHksIHdobyBpcyBzZXJpb3VzIGFib3V0IHRoZSBkaW5uZXIgb2ZmZXIuICB0aGlzIHdhcyBvbmUg aGVsbCBvZiBhDQogICAgICAgcmV2aWV3 From nobody Sun Mar 5 12:22:36 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3AA51294C3; Sun, 5 Mar 2017 12:22:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QRXzJsjv8jZZ; Sun, 5 Mar 2017 12:22:34 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 B1F931294A2; Sun, 5 Mar 2017 12:22:33 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.90.29; From: "Susan Hares" To: "'Randy Bush'" , "'Alvaro Retana \(aretana\)'" References: In-Reply-To: Date: Sun, 5 Mar 2017 15:17:35 -0500 Message-ID: <000201d295ed$8824b320$986e1960$@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: AQInnAj+Yxa8tap/yfCJFXAjQYwk1wF1zsYwoNDf5yA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: idr-chairs@ietf.org, draft-ietf-idr-bgp-extended-messages@ietf.org, idr@ietf.org Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Mar 2017 20:22:35 -0000 Randy and Alvaro: A few point have raised my disagreement regarding the AD reviews. At this point, the text is at odds with RFC4271. If you feel RFC4271, does not speak about these issues - you may have missed why the BGP FSM is there. Please change your text. Sue Point 1 - =============== Alvaro: > An implementation that advertises support for BGP Extended Messages > MUST be capable of receiving an UPDATE message with a length up to > and including 65535 octets. Randy: >like many MUSTs, there is no direct enforcement, only the ability to diagnose blame in the case of failure and have the resulting tac ticket be classified as an enhancement request :) Sue: Normally, the diagnosis comes from testers that people run prior to putting things in the field (E.g. IXIA). Part of BGP implementation testing is a length BGP FSM test with a tester. ------------- Point 2: Error handling is precisely defined in the BGP FSM. You need to tag the Extended message reception to the BGP Header error for all of this to work. Randy's comment: Randy: "ok, jgs, what did you mean by "any speaker that treats an improper extended message as a fatal error," and what did you think we should do about it. neither 4271 not 7606 tell what to do with a fatal error per se." Sue's response: Any messages that exceeds 4096 for BGP speaker will result in a BGP state machine event of BGP Header error (event 21, BGP state machine, page 49). Therefore, the error procedures would be based on this even in the BGP FSM based on state. The RFC4271 error handling procedures are defined by the BGP FSM based on the current state . Please walk through the BGP FSM to fine the precise action based on state. Implementations do adhere to it. There are options - so please read the entire section. Text from version 21 A BGP speaker that has the ability to use Extended Messages but has not advertised the BGP Extended Messages capability, presumably due to configuration, SHOULD NOT accept an Extended Message. A speaker MAY implement a more liberal policy and accept Extended Messages, even from a peer to which it has not advertised the capability, in the interest of preserving the BGP session if at all possible. A BGP speaker that does not advertise the BGP Extended Messages capability might also genuinely not support Extended Messages. Such a speaker would be expected to follow the error handling procedures of [RFC4271] if it receives an Extended Message. Similarly, any speaker that treats an improper Extended Message as a fatal error, MUST treat it similarly. The inconsistency between the local and remote BGP speakers MUST be flagged to the network operator through standard operational interfaces. The information should include the NLRI and as much relevant information as reasonably possible. Replacement text. A BGP speaker that has the ability to use Extended Messages but has not advertised the BGP Extended Messages capability, presumably due to configuration, SHOULD NOT accept an Extended Message. A BGP speaker that does not advertise the BGP Extended Messages capability might also genuinely not support Extended Messages. If the BGP speaker does not accept an extended messages, the BGP speaker MUST indicate a BGP Header error (event 21) to the BGP finite state machine (FSM). A speaker MAY implement a more liberal policy and accept Extended Messages, even from a peer to which it has not advertised the capability, in the interest of preserving the BGP session if at all possible. ============================================================================ ========================= #3 - on reporting this error - The HEADER length error is reported as part of the BGP Statement machine for errors. Why are we going through additional issues rather than stay with the BGP Finite state machine. Either the Length field is correct, or it is not. If you have an erroneous length for what is configured, you drop it. Most people include the erroneous header length and check the BGP speakers. Why are you making this more complicated? If you want to enforce the MUST, then we must open the BGP FSM. ======================== #4 - on the limit the message size, this was to be a warning to BESS or other groups to not defined BGP applications which not stuff more junk in than the BGP packet size can hold. > P4. I don't understand what this means: "Applications generating > messages which might be encapsulated within BGP messages MUST limit > the size of their payload to take into account the maximum message > size. It is a social warning, like the cancer warning on cigarettes. I not in favor of social warnings in a base technical specification. Author/AD can remove. Sue Hares -----Original Message----- From: Randy Bush [mailto:randy@psg.com] Sent: Sunday, March 5, 2017 2:47 AM To: Alvaro Retana (aretana) Cc: draft-ietf-idr-bgp-extended-messages@ietf.org; idr-chairs@ietf.org; idr@ietf.org; Susan Hares Subject: Re: AD Review of draft-ietf-idr-bgp-extended-messages-20 quite the review. decided to earn your dinner, eh? owe you one. you can collect in chicago. > M1. Section 4. (Operation): "An implementation that supports the BGP > Extended Messages MUST be prepared to receive an UPDATE message that > is larger than 4096 bytes." Only UPDATEs? yes. see jeff's message. > I know that the most likely case for exceeding the 4k size is an > UPDATE, but why are the other messages not considered? rather ask why they should be. i know this is bgp, but do we really need to complicate life? and there is a bit of a recursion problem if you try to extended OPEN. > what does "prepared to receive" mean, and how can "MUST be prepared to > receive" be enforced? An implementation that advertises support for BGP Extended Messages MUST be capable of receiving an UPDATE message with a length up to and including 65535 octets. like many MUSTs, there is no direct enforcement, only the ability to diagnose blame in the case of failure and have the resulting tac ticket be classified as an enhancement request :) > Given the discussion in Section 5 (Error Handling), you might want to > add something like ".even if the Capability is not advertised". this section is predicated on advertisement. personally, as a long term naggumite (yes, dr postel and i argued about this), i think the whole send/receive without advertisement is a useless slippery slope and i would be happy to toss it. > M2. Section 5 (Error Handling). "A BGP speaker that has the ability > to use extended messages but has not advertised the BGP Extended > Messages capability, presumably due to configuration, SHOULD NOT > accept an extended message. A speaker MAY implement a more liberal > policy and accept extended messages even from a peer that has not > advertised the capability." This paragraph troubles me a lot because > it is in direct contraction with Section 3: "A peer which does not > advertise this capability MUST NOT send BGP Extended Messages, and BGP > Extended Messages MUST NOT be sent to it.". However, I think that > John Scudder's reasoning [3] makes sense ("keep the session up at > (almost) all costs", and there's clear precedence in the WG) for the > case where the sender did advertise the Capability, but I'm not > convinced on the case where it didn't - please include something like > John's explanation in the text. you did see where john went on to say "I acknowledge this choice would be fairly disgusting, and I understand why the authors didn't make it." but, if we keep the MAY, then i guess throwing in jgs's excuse is worthwhile. A BGP speaker that has the ability to use extended messages but has not advertised the BGP Extended Messages capability, presumably due to configuration, SHOULD NOT accept an extended message. A speaker MAY implement a more liberal policy and accept extended messages, even from a peer to which it has not advertised the capability, in the interest of preserving the BGP session if at all possibe. > M2.1. Even with John's explanation, I find myself thinking that this > specification could result in some sloppy implementations: if I need > to account for receiving unexpected Extended Messages in my code, then > maybe I won't worry too much about controlling what to send to my > peers - specially in cases where it would be easy to just replicate an > UPDATE (like in a peer-group) and not worry about possible exceptions. > I know that we can't avoid bad implementations, no matter what text is > added - but I think that recognizing the threat (maybe in the Security > Considerations section) of someone receiving an Extended Message when > they don't support it would be good. I know that there's text in the > document already which talks about what to do if the receiver doesn't > support Extended Messages - I'm just worried about potential issues > with memory allocation if the receiver was not ready. in the absense of an AD with the guts to let me tear that out, i'll put a note in sec cons. :) Section 5 allowed a receiver to accept an extended message even though they had not advertised the capability. This slippery slope will surely lead to sloppy implementations sending extended messages when the receiver is not prepared to deal with them, e.g. to peer groups. At best, this will result in erroes; at worst, buffer overflows. > M3. Section 5 (Error Handling). ".reset the session with a Bad > Message Length NOTIFICATION." Please be clear and specific: (something > like this would be more precise) "...send a NOTIFICATION message with > the Error Code set to Message Header Error and the Error Subcode set > to Bad Message Type, and close the session". Alternatively, you can > just remove the text (after the reference to rfc4271) as that is what > rfc4271 already says and there's no need to repeat it here and risk > not being precise. i like removing text! > M4. Section 5 (Error Handling). "Similarly, any speaker that treats > an improper extended message as a fatal error, MUST do likewise." It > sounds that you're saying that any fatal error will result in a "Bad > Message Length NOTIFICATION". I hope that is not what you meant - and > that other errors should result in the appropriate action from > rfc4271/rfc7606. IOW, the error checking for the message (besides de > length) doesn't change, right? ok, jgs, what did you mean by "any speaker that treats an improper extended message as a fatal error," and what did you think we should do about it. neither 4271 not 7606 tell what to do with a fatal error per se. saying treat it as an as an UPDATE Message Error per RFC4271 is not perfect, as it could be an overly long message of a different type. clue bat, please. > M5. Section 5 (Error Handling). "The inconsistency between the local > and remote BGP speakers MUST be reported via syslog and/or SNMP." > SNMP? AFAIK, there's no object that can report this inconsistency > since there's no NOTIFICATION generated. In the proposed text by > Gunter Van De Velde [4], SNMP and syslog were mentioned as examples - > I suggest you follow that path (no need for all the "flowery > language") and just reference mechanisms by example to avoid having to > point at how it would be done. > > M5.1. [minor] Gunter had originally suggested that the message that > caused the inconsistency be included in the report. Are you expecting > the inconsistency report to just be a "Bob sent me an Extended > Message, but I didn't advertise the Capability to him"-type message, > or something more? It might be useful to provide some guidance > indicating what type of information might be useful/interesting. The inconsistency between the local and remote BGP speakers MUST be flagged to the network operator through standard operational interfaces. The information should include the NLRI and as much relevant information as reasonably possible. > M6. Updates to rfc4271. The Abstract/Introduction correctly mention > that this document Updates rfc4271. But I think we need to be more > specific, specially where rfc4271 changes and there is normative > language involved. I found two cases: > > M6.1. Section 5 doesn't describe the behavior if the message is longer > than 65535. Please include either an explicit update to > rfc4271/Section 6.1 for the use of Extended Messages, or the specific > process here. > > M6.2. rfc4271: "The value of the Length field MUST always be at least > 19 and no greater than 4096" That needs to be updated to 65535. 6. Changes to RFC4271 [RFC4271] states "The value of the Length field MUST always be at least > 19 and no greater than 4096." This document changes the latter number to 65535 for UPDATE messages. [RFC4271] Sec 6.1, specifies raising an error if the length of a message is over 4096 octets. For UPDATE messages, iff the receiver has advertised the capability to receive extended messages, this document raises that limit to 65535. > M7. What about transition/migration/partial deployment? What should > the behavior be if, for example, an Extended Message UPDATE is > received from a peer, but can't be propagated to others because they > don't support Extended Messages if they do not support extended messages, then they can not be bgpsec speakers. so the whole bgpsec path stripping applies and the message becomes short. > There should be some guidance for the general case (i.e. when the > total size is >4k due simply to the total amount of information, and > not because a single attribute, for example, is really big) how about "do not do this?" i believe you have entered a twisty maze in which all rooms do not have path(s) to the exit. 4. Operation ... A BGP announcement will, in the normal case, propagate throughout the BGP speaking Internet; and there will undoubtedly be BGP speakers which do not have the Extended Message capability. Therefore putting an attribute which can not be decomposed to 4096 octets or less in an Extended Message is a sure path to routing failure. > P1. Abstract: s/extend its current message size from 4096/extend its > current maximum message size from 4096 ack > P2. s/I-D.ietf-sidr-bgpsec-overview/I-D.ietf-sidr-bgpsec-protocol ack > P3. IANA already assigned Code 6 for the Capability. Please use that > value and remind IANA of the early allocation in the IANA > Considerations section. ack > P4. I don't understand what this means: "Applications generating > messages which might be encapsulated within BGP messages MUST limit > the size of their payload to take into account the maximum message > size." given that we restrict to UPDATE, i do not know what this means at all :) > P5. Security Considerations: I think it would be good to also > reference rfc4272 (BGP Security Vulnerabilities Analysis) in this > section. sure > N1. "It does enable large BGPsec BGPSEC_PATHs, see > [I-D.ietf-sidr-bgpsec-protocol]." Nice, but superfluous as it refers > to this document. [2 ] ack randy, who is serious about the dinner offer. this was one hell of a review From nobody Mon Mar 6 07:30:58 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D3E6129856; Mon, 6 Mar 2017 07:30:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id diFDLAhbDF10; Mon, 6 Mar 2017 07:30:50 -0800 (PST) Received: from SNT004-OMC3S45.hotmail.com (snt004-omc3s45.hotmail.com [65.54.51.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D450F129533; Mon, 6 Mar 2017 07:30:49 -0800 (PST) Received: from NAM04-SN1-obe.outbound.protection.outlook.com ([65.55.90.137]) by SNT004-OMC3S45.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Mon, 6 Mar 2017 07:30:49 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=pIqDaBzjNTzUSKWGhYjQQoAKHq7NIm1XVdOnwNxVQ0g=; b=a165YJRsjc67/6LsDP6ffGW2tKKrXOO3dvr44AWf8ofXDHf4Ta18Q1/YFjTRaR0PEpvB/Mlbdo0+EnIzmntgNPnHzQDpsjowMOXWDLHbCxLqY9or5eQSFHPhR/KjsPtU+2GvfWdvgMEc9Ov4oEFHsrVFAvC+h1pCxpWVbpdCZsaeARDagTmb8v/Q+myXKZ2cJ2irMqu0a/GJJijOMCYMbguqfoWe1+MJ0+4HiChoyCErZN9QmwPps5SUOYcF8n2G97kIHWkRFfUCImKr5aqzuesCTTnx9KU8LYoBNR222nAc3Ri9ddV3f5/lR7qtCx3L7CChF/s60YDHaX2VoYa8aQ== Received: from SN1NAM04FT057.eop-NAM04.prod.protection.outlook.com (10.152.88.53) by SN1NAM04HT190.eop-NAM04.prod.protection.outlook.com (10.152.89.70) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.7; Mon, 6 Mar 2017 15:30:48 +0000 Received: from DM3PR13MB0604.namprd13.prod.outlook.com (10.152.88.55) by SN1NAM04FT057.mail.protection.outlook.com (10.152.89.46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.7 via Frontend Transport; Mon, 6 Mar 2017 15:30:48 +0000 Received: from DM3PR13MB0604.namprd13.prod.outlook.com ([10.164.8.150]) by DM3PR13MB0604.namprd13.prod.outlook.com ([10.164.8.150]) with mapi id 15.01.0961.012; Mon, 6 Mar 2017 15:30:48 +0000 From: Shitanshu Shah To: Susan Hares , 'Ron Bonica' , "rtg-dir@ietf.org" , "draft-ietf-idr-sla-exchange.all@ietf.org" , "idr@ietf.org" Thread-Topic: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 Thread-Index: AdKIcLCEU+uutt39QyCrZCwOKAXyLQAcLKCoAUVZnUABwWlZAABkf7iD Date: Mon, 6 Mar 2017 15:30:47 +0000 Message-ID: References: , <053401d294fc$6f739180$4e5ab480$@ndzh.com> In-Reply-To: <053401d294fc$6f739180$4e5ab480$@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;ndzh.com; dmarc=none action=none header.from=hotmail.com; x-incomingtopheadermarker: OriginalChecksum:8797B8E6FDBC250D14C27A269C3275FF9A3D1994DDD992494D0309914C016D03; UpperCasedChecksum:D584D6E1E63B0CC5343555987AD40272E34BB43D7F31975C2D16102608CD6B06; SizeAsReceived:8538; Count:42 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [KevUdZ8OBCcj/tzWMwko89OfbHb3PIhu] x-microsoft-exchange-diagnostics: 1; SN1NAM04HT190; 5:ioNP1yjUKL5FNooy2hmWIeWt3iiG3LH6+8+9s1G8aLzDOFUjYaFzo9YCRUUORuagKYdjyK59eysoJyCFc1daxSV+UPpPA00GTP3ZvUnoB+u+cB6UbPuYoMaZetyxzaQ/CY4XMP41T5poXzVCEmDh1Q==; 24:VJaE6nz3UOx/5yty5fD/XNVtehU17sAyJ9UKpAHCv26+4/E9oYYjnBMUTAD54bFCtEfJ4v4v8YzyWmEcgVbXHEANnE9h7nhkPEejqhhffY0=; 7:PV5LAlV5lJnjuKiqxg3bvYLAtIenMBGpSccXm7rp4HUx5pNxpXV9x0anhwkT8TvtrvtfXYuFbQrAqkKLYZMIqhLA1bed1iYbq8fUQfI/Iyaz64SQ1Hsa8gjfYPOHpUgnm2O/b1PogDX81bRtElPm5GbD0tdGuRjignfEsbPnIxKdhL/ezx6HH5sVJkx3cwAuw/WVRjfJAPWZU8DqTPYj7yJS839NjWmd5prgUz4eiAD6qZLwI8vLMM/E1GIxt+wObEgYL1ZNmCT3s8ep1rhtaLzBlsTrI3WSlZhqK4Kt87xhD5VM4HQnHVrj3x9u8SFI x-incomingheadercount: 42 x-eopattributedmessage: 0 x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(10019020)(98900016); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1NAM04HT190; H:DM3PR13MB0604.namprd13.prod.outlook.com; FPR:; SPF:None; LANG:en; x-ms-office365-filtering-correlation-id: 837ace01-1a50-4f50-45eb-08d464a5c39c x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201702061074)(5061506573)(5061507331)(1603103135)(201702181095)(1601125254)(1603101448)(1701031045); SRVR:SN1NAM04HT190; x-ms-exchange-slblob-mailprops: EpEO96k6WokzTUcyF24Llm7faH7xOndcavwlKEL5jzWPDnN2zeoc9eDtVmhUVXRAb3Qdn5Kris/hnonW35W9KBmtDjbHbdu1naClsvJJmD1iQ3cgy0D65q8pYs41VulERfUJALX/wHkSG+YsILtx6jdXrwveFhz3PlGVMQGvaPEqKF4d+OEAkG27PDhB19KRySOtO7L9woVJEJi+JxcU0lzuxaeaw9WoXjFCbkCiQCYUY4bac49kgwMUYHJYlcO4A35R0ozrM6urO9j8Y5HcsqhKk/+TwLHFLpPpc1U/lwyQZE39WzPEDiiHKT25LMJTY9zSJaJp3ZN2E9166v6/ZJCYnOza7hFf7AxlJGOxlFTiBiQUZPee73gCwWWI35Ti3GsLoT6FtKu1s98qhRt9Xc819CCwKkMlCmLgAFr7RMsJ/nE9BADC1PApzzfR/I2/ArJ+XnyZcqANR4ApZB4aXM3iyfs5EdVhCGrTfOlddT1AQt21+7ses1xE7yyf/rYcpKAU/Zh8P98VDB73hYhdc2+w5DeFO8CihRYE4T7j4l6S483D0APkLrwzl6fUSzdL1y12Mbx/uwGQ7FCI6Hj4ZKuXCXCG4tp60t4105G6QqxQ9OW49gyZPuTB6tsZkUbHBDi+MlyldF5IzNLe1OfigSBuln7oIXjZfZCwm8M5k5wttS3hfDo6vtrkLHIv3wOQVQGP+Efi/KhtYTQhgwDLrIuZBjyktqa4Ae6lGWJrTkwhpo0a1E+4e1+dZ9WONGYQ7z+FAzOgH5A= x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(432015087)(444000031); SRVR:SN1NAM04HT190; BCL:0; PCL:0; RULEID:; SRVR:SN1NAM04HT190; x-forefront-prvs: 0238AEEDB0 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM3PR13MB0604AC6594DBE7B40707F528E52C0DM3PR13MB0604namp_" MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Mar 2017 15:30:47.9168 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1NAM04HT190 X-OriginalArrivalTime: 06 Mar 2017 15:30:49.0000 (UTC) FILETIME=[A1B9DA80:01D2968E] Archived-At: Subject: Re: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 15:30:52 -0000 --_000_DM3PR13MB0604AC6594DBE7B40707F528E52C0DM3PR13MB0604namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Sue, Following is what I had responded to Ron. Hopefully that addresses/clarifie= s. To break it down in two point response, 1) This draft is not changing how SLA is established at first place. The dr= aft is providing a method to convey this a priori established SLA to help r= educe lot of manual complexities and errors to admin. Thus given a knowledg= e of what SLA is established, in general devices should be capable to suppo= rt that established SLA. 2) If there still are any issues in implementing exchanged SLA in forwardin= g, we think they either are implementation specific or of temporary nature = where for example enough resources not available at any specific point of a= time. We feel that in current state of the draft, it can be largely useful in dep= loyments. One can imagine though even establishment of SLA also can be done via excha= nging it over bgp. However, negotiation of SLA does not have to be clubbed = with exchange of SLA. Negotiation of SLA is not in this scope. Regards, Shitanshu ________________________________ From: Susan Hares Sent: Saturday, March 4, 2017 8:31 AM To: 'Ron Bonica'; 'Shitanshu Shah'; rtg-dir@ietf.org; draft-ietf-idr-sla-ex= change.all@ietf.org; idr@ietf.org Subject: RE: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 Shitanshu: Please address Ron=92s comment about widely deployed. I believe this was p= art of Alvaro=92s comments. Sue From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Ron Bonica Sent: Thursday, February 23, 2017 12:07 PM To: Shitanshu Shah; rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.= org; idr@ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 Hello, The draft is internally consistent. But given what is left out of scope, I = wonder if the new attributes will ever be widely deployed. = Ron This document might benefit from discussion of operational issues. I assume= that when a BGP listener learns a route with the SLA Exchange Attribute, i= t provisions class of service forwarding classes on interfaces. ##svshah, though this is one desired use of exchanging SLA content, the dra= ft focuses on transporting SLA content from the SLA Producer to the SLA Con= sumer. Processing of the QoS attribute content, at the SLA Consumer, is out= side the scope of this document. ##svshah, Let me know if you have a suggestion to make description clearer = in Section 1 and 2 to highlight this. I also assume that a) it takes time to provision class of service forwardin= g classes and b) the number of forwarding classes that can be provisioned a= re finite. What does the BGP listener do when the number of forwarding clas= ses requested exceeds its capacity to deliver? ##svshah, Since scope of the document is to transport SLA content from the = SLA Producer to the SLA Consumer, the document considers error handling in = the context of transporting data and thus any formating errors and semantic= s errors within that context. Any errors in the context of processing QoS a= ttribute content at the SLA Consumer is outside the scope of the document. --_000_DM3PR13MB0604AC6594DBE7B40707F528E52C0DM3PR13MB0604namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi Sue,


Following is what I had responded to Ron. Hopefully that addresses/= clarifies.


To break i= t down in two point response,


1) This dr= aft is not changing how SLA is established at first place. The draft i= s providing a method to convey this a priori established SLA to help r= educe lot of manual complexities and errors to admin. Thus given a knowledge of what SLA is established, in general de= vices should be capable to support that established SLA.



2) If ther= e still are any issues in implementing exchanged SLA in forwarding, we thin= k they either are implementation specific or of temporary nature where= for example enough resources not available at any specific point of a time.


We feel th= at in current state of the draft, it can be largely useful in deployments.<= /p>




One can im= agine though even establishment of SLA also can be done via exchanging= it over bgp. However, negotiation of SLA does not have to be clubbed with = exchange of SLA. Negotiation of SLA is not in this scope.


Regards,=
Shitansh= u


From: Susan Hares <share= s@ndzh.com>
Sent: Saturday, March 4, 2017 8:31 AM
To: 'Ron Bonica'; 'Shitanshu Shah'; rtg-dir@ietf.org; draft-ietf-idr= -sla-exchange.all@ietf.org; idr@ietf.org
Subject: RE: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10=
 

Shitanshu:

 

Please address Ron=92s = comment about widely deployed.  I believe this was part of Alvaro=92s = comments.

 

Sue

 

From: rtg-di= r [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Ron Bonica
Sent: Thursday, February 23, 2017 12:07 PM
To: Shitanshu Shah; rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.al= l@ietf.org; idr@ietf.org
Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10=

 

Hello,

 

The draft is internally= consistent. But given what is left out of scope, I wonder if the new attri= butes will ever be widely deployed.

 

    = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ; Ron

 

 


This document might benefit from discussion of operational issues. I assume= that when a BGP listener learns a route with the SLA Exchange Attribute, i= t provisions class of service forwarding classes on interfaces.

 

##svshah= , though this is one desired use of exchanging SLA content, the draft focus= es on transporting SLA content from the SLA Producer to the SLA Consumer. P= rocessing of the QoS attribute content, at the SLA Consumer, is outside the scope of this document.

 

##svshah= , Let me know if you have a suggestion to make description clearer in Secti= on 1 and 2 to highlight this.

 

 

I also assume that a) it = takes time to provision class of service forwarding classes and b) the numb= er of forwarding classes that can be provisioned are finite. What does the BGP listener do when the number of forwarding classes reques= ted exceeds its capacity to deliver? 

 

##svshah= , Since scope of the document is to transport SLA content from the SLA Prod= ucer to the SLA Consumer, the document considers error handling in the cont= ext of transporting data and thus any formating errors and semantics errors within that context. Any errors = in the context of processing QoS attribute content at the SLA Consumer is o= utside the scope of the document.

 

 

 

--_000_DM3PR13MB0604AC6594DBE7B40707F528E52C0DM3PR13MB0604namp_-- From nobody Mon Mar 6 08:29:08 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7205129540; Mon, 6 Mar 2017 08:29:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CtM5BlReGbkW; Mon, 6 Mar 2017 08:29:06 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 A78931294F5; Mon, 6 Mar 2017 08:29:05 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.90.29; From: "Susan Hares" To: "'Shitanshu Shah'" , "'Ron Bonica'" , , , References: , <053401d294fc$6f739180$4e5ab480$@ndzh.com> In-Reply-To: Date: Mon, 6 Mar 2017 11:24:02 -0500 Message-ID: <00b401d29696$11e5a850$35b0f8f0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B5_01D2966C.2912FBB0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH+U8bIprcHIBv9vIIxWXYNekqkjQJ00uVDAja9hsUCLb3BQwJAbTEloOe2COA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 16:29:07 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00B5_01D2966C.2912FBB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Shitanshu: Ron is discussing your point #2 - you need to engage him on issue #2. You can provide input from operators who indicate this is necessary, but it is important to have this discussion. Alvaro was concerned about the deployments of these attributes. Sue From: Shitanshu Shah [mailto:shitanshu_shah@hotmail.com] Sent: Monday, March 6, 2017 10:31 AM To: Susan Hares; 'Ron Bonica'; rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; idr@ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 Hi Sue, Following is what I had responded to Ron. Hopefully that addresses/clarifies. To break it down in two point response, 1) This draft is not changing how SLA is established at first place. The draft is providing a method to convey this a priori established SLA to help reduce lot of manual complexities and errors to admin. Thus given a knowledge of what SLA is established, in general devices should be capable to support that established SLA. 2) If there still are any issues in implementing exchanged SLA in forwarding, we think they either are implementation specific or of temporary nature where for example enough resources not available at any specific point of a time. We feel that in current state of the draft, it can be largely useful in deployments. One can imagine though even establishment of SLA also can be done via exchanging it over bgp. However, negotiation of SLA does not have to be clubbed with exchange of SLA. Negotiation of SLA is not in this scope. Regards, Shitanshu _____ From: Susan Hares Sent: Saturday, March 4, 2017 8:31 AM To: 'Ron Bonica'; 'Shitanshu Shah'; rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; idr@ietf.org Subject: RE: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 Shitanshu: Please address Ron's comment about widely deployed. I believe this was part of Alvaro's comments. Sue From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Ron Bonica Sent: Thursday, February 23, 2017 12:07 PM To: Shitanshu Shah; rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; idr@ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 Hello, The draft is internally consistent. But given what is left out of scope, I wonder if the new attributes will ever be widely deployed. Ron This document might benefit from discussion of operational issues. I assume that when a BGP listener learns a route with the SLA Exchange Attribute, it provisions class of service forwarding classes on interfaces. ##svshah, though this is one desired use of exchanging SLA content, the draft focuses on transporting SLA content from the SLA Producer to the SLA Consumer. Processing of the QoS attribute content, at the SLA Consumer, is outside the scope of this document. ##svshah, Let me know if you have a suggestion to make description clearer in Section 1 and 2 to highlight this. I also assume that a) it takes time to provision class of service forwarding classes and b) the number of forwarding classes that can be provisioned are finite. What does the BGP listener do when the number of forwarding classes requested exceeds its capacity to deliver? ##svshah, Since scope of the document is to transport SLA content from the SLA Producer to the SLA Consumer, the document considers error handling in the context of transporting data and thus any formating errors and semantics errors within that context. Any errors in the context of processing QoS attribute content at the SLA Consumer is outside the scope of the document. ------=_NextPart_000_00B5_01D2966C.2912FBB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Shitanshu:

 

Ron is discussing your point #2 – you need to engage him on = issue #2.    You can provide input from operators who = indicate this is necessary, but it is important to have this = discussion.  Alvaro was concerned about the deployments of these = attributes.

 

Sue

 

From:= = Shitanshu Shah [mailto:shitanshu_shah@hotmail.com]
Sent: = Monday, March 6, 2017 10:31 AM
To: Susan Hares; 'Ron Bonica'; = rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; = idr@ietf.org
Subject: Re: [RTG-DIR] RtgDir review: = draft-ietf-idr-sla-exchange-10

 

Hi = Sue,

 

Following is = what I had responded to Ron. Hopefully that = addresses/clarifies.

 

To break it = down in two point response,

 

1) This draft = is not changing how SLA is established at first place. The draft is = providing a method to convey this a priori established SLA to help = reduce lot of manual complexities and errors to admin. Thus given a = knowledge of what SLA is established, in general devices should be = capable to support that = established SLA.

 

 

2) If there = still are any issues in implementing exchanged SLA in forwarding, we = think they either are implementation specific or of temporary = nature where for example enough resources not available at any specific = point of a time.

 

We feel that in = current state of the draft, it can be largely useful in = deployments.

 

 

 

One can imagine = though even establishment of SLA also can be done via exchanging it = over bgp. However, negotiation of SLA does not have to be clubbed with = exchange of SLA. Negotiation of SLA is not in this = scope.

 

Regards,

Shitanshu

 

From: Susan Hares <shares@ndzh.com>
Sent: = Saturday, March 4, 2017 8:31 AM
To: 'Ron Bonica'; 'Shitanshu = Shah'; rtg-dir@ietf.org; draft-ietf-idr-s= la-exchange.all@ietf.org; idr@ietf.org
Subject: RE: = [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 =

 

Shitanshu:

 

Please address Ron’s comment about widely deployed.  I = believe this was part of Alvaro’s comments.

 

Sue

 

 

Hello,

 

The draft is internally consistent. But given what is left out of = scope, I wonder if the new attributes will ever be widely = deployed.

 

           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;       Ron

 

 


This document might benefit from discussion of operational issues. = I assume that when a BGP listener learns a route with the SLA Exchange = Attribute, it provisions class of service forwarding classes on = interfaces.

 

##svsha= h, though this is one desired use of exchanging SLA content, the draft = focuses on transporting SLA content from the SLA Producer to the SLA = Consumer. Processing of the QoS attribute content, at the SLA Consumer, = is outside the scope of this document.

 <= /span>

##svsha= h, Let me know if you have a suggestion to make description clearer in = Section 1 and 2 to highlight this.

 

 

I also assume that a) it takes time to provision class of service = forwarding classes and b) the number of forwarding classes that can be = provisioned are finite. What does the BGP listener do when the number of = forwarding classes requested exceeds its capacity to = deliver? 

 

##svsha= h, Since scope of the document is to transport SLA content from the SLA = Producer to the SLA Consumer, the document considers error handling in = the context of transporting data and thus any formating errors and = semantics errors within that context. Any errors in the context of = processing QoS attribute content at the SLA Consumer is outside the = scope of the document.

 <= /span>

 

 

------=_NextPart_000_00B5_01D2966C.2912FBB0-- From nobody Mon Mar 6 12:22:30 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 450811299DC; Mon, 6 Mar 2017 12:22:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QHheRA5HjUQb; Mon, 6 Mar 2017 12:22:27 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4923A1299D4; Mon, 6 Mar 2017 12:22:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8087; q=dns/txt; s=iport; t=1488831747; x=1490041347; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=Pcn3JSPRew81HgSzQJQJNuTYjE8bDScpuUiyQVbb4ok=; b=a14onAHCG9upVHMuaUingN+0vWmjPauQkHUroAjGbG0Rwae+6p6ZkeKl HoPJ5/OqxEqoNkuK/vD01ox0GyvVZqdQN/stKZmArHb42tTZU9OKidaGp SY+YFBVcf1BNHao1Bpcn8gq62muaD8ScHpTeNdQa3tV++KJ0Wq+jhSiDw 0=; X-IronPort-AV: E=Sophos;i="5.35,255,1484006400"; d="scan'208";a="393350929" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Mar 2017 20:22:26 +0000 Received: from [10.41.60.248] ([10.41.60.248]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v26KMPbj001853; Mon, 6 Mar 2017 20:22:25 GMT To: Jeffrey Haas , "Alvaro Retana (aretana)" References: <20170228210627.GB17448@pfrc.org> From: Enke Chen Message-ID: <3eb4d853-1d44-6250-c70a-26f60eac39e6@cisco.com> Date: Mon, 6 Mar 2017 12:22:24 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <20170228210627.GB17448@pfrc.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "idr-chairs@ietf.org" , "draft-ietf-idr-bgp-extended-messages@ietf.org" , Susan Hares , "idr@ietf.org" Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 20:22:29 -0000 Hi, Folks: I see benefits and no drawbacks for the "BGP-Extended Message Capability" to cover all the message types, that is, requiring a speaker that advertises the capability to be able to receiving large messages of any type. While the requirement for the large message is driven by the UPDATE message, other messages (such as NOTIFICATION or OPEN) can potentially exceed the 4K message size as well. It is better to deal with this issue once. Clearly a large UPDATE message may require a large NOTIFICATION message, e.g., for carrying a malformed attribute. Regarding the OPEN message, as BGP capabilities are carried inside the OPEN message and a number of capabilities are AFI/SAFI specific and thus have the "multiplier" effect on the message size, potentially the OPEN message may exceed the message size in the future. This "extended message capability" can be used in a couple of ways to deal with the large OPEN message if the capability is made to mean support for all message types: o A speaker can remember the capability from its previous OPEN, and infer that the large message is most likely supported over the current session, and send the large OPEN message if needed. (It can back off from sending the large OPEN based on NOTIFICATION message.) o A speaker can send a normal OPEN, and once it determines from the received OPEN message that the large message capability is supported by the remote speaker, the speaker can close the connection and start with a large OPEN. Admittedly these mechanism are not as elegant as the one that bumps the BGP version. They can be just as effective (especially the first one) in practice. Thanks. -- Enke On 2/28/17 1:06 PM, Jeffrey Haas wrote: > Alvaro, > > I'm not speaking for the authors. However, a few comments on your writeup: > > On Thu, Feb 23, 2017 at 07:17:05PM +0000, Alvaro Retana (aretana) wrote: >> M1. Section 4. (Operation): “An implementation that supports the BGP >> Extended Messages MUST be prepared to receive an UPDATE message that is >> larger than 4096 bytes.“ Only UPDATEs? I know that the most likely case >> for exceeding the 4k size is an UPDATE, but why are the other messages not >> considered? > > The fundamental issue is with regards to not only the basic behavior of RFC 4271 > and its earlier RFC 1771 but also to BGP Versioning. > > Those RFCs set the expectation that version 4 of BGP will have at most a 4k > packet size. Capability advertisement, an extension on top of BGP, isn't a > required feature - although it's certainly very common these days. > > Thus, for backward compatibility reasons, OPEN messages must be no bigger > than 4k if we're still BGP-4. > > I don't think there's an argument for larger KEEPALIVE messages. :-) > > Similarly, the NOTIFICATION with no restrictions for version compatibility > reasons. *However*, once BGP has reached the Established state, it is > possible for it to send longer NOTIFICATION messages, if we permitted it and > the feature was duly negotiated. This is probably not the best idea because > it will still be necessary to be able to deal with an old speaker in such > cases. > > Also, most implementations don't dump that much information in the > NOTIFICATION Data section. Putting sufficient semantics on the content > would start to get messy. We don't want XML or backtrace over that message. > > The case for UPDATE is clear. > > The remaining message with some potential motivation is ROUTE-REFRESH. The > basic refresh message is likely to be able to hold AFI/SAFI sets for some > time. The ORF feature that is built upon refresh already deals with sending > its filters over the course of multiple messages. So, there's not a lot of > motivation. > > And that's the messages we have so far. While I can see new messages being > defined that may want it, I don't think there's a strong argument for it > today. > >> Also, what does “prepared to receive” >> mean, and how can “MUST be prepared to receive” be enforced? Given the >> discussion in Section 5 (Error Handling), you might want to add something >> like “…even if the Capability is not advertised”. > > If the capability hasn't been negotiated, then the expectation is that it's > a PDU error and the session should be dropped. See prior comments about BGP > versioning. > >> M2. Section 5 (Error Handling). “A BGP speaker that has the ability to >> use extended messages but has not advertised the BGP Extended Messages >> capability, presumably due to configuration, SHOULD NOT accept an extended >> message. A speaker MAY implement a more liberal policy and accept >> extended messages even from a peer that has not advertised the >> capability.” This paragraph troubles me a lot because it is in direct >> contraction with Section 3: “A peer which does not advertise this >> capability MUST NOT send BGP Extended Messages, and BGP Extended Messages >> MUST NOT be sent to it.”. However, I think that John Scudder’s reasoning >> [3] makes sense ("keep the session up at (almost) all costs", and there’s >> clear precedence in the WG) for the case where the sender did advertise >> the Capability, but I’m not convinced on the case where it didn’t – please >> include something like John’s explanation in the text. > > John can own this one. I find the case a little weaker. It vaguely makes > me want a probe message to verify that I can indeed get a full-sized PDU > through. > >> M5. Section 5 (Error Handling). “The inconsistency between the local and >> remote BGP speakers MUST be reported via syslog and/or SNMP.” SNMP? >> AFAIK, there’s no object that can report this inconsistency since there’s >> no NOTIFICATION generated. In the proposed text by Gunter Van De Velde >> [4], SNMP and syslog were mentioned as examples – I suggest you follow >> that path (no need for all the “flowery language”) and just reference >> mechanisms by example to avoid having to point at how it would be done. > > IMO, "brought to the attention of the operator. Example mechanisms might > include syslog or SNMP notifications." > > While you're correct that no IETF standard MIB object covers such a > scenario, we shouldn't be proscriptive about some vendor deciding they want > it in their enterprise implementation. > > At some point, we need similar boilerplate language for yang notifications. > >> M7. What about transition/migration/partial deployment? What should the >> behavior be if, for example, an Extended Message UPDATE is received from a >> peer, but can’t be propagated to others because they don’t support >> Extended Messages (think route reflectors or simple eBGP -> iBGP)?? There >> should be some guidance for the general case (i.e. when the total size is >>> 4k due simply to the total amount of information, and not because a >> single attribute, for example, is really big), and some requirements >> looking forward to potential new messages/attributes that specifically >> rely on Extended Messages. > > I'm not sure such guidance belongs in this document. We already have > scenarios wherein normal protocol machinery can result in messages that are > too large. The expected behavior is "treat as withdraw" to the next > downstream, similar to the BGP Error handling RFC. > > Examples of this include AS_PATH or CLUSTER_LIST attributes needing to add a > new entry on a full PDU. > >> M7.2. What should the default be for this extension? Should it be enabled by default or not? > > IMO, there are good reasons to not turn it on for existing BGP deployments > but alternatively good reasons once the extension is widely enough present > in a given topology. The latter example includes bgpsec. > > -- Jeff > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > From nobody Mon Mar 6 16:44:58 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91B2F12941C; Mon, 6 Mar 2017 16:44:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W8UNRY6kxZAm; Mon, 6 Mar 2017 16:44:54 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 8A0E7126579; Mon, 6 Mar 2017 16:44:54 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.90.29; From: "Susan Hares" To: "'Enke Chen'" , "'Jeffrey Haas'" , "'Alvaro Retana \(aretana\)'" References: <20170228210627.GB17448@pfrc.org> <3eb4d853-1d44-6250-c70a-26f60eac39e6@cisco.com> In-Reply-To: <3eb4d853-1d44-6250-c70a-26f60eac39e6@cisco.com> Date: Mon, 6 Mar 2017 19:39:54 -0500 Message-ID: <006c01d296db$578601d0$06920570$@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: AQInnAj+Yxa8tap/yfCJFXAjQYwk1wJi0XFfAwzFclWgsvROwA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: idr-chairs@ietf.org, draft-ietf-idr-bgp-extended-messages@ietf.org, idr@ietf.org Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 00:44:56 -0000 Enke:=20 =20 This reply is being a bit specific about RFC4271. You may have implied = all of this in your message, but after the AD's comments on this draft I = think it is best to be specific on the BGP FSM on RFC4271. =20 According to RFC4271, the event which is generated when a BGP packet is = received by a peer with a message size over 4096 is BGP Header Error = event (event 21). It does not matter which BGP message generates this = error. Therefore, the extended BGP message specification ( version = -21) could handle the OPEN message if the following text was changed:=20 Old/ [RFC4271] states "The value of the Length field MUST always be at least 19 and no greater than 4096." This document changes the latter number to 65535 for UPDATE messages. [RFC4271] Sec 6.1, specifies raising an error if the length of a message is over 4096 octets. For UPDATE messages, if the receiver has advertised the capability to receive Extended Messages, this document raises that limit to 65535. /=20 New /=20 [RFC4271] states "The value of the Length field MUST always be at least 19 and no greater than 4096." This document changes the latter number to 65535 for BGP messages. [RFC4271] Sec 6.1, specifies raising an error if the length of a message is over 4096 octets. For BGP messages, if the receiver is configured to be a BGP speaker to be an Extended Message speaker, = this document raises that limit to 65535. / =20 Randy may be indicating the problem of=20 TCP connection comes up=20 BGP-speaker 1 (Extended size OPEN ) ---> =20 <---BGP speaker 2 (only supports = normal OPEN)=20 But wants to indicate that the = EXTENDED OPEN is bad.=20 This is actually handled in the current BGP FSM by using the = SENDNOTIFICATIONwithoutOPEN attribute set to TRUE. The BGP speaker2 = with this option does the following=20 BGP-speaker 1 (Extended size open) --->=20 <-------BGP speaker 2: NOTIFICATION: = HEADER ERR, Message Length Error.=20 You can find this on p. 56 of RFC4271, see Event 21 (BGP message Header = Error) with the following text:=20 " If BGP message header checking (Event 21) or OPEN message = checking detects an error (Event 22) (see Section 6.2), the local system: - (optionally) If the SendNOTIFICATIONwithoutOPEN attribute is set to TRUE, then the local system first sends a NOTIFICATION message with the appropriate error code, and then - stops the ConnectRetryTimer (if running) and sets the ConnectRetryTimer to zero, - releases all BGP resources, - drops the TCP connection, - increments the ConnectRetryCounter by 1, - (optionally) performs peer oscillation damping if the DampPeerOscillations attribute is set to TRUE, and - changes its state to Idle. Note, if the SENDNOTIFICATIONwithoutOpen Attribute is set, then the = error code will provide Bad Message Header, sub-code: Bad message = length. With this notification, the BGP speaker sending the OPEN with = the extended message can have a pretty understanding of what happened. = If the BGP speaker receives this message in response to an oversize = open, it would be prudent for the BGP implementation to send a BGP Open = (with/without the capability that advertises the extended message).=20 If you do use the extended message capability, the scenario might go BGP peer-1 BGP peer-2=20 Capable of not capable of=20 Extended msg extended msg BGP Open (Extended message) ----->=20 <---- BGP notification (BGP Message = header error, Bad message length)=20 BGP open (normal, Extended message capability)----> =20 <--- BGP Open (normal, [no extended message capability)=20 BGP open (normal, [no extended message capability]---->=20 =20 With the SENDNOTIFICATIONwithoutOpen Attribute, I do not see how Randy = gets into an open-loop. I'm sure Randy will let me know if I've missed = something in the scenario he's suggesting.=20 Sue Hares -----Original Message----- From: Enke Chen [mailto:enkechen@cisco.com]=20 Sent: Monday, March 6, 2017 3:22 PM To: Jeffrey Haas; Alvaro Retana (aretana) Cc: idr-chairs@ietf.org; draft-ietf-idr-bgp-extended-messages@ietf.org; = Susan Hares; idr@ietf.org; Enke Chen Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20 Hi, Folks: I see benefits and no drawbacks for the "BGP-Extended Message = Capability" to cover all the message types, that is, requiring a speaker = that advertises the capability to be able to receiving large messages of = any type. While the requirement for the large message is driven by the = UPDATE message, other messages (such as NOTIFICATION or OPEN) can = potentially exceed the 4K message size as well. It is better to deal = with this issue once. Clearly a large UPDATE message may require a large NOTIFICATION message, = e.g., for carrying a malformed attribute. Regarding the OPEN message, as BGP capabilities are carried inside the = OPEN message and a number of capabilities are AFI/SAFI specific and thus = have the "multiplier" effect on the message size, potentially the OPEN message may exceed the = message size in the future. This "extended message capability" can be = used in a couple of ways to deal with the large OPEN message if the = capability is made to mean support for all message types: o A speaker can remember the capability from its previous OPEN, and = infer that the large message is most likely supported over the current = session, and send the large OPEN message if needed. (It can back off from sending the = large OPEN based on NOTIFICATION message.) o A speaker can send a normal OPEN, and once it determines from the = received OPEN message that the large message capability is supported by the = remote speaker, the speaker can close the connection and start with a = large OPEN. Admittedly these mechanism are not as elegant as the one that bumps the = BGP version. They can be just as effective (especially the first one) in practice. Thanks. -- Enke On 2/28/17 1:06 PM, Jeffrey Haas wrote: > Alvaro, >=20 > I'm not speaking for the authors. However, a few comments on your = writeup: >=20 > On Thu, Feb 23, 2017 at 07:17:05PM +0000, Alvaro Retana (aretana) = wrote: >> M1. Section 4. (Operation): =E2=80=9CAn implementation that supports = the BGP=20 >> Extended Messages MUST be prepared to receive an UPDATE message that=20 >> is larger than 4096 bytes.=E2=80=9C Only UPDATEs? I know that the = most=20 >> likely case for exceeding the 4k size is an UPDATE, but why are the=20 >> other messages not considered? >=20 > The fundamental issue is with regards to not only the basic behavior=20 > of RFC 4271 and its earlier RFC 1771 but also to BGP Versioning. >=20 > Those RFCs set the expectation that version 4 of BGP will have at most = > a 4k packet size. Capability advertisement, an extension on top of=20 > BGP, isn't a required feature - although it's certainly very common = these days. >=20 > Thus, for backward compatibility reasons, OPEN messages must be no=20 > bigger than 4k if we're still BGP-4. >=20 > I don't think there's an argument for larger KEEPALIVE messages. :-) >=20 > Similarly, the NOTIFICATION with no restrictions for version=20 > compatibility reasons. *However*, once BGP has reached the=20 > Established state, it is possible for it to send longer NOTIFICATION=20 > messages, if we permitted it and the feature was duly negotiated. =20 > This is probably not the best idea because it will still be necessary=20 > to be able to deal with an old speaker in such cases. >=20 > Also, most implementations don't dump that much information in the=20 > NOTIFICATION Data section. Putting sufficient semantics on the=20 > content would start to get messy. We don't want XML or backtrace over = that message. >=20 > The case for UPDATE is clear. >=20 > The remaining message with some potential motivation is ROUTE-REFRESH. = =20 > The basic refresh message is likely to be able to hold AFI/SAFI sets=20 > for some time. The ORF feature that is built upon refresh already=20 > deals with sending its filters over the course of multiple messages. =20 > So, there's not a lot of motivation. >=20 > And that's the messages we have so far. While I can see new messages=20 > being defined that may want it, I don't think there's a strong=20 > argument for it today. >=20 >> Also, what does =E2=80=9Cprepared to receive=E2=80=9D >> mean, and how can =E2=80=9CMUST be prepared to receive=E2=80=9D be = enforced? Given=20 >> the discussion in Section 5 (Error Handling), you might want to add=20 >> something like =E2=80=9C=E2=80=A6even if the Capability is not = advertised=E2=80=9D. >=20 > If the capability hasn't been negotiated, then the expectation is that = > it's a PDU error and the session should be dropped. See prior=20 > comments about BGP versioning. >=20 >> M2. Section 5 (Error Handling). =E2=80=9CA BGP speaker that has the = ability=20 >> to use extended messages but has not advertised the BGP Extended=20 >> Messages capability, presumably due to configuration, SHOULD NOT=20 >> accept an extended message. A speaker MAY implement a more liberal=20 >> policy and accept extended messages even from a peer that has not=20 >> advertised the capability.=E2=80=9D This paragraph troubles me a lot = because=20 >> it is in direct contraction with Section 3: =E2=80=9CA peer which = does not=20 >> advertise this capability MUST NOT send BGP Extended Messages, and=20 >> BGP Extended Messages MUST NOT be sent to it.=E2=80=9D. However, I = think=20 >> that John Scudder=E2=80=99s reasoning [3] makes sense ("keep the = session up=20 >> at (almost) all costs", and there=E2=80=99s clear precedence in the = WG) for=20 >> the case where the sender did advertise the Capability, but = I=E2=80=99m not=20 >> convinced on the case where it didn=E2=80=99t =E2=80=93 please = include something like John=E2=80=99s explanation in the text. >=20 > John can own this one. I find the case a little weaker. It vaguely=20 > makes me want a probe message to verify that I can indeed get a=20 > full-sized PDU through. >=20 >> M5. Section 5 (Error Handling). =E2=80=9CThe inconsistency between = the local and >> remote BGP speakers MUST be reported via syslog and/or SNMP.=E2=80=9D = SNMP? >> AFAIK, there=E2=80=99s no object that can report this inconsistency = since=20 >> there=E2=80=99s no NOTIFICATION generated. In the proposed text by = Gunter=20 >> Van De Velde [4], SNMP and syslog were mentioned as examples = =E2=80=93 I=20 >> suggest you follow that path (no need for all the =E2=80=9Cflowery = language=E2=80=9D)=20 >> and just reference mechanisms by example to avoid having to point at = how it would be done. >=20 > IMO, "brought to the attention of the operator. Example mechanisms=20 > might include syslog or SNMP notifications." >=20 > While you're correct that no IETF standard MIB object covers such a=20 > scenario, we shouldn't be proscriptive about some vendor deciding they = > want it in their enterprise implementation. >=20 > At some point, we need similar boilerplate language for yang = notifications. >=20 >> M7. What about transition/migration/partial deployment? What should=20 >> the behavior be if, for example, an Extended Message UPDATE is=20 >> received from a peer, but can=E2=80=99t be propagated to others = because they=20 >> don=E2=80=99t support Extended Messages (think route reflectors or = simple=20 >> eBGP -> iBGP)?? There should be some guidance for the general case=20 >> (i.e. when the total size is >>> 4k due simply to the total amount of information, and not because a >> single attribute, for example, is really big), and some requirements=20 >> looking forward to potential new messages/attributes that=20 >> specifically rely on Extended Messages. >=20 > I'm not sure such guidance belongs in this document. We already have=20 > scenarios wherein normal protocol machinery can result in messages=20 > that are too large. The expected behavior is "treat as withdraw" to=20 > the next downstream, similar to the BGP Error handling RFC. >=20 > Examples of this include AS_PATH or CLUSTER_LIST attributes needing to = > add a new entry on a full PDU. >=20 >> M7.2. What should the default be for this extension? Should it be = enabled by default or not? >=20 > IMO, there are good reasons to not turn it on for existing BGP=20 > deployments but alternatively good reasons once the extension is=20 > widely enough present in a given topology. The latter example = includes bgpsec. >=20 > -- Jeff >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >=20 From nobody Mon Mar 6 16:47:27 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAC40129A78; Mon, 6 Mar 2017 16:47:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YORQmYM3RJV3; Mon, 6 Mar 2017 16:47:25 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 40380129644; Mon, 6 Mar 2017 16:47:09 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.90.29; From: "Susan Hares" To: "'Enke Chen'" , "'Jeffrey Haas'" , "'Alvaro Retana \(aretana\)'" References: <20170228210627.GB17448@pfrc.org> <3eb4d853-1d44-6250-c70a-26f60eac39e6@cisco.com> In-Reply-To: <3eb4d853-1d44-6250-c70a-26f60eac39e6@cisco.com> Date: Mon, 6 Mar 2017 19:42:09 -0500 Message-ID: <006e01d296db$a7c4c320$f74e4960$@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: AQInnAj+Yxa8tap/yfCJFXAjQYwk1wJi0XFfAwzFclWgswHrEA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: idr-chairs@ietf.org, draft-ietf-idr-bgp-extended-messages@ietf.org, idr@ietf.org Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 00:47:26 -0000 Enke and IDR WG:=20 =20 If there is enough concern about the extended messages covering all = messages versus UPDATE messages, I will need to do 1 week call on this = topic. =20 =20 Sue Hares=20 -----Original Message----- From: Enke Chen [mailto:enkechen@cisco.com]=20 Sent: Monday, March 6, 2017 3:22 PM To: Jeffrey Haas; Alvaro Retana (aretana) Cc: idr-chairs@ietf.org; draft-ietf-idr-bgp-extended-messages@ietf.org; = Susan Hares; idr@ietf.org; Enke Chen Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20 Hi, Folks: I see benefits and no drawbacks for the "BGP-Extended Message = Capability" to cover all the message types, that is, requiring a speaker = that advertises the capability to be able to receiving large messages of = any type. While the requirement for the large message is driven by the = UPDATE message, other messages (such as NOTIFICATION or OPEN) can = potentially exceed the 4K message size as well. It is better to deal = with this issue once. Clearly a large UPDATE message may require a large NOTIFICATION message, = e.g., for carrying a malformed attribute. Regarding the OPEN message, as BGP capabilities are carried inside the = OPEN message and a number of capabilities are AFI/SAFI specific and thus = have the "multiplier" effect on the message size, potentially the OPEN message may exceed the = message size in the future. This "extended message capability" can be = used in a couple of ways to deal with the large OPEN message if the = capability is made to mean support for all message types: o A speaker can remember the capability from its previous OPEN, and = infer that the large message is most likely supported over the current = session, and send the large OPEN message if needed. (It can back off from sending the = large OPEN based on NOTIFICATION message.) o A speaker can send a normal OPEN, and once it determines from the = received OPEN message that the large message capability is supported by the = remote speaker, the speaker can close the connection and start with a = large OPEN. Admittedly these mechanism are not as elegant as the one that bumps the = BGP version. They can be just as effective (especially the first one) in practice. Thanks. -- Enke On 2/28/17 1:06 PM, Jeffrey Haas wrote: > Alvaro, >=20 > I'm not speaking for the authors. However, a few comments on your = writeup: >=20 > On Thu, Feb 23, 2017 at 07:17:05PM +0000, Alvaro Retana (aretana) = wrote: >> M1. Section 4. (Operation): =E2=80=9CAn implementation that supports = the BGP=20 >> Extended Messages MUST be prepared to receive an UPDATE message that=20 >> is larger than 4096 bytes.=E2=80=9C Only UPDATEs? I know that the = most=20 >> likely case for exceeding the 4k size is an UPDATE, but why are the=20 >> other messages not considered? >=20 > The fundamental issue is with regards to not only the basic behavior=20 > of RFC 4271 and its earlier RFC 1771 but also to BGP Versioning. >=20 > Those RFCs set the expectation that version 4 of BGP will have at most = > a 4k packet size. Capability advertisement, an extension on top of=20 > BGP, isn't a required feature - although it's certainly very common = these days. >=20 > Thus, for backward compatibility reasons, OPEN messages must be no=20 > bigger than 4k if we're still BGP-4. >=20 > I don't think there's an argument for larger KEEPALIVE messages. :-) >=20 > Similarly, the NOTIFICATION with no restrictions for version=20 > compatibility reasons. *However*, once BGP has reached the=20 > Established state, it is possible for it to send longer NOTIFICATION=20 > messages, if we permitted it and the feature was duly negotiated. =20 > This is probably not the best idea because it will still be necessary=20 > to be able to deal with an old speaker in such cases. >=20 > Also, most implementations don't dump that much information in the=20 > NOTIFICATION Data section. Putting sufficient semantics on the=20 > content would start to get messy. We don't want XML or backtrace over = that message. >=20 > The case for UPDATE is clear. >=20 > The remaining message with some potential motivation is ROUTE-REFRESH. = =20 > The basic refresh message is likely to be able to hold AFI/SAFI sets=20 > for some time. The ORF feature that is built upon refresh already=20 > deals with sending its filters over the course of multiple messages. =20 > So, there's not a lot of motivation. >=20 > And that's the messages we have so far. While I can see new messages=20 > being defined that may want it, I don't think there's a strong=20 > argument for it today. >=20 >> Also, what does =E2=80=9Cprepared to receive=E2=80=9D >> mean, and how can =E2=80=9CMUST be prepared to receive=E2=80=9D be = enforced? Given=20 >> the discussion in Section 5 (Error Handling), you might want to add=20 >> something like =E2=80=9C=E2=80=A6even if the Capability is not = advertised=E2=80=9D. >=20 > If the capability hasn't been negotiated, then the expectation is that = > it's a PDU error and the session should be dropped. See prior=20 > comments about BGP versioning. >=20 >> M2. Section 5 (Error Handling). =E2=80=9CA BGP speaker that has the = ability=20 >> to use extended messages but has not advertised the BGP Extended=20 >> Messages capability, presumably due to configuration, SHOULD NOT=20 >> accept an extended message. A speaker MAY implement a more liberal=20 >> policy and accept extended messages even from a peer that has not=20 >> advertised the capability.=E2=80=9D This paragraph troubles me a lot = because=20 >> it is in direct contraction with Section 3: =E2=80=9CA peer which = does not=20 >> advertise this capability MUST NOT send BGP Extended Messages, and=20 >> BGP Extended Messages MUST NOT be sent to it.=E2=80=9D. However, I = think=20 >> that John Scudder=E2=80=99s reasoning [3] makes sense ("keep the = session up=20 >> at (almost) all costs", and there=E2=80=99s clear precedence in the = WG) for=20 >> the case where the sender did advertise the Capability, but = I=E2=80=99m not=20 >> convinced on the case where it didn=E2=80=99t =E2=80=93 please = include something like John=E2=80=99s explanation in the text. >=20 > John can own this one. I find the case a little weaker. It vaguely=20 > makes me want a probe message to verify that I can indeed get a=20 > full-sized PDU through. >=20 >> M5. Section 5 (Error Handling). =E2=80=9CThe inconsistency between = the local and >> remote BGP speakers MUST be reported via syslog and/or SNMP.=E2=80=9D = SNMP? >> AFAIK, there=E2=80=99s no object that can report this inconsistency = since=20 >> there=E2=80=99s no NOTIFICATION generated. In the proposed text by = Gunter=20 >> Van De Velde [4], SNMP and syslog were mentioned as examples = =E2=80=93 I=20 >> suggest you follow that path (no need for all the =E2=80=9Cflowery = language=E2=80=9D)=20 >> and just reference mechanisms by example to avoid having to point at = how it would be done. >=20 > IMO, "brought to the attention of the operator. Example mechanisms=20 > might include syslog or SNMP notifications." >=20 > While you're correct that no IETF standard MIB object covers such a=20 > scenario, we shouldn't be proscriptive about some vendor deciding they = > want it in their enterprise implementation. >=20 > At some point, we need similar boilerplate language for yang = notifications. >=20 >> M7. What about transition/migration/partial deployment? What should=20 >> the behavior be if, for example, an Extended Message UPDATE is=20 >> received from a peer, but can=E2=80=99t be propagated to others = because they=20 >> don=E2=80=99t support Extended Messages (think route reflectors or = simple=20 >> eBGP -> iBGP)?? There should be some guidance for the general case=20 >> (i.e. when the total size is >>> 4k due simply to the total amount of information, and not because a >> single attribute, for example, is really big), and some requirements=20 >> looking forward to potential new messages/attributes that=20 >> specifically rely on Extended Messages. >=20 > I'm not sure such guidance belongs in this document. We already have=20 > scenarios wherein normal protocol machinery can result in messages=20 > that are too large. The expected behavior is "treat as withdraw" to=20 > the next downstream, similar to the BGP Error handling RFC. >=20 > Examples of this include AS_PATH or CLUSTER_LIST attributes needing to = > add a new entry on a full PDU. >=20 >> M7.2. What should the default be for this extension? Should it be = enabled by default or not? >=20 > IMO, there are good reasons to not turn it on for existing BGP=20 > deployments but alternatively good reasons once the extension is=20 > widely enough present in a given topology. The latter example = includes bgpsec. >=20 > -- Jeff >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >=20 From nobody Mon Mar 6 18:59:13 2017 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C6E0E129A9E; Mon, 6 Mar 2017 18:59:12 -0800 (PST) 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.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148885555280.15065.2328508985523811792.idtracker@ietfa.amsl.com> Date: Mon, 06 Mar 2017 18:59:12 -0800 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-route-leak-detection-mitigation-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 02:59:13 -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 of the IETF. Title : Methods for Detection and Mitigation of BGP Route Leaks Authors : Kotikalapudi Sriram Doug Montgomery Brian Dickson Keyur Patel Andrei Robachevsky Filename : draft-ietf-idr-route-leak-detection-mitigation-06.txt Pages : 24 Date : 2017-03-06 Abstract: RFC 7908 provides a definition of the route leak problem, and also enumerates several types of route leaks. This document first examines which of those route-leak types are detected and mitigated by the existing origin validation (OV) [RFC 6811]. It is recognized that OV offers a limited detection and mitigation capability against route leaks. This document specifies enhancements that significantly extend the route-leak prevention, detection, and mitigation capabilities of BGP. One solution component involves intra-AS messaging from ingress router to egress router using a BGP Community or Attribute. This intra-AS messaging prevents the AS from causing route leaks. Another solution component involves carrying a per-hop route-leak protection (RLP) field in BGP updates. The RLP fields are proposed to be carried in a new optional transitive attribute, called BGP RLP attribute. The RLP attribute helps with detection and mitigation of route leaks at ASes downstream from the leaking AS. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-route-leak-detection-mitigation/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-route-leak-detection-mitigation-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-route-leak-detection-mitigation-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 Mar 6 19:31:52 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9872129AC7 for ; Mon, 6 Mar 2017 19:31:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.947 X-Spam-Level: X-Spam-Status: No, score=0.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-l-aO073Q7Y for ; Mon, 6 Mar 2017 19:31:49 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 5F554129ABA for ; Mon, 6 Mar 2017 19:31:49 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=70.194.16.251; From: "Susan Hares" To: Date: Mon, 6 Mar 2017 22:26:47 -0500 Message-ID: <00c501d296f2$a7a0c8f0$f6e25ad0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C6_01D296C8.BECB3620" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdKW8TLVqllJkcvhQbeGPXZzhGF0pw== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Hannes Gredler' Subject: [Idr] 2 Week WG LC for draft-ietf-idr-bgp-prefix-sid-04.txt - 3/6 to 3/20/2017 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 03:31:50 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00C6_01D296C8.BECB3620 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This message begins a 2 week WG LC for draft-ietf-idr-bgp-prefix-sid-04.txt (3/6 to 3/20). This draft proposed a new optional, transitive BGP path attribute, the BGP Prefix Segment attribute to carry BGP Prefix Segment Identifier (BGP Prefix SID) information for: Label-Index, IPv6 SID, and Originator SRGB. This draft is linked to work on DC segment routing describe draft-ietf-spring-segment-routing-msdc-03.txt. We have one remaining author (Arjun Sreekantiah) has not responded to the IPR call, but it is likely he will respond shortly. If Arun does not respond to the IPR call during the first week, this WG LC will be extended for 1 additional week. Three implementations exist and the details are on the web site, and in the draft: https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-prefix-sid%20implemen tations Sue Hares ------=_NextPart_000_00C6_01D296C8.BECB3620 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This = message begins a 2 week WG LC for draft-ietf-idr-bgp-prefix-sid-04.txt = (3/6 to 3/20).   

 

This draft = proposed a new optional, transitive BGP path  attribute, the BGP = Prefix Segment attribute to carry BGP Prefix Segment Identifier (BGP = Prefix SID) information for:   Label-Index, IPv6 SID, and = Originator SRGB.  This draft is linked to work on DC segment = routing describe draft-ietf-spring-segment-routing-msdc-03.txt. =

 

We have one remaining author (Arjun Sreekantiah) has = not responded to the IPR call, but it is likely he will respond = shortly.  If Arun does not respond to the IPR call during the first = week, this WG LC will be extended for 1 additional week.  =

 

Three implementations exist and the details are on the = web site, and in the draft:

https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bg= p-prefix-sid%20implementations

 

 

Sue Hares =

------=_NextPart_000_00C6_01D296C8.BECB3620-- From nobody Mon Mar 6 19:45:49 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 973B9128BA2; Mon, 6 Mar 2017 19:45:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rKwVqoNnyf7q; Mon, 6 Mar 2017 19:45:45 -0800 (PST) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0136.outbound.protection.outlook.com [23.103.201.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 B61F312706D; Mon, 6 Mar 2017 19:45:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=P9cIF0soAOiPFw3nFF7no3R2RwFG0qYFdB3YsCo0KQo=; b=hcSyfAKt0bj0fMskVM9698SbmMnU9fRc5PwrkwxKMTAijKyG+/6dmmZqQljzFpd9FpM06Ot97NiL/n2ELIzifHMmfE5MIRUXvR2HiamHPKnyv4NJIUej0WiecVdsrHI/e34v/DJoVuA1mOPlY77MmAWKr94Wt/1pNCSfQm+szY0= Received: from DM2PR09MB0446.namprd09.prod.outlook.com (10.161.252.145) by DM2PR09MB0447.namprd09.prod.outlook.com (10.161.252.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.12; Tue, 7 Mar 2017 03:35:41 +0000 Received: from DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) by DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) with mapi id 15.01.0947.020; Tue, 7 Mar 2017 03:35:41 +0000 From: "Sriram, Kotikalapudi (Fed)" To: IDR Thread-Topic: New Version Notification for draft-ietf-idr-route-leak-detection-mitigation-06.txt Thread-Index: AQHSlu7P5Kft+0ekvk2MFAsD/mD0OqGItr2o Date: Tue, 7 Mar 2017 03:35:41 +0000 Message-ID: References: <148885555293.15065.2709695938640044668.idtracker@ietfa.amsl.com> In-Reply-To: <148885555293.15065.2709695938640044668.idtracker@ietfa.amsl.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;ietf.org; dmarc=none action=none header.from=nist.gov; x-originating-ip: [129.6.218.70] x-ms-office365-filtering-correlation-id: 13691988-8a3e-4199-e9da-08d4650b07ff x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:DM2PR09MB0447; x-microsoft-exchange-diagnostics: 1; DM2PR09MB0447; 7:Gy5hpJfsPF8cPEvAHnGoBGx75Rb6alscQxSPTxan9oVLHFyDoq96BHMGPVBuf7aOjabH/WyIvnZxXBI547ZFRumavX2DrmHZfWUc1hjC7+41Ne9rLynBq2blcjUZqmugW9MMn/GOiwb4ntFNqE/WH2glv5HIrTrPhxJb5CkbS1IcKAuJuRoVURBHmKoYA0G0Z2ltc2o3QG90kwI5XtSMNVzSY4Y8OyPDgDQMMw8YxasrkfAJuGFEbumFQ4mnmrSUQ7subZ+uDjZKkhdvmCxVBX7GBHV818TxXDrvh4j89WBDSYxPMEXzMptfUceay4hsORqNLt2Jrp0VgcqC9qcD2g== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123558025)(20161123560025)(20161123562025)(20161123564025)(20161123555025)(6072148); SRVR:DM2PR09MB0447; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0447; x-forefront-prvs: 0239D46DB6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39410400002)(39860400002)(39840400002)(39850400002)(39450400003)(377454003)(377424004)(8936002)(3660700001)(33656002)(15650500001)(450100001)(2900100001)(3280700002)(3846002)(102836003)(6116002)(66066001)(6436002)(2473003)(229853002)(9686003)(2906002)(6506006)(55016002)(8676002)(81166006)(25786008)(54906002)(99286003)(6306002)(77096006)(189998001)(2950100002)(74316002)(106116001)(6916009)(7736002)(76176999)(7696004)(50986999)(5660300001)(54356999)(86362001)(305945005)(110136004)(38730400002)(230783001)(92566002)(53546006)(53936002)(122556002)(4326008); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0447; H:DM2PR09MB0446.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM 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: 07 Mar 2017 03:35:41.7308 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0447 Archived-At: Cc: "idr-chairs@ietf.org" , "draft-ietf-idr-route-leak-detection-mitigation.authors@ietf.org" Subject: [Idr] Fw: New Version Notification for draft-ietf-idr-route-leak-detection-mitigation-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 03:45:47 -0000 In this version 06 draft, the following sections are new or significantly u= pdated: =20 4. Mechanisms for Prevention, Detection and Mitigation of Route Leaks . . = 6 4.1. Ascertaining Peering Relationship . . . . . . . . . . . . 6 4.2. Prevention of Route Leaks at Local AS: Intra-AS Messaging=85 7 4.2.1. Non-Transitive BGP Community for Intra-AS Messaging =85 7 4.2.2. Non-Transitive BGP pRLP Attribute for Intra-AS Messaging =85= 8 6.5. Per-Hop RLP Field or Single RLP Flag per Update? . . . . 16 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 Section 6.5 has a fresh new illustrated example for understanding=20 comparisons between per-hop RLP Field vs. single RLP Flag per update. Comments welcome. Thanks, Sriram =20 ________________________________________ From: internet-drafts@ietf.org Sent: Monday, March 6, 2017 9:59 PM To: Sriram, Kotikalapudi (Fed); Montgomery, Douglas (Fed); Andrei Robachevs= ky; Brian Dickson; Keyur Patel Subject: New Version Notification for draft-ietf-idr-route-leak-detection-m= itigation-06.txt A new version of I-D, draft-ietf-idr-route-leak-detection-mitigation-06.txt has been successfully submitted by Kotikalapudi Sriram and posted to the IETF repository. Name: draft-ietf-idr-route-leak-detection-mitigation Revision: 06 Title: Methods for Detection and Mitigation of BGP Route Leaks Document date: 2017-03-06 Group: idr Pages: 24 URL: https://www.ietf.org/internet-drafts/draft-ietf-idr-route-l= eak-detection-mitigation-06.txt Status: https://datatracker.ietf.org/doc/draft-ietf-idr-route-leak-= detection-mitigation/ Htmlized: https://tools.ietf.org/html/draft-ietf-idr-route-leak-detec= tion-mitigation-06 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-route-le= ak-detection-mitigation-06 Abstract: RFC 7908 provides a definition of the route leak problem, and also enumerates several types of route leaks. This document first examines which of those route-leak types are detected and mitigated by the existing origin validation (OV) [RFC 6811]. It is recognized that OV offers a limited detection and mitigation capability against route leaks. This document specifies enhancements that significantly extend the route-leak prevention, detection, and mitigation capabilities of BGP. One solution component involves intra-AS messaging from ingress router to egress router using a BGP Community or Attribute. This intra-AS messaging prevents the AS from causing route leaks. Another solution component involves carrying a per-hop route-leak protection (RLP) field in BGP updates. The RLP fields are proposed to be carried in a new optional transitive attribute, called BGP RLP attribute. The RLP attribute helps with detection and mitigation of route leaks at ASes downstream from the leaking AS. From nobody Tue Mar 7 02:08:40 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82341129510; Tue, 7 Mar 2017 02:08:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.368 X-Spam-Level: X-Spam-Status: No, score=-2.368 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.229, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UnnfOocYT9Gs; Tue, 7 Mar 2017 02:08:35 -0800 (PST) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::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 65970129455; Tue, 7 Mar 2017 02:08:35 -0800 (PST) Received: by mail-qk0-x231.google.com with SMTP id y76so67832916qkb.0; Tue, 07 Mar 2017 02:08:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=fBtuiiI7Lx+E8Qh4+9163dSnL2HZw19oIyMeEqkmApQ=; b=M2mdtg5wMpcmJmbhdDssf4ynCaPiqeSbJg9DfTU8H1VeWdFM08wo3CIVs8PqNhVsOD 7Lft9nxyPHeuzeKLeAga84bTL7Ac3oI2ZMwEnOeLUvCdYS0N8wiPTMPtMg7/ikU+Mpth yVHKK0mmYV5IDjcybJZkR+uYaehdgsXszxBArM6w6ISdJBtnhoNYkE9A11svz3D8T+w7 Z19z/N4JId4ZZvNfZOg0PUEcECC1P4j8vzpW+BnDLgSKAt2BJXCjczuO6RAVQVO5IdS+ bnn+d3nPE4sd/U6ppChkGoTU4wqwP36qrCr8f+i6z4XsGAS4ZRLT5nX53HLsNTCQLJSV +vrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=fBtuiiI7Lx+E8Qh4+9163dSnL2HZw19oIyMeEqkmApQ=; b=t+S1hmHKxFP8B7Q0I430U6yKs3qp/KSnYHpyfXyYLmb4pbAfqmqXCIOjTjoqpGJF8H xJJZ0yW7zq3r6gv/HRjve0T3Y+q/keJbPqm8MhKMlSBF0Sb5Qn3apBunDWU7zkMXOZpm hzapCot8LYleqJ7tXNxZc9+rALLh+kJqEn9RKmy4zF0ZqGIENKuqIJ77UAt06feZ8RVq gx31ZspO07HCzqxq8OMYiaB/VcXXLxfdLHq8dms4yTHLVowxWzM6JhGnoy57mbeRENlQ vWVh6koCusc+oPUTJDryXM1DFzBMe0hOUr2kILGS+6svXn/PQrj+XDxZSSsTvJ/ev7Wp 8kyw== X-Gm-Message-State: AMke39niz44MHfcK/u3QmVy2/N0xZoUingm345u79w1+A0y+p8Kqn6i4i5/dpnH76XsbeD9GRfZN2ivV35hASg== X-Received: by 10.55.65.136 with SMTP id o130mr18857752qka.168.1488881314456; Tue, 07 Mar 2017 02:08:34 -0800 (PST) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.140.42.181 with HTTP; Tue, 7 Mar 2017 02:08:33 -0800 (PST) In-Reply-To: <006e01d296db$a7c4c320$f74e4960$@ndzh.com> References: <20170228210627.GB17448@pfrc.org> <3eb4d853-1d44-6250-c70a-26f60eac39e6@cisco.com> <006e01d296db$a7c4c320$f74e4960$@ndzh.com> From: Robert Raszuk Date: Tue, 7 Mar 2017 11:08:33 +0100 X-Google-Sender-Auth: JVF04RYlbLW2WZ6ojsi5ZahDIrk Message-ID: To: Susan Hares , Randy Bush Content-Type: multipart/alternative; boundary=001a11488ce4dc6d5f054a213188 Archived-At: Cc: idr wg , idr-chairs@ietf.org, draft-ietf-idr-bgp-extended-messages@ietf.org Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 10:08:38 -0000 --001a11488ce4dc6d5f054a213188 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Sue, Authors, Current draft says: *"Currently, the Extended Message Capability only applies to UPDATE messages."* I would like to ask authors to change the below restriction to also consider future BGP messages still compliant with RFC4271 RFC. I would therefor propose to extend the above sentence with: *"The Extended Message Capability applies to UPDATE messages as well as if required to any new BGP messages."* - - - I am less concerned in making Extended Message Capability applicable to OPEN or KEEPALIVE messages. IMHO Capabilities from OPEN should be moved to new BGP message (BGP CAPABILITIES MESSAGE) which would by design allow their dynamic nature along the lines of current dynamic capabilities proposal except outside of messing up with OPEN. For NOTIFICATION as Enke already pointed there is good reason for it to be extended. Alternatively a new provision for signalling the errors between peers should be provided in new message (example: BGP OPERATIONAL message). Thx, R. On Tue, Mar 7, 2017 at 1:42 AM, Susan Hares wrote: > Enke and IDR WG: > > If there is enough concern about the extended messages covering all > messages versus UPDATE messages, I will need to do 1 week call on this > topic. > > > Sue Hares > > -----Original Message----- > From: Enke Chen [mailto:enkechen@cisco.com] > Sent: Monday, March 6, 2017 3:22 PM > To: Jeffrey Haas; Alvaro Retana (aretana) > Cc: idr-chairs@ietf.org; draft-ietf-idr-bgp-extended-messages@ietf.org; > Susan Hares; idr@ietf.org; Enke Chen > Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20 > > Hi, Folks: > > I see benefits and no drawbacks for the "BGP-Extended Message Capability" > to cover all the message types, that is, requiring a speaker that > advertises the capability to be able to receiving large messages of any > type. While the requirement for the large message is driven by the UPDAT= E > message, other messages (such as NOTIFICATION or OPEN) can potentially > exceed the 4K message size as well. It is better to deal with this issue > once. > > Clearly a large UPDATE message may require a large NOTIFICATION message, > e.g., for carrying a malformed attribute. > > Regarding the OPEN message, as BGP capabilities are carried inside the > OPEN message and a number of capabilities are AFI/SAFI specific and thus > have the "multiplier" > effect on the message size, potentially the OPEN message may exceed the > message size in the future. This "extended message capability" can be use= d > in a couple of ways to deal with the large OPEN message if the capability > is made to mean support for all message types: > > o A speaker can remember the capability from its previous OPEN, and > infer that > the large message is most likely supported over the current session, > and send > the large OPEN message if needed. (It can back off from sending the > large OPEN > based on NOTIFICATION message.) > > o A speaker can send a normal OPEN, and once it determines from the > received > OPEN message that the large message capability is supported by the > remote > speaker, the speaker can close the connection and start with a large > OPEN. > > Admittedly these mechanism are not as elegant as the one that bumps the > BGP version. > They can be just as effective (especially the first one) in practice. > > Thanks. -- Enke > > On 2/28/17 1:06 PM, Jeffrey Haas wrote: > > Alvaro, > > > > I'm not speaking for the authors. However, a few comments on your > writeup: > > > > On Thu, Feb 23, 2017 at 07:17:05PM +0000, Alvaro Retana (aretana) wrote= : > >> M1. Section 4. (Operation): =E2=80=9CAn implementation that supports t= he BGP > >> Extended Messages MUST be prepared to receive an UPDATE message that > >> is larger than 4096 bytes.=E2=80=9C Only UPDATEs? I know that the mo= st > >> likely case for exceeding the 4k size is an UPDATE, but why are the > >> other messages not considered? > > > > The fundamental issue is with regards to not only the basic behavior > > of RFC 4271 and its earlier RFC 1771 but also to BGP Versioning. > > > > Those RFCs set the expectation that version 4 of BGP will have at most > > a 4k packet size. Capability advertisement, an extension on top of > > BGP, isn't a required feature - although it's certainly very common > these days. > > > > Thus, for backward compatibility reasons, OPEN messages must be no > > bigger than 4k if we're still BGP-4. > > > > I don't think there's an argument for larger KEEPALIVE messages. :-) > > > > Similarly, the NOTIFICATION with no restrictions for version > > compatibility reasons. *However*, once BGP has reached the > > Established state, it is possible for it to send longer NOTIFICATION > > messages, if we permitted it and the feature was duly negotiated. > > This is probably not the best idea because it will still be necessary > > to be able to deal with an old speaker in such cases. > > > > Also, most implementations don't dump that much information in the > > NOTIFICATION Data section. Putting sufficient semantics on the > > content would start to get messy. We don't want XML or backtrace over > that message. > > > > The case for UPDATE is clear. > > > > The remaining message with some potential motivation is ROUTE-REFRESH. > > The basic refresh message is likely to be able to hold AFI/SAFI sets > > for some time. The ORF feature that is built upon refresh already > > deals with sending its filters over the course of multiple messages. > > So, there's not a lot of motivation. > > > > And that's the messages we have so far. While I can see new messages > > being defined that may want it, I don't think there's a strong > > argument for it today. > > > >> Also, what does =E2=80=9Cprepared to receive=E2=80=9D > >> mean, and how can =E2=80=9CMUST be prepared to receive=E2=80=9D be enf= orced? Given > >> the discussion in Section 5 (Error Handling), you might want to add > >> something like =E2=80=9C=E2=80=A6even if the Capability is not adverti= sed=E2=80=9D. > > > > If the capability hasn't been negotiated, then the expectation is that > > it's a PDU error and the session should be dropped. See prior > > comments about BGP versioning. > > > >> M2. Section 5 (Error Handling). =E2=80=9CA BGP speaker that has the a= bility > >> to use extended messages but has not advertised the BGP Extended > >> Messages capability, presumably due to configuration, SHOULD NOT > >> accept an extended message. A speaker MAY implement a more liberal > >> policy and accept extended messages even from a peer that has not > >> advertised the capability.=E2=80=9D This paragraph troubles me a lot = because > >> it is in direct contraction with Section 3: =E2=80=9CA peer which does= not > >> advertise this capability MUST NOT send BGP Extended Messages, and > >> BGP Extended Messages MUST NOT be sent to it.=E2=80=9D. However, I th= ink > >> that John Scudder=E2=80=99s reasoning [3] makes sense ("keep the sessi= on up > >> at (almost) all costs", and there=E2=80=99s clear precedence in the WG= ) for > >> the case where the sender did advertise the Capability, but I=E2=80=99= m not > >> convinced on the case where it didn=E2=80=99t =E2=80=93 please include= something like > John=E2=80=99s explanation in the text. > > > > John can own this one. I find the case a little weaker. It vaguely > > makes me want a probe message to verify that I can indeed get a > > full-sized PDU through. > > > >> M5. Section 5 (Error Handling). =E2=80=9CThe inconsistency between th= e local > and > >> remote BGP speakers MUST be reported via syslog and/or SNMP.=E2=80=9D = SNMP? > >> AFAIK, there=E2=80=99s no object that can report this inconsistency si= nce > >> there=E2=80=99s no NOTIFICATION generated. In the proposed text by Gu= nter > >> Van De Velde [4], SNMP and syslog were mentioned as examples =E2=80=93= I > >> suggest you follow that path (no need for all the =E2=80=9Cflowery lan= guage=E2=80=9D) > >> and just reference mechanisms by example to avoid having to point at > how it would be done. > > > > IMO, "brought to the attention of the operator. Example mechanisms > > might include syslog or SNMP notifications." > > > > While you're correct that no IETF standard MIB object covers such a > > scenario, we shouldn't be proscriptive about some vendor deciding they > > want it in their enterprise implementation. > > > > At some point, we need similar boilerplate language for yang > notifications. > > > >> M7. What about transition/migration/partial deployment? What should > >> the behavior be if, for example, an Extended Message UPDATE is > >> received from a peer, but can=E2=80=99t be propagated to others becaus= e they > >> don=E2=80=99t support Extended Messages (think route reflectors or sim= ple > >> eBGP -> iBGP)?? There should be some guidance for the general case > >> (i.e. when the total size is > >>> 4k due simply to the total amount of information, and not because a > >> single attribute, for example, is really big), and some requirements > >> looking forward to potential new messages/attributes that > >> specifically rely on Extended Messages. > > > > I'm not sure such guidance belongs in this document. We already have > > scenarios wherein normal protocol machinery can result in messages > > that are too large. The expected behavior is "treat as withdraw" to > > the next downstream, similar to the BGP Error handling RFC. > > > > Examples of this include AS_PATH or CLUSTER_LIST attributes needing to > > add a new entry on a full PDU. > > > >> M7.2. What should the default be for this extension? Should it be > enabled by default or not? > > > > IMO, there are good reasons to not turn it on for existing BGP > > deployments but alternatively good reasons once the extension is > > widely enough present in a given topology. The latter example includes > bgpsec. > > > > -- Jeff > > > > _______________________________________________ > > 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 > --001a11488ce4dc6d5f054a213188 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
= Hi Sue, Authors,

=
Current draft says:=C2=A0

"Cur= rently, the Extended Message Capability only applies to UPDATE messages.&qu= ot;

I would like to ask authors to change the= below restriction to also consider future BGP messages still compliant wit= h RFC4271 RFC. I would therefor propose to extend the above sentence with:<= /font>

"The Extended Message Capabilit= y applies to UPDATE messages as well as if required to any new BGP messages= ."

- - -

I am less concerned in making Extended Message Capability = applicable to OPEN or KEEPALIVE messages. IMHO Capabilities from OPEN shoul= d be moved to new BGP message (BGP CAPABILITIES MESSAGE) which would by des= ign allow their dynamic nature along the lines of current dynamic capabilit= ies proposal except outside of messing up with OPEN.=C2=A0

For NOTIFICATION as Enke already pointed the= re is good reason for it to be extended. Alternatively a new provision for = signalling the errors between peers should be provided in new message (exam= ple: BGP OPERATIONAL message).=C2=A0

=
Thx,
R.






On Tue, Mar 7, 2017 at 1:42 AM, Susan Hares <shares@ndzh.co= m> wrote:
Enke and IDR WG:<= br> <WG chair hat on>
If there is enough concern about the extended messages covering all message= s versus UPDATE messages,=C2=A0 I will need to do=C2=A0 1 week call on this= topic.
<WG Chair hat off>

Sue Hares

-----Original Message-----
From: Enke Chen [mailto:enkechen@cisc= o.com]
Sent: Monday, March 6, 2017 3:22 PM
To: Jeffrey Haas; Alvaro Retana (aretana)
Cc: idr-chairs@ietf.org; draft-ietf-idr-bg= p-extended-messages@ietf.org; Susan Hares; idr@ietf.org; Enke Chen
Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-2= 0

Hi, Folks:

I see benefits and no drawbacks for the "BGP-Extended Message Capabili= ty" to cover all the message types, that is, requiring a speaker that = advertises the capability to be able to receiving large messages of any typ= e.=C2=A0 While the requirement for the large message is driven by the UPDAT= E message, other messages (such as NOTIFICATION or OPEN) can potentially ex= ceed the 4K message size as well. It is better to deal with this issue once= .

Clearly a large UPDATE message may require a large NOTIFICATION message, e.= g., for carrying a malformed attribute.

Regarding the OPEN message, as BGP capabilities are carried inside the OPEN= message and a number of capabilities are AFI/SAFI specific and thus have t= he "multiplier"
effect on the message size, potentially the OPEN message may exceed the mes= sage size in the future. This "extended message capability" can b= e used in a couple of ways to deal with the large OPEN message if the capab= ility is made to mean support for all message types:

=C2=A0 =C2=A0o A speaker can remember the capability from its previous OPEN= , and infer that
=C2=A0 =C2=A0 =C2=A0the large message is most likely supported over the cur= rent session, and send
=C2=A0 =C2=A0 =C2=A0the large OPEN message if needed. (It can back off from= sending the large OPEN
=C2=A0 =C2=A0 =C2=A0based on NOTIFICATION message.)

=C2=A0 =C2=A0o A speaker can send a normal OPEN, and once it determines fro= m the received
=C2=A0 =C2=A0 =C2=A0OPEN message that the large message capability is suppo= rted by the remote
=C2=A0 =C2=A0 =C2=A0speaker, the speaker can close the connection and start= with a large OPEN.

Admittedly these mechanism are not as elegant as the one that bumps the BGP= version.
They can be just as effective (especially the first one) in practice.

Thanks.=C2=A0 -- Enke

On 2/28/17 1:06 PM, Jeffrey Haas wrote:
> Alvaro,
>
> I'm not speaking for the authors.=C2=A0 However, a few comments on= your writeup:
>
> On Thu, Feb 23, 2017 at 07:17:05PM +0000, Alvaro Retana (aretana) wrot= e:
>> M1. Section 4. (Operation): =E2=80=9CAn implementation that suppor= ts the BGP
>> Extended Messages MUST be prepared to receive an UPDATE message th= at
>> is larger than 4096 bytes.=E2=80=9C=C2=A0 Only UPDATEs?=C2=A0 I kn= ow that the most
>> likely case for exceeding the 4k size is an UPDATE, but why are th= e
>> other messages not considered?
>
> The fundamental issue is with regards to not only the basic behavior > of RFC 4271 and its earlier RFC 1771 but also to BGP Versioning.
>
> Those RFCs set the expectation that version 4 of BGP will have at most=
> a 4k packet size.=C2=A0 Capability advertisement, an extension on top = of
> BGP, isn't a required feature - although it's certainly very c= ommon these days.
>
> Thus, for backward compatibility reasons, OPEN messages must be no
> bigger than 4k if we're still BGP-4.
>
> I don't think there's an argument for larger KEEPALIVE message= s. :-)
>
> Similarly, the NOTIFICATION with no restrictions for version
> compatibility reasons.=C2=A0 *However*, once BGP has reached the
> Established state, it is possible for it to send longer NOTIFICATION > messages, if we permitted it and the feature was duly negotiated.
> This is probably not the best idea because it will still be necessary<= br> > to be able to deal with an old speaker in such cases.
>
> Also, most implementations don't dump that much information in the=
> NOTIFICATION Data section.=C2=A0 Putting sufficient semantics on the > content would start to get messy.=C2=A0 We don't want XML or backt= race over that message.
>
> The case for UPDATE is clear.
>
> The remaining message with some potential motivation is ROUTE-REFRESH.=
> The basic refresh message is likely to be able to hold AFI/SAFI sets > for some time.=C2=A0 The ORF feature that is built upon refresh alread= y
> deals with sending its filters over the course of multiple messages. > So, there's not a lot of motivation.
>
> And that's the messages we have so far.=C2=A0 While I can see new = messages
> being defined that may want it, I don't think there's a strong=
> argument for it today.
>
>> Also, what does =E2=80=9Cprepared to receive=E2=80=9D
>> mean, and how can =E2=80=9CMUST be prepared to receive=E2=80=9D be= enforced?=C2=A0 Given
>> the discussion in Section 5 (Error Handling), you might want to ad= d
>> something like =E2=80=9C=E2=80=A6even if the Capability is not adv= ertised=E2=80=9D.
>
> If the capability hasn't been negotiated, then the expectation is = that
> it's a PDU error and the session should be dropped.=C2=A0 See prio= r
> comments about BGP versioning.
>
>> M2. Section 5 (Error Handling).=C2=A0 =E2=80=9CA BGP speaker that = has the ability
>> to use extended messages but has not advertised the BGP Extended >> Messages capability, presumably due to configuration, SHOULD NOT >> accept an extended message.=C2=A0 A speaker MAY implement a more l= iberal
>> policy and accept extended messages even from a peer that has not<= br> >> advertised the capability.=E2=80=9D=C2=A0 This paragraph troubles = me a lot because
>> it is in direct contraction with Section 3: =E2=80=9CA peer which = does not
>> advertise this capability MUST NOT send BGP Extended Messages, and=
>> BGP Extended Messages MUST NOT be sent to it.=E2=80=9D.=C2=A0 Howe= ver, I think
>> that John Scudder=E2=80=99s reasoning [3] makes sense ("keep = the session up
>> at (almost) all costs", and there=E2=80=99s clear precedence = in the WG) for
>> the case where the sender did advertise the Capability, but I=E2= =80=99m not
>> convinced on the case where it didn=E2=80=99t =E2=80=93 please inc= lude something like John=E2=80=99s explanation in the text.
>
> John can own this one.=C2=A0 I find the case a little weaker.=C2=A0 It= vaguely
> makes me want a probe message to verify that I can indeed get a
> full-sized PDU through.
>
>> M5. Section 5 (Error Handling).=C2=A0 =E2=80=9CThe inconsistency b= etween the local and
>> remote BGP speakers MUST be reported via syslog and/or SNMP.=E2=80= =9D=C2=A0 =C2=A0SNMP?
>> AFAIK, there=E2=80=99s no object that can report this inconsistenc= y since
>> there=E2=80=99s no NOTIFICATION generated.=C2=A0 In the proposed t= ext by Gunter
>> Van De Velde [4], SNMP and syslog were mentioned as examples =E2= =80=93 I
>> suggest you follow that path (no need for all the =E2=80=9Cflowery= language=E2=80=9D)
>> and just reference mechanisms by example to avoid having to point = at how it would be done.
>
> IMO, "brought to the attention of the operator.=C2=A0 Example mec= hanisms
> might include syslog or SNMP notifications."
>
> While you're correct that no IETF standard MIB object covers such = a
> scenario, we shouldn't be proscriptive about some vendor deciding = they
> want it in their enterprise implementation.
>
> At some point, we need similar boilerplate language for yang notificat= ions.
>
>> M7. What about transition/migration/partial deployment?=C2=A0 What= should
>> the behavior be if, for example, an Extended Message UPDATE is
>> received from a peer, but can=E2=80=99t be propagated to others be= cause they
>> don=E2=80=99t support Extended Messages (think route reflectors or= simple
>> eBGP -> iBGP)??=C2=A0 There should be some guidance for the gen= eral case
>> (i.e. when the total size is
>>> 4k due simply to the total amount of information, and not beca= use a
>> single attribute, for example, is really big), and some requiremen= ts
>> looking forward to potential new messages/attributes that
>> specifically rely on Extended Messages.
>
> I'm not sure such guidance belongs in this document.=C2=A0 We alre= ady have
> scenarios wherein normal protocol machinery can result in messages
> that are too large.=C2=A0 The expected behavior is "treat as with= draw" to
> the next downstream, similar to the BGP Error handling RFC.
>
> Examples of this include AS_PATH or CLUSTER_LIST attributes needing to=
> add a new entry on a full PDU.
>
>> M7.2. What should the default be for this extension?=C2=A0 Should = it be enabled by default or not?
>
> IMO, there are good reasons to not turn it on for existing BGP
> deployments but alternatively good reasons once the extension is
> widely enough present in a given topology.=C2=A0 The latter example in= cludes bgpsec.
>
> -- Jeff
>
> _______________________________________________
> 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

--001a11488ce4dc6d5f054a213188-- From nobody Tue Mar 7 07:39:54 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01DDF129499; Tue, 7 Mar 2017 06:08:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.947 X-Spam-Level: X-Spam-Status: No, score=0.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nh87dXEIkSzt; Tue, 7 Mar 2017 06:08:15 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 10716129440; Tue, 7 Mar 2017 06:00:55 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.90.29; From: "Susan Hares" To: "'Robert Raszuk'" , "'Randy Bush'" References: <20170228210627.GB17448@pfrc.org> <3eb4d853-1d44-6250-c70a-26f60eac39e6@cisco.com> <006e01d296db$a7c4c320$f74e4960$@ndzh.com> In-Reply-To: Date: Tue, 7 Mar 2017 08:55:45 -0500 Message-ID: <010101d2974a$8520d060$8f627120$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0102_01D29720.9C4D3960" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQInnAj+Yxa8tap/yfCJFXAjQYwk1wJi0XFfAwzFclUBlnEaYAHWMN+roJh6cNA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'idr wg' , idr-chairs@ietf.org, draft-ietf-idr-bgp-extended-messages@ietf.org Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 14:08:18 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0102_01D29720.9C4D3960 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Robert:=20 =20 This is a more complex change to the state machine than just extending = all messages.=20 =20 Sue Hares=20 =20 From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert = Raszuk Sent: Tuesday, March 7, 2017 5:09 AM To: Susan Hares; Randy Bush Cc: Enke Chen; Jeffrey Haas; Alvaro Retana (aretana); = idr-chairs@ietf.org; draft-ietf-idr-bgp-extended-messages@ietf.org; idr = wg Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20 =20 Hi Sue, Authors, =20 Current draft says:=20 =20 "Currently, the Extended Message Capability only applies to UPDATE = messages." =20 I would like to ask authors to change the below restriction to also = consider future BGP messages still compliant with RFC4271 RFC. I would = therefor propose to extend the above sentence with: =20 "The Extended Message Capability applies to UPDATE messages as well as = if required to any new BGP messages." =20 - - - =20 I am less concerned in making Extended Message Capability applicable to = OPEN or KEEPALIVE messages. IMHO Capabilities from OPEN should be moved = to new BGP message (BGP CAPABILITIES MESSAGE) which would by design = allow their dynamic nature along the lines of current dynamic = capabilities proposal except outside of messing up with OPEN.=20 =20 For NOTIFICATION as Enke already pointed there is good reason for it to = be extended. Alternatively a new provision for signalling the errors = between peers should be provided in new message (example: BGP = OPERATIONAL message).=20 =20 Thx, R. =20 =20 =20 =20 =20 =20 On Tue, Mar 7, 2017 at 1:42 AM, Susan Hares wrote: Enke and IDR WG: If there is enough concern about the extended messages covering all = messages versus UPDATE messages, I will need to do 1 week call on this = topic. Sue Hares -----Original Message----- From: Enke Chen [mailto:enkechen@cisco.com] Sent: Monday, March 6, 2017 3:22 PM To: Jeffrey Haas; Alvaro Retana (aretana) Cc: idr-chairs@ietf.org; draft-ietf-idr-bgp-extended-messages@ietf.org; = Susan Hares; idr@ietf.org; Enke Chen Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20 Hi, Folks: I see benefits and no drawbacks for the "BGP-Extended Message = Capability" to cover all the message types, that is, requiring a speaker = that advertises the capability to be able to receiving large messages of = any type. While the requirement for the large message is driven by the = UPDATE message, other messages (such as NOTIFICATION or OPEN) can = potentially exceed the 4K message size as well. It is better to deal = with this issue once. Clearly a large UPDATE message may require a large NOTIFICATION message, = e.g., for carrying a malformed attribute. Regarding the OPEN message, as BGP capabilities are carried inside the = OPEN message and a number of capabilities are AFI/SAFI specific and thus = have the "multiplier" effect on the message size, potentially the OPEN message may exceed the = message size in the future. This "extended message capability" can be = used in a couple of ways to deal with the large OPEN message if the = capability is made to mean support for all message types: o A speaker can remember the capability from its previous OPEN, and = infer that the large message is most likely supported over the current = session, and send the large OPEN message if needed. (It can back off from sending the = large OPEN based on NOTIFICATION message.) o A speaker can send a normal OPEN, and once it determines from the = received OPEN message that the large message capability is supported by the = remote speaker, the speaker can close the connection and start with a = large OPEN. Admittedly these mechanism are not as elegant as the one that bumps the = BGP version. They can be just as effective (especially the first one) in practice. Thanks. -- Enke On 2/28/17 1:06 PM, Jeffrey Haas wrote: > Alvaro, > > I'm not speaking for the authors. However, a few comments on your = writeup: > > On Thu, Feb 23, 2017 at 07:17:05PM +0000, Alvaro Retana (aretana) = wrote: >> M1. Section 4. (Operation): =E2=80=9CAn implementation that supports = the BGP >> Extended Messages MUST be prepared to receive an UPDATE message that >> is larger than 4096 bytes.=E2=80=9C Only UPDATEs? I know that the = most >> likely case for exceeding the 4k size is an UPDATE, but why are the >> other messages not considered? > > The fundamental issue is with regards to not only the basic behavior > of RFC 4271 and its earlier RFC 1771 but also to BGP Versioning. > > Those RFCs set the expectation that version 4 of BGP will have at most > a 4k packet size. Capability advertisement, an extension on top of > BGP, isn't a required feature - although it's certainly very common = these days. > > Thus, for backward compatibility reasons, OPEN messages must be no > bigger than 4k if we're still BGP-4. > > I don't think there's an argument for larger KEEPALIVE messages. :-) > > Similarly, the NOTIFICATION with no restrictions for version > compatibility reasons. *However*, once BGP has reached the > Established state, it is possible for it to send longer NOTIFICATION > messages, if we permitted it and the feature was duly negotiated. > This is probably not the best idea because it will still be necessary > to be able to deal with an old speaker in such cases. > > Also, most implementations don't dump that much information in the > NOTIFICATION Data section. Putting sufficient semantics on the > content would start to get messy. We don't want XML or backtrace over = that message. > > The case for UPDATE is clear. > > The remaining message with some potential motivation is ROUTE-REFRESH. > The basic refresh message is likely to be able to hold AFI/SAFI sets > for some time. The ORF feature that is built upon refresh already > deals with sending its filters over the course of multiple messages. > So, there's not a lot of motivation. > > And that's the messages we have so far. While I can see new messages > being defined that may want it, I don't think there's a strong > argument for it today. > >> Also, what does =E2=80=9Cprepared to receive=E2=80=9D >> mean, and how can =E2=80=9CMUST be prepared to receive=E2=80=9D be = enforced? Given >> the discussion in Section 5 (Error Handling), you might want to add >> something like =E2=80=9C=E2=80=A6even if the Capability is not = advertised=E2=80=9D. > > If the capability hasn't been negotiated, then the expectation is that > it's a PDU error and the session should be dropped. See prior > comments about BGP versioning. > >> M2. Section 5 (Error Handling). =E2=80=9CA BGP speaker that has the = ability >> to use extended messages but has not advertised the BGP Extended >> Messages capability, presumably due to configuration, SHOULD NOT >> accept an extended message. A speaker MAY implement a more liberal >> policy and accept extended messages even from a peer that has not >> advertised the capability.=E2=80=9D This paragraph troubles me a lot = because >> it is in direct contraction with Section 3: =E2=80=9CA peer which = does not >> advertise this capability MUST NOT send BGP Extended Messages, and >> BGP Extended Messages MUST NOT be sent to it.=E2=80=9D. However, I = think >> that John Scudder=E2=80=99s reasoning [3] makes sense ("keep the = session up >> at (almost) all costs", and there=E2=80=99s clear precedence in the = WG) for >> the case where the sender did advertise the Capability, but = I=E2=80=99m not >> convinced on the case where it didn=E2=80=99t =E2=80=93 please = include something like John=E2=80=99s explanation in the text. > > John can own this one. I find the case a little weaker. It vaguely > makes me want a probe message to verify that I can indeed get a > full-sized PDU through. > >> M5. Section 5 (Error Handling). =E2=80=9CThe inconsistency between = the local and >> remote BGP speakers MUST be reported via syslog and/or SNMP.=E2=80=9D = SNMP? >> AFAIK, there=E2=80=99s no object that can report this inconsistency = since >> there=E2=80=99s no NOTIFICATION generated. In the proposed text by = Gunter >> Van De Velde [4], SNMP and syslog were mentioned as examples = =E2=80=93 I >> suggest you follow that path (no need for all the =E2=80=9Cflowery = language=E2=80=9D) >> and just reference mechanisms by example to avoid having to point at = how it would be done. > > IMO, "brought to the attention of the operator. Example mechanisms > might include syslog or SNMP notifications." > > While you're correct that no IETF standard MIB object covers such a > scenario, we shouldn't be proscriptive about some vendor deciding they > want it in their enterprise implementation. > > At some point, we need similar boilerplate language for yang = notifications. > >> M7. What about transition/migration/partial deployment? What should >> the behavior be if, for example, an Extended Message UPDATE is >> received from a peer, but can=E2=80=99t be propagated to others = because they >> don=E2=80=99t support Extended Messages (think route reflectors or = simple >> eBGP -> iBGP)?? There should be some guidance for the general case >> (i.e. when the total size is >>> 4k due simply to the total amount of information, and not because a >> single attribute, for example, is really big), and some requirements >> looking forward to potential new messages/attributes that >> specifically rely on Extended Messages. > > I'm not sure such guidance belongs in this document. We already have > scenarios wherein normal protocol machinery can result in messages > that are too large. The expected behavior is "treat as withdraw" to > the next downstream, similar to the BGP Error handling RFC. > > Examples of this include AS_PATH or CLUSTER_LIST attributes needing to > add a new entry on a full PDU. > >> M7.2. What should the default be for this extension? Should it be = enabled by default or not? > > IMO, there are good reasons to not turn it on for existing BGP > deployments but alternatively good reasons once the extension is > widely enough present in a given topology. The latter example = includes bgpsec. > > -- Jeff > > _______________________________________________ > 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 =20 ------=_NextPart_000_0102_01D29720.9C4D3960 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Robert:

 

<individual contributor hat on>

This is a more complex change to the state machine than just = extending all messages.

 

Sue Hares

 

From:= = rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert = Raszuk
Sent: Tuesday, March 7, 2017 5:09 AM
To: = Susan Hares; Randy Bush
Cc: Enke Chen; Jeffrey Haas; Alvaro = Retana (aretana); idr-chairs@ietf.org; = draft-ietf-idr-bgp-extended-messages@ietf.org; idr wg
Subject: = Re: [Idr] AD Review of = draft-ietf-idr-bgp-extended-messages-20

 

Hi = Sue, Authors,

 

Current draft = says: 

 

"Currently, the Extended = Message Capability only applies to UPDATE = messages."

 

I = would like to ask authors to change the below restriction to also = consider future BGP messages still compliant with RFC4271 RFC. I would = therefor propose to extend the above sentence = with:

 

"The Extended Message = Capability applies to UPDATE messages as well as if required to any new = BGP messages."

 

- - = -

 

I am = less concerned in making Extended Message Capability applicable to OPEN = or KEEPALIVE messages. IMHO Capabilities from OPEN should be moved to = new BGP message (BGP CAPABILITIES MESSAGE) which would by design allow = their dynamic nature along the lines of current dynamic capabilities = proposal except outside of messing up with = OPEN. 

 

For = NOTIFICATION as Enke already pointed there is good reason for it to be = extended. Alternatively a new provision for signalling the errors = between peers should be provided in new message (example: BGP = OPERATIONAL message). 

 

Thx,

R.

=

 

 

 

 

 

 

On Tue, Mar 7, 2017 at 1:42 AM, Susan Hares <shares@ndzh.com> wrote:

Enke and IDR = WG:
<WG chair hat on>
If there is enough concern about the = extended messages covering all messages versus UPDATE messages,  I = will need to do  1 week call on this topic.
<WG Chair hat = off>

Sue Hares

-----Original Message-----
From: = Enke Chen [mailto:enkechen@cisco.com]
Sent: Monday, March 6, 2017 3:22 PM
To: Jeffrey Haas; Alvaro Retana (aretana)
Cc: idr-chairs@ietf.org; draft-ietf-= idr-bgp-extended-messages@ietf.org; Susan Hares; idr@ietf.org; Enke Chen
Subject: Re: [Idr] AD Review of = draft-ietf-idr-bgp-extended-messages-20

Hi, Folks:

I see benefits and no drawbacks for = the "BGP-Extended Message Capability" to cover all the message = types, that is, requiring a speaker that advertises the capability to be = able to receiving large messages of any type.  While the = requirement for the large message is driven by the UPDATE message, other = messages (such as NOTIFICATION or OPEN) can potentially exceed the 4K = message size as well. It is better to deal with this issue = once.

Clearly a large UPDATE message may require a large = NOTIFICATION message, e.g., for carrying a malformed = attribute.

Regarding the OPEN message, as BGP capabilities are = carried inside the OPEN message and a number of capabilities are = AFI/SAFI specific and thus have the "multiplier"
effect on = the message size, potentially the OPEN message may exceed the message = size in the future. This "extended message capability" can be = used in a couple of ways to deal with the large OPEN message if the = capability is made to mean support for all message types:

  =  o A speaker can remember the capability from its previous OPEN, = and infer that
     the large message is most likely = supported over the current session, and send
     the = large OPEN message if needed. (It can back off from sending the large = OPEN
     based on NOTIFICATION = message.)

   o A speaker can send a normal OPEN, and = once it determines from the received
     OPEN message = that the large message capability is supported by the remote
  =    speaker, the speaker can close the connection and start = with a large OPEN.

Admittedly these mechanism are not as elegant = as the one that bumps the BGP version.
They can be just as effective = (especially the first one) in practice.

Thanks.  -- = Enke

On 2/28/17 1:06 PM, Jeffrey Haas wrote:
> = Alvaro,
>
> I'm not speaking for the authors.  However, = a few comments on your writeup:
>
> On Thu, Feb 23, 2017 at = 07:17:05PM +0000, Alvaro Retana (aretana) wrote:
>> M1. Section = 4. (Operation): =E2=80=9CAn implementation that supports the = BGP
>> Extended Messages MUST be prepared to receive an UPDATE = message that
>> is larger than 4096 bytes.=E2=80=9C  Only = UPDATEs?  I know that the most
>> likely case for = exceeding the 4k size is an UPDATE, but why are the
>> other = messages not considered?
>
> The fundamental issue is with = regards to not only the basic behavior
> of RFC 4271 and its = earlier RFC 1771 but also to BGP Versioning.
>
> Those RFCs = set the expectation that version 4 of BGP will have at most
> a 4k = packet size.  Capability advertisement, an extension on top = of
> BGP, isn't a required feature - although it's certainly very = common these days.
>
> Thus, for backward compatibility = reasons, OPEN messages must be no
> bigger than 4k if we're still = BGP-4.
>
> I don't think there's an argument for larger = KEEPALIVE messages. :-)
>
> Similarly, the NOTIFICATION with = no restrictions for version
> compatibility reasons.  = *However*, once BGP has reached the
> Established state, it is = possible for it to send longer NOTIFICATION
> messages, if we = permitted it and the feature was duly negotiated.
> This is = probably not the best idea because it will still be necessary
> to = be able to deal with an old speaker in such cases.
>
> Also, = most implementations don't dump that much information in the
> = NOTIFICATION Data section.  Putting sufficient semantics on = the
> content would start to get messy.  We don't want XML or = backtrace over that message.
>
> The case for UPDATE is = clear.
>
> The remaining message with some potential = motivation is ROUTE-REFRESH.
> The basic refresh message is likely = to be able to hold AFI/SAFI sets
> for some time.  The ORF = feature that is built upon refresh already
> deals with sending = its filters over the course of multiple messages.
> So, there's = not a lot of motivation.
>
> And that's the messages we have = so far.  While I can see new messages
> being defined that = may want it, I don't think there's a strong
> argument for it = today.
>
>> Also, what does =E2=80=9Cprepared to = receive=E2=80=9D
>> mean, and how can =E2=80=9CMUST be prepared = to receive=E2=80=9D be enforced?  Given
>> the discussion = in Section 5 (Error Handling), you might want to add
>> = something like =E2=80=9C=E2=80=A6even if the Capability is not = advertised=E2=80=9D.
>
> If the capability hasn't been = negotiated, then the expectation is that
> it's a PDU error and = the session should be dropped.  See prior
> comments about = BGP versioning.
>
>> M2. Section 5 (Error = Handling).  =E2=80=9CA BGP speaker that has the ability
>> = to use extended messages but has not advertised the BGP = Extended
>> Messages capability, presumably due to = configuration, SHOULD NOT
>> accept an extended message.  = A speaker MAY implement a more liberal
>> policy and accept = extended messages even from a peer that has not
>> advertised = the capability.=E2=80=9D  This paragraph troubles me a lot = because
>> it is in direct contraction with Section 3: = =E2=80=9CA peer which does not
>> advertise this capability = MUST NOT send BGP Extended Messages, and
>> BGP Extended = Messages MUST NOT be sent to it.=E2=80=9D.  However, I = think
>> that John Scudder=E2=80=99s reasoning [3] makes sense = ("keep the session up
>> at (almost) all costs", and = there=E2=80=99s clear precedence in the WG) for
>> the case = where the sender did advertise the Capability, but I=E2=80=99m = not
>> convinced on the case where it didn=E2=80=99t =E2=80=93 = please include something like John=E2=80=99s explanation in the = text.
>
> John can own this one.  I find the case a = little weaker.  It vaguely
> makes me want a probe message to = verify that I can indeed get a
> full-sized PDU = through.
>
>> M5. Section 5 (Error Handling).  = =E2=80=9CThe inconsistency between the local and
>> remote BGP = speakers MUST be reported via syslog and/or SNMP.=E2=80=9D  =  SNMP?
>> AFAIK, there=E2=80=99s no object that can report = this inconsistency since
>> there=E2=80=99s no NOTIFICATION = generated.  In the proposed text by Gunter
>> Van De Velde = [4], SNMP and syslog were mentioned as examples =E2=80=93 I
>> = suggest you follow that path (no need for all the =E2=80=9Cflowery = language=E2=80=9D)
>> and just reference mechanisms by example = to avoid having to point at how it would be done.
>
> IMO, = "brought to the attention of the operator.  Example = mechanisms
> might include syslog or SNMP = notifications."
>
> While you're correct that no IETF = standard MIB object covers such a
> scenario, we shouldn't be = proscriptive about some vendor deciding they
> want it in their = enterprise implementation.
>
> At some point, we need = similar boilerplate language for yang notifications.
>
>> = M7. What about transition/migration/partial deployment?  What = should
>> the behavior be if, for example, an Extended Message = UPDATE is
>> received from a peer, but can=E2=80=99t be = propagated to others because they
>> don=E2=80=99t support = Extended Messages (think route reflectors or simple
>> eBGP = -> iBGP)??  There should be some guidance for the general = case
>> (i.e. when the total size is
>>> 4k due = simply to the total amount of information, and not because a
>> = single attribute, for example, is really big), and some = requirements
>> looking forward to potential new = messages/attributes that
>> specifically rely on Extended = Messages.
>
> I'm not sure such guidance belongs in this = document.  We already have
> scenarios wherein normal = protocol machinery can result in messages
> that are too = large.  The expected behavior is "treat as withdraw" = to
> the next downstream, similar to the BGP Error handling = RFC.
>
> Examples of this include AS_PATH or CLUSTER_LIST = attributes needing to
> add a new entry on a full = PDU.
>
>> M7.2. What should the default be for this = extension?  Should it be enabled by default or not?
>
> = IMO, there are good reasons to not turn it on for existing BGP
> = deployments but alternatively good reasons once the extension is
> = widely enough present in a given topology.  The latter example = includes bgpsec.
>
> -- Jeff
>
> = _______________________________________________
> 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

 

------=_NextPart_000_0102_01D29720.9C4D3960-- From nobody Tue Mar 7 07:41:31 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A1C1129583; Tue, 7 Mar 2017 06:25:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MMENo7eJ4S0Q; Tue, 7 Mar 2017 06:25:19 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 25A0F129659; Tue, 7 Mar 2017 06:20:33 -0800 (PST) Received: from tops.chopps.org (unknown [80.157.8.80]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 49354617DA; Tue, 7 Mar 2017 14:20:32 +0000 (UTC) User-agent: mu4e 0.9.19; emacs 25.1.1 From: Christian Hopps To: Routing ADs Date: Tue, 07 Mar 2017 09:20:30 -0500 Message-ID: <87o9xdcgnl.fsf@chopps.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Cc: idr@ietf.org, draft-ietf-idr-bgp-prefix-sid.all@ietf.org Subject: [Idr] RtgDir review for draft-ietf-idr-bgp-prefix-sid-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 14:25:23 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing = ADs. For more information about the Routing Directorate, please see =E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it wo= uld be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or= by updating the draft. Document: draft-ietf-idr-bgp-prefix-sid-04 Reviewer: Christian Hopps Review Date: 2017-03-04 IETF LC End Date: Unknown Intended Status: Standards Track Summary: =3D=3D=3D=3D=3D=3D=3D=3D [x] This document is basically ready for publication, but has nits that should be considered prior to publication. Comments: =3D=3D=3D=3D=3D=3D=3D=3D=3D Draft is quite readable. Major Issues: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D No major issues found. Minor Issues: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D References normative vs informative. I'm not sure why some of the informati= ve aren't normative. For example the S-bit indicates that the router is capabl= e of processing the SRH which is defined by [I-D.ietf-6man-segment-routing-heade= r] so shouldn't this be a Normative reference? Additionally the Originator SRGB T= LV references [I-D.ietf-ospf-segment-routing-extensions] for the meaning of multiple ranges (represented by the presence of multiple TLVs). Advisory only: There are many cases of reserved fields being "SHOULD be 0 on transmit and MUST be ignored on receive." Is it better to use MUST instead = of SHOULD here as that allows for better future-proofing? With "MUST be 0" you could then count on the values being zero for devices that do not support a future extension where the value is not zero. Of course future extensions c= ould always use another method to determine if the reserved field holds newly va= lid values so this isn't that big a deal. Nits: =3D=3D=3D=3D=3D By far there are more references to "nodes" than to "routers", but I think = they all refer to the same thing -- maybe pick one name. Section 4 1st paragraph: remove first sentence starting "The value field..." 2nd paragraph: Add "The" to "Following TLVs are defined." Section 4.3 2nd paragraph of description of SRGB (1st paragraph on page.8) = uses an unexpanded acronym SRTE. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAli+wa4ACgkQLh2DDte4 MCVfeA/8DbNoWfMgG9i1HRs9khA4bTU7mf4AaRTlyLN5/MH3ypoEOos9xXbyN5hd 4zwI0Cgpfrjc+7x8AT8OZesfekoDUYrsg4UAq5TFV0dB7AFR4Z1g9xj8cOFmCnLO yK16yC3BawkDMP0l2F0NkNtBGUshqc7XZK+K7hm7vxLEJnrV7noRMJUOSbPafpxL vqb5Uiy3mdxF9AuapfPdHx47qfOqvBqzjd5wNBjIYDLsgbG7llRVvJUTKSQhGln6 Zx7O3YWNwS3ZkJbYxbRsMg8KpG8LlYLw9xiz0caiWy3QkBZ/WwpbS5noDJGcrHdt LsMuh5zF2PpO4wVhZ6Nfr/VdgtiQ9Xvr2POXsZQ/AbvWVizEEY/8oFRhUhRDJQDQ gF9qLMkT5jbXzMMSv8NEeYKeWdiIX85OyEe1NaaVsKgWDBoZ9VjHvvio9WOpR3R4 XVDXSGDrFEUkElCQzujcMm8eRjmk8xNFewVxjtekZR+I2zJOGEHsVx1pnPZGvXv2 b1Rmf8jaGvCwosgAtNGbh4SQLFyx2YhAWkGxmEDEXLx8wVfkDmme9eNlJ4q/7759 W4xSLfVxJqZ4ZD3/4gQ1PRWQ9v8npvfcgrYy/Ny46jOdb7UHIHDKWCNXCiREqTMh Y1JEayFOIwrVR7EZUyT3xqAFUfvGqy4TPx2W7Boh11BOuncWT1I= =IxJR -----END PGP SIGNATURE----- --=-=-=-- From 7riw77@gmail.com Tue Mar 7 07:06:15 2017 Return-Path: <7riw77@gmail.com> X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE8A126D74; Tue, 7 Mar 2017 07:06:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jkMcFO590cee; Tue, 7 Mar 2017 07:06:12 -0800 (PST) Received: from mail-qk0-x241.google.com (mail-qk0-x241.google.com [IPv6:2607:f8b0:400d:c09::241]) (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 7D7D6128B38; Tue, 7 Mar 2017 07:06:12 -0800 (PST) Received: by mail-qk0-x241.google.com with SMTP id o135so1487364qke.2; Tue, 07 Mar 2017 07:06:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=L9UNe7aDU83Tp5KSkYJ5q0dUho1j0jrBqkSalXJUpA0=; b=JwxNo/EBi7TKOlL5rreQNAVDja+UEm4pFrOLylMmfKcYuAih46S31WEQimbmHL+e+l 7XuuQtAqHq8SQKv2Xt5yYdpaLVk5IVoDgYP+TMhHl9N1b8ULs1Asm7x12jXH6dsMBvsK CafNvL1THr/wgzArwgwxF+JUfbt1OvumqedStqosaQMahewZgqRZD8n6STYNzUZKBVnB Ro9EDL3bpUG2KYRbWY4JrTQSYWDCwH9SqSSNfd/WLp1bWIXL0haGUSY6HIY4GCMaIz7C xsUm5N7vPE96TAsiZhmBQjW0Ra0t+TbQAVx82CXTdBGbKeCrwDq30KMErZERsbwHNaL1 41bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=L9UNe7aDU83Tp5KSkYJ5q0dUho1j0jrBqkSalXJUpA0=; b=DDWFiwhk5shkamGC6HCuxeUCjPosU6Fx5tXBw/rZMqwwybl1SVCvvrkdwW3SyW+D97 z12jFgDhJw6s3CxfqYw0jRA88F28FXkxvJPvNcCCfTbtFkUv42oNnYgEnv6HY6YpQ6fC n4/RPRorBq9nB7/btzlCJvwBWoXDJgsyoEBM2yNnxVKkf0V8wGBBuS7G4A0dWDeIOC3O 2/ISBx9tnNd4QiaZKMWAtrPREAYAuCGJWjB6KMhEG6JZWNEhdw34HlFKCDE574gB6GO8 jMqxk0W5p05GMKhqRKmWo3cMv1bRRUbm5OpHoxWbHcIgYFSO+O+6NRNdyJ+raPd8vpaE PJrw== X-Gm-Message-State: AMke39nbE9R8nlyJf/HP4Z+6OpjCbpM41qnDIHp+myd8SBPiRpaSxhsvzTQgWTq5QjijLg== X-Received: by 10.129.114.130 with SMTP id n124mr286799ywc.193.1488899171595; Tue, 07 Mar 2017 07:06:11 -0800 (PST) Received: from Russ (162-229-180-77.lightspeed.rlghnc.sbcglobal.net. [162.229.180.77]) by smtp.gmail.com with ESMTPSA id s4sm94291ywa.32.2017.03.07.07.06.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Mar 2017 07:06:11 -0800 (PST) From: "Russ White" <7riw77@gmail.com> To: "'Robert Raszuk'" , "'Susan Hares'" , "'Randy Bush'" References: <20170228210627.GB17448@pfrc.org> <3eb4d853-1d44-6250-c70a-26f60eac39e6@cisco.com> <006e01d296db$a7c4c320$f74e4960$@ndzh.com> In-Reply-To: Date: Tue, 7 Mar 2017 10:06:08 -0500 Message-ID: <020501d29754$59ef7cc0$0dce7640$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQInnAj+Yxa8tap/yfCJFXAjQYwk1wJi0XFfAwzFclUBlnEaYAHWMN+roJiOp3A= Content-Language: en-us Cc: 'idr wg' , draft-ietf-idr-bgp-extended-messages@ietf.org, idr-chairs@ietf.org Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 15:06:15 -0000 > I would like to ask authors to change the below restriction to also = consider > future BGP messages still compliant with RFC4271 RFC. I would therefor > propose to extend the above sentence with: I agree with this assessment -- the new extended message type should = apply to any message type necessary. :-) Russ From rraszuk@gmail.com Tue Mar 7 07:15:49 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76355126DFB; Tue, 7 Mar 2017 07:15:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.368 X-Spam-Level: X-Spam-Status: No, score=-2.368 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.229, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYdYImhLqAw1; Tue, 7 Mar 2017 07:15:46 -0800 (PST) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::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 DC56F12959A; Tue, 7 Mar 2017 07:14:11 -0800 (PST) Received: by mail-qk0-x230.google.com with SMTP id v125so8257454qkh.2; Tue, 07 Mar 2017 07:14:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=R3JllnLdDMlJMC86+V6nWYZYW6tLMPn4GgHZcvI2Diw=; b=HHAvDk2CurHJjmRQEk1ic5jscBw+1bgGjncTb5PMai7qMZxoj9HJyl/7S+C6mmbSJX FZ8xl0E3S2GIpzluX+U/QazYdnmtfRVe6rXvcvxg6HUVdO6jKEWWVo78GS/hcvFqQH/f uXcggAMYmqHv886HZ467OhurnA9/hEmrBhRc59WSTS/B1AFum711EjrOUejnNipD9zZA Xf0zST+9WDe0I1cMsH2zxzsXfi9oHmRDCnKD25/enXcX2ONbxdYUW6KPDKBysteeO5ri Z2eSn4FzihJEvlnm646c+oFpY4u0G4nKHB/eG9+oCXw1gIPijIDlfaoQxrKTVUMte3OQ DsqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=R3JllnLdDMlJMC86+V6nWYZYW6tLMPn4GgHZcvI2Diw=; b=K/SvRtiWVVheLxrVhkUkjHVYR8D2wrtUrGPi+TuxPZ3ngCQV1cywSpjOY2dm0XYV7k LjUR//i4kkDXHIsC0PFc52FrRUKiqRYf9tXNiYGHfdtvkY+bHOOvhcPyj1nFBb2+unJd Ei4L3f1ppWIyd5u7CJsBbofmfmVKsN+WQjHDeP6WEAbFUz6lTiUlVm1lJAQ4VE1QaoSp tcpFn0wbXmhTcezSi4s2e0mp4Wv5rBgoWKUXq8KTi7jrQpxSIjwNtNXsz0F2HzXUcq9q Tn543nR5XNSNPTsgdKK/UbgJRVV+pk1j7MuHX9H8hF1UVW/lNnocR9zuqLU80Ah7tsf/ eJFQ== X-Gm-Message-State: AMke39moWFuNwVZ6B5PRRObdgC/N6zPn3cjvVv6OK/1yGRhz2lqOezPO+tnMjR2yrKfrZxakbc7if/0Nzxlwiw== X-Received: by 10.55.128.66 with SMTP id b63mr936464qkd.297.1488899650662; Tue, 07 Mar 2017 07:14:10 -0800 (PST) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.140.42.181 with HTTP; Tue, 7 Mar 2017 07:14:09 -0800 (PST) In-Reply-To: <010101d2974a$8520d060$8f627120$@ndzh.com> References: <20170228210627.GB17448@pfrc.org> <3eb4d853-1d44-6250-c70a-26f60eac39e6@cisco.com> <006e01d296db$a7c4c320$f74e4960$@ndzh.com> <010101d2974a$8520d060$8f627120$@ndzh.com> From: Robert Raszuk Date: Tue, 7 Mar 2017 16:14:09 +0100 X-Google-Sender-Auth: ZSinF4Cocg-SRQ5iAEXUjWqcSYQ Message-ID: To: Susan Hares Content-Type: multipart/alternative; boundary=94eb2c06654cc90089054a257677 Cc: idr wg , idr-chairs@ietf.org, draft-ietf-idr-bgp-extended-messages@ietf.org Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 15:15:49 -0000 --94eb2c06654cc90089054a257677 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sue, I don't understand your point of "more complex". Current proposal extends single message type. I indicated that future defined messages needs also to have an option to be extended with proposed capability. That's all. Thx, Robert On Tue, Mar 7, 2017 at 2:55 PM, Susan Hares wrote: > Robert: > > > > > > This is a more complex change to the state machine than just extending al= l > messages. > > > > Sue Hares > > > > *From:* rraszuk@gmail.com [mailto:rraszuk@gmail.com] *On Behalf Of *Rober= t > Raszuk > *Sent:* Tuesday, March 7, 2017 5:09 AM > *To:* Susan Hares; Randy Bush > *Cc:* Enke Chen; Jeffrey Haas; Alvaro Retana (aretana); > idr-chairs@ietf.org; draft-ietf-idr-bgp-extended-messages@ietf.org; idr w= g > > *Subject:* Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20 > > > > Hi Sue, Authors, > > > > Current draft says: > > > > *"Currently, the Extended Message Capability only applies to UPDATE > messages."* > > > > I would like to ask authors to change the below restriction to also > consider future BGP messages still compliant with RFC4271 RFC. I would > therefor propose to extend the above sentence with: > > > > *"The Extended Message Capability applies to UPDATE messages as well as i= f > required to any new BGP messages."* > > > > - - - > > > > I am less concerned in making Extended Message Capability applicable to > OPEN or KEEPALIVE messages. IMHO Capabilities from OPEN should be moved t= o > new BGP message (BGP CAPABILITIES MESSAGE) which would by design allow > their dynamic nature along the lines of current dynamic capabilities > proposal except outside of messing up with OPEN. > > > > For NOTIFICATION as Enke already pointed there is good reason for it to b= e > extended. Alternatively a new provision for signalling the errors between > peers should be provided in new message (example: BGP OPERATIONAL message= ). > > > > Thx, > > R. > > > > > > > > > > > > > > On Tue, Mar 7, 2017 at 1:42 AM, Susan Hares wrote: > > Enke and IDR WG: > > If there is enough concern about the extended messages covering all > messages versus UPDATE messages, I will need to do 1 week call on this > topic. > > > Sue Hares > > -----Original Message----- > From: Enke Chen [mailto:enkechen@cisco.com] > Sent: Monday, March 6, 2017 3:22 PM > To: Jeffrey Haas; Alvaro Retana (aretana) > Cc: idr-chairs@ietf.org; draft-ietf-idr-bgp-extended-messages@ietf.org; > Susan Hares; idr@ietf.org; Enke Chen > Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20 > > Hi, Folks: > > I see benefits and no drawbacks for the "BGP-Extended Message Capability" > to cover all the message types, that is, requiring a speaker that > advertises the capability to be able to receiving large messages of any > type. While the requirement for the large message is driven by the UPDAT= E > message, other messages (such as NOTIFICATION or OPEN) can potentially > exceed the 4K message size as well. It is better to deal with this issue > once. > > Clearly a large UPDATE message may require a large NOTIFICATION message, > e.g., for carrying a malformed attribute. > > Regarding the OPEN message, as BGP capabilities are carried inside the > OPEN message and a number of capabilities are AFI/SAFI specific and thus > have the "multiplier" > effect on the message size, potentially the OPEN message may exceed the > message size in the future. This "extended message capability" can be use= d > in a couple of ways to deal with the large OPEN message if the capability > is made to mean support for all message types: > > o A speaker can remember the capability from its previous OPEN, and > infer that > the large message is most likely supported over the current session, > and send > the large OPEN message if needed. (It can back off from sending the > large OPEN > based on NOTIFICATION message.) > > o A speaker can send a normal OPEN, and once it determines from the > received > OPEN message that the large message capability is supported by the > remote > speaker, the speaker can close the connection and start with a large > OPEN. > > Admittedly these mechanism are not as elegant as the one that bumps the > BGP version. > They can be just as effective (especially the first one) in practice. > > Thanks. -- Enke > > On 2/28/17 1:06 PM, Jeffrey Haas wrote: > > Alvaro, > > > > I'm not speaking for the authors. However, a few comments on your > writeup: > > > > On Thu, Feb 23, 2017 at 07:17:05PM +0000, Alvaro Retana (aretana) wrote= : > >> M1. Section 4. (Operation): =E2=80=9CAn implementation that supports t= he BGP > >> Extended Messages MUST be prepared to receive an UPDATE message that > >> is larger than 4096 bytes.=E2=80=9C Only UPDATEs? I know that the mo= st > >> likely case for exceeding the 4k size is an UPDATE, but why are the > >> other messages not considered? > > > > The fundamental issue is with regards to not only the basic behavior > > of RFC 4271 and its earlier RFC 1771 but also to BGP Versioning. > > > > Those RFCs set the expectation that version 4 of BGP will have at most > > a 4k packet size. Capability advertisement, an extension on top of > > BGP, isn't a required feature - although it's certainly very common > these days. > > > > Thus, for backward compatibility reasons, OPEN messages must be no > > bigger than 4k if we're still BGP-4. > > > > I don't think there's an argument for larger KEEPALIVE messages. :-) > > > > Similarly, the NOTIFICATION with no restrictions for version > > compatibility reasons. *However*, once BGP has reached the > > Established state, it is possible for it to send longer NOTIFICATION > > messages, if we permitted it and the feature was duly negotiated. > > This is probably not the best idea because it will still be necessary > > to be able to deal with an old speaker in such cases. > > > > Also, most implementations don't dump that much information in the > > NOTIFICATION Data section. Putting sufficient semantics on the > > content would start to get messy. We don't want XML or backtrace over > that message. > > > > The case for UPDATE is clear. > > > > The remaining message with some potential motivation is ROUTE-REFRESH. > > The basic refresh message is likely to be able to hold AFI/SAFI sets > > for some time. The ORF feature that is built upon refresh already > > deals with sending its filters over the course of multiple messages. > > So, there's not a lot of motivation. > > > > And that's the messages we have so far. While I can see new messages > > being defined that may want it, I don't think there's a strong > > argument for it today. > > > >> Also, what does =E2=80=9Cprepared to receive=E2=80=9D > >> mean, and how can =E2=80=9CMUST be prepared to receive=E2=80=9D be enf= orced? Given > >> the discussion in Section 5 (Error Handling), you might want to add > >> something like =E2=80=9C=E2=80=A6even if the Capability is not adverti= sed=E2=80=9D. > > > > If the capability hasn't been negotiated, then the expectation is that > > it's a PDU error and the session should be dropped. See prior > > comments about BGP versioning. > > > >> M2. Section 5 (Error Handling). =E2=80=9CA BGP speaker that has the a= bility > >> to use extended messages but has not advertised the BGP Extended > >> Messages capability, presumably due to configuration, SHOULD NOT > >> accept an extended message. A speaker MAY implement a more liberal > >> policy and accept extended messages even from a peer that has not > >> advertised the capability.=E2=80=9D This paragraph troubles me a lot = because > >> it is in direct contraction with Section 3: =E2=80=9CA peer which does= not > >> advertise this capability MUST NOT send BGP Extended Messages, and > >> BGP Extended Messages MUST NOT be sent to it.=E2=80=9D. However, I th= ink > >> that John Scudder=E2=80=99s reasoning [3] makes sense ("keep the sessi= on up > >> at (almost) all costs", and there=E2=80=99s clear precedence in the WG= ) for > >> the case where the sender did advertise the Capability, but I=E2=80=99= m not > >> convinced on the case where it didn=E2=80=99t =E2=80=93 please include= something like > John=E2=80=99s explanation in the text. > > > > John can own this one. I find the case a little weaker. It vaguely > > makes me want a probe message to verify that I can indeed get a > > full-sized PDU through. > > > >> M5. Section 5 (Error Handling). =E2=80=9CThe inconsistency between th= e local > and > >> remote BGP speakers MUST be reported via syslog and/or SNMP.=E2=80=9D = SNMP? > >> AFAIK, there=E2=80=99s no object that can report this inconsistency si= nce > >> there=E2=80=99s no NOTIFICATION generated. In the proposed text by Gu= nter > >> Van De Velde [4], SNMP and syslog were mentioned as examples =E2=80=93= I > >> suggest you follow that path (no need for all the =E2=80=9Cflowery lan= guage=E2=80=9D) > >> and just reference mechanisms by example to avoid having to point at > how it would be done. > > > > IMO, "brought to the attention of the operator. Example mechanisms > > might include syslog or SNMP notifications." > > > > While you're correct that no IETF standard MIB object covers such a > > scenario, we shouldn't be proscriptive about some vendor deciding they > > want it in their enterprise implementation. > > > > At some point, we need similar boilerplate language for yang > notifications. > > > >> M7. What about transition/migration/partial deployment? What should > >> the behavior be if, for example, an Extended Message UPDATE is > >> received from a peer, but can=E2=80=99t be propagated to others becaus= e they > >> don=E2=80=99t support Extended Messages (think route reflectors or sim= ple > >> eBGP -> iBGP)?? There should be some guidance for the general case > >> (i.e. when the total size is > >>> 4k due simply to the total amount of information, and not because a > >> single attribute, for example, is really big), and some requirements > >> looking forward to potential new messages/attributes that > >> specifically rely on Extended Messages. > > > > I'm not sure such guidance belongs in this document. We already have > > scenarios wherein normal protocol machinery can result in messages > > that are too large. The expected behavior is "treat as withdraw" to > > the next downstream, similar to the BGP Error handling RFC. > > > > Examples of this include AS_PATH or CLUSTER_LIST attributes needing to > > add a new entry on a full PDU. > > > >> M7.2. What should the default be for this extension? Should it be > enabled by default or not? > > > > IMO, there are good reasons to not turn it on for existing BGP > > deployments but alternatively good reasons once the extension is > > widely enough present in a given topology. The latter example includes > bgpsec. > > > > -- Jeff > > > > _______________________________________________ > > 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 > > > --94eb2c06654cc90089054a257677 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sue,=C2=A0

=
I don't understand your point of "more co= mplex".=C2=A0

Cur= rent proposal extends single message type. I indicated that future defined = messages needs also to have an option to be extended with proposed capabili= ty.=C2=A0

That's a= ll.=C2=A0

Thx,
Robert



On Tu= e, Mar 7, 2017 at 2:55 PM, Susan Hares <shares@ndzh.com> wrote= :

Robert:

=C2=A0

=

<individual contributo= r hat on>

This is a more complex change to the state machine than just ex= tending all messages.

=C2=A0

Sue Hares

=C2=A0

From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] <= b>On Behalf Of Robert Raszuk
Sent: Tuesday, March 7, 2017 5:0= 9 AM
To: Susan Hares; Randy Bush
Cc: Enke Chen; Jeffrey= Haas; Alvaro Retana (aretana); idr-chairs@ietf.org; draft-ietf-idr-bgp-extended-= messages@ietf.org; idr wg


= Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messag= es-20

=C2=A0

Hi Sue, Au= thors,

=C2= =A0

Current draft says:=C2=A0<= u>

=C2=A0

=

"Currently, the Extended Message Capabi= lity only applies to UPDATE messages."

=C2=A0

I would like to ask authors to change the below restriction to als= o consider future BGP messages still compliant with RFC4271 RFC. I would th= erefor propose to extend the above sentence with:

<= /div>

=C2=A0

"The Extended Message Capability applies to UPDATE messag= es as well as if required to any new BGP messages."<= u>

=C2=A0

<= div>

- - -

=C2=A0

I am less con= cerned in making Extended Message Capability applicable to OPEN or KEEPALIV= E messages. IMHO Capabilities from OPEN should be moved to new BGP message = (BGP CAPABILITIES MESSAGE) which would by design allow their dynamic nature= along the lines of current dynamic capabilities proposal except outside of= messing up with OPEN.=C2=A0

=C2=A0

For NOTIFIC= ATION as Enke already pointed there is good reason for it to be extended. A= lternatively a new provision for signalling the errors between peers should= be provided in new message (example: BGP OPERATIONAL message).=C2=A0

=C2=A0

Thx,

R.

=C2=A0

=C2=A0

=C2=A0

<= p class=3D"MsoNormal">=C2=A0

<= u>=C2=A0

=C2=A0

On Tue, Mar 7, 2017 at= 1:42 AM, Susan Hares <shares@ndzh.com> wrote:

Enke and IDR WG:
<WG chair hat on><= br>If there is enough concern about the extended messages covering all mess= ages versus UPDATE messages,=C2=A0 I will need to do=C2=A0 1 week call on t= his topic.
<WG Chair hat off>

Sue Hares

= -----Original Message-----
From: Enke Chen [mailto:enkechen@cisco.com]
Sent: Monday, March 6, 2017 3:22 PM
To: Jeffrey Haas; Alvaro Retana (aretana)
Cc: idr-chairs@ietf.org; draft-ietf-idr-bgp-ext= ended-messages@ietf.org; Susan Hares; idr@ietf.org; Enke Chen
Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp= -extended-messages-20

Hi, Folks:

I see benefits and no drawbacks for the "BG= P-Extended Message Capability" to cover all the message types, that is= , requiring a speaker that advertises the capability to be able to receivin= g large messages of any type.=C2=A0 While the requirement for the large mes= sage is driven by the UPDATE message, other messages (such as NOTIFICATION = or OPEN) can potentially exceed the 4K message size as well. It is better t= o deal with this issue once.

Clearly a large UPDATE message may requ= ire a large NOTIFICATION message, e.g., for carrying a malformed attribute.=

Regarding the OPEN message, as BGP capabilities are carried inside = the OPEN message and a number of capabilities are AFI/SAFI specific and thu= s have the "multiplier"
effect on the message size, potentiall= y the OPEN message may exceed the message size in the future. This "ex= tended message capability" can be used in a couple of ways to deal wit= h the large OPEN message if the capability is made to mean support for all = message types:

=C2=A0 =C2=A0o A speaker can remember the capability = from its previous OPEN, and infer that
=C2=A0 =C2=A0 =C2=A0the large mes= sage is most likely supported over the current session, and send
=C2=A0 = =C2=A0 =C2=A0the large OPEN message if needed. (It can back off from sendin= g the large OPEN
=C2=A0 =C2=A0 =C2=A0based on NOTIFICATION message.)
=
=C2=A0 =C2=A0o A speaker can send a normal OPEN, and once it determines= from the received
=C2=A0 =C2=A0 =C2=A0OPEN message that the large messa= ge capability is supported by the remote
=C2=A0 =C2=A0 =C2=A0speaker, th= e speaker can close the connection and start with a large OPEN.

Admi= ttedly these mechanism are not as elegant as the one that bumps the BGP ver= sion.
They can be just as effective (especially the first one) in practi= ce.

Thanks.=C2=A0 -- Enke

On 2/28/17 1:06 PM, Jeffrey Haas wr= ote:
> Alvaro,
>
> I'm not speaking for the authors.= =C2=A0 However, a few comments on your writeup:
>
> On Thu, Feb= 23, 2017 at 07:17:05PM +0000, Alvaro Retana (aretana) wrote:
>> M= 1. Section 4. (Operation): =E2=80=9CAn implementation that supports the BGP=
>> Extended Messages MUST be prepared to receive an UPDATE messag= e that
>> is larger than 4096 bytes.=E2=80=9C=C2=A0 Only UPDATEs?= =C2=A0 I know that the most
>> likely case for exceeding the 4k si= ze is an UPDATE, but why are the
>> other messages not considered?=
>
> The fundamental issue is with regards to not only the basi= c behavior
> of RFC 4271 and its earlier RFC 1771 but also to BGP Ver= sioning.
>
> Those RFCs set the expectation that version 4 of B= GP will have at most
> a 4k packet size.=C2=A0 Capability advertiseme= nt, an extension on top of
> BGP, isn't a required feature - alth= ough it's certainly very common these days.
>
> Thus, for b= ackward compatibility reasons, OPEN messages must be no
> bigger than= 4k if we're still BGP-4.
>
> I don't think there's= an argument for larger KEEPALIVE messages. :-)
>
> Similarly, = the NOTIFICATION with no restrictions for version
> compatibility rea= sons.=C2=A0 *However*, once BGP has reached the
> Established state, = it is possible for it to send longer NOTIFICATION
> messages, if we p= ermitted it and the feature was duly negotiated.
> This is probably n= ot the best idea because it will still be necessary
> to be able to d= eal with an old speaker in such cases.
>
> Also, most implement= ations don't dump that much information in the
> NOTIFICATION Dat= a section.=C2=A0 Putting sufficient semantics on the
> content would = start to get messy.=C2=A0 We don't want XML or backtrace over that mess= age.
>
> The case for UPDATE is clear.
>
> The rema= ining message with some potential motivation is ROUTE-REFRESH.
> The = basic refresh message is likely to be able to hold AFI/SAFI sets
> fo= r some time.=C2=A0 The ORF feature that is built upon refresh already
&g= t; deals with sending its filters over the course of multiple messages.
= > So, there's not a lot of motivation.
>
> And that'= s the messages we have so far.=C2=A0 While I can see new messages
> b= eing defined that may want it, I don't think there's a strong
&g= t; argument for it today.
>
>> Also, what does =E2=80=9Cprep= ared to receive=E2=80=9D
>> mean, and how can =E2=80=9CMUST be pre= pared to receive=E2=80=9D be enforced?=C2=A0 Given
>> the discussi= on in Section 5 (Error Handling), you might want to add
>> somethi= ng like =E2=80=9C=E2=80=A6even if the Capability is not advertised=E2=80=9D= .
>
> If the capability hasn't been negotiated, then the ex= pectation is that
> it's a PDU error and the session should be dr= opped.=C2=A0 See prior
> comments about BGP versioning.
>
&g= t;> M2. Section 5 (Error Handling).=C2=A0 =E2=80=9CA BGP speaker that ha= s the ability
>> to use extended messages but has not advertised t= he BGP Extended
>> Messages capability, presumably due to configur= ation, SHOULD NOT
>> accept an extended message.=C2=A0 A speaker M= AY implement a more liberal
>> policy and accept extended messages= even from a peer that has not
>> advertised the capability.=E2=80= =9D=C2=A0 This paragraph troubles me a lot because
>> it is in dir= ect contraction with Section 3: =E2=80=9CA peer which does not
>> = advertise this capability MUST NOT send BGP Extended Messages, and
>&= gt; BGP Extended Messages MUST NOT be sent to it.=E2=80=9D.=C2=A0 However, = I think
>> that John Scudder=E2=80=99s reasoning [3] makes sense (= "keep the session up
>> at (almost) all costs", and ther= e=E2=80=99s clear precedence in the WG) for
>> the case where the = sender did advertise the Capability, but I=E2=80=99m not
>> convin= ced on the case where it didn=E2=80=99t =E2=80=93 please include something = like John=E2=80=99s explanation in the text.
>
> John can own t= his one.=C2=A0 I find the case a little weaker.=C2=A0 It vaguely
> ma= kes me want a probe message to verify that I can indeed get a
> full-= sized PDU through.
>
>> M5. Section 5 (Error Handling).=C2= =A0 =E2=80=9CThe inconsistency between the local and
>> remote BGP= speakers MUST be reported via syslog and/or SNMP.=E2=80=9D=C2=A0 =C2=A0SNM= P?
>> AFAIK, there=E2=80=99s no object that can report this incons= istency since
>> there=E2=80=99s no NOTIFICATION generated.=C2=A0 = In the proposed text by Gunter
>> Van De Velde [4], SNMP and syslo= g were mentioned as examples =E2=80=93 I
>> suggest you follow tha= t path (no need for all the =E2=80=9Cflowery language=E2=80=9D)
>>= and just reference mechanisms by example to avoid having to point at how i= t would be done.
>
> IMO, "brought to the attention of the= operator.=C2=A0 Example mechanisms
> might include syslog or SNMP no= tifications."
>
> While you're correct that no IETF st= andard MIB object covers such a
> scenario, we shouldn't be prosc= riptive about some vendor deciding they
> want it in their enterprise= implementation.
>
> At some point, we need similar boilerplate= language for yang notifications.
>
>> M7. What about transi= tion/migration/partial deployment?=C2=A0 What should
>> the behavi= or be if, for example, an Extended Message UPDATE is
>> received f= rom a peer, but can=E2=80=99t be propagated to others because they
>&= gt; don=E2=80=99t support Extended Messages (think route reflectors or simp= le
>> eBGP -> iBGP)??=C2=A0 There should be some guidance for t= he general case
>> (i.e. when the total size is
>>> 4k= due simply to the total amount of information, and not because a
>&g= t; single attribute, for example, is really big), and some requirements
= >> looking forward to potential new messages/attributes that
>&= gt; specifically rely on Extended Messages.
>
> I'm not sur= e such guidance belongs in this document.=C2=A0 We already have
> sce= narios wherein normal protocol machinery can result in messages
> tha= t are too large.=C2=A0 The expected behavior is "treat as withdraw&quo= t; to
> the next downstream, similar to the BGP Error handling RFC.>
> Examples of this include AS_PATH or CLUSTER_LIST attributes = needing to
> add a new entry on a full PDU.
>
>> M7.2.= What should the default be for this extension?=C2=A0 Should it be enabled = by default or not?
>
> IMO, there are good reasons to not turn = it on for existing BGP
> deployments but alternatively good reasons o= nce the extension is
> widely enough present in a given topology.=C2= =A0 The latter example includes bgpsec.
>
> -- Jeff
>
= > _______________________________________________
> Idr maili= ng list
> Idr@ietf.= org
> https://www.ietf.org/mailman/listinfo/idr
>
=
_______________________________________________
Idr mailing lis= t
Idr@ietf.org
= htt= ps://www.ietf.org/mailman/listinfo/idr

=C2=A0


--94eb2c06654cc90089054a257677-- From nobody Tue Mar 7 08:18:17 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0604129512; Tue, 7 Mar 2017 07:28:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.947 X-Spam-Level: X-Spam-Status: No, score=0.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W8Qp-aTd2rtQ; Tue, 7 Mar 2017 07:28:38 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 ED8EC12949D; Tue, 7 Mar 2017 07:28:37 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.90.29; From: "Susan Hares" To: "'Robert Raszuk'" References: <20170228210627.GB17448@pfrc.org> <3eb4d853-1d44-6250-c70a-26f60eac39e6@cisco.com> <006e01d296db$a7c4c320$f74e4960$@ndzh.com> <010101d2974a$8520d060$8f627120$@ndzh.com> In-Reply-To: Date: Tue, 7 Mar 2017 10:23:32 -0500 Message-ID: <018c01d29756$c8b4f610$5a1ee230$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_018D_01D2972C.DFE18620" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQInnAj+Yxa8tap/yfCJFXAjQYwk1wJi0XFfAwzFclUBlnEaYAHWMN+rAr58MhwCyGvcFaBsW8AA Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'idr wg' , idr-chairs@ietf.org, draft-ietf-idr-bgp-extended-messages@ietf.org Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 15:28:41 -0000 This is a multipart message in MIME format. ------=_NextPart_000_018D_01D2972C.DFE18620 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Robert:=20 =20 Let=E2=80=99s take this offline. The complexity is in the changes to = the RFC4271 finite state machine. I=E2=80=99m glad to explain the = design of the BGP FSM offline, but I=E2=80=99ve gone through the precise = reasons already on the mail list. My suggestion is to include all = messages including future messages if approved. =20 Sue=20 =20 From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert = Raszuk Sent: Tuesday, March 7, 2017 10:14 AM To: Susan Hares Cc: Randy Bush; Enke Chen; Jeffrey Haas; Alvaro Retana (aretana); = idr-chairs@ietf.org; draft-ietf-idr-bgp-extended-messages@ietf.org; idr = wg Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20 =20 Sue,=20 =20 I don't understand your point of "more complex".=20 =20 Current proposal extends single message type. I indicated that future = defined messages needs also to have an option to be extended with = proposed capability.=20 =20 That's all.=20 =20 Thx, Robert =20 =20 =20 On Tue, Mar 7, 2017 at 2:55 PM, Susan Hares wrote: Robert:=20 =20 This is a more complex change to the state machine than just extending = all messages.=20 =20 Sue Hares=20 =20 From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert = Raszuk Sent: Tuesday, March 7, 2017 5:09 AM To: Susan Hares; Randy Bush Cc: Enke Chen; Jeffrey Haas; Alvaro Retana (aretana); = idr-chairs@ietf.org; draft-ietf-idr-bgp-extended-messages@ietf.org; idr = wg Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20 =20 Hi Sue, Authors, =20 Current draft says:=20 =20 "Currently, the Extended Message Capability only applies to UPDATE = messages." =20 I would like to ask authors to change the below restriction to also = consider future BGP messages still compliant with RFC4271 RFC. I would = therefor propose to extend the above sentence with: =20 "The Extended Message Capability applies to UPDATE messages as well as = if required to any new BGP messages." =20 - - - =20 I am less concerned in making Extended Message Capability applicable to = OPEN or KEEPALIVE messages. IMHO Capabilities from OPEN should be moved = to new BGP message (BGP CAPABILITIES MESSAGE) which would by design = allow their dynamic nature along the lines of current dynamic = capabilities proposal except outside of messing up with OPEN.=20 =20 For NOTIFICATION as Enke already pointed there is good reason for it to = be extended. Alternatively a new provision for signalling the errors = between peers should be provided in new message (example: BGP = OPERATIONAL message).=20 =20 Thx, R. =20 =20 =20 =20 =20 =20 On Tue, Mar 7, 2017 at 1:42 AM, Susan Hares wrote: Enke and IDR WG: If there is enough concern about the extended messages covering all = messages versus UPDATE messages, I will need to do 1 week call on this = topic. Sue Hares -----Original Message----- From: Enke Chen [mailto:enkechen@cisco.com] Sent: Monday, March 6, 2017 3:22 PM To: Jeffrey Haas; Alvaro Retana (aretana) Cc: idr-chairs@ietf.org; draft-ietf-idr-bgp-extended-messages@ietf.org; = Susan Hares; idr@ietf.org; Enke Chen Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20 Hi, Folks: I see benefits and no drawbacks for the "BGP-Extended Message = Capability" to cover all the message types, that is, requiring a speaker = that advertises the capability to be able to receiving large messages of = any type. While the requirement for the large message is driven by the = UPDATE message, other messages (such as NOTIFICATION or OPEN) can = potentially exceed the 4K message size as well. It is better to deal = with this issue once. Clearly a large UPDATE message may require a large NOTIFICATION message, = e.g., for carrying a malformed attribute. Regarding the OPEN message, as BGP capabilities are carried inside the = OPEN message and a number of capabilities are AFI/SAFI specific and thus = have the "multiplier" effect on the message size, potentially the OPEN message may exceed the = message size in the future. This "extended message capability" can be = used in a couple of ways to deal with the large OPEN message if the = capability is made to mean support for all message types: o A speaker can remember the capability from its previous OPEN, and = infer that the large message is most likely supported over the current = session, and send the large OPEN message if needed. (It can back off from sending the = large OPEN based on NOTIFICATION message.) o A speaker can send a normal OPEN, and once it determines from the = received OPEN message that the large message capability is supported by the = remote speaker, the speaker can close the connection and start with a = large OPEN. Admittedly these mechanism are not as elegant as the one that bumps the = BGP version. They can be just as effective (especially the first one) in practice. Thanks. -- Enke On 2/28/17 1:06 PM, Jeffrey Haas wrote: > Alvaro, > > I'm not speaking for the authors. However, a few comments on your = writeup: > > On Thu, Feb 23, 2017 at 07:17:05PM +0000, Alvaro Retana (aretana) = wrote: >> M1. Section 4. (Operation): =E2=80=9CAn implementation that supports = the BGP >> Extended Messages MUST be prepared to receive an UPDATE message that >> is larger than 4096 bytes.=E2=80=9C Only UPDATEs? I know that the = most >> likely case for exceeding the 4k size is an UPDATE, but why are the >> other messages not considered? > > The fundamental issue is with regards to not only the basic behavior > of RFC 4271 and its earlier RFC 1771 but also to BGP Versioning. > > Those RFCs set the expectation that version 4 of BGP will have at most > a 4k packet size. Capability advertisement, an extension on top of > BGP, isn't a required feature - although it's certainly very common = these days. > > Thus, for backward compatibility reasons, OPEN messages must be no > bigger than 4k if we're still BGP-4. > > I don't think there's an argument for larger KEEPALIVE messages. :-) > > Similarly, the NOTIFICATION with no restrictions for version > compatibility reasons. *However*, once BGP has reached the > Established state, it is possible for it to send longer NOTIFICATION > messages, if we permitted it and the feature was duly negotiated. > This is probably not the best idea because it will still be necessary > to be able to deal with an old speaker in such cases. > > Also, most implementations don't dump that much information in the > NOTIFICATION Data section. Putting sufficient semantics on the > content would start to get messy. We don't want XML or backtrace over = that message. > > The case for UPDATE is clear. > > The remaining message with some potential motivation is ROUTE-REFRESH. > The basic refresh message is likely to be able to hold AFI/SAFI sets > for some time. The ORF feature that is built upon refresh already > deals with sending its filters over the course of multiple messages. > So, there's not a lot of motivation. > > And that's the messages we have so far. While I can see new messages > being defined that may want it, I don't think there's a strong > argument for it today. > >> Also, what does =E2=80=9Cprepared to receive=E2=80=9D >> mean, and how can =E2=80=9CMUST be prepared to receive=E2=80=9D be = enforced? Given >> the discussion in Section 5 (Error Handling), you might want to add >> something like =E2=80=9C=E2=80=A6even if the Capability is not = advertised=E2=80=9D. > > If the capability hasn't been negotiated, then the expectation is that > it's a PDU error and the session should be dropped. See prior > comments about BGP versioning. > >> M2. Section 5 (Error Handling). =E2=80=9CA BGP speaker that has the = ability >> to use extended messages but has not advertised the BGP Extended >> Messages capability, presumably due to configuration, SHOULD NOT >> accept an extended message. A speaker MAY implement a more liberal >> policy and accept extended messages even from a peer that has not >> advertised the capability.=E2=80=9D This paragraph troubles me a lot = because >> it is in direct contraction with Section 3: =E2=80=9CA peer which = does not >> advertise this capability MUST NOT send BGP Extended Messages, and >> BGP Extended Messages MUST NOT be sent to it.=E2=80=9D. However, I = think >> that John Scudder=E2=80=99s reasoning [3] makes sense ("keep the = session up >> at (almost) all costs", and there=E2=80=99s clear precedence in the = WG) for >> the case where the sender did advertise the Capability, but = I=E2=80=99m not >> convinced on the case where it didn=E2=80=99t =E2=80=93 please = include something like John=E2=80=99s explanation in the text. > > John can own this one. I find the case a little weaker. It vaguely > makes me want a probe message to verify that I can indeed get a > full-sized PDU through. > >> M5. Section 5 (Error Handling). =E2=80=9CThe inconsistency between = the local and >> remote BGP speakers MUST be reported via syslog and/or SNMP.=E2=80=9D = SNMP? >> AFAIK, there=E2=80=99s no object that can report this inconsistency = since >> there=E2=80=99s no NOTIFICATION generated. In the proposed text by = Gunter >> Van De Velde [4], SNMP and syslog were mentioned as examples = =E2=80=93 I >> suggest you follow that path (no need for all the =E2=80=9Cflowery = language=E2=80=9D) >> and just reference mechanisms by example to avoid having to point at = how it would be done. > > IMO, "brought to the attention of the operator. Example mechanisms > might include syslog or SNMP notifications." > > While you're correct that no IETF standard MIB object covers such a > scenario, we shouldn't be proscriptive about some vendor deciding they > want it in their enterprise implementation. > > At some point, we need similar boilerplate language for yang = notifications. > >> M7. What about transition/migration/partial deployment? What should >> the behavior be if, for example, an Extended Message UPDATE is >> received from a peer, but can=E2=80=99t be propagated to others = because they >> don=E2=80=99t support Extended Messages (think route reflectors or = simple >> eBGP -> iBGP)?? There should be some guidance for the general case >> (i.e. when the total size is >>> 4k due simply to the total amount of information, and not because a >> single attribute, for example, is really big), and some requirements >> looking forward to potential new messages/attributes that >> specifically rely on Extended Messages. > > I'm not sure such guidance belongs in this document. We already have > scenarios wherein normal protocol machinery can result in messages > that are too large. The expected behavior is "treat as withdraw" to > the next downstream, similar to the BGP Error handling RFC. > > Examples of this include AS_PATH or CLUSTER_LIST attributes needing to > add a new entry on a full PDU. > >> M7.2. What should the default be for this extension? Should it be = enabled by default or not? > > IMO, there are good reasons to not turn it on for existing BGP > deployments but alternatively good reasons once the extension is > widely enough present in a given topology. The latter example = includes bgpsec. > > -- Jeff > > _______________________________________________ > 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 =20 =20 ------=_NextPart_000_018D_01D2972C.DFE18620 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Robert:

<individual contributor hat on>

Let=E2=80=99s take this offline.=C2=A0 The complexity is in the = changes to the RFC4271 finite state machine.=C2=A0 I=E2=80=99m glad to = explain the design of the BGP FSM offline, but I=E2=80=99ve gone through = the precise reasons already on the mail list.=C2=A0 =C2=A0My suggestion = is to include all messages including future messages if = approved.=C2=A0=C2=A0

Sue

 

From:= = rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert = Raszuk
Sent: Tuesday, March 7, 2017 10:14 AM
To: = Susan Hares
Cc: Randy Bush; Enke Chen; Jeffrey Haas; Alvaro = Retana (aretana); idr-chairs@ietf.org; = draft-ietf-idr-bgp-extended-messages@ietf.org; idr wg
Subject: = Re: [Idr] AD Review of = draft-ietf-idr-bgp-extended-messages-20

 

Sue, 

 

I don't understand your point = of "more complex". 

 

Current proposal extends = single message type. I indicated that future defined messages needs also = to have an option to be extended with proposed = capability. 

 

That's = all. 

 

Thx,

Robert

 

 

 

On Tue, Mar 7, 2017 at 2:55 PM, Susan Hares <shares@ndzh.com> = wrote:

Robert:

 

<individual contributor hat on>

This is a more complex change to the state machine than just = extending all messages.

 

Sue Hares

 

From:= = rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert = Raszuk
Sent: Tuesday, March 7, 2017 5:09 AM
To: = Susan Hares; Randy Bush
Cc: Enke Chen; Jeffrey Haas; Alvaro = Retana (aretana); idr-chairs@ietf.org; draft-ietf-idr-bgp-extended-messages@ietf.org; idr = wg


Subject: Re: [Idr] AD Review of = draft-ietf-idr-bgp-extended-messages-20

 <= /o:p>

Hi Sue, = Authors,

 <= /o:p>

Current draft = says: 

 <= /o:p>

"Currently, the Extended = Message Capability only applies to UPDATE = messages."

 <= /o:p>

I would like to ask authors = to change the below restriction to also consider future BGP messages = still compliant with RFC4271 RFC. I would therefor propose to extend the = above sentence with:

 <= /o:p>

"The Extended Message = Capability applies to UPDATE messages as well as if required to any new = BGP messages."

 <= /o:p>

- - = -

 <= /o:p>

I am less concerned in making = Extended Message Capability applicable to OPEN or KEEPALIVE messages. = IMHO Capabilities from OPEN should be moved to new BGP message (BGP = CAPABILITIES MESSAGE) which would by design allow their dynamic nature = along the lines of current dynamic capabilities proposal except outside = of messing up with OPEN. 

 <= /o:p>

For NOTIFICATION as Enke = already pointed there is good reason for it to be extended. = Alternatively a new provision for signalling the errors between peers = should be provided in new message (example: BGP OPERATIONAL = message). 

 <= /o:p>

Thx,

R.

=

 <= /o:p>

 <= /o:p>

 <= /o:p>

 <= /o:p>

 

 <= /o:p>

On Tue, Mar = 7, 2017 at 1:42 AM, Susan Hares <shares@ndzh.com> wrote:

Enke and IDR = WG:
<WG chair hat on>
If there is enough concern about the = extended messages covering all messages versus UPDATE messages,  I = will need to do  1 week call on this topic.
<WG Chair hat = off>

Sue = Hares

-----Original = Message-----
From: Enke = Chen [mailto:enkechen@cisco.com]
Sent: Monday, March 6, 2017 3:22 = PM
To: Jeffrey Haas; = Alvaro Retana (aretana)
Cc: idr-chairs@ietf.org; draft-ietf-idr-bgp-extended-messages@ietf.org; = Susan Hares; idr@ietf.org; Enke Chen
Subject: Re: [Idr] AD Review of = draft-ietf-idr-bgp-extended-messages-20

Hi, = Folks:

I see benefits and no drawbacks for the "BGP-Extended = Message Capability" to cover all the message types, that is, = requiring a speaker that advertises the capability to be able to = receiving large messages of any type.  While the requirement for = the large message is driven by the UPDATE message, other messages (such = as NOTIFICATION or OPEN) can potentially exceed the 4K message size as = well. It is better to deal with this issue once.

Clearly a large = UPDATE message may require a large NOTIFICATION message, e.g., for = carrying a malformed attribute.

Regarding the OPEN message, as = BGP capabilities are carried inside the OPEN message and a number of = capabilities are AFI/SAFI specific and thus have the = "multiplier"
effect on the message size, potentially the = OPEN message may exceed the message size in the future. This = "extended message capability" can be used in a couple of ways = to deal with the large OPEN message if the capability is made to mean = support for all message types:

   o A speaker can = remember the capability from its previous OPEN, and infer that
  =    the large message is most likely supported over the current = session, and send
     the large OPEN message if = needed. (It can back off from sending the large OPEN
    =  based on NOTIFICATION message.)

   o A speaker = can send a normal OPEN, and once it determines from the = received
     OPEN message that the large message = capability is supported by the remote
     speaker, = the speaker can close the connection and start with a large = OPEN.

Admittedly these mechanism are not as elegant as the one = that bumps the BGP version.
They can be just as effective (especially = the first one) in practice.

Thanks.  -- Enke

On = 2/28/17 1:06 PM, Jeffrey Haas wrote:
> Alvaro,
>
> I'm = not speaking for the authors.  However, a few comments on your = writeup:
>
> On Thu, Feb 23, 2017 at 07:17:05PM +0000, = Alvaro Retana (aretana) wrote:
>> M1. Section 4. (Operation): = =E2=80=9CAn implementation that supports the BGP
>> Extended = Messages MUST be prepared to receive an UPDATE message that
>> = is larger than 4096 bytes.=E2=80=9C  Only UPDATEs?  I know = that the most
>> likely case for exceeding the 4k size is an = UPDATE, but why are the
>> other messages not = considered?
>
> The fundamental issue is with regards to not = only the basic behavior
> of RFC 4271 and its earlier RFC 1771 but = also to BGP Versioning.
>
> Those RFCs set the expectation = that version 4 of BGP will have at most
> a 4k packet size.  = Capability advertisement, an extension on top of
> BGP, isn't a = required feature - although it's certainly very common these = days.
>
> Thus, for backward compatibility reasons, OPEN = messages must be no
> bigger than 4k if we're still = BGP-4.
>
> I don't think there's an argument for larger = KEEPALIVE messages. :-)
>
> Similarly, the NOTIFICATION with = no restrictions for version
> compatibility reasons.  = *However*, once BGP has reached the
> Established state, it is = possible for it to send longer NOTIFICATION
> messages, if we = permitted it and the feature was duly negotiated.
> This is = probably not the best idea because it will still be necessary
> to = be able to deal with an old speaker in such cases.
>
> Also, = most implementations don't dump that much information in the
> = NOTIFICATION Data section.  Putting sufficient semantics on = the
> content would start to get messy.  We don't want XML or = backtrace over that message.
>
> The case for UPDATE is = clear.
>
> The remaining message with some potential = motivation is ROUTE-REFRESH.
> The basic refresh message is likely = to be able to hold AFI/SAFI sets
> for some time.  The ORF = feature that is built upon refresh already
> deals with sending = its filters over the course of multiple messages.
> So, there's = not a lot of motivation.
>
> And that's the messages we have = so far.  While I can see new messages
> being defined that = may want it, I don't think there's a strong
> argument for it = today.
>
>> Also, what does =E2=80=9Cprepared to = receive=E2=80=9D
>> mean, and how can =E2=80=9CMUST be prepared = to receive=E2=80=9D be enforced?  Given
>> the discussion = in Section 5 (Error Handling), you might want to add
>> = something like =E2=80=9C=E2=80=A6even if the Capability is not = advertised=E2=80=9D.
>
> If the capability hasn't been = negotiated, then the expectation is that
> it's a PDU error and = the session should be dropped.  See prior
> comments about = BGP versioning.
>
>> M2. Section 5 (Error = Handling).  =E2=80=9CA BGP speaker that has the ability
>> = to use extended messages but has not advertised the BGP = Extended
>> Messages capability, presumably due to = configuration, SHOULD NOT
>> accept an extended message.  = A speaker MAY implement a more liberal
>> policy and accept = extended messages even from a peer that has not
>> advertised = the capability.=E2=80=9D  This paragraph troubles me a lot = because
>> it is in direct contraction with Section 3: = =E2=80=9CA peer which does not
>> advertise this capability = MUST NOT send BGP Extended Messages, and
>> BGP Extended = Messages MUST NOT be sent to it.=E2=80=9D.  However, I = think
>> that John Scudder=E2=80=99s reasoning [3] makes sense = ("keep the session up
>> at (almost) all costs", and = there=E2=80=99s clear precedence in the WG) for
>> the case = where the sender did advertise the Capability, but I=E2=80=99m = not
>> convinced on the case where it didn=E2=80=99t =E2=80=93 = please include something like John=E2=80=99s explanation in the = text.
>
> John can own this one.  I find the case a = little weaker.  It vaguely
> makes me want a probe message to = verify that I can indeed get a
> full-sized PDU = through.
>
>> M5. Section 5 (Error Handling).  = =E2=80=9CThe inconsistency between the local and
>> remote BGP = speakers MUST be reported via syslog and/or SNMP.=E2=80=9D  =  SNMP?
>> AFAIK, there=E2=80=99s no object that can report = this inconsistency since
>> there=E2=80=99s no NOTIFICATION = generated.  In the proposed text by Gunter
>> Van De Velde = [4], SNMP and syslog were mentioned as examples =E2=80=93 I
>> = suggest you follow that path (no need for all the =E2=80=9Cflowery = language=E2=80=9D)
>> and just reference mechanisms by example = to avoid having to point at how it would be done.
>
> IMO, = "brought to the attention of the operator.  Example = mechanisms
> might include syslog or SNMP = notifications."
>
> While you're correct that no IETF = standard MIB object covers such a
> scenario, we shouldn't be = proscriptive about some vendor deciding they
> want it in their = enterprise implementation.
>
> At some point, we need = similar boilerplate language for yang notifications.
>
>> = M7. What about transition/migration/partial deployment?  What = should
>> the behavior be if, for example, an Extended Message = UPDATE is
>> received from a peer, but can=E2=80=99t be = propagated to others because they
>> don=E2=80=99t support = Extended Messages (think route reflectors or simple
>> eBGP = -> iBGP)??  There should be some guidance for the general = case
>> (i.e. when the total size is
>>> 4k due = simply to the total amount of information, and not because a
>> = single attribute, for example, is really big), and some = requirements
>> looking forward to potential new = messages/attributes that
>> specifically rely on Extended = Messages.
>
> I'm not sure such guidance belongs in this = document.  We already have
> scenarios wherein normal = protocol machinery can result in messages
> that are too = large.  The expected behavior is "treat as withdraw" = to
> the next downstream, similar to the BGP Error handling = RFC.
>
> Examples of this include AS_PATH or CLUSTER_LIST = attributes needing to
> add a new entry on a full = PDU.
>
>> M7.2. What should the default be for this = extension?  Should it be enabled by default or not?
>
> = IMO, there are good reasons to not turn it on for existing BGP
> = deployments but alternatively good reasons once the extension is
> = widely enough present in a given topology.  The latter example = includes bgpsec.
>
> -- Jeff
>
> = _______________________________________________
> 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

 <= /o:p>

 

------=_NextPart_000_018D_01D2972C.DFE18620-- From nobody Tue Mar 7 08:18:59 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9765129481; Tue, 7 Mar 2017 07:32:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.369 X-Spam-Level: X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.229, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZbKnY0pyqiat; Tue, 7 Mar 2017 07:32:49 -0800 (PST) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::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 62651129454; Tue, 7 Mar 2017 07:32:47 -0800 (PST) Received: by mail-qk0-x234.google.com with SMTP id 1so9203191qkl.3; Tue, 07 Mar 2017 07:32:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=YCbtC/YlmY6YwfmzwnPCiZtE5TY0KFA/+QvP8BnXbjs=; b=pdBU8QC/o+O7n5i8L6tIBLvfGTJXHlUG44+A8Mk0jvcQPWhNNuo3RAPJhkvi5L2aJ8 TUGceS+HGSK0Te/R8CcJLHMteXXyaDV5U8OhQrGtTynemuT2Zx/ucIzsKgdc2xqrpLLZ b21q56xyZGaUcC3suLtOjdcKpvv86La+VFl1f4wKCeHimhwSAIV81EIL2qeS/YwGmAz9 CdlTpAptycTG2Xl2tFL5vXENsupYaGj9Y4t8Oiu6sBG6eFa9w4lGMPpP9th7JCmG/chh LkWYOl2FfVg07Jw5xmA5hJbaCDLx5zZsjjn4ObXq8JK+TLet2NPJePBN/0xjcCZQ3dvK 8LWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=YCbtC/YlmY6YwfmzwnPCiZtE5TY0KFA/+QvP8BnXbjs=; b=oZSvXd6PqJZoh+CZhFwySXXbe6T7cxinabeVRMA3WnnTrpFHI7GVlJdTbzfn2ZxX5V TC4PE2VAvkxyEnBKgIgMk4V9Jx2Vwa0KCUydhY0fLoXlx0x8c3Kq3e4bOaJPXPWkxPf2 Z/urVnbf3ePS6olvIask0WqG16FOtvAv+A56reYgB9lC9D8u7TC1xcP5K5NtYe8d+AOA r1JALtERLUkt/Zbqbibw1ITafDJxC4u1KIP5yvfaZ4Y6yfqW6u/aU9qsSpU19D3I25fP a7b/VTrd+gzSVwz50Pk79RlyQE3GFOiK6QjPhZSZ16IBudiiaWZ1o/crIog52Rhn1/CN ChIA== X-Gm-Message-State: AMke39mUAfS69LIA4MWslv9VDptQhac/dMDPF/9SiCrtEbM9I3ffALWgzB++J7fZr6Eg5ag2S9ZKmV1fYoxvVQ== X-Received: by 10.200.62.145 with SMTP id y17mr1109234qtf.53.1488900766556; Tue, 07 Mar 2017 07:32:46 -0800 (PST) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.140.42.181 with HTTP; Tue, 7 Mar 2017 07:32:45 -0800 (PST) In-Reply-To: <018c01d29756$c8b4f610$5a1ee230$@ndzh.com> References: <20170228210627.GB17448@pfrc.org> <3eb4d853-1d44-6250-c70a-26f60eac39e6@cisco.com> <006e01d296db$a7c4c320$f74e4960$@ndzh.com> <010101d2974a$8520d060$8f627120$@ndzh.com> <018c01d29756$c8b4f610$5a1ee230$@ndzh.com> From: Robert Raszuk Date: Tue, 7 Mar 2017 16:32:45 +0100 X-Google-Sender-Auth: rVQJAv8wwHKDFg9z76ie0JqfI2M Message-ID: To: Susan Hares Content-Type: multipart/alternative; boundary=f403045e6b284bf09f054a25b945 Archived-At: Cc: idr wg , idr-chairs@ietf.org, draft-ietf-idr-bgp-extended-messages@ietf.org Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 15:32:52 -0000 --f403045e6b284bf09f054a25b945 Content-Type: text/plain; charset=UTF-8 Hi Sue, > My suggestion is to include all messages including future messages if approved. Ahh then it is great - we are in sync ! My other comments were just an opinion ... but if it is easier to extend all messages then perfect. Cheers, R. --f403045e6b284bf09f054a25b945 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Sue,

> My suggestion is to include all messages including future messages i= f approved. =C2=A0

Ahh then it is great - we are in s= ync !=C2=A0

My other comments were just an opinion ... bu= t if it is easier to extend all messages then perfect.=C2=A0

Cheers,
R.


<= /div> --f403045e6b284bf09f054a25b945-- From nobody Tue Mar 7 08:19:11 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D69E31295ED; Tue, 7 Mar 2017 07:39:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.947 X-Spam-Level: X-Spam-Status: No, score=0.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6NiTtvyN-2X7; Tue, 7 Mar 2017 07:39:54 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 08B3C1295CE; Tue, 7 Mar 2017 07:37:59 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.90.29; From: "Susan Hares" To: "'Robert Raszuk'" References: <20170228210627.GB17448@pfrc.org> <3eb4d853-1d44-6250-c70a-26f60eac39e6@cisco.com> <006e01d296db$a7c4c320$f74e4960$@ndzh.com> <010101d2974a$8520d060$8f627120$@ndzh.com> <018c01d29756$c8b4f610$5a1ee230$@ndzh.com> In-Reply-To: Date: Tue, 7 Mar 2017 10:32:55 -0500 Message-ID: <01b301d29758$180458e0$480d0aa0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01B4_01D2972E.2F304CB0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQInnAj+Yxa8tap/yfCJFXAjQYwk1wJi0XFfAwzFclUBlnEaYAHWMN+rAr58MhwCyGvcFQMczvZ5Ak2aXIygQQsqUA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'idr wg' , idr-chairs@ietf.org, draft-ietf-idr-bgp-extended-messages@ietf.org Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 15:39:55 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01B4_01D2972E.2F304CB0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Robert: =20 Yep - Easier to just include all messages. =20 =20 Sue=20 =20 From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert = Raszuk Sent: Tuesday, March 7, 2017 10:33 AM To: Susan Hares Cc: Randy Bush; Enke Chen; Jeffrey Haas; Alvaro Retana (aretana); = idr-chairs@ietf.org; draft-ietf-idr-bgp-extended-messages@ietf.org; idr = wg Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20 =20 Hi Sue, =20 > My suggestion is to include all messages including future messages if = approved. =20 =20 Ahh then it is great - we are in sync !=20 =20 My other comments were just an opinion ... but if it is easier to extend = all messages then perfect.=20 =20 Cheers, R. =20 =20 ------=_NextPart_000_01B4_01D2972E.2F304CB0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Robert:

<individual contributor=E2=80=99s hat on> =

Yep=C2=A0 - Easier to just include all messages. = =C2=A0

 

Sue

 

From:= = rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert = Raszuk
Sent: Tuesday, March 7, 2017 10:33 AM
To: = Susan Hares
Cc: Randy Bush; Enke Chen; Jeffrey Haas; Alvaro = Retana (aretana); idr-chairs@ietf.org; = draft-ietf-idr-bgp-extended-messages@ietf.org; idr wg
Subject: = Re: [Idr] AD Review of = draft-ietf-idr-bgp-extended-messages-20

 

Hi Sue,

 

> My suggestion is to include all messages including future = messages if approved.  

 

Ahh then it is great - we are in sync ! 

 

My other comments were just an opinion ... but if it is easier to = extend all messages then perfect. 

 

Cheers,

R.

 

 

------=_NextPart_000_01B4_01D2972E.2F304CB0-- From nobody Tue Mar 7 08:57:29 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C43B1294D0 for ; Tue, 7 Mar 2017 08:57:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OD7x3pr9LL-e for ; Tue, 7 Mar 2017 08:57:26 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 880AB128AB0 for ; Tue, 7 Mar 2017 08:57:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7256; q=dns/txt; s=iport; t=1488905846; x=1490115446; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=srkfENP5BSA+eVbkPDn/FIktNplN5mWKq9L8w1k42Nk=; b=RfCYzH//L4Ha2zGr6rUikwvJQSdB5HHsH9SQEaliY8ZJA/ebthbF7xgU hyX6YJDdjeI0ztR+YP3E5LiM2kyWJk0oVZr4Y7crQtWaO8zTLb+GY8nJx v+f4vIbbKepdW3/EDyTidJbj60UBeXijPNWnFTDJyw8SA9GsZ3i9ZmkQQ M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D5AQAh5b5Y/4UNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5jYYEKB4NYigyRS4gNh36FLIINhiICGoIMPxgBAgEBAQEBAQF?= =?us-ascii?q?rKIUVAQEBBCMKTBACAQgOAwMBAigDAgICHxEUCQgBAQQBDQWJZwMVsA6CJoc5D?= =?us-ascii?q?YM2AQEBAQEBAQEBAQEBAQEBAQEBAQEBHYZOggWCaoJRgiOCZi6CMQWbdjoBjgy?= =?us-ascii?q?EKoF7hSKKAopTiGcBHziBA1YVPxEBhEIdgWN1iQaBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.36,258,1486425600"; d="scan'208,217";a="394701070" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Mar 2017 16:57:24 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v27GvOdq021233 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 7 Mar 2017 16:57:24 GMT Received: from xch-rcd-019.cisco.com (173.37.102.29) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 7 Mar 2017 10:57:24 -0600 Received: from xch-rcd-019.cisco.com ([173.37.102.29]) by XCH-RCD-019.cisco.com ([173.37.102.29]) with mapi id 15.00.1210.000; Tue, 7 Mar 2017 10:57:24 -0600 From: "Arjun Sreekantiah (asreekan)" To: Susan Hares , "idr@ietf.org" Thread-Topic: [Idr] draft-ietf-idr-bgp-prefix-sid-04 - IPR call Thread-Index: AdKMceb+tcnatgNgTpy4nKexMAmXNwK4TjgA Date: Tue, 7 Mar 2017 16:57:23 +0000 Message-ID: <0A1CE9FD-A2A8-4F0C-8B33-48B6075072D9@cisco.com> References: <00a901d28c72$1dba3a70$592eaf50$@ndzh.com> In-Reply-To: <00a901d28c72$1dba3a70$592eaf50$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.15.1.160411 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.68.190] Content-Type: multipart/alternative; boundary="_000_0A1CE9FDA2A84F0C8B3348B6075072D9ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "Clarence Filsfils \(cfilsfil\)" , 'Keyur Patel' , 'Saikat Ray' , "bruno.decraene@orange.com" , 'Hannes Gredler' Subject: Re: [Idr] draft-ietf-idr-bgp-prefix-sid-04 - IPR call X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 16:57:28 -0000 --_000_0A1CE9FDA2A84F0C8B3348B6075072D9ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmW0gbm90IGF3YXJlIG9mIGFueSBJUFIgb3RoZXIgdGhhbiB0aGUgb25lcyBhbHJlYWR5IGRp c2Nsb3NlZC4NCg0KQXJqdW4NCg0KRnJvbTogSWRyIDxpZHItYm91bmNlc0BpZXRmLm9yZzxtYWls dG86aWRyLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgU3VzYW4gSGFyZXMgPHNoYXJl c0BuZHpoLmNvbTxtYWlsdG86c2hhcmVzQG5kemguY29tPj4NCkRhdGU6IFR1ZXNkYXksIEZlYnJ1 YXJ5IDIxLCAyMDE3IGF0IDEwOjQxIEFNDQpUbzogImlkckBpZXRmLiBMaXN0IiA8aWRyQGlldGYu b3JnPG1haWx0bzppZHJAaWV0Zi5vcmc+Pg0KQ2M6ICJDbGFyZW5jZSBGaWxzZmlscyAoY2ZpbHNm aWwpIiA8Y2ZpbHNmaWxAY2lzY28uY29tPG1haWx0bzpjZmlsc2ZpbEBjaXNjby5jb20+PiwgJ0tl eXVyIFBhdGVsJyA8a2V5dXJAYXJyY3VzLmNvbTxtYWlsdG86a2V5dXJAYXJyY3VzLmNvbT4+LCAn U2Fpa2F0IFJheScgPHJheXNhaWthdEBnbWFpbC5jb208bWFpbHRvOnJheXNhaWthdEBnbWFpbC5j b20+PiwgImJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb208bWFpbHRvOmJydW5vLmRlY3JhZW5lQG9y YW5nZS5jb20+IiA8YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbTxtYWlsdG86YnJ1bm8uZGVjcmFl bmVAb3JhbmdlLmNvbT4+LCAnSGFubmVzIEdyZWRsZXInIDxoYW5uZXNAcnRicmljay5jb208bWFp bHRvOmhhbm5lc0BydGJyaWNrLmNvbT4+DQpTdWJqZWN0OiBbSWRyXSBkcmFmdC1pZXRmLWlkci1i Z3AtcHJlZml4LXNpZC0wNCAtIElQUiBjYWxsDQoNClN0ZWZhbm8sIENsYXJlbmNlLCBBY2VlLCBL ZXl1ciwgSGFubmVzLCBhbmQgU2Fpa2F0Og0KDQpQbGVhc2UgaW5kaWNhdGUgd2hldGhlciB5b3Ug a25vdyBvZiBhbnkgSVBSIGZvciBkcmFmdC1pZXRmLWJncC1wcmVmaXgtc2lkLTA0LnR4dC4gICBB ZnRlciB3ZSBoYXZlIGFsbCBvZiB5b3VyIElQUiBjYWxscywgd2Ugd2lsbCBiZWdpbiB0aGUgV0cg TEMgZm9yIHRoaXMgZG9jdW1lbnQuDQoNClN1ZSBIYXJlcw0K --_000_0A1CE9FDA2A84F0C8B3348B6075072D9ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <1AFA4DF9F679364BB4412932C28A1DFF@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpOyI+SeKAmW0gbm90 IGF3YXJlIG9mIGFueSBJUFIgb3RoZXIgdGhhbiB0aGUgb25lcyBhbHJlYWR5IGRpc2Nsb3NlZC48 L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+QXJqdW48L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXYgaWQ9Ik1BQ19PVVRMT09LX1NJR05BVFVSRSI+PC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9E WV9TRUNUSU9OIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZTox MnB0OyB0ZXh0LWFsaWduOmxlZnQ7IGNvbG9yOmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRpdW0g bm9uZTsgQk9SREVSLUxFRlQ6IG1lZGl1bSBub25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQQURE SU5HLUxFRlQ6IDBpbjsgUEFERElORy1SSUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFw dCBzb2xpZDsgQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8 c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTogPC9zcGFuPklkciAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmlkci1ib3VuY2VzQGlldGYub3JnIj5pZHItYm91bmNlc0BpZXRmLm9yZzwvYT4m Z3Q7IG9uIGJlaGFsZiBvZiBTdXNhbiBIYXJlcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNoYXJlc0Bu ZHpoLmNvbSI+c2hhcmVzQG5kemguY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13 ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9zcGFuPlR1ZXNkYXksIEZlYnJ1YXJ5IDIxLCAyMDE3IGF0IDEw OjQxIEFNPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+JnF1 b3Q7aWRyQGlldGYuIExpc3QmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzppZHJAaWV0Zi5vcmci PmlkckBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQi PkNjOiA8L3NwYW4+JnF1b3Q7Q2xhcmVuY2UgRmlsc2ZpbHMgKGNmaWxzZmlsKSZxdW90OyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmNmaWxzZmlsQGNpc2NvLmNvbSI+Y2ZpbHNmaWxAY2lzY28uY29tPC9h PiZndDssICdLZXl1ciBQYXRlbCcgJmx0OzxhIGhyZWY9Im1haWx0bzprZXl1ckBhcnJjdXMuY29t Ij5rZXl1ckBhcnJjdXMuY29tPC9hPiZndDssICdTYWlrYXQgUmF5JyAmbHQ7PGEgaHJlZj0ibWFp bHRvOnJheXNhaWthdEBnbWFpbC5jb20iPnJheXNhaWthdEBnbWFpbC5jb208L2E+Jmd0OywNCiAm cXVvdDs8YSBocmVmPSJtYWlsdG86YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbSI+YnJ1bm8uZGVj cmFlbmVAb3JhbmdlLmNvbTwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpicnVuby5kZWNy YWVuZUBvcmFuZ2UuY29tIj5icnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tPC9hPiZndDssICdIYW5u ZXMgR3JlZGxlcicgJmx0OzxhIGhyZWY9Im1haWx0bzpoYW5uZXNAcnRicmljay5jb20iPmhhbm5l c0BydGJyaWNrLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQi PlN1YmplY3Q6IDwvc3Bhbj5bSWRyXSBkcmFmdC1pZXRmLWlkci1iZ3AtcHJlZml4LXNpZC0wNCAt IElQUiBjYWxsPGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gc3R5bGU9Im1z by1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+DQo8ZGl2IHhtbG5zOnY9InVybjpzY2hlbWFz LW1pY3Jvc29mdC1jb206dm1sIiB4bWxuczpvPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9m ZmljZTpvZmZpY2UiIHhtbG5zOnc9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOndv cmQiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vb2ZmaWNlLzIwMDQvMTIv b21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPg0KPG1ldGEgbmFt ZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVt KSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxp Lk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlz aXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFp bFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPGRpdiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIg dmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+U3RlZmFubywgQ2xhcmVuY2UsIEFjZWUsIEtleXVyLCBIYW5uZXMsIGFuZCBTYWlr YXQ6IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QbGVhc2UgaW5kaWNhdGUgd2hldGhlciB5b3Ug a25vdyBvZiBhbnkgSVBSIGZvciBkcmFmdC1pZXRmLWJncC1wcmVmaXgtc2lkLTA0LnR4dC4mbmJz cDsmbmJzcDsgQWZ0ZXIgd2UgaGF2ZSBhbGwgb2YgeW91ciBJUFIgY2FsbHMsIHdlIHdpbGwgYmVn aW4gdGhlIFdHIExDIGZvciB0aGlzIGRvY3VtZW50Lg0KPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlN1ZSBIYXJlcyA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvc3Bh bj48L3NwYW4+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_0A1CE9FDA2A84F0C8B3348B6075072D9ciscocom_-- From nobody Tue Mar 7 09:54:16 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BDF5129467 for ; Tue, 7 Mar 2017 09:54:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.947 X-Spam-Level: X-Spam-Status: No, score=0.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cavDn2w_smjU for ; Tue, 7 Mar 2017 09:54:13 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 E1D7E12945A for ; Tue, 7 Mar 2017 09:54:12 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=70.194.20.38; From: "Susan Hares" To: "'Arjun Sreekantiah \(asreekan\)'" , References: <00a901d28c72$1dba3a70$592eaf50$@ndzh.com> <0A1CE9FD-A2A8-4F0C-8B33-48B6075072D9@cisco.com> In-Reply-To: <0A1CE9FD-A2A8-4F0C-8B33-48B6075072D9@cisco.com> Date: Tue, 7 Mar 2017 12:49:00 -0500 Message-ID: <00c401d2976b$1ad83ec0$5088bc40$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C5_01D29741.3204F5E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLRmZ897QD/Rst3CoPQS8v4sIhJ4QEZZzpCn4LXiGA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: "'Clarence Filsfils \(cfilsfil\)'" , 'Keyur Patel' , 'Saikat Ray' , bruno.decraene@orange.com, 'Hannes Gredler' Subject: Re: [Idr] draft-ietf-idr-bgp-prefix-sid-04 - IPR call X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 17:54:14 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00C5_01D29741.3204F5E0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Arjun:=20 =20 Thank you for the IPR statement. =20 =20 Sue=20 =20 From: Arjun Sreekantiah (asreekan) [mailto:asreekan@cisco.com]=20 Sent: Tuesday, March 7, 2017 11:57 AM To: Susan Hares; idr@ietf.org Cc: Clarence Filsfils (cfilsfil); 'Keyur Patel'; 'Saikat Ray'; = bruno.decraene@orange.com; 'Hannes Gredler'; Stefano Previdi (sprevidi) Subject: Re: [Idr] draft-ietf-idr-bgp-prefix-sid-04 - IPR call =20 I=E2=80=99m not aware of any IPR other than the ones already disclosed. =20 Arjun =20 From: Idr on behalf of Susan Hares = Date: Tuesday, February 21, 2017 at 10:41 AM To: "idr@ietf. List " Cc: "Clarence Filsfils (cfilsfil)" , 'Keyur Patel' = , 'Saikat Ray' , = "bruno.decraene@orange.com" , 'Hannes = Gredler' Subject: [Idr] draft-ietf-idr-bgp-prefix-sid-04 - IPR call =20 Stefano, Clarence, Acee, Keyur, Hannes, and Saikat:=20 =20 Please indicate whether you know of any IPR for = draft-ietf-bgp-prefix-sid-04.txt. After we have all of your IPR calls, = we will begin the WG LC for this document.=20 =20 Sue Hares=20 ------=_NextPart_000_00C5_01D29741.3204F5E0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Arjun:

 

Thank you for the IPR = statement.=C2=A0 =C2=A0=C2=A0

 

Sue =

 

From:= = Arjun Sreekantiah (asreekan) [mailto:asreekan@cisco.com] =
Sent: Tuesday, March 7, 2017 11:57 AM
To: Susan = Hares; idr@ietf.org
Cc: Clarence Filsfils (cfilsfil); 'Keyur = Patel'; 'Saikat Ray'; bruno.decraene@orange.com; 'Hannes Gredler'; = Stefano Previdi (sprevidi)
Subject: Re: [Idr] = draft-ietf-idr-bgp-prefix-sid-04 - IPR = call

 

I=E2=80=99m not aware of any IPR = other than the ones already = disclosed.

 

=

Arjun

<= /div>

 

=

From: = Idr <idr-bounces@ietf.org> on = behalf of Susan Hares <shares@ndzh.com>
Date: = Tuesday, February 21, 2017 at 10:41 AM
To: "idr@ietf. List" <idr@ietf.org>
Cc: = "Clarence Filsfils (cfilsfil)" <cfilsfil@cisco.com>, 'Keyur = Patel' <keyur@arrcus.com>, = 'Saikat Ray' <raysaikat@gmail.com>, = "bruno.decraene@orange.com&q= uot; <bruno.decraene@orange.com&g= t;, 'Hannes Gredler' <hannes@rtbrick.com>
Subje= ct: [Idr] draft-ietf-idr-bgp-prefix-sid-04 - IPR call

<= p class=3DMsoNormal> 

=

Stefano, = Clarence, Acee, Keyur, Hannes, and Saikat:

 

Please indicate whether = you know of any IPR for draft-ietf-bgp-prefix-sid-04.txt.   = After we have all of your IPR calls, we will begin the WG LC for this = document.

 

Sue Hares =

------=_NextPart_000_00C5_01D29741.3204F5E0-- From nobody Tue Mar 7 10:45:27 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B61B712959B; Tue, 7 Mar 2017 10:45:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52zM_uFgVPbS; Tue, 7 Mar 2017 10:45:24 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77D69129467; Tue, 7 Mar 2017 10:45:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1413; q=dns/txt; s=iport; t=1488912324; x=1490121924; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=zREL1chkkdssh8yLd1DdX8WbYfadIFr4CWZcWjYvp4s=; b=aC2aLIW7ba1vlJrz8GLpV7mn/rw3c2omKE3i+nuMns1eoAz0UQ95q2CA k+Ak+CCh9sf8nqU6FhtjT+m8zCmQK+aM+MdtauT09G/EGh/Cj+Syusgcj uS/bnaHzLWh2cmmhX+hZ26F/gXg3bseif428neWLhin1ynjYot/NQdvTw w=; X-IronPort-AV: E=Sophos;i="5.36,258,1486425600"; d="scan'208";a="215460846" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Mar 2017 18:45:24 +0000 Received: from [10.24.73.40] ([10.24.73.40]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v27IjMIC027393; Tue, 7 Mar 2017 18:45:22 GMT To: Susan Hares References: <20170228210627.GB17448@pfrc.org> <3eb4d853-1d44-6250-c70a-26f60eac39e6@cisco.com> <006e01d296db$a7c4c320$f74e4960$@ndzh.com> <010101d2974a$8520d060$8f627120$@ndzh.com> <018c01d29756$c8b4f610$5a1ee230$@ndzh.com> <01b301d29758$180458e0$480d0aa0$@ndzh.com> From: Enke Chen Message-ID: Date: Tue, 7 Mar 2017 10:45:22 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <01b301d29758$180458e0$480d0aa0$@ndzh.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: 'idr wg' , 'Robert Raszuk' , idr-chairs@ietf.org, draft-ietf-idr-bgp-extended-messages@ietf.org Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 18:45:25 -0000 Hi, Folks: o There is no extra work for a receiver to cover message types other than UPDATE. o There is a little bit work for a sender that wishes to send a large OPEN (e.g., using the prior capability and possibly subsequent NOTIFICATION). Additionally, I do not see a need to touch on the FSM specified in RFC 4271 even in the case of sending a large OPEN, which potentially may involve two separate consecutive sessions but each session would just follow the existing FSM. Thanks. -- Enke On 3/7/17 7:32 AM, Susan Hares wrote: > Robert: > > > > Yep - Easier to just include all messages. > > > > Sue > > > > *From:*rraszuk@gmail.com [mailto:rraszuk@gmail.com] *On Behalf Of *Robert Raszuk > *Sent:* Tuesday, March 7, 2017 10:33 AM > *To:* Susan Hares > *Cc:* Randy Bush; Enke Chen; Jeffrey Haas; Alvaro Retana (aretana); idr-chairs@ietf.org; draft-ietf-idr-bgp-extended-messages@ietf.org; idr wg > *Subject:* Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20 > > > > Hi Sue, > > > >> My suggestion is to include all messages including future messages if approved. > > > > Ahh then it is great - we are in sync ! > > > > My other comments were just an opinion ... but if it is easier to extend all messages then perfect. > > > > Cheers, > > R. > > > > > From nobody Tue Mar 7 11:53:21 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82D7012948D; Tue, 7 Mar 2017 11:53:19 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft1331857.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wftV5bJ1hA76; Tue, 7 Mar 2017 11:53:17 -0800 (PST) Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.164]) (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 C2B4A129426; Tue, 7 Mar 2017 11:53:17 -0800 (PST) Received: from pure.maildistiller.com (unknown [10.110.50.29]) by dispatch1-us1.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTP id 658068006E; Tue, 7 Mar 2017 19:53:16 +0000 (UTC) X-Virus-Scanned: Proofpoint Essentials engine Received: from mx6-us1.ppe-hosted.com (unknown [10.110.49.251]) by pure.maildistiller.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 49E3B60058; Tue, 7 Mar 2017 19:53:16 +0000 (UTC) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01lp0119.outbound.protection.outlook.com [207.46.163.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx6-us1.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 397D44C0077; Tue, 7 Mar 2017 19:53:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT1331857.onmicrosoft.com; s=selector1-arrcus-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=bjhl5XVbwIO8wSAV1Qz0GquTXU+GjOCK2SZ44sb1d8I=; b=a6GyhBAfd+rnmooHW4Is3dAJ/VCVUAXtow2GXoPy6d4AV8fo1YWvngHwiRPDnZR8s8WtvbOs8UqNo8FZcJK7qD2JMG21Tx2jDcYYNcvmKFYr4d8iTERXmUHEJIM46ckHl9vtlBpkpU6WMabIqhYhAoZQ2+E5SB2OPFeYaNO3nME= Received: from BY2PR18MB0262.namprd18.prod.outlook.com (10.163.72.152) by BY2PR18MB0263.namprd18.prod.outlook.com (10.163.72.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.961.14; Tue, 7 Mar 2017 19:53:07 +0000 Received: from BY2PR18MB0262.namprd18.prod.outlook.com ([10.163.72.152]) by BY2PR18MB0262.namprd18.prod.outlook.com ([10.163.72.152]) with mapi id 15.01.0947.020; Tue, 7 Mar 2017 19:53:07 +0000 From: Keyur Patel To: Susan Hares , 'Shitanshu Shah' , 'Ron Bonica' , "rtg-dir@ietf.org" , "draft-ietf-idr-sla-exchange.all@ietf.org" , "idr@ietf.org" Thread-Topic: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 Thread-Index: AdKIcLCEU+uutt39QyCrZCwOKAXyLQAcLKCoAUVZnUABwWlZAABkf7iDAAHoygAAKNQfgA== Date: Tue, 7 Mar 2017 19:53:06 +0000 Message-ID: References: <053401d294fc$6f739180$4e5ab480$@ndzh.com> <00b401d29696$11e5a850$35b0f8f0$@ndzh.com> In-Reply-To: <00b401d29696$11e5a850$35b0f8f0$@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;ndzh.com; dmarc=none action=none header.from=arrcus.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [96.68.143.133] x-ms-office365-filtering-correlation-id: ce6b79e8-206d-46da-7cfd-08d465939348 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BY2PR18MB0263; x-microsoft-exchange-diagnostics: 1; BY2PR18MB0263; 7:7AEKkrHLSj1/xmhEGCbeWEVAu/eym+Dix5j2ZY5VVmF+zp8AzEhUt6xuYAYg0iJ/hfjnaatdZvPbLo305+Ze2iY1pvcNlfKZYV7lJLIT5SUkf38XMT8j/iLn54IabRyehjiqZk0s+TCQNWMFY5G31WuMbmQ6GjGe7F6frkEo257HBCK3gwXOyz11w77TIudmHIS3BOO/M3nUOiArdymKflKhDWEfUjNazXseUczAlENYTlfu37p0cw8S6p0fz+29LcEBj4PFbX0P53qdO2YfU3FnnHYSUFKKpLB+PC7KJqsDYwxf4ZeXYJM6PuGoe8Dm+sWfkKC9QK5QjohXtpgXlA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(97927398514766)(95692535739014)(18271650672692)(194151415913766)(21748063052155)(154440410675630)(50582790962513); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123564025)(20161123560025)(20161123555025)(20161123558025)(20161123562025)(2016111802025)(6072148)(6043046); SRVR:BY2PR18MB0263; BCL:0; PCL:0; RULEID:; SRVR:BY2PR18MB0263; x-forefront-prvs: 0239D46DB6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39830400002)(39410400002)(39450400003)(54094003)(377454003)(3846002)(93886004)(39060400002)(3660700001)(38730400002)(2906002)(86362001)(6246003)(230783001)(6116002)(53546006)(6506006)(2900100001)(3280700002)(189998001)(2501003)(8676002)(1941001)(2950100002)(102836003)(66066001)(53936002)(25786008)(81166006)(8666007)(122556002)(77096006)(83716003)(2201001)(76176999)(50986999)(6486002)(6436002)(54356999)(229853002)(82746002)(5660300001)(36756003)(33656002)(7736002)(6512007)(99286003)(6306002)(54896002)(8936002)(236005)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR18MB0263; H:BY2PR18MB0262.namprd18.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_A99C2EDDD7424DCDA0B93E249449078Earrcuscom_" MIME-Version: 1.0 X-OriginatorOrg: arrcus.com X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Mar 2017 19:53:06.8869 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 697b3529-5c2b-40cf-a019-193eb78f6820 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR18MB0263 X-MDID: 1488916396-ciskaKmhPV07 Archived-At: Subject: Re: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 19:53:19 -0000 --_000_A99C2EDDD7424DCDA0B93E249449078Earrcuscom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU3VlLCBSb24sIEFsdmFybywNCg0KQXMgU2hpdGFuc2h1IGhhcyBzdGF0ZWQgaW4gIzIgdGhh dCBpc3N1ZXMgaW4gaW1wbGVtZW50aW5nIFNMQXMgaW4gZm9yd2FyZGluZyBhcmUgbW9zdGx5IGlt cGxlbWVudGF0aW9uIHNwZWNpZmljLiBUbyB0aGF0IHBvaW50LCB3ZSBjb3VsZCBhZGQgdGV4dCBz dWdnZXN0aW5nIHRoYXQgc3VmZmljaWVudCBsb2dnaW5nIHNob3VsZCBiZSBkb25lIHNvIGFzIHRv IGFsbG93IG9wZXJhdG9ycyB0byBpbnRlcnZlbmUgYW5kIHNvbHZlIHRoZSBpc3N1ZS4gIFdvdWxk IHRoYXQgYmUgc3VmZmljaWVudD8NCg0KUGxlYXNlIGFkdmlzZS4NCg0KUmVnYXJkcywNCktleXVy DQoNCkZyb206IFN1c2FuIEhhcmVzIDxzaGFyZXNAbmR6aC5jb20+DQpEYXRlOiBNb25kYXksIE1h cmNoIDYsIDIwMTcgYXQgODoyNCBBTQ0KVG86ICdTaGl0YW5zaHUgU2hhaCcgPHNoaXRhbnNodV9z aGFoQGhvdG1haWwuY29tPiwgJ1JvbiBCb25pY2EnIDxyYm9uaWNhQGp1bmlwZXIubmV0PiwgInJ0 Zy1kaXJAaWV0Zi5vcmciIDxydGctZGlyQGlldGYub3JnPiwgImRyYWZ0LWlldGYtaWRyLXNsYS1l eGNoYW5nZS5hbGxAaWV0Zi5vcmciIDxkcmFmdC1pZXRmLWlkci1zbGEtZXhjaGFuZ2UuYWxsQGll dGYub3JnPiwgImlkckBpZXRmLm9yZyIgPGlkckBpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBbUlRH LURJUl0gUnRnRGlyIHJldmlldzogZHJhZnQtaWV0Zi1pZHItc2xhLWV4Y2hhbmdlLTEwDQpSZXNl bnQtRnJvbTogPGFsaWFzLWJvdW5jZXNAaWV0Zi5vcmc+DQpSZXNlbnQtVG86IDxsdWlzLnRvbW90 YWtpQHZlcml6b24uY29tPiwgPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+LCA8c2hpdGFu c2h1X3NoYWhAaG90bWFpbC5jb20+LCA8a2V5dXJAYXJyY3VzLmNvbT4sIDxzYmFqYWpAanVuaXBl ci5uZXQ+LCA8amdzQGp1bmlwZXIubmV0PiwgPHNoYXJlc0BuZHpoLmNvbT4sIDxqaWUuZG9uZ0Bo dWF3ZWkuY29tPiwgPGFyZXRhbmFAY2lzY28uY29tPiwgPGRiMzU0NkBhdHQuY29tPiwgPGFrYXRs YXNAZ21haWwuY29tPiwgPHNraEBuZHpoLmNvbT4NClJlc2VudC1EYXRlOiBNb25kYXksIE1hcmNo IDYsIDIwMTcgYXQgODoyOSBBTQ0KDQpTaGl0YW5zaHU6DQoNClJvbiBpcyBkaXNjdXNzaW5nIHlv dXIgcG9pbnQgIzIg4oCTIHlvdSBuZWVkIHRvIGVuZ2FnZSBoaW0gb24gaXNzdWUgIzIuICAgIFlv dSBjYW4gcHJvdmlkZSBpbnB1dCBmcm9tIG9wZXJhdG9ycyB3aG8gaW5kaWNhdGUgdGhpcyBpcyBu ZWNlc3NhcnksIGJ1dCBpdCBpcyBpbXBvcnRhbnQgdG8gaGF2ZSB0aGlzIGRpc2N1c3Npb24uICBB bHZhcm8gd2FzIGNvbmNlcm5lZCBhYm91dCB0aGUgZGVwbG95bWVudHMgb2YgdGhlc2UgYXR0cmli dXRlcy4NCg0KU3VlDQoNCkZyb206IFNoaXRhbnNodSBTaGFoIFttYWlsdG86c2hpdGFuc2h1X3No YWhAaG90bWFpbC5jb21dDQpTZW50OiBNb25kYXksIE1hcmNoIDYsIDIwMTcgMTA6MzEgQU0NClRv OiBTdXNhbiBIYXJlczsgJ1JvbiBCb25pY2EnOyBydGctZGlyQGlldGYub3JnOyBkcmFmdC1pZXRm LWlkci1zbGEtZXhjaGFuZ2UuYWxsQGlldGYub3JnOyBpZHJAaWV0Zi5vcmcNClN1YmplY3Q6IFJl OiBbUlRHLURJUl0gUnRnRGlyIHJldmlldzogZHJhZnQtaWV0Zi1pZHItc2xhLWV4Y2hhbmdlLTEw DQoNCg0KSGkgU3VlLA0KDQoNCg0KRm9sbG93aW5nIGlzIHdoYXQgSSBoYWQgcmVzcG9uZGVkIHRv IFJvbi4gSG9wZWZ1bGx5IHRoYXQgYWRkcmVzc2VzL2NsYXJpZmllcy4NCg0KDQoNClRvIGJyZWFr IGl0IGRvd24gaW4gdHdvIHBvaW50IHJlc3BvbnNlLA0KDQoNCg0KMSkgVGhpcyBkcmFmdCBpcyBu b3QgY2hhbmdpbmcgaG93IFNMQSBpcyBlc3RhYmxpc2hlZCBhdCBmaXJzdCBwbGFjZS4gVGhlIGRy YWZ0IGlzIHByb3ZpZGluZyBhIG1ldGhvZCB0byBjb252ZXkgdGhpcyBhIHByaW9yaSBlc3RhYmxp c2hlZCBTTEEgdG8gaGVscCByZWR1Y2UgbG90IG9mIG1hbnVhbCBjb21wbGV4aXRpZXMgYW5kIGVy cm9ycyB0byBhZG1pbi4gVGh1cyBnaXZlbiBhIGtub3dsZWRnZSBvZiB3aGF0IFNMQSBpcyBlc3Rh Ymxpc2hlZCwgaW4gZ2VuZXJhbCBkZXZpY2VzIHNob3VsZCBiZSBjYXBhYmxlIHRvIHN1cHBvcnQg dGhhdCBlc3RhYmxpc2hlZCBTTEEuDQoNCg0KDQoNCg0KMikgSWYgdGhlcmUgc3RpbGwgYXJlIGFu eSBpc3N1ZXMgaW4gaW1wbGVtZW50aW5nIGV4Y2hhbmdlZCBTTEEgaW4gZm9yd2FyZGluZywgd2Ug dGhpbmsgdGhleSBlaXRoZXIgYXJlIGltcGxlbWVudGF0aW9uIHNwZWNpZmljIG9yIG9mIHRlbXBv cmFyeSBuYXR1cmUgd2hlcmUgZm9yIGV4YW1wbGUgZW5vdWdoIHJlc291cmNlcyBub3QgYXZhaWxh YmxlIGF0IGFueSBzcGVjaWZpYyBwb2ludCBvZiBhIHRpbWUuDQoNCg0KDQpXZSBmZWVsIHRoYXQg aW4gY3VycmVudCBzdGF0ZSBvZiB0aGUgZHJhZnQsIGl0IGNhbiBiZSBsYXJnZWx5IHVzZWZ1bCBp biBkZXBsb3ltZW50cy4NCg0KDQoNCg0KDQoNCg0KT25lIGNhbiBpbWFnaW5lIHRob3VnaCBldmVu IGVzdGFibGlzaG1lbnQgb2YgU0xBIGFsc28gY2FuIGJlIGRvbmUgdmlhIGV4Y2hhbmdpbmcgaXQg b3ZlciBiZ3AuIEhvd2V2ZXIsIG5lZ290aWF0aW9uIG9mIFNMQSBkb2VzIG5vdCBoYXZlIHRvIGJl IGNsdWJiZWQgd2l0aCBleGNoYW5nZSBvZiBTTEEuIE5lZ290aWF0aW9uIG9mIFNMQSBpcyBub3Qg aW4gdGhpcyBzY29wZS4NCg0KDQpSZWdhcmRzLA0KU2hpdGFuc2h1DQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpGcm9tOiBTdXNhbiBIYXJlcyA8c2hhcmVzQG5kemguY29tPG1h aWx0bzpzaGFyZXNAbmR6aC5jb20+Pg0KU2VudDogU2F0dXJkYXksIE1hcmNoIDQsIDIwMTcgODoz MSBBTQ0KVG86ICdSb24gQm9uaWNhJzsgJ1NoaXRhbnNodSBTaGFoJzsgcnRnLWRpckBpZXRmLm9y ZzxtYWlsdG86cnRnLWRpckBpZXRmLm9yZz47IGRyYWZ0LWlldGYtaWRyLXNsYS1leGNoYW5nZS5h bGxAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtaWRyLXNsYS1leGNoYW5nZS5hbGxAaWV0Zi5v cmc+OyBpZHJAaWV0Zi5vcmc8bWFpbHRvOmlkckBpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBbUlRH LURJUl0gUnRnRGlyIHJldmlldzogZHJhZnQtaWV0Zi1pZHItc2xhLWV4Y2hhbmdlLTEwDQoNClNo aXRhbnNodToNCg0KUGxlYXNlIGFkZHJlc3MgUm9u4oCZcyBjb21tZW50IGFib3V0IHdpZGVseSBk ZXBsb3llZC4gIEkgYmVsaWV2ZSB0aGlzIHdhcyBwYXJ0IG9mIEFsdmFyb+KAmXMgY29tbWVudHMu DQoNClN1ZQ0KDQpGcm9tOiBydGctZGlyIFttYWlsdG86cnRnLWRpci1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgUm9uIEJvbmljYQ0KU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDIzLCAy MDE3IDEyOjA3IFBNDQpUbzogU2hpdGFuc2h1IFNoYWg7IHJ0Zy1kaXJAaWV0Zi5vcmc8bWFpbHRv OnJ0Zy1kaXJAaWV0Zi5vcmc+OyBkcmFmdC1pZXRmLWlkci1zbGEtZXhjaGFuZ2UuYWxsQGlldGYu b3JnPG1haWx0bzpkcmFmdC1pZXRmLWlkci1zbGEtZXhjaGFuZ2UuYWxsQGlldGYub3JnPjsgaWRy QGlldGYub3JnPG1haWx0bzppZHJAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW1JURy1ESVJdIFJ0 Z0RpciByZXZpZXc6IGRyYWZ0LWlldGYtaWRyLXNsYS1leGNoYW5nZS0xMA0KDQpIZWxsbywNCg0K VGhlIGRyYWZ0IGlzIGludGVybmFsbHkgY29uc2lzdGVudC4gQnV0IGdpdmVuIHdoYXQgaXMgbGVm dCBvdXQgb2Ygc2NvcGUsIEkgd29uZGVyIGlmIHRoZSBuZXcgYXR0cmlidXRlcyB3aWxsIGV2ZXIg YmUgd2lkZWx5IGRlcGxveWVkLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJvbg0KDQoNCg0K VGhpcyBkb2N1bWVudCBtaWdodCBiZW5lZml0IGZyb20gZGlzY3Vzc2lvbiBvZiBvcGVyYXRpb25h bCBpc3N1ZXMuIEkgYXNzdW1lIHRoYXQgd2hlbiBhIEJHUCBsaXN0ZW5lciBsZWFybnMgYSByb3V0 ZSB3aXRoIHRoZSBTTEEgRXhjaGFuZ2UgQXR0cmlidXRlLCBpdCBwcm92aXNpb25zIGNsYXNzIG9m IHNlcnZpY2UgZm9yd2FyZGluZyBjbGFzc2VzIG9uIGludGVyZmFjZXMuDQoNCg0KIyNzdnNoYWgs IHRob3VnaCB0aGlzIGlzIG9uZSBkZXNpcmVkIHVzZSBvZiBleGNoYW5naW5nIFNMQSBjb250ZW50 LCB0aGUgZHJhZnQgZm9jdXNlcyBvbiB0cmFuc3BvcnRpbmcgU0xBIGNvbnRlbnQgZnJvbSB0aGUg U0xBIFByb2R1Y2VyIHRvIHRoZSBTTEEgQ29uc3VtZXIuIFByb2Nlc3Npbmcgb2YgdGhlIFFvUyBh dHRyaWJ1dGUgY29udGVudCwgYXQgdGhlIFNMQSBDb25zdW1lciwgaXMgb3V0c2lkZSB0aGUgc2Nv cGUgb2YgdGhpcyBkb2N1bWVudC4NCg0KDQoNCiMjc3ZzaGFoLCBMZXQgbWUga25vdyBpZiB5b3Ug aGF2ZSBhIHN1Z2dlc3Rpb24gdG8gbWFrZSBkZXNjcmlwdGlvbiBjbGVhcmVyIGluIFNlY3Rpb24g MSBhbmQgMiB0byBoaWdobGlnaHQgdGhpcy4NCg0KDQpJIGFsc28gYXNzdW1lIHRoYXQgYSkgaXQg dGFrZXMgdGltZSB0byBwcm92aXNpb24gY2xhc3Mgb2Ygc2VydmljZSBmb3J3YXJkaW5nIGNsYXNz ZXMgYW5kIGIpIHRoZSBudW1iZXIgb2YgZm9yd2FyZGluZyBjbGFzc2VzIHRoYXQgY2FuIGJlIHBy b3Zpc2lvbmVkIGFyZSBmaW5pdGUuIFdoYXQgZG9lcyB0aGUgQkdQIGxpc3RlbmVyIGRvIHdoZW4g dGhlIG51bWJlciBvZiBmb3J3YXJkaW5nIGNsYXNzZXMgcmVxdWVzdGVkIGV4Y2VlZHMgaXRzIGNh cGFjaXR5IHRvIGRlbGl2ZXI/DQoNCg0KIyNzdnNoYWgsIFNpbmNlIHNjb3BlIG9mIHRoZSBkb2N1 bWVudCBpcyB0byB0cmFuc3BvcnQgU0xBIGNvbnRlbnQgZnJvbSB0aGUgU0xBIFByb2R1Y2VyIHRv IHRoZSBTTEEgQ29uc3VtZXIsIHRoZSBkb2N1bWVudCBjb25zaWRlcnMgZXJyb3IgaGFuZGxpbmcg aW4gdGhlIGNvbnRleHQgb2YgdHJhbnNwb3J0aW5nIGRhdGEgYW5kIHRodXMgYW55IGZvcm1hdGlu ZyBlcnJvcnMgYW5kIHNlbWFudGljcyBlcnJvcnMgd2l0aGluIHRoYXQgY29udGV4dC4gQW55IGVy cm9ycyBpbiB0aGUgY29udGV4dCBvZiBwcm9jZXNzaW5nIFFvUyBhdHRyaWJ1dGUgY29udGVudCBh dCB0aGUgU0xBIENvbnN1bWVyIGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoZSBkb2N1bWVudC4N Cg0KDQoNCg0K --_000_A99C2EDDD7424DCDA0B93E249449078Earrcuscom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxuczptdj0iaHR0cDovL21hY1ZtbFNj aGVtYVVyaSIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPg0KPGhlYWQ+ DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hh cnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJUaXRsZSIgY29udGVudD0iIj4NCjxtZXRhIG5hbWU9 IktleXdvcmRzIiBjb250ZW50PSIiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJN aWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8IS0tW2lmICFtc29dPjxzdHls ZT52XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQpvXDoqIHtiZWhhdmlvcjp1cmwo I2RlZmF1bHQjVk1MKTt9DQp3XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQouc2hh cGUge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCjwvc3R5bGU+PCFbZW5kaWZdLS0+PHN0 eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAx MSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpNZW5sbzsNCglw YW5vc2UtMToyIDExIDYgOSAzIDggNCAyIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFy IjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4w cHQ7DQoJZm9udC1mYW1pbHk6VGFob21hO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1z dHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OlRhaG9tYTt9DQpz cGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWls eTpDYWxpYnJpOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgljb2xvcjp3 aW5kb3d0ZXh0O30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6 dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm b250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBp bjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xv cj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5IaSBTdWUsIFJvbiwgQWx2YXJv LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPkFzIFNoaXRhbnNodSBoYXMgc3RhdGVkIGluICMy IHRoYXQgaXNzdWVzIGluIGltcGxlbWVudGluZyBTTEFzIGluIGZvcndhcmRpbmcgYXJlIG1vc3Rs eSBpbXBsZW1lbnRhdGlvbiBzcGVjaWZpYy4gVG8gdGhhdCBwb2ludCwgd2UgY291bGQgYWRkIHRl eHQgc3VnZ2VzdGluZyB0aGF0IHN1ZmZpY2llbnQgbG9nZ2luZyBzaG91bGQNCiBiZSBkb25lIHNv IGFzIHRvIGFsbG93IG9wZXJhdG9ycyB0byBpbnRlcnZlbmUgYW5kIHNvbHZlIHRoZSBpc3N1ZS4m bmJzcDsgV291bGQgdGhhdCBiZSBzdWZmaWNpZW50PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmki PlBsZWFzZSBhZHZpc2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+UmVnYXJkcyw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5LZXl1cjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+DQo8L2I+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2siPlN1c2FuIEhhcmVzICZsdDtz aGFyZXNAbmR6aC5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPk1vbmRheSwgTWFyY2ggNiwgMjAx NyBhdCA4OjI0IEFNPGJyPg0KPGI+VG86IDwvYj4nU2hpdGFuc2h1IFNoYWgnICZsdDtzaGl0YW5z aHVfc2hhaEBob3RtYWlsLmNvbSZndDssICdSb24gQm9uaWNhJyAmbHQ7cmJvbmljYUBqdW5pcGVy Lm5ldCZndDssICZxdW90O3J0Zy1kaXJAaWV0Zi5vcmcmcXVvdDsgJmx0O3J0Zy1kaXJAaWV0Zi5v cmcmZ3Q7LCAmcXVvdDtkcmFmdC1pZXRmLWlkci1zbGEtZXhjaGFuZ2UuYWxsQGlldGYub3JnJnF1 b3Q7ICZsdDtkcmFmdC1pZXRmLWlkci1zbGEtZXhjaGFuZ2UuYWxsQGlldGYub3JnJmd0OywgJnF1 b3Q7aWRyQGlldGYub3JnJnF1b3Q7ICZsdDtpZHJAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVj dDogPC9iPlJFOiBbUlRHLURJUl0gUnRnRGlyIHJldmlldzogZHJhZnQtaWV0Zi1pZHItc2xhLWV4 Y2hhbmdlLTEwPGJyPg0KPGI+UmVzZW50LUZyb206IDwvYj4mbHQ7YWxpYXMtYm91bmNlc0BpZXRm Lm9yZyZndDs8YnI+DQo8Yj5SZXNlbnQtVG86IDwvYj4mbHQ7bHVpcy50b21vdGFraUB2ZXJpem9u LmNvbSZndDssICZsdDttb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tJmd0OywgJmx0O3NoaXRh bnNodV9zaGFoQGhvdG1haWwuY29tJmd0OywgJmx0O2tleXVyQGFycmN1cy5jb20mZ3Q7LCAmbHQ7 c2JhamFqQGp1bmlwZXIubmV0Jmd0OywgJmx0O2pnc0BqdW5pcGVyLm5ldCZndDssICZsdDtzaGFy ZXNAbmR6aC5jb20mZ3Q7LCAmbHQ7amllLmRvbmdAaHVhd2VpLmNvbSZndDssICZsdDthcmV0YW5h QGNpc2NvLmNvbSZndDssICZsdDtkYjM1NDZAYXR0LmNvbSZndDssICZsdDtha2F0bGFzQGdtYWls LmNvbSZndDssDQogJmx0O3NraEBuZHpoLmNvbSZndDs8YnI+DQo8Yj5SZXNlbnQtRGF0ZTogPC9i Pk1vbmRheSwgTWFyY2ggNiwgMjAxNyBhdCA4OjI5IEFNPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6IzFGNDk3RCI+U2hpdGFuc2h1Og0KPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOiMxRjQ5N0QiPlJvbiBpcyBk aXNjdXNzaW5nIHlvdXIgcG9pbnQgIzIg4oCTIHlvdSBuZWVkIHRvIGVuZ2FnZSBoaW0gb24gaXNz dWUgIzIuJm5ic3A7ICZuYnNwOyZuYnNwO1lvdSBjYW4gcHJvdmlkZSBpbnB1dCBmcm9tIG9wZXJh dG9ycyB3aG8gaW5kaWNhdGUgdGhpcyBpcyBuZWNlc3NhcnksIGJ1dCBpdCBpcyBpbXBvcnRhbnQg dG8gaGF2ZSB0aGlzDQogZGlzY3Vzc2lvbi4mbmJzcDsgQWx2YXJvIHdhcyBjb25jZXJuZWQgYWJv dXQgdGhlIGRlcGxveW1lbnRzIG9mIHRoZXNlIGF0dHJpYnV0ZXMuIDwvc3Bhbj4NCjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOiMxRjQ5N0QiPlN1ZQ0KPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 VGFob21hIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6VGFob21hIj4gU2hpdGFuc2h1IFNoYWggW21haWx0bzpzaGl0YW5zaHVfc2hhaEBo b3RtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIE1hcmNoIDYsIDIwMTcgMTA6 MzEgQU08YnI+DQo8Yj5Ubzo8L2I+IFN1c2FuIEhhcmVzOyAnUm9uIEJvbmljYSc7IHJ0Zy1kaXJA aWV0Zi5vcmc7IGRyYWZ0LWlldGYtaWRyLXNsYS1leGNoYW5nZS5hbGxAaWV0Zi5vcmc7IGlkckBp ZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1JURy1ESVJdIFJ0Z0RpciByZXZpZXc6 IGRyYWZ0LWlldGYtaWRyLXNsYS1leGNoYW5nZS0xMDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxkaXYgaWQ9ImRpdnRhZ2RlZmF1bHR3cmFwcGVyIj4NCjxwPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj5IaSBTdWUsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHA+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2siPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJp O2NvbG9yOmJsYWNrIj5Gb2xsb3dpbmcgaXMgd2hhdCBJIGhhZCByZXNwb25kZWQgdG8gUm9uLiBI b3BlZnVsbHkmbmJzcDt0aGF0IGFkZHJlc3Nlcy9jbGFyaWZpZXMuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2siPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpD YWxpYnJpO2NvbG9yOmJsYWNrIj5UbyBicmVhayBpdCBkb3duIGluIHR3byBwb2ludCByZXNwb25z ZSw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2Fs aWJyaTtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2siPjEpIFRoaXMgZHJhZnQgaXMg bm90IGNoYW5naW5nIGhvdyBTTEEgaXMgZXN0YWJsaXNoZWQgYXQgZmlyc3QgcGxhY2UuIFRoZSBk cmFmdCZuYnNwO2lzIHByb3ZpZGluZyBhIG1ldGhvZCB0byBjb252ZXkgdGhpcyBhIHByaW9yaSBl c3RhYmxpc2hlZCZuYnNwO1NMQSB0byBoZWxwIHJlZHVjZSBsb3Qgb2YgbWFudWFsIGNvbXBsZXhp dGllcyBhbmQgZXJyb3JzIHRvIGFkbWluLiBUaHVzDQogZ2l2ZW4gYSBrbm93bGVkZ2Ugb2Ygd2hh dCBTTEEgaXMgZXN0YWJsaXNoZWQsIGluIGdlbmVyYWwgZGV2aWNlcyBzaG91bGQgYmUgY2FwYWJs ZSB0byBzdXBwb3J0IHRoYXQgZXN0YWJsaXNoZWQmbmJzcDtTTEEuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2siPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpD YWxpYnJpO2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+MikgSWYgdGhlcmUgc3Rp bGwgYXJlIGFueSBpc3N1ZXMgaW4gaW1wbGVtZW50aW5nIGV4Y2hhbmdlZCBTTEEgaW4gZm9yd2Fy ZGluZywgd2UgdGhpbmsgdGhleSBlaXRoZXIgYXJlIGltcGxlbWVudGF0aW9uIHNwZWNpZmljIG9y Jm5ic3A7b2YgdGVtcG9yYXJ5IG5hdHVyZSB3aGVyZSBmb3IgZXhhbXBsZSBlbm91Z2ggcmVzb3Vy Y2VzIG5vdCBhdmFpbGFibGUgYXQgYW55IHNwZWNpZmljDQogcG9pbnQgb2YgYSB0aW1lLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpO2Nv bG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+V2UgZmVlbCB0aGF0IGluIGN1cnJlbnQg c3RhdGUgb2YgdGhlIGRyYWZ0LCBpdCBjYW4gYmUgbGFyZ2VseSB1c2VmdWwgaW4gZGVwbG95bWVu dHMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNh bGlicmk7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpi bGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2siPk9uZSBjYW4gaW1hZ2luZSB0aG91Z2ggZXZlbiBl c3RhYmxpc2htZW50IG9mIFNMQSBhbHNvIGNhbiZuYnNwO2JlIGRvbmUgdmlhIGV4Y2hhbmdpbmcg aXQgb3ZlciBiZ3AuIEhvd2V2ZXIsIG5lZ290aWF0aW9uIG9mIFNMQSBkb2VzIG5vdCBoYXZlIHRv IGJlIGNsdWJiZWQgd2l0aCBleGNoYW5nZSBvZiBTTEEuIE5lZ290aWF0aW9uIG9mIFNMQSBpcyBu b3QgaW4gdGhpcyBzY29wZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTpDYWxpYnJpO2NvbG9yOmJsYWNrIj5SZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTpDYWxpYnJpO2NvbG9yOmJsYWNrIj5TaGl0YW5zaHU8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJj ZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OkNhbGlicmk7Y29sb3I6YmxhY2siPg0KPGhyIHNpemU9IjIiIHdpZHRoPSI5OCUiIGFsaWduPSJj ZW50ZXIiPg0KPC9zcGFuPjwvZGl2Pg0KPGRpdiBpZD0iZGl2UnBseUZ3ZE1zZyI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpDYWxpYnJpO2NvbG9yOmJsYWNrIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+IFN1c2FuIEhhcmVz ICZsdDs8YSBocmVmPSJtYWlsdG86c2hhcmVzQG5kemguY29tIj5zaGFyZXNAbmR6aC5jb208L2E+ Jmd0Ozxicj4NCjxiPlNlbnQ6PC9iPiBTYXR1cmRheSwgTWFyY2ggNCwgMjAxNyA4OjMxIEFNPGJy Pg0KPGI+VG86PC9iPiAnUm9uIEJvbmljYSc7ICdTaGl0YW5zaHUgU2hhaCc7IDxhIGhyZWY9Im1h aWx0bzpydGctZGlyQGlldGYub3JnIj5ydGctZGlyQGlldGYub3JnPC9hPjsNCjxhIGhyZWY9Im1h aWx0bzpkcmFmdC1pZXRmLWlkci1zbGEtZXhjaGFuZ2UuYWxsQGlldGYub3JnIj5kcmFmdC1pZXRm LWlkci1zbGEtZXhjaGFuZ2UuYWxsQGlldGYub3JnPC9hPjsNCjxhIGhyZWY9Im1haWx0bzppZHJA aWV0Zi5vcmciPmlkckBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtSVEct RElSXSBSdGdEaXIgcmV2aWV3OiBkcmFmdC1pZXRmLWlkci1zbGEtZXhjaGFuZ2UtMTA8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2siPg0KPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6 IzFGNDk3RCI+U2hpdGFuc2h1Og0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxp YnJpO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 Q2FsaWJyaTtjb2xvcjojMUY0OTdEIj5QbGVhc2UgYWRkcmVzcyBSb27igJlzIGNvbW1lbnQgYWJv dXQgd2lkZWx5IGRlcGxveWVkLiZuYnNwOyBJIGJlbGlldmUgdGhpcyB3YXMgcGFydCBvZiBBbHZh cm/igJlzIGNvbW1lbnRzLg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJp O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2Fs aWJyaTtjb2xvcjojMUY0OTdEIj5TdWUNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 Q2FsaWJyaTtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpUYWhvbWE7Y29sb3I6Ymxh Y2siPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTpUYWhvbWE7Y29sb3I6YmxhY2siPiBydGctZGlyIFs8YSBocmVmPSJtYWlsdG86cnRnLWRp ci1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86cnRnLWRpci1ib3VuY2VzQGlldGYub3JnPC9hPl0N CjxiPk9uIEJlaGFsZiBPZiA8L2I+Um9uIEJvbmljYTxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2Rh eSwgRmVicnVhcnkgMjMsIDIwMTcgMTI6MDcgUE08YnI+DQo8Yj5Ubzo8L2I+IFNoaXRhbnNodSBT aGFoOyA8YSBocmVmPSJtYWlsdG86cnRnLWRpckBpZXRmLm9yZyI+cnRnLWRpckBpZXRmLm9yZzwv YT47DQo8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1pZHItc2xhLWV4Y2hhbmdlLmFsbEBpZXRm Lm9yZyI+ZHJhZnQtaWV0Zi1pZHItc2xhLWV4Y2hhbmdlLmFsbEBpZXRmLm9yZzwvYT47DQo8YSBo cmVmPSJtYWlsdG86aWRyQGlldGYub3JnIj5pZHJAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVj dDo8L2I+IFJlOiBbUlRHLURJUl0gUnRnRGlyIHJldmlldzogZHJhZnQtaWV0Zi1pZHItc2xhLWV4 Y2hhbmdlLTEwPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6IzFGNDk3RCI+SGVsbG8sPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjojMUY0OTdEIj5UaGUg ZHJhZnQgaXMgaW50ZXJuYWxseSBjb25zaXN0ZW50LiBCdXQgZ2l2ZW4gd2hhdCBpcyBsZWZ0IG91 dCBvZiBzY29wZSwgSSB3b25kZXIgaWYgdGhlIG5ldyBhdHRyaWJ1dGVzIHdpbGwgZXZlcg0KIGJl IHdpZGVseSBkZXBsb3llZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDYWxp YnJpO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBSb248L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+PGJyPg0KVGhpcyBk b2N1bWVudCBtaWdodCBiZW5lZml0IGZyb20gZGlzY3Vzc2lvbiBvZiBvcGVyYXRpb25hbCBpc3N1 ZXMuIEkgYXNzdW1lIHRoYXQgd2hlbiBhIEJHUCBsaXN0ZW5lciBsZWFybnMgYSByb3V0ZSB3aXRo IHRoZSBTTEEgRXhjaGFuZ2UgQXR0cmlidXRlLCBpdCBwcm92aXNpb25zIGNsYXNzIG9mIHNlcnZp Y2UgZm9yd2FyZGluZyBjbGFzc2VzIG9uIGludGVyZmFjZXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVw dDtmb250LWZhbWlseTpNZW5sbztjb2xvcjpibGFjayI+IyNzdnNoYWgsIHRob3VnaCB0aGlzIGlz IG9uZSBkZXNpcmVkIHVzZSBvZiBleGNoYW5naW5nIFNMQSBjb250ZW50LCB0aGUgZHJhZnQgZm9j dXNlcyBvbiB0cmFuc3BvcnRpbmcgU0xBIGNvbnRlbnQgZnJvbSB0aGUgU0xBIFByb2R1Y2VyIHRv IHRoZSBTTEEgQ29uc3VtZXIuIFByb2Nlc3Npbmcgb2YgdGhlIFFvUyBhdHRyaWJ1dGUgY29udGVu dCwNCiBhdCB0aGUgU0xBIENvbnN1bWVyLCBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIGRv Y3VtZW50Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtaW4taGVpZ2h0OjEzcHgi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6Ymxh Y2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OC41cHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6YmxhY2siPiMjc3ZzaGFoLCBMZXQgbWUg a25vdyBpZiB5b3UgaGF2ZSBhIHN1Z2dlc3Rpb24gdG8gbWFrZSBkZXNjcmlwdGlvbiBjbGVhcmVy IGluIFNlY3Rpb24gMSBhbmQgMiB0byBoaWdobGlnaHQgdGhpcy48L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2siPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xv cjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj5JIGFsc28gYXNzdW1lIHRoYXQgYSkgaXQgdGFrZXMg dGltZSB0byBwcm92aXNpb24gY2xhc3Mgb2Ygc2VydmljZSBmb3J3YXJkaW5nIGNsYXNzZXMgYW5k IGIpIHRoZSBudW1iZXIgb2YgZm9yd2FyZGluZw0KIGNsYXNzZXMgdGhhdCBjYW4gYmUgcHJvdmlz aW9uZWQgYXJlIGZpbml0ZS4gV2hhdCBkb2VzIHRoZSBCR1AgbGlzdGVuZXIgZG8gd2hlbiB0aGUg bnVtYmVyIG9mIGZvcndhcmRpbmcgY2xhc3NlcyByZXF1ZXN0ZWQgZXhjZWVkcyBpdHMgY2FwYWNp dHkgdG8gZGVsaXZlcj8mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1m YW1pbHk6TWVubG87Y29sb3I6YmxhY2siPiMjc3ZzaGFoLCBTaW5jZSBzY29wZSBvZiB0aGUgZG9j dW1lbnQgaXMgdG8gdHJhbnNwb3J0IFNMQSBjb250ZW50IGZyb20gdGhlIFNMQSBQcm9kdWNlciB0 byB0aGUgU0xBIENvbnN1bWVyLCB0aGUgZG9jdW1lbnQgY29uc2lkZXJzIGVycm9yIGhhbmRsaW5n IGluIHRoZSBjb250ZXh0IG9mIHRyYW5zcG9ydGluZyBkYXRhIGFuZCB0aHVzIGFueQ0KIGZvcm1h dGluZyBlcnJvcnMgYW5kIHNlbWFudGljcyBlcnJvcnMgd2l0aGluIHRoYXQgY29udGV4dC4gQW55 IGVycm9ycyBpbiB0aGUgY29udGV4dCBvZiBwcm9jZXNzaW5nIFFvUyBhdHRyaWJ1dGUgY29udGVu dCBhdCB0aGUgU0xBIENvbnN1bWVyIGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoZSBkb2N1bWVu dC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6Ymxh Y2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 Q2FsaWJyaTtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_A99C2EDDD7424DCDA0B93E249449078Earrcuscom_-- From nobody Tue Mar 7 14:07:14 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8421294E1; Tue, 7 Mar 2017 14:07:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hVBgloacq9c4; Tue, 7 Mar 2017 14:07:12 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 717C1129473; Tue, 7 Mar 2017 14:07:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1712; q=dns/txt; s=iport; t=1488924432; x=1490134032; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=k361KZV50E0EVGn9XQwJWQi8UGYK0LL4eAMnW6dG3Kw=; b=fyeL6b/b5jyFRZcgZZrqg4Tdo9VlPSrR0OQB7JM5XEgUQkwQoA/bquUH 73HzQ8/bTZvJ1exx0jhNcWh3jKA3IaUx+ig8YM2ExB/imk1VMp+u0o49V Mh8ZFwK1dIX4yMREAlmEWL/CtHE0yC7vOdQyVPh4TPYuGerKbK2rn6plD A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AcAgDnLb9Y/5hdJa1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBg1GBaweDWIoMpwKCDYYiAhqCET8YAQIBAQEBAQEBayiFFgYjBA1FEAI?= =?us-ascii?q?BCA4MAiYCAgIwFRACBA4FiX+wX4FsOop8AQEBAQEBAQEBAQEBAQEBAQEBAQEBH?= =?us-ascii?q?YELhUOCBYJqh1ougjEBBJV3hjkBkjYKgXGPJIhDincBHziBA1YVUAGGQnWJBoE?= =?us-ascii?q?NAQEB?= X-IronPort-AV: E=Sophos;i="5.36,260,1486425600"; d="scan'208";a="393910184" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Mar 2017 22:07:11 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v27M7Bus016512 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 7 Mar 2017 22:07:11 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 7 Mar 2017 16:07:10 -0600 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Tue, 7 Mar 2017 16:07:10 -0600 From: "Alvaro Retana (aretana)" To: Jeffrey Haas Thread-Topic: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20 Thread-Index: AQHSjglrFbHoeYS2WUyxb/MV1DegzqF/VY+AgAq9dwA= Date: Tue, 7 Mar 2017 22:07:10 +0000 Message-ID: References: <20170228210627.GB17448@pfrc.org> In-Reply-To: <20170228210627.GB17448@pfrc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.6] Content-Type: text/plain; charset="utf-8" Content-ID: <4C2EFB91C0BB184682C9184804EEB4DA@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "idr-chairs@ietf.org" , "draft-ietf-idr-bgp-extended-messages@ietf.org" , Susan Hares , "idr@ietf.org" Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 22:07:13 -0000 T24gMi8yOC8xNywgNDowNiBQTSwgIkplZmZyZXkgSGFhcyIgPGpoYWFzQHBmcmMub3JnPiB3cm90 ZToNCg0K4oCmDQo+ID5NNy4gV2hhdCBhYm91dCB0cmFuc2l0aW9uL21pZ3JhdGlvbi9wYXJ0aWFs IGRlcGxveW1lbnQ/ICBXaGF0IHNob3VsZCB0aGUNCj4gPmJlaGF2aW9yIGJlIGlmLCBmb3IgZXhh bXBsZSwgYW4gRXh0ZW5kZWQgTWVzc2FnZSBVUERBVEUgaXMgcmVjZWl2ZWQgZnJvbSBhDQo+ID5w ZWVyLCBidXQgY2Fu4oCZdCBiZSBwcm9wYWdhdGVkIHRvIG90aGVycyBiZWNhdXNlIHRoZXkgZG9u 4oCZdCBzdXBwb3J0DQo+ID5FeHRlbmRlZCBNZXNzYWdlcyAodGhpbmsgcm91dGUgcmVmbGVjdG9y cyBvciBzaW1wbGUgZUJHUCAtPiBpQkdQKT8/ICBUaGVyZQ0KPiA+c2hvdWxkIGJlIHNvbWUgZ3Vp ZGFuY2UgZm9yIHRoZSBnZW5lcmFsIGNhc2UgKGkuZS4gd2hlbiB0aGUgdG90YWwgc2l6ZSBpcw0K PiA+PjRrIGR1ZSBzaW1wbHkgdG8gdGhlIHRvdGFsIGFtb3VudCBvZiBpbmZvcm1hdGlvbiwgYW5k IG5vdCBiZWNhdXNlIGENCj4gPnNpbmdsZSBhdHRyaWJ1dGUsIGZvciBleGFtcGxlLCBpcyByZWFs bHkgYmlnKSwgYW5kIHNvbWUgcmVxdWlyZW1lbnRzDQo+ID5sb29raW5nIGZvcndhcmQgdG8gcG90 ZW50aWFsIG5ldyBtZXNzYWdlcy9hdHRyaWJ1dGVzIHRoYXQgc3BlY2lmaWNhbGx5DQo+ID5yZWx5 IG9uIEV4dGVuZGVkIE1lc3NhZ2VzLg0KPg0KPiBJJ20gbm90IHN1cmUgc3VjaCBndWlkYW5jZSBi ZWxvbmdzIGluIHRoaXMgZG9jdW1lbnQuICBXZSBhbHJlYWR5IGhhdmUNCj4gc2NlbmFyaW9zIHdo ZXJlaW4gbm9ybWFsIHByb3RvY29sIG1hY2hpbmVyeSBjYW4gcmVzdWx0IGluIG1lc3NhZ2VzIHRo YXQgYXJlDQo+IHRvbyBsYXJnZS4gIFRoZSBleHBlY3RlZCBiZWhhdmlvciBpcyAidHJlYXQgYXMg d2l0aGRyYXciIHRvIHRoZSBuZXh0DQo+IGRvd25zdHJlYW0sIHNpbWlsYXIgdG8gdGhlIEJHUCBF cnJvciBoYW5kbGluZyBSRkMuDQo+DQo+IEV4YW1wbGVzIG9mIHRoaXMgaW5jbHVkZSBBU19QQVRI IG9yIENMVVNURVJfTElTVCBhdHRyaWJ1dGVzIG5lZWRpbmcgdG8gYWRkIGENCj4gbmV3IGVudHJ5 IG9uIGEgZnVsbCBQRFUuDQoNCk9r4oCmYnV0IGlzIHRoYXQgZG9jdW1lbnRlZCBhbnl3aGVyZT8g IEkgbWF5IGJlIG1pc3NpbmcgaXQsIGJ1dCBJIGNvdWxkbuKAmXQgZmluZCBhbnl0aGluZyBsaWtl IHRoYXQgaW4gcmZjNDI3MSBvciByZmM3NjA2Lg0KDQpUaGFua3MhDQoNCkFsdmFyby4NCg0K From nobody Tue Mar 7 14:08:06 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5E711295FA; Tue, 7 Mar 2017 14:08:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tejGEnnmcy_R; Tue, 7 Mar 2017 14:08:00 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BEA2129473; Tue, 7 Mar 2017 14:08:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7164; q=dns/txt; s=iport; t=1488924480; x=1490134080; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=GDK65SOfzx7dW5cdTuU8XepgbQ5GaEOc+K6p38crkxA=; b=SteacQQoaQ1wKPpHWf8EWHVascCI9gb8BlDTu1MgKcf/ziA+69pfHeNf +fdyRaArP6pbh8tvC+P1g/7K2oWw1GHohaatD3FkIrTCG3dCSsHh/ETux Ja24yYnY3nhEDrvb6JnoBzVl0I1xpq3kpb0rjRxFITZNMoo/gI60+O4w3 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CoAQDTLr9Y/4oNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1FhgQoHg1iKDJEsH5U3gg0shXYCGoIRPxgBAgEBAQEBAQFrKIU?= =?us-ascii?q?WAQQBIxFFBQsCAQgaAhEVAgICMBUQAgQOBR+JWAgOsFGCJop8AQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBGAWBC4VDggUIgmKEMSM/gkcugjEFlXeGOQGGdYtBgXuFIoo?= =?us-ascii?q?CiEOKdwEfOIEDVhVQAYZCdYdXgS+BDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.36,260,1486425600"; d="scan'208";a="206999108" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Mar 2017 22:07:59 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v27M7xkX023806 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 7 Mar 2017 22:07:59 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 7 Mar 2017 16:07:58 -0600 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Tue, 7 Mar 2017 16:07:58 -0600 From: "Alvaro Retana (aretana)" To: Randy Bush Thread-Topic: AD Review of draft-ietf-idr-bgp-extended-messages-20 Thread-Index: AQHSjglrFbHoeYS2WUyxb/MV1DegzqGGUcQAgAPBewA= Date: Tue, 7 Mar 2017 22:07:58 +0000 Message-ID: <78AB6B5C-A57A-4311-BBEA-CE70133F8F71@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.6] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "idr-chairs@ietf.org" , "draft-ietf-idr-bgp-extended-messages@ietf.org" , Susan Hares , "idr@ietf.org" Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 22:08:03 -0000 T24gMy81LzE3LCAyOjQ2IEFNLCAiUmFuZHkgQnVzaCIgPHJhbmR5QHBzZy5jb20+IHdyb3RlOg0K DQpSYW5keToNCg0KSGkhDQoNCkkgaGF2ZSBzb21lIGluLWxpbmUgY29tbWVudHMuICBUaGFua3Mg Zm9yIHRoZSB1cGRhdGVkIGRvY3VtZW50Lg0KDQpBbHZhcm8uDQoNCg0K4oCmDQo+ID4gTTIuMS4g IEV2ZW4gd2l0aCBKb2hu4oCZcyBleHBsYW5hdGlvbiwgSSBmaW5kIG15c2VsZiB0aGlua2luZyB0 aGF0IHRoaXMNCj4gPiBzcGVjaWZpY2F0aW9uIGNvdWxkIHJlc3VsdCBpbiBzb21lIHNsb3BweSBp bXBsZW1lbnRhdGlvbnM6IGlmIEkgbmVlZA0KPiA+IHRvIGFjY291bnQgZm9yIHJlY2VpdmluZyB1 bmV4cGVjdGVkIEV4dGVuZGVkIE1lc3NhZ2VzIGluIG15IGNvZGUsIHRoZW4NCj4gPiBtYXliZSBJ IHdvbuKAmXQgd29ycnkgdG9vIG11Y2ggYWJvdXQgY29udHJvbGxpbmcgd2hhdCB0byBzZW5kIHRv IG15DQo+ID4gcGVlcnMg4oCTIHNwZWNpYWxseSBpbiBjYXNlcyB3aGVyZSBpdCB3b3VsZCBiZSBl YXN5IHRvIGp1c3QgcmVwbGljYXRlIGFuDQo+ID4gVVBEQVRFIChsaWtlIGluIGEgcGVlci1ncm91 cCkgYW5kIG5vdCB3b3JyeSBhYm91dCBwb3NzaWJsZSBleGNlcHRpb25zLg0KPiA+IEkga25vdyB0 aGF0IHdlIGNhbuKAmXQgYXZvaWQgYmFkIGltcGxlbWVudGF0aW9ucywgbm8gbWF0dGVyIHdoYXQg dGV4dCBpcw0KPiA+IGFkZGVkIOKAkyBidXQgSSB0aGluayB0aGF0IHJlY29nbml6aW5nIHRoZSB0 aHJlYXQgKG1heWJlIGluIHRoZSBTZWN1cml0eQ0KPiA+IENvbnNpZGVyYXRpb25zIHNlY3Rpb24p IG9mIHNvbWVvbmUgcmVjZWl2aW5nIGFuIEV4dGVuZGVkIE1lc3NhZ2Ugd2hlbg0KPiA+IHRoZXkg ZG9u4oCZdCBzdXBwb3J0IGl0IHdvdWxkIGJlIGdvb2QuICBJIGtub3cgdGhhdCB0aGVyZeKAmXMg dGV4dCBpbiB0aGUNCj4gPiBkb2N1bWVudCBhbHJlYWR5IHdoaWNoIHRhbGtzIGFib3V0IHdoYXQg dG8gZG8gaWYgdGhlIHJlY2VpdmVyIGRvZXNu4oCZdA0KPiA+IHN1cHBvcnQgRXh0ZW5kZWQgTWVz c2FnZXMg4oCTIEnigJltIGp1c3Qgd29ycmllZCBhYm91dCBwb3RlbnRpYWwgaXNzdWVzDQo+ID4g d2l0aCBtZW1vcnkgYWxsb2NhdGlvbiBpZiB0aGUgcmVjZWl2ZXIgd2FzIG5vdCByZWFkeeKApg0K Pg0KPiBpbiB0aGUgYWJzZW5zZSBvZiBhbiBBRCB3aXRoIHRoZSBndXRzIHRvIGxldCBtZSB0ZWFy IHRoYXQgb3V0LCBpJ2xsIHB1dA0KPiBhIG5vdGUgaW4gc2VjIGNvbnMuIDopDQoNCuKYug0KDQpQ ZXJzb25hbGx5LCBJIGRvbuKAmXQgbGlrZSB0aGlzIHBhdGggb2YgYWNjZXB0aW5nIGFueXRoaW5n IHRoYXQgeW91IGRpZG7igJl0IG5lZ290aWF0ZS4gIEhvd2V2ZXIsIEkgaGF2ZSB0byBhc3N1bWUg dGhhdCwgYnkgdGhlIHRpbWUgdGhlIENoYWlycyByZXF1ZXN0IHRoZSBwdWJsaWNhdGlvbiBvZiBh IGRvY3VtZW50LCB0aGVyZSBpcyBhbHJlYWR5IGNvbnNlbnN1cyBpbiB0aGUgV0cg4oCTIGluIHRo aXMgY2FzZSwgdGhlIFNoZXBoZXJk4oCZcyB3cml0ZS11cCBzYXlzIHRoYXQgdGhlcmUgaXMg4oCc c3Ryb25nIGNvbnNlbnN1c+KAnSBbMV0uICBGcm9tIHlvdXIgYW5zd2VycyBhbmQgdGhlIHRleHQg YmVsb3csIEkgdGhpbmsgeW91IGFuZCBJIHdvdWxkIGJvdGggaGF2ZSBiZWVuIGluIHRoZSByb3Vn aCBvbiB0aGlzIGNvbnNlbnN1cyBjYWxsLg0KDQpbMV0gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtaWV0Zi1pZHItYmdwLWV4dGVuZGVkLW1lc3NhZ2VzL3NoZXBoZXJkd3Jp dGV1cC8gDQoNCg0KPiAgICBTZWN0aW9uIDUgYWxsb3dlZCBhIHJlY2VpdmVyIHRvIGFjY2VwdCBh biBleHRlbmRlZCBtZXNzYWdlIGV2ZW4NCj4gICAgdGhvdWdoIHRoZXkgaGFkIG5vdCBhZHZlcnRp c2VkIHRoZSBjYXBhYmlsaXR5LiAgVGhpcyBzbGlwcGVyeSBzbG9wZQ0KPiAgICB3aWxsIHN1cmVs eSBsZWFkIHRvIHNsb3BweSBpbXBsZW1lbnRhdGlvbnMgc2VuZGluZyBleHRlbmRlZCBtZXNzYWdl cw0KPiAgICB3aGVuIHRoZSByZWNlaXZlciBpcyBub3QgcHJlcGFyZWQgdG8gZGVhbCB3aXRoIHRo ZW0sIGUuZy4gdG8gcGVlcg0KPiAgICBncm91cHMuICBBdCBiZXN0LCB0aGlzIHdpbGwgcmVzdWx0 IGluIGVycm9lczsgYXQgd29yc3QsIGJ1ZmZlcg0KPiAgICBvdmVyZmxvd3MuDQoNClRoaXMgdGV4 dCByYWlzZXMgdGhlIG9idmlvdXMgcXVlc3Rpb24gb2Y6IHdoeSBldmVuIGRvIHRoaXMgaWYgaXQg bWF5IGJlIHNvIGJhZD8NCg0KVGhlIHRleHQgc2hvdWxkIHJlZmxlY3QgdGhlIFdHIGNvbnNlbnN1 cyDigJMgbm90IHlvdXIgcGVyc29uYWwgb3BpbmlvbiAob3IgbWluZSwgZm9yIHRoYXQgbWF0dGVy KS4gIFBsZWFzZSByZXdvcmQgdG8gYmUgbW9yZSBvYmplY3RpdmUuDQoNCuKApg0KPiA2LiAgQ2hh bmdlcyB0byBSRkM0MjcxDQo+DQo+ICAgIFtSRkM0MjcxXSBzdGF0ZXMgIlRoZSB2YWx1ZSBvZiB0 aGUgTGVuZ3RoIGZpZWxkIE1VU1QgYWx3YXlzIGJlIGF0DQo+ICAgIGxlYXN0ID4gMTkgYW5kIG5v IGdyZWF0ZXIgdGhhbiA0MDk2LiIgIFRoaXMgZG9jdW1lbnQgY2hhbmdlcyB0aGUNCj4gICAgbGF0 dGVyIG51bWJlciB0byA2NTUzNSBmb3IgVVBEQVRFIG1lc3NhZ2VzLg0KPg0KPiAgICBbUkZDNDI3 MV0gU2VjIDYuMSwgc3BlY2lmaWVzIHJhaXNpbmcgYW4gZXJyb3IgaWYgdGhlIGxlbmd0aCBvZiBh DQo+ICAgIG1lc3NhZ2UgaXMgb3ZlciA0MDk2IG9jdGV0cy4gIEZvciBVUERBVEUgbWVzc2FnZXMs IGlmZiB0aGUgcmVjZWl2ZXINCj4gICAgaGFzIGFkdmVydGlzZWQgdGhlIGNhcGFiaWxpdHkgdG8g cmVjZWl2ZSBleHRlbmRlZCBtZXNzYWdlcywgdGhpcw0KPiAgICBkb2N1bWVudCByYWlzZXMgdGhh dCBsaW1pdCB0byA2NTUzNS4NCg0KVGhpcyBsYXN0IHBhcmFncmFwaCBpcyBub3QgY29tcGxldGVs eSB0cnVlIGJlY2F1c2Ugb2YgU2VjdGlvbiA0Lg0KDQoNCg0KPiA+IE03LiBXaGF0IGFib3V0IHRy YW5zaXRpb24vbWlncmF0aW9uL3BhcnRpYWwgZGVwbG95bWVudD8gIFdoYXQgc2hvdWxkDQo+ID4g dGhlIGJlaGF2aW9yIGJlIGlmLCBmb3IgZXhhbXBsZSwgYW4gRXh0ZW5kZWQgTWVzc2FnZSBVUERB VEUgaXMNCj4gPiByZWNlaXZlZCBmcm9tIGEgcGVlciwgYnV0IGNhbuKAmXQgYmUgcHJvcGFnYXRl ZCB0byBvdGhlcnMgYmVjYXVzZSB0aGV5DQo+ID4gZG9u4oCZdCBzdXBwb3J0IEV4dGVuZGVkIE1l c3NhZ2VzDQo+DQo+IGlmIHRoZXkgZG8gbm90IHN1cHBvcnQgZXh0ZW5kZWQgbWVzc2FnZXMsIHRo ZW4gdGhleSBjYW4gbm90IGJlIGJncHNlYw0KPiBzcGVha2Vycy4gIHNvIHRoZSB3aG9sZSBiZ3Bz ZWMgcGF0aCBzdHJpcHBpbmcgYXBwbGllcyBhbmQgdGhlIG1lc3NhZ2UNCj4gYmVjb21lcyBzaG9y dC4NCj4NCj4gPiBUaGVyZSBzaG91bGQgYmUgc29tZSBndWlkYW5jZSBmb3IgdGhlIGdlbmVyYWwg Y2FzZSAoaS5lLiB3aGVuIHRoZQ0KPiA+IHRvdGFsIHNpemUgaXMgPjRrIGR1ZSBzaW1wbHkgdG8g dGhlIHRvdGFsIGFtb3VudCBvZiBpbmZvcm1hdGlvbiwgYW5kDQo+ID4gbm90IGJlY2F1c2UgYSBz aW5nbGUgYXR0cmlidXRlLCBmb3IgZXhhbXBsZSwgaXMgcmVhbGx5IGJpZykNCj4NCj4gaG93IGFi b3V0ICJkbyBub3QgZG8gdGhpcz8iDQo+DQo+IGkgYmVsaWV2ZSB5b3UgaGF2ZSBlbnRlcmVkIGEg dHdpc3R5IG1hemUgaW4gd2hpY2ggYWxsIHJvb21zIGRvIG5vdCBoYXZlDQo+IHBhdGgocykgdG8g dGhlIGV4aXQuDQo+DQo+IDQuICBPcGVyYXRpb24NCj4uLi4NCj4gICAgQSBCR1AgYW5ub3VuY2Vt ZW50IHdpbGwsIGluIHRoZSBub3JtYWwgY2FzZSwgcHJvcGFnYXRlIHRocm91Z2hvdXQgdGhlDQo+ ICAgIEJHUCBzcGVha2luZyBJbnRlcm5ldDsgYW5kIHRoZXJlIHdpbGwgdW5kb3VidGVkbHkgYmUg QkdQIHNwZWFrZXJzDQo+ICAgIHdoaWNoIGRvIG5vdCBoYXZlIHRoZSBFeHRlbmRlZCBNZXNzYWdl IGNhcGFiaWxpdHkuICBUaGVyZWZvcmUgcHV0dGluZw0KPiAgICBhbiBhdHRyaWJ1dGUgd2hpY2gg Y2FuIG5vdCBiZSBkZWNvbXBvc2VkIHRvIDQwOTYgb2N0ZXRzIG9yIGxlc3MgaW4gYW4NCj4gICAg RXh0ZW5kZWQgTWVzc2FnZSBpcyBhIHN1cmUgcGF0aCB0byByb3V0aW5nIGZhaWx1cmUuDQoNCklm IHRoaXMgdGV4dCBpcyBpbiB0aGUgZG9jdW1lbnQsIHRoZW4geW914oCZcmUgYmFzaWNhbGx5IHNh eWluZyB0aGF0IHlvdSBzaG91bGRu4oCZdCBkZXBsb3kgYW55dGhpbmcgdGhhdCBjb3VsZCBuZWVk IG1vcmUgdGhhbiA0ayBiZWNhdXNlIGl0IGlzIGEg4oCcc3VyZSBwYXRoIHRvIHJvdXRpbmcgZmFp bHVyZeKAnS4gIEFnYWluLCBwbGVhc2UgcmVmbGVjdCBXRyBjb25zZW5zdXPigKYNCg0KV2hhdCBJ IHdhcyByZWFsbHkgaG9waW5nIGZvciB3YXMgc29tZXRoaW5nIGxpa2Ugd2hhdCB5b3Ugd3JvdGUg YWJvdmUgYWJvdXQgQkdQU2VjOiBpZiBhIDRrLW5laWdoYm9yIGlzIGVuY291bnRlcmVkLCB0aGVu IGp1c3QgcmV2ZXJ0IHRvIOKAnG5vcm1hbCBvcGVyYXRpb27igJ0uICBJ4oCZbSBub3QgYXNraW5n IHlvdSB0byBwdXQgdGhhdCB0ZXh0IGluIHRoaXMgZG9jdW1lbnQsIG1vc3RseSBiZWNhdXNlIHRo ZXJlIG1pZ2h0IG5vdCBiZSDigJxub3JtYWwgb3BlcmF0aW9u4oCdIGZvciBzb21ldGhpbmcgbmV3 IGluIHRoZSBmdXR1cmUgKGxpa2UgdGhlcmUgaXMgZm9yIEJHUFNlYykuICBTbywgd2hhdCBhbSBJ IGFza2luZyBmb3I/ICBUd28gdGhpbmdzOg0KDQotIGd1aWRhbmNlIG9mIHdoYXQgdG8gZG8gaWYg dGhlIOKAnG5vcm1hbCBvcGVyYXRpb27igJ0gb2YgYWRkaW5nIGF0dHJpYnV0ZXMgcmVzdWx0cyBp biA+NGsuICBNYXliZSDigJx0cmVhdCBhcyB3aXRoZHJhd+KAnSB3b3VsZCBiZSBhcHByb3ByaWF0 ZeKApg0KDQotIHNvbWUgdGV4dCBzYXlpbmcgdGhhdCBpZiBhIGZ1dHVyZSBleHRlbnNpb24ga25v d3MgaXQgbmVlZHMgbW9yZSB0aGFuIDRrIChsaWtlIEJHUFNlYyBkb2VzKSwgdGhlbiBpdCBNVVNU IGluY2x1ZGUgc29tZSB0ZXh0IGFib3V0IHdoYXQgdG8gZG8uICBJT1csIHlvdSBjYW7igJl0IHNv bHZlIHRoZSBmdXR1cmUgY2FzZSBub3csIGxldCB0aGVtIHNvbHZlIGl0IGxhdGVyLg0KDQoNCkJU VywgaXQgbG9va3MgbGlrZSB5b3UgbWF5IGhhdmUgb3Zlcmxvb2tlZCB0aGVzZSBvdGhlciBxdWVz dGlvbnM6IOKAnFdoYXQgc2hvdWxkIHRoZSBkZWZhdWx0IGJlIGZvciB0aGlzIGV4dGVuc2lvbj8g IFNob3VsZCBpdCBiZSBlbmFibGVkIGJ5IGRlZmF1bHQgb3Igbm90P+KAnQ0KDQo= From nobody Tue Mar 7 14:09:00 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79D6D129473; Tue, 7 Mar 2017 14:08:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XurPI5tiYrET; Tue, 7 Mar 2017 14:08:58 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EEDB1294EC; Tue, 7 Mar 2017 14:08:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=806; q=dns/txt; s=iport; t=1488924538; x=1490134138; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=cfyOKq+6bGCXNOIZEE1oB8MhceplAM0dSaUcHGrUYFE=; b=MEoAgoTsvnJSOYMOlL1KKaf/3WUtYZfXcb9XX+UCpXQbfzP0LI+OGP4X Y+Uqs2iP53jMwoA5fPqqhIzGucEXyE8uPhxQGecxCzOb9BPqXFWrxVVnM +wCrCcUk9xYA1PQyNVqWYgDIlVVRe1Lcj0ZsBO7ZRg1UylHHduV+KG6zq 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CYAQDoLr9Y/4ENJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1GBaweDWIoMkUuVN4INhiICGoIRPxgBAgEBAQEBAQFrKIUWAQQ?= =?us-ascii?q?BIxFFBQsCAQgODAImAgICMBUQAgQBDQWJdwiwX4IminwBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEdgQuFQ4IFgmqHWi6CMQEElXeGOQGSNoFjGIUiigKIQ4p3AR84gQN?= =?us-ascii?q?WFVABhkJ1iQaBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.36,260,1486425600"; d="scan'208";a="394074121" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Mar 2017 22:08:57 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v27M8vDj028416 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 7 Mar 2017 22:08:57 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 7 Mar 2017 16:08:56 -0600 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Tue, 7 Mar 2017 16:08:56 -0600 From: "Alvaro Retana (aretana)" To: Susan Hares , "'Randy Bush'" Thread-Topic: AD Review of draft-ietf-idr-bgp-extended-messages-20 Thread-Index: AQHSjglrFbHoeYS2WUyxb/MV1DegzqGGUcQAgADRzICAAu/0AA== Date: Tue, 7 Mar 2017 22:08:56 +0000 Message-ID: <0BBC61A9-758C-44FF-B36E-9C41399EDCCB@cisco.com> References: <000201d295ed$8824b320$986e1960$@ndzh.com> In-Reply-To: <000201d295ed$8824b320$986e1960$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.6] Content-Type: text/plain; charset="utf-8" Content-ID: <97CF658AC125B74C86FE029288F4D673@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "idr-chairs@ietf.org" , "draft-ietf-idr-bgp-extended-messages@ietf.org" , "idr@ietf.org" Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 22:08:59 -0000 T24gMy81LzE3LCAzOjE3IFBNLCAiU3VzYW4gSGFyZXMiIDxzaGFyZXNAbmR6aC5jb20+IHdyb3Rl Og0KDQpTdWU6DQoNCkhpIQ0KDQo+IEEgZmV3IHBvaW50IGhhdmUgcmFpc2VkIG15IGRpc2FncmVl bWVudCByZWdhcmRpbmcgdGhlIEFEIHJldmlld3MuICAgQXQgdGhpcw0KPiBwb2ludCwgdGhlIHRl eHQgaXMgYXQgb2RkcyB3aXRoIFJGQzQyNzEuICAgSWYgeW91IGZlZWwgUkZDNDI3MSwgZG9lcyBu b3QNCj4gc3BlYWsgYWJvdXQgdGhlc2UgaXNzdWVzIC0geW91IG1heSBoYXZlIG1pc3NlZCB3aHkg dGhlIEJHUCBGU00gaXMgdGhlcmUuDQo+IFBsZWFzZSBjaGFuZ2UgeW91ciB0ZXh0LiANCg0KSeKA mW0gbm90IHN1cmUgd2h5IHlvdSBkaXNhZ3JlZSB3aXRoIG15IGNvbW1lbnRz4oCmYnV0IGlmIEkg aW50ZXJwcmV0IHlvdXIgcG9pbnRzIGNvcnJlY3RseSwgSSB0aGluayB5b3XigJlyZSBzYXlpbmcg dGhhdCB0aGlzIGRvY3VtZW50IHNob3VsZCBhbHNvIHVwZGF0ZSB0aGUgRlNNIHdoZXJlIG5lZWRl ZCwgaXMgdGhhdCByaWdodD8gIElmIHNvLCB0aGVuIEkgYWdyZWUgd2l0aCB0aGF0Lg0KDQpUaGFu a3MhDQoNCkFsdmFyby4NCg0K From nobody Tue Mar 7 14:16:06 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A43D129519; Tue, 7 Mar 2017 14:15:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jYGoltql_tJS; Tue, 7 Mar 2017 14:15:54 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C6A21294EC; Tue, 7 Mar 2017 14:15:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1368; q=dns/txt; s=iport; t=1488924954; x=1490134554; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=/pOTx4aOy1XXR5R4hmEySqivkWbIEVcFyUsmROMCW64=; b=ZaUOjSfCUAlvPhjM9FEHgo3ZHrfpvFusAuW4HiiT1eWAY26Q04CE7mEM oUxI4JHgYeTCTzg3DPVsvc7gFr9EMR1/6KSSDJm6emxV5eH4OqMlVm52j 7Ml98mmyFp9j+j4Mh2/Ff4LQqdgfdmDR41pDukau+aTqZkF8TRhTGP6wb A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AvAgBJML9Y/5RdJa1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBg1GBaweDWIoMkSyVVoINhiICGoIRPxgBAgEBAQEBAQFrHQuFFgYjEUU?= =?us-ascii?q?QAgEIGgImAgICMBUQAgQOBYl/sGGCJop8AQEBAQEBAQEBAQEBAQEBAQEBAQEBH?= =?us-ascii?q?YELhUOCBQiCYoUOgkwugjEBBJV3hjkBih2IGYF7jySIQ4p3AR84gQNWFVABhkJ?= =?us-ascii?q?1iQaBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.36,260,1486425600"; d="scan'208";a="394077425" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Mar 2017 22:15:53 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v27MFrpF029358 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 7 Mar 2017 22:15:53 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 7 Mar 2017 16:15:53 -0600 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Tue, 7 Mar 2017 16:15:53 -0600 From: "Alvaro Retana (aretana)" To: "idr-chairs@ietf.org" Thread-Topic: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20 Thread-Index: AQHSjglrFbHoeYS2WUyxb/MV1DegzqF/VY+AgAlhrgCAAEiTgIABFaOA Date: Tue, 7 Mar 2017 22:15:52 +0000 Message-ID: <8F538ECE-0317-41CE-95BC-9F64E7385B4D@cisco.com> References: <20170228210627.GB17448@pfrc.org> <3eb4d853-1d44-6250-c70a-26f60eac39e6@cisco.com> <006e01d296db$a7c4c320$f74e4960$@ndzh.com> In-Reply-To: <006e01d296db$a7c4c320$f74e4960$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.6] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "idr@ietf.org" , "draft-ietf-idr-bgp-extended-messages@ietf.org" , Susan Hares Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 22:15:58 -0000 SGkhDQoNCkFmdGVyIHJlYWRpbmcgdGhlIG1lc3NhZ2VzIGluIHRoaXMgdGhyZWFkLCBJ4oCZbSBy ZXR1cm5pbmcgdGhlIGRvY3VtZW50IHRvIHRoZSBXRyB0byBmaW5pc2ggdGhlIGRpc2N1c3Npb24g dGhlcmUuDQoNCkJhc2VkIG9uIHRoZSBkaXNjdXNzaW9uLCBJIHRoaW5rIHRoZXJlIGFyZSBzb21l IG9wZW4gaXRlbXMgdGhhdCBJIHdvdWxkIGxpa2UgdGhlIFdHIHRvIGNsb3NlIG9uIChpbiBubyBw YXJ0aWN1bGFyIG9yZGVyKToNCg0KLSBTaG91bGQgdGhpcyBkb2N1bWVudCBhZGRyZXNzIGFsbCBt ZXNzYWdlcyBvciBqdXN0IFVQREFURVM/ICBbVGhlIENoYWlycyBhc2tlZCBmb3IgZmVlZGJhY2sg ZnJvbSBncm93Ll0NCg0KLSBBcmUgYW55IHVwZGF0ZXMgbmVlZGVkIHRvIHRoZSBGU00/DQoNCi0g SXMgaXQgb2sgdG8gc2VuZC9hY2NlcHQgRXh0ZW5kZWQgTWVzc2FnZXMgd2l0aG91dCBoYXZpbmcg cmVjZWl2ZWQvYWR2ZXJ0aXNlZCB0aGUgQ2FwYWJpbGl0eT8gIFRoaXMgaXMgYSBzaWduaWZpY2Fu dCBjaGFuZ2UgaW4gdGhlIHdheSBCR1Agb3BlcmF0ZXMg4oCTIGFuZCB3b3VsZCBzZXQgYW4gaW1w b3J0YW50IHByZWNlZGVudC4NCg0KLSBXaGF0IGFib3V0IGluY3JlbWVudGFsIGRlcGxveW1lbnQ/ ICBTaG91bGQgdGhlcmUgYmUgb3BlcmF0aW9uYWwgZ3VpZGFuY2U/ICBJZiBzbywgd2hhdCBzaG91 bGQgdGhhdCBndWlkYW5jZSBiZT8NCg0KDQpUaGFua3MhDQoNCkFsdmFyby4NCg0KDQpPbiAzLzYv MTcsIDc6NDIgUE0sICJTdXNhbiBIYXJlcyIgPHNoYXJlc0BuZHpoLmNvbT4gd3JvdGU6DQoNCj4g PFdHIGNoYWlyIGhhdCBvbj4gDQo+IElmIHRoZXJlIGlzIGVub3VnaCBjb25jZXJuIGFib3V0IHRo ZSBleHRlbmRlZCBtZXNzYWdlcyBjb3ZlcmluZyBhbGwgbWVzc2FnZXMgdmVyc3VzIA0KPiBVUERB VEUgbWVzc2FnZXMsICBJIHdpbGwgbmVlZCB0byBkbyAgMSB3ZWVrIGNhbGwgb24gdGhpcyB0b3Bp Yy4gIA0KPiA8V0cgQ2hhaXIgaGF0IG9mZj4NCg0K From nobody Tue Mar 7 14:20:32 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5073D129517; Tue, 7 Mar 2017 14:20:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGzTGzcD0DQW; Tue, 7 Mar 2017 14:20:29 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 C5E6A12968D; Tue, 7 Mar 2017 14:19:55 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.90.29; From: "Susan Hares" To: "'Alvaro Retana \(aretana\)'" , "'Randy Bush'" References: <000201d295ed$8824b320$986e1960$@ndzh.com> <0BBC61A9-758C-44FF-B36E-9C41399EDCCB@cisco.com> In-Reply-To: <0BBC61A9-758C-44FF-B36E-9C41399EDCCB@cisco.com> Date: Tue, 7 Mar 2017 17:14:52 -0500 Message-ID: <01a601d29790$3edc1060$bc943120$@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: AQInnAj+Yxa8tap/yfCJFXAjQYwk1wF1zsYwAlX2LeQCP/hY1aCviGpA Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: idr-chairs@ietf.org, draft-ietf-idr-bgp-extended-messages@ietf.org, idr@ietf.org Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 22:20:30 -0000 Alvaro: =20 I'm saying your suggested revisions did not correctly align with RFC4271 = specification, specifically in the area of the FSM. I objected to = version-21 because it contained errors by misaligning the text with the = IDR FSM. (see mail list for specific issues0. I proposed a cleaner = replacement text. Earlier versions did not hit this misalignment. As a = shepherd, I felt version-21 could not go forward. =20 =20 =20 I am saying the better way is to just utilize the BGP message header = length error function (0-4096 normal, 4097-65535 extended) and let the = FSM handle it. Then all BGP messages could be large. See the email = thread.=20 =20 =20 This is why we have the thread on the mail list about accepting all = messages =20 Happy changing hat day to you!=20 Sue -----Original Message----- From: Alvaro Retana (aretana) [mailto:aretana@cisco.com]=20 Sent: Tuesday, March 7, 2017 5:09 PM To: Susan Hares; 'Randy Bush' Cc: draft-ietf-idr-bgp-extended-messages@ietf.org; idr-chairs@ietf.org; = idr@ietf.org Subject: Re: AD Review of draft-ietf-idr-bgp-extended-messages-20 On 3/5/17, 3:17 PM, "Susan Hares" wrote: Sue: Hi! > A few point have raised my disagreement regarding the AD reviews. At = this > point, the text is at odds with RFC4271. If you feel RFC4271, does = not > speak about these issues - you may have missed why the BGP FSM is = there. > Please change your text.=20 I=E2=80=99m not sure why you disagree with my comments=E2=80=A6but if I = interpret your points correctly, I think you=E2=80=99re saying that this = document should also update the FSM where needed, is that right? If so, = then I agree with that. Thanks! Alvaro. From nobody Tue Mar 7 15:44:17 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 269B8129444; Tue, 7 Mar 2017 15:44:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M_GETV6SD3RY; Tue, 7 Mar 2017 15:44:14 -0800 (PST) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0130.outbound.protection.outlook.com [23.103.201.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2043D126BF7; Tue, 7 Mar 2017 15:44:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=pelNH4jxUyWJF1jQEaQ5u4svr8C72hmAqS7U6GU18KQ=; b=T/ivyAKBrSUg8Ye5oYPp8GNHC2+K1cMMperWa3x5zpqQoqjtvq1oRReiC5AbVi1o6HDtcyjAwK1nYQXArJmH+vKRuLB6P75TkbuwGPgFoF+El4KTdemkRGtSPFWt1pmJXyUm0BbnyS98+S9CzWL5G11bTPMvQw5BASk7RTsLG88= Received: from BL2PR09MB0996.namprd09.prod.outlook.com (10.167.102.15) by BL2PR09MB0995.namprd09.prod.outlook.com (10.167.102.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.12; Tue, 7 Mar 2017 23:44:11 +0000 Received: from BL2PR09MB0996.namprd09.prod.outlook.com ([10.167.102.15]) by BL2PR09MB0996.namprd09.prod.outlook.com ([10.167.102.15]) with mapi id 15.01.0947.020; Tue, 7 Mar 2017 23:44:12 +0000 From: "Borchert, Oliver (Fed)" To: Enke Chen , Susan Hares Thread-Topic: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20 Thread-Index: AQHSjglrFbHoeYS2WUyxb/MV1DegzqF+8PqAgAlhrgCAAEiTgIAAnkCAgAA/eoCAABXogIAAAp8AgAACk4CAAAAMgIAANcUA////qgA= Date: Tue, 7 Mar 2017 23:44:11 +0000 Message-ID: References: <20170228210627.GB17448@pfrc.org> <3eb4d853-1d44-6250-c70a-26f60eac39e6@cisco.com> <006e01d296db$a7c4c320$f74e4960$@ndzh.com> <010101d2974a$8520d060$8f627120$@ndzh.com> <018c01d29756$c8b4f610$5a1ee230$@ndzh.com> <01b301d29758$180458e0$480d0aa0$@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/f.1f.0.170216 authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.140.59] x-ms-office365-filtering-correlation-id: f37e9605-2ce5-4812-43d3-08d465b3db60 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BL2PR09MB0995; x-microsoft-exchange-diagnostics: 1; BL2PR09MB0995; 7:t+kFLsjEDnEffB7uTMhirMLhGLC6Ki/iLCJP7QeJe9libBvfcAWa4kvrWOOri4iB+A8hr9cx0csXWCqJpv32jJhYXTjIURMYpYZ2gtydJguqkASHg8RYUDfMWsStecaXjf19x3xeNgHyrsKxDFd/5rQVuMb5BsL6px9I0IftRTDeGeze8lGXxfgDFLvRgL1ZYt0IWh3XgBreNEcCjwqLYAY+Hv8xT8xO63sbpCMN/Se4L6f2fCK6iF6HB8cfWWzUetq7HMGiC9um6UftCYS8KUH1Muaty3Dqa0d7AcWq8U3qmPoJ/umaYkAdEU72PAnS4ZWb6ViJF71wipsG1IAJnA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123558025)(20161123555025)(20161123560025)(20161123562025)(20161123564025)(6072148); SRVR:BL2PR09MB0995; BCL:0; PCL:0; RULEID:; SRVR:BL2PR09MB0995; x-forefront-prvs: 0239D46DB6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39410400002)(39850400002)(39840400002)(39860400002)(24454002)(377454003)(189998001)(66066001)(83716003)(229853002)(6506006)(77096006)(6486002)(53546006)(4001350100001)(2950100002)(83506001)(86362001)(76176999)(2900100001)(81166006)(8676002)(122556002)(50986999)(54356999)(82746002)(8936002)(106116001)(5660300001)(3280700002)(3660700001)(15650500001)(33656002)(230783001)(93886004)(99286003)(53936002)(36756003)(25786008)(6306002)(54906002)(6512007)(6436002)(38730400002)(6246003)(305945005)(3846002)(4326008)(6116002)(102836003)(7736002)(2906002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR09MB0995; H:BL2PR09MB0996.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <510BF23A5F308349BAC4E1DB1A24DB04@namprd09.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Mar 2017 23:44:11.7965 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR09MB0995 Archived-At: Cc: 'idr wg' , "draft-ietf-idr-bgp-extended-messages@ietf.org" , 'Robert Raszuk' , "idr-chairs@ietf.org" Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 23:44:16 -0000 SSBhbSB3b25kZXJpbmcg4oCTIGFjY29yZGluZyB0byBSRkMgNDI3MSwgaG93IGNhbiBhbiBPUEVO IG1lc3NhZ2UgZXZlciBleGNlZWQgMjg0IGJ5dGVzPw0KVGhlIGJncCBtZXNzYWdlIGhlYWRlciBo YXMgMTkgYnl0ZXMgYW5kIHRoZSBPUEVOIG1lc3NhZ2UgcGF5bG9hZCBhZGRzIDEwLiBUaGlzIGlz IDI5LCB0aGVuIHRoZSBvbmx5IA0KYWRkaXRpb24gaGVyZSBhcmUgdGhlIE9wdGlvbmFsIFBhcmFt ZXRlcnMgd2hpY2ggY2Fubm90IGV4Y2VlZCAyNTUgYnl0ZXMgY29tYmluZWQgZHVlIHRvIHRoZSAx IGJ5dGUgbGVuZ3RoIGZpZWxkLg0KDQpUaGVyZWZvcmUsIGFuIG9wZW4gbWVzc2FnZSBjYW5ub3Qg ZXhjZWVkIDI4NCBieXRlcyBhbmQgaWYgbGFyZ2VyIHRoYW4gMjg0IGJ5dGVzLCB3b3VsZG7igJl0 IGl0IGJlIGludmFsaWQuIA0KDQpJbiB0aGlzIHJlZ2FyZCwgSSBkb27igJl0IHJlYWxseSB1bmRl cnN0YW5kIHRoZSB3aG9sZSBkaXNjdXNzaW9uIGFib3V0IGFsbG93aW5nIGFuIE9QRU4gbWVzc2Fn ZSBsYXJnZXIgdGhhbiA0Sy4gDQpJdCBzaG91bGRu4oCZdCBldmVuIGJlIGxhcmdlciB0aGFuIDI4 NCBieXRlcz8gIE1heWJlIEkgYW0gbWlzc2luZyBzb21ldGhpbmcuDQoNCkJUVywgc2FtZSBpcyB0 cnVlIGZvciBLRUVQQUxJVkUgKG1heCAxOSBieXRlcykNCg0KT2xpdmVyDQoNCg0KDQpPbiAzLzcv MTcsIDE6NDUgUE0sICJJZHIgb24gYmVoYWxmIG9mIEVua2UgQ2hlbiIgPGlkci1ib3VuY2VzQGll dGYub3JnIG9uIGJlaGFsZiBvZiBlbmtlY2hlbkBjaXNjby5jb20+IHdyb3RlOg0KDQogICAgSGks IEZvbGtzOg0KICAgIA0KICAgIG8gVGhlcmUgaXMgbm8gZXh0cmEgd29yayBmb3IgYSByZWNlaXZl ciB0byBjb3ZlciBtZXNzYWdlIHR5cGVzIG90aGVyIHRoYW4gVVBEQVRFLg0KICAgIG8gVGhlcmUg aXMgYSBsaXR0bGUgYml0IHdvcmsgZm9yIGEgc2VuZGVyIHRoYXQgd2lzaGVzIHRvIHNlbmQgYSBs YXJnZSBPUEVOIChlLmcuLA0KICAgICAgdXNpbmcgdGhlIHByaW9yIGNhcGFiaWxpdHkgYW5kIHBv c3NpYmx5IHN1YnNlcXVlbnQgTk9USUZJQ0FUSU9OKS4NCiAgICANCiAgICBBZGRpdGlvbmFsbHks IEkgZG8gbm90IHNlZSBhIG5lZWQgdG8gdG91Y2ggb24gdGhlIEZTTSBzcGVjaWZpZWQgaW4gUkZD IDQyNzEgZXZlbg0KICAgIGluIHRoZSBjYXNlIG9mIHNlbmRpbmcgYSBsYXJnZSBPUEVOLCB3aGlj aCBwb3RlbnRpYWxseSBtYXkgaW52b2x2ZSB0d28gc2VwYXJhdGUNCiAgICBjb25zZWN1dGl2ZSBz ZXNzaW9ucyBidXQgZWFjaCBzZXNzaW9uIHdvdWxkIGp1c3QgZm9sbG93IHRoZSBleGlzdGluZyBG U00uDQogICAgDQogICAgVGhhbmtzLiAgIC0tIEVua2UNCiAgICANCiAgICBPbiAzLzcvMTcgNzoz MiBBTSwgU3VzYW4gSGFyZXMgd3JvdGU6DQogICAgPiBSb2JlcnQ6DQogICAgPiANCiAgICA+IDxp bmRpdmlkdWFsIGNvbnRyaWJ1dG9y4oCZcyBoYXQgb24+DQogICAgPiANCiAgICA+IFllcCAgLSBF YXNpZXIgdG8ganVzdCBpbmNsdWRlIGFsbCBtZXNzYWdlcy4gIA0KICAgID4gDQogICAgPiAgDQog ICAgPiANCiAgICA+IFN1ZQ0KICAgID4gDQogICAgPiAgDQogICAgPiANCiAgICA+ICpGcm9tOipy cmFzenVrQGdtYWlsLmNvbSBbbWFpbHRvOnJyYXN6dWtAZ21haWwuY29tXSAqT24gQmVoYWxmIE9m ICpSb2JlcnQgUmFzenVrDQogICAgPiAqU2VudDoqIFR1ZXNkYXksIE1hcmNoIDcsIDIwMTcgMTA6 MzMgQU0NCiAgICA+ICpUbzoqIFN1c2FuIEhhcmVzDQogICAgPiAqQ2M6KiBSYW5keSBCdXNoOyBF bmtlIENoZW47IEplZmZyZXkgSGFhczsgQWx2YXJvIFJldGFuYSAoYXJldGFuYSk7IGlkci1jaGFp cnNAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtaWRyLWJncC1leHRlbmRlZC1tZXNzYWdlc0BpZXRmLm9y ZzsgaWRyIHdnDQogICAgPiAqU3ViamVjdDoqIFJlOiBbSWRyXSBBRCBSZXZpZXcgb2YgZHJhZnQt aWV0Zi1pZHItYmdwLWV4dGVuZGVkLW1lc3NhZ2VzLTIwDQogICAgPiANCiAgICA+ICANCiAgICA+ IA0KICAgID4gSGkgU3VlLA0KICAgID4gDQogICAgPiAgDQogICAgPiANCiAgICA+PiBNeSBzdWdn ZXN0aW9uIGlzIHRvIGluY2x1ZGUgYWxsIG1lc3NhZ2VzIGluY2x1ZGluZyBmdXR1cmUgbWVzc2Fn ZXMgaWYgYXBwcm92ZWQuICANCiAgICA+IA0KICAgID4gIA0KICAgID4gDQogICAgPiBBaGggdGhl biBpdCBpcyBncmVhdCAtIHdlIGFyZSBpbiBzeW5jICEgDQogICAgPiANCiAgICA+ICANCiAgICA+ IA0KICAgID4gTXkgb3RoZXIgY29tbWVudHMgd2VyZSBqdXN0IGFuIG9waW5pb24gLi4uIGJ1dCBp ZiBpdCBpcyBlYXNpZXIgdG8gZXh0ZW5kIGFsbCBtZXNzYWdlcyB0aGVuIHBlcmZlY3QuIA0KICAg ID4gDQogICAgPiAgDQogICAgPiANCiAgICA+IENoZWVycywNCiAgICA+IA0KICAgID4gUi4NCiAg ICA+IA0KICAgID4gIA0KICAgID4gDQogICAgPiAgDQogICAgPiANCiAgICANCiAgICBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgIElkciBtYWlsaW5n IGxpc3QNCiAgICBJZHJAaWV0Zi5vcmcNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2lkcg0KICAgIA0KDQo= From nobody Tue Mar 7 15:49:24 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDD111294BB; Tue, 7 Mar 2017 15:49:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.501 X-Spam-Level: X-Spam-Status: No, score=-13.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qr0JCdd7X5CJ; Tue, 7 Mar 2017 15:49:19 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E28B1294A6; Tue, 7 Mar 2017 15:49:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2948; q=dns/txt; s=iport; t=1488930559; x=1490140159; h=subject:references:cc:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=CuMUNSG2zMA+GUgYDqEZ6d+GNjtTOEVhgqqsVbIVQNE=; b=FhKGjc32OE6ggXFtdhg77XPPk8ePpBtiv5pbPbzdznN7oVS57CcLfZrT JUuQ/M3MjYK4E7UKI1pQ0YGtYZhpdDXdUeH0SCBmXAkzviemAEJghy2Ob N8vht1wYNTCsOJBaIg8Aui4FFFdYPevPQBQLiplm4uzaHGde/nlxN/baE 4=; X-IronPort-AV: E=Sophos;i="5.36,260,1486425600"; d="scan'208";a="394837126" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Mar 2017 23:49:18 +0000 Received: from [10.41.57.142] ([10.41.57.142]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v27NnIgl014150; Tue, 7 Mar 2017 23:49:18 GMT References: <20170228210627.GB17448@pfrc.org> <3eb4d853-1d44-6250-c70a-26f60eac39e6@cisco.com> <006e01d296db$a7c4c320$f74e4960$@ndzh.com> <010101d2974a$8520d060$8f627120$@ndzh.com> <018c01d29756$c8b4f610$5a1ee230$@ndzh.com> <01b301d29758$180458e0$480d0aa0$@ndzh.com> From: Enke Chen Message-ID: <7657b686-0685-9bdf-17ba-e7d618a237aa@cisco.com> Date: Tue, 7 Mar 2017 15:49:17 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: 'idr wg' , 'Robert Raszuk' , "idr-chairs@ietf.org" , "draft-ietf-idr-bgp-extended-messages@ietf.org" , Susan Hares Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 23:49:22 -0000 Please check out the following document: Extended Optional Parameters Length for BGP OPEN Message draft-ietf-idr-ext-opt-param-02 -- Enke On 3/7/17 3:44 PM, Borchert, Oliver (Fed) wrote: > I am wondering – according to RFC 4271, how can an OPEN message ever exceed 284 bytes? > The bgp message header has 19 bytes and the OPEN message payload adds 10. This is 29, then the only > addition here are the Optional Parameters which cannot exceed 255 bytes combined due to the 1 byte length field. > > Therefore, an open message cannot exceed 284 bytes and if larger than 284 bytes, wouldn’t it be invalid. > > In this regard, I don’t really understand the whole discussion about allowing an OPEN message larger than 4K. > It shouldn’t even be larger than 284 bytes? Maybe I am missing something. > > BTW, same is true for KEEPALIVE (max 19 bytes) > > Oliver > > > > On 3/7/17, 1:45 PM, "Idr on behalf of Enke Chen" wrote: > > Hi, Folks: > > o There is no extra work for a receiver to cover message types other than UPDATE. > o There is a little bit work for a sender that wishes to send a large OPEN (e.g., > using the prior capability and possibly subsequent NOTIFICATION). > > Additionally, I do not see a need to touch on the FSM specified in RFC 4271 even > in the case of sending a large OPEN, which potentially may involve two separate > consecutive sessions but each session would just follow the existing FSM. > > Thanks. -- Enke > > On 3/7/17 7:32 AM, Susan Hares wrote: > > Robert: > > > > > > > > Yep - Easier to just include all messages. > > > > > > > > Sue > > > > > > > > *From:*rraszuk@gmail.com [mailto:rraszuk@gmail.com] *On Behalf Of *Robert Raszuk > > *Sent:* Tuesday, March 7, 2017 10:33 AM > > *To:* Susan Hares > > *Cc:* Randy Bush; Enke Chen; Jeffrey Haas; Alvaro Retana (aretana); idr-chairs@ietf.org; draft-ietf-idr-bgp-extended-messages@ietf.org; idr wg > > *Subject:* Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20 > > > > > > > > Hi Sue, > > > > > > > >> My suggestion is to include all messages including future messages if approved. > > > > > > > > Ahh then it is great - we are in sync ! > > > > > > > > My other comments were just an opinion ... but if it is easier to extend all messages then perfect. > > > > > > > > Cheers, > > > > R. > > > > > > > > > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > From nobody Tue Mar 7 15:51:27 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE021294A6; Tue, 7 Mar 2017 15:51:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.501 X-Spam-Level: X-Spam-Status: No, score=-13.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11nk7Q2cqPl5; Tue, 7 Mar 2017 15:51:23 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3352129444; Tue, 7 Mar 2017 15:51:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3172; q=dns/txt; s=iport; t=1488930682; x=1490140282; h=subject:cc:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=crEna49HySQG6yPxYIf/kv2sehzXFaUDXHGVtpl8AMY=; b=T5+1tRZnHKhSjJJVtJ16FTLLzSGeuekcaEz9cmbkrTZ3s7sOiEQP3DSw Yuu2IEJTmhVAwcMANr3yY0lXo4ZT9tx6o+iAg5qO2WCXv7+dCBcFJ2i5R pbn4Q46hMqWFXunG48/mnfET1r5gg+9DFeANO7E5spJIEVKQLmABLw83z c=; X-IronPort-AV: E=Sophos;i="5.36,260,1486425600"; d="scan'208";a="215599206" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Mar 2017 23:51:22 +0000 Received: from [10.41.57.142] ([10.41.57.142]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v27NpLdH030984; Tue, 7 Mar 2017 23:51:21 GMT References: <20170228210627.GB17448@pfrc.org> <3eb4d853-1d44-6250-c70a-26f60eac39e6@cisco.com> <006e01d296db$a7c4c320$f74e4960$@ndzh.com> <010101d2974a$8520d060$8f627120$@ndzh.com> <018c01d29756$c8b4f610$5a1ee230$@ndzh.com> <01b301d29758$180458e0$480d0aa0$@ndzh.com> <7657b686-0685-9bdf-17ba-e7d618a237aa@cisco.com> From: Enke Chen Message-ID: Date: Tue, 7 Mar 2017 15:51:21 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <7657b686-0685-9bdf-17ba-e7d618a237aa@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: 'idr wg' , 'Robert Raszuk' , "idr-chairs@ietf.org" , "draft-ietf-idr-bgp-extended-messages@ietf.org" , Susan Hares Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 23:51:24 -0000 https://datatracker.ietf.org/doc/draft-ietf-idr-ext-opt-param/ draft-ietf-idr-ext-opt-param-05 On 3/7/17 3:49 PM, Enke Chen wrote: > Please check out the following document: > > Extended Optional Parameters Length for BGP OPEN Message > draft-ietf-idr-ext-opt-param-02 > > -- Enke > > On 3/7/17 3:44 PM, Borchert, Oliver (Fed) wrote: >> I am wondering – according to RFC 4271, how can an OPEN message ever exceed 284 bytes? >> The bgp message header has 19 bytes and the OPEN message payload adds 10. This is 29, then the only >> addition here are the Optional Parameters which cannot exceed 255 bytes combined due to the 1 byte length field. >> >> Therefore, an open message cannot exceed 284 bytes and if larger than 284 bytes, wouldn’t it be invalid. >> >> In this regard, I don’t really understand the whole discussion about allowing an OPEN message larger than 4K. >> It shouldn’t even be larger than 284 bytes? Maybe I am missing something. >> >> BTW, same is true for KEEPALIVE (max 19 bytes) >> >> Oliver >> >> >> >> On 3/7/17, 1:45 PM, "Idr on behalf of Enke Chen" wrote: >> >> Hi, Folks: >> >> o There is no extra work for a receiver to cover message types other than UPDATE. >> o There is a little bit work for a sender that wishes to send a large OPEN (e.g., >> using the prior capability and possibly subsequent NOTIFICATION). >> >> Additionally, I do not see a need to touch on the FSM specified in RFC 4271 even >> in the case of sending a large OPEN, which potentially may involve two separate >> consecutive sessions but each session would just follow the existing FSM. >> >> Thanks. -- Enke >> >> On 3/7/17 7:32 AM, Susan Hares wrote: >> > Robert: >> > >> > >> > >> > Yep - Easier to just include all messages. >> > >> > >> > >> > Sue >> > >> > >> > >> > *From:*rraszuk@gmail.com [mailto:rraszuk@gmail.com] *On Behalf Of *Robert Raszuk >> > *Sent:* Tuesday, March 7, 2017 10:33 AM >> > *To:* Susan Hares >> > *Cc:* Randy Bush; Enke Chen; Jeffrey Haas; Alvaro Retana (aretana); idr-chairs@ietf.org; draft-ietf-idr-bgp-extended-messages@ietf.org; idr wg >> > *Subject:* Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20 >> > >> > >> > >> > Hi Sue, >> > >> > >> > >> >> My suggestion is to include all messages including future messages if approved. >> > >> > >> > >> > Ahh then it is great - we are in sync ! >> > >> > >> > >> > My other comments were just an opinion ... but if it is easier to extend all messages then perfect. >> > >> > >> > >> > Cheers, >> > >> > R. >> > >> > >> > >> > >> > >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >> >> From nobody Tue Mar 7 17:21:22 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7C93129482; Tue, 7 Mar 2017 17:21:19 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XkLArFKhAubt; Tue, 7 Mar 2017 17:21:17 -0800 (PST) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0129.outbound.protection.outlook.com [23.103.201.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BCBA129447; Tue, 7 Mar 2017 17:21:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=SpyyREOUdSbdoseV7nYDTqVuY6CrjbqvtnQPK+peLT0=; b=ypoPspRlfnry9KjeQyWR/79/2JgeKkLdeivgiqv+q4ixQBqXGLJz84jsBzPbeR9GVoysGc/D0a0/98gn58CcLAm7raWu6P7YFWq7XvFQ5VtUt71sixR4y4cfQMLo8OmdF8zj41u6DvLXCUwNjLCue1W6jJ8rf74yPJbG/HMoUtc= Received: from BL2PR09MB0996.namprd09.prod.outlook.com (10.167.102.15) by BL2PR09MB0995.namprd09.prod.outlook.com (10.167.102.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.12; Wed, 8 Mar 2017 01:21:14 +0000 Received: from BL2PR09MB0996.namprd09.prod.outlook.com ([10.167.102.15]) by BL2PR09MB0996.namprd09.prod.outlook.com ([10.167.102.15]) with mapi id 15.01.0947.020; Wed, 8 Mar 2017 01:21:14 +0000 From: "Borchert, Oliver (Fed)" To: Enke Chen Thread-Topic: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20 Thread-Index: AQHSjglrFbHoeYS2WUyxb/MV1DegzqF+8PqAgAlhrgCAAEiTgIAAnkCAgAA/eoCAABXogIAAAp8AgAACk4CAAAAMgIAANcUA////qgCAAFVAgP//xd8A Date: Wed, 8 Mar 2017 01:21:14 +0000 Message-ID: References: <20170228210627.GB17448@pfrc.org> <3eb4d853-1d44-6250-c70a-26f60eac39e6@cisco.com> <006e01d296db$a7c4c320$f74e4960$@ndzh.com> <010101d2974a$8520d060$8f627120$@ndzh.com> <018c01d29756$c8b4f610$5a1ee230$@ndzh.com> <01b301d29758$180458e0$480d0aa0$@ndzh.com> <7657b686-0685-9bdf-17ba-e7d618a237aa@cisco.com> In-Reply-To: <7657b686-0685-9bdf-17ba-e7d618a237aa@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [71.114.41.213] x-ms-office365-filtering-correlation-id: 62003def-6098-4d15-07ad-08d465c16a1b x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BL2PR09MB0995; x-microsoft-exchange-diagnostics: 1; BL2PR09MB0995; 7:jctdo6tdIe4fxPHKcGBsBndBgpnuXZMHWwO9nz3Chn4ifWhv7FfNjz5I7mmeH/mEU/rRC/CVo6ErXEljG2Jn9HRG0v2iidAurd/e+MnY3AzzhEC771WATGdRgbKpYI7VJg07rVq6YcBeJ3ypyHlaMvEhprylzozvu6pyGza8/0PsoDfsVzesp8QNgATLXYwV7YoxfyLNlJSO+JWVU1i2KFQgRvbRZcJlcbn4Sqp32Q6soJ6F1LbQgDE5JbeiDMm/p9gZmPyi5T44fttX0r3BFs1P66NHKUYqXNjIwrKUjFITYpsBHx/M83Xk1+j3VDbGzsqrEgby1CAhrvj/QkAENA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(20161123558025)(6072148); SRVR:BL2PR09MB0995; BCL:0; PCL:0; RULEID:; SRVR:BL2PR09MB0995; x-forefront-prvs: 02408926C4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39450400003)(39850400002)(39860400002)(39840400002)(51914003)(24454002)(377454003)(189998001)(66066001)(83716003)(6506006)(77096006)(6916009)(6486002)(53546006)(229853002)(4001350100001)(2950100002)(86362001)(76176999)(2900100001)(83506001)(81166006)(122556002)(8676002)(50986999)(54356999)(82746002)(8936002)(5660300001)(3280700002)(106116001)(15650500001)(3660700001)(33656002)(93886004)(230783001)(99286003)(110136004)(53936002)(36756003)(54906002)(38730400002)(6306002)(6512007)(6436002)(6246003)(25786008)(305945005)(4326008)(3846002)(6116002)(102836003)(7736002)(2906002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR09MB0995; H:BL2PR09MB0996.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Mar 2017 01:21:14.8707 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR09MB0995 Archived-At: Cc: 'idr wg' , "draft-ietf-idr-bgp-extended-messages@ietf.org" , 'Robert Raszuk' , Susan Hares , "idr-chairs@ietf.org" Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 01:21:19 -0000 RW5rZSwNCg0KdGhhbmtzIGZvciB0aGUgcG9pbnRlci4gV2l0aCB0aGlzIGluIG1pbmQsIGl0IG1h a2VzIHBlcmZlY3RseSBzZW5zZSB0aGVuIHRvIGhhdmUgYWxsIGJncCBtZXNzYWdlcyBpbmNsdWRl ZCByYXRoZXIgdGhhbiDigJxjaGVycnkgcGlja2luZ+KAnSBzb21lIG9mIHRoZW0uDQoNCk9saXZl cg0KDQpPbiAzLzcvMTcsIDY6NDkgUE0sICJFbmtlIENoZW4iIDxlbmtlY2hlbkBjaXNjby5jb20+ IHdyb3RlOg0KDQogICAgUGxlYXNlIGNoZWNrIG91dCB0aGUgZm9sbG93aW5nIGRvY3VtZW50Og0K ICAgIA0KICAgIEV4dGVuZGVkIE9wdGlvbmFsIFBhcmFtZXRlcnMgTGVuZ3RoIGZvciBCR1AgT1BF TiBNZXNzYWdlDQogICAgZHJhZnQtaWV0Zi1pZHItZXh0LW9wdC1wYXJhbS0wMg0KICAgIA0KICAg IC0tIEVua2UNCiAgICANCiAgICBPbiAzLzcvMTcgMzo0NCBQTSwgQm9yY2hlcnQsIE9saXZlciAo RmVkKSB3cm90ZToNCiAgICA+IEkgYW0gd29uZGVyaW5nIOKAkyBhY2NvcmRpbmcgdG8gUkZDIDQy NzEsIGhvdyBjYW4gYW4gT1BFTiBtZXNzYWdlIGV2ZXIgZXhjZWVkIDI4NCBieXRlcz8NCiAgICA+ IFRoZSBiZ3AgbWVzc2FnZSBoZWFkZXIgaGFzIDE5IGJ5dGVzIGFuZCB0aGUgT1BFTiBtZXNzYWdl IHBheWxvYWQgYWRkcyAxMC4gVGhpcyBpcyAyOSwgdGhlbiB0aGUgb25seSANCiAgICA+IGFkZGl0 aW9uIGhlcmUgYXJlIHRoZSBPcHRpb25hbCBQYXJhbWV0ZXJzIHdoaWNoIGNhbm5vdCBleGNlZWQg MjU1IGJ5dGVzIGNvbWJpbmVkIGR1ZSB0byB0aGUgMSBieXRlIGxlbmd0aCBmaWVsZC4NCiAgICA+ IA0KICAgID4gVGhlcmVmb3JlLCBhbiBvcGVuIG1lc3NhZ2UgY2Fubm90IGV4Y2VlZCAyODQgYnl0 ZXMgYW5kIGlmIGxhcmdlciB0aGFuIDI4NCBieXRlcywgd291bGRu4oCZdCBpdCBiZSBpbnZhbGlk LiANCiAgICA+IA0KICAgID4gSW4gdGhpcyByZWdhcmQsIEkgZG9u4oCZdCByZWFsbHkgdW5kZXJz dGFuZCB0aGUgd2hvbGUgZGlzY3Vzc2lvbiBhYm91dCBhbGxvd2luZyBhbiBPUEVOIG1lc3NhZ2Ug bGFyZ2VyIHRoYW4gNEsuIA0KICAgID4gSXQgc2hvdWxkbuKAmXQgZXZlbiBiZSBsYXJnZXIgdGhh biAyODQgYnl0ZXM/ICBNYXliZSBJIGFtIG1pc3Npbmcgc29tZXRoaW5nLg0KICAgID4gDQogICAg PiBCVFcsIHNhbWUgaXMgdHJ1ZSBmb3IgS0VFUEFMSVZFIChtYXggMTkgYnl0ZXMpDQogICAgPiAN CiAgICA+IE9saXZlcg0KICAgID4gDQogICAgPiANCiAgICA+IA0KICAgID4gT24gMy83LzE3LCAx OjQ1IFBNLCAiSWRyIG9uIGJlaGFsZiBvZiBFbmtlIENoZW4iIDxpZHItYm91bmNlc0BpZXRmLm9y ZyBvbiBiZWhhbGYgb2YgZW5rZWNoZW5AY2lzY28uY29tPiB3cm90ZToNCiAgICA+IA0KICAgID4g ICAgIEhpLCBGb2xrczoNCiAgICA+ICAgICANCiAgICA+ICAgICBvIFRoZXJlIGlzIG5vIGV4dHJh IHdvcmsgZm9yIGEgcmVjZWl2ZXIgdG8gY292ZXIgbWVzc2FnZSB0eXBlcyBvdGhlciB0aGFuIFVQ REFURS4NCiAgICA+ICAgICBvIFRoZXJlIGlzIGEgbGl0dGxlIGJpdCB3b3JrIGZvciBhIHNlbmRl ciB0aGF0IHdpc2hlcyB0byBzZW5kIGEgbGFyZ2UgT1BFTiAoZS5nLiwNCiAgICA+ICAgICAgIHVz aW5nIHRoZSBwcmlvciBjYXBhYmlsaXR5IGFuZCBwb3NzaWJseSBzdWJzZXF1ZW50IE5PVElGSUNB VElPTikuDQogICAgPiAgICAgDQogICAgPiAgICAgQWRkaXRpb25hbGx5LCBJIGRvIG5vdCBzZWUg YSBuZWVkIHRvIHRvdWNoIG9uIHRoZSBGU00gc3BlY2lmaWVkIGluIFJGQyA0MjcxIGV2ZW4NCiAg ICA+ICAgICBpbiB0aGUgY2FzZSBvZiBzZW5kaW5nIGEgbGFyZ2UgT1BFTiwgd2hpY2ggcG90ZW50 aWFsbHkgbWF5IGludm9sdmUgdHdvIHNlcGFyYXRlDQogICAgPiAgICAgY29uc2VjdXRpdmUgc2Vz c2lvbnMgYnV0IGVhY2ggc2Vzc2lvbiB3b3VsZCBqdXN0IGZvbGxvdyB0aGUgZXhpc3RpbmcgRlNN Lg0KICAgID4gICAgIA0KICAgID4gICAgIFRoYW5rcy4gICAtLSBFbmtlDQogICAgPiAgICAgDQog ICAgPiAgICAgT24gMy83LzE3IDc6MzIgQU0sIFN1c2FuIEhhcmVzIHdyb3RlOg0KICAgID4gICAg ID4gUm9iZXJ0Og0KICAgID4gICAgID4gDQogICAgPiAgICAgPiA8aW5kaXZpZHVhbCBjb250cmli dXRvcuKAmXMgaGF0IG9uPg0KICAgID4gICAgID4gDQogICAgPiAgICAgPiBZZXAgIC0gRWFzaWVy IHRvIGp1c3QgaW5jbHVkZSBhbGwgbWVzc2FnZXMuICANCiAgICA+ICAgICA+IA0KICAgID4gICAg ID4gIA0KICAgID4gICAgID4gDQogICAgPiAgICAgPiBTdWUNCiAgICA+ICAgICA+IA0KICAgID4g ICAgID4gIA0KICAgID4gICAgID4gDQogICAgPiAgICAgPiAqRnJvbToqcnJhc3p1a0BnbWFpbC5j b20gW21haWx0bzpycmFzenVrQGdtYWlsLmNvbV0gKk9uIEJlaGFsZiBPZiAqUm9iZXJ0IFJhc3p1 aw0KICAgID4gICAgID4gKlNlbnQ6KiBUdWVzZGF5LCBNYXJjaCA3LCAyMDE3IDEwOjMzIEFNDQog ICAgPiAgICAgPiAqVG86KiBTdXNhbiBIYXJlcw0KICAgID4gICAgID4gKkNjOiogUmFuZHkgQnVz aDsgRW5rZSBDaGVuOyBKZWZmcmV5IEhhYXM7IEFsdmFybyBSZXRhbmEgKGFyZXRhbmEpOyBpZHIt Y2hhaXJzQGlldGYub3JnOyBkcmFmdC1pZXRmLWlkci1iZ3AtZXh0ZW5kZWQtbWVzc2FnZXNAaWV0 Zi5vcmc7IGlkciB3Zw0KICAgID4gICAgID4gKlN1YmplY3Q6KiBSZTogW0lkcl0gQUQgUmV2aWV3 IG9mIGRyYWZ0LWlldGYtaWRyLWJncC1leHRlbmRlZC1tZXNzYWdlcy0yMA0KICAgID4gICAgID4g DQogICAgPiAgICAgPiAgDQogICAgPiAgICAgPiANCiAgICA+ICAgICA+IEhpIFN1ZSwNCiAgICA+ ICAgICA+IA0KICAgID4gICAgID4gIA0KICAgID4gICAgID4gDQogICAgPiAgICAgPj4gTXkgc3Vn Z2VzdGlvbiBpcyB0byBpbmNsdWRlIGFsbCBtZXNzYWdlcyBpbmNsdWRpbmcgZnV0dXJlIG1lc3Nh Z2VzIGlmIGFwcHJvdmVkLiAgDQogICAgPiAgICAgPiANCiAgICA+ICAgICA+ICANCiAgICA+ICAg ICA+IA0KICAgID4gICAgID4gQWhoIHRoZW4gaXQgaXMgZ3JlYXQgLSB3ZSBhcmUgaW4gc3luYyAh IA0KICAgID4gICAgID4gDQogICAgPiAgICAgPiAgDQogICAgPiAgICAgPiANCiAgICA+ICAgICA+ IE15IG90aGVyIGNvbW1lbnRzIHdlcmUganVzdCBhbiBvcGluaW9uIC4uLiBidXQgaWYgaXQgaXMg ZWFzaWVyIHRvIGV4dGVuZCBhbGwgbWVzc2FnZXMgdGhlbiBwZXJmZWN0LiANCiAgICA+ICAgICA+ IA0KICAgID4gICAgID4gIA0KICAgID4gICAgID4gDQogICAgPiAgICAgPiBDaGVlcnMsDQogICAg PiAgICAgPiANCiAgICA+ICAgICA+IFIuDQogICAgPiAgICAgPiANCiAgICA+ICAgICA+ICANCiAg ICA+ICAgICA+IA0KICAgID4gICAgID4gIA0KICAgID4gICAgID4gDQogICAgPiAgICAgDQogICAg PiAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAg ICA+ICAgICBJZHIgbWFpbGluZyBsaXN0DQogICAgPiAgICAgSWRyQGlldGYub3JnDQogICAgPiAg ICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZHINCiAgICA+ICAgICAN CiAgICA+IA0KICAgIA0KDQo= From nobody Tue Mar 7 20:14:50 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF35A129418; Tue, 7 Mar 2017 20:14:48 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=verizon.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9nio4-GCZQ0; Tue, 7 Mar 2017 20:14:46 -0800 (PST) Received: from omzsmtpe02.verizonbusiness.com (omzsmtpe02.verizonbusiness.com [199.249.25.209]) (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 E3D4B12946D; Tue, 7 Mar 2017 20:14:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=verizon.com; i=@verizon.com; q=dns/txt; s=corp; t=1488946486; x=1520482486; h=from:to:date:subject:message-id:references:in-reply-to: mime-version; bh=SZWoyaA+YrhtgmkWyrzUHu0QE/KwXHPtXs6FSCyAaFY=; b=LU0UYZ+NmKI2wWwxNcXlB7D9CPUi0rsstZiPEMd5acsmviDI0uCPi+9m 5mdofRTxVsaAkQLm/KWlJJ+c6Etx94909YHJBrlX2w6MlgNDOywCuqz04 FgqVjxZV+HxiEM5U29+7Q+SrCnDpv3rPSTdyhrMHc9u2S0+uVLyDNSq6O o=; X-IronPort-Anti-Spam-Filtered: false Received: from omzsmtpi02.vzbi.com ([165.122.46.172]) by omzsmtpe02.verizonbusiness.com with ESMTP; 08 Mar 2017 04:14:44 +0000 From: "Tomotaki, Luis M" X-IronPort-AV: E=Sophos;i="5.36,261,1486425600"; d="scan'208,217";a="106723023" Received: from fhdp1lumxc7hb05.verizon.com (HELO FHDP1LUMXC7HB05.us.one.verizon.com) ([166.68.59.192]) by omzsmtpi02.vzbi.com with ESMTP/TLS/AES128-SHA; 08 Mar 2017 04:14:42 +0000 Received: from FHDP1LUMXC7V91.us.one.verizon.com ([166.68.240.155]) by FHDP1LUMXC7HB05.us.one.verizon.com ([166.68.59.192]) with mapi; Tue, 7 Mar 2017 23:14:42 -0500 To: Shitanshu Shah , Susan Hares , 'Ron Bonica' , "rtg-dir@ietf.org" , "draft-ietf-idr-sla-exchange.all@ietf.org" , "idr@ietf.org" Date: Tue, 7 Mar 2017 23:10:51 -0500 Thread-Topic: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 Thread-Index: AdKIcLCEU+uutt39QyCrZCwOKAXyLQAcLKCoAUVZnUABwWlZAABkf7iDAEubxBA= Message-ID: <467340A77F13C944919805BFF3B8ACFC30DC040408@FHDP1LUMXC7V91.us.one.verizon.com> References: , <053401d294fc$6f739180$4e5ab480$@ndzh.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_467340A77F13C944919805BFF3B8ACFC30DC040408FHDP1LUMXC7V9_" MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 04:14:48 -0000 --_000_467340A77F13C944919805BFF3B8ACFC30DC040408FHDP1LUMXC7V9_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ron and Sue, >From a service provider perspective, exchanging the SLA information between= the PE and CE would be very beneficial and could be widely used. I think = this is particular important in service provider's L3VPN networks where the= customers or service providers currently do not have full visibility to th= e QoS policy in the other end of the connection but still needs matching CE= -PE SLA/QoS policies to achieve the correct two-way traffic prioritization = behavior during congestion. In this example, once the SLA information exch= ange is standardized, my expectation is that the different CE/PE vendors wo= uld be able to automatically update in a vendor specific way, the SLA/QoS p= olicies based on the SLA information provided via BGP. Luis From: Shitanshu Shah [mailto:shitanshu_shah@hotmail.com] Sent: Monday, March 6, 2017 9:31 AM To: Susan Hares ; 'Ron Bonica' ; rtg-= dir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; idr@ietf.org Subject: [E] Re: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 Hi Sue, Following is what I had responded to Ron. Hopefully that addresses/clarifie= s. To break it down in two point response, 1) This draft is not changing how SLA is established at first place. The dr= aft is providing a method to convey this a priori established SLA to help r= educe lot of manual complexities and errors to admin. Thus given a knowledg= e of what SLA is established, in general devices should be capable to suppo= rt that established SLA. 2) If there still are any issues in implementing exchanged SLA in forwardin= g, we think they either are implementation specific or of temporary nature = where for example enough resources not available at any specific point of a= time. We feel that in current state of the draft, it can be largely useful in dep= loyments. One can imagine though even establishment of SLA also can be done via excha= nging it over bgp. However, negotiation of SLA does not have to be clubbed = with exchange of SLA. Negotiation of SLA is not in this scope. Regards, Shitanshu ________________________________ From: Susan Hares > Sent: Saturday, March 4, 2017 8:31 AM To: 'Ron Bonica'; 'Shitanshu Shah'; rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; idr@ietf.org Subject: RE: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 Shitanshu: Please address Ron's comment about widely deployed. I believe this was par= t of Alvaro's comments. Sue From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Ron Bonica Sent: Thursday, February 23, 2017 12:07 PM To: Shitanshu Shah; rtg-dir@ietf.org; draft-ietf-i= dr-sla-exchange.all@ietf.org; idr@ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 Hello, The draft is internally consistent. But given what is left out of scope, I = wonder if the new attributes will ever be widely deployed. = Ron This document might benefit from discussion of operational issues. I assume= that when a BGP listener learns a route with the SLA Exchange Attribute, i= t provisions class of service forwarding classes on interfaces. ##svshah, though this is one desired use of exchanging SLA content, the dra= ft focuses on transporting SLA content from the SLA Producer to the SLA Con= sumer. Processing of the QoS attribute content, at the SLA Consumer, is out= side the scope of this document. ##svshah, Let me know if you have a suggestion to make description clearer = in Section 1 and 2 to highlight this. I also assume that a) it takes time to provision class of service forwardin= g classes and b) the number of forwarding classes that can be provisioned a= re finite. What does the BGP listener do when the number of forwarding clas= ses requested exceeds its capacity to deliver? ##svshah, Since scope of the document is to transport SLA content from the = SLA Producer to the SLA Consumer, the document considers error handling in = the context of transporting data and thus any formating errors and semantic= s errors within that context. Any errors in the context of processing QoS a= ttribute content at the SLA Consumer is outside the scope of the document. --_000_467340A77F13C944919805BFF3B8ACFC30DC040408FHDP1LUMXC7V9_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ron= and Sue,

From a service pro= vider perspective, exchanging the SLA information between the PE and CE wou= ld be very beneficial and could be widely used.  I think this is parti= cular important in service provider’s L3VPN networks where the custom= ers or service providers currently do not have full visibility to the QoS p= olicy in the other end of the connection but still needs matching CE-PE SLA= /QoS policies to achieve the correct two-way traffic prioritization behavio= r during congestion.  In this example, once the SLA information exchan= ge is standardized, my expectation is that the different CE/PE vendors woul= d be able to automatically update in a vendor specific way, the SLA/QoS pol= icies based on the SLA information provided via BGP. 

 

Luis

 <= /o:p>

From: Shitanshu Shah [mailto= :shitanshu_shah@hotmail.com]
Sent: Monday, March 6, 2017 9:31 AM=
To: Susan Hares <shares@ndzh.com>; 'Ron Bonica' <rbonic= a@juniper.net>; rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.o= rg; idr@ietf.org
Subject: [E] Re: [RTG-DIR] RtgDir review: draft-= ietf-idr-sla-exchange-10

 

Hi Sue,

<= p> <= /o:p>

Following is what I had responded to Ron. Hopefully that addresse= s/clarifies.

 

To break it down in two point respo= nse,

 

1) This draft is not changing how SLA is es= tablished at first place. The draft is providing a method to convey th= is a priori established SLA to help reduce lot of manual complexities = and errors to admin. Thus given a knowledge of what SLA is established, in = general devices should be capable to support that established SLA.

 

 

2) If there still are any issues i= n implementing exchanged SLA in forwarding, we think they either are implem= entation specific or of temporary nature where for example enough reso= urces not available at any specific point of a time.

<= p> <= /o:p>

We feel that in current state of the draft, it can be largely useful i= n deployments.

 

 

 

One can imagine though even establishment of SLA also can be done via= exchanging it over bgp. However, negotiation of SLA does not have to be cl= ubbed with exchange of SLA. Negotiation of SLA is not in this scope.

 

Regards,

<= /div>

Shitanshu

 

From:<= span style=3D'font-size:11.0pt;font-family:"Calibri",sans-serif;color:black= '> Susan Hares <shares@ndzh.com&g= t;
Sent: Saturday, March 4, 2017 8:31 AM
To: 'Ron Bonic= a'; 'Shitanshu Shah'; rtg-dir@ietf.org<= /a>; draft-ietf= -idr-sla-exchange.all@ietf.org; idr@iet= f.org
Subject: RE: [RTG-DIR] RtgDir review: draft-ietf-idr-sl= a-exchange-10

 

=

Shitanshu: <= o:p>

 <= o:p>

Please address Ron’s comment about w= idely deployed.  I believe this was part of Alvaro’s comments. <= /span>

 =

Sue

 =

From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Ron BonicaSent: Thursday, February 23, 2017 12:07 PM
To: Shitanshu = Shah; rtg-dir@ietf.org; draft-ietf-idr-sla-exchang= e.all@ietf.org; idr@ietf.org
= Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10

<= span style=3D'color:black'> 

Hello,=

 =

The dr= aft is internally consistent. But given what is left out of scope, I wonder= if the new attributes will ever be widely deployed.

 

     = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            Ron<= /span>

 =

 =


This= document might benefit from discussion of operational issues. I assume tha= t when a BGP listener learns a route with the SLA Exchange Attribute, it pr= ovisions class of service forwarding classes on interfaces.

 

##svshah, though this = is one desired use of exchanging SLA content, the draft focuses on transpor= ting SLA content from the SLA Producer to the SLA Consumer. Processing of t= he QoS attribute content, at the SLA Consumer, is outside the scope of this= document.

 

= ##svs= hah, Let me know if you have a suggestion to make description clearer in Se= ction 1 and 2 to highlight this.

 <= /span>

<= span style=3D'font-size:10.0pt;font-family:"Calibri",sans-serif;color:black= '> 

I also assume that a) it takes time to provision class of servic= e forwarding classes and b) the number of forwarding classes that can be pr= ovisioned are finite. What does the BGP listener do when the number of forw= arding classes requested exceeds its capacity to deliver? 

 

##svshah, S= ince scope of the document is to transport SLA content from the SLA Produce= r to the SLA Consumer, the document considers error handling in the context= of transporting data and thus any formating errors and semantics errors wi= thin that context. Any errors in the context of processing QoS attribute co= ntent at the SLA Consumer is outside the scope of the document.<= /p>

 

&= nbsp;

 

= --_000_467340A77F13C944919805BFF3B8ACFC30DC040408FHDP1LUMXC7V9_-- From nobody Wed Mar 8 07:27:46 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C49E912966B; Wed, 8 Mar 2017 07:27:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ZVZB8FXbTXy; Wed, 8 Mar 2017 07:27:40 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 B230C1296E8; Wed, 8 Mar 2017 07:27:39 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.90.29; From: "Susan Hares" To: "'Tomotaki, Luis M'" , "'Shitanshu Shah'" , "'Ron Bonica'" , , , References: , <053401d294fc$6f739180$4e5ab480$@ndzh.com> <467340A77F13C944919805BFF3B8ACFC30DC040408@FHDP1LUMXC7V91.us.one.verizon.com> In-Reply-To: <467340A77F13C944919805BFF3B8ACFC30DC040408@FHDP1LUMXC7V91.us.one.verizon.com> Date: Wed, 8 Mar 2017 10:22:33 -0500 Message-ID: <011601d2981f$cfe364c0$6faa2e40$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0117_01D297F5.E7106A00" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH+U8bIprcHIBv9vIIxWXYNekqkjQJ00uVDAja9hsUCLb3BQwJAbTElA0kpQQ2g0IB64A== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 15:27:42 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0117_01D297F5.E7106A00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Luis: Thank you for letting me know you desire for this feature. Since Ron had additional questions, I'll let him start off this discussion. Sue From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Tomotaki, Luis M Sent: Tuesday, March 7, 2017 11:11 PM To: Shitanshu Shah; Susan Hares; 'Ron Bonica'; rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; idr@ietf.org Subject: Re: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 Ron and Sue, >From a service provider perspective, exchanging the SLA information between the PE and CE would be very beneficial and could be widely used. I think this is particular important in service provider's L3VPN networks where the customers or service providers currently do not have full visibility to the QoS policy in the other end of the connection but still needs matching CE-PE SLA/QoS policies to achieve the correct two-way traffic prioritization behavior during congestion. In this example, once the SLA information exchange is standardized, my expectation is that the different CE/PE vendors would be able to automatically update in a vendor specific way, the SLA/QoS policies based on the SLA information provided via BGP. Luis From: Shitanshu Shah [mailto:shitanshu_shah@hotmail.com] Sent: Monday, March 6, 2017 9:31 AM To: Susan Hares ; 'Ron Bonica' ; rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; idr@ietf.org Subject: [E] Re: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 Hi Sue, Following is what I had responded to Ron. Hopefully that addresses/clarifies. To break it down in two point response, 1) This draft is not changing how SLA is established at first place. The draft is providing a method to convey this a priori established SLA to help reduce lot of manual complexities and errors to admin. Thus given a knowledge of what SLA is established, in general devices should be capable to support that established SLA. 2) If there still are any issues in implementing exchanged SLA in forwarding, we think they either are implementation specific or of temporary nature where for example enough resources not available at any specific point of a time. We feel that in current state of the draft, it can be largely useful in deployments. One can imagine though even establishment of SLA also can be done via exchanging it over bgp. However, negotiation of SLA does not have to be clubbed with exchange of SLA. Negotiation of SLA is not in this scope. Regards, Shitanshu _____ From: Susan Hares Sent: Saturday, March 4, 2017 8:31 AM To: 'Ron Bonica'; 'Shitanshu Shah'; rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; idr@ietf.org Subject: RE: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 Shitanshu: Please address Ron's comment about widely deployed. I believe this was part of Alvaro's comments. Sue From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Ron Bonica Sent: Thursday, February 23, 2017 12:07 PM To: Shitanshu Shah; rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; idr@ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 Hello, The draft is internally consistent. But given what is left out of scope, I wonder if the new attributes will ever be widely deployed. Ron This document might benefit from discussion of operational issues. I assume that when a BGP listener learns a route with the SLA Exchange Attribute, it provisions class of service forwarding classes on interfaces. ##svshah, though this is one desired use of exchanging SLA content, the draft focuses on transporting SLA content from the SLA Producer to the SLA Consumer. Processing of the QoS attribute content, at the SLA Consumer, is outside the scope of this document. ##svshah, Let me know if you have a suggestion to make description clearer in Section 1 and 2 to highlight this. I also assume that a) it takes time to provision class of service forwarding classes and b) the number of forwarding classes that can be provisioned are finite. What does the BGP listener do when the number of forwarding classes requested exceeds its capacity to deliver? ##svshah, Since scope of the document is to transport SLA content from the SLA Producer to the SLA Consumer, the document considers error handling in the context of transporting data and thus any formating errors and semantics errors within that context. Any errors in the context of processing QoS attribute content at the SLA Consumer is outside the scope of the document. ------=_NextPart_000_0117_01D297F5.E7106A00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Luis:

 

Thank you for letting me know you desire for this feature.  =  Since Ron had additional questions, I’ll let him start off = this discussion.

 

Sue

 

From:= = Idr [mailto:idr-bounces@ietf.org] On Behalf Of Tomotaki, Luis = M
Sent: Tuesday, March 7, 2017 11:11 PM
To: = Shitanshu Shah; Susan Hares; 'Ron Bonica'; rtg-dir@ietf.org; = draft-ietf-idr-sla-exchange.all@ietf.org; = idr@ietf.org
Subject: Re: [Idr] [RTG-DIR] RtgDir review: = draft-ietf-idr-sla-exchange-10

 

Ron and Sue,

From a service provider perspective, exchanging the SLA information = between the PE and CE would be very beneficial and could be widely = used.  I think this is particular important in service = provider’s L3VPN networks where the customers or service providers = currently do not have full visibility to the QoS policy in the other end = of the connection but still needs matching CE-PE SLA/QoS policies to = achieve the correct two-way traffic prioritization behavior during = congestion.  In this example, once the SLA information exchange is = standardized, my expectation is that the different CE/PE vendors would = be able to automatically update in a vendor specific way, the SLA/QoS = policies based on the SLA information provided via BGP.  =

 

Luis

 

From: Shitanshu = Shah [mailto:shitanshu_shah@hotmail.= com]
Sent: Monday, March 6, 2017 9:31 AM
To: = Susan Hares <shares@ndzh.com>; 'Ron Bonica' = <rbonica@juniper.net>; = rtg-dir@ietf.org; draft-ietf-idr-s= la-exchange.all@ietf.org; idr@ietf.org
Subject: [E] Re: = [RTG-DIR] RtgDir review: = draft-ietf-idr-sla-exchange-10

 

Hi = Sue,

 

Following is = what I had responded to Ron. Hopefully that = addresses/clarifies.

 

To break it = down in two point response,

 

1) This draft = is not changing how SLA is established at first place. The draft is = providing a method to convey this a priori established SLA to help = reduce lot of manual complexities and errors to admin. Thus given a = knowledge of what SLA is established, in general devices should be = capable to support that = established SLA.

 

 

2) If there = still are any issues in implementing exchanged SLA in forwarding, we = think they either are implementation specific or of temporary = nature where for example enough resources not available at any specific = point of a time.

 

We feel that in = current state of the draft, it can be largely useful in = deployments.

 

 

 

One can imagine = though even establishment of SLA also can be done via exchanging it = over bgp. However, negotiation of SLA does not have to be clubbed with = exchange of SLA. Negotiation of SLA is not in this = scope.

 

Regards,

Shitanshu

 

From: Susan Hares <shares@ndzh.com>
Sent: = Saturday, March 4, 2017 8:31 AM
To: 'Ron Bonica'; 'Shitanshu = Shah'; rtg-dir@ietf.org; draft-ietf-idr-s= la-exchange.all@ietf.org; idr@ietf.org
Subject: RE: = [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 =

 

Shitanshu:

 

Please address Ron’s comment about widely deployed.  I = believe this was part of Alvaro’s comments.

 

Sue

 

 

Hello,

 

The draft is internally consistent. But given what is left out of = scope, I wonder if the new attributes will ever be widely = deployed.

 

           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;       Ron

 

 


This document might benefit from discussion of operational issues. = I assume that when a BGP listener learns a route with the SLA Exchange = Attribute, it provisions class of service forwarding classes on = interfaces.

 

##svshah, though = this is one desired use of exchanging SLA content, the draft focuses on = transporting SLA content from the SLA Producer to the SLA Consumer. = Processing of the QoS attribute content, at the SLA Consumer, is outside = the scope of this document.

 

##svshah, Let me = know if you have a suggestion to make description clearer in Section 1 = and 2 to highlight this.

 

 

I also assume that a) it takes time to provision class of service = forwarding classes and b) the number of forwarding classes that can be = provisioned are finite. What does the BGP listener do when the number of = forwarding classes requested exceeds its capacity to = deliver? 

 

##svshah, Since = scope of the document is to transport SLA content from the SLA Producer = to the SLA Consumer, the document considers error handling in the = context of transporting data and thus any formating errors and semantics = errors within that context. Any errors in the context of processing QoS = attribute content at the SLA Consumer is outside the scope of the = document.

 

 

 

------=_NextPart_000_0117_01D297F5.E7106A00-- From nobody Wed Mar 8 08:51:35 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA62E12943E; Wed, 8 Mar 2017 08:51:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JNTanND_TJoQ; Wed, 8 Mar 2017 08:51:25 -0800 (PST) Received: from relais-inet.orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD81B126DFB; Wed, 8 Mar 2017 08:51:24 -0800 (PST) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 8874CC0615; Wed, 8 Mar 2017 17:51:23 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.61]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 58AEA1200F5; Wed, 8 Mar 2017 17:51:23 +0100 (CET) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM7E.corporate.adroot.infra.ftgroup ([fe80::b91c:ea2c:ac8a:7462%19]) with mapi id 14.03.0319.002; Wed, 8 Mar 2017 17:51:22 +0100 From: To: Susan Hares Thread-Topic: [Idr] 2 Week WG LC for draft-ietf-idr-bgp-prefix-sid-04.txt - 3/6 to 3/20/2017 Thread-Index: AdKW8TLVqllJkcvhQbeGPXZzhGF0pwBKGbdg Date: Wed, 8 Mar 2017 16:51:22 +0000 Message-ID: <6339_1488991883_58C0368B_6339_12244_1_53C29892C857584299CBF5D05346208A1ED9982C@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <00c501d296f2$a7a0c8f0$f6e25ad0$@ndzh.com> In-Reply-To: <00c501d296f2$a7a0c8f0$f6e25ad0$@ndzh.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.3] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A1ED9982COPEXCLILM21corp_" MIME-Version: 1.0 Archived-At: Cc: "idr@ietf.org" , "spring@ietf.org" , 'Hannes Gredler' Subject: Re: [Idr] 2 Week WG LC for draft-ietf-idr-bgp-prefix-sid-04.txt - 3/6 to 3/20/2017 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 16:51:28 -0000 --_000_53C29892C857584299CBF5D05346208A1ED9982COPEXCLILM21corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cross-posting to SPRING WG as this document is highly related to draft-ietf= -spring-segment-routing-msdc which is under WG Last Call in the SPRING WG. I've read the document and have the following comments. ----- =A72 'A BGP-Prefix-SID is always global within the SR/BGP domain' Do you imply that this extension may only be used within one SR/BGP domain? IOW all involved ASes must coordinate their BGP SID allocation? This would fit the MSDC use case discussed in draft-ietf-spring-segment-rou= ting-msdc, but may be a restriction for other uses cases (e.g. Inter AS VPN= option C requiring an inter-AS MPLS LSP). Could the document clarify/elaborate on this? One option may be for the ASBR to be configured to shit the received index = by an offset (e.g. +1000). (this possibility could be referred to in sectio= n 6.1) -- =A72 'A BGP-Prefix-SID is always global within the SR/BGP domain' On a side note, - on the BGP side, IMHO, a BGP domain probably means an AS (looking back up= to RFC 1771 I'm not seeing the definition of a BGP domain) - on the SR side, I think you mean that all ASes in the DC are in the same = SR domain Hence SR domain does not equal a BGP domain. ----- =A72: "the newly proposed BGP Prefix-SID attribute can be attached to prefi= xes from AFI/SAFI: =BB =A73: "The BGP-Prefix-SID attached to a BGP prefix P" =A73.1: "this TLV can be used to advertise the label index of a given prefi= x" IINM, BGP Attributes are not attached to (IP) prefixes but shared by all pr= efixes of a given BGP UPDATE. In addition to the terminology point, this has consequences as: - [RFC3107] and [RFC4760] allow the advertisement of multiple IP prefixes p= er BGP UPDATE - draft-ietf-idr-bgp-prefix-sid would add the new requirement that each IP = prefix be advertised in a dedicated BGP UPDATE. (unless multiple Label-Inde= x TLB must be advertised) If this extension requires the use of one BGP update message per IP prefix,= I think this point should be highlighted and discussed in both draft-ietf-= idr-bgp-prefix-sid and draft-ietf-spring-segment-routing-msdc --- =A72 "the newly proposed BGP Prefix-SID attribute can be attached to prefixes fr= om AFI/SAFI: Multiprotocol BGP labeled IPv4/IPv6 Unicast ([RFC3107]). Multiprotocol BGP ([RFC4760]) un= labeled IPv6 Unicast." If this attribute is found on routes of different AFI/SAFI, how is this han= dled? Is this considered an error (hence attribute is discarded as per =A77) If so, this does not seem to work in Carrier's carrier VPN case (where the = CE use AFI/SAFI 1/4 routes, may attach the Prefix-SID attribute; then the P= E will transform this route into a AFI/SAFI 1/128 with the same Prefix-SID = attribute attached). If not, it must be clear that the BGP-Prefix-SID Index must not be used on = the VPN route. Can this also be clarified in section 7 (error handling)? --- =A74 " The BGP Prefix SID attribute is an optional, transitive BGP path attribut= e. =BB Hence this attribute may spread very far, e.g. received over Internet route= s. IPv6 Internet routes may be converted in AFI/SAFI 2/4 routes (labeled IPv6)= , in particular for AS running 6PE (RFC 4798). Hence this AS would interpre= t the Prefix SID and the received index would likely (or even deliberately)= collision with Index provisioned by this AS. I think the use of a transitive attribute is debatable given that this attr= ibute is not required for the service/network to work. i.e. it's only "nice= to have" in order for each node to use the same label (and assuming they c= an be configured with the same SRGB). So the document is trading security r= isk for a nice to have feature. --- =A75.1 " A BGP Prefix-SID attribute is called "unacceptable" for a speaker M if the derived label value L lies outside the SRGB configured on M. Otherwise the Label Index attribute is called "acceptable" to speaker M= . =BB The case where two different IP Prefixes are received with the same Index (= but with different labels) does not seem to be correctly handled. As per cu= rrent text, both Prefix would incorrectly be merged into the same FEC (inco= ming label). Also, the index in the BGP Prefix-SID may collision with the same index, re= ceived from a different protocol (e.g. IS-IS) with a different prefix. How = is this handled? This seems specifically an issue when combined with the previous point (com= ment). --- =A75.2 (IPv6 SID) " * S flag: if set then it means that the BGP speaker attaching the Prefix-SID Attribute to a prefix is capable of processing the IPv6 Segment Routing Header (SRH, [I-D.ietf-6man-segment-routing-header]= ) for the segment corresponding to the originated IPv6 prefix" A similar text has just been removed in the latest version of the SR ISIS e= xtension published yesterday (draft-ietf-isis-segment-routing-extensions-11= ). (cf "H-Flag"). Hence, are you sure that this SRv6 specific part is still applicable/up to = date? --- "9. Security Considerations This document introduces no new security considerations above and beyond= those already specified in [RFC4271] and [RFC3107]." Some of the comments above may probably have security considerations. --- Nits: =A74.1 OLD: None are defined at this stage of the document. NEW: None are defined by this document. -- =A72 OLD: the newly proposed BGP Prefix-SID attribute NEW: the BGP Prefix-SID attribute defined in this document -- "11. Change Log Initial Version: Sep 21 2014" This section does not seem that useful and could either be removed or compl= eted with the change log of all versions. -- Name of the attribute is not consistently spelled (e.g. BGP-Prefix-SID, BGP= Prefix SID, BGP Prefix-SID) Thanks Regards, --Bruno From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Tuesday, March 07, 2017 4:27 AM To: idr@ietf.org Cc: 'Hannes Gredler' Subject: [Idr] 2 Week WG LC for draft-ietf-idr-bgp-prefix-sid-04.txt - 3/6 = to 3/20/2017 This message begins a 2 week WG LC for draft-ietf-idr-bgp-prefix-sid-04.txt= (3/6 to 3/20). This draft proposed a new optional, transitive BGP path attribute, the BGP= Prefix Segment attribute to carry BGP Prefix Segment Identifier (BGP Prefi= x SID) information for: Label-Index, IPv6 SID, and Originator SRGB. This= draft is linked to work on DC segment routing describe draft-ietf-spring-s= egment-routing-msdc-03.txt. We have one remaining author (Arjun Sreekantiah) has not responded to the I= PR call, but it is likely he will respond shortly. If Arun does not respon= d to the IPR call during the first week, this WG LC will be extended for 1 = additional week. Three implementations exist and the details are on the web site, and in the= draft: https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-prefix-sid%20impleme= ntations Sue Hares ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_53C29892C857584299CBF5D05346208A1ED9982COPEXCLILM21corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Cross-p= osting to SPRING WG as this document is highly related to draft-ietf-spring= -segment-routing-msdc which is under WG Last Call in the SPRING WG.

&n= bsp;

I’= ;ve read the document and have the following comments.

&n= bsp;

-----

=A72

‘A BGP-Prefix-SID is always global wi= thin the SR/BGP domain’

&n= bsp;

Do you = imply that this extension may only be used within one SR/BGP domain?

IOW all= involved ASes must coordinate their BGP SID allocation?<= /p>

&n= bsp;

This wo= uld fit the MSDC use case discussed in draft-ietf-spring-segment-routing-ms= dc, but may be a restriction for other uses cases (e.g. Inter AS VPN option= C requiring an inter-AS MPLS LSP).

Could t= he document clarify/elaborate on this?

One opt= ion may be for the ASBR to be configured to shit the received index by an o= ffset (e.g. +1000). (this possibility could be referred to in section 6= .1)

--=

=A72

‘A BGP-Prefix-SID is always global wi= thin the SR/BGP domain’

&n= bsp;

On a si= de note,

- on th= e BGP side, IMHO, a BGP domain probably means an AS (looking back up to RFC= 1771 I’m not seeing the definition of a BGP domain)

- on th= e SR side, I think you mean that all ASes in the DC are in the same SR doma= in

&n= bsp;

Hence S= R domain does not equal a BGP domain.

-----

&n= bsp;

=A72: &= #8220;the newly proposed BGP Prefix-SID attribu= te can be attached to prefixes from AFI/SAFI: =BB

=A73: “The BGP-Prefix-SID attached to a BGP prefix P“ 
=A73.1: “this TLV can be used to advertise =
the label index of a given prefix”
 

&n= bsp;

IINM, B= GP Attributes are not attached to (IP) prefixes but shared by all prefixes = of a given BGP UPDATE.

In addi= tion to the terminology point, this has consequences as:<= /p>

- [RFC3= 107] and [RFC4760] allow the advertisement of multiple IP prefixes per BGP = UPDATE

- draft= -ietf-idr-bgp-prefix-sid would add the new requirement that each IP prefix = be advertised in a dedicated BGP UPDATE. (unless multiple Label-Index TLB m= ust be advertised)

&n= bsp;

If this= extension requires the use of one BGP update message per IP prefix, I thin= k this point should be highlighted and discussed in both draft-ietf-idr-bgp= -prefix-sid and draft-ietf-spring-segment-routing-msdc

&n= bsp;

---

=A72

“the newly proposed BGP Prefix-SID at= tribute can be attached to prefixes from AFI/SAFI:

      Multiprotoco= l BGP labeled IPv4/IPv6 Unicast ([RFC3107]).

      Multiprotoco= l BGP ([RFC4760<= /a>]) unlabeled IPv6 Unicast.”

 

If this= attribute is found on routes of different AFI/SAFI, how is this handled? I= s this considered an error (hence attribute is discarded as per =A77)<= /o:p>

If so, = this does not seem to work in Carrier’s carrier VPN case (where the C= E use AFI/SAFI 1/4 routes, may attach the Prefix-SID attribute; then the PE= will transform this route into a AFI/SAFI 1/128 with the same Prefix-SID attribute attached).

If not,= it must be clear that the BGP-Prefix-SID Index must not be used on the VPN= route.

&n= bsp;

Can thi= s also be clarified in section 7 (error handling)?

&n= bsp;

---

=A74
“ The BGP P=
refix SID attribute is an optional, transitive BGP path attribute. =BB=

 
Hence this attribute may spread very far, e.g=
. received over Internet routes. 
IPv6 Internet routes may be converted in AFI/=
SAFI 2/4 routes (labeled IPv6), in particular for AS running 6PE (RFC 4798)=
. Hence this AS would interpret the Prefix SID and the received index would=
 likely (or even deliberately) collision with Index provisioned by this AS.=

I think the use of a transitive attribute is =
debatable given that this attribute is not required for the service/network=
 to work. i.e. it’s only “nice to have” in order for each=
 node to use the same label (and assuming they can be configured with the s=
ame SRGB). So the document is trading security risk for a nice to have feat=
ure.
 
---
=A75.1
“   A BGP Prefix-SID attribute is=
 called "unacceptable" for a speaker M
   if the derived label value L lies ou=
tside the SRGB configured on M.
   Otherwise the Label Index attribute =
is called "acceptable" to speaker  M. =BB

&n= bsp;

The cas= e where two different IP Prefixes are received with the same Index (but wit= h different labels) does not seem to be correctly handled. As per current t= ext, both Prefix would incorrectly be merged into the same FEC (incoming label).

Also, t= he index in the BGP Prefix-SID may collision with the same index, received = from a different protocol (e.g. IS-IS) with a different prefix. How is this= handled?

This se= ems specifically an issue when combined with the previous point (comment).<= o:p>

---

=A75.2 = (IPv6 SID)

&n= bsp;

“      *  S f=
lag: if set then it means that the BGP speaker attaching the
         =
Prefix-SID Attribute to a prefix is capable of processing the
         =
IPv6 Segment Routing Header (SRH,
         =
[I-D.iet=
f-6man-segment-routing-header]) for the seg=
ment
         =
corresponding to the originated IPv6 prefix”

&n= bsp;

A simil= ar text has just been removed in the latest version of the SR ISIS extensio= n published yesterday (draft-ietf-isis-segment-routing-extensions-11). (cf = “H-Flag”).

Hence, = are you sure that this SRv6 specific part is still applicable/up to date?

&n= bsp;

&n= bsp;

---

“= 9.  Security Considerations

&n= bsp;

 &= nbsp; This document introduces no new security considerations above and bey= ond those already specified in [RFC4271] and [RFC3107].”

&n= bsp;

Some of= the comments above may probably have security considerations.

&n= bsp;

---

Nits:

=A74.1<= o:p>

OLD: None are def=
ined at this stage of the document.
NEW: None are def=
ined by this document.

--=

=A72

OLD: the newly pr=
oposed BGP Prefix-SID attribute
NEW: the BGP Pref=
ix-SID attribute defined in this document
--
“11.  Change Log

 


   Initial Version:  Sep 21 2014&#=
8221;


 


This section does not seem that useful and co=
uld either be removed or completed with the change log of all versions.


--


Name of=
 the attribute is not consistently spelled (e.g. BGP-Prefix-SID, BGP Prefix=
 SID, BGP Prefix-SID)



&n=
bsp;


Thanks<=
o:p>


Regards=
,


--Bruno=



&n=
bsp;








From: Idr [mailto:idr-bounces@ietf.org]
On Behalf Of Susan Hares

Sent: Tuesday, March 07, 2017 4:27 AM

To: idr@ietf.org

Cc: 'Hannes Gredler'

Subject: [Idr] 2 Week WG LC for draft-ietf-idr-bgp-prefix-sid-04.txt=
 - 3/6 to 3/20/2017






 


This message begins a 2 week WG=
 LC for draft-ietf-idr-bgp-prefix-sid-04.txt (3/6 to 3/20).   


 


This draft proposed a new optio=
nal, transitive BGP path  attribute, the BGP Prefix Segment attribute =
to carry BGP Prefix Segment Identifier (BGP Prefix SID) information for: &n=
bsp; Label-Index, IPv6 SID, and Originator SRGB.
  This draft is linked to work on DC segment routing describe draft-ie=
tf-spring-segment-routing-msdc-03.txt.



 


We have one remaining author (A=
rjun Sreekantiah) has not responded to the IPR call, but it is likely he wi=
ll respond shortly.  If Arun does not respond to the IPR call during t=
he first week, this WG LC will be extended
 for 1 additional week.  


 


Three implementations exist and=
 the details are on the web site, and in the draft:



https://tr=
ac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-prefix-sid%20implementations


 


 


Sue Hares 




______________________________________________________________________=
___________________________________________________

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_53C29892C857584299CBF5D05346208A1ED9982COPEXCLILM21corp_-- From nobody Wed Mar 8 08:57:26 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4569F12946A; Wed, 8 Mar 2017 08:57:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R44Byi2mg__8; Wed, 8 Mar 2017 08:57:19 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 CF38B1295CA; Wed, 8 Mar 2017 08:57:18 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.90.29; From: "Susan Hares" To: References: <00c501d296f2$a7a0c8f0$f6e25ad0$@ndzh.com> <6339_1488991883_58C0368B_6339_12244_1_53C29892C857584299CBF5D05346208A1ED9982C@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: <6339_1488991883_58C0368B_6339_12244_1_53C29892C857584299CBF5D05346208A1ED9982C@OPEXCLILM21.corporate.adroot.infra.ftgroup> Date: Wed, 8 Mar 2017 11:52:14 -0500 Message-ID: <01a301d2982c$571bd330$05537990$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01A4_01D29802.6E48B160" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIZ1dTmxsGJmEzqH1hB3ufWIyDUXAI/EttyoOq0XGA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: idr@ietf.org, spring@ietf.org, 'Hannes Gredler' Subject: Re: [Idr] 2 Week WG LC for draft-ietf-idr-bgp-prefix-sid-04.txt - 3/6 to 3/20/2017 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 16:57:21 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01A4_01D29802.6E48B160 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Bruno:=20 =20 Thank you for cross-posing this to the spring WG.=20 =20 Sue=20 =20 From: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com]=20 Sent: Wednesday, March 8, 2017 11:51 AM To: Susan Hares Cc: 'Hannes Gredler'; spring@ietf.org; idr@ietf.org Subject: RE: [Idr] 2 Week WG LC for draft-ietf-idr-bgp-prefix-sid-04.txt = - 3/6 to 3/20/2017 =20 Cross-posting to SPRING WG as this document is highly related to draft-ietf-spring-segment-routing-msdc which is under WG Last Call in = the SPRING WG. =20 I=92ve read the document and have the following comments. =20 ----- =A72 =91A BGP-Prefix-SID is always global within the SR/BGP domain=92 =20 Do you imply that this extension may only be used within one SR/BGP = domain? IOW all involved ASes must coordinate their BGP SID allocation? =20 This would fit the MSDC use case discussed in draft-ietf-spring-segment-routing-msdc, but may be a restriction for = other uses cases (e.g. Inter AS VPN option C requiring an inter-AS MPLS LSP). Could the document clarify/elaborate on this? One option may be for the ASBR to be configured to shit the received = index by an offset (e.g. +1000). (this possibility could be referred to in = section 6.1) -- =A72 =91A BGP-Prefix-SID is always global within the SR/BGP domain=92 =20 On a side note, - on the BGP side, IMHO, a BGP domain probably means an AS (looking back = up to RFC 1771 I=92m not seeing the definition of a BGP domain) - on the SR side, I think you mean that all ASes in the DC are in the = same SR domain =20 Hence SR domain does not equal a BGP domain. ----- =20 =A72: =93the newly proposed BGP Prefix-SID attribute can be attached to = prefixes from AFI/SAFI: =BB =A73: =93The BGP-Prefix-SID attached to a BGP prefix P=93=20 =A73.1: =93this TLV can be used to advertise the label index of a given = prefix=94 =20 =20 IINM, BGP Attributes are not attached to (IP) prefixes but shared by all prefixes of a given BGP UPDATE. In addition to the terminology point, this has consequences as: - [RFC3107] and [RFC4760] allow the advertisement of multiple IP = prefixes per BGP UPDATE - draft-ietf-idr-bgp-prefix-sid would add the new requirement that each = IP prefix be advertised in a dedicated BGP UPDATE. (unless multiple = Label-Index TLB must be advertised) =20 If this extension requires the use of one BGP update message per IP = prefix, I think this point should be highlighted and discussed in both draft-ietf-idr-bgp-prefix-sid and draft-ietf-spring-segment-routing-msdc =20 --- =A72 =93the newly proposed BGP Prefix-SID attribute can be attached to = prefixes from AFI/SAFI: Multiprotocol BGP labeled IPv4/IPv6 Unicast ([ RFC3107]). Multiprotocol BGP ([ = RFC4760]) unlabeled IPv6 Unicast.=94 =20 If this attribute is found on routes of different AFI/SAFI, how is this handled? Is this considered an error (hence attribute is discarded as = per =A77) If so, this does not seem to work in Carrier=92s carrier VPN case (where = the CE use AFI/SAFI 1/4 routes, may attach the Prefix-SID attribute; then = the PE will transform this route into a AFI/SAFI 1/128 with the same Prefix-SID attribute attached). If not, it must be clear that the BGP-Prefix-SID Index must not be used = on the VPN route. =20 Can this also be clarified in section 7 (error handling)? =20 --- =A74 =93 The BGP Prefix SID attribute is an optional, transitive BGP path attribute. =BB =20 Hence this attribute may spread very far, e.g. received over Internet routes.=20 IPv6 Internet routes may be converted in AFI/SAFI 2/4 routes (labeled = IPv6), in particular for AS running 6PE (RFC 4798). Hence this AS would = interpret the Prefix SID and the received index would likely (or even = deliberately) collision with Index provisioned by this AS. I think the use of a transitive attribute is debatable given that this attribute is not required for the service/network to work. i.e. it=92s = only =93nice to have=94 in order for each node to use the same label (and = assuming they can be configured with the same SRGB). So the document is trading security risk for a nice to have feature. =20 --- =A75.1 =93 A BGP Prefix-SID attribute is called "unacceptable" for a speaker = M if the derived label value L lies outside the SRGB configured on M. Otherwise the Label Index attribute is called "acceptable" to speaker = M. =BB =20 The case where two different IP Prefixes are received with the same = Index (but with different labels) does not seem to be correctly handled. As = per current text, both Prefix would incorrectly be merged into the same FEC (incoming label). Also, the index in the BGP Prefix-SID may collision with the same index, received from a different protocol (e.g. IS-IS) with a different prefix. = How is this handled? This seems specifically an issue when combined with the previous point (comment). --- =A75.2 (IPv6 SID) =20 =93 * S flag: if set then it means that the BGP speaker attaching = the Prefix-SID Attribute to a prefix is capable of processing the IPv6 Segment Routing Header (SRH, [ I-D.ietf-6man-segment-routing-header]) for = the segment corresponding to the originated IPv6 prefix=94 =20 A similar text has just been removed in the latest version of the SR = ISIS extension published yesterday (draft-ietf-isis-segment-routing-extensions-11). (cf =93H-Flag=94). Hence, are you sure that this SRv6 specific part is still applicable/up = to date? =20 =20 --- =939. Security Considerations =20 This document introduces no new security considerations above and = beyond those already specified in [RFC4271] and [RFC3107].=94 =20 Some of the comments above may probably have security considerations. =20 --- Nits: =A74.1 OLD: None are defined at this stage of the document. NEW: None are defined by this document. -- =A72 OLD: the newly proposed BGP Prefix-SID attribute NEW: the BGP Prefix-SID attribute defined in this document -- =9311. Change Log =20 Initial Version: Sep 21 2014=94 =20 This section does not seem that useful and could either be removed or completed with the change log of all versions. -- Name of the attribute is not consistently spelled (e.g. BGP-Prefix-SID, = BGP Prefix SID, BGP Prefix-SID)=20 =20 Thanks Regards, --Bruno =20 From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Tuesday, March 07, 2017 4:27 AM To: idr@ietf.org Cc: 'Hannes Gredler' Subject: [Idr] 2 Week WG LC for draft-ietf-idr-bgp-prefix-sid-04.txt - = 3/6 to 3/20/2017 =20 This message begins a 2 week WG LC for = draft-ietf-idr-bgp-prefix-sid-04.txt (3/6 to 3/20). =20 =20 This draft proposed a new optional, transitive BGP path attribute, the = BGP Prefix Segment attribute to carry BGP Prefix Segment Identifier (BGP = Prefix SID) information for: Label-Index, IPv6 SID, and Originator SRGB. = This draft is linked to work on DC segment routing describe draft-ietf-spring-segment-routing-msdc-03.txt.=20 =20 We have one remaining author (Arjun Sreekantiah) has not responded to = the IPR call, but it is likely he will respond shortly. If Arun does not respond to the IPR call during the first week, this WG LC will be = extended for 1 additional week. =20 =20 Three implementations exist and the details are on the web site, and in = the draft:=20 https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-prefix-sid%20imple= men tations =20 =20 Sue Hares=20 _________________________________________________________________________= ___ _____________________________________________ =20 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. =20 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. ------=_NextPart_000_01A4_01D29802.6E48B160 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Bruno:

 

Thank you for = cross-posing this to the spring WG.

 

Sue =

 

From:= = bruno.decraene@orange.com [mailto:bruno.decraene@orange.com] =
Sent: Wednesday, March 8, 2017 11:51 AM
To: Susan = Hares
Cc: 'Hannes Gredler'; spring@ietf.org; = idr@ietf.org
Subject: RE: [Idr] 2 Week WG LC for = draft-ietf-idr-bgp-prefix-sid-04.txt - 3/6 to = 3/20/2017

 

Cross-posting to SPRING WG as this document is = highly related to draft-ietf-spring-segment-routing-msdc which is under = WG Last Call in the SPRING WG.

 

I’ve read the = document and have the following comments.

 

-----

=A72

‘A BGP-Prefix-SID is always global within the SR/BGP = domain’

 

Do you imply that this = extension may only be used within one SR/BGP = domain?

IOW all involved ASes must coordinate their BGP = SID allocation?

 

This would fit the MSDC = use case discussed in draft-ietf-spring-segment-routing-msdc, but may be = a restriction for other uses cases (e.g. Inter AS VPN option C requiring = an inter-AS MPLS LSP).

Could the document clarify/elaborate on = this?

One option may be for the ASBR to be configured = to shit the received index by an offset (e.g. +1000). (this possibility = could be referred to in section 6.1)

--

=A72

‘A BGP-Prefix-SID is always global within the SR/BGP = domain’

 

On a side = note,

- on the BGP side, IMHO, a BGP domain probably = means an AS (looking back up to RFC 1771 I’m not seeing the = definition of a BGP domain)

- on the SR side, I = think you mean that all ASes in the DC are in the same SR = domain

 

Hence SR domain does not = equal a BGP domain.

-----

 

=A72: “the = newly proposed BGP Prefix-SID attribute can be attached to prefixes from = AFI/SAFI: =BB

=A73: “The BGP-Prefix-SID attached to a BGP prefix =
P“ 
=A73.1: “this TLV can be used to =
advertise the label index of a given =
prefix”
 

 

IINM, BGP Attributes are = not attached to (IP) prefixes but shared by all prefixes of a given BGP = UPDATE.

In addition to the terminology point, this has = consequences as:

- [RFC3107] and [RFC4760] allow the = advertisement of multiple IP prefixes per BGP = UPDATE

- draft-ietf-idr-bgp-prefix-sid would add the = new requirement that each IP prefix be advertised in a dedicated BGP = UPDATE. (unless multiple Label-Index TLB must be = advertised)

 

If this extension = requires the use of one BGP update message per IP prefix, I think this = point should be highlighted and discussed in both = draft-ietf-idr-bgp-prefix-sid and = draft-ietf-spring-segment-routing-msdc

 

---

=A72

“the newly proposed BGP Prefix-SID attribute can be attached = to prefixes from AFI/SAFI:

      Multiprotocol BGP labeled IPv4/IPv6 = Unicast ([RFC3107]).

      Multiprotocol BGP ([RFC4760]) unlabeled IPv6 = Unicast.”

 

If this attribute is found on routes of = different AFI/SAFI, how is this handled? Is this considered an error = (hence attribute is discarded as per =A77)

If so, this does not = seem to work in Carrier’s carrier VPN case (where the CE use = AFI/SAFI 1/4 routes, may attach the Prefix-SID attribute; then the PE = will transform this route into a AFI/SAFI 1/128 with the same Prefix-SID = attribute attached).

If not, it must be clear that the BGP-Prefix-SID = Index must not be used on the VPN route.

 

Can this also be = clarified in section 7 (error handling)?

 

---

=A74
“ =
The BGP Prefix SID attribute is an optional, transitive BGP path =
attribute. =BB
 
Hence this =
attribute may spread very far, e.g. received over Internet routes. =

IPv6 Internet =
routes may be converted in AFI/SAFI 2/4 routes (labeled IPv6), in =
particular for AS running 6PE (RFC 4798). Hence this AS would interpret =
the Prefix SID and the received index would likely (or even =
deliberately) collision with Index provisioned by this =
AS.
I think the =
use of a transitive attribute is debatable given that this attribute is =
not required for the service/network to work. i.e. it’s only =
“nice to have” in order for each node to use the same label =
(and assuming they can be configured with the same SRGB). So the =
document is trading security risk for a nice to have =
feature.
 
---=

=A75.1
“   A BGP Prefix-SID attribute is =
called "unacceptable" for a speaker =
M
   if the derived label value L lies =
outside the SRGB configured on M.
   =
Otherwise the Label Index attribute is called "acceptable" to =
speaker  M. =BB

 

The case where two = different IP Prefixes are received with the same Index (but with = different labels) does not seem to be correctly handled. As per current = text, both Prefix would incorrectly be merged into the same FEC = (incoming label).

Also, the index in the BGP Prefix-SID may = collision with the same index, received from a different protocol (e.g. = IS-IS) with a different prefix. How is this = handled?

This seems specifically an issue when combined = with the previous point (comment).

---

=A75.2 (IPv6 = SID)

 

“ &nb=
sp;    *  S flag: if set then it means that the BGP =
speaker attaching =
the
        =
 Prefix-SID Attribute to a prefix is capable of processing =
the
        =
 IPv6 Segment Routing Header =
(SRH,
       &nbs=
p; [I-D.ietf-6man-segment-routing-header]) =
for the =
segment
       &n=
bsp; corresponding to the originated IPv6 =
prefix”

 

A similar text has just = been removed in the latest version of the SR ISIS extension published = yesterday (draft-ietf-isis-segment-routing-extensions-11). (cf = “H-Flag”).

Hence, are you sure that this SRv6 specific part = is still applicable/up to date?

 

 

---

“9.  Security = Considerations

 

   This = document introduces no new security considerations above and beyond = those already specified in [RFC4271] and = [RFC3107].”

 

Some of the comments = above may probably have security considerations.

 

---

Nits:

=A74.1

OLD: =
None are defined at this stage of the =
document.
NEW: =
None are defined by this document.

--

=A72

OLD: =
the newly proposed BGP Prefix-SID =
attribute
NEW: =
the BGP Prefix-SID attribute defined in this =
document
--
“11.  =
Change Log
 
   =
Initial Version:  Sep 21 =
2014”
 
This section =
does not seem that useful and could either be removed or completed with =
the change log of all =
versions.
--

Name of the attribute is = not consistently spelled (e.g. BGP-Prefix-SID, BGP Prefix SID, BGP = Prefix-SID)

 

Thanks

Regards,

--Bruno

 

From:= = Idr [mailto:idr-bounces@ietf.org] = On Behalf Of Susan Hares
Sent: Tuesday, = March 07, 2017 4:27 AM
To: idr@ietf.org
Cc: 'Hannes = Gredler'
Subject: [Idr] 2 Week WG LC for = draft-ietf-idr-bgp-prefix-sid-04.txt - 3/6 to = 3/20/2017

 

This message = begins a 2 week WG LC for draft-ietf-idr-bgp-prefix-sid-04.txt (3/6 to = 3/20).   

 

This draft = proposed a new optional, transitive BGP path  attribute, the BGP = Prefix Segment attribute to carry BGP Prefix Segment Identifier (BGP = Prefix SID) information for:   Label-Index, IPv6 SID, and = Originator SRGB.  This draft is linked to work on DC segment = routing describe draft-ietf-spring-segment-routing-msdc-03.txt. =

 

We have one remaining author (Arjun Sreekantiah) has = not responded to the IPR call, but it is likely he will respond = shortly.  If Arun does not respond to the IPR call during the first = week, this WG LC will be extended for 1 additional week.  =

 

Three implementations exist and the details are on the = web site, and in the draft:

https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bg= p-prefix-sid%20implementations

 

 

Sue Hares = 

_______________________________________________________________=
__________________________________________________________
 
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.
------=_NextPart_000_01A4_01D29802.6E48B160-- From nobody Wed Mar 8 12:04:27 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C0831295A1; Wed, 8 Mar 2017 12:04:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NASn3nu2cVxf; Wed, 8 Mar 2017 12:04:23 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4560B127A91; Wed, 8 Mar 2017 12:04:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6168; q=dns/txt; s=iport; t=1489003463; x=1490213063; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Ea5fDp+gt53hiGW2qRUvbnI79N98hfCA6EiIi7Rzw8c=; b=GFejNlwgXnbmtz15HniXQce+x0EnD3fMlzpt5PI6LsN1N6sz3Cv1kLAM tAEwrww+Q9Fb9nbsW5FXE722TIFARBykoS0PEPILI38C42REi1oKvDlxA Wf4l+u4nDMNfz76Spaug12XQbx0lFoH/ERZdzL5++lkP4NfkHbvdmXaTN o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B3AQCUYsBY/5JdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1FhgQoHg1mKDJFNiA2NK4INHwuFeAIagic/GAECAQEBAQEBAWs?= =?us-ascii?q?ohRUBAQEBAwEBIRE6CwwEAgEIEQQBAQECAiMDAgICHwYLFAEICAIEAQ0FCIlfA?= =?us-ascii?q?xUOsEKCJoc2DYM4AQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBC4VDg2aBCYJRhQm?= =?us-ascii?q?CXwWbfDoBjgyEIoIEhSOISIE6iESCEIhpAR84gQNWFT86hBcggWIBdYkGAYEMA?= =?us-ascii?q?QEB?= X-IronPort-AV: E=Sophos;i="5.36,265,1486425600"; d="scan'208";a="216065546" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Mar 2017 20:04:22 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v28K4MK5013052 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 8 Mar 2017 20:04:22 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 8 Mar 2017 14:04:21 -0600 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Wed, 8 Mar 2017 14:04:21 -0600 From: "Jakob Heitz (jheitz)" To: "Borchert, Oliver (Fed)" , "Enke Chen (enkechen)" Thread-Topic: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20 Thread-Index: AQHSjglrFbHoeYS2WUyxb/MV1DegzqF/VY+AgAlhrgCAAEiTgIAAnkCAgAA/eoCAABXogIAAAp8AgAACk4CAAAAMgIAANcUAgABTfYCAAAFtgIAAGbEAgADUQkA= Date: Wed, 8 Mar 2017 20:04:21 +0000 Message-ID: References: <20170228210627.GB17448@pfrc.org> <3eb4d853-1d44-6250-c70a-26f60eac39e6@cisco.com> <006e01d296db$a7c4c320$f74e4960$@ndzh.com> <010101d2974a$8520d060$8f627120$@ndzh.com> <018c01d29756$c8b4f610$5a1ee230$@ndzh.com> <01b301d29758$180458e0$480d0aa0$@ndzh.com> <7657b686-0685-9bdf-17ba-e7d618a237aa@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [128.107.151.82] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: 'idr wg' , "draft-ietf-idr-bgp-extended-messages@ietf.org" , Susan Hares , 'Robert Raszuk' , "idr-chairs@ietf.org" Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 20:04:25 -0000 SSBkb24ndCB0aGluayBpdCBtYWtlcyBzZW5zZSB0byBmYWxsYmFjayBpZiBhIGxvbmcgT1BFTiBt ZXNzYWdlIGZhaWxzLg0KU3VwcG9zZSB0aGUgT1BFTiBtZXNzYWdlIGlzIDQxMDAgYnl0ZXMgbG9u ZyBhbmQgaXQgZmFpbHMuDQpIb3cgd2lsbCB5b3Ugc2hyaW5rIGl0Pw0KVGhlIG9wZXJhdG9yIHdp bGwgbmVlZCB0byByZW1vdmUgc29tZSBmZWF0dXJlcyBmcm9tIHRoZSBjb25maWd1cmF0aW9uIGJl Zm9yZSB0cnlpbmcgYWdhaW4uDQoNClRoYW5rcywNCkpha29iLg0KDQo+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+IEZyb206IElkciBbbWFpbHRvOmlkci1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgQm9yY2hlcnQsIE9saXZlciAoRmVkKQ0KPiBTZW50OiBUdWVzZGF5LCBNYXJj aCAwNywgMjAxNyA1OjIxIFBNDQo+IFRvOiBFbmtlIENoZW4gKGVua2VjaGVuKSA8ZW5rZWNoZW5A Y2lzY28uY29tPg0KPiBDYzogJ2lkciB3ZycgPGlkckBpZXRmLm9yZz47IGRyYWZ0LWlldGYtaWRy LWJncC1leHRlbmRlZC1tZXNzYWdlc0BpZXRmLm9yZzsgJ1JvYmVydCBSYXN6dWsnIDxyb2JlcnRA cmFzenVrLm5ldD47DQo+IFN1c2FuIEhhcmVzIDxzaGFyZXNAbmR6aC5jb20+OyBpZHItY2hhaXJz QGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbSWRyXSBBRCBSZXZpZXcgb2YgZHJhZnQtaWV0Zi1p ZHItYmdwLWV4dGVuZGVkLW1lc3NhZ2VzLTIwDQo+IA0KPiBFbmtlLA0KPiANCj4gdGhhbmtzIGZv ciB0aGUgcG9pbnRlci4gV2l0aCB0aGlzIGluIG1pbmQsIGl0IG1ha2VzIHBlcmZlY3RseSBzZW5z ZSB0aGVuIHRvIGhhdmUgYWxsIGJncCBtZXNzYWdlcyBpbmNsdWRlZCByYXRoZXINCj4gdGhhbiDi gJxjaGVycnkgcGlja2luZ+KAnSBzb21lIG9mIHRoZW0uDQo+IA0KPiBPbGl2ZXINCj4gDQo+IE9u IDMvNy8xNywgNjo0OSBQTSwgIkVua2UgQ2hlbiIgPGVua2VjaGVuQGNpc2NvLmNvbT4gd3JvdGU6 DQo+IA0KPiAgICAgUGxlYXNlIGNoZWNrIG91dCB0aGUgZm9sbG93aW5nIGRvY3VtZW50Og0KPiAN Cj4gICAgIEV4dGVuZGVkIE9wdGlvbmFsIFBhcmFtZXRlcnMgTGVuZ3RoIGZvciBCR1AgT1BFTiBN ZXNzYWdlDQo+ICAgICBkcmFmdC1pZXRmLWlkci1leHQtb3B0LXBhcmFtLTAyDQo+IA0KPiAgICAg LS0gRW5rZQ0KPiANCj4gICAgIE9uIDMvNy8xNyAzOjQ0IFBNLCBCb3JjaGVydCwgT2xpdmVyIChG ZWQpIHdyb3RlOg0KPiAgICAgPiBJIGFtIHdvbmRlcmluZyDigJMgYWNjb3JkaW5nIHRvIFJGQyA0 MjcxLCBob3cgY2FuIGFuIE9QRU4gbWVzc2FnZSBldmVyIGV4Y2VlZCAyODQgYnl0ZXM/DQo+ICAg ICA+IFRoZSBiZ3AgbWVzc2FnZSBoZWFkZXIgaGFzIDE5IGJ5dGVzIGFuZCB0aGUgT1BFTiBtZXNz YWdlIHBheWxvYWQgYWRkcyAxMC4gVGhpcyBpcyAyOSwgdGhlbiB0aGUgb25seQ0KPiAgICAgPiBh ZGRpdGlvbiBoZXJlIGFyZSB0aGUgT3B0aW9uYWwgUGFyYW1ldGVycyB3aGljaCBjYW5ub3QgZXhj ZWVkIDI1NSBieXRlcyBjb21iaW5lZCBkdWUgdG8gdGhlIDEgYnl0ZSBsZW5ndGgNCj4gZmllbGQu DQo+ICAgICA+DQo+ICAgICA+IFRoZXJlZm9yZSwgYW4gb3BlbiBtZXNzYWdlIGNhbm5vdCBleGNl ZWQgMjg0IGJ5dGVzIGFuZCBpZiBsYXJnZXIgdGhhbiAyODQgYnl0ZXMsIHdvdWxkbuKAmXQgaXQg YmUgaW52YWxpZC4NCj4gICAgID4NCj4gICAgID4gSW4gdGhpcyByZWdhcmQsIEkgZG9u4oCZdCBy ZWFsbHkgdW5kZXJzdGFuZCB0aGUgd2hvbGUgZGlzY3Vzc2lvbiBhYm91dCBhbGxvd2luZyBhbiBP UEVOIG1lc3NhZ2UgbGFyZ2VyIHRoYW4gNEsuDQo+ICAgICA+IEl0IHNob3VsZG7igJl0IGV2ZW4g YmUgbGFyZ2VyIHRoYW4gMjg0IGJ5dGVzPyAgTWF5YmUgSSBhbSBtaXNzaW5nIHNvbWV0aGluZy4N Cj4gICAgID4NCj4gICAgID4gQlRXLCBzYW1lIGlzIHRydWUgZm9yIEtFRVBBTElWRSAobWF4IDE5 IGJ5dGVzKQ0KPiAgICAgPg0KPiAgICAgPiBPbGl2ZXINCj4gICAgID4NCj4gICAgID4NCj4gICAg ID4NCj4gICAgID4gT24gMy83LzE3LCAxOjQ1IFBNLCAiSWRyIG9uIGJlaGFsZiBvZiBFbmtlIENo ZW4iIDxpZHItYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgZW5rZWNoZW5AY2lzY28uY29t PiB3cm90ZToNCj4gICAgID4NCj4gICAgID4gICAgIEhpLCBGb2xrczoNCj4gICAgID4NCj4gICAg ID4gICAgIG8gVGhlcmUgaXMgbm8gZXh0cmEgd29yayBmb3IgYSByZWNlaXZlciB0byBjb3ZlciBt ZXNzYWdlIHR5cGVzIG90aGVyIHRoYW4gVVBEQVRFLg0KPiAgICAgPiAgICAgbyBUaGVyZSBpcyBh IGxpdHRsZSBiaXQgd29yayBmb3IgYSBzZW5kZXIgdGhhdCB3aXNoZXMgdG8gc2VuZCBhIGxhcmdl IE9QRU4gKGUuZy4sDQo+ICAgICA+ICAgICAgIHVzaW5nIHRoZSBwcmlvciBjYXBhYmlsaXR5IGFu ZCBwb3NzaWJseSBzdWJzZXF1ZW50IE5PVElGSUNBVElPTikuDQo+ICAgICA+DQo+ICAgICA+ICAg ICBBZGRpdGlvbmFsbHksIEkgZG8gbm90IHNlZSBhIG5lZWQgdG8gdG91Y2ggb24gdGhlIEZTTSBz cGVjaWZpZWQgaW4gUkZDIDQyNzEgZXZlbg0KPiAgICAgPiAgICAgaW4gdGhlIGNhc2Ugb2Ygc2Vu ZGluZyBhIGxhcmdlIE9QRU4sIHdoaWNoIHBvdGVudGlhbGx5IG1heSBpbnZvbHZlIHR3byBzZXBh cmF0ZQ0KPiAgICAgPiAgICAgY29uc2VjdXRpdmUgc2Vzc2lvbnMgYnV0IGVhY2ggc2Vzc2lvbiB3 b3VsZCBqdXN0IGZvbGxvdyB0aGUgZXhpc3RpbmcgRlNNLg0KPiAgICAgPg0KPiAgICAgPiAgICAg VGhhbmtzLiAgIC0tIEVua2UNCj4gICAgID4NCj4gICAgID4gICAgIE9uIDMvNy8xNyA3OjMyIEFN LCBTdXNhbiBIYXJlcyB3cm90ZToNCj4gICAgID4gICAgID4gUm9iZXJ0Og0KPiAgICAgPiAgICAg Pg0KPiAgICAgPiAgICAgPiA8aW5kaXZpZHVhbCBjb250cmlidXRvcuKAmXMgaGF0IG9uPg0KPiAg ICAgPiAgICAgPg0KPiAgICAgPiAgICAgPiBZZXAgIC0gRWFzaWVyIHRvIGp1c3QgaW5jbHVkZSBh bGwgbWVzc2FnZXMuDQo+ICAgICA+ICAgICA+DQo+ICAgICA+ICAgICA+DQo+ICAgICA+ICAgICA+ DQo+ICAgICA+ICAgICA+IFN1ZQ0KPiAgICAgPiAgICAgPg0KPiAgICAgPiAgICAgPg0KPiAgICAg PiAgICAgPg0KPiAgICAgPiAgICAgPiAqRnJvbToqcnJhc3p1a0BnbWFpbC5jb20gW21haWx0bzpy cmFzenVrQGdtYWlsLmNvbV0gKk9uIEJlaGFsZiBPZiAqUm9iZXJ0IFJhc3p1aw0KPiAgICAgPiAg ICAgPiAqU2VudDoqIFR1ZXNkYXksIE1hcmNoIDcsIDIwMTcgMTA6MzMgQU0NCj4gICAgID4gICAg ID4gKlRvOiogU3VzYW4gSGFyZXMNCj4gICAgID4gICAgID4gKkNjOiogUmFuZHkgQnVzaDsgRW5r ZSBDaGVuOyBKZWZmcmV5IEhhYXM7IEFsdmFybyBSZXRhbmEgKGFyZXRhbmEpOyBpZHItY2hhaXJz QGlldGYub3JnOyBkcmFmdC1pZXRmLWlkci0NCj4gYmdwLWV4dGVuZGVkLW1lc3NhZ2VzQGlldGYu b3JnOyBpZHIgd2cNCj4gICAgID4gICAgID4gKlN1YmplY3Q6KiBSZTogW0lkcl0gQUQgUmV2aWV3 IG9mIGRyYWZ0LWlldGYtaWRyLWJncC1leHRlbmRlZC1tZXNzYWdlcy0yMA0KPiAgICAgPiAgICAg Pg0KPiAgICAgPiAgICAgPg0KPiAgICAgPiAgICAgPg0KPiAgICAgPiAgICAgPiBIaSBTdWUsDQo+ ICAgICA+ICAgICA+DQo+ICAgICA+ICAgICA+DQo+ICAgICA+ICAgICA+DQo+ICAgICA+ICAgICA+ PiBNeSBzdWdnZXN0aW9uIGlzIHRvIGluY2x1ZGUgYWxsIG1lc3NhZ2VzIGluY2x1ZGluZyBmdXR1 cmUgbWVzc2FnZXMgaWYgYXBwcm92ZWQuDQo+ICAgICA+ICAgICA+DQo+ICAgICA+ICAgICA+DQo+ ICAgICA+ICAgICA+DQo+ICAgICA+ICAgICA+IEFoaCB0aGVuIGl0IGlzIGdyZWF0IC0gd2UgYXJl IGluIHN5bmMgIQ0KPiAgICAgPiAgICAgPg0KPiAgICAgPiAgICAgPg0KPiAgICAgPiAgICAgPg0K PiAgICAgPiAgICAgPiBNeSBvdGhlciBjb21tZW50cyB3ZXJlIGp1c3QgYW4gb3BpbmlvbiAuLi4g YnV0IGlmIGl0IGlzIGVhc2llciB0byBleHRlbmQgYWxsIG1lc3NhZ2VzIHRoZW4gcGVyZmVjdC4N Cj4gICAgID4gICAgID4NCj4gICAgID4gICAgID4NCj4gICAgID4gICAgID4NCj4gICAgID4gICAg ID4gQ2hlZXJzLA0KPiAgICAgPiAgICAgPg0KPiAgICAgPiAgICAgPiBSLg0KPiAgICAgPiAgICAg Pg0KPiAgICAgPiAgICAgPg0KPiAgICAgPiAgICAgPg0KPiAgICAgPiAgICAgPg0KPiAgICAgPiAg ICAgPg0KPiAgICAgPg0KPiAgICAgPiAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gICAgID4gICAgIElkciBtYWlsaW5nIGxpc3QNCj4gICAgID4g ICAgIElkckBpZXRmLm9yZw0KPiAgICAgPiAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9pZHINCj4gICAgID4NCj4gICAgID4NCj4gDQo+IA0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBJZHIgbWFpbGluZyBsaXN0DQo+ IElkckBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lk cg0K From nobody Wed Mar 8 12:13:42 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDD0F129533; Wed, 8 Mar 2017 12:13:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GKBLJMraTqCm; Wed, 8 Mar 2017 12:13:40 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 346AF12946F; Wed, 8 Mar 2017 12:13:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4980; q=dns/txt; s=iport; t=1489004020; x=1490213620; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=v6hSND2LwfF4ztke028pptv0kMgTRifAttgKBREEErE=; b=HZur8pYdVCL+pATY2Bc5yVCc7XjjjoLLrxu54oBkNHr9Pq5XtG58X13C uU/jnKN9htCwrtocU7tROcxrBhlHp1elNy7aNsJhjXct+9IpMMk44PLSp XyeNze71MhhYfjym87jYdKO3bzKUZAKGsQSWd8luTl0/ihRHI4gV5jM8s I=; X-IronPort-AV: E=Sophos;i="5.36,265,1486425600"; d="scan'208";a="221528929" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Mar 2017 20:13:39 +0000 Received: from [10.41.58.92] ([10.41.58.92]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v28KDcu2017053; Wed, 8 Mar 2017 20:13:38 GMT To: "Jakob Heitz (jheitz)" References: <20170228210627.GB17448@pfrc.org> <3eb4d853-1d44-6250-c70a-26f60eac39e6@cisco.com> <006e01d296db$a7c4c320$f74e4960$@ndzh.com> <010101d2974a$8520d060$8f627120$@ndzh.com> <018c01d29756$c8b4f610$5a1ee230$@ndzh.com> <01b301d29758$180458e0$480d0aa0$@ndzh.com> <7657b686-0685-9bdf-17ba-e7d618a237aa@cisco.com> From: Enke Chen Message-ID: Date: Wed, 8 Mar 2017 12:13:38 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: 'idr wg' , 'Robert Raszuk' , "idr-chairs@ietf.org" , "draft-ietf-idr-bgp-extended-messages@ietf.org" , Susan Hares Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 20:13:42 -0000 If one has to send a large OPEN, then it is rejected by the remote speaker, then the session needs to be held down (or for slow retry) until the remote speaker is upgraded or the OPEN size reduced locally as you are saying. The details need to be specified in a new revision. Thanks. -- Enke On 3/8/17 12:04 PM, Jakob Heitz (jheitz) wrote: > I don't think it makes sense to fallback if a long OPEN message fails. > Suppose the OPEN message is 4100 bytes long and it fails. > How will you shrink it? > The operator will need to remove some features from the configuration before trying again. > > Thanks, > Jakob. > >> -----Original Message----- >> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Borchert, Oliver (Fed) >> Sent: Tuesday, March 07, 2017 5:21 PM >> To: Enke Chen (enkechen) >> Cc: 'idr wg' ; draft-ietf-idr-bgp-extended-messages@ietf.org; 'Robert Raszuk' ; >> Susan Hares ; idr-chairs@ietf.org >> Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20 >> >> Enke, >> >> thanks for the pointer. With this in mind, it makes perfectly sense then to have all bgp messages included rather >> than “cherry picking” some of them. >> >> Oliver >> >> On 3/7/17, 6:49 PM, "Enke Chen" wrote: >> >> Please check out the following document: >> >> Extended Optional Parameters Length for BGP OPEN Message >> draft-ietf-idr-ext-opt-param-02 >> >> -- Enke >> >> On 3/7/17 3:44 PM, Borchert, Oliver (Fed) wrote: >> > I am wondering – according to RFC 4271, how can an OPEN message ever exceed 284 bytes? >> > The bgp message header has 19 bytes and the OPEN message payload adds 10. This is 29, then the only >> > addition here are the Optional Parameters which cannot exceed 255 bytes combined due to the 1 byte length >> field. >> > >> > Therefore, an open message cannot exceed 284 bytes and if larger than 284 bytes, wouldn’t it be invalid. >> > >> > In this regard, I don’t really understand the whole discussion about allowing an OPEN message larger than 4K. >> > It shouldn’t even be larger than 284 bytes? Maybe I am missing something. >> > >> > BTW, same is true for KEEPALIVE (max 19 bytes) >> > >> > Oliver >> > >> > >> > >> > On 3/7/17, 1:45 PM, "Idr on behalf of Enke Chen" wrote: >> > >> > Hi, Folks: >> > >> > o There is no extra work for a receiver to cover message types other than UPDATE. >> > o There is a little bit work for a sender that wishes to send a large OPEN (e.g., >> > using the prior capability and possibly subsequent NOTIFICATION). >> > >> > Additionally, I do not see a need to touch on the FSM specified in RFC 4271 even >> > in the case of sending a large OPEN, which potentially may involve two separate >> > consecutive sessions but each session would just follow the existing FSM. >> > >> > Thanks. -- Enke >> > >> > On 3/7/17 7:32 AM, Susan Hares wrote: >> > > Robert: >> > > >> > > >> > > >> > > Yep - Easier to just include all messages. >> > > >> > > >> > > >> > > Sue >> > > >> > > >> > > >> > > *From:*rraszuk@gmail.com [mailto:rraszuk@gmail.com] *On Behalf Of *Robert Raszuk >> > > *Sent:* Tuesday, March 7, 2017 10:33 AM >> > > *To:* Susan Hares >> > > *Cc:* Randy Bush; Enke Chen; Jeffrey Haas; Alvaro Retana (aretana); idr-chairs@ietf.org; draft-ietf-idr- >> bgp-extended-messages@ietf.org; idr wg >> > > *Subject:* Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20 >> > > >> > > >> > > >> > > Hi Sue, >> > > >> > > >> > > >> > >> My suggestion is to include all messages including future messages if approved. >> > > >> > > >> > > >> > > Ahh then it is great - we are in sync ! >> > > >> > > >> > > >> > > My other comments were just an opinion ... but if it is easier to extend all messages then perfect. >> > > >> > > >> > > >> > > Cheers, >> > > >> > > R. >> > > >> > > >> > > >> > > >> > > >> > >> > _______________________________________________ >> > 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 Mar 8 13:35:06 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF96129573; Wed, 8 Mar 2017 13:35:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6aNrgfNMzzbm; Wed, 8 Mar 2017 13:35:01 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 73B501294D7; Wed, 8 Mar 2017 13:35:01 -0800 (PST) Received: from [172.29.109.148] (unknown [66.129.239.12]) by slice.pfrc.org (Postfix) with ESMTPSA id 83DC81E32D; Wed, 8 Mar 2017 16:41:01 -0500 (EST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: text/plain; charset=us-ascii From: Jeffrey Haas In-Reply-To: Date: Wed, 8 Mar 2017 13:35:01 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170228210627.GB17448@pfrc.org> <3eb4d853-1d44-6250-c70a-26f60eac39e6@cisco.com> <006e01d296db$a7c4c320$f74e4960$@ndzh.com> <010101d2974a$8520d060$8f627120$@ndzh.com> <018c01d29756$c8b4f610$5a1ee230$@ndzh.com> <01b301d29758$180458e0$480d0aa0$@ndzh.com> <7657b686-0685-9bdf-17ba-e7d618a237aa@cisco.com> To: Enke Chen X-Mailer: Apple Mail (2.2104) Archived-At: Cc: idr wg , Robert Raszuk , "idr-chairs@ietf.org" , "draft-ietf-idr-bgp-extended-messages@ietf.org" , Susan Hares Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 21:35:03 -0000 > On Mar 8, 2017, at 12:13 PM, Enke Chen wrote: >=20 > If one has to send a large OPEN, then it is rejected by the remote = speaker,=20 > then the session needs to be held down (or for slow retry) until the = remote > speaker is upgraded or the OPEN size reduced locally as you are = saying. >=20 > The details need to be specified in a new revision. This covers my prior comment: The minute you move to extended BGP Open = size, you change what wiggle room we've left for version negotiation. And perhaps that's fine. I've spent my entire networking life in BGP-4. = A BGP-5 that only has interop with BGP-4 will likely be fine. That said, you need to say this in the specs. -- Jeff From nobody Wed Mar 8 13:36:49 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77C361294D7; Wed, 8 Mar 2017 13:36:48 -0800 (PST) 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, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3GQXAtQjP8Li; Wed, 8 Mar 2017 13:36:47 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 70DBA129462; Wed, 8 Mar 2017 13:36:47 -0800 (PST) Received: from [172.29.109.148] (unknown [66.129.239.12]) by slice.pfrc.org (Postfix) with ESMTPSA id AD4861E32D; Wed, 8 Mar 2017 16:42:47 -0500 (EST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_A6C2B194-3FC1-4C05-8F22-EC58757D883C" From: Jeffrey Haas In-Reply-To: Date: Wed, 8 Mar 2017 13:36:47 -0800 Message-Id: References: <20170228210627.GB17448@pfrc.org> To: "Alvaro Retana (aretana)" X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "idr-chairs@ietf.org" , "draft-ietf-idr-bgp-extended-messages@ietf.org" , Susan Hares , "idr@ietf.org" Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 21:36:48 -0000 --Apple-Mail=_A6C2B194-3FC1-4C05-8F22-EC58757D883C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 7, 2017, at 2:07 PM, Alvaro Retana (aretana) = wrote: >=20 >> I'm not sure such guidance belongs in this document. We already have >> scenarios wherein normal protocol machinery can result in messages = that are >> too large. The expected behavior is "treat as withdraw" to the next >> downstream, similar to the BGP Error handling RFC. >>=20 >> Examples of this include AS_PATH or CLUSTER_LIST attributes needing = to add a >> new entry on a full PDU. >=20 > Ok=E2=80=A6but is that documented anywhere? I may be missing it, but = I couldn=E2=80=99t find anything like that in rfc4271 or rfc7606. At best, this is "reading between the lines". If you can't form a valid PDU to encode in your Adj-rib-out, you = withdraw your entry from the adj-rib-out. This means you send an = explicit withdraw. I think it'd be gross to take this specific document and try to force it = to be a normative clarification to this point. -- Jeff --Apple-Mail=_A6C2B194-3FC1-4C05-8F22-EC58757D883C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Mar 7, 2017, at 2:07 PM, Alvaro Retana (aretana) <aretana@cisco.com> = wrote:

I'm not sure such guidance belongs in this document. =  We already have
scenarios wherein normal protocol = machinery can result in messages that are
too large. =  The expected behavior is "treat as withdraw" to the next
downstream, similar to the BGP Error handling RFC.

Examples of this include AS_PATH or = CLUSTER_LIST attributes needing to add a
new entry on a = full PDU.

Ok=E2=80=A6but is that documented anywhere? =  I may be missing it, but I couldn=E2=80=99t find anything like = that in rfc4271 or rfc7606.

At best, this is "reading between the = lines".

If you = can't form a valid PDU to encode in your Adj-rib-out, you withdraw your = entry from the adj-rib-out.  This means you send an explicit = withdraw.

I = think it'd be gross to take this specific document and try to force it = to be a normative clarification to this point.



-- Jeff

= --Apple-Mail=_A6C2B194-3FC1-4C05-8F22-EC58757D883C-- From nobody Wed Mar 8 17:24:05 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 507B61294EB; Wed, 8 Mar 2017 17:24:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XkL2kEJpXkMy; Wed, 8 Mar 2017 17:24:03 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 BE7DE1294CE; Wed, 8 Mar 2017 17:24:02 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=70.194.24.193; From: "Susan Hares" To: "'Enke Chen'" , "'Jakob Heitz \(jheitz\)'" References: <20170228210627.GB17448@pfrc.org> <3eb4d853-1d44-6250-c70a-26f60eac39e6@cisco.com> <006e01d296db$a7c4c320$f74e4960$@ndzh.com> <010101d2974a$8520d060$8f627120$@ndzh.com> <018c01d29756$c8b4f610$5a1ee230$@ndzh.com> <01b301d29758$180458e0$480d0aa0$@ndzh.com> <7657b686-0685-9bdf-17ba-e7d618a237aa@cisco.com> In-Reply-To: Date: Wed, 8 Mar 2017 20:19:21 -0500 Message-ID: <003e01d29873$31b2d430$95187c90$@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: AQInnAj+Yxa8tap/yfCJFXAjQYwk1wJi0XFfAwzFclUBlnEaYAHWMN+rAr58MhwCyGvcFQMczvZ5Ak2aXIwCIxMNygKhSz2mAkKflqECNogRigHZPoiMAtOA/wsCBpBH+p/Druyw Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'idr wg' , draft-ietf-idr-bgp-extended-messages@ietf.org, 'Robert Raszuk' , idr-chairs@ietf.org Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 01:24:05 -0000 Enke and Jakob:=20 I am not commenting on the operational desires or your implementations = in this message, only to clarify that the "slow retry" is not an = absolute in the state machine. There is also no logical difference in = the current statement machine between BGP header error (Event 21) or an = OPEN message header error (Event 22) in the FSM.=20 So, if you are talking code and the RFC4271 specification in your = messages - I do not understand your comments. RFC4271 consider the = issues you are indicating and put in optional switches to control = behaviors. There are knobs to have no peer damping, little peer damping = or lots of peer damping. It is also possible to have logic in = implementations which sets these options based on a previous response.=20 If you are speaking about your implementations, you know best.=20 Sue=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D If the OPEN exceeds the maximum size, it is a header size error (Event = 21, p 49, RFC4271 ) in the state machine. If the logical flag = SendNOTIFICATIONwithoutOPEN (p. 37, RFC4271), then the state machine = will respond to an open with a Notification with the header error = message.=20 Two possible sequences in the FSM if the logical = SENDNOTIFICATIONwithoutOpen is sent=20 Sequence 1 - Peer with Extended BGP message establishes first=20 TCP connection establish ------ Send Open --->=20 [open sent state]=20 (5000) <----- NOTIFICATION (header error)=20 Performs peer damping (if this option is set)=20 Peer 2 goes to idle and restarts=20 [p. 57, RFC4271]=20 Reception of NOTIFICATON Clears all BGP resources=20 Goes to IDLE. Manual/automatic start can restart session=20 If you configure peer damping, then you have a delay.=20 If you configure "no peer damping" and "automatic start" And the implementation logic knows to switch back to 4096, =20 This sequence does not have to delay the peer.=20 If you configure peer damping, then it does damp. If not, you can sequence through this quickly. =20 =20 Sequence 2 - Peer with Normal BGP sends first open=20 TCP connection=20 <--------- (open) (less than or equal to 4096)=20 No extended message capability=20 Open ---->=20 Extended peer should not send a OPEN with more than 4096.=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D You could specify in a specification these optional settings + peer = logic without changing RFC4271 FSM.=20 You just would specify some optional settings as mandatory and a logic = around them.=20 I agree with Enke that additional text should be created to define these = for open.=20 If you specify that the Open cannot be greater than 4096, then the logic = changes in the=20 OPEN validation code. And the errors messages is OPEN-MSG-Format error. = You would go through the exact sequence in the FSM (see page 57 of = RFC4271),=20 And the error is not specific to the error length. =20 Sue=20 =20 -----Original Message----- From: Enke Chen [mailto:enkechen@cisco.com]=20 Sent: Wednesday, March 8, 2017 3:14 PM To: Jakob Heitz (jheitz) Cc: Borchert, Oliver (Fed); 'idr wg'; = draft-ietf-idr-bgp-extended-messages@ietf.org; 'Robert Raszuk'; Susan = Hares; idr-chairs@ietf.org; Enke Chen Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20 If one has to send a large OPEN, then it is rejected by the remote = speaker, then the session needs to be held down (or for slow retry) = until the remote speaker is upgraded or the OPEN size reduced locally as = you are saying. The details need to be specified in a new revision. Thanks. -- Enke On 3/8/17 12:04 PM, Jakob Heitz (jheitz) wrote: > I don't think it makes sense to fallback if a long OPEN message fails. > Suppose the OPEN message is 4100 bytes long and it fails. > How will you shrink it? > The operator will need to remove some features from the configuration = before trying again. >=20 > Thanks, > Jakob. >=20 >> -----Original Message----- >> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Borchert, Oliver = >> (Fed) >> Sent: Tuesday, March 07, 2017 5:21 PM >> To: Enke Chen (enkechen) >> Cc: 'idr wg' ;=20 >> draft-ietf-idr-bgp-extended-messages@ietf.org; 'Robert Raszuk'=20 >> ; Susan Hares ;=20 >> idr-chairs@ietf.org >> Subject: Re: [Idr] AD Review of=20 >> draft-ietf-idr-bgp-extended-messages-20 >> >> Enke, >> >> thanks for the pointer. With this in mind, it makes perfectly sense=20 >> then to have all bgp messages included rather than =E2=80=9Ccherry = picking=E2=80=9D some of them. >> >> Oliver >> >> On 3/7/17, 6:49 PM, "Enke Chen" wrote: >> >> Please check out the following document: >> >> Extended Optional Parameters Length for BGP OPEN Message >> draft-ietf-idr-ext-opt-param-02 >> >> -- Enke >> >> On 3/7/17 3:44 PM, Borchert, Oliver (Fed) wrote: >> > I am wondering =E2=80=93 according to RFC 4271, how can an OPEN = message ever exceed 284 bytes? >> > The bgp message header has 19 bytes and the OPEN message = payload adds 10. This is 29, then the only >> > addition here are the Optional Parameters which cannot exceed=20 >> 255 bytes combined due to the 1 byte length field. >> > >> > Therefore, an open message cannot exceed 284 bytes and if = larger than 284 bytes, wouldn=E2=80=99t it be invalid. >> > >> > In this regard, I don=E2=80=99t really understand the whole = discussion about allowing an OPEN message larger than 4K. >> > It shouldn=E2=80=99t even be larger than 284 bytes? Maybe I am = missing something. >> > >> > BTW, same is true for KEEPALIVE (max 19 bytes) >> > >> > Oliver >> > >> > >> > >> > On 3/7/17, 1:45 PM, "Idr on behalf of Enke Chen" = wrote: >> > >> > Hi, Folks: >> > >> > o There is no extra work for a receiver to cover message = types other than UPDATE. >> > o There is a little bit work for a sender that wishes to = send a large OPEN (e.g., >> > using the prior capability and possibly subsequent = NOTIFICATION). >> > >> > Additionally, I do not see a need to touch on the FSM = specified in RFC 4271 even >> > in the case of sending a large OPEN, which potentially may = involve two separate >> > consecutive sessions but each session would just follow the = existing FSM. >> > >> > Thanks. -- Enke >> > >> > On 3/7/17 7:32 AM, Susan Hares wrote: >> > > Robert: >> > > >> > > >> > > >> > > Yep - Easier to just include all messages. >> > > >> > > >> > > >> > > Sue >> > > >> > > >> > > >> > > *From:*rraszuk@gmail.com [mailto:rraszuk@gmail.com] *On = Behalf Of *Robert Raszuk >> > > *Sent:* Tuesday, March 7, 2017 10:33 AM >> > > *To:* Susan Hares >> > > *Cc:* Randy Bush; Enke Chen; Jeffrey Haas; Alvaro Retana = (aretana); idr-chairs@ietf.org; draft-ietf-idr- >> bgp-extended-messages@ietf.org; idr wg >> > > *Subject:* Re: [Idr] AD Review of = draft-ietf-idr-bgp-extended-messages-20 >> > > >> > > >> > > >> > > Hi Sue, >> > > >> > > >> > > >> > >> My suggestion is to include all messages including = future messages if approved. >> > > >> > > >> > > >> > > Ahh then it is great - we are in sync ! >> > > >> > > >> > > >> > > My other comments were just an opinion ... but if it is = easier to extend all messages then perfect. >> > > >> > > >> > > >> > > Cheers, >> > > >> > > R. >> > > >> > > >> > > >> > > >> > > >> > >> > _______________________________________________ >> > 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 Mar 8 17:34:12 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC701295EE; Wed, 8 Mar 2017 17:34:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T0rljMXBPvdy; Wed, 8 Mar 2017 17:34:10 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 35C9E12953D; Wed, 8 Mar 2017 17:34:10 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=70.194.24.193; From: "Susan Hares" To: "'Jeffrey Haas'" , "'Enke Chen'" References: <20170228210627.GB17448@pfrc.org> <3eb4d853-1d44-6250-c70a-26f60eac39e6@cisco.com> <006e01d296db$a7c4c320$f74e4960$@ndzh.com> <010101d2974a$8520d060$8f627120$@ndzh.com> <018c01d29756$c8b4f610$5a1ee230$@ndzh.com> <01b301d29758$180458e0$480d0aa0$@ndzh.com> <7657b686-0685-9bdf-17ba-e7d618a237aa@cisco.com> In-Reply-To: Date: Wed, 8 Mar 2017 20:29:37 -0500 Message-ID: <004001d29874$9ed03840$dc70a8c0$@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: AQInnAj+Yxa8tap/yfCJFXAjQYwk1wJi0XFfAwzFclUBlnEaYAHWMN+rAr58MhwCyGvcFQMczvZ5Ak2aXIwCIxMNygKhSz2mAkKflqECNogRigHZPoiMAtOA/wsCBpBH+gFPsoV1n7k994A= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'idr wg' , draft-ietf-idr-bgp-extended-messages@ietf.org, 'Robert Raszuk' , idr-chairs@ietf.org Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 01:34:11 -0000 Jeff: Caveat - I am not commenting on operational issues. If your brief comment denotes some operational issues, I would appreciate a longer description on-list or off-list. If you are comment on the functionality within the RFC4271 FSM, I am not sure why the "wiggle room is reduced when the open message size is changed"? I have been specific on this list as to the functionality a message header length error enacts (Event 21) versus an Open Message Header enacts (Event 22). Please be as specific in your response if it is a FSM issues. Sue -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jeffrey Haas Sent: Wednesday, March 8, 2017 4:35 PM To: Enke Chen Cc: idr wg; Robert Raszuk; idr-chairs@ietf.org; draft-ietf-idr-bgp-extended-messages@ietf.org; Susan Hares Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20 > On Mar 8, 2017, at 12:13 PM, Enke Chen wrote: > > If one has to send a large OPEN, then it is rejected by the remote > speaker, then the session needs to be held down (or for slow retry) > until the remote speaker is upgraded or the OPEN size reduced locally as you are saying. > > The details need to be specified in a new revision. This covers my prior comment: The minute you move to extended BGP Open size, you change what wiggle room we've left for version negotiation. And perhaps that's fine. I've spent my entire networking life in BGP-4. A BGP-5 that only has interop with BGP-4 will likely be fine. That said, you need to say this in the specs. -- Jeff _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From nobody Thu Mar 9 03:05:46 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB346129468; Thu, 9 Mar 2017 03:05:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0XURhV1E6tOx; Thu, 9 Mar 2017 03:05:43 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD5E7129466; Thu, 9 Mar 2017 03:05:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4356; q=dns/txt; s=iport; t=1489057542; x=1490267142; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=L8aCA7znQk1RMzDmG9JvsVTiWwUrWM5PdiPShYpeswU=; b=L6HnkHY3AJ2TnsB5QyFOfTqT6006yTTRHRF1wDDlK2vXvex/V/2EFGEG PeZC35XeVZ8c5i1sAZunpcp6R6xl5i1PAcgVTg99fuyI6UmWuNEU3q5BD P2TIaEo9WUv5j0hiI0JGm5h6Ng2nAglrfhAfp0/yNz7PLfQm9MVxKyQgP A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ApAQA5NsFY/5hdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1FhgQoHg1mKDJFOlTiCDiqFeAIagjI/GAECAQEBAQEBAWsohRU?= =?us-ascii?q?BAQEBAgEjEUUFCwIBCA4GBAICJgICAjAVEAIEDgWJeAgOsDGCJopvAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBHYELhUOCBYJqhFSDBi6CMQWPWIYihj8BhnWLQoF7U4R?= =?us-ascii?q?QigKTPgEfOIEDVhVQAYRCHYFjdQGJHYENAQEB?= X-IronPort-AV: E=Sophos;i="5.36,268,1486425600"; d="scan'208";a="221201665" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Mar 2017 11:05:41 +0000 Received: from XCH-RTP-008.cisco.com (xch-rtp-008.cisco.com [64.101.220.148]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v29B5fk3001283 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 9 Mar 2017 11:05:41 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-008.cisco.com (64.101.220.148) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 9 Mar 2017 06:05:40 -0500 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1210.000; Thu, 9 Mar 2017 06:05:41 -0500 From: "Stefano Previdi (sprevidi)" To: Christian Hopps Thread-Topic: RtgDir review for draft-ietf-idr-bgp-prefix-sid-04 Thread-Index: AQHSmMUXdFjiFkN2Vkmb2poli49Pkw== Date: Thu, 9 Mar 2017 11:05:41 +0000 Message-ID: References: <87o9xdcgnl.fsf@chopps.org> In-Reply-To: <87o9xdcgnl.fsf@chopps.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.99.22] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "idr@ietf.org" , "draft-ietf-idr-bgp-prefix-sid.all@ietf.org" , Routing ADs Subject: Re: [Idr] RtgDir review for draft-ietf-idr-bgp-prefix-sid-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 11:05:44 -0000 SGkgQ2hyaXMsDQoNCm1hbnkgdGhhbmtzIGZvciB5b3VyIHJldmlldy4NCg0KSSBhcHBsaWVkIGFs bCB5b3VyIGNvbW1lbnRzIGFuZCBzdWdnZXN0aW9ucy4gU2VlIGJlbG93Lg0KDQoNCj4gT24gTWFy IDcsIDIwMTcsIGF0IDM6MjAgUE0sIENocmlzdGlhbiBIb3BwcyA8Y2hvcHBzQGNob3Bwcy5vcmc+ IHdyb3RlOg0KPiANCj4gDQo+IEkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBSb3V0aW5nIERp cmVjdG9yYXRlIHJldmlld2VyIGZvciB0aGlzIGRyYWZ0LiBUaGUNCj4gUm91dGluZyBEaXJlY3Rv cmF0ZSBzZWVrcyB0byByZXZpZXcgYWxsIHJvdXRpbmcgb3Igcm91dGluZy1yZWxhdGVkIGRyYWZ0 cyBhcw0KPiB0aGV5IHBhc3MgdGhyb3VnaCBJRVRGIGxhc3QgY2FsbCBhbmQgSUVTRyByZXZpZXcs IGFuZCBzb21ldGltZXMgb24gc3BlY2lhbA0KPiByZXF1ZXN0LiBUaGUgcHVycG9zZSBvZiB0aGUg cmV2aWV3IGlzIHRvIHByb3ZpZGUgYXNzaXN0YW5jZSB0byB0aGUgUm91dGluZyBBRHMuDQo+IEZv ciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlLCBwbGVhc2Ug c2VlDQo+IOKAi2h0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2FyZWEvcnRnL3RyYWMvd2lraS9S dGdEaXINCj4gDQo+IEFsdGhvdWdoIHRoZXNlIGNvbW1lbnRzIGFyZSBwcmltYXJpbHkgZm9yIHRo ZSB1c2Ugb2YgdGhlIFJvdXRpbmcgQURzLCBpdCB3b3VsZA0KPiBiZSBoZWxwZnVsIGlmIHlvdSBj b3VsZCBjb25zaWRlciB0aGVtIGFsb25nIHdpdGggYW55IG90aGVyIElFVEYgTGFzdCBDYWxsDQo+ IGNvbW1lbnRzIHRoYXQgeW91IHJlY2VpdmUsIGFuZCBzdHJpdmUgdG8gcmVzb2x2ZSB0aGVtIHRo cm91Z2ggZGlzY3Vzc2lvbiBvciBieQ0KPiB1cGRhdGluZyB0aGUgZHJhZnQuDQo+IA0KPiBEb2N1 bWVudDogZHJhZnQtaWV0Zi1pZHItYmdwLXByZWZpeC1zaWQtMDQNCj4gUmV2aWV3ZXI6IENocmlz dGlhbiBIb3Bwcw0KPiBSZXZpZXcgRGF0ZTogMjAxNy0wMy0wNA0KPiBJRVRGIExDIEVuZCBEYXRl OiBVbmtub3duDQo+IEludGVuZGVkIFN0YXR1czogU3RhbmRhcmRzIFRyYWNrDQo+IA0KPiBTdW1t YXJ5Og0KPiA9PT09PT09PQ0KPiANCj4gICAgW3hdIFRoaXMgZG9jdW1lbnQgaXMgYmFzaWNhbGx5 IHJlYWR5IGZvciBwdWJsaWNhdGlvbiwgYnV0IGhhcyBuaXRzIHRoYXQNCj4gICAgc2hvdWxkIGJl IGNvbnNpZGVyZWQgcHJpb3IgdG8gcHVibGljYXRpb24uDQo+IA0KPiBDb21tZW50czoNCj4gPT09 PT09PT09DQo+IA0KPiBEcmFmdCBpcyBxdWl0ZSByZWFkYWJsZS4NCj4gDQo+IE1ham9yIElzc3Vl czoNCj4gPT09PT09PT09PT09PQ0KPiANCj4gTm8gbWFqb3IgaXNzdWVzIGZvdW5kLg0KPiANCj4g TWlub3IgSXNzdWVzOg0KPiA9PT09PT09PT09PT09DQo+IA0KPiBSZWZlcmVuY2VzIG5vcm1hdGl2 ZSB2cyBpbmZvcm1hdGl2ZS4gSSdtIG5vdCBzdXJlIHdoeSBzb21lIG9mIHRoZSBpbmZvcm1hdGl2 ZQ0KPiBhcmVuJ3Qgbm9ybWF0aXZlLiBGb3IgZXhhbXBsZSB0aGUgUy1iaXQgaW5kaWNhdGVzIHRo YXQgdGhlIHJvdXRlciBpcyBjYXBhYmxlIG9mDQo+IHByb2Nlc3NpbmcgdGhlIFNSSCB3aGljaCBp cyBkZWZpbmVkIGJ5IFtJLUQuaWV0Zi02bWFuLXNlZ21lbnQtcm91dGluZy1oZWFkZXJdIHNvDQo+ IHNob3VsZG4ndCB0aGlzIGJlIGEgTm9ybWF0aXZlIHJlZmVyZW5jZT8NCg0KDQphbW9uZyB0aGUg Y29tbWVudHMgSSByZWNlaXZlZCwgaXQgYXBwZWFyZWQgdGhhdCB0aGUgZmxhZyBpbiB0aGUgaXB2 NiBzaWQgdGx2IGlzIG5vdCBuZWVkZWQgc28gSSBjaGFuZ2VkIHRoZSB0bHYgZm9ybWF0IGFuZCBy ZW1vdmVkIHRoZSByZWZlcmVuY2UgKGFsc28sIHRoZSBzcmggZHJhZnQgaXMgc3RpbGwgbm90IGlu IGxhc3QgY2FsbCBzbyBJIGRvbuKAmXQgd2FudCB0byBoYXZlIGFuIGV4dHJhIGRlbGF5IG9uIHRo aXMgb25lKS4NCg0KDQo+IEFkZGl0aW9uYWxseSB0aGUgT3JpZ2luYXRvciBTUkdCIFRMVg0KPiBy ZWZlcmVuY2VzIFtJLUQuaWV0Zi1vc3BmLXNlZ21lbnQtcm91dGluZy1leHRlbnNpb25zXSBmb3Ig dGhlIG1lYW5pbmcgb2YNCj4gbXVsdGlwbGUgcmFuZ2VzIChyZXByZXNlbnRlZCBieSB0aGUgcHJl c2VuY2Ugb2YgbXVsdGlwbGUgVExWcykuDQoNCg0KSSBhbHNvIHJlbW92ZWQgdGhlIHJlZmVyZW5j ZS4NCg0KDQo+IEFkdmlzb3J5IG9ubHk6IFRoZXJlIGFyZSBtYW55IGNhc2VzIG9mIHJlc2VydmVk IGZpZWxkcyBiZWluZyAiU0hPVUxEIGJlIDAgb24NCj4gdHJhbnNtaXQgYW5kIE1VU1QgYmUgaWdu b3JlZCBvbiByZWNlaXZlLiIgSXMgaXQgYmV0dGVyIHRvIHVzZSBNVVNUIGluc3RlYWQgb2YNCj4g U0hPVUxEIGhlcmUgYXMgdGhhdCBhbGxvd3MgZm9yIGJldHRlciBmdXR1cmUtcHJvb2Zpbmc/IFdp dGggIk1VU1QgYmUgMCIgeW91DQo+IGNvdWxkIHRoZW4gY291bnQgb24gdGhlIHZhbHVlcyBiZWlu ZyB6ZXJvIGZvciBkZXZpY2VzIHRoYXQgZG8gbm90IHN1cHBvcnQgYQ0KPiBmdXR1cmUgZXh0ZW5z aW9uIHdoZXJlIHRoZSB2YWx1ZSBpcyBub3QgemVyby4gT2YgY291cnNlIGZ1dHVyZSBleHRlbnNp b25zIGNvdWxkDQo+IGFsd2F5cyB1c2UgYW5vdGhlciBtZXRob2QgdG8gZGV0ZXJtaW5lIGlmIHRo ZSByZXNlcnZlZCBmaWVsZCBob2xkcyBuZXdseSB2YWxpZA0KPiB2YWx1ZXMgc28gdGhpcyBpc24n dCB0aGF0IGJpZyBhIGRlYWwuDQoNCg0KZml4ZWQuDQoNCg0KPiANCj4gTml0czoNCj4gPT09PT0N Cj4gDQo+IEJ5IGZhciB0aGVyZSBhcmUgbW9yZSByZWZlcmVuY2VzIHRvICJub2RlcyIgdGhhbiB0 byAicm91dGVycyIsIGJ1dCBJIHRoaW5rIHRoZXkNCj4gYWxsIHJlZmVyIHRvIHRoZSBzYW1lIHRo aW5nIC0tIG1heWJlIHBpY2sgb25lIG5hbWUuDQo+IA0KPiBTZWN0aW9uIDQgMXN0IHBhcmFncmFw aDogcmVtb3ZlIGZpcnN0IHNlbnRlbmNlIHN0YXJ0aW5nICJUaGUgdmFsdWUgZmllbGQuLi4iDQo+ IA0KPiAybmQgcGFyYWdyYXBoOiBBZGQgIlRoZSIgdG8gIkZvbGxvd2luZyBUTFZzIGFyZSBkZWZp bmVkLiINCj4gDQo+IFNlY3Rpb24gNC4zIDJuZCBwYXJhZ3JhcGggb2YgZGVzY3JpcHRpb24gb2Yg U1JHQiAoMXN0IHBhcmFncmFwaCBvbiBwYWdlLjgpIHVzZXMNCj4gYW4gdW5leHBhbmRlZCBhY3Jv bnltIFNSVEUuDQoNCmFsbCBmaXhlZC4NCg0KVGhhbmtzLg0Kcy4NCg0KDQoNCg== From nobody Thu Mar 9 03:59:26 2017 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A7DC1129564; Thu, 9 Mar 2017 03:59:19 -0800 (PST) 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.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148906075966.5850.5211042768412238817@ietfa.amsl.com> Date: Thu, 09 Mar 2017 03:59:19 -0800 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgpls-segment-routing-epe-10.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 11:59: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 of the IETF. Title : Segment Routing BGP Egress Peer Engineering BGP-LS Extensions Authors : Stefano Previdi Clarence Filsfils Keyur Patel Saikat Ray Jie Dong Mach (Guoyi) Chen Filename : draft-ietf-idr-bgpls-segment-routing-epe-10.txt Pages : 21 Date : 2017-03-09 Abstract: Segment Routing (SR) leverages source routing. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. A segment can represent any instruction, topological or service-based. SR allows to enforce a flow through any topological path and service chain while maintaining per-flow state only at the ingress node of the SR domain. The Segment Routing architecture can be directly applied to the MPLS dataplane with no change on the forwarding plane. It requires minor extension to the existing link-state routing protocols. This document outline a BGP-LS extension for exporting BGP peering node topology information (including its peers, interfaces and peering ASs) in a way that is exploitable in order to compute efficient BGP Peering Engineering policies and strategies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-segment-routing-epe/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-bgpls-segment-routing-epe-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgpls-segment-routing-epe-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 Mar 9 09:03:53 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0A591296BD for ; Thu, 9 Mar 2017 09:03:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eeWqEAX8zo61 for ; Thu, 9 Mar 2017 09:03:50 -0800 (PST) Received: from mail-wr0-f193.google.com (mail-wr0-f193.google.com [209.85.128.193]) (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 31D911296B8 for ; Thu, 9 Mar 2017 09:03:49 -0800 (PST) Received: by mail-wr0-f193.google.com with SMTP id u108so8667147wrb.2 for ; Thu, 09 Mar 2017 09:03:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=3B1VlRaR7QHyRCuUOiOhf1dzqORkH3iIiHIgvsSUzFU=; b=JBbJFH03hpGAQnqcNkc3sAx+qg7quRFMHCuc7vy98Pql5L34GlhCidKVcOZJtSHvKd Wo+U4ZKMCePhR6lcgo8zws0bbDrLnX/TjShu8fPzizCXdvUrHjZ/aQHRjjhepyhsxwvU APhA/QkUguBbl+cwuPdjPgqLNvdRNJDIeEoYDuMa8QDVxO+Vi2hZCOkw5ZaEsTE2AJfT rA31AMbG81lnD+NZnpBb5Oz2XX98+jIN4ajxVN9ZL9x55lhgYDkyLDbENzHb1L8ngBT0 1xjf8td2amMuowSeJyFynBldroYJzPJeIK9Dgyo5rmUfM5MZiMAWw67JDTSCopScF87p RiKA== X-Gm-Message-State: AMke39kYfVNzTSGoZI6CsyeI4JUDdq7TmWVb82n7LaYiaeKTuf3dDUJw1gzEJOV3QCDyJQ== X-Received: by 10.223.163.206 with SMTP id m14mr13160153wrb.34.1489079028481; Thu, 09 Mar 2017 09:03:48 -0800 (PST) Received: from localhost ([2001:67c:208c:10:dd7e:5c5d:90ed:7ed]) by smtp.gmail.com with ESMTPSA id o2sm9441357wmb.28.2017.03.09.09.03.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Mar 2017 09:03:47 -0800 (PST) Date: Thu, 9 Mar 2017 18:03:45 +0100 From: Job Snijders To: RFC Errata System , idr@ietf.org, nmalykh@gmail.com Message-ID: <20170309170345.tnrs3pre5qqmiy5x@Vurt.local> References: <20170309152156.5956BB80EB2@rfc-editor.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170309152156.5956BB80EB2@rfc-editor.org> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: NeoMutt/20170306 (1.8.0) Archived-At: Cc: draft-ietf-idr-large-community@ietf.org, shares@ndzh.com Subject: Re: [Idr] [Editorial Errata Reported] RFC8092 (4962) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 17:03:52 -0000 On Thu, Mar 09, 2017 at 07:21:56AM -0800, RFC Errata System wrote: > The following errata report has been submitted for RFC8092, "BGP Large > Communities Attribute". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=8092&eid=4962 > > -------------------------------------- > Type: Editorial > > Section: 3 > > Original Text > ------------- > Duplicate BGP Large Community values MUST NOT be transmitted. A > receiving speaker MUST silently remove redundant BGP Large > Community values from a BGP Large Community attribute. > > Corrected Text > -------------- > Duplicate BGP Large Community values MUST NOT be transmitted. A > receiving speaker MUST silently remove redundant BGP Large > Community values from a BGP Large Communities attribute. I suggest to reject this errata. The name of the BGP Path Attribute is singular, namely "LARGE_COMMUNITY" (see IANA's "Border Gateway Protocol (BGP) Parameters" registry for "BGP Path Attributes") There somewhat is a lack of semantic precision on when to use "community" and when to use "communities", but there is no other commonly accepted jargon for what we're talking about in IETF creole language. In this sense RFC 8092 was aligned with RFC 1997. Sorry for the confusion, but we didn't see a way around it. If you are an implementer, feel free to reach out to me off list, I'd be happy to help clarify, confirm your understanding of the specification and perhaps help with interop testing. Kind regards, Job From nobody Thu Mar 9 12:21:01 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEFDD12946E; Thu, 9 Mar 2017 12:20:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vyz4JrleYygu; Thu, 9 Mar 2017 12:20:58 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77F5D1293FF; Thu, 9 Mar 2017 12:20:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2242; q=dns/txt; s=iport; t=1489090858; x=1490300458; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=OpRIzvpRlJ4lDOr7/IZ9fXWXvZtPUZ7zBNTWfv3+ip0=; b=AahpoNnS0MinBn5fD1QwqQoRQUH8gnSdB5NdvgfmCECTNZiA0TJreQ+f Shim35mSnby3HOIgYPrecBNRK4C7GZHoY04fquVRNh2R6ZWiMkzMncA2G lpKJtrdx2JzcgLNnYa3S5BqN01PDR0g6K5wfY+4tinPMx8bgT/CdIirVC c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ATAQAXuMFY/5FdJa1DGhkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNRYYEKB41lkU+IDY0rgg4fC4V4AoIxPxgBAgEBAQEBAQFrKIU?= =?us-ascii?q?VAQEBAQMBATg0CwwEAgEIEQQBAQEeCQchBgsUCQgCBAENBQgMiVQDFQ4xsySHO?= =?us-ascii?q?A2DIwEBAQEBAQEBAQEBAQEBAQEBAQEBAR2GToRvgTyBFUaHIgWJGoY+hiKGBTo?= =?us-ascii?q?BjgyEIpEpilSIagEfOBVuVhU/hFQdgWN1AROHWgaBKoENAQEB?= X-IronPort-AV: E=Sophos;i="5.36,137,1486425600"; d="scan'208";a="218395629" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Mar 2017 20:20:56 +0000 Received: from XCH-ALN-015.cisco.com (xch-aln-015.cisco.com [173.36.7.25]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v29KKuqh018243 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 9 Mar 2017 20:20:56 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 9 Mar 2017 14:20:55 -0600 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Thu, 9 Mar 2017 14:20:55 -0600 From: "Jakob Heitz (jheitz)" To: Job Snijders , RFC Errata System , "idr@ietf.org" , "nmalykh@gmail.com" Thread-Topic: [Idr] [Editorial Errata Reported] RFC8092 (4962) Thread-Index: AQHSmOjo5F1lfj0IAEKQ0vaxnQPJCqGNIPyA///SeCA= Date: Thu, 9 Mar 2017 20:20:55 +0000 Message-ID: <701766e2506f49d3adc1686a829875d2@XCH-ALN-014.cisco.com> References: <20170309152156.5956BB80EB2@rfc-editor.org> <20170309170345.tnrs3pre5qqmiy5x@Vurt.local> In-Reply-To: <20170309170345.tnrs3pre5qqmiy5x@Vurt.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.40.202] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-idr-large-community@ietf.org" , "shares@ndzh.com" Subject: Re: [Idr] [Editorial Errata Reported] RFC8092 (4962) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 20:21:00 -0000 I agree. Thanks, Jakob. > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Job Snijders > Sent: Thursday, March 09, 2017 9:04 AM > To: RFC Errata System ; idr@ietf.org; nmalykh@= gmail.com > Cc: draft-ietf-idr-large-community@ietf.org; shares@ndzh.com > Subject: Re: [Idr] [Editorial Errata Reported] RFC8092 (4962) >=20 > On Thu, Mar 09, 2017 at 07:21:56AM -0800, RFC Errata System wrote: > > The following errata report has been submitted for RFC8092, "BGP Large > > Communities Attribute". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata_search.php?rfc=3D8092&eid=3D4962 > > > > -------------------------------------- > > Type: Editorial > > > > Section: 3 > > > > Original Text > > ------------- > > Duplicate BGP Large Community values MUST NOT be transmitted. A > > receiving speaker MUST silently remove redundant BGP Large > > Community values from a BGP Large Community attribute. > > > > Corrected Text > > -------------- > > Duplicate BGP Large Community values MUST NOT be transmitted. A > > receiving speaker MUST silently remove redundant BGP Large > > Community values from a BGP Large Communities attribute. >=20 > I suggest to reject this errata. The name of the BGP Path Attribute is > singular, namely "LARGE_COMMUNITY" (see IANA's "Border Gateway Protocol > (BGP) Parameters" registry for "BGP Path Attributes") >=20 > There somewhat is a lack of semantic precision on when to use > "community" and when to use "communities", but there is no other > commonly accepted jargon for what we're talking about in IETF creole > language. In this sense RFC 8092 was aligned with RFC 1997. Sorry for > the confusion, but we didn't see a way around it. >=20 > If you are an implementer, feel free to reach out to me off list, I'd be > happy to help clarify, confirm your understanding of the specification > and perhaps help with interop testing. >=20 > Kind regards, >=20 > Job >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Thu Mar 9 14:02:52 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 822BB129504; Thu, 9 Mar 2017 14:02:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DY7rm5lE8jTJ; Thu, 9 Mar 2017 14:02:49 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A16A6129546; Thu, 9 Mar 2017 14:02:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2542; q=dns/txt; s=iport; t=1489096968; x=1490306568; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=NxYdeyZKa3eh0HFebvB43YkHtyiGsPvD5RhERixRkFI=; b=m1BcyBzI8b6XhSYMU3fAWK9NZ6NNkuqF9RgL+FrRwiLcz97siktI4QiW fGwzssN9ehrCBWTHU7X9EKs9axr1h6E1L1kNJPlPo8T+bM00rmpVr25Ix 1ipIHvoCHIPMlzfDmmHqAzkV5/LgjR4zIUBxPh+pRDOBiu8AhlDMkpUb6 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CvAQC7z8FY/49dJa1DGhkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNRYYEKB4MTRooMkTAflTiCDiqFeAIaghc/GAECAQEBAQEBAWs?= =?us-ascii?q?ohRYBBQwXEUUQAgEGAhgCAiYCAgIwFRACBAENBRSJbA4xkx2dW4ImimgBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEdgQuFQ4IFCIJigTyBW4E9gwYugjEFiRqGPoYihj8?= =?us-ascii?q?BkjeBe48liESKegEfOBVuVhVQAYRCDRCBY3UBE4daBoEqgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.36,137,1486425600"; d="scan'208";a="218452634" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Mar 2017 22:02:47 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v29M2l8r004542 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 9 Mar 2017 22:02:47 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 9 Mar 2017 16:02:47 -0600 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Thu, 9 Mar 2017 16:02:46 -0600 From: "Alvaro Retana (aretana)" To: Job Snijders , "idr@ietf.org" , "nmalykh@gmail.com" Thread-Topic: [Editorial Errata Reported] RFC8092 (4962) Thread-Index: AQHSmOjpYm14ufnE6UuE6v5ZB2jNDqGNIPyA////ugA= Date: Thu, 9 Mar 2017 22:02:46 +0000 Message-ID: <862277A8-79A9-4AF9-8357-630E56CE9790@cisco.com> References: <20170309152156.5956BB80EB2@rfc-editor.org> <20170309170345.tnrs3pre5qqmiy5x@Vurt.local> In-Reply-To: <20170309170345.tnrs3pre5qqmiy5x@Vurt.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.6] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-idr-large-community@ietf.org" , "shares@ndzh.com" Subject: Re: [Idr] [Editorial Errata Reported] RFC8092 (4962) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 22:02:50 -0000 W1Rvb2sgdGhlIFJGQyBFZGl0b3Igb2ZmLl0NCg0KSm9iOg0KDQpIaSENCg0KSSB0aGluayB0aGlz IHJlcG90IGlzIGNvcnJlY3QsIHRyaXZpYWwsIGJ1dCBjb3JyZWN0Lg0KDQpUaGUgbmFtZSBvZiB0 aGUgY29kZSBhc3NpZ25lZCBieSBJQU5BIGlzIGluIGZhY3Qgc2luZ3VsYXIgKExBUkdFX0NPTU1V TklUWSksIGJ1dCB0aGUgZXJyb3IgYmVsb3cgaXMgdGhlIG5hbWUgb2YgdGhlIGF0dHJpYnV0ZSAo bm90IHRoZSBjb2RlIHBvaW50KSBpbiB0aGUgZG9jdW1lbnQuICANCg0KTm90ZSB0aGF0IHRoZSBh dHRyaWJ1dGUgaXMgbmFtZWQg4oCcQkdQIExhcmdlIENvbW11bml0aWVzIEF0dHJpYnV0ZeKAnSBp biBTZWN0aW9uIDMgKG5vdCDigJxCR1AgTGFyZ2UgQ29tbXVuaXR5IGF0dHJpYnV0ZeKAnSkuICBJ biBmYWN0LCB0aGUgcGhyYXNlIOKAnEJHUCBMYXJnZSBDb21tdW5pdGllcyBBdHRyaWJ1dGXigJ0g aXMgdXNlZCB0aHJvdWdob3V0IHRoZSB0ZXh0ICgxMyB0aW1lcyEpLCBleGNlcHQgZm9yIHRoZSBp bnN0YW5jZSBiZWxvdyAoYW5kIGEgMiBtb3JlIGluIFNlY3Rpb24gNykuDQoNClNv4oCmSeKAmWxs IG1hcmsgdGhpcyByZXBvcnQgYXMg4oCcSG9sZCBmb3IgRG9jdW1lbnQgVXBkYXRl4oCdLCB3aGlj aCBtZWFucyB0aGF0IGlmIHRoaXMgUkZDIGlzIGV2ZXIgdXBkYXRlZCBpdCBzaG91bGQgY29ycmVj dCB0aGUgbmFtZSBvZiB0aGUgYXR0cmlidXRlLg0KDQpUaGFua3MhDQoNCkFsdmFyby4NCg0KDQoN Ck9uIDMvOS8xNywgMTI6MDMgUE0sICJKb2IgU25pamRlcnMiIDxqb2JAbnR0Lm5ldD4gd3JvdGU6 DQoNCk9uIFRodSwgTWFyIDA5LCAyMDE3IGF0IDA3OjIxOjU2QU0gLTA4MDAsIFJGQyBFcnJhdGEg U3lzdGVtIHdyb3RlOg0KPlRoZSBmb2xsb3dpbmcgZXJyYXRhIHJlcG9ydCBoYXMgYmVlbiBzdWJt aXR0ZWQgZm9yIFJGQzgwOTIsICJCR1AgTGFyZ2UNCj5Db21tdW5pdGllcyBBdHRyaWJ1dGUiLg0K Pi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+WW91IG1heSByZXZpZXcg dGhlIHJlcG9ydCBiZWxvdyBhbmQgYXQ6DQo+aHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9lcnJh dGFfc2VhcmNoLnBocD9yZmM9ODA5MiZlaWQ9NDk2Mg0KPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQo+VHlwZTogRWRpdG9yaWFsDQo+U2VjdGlvbjogMw0KPk9yaWdpbmFs IFRleHQNCj4tLS0tLS0tLS0tLS0tDQo+ICAgIER1cGxpY2F0ZSBCR1AgTGFyZ2UgQ29tbXVuaXR5 IHZhbHVlcyBNVVNUIE5PVCBiZSB0cmFuc21pdHRlZC4gQQ0KPiAgICByZWNlaXZpbmcgc3BlYWtl ciBNVVNUIHNpbGVudGx5IHJlbW92ZSByZWR1bmRhbnQgQkdQIExhcmdlDQo+ICAgIENvbW11bml0 eSB2YWx1ZXMgZnJvbSBhIEJHUCBMYXJnZSBDb21tdW5pdHkgYXR0cmlidXRlLg0KPkNvcnJlY3Rl ZCBUZXh0DQo+LS0tLS0tLS0tLS0tLS0NCj4gICAgRHVwbGljYXRlIEJHUCBMYXJnZSBDb21tdW5p dHkgdmFsdWVzIE1VU1QgTk9UIGJlIHRyYW5zbWl0dGVkLiBBDQo+ICAgIHJlY2VpdmluZyBzcGVh a2VyIE1VU1Qgc2lsZW50bHkgcmVtb3ZlIHJlZHVuZGFudCBCR1AgTGFyZ2UNCj4gICAgQ29tbXVu aXR5IHZhbHVlcyBmcm9tIGEgQkdQIExhcmdlIENvbW11bml0aWVzIGF0dHJpYnV0ZS4NCg0KSSBz dWdnZXN0IHRvIHJlamVjdCB0aGlzIGVycmF0YS4gVGhlIG5hbWUgb2YgdGhlIEJHUCBQYXRoIEF0 dHJpYnV0ZSBpcw0Kc2luZ3VsYXIsIG5hbWVseSAiTEFSR0VfQ09NTVVOSVRZIiAoc2VlIElBTkEn cyAiQm9yZGVyIEdhdGV3YXkgUHJvdG9jb2wNCihCR1ApIFBhcmFtZXRlcnMiIHJlZ2lzdHJ5IGZv ciAiQkdQIFBhdGggQXR0cmlidXRlcyIpDQoNCg0KDQo= From nobody Fri Mar 10 11:53:13 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07E3B126CD8; Fri, 10 Mar 2017 11:53:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.198 X-Spam-Level: X-Spam-Status: No, score=-1.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ANKbYZk1gu2G; Fri, 10 Mar 2017 11:53:05 -0800 (PST) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0117.outbound.protection.outlook.com [104.47.34.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1A911270B4; Fri, 10 Mar 2017 11:53:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=u381glLYvgD0Ay+mqWRYHDtPT4z3BqcQ8RxzdCq5ugs=; b=jiExuAr/4BC2/sfEaLhn/KnW4Eov7Y33euJHby6bef5c2ThP8pneX9CHhLpKhf/XYGxMF22FbYq+/N7HoZflgMK11YArg+5TymD4dp6PLe9EhlO9KFqcM7WT6IOld4sboSKB7DAiC1NdKwq4LstP6AfAKRR4awwAcjagEAplQVU= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; Received: from dhegde-sslvpn-nc.jnpr.net (66.129.241.13) by CY1PR05MB2507.namprd05.prod.outlook.com (10.167.10.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.961.8; Fri, 10 Mar 2017 19:53:04 +0000 MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/html; charset="utf-8" X-Apple-Auto-Saved: 1 X-Apple-Mail-Remote-Attachments: YES From: John G.Scudder X-Apple-Base-Url: x-msg://73/ In-Reply-To: <10484_1487263806_58A5D83E_10484_6197_1_53C29892C857584299CBF5D05346208A1ED67062@OPEXCLILM21.corporate.adroot.infra.ftgroup> X-Apple-Windows-Friendly: 1 Date: Fri, 10 Mar 2017 14:52:46 -0500 X-Apple-Mail-Signature: SKIP_SIGNATURE Content-Transfer-Encoding: quoted-printable Message-ID: References: <00f901d287e4$16ecb2f0$44c618d0$@ndzh.com> <10484_1487263806_58A5D83E_10484_6197_1_53C29892C857584299CBF5D05346208A1ED67062@OPEXCLILM21.corporate.adroot.infra.ftgroup> X-Uniform-Type-Identifier: com.apple.mail-draft To: X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.13] X-ClientProxiedBy: BN6PR11CA0047.namprd11.prod.outlook.com (10.173.25.33) To CY1PR05MB2507.namprd05.prod.outlook.com (10.167.10.134) X-MS-Office365-Filtering-Correlation-Id: d664ebe2-83d8-4171-62a8-08d467ef1132 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY1PR05MB2507; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 3:RQqO8hs5l1sv3zYdVtB7JXzDl4mZYO5jDDfL1RQ7LoTDRrwy4Cvw2CGODU8Yvlezuv0V5FSbr6Uc5w/HPiAyRki6PR8M04uHwjqyE4vvmKsYoO6wR3HpVI5r+rdT8Hc5LFZgf9QSn1SFwLODwzQaMAxsGluLgPtSMQkT68sGsxtxyeAuoMIVZ4kuJYPgJUaOfVCI7Jn/jE4GG/6Nxl5M+FrTVLcw5X8+YrCe24TTByM6Yj2DhDNQulWty9sDBnFwb8N3N6XWB9iub4epJ9P3y7ZwDQybHLB91DC8m+g+br8=; 25:o6L4dMlRMMSVvMOncQevZIRAgUf8iv66kCPeoOC3Wr4MuK5sNynFlLJY5rwaw2p46HrBTHWEsNVAzvl19ZVPUsGDCppXHp6aflmHYxtE8LpClv1zf8/HuCgsHrlc85v/sS3vvr1gwm7iRaKbdiH6Do3EPTrYd0TwPKBTMJ5om242dGT/FddHKRfieMmg/vaFhOh0dLJ4QDYopZ6jsChRBCs1y/Iw+GQf4Eam0T/y4kFnNK+7knfdUq+jjQjgEqkJS+yfevZklSG/JbuInsVNtMxrVxonZb3dnPOFAmibWZ8IxidhkSDdkJshffApUdMHy8gl56R71qmeB0Rk0hstceZUEtOK84d0snNKcrs2ZGbqC496XVr5jVK8zCntqAyTafuUGW8A12vgHVdipIekZRGgLrKoY32vMsXZHWN/z2lUzV2wG+qhgGGEkDWa5fd4upS+zFolXmJ47of23AHjTw== X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 31:VYg2caHZjAHfhi4TA06wps96Y+5OwsAut+su3wJg5Os5b5DZVBKDVCJ7kf+w44LxKYGE2k6RSiNZ5QFGdi+fVreJSYg2XfY5zwiXVaK5CGRyML5hCNqZprxQJEBFFdLDsutUpWN2alHyMISjPreueIZY1RyQcdBE1AcNlr5I1gTA48YZHH+APwAE6SyFpohfNofh7XQ8t6kXzi5KtajgsbAvszrfYfoLFxY7kNgfGCuCLfco6s9mGb7IOwZ6HcUg770iDTweNTe+MONKBMeNpg==; 20:9m4LVj66hO2b0jYsdEktimU0kK8gwnY3bxEPWKI5V/2pH1xlFrx0ZMW3SjTT39doN5jIpsI2niyGGZsEL+FkHrXs0HSy4fULvLPWY64SpY+MIIIFppHN/9v6bHR/Iqv4mDX78Ln7kcyok4z60YxjHNyzvaeeYs0qx5Gw9HqGCs3HLEbrD78JoWHHfRBya628WXjKtuKa/sehQ//phqwc8HXKLUgT+nq8KVyOa+AHBW9GV/5C1eD4Z4EsuUyQFWAyiIweN4zCxGCr/j562c9xE3d75NY+FcaERCGBtRukUQLw0RVRlnBpDtWZXBgwJ3AKs0HF1Q5kCF+C4SU+EhVoT2WYabxBqBm2DLlRzDPdJC7xC1Aw22Q+bKzxfbaz9Y2S2hadfnpxk+yao10vWcd9rxfU34p51zSPrGh9o+TZd170gCSaQVqqSzmwNWKGKd7ie+x8S1S0eEcjZh3NtHVQIC5emG5994INBixkoQXILOAVMjwi9za/+I8PpKwYG23qUPMgyhVNJ5xMZF/oKJSAWllkHxrpwOVnbmsSvw7rfAxbatNaKdS5Z9jS2qqofxC0ahWQ1UHt2Y5mUUqhaSDYRVdt9BRKMWl9Z0r/K0arqVE= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(120809045254105)(18271650672692); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(20161123555025)(20161123558025)(20161123562025)(20161123564025)(6072148); SRVR:CY1PR05MB2507; BCL:0; PCL:0; RULEID:; SRVR:CY1PR05MB2507; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 4:7+NUmGZ4BQKZF6uY9KtWClEvCrYW8KItKuXIF4Ee6qn7wQloJRu+VljrSiR9FeBFyCXK6y9s/U3104Nf37GeDFzkzF12o4vmdAXMR7o8gAV+VaiQZX1r4r4OrhBChN8KZ8jKX9rmajbGk69HEetmY4QVLnq4PosVn+q6upOyeeCnuPAYtR/TobKnjaeAcAoHK0/vMlGMnbJQonvw/2xJ2eDlebIyUb+9dVMwpbyCvB+dH2UTxoxLIKh/U7kz+6/HOu5NcqU8kLXOWfh4T4xdy/t++UghxEBlzlOVL3CSklW9aD5DWwC8fqm5KhJzucvyKBZTIavUboGO0TZItfOnG+NRlO3pYQeg6p8K4OFlY2myIE9pjoEDnwZ/JMrTXk/nLzx18whno1K+cCnywBJu2I9u8tfdjnb2c81WftBf9olTE7JDOZlTbOCrd7XkqjVvwTXJM/tl9yiOxghjk+uNo5nTGyMZUxNAxpxTp36pRfseuceGW8AunxqOeiOeu/cY0gmXhLRT3+iJlSiUr7Ix+KnY2yOdUvg6mZnNUKXchE0E788Febwo+pj+cNrhhU3J2SVypYp13040L/YoSZ32uvCTijgH3SfKj/NO/bcLF9BmA4WujZ69HaZov4+e8eE83Gx3Oxeo29vtZfSgN4H/H1p3P7je0TVBYb/Eap31MubRxyTIFhv2h4o8ibClDchsr38LdUibhniFBA1c6Ge10w== X-Forefront-PRVS: 02426D11FE X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(39840400002)(39860400002)(39450400003)(39410400002)(39850400002)(24454002)(377454003)(5423002)(2351001)(23846002)(110136004)(38730400002)(42186005)(229853002)(53936002)(7736002)(8676002)(53416004)(5890100001)(6116002)(6246003)(81166006)(54906002)(7906003)(6306002)(4326008)(36756003)(236005)(8746002)(53546006)(6512007)(6486002)(50466002)(606005)(23676002)(2906002)(66066001)(2950100002)(6916009)(6666003)(230783001)(25786008)(6506006)(50226002)(189998001)(3846002)(33656002)(76176999)(50986999)(86362001)(5660300001)(42262002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2507; H:dhegde-sslvpn-nc.jnpr.net; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDWTFQUjA1TUIyNTA3OzIzOmJFOGpNMDQvQUZ2WGZxWlpablpLcFBCUFRv?= =?utf-8?B?T25KdnQ0YVgwWEw1ejBmSTFNWHVxS2w3TW9uQkhyeEJrTlFubnh6RTFLYk4x?= =?utf-8?B?c3Azd0VudG9MZ3p3VThvSlZtSTZFUldieFlxbFhBWXY1dEthMmZMYkU1OSsv?= =?utf-8?B?SmprVGhLUkpMdmE5Vys4RGErT0lDZ2tKWmxQMUJWZjllWlF5YUNabmJIaUpU?= =?utf-8?B?THhBK0VvSUdNMEVZNXVZczRpRWxIU2VEeStqQTZ4bkxLcHRXRVN0SGZsZ0NX?= =?utf-8?B?UVd2R1RnWjhoVWhJemhQQnUxMFkwMDJtTFVWMGtpai9iRUtCVU9uRmdLRmNP?= =?utf-8?B?KzBPV2RzRjNhQjhMT0hNWlRHbkxuUHBMWDlCQllTMkdiMUxWcFo5VnNMakJJ?= =?utf-8?B?KzRJM0t1cVR2Z2JrOXc2ZVViTkhQT2wrTndjUzJvSUlYSXZ2NGdtZ3B5WFVG?= =?utf-8?B?YjVwd01zb1IzakZkMEllUUo5MlRlZmRKV3lSRkQvTDZwVmxTaVliMVozMEVP?= =?utf-8?B?Vko2cUhvNkI1LytDV3I0VmhNNDM1bllzUW5LZlQxNkd1ZXpldjRHZDNNanV6?= =?utf-8?B?SE5DMkVVU3VUZ0U4b1ZUMFZmc1VqN3F4LzFWWS9qRHgvWGF6Q0x5dnEvaGR3?= =?utf-8?B?a3JTTVNnZlYrZVZjTUZqZTFjMDJaWklTcWsyaXBXMm9zVUZWbC8yckFoMHRL?= =?utf-8?B?V0ZvSzN2c0NlZzlWZ2YzUUNPSzhNMC9Bd01JL1RocFZVZzJOdkM1MVN6U2gx?= =?utf-8?B?NUNzTE83ZmNKQjlwRmVRV1gwVXNlS1Vub21YN3BaVDhBb0g0UGpwRTdXb0Ev?= =?utf-8?B?Y01OUjBwbXl4SXZob000aUVSRzZpd0VCL05HUS9FN3JyOWZJaWRUVSt2QXZ1?= =?utf-8?B?dng2TVkyUWVrdlBybW5hT1RwT21oejdqWmVuRkRaVUZrWms5V1JPTDdwL2hC?= =?utf-8?B?VExrVEUwN1FReVBNK2hSQS94NCt1RkNFemdETUt4Yk1PR21sZGFaYk1IczNy?= =?utf-8?B?dk50cTd5L2hyK3Z3a3U1RXBxdDZjcnNtZWs4MUxPSzBUY1hlQnBMZUlIcHFR?= =?utf-8?B?cEdWVjR6enl6OVhLUnUvZ3VvRFRVS2xsQzQ0V3FteUwzdnl0V2IvU0tZL3Zm?= =?utf-8?B?YzJDbE1UOGsyZjM5UGZ4cnB2UGxWVnoxZjVvb0RBS0d2RlVrZTVmeE9qT2ZU?= =?utf-8?B?clMrVUU2TmJIcGpHb3lGc0JHbndBMWdFTUhMTlYxK1RvMmdPMDJ2b2lYUDZ0?= =?utf-8?B?TFdLemxTejR0aTFvUmhtTEZjSWYrclQwS1lpSTFBWXRMbU8wQmRUdnB3S3Rn?= =?utf-8?B?cWpYZ1ZYTFNwUWt1M2NsSmp0RHpDSS9vZ2FUTHJDQXkwNFBKYnV6RDdJRW1F?= =?utf-8?B?Uld5V3Vpa1hwODhkRTVvZ0FOQW95WTd5SWFtNlVNK0FRVkhOTDFCWGQ2a2ZN?= =?utf-8?B?Q2FvREdsOXZYdUNnZEpmVnlZQUtFV0c4elZHSnp2SmZjTDNIWXhOaUw2Q29S?= =?utf-8?B?ZzR0OHo2RXZaUEtaWjF2NHJ1c2dKRi83TzRxdXAySDJoRDB0dXZ2N2xveUJo?= =?utf-8?B?MzRla1BXUElwczdDYmQ2WW45Ti85T1drejNaa1NhK0lCTmgrSXZkMTBMSUZy?= =?utf-8?B?WFJuZC85cU8xdFZCSWlZU0dLQXgzK05pSTVieWQ5SHczWFczSEk5QU1vY0N2?= =?utf-8?B?UVRCUlk0OENUQll3RVg0TXNraGtNRG1JeXpVRDZLclVaWXhrdEc4aUkrOThT?= =?utf-8?B?STZEV1I0OTUzZ25BcnBSZz09?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 6:ia4l9GnMzEExiEJRud0sokGYuNrmlO1/EpALERx15AJMXlq84c3Yzcaw4EWiMcl7Ap2ip5Y0Tv0IextrHzf+P+OJNVFl0VGL+WAw/1d/Rx/HIQBoqBixiLB5vckCYtrKM76y5bQ4/pg56fg1wKH+KzpsMMQyNrRun6SXYwdXmwQAV9JUXcRGOpsXwnPdKU5u90lrp411haLebZ7842da30kQkwKYR2ALLPLzPGgXkzBa/x1tJkYEXIQqKmIsWsbHT83xXl7NTJEwwqIKvuwcoK5uS+KwX4zuPCUNwDB3eb6TLIMUCvpASrYkdyEldwKtJMzCK4WRJGDcv8V740uOus/dWtwYQfh+GOP6wUQSNdCSZS/aVoekA8gRCPSbKcoIReoWUuabrcJXwRHS9MoaMOYfQq8CCY62t6R/H5i/2+E=; 5:42thxPFLldrb201p/hHFN8ZymoPW62ZQ9By1WiaMj1YHsaZ+5B2vAhlPxLMtABs4RDKLvv1gqTHQd9LO7UcJe2Cay5JBnIuTJCD3rZh8bAojGlaZkGRwKv0rHJAApLZdlS533kLycvbNJOaRRnlADg==; 24:A+/Qx4yaFrtM54hytwYhi2kak8etShj23RZw9hw6dbSTjV6kbb4Pd1mn/M2f+scZRclG9dgKnpECLy3Fy9S4XqAizbLvdS/1cOaMKAd3n90= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 7:FEjMgGB0dt214dViOU+hKkd81pHxDxiO8J9YeOJj8MgcxidNqOYWVQwRzbSIGY2S6st71b3rZWDNfu90YgxVy7lVPQWOEz6BrzfiBntGaEPv4K7/+FqvAAsgl9JPKc83IzvrPLdU0eUjorYRNX7y8AOHy93o+jPvFb/MMKTMpZp7xL7zuZdm30RCmrc84rp9ETqGwswLAhUqYUDFLzCOv06nFiBz7vgWZxWp+bGVpObzM2fl6HZRCAoMxPhhGAIU5XFrVMlPCwYKhr/Aa70k6AEttCv8f2MDVNhHqvSrd8xEtjrbElYAIAksCxU2RMqeFj6Yc6P6dyWTsHj4W2fIrg== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Mar 2017 19:53:04.2165 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2507 Archived-At: Cc: "idr@ietf.org" , "spring@ietf.org" , Susan Hares , Bruno Decraene Subject: Re: [Idr] [spring] IDR WG 2 week WG LC on draft-ietf-idr-bgpls-segment-routing-epe - (2/15/2017 to 3/1/2017) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 19:53:07 -0000 Hi Authors,

I see that yesterday's -10 revision = doesn't address Bruno's comments, below. Can you please either update = the document if you accept Bruno's suggestions, or otherwise discuss = them on the list? We can't declare the WGLC to be satisfactorily = finished until this is resolved.

Thanks,

--John

On = Feb 16, 2017, at 11:50 AM, bruno.decraene@orange.com wrote:

Hi,
 
I=E2=80=99ve read the draft, please find below some minor = comments:
 
---
=C2=A74.3
"      *  A = 4 octet index defining the offset in the SID/Label space advertised by = this router using the encodings defined in  Section 3.1."
 
- Following the recent addition of the SRLB Label Space, I'd = rather have the text explicitly refers to name of that Label space. = e.g.
OLD: SID/Label space
NEW: SRGB
 
- Which (SRGB) advertisement? I'm assuming the IGP one, but I = guess someone may imagine using the BGP "Originator SRGB TLV". Then what = if the node runs multiple IGP with different SRGB configured?
 
- Note that this document has no "Section 3.1". The text = seems borrowed from the IS-IS SR draft, hence may be adding the name of = this draft would just solve the point. (with a normative reference to = this IS-IS draft)
 
---
OLD: The Link NLRI uses the new Protocol-ID value (to be = assigned by IANA)
proposed NEW: The Link NLRI uses the BGP Protocol-ID = (TBD1)
 
(=E2=80=9Cnew=E2=80=9D may become unspecific 2 years from = now)
 
---
One could probably argue that = [I-D.ietf-spring-segment-routing] should be a normative reference.
 
Thanks,
Regards,
--Bruno
 
 
From: spring [mailto:spring-bounces@ietf.org] On Behalf = Of Susan Hares
Sent: Thursday, February 16, 2017 = 12:35 AM
To: idr@ietf.org
Cc: 'Alvaro Retana = (aretana)'; spring@ietf.org
Subject: [spring] IDR WG 2 week WG = LC on draft-ietf-idr-bgpls-segment-routing-epe - (2/15/2017 to = 3/1/2017)
 
This= begins a 2 week IDR WG last call on = draft-ietf-idr-bgpls-segment-routing-epe from (2/15 to 3/1/2017) =    There are two implementations describe on the wiki = at:
 
The two implementation are from  Cisco IOS-XR release 6.0.2 and = Cisco Nexus Switch N9000/N3000 platforms running NX-OS 7.0(3)I1(1) or = greater.   The authors will indicate on the list and in the = wiki the following information :
 
1)      Were these = implementations separate implementations?
2)      What were the = results of the interoperability tests?
 
This= work is linked to the draft-ietf-spring-segment-routing-central-epe = work in the SPRING WG. Based on the two drafts, the WG should might = consider:  
1)      Is there need for = this work in deployments in networks/
2)      Is this technically = ready for publication?
3)      Does it fit with = the spring informational draft?
 
For the ease of reference the web references are = below:
 
Sue Hares 
_______________________________________________________________=
__________________________________________________________

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.
_______________________________________________
Idr mailing = list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

= From nobody Fri Mar 10 12:01:44 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B202129678 for ; Thu, 9 Mar 2017 07:22:01 -0800 (PST) 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, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vxLlf44NVX3Y for ; Thu, 9 Mar 2017 07:22:00 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B4C4128B38 for ; Thu, 9 Mar 2017 07:22:00 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 5956BB80EB2; Thu, 9 Mar 2017 07:21:56 -0800 (PST) To: jheitz@cisco.com, job@ntt.net, keyur@arrcus.com, ibagdona.ietf@gmail.com, nick@inex.ie, akatlas@gmail.com, db3546@att.com, aretana@cisco.com, jgs@juniper.net, shares@ndzh.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20170309152156.5956BB80EB2@rfc-editor.org> Date: Thu, 9 Mar 2017 07:21:56 -0800 (PST) Archived-At: X-Mailman-Approved-At: Fri, 10 Mar 2017 12:01:44 -0800 Cc: idr@ietf.org, text/plain@rfc-editor.org, rfc-editor@rfc-editor.orgContent-Type, charset=UTF-8@rfc-editor.org, nmalykh@gmail.com Subject: [Idr] [Editorial Errata Reported] RFC8092 (4962) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 15:22:01 -0000 The following errata report has been submitted for RFC8092, "BGP Large Communities Attribute". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=8092&eid=4962 -------------------------------------- Type: Editorial Reported by: Nikolai Malykh Section: 3 Original Text ------------- Duplicate BGP Large Community values MUST NOT be transmitted. A receiving speaker MUST silently remove redundant BGP Large Community values from a BGP Large Community attribute. Corrected Text -------------- Duplicate BGP Large Community values MUST NOT be transmitted. A receiving speaker MUST silently remove redundant BGP Large Community values from a BGP Large Communities attribute. Notes ----- Typo Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8092 (draft-ietf-idr-large-community-12) -------------------------------------- Title : BGP Large Communities Attribute Publication Date : February 2017 Author(s) : J. Heitz, Ed., J. Snijders, Ed., K. Patel, I. Bagdonas, N. Hilliard Category : PROPOSED STANDARD Source : Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG From nobody Fri Mar 10 12:01:49 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9D5C129530 for ; Thu, 9 Mar 2017 19:03:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G0qqz7Y2ARY0 for ; Thu, 9 Mar 2017 19:03:45 -0800 (PST) Received: from mail-wr0-x241.google.com (mail-wr0-x241.google.com [IPv6:2a00:1450:400c:c0c::241]) (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 E720E12953D for ; Thu, 9 Mar 2017 19:03:37 -0800 (PST) Received: by mail-wr0-x241.google.com with SMTP id u48so10050203wrc.1 for ; Thu, 09 Mar 2017 19:03:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=H5ManzjaYhwqiFy5rApbjIuiZbMJvX8eJlE1+XEVs7E=; b=bltK0lXJMSUKxHZeEt95762g19mc8TV6qOuZdPB6yDCFAZeXdONlI+5WHmgEkmfVfO xfhPr5QwqvdaYAqqjgSDsM4+LhFwxBT4vW3ZMaxgSx0yPhxi9XWXwKCourmfx0OUobX6 Hs/LMOp1GSDXvtkAvifmwWUvtnGs3LBgyWdy0EuaZX2uS/VDNNM+tddf4y32kV3GytJ8 Tk0/zQvVX6cvQ02YV1dNBSnrTkZPR5pvf2TLd0f/5ileuQ0amqEJ6LblNr4cnfmODp6Q +p96iavaK5q1C8mhPxiMfAOdSIBPOefzVcVeimMtlZEy1CPol4kJVbe0SA9zBz6j4NNx ge1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=H5ManzjaYhwqiFy5rApbjIuiZbMJvX8eJlE1+XEVs7E=; b=tO4I7PkjUEG45wgVtFJ0MBdq29C0qCKHJoTpKAtcGh4am02fwaD7AL3ussjRq5X9HZ GF4FFbez/c8RMTdLeKv4QPYTvm/7iF1yBoXB+/eW6t6NtrBpQ4PZqdRQMS1UGp85IgcW kgu6X0fJqw9OZXDxSyzaxNFFcd+1UCZL6TfuNJjkvZvDZgu0167qfT3brvhuxZBk4AgX 1CgHA1dEjUYfjcbiED/9ADLqp65OfT1Bc2KOET9EORTqO3Wp/yMPGjknPHsxuFgopwco 8mrGTzDHK55HUXT7FvBvKPvVcdYoJkeW7tUtSqMR9fP4x29VS1lSdPHADYJ5kw5DU0zW 4XNw== X-Gm-Message-State: AMke39m9B2jTrqUdldLB1RA0eJVdTVWuOguiJuPL3Ozkuus2gpJvjOxwpgGctOBoZpM+YQ== X-Received: by 10.223.179.216 with SMTP id x24mr12731152wrd.171.1489098918657; Thu, 09 Mar 2017 14:35:18 -0800 (PST) Received: from [192.168.191.246] ([80.69.10.100]) by smtp.gmail.com with ESMTPSA id p93sm9857967wrc.67.2017.03.09.14.35.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Mar 2017 14:35:17 -0800 (PST) To: RFC Errata System , jheitz@cisco.com, job@ntt.net, keyur@arrcus.com, nick@inex.ie, akatlas@gmail.com, db3546@att.com, aretana@cisco.com, jgs@juniper.net, shares@ndzh.com References: <20170309152156.5956BB80EB2@rfc-editor.org> From: Ignas Bagdonas Message-ID: <0be5014c-4145-6430-2b3c-14b2beb8d153@gmail.com> Date: Thu, 9 Mar 2017 22:35:16 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <20170309152156.5956BB80EB2@rfc-editor.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Fri, 10 Mar 2017 12:01:44 -0800 Cc: idr@ietf.org, nmalykh@gmail.com, rfc-editor@rfc-editor.org Subject: Re: [Idr] [Editorial Errata Reported] RFC8092 (4962) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 03:03:46 -0000 Hi there, If the intention of the errata is to address the handling of duplicated large community attributes (i.e., multiple type 32 attributes present in UPDATE message) then it does not seem to be right. RFC7606 does not allow to have more than one meaningful attribute of the same type in a single UPDATE message, therefore the literal interpretation of "BGP Large Communities" attribute does not apply as only the first such attribute gets interpreted and all subsequent ones get ignored. RFC8092 has both singular and plural form of term "large community" values used in different contexts, referring to either a single 12 octet large community value or to a whole large communities attribute. Ignas On 09/03/2017 15:21, RFC Errata System wrote: > The following errata report has been submitted for RFC8092, > "BGP Large Communities Attribute". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=8092&eid=4962 > > -------------------------------------- > Type: Editorial > Reported by: Nikolai Malykh > > Section: 3 > > Original Text > ------------- > Duplicate BGP Large Community values MUST NOT be transmitted. A > receiving speaker MUST silently remove redundant BGP Large Community > values from a BGP Large Community attribute. > > > Corrected Text > -------------- > Duplicate BGP Large Community values MUST NOT be transmitted. A > receiving speaker MUST silently remove redundant BGP Large Community > values from a BGP Large Communities attribute. > > > Notes > ----- > Typo > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC8092 (draft-ietf-idr-large-community-12) > -------------------------------------- > Title : BGP Large Communities Attribute > Publication Date : February 2017 > Author(s) : J. Heitz, Ed., J. Snijders, Ed., K. Patel, I. Bagdonas, N. Hilliard > Category : PROPOSED STANDARD > Source : Inter-Domain Routing > Area : Routing > Stream : IETF > Verifying Party : IESG From nobody Fri Mar 10 12:01:53 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5633C126DFB for ; Fri, 10 Mar 2017 11:53:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQJEhd7fH1Ef for ; Fri, 10 Mar 2017 11:53:04 -0800 (PST) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0108.outbound.protection.outlook.com [104.47.34.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 719C6126CD8 for ; Fri, 10 Mar 2017 11:53:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=zPS8TlhHtGros5/NaFyNjo1KW7OcWzh5NYiXCVKfTc0=; b=d6IIhuKqR7IJOGH2MXY3/tgkAQkR9frI0WAgUW88BSUvgrngj2viwhlPEgXVAvWDJz1WFKUD+NxbuaFi5kxrst0KWhlsWMfHBu4l5bhhLUXLdpAjJzDcEi4NaLS0KSZ8poUwFD6eDdxIbzJK0ncZR5OyObYF18uXXxl9hUWThfU= Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=juniper.net; Received: from dhegde-sslvpn-nc.jnpr.net (66.129.241.13) by CY1PR05MB2507.namprd05.prod.outlook.com (10.167.10.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.961.8; Fri, 10 Mar 2017 19:53:01 +0000 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "John G. Scudder" In-Reply-To: <0be5014c-4145-6430-2b3c-14b2beb8d153@gmail.com> Date: Fri, 10 Mar 2017 14:04:25 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20170309152156.5956BB80EB2@rfc-editor.org> <0be5014c-4145-6430-2b3c-14b2beb8d153@gmail.com> To: Ignas Bagdonas X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.13] X-ClientProxiedBy: BN6PR11CA0047.namprd11.prod.outlook.com (10.173.25.33) To CY1PR05MB2507.namprd05.prod.outlook.com (10.167.10.134) X-MS-Office365-Filtering-Correlation-Id: 0ede2b6d-bec4-4ebf-8f88-08d467ef100c X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY1PR05MB2507; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 3:SgZVpZkPVtqhqCX39O5rD7SGGYwrQxrV4ORwy/73QkFiFakngfKAljnexafzwZm0PH0uDRBZL6MyuFgS4QwfO/ayLhOOP4yQwxZVxYwQ+rf0otQeXdUQyQ2wJI17h2P4n+TFC5npH4d/aBU3oYzwP0j5e7q/hF/HZW/x3qjDQi+dL8WLmeaPHuOkyhuoDrheUZwBcSxnj5yzb9fGa3UVCR7SlsqnsHc1uWO7A/rEP+JD2Q770bDTa2Buqx4pAwlW0OBSTH3F7Am56FLJh51BrzmXVMp2R4D57jrBpHQOSTE=; 25:cE6k4oFe4pGbaIdzxuUjatbFARXrX7xaFTzl5n55aN6nBvaoRSO1DzEjEdWIN/havPfHI9Y3YVQTJ+XilyjPUXsyju+YQwPPg0SO1Z62O6QFOjqSIrvJj14ygRFxy1irLSCAGHiH24DPIF/EnlXxmTLaQ+tj4xEuGuKky+0ctPN/dUIPfL8K0e2QbYfpTijnWeTNepZCgCi0QkfBMvZZz2u5qt87t9Ijw/u/EzmvO7FxXserai2vO9rT1CNG7OkNabYyK4im7oaJS3b0uSTE2DBFTfgcfH7w2fow4zfXQK6CTr7L+6kwMNTiqRGQdaCygy0ISgLonvSrjnZi0y3iyVCbxkdZWq1AcdaOCvKVkK49QAtyVdQwiRlBa9SbrVfhVhpmmr8VAvBcIgquxxZYTYmagDNmwELInmR0ZuM93IHdOpX7EX1vvDy29gK2209c0j4bbMPEKISLvD911DAreQ== X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 31:bhs+L50zrOkn3APqU5n0aO10bpMeD1UCrXDXMK5LQwIaJ0xCa06DS88xaOpwOS29F9mj5movvsIhIp6NSheNxUSZT0vSe2QbWds06yxuSPt2NeWTJpsSj1RwEy6X0pDi1jHKfH7aPqbzzN6ac+9LVh4FgZ/JJxjXJvokDU++DxEef9To0UUuOK2eWhOaYC5V+nDypcKCz4hZax9jHtOHFJNr9o0oPaPk4IE70+5TBu7/Tve3MSia52owxkiv3k4Y5cU5g/HIorrqo2tyK8rvIg==; 20:8jrEwOEywQbV0X94rRaY43SW6t7gsyTVVNDIyhhSUjBDfjWtiQihTjR+BGWq8PXDfmORAbCN5ZJa/18FtCLzd4QlGajjRE6MFS/HmcLPR1+zea/737Lw1coOMLPVP80e1Z6suIVspBOGTJImxn9eOR/aURyVrvc7gqmeMLWST2Hli18IugQtVRjrDZoGehwLzd95qGQjZ6EPDzu2g3wy2dIL3x/JJzyn+Joyk7U/av8AfFV+Dtb4aaLXDj324Q29y2OojsEx2jOJB3Kc9T6b+ELn/Xu11dSQQXxfNHt3G4fuiEpzUepcIqd91zmHIIv/ixRvMMRke8Q3R4UWq6jmu3z81O2vLN6n/Z2JWiZxXGDIuN16ENLZ0gv1MrANe2Bm7FNDnWsXwRgQjAExdER8IH/njEq6ItpBB8Vfh4TuqSIN7etuOE813Jfhw4dD72dUsIh8aKbP7H7ZOh8KmcrgxuhLWpXoSt5qexFo8a4P+nMfBzwZZJZlRV7OA5flZcAkx86v8Z9b8e5cnr3PZT9zKmge08Ifhp/KxjYnHC04G2ZR/0mhJPG6R4/vyfGBji/c/T/mRfjybRPXA9Bum4yNTrblC484NRAX4qpHuoZqPbs= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(192374486261705); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(20161123555025)(20161123558025)(20161123562025)(20161123564025)(6072148); SRVR:CY1PR05MB2507; BCL:0; PCL:0; RULEID:; SRVR:CY1PR05MB2507; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 4:TCGk7LXPmFt8+sVQY0LLbIUYL4leBcFfxOX5azvpozAMKcY7A6xKbT6Vo4qUEidbdM0rKgEs1EZuaWL31Ie2GqRqAvFTUfRdvVVrbLkcWEhNYQi9FbMggE5hYwpd2dQi9CNsAXXZsLkxrhPU7G1ecodWDIqtfjbMsx8HWaWLLq4Sp3SOi6eURjh2KO93cOYwwnirOJ1UjVZw3usuiBkA+03WcT6hxqCstraaZmzgbv9oQ83LZkf13NLsOa1xB+cZqZMudom2mEnJ4V326Iel/XiPTULBZSaCh3nL4f2X2TsfxH0F4uW7nkpSPRPS/HPRMN92Vto4DQcVvHu2ddSZUQ0TxnqqtlnIaQ8aFd4LmsRORbTf6YjYv2UqzuousiOeajCQ4OKEr113WJruKVmNlE0CeToVQ4EgRvbQ8NYCiL1plfWNn/ej/xBZ6pO83L3PMlcLPRen9Zxihr29+ODzhnh0FnwgnkebRMxNDXSEKelrjUzcK3aCeWEodXOsL8FJZ0780BCEUFVMP8ZVYjYCNYHiI5+J1P8gH1SeUg5zyCgfYM9gnq+Jq2h2g+qSTGKh2s5PeawEnW3bfuIQ56j2r9QTWAqUafFigjzXw4bXudMuToIBL9qn08iTmgOkudJl1MTqOWsoCGS6rwUu4Jh+tf7rtcsiGJVtsjZJNtVnYd0= X-Forefront-PRVS: 02426D11FE X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(39840400002)(39860400002)(39450400003)(39410400002)(39850400002)(24454002)(377454003)(110136004)(38730400002)(42186005)(229853002)(53936002)(7736002)(8676002)(966004)(53416004)(6116002)(305945005)(6246003)(81166006)(54906002)(6306002)(4326008)(15188155005)(36756003)(8746002)(53546006)(6512007)(6486002)(50466002)(2906002)(66066001)(47776003)(2950100002)(6916009)(23746002)(6666003)(25786008)(6506006)(50226002)(189998001)(7416002)(3846002)(33656002)(76176999)(50986999)(86362001)(5660300001)(16799955002)(42262002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2507; H:dhegde-sslvpn-nc.jnpr.net; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; CY1PR05MB2507; 23:AxZUQSVlA5HLSRB9nlLR+P8b7UDRkqXJGybam?= =?Windows-1252?Q?svfdOAcHLNqcuP19RC6tBB+IA7dSgIGFKpw29+AvW3eiZyy3UIwaKveP?= =?Windows-1252?Q?3GBvUPr5O6i4BuaFS3ljtBcMGusAMePrcwyIwYn5/3psXVN2ZdBHMxL1?= =?Windows-1252?Q?TTZ7nCtlPK6j3H/s+eCi492UbPLUK5TUe8FoJnbI4v5j8YqVtpxR13Ue?= =?Windows-1252?Q?0GTOPfZmxKUqivIHBLtsOUGRY2pybqC+o68HvSo09x26d5X7Ir7DVyMt?= =?Windows-1252?Q?RP9kx1HTDYQ8+YgGfpAfIQfjjBOeNrywCnnahvn5goIQzKsSowtPvQ34?= =?Windows-1252?Q?fZzUP4H2bMOX1ZiDEpU/4ZZdT7sJbyTXyXg6fC4S0BG092l/4m4vpaz0?= =?Windows-1252?Q?UV2mvLCWOD484GdUbJfXQ/fWI1YipgKXyDXpY4qq69Iu4AFW1k7ZQFNx?= =?Windows-1252?Q?yybSpk0n0+DQH510xET+h/TzhluYgJ1d0A1jsEuaCFV8ugIjsW8iqpxy?= =?Windows-1252?Q?ZE2whY+mw2oqXdIwP+df8pDhZfCb3gwpMoe2LbkjW8UbpHkSp9jjzXJ9?= =?Windows-1252?Q?5a0N6WUsu1cvvfOLOqB1ApCvRRpBTkCL0WrZ5OEpW/aWKiIuM0DlJSV+?= =?Windows-1252?Q?Gv7MYVYEseYEZRdtqpX5aFK5djczp5Px7PpUjsaXbIObOm5IxJJS8i2a?= =?Windows-1252?Q?pIgDBDhSXTyA6aJdaxCvA17BMlYaj1avRQgsyeop5QriIlfqA+8XM2mP?= =?Windows-1252?Q?OzjgUEFMq0EJfejdfDm4ptebN4Nb9fFyD5StJ+PAbQ18xUZUEX/g96zk?= =?Windows-1252?Q?vja5D96a4wmfVq0lR1Au7FLSVL0fw7DRGizRa2pfxHxMPEop3msR8ZET?= =?Windows-1252?Q?650UGhxukl3gJxqZXjp8cB/2xc5JSu4yAEsubl5KAReGkv9sRyVl6n9S?= =?Windows-1252?Q?7FxMmlYAbkt7fsZnZChlX7spaz03Jyvm6pptVhhSKzc2t1DE5yeSQQ+o?= =?Windows-1252?Q?A8ExqqycmdGRHWH2mQpZKHtzXTGxniurrO+kvQmwxqR+zR3th8fHLMxd?= =?Windows-1252?Q?0inTYpY/hR7kA+mEz9SvisIwesxcUNViOfNAKILGB/YPgy7gAaiU43R3?= =?Windows-1252?Q?CJRyYIy2JRsXLFXFulgImPVldZa5WW7y/rnf7O1gvkJ7+6ZTLPI5pYmf?= =?Windows-1252?Q?HNIW3oEVH6Aq9DZcs8x4zmUQo9ph9tvypxsVB6rwF1uA3bBzyUvNjm+p?= =?Windows-1252?Q?j82BFA06HgLKKSFP/nFcTQL+spZt84/2c9QHJpDQVHv6Iac0TkCA9mCT?= =?Windows-1252?Q?fh2isVJoScblLFPc5rLCKt4eyOkgY8z1UBaBUbSDZ+x8MblJOiWwtaU+?= =?Windows-1252?Q?/4XVPCm7j7UWC8tpvmmIkd3b90qWSWoRw=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 6:ta06YQZjZM9CUpmDykJBiRJfDO7M/QXdyDCMgHa0SC/NJAcJhRL9irITTzLSsT+iu5Y+CBNy04U8LnCaZeMWBDwvvPeACZ/kZ1FPKdQufyo9MYhhrkNNzikCpososuVCtLvbVngDG7e+wFq0TZ8Ny+QPDYbU2DN+TAd/Aaqw34gdn9fCF+IrjJlAR5Tqgl8MkRqhcWnvdBW8I3Dq/MFGn/+WIIPecXE2R3pUzjRLxPiwu53k/aXS1PKeRUBZ5E37VV35S462XzwN+DnCPt0N6EX3NV1WPX4KACFQnyv2w8ypPcwiUHTQgu6UP3Xpzghurs2fKoghbqkHgAMJn19bB4j/91vBpVMC3Pegb/GAOeyYOyieTpWXPn+ISE0Bfx5P5vTdVtKg/YDRXz0dmDM34A2D855Fk3MEjk4hS4F+z4A=; 5:qK8zhQgeFRYSkTTiMC/39XtvTB87GOaDuGocW8PBypf+30XjSaWw9XsHOxBV5d+JT7Hvy3C8uxk460vPpI8aLpx9rpJmkdc8JGypsnNIwbMWgE5SxVRJ2C0SDKQyFiW4KBey22l+ayDvNjewEr6rGw==; 24:wNys09IhZZE3q0im8WKCaNTq9SnU1N6KweKVJI0OXpTfqGaI0bcw4x9E1mly4r8AAr0PnAOcVSIGHELX5+iYMDq5FZBL3/Lc/WxINKh2JjE= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 7:op8G4x+KVhrDrv3oQDK3Xc/zjDZlIshvrVLT+GodpvGWtQn15V/cZohzRvCHUgDqaIznYVZLG2DKDrvcQw2GPJW8u+WtrnPzh9YPOR3CgfEEEsYshy5NqhkGx0BTP0/fe7tRGdEVg8jGmPLm5HyDUU3d/XP1dHF2A0Pyuo19RAcfbBLuXSXwNngFJ7p1Vq/gTS2FMipxBTQYWAWTJdSXxeDOPBrMxU49POhB7KGuBMr4DLu21PZvAAmFBzpKWg/YZ8Qfw7tTTW4MWB/d9yPk4LJ4qQEXpvg0SA3y9JOf+qpF5HbWvRYVDPP/o4iDvvK/fktcB1kDLaEo6ijQ/kvZMQ== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Mar 2017 19:53:01.6084 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2507 Archived-At: X-Mailman-Approved-At: Fri, 10 Mar 2017 12:01:44 -0800 Cc: idr@ietf.org, nick@inex.ie, nmalykh@gmail.com, keyur@arrcus.com, shares@ndzh.com, RFC Errata System Subject: Re: [Idr] [Editorial Errata Reported] RFC8092 (4962) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 19:53:06 -0000 That's neither the intent (AFAICT) or the effect (for sure) of the = erratum. The sole change proposed is to change "Community" to = "Communities" in one instance of the name of the attribute, which as = Alvaro points out just harmonizes the text with 13 other occurrences in = the RFC. I'm not so sure I agree with Alvaro that the case for the change is = open-and-shut -- although he's right there are various other = occurrences, there are also two other occurrences of the singular = "Community" in the security section. If we're actually going to pick = this nit, shouldn't the erratum cover all of them? Although in one case, = changing to the plural would make the text exceedingly awkward. I for one would support letting sleeping dogs lie, but whatever. --John > On Mar 9, 2017, at 5:35 PM, Ignas Bagdonas = wrote: >=20 > Hi there, >=20 > If the intention of the errata is to address the handling of = duplicated large community attributes (i.e., multiple type 32 attributes = present in UPDATE message) then it does not seem to be right. RFC7606 = does not allow to have more than one meaningful attribute of the same = type in a single UPDATE message, therefore the literal interpretation of = "BGP Large Communities" attribute does not apply as only the first such = attribute gets interpreted and all subsequent ones get ignored. RFC8092 = has both singular and plural form of term "large community" values used = in different contexts, referring to either a single 12 octet large = community value or to a whole large communities attribute. >=20 >=20 > Ignas >=20 >=20 > On 09/03/2017 15:21, RFC Errata System wrote: >> The following errata report has been submitted for RFC8092, >> "BGP Large Communities Attribute". >>=20 >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=3D8092&eid=3D4962 >>=20 >> -------------------------------------- >> Type: Editorial >> Reported by: Nikolai Malykh >>=20 >> Section: 3 >>=20 >> Original Text >> ------------- >> Duplicate BGP Large Community values MUST NOT be transmitted. A >> receiving speaker MUST silently remove redundant BGP Large = Community >> values from a BGP Large Community attribute. >>=20 >>=20 >> Corrected Text >> -------------- >> Duplicate BGP Large Community values MUST NOT be transmitted. A >> receiving speaker MUST silently remove redundant BGP Large = Community >> values from a BGP Large Communities attribute. >>=20 >>=20 >> Notes >> ----- >> Typo >>=20 >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party >> can log in to change the status and edit the report, if necessary. >>=20 >> -------------------------------------- >> RFC8092 (draft-ietf-idr-large-community-12) >> -------------------------------------- >> Title : BGP Large Communities Attribute >> Publication Date : February 2017 >> Author(s) : J. Heitz, Ed., J. Snijders, Ed., K. Patel, I. = Bagdonas, N. Hilliard >> Category : PROPOSED STANDARD >> Source : Inter-Domain Routing >> Area : Routing >> Stream : IETF >> Verifying Party : IESG >=20 From nobody Fri Mar 10 12:36:49 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 601071294EF for ; Fri, 10 Mar 2017 12:36:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EhNAApApx-AK for ; Fri, 10 Mar 2017 12:36:46 -0800 (PST) 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 1C0041294DA for ; Fri, 10 Mar 2017 12:36:45 -0800 (PST) X-Envelope-To: idr@ietf.org Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id v2AKafh8035994 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Mar 2017 20:36:42 GMT (envelope-from nick@inex.ie) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local Message-ID: <58C30E59.5080003@inex.ie> Date: Fri, 10 Mar 2017 20:36:41 +0000 From: Nick Hilliard User-Agent: Postbox 5.0.11 (Macintosh/20170302) MIME-Version: 1.0 To: "John G. Scudder" References: <20170309152156.5956BB80EB2@rfc-editor.org> <0be5014c-4145-6430-2b3c-14b2beb8d153@gmail.com> In-Reply-To: X-Enigmail-Version: 1.2.3 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=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: idr@ietf.org, nmalykh@gmail.com, RFC Errata System Subject: Re: [Idr] [Editorial Errata Reported] RFC8092 (4962) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 20:36:48 -0000 John G. Scudder wrote: > I'm not so sure I agree with Alvaro that the case for the change is > open-and-shut -- although he's right there are various other > occurrences, there are also two other occurrences of the singular > "Community" in the security section. If we're actually going to pick > this nit, shouldn't the erratum cover all of them? Although in one > case, changing to the plural would make the text exceedingly > awkward. "Community" vs "communities" was discussed at length during the authorship process, and the term "language torture" was used in relation to this specific point. The root problem is that 1997 conflated the two terms and we're left with an ambiguity about which term means what. > I for one would support letting sleeping dogs lie, but whatever. Please let's do this; the meaning is clear. If there is a future revision, it can be changed. Nick From nobody Fri Mar 10 20:26:05 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B42D7129447 for ; Fri, 10 Mar 2017 20:26:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jok6fKIKKtCy for ; Fri, 10 Mar 2017 20:26:02 -0800 (PST) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::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 B6F051293F8 for ; Fri, 10 Mar 2017 20:26:01 -0800 (PST) Received: by mail-wm0-x231.google.com with SMTP id v186so7944821wmd.0 for ; Fri, 10 Mar 2017 20:26:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=WiwoFIxGZx5OVXpmX4yNnU3PyDAu7N5gmYHxxyOm/1U=; b=QBXyG7D5TJ1nkRkroYpFZkztSuiusUIp3TZFMTX0bbrmhKNPYZSXm23KETSBsoA5qR hH9Thi5C6z8cM5hNu1sS6kpdWkPWMyG26tTNNwSON7CsXEcBBXGkOmrGqjRQnazpEYHn aLkB3VmlJCDaHJDo+R4xIiM7NKhdGCWyXzv313+BPk0PDTaQUFK7Mp0g7giSmqAfBgU4 JaAGhIrgIZjIBHxSKe2LVICePK973joqg6ZNc8ugGUTd3fU95TuB57XZhTwFEPxJ8Qg4 Z+ElhwerFnwNt9KSI3oQAGSPeuKCqLSo0S+svrOzGppy90+8mU6PhiIQgygbyrP3l5XE 2U8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=WiwoFIxGZx5OVXpmX4yNnU3PyDAu7N5gmYHxxyOm/1U=; b=lvIIQScBAfOoTfNtuCI7wPBZi2PO6IoQ/jBVSDLWnp9qXiMOy9TYmowoHxNXl8wPGC MO22LuouaDam/RMQwi0F+hQ0ShMkKAnxsMkjK59nAEkxE6RrvR/Jkq9GuI4QnXiC0pw5 yeoMU9SaTY53l2wmYfb/mVLJcGuRdkxZn0VjQtwdLORItZjATn1uKOSekrrNebJp3mr7 ZI/VaU4KiKdB7CcCa33QO6JG3my309brt/hDvGbEmLOV1KH+qdfSf0c6Z6L/zU8YH9vq ByPgxAkIRU+hIf+uBeomQ9jQLzRqob31H8WZtHcqldwC7ioT08TwpW/y/jW7h+fYCyzQ ZpKw== X-Gm-Message-State: AFeK/H12lv8RDs9u1yc+W/bFIo+U4IjfVndd7bvmAjzCoOWHqdfR6u14gt/45VysUlIHKIiUhOp5zLv3MmAczQ== X-Received: by 10.28.105.92 with SMTP id e89mr1477291wmc.93.1489206360076; Fri, 10 Mar 2017 20:26:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.169.132 with HTTP; Fri, 10 Mar 2017 20:25:19 -0800 (PST) From: Tony Przygienda Date: Fri, 10 Mar 2017 20:25:19 -0800 Message-ID: To: idr wg Content-Type: multipart/alternative; boundary=001a114788de16fa52054a6ce028 Archived-At: Subject: [Idr] New beside-reading draft for the IDR aficionado ... X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Mar 2017 04:26:04 -0000 --001a114788de16fa52054a6ce028 Content-Type: text/plain; charset=UTF-8 Posted, comments welcome: https://datatracker.ietf.org/doc/draft-przygienda-idr-compressed-updates/ thanks --- tony --001a114788de16fa52054a6ce028 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Poste= d, comments welcome:

<= br>
thanks=C2=A0

--- tony=C2=A0
--001a114788de16fa52054a6ce028-- From nobody Fri Mar 10 23:33:50 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A18A21295CD for ; Fri, 10 Mar 2017 23:33:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OuCjhK1Bs1Jf for ; Fri, 10 Mar 2017 23:33:47 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E7CE1295C8 for ; Fri, 10 Mar 2017 23:33:47 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DIR35455; Sat, 11 Mar 2017 07:33:45 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.301.0; Sat, 11 Mar 2017 07:33:43 +0000 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.160]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Sat, 11 Mar 2017 15:33:39 +0800 From: "Dongjie (Jimmy)" To: idr wg Thread-Topic: IETF98 agenda topics Thread-Index: AdKaOZ0k0vmUEiqeSiKyMVPekGCYxg== Date: Sat, 11 Mar 2017 07:33:38 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C927935B96C0@NKGEML515-MBS.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.110.81] Content-Type: multipart/alternative; boundary="_000_76CD132C3ADEF848BD84D028D243C927935B96C0NKGEML515MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.58C3A859.006D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.160, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 5a94c75be9a623cba389a30712cc421b Archived-At: Cc: Susan Hares Subject: [Idr] IETF98 agenda topics X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Mar 2017 07:33:49 -0000 --_000_76CD132C3ADEF848BD84D028D243C927935B96C0NKGEML515MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, IDR will meet at IETF98 on Friday, March 31 from 9:00 to 11:30. Please forw= ard any IDR agenda items you might have to me and CC the chairs, the deadli= ne is March 17 by 10:00 U.S. Eastern Time. Priority will be given to those = who get their requests in by the deadline, though if agenda space permits i= t we will consider requests gotten in before March 22 at 10:00 U.S. Eastern= Time. Please include the name of the person who will be presenting, and th= e estimate time you'll need (including Q/A). If you plan to make a presentation, please keep in mind the IDR tradition, = "no Internet Draft - no time slot". You should also plan to send your slide= s to me and CC the chairs no later than 24 hours prior to the meeting, thou= gh earlier is better. If we don't have your slides by the deadline, you may= lose your slot. Please number your slides for the benefit of remote attend= ees. If you plan to use any fancy builds or transitions you must arrange th= is with us in advance -- otherwise you should assume your slides may be con= verted to PDF and presented from the PDF. Potential presenters, please take a look at the checklist for presenting at= IDR: https://trac.tools.ietf.org/wg/idr/trac/wiki/Checklist%20for%20presenting%2= 0at%20an%20IDR%20meeting Best regards, Jie --_000_76CD132C3ADEF848BD84D028D243C927935B96C0NKGEML515MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 

IDR will meet at IETF98 on Frid= ay, March 31 from 9:00 to 11:30. Please forward any IDR agenda items you mi= ght have to me and CC the chairs, the deadline is March 17 by 10:00 U.S. Ea= stern Time. Priority will be given to those who get their requests in by the deadline, though if agenda space pe= rmits it we will consider requests gotten in before March 22 at 10:00 U.S. = Eastern Time. Please include the name of the person who will be presenting,= and the estimate time you'll need (including Q/A).

 

If you plan to make a presentat= ion, please keep in mind the IDR tradition, "no Internet Draft - no ti= me slot". You should also plan to send your slides to me and CC the ch= airs no later than 24 hours prior to the meeting, though earlier is better. If we don't have your slides by the deadline, yo= u may lose your slot. Please number your slides for the benefit of remote a= ttendees. If you plan to use any fancy builds or transitions you must arran= ge this with us in advance -- otherwise you should assume your slides may be converted to PDF and presented from t= he PDF.

 

Potential presenters, please ta= ke a look at the checklist for presenting at IDR:

https://trac.tools.ietf.org/wg/idr/trac/wiki/Checklist%20for%20presen= ting%20at%20an%20IDR%20meeting

 

Best regards,=

Jie

--_000_76CD132C3ADEF848BD84D028D243C927935B96C0NKGEML515MBSchi_-- From nobody Sat Mar 11 06:32:53 2017 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EEF3127077; Sat, 11 Mar 2017 06:32:51 -0800 (PST) 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.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148924277112.2960.17904473852401253352@ietfa.amsl.com> Date: Sat, 11 Mar 2017 06:32:51 -0800 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Mar 2017 14:32:51 -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 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-02.txt Pages : 14 Date : 2017-03-11 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 a newly defined BGP SAFI 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-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-rs-bfd-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Mar 11 07:17:12 2017 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 83FBB129479; Sat, 11 Mar 2017 07:17:07 -0800 (PST) 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.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148924542752.2884.13750476757955011040@ietfa.amsl.com> Date: Sat, 11 Mar 2017 07:17:07 -0800 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-flowspec-interfaceset-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Mar 2017 15:17:07 -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 of the IETF. Title : Applying BGP flowspec rules on a specific interface set Authors : Stephane Litkowski Adam Simpson Keyur Patel Jeff Haas Lucy Yong Filename : draft-ietf-idr-flowspec-interfaceset-03.txt Pages : 15 Date : 2017-03-11 Abstract: BGP flowspec is an extension to BGP that allows for the dissemination of traffic flow specification rules. The primary application of this extension is DDoS mitigation where the flowspec rules are applied in most cases to all peering routers of the network. This document will present another use case of BGP flowspec where flow specifications are used to maintain some access control lists at network boundary. BGP flowspec is a very efficient distributing machinery that can help in saving OPEX while deploying/updating ACLs. This new application requires flow specification rules to be applied only on a specific subset of interfaces and in a specific direction. The current specification of BGP flowspec ([RFC5575]) introduces the notion of flow specification (which describes the matching criterion) and traffic filtering actions. The flow specification is encoded as part of the NLRI while the traffic filtering actions are encoded as extended communities. The combination of a flow specification and one or more actions is known as a flow specification rule. [RFC5575] does not detail where the flow specification rules need to be applied. Besides the flow specification and traffic filtering actions, this document introduces the notion of traffic filtering scope in order to drive where a particular rule must be applied. In particular, this document introduces the "interface-set" traffic filtering scope that could be used in parallel of traffic filtering actions (marking, rate-limiting ...). The purpose of this extension is to inform remote routers about groups of interfaces where the rule must be applied. This extension can also be used in a DDoS mitigation context where a provider wants to apply the filtering only on specific peers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-interfaceset/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-flowspec-interfaceset-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-flowspec-interfaceset-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Mar 12 09:11:26 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8C3E129499; Sun, 12 Mar 2017 09:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6SYpRcJnm2CM; Sun, 12 Mar 2017 09:11:16 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0128.outbound.protection.outlook.com [104.47.41.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 5E68E129491; Sun, 12 Mar 2017 09:11:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=dG0E4+kg2GhWhblH5lG1gFmjEkYb+TM+u/iGt44DE18=; b=ZhIF9LL0TRzv2NgKNeRcWC8yZG0DQaK0uCiYIFiVOmqw+4mBHeoOLJF9WyiHZsavXFXcCCsurS9DihjJRtq+NyLsET3CPzsax8u+Kz635TQMdbcgi2ELH9F2PLoMVed79jQZ/9StNQxIHssZEobZ1epO+ovMUs+uoZd8YNDfqq8= Received: from BLUPR0501MB2051.namprd05.prod.outlook.com (10.164.23.21) by BLUPR0501MB2052.namprd05.prod.outlook.com (10.164.23.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.977.5; Sun, 12 Mar 2017 16:11:14 +0000 Received: from BLUPR0501MB2051.namprd05.prod.outlook.com ([10.164.23.21]) by BLUPR0501MB2051.namprd05.prod.outlook.com ([10.164.23.21]) with mapi id 15.01.0977.008; Sun, 12 Mar 2017 16:11:14 +0000 From: Ron Bonica To: Susan Hares , "EXT - luis.tomotaki@verizon.com" , 'Shitanshu Shah' , "rtg-dir@ietf.org" , "draft-ietf-idr-sla-exchange.all@ietf.org" , "idr@ietf.org" Thread-Topic: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 Thread-Index: AdKIcLCEU+uutt39QyCrZCwOKAXyLQAcLKCoAUVZnUABwWlZAABkf7iDAEubxBAAGLyHgADK0jWA Date: Sun, 12 Mar 2017 16:11:14 +0000 Message-ID: References: , <053401d294fc$6f739180$4e5ab480$@ndzh.com> <467340A77F13C944919805BFF3B8ACFC30DC040408@FHDP1LUMXC7V91.us.one.verizon.com> <011601d2981f$cfe364c0$6faa2e40$@ndzh.com> In-Reply-To: <011601d2981f$cfe364c0$6faa2e40$@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;ndzh.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.14] x-microsoft-exchange-diagnostics: 1; BLUPR0501MB2052; 7:DvZE6taJE1n8hI0n6PbLpxTAG54/j8OnDXVxYrr8fxODZd8DWLoQ1XWtTvqtWl58wFK2qNgatr2qjQ3u8CNDrUI2UwZ2WGGgZFAol0N7YL93d/LsL7X9eUrHlG4dc+DI0ZkcdhstdO+oi3p9IcqK8RmvVpqK2f9la41e202Fh48g1gPkGHCt2kzmAM7fFaFGhpAieL6NlX1VZtfRcfBhafxmVo7Nu8ZthDkDp1hZxz8I278qQENug9oz07GUMoX4zwL8Vg0rpHZKE/wqoyQofcGrZD1Dt67h3aPyd4r9Xn8UX1DguewWVcCwQ3bAtxBtBnDk7ngIHalE1BgcaxDkPQ== x-ld-processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr x-ms-office365-filtering-correlation-id: 92a87e72-eb5f-48be-dba1-08d469626899 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BLUPR0501MB2052; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(194151415913766)(21748063052155)(154440410675630); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123558025)(20161123564025)(20161123562025)(20161123560025)(20161123555025)(6072148); SRVR:BLUPR0501MB2052; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB2052; x-forefront-prvs: 0244637DEA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39850400002)(39410400002)(39450400003)(39840400002)(54094003)(377454003)(2501003)(6436002)(3846002)(93886004)(2900100001)(66066001)(33656002)(9686003)(790700001)(236005)(230783001)(2906002)(102836003)(6306002)(99286003)(6116002)(25786008)(53936002)(6246003)(38730400002)(54896002)(55016002)(5660300001)(2201001)(229853002)(86362001)(7736002)(74316002)(53546006)(6506006)(39060400002)(2950100002)(189998001)(122556002)(7696004)(77096006)(345774005)(50986999)(81156014)(76176999)(54356999)(81166006)(8936002)(3280700002)(3660700001)(8676002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB2052; H:BLUPR0501MB2051.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BLUPR0501MB205196DE5F8F24832FF94A31AE220BLUPR0501MB2051_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Mar 2017 16:11:14.7770 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB2052 Archived-At: Subject: Re: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 16:11:19 -0000 --_000_BLUPR0501MB205196DE5F8F24832FF94A31AE220BLUPR0501MB2051_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Luis, This discussion might require a slightly higher bandwidth channel. Feel fre= e to call me whenever you get a chance. Ron 571 203 1= 704 From: Susan Hares [mailto:shares@ndzh.com] Sent: Wednesday, March 8, 2017 10:23 AM To: EXT - luis.tomotaki@verizon.com ; 'Shitanshu= Shah' ; Ron Bonica ; rtg-= dir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; idr@ietf.org Subject: RE: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 Luis: Thank you for letting me know you desire for this feature. Since Ron had = additional questions, I'll let him start off this discussion. Sue From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Tomotaki, Luis M Sent: Tuesday, March 7, 2017 11:11 PM To: Shitanshu Shah; Susan Hares; 'Ron Bonica'; rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; idr@ietf.org Subject: Re: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 Ron and Sue, >From a service provider perspective, exchanging the SLA information between= the PE and CE would be very beneficial and could be widely used. I think = this is particular important in service provider's L3VPN networks where the= customers or service providers currently do not have full visibility to th= e QoS policy in the other end of the connection but still needs matching CE= -PE SLA/QoS policies to achieve the correct two-way traffic prioritization = behavior during congestion. In this example, once the SLA information exch= ange is standardized, my expectation is that the different CE/PE vendors wo= uld be able to automatically update in a vendor specific way, the SLA/QoS p= olicies based on the SLA information provided via BGP. Luis From: Shitanshu Shah [mailto:shitanshu_shah@hotmail.com] Sent: Monday, March 6, 2017 9:31 AM To: Susan Hares >; 'Ron Bonica' >; rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; idr@ietf.org Subject: [E] Re: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 Hi Sue, Following is what I had responded to Ron. Hopefully that addresses/clarifie= s. To break it down in two point response, 1) This draft is not changing how SLA is established at first place. The dr= aft is providing a method to convey this a priori established SLA to help r= educe lot of manual complexities and errors to admin. Thus given a knowledg= e of what SLA is established, in general devices should be capable to suppo= rt that established SLA. 2) If there still are any issues in implementing exchanged SLA in forwardin= g, we think they either are implementation specific or of temporary nature = where for example enough resources not available at any specific point of a= time. We feel that in current state of the draft, it can be largely useful in dep= loyments. One can imagine though even establishment of SLA also can be done via excha= nging it over bgp. However, negotiation of SLA does not have to be clubbed = with exchange of SLA. Negotiation of SLA is not in this scope. Regards, Shitanshu ________________________________ From: Susan Hares > Sent: Saturday, March 4, 2017 8:31 AM To: 'Ron Bonica'; 'Shitanshu Shah'; rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; idr@ietf.org Subject: RE: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 Shitanshu: Please address Ron's comment about widely deployed. I believe this was par= t of Alvaro's comments. Sue From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Ron Bonica Sent: Thursday, February 23, 2017 12:07 PM To: Shitanshu Shah; rtg-dir@ietf.org; draft-ietf-i= dr-sla-exchange.all@ietf.org; idr@ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 Hello, The draft is internally consistent. But given what is left out of scope, I = wonder if the new attributes will ever be widely deployed. = Ron This document might benefit from discussion of operational issues. I assume= that when a BGP listener learns a route with the SLA Exchange Attribute, i= t provisions class of service forwarding classes on interfaces. ##svshah, though this is one desired use of exchanging SLA content, the dra= ft focuses on transporting SLA content from the SLA Producer to the SLA Con= sumer. Processing of the QoS attribute content, at the SLA Consumer, is out= side the scope of this document. ##svshah, Let me know if you have a suggestion to make description clearer = in Section 1 and 2 to highlight this. I also assume that a) it takes time to provision class of service forwardin= g classes and b) the number of forwarding classes that can be provisioned a= re finite. What does the BGP listener do when the number of forwarding clas= ses requested exceeds its capacity to deliver? ##svshah, Since scope of the document is to transport SLA content from the = SLA Producer to the SLA Consumer, the document considers error handling in = the context of transporting data and thus any formating errors and semantic= s errors within that context. Any errors in the context of processing QoS a= ttribute content at the SLA Consumer is outside the scope of the document. --_000_BLUPR0501MB205196DE5F8F24832FF94A31AE220BLUPR0501MB2051_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Luis,

 

This discussion might require a sligh= tly higher bandwidth channel. Feel free to call me whenever you get a chanc= e.

 

      &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;        Ron

      &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;         571 203 1704

 

&nbs= p;

From: Susan Hares [mailto:shares@ndz= h.com]
Sent: Wednesday, March 8, 2017 10:23 AM
To: EXT - luis.tomotaki@verizon.com <luis.tomotaki@verizon.com>= ;; 'Shitanshu Shah' <shitanshu_shah@hotmail.com>; Ron Bonica <rbon= ica@juniper.net>; rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf= .org; idr@ietf.org
Subject: RE: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-excha= nge-10

 

Luis:

 

Thank you for letting me know you des= ire for this feature.   Since Ron had additional questions, IR= 17;ll let him start off this discussion.

 

Sue

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Tomotaki, Luis M
Sent: Tuesday, March 7, 2017 11:11 PM
To: Shitanshu Shah; Susan Hares; 'Ron Bonica'; rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; idr@ietf.org
Subject: Re: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-excha= nge-10

 

Ron and Sue,

From a service provider perspective, = exchanging the SLA information between the PE and CE would be very benefici= al and could be widely used.  I think this is particular important in service provider’s L3VPN networks where the = customers or service providers currently do not have full visibility to the= QoS policy in the other end of the connection but still needs matching CE-= PE SLA/QoS policies to achieve the correct two-way traffic prioritization behavior during congestion.  In this e= xample, once the SLA information exchange is standardized, my expectation i= s that the different CE/PE vendors would be able to automatically update in= a vendor specific way, the SLA/QoS policies based on the SLA information provided via BGP. 

 

Luis

 

From: Shitanshu Shah [mailto:shitanshu_shah@hotmail.com]
Sent: Monday, March 6, 2017 9:31 AM
To: Susan Hares <shares@ndzh.c= om>; 'Ron Bonica' <rbonica= @juniper.net>; rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; idr@ietf.org
Subject: [E] Re: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchang= e-10

 

H= i Sue,

<= o:p> 

F= ollowing is what I had responded to Ron. Hopefully that addresses/clar= ifies.

<= o:p> 

T= o break it down in two point response,

<= o:p> 

1= ) This draft is not changing how SLA is established at first place. The dra= ft is providing a method to convey this a priori established SLA = to help reduce lot of manual complexities and errors to admin. Thus given a knowledge of what SLA is established, in general devic= es should be capable to support that established SLA.

<= o:p> 

<= o:p> 

2= ) If there still are any issues in implementing exchanged SLA in forwarding= , we think they either are implementation specific or of temporary nat= ure where for example enough resources not available at any specific point of a time.

<= o:p> 

W= e feel that in current state of the draft, it can be largely useful in depl= oyments.

<= o:p> 

<= o:p> 

<= o:p> 

O= ne can imagine though even establishment of SLA also can be done via e= xchanging it over bgp. However, negotiation of SLA does not have to be club= bed with exchange of SLA. Negotiation of SLA is not in this scope.

<= o:p> 

Regards,

Shitanshu

 <= /p>

From: Susan = Hares <shares@ndzh.com>
Sent: Saturday, March 4, 2017 8:31 AM
To: 'Ron Bonica'; 'Shitanshu Shah'; rtg-dir@ietf.org; draft-ietf-idr-= sla-exchange.all@ietf.org; idr@ietf.org
Subject: RE: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10=

 

Shitanshu:

 

Please address Ron’s comment about widely dep= loyed.  I believe this was part of Alvaro’s comments.

 

Sue

 

From: rtg-dir [mailto:rtg-dir-bounces@ietf.o= rg] On Behalf Of Ron Bonica
Sent: Thursday, February 23, 2017 12:07 PM
To: Shitanshu Shah; rtg-dir@ietf= .org; draft-ietf-idr-= sla-exchange.all@ietf.org; idr@ietf.org
Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10=

 

Hello,

 

The draft is internally consistent. But given what = is left out of scope, I wonder if the new attributes will ever be widely deployed.

 

        &nb= sp;            =             &nb= sp;            =             &nb= sp;            =          Ron

 

 


This document might benefit from discussion of operational issues. I assume= that when a BGP listener learns a route with the SLA Exchange Attribute, i= t provisions class of service forwarding classes on interfaces.

 <= /span>

##svshah, = though this is one desired use of exchanging SLA content, the draft focuses= on transporting SLA content from the SLA Producer to the SLA Consumer. Pro= cessing of the QoS attribute content, at the SLA Consumer, is outside the scope of this document.<= /span>

 

##svshah, = Let me know if you have a suggestion to make description clearer in Section= 1 and 2 to highlight this.

 <= /span>

 <= /span>

I also assume that a) it takes time to provision clas= s of service forwarding classes and b) the number of forwarding classes that can be provisioned are finite. What does the BG= P listener do when the number of forwarding classes requested exceeds its c= apacity to deliver? 

 <= /span>

##svshah, = Since scope of the document is to transport SLA content from the SLA Produc= er to the SLA Consumer, the document considers error handling in the contex= t of transporting data and thus any formating errors and semantics errors within that context. Any errors in t= he context of processing QoS attribute content at the SLA Consumer is outsi= de the scope of the document.

 

 <= /span>

 <= /span>

--_000_BLUPR0501MB205196DE5F8F24832FF94A31AE220BLUPR0501MB2051_-- From nobody Sun Mar 12 19:36:25 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF478129436 for ; Sun, 12 Mar 2017 19:36:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2Le-Jn5h58A for ; Sun, 12 Mar 2017 19:36:23 -0700 (PDT) Received: from SNT004-OMC1S26.hotmail.com (snt004-omc1s26.hotmail.com [65.55.90.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 737D71293F5 for ; Sun, 12 Mar 2017 19:36:23 -0700 (PDT) Received: from APC01-PU1-obe.outbound.protection.outlook.com ([65.55.90.9]) by SNT004-OMC1S26.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Sun, 12 Mar 2017 19:36:22 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Q402fF9LWbslP2s/NDNbCTvVisKUgwNCF5DyaoCRUc8=; b=CTmlchHCI67Yg0Oj+WVkpF+6PTF8AtOokbrwF72mfT1oBDRh4J7EZXK4D9nfiNvqjNoQUL4uH10o+nSRxyiewt+rmGav34jpLikp4WcUw09otmybTAJqQXyipto7/WjGA7LFHdLG+CYKR1XvApViea5Tx7/IoTx/UkA23uPqrk85hnZAA0+8aUJgYqNfd37fZjVwFwO11vRz/6hMLUHX1UsMoTedlQ85cYi1SUpP0o6uwZTNOqfB9PwWuzdcKBrSo8tQlu9CFFh4nmHHpSm9OIGvhn7uJW/yW6yPxNH5Kc9BmRbOpSF9KIF9par1+ikK6rYBRIj26NTr3NgC9Zo2ww== Received: from PU1APC01FT008.eop-APC01.prod.protection.outlook.com (10.152.252.59) by PU1APC01HT167.eop-APC01.prod.protection.outlook.com (10.152.253.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.7; Mon, 13 Mar 2017 02:36:19 +0000 Received: from HK2PR0601MB1361.apcprd06.prod.outlook.com (10.152.252.55) by PU1APC01FT008.mail.protection.outlook.com (10.152.252.66) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.7 via Frontend Transport; Mon, 13 Mar 2017 02:36:19 +0000 Received: from HK2PR0601MB1361.apcprd06.prod.outlook.com ([10.165.182.19]) by HK2PR0601MB1361.apcprd06.prod.outlook.com ([10.165.182.19]) with mapi id 15.01.0947.023; Mon, 13 Mar 2017 02:36:19 +0000 From: li zhenqiang To: idr Thread-Topic: new doc announcement: Populate to FIB Action for FlowSpec Thread-Index: AQHSm6KYElig7qoIwkyep/WB5bpnbg== Date: Mon, 13 Mar 2017 02:36:19 +0000 Message-ID: Accept-Language: zh-CN, 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;ietf.org; dmarc=none action=none header.from=hotmail.com; x-incomingtopheadermarker: OriginalChecksum:62AFC98981F3F5D2B104DAFB25C967E75F7519B690B42578BE801A5FBA06BEEB; UpperCasedChecksum:F695A5C6F229A7786B6BB3BC521C22B3A9EF6A62177413974710461AF06BF275; SizeAsReceived:7465; Count:34 x-ms-exchange-messagesentrepresentingtype: 1 x-incomingheadercount: 34 x-eopattributedmessage: 0 x-microsoft-exchange-diagnostics: 1; PU1APC01HT167; 5:sjChI0gXrumd77cTL3c0/E3pe1GWGw6XKUmxmATRQ5Hhgu/lvZMMI+oU79nuoTwE2Qc57ApWi9rJOIVunMSDeqOVQb0Zu9UHeTG6WHhnlJQCqKrvYOzpkbysbepWeTtFnSVcVwVzepRSGCvkfusOmA==; 24:UjJVajIKEGs8hjpASVwRjB3mUpVeePltyfryceVrobaZojnEmJa+qfPV1M3iPzeL20rOvbvrO+cSWRMDpCAwfoov7aLCYVLwOs8ZItpSAeg=; 7:wJcNdS1I3WIW4H+dQy/jdBzoda2XD2Qo1uQja9r7Ka1S5Vy2nKU3BghfGusFytjN2MAVUuYNBcGPU0BwAtwvXDtLAAylOWKs6+dTT5WwyWyzHDQV/gbnGr8zrlm5FcKeixMMpLYhnsn5x/MOz9stHzKoxKGAdFSCX/ve4TcTVC15DShLCravdmIE6+Lz0YtONczxQVdS2uxTq+n0BbCnPYK+F9C+Km+W9AGYXLKqTGv0QPQyMrjpd3Go80tUleRlnMozfF5tc0GZaE2KgNOoH+QNlUaK378NfSysFGo7xrjZU6bjvYi5QIOHDpoV68La x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(10019020)(98900016); DIR:OUT; SFP:1102; SCL:1; SRVR:PU1APC01HT167; H:HK2PR0601MB1361.apcprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; x-ms-office365-filtering-correlation-id: 065e4413-631c-44bd-3b97-08d469b9b98b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201702061074)(5061506573)(5061507331)(1603103135)(1601125254)(1603101448)(1701031045); SRVR:PU1APC01HT167; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(432015087)(444000031); SRVR:PU1APC01HT167; BCL:0; PCL:0; RULEID:; SRVR:PU1APC01HT167; x-forefront-prvs: 0245702D7B spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_HK2PR0601MB1361F01123946AF8F40A16D8FC250HK2PR0601MB1361_" MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Mar 2017 02:36:19.5578 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: PU1APC01HT167 X-OriginalArrivalTime: 13 Mar 2017 02:36:22.0557 (UTC) FILETIME=[9A7594D0:01D29BA2] Archived-At: Subject: [Idr] new doc announcement: Populate to FIB Action for FlowSpec X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 02:36:24 -0000 --_000_HK2PR0601MB1361F01123946AF8F40A16D8FC250HK2PR0601MB1361_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBXRyBtZW1iZXJzLA0KDQpBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBzdWJtaXR0ZWQgdG8g SURSIHdvcmtpbmcgZ3JvdXAuIEl0cyBpbmZvcm1hdGlvbiBpcyBzaG93biBiZWxvdy4gWW91ciBj b21tZW50cyBhcmUgd2VsY29tZS4NCg0KICAgICAgICBUaXRsZSAgICAgICAgICAgOiBQb3B1bGF0 ZSB0byBGSUIgQWN0aW9uIGZvciBGbG93U3BlYw0KICAgICAgICBBdXRob3JzICAgICA6IFpoZW5x aWFuZyBMaQ0KICAgICAgIEZpbGVuYW1lICAgIDogZHJhZnQtbGktaWRyLWZsb3dzcGVjLXBvcHVs YXRlLXRvLWZpYi0wMA0KICAgICAgIERhdGUgICAgICAgICAgICA6IDIwMTctMDMtMTENCiAgICAg ICBBYnN0cmFjdCAgICAgIDogQSBiaXQsIEYgYml0LCBpcyBkZWZpbmVkIGluIHRyYWZmaWMgYWN0 aW9uIGV4dGVuZGVkIGNvbW11bml0eSwgd2hpY2ggaXMgdXNlZCBieSBGbG93U3BlYyB0byBpbmRp Y2F0ZSB0aGUgYXNzb2NpYXRlZCBzcGVjaWZpY2F0aW9ucyBiZQ0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBpbnN0YWxsZWQgZGlyZWN0bHkgaW4gRklCIChGb3J3YXJkaW5nIEluZm9ybWF0 aW9uIEJhc2UpLg0KICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWxpLWlkci1mbG93c3BlYy1wb3B1bGF0ZS10by1maWIvDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpsaV96aGVucWlhbmdAaG90bWFpbC5jb20NCg== --_000_HK2PR0601MB1361F01123946AF8F40A16D8FC250HK2PR0601MB1361_ Content-Type: text/html; charset="utf-8" Content-ID: <04854CBFAB4BBB4DBDE5FC2B2F529820@apcprd06.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT5ib2R5IHsgbGluZS1oZWlnaHQ6IDEu NTsgfWJvZHkgeyBmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IOW+rui9r+mbhem7kTsg Y29sb3I6IHJnYigwLCAwLCAwKTsgbGluZS1oZWlnaHQ6IDEuNTsgfTwvc3R5bGU+DQo8L2hlYWQ+ DQo8Ym9keT4NCjxkaXY+PHNwYW4+PC9zcGFuPkRlYXIgV0cgbWVtYmVycyw8L2Rpdj4NCjxkaXY+ PGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IOW+rui9r+mbhem7 kSwgVGFob21hOyBsaW5lLWhlaWdodDogbm9ybWFsOyI+QSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMg c3VibWl0dGVkIHRvIElEUiB3b3JraW5nIGdyb3VwLiBJdHMgaW5mb3JtYXRpb24gaXMgc2hvd24g YmVsb3cuIFlvdXIgY29tbWVudHMgYXJlIHdlbGNvbWUuPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250 LWZhbWlseTog5b6u6L2v6ZuF6buRLCBUYWhvbWE7IGxpbmUtaGVpZ2h0OiBub3JtYWw7Ij4mbmJz cDs8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiDlvq7ova/pm4Xpu5EsIFRhaG9tYTsg bGluZS1oZWlnaHQ6IG5vcm1hbDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBUaXRsZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyA6Jm5ic3A7PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiDlvq7ova/p m4Xpu5E7IGZvbnQtc2l6ZTogMTAuNXB0OyBsaW5lLWhlaWdodDogMS41OyBiYWNrZ3JvdW5kLWNv bG9yOiB3aW5kb3c7Ij5Qb3B1bGF0ZSB0byBGSUIgQWN0aW9uIGZvciBGbG93U3BlYzwvc3Bhbj48 L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiDlvq7ova/pm4Xpu5EsIFRhaG9tYTsgbGlu ZS1oZWlnaHQ6IG5vcm1hbDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBBdXRob3JzICZuYnNwOyAmbmJzcDsgOiBaaGVucWlhbmcgTGk8L2Rpdj4NCjxkaXYgc3R5 bGU9ImZvbnQtZmFtaWx5OiDlvq7ova/pm4Xpu5EsIFRhaG9tYTsgbGluZS1oZWlnaHQ6IG5vcm1h bDsiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0ZpbGVuYW1lICZuYnNwOyAmbmJzcDs6Jm5i c3A7PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiDlvq7ova/pm4Xpu5E7IGZvbnQtc2l6ZTogMTAu NXB0OyBsaW5lLWhlaWdodDogMS41OyBiYWNrZ3JvdW5kLWNvbG9yOiB3aW5kb3c7Ij5kcmFmdC1s aS1pZHItZmxvd3NwZWMtcG9wdWxhdGUtdG8tZmliLTAwPC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHls ZT0iZm9udC1mYW1pbHk6IOW+rui9r+mbhem7kSwgVGFob21hOyBsaW5lLWhlaWdodDogbm9ybWFs OyI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7RGF0ZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA6IDIwMTctMDMtMTE8 L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IOW+rui9r+mbhem7kSwgVGFo b21hOyBsaW5lLWhlaWdodDogbm9ybWFsOyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAn5b6u 6L2v6ZuF6buRLCBUYWhvbWEnOyBjb2xvcjogcmdiKDAsIDAsIDApOyBiYWNrZ3JvdW5kLWNvbG9y OiByZ2JhKDAsIDAsIDAsIDApOyI+Jm5ic3A7ICZuYnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6ICcnOyBmb250LXNpemU6IDEwLjVwdDsgbGluZS1oZWlnaHQ6IDEuNTsg YmFja2dyb3VuZC1jb2xvcjogd2luZG93OyI+Jm5ic3A7DQogJm5ic3A7QWJzdHJhY3QgJm5ic3A7 ICZuYnNwOyAmbmJzcDs6Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogJ+W+ rui9r+mbhem7kSwgVGFob21hJzsgZm9udC1zaXplOiAxMC41cHQ7IGxpbmUtaGVpZ2h0OiAxLjU7 IGJhY2tncm91bmQtY29sb3I6IHdpbmRvdzsiPkEmbmJzcDtiaXQsJm5ic3A7RiZuYnNwO2JpdCwm bmJzcDtpcyZuYnNwO2RlZmluZWQmbmJzcDtpbiZuYnNwO3RyYWZmaWMmbmJzcDthY3Rpb24mbmJz cDtleHRlbmRlZCZuYnNwO2NvbW11bml0eSwmbmJzcDt3aGljaDwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6ICflvq7ova/pm4Xpu5EsIFRhaG9tYSc7IGZvbnQtc2l6ZTogMTAuNXB0OyBs aW5lLWhlaWdodDogMS41OyBiYWNrZ3JvdW5kLWNvbG9yOiB3aW5kb3c7Ij4mbmJzcDtpcyZuYnNw O3VzZWQmbmJzcDtieSZuYnNwO0Zsb3dTcGVjJm5ic3A7dG8mbmJzcDtpbmRpY2F0ZSZuYnNwO3Ro ZSZuYnNwO2Fzc29jaWF0ZWQmbmJzcDtzcGVjaWZpY2F0aW9ucyZuYnNwO2JlPC9zcGFuPjwvZGl2 Pg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAmcXVvdDsiIOW+rui9r+mbhem7kSx0YWhvbWE/ Pztmb250LXNpemU6MTRweDtjb2xvcjpyZ2IoMCwwLDApO2JhY2tncm91bmQtY29sb3I6cmdiYSgw LGZvbnQtd2VpZ2h0Om5vcm1hbDtmb250LXN0eWxlOm5vcm1hbDt0ZXh0LWRlY29yYXRpb246bm9u ZTs/PSIiPiZuYnNwOyAmbmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2Io MCwgMCwgMCk7IGJhY2tncm91bmQtY29sb3I6IHJnYmEoMCwgMCwgMCwgMCk7Ij4mbmJzcDsgJm5i c3A7Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBiYWNrZ3Jv dW5kLWNvbG9yOiByZ2JhKDAsIDAsIDAsIDApOyI+Jm5ic3A7DQogJm5ic3A7Jm5ic3A7PC9zcGFu PjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2Jh KDAsIDAsIDAsIDApOyI+Jm5ic3A7ICZuYnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29s b3I6IHJnYigwLCAwLCAwKTsgYmFja2dyb3VuZC1jb2xvcjogcmdiYSgwLCAwLCAwLCAwKTsiPiZu YnNwOyAmbmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7 IGJhY2tncm91bmQtY29sb3I6IHJnYmEoMCwgMCwgMCwgMCk7Ij4mbmJzcDsgJm5ic3A7Jm5ic3A7 PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBiYWNrZ3JvdW5kLWNvbG9y OiByZ2JhKDAsIDAsIDAsIDApOyI+Jm5ic3A7DQogJm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTogJ+W+rui9r+mbhem7kSwgVGFob21hJzsiPiZuYnNwO2luc3RhbGxl ZCZuYnNwO2RpcmVjdGx5Jm5ic3A7aW4mbmJzcDtGSUImbmJzcDsoRm9yd2FyZGluZyZuYnNwO0lu Zm9ybWF0aW9uJm5ic3A7QmFzZSkuPC9zcGFuPg0KPGRpdj48c3BhbiBzdHlsZT0iY29sb3I6IHJn YigwLCAwLCAwKTsgYmFja2dyb3VuZC1jb2xvcjogcmdiYSgwLCAwLCAwLCAwKTsiPjwvc3Bhbj48 c3BhbiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAxMC41cHQ7IGxpbmUt aGVpZ2h0OiAxLjU7IGJhY2tncm91bmQtY29sb3I6IHJnYmEoMCwgMCwgMCwgMCk7Ij4mbmJzcDsg Jm5ic3A7ICZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGxpbmUt aGVpZ2h0OiAxLjU7IGJhY2tncm91bmQtY29sb3I6IHdpbmRvdzsiPg0KPC9zcGFuPjxhIGhyZWY9 IiZuYnNwO2h0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWxpLWlkci1mbG93 c3BlYy1wb3B1bGF0ZS10by1maWIvIiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGxpbmUtaGVp Z2h0OiAxLjU7IGJhY2tncm91bmQtY29sb3I6IHdpbmRvdzsiPiZuYnNwO2h0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWxpLWlkci1mbG93c3BlYy1wb3B1bGF0ZS10by1maWIv PC9hPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LXNpemU6IDEwLjVwdDsg bGluZS1oZWlnaHQ6IDEuNTsgYmFja2dyb3VuZC1jb2xvcjogcmdiYSgwLCAwLCAwLCAwKTsiPiZu YnNwOzwvc3Bhbj48L2Rpdj4NCjxkaXY+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7 IGZvbnQtc2l6ZTogMTAuNXB0OyBsaW5lLWhlaWdodDogMS41OyBiYWNrZ3JvdW5kLWNvbG9yOiBy Z2JhKDAsIDAsIDAsIDApOyI+PGJyPg0KPC9zcGFuPjwvZGl2Pg0KPGhyIHN0eWxlPSJ3aWR0aDog MjEwcHg7IGhlaWdodDogMXB4OyIgY29sb3I9IiNiNWM0ZGYiIHNpemU9IjEiIGFsaWduPSJsZWZ0 Ij4NCjxkaXY+PHNwYW4+DQo8ZGl2IHN0eWxlPSJNQVJHSU46IDEwcHg7IEZPTlQtRkFNSUxZOiB2 ZXJkYW5hOyBGT05ULVNJWkU6IDEwcHQiPg0KPGRpdj5saV96aGVucWlhbmdAaG90bWFpbC5jb208 L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_HK2PR0601MB1361F01123946AF8F40A16D8FC250HK2PR0601MB1361_-- From nobody Sun Mar 12 22:01:49 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F292712952D for ; Sun, 12 Mar 2017 22:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ugk8PqnrVNuz for ; Sun, 12 Mar 2017 22:01:47 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 15636129456 for ; Sun, 12 Mar 2017 22:01:47 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cnI77-0000jU-0y for idr@ietf.org; Mon, 13 Mar 2017 05:01:45 +0000 Date: Mon, 13 Mar 2017 14:01:43 +0900 Message-ID: From: Randy Bush To: Interminable Discussion Room In-Reply-To: <148924277112.2960.17904473852401253352@ietfa.amsl.com> References: <148924277112.2960.17904473852401253352@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 05:01:48 -0000 note that this version is rather different and warrants reading. randy From nobody Mon Mar 13 02:31:50 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE1712955C; Mon, 13 Mar 2017 02:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gbVsCBYP8GkJ; Mon, 13 Mar 2017 02:31:45 -0700 (PDT) Received: from out-3.mail.exa.net.uk (out-3.mail.exa.net.uk [82.219.4.131]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F2F81294F7; Mon, 13 Mar 2017 02:31:26 -0700 (PDT) Received: from smtp-1.mail.exa.net.uk (smtp-1.mail.exa.net.uk [82.219.5.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by out-3.mail.exa.net.uk (ExaSMTPD) with ESMTPS id 4826A1C0066; Mon, 13 Mar 2017 09:31:24 +0000 (GMT) Received: from smtp-1.mail.exa.net.uk (localhost [127.0.0.1]) by smtp-1.mail.exa.net.uk (ExaSMTPD) with ESMTP id 326A32211B6; Mon, 13 Mar 2017 09:31:24 +0000 (GMT) Received: from bluemind.exa.net.uk (bluemind.exa.net.uk [82.219.13.108]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-1.mail.exa.net.uk (ExaSMTPD) with ESMTPS; Mon, 13 Mar 2017 09:31:24 +0000 (GMT) Received: from localhost.localdomain (localhost [127.0.0.1]) by bluemind.exa.net.uk (Postfix) with ESMTP id F35591121A4A; Mon, 13 Mar 2017 09:31:23 +0000 (GMT) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_36331215e36409b3ad1484cab3d8b4cf" Date: Mon, 13 Mar 2017 09:31:23 +0000 From: Thomas Mangin To: In-Reply-To: References: <20170228210627.GB17448@pfrc.org> <3eb4d853-1d44-6250-c70a-26f60eac39e6@cisco.com> <006e01d296db$a7c4c320$f74e4960$@ndzh.com> <010101d2974a$8520d060$8f627120$@ndzh.com> <018c01d29756$c8b4f610$5a1ee230$@ndzh.com> <01b301d29758$180458e0$480d0aa0$@ndzh.com> <7657b686-0685-9bdf-17ba-e7d618a237aa@cisco.com> Message-ID: <5491a618e2e481765b042d7ef7a65fc3@exa-networks.co.uk> X-Sender: thomas.mangin@exa-networks.co.uk User-Agent: Roundcube Webmail/0.8.5 X-Virus-Scanned: clamav-milter 0.99.2 at outbound1.mail.exa.net.uk X-Virus-Status: Clean Archived-At: Cc: 'idr wg' , draft-ietf-idr-bgp-extended-messages@ietf.org, Susan Hares , 'Robert Raszuk' , idr-chairs@ietf.org Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 09:31:48 -0000 --=_36331215e36409b3ad1484cab3d8b4cf Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8 Hello, I just noticed that I tried to re-invent draft-ietf-idr-ext-opt-param [1] on grow. For people not on both list, here are the summary of what I found. At least one implementation seen in the wild (read ExaBGP) is buggy and do not check the "Optional Parameters Length", parsing the rest of the OPEN buffer without truncating it. https://github.com/Exa-Networks/exabgp/blob/974f97fc6be63f0b05755ffc3e1ea69a02c0505b/lib/exabgp/bgp/message/open/capability/capabilities.py#L159 While I now fixed the bug, using 255 as a values and expecting the speaker to handle this number as "magical" may break some deployment down the line. While I can only apologise for letting such a error in my code, I would assume that more than one "home brewed" implementation may perform bad or lazy OPEN parsing and that therefore the draft as written would at some point break some currently working BGP session. I therefore proposed on grow an alternative way to encode the extended length within a capability - total or extra bytes after the initial value in the 1 bytes length, and asking new implementation to make sure that the data within the one byte length remains valid. This approach does not change at all the parsing of the current OPEN and for buggy implementation ignoring the length (parsing the whole payload - like ExaBGP did), it will continue to work, this change is transparent. However this change would not allow to extend an individual capability size (from one byte to two) the way the current encoding propose, it would however allow partial capability exchange between a speaker aware of the extension (if this is a good or bad thing is surely up to debate). I also realise that it may be several years before the extended encoding, even if available today, is required due to the growth of the OPEN size. I am therefore only pointing this issue to the list for information so that the author can decide if they consider this scenario as probable and worthy of consideration or not. Sincerely, Thomas On 2017-03-07 23:51, Enke Chen wrote: > https://datatracker.ietf.org/doc/draft-ietf-idr-ext-opt-param/ [1]draft-ietf-idr-ext-opt-param-05 Links: ------ [1] https://datatracker.ietf.org/doc/draft-ietf-idr-ext-opt-param/ --=_36331215e36409b3ad1484cab3d8b4cf Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 Hello,

I just noticed that I tried to re-invent draft-ietf-idr-ext-opt-param on grow. For people not on both list, here are the summar= y of what I found.

At least one implementation seen in th= e wild (read ExaBGP) is buggy and do not check the "Option= al Parameters Length", parsing the rest of the OPEN buffer without truncati= ng it.

https://github.com/Exa-Networks/exabg= p/blob/974f97fc6be63f0b05755ffc3e1ea69a02c0505b/lib/exabgp/bgp/message/open= /capability/capabilities.py#L159

While I now fixed the bu= g, using 255 as a values and expecting the speaker to handle this number as= "magical" may break some deployment down the line.

While I can = only apologise for letting such a error in my code, I would assume that mor= e than one "home brewed" implementation may perform bad or lazy OPEN parsin= g and that therefore the draft as written would at some point break some cu= rrently working BGP session.

I therefore proposed on grow an alt= ernative way to encode the extended length within a capability - = total or extra bytes after the initial value in the 1 bytes length, and ask= ing new implementation to make sure that the data within the one byte = length remains valid.
This approach does not change at all the pa= rsing of the current OPEN and for buggy implementation ignoring the le= ngth (parsing the whole payload - like ExaBGP did), it will continue to wor= k, this change is transparent.

However this change would not all= ow to extend an individual capability size (from one byte to two) the way t= he current encoding propose, it would however allow partial capability exch= ange between a speaker aware of the extension (if this is a good or bad thi= ng is surely up to debate).

I also realise that it may be severa= l years before the extended encoding, even if available today, is required = due to the growth of the OPEN size. I am therefore only pointing this issue= to the list for information so that the author can decide if they consider= this scenario as probable and worthy of consideration or not.

S= incerely,

Thomas

On 2017-03-07 23:51, Enke Chen wrote:

https://datatracker.ietf.org/doc/draft-ietf-idr-ext-opt-param/draf=
t-ietf-idr-ext-opt-param-05

 
--=_36331215e36409b3ad1484cab3d8b4cf-- From nobody Mon Mar 13 02:51:29 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A2C3129566 for ; Mon, 13 Mar 2017 02:51:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.348 X-Spam-Level: X-Spam-Status: No, score=-2.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KVeItY9PivnZ for ; Mon, 13 Mar 2017 02:51:25 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::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 462B21294F7 for ; Mon, 13 Mar 2017 02:51:25 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id y76so218153135qkb.0 for ; Mon, 13 Mar 2017 02:51:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=426XpXmuD6XjcW4pOpFG6GYFfHGKbez1taGdf7U33nU=; b=l/9x2fPHTGiaCRY5qdZg0p9hSa7LNRmnVJYnoYYrPtkhnFnq49JgGre3qRHNgBUfyK PM0aIbxgFmsU7CFvps8Dk6uOwarvovUmEDZ3GvhJ6BCR1THXs3m+aFtFsgVET8DF8iRY pQagQSNTfcOCUDwkezWif+320m6atjTtfDuZr0ZcexsFkTAPoF25+O9+dTY1YJAv9nLv h4rgbN6BzwvZ/6V1OWYLZ4k3fTzgNLTJNLW7dE/axS3uzmwQ0j9o2c3MUbdk6RL1JA89 Hb3W+dYVkAWEmN+caUts9bPV1qtAzPLe1eD7GLBPqPl/NRJxAd4U1A0vGQJ53ZKopNSF EBYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=426XpXmuD6XjcW4pOpFG6GYFfHGKbez1taGdf7U33nU=; b=d8wrZ//flkCP4ROY3S5NLSw7KN6XLRG/MtAuUTF21ty5C/uo/CDN2LyoCK2rs9IkTt nlHmIQ/QWH/nicYTacQmSdcOKZdC2S+bWCYCgWnHB/NDsA1qRqtAhVnhgptb9ltNdICg ezfyBu+ZxWsNRlfp6NGdnT+gcZ9EWXafJUKy9daYFKVCSVOAzweeBAHuupb3BErZW5UG tErkWQxgGwS9yO5E9pUggaGKqFdj2CUPYugf5QAY0rHEKeXxegbILoNCc5HPgSmhDuPf nL52CBXP9Jb/+2eXJjbSzR99W23SRaT0PxYAvuW1JpuwG+555I+pwTEsAeiaK9ViBkpo grvg== X-Gm-Message-State: AMke39nrJIhz26rcSur/p2PujWz5tuwO90tl8XAqmKpTotwIkGf8ixUo/DUnn80xtFWvgNzo4wX+Oc39RVi1yA== X-Received: by 10.55.128.66 with SMTP id b63mr33284690qkd.297.1489398684315; Mon, 13 Mar 2017 02:51:24 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.140.42.181 with HTTP; Mon, 13 Mar 2017 02:51:23 -0700 (PDT) In-Reply-To: References: <148924277112.2960.17904473852401253352@ietfa.amsl.com> From: Robert Raszuk Date: Mon, 13 Mar 2017 10:51:23 +0100 X-Google-Sender-Auth: OceeoE6G_DtOymndsEjXhSGNV4k Message-ID: To: Randy Bush Content-Type: multipart/alternative; boundary=94eb2c06654c81fe3b054a99a7e6 Archived-At: Cc: Interminable Discussion Room Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 09:51:27 -0000 --94eb2c06654c81fe3b054a99a7e6 Content-Type: text/plain; charset=UTF-8 Hi Randy & authors of this document, Major comment: Let's observe that the ultimate objective of this draft (and in fact much more) can be achieved by assuring that clients receive more then one path to given bgp destinations at normal operation. That direction has been proven to work much more effectively in all other scenarios which require fast connectivity restoration as opposed to counting on control plane "convergence". The following alternative techniques can be used to distribute more then just best path between BGP clients: *A* Use of add-paths RFC7911 from RS to clients (with eBGP support extension) *B* Use of diverse-path RFC6774 from RS to clients *C* Direct EBGP peering between clients with the help of BGP Auto Discovery https://goo.gl/KKgqfU (now with merged work of Automagic peering at IXPs: https://goo.gl/RJIKYM) Let's also notice that in IX folks peering via RS have open or selective peering policy and they send at most their clients + internal routes. Therefor for any given b_net there will be no more then few paths. There is no Transit Internet open peering via RS or very often even via IX. This will allow all clients to quickly switch over to backup path which would be with PIC already present in their data plane ahead of failure. Moreover this will reduce churn and convergence delay when say 1000 clients in one shot is bombarding RS using new proposed SAFI of the very same client router going down. Also let's keep in mind that modern routing stacks allow to much more intelligent routing by actively and passively monitoring all alternative paths to your interesting destinations and based on the quality of the data plane via any peer choose the best path. That with just getting a single path at a time is simply not possible as those "interesting destinations" are not BGP next hops, but applications servers sitting one or more ASes far from client. Minor comment: Today BFD sessions last time I checked must be bounded to a protocol. In current IX+RS model there is no direct protocol between clients. Hence BFD implementations on the clients needs to be augmented to auto peer with all BGP next hops received over eBGP sessions to RS. Not impossible and in fact perhaps good feature on its own .. but needs to be supported on all clients just like the new SAFI draft proposes. Kind regards, Robert On Mon, Mar 13, 2017 at 6:01 AM, Randy Bush wrote: > note that this version is rather different and warrants reading. > > randy > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --94eb2c06654c81fe3b054a99a7e6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Randy & authors of this document= ,

Major comment:
=

Let's observe that the = ultimate objective of this draft (and in fact much more) can be achieved by= assuring that clients receive more then one path to given bgp destinations= at normal operation.=C2=A0

That direction has been proven to work much more effectively in all o= ther scenarios which require fast connectivity restoration as opposed to co= unting on control plane "convergence".=C2=A0

The following alternative techniques can b= e used to distribute more then just best path between BGP clients:

*A* Use of add-paths RFC7911 f= rom RS to clients (with eBGP support extension)
*B* Use of diverse-path RFC6774 from RS to client= s=C2=A0

*C* Direct EBG= P peering between clients with the help of BGP Auto Discovery=C2=A0https://goo.gl/KKgqfU =C2=A0(now with merged= work of Automagic peering at IXPs:=C2=A0= https://goo.gl/RJIKYM)=C2=A0

Let's also notice that in IX folks peering via RS have open = or selective peering policy and they send at most their clients + internal = routes. Therefor for any given b_net there will be no more then few paths. = There is no Transit Internet open peering via RS or very often even via IX.=

This will allow all c= lients to quickly switch over to backup path which would be with PIC alread= y present in their data plane ahead of failure.=C2=A0

Moreover this will reduce churn and converg= ence delay when say 1000 clients in one shot is bombarding RS using new pro= posed SAFI of the very same client router going down.=C2=A0

Also let's keep in mind that mode= rn routing stacks allow to much more intelligent routing by actively and pa= ssively monitoring all alternative paths to your interesting destinations a= nd based on the quality of the data plane via any peer choose the best path= . That with just getting a single path at a time is simply not possible as = those "interesting destinations" are not BGP next hops, but appli= cations servers sitting one or more ASes far from client.=C2=A0


Mino= r comment:

Today BFD s= essions last time I checked must be bounded to a protocol. In current IX+RS= model there is no direct protocol between clients. Hence BFD implementatio= ns on the clients needs to be augmented to auto peer with all BGP next hops= received over eBGP sessions to RS. Not impossible and in fact perhaps good= feature on its own .. but needs to be supported on all clients just like t= he new SAFI draft proposes.=C2=A0

Kind regards,
Robert








On Mon, Mar 13, 2017 at 6:01 AM, Randy Bush= <r= andy@psg.com> wrote:
note t= hat this version is rather different and warrants reading.

randy

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

--94eb2c06654c81fe3b054a99a7e6-- From nobody Mon Mar 13 03:32:07 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9182A1279EB for ; Mon, 13 Mar 2017 03:32:06 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OWap8IF2r70Q for ; Mon, 13 Mar 2017 03:32:04 -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 6A67D127078 for ; Mon, 13 Mar 2017 03:32:03 -0700 (PDT) X-Envelope-To: idr@ietf.org Received: from cupcake.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id v2DAVwKn090218 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Mar 2017 10:31:58 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be cupcake.local Message-ID: <58C6751D.60306@foobar.org> Date: Mon, 13 Mar 2017 10:31:57 +0000 From: Nick Hilliard User-Agent: Postbox 5.0.11 (Macintosh/20170302) MIME-Version: 1.0 To: Robert Raszuk References: <148924277112.2960.17904473852401253352@ietfa.amsl.com> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Interminable Discussion Room Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 10:32:06 -0000 Robert Raszuk wrote: > Let's observe that the ultimate objective of this draft (and in fact > much more) can be achieved by assuring that clients receive more then > one path to given bgp destinations at normal operation. This is a fundamental misunderstanding. The aim of this draft is to ensure that traffic isn't blackholed if there is a layer 2 incongruity on the IXP which causes connectivity to be non commutative. Given the following topology, A's connectivity to RS works fine, and B's connectivity to RS works fine, but A cannot communicate with B: > +-----+ +-----+ > | +--> | | > | A | | B | > | | <--+ | > +-----+ +-----+ > | | > | +------+ | > +-+ +--+ > | RS | > | | > +------+ What's needed is some protocol running between A and B to ensure that they can still talk to each other, i.e. BFD. No amount of alternative paths will save you in this situation because the control plane (RS) has connectivity to both data plane routers. Nick From nobody Mon Mar 13 03:32:56 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC9B8129400; Mon, 13 Mar 2017 03:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kojJxwmTRKI3; Mon, 13 Mar 2017 03:32:52 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8010F127078; Mon, 13 Mar 2017 03:32:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6684; q=dns/txt; s=iport; t=1489401172; x=1490610772; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=E3O7TWMI3kV3JbtE9e7bY3RKdtEd+ywiLU391lr/TM4=; b=aC1kG51xASO9Ww8cQ10zJfs/mbtWx7eAJm4HnVNSaxcbepynj7E62ujO uTW9Vv/xHgjlvbSR3z5KeDIdzedxIcb3pjSqctuT1TG1DFaf/BLU75l9P GyfIESenQ3XsYO+W9AgN+PSnHhtUlZ2xxJQHRjFTUfIjLnDgbVnWoKz9c w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D5AQC7dMZY/40NJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1FhgQoHg1mKDpFQlTuCDh8NhXYCGoI0PxgBAgEBAQEBAQFrKIU?= =?us-ascii?q?VAQEBAQIBAQEhEToLBQsCAQgRBAEBAQICHwQDAgICJQsUAQgIAQEEDgWJeAgOr?= =?us-ascii?q?weCJopXAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBC4VDggUIgmKEJhEBM4JvLoI?= =?us-ascii?q?xBY9bhiWGQQGGdYtDgXuFJYNVhjCIRYp9AR84fAhYFUERAYRFHRmBSnWHJYEhg?= =?us-ascii?q?Q0BAQE?= X-IronPort-AV: E=Sophos;i="5.36,158,1486425600"; d="scan'208";a="222623179" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Mar 2017 10:32:50 +0000 Received: from XCH-RTP-010.cisco.com (xch-rtp-010.cisco.com [64.101.220.150]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v2DAVSqO000813 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 13 Mar 2017 10:31:29 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-010.cisco.com (64.101.220.150) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 13 Mar 2017 06:31:28 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1210.000; Mon, 13 Mar 2017 06:31:28 -0400 From: "Stefano Previdi (sprevidi)" To: "John G.Scudder" Thread-Topic: [Idr] [spring] IDR WG 2 week WG LC on draft-ietf-idr-bgpls-segment-routing-epe - (2/15/2017 to 3/1/2017) Thread-Index: AdKH5ALnHgVYM3zURr+F4Gs1EKSVZgAj0X2gBGOg2gAAgSypAA== Date: Mon, 13 Mar 2017 10:31:28 +0000 Message-ID: References: <00f901d287e4$16ecb2f0$44c618d0$@ndzh.com> <10484_1487263806_58A5D83E_10484_6197_1_53C29892C857584299CBF5D05346208A1ED67062@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.229.16] Content-Type: text/plain; charset="utf-8" Content-ID: <77E0960AA2E3A344BFDD26C047CAEB2D@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "idr@ietf.org" , "spring@ietf.org" , "draft-ietf-idr-bgpls-segment-routing-epe@ietf.org" , Susan Hares , Bruno Decraene Subject: Re: [Idr] [spring] IDR WG 2 week WG LC on draft-ietf-idr-bgpls-segment-routing-epe - (2/15/2017 to 3/1/2017) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 10:32:54 -0000 Sm9obiwgQnJ1bm8sDQoNCnNvcnJ5IGZvciBoYXZpbmcgbWlzc2VkIHRoYXQuIEnigJlsbCByZXN1 Ym1pdCByaWdodCBub3cuIEkgaW50ZWdyYXRlZCBhbGwgY29tbWVudHMuIFJlZ2FyZGluZyB0aGUg bWlzc2luZyAic2VjdGlvbiAzLjEiIChyZWZlcnJpbmcgdG8gdGhlIGlzaXMgZHJhZnQpLCBJIHJl cGxhY2VkIHRleHQgd2l0aCB0aGUgcmVmZXJlbmNlIHRvIGRyYWZ0LWlldGYtaWRyLWJncC1scy1z ZWdtZW50LXJvdXRpbmctZXh0IHdoaWNoIGRlZmluZXMgdGhlIGJncC1scyB0bHYgZm9yIGFkdmVy dGlzaW5nIHRoZSBTUkdCLiBJIGdhdmUgdGhpcyBhcyBhbiBleGFtcGxlLiBJIGFsc28gbW92ZWQg ZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nIGludG8gdGhlIG5vcm1hdGl2ZSByZWZl cmVuY2VzIHNlY3Rpb24uDQoNClRoYW5rcy4NCg0Kcy4NCg0KDQo+IE9uIE1hciAxMCwgMjAxNywg YXQgODo1MiBQTSwgSm9obiBHLlNjdWRkZXIgPGpnc0BqdW5pcGVyLm5ldD4gd3JvdGU6DQo+IA0K PiBIaSBBdXRob3JzLA0KPiANCj4gSSBzZWUgdGhhdCB5ZXN0ZXJkYXkncyAtMTAgcmV2aXNpb24g ZG9lc24ndCBhZGRyZXNzIEJydW5vJ3MgY29tbWVudHMsIGJlbG93LiBDYW4geW91IHBsZWFzZSBl aXRoZXIgdXBkYXRlIHRoZSBkb2N1bWVudCBpZiB5b3UgYWNjZXB0IEJydW5vJ3Mgc3VnZ2VzdGlv bnMsIG9yIG90aGVyd2lzZSBkaXNjdXNzIHRoZW0gb24gdGhlIGxpc3Q/IFdlIGNhbid0IGRlY2xh cmUgdGhlIFdHTEMgdG8gYmUgc2F0aXNmYWN0b3JpbHkgZmluaXNoZWQgdW50aWwgdGhpcyBpcyBy ZXNvbHZlZC4NCj4gDQo+IFRoYW5rcywNCj4gDQo+IC0tSm9obg0KPiANCj4+IE9uIEZlYiAxNiwg MjAxNywgYXQgMTE6NTAgQU0sIGJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb20gd3JvdGU6DQo+PiAN Cj4+IEhpLA0KPj4gIA0KPj4gSeKAmXZlIHJlYWQgdGhlIGRyYWZ0LCBwbGVhc2UgZmluZCBiZWxv dyBzb21lIG1pbm9yIGNvbW1lbnRzOg0KPj4gIA0KPj4gLS0tDQo+PiDCpzQuMw0KPj4gIiAgICAg ICogIEEgNCBvY3RldCBpbmRleCBkZWZpbmluZyB0aGUgb2Zmc2V0IGluIHRoZSBTSUQvTGFiZWwg c3BhY2UgYWR2ZXJ0aXNlZCBieSB0aGlzIHJvdXRlciB1c2luZyB0aGUgZW5jb2RpbmdzIGRlZmlu ZWQgaW4gIFNlY3Rpb24gMy4xLiINCj4+ICANCj4+IC0gRm9sbG93aW5nIHRoZSByZWNlbnQgYWRk aXRpb24gb2YgdGhlIFNSTEIgTGFiZWwgU3BhY2UsIEknZCByYXRoZXIgaGF2ZSB0aGUgdGV4dCBl eHBsaWNpdGx5IHJlZmVycyB0byBuYW1lIG9mIHRoYXQgTGFiZWwgc3BhY2UuIGUuZy4NCj4+IE9M RDogU0lEL0xhYmVsIHNwYWNlDQo+PiBORVc6IFNSR0INCj4+ICANCj4+IC0gV2hpY2ggKFNSR0Ip IGFkdmVydGlzZW1lbnQ/IEknbSBhc3N1bWluZyB0aGUgSUdQIG9uZSwgYnV0IEkgZ3Vlc3Mgc29t ZW9uZSBtYXkgaW1hZ2luZSB1c2luZyB0aGUgQkdQICJPcmlnaW5hdG9yIFNSR0IgVExWIi4gVGhl biB3aGF0IGlmIHRoZSBub2RlIHJ1bnMgbXVsdGlwbGUgSUdQIHdpdGggZGlmZmVyZW50IFNSR0Ig Y29uZmlndXJlZD8NCj4+ICANCj4+IC0gTm90ZSB0aGF0IHRoaXMgZG9jdW1lbnQgaGFzIG5vICJT ZWN0aW9uIDMuMSIuIFRoZSB0ZXh0IHNlZW1zIGJvcnJvd2VkIGZyb20gdGhlIElTLUlTIFNSIGRy YWZ0LCBoZW5jZSBtYXkgYmUgYWRkaW5nIHRoZSBuYW1lIG9mIHRoaXMgZHJhZnQgd291bGQganVz dCBzb2x2ZSB0aGUgcG9pbnQuICh3aXRoIGEgbm9ybWF0aXZlIHJlZmVyZW5jZSB0byB0aGlzIElT LUlTIGRyYWZ0KQ0KPj4gIA0KPj4gLS0tDQo+PiBPTEQ6IFRoZSBMaW5rIE5MUkkgdXNlcyB0aGUg bmV3IFByb3RvY29sLUlEIHZhbHVlICh0byBiZSBhc3NpZ25lZCBieSBJQU5BKQ0KPj4gcHJvcG9z ZWQgTkVXOiBUaGUgTGluayBOTFJJIHVzZXMgdGhlIEJHUCBQcm90b2NvbC1JRCAoVEJEMSkNCj4+ ICANCj4+ICjigJxuZXfigJ0gbWF5IGJlY29tZSB1bnNwZWNpZmljIDIgeWVhcnMgZnJvbSBub3cp DQo+PiAgDQo+PiAtLS0NCj4+IE9uZSBjb3VsZCBwcm9iYWJseSBhcmd1ZSB0aGF0IFtJLUQuaWV0 Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nXSBzaG91bGQgYmUgYSBub3JtYXRpdmUgcmVmZXJlbmNl Lg0KPj4gIA0KPj4gVGhhbmtzLA0KPj4gUmVnYXJkcywNCj4+IC0tQnJ1bm8NCj4+ICANCj4+ICAN Cj4+IEZyb206IHNwcmluZyBbbWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgU3VzYW4gSGFyZXMNCj4+IFNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAxNiwgMjAxNyAx MjozNSBBTQ0KPj4gVG86IGlkckBpZXRmLm9yZw0KPj4gQ2M6ICdBbHZhcm8gUmV0YW5hIChhcmV0 YW5hKSc7IHNwcmluZ0BpZXRmLm9yZw0KPj4gU3ViamVjdDogW3NwcmluZ10gSURSIFdHIDIgd2Vl ayBXRyBMQyBvbiBkcmFmdC1pZXRmLWlkci1iZ3Bscy1zZWdtZW50LXJvdXRpbmctZXBlIC0gKDIv MTUvMjAxNyB0byAzLzEvMjAxNykNCj4+ICANCj4+IFRoaXMgYmVnaW5zIGEgMiB3ZWVrIElEUiBX RyBsYXN0IGNhbGwgb24gZHJhZnQtaWV0Zi1pZHItYmdwbHMtc2VnbWVudC1yb3V0aW5nLWVwZSBm cm9tICgyLzE1IHRvIDMvMS8yMDE3KSAgICBUaGVyZSBhcmUgdHdvIGltcGxlbWVudGF0aW9ucyBk ZXNjcmliZSBvbiB0aGUgd2lraSBhdDoNCj4+IGh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL2lk ci93aWtpL2RyYWZ0LWlldGYtaWRyLWJncGxzLXNlZ21lbnQtcm91dGluZy1lcGUlMjANCj4+ICAN Cj4+IFRoZSB0d28gaW1wbGVtZW50YXRpb24gYXJlIGZyb20gIENpc2NvIElPUy1YUiByZWxlYXNl IDYuMC4yIGFuZCBDaXNjbyBOZXh1cyBTd2l0Y2ggTjkwMDAvTjMwMDAgcGxhdGZvcm1zIHJ1bm5p bmcgTlgtT1MgNy4wKDMpSTEoMSkgb3IgZ3JlYXRlci4gICBUaGUgYXV0aG9ycyB3aWxsIGluZGlj YXRlIG9uIHRoZSBsaXN0IGFuZCBpbiB0aGUgd2lraSB0aGUgZm9sbG93aW5nIGluZm9ybWF0aW9u IDoNCj4+ICANCj4+IDEpICAgICAgV2VyZSB0aGVzZSBpbXBsZW1lbnRhdGlvbnMgc2VwYXJhdGUg aW1wbGVtZW50YXRpb25zPw0KPj4gMikgICAgICBXaGF0IHdlcmUgdGhlIHJlc3VsdHMgb2YgdGhl IGludGVyb3BlcmFiaWxpdHkgdGVzdHM/DQo+PiAgDQo+PiBUaGlzIHdvcmsgaXMgbGlua2VkIHRv IHRoZSBkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctY2VudHJhbC1lcGUgd29yayBp biB0aGUgU1BSSU5HIFdHLiBCYXNlZCBvbiB0aGUgdHdvIGRyYWZ0cywgdGhlIFdHIHNob3VsZCBt aWdodCBjb25zaWRlcjogIA0KPj4gMSkgICAgICBJcyB0aGVyZSBuZWVkIGZvciB0aGlzIHdvcmsg aW4gZGVwbG95bWVudHMgaW4gbmV0d29ya3MvDQo+PiAyKSAgICAgIElzIHRoaXMgdGVjaG5pY2Fs bHkgcmVhZHkgZm9yIHB1YmxpY2F0aW9uPw0KPj4gMykgICAgICBEb2VzIGl0IGZpdCB3aXRoIHRo ZSBzcHJpbmcgaW5mb3JtYXRpb25hbCBkcmFmdD8NCj4+ICANCj4+IEZvciB0aGUgZWFzZSBvZiBy ZWZlcmVuY2UgdGhlIHdlYiByZWZlcmVuY2VzIGFyZSBiZWxvdzoNCj4+IGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaWRyLWJncGxzLXNlZ21lbnQtcm91dGluZy1l cGUvDQo+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXNwcmlu Zy1zZWdtZW50LXJvdXRpbmctY2VudHJhbC1lcGUvDQo+PiAgDQo+PiBTdWUgSGFyZXMgDQo+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+PiANCj4+IENlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQg Y29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVz IGV0IG5lIGRvaXZlbnQgZG9uYw0KPj4gcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBj b3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFy IGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXINCj4+IGEgbCdleHBlZGl0ZXVyIGV0IGxlIGRl dHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJv bmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sDQo+PiBPcmFuZ2UgZGVjbGlu ZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3Jt ZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQo+PiANCj4+IFRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFj aG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9u IHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7DQo+PiB0aGV5IHNob3VsZCBub3QgYmUgZGlz dHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCj4+IElmIHlv dSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNl bmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KPj4gQXMg ZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMg dGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KPj4gVGhhbmsg eW91Lg0KPj4gDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPj4gSWRyIG1haWxpbmcgbGlzdA0KPj4gSWRyQGlldGYub3JnDQo+PiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkcg0KPiANCg0K From nobody Mon Mar 13 03:45:31 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AEE612954B for ; Mon, 13 Mar 2017 03:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.348 X-Spam-Level: X-Spam-Status: No, score=-2.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hLcA-Yvt4dz9 for ; Mon, 13 Mar 2017 03:45:27 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::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 6C04F1293FD for ; Mon, 13 Mar 2017 03:45:27 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id v125so214540221qkh.2 for ; Mon, 13 Mar 2017 03:45:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Fbj2vdUUvGRCx0suHoj9Y3cnlsecO7CCuhIRopz3Akc=; b=fRqL6bx260N+rgHshpFeNYW2PquqfkNMkqNAFZimBG3FH/lTIQqmBYnj3TRkNIssqy lS3NHIVnEgCchaQkr+5/+xqWTRgXHLDKeWJWoDx2e4zABjrUFyZ0vopeb4vHimjqpkdQ 4jdsOHFEHD2AUas/PTaCNJpr+CSTiwaXdK46rnuQyV7pKZUBBpGL2YNOYlGjR4xoKSQH jpAV1Yq3SqQ7GjE9kS63NeIckcEvjw+MVOA/3Lh9fW48DD6wF+DCzba4IikuNdYnskAv zotBUCrzpiyGn7m1vgSJnVdULsoaXqGHFjiTlA3suo6o8UdRR8+D0ic1x56Okfr+hRXm HBQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Fbj2vdUUvGRCx0suHoj9Y3cnlsecO7CCuhIRopz3Akc=; b=qThHCfpqz7dPRz5a5uOcU0ObSg1RVxvmdxHen9sY1Gy6fh/sDc+3zD2mzIRKHdf/ig J3PalSijp7Qhbgco8SdP8HGNkGNW3KU3wvc5EOaHShKgmHgEFF6JeuPOMpwTNsgHXUeY /xRB4tgjV6Q9f+i3cnKNAXBSU9QRH4frhTUHk0LaTh+6/wP6kchDidyTGQ1y/eHqa+q3 6CPupEOsWCepGPDvEWGVn6OGWu7wdO1m0YheOH1nxlbsdlZ6meiraAV9AHdyF0lNb+Cu QbEoy7zzLjzhA4rlydEXlUQ7i1WMyZEyXfeW3tyHUEp4r/A4IUdtY0Tu90PEwpupdskg P+fg== X-Gm-Message-State: AFeK/H0SgVx+EDOr3TNDzQ3NA+shewJuAXX0fdVRb8IS75yu+K1UEScGNDIKxLdt+aymldfu92ECwMn6ORtEtQ== X-Received: by 10.55.65.136 with SMTP id o130mr29516845qka.168.1489401926559; Mon, 13 Mar 2017 03:45:26 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.140.42.181 with HTTP; Mon, 13 Mar 2017 03:45:25 -0700 (PDT) Received: by 10.140.42.181 with HTTP; Mon, 13 Mar 2017 03:45:25 -0700 (PDT) In-Reply-To: References: <148924277112.2960.17904473852401253352@ietfa.amsl.com> <58C6751D.60306@foobar.org> From: Robert Raszuk Date: Mon, 13 Mar 2017 11:45:25 +0100 X-Google-Sender-Auth: hDHcQDkRdYsV-PkbWECLPGb9jig Message-ID: To: Nick Hilliard Content-Type: multipart/alternative; boundary=001a11488ce4c2b3af054a9a6829 Archived-At: Cc: idr wg Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 10:45:29 -0000 --001a11488ce4c2b3af054a9a6829 Content-Type: text/plain; charset=UTF-8 Nick, I am afraid you have completely missed my point. I never said clients must not detect other clients liveness before using it for best path selection and in their local data planes. I said RS does not need to bothered with that information. In fact I explicitely said that modern clients will detect health of the path well beyond local peer's next hop. Cheers, R. On Mar 13, 2017 11:32 AM, "Nick Hilliard" wrote: Robert Raszuk wrote: > Let's observe that the ultimate objective of this draft (and in fact > much more) can be achieved by assuring that clients receive more then > one path to given bgp destinations at normal operation. This is a fundamental misunderstanding. The aim of this draft is to ensure that traffic isn't blackholed if there is a layer 2 incongruity on the IXP which causes connectivity to be non commutative. Given the following topology, A's connectivity to RS works fine, and B's connectivity to RS works fine, but A cannot communicate with B: > +-----+ +-----+ > | +--> | | > | A | | B | > | | <--+ | > +-----+ +-----+ > | | > | +------+ | > +-+ +--+ > | RS | > | | > +------+ What's needed is some protocol running between A and B to ensure that they can still talk to each other, i.e. BFD. No amount of alternative paths will save you in this situation because the control plane (RS) has connectivity to both data plane routers. Nick _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr --001a11488ce4c2b3af054a9a6829 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Nick,

I= am afraid you have completely missed my point.

=
I never said clients must not detect other clients = liveness before using it for best path selection and in their local data pl= anes.

I said RS does not= need to bothered with that information.

<= div dir=3D"auto">In fact I explicitely said that modern clients will detect= health of the path well beyond local peer's next hop.

Cheers,
R.
<= br>

On Mar 13, 201= 7 11:32 AM, "Nick Hilliard" <nick@foobar.org> wrote:
Robert Raszuk wrote:
> Let's observe that the ultimate objective of this draft (and in fa= ct
> much more) can be achieved by assuring that clients receive more then<= br> > one path to given bgp destinations at normal operation.

This is a fundamental misunderstanding.=C2=A0 The aim of this draft i= s to
ensure that traffic isn't blackholed if there is a layer 2 incongruity<= br> on the IXP which causes connectivity to be non commutative.

Given the following topology, A's connectivity to RS works fine, and B&= #39;s
connectivity to RS works fine, but A cannot communicate with B:

>=C2=A0 =C2=A0 +-----+=C2=A0 =C2=A0 +-----+
>=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0+--> |=C2=A0 =C2=A0 =C2=A0|
>=C2=A0 =C2=A0 |=C2=A0 A=C2=A0 |=C2=A0 =C2=A0 |=C2=A0 B=C2=A0 |
>=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0| <--+=C2=A0 =C2=A0 =C2=A0|
>=C2=A0 =C2=A0 +-----+=C2=A0 =C2=A0 +-----+
>=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0| +------+=C2=A0 |
>=C2=A0 =C2=A0 =C2=A0 =C2=A0+-+=C2=A0 =C2=A0 =C2=A0 +--+
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 RS=C2=A0 |
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 |
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+------+

What's needed is some protocol running between A and B to ensure that they can still talk to each other, i.e. BFD.

No amount of alternative paths will save you in this situation because
the control plane (RS) has connectivity to both data plane routers.

Nick

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

--001a11488ce4c2b3af054a9a6829-- From nobody Mon Mar 13 05:00:26 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82B1A12957C for ; Mon, 13 Mar 2017 05:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1gDv1u2CE0oR for ; Mon, 13 Mar 2017 05:00:16 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 7160E12957E for ; Mon, 13 Mar 2017 05:00:16 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cnOe5-0002Ei-SM; Mon, 13 Mar 2017 12:00:14 +0000 Date: Mon, 13 Mar 2017 21:00:11 +0900 Message-ID: From: Randy Bush To: Robert Raszuk In-Reply-To: References: <148924277112.2960.17904473852401253352@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: Interminable Discussion Room Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 12:00:24 -0000 > Let's observe that the ultimate objective of this draft (and in fact much > more) can be achieved by assuring that clients receive more then one path > to given bgp destinations at normal operation. let's break tradition and actually see what the document says. 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 a newly defined BGP SAFI to signal the state of the data link to the route server(s). and, if you wander over to the referenced route server docco, you'll see that it already deals with alternate paths. rady From nobody Mon Mar 13 05:33:30 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 814821295B3 for ; Mon, 13 Mar 2017 05:33:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQ0ASsgKe3KN for ; Mon, 13 Mar 2017 05:33:27 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5B6D1295A8 for ; Mon, 13 Mar 2017 05:33:26 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id 1so220176647qkl.3 for ; Mon, 13 Mar 2017 05:33:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=v+JslLP7etPBM2rpOXv0w0tYTBV4xmgQhvZ3OMHzH70=; b=Y1uUOEaFKR93xd2bAbWfWCyqJlz4qweiY5DXFp91C7D1PmNPF02lFbuavLk9UoaAeZ Mo83IyllR86dnnXF+fFe/sC/dqrYkDU3b072jcKHjEiKnSZvQOdAq5gfOsGIZoE2ZK8b 7wMj/y0hogZRqDekbibEEAETtqvtIk0ZljUus6uBvn9puzveEwdikCv1Ja0MQHRPpmdr cbKBB9LFYSyGygMGLwTGM8l66fEJ4Mw4nbQcpdBxfscNU4j2bMYUlWTg649+wwoIgX2j wOx8ZocCphcv0GhGv/E1WEKuL/xeh1BxudEjr92NMkUS7JZeuYbjFawyRsJNn0pAzj8k y9cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=v+JslLP7etPBM2rpOXv0w0tYTBV4xmgQhvZ3OMHzH70=; b=Fv2msirr+OAZA+Rr9uQx1Z8RY+xeDLgKgHiHOe0n8i1DT+mdU5AKjo9tWKRKeimrEj ZjDI1yxVqvNWLi8Np0J6D2FauGO5+N6vfKGy8C1cw/47hHpEO7OLe0Yt1haxo5hRUUiK 6gcjlZdtGrw3ART1wzYc3cfrOMf7B0QjNhAxLgD/NoUwWIh8Ljs6bMxVS79oHO2ncHf5 Q6/RPLLxCgbdDEIiiG1CnXTlhJ/nDEuBK/UMRYanqgxh0/CFVRP+dbk+WYx48ief5NV1 DUKSo6dT4BuRrgRayyxz5YTi0WHnvyv+N9KpoErbctmHczGXdq89Za/vIgX5eIKPk4Uy Movw== X-Gm-Message-State: AMke39nzXDGcCK2akV7K97eQSQTpK5Pn37reO7goSXzSPGmBS1k1RFTqAgS08/9oTl3LxkYA+K9MAqr1iflyHg== X-Received: by 10.55.144.4 with SMTP id s4mr30326612qkd.101.1489408405897; Mon, 13 Mar 2017 05:33:25 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.140.42.181 with HTTP; Mon, 13 Mar 2017 05:33:25 -0700 (PDT) In-Reply-To: References: <148924277112.2960.17904473852401253352@ietfa.amsl.com> From: Robert Raszuk Date: Mon, 13 Mar 2017 13:33:25 +0100 X-Google-Sender-Auth: K2XgldIhQdkq4TunftxIZNN_zMI Message-ID: To: Randy Bush Content-Type: multipart/alternative; boundary=94eb2c057a70f5adb0054a9beacc Archived-At: Cc: Interminable Discussion Room Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 12:33:28 -0000 --94eb2c057a70f5adb0054a9beacc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > > let's break tradition and actually see what the document says. > =E2=80=8BLet's also break tradition and become a bit open minded to look at= bigger picture vs just consider on one specific solution to the problem. > 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. =E2=80=8BThat not correct if you do it right. If you can reach A via NH1 an= d NH2 and RS propagates both of those NHs to clients - it is up to clients to validate those NHs and choose one which they prefer for forwarding at a given point of time. RS does not need to be part of that game at all. > =E2=80=8B =E2=80=8B > This document proposes the use > of BFD between the two peering routers to detect a data plane > failure, =E2=80=8BBFD can be extended to work without protocol, object tracking =E2= =80=8Bcan used, passive or active probes traversing next hops etc ... but it's a local matter on the client. In fact it remains interesting to see what timers are required to handle BFD to say 1000 peers from a single box. Now comes BFD security with maintaining different MD5 keys across 1000 peers ! The draft says read RFC5880 and that's what is there. > =E2=80=8Ba=E2=80=8B > nd then uses a newly defined BGP SAFI to signal the state > of the data link to the route server(s). > =E2=80=8BSignalling anything to route servers is not needed. It puts us all= back to late 80s' or early 90s' on how networks were running at that time. and, if you wander over to the referenced route server docco, you'll see > that it already deals with alternate paths. > =E2=80=8BIt's not about "dealing with them" ... it is about distributing th= em to the clients so clients can use them. Thx, Robert=E2=80=8B --94eb2c057a70f5adb0054a9beacc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
let's break tradition and actually see what = the document says.

= =E2=80=8BLet's also break tradition and become a bit open minded to loo= k at bigger picture vs just consider on one specific solution to the proble= m.=C2=A0
=C2=A0
Abstract

=C2=A0 =C2=A0When route servers are used, the data plane is not congruent w= ith the
=C2=A0 =C2=A0control plane.=C2=A0 Therefore, the peers on the Internet exch= ange can
=C2=A0 =C2=A0lose data connectivity without the control plane being aware o= f it,
=C2=A0 =C2=A0and packets are dropped on the floor.=C2=A0


=E2=80=8BThat not c= orrect if you do it right. If you can reach A via NH1 and NH2 and RS propag= ates both of those NHs to clients - it is up to clients to validate those N= Hs and choose one which they prefer for forwarding at a given point of time= .=C2=A0

RS does not ne= ed to be part of that game at all.=C2=A0

=C2= =A0
=E2=80=8B =C2=A0 =E2=80=8B
This document proposes = the use
=C2=A0 =C2=A0of BFD between the two peering routers to detect a data plane<= br> =C2=A0 =C2=A0failure,

=E2=80=8BBFD can be extended to work without protocol, object tracking= =E2=80=8Bcan used, passive or active probes traversing next hops etc ... b= ut it's a local matter on the client.=C2=A0
In fact it remains interesting to see what timers= are required to handle BFD to say 1000 peers from a single box.=C2=A0

Now comes BFD securi= ty with maintaining different MD5 keys across 1000 peers ! The draft says r= ead RFC5880 and that's what is there.=C2=A0
=C2=A0
=E2=80=8Ba=E2=80=8Bnd then uses a newly defined BGP SAFI to signal the state
=C2=A0 =C2=A0of the data link to the route server(s).


=E2=80=8BSignalling= anything to route servers is not needed. It puts us all back to late 80s&#= 39; or early 90s' on how networks were running at that time.
=C2=A0

and, if you wander over to the referenced route server docco, y= ou'll see
that it already deals with alternate paths.

=
=E2=80=8BIt's not about "dealing with them= " ... it is about distributing them to the clients so clients can use = them.=C2=A0


=
Thx,
Robert=E2=80=8B


--94eb2c057a70f5adb0054a9beacc-- From nobody Mon Mar 13 09:58:31 2017 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 935B7129873; Mon, 13 Mar 2017 09:58:22 -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.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148942430257.16934.9532791236040123164@ietfa.amsl.com> Date: Mon, 13 Mar 2017 09:58:22 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgpls-segment-routing-epe-11.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 16:58:24 -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 of the IETF. Title : Segment Routing BGP Egress Peer Engineering BGP-LS Extensions Authors : Stefano Previdi Clarence Filsfils Keyur Patel Saikat Ray Jie Dong Mach (Guoyi) Chen Filename : draft-ietf-idr-bgpls-segment-routing-epe-11.txt Pages : 21 Date : 2017-03-13 Abstract: Segment Routing (SR) leverages source routing. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. A segment can represent any instruction, topological or service-based. SR allows to enforce a flow through any topological path and service chain while maintaining per-flow state only at the ingress node of the SR domain. The Segment Routing architecture can be directly applied to the MPLS dataplane with no change on the forwarding plane. It requires minor extension to the existing link-state routing protocols. This document outline a BGP-LS extension for exporting BGP peering node topology information (including its peers, interfaces and peering ASs) in a way that is exploitable in order to compute efficient BGP Peering Engineering policies and strategies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-segment-routing-epe/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-bgpls-segment-routing-epe-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgpls-segment-routing-epe-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 Mon Mar 13 10:29:51 2017 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E50D1298B5; Mon, 13 Mar 2017 10:29:44 -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.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148942618422.16959.13957745243259210361@ietfa.amsl.com> Date: Mon, 13 Mar 2017 10:29:44 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-flow-spec-v6-08.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 17:29:44 -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 of the IETF. Title : Dissemination of Flow Specification Rules for IPv6 Authors : Danny McPherson Robert Raszuk Burjiz Pithawala Andy Karch Susan Hares Filename : draft-ietf-idr-flow-spec-v6-08.txt Pages : 10 Date : 2017-03-13 Abstract: Dissemination of Flow Specification Rules [RFC5575] provides a protocol extension for propagation of traffic flow information for the purpose of rate limiting or filtering. The [RFC5575] specifies those extensions for IPv4 protocol data packets. This specification extends the current [RFC5575] and defines changes to the original document in order to make it also usable and applicable to IPv6 data packets. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-flow-spec-v6/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-flow-spec-v6-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-flow-spec-v6-08 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 Mar 13 13:06:52 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E57DE1294D5 for ; Mon, 13 Mar 2017 13:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.418 X-Spam-Level: X-Spam-Status: No, score=-1.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aAD-wjtJ3Gea for ; Mon, 13 Mar 2017 13:06:43 -0700 (PDT) Received: from mail-wm0-f42.google.com (mail-wm0-f42.google.com [74.125.82.42]) (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 AD381129B00 for ; Mon, 13 Mar 2017 13:06:43 -0700 (PDT) Received: by mail-wm0-f42.google.com with SMTP id n11so49083497wma.1 for ; Mon, 13 Mar 2017 13:06:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-disposition:user-agent; bh=veXaNIKM32ZXIklAvrvF13uw4coWh2HHR2ZBXwUETes=; b=C0LqShF4WEiZie+xbpxxfuW/828zMjC3BbCqHJM6d5VDBdO8iKo7yexHjVWeCP/WGO uLupXoP+jhU5AnIchaZQ6B80CuayDJgLFKMFQX3M8wf+vG81YsdfErhib3vtVaQsgbi5 Sn75//1eYjdOm5YzLoDQG4Zx8N+w8lZPvRuB8IJABwx50tryGBsf+RMsOfN2Cjs7Sd+C jkObw781Wj3gutc492udo1KdL0zyu47/hDu4LtlhIMpulux9jzpGYWy2eJaPZetuZP8s Lg2QOK3IJh5ZdobKFhKYKDe1okZKnMOmEo+4qeVIKTa3NpUcMGowBZGL6eXY4j36D/aa D94w== X-Gm-Message-State: AFeK/H3RRC8peuucKL0I1wRk8aHZQtNnTR5m5sY3MwTWk0riBEQS5pZoyTCNzVFxEhP7Dg== X-Received: by 10.28.150.194 with SMTP id y185mr11466174wmd.92.1489435601776; Mon, 13 Mar 2017 13:06:41 -0700 (PDT) Received: from localhost ([2001:67c:208c:10:d171:79c6:67cd:815b]) by smtp.gmail.com with ESMTPSA id v1sm26176451wra.65.2017.03.13.13.06.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Mar 2017 13:06:37 -0700 (PDT) Date: Mon, 13 Mar 2017 21:06:36 +0100 From: Job Snijders To: idr@ietf.org Message-ID: <20170313200636.mcarzfvikh5p5pce@Vurt.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett User-Agent: NeoMutt/20170306 (1.8.0) Archived-At: Subject: [Idr] preempt BGP parameter squatting through warnings/errors in idnits tool? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 20:06:45 -0000 Hi group, This morning I thought to myself: "isn't part of the codepoint squatting challenge our dependence on manual review of drafts for documented potential squatting?" Perhaps the idnits tool (https://tools.ietf.org/tools/idnits/about) can be updated in such a way to throw a warning or nit error when the Working group is "IDR" and the "IANA Considerations" section contains any of these regexes: [cCode] \(suggested [0-9]+\) suggested value .* [0-9]+\. [tT]he suggested value Or perhaps only look for these if the string 'TDB' doesn't occur anywhere the "IANA Considerations" section. I'm sure we can come up with some likely heuristics based on prior submissions to catch potential squatting-to-be. The idnits tools could make a suggestion like: "It appears this draft targetted for IDR is self servicing BGP codepoints, please review https://trac.ietf.org/trac/idr/wiki/Checklist%20for%20writing%20a%20BGP-related%20draft or contact the IDR chairs". Of course this may only be a small piece of the solution, but it could help instill discipline in this working group. Kind regards, Job From nobody Mon Mar 13 13:54:04 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C121F129496; Mon, 13 Mar 2017 13:54: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qXCkXeaXmxpq; Mon, 13 Mar 2017 13:54:02 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0124.outbound.protection.outlook.com [104.47.41.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E63E51293D6; Mon, 13 Mar 2017 13:54:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/7qu8L1U8QIWvjdmF4/tORwXGU25akIW3bl9zfcV8aU=; b=PismYVAtTOJ61zlX7aDUzKypGpEio9JxrnAiKMhGi95yeArQ99aAY3d37GFc0Cae0jhZyYgMtOT2PzCmsjGSOIh52x2h0niZaa7muoqjJzNhy7J9eKkVuSdO2m6AxbX0AZh+mN8+qafveoSZgF4if+izLKmmJlDSbfpmTAbnXgA= Authentication-Results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=juniper.net; Received: from [172.29.101.205] (66.129.239.13) by CO2PR05MB2502.namprd05.prod.outlook.com (10.166.95.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.977.5; Mon, 13 Mar 2017 20:53:59 +0000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "John G. Scudder" In-Reply-To: Date: Mon, 13 Mar 2017 16:53:54 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <41D02020-B0F5-478C-8FFE-5EEE93D29E06@juniper.net> References: <00f901d287e4$16ecb2f0$44c618d0$@ndzh.com> <10484_1487263806_58A5D83E_10484_6197_1_53C29892C857584299CBF5D05346208A1ED67062@OPEXCLILM21.corporate.adroot.infra.ftgroup> To: Stefano Previdi , Bruno Decraene X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.239.13] X-ClientProxiedBy: MWHPR2201CA0022.namprd22.prod.outlook.com (10.174.164.35) To CO2PR05MB2502.namprd05.prod.outlook.com (10.166.95.148) X-MS-Office365-Filtering-Correlation-Id: 01ecd29b-ec1f-48f3-1e44-08d46a531324 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CO2PR05MB2502; X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2502; 3:XxA0ec41XmcBlNOMHXf5jF2D+AZAlOt5k9knksTXGjI6awQj9xE+wBmRBGl7VY/dYVgfTnFElW94MUkKyt4+ZS+9QkDhZpjBLiwI1oO0tO50z64q+VEE2HtaycSTKY7y5MJgFkzhaK98t4JKqYjWa+ArDlUrv1Lgx8PWW6Ptvvpu7ryb62hRQq6tZ3sBwy5NT52ZKpk+EAE1kgdN/bLW0bHE6ml8cDsHL4gq+ki33NhqXbYlmSfhMeKVpZayuPGS7qPv04JTOBCU4OVOs0+VBWxPVj/2I0zkgCYUbVVBtTQ=; 25:ZLbPdyZUX7j4zOBfqyp9bnM2sjurekkFwsOpLXaGbu4SA2j8D70ODvpaMrGddxHsWG0BfkJtycEX4W1zM7sxYxZ9MWPBSO/7EVZfcGqmOA2c7FsxUKLMonS5nKP8Ec8cLQML4BLGYcTfVd3Ucw3uO81MuoOHv5xxa/lkpVccO8/TskNMjI3S62MrO6jnpwrMQf0OPcph6fjDA8GlPH1/pgFdsKMF0t55ZL/35Jdw852KfzbqlLfO51fJ7QZCDE+b5uhzoIi8dj106fPK61n+omgGtfQWcKZkk9verQMQElyRFsbZyRSoibNQ33xhBkk594o95SQ9eVQ45E3mVLhiAF3+OLHu1EpPatbetv714WcdRIUE+aWesuklwwfN8vLpgNvQW5yPunvHTDKQ+Imw6/2vqH0a2ji/NqohKIeofCebZbkzsEeoPD834Jw3hNUColpb14fiLX8HL10UAVvXrQ== X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2502; 31:64CuGAxbog7IizIsBFAZtVSLX25H+KSSD9oPID6c8uJSBzeIv6NTtnElHrOlr+JIpkipe4rsDH44+49tSbMxuBQqRYIJJadtr7zm1gVY2RO+fWrnQdadX4oisQgt4GQce/xYDJ8gV3c7j4gb7VFI9d/IlPAxFXECiZcEct3W7WUzqlgplMG5bljVplPgxCRZ2Y1P+4AUINB4w1JkPlRMtakTQwC4deVHyzTurVSIWyk9jmnnv7Kz5+CxCzUsb+JhYhmvaZ+tDcwV61wsgEwjq5I933iTNLtWkr8zLM92euQ=; 20:d7GzGRerdCElw8cBu5OQBVKQwj4Z6OSobHGlizi0DlEapJ59AXfzEJFZ1Q45UmbxGY1DNVzSiuM2KhJBpSl8eajGRNtBjoxgzRA+LdI+s52sI/IjQSTKxwfVQpPjc3xRMt4hBCnlBeB0N4LUr520N/T0xQiIM+T9UbgdlCRTc0tKp+He+7NAI8SiEEyi0z9hSfJM2Ke/T+twUyVQrTbwHuernY7TQCe8PXhLU5Ye2SbQUjpsZcRoRBSvd6TU0vZ+Z867tJIX/stS/0jX/7VksZrgKjrspPMwYHrKug42vv7pSxU0U7eGTJ4sDAGmH8psnmQFLdi2s3pWtegEU5ya/bDIyJk1YIVwQmj4BvM1VAHwYWGyYudLh2C2UuX3vUK1cPAH+ImbtKDVFnDMxknUyfDCawh6D3VG3QfxGc/PXhBwOFh9UrIOQ+WYQl2TcSIJGV00vdY0bSNW9odykFF6+qXLAeC3e1qmC7ymhq3b0eqX5No0WqNyIL7+DYjjCYmc X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(120809045254105)(138986009662008)(95692535739014)(18271650672692); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123555025)(20161123562025)(20161123564025)(20161123558025)(20161123560025)(6072148); SRVR:CO2PR05MB2502; BCL:0; PCL:0; RULEID:; SRVR:CO2PR05MB2502; X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2502; 4:dmazwngmNEe2vD0OIDFDSlDNfBeFijxrX+kgYfytU8e8jHkQEAcMDddaWqd0afYORDqT7zE+CsFtlxBwKih+nZCuED+fnuLDYChJAReO2X53OoyYvCWIVzouH0cSEYSgL0fSYKJfFUHxR484QybzqCaWWdl4r8Sy3S394ytyfDKyJicqmEvdSoJzIaCIK1mZ6/ZRK5LGtZ4LkyO1Px13e49U9xA9WFASLq1alPVN9IkmwXDwjd2ly3I9fkzbl0LFvecyBsiH7vP5/IlY3XiCJvtIgIL5wmG1X2O9EJIqt/EImk2GZA1N6GskDeSsQYKP9vZW687Ed+qLoInotCVQFYK7bul8BZETgs4xA3z2UfeYw4juwRmcTStMiau7uZVR5XldvuA4qXMzWJN19N41Ochcmr65LUN9HZdzkX9JW2dAC0HfTwuKsGaq0UHQeQTiSDy4m+csbUWr+cuAMzwP/H3rOX2MxtqXVdH8C2URY0ksWxKHlird5Sfu7+mr7/JFYBWM/lcVJMR9xP+M9sPZt6ETWZrH+s9BZbLJraMpzpU8+oYcdj6oPROqIFnOjs9KNykaBJ9XvpraEqatsm6aA1Yj7WsavgmSZvC/sMJXoRIwkv86sUmWK1jbMEfnxCU+MgoIhtOGgOt9VeUIOsQF3te5MU0C2SvJbH/kYxSDuqzxVjnN09rFMYM/SC8mMnrVsAOu1plv6VggVFEQQCuOta5rby5ZotpY3rfNL77kXNr5XBqdlLg8m7Xkl5K1n3aFlmRHmn9g/dSh9GWcvZHucg== X-Forefront-PRVS: 0245702D7B X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(39410400002)(39860400002)(39850400002)(39840400002)(39450400003)(377454003)(5423002)(24454002)(189998001)(6666003)(54906002)(6306002)(33656002)(8746002)(66066001)(36756003)(86362001)(47776003)(4326008)(57306001)(50226002)(90366009)(6486002)(77096006)(50466002)(25786008)(8676002)(81166006)(23676002)(2906002)(229853002)(5890100001)(53936002)(2950100002)(93886004)(42186005)(230783001)(83716003)(82746002)(50986999)(7736002)(6116002)(3846002)(305945005)(76176999)(38730400002)(6246003)(5660300001)(53546007)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB2502; H:[172.29.101.205]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDTzJQUjA1TUIyNTAyOzIzOk5FZjBEMEsrMnBTU0VndVJwU0IrbmtTS0tU?= =?utf-8?B?Nk8wZklwOXlKM3Arc1lrVTJsZ1IrOEo3MitaOXhTVm5Palh5UGZ0UFNGQ0V1?= =?utf-8?B?L1ZlTTZnQmZvZDJ3T2lPNW5MZG1zSFd6SkhxN1U3cFJUVmRxTU8waWhYVDM2?= =?utf-8?B?L3JQTkNtYjNmbDNydXRXVkRxTXJWSmlaaGhucE1ndnJTV1ZOUWJkbG5CVWJR?= =?utf-8?B?YzYxSDJWUEpXZFVGNmYrQ0o5OS92dDVJYUR4Mmd0cFVtZmhBOERyaDNaUFJP?= =?utf-8?B?dTVMWWJOWVBtakxGNkFzUndCMG4zY0lxaDBkV3VJS2RpYlZjbXUrYTlmdjBp?= =?utf-8?B?cXdQYmZQdzF6QnlScTZLb1NkV3J1ZVh2U3Z1WCs1dzljSFFFMk9RblVBRy94?= =?utf-8?B?elVhcmxIQXJOQVRWUG5LZVdXUWdBSFdJUWd6RFVMbTdwQ1k4eEM1YkkyR0w5?= =?utf-8?B?YjJON2IwNHZMZkRrRFNrb0NSYzhWTmNQQXdMTHdsNGEwb1BCbEthby9lUUpZ?= =?utf-8?B?cXh4SW5LSXFDcGVHVXQybWY3TWJSZHp2OE9uZ3pXKzV2aEpjS29jb1pVR0Iw?= =?utf-8?B?WTM3S0V4RVJDK3U0N0NqOTgvTFVOZ1lXczcyNDMzamh5Ty9zQkpjQ2g5cXB3?= =?utf-8?B?YS9mcmdjVEcvNEhWZlYreURNTjM2VnFaNTlSS0xzMm81QVU0NmxsdnFEQlJl?= =?utf-8?B?V1hFREk2aW5HWUcvN0RtR0ZoNlFuWWtKOW5KQVRMWUVBQVZwZFhXbXA3bU9H?= =?utf-8?B?S25WQmc5Qmh0OENiTGk2elhyRldFQ042RGVIMWllT0xmZk5ibHJGWXNaU2JN?= =?utf-8?B?MTJTbjRXYnM1Yis5WlhmR25SVURSOU9hYTU0K2E0QWdEbTQ5d3RUSm40bXRJ?= =?utf-8?B?R2dFM2pzMlUxcFlCbVp3U09hd0VTQzgwVkhYb241bW8wYXpLSUFLdFNlS0FX?= =?utf-8?B?aitsMXpQclhQY3Q0VEdMQndLWVMxaThyK0pEbzF6bmZhOElhNGdQY3h1c1Q5?= =?utf-8?B?YWR6cVIvc2c5K1ZCVVBDS2Z1bUpqY0VmT083M3owYkd5cW04bWtGNnR5MWVr?= =?utf-8?B?aDVYY25nVkx2TjNhN0t2SzJqQ2k3bm1zdHJxeSs1OEYvWlJpOFRxeUJkSDdQ?= =?utf-8?B?MkJUbmkrcjB0MUZwTkZTV0tKTmQ5QmdRcFgrNUVKdGFSaTlNdXo3VlpNMnlE?= =?utf-8?B?Ym1CcEJYUWtCd1JENGdKZGM0M052akZRZ2JBd0p5blppaEViQVoyWi9VT21h?= =?utf-8?B?VjA4dFhxalBSdTU3TElYK2FGQjFQeWxiNTdnQ0R3M3ZGejlXNzAwZ0kwaGJ0?= =?utf-8?B?eXpTeEhpSlpNY3VQNUQ0a2t1bGlNZWw5U29BWlNYUEJWQ1dZQzgrKy96bjBz?= =?utf-8?B?MHJEckx3aWduRlhVZTZySlJDVk9vRkR6aEpSQlJyL2hrbTBWMEhiV1JnN0lu?= =?utf-8?B?ckhWanVlUDJYc284MzBYS052d21ITFloNGtIZWZQeThiVmx6aGpwNVpXNlpE?= =?utf-8?B?V1NPdkZKMWpnM1BmUFNsRlQ3cnBvZWtpU2VSWGROVzR1L05lZnFSaWE4Y3VD?= =?utf-8?B?d0NJM1dRRk9jYmtjQi92SG53aFp6ZmJaNE9tTlBvbFlxdXN5TWJVbTk2K2ty?= =?utf-8?B?TWFYVTJpeE9tdG0zTEpuNndQdVRnVlBnbm1VZDRqOGxQdUptdS9RbVVjQzhP?= =?utf-8?B?d20vVlg4NUpHUHNxTS9pRWtiQk1zb2hmdks5OWZzakdqeitJNTBUejl6TVlo?= =?utf-8?Q?E8lH3+F4ZdfK8klnn/3zEeCVcVKHVOEji1vtM=3D?= X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2502; 6:EFqjadZ1/UI2pmkT75geGk/rvw7iMhfW1vh/SrcZJibtlxLatSjiZs1R5tmQFXK3XERlN+WMpbTnnw0yz6bdv+vYgzh9p159Omz6FTNoLngEYqOTd+PjMDDV4Dcub+U5ZtwWTgkwadGUErxPNG+63DihxdfcsMg4n0wSFg3bVWpuPnnjtGS0jSndpaYb1sPBIvx9YVZTQ4xXDIIFZxFwOnSyeDeavzVVhHep+WSsY+c8PSDIK+XsU5KBz3EhSL5YvvfSUYLXfduZGtyrXefbmF3ViS65S3Lk5oz1cBZfJqCYQlqYon8E39Szk3ez7AekHTS656xZAQBnp5AJf1/NpeRLKogCB3gh6/k0qk6iTe9D1n/XAu1joKWkfxqf180KnPxquG7yoJ1jiXVJ6JLMnlCaPAPlc+cSFUyallBgFFQ=; 5:2Y8ye3JjQOE+MziagMCWwr40CCQeMZuuxqqsgixbJPdMZS40En0/13n2JRNLux5jilxVErCYm8Rho/UwIX4JrV2Vzs2hj3Bw0bYHrXSUu4RzKsxplffqvkXFJ9V0Z1bIE6P8xTel8/cFSVNy0Z520w==; 24:GKVZXFiYV6ohx7jkBsvzxIziEZQocGHtJMeRpGeLnFC5FnEUie7C06j6Wc7Gl76UJxbx7ciayyir/a7U28EsNFoLdjFuMAILWi7yIHe0mlk= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2502; 7:b2yyvu+t4uibsHuA+gmwNlSBME5Y17JMR26oUqzgBsvnJV7KYEY2g8ZS8n25f1w3Ox0Tc3Jo0rKvkvF0KRw3+Gsq2ywE16EvWOGkflupml22JmbZ9pv6LRWb3EsLpcStXzgpBhBcfMKrlj9D85Z1f8LOdyUk1VuwJ177xVZGzgVsPEwoggKtwiPO0vf5JP0gELb5BFosS1YzwJdU7ir0nhqkdmvm2FYyxHA6m59LI5LEvzSUT3/awQs8GiDKNfmWnmd8bWFJJjFHtgwHV/ZfZrXCnKr58hUc3VOUEuOiZQUTKqk2TThNfQ3m4p3+qUkjRJxKjnp2rph/64XDnO/PmA== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Mar 2017 20:53:59.1657 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB2502 Archived-At: Cc: "idr@ietf.org" , "spring@ietf.org" , "draft-ietf-idr-bgpls-segment-routing-epe@ietf.org" , Susan Hares Subject: Re: [Idr] [spring] IDR WG 2 week WG LC on draft-ietf-idr-bgpls-segment-routing-epe - (2/15/2017 to 3/1/2017) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 20:54:04 -0000 Thanks, Stefano. Bruno, at your convenience can you confirm that you're satisfied with = the resolution? Looks OK to me even though the changes don't precisely = adhere to your suggestions ("Link NLRI uses the Protocol-ID value" = instead of "Link NLRI uses the BGP Protocol-ID value"). The rfcdiff is = https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-bgpls-segment-routing= -epe-11.txt --John > On Mar 13, 2017, at 6:31 AM, Stefano Previdi (sprevidi) = wrote: >=20 > John, Bruno, >=20 > sorry for having missed that. I=E2=80=99ll resubmit right now. I = integrated all comments. Regarding the missing "section 3.1" (referring = to the isis draft), I replaced text with the reference to = draft-ietf-idr-bgp-ls-segment-routing-ext which defines the bgp-ls tlv = for advertising the SRGB. I gave this as an example. I also moved = draft-ietf-spring-segment-routing into the normative references section. >=20 > Thanks. >=20 > s. >=20 >=20 >> On Mar 10, 2017, at 8:52 PM, John G.Scudder wrote: >>=20 >> Hi Authors, >>=20 >> I see that yesterday's -10 revision doesn't address Bruno's comments, = below. Can you please either update the document if you accept Bruno's = suggestions, or otherwise discuss them on the list? We can't declare the = WGLC to be satisfactorily finished until this is resolved. >>=20 >> Thanks, >>=20 >> --John >>=20 >>> On Feb 16, 2017, at 11:50 AM, bruno.decraene@orange.com wrote: >>>=20 >>> Hi, >>>=20 >>> I=E2=80=99ve read the draft, please find below some minor comments: >>>=20 >>> --- >>> =C2=A74.3 >>> " * A 4 octet index defining the offset in the SID/Label space = advertised by this router using the encodings defined in Section 3.1." >>>=20 >>> - Following the recent addition of the SRLB Label Space, I'd rather = have the text explicitly refers to name of that Label space. e.g. >>> OLD: SID/Label space >>> NEW: SRGB >>>=20 >>> - Which (SRGB) advertisement? I'm assuming the IGP one, but I guess = someone may imagine using the BGP "Originator SRGB TLV". Then what if = the node runs multiple IGP with different SRGB configured? >>>=20 >>> - Note that this document has no "Section 3.1". The text seems = borrowed from the IS-IS SR draft, hence may be adding the name of this = draft would just solve the point. (with a normative reference to this = IS-IS draft) >>>=20 >>> --- >>> OLD: The Link NLRI uses the new Protocol-ID value (to be assigned by = IANA) >>> proposed NEW: The Link NLRI uses the BGP Protocol-ID (TBD1) >>>=20 >>> (=E2=80=9Cnew=E2=80=9D may become unspecific 2 years from now) >>>=20 >>> --- >>> One could probably argue that [I-D.ietf-spring-segment-routing] = should be a normative reference. >>>=20 >>> Thanks, >>> Regards, >>> --Bruno >>>=20 >>>=20 >>> From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Susan = Hares >>> Sent: Thursday, February 16, 2017 12:35 AM >>> To: idr@ietf.org >>> Cc: 'Alvaro Retana (aretana)'; spring@ietf.org >>> Subject: [spring] IDR WG 2 week WG LC on = draft-ietf-idr-bgpls-segment-routing-epe - (2/15/2017 to 3/1/2017) >>>=20 >>> This begins a 2 week IDR WG last call on = draft-ietf-idr-bgpls-segment-routing-epe from (2/15 to 3/1/2017) = There are two implementations describe on the wiki at: >>> = https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-segment-routing-e= pe%20 >>>=20 >>> The two implementation are from Cisco IOS-XR release 6.0.2 and = Cisco Nexus Switch N9000/N3000 platforms running NX-OS 7.0(3)I1(1) or = greater. The authors will indicate on the list and in the wiki the = following information : >>>=20 >>> 1) Were these implementations separate implementations? >>> 2) What were the results of the interoperability tests? >>>=20 >>> This work is linked to the = draft-ietf-spring-segment-routing-central-epe work in the SPRING WG. = Based on the two drafts, the WG should might consider: =20 >>> 1) Is there need for this work in deployments in networks/ >>> 2) Is this technically ready for publication? >>> 3) Does it fit with the spring informational draft? >>>=20 >>> For the ease of reference the web references are below: >>> = https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-segment-routing-epe/= >>> = https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-central= -epe/ >>>=20 >>> Sue Hares=20 >>> = __________________________________________________________________________= _______________________________________________ >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> _______________________________________________ >>> Idr mailing list >>> Idr@ietf.org >>> https://www.ietf.org/mailman/listinfo/idr >>=20 >=20 From nobody Mon Mar 13 14:16:41 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43F0E129B06 for ; Mon, 13 Mar 2017 14:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82_kfgxwqXzb for ; Mon, 13 Mar 2017 14:16:39 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 02E3512941C for ; Mon, 13 Mar 2017 14:16:38 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=70.194.5.9; From: "Susan Hares" To: "'Dongjie \(Jimmy\)'" , "'John G. Scudder'" , "'idr wg'" Date: Mon, 13 Mar 2017 17:11:45 -0400 Message-ID: <03ae01d29c3e$6c5d87a0$451896e0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03AF_01D29C1C.E54D9550" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdKcPVPh3IELTHU6SJ2Iz/aG+zZH9g== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [Idr] Request for 2 drafts X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 21:16:40 -0000 This is a multipart message in MIME format. ------=_NextPart_000_03AF_01D29C1C.E54D9550 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Jie, John and y'all IDR folks: I'd like to follow-up on our "clean up" the attribute area discussion. I've published: draft-hares-deprecate-atomic-aggregate-00 draft-hares-idr-bgp-registries-00.txt I'd like a presentation slot to continue our discussion. It might be good near Jeff's document on the same topic (if he's asking for a slot). Sue PS - I know the first one does not have a BGP or idr title. It's on purpose. ------=_NextPart_000_03AF_01D29C1C.E54D9550 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Jie, John = and y’all IDR folks:

 

<individual contributor hat on> =

 

I’d like to follow-up on our “clean = up” the attribute area discussion.

 

I’ve = published:

 

draft-hares-deprecate-atomic-aggregate-00  =

draft-hares-idr-bgp-registries-00.txt

 

I’d = like a presentation slot to continue our discussion.  It might be = good near Jeff’s document on the same topic (if he’s asking = for a slot).

 

 

<individual contributor hat off> =

 

Sue

 

PS – I = know the first one does not have a BGP or idr title.  It’s on = purpose.    

 

 

 

 

------=_NextPart_000_03AF_01D29C1C.E54D9550-- From nobody Mon Mar 13 14:26:29 2017 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F733129406; Mon, 13 Mar 2017 14:26:27 -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.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148944038756.20276.10433880975348907444@ietfa.amsl.com> Date: Mon, 13 Mar 2017 14:26:27 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-flowspec-oid-04.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 21:26:27 -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 of the IETF. Title : Revised Validation Procedure for BGP Flow Specifications Authors : James Uttaro Juan Alcaide Clarence Filsfils David Smith Pradosh Mohapatra Filename : draft-ietf-idr-bgp-flowspec-oid-04.txt Pages : 9 Date : 2017-03-13 Abstract: This document describes a modification to the validation procedure defined in RFC 5575 for the dissemination of BGP flow specifications. RFC 5575 requires that the originator of the flow specification matches the originator of the best-match unicast route for the destination prefix embedded in the flow specification. This allows only BGP speakers within the data forwarding path (such as autonomous system border routers) to originate BGP flow specifications. Though it is possible to disseminate such flow specifications directly from border routers, it may be operationally cumbersome in an autonomous system with a large number of border routers having complex BGP policies. The modification proposed herein enables flow specifications to be originated from a centralized BGP route controller. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-flowspec-oid/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-bgp-flowspec-oid-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-flowspec-oid-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 13 17:46:21 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C27E6129410 for ; Mon, 13 Mar 2017 17:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cmke9uU-XEE0 for ; Mon, 13 Mar 2017 17:46:18 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA8B1129426 for ; Mon, 13 Mar 2017 17:46:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8454; q=dns/txt; s=iport; t=1489452377; x=1490661977; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=MI56Bp9HRArb4l7sk5U97glgAgilGKgiHoZjoqPPkJw=; b=KYrYy/79t+gOzXh3U9napuL7v7VwhXzHLQBLDX8FSklm9pXRFqeqcZ8W KxesRiYwhwyMytisbpmGPDh0uQHDjgi7kES+xg/Tg3pqrQIPJd+mgzLtK nVyX3ZykWWXBj3YMSDAqAvcAk4mphRQwSthHNismAwEcEb7pFi84EFdyy s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BDAQD5O8dY/5ldJa1cARkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJuY2GBCgeNZpFRkA6FLYIOLIV2AoJiPxgBAgEBAQEBAQFrKIU?= =?us-ascii?q?VAQEBAQMtTBACAQgRBAEBGgIMBzIUCQgBAQQBDQUIiXgOsACKYgEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBARgFhk6DZoEJhQonAYUHBY9bhiWGQQGGdYs6ggSFJYoFk0I?= =?us-ascii?q?BHziBBFgVhxh1AYhUAYEMAQEB?= X-IronPort-AV: E=Sophos;i="5.36,161,1486425600"; d="scan'208,217";a="397438442" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Mar 2017 00:46:16 +0000 Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v2E0kGuD024160 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 14 Mar 2017 00:46:16 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 13 Mar 2017 19:46:16 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Mon, 13 Mar 2017 19:46:16 -0500 From: "Jakob Heitz (jheitz)" To: "Dongjie (Jimmy)" , Susan Hares , "John G. Scudder" Thread-Topic: IETF98 agenda topics Thread-Index: AdKaOZ0k0vmUEiqeSiKyMVPekGCYxgCImbTg Date: Tue, 14 Mar 2017 00:46:16 +0000 Message-ID: References: <76CD132C3ADEF848BD84D028D243C927935B96C0@NKGEML515-MBS.china.huawei.com> In-Reply-To: <76CD132C3ADEF848BD84D028D243C927935B96C0@NKGEML515-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [128.107.151.21] Content-Type: multipart/alternative; boundary="_000_df8fbbdbe0f84b3e931bf6eaa7208354XCHALN014ciscocom_" MIME-Version: 1.0 Archived-At: Cc: idr wg Subject: Re: [Idr] IETF98 agenda topics X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 00:46:19 -0000 --_000_df8fbbdbe0f84b3e931bf6eaa7208354XCHALN014ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'd like 10 minutes to present https://tools.ietf.org/html/draft-idr-bgp-rt-oscillation-01 (the .00 version was never presented) Thanks, Jakob. From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Dongjie (Jimmy) Sent: Friday, March 10, 2017 11:34 PM To: idr wg Cc: Susan Hares Subject: [Idr] IETF98 agenda topics Dear all, IDR will meet at IETF98 on Friday, March 31 from 9:00 to 11:30. Please forw= ard any IDR agenda items you might have to me and CC the chairs, the deadli= ne is March 17 by 10:00 U.S. Eastern Time. Priority will be given to those = who get their requests in by the deadline, though if agenda space permits i= t we will consider requests gotten in before March 22 at 10:00 U.S. Eastern= Time. Please include the name of the person who will be presenting, and th= e estimate time you'll need (including Q/A). If you plan to make a presentation, please keep in mind the IDR tradition, = "no Internet Draft - no time slot". You should also plan to send your slide= s to me and CC the chairs no later than 24 hours prior to the meeting, thou= gh earlier is better. If we don't have your slides by the deadline, you may= lose your slot. Please number your slides for the benefit of remote attend= ees. If you plan to use any fancy builds or transitions you must arrange th= is with us in advance -- otherwise you should assume your slides may be con= verted to PDF and presented from the PDF. Potential presenters, please take a look at the checklist for presenting at= IDR: https://trac.tools.ietf.org/wg/idr/trac/wiki/Checklist%20for%20presenting%2= 0at%20an%20IDR%20meeting Best regards, Jie --_000_df8fbbdbe0f84b3e931bf6eaa7208354XCHALN014ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I'd like 10 minutes to present

https://tools.ietf.org/html/draft-idr-bgp-rt-os= cillation-01

 

(the .00 version was never presented)

 

T= hanks,

J= akob.

 

From: = Idr [mailto:idr-bounces@ietf.org] On Behalf Of Dongjie (Jimmy)
Sent: Friday, March 10, 2017 11:34 PM
To: idr wg <idr@ietf.org>
Cc: Susan Hares <shares@ndzh.com>
Subject: [Idr] IETF98 agenda topics

 =

Dear all,

 

IDR will meet at IETF98 on Friday, March 31 from 9:0= 0 to 11:30. Please forward any IDR agenda items you might have to me and CC= the chairs, the deadline is March 17 by 10:00 U.S. Eastern Time. Priority = will be given to those who get their requests in by the deadline, though if agenda space permits it we will con= sider requests gotten in before March 22 at 10:00 U.S. Eastern Time. Please= include the name of the person who will be presenting, and the estimate ti= me you'll need (including Q/A).

 

If you plan to make a presentation, please keep in m= ind the IDR tradition, "no Internet Draft - no time slot". You sh= ould also plan to send your slides to me and CC the chairs no later than 24= hours prior to the meeting, though earlier is better. If we don't have your slides by the deadline, you may lose your= slot. Please number your slides for the benefit of remote attendees. If yo= u plan to use any fancy builds or transitions you must arrange this with us= in advance -- otherwise you should assume your slides may be converted to PDF and presented from the PDF.

 

Potential presenters, please take a look at the chec= klist for presenting at IDR:

https://trac.to= ols.ietf.org/wg/idr/trac/wiki/Checklist%20for%20presenting%20at%20an%20IDR%= 20meeting

 

Best regards,

Jie

--_000_df8fbbdbe0f84b3e931bf6eaa7208354XCHALN014ciscocom_-- From nobody Mon Mar 13 19:46:59 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8B2C12962E for ; Mon, 13 Mar 2017 19:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.115 X-Spam-Level: X-Spam-Status: No, score=-1.115 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SbhNRdznMfBp for ; Mon, 13 Mar 2017 19:46:56 -0700 (PDT) Received: from APC01-SG2-obe.outbound.protection.outlook.com (mail-oln040092253069.outbound.protection.outlook.com [40.92.253.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C5E11297EC for ; Mon, 13 Mar 2017 19:46:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=bhBj4jY5S1V4ea1q0KHw3in014eWzrKjTeC+qi8R7ak=; b=byDjyYXR1t6PXa5GJWerhnq+SZxmUX2ftYI09wJYRPtACG874kEb7C+TWTlEdCagfeZhUYTkbauHXh0CeKYOGvamstImVpyRfxRgS/77Nk/fOIIhxV3E9jLdhHdjmPsCd9KPOYTnOt2nJDjM1BYesogM+4j620ziVmUFA4Hwr/K0MDxbHLhAOhLJjcBoWGuu9//8L4/VrlIQ6qditTlmDGtgfHaH2lnn0zt5CG24E6grvynyArQ48eU0GmOS20JvVyrc8gOH3Fgrg4mUZuTyxZFl+VL6K23vFeSkv6Rr2tnaMTv8of+AaZbLgr56qVpPpIDvObQg/P2a+sWTa3d9zQ== Received: from HK2APC01FT014.eop-APC01.prod.protection.outlook.com (10.152.248.52) by HK2APC01HT216.eop-APC01.prod.protection.outlook.com (10.152.249.53) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.7; Tue, 14 Mar 2017 02:46:52 +0000 Received: from SG2PR0601MB1376.apcprd06.prod.outlook.com (10.152.248.57) by HK2APC01FT014.mail.protection.outlook.com (10.152.248.103) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.7 via Frontend Transport; Tue, 14 Mar 2017 02:46:52 +0000 Received: from SG2PR0601MB1376.apcprd06.prod.outlook.com ([10.169.105.150]) by SG2PR0601MB1376.apcprd06.prod.outlook.com ([10.169.105.150]) with mapi id 15.01.0961.021; Tue, 14 Mar 2017 02:46:51 +0000 From: li zhenqiang To: "Jakob Heitz (jheitz)" , "Dongjie (Jimmy)" , shares , John Scudder Thread-Topic: [Idr] IETF98 agenda topics Thread-Index: AQHSnG07qbNO2oblZkaPt2miTYOwhw== Date: Tue, 14 Mar 2017 02:46:51 +0000 Message-ID: References: <76CD132C3ADEF848BD84D028D243C927935B96C0@NKGEML515-MBS.china.huawei.com>, Accept-Language: zh-CN, 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;cisco.com; dmarc=none action=none header.from=hotmail.com; x-incomingtopheadermarker: OriginalChecksum:CE791DF7D2A730E574F46EEB8C8A587E7705C562391AB3503085FE0A2546BCF8; UpperCasedChecksum:E153BA61951AB34B61D3C68B2735EAC2A115521FF5E7748B85E6E618806952D2; SizeAsReceived:7705; Count:36 x-ms-exchange-messagesentrepresentingtype: 1 x-incomingheadercount: 36 x-eopattributedmessage: 0 x-microsoft-exchange-diagnostics: 1; HK2APC01HT216; 5:Tfk6+oYbevFco6741VP9DJchSmbL8XWmDza26YV16mBAe4vJ4p3uwkaBfDwwUv8t7U0voC8BWq+UmoABpum1bnkVAZNY8/dQyZmsZK8ju0XpsvXl9xZYj/zW9/X+8Rrd6b9jXdEzpPgvNYU7Wo94bs3TxI9zELGUbWkqe0Cewog=; 24:oxh2Rco59gjp8iCTy6qFQbktHk0LZAvu7SlF3HXKnhTejNwfRkT4Dir0g7hwhWbomN7rA3U43GkH+q+qNor6nhEo915c8g8ZSuKsjB13OTE=; 7:fX/INYhp74EzbzneBWqXilL8qRsZUKXX8WGzzNi38AGMFCQQcfxjjE4MoZGs4UB4oZJ+tWAq57jbwHpM87h0OzZ/+JeEAXWTGLjejiYtgvL3alZ2NY66C4tHlzbS6b+iCkbFPWOUai1YbDeJw9Jtym2zaoBwdW1qju29lX2FdNWDrFUrSjrm1Lw16As8zGi8UzBv+vsxNowzHuvAkseRML2Bb9QJ8OzT80AfdxVeZ5LGakF+OUdvCIdls6SXcdVaO58AwbE+LoSCOrbqcg8S1JNbJTGQzMImIEWNpwjtdVRaLDMnfJrjO4JM1p12o2Q7 x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(7070007)(98900017); DIR:OUT; SFP:1901; SCL:1; SRVR:HK2APC01HT216; H:SG2PR0601MB1376.apcprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; x-ms-office365-filtering-correlation-id: 83dcbdcb-00d3-4899-f8b6-08d46a845c08 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201702061074)(5061506573)(5061507331)(1603103135)(1601125254)(1603101448)(1701031045); SRVR:HK2APC01HT216; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:HK2APC01HT216; BCL:0; PCL:0; RULEID:; SRVR:HK2APC01HT216; x-forefront-prvs: 02462830BE spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SG2PR0601MB1376D74C79DEB88C2B264B17FC240SG2PR0601MB1376_" MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Mar 2017 02:46:51.8246 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: HK2APC01HT216 Archived-At: Cc: idr Subject: Re: [Idr] IETF98 agenda topics X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 02:46:57 -0000 --_000_SG2PR0601MB1376D74C79DEB88C2B264B17FC240SG2PR0601MB1376_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear WG Chairs, I'd like a time slot to present Populate to FIB Action for FlowSpec. 5 minu= tes is ok. The link for the draft is https://datatracker.ietf.org/doc/draft= -li-idr-flowspec-populate-to-fib/ . Thank you very much. Best Regards, ________________________________ li_zhenqiang@hotmail.com From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Dongjie (Jimmy) Sent: Friday, March 10, 2017 11:34 PM To: idr wg Cc: Susan Hares Subject: [Idr] IETF98 agenda topics Dear all, IDR will meet at IETF98 on Friday, March 31 from 9:00 to 11:30. Please forw= ard any IDR agenda items you might have to me and CC the chairs, the deadli= ne is March 17 by 10:00 U.S. Eastern Time. Priority will be given to those = who get their requests in by the deadline, though if agenda space permits i= t we will consider requests gotten in before March 22 at 10:00 U.S. Eastern= Time. Please include the name of the person who will be presenting, and th= e estimate time you'll need (including Q/A). If you plan to make a presentation, please keep in mind the IDR tradition, = "no Internet Draft - no time slot". You should also plan to send your slide= s to me and CC the chairs no later than 24 hours prior to the meeting, thou= gh earlier is better. If we don't have your slides by the deadline, you may= lose your slot. Please number your slides for the benefit of remote attend= ees. If you plan to use any fancy builds or transitions you must arrange th= is with us in advance -- otherwise you should assume your slides may be con= verted to PDF and presented from the PDF. Potential presenters, please take a look at the checklist for presenting at= IDR: https://trac.tools.ietf.org/wg/idr/trac/wiki/Checklist%20for%20presenting%2= 0at%20an%20IDR%20meeting Best regards, Jie --_000_SG2PR0601MB1376D74C79DEB88C2B264B17FC240SG2PR0601MB1376_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <9242A1806E187C4BA4BBB5F9CC8E636D@apcprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Dear WG Chairs,

I'd like a time slot to present Populate to FIB Action for Fl= owSpec. 5 minutes is ok. The link for the draft is h= ttps://datatracker.ietf.org/doc/draft-li-idr-flowspec-populate-to-fib/<= span style=3D"color: rgb(0, 0, 0); font-size: 10.5pt; line-height: 1.5; bac= kground-color: rgba(0, 0, 0, 0);"> .

Thank you very much.

Best Regards,
li_zhenqiang@hotmail.com

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Dongjie (Jimmy)
Sent: Friday, March 10, 2017 11:34 PM
To: idr wg <idr@ietf.org>
Cc: Susan Hares <shares@ndzh.com>
Subject: [Idr] IETF98 agenda topics

 

Dear all,

 

IDR will meet at IETF98 on Friday, March 31 from 9:00 to 11:30. Please forw= ard any IDR agenda items you might have to me and CC the chairs, the deadli= ne is March 17 by 10:00 U.S. Eastern Time. Priority will be given to those = who get their requests in by the deadline, though if agenda space permits it we will consider requests gott= en in before March 22 at 10:00 U.S. Eastern Time. Please include the name o= f the person who will be presenting, and the estimate time you'll need (inc= luding Q/A).

 

If you plan to make a presentation, please keep in mind the IDR tradition, = "no Internet Draft - no time slot". You should also plan to send = your slides to me and CC the chairs no later than 24 hours prior to the mee= ting, though earlier is better. If we don't have your slides by the deadline, you may lose your slot. Please number yo= ur slides for the benefit of remote attendees. If you plan to use any fancy= builds or transitions you must arrange this with us in advance -- otherwis= e you should assume your slides may be converted to PDF and presented from the PDF.

 

Potential presenters, please take a look at the checklist for presenting at= IDR:

https://trac.tools.ietf.org/wg/idr/trac/wiki/Checklist%20for%2= 0presenting%20at%20an%20IDR%20meeting

 

Best regards,

Jie

--_000_SG2PR0601MB1376D74C79DEB88C2B264B17FC240SG2PR0601MB1376_-- From nobody Mon Mar 13 20:16:03 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 576D312949B for ; Mon, 13 Mar 2017 20:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n6lP6hzLtcMF for ; Mon, 13 Mar 2017 20:15:59 -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 623DC1293F5 for ; Mon, 13 Mar 2017 20:15:58 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML714-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DIV06378; Tue, 14 Mar 2017 03:15:56 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 14 Mar 2017 03:15:55 +0000 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.160]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Tue, 14 Mar 2017 11:15:49 +0800 From: "Dongjie (Jimmy)" To: Susan Hares , "'John G. Scudder'" , "'idr wg'" Thread-Topic: Request for 2 drafts Thread-Index: AdKcPVPh3IELTHU6SJ2Iz/aG+zZH9gAM0oVA Date: Tue, 14 Mar 2017 03:15:48 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C927935BD242@NKGEML515-MBS.china.huawei.com> References: <03ae01d29c3e$6c5d87a0$451896e0$@ndzh.com> In-Reply-To: <03ae01d29c3e$6c5d87a0$451896e0$@ndzh.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.151.75] Content-Type: multipart/alternative; boundary="_000_76CD132C3ADEF848BD84D028D243C927935BD242NKGEML515MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.58C7606C.006E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.160, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: c66127e57cbf92218690b0237d0d8152 Archived-At: Subject: Re: [Idr] Request for 2 drafts X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 03:16:01 -0000 --_000_76CD132C3ADEF848BD84D028D243C927935BD242NKGEML515MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sue, I've added your presentation to the tentative agenda, could you also let me= know the desired duration of your presentation? Thanks. Best regards, Jie From: Susan Hares [mailto:shares@ndzh.com] Sent: Tuesday, March 14, 2017 5:12 AM To: Dongjie (Jimmy) ; 'John G. Scudder' ; 'idr wg' Subject: Request for 2 drafts Jie, John and y'all IDR folks: I'd like to follow-up on our "clean up" the attribute area discussion. I've published: draft-hares-deprecate-atomic-aggregate-00 draft-hares-idr-bgp-registries-00.txt I'd like a presentation slot to continue our discussion. It might be good = near Jeff's document on the same topic (if he's asking for a slot). Sue PS - I know the first one does not have a BGP or idr title. It's on purpos= e. --_000_76CD132C3ADEF848BD84D028D243C927935BD242NKGEML515MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Sue,

 

I’ve added your presentation to the tentative agenda, could= you also let me know the desired duration of your presentation? Thanks.

 

Best regards,

Jie

 

From: Susan Hares [mailto:shares@ndzh.com]
Sent: Tuesday, March 14, 2017 5:12 AM
To: Dongjie (Jimmy) <jie.dong@huawei.com>; 'John G. Scudder' &= lt;jgs@juniper.net>; 'idr wg' <idr@ietf.org>
Subject: Request for 2 drafts

 

Jie, John and y’all IDR f= olks:

 

<individual contributor hat = on>

 

I’d like to follow-up on = our “clean up” the attribute area discussion.

 

I’ve published:

 

draft-hares-deprecate-atomic-ag= gregate-00 

draft-hares-idr-bgp-registries-= 00.txt

 

I’d like a presentation s= lot to continue our discussion.  It might be good near Jeff’s do= cument on the same topic (if he’s asking for a slot).

 

 

<individual contributor hat = off>

 

Sue

 

PS – I know the first one= does not have a BGP or idr title.  It’s on purpose.   = ; 

 

 

 

 

--_000_76CD132C3ADEF848BD84D028D243C927935BD242NKGEML515MBSchi_-- From nobody Mon Mar 13 22:33:03 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2FE1293EC for ; Mon, 13 Mar 2017 22:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z7kXzrMvsY0x for ; Mon, 13 Mar 2017 22:33:01 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 4EA78126BF7 for ; Mon, 13 Mar 2017 22:33:01 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cnf4t-0000gR-EQ; Tue, 14 Mar 2017 05:32:59 +0000 Date: Tue, 14 Mar 2017 14:32:57 +0900 Message-ID: From: Randy Bush To: Robert Raszuk In-Reply-To: References: <148924277112.2960.17904473852401253352@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Interminable Discussion Room Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 05:33:02 -0000 > =E2=80=8BThat not correct if you do it right. If you can reach A via NH1 = and NH2 > and RS propagates both of those NHs to clients - it is up to clients to > validate those NHs and choose one which they prefer for forwarding at a > given point of time. why do folk use RS? to offload the bgp decision process. randy From nobody Tue Mar 14 01:07:39 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A9B61288B8 for ; Tue, 14 Mar 2017 01:07:38 -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, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SMlQ0YX-6LgC for ; Tue, 14 Mar 2017 01:07:36 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (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 09057120725 for ; Tue, 14 Mar 2017 01:07:35 -0700 (PDT) X-Original-To: idr@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 7545861381 for ; Tue, 14 Mar 2017 09:07:33 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 1CD86604D5; Tue, 14 Mar 2017 09:07:33 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id 0E92D71B3C; Tue, 14 Mar 2017 09:07:33 +0100 (CET) Date: Tue, 14 Mar 2017 09:07:32 +0100 From: Gert Doering To: Randy Bush Message-ID: <20170314080732.GE2367@Space.Net> References: <148924277112.2960.17904473852401253352@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Cc: Interminable Discussion Room , Robert Raszuk Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 08:07:38 -0000 Hi, On Tue, Mar 14, 2017 at 02:32:57PM +0900, Randy Bush wrote: > > ???That not correct if you do it right. If you can reach A via NH1 and NH2 > > and RS propagates both of those NHs to clients - it is up to clients to > > validate those NHs and choose one which they prefer for forwarding at a > > given point of time. > > why do folk use RS? to offload the bgp decision process. Mmmmh, I'm not sure I agree to that - we use the RS because it saves us the hassles of maintaining 300+ BGP sessions with lots of small peers, so "human life time" plus "router CPU" is more a factor. Offloading the BGP decision process is a side effect - with sometimes undesired results, in which case we add direct sessions to reclaim control. But usually, for those 300 smaller peers, "it just gets things done". Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Tue Mar 14 01:57:48 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94EBD129469; Tue, 14 Mar 2017 01:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9egJVvRq2tyS; Tue, 14 Mar 2017 01:57:44 -0700 (PDT) Received: from relais-inet.orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AC3E129441; Tue, 14 Mar 2017 01:57:44 -0700 (PDT) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 3F4724036C; Tue, 14 Mar 2017 09:57:43 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.17]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id EEFB31A0087; Tue, 14 Mar 2017 09:57:42 +0100 (CET) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM24.corporate.adroot.infra.ftgroup ([fe80::a1e6:3e6a:1f68:5f7e%18]) with mapi id 14.03.0319.002; Tue, 14 Mar 2017 09:57:42 +0100 From: To: "John G. Scudder" , Stefano Previdi Thread-Topic: [Idr] [spring] IDR WG 2 week WG LC on draft-ietf-idr-bgpls-segment-routing-epe - (2/15/2017 to 3/1/2017) Thread-Index: AQHSnDvzGI7wSSizeEyT+I67EhY6v6GUBGLg Date: Tue, 14 Mar 2017 08:57:41 +0000 Message-ID: <4289_1489481863_58C7B087_4289_4597_1_53C29892C857584299CBF5D05346208A31C63CDC@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <00f901d287e4$16ecb2f0$44c618d0$@ndzh.com> <10484_1487263806_58A5D83E_10484_6197_1_53C29892C857584299CBF5D05346208A1ED67062@OPEXCLILM21.corporate.adroot.infra.ftgroup> <41D02020-B0F5-478C-8FFE-5EEE93D29E06@juniper.net> In-Reply-To: <41D02020-B0F5-478C-8FFE-5EEE93D29E06@juniper.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "idr@ietf.org" , "spring@ietf.org" , "draft-ietf-idr-bgpls-segment-routing-epe@ietf.org" , Susan Hares Subject: Re: [Idr] [spring] IDR WG 2 week WG LC on draft-ietf-idr-bgpls-segment-routing-epe - (2/15/2017 to 3/1/2017) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 08:57:46 -0000 PiBGcm9tOiBKb2huIEcuIFNjdWRkZXIgW21haWx0bzpqZ3NAanVuaXBlci5uZXRdICA+IFNlbnQ6 IE1vbmRheSwgTWFyY2ggMTMsIDIwMTcgOTo1NCBQTQ0KPiANCiA+IFRoYW5rcywgU3RlZmFuby4N CiA+IA0KID4gQnJ1bm8sIGF0IHlvdXIgY29udmVuaWVuY2UgY2FuIHlvdSBjb25maXJtIHRoYXQg eW91J3JlIHNhdGlzZmllZCB3aXRoIHRoZSByZXNvbHV0aW9uPw0KDQotMTEgYWRkcmVzc2VzIG15 IGNvbW1lbnRzLg0KDQpUaGFuayB5b3UgSm9obiwgU3RlZmFuby4NCg0KPiBMb29rcw0KID4gT0sg dG8gbWUgZXZlbiB0aG91Z2ggdGhlIGNoYW5nZXMgZG9uJ3QgcHJlY2lzZWx5IGFkaGVyZSB0byB5 b3VyIHN1Z2dlc3Rpb25zICgiTGluayBOTFJJDQogPiB1c2VzIHRoZSBQcm90b2NvbC1JRCB2YWx1 ZSIgaW5zdGVhZCBvZiAiTGluayBOTFJJIHVzZXMgdGhlIEJHUCBQcm90b2NvbC1JRCB2YWx1ZSIp LiANCg0KSW5kZWVkLg0KSSBzdGlsbCB0aGluayB0aGF0IG5vdCBpbmRpY2F0aW5nIHRoZSBQcm90 b2NvbC1JRCB0byB1c2UgKGVpdGhlciBieSBpdHMgbmFtZSAiQkdQIiBvciBpdHMgdmFsdWUgIjci KSAgaXMgc3ViLW9wdGltYWwgKG9yIG5vdCB1c2VmdWwpLCBob3dldmVyLCB0aGlzIHRleHQgaW4g c2VjdGlvbiA2LjEgaXMgaWxsdXN0cmF0aXZlIG9ubHkuIFRoZSBub3JtYXRpdmUgdGV4dCBpbiDC pzQgZG9lcyBzdGF0ZSBib3RoIHRoZSBuYW1lIGFuZCB0aGUgY29kZSBwb2ludC4gU28gdGhpcyBp cyBnb29kIGVub3VnaCBmb3IgbWUuDQoNCk9uIGEgc2lkZSBub3RlICIodG8gYmUgYXNzaWduZWQg YnkgSUFOQSkiIHNlZW1zIHdyb25nIGFzIHRoZSB2YWx1ZSBoYXMgYmVlbiBhc3NpZ25lZCBodHRw Oi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL2JncC1scy1wYXJhbWV0ZXJzL2JncC1scy1wYXJh bWV0ZXJzLnhodG1sICAoQW5kIGZpeGluZyB0aGlzIHdvdWxkIGFsc28gYWRkcmVzcyB0aGUgcG9p bnQgYWJvdmUuKQ0KDQotLUJydW5vDQoNCj4gVGhlDQogPiByZmNkaWZmIGlzIGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtaWRyLWJncGxzLXNlZ21lbnQtcm91 dGluZy1lcGUtMTEudHh0DQogPiANCiA+IC0tSm9obg0KID4gDQogPiA+IE9uIE1hciAxMywgMjAx NywgYXQgNjozMSBBTSwgU3RlZmFubyBQcmV2aWRpIChzcHJldmlkaSkgPHNwcmV2aWRpQGNpc2Nv LmNvbT4gd3JvdGU6DQogPiA+DQogPiA+IEpvaG4sIEJydW5vLA0KID4gPg0KID4gPiBzb3JyeSBm b3IgaGF2aW5nIG1pc3NlZCB0aGF0LiBJ4oCZbGwgcmVzdWJtaXQgcmlnaHQgbm93LiBJIGludGVn cmF0ZWQgYWxsIGNvbW1lbnRzLiBSZWdhcmRpbmcNCiA+IHRoZSBtaXNzaW5nICJzZWN0aW9uIDMu MSIgKHJlZmVycmluZyB0byB0aGUgaXNpcyBkcmFmdCksIEkgcmVwbGFjZWQgdGV4dCB3aXRoIHRo ZSByZWZlcmVuY2UgdG8NCiA+IGRyYWZ0LWlldGYtaWRyLWJncC1scy1zZWdtZW50LXJvdXRpbmct ZXh0IHdoaWNoIGRlZmluZXMgdGhlIGJncC1scyB0bHYgZm9yIGFkdmVydGlzaW5nIHRoZQ0KID4g U1JHQi4gSSBnYXZlIHRoaXMgYXMgYW4gZXhhbXBsZS4gSSBhbHNvIG1vdmVkIGRyYWZ0LWlldGYt c3ByaW5nLXNlZ21lbnQtcm91dGluZyBpbnRvIHRoZQ0KID4gbm9ybWF0aXZlIHJlZmVyZW5jZXMg c2VjdGlvbi4NCiA+ID4NCiA+ID4gVGhhbmtzLg0KID4gPg0KID4gPiBzLg0KID4gPg0KID4gPg0K ID4gPj4gT24gTWFyIDEwLCAyMDE3LCBhdCA4OjUyIFBNLCBKb2huIEcuU2N1ZGRlciA8amdzQGp1 bmlwZXIubmV0PiB3cm90ZToNCiA+ID4+DQogPiA+PiBIaSBBdXRob3JzLA0KID4gPj4NCiA+ID4+ IEkgc2VlIHRoYXQgeWVzdGVyZGF5J3MgLTEwIHJldmlzaW9uIGRvZXNuJ3QgYWRkcmVzcyBCcnVu bydzIGNvbW1lbnRzLCBiZWxvdy4gQ2FuIHlvdQ0KID4gcGxlYXNlIGVpdGhlciB1cGRhdGUgdGhl IGRvY3VtZW50IGlmIHlvdSBhY2NlcHQgQnJ1bm8ncyBzdWdnZXN0aW9ucywgb3Igb3RoZXJ3aXNl IGRpc2N1c3MNCiA+IHRoZW0gb24gdGhlIGxpc3Q/IFdlIGNhbid0IGRlY2xhcmUgdGhlIFdHTEMg dG8gYmUgc2F0aXNmYWN0b3JpbHkgZmluaXNoZWQgdW50aWwgdGhpcyBpcw0KID4gcmVzb2x2ZWQu DQogPiA+Pg0KID4gPj4gVGhhbmtzLA0KID4gPj4NCiA+ID4+IC0tSm9obg0KID4gPj4NCiA+ID4+ PiBPbiBGZWIgMTYsIDIwMTcsIGF0IDExOjUwIEFNLCBicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29t IHdyb3RlOg0KID4gPj4+DQogPiA+Pj4gSGksDQogPiA+Pj4NCiA+ID4+PiBJ4oCZdmUgcmVhZCB0 aGUgZHJhZnQsIHBsZWFzZSBmaW5kIGJlbG93IHNvbWUgbWlub3IgY29tbWVudHM6DQogPiA+Pj4N CiA+ID4+PiAtLS0NCiA+ID4+PiDCpzQuMw0KID4gPj4+ICIgICAgICAqICBBIDQgb2N0ZXQgaW5k ZXggZGVmaW5pbmcgdGhlIG9mZnNldCBpbiB0aGUgU0lEL0xhYmVsIHNwYWNlIGFkdmVydGlzZWQg YnkgdGhpcw0KID4gcm91dGVyIHVzaW5nIHRoZSBlbmNvZGluZ3MgZGVmaW5lZCBpbiAgU2VjdGlv biAzLjEuIg0KID4gPj4+DQogPiA+Pj4gLSBGb2xsb3dpbmcgdGhlIHJlY2VudCBhZGRpdGlvbiBv ZiB0aGUgU1JMQiBMYWJlbCBTcGFjZSwgSSdkIHJhdGhlciBoYXZlIHRoZSB0ZXh0DQogPiBleHBs aWNpdGx5IHJlZmVycyB0byBuYW1lIG9mIHRoYXQgTGFiZWwgc3BhY2UuIGUuZy4NCiA+ID4+PiBP TEQ6IFNJRC9MYWJlbCBzcGFjZQ0KID4gPj4+IE5FVzogU1JHQg0KID4gPj4+DQogPiA+Pj4gLSBX aGljaCAoU1JHQikgYWR2ZXJ0aXNlbWVudD8gSSdtIGFzc3VtaW5nIHRoZSBJR1Agb25lLCBidXQg SSBndWVzcyBzb21lb25lIG1heQ0KID4gaW1hZ2luZSB1c2luZyB0aGUgQkdQICJPcmlnaW5hdG9y IFNSR0IgVExWIi4gVGhlbiB3aGF0IGlmIHRoZSBub2RlIHJ1bnMgbXVsdGlwbGUgSUdQIHdpdGgN CiA+IGRpZmZlcmVudCBTUkdCIGNvbmZpZ3VyZWQ/DQogPiA+Pj4NCiA+ID4+PiAtIE5vdGUgdGhh dCB0aGlzIGRvY3VtZW50IGhhcyBubyAiU2VjdGlvbiAzLjEiLiBUaGUgdGV4dCBzZWVtcyBib3Jy b3dlZCBmcm9tIHRoZSBJUy1JUw0KID4gU1IgZHJhZnQsIGhlbmNlIG1heSBiZSBhZGRpbmcgdGhl IG5hbWUgb2YgdGhpcyBkcmFmdCB3b3VsZCBqdXN0IHNvbHZlIHRoZSBwb2ludC4gKHdpdGggYQ0K ID4gbm9ybWF0aXZlIHJlZmVyZW5jZSB0byB0aGlzIElTLUlTIGRyYWZ0KQ0KID4gPj4+DQogPiA+ Pj4gLS0tDQogPiA+Pj4gT0xEOiBUaGUgTGluayBOTFJJIHVzZXMgdGhlIG5ldyBQcm90b2NvbC1J RCB2YWx1ZSAodG8gYmUgYXNzaWduZWQgYnkgSUFOQSkNCiA+ID4+PiBwcm9wb3NlZCBORVc6IFRo ZSBMaW5rIE5MUkkgdXNlcyB0aGUgQkdQIFByb3RvY29sLUlEIChUQkQxKQ0KID4gPj4+DQogPiA+ Pj4gKOKAnG5ld+KAnSBtYXkgYmVjb21lIHVuc3BlY2lmaWMgMiB5ZWFycyBmcm9tIG5vdykNCiA+ ID4+Pg0KID4gPj4+IC0tLQ0KID4gPj4+IE9uZSBjb3VsZCBwcm9iYWJseSBhcmd1ZSB0aGF0IFtJ LUQuaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nXSBzaG91bGQgYmUgYSBub3JtYXRpdmUNCiA+ IHJlZmVyZW5jZS4NCiA+ID4+Pg0KID4gPj4+IFRoYW5rcywNCiA+ID4+PiBSZWdhcmRzLA0KID4g Pj4+IC0tQnJ1bm8NCiA+ID4+Pg0KID4gPj4+DQogPiA+Pj4gRnJvbTogc3ByaW5nIFttYWlsdG86 c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTdXNhbiBIYXJlcw0KID4gPj4+ IFNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAxNiwgMjAxNyAxMjozNSBBTQ0KID4gPj4+IFRvOiBp ZHJAaWV0Zi5vcmcNCiA+ID4+PiBDYzogJ0FsdmFybyBSZXRhbmEgKGFyZXRhbmEpJzsgc3ByaW5n QGlldGYub3JnDQogPiA+Pj4gU3ViamVjdDogW3NwcmluZ10gSURSIFdHIDIgd2VlayBXRyBMQyBv biBkcmFmdC1pZXRmLWlkci1iZ3Bscy1zZWdtZW50LXJvdXRpbmctZXBlIC0NCiA+ICgyLzE1LzIw MTcgdG8gMy8xLzIwMTcpDQogPiA+Pj4NCiA+ID4+PiBUaGlzIGJlZ2lucyBhIDIgd2VlayBJRFIg V0cgbGFzdCBjYWxsIG9uIGRyYWZ0LWlldGYtaWRyLWJncGxzLXNlZ21lbnQtcm91dGluZy1lcGUg ZnJvbQ0KID4gKDIvMTUgdG8gMy8xLzIwMTcpICAgIFRoZXJlIGFyZSB0d28gaW1wbGVtZW50YXRp b25zIGRlc2NyaWJlIG9uIHRoZSB3aWtpIGF0Og0KID4gPj4+IGh0dHBzOi8vdHJhYy5pZXRmLm9y Zy90cmFjL2lkci93aWtpL2RyYWZ0LWlldGYtaWRyLWJncGxzLXNlZ21lbnQtcm91dGluZy1lcGUl MjANCiA+ID4+Pg0KID4gPj4+IFRoZSB0d28gaW1wbGVtZW50YXRpb24gYXJlIGZyb20gIENpc2Nv IElPUy1YUiByZWxlYXNlIDYuMC4yIGFuZCBDaXNjbyBOZXh1cyBTd2l0Y2gNCiA+IE45MDAwL04z MDAwIHBsYXRmb3JtcyBydW5uaW5nIE5YLU9TIDcuMCgzKUkxKDEpIG9yIGdyZWF0ZXIuICAgVGhl IGF1dGhvcnMgd2lsbCBpbmRpY2F0ZSBvbg0KID4gdGhlIGxpc3QgYW5kIGluIHRoZSB3aWtpIHRo ZSBmb2xsb3dpbmcgaW5mb3JtYXRpb24gOg0KID4gPj4+DQogPiA+Pj4gMSkgICAgICBXZXJlIHRo ZXNlIGltcGxlbWVudGF0aW9ucyBzZXBhcmF0ZSBpbXBsZW1lbnRhdGlvbnM/DQogPiA+Pj4gMikg ICAgICBXaGF0IHdlcmUgdGhlIHJlc3VsdHMgb2YgdGhlIGludGVyb3BlcmFiaWxpdHkgdGVzdHM/ DQogPiA+Pj4NCiA+ID4+PiBUaGlzIHdvcmsgaXMgbGlua2VkIHRvIHRoZSBkcmFmdC1pZXRmLXNw cmluZy1zZWdtZW50LXJvdXRpbmctY2VudHJhbC1lcGUgd29yayBpbiB0aGUNCiA+IFNQUklORyBX Ry4gQmFzZWQgb24gdGhlIHR3byBkcmFmdHMsIHRoZSBXRyBzaG91bGQgbWlnaHQgY29uc2lkZXI6 DQogPiA+Pj4gMSkgICAgICBJcyB0aGVyZSBuZWVkIGZvciB0aGlzIHdvcmsgaW4gZGVwbG95bWVu dHMgaW4gbmV0d29ya3MvDQogPiA+Pj4gMikgICAgICBJcyB0aGlzIHRlY2huaWNhbGx5IHJlYWR5 IGZvciBwdWJsaWNhdGlvbj8NCiA+ID4+PiAzKSAgICAgIERvZXMgaXQgZml0IHdpdGggdGhlIHNw cmluZyBpbmZvcm1hdGlvbmFsIGRyYWZ0Pw0KID4gPj4+DQogPiA+Pj4gRm9yIHRoZSBlYXNlIG9m IHJlZmVyZW5jZSB0aGUgd2ViIHJlZmVyZW5jZXMgYXJlIGJlbG93Og0KID4gPj4+IGh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaWRyLWJncGxzLXNlZ21lbnQtcm91 dGluZy1lcGUvDQogPiA+Pj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt aWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLWNlbnRyYWwtZXBlLw0KID4gPj4+DQogPiA+Pj4g U3VlIEhhcmVzDQogPiA+Pj4NCiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiA+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KID4gPj4+DQogPiA+Pj4gQ2UgbWVz c2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRp b25zIGNvbmZpZGVudGllbGxlcyBvdQ0KID4gcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9u Yw0KID4gPj4+IHBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0 b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlDQogPiBwYXIgZXJyZXVyLCB2 ZXVpbGxleiBsZSBzaWduYWxlcg0KID4gPj4+IGEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJl IGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVz DQogPiBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLA0KID4gPj4+IE9yYW5nZSBkZWNs aW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZv cm1lIG91IGZhbHNpZmllLg0KID4gTWVyY2kuDQogPiA+Pj4NCiA+ID4+PiBUaGlzIG1lc3NhZ2Ug YW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdl ZCBpbmZvcm1hdGlvbg0KID4gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsNCiA+ID4+PiB0 aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0 aG9yaXNhdGlvbi4NCiA+ID4+PiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVy cm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzDQogPiBtZXNzYWdl IGFuZCBpdHMgYXR0YWNobWVudHMuDQogPiA+Pj4gQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBP cmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQs DQogPiBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NCiA+ID4+PiBUaGFuayB5b3UuDQogPiA+Pj4NCiA+ ID4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KID4g Pj4+IElkciBtYWlsaW5nIGxpc3QNCiA+ID4+PiBJZHJAaWV0Zi5vcmcNCiA+ID4+PiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkcg0KID4gPj4NCiA+ID4NCg0KCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVz IGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZl bnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9y aXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxl eiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVz IHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0 aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBz aSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpU aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwg b3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0 aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0 aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxl YXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0 YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUg Zm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmll ZC4KVGhhbmsgeW91LgoK From nobody Tue Mar 14 02:46:06 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B225A1294DB for ; Tue, 14 Mar 2017 02:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id thtKJZVSFyJc for ; Tue, 14 Mar 2017 02:46:01 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84BBC129524 for ; Tue, 14 Mar 2017 02:46:01 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id p64so243292683qke.1 for ; Tue, 14 Mar 2017 02:46:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=XjByXwmgOz/Au8cR1AZYwM2j3dn4rlD3joDfY2qWNgI=; b=qop7XR9N9eUSMwVb5j7e7TCur7CN7NcRLfkbGOdi9sSgL6IgpwEMKXBNNk0FY3GY/0 +1f5uUWAiW+XB0YTezCe28ONUDZ7gW2VKmcWjMYJwOwePHHLTPhwMfA+Hw90/gzzPzvI DYO5lZL+ZIYdAyEp6nSY47MVSuEXGyUaNZwWnRFsqzUI3HHjvQTYkWyE4h5VBKyJEG2d pqcYkCTOtXcqYQ9vvigWYWZZx5i/W/vLBYjmdxYAMNKlmHHpErCpAnBfMhYsii06L2Aa FtN9SfSNoLUGBbnspmR3zCV2vYkI+oRHniF9H/nX/loNfWJYwBECt3sd4p2IH6ktIovQ jd9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=XjByXwmgOz/Au8cR1AZYwM2j3dn4rlD3joDfY2qWNgI=; b=gW3JF2g/lN0n7WMXLTb+ETVorZvJQxvunYpyX0S4LW6JCYpdw4izmAwZDhHjRR9vuG E66RYKdrSfd5PAqPJNDdzmvWrkwjp1x2cJzViUof4opAEDZWTBYQA5RFeDFIV9sHgA5k Gdu8A1CxwTQOPU07O5PFWbjOqzuQ+Ry37CZNcoPGxr6IrYoiZ8Or3euENX4YuUlvlXt8 fZcaKaig0qMqFHMxTcUc+aPjcb9TtVN0Fk5u7KsYYs1Hh7e3hg8EtJbELGUsFT9TxdFU yaAOnPQ1vaHtEC1iFPuK4jcpa4f5QQaoFHUWQZPxTPVFtLV10Z5pfR9ko1u7wC2XWIGM nWqA== X-Gm-Message-State: AMke39mggeTqK8mh/fohyjjUEuCO3CDyKC6nN3lvZavdeB6NErzxf9M93zBfZvnmT5NYJAf/hMHjSvw+rvNFPQ== X-Received: by 10.55.128.66 with SMTP id b63mr38857994qkd.297.1489484760564; Tue, 14 Mar 2017 02:46:00 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.140.42.181 with HTTP; Tue, 14 Mar 2017 02:45:59 -0700 (PDT) In-Reply-To: References: <148924277112.2960.17904473852401253352@ietfa.amsl.com> From: Robert Raszuk Date: Tue, 14 Mar 2017 10:45:59 +0100 X-Google-Sender-Auth: yOn4dB3bvqW1_8F2ME-Et-kIqe8 Message-ID: To: Randy Bush Content-Type: multipart/alternative; boundary=94eb2c06654c0d4d77054aadb21c Archived-At: Cc: Interminable Discussion Room Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 09:46:02 -0000 --94eb2c06654c0d4d77054aadb21c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > why do folk use RS? to offload the bgp decision process. > > randy > =E2=80=8BWrong completely ! RS are used to establish one (or two) eBGP session and get all the juice. = =E2=80=8B The more juice you get the better and in fact you need more then you can swallow at a time to choose which one tastes better at a given point of time. --94eb2c06654c0d4d77054aadb21c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=C2=A0
why do folk use RS?=C2=A0 to of= fload the bgp decision process.

randy

=E2=80=8BWrong completely !

RS are used to establish one (or two) eBGP session and = get all the juice. =E2=80=8B

The more juice you get the better and in fact you need more then y= ou can swallow at a time to choose which one tastes better at a given point= of time.=C2=A0

--94eb2c06654c0d4d77054aadb21c-- From nobody Tue Mar 14 03:00:50 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF2D61293F9 for ; Tue, 14 Mar 2017 03:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vMEwvZWBpHyi for ; Tue, 14 Mar 2017 03:00:48 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 7A71D12943B for ; Tue, 14 Mar 2017 02:52:35 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cnj86-0001ss-1L; Tue, 14 Mar 2017 09:52:34 +0000 Date: Tue, 14 Mar 2017 18:52:31 +0900 Message-ID: From: Randy Bush To: Robert Raszuk In-Reply-To: References: <148924277112.2960.17904473852401253352@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Interminable Discussion Room Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 10:00:49 -0000 >> why do folk use RS? to offload the bgp decision process. > RS are used to establish one (or two) eBGP session and get all the > juice. =E2=80=8B that is one. my case is one. and there are others. folk are at large exchanges with small routers; some can handle about one view. they do not have the horsepower to make best next hop choices from large sets. we should not disenfranchise them. randy From nobody Tue Mar 14 03:05:11 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9609C129524 for ; Tue, 14 Mar 2017 03:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cqn8VyE0Z0-M for ; Tue, 14 Mar 2017 03:05:07 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::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 8DFB912943B for ; Tue, 14 Mar 2017 03:05:07 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id r45so51598288qte.3 for ; Tue, 14 Mar 2017 03:05:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=crsMgEJu4MioFHJRcVnUWnNcwMESSkyvz5q4gzdp2Uo=; b=NNgAnQYJ3ROQOZR4UigmWQjkCOArTMyZ5J7gtSNKB/YIUk2mJWGlj7C2itOj5pUvxC Rgpk4gRpasRV8cDOHQvHsiU+LIEvMjsDAG+JqQrsSln7P65WnWGk3N2u3NL8/CYtBE6Z l/pZ48ahLkC6Gl8PRDvTA7CU7l+hQUZe54cjs4lJk8jbMp1F+kW6ELuMAvIwnWRqnXm6 c0kqs0VelGP5pxaVQMqAMs3HFvSSN3zZ0wWsqZ8uBZ1o6K5FBpGdRRwWK5IvFrOobkl3 3QqFSeW70fnkIeH+LDcotFqtg2t14VO1Zvzm2p39QweM6+gGLMzLPKQBwAI2il7BV8t7 g5Vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=crsMgEJu4MioFHJRcVnUWnNcwMESSkyvz5q4gzdp2Uo=; b=bwFh0jYM2/fmHqQc3FgFTU/IbZZhXVG0dtKiLXPqpQR4xIMeyNLpYFpPJoi0dM2JLq ltbW/Sh4ZTPN0hPML5PAJvLD+GqjQK5o896QXavZymj6KdQJzICvIdCMPqveofvi+13D +wtx/4F16vW6TWh0qpPR/9zb9uCcyXfTJn8P9s6MeW2Ux03N9kC4zS+OdqSYOS8oM2j5 /pKYFeTlTF5tELtd49uuxTm85noLbMA3vzGYNc3xm8IOewoD5cKkmS84PTc06gck+KuJ n89cKLooYQHC3PiruuvTLcMSm8OTemxkftzGa/jUw0Rcdz/BVFKnPgf9CBR74+cpeXS4 Btaw== X-Gm-Message-State: AMke39mbF3WYqNxn5mWL0+oeYlpYq5juizDN63NR0dXOgmcY7NAaB1jIUOLADUDib9Ess41yhsMF998ZcjicnA== X-Received: by 10.200.2.150 with SMTP id p22mr39327514qtg.197.1489485906538; Tue, 14 Mar 2017 03:05:06 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.140.42.181 with HTTP; Tue, 14 Mar 2017 03:05:05 -0700 (PDT) In-Reply-To: References: <148924277112.2960.17904473852401253352@ietfa.amsl.com> From: Robert Raszuk Date: Tue, 14 Mar 2017 11:05:05 +0100 X-Google-Sender-Auth: ywh9p-l-aE1924tFgXd7bn7NDO0 Message-ID: To: Randy Bush Content-Type: multipart/alternative; boundary=f4030435c2345b828e054aadf660 Archived-At: Cc: Interminable Discussion Room Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 10:05:09 -0000 --f4030435c2345b828e054aadf660 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Randy .. Any ASBR (even software running in a VM or container) today used as peering router can handle Internet table. That is 600K+ nets. IXes give you tiny subset of it via open or selective policy. Moreover as I mentioned in my original comment - over RS you get local customer and internal routes and no more. So for any net it will be usually one or two paths anyway. So if someone has one path (and client has no way of knowing) signalling to RS that next hop is gone is not helpful as there is no backup path RS could recompute and send to such client. Learning two paths for given net with different NHs (even if RS has more then two) seems to provide sufficient robustness and enables you to measure quality to the destinations as well as do things line multipath TCP =3D =3D =3D Little suggestion: Now if someone is really so weak on the edge and attaches to IX to only peer locally we should perhaps invent co-located with RS pair of data plane boxes where such weak guys would for forwarding just default to such data plane gateway. That way those two forwarders could have as many paths as RS feeds it with yet all weak clients are happy to forward and reach all open peers of a given IX. In fact most IX switches while running in L2 mode could be configured for L3 as well so no need to even invest new $$$ needed. Kind regards, Robert. On Tue, Mar 14, 2017 at 10:52 AM, Randy Bush wrote: > >> why do folk use RS? to offload the bgp decision process. > > RS are used to establish one (or two) eBGP session and get all the > > juice. =E2=80=8B > > that is one. my case is one. and there are others. > > folk are at large exchanges with small routers; some can handle about > one view. they do not have the horsepower to make best next hop choices > from large sets. we should not disenfranchise them. > > randy > --f4030435c2345b828e054aadf660 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Randy ..=C2=A0
=
Any ASBR (even software running in a VM or con= tainer) today used as peering router can handle Internet table. That is 600= K+ nets.

IXes give you= tiny subset of it via open or selective policy. Moreover as I mentioned in= my original comment - over RS you get local customer and internal routes a= nd no more. So for any net it will be usually one or two paths anyway.=C2= =A0

So if someone has = one path (and client has no way of knowing) signalling to RS that next hop = is gone is not helpful as there is no backup path RS could recompute and se= nd to such client.=C2=A0

Learning two paths for given net with different NHs (even if RS has more= then two) seems to provide sufficient robustness and enables you to measur= e quality to the destinations as well as do things line multipath TCP
=

=3D =3D =C2=A0=3D=C2=A0

Little suggestion:
<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ;font-size:small">
Now if someone is really so = weak on the edge and attaches to IX to only peer locally we should perhaps = invent co-located with RS pair of data plane boxes where such weak guys wou= ld for forwarding just default to such data plane gateway. That way those t= wo forwarders could have as many paths as RS feeds it with yet all weak cli= ents are happy to forward and reach all open peers of a given IX.=C2=A0

In fact most IX switches = while running in L2 mode could be configured for L3 as well so no need to e= ven invest new $$$ needed.=C2=A0

Kind regards,
Robert.



<= /div>

On Tue, Mar = 14, 2017 at 10:52 AM, Randy Bush <randy@psg.com> wrote:
>> why do folk use RS?=C2= =A0 to offload the bgp decision process.
> RS are used to establish one (or two) eBGP ses= sion and get all the
> juice. =E2=80=8B

that is one.=C2=A0 my case is one.=C2=A0 and there are others.

folk are at large exchanges with small routers; some can handle about
one view.=C2=A0 they do not have the horsepower to make best next hop choic= es
from large sets.=C2=A0 we should not disenfranchise them.

randy

--f4030435c2345b828e054aadf660-- From nobody Tue Mar 14 04:14:21 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4164F12954B for ; Tue, 14 Mar 2017 04:14: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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 669YsHcQCB9I for ; Tue, 14 Mar 2017 04:14:19 -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 157A31279EB for ; Tue, 14 Mar 2017 04:14:18 -0700 (PDT) X-Envelope-To: idr@ietf.org Received: from cupcake.local (87-198-221-22.static.ptr.magnet.ie [87.198.221.22]) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id v2EBEFMg074167 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Mar 2017 11:14:16 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 87-198-221-22.static.ptr.magnet.ie [87.198.221.22] claimed to be cupcake.local Message-ID: <58C7D087.9060107@foobar.org> Date: Tue, 14 Mar 2017 11:14:15 +0000 From: Nick Hilliard User-Agent: Postbox 5.0.11 (Macintosh/20170302) MIME-Version: 1.0 To: Robert Raszuk References: <148924277112.2960.17904473852401253352@ietfa.amsl.com> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Interminable Discussion Room Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 11:14:20 -0000 Robert Raszuk wrote: > Randy Bush wrote: > why do folk use RS? to offload the bgp decision process. > > ​Wrong completely ! A bit less URRONG might be productive on this point. As an operator, I'm aware of both rationales being used in production. Nick From nobody Tue Mar 14 04:27:11 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 817B11294CE for ; Tue, 14 Mar 2017 04:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZbMAocwKTMBC for ; Tue, 14 Mar 2017 04:27:09 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 6718212954D for ; Tue, 14 Mar 2017 04:27:08 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=70.194.5.9; From: "Susan Hares" To: "'Dongjie \(Jimmy\)'" , "'John G. Scudder'" , "'idr wg'" References: <03ae01d29c3e$6c5d87a0$451896e0$@ndzh.com> <76CD132C3ADEF848BD84D028D243C927935BD242@NKGEML515-MBS.china.huawei.com> In-Reply-To: <76CD132C3ADEF848BD84D028D243C927935BD242@NKGEML515-MBS.china.huawei.com> Date: Tue, 14 Mar 2017 07:22:15 -0400 Message-ID: <00d801d29cb5$3c4ba610$b4e2f230$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D9_01D29C93.B53AC960" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIgYy6xumBx4YeN0V40xjwsD29naAJtob5FoOU2/6A= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] Request for 2 drafts X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 11:27:10 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00D9_01D29C93.B53AC960 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Jie: Thank you. Sue From: Dongjie (Jimmy) [mailto:jie.dong@huawei.com] Sent: Monday, March 13, 2017 11:16 PM To: Susan Hares; 'John G. Scudder'; 'idr wg' Subject: RE: Request for 2 drafts Hi Sue, I've added your presentation to the tentative agenda, could you also let me know the desired duration of your presentation? Thanks. Best regards, Jie From: Susan Hares [mailto:shares@ndzh.com] Sent: Tuesday, March 14, 2017 5:12 AM To: Dongjie (Jimmy) ; 'John G. Scudder' ; 'idr wg' Subject: Request for 2 drafts Jie, John and y'all IDR folks: I'd like to follow-up on our "clean up" the attribute area discussion. I've published: draft-hares-deprecate-atomic-aggregate-00 draft-hares-idr-bgp-registries-00.txt I'd like a presentation slot to continue our discussion. It might be good near Jeff's document on the same topic (if he's asking for a slot). Sue PS - I know the first one does not have a BGP or idr title. It's on purpose. ------=_NextPart_000_00D9_01D29C93.B53AC960 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Jie:

 

Thank  = you.

 

Sue =

 

From:= = Dongjie (Jimmy) [mailto:jie.dong@huawei.com]
Sent: Monday, = March 13, 2017 11:16 PM
To: Susan Hares; 'John G. Scudder'; = 'idr wg'
Subject: RE: Request for 2 drafts =

 

Hi = Sue,

=  

IR= 17;ve added your presentation to the tentative agenda, could you also = let me know the desired duration of your presentation? = Thanks.

=  

Best = regards,

Jie

=  

From: Susan Hares [mailto:shares@ndzh.com] =
Sent: Tuesday, March 14, 2017 5:12 AM
To: Dongjie = (Jimmy) <jie.dong@huawei.com>; 'John = G. Scudder' <jgs@juniper.net>; 'idr wg' <idr@ietf.org>
Subject: = Request for 2 drafts

 

Jie, John = and y’all IDR folks:

 

<individual contributor hat = on>

 

I’d = like to follow-up on our “clean up” the attribute area = discussion.

 

I’ve = published:

 

draft-hares-deprecate-atomic-aggrega= te-00 

draft-hares-idr-bgp-registries-00.tx= t

 

I’d = like a presentation slot to continue our discussion.  It might be = good near Jeff’s document on the same topic (if he’s asking = for a slot).

 

 

<individual contributor hat = off>

 

Sue =

 

PS – = I know the first one does not have a BGP or idr title.  It’s = on purpose.    

 

 

 

 

------=_NextPart_000_00D9_01D29C93.B53AC960-- From nobody Tue Mar 14 04:30:44 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E6D7129867 for ; Tue, 14 Mar 2017 04:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id thu7G2lSwN9V for ; Tue, 14 Mar 2017 04:30:42 -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 55ABC1294CE for ; Tue, 14 Mar 2017 04:30:42 -0700 (PDT) X-Envelope-To: idr@ietf.org Received: from cupcake.local (87-198-221-22.static.ptr.magnet.ie [87.198.221.22]) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id v2EBUdNX076082 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Mar 2017 11:30:39 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 87-198-221-22.static.ptr.magnet.ie [87.198.221.22] claimed to be cupcake.local Message-ID: <58C7D45E.80704@foobar.org> Date: Tue, 14 Mar 2017 11:30:38 +0000 From: Nick Hilliard User-Agent: Postbox 5.0.11 (Macintosh/20170302) MIME-Version: 1.0 To: Robert Raszuk References: <148924277112.2960.17904473852401253352@ietfa.amsl.com> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Interminable Discussion Room Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 11:30:44 -0000 Robert, speaking with my ixp operator hat on: Robert Raszuk wrote: > Any ASBR (even software running in a VM or container) today used as > peering router can handle Internet table. That is 600K+ nets. this statement is incorrect on production networks. > IXes give you tiny subset of it via open or selective policy. this statement is incorrect on production ixps. > Moreover > as I mentioned in my original comment - over RS you get local customer > and internal routes and no more. So for any net it will be usually one > or two paths anyway. this statement is incorrect on production ixps. > So if someone has one path (and client has no way of knowing) signalling > to RS that next hop is gone is not helpful as there is no backup path RS > could recompute and send to such client. > > Learning two paths for given net with different NHs (even if RS has more > then two) seems to provide sufficient robustness and enables you to > measure quality to the destinations as well as do things line multipath TCP this statement is both incorrect and wildly unrealistic on real world networks, even from the most rarified theoretical point of view. > Now if someone is really so weak on the edge and attaches to IX to only > peer locally we should perhaps invent co-located with RS pair of data > plane boxes where such weak guys would for forwarding just default to > such data plane gateway. That way those two forwarders could have as > many paths as RS feeds it with yet all weak clients are happy to forward > and reach all open peers of a given IX. > > In fact most IX switches while running in L2 mode could be configured > for L3 as well so no need to even invest new $$$ needed. this statement is incorrect at production ixps. I would be happy to provide multiple counterexamples to all these points. This draft is attempting to solve a real world problem on real world networks. It would be nice for ixp participants to have ideally specified equipment providing service for clients which all had working, network-aware multipath implementations which could react immediately to blackholing events, but this doesn't even begin to approximate reality. Production IXPs need to be able to provide baseline services to a hodge-podge of different types of equipment serving the great unwashed of the internet. There are very few assumptions you can make about equipment specification that will turn out to be realistic. Nick From nobody Tue Mar 14 04:32:10 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96C291294CE for ; Tue, 14 Mar 2017 04:32:06 -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, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7irfW1m6P1T for ; Tue, 14 Mar 2017 04:32:05 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (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 91B381293DC for ; Tue, 14 Mar 2017 04:32:05 -0700 (PDT) X-Original-To: idr@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 2D42961575 for ; Tue, 14 Mar 2017 12:32:04 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id E5A6A602B6; Tue, 14 Mar 2017 12:32:03 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id D7BC77064D; Tue, 14 Mar 2017 12:32:03 +0100 (CET) Date: Tue, 14 Mar 2017 12:32:03 +0100 From: Gert Doering To: Robert Raszuk Message-ID: <20170314113203.GI2367@Space.Net> References: <148924277112.2960.17904473852401253352@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Cc: Interminable Discussion Room Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 11:32:06 -0000 Hi On Tue, Mar 14, 2017 at 11:05:05AM +0100, Robert Raszuk wrote: > Any ASBR (even software running in a VM or container) today used as peering > router can handle Internet table. That is 600K+ nets. *cough* Please enlighten yourself what people use "as peering router" today :-) > IXes give you tiny subset of it via open or selective policy. ... and about the amount of prefixes you can receive on a reasonably-sized IXP. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Tue Mar 14 04:45:40 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD0B6129567 for ; Tue, 14 Mar 2017 04:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Je2uSJeknphL for ; Tue, 14 Mar 2017 04:45:37 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58690126D73 for ; Tue, 14 Mar 2017 04:45:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3392; q=dns/txt; s=iport; t=1489491937; x=1490701537; h=from:to:cc:subject:date:message-id:mime-version; bh=qKpmaoeamhU+j5MKn3Ev+Uf4/bR9z5O8RQ4eakn+Tv4=; b=EDJ+D10bv/M/YO6iRhwHm0HDKp291uUxLg1TEGpEQm9rpEFfH8L/+NLC aPziNK850FyhiUCaJs/g8IpCu38CIXVcsv2/PVohVYB+9uMkBbr1pwnlB 3nUr/v+6jZzAQkyRF9mZQChI6mNkvjr3GnoFNvQMKjjx5lAESQXH9OI0S I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C3AQBQ18dY/4kNJK1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgm5jYYERjWahYoMegg+CDiqFeIJJPxgBAgEBAQEBAQFrKIYVEgEMdCc?= =?us-ascii?q?EAQ2KBQ6vS4phAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWGTo8oBZAcjCcBhnWLR?= =?us-ascii?q?ZElk0YBHziBBFgVhR0YgWOJGoENAQEB?= X-IronPort-AV: E=Sophos;i="5.36,163,1486425600"; d="scan'208,217";a="395984142" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Mar 2017 11:45:36 +0000 Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v2EBjZwd013176 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 14 Mar 2017 11:45:36 GMT Received: from xch-rtp-012.cisco.com (64.101.220.152) by XCH-RTP-009.cisco.com (64.101.220.149) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 14 Mar 2017 07:45:34 -0400 Received: from xch-rtp-012.cisco.com ([64.101.220.152]) by XCH-RTP-012.cisco.com ([64.101.220.152]) with mapi id 15.00.1210.000; Tue, 14 Mar 2017 07:45:35 -0400 From: "Gaurav Dawra (gdawra)" To: "jie.dong@huawei.com" , "jgs@juniper.net" , "shares@ndzh.com" , "idr@ietf.org" Thread-Topic: [idr] Slots requests for IDR WG session - IETF 98 - Chicago Thread-Index: AQHSnLh+RMrACW9R2EiadBqXYlIfSw== Date: Tue, 14 Mar 2017 11:45:35 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.0.161029 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.124.221] Content-Type: multipart/alternative; boundary="_000_D4ED25EC1D6AF5gdawraciscocom_" MIME-Version: 1.0 Archived-At: Cc: "Patrice Brissette \(pbrisset\)" , "Clarence Filsfils \(cfilsfil\)" Subject: [Idr] [idr] Slots requests for IDR WG session - IETF 98 - Chicago X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 11:45:38 -0000 --_000_D4ED25EC1D6AF5gdawraciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Sue, Jie, John and y'all IDR folks: I've published: draft-dawra-idr-srv6-vpn (https://datatracker.ietf.org/doc/draft-dawra-idr-= srv6-vpn/) 20mins Gaurav Dawra, Patrice Brissette I'd like a presentation slot to continue this discussion. Cheers, Gaurav --_000_D4ED25EC1D6AF5gdawraciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <25EACE67B78DBD44B246AAABEFAB9F64@emea.cisco.com> Content-Transfer-Encoding: quoted-printable

Dear Sue, Jie, John and y’all IDR f= olks: 

   

I’ve published: 


draft-dawra-idr-srv6-vpn (https://datatracker.ietf.org/doc/draft-dawra-idr-srv= 6-vpn/)


20mins=

Gaurav Dawra, <= /span>Patrice Brissette 

 

I’d like a presentation slot to con= tinue this discussion. 

 

Cheers,


Gaurav 


--_000_D4ED25EC1D6AF5gdawraciscocom_-- From nobody Tue Mar 14 05:27:46 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A2B112957D for ; Tue, 14 Mar 2017 05:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6ARIRN-g-nK for ; Tue, 14 Mar 2017 05:27:44 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::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 2669712955C for ; Tue, 14 Mar 2017 05:27:44 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id n21so54029761qta.1 for ; Tue, 14 Mar 2017 05:27:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=XhuZBAA9kBMxL2IrXiWYC817CWbDLpRzcWv88ucDw60=; b=PrLqfVWTBZwZYYz3FVSCWbv1zojSh6OY9SEYgJecBTjQuummYEZaG1QeXCU96C5jLU DEA+iMAfbEYokAXS2rth2mns3RG/MjkgbX4S0iAE6KAiIVHi760WCZVeW01kb/MUKjkh ml81Ule39MYz9DZ0wXYYPzFk2TgDaHZpL9ieGhnesJTIB4tGi7jLpTg96lxZKTUXbrL4 gpRNPOwmAJUVS4ITM8s9lP7L1IPUjPDwbGRSEEo1a5CFipjrNDKmlGqTnKsFdUiktSaW YVWkAFnEDnuKmJN0lpnsZZ26RkeEtnalYCxPWFNjMkR6PJBSU7uSi4QZDd7dLsU1SYTN DTkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=XhuZBAA9kBMxL2IrXiWYC817CWbDLpRzcWv88ucDw60=; b=GA6Cu136s2ismrxu6/y9RwQa63ZVcZsRBb+qtPaYC2wO82Ok12Kp54PqRgRtfRxmFn j82mFl4Fj92g5XVdZWXIKEyzrOvB9LVn1l2ALdJZ++q6iI9syO+FMP3gs486eu9dgflT BqE52qKvGfS0HO4VXLP+Etmp0KqNwrcTQTM25PEmZ6oVn1rDVIZHjIB320d0Wv+k89Hq 9U1ADDN3HtdBaepTu6j92q2me9QKBz3q3BcgSdr6lchWRdLg1jAmG1peP6lju66HhvRC ILRsvjiHrb0vCNfzdrGFi9aKr0B+vSicGCA7ZLiuGSHck3szYcPTLoPx6zaZbFC80kA9 luWA== X-Gm-Message-State: AMke39kVTqrwjF9UVU62aMDhShg9dclMxgemVfcyepbUtbsNYsQ28wiMFUMGEaTPA5CL4pqx6XLY61aFwpCa3g== X-Received: by 10.200.62.145 with SMTP id y17mr39861503qtf.53.1489494463092; Tue, 14 Mar 2017 05:27:43 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.140.42.181 with HTTP; Tue, 14 Mar 2017 05:27:42 -0700 (PDT) In-Reply-To: <58C7D45E.80704@foobar.org> References: <148924277112.2960.17904473852401253352@ietfa.amsl.com> <58C7D45E.80704@foobar.org> From: Robert Raszuk Date: Tue, 14 Mar 2017 13:27:42 +0100 X-Google-Sender-Auth: 1mfcVxHvEXqg7s_uzjDgVYOSVRo Message-ID: To: Nick Hilliard Content-Type: multipart/alternative; boundary=f403045e6b285e2127054aaff4ee Archived-At: Cc: Interminable Discussion Room Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 12:27:45 -0000 --f403045e6b285e2127054aaff4ee Content-Type: text/plain; charset=UTF-8 Nick, If someone is using weak BGP stacks which can not handle two BGP paths per net .. sorry that to me does not justify inventing new SAFI. Moreover the idea behind the new SAFI is flawed since it assumes RS always would have a secondary path to send to client. Otherwise noise of 1000 peers bombarding RS with message "NH-X is not reachable" is pretty useless if given net has only one NH on the RS. Moreover those weak clients which can not run best path for RS received nets are now subject to handle 1000 BFD sessions ... it really does not sound right that an edge can do the latter just fine and not the former. Last to address real world problem - I proposed very easy solution which you as an IXP operator can enable today via simple config on your switch and treat such switch (or pair of switches) as default forwarder. Done ! Fully backward compatible with existing IXP deployment too. Thanks, R. On Tue, Mar 14, 2017 at 12:30 PM, Nick Hilliard wrote: > Robert, > > speaking with my ixp operator hat on: > > Robert Raszuk wrote: > > Any ASBR (even software running in a VM or container) today used as > > peering router can handle Internet table. That is 600K+ nets. > > this statement is incorrect on production networks. > > > IXes give you tiny subset of it via open or selective policy. > > this statement is incorrect on production ixps. > > > Moreover > > as I mentioned in my original comment - over RS you get local customer > > and internal routes and no more. So for any net it will be usually one > > or two paths anyway. > > this statement is incorrect on production ixps. > > > So if someone has one path (and client has no way of knowing) signalling > > to RS that next hop is gone is not helpful as there is no backup path RS > > could recompute and send to such client. > > > > Learning two paths for given net with different NHs (even if RS has more > > then two) seems to provide sufficient robustness and enables you to > > measure quality to the destinations as well as do things line multipath > TCP > > this statement is both incorrect and wildly unrealistic on real world > networks, even from the most rarified theoretical point of view. > > > Now if someone is really so weak on the edge and attaches to IX to only > > peer locally we should perhaps invent co-located with RS pair of data > > plane boxes where such weak guys would for forwarding just default to > > such data plane gateway. That way those two forwarders could have as > > many paths as RS feeds it with yet all weak clients are happy to forward > > and reach all open peers of a given IX. > > > > In fact most IX switches while running in L2 mode could be configured > > for L3 as well so no need to even invest new $$$ needed. > > this statement is incorrect at production ixps. > > I would be happy to provide multiple counterexamples to all these points. > > This draft is attempting to solve a real world problem on real world > networks. It would be nice for ixp participants to have ideally > specified equipment providing service for clients which all had working, > network-aware multipath implementations which could react immediately to > blackholing events, but this doesn't even begin to approximate reality. > Production IXPs need to be able to provide baseline services to a > hodge-podge of different types of equipment serving the great unwashed > of the internet. There are very few assumptions you can make about > equipment specification that will turn out to be realistic. > > Nick > --f403045e6b285e2127054aaff4ee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Nick,

If someone is using weak BGP stacks which can not handl= e two BGP paths per net .. sorry that to me does not justify inventing new = SAFI.=C2=A0

Moreover t= he idea behind the new SAFI is flawed since it assumes RS always would have= a secondary path to send to client. Otherwise noise of 1000 peers bombardi= ng RS with message "NH-X is not reachable" is pretty useless if g= iven net has only one NH on the RS.=C2=A0

Moreover those weak clients which can not run best path= for RS received nets are now subject to handle 1000 BFD sessions ... it re= ally does not sound right that an edge can do the latter just fine and not = the former.=C2=A0

Last= to address real world problem - I proposed very easy solution which you as= an IXP operator can enable today via simple config on your switch and trea= t such switch (or pair of switches) as default forwarder. Done ! Fully back= ward compatible with existing IXP deployment too.=C2=A0

Thanks,
R.
<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ;font-size:small">








On Tue, Mar 14, 2017 at 12:30 PM, Nick Hilliard <ni= ck@foobar.org> wrote:
Rober= t,

speaking with my ixp operator hat on:

Robert Raszuk wrote:
> Any ASBR (even software running in a VM or container) today used as > peering router can handle Internet table. That is 600K+ nets.

this statement is incorrect on production networks.

> IXes give you tiny subset of it via open or selective policy.

this statement is incorrect on production ixps.

> Moreover
> as I mentioned in my original comment - over RS you get local customer=
> and internal routes and no more. So for any net it will be usually one=
> or two paths anyway.

this statement is incorrect on production ixps.

> So if someone has one path (and client has no way of knowing) signalli= ng
> to RS that next hop is gone is not helpful as there is no backup path = RS
> could recompute and send to such client.
>
> Learning two paths for given net with different NHs (even if RS has mo= re
> then two) seems to provide sufficient robustness and enables you to > measure quality to the destinations as well as do things line multipat= h TCP

this statement is both incorrect and wildly unrealistic on real worl= d
networks, even from the most rarified theoretical point of view.

> Now if someone is really so weak on the edge and attaches to IX to onl= y
> peer locally we should perhaps invent co-located with RS pair of data<= br> > plane boxes where such weak guys would for forwarding just default to<= br> > such data plane gateway. That way those two forwarders could have as > many paths as RS feeds it with yet all weak clients are happy to forwa= rd
> and reach all open peers of a given IX.
>
> In fact most IX switches while running in L2 mode could be configured<= br> > for L3 as well so no need to even invest new $$$ needed.

this statement is incorrect at production ixps.

I would be happy to provide multiple counterexamples to all these points.
This draft is attempting to solve a real world problem on real world
networks.=C2=A0 It would be nice for ixp participants to have ideally
specified equipment providing service for clients which all had working, network-aware multipath implementations which could react immediately to blackholing events, but this doesn't even begin to approximate reality.=
Production IXPs need to be able to provide baseline services to a
hodge-podge of different types of equipment serving the great unwashed
of the internet.=C2=A0 There are very few assumptions you can make about equipment specification that will turn out to be realistic.

Nick

--f403045e6b285e2127054aaff4ee-- From nobody Tue Mar 14 05:54:05 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C3181293E0 for ; Tue, 14 Mar 2017 05:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bYz47rW476uV for ; Tue, 14 Mar 2017 05:54:02 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::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 D4CA7128874 for ; Tue, 14 Mar 2017 05:54:01 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id i34so54535074qtc.0 for ; Tue, 14 Mar 2017 05:54:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=FRxv86E/w7OQp1gskN7rPMI6yzx7V9yVNWvaVAbRjXE=; b=r+ToAq0O3MMqx/87VW0Ofk7CZs1lQk4zw4Bt//xYb+HQAb3ilzYtmbi1UU6NfsEeMj i+fNTCzTr76Fp/lX04FjfP1yn6Vw2vXQ8nU1ylseqHeaULn9DHokP8RBt3UEsgZMOA+n Dr5WIqi0XV58r1dOKFODXjlzC1JghWX0i0CXo8M+hrmtFRNbBCz/iaUL2QW6+rOG9Lng 0DuIjGKEMpSpS4LqLhbUB1qz/NVPx8coRKgC9EaT2cVgrWgkc94APDhTDO3B7w4KnX7H nGDbV4SfURxH9b3mZhi8HLtMuNyoAZtORzmNMX6Q9xq4t/yDzZqjG6PbeW1BL8WKdTwY 7HrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=FRxv86E/w7OQp1gskN7rPMI6yzx7V9yVNWvaVAbRjXE=; b=HWXi6lqHNGyj88j5PD+3yM6bs2rswJj5AT/4YQVTRPyNTXvXVPLJd972PFvj9TGLvZ LYN2ikxS70uM+UREXfStyhEtbKTQvZXPJu9DnejadmRdxnAZz1Ssa6MpxxMTM+JevyVC 8iNoIDE950OWQcHNC/RzRYo5AhoZ4VG1KJp75kwBey2L3lSxnvNRjSSwyh4b5P4hpdYb b42FHWqjzrlSzgPyaqSJKxyUN0VD1M2hY8l4oSbnpED1cVAhPBrkd97U9sGbEXM3aoea boMRbht/S96qxnCzW3VBJKU5g+UNZuY1HpwKdDwxR2P+7YYoFGT9t1Lrlpw9rd4MK8Z2 xOjQ== X-Gm-Message-State: AMke39l9yKhd7ouwG96VNRmsegnwXOzRd6Uz72MTlN55HAhzk9qyUwdtfsu8QPoPopgn6vy5qzysEzDj0kXF9g== X-Received: by 10.200.2.150 with SMTP id p22mr40089034qtg.197.1489496040862; Tue, 14 Mar 2017 05:54:00 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.140.42.181 with HTTP; Tue, 14 Mar 2017 05:54:00 -0700 (PDT) In-Reply-To: <20170314113203.GI2367@Space.Net> References: <148924277112.2960.17904473852401253352@ietfa.amsl.com> <20170314113203.GI2367@Space.Net> From: Robert Raszuk Date: Tue, 14 Mar 2017 13:54:00 +0100 X-Google-Sender-Auth: mhf9JYKKJXIL12Xm-_1W1S9_Q6A Message-ID: To: Gert Doering Content-Type: multipart/alternative; boundary=f4030435c234693803054ab052ea Archived-At: Cc: Interminable Discussion Room Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 12:54:04 -0000 --f4030435c234693803054ab052ea Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =E2=80=8B> Please enlighten yourself what people use "as peering router" to= day :-) Care to enlighten me on or offline ? Which BGP stacks can not handle full table ? ... and about the amount of prefixes you can receive on a reasonably-sized > IXP. > AMS-IX ... 160K v4 prefixes .. Ref: https://ams-ix.net/technical/statistics/route-server-stats LINX (all combined RSes) - 120K v4 prefixes https://stats.linx.net/rs/ JPIX - 20K v4 routes ... avrage grow 4K per year https://www.slideshare.net/apnic/the-trend-stats-of-routing-table-at-jpix-r= oute-servers Is this overwhelming ? Please notice that not all of them would churn on a daily basis too so your weak edge may choke only upon initial dump. No public data on how many paths each of those nets have. R. --f4030435c234693803054ab052ea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

=E2=80=8B>=C2=A0Please enlighten yoursel= f what people use "as peering router" today :-)

Care to enlighten me on or offline ? W= hich BGP stacks can not handle full table ?=C2=A0
<= br>

.= .. and about the amount of prefixes you can receive on a reasonably-sized IXP.


= AMS-IX ... 160K v4 prefixes .. =C2=A0
Ref: https://ams= -ix.net/technical/statistics/route-server-stats

LINX (all combined RSes) - 120K v4 prefixes
https://stats.linx.net/rs/

JPIX - 20K v4 routes ... avrage grow 4K per yea= r=C2=A0
https://www.slideshare.net/apnic= /the-trend-stats-of-routing-table-at-jpix-route-servers


Is this overwhelming ?= =C2=A0Please notice that not all of them would churn on a daily basis too s= o your weak edge may choke only upon initial dump.=C2=A0No public data on how many path= s each of those nets have.=C2=A0
<= span style=3D"font-family:arial,helvetica,sans-serif">
R.

--f4030435c234693803054ab052ea-- From nobody Tue Mar 14 05:56:08 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66C551294E4 for ; Tue, 14 Mar 2017 05:56:06 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nldhUZl-oVgj for ; Tue, 14 Mar 2017 05:56:04 -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 5F8FA12706D for ; Tue, 14 Mar 2017 05:56:04 -0700 (PDT) X-Envelope-To: idr@ietf.org Received: from cupcake.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id v2ECu10k087154 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Mar 2017 12:56:01 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be cupcake.local Message-ID: <58C7E860.3010403@foobar.org> Date: Tue, 14 Mar 2017 12:56:00 +0000 From: Nick Hilliard User-Agent: Postbox 5.0.11 (Macintosh/20170302) MIME-Version: 1.0 To: Robert Raszuk References: <148924277112.2960.17904473852401253352@ietfa.amsl.com> <58C7D45E.80704@foobar.org> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Interminable Discussion Room Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 12:56:06 -0000 Robert, your proposal is not even wrong. Nick Robert Raszuk wrote: > If someone is using weak BGP stacks which can not handle two BGP paths > per net .. sorry that to me does not justify inventing new SAFI. > > Moreover the idea behind the new SAFI is flawed since it assumes RS > always would have a secondary path to send to client. Otherwise noise of > 1000 peers bombarding RS with message "NH-X is not reachable" is pretty > useless if given net has only one NH on the RS. > > Moreover those weak clients which can not run best path for RS received > nets are now subject to handle 1000 BFD sessions ... it really does not > sound right that an edge can do the latter just fine and not the former. > > Last to address real world problem - I proposed very easy solution which > you as an IXP operator can enable today via simple config on your switch > and treat such switch (or pair of switches) as default forwarder. Done ! > Fully backward compatible with existing IXP deployment too. From nobody Tue Mar 14 06:30:28 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 464041294A7 for ; Tue, 14 Mar 2017 06:30:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YXyOceZpEOld for ; Tue, 14 Mar 2017 06:30:25 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::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 4CA9A129489 for ; Tue, 14 Mar 2017 06:30:25 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id v125so242689479qkh.2 for ; Tue, 14 Mar 2017 06:30:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=BDabjsWAKgmg8FNwlCZIMQacZMfwZhvX8C7ufsG7inc=; b=fpBLN7HBSUzTt01og6KAGisOWZFbAy6EIG6nAvzfmax97A7gTvEnq4E6jCK6Yay1Li 4A3NGtDCmDWORtJLYMeQEJ8ui/78FDbpZUqqzTYyMSnMAcVaPT5C6jihwYxxngTeuSTu Fk8KEmst93DCTGVwjV+pikdUhpoc0+nX6Afoo8Ivzc1GjnMGF9Jz6BBsx9XJ+94ILCur C67sy+vt46jRseDrTHcYuQX32CQisrQM2XscaNh3QhfsEOMDrdIK3In0amLWSzeJ/NDN pRGYYxi9/oqsFu0P9P4mIpQ/JfQf4+MPNWdDFW9FCEQ8LgEEx0VY89WwBc94e+Pqhy12 px/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=BDabjsWAKgmg8FNwlCZIMQacZMfwZhvX8C7ufsG7inc=; b=uJ+XmdaNQdA3Pb+Y/PdTwMy99UZ0az4aXskhnQJzH5H8oaQUrSg9JLid//C+VqxdGc mIdM52ith28B9hndYkDzkNXhtaWuHkUMP7vIjUd3YIR+4+orjgKUNSzhnVFX/mxVu/Ps n3hO3A2HOMs3RC3yDTonyRhVeXTQfvgImCQKZhFPn5vMPSTO2ir2sBTjFh0XChrCghIc Fbe1e254QhGqDa+/vNzy8ieHZnPe+e5JKLwbMTvVa844l3ccATDghSuOULfes6b9pkia 4ZKt279EHcvzYfNwP9EC+VxG/1kvBBnOxIJmGIcB6jk9TPE/vFi2Ueoowja3PzDjmLWA +WsA== X-Gm-Message-State: AMke39mn0jB0JKBiWPion5K5dESCj0hrNw3XTbQk+9IE41P3MN3lZkqY9QeTSLxc54Cbe8uWWcZJz7DFQFcnxQ== X-Received: by 10.55.144.4 with SMTP id s4mr35421992qkd.101.1489498224468; Tue, 14 Mar 2017 06:30:24 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.140.42.181 with HTTP; Tue, 14 Mar 2017 06:30:23 -0700 (PDT) In-Reply-To: <58C7E860.3010403@foobar.org> References: <148924277112.2960.17904473852401253352@ietfa.amsl.com> <58C7D45E.80704@foobar.org> <58C7E860.3010403@foobar.org> From: Robert Raszuk Date: Tue, 14 Mar 2017 14:30:23 +0100 X-Google-Sender-Auth: 8h_Lw5o6CYaocWTdev3F0dajW4w Message-ID: To: Nick Hilliard Content-Type: multipart/alternative; boundary=94eb2c057a70902c9a054ab0d4ba Archived-At: Cc: Interminable Discussion Room Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 13:30:27 -0000 --94eb2c057a70902c9a054ab0d4ba Content-Type: text/plain; charset=UTF-8 Clearly it requires a bit out of the box perspective ;-) For those interested it does borrow a bit from RFC6769 as well as from the notion of BGP Virtual Next Hop proposal/patent. Best, R. On Tue, Mar 14, 2017 at 1:56 PM, Nick Hilliard wrote: > Robert, > > your proposal is not even wrong. > > Nick > > Robert Raszuk wrote: > > If someone is using weak BGP stacks which can not handle two BGP paths > > per net .. sorry that to me does not justify inventing new SAFI. > > > > Moreover the idea behind the new SAFI is flawed since it assumes RS > > always would have a secondary path to send to client. Otherwise noise of > > 1000 peers bombarding RS with message "NH-X is not reachable" is pretty > > useless if given net has only one NH on the RS. > > > > Moreover those weak clients which can not run best path for RS received > > nets are now subject to handle 1000 BFD sessions ... it really does not > > sound right that an edge can do the latter just fine and not the former. > > > > Last to address real world problem - I proposed very easy solution which > > you as an IXP operator can enable today via simple config on your switch > > and treat such switch (or pair of switches) as default forwarder. Done ! > > Fully backward compatible with existing IXP deployment too. > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --94eb2c057a70902c9a054ab0d4ba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Clearly it= requires a bit out of the box perspective ;-)
=
For those interested it does borrow a bit from= RFC6769=C2=A0as well as from the not= ion of BGP Virtual Next Hop proposal/patent.

Best,
R.


On Tue, Mar 14, 2017 at 1:56 PM, Nick Hilliard <nick@foobar.org><= /span> wrote:
Robert,

your proposal is not even wrong.

Nick

Robert Raszuk wrote:
> If someone is using weak BGP stacks which can not handle two BGP paths=
> per net .. sorry that to me does not justify inventing new SAFI.
>
> Moreover the idea behind the new SAFI is flawed since it assumes RS > always would have a secondary path to send to client. Otherwise noise = of
> 1000 peers bombarding RS with message "NH-X is not reachable"= ; is pretty
> useless if given net has only one NH on the RS.
>
> Moreover those weak clients which can not run best path for RS receive= d
> nets are now subject to handle 1000 BFD sessions ... it really does no= t
> sound right that an edge can do the latter just fine and not the forme= r.
>
> Last to address real world problem - I proposed very easy solution whi= ch
> you as an IXP operator can enable today via simple config on your swit= ch
> and treat such switch (or pair of switches) as default forwarder. Done= !
> Fully backward compatible with existing IXP deployment too.

____________________________= ___________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

--94eb2c057a70902c9a054ab0d4ba-- From nobody Tue Mar 14 07:43:36 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1868D12025C for ; Tue, 14 Mar 2017 07:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4gKgW98xHb4B for ; Tue, 14 Mar 2017 07:43:33 -0700 (PDT) Received: from excession.bakker.net (home.bakker.net [IPv6:2001:888:1037:1337::53:53]) (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 272C312025D for ; Tue, 14 Mar 2017 07:43:33 -0700 (PDT) Received: by excession.bakker.net (Postfix, from userid 910) id 14A4D14A1; Tue, 14 Mar 2017 15:43:31 +0100 (CET) Date: Tue, 14 Mar 2017 15:43:30 +0100 From: niels@bakker.net (Niels Bakker) To: idr@ietf.org Message-ID: <20170314144330.GA48058@excession.tpb.net> References: <148924277112.2960.17904473852401253352@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 14:43:35 -0000 * robert@raszuk.net (Robert Raszuk) [Tue 14 Mar 2017, 11:05 CET]: >Learning two paths for given net with different NHs (even if RS has more >then two) seems to provide sufficient robustness and enables you to measure >quality to the destinations as well as do things line multipath TCP This would require a major rearchitecting of pretty much all network components out there because we'd be doing away with the concept of having one best path that's chosen by each hop handling a packet. >Now if someone is really so weak on the edge and attaches to IX to only >peer locally we should perhaps invent co-located with RS pair of data plane >boxes where such weak guys would for forwarding just default to such data >plane gateway. That way those two forwarders could have as many paths as RS >feeds it with yet all weak clients are happy to forward and reach all open >peers of a given IX. > >In fact most IX switches while running in L2 mode could be configured for >L3 as well so no need to even invest new $$$ needed. As Nick said, not even wrong. Route servers decouple the forwarding plane from the control plane in an additional way beyond what already happens inside routers for hardware design reasons. This draft seeks to add a mechanism to signal any dislocations, improving robustness of existing deployments. Regards, -- Niels (former IXP operator, current IXP participant hat) -- From nobody Tue Mar 14 08:04:23 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC901294EB for ; Tue, 14 Mar 2017 08:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uizpRp9Rpxcl for ; Tue, 14 Mar 2017 08:04:17 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A7EA1294E7 for ; Tue, 14 Mar 2017 08:04:17 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id v125so245118267qkh.2 for ; Tue, 14 Mar 2017 08:04:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=0sI4JAsaPFZDdnH7jAXtE4z8RchkXI/Ao1ygeQHtZ+8=; b=Z8xlOC+8qG5VUxeoEdjwnw/O0ztfS+nqsWIwyV3ryyk2X/ahtKAXaUsfCYRgzTiXCO hDyx0mpbonAj9CUtrPIK9b5b49O23MaTiwXjFCgfQa6xR9LJtSryLabpXMNFbqvJyH5V XzWPwNwumC1sulsImhX+TECFenn+pV8oAGh461wmvOLn09yxBpMiiIhLnxDV7NiRC7VM cF0T39pgs3y+RjU36xMUaBqdRk7g75k4NQd7Vy1x8mLVfS4so7G/eObIBQkhfDCJgCIF 1p/HtfYCM8J4tOzJcA4SUJ/GYZUCRhH2VtHACqdEzPhYF4Ids1KDCpd0ssIkHiik5FRm nPww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=0sI4JAsaPFZDdnH7jAXtE4z8RchkXI/Ao1ygeQHtZ+8=; b=HjttYfn/eLYDh9Z8izWpp4oOkcQLNWEy4tDBQpfSuUaPjmCs6ep12DE3fLcnMs69Gu xiTjgY84cS2DTKihRIEqx1XWDJj4ohtO/XT/sxKEnCQ2ohzTJGFAtBrOcQIt5rq+62PQ FA5gWV6WMLHpJMcBiPSjD+exaT4tkXYFGsyJOpuA47TFAKINg0VPl1vpTSNdlGKzUZyJ 97+tmkLNg0kbA6o6plG67HUtVDgSFShjPoA0z9U5Uuggl/YjtGVexDjNPbGxfZrJon2N Nn0JrVR83Iw3brY0BnpBPoO5QwwkktGVnFPqBMD/BkOGMbW3vuu+d3sK9+PRj0voaT6n 8FzQ== X-Gm-Message-State: AFeK/H23SkXJE8Pj5xKjaVlnnsT1BmJmJU+xNn4oxWpM1hyAFOrOxvQWLIv80eYwz7Hwd1R329RXLJMQiVhqgQ== X-Received: by 10.55.18.158 with SMTP id 30mr39544396qks.123.1489503856434; Tue, 14 Mar 2017 08:04:16 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.140.42.181 with HTTP; Tue, 14 Mar 2017 08:04:15 -0700 (PDT) In-Reply-To: <20170314144330.GA48058@excession.tpb.net> References: <148924277112.2960.17904473852401253352@ietfa.amsl.com> <20170314144330.GA48058@excession.tpb.net> From: Robert Raszuk Date: Tue, 14 Mar 2017 16:04:15 +0100 X-Google-Sender-Auth: T9_JpY_ilTQRhSKaERY2h_zAs_c Message-ID: To: Niels Bakker Cc: idr wg Content-Type: multipart/alternative; boundary=001a1146f482412999054ab2244e Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 15:04:20 -0000 --001a1146f482412999054ab2244e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Not sure if we should continue this thread .... I think all what needs to be said has been said already regarding proposed draft. But just to clarify on your questions: > Learning two paths for given net with different NHs (even if RS has more >> then two) seems to provide sufficient robustness and enables you to >> measure >> quality to the destinations as well as do things line multipath TCP >> > > This would require a major rearchitecting of pretty much all network > components out there because we'd be doing away with the concept of havin= g > one best path that's chosen by each hop handling a packet. =E2=80=8BWhen IX client advertises=E2=80=8B a route to Route Server it will= still advertise best path only as he sets nhs. When RS today already import to per client bRIB all paths (if available) and selects best then advertises it to all peers (subject to policy). Only change is needed is to advertise with either add-paths or diverse-path second best. No major change at all. One line config on existing routers. =E2=80=8BN=E2=80=8B >> ow if someone is really so weak on the edge and attaches to IX to only >> peer locally we should perhaps invent co-located with RS pair of data >> plane >> boxes where such weak guys would for forwarding just default to such dat= a >> plane gateway. That way those two forwarders could have as many paths as >> RS >> feeds it with yet all weak clients are happy to forward and reach all op= en >> peers of a given IX. >> >> In fact most IX switches while running in L2 mode could be configured fo= r >> L3 as well so no need to even invest new $$$ needed. >> > > As Nick said, not even wrong. > > Route servers decouple the forwarding plane from the control plane in an > additional way beyond what already happens inside routers for hardware > design reasons. =E2=80=8BI am not saying that Route Servers should be doing forwarding ... = if this is what you are trying to address by the above comment. RS would send all paths they know =E2=80=8Babout to device which will act a= s a forwarder in the middle of IX. Sitting close or being a function of L3 forwarding on the switch allows to have all weak clients go via such pair of routers. No suboptimal routing as packets go via the switch anyway, no 1000 x 1000 BFD sessions between all clients, quick local repair in case of path failure ... and such device could be used only for those open policy destinations which do have more then one path in the first place. Yes this is not the model IX do today ... but is this sufficient reason to dismiss it - provided above basic solution of sending more then best path would perhaps be not feasible. Thx, R. > This draft seeks to add a mechanism to signal any dislocations, improving > robustness of existing deployments. > > Regards, > > > -- Niels (former IXP operator, current IXP participant hat) > > -- > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --001a1146f482412999054ab2244e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Not sure i= f we should continue this thread =C2=A0....=C2=A0 I think all what needs to= be said has been said already regarding proposed draft. But just to clarif= y on your questions:

=C2=A0
Learning two paths for given net w= ith different NHs (even if RS has more
then two) seems to provide sufficient robustness and enables you to measure=
quality to the destinations as well as do things line multipath TCP

 This would require a major rearchitecting of pretty much all network compon= ents out there because we'd be doing away with the concept of having on= e best path that's chosen by each hop handling a packet.

=E2=80=8BWhen IX client advertises=E2= =80=8B a route to Route Server it will still advertise best path only as he= sets nhs. When RS today already import to per client bRIB all paths (if av= ailable) and selects best then advertises it to all peers (subject to polic= y).=C2=A0

Only change = is needed is to advertise with either add-paths or diverse-path second best= . No major change at all. One line config on existing routers.=C2=A0
<= br>

<= span class=3D"">
=E2=80=8BN=E2=80=8B
ow if someone is really s= o weak on the edge and attaches to IX to only
peer locally we should perhaps invent co-located with RS pair of data plane=
boxes where such weak guys would for forwarding just default to such data plane gateway. That way those two forwarders could have as many paths as RS=
feeds it with yet all weak clients are happy to forward and reach all open<= br> peers of a given IX.

In fact most IX switches while running in L2 mode could be configured for L3 as well so no need to even invest new $$$ needed.

As Nick said, not even wrong.

Route servers decouple the forwarding plane from the control plane in an ad= ditional way beyond what already happens inside routers for hardware design= reasons.=C2=A0

=E2=80= =8BI am not saying that Route Servers should be doing forwarding ... if thi= s is what you are trying to address by the above comment.=C2=A0

RS would send all paths they know= =E2=80=8Babout to device which will act as a forwarder in the middle of IX= . Sitting close or being a function of L3 forwarding on the switch allows t= o have all weak clients go via such pair of routers. No suboptimal routing = as packets go via the switch anyway, no 1000 x 1000 BFD sessions between al= l clients, quick local repair in case of path failure ... and such device c= ould be used only for those open policy destinations which do have more the= n one path in the first place.=C2=A0

Yes this is not the model IX do today ... but is this suffic= ient reason to dismiss it - provided above basic solution of sending more t= hen best path would perhaps be not feasible. =C2=A0=C2=A0

Thx,
R.=

=C2=A0
This d= raft seeks to add a mechanism to signal any dislocations, improving robustn= ess of existing deployments.

Regards,


=C2=A0 =C2=A0 =C2=A0 =C2=A0 -- Niels (former IXP operator, current IXP part= icipant hat)

--

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

--001a1146f482412999054ab2244e-- From nobody Tue Mar 14 08:38:56 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96EE4129680 for ; Tue, 14 Mar 2017 08:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1MHvsvuzLj_n for ; Tue, 14 Mar 2017 08:38:52 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4184712967E for ; Tue, 14 Mar 2017 08:38:52 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v2EFcnmx003789; Tue, 14 Mar 2017 15:38:49 GMT Received: from 950129200 ([176.241.251.4]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v2EFcgff003582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Mar 2017 15:38:48 GMT Reply-To: From: "Adrian Farrel" To: "'Susan Hares'" Cc: Date: Tue, 14 Mar 2017 15:38:43 -0000 Message-ID: <048701d29cd9$15204b80$3f60e280$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdKc2PV/e/RaEO6zQqqFeoyOTWvYcA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22942.000 X-TM-AS-Result: No--20.282-10.0-31-10 X-imss-scan-details: No--20.282-10.0-31-10 X-TMASE-MatchedRID: /bTTn+BoLfHTTjedRTCyDbTTMie9o0HdGSqdEmeD/nWna6U74e0+qLt+ i+Gg5iN8MSeq2sKeo9a7G026MQdKytTgPtgJJv6U3FqOVb7PDEJxZkR+u3smBfgnJH5vm2+gMwR yrAxy6J/0shMOy8dT8blImD8msNmxAZpqQblsTtNIcJTn2HkqsbQdzjQ9SbpyIFBEE5CFomKLc1 PIi3pXyr+BnJG/GSueY7V+phOVvxC8eaYomTBk5Eim+3pSpOPvwx0jRRxcQfPceXQ6q2ggSuS8/ V4lJBIYmlgl1zH9ECYA+AuR2hjATwCIHz1SKy8sr1KBVnj2tAwhmbYg1ZcOnsUmcSma304TKEil pp/NgyBbRbsK17zp0rrquzCUUsb+2vHXB5YKlQWrVklnbP5Jtu4dka7CjortFRlN8zTSzj76uPu Mcca1IFlcqyLieSwWi42Qfj/RkgGm3t4b0+rBhVaOpp/sV5nVSGyGlRuVtF0m1kf23NRabliNxV LlNmEJQtUpXtJeY0jfOX4vEq5EGs4R2cR+uasawCZxkTHxccm+1Vx7rDn4ryXEq8wEhaRLdn5HT OCw5bg11NKL0g27ZISntUu3UyDoW0WwPyv6x8zM1jffIgQXhl+U6kGoEdO3wg96cEZFZobKK48A a8Xh3p6Ss6O2bihGhfezGru4hFABUM2WwgFZp5+EzsRrGT9I+LidURF+DB0rUBPM1gcCKFc0URi jKiYefsS7adBrPw/2MyF1ukkvJkE5KffbFcTc+VbPOV9CBzpcSMp/1+Epp1+aJfM1BJF8h7TTfm bVivq5PLviRCQQggNc2rDf2fw/VDt884Mvu5CeAiCmPx4NwLTrdaH1ZWqCpvI8UZOf47jUZxEAl FPo846HM5rqDwqtlExlQIQeRG0= Archived-At: Subject: [Idr] Thoughts on https://www.ietf.org/id/draft-hares-idr-bgp-registries-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 15:38:54 -0000 Hi Sue and all, Sue, thanks for getting the ball rolling by putting pen to paper. This gives us something concrete to work with. I think you are trying to address two separate problems in the document. They are both important issues that need a solution, but I think there is a problem conflating them. 1. How to stop code point squatting in all its guises 2. How to stop code point allocations through the normal IANA process for "ideas that could use more review". IMHO you are addressing the second point well with your proposals in this draft. That is, you are introducing a relatively low cost cross-check for allocations from a large set of BGP registries by making them require both their current allocation procedures *and* expert review. To complete the documentation of this process two further things are needed: a. Advice to the Designated Experts. This can be quite simple, but it is intended to add some predictability and continuity to the way that DEs approach the question of a new assignment. b. Recognition that IETF consensus trumps DE opinion. Hopefully this will never arise, but it is clear (or should be) that for a Standards Action registry, if there is IETF consensus for an assignment, then the DEs can warn and advise, but the will of the IETF takes precedence. This can be particularly lumpy because the DEs don't get invoked until after IETF last call. It may be worth describing this situation and explaining how the DEs should handle it. The first point is different, and it may help to break it down into several pieces: i. Squatting in WG drafts ii. Squatting in individual I-Ds iii. Squatting outside the IETF IDR is certainly not the only WG to have faced this problem. Solutions include: i. Chairs must make sure it doesn't happen! Require WG I-Ds to be reposted at once with code point values left out. Use early allocation procedures to get real values assigned. ii. Chairs can take some action by explaining that an I-D will not be adopted when it contains code point values. It may help to understand why squatting happens. Sometimes the authors are just trying to be helpful by "suggesting" values that could be assigned - this is addressed through firmness by the chairs, and education. Sometimes the authors are doing an early implementation and need a code point - this is handled by early allocation and by use of experimental code points. In some cases, the chairs may need to help drafts be adopted into the WG and reviewed so that early allocation can be done. Of course, another way to handle squatting is to make it very, very easy to get a legitimate code point. On the whole this requires a change to the allocation policy for the registries. FCFS or Expert Review are good solutions, but (obviously) if a registry is marked as "IETF Review" assigning an expert doesn't help because the rules of IETF Review still have to be applied. Some people try to fix this as "IETF Review or Expert Review" but since the lowest common denominator will apply, this might as well just be "Expert Review". And, in case of moving to FCFS or Expert Review, the WG has to be clear that it is willingly giving up *any* input into the control of code point assignment. Cheers, Adrian > -----Original Message----- > From: John G. Scudder [mailto:jgs@juniper.net] > Sent: 14 March 2017 14:17 > To: adrian@olddog.co.uk > Cc: Jeff Haas > Subject: Re: https://www.ietf.org/id/draft-hares-idr-bgp-registries-01.txt > > I think Sue has crossed the beams. (This happens frequently.) > > I've long thought ER might not be a bad idea for BGP SA (and similar) registries. > This is not for any of the reasons Sue lists, but because we (IDR chairs) have been > blindsided more than once by an RFC being issued that made some kind of > elementary gaffe. An example is the Entropy Label Capability Attribute. ADs have > promised us "oh we'll take care of that and make sure it never happens again", > then it happens again. ER seems like a straightforward and already extant piece > of process machinery to apply to the problem of making sure IDR gets informed > before the RFC issues. > > The squatting thing is probably at the forefront of Sue's mind for obvious > reasons, but as you say, this doesn't help at all. (Very little will help other than > large unconstrained code point spaces, which can be retrofitted in some cases. Of > course, those will lead to the problem of uncoordinated development of > protocols and extensions that are too ossified to be changed and so will be > presented as a fait accompli when brought to the IETF. Pay me now, pay me later. > > --John > > > On Mar 14, 2017, at 7:37 AM, Adrian Farrel wrote: > > > > Hi, > > > > I probably don't mind how this pans out, but I am curious as to what problem > > this is fixing. > > > > The draft says "people squatted on code points" and I don't think this change in > > process will stop that. > > > > But maybe the intention is to reduce the motivation for squatting (or to make it > > easier to not squat). > > > > Now, the document goes on to suggest that adding an expert review option will > > make that happen because it will "increase the pace of early allocation." That > > suggests that the problem is the pace of early allocation. So, why not fix that > > problem? > > > > But, looking at RFC 7120, it is up to the WG chairs to determine when early > > allocation should be made. So how is that different from having expert review > > with the chairs appointed as the designated experts? > > > > In short, I don't think this draft is fixing anything: just fiddling. > > > > Adrian > > From nobody Tue Mar 14 08:58:27 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 470701296FB for ; Tue, 14 Mar 2017 08:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iKo7GcJPQW9H for ; Tue, 14 Mar 2017 08:58:25 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87D8212966C for ; Tue, 14 Mar 2017 08:58:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1510; q=dns/txt; s=iport; t=1489507104; x=1490716704; h=from:to:cc:subject:date:message-id:mime-version; bh=g22uidwEwYw7mleWc+dd1as3VjPtDclW97wg/XIGVZ4=; b=NeAkY2LqYgli6SFsNV6OYTuhhuctwED4LjwWEwo2WR/1QOhib4LJoa7A 0t8EHlvuUg4aq5MuCZoML4+098GDZev7CZcZCRoOAnUGvOIBy4g7YmRc1 UzZDmD1RWfZxYfvyWFOhCLUznjuLZH/87RlVsQRVE7iV1K3lUi0HVVmoF Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AjAQDgEshY/4oNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1FhgRGNZqFjgx6CD4IOKoV4glk/GAECAQEBAQEBAWsohQyBCRI?= =?us-ascii?q?BCwEKaicEAQ2KBQ6vUopiAQEBAQEBAQMBAQEBAQEBAQEBGQWVdgWcQwGGdYtFk?= =?us-ascii?q?SWTRgEfOIEEWBWHGIkagQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.36,164,1486425600"; d="scan'208,217";a="220246860" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Mar 2017 15:58:23 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v2EFwNIC019612 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 14 Mar 2017 15:58:23 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 14 Mar 2017 11:58:22 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Tue, 14 Mar 2017 11:58:22 -0400 From: "Acee Lindem (acee)" To: Susan Hares , John Scudder , Jie Dong CC: IDR List , Shawn Zandi , Keyur Patel Thread-Topic: IETF 98 IDR Slot Thread-Index: AQHSnNvOM7s1P0JETE2IMEbEc7tHNg== Date: Tue, 14 Mar 2017 15:58:22 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.198] Content-Type: multipart/alternative; boundary="_000_D4ED8B5BA213Caceeciscocom_" MIME-Version: 1.0 Archived-At: Subject: [Idr] IETF 98 IDR Slot X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 15:58:26 -0000 --_000_D4ED8B5BA213Caceeciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sue, John, Jie, Can we get a 10 minute slot for this draft? https://datatracker.ietf.org/doc/draft-acee-idr-lldp-peer-discovery/ Thanks, Acee --_000_D4ED8B5BA213Caceeciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <896D23AEF300AA42AC2B50E62FE7088D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Sue, John, Jie, 

Can we get a 10 minute slot for = ;this draft? 



Thanks,
Acee 
--_000_D4ED8B5BA213Caceeciscocom_-- From nobody Tue Mar 14 09:19:41 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2B22132946 for ; Tue, 14 Mar 2017 09:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yzV-wMBuXB8o for ; Tue, 14 Mar 2017 09:19:38 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 5AAFA12975C for ; Tue, 14 Mar 2017 09:19:38 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=70.194.5.9; From: "Susan Hares" To: "'Acee Lindem \(acee\)'" , "'John Scudder'" , "'Jie Dong'" Cc: "'IDR List'" , "'Shawn Zandi'" , "'Keyur Patel'" References: In-Reply-To: Date: Tue, 14 Mar 2017 12:14:33 -0400 Message-ID: <01c001d29cde$11dc2ac0$35948040$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01C1_01D29CBC.8ACCADA0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKdSQWagp77cpIAT7On7V/cgYqW7p//Kf5g Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] IETF 98 IDR Slot X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 16:19:39 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01C1_01D29CBC.8ACCADA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Acee: I've got this request. I will be putting up a list of proposed talks. Sue From: Acee Lindem (acee) [mailto:acee@cisco.com] Sent: Tuesday, March 14, 2017 11:58 AM To: Susan Hares; John Scudder; Jie Dong Cc: IDR List; Shawn Zandi; Keyur Patel Subject: IETF 98 IDR Slot Sue, John, Jie, Can we get a 10 minute slot for this draft? https://datatracker.ietf.org/doc/draft-acee-idr-lldp-peer-discovery/ Thanks, Acee ------=_NextPart_000_01C1_01D29CBC.8ACCADA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Acee:

 

I’ve got this request.  I will be putting up a list of = proposed talks.

 

Sue

 

From:= = Acee Lindem (acee) [mailto:acee@cisco.com]
Sent: Tuesday, = March 14, 2017 11:58 AM
To: Susan Hares; John Scudder; Jie = Dong
Cc: IDR List; Shawn Zandi; Keyur Patel
Subject: = IETF 98 IDR Slot

 

Sue, John, = Jie, 

 

Can = we get a 10 minute slot for this = draft? 

 

------=_NextPart_000_01C1_01D29CBC.8ACCADA0-- From nobody Tue Mar 14 09:53:31 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5A3D13294F; Tue, 14 Mar 2017 09:53:29 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=verizon.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vkv8qDpdqSZ3; Tue, 14 Mar 2017 09:53:27 -0700 (PDT) Received: from omzsmtpe02.verizonbusiness.com (omzsmtpe02.verizonbusiness.com [199.249.25.209]) (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 F2B141297C6; Tue, 14 Mar 2017 09:53:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=verizon.com; i=@verizon.com; q=dns/txt; s=corp; t=1489510407; x=1521046407; h=from:to:date:subject:message-id:references:in-reply-to: mime-version; bh=YX5uX043ZRNduOpgZslycmeNODTGxM3mugBeicqwSNI=; b=DDjqu0imCbbRr/XJZPcbxQyvZsF2JQrq9LgIQ0hOyLxq1MwNABhI/87P r+2shIhlrowbUsJI6vfr/1+Ll7YLkU0AQE/StTeaglKqBjtzf5N39H3XD Zq0kSqQObvUxuZwfcEzuvVg91d8+DS0BUBcrFQ4V/eyrelCoIsMP2X9Ex 0=; X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145]) by omzsmtpe02.verizonbusiness.com with ESMTP; 14 Mar 2017 16:53:25 +0000 From: "Tomotaki, Luis M" X-IronPort-AV: E=Sophos;i="5.36,164,1486425600"; d="scan'208,217";a="312548415" Received: from fhdp1lumxc7hb01.verizon.com (HELO FHDP1LUMXC7HB01.us.one.verizon.com) ([166.68.59.188]) by fldsmtpi03.verizon.com with ESMTP/TLS/AES128-SHA; 14 Mar 2017 16:52:45 +0000 Received: from FHDP1LUMXC7V91.us.one.verizon.com ([166.68.240.155]) by FHDP1LUMXC7HB01.us.one.verizon.com ([166.68.59.188]) with mapi; Tue, 14 Mar 2017 12:52:45 -0400 To: Ron Bonica , Susan Hares , 'Shitanshu Shah' , "rtg-dir@ietf.org" , "draft-ietf-idr-sla-exchange.all@ietf.org" , "idr@ietf.org" Date: Tue, 14 Mar 2017 12:52:43 -0400 Thread-Topic: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 Thread-Index: AdKIcLCEU+uutt39QyCrZCwOKAXyLQAcLKCoAUVZnUABwWlZAABkf7iDAEubxBAAGLyHgADK0jWAAGYFHyA= Message-ID: <467340A77F13C944919805BFF3B8ACFC30DC040884@FHDP1LUMXC7V91.us.one.verizon.com> References: , <053401d294fc$6f739180$4e5ab480$@ndzh.com> <467340A77F13C944919805BFF3B8ACFC30DC040408@FHDP1LUMXC7V91.us.one.verizon.com> <011601d2981f$cfe364c0$6faa2e40$@ndzh.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_467340A77F13C944919805BFF3B8ACFC30DC040884FHDP1LUMXC7V9_" MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 16:53:30 -0000 --_000_467340A77F13C944919805BFF3B8ACFC30DC040884FHDP1LUMXC7V9_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ron, Are you available for a quick call on Thursday at 10AM CT? Luis From: Ron Bonica [mailto:rbonica@juniper.net] Sent: Sunday, March 12, 2017 11:11 AM To: Susan Hares ; Tomotaki, Luis M ; 'Shitanshu Shah' ; rtg-dir@ietf.org; = draft-ietf-idr-sla-exchange.all@ietf.org; idr@ietf.org Subject: [E] RE: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange= -10 Luis, This discussion might require a slightly higher bandwidth channel. Feel fre= e to call me whenever you get a chance. Ron 571 203 1= 704 From: Susan Hares [mailto:shares@ndzh.com] Sent: Wednesday, March 8, 2017 10:23 AM To: EXT - luis.tomotaki@verizon.com >; 'Shitanshu Shah' = >; Ron Bonica= >; rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; idr@ietf.org Subject: RE: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 Luis: Thank you for letting me know you desire for this feature. Since Ron had = additional questions, I'll let him start off this discussion. Sue From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Tomotaki, Luis M Sent: Tuesday, March 7, 2017 11:11 PM To: Shitanshu Shah; Susan Hares; 'Ron Bonica'; rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; idr@ietf.org Subject: Re: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 Ron and Sue, >From a service provider perspective, exchanging the SLA information between= the PE and CE would be very beneficial and could be widely used. I think = this is particular important in service provider's L3VPN networks where the= customers or service providers currently do not have full visibility to th= e QoS policy in the other end of the connection but still needs matching CE= -PE SLA/QoS policies to achieve the correct two-way traffic prioritization = behavior during congestion. In this example, once the SLA information exch= ange is standardized, my expectation is that the different CE/PE vendors wo= uld be able to automatically update in a vendor specific way, the SLA/QoS p= olicies based on the SLA information provided via BGP. Luis From: Shitanshu Shah [mailto:shitanshu_shah@hotmail.com] Sent: Monday, March 6, 2017 9:31 AM To: Susan Hares >; 'Ron Bonica' >; rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; idr@ietf.org Subject: [E] Re: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 Hi Sue, Following is what I had responded to Ron. Hopefully that addresses/clarifie= s. To break it down in two point response, 1) This draft is not changing how SLA is established at first place. The dr= aft is providing a method to convey this a priori established SLA to help r= educe lot of manual complexities and errors to admin. Thus given a knowledg= e of what SLA is established, in general devices should be capable to suppo= rt that established SLA. 2) If there still are any issues in implementing exchanged SLA in forwardin= g, we think they either are implementation specific or of temporary nature = where for example enough resources not available at any specific point of a= time. We feel that in current state of the draft, it can be largely useful in dep= loyments. One can imagine though even establishment of SLA also can be done via excha= nging it over bgp. However, negotiation of SLA does not have to be clubbed = with exchange of SLA. Negotiation of SLA is not in this scope. Regards, Shitanshu ________________________________ From: Susan Hares > Sent: Saturday, March 4, 2017 8:31 AM To: 'Ron Bonica'; 'Shitanshu Shah'; rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; idr@ietf.org Subject: RE: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 Shitanshu: Please address Ron's comment about widely deployed. I believe this was par= t of Alvaro's comments. Sue From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Ron Bonica Sent: Thursday, February 23, 2017 12:07 PM To: Shitanshu Shah; rtg-dir@ietf.org; draft-ietf-i= dr-sla-exchange.all@ietf.org; idr@ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 Hello, The draft is internally consistent. But given what is left out of scope, I = wonder if the new attributes will ever be widely deployed. = Ron This document might benefit from discussion of operational issues. I assume= that when a BGP listener learns a route with the SLA Exchange Attribute, i= t provisions class of service forwarding classes on interfaces. ##svshah, though this is one desired use of exchanging SLA content, the dra= ft focuses on transporting SLA content from the SLA Producer to the SLA Con= sumer. Processing of the QoS attribute content, at the SLA Consumer, is out= side the scope of this document. ##svshah, Let me know if you have a suggestion to make description clearer = in Section 1 and 2 to highlight this. I also assume that a) it takes time to provision class of service forwardin= g classes and b) the number of forwarding classes that can be provisioned a= re finite. What does the BGP listener do when the number of forwarding clas= ses requested exceeds its capacity to deliver? ##svshah, Since scope of the document is to transport SLA content from the = SLA Producer to the SLA Consumer, the document considers error handling in = the context of transporting data and thus any formating errors and semantic= s errors within that context. Any errors in the context of processing QoS a= ttribute content at the SLA Consumer is outside the scope of the document. --_000_467340A77F13C944919805BFF3B8ACFC30DC040884FHDP1LUMXC7V9_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Ron,

Are you available for = a quick call on Thursday at 10AM CT?

 

Luis

 

From: Ron Bonica [mailto:rbonica@juniper.net]
<= b>Sent: Sunday, March 12, 2017 11:11 AM
To: Susan Hares <s= hares@ndzh.com>; Tomotaki, Luis M <luis.tomotaki@one.verizon.com>;= 'Shitanshu Shah' <shitanshu_shah@hotmail.com>; rtg-dir@ietf.org; dra= ft-ietf-idr-sla-exchange.all@ietf.org; idr@ietf.org
Subject: [E] = RE: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10

 

Luis,

 

This discussion might req= uire a slightly higher bandwidth channel. Feel free to call me whenever you= get a chance.

 

     &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;         Ron

        =             &nb= sp;            =             &nb= sp;            =         571 203 1704

 

 

<= div>

From: Susan Hares [mailto:shares@ndzh.com]
Sent: Wednesday, March 8, 2= 017 10:23 AM
To: EXT - luis.tomotaki@verizon.com <luis.tomotaki@verizon.com>; 'Shitanshu Shah' <shitanshu_shah@hotmail.com>; Ron B= onica <rbonica@juniper.net>= ;; rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.a= ll@ietf.org; idr@ietf.org
Sub= ject: RE: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10=

 

Luis:

 

Thank you for l= etting me know you desire for this feature.   Since Ron had addit= ional questions, I’ll let him start off this discussion. <= /span>

 

Sue

&= nbsp;

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of= Tomotaki, Luis M
Sent: Tuesday, March 7, 2017 11:11 PM
To: Shitanshu Shah; Susan Hares; 'Ron Bonica'; rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; idr@ietf.org
Subject: Re: [Idr] [RTG= -DIR] RtgDir review: draft-ietf-idr-sla-exchange-10

 

Ron and Sue,

From a servi= ce provider perspective, exchanging the SLA information between the PE and = CE would be very beneficial and could be widely used.  I think this is= particular important in service provider’s L3VPN networks where the = customers or service providers currently do not have full visibility to the= QoS policy in the other end of the connection but still needs matching CE-= PE SLA/QoS policies to achieve the correct two-way traffic prioritization b= ehavior during congestion.  In this example, once the SLA information = exchange is standardized, my expectation is that the different CE/PE vendor= s would be able to automatically update in a vendor specific way, the SLA/Q= oS policies based on the SLA information provided via BGP. 

 

Luis

=  

From: Shitanshu Shah = [mailto:shitanshu_shah@hotmai= l.com]
Sent: Monday, March 6, 2017 9:31 AM
To: Sus= an Hares <shares@ndzh.com>; 'R= on Bonica' <rbonica@juniper.net>; rtg-dir@ietf.org; draft-ietf-idr-sla-exc= hange.all@ietf.org; idr@ietf.orgSubject: [E] Re: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchan= ge-10

 

Hi Sue,

 

= Following is w= hat I had responded to Ron. Hopefully that addresses/clarifies.

 

To break it down in two point response,

 

1) This draft is not changing how SLA is established at first = place. The draft is providing a method to convey this a priori establi= shed SLA to help reduce lot of manual complexities and errors to admin= . Thus given a knowledge of what SLA is established, in general devices sho= uld be capable to support that established SLA.

<= p> <= /o:p>

 

2) If there still are any issues in implementing exch= anged SLA in forwarding, we think they either are implementation specific o= r of temporary nature where for example enough resources not available= at any specific point of a time.

 

= We feel that i= n current state of the draft, it can be largely useful in deployments.=

 

 

 

One can imagine th= ough even establishment of SLA also can be done via exchanging it over= bgp. However, negotiation of SLA does not have to be clubbed with exchange= of SLA. Negotiation of SLA is not in this scope.

<= span style=3D'font-family:"Calibri",sans-serif;color:black'> 

Regards,

S= hitanshu

<= o:p> 

From: Susan Hares <= ;shares@ndzh.com>
Sent:= Saturday, March 4, 2017 8:31 AM
To: 'Ron Bonica'; 'Shitanshu Sha= h'; rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.= all@ietf.org; idr@ietf.org
Su= bject: RE: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 =

 

Shitanshu: <= /p>

 <= /p>

Please address Ron’s comment about widely deployed.&nb= sp; I believe this was part of Alvaro’s comments.

 

Sue

 

From: rtg-dir [mailto:rtg-d= ir-bounces@ietf.org] On Behalf Of Ron Bonica
Sent: Thu= rsday, February 23, 2017 12:07 PM
To: Shitanshu Shah; rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; idr@ietf.org
Subject: Re: = [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10

 

Hello,

 

The draft is internally = consistent. But given what is left out of scope, I wonder if the new attrib= utes will ever be widely deployed.<= /o:p>

 <= /o:p>

        = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;         Ron

 

 


This document might be= nefit from discussion of operational issues. I assume that when a BGP liste= ner learns a route with the SLA Exchange Attribute, it provisions class of = service forwarding classes on interfaces.

 

##svshah, though this is one desired use of exch= anging SLA content, the draft focuses on transporting SLA content from the = SLA Producer to the SLA Consumer. Processing of the QoS attribute content, = at the SLA Consumer, is outside the scope of this document.

<= p style=3D'min-height:13px'> 

##svshah, Let me know if you have a suggestion to= make description clearer in Section 1 and 2 to highlight this.<= /p>

 

 <= o:p>

I also assume that a) it takes ti= me to provision class of service forwarding classes and b) the number of fo= rwarding classes that can be provisioned are finite. What does the BGP list= ener do when the number of forwarding classes requested exceeds its capacit= y to deliver? 

 <= /span>

##svshah, Since scope of the document is to transport SLA conten= t from the SLA Producer to the SLA Consumer, the document considers error h= andling in the context of transporting data and thus any formating errors a= nd semantics errors within that context. Any errors in the context of proce= ssing QoS attribute content at the SLA Consumer is outside the scope of the= document.

 

 

 <= /span>

= --_000_467340A77F13C944919805BFF3B8ACFC30DC040884FHDP1LUMXC7V9_-- From nobody Tue Mar 14 10:04:06 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B59E13297D; Tue, 14 Mar 2017 10:04:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tKtZnZAWk48m; Tue, 14 Mar 2017 10:04:01 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0117.outbound.protection.outlook.com [104.47.32.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3645A132970; Tue, 14 Mar 2017 10:04:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=LEzTuoZh56+KnXm/vUJWto6kKFlFJYbqZPRhStFNKYU=; b=RwHCP91kEq2+vfRTHrUNxJHCrCuvprlSAbUCtohbb3KI1VKPSiJvUS9w1i9KXc1bcIBSSsDLISAOJ3Nh85C2JXavzie7UdXTG890ER1phPo9uRp6nn4AS5DI4x25hdpjWAxp+a93WMSYOhRJnHSHxNTUM6nxaRo0P8g5QzFTyp0= Received: from BLUPR0501MB2051.namprd05.prod.outlook.com (10.164.23.21) by BLUPR0501MB2052.namprd05.prod.outlook.com (10.164.23.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.977.5; Tue, 14 Mar 2017 17:03:59 +0000 Received: from BLUPR0501MB2051.namprd05.prod.outlook.com ([10.164.23.21]) by BLUPR0501MB2051.namprd05.prod.outlook.com ([10.164.23.21]) with mapi id 15.01.0977.010; Tue, 14 Mar 2017 17:03:59 +0000 From: Ron Bonica To: "EXT - luis.tomotaki@verizon.com" , Susan Hares , 'Shitanshu Shah' , "rtg-dir@ietf.org" , "draft-ietf-idr-sla-exchange.all@ietf.org" , "idr@ietf.org" Thread-Topic: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 Thread-Index: AdKIcLCEU+uutt39QyCrZCwOKAXyLQAcLKCoAUVZnUABwWlZAABkf7iDAEubxBAAGLyHgADK0jWAAGYFHyAAAG3nIA== Date: Tue, 14 Mar 2017 17:03:58 +0000 Message-ID: References: , <053401d294fc$6f739180$4e5ab480$@ndzh.com> <467340A77F13C944919805BFF3B8ACFC30DC040408@FHDP1LUMXC7V91.us.one.verizon.com> <011601d2981f$cfe364c0$6faa2e40$@ndzh.com> <467340A77F13C944919805BFF3B8ACFC30DC040884@FHDP1LUMXC7V91.us.one.verizon.com> In-Reply-To: <467340A77F13C944919805BFF3B8ACFC30DC040884@FHDP1LUMXC7V91.us.one.verizon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: verizon.com; dkim=none (message not signed) header.d=none;verizon.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.10] x-microsoft-exchange-diagnostics: 1; BLUPR0501MB2052; 7:cLiR1UcfzcHln9E/255zXT/PkpD5t462G6rQ+lynVWJekf/mjYR36R1EJGVG2TNBRhxfNOXH21YxuW4kWGdQAkPL6qm9W4NbnrC4VkYZr4zFtjqS0v1deEtWWEZzETjBs+5UTI84cu7UtupSHC9YJyUeonVtbZ8qXfSCNmpiYHitnVVTXkwz/ILHhN6kQyq8Mkp5phtAH8H5r94wvKPSpAMcOfOgL0H1TQZxhAIyXmJ7b8jBOVOwLBpjqIgiEwfRkZwmGM4WhQpVd6HUO1w3f6wMgk12op+9Uak7xD7TPq+EUYMhXvsI7zXNIyv7yyfAnJyVtfnbOFrvjO7gwvj0Rg== x-ld-processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr x-ms-office365-filtering-correlation-id: 5109b8c3-e374-40c6-18ba-08d46afc1b75 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BLUPR0501MB2052; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(194151415913766)(21748063052155)(154440410675630); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(20161123564025)(20161123562025)(20161123555025)(20161123558025)(6072148); SRVR:BLUPR0501MB2052; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB2052; x-forefront-prvs: 02462830BE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39840400002)(39450400003)(39860400002)(39850400002)(39410400002)(54094003)(377454003)(122556002)(77096006)(7696004)(2950100002)(189998001)(53546007)(8936002)(3660700001)(3280700002)(8676002)(345774005)(76176999)(54356999)(81166006)(50986999)(53936002)(9686003)(2900100001)(236005)(790700001)(102836003)(66066001)(2906002)(68736007)(3846002)(6436002)(93886004)(2501003)(55016002)(229853002)(7736002)(74316002)(5660300001)(6116002)(33656002)(6306002)(6506006)(86362001)(54896002)(2201001)(25786008)(99286003)(6246003)(39060400002)(38730400002)(230783001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB2052; H:BLUPR0501MB2051.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BLUPR0501MB2051AA5C645181C5AF5F7141AE240BLUPR0501MB2051_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Mar 2017 17:03:58.9713 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB2052 Archived-At: Subject: Re: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 17:04:04 -0000 --_000_BLUPR0501MB2051AA5C645181C5AF5F7141AE240BLUPR0501MB2051_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes. I will send you a meeting invite. Feel free to forward it. Ron From: Tomotaki, Luis M [mailto:luis.tomotaki@verizon.com] Sent: Tuesday, March 14, 2017 12:53 PM To: Ron Bonica ; Susan Hares ; 'Shita= nshu Shah' ; rtg-dir@ietf.org; draft-ietf-idr-s= la-exchange.all@ietf.org; idr@ietf.org Subject: RE: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 Hi Ron, Are you available for a quick call on Thursday at 10AM CT? Luis From: Ron Bonica [mailto:rbonica@juniper.net] Sent: Sunday, March 12, 2017 11:11 AM To: Susan Hares >; Tomotaki, Luis M= >; 'Sh= itanshu Shah' >; rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.= all@ietf.org; idr@ietf.org= Subject: [E] RE: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange= -10 Luis, This discussion might require a slightly higher bandwidth channel. Feel fre= e to call me whenever you get a chance. Ron 571 203 1= 704 From: Susan Hares [mailto:shares@ndzh.com] Sent: Wednesday, March 8, 2017 10:23 AM To: EXT - luis.tomotaki@verizon.com >; 'Shitanshu Shah' = >; Ron Bonica= >; rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; idr@ietf.org Subject: RE: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 Luis: Thank you for letting me know you desire for this feature. Since Ron had = additional questions, I'll let him start off this discussion. Sue From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Tomotaki, Luis M Sent: Tuesday, March 7, 2017 11:11 PM To: Shitanshu Shah; Susan Hares; 'Ron Bonica'; rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; idr@ietf.org Subject: Re: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 Ron and Sue, >From a service provider perspective, exchanging the SLA information between= the PE and CE would be very beneficial and could be widely used. I think = this is particular important in service provider's L3VPN networks where the= customers or service providers currently do not have full visibility to th= e QoS policy in the other end of the connection but still needs matching CE= -PE SLA/QoS policies to achieve the correct two-way traffic prioritization = behavior during congestion. In this example, once the SLA information exch= ange is standardized, my expectation is that the different CE/PE vendors wo= uld be able to automatically update in a vendor specific way, the SLA/QoS p= olicies based on the SLA information provided via BGP. Luis From: Shitanshu Shah [mailto:shitanshu_shah@hotmail.com] Sent: Monday, March 6, 2017 9:31 AM To: Susan Hares >; 'Ron Bonica' >; rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; idr@ietf.org Subject: [E] Re: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 Hi Sue, Following is what I had responded to Ron. Hopefully that addresses/clarifie= s. To break it down in two point response, 1) This draft is not changing how SLA is established at first place. The dr= aft is providing a method to convey this a priori established SLA to help r= educe lot of manual complexities and errors to admin. Thus given a knowledg= e of what SLA is established, in general devices should be capable to suppo= rt that established SLA. 2) If there still are any issues in implementing exchanged SLA in forwardin= g, we think they either are implementation specific or of temporary nature = where for example enough resources not available at any specific point of a= time. We feel that in current state of the draft, it can be largely useful in dep= loyments. One can imagine though even establishment of SLA also can be done via excha= nging it over bgp. However, negotiation of SLA does not have to be clubbed = with exchange of SLA. Negotiation of SLA is not in this scope. Regards, Shitanshu ________________________________ From: Susan Hares > Sent: Saturday, March 4, 2017 8:31 AM To: 'Ron Bonica'; 'Shitanshu Shah'; rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; idr@ietf.org Subject: RE: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 Shitanshu: Please address Ron's comment about widely deployed. I believe this was par= t of Alvaro's comments. Sue From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Ron Bonica Sent: Thursday, February 23, 2017 12:07 PM To: Shitanshu Shah; rtg-dir@ietf.org; draft-ietf-i= dr-sla-exchange.all@ietf.org; idr@ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 Hello, The draft is internally consistent. But given what is left out of scope, I = wonder if the new attributes will ever be widely deployed. = Ron This document might benefit from discussion of operational issues. I assume= that when a BGP listener learns a route with the SLA Exchange Attribute, i= t provisions class of service forwarding classes on interfaces. ##svshah, though this is one desired use of exchanging SLA content, the dra= ft focuses on transporting SLA content from the SLA Producer to the SLA Con= sumer. Processing of the QoS attribute content, at the SLA Consumer, is out= side the scope of this document. ##svshah, Let me know if you have a suggestion to make description clearer = in Section 1 and 2 to highlight this. I also assume that a) it takes time to provision class of service forwardin= g classes and b) the number of forwarding classes that can be provisioned a= re finite. What does the BGP listener do when the number of forwarding clas= ses requested exceeds its capacity to deliver? ##svshah, Since scope of the document is to transport SLA content from the = SLA Producer to the SLA Consumer, the document considers error handling in = the context of transporting data and thus any formating errors and semantic= s errors within that context. Any errors in the context of processing QoS a= ttribute content at the SLA Consumer is outside the scope of the document. --_000_BLUPR0501MB2051AA5C645181C5AF5F7141AE240BLUPR0501MB2051_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes. I will send you a meeting invite= . Feel free to forward it.

 

      &= nbsp;           &nbs= p;          Ron

 

&nbs= p;

From: Tomotaki, Luis M [mailto:luis.= tomotaki@verizon.com]
Sent: Tuesday, March 14, 2017 12:53 PM
To: Ron Bonica <rbonica@juniper.net>; Susan Hares <shares@n= dzh.com>; 'Shitanshu Shah' <shitanshu_shah@hotmail.com>; rtg-dir@i= etf.org; draft-ietf-idr-sla-exchange.all@ietf.org; idr@ietf.org
Subject: RE: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-excha= nge-10

 

Hi Ron,

Are you available for a quick call on= Thursday at 10AM CT?

 

Luis

 

From: Ron Bonica [mailto:rbonica@juniper.net]
Sent: Sunday, March 12, 2017 11:11 AM
To: Susan Hares <shares@ndzh.c= om>; Tomotaki, Luis M <luis.tomotaki@one.verizon.com>; 'Shitanshu Shah' <shitanshu_shah@hotmail.com>; rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; idr@ietf.org
Subject: [E] RE: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-e= xchange-10

 

Luis,

 

This discussion might require a sligh= tly higher bandwidth channel. Feel free to call me whenever you get a chanc= e.

 

      &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;        Ron

      &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;         571 203 1704

 

 

From: Susan Hares [mailto:shares@ndzh.com]
Sent: Wednesday, March 8, 2017 10:23 AM
To: EXT - luis.tomotaki= @verizon.com <luis.tomo= taki@verizon.com>; 'Shitanshu Shah' <shitanshu_shah@hotmail.com>; Ron Bonica <rbonica@juniper.net<= /a>>; rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; idr@ietf.org
Subject: RE: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-excha= nge-10

 

Luis:

 

Thank you for letting me know you des= ire for this feature.   Since Ron had additional questions, IR= 17;ll let him start off this discussion.

 

Sue

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Tomotaki, Luis M
Sent: Tuesday, March 7, 2017 11:11 PM
To: Shitanshu Shah; Susan Hares; 'Ron Bonica'; rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; idr@ietf.org
Subject: Re: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-excha= nge-10

 

Ron and Sue,

From a service provider perspective, = exchanging the SLA information between the PE and CE would be very benefici= al and could be widely used.  I think this is particular important in service provider’s L3VPN networks where the = customers or service providers currently do not have full visibility to the= QoS policy in the other end of the connection but still needs matching CE-= PE SLA/QoS policies to achieve the correct two-way traffic prioritization behavior during congestion.  In this e= xample, once the SLA information exchange is standardized, my expectation i= s that the different CE/PE vendors would be able to automatically update in= a vendor specific way, the SLA/QoS policies based on the SLA information provided via BGP. 

 

Luis

 

From: Shitanshu Shah [mailto:shitanshu_shah@hotmail.com]
Sent: Monday, March 6, 2017 9:31 AM
To: Susan Hares <shares@ndzh.c= om>; 'Ron Bonica' <rbonica= @juniper.net>; rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; idr@ietf.org
Subject: [E] Re: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchang= e-10

 

H= i Sue,

<= o:p> 

F= ollowing is what I had responded to Ron. Hopefully that addresses/clar= ifies.

<= o:p> 

T= o break it down in two point response,

<= o:p> 

1= ) This draft is not changing how SLA is established at first place. The dra= ft is providing a method to convey this a priori established SLA = to help reduce lot of manual complexities and errors to admin. Thus given a knowledge of what SLA is established, in general devic= es should be capable to support that established SLA.

<= o:p> 

<= o:p> 

2= ) If there still are any issues in implementing exchanged SLA in forwarding= , we think they either are implementation specific or of temporary nat= ure where for example enough resources not available at any specific point of a time.

<= o:p> 

W= e feel that in current state of the draft, it can be largely useful in depl= oyments.

<= o:p> 

<= o:p> 

<= o:p> 

O= ne can imagine though even establishment of SLA also can be done via e= xchanging it over bgp. However, negotiation of SLA does not have to be club= bed with exchange of SLA. Negotiation of SLA is not in this scope.

<= o:p> 

Regards,

Shitanshu

 <= /p>

From: Susan = Hares <shares@ndzh.com>
Sent: Saturday, March 4, 2017 8:31 AM
To: 'Ron Bonica'; 'Shitanshu Shah'; rtg-dir@ietf.org; draft-ietf-idr-= sla-exchange.all@ietf.org; idr@ietf.org
Subject: RE: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10=

 

Shitanshu:

 

Please address Ron’s comment about widely dep= loyed.  I believe this was part of Alvaro’s comments.

 

Sue

 

From: rtg-dir [mailto:rtg-dir-bounces@ietf.o= rg] On Behalf Of Ron Bonica
Sent: Thursday, February 23, 2017 12:07 PM
To: Shitanshu Shah; rtg-dir@ietf= .org; draft-ietf-idr-= sla-exchange.all@ietf.org; idr@ietf.org
Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10=

 

Hello,

 

The draft is internally consistent. But given what = is left out of scope, I wonder if the new attributes will ever be widely deployed.

 

        &nb= sp;            =             &nb= sp;            =             &nb= sp;            =          Ron

 

 


This document might benefit from discussion of operational issues. I assume= that when a BGP listener learns a route with the SLA Exchange Attribute, i= t provisions class of service forwarding classes on interfaces.

 <= /span>

##svshah, = though this is one desired use of exchanging SLA content, the draft focuses= on transporting SLA content from the SLA Producer to the SLA Consumer. Pro= cessing of the QoS attribute content, at the SLA Consumer, is outside the scope of this document.<= /span>

 

##svshah, = Let me know if you have a suggestion to make description clearer in Section= 1 and 2 to highlight this.

 <= /span>

 <= /span>

I also assume that a) it takes time to provision clas= s of service forwarding classes and b) the number of forwarding classes that can be provisioned are finite. What does the BG= P listener do when the number of forwarding classes requested exceeds its c= apacity to deliver? 

 <= /span>

##svshah, = Since scope of the document is to transport SLA content from the SLA Produc= er to the SLA Consumer, the document considers error handling in the contex= t of transporting data and thus any formating errors and semantics errors within that context. Any errors in t= he context of processing QoS attribute content at the SLA Consumer is outsi= de the scope of the document.

 

 <= /span>

 <= /span>

--_000_BLUPR0501MB2051AA5C645181C5AF5F7141AE240BLUPR0501MB2051_-- From nobody Tue Mar 14 10:07:35 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6087913299B for ; Tue, 14 Mar 2017 10:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ll2JgFeYCXrw for ; Tue, 14 Mar 2017 10:07:32 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF1D213299C for ; Tue, 14 Mar 2017 10:07:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3642; q=dns/txt; s=iport; t=1489511251; x=1490720851; h=from:to:cc:subject:date:message-id:mime-version; bh=PZOpY6kJZMSUQm7Y2g6MkGw9t8RyEHB6n7X/tK34LPg=; b=OfP9BQLfqW0pP/XIoa7N28Dgoila7e5Epx4SUUv+mNQkVZVkZuhVULCN HbqgsiPXBmDtffHtKf+RGADSntSUNclCKUXcv+mlRKpYLMOA7I9/8+YDO LUOAQwKZQJcIziEAeXbqkN3KiYMW2ClyMXa3iCCJU6ckQ0Q3pBaVyFgQC g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AkAQBTIshY/5ldJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5jYYERjWahY4Megg+CDiqFeIJZPxgBAgEBAQEBAQFrKIYVEgE?= =?us-ascii?q?MdCcEAQ2KBQ6wAIpbAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWGToYTiRUFnEMBh?= =?us-ascii?q?nWLRYF7hSWKAwKTRgEfOIEEWBWFHRiBY4kagQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.36,164,1486425600"; d="scan'208,217";a="223291255" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Mar 2017 17:07:30 +0000 Received: from XCH-RTP-010.cisco.com (xch-rtp-010.cisco.com [64.101.220.150]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v2EH7U2Q006192 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 14 Mar 2017 17:07:30 GMT Received: from xch-rtp-012.cisco.com (64.101.220.152) by XCH-RTP-010.cisco.com (64.101.220.150) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 14 Mar 2017 13:07:30 -0400 Received: from xch-rtp-012.cisco.com ([64.101.220.152]) by XCH-RTP-012.cisco.com ([64.101.220.152]) with mapi id 15.00.1210.000; Tue, 14 Mar 2017 13:07:29 -0400 From: "Gaurav Dawra (gdawra)" To: "jie.dong@huawei.com" , "jgs@juniper.net" , "shares@ndzh.com" , "idr@ietf.org" CC: "Patrice Brissette (pbrisset)" , "Clarence Filsfils (cfilsfil)" Thread-Topic: [IDR] Slots request for IDR WG session - IETF 98 - Chicago Thread-Index: AQHSnOV2w8hjE1GT1US5XCgwoYozRw== Date: Tue, 14 Mar 2017 17:07:29 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.0.161029 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.155.39.126] Content-Type: multipart/alternative; boundary="_000_D4ED6ABE1D6C63gdawraciscocom_" MIME-Version: 1.0 Archived-At: Subject: [Idr] [IDR] Slots request for IDR WG session - IETF 98 - Chicago X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 17:07:33 -0000 --_000_D4ED6ABE1D6C63gdawraciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Sue, John, Jie, Apologies, sending again with revised slot request. We have published below= draft and we appreciate if we can please request for 15 mins slot, if at a= ll possible. draft-dawra-idr-srv6-vpn (https://datatracker.ietf.org/doc/draft-dawra-idr-= srv6-vpn/) 15mins Gaurav Dawra, Patrice Brissette Regards, Gaurav --_000_D4ED6ABE1D6C63gdawraciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <8B32CFD2A2F0F94599118821F668A8EA@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi, Sue, John, Jie,

   

Apologies, sending again with revised slot request. We have published belo= w draft and we appreciate if we can please request for 15 mins slot, if at = all possible.


draft-dawra-idr-srv6-vpn (https://datatracker.ietf.org/doc/draft-dawra-idr-srv= 6-vpn/)


15mins=

Gaurav Dawra, <= /span>Patrice Brissette 

 

Regards,


Gaurav


--_000_D4ED6ABE1D6C63gdawraciscocom_-- From nobody Tue Mar 14 10:23:16 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD931329C7 for ; Tue, 14 Mar 2017 10:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Msxa43JwoOJ9 for ; Tue, 14 Mar 2017 10:23:13 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 460E712960F for ; Tue, 14 Mar 2017 10:23:13 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=70.194.5.9; From: "Susan Hares" To: Cc: References: <048701d29cd9$15204b80$3f60e280$@olddog.co.uk> In-Reply-To: <048701d29cd9$15204b80$3f60e280$@olddog.co.uk> Date: Tue, 14 Mar 2017 13:18:26 -0400 Message-ID: <022201d29ce6$ffb2ba40$ff182ec0$@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: AQHgLJVhftftdlZ2OeQGM5dxbx7ZtaF5ZOpA Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] Thoughts on https://www.ietf.org/id/draft-hares-idr-bgp-registries-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 17:23:15 -0000 Adrian: Thank you for this analysis. This proposal was aimed at #2. For the education in #1, see Jeff Haas' slides from the last IETF. Your comments on what Chair's need to do are helpful comments. For getting early allocations, I still believe the WG needs to be in the process. I agree we need to work on "why" people squat. For this, I hope we will have a good discussion on IDR and Grow - at the very least. Sue -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Tuesday, March 14, 2017 11:39 AM To: 'Susan Hares' Cc: idr@ietf.org Subject: Thoughts on https://www.ietf.org/id/draft-hares-idr-bgp-registries-01.txt Hi Sue and all, Sue, thanks for getting the ball rolling by putting pen to paper. This gives us something concrete to work with. I think you are trying to address two separate problems in the document. They are both important issues that need a solution, but I think there is a problem conflating them. 1. How to stop code point squatting in all its guises 2. How to stop code point allocations through the normal IANA process for "ideas that could use more review". IMHO you are addressing the second point well with your proposals in this draft. That is, you are introducing a relatively low cost cross-check for allocations from a large set of BGP registries by making them require both their current allocation procedures *and* expert review. To complete the documentation of this process two further things are needed: a. Advice to the Designated Experts. This can be quite simple, but it is intended to add some predictability and continuity to the way that DEs approach the question of a new assignment. b. Recognition that IETF consensus trumps DE opinion. Hopefully this will never arise, but it is clear (or should be) that for a Standards Action registry, if there is IETF consensus for an assignment, then the DEs can warn and advise, but the will of the IETF takes precedence. This can be particularly lumpy because the DEs don't get invoked until after IETF last call. It may be worth describing this situation and explaining how the DEs should handle it. The first point is different, and it may help to break it down into several pieces: i. Squatting in WG drafts ii. Squatting in individual I-Ds iii. Squatting outside the IETF IDR is certainly not the only WG to have faced this problem. Solutions include: i. Chairs must make sure it doesn't happen! Require WG I-Ds to be reposted at once with code point values left out. Use early allocation procedures to get real values assigned. ii. Chairs can take some action by explaining that an I-D will not be adopted when it contains code point values. It may help to understand why squatting happens. Sometimes the authors are just trying to be helpful by "suggesting" values that could be assigned - this is addressed through firmness by the chairs, and education. Sometimes the authors are doing an early implementation and need a code point - this is handled by early allocation and by use of experimental code points. In some cases, the chairs may need to help drafts be adopted into the WG and reviewed so that early allocation can be done. Of course, another way to handle squatting is to make it very, very easy to get a legitimate code point. On the whole this requires a change to the allocation policy for the registries. FCFS or Expert Review are good solutions, but (obviously) if a registry is marked as "IETF Review" assigning an expert doesn't help because the rules of IETF Review still have to be applied. Some people try to fix this as "IETF Review or Expert Review" but since the lowest common denominator will apply, this might as well just be "Expert Review". And, in case of moving to FCFS or Expert Review, the WG has to be clear that it is willingly giving up *any* input into the control of code point assignment. Cheers, Adrian > -----Original Message----- > From: John G. Scudder [mailto:jgs@juniper.net] > Sent: 14 March 2017 14:17 > To: adrian@olddog.co.uk > Cc: Jeff Haas > Subject: Re: > https://www.ietf.org/id/draft-hares-idr-bgp-registries-01.txt > > I think Sue has crossed the beams. (This happens frequently.) > > I've long thought ER might not be a bad idea for BGP SA (and similar) registries. > This is not for any of the reasons Sue lists, but because we (IDR > chairs) have been > blindsided more than once by an RFC being issued that made some kind > of elementary gaffe. An example is the Entropy Label Capability > Attribute. ADs have > promised us "oh we'll take care of that and make sure it never happens > again", then it happens again. ER seems like a straightforward and > already extant piece > of process machinery to apply to the problem of making sure IDR gets > informed before the RFC issues. > > The squatting thing is probably at the forefront of Sue's mind for > obvious reasons, but as you say, this doesn't help at all. (Very > little will help other than > large unconstrained code point spaces, which can be retrofitted in some cases. Of > course, those will lead to the problem of uncoordinated development of > protocols and extensions that are too ossified to be changed and so > will be presented as a fait accompli when brought to the IETF. Pay me > now, pay me later. > > --John > > > On Mar 14, 2017, at 7:37 AM, Adrian Farrel wrote: > > > > Hi, > > > > I probably don't mind how this pans out, but I am curious as to what > > problem this is fixing. > > > > The draft says "people squatted on code points" and I don't think > > this change in > > process will stop that. > > > > But maybe the intention is to reduce the motivation for squatting > > (or to make it > > easier to not squat). > > > > Now, the document goes on to suggest that adding an expert review > > option will > > make that happen because it will "increase the pace of early allocation." That > > suggests that the problem is the pace of early allocation. So, why > > not fix that > > problem? > > > > But, looking at RFC 7120, it is up to the WG chairs to determine > > when early allocation should be made. So how is that different from > > having expert review > > with the chairs appointed as the designated experts? > > > > In short, I don't think this draft is fixing anything: just fiddling. > > > > Adrian > > From nobody Tue Mar 14 12:01:08 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C772313149B for ; Tue, 14 Mar 2017 12:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.022 X-Spam-Level: X-Spam-Status: No, score=-0.022 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZTwYXLF3dUe for ; Tue, 14 Mar 2017 12:01:01 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0126.outbound.protection.outlook.com [104.47.36.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC458131457 for ; Tue, 14 Mar 2017 12:00:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=c5txAdLxKSbk0onqI+XYQF/RlmC5BSrrX2fhfGXMep4=; b=NPum3zShwoQaufwCWs5xi03sqwnmn9YgGM0FzcNSuxRK/Ze1QYFKro7lgbiUiIpGNb/fqxoNpdGnd8PXl9c+xVzP+FtTZIi89+Pdinfq+JSKD3o71xkoppXDa4fUKgB5VyWaoRTLy2B0dyG9rkwP0xtlOHMRyd5JJso099PYmlI= Received: from SN2PR05MB2671.namprd05.prod.outlook.com (10.166.212.142) by SN2PR05MB2669.namprd05.prod.outlook.com (10.166.212.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.2; Tue, 14 Mar 2017 19:00:54 +0000 Received: from SN2PR05MB2671.namprd05.prod.outlook.com ([10.166.212.142]) by SN2PR05MB2671.namprd05.prod.outlook.com ([10.166.212.142]) with mapi id 15.01.0977.010; Tue, 14 Mar 2017 19:00:53 +0000 From: Kaliraj Vairavakkalai To: "idr@ietf.org" Thread-Topic: Request WG adoption for draft-gredler-idr-bgplu-epe Thread-Index: AQHSnPVOfZ0qSRg+P0iH2zbRNjhxsg== Date: Tue, 14 Mar 2017 19:00:53 +0000 Message-ID: <54AF9ADE-1FB7-447F-8F81-E10D0B787DEB@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.11] x-microsoft-exchange-diagnostics: 1; SN2PR05MB2669; 7:eJMwCP4wqcvbCYYfwaIeHzAVvoce6wizRWK2ZgZNKAp3nrnqeF9hAjOZ6s25htPHHq7v5ULXCiwy8rmN3bn/1/edjH1PJHNp1mxpj8YizaBVPNgZqgjx4R2Ln5myC2KIOWKZ1OvsXhCSDQ6GBstNcqVI1naIJ0WF1w5EZ0bF2JyUeYtPoPV0YQBmL3zkZrG5ChVY+X3d322uRTpd6HH/2kjbgyDT94RsO5Noeibmy0Q531ZO7VTgLlO+cQVSISAZNrVFc6YSzMbvdN/B0DFypaBNIM3irq/DrmMqhYKYUar48FdrdSlm9cfU0N6CYxD82a8HT2fxkDdMLDHEK8M1eQ== x-ms-office365-filtering-correlation-id: e0473f9b-3ca3-41bf-3001-08d46b0c70a7 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:SN2PR05MB2669; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123564025)(20161123555025)(20161123562025)(20161123558025)(20161123560025)(6072148); SRVR:SN2PR05MB2669; BCL:0; PCL:0; RULEID:; SRVR:SN2PR05MB2669; x-forefront-prvs: 02462830BE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39840400002)(39850400002)(39450400003)(39860400002)(305945005)(7736002)(6486002)(83716003)(66066001)(8676002)(2900100001)(53936002)(83506001)(2351001)(2501003)(86362001)(2906002)(82746002)(6506006)(5660300001)(81166006)(1730700003)(106116001)(3280700002)(8936002)(50986999)(54356999)(6916009)(33656002)(6116002)(3846002)(3660700001)(102836003)(6512007)(38730400002)(25786008)(99286003)(230783001)(6306002)(122556002)(558084003)(6436002)(5640700003)(36756003)(77096006)(189998001)(110136004)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR05MB2669; H:SN2PR05MB2671.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Mar 2017 19:00:53.9266 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR05MB2669 Archived-At: Subject: [Idr] Request WG adoption for draft-gredler-idr-bgplu-epe X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 19:01:06 -0000 SGkgSURSIFdHLCANCg0KVGhlIGF1dGhvcnMgb2YgZm9sbG93aW5nIGluZm9ybWF0aW9uYWwtZHJh ZnQgd291bGQgbGlrZSB0byByZXF1ZXN0IGl0cyBhZG9wdGlvbiBieSB0aGUgSURSIHdvcmtpbmcg Z3JvdXAgYXMgYSBXRy1kb2N1bWVudC4gDQoNCiAgZHJhZnQtZ3JlZGxlci1pZHItYmdwbHUtZXBl ICAgRWdyZXNzIFBlZXIgRW5naW5lZXJpbmcgdXNpbmcgQkdQLUxVDQoNCiAgaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZ3JlZGxlci1pZHItYmdwbHUtZXBlLyANCg0KVGhh bmtzLCANCkthbGlyYWogDQooY28tYXV0aG9yKSANCg0K From nobody Tue Mar 14 12:02:24 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D44A1299D2 for ; Tue, 14 Mar 2017 12:02:23 -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=[RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xwePK45EvSqi for ; Tue, 14 Mar 2017 12:02:20 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id EEF9E1314BE for ; Tue, 14 Mar 2017 12:01:38 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 244241E33B; Tue, 14 Mar 2017 15:02:16 -0400 (EDT) Date: Tue, 14 Mar 2017 15:02:15 -0400 From: Jeffrey Haas To: idr@ietf.org Message-ID: <20170314190215.GA12864@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: Subject: [Idr] [internet-drafts@ietf.org: I-D Action: draft-ietf-idr-flowspec-interfaceset-03.txt] X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 19:02:23 -0000 Note that the only change in -03 was to update the IANA considerations so that the proposal could proceed with first come, first serve extended community allocation from IANA. The authors intend to address the points Geoff Huston raised as part of early routing directorate review in the next revision. No protocol changes are expected to result from that update. -- Jeff ----- Forwarded message from internet-drafts@ietf.org ----- Date: Sat, 11 Mar 2017 07:17:07 -0800 From: internet-drafts@ietf.org To: i-d-announce@ietf.org Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-flowspec-interfaceset-03.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing of the IETF. Title : Applying BGP flowspec rules on a specific interface set Authors : Stephane Litkowski Adam Simpson Keyur Patel Jeff Haas Lucy Yong Filename : draft-ietf-idr-flowspec-interfaceset-03.txt Pages : 15 Date : 2017-03-11 Abstract: BGP flowspec is an extension to BGP that allows for the dissemination of traffic flow specification rules. The primary application of this extension is DDoS mitigation where the flowspec rules are applied in most cases to all peering routers of the network. This document will present another use case of BGP flowspec where flow specifications are used to maintain some access control lists at network boundary. BGP flowspec is a very efficient distributing machinery that can help in saving OPEX while deploying/updating ACLs. This new application requires flow specification rules to be applied only on a specific subset of interfaces and in a specific direction. The current specification of BGP flowspec ([RFC5575]) introduces the notion of flow specification (which describes the matching criterion) and traffic filtering actions. The flow specification is encoded as part of the NLRI while the traffic filtering actions are encoded as extended communities. The combination of a flow specification and one or more actions is known as a flow specification rule. [RFC5575] does not detail where the flow specification rules need to be applied. Besides the flow specification and traffic filtering actions, this document introduces the notion of traffic filtering scope in order to drive where a particular rule must be applied. In particular, this document introduces the "interface-set" traffic filtering scope that could be used in parallel of traffic filtering actions (marking, rate-limiting ...). The purpose of this extension is to inform remote routers about groups of interfaces where the rule must be applied. This extension can also be used in a DDoS mitigation context where a provider wants to apply the filtering only on specific peers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-interfaceset/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-flowspec-interfaceset-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-flowspec-interfaceset-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr ----- End forwarded message ----- From nobody Tue Mar 14 12:24:28 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64EB41299D5 for ; Tue, 14 Mar 2017 12:24:27 -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=[RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WAi7I700dBTf for ; Tue, 14 Mar 2017 12:24:26 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 4412A1299D4 for ; Tue, 14 Mar 2017 12:24:26 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id A2DCB1E33B; Tue, 14 Mar 2017 15:30:36 -0400 (EDT) Date: Tue, 14 Mar 2017 15:30:36 -0400 From: Jeffrey Haas To: idr@ietf.org Message-ID: <20170314193036.GC12864@pfrc.org> References: <03ae01d29c3e$6c5d87a0$451896e0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <03ae01d29c3e$6c5d87a0$451896e0$@ndzh.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Idr] draft-hares-deprecate-atomic-aggregate (was Re: Request for 2 drafts) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 19:24:27 -0000 Sue, On Mon, Mar 13, 2017 at 05:11:45PM -0400, Susan Hares wrote: > I'd like to follow-up on our "clean up" the attribute area discussion. > > I've published: [...] > > draft-hares-deprecate-atomic-aggregate-00 I'd actually recommend against outright deprecating AA. Mostly it'll lead to confusion of compliant implementations of 1771/4271 without a lot of benefit. A significant amount of the controversy around the feature while standardizing 4271 had to do with the rules by which AA was attached to routes. I suspect very few people besides Tony Li ever had a strong opinion about the behavior, especially once we got beyond the BGP-3 transition. (And I wasn't there at the time. The Tony observation is driven mostly by him popping up a few years ago with a proposal that included AA behavior.) The current behavior of 4271 with regard to AA is pretty mild: If you're dropping out ASes from the path as part of aggregation, you SHOULD add this thing. If you see it, don't de-aggregate. People generally don't de-aggregate magically these days and those who do generally expect to have to be very careful. The document that I thought was worth writing at some point, even if it only was a draft and never got published, was a short discussion about the origin of the feature, what its original intent was, what was broken about its original rules to be attached and why we ended up where we did. This is arguably a history document intending to document a rather ugly bit of living history that confuses newcomers to the protocol. I'm happy to contribute to such a document. But I don't recommend we proceed down the path to deprecation. -- Jeff From nobody Tue Mar 14 12:39:04 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F120129A87 for ; Tue, 14 Mar 2017 12:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fmHMDKXTqVjH for ; Tue, 14 Mar 2017 12:38:35 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0133.outbound.protection.outlook.com [104.47.42.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95BB5129A7C for ; Tue, 14 Mar 2017 12:38:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=zPQm5pTJ71Rw6LOc2AF6tQVyQPJfLnuAV8wy/VeZaOQ=; b=jsQU2k/9kgCA6DQKuw5f2Q9LcPbDNgswi9y2TrbrNm3e8OOohqyRg6N7s5sO77Ec+6fQm6LgIbrNxFt+XpL0QIHz9JVMsakHbPDbLETvoTclXhkn8pPwr1Bzhwgpxs83sqk2ajGIXVluI+2w4TSYFeEOotF9I+dSvLOk9Cq3xvY= Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=juniper.net; Received: from [172.29.33.162] (66.129.241.11) by BL2PR05MB2178.namprd05.prod.outlook.com (10.167.98.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.977.5; Tue, 14 Mar 2017 19:38:15 +0000 To: Susan Hares , References: <048701d29cd9$15204b80$3f60e280$@olddog.co.uk> <022201d29ce6$ffb2ba40$ff182ec0$@ndzh.com> CC: From: Eric C Rosen Message-ID: Date: Tue, 14 Mar 2017 15:38:12 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <022201d29ce6$ffb2ba40$ff182ec0$@ndzh.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.11] X-ClientProxiedBy: CY4PR09CA0094.namprd09.prod.outlook.com (10.172.133.160) To BL2PR05MB2178.namprd05.prod.outlook.com (10.167.98.138) X-MS-Office365-Filtering-Correlation-Id: 7d245099-385b-43c8-4193-08d46b11a924 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BL2PR05MB2178; X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2178; 3:p3zd1LbgNW5+pD+aWPM7bs2m1oZ8XpCx7sg9vqUuZS7kshEGE4YleoNdcUvNO/reLFMy3c12FKef8UKiT9seWXGc4GPXAPCOWoO3qYnw8jDC21zMH0EwrlTu0SosMJ262ZhBQdOwIz592bCSVh3wDbDr2CDtaCiNnAVOUIl+D11NPL8IBxAe4GQ7ewZWadWaQFqqFSiockrcNKEuDLg47nfBNjw4QlDJsyZ/uJ43wWGKapZ2d2Iwz5HawBto9idziRQB4azb0P0jALAsQnv/4Yy5tgHsUIPDCTCY8felw7M=; 25:8IOmaFFgfB1IZ8/3QwiPFzRShZ85hJf96iEP3okBXO1KqNBNzbFrsJLndHs0JdKdgfbdbnhD9okix1iZYtBhNYZ7kJDCFTPdlOi8QH0Ku5wDM8Ea3xL5J/wfsI7l3pGt2/t+pU8JsWC3DZqzKqAw4apPxZDcK/4Nl3jwvB1mtxxLjj7w+L5JtmAcRxysMSHt8RTHtHRsrSuyN3ZHyfPQBJ1Vjgx5/l+wx/6nmHTMkQKjH2ENZ4mmgJA+yz2uwACuONRFGAV25ecUbT4rvh5BeoUPKWQepTeWBMFG/hUOftl0k6ExC+5UjU53Pbx6hu+fig/w0IDKI+LEKe1tLtByajFJn0em+uFvqj4bmxass1elRC1Fk6n+/unn1ofiZCQDFr74Kxn58uq5ynpMYWKVNSqbLHp1WuPktPDbnlOI+/6gP3GOEn+SBGcBTky12+PpVkwzH9iYXEZYlKSSbtgA1A== X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2178; 31:98We9i6gtSYeOxVRIftPw9CZgsOoNEaQE+ZKzLAKhuq0vD7luDC8igaanycUQhjWYrsLGwn3UvqLDKJIa9ISXAgyCOZ9ZDWoyHqL4XIsEfrb468h1dL3OgS7lJSVWE74rWD9cMEGVXEZ3cCkmeFtaJQ/mqftJebowLTaZYBt3fxC7mA94OgCcU4FpZ3nXRTuoVg085por5lFwfbGy5rYBysaDkP+yOuAltNj9I7fXpI=; 20:CfyyHXxA3wbC9s4J9bqtwPtcDQD6Www6kSYdMx3qhBz5NZ76fSmQ6eQz8531PQTgKAb6j6KSZ/FFqhVOZvUpX/i2+c46rX9z1s2hXL8+hjn8jvM3u2zYwunv2Fq4+X8nAvSjvgQEJbxUBANobdgHkFzXYjC8tCK84b/dFHZvd5NNLbbqaujYpsoHKG1Xgq85BtXYzepllayzy8BQU70GzvaTFkps4/2gdQ5lSNCX/+mL62oaTqUegKigOyYBSVJVPxgBl/q17VjN40fbjiqwrdVpCn5shFiO+NODCA0+PKIyzpP2F//BWyxP4vYf5fjwYTEYq/BU81fUIscJoad8eP7wu0xveRKAcymGlInn9fTw1Ovi09rVrysQvf352SilA0/9QggR9o520AWXVt6FXYDBrn+IZI1EqoKJVpAEP8YjaAVzx6MzPSwslFRtAZsp6XwUkiDY6ID+kjgzVXoEErc/L5c5aLI4aa/VW8ynOXy9RTInZU5oQieqiMH04cgZEQKEYPRlhBmFC0buAm9nD8H6USOnmIqJLxUI8dKivYT9n3fF6hK952BGctAKxKjI30qBuDIhAVst85JbkZM3//FIAyP4EwoYAE0l5+mavgU= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123560025)(20161123558025)(20161123555025)(20161123564025)(6072148); SRVR:BL2PR05MB2178; BCL:0; PCL:0; RULEID:; SRVR:BL2PR05MB2178; X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2178; 4:N7Ir7L3FFa7+HncsGEzqaeWj9jtVfbpTKrS2QJiLr/F72jQfhpxBZ0zcAg2fDi4GYD4jpIiFJPafeNfN7JnmZ+FPdZkRDA5MpNPwOF6W83lE0V2ruZZc0Lb5k//wE9e9wm7tsU+2bITrFSz11bKJ+YW88VgWj7yJJNxnsNgLt9OLtAbBa611/xKLEiz3Z1E4kZp4g+7tCe9Z7qG8ueRmFj79JnwJnG52sYd0FJhfSSMOC3lR9MPVO3bEHEGBd0rtt5krVsqSA6v7rKptaaCC88JBQXAcX/IndE0CXFLn+gK96200nA3QdCxykRiClNV/b9IPY2W1H6a7wVh/EiAxj6gHjXULxa1pknatFu3bdPsh7bAm15Rsy6HCjlZYuXPW+I+tZ3lKPa+ecdOWwUtONneeImMrhiPm6tiAp5ntDSFUy/NIdqtasxqW+KQijFvmqymPKv/sWhqE0ZVDVuKSrq2FNKVxBSEhEGrNGRMMYha8RxFjo7JZ1szMPgwbVMKZQQKjdEPKttrM42TRypI2qK6gNLTz3Tsz8hj68xdEB+IJsoDFXOEi/rLm+ckYmQ0IcPyFZt1Gy/HS/HeJT/OziHRbC/l1r76nkD509Pm8aQX7+E6kFZR4sR2Th1Pkuz80 X-Forefront-PRVS: 02462830BE X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(39450400003)(39840400002)(39860400002)(39850400002)(39410400002)(77096006)(42186005)(36756003)(2906002)(31686004)(86362001)(6486002)(90366009)(31696002)(50466002)(33646002)(229853002)(230783001)(76176999)(54356999)(50986999)(7736002)(81166006)(8676002)(305945005)(38730400002)(23746002)(6246003)(6116002)(65826007)(83506001)(5660300001)(6666003)(53936002)(2950100002)(189998001)(4326008)(230700001)(65956001)(66066001)(47776003)(25786008)(3846002)(163123001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR05MB2178; H:[172.29.33.162]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; BL2PR05MB2178; 23:kpP4DOvUhmON6Vk2pgGtA301xtHlA4thKPMkx?= =?Windows-1252?Q?4pLfQE15NtITRoIf+iXeKohht9lGueX1Guo0SducHzVBVRO/rg10ihvD?= =?Windows-1252?Q?mdyCScq5JReFhGnnWTZddQ/enHHFdKR6ttPxuDgDxrFw4/p/Vm12BHac?= =?Windows-1252?Q?m0afO9zupfFXBmCAUkyNwXk9496dKNgXfq2Es+/8SA4U7JLad/2cDgO2?= =?Windows-1252?Q?B084kySdS1X8/uYdVdmpUr+C7cIM3rQ7pz4FRHaLWZAXEplU9dcFr619?= =?Windows-1252?Q?CJCabst5by0oVynS0LNa8drkcLMuhhFK2yfurz5fMCE0ai3kCMFOdQX9?= =?Windows-1252?Q?5iBvkCLr4LidKc76uACkfiGH3xvnlWCiJgZEYcco/N1XZg9vZf6UiXbx?= =?Windows-1252?Q?XU4ldK+wmOq5SheUC6Bam64HqeAH51KFAEbcmt9yfHMVqvPUcjOvm7dl?= =?Windows-1252?Q?mNeq540csTuAdXjgoCfB+tBcKx58W+6czMD7LKeXFwmgj+cjDJoEDL+r?= =?Windows-1252?Q?sRaLIFiTmcA0N9CC6qR+F58jqtaiKJeB2jYId4+KX6jkHIzBnrncEkyS?= =?Windows-1252?Q?24pcBBe6p3/dnXj2YkLx9wFe/0jPr+XVx3RI1fk9rMjiqQvzt+nnshsK?= =?Windows-1252?Q?cGn/BQsj3rsTfBrDbP18MtHx51qmbbIUjHDXCco1OW9fw3nOV1og6zYF?= =?Windows-1252?Q?fFTeUfUpgQUFRt4ENAwf6e7OVnEW2AW0M/onwOsWu8gnbd4foTJuqQS+?= =?Windows-1252?Q?2hT/sXlspUt25rTu2lyTgsoPgUS4pPU+Bv4h0UhPSrNn/N3h8DsiLKtQ?= =?Windows-1252?Q?fZ/l934vIVbabS88S0UZeCdpaeXH+KQuzRTLNsTZKJOqSD4rSNvkMMRj?= =?Windows-1252?Q?tOTL0H93ppj5myeBXVjrO7hO7dLYoSHDIl7aZIeooCptD6bSe39swwT3?= =?Windows-1252?Q?Lb72o3S4aufFemX3MitT3pRmCh9HO2iU6a8qhExa6OFHelIbEaZTSeTC?= =?Windows-1252?Q?KxLs0xBFtk5IorDVXlESxish4HuPXlgsWuOlHjZeLAtWU6GH0gSR0Tol?= =?Windows-1252?Q?yGUwEshKMREZhSbimTsxNilSZeDhUQ6XpjmsuzjksX4vWgksn1gusNPu?= =?Windows-1252?Q?J86Gr3qqsJ+muogE3/uSNZF2+OEBfYo4yFPqDqS0Gs6pQeIy0XkOxFTd?= =?Windows-1252?Q?rL/8yIIT5Q+mITdTMtYKSPnMlYAbleKrmRXCL5l/JhvuAydqr47Qkcyv?= =?Windows-1252?Q?/IRxbW1OI7DIlaDcA=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2178; 6:v41RWuM0NbKWGJXDHjnoAJ+0EmpP9w7DCvUtgJzVdXCytx4f34S/zQZYHTy511IJCRkCsgYkk4tKp558DzoTL7nsiWUlLTw6oJ4Bv8iMpbqOrH4n4BpkU/6GrgVEJw2WCYOXtW0CB3QOfRiqVW43wuhMNE+4tt0ZsAIuXM/HoNZ5vhdnhSC9PdQZA4x+I47Qp23ttqszhTHlKC/6gVuiaiVYLh/UHVBtZJ6WKHHdBOpTqXCcWgSKE7ncojtK8Pt5UOcxtwXH9ysFhNmCyCXN3s/p2qUJsxXsDzmJsBG6okOuUiu340vK1QBU9aC/G0FymGNR8Hxjlc6yw3cVdBkJsIyFXbZVfLToGlBHhQKGnvQzHiWEnnyHY9JnHMwuQaW4xmnSu5PvZeN+OVIHZgv8TkwSnm05qbkFOJDp1HB02rU=; 5:b6t7IHs12VpX1XHyuG7x5cq69phww1eqDgTGpkQYZ3s+htwpExK4pqo+pBc+xyLFG+ZxUS8aoYx5rbYR0Jl14Jvrny65w0zsDUJ1Qj9jDrjF8WKHF58wXGrnXqobqB2sBHxkJxbGQlB4e4DKIkbNAg==; 24:K1MDmuUtrc9Cxg798ObcxoTJpjPxpDE2HS+ZfPNMOH+4N3jJMX6QV5D3kNIS42oMEb37NPB0ISVkx//zzAYhxtv48kNt3pKCkA+XMYgKSYE= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2178; 7:dV7f2oJDtAQoLdbn22sPNbBodKcIMU/UBsJQN/3FJAM+9KgcScAD+OapzJecuuvR6JKvF61Apz+XVh70qj/kStu+gdaQqj92KLIz3YgUGYfTBji+wBgAe7weEZZzRZeBdOw8zaaE4FYxE2+bHnwpkj+UhXfMQe0jWlGOehUWI07istqBu/NoaBLj3z34JX22cZzVctjciSedyOsYYpcgz9eLPKVB547mg13XGlxHjluVSl/x1lhxOGvRe6Tyxq5lpobtR8jBrJq8e6erOfR4VNdg8wFZaJsH24gbu18TOx5tqpZGXw0rq8ygUlxiTf0IYJnFsSnpBp/4Lr1L61U7bA== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Mar 2017 19:38:15.2606 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR05MB2178 Archived-At: Subject: Re: [Idr] Thoughts on https://www.ietf.org/id/draft-hares-idr-bgp-registries-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 19:38:47 -0000 I don't think we need any more procedural hurdles that will slow down the allocation process or that will introduce more politics into it. The draft does not seem to be a solution to any problem, it just adds process and politics. It claims to have the goal of "increasing the pace of early allocation", and proposes to do this by requiring allocations to be approved by a committee of WG chairs or other designated "experts". It neglects to say how having more committees will increase the pace. No doubt the designated experts will make their decisions "soon", as that term is defined in draft-farrel-soon. Adoption of this draft will result in more squatting rather than less. Furthermore, a number of the mentioned registries were not established by the IDR WG, and I don't see that the IDR WG has any standing to request changes in the registration policies of those registries. From nobody Tue Mar 14 13:31:31 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 620281314B8 for ; Tue, 14 Mar 2017 13:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXA4v3rtef5k for ; Tue, 14 Mar 2017 13:31:28 -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 AE7151293EB for ; Tue, 14 Mar 2017 13:31:27 -0700 (PDT) X-Envelope-To: idr@ietf.org Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id v2EKVOwQ042896 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Mar 2017 20:31:25 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local Message-ID: <58C8531B.2040500@foobar.org> Date: Tue, 14 Mar 2017 20:31:23 +0000 From: Nick Hilliard User-Agent: Postbox 5.0.11 (Macintosh/20170302) MIME-Version: 1.0 To: Robert Raszuk CC: Interminable Discussion Room References: <148924277112.2960.17904473852401253352@ietfa.amsl.com> <58C7D45E.80704@foobar.org> <58C7E860.3010403@foobar.org> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 20:31:29 -0000 Robert Raszuk wrote: > Clearly it requires a bit out of the box perspective ;-) Blue-sky thinking has its place, but we're discussing a tweak of a corner case of an existing well-established system, not a complete core rethink based on ideas which have not been exposed to the realities of production environments. If we could return to discussing this draft, that would be great. Nick From nobody Tue Mar 14 13:34:37 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A478912997C for ; Tue, 14 Mar 2017 13:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-ePnhJ8TBRC for ; Tue, 14 Mar 2017 13:34:33 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98554129993 for ; Tue, 14 Mar 2017 13:34:33 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id y76so257862854qkb.0 for ; Tue, 14 Mar 2017 13:34:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=YaTqqZzPifDgVr2iVjmH3XJEIZ8OS9hREDLnPdafgfw=; b=lKvXzsO+a+O17p70bMYaQG2zg2+fkm+dwMYWNJy/3fn69KUarJjiwjD/JryfSvMmru FYVgmGIc3SEvQrPiFyDnY6pIXom+G05q9sU3jO0+npGxH3gcB9/Oa8o/oTTrLRv+c5eN skRj+Q7YfOnlOMbDX67PFi72AG7ef6uR+R+Z4pQQSs+0ibRlBMcbcd4nYK5QomykZWqD Jxj8IcGnp8vgnJQLZ3fgtjBea7oOsLyPELadJZG5FaRI+jNyPDNOW1SZDBbKPv/shUlE BpquS4EEug/KNcMbv5DmGwYd09l62ertsKRyEftJkx0/gGO/wOB5XEC78UxbtMyOG8JS dKUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=YaTqqZzPifDgVr2iVjmH3XJEIZ8OS9hREDLnPdafgfw=; b=SqLn2GyFqp07cvlupaq82XDENA7lskyxpG3CNaoJ3qmN08hmBxd4l+7SCSTjUVyjG/ nfUABkD5Cbm5mrzvpZ+ONhDNYi1ELLWoaDhnalVVkcEOxztwsKEWKOqN7opLeJiipBNP 32x0fmeFmrXYI3JQ+3qqPmXStn7VZO+c2qR+D9i5+0/cnkNihcrrh4yKNqdtDnNxu8eA CJXxERw/Gw5Ebtd2s5zMozj/9idLs2amdbD6egv5UINlWwPwzvInKXp6xuJnhAsQcA3H aLbbDNPsRNGX4KNiRvCvdlrtwt7EkClTj0ZcHK+9DsA6LUwwJACWwh8KrF8QiXpBsmoz 3RoQ== X-Gm-Message-State: AFeK/H1ZPcTZBJqKt6jL4zBJBqLEZzeD765Mu0dq3YDhqRoeWY1ENio9f6LmI0+16qGpRfSj8eyjCWQd1wpgRw== X-Received: by 10.55.22.66 with SMTP id g63mr37332729qkh.18.1489523672710; Tue, 14 Mar 2017 13:34:32 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.140.42.181 with HTTP; Tue, 14 Mar 2017 13:34:32 -0700 (PDT) In-Reply-To: References: <048701d29cd9$15204b80$3f60e280$@olddog.co.uk> <022201d29ce6$ffb2ba40$ff182ec0$@ndzh.com> From: Robert Raszuk Date: Tue, 14 Mar 2017 21:34:32 +0100 X-Google-Sender-Auth: 10z6PttFxW4YwNLxsrFicalDKec Message-ID: To: Eric C Rosen Cc: Susan Hares , Adrian Farrel , idr wg Content-Type: multipart/alternative; boundary=001a1147734a65924a054ab6c1c9 Archived-At: Subject: Re: [Idr] Thoughts on https://www.ietf.org/id/draft-hares-idr-bgp-registries-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 20:34:36 -0000 --001a1147734a65924a054ab6c1c9 Content-Type: text/plain; charset=UTF-8 I very much agree with Eric here. All what needs to be done to prevent squatting is a public wiki page in IETF (across WGs) with pool of available BGP attribute code points as well as AFI/SAFIs where whoever has a draft and is implementing it ahead of IETF politics takes next available code and links it with a draft name. Then she or he may come to WG with proven implementation at hand. By default considering how fast IETF moves such self registration could be valid for 5 years. After that either the spec is dead and it is ok to free up the code or draft becomes RFC. Submitter can free up the code earlier too. All committees, designated experts, tiger/design teams will just have opposite effect and granted will scare folks who need to implement something for their internal use or for their dedicated customers resulting in much more squatting. Does anyone really believes that if "expert" tells "NO" then the given implementation will get abandoned ? The same should apply to other protocols .. however BGP is the lowest hanging fruit so one could start with that. On Tue, Mar 14, 2017 at 8:38 PM, Eric C Rosen wrote: > I don't think we need any more procedural hurdles that will slow down the > allocation process or that will introduce more politics into it. > > The draft does not seem to be a solution to any problem, it just adds > process and politics. It claims to have the goal of "increasing the pace > of early allocation", and proposes to do this by requiring allocations to > be approved by a committee of WG chairs or other designated "experts". It > neglects to say how having more committees will increase the pace. > > No doubt the designated experts will make their decisions "soon", as that > term is defined in draft-farrel-soon. > > Adoption of this draft will result in more squatting rather than less. > > Furthermore, a number of the mentioned registries were not established by > the IDR WG, and I don't see that the IDR WG has any standing to request > changes in the registration policies of those registries. > > > > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --001a1147734a65924a054ab6c1c9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I very muc= h agree with Eric here.=C2=A0

All what needs to be done to prevent squatting is a public wiki pa= ge in IETF (across WGs) with pool of available BGP attribute code points as= well as AFI/SAFIs where whoever has a draft and is implementing it ahead o= f IETF politics takes next available code and links it with a draft name. T= hen she or he may come to WG with proven implementation at hand.

By default considering how fast = IETF moves such self registration could be valid for 5 years. After that ei= ther the spec is dead and it is ok to free up the code or draft becomes RFC= . Submitter can free up the code earlier too.=C2=A0

All committees, designated experts, tiger/des= ign teams will just have opposite effect and granted will scare folks who n= eed to implement something for their internal use or for their dedicated cu= stomers resulting in much more squatting. Does anyone really believes that = if "expert" tells =C2=A0"NO" then the given implementat= ion will get abandoned ?=C2=A0

The same should apply to other protocols .. however BGP is the low= est hanging fruit so one could start with that.


On Tue, Mar 14, 2017 at 8:38 PM, Eric C Rosen <e= rosen@juniper.net> wrote:
I= don't think we need any more procedural hurdles that will slow down th= e allocation process or that will introduce more politics into it.

The draft does not seem to be a solution to any problem, it just adds proce= ss and politics.=C2=A0 It claims to have the goal of "increasing the p= ace of early allocation", and proposes to do this by requiring allocat= ions to be approved by a committee of WG chairs or other designated "e= xperts".=C2=A0 It neglects to say how having more committees will incr= ease the pace.

No doubt the designated experts will make their decisions "soon",= as that term is defined in draft-farrel-soon.

Adoption of this draft will result in more squatting rather than less.

Furthermore, a number of the mentioned registries were not established by t= he IDR WG, and I don't see that the IDR WG has any standing to request = changes in the registration policies of those registries.






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

--001a1147734a65924a054ab6c1c9-- From nobody Tue Mar 14 13:36:05 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCAE4129993 for ; Tue, 14 Mar 2017 13:36:03 -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=[RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jbj18YFycUS6 for ; Tue, 14 Mar 2017 13:36:02 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED261296B4 for ; Tue, 14 Mar 2017 13:36:02 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id BC4CA1E33B; Tue, 14 Mar 2017 16:42:12 -0400 (EDT) Date: Tue, 14 Mar 2017 16:42:12 -0400 From: Jeffrey Haas To: Robert Raszuk Cc: Nick Hilliard , idr wg Message-ID: <20170314204212.GD12864@pfrc.org> References: <148924277112.2960.17904473852401253352@ietfa.amsl.com> <58C6751D.60306@foobar.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: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 20:36:04 -0000 Robert, I'll let the other comments in this thread stand on their merit. However, I did want to respond to one specific point here: On Mon, Mar 13, 2017 at 11:45:25AM +0100, Robert Raszuk wrote: > I am afraid you have completely missed my point. > > I never said clients must not detect other clients liveness before using it > for best path selection and in their local data planes. > > I said RS does not need to bothered with that information. The relevant bit of procedure within this document to run BFD toward an eBGP nexthop and use it in the local decision process is of potential value even without the RS SAFI part of the protocol. So, in this respect, I agree. The authors had previously discussed extracting this procedure from the document and are fine with doing so if it makes sense. The one "common" use case where this may be of benefit outside of a route-server environment is BGP "VPNs" that are constructed using IPSEC tunnels with the network effectively an NBMA subnet. -- Jeff From nobody Tue Mar 14 13:38:07 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61A4D12951D for ; Tue, 14 Mar 2017 13:38:05 -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=[RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id puMN_rOMR66Y for ; Tue, 14 Mar 2017 13:38:04 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 9AF5012944A for ; Tue, 14 Mar 2017 13:38:04 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 106261E33B; Tue, 14 Mar 2017 16:44:14 -0400 (EDT) Date: Tue, 14 Mar 2017 16:44:14 -0400 From: Jeffrey Haas To: Robert Raszuk Cc: Eric C Rosen , Susan Hares , idr wg Message-ID: <20170314204414.GE12864@pfrc.org> References: <048701d29cd9$15204b80$3f60e280$@olddog.co.uk> <022201d29ce6$ffb2ba40$ff182ec0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Idr] Thoughts on https://www.ietf.org/id/draft-hares-idr-bgp-registries-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 20:38:05 -0000 On Tue, Mar 14, 2017 at 09:34:32PM +0100, Robert Raszuk wrote: > All what needs to be done to prevent squatting is a public wiki page in > IETF (across WGs) with pool of available BGP attribute code points as well > as AFI/SAFIs where whoever has a draft and is implementing it ahead of IETF > politics takes next available code and links it with a draft name. Then she > or he may come to WG with proven implementation at hand. In praise of IANA, their FCFS turnaround is quite fast. They satisfy all of the necessary properties above. No need for wiki here. -- Jeff (otherwise a wiki fan) From nobody Tue Mar 14 13:45:33 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9B7C1314CF for ; Tue, 14 Mar 2017 13:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xJ-xt8t856Y9 for ; Tue, 14 Mar 2017 13:45:30 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::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 551EF1314CD for ; Tue, 14 Mar 2017 13:45:30 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id y76so258092743qkb.0 for ; Tue, 14 Mar 2017 13:45:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=6yK4Jpz0GbKvGZcCHi63uYR9XMDOLpnlpkO2MJZjKY8=; b=edvPCdzU2ncvSwWJSJQZs+i/LiGDIaYfDm3HLztxioLcit/VuZfjQfrZbBNTIX9VoJ FMveOcVrTc+awAxOIx/GjZwfwVZH44F2kLrE8dMwUw242erHwhEMpeavj8Fyy5cCDtRs Xl4QJZ74dB4xqXMttiEgBfgKD4X9isX2xDjzGbzNe+hGbE86v8HI4kew3oUlHcYi4YJT x0CfrvVq0dVAcD+oJEAJtaI7pBV/Kt/gP7lMRfFHVf2J+puugW1u6hgMj0LYbSLZ02+9 h+CJzlBjFV6AimPG4Yr1xbisjDNAQgmAN5F1N0DuwFbvX4SdNJbNHBGc+AtPX1D4vuoi 5Qug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=6yK4Jpz0GbKvGZcCHi63uYR9XMDOLpnlpkO2MJZjKY8=; b=X/QmKYqpSC4WRYo64pGRN9YIivDXNStooyOWGO6hcc+nTEqCTj2UE0wLCMDlxx3BV7 vqQFbw20VGIifsL3t4JU1JpmLnLChjtkl5+BOVq6E92JQtph9wU4fZ0HtNblEek+tzkP ErjkOjz4di5mJPL/Pt1HiLD4acAJvwzaINC8jlkvPnONGURH3puqHKwt3bIlFfi/mda2 V8olnyqkFjv1iy0m9BcbiobYx2JneVW59zCGfE1vL+gqfF+iMs6WqV6smEo6b17P+rzb 4446tMVQdF8rROQ7LZR146gKs0gMZJXCI/WlcsYkRLcJL0ll6Sc5h3tH9Xi/qHKyO/KH GUlA== X-Gm-Message-State: AMke39kjy9BMZSQzd7PO54aDp05v7+cYIGUg8Yr2etb4ig3jV6/jF1xKkv3qNiJHwRG9arN9UnjoYWa4MSxD7A== X-Received: by 10.55.144.4 with SMTP id s4mr37591815qkd.101.1489524329420; Tue, 14 Mar 2017 13:45:29 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.140.42.181 with HTTP; Tue, 14 Mar 2017 13:45:28 -0700 (PDT) In-Reply-To: <20170314204212.GD12864@pfrc.org> References: <148924277112.2960.17904473852401253352@ietfa.amsl.com> <58C6751D.60306@foobar.org> <20170314204212.GD12864@pfrc.org> From: Robert Raszuk Date: Tue, 14 Mar 2017 21:45:28 +0100 X-Google-Sender-Auth: YOliGWvDviqMQN6rwVHwE-U7qjY Message-ID: To: Jeffrey Haas Cc: Nick Hilliard , idr wg Content-Type: multipart/alternative; boundary=94eb2c057a708a247d054ab6e868 Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 20:45:32 -0000 --94eb2c057a708a247d054ab6e868 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =E2=80=8BHi Jeff,=E2=80=8B > I said RS does not need to bothered with that information. > > The relevant bit of procedure within this document to run BFD toward an > eBGP > nexthop and use it in the local decision process is of potential value ev= en > without the RS SAFI part of the protocol. So, in this respect, I agree. > =E2=80=8BCompletely agree ! In fact to me this is basic 4271 as you should not use a path (even single path) if you can not validate if the next hop to it is reachable. I think we all in BGP did not pay that much attention to reachability on multiaccess LANs =E2=80=8Bas most peering happens on p2p links where the sa= me problem does not happen. > The authors had previously discussed extracting this procedure from the > document and are fine with doing so if it makes sense. > Makes sense. It should be done by default one way or another. /* Not sure if BFD considering those "weak customer peering routers" is the best idea. */ The one "common" use case where this may be of benefit outside of a > route-server environment is BGP "VPNs" that are constructed using IPSEC > tunnels with the network effectively an NBMA subnet. > =E2=80=8BSee all SD-WANs today need more then one path such that they make forwarding decision by probing all alternative overlay links and based on the applied logic switch over to better or lower cost or less delay path. If you give them just single path this is all no longer possible. That is what worries me in this the most if you would like to utlize this new NH NOTIFCATION SAFI for WAN VPNs. =E2=80=8BThx, R.=E2=80=8B --94eb2c057a708a247d054ab6e868 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=E2=80=8BHi Jeff,=E2=80=8B

> I said RS does not need to bothered= with that information.

The relevant bit of procedure within this document to run BFD toward= an eBGP
nexthop and use it in the local decision process is of potential value even=
without the RS SAFI part of the protocol.=C2=A0 So, in this respect, I agre= e.

=E2=80=8BComple= tely agree !=C2=A0

In = fact to me this is basic 4271 as you should not use a path (even single pat= h) if you can not validate if the next hop to it is reachable.=C2=A0
<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ;font-size:small">
I think we all in BGP did no= t pay that much attention to reachability on multiaccess LANs =E2=80=8Bas m= ost peering happens on p2p links where the same problem does not happen.=C2= =A0

=C2=A0
The authors had previously discussed extracting this procedure from the<= br> document and are fine with doing so if it makes sense.

Makes sense. It should be done by defaul= t one way or another. /* Not sure if BFD considering those "weak custo= mer peering routers" is the best idea. */
=C2=A0
=

The one "common" us= e case where this may be of benefit outside of a
route-server environment is BGP "VPNs" that are constructed using= IPSEC
tunnels with the network effectively an NBMA subnet.
<= br>
=E2=80=8BSee all SD-WANs today need more t= hen one path such that they make forwarding decision by probing all alterna= tive overlay links and based on the applied logic switch over to better or = lower cost or less delay path. If you give them just single path this is al= l no longer possible. That is what worries me in this the most if you would= like to utlize this new NH NOTIFCATION SAFI for WAN VPNs.=C2=A0

<= /div>
=E2=80=8BThx,
R.=E2=80=8B


=C2=A0
--94eb2c057a708a247d054ab6e868-- From nobody Tue Mar 14 13:48:19 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 653981314E0 for ; Tue, 14 Mar 2017 13:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LncSNLZkNJoo for ; Tue, 14 Mar 2017 13:48:12 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::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 328C21314DD for ; Tue, 14 Mar 2017 13:48:12 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id i34so65527454qtc.0 for ; Tue, 14 Mar 2017 13:48:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=aSwOop25uJVYAjyExfHxifX3fMGKRRXsSaCZpT+jOG0=; b=Wux5blx58/gccJY/DYhtAhpLqBqfAaOvt+6vqo6mf6tt91r3h8VcJQOCa4WH7iQtXN ilUP3DUwAuOz6+fOcE70rLgE+WNnRfAVtjPoT+s5su//AV68pyf9TZc463JlEam+kg03 po7HvWBOgvlWraDn3WaRHxNfL0cQQvYoMHTdWCLT+b9SKSLySmdc6qLCEJnQkaGx8LVs 7jN0RQlFo1ftcXT/XhiRfLshF3gQxEtBJtpFC+f2jQSgiL1HL/+l6ILuaCiAvM51JKsE TKM7sZn4YFOo+nzuagv2Objwh/XLiWK0LyJEHiTRPN8oaARu8p32oEnHVfPO7+Fwvh7Y lpWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=aSwOop25uJVYAjyExfHxifX3fMGKRRXsSaCZpT+jOG0=; b=HavqRRePaMmqi9/XXqOTEsIlvW+M0BxaDzF38Jwif50gBLX31Hyzpyzxruw400yC9W z7M+6eal2BcjyzTr5rnd4OItxhosKLa7G1TeIZYUSTLy8QmuY3PVWReTStdxuJ5314Gi 8wztttyGiOQ2Xh7Vqh8LryvSq9oV8mL8VpeHv2jF4PsMnEcIsBznbq5djzOl8/4tVvZl G0tOFZ7onZF5Qx8bwBoSdTtDTgp8E8qmMGpXLY0xJfbil0sjOFiy/NQmAyJlrJKaxhz4 p0LLfHRf+eOca5j5YEgdtXoAzAFY2Iq8NtQpL5S8fyRG2j9ET+eCvMf+bTcEEd5qjarM 5arQ== X-Gm-Message-State: AMke39k9+5zFWOuJE/AfDXWnWnb87Dku3HcNz6D1xADbDFXtGgjHGz5OeG7pIOmrLr/ojTQnYxeJaDbnOhmsaQ== X-Received: by 10.200.0.25 with SMTP id a25mr37487764qtg.199.1489524491285; Tue, 14 Mar 2017 13:48:11 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.140.42.181 with HTTP; Tue, 14 Mar 2017 13:48:10 -0700 (PDT) In-Reply-To: <20170314204414.GE12864@pfrc.org> References: <048701d29cd9$15204b80$3f60e280$@olddog.co.uk> <022201d29ce6$ffb2ba40$ff182ec0$@ndzh.com> <20170314204414.GE12864@pfrc.org> From: Robert Raszuk Date: Tue, 14 Mar 2017 21:48:10 +0100 X-Google-Sender-Auth: DXT6QsKTK1ueC7ZEDPGWLDTz8OY Message-ID: To: Jeffrey Haas Cc: Eric C Rosen , Susan Hares , idr wg Content-Type: multipart/alternative; boundary=f403045e73622ffe41054ab6f2e1 Archived-At: Subject: Re: [Idr] Thoughts on https://www.ietf.org/id/draft-hares-idr-bgp-registries-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 20:48:13 -0000 --f403045e73622ffe41054ab6f2e1 Content-Type: text/plain; charset=UTF-8 It's not that IANA is slow ... it's the process that get's you to IANA is a bottleneck. Can anyone submits a draft to IANA to get code point without any IETF sponsorship ? On Tue, Mar 14, 2017 at 9:44 PM, Jeffrey Haas wrote: > On Tue, Mar 14, 2017 at 09:34:32PM +0100, Robert Raszuk wrote: > > All what needs to be done to prevent squatting is a public wiki page in > > IETF (across WGs) with pool of available BGP attribute code points as > well > > as AFI/SAFIs where whoever has a draft and is implementing it ahead of > IETF > > politics takes next available code and links it with a draft name. Then > she > > or he may come to WG with proven implementation at hand. > > In praise of IANA, their FCFS turnaround is quite fast. They satisfy all > of > the necessary properties above. > > No need for wiki here. > > > -- Jeff (otherwise a wiki fan) > --f403045e73622ffe41054ab6f2e1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

It's n= ot that IANA is slow ... it's the process that get's you to IANA is= a bottleneck.=C2=A0

C= an anyone submits a draft to IANA to get code point without any IETF sponso= rship ?=C2=A0



On Tue, M= ar 14, 2017 at 9:44 PM, Jeffrey Haas <jhaas@pfrc.org> wrote:
On Tue, Mar 14, 2017 at 09= :34:32PM +0100, Robert Raszuk wrote:
> All what needs to be done to prevent squatting is a public wiki page i= n
> IETF (across WGs) with pool of available BGP attribute code points as = well
> as AFI/SAFIs where whoever has a draft and is implementing it ahead of= IETF
> politics takes next available code and links it with a draft name. The= n she
> or he may come to WG with proven implementation at hand.

In praise of IANA, their FCFS turnaround is quite fast.=C2=A0 They s= atisfy all of
the necessary properties above.

No need for wiki here.


-- Jeff (otherwise a wiki fan)

--f403045e73622ffe41054ab6f2e1-- From nobody Tue Mar 14 13:56:59 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A0851314FA for ; Tue, 14 Mar 2017 13:56:57 -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=[RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LSCXfTnI4YWF for ; Tue, 14 Mar 2017 13:56:55 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id CDC4A129B0D for ; Tue, 14 Mar 2017 13:56:55 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 39DAA1E33B; Tue, 14 Mar 2017 17:03:06 -0400 (EDT) Date: Tue, 14 Mar 2017 17:03:05 -0400 From: Jeffrey Haas To: Robert Raszuk Cc: Eric C Rosen , Susan Hares , idr wg Message-ID: <20170314210305.GF12864@pfrc.org> References: <048701d29cd9$15204b80$3f60e280$@olddog.co.uk> <022201d29ce6$ffb2ba40$ff182ec0$@ndzh.com> <20170314204414.GE12864@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: Subject: Re: [Idr] Thoughts on https://www.ietf.org/id/draft-hares-idr-bgp-registries-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 20:56:57 -0000 On Tue, Mar 14, 2017 at 09:48:10PM +0100, Robert Raszuk wrote: > It's not that IANA is slow ... it's the process that get's you to IANA is a > bottleneck. > > Can anyone submits a draft to IANA to get code point without any IETF > sponsorship ? FCFS is FCFS. If you wanted to submit a draft-raszuk-waste-extcomm-code-point, you could likely prove this, but I suspect IANA wouldn't be happy and would at least press you "um, this doesn't look like it's going to be around long...." -- Jeff From nobody Tue Mar 14 13:59:48 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71CFF129B0D for ; Tue, 14 Mar 2017 13:59:46 -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=[RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UE1_-xvfjgNS for ; Tue, 14 Mar 2017 13:59:45 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id A1EF1129B11 for ; Tue, 14 Mar 2017 13:59:45 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 30A531E33B; Tue, 14 Mar 2017 17:05:56 -0400 (EDT) Date: Tue, 14 Mar 2017 17:05:56 -0400 From: Jeffrey Haas To: Robert Raszuk Cc: Nick Hilliard , idr wg Message-ID: <20170314210555.GG12864@pfrc.org> References: <58C6751D.60306@foobar.org> <20170314204212.GD12864@pfrc.org> 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.21 (2010-09-15) Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 20:59:46 -0000 On Tue, Mar 14, 2017 at 09:45:28PM +0100, Robert Raszuk wrote: > In fact to me this is basic 4271 as you should not use a path (even single > path) if you can not validate if the next hop to it is reachable. > > I think we all in BGP did not pay that much attention to reachability on > multiaccess LANs ​as most peering happens on p2p links where the same > problem does not happen. For first party nexthops, BGP timers can address this to some extent. BGP timers are too long, hence BFD. For third party nexthops, you can have persistant bad forwarding. Normal BGP procedure doesn't help you here. So, we agree that the case isn't given good attention in the core specs. > > The one "common" use case where this may be of benefit outside of a > > route-server environment is BGP "VPNs" that are constructed using IPSEC > > tunnels with the network effectively an NBMA subnet. > > > > ​See all SD-WANs today need more then one path such that they make > forwarding decision by probing all alternative overlay links and based on > the applied logic switch over to better or lower cost or less delay path. > If you give them just single path this is all no longer possible. That is > what worries me in this the most if you would like to utlize this new NH > NOTIFCATION SAFI for WAN VPNs. The new SAFI is targeted specifically for the RS case and hasn't received specific consideration for other use cases yet. Feel free to kick off that as a topic, although I'd suggest doing so separably from the rs-bfd thread. -- Jeff From nobody Tue Mar 14 14:08:42 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CFA9131535 for ; Tue, 14 Mar 2017 14:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.623 X-Spam-Level: X-Spam-Status: No, score=-12.623 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5L9UUwQgJZ4x for ; Tue, 14 Mar 2017 14:08:37 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEBF6129B33 for ; Tue, 14 Mar 2017 14:08:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3272; q=dns/txt; s=iport; t=1489525717; x=1490735317; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=uGPNSBwR7xBm0pMT4Y06gKdr8bSPpTF5hXZcU+RW6cs=; b=YI1UPibpmR+DT88YeTrcHRRlRMXpMpZhuJIn8Frkr+8ii9gfOeRnOjHp Tw29RS+ZBBDUTIWF0oeTqGTA88HrPnOhyKBsezYAotu2nZYU+lQSKvs7B yp1sxulxOGE6ZNww8A7Ssoh0q0rGLi3cQxYVxyRanpWNWka5DJVvHujbK E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CBAgCQW8hY/5hdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgycqYYEKB4NZig2RNh+VPIIOHw2FdgIagj4/GAECAQEBAQEBAWs?= =?us-ascii?q?ohRUBAQEBAwEBIRE6CwwEAgEIDgMDAQIBAgImAgICJQsVCAgCBAENBYoADq1cg?= =?us-ascii?q?iaKXQEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgQuFQ4IFCIJihDAOFoMGLoIxBYk?= =?us-ascii?q?UiBKLHQGGdYtFkSWTRgEfOIEEWBVBEQGERR2BY3WGdYEwgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.36,165,1486425600"; d="scan'208";a="218540624" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Mar 2017 21:08:25 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v2EL8Pvs000841 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 14 Mar 2017 21:08:25 GMT Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 14 Mar 2017 16:08:25 -0500 Received: from xch-aln-005.cisco.com ([173.36.7.15]) by XCH-ALN-005.cisco.com ([173.36.7.15]) with mapi id 15.00.1210.000; Tue, 14 Mar 2017 16:08:24 -0500 From: "Rajiv Asati (rajiva)" To: Jeffrey Haas , Robert Raszuk CC: idr wg Thread-Topic: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt Thread-Index: AQHSmnRjZQMhW6yq5kum3Hd4lOeZoKGSjLmAgABQ7oCAAAtWgP//sAtXgAKMygD//8REAA== Date: Tue, 14 Mar 2017 21:08:24 +0000 Message-ID: <815723FC-B143-4410-B0FF-D9FB4F827862@cisco.com> References: <148924277112.2960.17904473852401253352@ietfa.amsl.com> <58C6751D.60306@foobar.org> <20170314204212.GD12864@pfrc.org> In-Reply-To: <20170314204212.GD12864@pfrc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.18.255.108] Content-Type: text/plain; charset="utf-8" Content-ID: <9F2E36E02C61A34EA724B1B2E3984BB2@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 21:08:39 -0000 SmVmZiwgDQoNCklzIHRoZSBhc3N1bXB0aW9uIGhlcmUgdGhhdCB0aGUgY2xpZW50IHJvdXRlcnMg aGF2ZSByb3V0aW5nIHZpZXcgbGltaXRlZCB0byB3aGF04oCZcyBwcm92aWRlZCBieSB0aGUgUm91 dGUgU2VydmVyPyBJZiBub3QsIHRoZW4gd291bGRu4oCZdCBDbGllbnQgUm91dGVycyBiZW5lZml0 IGZyb20gaGF2aW5nIHRvIGludmFsaWRhdGUgdGhlIHBhdGggbGVhcm5lZCBmcm9tIHRoZSByZW1v dGUgY2xpZW50IHJvdXRlciBhcyBzb29uIGFzIHRoZSBjb25uZWN0aXZpdHkgY2hlY2sgZmFpbGVk Pw0KDQpPZiBjb3Vyc2UsIENsaWVudCBSb3V0ZXJzIGNvbnZleWluZyB0aGUgbGFjayBvZiBOTFJJ IHJlYWNoYWJpbGl0eSBwZXIgTkggdG8gdGhlIFJvdXRlIFNlcnZlciwgYW5kIGV4cGVjdGluZyBS b3V0ZSBTZXJ2ZXIgdG8gcHJvdmlkZSBhIGRpZmZlcmVudCBOSHMgb2YgdGhlIE5MUklzLCBhbmQg ZXhwZWN0aW5nIGl0IHRvIGJlIGZ1bmN0aW9uYWwsIHdoaWxlIHN0aWxsIGF0dHJhY3RpbmcgdGhl IHRyYWZmaWMgZm9yIHVucmVhY2hhYmxlIGRlc3RpbmF0aW9ucyBzaW5jZSB0aGUgTG9jLVJJQiBp cyBzdGlsbCBwb2ludGluZyB0byB0aGUgdW5yZWFjaGFibGUgTkggZm9yIHRoZSBhZmZlY3RlZCBO TFJJcy4NCg0KSSB3b25kZXIgd2hldGhlciAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtaWRyLWJncC1iZXN0cGF0aC1zZWxlY3Rpb24tY3JpdGVyaWEgYmUgdXNlZnVsIGhl cmUuDQoNCi0tIA0KQ2hlZXJzLA0KUmFqaXYgQXNhdGkNCkRpc3Rpbmd1aXNoZWQgRW5naW5lZXIs IENpc2NvDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBJZHIgPGlkci1ib3Vu Y2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgSmVmZnJleSBIYWFzIDxqaGFhc0BwZnJjLm9yZz4N CkRhdGU6IFR1ZXNkYXksIE1hcmNoIDE0LCAyMDE3IGF0IDQ6NDIgUE0NClRvOiAicm9iZXJ0QHJh c3p1ay5uZXQiIDxyb2JlcnRAcmFzenVrLm5ldD4NCkNjOiAiaWRyQGlldGYub3JnIiA8aWRyQGll dGYub3JnPg0KU3ViamVjdDogUmU6IFtJZHJdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtaWRyLXJz LWJmZC0wMi50eHQNCg0KICAgIFJvYmVydCwNCiAgICANCiAgICBJJ2xsIGxldCB0aGUgb3RoZXIg Y29tbWVudHMgaW4gdGhpcyB0aHJlYWQgc3RhbmQgb24gdGhlaXIgbWVyaXQuICBIb3dldmVyLCBJ DQogICAgZGlkIHdhbnQgdG8gcmVzcG9uZCB0byBvbmUgc3BlY2lmaWMgcG9pbnQgaGVyZToNCiAg ICANCiAgICBPbiBNb24sIE1hciAxMywgMjAxNyBhdCAxMTo0NToyNUFNICswMTAwLCBSb2JlcnQg UmFzenVrIHdyb3RlOg0KICAgID4gSSBhbSBhZnJhaWQgeW91IGhhdmUgY29tcGxldGVseSBtaXNz ZWQgbXkgcG9pbnQuDQogICAgPiANCiAgICA+IEkgbmV2ZXIgc2FpZCBjbGllbnRzIG11c3Qgbm90 IGRldGVjdCBvdGhlciBjbGllbnRzIGxpdmVuZXNzIGJlZm9yZSB1c2luZyBpdA0KICAgID4gZm9y IGJlc3QgcGF0aCBzZWxlY3Rpb24gYW5kIGluIHRoZWlyIGxvY2FsIGRhdGEgcGxhbmVzLg0KICAg ID4gDQogICAgPiBJIHNhaWQgUlMgZG9lcyBub3QgbmVlZCB0byBib3RoZXJlZCB3aXRoIHRoYXQg aW5mb3JtYXRpb24uDQogICAgDQogICAgVGhlIHJlbGV2YW50IGJpdCBvZiBwcm9jZWR1cmUgd2l0 aGluIHRoaXMgZG9jdW1lbnQgdG8gcnVuIEJGRCB0b3dhcmQgYW4gZUJHUA0KICAgIG5leHRob3Ag YW5kIHVzZSBpdCBpbiB0aGUgbG9jYWwgZGVjaXNpb24gcHJvY2VzcyBpcyBvZiBwb3RlbnRpYWwg dmFsdWUgZXZlbg0KICAgIHdpdGhvdXQgdGhlIFJTIFNBRkkgcGFydCBvZiB0aGUgcHJvdG9jb2wu ICBTbywgaW4gdGhpcyByZXNwZWN0LCBJIGFncmVlLg0KICAgIA0KICAgIFRoZSBhdXRob3JzIGhh ZCBwcmV2aW91c2x5IGRpc2N1c3NlZCBleHRyYWN0aW5nIHRoaXMgcHJvY2VkdXJlIGZyb20gdGhl DQogICAgZG9jdW1lbnQgYW5kIGFyZSBmaW5lIHdpdGggZG9pbmcgc28gaWYgaXQgbWFrZXMgc2Vu c2UuDQogICAgDQogICAgVGhlIG9uZSAiY29tbW9uIiB1c2UgY2FzZSB3aGVyZSB0aGlzIG1heSBi ZSBvZiBiZW5lZml0IG91dHNpZGUgb2YgYQ0KICAgIHJvdXRlLXNlcnZlciBlbnZpcm9ubWVudCBp cyBCR1AgIlZQTnMiIHRoYXQgYXJlIGNvbnN0cnVjdGVkIHVzaW5nIElQU0VDDQogICAgdHVubmVs cyB3aXRoIHRoZSBuZXR3b3JrIGVmZmVjdGl2ZWx5IGFuIE5CTUEgc3VibmV0LiAgDQogICAgDQog ICAgLS0gSmVmZg0KICAgIA0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQogICAgSWRyIG1haWxpbmcgbGlzdA0KICAgIElkckBpZXRmLm9yZw0KICAg IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRyDQogICAgDQoNCg== From nobody Tue Mar 14 14:11:25 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDE5513153A for ; Tue, 14 Mar 2017 14:11:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.623 X-Spam-Level: X-Spam-Status: No, score=-12.623 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id psu5YOL-8lvJ for ; Tue, 14 Mar 2017 14:11:22 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 244F7131547 for ; Tue, 14 Mar 2017 14:11:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3438; q=dns/txt; s=iport; t=1489525882; x=1490735482; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=WyPgAFGQUBALJHsNj633KfZfCXkUp3l+tI/NowCP87U=; b=FEARQ13eyFpwIEA2noOI3Jky2416uLJVZJbf/VU+BwUIsfo+wTfMB3V4 3Mjjmz70aR1cCoLXSghjgsv71ZlWcgR5moZDOikLnJXpSTWXBNI1nfwg8 35nOeWlz+eGlpVr5VSoPal8h6C3y4IdbuE/rO4RvV7nkDJv+7ZSEg/bdl 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CjAQBUW8hY/5NdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1FhgQoHg1mKDZFVlTyCDh8NhXYCGoI+PxgBAgEBAQEBAQFrKIU?= =?us-ascii?q?VAQEBAQIBAQEhEToLBQcEAgEIDgMDAQIBAgImAgICJQsVCAgCBAENBYl4CA6tX?= =?us-ascii?q?IImil0BAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYELhUOCBYJqhD6DHC6CMQWGaZV?= =?us-ascii?q?aAYZ1hk2EeJElk0YBHziBBFgVQREBhEUdgWN1hncrgQOBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.36,165,1486425600"; d="scan'208";a="218547241" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Mar 2017 21:11:21 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v2ELBLZk017045 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 14 Mar 2017 21:11:21 GMT Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 14 Mar 2017 16:11:20 -0500 Received: from xch-aln-005.cisco.com ([173.36.7.15]) by XCH-ALN-005.cisco.com ([173.36.7.15]) with mapi id 15.00.1210.000; Tue, 14 Mar 2017 16:11:20 -0500 From: "Rajiv Asati (rajiva)" To: Jeffrey Haas , Robert Raszuk CC: idr wg Thread-Topic: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt Thread-Index: AQHSmnRjZQMhW6yq5kum3Hd4lOeZoKGSjLmAgABQ7oCAAAtWgP//sAtXgAKMygCAAADqAIAABbgA//++dAA= Date: Tue, 14 Mar 2017 21:11:20 +0000 Message-ID: References: <58C6751D.60306@foobar.org> <20170314204212.GD12864@pfrc.org> <20170314210555.GG12864@pfrc.org> In-Reply-To: <20170314210555.GG12864@pfrc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.18.255.108] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 21:11:24 -0000 PiAgICBGb3IgdGhpcmQgcGFydHkgbmV4dGhvcHMsIHlvdSBjYW4gaGF2ZSBwZXJzaXN0YW50IGJh ZCBmb3J3YXJkaW5nLiAgTm9ybWFsDQo+ICAgQkdQIHByb2NlZHVyZSBkb2Vzbid0IGhlbHAgeW91 IGhlcmUuDQoNCkFncmVlZC4gVW5sZXNzIEJHUCBiZXN0cGF0aCBzZWxlY3Rpb24gY29uc2lkZXJz IChldmVudC1kcml2ZW4pIE5IIGxpdmVsaW5lc3MgY2hlY2ssIHRoZSBibGFja2hvbGluZyBwcm9i bGVtIHdvdWxkIGNvbnRpbnVlLg0KDQoNCi0tIA0KQ2hlZXJzLA0KUmFqaXYgDQoNCmh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWlkci1iZ3AtYmVzdHBhdGgtc2VsZWN0aW9u LWNyaXRlcmlhLTA2DQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IElkciA8 aWRyLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBKZWZmcmV5IEhhYXMgPGpoYWFzQHBm cmMub3JnPg0KRGF0ZTogVHVlc2RheSwgTWFyY2ggMTQsIDIwMTcgYXQgNTowNSBQTQ0KVG86ICJy b2JlcnRAcmFzenVrLm5ldCIgPHJvYmVydEByYXN6dWsubmV0Pg0KQ2M6ICJpZHJAaWV0Zi5vcmci IDxpZHJAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0lkcl0gSS1EIEFjdGlvbjogZHJhZnQtaWV0 Zi1pZHItcnMtYmZkLTAyLnR4dA0KDQogICAgT24gVHVlLCBNYXIgMTQsIDIwMTcgYXQgMDk6NDU6 MjhQTSArMDEwMCwgUm9iZXJ0IFJhc3p1ayB3cm90ZToNCiAgICA+IEluIGZhY3QgdG8gbWUgdGhp cyBpcyBiYXNpYyA0MjcxIGFzIHlvdSBzaG91bGQgbm90IHVzZSBhIHBhdGggKGV2ZW4gc2luZ2xl DQogICAgPiBwYXRoKSBpZiB5b3UgY2FuIG5vdCB2YWxpZGF0ZSBpZiB0aGUgbmV4dCBob3AgdG8g aXQgaXMgcmVhY2hhYmxlLg0KICAgID4gDQogICAgPiBJIHRoaW5rIHdlIGFsbCBpbiBCR1AgZGlk IG5vdCBwYXkgdGhhdCBtdWNoIGF0dGVudGlvbiB0byByZWFjaGFiaWxpdHkgb24NCiAgICA+IG11 bHRpYWNjZXNzIExBTnMg4oCLYXMgbW9zdCBwZWVyaW5nIGhhcHBlbnMgb24gcDJwIGxpbmtzIHdo ZXJlIHRoZSBzYW1lDQogICAgPiBwcm9ibGVtIGRvZXMgbm90IGhhcHBlbi4NCiAgICANCiAgICBG b3IgZmlyc3QgcGFydHkgbmV4dGhvcHMsIEJHUCB0aW1lcnMgY2FuIGFkZHJlc3MgdGhpcyB0byBz b21lIGV4dGVudC4NCiAgICANCiAgICBCR1AgdGltZXJzIGFyZSB0b28gbG9uZywgaGVuY2UgQkZE Lg0KICAgIA0KICAgIEZvciB0aGlyZCBwYXJ0eSBuZXh0aG9wcywgeW91IGNhbiBoYXZlIHBlcnNp c3RhbnQgYmFkIGZvcndhcmRpbmcuICBOb3JtYWwNCiAgICBCR1AgcHJvY2VkdXJlIGRvZXNuJ3Qg aGVscCB5b3UgaGVyZS4NCiAgICANCiAgICBTbywgd2UgYWdyZWUgdGhhdCB0aGUgY2FzZSBpc24n dCBnaXZlbiBnb29kIGF0dGVudGlvbiBpbiB0aGUgY29yZSBzcGVjcy4NCiAgICANCiAgICA+ID4g VGhlIG9uZSAiY29tbW9uIiB1c2UgY2FzZSB3aGVyZSB0aGlzIG1heSBiZSBvZiBiZW5lZml0IG91 dHNpZGUgb2YgYQ0KICAgID4gPiByb3V0ZS1zZXJ2ZXIgZW52aXJvbm1lbnQgaXMgQkdQICJWUE5z IiB0aGF0IGFyZSBjb25zdHJ1Y3RlZCB1c2luZyBJUFNFQw0KICAgID4gPiB0dW5uZWxzIHdpdGgg dGhlIG5ldHdvcmsgZWZmZWN0aXZlbHkgYW4gTkJNQSBzdWJuZXQuDQogICAgPiA+DQogICAgPiAN CiAgICA+IOKAi1NlZSBhbGwgU0QtV0FOcyB0b2RheSBuZWVkIG1vcmUgdGhlbiBvbmUgcGF0aCBz dWNoIHRoYXQgdGhleSBtYWtlDQogICAgPiBmb3J3YXJkaW5nIGRlY2lzaW9uIGJ5IHByb2Jpbmcg YWxsIGFsdGVybmF0aXZlIG92ZXJsYXkgbGlua3MgYW5kIGJhc2VkIG9uDQogICAgPiB0aGUgYXBw bGllZCBsb2dpYyBzd2l0Y2ggb3ZlciB0byBiZXR0ZXIgb3IgbG93ZXIgY29zdCBvciBsZXNzIGRl bGF5IHBhdGguDQogICAgPiBJZiB5b3UgZ2l2ZSB0aGVtIGp1c3Qgc2luZ2xlIHBhdGggdGhpcyBp cyBhbGwgbm8gbG9uZ2VyIHBvc3NpYmxlLiBUaGF0IGlzDQogICAgPiB3aGF0IHdvcnJpZXMgbWUg aW4gdGhpcyB0aGUgbW9zdCBpZiB5b3Ugd291bGQgbGlrZSB0byB1dGxpemUgdGhpcyBuZXcgTkgN CiAgICA+IE5PVElGQ0FUSU9OIFNBRkkgZm9yIFdBTiBWUE5zLg0KICAgIA0KICAgIFRoZSBuZXcg U0FGSSBpcyB0YXJnZXRlZCBzcGVjaWZpY2FsbHkgZm9yIHRoZSBSUyBjYXNlIGFuZCBoYXNuJ3Qg cmVjZWl2ZWQNCiAgICBzcGVjaWZpYyBjb25zaWRlcmF0aW9uIGZvciBvdGhlciB1c2UgY2FzZXMg eWV0LiAgRmVlbCBmcmVlIHRvIGtpY2sgb2ZmIHRoYXQNCiAgICBhcyBhIHRvcGljLCBhbHRob3Vn aCBJJ2Qgc3VnZ2VzdCBkb2luZyBzbyBzZXBhcmFibHkgZnJvbSB0aGUgcnMtYmZkIHRocmVhZC4N CiAgICANCiAgICAtLSBKZWZmDQogICAgDQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCiAgICBJZHIgbWFpbGluZyBsaXN0DQogICAgSWRyQGlldGYu b3JnDQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZHINCiAgICAN Cg0K From nobody Tue Mar 14 14:21:26 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DE5F13155B for ; Tue, 14 Mar 2017 14:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C74xNkhYIe0n for ; Tue, 14 Mar 2017 14:21:23 -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 2F967131555 for ; Tue, 14 Mar 2017 14:21:22 -0700 (PDT) X-Envelope-To: Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id v2ELLKQr049104 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 14 Mar 2017 21:21:20 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local Message-ID: <58C85ECE.3080109@foobar.org> Date: Tue, 14 Mar 2017 21:21:18 +0000 From: Nick Hilliard User-Agent: Postbox 5.0.11 (Macintosh/20170302) MIME-Version: 1.0 To: IETF IDR Working Group References: <148924277112.2960.17904473852401253352@ietfa.amsl.com> In-Reply-To: <148924277112.2960.17904473852401253352@ietfa.amsl.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 21:21:25 -0000 the text states: > 5.1. Route Server Client Procedures for NHIB Changes > > When entries are added to the a route server client's Adj-NHIB-In for > a route server peering session, it will then attempt to verify > connectivity to the BGP nexthop for that entry. The procedure > described in this specification utilizes BFD; other mechanisms are > permitted but are out of scope of this document. It might be an idea to explicitly acknowledge that some clients may want to selectively filter out NHIB on the basis that they don't want to establish bfd sessions to those particular NHs. There could be many reasons for this, e.g. reliability of bfd on the remote side, reliability of bfd on the local side. This would require some selection mechanism to be implemented on the client. A couple of other things: 1. if a route server client stops announcing prefixes to the route server but still accepts prefixes, do all bfd sessions to it also get torn down? Or is the purpose of the RS Adj-NHIB-In to ensure stickiness of bfd sessions? If this is the case, it should be mentioned explicitly because otherwise the feedback loop looks ... well, a bit peculiar. 2. > It is incorrect provisioning for an IXP client which > is using a Route Server to have a BGP session with another IXP > client. lolno, if I'm reading this correctly. It's quite usual to have bilateral + multilateral sessions configuration between router pairs. Nick From nobody Tue Mar 14 14:30:04 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 536D6129B50 for ; Tue, 14 Mar 2017 14:29:58 -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=[RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Se8K2211sGK5 for ; Tue, 14 Mar 2017 14:29:57 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 29857129AD0 for ; Tue, 14 Mar 2017 14:29:57 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 959761E33B; Tue, 14 Mar 2017 17:36:07 -0400 (EDT) Date: Tue, 14 Mar 2017 17:36:07 -0400 From: Jeffrey Haas To: "Rajiv Asati (rajiva)" Cc: Robert Raszuk , idr wg Message-ID: <20170314213607.GH12864@pfrc.org> References: <58C6751D.60306@foobar.org> <20170314204212.GD12864@pfrc.org> <815723FC-B143-4410-B0FF-D9FB4F827862@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <815723FC-B143-4410-B0FF-D9FB4F827862@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 21:29:58 -0000 Rajiv, On Tue, Mar 14, 2017 at 09:08:24PM +0000, Rajiv Asati (rajiva) wrote: > Is the assumption here that the client routers have routing view limited to what’s provided by the Route Server? If not, then wouldn’t Client Routers benefit from having to invalidate the path learned from the remote client router as soon as the connectivity check failed? This is what I believe the procedure says. See section 6. > Of course, Client Routers conveying the lack of NLRI reachability per NH to the Route Server, and expecting Route Server to provide a different NHs of the NLRIs, and expecting it to be functional, while still attracting the traffic for unreachable destinations since the Loc-RIB is still pointing to the unreachable NH for the affected NLRIs. The thing that is somewhat different for a IXP environment running a route server than normal eBGP is the low (to zero) likelihood of having a backup path. If 10/8 was learned from the route server for nexthop 192.0.2.1, and you stop being able to reach that nexthop, removing it from your forwarding (unreachable) is your only choice. You *might* have a source of that path internally. In that case, you can use it. But more importantly, you'll stop sending it toward your own peering and attracting blackholed traffic. > I wonder whether https://tools.ietf.org/html/draft-ietf-idr-bgp-bestpath-selection-criteria be useful here. In a sense of good timing, John Scudder had brought this to my attention about an hour ago. RS-BFD basically reinvents the same procedure in your draft, simply being specific about the use of BFD as the dataplane liveness check mechanism. However, as you note in the RS-BFD draft, we do leave the option for other mechanisms. I suspect the other authors of RS-BFD aren't particular where we pick up our text for the resolvability condition. However, if the suggestion is to make a reference to your draft, you'll need to bring it back from zombie state and progress it. :-) -- Jeff From nobody Tue Mar 14 14:42:10 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66B7A1293F4 for ; Tue, 14 Mar 2017 14:42:08 -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=[RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mx92USqFbjfJ for ; Tue, 14 Mar 2017 14:42:07 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF1F126FDC for ; Tue, 14 Mar 2017 14:42:07 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 8F5E61E33B; Tue, 14 Mar 2017 17:48:17 -0400 (EDT) Date: Tue, 14 Mar 2017 17:48:17 -0400 From: Jeffrey Haas To: Nick Hilliard Cc: IETF IDR Working Group Message-ID: <20170314214817.GI12864@pfrc.org> References: <148924277112.2960.17904473852401253352@ietfa.amsl.com> <58C85ECE.3080109@foobar.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <58C85ECE.3080109@foobar.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 21:42:08 -0000 Nick, On Tue, Mar 14, 2017 at 09:21:18PM +0000, Nick Hilliard wrote: > the text states: > > > 5.1. Route Server Client Procedures for NHIB Changes > > > > When entries are added to the a route server client's Adj-NHIB-In for > > a route server peering session, it will then attempt to verify > > connectivity to the BGP nexthop for that entry. The procedure > > described in this specification utilizes BFD; other mechanisms are > > permitted but are out of scope of this document. > > It might be an idea to explicitly acknowledge that some clients may want > to selectively filter out NHIB on the basis that they don't want to > establish bfd sessions to those particular NHs. There could be many > reasons for this, e.g. reliability of bfd on the remote side, > reliability of bfd on the local side. This would require some selection > mechanism to be implemented on the client. We had some text in earlier internal versions of the document that tried to make this explicit. I believe the text that remains is appropriately permissive but maybe not as explicit as you might like: : At the route server, the Adj-NHIB-Out for each client is populated : with the next hops from its Loc-RIB. If the BGP capabilities learned : during BGP session setup identify a next hop as compatible with this : proposal, this is reflected in the NHIB. Initially, it is assumed : that the client router is able to reach its next hops which is stored : in the NHIB. If a next hop is added to the NHIB for a particular : client, a route SHOULD be added to the router server's Adj-NHIB-Out. The SHOULD is the relevant point. This didn't make it into the sections for explicit NHIB behavior, and probably could use some emphasis in a future revision. >From the client procedure side: : If the client can not establish a BFD session with an entry in its : NHIB, the next hop is put it in the Adj-NHIB-Out for backward : compatibility. > A couple of other things: > > 1. if a route server client stops announcing prefixes to the route > server but still accepts prefixes, do all bfd sessions to it also get > torn down? Or is the purpose of the RS Adj-NHIB-In to ensure stickiness > of bfd sessions? If this is the case, it should be mentioned explicitly > because otherwise the feedback loop looks ... well, a bit peculiar. Section 5.2: : In the event that a given client that supports this feature does not : provide any routes containing BGP next hops that would be used to : populate an Adj-NHIB-Out entry, the route server SHOULD advertise an : entry for such a router using the provided self-originated entry. : This permits the provisioning of BFD peering sessions for continuity : check when route exchange via the route server is asymmetric and one : client has routes from a second client, but not vice-versa. > 2. > > It is incorrect provisioning for an IXP client which > > is using a Route Server to have a BGP session with another IXP > > client. > > lolno, if I'm reading this correctly. It's quite usual to have > bilateral + multilateral sessions configuration between router pairs. I suspected the sanity check might bounce here. :-) We'll update the wording accordingly. The main consideration is the new SAFI doesn't get negotiated and start transitively propagating the state. It might be worth adding verbiage about ensuring RS-Reachable SAFI have an AS_PATH that is consistent with directly connected peers instead. -- Jeff From nobody Tue Mar 14 14:48:44 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 003F4129B65 for ; Tue, 14 Mar 2017 14:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=instituut-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mI2iWwAArw8C for ; Tue, 14 Mar 2017 14:48:41 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::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 7F8F1129B60 for ; Tue, 14 Mar 2017 14:48:41 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id 196so15990885wmm.1 for ; Tue, 14 Mar 2017 14:48:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=AxaUxIEenpzHL6SnAcJhCi8IDGRdCT4gnahcmhKvGQY=; b=CoepSIihI/dL/EuL+usDAGD+srMY0Byigll3VP2yegJHVsIlshalRg/xs50B3va0pz pqeZKB4IkS9/WaY0QblqEa9isfjRZH7T4Mzgm7ELZjG+SMugC6vIdqekNvqOeBCKqg8q cZrXOQ0pgJuDn3UV0Al94s5suuXmL7qZDmp4AkFRGBHKi1pjqfY/DkTHFRBcsaChCrsX 0rOz013m+l1IP0nms8A7bs+kfivS6zZib3sfAcP2ppttb89mWrXgVpN2fAzWc0CiqjyS QYuzcypMVzdzqL631R7pKXHhIjlr2XznBXHBUPbFoavLU0a6lflw+CM2RILWox4/dTvY 4OvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=AxaUxIEenpzHL6SnAcJhCi8IDGRdCT4gnahcmhKvGQY=; b=gpHVyO1K9Jvq0E6NpzVe92RhRODpw3D9kYFEP/FspwAPVDFD4BVThdmywei2EJcvMu P0QiwJ6BLyh0lIR7uqXicDixwJhnl1nmAtZwYBp0prZiSheQJmqT1IKvv55J+65R2BQQ En02xW22E1nWWfxU4nm94ZFvIJEs6RSn8aCYrBy+iBTkU9WIMYdsHPcYCKbMRyzPoUcJ iOUbJhCw/PjGSRVE0LFsRK4AxUmatvqnhEg88TGAH211IyUmzFDIfEPTXmv1Xzu/qtJu q//8boYh7LaNX+fPrmQC3qpf0S+czqSuteH6S8om/dAif0jKBAbHLqQCCGQoivFxX2Bh OG8w== X-Gm-Message-State: AFeK/H3LVUbzKP4B+zoYbh+neiuBgvupvIVC1pHTlW/AdaiFIsjPp8EjH5h1aH/8MKQ9eQ== X-Received: by 10.28.95.87 with SMTP id t84mr16394113wmb.35.1489528119788; Tue, 14 Mar 2017 14:48:39 -0700 (PDT) Received: from localhost ([2001:67c:208c:10:195a:2373:c926:335d]) by smtp.gmail.com with ESMTPSA id j74sm30825558wrj.21.2017.03.14.14.48.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Mar 2017 14:48:33 -0700 (PDT) Date: Tue, 14 Mar 2017 22:48:32 +0100 From: Job Snijders To: Jeffrey Haas Cc: "Rajiv Asati (rajiva)" , idr wg , Robert Raszuk Message-ID: <20170314214832.s3k37p27y7xfpfsv@Vurt.local> References: <58C6751D.60306@foobar.org> <20170314204212.GD12864@pfrc.org> <815723FC-B143-4410-B0FF-D9FB4F827862@cisco.com> <20170314213607.GH12864@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20170314213607.GH12864@pfrc.org> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: NeoMutt/20170306 (1.8.0) Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 21:48:43 -0000 On Tue, Mar 14, 2017 at 05:36:07PM -0400, Jeffrey Haas wrote: > On Tue, Mar 14, 2017 at 09:08:24PM +0000, Rajiv Asati (rajiva) wrote: > > Is the assumption here that the client routers have routing view > > limited to what’s provided by the Route Server? If not, then > > wouldn’t Client Routers benefit from having to invalidate the path > > learned from the remote client router as soon as the connectivity > > check failed? > > This is what I believe the procedure says. See section 6. > > > Of course, Client Routers conveying the lack of NLRI reachability > > per NH to the Route Server, and expecting Route Server to provide a > > different NHs of the NLRIs, and expecting it to be functional, while > > still attracting the traffic for unreachable destinations since the > > Loc-RIB is still pointing to the unreachable NH for the affected > > NLRIs. > > The thing that is somewhat different for a IXP environment running a > route server than normal eBGP is the low (to zero) likelihood of > having a backup path. If 10/8 was learned from the route server for > nexthop 192.0.2.1, and you stop being able to reach that nexthop, > removing it from your forwarding (unreachable) is your only choice. > > You *might* have a source of that path internally. In that case, you > can use it. I might be misunderstanding you, but a route server is considered (at best) a supplementary partial view on the default-free zone. If the route server doesn't have the route, you will have learned an alternative route through either bilateral sessions on the IXP or through other sources such as transit sessions, or through ebgp paths distributed over ibgp. Any path that does not exist in the 'DFZ', but _does_ exist on the route server, is either an artifact of hyper local traffic engineering through deaggregation, or is a bgp hijack for the purpose of spamming a specific subset of route server participants. I'm somewhat inclined to accept that the route server itself may not have alternative paths for anything it received from one of its participants. however the likelihood of having an alternative path might increase as the route server's constituency increases (a growth trajectory which in turn might go hand in hand with increased chances of intra-fabric partial unreachability between participants of the fabric). either way, since we accepted that path hiding is an issue, we've implicitly accepted that backup paths may exist. > But more importantly, you'll stop sending it toward your own peering > and attracting blackholed traffic. i'm not sure i follow this scenario From nobody Tue Mar 14 14:58:57 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73040129B06 for ; Tue, 14 Mar 2017 14:58:56 -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=[RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gAe80v8dln0J for ; Tue, 14 Mar 2017 14:58:55 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 32D9E126FDC for ; Tue, 14 Mar 2017 14:58:55 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id C52271E33B; Tue, 14 Mar 2017 18:05:05 -0400 (EDT) Date: Tue, 14 Mar 2017 18:05:05 -0400 From: Jeffrey Haas To: Job Snijders Cc: "Rajiv Asati (rajiva)" , idr wg , Robert Raszuk Message-ID: <20170314220505.GJ12864@pfrc.org> References: <20170314204212.GD12864@pfrc.org> <815723FC-B143-4410-B0FF-D9FB4F827862@cisco.com> <20170314213607.GH12864@pfrc.org> <20170314214832.s3k37p27y7xfpfsv@Vurt.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20170314214832.s3k37p27y7xfpfsv@Vurt.local> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 21:58:56 -0000 On Tue, Mar 14, 2017 at 10:48:32PM +0100, Job Snijders wrote: > On Tue, Mar 14, 2017 at 05:36:07PM -0400, Jeffrey Haas wrote: > > On Tue, Mar 14, 2017 at 09:08:24PM +0000, Rajiv Asati (rajiva) wrote: > > > Is the assumption here that the client routers have routing view > > > limited to what’s provided by the Route Server? If not, then > > > wouldn’t Client Routers benefit from having to invalidate the path > > > learned from the remote client router as soon as the connectivity > > > check failed? > > > > This is what I believe the procedure says. See section 6. > > > > > Of course, Client Routers conveying the lack of NLRI reachability > > > per NH to the Route Server, and expecting Route Server to provide a > > > different NHs of the NLRIs, and expecting it to be functional, while > > > still attracting the traffic for unreachable destinations since the > > > Loc-RIB is still pointing to the unreachable NH for the affected > > > NLRIs. > > > > The thing that is somewhat different for a IXP environment running a > > route server than normal eBGP is the low (to zero) likelihood of > > having a backup path. If 10/8 was learned from the route server for > > nexthop 192.0.2.1, and you stop being able to reach that nexthop, > > removing it from your forwarding (unreachable) is your only choice. > > > > You *might* have a source of that path internally. In that case, you > > can use it. > > I might be misunderstanding you, but a route server is considered (at > best) a supplementary partial view on the default-free zone. If the > route server doesn't have the route, you will have learned an > alternative route through either bilateral sessions on the IXP or > through other sources such as transit sessions, or through ebgp paths > distributed over ibgp. The RS client having a source of a path via its iBGP from its internal network is exactly what I had in mind. RS clients having bilateral sessions with other IXP clients was somewhat less than common when I last operated a route server, so forgive my myopia on that point. :-) > Any path that does not exist in the 'DFZ', but > _does_ exist on the route server, is either an artifact of hyper local > traffic engineering through deaggregation, or is a bgp hijack for the > purpose of spamming a specific subset of route server participants. I would also caution against Internet-operations focused myopia as well here. RSes are deployed in environments that aren't IXPs. For the IXP case, I tend to agree with you. (And have been half following the GROW threads about having the RS participate in route validation.) > > But more importantly, you'll stop sending it toward your own peering > > and attracting blackholed traffic. > > i'm not sure i follow this scenario Receiving a path from the RS that is blackholing and propagating it internally via iBGP. -- Jeff From nobody Tue Mar 14 15:02:09 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 987E7129BA1 for ; Tue, 14 Mar 2017 15:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id esCmhXOJIGxZ for ; Tue, 14 Mar 2017 15:02:04 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::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 A9A22129B9B for ; Tue, 14 Mar 2017 15:02:03 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id p64so259597112qke.1 for ; Tue, 14 Mar 2017 15:02:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=QeSU+PKZikk691j5dK11DgIUPozlaT8DutLKxzpFihA=; b=qElac5bBxG+6nX9vVYdZgyo51M7rhINr3RjRfdrVcRrBJrP6o9VmoOv6tZyRTQV7MU RXy3MNF4zs1EanCWJVUAhKgIGWW77489r0FiVSlkc7bQTcYYEB4hE4HqPAiszDhnd5Hb awwEWn37sD4AbZkapTAYBgJWxzMvGJki1JrkszqvMRXTvnwXt0OM/afjoHLnTaXzqPlG iJlBLNRD2/kl+wn/7EX8oR9BkSF9s4zzC6lV429ZogJAEACilU5ugSrzYX9m9AaYm8Gj M4oXoLNNkGZ01tg4yUmeM9VUMVnL/Lx+oXezxB6pkzed1nYob8lyYQOHB9bMvbIdmwM+ qKcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=QeSU+PKZikk691j5dK11DgIUPozlaT8DutLKxzpFihA=; b=PCIhpMguJBc9r+qdJOIQsZOCAKdnOvkqv/qRmxwckFtLWUPkG6uTbOZbBaaftB6Oe8 uWo3L/Aki02mCoN75oDkWd+JZmx6E1Sqnyhl/MB4UIiNOnF5WQS1baTG6YKOMojCOYFr GZ5wypVAOtCi4FB9HteJz6kZWkMcixga/C9H7DnsAadKKVxf3s03yr4cjpGF9++ORTHp Wkv8SqG5h33N9DNg2dnbqXr64jZf6MqArz7Ge0e/EnvjiQx4OGY23TFyX20oJn4qweoT gykcDNNYf19Cav86kL4RCTpB65bIY0GxGH0VB7RVCW8HCMl/15qE+OAYTVRjGcGXYB68 6QTg== X-Gm-Message-State: AMke39l31/Dhj+8THmovkNVWdB7srSXv/z9EApRyfyjhidyroCW+CZ/R9sEjL2ut8sIVx1tVUD2f4aILsGEIzg== X-Received: by 10.55.144.4 with SMTP id s4mr37909631qkd.101.1489528922814; Tue, 14 Mar 2017 15:02:02 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.140.42.181 with HTTP; Tue, 14 Mar 2017 15:02:02 -0700 (PDT) In-Reply-To: <20170314214832.s3k37p27y7xfpfsv@Vurt.local> References: <58C6751D.60306@foobar.org> <20170314204212.GD12864@pfrc.org> <815723FC-B143-4410-B0FF-D9FB4F827862@cisco.com> <20170314213607.GH12864@pfrc.org> <20170314214832.s3k37p27y7xfpfsv@Vurt.local> From: Robert Raszuk Date: Tue, 14 Mar 2017 23:02:02 +0100 X-Google-Sender-Auth: c7Um8-3diq9s1epeil-9Pj1LMvs Message-ID: To: Job Snijders Cc: Jeffrey Haas , "Rajiv Asati (rajiva)" , idr wg Content-Type: multipart/alternative; boundary=94eb2c057a7053bfa9054ab7fa68 Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 22:02:09 -0000 --94eb2c057a7053bfa9054ab7fa68 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =E2=80=8BHi Job,=E2=80=8B > =E2=80=8B > Any path that does not exist in the 'DFZ', but > _does_ exist on the route server, is either an artifact of hyper local > traffic engineering through deaggregation, or is a bgp hijack for the > purpose of spamming a specific subset of route server participants. > =E2=80=8BInteresting ... why would you think so ? Imagine I connect to an IX and also have direct Transit =E2=80=8Bwith NTT. = To the same IX also customers of NTT connect such that I can use IX switch to get to them without going via longer path of transit provider. To me their direct routes are better (BGP path selection wise) and I go via IX to reach them (or they go via IX to reach my content). > I'm somewhat inclined to accept that the route server itself may not > have alternative paths for anything it received from one of its > participants. =E2=80=8BWell that is indeed very important to verify. I am also inclined t= o the same. But have no data to validate how many paths for all nets RSes carry in major IXes. Moreover IXes normally use two RS today so it is trivial to make sure one RS sends =E2=80=8Bfirst best the other second best to the clients (if they = have more then one). Signalling client to RS that NH is down seems at best redundant. =E2=80=8BThx, r. --94eb2c057a7053bfa9054ab7fa68 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=E2=80=8BHi Job,=E2=80=8B
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
=E2=80= =8B
Any path that does not exist in the 'DFZ', but
_does_ exist on the route server, is either an artifact of hyper local
traffic engineering through deaggregation, or is a bgp hijack for the
purpose of spamming a specific subset of route server participants.

=E2=80=8BInteresting ... wh= y would you think so ?=C2=A0

Imagine I connect to an IX and also have direct Transit =E2=80=8Bw= ith NTT. To the same IX also customers of NTT connect such that I can use I= X switch to get to them without going via longer path of transit provider.= =C2=A0

To me their dir= ect routes are better (BGP path selection wise) and I go via IX to reach th= em (or they go via IX to reach my content).=C2=A0

=C2=A0
I'm= somewhat inclined to accept that the route server itself may not
have alternative paths for anything it received from one of its
participants.


=E2=80=8BWell that is indeed very important to verify. I am also incl= ined to the same. But have no data to validate how many paths for all nets = RSes carry in major IXes.=C2=A0

Moreover IXes normally use two RS today so it is trivial to make = sure one RS sends =E2=80=8Bfirst best the other second best to the clients = (if they have more then one). Signalling client to RS that NH is down seems= at best redundant.=C2=A0

=E2=80=8BT= hx,
r.= =C2=A0
--94eb2c057a7053bfa9054ab7fa68-- From nobody Tue Mar 14 15:08:03 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B57F129A76 for ; Tue, 14 Mar 2017 15:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=instituut-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HqIopOyic0F9 for ; Tue, 14 Mar 2017 15:07:58 -0700 (PDT) Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::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 7E254129406 for ; Tue, 14 Mar 2017 15:07:58 -0700 (PDT) Received: by mail-wr0-x22f.google.com with SMTP id l37so132971687wrc.1 for ; Tue, 14 Mar 2017 15:07:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=32HqNoSQCkQTBiRTUxdKMli+/FGwHmq2nU3eyKt7QVc=; b=qyJsXUlyV6sP1vqAAmGOrsrll2H3DvCROXDr4nTI3LYsj/f9FK3VMTAj20yktcRJ4u oFAA4QEPwSGBfkZ9vmeA0k8GmC8kdBt19nuduxAizYYAZmhxBkQq0zXZfeycturpk1Sb j4NnTzJQ9SS4BRmDLXXrhz+sFG+REgn0cviqVgbanWzm3EwiqRJ9nHskz8U3fiEjAly7 XXzfyDwbUSFoWQXX7whvBPeV5DHgR8axQfns6u+Om9p1/4h8ReFjHxEOgXvFvzZeloEy E5L1G/YU2uC39FSylo1bMQonvUtkchbku7nrEc77nTAPKS/oIk7e21GmnAdtsu4aKbEb bOkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=32HqNoSQCkQTBiRTUxdKMli+/FGwHmq2nU3eyKt7QVc=; b=lr752S/xjKEwwugLE5lhQpG+1zskPqaIFQnpGUhPc2tx5YvO+zV4rtZNVzO/5af/eO ehmMDeocHUzsjAgKFYtJXVMoSX7FS6hR2XEcWN9mXlCwMiopInDeDLC19X9XY6iklma9 wcoZZqi5Q6Qs3v08zoqaPXnlHzdY7RhO+4MQOUEd8EdahTviHw5IiPKacCx7O+PV/wYR 8h14pQnBwcr4I311pab32wYBv/ULZdzAqthiriH+u2Me5oqSW6HVNlG0xUEd0I+OnYki Kn0Eg9qvytYjo7XxFLnxi67A/pxPnXIXJEiODwsSaBfJbmgFmNIFoWEBYwBkrjZyTXye 4a2A== X-Gm-Message-State: AMke39kc4cUS55kLnfLAFdU0ACBmOX+/zmywx2KVl5lhSXEQ32/C01TUxqyY1Uyam7ng4QR25+/QwRwqjhoXTw== X-Received: by 10.223.148.35 with SMTP id 32mr34436195wrq.82.1489529274895; Tue, 14 Mar 2017 15:07:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.182.162 with HTTP; Tue, 14 Mar 2017 15:07:54 -0700 (PDT) X-Originating-IP: [2001:67c:208c:10:195a:2373:c926:335d] In-Reply-To: <20170314193036.GC12864@pfrc.org> References: <03ae01d29c3e$6c5d87a0$451896e0$@ndzh.com> <20170314193036.GC12864@pfrc.org> From: Job Snijders Date: Tue, 14 Mar 2017 23:07:54 +0100 Message-ID: To: Jeffrey Haas , idr wg Content-Type: multipart/alternative; boundary=94eb2c0d21c250257a054ab80f23 Archived-At: Subject: Re: [Idr] draft-hares-deprecate-atomic-aggregate (was Re: Request for 2 drafts) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 22:08:02 -0000 --94eb2c0d21c250257a054ab80f23 Content-Type: text/plain; charset=UTF-8 On Tue, 14 Mar 2017 at 20:24, Jeffrey Haas wrote: > Sue, > > On Mon, Mar 13, 2017 at 05:11:45PM -0400, Susan Hares wrote: > > I'd like to follow-up on our "clean up" the attribute area discussion. > > > > I've published: > [...] > > > > draft-hares-deprecate-atomic-aggregate-00 > > I'd actually recommend against outright deprecating AA. Mostly it'll lead > to confusion of compliant implementations of 1771/4271 without a lot of > benefit. > > A significant amount of the controversy around the feature while > standardizing 4271 had to do with the rules by which AA was attached to > routes. I suspect very few people besides Tony Li ever had a strong > opinion > about the behavior, especially once we got beyond the BGP-3 transition. > (And I wasn't there at the time. The Tony observation is driven mostly by > him popping up a few years ago with a proposal that included AA behavior.) > > The current behavior of 4271 with regard to AA is pretty mild: If you're > dropping out ASes from the path as part of aggregation, you SHOULD add this > thing. If you see it, don't de-aggregate. > > People generally don't de-aggregate magically these days and those who do > generally expect to have to be very careful. > > The document that I thought was worth writing at some point, even if it > only > was a draft and never got published, was a short discussion about the > origin > of the feature, what its original intent was, what was broken about its > original rules to be attached and why we ended up where we did. This is > arguably a history document intending to document a rather ugly bit of > living history that confuses newcomers to the protocol. > > I'm happy to contribute to such a document. But I don't recommend we > proceed down the path to deprecation. Hi Jeff, Isn't the path to deprecate a poorly understood feature ("poorly" as in ugly, that there is a disconnect between expectations), to just.. deprecate it? I'd welcome historic perspective in such a deprecation document for newcomers, it would be helpful for my edification to learn of the rise and fall of a protocol complications. However I don't see a compelling reason in itself to not touch 4271, for the purpose of touching 4271. There have been a number of updates to 4271 over the years, and compliant implementations need to continue to monitor IETF documents to remain complaint, right? In context of internet-wide EBGP operations I'd view both aggregation (aggregation through snipping globally unique ASNs from the as_path) as well as de-aggregation as most unwelcome. At this point especially de-aggregation is real threat to the DFZ, stuff like http://bgpmon.net/bgp-optimizer-causes-thousands-of-fake-routes/ comes to mind. Is there a legitimate use case for keeping atomic aggregate around? if not, we should clean up. I'm usually in favour of deleting things that are not used. Kind regards, Job --94eb2c0d21c250257a054ab80f23 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tue, 14 Mar 2017 at= 20:24, Jeffrey Haas <jhaas@pfrc.org> wrote:
Sue,

On Mon, Mar 13, 2017 at 05:11:45PM -0400, Susan Hares wrote:
> I'd like to follow-up on our "clean up" the attribute ar= ea discussion.
>
> I've published:
[...]
>
> draft-hares-deprecate-atomic-aggregate-00

I'd actually recommend against outright deprecating AA.=C2=A0 Mostly it= 'll lead
to confusion of compliant implementations of 1771/4271 without a lot of
benefit.

A significant amount of the controversy around the feature while
standardizing 4271 had to do with the rules by which AA was attached to
routes.=C2=A0 I suspect very few people besides Tony Li ever had a strong o= pinion
about the behavior, especially once we got beyond the BGP-3 transition.
(And I wasn't there at the time.=C2=A0 The Tony observation is driven m= ostly by
him popping up a few years ago with a proposal that included AA behavior.)<= br class=3D"gmail-m_8479427967080327251gmail_msg">
The current behavior of 4271 with regard to AA is pretty mild: If you'r= e
dropping out ASes from the path as part of aggregation, you SHOULD add this=
thing.=C2=A0 If you see it, don't de-aggregate.

People generally don't de-aggregate magically these days and those who = do
generally expect to have to be very careful.

The document that I thought was worth writing at some point, even if it onl= y
was a draft and never got published, was a short discussion about the origi= n
of the feature, what its original intent was, what was broken about its
original rules to be attached and why we ended up where we did.=C2=A0 This = is
arguably a history document intending to document a rather ugly bit of
living history that confuses newcomers to the protocol.

I'm happy to contribute to such a document.=C2=A0 But I don't recom= mend we
proceed down the path to deprecation.

Hi Je= ff,

Isn't the path to deprecate a poorly under= stood feature ("poorly" as in ugly, that there is a disconnect be= tween expectations), to just.. deprecate it? I'd welcome historic persp= ective in such a deprecation document for newcomers, it would be helpful fo= r my edification to learn of the rise and fall of a protocol complications.=

However I don't see a compelling reason in it= self to not touch 4271, for the purpose of touching 4271. There have been a= number of updates to 4271 over the years, and compliant implementations ne= ed to continue to monitor IETF documents to remain complaint, right?=C2=A0<= /div>

In context of internet-wide EBGP operations I'= d view both aggregation (aggregation through snipping globally unique ASNs = from the as_path) as well as de-aggregation as most unwelcome. At this poin= t especially de-aggregation is real threat to the DFZ, stuff like=C2=A0ht= tp://bgpmon.net/bgp-optimizer-causes-thousands-of-fake-routes/ comes to= mind.

Is there a=C2=A0legitimate use case for kee= ping atomic aggregate around? if not, we should clean up.

I'm usually in favour of deleting things that are not used.

Kind regards,

Job
=
--94eb2c0d21c250257a054ab80f23-- From nobody Tue Mar 14 15:21:37 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E1BD127058 for ; Tue, 14 Mar 2017 15:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=instituut-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sp4t1f65GUYE for ; Tue, 14 Mar 2017 15:21:34 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A0D21315BD for ; Tue, 14 Mar 2017 15:21:34 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id v186so74840379wmd.0 for ; Tue, 14 Mar 2017 15:21:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=zKo1wIiaXCnpENKDBdUBciAhFrirEeqATne8caDWf1M=; b=eIvJ8PKbfXKeSMVjgTUwLUvqbNnRTAyMlJF0UK+UiLflBCYbBZzvlr3qQZ8Kg8HS0+ NtCpIcURxycDdfx/fvnhh8Z16YHQWKuQV7Ta0DJFUvP4RX1fYnbwdLGip0747EkkRPX8 QboYq78FoqF0uHTOenGovzGAL7quCDvq8KRWKcQzfxRrmgZFnrZCy/W9JsZ7SzaTAXv9 LO0rXwHQaGQzEaHdC3mMM3ATlYYGCGzjkSh9vZOmh5n6uqFk39/32g911eUzrr34rxS6 3n9CXVVqv6GBHWAINzEEDpmUZ4XV468pCJU2NI8ywh+tiCfGadKK/bYLj2BMdY5yu6jp q8ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=zKo1wIiaXCnpENKDBdUBciAhFrirEeqATne8caDWf1M=; b=Ae+DMUUgWCtOUpn6vZ/+hMp/GSuaLtRmZFDkl0AuJ5aopOk4C4XiTdaFiKGPiURxCy iAvRNoHXx8LPS80BSRpxtA+bACL/FPbYGLXt/yPk+VPvBkmU92h52mDwc30ccrENciY2 /Eef1XommsKNvIwCR83ou1Thdtb6FKtw4iJsrFXELVp3nasoIP6G9O4dMICFUL33ayGG U7gNruMj0faQcsZNCGHWVOgHoWopJ6H8fqV5noelgH1F68bYj4qrPBxcxZMkuZlkpVcV kbjKGA3hTQq5NCReuz2A+x5iZV1X4Y4z4BU7I2xNCQVMY7rl3+wVGGBhrWe4F4HJ6uEl LTgw== X-Gm-Message-State: AFeK/H3JNP1ZRrLKsRZOU4OboIsqCOmzZdLQvO+BjLmKDqP0ZpxAHL7bKp2uOo3NE3G2HQ== X-Received: by 10.28.146.207 with SMTP id u198mr16607048wmd.36.1489530092772; Tue, 14 Mar 2017 15:21:32 -0700 (PDT) Received: from localhost ([2001:67c:208c:10:195a:2373:c926:335d]) by smtp.gmail.com with ESMTPSA id 128sm17151977wmp.11.2017.03.14.15.21.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Mar 2017 15:21:25 -0700 (PDT) Date: Tue, 14 Mar 2017 23:21:24 +0100 From: Job Snijders To: Jeffrey Haas Cc: "Rajiv Asati (rajiva)" , idr wg , Robert Raszuk Message-ID: <20170314222124.bfxbvgbzk4n27rh3@Vurt.local> References: <20170314204212.GD12864@pfrc.org> <815723FC-B143-4410-B0FF-D9FB4F827862@cisco.com> <20170314213607.GH12864@pfrc.org> <20170314214832.s3k37p27y7xfpfsv@Vurt.local> <20170314220505.GJ12864@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20170314220505.GJ12864@pfrc.org> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: NeoMutt/20170306 (1.8.0) Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 22:21:36 -0000 On Tue, Mar 14, 2017 at 06:05:05PM -0400, Jeffrey Haas wrote: > On Tue, Mar 14, 2017 at 10:48:32PM +0100, Job Snijders wrote: > > On Tue, Mar 14, 2017 at 05:36:07PM -0400, Jeffrey Haas wrote: > > > On Tue, Mar 14, 2017 at 09:08:24PM +0000, Rajiv Asati (rajiva) wrote: > > > > Is the assumption here that the client routers have routing view > > > > limited to what’s provided by the Route Server? If not, then > > > > wouldn’t Client Routers benefit from having to invalidate the path > > > > learned from the remote client router as soon as the connectivity > > > > check failed? > > > > > > This is what I believe the procedure says. See section 6. > > > > > > > Of course, Client Routers conveying the lack of NLRI reachability > > > > per NH to the Route Server, and expecting Route Server to provide a > > > > different NHs of the NLRIs, and expecting it to be functional, while > > > > still attracting the traffic for unreachable destinations since the > > > > Loc-RIB is still pointing to the unreachable NH for the affected > > > > NLRIs. > > > > > > The thing that is somewhat different for a IXP environment running a > > > route server than normal eBGP is the low (to zero) likelihood of > > > having a backup path. If 10/8 was learned from the route server for > > > nexthop 192.0.2.1, and you stop being able to reach that nexthop, > > > removing it from your forwarding (unreachable) is your only choice. > > > > > > You *might* have a source of that path internally. In that case, you > > > can use it. > > > > I might be misunderstanding you, but a route server is considered (at > > best) a supplementary partial view on the default-free zone. If the > > route server doesn't have the route, you will have learned an > > alternative route through either bilateral sessions on the IXP or > > through other sources such as transit sessions, or through ebgp paths > > distributed over ibgp. > > The RS client having a source of a path via its iBGP from its internal > network is exactly what I had in mind. > > RS clients having bilateral sessions with other IXP clients was somewhat > less than common when I last operated a route server, so forgive my myopia > on that point. :-) Glad we uncovered this discrepancy, it is safe to assume that in many cases (i say 'many' because we have no well established metric system for this), both bilateral and multilateral sesions exist. Any specification will need to be engineered with this in mind. If someone is looking to receive as many BGP routes and paths as possible, you'll set up sesions with whoever wants to, this includes both direct and route servers. With the rise of network automation based on public peering directories such as peeringdb.com, this process becomes even more streamlined. The process effort of denying bilateral peering requests because you can see the remote network through the route server, or tuning the route server to not be used when there is a bilateral session, would outweight just setting up bgp indiscriminately. > > Any path that does not exist in the 'DFZ', but > > _does_ exist on the route server, is either an artifact of hyper local > > traffic engineering through deaggregation, or is a bgp hijack for the > > purpose of spamming a specific subset of route server participants. > > I would also caution against Internet-operations focused myopia as well > here. RSes are deployed in environments that aren't IXPs. This is new information for me. > For the IXP case, I tend to agree with you. (And have been half > following the GROW threads about having the RS participate in route > validation.) > > > > But more importantly, you'll stop sending it toward your own peering > > > and attracting blackholed traffic. > > > > i'm not sure i follow this scenario > > Receiving a path from the RS that is blackholing and propagating it > internally via iBGP. gotcha, yes. From nobody Tue Mar 14 15:33:08 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0B881294C7 for ; Tue, 14 Mar 2017 15:33:07 -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=[RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hizMGtzWPZyQ for ; Tue, 14 Mar 2017 15:33:06 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 6601D127058 for ; Tue, 14 Mar 2017 15:33:06 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id D138F1E33B; Tue, 14 Mar 2017 18:39:16 -0400 (EDT) Date: Tue, 14 Mar 2017 18:39:16 -0400 From: Jeffrey Haas To: Job Snijders Cc: idr wg Message-ID: <20170314223916.GL12864@pfrc.org> References: <03ae01d29c3e$6c5d87a0$451896e0$@ndzh.com> <20170314193036.GC12864@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: Subject: Re: [Idr] draft-hares-deprecate-atomic-aggregate (was Re: Request for 2 drafts) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 22:33:07 -0000 On Tue, Mar 14, 2017 at 11:07:54PM +0100, Job Snijders wrote: > Isn't the path to deprecate a poorly understood feature ("poorly" as in > ugly, that there is a disconnect between expectations), to just.. deprecate > it? I'd welcome historic perspective in such a deprecation document for > newcomers, it would be helpful for my edification to learn of the rise and > fall of a protocol complications. This is one of those things I'd love to say "it's nice on principle" but usually get followed by "but the consequences are a bit ugly". Deprecating means largely "don't do that". You now have to deal with all of the consequences of those things that still do that or expect such to be done. BGP changes are all about incremental rollout headache after all. Implementations will still be required to understand the attribute and minimally to ignore it. This means you don't really get rid of much code there. Conformance tools will still probe for what we do for things and have to be revised to not flag as non-conformant an implementation that doesn't pass the attribute along if it's been set. Or that it's added if the as-path is truncated or otherwise incomplete. And while deaggregation isn't typically done automatically by routers, it's still good to signal that doing so may be a bad idea. I'll let you dig out your favorite deaggregation traffic shaping tool presentation from the *NOG of your choice. So, the benefits don't really outweigh the consequence of leaving it in. If we'd been having this conversation as part of trying to get 1771 style AA semantics working right[1], I might have had a somewhat different opinion. > However I don't see a compelling reason in itself to not touch 4271, for > the purpose of touching 4271. There have been a number of updates to 4271 > over the years, and compliant implementations need to continue to monitor > IETF documents to remain complaint, right? See above. > In context of internet-wide EBGP operations I'd view both aggregation > (aggregation through snipping globally unique ASNs from the as_path) as > well as de-aggregation as most unwelcome. At this point especially > de-aggregation is real threat to the DFZ, stuff like > http://bgpmon.net/bgp-optimizer-causes-thousands-of-fake-routes/ comes to > mind. See above. (I generally agree.) It's also likely to get worse. > Is there a legitimate use case for keeping atomic aggregate around? if not, > we should clean up. > > I'm usually in favour of deleting things that are not used. You're also not the one that gets the bug reports from this sort of thing. :-) At best, I'll acknowledge your network won't fall over from it not showing up the few times it actually does in the DFZ these days. -- Jeff [1] As part of Sue's crash course to how to participate in the IETF process, I was encouraged to try to work out issues we'd found in our implementation of the specification (draft-ietf-idr-bgp4-XX) on the mailing list. As part of working through inconsistencies in the text regarding how AA was set, I tried to contact our venerable authors on BGP to get them to work through those inconsistencies with me. Being busy at startups, most didn't respond. This left a rather inexperienced protocols implementor trying to intuit "what is this thing for?" and supplying various bits of text toward the draft to try to rectify the discrepancies. It turns out that if done using the intent of 1771 and earlier, AA would be set on *most* things, especially when policy was involved. However, discovering this set of things resulted in at least 3 churns of the draft. Eventually that was overcome by the realization that this is an appendix, in the anatomy sense; a vestigial organ. It's mostly useful to prevent auto-deaggregation in implementations that were transitioning from the classful BGP-3 to CIDR BGP-4. Such things didn't seem to be common even back in the day, and the transition from -3 to -4 seemed to take very little time across the backbones. What eventually remained was "this is a good idea to signal truncation or loss of information from the as-path" in the event that deaggregation would happen. While gross, people did and still do it. And even otherwise, having it as a handy note that "information was lost" during aggregation is still handy.[2] Having lost most of the crazy text about the rules with which you set AA based on what you learned, we now have a relatively quiet feature that's easy to implement with some minor operational benefit. This exercise in archaeology was my first, and a lingering introduction to Internet standards. I've almost foriven my second introduction, which involved SNMP. [2] An interesting side effect of extened UPDATES in our other thread will be that aggregation that results in sets from gateD family software will mean we have even LONGER AS_SETs today than before. While such implementations support "brief" aggregation, the transitional behavior of a long AS_SET on a extended message speaker to a 4k speaker will make for an interesting edge and conformance case. From nobody Tue Mar 14 15:33:39 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA52127058 for ; Tue, 14 Mar 2017 15:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=instituut-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m_3So2nWU8Dc for ; Tue, 14 Mar 2017 15:33:36 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::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 8FDB0129BD1 for ; Tue, 14 Mar 2017 15:33:36 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id n11so10181581wma.0 for ; Tue, 14 Mar 2017 15:33:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=gkIYqzE+30izYcGhNeluoBmQsOeCuLVlAq7Q4sJ1nNo=; b=Efvcv9sW4L6n6mk64WtyO90Y6kp64dFCo/Pz0brgxvFNT3Uho0G5BABuKnvIsTjR8+ pmxax8j/yyEnKG3VtqN9sy9TXNbXhM6X+GYPDR54YoJyvlSJF0EUDlJAlvNks0A4jCqm g8XIj7N6wcD+ndyEPgcHOwz9itj8qYETJImWSmdp086uDTluyL1162AlZRxC6s5ByJuJ 5tT6VPZUgo40pptlk+hmbr6SM48yFXRJI9EW9XSq8Q5jUIUZlX9Snd+dQcBAf8G75vHl s+o02OA8NbjfaC+owgpQGTVOqL3EKqLvihXTCx+4QEWOLi89fjQYfSNvMYo1yoGWeuoH Ns3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=gkIYqzE+30izYcGhNeluoBmQsOeCuLVlAq7Q4sJ1nNo=; b=eMBKxhHXau6/asBUWfS5+NH8IVkrOAfAIgFtGQCHdJH8FiSqpt/NhlXJCKiIkMRoWS gANZz3zlhowCthy4gjQsEuSzQ6zzvgWyc6kgmspgs/tM/wgLeSfdcLXNqSh3qFYLK856 Akdcv3Pn60xxQXf96fr6VIWf6Ht6e019AxA0jCl573VOwoP8V2yCRtwb1qvnDPFJA73T 9BSKT8J3pLbIo9Y6maZr2mLSPgH65RlxZILVA4htJ0KeZ9FcYP0+mR4KkYg2jvHDzcL9 xruYejufPHufOtcGEgDlfG4QIYSfqH+H32erD76DXtJeMJMLTc15ZYGqpDB94z75VHyF wTwg== X-Gm-Message-State: AFeK/H3eE1PFwXqSzrfdq+qidnd0aem9/2J3mhjJvHQKu0L6dJ0173UNnlf4SR4JRJ9o5w== X-Received: by 10.28.40.65 with SMTP id o62mr1682495wmo.131.1489530814872; Tue, 14 Mar 2017 15:33:34 -0700 (PDT) Received: from localhost ([2001:67c:208c:10:195a:2373:c926:335d]) by smtp.gmail.com with ESMTPSA id 63sm30810983wrh.68.2017.03.14.15.33.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Mar 2017 15:33:33 -0700 (PDT) Date: Tue, 14 Mar 2017 23:33:33 +0100 From: Job Snijders To: Robert Raszuk Cc: Jeffrey Haas , "Rajiv Asati (rajiva)" , idr wg Message-ID: <20170314223333.bw3caxfn34y6zlb7@Vurt.local> References: <20170314204212.GD12864@pfrc.org> <815723FC-B143-4410-B0FF-D9FB4F827862@cisco.com> <20170314213607.GH12864@pfrc.org> <20170314214832.s3k37p27y7xfpfsv@Vurt.local> 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: NeoMutt/20170306 (1.8.0) Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 22:33:38 -0000 On Tue, Mar 14, 2017 at 11:02:02PM +0100, Robert Raszuk wrote: > > Any path that does not exist in the 'DFZ', but _does_ exist on the > > route server, is either an artifact of hyper local traffic > > engineering through deaggregation, or is a bgp hijack for the > > purpose of spamming a specific subset of route server participants. > > Interesting ... why would you think so ? It is my observation that some networks will announce for instance a /16 to their upstream providers, but a /17 to their 'settlement free peers' (which could be found at an IXP). While there is no one single version of view of the Default-Free Zone, we do have a an understanding of what global reachability means vs local visibility. Through services such as http://stat.ripe.net/ you can see instances where the /16 enjoys good visiblity on the RIS/routeviews collectors but that more specifics also exist, which are not seem on all collectors. While the practise of announcing more specifics to certain classes of BGP neighbors does not have my preference, I can follow the rationale. The hijack case is discussed here https://ripe72.ripe.net/archives/video/203/ - https://ripe72.ripe.net/presentations/165-invisiable-hijacking-follow-up.pdf To summarize: if a route server has a unique route (either by virtue of being a more-specific of something learned over ibgp, or by being a hijack), that route in and of itself might not be of any value. I'd argue that for the public internet use case, it is fine to design a solution which assumes that route servers never contain 'unique' information, and that any participanting autonomous system will have alternative paths either to the same prefix or a less specific. > Imagine I connect to an IX and also have direct Transit with NTT. To > the same IX also customers of NTT connect such that I can use IX > switch to get to them without going via longer path of transit > provider. This is a valid and common scenario. > To me their direct routes are better (BGP path selection wise) and I > go via IX to reach them (or they go via IX to reach my content). Correct. > > I'm somewhat inclined to accept that the route server itself may not > > have alternative paths for anything it received from one of its > > participants. > > Well that is indeed very important to verify. I am also inclined to > the same. But have no data to validate how many paths for all nets > RSes carry in major IXes. > > Moreover IXes normally use two RS today so it is trivial to make sure one > RS sends first best the other second best to the clients (if they have > more then one). Signalling client to RS that NH is down seems at best > redundant. I believe it is a common practise amongst IXP Route Server operators to let the two (or more) route servers operate entirely _independent_ from each other, e.g. with no BGP sessions amongest the RS's themselves. Kind regards, Job From nobody Tue Mar 14 15:45:33 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7F95131614 for ; Tue, 14 Mar 2017 15:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=instituut-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wxt4EW5DkExN for ; Tue, 14 Mar 2017 15:45:30 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::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 A905413161B for ; Tue, 14 Mar 2017 15:45:29 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id n11so10327991wma.0 for ; Tue, 14 Mar 2017 15:45:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=OfDxbSZ3Pr5nad2GucA7OwrS+nIfQIqv/EV9oqe1CLM=; b=ZUdg6LQP24yvg2L1PHYaZkgM6+7lpJ5g4d8csZ++xQweybInn63CPQDWvAql8zSjA0 PVVhUBsIKWxmGlRP5+R6okzy61WVXBDyXUiIJfeNcKnLOu409We6EXUNm+/xtKSO6dRD Sxn2B3oaSJcB+LxuvX2i9WLu2C0apJvNCe24iVmqoSapjQsovOz1OoyF3WNPhAX7JCWH FMX2etSoBj8GkXmreT2RGryo97wuIRqHQ621q7oE10T1m47n53D1bSKhGqrXgXuiSPaU gCmfTaiBDN0NaNw5lrsEcpIWNMgUqNU4XTNXzWg9S8vYknzFLbLzmRllDF5TmdnnRBsh yyBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=OfDxbSZ3Pr5nad2GucA7OwrS+nIfQIqv/EV9oqe1CLM=; b=H7I877a+6ulY480ZVRioLXbDTLVRFd8mv0NCLf36zvvjmDJp4ZATtaT3I63oKeAm9S 6YdajJp/VnqpJWBOSs0IUZneUHiyrz7/2lors10Bp7+l3foFDm+Dvi/hKVV0dcNdEPJo ZcSVB0FNxAUsB7vhSh05jKh1S3P4UkLL9VVWI4gtEaTQZ1Z/FHKY2e5rNEpfv8m2Z/dn slr20EAgz8pTOGV5ZgF/up4PTtholcBW/0uC6j+wHJUOTEpNeBkCZaWMWXfjTRpK2aQX KOIHxCSHebf+Tproyv9FTN28owy/X73IXkFqqztpn9fj8KFUpsBgGmD4Nfe+zFKEDlR1 1Eyw== X-Gm-Message-State: AFeK/H2CQfPUFLhugRJ565HE4o5iG+BEU0MqXyV7D8/+Zrom6Tf+CfeHJRlxRr53ebJCiQ== X-Received: by 10.28.214.146 with SMTP id n140mr1674200wmg.58.1489531527868; Tue, 14 Mar 2017 15:45:27 -0700 (PDT) Received: from localhost ([2001:67c:208c:10:195a:2373:c926:335d]) by smtp.gmail.com with ESMTPSA id w97sm52901wrc.20.2017.03.14.15.45.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Mar 2017 15:45:26 -0700 (PDT) Date: Tue, 14 Mar 2017 23:45:25 +0100 From: Job Snijders To: Jeffrey Haas Cc: idr wg Message-ID: <20170314224525.2hjohmaf74vuxnwy@Vurt.local> References: <03ae01d29c3e$6c5d87a0$451896e0$@ndzh.com> <20170314193036.GC12864@pfrc.org> <20170314223916.GL12864@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170314223916.GL12864@pfrc.org> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: NeoMutt/20170306 (1.8.0) Archived-At: Subject: Re: [Idr] draft-hares-deprecate-atomic-aggregate (was Re: Request for 2 drafts) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 22:45:32 -0000 On Tue, Mar 14, 2017 at 06:39:16PM -0400, Jeffrey Haas wrote: > On Tue, Mar 14, 2017 at 11:07:54PM +0100, Job Snijders wrote: > > Isn't the path to deprecate a poorly understood feature ("poorly" as in > > ugly, that there is a disconnect between expectations), to just.. deprecate > > it? I'd welcome historic perspective in such a deprecation document for > > newcomers, it would be helpful for my edification to learn of the rise and > > fall of a protocol complications. > > This is one of those things I'd love to say "it's nice on principle" but > usually get followed by "but the consequences are a bit ugly". > > Deprecating means largely "don't do that". You now have to deal with all of > the consequences of those things that still do that or expect such to be > done. BGP changes are all about incremental rollout headache after all. > > Implementations will still be required to understand the attribute and > minimally to ignore it. This means you don't really get rid of much code > there. > > Conformance tools will still probe for what we do for things and have to be > revised to not flag as non-conformant an implementation that doesn't pass > the attribute along if it's been set. Or that it's added if the as-path is > truncated or otherwise incomplete. > > And while deaggregation isn't typically done automatically by routers, it's > still good to signal that doing so may be a bad idea. I'll let you dig out > your favorite deaggregation traffic shaping tool presentation from the *NOG > of your choice. > > So, the benefits don't really outweigh the consequence of leaving it in. > > If we'd been having this conversation as part of trying to get 1771 style AA > semantics working right[1], I might have had a somewhat different opinion. > > > However I don't see a compelling reason in itself to not touch 4271, for > > the purpose of touching 4271. There have been a number of updates to 4271 > > over the years, and compliant implementations need to continue to monitor > > IETF documents to remain complaint, right? > > See above. > > > In context of internet-wide EBGP operations I'd view both aggregation > > (aggregation through snipping globally unique ASNs from the as_path) as > > well as de-aggregation as most unwelcome. At this point especially > > de-aggregation is real threat to the DFZ, stuff like > > http://bgpmon.net/bgp-optimizer-causes-thousands-of-fake-routes/ comes to > > mind. > > See above. (I generally agree.) It's also likely to get worse. > > > Is there a legitimate use case for keeping atomic aggregate around? if not, > > we should clean up. > > > > I'm usually in favour of deleting things that are not used. > > You're also not the one that gets the bug reports from this sort of thing. > :-) > > At best, I'll acknowledge your network won't fall over from it not showing > up the few times it actually does in the DFZ these days. > > -- Jeff > > [1] As part of Sue's crash course to how to participate in the IETF process, > I was encouraged to try to work out issues we'd found in our implementation > of the specification (draft-ietf-idr-bgp4-XX) on the mailing list. As part > of working through inconsistencies in the text regarding how AA was set, I > tried to contact our venerable authors on BGP to get them to work through > those inconsistencies with me. Being busy at startups, most didn't respond. > This left a rather inexperienced protocols implementor trying to intuit > "what is this thing for?" and supplying various bits of text toward the > draft to try to rectify the discrepancies. > > It turns out that if done using the intent of 1771 and earlier, AA would be > set on *most* things, especially when policy was involved. However, > discovering this set of things resulted in at least 3 churns of the draft. > Eventually that was overcome by the realization that this is an appendix, in > the anatomy sense; a vestigial organ. It's mostly useful to prevent > auto-deaggregation in implementations that were transitioning from the > classful BGP-3 to CIDR BGP-4. Such things didn't seem to be common even > back in the day, and the transition from -3 to -4 seemed to take very little > time across the backbones. > > What eventually remained was "this is a good idea to signal truncation or > loss of information from the as-path" in the event that deaggregation would > happen. While gross, people did and still do it. And even otherwise, having > it as a handy note that "information was lost" during aggregation is still > handy.[2] Having lost most of the crazy text about the rules with which you > set AA based on what you learned, we now have a relatively quiet feature > that's easy to implement with some minor operational benefit. > > This exercise in archaeology was my first, and a lingering introduction to > Internet standards. I've almost foriven my second introduction, which > involved SNMP. > > [2] An interesting side effect of extened UPDATES in our other thread will > be that aggregation that results in sets from gateD family software will > mean we have even LONGER AS_SETs today than before. While such > implementations support "brief" aggregation, the transitional behavior of a > long AS_SET on a extended message speaker to a 4k speaker will make for an > interesting edge and conformance case. Thank you for sharing this Jeff. I treasure emails like these :) Kind regards, Job From nobody Tue Mar 14 15:46:35 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95F6613161C; Tue, 14 Mar 2017 15:46:33 -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=[RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TO2Zj0JMfmBs; Tue, 14 Mar 2017 15:46:32 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 941D013161B; Tue, 14 Mar 2017 15:46:32 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 3124A1E33B; Tue, 14 Mar 2017 18:52:43 -0400 (EDT) Date: Tue, 14 Mar 2017 18:52:43 -0400 From: Jeffrey Haas To: Susan Hares Cc: 'Enke Chen' , 'idr wg' , 'Robert Raszuk' , idr-chairs@ietf.org, draft-ietf-idr-bgp-extended-messages@ietf.org Message-ID: <20170314225242.GM12864@pfrc.org> References: <01b301d29758$180458e0$480d0aa0$@ndzh.com> <7657b686-0685-9bdf-17ba-e7d618a237aa@cisco.com> <004001d29874$9ed03840$dc70a8c0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <004001d29874$9ed03840$dc70a8c0$@ndzh.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 22:46:34 -0000 Sue, On Wed, Mar 08, 2017 at 08:29:37PM -0500, Susan Hares wrote: > Caveat - I am not commenting on operational issues. If your brief comment > denotes some operational issues, I would appreciate a longer description > on-list or off-list. > > If you are comment on the functionality within the RFC4271 FSM, I am not > sure why the "wiggle room is reduced when the open message size is changed"? > I have been specific on this list as to the functionality a message header > length error enacts (Event 21) versus an Open Message Header enacts (Event > 22). Please be as specific in your response if it is a FSM issues. This is to some extent a simple issue with regard to extended and non-extended speakers trying to interoperate. However, the version case with the changes under discussion complicate the matter slightly. Presume old RFC 4271 speaker, O. Presume new extended message speaker E. If E sends an open message > 4096 octets to O, the generally expected behavior is that O will send a notification message with a Bad Message Length subcode. O has no reason to change its behavior. E may have course note this specific error and try to back-off, if possible to a <= 4096 message size. However, I tend to agree with other threads that we're better off blocking the peering session from coming up without further intervention. I am *not* a supporter of deferring the larger Open operations to another message; we'd be better off getting something like Dynamic Capabilities working and we've had a number of discussions about why some of that behavior is problematic. (Alternatively, we simply have the extended open message, but that's a bit of a change in the FSM.) So... why did I bring up the version negotiation point? Mostly because for version negotiation to work, once we leave -4 behind, we need to be able to generate an Unsupported Version Number error. We can't do that if the receiver simply dumps the session due to hitting the message length validation failure first. As I mention too tersely in my response... oh well. But it does mean that if we go with > 4k open messages that old speakers will only get upset about PDUs that are too big rather than giving us other useful information about why session negotiation is failing. I suspect this is fine, but it should be a choice that is clearly understood. -- Jeff From nobody Tue Mar 14 15:46:54 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0212131619 for ; Tue, 14 Mar 2017 15:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5SFeS3a6pber for ; Tue, 14 Mar 2017 15:46:51 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::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 45A7313161E for ; Tue, 14 Mar 2017 15:46:47 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id i34so365079qtc.0 for ; Tue, 14 Mar 2017 15:46:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=VgcEtPDkCArrNq3UniTeKLRc5wJ/qDl2E/WxneDUxuY=; b=rhau9npPyqlThJEKRlt2ZyRqcbf0MVfP3Y2oVctjjay/8hu0aBkXi7QfVYQhHsA4Kj YrlGGpo8hXuYlVg9FPiGx3t3OrZjeL2vumRaQXgzC2phKVZJ8Wxudag1rijAjwyepV7Z H5PEZhQ3GvqcdEzVy9ya8CDuchawVRPqVT3QJhBAdsfTRjplXwVm0x6Bnj0RIDXE/7DE 31s0VjuEWV7SPleYKtEmemfcfRcOM0A+8FpLYGjuwaZtGCusN/uQm8MY0oX4C3B8m3xw TOcaZRHg8BtbvJmKqPXmYwQCCDka7eD1w9nPOPlTexF4cdSPimlrqcDhV47Rpcd+W5Od jxmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=VgcEtPDkCArrNq3UniTeKLRc5wJ/qDl2E/WxneDUxuY=; b=KCCTt94G/xMh4UPOD0V4Dg6zi8TGvqQocxJb1w4g8BRmoFIgNjU3OzStJheBHWK842 6NDeHn5P6ngjXDV0MH2ugDpzHPDm1B5bQJT1cw/+PAKsZcsx1+pIU61XQcQWYAlSFMa5 /FRTBbkYs6TqJp4LkKJ6quoeyAy3bwvuBgfOWX6N0EpJM5bs5t5WqQD5QrQ/yZD/iDGK DQMISPqJR+zXlSjdwgN+rhZeducfmCBn5jBxcaWOVSKWyfH+ckBgpOMWYp0z/+f8hME5 BmaKhEnbp8wKGXXoefDdYsuSuJR5GYMAIktAhI6+O1yAlBmgLZOtigINWw5DIz1lGvof TVUA== X-Gm-Message-State: AFeK/H1YWFCgqYTa/iVh95oHua2iigkEocJR/q0ZXMECyTKvRm9Yu42qSe8ctZPLc6OjBd2NzyUeQ6XDivep/A== X-Received: by 10.200.53.209 with SMTP id l17mr44405qtb.281.1489531606473; Tue, 14 Mar 2017 15:46:46 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.140.42.181 with HTTP; Tue, 14 Mar 2017 15:46:45 -0700 (PDT) In-Reply-To: <20170314223333.bw3caxfn34y6zlb7@Vurt.local> References: <20170314204212.GD12864@pfrc.org> <815723FC-B143-4410-B0FF-D9FB4F827862@cisco.com> <20170314213607.GH12864@pfrc.org> <20170314214832.s3k37p27y7xfpfsv@Vurt.local> <20170314223333.bw3caxfn34y6zlb7@Vurt.local> From: Robert Raszuk Date: Tue, 14 Mar 2017 23:46:45 +0100 X-Google-Sender-Auth: c81WUl8bOBHKyxDAXNqD4Uz1ljo Message-ID: To: Job Snijders Cc: Jeffrey Haas , "Rajiv Asati (rajiva)" , idr wg Content-Type: multipart/alternative; boundary=001a1143c7b0492ba0054ab89a4d Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 22:46:53 -0000 --001a1143c7b0492ba0054ab89a4d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =E2=80=8BJob,=E2=80=8B > I believe it is a common practise amongst IXP Route Server operators to > let the two (or more) route servers operate entirely _independent_ from > each other, e.g. with no BGP sessions amongest the RS's themselves. > =E2=80=8BSince clients will likely eBGP peer to both route servers and send= pretty much the same UPDATES to both you do not need any session between RSes to choose best one one and second best on the other towards the clients :) In fact in RS case tie break may be rtr_id :) Very easy to set such preference in cli. =3D =3D =3D All, And just for the record here the idea for NH SAFI has been proposed by Ilya & myself in 2012 ... https://tools.ietf.org/html/draft-ietf-idr-bgp-nh-cost-00 Best, R. =E2=80=8B --001a1143c7b0492ba0054ab89a4d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=E2=80=8BJob,=E2=80=8B
=C2=A0
I believe it is a common prac= tise amongst IXP Route Server operators to
let the two (or more) route servers operate entirely _independent_ from
each other, e.g. with no BGP sessions amongest the RS's themselves.
=

=E2=80=8BSince clients = will likely eBGP peer to both route servers and send pretty much the same U= PDATES to both you do not need any session between RSes to choose best one = one and second best on the other towards the clients :) In fact in RS case = tie break may be rtr_id :) =C2=A0Very easy to set such preference in cli.= =C2=A0

=3D =3D =3D=C2= =A0

All,

And just for the record here the id= ea for NH SAFI has been proposed by Ilya & myself in 2012 ...=C2=A0

https://tools.ietf.org/html/draft-ietf-idr-bgp-nh-c= ost-00

Best,
R.

=E2=80=8B

--001a1143c7b0492ba0054ab89a4d-- From nobody Tue Mar 14 15:52:47 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33814131614 for ; Tue, 14 Mar 2017 15:52:46 -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=[RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vofwghy9i362 for ; Tue, 14 Mar 2017 15:52:45 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id E9F9C131626 for ; Tue, 14 Mar 2017 15:52:44 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 842E41E33B; Tue, 14 Mar 2017 18:58:55 -0400 (EDT) Date: Tue, 14 Mar 2017 18:58:55 -0400 From: Jeffrey Haas To: Robert Raszuk Cc: Job Snijders , "Rajiv Asati (rajiva)" , idr wg Message-ID: <20170314225855.GN12864@pfrc.org> References: <20170314204212.GD12864@pfrc.org> <815723FC-B143-4410-B0FF-D9FB4F827862@cisco.com> <20170314213607.GH12864@pfrc.org> <20170314214832.s3k37p27y7xfpfsv@Vurt.local> <20170314223333.bw3caxfn34y6zlb7@Vurt.local> 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: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 22:52:46 -0000 On Tue, Mar 14, 2017 at 11:46:45PM +0100, Robert Raszuk wrote: > And just for the record here the idea for NH SAFI has been proposed by Ilya > & myself in 2012 ... > > https://tools.ietf.org/html/draft-ietf-idr-bgp-nh-cost-00 rs-bfd started with that as a likely way to handle carrying the RS state. However, we reached two conclusions: - the draft was inactive. - and even if we used it, it was an awkward fit for the mechanism. https://www.ietf.org/proceedings/93/slides/slides-93-idr-3.pdf Similarly, BGP-LS was given a try and decided to be too heavy weight. So, we're closer to where we started. :-) -- Jeff From nobody Tue Mar 14 16:08:55 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06439129B23 for ; Tue, 14 Mar 2017 16:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LszM9tSxzzOA for ; Tue, 14 Mar 2017 16:08:52 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::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 615EE129440 for ; Tue, 14 Mar 2017 16:08:52 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id n21so637740qta.1 for ; Tue, 14 Mar 2017 16:08:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=3MUHRUOGgdgIv3Hes/TcIScOCTiYXrt57Xf5yJljmoE=; b=RP5WjaEUqSntEElxrB+rMQUmOijcnWX3lMwlTRjaEN7kENQt4sU9Q79r8HgjKKi5rf PfB6CoSIeUqHi0+DNZG8BEXe/StfGYPRC9CI20z2y72NxUP8gn8BfY4CxVfhD8Wf30QL HaWyoKU/5PDFuXKtHIWZqPUwH1Kr/gJZhx3Eqf3iKa++lo+mBbmnHLIa0n6Vg4rpNe/p SL+edtEIJUHG8jz1wvv8UmCNJjqXHwpiyzR5dGVCuBSC1CnegJT/LMlq1R+ibCwXwtbX UsSZwwIrpXQidmeBslBszqWfK4V/kRRiL96S8NU6cE/M1+8eHUn6Ygtox5qn9sU55tOy 2q4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=3MUHRUOGgdgIv3Hes/TcIScOCTiYXrt57Xf5yJljmoE=; b=fIOJ7eTwiL1xoXyYhykHKWpxM/aOj0CLogz9fQCUhgE5tWxjzf2lIh+/DceV0pbXNB WkuMCZt1VmvycFXJDHuhAdj3TxAx8o75WePl8mwVgXRinNazDZjrhSd4S9gx1eAu+QK6 +fbP8eB8TUzM7qnoNUq/Oy8C+KVzmDf7HMV2JPiJyjoCECGfUBThmaIOeEumBhdxV4o+ pXpWaIq5jdDB/HeaYFMSvQep4c+6K0CJU7/NKjXgrXC3yfMh0OBe825AOURU7j63n1Vr OUMw4R3X+oMRChqG0vZXf4+i2ty2kHMhZyRP1hnlUZ67A2LKHK5roWcUPcuSL3b1d0rv /ePg== X-Gm-Message-State: AFeK/H3nWO29fV9JMO0qPJ3W85I2xJPuFn71IVB6bQ/nGXT2Z4gPqon/8O++6x+/q8vidNRCmo9uWVgvvWpqnQ== X-Received: by 10.200.62.145 with SMTP id y17mr156589qtf.53.1489532931539; Tue, 14 Mar 2017 16:08:51 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.140.42.181 with HTTP; Tue, 14 Mar 2017 16:08:50 -0700 (PDT) In-Reply-To: <20170314225855.GN12864@pfrc.org> References: <20170314204212.GD12864@pfrc.org> <815723FC-B143-4410-B0FF-D9FB4F827862@cisco.com> <20170314213607.GH12864@pfrc.org> <20170314214832.s3k37p27y7xfpfsv@Vurt.local> <20170314223333.bw3caxfn34y6zlb7@Vurt.local> <20170314225855.GN12864@pfrc.org> From: Robert Raszuk Date: Wed, 15 Mar 2017 00:08:50 +0100 X-Google-Sender-Auth: weT5IESoxqy9Wst-QZn74T7FN-c Message-ID: To: Jeffrey Haas Cc: Job Snijders , "Rajiv Asati (rajiva)" , idr wg Content-Type: multipart/alternative; boundary=f403045e6b28440ad8054ab8e97b Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 23:08:54 -0000 --f403045e6b28440ad8054ab8e97b Content-Type: text/plain; charset=UTF-8 Ok so we have history covered :) - - - Apart of that the more I think about this the more reasons pop-up which question both justification and value in informing RS about next hop reachability from clients to clients of Internet Exchanges. Let's summarize those again: - RS may not have other paths - RS may send more then best path to clients - RS come in pairs and it is trivial to send different paths from each of the RS with zero upgrade to clients - RS clients are grouped per their policies .. per client RIB requires a lot of overhead on route servers to address the case where only one client in the group suffers from some unreachable next hop - BFD sessions to next hops will require per next hop MD5 for security - IX have often more then one lan ... say 1500 and 9000 MTU. Next hops again may be different on both. - BFD session timers can't be unified on the clients as some clients are local and some remote. Remote both in the case of distributed IX as well as in the case of IX customers just connecting to IX with fiber without any *local* metal. - Clients will likely report churn of the same next hop being unreachable reasonable in the same time - When client reports unreachable next hop to RS .. it removes the path from client's RIB. But when does it add it again ? Note eBGP to RS are all fine .. would clients now not only keep BFD sessions to active peers but also trying to establish BFD to unreachable peers then notify RS that the peer is back ? - BFD on clients needs to work in non protocol associated mode. ... and I am pretty sure this is just the starter. r. On Tue, Mar 14, 2017 at 11:58 PM, Jeffrey Haas wrote: > On Tue, Mar 14, 2017 at 11:46:45PM +0100, Robert Raszuk wrote: > > And just for the record here the idea for NH SAFI has been proposed by > Ilya > > & myself in 2012 ... > > > > https://tools.ietf.org/html/draft-ietf-idr-bgp-nh-cost-00 > > rs-bfd started with that as a likely way to handle carrying the RS state. > However, we reached two conclusions: > - the draft was inactive. > - and even if we used it, it was an awkward fit for the mechanism. > > https://www.ietf.org/proceedings/93/slides/slides-93-idr-3.pdf > > Similarly, BGP-LS was given a try and decided to be too heavy weight. > > So, we're closer to where we started. :-) > > -- Jeff > --f403045e6b28440ad8054ab8e97b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Ok so we h= ave history covered :)=C2=A0

- - -

Apart o= f that the more I think about this the more reasons pop-up which question b= oth justification and value in informing RS about next hop reachability fro= m clients to clients of Internet Exchanges.=C2=A0
<= br>
Let's summarize those again:

- RS may not have other paths=C2=A0<= /div>

- RS may send more the= n best path to clients

- RS come in pairs and it is trivial to send different paths from each of = the RS with zero upgrade to clients=C2=A0

- RS clients are grouped per their policies .. per clie= nt RIB requires a lot of overhead on route servers to address the case wher= e only one client in the group suffers from some unreachable next hop
=

- BFD sessions to next hops= will require per next hop MD5 for security

- IX have often more then one lan ... say 1500 and 90= 00 MTU. Next hops again may be different on both.=C2=A0

- BFD session timers can't be unified= on the clients as some clients are local and some remote. Remote both in t= he case of distributed IX as well as in the case of IX customers just conne= cting to IX with fiber without any *local* metal.=C2=A0

- Clients will likely report churn of the= same next hop being unreachable reasonable in the same time=C2=A0

- When client reports unreacha= ble next hop to RS .. it removes the path from client's RIB. But when d= oes it add it again ? Note eBGP to RS are all fine .. would clients now not= only keep BFD sessions to active peers but also trying to establish BFD to= unreachable peers then notify RS that the peer is back ?=C2=A0

- BFD on clients needs to work in= non protocol associated mode.=C2=A0

... and I am pretty sure this is just the starter.

r.

=




On Tue, Mar 14, 2017 at 11:58 PM, Jeffrey Haas &l= t;jhaas@pfrc.org>= ; wrote:
On Tue, = Mar 14, 2017 at 11:46:45PM +0100, Robert Raszuk wrote:
> And just for the record here the idea for NH SAFI has been proposed by= Ilya
> & myself in 2012 ...
>
> https://tools.ietf.org/html/draft= -ietf-idr-bgp-nh-cost-00

rs-bfd started with that as a likely way to handle carrying the RS s= tate.
However, we reached two conclusions:
- the draft was inactive.
- and even if we used it, it was an awkward fit for the mechanism.

https://www.ietf.org/proceedings/= 93/slides/slides-93-idr-3.pdf

Similarly, BGP-LS was given a try and decided to be too heavy weight.

So, we're closer to where we started. :-)

-- Jeff

--f403045e6b28440ad8054ab8e97b-- From nobody Tue Mar 14 16:57:20 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75F7A12945F for ; Tue, 14 Mar 2017 16:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZEG0zcBS_2wh for ; Tue, 14 Mar 2017 16:57:16 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id A0DB51316DF for ; Tue, 14 Mar 2017 16:57:16 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id D30BB1E33B; Tue, 14 Mar 2017 20:03:26 -0400 (EDT) Date: Tue, 14 Mar 2017 20:03:26 -0400 From: Jeffrey Haas To: Robert Raszuk Cc: Job Snijders , "Rajiv Asati (rajiva)" , idr wg Message-ID: <20170315000326.GO12864@pfrc.org> References: <20170314204212.GD12864@pfrc.org> <815723FC-B143-4410-B0FF-D9FB4F827862@cisco.com> <20170314213607.GH12864@pfrc.org> <20170314214832.s3k37p27y7xfpfsv@Vurt.local> <20170314223333.bw3caxfn34y6zlb7@Vurt.local> <20170314225855.GN12864@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: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 23:57:18 -0000 On Wed, Mar 15, 2017 at 12:08:50AM +0100, Robert Raszuk wrote: > Apart of that the more I think about this the more reasons pop-up which > question both justification and value in informing RS about next hop > reachability from clients to clients of Internet Exchanges. > > Let's summarize those again: > > - RS may not have other paths > > - RS may send more then best path to clients > > - RS come in pairs and it is trivial to send different paths from each of > the RS with zero upgrade to clients But then you're not using a secondary RS for redundancy of your best path. (That may be fine.) > - RS clients are grouped per their policies .. per client RIB requires a > lot of overhead on route servers to address the case where only one client > in the group suffers from some unreachable next hop RS operators will have to speak to what sort of policies they want, but this *does* impact what a RS chooses to do with a declaration of unreachability from one peer in a peer group: - Does it try to split the group for that peer? (Unrealistic, IMO.) - Does it de-pref routes with that nexthop for *all* peers on the presumption that something bad has happened that the other peers haven't noticed yet? Etc. Good topic for further discussion. > - BFD sessions to next hops will require per next hop MD5 for security The use of BFD security mechanisms in general is an interesting question. Thankfully the suggested BFD timers here are very slow which helps the session scaling. > - IX have often more then one lan ... say 1500 and 9000 MTU. Next hops > again may be different on both. > > - BFD session timers can't be unified on the clients as some clients are > local and some remote. Remote both in the case of distributed IX as well as > in the case of IX customers just connecting to IX with fiber without any > *local* metal. > > - Clients will likely report churn of the same next hop being unreachable > reasonable in the same time A significant enough fabric event will simply lose the peering sessions to the RS in the first place. But losing entire "sides" of clients happens. > - When client reports unreachable next hop to RS .. it removes the path > from client's RIB. But when does it add it again ? Note eBGP to RS are all > fine .. would clients now not only keep BFD sessions to active peers but > also trying to establish BFD to unreachable peers then notify RS that the > peer is back ? This is no worse than an IGP event. > - BFD on clients needs to work in non protocol associated mode. > > ... and I am pretty sure this is just the starter. And good fodder for discussion from IX operators. > > r. > > > > > > On Tue, Mar 14, 2017 at 11:58 PM, Jeffrey Haas wrote: > > > On Tue, Mar 14, 2017 at 11:46:45PM +0100, Robert Raszuk wrote: > > > And just for the record here the idea for NH SAFI has been proposed by > > Ilya > > > & myself in 2012 ... > > > > > > https://tools.ietf.org/html/draft-ietf-idr-bgp-nh-cost-00 > > > > rs-bfd started with that as a likely way to handle carrying the RS state. > > However, we reached two conclusions: > > - the draft was inactive. > > - and even if we used it, it was an awkward fit for the mechanism. > > > > https://www.ietf.org/proceedings/93/slides/slides-93-idr-3.pdf > > > > Similarly, BGP-LS was given a try and decided to be too heavy weight. > > > > So, we're closer to where we started. :-) > > > > -- Jeff > > From nobody Tue Mar 14 17:46:24 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F5D2131755 for ; Tue, 14 Mar 2017 17:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wMzgly5y7-Pn for ; Tue, 14 Mar 2017 17:46:21 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 8695813174D for ; Tue, 14 Mar 2017 17:46:21 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 462A01E33B; Tue, 14 Mar 2017 20:52:32 -0400 (EDT) Date: Tue, 14 Mar 2017 20:52:32 -0400 From: Jeffrey Haas To: "Dongjie (Jimmy)" Cc: idr wg , Susan Hares Message-ID: <20170315005231.GP12864@pfrc.org> References: <76CD132C3ADEF848BD84D028D243C927935B96C0@NKGEML515-MBS.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <76CD132C3ADEF848BD84D028D243C927935B96C0@NKGEML515-MBS.china.huawei.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Idr] IETF98 agenda topics X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 00:46:22 -0000 Jie, On Sat, Mar 11, 2017 at 07:33:38AM +0000, Dongjie (Jimmy) wrote: > IDR will meet at IETF98 on Friday, March 31 from 9:00 to 11:30. Please > forward any IDR agenda items you might have to me and CC the chairs, the > deadline is March 17 by 10:00 U.S. Eastern Time. Priority will be given to > those who get their requests in by the deadline, though if agenda space > permits it we will consider requests gotten in before March 22 at 10:00 > U.S. Eastern Time. Please include the name of the person who will be > presenting, and the estimate time you'll need (including Q/A). We'd like a 10 minute slot for draft-ietf-idr-rs-bfd. We've presented on this before, but the discussion on the list suggests some in-room discussion may be valuable. -- Jeff From nobody Wed Mar 15 01:32:14 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA7161298AF for ; Wed, 15 Mar 2017 01:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TlDuzdIxY2cb for ; Wed, 15 Mar 2017 01:32:10 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 BF6601298A6 for ; Wed, 15 Mar 2017 01:32:10 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1co4Lj-0003JI-0w; Wed, 15 Mar 2017 08:32:03 +0000 Date: Wed, 15 Mar 2017 17:32:00 +0900 Message-ID: From: Randy Bush To: Jeffrey Haas Cc: "Dongjie (Jimmy)" , idr wg , Susan Hares In-Reply-To: <20170315005231.GP12864@pfrc.org> References: <76CD132C3ADEF848BD84D028D243C927935B96C0@NKGEML515-MBS.china.huawei.com> <20170315005231.GP12864@pfrc.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Idr] IETF98 agenda topics X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 08:32:12 -0000 > We'd like a 10 minute slot for draft-ietf-idr-rs-bfd. We've presented > on this before, but the discussion on the list suggests some in-room > discussion may be valuable. it has also undergone substantial change randy From nobody Wed Mar 15 02:13:36 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 789BB12999D for ; Wed, 15 Mar 2017 02:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UIqAhcVexsuK for ; Wed, 15 Mar 2017 02:13:31 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::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 8844612999F for ; Wed, 15 Mar 2017 02:13:31 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id r45so7419862qte.3 for ; Wed, 15 Mar 2017 02:13:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=d5+8+lldPqX37cWD8niSorna8uA1V16AUGzl7wsg5V8=; b=X3qd7KIAbOr0O7WQEosnJQkarc1waUTVR4YKSpjDT0tM+AELUk7Rudg8rHt3Xl16R3 h+3IzUX2bA8OLy3rcBaHwAET2AnkOM+WQFJPED99VbHSdRCrXs7poA2HVJ/sX/TrMiZh c9nD06AjjPuRj2x3q4fFQRuZFlT7ECYOgKqnscVb21qMtXD/QLFUsOsqaEiixfMSw9/9 q8rIi8NrY3Rv/VBbVV1bq5rHwu6jtjkao04do8259GDCZVKjpuFxbImeLm7BcC5ufucN js1YFOW7UkFNrxr5eg9oCuu1kgsJZ+z+BCSF4/g32sDaYZJlR0gCqZ2C8kckNF8RcP+d E6kA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=d5+8+lldPqX37cWD8niSorna8uA1V16AUGzl7wsg5V8=; b=eBCNrvH/aygtkGFRgbaa+1Fy4yAdCqc9uh/Ly5yN2tA580xI2/+9CklwzKFZ91rkCL 6ugE2DINQ4jfhv7s8zA2IYfoeQJc3cyN6HfKGUQjg5uXm7d6iMRf+jbTYqkOHhBAeNoF j8iCKk/1qjMv/Pieo69zk9FYezM1lWOUv6vZFuBrH61VIrWBHciVW3xHOoVWRB4azgCO 61zKDmOC2QtxNuf9Rzo3rmuH/L6FXiuMIZb5tfrI+qKgk0lTYF+RHtn1bO8jlskGpFfG MVWkxYCFZp1sjgVGRoRoMdUZAMnyB3S1xUYrgaAX9hLiSAfiY7b5e+8N/JCfI6qwLzvo ZXTQ== X-Gm-Message-State: AFeK/H36gR0zxD4JZFDnjhvrPcXzBzPo/RfHUZ9wvNKtzJ2ZDzSU0boUNBDoJFwpxT32SQGTaD99VDEU5SGUVg== X-Received: by 10.237.37.121 with SMTP id w54mr1963661qtc.14.1489569210505; Wed, 15 Mar 2017 02:13:30 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.140.42.181 with HTTP; Wed, 15 Mar 2017 02:13:29 -0700 (PDT) In-Reply-To: <20170315000326.GO12864@pfrc.org> References: <20170314204212.GD12864@pfrc.org> <815723FC-B143-4410-B0FF-D9FB4F827862@cisco.com> <20170314213607.GH12864@pfrc.org> <20170314214832.s3k37p27y7xfpfsv@Vurt.local> <20170314223333.bw3caxfn34y6zlb7@Vurt.local> <20170314225855.GN12864@pfrc.org> <20170315000326.GO12864@pfrc.org> From: Robert Raszuk Date: Wed, 15 Mar 2017 10:13:29 +0100 X-Google-Sender-Auth: BLkOEVHZz0xHgTBigSRVVGa4IgI Message-ID: To: Jeffrey Haas Cc: idr wg Content-Type: multipart/alternative; boundary=001a1140f782a9206d054ac15bd2 Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 09:13:34 -0000 --001a1140f782a9206d054ac15bd2 Content-Type: text/plain; charset=UTF-8 > This is no worse than an IGP event. Well that in fact brings another alternative ... why not to simply run a separate instance of ISIS over IX open LAN fabric interfaces ? DIS could be on RS and even with basic hellos both RS and remote clients will know about client being unreachable. If someone wants you can run BFD to speed things up as well. That addresses the reported problem without need for RS SAFI and for those who do not want more then single path speeds up connectivity restoration etc ... Even for those who have more then one path if ISIS timers are enough they do not need to run BFD any more to all next hops. Moreover *modern* IX operators will soon start adding value add services (example: DDoS protection) for their customers for a little extra fee per month. That in turn will be much simpler to be deployed with service chain and IGP local flooding of for example SIDs. Has that approach been considered here ? Again just like with data plane gateway proposal this requires zero change on the client side and is just a control plane config touch. Best, r. On Wed, Mar 15, 2017 at 1:03 AM, Jeffrey Haas wrote: > On Wed, Mar 15, 2017 at 12:08:50AM +0100, Robert Raszuk wrote: > > Apart of that the more I think about this the more reasons pop-up which > > question both justification and value in informing RS about next hop > > reachability from clients to clients of Internet Exchanges. > > > > Let's summarize those again: > > > > - RS may not have other paths > > > > - RS may send more then best path to clients > > > > - RS come in pairs and it is trivial to send different paths from each of > > the RS with zero upgrade to clients > > But then you're not using a secondary RS for redundancy of your best path. > (That may be fine.) > > > - RS clients are grouped per their policies .. per client RIB requires a > > lot of overhead on route servers to address the case where only one > client > > in the group suffers from some unreachable next hop > > RS operators will have to speak to what sort of policies they want, but > this > *does* impact what a RS chooses to do with a declaration of unreachability > from one peer in a peer group: > - Does it try to split the group for that peer? (Unrealistic, IMO.) > - Does it de-pref routes with that nexthop for *all* peers on the > presumption that something bad has happened that the other peers haven't > noticed yet? > > Etc. > > Good topic for further discussion. > > > - BFD sessions to next hops will require per next hop MD5 for security > > The use of BFD security mechanisms in general is an interesting question. > Thankfully the suggested BFD timers here are very slow which helps the > session scaling. > > > - IX have often more then one lan ... say 1500 and 9000 MTU. Next hops > > again may be different on both. > > > > - BFD session timers can't be unified on the clients as some clients are > > local and some remote. Remote both in the case of distributed IX as well > as > > in the case of IX customers just connecting to IX with fiber without any > > *local* metal. > > > > - Clients will likely report churn of the same next hop being unreachable > > reasonable in the same time > > A significant enough fabric event will simply lose the peering sessions to > the RS in the first place. But losing entire "sides" of clients happens. > > > - When client reports unreachable next hop to RS .. it removes the path > > from client's RIB. But when does it add it again ? Note eBGP to RS are > all > > fine .. would clients now not only keep BFD sessions to active peers but > > also trying to establish BFD to unreachable peers then notify RS that the > > peer is back ? > > This is no worse than an IGP event. > > > - BFD on clients needs to work in non protocol associated mode. > > > > ... and I am pretty sure this is just the starter. > > And good fodder for discussion from IX operators. > > > > > r. > > > > > > > > > > > > On Tue, Mar 14, 2017 at 11:58 PM, Jeffrey Haas wrote: > > > > > On Tue, Mar 14, 2017 at 11:46:45PM +0100, Robert Raszuk wrote: > > > > And just for the record here the idea for NH SAFI has been proposed > by > > > Ilya > > > > & myself in 2012 ... > > > > > > > > https://tools.ietf.org/html/draft-ietf-idr-bgp-nh-cost-00 > > > > > > rs-bfd started with that as a likely way to handle carrying the RS > state. > > > However, we reached two conclusions: > > > - the draft was inactive. > > > - and even if we used it, it was an awkward fit for the mechanism. > > > > > > https://www.ietf.org/proceedings/93/slides/slides-93-idr-3.pdf > > > > > > Similarly, BGP-LS was given a try and decided to be too heavy weight. > > > > > > So, we're closer to where we started. :-) > > > > > > -- Jeff > > > > --001a1140f782a9206d054ac15bd2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

> This is no worse than a= n IGP event.

Well that in fact= brings another alternative ... why not to simply run a separate instance o= f ISIS over IX open LAN fabric interfaces ?=C2=A0

DIS could be on RS and even with basic hellos both RS and r= emote clients will know about client being unreachable. If someone wants yo= u can run BFD to speed things up as well.=C2=A0

That = addresses the reported problem without need for RS SAFI and for those who d= o not want more then single path speeds up connectivity restoration etc ...= Even for those who have more then one path if ISIS timers are enough they = do not need to run BFD any more to all next hops.=C2=A0

Moreover *modern= * IX operators will soon start adding value add services (example: DDoS pro= tection) for their customers for a little extra fee per month. That in turn= will be much simpler to be deployed with service chain and IGP local flood= ing of for example SIDs.

Has that approach been considered here ? Again = just like with data plane gateway proposal this requires zero change on the= client side and is just a control plane config touch.=C2=A0

Best,
r.
=C2= =A0

On Wed, Mar 15, 2017 at 1:03 AM, Jeffrey Haas &l= t;jhaas@pfrc.org>= ; wrote:
On Wed, = Mar 15, 2017 at 12:08:50AM +0100, Robert Raszuk wrote:
> Apart of that the more I think about this the more reasons pop-up whic= h
> question both justification and value in informing RS about next hop > reachability from clients to clients of Internet Exchanges.
>
> Let's summarize those again:
>
> - RS may not have other paths
>
> - RS may send more then best path to clients
>
> - RS come in pairs and it is trivial to send different paths from each= of
> the RS with zero upgrade to clients

But then you're not using a secondary RS for redundancy of your = best path.
(That may be fine.)

> - RS clients are grouped per their policies .. per client RIB requires= a
> lot of overhead on route servers to address the case where only one cl= ient
> in the group suffers from some unreachable next hop

RS operators will have to speak to what sort of policies they want, = but this
*does* impact what a RS chooses to do with a declaration of unreachability<= br> from one peer in a peer group:
- Does it try to split the group for that peer? (Unrealistic, IMO.)
- Does it de-pref routes with that nexthop for *all* peers on the
=C2=A0 presumption that something bad has happened that the other peers hav= en't
=C2=A0 noticed yet?

Etc.

Good topic for further discussion.

> - BFD sessions to next hops will require per next hop MD5 for security=

The use of BFD security mechanisms in general is an interesting ques= tion.
Thankfully the suggested BFD timers here are very slow which helps the
session scaling.

> - IX have often more then one lan ... say 1500 and 9000 MTU. Next hops=
> again may be different on both.
>
> - BFD session timers can't be unified on the clients as some clien= ts are
> local and some remote. Remote both in the case of distributed IX as we= ll as
> in the case of IX customers just connecting to IX with fiber without a= ny
> *local* metal.
>
> - Clients will likely report churn of the same next hop being unreacha= ble
> reasonable in the same time

A significant enough fabric event will simply lose the peering sessi= ons to
the RS in the first place.=C2=A0 But losing entire "sides" of cli= ents happens.

> - When client reports unreachable next hop to RS .. it removes the pat= h
> from client's RIB. But when does it add it again ? Note eBGP to RS= are all
> fine .. would clients now not only keep BFD sessions to active peers b= ut
> also trying to establish BFD to unreachable peers then notify RS that = the
> peer is back ?

This is no worse than an IGP event.

> - BFD on clients needs to work in non protocol associated mode.
>
> ... and I am pretty sure this is just the starter.

And good fodder for discussion from IX operators.

>
> r.
>
>
>
>
>
> On Tue, Mar 14, 2017 at 11:58 PM, Jeffrey Haas <jhaas@pfrc.org> wrote:
>
> > On Tue, Mar 14, 2017 at 11:46:45PM +0100, Robert Raszuk wrote: > > > And just for the record here the idea for NH SAFI has been p= roposed by
> > Ilya
> > > & myself in 2012 ...
> > >
> > > https://tools.ietf.org/html/= draft-ietf-idr-bgp-nh-cost-00
> >
> > rs-bfd started with that as a likely way to handle carrying the R= S state.
> > However, we reached two conclusions:
> > - the draft was inactive.
> > - and even if we used it, it was an awkward fit for the mechanism= .
> >
> > https://www.ietf.org/pr= oceedings/93/slides/slides-93-idr-3.pdf
> >
> > Similarly, BGP-LS was given a try and decided to be too heavy wei= ght.
> >
> > So, we're closer to where we started. :-)
> >
> > -- Jeff
> >

--001a1140f782a9206d054ac15bd2-- From nobody Wed Mar 15 05:30:38 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 944D5131444 for ; Wed, 15 Mar 2017 05:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9tis5ZFT0GT9 for ; Wed, 15 Mar 2017 05:30:35 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 EA6FF13144E for ; Wed, 15 Mar 2017 05:30:32 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=70.194.2.137; From: "Susan Hares" To: "'Jeffrey Haas'" , "'Dongjie \(Jimmy\)'" Cc: "'idr wg'" References: <76CD132C3ADEF848BD84D028D243C927935B96C0@NKGEML515-MBS.china.huawei.com> <20170315005231.GP12864@pfrc.org> In-Reply-To: <20170315005231.GP12864@pfrc.org> Date: Wed, 15 Mar 2017 08:25:44 -0400 Message-ID: <018601d29d87$4555c380$d0014a80$@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: AQEOUZijZcF8dgqwJOTyHxJsi/GZFwLVN7E7owfAZGA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] IETF98 agenda topics X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 12:30:37 -0000 Jeff: Ack. We've got this request. Agenda will go up shortly. Sue Hares -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jeffrey Haas Sent: Tuesday, March 14, 2017 8:53 PM To: Dongjie (Jimmy) Cc: idr wg; Susan Hares Subject: Re: [Idr] IETF98 agenda topics Jie, On Sat, Mar 11, 2017 at 07:33:38AM +0000, Dongjie (Jimmy) wrote: > IDR will meet at IETF98 on Friday, March 31 from 9:00 to 11:30. Please > forward any IDR agenda items you might have to me and CC the chairs, > the deadline is March 17 by 10:00 U.S. Eastern Time. Priority will be > given to those who get their requests in by the deadline, though if > agenda space permits it we will consider requests gotten in before > March 22 at 10:00 U.S. Eastern Time. Please include the name of the > person who will be presenting, and the estimate time you'll need (including Q/A). We'd like a 10 minute slot for draft-ietf-idr-rs-bfd. We've presented on this before, but the discussion on the list suggests some in-room discussion may be valuable. -- Jeff _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From nobody Wed Mar 15 07:55:14 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B73341315D5 for ; Wed, 15 Mar 2017 07:55:12 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H5SsGg84eBjl for ; Wed, 15 Mar 2017 07:55:10 -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 5D1861315DB for ; Wed, 15 Mar 2017 07:55:10 -0700 (PDT) X-Envelope-To: idr@ietf.org Received: from cupcake.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id v2FEt6Fu077432 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Mar 2017 14:55:07 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be cupcake.local Message-ID: <58C955CA.7040405@foobar.org> Date: Wed, 15 Mar 2017 14:55:06 +0000 From: Nick Hilliard User-Agent: Postbox 5.0.11 (Macintosh/20170302) MIME-Version: 1.0 To: Jeffrey Haas CC: IETF IDR Working Group References: <148924277112.2960.17904473852401253352@ietfa.amsl.com> <58C85ECE.3080109@foobar.org> <20170314214817.GI12864@pfrc.org> In-Reply-To: <20170314214817.GI12864@pfrc.org> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 14:55:13 -0000 Jeffrey Haas wrote: > We had some text in earlier internal versions of the document that tried to > make this explicit. I believe the text that remains is appropriately > permissive but maybe not as explicit as you might like: it's definitely permissive, but sometimes it's good to make things easy for the reader. FWIW, I think you're having some reverse bikeshedding here, and part of the reason is a lack of broad brush strokes to make it easy for the casual reader to follow what's going on in the heads of the authors. > : At the route server, the Adj-NHIB-Out for each client is populated > : with the next hops from its Loc-RIB. If the BGP capabilities learned > : during BGP session setup identify a next hop as compatible with this > : proposal, this is reflected in the NHIB. Initially, it is assumed > : that the client router is able to reach its next hops which is stored > : in the NHIB. If a next hop is added to the NHIB for a particular > : client, a route SHOULD be added to the router server's Adj-NHIB-Out. > > The SHOULD is the relevant point. This didn't make it into the sections for > explicit NHIB behavior, and probably could use some emphasis in a future > revision. > > From the client procedure side: > : If the client can not establish a BFD session with an entry in its > : NHIB, the next hop is put it in the Adj-NHIB-Out for backward > : compatibility. > >> A couple of other things: >> >> 1. if a route server client stops announcing prefixes to the route >> server but still accepts prefixes, do all bfd sessions to it also get >> torn down? Or is the purpose of the RS Adj-NHIB-In to ensure stickiness >> of bfd sessions? If this is the case, it should be mentioned explicitly >> because otherwise the feedback loop looks ... well, a bit peculiar. > > Section 5.2: > > > : In the event that a given client that supports this feature does not > : provide any routes containing BGP next hops that would be used to > : populate an Adj-NHIB-Out entry, the route server SHOULD advertise an > : entry for such a router using the provided self-originated entry. > : This permits the provisioning of BFD peering sessions for continuity > : check when route exchange via the route server is asymmetric and one > : client has routes from a second client, but not vice-versa. Again, to make it easier for the reader, I'd suggest adding in some helicopter-view text to explain the rationale behind this feedback mechanism. It's quite a nice way of handling bfd session stability, btw, but it really is not obvious from a first (or even second) reading what the overall picture is. >> 2. >>> It is incorrect provisioning for an IXP client which >>> is using a Route Server to have a BGP session with another IXP >>> client. >> lolno, if I'm reading this correctly. It's quite usual to have >> bilateral + multilateral sessions configuration between router pairs. > > I suspected the sanity check might bounce here. :-) "This text was included intentionally to see if people were paying attention". > We'll update the wording accordingly. The main consideration is the new > SAFI doesn't get negotiated and start transitively propagating the state. Right, I hadn't considered that. That would cause a pile of hilarity, no doubt about it. > It might be worth adding verbiage about ensuring RS-Reachable SAFI have an > AS_PATH that is consistent with directly connected peers instead. ew, ugly hack. Please don't. Nick From nobody Wed Mar 15 08:13:21 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8235713164C for ; Wed, 15 Mar 2017 08:13: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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PA92xuGknK_k for ; Wed, 15 Mar 2017 08:13:14 -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 07C45131647 for ; Wed, 15 Mar 2017 08:13:13 -0700 (PDT) X-Envelope-To: idr@ietf.org Received: from cupcake.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id v2FFDAFp079568 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Mar 2017 15:13:10 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be cupcake.local Message-ID: <58C95A05.3030107@foobar.org> Date: Wed, 15 Mar 2017 15:13:09 +0000 From: Nick Hilliard User-Agent: Postbox 5.0.11 (Macintosh/20170302) MIME-Version: 1.0 To: Robert Raszuk CC: Jeffrey Haas , idr wg References: <20170314204212.GD12864@pfrc.org> <815723FC-B143-4410-B0FF-D9FB4F827862@cisco.com> <20170314213607.GH12864@pfrc.org> <20170314214832.s3k37p27y7xfpfsv@Vurt.local> <20170314223333.bw3caxfn34y6zlb7@Vurt.local> <20170314225855.GN12864@pfrc.org> <20170315000326.GO12864@pfrc.org> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 15:13:20 -0000 Robert Raszuk wrote: > Has that approach been considered here I have seen people attempt IGPs at IXPs before. It was hilarious. It wasn't intended to be hilarious. Nick From nobody Wed Mar 15 08:25:37 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46FE0131690 for ; Wed, 15 Mar 2017 08:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yv72eIHW3neZ for ; Wed, 15 Mar 2017 08:25:33 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C520113167B for ; Wed, 15 Mar 2017 08:25:32 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id x35so14945699qtc.2 for ; Wed, 15 Mar 2017 08:25:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Ynhybf2VF1LjG+ky0R9IkwjM41OAoXhlIwHJDoECuyY=; b=OF255cE13k48zP6BtZ3NH2Lqn3RpVYuh6hxwjl9FLWiXdo1rF4klRC31vmx5Co2yzY TXE8dAjz5EO/SdAmA/blASFTMP4FaqIzeWEIDp95NPBTgAhazhESPmKW8R2+YBXZGcns XImxW+BPT9E5mbarQef+MKYPDSNhXVuenLxq3lMIM8so9Qb92NwimBp3bE0zYp9sFlMu C+E1Vx0CnGbu7UICSqL/E7Cr/v04uxB/yWbZBswA1JnV9sCkDBdhJg186DCF8ZSsuG8I Wc7fe1wcxt2DmASCwicTtiPhGTqHngEwbrFGeIMNxfwBTKq9H8yq3XBLo6Vt2jk4WFzp CTdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Ynhybf2VF1LjG+ky0R9IkwjM41OAoXhlIwHJDoECuyY=; b=t/vHzSzLipMgJg9GC6EJITXg3CXkQXFR+54NMtgLc4b7mYTwC2hDdfZgQ+A3Y6lnUj yqJwdr2F+AZEcqxYnSuslmwBMcsLPc7EPFuNDqQrN6cu7K/y76zFFJFvX1G4z9z4oSRa yETB3OSwV4jbnfyjBx9Jr0zzWLq49DH3uDvwmDQYVo998TBkhm9tgd0h7jzlBWmZFiRL HVOaaaAnR1s3y7WhpsY7pyuCiXi0dZGzGzpRwPcW896+hFknJ8TSY43qyyqrtqOv9EEc Wer05xiSSbYQWQDqvxvwQiSp4m967uAmQdzCRbDiICmX8syajaPoi3IirXvGdG+5atfG AlKQ== X-Gm-Message-State: AFeK/H1M/iejah2vMIHOSGEiHE8KV3+hAjQkaHzCSK9F5q9fiHOul8jbC/ZZmcmErCGjNEF0ydx0KGFk9zZ7Eg== X-Received: by 10.200.0.25 with SMTP id a25mr3148809qtg.199.1489591531879; Wed, 15 Mar 2017 08:25:31 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.140.42.181 with HTTP; Wed, 15 Mar 2017 08:25:30 -0700 (PDT) In-Reply-To: <58C95A05.3030107@foobar.org> References: <20170314204212.GD12864@pfrc.org> <815723FC-B143-4410-B0FF-D9FB4F827862@cisco.com> <20170314213607.GH12864@pfrc.org> <20170314214832.s3k37p27y7xfpfsv@Vurt.local> <20170314223333.bw3caxfn34y6zlb7@Vurt.local> <20170314225855.GN12864@pfrc.org> <20170315000326.GO12864@pfrc.org> <58C95A05.3030107@foobar.org> From: Robert Raszuk Date: Wed, 15 Mar 2017 16:25:30 +0100 X-Google-Sender-Auth: DGW6ckKuDoX2vdlRq9Na6LMmlWI Message-ID: To: Nick Hilliard Cc: Jeffrey Haas , idr wg Content-Type: multipart/alternative; boundary=f403045e73621e475a054ac68e66 Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 15:25:34 -0000 --f403045e73621e475a054ac68e66 Content-Type: text/plain; charset=UTF-8 Nick, One thing is to try to use IGP to distribute routes. Completely another thing is to use it as topology discovery and next hop liveness signalling. I am talking about the latter ... not the former. On Wed, Mar 15, 2017 at 4:13 PM, Nick Hilliard wrote: > Robert Raszuk wrote: > > Has that approach been considered here > > I have seen people attempt IGPs at IXPs before. It was hilarious. > > It wasn't intended to be hilarious. > > Nick > --f403045e73621e475a054ac68e66 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Nick,

One thing is to try to use IGP to distribute routes. Co= mpletely another thing is to use it as topology discovery and next hop live= ness signalling.=C2=A0

I am talking about the latter ... not the former.=C2=A0


On Wed, Mar 15, 2017 at 4:13 PM, Nick Hilliard <<= a href=3D"mailto:nick@foobar.org" target=3D"_blank">nick@foobar.org>= wrote:
Robert Ra= szuk wrote:
> Has that approach been considered here

I have seen people attempt IGPs at IXPs before.=C2=A0 It was hilario= us.

It wasn't intended to be hilarious.

Nick

--f403045e73621e475a054ac68e66-- From nobody Wed Mar 15 08:29:25 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B506131678 for ; Wed, 15 Mar 2017 08:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VjMzxmixyDOi for ; Wed, 15 Mar 2017 08:29:22 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 9D98313167A for ; Wed, 15 Mar 2017 08:29:22 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 4FBC61E33B; Wed, 15 Mar 2017 11:35:34 -0400 (EDT) Date: Wed, 15 Mar 2017 11:35:34 -0400 From: Jeffrey Haas To: Nick Hilliard Cc: IETF IDR Working Group Message-ID: <20170315153534.GR12864@pfrc.org> References: <148924277112.2960.17904473852401253352@ietfa.amsl.com> <58C85ECE.3080109@foobar.org> <20170314214817.GI12864@pfrc.org> <58C955CA.7040405@foobar.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <58C955CA.7040405@foobar.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 15:29:24 -0000 On Wed, Mar 15, 2017 at 02:55:06PM +0000, Nick Hilliard wrote: > Jeffrey Haas wrote: > > We had some text in earlier internal versions of the document that tried to > > make this explicit. I believe the text that remains is appropriately > > permissive but maybe not as explicit as you might like: > > it's definitely permissive, but sometimes it's good to make things easy > for the reader. FWIW, I think you're having some reverse bikeshedding > here, and part of the reason is a lack of broad brush strokes to make it > easy for the casual reader to follow what's going on in the heads of the > authors. This is more the issue of three different authors wordsmithing the document with different styles. This round had enough bits rewritten that the focus was on correctness rather than ease of reading. Next round will hopefully address that presuming the technical content is accepted. > Again, to make it easier for the reader, I'd suggest adding in some > helicopter-view text to explain the rationale behind this feedback > mechanism. It's quite a nice way of handling bfd session stability, > btw, but it really is not obvious from a first (or even second) reading > what the overall picture is. Agreed. > >> lolno, if I'm reading this correctly. It's quite usual to have > >> bilateral + multilateral sessions configuration between router pairs. > > > > I suspected the sanity check might bounce here. :-) > > "This text was included intentionally to see if people were paying > attention". :-) > > We'll update the wording accordingly. The main consideration is the new > > SAFI doesn't get negotiated and start transitively propagating the state. > > Right, I hadn't considered that. That would cause a pile of hilarity, > no doubt about it. Exactly. This state, for want of better terminology, is session local. However, most implementations of BGP use generic RIB plumbing that makes redistribution a likely accident. > > It might be worth adding verbiage about ensuring RS-Reachable SAFI have an > > AS_PATH that is consistent with directly connected peers instead. > > ew, ugly hack. Please don't. Why not? It's the closest thing we have to "only accept stuff from the adjacent peer". We don't currently have a "verify that no-advertise did its job" feature. -- Jeff From nobody Wed Mar 15 08:42:42 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B28621316BF; Wed, 15 Mar 2017 08:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XgH5R0yUAILL; Wed, 15 Mar 2017 08:42:39 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 0CAC11316B0; Wed, 15 Mar 2017 08:42:38 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=70.194.2.137; From: "Susan Hares" To: "'Jeffrey Haas'" Cc: "'Enke Chen'" , "'idr wg'" , "'Robert Raszuk'" , , References: <01b301d29758$180458e0$480d0aa0$@ndzh.com> <7657b686-0685-9bdf-17ba-e7d618a237aa@cisco.com> <004001d29874$9ed03840$dc70a8c0$@ndzh.com> <20170314225242.GM12864@pfrc.org> In-Reply-To: <20170314225242.GM12864@pfrc.org> Date: Wed, 15 Mar 2017 11:37:56 -0400 Message-ID: <027c01d29da2$1efbd8d0$5cf38a70$@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: AQJNmlyMtg6aifomFjff9yu//s8nwgIjEw3KAqFLPaYCQp+WoQI2iBGKAdk+iIwC04D/CwIGkEf6AU+yhXUBoGKx1QInXlwbn/fKQNA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 15:42:41 -0000 Jeff: I now understand your "wiggle room". We both agree on the FSM actions and that we need operator input on the choices. 1) Open Message < 4096 - hold while at BGP version 4 [This can be held at the Open Message header tests (event 22)] While all other MESSAGES > 4096 if open capability for extended messages. 2) all Messages at > 4096 - with BGP version 5 (no capability negotiation) 3) Open Message < 4096 - with BGP version 4 + Dynamic Capabilities All other BGP-4 messages > 4096 if Open capability for extended messages 4) Update message only at > 4096 if Open capability for extended messages Did I miss an open? If not, I will open a request for feedback on IDR, and add this to the grow request for input. Sue Hares -----Original Message----- From: Jeffrey Haas [mailto:jhaas@pfrc.org] Sent: Tuesday, March 14, 2017 6:53 PM To: Susan Hares Cc: 'Enke Chen'; 'idr wg'; 'Robert Raszuk'; idr-chairs@ietf.org; draft-ietf-idr-bgp-extended-messages@ietf.org Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20 Sue, On Wed, Mar 08, 2017 at 08:29:37PM -0500, Susan Hares wrote: > Caveat - I am not commenting on operational issues. If your brief > comment denotes some operational issues, I would appreciate a longer > description on-list or off-list. > > If you are comment on the functionality within the RFC4271 FSM, I am > not sure why the "wiggle room is reduced when the open message size is changed"? > I have been specific on this list as to the functionality a message > header length error enacts (Event 21) versus an Open Message Header enacts (Event > 22). Please be as specific in your response if it is a FSM issues. This is to some extent a simple issue with regard to extended and non-extended speakers trying to interoperate. However, the version case with the changes under discussion complicate the matter slightly. Presume old RFC 4271 speaker, O. Presume new extended message speaker E. If E sends an open message > 4096 octets to O, the generally expected behavior is that O will send a notification message with a Bad Message Length subcode. O has no reason to change its behavior. E may have course note this specific error and try to back-off, if possible to a <= 4096 message size. However, I tend to agree with other threads that we're better off blocking the peering session from coming up without further intervention. I am *not* a supporter of deferring the larger Open operations to another message; we'd be better off getting something like Dynamic Capabilities working and we've had a number of discussions about why some of that behavior is problematic. (Alternatively, we simply have the extended open message, but that's a bit of a change in the FSM.) So... why did I bring up the version negotiation point? Mostly because for version negotiation to work, once we leave -4 behind, we need to be able to generate an Unsupported Version Number error. We can't do that if the receiver simply dumps the session due to hitting the message length validation failure first. As I mention too tersely in my response... oh well. But it does mean that if we go with > 4k open messages that old speakers will only get upset about PDUs that are too big rather than giving us other useful information about why session negotiation is failing. I suspect this is fine, but it should be a choice that is clearly understood. -- Jeff From nobody Wed Mar 15 08:59:26 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC051316A4 for ; Wed, 15 Mar 2017 08:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VHyIUOp_gvba for ; Wed, 15 Mar 2017 08:59:23 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 E035A13166D for ; Wed, 15 Mar 2017 08:59:22 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=70.194.2.137; From: "Susan Hares" To: "'Jeffrey Haas'" , "'Job Snijders'" Cc: "'idr wg'" References: <03ae01d29c3e$6c5d87a0$451896e0$@ndzh.com> <20170314193036.GC12864@pfrc.org> <20170314223916.GL12864@pfrc.org> In-Reply-To: <20170314223916.GL12864@pfrc.org> Date: Wed, 15 Mar 2017 11:54:39 -0400 Message-ID: <02b101d29da4$7454af30$5cfe0d90$@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: AQIgYy6xumBx4YeN0V40xjwsD29naAICzufFAT/VB6ADKYzHQqDHH02Q Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] draft-hares-deprecate-atomic-aggregate (was Re: Request for 2 drafts) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 15:59:24 -0000 Jeff: +1 to your problems on changing. Conformance tools can be changed, but operators (Data Center, IXP, Enterprise, Carrier) need to buy into upgrades to tools and re-testing all BGPs. Thank you for revealing your tortured past below. I'm sure you should be a co-author on any history for Atomic Aggregation (sounds radioactive). (Smile. ) Sue -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jeffrey Haas Sent: Tuesday, March 14, 2017 6:39 PM To: Job Snijders Cc: idr wg Subject: Re: [Idr] draft-hares-deprecate-atomic-aggregate (was Re: Request for 2 drafts) On Tue, Mar 14, 2017 at 11:07:54PM +0100, Job Snijders wrote: > Isn't the path to deprecate a poorly understood feature ("poorly" as > in ugly, that there is a disconnect between expectations), to just.. > deprecate it? I'd welcome historic perspective in such a deprecation > document for newcomers, it would be helpful for my edification to > learn of the rise and fall of a protocol complications. This is one of those things I'd love to say "it's nice on principle" but usually get followed by "but the consequences are a bit ugly". Deprecating means largely "don't do that". You now have to deal with all of the consequences of those things that still do that or expect such to be done. BGP changes are all about incremental rollout headache after all. Implementations will still be required to understand the attribute and minimally to ignore it. This means you don't really get rid of much code there. Conformance tools will still probe for what we do for things and have to be revised to not flag as non-conformant an implementation that doesn't pass the attribute along if it's been set. Or that it's added if the as-path is truncated or otherwise incomplete. And while deaggregation isn't typically done automatically by routers, it's still good to signal that doing so may be a bad idea. I'll let you dig out your favorite deaggregation traffic shaping tool presentation from the *NOG of your choice. So, the benefits don't really outweigh the consequence of leaving it in. If we'd been having this conversation as part of trying to get 1771 style AA semantics working right[1], I might have had a somewhat different opinion. > However I don't see a compelling reason in itself to not touch 4271, > for the purpose of touching 4271. There have been a number of updates > to 4271 over the years, and compliant implementations need to continue > to monitor IETF documents to remain complaint, right? See above. > In context of internet-wide EBGP operations I'd view both aggregation > (aggregation through snipping globally unique ASNs from the as_path) > as well as de-aggregation as most unwelcome. At this point especially > de-aggregation is real threat to the DFZ, stuff like > http://bgpmon.net/bgp-optimizer-causes-thousands-of-fake-routes/ comes > to mind. See above. (I generally agree.) It's also likely to get worse. > Is there a legitimate use case for keeping atomic aggregate around? if > not, we should clean up. > > I'm usually in favour of deleting things that are not used. You're also not the one that gets the bug reports from this sort of thing. :-) At best, I'll acknowledge your network won't fall over from it not showing up the few times it actually does in the DFZ these days. -- Jeff [1] As part of Sue's crash course to how to participate in the IETF process, I was encouraged to try to work out issues we'd found in our implementation of the specification (draft-ietf-idr-bgp4-XX) on the mailing list. As part of working through inconsistencies in the text regarding how AA was set, I tried to contact our venerable authors on BGP to get them to work through those inconsistencies with me. Being busy at startups, most didn't respond. This left a rather inexperienced protocols implementor trying to intuit "what is this thing for?" and supplying various bits of text toward the draft to try to rectify the discrepancies. It turns out that if done using the intent of 1771 and earlier, AA would be set on *most* things, especially when policy was involved. However, discovering this set of things resulted in at least 3 churns of the draft. Eventually that was overcome by the realization that this is an appendix, in the anatomy sense; a vestigial organ. It's mostly useful to prevent auto-deaggregation in implementations that were transitioning from the classful BGP-3 to CIDR BGP-4. Such things didn't seem to be common even back in the day, and the transition from -3 to -4 seemed to take very little time across the backbones. What eventually remained was "this is a good idea to signal truncation or loss of information from the as-path" in the event that deaggregation would happen. While gross, people did and still do it. And even otherwise, having it as a handy note that "information was lost" during aggregation is still handy.[2] Having lost most of the crazy text about the rules with which you set AA based on what you learned, we now have a relatively quiet feature that's easy to implement with some minor operational benefit. This exercise in archaeology was my first, and a lingering introduction to Internet standards. I've almost foriven my second introduction, which involved SNMP. [2] An interesting side effect of extened UPDATES in our other thread will be that aggregation that results in sets from gateD family software will mean we have even LONGER AS_SETs today than before. While such implementations support "brief" aggregation, the transitional behavior of a long AS_SET on a extended message speaker to a 4k speaker will make for an interesting edge and conformance case. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From nobody Wed Mar 15 09:09:16 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84CCA1316DF for ; Wed, 15 Mar 2017 09:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.947 X-Spam-Level: X-Spam-Status: No, score=0.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NfRKhH1oKyY8 for ; Wed, 15 Mar 2017 09:09:13 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 C3B421316B7 for ; Wed, 15 Mar 2017 09:09:12 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=70.194.2.137; From: "Susan Hares" To: "'Job Snijders'" , "'Jeffrey Haas'" , "'idr wg'" References: <03ae01d29c3e$6c5d87a0$451896e0$@ndzh.com> <20170314193036.GC12864@pfrc.org> In-Reply-To: Date: Wed, 15 Mar 2017 11:47:59 -0400 Message-ID: <028b01d29da3$85fb8890$91f299b0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_028C_01D29D81.FEEAD2F0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIgYy6xumBx4YeN0V40xjwsD29naAICzufFAT/VB6Cg4Gk50A== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] draft-hares-deprecate-atomic-aggregate (was Re: Request for 2 drafts) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 16:09:14 -0000 This is a multipart message in MIME format. ------=_NextPart_000_028C_01D29D81.FEEAD2F0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Job and Jeff:=20 =20 Thank you for the feedback. You are having the same conversation I had = with myself about deprecate. After IETF97, I came down on the side of = =E2=80=9Cgetting rid of features that do not exist=E2=80=9D. If we are = going to a BGP version 5, this would be one of the things we would get = rid of. I=E2=80=99d like to hear more from other people. =20 =20 Job - I=E2=80=99m happy to work with you on such a document that = provides history for atomic-aggregate since I was in the original = discussions. I will start a document and we can discuss it at IETF 98 = prior to publishing. =20 =20 Sue=20 =20 From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Job Snijders Sent: Tuesday, March 14, 2017 6:08 PM To: Jeffrey Haas; idr wg Subject: Re: [Idr] draft-hares-deprecate-atomic-aggregate (was Re: = Request for 2 drafts) =20 =20 On Tue, 14 Mar 2017 at 20:24, Jeffrey Haas wrote: Sue, On Mon, Mar 13, 2017 at 05:11:45PM -0400, Susan Hares wrote: > I'd like to follow-up on our "clean up" the attribute area discussion. > > I've published: [...] > > draft-hares-deprecate-atomic-aggregate-00 I'd actually recommend against outright deprecating AA. Mostly it'll = lead to confusion of compliant implementations of 1771/4271 without a lot of benefit. A significant amount of the controversy around the feature while standardizing 4271 had to do with the rules by which AA was attached to routes. I suspect very few people besides Tony Li ever had a strong = opinion about the behavior, especially once we got beyond the BGP-3 transition. (And I wasn't there at the time. The Tony observation is driven mostly = by him popping up a few years ago with a proposal that included AA = behavior.) The current behavior of 4271 with regard to AA is pretty mild: If you're dropping out ASes from the path as part of aggregation, you SHOULD add = this thing. If you see it, don't de-aggregate. People generally don't de-aggregate magically these days and those who = do generally expect to have to be very careful. The document that I thought was worth writing at some point, even if it = only was a draft and never got published, was a short discussion about the = origin of the feature, what its original intent was, what was broken about its original rules to be attached and why we ended up where we did. This is arguably a history document intending to document a rather ugly bit of living history that confuses newcomers to the protocol. I'm happy to contribute to such a document. But I don't recommend we proceed down the path to deprecation. =20 Hi Jeff, =20 Isn't the path to deprecate a poorly understood feature ("poorly" as in = ugly, that there is a disconnect between expectations), to just.. = deprecate it? I'd welcome historic perspective in such a deprecation = document for newcomers, it would be helpful for my edification to learn = of the rise and fall of a protocol complications. =20 However I don't see a compelling reason in itself to not touch 4271, for = the purpose of touching 4271. There have been a number of updates to = 4271 over the years, and compliant implementations need to continue to = monitor IETF documents to remain complaint, right?=20 =20 In context of internet-wide EBGP operations I'd view both aggregation = (aggregation through snipping globally unique ASNs from the as_path) as = well as de-aggregation as most unwelcome. At this point especially = de-aggregation is real threat to the DFZ, stuff like = http://bgpmon.net/bgp-optimizer-causes-thousands-of-fake-routes/ comes = to mind. =20 Is there a legitimate use case for keeping atomic aggregate around? if = not, we should clean up. =20 I'm usually in favour of deleting things that are not used. =20 Kind regards, =20 Job =20 ------=_NextPart_000_028C_01D29D81.FEEAD2F0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Job and Jeff:

 

Thank you for the feedback.=C2=A0 You are having the same = conversation I had with myself about deprecate.=C2=A0 After IETF97, I = came down on the side of =E2=80=9Cgetting rid of features that do not = exist=E2=80=9D. =C2=A0=C2=A0If we are going to a BGP version 5, this = would be one of the things we would get rid of.=C2=A0 =C2=A0I=E2=80=99d = like to hear more from other people.=C2=A0

 

Job - I=E2=80=99m happy to work with you on such a document that = provides history for atomic-aggregate since I was in the original = discussions. =C2=A0=C2=A0I will start a document and we can discuss it = at IETF 98 prior to publishing. =C2=A0

 

Sue

 

From:= = Idr [mailto:idr-bounces@ietf.org] On Behalf Of Job = Snijders
Sent: Tuesday, March 14, 2017 6:08 PM
To: = Jeffrey Haas; idr wg
Subject: Re: [Idr] = draft-hares-deprecate-atomic-aggregate (was Re: Request for 2 = drafts)

 

 

On = Tue, 14 Mar 2017 at 20:24, Jeffrey Haas <jhaas@pfrc.org> = wrote:

Sue,

On Mon, Mar 13, 2017 at 05:11:45PM -0400, = Susan Hares wrote:
> I'd like to follow-up on our "clean = up" the attribute area discussion.
>
> I've = published:
[...]
>
> = draft-hares-deprecate-atomic-aggregate-00

I'd actually recommend = against outright deprecating AA.  Mostly it'll lead
to confusion = of compliant implementations of 1771/4271 without a lot = of
benefit.

A significant amount of the controversy around the = feature while
standardizing 4271 had to do with the rules by which AA = was attached to
routes.  I suspect very few people besides Tony = Li ever had a strong opinion
about the behavior, especially once we = got beyond the BGP-3 transition.
(And I wasn't there at the = time.  The Tony observation is driven mostly by
him popping up a = few years ago with a proposal that included AA behavior.)

The = current behavior of 4271 with regard to AA is pretty mild: If = you're
dropping out ASes from the path as part of aggregation, you = SHOULD add this
thing.  If you see it, don't = de-aggregate.

People generally don't de-aggregate magically these = days and those who do
generally expect to have to be very = careful.

The document that I thought was worth writing at some = point, even if it only
was a draft and never got published, was a = short discussion about the origin
of the feature, what its original = intent was, what was broken about its
original rules to be attached = and why we ended up where we did.  This is
arguably a history = document intending to document a rather ugly bit of
living history = that confuses newcomers to the protocol.

I'm happy to contribute = to such a document.  But I don't recommend we
proceed down the = path to deprecation.

 

Hi Jeff,

 

Isn't the path to deprecate a poorly understood = feature ("poorly" as in ugly, that there is a disconnect = between expectations), to just.. deprecate it? I'd welcome historic = perspective in such a deprecation document for newcomers, it would be = helpful for my edification to learn of the rise and fall of a protocol = complications.

 

However I don't see a compelling reason in itself to = not touch 4271, for the purpose of touching 4271. There have been a = number of updates to 4271 over the years, and compliant implementations = need to continue to monitor IETF documents to remain complaint, = right? 

 

In context of internet-wide EBGP operations I'd view = both aggregation (aggregation through snipping globally unique ASNs from = the as_path) as well as de-aggregation as most unwelcome. At this point = especially de-aggregation is real threat to the DFZ, stuff like http://bgpmon.net/bgp-optimizer-causes-thousands-of-fake-routes/ = comes to mind.

 

Is there a legitimate use case for keeping atomic = aggregate around? if not, we should clean = up.

 

I'm usually in favour of deleting things that are not = used.

 

Kind regards,

 

Job

 

------=_NextPart_000_028C_01D29D81.FEEAD2F0-- From nobody Wed Mar 15 11:16:50 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DDAE131778 for ; Wed, 15 Mar 2017 11:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3VjWO2dIXCt8 for ; Wed, 15 Mar 2017 11:16:47 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id A8EB1131774 for ; Wed, 15 Mar 2017 11:16:47 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 9F9101E33B; Wed, 15 Mar 2017 14:22:59 -0400 (EDT) Date: Wed, 15 Mar 2017 14:22:59 -0400 From: Jeffrey Haas To: Susan Hares Cc: 'Job Snijders' , 'idr wg' Message-ID: <20170315182259.GS12864@pfrc.org> References: <03ae01d29c3e$6c5d87a0$451896e0$@ndzh.com> <20170314193036.GC12864@pfrc.org> <20170314223916.GL12864@pfrc.org> <02b101d29da4$7454af30$5cfe0d90$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <02b101d29da4$7454af30$5cfe0d90$@ndzh.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Idr] draft-hares-deprecate-atomic-aggregate (was Re: Request for 2 drafts) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 18:16:49 -0000 On Wed, Mar 15, 2017 at 11:54:39AM -0400, Susan Hares wrote: > Thank you for revealing your tortured past below. I'm sure you should be > a co-author on any history for Atomic Aggregation (sounds radioactive). I've had challenging work and good teachers. We could discuss whether you'd rather repurpose the deprecate draft for history in Chicago. :-) -- Jeff From nobody Wed Mar 15 12:44:42 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEE121317F5 for ; Wed, 15 Mar 2017 12:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WEIQKlNEg9Iz for ; Wed, 15 Mar 2017 12:44:38 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id CF1CC13177F for ; Wed, 15 Mar 2017 12:44:38 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id B05891E33B; Wed, 15 Mar 2017 15:50:50 -0400 (EDT) Date: Wed, 15 Mar 2017 15:50:50 -0400 From: Jeffrey Haas To: Nick Hilliard Cc: Robert Raszuk , idr wg Message-ID: <20170315195050.GT12864@pfrc.org> References: <20170314213607.GH12864@pfrc.org> <20170314214832.s3k37p27y7xfpfsv@Vurt.local> <20170314223333.bw3caxfn34y6zlb7@Vurt.local> <20170314225855.GN12864@pfrc.org> <20170315000326.GO12864@pfrc.org> <58C95A05.3030107@foobar.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <58C95A05.3030107@foobar.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 19:44:40 -0000 On Wed, Mar 15, 2017 at 03:13:09PM +0000, Nick Hilliard wrote: > Robert Raszuk wrote: > > Has that approach been considered here > > I have seen people attempt IGPs at IXPs before. It was hilarious. > > It wasn't intended to be hilarious. The reasons for the hilarity might not be obvious to some here. Some of them include: - Effectively an NBMA environment that most software wants to pick up as a broadcast environment... and the protocols break when the L2 goes awry. - IXPs tend to get a rather entertaining mish-mash of equipment... and thus bugs. - IGPs really like to have a consistent map and aren't happy when the LSDB isn't consistent for various reasons. (See some above.) - Security of IGP with multiple participant? Um, no. Please share others. :-) -- Jeff From nobody Wed Mar 15 13:09:15 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD6A413181A for ; Wed, 15 Mar 2017 13:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PNIS_yZj_ZsP for ; Wed, 15 Mar 2017 13:09:13 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 146F0131815 for ; Wed, 15 Mar 2017 13:09:13 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id 1so22815388qkl.3 for ; Wed, 15 Mar 2017 13:09:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=zsWd633OrnIazCQicLTT/9Ojo+agNLNvLxap3BwA3dM=; b=cdedwEwcdbmJRRYWgw2Y6lip3RgHp81cuoqr28iUy9x+qgf5KatJXzHKAcRDuPK6qq B1MTwVLP/MG4X0fz+LF5mz+UQj6JW9TjATAqaLixY9SmE4eOS2RfFJNuPCO3P2oPJbz0 /xyGNTxmBlu4QUHRzXNbK93Dbz+udJZnHPSUrLqCfuS8GYsG7eVoVFE6ns2iWzdAmvZa d459yGsAbUtyQlthR8mESJQUUfMEkiwY4xqPJcOsFl67gPyrpiDcd1LF1iQT2FAUTQ08 pAM/GgYO+SOX8dNEH89uzvxgFM5BhbNJfkRorxP9nK/o2M4HbzESWWWS2WJxufoORykG LNsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=zsWd633OrnIazCQicLTT/9Ojo+agNLNvLxap3BwA3dM=; b=groFYyyQpizgYzwufNpZ+NK1lifPzbjLYZSscwzWFllSEA7ZPfqSvn5EdYfJO4mVLJ ZeGy7JNT+21+ui3n0ss2AjfuL/7gb1XGw78Hs+yXKFH8/bWlkhp1x9cPLQMmY7jZ/YMH 606MkhQKgQRWGKfDZ4KFcpDt0ffphEuc6gCpIUfiwrEwNe2iOx5W6dUlUPxOLECmuJZM gOljEeAHR9zT2HAT7q4Fqa3mCT855XZBbM9yj08iRtaunydJ0FNwR1AvX2rbeea5hB6V 56WrMoAJ+fo8ayV6PtSChAuDwj/K+7XRkXYyIn9cLMcyIo9PGk7rFo2XM3ktTvvuOm2S datw== X-Gm-Message-State: AFeK/H1BBcb1xp/HZa5qecMdtVPfrROoZUDmSCxMn1nzAPGfMk/SqmSlb7rA3SmcNQ4pTpsFO+8wi12SLIJXhA== X-Received: by 10.55.65.136 with SMTP id o130mr4393161qka.168.1489608552241; Wed, 15 Mar 2017 13:09:12 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.140.42.181 with HTTP; Wed, 15 Mar 2017 13:09:11 -0700 (PDT) In-Reply-To: <20170315195050.GT12864@pfrc.org> References: <20170314213607.GH12864@pfrc.org> <20170314214832.s3k37p27y7xfpfsv@Vurt.local> <20170314223333.bw3caxfn34y6zlb7@Vurt.local> <20170314225855.GN12864@pfrc.org> <20170315000326.GO12864@pfrc.org> <58C95A05.3030107@foobar.org> <20170315195050.GT12864@pfrc.org> From: Robert Raszuk Date: Wed, 15 Mar 2017 21:09:11 +0100 X-Google-Sender-Auth: aCGKKA66BBI_jTDO7Y2L4BE5Xhg Message-ID: To: Jeffrey Haas Cc: Nick Hilliard , idr wg Content-Type: multipart/alternative; boundary=001a11488ce49c620b054aca84a3 Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 20:09:15 -0000 --001a11488ce49c620b054aca84a3 Content-Type: text/plain; charset=UTF-8 > - IXPs tend to get a rather entertaining mish-mash of equipment... and thus bugs. + > Please enlighten yourself what people use "as peering router" today :-) While this is GROW question ... perhaps it would be very helpful to get some more real data on what type of routers customers of the IX use to peer within IX ? Why such equipment is considered at best as 2nd class citizen ? For my BB IX peerings I would in fact put the best routers to peer outside of my network on the edge - not just some junk or homebrew bgp/igp. It is anyway interesting that now fear of IGP bugs is used a motivation for BGP protocol extension. My personal problem with proposed RS SAFI is that it delays even further both RS support and IX operators support for ability to send multiple paths to me as client of the IX. And I need those multiple paths for already stated reasons. One would hope that we learn something from years of PIC experience ... Regards, Robert. --001a11488ce49c620b054aca84a3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


>= - IXPs tend to get a rather entertaining mish-mash of equipment... and thu= s=C2= =A0bugs.
+=C2=A0
>=C2=A0Please enlighten yourself what people use "as peering= router" today :-)


While this is GROW question ... perhaps = it would be very helpful to get some more real data on what type of routers= customers of the IX use to peer within IX ? Why such equipment is consider= ed at best as 2nd class citizen ?=C2=A0

For my BB IX peerings I would in= fact put the best routers to peer outside of my network on the edge - not = just some junk or homebrew bgp/igp.=C2=A0

It is anyway interesting that now fear of IGP bugs is used a mo= tivation for BGP protocol extension.

=
My personal problem with proposed RS SAF= I is that it delays even further both RS support and IX operators support f= or ability to send multiple paths to me as client of the IX. And I need tho= se multiple paths for already stated reasons.=C2=A0

One would hope that we le= arn something from years of PIC experience ...=C2=A0

Regards,
Robert.


--001a11488ce49c620b054aca84a3-- From nobody Wed Mar 15 13:17:04 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B145913181F for ; Wed, 15 Mar 2017 13:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.419 X-Spam-Level: X-Spam-Status: No, score=-1.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ciscodude-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qivB_xx_qA4t for ; Wed, 15 Mar 2017 13:17:00 -0700 (PDT) Received: from mail-it0-f52.google.com (mail-it0-f52.google.com [209.85.214.52]) (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 483F613181A for ; Wed, 15 Mar 2017 13:17:00 -0700 (PDT) Received: by mail-it0-f52.google.com with SMTP id g138so27216719itb.0 for ; Wed, 15 Mar 2017 13:17:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ciscodude-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=iRk3ku0okqtZ90COKEzDoN/elY8IjETYBJxoHLmv2UU=; b=nAE+wOiJ6YERE8zGKIpB7wWMiteuI1PggD6HrwGEG2DZSsOSWLKjqqE4DWiaj/Xjvz W6eUMYW02z391IqIpIsZLMFMNrnvu0+wbmqzuC4Fwjp15T7NUQEdw4gthx4N1PZzR5rv sSCauU8cRkAxS4CNb1ngn5pmXP0oyRICB12OtQfip22DqEdIQS1k/+Ejgc/S5TF2zJFE NvjqnltQLXBbtmJCkefcyO6sEMKmIoQ77POgih6HC68bf3Kw9pAeKVyUhtEPTWNt8Egz L5taML84AKq8Wg2fnoR38Mycuk2rS9sm/acY2lFNgRiszattrOiZtD/CVnB+qA1rTot1 27pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=iRk3ku0okqtZ90COKEzDoN/elY8IjETYBJxoHLmv2UU=; b=UhjxV7HJ+OIxGwxbJRVO2X3lxGjM3Ew8PWbt62yadnQLTCr530IjcAov5NN7AKxmYH Q71MeX2xuC220L9A8+YWphVX2YxJbdqIIub5BLi1s6LHMTgoUe3mJKolDk63c6twksS7 mg0TDNCqe2iOS2IzfqnkbOAS2AuO/nESHV1+tbowq1waGZHNWoDu2ZdShN0TSRUPFEtX gEhyJ95Md6KJakikfrpLmrdCJYpjAaYi9l8OC0pi+B5c9n+yUI6U/Xqt67OsTORt9vn8 EwEIc7vNT/DzYkiF3axwM9DjgaFk3zi6NoZxrZ+E3SC71xA2glDU0tTfnUEos3uXnRKH 4x4g== X-Gm-Message-State: AFeK/H2m/keOrvZE5D+f6iar+/Z4JPdCmzGADNbid4nf8lcI7AbCLeYWIukNqbn0kdSoPw== X-Received: by 10.36.25.1 with SMTP id b1mr21702429itb.86.1489608959316; Wed, 15 Mar 2017 13:15:59 -0700 (PDT) Received: from octocat.ciscodude.co (out-nat.ciscodude.net. [192.160.102.248]) by smtp.gmail.com with ESMTPSA id g103sm1946500iod.44.2017.03.15.13.15.57 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 15 Mar 2017 13:15:58 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_9EE84703-504D-48D3-A537-38382720F212" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Theodore Baschak In-Reply-To: <028b01d29da3$85fb8890$91f299b0$@ndzh.com> Date: Wed, 15 Mar 2017 15:15:54 -0500 Cc: Job Snijders , Jeffrey Haas , idr wg Message-Id: <92934AA6-B2C6-4C99-BD47-555717955079@ciscodude.net> References: <03ae01d29c3e$6c5d87a0$451896e0$@ndzh.com> <20170314193036.GC12864@pfrc.org> <028b01d29da3$85fb8890$91f299b0$@ndzh.com> To: Susan Hares X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Idr] draft-hares-deprecate-atomic-aggregate (was Re: Request for 2 drafts) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 20:17:03 -0000 --Apple-Mail=_9EE84703-504D-48D3-A537-38382720F212 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The big incumbent Telco in my area, AS7122, went from overboard on = de-aggregation (several /16's advertised as /16+/19's + /24's +/32's) to = overboard on aggregation, using the atomic aggregate attribute.=20 Overnight on 2015-09-13 AS7122 enabled atomic aggregate for all blocks, = despite having 6 downstreams advertising /24's and whatnot from those = blocks. Just coincidentally, none of those downstreams were multi-homed = at the time so no one noticed anything and there was no pushback. = However, now some of these ASNs have been wanting to multi-home and will = have trouble doing so because their one path will now be squashed in a = atomic aggregate. Theodore Baschak - AS395089 - Hextet Systems https://bgp.guru/ - https://hextet.net/ http://mbix.ca/ - http://mbnog.ca/ > On Mar 15, 2017, at 10:47 AM, Susan Hares wrote: >=20 > Job and Jeff:=20 > =20 > Thank you for the feedback. You are having the same conversation I = had with myself about deprecate. After IETF97, I came down on the side = of =E2=80=9Cgetting rid of features that do not exist=E2=80=9D. If we = are going to a BGP version 5, this would be one of the things we would = get rid of. I=E2=80=99d like to hear more from other people. =20 > =20 > Job - I=E2=80=99m happy to work with you on such a document that = provides history for atomic-aggregate since I was in the original = discussions. I will start a document and we can discuss it at IETF 98 = prior to publishing. =20 > =20 > Sue=20 > =20 > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Job Snijders > Sent: Tuesday, March 14, 2017 6:08 PM > To: Jeffrey Haas; idr wg > Subject: Re: [Idr] draft-hares-deprecate-atomic-aggregate (was Re: = Request for 2 drafts) > =20 > =20 > On Tue, 14 Mar 2017 at 20:24, Jeffrey Haas > wrote: >> Sue, >>=20 >> On Mon, Mar 13, 2017 at 05:11:45PM -0400, Susan Hares wrote: >> > I'd like to follow-up on our "clean up" the attribute area = discussion. >> > >> > I've published: >> [...] >> > >> > draft-hares-deprecate-atomic-aggregate-00 >>=20 >> I'd actually recommend against outright deprecating AA. Mostly it'll = lead >> to confusion of compliant implementations of 1771/4271 without a lot = of >> benefit. >>=20 >> A significant amount of the controversy around the feature while >> standardizing 4271 had to do with the rules by which AA was attached = to >> routes. I suspect very few people besides Tony Li ever had a strong = opinion >> about the behavior, especially once we got beyond the BGP-3 = transition. >> (And I wasn't there at the time. The Tony observation is driven = mostly by >> him popping up a few years ago with a proposal that included AA = behavior.) >>=20 >> The current behavior of 4271 with regard to AA is pretty mild: If = you're >> dropping out ASes from the path as part of aggregation, you SHOULD = add this >> thing. If you see it, don't de-aggregate. >>=20 >> People generally don't de-aggregate magically these days and those = who do >> generally expect to have to be very careful. >>=20 >> The document that I thought was worth writing at some point, even if = it only >> was a draft and never got published, was a short discussion about the = origin >> of the feature, what its original intent was, what was broken about = its >> original rules to be attached and why we ended up where we did. This = is >> arguably a history document intending to document a rather ugly bit = of >> living history that confuses newcomers to the protocol. >>=20 >> I'm happy to contribute to such a document. But I don't recommend we >> proceed down the path to deprecation. > =20 > Hi Jeff, > =20 > Isn't the path to deprecate a poorly understood feature ("poorly" as = in ugly, that there is a disconnect between expectations), to just.. = deprecate it? I'd welcome historic perspective in such a deprecation = document for newcomers, it would be helpful for my edification to learn = of the rise and fall of a protocol complications. > =20 > However I don't see a compelling reason in itself to not touch 4271, = for the purpose of touching 4271. There have been a number of updates to = 4271 over the years, and compliant implementations need to continue to = monitor IETF documents to remain complaint, right?=20 > =20 > In context of internet-wide EBGP operations I'd view both aggregation = (aggregation through snipping globally unique ASNs from the as_path) as = well as de-aggregation as most unwelcome. At this point especially = de-aggregation is real threat to the DFZ, stuff like = http://bgpmon.net/bgp-optimizer-causes-thousands-of-fake-routes/ = comes = to mind. > =20 > Is there a legitimate use case for keeping atomic aggregate around? if = not, we should clean up. > =20 > I'm usually in favour of deleting things that are not used. > =20 > Kind regards, > =20 > Job > =20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr --Apple-Mail=_9EE84703-504D-48D3-A537-38382720F212 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The big incumbent Telco in my area, AS7122, went from = overboard on de-aggregation (several /16's advertised as /16+/19's + = /24's +/32's) to overboard on aggregation, using the atomic aggregate = attribute. 

Overnight on 2015-09-13 AS7122 enabled atomic aggregate for = all blocks, despite having 6 downstreams advertising /24's and whatnot = from those blocks. Just coincidentally, none of those downstreams were = multi-homed at the time so no one noticed anything and there was no = pushback. However, now some of these ASNs have been wanting to = multi-home and will have trouble doing so because their one path will = now be squashed in a atomic aggregate.


Theodore Baschak - AS395089 - = Hextet Systems
https://bgp.guru/ - https://hextet.net/
http://mbix.ca/ - http://mbnog.ca/

On Mar 15, 2017, at 10:47 AM, Susan Hares <shares@ndzh.com> = wrote:

Job and Jeff: 
 
Thank you for the = feedback.  You are having the same conversation I had with myself = about deprecate.  After IETF97, I came down on the side of = =E2=80=9Cgetting rid of features that do not exist=E2=80=9D. =   If we are going to a BGP version 5, this would be one of the = things we would get rid of.   I=E2=80=99d like to hear more = from other people.  
 
Job - I=E2=80=99m happy = to work with you on such a document that provides history for = atomic-aggregate since I was in the original discussions.   I = will start a document and we can discuss it at IETF 98 prior to = publishing.  
 
Sue 
 
From: Idr [mailto:idr-bounces@ietf.org] On Behalf = Of Job Snijders
Sent: Tuesday, March 14, 2017 = 6:08 PM
To: Jeffrey Haas; idr wg
Subject: Re: [Idr] = draft-hares-deprecate-atomic-aggregate (was Re: Request for 2 = drafts)
 
 
On = Tue, 14 Mar 2017 at 20:24, Jeffrey Haas <jhaas@pfrc.org> = wrote:
Sue,

On Mon, Mar 13, 2017 at = 05:11:45PM -0400, Susan Hares wrote:
> I'd like to = follow-up on our "clean up" the attribute area discussion.
>
> I've published:
[...]
>
> = draft-hares-deprecate-atomic-aggregate-00

I'd= actually recommend against outright deprecating AA.  Mostly it'll = lead
to confusion of compliant implementations of = 1771/4271 without a lot of
benefit.

A significant amount of the controversy around the feature = while
standardizing 4271 had to do with the rules by which = AA was attached to
routes.  I suspect very few people = besides Tony Li ever had a strong opinion
about the = behavior, especially once we got beyond the BGP-3 transition.
(And I wasn't there at the time.  The Tony observation = is driven mostly by
him popping up a few years ago with a = proposal that included AA behavior.)

The = current behavior of 4271 with regard to AA is pretty mild: If you're
dropping out ASes from the path as part of aggregation, you = SHOULD add this
thing.  If you see it, don't = de-aggregate.

People generally don't = de-aggregate magically these days and those who do
generally= expect to have to be very careful.

The = document that I thought was worth writing at some point, even if it = only
was a draft and never got published, was a short = discussion about the origin
of the feature, what its = original intent was, what was broken about its
original = rules to be attached and why we ended up where we did.  This is
arguably a history document intending to document a rather = ugly bit of
living history that confuses newcomers to the = protocol.

I'm happy to contribute to such a = document.  But I don't recommend we
proceed down the = path to deprecation.
 
Hi Jeff,
 
Isn't the path to deprecate a poorly understood = feature ("poorly" as in ugly, that there is a disconnect between = expectations), to just.. deprecate it? I'd welcome historic perspective = in such a deprecation document for newcomers, it would be helpful for my = edification to learn of the rise and fall of a protocol = complications.
 
However I don't see a compelling reason in itself to = not touch 4271, for the purpose of touching 4271. There have been a = number of updates to 4271 over the years, and compliant implementations = need to continue to monitor IETF documents to remain complaint, = right? 
 
In context of internet-wide EBGP operations I'd view = both aggregation (aggregation through snipping globally unique ASNs from = the as_path) as well as de-aggregation as most unwelcome. At this point = especially de-aggregation is real threat to the DFZ, stuff like http://bgpmon.net/bgp-optimizer-causes-thousands-of-fake-routes= / comes to = mind.
 
Is there a legitimate use case for keeping = atomic aggregate around? if not, we should clean up.
 
I'm usually in favour of deleting things = that are not used.
 
Kind regards,
 
Job
 
_______________________________________________
Idr mailing = list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

= --Apple-Mail=_9EE84703-504D-48D3-A537-38382720F212-- From nobody Wed Mar 15 14:11:28 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6CE6131849 for ; Wed, 15 Mar 2017 14:11:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.947 X-Spam-Level: X-Spam-Status: No, score=0.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9wymEpqTlbr for ; Wed, 15 Mar 2017 14:11:24 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 3A6F513184E for ; Wed, 15 Mar 2017 14:11:20 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=70.194.2.137; From: "Susan Hares" To: "'Theodore Baschak'" Cc: "'idr wg'" References: <03ae01d29c3e$6c5d87a0$451896e0$@ndzh.com> <20170314193036.GC12864@pfrc.org> <028b01d29da3$85fb8890$91f299b0$@ndzh.com> <92934AA6-B2C6-4C99-BD47-555717955079@ciscodude.net> In-Reply-To: <92934AA6-B2C6-4C99-BD47-555717955079@ciscodude.net> Date: Wed, 15 Mar 2017 17:06:15 -0400 Message-ID: <048201d29dcf$fc5648f0$f502dad0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0483_01D29DAE.754963E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIgYy6xumBx4YeN0V40xjwsD29naAICzufFAT/VB6ACVCgSKwIJiBaToL3WZAA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] draft-hares-deprecate-atomic-aggregate (was Re: Request for 2 drafts) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 21:11:27 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0483_01D29DAE.754963E0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the report. This is useful information =E2=80=93 sounds = like the atomic aggregate caused some real problems. =20 Do you know what the telco will do if we pull atomic aggregate?=20 =20 Sue=20 =20 From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Theodore Baschak Sent: Wednesday, March 15, 2017 4:16 PM To: Susan Hares Cc: idr wg Subject: Re: [Idr] draft-hares-deprecate-atomic-aggregate (was Re: = Request for 2 drafts) =20 The big incumbent Telco in my area, AS7122, went from overboard on = de-aggregation (several /16's advertised as /16+/19's + /24's +/32's) to = overboard on aggregation, using the atomic aggregate attribute.=20 =20 Overnight on 2015-09-13 AS7122 enabled atomic aggregate for all blocks, = despite having 6 downstreams advertising /24's and whatnot from those = blocks. Just coincidentally, none of those downstreams were multi-homed = at the time so no one noticed anything and there was no pushback. = However, now some of these ASNs have been wanting to multi-home and will = have trouble doing so because their one path will now be squashed in a = atomic aggregate. =20 Theodore Baschak - AS395089 - Hextet Systems https://bgp.guru/ - https://hextet.net/ http://mbix.ca/ - http://mbnog.ca/ =20 On Mar 15, 2017, at 10:47 AM, Susan Hares wrote: =20 Job and Jeff:=20 =20 Thank you for the feedback. You are having the same conversation I had = with myself about deprecate. After IETF97, I came down on the side of = =E2=80=9Cgetting rid of features that do not exist=E2=80=9D. If we are = going to a BGP version 5, this would be one of the things we would get = rid of. I=E2=80=99d like to hear more from other people. =20 =20 Job - I=E2=80=99m happy to work with you on such a document that = provides history for atomic-aggregate since I was in the original = discussions. I will start a document and we can discuss it at IETF 98 = prior to publishing. =20 =20 Sue=20 =20 From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Job Snijders Sent: Tuesday, March 14, 2017 6:08 PM To: Jeffrey Haas; idr wg Subject: Re: [Idr] draft-hares-deprecate-atomic-aggregate (was Re: = Request for 2 drafts) =20 =20 On Tue, 14 Mar 2017 at 20:24, Jeffrey Haas < = jhaas@pfrc.org> wrote: Sue, On Mon, Mar 13, 2017 at 05:11:45PM -0400, Susan Hares wrote: > I'd like to follow-up on our "clean up" the attribute area discussion. > > I've published: [...] > > draft-hares-deprecate-atomic-aggregate-00 I'd actually recommend against outright deprecating AA. Mostly it'll = lead to confusion of compliant implementations of 1771/4271 without a lot of benefit. A significant amount of the controversy around the feature while standardizing 4271 had to do with the rules by which AA was attached to routes. I suspect very few people besides Tony Li ever had a strong = opinion about the behavior, especially once we got beyond the BGP-3 transition. (And I wasn't there at the time. The Tony observation is driven mostly = by him popping up a few years ago with a proposal that included AA = behavior.) The current behavior of 4271 with regard to AA is pretty mild: If you're dropping out ASes from the path as part of aggregation, you SHOULD add = this thing. If you see it, don't de-aggregate. People generally don't de-aggregate magically these days and those who = do generally expect to have to be very careful. The document that I thought was worth writing at some point, even if it = only was a draft and never got published, was a short discussion about the = origin of the feature, what its original intent was, what was broken about its original rules to be attached and why we ended up where we did. This is arguably a history document intending to document a rather ugly bit of living history that confuses newcomers to the protocol. I'm happy to contribute to such a document. But I don't recommend we proceed down the path to deprecation. =20 Hi Jeff, =20 Isn't the path to deprecate a poorly understood feature ("poorly" as in = ugly, that there is a disconnect between expectations), to just.. = deprecate it? I'd welcome historic perspective in such a deprecation = document for newcomers, it would be helpful for my edification to learn = of the rise and fall of a protocol complications. =20 However I don't see a compelling reason in itself to not touch 4271, for = the purpose of touching 4271. There have been a number of updates to = 4271 over the years, and compliant implementations need to continue to = monitor IETF documents to remain complaint, right?=20 =20 In context of internet-wide EBGP operations I'd view both aggregation = (aggregation through snipping globally unique ASNs from the as_path) as = well as de-aggregation as most unwelcome. At this point especially = de-aggregation is real threat to the DFZ, stuff like = = http://bgpmon.net/bgp-optimizer-causes-thousands-of-fake-routes/ comes = to mind. =20 Is there a legitimate use case for keeping atomic aggregate around? if = not, we should clean up. =20 I'm usually in favour of deleting things that are not used. =20 Kind regards, =20 Job =20 _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr =20 ------=_NextPart_000_0483_01D29DAE.754963E0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Thanks for the report.=C2=A0=C2=A0 This is useful information = =E2=80=93 sounds like the atomic aggregate caused some real problems. = =C2=A0=C2=A0

Do you know what the telco will do if we pull atomic aggregate? =

 

Sue

 

From:= = Idr [mailto:idr-bounces@ietf.org] On Behalf Of Theodore = Baschak
Sent: Wednesday, March 15, 2017 4:16 PM
To: = Susan Hares
Cc: idr wg
Subject: Re: [Idr] = draft-hares-deprecate-atomic-aggregate (was Re: Request for 2 = drafts)

 

The big = incumbent Telco in my area, AS7122, went from overboard on = de-aggregation (several /16's advertised as /16+/19's + /24's +/32's) to = overboard on aggregation, using the atomic aggregate = attribute. 

 

Overnight on 2015-09-13 AS7122 enabled atomic = aggregate for all blocks, despite having 6 downstreams advertising /24's = and whatnot from those blocks. Just coincidentally, none of those = downstreams were multi-homed at the time so no one noticed anything and = there was no pushback. However, now some of these ASNs have been wanting = to multi-home and will have trouble doing so because their one path will = now be squashed in a atomic aggregate.

 


Theodore Baschak - AS395089 - Hextet Systems
https://bgp.guru/ - https://hextet.net/
http://mbix.ca/ - http://mbnog.ca/

 

On Mar 15, 2017, at 10:47 AM, Susan Hares <shares@ndzh.com> = wrote:

 

Job and Jeff: 

 

Thank you for the feedback.  You are having the same = conversation I had with myself about deprecate.  After IETF97, I = came down on the side of =E2=80=9Cgetting rid of features that do not = exist=E2=80=9D.   If we are going to a BGP version 5, this = would be one of the things we would get rid of.   I=E2=80=99d = like to hear more from other people.  

 

Job - I=E2=80=99m happy to work with you on such a document that = provides history for atomic-aggregate since I was in the original = discussions.   I will start a document and we can discuss it = at IETF 98 prior to publishing. =  

 

Sue 

 

From:=  Idr [mailto:idr-bounces@ietf.org] On Behalf Of Job = Snijders
Sent: Tuesday, March 14, 2017 6:08 = PM
To: Jeffrey = Haas; idr wg
Subject: Re: [Idr] = draft-hares-deprecate-atomic-aggregate (was Re: Request for 2 = drafts)

 

 

On Tue, 14 Mar 2017 at 20:24, Jeffrey Haas <jhaas@pfrc.org> = wrote:

Sue,

On Mon, Mar 13, 2017 at = 05:11:45PM -0400, Susan Hares wrote:
> I'd like to follow-up on = our "clean up" the attribute area discussion.
>
> = I've published:
[...]
>
> = draft-hares-deprecate-atomic-aggregate-00

I'd actually recommend = against outright deprecating AA.  Mostly it'll lead
to confusion = of compliant implementations of 1771/4271 without a lot = of
benefit.

A significant amount of the controversy around the = feature while
standardizing 4271 had to do with the rules by which AA = was attached to
routes.  I suspect very few people besides Tony = Li ever had a strong opinion
about the behavior, especially once we = got beyond the BGP-3 transition.
(And I wasn't there at the = time.  The Tony observation is driven mostly by
him popping up a = few years ago with a proposal that included AA behavior.)

The = current behavior of 4271 with regard to AA is pretty mild: If = you're
dropping out ASes from the path as part of aggregation, you = SHOULD add this
thing.  If you see it, don't = de-aggregate.

People generally don't de-aggregate magically these = days and those who do
generally expect to have to be very = careful.

The document that I thought was worth writing at some = point, even if it only
was a draft and never got published, was a = short discussion about the origin
of the feature, what its original = intent was, what was broken about its
original rules to be attached = and why we ended up where we did.  This is
arguably a history = document intending to document a rather ugly bit of
living history = that confuses newcomers to the protocol.

I'm happy to contribute = to such a document.  But I don't recommend we
proceed down the = path to deprecation.

 

Hi Jeff,

 

Isn't the path to deprecate a poorly understood = feature ("poorly" as in ugly, that there is a disconnect = between expectations), to just.. deprecate it? I'd welcome historic = perspective in such a deprecation document for newcomers, it would be = helpful for my edification to learn of the rise and fall of a protocol = complications.

 

However I don't see a compelling reason in itself to = not touch 4271, for the purpose of touching 4271. There have been a = number of updates to 4271 over the years, and compliant implementations = need to continue to monitor IETF documents to remain complaint, = right? 

 

In context of internet-wide EBGP operations I'd view = both aggregation (aggregation through snipping globally unique ASNs from = the as_path) as well as de-aggregation as most unwelcome. At this point = especially de-aggregation is real threat to the DFZ, stuff like http://bgpmon.net/bgp-optimizer-causes-thousands-o= f-fake-routes/ comes to = mind.

 

Is there a legitimate use case for keeping atomic = aggregate around? if not, we should clean = up.

 

I'm usually in favour of deleting things that are not = used.

 

Kind regards,

 

Job

 

__________= _____________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/m= ailman/listinfo/idr

 

------=_NextPart_000_0483_01D29DAE.754963E0-- From nobody Wed Mar 15 14:27:06 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E08401317E5 for ; Wed, 15 Mar 2017 14:27:04 -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, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPFJ_jIwATDP for ; Wed, 15 Mar 2017 14:27:02 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (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 E87F5131830 for ; Wed, 15 Mar 2017 14:26:58 -0700 (PDT) X-Original-To: idr@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id A207A6028E for ; Wed, 15 Mar 2017 22:26:56 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 629226010D; Wed, 15 Mar 2017 22:26:56 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id 544C617924; Wed, 15 Mar 2017 22:26:56 +0100 (CET) Date: Wed, 15 Mar 2017 22:26:56 +0100 From: Gert Doering To: Robert Raszuk Cc: Jeffrey Haas , idr wg Message-ID: <20170315212656.GD2367@Space.Net> References: <20170314223333.bw3caxfn34y6zlb7@Vurt.local> <20170314225855.GN12864@pfrc.org> <20170315000326.GO12864@pfrc.org> <58C95A05.3030107@foobar.org> <20170315195050.GT12864@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 21:27:05 -0000 Hi, On Wed, Mar 15, 2017 at 09:09:11PM +0100, Robert Raszuk wrote: > > - IXPs tend to get a rather entertaining mish-mash of equipment... and > thus bugs. > + > > Please enlighten yourself what people use "as peering router" today :-) > > While this is GROW question ... perhaps it would be very helpful to get > some more real data on what type of routers customers of the IX use to peer > within IX ? Why such equipment is considered at best as 2nd class citizen ? "What people can afford, and which can barely keep up with the demand". So, you'll still find Cisco Sup720 or Juniper MX80 as peering routers - reliable workhorses as far as forwarding capacity is concerned, but CPU starved (= keep the number of BGP sessions down if you want any semblance of stability), and unfortunately also with centralized BFD (at least on the Cisco). > For my BB IX peerings I would in fact put the best routers to peer outside > of my network on the edge - not just some junk or homebrew bgp/igp. If you keep buying "best of breed" boxes every 3 years, while the competition keeps chugging along with half the CAPEX needed, your customers will wander over, and you'll have to reconsider. For a "smallish" ISP over here, a "fat pipe" to an IXP is 10Gbit/s or maybe 20 Gbit/s - so if you need to by a US$ 50k router for that, every 3 years, it does quite add to the peering costs. We typically have budget to forklift IXP routers every 8-10 years... bandwidth growth isn't that fast anymore, so "nice and shiny" today will be "old and crappy" in 6 years, but as long as it keeps working, it will be kept around. It's not like "peering routers are treated second-class", more like "the market expects that this all costs nothing" - so *inside* the networks, "proper routers" get replaced by "dumb and fast" P-routers with little/no BGP, to save even more CAPEX. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Wed Mar 15 14:58:19 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 842E8129C25 for ; Wed, 15 Mar 2017 14:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wHzSt-pUTssW for ; Wed, 15 Mar 2017 14:58:16 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::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 4B4E6129C0E for ; Wed, 15 Mar 2017 14:58:16 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id v127so25073173qkb.2 for ; Wed, 15 Mar 2017 14:58:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=h1Z4zjT5rGxYQTJlG+DHI4GgVrrn8Y5Ent9RwbLk2uA=; b=kfvSvNOPPiOlIG3Po1+PkqlM7JWesxm9MjMojclcy3xHaCFLS2qWAqH8z9KvN+qzXv +x7vwDOHcOdqw8UaTUCfaDnixfJyFD9uB1TwmosikHBkyPocRWx7ly7C39dK8qHd5kHH 7oNn9alxt1rKgLw4+t9gR2juz3xPLp/8TefhX+dYZn5fDyn++HO9Lfph08XExetkrcoL kqVkH8quRAaFD0Xvdf/iwkhl6K1yEEYMGCLmzc6g39IWiiXCPW52tuipTJzDHVJ8CZgU 7b4EnJEpNThYL9XSHAOXLiG3q+45It4ZE5NM5nlQiGpN7Bj5Z22LpMgY7pfZA/1l+nL4 Q4lA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=h1Z4zjT5rGxYQTJlG+DHI4GgVrrn8Y5Ent9RwbLk2uA=; b=NJhOUWVjDCU70e/n+uZazkbvBZN4IGyFL7gu4MNx0ngkmOkw1Llaivb3p3Ar6bvHjM umNZWeBL7jDFoF+f89wpFb9R5dsvRdFz/sH5jhJKdsw24rXUxQ3h/jl2qtJ2DspJ2frY qoDoHzFNlMRzLMVwIxRwOA7QHFeGtSMtbDn+I2fdS58nVrnzZiii+/641yG6b3KFqwjD n2jxiv0UhVpd/p/FYClb8CKj1t2HYcQJ+IeHitXgvlujvFlAG7PDBFWTw+18anY1rQmI Ob8f8xb+vYPEA9xogVS7rIJy1YYYvP/SSgmFOc0xQtqSCYloV8CvGcEYoKDjIuV3qHjm FScw== X-Gm-Message-State: AFeK/H2ffvY5d51GRlhcvh3q+X5mxDZHFbIREhr25t+W7HXpRM0bN7ZWjsqahJUr3zGbmVBK3hyzZ4n3VXqshg== X-Received: by 10.55.128.66 with SMTP id b63mr5524316qkd.297.1489615095273; Wed, 15 Mar 2017 14:58:15 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.140.42.181 with HTTP; Wed, 15 Mar 2017 14:58:14 -0700 (PDT) In-Reply-To: <20170315212656.GD2367@Space.Net> References: <20170314223333.bw3caxfn34y6zlb7@Vurt.local> <20170314225855.GN12864@pfrc.org> <20170315000326.GO12864@pfrc.org> <58C95A05.3030107@foobar.org> <20170315195050.GT12864@pfrc.org> <20170315212656.GD2367@Space.Net> From: Robert Raszuk Date: Wed, 15 Mar 2017 22:58:14 +0100 X-Google-Sender-Auth: 0WXlMjxAF5t0mfURf-Na59RWMqo Message-ID: To: Gert Doering Cc: Jeffrey Haas , idr wg Content-Type: multipart/alternative; boundary=94eb2c06654c9b53f4054acc0ac2 Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 21:58:18 -0000 --94eb2c06654c9b53f4054acc0ac2 Content-Type: text/plain; charset=UTF-8 Thank you Gert for the info ! Like Job observed for some customers peering to/via IX is just an additional optimization hence indeed some may not always put most expensive and latest gear there. Actually after this discussion I am quite curious how many nets on the routes servers really have more then one bgp path. If not much then this entire effort here may not be practically useful. Now if you say that the equipment is rather dated on the customer edge how and when do you think it will get upgraded with brand new images (provided it is not already EOE/EOL) to even support what is being discussed here ? Shouldn't we at least try to come up with solutions which require no new upgrades for IX customers ? At most few lines of configuration of existing equipment ? Cheers, r. On Wed, Mar 15, 2017 at 10:26 PM, Gert Doering wrote: > Hi, > > On Wed, Mar 15, 2017 at 09:09:11PM +0100, Robert Raszuk wrote: > > > - IXPs tend to get a rather entertaining mish-mash of equipment... and > > thus bugs. > > + > > > Please enlighten yourself what people use "as peering router" today :-) > > > > While this is GROW question ... perhaps it would be very helpful to get > > some more real data on what type of routers customers of the IX use to > peer > > within IX ? Why such equipment is considered at best as 2nd class > citizen ? > > "What people can afford, and which can barely keep up with the demand". > > So, you'll still find Cisco Sup720 or Juniper MX80 as peering routers - > reliable workhorses as far as forwarding capacity is concerned, but CPU > starved (= keep the number of BGP sessions down if you want any > semblance of stability), and unfortunately also with centralized BFD > (at least on the Cisco). > > > > For my BB IX peerings I would in fact put the best routers to peer > outside > > of my network on the edge - not just some junk or homebrew bgp/igp. > > If you keep buying "best of breed" boxes every 3 years, while the > competition keeps chugging along with half the CAPEX needed, your > customers will wander over, and you'll have to reconsider. > > For a "smallish" ISP over here, a "fat pipe" to an IXP is 10Gbit/s or > maybe 20 Gbit/s - so if you need to by a US$ 50k router for that, > every 3 years, it does quite add to the peering costs. > > We typically have budget to forklift IXP routers every 8-10 years... > bandwidth growth isn't that fast anymore, so "nice and shiny" today > will be "old and crappy" in 6 years, but as long as it keeps working, > it will be kept around. > > > It's not like "peering routers are treated second-class", more like > "the market expects that this all costs nothing" - so *inside* the > networks, "proper routers" get replaced by "dumb and fast" P-routers > with little/no BGP, to save even more CAPEX. > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > --94eb2c06654c9b53f4054acc0ac2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Thank you = Gert for the info !

Li= ke Job observed for some customers peering to/via IX is just an additional = optimization hence indeed some may not always put most expensive and latest= gear there.=C2=A0

Act= ually after this discussion I am quite curious how many nets on the routes = servers really have more then one bgp path. If not much then this entire ef= fort here may not be practically useful.=C2=A0

=
Now if you say that the equipment is rather dated = on the customer edge how and when do you think it will get upgraded with br= and new images (provided it is not already EOE/EOL) to even support what is= being discussed here ? Shouldn't we at least try to come up with solut= ions which require no new upgrades for IX customers ? At most few lines of = configuration of existing equipment ?=C2=A0

Cheers,
r.


On Wed, Mar 15, 2017 at 10:26 PM, Gert Doering <gert@space.net= > wrote:
Hi,

On Wed, Mar 15, 2017 at 09:09:11PM +0100, Robert Raszuk wrote:
> > - IXPs tend to get a rather entertaining mish-mash of equipment..= . and
> thus bugs.
> +
> > Please enlighten yourself what people use "as peering router= " today :-)
>
> While this is GROW question ... perhaps it would be very helpful to ge= t
> some more real data on what type of routers customers of the IX use to= peer
> within IX ? Why such equipment is considered at best as 2nd class citi= zen ?

"What people can afford, and which can barely keep up with the = demand".

So, you'll still find Cisco Sup720 or Juniper MX80 as peering routers -=
reliable workhorses as far as forwarding capacity is concerned, but CPU
starved (=3D keep the number of BGP sessions down if you want any
semblance of stability), and unfortunately also with centralized BFD
(at least on the Cisco).


> For my BB IX peerings I would in fact put the best routers to peer out= side
> of my network on the edge - not just some junk or homebrew bgp/igp.
If you keep buying "best of breed" boxes every 3 years, wh= ile the
competition keeps chugging along with half the CAPEX needed, your
customers will wander over, and you'll have to reconsider.

For a "smallish" ISP over here, a "fat pipe" to an IXP = is 10Gbit/s or
maybe 20 Gbit/s - so if you need to by a US$ 50k router for that,
every 3 years, it does quite add to the peering costs.

We typically have budget to forklift IXP routers every 8-10 years...
bandwidth growth isn't that fast anymore, so "nice and shiny"= today
will be "old and crappy" in 6 years, but as long as it keeps work= ing,
it will be kept around.


It's not like "peering routers are treated second-class", mor= e like
"the market expects that this all costs nothing" - so *inside* th= e
networks, "proper routers" get replaced by "dumb and fast&qu= ot; P-routers
with little/no BGP, to save even more CAPEX.

Gert Doering
=C2=A0 =C2=A0 =C2=A0 =C2=A0 -- NetMaster
--
have you enabled IPv6 on something today...?

SpaceNet AG=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Aufsichtsratsvo= rs.: A. Grundner-Culemann
D-80807 Muenchen=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0HRB: 136055 (AG Muenchen)
Tel: = +49 (0)89/32356-444=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0USt-IdNr.: = DE813185279

--94eb2c06654c9b53f4054acc0ac2-- From nobody Wed Mar 15 15:15:42 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EF84129C31 for ; Wed, 15 Mar 2017 15:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5GhU09MdApJq for ; Wed, 15 Mar 2017 15:15:39 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 C6E99129C2A for ; Wed, 15 Mar 2017 15:15:38 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=70.194.2.137; From: "Susan Hares" To: "'idr wg'" Date: Wed, 15 Mar 2017 18:10:48 -0400 Message-ID: <04f701d29dd9$007f1c00$017d5400$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_04F8_01D29DB7.796F77D0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdKd2GEzcBfPwNajTSuziYb8Pa1RJg== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [Idr] IDR Agenda online X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 22:15:41 -0000 This is a multipart message in MIME format. ------=_NextPart_000_04F8_01D29DB7.796F77D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The IDR agenda is online for IETF 98. If you requested a slot, please verify that you are on the agenda. If we missed something, that's probably my fault and not Jie Dong's. If you have not request a slot, send the request ASAP. We'll try to accommodate, but we can only squeeze 1-2 more Into the agenda. Please send presentations to Jie Dong and the chairs. Jie Dong will be contacting each of the presentors to get your slides. Bruno Decraene gets the prize for the 1st presentation sent in. Sue Hares ------=_NextPart_000_04F8_01D29DB7.796F77D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The IDR = agenda is online for IETF 98.

 

If you = requested a slot, please verify that you are on the agenda. =

If we missed something, that’s = probably my fault and not Jie Dong’s.

 

If you have = not request a slot, send the request ASAP.

We’ll try to accommodate, but we can only = squeeze 1-2 more

Into the = agenda. 

 

Please send = presentations to Jie Dong and the chairs.

Jie Dong will be contacting each of the presentors to = get your slides.

 

Bruno = Decraene gets the prize for the 1st presentation sent = in. 

 

Sue Hares

 

------=_NextPart_000_04F8_01D29DB7.796F77D0-- From nobody Wed Mar 15 15:23:04 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9DF129C47 for ; Wed, 15 Mar 2017 15:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=instituut-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AoJw-LvltGkw for ; Wed, 15 Mar 2017 15:22:59 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::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 00317129C49 for ; Wed, 15 Mar 2017 15:22:58 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id n11so34164771wma.0 for ; Wed, 15 Mar 2017 15:22:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9kcXqXYmlQYLQbGshGk6QAEaMWxogO/WSjF6rRXYy/w=; b=iYi68UwIJzhjn7F4GefglT+6kDFSIhVtJIsZrjvtKjMbdQJAymAfYY6yD6LyNMPNLp vBfLUGCicDHIHjJZNkynmRE2bQLQDVdqFNHxDDrGh3MZL5O0LVMJB/+qRj/zPb76MkEV 15ioRp7gRb1wi4q1j0wlv3w8oMd+vTh/2npCxr8L0OVQiMhRFD+EtOEeSX7RXOLT7q5u tNNca4FvJuzeWrY03zJr3un4Sl+xrg+OJ+H2yZB/s0y4nR2M3IiTYwJQepADWrgPSB1O UhsMTEw70pW/WvXPMIGh1boLVP5HzLZOFOe55N1nJ9BnXfhPxj6BZHlLi7TfzMQn9BnJ X0LA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9kcXqXYmlQYLQbGshGk6QAEaMWxogO/WSjF6rRXYy/w=; b=Cp9cLHFOqP5dHTH+yVux7M5P+Y+AzaHK46r0LjVJ0iwnYvJ3Hgc5cQeRO34hO9xpXJ BLGLCepb0HSdHl44G/uJdahulcDXReWoMUB7ApuOtOlQWq2lFL/Hqbq5H1igb+WqncjS va2/vvkquv/ZjdUDQMTvYIpn183+A0ZYStJDw6TLr6onepS3rv6euYhq7GNH5j17qqvq Fdc38v9Q6+TEmJ7dT8aFq9kJnhnd0lgLUKyLn4C+pQyDOnXT9yl9LZw0ExDNIBuVIG3y Be8y5Pa0ZT3Qe5F0HXr/sMJL0MizDpzfb0OL50bFnIpqdms1bj9Uh67fmSuhytbhgheK Qdbw== X-Gm-Message-State: AFeK/H2b62ZcQF6RyditYFo8LOgqE5KXcIZ+QTTos0Ud96Nme77DFsn3CpfTIQdzH8CV+3UD6o6LafeYPZxkfA== X-Received: by 10.28.187.68 with SMTP id l65mr6336604wmf.24.1489616577329; Wed, 15 Mar 2017 15:22:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.182.162 with HTTP; Wed, 15 Mar 2017 15:22:56 -0700 (PDT) X-Originating-IP: [192.147.168.22] In-Reply-To: References: <20170314223333.bw3caxfn34y6zlb7@Vurt.local> <20170314225855.GN12864@pfrc.org> <20170315000326.GO12864@pfrc.org> <58C95A05.3030107@foobar.org> <20170315195050.GT12864@pfrc.org> <20170315212656.GD2367@Space.Net> From: Job Snijders Date: Wed, 15 Mar 2017 23:22:56 +0100 Message-ID: To: Gert Doering , Robert Raszuk Cc: idr wg Content-Type: multipart/alternative; boundary=001a114b09dcf1974d054acc6240 Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 22:23:02 -0000 --001a114b09dcf1974d054acc6240 Content-Type: text/plain; charset=UTF-8 On Wed, 15 Mar 2017 at 22:58, Robert Raszuk wrote: > Like Job observed for some customers peering to/via IX is just an > additional optimization hence indeed some may not always put most expensive > and latest gear there. > > Actually after this discussion I am quite curious how many nets on the > routes servers really have more then one bgp path. If not much then this > entire effort here may not be practically useful. > Did some small crude sampling by asking around: AMS-IX RS indicated that one out of three routes have an alternative path DE-CIX RS 1 out of 2 routes have an alternative path INEX RS seemed to have virtually no alternative paths for the routes Kind regards, Job --001a114b09dcf1974d054acc6240 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wed, 15 Mar 2017 at= 22:58, Robert Raszuk <robert@raszuk.net> wrote:
=
Like Job observed f= or some customers peering to/via IX is just an additional optimization henc= e indeed some may not always put most expensive and latest gear there.=C2= =A0

Actually after this discussion I am quite c= urious how many nets on the routes servers really have more then one bgp pa= th. If not much then this entire effort here may not be practically useful.= =C2=A0

Did some small crude sam= pling by asking around:

AMS-IX RS indicated t= hat one out of three routes have an alternative path
DE-CIX= RS 1 out of 2 routes have an alternative path=C2=A0
INEX RS seem= ed to have virtually no alternative paths for the routes

=
Kind regards,

Job
--001a114b09dcf1974d054acc6240-- From nobody Wed Mar 15 15:38:37 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 448EF129C34 for ; Wed, 15 Mar 2017 15:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7eiiYcvu9vb6 for ; Wed, 15 Mar 2017 15:38:33 -0700 (PDT) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::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 ADBB9129C2B for ; Wed, 15 Mar 2017 15:38:33 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id i34so24771283qtc.0 for ; Wed, 15 Mar 2017 15:38:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=GdYkXGKDaqqWj613yzyknoNzfVlEpFXaI2JfZgRNqPk=; b=mndPwrFqDL59o/gB67edwwPbvYN+kSyUjXVUoIc64iT94zOvYZROEUPi1j89idzYQy Bl4LQtbHuOro1ZSgT1iSe+N+An/VWFyv+h7s7sluaEdkCSpTnzVyv7XqcqMRQaHxmUc9 1UPJeuX/jcmjcYPSzmLjf4QFVqYOQ0Nm0N2g8a0ySHoJBFS27rxBjFbhOwr563WeKnhs 2WmqO0prQRi1nYCpkUGXYZogWViYfKBbjbqE0L5VIDLj/iE9e4jTs36atgbUOT5cp3Dr mO++euTAC/CEpXpC+kXROTCHrB+VqNxEIXMzPj/bvNF2FACCygauRwlHpKZu+3JzDxXR cmng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=GdYkXGKDaqqWj613yzyknoNzfVlEpFXaI2JfZgRNqPk=; b=KqldsLSvMcXuSdl17uEiCthk10McvPAAXbPQYxqXrlbLrV1p0VPjsSU4YR3cFxS9Ol 8qjUCA8gGUiVZVjbjsiJr37kvxVE+C34p/MKDV7bII1jaSTq2ptyguPf6FADy0CMxi+8 m+91TkZErPSEIiUvgEBYJC73HbRVIc2Rma5xtYgRTjVPUYC+2jrAkeQS43VjaJZvwihV mBdJMcORBaBmnknl3u4+rQDNjrz2dBKzZPKUbEudq7yI7KTet/QqlKHgOdQldr27itlN MTEH1cUVyrEAADItmKn2lr7uNIiqbBL1YQivQXJ27zaD7smD1VH9yeuMYm5h183I1vIk 66yw== X-Gm-Message-State: AFeK/H01TN3+a38WBBQpTEC6lCG9owr4iHSuJjjNRKXMLdv/hXV4jp0BzOwAOKqtzw33bfNOzcEeg7Ivyb/Y5A== X-Received: by 10.200.0.25 with SMTP id a25mr5012048qtg.199.1489617512743; Wed, 15 Mar 2017 15:38:32 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.140.42.181 with HTTP; Wed, 15 Mar 2017 15:38:31 -0700 (PDT) In-Reply-To: References: <20170314223333.bw3caxfn34y6zlb7@Vurt.local> <20170314225855.GN12864@pfrc.org> <20170315000326.GO12864@pfrc.org> <58C95A05.3030107@foobar.org> <20170315195050.GT12864@pfrc.org> <20170315212656.GD2367@Space.Net> From: Robert Raszuk Date: Wed, 15 Mar 2017 23:38:31 +0100 X-Google-Sender-Auth: uXg85LyOYYPDwdEQXrjNj-b-jBA Message-ID: To: Job Snijders Cc: Gert Doering , idr wg Content-Type: multipart/alternative; boundary=f403045e7362b2d9a1054acc9a65 Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 22:38:35 -0000 --f403045e7362b2d9a1054acc9a65 Content-Type: text/plain; charset=UTF-8 Thank you Job ! So this means that every third or second customer in first two IXes respectively connect to exchange with at least two edge routers or it could be the same CE router with two interfaces :). Now this also means that each such edge router is connecting to both independent route servers. Based on the above just making sure that those two route servers pick paths with different next hop as best may already address the problem to improve robustness with just putting only a negligible additional load on the customer edge keeping current hardware and software as is. Kind regards, Robert. On Wed, Mar 15, 2017 at 11:22 PM, Job Snijders wrote: > > On Wed, 15 Mar 2017 at 22:58, Robert Raszuk wrote: > >> Like Job observed for some customers peering to/via IX is just an >> additional optimization hence indeed some may not always put most expensive >> and latest gear there. >> >> Actually after this discussion I am quite curious how many nets on the >> routes servers really have more then one bgp path. If not much then this >> entire effort here may not be practically useful. >> > > Did some small crude sampling by asking around: > > AMS-IX RS indicated that one out of three routes have an alternative path > DE-CIX RS 1 out of 2 routes have an alternative path > INEX RS seemed to have virtually no alternative paths for the routes > > Kind regards, > > Job > --f403045e7362b2d9a1054acc9a65 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thank you Job !

So this means that every third or second cust= omer in first two IXes respectively connect to exchange with at least two e= dge routers or it could be the same CE router with two interfaces :).
=

Now this also means that ea= ch such edge router is connecting to both independent route servers.=C2=A0<= /div>

Based on the above jus= t making sure that those two route servers pick paths with different next h= op as best may already address the problem to improve robustness with just = putting only a negligible additional load on the customer edge keeping curr= ent hardware and software as is.

Kind regards,
Robert.


O= n Wed, Mar 15, 2017 at 11:22 PM, Job Snijders <job@instituut.net> wrote:

On Wed, 15 Mar 2017 at 22:58, Rob= ert Raszuk <rober= t@raszuk.net> wrote:
Like Job observed for some customers peering to/via IX is just an addi= tional optimization hence indeed some may not always put most expensive and= latest gear there.=C2=A0

Actually after this discussion I am quite curio= us how many nets on the routes servers really have more then one bgp path. = If not much then this entire effort here may not be practically useful.=C2= =A0

Did some small crude= sampling by asking around:

AMS-IX RS indicat= ed that one out of three routes have an alternative path
DE= -CIX RS 1 out of 2 routes have an alternative path=C2=A0
INEX RS = seemed to have virtually no alternative paths for the routes
=
Kind regards,

Job

--f403045e7362b2d9a1054acc9a65-- From nobody Thu Mar 16 00:38:02 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEA1A126FB3 for ; Thu, 16 Mar 2017 00:38:01 -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, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HigDRCXIgfXU for ; Thu, 16 Mar 2017 00:37:59 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (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 17D6D126DFB for ; Thu, 16 Mar 2017 00:37:56 -0700 (PDT) X-Original-To: idr@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 38151618BA for ; Thu, 16 Mar 2017 08:37:54 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id F3B00604A9; Thu, 16 Mar 2017 08:37:53 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id EED598713; Thu, 16 Mar 2017 08:37:53 +0100 (CET) Date: Thu, 16 Mar 2017 08:37:53 +0100 From: Gert Doering To: Robert Raszuk Cc: Job Snijders , Gert Doering , idr wg Message-ID: <20170316073753.GE2367@Space.Net> References: <20170315000326.GO12864@pfrc.org> <58C95A05.3030107@foobar.org> <20170315195050.GT12864@pfrc.org> <20170315212656.GD2367@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ao30A/m+fEOaAmiA" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 07:38:02 -0000 --ao30A/m+fEOaAmiA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Wed, Mar 15, 2017 at 11:38:31PM +0100, Robert Raszuk wrote: > Thank you Job ! >=20 > So this means that every third or second customer in first two IXes > respectively connect to exchange with at least two edge routers or it cou= ld > be the same CE router with two interfaces :). There's large ISPs connecting with up to 4 routers to the IXP (so, same peer AS has multiple possible nexthops). There's also smaller ASes buying upstream from two or more ISPs that are all connected to the same IXP (so, same origin AS has paths through different neighbouring ASes at the same IXP). Optimizing the "route server shall distribute multiple paths" is only half of the solution. More interesting for me is "where do I need to point my vendors to, to get them to implement proper black-hole detection in the forwarding path, so the BGP NH can be invalidated?" (I'm not aware of any gear that will do this right now, as in "if IPv4 ARP or IPv6 ND fails, mark NH as invalid and look for other paths in BGP" - but I'm always willing to learn) Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --ao30A/m+fEOaAmiA Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAljKQM4ACgkQ31bAZeTO f8VgSBAArI5tedbZgpdTvQU7HJvLo9OCxThX9NR0wLD1VBzkBSkmYcx4S8p5bf/R ZJsAowLptAI2/cIw1IznMyecxl/iebLteZ7VJr2aN2MH87vRxVdO5/nlstvD4l+n vE5I1GKvNYmZcEJUuzYvBRMqbOhN/OgdUl+k2BpGArIiH47g9XwxqTWDExg+vb5L WNWpxfn66qO3lhDcHr7Y3GxjPpXRFyeLQzJajFvAhxi8pPFuKKZd8FABpZdg7ehi BF5GquagkXYb3PDJtzynJkSa5tGdWQPiMRZK/Kp4iYmCDguDgZGZGCvuYWyc0O8e /scdrm+jLJLKoNm+DLeypikkvTtcObyTlYF0asL1h1XrRVvwaFU0iTLaUfjOkwCc rqC5f8ox+XQ73tan3paHJ0cGJYZ1Kp9mZutxLcPAAK5yl563TD4aW6s3XUTy/eTf 6ByxNG7CYEBruM/9Ya7kyRGmv22GglecKYySAf7Hc8ZloIna1//RLq1e1vD4RDVY gmPwnUjfH7YKCVH+d3Pk4alH8dIDs1Kb4rzI6X/BZ9Qn+0yHNePnCQdzcSnioGkq OV2p+ihGWslFTbovh7+7s7pVnWDcSlnzGUj+5oPnzIqQOhirMXKVU96TYsqALj2N vkMEts87qOC7vBLuCEU9+tjzmIFpmcgxR1X1FCn688cGd9V2CCU= =ecqc -----END PGP SIGNATURE----- --ao30A/m+fEOaAmiA-- From nobody Thu Mar 16 02:29:33 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D786E126C23 for ; Thu, 16 Mar 2017 02:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hkd42zI_GP4d for ; Thu, 16 Mar 2017 02:29:31 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::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 238FD126DD9 for ; Thu, 16 Mar 2017 02:29:31 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id r45so32569377qte.3 for ; Thu, 16 Mar 2017 02:29:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=u/f7kjDBvOBQieUJKaqO5MTQvbLVvBvCGEe35CzrjFE=; b=QkRtEkzhCixYuORhxssQiAEysyAZTEHz3lkgfeKDzdJiQ1tmtjlSSsf5dS+JgVQNpi LTLoeofOQbX9ul5ibmsTbgoQtGrA7HE/GKWsVG+e33uJ5OaRANQqelTt0S/XGuMKvSlL 0FNQ/skUe6uArPdRUgRqxHy7v6bkgQpGzrsJYRC4NpoC3Cp8fISSrY3T/V95Ul87bsMC KSlilHgF09q5jtm/f3GRQscZjnDKZZWAdjxpsSQdFfyUKq3eIV4qvHEfV+JKdQ+81aUX Mgb0ZTrKARrSDNL/zp9R8N8JXd9CQ/mg/Tqg3+RCn97iTOkgTL9WxU8bWO+72pP4IOqB 6PaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=u/f7kjDBvOBQieUJKaqO5MTQvbLVvBvCGEe35CzrjFE=; b=h9YYz3NeCjzSrqfKHL07O0gGH2UCcZj/T5kdxvOc4XX73atFKBwOalF//KqzpdT9IF S96GsD+Ezh87kklkjhHkvpMSA/dMBAAXu/dDCt0f6Snd8LHm/DTw8P9LzxPMu49eIbra gSUOTrU6UxEdTB0TfvswM+eV3iBrcZEgPVlCQ/eovw6BGh9jKCx3JDkl4/k8yi5C4fTZ pXuoNm7O+cMmeDKy2Dn/R9bGb0Yr4gTqcaxWt2pSfcpQKwcIQec6y1S7odfl/HaeV/Mu OHSPim9iz/oHXCNddVIm8DrzC4OzGdEViFgicKICO1gflra8lvIzZYsvd5ZG+Mw/vEGK VG2A== X-Gm-Message-State: AFeK/H1lDYq/V9VvHOLKq1C4uSHafh3bma+h8C+2DQ2BYDkNZItbncSX7reor3nysJPEsMs3oRB8+QNdYUabuA== X-Received: by 10.200.53.209 with SMTP id l17mr6953625qtb.281.1489656570181; Thu, 16 Mar 2017 02:29:30 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.140.42.181 with HTTP; Thu, 16 Mar 2017 02:29:29 -0700 (PDT) In-Reply-To: <20170316073753.GE2367@Space.Net> References: <20170315000326.GO12864@pfrc.org> <58C95A05.3030107@foobar.org> <20170315195050.GT12864@pfrc.org> <20170315212656.GD2367@Space.Net> <20170316073753.GE2367@Space.Net> From: Robert Raszuk Date: Thu, 16 Mar 2017 10:29:29 +0100 X-Google-Sender-Auth: _z6_xqPV9d49p_RepuSmJ2JCl6k Message-ID: To: Gert Doering Cc: Job Snijders , idr wg Content-Type: multipart/alternative; boundary=001a1143c7b0b406eb054ad5b225 Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 09:29:33 -0000 --001a1143c7b0b406eb054ad5b225 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Gert, There's large ISPs connecting with up to 4 routers to the IXP (so, same > peer AS has multiple possible nexthops). > > There's also smaller ASes buying upstream from two or more ISPs that are > all connected to the same IXP (so, same origin AS has paths through > different neighbouring ASes at the same IXP). > Well =E2=80=8Bfor one I just went through talking to multiple large ISPs to= get transit via IXes and the answer is NO. They all (except one) said only direct peering with fiber. And the one who accepts to come via IX clearly requires direct eBGP session. So even if ISP is connecting to IX he is not offering free transit so his routes will not be downloadable from RS. That is the main point here. > Optimizing the "route server shall distribute multiple paths" is only > half of the solution. More interesting for me is "where do I need to > point my vendors to, to get them to implement proper black-hole > detection in the forwarding path, so the BGP NH can be invalidated?" > (I'm not aware of any gear that will do this right now, as in "if > IPv4 ARP or IPv6 ND fails, mark NH as invalid and look for other paths > in BGP" - but I'm always willing to learn) > =E2=80=8BCisco IOS classic/XE + NX object tracking is a cool feature quite = unknown as no marketing force was promoting it. You can run it even on Sup720 and set frequency of probing accordingly :) =E2=80=8BI use it every day. Juniper have had similar tool, but less flexible. Asking vendors (or extend BFD spec) to support BFD livness detection to set of destinations (say your current active next hops) without protocol may be a wise move too. But if we know that in real deployments only 0%, 33% or 50% nets have path redundancy on RS sending information there in the new SAFI .. such that single path nets lost reachability to next hops on all or some clients will do no good. =E2=80=8BThx, r.=E2=80=8B --001a1143c7b0b406eb054ad5b225 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Gert,

There's large ISPs connecting with up to 4 routers to the= IXP (so, same
peer AS has multiple possible nexthops).

There's also smaller ASes buying upstream from two or more ISPs that ar= e
all connected to the same IXP (so, same origin AS has paths through
different neighbouring ASes at the same IXP).

Well =E2=80=8Bfor one I just went through talking= to multiple large ISPs to get transit via IXes and the answer is NO. They = all (except one) said only direct peering with fiber. And the one who accep= ts to come via IX clearly requires direct eBGP session.=C2=A0

So even if ISP is connecting to IX = he is not offering free transit so his routes will not be downloadable from= RS. That is the main point here.=C2=A0

=C2=A0
Optimizing the "route server shall dis= tribute multiple paths" is only
half of the solution.=C2=A0 More interesting for me is "where do I nee= d to
point my vendors to, to get them to implement proper black-hole
detection in the forwarding path, so the BGP NH can be invalidated?" (I'm not aware of any gear that will do this right now, as in "if<= br> IPv4 ARP or IPv6 ND fails, mark NH as invalid and look for other paths
in BGP" - but I'm always willing to learn)
=E2=80=8BCisco IOS classic/XE + NX object t= racking is a cool feature quite unknown as no marketing force was promoting= it. You can run it even on Sup720 and set frequency of probing accordingly= :) =E2=80=8BI use it every day.

Juniper have had similar tool, but less flexible.=C2=A0

Asking vendors (or extend BFD = spec) to support BFD livness detection to set of destinations (say your cur= rent active next hops) without protocol may be a wise move too.=C2=A0
=

But if we know that in real= deployments only 0%, 33% or 50% nets have path redundancy on RS sending in= formation there in the new SAFI .. such that single path nets lost reachabi= lity to next hops on all or some clients will do no good.

=E2=80=8BThx,
r.=E2=80=8B
--001a1143c7b0b406eb054ad5b225-- From nobody Thu Mar 16 03:04:50 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22B6A126DD9 for ; Thu, 16 Mar 2017 03:04:49 -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, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4P3t-IZPtiGM for ; Thu, 16 Mar 2017 03:04:46 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (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 5422512704B for ; Thu, 16 Mar 2017 03:04:46 -0700 (PDT) X-Original-To: idr@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id DEB7561896 for ; Thu, 16 Mar 2017 11:04:44 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 91BAF614BC; Thu, 16 Mar 2017 11:04:44 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id 82F8E999A; Thu, 16 Mar 2017 11:04:44 +0100 (CET) Date: Thu, 16 Mar 2017 11:04:44 +0100 From: Gert Doering To: Robert Raszuk Cc: Gert Doering , Job Snijders , idr wg Message-ID: <20170316100444.GJ2367@Space.Net> References: <58C95A05.3030107@foobar.org> <20170315195050.GT12864@pfrc.org> <20170315212656.GD2367@Space.Net> <20170316073753.GE2367@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="+Q8hqmR/zbfF3tX0" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 10:04:49 -0000 --+Q8hqmR/zbfF3tX0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Mar 16, 2017 at 10:29:29AM +0100, Robert Raszuk wrote: > There's large ISPs connecting with up to 4 routers to the IXP (so, same > > peer AS has multiple possible nexthops). > > > > There's also smaller ASes buying upstream from two or more ISPs that are > > all connected to the same IXP (so, same origin AS has paths through > > different neighbouring ASes at the same IXP). > > >=20 > Well ???for one I just went through talking to multiple large ISPs to get > transit via IXes and the answer is NO. They all (except one) said only > direct peering with fiber. And the one who accepts to come via IX clearly > requires direct eBGP session. >=20 > So even if ISP is connecting to IX he is not offering free transit so his > routes will not be downloadable from RS. That is the main point here. Terminology seems to be funky here. "transit" is, for me, "I can use you to access the full Internet", not "I can use your network to reach your customers" - which would be "peering". So, except for 6939, I wouldn't expect anyone ever to give me "free transit= ", no matter whether on an exchange or otherwise. Now, at an IXP, there are participants (of course) that consider me too small to peer with them - that's a political and marketing decision, but not truly relevant for this discussion. At DECIX, there are something like 300+ ASes connected, some with multiple routers, and many of them are quite happy to peer with the RS, offering connectivity to their customer ASes. Whether or not a few of them are not using the RS, or not sending routes to the RS, can hardly be considered "the main point here", if we're discussing enhancing RS functionality. > > Optimizing the "route server shall distribute multiple paths" is only > > half of the solution. More interesting for me is "where do I need to > > point my vendors to, to get them to implement proper black-hole > > detection in the forwarding path, so the BGP NH can be invalidated?" > > (I'm not aware of any gear that will do this right now, as in "if > > IPv4 ARP or IPv6 ND fails, mark NH as invalid and look for other paths > > in BGP" - but I'm always willing to learn) > > >=20 > ???Cisco IOS classic/XE + NX object tracking is a cool feature quite unkn= own > as no marketing force was promoting it. You can run it even on Sup720 and > set frequency of probing accordingly :) ???I use it every day. Oh, I can, and I can tie other stuff into it (like, static routes). But=20 does *BGP* know, and invalidate its nexthops, if object tracking tells it "does not ping anymore"? Can I tell BGP "please run this automatically= =20 for all nexthops seen on this interface"? Manually configuring this for each peer address I *might* receive over the RS is operationally insane - 600+ devices on DECIX, with next-hop addresses I might not even know about until I receive a route for it, from the RS. > Juniper have had similar tool, but less flexible. >=20 > Asking vendors (or extend BFD spec) to support BFD livness detection to s= et > of destinations (say your current active next hops) without protocol may = be > a wise move too. This is why I'm asking for "do we have a document to point vendors so, so this magic would be available for me to use"? Until then, the proposed draft is a good start. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --+Q8hqmR/zbfF3tX0 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAljKYzsACgkQ31bAZeTO f8XeLQ//fGEZ5z9QKNuSciWU3xxSUqHKUPCoEbiDrKACFIKVKRL1T2PpRiA8vjIb AhoKn9B7lSpadRHWCsngfsr95j+/q87sYdEqk2YKijNoMqM5i0sh1R9t3vp1LdSB 8vem+wfeA2ZNcuVGW6eEYhKVTFOBmXmPhzqdVk3GMAVA2dxsNGDQaspRXH2tPvEC A8IAz9FEUtPDOH2PdufFixlyWMm6F8ulmKOXKgojeHp6beRilRyJooNbp5jOnJhY O0VbkmP6ZULUrYH73U6+ajzaGv7aNibNaFjkIjtnTijHhAaTRT4iMfbczpTkr6Ka DvcjCFgHmLu7tDyYjQBotyTswjKCpoG6+/y9Cj3O1sg/YX+hIwdibvB1C8xupWMW x6DaMtLwy9eBDFOafJ0jXYsSkypIrheog/AmscBNeKrja5E3c9vyIrkasOXJud2f MWqKkLM+ZIqN/XDFbcCa0/gHUW3WcTXk3eaZyWft5KDFEDeyefiQL8iRj2H8+pmi HTrrSnS0mPeG8KHvUDJTtdmE4UvGuWkWJgjq56ud4Jo+J++K/KKdKylpPi3hhk2E T9sNPpGBtJrkQf1TQ2s/Uqig/NnMsjZNYfHT6YrB5PcqzzjAh33zEWMQihT+tvbM KxUkg7NJBEWgBNjvCLl7H3H+M8Rtt41P7hDSgWk1cqzUi91A6U8= =lZi0 -----END PGP SIGNATURE----- --+Q8hqmR/zbfF3tX0-- From nobody Thu Mar 16 03:54:33 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD6812708C for ; Thu, 16 Mar 2017 03:54:32 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id il2sx7bBByQV for ; Thu, 16 Mar 2017 03:54:30 -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 2606112704B for ; Thu, 16 Mar 2017 03:54:29 -0700 (PDT) X-Envelope-To: idr@ietf.org Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id v2GAsRNP021863 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Mar 2017 10:54:27 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local Message-ID: <58CA6EE2.9030701@foobar.org> Date: Thu, 16 Mar 2017 10:54:26 +0000 From: Nick Hilliard User-Agent: Postbox 5.0.11 (Macintosh/20170302) MIME-Version: 1.0 To: Robert Raszuk CC: Job Snijders , idr wg References: <20170314223333.bw3caxfn34y6zlb7@Vurt.local> <20170314225855.GN12864@pfrc.org> <20170315000326.GO12864@pfrc.org> <58C95A05.3030107@foobar.org> <20170315195050.GT12864@pfrc.org> <20170315212656.GD2367@Space.Net> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 10:54:32 -0000 Robert Raszuk wrote: > Based on the above just making sure that those two route servers pick > paths with different next hop as best may already address the problem to > improve robustness with just putting only a negligible additional load > on the customer edge keeping current hardware and software as is. just to be clear, 1. this does not fix the problem we're trying to address here and even if it did, 2. ixp operators are not going to impose their own routing tweaks on their participant base by choosing different NHs. IXP participants demand consistency and if ixp operators don't provide this, or start interfering in the routing decisions of their stakeholders, then the ixp participants will go elsewhere. Nick From nobody Thu Mar 16 04:01:21 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0045E12778E for ; Thu, 16 Mar 2017 04:01: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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oGdB3hA5nyMr for ; Thu, 16 Mar 2017 04:01:18 -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 C8889127097 for ; Thu, 16 Mar 2017 04:01:15 -0700 (PDT) X-Envelope-To: idr@ietf.org Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id v2GB1D1r022637 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Mar 2017 11:01:13 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local Message-ID: <58CA7078.4000601@foobar.org> Date: Thu, 16 Mar 2017 11:01:12 +0000 From: Nick Hilliard User-Agent: Postbox 5.0.11 (Macintosh/20170302) MIME-Version: 1.0 To: Jeffrey Haas CC: Robert Raszuk , idr wg References: <20170314213607.GH12864@pfrc.org> <20170314214832.s3k37p27y7xfpfsv@Vurt.local> <20170314223333.bw3caxfn34y6zlb7@Vurt.local> <20170314225855.GN12864@pfrc.org> <20170315000326.GO12864@pfrc.org> <58C95A05.3030107@foobar.org> <20170315195050.GT12864@pfrc.org> In-Reply-To: <20170315195050.GT12864@pfrc.org> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 11:01:20 -0000 Jeffrey Haas wrote: > The reasons for the hilarity might not be obvious to some here. Some of > them include: > - Effectively an NBMA environment that most software wants to pick up as a > broadcast environment... and the protocols break when the L2 goes awry. > - IXPs tend to get a rather entertaining mish-mash of equipment... and thus > bugs. > - IGPs really like to have a consistent map and aren't happy when the LSDB > isn't consistent for various reasons. (See some above.) > - Security of IGP with multiple participant? Um, no. > > Please share others. :-) "Is that your anycast DNS IP address I see there? LOL, this should be fun." No-one ever said IXPs were hygienic. Nick From nobody Thu Mar 16 05:12:53 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CDAC12945E for ; Thu, 16 Mar 2017 05:12:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K6ALRuljwpt4 for ; Thu, 16 Mar 2017 05:12:50 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::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 1E3F7129452 for ; Thu, 16 Mar 2017 05:12:50 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id r45so35399186qte.3 for ; Thu, 16 Mar 2017 05:12:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=T9IY911CtWSOk/nRUl8if+4+olpBfHzwYkKvC86pJyo=; b=ieo+j1Gw+CrIpgDr3hRwVaMCsjgVViNBvGr/VC7yzNC51VybNNAj5wSdRlqWlNfqbC RYxOT2yHsYvPsFpgrUa1saChaCwW8GBW6yxY9nkPPaYFczAlRbvGM1UlZqto4KcN84P8 NR1OVdIXkDW+lGwT2uR+BwgHvghOjKVkgapSsDIoGCllGMSf1vfjZZMgKFuPQpBW7YMz fdvIpsDjE8lfPBlajy2RPRgrlZxDf8Iew84SL/FxQizNojDoyvbtYE1sowJLQQZSXEC1 o2Z/GX9ro6QhS7mQ9JjwPiwlOpd8IjUprHpECy9aYxjf0G5yM5REA3R0b0XBVQpBOksr Ox5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=T9IY911CtWSOk/nRUl8if+4+olpBfHzwYkKvC86pJyo=; b=Ww+HGw28rMe0G6bdAHo5VeiB6pVLGB7i4VsYVCjav2YofszymeHF5EAuxhWT+eLmfH f6QHvXruAB8yHyLR8w/473CxD7pM8ZU4Ir3jVqrZyYD121arGmOuABdTNmOZFWrIrYLh 6YhqBRY0wzSui1GFuqdsAurLI5o9283e/qyBBqOmqofg3lN7HUhnHMqbqfkMajEP1xDc ViYVp7/F2I3NK8GoyVbrxdns/4yj4nDukG1soBC7KJaTgHto8M78Dj2/YS2ocKgo0zWY 4efPzITe6G0Ta0k6HnTaoyOnqsnpiBtKh0MCPoTEY1HthvQnwzF66bdNX0EYHkiQMANf 3OnA== X-Gm-Message-State: AFeK/H0SJ3YH88DvxPvNw0BNCvxIw5hXACNoJPgEi1OvOAvjkMux6VcAMB06j+ew7kR7OoJ/yEy+Gt2SgmKvpg== X-Received: by 10.200.3.81 with SMTP id w17mr7522332qtg.36.1489666369133; Thu, 16 Mar 2017 05:12:49 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.140.42.181 with HTTP; Thu, 16 Mar 2017 05:12:48 -0700 (PDT) In-Reply-To: <20170316100444.GJ2367@Space.Net> References: <58C95A05.3030107@foobar.org> <20170315195050.GT12864@pfrc.org> <20170315212656.GD2367@Space.Net> <20170316073753.GE2367@Space.Net> <20170316100444.GJ2367@Space.Net> From: Robert Raszuk Date: Thu, 16 Mar 2017 13:12:48 +0100 X-Google-Sender-Auth: UU_HuE9nwAu66z6sBaUqCLhe5WU Message-ID: To: Gert Doering Cc: Job Snijders , idr wg Content-Type: multipart/alternative; boundary=f4030435b7e0c429d8054ad7fa7c Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 12:12:51 -0000 --f4030435b7e0c429d8054ad7fa7c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > > Oh, I can, and I can tie other stuff into it (like, static routes). But > does *BGP* know, and invalidate its nexthops, if object tracking tells > it "does not ping anymore"? Can I tell BGP "please run this automaticall= y > for all nexthops seen on this interface"? > =E2=80=8BYou can today say run it for all the peers which match a route map= . It is just a little extension to BGP Next Hop Tracking feature (which already have table of all next hops) to actually also automate tracking next hops. In fact one customer in the past requested that already .. but I don't know if this was implemented in IOS already. I am sure folks from C vendor will tell us :)=E2=80=8B > Manually configuring this for each peer address I *might* receive over th= e > RS is operationally insane - 600+ devices on DECIX, with next-hop address= es > I might not even know about until I receive a route for it, from the RS. > =E2=80=8BNo manual stuff. All you need is a single knob which will force only /32 next hop for resolution (already available) + do the tracking for all next hops received over given eBGP peer. =E2=80=8B This is why I'm asking for "do we have a document to point vendors so, > so this magic would be available for me to use"? > > Until then, the proposed draft is a good start. > =E2=80=8BThe feature request is one liner stated above. I am not sure if IE= TF document is needed for that=E2=80=8B. IMHO it is more of topic for Nanog/RI= PE. This is rather very much implementation specific. Cisco will tell we will extend object + next hop tracking, Juniper will do nice trick with rib-groups, linux based vendors will recommend to base nh liveness detection based on arp tracking which is already in all linux kernels. The fundamental question is should it be unidirectional (no session established of any sort between any to any) or we would like to keep the state associated with tracked object (BFD, symmetric or asymmetric echo/seamless etc ...). =E2=80=8Br.=E2=80=8B --f4030435b7e0c429d8054ad7fa7c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Oh, I can, and I can tie other stuff into it (li= ke, static routes).=C2=A0 But
does *BGP* know, and invalidate its nexthops, if object tracking tells
it "does not ping anymore"?=C2=A0 Can I tell BGP "please run= this automatically
for all nexthops seen on this interface"?

=E2=80=8BYou can today say run it for all the pe= ers which match a route map. It is just a little extension to BGP Next Hop = Tracking feature (which already have table of all next hops) to actually al= so automate tracking next hops.=C2=A0

In fact one customer in the past requested that already .. = but I don't know if this was implemented in IOS already. I am sure folk= s from C vendor will tell us :)=E2=80=8B
=C2=A0
Manually configuring this for each peer addres= s I *might* receive over the
RS is operationally insane - 600+ devices on DECIX, with next-hop addresses=
I might not even know about until I receive a route for it, from the RS.

=E2=80=8BNo manual stu= ff.=C2=A0

All you need= is a single knob which will force only /32 next hop for resolution (alread= y available) + do the tracking for all next hops received over given eBGP p= eer. =E2=80=8B

This is why I&= #39;m asking for "do we have a document to point vendors so,
so this magic would be available for me to use"?

Until then, the proposed draft is a good start.

=E2=80=8BThe feature request is one liner state= d above. I am not sure if IETF document is needed for that=E2=80=8B. IMHO i= t is more of topic for Nanog/RIPE.=C2=A0

=
This is rather very much implementation specific.=C2=A0<= /div>

Cisco will tell we will extend object + n= ext hop tracking, Juniper will do nice trick with rib-groups, linux based v= endors will recommend to base nh liveness detection based on arp tracking w= hich is already in all linux kernels.=C2=A0

The fundamental question is should it be unidirection= al (no session established of any sort between any to any) or we would like= to keep the state associated with tracked object (BFD, symmetric or asymme= tric echo/seamless etc ...).=C2=A0

=
=E2=80=8Br.=E2=80=8B

--f4030435b7e0c429d8054ad7fa7c-- From nobody Thu Mar 16 05:17:05 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 549E9129471 for ; Thu, 16 Mar 2017 05:17:04 -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, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t08FD69nKRCg for ; Thu, 16 Mar 2017 05:17:02 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (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 ED8F4129452 for ; Thu, 16 Mar 2017 05:17:01 -0700 (PDT) X-Original-To: idr@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 158AA615C0 for ; Thu, 16 Mar 2017 13:17:00 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id D0354604A9; Thu, 16 Mar 2017 13:16:59 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id C1AC2235FA; Thu, 16 Mar 2017 13:16:59 +0100 (CET) Date: Thu, 16 Mar 2017 13:16:59 +0100 From: Gert Doering To: Robert Raszuk Cc: Gert Doering , Job Snijders , idr wg Message-ID: <20170316121659.GM2367@Space.Net> References: <20170315195050.GT12864@pfrc.org> <20170315212656.GD2367@Space.Net> <20170316073753.GE2367@Space.Net> <20170316100444.GJ2367@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="KmzaXh/dgmvFxern" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 12:17:04 -0000 --KmzaXh/dgmvFxern Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Mar 16, 2017 at 01:12:48PM +0100, Robert Raszuk wrote: > The fundamental question is should it be unidirectional (no session > established of any sort between any to any) or we would like to keep the > state associated with tracked object (BFD, symmetric or asymmetric > echo/seamless etc ...). Both would be vastly superiour to what we have now - "no lively detection". As for "just ask your vendor about it" - yeah, been doing that, since years, for stuff that should have been obvious. But the standard reply is "nobody else is asking for it" and "how many new boxes are you going to buy?" - and since we're small, the latter argument is not convincing. Having an IETF recommendation how to make indirect peerings more robust by doing x, y or z and tieing that into BGP NH feasibility decision=20 would defuse the "nobody else is asking for it" argument thoroughly :) Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --KmzaXh/dgmvFxern Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAljKgjAACgkQ31bAZeTO f8XItw//WUdNI8EsUihvIew7FMsC2GLY96BNgjl5r9ZFraxb/YpDVxXMsby+twiA YWq6zjPaDlIUUdzma21qY99dtrKXqY+fXmX10erIwy9Ln+7ozfuO+1suu420I2yk H8EMEbOBPfESXN7R1qEQSqL2zFYgQ6Lk40PbiLYx4wK0WKNSUpgDtNrAyZmaHV2a wjTOFiyl7hGiCVHTmAFyD32DBYEEqxoxeGvdNlsEjPKx0JFtQR8ied7QpzONI55B M4XCCBYZvt2Acox2Wi0NgEzHNVcZGSgp2dtWkASXMQ0jDaUppIXfIWstKvwsZZvK QIcojozwhdGGPIUeBzOn//pfj+wLqPJECyxw1G3Ya9MS9N4me0fSCpKFnqEyFp8E zf74AvU63uv8f0JFV9u1VWsQ85ff2hjoZA1hQSbf0BrctDPQuZA2D9W9kfGgcG8E tgqzPbgwxx8DlajFOaSGGVG0swfs8SzexHuxsHSqE5/WUwIdZyo5HRjRgrUVSMb3 mZBIfiGsRuEUt64R+WI8IC8cA3z3hR93ykfbSA/naSrjX6CIfXckVUqZAypLFPOU /9uCneRbvlHzZNc2X9r6HpFcAAwrXjr1kEnBfB+kDK7L2yJhUiz8R08djtdBoRQx Hx5KB5BOkIRqUsE6ld9lgYU1IEulxs8QTVmXjah2pGGstjxGa9A= =WH5w -----END PGP SIGNATURE----- --KmzaXh/dgmvFxern-- From nobody Thu Mar 16 06:44:46 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B9F31294F9 for ; Thu, 16 Mar 2017 06:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iRtwV7UbS88C for ; Thu, 16 Mar 2017 06:44:43 -0700 (PDT) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8193A1294F7 for ; Thu, 16 Mar 2017 06:44:43 -0700 (PDT) Received: by mail-qt0-x232.google.com with SMTP id r45so37599642qte.3 for ; Thu, 16 Mar 2017 06:44:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=6psMURfQxYOSyltHhbWISfiBSDwv8z8qZixPjM/3xN4=; b=rR9g/bROlzCpuBbIvB/hzab4/Pu8RP9itveZSSRvCYkKZ3UolzsD3MafzXkSFx6bSB aW7DyMlabLPXlNAp6mvw5/lrqeSC8kTnyrXJUKjTVsJq1F8T4/PICZNRcUX6vZtg9g6O HHZCGYSCwcRwtm9q4vkYroKlaNC2r209lLIE2BTBHhWQbRrroQQnIINd5nSwOYyK69on AMOBXe1k00u4KOTo76KIUtIxl1yush3S0LKwINzQUxJ+OrDvNycgHixe+ur6g8wBEn0K OeBcAMMc4kpEmFn/W2A9lzrVhYiVuqyV0nK8ZkgLAOxdsYmQgFGUzl5zA8pCHwAKIV5f JGpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=6psMURfQxYOSyltHhbWISfiBSDwv8z8qZixPjM/3xN4=; b=rwAlXuDON7sRKn941B+79V4DJSRnXYWYtSZ8GtKWdR51cBERl8xu/JNJ+J9+uw2FxV mm8lYYZ31f5NaqBZI3lWZvrYXwqWs96e+yJRY17scgQEGYSM9+PiamGImuK6AYyDFxEQ yAtWSkxJziTc+oGF9vd8wARhe6/ywyuxwwuNQ2Ws3Bh3EyMUVj+vR7CyAFyNJfc340sl QEUICKqzkCyHHDSBIIr7XK4b8s7e8igeNV+qSE44i9lzcf0+sbnHhM9c83YRLCIKZwXA 09X0AIPOyeXlk/9IxIPjdpTgCXWXClyqSH0iygIVNSQ4jDyBikxMc8EmmTROe8CECP0r g8zw== X-Gm-Message-State: AFeK/H1+Sqo4uVRqxrfpRdUk0ijrIjYwlhXlKEiBJ4h+vVh8YDvTp/9KD0ZcRBXu5u49VMSf7tfuSPwpLlK+Tw== X-Received: by 10.237.37.121 with SMTP id w54mr9046595qtc.14.1489671882567; Thu, 16 Mar 2017 06:44:42 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.140.42.181 with HTTP; Thu, 16 Mar 2017 06:44:41 -0700 (PDT) In-Reply-To: <20170316121659.GM2367@Space.Net> References: <20170315195050.GT12864@pfrc.org> <20170315212656.GD2367@Space.Net> <20170316073753.GE2367@Space.Net> <20170316100444.GJ2367@Space.Net> <20170316121659.GM2367@Space.Net> From: Robert Raszuk Date: Thu, 16 Mar 2017 14:44:41 +0100 X-Google-Sender-Auth: vT0XESlk4-ngZFvoOIH4QuoeGjo Message-ID: To: Gert Doering Cc: idr wg Content-Type: multipart/alternative; boundary=001a1140f782647b64054ad9431c Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 13:44:45 -0000 --001a1140f782647b64054ad9431c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > On Thu, Mar 16, 2017 at 01:12:48PM +0100, Robert Raszuk wrote: > > The fundamental question is should it be unidirectional (no session > > established of any sort between any to any) or we would like to keep th= e > > state associated with tracked object (BFD, symmetric or asymmetric > > echo/seamless etc ...). > > Both would be vastly superiour to what we have now - "no lively detection= ". > =E2=80=8BOk .. let me take a stub on this with existing =E2=80=8Bequipment = after IETF. Will report findings either offline or online. If for nothing else then to just document what automation is already possible today in this space. Having an IETF recommendation how to make indirect peerings more robust > by doing x, y or z and tieing that into BGP NH feasibility decision > would defuse the "nobody else is asking for it" argument thoroughly :) > =E2=80=8BWell this to me sounds like a perfect GROW draft at most. =E2=80= =8B But let's face it ... for all major vendors IX based revenue does not even fit to annual balance sheet .... so I am pretty sure any enhancement in this space will be done only after good amount of convincing arguments even if all IXPs sign an open letter "We need it". Cheers, R. --001a1140f782647b64054ad9431c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=C2=A0
On Thu, Mar 16= , 2017 at 01:12:48PM +0100, Robert Raszuk wrote:
> The fundamental question is should it be unidirectional (no session > established of any sort between any to any) or we would like to keep t= he
> state associated with tracked object (BFD, symmetric or asymmetric
> echo/seamless etc ...).

Both would be vastly superiour to what we have now - "no lively= detection".

= =E2=80=8BOk .. let me take a stub on this with existing =E2=80=8Bequipment = after IETF. Will report findings either offline or online. If for nothing e= lse then to just document what automation is already possible today in this= space.=C2=A0

Having an IETF = recommendation how to make indirect peerings more robust
by doing x, y or z and tieing that into BGP NH feasibility decision
would defuse the "nobody else is asking for it" argument thorough= ly :)

=E2=80=8BWell = this to me sounds like a perfect GROW draft at most. =E2=80=8B

But let's face it ... for all = major vendors IX based revenue does not even fit to annual balance sheet ..= .. so I am pretty sure any enhancement in this space will be done only afte= r good amount of convincing arguments even if all IXPs sign an open letter = "We need it".

Cheers,
R.
--001a1140f782647b64054ad9431c-- From nobody Thu Mar 16 11:48:00 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 352471298CF; Thu, 16 Mar 2017 11:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xL7dAD8sUSDl; Thu, 16 Mar 2017 11:47:57 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 F143F129951; Thu, 16 Mar 2017 11:47:55 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=70.194.2.137; From: "Susan Hares" To: "'idr wg'" Cc: , , "'Dongjie \(Jimmy\)'" Date: Thu, 16 Mar 2017 14:43:05 -0400 Message-ID: <013d01d29e85$270dcae0$752960a0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_013E_01D29E63.9FFCEE30" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdKehOZ/wEwxmWbqQC6qAxZ77D+MDw== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [Idr] IPR call for draft-grendler-idr-bgplu-epe X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 18:47:58 -0000 This is a multipart message in MIME format. ------=_NextPart_000_013E_01D29E63.9FFCEE30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This is an IPR call prior to a call for adoption for draft-gredler-idr-bgplu-epe ( Egress Peer Engineering using BGP-LU) which can be found at https://datatracker.ietf.org/doc/draft-gredler-idr-bgplu-epe/ Will the authors please indicate whether they know of any IPR on this draft? Sue Hares ------=_NextPart_000_013E_01D29E63.9FFCEE30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is = an IPR call prior to a call for adoption for = draft-gredler-idr-bgplu-epe  ( Egress Peer Engineering using = BGP-LU) which can be found at

  ht= tps://datatracker.ietf.org/doc/draft-gredler-idr-bgplu-epe/ =

 

Will the authors please indicate whether they know = of any IPR on this draft?

 

Sue = Hares

 

------=_NextPart_000_013E_01D29E63.9FFCEE30-- From nobody Thu Mar 16 12:05:09 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA4911299E1 for ; Thu, 16 Mar 2017 12:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 88gUoUcSrNf3 for ; Thu, 16 Mar 2017 12:05:07 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 3880D1299E2 for ; Thu, 16 Mar 2017 12:05:04 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=70.194.2.137; From: "Susan Hares" To: "'Kaliraj Vairavakkalai'" , References: <54AF9ADE-1FB7-447F-8F81-E10D0B787DEB@juniper.net> In-Reply-To: <54AF9ADE-1FB7-447F-8F81-E10D0B787DEB@juniper.net> Date: Thu, 16 Mar 2017 14:43:52 -0400 Message-ID: <015701d29e85$426f11e0$c74d35a0$@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: AQGHaiT+TIm6aKH+HkgTrZQ5hRsD46IuJOXw Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] Request WG adoption for draft-gredler-idr-bgplu-epe X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 19:05:08 -0000 Kaliraj: Thank you for request. I've started an IPR call. After the IPR calls is complete, I will start the WG adoption call. Sue -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Kaliraj Vairavakkalai Sent: Tuesday, March 14, 2017 3:01 PM To: idr@ietf.org Subject: [Idr] Request WG adoption for draft-gredler-idr-bgplu-epe Hi IDR WG, The authors of following informational-draft would like to request its adoption by the IDR working group as a WG-document. draft-gredler-idr-bgplu-epe Egress Peer Engineering using BGP-LU https://datatracker.ietf.org/doc/draft-gredler-idr-bgplu-epe/ Thanks, Kaliraj (co-author) _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From nobody Thu Mar 16 18:07:46 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7A42129BB3; Thu, 16 Mar 2017 18:07:43 -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, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4lLAW-7Rpwkc; Thu, 16 Mar 2017 18:07:41 -0700 (PDT) Received: from kangchenjunga.rtbrick.net (kangchenjunga.rtbrick.com [217.160.181.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2E15129BB2; Thu, 16 Mar 2017 18:07:41 -0700 (PDT) Received: from [192.168.2.4] ([::ffff:122.166.206.43]) (AUTH: PLAIN hannes, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by kangchenjunga.rtbrick.net with ESMTPSA; Fri, 17 Mar 2017 02:07:38 +0100 id 0000000028810750.0000000058CB36DB.0000133D Content-Type: multipart/alternative; boundary=Apple-Mail-31AAD233-08BE-42F2-90F3-F3E5A77B47E1 Mime-Version: 1.0 (1.0) From: Hannes Gredler X-Mailer: iPhone Mail (13G36) In-Reply-To: <013d01d29e85$270dcae0$752960a0$@ndzh.com> Date: Fri, 17 Mar 2017 06:37:35 +0530 Cc: idr wg , draft-gredler-idr-bgplu-epe@ietf.org, idr-chairs@ietf.org, "Dongjie (Jimmy)" Content-Transfer-Encoding: 7bit Message-Id: <15334F01-0225-4D57-BF13-BDD709921961@rtbrick.com> References: <013d01d29e85$270dcae0$752960a0$@ndzh.com> To: Susan Hares Archived-At: Subject: Re: [Idr] IPR call for draft-grendler-idr-bgplu-epe X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 01:07:44 -0000 --Apple-Mail-31AAD233-08BE-42F2-90F3-F3E5A77B47E1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable i am not aware of any IPR. > On 17 Mar 2017, at 00:13, Susan Hares wrote: >=20 > This is an IPR call prior to a call for adoption for draft-gredler-idr-bgp= lu-epe ( Egress Peer Engineering using BGP-LU) which can be found at > https://datatracker.ietf.org/doc/draft-gredler-idr-bgplu-epe/ > =20 > Will the authors please indicate whether they know of any IPR on this draf= t? > =20 > Sue Hares > =20 --Apple-Mail-31AAD233-08BE-42F2-90F3-F3E5A77B47E1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
i am not aware of any IPR.

On 17 Mar 2017, at 00:13, Susan Hares <shares@ndzh.com> wrote:

This is an IPR call prior to a call for adoption for draft-gredler-idr-bgplu-epe  ( Egress Peer Engineering using BGP-LU) which can be found at

  https://datatracker.ietf.org/doc/draft-gredler-idr-bgplu-epe/

 

Will the authors please indicate whether they know of any IPR on this draft?

 

Sue Hares

 

--Apple-Mail-31AAD233-08BE-42F2-90F3-F3E5A77B47E1-- From nobody Thu Mar 16 20:52:43 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D7DA129BE8; Thu, 16 Mar 2017 20:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.696 X-Spam-Level: X-Spam-Status: No, score=-4.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f9sSrhOfRDsy; Thu, 16 Mar 2017 20:52:40 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0121.outbound.protection.outlook.com [104.47.41.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 A3FBE129BD4; Thu, 16 Mar 2017 20:52:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=zdpUHOaWn+qzCchfTne3gxuTLkSaldyrZrVRFLrWVxs=; b=MRd1bbtm15LsFO2DMqabPeQtl9Op/Vu5Ps56G4KujJsOF/wKu49RKwAkBMN8WEzu9Lpq5pHAbbodOqnYvRudjXPKzls/HqqqPfYN/FGvYbUcEWvi80FLWpEz+iDu5kQIUA2O8SxD8/AmjezM4eQbfGXlB4oI4eaX9NrxoHWWAOY= Received: from BN3PR0501MB1377.namprd05.prod.outlook.com (10.160.117.11) by BN3PR0501MB1377.namprd05.prod.outlook.com (10.160.117.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.977.5; Fri, 17 Mar 2017 03:52:38 +0000 Received: from BN3PR0501MB1377.namprd05.prod.outlook.com ([10.160.117.11]) by BN3PR0501MB1377.namprd05.prod.outlook.com ([10.160.117.11]) with mapi id 15.01.0977.013; Fri, 17 Mar 2017 03:52:38 +0000 From: Chandrasekar Ramachandran To: Susan Hares , 'idr wg' CC: "draft-gredler-idr-bgplu-epe@ietf.org" , "idr-chairs@ietf.org" , "'Dongjie (Jimmy)'" Thread-Topic: IPR call for draft-grendler-idr-bgplu-epe Thread-Index: AdKehOZ/wEwxmWbqQC6qAxZ77D+MDwATKzLw Date: Fri, 17 Mar 2017 03:52:38 +0000 Message-ID: References: <013d01d29e85$270dcae0$752960a0$@ndzh.com> In-Reply-To: <013d01d29e85$270dcae0$752960a0$@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;ndzh.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [116.197.184.12] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1377; 7:rsSvBdph41lC08U7CX4CQZBdgsFsw72z0XM2HwHjkSVaNy8IqqVq/oxCOz1x9tIZCfxL9AGVOLhWSc66rn/b7fgTxcR0ouhqAOsYc9bF8FsILTgyDqW6PBApzBPKpA/Di/hCmy5I6AQ9IuM6UMSZsZBLJVVDT4HgWgKXM07R+ddMlIwAtZRQt3j3SxSBmFE6KQjH/2rEZ3ttx18fRzYEMnMsXPqukvQI9/aYrTxua5x7wGbEUAFkLknTuNNoc8W0rQlzpDLDbOCqMvO/nRi+3ChRWVfSU1Uzkz5y5lifLOCH8KKS1Lo8vsfF7MrsK4Hc13HVTJTGJ600EmbpNQyV7Q== x-ms-office365-filtering-correlation-id: a8ea57a6-8fdc-41ca-87b1-08d46ce90dfe x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254042)(48565401081); SRVR:BN3PR0501MB1377; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(50582790962513)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123558025)(20161123560025)(6072148); SRVR:BN3PR0501MB1377; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1377; x-forefront-prvs: 0249EFCB0B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(39410400002)(39850400002)(39840400002)(39450400003)(377454003)(81166006)(3660700001)(790700001)(3280700002)(6116002)(3846002)(102836003)(33656002)(53936002)(230783001)(53546008)(2906002)(8936002)(77096006)(9686003)(54896002)(236005)(54906002)(6306002)(2950100002)(606005)(25786008)(6246003)(38730400002)(6436002)(7696004)(6506006)(229853002)(66066001)(99286003)(55016002)(7736002)(7906003)(8676002)(74316002)(189998001)(122556002)(2900100001)(5660300001)(4326008)(50986999)(19609705001)(86362001)(54356999)(76176999)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1377; H:BN3PR0501MB1377.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN3PR0501MB1377A182637781C0742DFA4AD9390BN3PR0501MB1377_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Mar 2017 03:52:38.2695 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1377 Archived-At: Subject: Re: [Idr] IPR call for draft-grendler-idr-bgplu-epe X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 03:52:42 -0000 --_000_BN3PR0501MB1377A182637781C0742DFA4AD9390BN3PR0501MB1377_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm not aware of any IPR on the draft. From: Susan Hares [mailto:shares@ndzh.com] Sent: Friday, March 17, 2017 12:13 AM To: 'idr wg' Cc: draft-gredler-idr-bgplu-epe@ietf.org; idr-chairs@ietf.org; 'Dongjie (Ji= mmy)' Subject: IPR call for draft-grendler-idr-bgplu-epe This is an IPR call prior to a call for adoption for draft-gredler-idr-bgpl= u-epe ( Egress Peer Engineering using BGP-LU) which can be found at https://datatracker.ietf.org/doc/draft-gredler-idr-bgplu-epe/ Will the authors please indicate whether they know of any IPR on this draft= ? Sue Hares --_000_BN3PR0501MB1377A182637781C0742DFA4AD9390BN3PR0501MB1377_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m not aware of= any IPR on the draft.

 

From: Susan Hares [mailto:shares@ndzh.com] Sent: Friday, March 17, 2017 12:13 AM
To: 'idr wg' <idr@ietf.org>
Cc: draft-gredler-idr-bgplu-epe@ietf.org; idr-chairs@ietf.org; 'Dong= jie (Jimmy)' <jie.dong@huawei.com>
Subject: IPR call for draft-grendler-idr-bgplu-epe

 

This is an IPR call prior to a call for adoption = for draft-gredler-idr-bgplu-epe  ( Egress Peer Engineering using BGP-L= U) which can be found at

  https://datatracker.ietf.org/doc/draft-gredler-idr-bgplu-epe/

 

Will the authors please indicate whether they kno= w of any IPR on this draft?

 

Sue Hares

 

--_000_BN3PR0501MB1377A182637781C0742DFA4AD9390BN3PR0501MB1377_-- From nobody Fri Mar 17 08:37:03 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B5401294B0; Fri, 17 Mar 2017 08:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qK0MJUs4dZ95; Fri, 17 Mar 2017 08:36:59 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0104.outbound.protection.outlook.com [104.47.34.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7E7F1294AA; Fri, 17 Mar 2017 08:36:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=KOWn1WGUftScCIA4DuHG+DImbNTTQSJVWm703f4e9PY=; b=OoOJ+wD4N9Zx3abq2zoi/roFJV10vYBgm3rfkl/n2cZ4LfiY5hhuGibizpNXtRwzb2L/tahm8TRzSwHByXgySplKGGh/aeu7pO9ymVHBUT7I65LTsr5O79j3by31nvFkh4QZ4ZpQjfs8DeeyIN04WK6hrE2itslDr/ih1aXQRmQ= Received: from BY1PR0501CA0033.namprd05.prod.outlook.com (10.162.139.43) by BLUPR0501MB1746.namprd05.prod.outlook.com (10.163.120.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.4; Fri, 17 Mar 2017 15:36:53 +0000 Received: from BL2FFO11FD009.protection.gbl (2a01:111:f400:7c09::167) by BY1PR0501CA0033.outlook.office365.com (2a01:111:e400:4821::43) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.4 via Frontend Transport; Fri, 17 Mar 2017 15:36:53 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.18) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=fail action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.18 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.18) by BL2FFO11FD009.mail.protection.outlook.com (10.173.161.15) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.961.10 via Frontend Transport; Fri, 17 Mar 2017 15:36:52 +0000 Received: from smtp.juniper.net (10.163.2.159) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 17 Mar 2017 08:36:34 -0700 Date: Fri, 17 Mar 2017 09:36:32 -0600 From: Ebben Aries To: Susan Hares CC: 'idr wg' , , , "'Dongjie (Jimmy)'" Message-ID: <20170317153632.w3lcc6ygky4cwh3l@smtp.juniper.net> References: <013d01d29e85$270dcae0$752960a0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <013d01d29e85$270dcae0$752960a0$@ndzh.com> X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.18; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39840400002)(39860400002)(39450400003)(39850400002)(2980300002)(377454003)(189002)(199003)(24454002)(9170700003)(54356999)(76176999)(229853002)(50466002)(38730400002)(50986999)(4326008)(33646002)(8936002)(47776003)(81166006)(110136004)(53936002)(8676002)(55016002)(54906002)(106466001)(105596002)(6306002)(53416004)(97756001)(230783001)(46406003)(7696004)(189998001)(305945005)(356003)(1076002)(6246003)(86362001)(77096006)(104016004)(23726003)(5660300001)(2906002)(6916009)(2950100002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB1746; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11FD009; 1:JrmOUri5SlYbnZPTufHrUM4ZvOiyW8S11APaszfgioWLnEAIm6IXTGviWZag1c+HgoOlhtSvDKFS+sVCF5i5S95qPtqoo9LnYfMlsQulOE2gexgFMuUZisR5bObpRSE8543MWImCTpoak+6JTm3rIeeO8l/+YmGGLGIrfLv2pQyta9Zy1Mc+V/gXyBmrXbI1h6wdtcw1FzlmAYEDo2nqWma4FULwEzSwNZLuC9eWD7meRGUd8wMCtqbFYhwflzyykV8o++RGj4SXjcbMN404AqFy62qFabSHHwJAUvRl8YUEH3brNxFg6BEQJtG6xaoBHHSOxemqQ3/UXM+Kpv1VSJP6oWarpLg1KB5puS83S8sYgac2au0uMXD466kFtJopVyHoGrj/wDcr5t9PNFBEEQZ/yyH8IMJ3jOQBtwGjLODhJ0/R9cWULKpGm4EDFa0rYNSvy8MnH5nKSIIVckZxB6JdxVoW/LIOYCVoulLlgbt9JH2y6MCBprN7JQ8U4JX50GBzV0B6UMyMCB4I43hLCDRUNRIbcz758lkHfTe/AW2fwz4zcW+elFjPagslzddAWelC+Rmq18uL1WK83mbi9n5lYI6XXLtka1H80BLYo14= X-MS-Office365-Filtering-Correlation-Id: a09805ea-e2df-4bd6-edc9-08d46d4b6fa0 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BLUPR0501MB1746; X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB1746; 3:pjHsHxa7UrXghGnyR75S13z2bJgGQBSly5knmIbN4SKs36SNrLe0SIdAxtvkl+GFhCPTn/tiOg7MnFq1wfuhVQ+/sO3Q7CldJqVb0k51AVHkut21WEq9Bz6520OJ9Heihq4b8AFHuayKDbVdZe+1cqaDM5E4SHf60eyiI8bS48DRsraK3dIx+5UvYJHpI6TOgmbU+fS2KHeygA413oYVyuBDP4bzEoztQiY2R4/gCz0+0v+ep4IMlMyYbXs1bSYZUiemFMTBVRmbEgw6zj+wDgy8ULK8D64Jxhs9AjoA5MSVKN4y6Z2jdlPMTXrysuXwiaqamLXeRYvAGKuGhRgdIqLceUrmtSpCTZx/w9uzAiQVkxzCvvMPZ0W9tRflSkCC; 25:DOKT5rAAebOCULQPHHO4wwqfiY6r6SeGk5oQrLeZMn77y1sWX28jbkHGO1eMrOyEWvOoaZxNVS95e6ZSpZmrHHc6TxTwcwGSZVBHgn5aoBP7SuA1zgnxUQtZ7ym5++0jeE6VvSjmMQn9OcZ9QPvhL6bVn0y0V+jnK0skx4k8e5WtaUbjvzL3q4bYKV444QUXrGUln4l5xufRAsKbqOojfFfcLkrvFM6UKUVBpA5DpPm73ANlGnWzLezeqkFYsXJSb6yRpCH/UGurhoURe5IgVrFvF3S37gomvT/swRuXfeEUbbf8rW6LXGK430cAC9092dJDzsNZbK62m8QtmwmO2PfMLAtutHAr4pWTpppwS1vsi3r4ftJHOC55B6bz+wubXoJdpOydmYrMRdM2qDCOnRYi+zM6RHXCoWVLUseXU9WYTGg2sxL3jgOqa0moAel0pv++T4Ik6DZfyGr70C3tyA== X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB1746; 31:O+gzi/9jLZJlt1WjtxAb6o4diq+2ov8o3eKUvtTQ5EAcnLnhsXnMlkfhNIwZKJRAKucoJTMW0JHKz5ivj5dU1t/deEgD7Px08nqpFei/c5yV2jjaWDlg1ucNWF73ZFPHgv8IV5epSSb+LKsip53ICt39rKJiD8IwdNGq3+5rlfbphWyrKxeEJ6P/049qXMO5+V2YlL+yUSCIs/qyZAjtssIoUKKCh0wDmpVrA1WgWw/waLG3XtXrqgIEJELJS4YrfViNEaGOKdJ1Da1q5aCFEw==; 20:U4SoKBpcoHYSqZDqOcN70JYUnbZ6S6sf7QLscKmZEc1QYQ2BvRrEXIfQcONuaT0oDLJTnuV/kjL7Zc/4mkjPITx5v3TrlK1DiGsPGdiyuxe4cognPdURSiIkybeMlqXpeGC08hvK9bxw3sz/RTcD7krVCA6jnvxHntuQPHzxVKnr2qaJ2aHC5d0A8WdShvy8IOEW793pGz+RnyKiUqe0nD83uog0TOlSeX8BVEU2oOTk9uPvb39DK5ofpOURENOjtWCf9eleV8UMaVpf7AkUEzoTV5qLgwJI2pgBqUzDEkrEJk+J4MCJBjI57UyCTKiQNY9u9nPTho9UlcfaYR9FG3++euWACu8AlkzJmdyZFqsNJvXf/s5ZNx5TRU1Aq65kTZ03EX0aA1lh6pDPWS0Zpq6pDNq498UuN0Op2u+FB1dD/92qHOUseHWExJeaVEqvz6rmeSJ1++sgA3NcO99QYoJJFG4ZKkW+RzC/1EIj5OrsAcTA0Cia4DiQ6UJksc7y X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(120809045254105); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(13023025)(13015025)(8121501046)(5005006)(13017025)(13018025)(13024025)(10201501046)(3002001)(6055026)(6041248)(20161123555025)(20161123564025)(20161123560025)(20161123562025)(20161123558025)(6072148); SRVR:BLUPR0501MB1746; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB1746; X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB1746; 4:PaEAzq5/o2Gf9SVAxHZLyB0ocFtPKzWf39Kh90JodYvb1IWlgFScr21UqZETGIEN41jAAaQBWTGsb0rwxkMY5o2+CAv/S+W4lUORAsxkpH+YuehtQCjJOIFeWgtisQq7PGdYIvomn8r5md3G6T7rt6wolHGC9oX4wWDI/ooZZJWvlXW0e2RhOMLx6eCEkrMr4bbtrUyzaUKHvZimzJfJ3qpcaXUoiN0jmMc7kQVicFiQuqV/H6JoM0274RBXW2qpdn7Xw+SoCVesf3qZ3u0D55aGB0DXYjw9Yvrk7ocKiZKdwGwm3O0pkDLe+/DtchfGnfuk4AANrS363H7GrPSVrB77LW+gA3oAINZ/ZppJAQ2oaBPLz+4FWceC/trnF+5uaDFx2EBMPnHbMn6rs1jrNoOQoFwDc26RoUBfaPNqrtu2AIwyn42kxtSSqwrrz4uIRqNIYBqcmHQ0nkD2tJMMmsR7d9ilevbnfCcxkPcOskmqlGAwcSbo3h5EW8YhTIbEmoKDQYTe79rxd4DKInNrnA2Io+uATwkFpdD4Pw9QpHL72vJLLn4x3IShH5p20+eWLdi8ANFLIbenF9fzoGRi7o4FqTwsMOiXPjWnckgxU4o/Tnsy9zs5eMMeNyk/yGMoOFtVf4iyufNyv5KRIffjqIK9fYtTqq4+ur0xBZ0cbCgjgbXKkQnAKQsBU4WEJ86gH88kzGzRCHxhHVYUTUdSvIoqHUSO39qMB2lZX505p6uILLLMM9UpZV6ElVdxQL27nA1GTuE87JQBwE+UyfpQEQ== X-Forefront-PRVS: 0249EFCB0B X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BLUPR0501MB1746; 23:rhIFJ6WKdS0+C2JCswJowjYxA6HO5Np1CHAgunU?= =?us-ascii?Q?vQ04aNIpOG9SvwwmmjLDQiubDp4ZYRepVw4pGAyww3CAf9BS+MvgVjS1UJEf?= =?us-ascii?Q?8j4S+ICKH2Csc8XaUEbpjolklnVtnVI7aV6JkCRg0gqLCyB/Yk7ndXWgbBF6?= =?us-ascii?Q?MNZpsZkc7wIBHteCB3fKGpnL130k/vL5zs7CKdy3eBJKWsbvoBK7pjHkBLcO?= =?us-ascii?Q?PbqaWeAVm48DK1cYpjyOoW1MAxcqkRmEU7Jp3Wm7Fwv/aSCvqJLSf/LdhFxP?= =?us-ascii?Q?dK04xPBvdYKv1jz1fiqCw049+8Muf7+9weIiYZYm5Blxxqhzg7Iqp/2ODBwg?= =?us-ascii?Q?d15h9j73WTfW41NZm3vv/fkAGQpdRCACrJtDQLaMM6pmuLBfwSqrIbxInSzS?= =?us-ascii?Q?UklTcSShiSkpmftG7le9gWUnX19w9LsDwmJRtPuuQZ8RNWJl4QwaxNo9obJB?= =?us-ascii?Q?CTECgD4w1MTbjqQGp31jrEcPNHdESZsfntur4rGrBdRbH8R7EwD3U7CTnWrb?= =?us-ascii?Q?1SZwUNjzGuhEjH2jXmA74XoN5cdVj+KGTfUvGrGQe9NoowAvnIHU/U2UEJD2?= =?us-ascii?Q?sTOhB/teGPWk1abHZiwn/0/7S6WruJwhaas+D939O9AFwY9AmLd2ZvHDSMV9?= =?us-ascii?Q?0AsxxTY83pCsjRG39LXiJjI1hHXIMj0QIAoR6m5XPVfRlZ1ADcDJjm/QwzRu?= =?us-ascii?Q?R8asSwr7E7CFKhvwlhNi7HiW70KZ2Zg7sds+anusaKesXzMvDxWeFt8r9ZgL?= =?us-ascii?Q?nHH6H+wo2mqcXpSvnDPnrQAg5Zx6PP0tGwRUlM8eZbakw+tKTUvYnXrs1Oin?= =?us-ascii?Q?M60hQl0j9kBfFYAvaIyt6RPhv7tCA5ILB7pen4rwWwFbg46fbcZNPjxj46Ci?= =?us-ascii?Q?bsnIXHJUxQcT8etv28q9R+Hp/YQ2oeH2Bm+RULBkfr+QX4YEbQvsOy11y6Fg?= =?us-ascii?Q?1O0h6e86T/lZpHuekHPjJp3bF+XQDG3AmeImr9l8LRPBbvdXS8n/N6A3pCY8?= =?us-ascii?Q?U8eu3mw0RYrSoWQKiXjkP94n5/kz3G2sSUeHMLG6nHWX+zWfsYvEWiFwE68K?= =?us-ascii?Q?whyQEcanUOtYfvrPc0mncXJ893YcUQ9Or8rJVM8hGu4sdudW7E22mXAhwUqU?= =?us-ascii?Q?F24DydK7Uv2y4WqTEM68N33CQi3l9uopI5gmaN8g6rgQVDiya0uUjMZwEzsg?= =?us-ascii?Q?+cg77gwWTORKsaanp3PcFIHOQHs2CwUW7Ar0aNmzyNT1TZoeA0/D2eKugwA?= =?us-ascii?Q?=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB1746; 6:055iDiOIVPrh1Ii/aFpgOL1EF/RlRAUGY+r3ohprRqHJ5in6FLt+qz1nIduPAjZlV8N9CEwP6K6v272vZV6QALGYcuGGKd6M3LamXry3NoftaQAzMNgC2fLQkadbvlqJhViHlOyILSkSaFfozFD0GXxw4MetBxZsNTwM+Z9cwWw1J49PAGKMCFAsf4+RSt97ZaHkHc3k4TsR4faGDfigl1Q2Vic1vNpPx2pKOafybg4uOtC/lrZY/aA8DsFfJWUkWN+HU/WKD4doBWPZeqoUBF6xwj7HrTy0D/BSn0hX77Bzu8otthQJrdo5xhIvpZxTeKme/B7/7J9QE6EKQdWSh8KXgEM407Ke1Tadc5jEUexRC/v+RXp0gKiM93IjLJ6omlib08dWt3hSJuwCxHu1G6b099Z37Qn/aIBS/Hs5UEM=; 5:GCh56aePnqBKDO6KzUgIgsqfsFWRPodVU0BHvrLM4dR0Ysq0M6wU2oO46c5Vl/E84cxwURdbaCunGnCmBUlZuBZIVi6YEJKIAR2YI6S+jfc9CWNieezMWOj9bl8K+vi1BKDNhXKuCbTG9HeXQYFqRA==; 24:vPGcbLdqA85ScYSEul0Agoxt0rmcinps1lsZV7DhPel/YjWJJRs5sYsMcS5iuLGVBpvSW19Kwbt2ESSoiC8wvGkSbLdnEqCyzMzcaG7ZD1A= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB1746; 7:xXoEKRbt6ma6hhoPcSOQ0bwNMkgsMsjvMQEoq6z+MC3GzEREIGE3tkEswVz7VHEZk4APJLSi/0cWY+P6amd8SuQas4euQZ17caS3knG+NoD80KQhpRNBab12YtxzHHgcc7tQmRZHyTGVWc/Jyb97AaoX6atANzO/JUMXMGsaqK/uRqnjC6kXwNAAS1AvSYaukIYp8HhQE7wBGB/Dx3FspRENWb/wBKOeQz8CttqAfP2rYBKhkNKv2hgPCaV3YJYe2g/lYHmi/Ow4+8kiTHliXEMhIZ7sFWlyq0kHOMIe+o6VsJimtG/ciHgHXv7wCrI8qhXnMfYiq0X7dzux7HjToA== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Mar 2017 15:36:52.2634 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.18]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB1746 Archived-At: Subject: Re: [Idr] IPR call for draft-grendler-idr-bgplu-epe X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 15:37:01 -0000 I am not aware of any IPR On Mar 16 14:43 PM, Susan Hares wrote: > This is an IPR call prior to a call for adoption for > draft-gredler-idr-bgplu-epe ( Egress Peer Engineering using BGP-LU) which > can be found at > > https://datatracker.ietf.org/doc/draft-gredler-idr-bgplu-epe/ > > > > Will the authors please indicate whether they know of any IPR on this draft? > > > > > Sue Hares > > > From nobody Fri Mar 17 18:49:56 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D80281294B6; Fri, 17 Mar 2017 18:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n4sygetDCOt7; Fri, 17 Mar 2017 18:49:54 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 434E4124D37; Fri, 17 Mar 2017 18:49:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4109; q=dns/txt; s=iport; t=1489801794; x=1491011394; h=from:to:cc:subject:date:message-id:mime-version; bh=m5ZqaYMzdmmbYMBbB/GP+phh6DHOjfBOZAd2oiDpsdc=; b=LMQ7fWawfHuEZSKiMtdUPX/1gJ1RSTBQGVAgVynKcDyPn2eiFmSBj0HC XBpV1p8XGATz35JZvkYcrJaBM86i2DdhDQxEaeIwUeIBUuPHv2oG684wd Q+hIYGXiPBuIUtr04SNGxb2birvt9Nu+SaDIVppR1ANWYMDN6jz384KGp E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AyAQC6kMxY/4YNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm45KmGBEY1qoW6FL4IOKoV4gwM/GAECAQEBAQEBAWsohUlKAhI?= =?us-ascii?q?BgQAmAQQBDQ2JeA61D4pLAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWGTo8oBZYBh?= =?us-ascii?q?kgBgVKFJotAkTSTUgEfOIEEWBV8hhyJIQGBDAEBAQ?= X-IronPort-AV: E=Sophos;i="5.36,178,1486425600"; d="scan'208,217";a="224854613" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Mar 2017 01:49:53 +0000 Received: from XCH-ALN-018.cisco.com (xch-aln-018.cisco.com [173.36.7.28]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v2I1nrxU031843 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 18 Mar 2017 01:49:53 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-018.cisco.com (173.36.7.28) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 17 Mar 2017 20:49:52 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Fri, 17 Mar 2017 20:49:52 -0500 From: "Jakob Heitz (jheitz)" To: "idr@ietf.org" , "idr-chairs@ietf.org" Thread-Topic: Early allocation for draft-ietf-idr-bgp-gr-notification Thread-Index: AdKfiYGhhTUsCANPSvWWpp5SshbNxA== Date: Sat, 18 Mar 2017 01:49:52 +0000 Message-ID: <4eedda5c2db74539bd0f949e38cb8b26@XCH-ALN-014.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [128.107.147.56] Content-Type: multipart/alternative; boundary="_000_4eedda5c2db74539bd0f949e38cb8b26XCHALN014ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [Idr] Early allocation for draft-ietf-idr-bgp-gr-notification X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Mar 2017 01:49:56 -0000 --_000_4eedda5c2db74539bd0f949e38cb8b26XCHALN014ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi chairs, We are implementing https://tools.ietf.org/html/draft-ietf-idr-bgp-gr-notification-09 and would like IANA to allocate the code 9 for the Hard Reset subcode in th= e BGP Cease NOTIFICATION message subcodes registry. Thanks, Jakob. --_000_4eedda5c2db74539bd0f949e38cb8b26XCHALN014ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi chairs,

 

We are implementing

https://tools.ietf.org/html/draft-ietf-id= r-bgp-gr-notification-09

and would like IANA to allocate the code 9 f= or the Hard Reset subcode in the

BGP Cease NOTIFICATION message subcodes regi= stry.

 

Thanks,

Jakob.

 

--_000_4eedda5c2db74539bd0f949e38cb8b26XCHALN014ciscocom_-- From nobody Sat Mar 18 03:54:33 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69AEC124BFA for ; Sat, 18 Mar 2017 03:54:32 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z7bLCZKXQw-j for ; Sat, 18 Mar 2017 03:54:30 -0700 (PDT) Received: from mail3.mlpsca01.us.to.gin.ntt.net (mail3.mlpsca01.us.to.gin.ntt.net [IPv6:2001:418:3ff:3::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 34991120727 for ; Sat, 18 Mar 2017 03:54:30 -0700 (PDT) Received: by mail3.mlpsca01.us.to.gin.ntt.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.88) (envelope-from ) id 1cpBzq-0000oI-Jn (job@us.ntt.net) for idr@ietf.org; Sat, 18 Mar 2017 10:54:30 +0000 Received: by mail-wm0-f45.google.com with SMTP id n11so32065677wma.1 for ; Sat, 18 Mar 2017 03:54:06 -0700 (PDT) X-Gm-Message-State: AFeK/H21TgkmY4lBxySmRsObm7pSOHX9mfjNaw+RPkW+8nRAmtqa6nowJx4WciT2A7gcJdeyfk/bVmMFpyBtLQ== X-Received: by 10.28.15.12 with SMTP id 12mr2196918wmp.22.1489834444795; Sat, 18 Mar 2017 03:54:04 -0700 (PDT) MIME-Version: 1.0 References: <4eedda5c2db74539bd0f949e38cb8b26@XCH-ALN-014.cisco.com> In-Reply-To: <4eedda5c2db74539bd0f949e38cb8b26@XCH-ALN-014.cisco.com> From: Job Snijders Date: Sat, 18 Mar 2017 10:53:53 +0000 X-Gmail-Original-Message-ID: Message-ID: To: "Jakob Heitz (jheitz)" , "idr-chairs@ietf.org" , "idr@ietf.org" Content-Type: multipart/alternative; boundary=001a11469342db6402054aff1c33 Archived-At: Subject: Re: [Idr] Early allocation for draft-ietf-idr-bgp-gr-notification X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Mar 2017 10:54:32 -0000 --001a11469342db6402054aff1c33 Content-Type: text/plain; charset=UTF-8 Hi everyone, Given the 50+ years of combined IETF experience the authors of this draft possess, I'm somewhat surprised to see a suggested value in the IANA considerations instead of "TBD". See the last major bullet point here: https://trac.ietf.org/trac/idr/wiki/Checklist%20for%20writing%20a%20BGP-related%20draft Jakob, thanks for kicking of the process to rectify this situation. Furthermore, shouldn't the "Hard Reset" be called "Really Really Really Reset"? I am skeptical whether the principles of graceful restart should be applied to the notification mechanism. In https://tools.ietf.org/html/draft-iops-grow-bgp-session-culling-00 we are describing a procedure that strongly relies on the currently understood semantics of expiration of BGP Hold Timers and the Administrative Shutdown: "STOP sending traffic". I find it hard to reconcile how we can have both "My control-plane temporarily going away, but keep sending traffic" and "data-plane is broken, bgp subsequently dies, don't send traffic". The exact failure scenario which triggers the expiration of the BGP Hold Timers cannot be known at OPEN when the capabilities are exchanged. The GR NOTIFICATION seems to distort the congruency between data-plane and control-plane. Perhaps there should be an implementation guideline which encourages vendors to by default, disable this mechanism on non-RFC3021/RFC6164 links? Has draft-idr-bgp-gr-notification been vetted in the wild? What were the results and under which circumstances is the mechanism useful? Am I missing something? Kind regards, Job On Sat, 18 Mar 2017 at 02:50, Jakob Heitz (jheitz) wrote: Hi chairs, We are implementing https://tools.ietf.org/html/draft-ietf-idr-bgp-gr-notification-09 and would like IANA to allocate the code 9 for the Hard Reset subcode in the BGP Cease NOTIFICATION message subcodes registry. Thanks, Jakob. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr --001a11469342db6402054aff1c33 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi everyone,

Given the 50+ years of combined IETF experience the authors of this draf= t possess, I'm somewhat surprised to see a suggested value in the IANA = considerations instead of "TBD". See the last major bullet point = here: https:= //trac.ietf.org/trac/idr/wiki/Checklist%20for%20writing%20a%20BGP-related%2= 0draft

Jakob, thanks for kicking of the process to rectify this situation.=C2=A0<= /div>

Furthermor= e, shouldn't the "Hard Reset" be called "Really Really R= eally Reset"? I am skeptical whether the principles of graceful restar= t should be applied to the notification mechanism. In=C2=A0https://tool= s.ietf.org/html/draft-iops-grow-bgp-session-culling-00 we are describin= g a procedure that strongly relies on the currently understood semantics of= expiration of BGP Hold Timers and the Administrative Shutdown: "STOP = sending traffic".

I find it hard to reconcile how we can have both "My co= ntrol-plane temporarily going away, but keep sending traffic" and &quo= t;data-plane is broken, bgp subsequently dies, don't send traffic"= . The exact failure scenario which triggers the expiration of the BGP Hold = Timers cannot be known at OPEN when the capabilities are exchanged. The GR = NOTIFICATION seems to distort the congruency between data-plane and control= -plane.=C2=A0

Perhaps there should be an implementation guideline which encourages ve= ndors to by default, disable this mechanism on non-RFC3021/RFC6164 links?

Has draft-idr-bgp-gr-notification been vetted in the wild? W= hat were the results and under which circumstances is the mechanism useful?= Am I missing something?

Kind regards,

Job

On Sat, 18 Mar 2017 at 02:50, Jakob Hei= tz (jheitz) <jheitz@cisco.com> wrote:

Hi chairs,

=C2=A0

We are impleme= nting

https://tools.ietf.org/html/draft-ietf-idr-bgp-g= r-notification-09=

and would like= IANA to allocate the code 9 for the Hard Reset subcode in the

BGP Cease NOTI= FICATION message subcodes registry.

=C2=A0

Thanks,

Jakob.

=C2=A0

_______________________________________________
Idr mailing list
Idr@i= etf.org
https://www.ietf.org/mailman/listinfo/i= dr
--001a11469342db6402054aff1c33-- From nobody Sat Mar 18 07:11:42 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4607D127775; Sat, 18 Mar 2017 07:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RCYbhVmwBgL2; Sat, 18 Mar 2017 07:11:39 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 3C02312751F; Sat, 18 Mar 2017 07:11:39 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=70.194.19.173; From: "Susan Hares" To: "'Jakob Heitz \(jheitz\)'" , , References: <4eedda5c2db74539bd0f949e38cb8b26@XCH-ALN-014.cisco.com> In-Reply-To: <4eedda5c2db74539bd0f949e38cb8b26@XCH-ALN-014.cisco.com> Date: Sat, 18 Mar 2017 10:06:47 -0400 Message-ID: <001101d29ff0$e21d3ca0$a657b5e0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0012_01D29FCF.5B0DBF80" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJNtEkTgzlTKZaIcQptCFnf9VYXeqCkeLPQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] Early allocation for draft-ietf-idr-bgp-gr-notification X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Mar 2017 14:11:41 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0012_01D29FCF.5B0DBF80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Jakob: The steps in this process are IPR call, and then call for the WG for allocation. Could you round up your authors to respond rapidly to the IPR call? Sue Hares From: Jakob Heitz (jheitz) [mailto:jheitz@cisco.com] Sent: Friday, March 17, 2017 9:50 PM To: idr@ietf.org; idr-chairs@ietf.org Cc: Mohammed Mirza (mohamirz) Subject: Early allocation for draft-ietf-idr-bgp-gr-notification Hi chairs, We are implementing https://tools.ietf.org/html/draft-ietf-idr-bgp-gr-notification-09 and would like IANA to allocate the code 9 for the Hard Reset subcode in the BGP Cease NOTIFICATION message subcodes registry. Thanks, Jakob. ------=_NextPart_000_0012_01D29FCF.5B0DBF80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Jakob: =

 

The steps in this = process are IPR call, and then call for the WG for = allocation.   Could you round up your authors to respond = rapidly to the IPR call?

 

Sue Hares =

 

From:= = Jakob Heitz (jheitz) [mailto:jheitz@cisco.com]
Sent: Friday, = March 17, 2017 9:50 PM
To: idr@ietf.org; = idr-chairs@ietf.org
Cc: Mohammed Mirza = (mohamirz)
Subject: Early allocation for = draft-ietf-idr-bgp-gr-notification

 

Hi = chairs,

 

We are implementing

https://tools.ietf.org/html/draft-ietf-idr-bgp-gr-notification-09

and = would like IANA to allocate the code 9 for the Hard Reset subcode in = the

BGP = Cease NOTIFICATION message subcodes registry.

 

Thanks,

Jakob.

 

------=_NextPart_000_0012_01D29FCF.5B0DBF80-- From nobody Mon Mar 20 06:29:46 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 792F4129495; Mon, 20 Mar 2017 06:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9oOJwrz4wh7M; Mon, 20 Mar 2017 06:29:35 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0097.outbound.protection.outlook.com [104.47.37.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9811B1270FC; Mon, 20 Mar 2017 06:29:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=bJk46ZmVhj/OJDZEgpRZWSpXhMIPlzmwL9w2Gu+3RqU=; b=JvMqqHqiFqHTA5HJB+OKDmzFNIImaWz9QSTsssLNEipZU7rI2eA2bRLPPkXHdotwoCIcJFIddYtVVtGv1LVhYcV1kGw0VQOzHzrgJrsJw7M0bR6ANV8LO5ZvqSBvu4P4JxCMSe3SSBXmk9P3EsjU6aUC53xKfQRdVZsVCx1HoKA= Received: from BLUPR0501MB2051.namprd05.prod.outlook.com (10.164.23.21) by BLUPR0501MB2051.namprd05.prod.outlook.com (10.164.23.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.4; Mon, 20 Mar 2017 13:29:32 +0000 Received: from BLUPR0501MB2051.namprd05.prod.outlook.com ([10.164.23.21]) by BLUPR0501MB2051.namprd05.prod.outlook.com ([10.164.23.21]) with mapi id 15.01.0991.011; Mon, 20 Mar 2017 13:29:32 +0000 From: Ron Bonica To: Susan Hares , "EXT - luis.tomotaki@verizon.com" , 'Shitanshu Shah' , "rtg-dir@ietf.org" , "draft-ietf-idr-sla-exchange.all@ietf.org" , "idr@ietf.org" Thread-Topic: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 Thread-Index: AdKIcLCEU+uutt39QyCrZCwOKAXyLQAcLKCoAUVZnUABwWlZAABkf7iDAEubxBAAGLyHgADK0jWAAYwzjCA= Date: Mon, 20 Mar 2017 13:29:32 +0000 Message-ID: References: , <053401d294fc$6f739180$4e5ab480$@ndzh.com> <467340A77F13C944919805BFF3B8ACFC30DC040408@FHDP1LUMXC7V91.us.one.verizon.com> <011601d2981f$cfe364c0$6faa2e40$@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;ndzh.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.14] x-microsoft-exchange-diagnostics: 1; BLUPR0501MB2051; 7:0d1dxxkpN+jUsF0/101t677slDp5oi9BpoN6mA4GCDrhyAmtrUVzXPqrgY1v3+IruSVmeSfC132EQgehMVcKLSmoQ2EV1KMEudaE5T6xt2mRNoKVSAPF2RAdXLIviGBf5Rwga0vVMejSmXkoFX1GTiSsUkpLz+Qa4h8s6pxqp1y4XVQiYfnqvuXBHw6tWyk8r7BQxSGNxwOvuOrxxJC8tdLVQR1eKGqlHeSmRfaPE/QnGdyyMNaQG2zkxqobZs10IuIQIkDSdVpMbug6za4brtrBXK5m5t0deeUJ3OUiuuyX+AunjIWjv6gWg317LCqxkUQMrht+fKJqW39squABzA== x-ld-processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr x-ms-office365-filtering-correlation-id: bae9b0c8-4209-47b4-5a18-08d46f9524fb x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081); SRVR:BLUPR0501MB2051; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(194151415913766)(21748063052155)(154440410675630); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123558025)(20161123562025)(20161123555025)(20161123560025)(20161123564025)(6072148); SRVR:BLUPR0501MB2051; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB2051; x-forefront-prvs: 02524402D6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39410400002)(39850400002)(39450400003)(39840400002)(39860400002)(377454003)(54094003)(3846002)(6116002)(229853002)(102836003)(790700001)(3280700002)(3660700001)(2906002)(33656002)(66066001)(76176999)(50986999)(54356999)(93886004)(5660300001)(122556002)(74316002)(7736002)(230783001)(189998001)(39060400002)(6246003)(2900100001)(38730400002)(8936002)(8676002)(53936002)(81166006)(7696004)(345774005)(6306002)(54896002)(6506006)(55016002)(99286003)(25786008)(236005)(77096006)(53946003)(2201001)(9686003)(2501003)(86362001)(6436002)(53546008); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB2051; H:BLUPR0501MB2051.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BLUPR0501MB2051A46E1EFCF5D7A295BB5AAE3A0BLUPR0501MB2051_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Mar 2017 13:29:32.4953 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB2051 Archived-At: Subject: Re: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 13:29:39 -0000 --_000_BLUPR0501MB2051A46E1EFCF5D7A295BB5AAE3A0BLUPR0501MB2051_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, Luis and I spoke on Friday. The following is a summary of our conversation: Draft-ietf-idr-sla-exchange proposes a mechanism through which a BGP speake= r associates a forwarding policy with a prefix. When a BGP listener receive= s an advertisement that is associated with a policy, it: - Instantiates the policy, if it does not already exist - Associates the prefix with the policy BGP listeners can instantiate a finite number of policies (N). SO, what ha= ppens when a BGP listener has N policies instantiated and it receives an ad= vertisement that would normally cause it to instantiate another policy? Opt= ions are: - Tear down the session - Discard the advertisement - Install the route, but without the advertisement - Do something else? We should probably be explicit about the required behavior. Ron From: Ron Bonica Sent: Sunday, March 12, 2017 12:11 PM To: 'Susan Hares' ; EXT - luis.tomotaki@verizon.com ; 'Shitanshu Shah' ; rtg-d= ir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; idr@ietf.org Subject: RE: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 Luis, This discussion might require a slightly higher bandwidth channel. Feel fre= e to call me whenever you get a chance. Ron 571 203 1= 704 From: Susan Hares [mailto:shares@ndzh.com] Sent: Wednesday, March 8, 2017 10:23 AM To: EXT - luis.tomotaki@verizon.com >; 'Shitanshu Shah' = >; Ron Bonica= >; rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; idr@ietf.org Subject: RE: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 Luis: Thank you for letting me know you desire for this feature. Since Ron had = additional questions, I'll let him start off this discussion. Sue From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Tomotaki, Luis M Sent: Tuesday, March 7, 2017 11:11 PM To: Shitanshu Shah; Susan Hares; 'Ron Bonica'; rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; idr@ietf.org Subject: Re: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 Ron and Sue, >From a service provider perspective, exchanging the SLA information between= the PE and CE would be very beneficial and could be widely used. I think = this is particular important in service provider's L3VPN networks where the= customers or service providers currently do not have full visibility to th= e QoS policy in the other end of the connection but still needs matching CE= -PE SLA/QoS policies to achieve the correct two-way traffic prioritization = behavior during congestion. In this example, once the SLA information exch= ange is standardized, my expectation is that the different CE/PE vendors wo= uld be able to automatically update in a vendor specific way, the SLA/QoS p= olicies based on the SLA information provided via BGP. Luis From: Shitanshu Shah [mailto:shitanshu_shah@hotmail.com] Sent: Monday, March 6, 2017 9:31 AM To: Susan Hares >; 'Ron Bonica' >; rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; idr@ietf.org Subject: [E] Re: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 Hi Sue, Following is what I had responded to Ron. Hopefully that addresses/clarifie= s. To break it down in two point response, 1) This draft is not changing how SLA is established at first place. The dr= aft is providing a method to convey this a priori established SLA to help r= educe lot of manual complexities and errors to admin. Thus given a knowledg= e of what SLA is established, in general devices should be capable to suppo= rt that established SLA. 2) If there still are any issues in implementing exchanged SLA in forwardin= g, we think they either are implementation specific or of temporary nature = where for example enough resources not available at any specific point of a= time. We feel that in current state of the draft, it can be largely useful in dep= loyments. One can imagine though even establishment of SLA also can be done via excha= nging it over bgp. However, negotiation of SLA does not have to be clubbed = with exchange of SLA. Negotiation of SLA is not in this scope. Regards, Shitanshu ________________________________ From: Susan Hares > Sent: Saturday, March 4, 2017 8:31 AM To: 'Ron Bonica'; 'Shitanshu Shah'; rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; idr@ietf.org Subject: RE: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 Shitanshu: Please address Ron's comment about widely deployed. I believe this was par= t of Alvaro's comments. Sue From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Ron Bonica Sent: Thursday, February 23, 2017 12:07 PM To: Shitanshu Shah; rtg-dir@ietf.org; draft-ietf-i= dr-sla-exchange.all@ietf.org; idr@ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 Hello, The draft is internally consistent. But given what is left out of scope, I = wonder if the new attributes will ever be widely deployed. = Ron This document might benefit from discussion of operational issues. I assume= that when a BGP listener learns a route with the SLA Exchange Attribute, i= t provisions class of service forwarding classes on interfaces. ##svshah, though this is one desired use of exchanging SLA content, the dra= ft focuses on transporting SLA content from the SLA Producer to the SLA Con= sumer. Processing of the QoS attribute content, at the SLA Consumer, is out= side the scope of this document. ##svshah, Let me know if you have a suggestion to make description clearer = in Section 1 and 2 to highlight this. I also assume that a) it takes time to provision class of service forwardin= g classes and b) the number of forwarding classes that can be provisioned a= re finite. What does the BGP listener do when the number of forwarding clas= ses requested exceeds its capacity to deliver? ##svshah, Since scope of the document is to transport SLA content from the = SLA Producer to the SLA Consumer, the document considers error handling in = the context of transporting data and thus any formating errors and semantic= s errors within that context. Any errors in the context of processing QoS a= ttribute content at the SLA Consumer is outside the scope of the document. --_000_BLUPR0501MB2051A46E1EFCF5D7A295BB5AAE3A0BLUPR0501MB2051_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

Luis and I spoke on Friday. The follo= wing is a summary of our conversation:

 

Draft-ietf-idr-sla-exchange proposes = a mechanism through which a BGP speaker associates a forwarding policy with= a prefix. When a BGP listener receives an advertisement t= hat is associated with a policy, it:

 

<= span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif;c= olor:#1F497D">-        =   Instantiates the policy, if i= t does not already exist

<= span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif;c= olor:#1F497D">-        =   Associates the prefix with th= e policy

 

BGP listeners can instantiate a finite number of policies (N). &nbs= p;SO, what happens when a BGP listener has N policies instantiated and it receives an advertisement that would normally cause it= to instantiate another policy? Options are:

 

<= span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif;c= olor:#1F497D">-        =   Tear down the session

<= span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif;c= olor:#1F497D">-        =   Discard the advertisement

<= span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif;c= olor:#1F497D">-        =   Install the route, but withou= t the advertisement

<= span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif;c= olor:#1F497D">-        =   Do something else?=

 

We should probably be explicit about the required behavior.

 

           &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;       Ron

 

 

From: Ron Bonica
Sent: Sunday, March 12, 2017 12:11 PM
To: 'Susan Hares' <shares@ndzh.com>; EXT - luis.tomotaki@veriz= on.com <luis.tomotaki@verizon.com>; 'Shitanshu Shah' <shitanshu_sh= ah@hotmail.com>; rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.= org; idr@ietf.org
Subject: RE: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-excha= nge-10

 

Luis,

 

This discussion might require a sligh= tly higher bandwidth channel. Feel free to call me whenever you get a chanc= e.

 

      &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;        Ron

      &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;         571 203 1704

 

 

From: Susan Hares [mailto:shares@ndzh.com]
Sent: Wednesday, March 8, 2017 10:23 AM
To: EXT - luis.tomotaki= @verizon.com <luis.tomo= taki@verizon.com>; 'Shitanshu Shah' <shitanshu_shah@hotmail.com>; Ron Bonica <rbonica@juniper.net<= /a>>; rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; idr@ietf.org
Subject: RE: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-excha= nge-10

 

Luis:

 

Thank you for letting me know you des= ire for this feature.   Since Ron had additional questions, IR= 17;ll let him start off this discussion.

 

Sue

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Tomotaki, Luis M
Sent: Tuesday, March 7, 2017 11:11 PM
To: Shitanshu Shah; Susan Hares; 'Ron Bonica'; rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; idr@ietf.org
Subject: Re: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-excha= nge-10

 

Ron and Sue,

From a service provider perspective, = exchanging the SLA information between the PE and CE would be very benefici= al and could be widely used.  I think this is particular important in service provider’s L3VPN networks where the = customers or service providers currently do not have full visibility to the= QoS policy in the other end of the connection but still needs matching CE-= PE SLA/QoS policies to achieve the correct two-way traffic prioritization behavior during congestion.  In this e= xample, once the SLA information exchange is standardized, my expectation i= s that the different CE/PE vendors would be able to automatically update in= a vendor specific way, the SLA/QoS policies based on the SLA information provided via BGP. 

 

Luis

 

From: Shitanshu Shah [mailto:shitanshu_shah@hotmail.com]
Sent: Monday, March 6, 2017 9:31 AM
To: Susan Hares <shares@ndzh.c= om>; 'Ron Bonica' <rbonica= @juniper.net>; rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; idr@ietf.org
Subject: [E] Re: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchang= e-10

 

H= i Sue,

<= o:p> 

F= ollowing is what I had responded to Ron. Hopefully that addresses/clar= ifies.

<= o:p> 

T= o break it down in two point response,

<= o:p> 

1= ) This draft is not changing how SLA is established at first place. The dra= ft is providing a method to convey this a priori established SLA = to help reduce lot of manual complexities and errors to admin. Thus given a knowledge of what SLA is established, in general devic= es should be capable to support that established SLA.

<= o:p> 

<= o:p> 

2= ) If there still are any issues in implementing exchanged SLA in forwarding= , we think they either are implementation specific or of temporary nat= ure where for example enough resources not available at any specific point of a time.

<= o:p> 

W= e feel that in current state of the draft, it can be largely useful in depl= oyments.

<= o:p> 

<= o:p> 

<= o:p> 

O= ne can imagine though even establishment of SLA also can be done via e= xchanging it over bgp. However, negotiation of SLA does not have to be club= bed with exchange of SLA. Negotiation of SLA is not in this scope.

<= o:p> 

Regards,

Shitanshu

 <= /p>

From: Susan = Hares <shares@ndzh.com>
Sent: Saturday, March 4, 2017 8:31 AM
To: 'Ron Bonica'; 'Shitanshu Shah'; rtg-dir@ietf.org; draft-ietf-idr-= sla-exchange.all@ietf.org; idr@ietf.org
Subject: RE: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10=

 

Shitanshu:

 

Please address Ron’s comment about widely dep= loyed.  I believe this was part of Alvaro’s comments.

 

Sue

 

From: rtg-dir [mailto:rtg-dir-bounces@ietf.o= rg] On Behalf Of Ron Bonica
Sent: Thursday, February 23, 2017 12:07 PM
To: Shitanshu Shah; rtg-dir@ietf= .org; draft-ietf-idr-= sla-exchange.all@ietf.org; idr@ietf.org
Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10=

 

Hello,

 

The draft is internally consistent. But given what = is left out of scope, I wonder if the new attributes will ever be widely deployed.

 

        &nb= sp;            =             &nb= sp;            =             &nb= sp;            =          Ron

 

 


This document might benefit from discussion of operational issues. I assume= that when a BGP listener learns a route with the SLA Exchange Attribute, i= t provisions class of service forwarding classes on interfaces.

 <= /span>

##svshah, = though this is one desired use of exchanging SLA content, the draft focuses= on transporting SLA content from the SLA Producer to the SLA Consumer. Pro= cessing of the QoS attribute content, at the SLA Consumer, is outside the scope of this document.<= /span>

 

##svshah, = Let me know if you have a suggestion to make description clearer in Section= 1 and 2 to highlight this.

 <= /span>

 <= /span>

I also assume that a) it takes time to provision clas= s of service forwarding classes and b) the number of forwarding classes that can be provisioned are finite. What does the BG= P listener do when the number of forwarding classes requested exceeds its c= apacity to deliver? 

 <= /span>

##svshah, = Since scope of the document is to transport SLA content from the SLA Produc= er to the SLA Consumer, the document considers error handling in the contex= t of transporting data and thus any formating errors and semantics errors within that context. Any errors in t= he context of processing QoS attribute content at the SLA Consumer is outsi= de the scope of the document.

 

 <= /span>

 <= /span>

--_000_BLUPR0501MB2051A46E1EFCF5D7A295BB5AAE3A0BLUPR0501MB2051_-- From nobody Mon Mar 20 07:05:01 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6902131491; Mon, 20 Mar 2017 07:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q0ohqkUmykYS; Mon, 20 Mar 2017 07:04:51 -0700 (PDT) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::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 7642E12949B; Mon, 20 Mar 2017 07:04:51 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id g138so96586176itb.0; Mon, 20 Mar 2017 07:04:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=KTXpOKSzMIwkf9Xc/62ZswKipaYYrqY887dNNARFRIM=; b=vfFLDyZBMsCa0/WsznnLhuK2llkEWySLsnrUDscs0Dzvl3utHVRMXvllL12+mf8LTE +dgsR0nEUNc/FaHQq6uakK8ql06xDC6vK9a31Jhz8zAlu5xoQY8UYj5mvDSMHxJiI07K yXos52OLdGfAc/qyEx4knL+N+UvmJR1bsxzP/aiBzK1ZBbH5bYueM3XhK6kvwxfIO/vQ K3wX6hUraZCB7mGZCa270i+UI0TnH452ZDx+O3D9dY/yqE8bLBFFNI2RpmewxeTqqWk9 6yOSfzG5NIhiRBVeSMZt4tjAdf7cPD9/iIqTAgipJE3tVvfcq2/NuvBdujyyRc80ha1L 5dvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=KTXpOKSzMIwkf9Xc/62ZswKipaYYrqY887dNNARFRIM=; b=cA1LglUbFDLd9XPVX6ZFAzAUDwFpogTFmRTjg+wXECZQJoUL+sclbI8Os0A28v9sb4 WD3dDlMRx4xeDdRO6gjaCm8XWDyGDV9gLducYhKdGOXc2VGJng0vmKe0gjHFagOfSpHs HV4Wdg4/93fNq2uc1BVy3sULyqFP2Ri3j6dJqHMa7bTiYNX+UdMfnIy7SgqgpQ28G16X 7Za4wpdFJuGvauO+7mE9bAF7zh3ZDP9d/6s6FqRtHJbI3l3TYWWtMWfcz795l8Lzvxcv YItOT9wYHPXKqwaIr2Wunav9O7CrcaGoTdIHR4zB+i7hCLFbVazYwJ0Oz0bQFz4UyiUz /yfg== X-Gm-Message-State: AFeK/H0Zi2o11Zl3qaifwIoCcRzYw+0WUUiQOje3JSSYWjTM5NRYQbY4psN8/cxeRMkxbXZ4om20TMpuaR+kpw== X-Received: by 10.107.16.217 with SMTP id 86mr26099682ioq.228.1490018689892; Mon, 20 Mar 2017 07:04:49 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.79.35.207 with HTTP; Mon, 20 Mar 2017 07:04:48 -0700 (PDT) Received: by 10.79.35.207 with HTTP; Mon, 20 Mar 2017 07:04:48 -0700 (PDT) In-Reply-To: References: <053401d294fc$6f739180$4e5ab480$@ndzh.com> <467340A77F13C944919805BFF3B8ACFC30DC040408@FHDP1LUMXC7V91.us.one.verizon.com> <011601d2981f$cfe364c0$6faa2e40$@ndzh.com> From: Robert Raszuk Date: Mon, 20 Mar 2017 15:04:48 +0100 X-Google-Sender-Auth: mo2ZSTEoGX0UDPwMcvDDh3hfyME Message-ID: To: Ronald Bonica Cc: "EXT - luis.tomotaki@verizon.com" , Susan Hares , "rtg-dir@ietf.org" , "idr@ietf.org" , "draft-ietf-idr-sla-exchange.all@ietf.org" , Shitanshu Shah Content-Type: multipart/alternative; boundary=001a113ecee8b87c7f054b2a02df Archived-At: Subject: Re: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 14:05:00 -0000 --001a113ecee8b87c7f054b2a02df Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Ron, The behaviour in the case you are bringing up could be a local policy. * ignore-when-overlap * overwrite-when-overlap Overlap means with local policy. Optionally you also can have a route map attach to both and apply such policy on a per prefix basis. Cheers R. On Mar 20, 2017 2:29 PM, "Ron Bonica" wrote: > Folks, > > > > Luis and I spoke on Friday. The following is a summary of our conversatio= n: > > > > Draft-ietf-idr-sla-exchange proposes a mechanism through which a BGP > speaker associates a forwarding policy with a prefix. When a BGP listener > receives an advertisement that is associated with a policy, it: > > > > - Instantiates the policy, if it does not already exist > > - Associates the prefix with the policy > > > > BGP listeners can instantiate a finite number of policies (N). SO, what > happens when a BGP listener has N policies instantiated and it receives a= n > advertisement that would normally cause it to instantiate another policy? > Options are: > > > > - Tear down the session > > - Discard the advertisement > > - Install the route, but without the advertisement > > - Do something else? > > > > We should probably be explicit about the required behavior. > > > > Ron > > > > > > *From:* Ron Bonica > *Sent:* Sunday, March 12, 2017 12:11 PM > *To:* 'Susan Hares' ; EXT - luis.tomotaki@verizon.com < > luis.tomotaki@verizon.com>; 'Shitanshu Shah' = ; > rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; idr@ietf.org > *Subject:* RE: [Idr] [RTG-DIR] RtgDir review: > draft-ietf-idr-sla-exchange-10 > > > > Luis, > > > > This discussion might require a slightly higher bandwidth channel. Feel > free to call me whenever you get a chance. > > > > Ron > > 571 203 > 1704 <(571)%20203-1704> > > > > > > *From:* Susan Hares [mailto:shares@ndzh.com ] > *Sent:* Wednesday, March 8, 2017 10:23 AM > *To:* EXT - luis.tomotaki@verizon.com ; > 'Shitanshu Shah' ; Ron Bonica < > rbonica@juniper.net>; rtg-dir@ietf.org; draft-ietf-idr-sla-exchange. > all@ietf.org; idr@ietf.org > *Subject:* RE: [Idr] [RTG-DIR] RtgDir review: > draft-ietf-idr-sla-exchange-10 > > > > Luis: > > > > Thank you for letting me know you desire for this feature. Since Ron ha= d > additional questions, I=E2=80=99ll let him start off this discussion. > > > > Sue > > > > *From:* Idr [mailto:idr-bounces@ietf.org ] *On > Behalf Of *Tomotaki, Luis M > *Sent:* Tuesday, March 7, 2017 11:11 PM > *To:* Shitanshu Shah; Susan Hares; 'Ron Bonica'; rtg-dir@ietf.org; > draft-ietf-idr-sla-exchange.all@ietf.org; idr@ietf.org > *Subject:* Re: [Idr] [RTG-DIR] RtgDir review: > draft-ietf-idr-sla-exchange-10 > > > > Ron and Sue, > > From a service provider perspective, exchanging the SLA information > between the PE and CE would be very beneficial and could be widely used. = I > think this is particular important in service provider=E2=80=99s L3VPN ne= tworks > where the customers or service providers currently do not have full > visibility to the QoS policy in the other end of the connection but still > needs matching CE-PE SLA/QoS policies to achieve the correct two-way > traffic prioritization behavior during congestion. In this example, once > the SLA information exchange is standardized, my expectation is that the > different CE/PE vendors would be able to automatically update in a vendor > specific way, the SLA/QoS policies based on the SLA information provided > via BGP. > > > > Luis > > > > *From:* Shitanshu Shah [mailto:shitanshu_shah@hotmail.com > ] > *Sent:* Monday, March 6, 2017 9:31 AM > *To:* Susan Hares ; 'Ron Bonica' ; > rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; idr@ietf.org > *Subject:* [E] Re: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-1= 0 > > > > Hi Sue, > > > > Following is what I had responded to Ron. Hopefully that > addresses/clarifies. > > > > To break it down in two point response, > > > > 1) This draft is not changing how SLA is established at first place. The > draft is providing a method to convey this a priori established SLA to he= lp > reduce lot of manual complexities and errors to admin. Thus given a > knowledge of what SLA is established, in general devices should be capabl= e > to support that established SLA. > > > > > > 2) If there still are any issues in implementing exchanged SLA in > forwarding, we think they either are implementation specific or of > temporary nature where for example enough resources not available at any > specific point of a time. > > > > We feel that in current state of the draft, it can be largely useful in > deployments. > > > > > > > > One can imagine though even establishment of SLA also can be done via > exchanging it over bgp. However, negotiation of SLA does not have to be > clubbed with exchange of SLA. Negotiation of SLA is not in this scope. > > > > Regards, > > Shitanshu > > > ------------------------------ > > *From:* Susan Hares > *Sent:* Saturday, March 4, 2017 8:31 AM > *To:* 'Ron Bonica'; 'Shitanshu Shah'; rtg-dir@ietf.org; > draft-ietf-idr-sla-exchange.all@ietf.org; idr@ietf.org > *Subject:* RE: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 > > > > Shitanshu: > > > > Please address Ron=E2=80=99s comment about widely deployed. I believe th= is was > part of Alvaro=E2=80=99s comments. > > > > Sue > > > > *From:* rtg-dir [mailto:rtg-dir-bounces@ietf.org > ] * On Behalf Of *Ron Bonica > *Sent:* Thursday, February 23, 2017 12:07 PM > *To:* Shitanshu Shah; rtg-dir@ietf.org; draft-ietf-idr-sla-exchange. > all@ietf.org; idr@ietf.org > *Subject:* Re: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 > > > > Hello, > > > > The draft is internally consistent. But given what is left out of scope, = I > wonder if the new attributes will ever be widely deployed. > > > > > Ron > > > > > > > This document might benefit from discussion of operational issues. I > assume that when a BGP listener learns a route with the SLA Exchange > Attribute, it provisions class of service forwarding classes on interface= s. > > > > ##svshah, though this is one desired use of exchanging SLA content, the > draft focuses on transporting SLA content from the SLA Producer to the SL= A > Consumer. Processing of the QoS attribute content, at the SLA Consumer, i= s > outside the scope of this document. > > > > ##svshah, Let me know if you have a suggestion to make description cleare= r > in Section 1 and 2 to highlight this. > > > > > > I also assume that a) it takes time to provision class of service > forwarding classes and b) the number of forwarding classes that can be > provisioned are finite. What does the BGP listener do when the number of > forwarding classes requested exceeds its capacity to deliver? > > > > ##svshah, Since scope of the document is to transport SLA content from th= e > SLA Producer to the SLA Consumer, the document considers error handling i= n > the context of transporting data and thus any formating errors and > semantics errors within that context. Any errors in the context of > processing QoS attribute content at the SLA Consumer is outside the scope > of the document. > > > > > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > --001a113ecee8b87c7f054b2a02df Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Ron,

The = behaviour in the case you are bringing up could be a local policy.

* ignore-when-overlap
* overwrite-when-overlap

Overlap means with local policy. Optionally you also can have= a route map attach to both and apply such policy on a per prefix basis.

Cheers
R.

On Mar 20, 2017 2:29 PM, "Ron Bonica" <rbonica@juniper.net> wrote:

Folks,

=C2=A0

Luis and I spoke on Friday. The follo= wing is a summary of our conversation:

=C2=A0

Draft-ietf-idr-sla-exchange proposes = a mechanism through which a BGP speaker associates a forwarding policy with= a prefix. When a BGP listener recei= ves an advertisement that is associated with a policy, it:

=C2=A0

-=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Instantiates the policy, if it d= oes not already exist

-=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Associates the prefix with the p= olicy

=C2=A0

BGP listeners can instantiate a= finite number of policies (N).=C2=A0 SO, what happens when a BGP listener = has N policies instantiated and it receives an advertisement that would normally cause it= to instantiate another policy? Options are:

=C2=A0

-=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Tear down the session<= /u>

-=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Discard the advertisement=

-=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Install the route, but without t= he advertisement

-=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Do something else?=

=C2=A0

We should probably be explicit = about the required behavior.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 Ron

=C2=A0

=C2=A0

=C2=A0

Luis,

=C2=A0

This discussion might require a sligh= tly higher bandwidth channel. Feel free to call me whenever you get a chanc= e.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Ron

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0571 203 1704

=C2=A0

=C2=A0

From: Susan Hares [mailto:shares@ndzh.com]
Sent: Wednesday, March 8, 2017 10:23 AM
To: EXT - luis.tomotaki@verizon.com <luis.tomotaki@verizon.com>; 'Shitansh= u Shah' <shitanshu_shah@hotmail.com>; Ron Bonica <rb= onica@juniper.net>; rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; idr@ietf.org
Subject: RE: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-excha= nge-10

=C2=A0

Luis:

=C2=A0

Thank you for letting me know you des= ire for this feature.=C2=A0 =C2=A0Since Ron had additional questions, I=E2= =80=99ll let him start off this discussion.

=C2=A0

Sue

=C2=A0

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Tomotaki, Luis M
Sent: Tuesday, March 7, 2017 11:11 PM
To: Shitanshu Shah; Susan Hares; 'Ron Bonica'; rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; idr@ietf.org
Subject: Re: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-excha= nge-10

=C2=A0

Ron and Sue,

From a service provider perspective, = exchanging the SLA information between the PE and CE would be very benefici= al and could be widely used.=C2=A0 I think this is particular important in service provider=E2=80=99s L3VPN networks where th= e customers or service providers currently do not have full visibility to t= he QoS policy in the other end of the connection but still needs matching C= E-PE SLA/QoS policies to achieve the correct two-way traffic prioritization behavior during congestion.=C2=A0 In this e= xample, once the SLA information exchange is standardized, my expectation i= s that the different CE/PE vendors would be able to automatically update in= a vendor specific way, the SLA/QoS policies based on the SLA information provided via BGP.=C2=A0 =

=C2=A0

Luis

=C2=A0

From: Shitanshu Shah [mailto:shitanshu_shah@hotmail.com]
Sent: Monday, March 6, 2017 9:31 AM
To: Susan Hares <shares@ndzh.com>; 'Ron Bonica' <rbonica@juniper.net>; rtg-dir@ietf.org;= draft-ietf-idr-sla-exchange.all@ietf.org; idr@ietf.org
Subject: [E] Re: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchang= e-10

=C2=A0

H= i Sue,

<= u>=C2=A0

F= ollowing is what I had responded to Ron. Hopefully=C2=A0that addresses/clar= ifies.

<= u>=C2=A0

T= o break it down in two point response,

<= u>=C2=A0

1= ) This draft is not changing how SLA is established at first place. The dra= ft=C2=A0is providing a method to convey this a priori established=C2=A0SLA = to help reduce lot of manual complexities and errors to admin. Thus given a knowledge of what SLA is established, in general devic= es should be capable to support that established=C2=A0SLA.

<= u>=C2=A0

<= u>=C2=A0

2= ) If there still are any issues in implementing exchanged SLA in forwarding= , we think they either are implementation specific or=C2=A0of temporary nat= ure where for example enough resources not available at any specific point of a time.

<= u>=C2=A0

W= e feel that in current state of the draft, it can be largely useful in depl= oyments.

<= u>=C2=A0

<= u>=C2=A0

<= u>=C2=A0

O= ne can imagine though even establishment of SLA also can=C2=A0be done via e= xchanging it over bgp. However, negotiation of SLA does not have to be club= bed with exchange of SLA. Negotiation of SLA is not in this scope.

<= u>=C2=A0

Regards,

Shitanshu

=C2=A0

From: Susan = Hares <shares@ndzh.= com>
Sent: Saturday, March 4, 2017 8:31 AM
To: 'Ron Bonica'; 'Shitanshu Shah'; rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; idr@ietf.org
Subject: RE: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10=

=C2=A0

Shitanshu:

=C2=A0

Please address Ron=E2=80=99s comment = about widely deployed.=C2=A0 I believe this was part of Alvaro=E2=80=99s co= mments.

=C2=A0

Sue

=C2=A0

From: rtg-dir [mailto:rtg-= dir-bounces@ietf.org] On Behalf Of Ron Bonica
Sent: Thursday, February 23, 2017 12:07 PM
To: Shitanshu Shah; rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; idr@ietf.org
Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10=

=C2=A0

Hello,

=C2=A0

The draft is internally consistent. B= ut given what is left out of scope, I wonder if the new attributes will ever be widely deployed.=

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= Ron

=C2=A0

=C2=A0


This document might benefit from discussion of operational issues. I assume= that when a BGP listener learns a route with the SLA Exchange Attribute, i= t provisions class of service forwarding classes on interfaces.

=C2=A0

##svshah, = though this is one desired use of exchanging SLA content, the draft focuses= on transporting SLA content from the SLA Producer to the SLA Consumer. Pro= cessing of the QoS attribute content, at the SLA Consumer, is outside the scope of this document.

=C2=A0

##svshah, = Let me know if you have a suggestion to make description clearer in Section= 1 and 2 to highlight this.

=C2=A0

=C2=A0

I also assume that a) it takes time to = provision class of service forwarding classes and b) the number of forwarding classes that can be provisioned are finite. What does the BG= P listener do when the number of forwarding classes requested exceeds its c= apacity to deliver?=C2=A0<= /span>

=C2=A0

##svshah, = Since scope of the document is to transport SLA content from the SLA Produc= er to the SLA Consumer, the document considers error handling in the contex= t of transporting data and thus any formating errors and semantics errors within that context. Any errors in t= he context of processing QoS attribute content at the SLA Consumer is outsi= de the scope of the document.

=C2=A0

=C2=A0

=C2=A0


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

--001a113ecee8b87c7f054b2a02df-- From nobody Mon Mar 20 08:55:45 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D88E1294BF; Mon, 20 Mar 2017 08:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGcizE1fDwbz; Mon, 20 Mar 2017 08:55:34 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 88AD1127863; Mon, 20 Mar 2017 08:55:33 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=50.36.87.190; From: "Susan Hares" To: "'Ron Bonica'" , , "'Shitanshu Shah'" , , , References: , <053401d294fc$6f739180$4e5ab480$@ndzh.com> <467340A77F13C944919805BFF3B8ACFC30DC040408@FHDP1LUMXC7V91.us.one.verizon.com> <011601d2981f$cfe364c0$6faa2e40$@ndzh.com> In-Reply-To: Date: Mon, 20 Mar 2017 11:50:27 -0400 Message-ID: <020c01d2a191$b2699740$173cc5c0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_020D_01D2A170.2B5C15F0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH+U8bIprcHIBv9vIIxWXYNekqkjQJ00uVDAja9hsUCLb3BQwJAbTElA0kpQQ0Bpe8MPwJC59+eoMQdvbA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 15:55:37 -0000 This is a multipart message in MIME format. ------=_NextPart_000_020D_01D2A170.2B5C15F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Ron: Thank you for taking the time to talk with Luis, and for giving us the concise and informative summary. Sue From: Ron Bonica [mailto:rbonica@juniper.net] Sent: Monday, March 20, 2017 9:30 AM To: Susan Hares; EXT - luis.tomotaki@verizon.com; 'Shitanshu Shah'; rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; idr@ietf.org Subject: RE: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 Folks, Luis and I spoke on Friday. The following is a summary of our conversation: Draft-ietf-idr-sla-exchange proposes a mechanism through which a BGP speaker associates a forwarding policy with a prefix. When a BGP listener receives an advertisement that is associated with a policy, it: - Instantiates the policy, if it does not already exist - Associates the prefix with the policy BGP listeners can instantiate a finite number of policies (N). SO, what happens when a BGP listener has N policies instantiated and it receives an advertisement that would normally cause it to instantiate another policy? Options are: - Tear down the session - Discard the advertisement - Install the route, but without the advertisement - Do something else? We should probably be explicit about the required behavior. Ron From: Ron Bonica Sent: Sunday, March 12, 2017 12:11 PM To: 'Susan Hares' ; EXT - luis.tomotaki@verizon.com ; 'Shitanshu Shah' ; rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; idr@ietf.org Subject: RE: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 Luis, This discussion might require a slightly higher bandwidth channel. Feel free to call me whenever you get a chance. Ron 571 203 1704 From: Susan Hares [mailto:shares@ndzh.com] Sent: Wednesday, March 8, 2017 10:23 AM To: EXT - luis.tomotaki@verizon.com ; 'Shitanshu Shah' ; Ron Bonica ; rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; idr@ietf.org Subject: RE: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 Luis: Thank you for letting me know you desire for this feature. Since Ron had additional questions, I'll let him start off this discussion. Sue From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Tomotaki, Luis M Sent: Tuesday, March 7, 2017 11:11 PM To: Shitanshu Shah; Susan Hares; 'Ron Bonica'; rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; idr@ietf.org Subject: Re: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 Ron and Sue, >From a service provider perspective, exchanging the SLA information between the PE and CE would be very beneficial and could be widely used. I think this is particular important in service provider's L3VPN networks where the customers or service providers currently do not have full visibility to the QoS policy in the other end of the connection but still needs matching CE-PE SLA/QoS policies to achieve the correct two-way traffic prioritization behavior during congestion. In this example, once the SLA information exchange is standardized, my expectation is that the different CE/PE vendors would be able to automatically update in a vendor specific way, the SLA/QoS policies based on the SLA information provided via BGP. Luis From: Shitanshu Shah [mailto:shitanshu_shah@hotmail.com] Sent: Monday, March 6, 2017 9:31 AM To: Susan Hares ; 'Ron Bonica' ; rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; idr@ietf.org Subject: [E] Re: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 Hi Sue, Following is what I had responded to Ron. Hopefully that addresses/clarifies. To break it down in two point response, 1) This draft is not changing how SLA is established at first place. The draft is providing a method to convey this a priori established SLA to help reduce lot of manual complexities and errors to admin. Thus given a knowledge of what SLA is established, in general devices should be capable to support that established SLA. 2) If there still are any issues in implementing exchanged SLA in forwarding, we think they either are implementation specific or of temporary nature where for example enough resources not available at any specific point of a time. We feel that in current state of the draft, it can be largely useful in deployments. One can imagine though even establishment of SLA also can be done via exchanging it over bgp. However, negotiation of SLA does not have to be clubbed with exchange of SLA. Negotiation of SLA is not in this scope. Regards, Shitanshu _____ From: Susan Hares Sent: Saturday, March 4, 2017 8:31 AM To: 'Ron Bonica'; 'Shitanshu Shah'; rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; idr@ietf.org Subject: RE: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 Shitanshu: Please address Ron's comment about widely deployed. I believe this was part of Alvaro's comments. Sue From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Ron Bonica Sent: Thursday, February 23, 2017 12:07 PM To: Shitanshu Shah; rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; idr@ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 Hello, The draft is internally consistent. But given what is left out of scope, I wonder if the new attributes will ever be widely deployed. Ron This document might benefit from discussion of operational issues. I assume that when a BGP listener learns a route with the SLA Exchange Attribute, it provisions class of service forwarding classes on interfaces. ##svshah, though this is one desired use of exchanging SLA content, the draft focuses on transporting SLA content from the SLA Producer to the SLA Consumer. Processing of the QoS attribute content, at the SLA Consumer, is outside the scope of this document. ##svshah, Let me know if you have a suggestion to make description clearer in Section 1 and 2 to highlight this. I also assume that a) it takes time to provision class of service forwarding classes and b) the number of forwarding classes that can be provisioned are finite. What does the BGP listener do when the number of forwarding classes requested exceeds its capacity to deliver? ##svshah, Since scope of the document is to transport SLA content from the SLA Producer to the SLA Consumer, the document considers error handling in the context of transporting data and thus any formating errors and semantics errors within that context. Any errors in the context of processing QoS attribute content at the SLA Consumer is outside the scope of the document. ------=_NextPart_000_020D_01D2A170.2B5C15F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ron:

 

Thank you for taking the time to talk with Luis, and for giving us = the concise and informative summary.

 

Sue

 

From:= = Ron Bonica [mailto:rbonica@juniper.net]
Sent: Monday, March = 20, 2017 9:30 AM
To: Susan Hares; EXT - = luis.tomotaki@verizon.com; 'Shitanshu Shah'; rtg-dir@ietf.org; = draft-ietf-idr-sla-exchange.all@ietf.org; = idr@ietf.org
Subject: RE: [Idr] [RTG-DIR] RtgDir review: = draft-ietf-idr-sla-exchange-10

 

Folks,

 

Luis and I spoke on Friday. The following is a summary of our = conversation:

 

Draft-ietf-idr-sla-exchange proposes a mechanism through which a BGP = speaker associates a forwarding policy with a prefix. When a BGP listener receives an advertisement = that is associated with a policy, it:

 

-     &nb= sp;    Instantiates the policy, if it does not already = exist

-     &nb= sp;    Associates the prefix with the policy

 

BGP listeners can instantiate a finite number of policies (N). =  SO, what happens when a BGP listener has N policies instantiated = and it receives an advertisement that would normally cause it to = instantiate another policy? Options are:

 

-     &nb= sp;    Tear down the session

-     &nb= sp;    Discard the advertisement

-     &nb= sp;    Install the route, but without the = advertisement

-     &nb= sp;    Do something else?

 

We should probably be explicit about the required = behavior.

 

           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;        = Ron

 

 

From: Ron = Bonica
Sent: Sunday, March 12, 2017 12:11 PM
To: = 'Susan Hares' <shares@ndzh.com>; EXT - luis.tomotaki@verizon.com = <luis.tomotaki@verizon.com&g= t;; 'Shitanshu Shah' <shitanshu_shah@hotmail.com= >; rtg-dir@ietf.org; draft-ietf-idr-s= la-exchange.all@ietf.org; idr@ietf.org
Subject: RE: = [Idr] [RTG-DIR] RtgDir review: = draft-ietf-idr-sla-exchange-10

 

Luis,

 

This discussion might require a slightly higher bandwidth channel. = Feel free to call me whenever you get a chance.

 

           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;    Ron

           &nbs= p;            = ;            =             &= nbsp;            =      571 203 1704

 

 

From: Susan = Hares [mailto:shares@ndzh.com] =
Sent: Wednesday, March 8, 2017 10:23 AM
To: EXT - = luis.tomotaki@verizon.com = <luis.tomotaki@verizon.com&g= t;; 'Shitanshu Shah' <shitanshu_shah@hotmail.com= >; Ron Bonica <rbonica@juniper.net>; rtg-dir@ietf.org; draft-ietf-idr-s= la-exchange.all@ietf.org; idr@ietf.org
Subject: RE: = [Idr] [RTG-DIR] RtgDir review: = draft-ietf-idr-sla-exchange-10

 

Luis:

 

Thank you for letting me know you desire for this feature.  =  Since Ron had additional questions, I’ll let him start off = this discussion.

 

Sue

 

From:= = Idr [mailto:idr-bounces@ietf.org] = On Behalf Of Tomotaki, Luis M
Sent: Tuesday, March 7, = 2017 11:11 PM
To: Shitanshu Shah; Susan Hares; 'Ron Bonica'; = rtg-dir@ietf.org; draft-ietf-idr-s= la-exchange.all@ietf.org; idr@ietf.org
Subject: Re: = [Idr] [RTG-DIR] RtgDir review: = draft-ietf-idr-sla-exchange-10

 

Ron and Sue,

From a service provider perspective, exchanging the SLA information = between the PE and CE would be very beneficial and could be widely = used.  I think this is particular important in service = provider’s L3VPN networks where the customers or service providers = currently do not have full visibility to the QoS policy in the other end = of the connection but still needs matching CE-PE SLA/QoS policies to = achieve the correct two-way traffic prioritization behavior during = congestion.  In this example, once the SLA information exchange is = standardized, my expectation is that the different CE/PE vendors would = be able to automatically update in a vendor specific way, the SLA/QoS = policies based on the SLA information provided via BGP.  =

 

Luis

 

From: Shitanshu = Shah [mailto:shitanshu_shah@hotmail.= com]
Sent: Monday, March 6, 2017 9:31 AM
To: = Susan Hares <shares@ndzh.com>; 'Ron Bonica' = <rbonica@juniper.net>; = rtg-dir@ietf.org; draft-ietf-idr-s= la-exchange.all@ietf.org; idr@ietf.org
Subject: [E] Re: = [RTG-DIR] RtgDir review: = draft-ietf-idr-sla-exchange-10

 

Hi = Sue,

 

Following is = what I had responded to Ron. Hopefully that = addresses/clarifies.

 

To break it = down in two point response,

 

1) This draft = is not changing how SLA is established at first place. The draft is = providing a method to convey this a priori established SLA to help = reduce lot of manual complexities and errors to admin. Thus given a = knowledge of what SLA is established, in general devices should be = capable to support that = established SLA.

 

 

2) If there = still are any issues in implementing exchanged SLA in forwarding, we = think they either are implementation specific or of temporary = nature where for example enough resources not available at any specific = point of a time.

 

We feel that in = current state of the draft, it can be largely useful in = deployments.

 

 

 

One can imagine = though even establishment of SLA also can be done via exchanging it = over bgp. However, negotiation of SLA does not have to be clubbed with = exchange of SLA. Negotiation of SLA is not in this = scope.

 

Regards,

Shitanshu

 

From: Susan Hares <shares@ndzh.com>
Sent: = Saturday, March 4, 2017 8:31 AM
To: 'Ron Bonica'; 'Shitanshu = Shah'; rtg-dir@ietf.org; draft-ietf-idr-s= la-exchange.all@ietf.org; idr@ietf.org
Subject: RE: = [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 =

 

Shitanshu:

 

Please address Ron’s comment about widely deployed.  I = believe this was part of Alvaro’s comments.

 

Sue

 

 

Hello,

 

The draft is internally consistent. But given what is left out of = scope, I wonder if the new attributes will ever be widely = deployed.

 

           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;       Ron

 

 


This document might benefit from discussion of operational issues. = I assume that when a BGP listener learns a route with the SLA Exchange = Attribute, it provisions class of service forwarding classes on = interfaces.

 

##svshah, though = this is one desired use of exchanging SLA content, the draft focuses on = transporting SLA content from the SLA Producer to the SLA Consumer. = Processing of the QoS attribute content, at the SLA Consumer, is outside = the scope of this document.

 

##svshah, Let me = know if you have a suggestion to make description clearer in Section 1 = and 2 to highlight this.

 

 

I also assume that a) it takes time to provision class of service = forwarding classes and b) the number of forwarding classes that can be = provisioned are finite. What does the BGP listener do when the number of = forwarding classes requested exceeds its capacity to = deliver? 

 

##svshah, Since = scope of the document is to transport SLA content from the SLA Producer = to the SLA Consumer, the document considers error handling in the = context of transporting data and thus any formating errors and semantics = errors within that context. Any errors in the context of processing QoS = attribute content at the SLA Consumer is outside the scope of the = document.

 

 

 

------=_NextPart_000_020D_01D2A170.2B5C15F0-- From nobody Mon Mar 20 10:50:48 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F4881315EC for ; Mon, 20 Mar 2017 10:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TfN3Mfg_FzJN for ; Mon, 20 Mar 2017 10:50:44 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A97E31315C1 for ; Mon, 20 Mar 2017 10:50:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8701; q=dns/txt; s=iport; t=1490032200; x=1491241800; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=5VVrSqr44X7fbfhbS4wk0fu4Yl5a7ENgqIkAIg5Qwh0=; b=VuTejbcASBFFv5Kyvu0vPmElIR4kHOgS8gUSXUhiPJmyBA6G/GyAmVnT +n4utbPcQRQ/ZMNappsUbt/koGcltR8W2IzsnaFfX+BJ+428ZkflKufck aS8tZBUbUf79OPZtklxyb8/f9muewxxTae86Z0DGlkP6pR4Ae02noSFmq w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AwAQDoFdBY/4oNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm45KmGBCgeNa5FdkBSFL4IOKoV4AoMOPxgBAgEBAQEBAQFrKIU?= =?us-ascii?q?VAQEBAQMdEEoCEAIBCA4DBAEBKAcyFAkIAQEEAQ0FCIl4DqsFikYBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEYBYZOhG+FCoUvBZYEhkkBhniLQZE0k1cBHziBBFgVfIY?= =?us-ascii?q?cdYheAYEMAQEB?= X-IronPort-AV: E=Sophos;i="5.36,195,1486425600"; d="scan'208,217";a="397648081" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Mar 2017 17:49:59 +0000 Received: from XCH-ALN-019.cisco.com (xch-aln-019.cisco.com [173.36.7.29]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v2KHnx0P005743 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 20 Mar 2017 17:49:59 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-019.cisco.com (173.36.7.29) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 20 Mar 2017 12:49:59 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Mon, 20 Mar 2017 12:49:58 -0500 From: "Jakob Heitz (jheitz)" To: Susan Hares , "idr@ietf.org" , Keyur Patel , "Rex Fernando (rex)" , John Scudder , Jeff Haas Thread-Topic: Early allocation for draft-ietf-idr-bgp-gr-notification Thread-Index: AdKfiYGhhTUsCANPSvWWpp5SshbNxAAkUieAAGHXTWA= Date: Mon, 20 Mar 2017 17:49:58 +0000 Message-ID: <99dbc8e61ccc4eef977389a7e671d013@XCH-ALN-014.cisco.com> References: <4eedda5c2db74539bd0f949e38cb8b26@XCH-ALN-014.cisco.com> <001101d29ff0$e21d3ca0$a657b5e0$@ndzh.com> In-Reply-To: <001101d29ff0$e21d3ca0$a657b5e0$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [128.107.147.56] Content-Type: multipart/alternative; boundary="_000_99dbc8e61ccc4eef977389a7e671d013XCHALN014ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] Early allocation for draft-ietf-idr-bgp-gr-notification X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 17:50:46 -0000 --_000_99dbc8e61ccc4eef977389a7e671d013XCHALN014ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Keyur, Rex, John, Jeff, Do you know of any IPR related to the draft? Thanks, Jakob. From: Susan Hares [mailto:shares@ndzh.com] Sent: Saturday, March 18, 2017 7:07 AM To: Jakob Heitz (jheitz) ; idr@ietf.org; idr-chairs@ietf.= org Cc: Mohammed Mirza (mohamirz) Subject: RE: Early allocation for draft-ietf-idr-bgp-gr-notification Jakob: The steps in this process are IPR call, and then call for the WG for alloca= tion. Could you round up your authors to respond rapidly to the IPR call? Sue Hares From: Jakob Heitz (jheitz) [mailto:jheitz@cisco.com] Sent: Friday, March 17, 2017 9:50 PM To: idr@ietf.org; idr-chairs@ietf.org Cc: Mohammed Mirza (mohamirz) Subject: Early allocation for draft-ietf-idr-bgp-gr-notification Hi chairs, We are implementing https://tools.ietf.org/html/draft-ietf-idr-bgp-gr-notification-09 and would like IANA to allocate the code 9 for the Hard Reset subcode in th= e BGP Cease NOTIFICATION message subcodes registry. Thanks, Jakob. --_000_99dbc8e61ccc4eef977389a7e671d013XCHALN014ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Keyur, Rex, John, Jeff,

 

Do you know of any IPR related to the draft?=

 

Thanks,

Jakob.

 

From: Susan Hares [mailto:shares@ndzh.com] Sent: Saturday, March 18, 2017 7:07 AM
To: Jakob Heitz (jheitz) <jheitz@cisco.com>; idr@ietf.org; idr= -chairs@ietf.org
Cc: Mohammed Mirza (mohamirz) <mohamirz@cisco.com>
Subject: RE: Early allocation for draft-ietf-idr-bgp-gr-notification=

 

Jakob:

 

The steps in this proc= ess are IPR call, and then call for the WG for allocation.   Coul= d you round up your authors to respond rapidly to the IPR call?

 

Sue Hares <= /span>

 

From: Jakob Heitz (jheitz) [mailto:jheitz@cisco.com]
Sent: Friday, March 17, 2017 9:50 PM
To: idr@ietf.org; idr-chairs@ietf.org
Cc: Mohammed Mirza (mohamirz)
Subject: Early allocation for draft-ietf-idr-bgp-gr-notification

 

Hi chairs,

 

We are implementing

https://tools.ietf.org/html/draft-ietf-id= r-bgp-gr-notification-09

and would like IANA to allocate the code 9 f= or the Hard Reset subcode in the

BGP Cease NOTIFICATION message subcodes regi= stry.

 

Thanks,

Jakob.

 

--_000_99dbc8e61ccc4eef977389a7e671d013XCHALN014ciscocom_-- From nobody Mon Mar 20 10:55:50 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 915031315F4 for ; Mon, 20 Mar 2017 10:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.796, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft1331857.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BlFtPZZQM5IE for ; Mon, 20 Mar 2017 10:55:45 -0700 (PDT) Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.164]) (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 7A568131624 for ; Mon, 20 Mar 2017 10:54:59 -0700 (PDT) Received: from pure.maildistiller.com (unknown [10.110.50.29]) by dispatch1-us1.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTP id 09C5F60095; Mon, 20 Mar 2017 17:54:59 +0000 (UTC) X-Virus-Scanned: Proofpoint Essentials engine Received: from mx2-us1.ppe-hosted.com (unknown [10.110.49.251]) by pure.maildistiller.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 533768005B; Mon, 20 Mar 2017 17:54:58 +0000 (UTC) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03lp0024.outbound.protection.outlook.com [216.32.181.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx2-us1.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 2087380086; Mon, 20 Mar 2017 17:54:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT1331857.onmicrosoft.com; s=selector1-arrcus-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=x5pvKd5aEfe8RR9nDeoQdhP2KwRwQ2vH9gyooKCOCD8=; b=RGFiOz+sV37LU/7+ts0xPC5Fhva5X21VPPGQmvqKXjl1QOoA7dih/6XTyKrQ4rA1GwAPS93c+JQTB99IDgUHPskNIAhsODf+QlfYIxZ5LX+nCerO9ZPvUEmP5D+dBsJ9jLMHMBGxmVzhqg25nQfa/gbDGiSF9vv+zrY+15+ciPo= Received: from BY2PR18MB0262.namprd18.prod.outlook.com (10.163.72.152) by BY2PR18MB0263.namprd18.prod.outlook.com (10.163.72.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.977.11; Mon, 20 Mar 2017 17:54:38 +0000 Received: from BY2PR18MB0262.namprd18.prod.outlook.com ([10.163.72.152]) by BY2PR18MB0262.namprd18.prod.outlook.com ([10.163.72.152]) with mapi id 15.01.0977.019; Mon, 20 Mar 2017 17:54:38 +0000 From: Keyur Patel To: "Jakob Heitz (jheitz)" , Susan Hares , "idr@ietf.org" , "Rex Fernando (rex)" , "John Scudder" , Jeff Haas Thread-Topic: Early allocation for draft-ietf-idr-bgp-gr-notification Thread-Index: AQHSoaJoTGZHR3uLU0+i3gO9B13JQqGdjYEA Date: Mon, 20 Mar 2017 17:54:37 +0000 Message-ID: References: <4eedda5c2db74539bd0f949e38cb8b26@XCH-ALN-014.cisco.com> <001101d29ff0$e21d3ca0$a657b5e0$@ndzh.com> <99dbc8e61ccc4eef977389a7e671d013@XCH-ALN-014.cisco.com> In-Reply-To: <99dbc8e61ccc4eef977389a7e671d013@XCH-ALN-014.cisco.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;cisco.com; dmarc=none action=none header.from=arrcus.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2601:646:8981:c940:45ff:aec5:a503:d12e] x-microsoft-exchange-diagnostics: 1; BY2PR18MB0263; 7:nvcmusa+LVXyzdFTuUEV/RDZcAygvhqifq91ocgxek7jCDdeSHmLBmVCLUugGKHoW7F3KaRbEuTrWmrwZEeJr+kFQTLyajutJTtY/Qnofshm/mBa6mDvUoh4VGMnlbK4ScB9I4GoB5FQPlthxG9s5/D/+lSg1LX5NzRznl5G6/W1hCYFh88v/dihePX/NkBMUKK1wJbPiW+G6rfehfQeB3SCTYmuQD2a2DDh19gKZcjUHi6D0t1REwBMFCBZDud2vIN76bZ3LJkn5uB93Vmn21iGFw7f8ciIYaX3wj16NOUCO54c5vUAmQM2BdmJg/eCMsncH4voTZ4ldPlpxyloCg== x-ms-office365-filtering-correlation-id: 7ea9157b-3620-4621-5156-08d46fba2d4c x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075); SRVR:BY2PR18MB0263; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123558025)(20161123560025)(2016111802025)(20161123564025)(20161123562025)(20161123555025)(6043046)(6072148); SRVR:BY2PR18MB0263; BCL:0; PCL:0; RULEID:; SRVR:BY2PR18MB0263; x-forefront-prvs: 02524402D6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39410400002)(39450400003)(377454003)(6486002)(8666007)(2900100001)(122556002)(2950100002)(6246003)(38730400002)(25786008)(6436002)(606005)(6506006)(82746002)(6116002)(7736002)(7906003)(86362001)(102836003)(2501003)(33656002)(189998001)(53936002)(229853002)(15650500001)(3280700002)(8936002)(3660700001)(2420400007)(81166006)(83716003)(8676002)(77096006)(5660300001)(4326008)(36756003)(53546008)(99286003)(2906002)(54896002)(6306002)(10710500007)(6512007)(50986999)(76176999)(230783001)(54356999)(236005)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR18MB0263; H:BY2PR18MB0262.namprd18.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_E8DCE5F4D0164CB09FDD37B5A5F186AEarrcuscom_" MIME-Version: 1.0 X-OriginatorOrg: arrcus.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Mar 2017 17:54:37.6908 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 697b3529-5c2b-40cf-a019-193eb78f6820 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR18MB0263 X-MDID: 1490032498-X2V7AwUt99pM Archived-At: Subject: Re: [Idr] Early allocation for draft-ietf-idr-bgp-gr-notification X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 17:55:48 -0000 --_000_E8DCE5F4D0164CB09FDD37B5A5F186AEarrcuscom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SmFrb2IsDQoNCkkgYW0gbm90IGF3YXJlIG9mIGFueSBJUFIgcmVsYXRlZCB0byB0aGUgZHJhZnQu DQoNClJlZ2FyZHMsDQpLZXl1cg0KDQpGcm9tOiAiSmFrb2IgSGVpdHogKGpoZWl0eikiIDxqaGVp dHpAY2lzY28uY29tPg0KRGF0ZTogTW9uZGF5LCBNYXJjaCAyMCwgMjAxNyBhdCAxMDo0OSBBTQ0K VG86IFN1c2FuIEhhcmVzIDxzaGFyZXNAbmR6aC5jb20+LCAiaWRyQGlldGYub3JnIiA8aWRyQGll dGYub3JnPiwgS2V5dXIgUGF0ZWwgPGtleXVyQGFycmN1cy5jb20+LCAiUmV4IEZlcm5hbmRvIChy ZXgpIiA8cmV4QGNpc2NvLmNvbT4sIEpvaG4gU2N1ZGRlciA8amdzQGp1bmlwZXIubmV0PiwgSmVm ZiBIYWFzIDxqaGFhc0BqdW5pcGVyLm5ldD4NCkNjOiAiTW9oYW1tZWQgTWlyemEgKG1vaGFtaXJ6 KSIgPG1vaGFtaXJ6QGNpc2NvLmNvbT4NClN1YmplY3Q6IFJFOiBFYXJseSBhbGxvY2F0aW9uIGZv ciBkcmFmdC1pZXRmLWlkci1iZ3AtZ3Itbm90aWZpY2F0aW9uDQoNCktleXVyLCBSZXgsIEpvaG4s IEplZmYsDQoNCkRvIHlvdSBrbm93IG9mIGFueSBJUFIgcmVsYXRlZCB0byB0aGUgZHJhZnQ/DQoN ClRoYW5rcywNCkpha29iLg0KDQpGcm9tOiBTdXNhbiBIYXJlcyBbbWFpbHRvOnNoYXJlc0BuZHpo LmNvbV0NClNlbnQ6IFNhdHVyZGF5LCBNYXJjaCAxOCwgMjAxNyA3OjA3IEFNDQpUbzogSmFrb2Ig SGVpdHogKGpoZWl0eikgPGpoZWl0ekBjaXNjby5jb20+OyBpZHJAaWV0Zi5vcmc7IGlkci1jaGFp cnNAaWV0Zi5vcmcNCkNjOiBNb2hhbW1lZCBNaXJ6YSAobW9oYW1pcnopIDxtb2hhbWlyekBjaXNj by5jb20+DQpTdWJqZWN0OiBSRTogRWFybHkgYWxsb2NhdGlvbiBmb3IgZHJhZnQtaWV0Zi1pZHIt YmdwLWdyLW5vdGlmaWNhdGlvbg0KDQpKYWtvYjoNCg0KVGhlIHN0ZXBzIGluIHRoaXMgcHJvY2Vz cyBhcmUgSVBSIGNhbGwsIGFuZCB0aGVuIGNhbGwgZm9yIHRoZSBXRyBmb3IgYWxsb2NhdGlvbi4g ICBDb3VsZCB5b3Ugcm91bmQgdXAgeW91ciBhdXRob3JzIHRvIHJlc3BvbmQgcmFwaWRseSB0byB0 aGUgSVBSIGNhbGw/DQoNClN1ZSBIYXJlcw0KDQpGcm9tOiBKYWtvYiBIZWl0eiAoamhlaXR6KSBb bWFpbHRvOmpoZWl0ekBjaXNjby5jb21dDQpTZW50OiBGcmlkYXksIE1hcmNoIDE3LCAyMDE3IDk6 NTAgUE0NClRvOiBpZHJAaWV0Zi5vcmc8bWFpbHRvOmlkckBpZXRmLm9yZz47IGlkci1jaGFpcnNA aWV0Zi5vcmc8bWFpbHRvOmlkci1jaGFpcnNAaWV0Zi5vcmc+DQpDYzogTW9oYW1tZWQgTWlyemEg KG1vaGFtaXJ6KQ0KU3ViamVjdDogRWFybHkgYWxsb2NhdGlvbiBmb3IgZHJhZnQtaWV0Zi1pZHIt YmdwLWdyLW5vdGlmaWNhdGlvbg0KDQpIaSBjaGFpcnMsDQoNCldlIGFyZSBpbXBsZW1lbnRpbmcN Cmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWlkci1iZ3AtZ3Itbm90aWZp Y2F0aW9uLTA5DQphbmQgd291bGQgbGlrZSBJQU5BIHRvIGFsbG9jYXRlIHRoZSBjb2RlIDkgZm9y IHRoZSBIYXJkIFJlc2V0IHN1YmNvZGUgaW4gdGhlDQpCR1AgQ2Vhc2UgTk9USUZJQ0FUSU9OIG1l c3NhZ2Ugc3ViY29kZXMgcmVnaXN0cnkuDQoNClRoYW5rcywNCkpha29iLg0KDQo= --_000_E8DCE5F4D0164CB09FDD37B5A5F186AEarrcuscom_ Content-Type: text/html; charset="utf-8" Content-ID: <04695B0CAD39B442912A8E53B227F8D5@namprd18.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseToiTHVjaWRhIENvbnNvbGUiO30NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0 eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9y bWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox MS4wcHQ7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5r DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFs MA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJn aW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOiM3MDMwQTA7DQoJZm9udC13ZWln aHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsOw0KCXRleHQtZGVjb3JhdGlvbjpub25lIG5v bmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9u dC1mYW1pbHk6Q2FsaWJyaTsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJ Y29sb3I6IzcwMzBBMDsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7 DQoJdGV4dC1kZWNvcmF0aW9uOm5vbmUgbm9uZTt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9y OndpbmRvd3RleHQ7fQ0Kc3Bhbi5tc29JbnMNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgljb2xv cjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEu MGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2Nv bG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5KYWtvYiw8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhbSBub3QgYXdhcmUgb2YgYW55IElQUiByZWxhdGVk IHRvIHRoZSBkcmFmdC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkcyw8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPktleXVyPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZxdW90O0pha29iIEhl aXR6IChqaGVpdHopJnF1b3Q7ICZsdDtqaGVpdHpAY2lzY28uY29tJmd0Ozxicj4NCjxiPkRhdGU6 IDwvYj5Nb25kYXksIE1hcmNoIDIwLCAyMDE3IGF0IDEwOjQ5IEFNPGJyPg0KPGI+VG86IDwvYj5T dXNhbiBIYXJlcyAmbHQ7c2hhcmVzQG5kemguY29tJmd0OywgJnF1b3Q7aWRyQGlldGYub3JnJnF1 b3Q7ICZsdDtpZHJAaWV0Zi5vcmcmZ3Q7LCBLZXl1ciBQYXRlbCAmbHQ7a2V5dXJAYXJyY3VzLmNv bSZndDssICZxdW90O1JleCBGZXJuYW5kbyAocmV4KSZxdW90OyAmbHQ7cmV4QGNpc2NvLmNvbSZn dDssIEpvaG4gU2N1ZGRlciAmbHQ7amdzQGp1bmlwZXIubmV0Jmd0OywgSmVmZiBIYWFzICZsdDtq aGFhc0BqdW5pcGVyLm5ldCZndDs8YnI+DQo8Yj5DYzogPC9iPiZxdW90O01vaGFtbWVkIE1pcnph IChtb2hhbWlyeikmcXVvdDsgJmx0O21vaGFtaXJ6QGNpc2NvLmNvbSZndDs8YnI+DQo8Yj5TdWJq ZWN0OiA8L2I+UkU6IEVhcmx5IGFsbG9jYXRpb24gZm9yIGRyYWZ0LWlldGYtaWRyLWJncC1nci1u b3RpZmljYXRpb248L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6Ymxh Y2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6IzcwMzBBMCI+S2V5dXIsIFJleCwgSm9obiwgSmVmZiw8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjoj NzAzMEEwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjojNzAzMEEwIj5EbyB5b3Uga25vdyBvZiBhbnkgSVBSIHJlbGF0ZWQg dG8gdGhlIGRyYWZ0Pzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOiM3MDMwQTAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0x1Y2lkYSBDb25zb2xlJnF1b3Q7O2NvbG9yOiM3MDMwQTAiPlRoYW5r cyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0x1Y2lkYSBDb25zb2xlJnF1b3Q7 O2NvbG9yOiM3MDMwQTAiPkpha29iLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzcwMzBBMCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg Ymx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gU3VzYW4g SGFyZXMgW21haWx0bzpzaGFyZXNAbmR6aC5jb21dIDxicj4NCjxiPlNlbnQ6PC9iPiBTYXR1cmRh eSwgTWFyY2ggMTgsIDIwMTcgNzowNyBBTTxicj4NCjxiPlRvOjwvYj4gSmFrb2IgSGVpdHogKGpo ZWl0eikgJmx0O2poZWl0ekBjaXNjby5jb20mZ3Q7OyBpZHJAaWV0Zi5vcmc7IGlkci1jaGFpcnNA aWV0Zi5vcmc8YnI+DQo8Yj5DYzo8L2I+IE1vaGFtbWVkIE1pcnphIChtb2hhbWlyeikgJmx0O21v aGFtaXJ6QGNpc2NvLmNvbSZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IEVhcmx5IGFsbG9j YXRpb24gZm9yIGRyYWZ0LWlldGYtaWRyLWJncC1nci1ub3RpZmljYXRpb248bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5K YWtvYjogPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5UaGUgc3RlcHMgaW4g dGhpcyBwcm9jZXNzIGFyZSBJUFIgY2FsbCwgYW5kIHRoZW4gY2FsbCBmb3IgdGhlIFdHIGZvciBh bGxvY2F0aW9uLiZuYnNwOyZuYnNwOyBDb3VsZCB5b3Ugcm91bmQgdXAgeW91ciBhdXRob3JzIHRv IHJlc3BvbmQgcmFwaWRseSB0byB0aGUgSVBSIGNhbGw/DQo8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPlN1ZSBIYXJlcyA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OlRhaG9tYSI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OlRhaG9tYSI+IEpha29iIEhlaXR6IChqaGVpdHopIFs8YSBocmVmPSJtYWlsdG86 amhlaXR6QGNpc2NvLmNvbSI+bWFpbHRvOmpoZWl0ekBjaXNjby5jb208L2E+XQ0KPGJyPg0KPGI+ U2VudDo8L2I+IEZyaWRheSwgTWFyY2ggMTcsIDIwMTcgOTo1MCBQTTxicj4NCjxiPlRvOjwvYj4g PGEgaHJlZj0ibWFpbHRvOmlkckBpZXRmLm9yZyI+aWRyQGlldGYub3JnPC9hPjsgPGEgaHJlZj0i bWFpbHRvOmlkci1jaGFpcnNAaWV0Zi5vcmciPg0KaWRyLWNoYWlyc0BpZXRmLm9yZzwvYT48YnI+ DQo8Yj5DYzo8L2I+IE1vaGFtbWVkIE1pcnphIChtb2hhbWlyeik8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gRWFybHkgYWxsb2NhdGlvbiBmb3IgZHJhZnQtaWV0Zi1pZHItYmdwLWdyLW5vdGlmaWNhdGlv bjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOiM3MDMwQTAiPkhpIGNoYWlycyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojNzAzMEEwIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojNzAzMEEwIj5X ZSBhcmUgaW1wbGVtZW50aW5nPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6IzcwMzBBMCI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtaWRyLWJncC1nci1ub3RpZmljYXRpb24tMDkiPmh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWlkci1iZ3AtZ3Itbm90aWZpY2F0aW9uLTA5 PC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOiM3MDMwQTAiPmFuZCB3b3VsZCBsaWtlIElBTkEgdG8gYWxsb2NhdGUgdGhlIGNvZGUg OSBmb3IgdGhlIEhhcmQgUmVzZXQgc3ViY29kZSBpbiB0aGU8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojNzAzMEEwIj5CR1AgQ2Vhc2Ug Tk9USUZJQ0FUSU9OIG1lc3NhZ2Ugc3ViY29kZXMgcmVnaXN0cnkuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzcwMzBBMCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtMdWNpZGEgQ29uc29sZSZxdW90Oztj b2xvcjojNzAzMEEwIj5UaGFua3MsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtM dWNpZGEgQ29uc29sZSZxdW90Oztjb2xvcjojNzAzMEEwIj5KYWtvYi48L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_E8DCE5F4D0164CB09FDD37B5A5F186AEarrcuscom_-- From nobody Mon Mar 20 12:26:50 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCF721316A1 for ; Mon, 20 Mar 2017 12:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SErU11hpKBDL for ; Mon, 20 Mar 2017 12:26:47 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 098FF13169C for ; Mon, 20 Mar 2017 12:26:46 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 1B8C01E33F; Mon, 20 Mar 2017 15:33:06 -0400 (EDT) Date: Mon, 20 Mar 2017 15:33:06 -0400 From: Jeffrey Haas To: "Jakob Heitz (jheitz)" Cc: Susan Hares , "idr@ietf.org" , Keyur Patel , "Rex Fernando (rex)" , John Scudder , Jeff Haas Message-ID: <20170320193305.GB26130@pfrc.org> References: <4eedda5c2db74539bd0f949e38cb8b26@XCH-ALN-014.cisco.com> <001101d29ff0$e21d3ca0$a657b5e0$@ndzh.com> <99dbc8e61ccc4eef977389a7e671d013@XCH-ALN-014.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <99dbc8e61ccc4eef977389a7e671d013@XCH-ALN-014.cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Idr] Early allocation for draft-ietf-idr-bgp-gr-notification X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 19:26:49 -0000 On Mon, Mar 20, 2017 at 05:49:58PM +0000, Jakob Heitz (jheitz) wrote: > Keyur, Rex, John, Jeff, > > Do you know of any IPR related to the draft? I know of know IPR on this draft. -- Jeff From nobody Mon Mar 20 12:28:46 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA137131480; Mon, 20 Mar 2017 12:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mYSW2cZIkqSb; Mon, 20 Mar 2017 12:28:43 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id A75F113169C; Mon, 20 Mar 2017 12:28:42 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id E29A61E33F; Mon, 20 Mar 2017 15:35:02 -0400 (EDT) Date: Mon, 20 Mar 2017 15:35:02 -0400 From: Jeffrey Haas To: "Jakob Heitz (jheitz)" Cc: "idr@ietf.org" , "idr-chairs@ietf.org" Message-ID: <20170320193502.GC26130@pfrc.org> References: <4eedda5c2db74539bd0f949e38cb8b26@XCH-ALN-014.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4eedda5c2db74539bd0f949e38cb8b26@XCH-ALN-014.cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Idr] Early allocation for draft-ietf-idr-bgp-gr-notification X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 19:28:45 -0000 On Sat, Mar 18, 2017 at 01:49:52AM +0000, Jakob Heitz (jheitz) wrote: > We are implementing > https://tools.ietf.org/html/draft-ietf-idr-bgp-gr-notification-09 > and would like IANA to allocate the code 9 for the Hard Reset subcode in the > BGP Cease NOTIFICATION message subcodes registry. Further, Juniper has shipping code for this sub-code (9). I spent some time looking for my requests for early IANA allocation, and appear to have missed this in my queue. Given my prior presentations on such squatting, I shall accept a mea culpa on behalf of Juniper. Probably time to do a full draft audit to see what else I've missed. Sigh. -- Jeff From nobody Mon Mar 20 12:37:57 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29D2D12951B; Mon, 20 Mar 2017 12:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5kNm6_fS2qNO; Mon, 20 Mar 2017 12:37:54 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 722AF1274D2; Mon, 20 Mar 2017 12:37:54 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 8F6ED1E33F; Mon, 20 Mar 2017 15:44:14 -0400 (EDT) Date: Mon, 20 Mar 2017 15:44:14 -0400 From: Jeffrey Haas To: Job Snijders Cc: "Jakob Heitz (jheitz)" , "idr-chairs@ietf.org" , "idr@ietf.org" Message-ID: <20170320194414.GD26130@pfrc.org> References: <4eedda5c2db74539bd0f949e38cb8b26@XCH-ALN-014.cisco.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: Subject: Re: [Idr] Early allocation for draft-ietf-idr-bgp-gr-notification X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 19:37:56 -0000 Job, On Sat, Mar 18, 2017 at 10:53:53AM +0000, Job Snijders wrote: > Given the 50+ years of combined IETF experience the authors of this draft > possess, I'm somewhat surprised to see a suggested value in the IANA > considerations instead of "TBD". See the last major bullet point here: > https://trac.ietf.org/trac/idr/wiki/Checklist%20for%20writing%20a%20BGP-related%20draft Unfortunately it's not an uncommon practice, and one we're moving out of thankfully. If you look around other working groups, even other BGP working groups like bess, it's not uncommon. > Furthermore, shouldn't the "Hard Reset" be called "Really Really Really > Reset"? I am skeptical whether the principles of graceful restart should be > applied to the notification mechanism. In > https://tools.ietf.org/html/draft-iops-grow-bgp-session-culling-00 we are > describing a procedure that strongly relies on the currently understood > semantics of expiration of BGP Hold Timers and the Administrative Shutdown: > "STOP sending traffic". I haven't yet read this draft, so take my further comments with that under consideration. > I find it hard to reconcile how we can have both "My control-plane > temporarily going away, but keep sending traffic" and "data-plane is > broken, bgp subsequently dies, don't send traffic". The exact failure > scenario which triggers the expiration of the BGP Hold Timers cannot be > known at OPEN when the capabilities are exchanged. The GR NOTIFICATION > seems to distort the congruency between data-plane and control-plane. > > Perhaps there should be an implementation guideline which encourages > vendors to by default, disable this mechanism on non-RFC3021/RFC6164 links? > > Has draft-idr-bgp-gr-notification been vetted in the wild? What were the > results and under which circumstances is the mechanism useful? Am I missing > something? The non-obvious connection is it's a requirement of draft-uttaro-idr-bgp-persistence (long-lived graceful restart). There's code shipping for this feature. I *believe* that it's another vendor as well, but can't confirm from memory. There has been some discussion that LLGR needs to be resurrected from zombie draft state. -- Jeff From nobody Mon Mar 20 12:43:25 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17DCD1293DB for ; Mon, 20 Mar 2017 12:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.697 X-Spam-Level: X-Spam-Status: No, score=-4.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BeTazfdGZ2Qi for ; Mon, 20 Mar 2017 12:43:21 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0124.outbound.protection.outlook.com [104.47.34.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5ADF128D3E for ; Mon, 20 Mar 2017 12:43:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=fN4YF8Hssazz1UaQswBmmelfUgcsGhSiePCcygt4ZAk=; b=I3+46+GN2CB4EU6UNMGYKNXAmSJojcujzljNM3hBOnloke0H2OBoEv4bLYYdPVdYXbWnZCUc1cdBQ218wGDAeEdHFHzviE4dU5bFqyABLGPky5xIxOLuzu+jDvyXPzDwiK4hOktNLAV4zc3vRZU3jByyQyrc3MAaEEfwNmRDatA= Authentication-Results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=juniper.net; Received: from [172.29.37.164] (66.129.241.12) by SN2PR05MB2510.namprd05.prod.outlook.com (10.166.213.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.4; Mon, 20 Mar 2017 19:43:20 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_DE5B7734-16FB-496C-B45F-9680B8FD1531" MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "John G. Scudder" In-Reply-To: <99dbc8e61ccc4eef977389a7e671d013@XCH-ALN-014.cisco.com> Date: Mon, 20 Mar 2017 15:43:15 -0400 CC: Susan Hares , "idr@ietf.org" , Keyur Patel , "Rex Fernando (rex)" , Jeff Haas , "Mohammed Mirza (mohamirz)" Message-ID: References: <4eedda5c2db74539bd0f949e38cb8b26@XCH-ALN-014.cisco.com> <001101d29ff0$e21d3ca0$a657b5e0$@ndzh.com> <99dbc8e61ccc4eef977389a7e671d013@XCH-ALN-014.cisco.com> To: "Jakob Heitz (jheitz)" X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.12] X-ClientProxiedBy: BN6PR20CA0015.namprd20.prod.outlook.com (10.173.158.153) To SN2PR05MB2510.namprd05.prod.outlook.com (10.166.213.19) X-MS-Office365-Filtering-Correlation-Id: eff3a05c-1df4-4a53-3336-08d46fc95d3a X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:SN2PR05MB2510; X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2510; 3:HZMgShH8QQyhnu99pIHyL1yi1S3ogysDjS/swUx0DR/A9MaFhpLwxxXmfn0AM3xfiRPFw8PKWI4DFsTvbO4fgyQQTIkRwdDYC34hWpxqN+NF+JBiym5Z9fp5FRY1j4f3iHYeg4ncIQRx3lsLfiHKMb+wxuMy1FxoNQ1hn4YsKvHV//ZzYxufr5VaMCCn1W3Y+f+9d6Bk/ar8ehKrwyC+k9pw34oLPOVlQF6s6bBLInaq9CgAq25mKGl1jTR0OvNcysEZLPhsHHmpxMVg166EiJV78+YbHw9kq6miOVfmM2s=; 25:eFq9JqixUh2vbGTd28Yb43Z3DCIXaYu6wOskD0fi6fSeYLtllmkt8Y+ynxpjgmVXPqFM7v5PK009OMLk2Kxe4pHHUi8KcKlCwPLyDeNMrm6gDpNR+D8b629o2Ym0Xw73ZW6WVDblgxQtoch5kGnpL6Z4tO75hmfDBClXdSKAAOw0qRUYCpccPscK6vQ3V0z8KroiVatL5M+ebSCSrB8Fl6y8F6yz0rIflKNlpSVssCZCP7XB4shvDAZGCvMYbWkl7jWLgIVMPQ5PxAvZoD8PyoucbWncfH1uROVr0TCgmveMpxGHWrlfq5XbFDI7BFs/828yyedcF3vCcCV32SD0Dun2UZQih8dXHwSIv81IYTez5TnXWuFBMoXOuMRn0jgmb1tForjdy8TwjRLJmPk1uywZz6jkqsEnJQGHOxlB0HylsiPFxRshXMYe3H3TUtMVGbAPpht2RLdKxcc5XWRmIw== X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2510; 31:w97If4/pJvhsRzz4+BH42BzRFbQlc2Oc2o/0e/Hpiy80BuFa5+dJ7H66T6SqCIr5HhEMt2JK1z78E/tfpUYVpG02Z5KhgeTvW/b5eeeGcnpSzAqUovwA1uyEvcWMgBpoqbLP4cDf2shmCtc6piqFWEHurpw1ayVz7cEvek1nF9Ej/l0VLyROx9bM062bCUc4HQN40ALvmVikUbyoW7YaYmeZuM/02GZMN4gGMhOBVUUT9PG0lTnEVJdpRqeUhI61; 20:ZkYxRH2ji/OrGATwd0+DdgoSf32RHcmQrAqb4bM6GkwAzew40LwmVpbA2kJQSsjCVMUnCXe5z0Qs1WTnLCPRkwCLQoj3u+5XV2PLQ25/Z2m4jqo/fHLn/KIXOkYAtW2dONvwWgkJ6mDt1Yk45i3A8IGb1f98CLod9qI97fwOD19pWNELYC0UM4clXppLe+dD3nA7KAVPa9d410TfvSxDlwfMddvu2hhLrSijMcbsPSLuOm6DDpmX/7gXHS5SBYNei5qBlZfxYemIRovjgiOhESxxhOsGcyOdQRdZJ6KSxQRzdnwpZa1mlW8qliMmSKXDsK4k5IitroZLAXDksmuNNTUrTlOiWTSPIhbX3QXwI35HJRFy/ZSvKTO7ihQRSfmI7RCy16MPw1IQBwPI3KcP4QylO8mNbmtos063fbJzKLipfJ8woyvyq+S+3RH9DlW7MFyg7+o4O4Yxcqb1K0lSQeyOfcNPXZwUij5uS9DgGdJ12PlE8GW1m6/65oKcCVrjYgKfUf//oNO2vJ9GVBiMQ3m6qf2vquyWiV//o5Wpj3sShMnVn/E1U/82VYNGGA03xl+pEzYJiVRzoAkASgjXlAwKqvhdarNLJsJd18KehRE= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(95692535739014); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123564025)(20161123560025)(20161123558025)(20161123562025)(20161123555025)(6072148); SRVR:SN2PR05MB2510; BCL:0; PCL:0; RULEID:; SRVR:SN2PR05MB2510; X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2510; 4:uWhiMPQxE8j4aRv9dAazO1Rp/EuCQytf+OeicgOHTJuPipL+DMsLFSSpV1fXHs/CgQbxAguVxaZmM9m11L+nbY3BKmAo79pD2PaFhSshwdt0lEgD06Sm1mYJDYEGtIMngm6AR6tYBX2vHHHlXw5IROzuIfy3tZRCEqVQbKfpv5QwOVViaaLzUGY6Nt2kCstHpDwfAktHL972CivR9JKyop8u3yeWkygzDDxyhRVInPz7+ZtMD3GA4WRR1Bo8Os7ruvH1pQintjJEp0bTh5BC2kwaAwpcVt02sb9prWu4/1wYdmV3wbBac78qZPrtMQFOni1e9QKwqZ0+TMFfS31PquAsatgpURC6fRZTH880tj9Vwoh2awm91ecpGAKoo8B0UmVE3ciJ/TtEx+ITwquq6VVOMAIliFNEWC+YC0qnbqJALkBjyHHsph6UrDXcf1csb08Vo9KHNW/+lhJt7tYOYqMotKpLZbi7DFbn/nyoW7W2xMyJETjR7HoVSKlDIyR3N2OTjoZrFZGgn1F56krTmpyKGEHZ79eHlEQd74i9PTRLfzQnq6ZFcHwuFjm+RAOCvtvyRGlrO0hqmnfqAWXDMaxc6bNZkMlLE+hwif4UiMxqwOFalQ03oxOvsODtgRk4TImw5XgjCNyrgp84MrRCYriWNcZnreLqKbAtbBj/9t0= X-Forefront-PRVS: 02524402D6 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(39840400002)(39850400002)(39860400002)(39410400002)(39450400003)(377454003)(24454002)(5660300001)(82746002)(229853002)(66066001)(2950100002)(6246003)(6916009)(2906002)(57306001)(7906003)(110136004)(189998001)(38730400002)(69556001)(7736002)(230783001)(33656002)(77096006)(83716003)(512954002)(6486002)(81166006)(86362001)(42186005)(8676002)(4326008)(50226002)(53936002)(6116002)(606005)(25786008)(76176999)(36756003)(15650500001)(50986999)(6666003)(6306002)(236005)(3846002)(54906002)(260700001)(53546008)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR05MB2510; H:[172.29.37.164]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN2PR05MB2510; 23:n/gXe/3CklFiS5mYKvnhszg17roWhQIbl5G5yCtN0?= =?us-ascii?Q?zyqlhHtWdJAAcwGYjX5clcf3wmFOfiSzk9OVkRTFgADVXp/Ial6OkTnQpWCZ?= =?us-ascii?Q?2Erij5xG25sqwTLBzC8bbyzdJbQAp2aLoQd6LniZaxGkGhbBVpoATD4WMugH?= =?us-ascii?Q?hHhI7nRMhZWzEkcHaby0jYX6cpkK1SH4czNkLYk4czfRhmOXEUdVOz1l1c18?= =?us-ascii?Q?kq+ReFEUFQce7x0iy7f9TTyxlQWf907ObkCDK9bTmDxyr/x1D4wnluL8AwyI?= =?us-ascii?Q?cp9HwBoEhaYYom6Y7xTEif1RNBYtJML5dn/O98DH01ZFK2P0yokavDWosbWH?= =?us-ascii?Q?b6BohhRbyXjEJeHGmML/ULYnBElpbmlOtnxfPAMRwsCIBaxCyVjoumFfTILk?= =?us-ascii?Q?XBJJKiM52i34DdJf2RETygDTzvWmoz/ZMdaXZcGBV8ewt55Ftf50kGItsC72?= =?us-ascii?Q?bTRESJx9W42Jv0VVnqdmZn5zxPGkuJL4JgMI+pRCpka8hEQyzrheDpR38P0O?= =?us-ascii?Q?qX7AcV7H1RM/WNdtD4ruOa2FsaYsdoxm2i37jrpverOhj7LMFON8q1VDAd5g?= =?us-ascii?Q?Z9SHfUjovL5+KfOaezS0Rq7yB9iO+fxJbvIYNMx+ENRJwDWVr7Rvf+h7BJ2g?= =?us-ascii?Q?NNOxI6JhBJogyabQbnrWe+zijXzJ7LROf2NjeoS6utVc90/bSkubEDTzCXoI?= =?us-ascii?Q?i2hUJuF5eL3yAWw4jgq9bgtFLVKVFspvbFzQHw8MieDEIAGIlypqALaAQS5M?= =?us-ascii?Q?MC72xEpFXi+2Qm6hqyw+Kv2l1Twmnj6IC0D/jKBQqdvWsTrOJY0iWkiVdoH/?= =?us-ascii?Q?b6hFBINBYb8I0FQPGzSA1YydCej2POFTwI36f5T/H2py5pVTXIJIM8maEszh?= =?us-ascii?Q?UPKpiVowGyYEthblRoovZq3lDfmbe8RHGKkkFdsjNzFIXi9JRGcN1yuMipBB?= =?us-ascii?Q?gosy0u65LKZD4FWYuzvWDjdaowUNjNBdRbm4QAPP/BEPM+8OjsNHkPrF3dKy?= =?us-ascii?Q?ooB9GpKkM9K9oQhqdK7gkBU6J8ofcbBUE1OQ409OwZeRK7uR+o5Ej8+iJcuE?= =?us-ascii?Q?6h/RESP4C+0RJrnL6OqlM8tt1O0ine0xISFCY3bdnNpMJmdECH68YL80wOej?= =?us-ascii?Q?kxmqgda9dNIfupJQwPJWRTKQMAaOcH5NUAOa1MF6kc+4B02bvaZ6umMmDzDR?= =?us-ascii?Q?1OnJ9Sh/stqNBrJUtviF6h6NWesbjkGYeiBW2nSm7ZyfUqyc1IIL7mB8mXMn?= =?us-ascii?Q?XzfFYjpN7q7aeU4z9MbSlCZSacKO57MalD/mOf45jPT+Fp/tiLwo+T+hD6+S?= =?us-ascii?B?dz09?= X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2510; 6:1aCyvdRf7GCfRFWAA7Z/9z7XcxV6zg+Up6chn6eaElOAEMJjsExA2spsIEv+LuvZFhKK4cZiUGltIr/ndWs8BmVa9vZHCqAgSC24ItoMAowbWEttveokP7AbTNnWz+GrChid2pIkcNURzm1pDpXdo1CjwbTSRFHpXgu71FTCImAEVH9srUP0S+oIGlNLih4jNIr2jutNZfmYofHuWFBZcJnzbGnHPjfg7cQBzkER83TfuAAJuc/q1haqDGwAisGKSh9ueZWGfdyKhyyJL5+nKAEnFyYozV3qpr0BGMFS4wwxbXsja8SJtRKjOYW/CiOCBDRWco+ozOBtD+veGpW7sIZ6f9WsOARr3tUw3ZCtnBHfheXWl38zqGGcK8iIfO+aF4yUlmyvNxzdKXRsMKnGwckM2QoXm32p96WRGameSVs=; 5:sTUfo7ahzogr+jEIi9FjcBL8i0oz+ZTafhN6AEW534/hxKXtJ75hTi9WmFtoOXpZmVmWl4QFZUoi5TjgIwg2Zf1lwpWTdSkjZbHZRlzTvHloLAoCjx9ppIC5YPfbwAz3TCUY470aI4VoKrEw6qt37w==; 24:3Q8za3u+DZeQTf+9Z+ksEKxwDR2LNMfPWwv1HdyFuCEnfFx/gGFEnEH3k5E/CMbeoBt1qlD1RUoDBXNsoZkj9fOYYLDiXb6Rtg+J3iT2RCQ= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2510; 7:U/6mFgwJ3Z2bW+bgUi+wqVg/Yp5EfjN+ueo0xydSlXCReKKbAJUUyy8c2xdxjnE8cJPvtOvIC+pFPOts93pp4qeHifJhRVy9qx7goy3NBxwWb+oJuYdPxueicnxD2VnzZZI/3SBaznOrWTOls4wGR542hxztbf9Xw0rUKTuXTP3NEANlKLdAa7HbaCBFw/zHaPQpzidXuiTQJLrgA/jxaP9pGh7DqS2kgMuQ+IWMsVw1d6tAOh17vf3X1YWtsmM9MRk5My1+AgHRFeNx2L7D1HTUHanYNKz74gmp2tZWS5sysRgW1F8j3q3JRs6tJ9eFbUOg3ADwAQCe2IwEtS4L+Q== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Mar 2017 19:43:20.0440 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR05MB2510 Archived-At: Subject: Re: [Idr] Early allocation for draft-ietf-idr-bgp-gr-notification X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 19:43:24 -0000 --Apple-Mail=_DE5B7734-16FB-496C-B45F-9680B8FD1531 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" Nope. --John > On Mar 20, 2017, at 1:49 PM, Jakob Heitz (jheitz) = wrote: >=20 > Keyur, Rex, John, Jeff, > =20 > Do you know of any IPR related to the draft? > =20 > Thanks, > Jakob. > =20 > From: Susan Hares [mailto:shares@ndzh.com]=20 > Sent: Saturday, March 18, 2017 7:07 AM > To: Jakob Heitz (jheitz) ; idr@ietf.org; = idr-chairs@ietf.org > Cc: Mohammed Mirza (mohamirz) > Subject: RE: Early allocation for draft-ietf-idr-bgp-gr-notification > =20 > Jakob:=20 > =20 > The steps in this process are IPR call, and then call for the WG for = allocation. Could you round up your authors to respond rapidly to the = IPR call? > =20 > Sue Hares=20 > =20 > From: Jakob Heitz (jheitz) [mailto:jheitz@cisco.com = ]=20 > Sent: Friday, March 17, 2017 9:50 PM > To: idr@ietf.org ; idr-chairs@ietf.org = > Cc: Mohammed Mirza (mohamirz) > Subject: Early allocation for draft-ietf-idr-bgp-gr-notification > =20 > Hi chairs, > =20 > We are implementing > https://tools.ietf.org/html/draft-ietf-idr-bgp-gr-notification-09 = > and would like IANA to allocate the code 9 for the Hard Reset subcode = in the > BGP Cease NOTIFICATION message subcodes registry. > =20 > Thanks, > Jakob. --Apple-Mail=_DE5B7734-16FB-496C-B45F-9680B8FD1531 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii" Nope.

--John

On Mar 20, 2017, at 1:49 PM, = Jakob Heitz (jheitz) <jheitz@cisco.com> wrote:

Keyur, Rex, John, Jeff,
 
Do you know of any IPR related to = the draft?
 
Thanks,
Jakob.
 
From: Susan Hares [mailto:shares@ndzh.com] 
Sent: Saturday, March 18, 2017 = 7:07 AM
To: Jakob Heitz (jheitz) <jheitz@cisco.com>; idr@ietf.org; idr-chairs@ietf.org
Cc: Mohammed Mirza (mohamirz) = <mohamirz@cisco.com>
Subject: RE: Early allocation for = draft-ietf-idr-bgp-gr-notification
 
Jakob: 
 
The steps = in this process are IPR call, and then call for the WG for = allocation.   Could you round up your authors to respond = rapidly to the IPR call?
 
Sue Hares 
 
From: Jakob = Heitz (jheitz) [mailto:jheitz@cisco.com] 
Sent: Friday, March 17, 2017 9:50 = PM
To: idr@ietf.org; idr-chairs@ietf.org
Cc: Mohammed Mirza = (mohamirz)
Subject: Early allocation for = draft-ietf-idr-bgp-gr-notification
 
Hi chairs,
 
We are = implementing
and would like IANA to allocate = the code 9 for the Hard Reset subcode in the
BGP Cease NOTIFICATION message subcodes = registry.
 
Thanks,
Jakob.

= --Apple-Mail=_DE5B7734-16FB-496C-B45F-9680B8FD1531-- From nobody Mon Mar 20 12:45:14 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3013D1293DA for ; Mon, 20 Mar 2017 12:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id reApap9wo8SJ for ; Mon, 20 Mar 2017 12:45:11 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 1FBD51292FC for ; Mon, 20 Mar 2017 12:45:11 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 6035E1E33F; Mon, 20 Mar 2017 15:51:31 -0400 (EDT) Date: Mon, 20 Mar 2017 15:51:31 -0400 From: Jeffrey Haas To: "John G. Scudder" Cc: "Jakob Heitz (jheitz)" , "idr@ietf.org" , Keyur Patel , Jeff Haas , Susan Hares Message-ID: <20170320195131.GE26130@pfrc.org> References: <4eedda5c2db74539bd0f949e38cb8b26@XCH-ALN-014.cisco.com> <001101d29ff0$e21d3ca0$a657b5e0$@ndzh.com> <99dbc8e61ccc4eef977389a7e671d013@XCH-ALN-014.cisco.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: Subject: Re: [Idr] Early allocation for draft-ietf-idr-bgp-gr-notification X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 19:45:13 -0000 Jakob points out: : Jeff, : : I'm not sure how pedantic lawyers get about typos :) : know-->no So, yes, I know of *no* IPR on this draft. -- Jeff (whose brain is apparently running on autopilot homonym mode) : : Thanks, : Jakob. : : : > -----Original Message----- : > From: Jeffrey Haas [mailto:jhaas@pfrc.org] : > Sent: Monday, March 20, 2017 12:33 PM : > To: Jakob Heitz (jheitz) : > Cc: Susan Hares ; idr@ietf.org; Keyur Patel : > ; Rex Fernando (rex) ; : > John Scudder ; Jeff Haas : > Subject: Re: [Idr] Early allocation for draft-ietf-idr-bgp-gr-notification : > : > : > On Mon, Mar 20, 2017 at 05:49:58PM +0000, Jakob Heitz (jheitz) wrote: : > > Keyur, Rex, John, Jeff, : > > : > > Do you know of any IPR related to the draft? : > : > I know of know IPR on this draft. : > From nobody Mon Mar 20 12:45:43 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B474129353; Mon, 20 Mar 2017 12:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6tJZDC-Fco5; Mon, 20 Mar 2017 12:45:39 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0113.outbound.protection.outlook.com [104.47.36.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A5C41292FC; Mon, 20 Mar 2017 12:45:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ke5Q86rWfoOOi36q0k7E0/G08bLyuXEDjimj83NaXEA=; b=EnRpA8ap1Qp3jlvLZK6B/7Ur0Iow8Gt57ZFQh+nz3mmXlxN36bOghBWLaHMcxGEiyPxEgiYjyujWp4VXkddwjVxJ2pagJHBLlcyzOMIB4D2JYpvZgRBnQjI+zbKQu79hDprNFnceA/5dphJhfU3H5oy18P3ncuuM2ymCcsmMmHE= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; Received: from [172.29.37.164] (66.129.241.12) by CO2PR05MB2501.namprd05.prod.outlook.com (10.166.95.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.4; Mon, 20 Mar 2017 19:45:36 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_C7823EB7-EC0E-458C-A86A-07F4415CBC65" MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "John G. Scudder" In-Reply-To: Date: Mon, 20 Mar 2017 15:45:31 -0400 CC: "Jakob Heitz (jheitz)" , "idr-chairs@ietf.org" , "idr@ietf.org" Message-ID: <530CFCF4-36BE-426C-AAE5-55BC680810DB@juniper.net> References: <4eedda5c2db74539bd0f949e38cb8b26@XCH-ALN-014.cisco.com> To: Job Snijders X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.12] X-ClientProxiedBy: BN6PR09CA0015.namprd09.prod.outlook.com (10.172.16.25) To CO2PR05MB2501.namprd05.prod.outlook.com (10.166.95.147) X-MS-Office365-Filtering-Correlation-Id: 759c0340-5b23-4f0d-be39-08d46fc9ae88 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CO2PR05MB2501; X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2501; 3:ZQUGy58x8Mg2FOOgeCyqsMdjQ6GpODer0QcZXbDWZkYTUJ+RqHQ+KaQRbPYGSkmK6K+3rU2QNSdjozaKE3t2eQ+JofoX93H4FRpzwd9PElK0JLNwel983KSKFTo0LgD5Y9+5QU6nZqyNNYEVrFmRT2L4ubA8R9J0m6qvpKlKuCz4tS5CP1rZKuSiJvlj5GMIyrVKULZbiWVGpN2wi1JNYQKaTNId7G7QkPAK/avojG8iyLKXw8WBT6vSWjrlRSXalhofBEQLQHs1u6vq5xUTyWtzAn8gm5rSO5B7ks+MQRM=; 25:L0yJwGCK0FIQuWjJPek2S8MUnBRWBmfJwq9ky+uDbXvBBfeGo4VKGc+P2GXKnfldmaRMr7wsdCJMQ/NhpWpYmVWGHuwbGwUTsrEWG/pZ4IQIpvYsVXg4TEiUU/X71VG12KvfW0QGq8+uoW3ZSf72LzF6SQed2X6QCzJqS17z4BzlH7155wfm7IkD4mIWS3UpSLbvVbbzvdVJ8qStNsqxN3OObXA0efu0cYJsNEoMXtZlYoJI+hscVxKspFfTf35MJTqRwRHSSkxUhK2zZ67ssnjojrRKBZaWs8cbUdYmsliccSs8EzybBD0BYYk9tNBlHdRvTOCLyMYhzqTMTzmd+a7AIKEPSiZLG0ndsQgME7B5e7pWQeFla5ciACWskw4ygLnWPRwvT0G1UrvTlwAgcqaFbn0AA8R1plE/1rrvliEkgs5wFiXyxrfk8okKTpJF/w1JJmBcgkLxSDMZtlfHnQ== X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2501; 31:Vv/A4NqX3TUe4Si2162FFlxFvgfeX16fIASHc7mnUIqvwF+0aF5EhBPJO1MK6QyodH8hk8lYAtI0sm558dwnVazcela3wq9gXGT5JDEiUCyKH9Sbkhptl85cyIeLDfMp8rRgRHPSV3HFBfsxZSDiTWgNlFTT2dI+H8gk2avJ9xyRdzR9ZDxYZzibSYdOiK3Wls1wd6EsAO+XwXPNNQpYgCUSWAPqynrSaJyGMH+4/Wli71GoouYzMRUjzKc7InKa69sfVT8uLnCvnOll0sf/Ow==; 20:iNLHcPeSArD819UKKS/WG5DRLg1V/zkClkObSElRtNSrwA9IyIY6M3gy3SDSHpLqaWCbMUE6sgI9JZe1q8+6E5iCGZUcOBB/A5b5Mk5zZOFoltPu2Zs4ohzyMN74NeY/3syOIETqhXca9yLKi83vUa10rtkDQhK0xZrAActLcZj+8CPazENdMi4wtnTWb/gDq17AAgpfj0jHlF62jM+q0kg7fA2YUluE44FHcaborTn54EUCy4w4/XbWytKHkKk28AZ6pEXUzuFH/BWkXAS9bjzJOVBuQa737HnpfFwYmp9AGlWJPh+3qYf6HZZHToHMQl3uwHyaqieqtrhVwleww1souITmkN57V+MYHTd+md8H5Ll0xLs0fp0C6jmJy/Oc92R8oFYlARwkDu5pqJ/UjyKGmnopzXT0pGgjKymwcq1DOTOXIhq5zMIz6kT74pabae3P9i5cnZaLts+iD82Og/qBHwUmohzdW1eHGLoArQv6WFSuPhi3gAAOJWFcffhpv48wU7c+G9xyFIKscPkbXrZwCNS1jQKj6er5Ke3iX2d1EFiOraGT5IxXhZaJYFrIWj6FVutT3B95AvCgT8GU88QlLX4HLbHcTVJVZ7JRemI= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123558025)(20161123564025)(20161123562025)(20161123560025)(20161123555025)(6072148); SRVR:CO2PR05MB2501; BCL:0; PCL:0; RULEID:; SRVR:CO2PR05MB2501; X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2501; 4:lY9cT3cdbxm0VD93GEuHBw2liZvFZfsAzbzQ5wLAYlSmfuExo1fhdAaxTZajlSS/zor9zGYP8gFDG5Hr4MoRjMH+3iyPrQYaAyTD5mYnCpb6bQOSYmF0yRDcSgs6zg4AU4s6X1niFYG/WPTYXrBKDL03AOxrGYtP+H0jmonsO1Eh6M1wFnVkUVJny04QUhdYgidmVqFzhkkS+/aTSFSYMGgRautrHZWvXcWd1hDQearmiRSMmjnuftfC5ezHtQwSHXWzeW9+XnQ1MAUaXFhk2OXe547Haw2yYcMNaEpzAYSIOR0N3hOHFV+7FWBz1aTyzfWWsbzRZf/vkPnHDA/7lmSLb6uon+7dz2meK7YvGxKqdqakgGfpBjpXX5MvtJr1cqXLuRRicEfN75tBt35CN3dFSbroXEAmbTR5uPO7GjsaCRQqbK/S4Ig1Cny9PKOHBDV88MPxoMMrJpC2FjvDMsoUUPM52QJYRj3IQ8XmxpkExK1WHgBdgUzoCIQ8yyNJ0WzoPvBoIq/gf3OhIkt0walME7HB6/1qdeOXQIgXxvMYkDgFSvNWxSL95t37u3KTY8noAy060dYCR5oSn3iVCxkeiVwXEmoQO2dH9e7L8xlfTd9anBUFmIis+WovliCB X-Forefront-PRVS: 02524402D6 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(979002)(6049001)(39860400002)(39840400002)(39850400002)(39410400002)(39450400003)(24454002)(377454003)(230783001)(236005)(6666003)(83716003)(2906002)(2950100002)(229853002)(84326002)(8676002)(76176999)(82746002)(7736002)(53936002)(42186005)(7906003)(90366009)(606005)(106356001)(5660300001)(6486002)(77096006)(86362001)(6916009)(36756003)(25786008)(50986999)(57306001)(6116002)(3846002)(4326008)(6306002)(54906002)(81166006)(33656002)(38730400002)(110136004)(260700001)(189998001)(50226002)(69556001)(512954002)(66066001)(6246003)(104396002)(42262002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB2501; H:[172.29.37.164]; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CO2PR05MB2501; 23:+lnbdDpk4F4jNrkKVF54uYCumrAtc4H303dWnzXNL?= =?us-ascii?Q?4wQNyG1XqT+uE+7p8v09y0GE/VmozDLg7sXXHJ1Dg1P419P5MRG7CGD1y7Vx?= =?us-ascii?Q?tQm+YVpxc4dffGJ3NHHVKuP2t5UmVIi02Hp+Ghz5pcUgUIEDPQKOzworeZ78?= =?us-ascii?Q?QaLEQSesIok5I7yysaoXNiSSeGJrFWtK9SgbFHZNeoEzdZEQipB+H+tHkh1K?= =?us-ascii?Q?I1Hsqsnp/XyIWhXyT4IgDqUmOxmMaF7Q36QnRlMHDvYeobH4gpB8wQx6+MYY?= =?us-ascii?Q?67AaS2sCSgiP9Xp9qV8yfhVTo67lpzHR0ML3y7IIrT3ul/vDaF0vRSflbruX?= =?us-ascii?Q?PKT9dheanI8iDh9cAagj3s4BJOdXHLwetUbLiIN127Q4cfAM9QcHeC8GSVN5?= =?us-ascii?Q?anWY6z22QHGS0AyBgnkE0sR575aEVi7H4DPA2xjAPSg6nTWURlj0uSLe94CW?= =?us-ascii?Q?MYob3wyarp4lLvcvK2uNHuNUEz0uzlUF8vdhd+Ail3XpD21Q+E6sbiLszQHd?= =?us-ascii?Q?gCHEt5ZK+YS9bKUTI6VPDYLajoMaOTlNYkTE0gdiAWBfgHezWy/pwq6JPFbd?= =?us-ascii?Q?Zi0mW+xj5DfcVdGLTndMvY1vggY5iHrhrtYm5xb6xTATatryoplSqIldwhpA?= =?us-ascii?Q?Ka/eJxB+fyGu7hCyfCW8mDNp/EGAs6J3C8WkrA/tJSmW1CtMwTSgDFNeGrmK?= =?us-ascii?Q?uZwZxT93kDWjZvvDGJHP3OG9OlDWNpzFqXnvlrChgvA7lpiF/Z3o0UdBkxaY?= =?us-ascii?Q?JHgOQEbzhurbVfUOJgWpNACfwb9fCTXAgvWmQI1iu2i4Vg9Dvd1smAkjIIHT?= =?us-ascii?Q?4/fundlK/FPR9u8HRiB+yd47ZfwrCBxGtlUh2TOBK/exgIKdxwN4cW9ebpec?= =?us-ascii?Q?7pLj1V8A1ExD8gMESEP6n9hDcfBzh59bQa3Su/7Bx7kqs8QwoeGoP7Asaghg?= =?us-ascii?Q?PP5Yelev/79eG+NYdqr68gMcRrldm0Q5Docbi8Luwbv/+EKLgO8wLMNGNtCX?= =?us-ascii?Q?niosm5XMH/rfqciQoc5pQqrHtupTvLiooGSJFYy7BF9znDJ8HcrzcxPrBCD6?= =?us-ascii?Q?CDfRcmCphRf+/67jfFAswD28eAQgaZWcF3v1IC/BA32wy+GJAXk5x0nBH6Ny?= =?us-ascii?Q?If95vMIG/xBPYuhos9ymT95eNcZbRHgL6nUiSd8pE5j53BuFliMoSh09e0SZ?= =?us-ascii?Q?xFMe9EMjJ2wCwNu0YLSuEN2uXRnyJrznx9zwQwYcaHQcvaGjimVXWJtYDaw1?= =?us-ascii?Q?Hux30kxPTQ0CQ6V2PIVQ3CidAQ/sYMtaLt1jfZKvGsyR2gFj3Fu8QfaIprvT?= =?us-ascii?Q?liXRbfD97GqhFIrZDUqj1mufeM4nFKploNAsPVeTFgSiiImbYLmZZ57rQQIB?= =?us-ascii?Q?BwIhEpX3gJ0a5NORVZGBSUtotxSnSQjT4m/2Tj6bV8Gaqpo?= X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2501; 6:Ot9QEJhCa4TYMOQuwWHux3fGOXYow/uzsjrwFFBD78/jqmHD6qfNqLWrSMT4ixhXD0yOpXIoONztn3wR4J/vmfHplWjyy+t0HrMTrG12d+0JMIlGFBUsM+UfFIH/Ltsy1ZjvrahoA/2EyWtkmsLW0v4310AAS/ho6jyFx87x/mCbUijYsoYY4TMS+NocXTKTIegYDaSqLedGa0QHYQiFNWAOBjDtJQvTKwoe60mXp3lv8ilHcOsErIt47A/BADS2B5SXD4rpo28jaPLPT3NS6HeqrAm9JgGtubyZ37NpC8LnkCWIUUKl2LK7aGqB/qMN+2YfTFjw17Qn4e0QXSFLJhEeapXbU4WiHtIszQG/nrgKQ3Pkfg9OzClgSWFoaUWYwxVo70qNiT4zyZD4y8QKW6yeqyekwwiHq86mWRGtXk4=; 5:EIGEy8Lg1VcbzTUQeQsVCa185DReQhL4N5rRQBRlpz/FVbPB5mlesPIG9nEe1zj8cwslTsGykvXoLOqkWelMPH5cIiDXTLQO42G38ki+l/cvQ25Et72mTwspiShbc3EPaB4JernFsMGHP60RGrrfHA==; 24:bNv8g41ZZ78h+oz5cbDrz1cUSKXrQuyXMgugzXCpW3aPVhyJUIQEQuqL5oVbhQMkIcymvbrSUTJxPyOeNcMiW1OSYTOPqsFWUZ0cmDBvRFU= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2501; 7:1HA43Gaw8Z4Uvf78cVFxHB4KpkfXu70cj2PXnzBFzEr9XCiLnDXhPq6YzP1BY/5OLkOgBHimvaRwwQhz9gA6mRPpzRWdLWxnytRHivM/Nc1XlM6C6G4U5vQ+IW0L1ki5ucfPr/LyNffaLWUBf8B9XQHEXy0TRAtBKkSA2CrbROkAe4tHzGAdMNaluvdZT+ziV0Kat//5Q4VHHhZwK0Bb42eI87ptMSFPYVMQtskRme4e5WbkV/3lGIDYYAoxWxcMOC9lFyspQeq4krHPnYAIlk8kdKbZfBncgNDw5u+8qbJfRza1Via/IDkT17IHQsfOdqv1KwhomYk/rt7pXS30xQ== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Mar 2017 19:45:36.5342 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB2501 Archived-At: Subject: Re: [Idr] Early allocation for draft-ietf-idr-bgp-gr-notification X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 19:45:41 -0000 --Apple-Mail=_C7823EB7-EC0E-458C-A86A-07F4415CBC65 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" On Mar 18, 2017, at 6:53 AM, Job Snijders wrote: > Given the 50+ years of combined IETF experience the authors of this = draft possess, I'm somewhat surprised to see a suggested value in the = IANA considerations instead of "TBD". See the last major bullet point = here: = https://trac.ietf.org/trac/idr/wiki/Checklist%20for%20writing%20a%20BGP-re= lated%20draft = Considering my name's in the list at the top of the draft, and that I = wrote the bullet point in question, that's on me. This is what you = should not do. If someone brings a dunce cap for me to wear during the chair's portion = of the meeting, I will. --John --Apple-Mail=_C7823EB7-EC0E-458C-A86A-07F4415CBC65 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii" On Mar 18, 2017, at 6:53 AM, Job Snijders <job@ntt.net> = wrote:
Given the 50+ years = of combined IETF experience the authors of this draft possess, I'm = somewhat surprised to see a suggested value in the IANA considerations = instead of "TBD". See the last major bullet point here: https://trac.ietf.org/trac/idr/wiki/Checklist%20for%20wr= iting%20a%20BGP-related%20draft

Considering my name's in the list at the top of = the draft, and that I wrote the bullet point in question, that's on me. = This is what you should not do.

If = someone brings a dunce cap for me to wear during the chair's portion of = the meeting, I will.

--John

= --Apple-Mail=_C7823EB7-EC0E-458C-A86A-07F4415CBC65-- From nobody Mon Mar 20 12:58:12 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0A3A131695 for ; Mon, 20 Mar 2017 12:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ISyU0Mp5GHvo for ; Mon, 20 Mar 2017 12:58:06 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 64719131653 for ; Mon, 20 Mar 2017 12:57:55 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id A55261E33F; Mon, 20 Mar 2017 16:04:15 -0400 (EDT) Date: Mon, 20 Mar 2017 16:04:15 -0400 From: Jeffrey Haas To: Gert Doering Cc: Robert Raszuk , idr wg Message-ID: <20170320200415.GB28021@pfrc.org> References: <20170315000326.GO12864@pfrc.org> <58C95A05.3030107@foobar.org> <20170315195050.GT12864@pfrc.org> <20170315212656.GD2367@Space.Net> <20170316073753.GE2367@Space.Net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170316073753.GE2367@Space.Net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 19:58:09 -0000 On Thu, Mar 16, 2017 at 08:37:53AM +0100, Gert Doering wrote: > Optimizing the "route server shall distribute multiple paths" is only > half of the solution. More interesting for me is "where do I need to > point my vendors to, to get them to implement proper black-hole > detection in the forwarding path, so the BGP NH can be invalidated?" As noted earlier, the BFD component of the draft is separable and may be worth a split at some later point if necessary. It's also the easy part of the draft. > (I'm not aware of any gear that will do this right now, as in "if > IPv4 ARP or IPv6 ND fails, mark NH as invalid and look for other paths > in BGP" - but I'm always willing to learn) Having been at the wrong end of quirks of ND/ARP issues, I don't recommend this as a sufficiently useful mechanism. I also suspect the IXPs wouldn't want their customers participating in a layer 2 OAM mechanism. This leaves layer 3, which moves us largely to BFD. Or alternatively ping. Which is gross, but would totally work. -- Jeff From nobody Mon Mar 20 13:15:12 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 938681276AF for ; Mon, 20 Mar 2017 13:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.695 X-Spam-Level: X-Spam-Status: No, score=-4.695 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IQ6zIFN8DeKp for ; Mon, 20 Mar 2017 13:15:06 -0700 (PDT) Received: from mail-pf0-f177.google.com (mail-pf0-f177.google.com [209.85.192.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 E9760129506 for ; Mon, 20 Mar 2017 13:15:03 -0700 (PDT) Received: by mail-pf0-f177.google.com with SMTP id p189so47254997pfp.1 for ; Mon, 20 Mar 2017 13:15:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=ybwuQ7JkUAQV6yttoB45QrHB5p+/gwL1BsJEyL9EISw=; b=TXmVJtli7PuHhCSUyFM2xqjLkV3rhkXysi0b0XvH6Az0Y6x/R6mw11qwMlr+rOITp/ JXfmYjfchWFvUKLStx0e470/xE6iepuypaNxtKF0XAhSig875upmqyXYHz34hEaIB0Qz R5SmkiO9FldgucVBTunXCy0DP3+JMEWERDRL4FUlsH9Q9ue5ESXC2sivw5fJ2t/Vgb8O GuOsBoH9oMntL7Qm6vJkep58TtSXGjqSozyMuerPA8mTDKFGjnGgXJgkHhozbU0KTU7K 9ziQ6k0fz5K8NEFOoTihCsiEHdmOMbtutK5pFmy7Y8prwUFBmybRuTiLB1pDY+yeqNVM tGyw== X-Gm-Message-State: AFeK/H3QuARZ04iTVjpccfTZ0QN3fmjVSA0PYQYVo9/YAQ3QQOa7mh6ojx2m03hHnj8Wkg== X-Received: by 10.98.160.193 with SMTP id p62mr35365962pfl.67.1490040903267; Mon, 20 Mar 2017 13:15:03 -0700 (PDT) Received: from localhost ([192.147.168.22]) by smtp.gmail.com with ESMTPSA id l1sm15761027pfk.8.2017.03.20.13.15.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Mar 2017 13:15:02 -0700 (PDT) Date: Mon, 20 Mar 2017 21:14:55 +0100 From: Job Snijders To: Jeffrey Haas Cc: "idr-chairs@ietf.org" , "idr@ietf.org" Message-ID: <20170320201455.micjs4yvzvyoycw6@Vurt.local> References: <4eedda5c2db74539bd0f949e38cb8b26@XCH-ALN-014.cisco.com> <20170320194414.GD26130@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170320194414.GD26130@pfrc.org> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: NeoMutt/20170306 (1.8.0) Archived-At: Subject: Re: [Idr] Early allocation for draft-ietf-idr-bgp-gr-notification X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 20:15:09 -0000 Hi Jeff, On Mon, Mar 20, 2017 at 03:44:14PM -0400, Jeffrey Haas wrote: > > Furthermore, shouldn't the "Hard Reset" be called "Really Really > > Really Reset"? I am skeptical whether the principles of graceful > > restart should be applied to the notification mechanism. In > > https://tools.ietf.org/html/draft-iops-grow-bgp-session-culling-00 we are > > describing a procedure that strongly relies on the currently > > understood semantics of expiration of BGP Hold Timers and the > > Administrative Shutdown: "STOP sending traffic". > > I haven't yet read this draft, so take my further comments with that under > consideration. ack. Please read the draft. We may have a fundamental problem on our hands here. > > I find it hard to reconcile how we can have both "My control-plane > > temporarily going away, but keep sending traffic" and "data-plane is > > broken, bgp subsequently dies, don't send traffic". The exact failure > > scenario which triggers the expiration of the BGP Hold Timers cannot be > > known at OPEN when the capabilities are exchanged. The GR NOTIFICATION > > seems to distort the congruency between data-plane and control-plane. 1/ To emphasize the congruency issue here: BGP Hold Timer expiration often (from the Operator's perspective) an unplanned event. BGP Hold Timers usually expire because there is an issue with the lower layer network. If there is an issue with the lower layer network, we should not continue to forward traffic over that path. If I understand draft-ietf-idr-bgp-gr-notification correctly, that is what would happen if both sides through capabilities negotation understand they both support draft-ietf-idr-bgp-gr-notification. "make before break" or "ignore this break" are doable when events are planned, but this draft touches upon scenarios which happen without planning from the operator's side, where we should be careful with our assumptions about why a Hold Timer expired. > > Perhaps there should be an implementation guideline which encourages > > vendors to by default, disable this mechanism on non-RFC3021/RFC6164 > > links? > > > > Has draft-idr-bgp-gr-notification been vetted in the wild? What were > > the results and under which circumstances is the mechanism useful? > > Am I missing something? > > The non-obvious connection is it's a requirement of > draft-uttaro-idr-bgp-persistence (long-lived graceful restart). > There's code shipping for this feature. I *believe* that it's another > vendor as well, but can't confirm from memory. > > There has been some discussion that LLGR needs to be resurrected from > zombie draft state. 2/ So draft-uttaro-idr-bgp-persistence is zombie from IETF perspective, but there is shipping code, so in order to resurrect draft-uttaro-idr-bgp-persistence properly (and finish the project?), draft-ietf-idr-bgp-gr-notification needs to move forward, is that the chain of events? 3/ If I may ask, why isn't BGP Cease NOTIFICATION message subcode 4 "Administrative Reset" used to perform the 'hard reset' function, and isn't subcode 9 (the suggested value) requested as a new feature called 'soft reset'? This way we don't break people's preconceptions about what it means to type in "clear neighbor 1.2.3.4".. By declaring "subcode 9" to be a hard clear, it appears to me the meaning of 'Administrative Reset (subcode 4)' is redefined, and redefining existing constructs might not be an easy task. Kind regards, Job From nobody Mon Mar 20 13:35:09 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 639C3126C0F; Mon, 20 Mar 2017 13:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TMHzHLnp7yoZ; Mon, 20 Mar 2017 13:35:05 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 85FD0127342; Mon, 20 Mar 2017 13:35:05 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id D3A481E33F; Mon, 20 Mar 2017 16:41:25 -0400 (EDT) Date: Mon, 20 Mar 2017 16:41:25 -0400 From: Jeffrey Haas To: Job Snijders Cc: "idr-chairs@ietf.org" , "idr@ietf.org" Message-ID: <20170320204125.GH28021@pfrc.org> References: <4eedda5c2db74539bd0f949e38cb8b26@XCH-ALN-014.cisco.com> <20170320194414.GD26130@pfrc.org> <20170320201455.micjs4yvzvyoycw6@Vurt.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170320201455.micjs4yvzvyoycw6@Vurt.local> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Idr] Early allocation for draft-ietf-idr-bgp-gr-notification X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 20:35:07 -0000 On Mon, Mar 20, 2017 at 09:14:55PM +0100, Job Snijders wrote: [session culling] > > I haven't yet read this draft, so take my further comments with that under > > consideration. > > ack. Please read the draft. We may have a fundamental problem on our > hands here. I read it. It's a weird hack, but it works. :-) > 1/ To emphasize the congruency issue here: BGP Hold Timer expiration > often (from the Operator's perspective) an unplanned event. BGP Hold > Timers usually expire because there is an issue with the lower layer > network. If there is an issue with the lower layer network, we should > not continue to forward traffic over that path. If I understand > draft-ietf-idr-bgp-gr-notification correctly, that is what would happen > if both sides through capabilities negotation understand they both > support draft-ietf-idr-bgp-gr-notification. I suspect the point you've overlooked is the N-bit is intended to indicate support for this on a per AFI-SAFI basis. This is something you have to explicitly ask for. It also isn't something that makes sense in many scenarios, especially Internet. > 2/ So draft-uttaro-idr-bgp-persistence is zombie from IETF perspective, > but there is shipping code, so in order to resurrect > draft-uttaro-idr-bgp-persistence properly (and finish the project?), > draft-ietf-idr-bgp-gr-notification needs to move forward, is that the > chain of events? It's a dependency, yes. > 3/ If I may ask, why isn't BGP Cease NOTIFICATION message subcode 4 > "Administrative Reset" used to perform the 'hard reset' function, and > isn't subcode 9 (the suggested value) requested as a new feature called > 'soft reset'? This way we don't break people's preconceptions about what > it means to type in "clear neighbor 1.2.3.4".. It will depend on whether you want to trigger this behavior or not. The semantics change from simply "I typed clear bgp" to "this session must not go through this mechanism if you've configured it". > By declaring "subcode 9" to be a hard clear, it appears to me the > meaning of 'Administrative Reset (subcode 4)' is redefined, and > redefining existing constructs might not be an easy task. Naming things is one of the two traditionally hard problems of computer science. -- Jeff From nobody Mon Mar 20 14:50:02 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10C41127B31; Mon, 20 Mar 2017 14:50:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.698 X-Spam-Level: X-Spam-Status: No, score=-4.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HePc3JLQgFO9; Mon, 20 Mar 2017 14:49:58 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0110.outbound.protection.outlook.com [104.47.36.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0DB7126DFB; Mon, 20 Mar 2017 14:49:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=AoqACeSTPOKOm7+nPD23WQvi5vo3PgV+55UL8lf3fEQ=; b=dhwtX0xWBg51e73CA6FFm5cYu3GNlOaHjYquRqmzfGKLju2wdpjDnfLiQdZUfoRCVpVOuadJsQHxCaKlM3eW6DeK+R9ZH7916W1hJBsynBtdKvayrB0Z1ae5GSsC5A2+p33KMCpUUQwrbuhlk/p92seQE0XVa9sBp9mD2cDvimg= Authentication-Results: pfrc.org; dkim=none (message not signed) header.d=none;pfrc.org; dmarc=none action=none header.from=juniper.net; Received: from [172.29.37.164] (66.129.241.12) by CO2PR05MB2504.namprd05.prod.outlook.com (10.166.95.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.4; Mon, 20 Mar 2017 21:49:56 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "John G. Scudder" In-Reply-To: <20170320204125.GH28021@pfrc.org> Date: Mon, 20 Mar 2017 17:49:50 -0400 CC: "idr-chairs@ietf.org" , "idr@ietf.org" Content-Transfer-Encoding: quoted-printable Message-ID: References: <4eedda5c2db74539bd0f949e38cb8b26@XCH-ALN-014.cisco.com> <20170320194414.GD26130@pfrc.org> <20170320201455.micjs4yvzvyoycw6@Vurt.local> <20170320204125.GH28021@pfrc.org> To: Jeffrey Haas , Job Snijders X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.12] X-ClientProxiedBy: BN6PR20CA0004.namprd20.prod.outlook.com (10.173.158.142) To CO2PR05MB2504.namprd05.prod.outlook.com (10.166.95.150) X-MS-Office365-Filtering-Correlation-Id: 26052b15-c61d-4a83-6642-08d46fdb0cff X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CO2PR05MB2504; X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2504; 3:ekLJdwFghOgIOoV635Nf9cZV9aBEuqf9S04jQus8DOr3gKz9HVVE58y70TPZ7oHxTx3JepxHaPUSG/dl4nawwmOO15RhqVfkqH9tiYyGvN36C0TZamCloma1gv3IQ7apRrgv9wdvYYlKOjeMnhvrjXJGyyRfRj9rzfDCiROlwfogETy/hF8o+ay7k6Nl06GzJQxZVfdfRN16xq5Nx2uphkSU+P6FZLf1Bfz4LLb1FGcEd4XNqQXdDvK4Y1BxDbp88PEJGjLhPcX8bjn/HII0EPXh022+KG6cbvEHOp8rC5w=; 25:3djds4n+fo6dnHPG6l9y1uv1sIMMI2YIAx9k0gRiRV2303fdd7HxNnMVB2imCiupfFXTEW28147QLtNmTFvHjIUNganoiSbMuooXS0zGjEJuqA9TevdbwfZaOCs9HGQCT6SPR40b24KBg8fT5JN1tbm8iqdLWiLsbpvDFu+DxflHCxal/HNSm5YRf37HC8ymlaKgwTWPMk1AvBswM+e0u65+9y1mgH0MTgUMwpXekerWlNAV6f8DUrVhVZo3EHccKs6IYbnm9s2x/UMOU7b60r5tgnUEXcdRIkrfhK8DYFiSIoY6D1qbjXkHz0InP66FhWKBLxs3BHnp7pqU7orHY+NsFvEKKPHA/VJoQJtHH+tjrvulk8EFTJbM4LInKuDlkI/387iPMTNwVJm/3vey7Kd2VkGId3en2w6SDSY8XuecmpsYyVawpD7B6XnHcnhIBknrRC2P7reJUgZKmTTvHQ== X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2504; 31:9LJ2AFN06j9Mzx29A9bMmKXbYJCeQ6XqtdN315VxPCNf/bjm9Knk4+Kkv7iWUSECAIot7cK63Lx00CFuKfFvQb6S3lJe/sys+Sw8AFeaTOylEgl57mvxhtZmLVAFUgOfmG6A8iBiC1ZsB6FnhLTGKcWOkFECXavimUlqGtwc0U4xv3qyiakXQbCK7dZwJtuTVH1FyuLnmfbo9KwMxeytUjM8/1do2fT1k9ZobqDH8SIpRCLqXrCtq3f7ZZABWohy36Pi+lvPR+XK1dyBdVOIPA==; 20:O3JigWCJT7iA06eRL28/K+Lk0YgOqJoQSFM3U3RVxkKc6oN4AxldfFwqaBu52RwGM0tmYhXpN/JO4YcsgXxx5xsZhBLdLfdYX9+rJxcCfHwaXOkhTUaFrX3yGFWYOe05GEM7FWtbj9Tu1JrUrydMWF7wcgOH+XarrQnBrrLTjKBXsyi34gdF9mistQSwBuD1PfPedEfpMkkqgJkk7yAQ1luQv40wNyXk2kJKI1wxPE9k+VB4kVX7rUweDbo7NB+46taNwdEZ1E2UJ/sX4I4Lxf014z1LXhdLQGrst0SsgKgVjKFOAiig6c8sxQWlivDSiLlFpK4xbVlZWBNbE7a9rdxaVoaj4iRed2lvYH5nXVPyclKicxDwHRu3Mr1Oz9lC6FhmFhb52Zjv7GuA0JSIhXhl+M4/F2hFNch+0zUV0FLvM9lM8Q4vX3N6Ke5hr/JiNyc53cnG11SG7rQMoVRxXqkMj411JoYTo8W2XmPAexZeGGrpbDKeF8eDY6IDTQyYXDjwueWqZ5skDrixrb6MuQZhLAGcVp+k2TAKtuvbCEiqNzmeN77RAX+BogfmQ8EBhSjoud5Btqq0VVQi6513y5WADzMoWpPDMptjzp6LC0U= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(72170088055959); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123555025)(20161123558025)(20161123562025)(20161123560025)(20161123564025)(6072148); SRVR:CO2PR05MB2504; BCL:0; PCL:0; RULEID:; SRVR:CO2PR05MB2504; X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2504; 4:GgeKxcQkpnA+SXqqxh0YIm5ZkB9D5vozAKCBbPw+sNSdiRqe3POgTH2hT8uq2Lk2Qjgf/7b4jK3w3kYivcQWYAgOFw2hyFEYsgEO83Y+YDTEmzbgvMtKUkx9cR8Z9LvGgfa7uARSo/lUtzygA0t9UZYc/jjlsyR2NTTcC1k3FWbNmIUKl83lWyFTtzIhZ2qMlS6Mpss0WZ8kD/vRiC5sOH/BS8+3pJYgJ75IaRMt8cby5/3QnKmDbsprgwxoTBkn6JZ5isPRTpXbki0+betbVQbV3Zb7wHrTeOVupqwsRMg5yYHtMBpleqaJtY8xmFTIk0ASCbZEl5wGsN5fR1SMEaP/5V2wAgxP6LFZNQDfgtuW3JrMXGBgaY/yBrOSbYQUW9Vsl/+PAhUWoSevY93Tm71CyjVOpyL++iVmjDMfzmWa97UcoCV3Ze0Yqtyzh5jROYkFIATFKAC6Y8dONCvri6Rfl26pwpxbOmzq7rkNHlgXe0denJzFWRCdm4h4ub5YVYOQX7eYHySwtrOK+Itr7/KuH1UdOC/OXQqCz++8wolzFlQAsKYm8WPJE8gKWHqg8QnQIKhJS29AO2pwaLhade8LqZhshPmVnhlH6T/QCHWVf3TxsOhDC1kpBnRfySbk3U5oUN86eYfEYAdMWf5RKe83h39zaEdYDSNzN6n4+YM= X-Forefront-PRVS: 02524402D6 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(39850400002)(39450400003)(39410400002)(39860400002)(39840400002)(377454003)(24454002)(33656002)(66066001)(82746002)(15650500001)(6116002)(3846002)(23726003)(305945005)(7736002)(57306001)(25786008)(47776003)(50466002)(53936002)(54906002)(86362001)(83716003)(6486002)(77096006)(8746002)(50226002)(38730400002)(2906002)(6246003)(8676002)(6666003)(81166006)(2950100002)(42186005)(189998001)(46406003)(76176999)(50986999)(4326008)(229853002)(230783001)(93886004)(5660300001)(36756003)(97756001)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB2504; H:[172.29.37.164]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CO2PR05MB2504; 23:Sj3b+nPLc624fK1fKJyPZbO4WyTADiSit7DR+ceSi?= =?us-ascii?Q?r5xuTb16zd5zLR3ihhiOwQdIOcZEPrL+6hlkuadF8yHcwwyaxXvOP3s5bAVS?= =?us-ascii?Q?Bc2IHP9pW8gby+xEpicBWmFlUyERChYPFOsARuqT6V/7LKXWqa0ALiH2aG9m?= =?us-ascii?Q?fVCt+g4vx+HsExggcoTCFEmXSNsD5k9MsHZG+xCOnnofQkFHkQ0a+l2uHJlv?= =?us-ascii?Q?0Ex9/6FcWjM48kTUbszXAWztNYH1KdKipBHJeoSyALDA3Zr5PxbAxg7O5OFZ?= =?us-ascii?Q?cB3qFAtMD7IqvoNXE+/2c6yyoYa1ThvGZ/22+tn/VeB2dftw0lVxA3inzUnM?= =?us-ascii?Q?H1XIhce16ezn2IU78JKBWEq1cPXidCrN69Dzn6N+zJp4TGNwJoqfikPfSwy6?= =?us-ascii?Q?J3o6We8Hh4R6x8vGkGM9U+A7PVI/9kc1s31ejqSx3LvmJ7UjLef1pCvvy2Yu?= =?us-ascii?Q?I0UOc9yYvxlGL2HzWiRiEoLnxjIe/h37snDG/zWRSBa5iqkPEJFX/01QWX6G?= =?us-ascii?Q?kt8c/j4uZfkTJcwBktrs2lEwO4ZqFI01YMXU51aI3+gDDZWub8PrUN89E5/G?= =?us-ascii?Q?wey+w8tzzK4Q6dQnr9PtLhuQ0E8UTt+xCNhdnWGLleszK4UeOcZlu27ECuWJ?= =?us-ascii?Q?OkhAhnAov0vnq/RRyVwMj3cZxENQs9H11BxnKFxRBNbKamr5qPXRTkV/FqDb?= =?us-ascii?Q?NpGi7b/LqCUymOf0LjhOtVwJDO5eMzQLguJNdisRWHz+ZhqiOvgeZIcTl3BT?= =?us-ascii?Q?Mx46rYSp3naE5qZJ4C+kUQR9/rdIVFc1mPN/K20VeqwhOv2jbpNhND/xBUXf?= =?us-ascii?Q?+BACd1eg+RTVLnAnjJpDd1YkIW0yfd4LLMrlBX35+372l+ZX0QCDJhv9mYzr?= =?us-ascii?Q?oUeJWHtLQrl0qHMgGV/gJvcYIZzisQvWCmeWe4BS7pSXUKSAsFkH237qkJZY?= =?us-ascii?Q?zHPPEWGb+6+o00TjA6IzPCnbAxOQa/oCtexgSl2zc7rIf6YD8kPZZHkOOzJr?= =?us-ascii?Q?uQ6E3SLcmqVfYankVw9kRukCGK8I3BNgXi+NvBUqi90k7KGNdgxInq8qXPMA?= =?us-ascii?Q?5bsQiRM1Q/UE8BrzufacOF4gPB+jqTPI0YwOPknu3CkHzfaucQoGHkvgK9gG?= =?us-ascii?Q?0EVizRh2Z7zmVlk1SE6ojsccroGoVLhwotXVolC4oZQ6YfwiP09ALw7Zfevq?= =?us-ascii?Q?c15FSvwo4atk3qjAved9hsfZqkdz5KE0HqCEBo8W2rp0nBYYR5JdfzF/DLPf?= =?us-ascii?Q?Oh2cRVhoiRw1yyfyfvF6E4CiB2LbIRKkZoilQta?= X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2504; 6:iUna/fRoZa0QhmWIVKZAaxJ6WJq2u0O1pMiRsNkYrfwGVjhlJYgbqpKOhw4HnIl1KKbKkR6ar+A2EqxZfKrLgMULoZ/G5S3gQTWK2QkjptaLMtft/TEI9Iif7nXfWXIcDmUkyF83AKGvhIkPbB+KT5jt6OzNt/UMbTIfaEnzsfIbxSqLfmzqmW5O2K3b3H+RWjzMm1b+sgWdC68UKRBKsAVNTNeSJapZpixvcdI/CmKpaL/QXzwpYp0OFDzzcChRaC9catfIgpYQ3qMEiBgWqcC1ORXPVMgGu7iVQnX+F0xfr+NRJ3x+gz/eNb413MRyN/WFD+5xWcB+yXCyQHbxAAEJxr8R/MAOPLID2c1TQZeLUoPvsxZjHCeM6QcO7A+Tmbc/d4PBGjYxaVcuJEyThFUUSp8OBAi4HiLEVQ/HE94=; 5:HFAH3azezVK4ccnZAhPorHM4bBMUFM2Yy9+ebOTQs5VzMfKDukHQh0i8+WAW2cuYeUBN+rchTy23CHY3VXAOqHDmTAraCnJlWp66sR4ZaprTMuC2xeoHUMEljbXyzUTnj8Rah5Y6Sq6geHYvVZ5TKw==; 24:W3kvZmLhSpREI4puhESw+GMPJxSwr/tCz1YfFiGEXxP8YK6wGxNDpfE6wdgfrASmnLTTXpYm8oUmKu4FBubs7IwWGPSYqbUPp/XwdiF3xfM= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2504; 7:dwc0tefRQdcOk9liAVcMmecIG9BbeJOQfVDKjkmjcRwkIWFwqqvoD4XSuCiR3Co6q2j/ICNmm2XcQ6JP/j78DWP3AcP7f6EYoEOTgpbvrGJJItRsuMUqM9+HR7M01bT1ktkywcoLE6j0Km/wgz6jWRcy1Vxwc4+BVZfWzstOc/HwyfecYCu38xTSy+68oHR7KKkQeEjJ8qkJ00lsNJ4Vgxa3PFhz+gqRrZ+ShWcy86IhyS2Hf/B9596Ktm8Z+I2ZptBN/q1mdCiz7HNSfGDPB/fMWACIH++7v34zU71+zLbp7CAHN89NbvoMIAqygNk2PSl2YtQEE5tswVXf44mxMQ== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Mar 2017 21:49:56.4611 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB2504 Archived-At: Subject: Re: [Idr] Early allocation for draft-ietf-idr-bgp-gr-notification X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 21:50:01 -0000 On Mar 20, 2017, at 4:41 PM, Jeffrey Haas wrote: > On Mon, Mar 20, 2017 at 09:14:55PM +0100, Job Snijders wrote: > [session culling] >>> I haven't yet read this draft, so take my further comments with that = under >>> consideration. >>=20 >> ack. Please read the draft. We may have a fundamental problem on our >> hands here. >=20 > I read it. It's a weird hack, but it works. :-) With respect to what "culling" calls "Voluntary BGP Session Teardown", = there's no problem. A pair of implementations that implement = gr-notification would already be expected to do the right thing when the = session was administratively shut down, by sending a hard reset. With respect to what "culling" calls "Involuntary BGP Session Teardown", = there is potentially a problem, but I think it's not insurmountable. The = problem, to the extent it exists, is that "culling" suggests the IX = switch fabric should be configured to block BGP traffic, causing the = hold time to expire. gr-notification interferes by putting the session = into GR mode: When a BGP speaker resets its session due to a HOLDTIME expiry, it should generate the relevant BGP NOTIFICATION message as mentioned in [RFC4271], but subsequently it MUST follow the rules for the Receiving Speaker mentioned in Section 4.1. At first this might seem alarming, but my observation is that the weird = hack already relies on waiting several minutes for the hold time to = expire. So, it doesn't seem terrible to add a few more minutes to wait = for the stale route timeout as well. Although "culling" doesn't discuss = how to determine the maintenance can proceed, it would seem both prudent = and straightforward to do so by monitoring the traffic level between the = affected peers, since presumably the IX operator doesn't have a priori = knowledge of the hold time in use. Once routing has converged away from = the path, the traffic level will drop, and the maintenance can proceed, = regardless of what perversions are in use in the control plane.=20 --John P.S.: I take no position, in this note, as to whether the suggestion in = "culling" to filter BGP control traffic as an IX management practice is = a good one.= From nobody Tue Mar 21 01:26:31 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F43D129680 for ; Tue, 21 Mar 2017 01:26: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, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bi0AmjUl3ogv for ; Tue, 21 Mar 2017 01:26:27 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (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 CB2B1127333 for ; Tue, 21 Mar 2017 01:26:25 -0700 (PDT) X-Original-To: idr@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id AADA960771 for ; Tue, 21 Mar 2017 09:26:22 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 76F0B604A9; Tue, 21 Mar 2017 09:26:22 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id 688816B922; Tue, 21 Mar 2017 09:26:22 +0100 (CET) Date: Tue, 21 Mar 2017 09:26:22 +0100 From: Gert Doering To: Jeffrey Haas Cc: Gert Doering , Robert Raszuk , idr wg Message-ID: <20170321082622.GP2367@Space.Net> References: <58C95A05.3030107@foobar.org> <20170315195050.GT12864@pfrc.org> <20170315212656.GD2367@Space.Net> <20170316073753.GE2367@Space.Net> <20170320200415.GB28021@pfrc.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="L/UlCz6KLdX40+mu" Content-Disposition: inline In-Reply-To: <20170320200415.GB28021@pfrc.org> X-NCC-RegID: de.space User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 08:26:29 -0000 --L/UlCz6KLdX40+mu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Mon, Mar 20, 2017 at 04:04:15PM -0400, Jeffrey Haas wrote: > On Thu, Mar 16, 2017 at 08:37:53AM +0100, Gert Doering wrote: [..] > > (I'm not aware of any gear that will do this right now, as in "if > > IPv4 ARP or IPv6 ND fails, mark NH as invalid and look for other paths > > in BGP" - but I'm always willing to learn) >=20 > Having been at the wrong end of quirks of ND/ARP issues, I don't recommend > this as a sufficiently useful mechanism. =20 Well, it won't catch all possible faults - but generally having a feedback mechanism from the L2 address resolution layer about "no idea where to send this packet to!" would catch the easy ones, that is: total blackholing due to fabric issues and "peer botched their IPv6 ACLs and ND breaks". > I also suspect the IXPs wouldn't want their customers participating in a > layer 2 OAM mechanism. This leaves layer 3, which moves us largely to BF= D. >=20 > Or alternatively ping. Which is gross, but would totally work. Indeed :-) Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --L/UlCz6KLdX40+mu Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAljQ46sACgkQ31bAZeTO f8VvGw//UFbpCGmHsHhPNwWf9vSBSpz11KuPitw9w1pge6NY2+ZU0rKXIV/CylOF vWl3zR5SJcS2DJdE+jG/kG80aQ+MKfAG4XXze4jzVQVADndSTJ81OfyzY4iaJ92f rAZDN5hc8bDdrmzfTSYU4wZEPt1Uke7djV+LLeXAtOxfUpSzt4LtBUqBu8ig8rbY JeDlt9Jt8/gvuTcDsx/nOF9aALd7UQKwMK2LYubDRRtiyBRZtyYr/Wghx1jZ/6CI nhtkk48zF947eX3Hu4HSot4ipBMWtO2e+oJAUNfCKIftrDYINqflmmyFZHkzr9P6 xZ7WRD0eO2O686ja2r2lqVzwltiiziKgirysTZtAgZzC4yi2p7bHoMScRi0XBb0R uKXRVXT9L4vnF5s27yKrCecyWtLOGAvhj7mtPFzkea2aT+NDdtZUaGlVnljFi189 r9xOviCPW0oRwzws6YHzrqYlTEM6ddPGsgcDmfvaLxtWY4ZkT7iG5WVpAl0A6GzT geiNffgEAUJqny7YSSBG38jVjmafDA5M7vVITSCJT8AOR3zl/RXa0nN+i/icckk4 m39NYXwBuAz3UtRF4zWSal72O2GProN/WrM6OidxKM7aXN2PXnUw1tM2djGR9gPb iiWbdanls1UoXhLvZ12uB//Gymk3UV0oPeDMbg4aVp8caE6CbEQ= =0kR2 -----END PGP SIGNATURE----- --L/UlCz6KLdX40+mu-- From nobody Tue Mar 21 03:49:47 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 204C01293F3 for ; Tue, 21 Mar 2017 03:49:40 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eq18un7zn-ki for ; Tue, 21 Mar 2017 03:49:38 -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 B4E871296E5 for ; Tue, 21 Mar 2017 03:49:37 -0700 (PDT) X-Envelope-To: idr@ietf.org Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id v2LAnZTU013299 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Mar 2017 10:49:35 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local Message-ID: <58D1053E.1040407@foobar.org> Date: Tue, 21 Mar 2017 10:49:34 +0000 From: Nick Hilliard User-Agent: Postbox 5.0.11 (Macintosh/20170302) MIME-Version: 1.0 To: "John G. Scudder" CC: "idr@ietf.org" References: <4eedda5c2db74539bd0f949e38cb8b26@XCH-ALN-014.cisco.com> <20170320194414.GD26130@pfrc.org> <20170320201455.micjs4yvzvyoycw6@Vurt.local> <20170320204125.GH28021@pfrc.org> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Idr] Early allocation for draft-ietf-idr-bgp-gr-notification X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 10:49:40 -0000 John G. Scudder wrote: > Although "culling" doesn't discuss how to determine the maintenance > can proceed, it would seem both prudent and straightforward to do so > by monitoring the traffic level between the affected peers this is what is done in practice, yes. Low tech, but it works fine. > P.S.: I take no position, in this note, as to whether the suggestion > in "culling" to filter BGP control traffic as an IX management > practice is a good one. Purists will argue that it is a hacky layering violation; but from a production point of view, it's been found to be an effective way of eliminating the effects of what can otherwise be highly disruptive work. Nick From nobody Tue Mar 21 08:24:11 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 366CE129A4D for ; Tue, 21 Mar 2017 08:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mbtqBz-KhQQn for ; Tue, 21 Mar 2017 08:24:07 -0700 (PDT) Received: from mail-pg0-f46.google.com (mail-pg0-f46.google.com [74.125.83.46]) (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 5E2EE129A3F for ; Tue, 21 Mar 2017 08:24:07 -0700 (PDT) Received: by mail-pg0-f46.google.com with SMTP id t143so29534242pgb.2 for ; Tue, 21 Mar 2017 08:24:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=EuyBMqmup1InpGyVbEeXLUoyV0J4ELXQgCJpSg+CslY=; b=rQmh3ZwEdkT5J2dqkIfYVDa3g4geVMV9eEudjkuHjk7QInF+WGea3zGnvP5QCdDbGG ADWtIKWTZqT7S+KbH4ZiFwmsmSAy3LJwfv2M9kmooCsPzafxZThGIdh63JBbuAFmPDjT Ym1Stijyf+g5nwcV2rin4RquP+XB2pwoHUEgzmYojLGvMYJq+3iDc+Q/L61cA76ng0mi 3iKvjzwHCNXlE5VXpKloSXA/xPwyprk3vJn0W+Gb36ZC0FS5yS4LlIm2cL5mTsHfRMWj 0FUr++/fYD56GQoHByOA/qjCWNP0OWITQIgFGKdRTlA0RbaUdgWWsruqjyc14at+gRRf pozw== X-Gm-Message-State: AFeK/H0IhPCvCsb2TZa5lvl1dLxT/1cQUs+DBnFZ8CxEJYy2PVtTsu1FJHaGXi2w3/va2Q== X-Received: by 10.98.69.86 with SMTP id s83mr40999255pfa.232.1490109846670; Tue, 21 Mar 2017 08:24:06 -0700 (PDT) Received: from localhost ([192.147.168.22]) by smtp.gmail.com with ESMTPSA id s20sm40406090pfg.11.2017.03.21.08.24.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Mar 2017 08:24:04 -0700 (PDT) Date: Tue, 21 Mar 2017 16:24:01 +0100 From: Job Snijders To: Jeffrey Haas Cc: "idr-chairs@ietf.org" , "idr@ietf.org" Message-ID: <20170321152401.56twmu4dq7acy2ly@Vurt.local> References: <4eedda5c2db74539bd0f949e38cb8b26@XCH-ALN-014.cisco.com> <20170320194414.GD26130@pfrc.org> <20170320201455.micjs4yvzvyoycw6@Vurt.local> <20170320204125.GH28021@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170320204125.GH28021@pfrc.org> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: NeoMutt/20170306 (1.8.0) Archived-At: Subject: Re: [Idr] Early allocation for draft-ietf-idr-bgp-gr-notification X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 15:24:09 -0000 On Mon, Mar 20, 2017 at 04:41:25PM -0400, Jeffrey Haas wrote: > On Mon, Mar 20, 2017 at 09:14:55PM +0100, Job Snijders wrote: > [session culling] > > > I haven't yet read this draft, so take my further comments with > > > that under consideration. > > > > ack. Please read the draft. We may have a fundamental problem on our > > hands here. > > I read it. It's a weird hack, but it works. :-) > > > 1/ To emphasize the congruency issue here: BGP Hold Timer expiration > > often (from the Operator's perspective) an unplanned event. BGP Hold > > Timers usually expire because there is an issue with the lower layer > > network. If there is an issue with the lower layer network, we > > should not continue to forward traffic over that path. If I > > understand draft-ietf-idr-bgp-gr-notification correctly, that is > > what would happen if both sides through capabilities negotation > > understand they both support draft-ietf-idr-bgp-gr-notification. > > I suspect the point you've overlooked is the N-bit is intended to > indicate support for this on a per AFI-SAFI basis. This is something > you have to explicitly ask for. Yes, but since a number of days or even weeks, can pass between when you ask for it at OPEN, and when a NOTIFICATION event actually occurs, circumstances might have changed. > It also isn't something that makes sense in many scenarios, especially > Internet. I'm happy to read that we're finding common understanding on the applicability of GR Notification. Perhaps a note to that point would be useful? > > 3/ If I may ask, why isn't BGP Cease NOTIFICATION message subcode 4 > > "Administrative Reset" used to perform the 'hard reset' function, and > > isn't subcode 9 (the suggested value) requested as a new feature called > > 'soft reset'? This way we don't break people's preconceptions about what > > it means to type in "clear neighbor 1.2.3.4".. > > It will depend on whether you want to trigger this behavior or not. The > semantics change from simply "I typed clear bgp" to "this session must not > go through this mechanism if you've configured it". ack. > > By declaring "subcode 9" to be a hard clear, it appears to me the > > meaning of 'Administrative Reset (subcode 4)' is redefined, and > > redefining existing constructs might not be an easy task. > > Naming things is one of the two traditionally hard problems of computer > science. mmm, regardless, since there is code in the wild we may already have passed the naming station. Kind regards, Job From nobody Tue Mar 21 08:29:08 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0976129A90 for ; Tue, 21 Mar 2017 08:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.194 X-Spam-Level: X-Spam-Status: No, score=-4.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, RCVD_IN_SORBS_SPAM=0.5, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FYiWwRv58UIh for ; Tue, 21 Mar 2017 08:28:54 -0700 (PDT) Received: from mail-pg0-f48.google.com (mail-pg0-f48.google.com [74.125.83.48]) (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 82CA3129A6C for ; Tue, 21 Mar 2017 08:28:36 -0700 (PDT) Received: by mail-pg0-f48.google.com with SMTP id n190so95453251pga.0 for ; Tue, 21 Mar 2017 08:28:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=OS3BniQSndr/Msn+uCoxLZjnOxIu4PY6QYBUH8dosrc=; b=MNWJUvqZKUJU0GJC0LfwBQyDsn4ZTGBlGgseKo1PNRjOF2Jrd3pZm9jvm58s4AGyr2 aDoa5sPrVWiDU7pg2v9hVDNvZSDpF8LRXONzebgaVfgopNT/5gedaA7NmTvD3Afnyc8E mPhP+pFIN2ZnX6v+/mELw7ZnlKMSwO6X4GTMB5LT1Mfk3My5ebLz8UPf7YjWYt4a7I3v Lh+wUdKQBlV0oeAOHI9uvUaRyVPzNN5Ktvryi+7LPLz7U0ZARiBGpW/Jwhy/q0Wpk5lE 1ar7gjq2zN7ycJI4N/K0lKaGOj+2e6L2SoikUBlDs+MkgNlFqu3UhOeARosQ4KmzTVno i0sw== X-Gm-Message-State: AFeK/H0mcJZOxYQ57KOMCu6zwordEEilm8bK8/KpzW1le4JltJI03HrW7wU6BPG7OglU0g== X-Received: by 10.99.42.78 with SMTP id q75mr38181514pgq.144.1490110115937; Tue, 21 Mar 2017 08:28:35 -0700 (PDT) Received: from localhost ([192.147.168.22]) by smtp.gmail.com with ESMTPSA id n185sm40497212pga.9.2017.03.21.08.28.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Mar 2017 08:28:34 -0700 (PDT) Date: Tue, 21 Mar 2017 16:28:31 +0100 From: Job Snijders To: "John G. Scudder" Cc: Jeffrey Haas , "idr-chairs@ietf.org" , "idr@ietf.org" Message-ID: <20170321152831.eckddfckenvblzu3@Vurt.local> References: <4eedda5c2db74539bd0f949e38cb8b26@XCH-ALN-014.cisco.com> <20170320194414.GD26130@pfrc.org> <20170320201455.micjs4yvzvyoycw6@Vurt.local> <20170320204125.GH28021@pfrc.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: NeoMutt/20170306 (1.8.0) Archived-At: Subject: Re: [Idr] Early allocation for draft-ietf-idr-bgp-gr-notification X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 15:28:56 -0000 On Mon, Mar 20, 2017 at 05:49:50PM -0400, John G. Scudder wrote: > On Mar 20, 2017, at 4:41 PM, Jeffrey Haas wrote: > > On Mon, Mar 20, 2017 at 09:14:55PM +0100, Job Snijders wrote: > > [session culling] > >>> I haven't yet read this draft, so take my further comments with that under > >>> consideration. > >> > >> ack. Please read the draft. We may have a fundamental problem on our > >> hands here. > > > > I read it. It's a weird hack, but it works. :-) > > With respect to what "culling" calls "Involuntary BGP Session > Teardown", there is potentially a problem, but I think it's not > insurmountable. The problem, to the extent it exists, is that > "culling" suggests the IX switch fabric should be configured to block > BGP traffic, causing the hold time to expire. gr-notification > interferes by putting the session into GR mode: > > When a BGP speaker resets its session due to a HOLDTIME expiry, it > should generate the relevant BGP NOTIFICATION message as mentioned in > [RFC4271], but subsequently it MUST follow the rules for the > Receiving Speaker mentioned in Section 4.1. > > At first this might seem alarming, but my observation is that the > weird hack already relies on waiting several minutes for the hold time > to expire. So, it doesn't seem terrible to add a few more minutes to > wait for the stale route timeout as well. Your analysis is helpful. We might add a note to the bgp-culling draft that "GR Notification" could negatively affect with the minimum required bgp culling time spam. > Although "culling" doesn't discuss how to determine the maintenance > can proceed, it would seem both prudent and straightforward to do so > by monitoring the traffic level between the affected peers, since > presumably the IX operator doesn't have a priori knowledge of the hold > time in use. Once routing has converged away from the path, the > traffic level will drop, and the maintenance can proceed, regardless > of what perversions are in use in the control plane. Correct. Kind regards, Job From nobody Tue Mar 21 08:47:10 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 235D5129AAF for ; Tue, 21 Mar 2017 08:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VaF-50lk8lw8 for ; Tue, 21 Mar 2017 08:47:06 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 9A826129B36 for ; Tue, 21 Mar 2017 08:44:51 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=70.194.19.173; From: "Susan Hares" To: Date: Tue, 21 Mar 2017 11:39:44 -0400 Message-ID: <02a501d2a259$5db07480$19115d80$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02A6_01D2A237.D69F22A0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdKiWO9ZeEqOCOdAT/OaWjlkG83DOA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] [spring] IDR WG 2 week WG LC on draft-ietf-idr-bgpls-segment-routing-epe - (2/15/2017 to 3/1/2017) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 15:47:08 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02A6_01D2A237.D69F22A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The IDR WG has reached consensus on draft-ietf-idr-bgpls-segment-routing-epe, and approved it for publications. It will be forwarded to the IESG for publication. The next steps in publication are shepherd review and AD Review. In parallel, there will be a final directorate review. Sue Hares and John Scudder ------=_NextPart_000_02A6_01D2A237.D69F22A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The IDR WG = has reached consensus on draft-ietf-idr-bgpls-segment-routing-epe, and = approved it for publications.    It will be forwarded to = the IESG for publication.  The next steps in publication are = shepherd review and AD Review.  In parallel, there will be a final = directorate review.

 

Sue Hares = and John Scudder

------=_NextPart_000_02A6_01D2A237.D69F22A0-- From nobody Tue Mar 21 09:01:09 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C526129AB2 for ; Tue, 21 Mar 2017 09:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.947 X-Spam-Level: X-Spam-Status: No, score=0.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v2wfHYcu5rIf for ; Tue, 21 Mar 2017 09:01:06 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 51C381294B8 for ; Tue, 21 Mar 2017 09:00:56 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=70.194.19.173; From: "Susan Hares" To: "'Eric C Rosen'" , Cc: References: <048701d29cd9$15204b80$3f60e280$@olddog.co.uk> <022201d29ce6$ffb2ba40$ff182ec0$@ndzh.com> In-Reply-To: Date: Tue, 21 Mar 2017 11:55:58 -0400 Message-ID: <02dc01d2a25b$a1eca590$e5c5f0b0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02DD_01D2A23A.1ADD0160" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHgLJVhftftdlZ2OeQGM5dxbx7ZtQIfusEjApalZLqhXqec8A== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] Thoughts on https://www.ietf.org/id/draft-hares-idr-bgp-registries-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 16:01:08 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02DD_01D2A23A.1ADD0160 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Eric: Politics: I do not know how this introduces politics - since it is just the WG chairs. The WG chairs for BGP related groups are very collaborative. If they are not collaborative, the ADs can work with or replace the WG chairs. How does it speed up things? It provides 8 designated experts which means IANA does not have to chase down a few people (2-3). This is the most often reason for IANA slow-downs (AFAIK). The collaborative chairs can decide on a rotation for a designated person to check up with other chairs. The new datatracker review process could automate that process. If you think this should have a time limit (for example - 2 weeks), I agree. I also believe it should run concurrent with other processes. This process should start after the AD review considers document worthy and it MUST start no later than IETF LC (2 weeks). With these additions, I do not think it will slow down the process. Have I responded to all your concerns? If you think these mitigate the problems, I will provide a revision to the draft that specifies these changes. Sue -----Original Message----- From: Eric C Rosen [mailto:erosen@juniper.net] Sent: Tuesday, March 14, 2017 3:38 PM To: Susan Hares; adrian@olddog.co.uk Cc: idr@ietf.org Subject: Re: [Idr] Thoughts on https://www.ietf.org/id/draft-hares-idr-bgp-registries-01.txt I don't think we need any more procedural hurdles that will slow down the allocation process or that will introduce more politics into it. The draft does not seem to be a solution to any problem, it just adds process and politics. It claims to have the goal of "increasing the pace of early allocation", and proposes to do this by requiring allocations to be approved by a committee of WG chairs or other designated "experts". It neglects to say how having more committees will increase the pace. No doubt the designated experts will make their decisions "soon", as that term is defined in draft-farrel-soon. Adoption of this draft will result in more squatting rather than less. Furthermore, a number of the mentioned registries were not established by the IDR WG, and I don't see that the IDR WG has any standing to request changes in the registration policies of those registries. ------=_NextPart_000_02DD_01D2A23A.1ADD0160 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Eric: =

 

Politics: I do not know how this introduces = politics - since it is just the WG chairs.  The WG chairs for BGP = related groups are very collaborative.  If they are not = collaborative, the ADs can work with or replace the WG chairs.  =  

 

How does it speed up things?  It = provides 8 designated experts which means IANA does not have to chase = down a few people (2-3).   This is the most often reason for = IANA slow-downs (AFAIK).  The collaborative chairs can decide on a = rotation for a designated person to check up with other chairs. =  The new datatracker review process could automate that process. If = you think this should have a time limit (for example - 2 weeks), I = agree.  I also believe it should run concurrent with other = processes.  This process should start after the AD review considers = document worthy and it MUST start no later than IETF LC (2 = weeks).   With these additions, I do not think it will slow = down the process.

 

Have I = responded to all your concerns?  If you think these mitigate the = problems, I will provide a revision to the draft that specifies these = changes.

 

Sue

 

 

 

-----Original Message-----
From: Eric C Rosen = [mailto:erosen@juniper.net]
Sent: Tuesday, March 14, 2017 3:38 = PM
To: Susan Hares; adrian@olddog.co.uk
Cc: = idr@ietf.org
Subject: Re: [Idr] Thoughts on = https://www.ietf.org/id/draft-hares-idr-bgp-registries-01.txt

 

I = don't think we need any more procedural hurdles that will slow down the = allocation process or that will introduce more politics into = it.

 

The draft does not seem to be a solution to any = problem, it just adds process and politics.  It claims to have the = goal of "increasing the pace of early allocation", and = proposes to do this by requiring allocations to be approved by a = committee of WG chairs or other designated "experts".  It = neglects to say how having more committees will increase the = pace.

 

No doubt the designated experts will make their = decisions "soon", as that term is defined in = draft-farrel-soon.

 

Adoption of this draft will result in more = squatting rather than less.

 

Furthermore, a number of the mentioned registries = were not established by the IDR WG, and I don't see that the IDR WG has = any standing to request changes in the registration policies of those = registries.

 

 

 

 

 

------=_NextPart_000_02DD_01D2A23A.1ADD0160-- From nobody Tue Mar 21 09:26:35 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25900129B83 for ; Tue, 21 Mar 2017 09:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.947 X-Spam-Level: X-Spam-Status: No, score=0.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NwunzszfWdKH for ; Tue, 21 Mar 2017 09:26:32 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 3331A129B44 for ; Tue, 21 Mar 2017 09:26:32 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=70.194.19.173; From: "Susan Hares" To: "'Robert Raszuk'" , "'Eric C Rosen'" Cc: "'idr wg'" References: <048701d29cd9$15204b80$3f60e280$@olddog.co.uk> <022201d29ce6$ffb2ba40$ff182ec0$@ndzh.com> In-Reply-To: Date: Tue, 21 Mar 2017 12:04:56 -0400 Message-ID: <02e901d2a25c$e29e45c0$a7dad140$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02EA_01D2A23B.5B8F8BF0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHgLJVhftftdlZ2OeQGM5dxbx7ZtQIfusEjApalZLoCoxIrnaFJkpMQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] Thoughts on https://www.ietf.org/id/draft-hares-idr-bgp-registries-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 16:26:34 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02EA_01D2A23B.5B8F8BF0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Robert:=20 =20 Please see my post to Eric responding to politics and delay. =20 =20 What you are describing is a FCFS. Rather than a wiki, why not IANA? = IANA can provide and maintains these numbers. IANA=E2=80=99s response = time on FCFS allocations is quick. If you believe a FCFS is = appropriate for BGP attributes and AFI/SAFs, I encourage you to write a = draft on that topic. =20 =20 Sue=20 =20 From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk Sent: Tuesday, March 14, 2017 4:35 PM To: Eric C Rosen Cc: Susan Hares; idr wg Subject: Re: [Idr] Thoughts on = https://www.ietf.org/id/draft-hares-idr-bgp-registries-01.txt =20 =20 I very much agree with Eric here.=20 =20 All what needs to be done to prevent squatting is a public wiki page in = IETF (across WGs) with pool of available BGP attribute code points as = well as AFI/SAFIs where whoever has a draft and is implementing it ahead = of IETF politics takes next available code and links it with a draft = name. Then she or he may come to WG with proven implementation at hand. =20 By default considering how fast IETF moves such self registration could = be valid for 5 years. After that either the spec is dead and it is ok to = free up the code or draft becomes RFC. Submitter can free up the code = earlier too.=20 =20 All committees, designated experts, tiger/design teams will just have = opposite effect and granted will scare folks who need to implement = something for their internal use or for their dedicated customers = resulting in much more squatting. Does anyone really believes that if = "expert" tells "NO" then the given implementation will get abandoned ?=20 =20 The same should apply to other protocols .. however BGP is the lowest = hanging fruit so one could start with that. =20 =20 =20 On Tue, Mar 14, 2017 at 8:38 PM, Eric C Rosen = wrote: I don't think we need any more procedural hurdles that will slow down = the allocation process or that will introduce more politics into it. The draft does not seem to be a solution to any problem, it just adds = process and politics. It claims to have the goal of "increasing the = pace of early allocation", and proposes to do this by requiring = allocations to be approved by a committee of WG chairs or other = designated "experts". It neglects to say how having more committees = will increase the pace. No doubt the designated experts will make their decisions "soon", as = that term is defined in draft-farrel-soon. Adoption of this draft will result in more squatting rather than less. Furthermore, a number of the mentioned registries were not established = by the IDR WG, and I don't see that the IDR WG has any standing to = request changes in the registration policies of those registries. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr =20 ------=_NextPart_000_02EA_01D2A23B.5B8F8BF0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Robert:

 

Please see my post to Eric responding to politics and delay. = =C2=A0

 

What you are describing is a FCFS.=C2=A0 Rather than a wiki, why not = IANA? =C2=A0IANA can provide and maintains these numbers.=C2=A0 = IANA=E2=80=99s response time on FCFS allocations is quick.=C2=A0=C2=A0 = If you believe a FCFS is appropriate for BGP attributes and AFI/SAFs, = =C2=A0I encourage you to write a draft on that topic. = =C2=A0

 

Sue

 

From:= = Idr [mailto:idr-bounces@ietf.org] On Behalf Of Robert = Raszuk
Sent: Tuesday, March 14, 2017 4:35 PM
To: = Eric C Rosen
Cc: Susan Hares; idr wg
Subject: Re: = [Idr] Thoughts on = https://www.ietf.org/id/draft-hares-idr-bgp-registries-01.txt<= /span>

 

 

I very much agree with Eric = here. 

 

All what needs to be done to = prevent squatting is a public wiki page in IETF (across WGs) with pool = of available BGP attribute code points as well as AFI/SAFIs where = whoever has a draft and is implementing it ahead of IETF politics takes = next available code and links it with a draft name. Then she or he may = come to WG with proven implementation at = hand.

 

By default considering how = fast IETF moves such self registration could be valid for 5 years. After = that either the spec is dead and it is ok to free up the code or draft = becomes RFC. Submitter can free up the code earlier = too. 

 

All committees, designated = experts, tiger/design teams will just have opposite effect and granted = will scare folks who need to implement something for their internal use = or for their dedicated customers resulting in much more squatting. Does = anyone really believes that if "expert" tells =  "NO" then the given implementation will get abandoned = ? 

 

The same should apply to = other protocols .. however BGP is the lowest hanging fruit so one could = start with that.

 

 

 

On Tue, Mar 14, 2017 at 8:38 PM, Eric C Rosen <erosen@juniper.net> wrote:

I don't think we need any more procedural hurdles that = will slow down the allocation process or that will introduce more = politics into it.

The draft does not seem to be a solution to any = problem, it just adds process and politics.  It claims to have the = goal of "increasing the pace of early allocation", and = proposes to do this by requiring allocations to be approved by a = committee of WG chairs or other designated "experts".  It = neglects to say how having more committees will increase the = pace.

No doubt the designated experts will make their decisions = "soon", as that term is defined in = draft-farrel-soon.

Adoption of this draft will result in more = squatting rather than less.

Furthermore, a number of the = mentioned registries were not established by the IDR WG, and I don't see = that the IDR WG has any standing to request changes in the registration = policies of those registries.







_______________________________= ________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

 

------=_NextPart_000_02EA_01D2A23B.5B8F8BF0-- From nobody Tue Mar 21 09:58:15 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1D40129C12 for ; Tue, 21 Mar 2017 09:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wih5v5Mzoy6c for ; Tue, 21 Mar 2017 09:58:12 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 57CEC129C11 for ; Tue, 21 Mar 2017 09:58:12 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=70.194.19.173; From: "Susan Hares" To: "'idr wg'" Date: Tue, 21 Mar 2017 12:53:14 -0400 Message-ID: <035901d2a263$a204a0c0$e60de240$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_035A_01D2A242.1AF34EE0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdKiYoj5WABkkGMdRjO4hb7phG9PSQ== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] 2 Week WG LC for draft-ietf-idr-bgp-prefix-sid-04.txt - 3/6 to 3/20/2017 - extending to 3/31 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 16:58:14 -0000 This is a multipart message in MIME format. ------=_NextPart_000_035A_01D2A242.1AF34EE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit IDR WG: Perhaps the WG LC came at a bad time since have received only 1 response. We will length the call to 3/31. Unless with have substantial input, this WG LC will not indicate consensus. Sue Hares ------=_NextPart_000_035A_01D2A242.1AF34EE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

IDR WG: =

 

Perhaps the WG LC came at a bad time since have = received only 1 response.  We will length the call to 3/31.  = Unless with have substantial input, this WG LC will not indicate = consensus.

 

Sue Hares

------=_NextPart_000_035A_01D2A242.1AF34EE0-- From nobody Tue Mar 21 10:04:16 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3704C1286B1; Tue, 21 Mar 2017 10:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.947 X-Spam-Level: X-Spam-Status: No, score=0.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fJ2RwXkXkuTA; Tue, 21 Mar 2017 10:04:13 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 9289D1294BF; Tue, 21 Mar 2017 10:04:13 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=70.194.19.173; From: "Susan Hares" To: "'John G. Scudder'" , "'Job Snijders'" Cc: "'Jakob Heitz \(jheitz\)'" , , References: <4eedda5c2db74539bd0f949e38cb8b26@XCH-ALN-014.cisco.com> <530CFCF4-36BE-426C-AAE5-55BC680810DB@juniper.net> In-Reply-To: <530CFCF4-36BE-426C-AAE5-55BC680810DB@juniper.net> Date: Tue, 21 Mar 2017 12:59:03 -0400 Message-ID: <036601d2a264$723bd9c0$56b38d40$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0367_01D2A242.EB2BE770" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJNtEkTgzlTKZaIcQptCFnf9VYXegKMmzFfAqlI3D+gf7Dy4A== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] Early allocation for draft-ietf-idr-bgp-gr-notification X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 17:04:15 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0367_01D2A242.EB2BE770 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit John: Will you revise the draft prior to early allocation call to remove this code point? Sue Hares (co-chair hat) From: John G. Scudder [mailto:jgs@juniper.net] Sent: Monday, March 20, 2017 3:46 PM To: Job Snijders Cc: Jakob Heitz (jheitz); idr-chairs@ietf.org; idr@ietf.org Subject: Re: [Idr] Early allocation for draft-ietf-idr-bgp-gr-notification On Mar 18, 2017, at 6:53 AM, Job Snijders wrote: Given the 50+ years of combined IETF experience the authors of this draft possess, I'm somewhat surprised to see a suggested value in the IANA considerations instead of "TBD". See the last major bullet point here: https://trac.ietf.org/trac/idr/wiki/Checklist%20for%20writing%20a%20BGP-rela ted%20draft Considering my name's in the list at the top of the draft, and that I wrote the bullet point in question, that's on me. This is what you should not do. If someone brings a dunce cap for me to wear during the chair's portion of the meeting, I will. --John ------=_NextPart_000_0367_01D2A242.EB2BE770 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

John:

 

Will you revise the draft prior to early allocation call to remove = this code point?

 

Sue Hares

(co-chair hat)

 

From:= = John G. Scudder [mailto:jgs@juniper.net]
Sent: Monday, March = 20, 2017 3:46 PM
To: Job Snijders
Cc: Jakob Heitz = (jheitz); idr-chairs@ietf.org; idr@ietf.org
Subject: Re: [Idr] = Early allocation for = draft-ietf-idr-bgp-gr-notification

 

On Mar 18, = 2017, at 6:53 AM, Job Snijders <job@ntt.net> = wrote:

Given the = 50+ years of combined IETF experience the authors of this draft possess, = I'm somewhat surprised to see a suggested value in the IANA = considerations instead of "TBD". See the last major bullet = point here: https://trac.ietf.org/trac/idr/wiki/Checklist%20for%20w= riting%20a%20BGP-related%20draft

 

Considering my name's in the list at the top of the = draft, and that I wrote the bullet point in question, that's on me. This = is what you should not do.

 

If someone brings a dunce cap for me to wear during = the chair's portion of the meeting, I will.

 

--John

 

------=_NextPart_000_0367_01D2A242.EB2BE770-- From nobody Tue Mar 21 10:14:38 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64572129C37; Tue, 21 Mar 2017 10:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eg8f2WO5SqOi; Tue, 21 Mar 2017 10:14:30 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 0F132129C31; Tue, 21 Mar 2017 10:14:26 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=70.194.19.173; From: "Susan Hares" To: "'John G. Scudder'" , "'Jeffrey Haas'" , "'Job Snijders'" Cc: , References: <4eedda5c2db74539bd0f949e38cb8b26@XCH-ALN-014.cisco.com> <20170320194414.GD26130@pfrc.org> <20170320201455.micjs4yvzvyoycw6@Vurt.local> <20170320204125.GH28021@pfrc.org> In-Reply-To: Date: Tue, 21 Mar 2017 13:09:21 -0400 Message-ID: <038301d2a265$e2a73050$a7f590f0$@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: AQJNtEkTgzlTKZaIcQptCFnf9VYXegKMmzFfARE8EXkBphrc1ADa2DYnAZHOVWaga93+4A== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] Early allocation for draft-ietf-idr-bgp-gr-notification X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 17:14:31 -0000 John, Jeff, Keyur and Job: It sounds like these two drafts are protocol and grow operational notes. Is this correct? Sue -----Original Message----- From: John G. Scudder [mailto:jgs@juniper.net] Sent: Monday, March 20, 2017 5:50 PM To: Jeffrey Haas; Job Snijders Cc: idr-chairs@ietf.org; idr@ietf.org Subject: Re: [Idr] Early allocation for draft-ietf-idr-bgp-gr-notification On Mar 20, 2017, at 4:41 PM, Jeffrey Haas wrote: > On Mon, Mar 20, 2017 at 09:14:55PM +0100, Job Snijders wrote: > [session culling] >>> I haven't yet read this draft, so take my further comments with that >>> under consideration. >> >> ack. Please read the draft. We may have a fundamental problem on our >> hands here. > > I read it. It's a weird hack, but it works. :-) With respect to what "culling" calls "Voluntary BGP Session Teardown", there's no problem. A pair of implementations that implement gr-notification would already be expected to do the right thing when the session was administratively shut down, by sending a hard reset. With respect to what "culling" calls "Involuntary BGP Session Teardown", there is potentially a problem, but I think it's not insurmountable. The problem, to the extent it exists, is that "culling" suggests the IX switch fabric should be configured to block BGP traffic, causing the hold time to expire. gr-notification interferes by putting the session into GR mode: When a BGP speaker resets its session due to a HOLDTIME expiry, it should generate the relevant BGP NOTIFICATION message as mentioned in [RFC4271], but subsequently it MUST follow the rules for the Receiving Speaker mentioned in Section 4.1. At first this might seem alarming, but my observation is that the weird hack already relies on waiting several minutes for the hold time to expire. So, it doesn't seem terrible to add a few more minutes to wait for the stale route timeout as well. Although "culling" doesn't discuss how to determine the maintenance can proceed, it would seem both prudent and straightforward to do so by monitoring the traffic level between the affected peers, since presumably the IX operator doesn't have a priori knowledge of the hold time in use. Once routing has converged away from the path, the traffic level will drop, and the maintenance can proceed, regardless of what perversions are in use in the control plane. --John P.S.: I take no position, in this note, as to whether the suggestion in "culling" to filter BGP control traffic as an IX management practice is a good one. From nobody Tue Mar 21 10:40:29 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17E0B129C58 for ; Tue, 21 Mar 2017 10:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XXaDvXQTVqW8 for ; Tue, 21 Mar 2017 10:40:22 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3895B129542 for ; Tue, 21 Mar 2017 10:40:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4493; q=dns/txt; s=iport; t=1490118012; x=1491327612; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=Q3s4flCVkeiGR+KKwMKd5xhnvnYCQ4jB+1d8hhcx01U=; b=ETmEP+9wz3LvJU1rczOELv9rgvLPZej7vwpzjAEefHjbcNDdQnyH/I0W N3fSGONcNNAFnuXeVEqgVdZa6L1X+CZNa7S3BUQWvSM0hAoa0tValLeSy ApTrWbcu2Q5RlUEl6U8NsD0EPNvb+h7CV4gb+b/R6KAIycJOdwwAZ5syy I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BoAQCaZNFY/4MNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5jYYEKB41rkV6QFYUvgg6GIgKDFD8YAQIBAQEBAQEBayiFFQE?= =?us-ascii?q?BAQEDLVwCAQgOAwMBAiQEBzIUCQgBAQQBEooErF2KSwEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAR2LPYR0hUUFnFABkkWRLZNeAR84gQRYFUGEVx0ZgUp1iDSBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.36,200,1486425600"; d="scan'208,217";a="221285869" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Mar 2017 17:40:11 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v2LHeBJY011675 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 21 Mar 2017 17:40:11 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 21 Mar 2017 13:40:10 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Tue, 21 Mar 2017 13:40:10 -0400 From: "Acee Lindem (acee)" To: Susan Hares , "'idr wg'" Thread-Topic: [Idr] 2 Week WG LC for draft-ietf-idr-bgp-prefix-sid-04.txt - 3/6 to 3/20/2017 - extending to 3/31 Thread-Index: AdKiYoj5WABkkGMdRjO4hb7phG9PSQAB6PiA Date: Tue, 21 Mar 2017 17:40:10 +0000 Message-ID: References: <035901d2a263$a204a0c0$e60de240$@ndzh.com> In-Reply-To: <035901d2a263$a204a0c0$e60de240$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.198] Content-Type: multipart/alternative; boundary="_000_D4F6DCFDA3929aceeciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] 2 Week WG LC for draft-ietf-idr-bgp-prefix-sid-04.txt - 3/6 to 3/20/2017 - extending to 3/31 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 17:40:24 -0000 --_000_D4F6DCFDA3929aceeciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support as a co-author. I know of no IPR. Thanks, Acee From: Idr > on behalf of = Susan Hares > Date: Tuesday, March 21, 2017 at 12:53 PM To: IDR List > Subject: Re: [Idr] 2 Week WG LC for draft-ietf-idr-bgp-prefix-sid-04.txt - = 3/6 to 3/20/2017 - extending to 3/31 IDR WG: Perhaps the WG LC came at a bad time since have received only 1 response. = We will length the call to 3/31. Unless with have substantial input, this = WG LC will not indicate consensus. Sue Hares --_000_D4F6DCFDA3929aceeciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
I support as a co-author. I know of no IPR.
Thanks,
Acee 

From: Idr <idr-bounces@ietf.org> on behalf of Susan Hares &l= t;shares@ndzh.com>
Date: Tuesday, March 21, 2017 at 12= :53 PM
To: IDR List <idr@ietf.org>
Subject: Re: [Idr] 2 Week WG LC for= draft-ietf-idr-bgp-prefix-sid-04.txt - 3/6 to 3/20/2017 - extending to 3/3= 1

IDR WG:

 

Perhaps the WG LC came at a bad time since have rece= ived only 1 response.  We will length the call to 3/31.  Unless w= ith have substantial input, this WG LC will not indicate consensus.

 

Sue Hares

--_000_D4F6DCFDA3929aceeciscocom_-- From nobody Tue Mar 21 10:52:05 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 778711299D6; Tue, 21 Mar 2017 10:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Ud3QjUm68Ke; Tue, 21 Mar 2017 10:52:00 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0113.outbound.protection.outlook.com [104.47.41.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38949128854; Tue, 21 Mar 2017 10:52:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=XlrkiJarv9i4lDkanq5f55s/uZ0WEO0afJCkRKqDyms=; b=HQqkf0aAkf3WhTKo6D6DKBGNYS0tym7pnmovCcJl2xFS39GIZixEFM/1MgnGXxAs82S/1x2Kof2QqV25ODR3vHpkXkVv2d65bJpmbBOlubSoR9L2IZ2Uk+oi3pXEe6MJJGM0omqBYYA7jBL6m9977aop7Ney/MojebbypKI+UBE= Authentication-Results: ndzh.com; dkim=none (message not signed) header.d=none;ndzh.com; dmarc=none action=none header.from=juniper.net; Received: from [172.29.37.164] (66.129.241.12) by SN2PR05MB2510.namprd05.prod.outlook.com (10.166.213.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.4; Tue, 21 Mar 2017 17:51:58 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "John G. Scudder" In-Reply-To: <036601d2a264$723bd9c0$56b38d40$@ndzh.com> Date: Tue, 21 Mar 2017 13:51:54 -0400 CC: Job Snijders , "Jakob Heitz (jheitz)" , idr-chairs , Content-Transfer-Encoding: quoted-printable Message-ID: <8647255E-B782-4C55-95C1-B68C7DAF8347@juniper.net> References: <4eedda5c2db74539bd0f949e38cb8b26@XCH-ALN-014.cisco.com> <530CFCF4-36BE-426C-AAE5-55BC680810DB@juniper.net> <036601d2a264$723bd9c0$56b38d40$@ndzh.com> To: Susan Hares X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.12] X-ClientProxiedBy: BN6PR14CA0030.namprd14.prod.outlook.com (10.171.172.144) To SN2PR05MB2510.namprd05.prod.outlook.com (10.166.213.19) X-MS-Office365-Filtering-Correlation-Id: a17d66be-02a7-4ca9-32c0-08d47082f904 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:SN2PR05MB2510; X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2510; 3:2DYmZ3HCBbBpIDe6Q2MAEqJaFyXfTiNi94Hyqx2yW2GwLBHjkNg3f5SvpFTOR4xEOE4O13yb1S+7LLJ9DdTb1RC1C+abCeLIM4UHhi2b8G8/S1ZWxK3otE9iBJ396oN7LWUrkkGitG814zM39sThfw5Ov6p2nBkrvBUIFKzLBtMoA3/0aOm92AfA+ljAbRr1pcAXxVRC6LnabZvvabznoF29epJZU4wLIp3Myyc+Ts4v+08h3xrIPdqxiu3MaLLz09IeU8fjK+RCGw1NoT4lNQlXfhToodIms4vhoDfknSQ=; 25:9daK2zZC5Z40eaPdz85NVzVVIWoXZ0ppZeXOXawFIcg3eR1gEHuymckVJN4f2Za6EfH+cWbAOqjTi67TpGqIU9284q3kHft34r83MSiPyrJ4zWSaD7nP7T6nGjv1acGlKy4e8aajgUvTdS98nUxJ7m6zF502AzklR5GINQiZwd0ZLe/pixPk18nho8j7LFSgOKehXugeYpgnav08BSYqMyMigIambeC2LLSZL6fZiL+URPcdP5l/7vi0DU80wHaOlQWQoTzV1TjGutwW+JS8m2ItVUOKxXjSqAxtixHYnbj83pX6Yg/TuR7Mp6A9lCJGLumzjkm0yCVw5uvfnY/RFgjd9U8+BAq7zh9P58DN3yehUkH4yzfePpDCyz5yZhb0ejaYQnvz/jStHMRv6nwqVD2agubpdGo53spuikepqTjEE26/yN1cxFpSlNrFalZ4veKsqFv7ADvgRbWJb/vv6g== X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2510; 31:x/PazzcEm+WbCtJcIG3/FE3wJIsrlYMvoyi8Kwhg9Cj4J/YdFthdaWUhJttVp4JH4Aj/thJ0b2nl1C+B3UZ0uTbrhh6rl5OjZmpWOu+9XyLpD1b+yCeZdUby2z2p/uFFmVFT88OiZDb0W4iVV3YeFLl/vfWHo6Mty+OrZAaPvSmtYRvysoO4RpLQUVuu0VuD0fktgfe2fZel2U+IGp2cBDIQXR/wx5A8xdtos1qWjxBKbTxuPXh6LLCDbGpXmdHLrinMpF6h9vuaKUYk8Kbs+Z1rF4qFG7wDiKMLKB+Onn4=; 20:p/X7KdNNqyizRQbNbFdJZtVikv0O42aB12ScwX4aL2YZGwI5wyx96bgQvir/leIbCJaCEtcDly3V9flH8Adawc+be6ipUO5TeLGBUhni1gu3eY7EpGiGvPXZ/HyYoJ4qptS9mEiinn10SyvL0QDR42lXOkyGDPY4M1sDuRYofPw6baeHyQ/awB7mLM86sdClc9Xj7oduuL/M8iUvIflsraqs8CQz2NWMhM9OUbgvvO2l4IIdt3Rmt6mbblwa+oY91221l8LOlIKLtiXdRNnIG+MBmIGozXSshpPpZLBdIo2e+Uef0+wfqqEGZeUOEruhLMAvgogbwIGY8plcwMcKs3a9sX0G3le6VUy/0kCmHcocKGedBXHCD6koBQwnurxBEZLYZGrc89Onv0yoHkNJ443VH+YniguAtSVOVZjNbRl6PhcoOoT3tXjvl5snkbfrZCEkzLTa0GutOcJ1U5HqpKTwH1NLczrRvXJ0uD3erx16TDtYZvUFZhV5tJczdXtUNZfBeDTOQCp7tEHXridB4FAG6GwvmcZw4Ooqok2WJH5uJlqc4sneJKGAaKS+WxuO5HzfS+3pY5hfXkcPwqGGKn5kKD4tFHjSj1pDYYnjHAI= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(20161123562025)(20161123558025)(20161123564025)(20161123555025)(6072148); SRVR:SN2PR05MB2510; BCL:0; PCL:0; RULEID:; SRVR:SN2PR05MB2510; X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2510; 4:X9oeQCdYNuTaVGfi2QjsZsy0ISmOYwRF3Im/kw8fovYwaLeakHVBWePO8r4rPkaV5PNK7auTTm/Gm6E0gWDNwyQuFwxU5vVgz0kZMkmX7Lp//NkKAdf/HcCjmjiREcKCziPH8tRNk0oz2lnM/zOzzBt9pUOpLF44G/5CMxK/6curmcm5avFGpWw6NtSCwx3fpUoVGJ0SMUe2Sf9L9hhm0gBhRpashxqnkxHgnkm9Jc2ZNgOJhJHI28ziubYHGjMuUtw26YffhpGBJ+fAoumK2uCP/NIAfBku7dspPAYdEuXGpMvmf5Rj4hONTUk2SlTBpj5K3SiZ3WAt6LUjZR7iURjsOgBLcjch/BNvPKCu6TJ6FoatsIrQjfgvfnGkLy8q1cGwtCSIitPL0Dxd8PlM6pgtfl61NnweT5UFgMXsdF0omg7D8dBE/ZA63SuOZi+A52qJRDP47Hbmsc1ySJN6/gXLyvRIbQTpTk14jiKis0sFG+375NgAf65VCNXyR7a0Vt8U+2qlVLiwjLPKSc8mFJhHSnA2P1pMNOtvf8iTHOf2IVm1aCK3oGGH2Y/bTo1vDxxrl4Ewi+RBZGQY7p2loWZz6tGoWzlZS/YkwoPclvYrlReMYThSW7ZtDud1FBFG X-Forefront-PRVS: 02530BD3AA X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(39450400003)(39410400002)(39840400002)(39850400002)(39860400002)(24454002)(377424004)(377454003)(3846002)(4326008)(6116002)(6486002)(66066001)(305945005)(50466002)(83716003)(23726003)(86362001)(77096006)(229853002)(6916009)(2950100002)(6666003)(2906002)(57306001)(82746002)(38730400002)(110136004)(47776003)(25786009)(7736002)(36756003)(189998001)(6246003)(5660300001)(81166006)(90366009)(46406003)(50986999)(8676002)(53936002)(50226002)(97756001)(93886004)(33656002)(230783001)(8746002)(76176999)(42186005)(54906002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR05MB2510; H:[172.29.37.164]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN2PR05MB2510; 23:4yW9zCfaoe7nUFyGjjvxhKdECJfHU1SviDg27eU6T?= =?us-ascii?Q?dIVDUH1DBSP4RBbQNerRYUEsvaA97qOwGkwXfI6h7iAg5/g8II9l1DBqnaCn?= =?us-ascii?Q?MPExTnLcp1KCLNMDJ/azDg8MAKMwrbFnsRaozbnars+IYLfJllRTTkRCdHK+?= =?us-ascii?Q?pU2ruLw/SdgPkPwVUvmetTL8QnoyO9u4rDMD2kO41/Fm6hZ4GnwmfHClKQdR?= =?us-ascii?Q?KjKMO2Ny/+gJR4TP1mhJgX3mz/iwNp84QFwJWhr1jLzpZ00oXkWUvdbKv2+U?= =?us-ascii?Q?1aCFEOxbp6DHq0P9np1ocxBgGN8GprvXJ86N9uGf2SmGP6ptrNWyju6krSgO?= =?us-ascii?Q?IaDeZA0dM6cVCHS9b2meoSE4Wtd5fjlIhx4c8YIoyFawRMTPx82Qps5PLUlp?= =?us-ascii?Q?FxSmIYvTgtT6bIrt8Ig6pMwthkIpwCVQ4156NMcFCZfw8Vf9PCX7foTKse9V?= =?us-ascii?Q?6ZDWwsdXiqSCkAaL/uj/uoAfk+uLYSWjHR3NSU14JfiTqKa5qr7tt70cvHUU?= =?us-ascii?Q?HRP+wN9yVc7yFTWfBsglttfPzjSzMpqS/Dlr1m5X0OvUN5QIIDAmn4IwrDkq?= =?us-ascii?Q?29XLvGGN39WA+WsEebve2O5GP1zdRahu5MN1MjWBTMrUo9hZdNO9yV8H6gBC?= =?us-ascii?Q?G9OWmWtlV5lMCq11Cnh54lU5N+wyq7POuQiu6OVUNs+wIR8Z6nhWG0S698H9?= =?us-ascii?Q?lmKiDfD2pX9VJCDfUHlHQRjsDd+mzHwOW3wiGwe5zy7NgUw40yx9fdYUy6aK?= =?us-ascii?Q?iyLu/UNX1Dc723uBn54kaoHBfrcLLYRP6nONXSybo6mhIE4DSFAoIyyRiFOT?= =?us-ascii?Q?WZ+LuR7nQZTJguPf7Ecx6S/5iXSsslAwCKwF6oHIS3g2t0vfBTAinkvg/V3C?= =?us-ascii?Q?YUVUmCK8mj1DOljXeEGeZDnPbEte7d/JwRXol9xDFgp2UsrcXQL+gZX/zi1k?= =?us-ascii?Q?Xn6SCt1e5KOmy6SGYyxFPdPwo8+hSh6YXKvjXzxe4VdIoVXUzeSRl7qGTre3?= =?us-ascii?Q?LOZHZzNMQUhVbLGIpJUb1a3PlWRFeYtWnGsmwZKSp7LKUkXLILr8QZXrItU7?= =?us-ascii?Q?lD1GTeyiqwBFM0FGAZoQOtOZn0Es4KF2PBEKy0yz9GiNwrFEraXe8svahWZQ?= =?us-ascii?Q?FEdRcFKlE+U2xL2UhdAZ/kf20FINV9Nm3BNT9rJNuNXSvrCdyl3fppdMy1AS?= =?us-ascii?Q?cBUhs3+d6m7FX9EG9sSdU/0bG8uQR/nxOqnku219wYm6Rg5EagA+IetfuJc7?= =?us-ascii?Q?XrUJBz1cWZMqKODMZ8Z1Xf4So4pF+umyEeCcf6RZTQmdv1K9xxANAn/4H9Sj?= =?us-ascii?Q?oRTRbKb75Kp/eCJpXjqk8w=3D?= X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2510; 6:qvhmistdUP4fosBUYFaP1VoOUamV4fuGWLScOkIBAVbDeN0f+cEc+nfVhkJbHm95TMM7GriMaFIw6N/ehJvkl9n5zW06mojiKcBfCMsllFR/ki+r9Y7onmGMraBG/PKvHA5zg8w51rOnEExdlEJiTT6A23xr7SYtxm7TfFDJHlfjjLBc7Q5lv1vr6e+BSasro5KHUkQ8feQi//zKJb2kcBxor+flHyROs3yyx6RM1r2JGz6yX4Qo60yXkj/ehl1tgGWlaFpAc3UKFhpnGCQbeOVTgo4ombj3ydZSRjRhagHUJAZ1quLvkfCOX8trIJOB6C0aoMCCImSpB8X/O2R1aXasFsBu6IyBAggxN5KSjO28uscfpHM6bzpCdTitkfBw4Ama8+3JHaNX6LEXmWqU8zqt1Irlr7tScXrud9lwdCc=; 5:9J1OQFdil/NvjIw90prUHmP8MgCCeOf6O43RbQjK+Gzm0J4J59Rw5MA+B8saIq2VRiiB9/0ghmrDqQuKvpGIWoRJ7IUEjHFXumpBhlhNqYNwoQabKpOVjYEcVMXZNgFzUHK3lKF5Z7W9Hy259NSeqg==; 24:rLGpL5IB420EWQ4cZ1a31P+MDZJ76RWuvJf4pev6Ew2kG2QtWjKXSiKJaxji8HS4s7WmCw+71kk5AV4cJapnkE2L+imqkgE8fwEx41pSghM= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2510; 7:G4j9Xw3vGnjl0Dz18HXpn3YkHrNRom72pcC1Yxlxl+nDT1VeOZ2toplsW2kQltWJdajAbNyoMi+ZID6ncebAsl7WNSKj6xdEe/OLJog8D4KeUOB02Z+VN915IKDp/QfEkdYL8v/QMTIQU52jET1jgfvZwVfyu0omhvqS64d82sXsEsXJHZVJqvKSYxUEKZ++tpn1AYS+qj4H7Ht9pil/eChrVIb8r1+VqhHocPMLyLo9Gv+1EjBwbWoUehlPc6wu+bglNhTCIPUGJcLD0TTrrwCzh61/W9vOV1MSGF/GyqRTJ/bVOZlU1yvt/WispjcWOUsbXOQKlS9nhRXyZQEC8w== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Mar 2017 17:51:58.2305 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR05MB2510 Archived-At: Subject: Re: [Idr] Early allocation for draft-ietf-idr-bgp-gr-notification X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 17:52:02 -0000 Hi Sue, On Mar 21, 2017, at 12:59 PM, Susan Hares wrote: > Will you revise the draft prior to early allocation call to remove = this code point?=20 I have the revised draft queued and ready to go as soon as submissions = reopen at 2017-03-26 23:59 CDT. The sole change is to remove the = offending "suggested value". Thanks, --John= From nobody Tue Mar 21 11:00:43 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09027129C58; Tue, 21 Mar 2017 11:00:41 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xq7E8riBEcZw; Tue, 21 Mar 2017 11:00:38 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0114.outbound.protection.outlook.com [23.103.200.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 403C6129C43; Tue, 21 Mar 2017 11:00:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=MtlZXKhMN2w6ttqnjcOR4pO7BvG72Tnzd7z/mUAwiB0=; b=d/VjByct7fNy3HPQRLOhbeaRpRHJIE9t7pfX97ajE6cOhG4pOjSavqOHUu9ijepaHi9xn+1XnEKkiPcGREicjJOT60OnuIfFZwcKq8ZGBcitzm2IYiWYiS8X+saU0NmQjOxphOGlX4pw+TYEoRimptGpdYDyNl88qdyNFKYZKtM= Received: from DM2PR09MB0446.namprd09.prod.outlook.com (10.161.252.145) by DM2PR09MB0445.namprd09.prod.outlook.com (10.161.252.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.977.11; Tue, 21 Mar 2017 18:00:36 +0000 Received: from DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) by DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) with mapi id 15.01.0977.019; Tue, 21 Mar 2017 18:00:36 +0000 From: "Sriram, Kotikalapudi (Fed)" To: "grow@ietf.org" , "idr@ietf.org" CC: "sidr wg list (sidr@ietf.org)" , "sidrops@ietf.org" , "draft-ietf-idr-route-leak-detection-mitigation.authors@ietf.org" Thread-Topic: operator inputs -- route leak solution Thread-Index: AdKia1LxrjWKYnevQ5+4FG+AD/ZO4w== Date: Tue, 21 Mar 2017 18:00:36 +0000 Message-ID: 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;ietf.org; dmarc=none action=none header.from=nist.gov; x-originating-ip: [129.6.110.145] x-microsoft-exchange-diagnostics: 1; DM2PR09MB0445; 7:xBQU71LM1+X3o0+Ty1/UwWlrOxncq+oJt+62mY5tIjRUmVCwGVQXIHZSBKkAqv27yEORlnSHP/t2qyis88m6fPo0AEOR51q3CpIH/HhBi6Qne7E21djlT8YEKgYZUlIt+mlN2YhFsLqzhyilxM88LemjTUvwMFpoLJiYbT8Oacg+9Ugs8PJzFksOesYoQsyO10C0G4A8oPkyRJr5bRgGsq0g9JDs2HvulqryB6sxTFuuE6YA9y7Zg8ORXhybY9Q6FeM9tCcNwO1WAjT0olpg28Zi48HvrsgLRnQMZRM1rrj09CCqaMzF7oW5yZomtbOs1GdDcccXwn28l5rrCbN3ZA== x-ms-office365-filtering-correlation-id: 7ba95e3f-b4b6-4025-082b-08d470842d66 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081); SRVR:DM2PR09MB0445; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(256337837700080); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(20161123562025)(20161123555025)(20161123558025)(20161123564025)(6072148); SRVR:DM2PR09MB0445; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0445; x-forefront-prvs: 02530BD3AA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39450400003)(39840400002)(39410400002)(39860400002)(305945005)(86362001)(3280700002)(7736002)(74316002)(3660700001)(6506006)(38730400002)(2906002)(2900100001)(54356999)(50986999)(66066001)(7696004)(33656002)(5660300001)(6436002)(55016002)(966004)(53936002)(9686003)(99286003)(54906002)(6306002)(77096006)(122556002)(8936002)(189998001)(8676002)(81166006)(3846002)(6116002)(2501003)(102836003)(4326008)(25786009)(450100002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0445; H:DM2PR09MB0446.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Mar 2017 18:00:36.3476 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0445 Archived-At: Subject: [Idr] operator inputs -- route leak solution X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 18:00:41 -0000 Inviting comments especially from GROW WG folk (network operators).=20 Please look at this and address the question posed at the end. Thank you. The most common form of route leak occurs when multi-homed=20 customer AS-C receives a route from its transit provider AS-A and leaks it to another transit provider AS-B. =20 [RFC 7908 https://tools.ietf.org/html/rfc7908 ] Customer AS-C is often the single point of failure. AS-A and AS-B may be doing intra-AS community tagging etc.=20 perfectly well to prevent route leaks, but AS-C does not and ends up leakin= g. The leaked route propagates via AS-B to the rest of Internet=20 due to prefer customer route policy. (Example: Google/Hathway/Airtel leak - https://bgpmon.net/what-caused-the-google-service-interruption/ =20 see many more examples in RFC 7908 ) A solution component for this has long been discussed in=20 SIDR/GROW/IDR and well documented in IDR (see Section 4)=20 ( https://tools.ietf.org/html/draft-ietf-idr-route-leak-detection-mitigatio= n-06 ).=20 The solution involves AS-A setting a field (in an optional transitive attri= bute) in BGP update to indicate that=20 (1) it is sending the route to a customer AS (or lateral peer), and=20 (2) the route SHOULD be considered a leak if subsequently received from a customer or a lateral peer. This is one component of the overall solution. It has been presented and discussed and I believe accepted in SIDR/IDR/GROW over the last few years (at least since 2014). Question:=20 >From an operator point of view, are you willing to place a piece of relationship info (as stated above) in the BGP update for the significant gain of a route leak solution that works well to detect/stop route leaks that do happen, and prevents single point of failures in incremental/partial deployment scenarios? Sriram=20 P.S. There is already immense BGP-derived public data out there on AS peeri= ng relations: http://as-rank.caida.org/?mode0=3Das-info&mode1=3Das-table&as=3D3356&data-s= elected-id=3D39=20 http://bgp.he.net/AS7018#_graph4=20 =20 =20 =20 From nobody Tue Mar 21 12:39:36 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1397E128990 for ; Tue, 21 Mar 2017 12:39:35 -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, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YF8__9_mAyIV for ; Tue, 21 Mar 2017 12:39:33 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 44FE5127286 for ; Tue, 21 Mar 2017 12:39:33 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 1ADBE1E33B; Tue, 21 Mar 2017 15:45:55 -0400 (EDT) Date: Tue, 21 Mar 2017 15:45:54 -0400 From: Jeffrey Haas To: idr@ietf.org Message-ID: <20170321194554.GA9648@pfrc.org> References: <4eedda5c2db74539bd0f949e38cb8b26@XCH-ALN-014.cisco.com> <20170320193502.GC26130@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170320193502.GC26130@pfrc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Idr] Early allocation for draft-ietf-idr-bgp-gr-notification X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 19:39:35 -0000 On Mon, Mar 20, 2017 at 03:35:02PM -0400, Jeffrey Haas wrote: > On Sat, Mar 18, 2017 at 01:49:52AM +0000, Jakob Heitz (jheitz) wrote: > > We are implementing > > https://tools.ietf.org/html/draft-ietf-idr-bgp-gr-notification-09 > > and would like IANA to allocate the code 9 for the Hard Reset subcode in the > > BGP Cease NOTIFICATION message subcodes registry. > > Further, Juniper has shipping code for this sub-code (9). > > I spent some time looking for my requests for early IANA allocation, and > appear to have missed this in my queue. Given my prior presentations on > such squatting, I shall accept a mea culpa on behalf of Juniper. The thread has prompting me to dig through the idr archives since I didn't find the appropriate thing in my work inbox (I have another one to check): https://mailarchive.ietf.org/arch/search/?q=subject%3Adraft-ietf-idr-bgp-gr-notification&f_list=idr See message posted 2014-04-28, subject "[Idr] Early allocation request for draft-ietf-idr-bgp-gr-notification-01" Similarly see request for WGLC on May 2014. -- Jeff From nobody Tue Mar 21 13:53:48 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F361D12EA81 for ; Tue, 21 Mar 2017 13:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JmS73BfwpgXy for ; Tue, 21 Mar 2017 13:53:45 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0097.outbound.protection.outlook.com [104.47.32.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7042112EE44 for ; Tue, 21 Mar 2017 13:53:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=E/D9i36Fft+te1BmhhQugQLONhT43vWWOu+WmVcLPSI=; b=j3O6ZBTRT6uh/B4wIHcj0FNUdjVW3CKGAduSZl+zNTsjrbVJayVe14vEHXuQa09QRR6/c8X3C/0oFRQy4tFKYi1+qG0q4WlDw2lSZMU7lyo8+3MG+qk/fAOAFjWltreA2QLC1x/C2olupIaDkwaGeYYA+RWVJrZLeToffk4spUw= Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=juniper.net; Received: from [172.29.33.229] (66.129.241.13) by BY2PR05MB2184.namprd05.prod.outlook.com (10.166.112.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.4; Tue, 21 Mar 2017 20:53:41 +0000 To: Susan Hares , References: <048701d29cd9$15204b80$3f60e280$@olddog.co.uk> <022201d29ce6$ffb2ba40$ff182ec0$@ndzh.com> <02dc01d2a25b$a1eca590$e5c5f0b0$@ndzh.com> CC: From: Eric C Rosen Message-ID: <3b9c229a-4573-c586-8627-3a8c38539ff8@juniper.net> Date: Tue, 21 Mar 2017 16:53:35 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <02dc01d2a25b$a1eca590$e5c5f0b0$@ndzh.com> Content-Type: multipart/alternative; boundary="------------EBAA8F4E2672D9D7D1E5306A" X-Originating-IP: [66.129.241.13] X-ClientProxiedBy: BN6PR20CA0019.namprd20.prod.outlook.com (10.173.158.157) To BY2PR05MB2184.namprd05.prod.outlook.com (10.166.112.12) X-MS-Office365-Filtering-Correlation-Id: 29992cc6-140a-4f96-6cd7-08d4709c5ba1 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BY2PR05MB2184; X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB2184; 3:Rzewdfm5ZAPCPEmA9T9ra4vF7xUM8UUr8p1wzDgxT06dRJHxDkTIXO8SryAdSSZ7PcFnsi7KHypGrDypHJmSp5ue2HYSyJrkN2uDi/+bR1Ikx7FNsSgmZNEu1ghe8FQHc2ho3Rs27NG1LGciX2a+C6N+EIYbQlb9epTjWgFmgFci4CU2GlTiIbnbsnFQW3vmIfCC/iAMp7wyddU0j82ZC8WeEjZLRUe3guhQU+tXQy6qQIZjL/So0+ah69sLAyNaICDKgEIab25dVGVPpC6f1T1Dj/ig6m0x5ASywkPkzcU=; 25:E4JEr9o9MLVefiSPblaOnYSmkkN/PX54KI+3Ndgpq5lDQSVivNNrLLuILcHYNlSRXgrKvxnUNN4nPn9ulEASzHddz2SCOPg1Yx1uZMto9DF4X19/vgrVdkSRyLwOWjo/tnRgD2skj4KOZH5xVeeNqFyI/51PIYhBB5J3uw0yv8ps4W/aQSh4tiJJeuZR8tokDKqKtkbUoot+HmFQcSRkAXD+bVCx/K1+PgR2AtTvQZyYcMQrT5Og34eTkod0bVZCAXU1Y4ualDgcSpwfIaWzQQ7Vq6ndq4sF3j74BQJhkTQG95FocruL5dM/62i4JQUx2CFIPXXm67q/U9yTf98kv76q9n9I92SRbYAN37+KtP0rCGNBRMbJG+ix23bEd9RiFGI5ClR44aEB6DJOxEboZii0KvtO0Rsg+L3zAU8YQTwGFD95/Ykf4P1X29T8KKxfb9nWEoeM8y9+lbbtjOZ7YA== X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB2184; 31:wKo92h5X3mUd/+C7yk+CJKsjOm0pKfUNobXR5ycU2srG9YGAx469DY/FXqAED7SE+MYC+wvXMCj/qF3vsKabTg69yi5fFGsce6kH+Fp6aW4QZ62IV5LZM6cwrn7bJAMwsGogxq6hEZ8t1VEfL17AQt4vV6HRmuC1alFkNRaOnXMH0lHjfvYOew0LH7OrtoCUsJc/KJUorvPnjd/3Di2/wmZkZg1c4oZhtmL0jqMCkIg=; 20:thUCaNxOZgHvJyKE+vk0hTxbTGaf7eN3XdC3tD8Hl/R3Il2WKm4eoroNh5oxVm32ZQYEuefKNvGYgUo6OjUeH7uhfLkKRGpGtWrhPlIeKgt6gswa/RzUrnYbFolhXpKzVBr8qdnUv5OxUwXJgLu5y7otipVZEisvJjWMXn91xev5aVEkZhN6E/6dRPt4VaxcPBQDZHzoqYIT4U8lwqJzrj1GJWuEdnctD8ZcP1CQa4ltUqU30cxaHUXM7Efxxpgr6lk4z/cb7F0LQvP8JHP0g1qCuEdBhiapAUSHxyVf5n/P4lx3TL91AKNHRAn/xPEAzs2RX0SHzfYvsOOK2h0ZFtdzD7UVrqYLmj0wuO23y2F0ykjqt8OL8HqxoYCPM1OTRJeC0PRyrnb+c3OsEblcGPSet7u6qaPsPvttdSCnZK6t7ykEdhoDDPP2CKJJvRJBs4mTC+9g7vNYkvRvmyMtyEAU1sld6MwtoPm8OIDccgmSibeRX6iig0mdCFO5L8yF8fm9pI8QdvMyQtWuAtbWhvyYMRCKppaD/agG1KEAcQ9pITonXdY3V9MM9sjIzQFRp+45CDQUs1wAK2U8/w0h9g1wx8UyR3m8jIzlsaDPiQc= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(788757137089); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123564025)(20161123558025)(20161123562025)(20161123555025)(20161123560025)(6072148); SRVR:BY2PR05MB2184; BCL:0; PCL:0; RULEID:; SRVR:BY2PR05MB2184; X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB2184; 4:zr3Cs18yzYeP7v++nPJKsiDnrXzKeSXksAt8LYgW+kPV/soit5wfB64aVBvdc811WH7Ht+V11Rhd5bl4fGP+PzzHblMgclLaMDaODZ6P+c561nasgPENHxqBnY22HEUuTb7aU20KS9VUgpLlx/KA0H4YiFSYqwbDiS8HSjOZcaJZX6DAUUmN0nokLXo6X9IhBI3ub6BlB3HMxijYOGKDBURA+oeZQ0zqOKDIzO9riNdNPNMFVbhxos4y+GlaI2Zhq+A0O5SOnH6zdxQXBy9Yf/FebrxVogVMhLJc3qLQaTfvgD3czjFJMlt2dqDd/bKoGxIW9bu5gAPuGOIQ52o4YwTrqlG76QQcL00bztSXxEDCIvs538bNV7V+zWk5t+J0Er8N7DYi8EP44OIT9dOn34lFPTtyE2romsj/ERMVKu0GvHmhFCkVpSR6yx5L3WEuz7JftqMD+0eDZyy0VQhUrSpErfMB9Rf0tj9/npnjvwvUBRujIFGkFa1mQI2wFUUV7+Q11FSb65W+epGxRrvH9ecEbIcU8OxYzNI9Yxwu1CLXeWT90cz4Cieu2Flg8G3dZqAJ28uwOk8wjNi1Qr/Awi+M1GTCT+1JCa1EXCvO8ntw6d4jueQYYgpYo7lVKDJsXe1Yg9eaoLvFmcPHsVPbdd30TReDjtft3ntc6jP/zqM= X-Forefront-PRVS: 02530BD3AA X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(39410400002)(39850400002)(39450400003)(39860400002)(39840400002)(24454002)(377454003)(93886004)(189998001)(83506001)(230783001)(42186005)(77096006)(229853002)(54896002)(6486002)(5660300001)(31696002)(65956001)(25786009)(66066001)(90366009)(86362001)(84326002)(31686004)(6666003)(2950100002)(50986999)(76176999)(54356999)(53936002)(4001350100001)(33646002)(2906002)(8676002)(81166006)(6116002)(3846002)(38730400002)(790700001)(64126003)(36756003)(270700001)(4326008)(53546009)(7736002)(163123001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR05MB2184; H:[172.29.33.229]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY2PR05MB2184; 23:Q4oGqB1LTrst6VBe4yx2pTYrpf14HhH3XxvWQo9qV?= =?us-ascii?Q?Ql1j0T/s7HJsWiRr1EcFzRmMVEEuXJVKj15lv5hYSJXSOn43o7lNdHIGPxn0?= =?us-ascii?Q?ML9VLD4xE2GDgw6CQUTd6sZNz4+kLmXqf45BMpENT5bQtb2V8ES2W9vpRv2H?= =?us-ascii?Q?JvVvRmCo+eoeniEjFS0NSVdti7p+T6Pxjie2yTN5Z68Q0Bn4xTcWtjakt6MP?= =?us-ascii?Q?ZIY+pbN45Z2kBatwFhhUcHjhezYH0a8Zr8Od2TXq9y1bI2O3nxrbRJPhx8Oq?= =?us-ascii?Q?Y7c/Pyms0VKQT1jmJfqjM8+U+A3YrNxZtlTFkROJA2/jWQ5yIO+BOs425ClD?= =?us-ascii?Q?hQzlS3SuPlvQQ7NrtULfiNDkUI+Qk7O03qRHH9Hf269g+CjJz9SSsw6rZJSs?= =?us-ascii?Q?ab4WCir/0tT7y6/MTjZ83BUZtOzPuqc2QSAW/rHwjyNszqQNFIrsycC7HZIg?= =?us-ascii?Q?LQ6et/Mez51H1XaqvQAqiDq75MPgioHnZQbi8O2dcQUI3kXQATmKFdZRkNy1?= =?us-ascii?Q?w3w8iBRfQypirzS1/ZpfGiBJ3Lw3sHkokLUfpv+XRfUefULlmKsRga0jHu9k?= =?us-ascii?Q?VNnmlj3kM8pdUPZHnPdjRc3TXd+0D9NHYjvw+T2eXQtnh4UvTfOsTGY6Pdlt?= =?us-ascii?Q?63jnxW4ECD51fjiA6jDurSXidJZ1fpjemUYTGPNDDYFkCFDZJ57/c6b5skTW?= =?us-ascii?Q?Y4splYDBVXz3NzB7dE0MLPzSidVUy6219MGPXOlEWKlmqc58ab3qbQ2o+D4s?= =?us-ascii?Q?5jYzLemxJPKnl5oSExX4xC/cU4oDkGRYLUMZgpQoV5mARC91zKlG48tpXEan?= =?us-ascii?Q?aKeO5SWAQha9xKFTS7P+CDlDCkn1Jl6QkVlW5tPF9ZqQLiCqzYpwi3SDae4q?= =?us-ascii?Q?fZGwpWoQZ+nBh613fGJt3xFdnFuUsSR/kerxrQV6VHgRf+6QTOWijrxSXYCb?= =?us-ascii?Q?mib6jtGSEtEVvuwNQpQyEHpyI4Ii1ZuN7NMscDJ3khmP1yTlhVizOmmsFUIX?= =?us-ascii?Q?O/TH8kki75BQLFg2psUWyafgcIXqK78XIyuLmoj+G2fJ4maRVVPma0RCYxUI?= =?us-ascii?Q?hNiDKHH+4Zti1ecJM4VplyWBc5EA8fLK2h97B2xiDg1bdjGZTnFAQrult6xy?= =?us-ascii?Q?XPt3yM4drRGR5sI9YmJTZwa3guF2DYwvbyQH6zprU/zjGieEBQbUe9+3bHTA?= =?us-ascii?Q?OY7p1oplSeKli865yjpK3rIB8s9J0fRg/LsQn+sLgwoSDxJep12MwCWCG4iV?= =?us-ascii?Q?MqbIhjd60goIRvfTIo=3D?= X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB2184; 6:tJxw+NPP0SgqFONcXOH8DMvvB3ceNn2cdnZy82nLVr5FRXPwRd8ap9eDRgrqF/QdsgbMSNEG9mX10IP/Ftx9v/tlCMiKv08Y37iPGTkk6CuwppICgbB4eHHyQRtHj0CC6xKhLy797whJhmOH7V1x7bgU0m5DEp7w2USI9hTGxONd/eRtqIi8MWrE1yW+LF/QxafnKZ8IlK8fN78oV8lDee15gNx+AvCS9hyw/KqP0rqCUoTbQYeHSEbc3DAxQ5Jxriqxuh0/FM3SAOuL+e6VmtRW1WDDkH24fZuAqoxMVmglQgZ3v5Qq/Ut+CRNc0AyUUuSYrsR2foM8Ye2uoDF1XxaK/8HVxnomOS3Pl8kU38KCv11dM/cUx3s5/BrmDirMSFKFjQCdB4HEpOtTSNlKU8SCbrdc8J3re+fNec80Ivs=; 5:MLWmFlOxALYPbcdcobp+coqTtLyC0E6H29oBTqvtAC4UMsEKqT9/4v/Mt+HRm35NUETWUcCRmbAY5SkCKjAiIhSUSym/ky2KRVaEM6/Eesum8b7bSbAeqRpnpcPluOETggm85DSnVEFwFxlxUaO09A==; 24:s/G7Td403ilxRp7miyochY5nDmCGpsI9cU0h4gfhUGt1yz6Rp+J7rnQP6iMqJPIjiRZo45T1E5kqag3tQCy06BZTi0d4uxdo9JewYU06jMg= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB2184; 7:mKWK3R9RsiElqTV0LwXe2o61fYJGPZiHtPBKAD4qxkKvsl+f4NXP+Ftu1ueNwsO6OuvhNfhROrdi0soGXZnQjE/WDE9NNZ4kNe3QnEXci//cIOqmL230yMaL0unzWGLdmvYKe7F91xFEIBiHbAjgBgRch1fUMWTgwsAcawoF2ySzEDZqmaBNiWt/tlw2/gCYbfoPYKJqAV5YyJQKXH1Up80uKQwM1oc6yGWyNVGRo4cfKvtrZUGXFJDdkA1W30H6ZjQXK9ELVB2eCx+3jtw0n6YD6HNfB5LbmwpHbQnNYlMEjajuoaAZuaUbUbDTFoyfm2X3fGMGUNqqi6c/M/xfjg== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Mar 2017 20:53:41.3952 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB2184 Archived-At: Subject: Re: [Idr] Thoughts on https://www.ietf.org/id/draft-hares-idr-bgp-registries-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 20:53:47 -0000 --------------EBAA8F4E2672D9D7D1E5306A Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit On 3/21/2017 11:55 AM, Susan Hares wrote: > > Eric: > > *Politics:* I do not know how this introduces politics - since it is > just the WG chairs. The WG chairs for BGP related groups are very > collaborative. > And they would never dream of trying to manipulate the process in order to slow down the work of a competitor! Absolutely unheard of. A committee with no politics? That would be a first. > If they are not collaborative, the ADs can work with or replace the WG > chairs. > Oh, no politics there either ;-) And we know how quickly things happen when the ADs have to "work with or replace" the chairs. > *How does it speed up things?* It provides 8 designated experts which > means IANA does not have to chase down a few people (2-3). > Currently, with no designated experts, IANA does not have to chase down anyone. Requiring additional approvals can only slow things down, not speed them up. > This is the most often reason for IANA slow-downs (AFAIK). The > collaborative chairs can decide on a rotation for a designated person > to check up with other chairs. > Egad, more process. > > Have I responded to all your concerns? > Not at all. --------------EBAA8F4E2672D9D7D1E5306A Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit On 3/21/2017 11:55 AM, Susan Hares wrote:

Eric:

 

Politics: I do not know how this introduces politics - since it is just the WG chairs. The WG chairs for BGP related groups are very collaborative. 


And they would never dream of trying to manipulate the process in order to slow down the work of a competitor!  Absolutely unheard of.

A committee with no politics?  That would be a first.

If they are not collaborative, the ADs can work with or replace the WG chairs.  


Oh, no politics there either ;-) And we know how quickly things happen when the ADs have to "work with or replace" the chairs.

 

How does it speed up things?  It provides 8 designated experts which means IANA does not have to chase down a few people (2-3).  


Currently, with no designated experts, IANA does not have to chase down anyone.  Requiring additional approvals can only slow things down, not speed them up.

This is the most often reason for IANA slow-downs (AFAIK).  The collaborative chairs can decide on a rotation for a designated person to check up with other chairs. 


Egad, more process.


Have I responded to all your concerns? 

 


Not at all.

--------------EBAA8F4E2672D9D7D1E5306A-- From nobody Tue Mar 21 13:55:24 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59CE012EE8D for ; Tue, 21 Mar 2017 13:55: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, RP_MATCHES_RCVD=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7IJ9sor5qnf7 for ; Tue, 21 Mar 2017 13:55:16 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (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 EE72312ECF5 for ; Tue, 21 Mar 2017 13:55:15 -0700 (PDT) X-Original-To: idr@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 23A84619D3 for ; Tue, 21 Mar 2017 21:55:14 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id D0D3D606E8; Tue, 21 Mar 2017 21:55:13 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id C21C96B17D; Tue, 21 Mar 2017 21:55:13 +0100 (CET) Date: Tue, 21 Mar 2017 21:55:13 +0100 From: Gert Doering To: "Sriram, Kotikalapudi (Fed)" Cc: "grow@ietf.org" , "idr@ietf.org" , "sidrops@ietf.org" , "draft-ietf-idr-route-leak-detection-mitigation.authors@ietf.org" , "sidr wg list (sidr@ietf.org)" Message-ID: <20170321205513.GA2367@Space.Net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: Re: [Idr] operator inputs -- route leak solution X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 20:55:18 -0000 Hi, On Tue, Mar 21, 2017 at 06:00:36PM +0000, Sriram, Kotikalapudi (Fed) wrote: > >>From an operator point of view, > are you willing to place a piece of relationship info (as stated above) > in the BGP update for the significant gain of a route leak solution > that works well to detect/stop route leaks that do happen, > and prevents single point of failures in incremental/partial > deployment scenarios? I'm not sure it will do any good. Those ISPs that care about the garbage their customers try to inject already do prefix/as-path filtering. Those ISPs that do not care today will not add bother to add a filter on this well-known community value (... and most likely, the customer router sending out unfiltered garbage won't have "send-community" enabled either). Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Tue Mar 21 15:19:47 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0121293E4; Tue, 21 Mar 2017 15:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yop8UWtzmMYZ; Tue, 21 Mar 2017 15:19:43 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::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 A0E561299D6; Tue, 21 Mar 2017 15:19:43 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id b140so57059674iof.1; Tue, 21 Mar 2017 15:19:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qsY+bWNf4uVp4x+J0c2SJTRhOlzE4eRrYm0v2JAQb9g=; b=WSsVexnRwM6tmHe16Ea4zuR6nKfRzYrtIWdztwRtFSYinnCQkiiHgZ0ZWkVNcKdVY/ s+/zCHz1kjfmCQr0e9fZ8ItumA2s+FGeF6myOKzTis/uZiTmIOcqj5qKFwOL+6jG48IB AchG8r9wT0SIOkLCVCG/sg4jEJAnPkVQyBgqwAeFH1sHQ13I9whZpNTiX24f7WW43mNB wNuBrQ4eT9yOa+jPC5gR3m4T7WyhPRb8oipfLACKl7i5rWD9bG/twvcqFvtOWXr4AF8q 4FGBCSzq89v6ii7mHikRKYzo86RXRuaY9s0LrpZKRxBaHX2h5ncbzStJmIYhAKQOmKU4 Kg6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qsY+bWNf4uVp4x+J0c2SJTRhOlzE4eRrYm0v2JAQb9g=; b=RQtP8FZ0VUYanPXF0akXdX7cvNcCa1riN86eDNsU0ud2SShc+/9AEnOSmVpHInGGK2 Bn+rHGyeVJiPTL/PvRIi2J14RIRJ5YLJ4cZSdUbpznuqo3GqcZWqyICo1CmgeLRdBL6r B7rqSU1lWCP/nZu2+5FbcehJ0CPPza83SxwIm3pcDVPPR2glKW3Dkh14oGAocVYXybti xs6lo+gOUEVKz1KCF1y7i/tFaV5ayGz8hFKYYUhoFO3GE2nd89pN+P0g2DhSeEkjHfNp Y4vW0zer+ETx//jj+AupHwEA5fiBvTwWi/QcEAqVXQAnJiBUotgAq5llN8ynqVHnremX 1vkg== X-Gm-Message-State: AFeK/H2y8fy8wQgmMhfoLSTc20qd6oqwQhRbqAslaPRUHO2K1hOlt9lPBrephBjB/shOT0ER3O8VLmXu/nfn1Q== X-Received: by 10.107.157.146 with SMTP id g140mr32456766ioe.63.1490134783056; Tue, 21 Mar 2017 15:19:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.121.77 with HTTP; Tue, 21 Mar 2017 15:19:42 -0700 (PDT) In-Reply-To: <20170321205513.GA2367@Space.Net> References: <20170321205513.GA2367@Space.Net> From: Brian Dickson Date: Tue, 21 Mar 2017 15:19:42 -0700 Message-ID: To: Gert Doering Cc: "Sriram, Kotikalapudi (Fed)" , "grow@ietf.org" , "idr@ietf.org" , "sidrops@ietf.org" , "draft-ietf-idr-route-leak-detection-mitigation.authors@ietf.org" , "sidr wg list (sidr@ietf.org)" Content-Type: multipart/alternative; boundary=001a11409824696c41054b450a11 Archived-At: Subject: Re: [Idr] operator inputs -- route leak solution X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 22:19:45 -0000 --001a11409824696c41054b450a11 Content-Type: text/plain; charset=UTF-8 Pre-emptive top-post in case anyone mistakes the technique proposed: This will NOT be implemented via communities. The proposal is for a NEW optional transitive attribute. If any operators can answer the original question, this will be very helpful. Thank you in advance to any and all operators. Reminder on optional+transitive logic - If the attribute is not understood/implemented/enabled, the attribute is passed unmodified. - If it is understood & implemented & enabled, behavior is subject to the applicable standards. - Thus, optional transitives are "opt-in", by definition. The proposal itself is an IDR WG I-D, and as such not finalized; input here is definitely helpful in reaching consensus, understanding requirements, etc. Brian On Tue, Mar 21, 2017 at 1:55 PM, Gert Doering wrote: > Hi, > > On Tue, Mar 21, 2017 at 06:00:36PM +0000, Sriram, Kotikalapudi (Fed) wrote: > > >>From an operator point of view, > > are you willing to place a piece of relationship info (as stated above) > > in the BGP update for the significant gain of a route leak solution > > that works well to detect/stop route leaks that do happen, > > and prevents single point of failures in incremental/partial > > deployment scenarios? > > I'm not sure it will do any good. > > Those ISPs that care about the garbage their customers try to inject > already do prefix/as-path filtering. > > Those ISPs that do not care today will not add bother to add a filter on > this well-known community value (... and most likely, the customer > router sending out unfiltered garbage won't have "send-community" > enabled either). > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > --001a11409824696c41054b450a11 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Pre-emptive top-post in case anyone mistakes the technique= proposed: This will NOT be implemented via communities.

The proposal is for a NEW optional transitive attribute.
If any operators can answer the original question, this will b= e very helpful. Thank you in advance to any and all operators.=C2=A0
<= div>
Reminder on optional+transitive logic=C2=A0
- = If the attribute is not understood/implemented/enabled, the attribute is pa= ssed unmodified.=C2=A0
- If it is understood & implemented &a= mp; enabled, behavior is subject to the applicable standards.
- T= hus, optional transitives are "opt-in", by definition.
=
The proposal itself is an IDR WG I-D, and as such not finali= zed; input here is definitely helpful in reaching consensus, understanding = requirements, etc.

Brian

On Tue, Mar 21, 2017 at 1:55 PM,= Gert Doering <gert@space.net> wrote:
Hi,

On Tue, Mar 21, 2017 at 06:00:36PM +0000, Sriram, Kotikalapudi (Fed) wrote:=
> >>From an operator point of view,
> are you willing to place a piece of relationship info (as stated above= )
> in the BGP update for the significant gain of a route leak solution > that works well to detect/stop route leaks that do happen,
> and prevents single point of failures in incremental/partial
> deployment scenarios?

I'm not sure it will do any good.

Those ISPs that care about the garbage their customers try to inject
already do prefix/as-path filtering.

Those ISPs that do not care today will not add bother to add a filter on this well-known community value (... and most likely, the customer
router sending out unfiltered garbage won't have "send-community&q= uot;
enabled either).

Gert Doering
=C2=A0 =C2=A0 =C2=A0 =C2=A0 -- NetMaster
--
have you enabled IPv6 on something today...?

SpaceNet AG=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Aufsichtsratsvo= rs.: A. Grundner-Culemann
D-80807 Muenchen=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0HRB: 136055 (AG Muenchen)
Tel: = +49 (0)89/32356-444=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0USt-IdNr.: = DE813185279

--001a11409824696c41054b450a11-- From nobody Tue Mar 21 15:27:13 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50823129ADA for ; Tue, 21 Mar 2017 15:27:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IaHTiQwacrcS for ; Tue, 21 Mar 2017 15:27:09 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43F641293E4 for ; Tue, 21 Mar 2017 15:27:09 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id n11so22914087wma.0 for ; Tue, 21 Mar 2017 15:27:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nzbzzV75MsrjjhcK4IvJRl4ck24wZmOJM6+sjq5lZYE=; b=kZm4n93iw/Hm7da868qQsKnS39IyhWHZwNL/l9KUSBYOdk4ik+n0j+OqurArdQeJzN tP0QF9gutzdjo04BfC95AIGi0GSM806NZhe9C66eN6jqaCUULzuSyon8xj2TeVtShSfw 3wzXtqbMjlxjmeA4/Sydo35P9mHul8GdiEX4MdyeO/3Fpw0HaBRlB/Bxep73FTmnrGHP x5w+X1kfTFF8TAGRhsICjqsNiYj3yVho1Vye7KC00k+SrFZfO2+1zI9mTafamrrvzO1z OClwVSDhcpsMJMxzIlZp/cnyXCGYuyKp5IXNYrmhJ9dtd8Utyn5IQL8L50dRYmig7Z47 onIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nzbzzV75MsrjjhcK4IvJRl4ck24wZmOJM6+sjq5lZYE=; b=tfCKd7mfOX/nUZecsUtmDEq3VAbgq3BNAKwmovSdvm2chmYp0Zhsurb4sxp55kIihu HyiMh3fIPNFV7nOIXrBvg4deraxuFlJHZb/GGvMtd6+UPOwCRAAfPU+jsq0gPGaoi/cv IBrs43ggwHCK0g7Oo0Luc/Yq5h6OPcSaE078za8RR2/vtHp9pfyU3HNuFoo7W3H8lTe/ Qqy7OIlON+GoyyOObRr9v7IrDUapmDXbSvH0Wc9byWO+01IQl1fIVRvJMcChYOM/Cf58 T1YHqazvM4fWE7gSP6Xu7zXdpHZ6WX1cLBtGZuvEC9PzLrr1B4+923Lx51f6hKFudfll S9Fw== X-Gm-Message-State: AFeK/H1zhfuDQZlSo7FdmL8lOXVv+dLslcBzAl3Xx1m9G2EX+ByM+4RtWXWYOw7ejl9QUN8j1LDQCuYB1AmAqw== X-Received: by 10.28.28.69 with SMTP id c66mr5070927wmc.28.1490135227840; Tue, 21 Mar 2017 15:27:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.169.132 with HTTP; Tue, 21 Mar 2017 15:26:27 -0700 (PDT) In-Reply-To: References: <048701d29cd9$15204b80$3f60e280$@olddog.co.uk> <022201d29ce6$ffb2ba40$ff182ec0$@ndzh.com> From: Tony Przygienda Date: Tue, 21 Mar 2017 15:26:27 -0700 Message-ID: To: Eric C Rosen Cc: Susan Hares , Adrian Farrel , idr wg Content-Type: multipart/alternative; boundary=001a1144fba4ec3f76054b4524dd Archived-At: Subject: Re: [Idr] Thoughts on https://www.ietf.org/id/draft-hares-idr-bgp-registries-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 22:27:11 -0000 --001a1144fba4ec3f76054b4524dd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 On Tue, Mar 14, 2017 at 12:38 PM, Eric C Rosen wrote: > I don't think we need any more procedural hurdles that will slow down the > allocation process or that will introduce more politics into it. > > The draft does not seem to be a solution to any problem, it just adds > process and politics. It claims to have the goal of "increasing the pace > of early allocation", and proposes to do this by requiring allocations to > be approved by a committee of WG chairs or other designated "experts". I= t > neglects to say how having more committees will increase the pace. > > No doubt the designated experts will make their decisions "soon", as that > term is defined in draft-farrel-soon. > > Adoption of this draft will result in more squatting rather than less. > > Furthermore, a number of the mentioned registries were not established by > the IDR WG, and I don't see that the IDR WG has any standing to request > changes in the registration policies of those registries. > > > > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --=20 *We=E2=80=99ve heard that a million monkeys at a million keyboards could pr= oduce the complete works of Shakespeare; now, thanks to the Internet, we know that is not true.* =E2=80=94Robert Wilensky --001a1144fba4ec3f76054b4524dd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1=C2=A0

On Tue, Mar 14, 2017 at 12:38 PM, Eric C Rosen <erosen@juni= per.net> wrote:
I don't= think we need any more procedural hurdles that will slow down the allocati= on process or that will introduce more politics into it.

The draft does not seem to be a solution to any problem, it just adds proce= ss and politics.=C2=A0 It claims to have the goal of "increasing the p= ace of early allocation", and proposes to do this by requiring allocat= ions to be approved by a committee of WG chairs or other designated "e= xperts".=C2=A0 It neglects to say how having more committees will incr= ease the pace.

No doubt the designated experts will make their decisions "soon",= as that term is defined in draft-farrel-soon.

Adoption of this draft will result in more squatting rather than less.

Furthermore, a number of the mentioned registries were not established by t= he IDR WG, and I don't see that the IDR WG has any standing to request = changes in the registration policies of those registries.






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



--
=
We=E2=80=99ve heard that a million monkeys at a million ke= yboards could produce the complete works of Shakespeare; now, thanks to the= Internet, we know that is not true.
=E2=80=94Robert Wilensky
--001a1144fba4ec3f76054b4524dd-- From nobody Tue Mar 21 16:36:51 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 610D7129409; Tue, 21 Mar 2017 16:36:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.911 X-Spam-Level: X-Spam-Status: No, score=-2.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=domino.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RSBjPzlRqKkM; Tue, 21 Mar 2017 16:36:46 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0130.outbound.protection.outlook.com [104.47.1.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8AF2129496; Tue, 21 Mar 2017 16:36:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=domino.onmicrosoft.com; s=selector1-domino-org; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=RZf1ujktFS/b52i+UMplQhDgJTkeScooLEH3ctIlZlI=; b=T8l0RW3yRd0VEhqlxuBcjo8NAKUC9pqwmPqcDVO0cOPSlEVdsC/LMWsAHeyXs2P8KBDT73KUslDt/19y3wL1lFIeQKSUlCE9jh4DcIGRGEuKX/nP8dhchwXH05Cz57iGd7wknJTyzy5eYippOJ9Au1gE67qUG3UDIAQWNeYGiS0= Received: from AM4PR03MB1425.eurprd03.prod.outlook.com (10.164.77.155) by AM4PR03MB1427.eurprd03.prod.outlook.com (10.164.77.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.977.11; Tue, 21 Mar 2017 23:36:40 +0000 Received: from AM4PR03MB1425.eurprd03.prod.outlook.com ([10.164.77.155]) by AM4PR03MB1425.eurprd03.prod.outlook.com ([10.164.77.155]) with mapi id 15.01.0977.020; Tue, 21 Mar 2017 23:36:40 +0000 From: "Neil J. McRae" To: "Sriram, Kotikalapudi (Fed)" CC: "grow@ietf.org" , "idr@ietf.org" , "sidrops@ietf.org" , "draft-ietf-idr-route-leak-detection-mitigation.authors@ietf.org" , "sidr wg list (sidr@ietf.org)" Thread-Topic: [Idr] operator inputs -- route leak solution Thread-Index: AdKia1LxrjWKYnevQ5+4FG+AD/ZO4wAMKpth Date: Tue, 21 Mar 2017 23:36:40 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: nist.gov; dkim=none (message not signed) header.d=none;nist.gov; dmarc=none action=none header.from=domino.org; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [107.77.224.155] x-microsoft-exchange-diagnostics: 1; AM4PR03MB1427; 7:tyTnIuVIwh5JEFjo2h+aFF46ANIfZr8wkDh54mlgbmQzX83VfBID0oPU6MXT50MY5CDxN03uB1HWVd9dIr/BvLQwRCPi6zJvm/Ph9L2qR5gxZTqlOXG7JpsCiZBvG/CDEwTwK9aI0kNCFLyvL3o/moi3rA4E4F4jHwQ0G/66y4LPL+q7BFS+J5eLvct3yn67cE8QaJzosn8HFnku86oTzHYO1dRfcJarXv4vFlstwRsd/58ectVZnePEHqX7/p+Rcxaf6mh/PgrlDLQkcMwmnkwOcbu7lh4wTAsUJpFfS1w79mBVf01sEiQUt8unpU+IdoIk0dcsJ2r64gjng7LQCA== x-ms-office365-filtering-correlation-id: 07f08d1c-a623-471e-07f0-08d470b3201b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075); SRVR:AM4PR03MB1427; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637)(256337837700080); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123555025)(20161123558025)(20161123560025)(20161123564025)(20161123562025)(2016111802025)(6072148)(6043046); SRVR:AM4PR03MB1427; BCL:0; PCL:0; RULEID:; SRVR:AM4PR03MB1427; x-forefront-prvs: 02530BD3AA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39450400003)(24454002)(966004)(2906002)(99286003)(5660300001)(8676002)(82746002)(83716003)(50986999)(53936002)(102836003)(122556002)(25786009)(2900100001)(54906002)(6116002)(229853002)(6512007)(86362001)(38730400002)(6246003)(6306002)(66066001)(3846002)(81166006)(110136004)(4326008)(77096006)(6436002)(6916009)(6506006)(3660700001)(189998001)(7736002)(33656002)(54356999)(3280700002)(2950100002)(76176999)(36756003)(305945005)(53546009)(6486002)(8936002)(8656002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR03MB1427; H:AM4PR03MB1425.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: domino.org X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Mar 2017 23:36:40.3569 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 398f3eb4-3394-48e7-885c-de1ab2a9cf2e X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR03MB1427 Archived-At: Subject: Re: [Idr] operator inputs -- route leak solution X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 23:36:49 -0000 It seems a reasonable approach as long as it's kept as simple as described = here. Regards, Neil. > On 21 Mar 2017, at 18:00, Sriram, Kotikalapudi (Fed) wrote: >=20 > Inviting comments especially from GROW WG folk (network operators).=20 > Please look at this and address the question posed at the end. Thank you. >=20 > The most common form of route leak occurs when multi-homed=20 > customer AS-C receives a route from its transit provider AS-A > and leaks it to another transit provider AS-B. =20 > [RFC 7908 https://tools.ietf.org/html/rfc7908 ] >=20 > Customer AS-C is often the single point of failure. > AS-A and AS-B may be doing intra-AS community tagging etc.=20 > perfectly well to prevent route leaks, but AS-C does not and ends up leak= ing. > The leaked route propagates via AS-B to the rest of Internet=20 > due to prefer customer route policy. > (Example: Google/Hathway/Airtel leak - > https://bgpmon.net/what-caused-the-google-service-interruption/ =20 > see many more examples in RFC 7908 ) >=20 > A solution component for this has long been discussed in=20 > SIDR/GROW/IDR and well documented in IDR (see Section 4)=20 > ( https://tools.ietf.org/html/draft-ietf-idr-route-leak-detection-mitigat= ion-06 ).=20 > The solution involves AS-A setting a field (in an optional transitive att= ribute) > in BGP update to indicate that=20 > (1) it is sending the route to a customer AS (or lateral peer), and=20 > (2) the route SHOULD be considered a leak if subsequently received > from a customer or a lateral peer. > This is one component of the overall solution. > It has been presented and discussed and I believe accepted > in SIDR/IDR/GROW over the last few years (at least since 2014). >=20 > Question:=20 >> From an operator point of view, > are you willing to place a piece of relationship info (as stated above) > in the BGP update for the significant gain of a route leak solution > that works well to detect/stop route leaks that do happen, > and prevents single point of failures in incremental/partial > deployment scenarios? >=20 > Sriram=20 >=20 > P.S. There is already immense BGP-derived public data out there on AS pee= ring relations: >=20 > http://as-rank.caida.org/?mode0=3Das-info&mode1=3Das-table&as=3D3356&data= -selected-id=3D39=20 >=20 > http://bgp.he.net/AS7018#_graph4 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Wed Mar 22 08:07:46 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46EA2131758 for ; Wed, 22 Mar 2017 07:36:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.023 X-Spam-Level: X-Spam-Status: No, score=-14.023 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LFwaLKdYj4kv for ; Wed, 22 Mar 2017 07:36:33 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B05412948E for ; Wed, 22 Mar 2017 07:36:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=481; q=dns/txt; s=iport; t=1490193360; x=1491402960; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=fZzQdYiH+AIB0iCnuOEi5RKGlVLLiMLoRYdfzbV+FxM=; b=brZRDUaRJI8hZuyOGazChQV/0WLcOs1wuI8pUbdHuyeabRz9yNk0AD9o Nn7PGQ22vIX69RIhsUiZKOc/H0p3JZUyynLO3T6eu62vIEyzycR0VEDmH ODPAC5g94/Z0V2f+0mqXlrAMHCaa/YmtjmIU+I4zh0jCacRJvKh2rJhKC w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ATAQA2i9JY/5xdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1FhgQoHjWuRYpVHgg4fC4V4AoMoPxgBAgEBAQEBAQFrKIUVAQE?= =?us-ascii?q?BAQIBAQE4NAsFCwIBCA4KHgULJwslAgQOBYl8CA6tD4o/AQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBGAWGToIFgmqEVIM0gjEBBJxRAZJGgWOPTJNfAR84gQRZFUERAYR?= =?us-ascii?q?GHRmBSnWJDYENAQEB?= X-IronPort-AV: E=Sophos;i="5.36,205,1486425600"; d="scan'208";a="223497329" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Mar 2017 14:35:59 +0000 Received: from XCH-RTP-006.cisco.com (xch-rtp-006.cisco.com [64.101.220.146]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v2MEZxUp000804 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 22 Mar 2017 14:35:59 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-006.cisco.com (64.101.220.146) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 22 Mar 2017 10:35:58 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1210.000; Wed, 22 Mar 2017 10:35:58 -0400 From: "Stefano Previdi (sprevidi)" To: Susan Hares CC: idr wg Thread-Topic: [Idr] 2 Week WG LC for draft-ietf-idr-bgp-prefix-sid-04.txt - 3/6 to 3/20/2017 - extending to 3/31 Thread-Index: AQHSoxmfWABkkGMdRjO4hb7phG9PSQ== Date: Wed, 22 Mar 2017 14:35:58 +0000 Message-ID: <199B16BC-18C3-4F6F-A4C9-156BA7040F82@cisco.com> References: <035901d2a263$a204a0c0$e60de240$@ndzh.com> In-Reply-To: <035901d2a263$a204a0c0$e60de240$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.97.160] Content-Type: text/plain; charset="us-ascii" Content-ID: <41F26C5EF9A0304FAC3CC4FCC159E4C5@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] 2 Week WG LC for draft-ietf-idr-bgp-prefix-sid-04.txt - 3/6 to 3/20/2017 - extending to 3/31 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 14:36:36 -0000 support as co-author. s. > On Mar 21, 2017, at 5:53 PM, Susan Hares wrote: >=20 > IDR WG:=20 > =20 > Perhaps the WG LC came at a bad time since have received only 1 response.= We will length the call to 3/31. Unless with have substantial input, thi= s WG LC will not indicate consensus.=20 > =20 > Sue Hares=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Wed Mar 22 08:07:58 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADC19131759 for ; Wed, 22 Mar 2017 07:39:33 -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, RP_MATCHES_RCVD=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2DpKDzFhxMu2 for ; Wed, 22 Mar 2017 07:39:32 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (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 5C9E71297AA for ; Wed, 22 Mar 2017 07:39:07 -0700 (PDT) X-Original-To: idr@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 9EA8161A02 for ; Wed, 22 Mar 2017 15:33:03 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 231F361637; Wed, 22 Mar 2017 15:33:03 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id 14C5F3435E; Wed, 22 Mar 2017 15:33:03 +0100 (CET) Date: Wed, 22 Mar 2017 15:33:03 +0100 From: Gert Doering To: Brian Dickson Cc: Gert Doering , "Sriram, Kotikalapudi (Fed)" , "grow@ietf.org" , "idr@ietf.org" , "sidrops@ietf.org" , "draft-ietf-idr-route-leak-detection-mitigation.authors@ietf.org" , "sidr wg list (sidr@ietf.org)" Message-ID: <20170322143302.GG2367@Space.Net> References: <20170321205513.GA2367@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="JjQGvUpjKaxqoY/q" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: Re: [Idr] operator inputs -- route leak solution X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 14:39:33 -0000 --JjQGvUpjKaxqoY/q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Tue, Mar 21, 2017 at 03:19:42PM -0700, Brian Dickson wrote: > Pre-emptive top-post in case anyone mistakes the technique proposed: This > will NOT be implemented via communities. >=20 > The proposal is for a NEW optional transitive attribute. >=20 > If any operators can answer the original question, this will be very > helpful. Thank you in advance to any and all operators. >=20 > Reminder on optional+transitive logic > - If the attribute is not understood/implemented/enabled, the attribute is > passed unmodified. > - If it is understood & implemented & enabled, behavior is subject to the > applicable standards. > - Thus, optional transitives are "opt-in", by definition. It does not really matter if this is a well-known community or a new transitive attribute. If ISPs do not turn this *on* on their customer connections, it will not do anything - and given that those ISPs that *need* to turn this on are the ones that are not caring today, I'm still not seeing why they would turn this on tomorrow. So you're adding implementation complexity which will not help anything. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --JjQGvUpjKaxqoY/q Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAljSix4ACgkQ31bAZeTO f8ULhxAAiPcBCmIotqsF0CoqP09alfDDaKam+WqBuTX/EFvah+KVFg5THx42yJoK 8HRHwMPghStcjXy8zbOd/jzOCpvq0x+OMCwqdD2WeExQcWum7nk5AyVtL9PqWn/F Ye8rbVuBuq1c2KH8YzmFv7MQu4OKmC/OEtjrYfFN/WhH2DPU/7QEj/HOYM7sxknW 4vAtiuI0aXfRW2rc2z/UrzOdOVaLfXQYVto2vkj0UhtP9KuKq7wvSTeWwXxSrEpX /MQLTpEfaZjXnkY8Z31sI8jTIakfXV/HUS9k0rG0m6Qp+snnk34jJYcWMvVZS+hn 5Fgj2xfQfUvzYEuqxntTBz87PrJwtZa9YA9DHSMvnp3sulHDQKtKBy90SsuwpKNg cdKZc1MBeQl2H1NOTJod2T5e4GHnbxmUnh6bJV3s9LN1raP8L3xdUN2gALsEglwE /zu6X3Xu2RzwPJF5s+MljPMhoZqlWMYzCxLmuHJytN/Lz8VcsIEiR+JtKrk3HPWZ M8yXcaQgR+YL682ySa4pkxAm3chtpatJanQZkoCIaMBQSPxhPMgdlyJXP3fZDEVl tuguuCI+AsmYH120mtXkAHTrYuMsz02RwbmErQA3PqHKoyy3UQPl6bV90c9tmd/N 40PBsbnxrmxSHWzZKvMNFjQ4cuo6SciRF0aq9e1pR0GvomGfr+I= =mefv -----END PGP SIGNATURE----- --JjQGvUpjKaxqoY/q-- From nobody Wed Mar 22 09:18:14 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5502129AB0; Wed, 22 Mar 2017 09:18:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id anNcjtNZDCpl; Wed, 22 Mar 2017 09:18:10 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0093.outbound.protection.outlook.com [104.47.36.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76D43129A52; Wed, 22 Mar 2017 09:18:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=zYsCyPHczO0FWMve20Z2rL7dJV2aJU6riuZu8PQLqTY=; b=NKmF7p92Lrf9tC6WaPtSE3TdjYp3jxfYpHT3gzk3SANj2GaeyOUHToB62sxL7EPbyaCjwaTBcRFfLE7Dcf5ytBxiNYbd9p6rfVQubgDVX05a5Vql+1o8oLWSXpcCAII+Irs79X8XZkbgqFZCLzxAoMbIaggg26FvVx7iQZJ9uqA= Received: from SN2PR05MB2671.namprd05.prod.outlook.com (10.166.212.142) by SN2PR05MB2669.namprd05.prod.outlook.com (10.166.212.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.4; Wed, 22 Mar 2017 16:18:05 +0000 Received: from SN2PR05MB2671.namprd05.prod.outlook.com ([10.166.212.142]) by SN2PR05MB2671.namprd05.prod.outlook.com ([10.166.212.142]) with mapi id 15.01.0991.013; Wed, 22 Mar 2017 16:18:05 +0000 From: Kaliraj Vairavakkalai To: Susan Hares , 'idr wg' CC: "draft-gredler-idr-bgplu-epe@ietf.org" , "idr-chairs@ietf.org" , "'Dongjie (Jimmy)'" Thread-Topic: IPR call for draft-grendler-idr-bgplu-epe Thread-Index: AdKehOZ/wEwxmWbqQC6qAxZ77D+MDwEaE/aA Date: Wed, 22 Mar 2017 16:18:05 +0000 Message-ID: References: <013d01d29e85$270dcae0$752960a0$@ndzh.com> In-Reply-To: <013d01d29e85$270dcae0$752960a0$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 authentication-results: ndzh.com; dkim=none (message not signed) header.d=none;ndzh.com; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.14] x-microsoft-exchange-diagnostics: 1; SN2PR05MB2669; 7:bjBGO7P9QmxBdaeuIh2EFOgrCqv4q4RinMs7G0Mheq6enYfFebdhDF1opckMdDAjAFDQZYD/G16IK/oIomW5xW09CuGValKm8Aw+Z4ouw5q46TMIXGXcHvcVbLqq1xsaQCx6T9WqlUEQ/wsS94SzbnVMViX3aS1hYMMrjr5VJVkx/30vpr0mti7n7DioGZpwaxt5qYH2P4zJYyIZP6yDDyjmORnrWDly7s8rzhUxZJJm8zTOf89fa7gnWclHXrrkV8T1C7XUvoZUferA0eg8oz7Sp79VXLGr50G4vTk1IeEMURMlZgd9fY6hJhJZGQ+emSpoG6ztioMFspKsm4bEmg== x-ms-office365-filtering-correlation-id: c5e46d5d-14f2-4b78-0130-08d4713f056c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081); SRVR:SN2PR05MB2669; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(50582790962513)(21748063052155)(138986009662008); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123564025)(20161123555025)(20161123560025)(20161123562025)(20161123558025)(6072148); SRVR:SN2PR05MB2669; BCL:0; PCL:0; RULEID:; SRVR:SN2PR05MB2669; x-forefront-prvs: 02543CD7CD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39850400002)(39410400002)(39840400002)(39860400002)(39450400003)(377454003)(606005)(6436002)(54356999)(76176999)(54906002)(99286003)(50986999)(77096006)(236005)(53936002)(5660300001)(3846002)(102836003)(189998001)(230783001)(122556002)(6306002)(54896002)(4001350100001)(6116002)(33656002)(7906003)(6512007)(6486002)(6506006)(66066001)(38730400002)(2906002)(36756003)(3280700002)(83716003)(86362001)(25786009)(4326008)(2950100002)(8936002)(82746002)(229853002)(3660700001)(6246003)(8676002)(81166006)(53546009)(7736002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR05MB2669; H:SN2PR05MB2671.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_B3B8F3AEED39414E84C7BCCF5C247236junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2017 16:18:05.2894 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR05MB2669 Archived-At: Subject: Re: [Idr] IPR call for draft-grendler-idr-bgplu-epe X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 16:18:13 -0000 --_000_B3B8F3AEED39414E84C7BCCF5C247236junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU3VlLCBJRFItV0csDQoNCkkgYW0gbm90IGF3YXJlIG9mIGFueSBJUFIuDQoNClRoYW5rcw0K S2FsaXJhag0KDQpGcm9tOiBTdXNhbiBIYXJlcyA8c2hhcmVzQG5kemguY29tPg0KRGF0ZTogVGh1 cnNkYXksIE1hcmNoIDE2LCAyMDE3IGF0IDExOjQzIEFNDQpUbzogJ2lkciB3ZycgPGlkckBpZXRm Lm9yZz4NCkNjOiAiZHJhZnQtZ3JlZGxlci1pZHItYmdwbHUtZXBlQGlldGYub3JnIiA8ZHJhZnQt Z3JlZGxlci1pZHItYmdwbHUtZXBlQGlldGYub3JnPiwgImlkci1jaGFpcnNAaWV0Zi5vcmciIDxp ZHItY2hhaXJzQGlldGYub3JnPiwgIidEb25namllIChKaW1teSknIiA8amllLmRvbmdAaHVhd2Vp LmNvbT4NClN1YmplY3Q6IElQUiBjYWxsIGZvciBkcmFmdC1ncmVuZGxlci1pZHItYmdwbHUtZXBl DQpSZXNlbnQtRnJvbTogPGFsaWFzLWJvdW5jZXNAaWV0Zi5vcmc+DQpSZXNlbnQtVG86IDxrYWxp cmFqQGp1bmlwZXIubmV0PiwgPGNzZWthckBqdW5pcGVyLm5ldD4sIDxiYWxhamlyQGp1bmlwZXIu bmV0PiwgPGx1ZmFuZ0BtaWNyb3NvZnQuY29tPiwgPGhhbm5lc0BydGJyaWNrLmNvbT4sIDxlYXJp ZXNAanVuaXBlci5uZXQ+DQpSZXNlbnQtRGF0ZTogVGh1cnNkYXksIE1hcmNoIDE2LCAyMDE3IGF0 IDExOjQ3IEFNDQoNCg0KVGhpcyBpcyBhbiBJUFIgY2FsbCBwcmlvciB0byBhIGNhbGwgZm9yIGFk b3B0aW9uIGZvciBkcmFmdC1ncmVkbGVyLWlkci1iZ3BsdS1lcGUgICggRWdyZXNzIFBlZXIgRW5n aW5lZXJpbmcgdXNpbmcgQkdQLUxVKSB3aGljaCBjYW4gYmUgZm91bmQgYXQNCg0KICBodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1ncmVkbGVyLWlkci1iZ3BsdS1lcGUvDQoN Cg0KDQpXaWxsIHRoZSBhdXRob3JzIHBsZWFzZSBpbmRpY2F0ZSB3aGV0aGVyIHRoZXkga25vdyBv ZiBhbnkgSVBSIG9uIHRoaXMgZHJhZnQ/DQoNCg0KDQpTdWUgSGFyZXMNCg0K --_000_B3B8F3AEED39414E84C7BCCF5C247236junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <82B38FB48FCBF54888EA4E5BE53B1464@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEx LjBwdDsNCglmb250LWZhbWlseTpDYWxpYnJpO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRl eHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0 IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7 bXNvLXN0eWxlLW5hbWU6IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWlseTpDYWxpYnJpO30N CnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFt aWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ291cmllciBOZXci Ow0KCWNvbG9yOndpbmRvd3RleHQ7DQoJbXNvLWxpZ2F0dXJlczpub25lO30NCnNwYW4ubXNvSW5z DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SGkgU3VlLCBJRFItV0csDQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkkgYW0gbm90 IGF3YXJlIG9mIGFueSBJUFIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UaGFua3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+S2FsaXJhag0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBw dDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkZyb206IDwv c3Bhbj4NCjwvYj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlN1c2FuIEhhcmVzICZsdDtzaGFy ZXNAbmR6aC5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlRodXJzZGF5LCBNYXJjaCAxNiwgMjAx NyBhdCAxMTo0MyBBTTxicj4NCjxiPlRvOiA8L2I+J2lkciB3ZycgJmx0O2lkckBpZXRmLm9yZyZn dDs8YnI+DQo8Yj5DYzogPC9iPiZxdW90O2RyYWZ0LWdyZWRsZXItaWRyLWJncGx1LWVwZUBpZXRm Lm9yZyZxdW90OyAmbHQ7ZHJhZnQtZ3JlZGxlci1pZHItYmdwbHUtZXBlQGlldGYub3JnJmd0Oywg JnF1b3Q7aWRyLWNoYWlyc0BpZXRmLm9yZyZxdW90OyAmbHQ7aWRyLWNoYWlyc0BpZXRmLm9yZyZn dDssICZxdW90OydEb25namllIChKaW1teSknJnF1b3Q7ICZsdDtqaWUuZG9uZ0BodWF3ZWkuY29t Jmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5JUFIgY2FsbCBmb3IgZHJhZnQtZ3JlbmRsZXItaWRy LWJncGx1LWVwZSA8YnI+DQo8Yj5SZXNlbnQtRnJvbTogPC9iPiZsdDthbGlhcy1ib3VuY2VzQGll dGYub3JnJmd0Ozxicj4NCjxiPlJlc2VudC1UbzogPC9iPiZsdDtrYWxpcmFqQGp1bmlwZXIubmV0 Jmd0OywgJmx0O2NzZWthckBqdW5pcGVyLm5ldCZndDssICZsdDtiYWxhamlyQGp1bmlwZXIubmV0 Jmd0OywgJmx0O2x1ZmFuZ0BtaWNyb3NvZnQuY29tJmd0OywgJmx0O2hhbm5lc0BydGJyaWNrLmNv bSZndDssICZsdDtlYXJpZXNAanVuaXBlci5uZXQmZ3Q7PGJyPg0KPGI+UmVzZW50LURhdGU6IDwv Yj5UaHVyc2RheSwgTWFyY2ggMTYsIDIwMTcgYXQgMTE6NDcgQU08L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5UaGlzIGlzIGFuIElQUiBjYWxsIHByaW9yIHRv IGEgY2FsbCBmb3IgYWRvcHRpb24gZm9yIGRyYWZ0LWdyZWRsZXItaWRyLWJncGx1LWVwZSZuYnNw OyAoIEVncmVzcyBQZWVyIEVuZ2luZWVyaW5nIHVzaW5nIEJHUC1MVSkgd2hpY2ggY2FuIGJlIGZv dW5kIGF0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWdyZWRsZXItaWRyLWJncGx1LWVwZS8iPg0KaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtZ3JlZGxlci1pZHItYmdwbHUtZXBlLzwvYT4gPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+V2lsbCB0aGUgYXV0aG9ycyBwbGVhc2UgaW5kaWNhdGUgd2hldGhlciB0 aGV5IGtub3cgb2YgYW55IElQUiBvbiB0aGlzIGRyYWZ0Pw0KPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+U3VlIEhhcmVzIDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_B3B8F3AEED39414E84C7BCCF5C247236junipernet_-- From nobody Wed Mar 22 11:36:45 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A229E129BE6 for ; Wed, 22 Mar 2017 11:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E-ATJQJZeV5C for ; Wed, 22 Mar 2017 11:36:38 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0111.outbound.protection.outlook.com [104.47.41.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 717641294E1 for ; Wed, 22 Mar 2017 11:36:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ya7QeV6TC0+70WCKaJ0+muYfAH9sAdqm8iKafERqx2k=; b=R9M3OtrHXZsWWdqmVWe20QzSk5GRVTQThiGO1XpXPtbfb/VzUsEXIGL4NmwsV8yyvwKAoic7gS99qa92+FGxO70wQSx01yWtQzq0uVW87B/95ZyjPdVWXWle1N9pm61uXXIOoNTgki57l05TnT4HMw6S6p7gX+aP7LxCVacbhV8= Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=juniper.net; Received: from [172.29.37.164] (66.129.241.12) by BN3PR05MB2499.namprd05.prod.outlook.com (10.167.3.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.4; Wed, 22 Mar 2017 18:36:36 +0000 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "John G. Scudder" In-Reply-To: <3b9c229a-4573-c586-8627-3a8c38539ff8@juniper.net> Date: Wed, 22 Mar 2017 14:36:32 -0400 CC: Susan Hares , Adrian Farrel , Content-Transfer-Encoding: quoted-printable Message-ID: References: <048701d29cd9$15204b80$3f60e280$@olddog.co.uk> <022201d29ce6$ffb2ba40$ff182ec0$@ndzh.com> <02dc01d2a25b$a1eca590$e5c5f0b0$@ndzh.com> <3b9c229a-4573-c586-8627-3a8c38539ff8@juniper.net> To: Eric Rosen X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.12] X-ClientProxiedBy: BN6PR03CA0024.namprd03.prod.outlook.com (10.168.230.162) To BN3PR05MB2499.namprd05.prod.outlook.com (10.167.3.134) X-MS-Office365-Filtering-Correlation-Id: 401d5739-007a-490f-bb8f-08d471525f50 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN3PR05MB2499; X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2499; 3:Gdd0wkhVJTqdQJ/TFiKujex6uOrwsVBBj6ZvJ7uNOpWrFEjkSJGuqWcO9hKDJvXmDMNQ6k8MZ096H/sUweRnpnhQ+6K+SX7XKOcloHRy5q5UKIxhDslNqZTZP9XPFMhDJwaDAZvWa4l0yOIJKsmvhaHtmbtDHt/menUytJLQ3dlpQws+TRdNDQGiABURTu2AQDzAl2hMkAORWNB5aSmu4aqDR7/bmukMRXKCUXZWVboaSs83c9HIrNO/AuoC3Y+D1VK2rusJY9GMeHhRVBt6WogvRNZHSFCLm9CkqpxImpw=; 25:RfiFigacX8niiDW0rRatjBJhx45KldfXzv22Dy4FnirHEqStmTJXWV7QiUr5ZezpA3ClqiNQDqZcC+VPfUB4GIyPK/hiMQLHCdmDj0vOQlA55lLufVdjw4XTwSkOG9fTfX5bHiJYb4IpCmmCAgnSn/8h98cYgLvdtQS0s2Q60IVoZ3Rl211gne1LEIteppnPzXDEnx+nEFXgjRzu86/ZtCqHYXcXFP63UccKxtYdecHz86iTZN38hJEGhZe9GQkCaNpxd0M+zGWZw7E08ygFFrSaGVTbImtQZbiBi7MmKkQm8KY52Kh6QxXj/ZldPvsgX3jIH/NXcuSq7gbBZpL9C4yDBZwBkwA2WC+fUSRVgbxCF8dmDJD3aOZZlPZVlC9KpwI17zL9Utk7/sn5I1VUSPwc4xSNwX6tGPd4hdvkSz5/N1V3ABg23vV6TvmJYk37T9Zko5zHIPzw7a3f+niirA== X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2499; 31:uLRSDPjQRmWMB7G4Fdrp1I6Y26Os40mDErTgh/gNofvNE+XMl9dSGfeKkV5ylUA7l/206CEcu0bnQ590wvmySNPSdeGcGWkD+OD0Ev1GkNCWqSngwYv+ouYD18/9CB3npzFI/vcM/vguR66gkMjPkAMh5QmxzhupwsF6p2dcrO0PHirhn2h9kg6XsNIBumIZKDVDfSTDLIcXJATWgKnBSaUutOZPg64RPe4Nb32SXY1TA18n6VnuDwQWNaNgjKV6; 20:P3Z1uB6MGz+f2t1n6nQOzNxHl5W8i6cRUuIirMeeW3cysRcakYomnM6Il1ioMwgeKsHIjvakW9ruT0NWplSNs34+Phn0v1g//K/AWHBsvhyMB4tZp1OBd0cVNqC92XTOxYBQ19nj/tAManspxfKZHVVUHmEBRXCbiMZAZ0tM0LXKFOeeNE/+CmH+cmBq77kzifqXlpj7OFWY5+aDGZWnAnfHL0ZC879wxojSghYep9NdhinfUDs356kSWlRCHtjr4qTrq0/mXPSNNSil3xzoTR22gF6fSIegGyl0Rj7uziUBClCjAuMG3nA8ibfH5q6fZZrK0Z5p8qAIJpNV/m+4AGjc+20ZAsbHnZVDjH09+ztgHBK7G0Yt/DTty0lp9uXOaahH28ARh10LZHP6W4474GQBNoGk6rJEa4DtGVZcdWlt3MQY3LIkiVDGXOSrUAp51BsNXmKRUQytX7ss7FzZyVYgQkCWFHXke7z7HDoZJ9WVuchKNAco3nR4ZxleWZCpAm+qNKj826yRdllioKS0UZsMee89MV9Tl5Ax5zvkFxk8SjoH8X7eEwb5dboZBe8ZSxyVTot8pSkkHfvMhsNaIb1V6S1KY9w1JRTN92fESv8= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(72170088055959)(100405760836317); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123564025)(20161123555025)(20161123560025)(20161123562025)(20161123558025)(6072148); SRVR:BN3PR05MB2499; BCL:0; PCL:0; RULEID:; SRVR:BN3PR05MB2499; X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2499; 4:uTAOyJYou9FNz7M9z7QXcRIRRVVAqBzgQwIKdqmfWO9M+6ctmfdBOYjmiFVm4/8C+zaVcFJJudLuiLsfJbTVCl13QRmTsU9b0fPCumWGghleiQLCJRbKu2ihfjbNmozSgDuALG+pLWCpUhHNFFrk97qNvz2JR5Di3MSc5x9syaviEXZ7WNdgoxPa8/3waUkxIsg8Cp+TDgA2UTNKwdVmuSpph7tWv/lvCF54ODxwNe3La3VEk9SZXZyq6Ty5iSshgloSGJ3kqwEUCSZikm/4HUmFv2PsnbaBGRAzIEpu/aPZm8YWophx8XwtCpgPIO6snKxN3KHEg+QFwnboIW83CwjRR7P244CQvTNALPAD33tOGyD7E1uNfZgSmE1yrRdsjcfbEq6tRz0+J+2WPB/ylxqdmjFrxssWkxrXrCGS1hTvSmAuVEHnhvOpWjUeVtfGu6BmtwuLyua63dt5IpAkvnvTnYm3mhgZz9W1iE8E/s7myxVQGaXzjqbm7eFkLTv79SKkR704gq5EzJLjzprG1ExotBHTpIuUOUVdCa67E+Ko1ldUFa12wDdX+athA+19BkH9L30+RqIv8zL+w/8NihHrJAQD+HynepVyYMs/IjiZyOlS4DE+k7hcuZJuoN/6dSHU4ih5goz5oBTf0PrA1xSvMqsi68FX+5APCw/Z/WHo8HGwj9/jbiVxyFQjY6VolUNe1VW+X0zLXxWT/Acfog== X-Forefront-PRVS: 02543CD7CD X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(39410400002)(39850400002)(39450400003)(39840400002)(39860400002)(23746002)(50986999)(50226002)(76176999)(8676002)(81166006)(53936002)(8746002)(2906002)(230783001)(33656002)(561944003)(50466002)(42186005)(6486002)(90366009)(93886004)(36756003)(3846002)(110136004)(6116002)(25786009)(66066001)(38730400002)(86362001)(77096006)(82746002)(47776003)(229853002)(6862004)(83716003)(2950100002)(6246003)(5660300001)(7736002)(305945005)(189998001)(4326008)(6666003)(6636002)(54906002)(163123001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR05MB2499; H:[172.29.37.164]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; BN3PR05MB2499; 23:I7DdifxdBtI3jZw72MV1VHlPjLr+IETcbxgUM?= =?Windows-1252?Q?xr/zOmexByNUI0Y7tdrXppjegJqLLaBPsXwx/txor8ZQcvQ3DVDppNEk?= =?Windows-1252?Q?w1qu02V+oCud8cGdch6xAj5U3RY3rUr9quArfdVg461Q1QveXeqxbMi8?= =?Windows-1252?Q?S19Cfd+XwB6qCl1nxL55zHWO49kTbicA2QgHRp+xw+w6RZx1J+Clga9I?= =?Windows-1252?Q?D+QrZ1mmAnuym7AfjAF8t8mG5HpMTd65EOhLPMy3gay+wGQ0Xi44C1tg?= =?Windows-1252?Q?AaOnOAydXiB+NIvpg4Gzj4Bf8qCBFqJvQ2DhwnyINHavcO5qqqoMxZNL?= =?Windows-1252?Q?Rz8U0+48JADe0ysEMjf3qNYGIJ5PdNTPggrAwjz1Sn1jUOwdTAyiMQhc?= =?Windows-1252?Q?unHOWKi2y9UVDSG3E/iu9CETQiRZ1MFiUN6Mj/FQHEHBys8BCoCSVZTJ?= =?Windows-1252?Q?cvXZjZhsr04qjimvO8Rnb8Rc8UkStR9fh+TNGJL+06U0YXKc4IgiEGDW?= =?Windows-1252?Q?FxMEw+TqR21ATRytzHdSdQECaTS9TsCpGBbzEVR+nV9qZdd3CU6WUDdU?= =?Windows-1252?Q?/Yiws6IB1amaIL0aAaouaCMvmd70mbF326kl90nDK9ZQYfBYxh9OjL2u?= =?Windows-1252?Q?KsPHPkaIzoBEJ1ivJEJ62BA97WYZjDfjr674RDC9nwZzZw8+5HMrDdmt?= =?Windows-1252?Q?E/GDfzEGPD6g1X0I1JoT4hIzTOdZW8fS+r7EMOv0xZ67+9amsDzkIkfB?= =?Windows-1252?Q?x7PzBg9YIdghSY/ChJWD6e6nOevfdo/1RUv06xaEd/89lUY4KAN0liUJ?= =?Windows-1252?Q?RHY4ie48UvI7N6i0SscOit0L+fhTNCLS5hPtXCfjiKvhJLxxJ9hrW+mb?= =?Windows-1252?Q?6ZURlaPg9xHlFUXuh7CO37EC/G7TUvRkJ7I5/i1GUY464gJSs0AeBBug?= =?Windows-1252?Q?7raqSypPKSSZIKOgjYzzcrYwOOTk1RgQ5hey6FqCFTSrDxl+BpV4npOe?= =?Windows-1252?Q?yNP1CZ+/7v+s70D19jJ0sd5GLqyPHk561b+3GQ0kxHk5if0Lo6JduS+2?= =?Windows-1252?Q?eu9wzdNT274/qw4SV3sQZowMS0i0vhsWc3b5CQo7hnMcm2Pv4IXAZsf3?= =?Windows-1252?Q?HUN4zxhvXG7rC1IQYYOgJpgLkIgtkWRg4vtd9daL341PrgUitsF34qwN?= =?Windows-1252?Q?FWy/FfsdniZFaVcocZ+TINULIY5Zd9VXHElDtMr4bu6+Ytyd0MDmmvK0?= =?Windows-1252?Q?ulRshC6jk58/CxxEPcTP/PcQtx0GgasOFAmLj456u6bvyPq8npx41QA/?= =?Windows-1252?Q?2op0VUNyjeX6zTm56N2zmDRBZvf0atVYvn6frdSKRq2N30=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2499; 6:QVNpJXSptQXy9GJ4FGbxpvSXC/D2Akn1Amt2sup0vwWhlm1dROw9uda5VSYaLgRkDKuPruYjL9f6gf6MgBKuulYsFNFBmeGWajyv5NSd5poPfXkzytMwokTk78FKHTAxJISIDcrs8sL9fbHRrmYNPBm5OPMLQWPvLR1P7Bt+2W3bFq3LGGUZ80rVW57FEuHyZypHokKQo4m7TYxYuEe4nKCbQwqapUCEoaiUaX+biQB3CMEciOJ0lqU9C2J5AFRYYo5/Du/wrrXrEFo1j9mRYOMaZCwb9mirt1iCDqRT/vYGEGqqlrB+0dFjosAsuyInSaih3Ka+E33t4yVAZa4kcWsu64/NEieca/KjYesZ7dN/rvWPdJTokRMnXRtLIYSpoukbQzzKznhtro6nhl7oeav38Szr2DxsltLxXQhwnbM=; 5:qJnjQ3OqDEjEsodJSx50TBauvkrMEUWs84DVTq11UNq8b2+fT7mS+zmMIO3y6tRM83K2zel226knbGDRkUNo0JaiAEDsxP0KO2MwvXjeQQ6Abte075fwt8Z3Iovc53LAZDAeVWMyS5ScoqxXSVCH/A==; 24:0XHFHaWgjwLXPBSBIFDVwf9r7QVke44dm4IwqeAqhoxxTYz4hqMsc0Md4CHiZ2mI/oZHi26pl1wgIPiSgT7zekTSpDytuT5mMGYSDZCMzSg= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2499; 7:HtOLZ+vHWltKUruuPC0I99o6Ip5m05Mb/+a+LeFVTOgXe7yOb8qwYnJP+sD3Nfcw5aB70UzYqt4LEmslRfTvMpgTolk4Dx2S0wVL20fB/SIZRPPlT2sduDfIKdJWfl/aoL4yonWdPnrl6YJYiBgtGJcvIxguqFluElDZnfvd+ok4YSF8hdJsSTwZ/mnF5S8rizuzkS9WT4VITPRS22o4yHxm5/op9B0EzG+iW1zE+NtmdeFFjWGq5+7i5/de87NAfR0dWBmcSPyUSPe6JT5lt5dl/69ceA/jRGjo6BKX8xXMuZqPiYjuAV6aKaGnFsu8Z3yt9F1cHurj1NMvs8FOzQ== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Mar 2017 18:36:36.2882 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR05MB2499 Archived-At: Subject: Re: [Idr] Thoughts on https://www.ietf.org/id/draft-hares-idr-bgp-registries-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 18:36:43 -0000 Eric, First of all, I am going to assume we are talking about this goal = (thanks, Adrian, for the nice summary): > 2. How to stop code point allocations through the normal IANA process = for "ideas > that could use more review". Let's consider that to be the problem statement, replacing the Abstract = and Introduction in the current draft. Sue's draft only covers registries that have what I suppose you'd call a = lot of red tape to begin with -- Standards Action and IETF Review = registries. The issue at hand is that although in theory these ensure = plenty of review because they go through IETF last call, you may be = shocked to learn that not everybody reviews every message sent to = ietf@ietf.org in a careful and timely fashion.=20 It's also interesting that you bring up the question of which WG "owns" = which registry. ("Furthermore, a number of the mentioned registries were = not established by the IDR WG, and I don't see that the IDR WG has any = standing to request changes in the registration policies of those = registries.") The problem at hand arises exactly when a spec is being = progressed in one WG but allocating a code point from a registry "owned" = by another WG. Guess what? There is no formal concept of a WG owning a = registry so there's no formal way to address this. By the same token, it = also means the concept of a WG having "standing to request changes" is = inoperative. Sue's draft represents an attempt at retrofitting such a = concept, and again, the reason is to try to ensure sufficient review = happens before it's too late. A specific example of when this didn't happen is with the Entropy Label = Capability Attribute allocated out of the BGP Path Attributes registry = by RFC 6790, from the MPLS WG and later deprecated by RFC 7447 because = it had a bug. IDR never touched the draft and the title of it ("The Use = of Entropy Labels in MPLS Forwarding") wasn't likely to draw the eye of = BGP folk. No amount of process will guarantee bugs don't slip through, = but the hope is that it'd help sometimes without being onerous. Regarding your comments about politics, I disagree but don't intend to = argue the point -- I'm not going to convince you. However, all of the = registries Sue identified are already SA or IETF Review, and I think = Adrian nailed it when he suggested: > b. Recognition that IETF consensus trumps DE opinion. Hopefully this = will never > arise, but it is clear (or should be) that for a Standards Action = registry, if > there is IETF consensus for an assignment, then the DEs can warn and = advise, but > the will of the IETF takes precedence. RFC 5226 is happily flexible in the article of what a registry policy = is: "It is not required that documents use these terms; the actual = requirement is that the instructions to IANA are clear and unambiguous." = So if we decide that what we want is, say, Standards Action with Expert = Advice (I just made that up based on Adrian's observation that this = isn't actually Expert Review according to the 5226 definition), then we = can do that as long as we write it up clearly. In parallel, Job Snijders made a useful suggestion that idnits maybe = should be on the lookout for code point squatting. This leads me to = wonder if we aren't going at this wrong -- if instead of using the = hammer of registry policy to ensure the right WGs have been notified, we = should try the screwdriver of automated tooling. The idea is registries = would still be marked up with parties interested in monitoring them, but = there would be no formal changes to the requirements for allocation from = the registries. Those monitoring the registries (e.g., the list of = people in Sue's draft) would get notifications when an allocation was = proposed -- as early as possible, but no later than when the draft was = sent for IETF last call. The onus would fall on them to chime in (again, = as early as possible) and the regular consensus process would take its = course. I think this approach would be just fine and would seem to address your = morbid fears of red tape, but it requires someone to go build some new = tooling (I don't even know if there's an existing tool that can be = pressed into service or if we're talking about an entirely new thing), = whereas the registry policy proposal uses "tooling" that already exists. --John= From nobody Wed Mar 22 14:49:34 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC794129353 for ; Wed, 22 Mar 2017 14:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.956 X-Spam-Level: X-Spam-Status: No, score=0.956 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nnAARIy-bLsy for ; Wed, 22 Mar 2017 14:49:25 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 9021A12751F for ; Wed, 22 Mar 2017 14:49:25 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=70.194.25.59; From: "Susan Hares" To: "'Eric C Rosen'" , Cc: References: <048701d29cd9$15204b80$3f60e280$@olddog.co.uk> <022201d29ce6$ffb2ba40$ff182ec0$@ndzh.com> <02dc01d2a25b$a1eca590$e5c5f0b0$@ndzh.com> <3b9c229a-4573-c586-8627-3a8c38539ff8@juniper.net> In-Reply-To: <3b9c229a-4573-c586-8627-3a8c38539ff8@juniper.net> Date: Wed, 22 Mar 2017 17:44:23 -0400 Message-ID: <00f701d2a355$78aa2590$69fe70b0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F8_01D2A333.F19A5A50" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHgLJVhftftdlZ2OeQGM5dxbx7ZtQIfusEjApalZLoB3VIuCQJnQvCHoT53ZeA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] Thoughts on https://www.ietf.org/id/draft-hares-idr-bgp-registries-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 21:49:28 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00F8_01D2A333.F19A5A50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Eric: What I summarize from your note is the following: 1) You do not feel WG chairs or ADs are collaborative in the IETF professional society even though the IETF runs on rough consensus and running code. You feel WG chairs and ADs are motivated by commercial reasons before the altruism of the IETF professional ideals. 2) You want a BGP attribute name-space without any oversight, even though squatting brought attribute conflict that lead us to this point. 3) "egad process" is the depth of your understanding on the IANA reviews. Wow! An anarchist in a standards society with a low opinion of moral of WG chairs and ADs. Thank you for bringing an enjoyable moment into my day. Sue From: Eric C Rosen [mailto:erosen@juniper.net] Sent: Tuesday, March 21, 2017 4:54 PM To: Susan Hares; adrian@olddog.co.uk Cc: idr@ietf.org Subject: Re: [Idr] Thoughts on https://www.ietf.org/id/draft-hares-idr-bgp-registries-01.txt On 3/21/2017 11:55 AM, Susan Hares wrote: Eric: Politics: I do not know how this introduces politics - since it is just the WG chairs. The WG chairs for BGP related groups are very collaborative. And they would never dream of trying to manipulate the process in order to slow down the work of a competitor! Absolutely unheard of. A committee with no politics? That would be a first. If they are not collaborative, the ADs can work with or replace the WG chairs. Oh, no politics there either ;-) And we know how quickly things happen when the ADs have to "work with or replace" the chairs. How does it speed up things? It provides 8 designated experts which means IANA does not have to chase down a few people (2-3). Currently, with no designated experts, IANA does not have to chase down anyone. Requiring additional approvals can only slow things down, not speed them up. This is the most often reason for IANA slow-downs (AFAIK). The collaborative chairs can decide on a rotation for a designated person to check up with other chairs. Egad, more process. Have I responded to all your concerns? Not at all. ------=_NextPart_000_00F8_01D2A333.F19A5A50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Eric: =

 

What I summarize from = your note is the following:

1)      =  You = do not feel WG chairs or ADs are collaborative in the IETF professional = society even though the IETF runs on rough consensus and running code. =   You feel WG chairs and ADs are motivated by commercial = reasons before the altruism of the IETF professional ideals. =   

2)      = You want a = BGP attribute name-space without any oversight, even though squatting = brought attribute conflict that lead us to this point. =

3)      = “egad = process” is the depth of your understanding on the IANA = reviews. 

 

Wow!  An anarchist = in a standards society with a low opinion of moral of WG chairs and ADs. =  

Thank you for bringing an enjoyable moment =  into my day. 

 

Sue =

 

From: Eric C Rosen [mailto:erosen@juniper.net]
Sent: Tuesday, = March 21, 2017 4:54 PM
To: Susan Hares; = adrian@olddog.co.uk
Cc: idr@ietf.org
Subject: Re: = [Idr] Thoughts on = https://www.ietf.org/id/draft-hares-idr-bgp-registries-01.txt<= /span>

 

On 3/21/2017 11:55 AM, Susan Hares = wrote:

Eric: =

 

Politics: I do not know how this introduces = politics - since it is just the WG chairs. The WG chairs for BGP related = groups are very collaborative. 


And they would never dream of trying to manipulate = the process in order to slow down the work of a competitor!  = Absolutely unheard of.

A committee with no politics?  That = would be a first.


If they are not collaborative, the ADs can work = with or replace the WG chairs.  


Oh, no politics there either ;-) And we know how = quickly things happen when the ADs have to "work with or = replace" the chairs.


 

How = does it speed up things?  It provides 8 designated experts = which means IANA does not have to chase down a few people = (2-3).  


Currently, with no designated experts, IANA does not = have to chase down anyone.  Requiring additional approvals can only = slow things down, not speed them up.


This is the most often reason for IANA slow-downs = (AFAIK).  The collaborative chairs can decide on a rotation for a = designated person to check up with other chairs. 


Egad, more = process.




Have = I responded to all your concerns? 

 


Not = at all.

------=_NextPart_000_00F8_01D2A333.F19A5A50-- From nobody Wed Mar 22 15:08:55 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 207B11292D3; Wed, 22 Mar 2017 15:08:47 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wwh3v6O4CsWL; Wed, 22 Mar 2017 15:08:45 -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 BD4CB1293DA; Wed, 22 Mar 2017 15:08:44 -0700 (PDT) X-Envelope-To: grow@ietf.org Received: from cupcake.local ([194.88.241.232]) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id v2MM8eLH069326 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Mar 2017 22:08:41 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host [194.88.241.232] claimed to be cupcake.local Message-ID: <58D2F5E7.80205@foobar.org> Date: Thu, 23 Mar 2017 00:08:39 +0200 From: Nick Hilliard User-Agent: Postbox 5.0.11 (Macintosh/20170302) MIME-Version: 1.0 To: Gert Doering CC: "idr@ietf.org" , "grow@ietf.org" References: <20170321205513.GA2367@Space.Net> <20170322143302.GG2367@Space.Net> In-Reply-To: <20170322143302.GG2367@Space.Net> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Idr] [GROW] operator inputs -- route leak solution X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 22:08:48 -0000 [cc: trimmed] Gert Doering wrote: > If ISPs do not turn this *on* on their customer connections, it will not > do anything - and given that those ISPs that *need* to turn this on are > the ones that are not caring today, I'm still not seeing why they would > turn this on tomorrow. the asns unlikely to turn on a feature like this are leaf customers, which is intentional. Nick From nobody Wed Mar 22 15:10:54 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 760731293DA; Wed, 22 Mar 2017 15:10:48 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ymIOPcdC6GSO; Wed, 22 Mar 2017 15:10:47 -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 E2EFD1292D3; Wed, 22 Mar 2017 15:10:46 -0700 (PDT) X-Envelope-To: grow@ietf.org Received: from cupcake.local ([194.88.241.232]) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id v2MMAhMt069578 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Mar 2017 22:10:44 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host [194.88.241.232] claimed to be cupcake.local Message-ID: <58D2F662.5020504@foobar.org> Date: Thu, 23 Mar 2017 00:10:42 +0200 From: Nick Hilliard User-Agent: Postbox 5.0.11 (Macintosh/20170302) MIME-Version: 1.0 To: Gert Doering CC: "idr@ietf.org" , "sidrops@ietf.org" , "grow@ietf.org" References: <20170321205513.GA2367@Space.Net> <20170322143302.GG2367@Space.Net> In-Reply-To: <20170322143302.GG2367@Space.Net> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Idr] [GROW] operator inputs -- route leak solution X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 22:10:48 -0000 Gert Doering wrote: > It does not really matter if this is a well-known community or a new > transitive attribute. actually it does. send-community is disabled by default on most ebgp stacks. Transmission of other transitive attributes is enabled by default. Nick From nobody Wed Mar 22 15:13:07 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C603127342; Wed, 22 Mar 2017 15:13:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xCZ06se0aQXb; Wed, 22 Mar 2017 15:13:04 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBC7A127735; Wed, 22 Mar 2017 15:13:03 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id 190so31004151itm.0; Wed, 22 Mar 2017 15:13:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oUHKLFxuZRky4t5r6WW0J1XCW+fLpRqc3d2eE1QmR/Y=; b=V9zI3/OXt0h8dzmKaggNrxMdCHAD5XiTNcrf0hx9YtqjiEKcHuJbhN3RMvPOAKd8tp y5R3DvFn6RoX3CD999aix5r8p3LuvwN+emRjcDxM5HuVJOmGCQitwQ4fibgoec+EIQni 6QzkeXENXtPK/AYBiREOM3NOooSkm33b5CyoGhRxIK0q9zviYKAB4JU5RKmPCbotPEKZ +GaIIZs4eDIk8SamDrvo9TQy/YCrKujkVl8Oi1RVQhmPfFE6J8nzJ/EBhQLjXNI4FcJ3 U3bJLhOWAaPq2pK95CVdDMEhH5qiIHePlfTronraFt6wg+eHvHkdXCGH3JlwYkc7hcNc DKOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oUHKLFxuZRky4t5r6WW0J1XCW+fLpRqc3d2eE1QmR/Y=; b=XUCiWtjZdPrtlbJldMMPmbjxMxJES81XKKfFpAthYw/JyOhdtin/z5kQlPVurv8hKg 4F3Yu8kgAgvkroCSDP9aL4hiAEOvPas8nzqUUFMFutPJUjC9XDSTI1M3XE5zcAvOAhsi wJ//JmRuK9W/aGIYc1TtKFLINlQItjHlMsgXcjMN5M7Ioivovov9ieuLDW0KXuXsNLn5 9AwD8MFEByoQZpPCa14zTYsdtXrvApIsG4J/PFUDOXmr/4xWirk0YgIefh9qQmwlmQiF MFfxeX015Yvi34AdvYibAf7zhEgTYT8LGCXKyWXHzU+yZStoX+jTsR3O39ei7XEnFSy3 IEeg== X-Gm-Message-State: AFeK/H3HxY2xPVkDHS/tX2hB4ZTAPfdnnQrQBramODZ/+x+t26wT6X82SloauUqVpUWTD16Yd7OmVWMtK8M6BQ== X-Received: by 10.36.4.67 with SMTP id 64mr10149401itb.19.1490220783203; Wed, 22 Mar 2017 15:13:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.121.77 with HTTP; Wed, 22 Mar 2017 15:13:02 -0700 (PDT) In-Reply-To: <20170322143302.GG2367@Space.Net> References: <20170321205513.GA2367@Space.Net> <20170322143302.GG2367@Space.Net> From: Brian Dickson Date: Wed, 22 Mar 2017 15:13:02 -0700 Message-ID: To: Gert Doering Cc: "Sriram, Kotikalapudi (Fed)" , "grow@ietf.org" , "idr@ietf.org" , "sidrops@ietf.org" , "draft-ietf-idr-route-leak-detection-mitigation.authors@ietf.org" , "sidr wg list (sidr@ietf.org)" Content-Type: multipart/alternative; boundary=001a1140ad4e6ba0a9054b59103c Archived-At: Subject: Re: [Idr] operator inputs -- route leak solution X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 22:13:06 -0000 --001a1140ad4e6ba0a9054b59103c Content-Type: text/plain; charset=UTF-8 On Wed, Mar 22, 2017 at 7:33 AM, Gert Doering wrote: > Hi, > > On Tue, Mar 21, 2017 at 03:19:42PM -0700, Brian Dickson wrote: > > Pre-emptive top-post in case anyone mistakes the technique proposed: This > > will NOT be implemented via communities. > > > > The proposal is for a NEW optional transitive attribute. > > > > If any operators can answer the original question, this will be very > > helpful. Thank you in advance to any and all operators. > > > > Reminder on optional+transitive logic > > - If the attribute is not understood/implemented/enabled, the attribute > is > > passed unmodified. > > - If it is understood & implemented & enabled, behavior is subject to the > > applicable standards. > > - Thus, optional transitives are "opt-in", by definition. > > It does not really matter if this is a well-known community or a new > transitive attribute. > > If ISPs do not turn this *on* on their customer connections, it will not > do anything - and given that those ISPs that *need* to turn this on are > the ones that are not caring today, I'm still not seeing why they would > turn this on tomorrow. > > There is direct benefit to partial (even very sparse) deployment. The deployment is self-serving; whoever turns this on protects themselves and their downstream customers. This becomes a differentiator with direct benefits, and creates market pressure to deploy. Here's the simplest example showing how few parties need to implement this, for benefit. (Key: O = originator, T = top-tier ISP, L = leaker; number N disambiguates; subscript y/n means "implements") On1 - (arbitrary path) - Tn1 - (arbitrary path) - L - (arbitrary path) - Tn2 - (arbitrary path) - On2 - leaks in both directions pass without any tagging/blocking; - Path via L is preferred, because T1 and T2 prefer customer routes (which include L) - All traffic between Tn1 and Tn2 is affected (assuming L leaks the entire routing table) - In addition to latency caused by extra hops, there will likely be queueing-based latency, and significant loss On1 - (arbitrary path) - Ty3 - (arbitrary path) - L - (arbitrary path) - Ty4 - (arbitrary path) - On2 - leaks in both directions are blocked, at Ty3 and Ty4 respectively - The leak is blocked despite neither On1 nor On2 activating the protocol - The actual path selected will be something else, possibly/probably: - On1 - ... - Ty3 - Ty4 - ... - On2 - Since Ty3 and Ty4 both block the L routes (leaked) inbound, those routes are excluded - Assuming Ty3 and Ty4 peer, there will not be a better path respectively, modulo other peers with shorter AS paths to On1 or On2. If both of the above paths (Tn1 - L - Tn2, and Ty3 - Ty4) are valid paths, the following will be the case: - In all likelihood, there will be massive latency and packet loss, on the first path via L - The other path will not have that latency/loss - On1 and On2 will both be better served by - preferentially routing to Ty3 and Ty4 (apply better local-pref inbound to Ty3 and Ty4) - preferentially announcing to Ty3 and Ty4 (prepend to Tn1 and Tn2) - On1 and On2 obtain benefit by being able route around L (the leaker) - Ty3 and Ty4 get benefit by having more traffic to/from their customers - Potential customers may choose Ty3 and Ty4 for those reasons - Networks who deploy on their own infrastructure gain similar benefits, even if they All of the above presumes intermediate ASNs that do not implement (all of the "arbitrary path" bits), yet there is benefit to all the named parties. The same would be true for ASNs at Tier-2 who peer at various exchange points, who implement; they would possibly position themselves better than Tier-1's until any Tier-1's implement. NB - ASNs who are upstream of L, but downstream of Ty3 and Ty4 would NOT see the benefit, unless they also implement, so there is further reason to implement for Tier-N, N>1. FYI - I worked as a senior network engineer, where inbound peering ACLs of other Tier-1 networks, allowed us to escape the AS7001 incident unscathed. This scales a lot better, since there is no need for ACL maintenance. Applying to customers/peers should be easy, assuming the ISP knows which BGP neighbors are customers... Brian > So you're adding implementation complexity which will not help anything. > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > --001a1140ad4e6ba0a9054b59103c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Mar 22, 2017 at 7:33 AM, Gert Doering <gert@space.net> wrote:
Hi,

On Tue, Mar 21, 2017 at 03:19:42PM -0700, Brian Dickson wrote:
> Pre-emptive top-post in case anyone mistakes the technique proposed: T= his
> will NOT be implemented via communities.
>
> The proposal is for a NEW optional transitive attribute.
>
> If any operators can answer the original question, this will be very > helpful. Thank you in advance to any and all operators.
>
> Reminder on optional+transitive logic
> - If the attribute is not understood/implemented/enabled, the att= ribute is
> passed unmodified.
> - If it is understood & implemented & enabled, behavior is sub= ject to the
> applicable standards.
> - Thus, optional transitives are "opt-in", by definition.
It does not really matter if this is a well-known community or a new=
transitive attribute.

If ISPs do not turn this *on* on their customer connections, it will not do anything - and given that those ISPs that *need* to turn this on are
the ones that are not caring today, I'm still not seeing why they would=
turn this on tomorrow.


There is direct benefit to partial (ev= en very sparse) deployment.

The deployment is self= -serving; whoever turns this on protects themselves and their downstream cu= stomers.

This becomes a differentiator with direct= benefits, and creates market pressure to deploy.

= Here's the simplest example showing how few parties need to implement t= his, for benefit.
(Key: O =3D originator, T =3D top-tier ISP, L = =3D leaker; number N disambiguates; subscript y/n means "implements&qu= ot;)

On1 - (arbitrary path) - Tn1 - (arbitrary pat= h) - L - (arbitrary path) - Tn2 - (arbitrary path) - On2
  • = leaks in both directions pass without any tagging/blocking;=C2=A0
  • P= ath via L is preferred, because T1 and T2 prefer customer routes (which inc= lude L)
  • All traffic between Tn1 and Tn2 is affected (assuming L= leaks the entire routing table)
  • In addition to latency caused by e= xtra hops, there will likely be queueing-based latency, and significant los= s
On1 - (arbitrary path) - Ty3 - (arbitrary path) - L -= (arbitrary path) - Ty4 - (arbitrary path) - On2=C2=A0
  • le= aks in both directions are blocked, at Ty3 and Ty4 respectively
  • The leak is blocked despite neither On1 nor On2 activating the protoco= l
  • The actual path selected will be something else, possibly/pr= obably:
    • On1 - ... - Ty3 - Ty4 - ... - On2
    • Since Ty3 and= Ty4 both block the L routes (leaked) inbound, those routes are excluded
    • Assuming Ty3 and Ty4 peer, there will not be a better path respective= ly, modulo other peers with shorter AS paths to On1 or On2.
    <= div>If both of the above paths (Tn1 - L - Tn2, and Ty3 - Ty4) are valid pat= hs, the following will be the case:
    • In all likelihood, th= ere will be massive latency and packet loss, on the first path via L
      • The other path will not have that latency/loss
    • On1 and On2 will b= oth be better served by=C2=A0
      • preferentially routing to Ty3 and= Ty4 (apply better =C2=A0local-pref inbound to Ty3 and Ty4)
      • prefere= ntially announcing to Ty3 and Ty4 (prepend to Tn1 and Tn2)
    • On1= and On2 obtain benefit by being able route around L (the leaker)
      • <= ul>
    • Ty3 and Ty4 get benefit by having more traffic to/from their custome= rs
    • Potential customers may choose Ty3 and Ty4 for those reasons
    • Networks who deploy on their own infrastructure gain similar benefits,= even if they=C2=A0
    All of the above presumes inte= rmediate ASNs that do not implement (all of the "arbitrary path" = bits), yet there is benefit to all the named parties.

    <= /div>
    The same would be true for ASNs at Tier-2 who peer at various exc= hange points, who implement; they would possibly position themselves better= than Tier-1's until any Tier-1's implement.

    NB - ASNs who are upstream of L, but downstream of Ty3 and Ty4 would NOT= see the benefit, unless they also implement, so there is further reason to= implement for Tier-N, N>1.

    FYI - I worked as a= senior network engineer, where inbound peering ACLs of other Tier-1 networ= ks, allowed us to escape the AS7001 incident unscathed.=C2=A0
    Thi= s scales a lot better, since there is no need for ACL maintenance.
    Applying to customers/peers should be easy, assuming the ISP knows which = BGP neighbors are customers...

    Brian
    =C2=A0
    So you're adding implementation complexity which will not help anything= .

    Gert Doering
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- NetMaster
    --
    have you enabled IPv6 on something today...?

    SpaceNet AG=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Vorstand: Sebastian v. Bomhard
    Joseph-Dollinger-Bogen 14=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Aufsichtsratsvo= rs.: A. Grundner-Culemann
    D-80807 Muenchen=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0HRB: 136055 (AG Muenchen)
    Tel: +49 (0)89/32356-444=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0USt-IdNr.: DE813185279

    --001a1140ad4e6ba0a9054b59103c-- From nobody Wed Mar 22 15:45:45 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84A58126DED for ; Wed, 22 Mar 2017 15:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJoRcpbOqatI for ; Wed, 22 Mar 2017 15:45:41 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79DB412709D for ; Wed, 22 Mar 2017 15:45:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5706; q=dns/txt; s=iport; t=1490222741; x=1491432341; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=AjS0uYMGmj32obUsD7Lzh0/BkNuhK8rYBW7r2VnkgCA=; b=jPreNwDQkjYkbGCbpHs0wEb86gu2OUEOPsnEyquFxsZYOxV99+RvCTgE yydMAA5hb1xhlvgHjOSbO4TxQ3MYIOnr818hniAS4qyAwzunxr+wMDYkb hhUoDb5ipr0Ke8A9CEfd/yT67SL2SPvFfUxprAIlNis2QwaWfH7biUnHD I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BvAgD8/dJY/5FdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5jYYEKB4Nbig+RQx+QGIUvgg6GIgIagxA/GAECAQEBAQEBAWs?= =?us-ascii?q?ohRUBAQEBAyMKXAIBCA4DAwECJAQDAgICMBQJCAEBBAESigSqf4ImijsBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEdhk6CBQiCYoR0gmYugjEFlgaGSwGSRpEvk18BHzi?= =?us-ascii?q?BBFkVUgGERh0ZgUp1iHSBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.36,206,1486425600"; d="scan'208,217";a="221851181" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Mar 2017 22:45:40 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v2MMjerq015190 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 22 Mar 2017 22:45:40 GMT Received: from xch-rtp-012.cisco.com (64.101.220.152) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 22 Mar 2017 18:45:39 -0400 Received: from xch-rtp-012.cisco.com ([64.101.220.152]) by XCH-RTP-012.cisco.com ([64.101.220.152]) with mapi id 15.00.1210.000; Wed, 22 Mar 2017 18:45:39 -0400 From: "Satya Mohanty (satyamoh)" To: Susan Hares , "'idr wg'" Thread-Topic: [Idr] 2 Week WG LC for draft-ietf-idr-bgp-prefix-sid-04.txt - 3/6 to 3/20/2017 - extending to 3/31 Thread-Index: AdKiYoj5WABkkGMdRjO4hb7phG9PSQA4lhQA Date: Wed, 22 Mar 2017 22:45:39 +0000 Message-ID: <087B8E9A-8D4A-496E-8574-028B60FCDE77@cisco.com> References: <035901d2a263$a204a0c0$e60de240$@ndzh.com> In-Reply-To: <035901d2a263$a204a0c0$e60de240$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.154.161.68] Content-Type: multipart/alternative; boundary="_000_087B8E9A8D4A496E8574028B60FCDE77ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] 2 Week WG LC for draft-ietf-idr-bgp-prefix-sid-04.txt - 3/6 to 3/20/2017 - extending to 3/31 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 22:45:43 -0000 --_000_087B8E9A8D4A496E8574028B60FCDE77ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3VwcG9ydC4NCg0KVGhhbmtzLA0K4oCUU2F0eWENCg0KRnJvbTogSWRyIDxpZHItYm91bmNlc0Bp ZXRmLm9yZzxtYWlsdG86aWRyLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgU3VzYW4g SGFyZXMgPHNoYXJlc0BuZHpoLmNvbTxtYWlsdG86c2hhcmVzQG5kemguY29tPj4NCkRhdGU6IFR1 ZXNkYXksIE1hcmNoIDIxLCAyMDE3IGF0IDk6NTMgQU0NClRvOiAnaWRyIHdnJyA8aWRyQGlldGYu b3JnPG1haWx0bzppZHJAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtJZHJdIDIgV2VlayBXRyBM QyBmb3IgZHJhZnQtaWV0Zi1pZHItYmdwLXByZWZpeC1zaWQtMDQudHh0IC0gMy82IHRvIDMvMjAv MjAxNyAtIGV4dGVuZGluZyB0byAzLzMxDQoNCklEUiBXRzoNCg0KUGVyaGFwcyB0aGUgV0cgTEMg Y2FtZSBhdCBhIGJhZCB0aW1lIHNpbmNlIGhhdmUgcmVjZWl2ZWQgb25seSAxIHJlc3BvbnNlLiAg V2Ugd2lsbCBsZW5ndGggdGhlIGNhbGwgdG8gMy8zMS4gIFVubGVzcyB3aXRoIGhhdmUgc3Vic3Rh bnRpYWwgaW5wdXQsIHRoaXMgV0cgTEMgd2lsbCBub3QgaW5kaWNhdGUgY29uc2Vuc3VzLg0KDQpT dWUgSGFyZXMNCg== --_000_087B8E9A8D4A496E8574028B60FCDE77ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <0F90A4E14EF00F449BE3AA91DCA7E2E5@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2PlN1cHBvcnQuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGFua3MsPC9kaXY+ DQo8ZGl2PuKAlFNhdHlhPC9kaXY+DQo8ZGl2Pg0KPGRpdiBpZD0iTUFDX09VVExPT0tfU0lHTkFU VVJFIj48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8 c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6 Q2FsaWJyaTsgZm9udC1zaXplOjEycHQ7IHRleHQtYWxpZ246bGVmdDsgY29sb3I6YmxhY2s7IEJP UkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJ TkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGluOyBQQURESU5HLVJJR0hUOiAwaW47IEJP UkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQ QURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Gcm9tOiA8 L3NwYW4+SWRyICZsdDs8YSBocmVmPSJtYWlsdG86aWRyLWJvdW5jZXNAaWV0Zi5vcmciPmlkci1i b3VuY2VzQGlldGYub3JnPC9hPiZndDsgb24gYmVoYWxmIG9mIFN1c2FuIEhhcmVzICZsdDs8YSBo cmVmPSJtYWlsdG86c2hhcmVzQG5kemguY29tIj5zaGFyZXNAbmR6aC5jb208L2E+Jmd0Ozxicj4N CjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+VHVlc2RheSwgTWFy Y2ggMjEsIDIwMTcgYXQgOTo1MyBBTTxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xk Ij5UbzogPC9zcGFuPidpZHIgd2cnICZsdDs8YSBocmVmPSJtYWlsdG86aWRyQGlldGYub3JnIj5p ZHJAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5T dWJqZWN0OiA8L3NwYW4+UmU6IFtJZHJdIDIgV2VlayBXRyBMQyBmb3IgZHJhZnQtaWV0Zi1pZHIt YmdwLXByZWZpeC1zaWQtMDQudHh0IC0gMy82IHRvIDMvMjAvMjAxNyAtIGV4dGVuZGluZyB0byAz LzMxPGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdiB4bWxuczp2PSJ1cm46c2No ZW1hcy1taWNyb3NvZnQtY29tOnZtbCIgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNv bTpvZmZpY2U6b2ZmaWNlIiB4bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmlj ZTp3b3JkIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0 LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxtZXRh IG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1l ZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u RW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4g MTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjxkaXYgbGFuZz0iRU4tVVMiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPklEUiBXRzogPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBlcmhhcHMgdGhl IFdHIExDIGNhbWUgYXQgYSBiYWQgdGltZSBzaW5jZSBoYXZlIHJlY2VpdmVkIG9ubHkgMSByZXNw b25zZS4mbmJzcDsgV2Ugd2lsbCBsZW5ndGggdGhlIGNhbGwgdG8gMy8zMS4mbmJzcDsgVW5sZXNz IHdpdGggaGF2ZSBzdWJzdGFudGlhbCBpbnB1dCwgdGhpcyBXRyBMQyB3aWxsIG5vdCBpbmRpY2F0 ZSBjb25zZW5zdXMuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U3VlIEhhcmVzIDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_087B8E9A8D4A496E8574028B60FCDE77ciscocom_-- From nobody Wed Mar 22 15:48:30 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEE7712896F for ; Wed, 22 Mar 2017 15:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4KeQjdYHqWbR for ; Wed, 22 Mar 2017 15:48:22 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00F88128CFF for ; Wed, 22 Mar 2017 15:48:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5864; q=dns/txt; s=iport; t=1490222901; x=1491432501; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=qxoCZ1foA7lx423rBVjsTkeM2BcBHfbthXFOcjbKUFA=; b=H6Mnz7OSHOL9Y3WZ0jX26NK9SqusXsGjp8pARAbrNZPC2JMoRDZuBpqE YkJTAPRpPRsAlcyqpdzwMoOx+Ik/4xhIYNyqhyyu0mKbqqBFRDdTGcziU y5hLA3OuzDn1p9zx4WLSembyFsFmvFd0SsjSDVQ/m7K53vzIfGlkXR80a Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BvAgAW/tJY/4MNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5jYYEKB4Nbig+RQx+QGIUvgg6GIgIagxA/GAECAQEBAQEBAWs?= =?us-ascii?q?ohRUBAQEBAyMKXAIBCA4DAwECJAQDAgICMBQJCAEBBAESigSqf4ImijsBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEdhk6CBQiCYoR0gmYugjEFnFEBkkaRL5NfAR84gQR?= =?us-ascii?q?ZFUERAYRGHRmBSnWIdIENAQEB?= X-IronPort-AV: E=Sophos;i="5.36,206,1486425600"; d="scan'208,217";a="223672337" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Mar 2017 22:48:21 +0000 Received: from XCH-ALN-018.cisco.com (xch-aln-018.cisco.com [173.36.7.28]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v2MMmLCr010122 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 22 Mar 2017 22:48:21 GMT Received: from xch-rcd-019.cisco.com (173.37.102.29) by XCH-ALN-018.cisco.com (173.36.7.28) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 22 Mar 2017 17:48:20 -0500 Received: from xch-rcd-019.cisco.com ([173.37.102.29]) by XCH-RCD-019.cisco.com ([173.37.102.29]) with mapi id 15.00.1210.000; Wed, 22 Mar 2017 17:48:20 -0500 From: "Arjun Sreekantiah (asreekan)" To: Susan Hares , "'idr wg'" Thread-Topic: [Idr] 2 Week WG LC for draft-ietf-idr-bgp-prefix-sid-04.txt - 3/6 to 3/20/2017 - extending to 3/31 Thread-Index: AdKiYoj5WABkkGMdRjO4hb7phG9PSQA6xlwA Date: Wed, 22 Mar 2017 22:48:20 +0000 Message-ID: <9FD1D310-BE0C-4511-AD71-251B752F67A1@cisco.com> References: <035901d2a263$a204a0c0$e60de240$@ndzh.com> In-Reply-To: <035901d2a263$a204a0c0$e60de240$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.15.1.160411 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.154.161.167] Content-Type: multipart/alternative; boundary="_000_9FD1D310BE0C4511AD71251B752F67A1ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] 2 Week WG LC for draft-ietf-idr-bgp-prefix-sid-04.txt - 3/6 to 3/20/2017 - extending to 3/31 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 22:48:24 -0000 --_000_9FD1D310BE0C4511AD71251B752F67A1ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3VwcG9ydCBhcyBjby1hdXRob3IuDQoNCkFyanVuDQoNCkZyb206IElkciA8aWRyLWJvdW5jZXNA aWV0Zi5vcmc8bWFpbHRvOmlkci1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mIFN1c2Fu IEhhcmVzIDxzaGFyZXNAbmR6aC5jb208bWFpbHRvOnNoYXJlc0BuZHpoLmNvbT4+DQpEYXRlOiBU dWVzZGF5LCBNYXJjaCAyMSwgMjAxNyBhdCA5OjUzIEFNDQpUbzogImlkckBpZXRmLiBMaXN0IiA8 aWRyQGlldGYub3JnPG1haWx0bzppZHJAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtJZHJdIDIg V2VlayBXRyBMQyBmb3IgZHJhZnQtaWV0Zi1pZHItYmdwLXByZWZpeC1zaWQtMDQudHh0IC0gMy82 IHRvIDMvMjAvMjAxNyAtIGV4dGVuZGluZyB0byAzLzMxDQoNCklEUiBXRzoNCg0KUGVyaGFwcyB0 aGUgV0cgTEMgY2FtZSBhdCBhIGJhZCB0aW1lIHNpbmNlIGhhdmUgcmVjZWl2ZWQgb25seSAxIHJl c3BvbnNlLiAgV2Ugd2lsbCBsZW5ndGggdGhlIGNhbGwgdG8gMy8zMS4gIFVubGVzcyB3aXRoIGhh dmUgc3Vic3RhbnRpYWwgaW5wdXQsIHRoaXMgV0cgTEMgd2lsbCBub3QgaW5kaWNhdGUgY29uc2Vu c3VzLg0KDQpTdWUgSGFyZXMNCg== --_000_9FD1D310BE0C4511AD71251B752F67A1ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmk7Ij5TdXBwb3J0IGFzIGNvLWF1 dGhvci48L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+QXJqdW48L2Rpdj4N CjxkaXY+DQo8ZGl2IGlkPSJNQUNfT1VUTE9PS19TSUdOQVRVUkUiPjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlf U0VDVElPTiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTJw dDsgdGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5v bmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElO Ry1MRUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQg c29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNw YW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj5JZHIgJmx0OzxhIGhyZWY9 Im1haWx0bzppZHItYm91bmNlc0BpZXRmLm9yZyI+aWRyLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0 OyBvbiBiZWhhbGYgb2YgU3VzYW4gSGFyZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpzaGFyZXNAbmR6 aC5jb20iPnNoYXJlc0BuZHpoLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2Vp Z2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5UdWVzZGF5LCBNYXJjaCAyMSwgMjAxNyBhdCA5OjUzIEFN PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+JnF1b3Q7aWRy QGlldGYuIExpc3QmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzppZHJAaWV0Zi5vcmciPmlkckBp ZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1Ympl Y3Q6IDwvc3Bhbj5SZTogW0lkcl0gMiBXZWVrIFdHIExDIGZvciBkcmFmdC1pZXRmLWlkci1iZ3At cHJlZml4LXNpZC0wNC50eHQgLSAzLzYgdG8gMy8yMC8yMDE3IC0gZXh0ZW5kaW5nIHRvIDMvMzE8 YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJr Ol9NYWlsT3JpZ2luYWxCb2R5Ij4NCjxkaXYgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0 LWNvbTp2bWwiIHhtbG5zOm89InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmlj ZSIgeG1sbnM6dz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6 bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxu cz0iaHR0cDovL3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0 b3IiIGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHls ZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMg MiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFs LCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJn aW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlm XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi Pg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94 bWw+PCFbZW5kaWZdLS0+DQo8ZGl2IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J RFIgV0c6IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QZXJoYXBzIHRoZSBXRyBMQyBjYW1lIGF0 IGEgYmFkIHRpbWUgc2luY2UgaGF2ZSByZWNlaXZlZCBvbmx5IDEgcmVzcG9uc2UuJm5ic3A7IFdl IHdpbGwgbGVuZ3RoIHRoZSBjYWxsIHRvIDMvMzEuJm5ic3A7IFVubGVzcyB3aXRoIGhhdmUgc3Vi c3RhbnRpYWwgaW5wdXQsIHRoaXMgV0cgTEMgd2lsbCBub3QgaW5kaWNhdGUgY29uc2Vuc3VzLg0K PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlN1ZSBIYXJlcyA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvc3Bhbj48L3NwYW4+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_9FD1D310BE0C4511AD71251B752F67A1ciscocom_-- From nobody Wed Mar 22 16:10:27 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 541531293EE for ; Wed, 22 Mar 2017 16:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gscOWcixqrQc for ; Wed, 22 Mar 2017 16:10:24 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 37215126C83 for ; Wed, 22 Mar 2017 16:10:24 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=70.194.25.59; From: "Susan Hares" To: "'John G. Scudder'" , "'Eric Rosen'" Cc: References: <048701d29cd9$15204b80$3f60e280$@olddog.co.uk> <022201d29ce6$ffb2ba40$ff182ec0$@ndzh.com> <02dc01d2a25b$a1eca590$e5c5f0b0$@ndzh.com> <3b9c229a-4573-c586-8627-3a8c38539ff8@juniper.net> In-Reply-To: Date: Wed, 22 Mar 2017 17:48:17 -0400 Message-ID: <010401d2a356$045770c0$0d065240$@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: AQHgLJVhftftdlZ2OeQGM5dxbx7ZtQIfusEjApalZLoB3VIuCQJnQvCHApVdmPKhKc/YwA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] Thoughts on https://www.ietf.org/id/draft-hares-idr-bgp-registries-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 23:10:26 -0000 John: The NM/OPS has found the tool filter of Yang model tests goes well with the YANG Doctor's review. Sue -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of John G. Scudder Sent: Wednesday, March 22, 2017 2:37 PM To: Eric Rosen Cc: Susan Hares; idr@ietf.org Subject: Re: [Idr] Thoughts on https://www.ietf.org/id/draft-hares-idr-bgp-registries-01.txt Eric, First of all, I am going to assume we are talking about this goal (thanks, Adrian, for the nice summary): > 2. How to stop code point allocations through the normal IANA process > for "ideas that could use more review". Let's consider that to be the problem statement, replacing the Abstract and Introduction in the current draft. Sue's draft only covers registries that have what I suppose you'd call a lot of red tape to begin with -- Standards Action and IETF Review registries. The issue at hand is that although in theory these ensure plenty of review because they go through IETF last call, you may be shocked to learn that not everybody reviews every message sent to ietf@ietf.org in a careful and timely fashion. It's also interesting that you bring up the question of which WG "owns" which registry. ("Furthermore, a number of the mentioned registries were not established by the IDR WG, and I don't see that the IDR WG has any standing to request changes in the registration policies of those registries.") The problem at hand arises exactly when a spec is being progressed in one WG but allocating a code point from a registry "owned" by another WG. Guess what? There is no formal concept of a WG owning a registry so there's no formal way to address this. By the same token, it also means the concept of a WG having "standing to request changes" is inoperative. Sue's draft represents an attempt at retrofitting such a concept, and again, the reason is to try to ensure sufficient review happens before it's too late. A specific example of when this didn't happen is with the Entropy Label Capability Attribute allocated out of the BGP Path Attributes registry by RFC 6790, from the MPLS WG and later deprecated by RFC 7447 because it had a bug. IDR never touched the draft and the title of it ("The Use of Entropy Labels in MPLS Forwarding") wasn't likely to draw the eye of BGP folk. No amount of process will guarantee bugs don't slip through, but the hope is that it'd help sometimes without being onerous. Regarding your comments about politics, I disagree but don't intend to argue the point -- I'm not going to convince you. However, all of the registries Sue identified are already SA or IETF Review, and I think Adrian nailed it when he suggested: > b. Recognition that IETF consensus trumps DE opinion. Hopefully this > will never arise, but it is clear (or should be) that for a Standards > Action registry, if there is IETF consensus for an assignment, then > the DEs can warn and advise, but the will of the IETF takes precedence. RFC 5226 is happily flexible in the article of what a registry policy is: "It is not required that documents use these terms; the actual requirement is that the instructions to IANA are clear and unambiguous." So if we decide that what we want is, say, Standards Action with Expert Advice (I just made that up based on Adrian's observation that this isn't actually Expert Review according to the 5226 definition), then we can do that as long as we write it up clearly. In parallel, Job Snijders made a useful suggestion that idnits maybe should be on the lookout for code point squatting. This leads me to wonder if we aren't going at this wrong -- if instead of using the hammer of registry policy to ensure the right WGs have been notified, we should try the screwdriver of automated tooling. The idea is registries would still be marked up with parties interested in monitoring them, but there would be no formal changes to the requirements for allocation from the registries. Those monitoring the registries (e.g., the list of people in Sue's draft) would get notifications when an allocation was proposed -- as early as possible, but no later than when the draft was sent for IETF last call. The onus would fall on them to chime in (again, as early as possible) and the regular consensus process would take its course. I think this approach would be just fine and would seem to address your morbid fears of red tape, but it requires someone to go build some new tooling (I don't even know if there's an existing tool that can be pressed into service or if we're talking about an entirely new thing), whereas the registry policy proposal uses "tooling" that already exists. --John _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From nobody Wed Mar 22 16:21:12 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5C7F1293E4; Wed, 22 Mar 2017 16:21:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.126 X-Spam-Level: X-Spam-Status: No, score=-1.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MRi-zLU4kIsy; Wed, 22 Mar 2017 16:21:01 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-oln040092005052.outbound.protection.outlook.com [40.92.5.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D883B126C83; Wed, 22 Mar 2017 16:21:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=7GllvzVJHJCsR7NMfxnfKoozpp3uisBOYibag8NHy2M=; b=XNGIWeIAr3tTITupqKJvND1qrzAhO2gLsMivUyABTIE2CiTbsdMuNvYcnFDYxNa45a8b+GA5eOOqms34z7S4UuU3OHU3jbIqbWfNgaFH4Tyt2sS3FeABqTOxjUFc7m4UhWRopu9w2KMZDvhXflqL8eZwJ+BsUhcKetj71VwuVytT8lgrdioPVUgTNWnodr+mWIDGCsbxRGtr2ENlXpzgdt/iQVIclXBbjUd/xJ0XtEEpHieFf1qO52HCeAUBjcjwdCSX+4SOlyBgNmWA4WjcXKP105EFKTr/IHaBREV8lzcEMvHGmhf58IWZOv5ZL1eAX6KEM3RXAinDiaI2MgsdJQ== Received: from BL2NAM02FT061.eop-nam02.prod.protection.outlook.com (10.152.76.55) by BL2NAM02HT196.eop-nam02.prod.protection.outlook.com (10.152.77.244) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.977.7; Wed, 22 Mar 2017 23:20:59 +0000 Received: from DM3PR13MB0604.namprd13.prod.outlook.com (10.152.76.57) by BL2NAM02FT061.mail.protection.outlook.com (10.152.77.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.977.7 via Frontend Transport; Wed, 22 Mar 2017 23:20:59 +0000 Received: from DM3PR13MB0604.namprd13.prod.outlook.com ([10.164.8.150]) by DM3PR13MB0604.namprd13.prod.outlook.com ([10.164.8.150]) with mapi id 15.01.0991.013; Wed, 22 Mar 2017 23:20:59 +0000 From: Shitanshu Shah To: Ron Bonica , Susan Hares , "EXT - luis.tomotaki@verizon.com" , "rtg-dir@ietf.org" , "draft-ietf-idr-sla-exchange.all@ietf.org" , "idr@ietf.org" Thread-Topic: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 Thread-Index: AdKIcLCEU+uutt39QyCrZCwOKAXyLQAcLKCoAUVZnUABwWlZAABkf7iDAEubxBAAGLyHgADK0jWAAYwzjCAAeWPkSA== Date: Wed, 22 Mar 2017 23:20:58 +0000 Message-ID: References: , <053401d294fc$6f739180$4e5ab480$@ndzh.com> <467340A77F13C944919805BFF3B8ACFC30DC040408@FHDP1LUMXC7V91.us.one.verizon.com> <011601d2981f$cfe364c0$6faa2e40$@ndzh.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=hotmail.com; x-incomingtopheadermarker: OriginalChecksum:61D553F9DB1B85CDF0218AED8E8DB041BF18F8E86D9AB0036262161940AFF410; UpperCasedChecksum:06E542D2BE7D6F4499ED8C1550FA85A6BDF199207B4728C1E9066596284E81CD; SizeAsReceived:8999; Count:42 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [qPQgGrevDMYGhdjeJABvGjaBkxbYezui] x-microsoft-exchange-diagnostics: 1; BL2NAM02HT196; 5:AbpbjlMN8/KJ9S4t9hO2jSUac3lktxcErg0naeR7bYuRDnP3deZr5TU7XiAcVo37sryy6il7c+rRO5vsxxuZcmScSoe2pp6Q3OtQ39wqIQZMkPp7Vi+3rA8j+NPFMUtLPwB11ztO56TGh5vmSRTWsw==; 24:PMq5m6Wq/0gKe0ycPR9FtmrQ8/yGk14FmVXWBLq8GGR4vgyFDquT1XzzTAwVJbH8THD6iUqGTI1pcK+unJWVBmAghytlo5Zd4WIAbSsz0vE=; 7:cE1oP1ggv/m+blxalFva/QKLkLAVSaYp90z5z3VE2OXAuZEaUlUmeihV/0Awjd7NE2y+tQKDENBgHFOOuEMegRyiLloTDkCQid1Y9qYd/3RcHjvUiHBqGKfqwiTm+TSEjtg2mLnJ2mlYYlcQSbqark2iLCdOGWlUfcPPLHKjOVLpCbh5xhglmOjvL6zK8dYfA/z2KkbcMAX/xPIfK7YEwVNLSrwCkPlOuv3FCiRrL/eDNIYhbpAZ6bNWF4885xKzAFzHA02zfq0hvwVhh7OzaA2ACRlAkmKfxhYPC+lu+S2xSF/f86WMplns5JNULUF2 x-incomingheadercount: 42 x-eopattributedmessage: 0 x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(7070007)(98900017); DIR:OUT; SFP:1901; SCL:1; SRVR:BL2NAM02HT196; H:DM3PR13MB0604.namprd13.prod.outlook.com; FPR:; SPF:None; LANG:en; x-ms-office365-filtering-correlation-id: 591de4bf-b79c-4d90-cc6e-08d4717a1975 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320250)(2017031322250)(1603101448)(1601125374)(1701031045); SRVR:BL2NAM02HT196; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:BL2NAM02HT196; BCL:0; PCL:0; RULEID:; SRVR:BL2NAM02HT196; x-forefront-prvs: 02543CD7CD spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM3PR13MB06045C76EE74B0C6AA5EA941E53C0DM3PR13MB0604namp_" MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2017 23:20:58.8287 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2NAM02HT196 Archived-At: Subject: Re: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 23:21:04 -0000 --_000_DM3PR13MB06045C76EE74B0C6AA5EA941E53C0DM3PR13MB0604namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Ron, Thank you for your time and discussion with Luis. When SLA (now called TCA) consumer receives an advertisement, the consumer = SHOULD install the route without TCA specific advertised attribute in the = case it can not process TCA attribute. We will make it explicit in the docu= ment. If you have suggestion on a specific section where it should go and/or if h= ave a suggestion on a text, please suggest. Regards, Shitanshu ________________________________ From: Ron Bonica Sent: Monday, March 20, 2017 7:29 AM To: Susan Hares; EXT - luis.tomotaki@verizon.com; 'Shitanshu Shah'; rtg-dir= @ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; idr@ietf.org Subject: RE: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 Folks, Luis and I spoke on Friday. The following is a summary of our conversation: Draft-ietf-idr-sla-exchange proposes a mechanism through which a BGP speake= r associates a forwarding policy with a prefix. When a BGP listener receive= s an advertisement that is associated with a policy, it: - Instantiates the policy, if it does not already exist - Associates the prefix with the policy BGP listeners can instantiate a finite number of policies (N). SO, what ha= ppens when a BGP listener has N policies instantiated and it receives an ad= vertisement that would normally cause it to instantiate another policy? Opt= ions are: - Tear down the session - Discard the advertisement - Install the route, but without the advertisement - Do something else? We should probably be explicit about the required behavior. Ron From: Ron Bonica Sent: Sunday, March 12, 2017 12:11 PM To: 'Susan Hares' ; EXT - luis.tomotaki@verizon.com ; 'Shitanshu Shah' ; rtg-d= ir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; idr@ietf.org Subject: RE: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 Luis, This discussion might require a slightly higher bandwidth channel. Feel fre= e to call me whenever you get a chance. Ron 571 203 1= 704 From: Susan Hares [mailto:shares@ndzh.com] Sent: Wednesday, March 8, 2017 10:23 AM To: EXT - luis.tomotaki@verizon.com >; 'Shitanshu Shah' = >; Ron Bonica= >; rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; idr@ietf.org Subject: RE: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 Luis: Thank you for letting me know you desire for this feature. Since Ron had = additional questions, I=92ll let him start off this discussion. Sue From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Tomotaki, Luis M Sent: Tuesday, March 7, 2017 11:11 PM To: Shitanshu Shah; Susan Hares; 'Ron Bonica'; rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; idr@ietf.org Subject: Re: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 Ron and Sue, >From a service provider perspective, exchanging the SLA information between= the PE and CE would be very beneficial and could be widely used. I think = this is particular important in service provider=92s L3VPN networks where t= he customers or service providers currently do not have full visibility to = the QoS policy in the other end of the connection but still needs matching = CE-PE SLA/QoS policies to achieve the correct two-way traffic prioritizatio= n behavior during congestion. In this example, once the SLA information ex= change is standardized, my expectation is that the different CE/PE vendors = would be able to automatically update in a vendor specific way, the SLA/QoS= policies based on the SLA information provided via BGP. Luis From: Shitanshu Shah [mailto:shitanshu_shah@hotmail.com] Sent: Monday, March 6, 2017 9:31 AM To: Susan Hares >; 'Ron Bonica' >; rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; idr@ietf.org Subject: [E] Re: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 Hi Sue, Following is what I had responded to Ron. Hopefully that addresses/clarifie= s. To break it down in two point response, 1) This draft is not changing how SLA is established at first place. The dr= aft is providing a method to convey this a priori established SLA to help r= educe lot of manual complexities and errors to admin. Thus given a knowledg= e of what SLA is established, in general devices should be capable to suppo= rt that established SLA. 2) If there still are any issues in implementing exchanged SLA in forwardin= g, we think they either are implementation specific or of temporary nature = where for example enough resources not available at any specific point of a= time. We feel that in current state of the draft, it can be largely useful in dep= loyments. One can imagine though even establishment of SLA also can be done via excha= nging it over bgp. However, negotiation of SLA does not have to be clubbed = with exchange of SLA. Negotiation of SLA is not in this scope. Regards, Shitanshu ________________________________ From: Susan Hares > Sent: Saturday, March 4, 2017 8:31 AM To: 'Ron Bonica'; 'Shitanshu Shah'; rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; idr@ietf.org Subject: RE: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 Shitanshu: Please address Ron=92s comment about widely deployed. I believe this was p= art of Alvaro=92s comments. Sue From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Ron Bonica Sent: Thursday, February 23, 2017 12:07 PM To: Shitanshu Shah; rtg-dir@ietf.org; draft-ietf-i= dr-sla-exchange.all@ietf.org; idr@ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10 Hello, The draft is internally consistent. But given what is left out of scope, I = wonder if the new attributes will ever be widely deployed. = Ron This document might benefit from discussion of operational issues. I assume= that when a BGP listener learns a route with the SLA Exchange Attribute, i= t provisions class of service forwarding classes on interfaces. ##svshah, though this is one desired use of exchanging SLA content, the dra= ft focuses on transporting SLA content from the SLA Producer to the SLA Con= sumer. Processing of the QoS attribute content, at the SLA Consumer, is out= side the scope of this document. ##svshah, Let me know if you have a suggestion to make description clearer = in Section 1 and 2 to highlight this. I also assume that a) it takes time to provision class of service forwardin= g classes and b) the number of forwarding classes that can be provisioned a= re finite. What does the BGP listener do when the number of forwarding clas= ses requested exceeds its capacity to deliver? ##svshah, Since scope of the document is to transport SLA content from the = SLA Producer to the SLA Consumer, the document considers error handling in = the context of transporting data and thus any formating errors and semantic= s errors within that context. Any errors in the context of processing QoS a= ttribute content at the SLA Consumer is outside the scope of the document. --_000_DM3PR13MB06045C76EE74B0C6AA5EA941E53C0DM3PR13MB0604namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

    Hi Ron,


    Thank you for your time and discussion with Luis.


    When SLA (now called TCA) consumer receives an advertisement, the c= onsumer SHOULD install the route  without TCA specific advertised= attribute in the case it can not process TCA attribute. We will make = it explicit in the document.


    If you have suggestion on a specific section where it should go and/or i= f have a suggestion on a text, please suggest.


    Regards,

    Shitanshu



    From: Ron Bonica <rbonic= a@juniper.net>
    Sent: Monday, March 20, 2017 7:29 AM
    To: Susan Hares; EXT - luis.tomotaki@verizon.com; 'Shitanshu Shah'; = rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; idr@ietf.org Subject: RE: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-excha= nge-10
     

    Folks,

     

    Luis and I spoke on Friday. The fol= lowing is a summary of our conversation:

     

    Draft-ietf-idr-sla-exchange propose= s a mechanism through which a BGP speaker associates a forwarding policy wi= th a prefix. When a BGP listener receives an advertisement t= hat is associated with a policy, it:

     

    -          Instantiates the policy, if it does n= ot already exist

    -          Associates the prefix with the policy=

     

    BGP listeners can = instantiate a finite number of policies (N).  SO, what happens when a = BGP listener has N policies instantiated and it receives an advertisement that would normally cause it to instantiate another polic= y? Options are:

     

    -          Tear down the session

    -          Discard the advertisement

    -          Install the route, but without the ad= vertisement

    -          Do something else?

     

    We should probably= be explicit about the required behavior.

     

       =             &nb= sp;            =             &nb= sp;            =             &nb= sp;   Ron

     

     

    From: Ron Bonica
    Sent: Sunday, March 12, 2017 12:11 PM
    To: 'Susan Hares' <shares@ndzh.com>; EXT - luis.tomotaki@veriz= on.com <luis.tomotaki@verizon.com>; 'Shitanshu Shah' <shitanshu_sh= ah@hotmail.com>; rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.= org; idr@ietf.org
    Subject: RE: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-excha= nge-10

     

    Luis,

     

    This discussion might require a sli= ghtly higher bandwidth channel. Feel free to call me whenever you get a cha= nce.

     

          = ;            &n= bsp;            = ;            &n= bsp;            = ;         Ron

          = ;            &n= bsp;            = ;            &n= bsp;            = ;          571 203 1704=

     

     

    From: Susan Hares [mailto:shares@ndzh.com]
    Sent: Wednesday, March 8, 2017 10:23 AM
    To: EXT - luis.tomotaki= @verizon.com <luis.tomo= taki@verizon.com>; 'Shitanshu Shah' <shitanshu_shah@hotmail.com>; Ron Bonica <rbonica@juniper.net<= /a>>; rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; idr@ietf.org
    Subject: RE: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-excha= nge-10

     

    Luis:

     

    Thank you for letting me know you d= esire for this feature.   Since Ron had additional questions, I= =92ll let him start off this discussion.

     

    Sue

     

    From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Tomotaki, Luis M
    Sent: Tuesday, March 7, 2017 11:11 PM
    To: Shitanshu Shah; Susan Hares; 'Ron Bonica'; rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; idr@ietf.org
    Subject: Re: [Idr] [RTG-DIR] RtgDir review: draft-ietf-idr-sla-excha= nge-10

     

    Ron and Sue,

    From a service provider perspective= , exchanging the SLA information between the PE and CE would be very benefi= cial and could be widely used.  I think this is particular important in service provider=92s L3VPN networks where the cust= omers or service providers currently do not have full visibility to the QoS= policy in the other end of the connection but still needs matching CE-PE S= LA/QoS policies to achieve the correct two-way traffic prioritization behavior during congestion.  In this e= xample, once the SLA information exchange is standardized, my expectation i= s that the different CE/PE vendors would be able to automatically update in= a vendor specific way, the SLA/QoS policies based on the SLA information provided via BGP. 

     

    Luis

     

    From: Shitanshu Shah [mailto:shitanshu_shah@hotmail.com]
    Sent: Monday, March 6, 2017 9:31 AM
    To: Susan Hares <shares@ndzh.c= om>; 'Ron Bonica' <rbonica= @juniper.net>; rtg-dir@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; idr@ietf.org
    Subject: [E] Re: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchang= e-10

     

    = Hi Sue,

    =  

    = Following is what I had responded to Ron. Hopefully that addresses/cla= rifies.

    =  

    = To break it down in two point response,

    =  

    = 1) This draft is not changing how SLA is established at first place. The dr= aft is providing a method to convey this a priori established SLA= to help reduce lot of manual complexities and errors to admin. Thus given a knowledge of what SLA is established, in general de= vices should be capable to support that established SLA.

    =  

    =  

    = 2) If there still are any issues in implementing exchanged SLA in forwardin= g, we think they either are implementation specific or of temporary na= ture where for example enough resources not available at any specific point of a time.

    =  

    = We feel that in current state of the draft, it can be largely useful in dep= loyments.

    =  

    =  

    =  

    = One can imagine though even establishment of SLA also can be done via = exchanging it over bgp. However, negotiation of SLA does not have to be clu= bbed with exchange of SLA. Negotiation of SLA is not in this scope.

    =  

    Regards,

    Shitanshu

     

    From: Su= san Hares <shares@ndzh.com> Sent: Saturday, March 4, 2017 8:31 AM
    To: 'Ron Bonica'; 'Shitanshu Shah'; rtg-dir@ietf.org; draft-ietf-idr-= sla-exchange.all@ietf.org; idr@ietf.org
    Subject: RE: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10=

     

    Shitanshu:

     

    Please address Ron=92s c= omment about widely deployed.  I believe this was part of Alvaro=92s c= omments.

     

    Sue

     

    From: rtg-dir [mailto:rtg-dir-= bounces@ietf.org] On Behalf Of Ron Bonica
    Sent: Thursday, February 23, 2017 12:07 PM
    To: Shitanshu Shah; rtg-dir@ietf= .org; draft-ietf-idr-= sla-exchange.all@ietf.org; idr@ietf.org
    Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-idr-sla-exchange-10=

     =

    Hello,

     

    The draft is internally = consistent. But given what is left out of scope, I wonder if the new attrib= utes will ever be widely deployed.

     

        =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            = Ron

     

     


    This document might benefit from discussion of operational issues. I assume= that when a BGP listener learns a route with the SLA Exchange Attribute, i= t provisions class of service forwarding classes on interfaces.

     

    ##svshah= , though this is one desired use of exchanging SLA content, the draft focus= es on transporting SLA content from the SLA Producer to the SLA Consumer. P= rocessing of the QoS attribute content, at the SLA Consumer, is outside the scope of this document.

     

    ##svshah= , Let me know if you have a suggestion to make description clearer in Secti= on 1 and 2 to highlight this.

     

     

    I also assume that a) it t= akes time to provision class of service forwarding classes and b) the numbe= r of forwarding classes that can be provisioned are finite. What does the BGP listener do when the number of forwarding cl= asses requested exceeds its capacity to deliver? 

     

    ##svshah= , Since scope of the document is to transport SLA content from the SLA Prod= ucer to the SLA Consumer, the document considers error handling in the cont= ext of transporting data and thus any formating errors and semantics errors within that context. Any errors = in the context of processing QoS attribute content at the SLA Consumer is o= utside the scope of the document.

     

     

     

    --_000_DM3PR13MB06045C76EE74B0C6AA5EA941E53C0DM3PR13MB0604namp_-- From nobody Wed Mar 22 16:23:37 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8726C1270A7 for ; Wed, 22 Mar 2017 16:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-_s7F5xMSc5 for ; Wed, 22 Mar 2017 16:23:35 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 507F0126C83 for ; Wed, 22 Mar 2017 16:23:35 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=70.194.25.59; From: "Susan Hares" To: Date: Wed, 22 Mar 2017 19:18:24 -0400 Message-ID: <01c101d2a362$9b0feb80$d12fc280$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01C2_01D2A341.13FFAB10" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdKjYemMcYaL/ySSRFieixhO0TATbg== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [Idr] draft-ietf-idr-bgp-gr-notification - 1 week call for comments on early adoption (3/21 to 3/30) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 23:23:36 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01C2_01D2A341.13FFAB10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Greetings IDR: As John Scudder notes draft-ietf-idr-bgp-gr-notification-10.txt will be changed to have no suggested value. IANA is requested to assign a new subcode in the "BGP Cease NOTIFICATION message subcodes" registry. The suggested name for the code point is "Hard Reset". The suggested value is 9. Given this change, the IDR WG is asked to consider early code-point adoption for draft-ietf-idr-bgp-gr-notification, and any additions they wish to make on the last WG LC (which found consensus). With more details on 2 implementations (Cisco and Juniper), this will be forwarded to the IESG. If you wish to send any additional comments, since John is a co-authors - please send them to me or to Jie Dong. Jie will provide me a summary of comments he's received. Will Cisco and Juniper people, please update the wiki page on the implementation. The authors an provide a section in the draft (if they wish) with implementation - which will be removed before publication. Sue Hares ------=_NextPart_000_01C2_01D2A341.13FFAB10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Greetings = IDR:

     

    As John Scudder notes = draft-ietf-idr-bgp-gr-notification-10.txt  will be changed to have = no suggested value. 

     

     

       IANA is requested to assign a new subcode = in the "BGP Cease

       NOTIFICATION message subcodes" = registry.  The suggested name for the

       code point is "Hard = Reset".  The suggested value is 9.

     

    Given = this change, the IDR WG is asked to consider early code-point adoption = for draft-ietf-idr-bgp-gr-notification, and any additions they wish to = make on the last WG LC (which found consensus).   With more = details on 2 implementations (Cisco and Juniper), this will be forwarded = to the IESG.  If you wish to send any additional comments, since = John is a co-authors – please send them to me or to Jie = Dong.   Jie will provide me a summary of comments he’s = received.

     

    Will Cisco and Juniper people, please update the wiki = page on the implementation.   The authors an provide a section = in the draft (if they wish) with implementation – which will be = removed before publication. 

     

    Sue Hares =

     

    ------=_NextPart_000_01C2_01D2A341.13FFAB10-- From nobody Wed Mar 22 16:30:15 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D67C1270A7 for ; Wed, 22 Mar 2017 16:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yq2qwqkUCEti for ; Wed, 22 Mar 2017 16:30:11 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15703126C83 for ; Wed, 22 Mar 2017 16:30:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8445; q=dns/txt; s=iport; t=1490225411; x=1491435011; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=mcBm0fy/Jf3f0dByx3wPRwGxfQiQL35TBjCFZFqTPx0=; b=Iqzv23ZkxvkGuif+pEvTUVjC9j6Og+/f2+5CeVbwJByOXWxykG6RGLPf rfpNtT4clWeewL3m9g2aK4BznHK3vNA3KjMyRBRgXvsRrXNBteFM1+l/F woQdqcaDooXEKtCcJjRljsNstu7oHTKndvfnBf/RyCNv+6GtQxr4EB+Nb M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BJAQDLCNNY/5pdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5jYYEKB41qkWKQGIUvgg6GIgKDKj8YAQIBAQEBAQEBayiFFQE?= =?us-ascii?q?BAQEDHRBKEgIBCA4DAwECJAQHMhQJCAEBBAESigStJoo6AQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBHYs9hHSFRQWPXUGMMwGSRoF7hSqKCohViwoBHziBBFkVQTyEUoF?= =?us-ascii?q?KdYh0gQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.36,206,1486425600"; d="scan'208,217";a="401676228" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Mar 2017 23:29:54 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v2MNTsfb004792 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 22 Mar 2017 23:29:54 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 22 Mar 2017 19:29:53 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Wed, 22 Mar 2017 19:29:53 -0400 From: "Acee Lindem (acee)" To: Susan Hares , "idr@ietf.org" Thread-Topic: [Idr] draft-ietf-idr-bgp-gr-notification - 1 week call for comments on early adoption (3/21 to 3/30) Thread-Index: AdKjYemMcYaL/ySSRFieixhO0TATbgAAkkqA Date: Wed, 22 Mar 2017 23:29:53 +0000 Message-ID: References: <01c101d2a362$9b0feb80$d12fc280$@ndzh.com> In-Reply-To: <01c101d2a362$9b0feb80$d12fc280$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.198] Content-Type: multipart/alternative; boundary="_000_D4F88000A3C18aceeciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] draft-ietf-idr-bgp-gr-notification - 1 week call for comments on early adoption (3/21 to 3/30) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 23:30:13 -0000 --_000_D4F88000A3C18aceeciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Sue, Since early code point assignment is a topic in another thread and the spec= ter of bureaucracy was raised, I'd like to question as to why we need an ea= rly adoption call? Since the document has already been accepted as a WG d= ocument and there is implementation interest, isn't that enough to warrant = early code point adoption? Thanks, Acee From: Idr > on behalf of = Susan Hares > Date: Wednesday, March 22, 2017 at 7:18 PM To: IDR List > Subject: [Idr] draft-ietf-idr-bgp-gr-notification - 1 week call for comment= s on early adoption (3/21 to 3/30) Greetings IDR: As John Scudder notes draft-ietf-idr-bgp-gr-notification-10.txt will be ch= anged to have no suggested value. IANA is requested to assign a new subcode in the "BGP Cease NOTIFICATION message subcodes" registry. The suggested name for the code point is "Hard Reset". The suggested value is 9. Given this change, the IDR WG is asked to consider early code-point adoptio= n for draft-ietf-idr-bgp-gr-notification, and any additions they wish to ma= ke on the last WG LC (which found consensus). With more details on 2 impl= ementations (Cisco and Juniper), this will be forwarded to the IESG. If yo= u wish to send any additional comments, since John is a co-authors - please= send them to me or to Jie Dong. Jie will provide me a summary of comment= s he's received. Will Cisco and Juniper people, please update the wiki page on the implement= ation. The authors an provide a section in the draft (if they wish) with = implementation - which will be removed before publication. Sue Hares --_000_D4F88000A3C18aceeciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
    Hi Sue, 

    Since early code point assignment is a topic in another thread and the= specter of bureaucracy was raised, I’d like to question as to why we= need an early adoption call?  Since the document  has already be= en accepted as a WG document and there is implementation interest, isn’t that enough to warrant early code point adoption?&nb= sp;

    Thanks,
    Acee

    From: Idr <idr-bounces@ietf.org> on behalf of Susan Hares &l= t;shares@ndzh.com>
    Date: Wednesday, March 22, 2017 at = 7:18 PM
    To: IDR List <idr@ietf.org>
    Subject: [Idr] draft-ietf-idr-bgp-g= r-notification - 1 week call for comments on early adoption (3/21 to 3/30)<= br>

    Greetings IDR:

     

    As John Scudder notes draft-ietf-idr-bgp-gr-notifica= tion-10.txt  will be changed to have no suggested value. 

     

    Given this change, the IDR WG is asked to consider e= arly code-point adoption for draft-ietf-idr-bgp-gr-notification, and any ad= ditions they wish to make on the last WG LC (which found consensus). &= nbsp; With more details on 2 implementations (Cisco and Juniper), this will be forwarded to the IESG.  If you wish= to send any additional comments, since John is a co-authors – please= send them to me or to Jie Dong.   Jie will provide me a summary = of comments he’s received.

     

    Will Cisco and Juniper people, please update the wik= i page on the implementation.   The authors an provide a section = in the draft (if they wish) with implementation – which will be remov= ed before publication. 

     

    Sue Hares

     

     --_000_D4F88000A3C18aceeciscocom_-- From nobody Wed Mar 22 16:50:44 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A78F1128D19; Wed, 22 Mar 2017 16:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fi5vWmEX-vps; Wed, 22 Mar 2017 16:50:34 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 EE5E7127201; Wed, 22 Mar 2017 16:50:33 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cqq1Q-0000LC-T1; Wed, 22 Mar 2017 23:50:33 +0000 Date: Wed, 22 Mar 2017 18:50:32 -0500 Message-ID: From: Randy Bush To: "Sriram, Kotikalapudi (Fed)" Cc: "grow@ietf.org" , "idr@ietf.org" , "sidrops@ietf.org" , "draft-ietf-idr-route-leak-detection-mitigation.authors@ietf.org" , "sidr wg list (sidr@ietf.org)" In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Idr] [Sidrops] operator inputs -- route leak solution X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 23:50:36 -0000 > SIDR/GROW/IDR and well documented in IDR (see Section 4) > ( https://tools.ietf.org/html/draft-ietf-idr-route-leak-detection-mitigation-06 ). > The solution involves AS-A setting a field (in an optional transitive > attribute) glad you liked the attribute approach well enough to plagarize it from our draft. now you just need to change from misconfigurable statements of relationships to plagarize the bgp open part of our draft and your golden. randy From nobody Wed Mar 22 18:09:44 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 013341292F5; Wed, 22 Mar 2017 18:09:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CCO3WtYsAR8q; Wed, 22 Mar 2017 18:09:36 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C385128954; Wed, 22 Mar 2017 18:09:36 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id w124so32095238itb.1; Wed, 22 Mar 2017 18:09:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qtGpYjit16EONu0EM0Wx5kW3QiIcY7QDfJOGkqQtaJI=; b=imeni+XKvXGsUU5vlf/8RXUaCta7nnXAzPjdTM+BkAdRHUvZFjFOLr5XyWz8/aCRAy gNYMmxthjEOCdagRbhrmHzCedInHQaxSCv6N18LQnuJmPo/G7aOty5TEkuW2QUbHYwLI 8vVVcnnOtH2yaLSTkh2WtzsM4R5dB91ZERfn5Mu3axSzFvsSQ77SfIqLzxlMVxx2g7xq /jwgkELna0y0lIisGKeV13loiLr8IJ/uSuVXMY0KSQHIHx14ekjxv6sGQ7PYxcHwrR8f GZhGkU/OZLfVeaNz9dAGXe2O7m3YzXibI4vB35oXszn35ca+wEWfAk9mNefTnWBkXmsR elMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qtGpYjit16EONu0EM0Wx5kW3QiIcY7QDfJOGkqQtaJI=; b=MvBj4vWAv7Aivhv/v9wXKoI2LNi7unIY4COjM+h+EeYoCPm9UtwIUXsGPpSZyg0W6z 7d4HV0k8t+CzHLjx5sRR00QFkKzSbpfOD113p2KFW6MaPFrAWDTKj4Hqgn5er4Mc+BQW WXbQOfz1zEy4qZXEwfXNQqiNqWsLgjprHy46I+OadjofjGpqOXqBn701Ew5E6aAjmjGN 94H51/ltSIRw0Kmk5Nb140YaJcVNQGC90NXzTsapRYn48vdU3gaCk/UHS97i0QLATd26 Tl82ysbmn2eoUmA2EQA1qp2oSpmtp+oCfL/lIsIjA+iN220WjXpBDsQIAYjBkvWrfWtA QxQg== X-Gm-Message-State: AFeK/H1YBDj2CfyijOurR5zm5LQSB2deOcXkvCvzEAYkxssc3v9A6vyp97+8NAUSTAhS4VFyUX7nC+0x0ySUog== X-Received: by 10.36.102.195 with SMTP id k186mr338487itc.75.1490231375484; Wed, 22 Mar 2017 18:09:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.121.77 with HTTP; Wed, 22 Mar 2017 18:09:34 -0700 (PDT) In-Reply-To: References: From: Brian Dickson Date: Wed, 22 Mar 2017 18:09:34 -0700 Message-ID: To: Randy Bush Cc: "Sriram, Kotikalapudi (Fed)" , "grow@ietf.org" , "idr@ietf.org" , "sidrops@ietf.org" , "draft-ietf-idr-route-leak-detection-mitigation.authors@ietf.org" , "sidr wg list (sidr@ietf.org)" Content-Type: multipart/alternative; boundary=001a1147f558c4efba054b5b87e3 Archived-At: Subject: Re: [Idr] [Sidrops] operator inputs -- route leak solution X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 01:09:38 -0000 --001a1147f558c4efba054b5b87e3 Content-Type: text/plain; charset=UTF-8 On Wed, Mar 22, 2017 at 4:50 PM, Randy Bush wrote: > > SIDR/GROW/IDR and well documented in IDR (see Section 4) > > ( https://tools.ietf.org/html/draft-ietf-idr-route-leak- > detection-mitigation-06 ). > > The solution involves AS-A setting a field (in an optional transitive > > attribute) > > glad you liked the attribute approach well enough to plagarize it from > our draft. now you just need to change from misconfigurable statements > of relationships to plagarize the bgp open part of our draft and your > golden. > > Randy, With all due respect, your draft fails to acknowledge the earlier work by me (from 2012), outside of the recent drafts of which I am a co-author. Specifically: draft-dickson-sidr-route-leak-def (which became the basis for RFC 7908) draft-dickson-sidr-route-leak-reqts draft-dickson-sidr-route-leak-solns So, perhaps it would be best to avoid claims of plagiarizing, when (a) there is clear evidence that the source of the material predates your work, and (b) when your work does not credit the original work by me. Pot calling the kettle black, throwing stones in glass houses, and all that. You might want to also read those (expired) I-Ds, to get clarity on preserving leak prevention across "special" peering sessions They also cover the ability to prevent leaks, without requiring the disclosure of customer relationships -- something for which you have expressed a strong desire. FWIW, I will be working with my co-authors on the relationship-disclosure detail. Maybe we can schedule some white-board time in Chicago. Brian P.S. It is "you're golden". --001a1147f558c4efba054b5b87e3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    On W= ed, Mar 22, 2017 at 4:50 PM, Randy Bush <randy@psg.com> wrote:
    = > SIDR/GROW/IDR and well documented in IDR (see Section 4)
    > ( https://tools.ie= tf.org/html/draft-ietf-idr-route-leak-detection-mitigation-06= =C2=A0 ).
    > The solution involves AS-A setting a field (in an optional transitive<= br> > attribute)

    glad you liked the attribute approach well enough to plagarize it fr= om
    our draft.=C2=A0 now you just need to change from misconfigurable statement= s
    of relationships to plagarize the bgp open part of our draft and your
    golden.


    Randy,

    =
    With all due respect, your draft fails to acknowledge the earlier work= by me (from 2012), outside of the recent drafts of which I am a co-author.=

    Specifically:
    draft-dickson-sidr-route-= leak-def (which became the basis for RFC 7908)
    draft-dickson-= sidr-route-leak-reqts
    draft-dickson-sidr-route-leak-solns
    =

    So, perhaps it would be best to avoid claims of p= lagiarizing, when (a) there is clear evidence that the source of the materi= al predates your work, and (b) when your work does not credit the original = work by me.

    Pot calling the kettle black, throwing= stones in glass houses, and all that.

    You might w= ant to also read those (expired) I-Ds, to get clarity on preserving leak pr= evention across "special" peering sessions
    They also co= ver the ability to prevent leaks, without requiring the disclosure of custo= mer relationships -- something for which you have expressed a strong desire= .

    FWIW, I will be working with my co-authors on th= e relationship-disclosure detail.

    Maybe we can sch= edule some white-board time in Chicago.

    Brian

    P.S.=C2=A0 It is "you're golden".
    <= /div>
    --001a1147f558c4efba054b5b87e3-- From nobody Wed Mar 22 20:21:38 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55242129B28; Wed, 22 Mar 2017 20:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sp5gXmSgkcmj; Wed, 22 Mar 2017 20:21:30 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 F2AAC1200A0; Wed, 22 Mar 2017 20:21:29 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cqtJW-00022B-T9; Thu, 23 Mar 2017 03:21:27 +0000 Date: Wed, 22 Mar 2017 22:21:26 -0500 Message-ID: From: Randy Bush To: Brian Dickson Cc: "Sriram, Kotikalapudi (Fed)" , "grow@ietf.org" , "idr@ietf.org" , "sidrops@ietf.org" , "draft-ietf-idr-route-leak-detection-mitigation.authors@ietf.org" , "sidr wg list (sidr@ietf.org)" In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Idr] [Sidrops] operator inputs -- route leak solution X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 03:21:31 -0000 > With all due respect, your draft fails to acknowledge the earlier work by > me (from 2012), outside of the recent drafts of which I am a > co-author. apologies. this should be corrected, > So, perhaps it would be best to avoid claims of plagiarizing, when (a) > there is clear evidence that the source of the material predates your work, > and (b) when your work does not credit the original work by me. word for word From nobody Wed Mar 22 20:34:19 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 434EA129438; Wed, 22 Mar 2017 20:34:11 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QLtG7LG5bahH; Wed, 22 Mar 2017 20:34:09 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0099.outbound.protection.outlook.com [23.103.201.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21F9B12942F; Wed, 22 Mar 2017 20:34:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=HxYKCR7u8SHJhFeVh3X66vemla6rJNNjhuaPG4YnIXU=; b=v1/qajZTMRQTqSut/5/9HkDtBX3yl+5Y5wo2LgQ+nNEt/pS2hfDFcyqJKPsxNzpV4JINLRQDqB31vslvQMn/I+FB4mKwKYfeZxkLNX7fdAvjPIS+SFWEdBRGdPZjPnP/yIuLgCIH1glxps4B3NcrBo7iUy5YwP9DgD39cNbPcyw= Received: from DM2PR09MB0446.namprd09.prod.outlook.com (10.161.252.145) by DM2PR09MB0446.namprd09.prod.outlook.com (10.161.252.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.977.11; Thu, 23 Mar 2017 03:34:07 +0000 Received: from DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) by DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) with mapi id 15.01.0977.019; Thu, 23 Mar 2017 03:34:07 +0000 From: "Sriram, Kotikalapudi (Fed)" To: Randy Bush CC: "grow@ietf.org" , "idr@ietf.org" , "sidrops@ietf.org" , "draft-ietf-idr-route-leak-detection-mitigation.authors@ietf.org" , "sidr wg list (sidr@ietf.org)" , "idr-chairs@ietf.org" Thread-Topic: [Sidrops] operator inputs -- route leak solution Thread-Index: AdKia1LxrjWKYnevQ5+4FG+AD/ZO4wA+8SkAAAcwRBI= Date: Thu, 23 Mar 2017 03:34:07 +0000 Message-ID: References: , 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;ietf.org; dmarc=none action=none header.from=nist.gov; x-originating-ip: [129.6.223.1] x-microsoft-exchange-diagnostics: 1; DM2PR09MB0446; 7:Xccu20Y8r07osmhTSUZ30bPMWEDEhjFtGoI4CsC4/zxqB2q6l4lphtSdim1gAjaW5knchfQZeJeS2JW+Y5giwFgC4dET0h/VFKJNmoUQlhD85yTshL9m0YymTVXH4KNjQ1e2qWMkjXHVOtHvz6nyrIoMnJDYhXVvShh4Z1shpBN/3JeHpBcBj7sGcSaC7/OCE0nslHQZ+nNVk2xSJAFWVjpQCI+Bzgqts720SWTFuiGyU0paWT4ExMNtF2xb+R5AZI9ULGj5AjRIjLKN3T+R9AK6xPxj2Vtg78LN6UsHoEcoBnkoJK6WMAYuCY0p6E+eg66ULLRer1qelH813U8Ipw== x-ms-office365-filtering-correlation-id: c3754c7c-e977-4ff1-21c1-08d4719d7656 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081); SRVR:DM2PR09MB0446; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123560025)(20161123564025)(20161123555025)(20161123558025)(6072148); SRVR:DM2PR09MB0446; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0446; x-forefront-prvs: 0255DF69B9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39860400002)(39450400003)(39840400002)(305945005)(3846002)(7736002)(54356999)(50986999)(76176999)(4326008)(102836003)(229853002)(122556002)(6246003)(6116002)(38730400002)(77096006)(6506006)(2900100001)(3660700001)(99286003)(110136004)(66066001)(86362001)(3280700002)(53936002)(189998001)(8676002)(2950100002)(2906002)(6916009)(9686003)(6306002)(74316002)(54906002)(6436002)(81166006)(7696004)(55016002)(33656002)(25786009)(8936002)(5660300001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0446; H:DM2PR09MB0446.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM 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: 23 Mar 2017 03:34:07.3891 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0446 Archived-At: Subject: Re: [Idr] [Sidrops] operator inputs -- route leak solution X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 03:34:11 -0000 >> SIDR/GROW/IDR and well documented in IDR (see Section 4) >> ( https://tools.ietf.org/html/draft-ietf-idr-route-leak-detection-mitiga= tion-06 ). >> The solution involves AS-A setting a field (in an optional transitive >> attribute) >glad you liked the attribute approach well enough to plagarize it from >our draft. now you just need to change from misconfigurable statements >of relationships to plagarize the bgp open part of our draft and your >golden. Randy, To the response that Brian already offered,=20 I would like to add the following with due respect. Our version-00 working group draft was published July 22, 2015, and it stat= ed: " The proposed RLP encoding SHOULD be carried in BGP-4 [RFC4271] updates in an optional transitive path attribute. "=20 https://tools.ietf.org/html/draft-ietf-idr-route-leak-detection-mitigation-= 00 =20 =20 Your version-00 individual draft was published in March 2016.=20 Sriram =20 =20 From nobody Thu Mar 23 00:46:10 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EDAB131443 for ; Thu, 23 Mar 2017 00:46:04 -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, RP_MATCHES_RCVD=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rabk6hvtq1_M for ; Thu, 23 Mar 2017 00:46:03 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (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 AB8FE131446 for ; Thu, 23 Mar 2017 00:46:01 -0700 (PDT) X-Original-To: idr@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id C76E161840 for ; Thu, 23 Mar 2017 08:45:57 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 7294860B6B; Thu, 23 Mar 2017 08:45:57 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id 63BA16BA8F; Thu, 23 Mar 2017 08:45:57 +0100 (CET) Date: Thu, 23 Mar 2017 08:45:57 +0100 From: Gert Doering To: Nick Hilliard Cc: Gert Doering , "idr@ietf.org" , "grow@ietf.org" Message-ID: <20170323074557.GK2367@Space.Net> References: <20170321205513.GA2367@Space.Net> <20170322143302.GG2367@Space.Net> <58D2F5E7.80205@foobar.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="H8PKZwTLj31pggDC" Content-Disposition: inline In-Reply-To: <58D2F5E7.80205@foobar.org> X-NCC-RegID: de.space User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: Re: [Idr] [GROW] operator inputs -- route leak solution X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 07:46:05 -0000 --H8PKZwTLj31pggDC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Mar 23, 2017 at 12:08:39AM +0200, Nick Hilliard wrote: > Gert Doering wrote: > > If ISPs do not turn this *on* on their customer connections, it will not > > do anything - and given that those ISPs that *need* to turn this on are > > the ones that are not caring today, I'm still not seeing why they would > > turn this on tomorrow. >=20 > the asns unlikely to turn on a feature like this are leaf customers, > which is intentional. In a topology "Upstream1<->customer<->Upstream2" the filtering, aka=20 the "turning on of the new feature" needs to happen at both upstreams - both need to send the new attribute downstream, and filter prefixes=20 coming in from their customer with the new attribute. If either upstream doesn't turn this on on their session to "cutomer",=20 the mechanism will not work (and you can't make it default, as it would break upstream/peering sessions). Please explain to me how this is going to work if "lazy upstream ISP"=20 keeps being lazy, and does nothing. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --H8PKZwTLj31pggDC Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAljTfTIACgkQ31bAZeTO f8XO/BAAkZ8zJ3rDAnuiWgIDwJV+IgQt35zCnO/UrpkdLKsX9FXKpoKEZcBAC6bg BRhiiL6BVQldd2bILOVGRIhDhxY67p+HsfA3reRif3iNDp0GiFpPBmcW018SUCwf FEAEiz256WHsRamUTTVh+5JJsMqML1uec56kHb62AAgBS+Bx6vkDVh42JduM6Pmy D8BSuCqpmhGQGQoFpkIt4+3VcJUEfzxI+djWwI4SsUqsGKXdFd0tA9mazUWN2WqX mhG0O7ytCnj4eAF/3Q6jRHZnxxJ4giSYDzGeWipzKwsthG2BnNnG43cfsADrRLbr 6pE++9KcFdlQova3t0ER6kUeB2We7Ujadf+B2DB2JF0TjxKE8Ooo0QZ/itavJ262 qnqATlyxAm5zWCqrfxpA6UkSrcbKP8APltAkhYQtbwTJ34n3xGPN+S0CVWbfXGlR G5qTuyRaJ6+xYNSlkptdRNl4GJYv2bYlG9mfLVdBxNlCRDwA49jj7feNC+6K04lL dirCVOVUEEGEFdl5yHv+nQGPALlD/YUp9ZG2W/2aTe1Amd3Ngp+Lhs1/uiM9esd1 wnDbv0Ykf6ntr2VG8TtjMLKruJlxok4CWYFhTu6p+AAKoIB+mw7d4A5l0jCm+/UK fsRsOPEKQi1cBmwauWcMzwlevyYwlBZOIt5UskYRohhEIMoCWuI= =FGv/ -----END PGP SIGNATURE----- --H8PKZwTLj31pggDC-- From nobody Thu Mar 23 00:50:28 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4B27131746 for ; Thu, 23 Mar 2017 00:50:14 -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, RP_MATCHES_RCVD=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OMWQurooGSQW for ; Thu, 23 Mar 2017 00:50:13 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (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 D6A95131690 for ; Thu, 23 Mar 2017 00:50:10 -0700 (PDT) X-Original-To: idr@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 155DE619A5 for ; Thu, 23 Mar 2017 08:50:09 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 9D47D61565; Thu, 23 Mar 2017 08:50:08 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id 8EA3B6BACB; Thu, 23 Mar 2017 08:50:08 +0100 (CET) Date: Thu, 23 Mar 2017 08:50:08 +0100 From: Gert Doering To: Brian Dickson Cc: Gert Doering , "Sriram, Kotikalapudi (Fed)" , "grow@ietf.org" , "idr@ietf.org" , "sidrops@ietf.org" , "draft-ietf-idr-route-leak-detection-mitigation.authors@ietf.org" , "sidr wg list (sidr@ietf.org)" Message-ID: <20170323075008.GL2367@Space.Net> References: <20170321205513.GA2367@Space.Net> <20170322143302.GG2367@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="mO1Hs8HP9h3I4vdI" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: Re: [Idr] operator inputs -- route leak solution X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 07:50:15 -0000 --mO1Hs8HP9h3I4vdI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Wed, Mar 22, 2017 at 03:13:02PM -0700, Brian Dickson wrote: > There is direct benefit to partial (even very sparse) deployment. >=20 > The deployment is self-serving; whoever turns this on protects themselves > and their downstream customers. Those that are interested in doing so already do customer route filtering today. For those that are not interested, where's the incentive in starting to do so if you have to do a software upgrade first (*and* the other upstreams of your customers need to send this attribute)? > This becomes a differentiator with direct benefits, and creates market > pressure to deploy. A-ha. Right, exactly like "filter customer routes" is working today to give "market pressure". I always had the impression that *market* pressure is totally in favour of "accept everything from the customer, send down the pipe whatever you can, and then bill the customer for the traffic"... Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --mO1Hs8HP9h3I4vdI Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAljTfi8ACgkQ31bAZeTO f8W7hw//bAlzlXD1a6H3ecoJAHNUCg3o/AlWjKcwx4Uh8ztyMcRUoGvnLnQKozCU nnKc+9Eglx14VKwsLhikTkj4pd9cZd/xe+uY5HtQOo1DQR2jWQaA/HX28Vqg/PMS yNIpz0ePpFFNvjIwZjjFojuZSX6WNl4ulYauJOHwOJicnFC6Vqy71RbjasWgyZMO PQ6QP9FYOkOj9oAmG9rJQGY0rzGUk0QIA+n4VvhqWnqeGQlThyzYnVlDIvkfbQMd BpPJcCq7ftzY5uQHXDPQReX+VBTfbIKgt9ngHTW6DUIHCXOyBm0GJ541r+y2nail 4qyaTbPrEdFtMGttU7IsGseXTVAQgf454ts0N4M+AmuhkErO8J8otSHM15DrA7yB BVYk+c3zlnxhk15Q4oThG2kW5iYkYlBLDc4AaRILjK0cl6MKf33IAwU8wodsNwwS J0BWUucy+Flbu9pV6PT1u6122dLxSNBmPstZr3k+NGKLYqMBPtdTUsVSLxqSUhbj PwFWNcts8wTDGaU5vy7BW/spcrElnamsA4DYnNGt5D4Ya/YE2DsTAlGiC73bkakt Qj90NEdpwvE78EVKhMmNEGB6umP9q8D3UEqwVnh684zrVokV+Rw6GI5yQaRyuqnA x+dISBRm9qA/EQZDaSQsLf8rUcQRKa2fZRuxT+Os1ug1mO4uGlU= =yv6G -----END PGP SIGNATURE----- --mO1Hs8HP9h3I4vdI-- From nobody Thu Mar 23 03:23:53 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE7B213153A for ; Thu, 23 Mar 2017 03:23: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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vgOZrcilNMNn for ; Thu, 23 Mar 2017 03:23:50 -0700 (PDT) Received: from kangchenjunga.rtbrick.net (kangchenjunga.rtbrick.com [217.160.181.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DFE01314C1 for ; Thu, 23 Mar 2017 03:23:49 -0700 (PDT) Received: from hannes-mba.local ([::ffff:103.6.157.63]) (AUTH: PLAIN hannes, TLS: TLSv1/SSLv3,256bits,AES256-GCM-SHA384) by kangchenjunga.rtbrick.net with ESMTPSA; Thu, 23 Mar 2017 11:23:46 +0100 id 000000002873A016.0000000058D3A233.00001F47 Received: from hannes-mba.local (localhost [IPv6:::1]) by hannes-mba.local (Postfix) with ESMTP id B6F41278DFB6; Thu, 23 Mar 2017 11:23:43 +0100 (CET) Date: Thu, 23 Mar 2017 11:23:43 +0100 From: 'Hannes Gredler' To: Susan Hares Cc: idr@ietf.org, asreekan@cisco.com, "'Stefano Previdi (sprevidi)'" Message-ID: <20170323102343.5vwmsscdb6c4jiu4@hannes-mba.local> References: <00c501d296f2$a7a0c8f0$f6e25ad0$@ndzh.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: <00c501d296f2$a7a0c8f0$f6e25ad0$@ndzh.com> User-Agent: NeoMutt/20161002 (1.7.0) Archived-At: Subject: Re: [Idr] 2 Week WG LC for draft-ietf-idr-bgp-prefix-sid-04.txt - 3/6 to 3/20/2017 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 10:23:52 -0000 hi sue, rtbrick has an implementation for Label-Index and Originator SRGB as well; /hannes On Mon, Mar 06, 2017 at 10:26:47PM -0500, Susan Hares wrote: | Three implementations exist and the details are on the web site, and in | the draft: From nobody Thu Mar 23 06:00:23 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB29F1293F8; Thu, 23 Mar 2017 06:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.948 X-Spam-Level: X-Spam-Status: No, score=0.948 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, BODY_ENHANCEMENT=0.001, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F9lRRZcKlZu2; Thu, 23 Mar 2017 06:00:03 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 F20371296EA; Thu, 23 Mar 2017 06:00:02 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=70.194.9.114; From: "Susan Hares" To: "'Brian Dickson'" , "'Randy Bush'" Cc: , , , "'sidr wg list'" , References: In-Reply-To: Date: Thu, 23 Mar 2017 08:54:28 -0400 Message-ID: <02fa01d2a3d4$9bff4dc0$d3fde940$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02FB_01D2A3B3.14EEBF30" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFy2aVjjW9G+WpNY0ppJr8stM1gVQGcf8JwAoeB1GSiQNC3IA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] [GROW] [Sidrops] operator inputs -- route leak solution X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 13:00:07 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02FB_01D2A3B3.14EEBF30 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Brian, Sriram and Randy:=20 =20 =20 Let me suggest we take the rest of this discussion on these IDR two = drafts offline from IDR. The IDR Chairs noted when the = draft-ietf-idr-route-leak-detection mitigation was adopted that there = was overlap between you two documents. We also noted interests in both = technical approaches. We asked to you provide a combined document that = the chairs could present to the IDR WG. This IETF is a wonderful time = to work on this project. Chicago has many fine establishments in which = to discuss this combined document. =20 =20 I suggest we focused on the technical issues on the IDR mail lists. For = discussions of IDR on the grow list, I suggest that we listen to the = valuable input from the operators on what their needs and ask clarifying = questions. =20 =20 =20 Thank you,=20 =20 Sue Hares=20 =20 From: GROW [mailto:grow-bounces@ietf.org] On Behalf Of Brian Dickson Sent: Wednesday, March 22, 2017 9:10 PM To: Randy Bush Cc: idr@ietf.org; = draft-ietf-idr-route-leak-detection-mitigation.authors@ietf.org; = grow@ietf.org; sidr wg list (sidr@ietf.org); sidrops@ietf.org Subject: Re: [GROW] [Sidrops] operator inputs -- route leak solution =20 On Wed, Mar 22, 2017 at 4:50 PM, Randy Bush wrote: > SIDR/GROW/IDR and well documented in IDR (see Section 4) > ( = https://tools.ietf.org/html/draft-ietf-idr-route-leak-detection-mitigatio= n-06 ). > The solution involves AS-A setting a field (in an optional transitive > attribute) glad you liked the attribute approach well enough to plagarize it from our draft. now you just need to change from misconfigurable statements of relationships to plagarize the bgp open part of our draft and your golden. =20 Randy, =20 With all due respect, your draft fails to acknowledge the earlier work = by me (from 2012), outside of the recent drafts of which I am a = co-author. =20 Specifically: draft-dickson-sidr-route-leak-def (which became the basis for RFC 7908) draft-dickson-sidr-route-leak-reqts draft-dickson-sidr-route-leak-solns =20 So, perhaps it would be best to avoid claims of plagiarizing, when (a) = there is clear evidence that the source of the material predates your = work, and (b) when your work does not credit the original work by me. =20 Pot calling the kettle black, throwing stones in glass houses, and all = that. =20 You might want to also read those (expired) I-Ds, to get clarity on = preserving leak prevention across "special" peering sessions They also cover the ability to prevent leaks, without requiring the = disclosure of customer relationships -- something for which you have = expressed a strong desire. =20 FWIW, I will be working with my co-authors on the = relationship-disclosure detail. =20 Maybe we can schedule some white-board time in Chicago. =20 Brian =20 P.S. It is "you're golden". ------=_NextPart_000_02FB_01D2A3B3.14EEBF30 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

    Brian, Sriram and Randy:

     

    <IDR co-chair hat on>

    Let me suggest we take the rest of this discussion on these IDR two = drafts offline from IDR.=C2=A0 The IDR Chairs noted=C2=A0 when the = draft-ietf-idr-route-leak-detection mitigation was adopted =C2=A0that = there was overlap between you two documents.=C2=A0 We also noted = interests in both technical approaches.=C2=A0 We asked to you provide a = combined document that the chairs could present to the IDR WG.=C2=A0 = This IETF is a wonderful time to work on this project. = =C2=A0=C2=A0Chicago has many fine establishments in which to discuss = this combined document. =C2=A0=C2=A0

     

    I suggest we focused on the technical issues on the IDR mail = lists.=C2=A0 For discussions of IDR on the grow list, I suggest that we = listen to the valuable input from the operators on what their needs and = ask clarifying questions. =C2=A0

    <IDR co-chair hat off>

     

    Thank you,

     

    Sue Hares

     

    From:= = GROW [mailto:grow-bounces@ietf.org] On Behalf Of Brian = Dickson
    Sent: Wednesday, March 22, 2017 9:10 PM
    To: = Randy Bush
    Cc: idr@ietf.org; = draft-ietf-idr-route-leak-detection-mitigation.authors@ietf.org; = grow@ietf.org; sidr wg list (sidr@ietf.org); = sidrops@ietf.org
    Subject: Re: [GROW] [Sidrops] operator inputs = -- route leak solution

     

    On Wed, Mar 22, 2017 at 4:50 PM, Randy Bush <randy@psg.com> = wrote:

    > SIDR/GROW/IDR = and well documented in IDR (see Section 4)
    > ( https://tools.ietf.org/html/draft-ietf-idr-route-leak-d= etection-mitigation-06  ).
    > = The solution involves AS-A setting a field (in an optional = transitive
    > = attribute)

    glad you liked the attribute approach well = enough to plagarize it from
    our draft.  now you just need to = change from misconfigurable statements
    of relationships to plagarize = the bgp open part of our draft and your
    golden.

     

    Randy,

     

    With all due respect, your draft fails to acknowledge = the earlier work by me (from 2012), outside of the recent drafts of = which I am a co-author.

     

    Specifically:

    draft-dickson-sidr-route-leak-def (which became the = basis for RFC 7908)

    draft-dickson-sidr-route-leak-reqts

    draft-dickson-sidr-route-leak-solns

     

    So, perhaps it would be best to avoid claims of = plagiarizing, when (a) there is clear evidence that the source of the = material predates your work, and (b) when your work does not credit the = original work by me.

     

    Pot calling the kettle black, throwing stones in glass = houses, and all that.

     

    You might want to also read those (expired) I-Ds, to = get clarity on preserving leak prevention across "special" = peering sessions

    They also = cover the ability to prevent leaks, without requiring the disclosure of = customer relationships -- something for which you have expressed a = strong desire.

     

    FWIW, I will be working with my co-authors on the = relationship-disclosure detail.

     

    Maybe we can schedule some white-board time in = Chicago.

     

    Brian

     

    P.S.  It is "you're = golden".

    ------=_NextPart_000_02FB_01D2A3B3.14EEBF30-- From nobody Thu Mar 23 07:41:12 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E65E81297A8 for ; Thu, 23 Mar 2017 07:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.895 X-Spam-Level: X-Spam-Status: No, score=-4.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.796, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft1331857.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0JTFzrjUBdMT for ; Thu, 23 Mar 2017 07:41:08 -0700 (PDT) Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.164]) (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 99B9D129702 for ; Thu, 23 Mar 2017 07:41:04 -0700 (PDT) Received: from pure.maildistiller.com (unknown [10.110.50.29]) by dispatch1-us1.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTP id B319F8006E; Thu, 23 Mar 2017 14:41:01 +0000 (UTC) X-Virus-Scanned: Proofpoint Essentials engine Received: from mx3-us3.ppe-hosted.com (unknown [10.110.49.251]) by pure.maildistiller.com (Proofpoint Essentials ESMTP Server) with ESMTPS id A7C3D6004F; Thu, 23 Mar 2017 14:41:01 +0000 (UTC) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01lp0183.outbound.protection.outlook.com [216.32.180.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx3-us3.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 5B2096005A; Thu, 23 Mar 2017 14:41:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT1331857.onmicrosoft.com; s=selector1-arrcus-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=l3zi8ud2E/fX/KopiGLb6iswfT1Tb+zBUUE1HuqNoUY=; b=DtqiZ6YQwmYwQDHFihLgkUJRREsVqQASeBvYML1HzR0hBI1hZ4YCmD6NMTab8SZ1ZoFzAKBDpwNRZGA9zxP/LIZ0xdlaipykGfMEwQGwE7VaUgkPMqelEZcWtrfelNlBH8mbqumByaTkOpFCbRDiCjc1+1BbUkBgHYkencddFK4= Received: from BY2PR18MB0262.namprd18.prod.outlook.com (10.163.72.152) by BY2PR18MB0261.namprd18.prod.outlook.com (10.163.72.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.977.11; Thu, 23 Mar 2017 14:40:58 +0000 Received: from BY2PR18MB0262.namprd18.prod.outlook.com ([10.163.72.152]) by BY2PR18MB0262.namprd18.prod.outlook.com ([10.163.72.152]) with mapi id 15.01.0977.021; Thu, 23 Mar 2017 14:40:58 +0000 From: Keyur Patel To: Susan Hares , 'idr wg' Thread-Topic: [Idr] 2 Week WG LC for draft-ietf-idr-bgp-prefix-sid-04.txt - 3/6 to 3/20/2017 - extending to 3/31 Thread-Index: AdKiYoj5WABkkGMdRjO4hb7phG9PSQBRkYKA Date: Thu, 23 Mar 2017 14:40:58 +0000 Message-ID: References: <035901d2a263$a204a0c0$e60de240$@ndzh.com> In-Reply-To: <035901d2a263$a204a0c0$e60de240$@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;ndzh.com; dmarc=none action=none header.from=arrcus.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2601:646:8981:c940:fdf5:fc5f:c6eb:d953] x-microsoft-exchange-diagnostics: 1; BY2PR18MB0261; 7:BKFE7rHzCCy5HbaNCOsLw79LLbXhYGtsQ8FesjTC+Y4+y2QGm+LMEeAjBfGSkdBBoXRbsl7+2zCTXHTIXOzbeTPnAIszHJiXV3GC3JcBfq4exT+5LyrL2VrOhYMsHO9aiM4oSYm67Anz7VvPg1dlDTypd+5aAciAbaGN+u0l9oJ2NBB2xLydP5OD5JnEBaHcPHvxG/f53co5IO7KZdhy4aIijLm4VXBfxHUCHClRycHjqDDyscayDyLCY/aDp2Lm9bYx7bxpJiQ0LUpYHHHx1o9gfgQodC676zjrzbTRA8MBbe0y9CFSnB/AVJmqylR1t0dTB8W4eJY2s1lOjdbAXA== x-ms-office365-filtering-correlation-id: aa1315f8-aebc-401c-8f58-08d471fa9edd x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075); SRVR:BY2PR18MB0261; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(2016111802025)(20161123558025)(20161123564025)(20161123555025)(20161123560025)(20161123562025)(6043046)(6072148); SRVR:BY2PR18MB0261; BCL:0; PCL:0; RULEID:; SRVR:BY2PR18MB0261; x-forefront-prvs: 0255DF69B9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39410400002)(39450400003)(39830400002)(5423002)(377454003)(2906002)(189998001)(36756003)(5660300001)(86362001)(82746002)(6246003)(50986999)(76176999)(54356999)(2900100001)(53546009)(83716003)(3660700001)(53936002)(3280700002)(6512007)(25786009)(229853002)(122556002)(6506006)(7736002)(33656002)(6486002)(230783001)(77096006)(2950100002)(99286003)(38730400002)(6306002)(102836003)(54896002)(6436002)(6116002)(8676002)(8936002)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR18MB0261; H:BY2PR18MB0262.namprd18.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BB3C2B241C334C808C6F2B8A7373030Farrcuscom_" MIME-Version: 1.0 X-OriginatorOrg: arrcus.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Mar 2017 14:40:58.2161 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 697b3529-5c2b-40cf-a019-193eb78f6820 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR18MB0261 X-MDID: 1490280062-B02xupsKs2rY Archived-At: Subject: Re: [Idr] 2 Week WG LC for draft-ietf-idr-bgp-prefix-sid-04.txt - 3/6 to 3/20/2017 - extending to 3/31 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 14:41:11 -0000 --_000_BB3C2B241C334C808C6F2B8A7373030Farrcuscom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3VwcG9ydCBhcyBhIGNvLWF1dGhvci4NCg0KUmVnYXJkcywNCktleXVyDQoNCkZyb206IElkciA8 aWRyLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBTdXNhbiBIYXJlcyA8c2hhcmVzQG5k emguY29tPg0KRGF0ZTogVHVlc2RheSwgTWFyY2ggMjEsIDIwMTcgYXQgOTo1MyBBTQ0KVG86ICdp ZHIgd2cnIDxpZHJAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0lkcl0gMiBXZWVrIFdHIExDIGZv ciBkcmFmdC1pZXRmLWlkci1iZ3AtcHJlZml4LXNpZC0wNC50eHQgLSAzLzYgdG8gMy8yMC8yMDE3 IC0gZXh0ZW5kaW5nIHRvIDMvMzENCg0KSURSIFdHOg0KDQpQZXJoYXBzIHRoZSBXRyBMQyBjYW1l IGF0IGEgYmFkIHRpbWUgc2luY2UgaGF2ZSByZWNlaXZlZCBvbmx5IDEgcmVzcG9uc2UuICBXZSB3 aWxsIGxlbmd0aCB0aGUgY2FsbCB0byAzLzMxLiAgVW5sZXNzIHdpdGggaGF2ZSBzdWJzdGFudGlh bCBpbnB1dCwgdGhpcyBXRyBMQyB3aWxsIG5vdCBpbmRpY2F0ZSBjb25zZW5zdXMuDQoNClN1ZSBI YXJlcw0K --_000_BB3C2B241C334C808C6F2B8A7373030Farrcuscom_ Content-Type: text/html; charset="utf-8" Content-ID: <32A2182D1DD994459749474932D67F77@namprd18.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eTpDYWxpYnJpO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1h aWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OkNhbGli cmk7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRv d3RleHQ7fQ0Kc3Bhbi5tc29JbnMNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNv LXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFs O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0K CW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3 aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlN1cHBvcnQgYXMgYSBjby1h dXRob3IuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpSZWdhcmRz LDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+S2V5dXI8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+SWRy ICZsdDtpZHItYm91bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mIFN1c2FuIEhhcmVzICZs dDtzaGFyZXNAbmR6aC5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlR1ZXNkYXksIE1hcmNoIDIx LCAyMDE3IGF0IDk6NTMgQU08YnI+DQo8Yj5UbzogPC9iPidpZHIgd2cnICZsdDtpZHJAaWV0Zi5v cmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbSWRyXSAyIFdlZWsgV0cgTEMgZm9yIGRy YWZ0LWlldGYtaWRyLWJncC1wcmVmaXgtc2lkLTA0LnR4dCAtIDMvNiB0byAzLzIwLzIwMTcgLSBl eHRlbmRpbmcgdG8gMy8zMTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xv cjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JRFIgV0c6IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QZXJoYXBzIHRoZSBX RyBMQyBjYW1lIGF0IGEgYmFkIHRpbWUgc2luY2UgaGF2ZSByZWNlaXZlZCBvbmx5IDEgcmVzcG9u c2UuJm5ic3A7IFdlIHdpbGwgbGVuZ3RoIHRoZSBjYWxsIHRvIDMvMzEuJm5ic3A7IFVubGVzcyB3 aXRoIGhhdmUgc3Vic3RhbnRpYWwgaW5wdXQsIHRoaXMgV0cgTEMgd2lsbCBub3QgaW5kaWNhdGUg Y29uc2Vuc3VzLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlN1ZSBIYXJlcyA8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BB3C2B241C334C808C6F2B8A7373030Farrcuscom_-- From nobody Thu Mar 23 07:51:40 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B09E71294CF; Thu, 23 Mar 2017 07:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7WsX89OWpiX; Thu, 23 Mar 2017 07:51:31 -0700 (PDT) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB0CC126B72; Thu, 23 Mar 2017 07:51:30 -0700 (PDT) Received: by mail-wr0-x22c.google.com with SMTP id l37so149342841wrc.1; Thu, 23 Mar 2017 07:51:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=1BpgAPOAkYfbxkDw+k1f1jmn2bdQhqMKg3umU1HXWtU=; b=OGdSDQ2iFlqbTaAnP8Dh2h12qr8DtFLpX5dZIFObgxFH0M3u2+USS3zAY0yNYWpnz5 5sR1wawuNrcWznEN5c7g8V9VnJ3TUwK1Clvamq7XNKx3lMJWvS8vuZHV4Jmi6zfiR7Av bKuemrGdEFwhJBmKsPJo3lzOzO7kB0QEoZriDcWh/XvHcTasK6JLXcWxtnCb9HRRmwtg Ia1TTKP7lYqrnsDU3aUDIuHxLWBi0p96VStNg9gq9OwxV0gEx5XrZnV2RgKp0nEFUhli /zS2r/I8vYqS5NI5Qz0rCesaNXYkyAuW1Iz2SuR8AHueejjVAP4pqgpb2qWo/9sKHAEG +NTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=1BpgAPOAkYfbxkDw+k1f1jmn2bdQhqMKg3umU1HXWtU=; b=auUek8Cwrd0GdYEh75q2QKywdJXg/nXeuy80fW19LNzBWxq0cxCnbH2TJEdLS9tn0/ pT19uF7Tos4P4wrgKNpWvS3TQMhkWUsZvy8CF0EGzFHYurtGJJBT90xzX2Hzy162NrOv m4VwhrRbwZP6P5Sl5p+8ojM96wPt2cCdx/clpBDcpFUXRX57qJdUFNpYUq6JDI9mwlF3 PgsbTdg+t0H6lCOSVHN8BRhYFsFMN3ELNW4WjlbjdZsXXOFHCXnqZm+8H5V1GyOaCy3p TixcO9dcFlIDtsl2dHHhWwllu5HWnUQxGHte9gWvxR6b4sN6nANXXdACPuyU9TnyUKan zr6g== X-Gm-Message-State: AFeK/H0IP1zXdbn/mTOi4yCmvzJhY59jg+i1hWcteSOpiuaBlisa94zgc1kg2vy47xANvA== X-Received: by 10.223.150.205 with SMTP id u71mr2969022wrb.195.1490280689368; Thu, 23 Mar 2017 07:51:29 -0700 (PDT) Received: from ISOC-A1FD58.local ([147.67.241.226]) by smtp.googlemail.com with ESMTPSA id 92sm6162655wrh.8.2017.03.23.07.51.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Mar 2017 07:51:27 -0700 (PDT) To: Gert Doering , Nick Hilliard References: <20170321205513.GA2367@Space.Net> <20170322143302.GG2367@Space.Net> <58D2F5E7.80205@foobar.org> <20170323074557.GK2367@Space.Net> Cc: "idr@ietf.org" , "grow@ietf.org" From: Andrei Robachevsky Message-ID: <7d3b762d-6117-46a1-ef1e-3182b44a0cf7@gmail.com> Date: Thu, 23 Mar 2017 15:51:26 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170323074557.GK2367@Space.Net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tWG8Gv3Dg66oNAI41cb0Asi5vCAalxn9M" Archived-At: Subject: Re: [Idr] [GROW] operator inputs -- route leak solution X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 14:51:33 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --tWG8Gv3Dg66oNAI41cb0Asi5vCAalxn9M Content-Type: multipart/mixed; boundary="JkI6ubXM6xcrBXrnIMfWJkNKCmmnKLuri"; protected-headers="v1" From: Andrei Robachevsky To: Gert Doering , Nick Hilliard Cc: "idr@ietf.org" , "grow@ietf.org" Message-ID: <7d3b762d-6117-46a1-ef1e-3182b44a0cf7@gmail.com> Subject: Re: [GROW] [Idr] operator inputs -- route leak solution References: <20170321205513.GA2367@Space.Net> <20170322143302.GG2367@Space.Net> <58D2F5E7.80205@foobar.org> <20170323074557.GK2367@Space.Net> In-Reply-To: <20170323074557.GK2367@Space.Net> --JkI6ubXM6xcrBXrnIMfWJkNKCmmnKLuri Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Gert Doering wrote on 23/03/2017 08:45: > Please explain to me how this is going to work if "lazy upstream ISP"=20 > keeps being lazy, and does nothing. I agree. However the motivation for the proposed solution comes from the desire to fix the problem in the future when RPKI and BGPSEC are deployed, but neither of these technologies protects against leaks. In the meantime a lazy upstream ISP can still turn the check on, which is much easier than maintaining filters for their customers cone. Andrei --JkI6ubXM6xcrBXrnIMfWJkNKCmmnKLuri-- --tWG8Gv3Dg66oNAI41cb0Asi5vCAalxn9M 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 iEYEARECAAYFAljT4O8ACgkQljz5tZmtij/QbgCgxDVBr//VFv2ZtYbS4d8u8ZXY /C8AniN4JcTFJopw7AUt/nXYyGrzzh34 =kVYw -----END PGP SIGNATURE----- --tWG8Gv3Dg66oNAI41cb0Asi5vCAalxn9M-- From nobody Thu Mar 23 08:48:36 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD1C129495; Thu, 23 Mar 2017 08:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D9dHF6x3duA6; Thu, 23 Mar 2017 08:48:19 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 2194D129405; Thu, 23 Mar 2017 08:48:19 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cr4yG-0005uC-7t; Thu, 23 Mar 2017 15:48:16 +0000 Date: Thu, 23 Mar 2017 10:48:15 -0500 Message-ID: From: Randy Bush To: Gert Doering Cc: Interminable Discussion Room , sidrops@ietf.org, GMO Crops In-Reply-To: <20170322143302.GG2367@Space.Net> References: <20170321205513.GA2367@Space.Net> <20170322143302.GG2367@Space.Net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Idr] [Sidrops] operator inputs -- route leak solution X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 15:48:25 -0000 > If ISPs do not turn this *on* on their customer connections, it will not > do anything - and given that those ISPs that *need* to turn this on are > the ones that are not caring today, I'm still not seeing why they would > turn this on tomorrow. not quite. if ntt and l3 told fiber@home "on or befofe next jan 1st, have draft-ymbk-idr-bgp-open-policy enabled," (as they do with route: object reg); beyond that, l3, ntt, and fiber@home need to do no more. it's all in the open. the leak does not happen. imiho, the other draft with the transitive eOTR attribute (draft-ymbk-idr-bgp-eotr-policy) is not needed. it is a way to diagnose at a distance, and i prefer to stop at the source. randy From nobody Thu Mar 23 09:01:08 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4648127078; Thu, 23 Mar 2017 09:01: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ywvkC3z344Wl; Thu, 23 Mar 2017 09:00:59 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0111.outbound.protection.outlook.com [23.103.201.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FA29127369; Thu, 23 Mar 2017 09:00:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=cqTMTCg3DfEn7hMZE2JSUzBShcgS3qu+8A15hujWDpI=; b=bG7CufsIZb0DsmHArCGZh+zlVLO6wnAYv6qCmQBryc7c5dp2GNNWxVUdjenMGEYg7I6RXSx2Q7th7PoJ4tbed8WIuZUrebGhsSuIW37kdTYPnObRMNTXBFQZttiA6HulGajj6OnnI63vwHviaxbT6PH3rvLJ+iOTmDYw6EFG+uc= Received: from DM2PR09MB0446.namprd09.prod.outlook.com (10.161.252.145) by DM2PR09MB0446.namprd09.prod.outlook.com (10.161.252.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.977.11; Thu, 23 Mar 2017 16:00:53 +0000 Received: from DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) by DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) with mapi id 15.01.0977.019; Thu, 23 Mar 2017 16:00:53 +0000 From: "Sriram, Kotikalapudi (Fed)" To: "aa@qrator.net" , Randy Bush CC: IDR , GROW WG Thread-Topic: BGP Role capability questions (draft-ymbk-idr-bgp-open-policy-03) Thread-Index: AQHSo+jvP6hZpcGmrUeYJg4L0E9giw== Date: Thu, 23 Mar 2017 16:00:53 +0000 Message-ID: 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;ietf.org; dmarc=none action=none header.from=nist.gov; x-originating-ip: [129.6.218.117] x-microsoft-exchange-diagnostics: 1; DM2PR09MB0446; 7:OZEHsynHoaRawJ0WSxcKRMWoIz9cgVDnSdfAJHsWvTHeqCCO4JQrfzuGfmJq5bbOf9rYONaiTtqMqAHQKsW/X/kT+E5fVpMy4wEy2WAoJhXQbBhiYz5on9VqM4gniBBPR/10pMAYhuOGLjHGWjSJsiYm7Tes+FvatG2i32rpkjhwKB7MEczFDZdDdaT+gNez8wlwRWWEuBsvWcTCe6qzicN8yLVgDpJwpCbYVSndimMSwh5aRfFt8bo3qeWDJsNmMadGoEF5KkZY/4XUl36lUEQwdTmvEPasEogVTNzNwqQiApvXdL/AXpFkfjsqgCtVpLrTaECEYxqknLJE0BFTaw== x-ms-office365-filtering-correlation-id: 87bc6241-ebde-47d2-074b-08d47205c8df x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081); SRVR:DM2PR09MB0446; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(788757137089); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123562025)(20161123555025)(20161123560025)(20161123558025)(20161123564025)(6072148); SRVR:DM2PR09MB0446; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0446; x-forefront-prvs: 0255DF69B9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39840400002)(39410400002)(39860400002)(39450400003)(39850400002)(53936002)(561944003)(189998001)(8676002)(3280700002)(86362001)(3660700001)(66066001)(7736002)(99286003)(25786009)(33656002)(55016002)(7696004)(5660300001)(81166006)(8936002)(6506006)(2900100001)(9686003)(2906002)(6436002)(74316002)(54906002)(54356999)(2501003)(50986999)(3846002)(305945005)(122556002)(230783001)(102836003)(77096006)(38730400002)(6116002)(4326008); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0446; H:DM2PR09MB0446.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM 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: 23 Mar 2017 16:00:53.0520 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0446 Archived-At: Subject: [Idr] BGP Role capability questions (draft-ymbk-idr-bgp-open-policy-03) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 16:01:02 -0000 This is meant to be friendly feedback/questions on the BGP Role capability = proposal. I think the claim is automation, which I am trying to understand/appreciate= . My difficulty is that BGP Role negotiation does not seem self-sufficient. It still requires out-of-band (OOB) communication between operators to know= =20 the peering relationship, ASN, interface IP address, etc. before BGP OPEN = can be sent. Then only can the operator fill in their BGP Role in the enhanced BGP OPEN = message. Right? So, BGP Role capability only seeks to re-confirm, does not replace the OOB = part. I suppose, if the BGP Role messages contradict with each other=20 or with the prior OOB communication, the operators fall back on OOB=20 once again to fix the miscommunication. Further, for a "complex" relationship, the operators must inform=20 each other via the OOB communication, the exact sets of prefixes=20 for which they have different types of peering roles. The BGP Role negotiation does not assist in that process.=20 The per-prefix role info (for "complex") comes only from the OOB communicat= ion. Considering the above, the following key statements=20 in the Abstract (in the bgp-open-policy draft) do not seem entirely correct= : " This document enhances BGP Open to establish agreement of the (peer, customer, provider, internal) relationship of two neighboring BGP speakers to enforce appropriate configuration on both sides. Propagated routes are then marked with an iOTC attribute according to agreed relationship allowing prevention of route leaks." The enhanced BGP Open (or BGP Role capability) does not help in=20 marking iOTC in the "complex" peering case.=20 In that case, the OOB communication is all that is there to rely on.=20 The proposed BGP Role capability cannot verify/confirm that unless all=20 the per-prefix roles are also conveyed in the enhanced BGP Open message.=20 But that is not feasible, right?=20 The draft also does not cover all the mismatch conditions: (1) If the BGP role messages contradict each other =96 do you drop the sess= ion? (2) What is done if BGP role messages do not contradict each other but they= =20 contradict with the prior OOB communication, etc.? Thanks! Sriram From nobody Thu Mar 23 09:23:34 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B06512988D; Thu, 23 Mar 2017 09:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.696 X-Spam-Level: X-Spam-Status: No, score=-4.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MUr8bHckr_rn; Thu, 23 Mar 2017 09:23:31 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0123.outbound.protection.outlook.com [104.47.36.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A4631298AA; Thu, 23 Mar 2017 09:23:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=hSZHHoAn8c5FbjAAXNIF2ylT3DTbNjgof/bSu3jX+J0=; b=JinwipF8qJ84wMlW2JK+kXy3mvlkJv8pnjH45Xlj+aXQR6RRxmSTcufDgJj7lDPwcpX5EPUuC4+TtKfpGN931NwGtiOp1NQvs6F8YFQnfFvR5f1/tW6Yw+EUCeqgu21IpLLk82OiBm6VYfIqFzIgTLhHEhqk1H9rRWnAeUZTRj8= Authentication-Results: ndzh.com; dkim=none (message not signed) header.d=none;ndzh.com; dmarc=none action=none header.from=juniper.net; Received: from [172.29.37.164] (66.129.241.12) by SN2PR05MB2512.namprd05.prod.outlook.com (10.166.213.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.4; Thu, 23 Mar 2017 16:23:26 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_21E6FDD4-A249-45E8-9410-D1275124DE50" MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "John G. Scudder" In-Reply-To: <035901d2a263$a204a0c0$e60de240$@ndzh.com> Date: Thu, 23 Mar 2017 12:23:22 -0400 CC: idr wg Message-ID: <63EF8536-CD09-48A4-A425-CB1807CA31AE@juniper.net> References: <035901d2a263$a204a0c0$e60de240$@ndzh.com> To: Susan Hares , X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.12] X-ClientProxiedBy: BN6PR13CA0039.namprd13.prod.outlook.com (10.171.172.25) To SN2PR05MB2512.namprd05.prod.outlook.com (10.166.213.21) X-MS-Office365-Filtering-Correlation-Id: 015085d1-fe44-4aa4-c04c-08d47208efb8 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:SN2PR05MB2512; X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2512; 3:OU4zp88nCvQSGpE10UzDIX5KJXrMhgpe6DN2OEJEqHlomudA6hvYhoA+7T8+Srg64dkf6uwkUx9kKMFmLJuixRe0QcSgzGWDFeHdsVch342K6M72D2f5/VwkQWPa6HRtZKtTeq4Aizp6G+KYz+vk4hfeHWdUiWn6nAm48B636XZIbaPo4l0L/2qQ6ZLtyPCSnXY4Xlp3m9en+zRUbHjk686kuBu3XiN12j5bSCs5f0p+hrsTP1zSgvICq69KlH5jXJKXhAN9fyhp65jtw3050WZcNNWWqalUFoi4OyVZ9LM=; 25:kFg/Hjh5puqJPfPPkNxRgP2d5HnhCenNQYFT9PIcc5lOrZakvrNe/Mrbt+4k+CF6wexIZ3Z3wWoIEqzi4Kdr9t2om8e9uD8p8KjyaJ6XFMowxOeA5qtO/3gTFCc+OLju1UnpFqHR0phd+jQenJ8GcsyOxLkm+Z73Et8741LXB1SLbNJJkaxz0FCT5l7yZ9ILvESWq8Fawvio2WqlttrWcnz7ikQfFV6HjRha0AwHmzN8Yu/6y8Z7yr1ctbY0jVl/QM99tcAeAcnznfVFG7jXD3herLvIp5fY6P26HydneCYyUrZU53AZp+hQZjIWl/3r1nKIr+GlGcfeA9uZvv5EOE75wb8Ce7+G5JeH4c8MmHrP/5rjy6DPJsbRKJsMlsSCzpaHdJXHAiBFm8byS6gnPspQ78mhmKZlXnaUkVhxcxwptMBVhYDMr6yhVdkmAUgcBQ7aKHxICxQoV5EidJSSJA== X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2512; 31:sotuw+hcgqLPXv2y6PtrfLoBuHZnXAHg4tf2dVblZ++UkNMm7bEwfHYkVSDTx2qyNrpIFtn4FwkEcbh3jQYnhiNBexwOfYzmVFJWRahqgv41LUq4v5whhBCGz0iyMzhCbl0LyHhl5VKcm5pykNbV2nWoRscWGT2rVz3g5XYypDNBY5qlUJoDnR4g3TXlT1NLLlstwn4c6I8PE2nRMGbUlLLbJ3ACUQyBg4hokirqTipVBEU86xfAA8h6uY4p8tqEJq3hkaXfvT5doQolPHWuqjBKbBTn7eobu/4BaqFWPj0=; 20:j3aGOtolCWmr2lNd0v7BoB74EpjhwWgA7ILWgPfs7ob5/UCWUGLNVaGaKdl1iqBXeclSBTEZH6L/Ia7TuQSbIvoNzghCVkj3ahw1VJC5nLUNQeHPsDIcYVO13NEhFqyOcwTzXV2mL4QuMtAgyDEhZEpP7N6+PBNpS5RvOG1KdjVlQRUaNm5k4LAJE3PQjOZi6040u9XlBtyi7qimccG1Gk6t4Xl8WkG1jBYa62VPjW9+6GZYYWqWhN/QHzrxcQnnq+9Pcv6Pe3wKNVFrf/7z8ei346Vq9JkZIqU9Xt9uaMYwuX7IqQAzkGsoUJBoEZxUGaL9yhhLphs91nV3Soe14wM1VKTUs5AdA9ThMXVC1xGCFMdimIPYfxoIx+7SBamwfXMMtOdrhnkLFo2TS8Tckn0+SKdicJQDIoI+EpIO/Fx4kN+F8jz6S19FDOclNkUDNKN29DQZis7QhUycEqomkP9x+ST55c3JW6r70CuJZ/TLFhoWfFWi1sTOdQ+v6x/MKJuVEJOcL6t7tbdTLUeLRjOtIm+iIyuDfCi58wtiCosT5Z4uvaoMXdohIuDApRLF+WuciTduMqn9bU0coINwb+SnoUNHvy96zDI4v66eQ24= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123558025)(20161123555025)(20161123564025)(20161123560025)(6072148); SRVR:SN2PR05MB2512; BCL:0; PCL:0; RULEID:; SRVR:SN2PR05MB2512; X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2512; 4:m0ef+EfkI/So85md/NlL6gD2tWbw0ij8vVfDJAs9HslBIf9p6/Ty9UpgWZCrGFIik/8BNumUNSM/zgroKybl4X4m/7d41/u+p8//FBC+FYsDsEkwcT2z/NY0P2OUhXjlAfVCPv86l4eHFs7fOWA5/4erMoHgZbgYCkJKPpVQK1bxOyLZ2l2YJoVoJIYJYKDDOFucjnB9HP4r6A+wWKcatPrQfnJ5EwBB+5lW4ropemNm3SGd/Temx28LnZSESUeuubtvihyyGSugY0ncab60PzBoWYGbyTVfCz634UVvPUB5ILWJSmwGZ1ixvq9RPA5ZiOSLJ9ff2Iz3+p/xEVRrumB1iWqH5pIrVn0hj4mL4RxUzhYxqeDQ/G+2d+KywSi3vzeUlEdRvoTgZp5nBXz5zelMKyh0QmW9ZHg+OHU73wn3i2tG0OpIrlBAcIu+Hpml2gaCZUHX4wN9YWYAhpXSC9T2NJuI4zZdPELtqS5DenlzUjBMTIaFIQr8++nBxVK80z/aWbuwEJYwhvwqL1ciOhvObFegFU39WbiBPEHJjZ9QgEtMX+8dGNtmCIEA7JJPOwtpGJWZLHqJpP+PHDouNpqKwc+FJ29xErffaXMXMfPnL+5MhCBmdeyC4q2xCX3/ X-Forefront-PRVS: 0255DF69B9 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(39860400002)(39410400002)(39840400002)(39850400002)(39450400003)(5423002)(24454002)(377454003)(36756003)(5660300001)(260700001)(230783001)(189998001)(8676002)(76176999)(512954002)(84326002)(6666003)(42186005)(7736002)(38730400002)(50986999)(82746002)(6116002)(25786009)(3846002)(83716003)(4326008)(50226002)(86362001)(57306001)(2906002)(6246003)(66066001)(81166006)(2950100002)(33656002)(53936002)(229853002)(77096006)(90366009)(6486002)(236005)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR05MB2512; H:[172.29.37.164]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN2PR05MB2512; 23:dHiuTDYx/iAKPeje9XBcjyXNGtoR2pv2COqfz6NVQ?= =?us-ascii?Q?ZCCDKS+4Pl4t551ES6Ko1Rn9ILf2L45Ih02muHShh/vfh04P+ku0+5XC58J4?= =?us-ascii?Q?dJ+uR/4iRZyYx3CkG9tlV9vuXAF4YTO5TXyRReJAXcAIiCPgDPxOVMGtzirj?= =?us-ascii?Q?2T/YAyDKkoGxBGAH6d5FzPQ05Lm48co4EW1hcyS4VYt/kZFmZ21t9Y4w7D/r?= =?us-ascii?Q?wwO6UEInpZUcUVj5kGpF4+Z2H9ecDldsMQo52EqwtQa30nyJVLR1xV1dGxNL?= =?us-ascii?Q?FI9Xy47nOxRjQQQ6d6rj1/IS1tP8/TiBp3Zfl6LvMGUcLe1hU4qAgVr4/lCc?= =?us-ascii?Q?opAB4DSg4RJeY1Iq7RozBzpxDvtB3K5bTO7qPR/7G2jtXAoxmENY/ITW4FAG?= =?us-ascii?Q?276+8LYAUBOaYlG5+Q3v0G314XRCLRFmcg5uVzzST977QXGLb2tRE//1FItw?= =?us-ascii?Q?M1yE4r2nzXKMhz8mtgCtuM6ZUgS3ZGLlKToMxQJADb5EdHSJm1yGnA5T7hCa?= =?us-ascii?Q?XzFWzUbw+K/peKF0OhFvttivparetDAJ/eGcRmpOIErxqFb5Y7icJLCNpkp9?= =?us-ascii?Q?SrT7B/zRRgWb7GOF9JuEHsiZnCMHE86CTIVuZHzOqR9O6rJL2mrQqLgx206n?= =?us-ascii?Q?zSNX+MH4ye6+olWpI6/AnJJYtMaZILXYplLPfo+w0AdDk+RNeKDIDEbHmbLr?= =?us-ascii?Q?smLYCXhRQVWjNbRBn30vj6K3xbBuFuVrFhzRic94f/kV77/M7Vuz0Qvte688?= =?us-ascii?Q?GUEkgHB/5DHnqzUxscm3AaJevWYvLNZZSgsODnOnGr80Z+u9I34qCoQy7UYm?= =?us-ascii?Q?QHlXwqOx+mFg5kHPZo2NsKyxyJgFAnyD7fgcRZ9O9Vq49qsbE6wm5kTtN58H?= =?us-ascii?Q?iE0cq24nGvld0JpMWsdTrEtXBr66yavtp4j7sNvBvMvpUFe0HDE9D9Dq2CnD?= =?us-ascii?Q?6OA8RqjhA6Ix8CGMHQ3ZzfOpB0LTqqSN4AS62rxp5AjuMPkkvJBLzxSMxECe?= =?us-ascii?Q?nJlPqflPUkAWGh1GerLDXzDeMn9vteSSZiny6aFLyUz5MnBx/5/hVxyAxpwo?= =?us-ascii?Q?LtRFrWNTh1RBLBNUflRojCVupXDGVjBswaCapnFLM0yKoXodiFrj6ZMbStQ0?= =?us-ascii?Q?MlXan1UAzHFaheBjYSxmxOVb0wubgQH?= X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2512; 6:wAfF7MDxDPWBLav4qbz92zye2WZe/EbMozyNbEMe+IIZoUepfjKyrzUKPbpQB8wl5AahbHgewexpm3GJHB7qqVv2//CSXAL4BmgQUWvqkXmMAz6GdmYXR6I5n4wETSeUi4hJ03ugcQEYFXFKv/H9So55a+mlGbYiKq308EXZT2tw6+Z16U1D3r8Olywauio+FdEdwDm3qYBkGFUC1ffiUViibM4UyQLQFp/wqD9Wo1snOw6e9kwRKStsVrJDIARI5u/ImtSviuu+i0q0aClYuVk9mKeX9hShWEL4A/OOyuJucJGLXwaF9ZBt/R3RTcIFWKXd0jtQnzReV6zPr2KQNcJnYDYn3cWQdhl8iZT/ODdpMB3vmMHnl+0/n7leg+tV5auGptNIi29XCB/ER/6kFWgD/9oNRPXJbf0k3E54wlM=; 5:lNMTiij6PPyGPY08t8SLUa7IdcGGIwSt7MW41ZQSXL9cWF3e6a9SxnS8v2tkAOspoxbIop3HAn2Ey76CCUW8EO6uiN2cPBIsVM6euX/8BetfqFq43a517ah10iVDCqB+yTYopMbCoaNs9T27B8oByA==; 24:jRTCkUjufjeOVh/esaB2ydNqc3sKiH4k+l45smqTw0qv0PVfqS/NEB0vWnHJntH+zk7lWtLgr/d9FDMiQPk+8UnxSM1/yd+3q47fkDEsXF4= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2512; 7:gQnnJzgef+WdP4lMEBIxkYelOq+HwoQKDc4eYeMQjifjgeWzaxVUtBqRvj7inAr1n7XkLlijku+AANpI8ZwAvKJZPa9bUd/xdjHFOxWJMKw1nSGKG//PR1h002DjDoH5hZTHKMWCReNeLjSVQR450/Eqx6Qqcn5w3nhvoOf//J6AtsrYDq5HncC7Sjrqvt29zh9QP56rm8ehPLq7uTfEyL09aITWltcNx2M3/FTC1STuyRmf/t9Aevd8Dk+GYpbtNPW9DUgLbCN1B7SoT9ZAlBT5K0XddhoAxyL9rhW1p3rRAOU4M0BjwFOJ8WJDRVNhGIpPPSG1D+cstaM77nrmDw== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Mar 2017 16:23:26.8876 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR05MB2512 Archived-At: Subject: Re: [Idr] 2 Week WG LC for draft-ietf-idr-bgp-prefix-sid-04.txt - 3/6 to 3/20/2017 - extending to 3/31 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 16:23:33 -0000 --Apple-Mail=_21E6FDD4-A249-45E8-9410-D1275124DE50 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" One further point, on March 8, Bruno Decraene sent a list of comments = about -04 to the list (with x-post to spring). I've seen neither a reply = nor a new version to address his comments. One of those would be needed = before we could consider the WGLC closed. Thanks, --John > On Mar 21, 2017, at 12:53 PM, Susan Hares wrote: >=20 > IDR WG:=20 > =20 > Perhaps the WG LC came at a bad time since have received only 1 = response. We will length the call to 3/31. Unless with have = substantial input, this WG LC will not indicate consensus.=20 > =20 > Sue Hares=20 --Apple-Mail=_21E6FDD4-A249-45E8-9410-D1275124DE50 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii" One further point, on March 8, Bruno Decraene sent a list of = comments about -04 to the list (with x-post to spring). I've seen = neither a reply nor a new version to address his comments. One of those = would be needed before we could consider the WGLC closed.

    Thanks,

    --John

    On Mar 21, 2017, at 12:53 PM, Susan Hares = <shares@ndzh.com> = wrote:

    IDR WG: 
     
    Perhaps = the WG LC came at a bad time since have received only 1 response.  = We will length the call to 3/31.  Unless with have substantial = input, this WG LC will not indicate consensus. 
     
    Sue = Hares 

    = --Apple-Mail=_21E6FDD4-A249-45E8-9410-D1275124DE50-- From nobody Thu Mar 23 09:49:22 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E075C1298C8 for ; Thu, 23 Mar 2017 09:49:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 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, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=salesforce.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tAR9ZV-gPilL for ; Thu, 23 Mar 2017 09:49:18 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C08F612989D for ; Thu, 23 Mar 2017 09:49:18 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id l203so33941320oia.0 for ; Thu, 23 Mar 2017 09:49:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salesforce.com; s=google; h=mime-version:from:date:message-id:subject:to:cc; bh=3SvoAPc6NL8OxucDcqV2c+nAeY9yWMfvbQcpTbY1BJM=; b=eAR3xYkObzJ9tyPCk4G6m92UpxBbZ2bpDH0syE8GBd2LQfxVxFN15BNVrRsZ7zJhe8 sW1vwu+iXZw1wGXMY2QihvIb9uXyFNA5BoCvlyFUUmPwwvRPWKIeLowxS+zR4SlxHTS5 Eyr20bP6CrBmZyuhI1QRxPi47dMsYne/u8JVM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=3SvoAPc6NL8OxucDcqV2c+nAeY9yWMfvbQcpTbY1BJM=; b=bSOqxCsLDJMHQ/LoSpPys1NacCu+T2xTkDdi+bD1+uBrfkFyaBinJHzJkgj7b29LOC 75ZvkXHJsIq2UpHsF53HpxZkIxaS/EXv/S3WCR1eci5Vd7oQ1JkiO3q4TTDtdwsQt/I5 rsi7zhSZZiCuy4f6fnzsvgwZwexetytpoRUCGDEfv5EaUxKGK85VTzg5lvCz2GVrJw09 xVj6wnaFmauu/oxugD2TSkh1YB/wv+v5OjI0z5Es9LPO6F+xYL94MZ/qOtLnQ8hp9VUS 2WnhSqMaehIib83fZfeb+uiXW9djfcpVEV7LzFiUFGHfBxUQPFVORvOMauc3e+PycaOx TKyQ== X-Gm-Message-State: AFeK/H0Lkyh/5AAyddz1kFu0+6SyKjDj72kUkxjD6G1z4apSJ4MN0VSxX0phLroJr5s8KRwsLSXm89gpd9DplubW X-Received: by 10.202.0.141 with SMTP id 135mr1810879oia.166.1490287757775; Thu, 23 Mar 2017 09:49:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.108.161 with HTTP; Thu, 23 Mar 2017 09:49:17 -0700 (PDT) From: Edet Nkposong Date: Thu, 23 Mar 2017 09:49:17 -0700 Message-ID: To: idr@ietf.org Cc: shares@ndzh.com Content-Type: multipart/alternative; boundary=001a1137a09a6a93e1054b68a89f Archived-At: Subject: Re: [Idr] 2 Week WG LC for draft-ietf-idr-bgp-prefix-sid-04.txt - X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 16:49:21 -0000 --001a1137a09a6a93e1054b68a89f Content-Type: text/plain; charset=UTF-8 Hell, I am one of the Authors and Contributors of draft-ietf-spring-segment- routing-msdc and I support the draft. Regards, Edet Nkposong --001a1137a09a6a93e1054b68a89f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Hell,
    I am one of the Authors and Contributors of draft-ietf-spring-segment-routing-msdc=C2= =A0 and I support the draft.

    Regards, Edet Nkposon= g
    --001a1137a09a6a93e1054b68a89f-- From nobody Thu Mar 23 10:18:42 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37359127B73; Thu, 23 Mar 2017 10:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wDCK_9Zlpdva; Thu, 23 Mar 2017 10:18:38 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D421129B26; Thu, 23 Mar 2017 10:18:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1154; q=dns/txt; s=iport; t=1490289518; x=1491499118; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=YN4W6ueZXatnAf+aKMnLhuPuXWLbJGBWdhkp7qD5w9M=; b=TF/DPGVGR1PTDsDmQz+rsnOQoW9q7XMhwXvmxH7Ig2kPWRyw9/5Zr1uW mrTFEINBaFNdpHIuLYzTrWBFyXFk5jhyRmconGgIcylQ0sPVRk51rWjyF CDe2RXwdAK091gKQ2nS6ZIS26kbwZf98NLF+VB6NE/EBQHNOlum5x2vdr g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AIAgDmAtRY/4UNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1GBbAeDW4oPkU+VSYIOhiICGoJ8PxgBAgEBAQEBAQFrKIUVAQE?= =?us-ascii?q?BAQIBIxFFBQsCAQgYAgIfBwICAjAVEAIEDgWJfgiqPoImij4BAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEdgQuFQ4IFgmqEVIMGLoIxAQScVQGSSZEvk2EBHziBBFkVQRE?= =?us-ascii?q?BhEYdGYFKdYh8gQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.36,210,1486425600"; d="scan'208";a="227642802" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Mar 2017 17:18:36 +0000 Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v2NHIaml001705 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 23 Mar 2017 17:18:37 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-009.cisco.com (64.101.220.149) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 23 Mar 2017 13:18:36 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1210.000; Thu, 23 Mar 2017 13:18:36 -0400 From: "Stefano Previdi (sprevidi)" To: "John G. Scudder" CC: Susan Hares , "draft-ietf-idr-bgp-prefix-sid@ietf.org" , idr wg Thread-Topic: [Idr] 2 Week WG LC for draft-ietf-idr-bgp-prefix-sid-04.txt - 3/6 to 3/20/2017 - extending to 3/31 Thread-Index: AQHSo/mBWABkkGMdRjO4hb7phG9PSQ== Date: Thu, 23 Mar 2017 17:18:36 +0000 Message-ID: References: <035901d2a263$a204a0c0$e60de240$@ndzh.com> <63EF8536-CD09-48A4-A425-CB1807CA31AE@juniper.net> In-Reply-To: <63EF8536-CD09-48A4-A425-CB1807CA31AE@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.97.160] Content-Type: text/plain; charset="utf-8" Content-ID: <57C5CDAED88AFF44B4726709461C5C6D@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] 2 Week WG LC for draft-ietf-idr-bgp-prefix-sid-04.txt - 3/6 to 3/20/2017 - extending to 3/31 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 17:18:40 -0000 SGkgSm9obiwNCg0KeWVzLCBJIHN0aWxsIGhhdmUgdG8gYWRkcmVzcyBCcnVub+KAmXMgY29tbWVu dHMuIEkgd2FzbuKAmXQgYWJsZSB0byBkbyBzbyBiZWZvcmUgdGhlIHN1Ym1pc3Npb24gZGVhZGxp bmUgYW5kIEnigJlsbCBkbyBpdCBieSBuZXh0IHdlZWsuDQoNCnMuDQoNCg0KPiBPbiBNYXIgMjMs IDIwMTcsIGF0IDU6MjMgUE0sIEpvaG4gRy4gU2N1ZGRlciA8amdzQGp1bmlwZXIubmV0PiB3cm90 ZToNCj4gDQo+IE9uZSBmdXJ0aGVyIHBvaW50LCBvbiBNYXJjaCA4LCBCcnVubyBEZWNyYWVuZSBz ZW50IGEgbGlzdCBvZiBjb21tZW50cyBhYm91dCAtMDQgdG8gdGhlIGxpc3QgKHdpdGggeC1wb3N0 IHRvIHNwcmluZykuIEkndmUgc2VlbiBuZWl0aGVyIGEgcmVwbHkgbm9yIGEgbmV3IHZlcnNpb24g dG8gYWRkcmVzcyBoaXMgY29tbWVudHMuIE9uZSBvZiB0aG9zZSB3b3VsZCBiZSBuZWVkZWQgYmVm b3JlIHdlIGNvdWxkIGNvbnNpZGVyIHRoZSBXR0xDIGNsb3NlZC4NCj4gDQo+IFRoYW5rcywNCj4g DQo+IC0tSm9obg0KPiANCj4+IE9uIE1hciAyMSwgMjAxNywgYXQgMTI6NTMgUE0sIFN1c2FuIEhh cmVzIDxzaGFyZXNAbmR6aC5jb20+IHdyb3RlOg0KPj4gDQo+PiBJRFIgV0c6IA0KPj4gIA0KPj4g UGVyaGFwcyB0aGUgV0cgTEMgY2FtZSBhdCBhIGJhZCB0aW1lIHNpbmNlIGhhdmUgcmVjZWl2ZWQg b25seSAxIHJlc3BvbnNlLiAgV2Ugd2lsbCBsZW5ndGggdGhlIGNhbGwgdG8gMy8zMS4gIFVubGVz cyB3aXRoIGhhdmUgc3Vic3RhbnRpYWwgaW5wdXQsIHRoaXMgV0cgTEMgd2lsbCBub3QgaW5kaWNh dGUgY29uc2Vuc3VzLiANCj4+ICANCj4+IFN1ZSBIYXJlcyANCj4gDQoNCg== From nobody Thu Mar 23 10:29:26 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 559EF129463 for ; Thu, 23 Mar 2017 10:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.81 X-Spam-Level: X-Spam-Status: No, score=-1.81 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id heGvY965qZPI for ; Thu, 23 Mar 2017 10:29:18 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0137.outbound.protection.outlook.com [104.47.36.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 639CC129A5E for ; Thu, 23 Mar 2017 10:29:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=nMeKIJ2dk4Tt/jfBVyq6Hc2K/fdqgXYgrRDOF4gCop4=; b=JQAj8WTlNcDRFrtqxAeAc8ECC0mbw7yOq6Jd0D7HbIDqELy61I9cYQXcwb3GYs4Dk+aOp2RWAwHfhHsRDOge3uFAwgWuAoMV5H/Dn0l9zNmskbwTy9yqxEj8DAqFBL1195lN7eJNOA7Qwxrrf2gpBHnB2DBInIpqepdAxRGYQJk= Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=juniper.net; Received: from [172.29.33.229] (66.129.241.13) by SN1PR05MB2191.namprd05.prod.outlook.com (10.169.124.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.4; Thu, 23 Mar 2017 17:29:14 +0000 To: "John G. Scudder" References: <048701d29cd9$15204b80$3f60e280$@olddog.co.uk> <022201d29ce6$ffb2ba40$ff182ec0$@ndzh.com> <02dc01d2a25b$a1eca590$e5c5f0b0$@ndzh.com> <3b9c229a-4573-c586-8627-3a8c38539ff8@juniper.net> CC: Susan Hares , Adrian Farrel , From: Eric C Rosen Message-ID: Date: Thu, 23 Mar 2017 13:29:12 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------3F6C03EB6437AC531881BFD8" X-Originating-IP: [66.129.241.13] X-ClientProxiedBy: BN6PR1301CA0033.namprd13.prod.outlook.com (10.174.84.174) To SN1PR05MB2191.namprd05.prod.outlook.com (10.169.124.139) X-MS-Office365-Filtering-Correlation-Id: b2d754b8-267c-4d6e-120c-08d4721220d9 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:SN1PR05MB2191; X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2191; 3:rhYH2ZiPlA9zxq1gYg6rzciDZmSGGRr5zhbLZJmquXRLmc2viCTcKnnKXrFy6Lb7g0Gln5lkCbJyEIr6Jenj0bnuUA2MnCPn2Hnytjc4MyjtyfEmqRcEdPCEf9C/AgJI/czpZAguHWV90ejBNaT+L2qmN90JHaFoOUPWKCoCz6/tKG7lm8s19YNyuVxUImdPFEuwKaEFqisT2dAjcT6J1sZnj48MjxL0+/k2f0/n2mS7eGD+m6nv5/AO18ZdsCv8Pvwpeh850DQBtCj7WTdRK3Z+trhvgsGV9grWRugSHgY=; 25:l3PI66zP3sZA+0qZhODPZBb9FFtlh7b8khIfDHqwinRdW7CKDKd/x8R25RmENLxqEgj9hmyreY+BtT39Axw3tPWtxL9jwbc/p3EzKxrJQMhiQHXBfuVvV2ltfaK2t0dRQ4DFpNxKuKdvN7QPlVpiCbwKL7zz5oYDUo9sxEI2R9btWdMGjvGW5nyl2xl8x0Ihx2AtDDeSBoMcNLgSTg4nGfB6dFwa391I9+d4XBtCukbttNFeJANXcibZmYEUnoyULUZp2B5t5GERJK56LqoqvEV0NkQ8/jjzXrHQpl37d0zgNEce1Nz84gX/WEUy63gGqVudx6VUBQPbm1H8s+xdii3gYNIj1aZCd7f38lPOEatysbLFst+bz/bKNSLOSYnecvExYTJlX8pHsJF6PmTOjsOgEVL0joHpV8ghSUVKXB7KsBFU0PhHcr9TGi9H3n0NBzD2p6GyF2KgE/uNu9aynQ== X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2191; 31:HXFsE2WRBCG+Z/7sDLtUNtXSexF+zO/WY3F9F9iGOlHfqzVfXchG2syDKvKppd/ztnS5h0tX0/xyncWs4pqR6ORrAaLKrrwJRfnQjJFVjI+OscHW7w4pw5ozK65/AfQwh54s3UhlUbetUK9m88D4FPfROKUKLXVwiRP6eRJgI/uEl3C5XmGPcHm58G8iBmfFJVidMGR2GJTV01CgWtDCy+F504cxCH3rEWcmU/Zerc8=; 20:d04pt8U2bqazGHX9XshJNgl4au/uFsgBDwrSpikAXHyEXMfyyPMY3yT96RLrRRSKcZ1wA8jZq8FpoK59RTKxvBkFXx22/FMsRC40RKthQtT+RKb6MQCWUcxF3JOY/nTM6YDPGQkw17BiRNU1lSgCgQ7YYLQsLPi5uaIFgIRfDb0ZbFomKxP7IWsKNUUKeE0bgo1LbVYfQecF58cnL6LONNbyfbKXV4MiXun6X6KE0MkNlS/SZxp5kN4gElPtKW9lsJXV9+3aOGiMfPAjjoH3vTOVr2TQcgJMdyk/0CvjZJa7DmYBLXIP7GuHK9Ty/mhnRLnZeXrEn7lJQUtZbkuWe+YjbOkJBLjerqVdiduS9Jp8Os+Pt5AIUzOTSZu10QMUIbFn4Dl5QR2WJrI359tL0sRMTGG2XtthFOLmzMU5ptnuBoPcYDycV7TMHEw38TZAunDgJuWdJSLBeEcDoQ2uEjh6p4rro18Hv/4bP8De5IVwxLkJEMU4H5SYTrVCiQ7YBSHdhM9BaAKi46P9YtiCUBcOnLEqVs4EKQwrMl1IdUuVDMzTlW2TppzzKQVR5M+uyry9UXhxLHXcuPNk5Kc2C79uNwtYfVgzWTtBAKKc0tw= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(72170088055959)(192374486261705)(138986009662008)(100405760836317); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123555025)(20161123560025)(20161123558025)(20161123564025)(20161123562025)(6072148); SRVR:SN1PR05MB2191; BCL:0; PCL:0; RULEID:; SRVR:SN1PR05MB2191; X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2191; 4:HGdQt3Vn1RfMfCJM1qMKsU9iK5/aKoDCCZapin9Bf2VvIce37ef0ovD8wd1nIS8THZaclRXLl14VwXaI982W8LSq+0ZIUUHc+1nyttjVIwB+3t9TgQQjBo7f1cs6gvYQhJ4nlr6f7cNWRpEX8bM613Tp+5vfcbTrJD529jU4jmglF6gLcNyL5b1TxKtCZD5chmKXRBShw4NYdFh432/xjgQlA+o1MfZuqMQBKfq9ejpTay4EvOg9AV6R8s6lyZXAQKXODCKJks40aiOrJeHe49IDqohXQfmVV9u/ynb5qHE8O6YtfSe59I1HRI2ANuSXUnKKltuBJayNwReiFYCqgcmFdmgKRSv2cEnBLtXUm644AUSFmGViVMl0oD0heXfHwxTDSr7G2xcjJnqIgN1z4gQzvbM5xHSu8Xje4SHkLhrvu7gD1JjuIHmbpzGU3qfxxGTIsYtCzfII222OkcDVV7/b48AOonrybZHiww6EX2w9EtROFDiHs9YTPgWjDa2ZWMRsEjaPBdI3OkR3V4+1LmdCmKLa/Zobzg/fO3PRnrGrqMxWa/sACSuc+vOcDrRYJhce/y4K37jqVcilb1E83hOHU4NxumSEbFMno28kliiZ4TWHi9KD3DeqHYvyKjTy2LbcOr+YbbmpJ0NDBX8Rb41aiZugbfPY4nqSlZCqaALwT2X+yLplQKXUInCwYZXqGngJlMeQHSLBBku0kbjE6Xy3q6ZW797A/kYkjFdh28NS8SuBp2cUQRRJ0mDAE5wjUCFAQ2lLrihXp9IMt0dBBg== X-Forefront-PRVS: 0255DF69B9 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(39450400003)(39840400002)(39860400002)(39850400002)(39410400002)(24454002)(377454003)(2906002)(90366009)(54906002)(33646002)(65806001)(25786009)(6486002)(4326008)(77096006)(53546009)(3260700006)(6862004)(230783001)(86362001)(65956001)(66066001)(189998001)(53936002)(64126003)(110136004)(38730400002)(6246003)(1941001)(65826007)(93886004)(42186005)(31686004)(561944003)(512944002)(31696002)(83506001)(36756003)(6116002)(3846002)(7736002)(5660300001)(229853002)(6636002)(2950100002)(54356999)(50986999)(76176999)(270700001)(84326002)(8676002)(81166006)(163123001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR05MB2191; H:[172.29.33.229]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN1PR05MB2191; 23:/PGnRBETkf8THKtxCPhT4fjmdPjxjAmWlWtvdKnEl?= =?us-ascii?Q?MdyMMW6glxTsbmZgYVMoxFQu0DLfwT3PvslA5KtyQEnbJ1AXwM2qQExLVUNO?= =?us-ascii?Q?WotAublnfIPihHw+jjbVVH6aRV63kPJfulbF2n6ylPKf/8yJlbhImDtjf6sG?= =?us-ascii?Q?FcND+XzPgp9JTYPlw3KTY6camMZ5dKI2kNV+2HhlP09gsTLTb3FnQWHs+X26?= =?us-ascii?Q?XKS1bmkADRnuFrFdcelcamTnaiPIqPMBSDP5QPv89QLdkKPIDSR2uZ4onhH5?= =?us-ascii?Q?/gtswJ8UHO7pz5ESql4+S8A1bsgG0/nri1JE460Qt9D8qUXyp3nGlv/6Sjg/?= =?us-ascii?Q?2mKoEU2YPxRROdxiHGctqvkmGeePln5rhBealc5Z2PE8b7ifenUckLVS+hLt?= =?us-ascii?Q?IUZ4FQ48CEWk8/I/A6kOBPD3ewNx1zlgpS1VVgywd0OZ6vSOsmYxhomVeWAB?= =?us-ascii?Q?LvOunjTahtazQ7dTMh00O6ecjVUPmaSmsg74JgEtlbH70ka1XxMwU8Jd6NYk?= =?us-ascii?Q?/nom2ExfiGpbzodrOTkXDA+1ySZKur5XIPYFmtYbI0Ql+AiQsKY0ZQTPqEzi?= =?us-ascii?Q?ROaEu0OXaI8XH5+8O6c5DXsH5CDf+nc6LluxU4lrxqW25lDFhCkf5Bm5jXiu?= =?us-ascii?Q?TbU+4+u4uhuQZIphQLI9ufHsZhn0EFFOxRj5Ix47RHzmsXMHVTq4h0Chn4t2?= =?us-ascii?Q?F/Xpizj0v0NLJwvl0OR2JvnxQboHNF1Koe5iyBIOE5gmfmtObFf3e41Q4lVT?= =?us-ascii?Q?NbaR5gxgpy6E+dnzgcOwqOkkhp5LoksaingQ4zr6sKWcvADp26iIGl/Nl9N9?= =?us-ascii?Q?QMr5VEKELqhEGtgk3X3C1r0SdNLi6ZJ3cyxzV63QKJ6eu7TiG2d3ykqbimvX?= =?us-ascii?Q?GvczMiSDDQ8GIZrJ87HcEUFWzSPUdzTCOZV6FHPxnXJHcoCG0xd2ZXQGLfIe?= =?us-ascii?Q?7PU/1phpaCCvYd6TTcKO9uPAyf7CDpNv/YKRIUW6x66dfGBSfCREore6/yMv?= =?us-ascii?Q?1cyDXXa+KpXE/BOhz9ZHac07bZH4BntktcWf/ogfLxm78QPPyeeKzXC2q1ex?= =?us-ascii?Q?0MiUWkcNfYltCuy28UbCV4X6KTdgmr9SX0+5cYJbR8MNESsdJrG+ex0zfMm2?= =?us-ascii?Q?y9VGCKPftSVryL28MbZm02PH8n/0HpFaasgnfQemJmaE+0eY8tlw5r0/xprV?= =?us-ascii?Q?+jX2HAW5d7SHd7Fr2xw+Ondq/Srsuty2Ag/L5xW+Xu8XzBrze0IVP60xTc39?= =?us-ascii?Q?7jMgcA3CbANoAXhazoDzSLxhKQHUQCBPbhIOO6Thrb0HVDL3r3o8ASJ+PAo4?= =?us-ascii?Q?1SQE38rULDZDy3Ca6GJZkRE+nKZ3HqGg/pwWcqRSGoD+biYrZ5N5Mlufp2wA?= =?us-ascii?Q?VHNSj89+oKal3KqJFzA4Gj/h7s=3D?= X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2191; 6:ky7mVzkX66K4qQSOUB/4Pnlr0gs5paTSF8ctve78p5TkYGdfV3grk/ZsOKSS8DMz9YmQ4Bxgc+9KaWvESUaKIEbr/yPwxpjMz3sSMhul9ruRIJ4LEHjToWaO/WIs7H086J2BzNKLPkYrSnnqtvmammoarAye++yu2X3AROr6qxG8q5cA61dNPVYn3cP5hmeXUgT0u1aQOahOyGplcZ0lvLUhvwh9NXwg9BBAFRe6HYvhud2MTgbWTV2AACbvkyQxRTmhK1cJC6oWAHjZ6cuuHxoswEhdC29HHn/5fPovl5liR/QY7+5IGCtw6pffqNmDRlEYBQZCvrnS8dAsY7n+Y/9kzrJZIc+7F6TvABI1TeKsfoIX1FGCHBxDpl5Jf2gRtLiodHqk+R/RoEXe6BwxuUZidgMtAsULWSA0ZWuXcdU=; 5:RwAgu1w3BQzAdD9OjOkvNBpdtEFfbldVPt3xTJC6DJZ9nrQjdhYWnWp+yKwfB7kFuuxiLmrDF8mjKmlKQ4N7M+FprtzecCMTpvq+u29mcHcUnd4I8igYEE9mJv4hUz7ZtN7wwiEaE9NynkGlQJIa+Q==; 24:MYq3BxhD0ft7f8EHqDZZUqDB/VIJvg/6LP9yuV5Dz6qY4L4wzioczQktDMgmB2pYpw3qbkufa9xIZrw3zh9gxop/xTDxipvEYgY2ARLqv08= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2191; 7:OyMuAhlZ5l/E2Ed9zbnB8LwfIENPMiCFc0IbPub9YYEMAUSJn6txViExBOc7tblE0vhiubc115rI5kntk6l2puXeBZwUHqpf26+abgWlQ9LIT1IReShLhCSr7aCpGLAMQjO6dAUBiEe84JVMB4p6zXzlyF8tRZbep9Y7ZcRrjI3iLX47nX1EPMTlTlWh0LgNzwOZfszD7cOZSTU1TP8BKGtU9vm8+bBetVKVO9ol/win/guOJ2ewaQUHOsNluxX5EQE5MXrJTlV3BMe7/G/KJ6c2mUm3ONXliJth/3qvTwWtpFIl/Oo6RfiZEx/in+0mMkUyeSIctPGqFlkuF+DK6Q== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Mar 2017 17:29:14.6122 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR05MB2191 Archived-At: Subject: Re: [Idr] Thoughts on https://www.ietf.org/id/draft-hares-idr-bgp-registries-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 17:29:24 -0000 --------------3F6C03EB6437AC531881BFD8 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit On 3/22/2017 2:36 PM, John G. Scudder wrote: > I think Adrian nailed it when he suggested: > >> b. Recognition that IETF consensus trumps DE opinion. Hopefully this will never >> arise, but it is clear (or should be) that for a Standards Action registry, if >> there is IETF consensus for an assignment, then the DEs can warn and advise, but >> the will of the IETF takes precedence. According to the proposal under consideration, the DEs are the same people who judge whether there is IETF consensus. The conflict of interest is evident. > the reason is to try to ensure sufficient review happens before it's too late. I'm not opposed to additional review, but that has nothing to do with the codepoint allocation process. Presumably it is already the job of the WG chairs and/or document shepherds to obtain an adequate level of review. > the concept of a WG having "standing to request changes" is inoperative I'm looking forward to the day when you can't get a codepoint in any registry without the approval of the security and the operations ADs ;-) > In parallel, Job Snijders made a useful suggestion that idnits maybe should be on the lookout for code point squatting. That's an interesting suggestion, but has to be used carefully. If someone is squatting on a codepoint, they should be encouraged to tell the rest of us that they are doing so. Encouraging them to keep it a secret (to avoid being tagged by idnits) would be a strange way to encourage interoperability. I also think that document shepherds should be on the lookout for cases where drafts specify codepoints or flags for new stuff without requesting the necessary registries to be set up. > This leads me to wonder if we aren't going at this wrong -- if instead of using the hammer of registry policy to ensure the right WGs have been notified, we should try the screwdriver of automated tooling. The idea is registries would still be marked up with parties interested in monitoring them, but there would be no formal changes to the requirements for allocation from the registries. Those monitoring the registries (e.g., the list of people in Sue's draft) would get notifications when an allocation was proposed -- as early as possible, but no later than when the draft was sent for IETF last call. The onus would fall on them to chime in (again, as early as possible) and the regular consensus process would take its course. This proposal makes sense. It encourages more review without giving dictatorial powers to a committee of WG chairs. > your morbid fears of red tape I've seen many cases where IETF politicians wield red tape as a weapon; some do so quite expertly. Ultimately all type fields will be two-octets long with FCFS registration; that's the ultimate solution to this particular red tape problem. --------------3F6C03EB6437AC531881BFD8 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit On 3/22/2017 2:36 PM, John G. Scudder wrote:
    I think Adrian nailed it when he suggested:


    b. Recognition that IETF consensus trumps DE opinion. Hopefully this will never
arise, but it is clear (or should be) that for a Standards Action registry, if
there is IETF consensus for an assignment, then the DEs can warn and advise, but
the will of the IETF takes precedence.

    According to the proposal under consideration, the DEs are the same people who judge whether there is IETF consensus.  The conflict of interest is evident.

    the reason is to try to ensure sufficient review happens before it's too late.

    I'm not opposed to additional review, but that has nothing to do with the codepoint allocation process.  Presumably it is already the job of the WG chairs and/or document shepherds to obtain an adequate level of review.

    the concept of a WG having "standing to request changes" is inoperative

    I'm looking forward to the day when you can't get a codepoint in any registry without the approval of the security and the operations ADs ;-)

    In parallel, Job Snijders made a useful suggestion that idnits maybe should be on the lookout for code point squatting.

    That's an interesting suggestion, but has to be used carefully.  If someone is squatting on a codepoint, they should be encouraged to tell the rest of us that they are doing so.  Encouraging them to keep it a secret (to avoid being tagged by idnits) would be a strange way to encourage interoperability.

    I also think that document shepherds should be on the lookout for cases where drafts specify codepoints or flags for new stuff without requesting the necessary registries to be set up.

    This leads me to wonder if we aren't going at this wrong -- if instead of using the hammer of registry policy to ensure the right WGs have been notified, we should try the screwdriver of automated tooling. The idea is registries would still be marked up with parties interested in monitoring them, but there would be no formal changes to the requirements for allocation from the registries. Those monitoring the registries (e.g., the list of people in Sue's draft) would get notifications when an allocation was proposed -- as early as possible, but no later than when the draft was sent for IETF last call. The onus would fall on them to chime in (again, as early as possible) and the regular consensus process would take its course.

    This proposal makes sense.  It encourages more review without giving dictatorial powers to a committee of WG chairs.

    your morbid fears of red tape

    I've seen many cases where IETF politicians wield red tape as a weapon; some do so quite expertly.  Ultimately all type fields will be two-octets long with FCFS registration; that's the ultimate solution to this particular red tape problem.

    --------------3F6C03EB6437AC531881BFD8-- From nobody Thu Mar 23 10:36:45 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99FD7129A79 for ; Thu, 23 Mar 2017 10:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=HBZWNKzi; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=Gif/z7rX Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0F5G1fsOPBqA for ; Thu, 23 Mar 2017 10:36:42 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (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 EF3F5129A1C for ; Thu, 23 Mar 2017 10:36:41 -0700 (PDT) Received: from pps.filterd (m0109333.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v2NHYP16026193; Thu, 23 Mar 2017 10:36:41 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=MzFXaXoLOftBNiVwOg433ezRxEq6qfklokDcunplg/I=; b=HBZWNKziOVafxDBvCXdP14l6L7ONddU9uqqvfStmwJRFegwR5ohmLzoNvHP4UWETAuOg gLrg9+j9kD7x1aiKXPltxizqTjhKp0MVi4pnITsVgUSi3XFIiak6hNvxPUJOX3eLdluo PvOPJEiafIw92ltDLPNdOz9ec0sSwFdGobg= Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 29ccw2t1ge-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 23 Mar 2017 10:36:41 -0700 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.24) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 23 Mar 2017 13:36:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=MzFXaXoLOftBNiVwOg433ezRxEq6qfklokDcunplg/I=; b=Gif/z7rXRdhtJ52NPakqEiWSJ3MSxOQrcc6Am069PkraLLPqUdNd0j/ydY0akfRHbVwhxJb/uizCG1QqJ9Xix6W3G1tPWrZS7tnABgwSZEA4qNG9EWj6Ocm2mHIV2kFT++6KnCMrml5JcBiy+sCgms7F+OmK3Umn8Bp1gaGlJpg= Received: from MWHPR15MB1421.namprd15.prod.outlook.com (10.173.234.135) by MWHPR15MB1423.namprd15.prod.outlook.com (10.173.234.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.12; Thu, 23 Mar 2017 17:36:38 +0000 Received: from MWHPR15MB1421.namprd15.prod.outlook.com ([10.173.234.135]) by MWHPR15MB1421.namprd15.prod.outlook.com ([10.173.234.135]) with mapi id 15.01.0991.017; Thu, 23 Mar 2017 17:36:38 +0000 From: Petr Lapukhov To: Edet Nkposong , "idr@ietf.org" CC: "shares@ndzh.com" Thread-Topic: [Idr] 2 Week WG LC for draft-ietf-idr-bgp-prefix-sid-04.txt - Thread-Index: AQHSo/V8jCVBSFrlBUqfdhdvzBgTr6GirkoZ Date: Thu, 23 Mar 2017 17:36:38 +0000 Message-ID: References: In-Reply-To: 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;ndzh.com; dmarc=none action=none header.from=fb.com; x-originating-ip: [25.173.47.4] x-microsoft-exchange-diagnostics: 1; MWHPR15MB1423; 7:mEEsXDQVZfyl1WXzxot0zsxif6f9DnO/Tdu2LYApHKaETMB1DIk8rTTQZhnXBZshl4DZuR5q2eQkciRrrXUrdS4i3wIT3gxttzs57fvA58gRrUBI04D4RBxvfulfNlo4KIaGHkDyNN5aBMZYZNRq4ZV1QC4+SPm5skEyit8JmQSrVKzn0nQHIo0BXYyfjRAHY8BlN1cw8+jmSML3p/0HIS6gMx681J9Uq0sa8DwGGLwoVeOkPR6zwpKn1jPuHpy7Kw1KKxAXVpOv42xxLhh95jrvFNnmoxRhg2iNCJAmBJVk4S9nZF5D/QmzomCiFnApJBEqzqWqZ1ki7sKbw5UzVw==; 20:1gN3JzB08tnuUhIEpxeaMasAY4mqoMLGJy/PD4cQscgBn0rGumWwxzqUhe+nWks2aILiC1cTIfoanU8dAcH+LW3+2J8eV4qbr6G6Na65Jp30r3oA3tSJ59alT8WjSZGcivjx1SYdLO1w4qC+N8cwRCtoh8gVRXds4uWfLNApxZY= x-ms-office365-filtering-correlation-id: ebee9c13-aba5-41b1-1695-08d472132935 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075); SRVR:MWHPR15MB1423; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(206333022235701); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(20161123558025)(6072148); SRVR:MWHPR15MB1423; BCL:0; PCL:0; RULEID:; SRVR:MWHPR15MB1423; x-forefront-prvs: 0255DF69B9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39830400002)(39410400002)(53754006)(377454003)(2950100002)(53936002)(38730400002)(5660300001)(7736002)(33656002)(6246003)(230783001)(3846002)(4326008)(74316002)(19627405001)(3660700001)(3280700002)(6116002)(7696004)(6606003)(102836003)(81166006)(86362001)(122556002)(189998001)(54356999)(9686003)(8936002)(2501003)(6506006)(2906002)(8676002)(55016002)(50986999)(54896002)(77096006)(66066001)(2900100001)(53546009)(25786009)(99286003)(229853002)(76176999)(6436002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1423; H:MWHPR15MB1421.namprd15.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR15MB14215516B9C64541D61F29FFA23F0MWHPR15MB1421namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Mar 2017 17:36:38.5401 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1423 X-OriginatorOrg: fb.com X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-23_15:, , signatures=0 Archived-At: Subject: Re: [Idr] 2 Week WG LC for draft-ietf-idr-bgp-prefix-sid-04.txt - X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 17:36:44 -0000 --_000_MWHPR15MB14215516B9C64541D61F29FFA23F0MWHPR15MB1421namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi everyone, I like Edet's spirit! Also, I'm one of the co-authors of draft-ietf-spring-segment-routing-msdc a= nd I support the WG last-call. Regards, Petr ________________________________ From: Idr on behalf of Edet Nkposong Sent: Thursday, March 23, 2017 9:49:17 AM To: idr@ietf.org Cc: shares@ndzh.com Subject: Re: [Idr] 2 Week WG LC for draft-ietf-idr-bgp-prefix-sid-04.txt - Hell, I am one of the Authors and Contributors of draft-ietf-spring-segment-routi= ng-msdc and I support the draft. Regards, Edet Nkposong --_000_MWHPR15MB14215516B9C64541D61F29FFA23F0MWHPR15MB1421namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

    Hi everyone,


    I like Edet's spirit!


    Also, I'm one of the co-authors of draft-ietf-spring-segment-routing-msdc and I support the WG last-call.


    Regards,


    Petr

    From: Idr <idr-bounces@i= etf.org> on behalf of Edet Nkposong <enkposong@salesforce.com>
    Sent: Thursday, March 23, 2017 9:49:17 AM
    To: idr@ietf.org
    Cc: shares@ndzh.com
    Subject: Re: [Idr] 2 Week WG LC for draft-ietf-idr-bgp-prefix-sid-04= .txt -
     
    Hell,
    I am one of the Authors and Contribut= ors of draft-ietf-spring-segment-routing-msdc  and I support the d= raft.

    Regards, Edet Nkposong
    --_000_MWHPR15MB14215516B9C64541D61F29FFA23F0MWHPR15MB1421namp_-- From nobody Thu Mar 23 10:42:30 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 425C2129B47 for ; Thu, 23 Mar 2017 10:42:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.586 X-Spam-Level: X-Spam-Status: No, score=-4.586 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id boGeKYZ2_pNL for ; Thu, 23 Mar 2017 10:42:23 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0124.outbound.protection.outlook.com [104.47.41.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AD57129B55 for ; Thu, 23 Mar 2017 10:42:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=7u1k3kFyyNe79kqnjRiSQc+ST/A8klnE1iu6v/vXIyc=; b=KCCnQrYpujUcWFcWDJj3Ox7fi0VvxTg6+ijcoSNy1qjHWL/Xbb2HqqztYpsn5Ueg/HTQVcBa9tlmrvVWYV9+9uxJGg8rmxaOX1jGKS1LgrVdAj3dfe6JXaFifJuorIpw3wDETrlpcLSevyUCBXGAMnP73oGAfIrU+KSB8HQhBx8= Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=juniper.net; Received: from [172.29.33.229] (66.129.241.13) by BL2PR05MB2178.namprd05.prod.outlook.com (10.167.98.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.4; Thu, 23 Mar 2017 17:42:20 +0000 To: Susan Hares , References: <048701d29cd9$15204b80$3f60e280$@olddog.co.uk> <022201d29ce6$ffb2ba40$ff182ec0$@ndzh.com> <02dc01d2a25b$a1eca590$e5c5f0b0$@ndzh.com> <3b9c229a-4573-c586-8627-3a8c38539ff8@juniper.net> <00f701d2a355$78aa2590$69fe70b0$@ndzh.com> CC: From: Eric C Rosen Message-ID: <31c3d895-5a69-f181-eaa5-6b4d4698ae6e@juniper.net> Date: Thu, 23 Mar 2017 13:42:19 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <00f701d2a355$78aa2590$69fe70b0$@ndzh.com> Content-Type: multipart/alternative; boundary="------------096FE233960334F1769C73C7" X-Originating-IP: [66.129.241.13] X-ClientProxiedBy: BN6PR18CA0022.namprd18.prod.outlook.com (10.175.188.32) To BL2PR05MB2178.namprd05.prod.outlook.com (10.167.98.138) X-MS-Office365-Filtering-Correlation-Id: 6368ade7-a4e1-4e90-f555-08d47213f52e X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BL2PR05MB2178; X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2178; 3:8I17kowSAKM0TLXUNTjPDY+uWLHs2UTgoulfJ80af9PdtFAuC9U8XbF3qyRi5OVGQLdYfgQdXop2vCk87u3HKaCc+Wkh2srAHW1XQ5xrsIy9jAgtuBcr13oqfQjAogH9HuJeU/YElZyDKEkSur63AYAAUn89wAnAvX52O/0wmYYcK3nRzv3Bq53A/QY5N239KA/IB/xCMetq4rjRx5OIgI4+7ZimcxkXmE+QJF5nq6v1wSTTf+K3V6gXaMcoS6yEFxLWlpjgQ6FgBLBEF9s06iumrfi5JO2h7fbKupOEd3A=; 25:md4qBd075pY1sCSngp0RDOTLC1jrV4EKqeipVpGA3tO6FfI3QZQ4dj3CR67+9PSbj0k0I4yNPBBG56mT0y8dCf62Y8QMy4JtrvAEB+rZxwHsi2OiTFrp+AIQ6ZtSWRhtUrr8gp/CMXwONiQVibqLS5fcqS2gRBhPDEZ98i4peBDRzG2GJ0vhGCi5eDdYFLMM+AMR7+4jIi16IDdkGKMKyznH0CmJTTRCJQqdqzevTSm6T7jCZtSwGs0LUzJN5HKay/TuUVUAR/BRQ8l/hOdKFuMqG/233gi7/0/kWF0NFJZq9otSXJ0S6R8GCAPo08faurZG4jCMhd6f9V9lzAlv1e6TVjidkAzs8z2QrSfmi//vsHJjYEUphwclvNtSjatrq3XFjLm3ABeO6oWIUGbDeTpzbrLffXHFDc08fVOnJwEYCEQg8rNlp8TKYrj6JwHtyYlCfA4XeVh97hecwaTPxw== X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2178; 31:xS5wjAc6M+nzuXRvsdfzUSEhFiy21d8AAtbORZbwvB0Hz6DsAylA/RQtLeTjQghia7KNQCo8+Np2ikYqupp1i7PdHKxQkGVux1uBHRY7HTlR+yOgBwcux/uAVjkPymh8TpYpO8t2jbKv+BoZR0KK3Am6niuz2zS1Z4RQTIxEsKUpjsRgvXFw3N8pPvAd0DrCw9WEIiMetYDYZFY5Q1ZeXYa55FpyiZ5tO5/dSf12w4s=; 20:QBhSphs7emB2nIE/MakHCuwWOJ3AG1CTjo0jQDlMb+HaNFj/Fb5n3NbL5RzCUYmD4VTGRxOiDZeEFFw3R0co1Hf8HvbIrYNhhSe+YSEJGzE2H/DK0F5LJNsQnBy2Nno5hQD6iOPKlRhPD+HRDORTTjOrIRYjdMvPPJg74ek/L87JcmNP77CFcENWB8bdMB5NKov0H1wI+jF7SDXDcCMSf9bOuyoKQ2j754eVT8EpXu0T9sIwTFaMbp8entHiKjLzmH/LeEt3vW+Astt0aMMnbH34UJ4fRYUEyWZSHZSBtPlN2EtjrHOq4Xp9XQWRdoSJf8U3ez1DH1XZnAo4c2xGd/d68p0E24Zm4fKRx49izmYeVvWHKeObEdnhQ4h+b1J4pixR401vDITdqeoiJkdcZuHlfR3D55s9YIJ8GTCzw41W1cIwXb0x9aGsdEmqfuQtEGiiD1WnedcUeYpPyNSv8j7BMtmNdv20MuEsO8x0eiMd5s80VBIiInw+P3O/xlewzJJWXHBcE00cvdmToyJDJIStz9RKb4cM8ur8vkD5UAoXRai5jgm/sI12CsiuiwyihqSPw3GmWGKYWvVsbmkzoN7ZxLvqTMtCb0hzhr48Nds= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(20161123558025)(6072148); SRVR:BL2PR05MB2178; BCL:0; PCL:0; RULEID:; SRVR:BL2PR05MB2178; X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2178; 4:4NbH5Uc5USl2rIZX7HIpCnVrdn5T9wx9Quktdu42c9Gse64R0aXFlIA1I63NWP4Sije1Rgvd3OMtVsqF1WtDmRknFmhOW/QAHnH7GMm/7S4owW7WKXvtlbNJoH6HTov2cnP3CIrN68wVJawFELY7O4e+vhUFamAoP9tXA+wD9fB4MNeK6LqctWQwmsb4oK0TqpD3CLGtEpAU/JgXqHMAg6dK7RHjI02sbDQIFK+LnVGutI01WJeyn0c0HxBwI03RPMZx1DIWIJQheJ4ys8ugfBdQkCL/OYtDX5W6CSHceDT78e3cOwSmyIt9BZ/KcQ0bbCv8O6hQvhn5KcheMMZAXDYYqIE42wjPiRcjPJg4b4UGtJV8U+ib3anOxdFv7kqMVWq6qZa+ku1sdkwGbeWTQ48/HFpHThwj5nFm5+7sc94fjHpfXAksbQl4411zGfvyGzYguxFX1j/9dV+1wjceZKegFhi0Kzg3DH+XPPDa9EaEQH2raNam5pKbnUW7L0lbtnj5Nx8NITiEmv2T/O8bt9o9Gzfi7lLcWDYlFR8uecGF91sjf9f1kI+wmZdxZnH+dpZqdoKWtRKSy71HqsEHyGjB9q3rMBOgVuxDjI5BWDSC3rsu1fW28gfJeyvgOdfq X-Forefront-PRVS: 0255DF69B9 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(39410400002)(39850400002)(39840400002)(39860400002)(39450400003)(24454002)(377454003)(65956001)(65806001)(86362001)(66066001)(31696002)(50986999)(77096006)(6486002)(54356999)(512944002)(229853002)(90366009)(53546009)(3260700006)(230783001)(76176999)(93886004)(2906002)(25786009)(33646002)(42186005)(36756003)(64126003)(81166006)(53936002)(31686004)(8676002)(7736002)(83506001)(6246003)(4326008)(270700001)(65826007)(189998001)(2950100002)(38730400002)(3846002)(84326002)(6116002)(5660300001)(163123001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR05MB2178; H:[172.29.33.229]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BL2PR05MB2178; 23:/nMISGou1shjFmkbGTZ6Ib8mjQPVX3LyRaLvkw/CW?= =?us-ascii?Q?llktOXMi/V4DkXWBmgW34cmzl8BBzw4gYP0VBE08/JDKB9cOSDcqxgeGWZpV?= =?us-ascii?Q?miKLGcIJHLNEMugsw3XeGhzyp84sdaipL3APoJDCLjO0PNj3AJ+FeIOSvK+6?= =?us-ascii?Q?Q8ppwoIzdr/wQosF+tS6l5EjemSWvYlf7nZqniZZYTBqESMGUnIeDNj4Xzyr?= =?us-ascii?Q?E4CCoWM+bSS4mnHvpIqqJAvfxz6RKrt0BAt97Mq5UbEJPKZQeQxoDAQzHMur?= =?us-ascii?Q?bKAcfcIE9T03WCk0JaYYBR2uAksUYz6QJ68CAGdi4U2lDI/8f9JGrFSISemG?= =?us-ascii?Q?bBbJbzi+UH1QmsgoioZJ2krz29bg1Sc9ZYOJqD8fyD3ONOD1r1ZzSEFnV1w7?= =?us-ascii?Q?ymr7Ww3RxR6oRWeT0Q5IEsjifzD3I2wbqtRyuO+fEf7uhB4qKjloQEmLQ2cT?= =?us-ascii?Q?bNlXeT76XtaVVajyqCAF3GF349jmzbIlZKMlxF93CYqSLtvMKD7K8Nsb5i0Y?= =?us-ascii?Q?Ngm1B3yIe/n1T5b4HKmCTell6nJ/PUrmgg7TSKdKd7luURxNH2pPT980Dk4s?= =?us-ascii?Q?oXLPpatQtiV/3Yh/dHRFssNe6zUzZd7dXXpPwdY/5EraagTWE1govEXc5Ocq?= =?us-ascii?Q?yKT8yUs0tS8Zlg6TAQyc2hHF9x0CESHVXNQZ8akCBdPp07XwVRe/Mt6GlBGk?= =?us-ascii?Q?+5dqdsa+9So9EC3srN9HP+ARW/H1vwDAOVpiQQNn/WI+TGo2fMCwaGZUaYQs?= =?us-ascii?Q?nzW9J9kSJ7qBG6l+YLeA7IS6xCtybOo68R9sGBpofai9adLghM3ITM58d8qt?= =?us-ascii?Q?old6aXXVUsQa+3yfJnWW8EFYAN2TlbrqQxYJelJ862U+/uPu9X5nDj+Eftwm?= =?us-ascii?Q?nqGWBHS/s/TYdaqWEqPzEcmVUTBKsIoJpKQyqwy+qafT+zTLI/+/86uJ7lMx?= =?us-ascii?Q?f7/a8CDzmhz/rwSPEvGffhRdwCt1xG39XR5z15VOseWOjr+n42XvxJhnYrBx?= =?us-ascii?Q?cZcm0fEwmWeTljaWWSl90reqE3FSZGaQSLWhkYj4XOIIrA+W5JDrha+b9K0A?= =?us-ascii?Q?x0G34sberpchmuwmgljNHyPU5FNwXhHsNN2Cx+4PEchyWDklYKCrYZFZXUpq?= =?us-ascii?Q?vgqVglhoW34coLgTADRHFItY6Bka71/3oksnWvp5+wqRFYasoqxoxr2FFV1I?= =?us-ascii?Q?7aiitfrJY0Q2k/yHw7F7CupFRfVrtjKeZ2h8H3g5PlqmiWqXjrsKjjblDvuJ?= =?us-ascii?Q?jeZ4l6YTV4XgNYY49hHK/BG7lf8Em2a+ZG/4xK+?= X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2178; 6:g0JK77LeA+CcOfcNtryy2K8KucvKZ47h9rzaHsEMJUGucg5mTIkv+9zJ7JN8rMhR5me0fIT1nO4yZFss5K8YgWr8L1kRWqoDnUjElMyqiY2V50NCSxRAxwQ9aL/ZOUkCZYWewHNHMMxAnKJj4g7mm2lLdgNAlP72l5dFbMXTRRLK+vOxGfX97VU/8PS+Af89PhL74KwK70J8Qj4U02xBMO8jCVDJwnEt0Y87zucQAh5Jw96SNbWWNZKhEIluG+rINJXqD3Q99pLMOqttpJHoanA35DwPSt1swrXyN7OdYS4jdLhs7Q6vCElj1k5iwaT4E8OjVETdgS5DeFwiPfHtJM2D540JPH9/oL/+NXk27WgNPy6dsDpY72rI3DR/TYA2k/bvqg0oUqqGBiwhUB9eCuyJdbgkPoww1VP5p5rx4UU=; 5:ZmesUbFwO35ELHqPJx8giASM+SMs4MW+gOP18a2bA/CxpS5VnImTdXyrClozaXJ59tF6By8UrDTrE5vmwmortvXrCZXZpfQEeim0OT30DxldXB+cgAQB4oJA//I/V8vWqGf+tXl5i1LgaQneDdoe+A==; 24:7B7Lx/qRqL3LKa7Gl46V6o+aOjyZ/Pmwz+aaxr/74Xla5AFdY8Am85yFw0ZBPnwjIW0vearGwS02ouazz43b7bCHoHx9rODuVwrY/HSSsQE= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2178; 7:PV1nVi+abRWO1pK95g9sGE/yjLDjMmDVQesi1RtziC+jv0WXM/3BYnp/MgM9Ih/UfHX4/wBYSXEz0xL9WB7n7oQ3CuV6G+++iuwrul+vTm0wmNQBFQLqwGEgQoPBBL6c/tXdUi71EEJSr6j9Rib37RusYCWNAJnNvMsAOM1HpPbAjig+Uxg5xEI8DZer8Flu73Z1BPxcL8HX1MlU+AuytsnT8twF+FJH19VtvIsn6XdGyxGaJDhrASwkK7vgJeajbNeje60/bJxRuJtPLO/iEd6Nox2gJ52jGti7neL+h81x3zJHksaZCYc/MaDvgfzuEh7fa0wRFutbZ/vKXdR58g== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Mar 2017 17:42:20.6420 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR05MB2178 Archived-At: Subject: Re: [Idr] Thoughts on https://www.ietf.org/id/draft-hares-idr-bgp-registries-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 17:42:25 -0000 --------------096FE233960334F1769C73C7 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit On 3/22/2017 5:44 PM, Susan Hares wrote: > You feel WG chairs and ADs are motivated by commercial reasons before > the altruism of the IETF professional ideals. This doesn't apply to all WG chairs and ADs at all times, but it certainly happens frequently. > You want a BGP attribute name-space without any oversight, even though > squatting brought attribute conflict that lead us to this point. Squatting is the use of unregistered codepoints. I do not support the use of unregistered codepoints. I think it should be easy to register codepoints, and making it easy will prevent squatting. Anything that makes registration more difficult will encourage more squatting. --------------096FE233960334F1769C73C7 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit On 3/22/2017 5:44 PM, Susan Hares wrote:
    You feel WG chairs and ADs are motivated by commercial reasons before the altruism of the IETF professional ideals.   

    This doesn't apply to all WG chairs and ADs at all times, but it certainly happens frequently. 

    You want a BGP attribute name-space without any oversight, even though squatting brought attribute conflict that lead us to this point.

    Squatting is the use of unregistered codepoints.  I do not support the use of unregistered codepoints.  I think it should be easy to register codepoints, and making it easy will prevent squatting.  Anything that makes registration more difficult will encourage more squatting. 
    --------------096FE233960334F1769C73C7-- From nobody Thu Mar 23 10:52:20 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB08F129BB8 for ; Thu, 23 Mar 2017 10:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.957 X-Spam-Level: X-Spam-Status: No, score=0.957 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sFVQMhYT3xDl for ; Thu, 23 Mar 2017 10:52:15 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 A4DFF129B42 for ; Thu, 23 Mar 2017 10:51:55 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=50.36.86.73; From: "Susan Hares" To: "'Eric C Rosen'" , "'John G. Scudder'" Cc: "'Adrian Farrel'" , References: <048701d29cd9$15204b80$3f60e280$@olddog.co.uk> <022201d29ce6$ffb2ba40$ff182ec0$@ndzh.com> <02dc01d2a25b$a1eca590$e5c5f0b0$@ndzh.com> <3b9c229a-4573-c586-8627-3a8c38539ff8@juniper.net> In-Reply-To: Date: Thu, 23 Mar 2017 13:46:39 -0400 Message-ID: <050901d2a3fd$734b3e10$59e1ba30$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_050A_01D2A3DB.EC3CAB50" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHgLJVhftftdlZ2OeQGM5dxbx7ZtQIfusEjApalZLoB3VIuCQJnQvCHApVdmPIBwb1GPqEdDJdQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] Thoughts on https://www.ietf.org/id/draft-hares-idr-bgp-registries-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 17:52:18 -0000 This is a multipart message in MIME format. ------=_NextPart_000_050A_01D2A3DB.EC3CAB50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Eric: Thank you for your return comments with helpful suggestions: 1) IETF consensus trumps DE opinion - If you are suggesting that the WG chair(s) that sponsored a draft should not be the Designated Expert. Good idea. 2) Adequate review - If you wish it to be a single working group assigning BGP code points, the WG chair/document shepherd method works. By this comment, we would need to select one WG to approve standardization of BGP code points. My proposal at IETF 97 was that IDR was such a WG since BGP base specifications (e.g., RFC4271) were started there. My alternate proposal of shared responsibility among the BGP-focused chairs is the bgp-registries. 3) On reviewing Shepherd's work - sounds like you would be a useful reviewer for documents. Please volunteer. 4) On code point squatting, operators had real problems with the current situation. Job said "automatic checks on drafts", Sue said "IETF Standard + DE of BGP chairs where IETF Consensus wins" - Got any alternate solutions. Got any alternate suggestions? Sue Hares From: Eric C Rosen [mailto:erosen@juniper.net] Sent: Thursday, March 23, 2017 1:29 PM To: John G. Scudder Cc: Susan Hares; Adrian Farrel; idr@ietf.org Subject: Re: [Idr] Thoughts on https://www.ietf.org/id/draft-hares-idr-bgp-registries-01.txt On 3/22/2017 2:36 PM, John G. Scudder wrote: I think Adrian nailed it when he suggested: b. Recognition that IETF consensus trumps DE opinion. Hopefully this will never arise, but it is clear (or should be) that for a Standards Action registry, if there is IETF consensus for an assignment, then the DEs can warn and advise, but the will of the IETF takes precedence. According to the proposal under consideration, the DEs are the same people who judge whether there is IETF consensus. The conflict of interest is evident. the reason is to try to ensure sufficient review happens before it's too late. I'm not opposed to additional review, but that has nothing to do with the codepoint allocation process. Presumably it is already the job of the WG chairs and/or document shepherds to obtain an adequate level of review. the concept of a WG having "standing to request changes" is inoperative I'm looking forward to the day when you can't get a codepoint in any registry without the approval of the security and the operations ADs ;-) In parallel, Job Snijders made a useful suggestion that idnits maybe should be on the lookout for code point squatting. That's an interesting suggestion, but has to be used carefully. If someone is squatting on a codepoint, they should be encouraged to tell the rest of us that they are doing so. Encouraging them to keep it a secret (to avoid being tagged by idnits) would be a strange way to encourage interoperability. I also think that document shepherds should be on the lookout for cases where drafts specify codepoints or flags for new stuff without requesting the necessary registries to be set up. This leads me to wonder if we aren't going at this wrong -- if instead of using the hammer of registry policy to ensure the right WGs have been notified, we should try the screwdriver of automated tooling. The idea is registries would still be marked up with parties interested in monitoring them, but there would be no formal changes to the requirements for allocation from the registries. Those monitoring the registries (e.g., the list of people in Sue's draft) would get notifications when an allocation was proposed -- as early as possible, but no later than when the draft was sent for IETF last call. The onus would fall on them to chime in (again, as early as possible) and the regular consensus process would take its course. This proposal makes sense. It encourages more review without giving dictatorial powers to a committee of WG chairs. your morbid fears of red tape I've seen many cases where IETF politicians wield red tape as a weapon; some do so quite expertly. Ultimately all type fields will be two-octets long with FCFS registration; that's the ultimate solution to this particular red tape problem. ------=_NextPart_000_050A_01D2A3DB.EC3CAB50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Eric:

     

    Thank you for your return comments with helpful suggestions: =

     

    1)      = IETF consensus trumps  DE opinion -   If you are = suggesting that the WG chair(s) that sponsored a draft should not be the = Designated Expert.  Good idea.

    2)      = Adequate review –  If you wish it to be a single working = group assigning BGP code points, the WG chair/document shepherd method = works.  By this comment, we would need to select one WG to approve = standardization of BGP code points.  My proposal at IETF 97 was = that IDR was such a WG since BGP base specifications (e.g., RFC4271) = were started there.  My alternate proposal of shared responsibility = among the BGP-focused chairs is the bgp-registries. =

    3)      = On reviewing Shepherd’s work – sounds like you would be a = useful reviewer for documents.  Please volunteer.  =

    4)      = On code point squatting, operators had real problems with the current = situation.   Job said “automatic checks on = drafts”,  Sue said “IETF Standard + DE of BGP chairs = where IETF Consensus wins” – Got any alternate = solutions.  Got any alternate suggestions?

     

    Sue Hares

     

    From: Eric C Rosen [mailto:erosen@juniper.net]
    Sent: = Thursday, March 23, 2017 1:29 PM
    To: John G. = Scudder
    Cc: Susan Hares; Adrian Farrel; = idr@ietf.org
    Subject: Re: [Idr] Thoughts on = https://www.ietf.org/id/draft-hares-idr-bgp-registries-01.txt<= /span>

     

    On 3/22/2017 2:36 PM, John G. Scudder = wrote:

    I think Adrian nailed it when he =
suggested:
     
    b. Recognition that =
IETF consensus trumps DE opinion. Hopefully this will =
never
    arise, but it is clear (or should be) that =
for a Standards Action registry, if
    there is IETF =
consensus for an assignment, then the DEs can warn and advise, =
but
    the will of the IETF takes =
precedence.


    According to the proposal under consideration, the = DEs are the same people who judge whether there is IETF consensus.  = The conflict of interest is evident.


    the =
reason is to try to ensure sufficient review happens before it's too =
late.


    I'm not opposed to = additional review, but that has nothing to do with the codepoint = allocation process.  Presumably it is already the job of the WG = chairs and/or document shepherds to obtain an adequate level of = review.


    the concept of a WG having =
"standing to request changes" is =
inoperative


    I'm looking forward = to the day when you can't get a codepoint in any registry without the = approval of the security and the operations ADs = ;-)


    In parallel, Job Snijders made a =
useful suggestion that idnits maybe should be on the lookout for code =
point squatting.


    That's an = interesting suggestion, but has to be used carefully.  If someone = is squatting on a codepoint, they should be encouraged to tell the rest = of us that they are doing so.  Encouraging them to keep it a secret = (to avoid being tagged by idnits) would be a strange way to encourage = interoperability.

    I also think that document shepherds should be = on the lookout for cases where drafts specify codepoints or flags for = new stuff without requesting the necessary registries to be set = up.


    This leads me to wonder if we aren't =
going at this wrong -- if instead of using the hammer of registry policy =
to ensure the right WGs have been notified, we should try the =
screwdriver of automated tooling. The idea is registries would still be =
marked up with parties interested in monitoring them, but there would be =
no formal changes to the requirements for allocation from the =
registries. Those monitoring the registries (e.g., the list of people in =
Sue's draft) would get notifications when an allocation was proposed -- =
as early as possible, but no later than when the draft was sent for IETF =
last call. The onus would fall on them to chime in (again, as early as =
possible) and the regular consensus process would take its =
course.


    This proposal makes = sense.  It encourages more review without giving dictatorial powers = to a committee of WG chairs.


    your morbid =
fears of red tape


    I've seen many cases where IETF = politicians wield red tape as a weapon; some do so quite expertly.  = Ultimately all type fields will be two-octets long with FCFS = registration; that's the ultimate solution to this particular red tape = problem.

    ------=_NextPart_000_050A_01D2A3DB.EC3CAB50-- From nobody Thu Mar 23 11:04:31 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBC731287A7 for ; Thu, 23 Mar 2017 11:04:29 -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, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rCMxwcjq1Oqc for ; Thu, 23 Mar 2017 11:04:28 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 53E59127011 for ; Thu, 23 Mar 2017 11:04:28 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 38A971E33F; Thu, 23 Mar 2017 14:10:53 -0400 (EDT) Date: Thu, 23 Mar 2017 14:10:53 -0400 From: Jeffrey Haas To: Susan Hares Cc: 'Eric C Rosen' , "'John G. Scudder'" , idr@ietf.org Message-ID: <20170323181052.GL27015@pfrc.org> References: <048701d29cd9$15204b80$3f60e280$@olddog.co.uk> <022201d29ce6$ffb2ba40$ff182ec0$@ndzh.com> <02dc01d2a25b$a1eca590$e5c5f0b0$@ndzh.com> <3b9c229a-4573-c586-8627-3a8c38539ff8@juniper.net> <050901d2a3fd$734b3e10$59e1ba30$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <050901d2a3fd$734b3e10$59e1ba30$@ndzh.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Idr] Thoughts on https://www.ietf.org/id/draft-hares-idr-bgp-registries-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 18:04:30 -0000 On Thu, Mar 23, 2017 at 01:46:39PM -0400, Susan Hares wrote: > 4) On code point squatting, operators had real problems with the > current situation. Job said "automatic checks on drafts", Sue said "IETF > Standard + DE of BGP chairs where IETF Consensus wins" - Got any alternate > solutions. Got any alternate suggestions? Wearing my work process hat, the issue is flagging when something needs more eyes. IETF process already gives us the necessary voice in how stuff works for allocation, I think. It's less we need a panel of designated experts, it's more that once something has been noticed, many voices will suggest doing the right thing. -- Jeff From nobody Thu Mar 23 11:18:18 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E118F1315E7 for ; Thu, 23 Mar 2017 11:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nd9GWU7KeeKA for ; Thu, 23 Mar 2017 11:18:15 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 692F3129BA1 for ; Thu, 23 Mar 2017 11:18:15 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=70.194.5.9; From: "Susan Hares" To: "'Jeffrey Haas'" Cc: "'Eric C Rosen'" , "'John G. Scudder'" , References: <048701d29cd9$15204b80$3f60e280$@olddog.co.uk> <022201d29ce6$ffb2ba40$ff182ec0$@ndzh.com> <02dc01d2a25b$a1eca590$e5c5f0b0$@ndzh.com> <3b9c229a-4573-c586-8627-3a8c38539ff8@juniper.net> <050901d2a3fd$734b3e10$59e1ba30$@ndzh.com> <20170323181052.GL27015@pfrc.org> In-Reply-To: <20170323181052.GL27015@pfrc.org> Date: Thu, 23 Mar 2017 14:13:07 -0400 Message-ID: <001f01d2a401$1fc173a0$5f445ae0$@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: AQHgLJVhftftdlZ2OeQGM5dxbx7ZtQIfusEjApalZLoB3VIuCQJnQvCHApVdmPIBwb1GPgECN7t0AgoLdiyhBLL5QA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] Thoughts on https://www.ietf.org/id/draft-hares-idr-bgp-registries-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 18:18:17 -0000 Jeff: Yes! - If flagging for more eye review is the case, then Job's suggestion is the way forward. It works for most YANG modules. - If having the expertise to review the "flag" is the issue, 1 WG being in charge of the situation will suffice with the current setup. - if cross-review in all BGP working group is issue - then try my registries proposal + IETF consensus. - if distrust of a single answer from WG shepherd, WG chair or set of WG chairs - this draft + Eric's suggestion for who can review. If we can define the largest concern(s), let's we could start with that solution. Sue -----Original Message----- From: Jeffrey Haas [mailto:jhaas@pfrc.org] Sent: Thursday, March 23, 2017 2:11 PM To: Susan Hares Cc: 'Eric C Rosen'; 'John G. Scudder'; idr@ietf.org Subject: Re: [Idr] Thoughts on https://www.ietf.org/id/draft-hares-idr-bgp-registries-01.txt On Thu, Mar 23, 2017 at 01:46:39PM -0400, Susan Hares wrote: > 4) On code point squatting, operators had real problems with the > current situation. Job said "automatic checks on drafts", Sue said "IETF > Standard + DE of BGP chairs where IETF Consensus wins" - Got any > alternate solutions. Got any alternate suggestions? Wearing my work process hat, the issue is flagging when something needs more eyes. IETF process already gives us the necessary voice in how stuff works for allocation, I think. It's less we need a panel of designated experts, it's more that once something has been noticed, many voices will suggest doing the right thing. -- Jeff From nobody Thu Mar 23 11:35:26 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C4921294CD for ; Thu, 23 Mar 2017 11:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.39 X-Spam-Level: X-Spam-Status: No, score=-2.39 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TEJEulcLBrj1 for ; Thu, 23 Mar 2017 11:35:21 -0700 (PDT) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::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 0EBFF129BB7 for ; Thu, 23 Mar 2017 11:35:21 -0700 (PDT) Received: by mail-it0-x235.google.com with SMTP id w124so45453783itb.1 for ; Thu, 23 Mar 2017 11:35:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Lo97TWmo1A6zli5g3aKSgbDLmx9xqvJeCLc8sSSMh2I=; b=T0AHc/xF9Ql2Uqrnb7DwkqPSrDCGvA5Dihxhtf2i+WqZ3jn6qmzo/6vu39fdx3GSw9 Ckou+iDR5HZ5SidqNEt9LUqUNOAPow1nReETVWm/lvezSHzLjQsQMYh2g+Pg2EEQ/9hv WRYeKpLaKNjojj+Byp9PoXH4EvMmwfBYi+X/GRgO207s4JLrN/VyXpt9JfHHsQDmOVpe OWgnLDBW6pL9ZxTWb9LgfgWjde9+bpgy7KuEphlrIBanQGtG2f4gN0/7ZbJVO8etaMAu FdnqHeJ0jI5a35tOyZxXZIMzOnCrf0oqJxyVG4NedIoAMIFtEV+RH0dwrchLcw4ncDa0 kblQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Lo97TWmo1A6zli5g3aKSgbDLmx9xqvJeCLc8sSSMh2I=; b=GihSMvB/MP2anO+ye6wUYwv8NFIT7NMhyTkiZ/nV022HINLNzX2FlOJ3KtEneGJF0f bNO6FB0hykfupjSnk13igUH2kgzhvZEwle6FJZHPKw5F5kvaG90lyEAi3SKC0zqOt5ri OJFoKe6FbhfTiTP5BZSQDOEr9mJo2mJ6QQeBzOnQHY5DJIC/N5LAmLKXu7IoyIPff+6q FgqT5Ajlu39ntBYlXdhl6R2inWa3pnGrUrYjHBRv6U+WLgjLGRK5OEzCWMD1tz9P+2i8 aYY4RheNWgUMllVyTXpG2ikCnC+epNm/FO8CqlU2nER1+TWyJjZbODLcGmfs1kaIbrSS BM8w== X-Gm-Message-State: AFeK/H16c9GVG+pkWL4IZXcSw4lvb+1VDWJCfnja0aidVnbTeiazeXXDYqQhzrd1XQZsNIyr7BDWwQob1TFBzA== X-Received: by 10.36.238.202 with SMTP id b193mr4043966iti.39.1490294120350; Thu, 23 Mar 2017 11:35:20 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.79.90.71 with HTTP; Thu, 23 Mar 2017 11:35:19 -0700 (PDT) In-Reply-To: <050901d2a3fd$734b3e10$59e1ba30$@ndzh.com> References: <048701d29cd9$15204b80$3f60e280$@olddog.co.uk> <022201d29ce6$ffb2ba40$ff182ec0$@ndzh.com> <02dc01d2a25b$a1eca590$e5c5f0b0$@ndzh.com> <3b9c229a-4573-c586-8627-3a8c38539ff8@juniper.net> <050901d2a3fd$734b3e10$59e1ba30$@ndzh.com> From: Robert Raszuk Date: Thu, 23 Mar 2017 14:35:19 -0400 X-Google-Sender-Auth: IPk8K0SoeyXVKk5Gy1IEO3AzYvU Message-ID: To: Susan Hares Cc: Eric C Rosen , "John G. Scudder" , idr wg Content-Type: multipart/alternative; boundary=94eb2c03783ca7a109054b6a235b Archived-At: Subject: Re: [Idr] Thoughts on https://www.ietf.org/id/draft-hares-idr-bgp-registries-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 18:35:24 -0000 --94eb2c03783ca7a109054b6a235b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sue, Automated checks on drafts means "*no self documented allocation*". Folks who are implementing things even will continue to do "s*elf undocumented allocations" *or are going to be permitted to get next code point and proceed with implementation without any politics and reviews. John said that your draft targets only standard action and IETF standards track final allocations where document goes via WG last call. But in my opinion the genesis of squatting is not at that point in time scale. It happens much earlier where an idea in the draft if facing early implementation. Jeff suggested to send such draft to IANA for early allocation individually but it will be seen in bad light. So with all of the above we still have no way to get codepoints for early implementations without being stuck with reviews. And implementations are not even used to jusitfy acceptance to become a WG document in IDR .... Cheers, r. On Thu, Mar 23, 2017 at 1:46 PM, Susan Hares wrote: > Eric: > > > > Thank you for your return comments with helpful suggestions: > > > > 1) IETF consensus trumps DE opinion - If you are suggesting that > the WG chair(s) that sponsored a draft should not be the Designated > Expert. Good idea. > > 2) Adequate review =E2=80=93 If you wish it to be a single working = group > assigning BGP code points, the WG chair/document shepherd method works. = By > this comment, we would need to select one WG to approve standardization o= f > BGP code points. My proposal at IETF 97 was that IDR was such a WG since > BGP base specifications (e.g., RFC4271) were started there. My alternate > proposal of shared responsibility among the BGP-focused chairs is the > bgp-registries. > > 3) On reviewing Shepherd=E2=80=99s work =E2=80=93 sounds like you wo= uld be a useful > reviewer for documents. Please volunteer. > > 4) On code point squatting, operators had real problems with the > current situation. Job said =E2=80=9Cautomatic checks on drafts=E2=80= =9D, Sue said =E2=80=9CIETF > Standard + DE of BGP chairs where IETF Consensus wins=E2=80=9D =E2=80=93 = Got any alternate > solutions. Got any alternate suggestions? > > > > Sue Hares > > > > *From:* Eric C Rosen [mailto:erosen@juniper.net] > *Sent:* Thursday, March 23, 2017 1:29 PM > *To:* John G. Scudder > *Cc:* Susan Hares; Adrian Farrel; idr@ietf.org > *Subject:* Re: [Idr] Thoughts on https://www.ietf.org/id/draft- > hares-idr-bgp-registries-01.txt > > > > On 3/22/2017 2:36 PM, John G. Scudder wrote: > > I think Adrian nailed it when he suggested: > > > > b. Recognition that IETF consensus trumps DE opinion. Hopefully this will= never > > arise, but it is clear (or should be) that for a Standards Action registr= y, if > > there is IETF consensus for an assignment, then the DEs can warn and advi= se, but > > the will of the IETF takes precedence. > > > According to the proposal under consideration, the DEs are the same peopl= e > who judge whether there is IETF consensus. The conflict of interest is > evident. > > > the reason is to try to ensure sufficient review happens before it's too = late. > > > I'm not opposed to additional review, but that has nothing to do with the > codepoint allocation process. Presumably it is already the job of the WG > chairs and/or document shepherds to obtain an adequate level of review. > > > the concept of a WG having "standing to request changes" is inoperative > > > I'm looking forward to the day when you can't get a codepoint in any > registry without the approval of the security and the operations ADs ;-) > > > In parallel, Job Snijders made a useful suggestion that idnits maybe shou= ld be on the lookout for code point squatting. > > > That's an interesting suggestion, but has to be used carefully. If > someone is squatting on a codepoint, they should be encouraged to tell th= e > rest of us that they are doing so. Encouraging them to keep it a secret > (to avoid being tagged by idnits) would be a strange way to encourage > interoperability. > > I also think that document shepherds should be on the lookout for cases > where drafts specify codepoints or flags for new stuff without requesting > the necessary registries to be set up. > > > This leads me to wonder if we aren't going at this wrong -- if instead of= using the hammer of registry policy to ensure the right WGs have been noti= fied, we should try the screwdriver of automated tooling. The idea is regis= tries would still be marked up with parties interested in monitoring them, = but there would be no formal changes to the requirements for allocation fro= m the registries. Those monitoring the registries (e.g., the list of people= in Sue's draft) would get notifications when an allocation was proposed --= as early as possible, but no later than when the draft was sent for IETF l= ast call. The onus would fall on them to chime in (again, as early as possi= ble) and the regular consensus process would take its course. > > > This proposal makes sense. It encourages more review without giving > dictatorial powers to a committee of WG chairs. > > > your morbid fears of red tape > > > I've seen many cases where IETF politicians wield red tape as a weapon; > some do so quite expertly. Ultimately all type fields will be two-octets > long with FCFS registration; that's the ultimate solution to this > particular red tape problem. > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > --94eb2c03783ca7a109054b6a235b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Sue,

    =
    Automated checks on drafts means "no self docume= nted allocation".=C2=A0

    Folks who are implementing things even will continue to do "= ;self undocumented allocations"=C2=A0or are going to be permitt= ed to get next code point and proceed with implementation without any polit= ics and reviews.=C2=A0

    John said that your draft targets only standard action and IETF standards = track final allocations where document goes via WG last call.=C2=A0

    But in my opinion the genesis= of squatting is not at that point in time scale. It happens much earlier w= here an idea in the draft if facing early implementation. Jeff suggested to= send such draft to IANA for early allocation individually but it will be s= een in bad light.=C2=A0

    So with all of the above we still have no way to get codepoints for early= implementations without being stuck with reviews. And implementations are = not even used to jusitfy acceptance to become a WG document in IDR ....

    Cheers,
    r.


    =



    On Thu, Mar 23, 2017 at 1:46 PM, S= usan Hares <shares@ndzh.com> wrote:

    Eric: <= /p>

    =C2=A0

    Thank you for yo= ur return comments with helpful suggestions:

    =C2=A0

    = 1)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <= /u>IETF consensus trumps=C2=A0 DE opinion -=C2= =A0 =C2=A0If you are suggesting that the WG chair(s) that sponsored a draft= should not be the Designated Expert.=C2=A0 Good idea.=

    = 2)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <= u>Adequate review =E2=80=93 =C2=A0If you wis= h it to be a single working group assigning BGP code points, the WG chair/d= ocument shepherd method works.=C2=A0 By this comment, we would need to sele= ct one WG to approve standardization of BGP code points.=C2=A0 My proposal = at IETF 97 was that IDR was such a WG since BGP base specifications (e.g., = RFC4271) were started there.=C2=A0 My alternate proposal of shared responsi= bility among the BGP-focused chairs is the bgp-registries.

    3)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 On reviewing Shepherd=E2=80=99s work = =E2=80=93 sounds like you would be a useful reviewer for documents.=C2=A0 P= lease volunteer.=C2=A0

    4)=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0

    Sue Hares

    =C2=A0

    From: Eric C Rosen [mailto:erosen@juniper.net]
    Sent: T= hursday, March 23, 2017 1:29 PM
    To: John G. Scudder
    Cc:= Susan Hares; Adrian Farrel; idr@ietf.org
    Subject: Re: [Idr] Thoughts on https://www.ietf.org/id/draft-hares-idr-bgp-registries-01.= txt

    =C2=A0

    On 3/22/2017 2:36 PM, Jo= hn G. Scudder wrote:

    I think Adrian nailed it when he suggested:
    =C2=A0
    b. Recognition that IETF consensus trumps DE op=
inion. Hopefully this will never
    arise, but it is c=
lear (or should be) that for a Standards Action registry, if<=
/pre>
    there is IETF consensus for an assignment, then the DEs can warn =
and advise, but
    the will of the IETF takes preceden=
ce.


    According to= the proposal under consideration, the DEs are the same people who judge wh= ether there is IETF consensus.=C2=A0 The conflict of interest is evident.

    the reason is to try to ensure sufficient =
review happens before it's too late.


    I'm not opposed to additional review, but that has nothing = to do with the codepoint allocation process.=C2=A0 Presumably it is already= the job of the WG chairs and/or document shepherds to obtain an adequate l= evel of review.


    the concept of a WG havin=
g "standing to request changes" is inoperative

    I'm looking forward to the day when you can=
't get a codepoint in any registry without the approval of the security=
 and the operations ADs ;-)


    In parallel, =
Job Snijders made a useful suggestion that idnits maybe should be on the lo=
okout for code point squatting.
    <=
br>That's an interesting suggestion, but has to be used carefully.=C2=
=A0 If someone is squatting on a codepoint, they should be encouraged to te=
ll the rest of us that they are doing so.=C2=A0 Encouraging them to keep it=
 a secret (to avoid being tagged by idnits) would be a strange way to encou=
rage interoperability.

    I also think that document shepherds should b=
e on the lookout for cases where drafts specify codepoints or flags for new=
 stuff without requesting the necessary registries to be set up.

    This leads me to wonder if we aren't going at t=
his wrong -- if instead of using the hammer of registry policy to ensure th=
e right WGs have been notified, we should try the screwdriver of automated =
tooling. The idea is registries would still be marked up with parties inter=
ested in monitoring them, but there would be no formal changes to the requi=
rements for allocation from the registries. Those monitoring the registries=
 (e.g., the list of people in Sue's draft) would get notifications when=
 an allocation was proposed -- as early as possible, but no later than when=
 the draft was sent for IETF last call. The onus would fall on them to chim=
e in (again, as early as possible) and the regular consensus process would =
take its course.

    This proposa=
l makes sense.=C2=A0 It encourages more review without giving dictatorial p=
owers to a committee of WG chairs.


    your m=
orbid fears of red tape

    I've seen many cases where IETF politicians w=
ield red tape as a weapon; some do so quite expertly.=C2=A0 Ultimately all =
type fields will be two-octets long with FCFS registration; that's the =
ultimate solution to this particular red tape problem.

    _____________________________________________= __
    Idr mailing list
    Idr@ietf.org
    https://www.ietf.org/mailman/listinfo/idr


    --94eb2c03783ca7a109054b6a235b-- From nobody Thu Mar 23 11:39:48 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF18E129407 for ; Thu, 23 Mar 2017 11:39:46 -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, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ge6zhZsg1_kb for ; Thu, 23 Mar 2017 11:39:45 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 29A5512948B for ; Thu, 23 Mar 2017 11:39:45 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 00A8F1E33F; Thu, 23 Mar 2017 14:46:09 -0400 (EDT) Date: Thu, 23 Mar 2017 14:46:09 -0400 From: Jeffrey Haas To: Susan Hares Cc: 'Eric C Rosen' , "'John G. Scudder'" , idr@ietf.org Message-ID: <20170323184608.GM27015@pfrc.org> References: <048701d29cd9$15204b80$3f60e280$@olddog.co.uk> <022201d29ce6$ffb2ba40$ff182ec0$@ndzh.com> <02dc01d2a25b$a1eca590$e5c5f0b0$@ndzh.com> <3b9c229a-4573-c586-8627-3a8c38539ff8@juniper.net> <050901d2a3fd$734b3e10$59e1ba30$@ndzh.com> <20170323181052.GL27015@pfrc.org> <001f01d2a401$1fc173a0$5f445ae0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001f01d2a401$1fc173a0$5f445ae0$@ndzh.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Idr] Thoughts on https://www.ietf.org/id/draft-hares-idr-bgp-registries-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 18:39:47 -0000 On Thu, Mar 23, 2017 at 02:13:07PM -0400, Susan Hares wrote: > - If flagging for more eye review is the case, then Job's suggestion is the > way forward. It works for most YANG modules. As I noted off-list to Job, pattern matching works great when you have a pattern that can catch it. Better than nothing, especially if we end up with good boilerplate text for allocations. (It might be worth having a chat with IANA about that.) > - If having the expertise to review the "flag" is the issue, 1 WG being in > charge of the situation will suffice with the current setup. > - if cross-review in all BGP working group is issue - then try my registries > proposal + IETF consensus. > - if distrust of a single answer from WG shepherd, WG chair or set of WG > chairs - this draft + Eric's suggestion for who can review. Mostly, I think once an issue is flagged, all eyes need to be pulled to one place. For the registries in question, IDR@ietf is probably fine, as long as we reach out. While I share some of Eric's dislike of process, I don't quite share his paranoia about process blockers. When things go awry anyway, the best we have in process is the appeals process. If we've reached that point, speed is doomed anyway. > If we can define the largest concern(s), let's we could start with that > solution. I'd suggest finding a way to flag stuff is appropriate. Nits search is one. Allowing chairs to prod a button in datatracker that says cross-WG review is needed might be another. I suspect this may make good wgchairs discussion. -- Jeff From nobody Thu Mar 23 11:51:12 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 931E1129B22 for ; Thu, 23 Mar 2017 11:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.81 X-Spam-Level: X-Spam-Status: No, score=-1.81 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fKr0YA9R_TOV for ; Thu, 23 Mar 2017 11:51:08 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0123.outbound.protection.outlook.com [104.47.40.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 836EF12965A for ; Thu, 23 Mar 2017 11:51:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=2Ie5o4zscPnm9+CBenyNqlCPnHiVz9q362bs7xhfZGQ=; b=dG8pZCDlmuihezjwUa6DayFU6rj9LVS9qbuAEJOtqQopRD9L4DJEfgF9ohvs55oCjfGdTAyOUcKkUHTQN14l/kN5r2aI42MucLRVyJMORQ+aH2qc6N9uZ7aXEfsRuhwtEP7ETp5Jq21uG8hMlCzsTKQ0UvBaIu8+5BCmeQSMDdI= Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=juniper.net; Received: from [172.29.33.229] (66.129.241.13) by BL2PR05MB2178.namprd05.prod.outlook.com (10.167.98.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.4; Thu, 23 Mar 2017 18:51:05 +0000 To: Susan Hares , "'John G. Scudder'" References: <048701d29cd9$15204b80$3f60e280$@olddog.co.uk> <022201d29ce6$ffb2ba40$ff182ec0$@ndzh.com> <02dc01d2a25b$a1eca590$e5c5f0b0$@ndzh.com> <3b9c229a-4573-c586-8627-3a8c38539ff8@juniper.net> <050901d2a3fd$734b3e10$59e1ba30$@ndzh.com> CC: 'Adrian Farrel' , From: Eric C Rosen Message-ID: Date: Thu, 23 Mar 2017 14:51:03 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <050901d2a3fd$734b3e10$59e1ba30$@ndzh.com> Content-Type: multipart/alternative; boundary="------------C3E16E4C47A8ED2EFB73CB93" X-Originating-IP: [66.129.241.13] X-ClientProxiedBy: BN6PR20CA0010.namprd20.prod.outlook.com (10.173.158.148) To BL2PR05MB2178.namprd05.prod.outlook.com (10.167.98.138) X-MS-Office365-Filtering-Correlation-Id: d19c3fb6-79c7-40b1-e44e-08d4721d8ff2 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BL2PR05MB2178; X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2178; 3:S4k9GyXSnH+Wjm7nB0mYg/PrYDnhinH2rTtBZhZ0GPMKcl0bd8BUeFRS7QnGuQcZbwOnIc+eswlqAv5fT9wGpIsckZ4PIXMBDUGvvSXMVQJczjMDPV9tu2xB4ewJqqVHXUijJhGgaN+ENWYATWdEx1kBE2bQ/DZqtHYM6oVooYeoxTf5exJuJP6j0+Jw5mJfliL1lL9WkQ2/MdfbPchhmCBtNqZZW63HNMWFIdRk4dSDZdG1z6EL9KOtAtpqj7S+gaPtFoYtEGCJ4Bm2rb8NYDwTywtlsDO6R2Fxap+Zy88=; 25:RnRLZufEcB8xomHqmo/MnyGYef0ymYC7geV3lexq/mioiaITbrCdvfH7oVWRO/dLlPu1/+CLbBcPOLvMqZbsEvJCfCEm2GbH8O6MLkxcaNkqdCmDKFHru8GyeMFUQoDTK1ts0ot+Yxt4LxMArJX4HaX0SOYBFs26+W/pkCJA5/lD51qMw6QBITNzlyBT+IhNzMq9FylZKp2RQG2Ky+rAGl8d1rtS0FvzhXdtWStOfC7+KZwuV4VutUodSU4Ug9lWHzYSxMcKdfrd2q3ZzpCx9DUyUZDxHctnWsWmxExw9tdTRXs4Yv1N64TbFmMHcfZB7jUh8qXHhBHyMLIJx27Ov7Q407W+/sShvDFtRYrK4JjkExeHvxp5UjEIB3miQXm5o+ckP+UGGYYgCJkDgrj6956pEV2PWexVqwUBDhMGRb0OF301xEwzExp1j8OpUxwK+lDfKwj6cKCOTEoforzeHA== X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2178; 31:25KmRPXp17ZIOFo+MEvVjms9eawO+hDgxt9MMsJf0e6+vYD8BE+ECypob+kZUzDMFrkU+PfssYBcezOVsqVHRaaRZWSldlF7l02C5gHi6wxYM293yuqNLsokZL5XFKvYVUnCnZNBhZ0lP2RilNLiUzTK4PROGeiAjTizlVQLQeX5hgp9EcppSi4/FL0jG69qnCL00vXm8E4OKS+VIZhLmecSD5EEyhK5g/4jP3Rd28c=; 20:VI/3rVf03gMIgGgfcFUXqboTcb/Ck4qRpMNvh27rLn+zT4xZhMoLbl1IOI73xHaAU6r2olZFWAc7Dd9vG45iGo6JnWhIPtQNj9e3mgmtkIDmuCXOrmJkFKJisiMCzsP5xDz/MfDY9/yMBWupXFAmK0d/r3OnYkmZHj1RIU18piKKV78zr2XHGfAZ8evTbadE2C+JZbVEYbl5TIffwxVxKbxOXt/Bgo0rJU3+GPKB3kUioVuJJQG8PibFOSvBPPS04JCp7qdvN8sHpW6y/Rx0VoTswsHt3J0+1e0dypwiWSq2BfcHEwLILdZvSLTfMJ/bKS4SVfrpyG/LbylxY4gVkQpc6u8EskWXPSBXBZ2I8uQzIZDQ2Lf+GUfPUnVwJOVS3WgK5CHVrSWi+hlI5eLnElx1yIMwk8BHJeZL+DMmphrLmk/iVN8GFTvT5SfdDxekdIChmsu7PedPTGCdoxBAEPxR4hJJnyds2eBlmw9wPfIpraLxgQh6p4IInwcFvb7aLQBNIrErrb20bnKs2mriGyIP343f8AG14IsTTUIhCL5a4oU1q7SRaXIa3UZgU8WAeToCl4Ac0mLmaCBIVtir2LR5NmAEgXtqqfCCj+IHC8k= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(100405760836317); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123562025)(20161123558025)(20161123564025)(20161123555025)(20161123560025)(6072148); SRVR:BL2PR05MB2178; BCL:0; PCL:0; RULEID:; SRVR:BL2PR05MB2178; X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2178; 4:2XsIaicOMXWMAGu287KlLJvp1UbGChoAxpq9tsoRuqdaj0BK+fy2xouHYKnutDIQ6M9YjZNpE5TbPbSbGN7c1XpLseeb33g3V80lCXmjVSfLwuwDMVzpBvw2MycsErF2QEf374bRoKBiv46/NeF4Vkntq38UGqzp4meN5zu2jPnqAOUIrPgR2Q+Dk8+VaJxlmONvOT0LJwWtJhBbmR0Z2urenNpgyMg1SJCajXBlYCohGCtnczpTQRXbjpjuY98ZBY3ziLse0BFOF1fLzSSuBZKMPUGw1CSBE+Py9S4RNVn2aIxAqiDQCrJQ+5pVIl1Hm9K8ZJJ564EDaMju/NYV6LBJLjxoX03LR74dzvycy/TX5Ee+c3fqY+6ZS5/FH6nBFTI52G0SxwjxhhhYksdfIBTgSpQB1QjOo91YV4UHqqSajDxGNkvCWQLOo/v8vMUbvunH0bMuEKtwaHsF79xecq2n/YcUg0uVGSJhdTygUTRjSb2tPtRB+bPjvAZUaTMzNqH+6a+AfDDBTjNXBHNQGIuRWu6024E6MBN7/XHMATRlmsroN4q909LJ4shMh2uNCo9gvwTJkYFLzT5AtXUK27JMs9iqOBz10Cl/8zYith0nVYlM6p3fllF6GkC5J+xae6rd1kGHh6Na2BLGaPOLR5fwLeY64l0PMiQCp2mg7j4= X-Forefront-PRVS: 0255DF69B9 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(39450400003)(39860400002)(39840400002)(39850400002)(39410400002)(377454003)(24454002)(8676002)(54906002)(6246003)(7736002)(83506001)(36756003)(81166006)(53936002)(6116002)(3846002)(84326002)(790700001)(54896002)(2950100002)(38730400002)(4001350100001)(6636002)(5660300001)(65826007)(4326008)(15187005004)(189998001)(50986999)(77096006)(54356999)(1941001)(6486002)(86362001)(65956001)(66066001)(31696002)(25786009)(2906002)(42186005)(33646002)(3260700006)(53546009)(90366009)(512944002)(229853002)(230783001)(93886004)(76176999)(163123001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR05MB2178; H:[172.29.33.229]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BL2PR05MB2178; 23:dqGg/utoQMP6oONWmshT2bMn0M0dcYsC+Ru+BTYm4?= =?us-ascii?Q?duWnujbDJJyT84Pbv0ks2/hcxwDfsItV8MoEwCkspvaym/dMF1sRLrAgZJs8?= =?us-ascii?Q?czZ7Ti1qpUbZ2SMx0vG3CwO7UkE9GfyczYOTp9/Pt6jsl1uYZ/npZP0tHuFF?= =?us-ascii?Q?G/3FI+XJ5tpzOxh50d8KTSWGXkqjK+V1p+ZIfZBbTsaQrR4G4/tFFdCL15mp?= =?us-ascii?Q?+FZhrml8V8LBBAQ4PqqcZE+8cXouD/uCj310BUWIEXfdBBkuoI+s0Hre+Liq?= =?us-ascii?Q?IeCv5VStQYYqtF1o8yFPAGyW6r2xA8W6UAyDSX47TFjaba1tQqvgr4whVCRF?= =?us-ascii?Q?dVVF9tHLHMgt7PudlaPwaVtklF5d3x2bFLQTAsMCaACx6uTqtrCMQZ2xwmbE?= =?us-ascii?Q?ZHbVotpa6IQmgrwIo1ZKsgImUbXU87Brx1n+WRduqiQvwn6oskA4tjkmndvx?= =?us-ascii?Q?gSRdoxbdza9zj4uupNZFRV34q9nXVO3ZRY5sOouwGwyuo8XvwkTLeBj+zwn0?= =?us-ascii?Q?VBcWKqoaUulsuIrhonXqXezXhU1QniKjR/R9IeJ4MCghL9HLaN0uFNIoWc2X?= =?us-ascii?Q?6scwPW6nLbEG98fx7OZtZxWGTosSDRwMgveAdUCjXgr+M6ZRg5F0mMv0FBBn?= =?us-ascii?Q?lqbAx2q7cqIFJvTqy0mEOa6fkkTAvm0PiOvKE5vrGylAsa0FOhwAX/7Vn74G?= =?us-ascii?Q?QKRaHZPWiVif/qEYDN+3rms7s3Da9xb0iEhEnJEP21K5nHFCYQy9u6MCOBsa?= =?us-ascii?Q?s+Q4mlyGPwO5o4c96sE0ULpO6Mi4wdwIOwOpc7lcYVw6uxajdO13I2+3l7l6?= =?us-ascii?Q?Oh2fQgIR3Yj5NmQUvnvLBbvKgdK8lynfxw3tRjrghxl5KB7k59bI7w1WQfyC?= =?us-ascii?Q?Q2vmrPYXn4ZjvFiqIa7iDk7+W7FY9p2Q/JeitT2vawB7MU0NTXkn6z4sVDA2?= =?us-ascii?Q?bFgDIJ5no48er9AJ8qHAOarxS6RHaw9iAw9RYmV77Ora2tEzitfVdM0bDT2x?= =?us-ascii?Q?l0v401bwRsfFPYNZEAM3JiSKmIQYxy3/TwDGvCoH4lW5/2l9en+EjhKc7wCC?= =?us-ascii?Q?bm1N5e98EfMTHUtThSwjfGrVszGBAZ7rj4uFDvJ+wH63oVlVruCqI7IpoSeL?= =?us-ascii?Q?vz1R24ml4IMMLtztGyVQYTKhs9yzo530tktat2M5CJagfmDk7ZiYBebgn6YG?= =?us-ascii?Q?8r9qWyRjI7P6ioAHRT+eSpJTCshxsm1Y42QeXsEeeMv88ENhNSQ6e7jDRu8q?= =?us-ascii?Q?DTC4zRaBLaK4h4d5daSgk5TMBZ8JhjXbhEomRPofCeE4xDmVAycV+VvsoayN?= =?us-ascii?Q?Xw6BpfAnXezD1uxHrJhiSAJpfTNA0iZ2LAJcqRykNTJ?= X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2178; 6:ebWFvNq+Bk08fU2GSqDItobKDTDSMLH1QlAzWeYe/cvWQWOH3bUfxHGHJqR7pT5F4wxGmfTKBp5+1GqFWU6yGWuFbMXlwv0U+rc69AGzmuNSURdBEveqyr99gvYzN5+4abY8zxpoLAu5R8L39QyUDSgmSgDJAPKLjJWsoETUzyazA2MYiZu6bp2ucppth+idt+EUJwTQtCou9OhAsgA0fHqVSW7kQsCPN0AUKZmTAXXLoypzIfyeWw7CipIyNi+0MescPMFdnJy6f0xx15+cUQXkoTHoB+AHo9NWBPOpuEkgEVED3u/0sIyKvXfV3KV4ViMqP8AMdu15czurEL1V7y8Iurd5Hfg9jckPOKW586JBQdnXh2RizJmN32pJ2bBKowh1H58ADQQIxrrSLrqQ39/1iNMUQYLuKf9kPhb8MHw=; 5:wriVrWpyxrZ3At8i/3r58zLh12Waki9dOkm1b/q3Q5udxBk8wV8xmyEhamZm5zbf8RiBmC8cJjssPqgfvq9GHMjX2LbUD7uMZJqzlK1m+FbmtTjv9Oqd91S5UKIj46OVFW2w84QvmyU1smtIGae7Ug==; 24:cJQOSF8tHB1Zf8BX2foV9SNR4qA/EnpobsBhdQWPh1x0I+coqip8XMYUOoZHHL+kIf8SUENssRvRcQ5Y+LmJ3BmQFmpCHdXW5pyWVN61ooA= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2178; 7:KFQK+B4uBRIoihBcDnqus1J6smB+x2Ya+fsclGYk/aOBiRnSVYHuU6+8Jzz+HqiaXUYZHT4RSF0DdwFQifHosKKR0R5N7OaAhuMjNGDLC2ra33ldWk0diWccOnE1YdQZp3rwVxdVgcV3bIDzYJe1TjXpEv+6qNOzh1DQ3+qJjmwrl5Rwp1O2sG+52+coiJ11sIgtanaNHLUa/tnMUDN4umTuypx47Z8kV6UPievePdIvRUKsfC7uwaqbozN8ekTtT4PijdnxgNdnYqREUKlaOYyQiOCLX+zcqWF9CoieEWI2q4SXDX/R275IL61fLX4e7SV1/b6RRuxGikZ+bSAyxQ== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Mar 2017 18:51:05.5906 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR05MB2178 Archived-At: Subject: Re: [Idr] Thoughts on https://www.ietf.org/id/draft-hares-idr-bgp-registries-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 18:51:11 -0000 --------------C3E16E4C47A8ED2EFB73CB93 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit On 3/23/2017 1:46 PM, Susan Hares wrote: > > 1)IETF consensus trumps DE opinion - If you are suggesting that the > WG chair(s) that sponsored a draft should not be the Designated Expert. > That was not my suggestion. > 2)Adequate review – If you wish it to be a single working group > assigning BGP code points, > That was not my suggestion either. > 4)On code point squatting, operators had real problems with the > current situation. Job said “automatic checks on drafts”, Sue said > “IETF Standard + DE of BGP chairs where IETF Consensus wins” > My point is that neither of these solutions will solve the problem. They simply create more process and just make the problem worse. The problem is real, the solutions are bogus. --------------C3E16E4C47A8ED2EFB73CB93 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit On 3/23/2017 1:46 PM, Susan Hares wrote:

     

    1)      IETF consensus trumps  DE opinion -   If you are suggesting that the WG chair(s) that sponsored a draft should not be the Designated Expert. 


    That was not my suggestion. 

    2)      Adequate review –  If you wish it to be a single working group assigning BGP code points,


    That was not my suggestion either.

    4)      On code point squatting, operators had real problems with the current situation.   Job said “automatic checks on drafts”,  Sue said “IETF Standard + DE of BGP chairs where IETF Consensus wins”


    My point is that neither of these solutions will solve the problem.  They simply create more process and just make the problem worse.

    The problem is real, the solutions are bogus.


    --------------C3E16E4C47A8ED2EFB73CB93-- From nobody Thu Mar 23 12:01:33 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28D6B129890 for ; Thu, 23 Mar 2017 12:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qxOCY58qohDw for ; Thu, 23 Mar 2017 12:01:29 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6ECA513162C for ; Thu, 23 Mar 2017 12:01:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=553; q=dns/txt; s=iport; t=1490295674; x=1491505274; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=b5wXY5gi6iQLH2RaJAyxc5QaqmNBQBYiX9e1RDMmwko=; b=ItcnuEoaXkC+MreDAHsGnVctE9IbBiVf1w36FqLBZ6+Osnmir9zjvolL bnOi1Zwb8dZwqCmY8c1ADJlPIp1JoZ0M1WZWGggRlZG0dzKOCIqAEyH5Q ihIEsbxeoPNq0exUeZJAywKUCU2oeHn5yH1vgADfBm5YDddRrgWx/fPKD Y=; X-IronPort-AV: E=Sophos;i="5.36,211,1486425600"; d="scan'208";a="402107558" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Mar 2017 19:01:13 +0000 Received: from [10.41.57.0] ([10.41.57.0]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v2NJ1Cp9026843; Thu, 23 Mar 2017 19:01:12 GMT To: Eric C Rosen References: <048701d29cd9$15204b80$3f60e280$@olddog.co.uk> <022201d29ce6$ffb2ba40$ff182ec0$@ndzh.com> <02dc01d2a25b$a1eca590$e5c5f0b0$@ndzh.com> <3b9c229a-4573-c586-8627-3a8c38539ff8@juniper.net> Cc: "John G. Scudder" , Susan Hares , idr@ietf.org, Enke Chen From: Enke Chen Message-ID: <0271cbf9-b892-463e-34b4-f3af7bea5bdf@cisco.com> Date: Thu, 23 Mar 2017 12:01:11 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Idr] Thoughts on https://www.ietf.org/id/draft-hares-idr-bgp-registries-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 19:01:31 -0000 Eric, On 3/23/17 10:29 AM, Eric C Rosen wrote: [snip] > Ultimately all type fields will be two-octets long with FCFS registration; that's the > ultimate solution to this particular red tape problem. Not only the type fields, but also the length fields in TLVs. Given the processing power and memory, there is hardly any reason for having one-byte type or length fields in TLV definitions. We have been burned too many times. This is something that should be high on the list of fixes if there is ever a BGP-5. Thanks. -- Enke From nobody Thu Mar 23 12:07:55 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C42D129BC8 for ; Thu, 23 Mar 2017 12:07:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.947 X-Spam-Level: X-Spam-Status: No, score=0.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQZYRwTZjTxz for ; Thu, 23 Mar 2017 12:07:52 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 12BE9129B40 for ; Thu, 23 Mar 2017 12:07:51 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=70.194.5.9; From: "Susan Hares" To: "'Acee Lindem \(acee\)'" , References: <01c101d2a362$9b0feb80$d12fc280$@ndzh.com> In-Reply-To: Date: Thu, 23 Mar 2017 15:02:46 -0400 Message-ID: <009901d2a408$0f727a60$2e576f20$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_009A_01D2A3E6.88634B60" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIjntrJ1OvrQqBz2zRGPcIIzhG8agIY+czioPAHcmA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] draft-ietf-idr-bgp-gr-notification - 1 week call for comments on early adoption (3/21 to 3/30) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 19:07:54 -0000 This is a multipart message in MIME format. ------=_NextPart_000_009A_01D2A3E6.88634B60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Acee: You raise a good point. John and I debated the topic earlier this week. However, since one of the co-chairs is a co-author, we decided it was best to review until 3/30. John made the point that he cannot change the draft until 3/27, and Alvaro will need the changed draft for IANA. Alvaro is copied, and I will talk to IANA to make sure they can process this quickly. Could you help us update the implementation part for cisco? Sue From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Acee Lindem (acee) Sent: Wednesday, March 22, 2017 7:30 PM To: Susan Hares; idr@ietf.org Subject: Re: [Idr] draft-ietf-idr-bgp-gr-notification - 1 week call for comments on early adoption (3/21 to 3/30) Hi Sue, Since early code point assignment is a topic in another thread and the specter of bureaucracy was raised, I'd like to question as to why we need an early adoption call? Since the document has already been accepted as a WG document and there is implementation interest, isn't that enough to warrant early code point adoption? Thanks, Acee From: Idr on behalf of Susan Hares Date: Wednesday, March 22, 2017 at 7:18 PM To: IDR List Subject: [Idr] draft-ietf-idr-bgp-gr-notification - 1 week call for comments on early adoption (3/21 to 3/30) Greetings IDR: As John Scudder notes draft-ietf-idr-bgp-gr-notification-10.txt will be changed to have no suggested value. IANA is requested to assign a new subcode in the "BGP Cease NOTIFICATION message subcodes" registry. The suggested name for the code point is "Hard Reset". The suggested value is 9. Given this change, the IDR WG is asked to consider early code-point adoption for draft-ietf-idr-bgp-gr-notification, and any additions they wish to make on the last WG LC (which found consensus). With more details on 2 implementations (Cisco and Juniper), this will be forwarded to the IESG. If you wish to send any additional comments, since John is a co-authors - please send them to me or to Jie Dong. Jie will provide me a summary of comments he's received. Will Cisco and Juniper people, please update the wiki page on the implementation. The authors an provide a section in the draft (if they wish) with implementation - which will be removed before publication. Sue Hares ------=_NextPart_000_009A_01D2A3E6.88634B60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Acee:

     

    You raise a good = point.  John and I debated the topic earlier this week.  = However, since one of the co-chairs is a co-author, we decided it was = best to review until 3/30.   John made the point that he = cannot change the draft until 3/27, and Alvaro will need the changed = draft for IANA.   Alvaro is copied, and I will talk to IANA to = make sure they can process this quickly.  

     

    Could you help us update = the implementation part for cisco?

     

    Sue =

     

     

    From:= = Idr [mailto:idr-bounces@ietf.org] On Behalf Of Acee Lindem = (acee)
    Sent: Wednesday, March 22, 2017 7:30 PM
    To: = Susan Hares; idr@ietf.org
    Subject: Re: [Idr] = draft-ietf-idr-bgp-gr-notification - 1 week call for comments on early = adoption (3/21 to 3/30)

     

    Hi = Sue, 

     

    =

    Since early code point assignment = is a topic in another thread and the specter of bureaucracy was raised, = I’d like to question as to why we need an early adoption call? =  Since the document  has already been accepted as a WG = document and there is implementation interest, isn’t that enough = to warrant early code point = adoption? 

     

    =

    Thanks,

    Acee

     

    =

    From: = Idr <idr-bounces@ietf.org> on = behalf of Susan Hares <shares@ndzh.com>
    Date: = Wednesday, March 22, 2017 at 7:18 PM
    To: IDR List <idr@ietf.org>
    Subject: = [Idr] draft-ietf-idr-bgp-gr-notification - 1 week call for comments = on early adoption (3/21 to 3/30)

     

    =

    Greetings IDR: =

     

    As John Scudder notes = draft-ietf-idr-bgp-gr-notification-10.txt  will be changed to have = no suggested value. 

     

     

       IANA is requested to assign a new subcode = in the "BGP Cease

       NOTIFICATION message subcodes" = registry.  The suggested name for the

       code point is "Hard = Reset".  The suggested value is 9.

     

    Given this change, the IDR WG is asked to consider = early code-point adoption for draft-ietf-idr-bgp-gr-notification, and = any additions they wish to make on the last WG LC (which found = consensus).   With more details on 2 implementations (Cisco = and Juniper), this will be forwarded to the IESG.  If you wish to = send any additional comments, since John is a co-authors – please = send them to me or to Jie Dong.   Jie will provide me a = summary of comments he’s received.

     

    Will Cisco and Juniper = people, please update the wiki page on the implementation.   = The authors an provide a section in the draft (if they wish) with = implementation – which will be removed before publication.  =

     

    Sue Hares =

     

    ------=_NextPart_000_009A_01D2A3E6.88634B60-- From nobody Thu Mar 23 12:12:09 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA68A129BEF for ; Thu, 23 Mar 2017 12:12:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.957 X-Spam-Level: X-Spam-Status: No, score=0.957 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SevGmDpIKj-O for ; Thu, 23 Mar 2017 12:12:06 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 4EFAE1296CD for ; Thu, 23 Mar 2017 12:12:06 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=70.194.5.9; From: "Susan Hares" To: "'Eric C Rosen'" , "'John G. Scudder'" Cc: References: <048701d29cd9$15204b80$3f60e280$@olddog.co.uk> <022201d29ce6$ffb2ba40$ff182ec0$@ndzh.com> <02dc01d2a25b$a1eca590$e5c5f0b0$@ndzh.com> <3b9c229a-4573-c586-8627-3a8c38539ff8@juniper.net> <050901d2a3fd$734b3e10$59e1ba30$@ndzh.com> In-Reply-To: Date: Thu, 23 Mar 2017 15:06:59 -0400 Message-ID: <00a601d2a408$a61f52d0$f25df870$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A7_01D2A3E7.1F0E9D30" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHgLJVhftftdlZ2OeQGM5dxbx7ZtQIfusEjApalZLoB3VIuCQJnQvCHApVdmPIBwb1GPgECN7t0Ahi7s66hBE8oUA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] Thoughts on https://www.ietf.org/id/draft-hares-idr-bgp-registries-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 19:12:08 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00A7_01D2A3E7.1F0E9D30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Eric: Thank you for the clarification. Suggest your solution in a draft if you believe it is complete. I only care that operators problems are fixed. Cheerily, Sue From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Eric C Rosen Sent: Thursday, March 23, 2017 2:51 PM To: Susan Hares; 'John G. Scudder' Cc: idr@ietf.org Subject: Re: [Idr] Thoughts on https://www.ietf.org/id/draft-hares-idr-bgp-registries-01.txt On 3/23/2017 1:46 PM, Susan Hares wrote: 1) IETF consensus trumps DE opinion - If you are suggesting that the WG chair(s) that sponsored a draft should not be the Designated Expert. That was not my suggestion. 2) Adequate review - If you wish it to be a single working group assigning BGP code points, That was not my suggestion either. 3) On code point squatting, operators had real problems with the current situation. Job said "automatic checks on drafts", Sue said "IETF Standard + DE of BGP chairs where IETF Consensus wins" My point is that neither of these solutions will solve the problem. They simply create more process and just make the problem worse. The problem is real, the solutions are bogus. ------=_NextPart_000_00A7_01D2A3E7.1F0E9D30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Eric:

    <wg chair hat off>

    <individual contributor hat on>

    Thank you for the clarification.   Suggest your solution in = a draft if you believe it is complete.  I only care that operators = problems are fixed.

    <individual contributor hat off>

     

    Cheerily, Sue

     

    From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Eric C = Rosen
    Sent: Thursday, March 23, 2017 2:51 PM
    To: = Susan Hares; 'John G. Scudder'
    Cc: = idr@ietf.org
    Subject: Re: [Idr] Thoughts on = https://www.ietf.org/id/draft-hares-idr-bgp-registries-01.txt<= /span>

     

    On 3/23/2017 1:46 PM, Susan Hares = wrote:

     

    1)      = IETF consensus trumps  DE opinion -   If you are = suggesting that the WG chair(s) that sponsored a draft should not be the = Designated Expert. 


    That was not my suggestion.  =


    2)      = Adequate review –  If you wish it to be a single working = group assigning BGP code points,


    That was not my suggestion = either.


    3)      = On code point squatting, operators had real problems with the current = situation.   Job said “automatic checks on = drafts”,  Sue said “IETF Standard + DE of BGP chairs = where IETF Consensus wins”


    My point is that = neither of these solutions will solve the problem.  They simply = create more process and just make the problem worse.

    The problem = is real, the solutions are = bogus.

    ------=_NextPart_000_00A7_01D2A3E7.1F0E9D30-- From nobody Thu Mar 23 12:14:48 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB22012986E for ; Thu, 23 Mar 2017 12:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ojGc4PZ4y9iJ for ; Thu, 23 Mar 2017 12:14:45 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 4DB8C13162D for ; Thu, 23 Mar 2017 12:14:28 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=70.194.5.9; From: "Susan Hares" To: "'Jeffrey Haas'" Cc: "'Eric C Rosen'" , "'John G. Scudder'" , References: <048701d29cd9$15204b80$3f60e280$@olddog.co.uk> <022201d29ce6$ffb2ba40$ff182ec0$@ndzh.com> <02dc01d2a25b$a1eca590$e5c5f0b0$@ndzh.com> <3b9c229a-4573-c586-8627-3a8c38539ff8@juniper.net> <050901d2a3fd$734b3e10$59e1ba30$@ndzh.com> <20170323181052.GL27015@pfrc.org> <001f01d2a401$1fc173a0$5f445ae0$@ndzh.com> <20170323184608.GM27015@pfrc.org> In-Reply-To: <20170323184608.GM27015@pfrc.org> Date: Thu, 23 Mar 2017 15:09:19 -0400 Message-ID: <00b301d2a408$f975b460$ec611d20$@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: AQHgLJVhftftdlZ2OeQGM5dxbx7ZtQIfusEjApalZLoB3VIuCQJnQvCHApVdmPIBwb1GPgECN7t0AgoLdiwB6VksPAE6yA/0oOukvgA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] Thoughts on https://www.ietf.org/id/draft-hares-idr-bgp-registries-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 19:14:47 -0000 Thanks for the ideas! 1) boilerplate text for allocations, 2) flagged issues to one WG 3) cross-WG review button in datatracker. Sue -----Original Message----- From: Jeffrey Haas [mailto:jhaas@pfrc.org] Sent: Thursday, March 23, 2017 2:46 PM To: Susan Hares Cc: 'Eric C Rosen'; 'John G. Scudder'; idr@ietf.org Subject: Re: [Idr] Thoughts on https://www.ietf.org/id/draft-hares-idr-bgp-registries-01.txt On Thu, Mar 23, 2017 at 02:13:07PM -0400, Susan Hares wrote: > - If flagging for more eye review is the case, then Job's suggestion > is the way forward. It works for most YANG modules. As I noted off-list to Job, pattern matching works great when you have a pattern that can catch it. Better than nothing, especially if we end up with good boilerplate text for allocations. (It might be worth having a chat with IANA about that.) > - If having the expertise to review the "flag" is the issue, 1 WG > being in charge of the situation will suffice with the current setup. > - if cross-review in all BGP working group is issue - then try my > registries proposal + IETF consensus. > - if distrust of a single answer from WG shepherd, WG chair or set of > WG chairs - this draft + Eric's suggestion for who can review. Mostly, I think once an issue is flagged, all eyes need to be pulled to one place. For the registries in question, IDR@ietf is probably fine, as long as we reach out. While I share some of Eric's dislike of process, I don't quite share his paranoia about process blockers. When things go awry anyway, the best we have in process is the appeals process. If we've reached that point, speed is doomed anyway. > If we can define the largest concern(s), let's we could start with > that solution. I'd suggest finding a way to flag stuff is appropriate. Nits search is one. Allowing chairs to prod a button in datatracker that says cross-WG review is needed might be another. I suspect this may make good wgchairs discussion. -- Jeff From nobody Thu Mar 23 13:17:11 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87C91131648; Thu, 23 Mar 2017 13:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AVoGpe_H90Yo; Thu, 23 Mar 2017 13:17:09 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 81F291315D3; Thu, 23 Mar 2017 13:17:09 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cr9AO-0007Ar-BF; Thu, 23 Mar 2017 20:17:04 +0000 Date: Thu, 23 Mar 2017 15:17:04 -0500 Message-ID: From: Randy Bush To: Gert Doering Cc: Brian Dickson , "idr@ietf.org" , "draft-ietf-idr-route-leak-detection-mitigation.authors@ietf.org" , "sidrops@ietf.org" , "Sriram, Kotikalapudi (Fed)" , "sidr wg list (sidr@ietf.org)" , "grow@ietf.org" In-Reply-To: <20170323075008.GL2367@Space.Net> References: <20170321205513.GA2367@Space.Net> <20170322143302.GG2367@Space.Net> <20170323075008.GL2367@Space.Net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Idr] [sidr] operator inputs -- route leak solution X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 20:17:10 -0000 >> The deployment is self-serving; whoever turns this on protects themselves >> and their downstream customers. > > Those that are interested in doing so already do customer route filtering > today. if god had meant us to fly in planes, she would not have given us trains. oh wait, americans don't have trains. :) randy From nobody Thu Mar 23 14:09:55 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDF72131677 for ; Thu, 23 Mar 2017 14:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ohL-aUDF5C6L for ; Thu, 23 Mar 2017 14:09:52 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09446129C11 for ; Thu, 23 Mar 2017 14:09:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15059; q=dns/txt; s=iport; t=1490303391; x=1491512991; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=sEK+nPWL0VRG+n/Gjg9TrZwDe+ZqxFtNjacTnGRCI5A=; b=QBHwWKiHDLbam5BlQjHba7zCMQkJ/h9Yau6bNTEtShZprPVfGRmc4/LU Svq1/CN7HvjKLLP21dDGyuvx1VqDP6VyIttQlar/9e44Nvintwh4GdILm fsMRemKCV76211tkn13IDhCwmvllGUhZcmu7j0anSaxrWFup1OrKCDYbH w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AmAQBLONRY/5tdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5jYYELB41qkU+QGYUwgg6GIgKDGD8YAQIBAQEBAQEBayiFFQE?= =?us-ascii?q?BAQEDHRBKAhACAQgOAwMBAQEkBAcyFAkIAQEEAQ0FigasYIpGAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBHYs9hHQWhS8BBI9eQYw2AZJJgXuFKooKiFeLCgEfOIEEWRV?= =?us-ascii?q?BPIRSgUp1iHyBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.36,211,1486425600"; d="scan'208,217";a="213722576" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Mar 2017 21:09:50 +0000 Received: from XCH-RTP-001.cisco.com (xch-rtp-001.cisco.com [64.101.220.141]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v2NL9o1n002879 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 23 Mar 2017 21:09:50 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-001.cisco.com (64.101.220.141) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 23 Mar 2017 17:09:49 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Thu, 23 Mar 2017 17:09:49 -0400 From: "Acee Lindem (acee)" To: Susan Hares , "idr@ietf.org" Thread-Topic: [Idr] draft-ietf-idr-bgp-gr-notification - 1 week call for comments on early adoption (3/21 to 3/30) Thread-Index: AdKjYemMcYaL/ySSRFieixhO0TATbgAAkkqAADFYwgD//+BtAA== Date: Thu, 23 Mar 2017 21:09:49 +0000 Message-ID: References: <01c101d2a362$9b0feb80$d12fc280$@ndzh.com> <009901d2a408$0f727a60$2e576f20$@ndzh.com> In-Reply-To: <009901d2a408$0f727a60$2e576f20$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.196] Content-Type: multipart/alternative; boundary="_000_D4F9B15AA3E32aceeciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] draft-ietf-idr-bgp-gr-notification - 1 week call for comments on early adoption (3/21 to 3/30) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 21:09:54 -0000 --_000_D4F9B15AA3E32aceeciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Sue, Sounds good. I will follow up on Cisco implementation or intent to implemen= t. Independent of our BGP roadmap, I would support allocation if anyone is = interested in implementing it since I believe it is a useful extension. Thanks, Acee From: Susan Hares > Date: Thursday, March 23, 2017 at 3:02 PM To: Acee Lindem >, IDR List > Cc: "Alvaro Retana (aretana)" > Subject: RE: [Idr] draft-ietf-idr-bgp-gr-notification - 1 week call for com= ments on early adoption (3/21 to 3/30) Acee: You raise a good point. John and I debated the topic earlier this week. H= owever, since one of the co-chairs is a co-author, we decided it was best t= o review until 3/30. John made the point that he cannot change the draft = until 3/27, and Alvaro will need the changed draft for IANA. Alvaro is co= pied, and I will talk to IANA to make sure they can process this quickly. Could you help us update the implementation part for cisco? Sue From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Acee Lindem (acee) Sent: Wednesday, March 22, 2017 7:30 PM To: Susan Hares; idr@ietf.org Subject: Re: [Idr] draft-ietf-idr-bgp-gr-notification - 1 week call for com= ments on early adoption (3/21 to 3/30) Hi Sue, Since early code point assignment is a topic in another thread and the spec= ter of bureaucracy was raised, I'd like to question as to why we need an ea= rly adoption call? Since the document has already been accepted as a WG d= ocument and there is implementation interest, isn't that enough to warrant = early code point adoption? Thanks, Acee From: Idr > on behalf of = Susan Hares > Date: Wednesday, March 22, 2017 at 7:18 PM To: IDR List > Subject: [Idr] draft-ietf-idr-bgp-gr-notification - 1 week call for comment= s on early adoption (3/21 to 3/30) Greetings IDR: As John Scudder notes draft-ietf-idr-bgp-gr-notification-10.txt will be ch= anged to have no suggested value. IANA is requested to assign a new subcode in the "BGP Cease NOTIFICATION message subcodes" registry. The suggested name for the code point is "Hard Reset". The suggested value is 9. Given this change, the IDR WG is asked to consider early code-point adoptio= n for draft-ietf-idr-bgp-gr-notification, and any additions they wish to ma= ke on the last WG LC (which found consensus). With more details on 2 impl= ementations (Cisco and Juniper), this will be forwarded to the IESG. If yo= u wish to send any additional comments, since John is a co-authors - please= send them to me or to Jie Dong. Jie will provide me a summary of comment= s he's received. Will Cisco and Juniper people, please update the wiki page on the implement= ation. The authors an provide a section in the draft (if they wish) with = implementation - which will be removed before publication. Sue Hares --_000_D4F9B15AA3E32aceeciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
    Hi Sue, 
    Sounds good. I will follow up on Cisco implementation or intent to imp= lement. Independent of our BGP roadmap, I would support allocation if anyon= e is interested in implementing it since I believe it is a useful extension= .
    Thanks,
    Acee

    From: Susan Hares <shares@ndzh.com>
    Date: Thursday, March 23, 2017 at 3= :02 PM
    To: Acee Lindem <acee@cisco.com>, IDR List <idr@ietf.org>
    Cc: "Alvaro Retana (aretana)&q= uot; <aretana@cisco.com>
    Subject: RE: [Idr] draft-ietf-idr-b= gp-gr-notification - 1 week call for comments on early adoption (3/21 to 3/= 30)

    Acee:

     

    You raise a good point= .  John and I debated the topic earlier this week.  However, sinc= e one of the co-chairs is a co-author, we decided it was best to review unt= il 3/30.   John made the point that he cannot change the draft until 3/27, and Alvaro will need the changed draft for IA= NA.   Alvaro is copied, and I will talk to IANA to make sure they= can process this quickly.  

     

    Could you help us upda= te the implementation part for cisco?

     

    Sue =

     

     

    From: Idr [mailt= o:idr-bounces@ietf.org] On Behalf Of Acee Lindem (acee)
    Sent: Wednesday, March 22, 2017 7:30 PM
    To: Susan Hares; idr@ietf.org Subject: Re: [Idr] draft-ietf-idr-bgp-gr-notification - 1 week call = for comments on early adoption (3/21 to 3/30)

     

    Hi Sue,=  

    &n= bsp;

    Since e= arly code point assignment is a topic in another thread and the specter of = bureaucracy was raised, I’d like to question as to why we need an ear= ly adoption call?  Since the document  has already been accepted as a WG document and there is implementation interes= t, isn’t that enough to warrant early code point adoption? =

    &n= bsp;

    Thanks,=

    Acee

    &n= bsp;

    From: Idr <idr= -bounces@ietf.org> on behalf of Susan Hares <shares@ndzh.com>
    Date: Wednesday, March 22, 2017 at 7:18 PM
    To: IDR List <idr@ietf.org>= ;
    Subject: [Idr] draft-ietf-idr-bgp-gr-notification - 1 week call for = comments on early adoption (3/21 to 3/30)

    &n= bsp;

    Greetings IDR:

     =

    As John Scudder notes dr= aft-ietf-idr-bgp-gr-notification-10.txt  will be changed to have no su= ggested value. 

     =

    Given this change, the I= DR WG is asked to consider early code-point adoption for draft-ietf-idr-bgp= -gr-notification, and any additions they wish to make on the last WG LC (wh= ich found consensus).   With more details on 2 implementations (Cisco and Juniper), this will be forwarded to the IE= SG.  If you wish to send any additional comments, since John is a co-a= uthors – please send them to me or to Jie Dong.   Jie will = provide me a summary of comments he’s received.

     =

    Will Cisco and Juniper p= eople, please update the wiki page on the implementation.   The a= uthors an provide a section in the draft (if they wish) with implementation= – which will be removed before publication. 

     =

    Sue Hares

     =

    --_000_D4F9B15AA3E32aceeciscocom_-- From nobody Thu Mar 23 14:21:32 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45272131631 for ; Thu, 23 Mar 2017 14:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.947 X-Spam-Level: X-Spam-Status: No, score=0.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CgadromZ1gGK for ; Thu, 23 Mar 2017 14:21:29 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 07598129A4A for ; Thu, 23 Mar 2017 14:21:28 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=70.194.5.9; From: "Susan Hares" To: "'Acee Lindem \(acee\)'" , References: <01c101d2a362$9b0feb80$d12fc280$@ndzh.com> <009901d2a408$0f727a60$2e576f20$@ndzh.com> In-Reply-To: Date: Thu, 23 Mar 2017 17:16:23 -0400 Message-ID: <001301d2a41a$b9cb2950$2d617bf0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0014_01D2A3F9.32BAE8E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIjntrJ1OvrQqBz2zRGPcIIzhG8agIY+cziAdjvvZcBr9OooqDT6bXg Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] draft-ietf-idr-bgp-gr-notification - 1 week call for comments on early adoption (3/21 to 3/30) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 21:21:31 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0014_01D2A3F9.32BAE8E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thank you. I appreciate the aid filling out the implementation report. Sue From: Acee Lindem (acee) [mailto:acee@cisco.com] Sent: Thursday, March 23, 2017 5:10 PM To: Susan Hares; idr@ietf.org Cc: Alvaro Retana (aretana) Subject: Re: [Idr] draft-ietf-idr-bgp-gr-notification - 1 week call for comments on early adoption (3/21 to 3/30) Hi Sue, Sounds good. I will follow up on Cisco implementation or intent to implement. Independent of our BGP roadmap, I would support allocation if anyone is interested in implementing it since I believe it is a useful extension. Thanks, Acee From: Susan Hares Date: Thursday, March 23, 2017 at 3:02 PM To: Acee Lindem , IDR List Cc: "Alvaro Retana (aretana)" Subject: RE: [Idr] draft-ietf-idr-bgp-gr-notification - 1 week call for comments on early adoption (3/21 to 3/30) Acee: You raise a good point. John and I debated the topic earlier this week. However, since one of the co-chairs is a co-author, we decided it was best to review until 3/30. John made the point that he cannot change the draft until 3/27, and Alvaro will need the changed draft for IANA. Alvaro is copied, and I will talk to IANA to make sure they can process this quickly. Could you help us update the implementation part for cisco? Sue From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Acee Lindem (acee) Sent: Wednesday, March 22, 2017 7:30 PM To: Susan Hares; idr@ietf.org Subject: Re: [Idr] draft-ietf-idr-bgp-gr-notification - 1 week call for comments on early adoption (3/21 to 3/30) Hi Sue, Since early code point assignment is a topic in another thread and the specter of bureaucracy was raised, I'd like to question as to why we need an early adoption call? Since the document has already been accepted as a WG document and there is implementation interest, isn't that enough to warrant early code point adoption? Thanks, Acee From: Idr on behalf of Susan Hares Date: Wednesday, March 22, 2017 at 7:18 PM To: IDR List Subject: [Idr] draft-ietf-idr-bgp-gr-notification - 1 week call for comments on early adoption (3/21 to 3/30) Greetings IDR: As John Scudder notes draft-ietf-idr-bgp-gr-notification-10.txt will be changed to have no suggested value. IANA is requested to assign a new subcode in the "BGP Cease NOTIFICATION message subcodes" registry. The suggested name for the code point is "Hard Reset". The suggested value is 9. Given this change, the IDR WG is asked to consider early code-point adoption for draft-ietf-idr-bgp-gr-notification, and any additions they wish to make on the last WG LC (which found consensus). With more details on 2 implementations (Cisco and Juniper), this will be forwarded to the IESG. If you wish to send any additional comments, since John is a co-authors - please send them to me or to Jie Dong. Jie will provide me a summary of comments he's received. Will Cisco and Juniper people, please update the wiki page on the implementation. The authors an provide a section in the draft (if they wish) with implementation - which will be removed before publication. Sue Hares ------=_NextPart_000_0014_01D2A3F9.32BAE8E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Thank you.  I appreciate the aid filling = out the implementation report.

     

    Sue =

     

    From:= = Acee Lindem (acee) [mailto:acee@cisco.com]
    Sent: Thursday, = March 23, 2017 5:10 PM
    To: Susan Hares; = idr@ietf.org
    Cc: Alvaro Retana (aretana)
    Subject: = Re: [Idr] draft-ietf-idr-bgp-gr-notification - 1 week call for comments = on early adoption (3/21 to 3/30)

     

    Hi = Sue, 

    Sounds good. I will follow up on = Cisco implementation or intent to implement. Independent of our BGP = roadmap, I would support allocation if anyone is interested in = implementing it since I believe it is a useful = extension.

    Thanks,

    Acee

     

    =

    From: = Susan Hares <shares@ndzh.com>
    Date: = Thursday, March 23, 2017 at 3:02 PM
    To: Acee Lindem <acee@cisco.com>, IDR List <idr@ietf.org>
    Cc: = "Alvaro Retana (aretana)" <aretana@cisco.com>
    Subject= : RE: [Idr] draft-ietf-idr-bgp-gr-notification - 1 week call for = comments on early adoption (3/21 to = 3/30)

     

    =

    Acee:

     

    You raise a good point.  John and I debated = the topic earlier this week.  However, since one of the co-chairs = is a co-author, we decided it was best to review until 3/30. =   John made the point that he cannot change the draft until = 3/27, and Alvaro will need the changed draft for IANA. =   Alvaro is copied, and I will talk to IANA to make sure they = can process this quickly.  

     

    Could you help us update the implementation part = for cisco?

     

    Sue

     

     

    = From:= Idr [mailto:idr-bounces@ietf.org] = On Behalf Of Acee Lindem (acee)
    Sent: Wednesday, March = 22, 2017 7:30 PM
    To: Susan Hares; idr@ietf.org
    Subject: Re: = [Idr] draft-ietf-idr-bgp-gr-notification - 1 week call for comments on = early adoption (3/21 to 3/30)

     

    Hi = Sue, 

     

    Since = early code point assignment is a topic in another thread and the specter = of bureaucracy was raised, I’d like to question as to why we need = an early adoption call?  Since the document  has already been = accepted as a WG document and there is implementation interest, = isn’t that enough to warrant early code point = adoption? 

     

    Thanks,

    Acee

     

    From: = Idr <idr-bounces@ietf.org> on = behalf of Susan Hares <shares@ndzh.com>
    Date: = Wednesday, March 22, 2017 at 7:18 PM
    To: IDR List <idr@ietf.org>
    Subject: = [Idr] draft-ietf-idr-bgp-gr-notification - 1 week call for comments = on early adoption (3/21 to 3/30)

     

    Greetings IDR: =

     

    As John Scudder notes = draft-ietf-idr-bgp-gr-notification-10.txt  will be changed to have = no suggested value. 

     

     

       IANA is requested to assign a new subcode = in the "BGP Cease

       NOTIFICATION message subcodes" = registry.  The suggested name for the

       code point is "Hard = Reset".  The suggested value is 9.

     

    Given this change, the IDR WG is asked to consider = early code-point adoption for draft-ietf-idr-bgp-gr-notification, and = any additions they wish to make on the last WG LC (which found = consensus).   With more details on 2 implementations (Cisco = and Juniper), this will be forwarded to the IESG.  If you wish to = send any additional comments, since John is a co-authors – please = send them to me or to Jie Dong.   Jie will provide me a = summary of comments he’s received.

     

    Will Cisco and Juniper = people, please update the wiki page on the implementation.   = The authors an provide a section in the draft (if they wish) with = implementation – which will be removed before publication.  =

     

    Sue Hares =

     

    ------=_NextPart_000_0014_01D2A3F9.32BAE8E0-- From nobody Fri Mar 24 11:53:08 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD2012773A for ; Fri, 24 Mar 2017 11:53:07 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id in4pvt_5QL7T for ; Fri, 24 Mar 2017 11:53:05 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12D111294BE for ; Fri, 24 Mar 2017 11:53:04 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id v2OIr2J6028198; Fri, 24 Mar 2017 18:53:02 GMT Received: from 950129200 ([176.241.250.4]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id v2OIqwqs028158 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Mar 2017 18:53:01 GMT Reply-To: From: "Adrian Farrel" To: "'Susan Hares'" , "'Jeffrey Haas'" Cc: References: <048701d29cd9$15204b80$3f60e280$@olddog.co.uk> <022201d29ce6$ffb2ba40$ff182ec0$@ndzh.com> <02dc01d2a25b$a1eca590$e5c5f0b0$@ndzh.com> <3b9c229a-4573-c586-8627-3a8c38539ff8@juniper.net> <050901d2a3fd$734b3e10$59e1ba30$@ndzh.com> <20170323181052.GL27015@pfrc.org> <001f01d2a401$1fc173a0$5f445ae0$@ndzh.com> <20170323184608.GM27015@pfrc.org> <00b301d2a408$f975b460$ec611d20$@ndzh.com> In-Reply-To: <00b301d2a408$f975b460$ec611d20$@ndzh.com> Date: Fri, 24 Mar 2017 18:52:58 -0000 Message-ID: <038601d2a4cf$dd34db60$979e9220$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHgLJVhftftdlZ2OeQGM5dxbx7ZtQIfusEjApalZLoB3VIuCQJnQvCHApVdmPIBwb1GPgECN7t0AgoLdiwB6VksPAE6yA/0An4Ij2Wg2T8fQA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22964.001 X-TM-AS-Result: No--34.794-10.0-31-10 X-imss-scan-details: No--34.794-10.0-31-10 X-TMASE-MatchedRID: 1ZHks2aQIkgF94UiDfmWytjko+KiQPUGLAnNohUyMa2YjVGk//6gycxF Qxp3PhHyY2lCzQi39ZLy7+YHWQ1L0Rw7NWRnX+2ceUyVZX4ivrvomPrNi98UBED0B37vQ26THME OEYcB5mkm+OJfOTgVT415MIIfJxo1cyxSKSOdP+y3UCG/IQp2PpwW7MPsTONF2qqh/6B8PpGJUU PpIhfF5NRevOMb629aupC6MfP3QBVHRupzdT1rchz2MDiYujy5flWvrY6z7GKabNoYojBQdqiZa OZUGVmqMelH7qhnqUE/0YJS2+Uc1rRgLeduNs8xwgzEIaHq7pclUwMLwz1Qz142zm1Zi+MJVPt4 gQaCtT9NYvDaO9t+nM3Xtn9HtskcfPmUQQG69pydVNZaI2n6/56KYa03LCO2aIwFrkgzXvaPvg6 L6ha7bfDjExc/+7QXN5PbzyayxNRUIV59BFXczo1nuRzhSr7jkUtSee+57IFBQfUgydCNnyOhB/ 49+Z8oeSj+2iiKL68jk/kPI8DPx5YZm9kw6UYUCFaAixm5eU8Lce5ZyDJAJuouc5Rcf1B0KpAHP dqyCcdqH84lsyg+s0am6KBu0q1DVJbgo5fZJ2vcWo5Vvs8MQr5d9p1Y13sKFJ4V2QoSrxetQ9Sc ZTpsKd/K5k+qLCYLkhgvntmboBhVq1v9C2Djn5RrnSy7UTtbH181YDtIVarM7zpEspqG/zpbfdT AcNXm4vM1YF6AJbZcLc3sLtjOt+03P1hii2skseWplitmp0j6C0ePs7A07QKmARN5PTKc Archived-At: Subject: Re: [Idr] Thoughts on https://www.ietf.org/id/draft-hares-idr-bgp-registries-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Mar 2017 18:53:07 -0000 Returning to this after a while away, I wonder whether the problem doesn't have a deeper root and so a simpler solution. The problem could be stated as "Sometimes code points are assigned from BGP registries through IETF consensus documents without proper care." And the perceived solution is that the assignment should be reviewed by suitably knowledgeable people. As Jeff says, "all eyes need to be pulled to one place." I don't think this problem is unique to BGP (although obviously, those involved on this list care most about BGP). Where else does it come up in the IETF and how is it handled? Some working groups are recognised as the centre of expertise for a protocol. There is an expectation that *all* protocol extensions are done in that WG. This is usually captured in the charter so that other WGs know where they stand. Some working groups are recognised as the centre of expertise for a protocol. There is an expectation that *all* protocol extensions will be reviewed by that WG. This is usually captured in the charters of other WGs so they know they must send documents for review. Some protocols are acknowledged to have a base wider than one WG and a Directorate exists to help the ADs by reviewing the documents (just like RTG-Dir). This relies on the review being triggered. I like Sue's 3 points and I think they would catch the majority of cases. They don't, of course, ensure that SNAFUs won't arise. And they don't stop people wilfully dodging. But they are very light touch, and that is to be applauded. Adrian -- Support an author and your imagination. Tales from the Wood - Eighteen new fairy tales. More Tales from the Wood - Eighteen MORE new fairy tales. https://www.feedaread.com/profiles/8604/ http://www.amazon.co.uk/Tales-Wood-Adrian-Farrel/dp/1786100924 Or buy from me direct. > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares > Sent: 23 March 2017 19:09 > To: 'Jeffrey Haas' > Cc: idr@ietf.org > Subject: Re: [Idr] Thoughts on https://www.ietf.org/id/draft-hares-idr-bgp- > registries-01.txt > > Thanks for the ideas! > > 1) boilerplate text for allocations, > 2) flagged issues to one WG > 3) cross-WG review button in datatracker. > > Sue > > -----Original Message----- > From: Jeffrey Haas [mailto:jhaas@pfrc.org] > Sent: Thursday, March 23, 2017 2:46 PM > To: Susan Hares > Cc: 'Eric C Rosen'; 'John G. Scudder'; idr@ietf.org > Subject: Re: [Idr] Thoughts on > https://www.ietf.org/id/draft-hares-idr-bgp-registries-01.txt > > On Thu, Mar 23, 2017 at 02:13:07PM -0400, Susan Hares wrote: > > - If flagging for more eye review is the case, then Job's suggestion > > is the way forward. It works for most YANG modules. > > As I noted off-list to Job, pattern matching works great when you have a > pattern that can catch it. Better than nothing, especially if we end up > with good boilerplate text for allocations. (It might be worth having a > chat with IANA about that.) > > > - If having the expertise to review the "flag" is the issue, 1 WG > > being in charge of the situation will suffice with the current setup. > > - if cross-review in all BGP working group is issue - then try my > > registries proposal + IETF consensus. > > - if distrust of a single answer from WG shepherd, WG chair or set of > > WG chairs - this draft + Eric's suggestion for who can review. > > Mostly, I think once an issue is flagged, all eyes need to be pulled to one > place. For the registries in question, IDR@ietf is probably fine, as long > as we reach out. > > While I share some of Eric's dislike of process, I don't quite share his > paranoia about process blockers. When things go awry anyway, the best we > have in process is the appeals process. If we've reached that point, speed > is doomed anyway. > > > If we can define the largest concern(s), let's we could start with > > that solution. > > I'd suggest finding a way to flag stuff is appropriate. Nits search is one. > Allowing chairs to prod a button in datatracker that says cross-WG review is > needed might be another. I suspect this may make good wgchairs discussion. > > -- Jeff > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Fri Mar 24 12:25:53 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7815E129426 for ; Fri, 24 Mar 2017 12:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uEiehkznLgyP for ; Fri, 24 Mar 2017 12:25:50 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A25BA1293F3 for ; Fri, 24 Mar 2017 12:25:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=525; q=dns/txt; s=iport; t=1490383549; x=1491593149; h=subject:references:to:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=WUOD8aUQlm/Rwpoe7qhuQTGWwk9rtUrL8dANapd5p7o=; b=blN575eulJKn1bVFybBwxSE5sLDzOAs6KaRgMICYh1b/qsAar1NAZARd Gv2hRMfA9fMm8BF29FPGB3OpCwT3dpk6NWHyZ7Q1MLSILrqGpPuFVyKx2 FBf4WGPS6su2Nhh9I7DvsFSeGKw6PX0bDhgr8LKoqas7svbjJwRUk2rNM c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CUAQB4ctVY/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhUCDYooPc5BckzqCD4IOhiICg2gYAQIBAQEBAQEBayiFFQEBAgI?= =?us-ascii?q?BIxVGCxwDAQIDAiYCAk0CCAcMBgIBAYl2BQiqRIImikUBAQEBAQEEAQEBAQEBA?= =?us-ascii?q?QEggQuFQ4IFgmqHWoJfBZAdjDySS4FkiHaGVotPgz+EVx84gQQ6HxVIgVuCdh2?= =?us-ascii?q?BZD81iW4BAQE?= X-IronPort-AV: E=Sophos;i="5.36,216,1486425600"; d="scan'208";a="653503949" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Mar 2017 19:25:23 +0000 Received: from [10.61.255.175] ([10.61.255.175]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v2OJPNue007140; Fri, 24 Mar 2017 19:25:23 GMT References: <6F5424A0-C324-4F39-AE4D-2A2B2A72E13A@cisco.com> To: shares@ndzh.com, idr@ietf.org From: Clarence Filsfils X-Forwarded-Message-Id: <6F5424A0-C324-4F39-AE4D-2A2B2A72E13A@cisco.com> Message-ID: <2d6899bd-5ce6-47aa-3c33-09f8242f364a@cisco.com> Date: Fri, 24 Mar 2017 18:46:58 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <6F5424A0-C324-4F39-AE4D-2A2B2A72E13A@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Idr] Fwd: [URGENT AND IMPORTANT] IETF WG last call X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Mar 2017 19:25:51 -0000 I support as co-author. Cheers, Clarence > From: "Susan Hares" > To: "'idr wg'" > Date: Tue, 21 Mar 2017 12:53:14 -0400 > Subject: Re: [Idr] 2 Week WG LC for draft-ietf-idr-bgp-prefix-sid-04.txt - > 3/6 to 3/20/2017 - extending to 3/31 > > > IDR WG: > > > > Perhaps the WG LC came at a bad time since have received only 1 response. > We will length the call to 3/31. Unless with have substantial input, this > WG LC will not indicate consensus. > > > > Sue Hares From nobody Fri Mar 24 12:29:57 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E56B129490 for ; Fri, 24 Mar 2017 12:29:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OtXYc_trwP2j for ; Fri, 24 Mar 2017 12:29:53 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77CF612948B for ; Fri, 24 Mar 2017 12:29:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3435; q=dns/txt; s=iport; t=1490383793; x=1491593393; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=NLO1Cuj5c73oIdaRaiHsVIJjiBZvHniilmcZUFT+ffI=; b=IymhDVLDAg8prL8HtJe7oaki166X3AnKwWZHg6JRgPQIIYynBQuIjFBn 1vT0pEOXhKgUw6Y0kuLQp6NDNd5C5qxw/Vgb/93MDAcLPYJxNy4qcOEl7 C4K3auC6cSRu9fgqJMO/wawBGNwehA4Lss39Adfkcj//W78uK3XoIhxRO A=; X-IronPort-AV: E=Sophos;i="5.36,216,1486425600"; d="scan'208,217";a="224519389" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Mar 2017 19:29:52 +0000 Received: from [10.154.161.58] ([10.154.161.58]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v2OJTq7X005059; Fri, 24 Mar 2017 19:29:52 GMT Message-ID: <58D573B0.2050704@cisco.com> Date: Fri, 24 Mar 2017 12:29:52 -0700 From: "Ahmed Bashandy (bashandy)" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Susan Hares , "'idr wg'" References: <035901d2a263$a204a0c0$e60de240$@ndzh.com> In-Reply-To: <035901d2a263$a204a0c0$e60de240$@ndzh.com> Content-Type: multipart/alternative; boundary="------------020302080603030508080401" Archived-At: Subject: Re: [Idr] 2 Week WG LC for draft-ietf-idr-bgp-prefix-sid-04.txt - 3/6 to 3/20/2017 - extending to 3/31 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Mar 2017 19:29:55 -0000 This is a multi-part message in MIME format. --------------020302080603030508080401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Support Ahmed On 3/21/2017 9:53 AM, Susan Hares wrote: > > IDR WG: > > Perhaps the WG LC came at a bad time since have received only 1 > response. We will length the call to 3/31. Unless with have > substantial input, this WG LC will not indicate consensus. > > Sue Hares > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr --------------020302080603030508080401 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Support

    Ahmed

    On 3/21/2017 9:53 AM, Susan Hares wrote:

    IDR WG:

     

    Perhaps the WG LC came at a bad time since have received only 1 response.  We will length the call to 3/31.  Unless with have substantial input, this WG LC will not indicate consensus.

     

    Sue Hares 



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

    --------------020302080603030508080401-- From nobody Fri Mar 24 13:10:30 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0401294E1 for ; Fri, 24 Mar 2017 13:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4wEhEq7wZDo for ; Fri, 24 Mar 2017 13:10:26 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69F12126BF0 for ; Fri, 24 Mar 2017 13:10:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1528; q=dns/txt; s=iport; t=1490386226; x=1491595826; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=qOuPMlS85/nCxOVFQhYmtFKaat6wKPB99mJpI5/dbNQ=; b=Ycs0n6RWeQ35wLg/n1yQnSrSMH09ttJqsrDcN3y7hwNZ2N/Wd1KhB5og 9GvFlLjeIYMM9US8SYXkR/HRKupVEfU8Zb2LKbFeUET8vMv/eMvYh1aAO jGVRsFYHkH6CXyJZU1JPn2Ngpo4zIyn8HQ5GOZfz/FtDv2Ou/hDXRYPOT w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B1AgB/fNVY/5NdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1RhgQsHg1uKD5EwH5VJgg4fC4V4AhqDDz8YAQIBAQEBAQEBayi?= =?us-ascii?q?FFQEBAQECAQEBIRE6FwQCAQgRAwECAwImAgICJQsVCAgCBAESiX8IDqohgiaKR?= =?us-ascii?q?gEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgQuFQ4IFCIJihGuCby6CMQWQHYVuhk4?= =?us-ascii?q?BkkqRMI8OhFYBHziBBFkVQQcKAYFQgnYdgWN1iHqBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.36,216,1486425600"; d="scan'208";a="402631162" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Mar 2017 20:10:25 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v2OKAPh4001050 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 24 Mar 2017 20:10:25 GMT Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 24 Mar 2017 15:10:24 -0500 Received: from xch-aln-005.cisco.com ([173.36.7.15]) by XCH-ALN-005.cisco.com ([173.36.7.15]) with mapi id 15.00.1210.000; Fri, 24 Mar 2017 15:10:24 -0500 From: "Rajiv Asati (rajiva)" To: "Clarence Filsfils (cfilsfil)" , "shares@ndzh.com" , "idr@ietf.org" Thread-Topic: [Idr] Fwd: [URGENT AND IMPORTANT] IETF WG last call Thread-Index: AQHSpNR508qjHR4mp0SQVEY8X4hIsaGkfHIA Date: Fri, 24 Mar 2017 20:10:24 +0000 Message-ID: <621568F8-A71E-4130-84C5-103233D740D7@cisco.com> References: <6F5424A0-C324-4F39-AE4D-2A2B2A72E13A@cisco.com> <2d6899bd-5ce6-47aa-3c33-09f8242f364a@cisco.com> In-Reply-To: <2d6899bd-5ce6-47aa-3c33-09f8242f364a@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.18.255.240] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] Fwd: [URGENT AND IMPORTANT] IETF WG last call X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Mar 2017 20:10:28 -0000 U3VwcG9ydC4NCg0KLS0gDQpDaGVlcnMsDQpSYWppdiAgDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiBJZHIgPGlkci1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgIkNs YXJlbmNlIEZpbHNmaWxzIChjZmlsc2ZpbCkiIDxjZmlsc2ZpbEBjaXNjby5jb20+DQpEYXRlOiBG cmlkYXksIE1hcmNoIDI0LCAyMDE3IGF0IDE6NDYgUE0NClRvOiAic2hhcmVzQG5kemguY29tIiA8 c2hhcmVzQG5kemguY29tPiwgImlkckBpZXRmLm9yZyIgPGlkckBpZXRmLm9yZz4NClN1YmplY3Q6 IFtJZHJdIEZ3ZDogW1VSR0VOVCBBTkQgSU1QT1JUQU5UXSBJRVRGIFdHIGxhc3QgY2FsbA0KDQog ICAgSSBzdXBwb3J0IGFzIGNvLWF1dGhvci4NCiAgICANCiAgICBDaGVlcnMsDQogICAgQ2xhcmVu Y2UNCiAgICANCiAgICANCiAgICA+IEZyb206ICJTdXNhbiBIYXJlcyIgPHNoYXJlc0BuZHpoLmNv bT4NCiAgICA+IFRvOiAiJ2lkciB3ZyciIDxpZHJAaWV0Zi5vcmc+DQogICAgPiBEYXRlOiBUdWUs IDIxIE1hciAyMDE3IDEyOjUzOjE0IC0wNDAwDQogICAgPiBTdWJqZWN0OiBSZTogW0lkcl0gMiBX ZWVrIFdHIExDIGZvciBkcmFmdC1pZXRmLWlkci1iZ3AtcHJlZml4LXNpZC0wNC50eHQgLQ0KICAg ID4gIDMvNiB0byAzLzIwLzIwMTcgLSBleHRlbmRpbmcgdG8gMy8zMQ0KICAgID4NCiAgICA+DQog ICAgPiBJRFIgV0c6DQogICAgPg0KICAgID4NCiAgICA+DQogICAgPiBQZXJoYXBzIHRoZSBXRyBM QyBjYW1lIGF0IGEgYmFkIHRpbWUgc2luY2UgaGF2ZSByZWNlaXZlZCBvbmx5IDEgcmVzcG9uc2Uu DQogICAgPiBXZSB3aWxsIGxlbmd0aCB0aGUgY2FsbCB0byAzLzMxLiAgVW5sZXNzIHdpdGggaGF2 ZSBzdWJzdGFudGlhbCBpbnB1dCwgdGhpcw0KICAgID4gV0cgTEMgd2lsbCBub3QgaW5kaWNhdGUg Y29uc2Vuc3VzLg0KICAgID4NCiAgICA+DQogICAgPg0KICAgID4gU3VlIEhhcmVzDQogICAgDQog ICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICBJ ZHIgbWFpbGluZyBsaXN0DQogICAgSWRyQGlldGYub3JnDQogICAgaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9pZHINCiAgICANCg0K From nobody Fri Mar 24 13:18:49 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 915C0129981 for ; Fri, 24 Mar 2017 13:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rV69-YV04Eid for ; Fri, 24 Mar 2017 13:18:47 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECA3012994F for ; Fri, 24 Mar 2017 13:18:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1407; q=dns/txt; s=iport; t=1490386726; x=1491596326; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=lGRmgXc89bc7Egf5WTvJC684Eji+ezjtcQfEX9t85XU=; b=U59105u1ysbwNszr4jjhMC7DB0lMFNVOYrIdCVk/ADjIZ6bgrTnetN6r nhzOs0KIhbNmSgotHjWRQ1Ntl/SyXvqMP//0YkP1AwpWbtMgoCYHqb9xH oeENGZdpbj7TtF3xyHt5NR77gN8JUbTyCfnIqpjDI70kHJYpm05XNugol c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAQDWftVY/5hdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1RheRKNcZFPlUmCDh8LhXgCgyk/GAECAQEBAQEBAWsohRUBAQE?= =?us-ascii?q?BAgEBATg0CwUHBAIBCBEDAQIBHhAnCx0IAgQOBYl/CA6sR4pFAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBGAWGToIFgmqEVIM0gjEFkB2FboZOAZJKkTCPDoRWAR84gQR?= =?us-ascii?q?ZFUEHCgGBUIJ2HYFjdYoHAQEB?= X-IronPort-AV: E=Sophos;i="5.36,216,1486425600"; d="scan'208";a="402633675" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Mar 2017 20:18:46 +0000 Received: from XCH-RTP-002.cisco.com (xch-rtp-002.cisco.com [64.101.220.142]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v2OKIjTU024372 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 24 Mar 2017 20:18:46 GMT Received: from xch-rtp-012.cisco.com (64.101.220.152) by XCH-RTP-002.cisco.com (64.101.220.142) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 24 Mar 2017 16:18:45 -0400 Received: from xch-rtp-012.cisco.com ([64.101.220.152]) by XCH-RTP-012.cisco.com ([64.101.220.152]) with mapi id 15.00.1210.000; Fri, 24 Mar 2017 16:18:44 -0400 From: "Gaurav Dawra (gdawra)" To: "Rajiv Asati (rajiva)" CC: "Clarence Filsfils (cfilsfil)" , "shares@ndzh.com" , "idr@ietf.org" Thread-Topic: [Idr] Fwd: [URGENT AND IMPORTANT] IETF WG last call Thread-Index: AQHSpNR508qjHR4mp0SQVEY8X4hIsaGkfHIA///xkbc= Date: Fri, 24 Mar 2017 20:18:44 +0000 Message-ID: References: <6F5424A0-C324-4F39-AE4D-2A2B2A72E13A@cisco.com> <2d6899bd-5ce6-47aa-3c33-09f8242f364a@cisco.com>, <621568F8-A71E-4130-84C5-103233D740D7@cisco.com> In-Reply-To: <621568F8-A71E-4130-84C5-103233D740D7@cisco.com> 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: Subject: Re: [Idr] Fwd: [URGENT AND IMPORTANT] IETF WG last call X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Mar 2017 20:18:48 -0000 Support. Gaurav Sent from my iPhone > On Mar 24, 2017, at 1:10 PM, Rajiv Asati (rajiva) wrot= e: >=20 > Support. >=20 > --=20 > Cheers, > Rajiv =20 >=20 > -----Original Message----- > From: Idr on behalf of "Clarence Filsfils (cfilsfi= l)" > Date: Friday, March 24, 2017 at 1:46 PM > To: "shares@ndzh.com" , "idr@ietf.org" > Subject: [Idr] Fwd: [URGENT AND IMPORTANT] IETF WG last call >=20 > I support as co-author. >=20 > Cheers, > Clarence >=20 >=20 >> From: "Susan Hares" >> To: "'idr wg'" >> Date: Tue, 21 Mar 2017 12:53:14 -0400 >> Subject: Re: [Idr] 2 Week WG LC for draft-ietf-idr-bgp-prefix-sid-04.txt= - >> 3/6 to 3/20/2017 - extending to 3/31 >>=20 >>=20 >> IDR WG: >>=20 >>=20 >>=20 >> Perhaps the WG LC came at a bad time since have received only 1 response= . >> We will length the call to 3/31. Unless with have substantial input, th= is >> WG LC will not indicate consensus. >>=20 >>=20 >>=20 >> Sue Hares >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >=20 >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Fri Mar 24 13:45:07 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 458C11289B5 for ; Fri, 24 Mar 2017 13:45:06 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I6jcTxIxZNAi for ; Fri, 24 Mar 2017 13:45:04 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::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 7BA0512871F for ; Fri, 24 Mar 2017 13:45:04 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id i34so1328892qtc.0 for ; Fri, 24 Mar 2017 13:45:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LyTt/FnfSgnCR4fCaSLTo3W6soeNlmyennKW73prQCw=; b=ZYDLMtqmtY4r7GVxsyHaNaZ3RZPhvSp0LxxQsSkVv6eY4A41y5oB8gmNrbuewgYmQI J7/3XW2vMmIK3yFPjAFVd7UXqTnWv/qq0AS/0FmEWUFD7QLagwIS4puxbeBSJPQ/Zy5j Kj0AiussI5eH8u1Q44HyUOdHfmXZerG6HozBYIWnlmubiogVWOrRYNfkKZGiKOWzQUMJ N5xs6tvyQfWSLXFB2sfDeBXdXa9NUnsY+V3eOgtphHP9gAxJxV3v9r9dokNdYKb4vLsi mHWKjJ57gPO9dyfDFmUkrGV0aEtDEpg4Lp9kvSHxv1mhA1+cSTY3dBu+s0OW92g4TsAM 0V7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LyTt/FnfSgnCR4fCaSLTo3W6soeNlmyennKW73prQCw=; b=XlKeoqWxlnxhBVix+mJHz24W0ec7rHE7l2ilNY4B6R/js9FxTjcgHqf6Qjy8A4lgLC xub+1thUlqyxEx2ng7u/RyxGlCM2lTNrxdLnhywei8o0GhSZ5uc5bZ6iR7bf80NuhguE DsXNAdC16xWygi6WMyK3a5sYpOmRqpoqyWeOxbLOgO9MLMOo46vWJsiK1UzaXg/VzLt0 +6XYFegCdR/Dvs7+LSBMtyO/5P8bc5SwvDo4+OzXV4RpbCu3RpIbzy84/cd2BxiFa8Br Vu3oAc9jNIh7N5cSp95WtElPeFPA+wQfq2o7YfALTOnV2NdHAbiWF6V44vDm6WSNRUCF jKNA== X-Gm-Message-State: AFeK/H3kFKiaJpVo4OkX6jNookWpA4hifVD5ROnoaCgZG49BLA8MDchwdu/yiimTvNYmlLGK/plb7hvYKHNF8Q== X-Received: by 10.200.42.151 with SMTP id b23mr9501532qta.163.1490388303431; Fri, 24 Mar 2017 13:45:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.92.5 with HTTP; Fri, 24 Mar 2017 13:45:02 -0700 (PDT) In-Reply-To: <2d6899bd-5ce6-47aa-3c33-09f8242f364a@cisco.com> References: <6F5424A0-C324-4F39-AE4D-2A2B2A72E13A@cisco.com> <2d6899bd-5ce6-47aa-3c33-09f8242f364a@cisco.com> From: Mohan Nanduri Date: Fri, 24 Mar 2017 16:45:02 -0400 Message-ID: To: "idr@ietf.org List" Cc: Susan Hares Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [Idr] Fwd: [URGENT AND IMPORTANT] IETF WG last call X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Mar 2017 20:45:06 -0000 Support. Cheers, -Mohan On Fri, Mar 24, 2017 at 1:46 PM, Clarence Filsfils wrote: > I support as co-author. > > Cheers, > Clarence > > >> From: "Susan Hares" >> To: "'idr wg'" >> Date: Tue, 21 Mar 2017 12:53:14 -0400 >> Subject: Re: [Idr] 2 Week WG LC for draft-ietf-idr-bgp-prefix-sid-04.txt - >> 3/6 to 3/20/2017 - extending to 3/31 >> >> >> IDR WG: >> >> >> >> Perhaps the WG LC came at a bad time since have received only 1 response. >> We will length the call to 3/31. Unless with have substantial input, this >> WG LC will not indicate consensus. >> >> >> >> Sue Hares > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Sat Mar 25 04:45:23 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7335128ACA; Sat, 25 Mar 2017 04:11:02 -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, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g8XGfDpCVIE5; Sat, 25 Mar 2017 04:11:01 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B2B7126FDC; Sat, 25 Mar 2017 04:11:00 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 946D3B8062D; Sat, 25 Mar 2017 04:10:53 -0700 (PDT) To: nmalykh@gmail.com, jheitz@cisco.com, job@ntt.net, keyur@arrcus.com, ibagdona.ietf@gmail.com, nick@inex.ie X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: aretana@cisco.com, iesg@ietf.org, idr@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20170325111053.946D3B8062D@rfc-editor.org> Date: Sat, 25 Mar 2017 04:10:53 -0700 (PDT) Archived-At: X-Mailman-Approved-At: Sat, 25 Mar 2017 04:45:22 -0700 Subject: [Idr] [Errata Held for Document Update] RFC8092 (4962) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Mar 2017 11:11:03 -0000 The following errata report has been held for document update for RFC8092, "BGP Large Communities Attribute". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=8092&eid=4962 -------------------------------------- Status: Held for Document Update Type: Editorial Reported by: Nikolai Malykh Date Reported: 2017-03-09 Held by: Alvaro Retana (IESG) Section: 3 Original Text ------------- Duplicate BGP Large Community values MUST NOT be transmitted. A receiving speaker MUST silently remove redundant BGP Large Community values from a BGP Large Community attribute. Corrected Text -------------- Duplicate BGP Large Community values MUST NOT be transmitted. A receiving speaker MUST silently remove redundant BGP Large Community values from a BGP Large Communities attribute. Notes ----- Typo ==== There are two mote instances where the name of the attribute is also mentioned as "BGP Large Community attribute", and not "BGP Large Communities Attribute” as defined in Section 3. I am changing the status to "Held for Document Update", which means that "The erratum is not a necessary update to the RFC. However, any future update of the document might consider this erratum, and determine whether it is correct and merits including in the update." [1] - Alvaro. [1] https://www.ietf.org/iesg/statement/errata-processing.html -------------------------------------- RFC8092 (draft-ietf-idr-large-community-12) -------------------------------------- Title : BGP Large Communities Attribute Publication Date : February 2017 Author(s) : J. Heitz, Ed., J. Snijders, Ed., K. Patel, I. Bagdonas, N. Hilliard Category : PROPOSED STANDARD Source : Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG From nobody Sat Mar 25 07:39:26 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A163129482; Sat, 25 Mar 2017 07:39:24 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4X252NtkfF-Z; Sat, 25 Mar 2017 07:39:22 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0103.outbound.protection.outlook.com [23.103.201.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 9980812940B; Sat, 25 Mar 2017 07:39:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=KiCc9E7CQ4ZqAQdVCbItKaxBEr17ksRk501nXT2Zbhc=; b=FSpstCAfFYZvT7wrt6h2Vxy4NMVuN/pnEqxGxtMwmO0wNYWF0EFE58Y9Gws8d7NsrG91Oxoa/VKg8zVYMPIIzGciN3tDzeV3LNBOthuGorg2IrginEL0yN1qw+twFjOpH2knePw4/ccJwKEmZzsAzLnhA5SlkFx3BOmzQHZfXcU= Received: from DM2PR09MB0446.namprd09.prod.outlook.com (10.161.252.145) by DM2PR09MB0447.namprd09.prod.outlook.com (10.161.252.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.977.11; Sat, 25 Mar 2017 14:39:20 +0000 Received: from DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) by DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) with mapi id 15.01.0977.021; Sat, 25 Mar 2017 14:39:20 +0000 From: "Sriram, Kotikalapudi (Fed)" To: GROW WG CC: IDR Thread-Topic: GROW RFC 7908 gets press coverage Thread-Index: AQHSpXIMmcQNIxso+0qvH9JB+l33dg== Date: Sat, 25 Mar 2017 14:39:20 +0000 Message-ID: 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;ietf.org; dmarc=none action=none header.from=nist.gov; x-originating-ip: [71.191.56.66] x-microsoft-exchange-diagnostics: 1; DM2PR09MB0447; 7:IhxiO3quC6l1qHimR+ZXBZJUhrPIZlkCqLBes1HKfUIsTLd7YKebrUKZpqK+01UusljrcR7kS0ucEQqofhPlriI5gCFZt/fNOn/VfXvH/FaMo3cbU7vGizutcyeipQon9/CAjx2hLKgvL45q5EyFYe5R0rRvmhutNPj8ddkRAk1ejG61LjGCORDPv7GZxPf1QcWQNviuhzPKBLYYnt5j0Vmlwwn2qBv4DjESnH5lONjqdzJPwBIULp8492PISsjyeVXeZXYl3vyNP7VrnSw60l98cmwXiGpKK+7z8TEYRpOflnpfKX3NdWfAbXq9Vc+F8jz5y4UpwI7mlhXTYjXyWA== x-ms-office365-filtering-correlation-id: 8321b4de-bcb6-42f9-7104-08d4738cb94e x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081); SRVR:DM2PR09MB0447; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123564025)(20161123560025)(20161123562025)(20161123558025)(20161123555025)(6072148); SRVR:DM2PR09MB0447; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0447; x-forefront-prvs: 025796F161 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39840400002)(39850400002)(39410400002)(110136004)(38730400002)(55016002)(7696004)(6916009)(9686003)(53936002)(99286003)(5660300001)(6306002)(4326008)(3280700002)(558084003)(3660700001)(189998001)(8936002)(25786009)(2906002)(8676002)(81166006)(74316002)(3846002)(102836003)(86362001)(6116002)(66066001)(2900100001)(54356999)(7736002)(6436002)(33656002)(305945005)(6506006)(50986999)(77096006)(122556002)(217873001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0447; H:DM2PR09MB0446.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM 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: 25 Mar 2017 14:39:20.4691 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0447 Archived-At: Subject: [Idr] GROW RFC 7908 gets press coverage X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Mar 2017 14:39:24 -0000 Just noticed ... RFC 7908 (route leaks problem definition) -- developed in GROW -- reported = in The Register.=20 https://www.theregister.co.uk/2016/06/23/fatthumbed_a_bgp_entry_relax_now_y= our_pain_has_a_name/ =20 Link to the RFC: https://tools.ietf.org/html/rfc7908=20 Sriram From nobody Mon Mar 27 01:46:43 2017 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C1A7D1294A5; Mon, 27 Mar 2017 01:46:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: idr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.48.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149060440173.8031.16213829916890829007@ietfa.amsl.com> Date: Mon, 27 Mar 2017 01:46:41 -0700 Archived-At: Subject: [Idr] I-D Action: draft-ietf-idr-rfc5575bis-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 08:46:42 -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 of the IETF. Title : Dissemination of Flow Specification Rules Authors : Susan Hares Robert Raszuk Danny McPherson Christoph Loibl Martin Bacher Filename : draft-ietf-idr-rfc5575bis-01.txt Pages : 30 Date : 2017-03-27 Abstract: This document updates RFC5575 which defines a Border Gateway Protocol Network Layer Reachability Information (BGP NLRI) encoding format that can be used to distribute traffic flow specifications. This allows the routing system to propagate information regarding more specific components of the traffic aggregate defined by an IP destination prefix. This draft specifies IPv4 traffic flow specifications via a BGP NLRI which carries traffic flow specification filter, and an Extended community value which encodes actions a routing system can take if the packet matches the traffic flow filters. The flow filters and the actions are processed in a fixed order. Other drafts specify IPv6, MPLS addresses, L2VPN addresses, and NV03 encapsulation of IP addresses. This document updates RFC5575 to correct unclear specifications in the flow filters and to provide rules for actions which interfere (e.g. redirection of traffic and flow filtering). Applications which use the bgp flow specification are: 1) application which automate of inter-domain coordination of traffic filtering, such as what is required in order to mitigate (distributed) denial- of-service attacks; 2) application which control traffic filtering in the context of a BGP/MPLS VPN service, and 3) applications with centralized control of traffic in a SDN or NFV context. Some of deployments of these three applications can be handled by the strict ordering of the BGP NLRI traffic flow filters, and the strict actions encoded in the Extended Community Flow Specification actions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-rfc5575bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-idr-rfc5575bis-01 https://datatracker.ietf.org/doc/html/draft-ietf-idr-rfc5575bis-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-rfc5575bis-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 Mar 27 05:19:09 2017 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B39AC129411; Mon, 27 Mar 2017 05:19:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: idr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.48.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149061714370.30501.7335115266662475316@ietfa.amsl.com> Date: Mon, 27 Mar 2017 05:19:03 -0700 Archived-At: Subject: [Idr] I-D Action: draft-ietf-idr-bgp-gr-notification-10.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 12:19: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 of the IETF. Title : Notification Message support for BGP Graceful Restart Authors : Keyur Patel Rex Fernando John Scudder Jeff Haas Filename : draft-ietf-idr-bgp-gr-notification-10.txt Pages : 7 Date : 2017-03-27 Abstract: The current BGP Graceful Restart mechanism limits the usage of BGP Graceful Restart to BGP protocol messages other than a BGP NOTIFICATION message. This document defines an extension to the BGP Graceful Restart that permits the Graceful Restart procedures to be performed when the BGP speaker receives a BGP NOTIFICATION Message or the Hold Time expires. This document also defines a new BGP NOTIFICATION Cease Error subcode whose effect is to request a full session restart instead of a Graceful Restart. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-gr-notification/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-idr-bgp-gr-notification-10 https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-gr-notification-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-gr-notification-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 Mar 27 20:19:36 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 330D71275C5; Mon, 27 Mar 2017 20:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gxuyrjnxMu0X; Mon, 27 Mar 2017 20:19:31 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0125.outbound.protection.outlook.com [104.47.34.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 9BCC41292AE; Mon, 27 Mar 2017 20:19:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=2OxktjY/TAXg3LU0YMlcEt4AfiK5SqPkod/whIK4Cxc=; b=c//RFxUtnTyQ0ur+L/sJUJZxo9D74wNIE04O+/1gI1PyEMwnrLxP8fjy66yLHsrZ+IgBQj2quTd6DJFF4D3d5icii2aUnnbk+lAP1/Nn8NDVKXNHuzoOqhuaENvE+oMGZ4m09ghm7AwiUMgcJ5+Vdvd7f8x4Qj4HLRJ5Ij6051Y= Received: from MWHPR05MB3215.namprd05.prod.outlook.com (10.173.229.146) by MWHPR05MB3216.namprd05.prod.outlook.com (10.173.229.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.2; Tue, 28 Mar 2017 03:19:30 +0000 Received: from MWHPR05MB3215.namprd05.prod.outlook.com ([10.173.229.146]) by MWHPR05MB3215.namprd05.prod.outlook.com ([10.173.229.146]) with mapi id 15.01.1005.009; Tue, 28 Mar 2017 03:19:30 +0000 From: Balaji Rajagopalan To: 'idr wg' , Susan Hares CC: "draft-gredler-idr-bgplu-epe@ietf.org" , "idr-chairs@ietf.org" , "'Dongjie (Jimmy)'" Thread-Topic: [Idr] IPR call for draft-grendler-idr-bgplu-epe Thread-Index: AdKehOZ/wEwxmWbqQC6qAxZ77D+MDwEaE/aAARIgkwAAGp+kgA== Date: Tue, 28 Mar 2017 03:19:30 +0000 Message-ID: References: <013d01d29e85$270dcae0$752960a0$@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.7.2.170228 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [116.197.184.14] x-microsoft-exchange-diagnostics: 1; MWHPR05MB3216; 7:NYY5tsUbxk5dOpCpBKHczVXsRNZ8vMzfaqtEDP3qorgHGLn6Ih2motsA1iSxOAfeAO2WFPPhSgjPM0FzU/DZVz3pgwf60ReBmVYju+orfktsvNo2NW9YwI42d3BD5TmzlkncvpKlq6/WCs8fNkidyMyu4ViyHTEq+BKUYb7tv2BHEWMr5r3zJ+FrO/41ETDZUSle1r7iNvNE47XnA8RaOcAh6zkwOPTesbUw4e31OV5NsDyCsChot1+QfKurRv1gYpXTd5L12aCpCFyyJAO0DmL+QUn9yD7q4V7sEGjvekSzJqIZN2IQ2KVayA45NTlXdgtON6RruR2ZkeU+73XALg== x-ms-office365-filtering-correlation-id: 7bc37ec0-a3ad-4ef0-8076-08d475893fdf x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081); SRVR:MWHPR05MB3216; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(50582790962513)(21748063052155)(138986009662008); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123564025)(20161123558025)(20161123560025)(20161123555025)(20161123562025)(6072148); SRVR:MWHPR05MB3216; BCL:0; PCL:0; RULEID:; SRVR:MWHPR05MB3216; x-forefront-prvs: 0260457E99 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39410400002)(39850400002)(39450400003)(39840400002)(39860400002)(377454003)(25786009)(66066001)(5660300001)(4326008)(3280700002)(229853002)(102836003)(122556002)(2950100002)(6116002)(53546009)(7736002)(8936002)(7906003)(3660700001)(81166006)(83506001)(8676002)(2900100001)(3846002)(230783001)(38730400002)(189998001)(6246003)(36756003)(6506006)(50986999)(54906002)(54356999)(76176999)(606005)(99286003)(6436002)(6512007)(6486002)(2906002)(236005)(54896002)(53936002)(77096006)(86362001)(6306002)(19623405001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR05MB3216; H:MWHPR05MB3215.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_D4FFD377437DEbalajirjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Mar 2017 03:19:30.7522 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR05MB3216 Archived-At: Subject: Re: [Idr] IPR call for draft-grendler-idr-bgplu-epe X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 03:19:34 -0000 --_000_D4FFD377437DEbalajirjunipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkknbSBub3QgYXdhcmUgb2YgYW55IElQUi4NCg0KLS0NCkJhbGFqaSBSYWphZ29wYWxh bg0KDQpGcm9tOiBTdXNhbiBIYXJlcyA8c2hhcmVzQG5kemguY29tPG1haWx0bzpzaGFyZXNAbmR6 aC5jb20+Pg0KRGF0ZTogVGh1cnNkYXksIE1hcmNoIDE2LCAyMDE3IGF0IDExOjQzIEFNDQpUbzog J2lkciB3ZycgPGlkckBpZXRmLm9yZzxtYWlsdG86aWRyQGlldGYub3JnPj4NCkNjOiAiZHJhZnQt Z3JlZGxlci1pZHItYmdwbHUtZXBlQGlldGYub3JnPG1haWx0bzpkcmFmdC1ncmVkbGVyLWlkci1i Z3BsdS1lcGVAaWV0Zi5vcmc+IiA8ZHJhZnQtZ3JlZGxlci1pZHItYmdwbHUtZXBlQGlldGYub3Jn PG1haWx0bzpkcmFmdC1ncmVkbGVyLWlkci1iZ3BsdS1lcGVAaWV0Zi5vcmc+PiwgImlkci1jaGFp cnNAaWV0Zi5vcmc8bWFpbHRvOmlkci1jaGFpcnNAaWV0Zi5vcmc+IiA8aWRyLWNoYWlyc0BpZXRm Lm9yZzxtYWlsdG86aWRyLWNoYWlyc0BpZXRmLm9yZz4+LCAiJ0RvbmdqaWUgKEppbW15KSciIDxq aWUuZG9uZ0BodWF3ZWkuY29tPG1haWx0bzpqaWUuZG9uZ0BodWF3ZWkuY29tPj4NClN1YmplY3Q6 IElQUiBjYWxsIGZvciBkcmFmdC1ncmVuZGxlci1pZHItYmdwbHUtZXBlDQpSZXNlbnQtRnJvbTog PGFsaWFzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmFsaWFzLWJvdW5jZXNAaWV0Zi5vcmc+Pg0K UmVzZW50LVRvOiA8a2FsaXJhakBqdW5pcGVyLm5ldDxtYWlsdG86a2FsaXJhakBqdW5pcGVyLm5l dD4+LCA8Y3Nla2FyQGp1bmlwZXIubmV0PG1haWx0bzpjc2VrYXJAanVuaXBlci5uZXQ+PiwgPGJh bGFqaXJAanVuaXBlci5uZXQ8bWFpbHRvOmJhbGFqaXJAanVuaXBlci5uZXQ+PiwgPGx1ZmFuZ0Bt aWNyb3NvZnQuY29tPG1haWx0bzpsdWZhbmdAbWljcm9zb2Z0LmNvbT4+LCA8aGFubmVzQHJ0YnJp Y2suY29tPG1haWx0bzpoYW5uZXNAcnRicmljay5jb20+PiwgPGVhcmllc0BqdW5pcGVyLm5ldDxt YWlsdG86ZWFyaWVzQGp1bmlwZXIubmV0Pj4NClJlc2VudC1EYXRlOiBUaHVyc2RheSwgTWFyY2gg MTYsIDIwMTcgYXQgMTE6NDcgQU0NCg0KDQpUaGlzIGlzIGFuIElQUiBjYWxsIHByaW9yIHRvIGEg Y2FsbCBmb3IgYWRvcHRpb24gZm9yIGRyYWZ0LWdyZWRsZXItaWRyLWJncGx1LWVwZSAgKCBFZ3Jl c3MgUGVlciBFbmdpbmVlcmluZyB1c2luZyBCR1AtTFUpIHdoaWNoIGNhbiBiZSBmb3VuZCBhdA0K DQogIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWdyZWRsZXItaWRyLWJn cGx1LWVwZS8NCg0KDQoNCldpbGwgdGhlIGF1dGhvcnMgcGxlYXNlIGluZGljYXRlIHdoZXRoZXIg dGhleSBrbm93IG9mIGFueSBJUFIgb24gdGhpcyBkcmFmdD8NCg0KDQoNClN1ZSBIYXJlcw0KDQo= --_000_D4FFD377437DEbalajirjunipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <229848A43933E84D802FDE2B43A82045@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NXB4OyBmb250LWZhbWlseTogQ29uc29sYXMsIHNhbnMtc2VyaWY7Ij4NCjxkaXY+SGksPC9kaXY+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JJ20gbm90IGF3YXJlIG9mIGFueSBJUFIuPC9kaXY+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4tLTwvZGl2Pg0KPGRpdj5CYWxhamkgUmFqYWdvcGFs YW48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJ T04iPg0KPGJsb2NrcXVvdGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUi IHN0eWxlPSJCT1JERVItTEVGVDogI2I1YzRkZiA1IHNvbGlkOyBQQURESU5HOjAgMCAwIDU7IE1B UkdJTjowIDAgMCA1OyI+DQo8ZGl2IHhtbG5zOm89InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6 d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8x Mi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQo8ZGl2IGJn Y29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj48Yj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+U3VzYW4gSGFyZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpzaGFyZXNAbmR6aC5jb20iPnNoYXJl c0BuZHpoLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlRodXJzZGF5LCBNYXJjaCAxNiwg MjAxNyBhdCAxMTo0MyBBTTxicj4NCjxiPlRvOiA8L2I+J2lkciB3ZycgJmx0OzxhIGhyZWY9Im1h aWx0bzppZHJAaWV0Zi5vcmciPmlkckBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj4m cXVvdDs8YSBocmVmPSJtYWlsdG86ZHJhZnQtZ3JlZGxlci1pZHItYmdwbHUtZXBlQGlldGYub3Jn Ij5kcmFmdC1ncmVkbGVyLWlkci1iZ3BsdS1lcGVAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBo cmVmPSJtYWlsdG86ZHJhZnQtZ3JlZGxlci1pZHItYmdwbHUtZXBlQGlldGYub3JnIj5kcmFmdC1n cmVkbGVyLWlkci1iZ3BsdS1lcGVAaWV0Zi5vcmc8L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFp bHRvOmlkci1jaGFpcnNAaWV0Zi5vcmciPmlkci1jaGFpcnNAaWV0Zi5vcmc8L2E+JnF1b3Q7DQog Jmx0OzxhIGhyZWY9Im1haWx0bzppZHItY2hhaXJzQGlldGYub3JnIj5pZHItY2hhaXJzQGlldGYu b3JnPC9hPiZndDssICZxdW90OydEb25namllIChKaW1teSknJnF1b3Q7ICZsdDs8YSBocmVmPSJt YWlsdG86amllLmRvbmdAaHVhd2VpLmNvbSI+amllLmRvbmdAaHVhd2VpLmNvbTwvYT4mZ3Q7PGJy Pg0KPGI+U3ViamVjdDogPC9iPklQUiBjYWxsIGZvciBkcmFmdC1ncmVuZGxlci1pZHItYmdwbHUt ZXBlIDxicj4NCjxiPlJlc2VudC1Gcm9tOiA8L2I+Jmx0OzxhIGhyZWY9Im1haWx0bzphbGlhcy1i b3VuY2VzQGlldGYub3JnIj5hbGlhcy1ib3VuY2VzQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5S ZXNlbnQtVG86IDwvYj4mbHQ7PGEgaHJlZj0ibWFpbHRvOmthbGlyYWpAanVuaXBlci5uZXQiPmth bGlyYWpAanVuaXBlci5uZXQ8L2E+Jmd0OywgJmx0OzxhIGhyZWY9Im1haWx0bzpjc2VrYXJAanVu aXBlci5uZXQiPmNzZWthckBqdW5pcGVyLm5ldDwvYT4mZ3Q7LCAmbHQ7PGEgaHJlZj0ibWFpbHRv OmJhbGFqaXJAanVuaXBlci5uZXQiPmJhbGFqaXJAanVuaXBlci5uZXQ8L2E+Jmd0OywgJmx0Ozxh IGhyZWY9Im1haWx0bzpsdWZhbmdAbWljcm9zb2Z0LmNvbSI+bHVmYW5nQG1pY3Jvc29mdC5jb208 L2E+Jmd0OywNCiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhhbm5lc0BydGJyaWNrLmNvbSI+aGFubmVz QHJ0YnJpY2suY29tPC9hPiZndDssICZsdDs8YSBocmVmPSJtYWlsdG86ZWFyaWVzQGp1bmlwZXIu bmV0Ij5lYXJpZXNAanVuaXBlci5uZXQ8L2E+Jmd0Ozxicj4NCjxiPlJlc2VudC1EYXRlOiA8L2I+ VGh1cnNkYXksIE1hcmNoIDE2LCAyMDE3IGF0IDExOjQ3IEFNPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjEuMGluIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPlRoaXMgaXMgYW4gSVBSIGNhbGwgcHJpb3IgdG8g YSBjYWxsIGZvciBhZG9wdGlvbiBmb3IgZHJhZnQtZ3JlZGxlci1pZHItYmdwbHUtZXBlJm5ic3A7 ICggRWdyZXNzIFBlZXIgRW5naW5lZXJpbmcgdXNpbmcgQkdQLUxVKSB3aGljaCBjYW4gYmUgZm91 bmQgYXQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJn aW4tbGVmdDoxLjBpbiI+Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWdyZWRsZXItaWRyLWJncGx1LWVwZS8iPg0KaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtZ3JlZGxlci1pZHItYmdwbHUtZXBlLzwvYT4gPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjEuMGluIj5XaWxsIHRoZSBhdXRob3JzIHBsZWFzZSBpbmRpY2F0ZSB3aGV0aGVy IHRoZXkga25vdyBvZiBhbnkgSVBSIG9uIHRoaXMgZHJhZnQ/DQo8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MS4waW4iPlN1ZSBIYXJlcyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+PHN0eWxlPjwhLS0NCi8qIEZvbnQg RGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsN CglwYW5vc2UtMToyIDcgMyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQg MyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3Jt YWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseTpDYWxpYnJpO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFpblRleHQs IGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpzcGFuLlBs YWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZh bWlseTpDYWxpYnJpO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsOw0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVt YWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciOw0KCWNvbG9yOndpbmRvd3RleHQ7DQoJbXNvLWxpZ2F0dXJlczpub25lO30NCnNw YW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6d2luZG93dGV4dDsNCgltc28tbGlnYXR1cmVz Om5vbmU7fQ0Kc3Bhbi5tc29JbnMNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNv LXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFs O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0K CW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_D4FFD377437DEbalajirjunipernet_-- From nobody Tue Mar 28 15:42:32 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63C7112869B for ; Tue, 28 Mar 2017 15:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UFUOumqq0Y_n for ; Tue, 28 Mar 2017 15:42:26 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC955124234 for ; Tue, 28 Mar 2017 15:42:24 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v2SMgMsE004453; Tue, 28 Mar 2017 23:42:23 +0100 Received: from 950129200 (dhcp-8535.meeting.ietf.org [31.133.133.53]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v2SMgKEO004400 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Mar 2017 23:42:22 +0100 Reply-To: From: "Adrian Farrel" To: "'Susan Hares'" , "'idr wg'" References: <035901d2a263$a204a0c0$e60de240$@ndzh.com> In-Reply-To: <035901d2a263$a204a0c0$e60de240$@ndzh.com> Date: Tue, 28 Mar 2017 23:42:21 +0100 Message-ID: <02d801d2a814$911042e0$b330c8a0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02D9_01D2A81C.F2D67FA0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJy9qBC8F701cXQis495LO0YAEVQ6BqOveA Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22972.002 X-TM-AS-Result: No--16.766-10.0-31-10 X-imss-scan-details: No--16.766-10.0-31-10 X-TMASE-MatchedRID: oll/cJ/dUC7Zfnct5UBzcXBRIrj8R47FnbR1KGab5Xlkh/XzQ/68digv oVUszPFSn34/cE72IoYkobjYrQULnH02CIWujuz86Zzj+kMRBrb6rVj794QCttqCxkzSpW/XlFb rf3w5DQjyQko+9F64VYhvDuwhdNATof0ugjLmfW6Vjmqvt/p8cnLhUU/qa4OGI0YrtQLsSUzCoo EDNritWwgdquk/Orvb7duC8bnsDBJCFB6Gxes2Bhes/RxhysDbXkAtH0iCZOza+IH8mvgPVIf87 UsW12BlNtrqBJtuOX6BWjWj7hCG0qoO96Tfmapcndu3heVAxaMP4vBWNr0zgSA6eO+NDmAxJZ3D 0zKPh7H10yQNuo1OJZfucML7iAp6c1BeS/J6aN9dMrg609R9BKO4XjVpMlFdn+lpJmYuEaN7ltq yJvHgp/JOjUaxKXKqGSKDIgjU9nky499dCbQy8IoLoibgjVEX1WPYxCHVrqdgHzfrfdHEt4c0B5 OUL/u1M5qWMflCo4dwtismKfx+71mKiy1F9pgLQesjq8XPMbt3Bf9JIqsoeA8YwboCQc88CE7se pEW6CvRM7el56AWz57jobRLBotGT+Zs2lM+sEAQ9/tMNQ4ait5EdUpA6Nu/DC/Vm90If4WtEJi9 sK8Vj1lPF7QujbckKoWa7+H+3DtkHsVpDopD33uTVkeYosXtOS0bT53qXdVT+oAjVn9e0ORqQAx bWD9+4vM1YF6AJbbqChA6lSRJvrQ/aqQZTRfKeotJ6wqXvVwj80Za3RRg8FcyJWZ/Ph9VwgVy8p 0g+frDcLIdjNa32e2vxPfyhacciJAzJVHEeyI= Archived-At: Subject: Re: [Idr] 2 Week WG LC for draft-ietf-idr-bgp-prefix-sid-04.txt - 3/6 to 3/20/2017 - extending to 3/31 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 22:42:30 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02D9_01D2A81C.F2D67FA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit All, Just a heads up that I am part way through a review of this document. I hope to complete it by the end of the week, but I am currently on vacation in Chicago and so not able to give so much time to the work. So far I have a number of nits and minor comments, but nothing of substance. Cheers, Adrian -- Support an author and your imagination. Tales from the Wood - Eighteen new fairy tales. More Tales from the Wood - Eighteen MORE new fairy tales. https://www.feedaread.com/profiles/8604/ http://www.amazon.co.uk/Tales-Wood-Adrian-Farrel/dp/1786100924 Or buy from me direct. From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: 21 March 2017 16:53 To: 'idr wg' Subject: Re: [Idr] 2 Week WG LC for draft-ietf-idr-bgp-prefix-sid-04.txt - 3/6 to 3/20/2017 - extending to 3/31 IDR WG: Perhaps the WG LC came at a bad time since have received only 1 response. We will length the call to 3/31. Unless with have substantial input, this WG LC will not indicate consensus. Sue Hares ------=_NextPart_000_02D9_01D2A81C.F2D67FA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    All,

     

    Just a heads up that I = am part way through a review of this document. I hope to complete it by = the end of the week, but I am currently on vacation in Chicago and so = not able to give so much time to the work.

     

    So far I have a number = of nits and minor comments, but nothing of = substance.

     

    Cheers,

    Adrian

     

    --

    Support an author and your = imagination.

    Tales from the Wood - Eighteen = new fairy tales.

    More Tales from the Wood - = Eighteen MORE new fairy tales.

    https://www.feedaread.com/profiles= /8604/

    http://www.amazon.co.uk/Tales-Wood= -Adrian-Farrel/dp/1786100924

    Or buy from me = direct.

     

     

     

     

    From: Idr = [mailto:idr-bounces@ietf.org] On Behalf Of Susan = Hares
    Sent: 21 March 2017 16:53
    To: 'idr = wg'
    Subject: Re: [Idr] 2 Week WG LC for = draft-ietf-idr-bgp-prefix-sid-04.txt - 3/6 to 3/20/2017 - extending to = 3/31

     

    IDR WG: =

     

    Perhaps the WG LC came at a bad time = since have received only 1 response.  We will length the call to = 3/31.  Unless with have substantial input, this WG LC will not = indicate consensus.

     

    Sue Hares =

    ------=_NextPart_000_02D9_01D2A81C.F2D67FA0-- From nobody Tue Mar 28 15:46:58 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5943712773A for ; Tue, 28 Mar 2017 15:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bdo4tDgdTgBF for ; Tue, 28 Mar 2017 15:46:54 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 4B2C412708C for ; Tue, 28 Mar 2017 15:46:54 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=31.133.128.130; From: "Susan Hares" To: , "'idr wg'" References: <035901d2a263$a204a0c0$e60de240$@ndzh.com> <02d801d2a814$911042e0$b330c8a0$@olddog.co.uk> In-Reply-To: <02d801d2a814$911042e0$b330c8a0$@olddog.co.uk> Date: Tue, 28 Mar 2017 18:42:07 -0400 Message-ID: <009301d2a814$882e6580$988b3080$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0094_01D2A7F3.011DD6F0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJy9qBC8F701cXQis495LO0YAEVQwJnRCIkoFcBopA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] 2 Week WG LC for draft-ietf-idr-bgp-prefix-sid-04.txt - 3/6 to 3/20/2017 - extending to 3/31 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 22:46:56 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0094_01D2A7F3.011DD6F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thank you for letting us know. Sue From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Tuesday, March 28, 2017 6:42 PM To: 'Susan Hares'; 'idr wg' Subject: RE: [Idr] 2 Week WG LC for draft-ietf-idr-bgp-prefix-sid-04.txt - 3/6 to 3/20/2017 - extending to 3/31 All, Just a heads up that I am part way through a review of this document. I hope to complete it by the end of the week, but I am currently on vacation in Chicago and so not able to give so much time to the work. So far I have a number of nits and minor comments, but nothing of substance. Cheers, Adrian -- Support an author and your imagination. Tales from the Wood - Eighteen new fairy tales. More Tales from the Wood - Eighteen MORE new fairy tales. https://www.feedaread.com/profiles/8604/ http://www.amazon.co.uk/Tales-Wood-Adrian-Farrel/dp/1786100924 Or buy from me direct. From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: 21 March 2017 16:53 To: 'idr wg' Subject: Re: [Idr] 2 Week WG LC for draft-ietf-idr-bgp-prefix-sid-04.txt - 3/6 to 3/20/2017 - extending to 3/31 IDR WG: Perhaps the WG LC came at a bad time since have received only 1 response. We will length the call to 3/31. Unless with have substantial input, this WG LC will not indicate consensus. Sue Hares ------=_NextPart_000_0094_01D2A7F3.011DD6F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Thank you for letting us know. =

     

    Sue =

     

    From:= = Adrian Farrel [mailto:adrian@olddog.co.uk]
    Sent: Tuesday, = March 28, 2017 6:42 PM
    To: 'Susan Hares'; 'idr = wg'
    Subject: RE: [Idr] 2 Week WG LC for = draft-ietf-idr-bgp-prefix-sid-04.txt - 3/6 to 3/20/2017 - extending to = 3/31

     

    All,

     

    Just a = heads up that I am part way through a review of this document. I hope to = complete it by the end of the week, but I am currently on vacation in = Chicago and so not able to give so much time to the = work.

     

    So far I = have a number of nits and minor comments, but nothing of = substance.

     

    Cheers,

    Adrian

     

    --

    Support an = author and your imagination.

    Tales from = the Wood - Eighteen new fairy tales.

    More Tales = from the Wood - Eighteen MORE new fairy tales.

    https://www.feedaread.c= om/profiles/8604/

    h= ttp://www.amazon.co.uk/Tales-Wood-Adrian-Farrel/dp/1786100924

    Or buy from me direct.

     

     

     

     

    From:= = Idr [mailto:idr-bounces@ietf.org] = On Behalf Of Susan Hares
    Sent: 21 March 2017 = 16:53
    To: 'idr wg'
    Subject: Re: [Idr] 2 Week WG LC = for draft-ietf-idr-bgp-prefix-sid-04.txt - 3/6 to 3/20/2017 - extending = to 3/31

     

    IDR WG: =

     

    Perhaps the WG LC came at a bad time since have = received only 1 response.  We will length the call to 3/31.  = Unless with have substantial input, this WG LC will not indicate = consensus.

     

    Sue Hares

    ------=_NextPart_000_0094_01D2A7F3.011DD6F0-- From nobody Wed Mar 29 02:24:26 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE7C1126CD8 for ; Wed, 29 Mar 2017 02:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FTbQyRhU_BiB for ; Wed, 29 Mar 2017 02:24:22 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0104.outbound.protection.outlook.com [104.47.0.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 832EF1243F6 for ; Wed, 29 Mar 2017 02:24:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=SNIAFSw6p5Dsj+DEeoTp3lPq0Dwc3GaxNErkIZn8eGY=; b=coyfxFDMPcEfrRS+in1th/y6ufdNPxSM5o6sbDAik7LbdYDv9K/DItAA6rSx9ieisII0bR13QYUJ9wTANRj4VXCabMwlEkEL/BvH8Wxqb0atIZamHC2+hJdBUT5t2HRWaN+O2u6JzfX40z72G+dvfY0KhaSiZl3U2xoGR4iwS00= Authentication-Results: olddog.co.uk; dkim=none (message not signed) header.d=none; olddog.co.uk; dmarc=none action=none header.from=btconnect.com; Received: from pc6 (86.169.157.161) by VI1PR0701MB3006.eurprd07.prod.outlook.com (10.173.72.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.2; Wed, 29 Mar 2017 09:24:16 +0000 Message-ID: <02df01d2a86d$fd6ac420$4001a8c0@gateway.2wire.net> From: t.petch To: , 'Susan Hares' , 'Jeffrey Haas' CC: References: <048701d29cd9$15204b80$3f60e280$@olddog.co.uk> <022201d29ce6$ffb2ba40$ff182ec0$@ndzh.com> <02dc01d2a25b$a1eca590$e5c5f0b0$@ndzh.com> <3b9c229a-4573-c586-8627-3a8c38539ff8@juniper.net> <050901d2a3fd$734b3e10$59e1ba30$@ndzh.com> <20170323181052.GL27015@pfrc.org> <001f01d2a401$1fc173a0$5f445ae0$@ndzh.com> <20170323184608.GM27015@pfrc.org> <00b301d2a408$f975b460$ec611d20$@ndzh.com> <038601d2a4cf$dd34db60$979e9220$@olddog.co.uk> Date: Wed, 29 Mar 2017 10:20:34 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.169.157.161] X-ClientProxiedBy: DB6P193CA0011.EURP193.PROD.OUTLOOK.COM (10.175.237.21) To VI1PR0701MB3006.eurprd07.prod.outlook.com (10.173.72.148) X-MS-Office365-Filtering-Correlation-Id: 5c7d86ab-c150-4eef-abc9-08d476855f49 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201703131423074)(201703031133080); SRVR:VI1PR0701MB3006; X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3006; 3:9wUlVQg+9V3p6pzsSrSew1NIylvfH5MoHMa0+ocYicAmr2CQJEUhgy1FfeeFg1Z9jJ6/xXYnr78z7KtI/HwcGAmRUElhvvPETBj7AAf1JPi17/Cz9aDHRDQa6oE7MU03k5wQEaoIIOCkEWv5ZZd/c75NiRK7MRYE879MfqdKh85k4ZOM9rPPmhEWh+l+9cCgBxjvK8dWPDOAB4heQTmfVbmLDtmCcmdRJX6VbJJ0hcFSiYiNe1mcZaEtXt6UPF0bCAumIrOhPhUMvbSA9sHgePpM6x3E9upzw+CeXn0b7KRMkMELS2TcrFxxsh0B4zEYGcHTdAp9+DKdG73yddwASQ==; 25:XPyYcwKxqeyJarVkSZeG2ooA4hD0vLwFJvC4RjSsM9RvEhH9lJJe0YYcYM4mAPfD4ej6Z124oX5Usreo4Wr8y5zauavXGBoFSI8EcxIW/OzDarE//BqZgtg/hYpcjSj5IdtICgcy+Y4BQM5CRIj1sguO98C1lH75KUyv6bSxGHUuY499RSYu753/HDfWpxF6NbrNqqJs+ObsCUKWze6OJrYGVF7CUQv8aNzp9dOXOtbrUCJceWEUtFzyJwqzK0ErLmHwYEYx8L1ZnZZmmiZId4YzjQOMRrMKPr3nXUMb1FmnR+03h1EjcMvumXs0kS+xfP0lkbz2DBnVo4/LFUliLAm8mCuvptVhc+SAl2BAGjsDTYmIF0j7hG/NAM+RtwyEXebe/o4hewoUgtFK3gl5xGRgZooZOLT2ouoEER0BE3JvyKWu9UMp7gU0OTbDQD7TTATg9mPXGJJkVK8XkIeajQ== X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3006; 31:LEnYNN82xZjMgy8kn64OSlZiaPhdWlli2wfE06GgNGUjM0i3/PTbeRe0QmbHfYlfacPd5BNMzdPuXmRq60K3fMCnYL9igz38JRuG78KOAym7oCkv8xBJd81RGeCAoJaoDuwNTFOpAVaCy+OawqdHeS6eps0obXkghtqJNAavgElButoBJK+84zshMLrCBFChwT3G/sR7RlJLkw8tJjGAGGYA6A0BTBjfp9ZpkPW4+I3TNkT13M66QrSepeodBvruRcakIEUYxaYFSbqrQZb6JEa4buIzfPX0G5zE/bNVVWU= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(185440541693429)(100405760836317)(146755900322472); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040449)(601004)(2401047)(5005006)(8121501046)(93006041)(93001041)(3002001)(10201501046)(6041248)(20161123558025)(201703131423074)(201702281528074)(201703061421074)(201703061406074)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(6072148); SRVR:VI1PR0701MB3006; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB3006; X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3006; 4:MLt+USUZwEoUW/sPvpj6zp/Ow7bpl0Fzu5JHRLpd27U7y+Hfv2RkVeOQi7RvLd+nXMK8rKEGsq4GdlVhQ/gb1HH1AR1xV9IHefKC/VsS1InjWAsjdpNN67jbGA2Tt4LMSqMhnCz/CrvTL+jecSEg26CdSGjlIIsfuOtqKNcgrK2gvv0I1m8rI2Ca5elx0HCAdsp3ic0Y1ufYTrvNXybdkSO4dIbaffAf2W6U9dQanAT/bQUQS5bQNrtoIcibI20GHmCsxqNpU5hnZrr3j4j9jo6tK0oT7zrehygXuMVAhxHCLBxVrIl+FlLoQwDj14fOs9T4KsH5bhI1EyW/sIQPdcwkKzrlnwqHX03YRb4j79akmP03elThuUCP9nHaagbWvDOn4kZcMrw4z+GxE+oEpZCo0lDFSpSt05TTug4Y1mSL+/gD7uL5sVN7UobEZJ7Ph/RLCRWFmahTAFiAp9OVuJ+nzNL3OY22//MeMa+FQsLBeeoU9mcMDwp9qSkos5UgAQoIuhEWQOgImDyV3aXOLr0Vns1VS143vMLBFeQacSG2922Cv2ht4FaH7xhKStZPe9ja4VNSKodz9kOgat1HfYW/3YLRMtG1/Ya9Gdvu37vN9e6hgMPS8UZV2PFSnIn2dpOpRDBghUXELDg4C1g9dXU1a6ho5aLs/Lq02EAzBD6+oaKtBm6UJUlVVCt9FJqRGrutZXPsLbeYvvLFn4JzjAPs/TV2QMTZQEvqWTVorTRoc7yKELo2qXPmexkWk9CwSG1rHLSPIPx5DxPdtxvANtPYWQ5ZGishDZk1h4EbUE6oid9MsuoAXCznmfM+jlb2R/AbkYcrOthjbOp0b1ug5xRgKn6UC589B+wcKsB67qhNrnTx3vhOtEL39+GGCrEVMI8SuIebdPb8ZMdB89iXAw== X-Forefront-PRVS: 0261CCEEDF X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(39450400003)(39400400002)(39410400002)(39850400002)(39840400002)(39860400002)(51914003)(24454002)(377454003)(13464003)(44736005)(6666003)(3846002)(6486002)(14496001)(50466002)(50226002)(53936002)(6116002)(4326008)(25786009)(62236002)(44716002)(966004)(4720700003)(230700001)(53546009)(1720100001)(8676002)(33646002)(9686003)(42186005)(305945005)(561944003)(5660300001)(2906002)(76176999)(81816999)(50986999)(81166006)(81686999)(38730400002)(6306002)(47776003)(7736002)(229853002)(189998001)(6246003)(93886004)(86362001)(6496005)(23756003)(230783001)(66066001)(61296003)(163123001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR0701MB3006; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; VI1PR0701MB3006; 23:fdxoPX/qOYkQrraa272RYtIR/CEgAFAblm7LH?= =?iso-8859-1?Q?C0jFczZj1j/uLaRd6k8t+0qQG4IKIWURpEY9wg58F/fv9qTJYbqnDcrhPN?= =?iso-8859-1?Q?L4U4QOqRIbQBcEyMZ7qE4a5yXz5XHTDRgf3BrjePqLoeg7EcJJSpOXuUiN?= =?iso-8859-1?Q?2pBSGfXO9QkOaDe0pJ4evFBdFc6m7HqIPPJIMSgv6r7L2Fcpq9rKxwiDzw?= =?iso-8859-1?Q?IPKdYfzXn/ntr3WKlUBPE3MmLeSFRX3hZ1yRDmVNCPlHNpikMVer8Ox3ev?= =?iso-8859-1?Q?uoacGgWHPy38wi9q7+h6jonmOpb2vexjpWNDp659DPQwMjRqutHM9ggMbo?= =?iso-8859-1?Q?uQMa38ueandLAxSpfG4bWXWRwNOFwqgKlPA4jRNOcMjfcVxgFKPpXrko1W?= =?iso-8859-1?Q?ws+cmhxFWElEBqC43sLMo3ZpnsR7niKKuXNX30IK8sdBYk5vr41v7g7gV2?= =?iso-8859-1?Q?XWeKdbYHfSYEtCFX0OEwwRvDRgyBuL9GQPCzzgmYGiJMJgZegfveyrIx2M?= =?iso-8859-1?Q?+BinCyXtAW6PrSi0g6VFIFGMDYSJQUvBFBw8L6jSLdD04BRU7RSJZ+IiXI?= =?iso-8859-1?Q?gdMVIYcSa72XOALjMRj/m2bB/mDBosGxP9v2Fx6fKCSiVtapR/amyuSMzz?= =?iso-8859-1?Q?9kn9hVeCQEhD3xezt/rlLOAwp79fuVPXp0xqXdZZwmaf3mcFK5GDL6SzHh?= =?iso-8859-1?Q?SY4hHp+PxISn7+Tqv5I1YcnwVFhpAR5KxeycxQXbQG8GHIAMVOzmWkxiOd?= =?iso-8859-1?Q?snJRH93Sh0gSSf3Z2W2++PBjNE1MAhhlkxNc8b7i1FeJNiOg9KoAog6XVE?= =?iso-8859-1?Q?yo3sgRl/vqAmSg3IaunbCqeuf0PqvDU5s3EBprKnx/v/FFIJIp17nFkIY/?= =?iso-8859-1?Q?neVb5D6yuSiVUVvXSYbXnFNqKKETsYw/8yKGgAfdadwJF0KWZihqJ4fEVN?= =?iso-8859-1?Q?+VE4U6L17YdNSQmBSlfUF1T7hHz+B/Lc1PpwXHODLiEJWfyoZc6dx+rFef?= =?iso-8859-1?Q?oC8oUEt3+I6sxnvfQajQko/4lLj2XClyaKdqynq32V6cdmR7uTnUp0xCNy?= =?iso-8859-1?Q?M7xjpKOkfJr5RnG7uDMThFlXAutdJbwqFimn9sEPnqDK5eP4Vv7BGElhTc?= =?iso-8859-1?Q?uzzj0G4GiuPAU2pRYOsnBGtCrM6TeCgb+xHctMMSgb7pbZo2qksIAasK1X?= =?iso-8859-1?Q?DVEIoWzoCqDtStt28VOyR5q/l7OHaAB/48bOgXDkfuJDo6kFzXjSljdfWD?= =?iso-8859-1?Q?ryFM7wvQEq7+mq+j3iVkrbetveYOZXDUD2/cTLYDgcXOlDZs638Fjf62zA?= =?iso-8859-1?Q?uywztdqaoNMsTFxcCnE7Y8gR7Gn5D+LTLNvPWfVXnqEFK9TtArHrNWsOmy?= =?iso-8859-1?Q?uZ8K41xXgUAtZx4izHxWayNRfLQ9ZOS1RFCub7gHqHegUPcMxVzommzMou?= =?iso-8859-1?Q?FRfwO0J9EFR7wQzMHgwH2Aq/nlY33+kNBa7Vl?= X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3006; 6:VOq5EXXWEB4sce9s3/X5siO6OlzBsUgsXz8eFqp3SfaH3FWq4KIznePmHkjGLNbC6piOkzew7u1fGPJqaA8ja6NXnLkOpT/eLqA+KVnrcssBavApFJa/2zIJE4sKFG/w8t/ExdXatcqFzoO/hXV0E/g4T1CUKxrf4Dww01M+1SSwTHQ4yAXtDHlArF5vgXoCxg/d5+38dr2BlodTfstaFwujA0YwRw6UMgnwrYVziJwgCUF0R/0b0I/LRpr8mvThWQ+kFB0Gb25O1aBu8AELMl7fA2yOUwI59cICaPU87oIKexBTo9nMd4AyCETKAxKuRHDtSW7JfhWVzzmYYIdoPLoF/9TnkMVsZ8KLu3zxKT6VSYJlZKP4I4PWtJWiXCDSnhsAPrV+zlFdLaeIc6FtJg==; 5:k1TBR5dj17/+wU9KfY+ej7gm4I6Qmaed00F4yoXIo/zBTgx+abxJyvP9kdBb9yjjvwBGPtsKdZxtiUz2/zwX5WlnTH3E6/khfcPspMFixSVcBeTpko610HNoPh9sXtOsVo70K84ECS2BB0ko95bChw==; 24:GQOENDllqHRi/3xzzPLQazuIFyKzOOj+8p7cXKJ0A7LYeRr+kP1GoFyBI/hwzZp8c/JBVCWNhWs3uOOURXFVBFvnHfjEzx8Quu7osMz9K3I= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3006; 7:VlYNOysmm4sW21GDPgcQCoFgp57Rp7nuqeM2WXD4gSCZ7GVLlntCwa6f6TcbZXe/Rpk33SXLw1AUwhTw5+5pz0rmnm+aVP15K4X67aDOqKZdhrVNLmYPbPYyHqCW1oIC3eg4Dkiy90tnmzLOLnoI6gIbsPSfJXLHJLQv/f/fpM/WfhTdaXIiatcHCHA/Gehd3T3NByt6oc+kReJ3kT8/ZomSspvRbLBUSusDCWHrCGzVNskX5BGWMPt7MtALwlkO7IliyD8CKHBgZZ9UM8xqvlnGqhLsXG3wevZKFi6/1NGNHFVwiLADYZhvGQgNDumCc10LYlIPvJ61JPgOT/5m/Q== X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Mar 2017 09:24:16.1579 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB3006 Archived-At: Subject: Re: [Idr] Thoughts on https://www.ietf.org/id/draft-hares-idr-bgp-registries-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 09:24:25 -0000 ---- Original Message ----- From: "Adrian Farrel" Sent: Friday, March 24, 2017 7:52 PM > Returning to this after a while away, I wonder whether the problem doesn't have > a deeper root and so a simpler solution. > > The problem could be stated as "Sometimes code points are assigned from BGP > registries through IETF consensus documents without proper care." > And the perceived solution is that the assignment should be reviewed by suitably > knowledgeable people. > As Jeff says, "all eyes need to be pulled to one place." > > I don't think this problem is unique to BGP (although obviously, those involved > on this list care most about BGP). > Where else does it come up in the IETF and how is it handled? A propos of which, draft-evens-grow-bmp-adj-rib-out-00 squats on four values in 'BMP Statistics Types' and, although not mentioned in IANA Considerations, redefines a bit in BMP Peer flags. The GROW WG appears not to have a procedure to deal with this. Should we take the authors, T. Evens S. Bayraktar M. Bhardwaj Cisco Systems P. Lucente NTT Communications tie them to a stake in the foyer and throw rotten eggs at them? Tom Petch > Some working groups are recognised as the centre of expertise for a protocol. > There is an expectation that *all* protocol extensions are done in that WG. This > is usually captured in the charter so that other WGs know where they stand. > Some working groups are recognised as the centre of expertise for a protocol. > There is an expectation that *all* protocol extensions will be reviewed by that > WG. This is usually captured in the charters of other WGs so they know they must > send documents for review. > Some protocols are acknowledged to have a base wider than one WG and a > Directorate exists to help the ADs by reviewing the documents (just like > RTG-Dir). This relies on the review being triggered. > > I like Sue's 3 points and I think they would catch the majority of cases. They > don't, of course, ensure that SNAFUs won't arise. And they don't stop people > wilfully dodging. But they are very light touch, and that is to be applauded. > > Adrian > -- > Support an author and your imagination. > Tales from the Wood - Eighteen new fairy tales. > More Tales from the Wood - Eighteen MORE new fairy tales. > https://www.feedaread.com/profiles/8604/ > http://www.amazon.co.uk/Tales-Wood-Adrian-Farrel/dp/1786100924 > Or buy from me direct. > > > -----Original Message----- > > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares > > Sent: 23 March 2017 19:09 > > To: 'Jeffrey Haas' > > Cc: idr@ietf.org > > Subject: Re: [Idr] Thoughts on https://www.ietf.org/id/draft-hares-idr-bgp- > > registries-01.txt > > > > Thanks for the ideas! > > > > 1) boilerplate text for allocations, > > 2) flagged issues to one WG > > 3) cross-WG review button in datatracker. > > > > Sue > > > > -----Original Message----- > > From: Jeffrey Haas [mailto:jhaas@pfrc.org] > > Sent: Thursday, March 23, 2017 2:46 PM > > To: Susan Hares > > Cc: 'Eric C Rosen'; 'John G. Scudder'; idr@ietf.org > > Subject: Re: [Idr] Thoughts on > > https://www.ietf.org/id/draft-hares-idr-bgp-registries-01.txt > > > > On Thu, Mar 23, 2017 at 02:13:07PM -0400, Susan Hares wrote: > > > - If flagging for more eye review is the case, then Job's suggestion > > > is the way forward. It works for most YANG modules. > > > > As I noted off-list to Job, pattern matching works great when you have a > > pattern that can catch it. Better than nothing, especially if we end up > > with good boilerplate text for allocations. (It might be worth having a > > chat with IANA about that.) > > > > > - If having the expertise to review the "flag" is the issue, 1 WG > > > being in charge of the situation will suffice with the current setup. > > > - if cross-review in all BGP working group is issue - then try my > > > registries proposal + IETF consensus. > > > - if distrust of a single answer from WG shepherd, WG chair or set of > > > WG chairs - this draft + Eric's suggestion for who can review. > > > > Mostly, I think once an issue is flagged, all eyes need to be pulled to one > > place. For the registries in question, IDR@ietf is probably fine, as long > > as we reach out. > > > > While I share some of Eric's dislike of process, I don't quite share his > > paranoia about process blockers. When things go awry anyway, the best we > > have in process is the appeals process. If we've reached that point, speed > > is doomed anyway. > > > > > If we can define the largest concern(s), let's we could start with > > > that solution. > > > > I'd suggest finding a way to flag stuff is appropriate. Nits search is one. > > Allowing chairs to prod a button in datatracker that says cross-WG review is > > needed might be another. I suspect this may make good wgchairs discussion. > > > > -- Jeff > > > > From nobody Wed Mar 29 07:28:20 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25A65124D37 for ; Wed, 29 Mar 2017 07:28:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7jPnhZn_2GoQ for ; Wed, 29 Mar 2017 07:28:17 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0114.outbound.protection.outlook.com [104.47.40.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A525129474 for ; Wed, 29 Mar 2017 07:28:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=X28a99nadR0RnpihqZsrZFJ9JpzZmesV3e0ckMGWNQ4=; b=fvKNYP2gEs9p611+cfpc/M0TuL+PXxOmKLFJ0We19QkLeQoaGSxad5I4mp6mVUqifzGeLkBECbJLiBmlXI4skzR2iiW7OOxxp4Xycfq6mz9RE7IfCizrR9fky7gZTFcbQftuhr+sTdYQrPPV8U257zelrAQ1YctsLqkuqUQe6NA= Authentication-Results: btconnect.com; dkim=none (message not signed) header.d=none;btconnect.com; dmarc=none action=none header.from=juniper.net; Received: from [172.29.34.129] (66.129.241.14) by CY1PR05MB2505.namprd05.prod.outlook.com (10.167.10.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.2; Wed, 29 Mar 2017 14:28:15 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "John G. Scudder" In-Reply-To: <02df01d2a86d$fd6ac420$4001a8c0@gateway.2wire.net> Date: Wed, 29 Mar 2017 09:28:10 -0500 CC: , Susan Hares , Jeffrey Haas , Content-Transfer-Encoding: quoted-printable Message-ID: <9B5CF8E4-23EC-44BC-9379-8BE9DBD214A1@juniper.net> References: <048701d29cd9$15204b80$3f60e280$@olddog.co.uk> <022201d29ce6$ffb2ba40$ff182ec0$@ndzh.com> <02dc01d2a25b$a1eca590$e5c5f0b0$@ndzh.com> <3b9c229a-4573-c586-8627-3a8c38539ff8@juniper.net> <050901d2a3fd$734b3e10$59e1ba30$@ndzh.com> <20170323181052.GL27015@pfrc.org> <001f01d2a401$1fc173a0$5f445ae0$@ndzh.com> <20170323184608.GM27015@pfrc.org> <00b301d2a408$f975b460$ec611d20$@ndzh.com> <038601d2a4cf$dd34db60$979e9220$@olddog.co.uk> <02df01d2a86d$fd6ac420$4001a8c0@gateway.2wire.net> To: t.petch X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.14] X-ClientProxiedBy: CY4PR04CA0027.namprd04.prod.outlook.com (10.172.133.13) To CY1PR05MB2505.namprd05.prod.outlook.com (10.167.10.26) X-MS-Office365-Filtering-Correlation-Id: d465a0ef-7e02-458e-4a5f-08d476afd71e X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(201703131423075)(201703031133081); SRVR:CY1PR05MB2505; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2505; 3:dOcdgcAjMKV1+XJEFMNHxefv8MQv2x3VvhftW4ncDqb3CHyfurF8lgngYPYjSZ2XpPmuOh0Zb9TmMV/cDkIdwDjGUt58t/NDjWXStxBzGvguKC9O9hLIyFxSY8VokdcMRh7A9LQUJHMpXfNao3oUhDLI7OqSJX2Rf8uyUvHswpd8mtxju6+hCbPnQIUQBEfCBp0OBDwNlrE4DLQNnE25IX9U6S6urweNtB6NEz4Bs5HDtPKRpFUxmPVt3VPZD5MDctEsCd4iQd6EBP/HyeXjacbEQnWBPuM8mWQl1Em/MOS2yht/QJ7XXBcpS9fvbPzDCPRWqF1wN83iYEXt7Gpw0D22cijSBBU3ar3bNa1e+nU=; 25:QpTXMKeXQiV2fhsyi4gA5VSLhWWr6IS2QMA5yCUa1MODmPeiub5Agg6X/Mt9DKCMsvVqBA+10A0DmetfJpYiMSadcRE7KnqVB4VDscMfucNcYWw7Jfd+BkLh2W6aWG9MXp6P0VqnjkK5y24XINrYqrovIZBDzHWjV3PXF4gHs9W/LPTmI2alzNiTGevdt4Ef7cCSZllmSupH/fyUnrUE27nnkt5GHyHiFtxri+wuM2Qq2b4e/AIWg8mTtMf2B/XNZNcRyuMpCTpcc+7SILv2yeUPSuJEtRcTFGR4Q2eUXD/CBnEI6/6LGgffKvHeYZvPaffud+mYLC81/xPsvMFsq2SnRcA13JSweC1B9g/cDTBy7e+8tCvhLYjfWDSMrJCcRIxVC0zuXc3oQr53kExZD6C6p9MI//cTeaJ5gdSSzoUTtl26lc73DyOgbOwxN5J12qTQWrF3XK7MAK/0K6jvkQ== X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2505; 31:uS9UM1QV1xgti4kK/IL7c+34HIYWMhuamY/iujfECLR4J9x6xBguYU/+lVPUuEX8eEf/d5luuZdX0YPAZ7Pza0SszJazapP6dWaJNk57ocQSCR2RDiSOMCkvxRrSruLNAnApNZY7NKo1Oj/Q1asuPuqqJyF13Niagv+YQFSi1rBND5elt7d2kCMXSgsWCxoOKYyixEyQNEHSv+g4zSetx6biWkZNajw9T8ux2Hp9XemIgg+9/ShrC+8F0eSVNP2QkAemYbQZn/GhCamYSIZ4kA==; 20:v2DCtU+I5LMQVFZJZxbaFe1XR63yeM15ovLt/1kUc5LsBqX4UFSFd0IAR4NXg2BuxyhQWUoQoCeGEihRuxrBFsNdRgao+p72YcYLOCTlTmU+4v/cGPSMsiKeU3G5snrMoGl2I/rItZ4si5fNiGonvhiIJuYa5F8Fuhe06WTiDR9hBNwNUJTSsZO0yufaZwmPTvplbAVbTUD5Fy7hGkhFOEj/hrHQiVtNaZ+5CRMsa3ABOQpQ7YF8xOFlpA/IviSgkgovClLNcMkFZaNvjjHaxFWVJouYCaov/g5j4Z5M2v0X+JGp8TdUGB5bGBv+ddli7eaaZ7E2NfY3hcKLBnPzSwxASNP6PROAEuHJxkHb4DEXq8m3ttlrC8Q9PKGsUrMukgtNNjT+A1FYPZW4ohx4l6WhlcZFtOJ9A9N7n5un3ebBNsol3FhyQaDywjtulrOePgzlc/6MYArnbTpPA1i7u+a/xYdGpNJOMqYLBIUhWw6v6hAzBx8OcurcbxsKEnSIJ/IGPHxe31xAgKqpw8jYr5YP/WUdWzoDbj7EawpusgTAXifT2/T4rXUI2vvx/WRd7jYbRPAdIkJfZTIDc0OKATDdWb6wiKmptul1BBh7Jbc= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(178726229863574); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406075)(20161123558025)(20161123560025)(20161123562025)(20161123555025)(20161123564025)(6072148); SRVR:CY1PR05MB2505; BCL:0; PCL:0; RULEID:; SRVR:CY1PR05MB2505; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2505; 4:bzx4E41lEgdqTqMlIICH8BmbvaIEHM1qNDGfc2VVDe5v6WtbDkJkIeY1grne3dHRXSom0o417Nt9seMSLo+lZX1OP7pjG+njGc7hXTFinxKRIYDh9yPhul+qCsMoYgKX+Ge+atmaOTUZ+ul1JkYwaKeZ+Z2EpXQkHV6zF9S+iZ0ucLrEPGFKYxCUInGbuDgVJoiBxmpSmBzXGmiNANc7nR+JWoVphWtKfQH6fTIrQNOhytLnCXqWekU3Qa+rnpBgITSHbn+EAe3bjC2xuhgDHKrMSNTDxezWDZOFlCp4MpPHMm2soh9dDFUQgoq7rjRXDFrX0CZIEsFEtah4Uu9k1Yhx8J2eJRGfuuHE4iFtfR8bxsEY03OX43FV8YCWIqQCmGnc3R7aG4DVjekHwiu+Yusau8WLEZrqYLKLHilgH3VHyy6KhqDm+5ltxgR267CLjP7C+GE+rJ4MFXWaDFlE2tU3kr6IEMPEeWuK86AFZc4hEGezat1aXVr2TgaJiOV0mWgjSK73pdKaW/nZJQMEp/Zck0zwSWV+0F7UTsaqSEJE/pOFB912h7Svo9rKSFyn0pefC4S43nLM8yXpYKNRssXvj0/rhUqtB3cXRZ6qWUiGWYDm1+M9aRQOFWg7gJQeRK4OYec7ituZvznV6VUiWku7SpRGtaa2cuvX4a4j/GeOvfCgSTjwtiCl8iaC5nhK8wf4rcRq4fbH1XDD4jng8Yoih4iRVI1daI7FXWwbWvDqvMDfvCEztobS/f9/HWRo6fosEeblcAI8e3/p23gsC1CZ7lXZDa9H9quSHJzttWVJt7mnxCfXTjZGyLAyYpEH X-Forefront-PRVS: 0261CCEEDF X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(39450400003)(39860400002)(39400400002)(39850400002)(39410400002)(39840400002)(24454002)(377454003)(66066001)(47776003)(305945005)(38730400002)(90366009)(7736002)(110136004)(6246003)(6486002)(6666003)(5660300001)(6916009)(86362001)(42186005)(50986999)(54906002)(189998001)(2950100002)(76176999)(8666007)(53936002)(230783001)(93886004)(97756001)(81166006)(8676002)(6116002)(83716003)(82746002)(3846002)(33656002)(8746002)(25786009)(23726003)(2906002)(50226002)(36756003)(77096006)(46406003)(229853002)(4326008)(50466002)(163123001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2505; H:[172.29.34.129]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR05MB2505; 23:9qxruKcZysMoCgkp1TVf9sq+Ikso0ksUvVe9dUJwg?= =?us-ascii?Q?cQ4MDAA3GZruJKvAtDhMBMxn2PM6AURoOIMpkq9i3XghucdwWvSmXBnM2Qa0?= =?us-ascii?Q?vj3PzcvY9qRK+I2OsN9o6JwOCZf4jOVzroD+jGtRRBC4nTAH+AIR+uzDinEa?= =?us-ascii?Q?6JGUHRom8QiXv3ulQGcSYRHXp0mpVyL0SqGuvBKzp1PmOQrUwgL/aRIWeZZ0?= =?us-ascii?Q?jxeBBo6nQrE9CtwolHL7Z/6KHIvgYpi3IbkG9Hinz2EyRyJcF1HBZTFG/fwa?= =?us-ascii?Q?d4KOtPEdYOL5CPxDhCf2pQbVgKa9xK+w+qIOZ7cFdPL4mUUvMtWWeH4LTZBC?= =?us-ascii?Q?WOA5EUBV1X6Vh8HF+x6nBIoJP/c07Q8Ygk0QuetrnSnnqzZ7ZsjoVyUqrvqe?= =?us-ascii?Q?a4je8vk9NPT/OcVYy8vJ3SPpr2F6wbsGIL6PmsaNBXu9qz/wiDzUupLD7FXr?= =?us-ascii?Q?sUL0zARzVuvwuFrY8/K6ecDMtBndnxunab8AQbsboIheVQ6JaXxA5zfF7kWM?= =?us-ascii?Q?SS3ieJPyN65XC1EFMBmm740ACsNVUcAQ+h3sLSY7LZ6Rt45P4n546HJN1Gyb?= =?us-ascii?Q?f+WpZeaybIyghj4xh8q0kgT+N1qgwvkXEI5IPqT+9jISPDYep0F62uGVxgSj?= =?us-ascii?Q?Hc4hD5AdUiAqmUnhrOu/Yy4wuf6G7X1T6tPKoh5nEwC4GAgE3yWikzDtHUu2?= =?us-ascii?Q?0FVb8O9GbjlBI2gr3CCodMdBtYlkaoE/5YgxxJMCa5tEekWXat8PMT9ZhA1A?= =?us-ascii?Q?dTknymdwHarQxh2xugeuYN792a2GuxEHjK7H+l4IgFEb4DBpNL+4ijsl2uI0?= =?us-ascii?Q?ZA5Kn/ZVcVa/7Tdh+qC84dPR5sMSK+M/3ueiv0jLMmAEiy4C6IEcjAaJ94Hn?= =?us-ascii?Q?uCTyVcsPOaY1mjIdQrbb+pccrU1zX4jXZNtzAKl0oFJkYxfknbOPuJsKqb+J?= =?us-ascii?Q?4wp8yTLkT+HLOMu5wv2Bwv8S2sj0zIiJ1wzkoQeXzOAaOpFf5j0tdHEa+cwY?= =?us-ascii?Q?XbxvXjx1V4wOiZA7GxKoglPRvFwAejBvTXQhS1nX516DIl96QrIAg6L413ux?= =?us-ascii?Q?Lj/O3+hxtzP2sJGqThh/Q4N+E5dMF3EFwhnChQx07HBloiF++yuvCjgdnuq0?= =?us-ascii?Q?pbXCMqHP/j3mDSqDK+jRTqXT9Ser5QqGoRh+EnWyCb5Pmo/74SFdJT5czuYY?= =?us-ascii?Q?C54ril93glU6NCVIrx2AsVQF5LUUspH5XooIZvpejKqx5zZTB0Gf2L+ddd9/?= =?us-ascii?Q?uYxAWfdXsWCqedXNhBaa3mNxtbUay2Xi8b03csvuqtLnwgP04+6SGWIM5qt/?= =?us-ascii?Q?F9PG3uOU2pKb3kw9QGAKgoFb4Ex2V1k78yQjK1s5w0r?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2505; 6:Gw9DojShmfkTeBo2GW9tPGqvUP4xHlASsJKJHvx0DGWvEyzu/sQRb+mCj53nEpiRhlpC9AwUYqQorXDL0XpKbib67yELc/26fRaq/uyLKinP8DIurOBpzt2EHEw11px1BzZDSDuKj056rf5fTQl9rQSeHrctqmOLTs1Bp8GKHtF5KP5uw1DOrurVPK+YCeKXYf1y/9qTgbXp1b4sOYBwFGfVyJ/u44wd4ABGZ2cMD7DtjGIFSIHIWIP/usSe6LXIpay4AMqnDHjoG7T2yoiuKMMCa7gQE81/hVL1drZY2oSwlz74BpOE4oe9TRBTXhBC3NzM86va6QMgm1LDbI0t3LXfjTY5vcTAtJy0C0L61nF4eEuNw0VEvd7hLgwhkqSUovuLGfBDVEcVPahjuQyhJn/DAoKoFj+z4NoxWYjnJrY=; 5:lkR98ZxuHnyZv6w3Hx8qOvPd2JIYSjQBk+AY4bgQJB79NIMqQAMDR5e7fC3QmxgEiwWWliVnPp+6qlHepqWNlUZAeWU5BovepKdL3G8yUBtoSErBq7s4Byh2KKSoU5t9/EDNeVVrxMKzUrL5uYacGQ==; 24:MvL2VyR9o6lTRathxDek6BeIGjBDd4EUPZhsuj2GhB72BGlRsKNtfc8A1jNExhipd4uIWL26q5eKtZ7997xAnPEqXDu+xbvRhQwMrCpwA00= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2505; 7:nb9FcmSCFcs59Z4yIw5K9ID7RwxsX3OD+4YFBndkgo7iuJoK1LJmijQFIL+riIJeVXUPfGUyAtgULXnzniFV/mJ3xHMviHB0nLVyypQMDlQ2MBHl3tUwy6k6g73/mcRMTQSKNP76kQod1e3X1K2hnhNau1nMH4PHXTJfBl/R8mDiwyO4nTREjnotLI4JYXUe7HGmBXWg+OYFQjy3CVYlyIpsEIcd9Jh8Ma6RuH8WacIyIWdlZhLtIhDVk8qagLj3gi91QMxahDoR552qgDDU5uWr0LMGnM4nTTXkxiTIZ48fkSmTrx45NQ33WYQBVbeerwNuwTXrmE4E2vNI6YqdbQ== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Mar 2017 14:28:15.7315 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2505 Archived-At: Subject: Re: [Idr] Thoughts on https://www.ietf.org/id/draft-hares-idr-bgp-registries-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 14:28:19 -0000 I've already brought it up with them and I expect they'll be correcting = it. No involuntary restraints or decomposing food were required. They're = all new authors so presumption of good intent is indicated (not that it = ever isn't, absent evidence to the contrary). Thanks for bringing it up. --John On Mar 29, 2017, at 4:20 AM, t.petch wrote: ... > A propos of which, >=20 > draft-evens-grow-bmp-adj-rib-out-00 >=20 > squats on four values in 'BMP Statistics Types' and, although not > mentioned in IANA Considerations, redefines a bit in BMP Peer flags. >=20 > The GROW WG appears not to have a procedure to deal with this. Should > we take the authors, >=20 > T. Evens > S. Bayraktar > M. Bhardwaj > Cisco Systems > P. Lucente > NTT Communications >=20 > tie them to a stake in the foyer and throw rotten eggs at them? >=20 > Tom Petch From nobody Wed Mar 29 08:35:17 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8DFF128D19 for ; Wed, 29 Mar 2017 08:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.697 X-Spam-Level: X-Spam-Status: No, score=-4.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lO0vj6ZZqf2o for ; Wed, 29 Mar 2017 08:35:12 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50138.outbound.protection.outlook.com [40.107.5.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 40AC0129422 for ; Wed, 29 Mar 2017 08:35:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Bo888JWsr+fMtHyA839j9gL/dW3yMumEKdPsWVaSb1s=; b=d/HARLl9r8nelFrX7z3L1+CLWC+zUTgQq4/Zpvp0Aj9ajh29goPQbydnDq2jPpY6xp7nx1WDhkLUBoXAXqx6fIhrH5BUrxLlHRB5ccMXx5XxJkYufyBNdTCqpjQFhUA6cawgaYjv0pURpKiwiSn4dPOuFeSvf9Ck9tR98kh/TBk= Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=btconnect.com; Received: from pc6 (86.169.157.161) by HE1PR0701MB3002.eurprd07.prod.outlook.com (10.168.93.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.2; Wed, 29 Mar 2017 15:35:08 +0000 Message-ID: <008e01d2a8a1$cc8f2560$4001a8c0@gateway.2wire.net> From: t.petch To: "John G. Scudder" CC: , Susan Hares , Jeffrey Haas , References: <048701d29cd9$15204b80$3f60e280$@olddog.co.uk> <022201d29ce6$ffb2ba40$ff182ec0$@ndzh.com> <02dc01d2a25b$a1eca590$e5c5f0b0$@ndzh.com> <3b9c229a-4573-c586-8627-3a8c38539ff8@juniper.net> <050901d2a3fd$734b3e10$59e1ba30$@ndzh.com> <20170323181052.GL27015@pfrc.org> <001f01d2a401$1fc173a0$5f445ae0$@ndzh.com> <20170323184608.GM27015@pfrc.org> <00b301d2a408$f975b460$ec611d20$@ndzh.com> <038601d2a4cf$dd34db60$979e9220$@olddog.co.uk> <02df01d2a86d$fd6ac420$4001a8c0@gateway.2wire.net> <9B5CF8E4-23EC-44BC-9379-8BE9DBD214A1@juniper.net> Date: Wed, 29 Mar 2017 16:18:27 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.169.157.161] X-ClientProxiedBy: DB6PR0601CA0031.eurprd06.prod.outlook.com (10.169.209.17) To HE1PR0701MB3002.eurprd07.prod.outlook.com (10.168.93.136) X-MS-Office365-Filtering-Correlation-Id: 53315434-ee2a-4c64-b6f9-08d476b92ea8 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201703131423075)(201703031133081); SRVR:HE1PR0701MB3002; X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 3:Bh0O10tUlkFTmYwAtU3xWURXtXNRUd1LCPUj4p61yAA2KodEeR2K3t61MFVUJkplcR3JyqmJ4yot7jm9cipYPjLa2sPLdhGLVCulHzqh3SmkLsMYbzWodoFr38ZNsW9kMnqQ/eScG6nXQnI8QE3agw6KbcgSkpVsW4ydAOL7NXmBPYgOeQrLT/Xim1AI9A9dOk1M6UjLGJnGSUQ4j1pWGjbVrV5Oh9cUMjlG9c7s29VbTD+fdy4BJ9E1R0Jz3TNK4sMktKpiAaYF9mk+cBR62AeFoNa0iWiDJI48emxLkpgkTZWnYI/ijavz/ZSgIj4XB1TIhtdi0Fj7gzCij+QwaQ==; 25:vpmM5dYF7exLwLXKY4sJc9AqWmMAOOnkdYUdiEf0EMQxy2J5q8HxtfhtZ+neY8RrTtcPeHkooWtiE/jzCRTWHTYH4HzvGwdOcaYox955MHVs3Bv2Qxe8Uc+NJrDVdfuUa9PS5oHaQEawEOaf2O0GfqZSoyOuU85/t2vHDGZEYHxFzqhDznjDZW1SDjMdk8HPKHrNpk83OvmxPkEHKE5I5CepKyJdMMKwa6ptItD1pUDpcJGdvpWWaReOVDgGX/luyFzX8S8O0SsOiLktJykDpO2BNYImwAKfkp77L+Km7jhUkeX4w00tMUEDVYLRTzcvg29b8KcK6L5vGzVTGJLesiYwQ8M2fo0PWMR5eJM+i3LMHj/KKC13S0w7LbU+xpPFp7/zyjGyO20t7aZvuHatncnjVF6O+uwR5vPmFVPEd2y8ImVrXwWrq1hlHvvNxmyNNPElAHGz2jsKN1WeJrAtyw== X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 31:0gXEKutKulxmNlhUqpM/Qn6WSuml5YLaWpbPO4UYAd4JduJYq0zKq95Ng4nFCWyqeI4jxIHsxJ5n8WVZfOivd9yKS8uUlEqslmziaC8S8lJ06ICkETTzrYPIK3LPRLe65ji0U8aOzV/0eyVfT9rjr3oJJyFDmQFlVGRDVvZT6761T8AQYdVJCYIPujHvAceeY55CKuCwWYQIyyd8MMA0UafIRWPdjsLQ2YdNtCqv3qVMbWVtTtWEUNkA1VUtnMe6xuULZwxoww5DUi3kLVaZfQ8Y5KlQszVZQAKJkLdcy5s= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(178726229863574)(138986009662008)(1591387915157); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006041)(93001041)(6041248)(20161123564025)(20161123558025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406075)(20161123560025)(20161123562025)(6072148); SRVR:HE1PR0701MB3002; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB3002; X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 4:gDejw1OAYl+w1Rh4/sMffvlhHod6P29tu7DHCel6sCCTW38+UoDj9sFihr/kFrt0Rscq6CbAoTIyHue/lJXsgZONp7SxPEEAyzgWzxrVxxhwxPklL5qjGgVx+QRQpNrM73sNx/Jf/aenGHtoJYCHfBIDJkjk40lv0LBvWnm5SJHqQbijAsMw6rMkuV8AVYQXcB2Ii3C/TKACs9A2StsHq7NixzajZKAV1DhNEK2BIh65HC6I3CWJi+F6P0LOLFPz0yUrUVX+WjAbCdOr16haicma/DftDi3LKksE23247laFbDMxDbnFzu3ER9AJbAFoKkUn360TlM1BE24RLMYCJ933Bdy0NH9W7nrUzQ1p2himHrqx5JAIs0VNIEJGoOmZ/ZS+bQfwFDEuZMvWzeTDnVCvaBPZmdPbLB6v79fR9FlE4V/uKhdgL3pJcNwr28OYghuFrv9/YslivjN9biEEjC6aMWONAPwPpZUy4f04Z5lTiM9emirQyHmcl50fEVbajujcXW+afWC6gP6FpRK8NkWlDvJNliSMP+lCnkYrxGAZw3wIvJoKCecAa1S2nrZC4AhHGF3f8CzuyuAYxHbEmOYvBVeR/qMaJMvCZlKIzcY/9RtjrRWsPdmglEKap/7DvE/9MiS5zZhg574Ak5vTLsUWaUcob/jwfq4s5DBYVgtH6a0IyldKKKNHUsAeYcxlkVuWLScno9tofEm5f+ygSePYKPevcTjUJ5x2NCOM/NX9cZI9QCCzEESfrq8VYxfv0qPuq8qbQ/iqhwRiC1aZjPlZUDmdsxnh6RBYj3FS8io6nCu+fvgpPui1Fe0RAQE3z1NjonVHR8CHiiehYU6x6FiQygSroZI6tQm7/u5W2jeyoQ1pUziSvDFiCVLXlCXYOvYSfkmSMl8CAvhUOJe7DA== X-Forefront-PRVS: 0261CCEEDF X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(39400400002)(39850400002)(39410400002)(39840400002)(39450400003)(39860400002)(377454003)(13464003)(24454002)(305945005)(50466002)(3846002)(6116002)(6666003)(66066001)(7736002)(47776003)(6916009)(230700001)(8666007)(230783001)(2906002)(54906002)(86362001)(9686003)(6306002)(6486002)(1720100001)(50226002)(8676002)(81166006)(44736005)(53936002)(5660300001)(42186005)(189998001)(61296003)(23756003)(81816999)(966004)(81686999)(4720700003)(44716002)(6496005)(33646002)(25786009)(76176999)(4326008)(38730400002)(93886004)(50986999)(110136004)(62236002)(163123001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB3002; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; HE1PR0701MB3002; 23:67SogCrtQCLCPmYToe0to67GKLTmmlkSRRIfT?= =?iso-8859-1?Q?vUR6Vb0uPXT3XtJO4o6dsUIG5bf4ECmhY6Q+GVSPA8GrhUPNCFUcXiGywM?= =?iso-8859-1?Q?tb6tMb9ZHhsxp198tzANUjgZptouGdU5ic5cnihoe11jCxIvqFiDKxIKYL?= =?iso-8859-1?Q?ov0E8uGbTOV8g3HSb0AOszjQ2WY4Aqd0gFYvzin4lxwyNe9o7OTFTwJdxQ?= =?iso-8859-1?Q?nzNuJIfHaFvgpIy/FMVPdFiZUHliNeBzf8RFzxV48HAme9m21K/ZHvqSvq?= =?iso-8859-1?Q?3TjMlcg9eKZoMur6JNMJktmNY96si0OHcelbbiLicAyEpX+k/3vnVXQ+eg?= =?iso-8859-1?Q?ZKtPKCkkhWxNYw8eRxEjRu0WI5xWGXTEvEdJWsXIemvq0PrtpfF/oHN/8f?= =?iso-8859-1?Q?no2GfW8VZaBKALTMnEDmosWymPgrEs+HnCYX9VY07WhUwXk8D3qmvfXWDa?= =?iso-8859-1?Q?bRqm+tGULiC4t4tXd9XxR3+FLR80sW4gM+j3WS+pVALxfTLqs7So9kObgw?= =?iso-8859-1?Q?b69h2U0Akqz9m8y4i1X9kP5CuGsaoxV0S+sdltjMAgSJdQz5dVF0Caj4O+?= =?iso-8859-1?Q?EtSPNGrEMzD0qLr850BX9ldfaVJq67+02TO32udHzErBbMIm/UfTaYh2KT?= =?iso-8859-1?Q?grsIzPgZEcSfNsAv8YsqLwbP1nMdW6hocIC/VuaItYdogRDoirJs1Myr9q?= =?iso-8859-1?Q?N3L6Za0Jq+84zP2ngxawXqscjLEUU4TXSwyS6S+DAXjKZILugnCFtOYFvK?= =?iso-8859-1?Q?IRiC1n1G+M1KphrsjcoR9YddF6Ct+v3kzR7TzYUppwTkEzu5IFzAAHYb/y?= =?iso-8859-1?Q?55Zyk+NFKNnyfVb64TqUqXc1fJhcIQEby0COS4oBOVBUIN7zGRD08JtH2M?= =?iso-8859-1?Q?GP6swOBb8bMNe8JjnBW3zqxZFKgUyRiE1O9E1/U1uWjuwvxUJA2muD1PrX?= =?iso-8859-1?Q?y/jsi54BDD7cmpoIzh9o3W4wUdwWXdOMeQAVUwgY9S0O7B+Duw47rO0DBX?= =?iso-8859-1?Q?G51DPjNj0mPG/fj213TTa3QXJyVsT2KL9CG8KBd3sfi0SKTyA8ot+PxOGI?= =?iso-8859-1?Q?BzHXNlvbBv8+6FFMIK8FuriGN03+RQaC44JslsVrWzZsUBnuWKcZ7ivEDS?= =?iso-8859-1?Q?ty3bQOyOY19KZO3+7LrmtYuUQrKXzxzPpGhdz4lTpgaGg2Y2C+VDkH94km?= =?iso-8859-1?Q?ywJU3QrVdk4RmXo3xB5bZMD1gjZQEvOHXtRokRqOokGCNNT/z8iiyCmJGA?= =?iso-8859-1?Q?dhsygYREp6uMUyF5hqEooFxVq0SA+NB8kCQZ4CDb6DXKOrawLfJUrT9f/F?= =?iso-8859-1?Q?mkGfs/TQRJpMc5RB3bw2Tr7Q41S+jzuV5NaOcOd1dXeOcYyTSozyqn2Gy7?= =?iso-8859-1?Q?i9Psr419A6Shw1O4pZE1o6nmN0DFCHfKJW8ZG4fY+7QkrpVelWjvw=3D?= =?iso-8859-1?Q?=3D?= X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 6:AH5iOeaoFN0Qeb2F/GZ9CGXXu/y7FSSgC1mrs3bw68jutC/m7OunD2sPo8AGFPTGr8VpGKE3KigoFyFki5VHNhu5MHpzQ2+e8xuMwmOB1kn4UrkYzsLs7xU3KTNZ0TbyMsAK0n5EKs64CrVx8qYT9G2FlAA8vxMLTF+OwzWZwqKH1bMqTK1P/lVeSkaACeVo91cPRbze81cCSGaF5Q2VyhyhuHqvuCUH5e+9MvjbcLyu4ScGgQHELyP+EM5y2NC8Vn7mjwg7EZsLdWNffq+3/fS479nOGxQadQushoW2BRm966BetkcJ33zK1RHJn13TewiVprWq25O2q7bpurZjhgEjZhsdMJOIKi+vGAU2sqvE2Io2NZ6Q6ximsGGCOj8IO2Og8OPA5DrWF7mxhqJmmQ==; 5:npKr0rpi3yojH9xPHSjgNV5jU1QXPLnrLP4FEv8KzUd00eVBm2qQjblazfIMKAHzCNlAHICJfNFjf6kazvZzWeOK7Z3rJaGph4cRQ4+EHTcoR5szKHL3WEgRKcD5MwpLgsTvRXYg1y5GaVbAJDS11g==; 24:U2TPxE3Ep3rjIOmrIXLlcTvF2M2p09M0GxyFA5wu+Y4fWXp1yJZcJLqNO7uiNHxZQk1VAFHkDwPaTaTS1qMCCYL41f/wNLatKiVrNUhF9Z4= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 7:qvpL6tASt3bp1zSCCMQT1tfvfbLEBzWPpOjxLG6wIu4bM1ELjMlwF6vdoXl80NhS4ZFw5gRDwv03Vssl4KRNv9yvvp3oiPQ2bI12emrHioq/q0rISUybR6VgFuBUSV1Dw0Ku9QnkOpXP5fn/3vY3wWvQRQpA9+PQFYQ5Xg67EooUcVSggT1yhWxsKHodSJbypbrIt7GU+2PPsdld6lW2TSIWYgmAek5ESAEf14weCvNfTUbiZ7z0iWqAcWdxhUMK4UtnW8ARtoWLSInziwlntKXJyMlweyfh2Q7JF+2KWz30zYpZJqI7fXi7t1B0vZmj5sJRQngOY8dk48UN5STQKQ== X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Mar 2017 15:35:08.2932 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB3002 Archived-At: Subject: [Idr] Anti-squatting Re: Thoughts on https://www.ietf.org/id/draft-hares-idr-bgp-registries-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 15:35:16 -0000 John Should we be - well we should be IMO - asking IANA to make it clearer? Go to http://www.iana.org/protocols and you get the impression that fill in a form and the assignment is on its way; which in some walks of life it is. I think we should be saying on that page that updates to registries require the following of a procedure, varies with the registry but will involve action by the IETF. We don't want to put people off except when they are squatting when we do. The current front matter deals with creating a new registry - see RFC 5226 - but not with assigning new entries in an existing registry. One for leibacotton I think. Tom Petch ----- Original Message ----- From: "John G. Scudder" Sent: Wednesday, March 29, 2017 3:28 PM I've already brought it up with them and I expect they'll be correcting it. No involuntary restraints or decomposing food were required. They're all new authors so presumption of good intent is indicated (not that it ever isn't, absent evidence to the contrary). Thanks for bringing it up. --John On Mar 29, 2017, at 4:20 AM, t.petch wrote: ... > A propos of which, > > draft-evens-grow-bmp-adj-rib-out-00 > > squats on four values in 'BMP Statistics Types' and, although not > mentioned in IANA Considerations, redefines a bit in BMP Peer flags. > > The GROW WG appears not to have a procedure to deal with this. Should > we take the authors, > > T. Evens > S. Bayraktar > M. Bhardwaj > Cisco Systems > P. Lucente > NTT Communications > > tie them to a stake in the foyer and throw rotten eggs at them? > > Tom Petch From nobody Fri Mar 31 04:34:34 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 016E212954C for ; Fri, 31 Mar 2017 04:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.647 X-Spam-Level: *** X-Spam-Status: No, score=3.647 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yr1BvzSTRctu for ; Fri, 31 Mar 2017 04:34:31 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 4A91E1243F6 for ; Fri, 31 Mar 2017 04:34:31 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=31.133.148.83; From: "Susan Hares" To: "'idr wg'" Date: Fri, 31 Mar 2017 07:29:38 -0400 Message-ID: <006201d2aa12$153b0b50$3fb121f0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0063_01D2A9F0.8E296B50" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdKqEgezBfX0kTu+QNmj6BRIlH/Urw== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [Idr] Zombie - Draft-ietf-idr-operational-messages X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 11:34:33 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0063_01D2A9F0.8E296B50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit d raft-ietf-idr-operational-message has been deprecated. Sue Hares ------=_NextPart_000_0063_01D2A9F0.8E296B50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    draft-ietf-idr-operational-messag= e   has been deprecated.

     

     

    Sue Hares =

    ------=_NextPart_000_0063_01D2A9F0.8E296B50-- From nobody Fri Mar 31 07:10:23 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 075E51296AA; Fri, 31 Mar 2017 07:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPUI-LBwyhYL; Fri, 31 Mar 2017 07:10:13 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (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 C05991294C4; Fri, 31 Mar 2017 07:10:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v2VEAD2w021705; Fri, 31 Mar 2017 07:10:13 -0700 Received: from XCH15-06-07.nw.nos.boeing.com (xch15-06-07.nw.nos.boeing.com [137.136.238.213]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v2VEA2dI021190 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Fri, 31 Mar 2017 07:10:02 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-07.nw.nos.boeing.com (2002:8988:eed5::8988:eed5) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 31 Mar 2017 07:10:01 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Fri, 31 Mar 2017 07:10:01 -0700 From: "Templin, Fred L" To: "rtgwg@ietf.org" , "idr@ietf.org" , "dmm@ietf.org" Thread-Topic: A Simple BGP-based Mobile Routing System for the Aeronautical Telecommunications Network Thread-Index: AdKqJ23SLpD8In76QZ6KmFhm2+NWUg== Date: Fri, 31 Mar 2017 14:10:01 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: [Idr] A Simple BGP-based Mobile Routing System for the Aeronautical Telecommunications Network X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 14:10:16 -0000 Hello, Yesterday (03/30/2017) I presented "A Simple BGP-based Mobile Routing Syste= m for the Aeronautical Telecommunications Network" at the IETF98 rtgwg sessio= n. I also presented the document at the Distributed Mobility Management (DMM) session earlier in the week. Both presentations resulted in interesting que= stions and comments. I would therefore like to invite community review input on th= e document - see below for the announcement with abstract and URLs: Thanks - Fred fred.l.templin@boeing.com --- A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : A Simple BGP-based Mobile Routing System for the = Aeronautical Telecommunications Network Author : Fred L. Templin Filename : draft-templin-atn-bgp-01.txt Pages : 14 Date : 2017-03-29 Abstract: The International Civil Aviation Organization (ICAO) is investigating mobile routing solutions for a worldwide Aeronautical Telecommunications Network with Internet Protocol Services (ATN/IPS). The ATN/IPS will eventually replace existing communication services with an IPv6-based service supporting pervasive Air Traffic Management (ATM) for Air Traffic Controllers (ATC), Airline Operations Controllers (AOC), and all commercial aircraft worldwide. This informational document describes a simple mobile routing service based on mature industry standards to address the ATN/IPS requirements. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-templin-atn-bgp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-templin-atn-bgp-01 https://datatracker.ietf.org/doc/html/draft-templin-atn-bgp-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-templin-atn-bgp-01 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Fri Mar 31 07:34:17 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D389212422F for ; Fri, 31 Mar 2017 07:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oo0vnDF_EU5W for ; Fri, 31 Mar 2017 07:34:13 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::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 2308612995D for ; Fri, 31 Mar 2017 07:34:10 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id l7so40668876ioe.3 for ; Fri, 31 Mar 2017 07:34:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=RZ42fEDM0/7cRnRryPg+m5uXfbXuS1zT76ULPWfZXW0=; b=Q54K0BiMCIZ11w8deC0BF6DMRcBwc3FX7qqaLy7R/PGZatmA+jE6dDagXs4lKiiRmE SI/UiNO68YmRkjpoIJj2r6DHcg+uQB1isGhQHfquSmgTrZEV+2JixpA1Tr15rXgNt2Rm WonPzRYnjuuX4HMDGybLK3b0f27rZ1xc4UDq8EztKTE7cdo2rNcGhO2UeisFXrPUkfDc WBzHUvd9tjfaX2LMA/d7WmF1H7+SeWVjx4TbkaqjT2p3Stq9isFmz16snKMjF/P0l+3l lE04ll09IRqarCyg1T5+y6EbtbtzpQXfwlOa/ucPi39Kke5XBj6rvW5VT8XMnpVvt+M/ QbuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=RZ42fEDM0/7cRnRryPg+m5uXfbXuS1zT76ULPWfZXW0=; b=Bh6+V+p1dJkRL7CgWQbkKcatku2Rwb9nRsTrvGT6X13pV30/VDMn1KtQ9vN5ZHwWVv 2VfgLDHjwJIUsWPMPze68LZM5sznuIFoNzUdh7tYisy4UErG52CdZ5CFyfQzHGM2UzHY Ciql4QzjRBf4c9YtxmhGrrAY5ufYMAQE2DryXTKYcAdTG5SyI3kcHDWsGp0dipzqUU+f 2BKWE+f+bx/P8jKcpkPoXqlQHoV5XokMuK+nQ9i8Gyp4ZzTRvaLmuyRnUQw/+ma2qR7d G73mO3Hi/zkhirN6BuRF5a8T59AFtqdvgxNBryoMrC9KaQ+CiAh1kqyVexMCHwaXxBBs swfQ== X-Gm-Message-State: AFeK/H0RA5hjaWEo4xftBmPRA/P9GMNrRkbWNHHZhrbSTcvEnOieXMJ8NnGT/n2UacRhUrsE9U8qLHLaHoHqhg== X-Received: by 10.107.10.21 with SMTP id u21mr3705260ioi.139.1490970849427; Fri, 31 Mar 2017 07:34:09 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.79.90.71 with HTTP; Fri, 31 Mar 2017 07:34:08 -0700 (PDT) Received: by 10.79.90.71 with HTTP; Fri, 31 Mar 2017 07:34:08 -0700 (PDT) In-Reply-To: References: From: Robert Raszuk Date: Fri, 31 Mar 2017 09:34:08 -0500 X-Google-Sender-Auth: 1UkltXUluk5wsZH8-G80DGpz3Tw Message-ID: To: Jeffrey Haas Cc: idr wg Content-Type: multipart/alternative; boundary=001a113ed766da7e15054c07b39c Archived-At: Subject: [Idr] RS BFD draft X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 14:34:15 -0000 --001a113ed766da7e15054c07b39c Content-Type: text/plain; charset=UTF-8 Hi Jeff, To your point of assymetry ... If the assymetry happens between clients placed in different rib groups of the given RS to corellate it is really ugly and breaks all today's code running as BGP route servers in the field. Besides for say UDP streaming unidirectional connectivity is not that bad to withdraw reachability just because symmetry is not there. Last most IX clients may have other connectivty outside of IX fabric in one or both directions so even TCP would work. Bottom line I agree on the need to document as BCP NH tracking part of the draft between IX clients, but new SAFI seems to me not to be a best idea. Best, R. PS. If client does not support add-path it can use different sessions as described by RFC6774. --001a113ed766da7e15054c07b39c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Hi Jeff,

    To your point of assymetry ...

    If the assymetry happens between clients placed in different rib groups= of the given RS to corellate it is really ugly and breaks all today's = code running as BGP route servers in the field.

    =
    Besides for say UDP streaming unidirectional connec= tivity is not that bad to withdraw reachability just because symmetry is no= t there.

    Last most IX cl= ients may have other connectivty outside of IX fabric in one or both direct= ions so even TCP would work.

    Bottom line I agree on the need to document as BCP NH tracking part of= the draft between IX clients, but new SAFI seems to me not to be a best id= ea.

    Best,
    R.

    PS. If clie= nt does not support add-path it can use different sessions as described by = RFC6774.
    --001a113ed766da7e15054c07b39c-- From nobody Fri Mar 31 08:11:15 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D28B12940D for ; Fri, 31 Mar 2017 08:11:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I6_sb-W_Hp64 for ; Fri, 31 Mar 2017 08:11:11 -0700 (PDT) Received: from owl2.lab.dtag.de (Owl2.lab.DTAG.DE [194.25.1.238]) by ietfa.amsl.com (Postfix) with ESMTP id B8EE4129412 for ; Fri, 31 Mar 2017 08:11:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by owl2.lab.dtag.de (Postfix) with ESMTP id C5C2DC44F8; Fri, 31 Mar 2017 17:11:06 +0200 (CEST) Received: from owl2.lab.dtag.de ([127.0.0.1]) by localhost (owl2.lab.dtag.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9E0B2xOjKUcg; Fri, 31 Mar 2017 17:11:06 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by owl2.lab.dtag.de (Postfix) with ESMTP id 7A239C8CF0; Fri, 31 Mar 2017 17:11:06 +0200 (CEST) Received: from dhcp-8525.meeting.ietf.org (dhcp-8525.meeting.ietf.org [31.133.133.37]) by owl2.lab.dtag.de (Postfix) with ESMTPSA id E088DC44F8; Fri, 31 Mar 2017 17:11:05 +0200 (CEST) To: Susan Hares , 'idr wg' References: <035901d2a263$a204a0c0$e60de240$@ndzh.com> From: Martin Horneffer Message-ID: <4c21f820-7d3e-bd73-cf95-9cd2cfeb7753@nic.dtag.de> Date: Fri, 31 Mar 2017 10:11:04 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <035901d2a263$a204a0c0$e60de240$@ndzh.com> Content-Type: multipart/alternative; boundary="------------33A030DB630666D6F15E86E5" Archived-At: Subject: Re: [Idr] 2 Week WG LC for draft-ietf-idr-bgp-prefix-sid-04.txt - 3/6 to 3/20/2017 - extending to 3/31 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 15:11:13 -0000 This is a multi-part message in MIME format. --------------33A030DB630666D6F15E86E5 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Support. Martin Am 21.03.17 um 11:53 schrieb Susan Hares: > > IDR WG: > > Perhaps the WG LC came at a bad time since have received only 1 > response. We will length the call to 3/31. Unless with have > substantial input, this WG LC will not indicate consensus. > > Sue Hares > --------------33A030DB630666D6F15E86E5 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Support.

    Martin

    Am 21.03.17 um 11:53 schrieb Susan Hares:

    IDR WG:

     

    Perhaps the WG LC came at a bad time since have received only 1 response.  We will length the call to 3/31.  Unless with have substantial input, this WG LC will not indicate consensus.

     

    Sue Hares


    --------------33A030DB630666D6F15E86E5-- From nobody Fri Mar 31 09:44:29 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8FA51294BF for ; Fri, 31 Mar 2017 09:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 46a-A6teLDQT for ; Fri, 31 Mar 2017 09:44:25 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB0C0126DD9 for ; Fri, 31 Mar 2017 09:44:24 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id v2VGiM98009225; Fri, 31 Mar 2017 17:44:22 +0100 Received: from 950129200 ([104.129.194.122]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id v2VGiJhr009211 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 Mar 2017 17:44:21 +0100 Reply-To: From: "Adrian Farrel" To: "'Susan Hares'" , "'idr wg'" References: <006201d2aa12$153b0b50$3fb121f0$@ndzh.com> In-Reply-To: <006201d2aa12$153b0b50$3fb121f0$@ndzh.com> Date: Fri, 31 Mar 2017 17:44:20 +0100 Message-ID: <009401d2aa3e$0d1b8f90$2752aeb0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0095_01D2AA46.6EE1A540" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLXG/uMjVY5UIZSh4KogBbjQrss35+mQ9EQ Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22976.006 X-TM-AS-Result: No--15.131-10.0-31-10 X-imss-scan-details: No--15.131-10.0-31-10 X-TMASE-MatchedRID: xQXWigFFh8JbJCKOm3VRCWCD5SM8YvVFwqKBAza4rVv4fnMMOzRLavhQ 2SJXp3riWNPIxk1QrbTvVbHa5Rs8t0OvwxWboMrdMDg31Je5iSn+GQFLLcthDar+vu6NNM2HixY J8/oaa/l1tKCSzroCgY9URkDgdlb5/RmmEswf7IeiXe5nNnUYt6BKM62rmx9p8eoBfgDeEI7gXu UEZiH4rz8G3G/wjVDpcLw8nYQVLsggFyxci4S+VuRnWbJNcqgXKqHlxTJ7eJUibp8py4XIryhHQ rcMnybC1lfDCm9+EZUWVP8qCAvKPSVbKC+1NyXA4pinC0b7AdVGrs1oWaIIgM5B/9LVe+0QGbbQ dh/kTL8lr4UAbUFME7qQyAveNtg60zEP/d7xPF1G2qlFbyxbIvvrzSSnpHFkfcUBSI0HztKGAoX hhbsbIC95uXownWhRnQrZDK7DrTqZEoWHC6Rh/WTNuWQFsA2GYBBGfcv6WOGNIndKSIasU9eS5V WUkyw9nHoiWJ/w7MZv/kcFnp29GMogYxpm9PTbQiO6TS4ko33kakAMW1g/fuLzNWBegCW26goQO pUkSb60P2qkGU0XyrhRbCW0NeMw2bNx1HEv7HB5ILrkKK3IDMCshsklRzu575BG3d9kVbrX8gCw dB+/6X0yu7tYn9laftwZ3X11IV0= Archived-At: Subject: Re: [Idr] Zombie - Draft-ietf-idr-operational-messages X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 16:44:28 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0095_01D2AA46.6EE1A540 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Given the proximity of tomorrow, I was looking for "Surviving the Zombie Apocalypse Using BGP Flowspec". From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: 31 March 2017 12:30 To: 'idr wg' Subject: [Idr] Zombie - Draft-ietf-idr-operational-messages d raft-ietf-idr-operational-message has been deprecated. Sue Hares ------=_NextPart_000_0095_01D2AA46.6EE1A540 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

    Given the proximity of = tomorrow, I was looking for "Surviving the Zombie Apocalypse Using = BGP Flowspec".

     

    From: Idr = [mailto:idr-bounces@ietf.org] On Behalf Of Susan = Hares
    Sent: 31 March 2017 12:30
    To: 'idr = wg'
    Subject: [Idr] Zombie - = Draft-ietf-idr-operational-messages

     

    draft-ietf-idr-operational-messag= e   has been deprecated.

     

     

    Sue Hares =

    ------=_NextPart_000_0095_01D2AA46.6EE1A540-- From nobody Fri Mar 31 11:12:15 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD31412953C for ; Fri, 31 Mar 2017 11:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.947 X-Spam-Level: X-Spam-Status: No, score=0.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BIqGR10w0FCl for ; Fri, 31 Mar 2017 11:12:12 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 E929D1200C5 for ; Fri, 31 Mar 2017 11:12:11 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=31.133.128.130; From: "Susan Hares" To: , "'idr wg'" References: <006201d2aa12$153b0b50$3fb121f0$@ndzh.com> <009401d2aa3e$0d1b8f90$2752aeb0$@olddog.co.uk> In-Reply-To: <009401d2aa3e$0d1b8f90$2752aeb0$@olddog.co.uk> Date: Fri, 31 Mar 2017 13:50:55 -0400 Message-ID: <007401d2aa47$58a51720$09ef4560$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0075_01D2AA25.D1937720" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLXG/uMjVY5UIZSh4KogBbjQrss3wEzujpvn5y4wwA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] Zombie - Draft-ietf-idr-operational-messages X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 18:12:14 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0075_01D2AA25.D1937720 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Was that a WG Adoption call request (smile)? Sue From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: Friday, March 31, 2017 12:44 PM To: 'Susan Hares'; 'idr wg' Subject: Re: [Idr] Zombie - Draft-ietf-idr-operational-messages Given the proximity of tomorrow, I was looking for "Surviving the Zombie Apocalypse Using BGP Flowspec". From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: 31 March 2017 12:30 To: 'idr wg' Subject: [Idr] Zombie - Draft-ietf-idr-operational-messages d raft-ietf-idr-operational-message has been deprecated. Sue Hares ------=_NextPart_000_0075_01D2AA25.D1937720 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Was that a WG Adoption call request = (smile)?

    Sue

     

    From:= = Idr [mailto:idr-bounces@ietf.org] On Behalf Of Adrian = Farrel
    Sent: Friday, March 31, 2017 12:44 PM
    To: = 'Susan Hares'; 'idr wg'
    Subject: Re: [Idr] Zombie - = Draft-ietf-idr-operational-messages

     

    Given the proximity of tomorrow, I = was looking for "Surviving the Zombie Apocalypse Using BGP = Flowspec".

     

    From:= = Idr [mailto:idr-bounces@ietf.org] = On Behalf Of Susan Hares
    Sent: 31 March 2017 = 12:30
    To: 'idr wg'
    Subject: [Idr] Zombie - = Draft-ietf-idr-operational-messages

     

    draft-ietf-idr-operational-messag= e   has been deprecated.

     

     

    Sue Hares =

    ------=_NextPart_000_0075_01D2AA25.D1937720-- From nobody Fri Mar 31 15:24:56 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA03D126DCA for ; Fri, 31 Mar 2017 15:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.947 X-Spam-Level: X-Spam-Status: No, score=0.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eQ183qfuzAdr for ; Fri, 31 Mar 2017 15:24:54 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 C525A1201F2 for ; Fri, 31 Mar 2017 15:24:53 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.221.149.50; From: "Susan Hares" To: "'idr wg'" References: In-Reply-To: Date: Fri, 31 Mar 2017 18:20:05 -0400 Message-ID: <003a01d2aa6c$f35e9e60$da1bdb20$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003B_01D2AA4B.6C4F6F60" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI3Y5KGMCFQeepPu+lvSWqLTw7uv6DmEqow Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [Idr] FW: IPR call for draft-grendler-idr-bgplu-epe X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 22:24:56 -0000 This is a multipart message in MIME format. ------=_NextPart_000_003B_01D2AA4B.6C4F6F60 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Forwarding the IPR statement for Luyuan.=20 =20 Sue =20 From: Fang, Luyuan [mailto:lufang@ebay.com]=20 Sent: Friday, March 31, 2017 3:07 PM To: Susan Hares Cc: draft-gredler-idr-bgplu-epe@ietf.org; idr-chairs@ietf.org; 'Dongjie = (Jimmy)' Subject: IPR call for draft-grendler-idr-bgplu-epe =20 I am not aware of any IPR. Luyuan =20 =20 From: Susan Hares Date: Thursday, March 16, 2017 at 11:43 AM To: 'idr wg' Cc: "draft-gredler-idr-bgplu-epe@ietf.org" = , "idr-chairs@ietf.org" = , "'Dongjie (Jimmy)'" Subject: IPR call for draft-grendler-idr-bgplu-epe Resent-From: Resent-To: , , = , , , = Resent-Date: Thursday, March 16, 2017 at 11:47 AM =20 This is an IPR call prior to a call for adoption for draft-gredler-idr-bgplu-epe ( Egress Peer Engineering using BGP-LU) = which can be found at https://datatracker.ietf.org/doc/draft-gredler-idr-bgplu-epe/ =20 Will the authors please indicate whether they know of any IPR on this = draft? =20 Sue Hares=20 =20 =20 ------=_NextPart_000_003B_01D2AA4B.6C4F6F60 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

    Forwarding the IPR statement = for Luyuan.

     

    Sue

     

    From:= = Fang, Luyuan [mailto:lufang@ebay.com]
    Sent: Friday, March 31, = 2017 3:07 PM
    To: Susan Hares
    Cc: = draft-gredler-idr-bgplu-epe@ietf.org; idr-chairs@ietf.org; 'Dongjie = (Jimmy)'
    Subject: IPR call for = draft-grendler-idr-bgplu-epe

     

    I am not aware of any = IPR.

    Luyuan

     

     

    From: Susan Hares = <shares@ndzh.com>

    Date: Thursday, March 16, 2017 at 11:43 = AM

    To: 'idr wg' = <idr@ietf.org>

    Cc: = "draft-gredler-idr-bgplu-epe@ietf.org" = <draft-gredler-idr-bgplu-epe@ietf.org>, = "idr-chairs@ietf.org" <idr-chairs@ietf.org>, = "'Dongjie (Jimmy)'" = <jie.dong@huawei.com>

    Subject: IPR call for = draft-grendler-idr-bgplu-epe

    Resent-From: = <alias-bounces@ietf.org>

    Resent-To: = <kaliraj@juniper.net>, <csekar@juniper.net>, = <balajir@juniper.net>, <lufang@microsoft.com>, = <hannes@rtbrick.com>, = <earies@juniper.net>

    Resent-Date: = Thursday, March 16, 2017 at 11:47 AM

     

    This is an IPR call = prior to a call for adoption for

    draft-gredler-idr-bgplu-epe  ( Egress = Peer Engineering using BGP-LU) which

    can be found = at

    ht= tps://datatracker.ietf.org/doc/draft-gredler-idr-bgplu-epe/

     

    Will the authors = please indicate whether they know of any IPR on this = draft?

     

    Sue Hares =

     

     

    ------=_NextPart_000_003B_01D2AA4B.6C4F6F60-- From nobody Fri Mar 31 19:01:54 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A97A9126C0F for ; Fri, 31 Mar 2017 19:01:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.419 X-Spam-Level: X-Spam-Status: No, score=-1.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LnJQnFaGUt6B for ; Fri, 31 Mar 2017 19:01:50 -0700 (PDT) Received: from mail-wm0-f49.google.com (mail-wm0-f49.google.com [74.125.82.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7156E127058 for ; Fri, 31 Mar 2017 19:01:50 -0700 (PDT) Received: by mail-wm0-f49.google.com with SMTP id t189so11154453wmt.1 for ; Fri, 31 Mar 2017 19:01:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-disposition:user-agent; bh=Ro25qi5UrcrYiWhT5u73dvhu7vsllQ5KQtVTYQWOAtU=; b=BZoE1BOilRu9P+lfTvC5g7SlGH7gwc3PMbN2442YACkcFWB6kvomwdbXTd82sTaqRC 1k9q0BZicRwyHIYVPrgu1vY6/PX+ryTzUP4pha2Cd6Q+bnds+NV8Eqejzeme9T9jQxAO LpEvr5gPF/k3mpdb2vx6l0Drvr7MeR99WCgzaoftR8aC76JnPK6nEP27c+HX1O8NeMSM KoddMg9QvAkL1lAkICASvLYo7rljJ/pe0ZzIZ0V2PFFuWBSvriv1BqnrgHo64LWavbI4 Fx2MN9vtBdF26hoiS8t2lZ4TXdAOc9ySguYM9lKqLagpEnzApe49+2OcbQQ3Hwnlu2OH Ur1g== X-Gm-Message-State: AFeK/H2pGNX1S1AjXTyWTvZn6+qSqV0Bh/ZD6ayoCTXZ1OG8ekEX1S2ROe0X/0cEMDhsiQ== X-Received: by 10.28.38.133 with SMTP id m127mr459128wmm.41.1491012108676; Fri, 31 Mar 2017 19:01:48 -0700 (PDT) Received: from localhost ([88.128.80.68]) by smtp.gmail.com with ESMTPSA id g141sm4913952wmd.10.2017.03.31.19.01.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 31 Mar 2017 19:01:47 -0700 (PDT) Date: Sat, 1 Apr 2017 03:01:36 +0100 From: Job Snijders To: idr@ietf.org Message-ID: <20170401020136.ftbjliohoaznzqyx@dhcp-86cf.meeting.ietf.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett User-Agent: NeoMutt/20170306 (1.8.0) Archived-At: Subject: [Idr] dear diary: well-known community vs new path attribute X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Apr 2017 02:01:53 -0000 Dear colleagues, In today's IDR session (thank you for the orderly meeting, chairs & secretary!) the topic of 'well-known BGP community vs BGP Path attribute' came up, in context of having a marker to signify or signal a route's audience [Sriram] https://datatracker.ietf.org/meeting/98/agenda/idr/ I've come to the conclusion that we have no choice other then to use a well-known communities for boolean functions like the ones currently on the table. There are a number of significant advantages to using communities, that in my opinion outweigh the perceived benefit of introducing a new path attribute. This is asserted from a deployment process and adoption rate perspective. Throughout this email I'll refer to the _function_ of the path attribute/community as "feature X". Most reasons relate to "accelerated" deployment rates. With "accelerated" I'm referring to a 2-3 year timescale rather then 8+ years. I'll share my analysis below. We have to assume that there are many networks which might (from this moment on) _never_ upgrade their software to the required newer software to support feature X natively. There are a number of reasons why a network might never receive the necessary software upgrades: the network choose to continue using devices well after the End-of-Sale/Support/Life date for economic reasons. Some networks use hardware longer then the vendor intended, sometimes because the operator disagreed with the vendor's view on longevity. Like some of you, I've travelled to regions of the world where a good router, is a router without bullet holes in it, in such cases you'll have to make things work with whatever was loaded on there. In other cases, the vendor simply has gone bankrupt, and the network has to make do with what is available on their sparing shelves until the hardware is fully amortised. With the above in mind, I'd argue that for many BGP features it is entirely acceptable to state "upgrade your software and receive awesome feature Y!". But in the instance of routing security, one might need to salvage as much as one can in existing deployments, for altruistic reasons. I think it is fair to assume that in all cases, the BGP speakers will support RFC 1997 BGP Communities. We can also assume that the device supports neighbor-specific routing policy options to (at the very least) match, and subsequently deny or permit based on the RFC 1997 community. Another interesting (perhaps underappreciated) angle is that there are both open source and commercial ancillary configuration management systems on the market, which will happily manage devices which were not upgraded to support Feature X natively. When vendor B doesn't want to implement native support for Feature X, perhaps the ancillary third market will support Feature X on vendor B. A number considerations apply for well-known BGP communities in context of route leak prevention: - on day 0, there will be no routes tagged with the well-known community, likewise on day 365, there will be a small number of routes tagged with the well-known community. - throughout the lifetime of feature X, the tagged routs are likely to be outnumbered by the untagged routes, in all contexts. - ideally feature X can be deployed incrementally within an AS, so it should _add_ an extra layer of protection, rather then replace or hotswap an existing protection function. - RFC 1997 communities are transitive, so Feature X must at the very least not be significantly hindered by the transivity, and in an ideal case actually benefit from the transivity property. Enforcing non-transivity through a RFC 2119-style "When received on EBGP, MUST delete" is also acceptable. Operators can manually emulate the non-transivity, and wait for software upgrades to do it for them. - the presence of a well-known community on one route, cannot, and should not be superimposed to other routes received through the same BGP session. In a more general sense, a well-known community on one route cannot act as a semaphore for the entire session. I am not aware of any implementations which allow to match/act on one route and perform congruent manipulation of properties on a different route. - When the well-known community for Feature X is present (aka 'true'), we can assume feature X for the route was enabled intentionally, however, in the case where it is absent, we're dealing with either an 'unknown' or 'false'. The deny/accept logic we expect to be present either through manual manipulation or through We also might be able to assume that networks looking to implement Feature X, will do so out of their own volition, sufficiently motivated to do so correctly. (Even though they are implementing the feature manually!) Likewise, there will be a significant number of networks which will not hear about Feature X for the foreseeable future, and only receive the feature through software upgrades. In other words: network operators whom are ignorant of Feature X until they read Release notes, could be considered harmless. Furthermore, networks which are well intended, might be in a position to recitfy erroneous use of the well-known community for feature X when received across EBGP sessions. >From my own deployment perspective, when using a BGP Community, (disclaimer: merely stating options!) I can start deploying _right_now_, _network-wide_ (meanwhile waiting for software upgrades to slowly start catching up and replace my manual implementation). More importantly, I can deploy in a heterogeneous environment where the timelines for policy deployment and software deployment are not aligned, or with parts of the network not even expected to receive the required software upgrade for native support. We haven't seen a standards track well-known community in a while, but I'd be supportive of a well-known community RFC which demands rigorous discipline related to the transivity, semantics, and would provide configuration examples for those who cannot (yet) use Feature X natively, with an agreed upon upgrade path to native support for feature X. As long as the benefits of using Feature X are 'egocentric' (aka "deploying this concept helps me, and I don't need others to cooperate with me"), and misuse of Feature X through the well-known community is either merely self-inflicted pain, or harmless, we'll be fine. Since Feature X is positioned in context of routing security, something we'd probably like to see broad adoption on, I'd argue that the lowest common denominator should be used: well-known BGP communities. Kind regards, Job From nobody Fri Mar 31 19:17:07 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F08BA127A91 for ; Fri, 31 Mar 2017 19:17:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dMBQsu6o6UIJ for ; Fri, 31 Mar 2017 19:17:03 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::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 6A9BE1200A0 for ; Fri, 31 Mar 2017 19:17:03 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id b140so50009113iof.1 for ; Fri, 31 Mar 2017 19:17:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=vR63Mchdd2cknvqImwu1OaQq4bwP65S1WdhoLGD1d/8=; b=NdzGJDxweWsfACtAHVXQGsZoZegRyxEvaYg7+JWk65kSdR3tEuvRLfWQbqUp4mx8Hx wZVBDveiz4qMwN1nCMJ6XqhPxJfw5bBKk22cD7+YV4vS4BOl4aPAIMQw6dLqWJCC7a3N bOMpwPdaOrDWuE+G/+LvvVSrbWQk2ta9VHAj+0RduxiIM8clkEopCBFeslsQdoMMcUoK GoIcZRIFLZf2dPHKkVX5WBsJTQhQVsCIr3cQ1dEl7vFkvAhzTjP3Y4J4L6J9HtEhA3d4 lFkAvxG0aFKqMKdDVsEOC+3HbKrGx8TsgVHNQtfAz0QmXQXDzVSUaLsxDj8MASIC86Mu TgCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=vR63Mchdd2cknvqImwu1OaQq4bwP65S1WdhoLGD1d/8=; b=hpYU3h7DXt0ETip7lctiZ+3mjnCH9cJ05N3WCG0ulscaesLXvs7hx7WWTedksglZGd 4ePsOW5oKUnfoY9UyUy0niNRL4xwTq2BDEWZ6QJBBoFGiDjbBOk5CESyomJuY2ZOEvvY ycjLRo6Y8D9z4NZrUegfVnHrmRiOOKCICaC6lhQM+pQEnJbeS0NT47K36ZPYxS48BqP2 VLaXaXuhb7UZqIxXAaGSeFwkOz5QW1bozW4stPyqpufIfdb8kGHZ12SKUzn7oJtieGwm 0G+nf0dLTsTvIdcbFcQyWExmPJYhqYvQDzmgyMnFZYoykpvbVgDyHF0yYEeL6gm2bEIq tc6Q== X-Gm-Message-State: AFeK/H0u9JE3EYJOPT08R2YHJcPGKkwLufzh43WI2s1Ge1bjEWr5GpI0beWJZx3Vh6qbYINbcpcHTIv3GSL0/A== X-Received: by 10.107.7.29 with SMTP id 29mr6940967ioh.57.1491013022590; Fri, 31 Mar 2017 19:17:02 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.79.90.71 with HTTP; Fri, 31 Mar 2017 19:17:01 -0700 (PDT) Received: by 10.79.90.71 with HTTP; Fri, 31 Mar 2017 19:17:01 -0700 (PDT) In-Reply-To: <20170401020136.ftbjliohoaznzqyx@dhcp-86cf.meeting.ietf.org> References: <20170401020136.ftbjliohoaznzqyx@dhcp-86cf.meeting.ietf.org> From: Robert Raszuk Date: Fri, 31 Mar 2017 21:17:01 -0500 X-Google-Sender-Auth: V8Sk52NzVNoztkOv56rp2owi-5k Message-ID: To: Job Snijders Cc: idr wg Content-Type: multipart/alternative; boundary=001a113ea6f09130a4054c118557 Archived-At: Subject: Re: [Idr] dear diary: well-known community vs new path attribute X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Apr 2017 02:17:06 -0000 --001a113ea6f09130a4054c118557 Content-Type: text/plain; charset=UTF-8 Hello Job, If we start to make choice between community vs attribute for each "boolean function" based on the assumption that some folks will "_*never_ upgrade their software*" then IDR job becomes really simple. IDR should just manage registry of communities in 80% of its proposals and we are done. So while in Sriram's proposal for intra-as (if at all needed) community will be a better choice IMO such call should be made each time on a case by case basis depending on the extension being discussed rather then any generic overrule. Cheers, Robert. On Mar 31, 2017 21:01, "Job Snijders" wrote: Dear colleagues, In today's IDR session (thank you for the orderly meeting, chairs & secretary!) the topic of 'well-known BGP community vs BGP Path attribute' came up, in context of having a marker to signify or signal a route's audience [Sriram] https://datatracker.ietf.org/ meeting/98/agenda/idr/ I've come to the conclusion that we have no choice other then to use a well-known communities for boolean functions like the ones currently on the table. There are a number of significant advantages to using communities, that in my opinion outweigh the perceived benefit of introducing a new path attribute. This is asserted from a deployment process and adoption rate perspective. Throughout this email I'll refer to the _function_ of the path attribute/community as "feature X". Most reasons relate to "accelerated" deployment rates. With "accelerated" I'm referring to a 2-3 year timescale rather then 8+ years. I'll share my analysis below. We have to assume that there are many networks which might (from this moment on) _never_ upgrade their software to the required newer software to support feature X natively. There are a number of reasons why a network might never receive the necessary software upgrades: the network choose to continue using devices well after the End-of-Sale/Support/Life date for economic reasons. Some networks use hardware longer then the vendor intended, sometimes because the operator disagreed with the vendor's view on longevity. Like some of you, I've travelled to regions of the world where a good router, is a router without bullet holes in it, in such cases you'll have to make things work with whatever was loaded on there. In other cases, the vendor simply has gone bankrupt, and the network has to make do with what is available on their sparing shelves until the hardware is fully amortised. With the above in mind, I'd argue that for many BGP features it is entirely acceptable to state "upgrade your software and receive awesome feature Y!". But in the instance of routing security, one might need to salvage as much as one can in existing deployments, for altruistic reasons. I think it is fair to assume that in all cases, the BGP speakers will support RFC 1997 BGP Communities. We can also assume that the device supports neighbor-specific routing policy options to (at the very least) match, and subsequently deny or permit based on the RFC 1997 community. Another interesting (perhaps underappreciated) angle is that there are both open source and commercial ancillary configuration management systems on the market, which will happily manage devices which were not upgraded to support Feature X natively. When vendor B doesn't want to implement native support for Feature X, perhaps the ancillary third market will support Feature X on vendor B. A number considerations apply for well-known BGP communities in context of route leak prevention: - on day 0, there will be no routes tagged with the well-known community, likewise on day 365, there will be a small number of routes tagged with the well-known community. - throughout the lifetime of feature X, the tagged routs are likely to be outnumbered by the untagged routes, in all contexts. - ideally feature X can be deployed incrementally within an AS, so it should _add_ an extra layer of protection, rather then replace or hotswap an existing protection function. - RFC 1997 communities are transitive, so Feature X must at the very least not be significantly hindered by the transivity, and in an ideal case actually benefit from the transivity property. Enforcing non-transivity through a RFC 2119-style "When received on EBGP, MUST delete" is also acceptable. Operators can manually emulate the non-transivity, and wait for software upgrades to do it for them. - the presence of a well-known community on one route, cannot, and should not be superimposed to other routes received through the same BGP session. In a more general sense, a well-known community on one route cannot act as a semaphore for the entire session. I am not aware of any implementations which allow to match/act on one route and perform congruent manipulation of properties on a different route. - When the well-known community for Feature X is present (aka 'true'), we can assume feature X for the route was enabled intentionally, however, in the case where it is absent, we're dealing with either an 'unknown' or 'false'. The deny/accept logic we expect to be present either through manual manipulation or through We also might be able to assume that networks looking to implement Feature X, will do so out of their own volition, sufficiently motivated to do so correctly. (Even though they are implementing the feature manually!) Likewise, there will be a significant number of networks which will not hear about Feature X for the foreseeable future, and only receive the feature through software upgrades. In other words: network operators whom are ignorant of Feature X until they read Release notes, could be considered harmless. Furthermore, networks which are well intended, might be in a position to recitfy erroneous use of the well-known community for feature X when received across EBGP sessions. >From my own deployment perspective, when using a BGP Community, (disclaimer: merely stating options!) I can start deploying _right_now_, _network-wide_ (meanwhile waiting for software upgrades to slowly start catching up and replace my manual implementation). More importantly, I can deploy in a heterogeneous environment where the timelines for policy deployment and software deployment are not aligned, or with parts of the network not even expected to receive the required software upgrade for native support. We haven't seen a standards track well-known community in a while, but I'd be supportive of a well-known community RFC which demands rigorous discipline related to the transivity, semantics, and would provide configuration examples for those who cannot (yet) use Feature X natively, with an agreed upon upgrade path to native support for feature X. As long as the benefits of using Feature X are 'egocentric' (aka "deploying this concept helps me, and I don't need others to cooperate with me"), and misuse of Feature X through the well-known community is either merely self-inflicted pain, or harmless, we'll be fine. Since Feature X is positioned in context of routing security, something we'd probably like to see broad adoption on, I'd argue that the lowest common denominator should be used: well-known BGP communities. Kind regards, Job _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr --001a113ea6f09130a4054c118557 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Hello Job,

    I= f we start to make choice between community vs attribute for each "boo= lean function" based on the assumption that some folks will "_never_ upgrade th= eir software" then IDR job becomes really simple.=C2=A0

    IDR should just manage regi= stry of communities in 80% of its proposals and we are done.

    So while in Sriram's proposal for= intra-as (if at all needed) community will be a better choice IMO such cal= l should be made each time on a case by case basis depending on the extensi= on being discussed rather then any generic overrule.

    Cheers,
    Robert.

    On Mar 31, 2017 21:01, "Job Snijders" <job@ntt.net> wrote:
    Dear colleagues,

    In today's IDR session (thank you for the orderly meeting, chairs &=
    secretary!) the topic of 'well-known BGP community vs BGP Path
    attribute' came up, in context of having a marker to signify or signal = a
    route's audience [Sriram] https://datatracker= .ietf.org/meeting/98/agenda/idr/

    I've come to the conclusion that we have no choice other then to use a<= br> well-known communities for boolean functions like the ones currently on
    the table.

    There are a number of significant advantages to using communities, that
    in my opinion outweigh the perceived benefit of introducing a new path
    attribute. This is asserted from a deployment process and adoption rate
    perspective. Throughout this email I'll refer to the _function_ of the<= br> path attribute/community as "feature X". Most reasons relate to "accelerated" deployment rates. With "accelerated" I= 9;m referring to a
    2-3 year timescale rather then 8+ years. I'll share my analysis below.<= br>
    We have to assume that there are many networks which might (from this
    moment on) _never_ upgrade their software to the required newer software to support feature X natively. There are a number of reasons why a
    network might never receive the necessary software upgrades: the network choose to continue using devices well after the End-of-Sale/Support/Life date for economic reasons. Some networks use hardware longer then the
    vendor intended, sometimes because the operator disagreed with the
    vendor's view on longevity. Like some of you, I've travelled to reg= ions
    of the world where a good router, is a router without bullet holes in
    it, in such cases you'll have to make things work with whatever was
    loaded on there. In other cases, the vendor simply has gone bankrupt,
    and the network has to make do with what is available on their sparing
    shelves until the hardware is fully amortised.

    With the above in mind, I'd argue that for many BGP features it is
    entirely acceptable to state "upgrade your software and receive awesom= e
    feature Y!". But in the instance of routing security, one might need t= o
    salvage as much as one can in existing deployments, for altruistic
    reasons.

    I think it is fair to assume that in all cases, the BGP speakers will
    support RFC 1997 BGP Communities. We can also assume that the device
    supports neighbor-specific routing policy options to (at the very least) match, and subsequently deny or permit based on the RFC 1997 community.

    Another interesting (perhaps underappreciated) angle is that there are
    both open source and commercial ancillary configuration management
    systems on the market, which will happily manage devices which were not
    upgraded to support Feature X natively. When vendor B doesn't want to implement native support for Feature X, perhaps the ancillary third
    market will support Feature X on vendor B.

    A number considerations apply for well-known BGP communities in context
    of route leak prevention:

    - on day 0, there will be no routes tagged with the well-known
    =C2=A0 community, likewise on day 365, there will be a small number of rout= es
    =C2=A0 tagged with the well-known community.

    - throughout the lifetime of feature X, the tagged routs are likely
    =C2=A0 to be outnumbered by the untagged routes, in all contexts.

    - ideally feature X can be deployed incrementally within an AS, so it
    =C2=A0 should _add_ an extra layer of protection, rather then replace or =C2=A0 hotswap an existing protection function.

    - RFC 1997 communities are transitive, so Feature X must at the very
    =C2=A0 least not be significantly hindered by the transivity, and in an ide= al
    =C2=A0 case actually benefit from the transivity property. Enforcing
    =C2=A0 non-transivity through a RFC 2119-style "When received on EBGP,= MUST
    =C2=A0 delete" is also acceptable. Operators can manually emulate the<= br> =C2=A0 non-transivity, and wait for software upgrades to do it for them.
    - the presence of a well-known community on one route, cannot, and
    =C2=A0 should not be superimposed to other routes received through the same=
    =C2=A0 BGP session. In a more general sense, a well-known community on one<= br> =C2=A0 route cannot act as a semaphore for the entire session. I am not awa= re
    =C2=A0 of any implementations which allow to match/act on one route and
    =C2=A0 perform congruent manipulation of properties on a different route.
    - When the well-known community for Feature X is present (aka 'true'= ;),
    =C2=A0 we can assume feature X for the route was enabled intentionally,
    =C2=A0 however, in the case where it is absent, we're dealing with eith= er an
    =C2=A0 'unknown' or 'false'. The deny/accept logic we expec= t to be present
    =C2=A0 either through manual manipulation or through

    We also might be able to assume that networks looking to implement
    Feature X, will do so out of their own volition, sufficiently motivated
    to do so correctly. (Even though they are implementing the feature
    manually!) Likewise, there will be a significant number of networks
    which will not hear about Feature X for the foreseeable future, and only receive the feature through software upgrades. In other words: network
    operators whom are ignorant of Feature X until they read Release notes,
    could be considered harmless. Furthermore, networks which are well
    intended, might be in a position to recitfy erroneous use of the
    well-known community for feature X when received across EBGP sessions.

    >From my own deployment perspective, when using a BGP Community,
    (disclaimer: merely stating options!) I can start deploying _right_now_, _network-wide_ (meanwhile waiting for software upgrades to slowly start
    catching up and replace my manual implementation). More importantly, I
    can deploy in a heterogeneous environment where the timelines for policy deployment and software deployment are not aligned, or with parts of the network not even expected to receive the required software upgrade for
    native support.

    We haven't seen a standards track well-known community in a while, but<= br> I'd be supportive of a well-known community RFC which demands rigorous<= br> discipline related to the transivity, semantics, and would provide
    configuration examples for those who cannot (yet) use Feature X
    natively, with an agreed upon upgrade path to native support for
    feature X.

    As long as the benefits of using Feature X are 'egocentric' (aka "deploying this concept helps me, and I don't need others to coope= rate
    with me"), and misuse of Feature X through the well-known community is=
    either merely self-inflicted pain, or harmless, we'll be fine.

    Since Feature X is positioned in context of routing security, something
    we'd probably like to see broad adoption on, I'd argue that the low= est
    common denominator should be used: well-known BGP communities.

    Kind regards,

    Job

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

    --001a113ea6f09130a4054c118557-- From nobody Fri Mar 31 21:00:33 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EC3712709D for ; Fri, 31 Mar 2017 21:00:32 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mqy06U2XARAL for ; Fri, 31 Mar 2017 21:00:29 -0700 (PDT) Received: from mail3.mlpsca01.us.to.gin.ntt.net (mail3.mlpsca01.us.to.gin.ntt.net [IPv6:2001:418:3ff:3::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 BA377126BFD for ; Fri, 31 Mar 2017 21:00:29 -0700 (PDT) Received: by mail3.mlpsca01.us.to.gin.ntt.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1cuADF-0002KT-Iu (job@us.ntt.net) for idr@ietf.org; Sat, 01 Apr 2017 04:00:29 +0000 Received: by mail-wr0-f176.google.com with SMTP id l43so119520540wre.1 for ; Fri, 31 Mar 2017 21:00:29 -0700 (PDT) X-Gm-Message-State: AFeK/H3ItPNYXR19HrQ7/dlMjK1OvyWMrJquBR/9tYXQni+iwEECT//3W06/WQTRMAlf0GmJC35cgP+EZDUn9g== X-Received: by 10.223.148.35 with SMTP id 32mr5687247wrq.82.1491019227829; Fri, 31 Mar 2017 21:00:27 -0700 (PDT) MIME-Version: 1.0 References: <20170401020136.ftbjliohoaznzqyx@dhcp-86cf.meeting.ietf.org> In-Reply-To: From: Job Snijders Date: Sat, 01 Apr 2017 04:00:16 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Job Snijders , Robert Raszuk Cc: idr wg Content-Type: multipart/alternative; boundary=94eb2c0d21c26dac8a054c12f76b Archived-At: Subject: Re: [Idr] dear diary: well-known community vs new path attribute X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Apr 2017 04:00:32 -0000 --94eb2c0d21c26dac8a054c12f76b Content-Type: text/plain; charset=UTF-8 Hi Robert, I agree, the choice is case by case. Kind regards, Job On Fri, 31 Mar 2017 at 21:17, Robert Raszuk wrote: Hello Job, If we start to make choice between community vs attribute for each "boolean function" based on the assumption that some folks will "_*never_ upgrade their software*" then IDR job becomes really simple. IDR should just manage registry of communities in 80% of its proposals and we are done. So while in Sriram's proposal for intra-as (if at all needed) community will be a better choice IMO such call should be made each time on a case by case basis depending on the extension being discussed rather then any generic overrule. Cheers, Robert. On Mar 31, 2017 21:01, "Job Snijders" wrote: Dear colleagues, In today's IDR session (thank you for the orderly meeting, chairs & secretary!) the topic of 'well-known BGP community vs BGP Path attribute' came up, in context of having a marker to signify or signal a route's audience [Sriram] https://datatracker.ietf.org/meeting/98/agenda/idr/ I've come to the conclusion that we have no choice other then to use a well-known communities for boolean functions like the ones currently on the table. There are a number of significant advantages to using communities, that in my opinion outweigh the perceived benefit of introducing a new path attribute. This is asserted from a deployment process and adoption rate perspective. Throughout this email I'll refer to the _function_ of the path attribute/community as "feature X". Most reasons relate to "accelerated" deployment rates. With "accelerated" I'm referring to a 2-3 year timescale rather then 8+ years. I'll share my analysis below. We have to assume that there are many networks which might (from this moment on) _never_ upgrade their software to the required newer software to support feature X natively. There are a number of reasons why a network might never receive the necessary software upgrades: the network choose to continue using devices well after the End-of-Sale/Support/Life date for economic reasons. Some networks use hardware longer then the vendor intended, sometimes because the operator disagreed with the vendor's view on longevity. Like some of you, I've travelled to regions of the world where a good router, is a router without bullet holes in it, in such cases you'll have to make things work with whatever was loaded on there. In other cases, the vendor simply has gone bankrupt, and the network has to make do with what is available on their sparing shelves until the hardware is fully amortised. With the above in mind, I'd argue that for many BGP features it is entirely acceptable to state "upgrade your software and receive awesome feature Y!". But in the instance of routing security, one might need to salvage as much as one can in existing deployments, for altruistic reasons. I think it is fair to assume that in all cases, the BGP speakers will support RFC 1997 BGP Communities. We can also assume that the device supports neighbor-specific routing policy options to (at the very least) match, and subsequently deny or permit based on the RFC 1997 community. Another interesting (perhaps underappreciated) angle is that there are both open source and commercial ancillary configuration management systems on the market, which will happily manage devices which were not upgraded to support Feature X natively. When vendor B doesn't want to implement native support for Feature X, perhaps the ancillary third market will support Feature X on vendor B. A number considerations apply for well-known BGP communities in context of route leak prevention: - on day 0, there will be no routes tagged with the well-known community, likewise on day 365, there will be a small number of routes tagged with the well-known community. - throughout the lifetime of feature X, the tagged routs are likely to be outnumbered by the untagged routes, in all contexts. - ideally feature X can be deployed incrementally within an AS, so it should _add_ an extra layer of protection, rather then replace or hotswap an existing protection function. - RFC 1997 communities are transitive, so Feature X must at the very least not be significantly hindered by the transivity, and in an ideal case actually benefit from the transivity property. Enforcing non-transivity through a RFC 2119-style "When received on EBGP, MUST delete" is also acceptable. Operators can manually emulate the non-transivity, and wait for software upgrades to do it for them. - the presence of a well-known community on one route, cannot, and should not be superimposed to other routes received through the same BGP session. In a more general sense, a well-known community on one route cannot act as a semaphore for the entire session. I am not aware of any implementations which allow to match/act on one route and perform congruent manipulation of properties on a different route. - When the well-known community for Feature X is present (aka 'true'), we can assume feature X for the route was enabled intentionally, however, in the case where it is absent, we're dealing with either an 'unknown' or 'false'. The deny/accept logic we expect to be present either through manual manipulation or through We also might be able to assume that networks looking to implement Feature X, will do so out of their own volition, sufficiently motivated to do so correctly. (Even though they are implementing the feature manually!) Likewise, there will be a significant number of networks which will not hear about Feature X for the foreseeable future, and only receive the feature through software upgrades. In other words: network operators whom are ignorant of Feature X until they read Release notes, could be considered harmless. Furthermore, networks which are well intended, might be in a position to recitfy erroneous use of the well-known community for feature X when received across EBGP sessions. >From my own deployment perspective, when using a BGP Community, (disclaimer: merely stating options!) I can start deploying _right_now_, _network-wide_ (meanwhile waiting for software upgrades to slowly start catching up and replace my manual implementation). More importantly, I can deploy in a heterogeneous environment where the timelines for policy deployment and software deployment are not aligned, or with parts of the network not even expected to receive the required software upgrade for native support. We haven't seen a standards track well-known community in a while, but I'd be supportive of a well-known community RFC which demands rigorous discipline related to the transivity, semantics, and would provide configuration examples for those who cannot (yet) use Feature X natively, with an agreed upon upgrade path to native support for feature X. As long as the benefits of using Feature X are 'egocentric' (aka "deploying this concept helps me, and I don't need others to cooperate with me"), and misuse of Feature X through the well-known community is either merely self-inflicted pain, or harmless, we'll be fine. Since Feature X is positioned in context of routing security, something we'd probably like to see broad adoption on, I'd argue that the lowest common denominator should be used: well-known BGP communities. Kind regards, Job _______________________________________________ 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 --94eb2c0d21c26dac8a054c12f76b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Hi Robert,

    I agree, the choice is c= ase by case.

    Kind regards,

    Job

    On Fri, 31 Mar 2017 at 21:17, Robert Raszuk <= ;robert@raszuk.net> wrote:
    Hello Job,

    If we= start to make choice between community vs attribute for each "boolean= function" based on the assumption that some folks will "_never_ upgrade their software" then IDR = job becomes really simple.=C2=A0

    IDR should just manage registry = of communities in 80% of its proposals and we are done.

    So while = in Sriram's proposal for intra-as (if at all needed) community will be = a better choice IMO such call should be made each time on a case by case ba= sis depending on the extension being discussed rather then any generic over= rule.

    Cheers,
    Robert.

    On Mar 31, 2017 21= :01, "Job Snijders" <job@ntt.net> wrote:
    Dear c= olleagues,

    In today's IDR session (thank you for the orderly meeting, chairs &=
    secretary!) the topic of 'well-known BGP community vs BGP Path
    attribute' came up, in context of having a marker to signify or signal = a
    route's audience [Sriram] https://datatracker.ietf.org/meeting/98/agenda/idr/

    I've come to the conclusion that we have no choice other then to use a<= br class=3D"gmail_msg"> well-known communities for boolean functions like the ones currently on
    the table.

    There are a number of significant advantages to using communities, that
    in my opinion outweigh the perceived benefit of introducing a new path
    attribute. This is asserted from a deployment process and adoption rate
    perspective. Throughout this email I'll refer to the _function_ of the<= br class=3D"gmail_msg"> path attribute/community as "feature X". Most reasons relate to "accelerated" deployment rates. With "accelerated" I= 9;m referring to a
    2-3 year timescale rather then 8+ years. I'll share my analysis below.<= br class=3D"gmail_msg">
    We have to assume that there are many networks which might (from this
    moment on) _never_ upgrade their software to the required newer software to support feature X natively. There are a number of reasons why a
    network might never receive the necessary software upgrades: the network choose to continue using devices well after the End-of-Sale/Support/Life date for economic reasons. Some networks use hardware longer then the
    vendor intended, sometimes because the operator disagreed with the
    vendor's view on longevity. Like some of you, I've travelled to reg= ions
    of the world where a good router, is a router without bullet holes in
    it, in such cases you'll have to make things work with whatever was
    loaded on there. In other cases, the vendor simply has gone bankrupt,
    and the network has to make do with what is available on their sparing
    shelves until the hardware is fully amortised.

    With the above in mind, I'd argue that for many BGP features it is
    entirely acceptable to state "upgrade your software and receive awesom= e
    feature Y!". But in the instance of routing security, one might need t= o
    salvage as much as one can in existing deployments, for altruistic
    reasons.

    I think it is fair to assume that in all cases, the BGP speakers will
    support RFC 1997 BGP Communities. We can also assume that the device
    supports neighbor-specific routing policy options to (at the very least) match, and subsequently deny or permit based on the RFC 1997 community.

    Another interesting (perhaps underappreciated) angle is that there are
    both open source and commercial ancillary configuration management
    systems on the market, which will happily manage devices which were not
    upgraded to support Feature X natively. When vendor B doesn't want to implement native support for Feature X, perhaps the ancillary third
    market will support Feature X on vendor B.

    A number considerations apply for well-known BGP communities in context
    of route leak prevention:

    - on day 0, there will be no routes tagged with the well-known
    =C2=A0 community, likewise on day 365, there will be a small number of rout= es
    =C2=A0 tagged with the well-known community.

    - throughout the lifetime of feature X, the tagged routs are likely
    =C2=A0 to be outnumbered by the untagged routes, in all contexts.

    - ideally feature X can be deployed incrementally within an AS, so it
    =C2=A0 should _add_ an extra layer of protection, rather then replace or =C2=A0 hotswap an existing protection function.

    - RFC 1997 communities are transitive, so Feature X must at the very
    =C2=A0 least not be significantly hindered by the transivity, and in an ide= al
    =C2=A0 case actually benefit from the transivity property. Enforcing
    =C2=A0 non-transivity through a RFC 2119-style "When received on EBGP,= MUST
    =C2=A0 delete" is also acceptable. Operators can manually emulate the<= br class=3D"gmail_msg"> =C2=A0 non-transivity, and wait for software upgrades to do it for them.
    - the presence of a well-known community on one route, cannot, and
    =C2=A0 should not be superimposed to other routes received through the same=
    =C2=A0 BGP session. In a more general sense, a well-known community on one<= br class=3D"gmail_msg"> =C2=A0 route cannot act as a semaphore for the entire session. I am not awa= re
    =C2=A0 of any implementations which allow to match/act on one route and
    =C2=A0 perform congruent manipulation of properties on a different route.
    - When the well-known community for Feature X is present (aka 'true'= ;),
    =C2=A0 we can assume feature X for the route was enabled intentionally,
    =C2=A0 however, in the case where it is absent, we're dealing with eith= er an
    =C2=A0 'unknown' or 'false'. The deny/accept logic we expec= t to be present
    =C2=A0 either through manual manipulation or through

    We also might be able to assume that networks looking to implement
    Feature X, will do so out of their own volition, sufficiently motivated
    to do so correctly. (Even though they are implementing the feature
    manually!) Likewise, there will be a significant number of networks
    which will not hear about Feature X for the foreseeable future, and only receive the feature through software upgrades. In other words: network
    operators whom are ignorant of Feature X until they read Release notes,
    could be considered harmless. Furthermore, networks which are well
    intended, might be in a position to recitfy erroneous use of the
    well-known community for feature X when received across EBGP sessions.

    >From my own deployment perspective, when using a BGP Community,
    (disclaimer: merely stating options!) I can start deploying _right_now_, _network-wide_ (meanwhile waiting for software upgrades to slowly start
    catching up and replace my manual implementation). More importantly, I
    can deploy in a heterogeneous environment where the timelines for policy deployment and software deployment are not aligned, or with parts of the network not even expected to receive the required software upgrade for
    native support.

    We haven't seen a standards track well-known community in a while, but<= br class=3D"gmail_msg"> I'd be supportive of a well-known community RFC which demands rigorous<= br class=3D"gmail_msg"> discipline related to the transivity, semantics, and would provide
    configuration examples for those who cannot (yet) use Feature X
    natively, with an agreed upon upgrade path to native support for
    feature X.

    As long as the benefits of using Feature X are 'egocentric' (aka "deploying this concept helps me, and I don't need others to coope= rate
    with me"), and misuse of Feature X through the well-known community is=
    either merely self-inflicted pain, or harmless, we'll be fine.

    Since Feature X is positioned in context of routing security, something
    we'd probably like to see broad adoption on, I'd argue that the low= est
    common denominator should be used: well-known BGP communities.

    Kind regards,

    Job

    _______________________________________________
    Idr mailing list
    Idr@i= etf.org
    https://www.ietf.org/mailman/listinfo/i= dr

    _______________________________________________
    Idr mailing list
    Idr@i= etf.org
    https://www.ietf.org/mailman/listinfo/i= dr
    --94eb2c0d21c26dac8a054c12f76b--