From nobody Tue Nov 1 00:00:20 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3340129537 for ; Tue, 1 Nov 2016 00:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.717 X-Spam-Level: X-Spam-Status: No, score=-5.717 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=-1.497, 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 eVcTj3c6Qbvt for ; Tue, 1 Nov 2016 00:00:15 -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 CEE2312942F for ; Tue, 1 Nov 2016 00:00:14 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CZL57543; Tue, 01 Nov 2016 07:00:12 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 1 Nov 2016 07:00:12 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Tue, 1 Nov 2016 15:00:04 +0800 From: Zhuangshunwan To: Susan Hares , "'IETF IDR WG'" Thread-Topic: [Idr] BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25) Thread-Index: AdIpUHjFMTMxey+uRgusubexAa1gwgKvM6Eg Date: Tue, 1 Nov 2016 07:00:03 +0000 Message-ID: <19AB2A007F56DB4E8257F949A2FB9858C87A93D0@NKGEML515-MBX.china.huawei.com> References: <01f401d22950$7f988470$7ec98d50$@ndzh.com> In-Reply-To: <01f401d22950$7f988470$7ec98d50$@ndzh.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.86.254] Content-Type: multipart/alternative; boundary="_000_19AB2A007F56DB4E8257F949A2FB9858C87A93D0NKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.58183D7D.012C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 2c441df91473e474f5de860bf8a6db6f Archived-At: Subject: Re: [Idr] BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25) 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, 01 Nov 2016 07:00:17 -0000 --_000_19AB2A007F56DB4E8257F949A2FB9858C87A93D0NKGEML515MBXchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 V0c6DQoNCldlIGhhdmUgZG9uZSBhIHRob3JvdWdoIGFuYWx5c2lzIGFib3V0IHRoZSBhdHRyaWJ1 dGUgc3F1YXR0aW5nIGlzc3VlIG9uIEh1YXdlaSByb3V0ZXIuIEF0dHJpYnV0ZSAzMCB3YXMgdXNl ZCBmb3IgYW4gaW1wbGVtZW50YXRpb24gb2YgZHJhZnQtdmFuZGV2ZWxkZS1pZHItcmVtb3RlLW5l eHQtaG9wLCBhbmQgYXR0cmlidXRlIDEyOSB3YXMgdXNlZCBmb3IgYW4gaW1wbGVtZW50YXRpb24g b2YgZHJhZnQtaWV0Zi1pZHItd2lkZS1iZ3AtY29tbXVuaXRpZXMuDQoNCkZvciBhdHRyaWJ1dGUg MzAsIHdlIGhhdmUgY3JlYXRlZCBwYXRjaGVzIGZvciB0aGlzIGlzc3VlLCBhbmQgd2lsbCBjb21w bGV0ZWx5IGZpeCB0aGUgcHJvYmxlbSBpbiB0aGUgbmV3IHJlbGVhc2UgdmVyc2lvbi4gSW4gZnV0 dXJlIHdlIHdpbGwgcmVwbGFjZSB0aGlzIGZlYXR1cmUgd2l0aCB0aGUgbWVjaGFuaXNtIGRlZmlu ZWQgaW4gZHJhZnQtaWV0Zi1pZHItdHVubmVsLWVuY2Fwcy4NCg0KRm9yIGF0dHJpYnV0ZSAxMjks IHdlIHJlcXVlc3QgZGVwcmVjYXRpb24gb2YgYXR0cmlidXRlIGNvZGUgMTI5LiBXZSB3aWxsIHdh aXQgZm9yIHRoZSBFYXJseSBBbGxvY2F0aW9uIHZhbHVlIGZvciBkcmFmdC1pZXRmLWlkci13aWRl LWJncC1jb21tdW5pdGllcywgT25jZSBpdCBpcyBhc3NpZ25lZCBieSBJQU5BLCB3ZSB3aWxsIHVw ZGF0ZSBvdXIgaW1wbGVtZW50YXRpb24gYW5kIHVzZSB0aGUgYXNzaWduZWQgY29kZSBmb3IgUE9D IHRlc3QuDQoNCkkgc2luY2VyZWx5IGFwb2xvZ2l6ZSBvbiBiZWhhbGYgb2YgSHVhd2VpIGZvciBv dXIgb3ZlcnNpZ2h0Lg0KDQpUaGFua3MsDQpTaHVud2FuDQoNCreivP7IyzogSWRyIFttYWlsdG86 aWRyLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gU3VzYW4gSGFyZXMNCreiy83KsbzkOiAyMDE2xOox MNTCMTjI1SAyMzowMQ0KytW8/sjLOiAnSUVURiBJRFIgV0cnDQqzrcvNOiAnS3Jpc3RpYW4gTGFy c3NvbicNCtb3zOI6IFtJZHJdIEJHUCBBdHRyaWJ1dGUgZm9yIExhcmdlIGNvbW11bml0aWVzIChB dHRyaWJ1dGUgMzApIHdhcyBzcXVhdHRlZCBvbiAtIExldCdzIGdldCBhIG5ldyBhdHRyaWJ1dGUg bnVtYmVyICgxIHdlZWsgV0cgY2FsbCAoMTAvMTggdG8gMTAvMjUpDQoNCldHOg0KDQpFYXJseSB0 ZXN0aW5nIG9mIHRoZSBMYXJnZSBDb21tdW5pdGllcyBkcmFmdCAoZHJhZnQtaWV0Zi1pZHItbGFy Z2UtY29tbXVuaXR5LTAzLnR4dCkgIHdpdGggYXR0cmlidXRlIHZhbHVlIG9mIDMwIGRldGVjdCB0 aGF0IHdlIGhhZCBhbiBpbXBsZW1lbnRhdGlvbiBzcXVhdHRpbmcgb24gYXR0cmlidXRlIDMwIGJ5 IGEgSHVhd2VpIHJvdXRlci4gICChsFNxdWF0dGluZ6GxIG9uIGFuIGF0dHJpYnV0ZSBpcyBhbnRp LXNvY2lhbCBiZWhhdmlvciBpbiB0aGUgSW50ZXJuZXQgaW4gYW55IHJlbGVhc2Ugb2Ygc29mdHdh cmUuDQoNClRoZSBpbmRpdmlkdWFscyB3aG8gZGlkIGluIEh1YXdlaSBoYXZlIGJlZW4gY29udGFj dGVkIGJ5IEppZSBEb25nLCBhbmQgobBhc2tlZKGxIGlmIHRoZXkgaGFkIG1hZGUgdGhpcyBtaXN0 YWtlIGluIGFueSBvdGhlciBhdHRyaWJ1dGUuICAgVGhlc2UgaW5kaXZpZHVhbHMgY29uZmVzc2Vk IHRvIEF0dHJpYnV0ZSAxMjkgKGZvciB3aWRlIGNvbW11bml0aWVzKS4gIFRoZXNlIGluZGl2aWR1 YWxzIGFwb2xvZ2l6ZSB0byB0aGUgV29ya2luZyBncm91cC4NCg0KTm93IHdoYXQgc2hhbGwgd2Ug ZG8/IFRoZSBsYXJnZSBjb21tdW5pdHkgZHJhZnQgaXMgY3JpdGljYWwgZm9yIHNldmVyYWwgbmV0 d29ya3MuIEFmdGVyIHRhbGtpbmcgd2l0aCB0aGUgZGV2ZWxvcGVycyBhbmQgb3BlcmF0b3JzLCBK b2huIGFuZCBJIHdvdWxkIGxpa2UgdG8gcmVjb21tZW5kIHdlIGRvIHRoZSBmb2xsb3dpbmc6DQoN CklEUiBzaG91bGQgcmVjb21tZW5kIHRoYXQgdGhlIGZvbGxvd2luZyBhdHRyaWJ1dGUgbnVtYmVy cyBiZSBkZXByZWNhdGVkOg0KDQpCR1AgQXR0cmlidXRlIDMwDQpCR1AgYXR0cmlidXRlIDEyOQ0K DQpJRFIgc2hvdWxkIGFzayBJQU5BIHRvIGFzc2lnbiBCR1AgTGFyZ2UgQ29tbXVuaXRpZXMgKGN1 cnJlbnRseSBBdHRyaWJ1dGUgMzApIHRvIGEgbmV3IGF0dHJpYnV0ZSBudW1iZXIuICBUaGlzIGlz IGEgMSB3ZWVrIGNhbGwgdG8gZGV0ZXJtaW5lIGlmIHRoZSBJRFIgYXBwcm92ZXMgdGhpcyBhY3Rp b24uICAgVGhpcyBjYWxsIHdpbGwgYWxsb3cgdGhlIGxhcmdlIGNvbW11bml0aWVzIGRyYWZ0IHRv IHN0aWxsIGNvbnRpbnVlIHdpdGggdGhlIDIgd2VlayBXRyBMQy4NCg0KSm9obiwgQWx2YXJvLCBh bmQgSSBoYXZlIGNoZWNrIHRoZSBlYXJseSBhbGxvY2F0aW9uIHJ1bGVzLiAgSW1wbGVtZW50YXRp b25zIHNob3VsZCBhc2sgZm9yIGVhcmx5IGFsbG9jYXRpb24gcHJpb3IgdG8gcmVsZWFzaW5nLCBh bmQgdGhleSBkbyBub3QgbmVlZCB0byBiZSBpbnRlcm9wZXJhYmlsaXR5IHRlc3RpbmcgdG8gcmVx dWVzdCB0aGUgZWFybHkgYWxsb2NhdGlvbiBmb3IgdGhlIGF0dHJpYnV0ZS4NCg0KU3VlIEhhcmVz DQoNCg0K --_000_19AB2A007F56DB4E8257F949A2FB9858C87A93D0NKGEML515MBXchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

WG:

 

We have done a thorough analysis about the attribute squatting issue o= n Huawei router. Attribute 30 was used for an implementation of draft-vande= velde-idr-remote-next-hop, and attribute 129 was used for an implementation of draft-ietf-idr-wide-bg= p-communities.

 

For attribute 30, we have created patches for this issue, and will com= pletely fix the problem in the new release version. In future we will repla= ce this feature with the mechanism defined in draft-ietf-idr-tunnel-encaps.

 

For attribute 129, we request deprecation of attribute code 129. We wi= ll wait for the Early Allocation value for draft-ietf-idr-wide-bgp-communit= ies, Once it is assigned by IANA, we will update our implementation and use the= assigned code for POC test.

 

I sincerely apologize on behalf of Huawei for our oversight.

 

Thanks,

Shunwan=

 

=B7=A2=BC=FE=C8=CB: Idr [mailto:idr-bounc= es@ietf.org] =B4=FA=B1=ED = Susan Hares
=B7=A2=CB=CD= =CA=B1=BC=E4: 2016=C4=EA10=D4=C2= 18=C8=D5 23:01
=CA=D5=BC=FE=C8=CB: 'IETF IDR WG'
=B3=AD=CB=CD: 'Kristian Larsson'
=D6=F7=CC=E2: [Idr] BGP Attribute for Large communities (Attribute 30) was squatted on = - Let's get a new attribute number (1 week WG call (10/18 to 10/25)

 

WG:

 

Early testing of the Large Comm= unities draft (draft-ietf-idr-large-community-03.txt)  with attribute = value of 30 detect that we had an implementation squatting on attribute 30 = by a Huawei router.   =A1=B0Squatting=A1=B1 on an attribute is anti-social behavior in the Internet in any release of software.  =

 

The individuals who did in Huaw= ei have been contacted by Jie Dong, and =A1=B0asked=A1=B1 if they had made = this mistake in any other attribute.   These individuals confesse= d to Attribute 129 (for wide communities).  These individuals apologize to the Working group. 

 

Now what shall we do? The large= community draft is critical for several networks. After talking with the d= evelopers and operators, John and I would like to recommend we do the follo= wing:

 

IDR should recommend that the f= ollowing attribute numbers be deprecated:  

 

BGP Attribute 30

BGP attribute 129

 

IDR should ask IANA to assign B= GP Large Communities (currently Attribute 30) to a new attribute number. &n= bsp;This is a 1 week call to determine if the IDR approves this action. &nb= sp; This call will allow the large communities draft to still continue with the 2 week WG LC. 

 

John, Alvaro, and I have check = the early allocation rules.  Implementations should ask for early allo= cation prior to releasing, and they do not need to be interoperability test= ing to request the early allocation for the attribute.

 

Sue Hares

 

 

--_000_19AB2A007F56DB4E8257F949A2FB9858C87A93D0NKGEML515MBXchi_-- From nobody Tue Nov 1 02:40:38 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5862129A91 for ; Tue, 1 Nov 2016 02:40:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497, SPF_HELO_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 lulc0fu-m-KO for ; Tue, 1 Nov 2016 02:40:35 -0700 (PDT) Received: from gir.theapt.org (gir.theapt.org [81.209.183.113]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A43B129450 for ; Tue, 1 Nov 2016 02:40:35 -0700 (PDT) Received: from gir.theapt.org (unknown [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/0 bits)) (Client did not present a certificate) (Authenticated sender: phessler) by gir.theapt.org (Postfix) with ESMTPSA id 95FF678985 for ; Tue, 1 Nov 2016 10:40:33 +0100 (CET) Date: Tue, 1 Nov 2016 10:40:32 +0100 From: Peter Hessler To: idr@ietf.org Message-ID: <20161101094032.GR27221@gir.theapt.org> References: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129 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, 01 Nov 2016 09:40:38 -0000 I support adoption. On 2016 Oct 31 (Mon) at 17:18:57 -0400 (-0400), John G.Scudder wrote: :Hi Everyone, : :The author has asked for the WG to adopt draft-snijders-idr-deprecate-30-31-129. : :If you support or oppose adoption please reply indicating so. Reasons for your position are helpful, as volunteering to review, comment, and/or shepherd. As an aside, I will note that I don't think the WG has the option of doing nothing, so if you oppose adoption please address what you think should be done instead. : :The adoption call will end November 13. : :Thanks, : :--John : :P.S.: https://tools.ietf.org/html/draft-snijders-idr-deprecate-30-31-129-01 : :Abstract : : This document requests IANA to deprecate the following BGP path : attributes values: 30, 31 and 129. : : :_______________________________________________ :Idr mailing list :Idr@ietf.org :https://www.ietf.org/mailman/listinfo/idr From nobody Tue Nov 1 03:44:36 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58C30129559 for ; Tue, 1 Nov 2016 03:44:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, TVD_SPACE_RATIO=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 LQqkLMcGuuyI for ; Tue, 1 Nov 2016 03:44:33 -0700 (PDT) Received: from mail1.bemta6.messagelabs.com (mail1.bemta6.messagelabs.com [193.109.254.106]) by ietfa.amsl.com (Postfix) with ESMTP id BAC0912952B for ; Tue, 1 Nov 2016 03:44:32 -0700 (PDT) Received: from [193.109.255.99] by server-2.bemta-6.messagelabs.com id 5D/92-27874-F0278185; Tue, 01 Nov 2016 10:44:31 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPIsWRWlGSWpSXmKPExsUSsELzqy5/kUS Ewd0vAhavbj9jcmD0WLLkJ1MAYxRrZl5SfkUCa8aLnlbGAtmKpxO3MDYwynQxcnEICRxkkjgx 8yNTFyMnkLOGUeLFLwMQm03ASGLCuv0sXYwcHCICihIrPyWDhIUFoiTuP9oNVi4iEC1x6sJLR ghbT+LHxF9sIDaLgIrE/pk3mEFsXgF7iXmf74LZjAKyEl8aV4PZzALiEreezAebIyEgILFkz3 lmCFtU4uXjf6wgtijQzE+3V7NAxBUkLi7oYgM5h1lAU2L9Ln2IMbYSj/4cYYSwFSWmdD9kh1g rKHFy5hOWCYzCs5Bsm4XQPQtJ9ywk3bOQdC9gZF3FqFGcWlSWWqRraKyXVJSZnlGSm5iZo2to YKaXm1pcnJiempOYVKyXnJ+7iREYDQxAsIPxy7KAQ4ySHExKorxfw8QjhPiS8lMqMxKLM+KLS nNSiw8xynBwKEnw9hZIRAgJFqWmp1akZeYA4xImLcHBoyQCkeYtLkjMLc5Mh0idYjTmWHTi+Q Mmjneb3z1gEmLJy89LlRLnPQNSKgBSmlGaBzcIli4uMcpKCfMyAp0mxFOQWpSbWYIq/4pRnIN RSZi3B2QKT2ZeCdy+V0CnMAGdYp4EdkpJIkJKqoFRoy7g3KcbLEKbFjGflV4Rrvz5YFBYZI5c m2HOp7v26xK5Hj3r3h7Pwxj/Mrq7T120IyuAM7Xj1+Ki5v6UeR+Zv/9+nKJ02/DAnaZdapkah 1Zd1GiQdNzkyhO04Yv2i6XnGm98fFPTaz+n1G+78YOPfSwFJ1jYM7zMctLvNVkZJD3u660+n6 bEUpyRaKjFXFScCAB+RieJEgMAAA== X-Env-Sender: david.freedman@uk.clara.net X-Msg-Ref: server-10.tower-48.messagelabs.com!1477997071!66960777!1 X-Originating-IP: [80.168.41.245] X-StarScan-Received: X-StarScan-Version: 9.0.13; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28768 invoked from network); 1 Nov 2016 10:44:31 -0000 Received: from staff03.mail.eu.clara.net (HELO staff03.mail.eu.clara.net) (80.168.41.245) by server-10.tower-48.messagelabs.com with SMTP; 1 Nov 2016 10:44:31 -0000 Received: from [80.168.41.252] (port=17743 helo=SRVGREXCAS02.claranet.local) by staff03.mail.eu.clara.net (staff03.mail.eu.clara.net [80.168.41.245]:25) with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) id 1c1WYR-0005MY-AE for idr@ietf.org (return-path ); Tue, 01 Nov 2016 10:44:31 +0000 Received: from SRVGREXMB01.claranet.local ([fe80::64bc:5d10:5203:a830]) by SRVGREXCAS02.claranet.local ([::1]) with mapi id 14.03.0319.002; Tue, 1 Nov 2016 10:41:31 +0000 From: David Freedman To: "idr@ietf.org" Thread-Topic: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129 Thread-Index: AQHSNCyBCyyAFtbePEee/C18dglmOA== Date: Tue, 1 Nov 2016 10:41:31 +0000 Message-ID: <9BF4C90E-E3C2-49DF-AC40-66C3EE2943FF@uk.clara.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1b.0.161010 x-originating-ip: [172.26.6.254] Content-Type: text/plain; charset="utf-8" Content-ID: <323CC1690AACE344A71876D8F65CC479@claranet.local> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129 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, 01 Nov 2016 10:44:34 -0000 U3VwcG9ydC4KCkRhdmUuCgo= From nobody Tue Nov 1 04:32:07 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD54E12964A for ; Tue, 1 Nov 2016 04:32:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.097 X-Spam-Level: X-Spam-Status: No, score=-4.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497] 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 kZlpfzEtq7EE for ; Tue, 1 Nov 2016 04:32:04 -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 F1C6F12962B for ; Tue, 1 Nov 2016 04:32:03 -0700 (PDT) X-Original-To: idr@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 1532C60DAE for ; Tue, 1 Nov 2016 12:32:02 +0100 (CET) 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 A8FF0628AB; Tue, 1 Nov 2016 12:32:01 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id A35E3718D; Tue, 1 Nov 2016 12:32:01 +0100 (CET) Date: Tue, 1 Nov 2016 12:32:01 +0100 From: Gert Doering To: "John G.Scudder" Message-ID: <20161101113201.GC79185@Space.Net> References: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> X-NCC-RegID: de.space User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Cc: IETF IDR Working Group Subject: Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129 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, 01 Nov 2016 11:32:05 -0000 Hi, On Mon, Oct 31, 2016 at 05:18:57PM -0400, John G.Scudder wrote: > The author has asked for the WG to adopt draft-snijders-idr-deprecate-30-31-129. Support adoption. Read the text as well, while at it, and it's short and to the point, so support for the content as well :) 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 Nov 1 05:00:57 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32057129693 for ; Tue, 1 Nov 2016 05:00:56 -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 EWK-2OyY8Oke for ; Tue, 1 Nov 2016 05:00:54 -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 60A1612966F for ; Tue, 1 Nov 2016 05:00:54 -0700 (PDT) X-Envelope-To: idr@ietf.org Received: from cupcake.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 uA1C0qwC018107 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Nov 2016 12:00:52 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 cupcake.local Message-ID: <581883F2.1060300@foobar.org> Date: Tue, 01 Nov 2016 12:00:50 +0000 From: Nick Hilliard User-Agent: Postbox 5.0.5 (Macintosh/20161020) MIME-Version: 1.0 To: "John G.Scudder" References: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> In-Reply-To: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: Cc: IETF IDR Working Group Subject: Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129 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, 01 Nov 2016 12:00:56 -0000 John G.Scudder wrote: > The author has asked for the WG to adopt draft-snijders-idr-deprecate-30-31-129. support. Nick From nobody Tue Nov 1 06:32:46 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E32481296F4 for ; Tue, 1 Nov 2016 06:32:45 -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, 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 MM1UJMp4Sawf for ; Tue, 1 Nov 2016 06:32:44 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC3661296E8 for ; Tue, 1 Nov 2016 06:32:43 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id u144so15400037wmu.1 for ; Tue, 01 Nov 2016 06:32:43 -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=V3kxb25Rv7AEYYHA4WVF3GevoaAykr5p6MEcEi/Qf1U=; b=qwUKHyNaNl4dXn3zK2MhJ8gfvxnMWasJQyWHQq+xA+KKCaF6F8sX8qzo+hO+9kbgpS veyPmwjnnQwDcdjabMTE36iWo0YYRkCC2SPQCZlBT+7Dlmo7+Hrg/xCri8l6YXx+ELZt EmsuS2M0Z+v1ly0nsgNhINfz/rlpmRYGmj34A+E1bZPLzVMyWOQpvS9S/mMegfPxyi4t t4S53QmxySps2MiKwFEkGjK3QPtS8b0ErcpTebJIK1g4LVt3+rdKrqMvhtSBNmlFNWDz YFZO53to85hyInAgEvHkW8Mi/gQouspM45g3i4ZR3yu1NSn3cdGXT+Avcr4ts/pyNKQo Xc+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=V3kxb25Rv7AEYYHA4WVF3GevoaAykr5p6MEcEi/Qf1U=; b=WxRXfUcaDs6HcKs41xPLqDX8dX6LPkHDH+iWuf/EBu7k0nrtnI/s0KXq3aRerNHOdU U6R0x/joyzqlq6T2mXGDsZOtTavK6NxodGRcwlt8iDoOWOKyXtUueqrAib77ToHpDZx6 uJSD4WSTZLGP8u2RH3GYuFzimCq5HlCKR0PI2FSJqYDBKb+gtitxyEUc9V2Oy4KY105l +SZNB/Hk6ZFSe4fIVlStlon64DAsaqsJ7a+FY7tAGZvxrb/Sx8M+neB3XYk+iS+eN4li EM0EbdOxlmccDAd2b6hBzqSWB51guEmAcw1iVDVU6VvK4QaWJ1ZUy++2fbIvoe99COzD lrUg== X-Gm-Message-State: ABUngvfLwjOKhBTP9/W8LWp4PaNeXKbNf+/QtKRvgbkQ1r/4t4NyT4Q/dpmHja9n32oIbg== X-Received: by 10.28.210.195 with SMTP id j186mr1867472wmg.30.1478007162067; Tue, 01 Nov 2016 06:32:42 -0700 (PDT) Received: from localhost ([2001:67c:208c:10:84fc:620c:8d43:a0fa]) by smtp.gmail.com with ESMTPSA id p13sm30599324wmd.20.2016.11.01.06.32.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Nov 2016 06:32:41 -0700 (PDT) Date: Tue, 1 Nov 2016 14:32:40 +0100 From: Job Snijders To: "John G.Scudder" Message-ID: <20161101133240.GK1581@hanna.meerval.net> References: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.1 (2016-10-04) Archived-At: Cc: IETF IDR Working Group Subject: Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129 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, 01 Nov 2016 13:32:46 -0000 Dear working group, To prevent having multiple drafts in quick succession covering the same style of issue - I'd like your feedback on the following: I believe that bgp path attribute 241, 242, 243 should also be added to this draft for the same reasons as 30, 31 and 129 are listed. OLD: This document requests IANA to deprecate the following BGP Path attributes: 30, 31, and 129. NEW: This document requests IANA to deprecate the following BGP Path attributes: 30, 31, 129, 241, 242, and 243. Does anyone object? If so, why? Unilaterally changing the document while in its mid-flight through the working group adoption process might be considered bad form, hence my request for feedback on the 241,242,243 topic. Please note - the deprecation of an attribute can be undone if proper process is followed. The priority here is to prevent IANA from assigning tainted codepoints to innocent bystanders, thus a deprecation document needs to exist. In time the working group has the power to undeprecate them for specific purposes. Kind regards, Job On Mon, Oct 31, 2016 at 05:18:57PM -0400, John G.Scudder wrote: > Hi Everyone, > > The author has asked for the WG to adopt draft-snijders-idr-deprecate-30-31-129. > > If you support or oppose adoption please reply indicating so. Reasons for your position are helpful, as volunteering to review, comment, and/or shepherd. As an aside, I will note that I don't think the WG has the option of doing nothing, so if you oppose adoption please address what you think should be done instead. > > The adoption call will end November 13. > > Thanks, > > --John > > P.S.: https://tools.ietf.org/html/draft-snijders-idr-deprecate-30-31-129-01 > > Abstract > > This document requests IANA to deprecate the following BGP path > attributes values: 30, 31 and 129. > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Tue Nov 1 07:02:44 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5E8412953A for ; Tue, 1 Nov 2016 07:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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 Nlwn4M4JS3Ye for ; Tue, 1 Nov 2016 07:02:40 -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 8A5B01294C3 for ; Tue, 1 Nov 2016 07:02:39 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id a197so79877120wmd.0 for ; Tue, 01 Nov 2016 07:02:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=m3UgNutFTm/ETvA4K/2C7pGezKSdVbuWGCLBa+reRjo=; b=yxdm7nHTKkjWAMe0QV/1XthIGuwHV3q4L/Zg/Jh4ttgJ6JU99Km781ZJjaH6anwZkj gnnCHnAxoM1FL0vFQW2Mcz07MFm+GPBBxdY5q1UkIXFJHeauavnKLKBj+HglOo+Zn7qF jNEf4/TLJlBBzMUtY1wMOsc2PtGbSQZeQIK6edv8KuCAWg1A52T2WcwRnM2B3T7OJtmV zm6NbHdB6LVErKODiJcPxlYw5ceFbEvXescnrzxFTKkJML2h68dGhW+cSbUtU9wRUJlF Hz7oFc7v3ZAP72mnrpMY6l6NhYNR1Byt1EpgYT1jHSG9IJgYq6j0A1+msFyg2bo1bDR9 en9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=m3UgNutFTm/ETvA4K/2C7pGezKSdVbuWGCLBa+reRjo=; b=mXn5eI8wFEIsLCNHZSgm9/D7rCIMX1hRXl6o6sCA6iqcqS6aHV3oxshihs/KoHuJlK bp5IdeHfUY66FsnRhDbns2EncoHJwTm7r2TA53gpedC5Yc8KQ0x5UQC2AY+ADrOeKrMv lKZZ/yd8BzMeyGLRijPSuy8ooka7I9jGV/YanLJBvVxZwvANEMDRltCh8sH0Bza+hl+X UeonDHGbxafdsXxNaSRjC6nZMEiizwAK9Yn/jbTARUXJE/nu6bzESjRvoNIV/zkonxEQ 5JVgQMbVYeNJiGqU3rinYtnHKSp7aaSz6GQ5Hf63DE5OsR3An9boya2QWTNkjtOHWKCb seEw== X-Gm-Message-State: ABUngveF9z8r3KQfnRC2hl5kwz5oI7FvKM1TfMbSsFKSutIQBvstG3cwUdRCv3frvI50Xt8eki39B0KeXnfdWw== X-Received: by 10.28.217.139 with SMTP id q133mr1903574wmg.17.1478008958080; Tue, 01 Nov 2016 07:02:38 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.80.137.69 with HTTP; Tue, 1 Nov 2016 07:02:37 -0700 (PDT) In-Reply-To: <20161101133240.GK1581@hanna.meerval.net> References: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> <20161101133240.GK1581@hanna.meerval.net> From: Robert Raszuk Date: Tue, 1 Nov 2016 15:02:37 +0100 X-Google-Sender-Auth: pqVUsYMQqOlZ6D9eBAz8mdfL3_w Message-ID: To: Job Snijders Content-Type: multipart/alternative; boundary=001a11468750ebda8005403dc677 Archived-At: Cc: IETF IDR Working Group Subject: Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129 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, 01 Nov 2016 14:02:43 -0000 --001a11468750ebda8005403dc677 Content-Type: text/plain; charset=UTF-8 Hi Job, Have you consider marking those codepoints as "RESERVED" rather then "DEPRECIATED". Reason being that if any of the applications they have been squatted on behalf of want to use them - it would be pretty easy to allocate them. The other alternative would be to allocate them to those applications now (for which the drafts exist) as IANA early allocations. If you depreciate them now and we know that as example Contrail Multicast is important either your draft will need to quickly be moved to historic or yet another types will need to be allocated again. In any of the above Large Communities will get virgin BGP attribute type which I believe is the main point here. Cheers, R. On Tue, Nov 1, 2016 at 2:32 PM, Job Snijders wrote: > Dear working group, > > To prevent having multiple drafts in quick succession covering the same > style of issue - I'd like your feedback on the following: > > I believe that bgp path attribute 241, 242, 243 should also be added to > this draft for the same reasons as 30, 31 and 129 are listed. > > OLD: > This document requests IANA to deprecate the following BGP Path > attributes: 30, 31, and 129. > > NEW: > This document requests IANA to deprecate the following BGP Path > attributes: 30, 31, 129, 241, 242, and 243. > > Does anyone object? If so, why? > > Unilaterally changing the document while in its mid-flight through the > working group adoption process might be considered bad form, hence my > request for feedback on the 241,242,243 topic. > > Please note - the deprecation of an attribute can be undone if proper > process is followed. The priority here is to prevent IANA from assigning > tainted codepoints to innocent bystanders, thus a deprecation document > needs to exist. In time the working group has the power to undeprecate > them for specific purposes. > > Kind regards, > > Job > > On Mon, Oct 31, 2016 at 05:18:57PM -0400, John G.Scudder wrote: > > Hi Everyone, > > > > The author has asked for the WG to adopt draft-snijders-idr-deprecate- > 30-31-129. > > > > If you support or oppose adoption please reply indicating so. Reasons > for your position are helpful, as volunteering to review, comment, and/or > shepherd. As an aside, I will note that I don't think the WG has the option > of doing nothing, so if you oppose adoption please address what you think > should be done instead. > > > > The adoption call will end November 13. > > > > Thanks, > > > > --John > > > > P.S.: https://tools.ietf.org/html/draft-snijders-idr-deprecate- > 30-31-129-01 > > > > Abstract > > > > This document requests IANA to deprecate the following BGP path > > attributes values: 30, 31 and 129. > > > > > > _______________________________________________ > > 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 > --001a11468750ebda8005403dc677 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Job,

Have you consider marking those codepoints as "R= ESERVED" rather then "DEPRECIATED".=C2=A0

Reason being that if any of the applicat= ions they have been squatted on behalf of want to use them - it would be pr= etty easy to allocate them.

The other alternative would be to allocate them to those applications= now (for which the drafts exist) as IANA early allocations. If you depreci= ate them now and we know that as example Contrail Multicast is important ei= ther your draft will need to quickly be moved to historic or yet another ty= pes will need to be allocated again.=C2=A0

In any of the above Large Communities will get virgin = BGP attribute type which I believe is the main point here.

Cheers,
R.


On Tue, Nov 1, 2016 at 2:32 PM, Job Snijders <job@ins= tituut.net> wrote:
Dear wor= king group,

To prevent having multiple drafts in quick succession covering the same
style of issue - I'd like your feedback on the following:

I believe that bgp path attribute 241, 242, 243 should also be added to
this draft for the same reasons as 30, 31 and 129 are listed.

OLD:
=C2=A0 =C2=A0 This document requests IANA to deprecate the following BGP Pa= th
=C2=A0 =C2=A0 attributes: 30, 31, and 129.

NEW:
=C2=A0 =C2=A0 This document requests IANA to deprecate the following BGP Pa= th
=C2=A0 =C2=A0 attributes: 30, 31, 129, 241, 242, and 243.

Does anyone object? If so, why?

Unilaterally changing the document while in its mid-flight through the
working group adoption process might be considered bad form, hence my
request for feedback on the 241,242,243 topic.

Please note - the deprecation of an attribute can be undone if proper
process is followed. The priority here is to prevent IANA from assigning tainted codepoints to innocent bystanders, thus a deprecation document
needs to exist. In time the working group has the power to undeprecate
them for specific purposes.

Kind regards,

Job

On Mon, Oct 31, 2016 at 05:18:57PM -0400, John G.Scudder wrote:
> Hi Everyone,
>
> The author has asked for the WG to adopt=C2=A0 draft-snijders-idr-depr= ecate-30-31-129.
>
> If you support or oppose adoption please reply indicating so. Reasons = for your position are helpful, as volunteering to review, comment, and/or s= hepherd. As an aside, I will note that I don't think the WG has the opt= ion of doing nothing, so if you oppose adoption please address what you thi= nk should be done instead.
>
> The adoption call will end November 13.
>
> Thanks,
>
> --John
>
> P.S.: https://tools.ietf.o= rg/html/draft-snijders-idr-deprecate-30-31-129-01
>
> Abstract
>
>=C2=A0 =C2=A0 This document requests IANA to deprecate the following BG= P path
>=C2=A0 =C2=A0 attributes values: 30, 31 and 129.
>
>
> _______________________________________________
> 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

--001a11468750ebda8005403dc677-- From nobody Tue Nov 1 07:12:35 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C680C12955C for ; Tue, 1 Nov 2016 07:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.432 X-Spam-Level: X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_SOFTFAIL=0.665] 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 4qgTfQFouqj9 for ; Tue, 1 Nov 2016 07:12:34 -0700 (PDT) Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (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 EA4D8129527 for ; Tue, 1 Nov 2016 07:12:33 -0700 (PDT) Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1c1Znk-000FlA-4S (job@us.ntt.net); Tue, 01 Nov 2016 14:12:32 +0000 Date: Tue, 1 Nov 2016 15:12:29 +0100 From: Job Snijders To: Robert Raszuk Message-ID: <20161101141229.GK1589@hanna.meerval.net> References: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> <20161101133240.GK1581@hanna.meerval.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.1 (2016-10-04) Archived-At: Cc: IETF IDR Working Group Subject: Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129 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, 01 Nov 2016 14:12:34 -0000 On Tue, Nov 01, 2016 at 03:02:37PM +0100, Robert Raszuk wrote: > Have you consider marking those codepoints as "RESERVED" rather then > "DEPRECIATED". "DEPRECIATED" is an IANA attribute state I am not familiar with, I assume you mean "deprecated"? :) > Reason being that if any of the applications they have been squatted > on behalf of want to use them - it would be pretty easy to allocate > them. > > The other alternative would be to allocate them to those applications > now (for which the drafts exist) as IANA early allocations. If you > depreciate them now and we know that as example Contrail Multicast is > important either your draft will need to quickly be moved to historic > or yet another types will need to be allocated again. That is not how the process works. An implementor should not be rewarded with the possibility of laziness after they squat on a codepoint. "Laziness" being that they don't have to renumber, and that they didnt have to go through the normal process to obtain the codepoint. I argue that we cannot tolerate: "I'll just take this one, IANA will give it to me anyway later on if the product becomes popular" Also, the 'deprecate' draft (if published) would be "updated", not moved to historic. Only when all six proposed squatted points are returned to the "unassigned" pool the document can be declared historic. > In any of the above Large Communities will get virgin BGP attribute > type which I believe is the main point here. No, the main point is to prevent another deployment issue like Large BGP Communities suffered. Large BGP Communities has been resolved now (after considerable effort I might add). This document protects innocent bystanders from being assigned undeployable tainted codepoints. Kind regards, Job From nobody Tue Nov 1 07:17:37 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 415E61296FB for ; Tue, 1 Nov 2016 07:17:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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 8myFQbopUC5G for ; Tue, 1 Nov 2016 07:17:33 -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 69F2F1296B5 for ; Tue, 1 Nov 2016 07:17:33 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id a197so80722002wmd.0 for ; Tue, 01 Nov 2016 07:17:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=1ASam+YuYAllVSNHzmyK8x15zXlBPf62qQtfoFxuQEE=; b=GeTwoh8ohGVa88+kijCFVl/W5sNv5evOJkJfVLMNwn2VYi6Bf5vi9l0j3bq9UYeHsB Ha6EHsMKuRRFnG7Ezy63MgDzxe6IPyo3z9W/S8SJmQoBsxyIYz0/Wm1fgWsd8R3Z8oG/ mavAYgVsq3Tu5nReh22jhJ5vkmVAttwl23eMIVTmmvAgA6cHe8KdNdCC7+WZu/Dfyoeb QTeLG5cG0h5FDu+Fpig+5Z5pViCBvJaodHzP6ahX/RqjFBKW2JQaji6EsWEYExz0dFDM BnQD8baUYvKHi1j7rw/cg1XSUoTH+LdLT/feSpky7s3NPIEH1OcRlFkl+/Nk7wP9c+Kh UvtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=1ASam+YuYAllVSNHzmyK8x15zXlBPf62qQtfoFxuQEE=; b=ll25l5VsVZpM4oA54u2EIX1clmeMbOrwOWuMFQFZreoPHQp9wG1mimF5qnUFlSyx9W /6HQByR5GjetsSHQKCI7JUUelBvZSwLVy8Sqvksvk94usd6DFnynjrNh4V1y1vWvebe4 +GG5FW8mt2u+v4UB9WYVP+b2ZhGdCkJAF5lFcXBwGn3tX04HqusbHkBZptmo+qwdaXoe +u5JQe1KQNLFgFn7d2HxuVh9BqBOe3kHS6W58DOdz/7OkVcKesdl7riQpuSFQrEU3vOd aiCqlvs8EEn9R9FrKcY4voYFplf0YSTEz/d4HV8ytuag4eOlMyUO3kk4wOMprPbVWQY8 uyBQ== X-Gm-Message-State: ABUngvf+/WiKzF7hCUh90mAGr2lJ2smVwni3iNO6BALzXnGckEZw9PqDZXX/yx0W3dbHr2OBgLVl6gXy+0zo3A== X-Received: by 10.28.163.196 with SMTP id m187mr1699284wme.73.1478009850912; Tue, 01 Nov 2016 07:17:30 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.80.137.69 with HTTP; Tue, 1 Nov 2016 07:17:30 -0700 (PDT) In-Reply-To: <20161101141229.GK1589@hanna.meerval.net> References: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> <20161101133240.GK1581@hanna.meerval.net> <20161101141229.GK1589@hanna.meerval.net> From: Robert Raszuk Date: Tue, 1 Nov 2016 15:17:30 +0100 X-Google-Sender-Auth: qvkaFh0Tw4FSqJthi4kgN8DklJ8 Message-ID: To: Job Snijders Content-Type: multipart/alternative; boundary=001a114cd9a22363e105403dfcdb Archived-At: Cc: IETF IDR Working Group Subject: Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129 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, 01 Nov 2016 14:17:35 -0000 --001a114cd9a22363e105403dfcdb Content-Type: text/plain; charset=UTF-8 > An implementor should not be rewarded with the possibility > of laziness after they squat on a codepoint. + > I argue that we cannot tolerate: Ahh got it. So the point of the document is *punishment* for early attempts to implement anything not to technically address the problem at hand. Thx for clarification ... Cheers, R. On Tue, Nov 1, 2016 at 3:12 PM, Job Snijders wrote: > On Tue, Nov 01, 2016 at 03:02:37PM +0100, Robert Raszuk wrote: > > Have you consider marking those codepoints as "RESERVED" rather then > > "DEPRECIATED". > > "DEPRECIATED" is an IANA attribute state I am not familiar with, I > assume you mean "deprecated"? :) > > > Reason being that if any of the applications they have been squatted > > on behalf of want to use them - it would be pretty easy to allocate > > them. > > > > The other alternative would be to allocate them to those applications > > now (for which the drafts exist) as IANA early allocations. If you > > depreciate them now and we know that as example Contrail Multicast is > > important either your draft will need to quickly be moved to historic > > or yet another types will need to be allocated again. > > That is not how the process works. An implementor should not be rewarded > with the possibility of laziness after they squat on a codepoint. > "Laziness" being that they don't have to renumber, and that they didnt > have to go through the normal process to obtain the codepoint. > > I argue that we cannot tolerate: "I'll just take this one, IANA will > give it to me anyway later on if the product becomes popular" > > Also, the 'deprecate' draft (if published) would be "updated", not moved > to historic. Only when all six proposed squatted points are returned to > the "unassigned" pool the document can be declared historic. > > > In any of the above Large Communities will get virgin BGP attribute > > type which I believe is the main point here. > > No, the main point is to prevent another deployment issue like Large BGP > Communities suffered. Large BGP Communities has been resolved now (after > considerable effort I might add). > > This document protects innocent bystanders from being assigned > undeployable tainted codepoints. > > Kind regards, > > Job > --001a114cd9a22363e105403dfcdb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> An implementor should not be rewarded=C2=A0with the p= ossibility=C2=A0
> of laziness after they squat on a c= odepoint.

+= =C2=A0

>=C2=A0I argue that we ca= nnot tolerate:

= Ahh got it.=C2=A0

So t= he point of the document is punishment for early attempts to impleme= nt anything not to technically address the problem at hand. Thx for clarifi= cation ...

Cheers,
= R.


<= div class=3D"gmail_quote">On Tue, Nov 1, 2016 at 3:12 PM, Job Snijders <job@ntt.= net> wrote:
On Tue, Nov 01, 2016 at 03:02:37PM +0100, Robert Raszuk wrote:
> Have you consider marking those codepoints as "RESERVED" rat= her then
> "DEPRECIATED".

"DEPRECIATED" is an IANA attribute state I am not familiar= with, I
assume you mean "deprecated"? :)

> Reason being that if any of the applications they have been squatted > on behalf of want to use them - it would be pretty easy to allocate > them.
>
> The other alternative would be to allocate them to those applications<= br> > now (for which the drafts exist) as IANA early allocations. If you
> depreciate them now and we know that as example Contrail Multicast is<= br> > important either your draft will need to quickly be moved to historic<= br> > or yet another types will need to be allocated again.

That is not how the process works. An implementor should not be rewa= rded
with the possibility of laziness after they squat on a codepoint.
"Laziness" being that they don't have to renumber, and that t= hey didnt
have to go through the normal process to obtain the codepoint.

I argue that we cannot tolerate: "I'll just take this one, IANA wi= ll
give it to me anyway later on if the product becomes popular"

Also, the 'deprecate' draft (if published) would be "updated&q= uot;, not moved
to historic. Only when all six proposed squatted points are returned to
the "unassigned" pool the document can be declared historic.

> In any of the above Large Communities will get virgin BGP attribute > type which I believe is the main point here.

No, the main point is to prevent another deployment issue like Large= BGP
Communities suffered. Large BGP Communities has been resolved now (after considerable effort I might add).

This document protects innocent bystanders from being assigned
undeployable tainted codepoints.

Kind regards,

Job

--001a114cd9a22363e105403dfcdb-- From nobody Tue Nov 1 07:23:58 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC44312971B for ; Tue, 1 Nov 2016 07:23:57 -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 kE37OGdH49JU for ; Tue, 1 Nov 2016 07:23:55 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0123.outbound.protection.outlook.com [104.47.33.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 2C13F1296FB for ; Tue, 1 Nov 2016 07:23: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=Ji2J2pJjJPQ7cKD4AFBO8LQhmbH9J+gyCXapeNh0Bt8=; b=KBYfugLnZqy8miBE6bTChz2Kb0vuhG8j8tCpzY34XA9KJufX8harkQkXlrFzeEsVGM5PIEDtMTK8rPEMgqxwWfMbqHKFvwSfGDHL3gGeDsHV8dFAkI97WMn8xLaQIzhxL4PPIcFPVH52WwKGN9Iu0lgGPGK8USyBHbB3I6E/3lg= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; Received: from [172.29.37.68] (66.129.241.11) by CY1PR05MB2508.namprd05.prod.outlook.com (10.167.10.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.679.5; Tue, 1 Nov 2016 14:23:52 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_3258E2BC-01D1-4576-AC6A-4F553A9D43D3" MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "John G. Scudder" In-Reply-To: Date: Tue, 1 Nov 2016 10:23:46 -0400 Message-ID: <2393790D-F279-41ED-B5B2-E427C60B4926@juniper.net> References: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> <20161101133240.GK1581@hanna.meerval.net> To: Robert Raszuk X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.11] X-ClientProxiedBy: BY1PR20CA0039.namprd20.prod.outlook.com (10.162.140.49) To CY1PR05MB2508.namprd05.prod.outlook.com (10.167.10.135) X-MS-Office365-Filtering-Correlation-Id: 5a257689-90e1-45c8-2bf2-08d40262b525 X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2508; 2:kP9sZL8vnqToTQik5vmt/GZ4frjCYzRgd9SaViiWhZwJmc3ffB1KmYwMb1YDoj6EQejSirzDFMApDzYn5WZSuP77QxIpQIF//uMMM7VfSxu+7yQHGrdywH38LK6duUCmjuROBsPaU/4YC4WguLUt5oh6okWuYA3SxEgVDMYXecWHg1Cun3auLC9cVaywSLYSWqBPFJyUhTeS+VBsgdfjPg==; 3:zASB/0kPFZT8eU1ZT0X5rP8FA2Dx6LwbY9q5sjFljqRaZa3+OPSE2XJ/4krfXOSNUW3C2oOefblMrlji2obEtR7El8u/IyZR2A2j1e/yRz61h9SzTRga8rMOqSWALLfqjp9HgCjwr5r8xVB2Hmz3wA== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR05MB2508; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR05MB2508; 25:BYUcLbXumF00Fvc1OxgK3+R2zYZxwIEryBDx6nRzb?= =?us-ascii?Q?BUxSl5L7uWmZdCeadHX6tbRSkM6W0qn6K4TNA1I86urYX0k3fgK1OkvJyWYL?= =?us-ascii?Q?QclHAT17bH48p2ykw43BHNT6tjv3EpV4PYObNilUYqVwvbNR9bVGcSiVtlV1?= =?us-ascii?Q?kyJaooVj8i6c1iBXdbeFpesrWVucyCuCGCfmafcc2KCrxlRemq6Zdz7Wh8VZ?= =?us-ascii?Q?v4wOWKU1/yDryiOopTtlvZCN9Qpkc5+nrrOLp3pbZWh/pj/QaPnN/tBdRpvI?= =?us-ascii?Q?teRMqLZD5v/FMZjti3QOZDkCLVO206b2gZqJsN9+1p0EZ+vrk9rNsALSpau5?= =?us-ascii?Q?bYVEvcmeh1rd8kIBIFtECmorHLjnmrDPxF4EUfCp3twh5pl3aslLgusijQUH?= =?us-ascii?Q?fRLJ+WRZRsTAsjUhLWRGvh6DYwSxWIqPicyUHviZ8tN5akIqKNdTwqkf1Z1Z?= =?us-ascii?Q?YYT4RXP+mDNhMFUuxkSvz24kImBcF6hfVDEMlWieBLxo04cVb0Xh89nTDLYZ?= =?us-ascii?Q?TYFp1VpPUHOUo+k+VPfs3CiKqfJ8L/4dvVDBrIgfOEFIH7v8k/pZioL4Kxn9?= =?us-ascii?Q?MrTNrizM5L6ZXyKhH4OWsL2ta4Mdjqi7qKdjOTERmiuXWe3j76MI0KeDPSJw?= =?us-ascii?Q?wZpt+srGewM8N84Zs5AxLGPXcU5yK0R1NhJBz2WeodqqVT3zbYjkWgS2dNL6?= =?us-ascii?Q?Xs6Raj6dgFPopwIuyGvlwwsQdpkNt7+7IQky6WL+DVoICeq6kHUcCJAitF8L?= =?us-ascii?Q?u7yNaPiMqO2HagcKsFkfY7y0syh9blPM0d9RcvnRt23CcWYQaeUf8vSQ22yx?= =?us-ascii?Q?6E2H7NcYs+bOBp9+tWLR+P/rKiO8nE+mgjIAIouQ3vXowoTPhCleuu967omi?= =?us-ascii?Q?BjzcE+3XjGluvAb068OWFkoRegJQpKSA6FaXoB0+Fq1a7XQA9J806cbOTnIh?= =?us-ascii?Q?QziKGYSC9P32o8xNTq3WQcnTYhKlleVbIPXh0Frb5QqUmSoJ2c8fq/07TbEK?= =?us-ascii?Q?lpj8zn83Up96Q6/BlWcoNBF2v/aHvxRDKaHKdRy/uc5JQ=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2508; 31:xanmyI2BNON6K+jStnjICRa4bEmsh/qypn6+OAiX9pBCIyk/6Pfgfrp9/wXGDZvYyhD25tshQ9W/35jXhodPb72Ig3u7lZlROqBlvsM4mKjPZJGGDgoOalOHXAs47T/F3TcwypzLlRtsZCG3Kjpnm5OBbIqLxaoIoP3t3UuR5SsWO64VpSswnOUfkgdPpzDh4eFu26WjWBPlUW5xwm4XZRs+dzI/lzITYsgn5XXBQy6K2kvaE8mW9d82SUPhKEe5; 20:ZHEz/HXwByLbrFWwpALxihk4blzF7LT4ReUB2fH+AGAyu2FIUuYO+kCTriVH0OVtqEiG0byXHlEo4jTvHezuIKgJTZOci+sUnWhslNcr5ccAQGiPu1aOr5TgaLij7XGl36efzKPEbE7ZwkKN9zmjn1wAtx7gWPYjTZFB6yqU0v9XQqqzWtouWnbzA19L4gHB3Uz85NS0BRrgej/gKTwbZuwc7fKcTJmjfn3pruWQbXEVx4TPbqHCa0wkvsXiCMUfFxLW3TiK8Risc3sCvi7KMuOrfF8C4Ge5/zoCOvWILDDHKHPRpQOfTQh/i4TrBYjtmNUn/NVhNyY17X3S/ZzTCD7zgmhYX+q9QRDFAZ6jJrmlln0G2nDfGNfR1gh1+N2V5Ch9EcvAN2UHG+Oc+w/92bw5TNlSsnMo8raEMwj3fygJBnMlU8MvduNMO5z6P8Et0PvjZXNQmC+o+58DHUfv9geoKqVhmzPWWFH5OiYw3BSwWuWspy1651MkgSi3vCF3LSi5NEhsmIV8Tb8zEYgLsrMzNiSySru0NGWSkDfZwAMtCqu0UiyaJB6VRsYZDg+ZwO1b+QPEm0uu7DZV7uLfe/zrBtCctQ7kqsAhG0sI7lk= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(278428928389397); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:CY1PR05MB2508; BCL:0; PCL:0; RULEID:; SRVR:CY1PR05MB2508; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2508; 4:Rr4u9qxBrc9/EQtVZrt7GPW2ewgB+xXfh3aNUy8PNnRGYnt+4gy/n+YEGzs6kULn481hMkZOJCM1THRMYARt5GDb1IM1DF1T0pwnn2T2v3Oz61ccrVYpniLC8W7Yzpu5w5rTtSAvWedyRI0vEESccwhi89L/tOWNvuxbSdWq/QcYX0sYDtE1viPi/vJ6CCC9RTcjJNV+KXevZohVZ7bPKsMoJEFXnrq7F3h/Y7lbmDPsjWQT3z/KE/kDfCaTaLxrfYqZl/3H8A+YIbu/o2iVjBvckJuVGLabVYbiPayC7YNcQ+mWCShrtaBeOuu+Evhq9xcBgZ9niLukWaHZkOaFajlr/gXXnLCNQCFP4Cq5I7NDZxftZK36BznnFbfH06hnwm34lYRCnhPlMPH9ihgoQOeAiP+tmE6oTZ6q8kim4ggH4ESRnzqSFwKvo0KQE8Ewi9tEVIo+qDOa2UxFS+SW0A== X-Forefront-PRVS: 01136D2D90 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(7916002)(76104003)(377454003)(53754006)(5423002)(199003)(189002)(24454002)(19580405001)(36756003)(6666003)(110136003)(5660300001)(105586002)(512954002)(76176999)(50986999)(15975445007)(77096005)(101416001)(86362001)(230783001)(92566002)(106356001)(7736002)(7846002)(4326007)(97736004)(42186005)(50226002)(81166006)(2950100002)(189998001)(82746002)(69556001)(3846002)(260700001)(586003)(84326002)(2906002)(66066001)(6116002)(8676002)(83716003)(81156014)(19580395003)(33656002)(7906003)(6916009)(68736007)(57306001)(19617315012)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2508; H:[172.29.37.68]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR05MB2508; 23:HZW4Xxv2g1OytgcNKXQcbPrc3FBeu4bhUXBSLFViN?= =?us-ascii?Q?5GW4htkgTQjnWlv/bf9UKcpxfumQKNrL+nELBVzKoMgSx/de/nsdgalBkcj0?= =?us-ascii?Q?FhhVlJCMPSL7p2xv/adVMAAKeVvoYmAn5JKx2tjALlYlvI5dHwL9nZuoYYwH?= =?us-ascii?Q?zvkgQgCtgG37T01aPM74D0rN3QekYm9tYlr1aC41zcKgFZwQdHjyGimsp1JQ?= =?us-ascii?Q?1rfAkQ6JaG53gFRN/SaU6f/oBfFBcRqxM5jcz0JfkCHiCYoWfcCFL7xxshOM?= =?us-ascii?Q?NsiWGL7ZMDHvQbWL8NOI4YdL8Kg1xOAZ8X2E7eHPsRFQVkeQ3k1CIzKB7/MO?= =?us-ascii?Q?Gd2l/G8VkabbkN8vnppioqHQpD4173D40kAOg8ISy9aIa/iB0tSCP6Qft7+P?= =?us-ascii?Q?c56OXIvJPJCu68Ijq8znXsyVSjtytOxI/CMs9jwtwoscq2kjBaoImMzDh77b?= =?us-ascii?Q?oBaLKsSuMKiFTKTaecQWWpccFWdyDbvjumJ3/TvvrixReLi8/gLEpNWyV3I7?= =?us-ascii?Q?eJyBGFtldNlnS6NDvagSBGoPKoEQpA3mSPQJkJFoTLj9vRwUhzxf4g7TrWwc?= =?us-ascii?Q?0fiHuzF5sejAhncR7cmFBdB0Y+4xpDltxxIdH5fkAv6X1GONq1cL+GQO/8YJ?= =?us-ascii?Q?7O1WnvwXtuRaewWP2WSxa/nnWQpS6s1ykRKPsoZvJijKVsT/f4/YhWUjEmrk?= =?us-ascii?Q?AKW0vQ0EEqqY2XyPj6EGviLpURMIex+05AjCC7FvxFj2gkO0rXpyFGpHygsI?= =?us-ascii?Q?4hcaI4nK+kmniYg0egY7rrYZLExheItAStFUwf5p4QCNCtbroI0MCtKxQOVt?= =?us-ascii?Q?SaiTrg+r6qwUHLYVsCddGFeVepP4gKYfMFN9ZWGpyG+SZCfXQjeHaFCjTDPY?= =?us-ascii?Q?sSIQqmmdF5J99ZU23ZEfCzDsRtv/RgiYyedmmUPdnSQ2w+yLay4PSL6Hmg1G?= =?us-ascii?Q?mirWvv0+hviiifJE5wYDO/2e3JA2po531yYYouboIvn5+zBjgKNkr1eGDEfP?= =?us-ascii?Q?36cG1Bi53r3K55FUBut1xH7WW+/CN4vJ6Oxdb+Lx9Wc6ekifTbBivgYBpYHe?= =?us-ascii?Q?lNJwijSRZuUCxgexjYfGj0Dzfu61f0IZFisDbgFFDQsfU8FnuesT7TBl2Uab?= =?us-ascii?Q?n1w4nXyBQ8/d7BMHWGepG450a3WciRyZ0plT5Uh8BQYkfHH0pYBBgRfh/FQk?= =?us-ascii?Q?C7ZjTErIcAaCdjNNJ2wIWzJOuGC7yZLG76kLeYd+K0c6dQa8DzfQ3r/ykx6e?= =?us-ascii?Q?l0eNqwsrG2XlDkIaTCjxOAYDextzgVdv9G5cwvJzr4H52NDmO/H9ejm2keae?= =?us-ascii?Q?i9ZvzMC5p1KPRG84jrMOjMaMXvKnwqftnZABWXsIMnM?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2508; 6:rYPy/q5BBumTK7PSJ1DV09FlXVSR6N/qHtF4mcjJ8zBOG2xX8Abogipwt9i3GE+3MIYv4q7I4OFA2XZyykDDApDC0/gtpvtADmhuqfhyo9SEtOcPsmPq6ncP6wOgJ3RL2pSZd7AoC2OakYGjAzK/RpgxTKLnU/QLRw9L6yyz6NRzPhsWV3hxLdO8jtWYHowerp+WPhrBHnDGM1M03alFCJfRTwpZYH9VvMIm0QsfoPA3Il1bXcxzO2MWr+11NVNdPYh2BUEDrmJJovX7V5K8b/4uD7nl4ZIfD0wIm84C4QmQdv9HzHiUHj6Xz/UUqZrmadaxFzDHX7Sxa+SXHMbX4rdgaEqwvo2TZCOS4Y/dNm8=; 5:juZ8CDCuB3seXFpJ7UV5mNozGhVPvbhucXfXx+QrVTeY/u7bvfNtADh0WJBdKhhBPjHxtLjCedZQQ9fKox4Ypb2Z/LDCxBN5RgpF2n6EymKCu15LzaxFrh7aYIsaibUfNYjUDBVnLk6QqVXh3R7vKChH68MHYIjxP55xvHkO8Tc=; 24:HQUfC9jkLtLR9yUnOWMqxgmezTlkeNrrpoIpZt7kPpIVbhd7KIKBwa4bsuc7BaipurI/y+WhuI4Sqco7A8s73TOQDySX1/fLY9TfwlZTZjE= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2508; 7:6vN8r7JBS0ntY+uqOefQEnJm39orYbkfqWB20XHPKJDdZLaI6UfGrwCpnrurUdQ+3/yJ3CxlRbRMImSE/vX2ur8T6Auauiiboz/mxbE0AHesfVK1PwRWlA99bGHR/w24K5bWNYZOG0N6RvYRrtazm/ij1iA3sPuwiQGkO7Yf93u3do9Lu7/bcnb+/GATRhEdbVzuWphBQK1QNpdi9razzFJ/faQdFex2ZYg6PIO2nGLsG4Y11wy7t4nyTdDHIZGJU/m4g7aRPsPRqVJHKBxg8x9HZDY9lw2lb242zfYfPTVu5kSqNDaki45Q4yEOyMY10TzVuNyMRhiok2lPv0+3TXUaNptPcKIL4Z4MKQNfLBQ= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Nov 2016 14:23:52.5346 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2508 Archived-At: Cc: IETF IDR Working Group Subject: Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129 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, 01 Nov 2016 14:23:58 -0000 --Apple-Mail=_3258E2BC-01D1-4576-AC6A-4F553A9D43D3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" AFAICT the function of the draft is simply to kick the IANA code point = state to "deprecated". It doesn't anchor it there for all time. = Presumably a later request can move the state to assigned or whatever, = as we've previously discussed. I don't think any update to the current = "deprecate" document would be needed to achieve this (I guess maybe the = later document might list this one in its "updates" header). I'll confirm this understanding with IESG and IANA before the end of the = WG adoption call. (Unless someone can point me to chapter-and-verse of a = reference that explains the process clearly enough, unfortunately I have = not found such.) Thanks, --John > On Nov 1, 2016, at 10:02 AM, Robert Raszuk wrote: >=20 > Hi Job, >=20 > Have you consider marking those codepoints as "RESERVED" rather then = "DEPRECIATED".=20 >=20 > Reason being that if any of the applications they have been squatted = on behalf of want to use them - it would be pretty easy to allocate = them. >=20 > The other alternative would be to allocate them to those applications = now (for which the drafts exist) as IANA early allocations. If you = depreciate them now and we know that as example Contrail Multicast is = important either your draft will need to quickly be moved to historic or = yet another types will need to be allocated again.=20 >=20 > In any of the above Large Communities will get virgin BGP attribute = type which I believe is the main point here. >=20 > Cheers, > R. >=20 >=20 > On Tue, Nov 1, 2016 at 2:32 PM, Job Snijders > wrote: > Dear working group, >=20 > To prevent having multiple drafts in quick succession covering the = same > style of issue - I'd like your feedback on the following: >=20 > I believe that bgp path attribute 241, 242, 243 should also be added = to > this draft for the same reasons as 30, 31 and 129 are listed. >=20 > OLD: > This document requests IANA to deprecate the following BGP Path > attributes: 30, 31, and 129. >=20 > NEW: > This document requests IANA to deprecate the following BGP Path > attributes: 30, 31, 129, 241, 242, and 243. >=20 > Does anyone object? If so, why? >=20 > Unilaterally changing the document while in its mid-flight through the > working group adoption process might be considered bad form, hence my > request for feedback on the 241,242,243 topic. >=20 > Please note - the deprecation of an attribute can be undone if proper > process is followed. The priority here is to prevent IANA from = assigning > tainted codepoints to innocent bystanders, thus a deprecation document > needs to exist. In time the working group has the power to undeprecate > them for specific purposes. >=20 > Kind regards, >=20 > Job >=20 > On Mon, Oct 31, 2016 at 05:18:57PM -0400, John G.Scudder wrote: > > Hi Everyone, > > > > The author has asked for the WG to adopt = draft-snijders-idr-deprecate-30-31-129. > > > > If you support or oppose adoption please reply indicating so. = Reasons for your position are helpful, as volunteering to review, = comment, and/or shepherd. As an aside, I will note that I don't think = the WG has the option of doing nothing, so if you oppose adoption please = address what you think should be done instead. > > > > The adoption call will end November 13. > > > > Thanks, > > > > --John > > > > P.S.: = https://tools.ietf.org/html/draft-snijders-idr-deprecate-30-31-129-01 = > > > > Abstract > > > > This document requests IANA to deprecate the following BGP path > > attributes values: 30, 31 and 129. > > > > > > _______________________________________________ > > 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 = >=20 --Apple-Mail=_3258E2BC-01D1-4576-AC6A-4F553A9D43D3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii" AFAICT the function of the draft is simply to kick the IANA = code point state to "deprecated". It doesn't anchor it there for all = time. Presumably a later request can move the state to assigned or = whatever, as we've previously discussed. I don't think any update to the = current "deprecate" document would be needed to achieve this (I guess = maybe the later document might list this one in its "updates" = header).

I'll = confirm this understanding with IESG and IANA before the end of the WG = adoption call. (Unless someone can point me to chapter-and-verse of a = reference that explains the process clearly enough, unfortunately I have = not found such.)

Thanks,

--John

On = Nov 1, 2016, at 10:02 AM, Robert Raszuk <robert@raszuk.net> = wrote:

Hi = Job,

Have = you consider marking those codepoints as "RESERVED" rather then = "DEPRECIATED". 

Reason = being that if any of the applications they have been squatted on behalf = of want to use them - it would be pretty easy to allocate = them.

The = other alternative would be to allocate them to those applications now = (for which the drafts exist) as IANA early allocations. If you = depreciate them now and we know that as example Contrail Multicast is = important either your draft will need to quickly be moved to historic or = yet another types will need to be allocated again. 

In any = of the above Large Communities will get virgin BGP attribute type which = I believe is the main point here.

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

On Tue, Nov 1, 2016 at 2:32 PM, Job Snijders <job@instituut.net> wrote:
Dear working group,

To prevent having multiple drafts in quick succession covering the = same
style of issue - I'd like your feedback on the following:

I believe that bgp path attribute 241, 242, 243 should also be added = to
this draft for the same reasons as 30, 31 and 129 are listed.

OLD:
    This document requests IANA to deprecate the following BGP = Path
    attributes: 30, 31, and 129.

NEW:
    This document requests IANA to deprecate the following BGP = Path
    attributes: 30, 31, 129, 241, 242, and 243.

Does anyone object? If so, why?

Unilaterally changing the document while in its mid-flight through = the
working group adoption process might be considered bad form, hence my
request for feedback on the 241,242,243 topic.

Please note - the deprecation of an attribute can be undone if proper
process is followed. The priority here is to prevent IANA from = assigning
tainted codepoints to innocent bystanders, thus a deprecation = document
needs to exist. In time the working group has the power to = undeprecate
them for specific purposes.

Kind regards,

Job

On Mon, Oct 31, 2016 at 05:18:57PM -0400, John G.Scudder wrote:
> Hi Everyone,
>
> The author has asked for the WG to adopt  = draft-snijders-idr-deprecate-30-31-129.
>
> If you support or oppose adoption please reply indicating so. = Reasons for your position are helpful, as volunteering to review, = comment, and/or shepherd. As an aside, I will note that I don't think = the WG has the option of doing nothing, so if you oppose adoption please = address what you think should be done instead.
>
> The adoption call will end November 13.
>
> Thanks,
>
> --John
>
> P.S.: https://tools.ietf.org/html/draft-snijders-idr-deprecate-30-31-129-01
>
> Abstract
>
>    This document requests IANA to deprecate the following = BGP path
>    attributes values: 30, 31 and 129.
>
>
> _______________________________________________
> 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=_3258E2BC-01D1-4576-AC6A-4F553A9D43D3-- From nobody Tue Nov 1 07:26:04 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E02E61296FB for ; Tue, 1 Nov 2016 07:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, SPF_HELO_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 ldtQCxEsDmUO for ; Tue, 1 Nov 2016 07:26:01 -0700 (PDT) Received: from gir.theapt.org (gir.theapt.org [IPv6:2001:470:1f0b:8b2::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13AB5129722 for ; Tue, 1 Nov 2016 07:26:01 -0700 (PDT) Received: from gir.theapt.org (unknown [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/0 bits)) (Client did not present a certificate) (Authenticated sender: phessler) by gir.theapt.org (Postfix) with ESMTPSA id 685BB78985; Tue, 1 Nov 2016 15:25:59 +0100 (CET) Date: Tue, 1 Nov 2016 15:25:51 +0100 From: Peter Hessler To: Robert Raszuk Message-ID: <20161101142537.GA24817@gir.theapt.org> References: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> <20161101133240.GK1581@hanna.meerval.net> <20161101141229.GK1589@hanna.meerval.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: IETF IDR Working Group Subject: Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129 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, 01 Nov 2016 14:26:03 -0000 On 2016 Nov 01 (Tue) at 15:17:30 +0100 (+0100), Robert Raszuk wrote: :> An implementor should not be rewarded with the possibility :> of laziness after they squat on a codepoint. : :+ : :> I argue that we cannot tolerate: : :Ahh got it. : :So the point of the document is *punishment* for early attempts to :implement anything not to technically address the problem at hand. Thx for :clarification ... : :Cheers, :R. : Early development in support of an ID is desirable, and in this WG pretty much required. For that, a lab image and (in the open source case) patches floating around is good. Pushing these to innocent customers is not. Squatting on random (e.g. Huawei with code 30) codepoints *should* be punished, imho. Regardless if we consider it to be punishment or not-punishment, it should be documented that these code points are tainted, and cannot be considered pure and clean for future assignments. I don't care either way if 129 is used for a future Early Assignment of Wide Communities. But I do care if 31 is assigned to someone that has to fight the existing ecosystem. :On Tue, Nov 1, 2016 at 3:12 PM, Job Snijders wrote: : :> On Tue, Nov 01, 2016 at 03:02:37PM +0100, Robert Raszuk wrote: :> > Reason being that if any of the applications they have been squatted :> > on behalf of want to use them - it would be pretty easy to allocate :> > them. :> > :> > The other alternative would be to allocate them to those applications :> > now (for which the drafts exist) as IANA early allocations. If you :> > depreciate them now and we know that as example Contrail Multicast is :> > important either your draft will need to quickly be moved to historic :> > or yet another types will need to be allocated again. :> :> That is not how the process works. An implementor should not be rewarded :> with the possibility of laziness after they squat on a codepoint. :> "Laziness" being that they don't have to renumber, and that they didnt :> have to go through the normal process to obtain the codepoint. :> :> I argue that we cannot tolerate: "I'll just take this one, IANA will :> give it to me anyway later on if the product becomes popular" :> :> Also, the 'deprecate' draft (if published) would be "updated", not moved :> to historic. Only when all six proposed squatted points are returned to :> the "unassigned" pool the document can be declared historic. :> :> > In any of the above Large Communities will get virgin BGP attribute :> > type which I believe is the main point here. :> :> No, the main point is to prevent another deployment issue like Large BGP :> Communities suffered. Large BGP Communities has been resolved now (after :> considerable effort I might add). :> :> This document protects innocent bystanders from being assigned :> undeployable tainted codepoints. :> :> Kind regards, :> :> Job :> -- Command, n.: Statement presented by a human and accepted by a computer in such a manner as to make the human feel as if he is in control. From nobody Tue Nov 1 07:28:12 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1F7412954E for ; Tue, 1 Nov 2016 07:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.432 X-Spam-Level: X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_SOFTFAIL=0.665] 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 eU7FbjAvT3P8 for ; Tue, 1 Nov 2016 07:28:10 -0700 (PDT) Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (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 B92401294C1 for ; Tue, 1 Nov 2016 07:28:10 -0700 (PDT) Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1c1a2r-0000kN-Bq (job@us.ntt.net); Tue, 01 Nov 2016 14:28:09 +0000 Date: Tue, 1 Nov 2016 15:28:07 +0100 From: Job Snijders To: Robert Raszuk Message-ID: <20161101142807.GL1589@hanna.meerval.net> References: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> <20161101133240.GK1581@hanna.meerval.net> <20161101141229.GK1589@hanna.meerval.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.1 (2016-10-04) Archived-At: Cc: IETF IDR Working Group Subject: Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129 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, 01 Nov 2016 14:28:11 -0000 On Tue, Nov 01, 2016 at 03:17:30PM +0100, Robert Raszuk wrote: > > An implementor should not be rewarded with the possibility of > > laziness after they squat on a codepoint. > > + > > > I argue that we cannot tolerate: > > Ahh got it. > > So the point of the document is *punishment* for early attempts to > implement anything not to technically address the problem at hand. Thx for > clarification ... Am I to understand that you consider deployment problems not to be technical problems? BGP Path attribute codepoints are a global, shared resources. As Internet community we have vested IANA with the authority to assign resources from this pool. The social contract is that we abide by the rules related to IETF and IANA. The same rules we write ourselves. Kind regards, Job From nobody Tue Nov 1 07:30:50 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A67611294C1 for ; Tue, 1 Nov 2016 07:30:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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 Ln5WnJROpEdu for ; Tue, 1 Nov 2016 07:30:47 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c: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 C5C3F129565 for ; Tue, 1 Nov 2016 07:30:46 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id a197so81442120wmd.0 for ; Tue, 01 Nov 2016 07:30:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=zs8zng9JBhG9M9uEG9D6FwcUWmUHyh/dH8sOUeKMsQQ=; b=MlvS6YGX/xhM9I6i2wR8PTosW/i3GgnAFo2G0JPs/EmBHpg2pTEqnH//T1a4IDBrnN PClf3Qt0Q7hsYglgt1aRzF36bP1VGt7uwOE0mCWjQj1MOpjWfwqW7wxNT/F7GCXSq1MM sCDBCExSxx+mLypO6mpPCjM69sNFoZrmzPXMBMDscqUfPd2vdMWX8X3wY3sfiGxLk1cq hEmuO4UxpAXKF1blffJCgoP7SLLxghkGnBTeu9KuDApgVqe765BFtksjuri0giJ8GIWW sxJDRtMM9ZshnID8Ki8XYjGOJsU13NLzs86tcxrFvK+JYD8inQT0vRWrL2vBBjBQAmYo DOrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=zs8zng9JBhG9M9uEG9D6FwcUWmUHyh/dH8sOUeKMsQQ=; b=DoqD6p/1yH5fOnOPwp2r+rfj5KVwQXQ8F9NWj/BZxMaSdRMY+XIBn98BAQKvvxCScP 0+7ffmD6kn7vzxu5OY3s4eAjqdRHDCp32ftWV/RfpDOnQot0pro5ark8GxD9swIkL1h3 PJzqBXsQgz1mThJE1LkG7xP3lug+I79+Yjngu2De9BgYgGdvmLhQJL+jl/AMsvFbye5e 9NSLZVIcXhJwSJPO4VKC7IbYP+0nPaQK1GdlHZ1qSs/YKV1TwvsHrw3BWKrDEFeeB3vr uSNHHCnWdlwO97vsWiCygrYaTtSoDpReQO+3qFeenDrnDCPYDGVmFIwhjoj0qhNmb/Lf NIWQ== X-Gm-Message-State: ABUngvfqSDXRYEaKMBraG7e5sLH4GwBhsXHgvq6z3DVCC3bxOD9ToTuBlLPTl9/kMQP7Gr2tu5EYFNYDUV+qCA== X-Received: by 10.28.46.15 with SMTP id u15mr1931845wmu.61.1478010645262; Tue, 01 Nov 2016 07:30:45 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.80.137.69 with HTTP; Tue, 1 Nov 2016 07:30:43 -0700 (PDT) In-Reply-To: <2393790D-F279-41ED-B5B2-E427C60B4926@juniper.net> References: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> <20161101133240.GK1581@hanna.meerval.net> <2393790D-F279-41ED-B5B2-E427C60B4926@juniper.net> From: Robert Raszuk Date: Tue, 1 Nov 2016 15:30:43 +0100 X-Google-Sender-Auth: d0kPhzAIwxusFZGCDyrV03wNDuA Message-ID: To: "John G. Scudder" Content-Type: multipart/alternative; boundary=001a1142532c7c385a05403e2b7f Archived-At: Cc: IETF IDR Working Group Subject: Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129 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, 01 Nov 2016 14:30:50 -0000 --001a1142532c7c385a05403e2b7f Content-Type: text/plain; charset=UTF-8 Hi John, >From IDR WG standpoint could you state clearly the process for Early Allocation of Attribute Types, Message Types or AFI/SAFIs codepoints ? Does the process differ between IETF WGs ? Say if BESS will try to do also early allocation for given BGP Attribute Type ? I think this is the key here and root of the problem. If we require interoperable implementations for any draft to proceed WG should enable authors to create those implementations in the first place. Thx a lot, Robert. On Tue, Nov 1, 2016 at 3:23 PM, John G. Scudder wrote: > AFAICT the function of the draft is simply to kick the IANA code point > state to "deprecated". It doesn't anchor it there for all time. Presumably > a later request can move the state to assigned or whatever, as we've > previously discussed. I don't think any update to the current "deprecate" > document would be needed to achieve this (I guess maybe the later document > might list this one in its "updates" header). > > I'll confirm this understanding with IESG and IANA before the end of the > WG adoption call. (Unless someone can point me to chapter-and-verse of a > reference that explains the process clearly enough, unfortunately I have > not found such.) > > Thanks, > > --John > > On Nov 1, 2016, at 10:02 AM, Robert Raszuk wrote: > > Hi Job, > > Have you consider marking those codepoints as "RESERVED" rather then > "DEPRECIATED". > > Reason being that if any of the applications they have been squatted on > behalf of want to use them - it would be pretty easy to allocate them. > > The other alternative would be to allocate them to those applications now > (for which the drafts exist) as IANA early allocations. If you depreciate > them now and we know that as example Contrail Multicast is important either > your draft will need to quickly be moved to historic or yet another types > will need to be allocated again. > > In any of the above Large Communities will get virgin BGP attribute type > which I believe is the main point here. > > Cheers, > R. > > > On Tue, Nov 1, 2016 at 2:32 PM, Job Snijders wrote: > >> Dear working group, >> >> To prevent having multiple drafts in quick succession covering the same >> style of issue - I'd like your feedback on the following: >> >> I believe that bgp path attribute 241, 242, 243 should also be added to >> this draft for the same reasons as 30, 31 and 129 are listed. >> >> OLD: >> This document requests IANA to deprecate the following BGP Path >> attributes: 30, 31, and 129. >> >> NEW: >> This document requests IANA to deprecate the following BGP Path >> attributes: 30, 31, 129, 241, 242, and 243. >> >> Does anyone object? If so, why? >> >> Unilaterally changing the document while in its mid-flight through the >> working group adoption process might be considered bad form, hence my >> request for feedback on the 241,242,243 topic. >> >> Please note - the deprecation of an attribute can be undone if proper >> process is followed. The priority here is to prevent IANA from assigning >> tainted codepoints to innocent bystanders, thus a deprecation document >> needs to exist. In time the working group has the power to undeprecate >> them for specific purposes. >> >> Kind regards, >> >> Job >> >> On Mon, Oct 31, 2016 at 05:18:57PM -0400, John G.Scudder wrote: >> > Hi Everyone, >> > >> > The author has asked for the WG to adopt draft-snijders-idr-deprecate-3 >> 0-31-129. >> > >> > If you support or oppose adoption please reply indicating so. Reasons >> for your position are helpful, as volunteering to review, comment, and/or >> shepherd. As an aside, I will note that I don't think the WG has the option >> of doing nothing, so if you oppose adoption please address what you think >> should be done instead. >> > >> > The adoption call will end November 13. >> > >> > Thanks, >> > >> > --John >> > >> > P.S.: https://tools.ietf.org/html/draft-snijders-idr-deprecate-30- >> 31-129-01 >> > >> > Abstract >> > >> > This document requests IANA to deprecate the following BGP path >> > attributes values: 30, 31 and 129. >> > >> > >> > _______________________________________________ >> > 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 >> > > > --001a1142532c7c385a05403e2b7f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi John,

From IDR WG standpoint could you state clearly the p= rocess for Early Allocation of Attribute Types, Message Types or AFI/SAFIs = codepoints ?=C2=A0

Doe= s the process differ between IETF WGs ? Say if BESS will try to do also ear= ly allocation for given BGP Attribute Type ?=C2=A0
=
I think this is the key here and root of the p= roblem.=C2=A0

If we re= quire interoperable implementations for any draft to proceed WG should enab= le authors to create those implementations in the first place.=C2=A0
<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ;font-size:small">
Thx a lot,
Robert.


On Tue, Nov 1, 2016 at 3:23 PM, Joh= n G. Scudder <jgs@juniper.net> wrote:
AFAICT the function of the dr= aft is simply to kick the IANA code point state to "deprecated". = It doesn't anchor it there for all time. Presumably a later request can= move the state to assigned or whatever, as we've previously discussed.= I don't think any update to the current "deprecate" document= would be needed to achieve this (I guess maybe the later document might li= st this one in its "updates" header).

I'll= confirm this understanding with IESG and IANA before the end of the WG ado= ption call. (Unless someone can point me to chapter-and-verse of a referenc= e that explains the process clearly enough, unfortunately I have not found = such.)

Thanks,

--John

= On Nov 1, 2016, at 10:02 AM, Robert Raszuk <robert@raszuk.net> wrote:

=
Hi Job,

Have you consider marking those codepoints as "RESERVED" rat= her then "DEPRECIATED".=C2=A0

<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ;font-size:small">Reason being that if any of the applications they have be= en squatted on behalf of want to use them - it would be pretty easy to allo= cate them.

The other a= lternative would be to allocate them to those applications now (for which t= he drafts exist) as IANA early allocations. If you depreciate them now and = we know that as example Contrail Multicast is important either your draft w= ill need to quickly be moved to historic or yet another types will need to = be allocated again.=C2=A0

In any of the above Large Communities will get virgin BGP attribute typ= e which I believe is the main point here.

Cheers,
R.


On Tue, Nov 1, 2016 at 2:32 PM, Job Snijders <job@instituut.net>= wrote:
Dear working group,

To prevent having multiple drafts in quick succession covering the same
style of issue - I'd like your feedback on the following:

I believe that bgp path attribute 241, 242, 243 should also be added to
this draft for the same reasons as 30, 31 and 129 are listed.

OLD:
=C2=A0 =C2=A0 This document requests IANA to deprecate the following BGP Pa= th
=C2=A0 =C2=A0 attributes: 30, 31, and 129.

NEW:
=C2=A0 =C2=A0 This document requests IANA to deprecate the following BGP Pa= th
=C2=A0 =C2=A0 attributes: 30, 31, 129, 241, 242, and 243.

Does anyone object? If so, why?

Unilaterally changing the document while in its mid-flight through the
working group adoption process might be considered bad form, hence my
request for feedback on the 241,242,243 topic.

Please note - the deprecation of an attribute can be undone if proper
process is followed. The priority here is to prevent IANA from assigning tainted codepoints to innocent bystanders, thus a deprecation document
needs to exist. In time the working group has the power to undeprecate
them for specific purposes.

Kind regards,

Job

On Mon, Oct 31, 2016 at 05:18:57PM -0400, John G.Scudder wrote:
> Hi Everyone,
>
> The author has asked for the WG to adopt=C2=A0 draft-snijders-idr-depr= ecate-30-31-129.
>
> If you support or oppose adoption please reply indicating so. Reasons = for your position are helpful, as volunteering to review, comment, and/or s= hepherd. As an aside, I will note that I don't think the WG has the opt= ion of doing nothing, so if you oppose adoption please address what you thi= nk should be done instead.
>
> The adoption call will end November 13.
>
> Thanks,
>
> --John
>
> P.S.: https://tools.ietf.o= rg/html/draft-snijders-idr-deprecate-30-31-129-01
>
> Abstract
>
>=C2=A0 =C2=A0 This document requests IANA to deprecate the following BG= P path
>=C2=A0 =C2=A0 attributes values: 30, 31 and 129.
>
>
> _______________________________________________
> 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



--001a1142532c7c385a05403e2b7f-- From nobody Tue Nov 1 07:38:09 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 392FF129705 for ; Tue, 1 Nov 2016 07:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, 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 5uIIQutwMGgo for ; Tue, 1 Nov 2016 07:38:05 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 492961297BC for ; Tue, 1 Nov 2016 07:38:05 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 551621E337; Tue, 1 Nov 2016 10:40:36 -0400 (EDT) Date: Tue, 1 Nov 2016 10:40:36 -0400 From: Jeffrey Haas To: "John G.Scudder" Message-ID: <20161101144036.GB10519@pfrc.org> References: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: IETF IDR Working Group Subject: Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129 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, 01 Nov 2016 14:38:08 -0000 On Mon, Oct 31, 2016 at 05:18:57PM -0400, John G.Scudder wrote: > The author has asked for the WG to adopt draft-snijders-idr-deprecate-30-31-129. > > If you support or oppose adoption please reply indicating so. Reasons for your position are helpful, as volunteering to review, comment, and/or shepherd. As an aside, I will note that I don't think the WG has the option of doing nothing, so if you oppose adoption please address what you think should be done instead. I have a few points to raise here: 1. Do we actually need a draft published to request IANA to block out allocation of these code points? If so, we're going to end up with a number of trivial drafts for these corrective actions. I'm interested in hearing the IESG's opinion on this point. If we do need a draft, this draft is as fine as any. Hopefully we don't need one. 2. Much as it's tempting to try to use this process to try to be the clue hammer and "punish" people for grabbing code points, you burn enough bridges you eventually run out of wood. We have a few issues code shipping with such use suggest: 2a. Some of these things are features in use. If so, they're just going to have to get a different official code point. IMO, the right answer here is to push the implementors to get their registrations in order and officially request them. The penalty on *them* is the potential that someone else has already collided with them due to different squatting. 2b. Some of these things are early implementations that are against drafts that aren't fully mature. This means there will be versioning issues. Either the code point gets re-used and deals with the versioning problem or the code point needs deprecation. And even then, the fact that there's an early implementation means that eventually a code point is needed. --- It seems to me what is needed is some work to classify such early deployments as 2a or 2b. 2a just involves getting some administrative issues cleared. 2b means we should discuss how do we "clean" a code point sooner than later. Final observation: Some of this is messy due to scope propagation issues of internal features. This is another wake-up to deal with that propblem. -- Jeff From nobody Tue Nov 1 07:41:19 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A2061297C1 for ; Tue, 1 Nov 2016 07:41:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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 rwwTXOKkDvm2 for ; Tue, 1 Nov 2016 07:41:16 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c: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 DA959129705 for ; Tue, 1 Nov 2016 07:41:15 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id n67so290084060wme.1 for ; Tue, 01 Nov 2016 07:41:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=hwebqIpT0aL2hm8o9uPnOBzNkeW/PMi6x/Ka60uCrSY=; b=gRTzwC+yOauxoYo8Fwim3QLas9Ek2+xT3g/yW7LQLrEwS+EOsrfDD0GXrRLZG2Vz79 qu6MM67hQVlAX3WrrWUrFN49PFtBvSGIahednaSlghcVXjzhoo2D+2eStzWJsJ7mk5Tm RM+Wz64zY59Io+vBYH+cl2aGfI/P/RamGAAkvPFzukloGzEeAqy3eU+oPv63EKJ7dezc Wl14W6Bpy7zVM05WdKrUHnj4tiJps+fcET7oiipmr5GXK4KiTOiJzfhsKhAf86lnz2xn SgR2P61ImLMYhxEZJJ9rbfnke+FqsfI7r/8mOhTe3qTxihdFLGWK9kPzPyAzOltXREDm sF3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=hwebqIpT0aL2hm8o9uPnOBzNkeW/PMi6x/Ka60uCrSY=; b=my1LFhh2CbK9EOwOsdL6iszZ5bE5YKbl+/Z6xeg5IXBVlWEnSWLmCZArifZH11ZmYz ddpG/M8GG3PpU2n0ALIpMvu8OtScZ5w8ta8bKhCaKTM4x333YGjWvvLa56XIH+g/sPaz p/AXtGflyNjQykI00mbVOuvg42I25ERhNYI/MEYBExaqVrEWNMb5kbOrbkWXl+rbA2ey qcVS+dfKlbKR5LeLg7WUnYwHBdgSGtSicijSVQvzuZYRmJi2pix7wFxfUKGJraP2j5+P X6hWL+ABzsDmmxn2HiH/efiU1MAeLCSlzA087LkBIUWirTga8/VmCmn2f9wp9cJRcYYb DKWg== X-Gm-Message-State: ABUngvcJmklF4+YagGT2wyOp0LPpL01QpkdSpHFczDrUL32jnSpAEjVhpU1ujEVhbLnUnXQM5HDkeUR/4lNjkw== X-Received: by 10.195.13.107 with SMTP id ex11mr25464883wjd.99.1478011274349; Tue, 01 Nov 2016 07:41:14 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.80.137.69 with HTTP; Tue, 1 Nov 2016 07:41:12 -0700 (PDT) In-Reply-To: <20161101142807.GL1589@hanna.meerval.net> References: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> <20161101133240.GK1581@hanna.meerval.net> <20161101141229.GK1589@hanna.meerval.net> <20161101142807.GL1589@hanna.meerval.net> From: Robert Raszuk Date: Tue, 1 Nov 2016 15:41:12 +0100 X-Google-Sender-Auth: QYVYvQBwBvj1FVjCogZUMJDF0OQ Message-ID: To: Job Snijders Content-Type: multipart/alternative; boundary=047d7bfcedbefb53d605403e5024 Archived-At: Cc: IETF IDR Working Group Subject: Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129 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, 01 Nov 2016 14:41:17 -0000 --047d7bfcedbefb53d605403e5024 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > Am I to understand that you consider deployment problems not to be > technical problems? > =E2=80=8BYou stated clearly that Large is not subject to suffer from deploy= ment problems. So what other deployment problems you envision if those types would be moved to early allocation by IANA ? =E2=80=8B > BGP Path attribute codepoints are a global, shared resources. As > Internet community we have vested IANA with the authority to assign > resources from this pool. The social contract is that we abide by the > rules related to IETF and IANA. The same rules we write ourselves. > =E2=80=8BFew days back You and others complained that Wide was not implemen= ted by anyone for so many years. Now when we see it actually was implemented at least by few BGP code basis =E2=80=8Bit is again bad. So to me the problem we need to solve is how to allow early implementations for any proposal on the table especially now when we have no two but at least 8 production BGP implementations (and growing). Forbidding it does not seems to me like a solution to the main problem. Kind regards, R. --047d7bfcedbefb53d605403e5024 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=C2=A0
Am I to understand that you con= sider deployment problems not to be
technical problems?

= =E2=80=8BYou stated clearly that Large is not subject to suffer from deploy= ment problems. So what other deployment problems you envision if those type= s would be moved to early allocation by IANA ? =E2=80=8B
= =C2=A0
BGP Path attribute codepoint= s are a global, shared resources. As
Internet community we have vested IANA with the authority to assign
resources from this pool. The social contract is that we abide by the
rules related to IETF and IANA. The same rules we write ourselves.

=E2=80=8BFew days back You a= nd others complained that Wide was not implemented by anyone for so many ye= ars. Now when we see it actually was implemented at least by few BGP code b= asis =E2=80=8Bit is again bad.=C2=A0

So to me the problem we need to solve is how to allow early = implementations for any proposal on the table especially now when we have n= o two but at least 8 production BGP implementations (and growing). Forbiddi= ng it does not seems to me like a solution to the main problem.

Kind regards,
R.
--047d7bfcedbefb53d605403e5024-- From nobody Tue Nov 1 07:54:10 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E482C12968B for ; Tue, 1 Nov 2016 07:54:08 -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 lAkKgxM1rwCa for ; Tue, 1 Nov 2016 07:54:07 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0127.outbound.protection.outlook.com [104.47.40.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 67D9D12960B for ; Tue, 1 Nov 2016 07:54: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=RvFJmHuDp0xTMQ1DZ4KpbFJTVwafUB4H5UWG2qLt71o=; b=DfJ25LjIjb9PnpyvPrhwwkRNP9ZoD2mI+oTysOg42W3LNkv8FBTueS+0CULpJuent+ULwUvK24eQnKvMVC83dFGRfKHCIR8QNKbeXiJ6Rm8Zblmz69/dJMZg2Yd17q40IP3gY/TaO/tMVpICF0TsIzF1g3KqVXjxPt/Z060SPV4= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; Received: from [172.29.37.68] (66.129.241.11) by CY1PR05MB2506.namprd05.prod.outlook.com (10.167.10.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.679.5; Tue, 1 Nov 2016 14:54:05 +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: <20161101144036.GB10519@pfrc.org> Date: Tue, 1 Nov 2016 10:53:59 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> <20161101144036.GB10519@pfrc.org> To: Jeffrey Haas X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.11] X-ClientProxiedBy: CO1PR06CA029.namprd06.prod.outlook.com (10.242.160.19) To CY1PR05MB2506.namprd05.prod.outlook.com (10.167.10.27) X-MS-Office365-Filtering-Correlation-Id: 025e130e-751a-4340-b507-08d40266edc7 X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2506; 2:+o91eWRrcqCmZmHMwtjJmVd+K8peJgvsronIaSimcAyA6djhKbjZRyOqFT9AyTt03P6D4XYTRc5zEm0wfnEE292j+8IVrjo7mzrpj375W4ucFoCiFYUERp5pxn6AETCc5wny9m/BYM7O4pPCIuMLN/Y5e+nKPhlfyukht5RDVOKBI1hFwDOimOaS4/ztpq2f07yreQz6PKuFkUJXXTiXgw==; 3:/r5T/isWq+29Fy3Ec3J8BuqtjFLnx4gWnlBDy28RsL0iwLaSDDfbhfKjyrLH7Tii9DhFFKCqdZRjJkRKVXKCcY1pQmuQ7QQME5uCHLiDjtmHv3lXdWPFFKquQaUCzoZhJfD5diigmJfxBlL7QuOpOQ== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR05MB2506; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2506; 25:DC62U3IKwRoaVi/nA4hgM3L/2WRiBDsHVoBnJX0b1EXQc1Zv2xTbpfApwm0Lv1S6A/gYq/Le1iBdnyE/U2TWAX9ZyylmEzT3GAjrae7ebnZR0BT6/tTqbRbrIjKw/t/nlnLfBU/JB2hVG3hz4rvvP5CXbT0INP6RLzLKT+efqGW7uqwD2Y4qh5gt/KTTIvJqnPHYn//m9/Q+Q5FQd5hWMnuV0J+Ruu2iIMcKgaQ9lV/dMigp2MGqOQtLg+LpTEUeSXXYw85nKeXSWd6iAlj7cxhAC9Rvx+hubYIdgY6723f1m2B+ZFVp5mq7X+RVnm0HHeqk4D6BRARxohazxNLI7saB0Cp0V+LkGKMIPcriW0b1uMcTGgPSDdylfd6URd6EWgRPmiVrGcUJZjvZOcjuLjIEn+XB01mFWyfJslK2w6BJbX4NJS60kSUo2q5aPs9OkswEydnWbly5sXbK38J3VD7gfEmKM2dhfpcm5mbmOC1Yp8QrfuOPwnE6BJ3ghIWNI69bpPxZcW2IczL0SnAI08UsH0QC9xE/7yIcK3nwuDOQmh11R+4UL1SU3uK6gbYPYb2hAeH52ajJE9cr5g2Xkb97wUuP3MAfim8x7F92I/l+TbZTW3C0caY2wt29aw+oGvnac3/1AtL0B651bZPzaSDCJbl8aovaEX2/9BNYQDGg64gVg4M4ZakjsHo/DjQxLF0sSygFw74Qw88Ep/GiTOYLCdrZIKDgnCusn/9vfjo= X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2506; 31:4rYBYSyI+L4xdO3S0w2wDtNCvnEiflV7o2A3OT2eCNVPU5ysnaBp0NrU8f9K7kjouUjNzQhaCJ/yg0/d20+Z/i0J0SJa83Q0CGwobHm2LnMS/6NsJvpX6yfrWun8ilIwMRL2Z1Jbvvm7hrBWj5RubrGLk22/vDsFUoF0OROwSN3x4ZpUvxg4u16L4I4yQHGyXaYrMUp5ex4XFmM2IOp2/ZzkHBGH8o9P8Ub4X9njS4rO4yGybv6eu33ew4nPKwh0; 20:2kRAYFJGEMt4k4L3PXK3wKCArVCXOzASKPxK/3n2QIXjoKzefWfW7Gr8Td1r4NVpIz7tfuL45SFqm1jP4i5qo02V61OOWu8X7EDpzRXdshExWwjkjdxUOIGtpjF70WubyUc1W9HZFUhike9+E3i2lRtJlEDtg8weOBCatlCi1eO+dUR2QLXZJEn6udjJXrd+GaSUNviZDgC+/w3xAiOQhMc52yTuju6Cga91QADnTRs73aopq95ALj23vwq53D7/UGHYP94JGM8cVhvPx6N5Zb2iaYIqo86p3kFHOBqJNxWyTflLgS6b8dtG4NbkV4q6p6MyI7dishR6E0bOl49DWL5RbZ0sWldHzbYfnpSTlZIwGWoGcPoC2edPFdoUXnv2x4nfN9HzabhJ2j1A6nj8qTiiD97NQSutvtlrTKt72+Mz/Nb3oR481q2r2LdR9FJQNFHPV3Ul52lDTu46Xgi5hDbLC70/4FSGV8Tc97dYluihz6T0b9WQgP8xD0kikMz2c0cnFuCxgV2zR76tSzr7t10vyJAdOdhFuXbAv6cYf0fwv4Y18y3az4fHEYFznxja5oQL9yszyut0oamqC9gncFiJBknZ6IAE9YgOAPgUhWs= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:CY1PR05MB2506; BCL:0; PCL:0; RULEID:; SRVR:CY1PR05MB2506; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2506; 4:u8tZS6S96opFHY48ulqrhyHdrJ9DKj0vzYJ2aorlJceNPpdzR4946z4Cp472heIgUxXZA3AZ0JQU9YXZiz6wXDrA92ILi6KhuemkS1GPDCZL5W4h44G3qHezEuuFiL9Be6HVXZzmTtIarm33FE0+Fn940oUHRBwVsrdJj9NRlSzoo0Ip10IuLgzyh27nA5z4IR4EaDibIkmrh1a0MF19OCP0kATTSySEbRq8IpB1a/HgY1IRqLD6MmwxDmdHjzKfQFxPmTzSMOCCrK7SfKRw7rBsslGLGaTVqX4bKQuSbe+E62texD4rZf6BvCbCp/B2Vtmg8ZqbP4xbEGdEV9W1EMxvnEzvzEiNU/44IYVSwoUOyAds9Ig7w+EIpf3zOY31LfP8dkecOvDJhGISt+QUQ6veAa9FiAuFfQXANjN12iY= X-Forefront-PRVS: 01136D2D90 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(7916002)(199003)(24454002)(377454003)(189002)(5423002)(4326007)(189998001)(7846002)(110136003)(23726003)(42186005)(86362001)(3846002)(7736002)(81166006)(19580405001)(97736004)(8746002)(81156014)(230783001)(8676002)(2950100002)(6916009)(305945005)(82746002)(6666003)(50466002)(105586002)(6116002)(106356001)(46406003)(36756003)(97756001)(586003)(19580395003)(101416001)(68736007)(92566002)(77096005)(5660300001)(2906002)(50226002)(83716003)(57306001)(47776003)(66066001)(76176999)(33656002)(50986999)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2506; H:[172.29.37.68]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR05MB2506; 23:whVWbG+dh2pb3DqOXSuIbiTXQougkUOgUmYFiqs8J?= =?us-ascii?Q?axvgcyjIUu73M04uvAN4BmV/DL0orAE87MhoEUX7SkXT8IGSmS+odHErOdmH?= =?us-ascii?Q?wpcXRZkSoyU4E40W1hC19vlDXm7kvdaczMb7328WbBBKEQ/TxNeVOfMyCnF3?= =?us-ascii?Q?43k7Wlti/SvYHfi22g5sX91yijMkw9F1GSGNOFskFl/IDzkLEN0EJNfMwUxg?= =?us-ascii?Q?8V5vdpKpYSDtIuGcUQhMCFLa0vef95U70I2QMnWg6pDqJ8cN6wYXNEQY8a4/?= =?us-ascii?Q?kkdlihx40rSu1eeICKE5TLhUmbwH54KsgFt35U+XY3E8FaoZw1TgHIUwxv9i?= =?us-ascii?Q?3es20zmBXSCMy4g9JoB/oICSFJMBgy3mZpZyfzuZq5lKUaG4v81LtwJ7ZBJX?= =?us-ascii?Q?UL5d73EBwfIPUTlURneDm+gQd1PaIudw20ZD4q+LmFdNVzSoyHTxhX8rDDQW?= =?us-ascii?Q?EIQ2MtTo3q7zO1KqRZxHeiK3bcOWHSyhBGm5jLtDJc1jTG6X6SNcgoIV/EtP?= =?us-ascii?Q?6MsvgzUt7NSYDi2DqbihhYpvA5ovybdz0YQd5WAPKUno53R7tXwVcoQ6D0KT?= =?us-ascii?Q?S6KLXmOj+Cvm4EO5D5HJwEImoxp2k2KtyUaP11sgqQThWjo4ZV3rdUXjr+RI?= =?us-ascii?Q?89he7pfRfl9ipXCioLTTTfti9aV5GQS6iw5SqvBsxz16MUCQfSc0sDYfLAGU?= =?us-ascii?Q?OX4hO2egL7aRtTRZbnenCc6vKh9uK0wtlSvGmNJDerCClHhogALAjRSrYE78?= =?us-ascii?Q?ni/QYfXYkuXtUfMD3aZy6p5zXi7egnn+rlI2CKfsc0C/RzJCXY+WyKytzyL3?= =?us-ascii?Q?AkF6E+duj4dGKwRqAIpddsI/tITwXX1be1/JFq3s3HQQoudQKbdjOx95VlVD?= =?us-ascii?Q?d6nZLgu+6apUDCGYiQWZFwg7ri0QNjGmHA4gi2x2xQJkYxsdb0QqiyJP1YOt?= =?us-ascii?Q?igXSsIl7jLX8mVjHbgsbR0rcF+vWBlGoSeHlEfQcxVlq/Exxzj7OLRXVXaRW?= =?us-ascii?Q?Uz25300iFB01FHvvTnk/Y79M418eLxi08vUpEl3WPmnxw8ViknWtWFOvAYl+?= =?us-ascii?Q?i9GG8BfiCNLEWBqHxFYBeuAoLNVERLuSjT08GhwmuWN0GcQu7JJUdCCQ3kMx?= =?us-ascii?Q?HVZ1c1UNlz2keKpAENwQ5/B1KXMJ4kvhU4pMmBW6D5faipd01E4W9xgVFyFs?= =?us-ascii?Q?PYmc4/DLz5mH5gn/BFTztJFUoLNGbC3qtPU4eA66wjqZE2dhPM5wRIazp0W0?= =?us-ascii?Q?rVuX+VlpfFTaMTE0ZOrI7TjvHvTiHJkh5a7uvz2ASIr9jlXCaIcQ2+ELoD+J?= =?us-ascii?B?QT09?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2506; 6:+gOdmGy0k9wlNlpwDj0IHvC3I/zpDBGkeELchdeZxFVH8XcJZfeeJjgRixBeYplYB7NsGAxk5nmaoux1K+7LtBwylGoxI6G3s5EnTXjMWkS+5NF+uOi3LUSyARr3qIhi6qcQDJeBedDhfIx0QvjkfuWsCYXi6A6jdqQsrflkJqtF6ElJ5vVX/wXVmlzk281+7t0svXpvjoMm3T8YwtaR/zgM7i59d91gWdk/AzcQM9uGEdsS/8PJiqvCBQHS/0BEnACcIEgESWoO9WAJGWco1vaCwIPuUY6u/g7qO8vq1hpXFwKlN7jjUQLDq20JbfeaWnfk8ozvb9zNp9Ol8C6lQcc2La4SqfFQiYcZEJP8nt4=; 5:Zgi7LOaxxJMemCJ/Gcm5tThA7fqXcORmOb95CmJB8w+86zLJtDwBDYF/NU76K+cERLxKNlOMbiaqRy6kzUffEiRci2z90xw2k51fHVc6tFI7H3nXOzPt1xp5t9uRlaHK1PyLqVOQ5W1+Ns4tur0dNm1TENS+lXojz44rutkqF1I=; 24:N//lihCo1l81TKp9ogOUZX0c56bffDiKyUqdBpHH8kGT8xPaeXlECLgRjfVE+ag19jpXHxsi2RpIvkxOlXWu/RSDbXW9HTfNbQtMoEeOpBg= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2506; 7:aGdpwuJa8Fayc6Mpc86VHbHOvghWU8Kcz9yobY+95UmszHrDIFn7p+3E+SLKLq1koD6t+bVUqx9OXS2lcefATlfNk+5V8ErDm8/T8nc1SQMQ5ser+1ZNVGGDjxzZ2qa/KrRKH7GdFb4FE6ffq4JetNeq4jA2j+utiHlSLPmv+h8wSd0mgV1NsXdRhOSzpIEN/+qCjimsGSvkiuWoDsokVJX0hJZeKcXGHniI/wIQ5M4+uUaac2Ymd1rYNiwcBarpMKRLA2MHm5OxN9+WPDkZhUv3NJNzJ+pWRW+RKQBBgHEX+fjTehYsKlb4zWkKHa288Gp2U8qQAaeFBwDcLK0qCDODQ5qVEc4AOIB1zAFbYR4= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Nov 2016 14:54:05.9405 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2506 Archived-At: Cc: IETF IDR Working Group Subject: Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129 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, 01 Nov 2016 14:54:09 -0000 On Nov 1, 2016, at 10:40 AM, Jeffrey Haas wrote: > 1. Do we actually need a draft published to request IANA to block out > allocation of these code points? If so, we're going to end up with a = number > of trivial drafts for these corrective actions. I'm interested in = hearing > the IESG's opinion on this point. IANA did specifically request an RFC to reference although they stopped = short of explicitly saying "if you don't promise to give us a document, = we won't do this action". I have asked them to clarify and will report = back, but I suggest that for now the WG should assume that we do = actually need to publish draft and progress it to RFC. Thanks, --John= From nobody Tue Nov 1 07:55:36 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFD78129540 for ; Tue, 1 Nov 2016 07:55:34 -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 pMPmV6avuGTd for ; Tue, 1 Nov 2016 07:55:32 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0095.outbound.protection.outlook.com [104.47.32.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FCC612968B for ; Tue, 1 Nov 2016 07:55:32 -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=gUoM/SAHyqXi0BEAOB7l4p/HCH4tNZcOWlhU5Y59OXE=; b=JlhXD/cxMIGk7che0Y3dRkje5VAUvFbN+rQZw7c+R1pY8xXntDVSdzorQGu1oLvA1qjBls5lhhO5ezp7bAYDgn0KNerDStkO+RGdy/lQAg2+FDsp8AAHXLn1jLTAx8Ek8ejIV7/R69Dw40CXCwtwZ5Ah1rXd/yvY++xe4GScXjQ= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; Received: from [172.29.37.68] (66.129.241.11) by CY1PR05MB2505.namprd05.prod.outlook.com (10.167.10.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.679.5; Tue, 1 Nov 2016 14:55:29 +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: Date: Tue, 1 Nov 2016 10:55:25 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <7FE93D56-DAB9-48BC-A577-D48E48E025B4@juniper.net> References: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> <20161101133240.GK1581@hanna.meerval.net> <2393790D-F279-41ED-B5B2-E427C60B4926@juniper.net> To: Robert Raszuk X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.11] X-ClientProxiedBy: BN3PR10CA0003.namprd10.prod.outlook.com (10.161.211.13) To CY1PR05MB2505.namprd05.prod.outlook.com (10.167.10.26) X-MS-Office365-Filtering-Correlation-Id: 945ba98a-c4fd-453f-d2ac-08d402671fe7 X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2505; 2:UtOPx8Y60cX+9J/6i9KBpYAghr06L8vKy6b1mQZB/CQfADZRXvbeqP3dbxyvE3jkPLGx+xPiQG2AUVzlsWrlepinXdGtPMg58g6D5FFZshcThrFU8LYtNQ1zaoTTYazWIKrC3jRL/nde9kxywdZSZYrbbSMo85K+sfn8BT5AH/Jlo8KV2ekMo2ZOYh2TVhcIfsC7ztb0sp83Dg2nf+dUqg==; 3:25f/yMOhN4Kw0W89BvLC4iNTKAFv0V473veU19uQitDv8K3Mqn6OijVl6axaAQfhEOpVwOCaClvDEZphxsIpk22NoVfdANpWxLQy2ZoC+QVx+boIIyt5b5/7saPT7M4UqLE3FrCpmNCOKRp3yHQ2cg==; 25:CTqYdTfwOugntsPgFwtJvEgWQXg0Re8rZh4DF9DzuxGwqoNgkH4uvVbk7zgKal1iVQ8mwGe6VrUleaDIAQVs/cr4HCb97a20FQhE9wUPCUI69CP1B+wegAOCAO1vdry5lZYME+qanK0Q/u/iXGr/BUMvLDGvvOwB/uYpqyhC/mfCaIiRk6C1ity7501Yn7s6S8xdvtkghTYRHXSwazTfA0SSL8zoJph8x1OcslzK1Efwf98IMHtxUY9oShZpfW+K7zd02j5aA3p1bYmudSVYaWCP4+nALyNbgynn8tGDhFSnIuV8s1xs9eQHg33fHBx8F6kKY4ryTBD4xjtqnBMEslBHYwBGYE6/+sjCNd2cVT2bJDaVM+1w3cuQB7F7hGkVIkkxXBt7vBfnp0rE7sk4vGKeB6hlZ7YeAvt2XuBKDj3OCZJ9K8ZBy6Q+VZttIcl/ X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR05MB2505; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2505; 31:aCje0OgeaL0bto35tCOw50TLTvcr85nCG/dS0iZGgaqKqMX5acEyUpoeVtogEKtubbo/MJ2vecX155ZbGYMJoc+tnUg4saOftJMdxA3ckM9C5FLBmuw+5s66O1fzDpAUpaPEmxeu38yB7sNtvaypD0ehzg7NKtTkrU/b5XWpsGx9l/zQEa0CE69vpoejKYiR47I7tGzNmFi1nAkt5HFktnFK6+Ks164mvq62wzfL0V90BvafaBpZ2Y4not5LXJGy; 20:hzCYZ00KrjQ/OJ3DEffTXUj0Zug4R2t/aR0mi9lgugU8CXgtcEHhe/iKH9mHyHEChIZG18EI0nh4fQFuPwL9ZNsFt7noBgzNYFsMjw1p0GtncNjPrB865fCM/66G16c729nbiZ0sw380BGDTR477SV+n5vo+BH9v8ZZf342UQ/fDkUU+OogY6sW3Nstd41XS75WIi9eJTzj9eTjWfASYfxY6GwCIobtD/0tXJyRwArkApV5apSGP31Jx8se31TkTRnapVy/8i8bEQdiKgnpO/WJ/fBVNQOZx0qZA3O14K+znLYBe9pbOMtJwoOrekMKWiGPre3JrXWuUMQwMeyRyptQd+i4BSqxS5Z9hXoZaVkR3Jcb2prC4y0B3AG9CEWN9G2elc1PjnHkzfaEbPdwc9zJ8bubtT3fdPd/DYuPBCvf4EIv5jaZ8USqECW+oURM+Fl6SuW02O5HrT8ihLT5Q8NNxgYRXDFHXcZzaC3pwJhXr8sd45ogDcndL7h4I0mS23lIT/4zcU2Xvkds9oXhXMqw+eGRK0Uwil0s6M2MVf/LMF0GK7WlrFW2IXdroKHaXJWTHDjdV3ngKCGbaQvWBYq04EuRHCRDiiHN0GaL29wc= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(278428928389397)(138986009662008)(100405760836317); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:CY1PR05MB2505; BCL:0; PCL:0; RULEID:; SRVR:CY1PR05MB2505; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2505; 4:LsZk/6TsFcyTpTGL1HTeMmDPtdv7LcQPYG2I+G6N1MLzsv7fgbTw8eLGXSTFObV986OZ4wXjWfEhi4sykCwxwr3bJI3if+uBSh20PMXfXcmxrRpVbP9VpRkeS4c4WTMXrUjPAova3nzWHVwONDdRJ0tAUt8waG+kUZp8Cizt7xNndX8Xr41mm7AQmqHt1Re2VT2nBUN24nZvmOyE3JHtgADAjsT9KSmjQtOE/IPLstDHHxuGZXpIX6S2hep5ZVKOMxqsow/+B2544W53bYpnmAwgUyqbxRumG7/FIBAWkpAJkDOtw+pXIIfgYnBve641OlUBMpHwL/+CNl9rNSD+TZ0NsmkS8vwetWEwLd+I55CFtOV9Dg9CNNCKvxFZriiBn4Hl6Q2JotCwDQ3baATBCDq9LqhJUOG6u6uPFwveF3bC5DmFv0BC/ZOiakqvsqISOrRy2jsEisb6IzbRcFTQaxHnaASwbj9Eij3VeF/d4/g4tIpylIiC1ewyr7JNmUx1NDk5A5O/8WmLYPx5vLK/96bvYkdXlAXwhaHMe6JFxgA= X-Forefront-PRVS: 01136D2D90 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(7916002)(377454003)(199003)(69234005)(189002)(53754006)(24454002)(5423002)(76104003)(8676002)(6666003)(66066001)(46406003)(33656002)(97756001)(2906002)(57306001)(36756003)(76176999)(50986999)(230783001)(2950100002)(5660300001)(189998001)(50226002)(6916009)(47776003)(4326007)(50466002)(101416001)(105586002)(68736007)(106356001)(82746002)(83716003)(7846002)(305945005)(93886004)(110136003)(97736004)(42186005)(81166006)(86362001)(7736002)(3846002)(23726003)(6116002)(19580395003)(77096005)(15975445007)(8746002)(92566002)(586003)(19580405001)(81156014)(42262002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2505; H:[172.29.37.68]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR05MB2505; 23:1T0dsgleA2Z0Hj0isyqAfv8KDtNxWNVvy/fRddkCT?= =?us-ascii?Q?t19/Yjfgf22LNExkUkDvFhIgFvSo7nVpROrWkozr051lvF4/FeLEx6a5gGoG?= =?us-ascii?Q?BZJ5pgQjkncZiB+6Rk5M7rN6au3ksUr53SvZVl1hBGN5im5uTc9ON3A5jsiH?= =?us-ascii?Q?xWCHj8ikrACTfegB4kW1M4eUCB5yZ1SbMn8XnIleZfJ8s+7HbufzwawJ9509?= =?us-ascii?Q?jdmLUq2qZgt3FP4gOmDUKGtrDJ76FbFBX0qZa6ftyxoBRlQeD71Yy+WjsxZc?= =?us-ascii?Q?QRGlZWM7mskpptzUk0zBoY2rZwsAN6hKjIZqlE/7keC84SjTNLzLiHWv1tMs?= =?us-ascii?Q?YhU7EIfzxK9U7flPhvRcF2mFR5CNDo4tKe5LSA+iWragIx4e0Qtz2NMaxK4s?= =?us-ascii?Q?Vp6psQXvXyXz3H9xm/Z1bilgL+vtp8besVm0gpaP+8/cwa9brkiK5JDt5MoX?= =?us-ascii?Q?oJRBJv4vlyjs4Oih1KHQ8XlVvWdv8JfLvSke603gJESL+E8wb00TmoOvrvNZ?= =?us-ascii?Q?KSG2SW3plfSinZ2viFssdtciBoU3iCJ5kJwj3taIclou0wtF+0GWuc9N9wvy?= =?us-ascii?Q?0E19JbjzGDGuWU6PNy9XLkZM8r4jOB3mb++a1vGSxQzI/Q42N5AXr3Gd2xRr?= =?us-ascii?Q?wbD0RZ0QqWKTOlfHPQtDHm0yYgHmqalRcU2weu1yp4/BOPGRhi1OodxODy0i?= =?us-ascii?Q?9qdl5c4tXxDI1/LB99mB2FmEjTBCDVpluqh6EdlZTt88Lz7QZ28pTZYNi0rk?= =?us-ascii?Q?4jL7Q5JSJePJYbYB4/6LtlyGWXnzcKSAMjX0tzdhVgEbIdbCxzJJD7/9W+zk?= =?us-ascii?Q?OCHF3oZiEBg8JT/LPDrilreyXvD9g91Ixi9Nd8TVE4XPfuyslpXD8ib7e0U0?= =?us-ascii?Q?rkPSGZ/apWl5kpgWala+8rt3ovFG5KavXNnq/e2oWi/qRBzz+tZVgd6KpicQ?= =?us-ascii?Q?cnsf8yKaK/ARLSZ9wbmDRBX24zZbGTTrvD9kZGqIWkn+n/KV0dLsrJgkS7fS?= =?us-ascii?Q?1VDjBx//54EvgisQZVzjUZi5HJpBEgIqGpP+nlW5hxssRfndGoOQ4mvkwymV?= =?us-ascii?Q?wbV7xseaOdO25NqPozn2/fmvthfQ7iyCvD8bBqZVx6epCs9IbrB8/8TvnDJ/?= =?us-ascii?Q?8X5aZ1i661FvZmepGM54rwFAK01p/eQibEMR9PRoFK+W6IXmfS6RLtbVLjJ1?= =?us-ascii?Q?z77XJtHxPLpjDUtu/UEpZxKjiZ0zR1/osQp+nSJ69FEgUF8yuWKyzuheRIO8?= =?us-ascii?Q?vYd91dqdufBgld5CViLAr+bHJ4TCHW4qI8z+5FKAVZ3UGRZ10xyJFJA5kx3R?= =?us-ascii?Q?+ohWZPdU7cgRQNzDyYvjJGt7esXlkTEDcBtGPzYO6DwEPdugimMuKnxxeXim?= =?us-ascii?Q?8abuTvoOfQhg+smD5aIB4c2AuYI1ryxSDLabYhu6KemLWoSJwD2XcoFlC6Dc?= =?us-ascii?Q?k+8cOfqyg=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2505; 6:JFqcQ0AxHDXUrLPW8p1ONxN9DINwWTwquJy50KsTlSBEVtXTuMbmj6Adffx1GrSACKR9kvvLbAo6ckTv/dohsZMm6l9/cDkUByzjPgwwLT98mna/sJx4cukoMj57ALurYojaxjhyq1TxmW9C8KhjS44R64I2H/3yTT/vc/FVz7pXeWrwgHhZyHrT5Ow0bFAFKD3CZDrP0FLLtrEIvEnVIH5A74EPcRleuIAUPvvk6h43ZLSMcQRi3JoQjStGnlUTvJJcqExlgpOhwJrlXZbOYokedJDNCS7QRsfI1T94IGDvv6W3F/R2/Ck5e730GpRg2fPV4KioHfE2HvCQiXr0y+1grfSX8LHU+N+ubr/mfQ4=; 5:uswQR4lsiTallMQI/knc2fZR07B2FLzwChUTG9692v9sqCepzqGLbIO8azgku3f9LnPC8xuTjv+oppksonFsP3yTeE9EB3lWxPvK/9OaxuJ+SyA/IUF/MsSgoFU/UBjF8I7XgGNS8hwehvly7SFo3vxHE6ZMQyHGyUTIsOuN2J4=; 24:ib2VYujse4VhJP8Fwpy2tCdlCeu4eojDRlRPmcQC/kL9Wh/ZeF5CgWk2bxQ38J4hWyHLyntP01xNzj6hmIpxZME7p2P07ZuohB4Idh0WRQE= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2505; 7:Qfpuut9TztGz+DNOZGy3odFQ11A8Ut9PwagkpEZ5fF9MKdVGYvYxb67BBuSuyALtVVX0K3r0mtDrmMQP/Uswcpa6ahBYHq8EgFjkUV35Oiew+je3/eFtSz0NZA9a4F4j+EDsELImLFk5WrxmWoxT42J5+Bwc9/9qjdADFX0CopJxKq3R1QwZgtDvYS9DZ1MXWTivfgOs5QQu24Oz2hETGo0rbIaDmz+MqBeRLQ7NTWMzVgJR8F1M1JSo4F9VjFqek2NET9UqIb0eYh4hXTeU6ZOafB1G6GOxRKu53fqNCQ3xwZ405GHQlSRX1ZPe6DSTnn7eMaND1GKqDFzAHBnMTbLQZUAfqWMNMQP4W0gf/TU= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Nov 2016 14:55:29.9740 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2505 Archived-At: Cc: IETF IDR Working Group Subject: Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129 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, 01 Nov 2016 14:55:35 -0000 Robert, > On Nov 1, 2016, at 10:30 AM, Robert Raszuk wrote: >=20 > Hi John, >=20 > =46rom IDR WG standpoint could you state clearly the process for Early = Allocation of Attribute Types, Message Types or AFI/SAFIs codepoints ?=20= It's spelled out in RFC 7120. The RFC is short, so summarizing it is = kind of redundant, basically just look at sections 2 and 3.1 (approx 1 = page of text).=20 > Does the process differ between IETF WGs ? Say if BESS will try to do = also early allocation for given BGP Attribute Type ?=20 There could be some variability between working groups since two of the = RFC 7120 Section 3.1 steps involve working group chairs using their = judgment: 2. The WG chairs determine whether the conditions for early allocations described in Section 2 are met, particularly = conditions (c) and (d). FYI, condition (c) requires there to be a stable specification, = condition (d) requires there to be "sufficient interest in the = community". 3. The WG chairs gauge whether there is consensus within the WG that early allocation is appropriate for the given document. Sue and I have chosen to gauge this by means of a two-week consensus = call, as we do with other working group consensus items. This also = serves to confirm conditions (c) and (d).=20 > I think this is the key here and root of the problem.=20 FWIW, I don't. > If we require interoperable implementations for any draft to proceed = WG should enable authors to create those implementations in the first = place.=20 I'm not aware of there having been an early allocation request for any = of the code points in question. Regards, --John >=20 > Thx a lot, > Robert. >=20 >=20 > On Tue, Nov 1, 2016 at 3:23 PM, John G. Scudder = wrote: > AFAICT the function of the draft is simply to kick the IANA code point = state to "deprecated". It doesn't anchor it there for all time. = Presumably a later request can move the state to assigned or whatever, = as we've previously discussed. I don't think any update to the current = "deprecate" document would be needed to achieve this (I guess maybe the = later document might list this one in its "updates" header). >=20 > I'll confirm this understanding with IESG and IANA before the end of = the WG adoption call. (Unless someone can point me to chapter-and-verse = of a reference that explains the process clearly enough, unfortunately I = have not found such.) >=20 > Thanks, >=20 > --John >=20 >> On Nov 1, 2016, at 10:02 AM, Robert Raszuk wrote: >>=20 >> Hi Job, >>=20 >> Have you consider marking those codepoints as "RESERVED" rather then = "DEPRECIATED".=20 >>=20 >> Reason being that if any of the applications they have been squatted = on behalf of want to use them - it would be pretty easy to allocate = them. >>=20 >> The other alternative would be to allocate them to those applications = now (for which the drafts exist) as IANA early allocations. If you = depreciate them now and we know that as example Contrail Multicast is = important either your draft will need to quickly be moved to historic or = yet another types will need to be allocated again.=20 >>=20 >> In any of the above Large Communities will get virgin BGP attribute = type which I believe is the main point here. >>=20 >> Cheers, >> R. >>=20 >>=20 >> On Tue, Nov 1, 2016 at 2:32 PM, Job Snijders = wrote: >> Dear working group, >>=20 >> To prevent having multiple drafts in quick succession covering the = same >> style of issue - I'd like your feedback on the following: >>=20 >> I believe that bgp path attribute 241, 242, 243 should also be added = to >> this draft for the same reasons as 30, 31 and 129 are listed. >>=20 >> OLD: >> This document requests IANA to deprecate the following BGP Path >> attributes: 30, 31, and 129. >>=20 >> NEW: >> This document requests IANA to deprecate the following BGP Path >> attributes: 30, 31, 129, 241, 242, and 243. >>=20 >> Does anyone object? If so, why? >>=20 >> Unilaterally changing the document while in its mid-flight through = the >> working group adoption process might be considered bad form, hence my >> request for feedback on the 241,242,243 topic. >>=20 >> Please note - the deprecation of an attribute can be undone if proper >> process is followed. The priority here is to prevent IANA from = assigning >> tainted codepoints to innocent bystanders, thus a deprecation = document >> needs to exist. In time the working group has the power to = undeprecate >> them for specific purposes. >>=20 >> Kind regards, >>=20 >> Job >>=20 >> On Mon, Oct 31, 2016 at 05:18:57PM -0400, John G.Scudder wrote: >> > Hi Everyone, >> > >> > The author has asked for the WG to adopt = draft-snijders-idr-deprecate-30-31-129. >> > >> > If you support or oppose adoption please reply indicating so. = Reasons for your position are helpful, as volunteering to review, = comment, and/or shepherd. As an aside, I will note that I don't think = the WG has the option of doing nothing, so if you oppose adoption please = address what you think should be done instead. >> > >> > The adoption call will end November 13. >> > >> > Thanks, >> > >> > --John >> > >> > P.S.: = https://tools.ietf.org/html/draft-snijders-idr-deprecate-30-31-129-01 >> > >> > Abstract >> > >> > This document requests IANA to deprecate the following BGP path >> > attributes values: 30, 31 and 129. >> > >> > >> > _______________________________________________ >> > 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 >>=20 >=20 >=20 From nobody Tue Nov 1 08:01:54 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67D6212973E for ; Tue, 1 Nov 2016 08:01:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.432 X-Spam-Level: X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_SOFTFAIL=0.665] 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 bu1SDVlHg-HN for ; Tue, 1 Nov 2016 08:01:51 -0700 (PDT) Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (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 3235E127076 for ; Tue, 1 Nov 2016 08:01:51 -0700 (PDT) Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1c1aZR-0004O0-Uh (job@us.ntt.net); Tue, 01 Nov 2016 15:01:50 +0000 Date: Tue, 1 Nov 2016 16:01:48 +0100 From: Job Snijders To: Robert Raszuk Message-ID: <20161101150148.GM1589@hanna.meerval.net> References: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> <20161101133240.GK1581@hanna.meerval.net> <20161101141229.GK1589@hanna.meerval.net> <20161101142807.GL1589@hanna.meerval.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.1 (2016-10-04) Archived-At: Cc: IETF IDR Working Group Subject: Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129 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, 01 Nov 2016 15:01:52 -0000 On Tue, Nov 01, 2016 at 03:41:12PM +0100, Robert Raszuk wrote: > > Am I to understand that you consider deployment problems not to be > > technical problems? > > You stated clearly that Large is not subject to suffer from deployment > problems. So what other deployment problems you envision if those types > would be moved to early allocation by IANA? You might misunderstand what I intended to convey, my apologies for not being able to articulate myself better. Large BGP Communities was assigned BGP Path attribute, by IANA according to the Early Allocation rules (value 30 - 2016.09.26). Turns out that an implementor had already used that codepoint. This proved to cause issues during an experimental deployment of Large BGP Communities. Large BGP Communities had to back to the WG, the chairs and then IANA assigned a new codepoint (value 32 - 2016.10.26). So, today, Large BGP Communities does not suffer from the squatted '30' codepoint, because a renumbering effort was undertaken. The above is a description of a deployment problem and its resolution. In short: any new (early) allocations should not come from tainted codepoints. To ensure this, IANA needs instruction not to do so (that is the draft at hand). Maybe a pragmatic example will help clarify the situation: If IANA assigns Path Attribute 30 as early allocation of draft-chen-idr-geo-coordinates-03, I suspect the draft-chen-idr-geo-coordinates effort will encounter considerable deployment problems. This would be a waste of time for the authors and implementors of draft-chen-idr-geo-coordinates. > > BGP Path attribute codepoints are a global, shared resources. As > > Internet community we have vested IANA with the authority to assign > > resources from this pool. The social contract is that we abide by the > > rules related to IETF and IANA. The same rules we write ourselves. > > Few days back You and others complained that Wide was not implemented > by anyone for so many years. Now when we see it actually was > implemented at least by few BGP code basis it is again bad. You might not view it this way, but I am actually looking out for Wide's chances of deployment. At this point it is not known which version of the wide draft was implemented, or even if the implementation is compatible with said specification. It really is in -wide-'s best interest to _not_ use attribute 129. > So to me the problem we need to solve is how to allow early > implementations for any proposal on the table especially now when we > have no two but at least 8 production BGP implementations (and > growing). Forbidding it does not seems to me like a solution to the > main problem. But isnt the solution simple? I think early implementors should just request an Early IANA Allocation and follow that process! Kind regards, Job From nobody Tue Nov 1 08:03:33 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 985F61279EB for ; Tue, 1 Nov 2016 08:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.718 X-Spam-Level: X-Spam-Status: No, score=-5.718 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, RP_MATCHES_RCVD=-1.497, 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 q_kB63-OZPZe for ; Tue, 1 Nov 2016 08:03:30 -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 542E6127076 for ; Tue, 1 Nov 2016 08:03:30 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CZM33624; Tue, 01 Nov 2016 15:03:27 +0000 (GMT) Received: from DFWEML701-CAH.china.huawei.com (10.193.5.175) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 1 Nov 2016 15:03:23 +0000 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by dfweml701-cah.china.huawei.com ([10.193.5.175]) with mapi id 14.03.0235.001; Tue, 1 Nov 2016 08:03:18 -0700 From: Linda Dunbar To: "John G.Scudder" , IETF IDR Working Group Thread-Topic: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129 Thread-Index: AQHSM/uh5u34AbLCG02ZcGAU0LAG1aDEOhXg Date: Tue, 1 Nov 2016 15:03:17 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657F64943@dfweml501-mbb> References: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> <19AB2A007F56DB4E8257F949A2FB9858C87A9272@NKGEML515-MBX.china.huawei.com> In-Reply-To: <19AB2A007F56DB4E8257F949A2FB9858C87A9272@NKGEML515-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.128] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.5818AEC0.0322, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 42e14bdb35ca057ee61c8f8090bf07ff Archived-At: Subject: Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129 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, 01 Nov 2016 15:03:32 -0000 DQpTdXBwb3J0IGFkb3B0aW9uLg0KDQpUaGFua3MsDQpMaW5kYSBEdW5iYXINCg0KLS0tLS3Tyrz+ 1K28/i0tLS0tDQq3orz+yMs6IElkciBbbWFpbHRvOmlkci1ib3VuY2VzQGlldGYub3JnXSC0+rHt IEpvaG4gRy5TY3VkZGVyDQq3osvNyrG85DogMjAxNsTqMTHUwjHI1SA1OjE5DQrK1bz+yMs6IElF VEYgSURSIFdvcmtpbmcgR3JvdXANCtb3zOI6IFtJZHJdIFdvcmtpbmcgZ3JvdXAgYWRvcHRpb24g Y2FsbCBmb3IgZHJhZnQtc25pamRlcnMtaWRyLWRlcHJlY2F0ZS0zMC0zMS0xMjkNCg0KSGkgRXZl cnlvbmUsDQoNClRoZSBhdXRob3IgaGFzIGFza2VkIGZvciB0aGUgV0cgdG8gYWRvcHQgIGRyYWZ0 LXNuaWpkZXJzLWlkci1kZXByZWNhdGUtMzAtMzEtMTI5LiANCg0KSWYgeW91IHN1cHBvcnQgb3Ig b3Bwb3NlIGFkb3B0aW9uIHBsZWFzZSByZXBseSBpbmRpY2F0aW5nIHNvLiBSZWFzb25zIGZvciB5 b3VyIHBvc2l0aW9uIGFyZSBoZWxwZnVsLCBhcyB2b2x1bnRlZXJpbmcgdG8gcmV2aWV3LCBjb21t ZW50LCBhbmQvb3Igc2hlcGhlcmQuIEFzIGFuIGFzaWRlLCBJIHdpbGwgbm90ZSB0aGF0IEkgZG9u J3QgdGhpbmsgdGhlIFdHIGhhcyB0aGUgb3B0aW9uIG9mIGRvaW5nIG5vdGhpbmcsIHNvIGlmIHlv dSBvcHBvc2UgYWRvcHRpb24gcGxlYXNlIGFkZHJlc3Mgd2hhdCB5b3UgdGhpbmsgc2hvdWxkIGJl IGRvbmUgaW5zdGVhZC4NCg0KVGhlIGFkb3B0aW9uIGNhbGwgd2lsbCBlbmQgTm92ZW1iZXIgMTMu DQoNClRoYW5rcywNCg0KLS1Kb2huDQoNClAuUy46IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1zbmlqZGVycy1pZHItZGVwcmVjYXRlLTMwLTMxLTEyOS0wMQ0KDQpBYnN0cmFjdA0K DQogICBUaGlzIGRvY3VtZW50IHJlcXVlc3RzIElBTkEgdG8gZGVwcmVjYXRlIHRoZSBmb2xsb3dp bmcgQkdQIHBhdGgNCiAgIGF0dHJpYnV0ZXMgdmFsdWVzOiAzMCwgMzEgYW5kIDEyOS4NCg0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSWRyIG1haWxp bmcgbGlzdA0KSWRyQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2lkcg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CklkciBtYWlsaW5nIGxpc3QNCklkckBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9pZHINCg== From nobody Tue Nov 1 08:04:09 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7BDE1293E4 for ; Tue, 1 Nov 2016 08:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.718 X-Spam-Level: X-Spam-Status: No, score=-5.718 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, RP_MATCHES_RCVD=-1.497, 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 xLMONuQ2J_ES for ; Tue, 1 Nov 2016 08:04:07 -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 2D857127076 for ; Tue, 1 Nov 2016 08:04:07 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CUI15268; Tue, 01 Nov 2016 15:04:05 +0000 (GMT) Received: from DFWEML701-CAH.china.huawei.com (10.193.5.175) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 1 Nov 2016 15:04:04 +0000 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by dfweml701-cah.china.huawei.com ([10.193.5.175]) with mapi id 14.03.0235.001; Tue, 1 Nov 2016 08:03:59 -0700 From: Linda Dunbar To: "John G. Scudder" , "idr@ietf.org" Thread-Topic: [Idr] Working group adoption call for draft-gredler-idr-bgp-ls-segment-routing-ext Thread-Index: AQHSM7wg7vct1hg0kk6cKw6i6KU11aDEA+aAgAA21uA= Date: Tue, 1 Nov 2016 15:03:59 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657F64956@dfweml501-mbb> References: <19AB2A007F56DB4E8257F949A2FB9858C87A9258@NKGEML515-MBX.china.huawei.com> In-Reply-To: <19AB2A007F56DB4E8257F949A2FB9858C87A9258@NKGEML515-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.128] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.5818AEE5.0366, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 7216d8aca70e1b09e74f70d02851aaf9 Archived-At: Subject: Re: [Idr] Working group adoption call for draft-gredler-idr-bgp-ls-segment-routing-ext 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, 01 Nov 2016 15:04:09 -0000 DQoNClN1cHBvcnQuDQoNClRoYW5rcywNCkxpbmRhIER1bmJhcg0KDQotLS0tLdPKvP7Urbz+LS0t LS0NCreivP7IyzogSWRyIFttYWlsdG86aWRyLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gSm9obiBH LiBTY3VkZGVyDQq3osvNyrG85DogMjAxNsTqMTHUwjHI1SA1OjE2DQrK1bz+yMs6IGlkckBpZXRm Lm9yZw0K1vfM4jogW0lkcl0gV29ya2luZyBncm91cCBhZG9wdGlvbiBjYWxsIGZvciBkcmFmdC1n cmVkbGVyLWlkci1iZ3AtbHMtc2VnbWVudC1yb3V0aW5nLWV4dA0KDQpIaSBFdmVyeW9uZSwNCg0K VGhlIGF1dGhvcnMgaGF2ZSBhc2tlZCAoc29tZSB0aW1lIGFnbyBhY3R1YWxseSkgZm9yIHRoZSBX RyB0byBhZG9wdCBkcmFmdC1ncmVkbGVyLWlkci1iZ3AtbHMtc2VnbWVudC1yb3V0aW5nLWV4dC4g DQoNCklmIHlvdSBzdXBwb3J0IG9yIG9wcG9zZSBhZG9wdGlvbiBwbGVhc2UgcmVwbHkgaW5kaWNh dGluZyBzby4gUmVhc29ucyBmb3IgeW91ciBwb3NpdGlvbiBhcmUgaGVscGZ1bCwgYXMgdm9sdW50 ZWVyaW5nIHRvIHJldmlldywgY29tbWVudCwgYW5kL29yIHNoZXBoZXJkLg0KDQpUaGUgYWRvcHRp b24gY2FsbCB3aWxsIGVuZCBOb3ZlbWJlciAxMy4NCg0KVGhhbmtzLA0KDQotLUpvaG4NCg0KUC5T LjogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtZ3JlZGxlci1pZHItYmdwLWxzLXNlZ21l bnQtcm91dGluZy1leHQtMDQudHh0DQoNCkFic3RyYWN0DQoNCiAgIFNlZ21lbnQgUm91dGluZyAo U1IpIGFsbG93cyBmb3IgYSBmbGV4aWJsZSBkZWZpbml0aW9uIG9mIGVuZC10by1lbmQNCiAgIHBh dGhzIHdpdGhpbiBJR1AgdG9wb2xvZ2llcyBieSBlbmNvZGluZyBwYXRocyBhcyBzZXF1ZW5jZXMg b2YNCiAgIHRvcG9sb2dpY2FsIHN1Yi1wYXRocywgY2FsbGVkICJzZWdtZW50cyIuICBUaGVzZSBz ZWdtZW50cyBhcmUNCiAgIGFkdmVydGlzZWQgYnkgdGhlIGxpbmstc3RhdGUgcm91dGluZyBwcm90 b2NvbHMgKElTLUlTLCBPU1BGIGFuZA0KICAgT1NQRnYzKS4NCg0KICAgVGhpcyBkcmFmdCBkZWZp bmVzIGV4dGVuc2lvbnMgdG8gdGhlIEJHUCBMaW5rLXN0YXRlIGFkZHJlc3MtZmFtaWx5IGluDQog ICBvcmRlciB0byBjYXJyeSBzZWdtZW50IGluZm9ybWF0aW9uIHZpYSBCR1AuDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSWRyIG1haWxpbmcgbGlzdA0K SWRyQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkcg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklkciBtYWls aW5nIGxpc3QNCklkckBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9pZHINCg== From nobody Tue Nov 1 08:04:23 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A40E1297C5 for ; Tue, 1 Nov 2016 08:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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 fRAQwXzQYUdU for ; Tue, 1 Nov 2016 08:04:17 -0700 (PDT) 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 119EF129663 for ; Tue, 1 Nov 2016 08:04:16 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id t79so112453021wmt.0 for ; Tue, 01 Nov 2016 08:04:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Y99WaVWUpGnel6rz65tJYTiS3A+wdOuw2y08gE5zA64=; b=eihi5Gy7NRNVHLfh3GJ2NYLdoNUNpY7QFETMK0B9i5AhHDMqZtFyHnZUcvlfmZQs+3 QfPaJKr2RzgXulGl4tLVaTyWAgMtQiQqrIqwX0JTtAnYmeB4H58IRTvnyl9RubO8FNc1 msUolX+VhHHIjfuSkKhujKetZ7JffuKPOUb268KKvZMjAfpYV9mXO/IChys0sdIT+eje iC364KXimmq9KZrZELyzB2YpRtiSJdDglsWFZgHgvJsm4BdeAHMGzHrX86Az02hYw90S Rb45qrWrCY9tdW/ZqjzOBItIetqpbhYG4+Y8sNXv3etK8nTuJfLgBLeSwWmY8ptG930X I94w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Y99WaVWUpGnel6rz65tJYTiS3A+wdOuw2y08gE5zA64=; b=UcIVj27bSBH86PEEGLvBQB7CiBKmGGY0DChvWdMOTY9NizQyWZcO5IeNhszmF5EX67 tCXd/Lol/3iUECa3LlbVdzCmhVzEQfiJvGxW+ATc6os+kmE0IHDyBcUB33Sbt1krpbON aK4kbCmkcHrM7zxDPVUhEl6CyWONgqNpO+p0FgV/uxbz0PbkIFvsEG8c58x7t5jlofNV qRb2oBx6FhrdL/Qq9CuFwMYu8VPCr1+/q6y5j4hm+JT7VlFfiPR2dxyQq9o69v2FEMVy J2/MuZ1x2F7kHul+SUj0ksf5R1WvHSDRhU1JrNqNoPS0pG0eSfIHRMiWqjSzhRtN4eJl 2npQ== X-Gm-Message-State: ABUngvcYKdpNjyY6BhGbgx4sP3/WaV/k+qlTBHH60FQsCl8ZjqI47RocS5RbZZ11eziS7cLqQvmGn/6Kw6bGTQ== X-Received: by 10.28.46.15 with SMTP id u15mr2056430wmu.61.1478012654603; Tue, 01 Nov 2016 08:04:14 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.80.137.69 with HTTP; Tue, 1 Nov 2016 08:04:13 -0700 (PDT) In-Reply-To: <7FE93D56-DAB9-48BC-A577-D48E48E025B4@juniper.net> References: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> <20161101133240.GK1581@hanna.meerval.net> <2393790D-F279-41ED-B5B2-E427C60B4926@juniper.net> <7FE93D56-DAB9-48BC-A577-D48E48E025B4@juniper.net> From: Robert Raszuk Date: Tue, 1 Nov 2016 16:04:13 +0100 X-Google-Sender-Auth: ZaymEfuGV7jUu3DRlTMvxTfVL7o Message-ID: To: "John G. Scudder" Content-Type: multipart/alternative; boundary=001a1142532c4052d205403ea3bc Archived-At: Cc: IETF IDR Working Group Subject: Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129 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, 01 Nov 2016 15:04:21 -0000 --001a1142532c4052d205403ea3bc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =E2=80=8BJohn,=E2=80=8B > I'm not aware of there having been an early allocation request for any of > the code points in question. > =E2=80=8BWell I am not sure how some of the documents in question could ask= for early allocation based on RFC7120 published in 2014 if they were written and published well before that date ... https://tools.ietf.org/html/draft-marques-l3vpn-mcast-edge-01 https://www.ietf.org/archive/id/draft-vandevelde-idr-remote-next-hop-00.txt ... Thx, R. =E2=80=8B --001a1142532c4052d205403ea3bc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=E2=80=8BJohn,=E2=80=8B
=C2=A0
I'm not aware of there h= aving been an early allocation request for any of the code points in questi= on.

=E2=80=8BWell I= am not sure how some of the documents in question could ask for early allo= cation based on RFC7120 published in 2014 if they were written and publishe= d well before that date ...

https://tools.ietf.org/html/draft-marques-l3vpn-mcast-edge-01
<= a href=3D"https://www.ietf.org/archive/id/draft-vandevelde-idr-remote-next-= hop-00.txt">https://www.ietf.org/archive/id/draft-vandevelde-idr-remote-nex= t-hop-00.txt
...

Thx,
R.

=E2=80=8B

--001a1142532c4052d205403ea3bc-- From nobody Tue Nov 1 08:05:03 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50149129663 for ; Tue, 1 Nov 2016 08:05:02 -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 x_NkJZO1w2Fa for ; Tue, 1 Nov 2016 08:05:00 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0105.outbound.protection.outlook.com [104.47.42.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 7660B12995E for ; Tue, 1 Nov 2016 08:04:56 -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=3dt5zmuyP+9dROotJRjVq4W8hzhjSLFz2AH91s8pk1U=; b=YV7/4581Ze4Nk3E6HGMzUaQI3OmGB4yOtZrRaRtFNV5OHZb+1hFIsDL/Dax3OcQlt7ur93l5JZ8ydneehh77r0Du1cNXJkolgDYPihucwNO6uRkKZ7wGiQi27LhiqdKCzsU+OVVmq0N7VqXh+W2J5Ar5Td4j6ivlam/zbCLF2Ro= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; Received: from [172.29.37.68] (66.129.241.11) 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.679.5; Tue, 1 Nov 2016 15:04:53 +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: Tue, 1 Nov 2016 11:04:48 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <89B7215E-505D-4EEF-94E6-DB9B7CC23A8D@juniper.net> References: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> <20161101133240.GK1581@hanna.meerval.net> <20161101141229.GK1589@hanna.meerval.net> <20161101142807.GL1589@hanna.meerval.net> To: Robert Raszuk X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.11] X-ClientProxiedBy: BN3PR10CA0009.namprd10.prod.outlook.com (10.161.211.19) To CY1PR05MB2507.namprd05.prod.outlook.com (10.167.10.134) X-MS-Office365-Filtering-Correlation-Id: 68f39adf-2c3e-4b94-b1f6-08d402686fe7 X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 2:2wP99zcf5bu4TGZXWmk87T0shUji5BRC0trOkT+Ga3SP0IcuFxZyZAiZUITH6shhu6d+/MDOQwJ6+EAd8GZg5xOTlyC7r3gVa0jSzsOXKYc1ufqxYE0M/AL2rJrYJbNXzZe5KVNgKHdTOL+www+BrKTatFnxjhE85V8Gl8G5oG7dEmXWFCNVA21IR/hue0Lu1vs8G+R0YxhwooXbI95Viw==; 3:mnOqf+KJDs5XRvp/IZ6SvdMbjUaY/wTugbYEuYhEqXoOTOzrn2ButeqeHJxOr1GnJkg7+PrpW/ilWygcJVcmuLPdyK5sPDkPBP9rMbsrqMByleMi8kd9+pQMZxpt/9HZlUufNUdkt31yiqLCKqFA4w== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR05MB2507; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 25:zSp4DASLirlITVxDxbom0LmZzgWYJRGNnQL2VCAsAXiUjY+tOiiAFyDQsEN4YrHVzYmnYRX5/zMF38Wsu/zfChqDRfJum3nAe3BKxC7nnS/gS1l9vEefroqmfw4nWy065LOY1S3AQDFGaAMdR7AL1jE5ETpdpP8R68hGREwriHNNJbGrcmoCTmCU2Pqw96RDAOxAcP/0/XVPkbbuBd2Qlg03FicAzI0SeBMrkEqEhwkmf5ZQTtqW3UZFi1tocFqeaEkNS/WzN6U8Kjo3QeGyJshKWMfK+7qcVhIcyqC/KNIwKHYvRWlfv4G9I8paWwZaiMRUp5BmfPgfmYhAFWElkinpyYPHteKL76pRP5Dx17wZe8T0n8pY8+pBsXx6Y4ZuDsBBm1zjaxrq5V2kIktw3o527EiUPJTRpRG0LmX/PTsulYM8csruTqcHnp/cpsHHUYCvASwz5eYiapQeZzazRYwQ9ljIzjB3z9WOPquLXAUe4hdfCHNc3IKoo/jFl85dxxiWn9XpxVG0OKiH0Q/XPaZrySJSD4yLSr1jtMxnvkQm8Xk7Cyz/8OcSm6m0qeguvdfDBgD72+ZW4fBKt+YEFAMTr7S8yKFb7687XN+oYaJC/oHTpm+RhWb2o4FnugkNODUdhB/sCTmmzcaqzx4ShDW1YzGTBHE7twCy2GvokgDXpDAUDyiU9oWlfXOQnCwQyXecDK7EohqYZWHgUIHPWR9eW7hV4HJclG2Bf0XB1JZiD4pv0U2RErXZGddF3yLZosasI36CdfWuNcdfLjOU41AUrhahl1hzo3y0SkacrahqolGcMFNHreiPmh+NvVYek69Oe1Ndn9h9zdeVASMV3g== X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 31:R1qIl/A7X6t838WF96Ia4KG6VRMr1kxY49g9jH62E+rRvR9YmhaXpukiczaQSBrqvZ9xEFyzCnzFkXRomxS95NyjOFlISIbX4s4U6ZW0OyXlFkT0RwD0lN2SNJqJn05jVJhxGPpPdKWr8bRwP8gTkQ5by+g6wUMMefgZU/tJTeZFntOirJ1j9yqrDnvo+gVfBtnTmuJig7csijKHTICTn10g8HLFOja+sPmXADJKqrWw0wtdKZxbAbFJmkMT3pBJWRAEqDvniL7OGfEbTVGpKw==; 20:GYL31T697bI5eCzRQetpztQkaKMQ43lQdHKDtnzwgLRAnuDlLvN2ogAZYzihIrDAtHFiOCj5JhQLr9XhVmZL+Kt38hL/4/5F0DA5uzak09U4JCV+aZcU7aipIf/1J9wThpznNaYgpePgVsneG/shjtDmqcRFt7OkJMzvrkPX4tpuEuv0CmoIugZqDLGB0lArWKbcvIrm27qqC6cuUPZ4Rv1LhAHjcoCQmL48I5XdcbW0/fZBwaMPS1D0TIcQYSz47xQd4unoA5aAv29UM2OQN9U/yD8LpGvlsP2jbMR3qOrtk3pTyf0f3gy7TtzSwH3LcqWWVpmDBhE/s+uReVVhpthME6u5JJyLjjyfbYeZwCBvoQIooyMWWg/0bGCd7Hx5CYoVSEjIOJbfhyK3ZJoeaVMoBG0j7IrouMthYCtD9SekURjHgIrSzEKLlJdf/b0xh0E2QXKI0URProoCXNkdHijxKi1R2xsL3xFzdsG1tNoXbVfRIxga4PX2Mzl1gNPRHfN1ZFRHo5QzJztfQqyoRiHeW6v8zdK/YDWAZnmm4tblfzCmThObe9P0g1A0jsReiR/+RMy0whiwReqlJvUuoMxEsRkXInUxFJcua4E273Y= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(120809045254105); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:CY1PR05MB2507; BCL:0; PCL:0; RULEID:; SRVR:CY1PR05MB2507; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 4:7UsMxTBcUi01KH8xhd47+oEmP/18M3p6eI+ltZusn4Ulc9nf3YRJWCp0XcF7ZZHRQTMeiMRSQzNawBlJzIBxno/r9mPJ3tKsvUMKry0KrHizhuLvHpD62fR8kVKOeWXz9roPO9O8Ek2AjN7HZG5K1TRVwjiYml4emz9+OeecihE8t8dk7fG6KR44FKlfLtvbcQXpbxp2v9ZkNQHArJ8qmP44cotw7MZrQ8lJ38IEZLEm0RpO92mbit10+4CyjHnSA2/HBU4NaORz2NQWlU1dPHUWP1BvALqKPjPJgpDYdF2haP5FMgQvdZXQnlxYaHoPJGkrkuQnaeD9/3LwpHuNkbBJsdj4VKeq0n4vWvvmjfPHB3oAxut9YhEaplMVSV616amMBG9F1AC3xvqbqavHVd//AFpRoM26kZgV3TZ24uVIkK1t725o2Iljahrh/HlOyyDFdg7WZ4r4/UjU7DCfPw== X-Forefront-PRVS: 01136D2D90 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(7916002)(199003)(24454002)(377454003)(189002)(82746002)(93886004)(77096005)(57306001)(23676002)(189998001)(86362001)(50466002)(229853001)(586003)(2906002)(7736002)(105586002)(15975445007)(106356001)(6666003)(6116002)(7846002)(92566002)(36756003)(76176999)(33656002)(42186005)(81156014)(19580395003)(81166006)(66066001)(50226002)(19580405001)(50986999)(3846002)(305945005)(47776003)(8676002)(5660300001)(110136003)(97736004)(8746002)(2950100002)(4326007)(561944003)(6916009)(68736007)(101416001)(83716003)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2507; H:[172.29.37.68]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDWTFQUjA1TUIyNTA3OzIzOnk0TTkrM2w0WmJDTUdEZjNRN1dmK0hGM0kw?= =?utf-8?B?MHk0aXhkWVR0Z2loOW4zQjl1ZThjdmR3K3V3MGZDTHVPeGJwVjVnU3k3RzN2?= =?utf-8?B?ekxmZ1FpZkNhWVVVUTZLQTNRaDJrM01JSGQzRWN1MWVuNGdFOTdZNFJtc0do?= =?utf-8?B?Tm00OEpQQ3htMXVEM1YwSithTUY0Zk5RQWJVMTg0cFZMb3ZLZzZVSjVlcXN4?= =?utf-8?B?Yk1rajczSGhNY1FOWS9tTWQ1eC9DeHlQMFFiNmNhYzhCZjQ0Wm9VaURiWHRN?= =?utf-8?B?NkR4OTRtZzVGNko3R1YxNmpBaFJmUHlXZ2VIN2t3cWlFTDJXS0ZVS1loRXRB?= =?utf-8?B?RThUSUhEVGJUMGYvcERhNCt5alJOdWV3Q0pZcTBKR2V0aEwxellsVWE5MytZ?= =?utf-8?B?aXAvbWs1R2dGRDlrV1hmNmJLSU9KVjVyNTRkaVVEOHF4dk9raGFFZ2kzb2tQ?= =?utf-8?B?Tit1Q010bVhIdlZOOGxLNThBa0JaUkRLTXlBN0I1UXJaNzBpUlBZMzJQQmh2?= =?utf-8?B?a3NUMjlkL0hiREU4U3Uvc3ZpSzhLSEJ4N21zRE4ySEpTNm12cmt4bDhGc09I?= =?utf-8?B?MTl1dFYweCtVYkJxZVlEcVFjd20xenNqRnhIOHYydER3SjJJNFJ1WHlSVi9V?= =?utf-8?B?RWYrMVB5VDY3SlpxTngxTUlDVDhjVHBhTVJvSDNBUlM0Y25jOU43anRIcDFj?= =?utf-8?B?bGVPRDBFSUZUTmQvYnZRMGtCTVhkMk1ld0daQld2T0l6Z2hvWC9rVW1vQzZH?= =?utf-8?B?NGZEZjQvVk0yRWU0TVh2eS9rSjZVRlFvUEtvaXhXTVcwZ2JSS0NEVk9JdzN3?= =?utf-8?B?QVhCT1ZMa1R0amY1N2hwQ2JRMWl1bnNURHRxdmt5bDhxQm9ZSENIUlpDRmRJ?= =?utf-8?B?NE5IM1VYOFdINjl2aXFKS0FUcDFCZkQwL0NESjlhdmF0VjdMeWRVUVJsMkhy?= =?utf-8?B?MCtkZ3owSXVFVVhLY3JzZ3pneEp3SnJXZnhMcTZHN0s0L0tsSE5LMHVPV1Fv?= =?utf-8?B?K0ZIYXNPdnhIOTRPRFdGaFQwWmdLU3Ivenkrc3RiUi9BSTNwVnNWVzdGVng3?= =?utf-8?B?TFFGeGRhRkEwYnFoMHI3c1AwdlF3SEwzQ2FlOFdhTzNTVVpQZUNnQ2d5eWxn?= =?utf-8?B?ZmdvV1N2c3hQeHBYMk5adksvYWliai9KeVZjaVcweDZCYTI4VE53MzkxOWdZ?= =?utf-8?B?SjdzRU1pdURlam9ydWZwQ2xtRmJCNTZadWppTGtGZUppNi9rR1FaOHhPdXIr?= =?utf-8?B?R0RMbXJTRFdxdVg3cDk4aTR2TUZnbWM4QUZHay9tNXNmYU10OGVOUTg2Z01i?= =?utf-8?B?TzZRcWF4eWV3djZ1bWx0ZUVTbjUwSHUvbVdjWG9OWUI1V2t2SkYxVEpOSU9x?= =?utf-8?B?Q1E1dURXT253Q2hkYWpuVHh5YlJtZUx3VDdrT0NtdkVZQnFkQ0RLK1BjYXdU?= =?utf-8?B?NnUxZXpkZElxbm1hcXAwZ0pONGFUbWJWMXRpaTZKbzN4YUVIeUwzUitwZThl?= =?utf-8?B?NjNSZURwSmZqU1l5dFVBc3VKMWt4NnJIOVB2Z3NOUWJpbEEzbDJ3OXR1SldN?= =?utf-8?B?Q1FwVC9uU2lSS3lvNWFNL0N5aG92WGJxL3NuL0pRME9NVGlSYUVrblVnRi9K?= =?utf-8?B?bzlNMHR6SmVjcGNLbFl4Qm9kMW9CUkhNcldpUzRzcmJRNjJnYzdxNjJXZVRo?= =?utf-8?B?QkU1TGpiVGpCbkF6MTdNV0tXS29NWlZDaGtpeEtJNzlVYjl6UThnWUhXY2gz?= =?utf-8?Q?XopQazQizHXhuo8rFTj2sBa5pLT9+yQ3+JDrc=3D?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 6:i49Qy3pJ8mKWsdC1JZzfMU+HB3mPt51/e4WB7vSZFQsHuN+o3iwlsaLBNTOa56XwMiklKhWPJzmIYYrzr2rniZPiWKLPmTM0xpcwozwQ5IkCOdFrZpHWoC5mn38TUylppDQ4Y11Jdu+76bYHvN32RoPb3tP5O6JPFZrTu0F0YVGRuMJpYfyAfH9kRUh3PUtVYtgzsz0+oHRE2dGjM5314vnJfT7rLmIzNfcNfoKhhVbuvGEHcpIYqpsEWikzsJ1t5hkFwQuizpan/RyQrEiQ0KaChS3W0Pao81pKYCvPAKiNwgwUee4Q77O+3IKUEzkZ8k/SeArQzxvdSZuEOQUtKlXh9X748ESNzq3N/CHLG3I=; 5:rAm86wEs6su08g9nWMMPWr3KvlB2nWMgOsPysn3VLyPCouecm5cgyIFgGsxo9ig5kSoWyGFVMU+EzsvW8w6NcWlioXwC80gDYnon2thCD5skonefh4mkxNhz8KvAzQOMsjWrY9oquUXIu9DgKHVMeWdRMv9ufMU9ulGKWFO7mNw=; 24:UqXpwWhBM8nvN0/c2egGj4/+DfbMUX6MEMVvchpLz9q464IsGcAkeZ2EfflmQ9967trNHDXZvbL7PAulmasQjeAuZ1vssoIl77B9vUzE1XU= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 7:rSB5bx6GQ5O0yMoYDIp1Z8mkpUepQe5G97+//6+YbMCBVXO15BI9chwmWSmzuFT2xQnXqB+Wcr0Oj3i+0K47bBWQUoWwSbGenmIY8ER8Qp3+/koUXNXobzU0+sLVYEu266z25NeDkt4U+3A280hCVMDRN+LEtV+8T3hoQh9aPhpkU/589SZMFPMiG/lRSKIakZgkuErEhPISO5Xw0GWGzdp/Egrk1OZKrVFLim3hMkAYmsWjnT27CCJnKpo4jc50xW8d0X+7P/2AIes2tDTlz6KrGnWDASuQyob/q8ybpQ0DvD0+wDLV8dGIFP+jvpn/tQM0z3hbhA6uKFBHCfIsxN+M34FdAJT0dHWP87KcCts= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Nov 2016 15:04:53.7217 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2507 Archived-At: Cc: IETF IDR Working Group Subject: [Idr] Early allocations and other ways to avoid squatting on code points 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, 01 Nov 2016 15:05:02 -0000 I have changed the subject line to reflect the fact we are off on a = tangent and no longer relevant to adoption of the draft in question. On Nov 1, 2016, at 10:41 AM, Robert Raszuk wrote: > =E2=80=8BFew days back You and others complained that Wide was not = implemented by anyone for so many years. Now when we see it actually was = implemented at least by few BGP code basis =E2=80=8Bit is again bad.=20 I'm not sure what you mean by "it is again bad" but see the message I = just sent -- we were not asked for an allocation for the code base in = question (not sure what other code bases you are including in "few", I = think one was reported). When the question of early allocation for wide came up recently (I don't = recall if it was on the list, in private email, in conversation or what, = sorry) my feedback was to ask whether wide satisfies the stability = requirement given in RFC 7120 Section 2 (c). Certainly if there is need = for an allocation for wide and it can satisfy the RFC 7120 requirements, = let's do it. If it can't satisfy the requirements, read on: > So to me the problem we need to solve is how to allow early = implementations for any proposal on the table especially now when we = have no two but at least 8 production BGP implementations (and growing). = Forbidding it does not seems to me like a solution to the main problem. I expect we will be discussing this at our upcoming meeting, although = that's no reason not to continue the conversation on the list right now, = on the contrary. Jeff has also written a draft that tries to address the = problem, he posted a pointer to it yesterday, = https://datatracker.ietf.org/doc/draft-haas-idr-extended-experimental/ Thanks, --John= From nobody Tue Nov 1 08:10:55 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 506061296F8 for ; Tue, 1 Nov 2016 08:10:54 -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_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 dnOuQ_e_pb-R for ; Tue, 1 Nov 2016 08:10:52 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0135.outbound.protection.outlook.com [104.47.41.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96E9D12949B for ; Tue, 1 Nov 2016 08:10:52 -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=+sRNrZB6tkCjzuB5C19Xd3DZtxZRYjuNmIekzqwPEk8=; b=kjNhj4+Gr8+lFcEu6M5zYQEAassIaWjRfZ2kgHaOykVguClLiZ8aGh7jBlSFd70jFX1aEUMLrPYrks2I6XiXDnhodCK93WQ/fw7ijZVzgBj2uFqJJiwjykq4VoTdgw8paHBz9caebKJ0JZIC31xTAK2LFTSISUz5PhAy8ozcIV8= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; Received: from [172.29.37.68] (66.129.241.11) by CO2PR05MB2502.namprd05.prod.outlook.com (10.166.95.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.5; Tue, 1 Nov 2016 15:10:50 +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: Tue, 1 Nov 2016 11:10:45 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> <20161101133240.GK1581@hanna.meerval.net> <2393790D-F279-41ED-B5B2-E427C60B4926@juniper.net> <7FE93D56-DAB9-48BC-A577-D48E48E025B4@juniper.net> To: Robert Raszuk X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.11] X-ClientProxiedBy: BN3PR10CA0029.namprd10.prod.outlook.com (10.161.211.39) To CO2PR05MB2502.namprd05.prod.outlook.com (10.166.95.148) X-MS-Office365-Filtering-Correlation-Id: 744eaf78-0a6f-4822-9892-08d40269448a X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2502; 2:UrGsyeKDqYWhQMY6Ra6v5AhYwTnHEXYacInVF7fMZpRNZUBLjCopFemPBJH08YQERdkjmKqriC0ekVg/l1KPLQFUY7HUUJsKq3LxMHn/fivQKOXlhkEAQkeiPA7NsbEe/B+hp7B6Rzc3PwagVNHncmtV2KtZxIkwi+xBg3tbs0rZ79jMylKfEbUhSQl68cXPrExCycdrheK/riIk1SF5SA==; 3:hEg3iG6AlymCQspvc/qfluRLQTLQgYaoFnw9qwxCtoLDUqeBcLoLMLFjj+/SxvfXijJCI2ygaYULgnhJEvB7sa7JEhBFi4d/e/XgH5vdH9tiRaaucsr1urLp3DI8AD+l1KuUMvFl1yOjoAfXu3vM8A== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR05MB2502; X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2502; 25:az9e5yjqU3PlxpTZrsgNb2kCxf98L+hlQ7QvvurVeGzohzsBjwCyHulZCksXzTHC46nwOvAG+zmbJKkFRYL56QQJN1qbu/uDEELmdM0AeqeGXumoyLHOCQ5fPwctFtiCVzjoD7hmQ2nvWTeqws7Eat2bsbeOANqo+2W/mfmQIqGKUAZ09hgia062ZHvZlaYA2vdxajrJqEYfQvyXnTF8NTJRlCcXHM4HIL+6/m8P2xhE0IIT/wHTZohIxk6aNTn9YJFCYcWeXvu4DSNNjF/ZfjUz8QTlaI2hSMDhwwL/MbIQUTbYGD4g8rr+qzhOOAbyZRpNsAVyqd8A/KQjy+QDI+2uIqPPSKGdfPMo9wBBCPhg4cfWhkdDWALPgh4ZUHmGdkD/IFGvssyW7jjHgnAuzXO4k6+BLWOqo7Ij7hxHLWXjKljwkYGYzJgy8wvD6Ig+klOUJnVpvRlHeStin075BE9JwVl4slsac9wzXViiW2gRTHwlbPdjzHeG0dbXqInpySr0kNrD6p4lPAnUCxmbAmOc73B5gqny6qWrfgIPijKPMNQ6AxxdCRhbcTHO0kinYk3g8s2JLixSioo3W43YfxBkT59+4wuq6Ja6Q9XFqRGO1sZ206ml2FV5pIX/nl+Jr49H/FXFXjy4qrgRP4Mn+m1aqmLNnWbEnQcXtWtPJrrWh4g3cTRLhHVJDnOVmufMq3zwEh0GRHvfavyHZBdjHkTqT8w7FlPxAPmk+qYqUsaNDI5PbkeYhzneI+tD+4JXUs/pbKS7M1g6fbhcGOVE9bvy04R3vDXR0S4w0KoATCEkfaemiVI5rpw0jQIOniDrU3YGc/P0niUOZ0oxrb7YFw== X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2502; 31:EXLV5gzIIzrQKTsmH8BKNQXCU2feK/BeoOJfNSUhbfoY6qA8aeznTUvIXi2PbgzgOB1gD+CrK2rP4ny+q+fmBGnFDQLPtZ/zhyVJTeDUgB1+jOpM6cRwjW/5ezj4Oa4HwsiGd34kmzpuTkFa+mAYTC1RJTNK4KmbBE8Jc4n7UbvO3CwY4J5JK/dfurbaPyNlcBiK3vsIT5huC1LniHhiVDIBQEuHuRPjKNO0hYDe8oNGAv9fU24/3uRBS+r9klua; 20:S7DJTV0SmJf4UZhy8qHdZKPgBpKGFggZueWYgHSZeUp0VzgysrKp8DvZuWnNh7HGSjXbU7kEHhZnygaEzuhoS4Kjmu3L7qM5Afb2nueBBfbrA2yYtvNmH38dRBpio5CKPB6wNwWv/u8fv6sn0prRyNF+PZtr3CfuzPuiB6l7s9y5FjXOPBu2A4JHspXOZTKEJB2ZZ8Usxm+mAvQ16t1ZHfbmFAes0nXCikQ30qacZfuszrXrw3nZb+ouLCS3gFBoeJj0yRc89BR4sofL6e8iWJP+ChSXHHj6D2VSD24HUm9uk4GX6eCBXKsmx/QvBykw8nd3AstxJURg2zPPV1QbP/5MLTYyyQ5Mka2MbhUjS0o7aqji8IDUXESwfcg6HqdY7QpV4hgGJ1kMPgKQjwUZw0EjqTirdRv+olqiU+hsJos5xel9H8P8uHVSTk43UPRwMb60zdimCZsDHMa2m6ACGUdlchXqMK7aI07+cFtLH7BaHa0m1FZrs8cMfGhMXaHQPx5LAWvhvNrd4wgHHe3rM2xAAFjyNlwZ44+LjEHtQ2nQPB+QfNZNFgCrfwIR6WVH3L3OgU5JvXCgnURbnjMyujl0rjj/4WgnXSrA2vlGXKg= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:CO2PR05MB2502; BCL:0; PCL:0; RULEID:; SRVR:CO2PR05MB2502; X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2502; 4:TklHXs8O5+uy4UptfMvhBnRXTEdbKOgH5zWe82sPE1xz64wh5cI8RAB7NCs/37L0YQhrYcdNI8Ecl/jJFO27SnLBQ4oYawv2HtHmPl7zFTuV8jKwWIQsdUZ35oVwp1ofHPmOcZ22wxAPXESvlff4F8zDasboxvcDjZa2c1dN8U0Ts+Uk/qv9lmvAYNyu8ZUZoY/1bp+PlMETkrOD5S724zvQyzzDgQl78PTLMkMo87Nd9Lq+m8hKZ1Jb8DFMq+a1RM/VNlNw6YEEIxGXRiNMRvnZRLm84c1p/tIe4PVud9oJ8GgJC+/nhs/pWeTWtKbh4k+mVHI6LWNq5b1Q8bzpMG7U5zEeixu2PW6/BVTyX//aYwehi8x2c40pwnp49BLHg0ZNwWSD+m3xWJJQlHcA9bgCo/jPK4FhtDBqi1q/4Qc= X-Forefront-PRVS: 01136D2D90 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(7916002)(189002)(5423002)(377454003)(24454002)(199003)(3846002)(305945005)(81156014)(83716003)(8746002)(6116002)(105586002)(6666003)(33656002)(76176999)(50226002)(101416001)(586003)(19580395003)(19580405001)(93886004)(106356001)(57306001)(47776003)(50986999)(8676002)(42186005)(110136003)(189998001)(6916009)(36756003)(68736007)(81166006)(50466002)(2950100002)(97736004)(230783001)(66066001)(23676002)(7846002)(2906002)(92566002)(5660300001)(7736002)(86362001)(15975445007)(77096005)(4326007)(82746002)(42262002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB2502; H:[172.29.37.68]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDTzJQUjA1TUIyNTAyOzIzOkhQMGM5MllkR2s0OXRWc29IZlZDOHpDN3FK?= =?utf-8?B?dGVqWkRwK0l6RTBpLzM1WmUyZUI5UlBDSk1VZnYyc1lDNkdPQnNWM1NiNmFE?= =?utf-8?B?Wi9iMG5HQ1BEa3dwekdRY0N3dkpkZ0dKTVkwaEdVK2g2eHJzbDRUa213MUFk?= =?utf-8?B?WlU2WjNoYzZDS21UT2h2aDRDMi80ZENxSFp0NzE3ekt2ZlFJbGNaSVdhVWV0?= =?utf-8?B?N29zaVRZeGI4ZUgyUUZNMG8xS3RsMHZxRFpHSDNTYjZ3dlJ2RE91eUJOaXZF?= =?utf-8?B?b0xnNGJsc3dsVUw0akpzZDJQcC9RVlNMd0pXL2ZjTm1sUVpSQ1g4MlNOQVd4?= =?utf-8?B?ZjFZdGVVWFRnaGtVZ2t3VmowTnFQYVZ5WUdXVzh3bHVuVWwwNEIwTGkyeVdl?= =?utf-8?B?YWFDUHQ3cnlvalB2aVpuUHRnSTJ4b0JXOURiTE1tSFlMQWd2bllnMDV3WVlh?= =?utf-8?B?SUhUM0VpT3pscVoybk9FRWVwVXJxUlRwOTM3UlZCemU0bE1BdVBMajkwb0tI?= =?utf-8?B?OTEvSjFqd3VsdUxDbGZseGt4R0dwNDhTa1RYbWMxV3c4SW01UDBKdXF6aFgw?= =?utf-8?B?My9QdjZZYlF3YUxXNGNERHlOd295b0oxNk5UNFkyc2hUTU0yNEhYZSs2RjR1?= =?utf-8?B?TGJHNFFHcGNVcGFuU2lwOXdWd0ZpSzRmVUxYeWp2K1FWQlVpUjU5NWRzVzd3?= =?utf-8?B?U1BUbUtDcUZuK05UVTJSZXZnUW5PaFN0Ry9JTXJ1a3hUeVdFODBiU0NPbytM?= =?utf-8?B?bjMzZGV2ejBIT1NOYzd3REtVTVcySWFuTFlYTHpDWHRPVjZTQ1pCTGMwMGNN?= =?utf-8?B?bUJGTDVTQnpmVko0Q2kreFNpOStsNEtrNUttMnRxeUY0TEFvQWpobnUwZHA5?= =?utf-8?B?S0NhaVgyWkNVd3JvWlU1azVPMklHS0tYZzFaK1g4OFBjem4xUHJvRVdDVHdW?= =?utf-8?B?QzlCak4xZm1UMnpidDNOME1vbjdnSEpOZGpmTjJ5TUY5N0ZwRnFIWk1rbVB6?= =?utf-8?B?bVV2dmpNWmY1elVVVWJQdFR4enoxVzhERlZjNmt1K3FSbEtjYzBoZUJqc0k2?= =?utf-8?B?MW02d3NmSjN3OTdaalc2Qm12dm9KWWxoREQrckxPMmZEVnpqeGMxaC9tTVNm?= =?utf-8?B?Rk9oSTkyalVlc3FNNjBDSUwzbnpjNTk3WWRYdlZlZUdORHVJL0FmYTBCSHY0?= =?utf-8?B?VzdYVUE1UmNKV1BSSzlNU2ZOb0EzdDM5eWlueHN6NDRnZjE4SSsxZ2lXQjVi?= =?utf-8?B?TFNBWkxENEVZUWRqdk9hWVFVZ2Y1Qm9hMUZBQ09rc0N2Nm11cWEwYm5QaVJD?= =?utf-8?B?WTZ5aFBUYTdCajlORkRWbEtnUnNHTUJ5R1hRTXdKVWMzaEpTSisxQlFmcmd1?= =?utf-8?B?Z1FFQnlpNlZabEZ2VGpYMVFjdXlUN0ZURE41MHJGTFVsRk9xUXk3QW1uVzkv?= =?utf-8?B?ckxqTWdvQk1rNit1dXhYSlh5UVJSVytTV1BxcVpqekJIcGVPdlhBQWpHaGdN?= =?utf-8?B?SW5kalFVa1hVbVBZbUNoK3RRQ2htOTVKa0FjeXZUU013YlMvSkdIVVhEbnBX?= =?utf-8?B?MmNNa3pZRjNtaWxLOCtwaDEzQzMvME9GR0xEeCtpY004bkVjRTN0QWVYRE1N?= =?utf-8?B?bTBJSFBwOTdYaEZSY0s0cE5yZmxYVmMwWmZNZUhqRHducCtPZzA0d3V3aHIz?= =?utf-8?B?QkVZYW5EZFU2azkyVDdSaTJXeTF4WGx0b1FLQ2dRSWcxdkhVT3I2b2MwdzFw?= =?utf-8?Q?CWqbRINT8+ubbVI78Z1sAFdKLp0LGemTQmWwI=3D?= X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2502; 6:2lzF4gaXcxJjOjJfiXf+zmB+/jOerP9YClqmgRjI6wQ4tgXCV8ZiCc/UNGEW4D4fwpjFCwGESd+jocNtqRmfLIOAjCKniE1/LmrnyA5DMPpC3bVFet3AYsK95j2+OVUbgnUdXRCDFZfapneYBR/keYPG/eoogdoYWv3V9aQf1IRFJBlAQQLptdfakD9t839+s1Jz0tML8YAu++j5cJ138ZDJd1HCRaT/rc3/FRueRIvpK+DbQDxkRPijQaq7kugT79N6HdFGy+rN2o2qNmUHrSJD7JCNFmBeSZdpwlqErMx/QEjjtJrv8d/L4S2EnGHd3McnbVa6LJOSkVhfC0XrXUzwHdC0Q8qvgPsuUJqqpx8=; 5:8Jgn8yNHJf/v6pElBwctTXmVtb8iACEGpxxc6y2FpdjvQNKnuJ9l0Si5SnlAFuNTF7oBYnm9kc8DE6AwD31Sh78MVhEYNiS+pXaY2MsVmdWxPIP239ygApnbO3KVcmic7mn5M1spwvYqx31eUKIWAi83a9wiPpHOCFjeAtHh1TM=; 24:XQom3jXvrjGgpj9cJ97fjnGV5W1hOqq+Ch+WwVvCY915S1Gdb6IwSW/itgIu2MF59n3KFnAQfCCcTo0lTVAoXlvrGB4hY2o7GGp8//u/Pf8= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2502; 7:yqQbmWQxMWA+weAlYQBslnYsKhnKslsPCQ5N7TamVAiwCejPw9LT+/aYJISRQRMLf33jQ9FcUtpmujPRinOaI0zAbmDPaoj2EnyuhlvoHOcGAmKdnizq4NuaAitKbt2/k66hBq8cVeSNGkNpMN2psIp6bDmLA8NJVDYF0w1rY9a8PLc2txo5VfMS/fCgadE3EVtftgNnIPOkh1kksLm4DkK4b155WpJHB/SMUtt0hdWqIFo1vt7ZbW2balUYZ4qDi+uPu7lTM1PuCCRoGVzN9wkkGVJh1igqG/ap/5khuUffISBv8ORvEwpNbkf8oCaw9eGzwUrltHAqTCsV6Vqwuowv392kNEqw6NBDwLr0XTk= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Nov 2016 15:10:50.4072 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB2502 Archived-At: Cc: IETF IDR Working Group Subject: Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129 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, 01 Nov 2016 15:10:54 -0000 Robert, Let's not split hairs, please, it's not productive. You can see as well = as I can that RFC 7120 was preceded by RFC 4020 which is substantially = similar for purposes of this discussion, and was published in 2005. --John > On Nov 1, 2016, at 11:04 AM, Robert Raszuk wrote: >=20 > =E2=80=8BJohn,=E2=80=8B > =20 >> I'm not aware of there having been an early allocation request for = any of the code points in question. >=20 > =E2=80=8BWell I am not sure how some of the documents in question = could ask for early allocation based on RFC7120 published in 2014 if = they were written and published well before that date ... >=20 > https://tools.ietf.org/html/draft-marques-l3vpn-mcast-edge-01 > = https://www.ietf.org/archive/id/draft-vandevelde-idr-remote-next-hop-00.tx= t > ... >=20 > Thx, > R. >=20 > =E2=80=8B >=20 From nobody Tue Nov 1 08:14:51 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF3D127076 for ; Tue, 1 Nov 2016 08:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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 XHeg7k3Z9Sx0 for ; Tue, 1 Nov 2016 08:14:37 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B24601298D3 for ; Tue, 1 Nov 2016 08:14:32 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id u144so16136335wmu.1 for ; Tue, 01 Nov 2016 08:14:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=vT0yF55fZkyhdgBP9FnP9bYABP2Zxra+FlWzpKBZ1jM=; b=dDlgLYNUKutQw3XGwgvKVx4jdqTWLqT6GP+qenqN2TD8p2+oVfOlZ44rkXaqYrSQXa IlFVnVtuwvF4ziHMXmmCIgngLRKdu+3x5YIsowT8heD6Fzca2suuv/2z2XSUrgEd2lii uVYkh4/I/dx4s9gyctBEiJOtHysr/U4VtPweuC83JmsuY5HNE6M1jFj5XR3wc3+gTRem UwK/C3g4uYBlZceHO1vEa3zmoPMbJgHvHLU7VPTinPGz83sbZTaCyljBjbCUBm60WLS+ 443zmAAgiVehZWww+hj0JRDnJS1UKJs24IWjC57S2UROL7zoEenzrUOdJDiwRV8XrxFq Yz+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=vT0yF55fZkyhdgBP9FnP9bYABP2Zxra+FlWzpKBZ1jM=; b=Jx0XywuyvtraFrUVZQPDw0ldzY+A4ZjtR0SiGpXgKd7tgWqvRMb77R4XpTu0ELSqXC LFzRINU/0XUA2niZU4vzX8+oeYTqvoFf58c/Xh2Lk9qti4R8ENGBVsqyxKMEIRo5j3RQ z7fw8JBnrEO4qd6IK/p4nkTT2mPlr7Xp2z0nXQ/S4rDu+8tQxFwAcLeu3nUJnoWgq2Q+ NR+ZQP0S0cMq6+V6FRIN/q331Ibwfh6dtj81skbWCj5gGhMPTxNxY0bPXZLXyiIF/YOk haljab+W7NQo5BLR0YOgiBZrRbImacErJq+3SQ4lzi5bXlw1akkys7DkWLl6h8QNJKxU FHcg== X-Gm-Message-State: ABUngvcm+8QCz/ZsVyZds6FLc1pInBT2dVYvRRkJftRJ5G8uDOzCwdjMp1DMGaD6LW8zE+ZOv2e8dRHGf+RBhg== X-Received: by 10.28.185.203 with SMTP id j194mr1895380wmf.73.1478013271226; Tue, 01 Nov 2016 08:14:31 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.80.137.69 with HTTP; Tue, 1 Nov 2016 08:14:30 -0700 (PDT) In-Reply-To: <20161101150148.GM1589@hanna.meerval.net> References: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> <20161101133240.GK1581@hanna.meerval.net> <20161101141229.GK1589@hanna.meerval.net> <20161101142807.GL1589@hanna.meerval.net> <20161101150148.GM1589@hanna.meerval.net> From: Robert Raszuk Date: Tue, 1 Nov 2016 16:14:30 +0100 X-Google-Sender-Auth: 7X5iVcULE3FK-fI9yPNrpPx77Kc Message-ID: To: Job Snijders Content-Type: multipart/alternative; boundary=001a1148ebca01445105403ec8e3 Archived-At: Cc: IETF IDR Working Group Subject: Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129 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, 01 Nov 2016 15:14:39 -0000 --001a1148ebca01445105403ec8e3 Content-Type: text/plain; charset=UTF-8 > even if the implementation is compatible with said specification Well I think this is completely different problem regardless on how the types/codepoints will be allocated. > Maybe a pragmatic example will help clarify the situation: If IANA > assigns Path Attribute 30 as early allocation of > draft-chen-idr-geo-coordinates-03 That was not what I have tried to express ... I suggested to assign all detected points to the drafts they belong as early allocation rather then to deprecate them. Result is the same - geo will not be allocated code point which is already used. So is 32 final code point for Large or early allocated one. If what LC got is final one why geo would need to ask for early allocation vs final one :) ? Best, R. On Tue, Nov 1, 2016 at 4:01 PM, Job Snijders wrote: > On Tue, Nov 01, 2016 at 03:41:12PM +0100, Robert Raszuk wrote: > > > Am I to understand that you consider deployment problems not to be > > > technical problems? > > > > You stated clearly that Large is not subject to suffer from deployment > > problems. So what other deployment problems you envision if those types > > would be moved to early allocation by IANA? > > You might misunderstand what I intended to convey, my apologies for not > being able to articulate myself better. > > Large BGP Communities was assigned BGP Path attribute, by IANA according > to the Early Allocation rules (value 30 - 2016.09.26). Turns out that an > implementor had already used that codepoint. This proved to cause issues > during an experimental deployment of Large BGP Communities. Large BGP > Communities had to back to the WG, the chairs and then IANA assigned a > new codepoint (value 32 - 2016.10.26). So, today, Large BGP Communities > does not suffer from the squatted '30' codepoint, because a renumbering > effort was undertaken. The above is a description of a deployment > problem and its resolution. > > In short: any new (early) allocations should not come from tainted > codepoints. To ensure this, IANA needs instruction not to do so (that is > the draft at hand). > > Maybe a pragmatic example will help clarify the situation: If IANA > assigns Path Attribute 30 as early allocation of > draft-chen-idr-geo-coordinates-03, I suspect the > draft-chen-idr-geo-coordinates effort will encounter considerable > deployment problems. This would be a waste of time for the authors and > implementors of draft-chen-idr-geo-coordinates. > > > > BGP Path attribute codepoints are a global, shared resources. As > > > Internet community we have vested IANA with the authority to assign > > > resources from this pool. The social contract is that we abide by the > > > rules related to IETF and IANA. The same rules we write ourselves. > > > > Few days back You and others complained that Wide was not implemented > > by anyone for so many years. Now when we see it actually was > > implemented at least by few BGP code basis it is again bad. > > You might not view it this way, but I am actually looking out for Wide's > chances of deployment. At this point it is not known which version of > the wide draft was implemented, or even if the implementation is > compatible with said specification. It really is in -wide-'s best > interest to _not_ use attribute 129. > > > So to me the problem we need to solve is how to allow early > > implementations for any proposal on the table especially now when we > > have no two but at least 8 production BGP implementations (and > > growing). Forbidding it does not seems to me like a solution to the > > main problem. > > But isnt the solution simple? I think early implementors should just > request an Early IANA Allocation and follow that process! > > Kind regards, > > Job > --001a1148ebca01445105403ec8e3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

> even if the implementat= ion is=C2=A0compatible with said specification

<= /div>
Well I think this is completely different problem regardless on = how the types/codepoints will be allocated.=C2=A0

> Maybe a pragmatic example will help clarify the situat= ion: If IANA
>=C2=A0assigns Path Attribute 30 as early= allocation of
>=C2=A0draft-chen-idr-geo-coordinates-03
<= br>
That was not what I have tried to express ... I sugge= sted to assign all detected points to the drafts they belong as early alloc= ation rather then to deprecate them. Result is the same - geo will not be a= llocated code point which is already used.=C2=A0

So is 32 final code point for Large or early allocated one. = If what LC got is final one why geo would need to ask for early allocation = vs final one :) ?=C2=A0

Best,
R.


On Tue, Nov 1, 2016 at 4:01 PM, Jo= b Snijders <job@ntt.net> wrote:
= On Tue, Nov 01, 2016 at 03:41:12PM +0100, Robert Raszuk wr= ote:
> > Am I to understand that you consider deployment problems not to b= e
> > technical problems?
>
> You stated clearly that Large is not subject to suffer from deployment=
> problems. So what other deployment problems you envision if those type= s
> would be moved to early allocation by IANA?

You might misunderstand what I intended to convey, my apologies for = not
being able to articulate myself better.

Large BGP Communities was assigned BGP Path attribute, by IANA according to the Early Allocation rules (value 30 - 2016.09.26). Turns out that an implementor had already used that codepoint. This proved to cause issues during an experimental deployment of Large BGP Communities. Large BGP
Communities had to back to the WG, the chairs and then IANA assigned a
new codepoint (value 32 - 2016.10.26). So, today, Large BGP Communities
does not suffer from the squatted '30' codepoint, because a renumbe= ring
effort was undertaken. The above is a description of a deployment
problem and its resolution.

In short: any new (early) allocations should not come from tainted
codepoints. To ensure this, IANA needs instruction not to do so (that is the draft at hand).

Maybe a pragmatic example will help clarify the situation: If IANA
assigns Path Attribute 30 as early allocation of
draft-chen-idr-geo-coordinates-03, I suspect the
draft-chen-idr-geo-coordinates effort will encounter considerable
deployment problems. This would be a waste of time for the authors and
implementors of draft-chen-idr-geo-coordinates.

> > BGP Path attribute codepoints are a global, shared resources. As<= br> > > Internet community we have vested IANA with the authority to assi= gn
> > resources from this pool. The social contract is that we abide by= the
> > rules related to IETF and IANA. The same rules we write ourselves= .
>
> Few days back You and others complained that Wide was not implemented<= br> > by anyone for so many years. Now when we see it actually was
> implemented at least by few BGP code basis it is again bad.

You might not view it this way, but I am actually looking out for Wi= de's
chances of deployment. At this point it is not known which version of
the wide draft was implemented, or even if the implementation is
compatible with said specification. It really is in -wide-'s best
interest to _not_ use attribute 129.

> So to me the problem we need to solve is how to allow early
> implementations for any proposal on the table especially now when we > have no two but at least 8 production BGP implementations (and
> growing). Forbidding it does not seems to me like a solution to the > main problem.

But isnt the solution simple? I think early implementors should just=
request an Early IANA Allocation and follow that process!

Kind regards,

Job

--001a1148ebca01445105403ec8e3-- From nobody Tue Nov 1 09:20:24 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC1FF1294BF for ; Tue, 1 Nov 2016 09:20:22 -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 3pN_UEp5PG_9 for ; Tue, 1 Nov 2016 09:20:21 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0090.outbound.protection.outlook.com [104.47.36.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1599112946B for ; Tue, 1 Nov 2016 09:20:20 -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=36EO4smPZjAIWU4x8kSRIuZa+/7TMO8h4G46pJcEy54=; b=ZVFfG0KnKnh5eikOWisVXlZPfl9ORkj/pBiiWuby2+51MT7aCiMuKzqiLTdh5x9mRer6HpdLA3SM9Bl1U0F9w+r7Ed7w08nmiGCSDzafP99X7dBGpqyDTHJEPO3bzmeJLyE/5jkzCGp9K5vYXXu5mteN1BsCs8ua1wbejYp6sVo= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; Received: from [172.29.37.68] (66.129.241.11) by SN2PR05MB2510.namprd05.prod.outlook.com (10.166.213.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.693.7; Tue, 1 Nov 2016 16:20:19 +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: Date: Tue, 1 Nov 2016 12:20:13 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <25D24BDC-5322-4B19-A971-9FDD65C07BF1@juniper.net> References: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> <20161101144036.GB10519@pfrc.org> To: Jeffrey Haas X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.11] X-ClientProxiedBy: BLUPR17CA0023.namprd17.prod.outlook.com (10.164.14.161) To SN2PR05MB2510.namprd05.prod.outlook.com (10.166.213.19) X-MS-Office365-Filtering-Correlation-Id: 6fa72cd3-5287-4d79-1da5-08d40272f946 X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2510; 2:feh/mBOGJKnCIijmKErwXohxu4pH2tzDltb1j/MebERj9X3cq1F/sl3GJFqOd8o8K59y2aCTpVPKgH4ncZfsgClzsiVn17YNSZp9YwrlfDv+PfAeKlELETA0Eep14l8YgrvS/KN7YsPi7hOYMFM5sPza7fg3Wl2RRU3biHgD6885B3/XPu2+duGjK8Lkka9OmJVgXGO0xQN4cskJklgpUA==; 3:+LbuPmDWfV7qD0ODJRMXA6wcQdszqw4fhQACLPkhAaSo3GBKX4UCIS08bv8jG9T00TC9fYpElQd4p+KPdioBPc8t7kzGLzfY2r3rR1MLhfMtxfqSZLEtoibsSWedgWDiok160IxnODjhafKk+PCA/A== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN2PR05MB2510; X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2510; 25:ypssU/F6rJc8Moiy5mavYF8mazIxyov8LrW2KraismVGEtEQMw5HQLgoKwDv+ZduffwgF3i+scGl7fxTdwdgMN9DEkhF2vM5SX19utERGi/yjMVyRdIGqOrHCn+S/NqWVHbuvcmuHuH/VnnqTiNSjJ3jXuHzvHq/1/Aeai/TXy7NXwaw2xM9pDxZTQJEYo0K27irrrwm1N0oCRMJXY4wBvUXw/jKxJ0byRKbJgVq6UsMmWbTYd5ukNf0NaEBYxH9M/xMlnLJJIZ8zQNUO3o5Ahtcbts/oxobwuN9Snmot0q4MG0M5ui3ORf2JfcWYDRDNf1Us9np3WfCKFdhjknfxFs2j+DjsQTpxVd6BxPLmpB61hDiEUxuKuiLzc0bP2IVSE/ihuVfbcfOf+MmWFp4SJyarn+7Rxd/g2v4/jMVGIAEs4zVb2mvjlCkgHZ5RTQ+N/Im74iPQFhLBykZtatTNbw6C7XxScPrtvD4gSNVogowpUWsXNK63qiLPca9+Ls3dPFLpD98Oz9iNY8OtyGZZpU7W0j9SNFozWw2uz9pZsWJqqLGhfpcOu86UbISAYdNAkgRuijDHYMschVFt15cQcr/omUs9VeQ4ND1e9fe7PnPwDm+YDGKfH8mZf/MvXMPK55ZhlIolSTEPH0jyRozCoQRuiERvvPOatwLXb32E0MQnwoiBGIwaJbvhyhdt0mTPbmAGo2U+2kgLNCvaSHi6VZI3b6sCz5jX8JccA0CLHcZzoZJWwm+LLvzc7i9HZXK X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2510; 31:mEy+y0sxWA3eU0lXDDptKUnPlb6taQLbFwkMLi3kgnquU5ywIT6Z74zD6j5SPc5WK0wqfH4UUC7Rd1rrTUlvDDkoJhhgrzIBcokg+8rNdD1RLwIP97hfuVV9uKL9HpGeJWIqIuMVXajlADbYVgcWchdSa5Zu3OiIlto44ud99S976G2FQ/MVhVzmMUmZacW+sDOCpK+1u737HTavtZMEjVwAO6jsJZbtz+lpFZZxNP+MVaXEiRHLXo2mLJC37h1tEmCFLT7CCs3qkIse+KK4Aw==; 20:gTG4ay7syNU6JsGvTXrAgjj4jIOT7Df21kysJhrD0kk4M6M0fWecyZGLwpoKa0TM3qu7hGxjVDKoZMfkeYxu9Lcd9wIseVcty6EzwBgQ/uUgK1jBXovcvnNPwaE25BeVqXeXVGhTxpECFrIjR5KW/59LJUaRvxDONCOVm5oS1T6Fg05VUHPwTyDrN7Oin+dhtNkGHi6wSoB6zyOs9gSCSaMrvCmDSudb+eSVK7yaJhoO0i2K+XeoFWS5xsXuyEizdTxsF54kw9fTa4dGXx1eUdhjw/V82CLYUnuZresWO4XMxU4T7MsqTLBmxGeT+HrIHU952uOmWERZfebxFJ89jW6k84bdAsMIP5UPgSnWSp1O/L1RdAeL0b+q/MD/06oHTMsE0GHkcmCKQtcDeRMgbxccQ3Pu0veISN/WKYwX1PCStO7R4Gbn0OtOylBmjJ2TrY+7s1wVn5VCSV602xiVgXTuCE3oS8leNlesMmS7GS5tM+RE9SYF02AF1X/eDxPCYyjCDuNGxMHWcJiNsEXjGSZMRIoDSVsWWmzBw93U3MypSjn86mlmHQ5DoKYODCgFep8JWC7mdbjTgB7lup6a/jrskgNpeZefcO38cSHGeUQ= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(138986009662008); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:SN2PR05MB2510; BCL:0; PCL:0; RULEID:; SRVR:SN2PR05MB2510; X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2510; 4:jO0lm7zce4E2KwZ/+G5jUEOO1aQ1HgJ0zOEHGA6cK8G0iKsB7izKS0+uNk5+7iuYgyH+GAL+N9zXaFzmcN1P8WKk1hnx8+u7SoHz372CZUkmZm2l96lBJh8Z3jJLxH7HytZoaurCFlg4emk/5VHOdCA13hWmk29yD5ssLyiiQIsmtHALVsQ4m+9/S4oo2PJ37xvncMpLW89FFdVQAUN7El3YaoLf4/TwXmZhqdJFXtaNnQUv8MD4rfzJ3zGKFqOyGA9Xt5GZVRMHfWYEKSxoq+OgnZ9qViMqUQaCBUiEelj/qRyHfdUcHRpz8/C8715Hgp+yPM+ScI11G/cSzAvhmJ8KFYRhTWH5rjlFekT9f8JQfXjPywdEmUm7bAvrfm39w8zEPquzrAibH/HiNZnh+htqVYuLf4uvUPWL1gezXlJ9tntK3D/PuPjq9S6ppYV2F0a5szYGaI1VFfZ1q7PmaQ== X-Forefront-PRVS: 01136D2D90 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(7916002)(5423002)(377454003)(24454002)(199003)(189002)(81166006)(8746002)(33656002)(305945005)(7846002)(6666003)(7736002)(8676002)(19580405001)(19580395003)(50226002)(5660300001)(50466002)(6916009)(189998001)(230783001)(83716003)(46406003)(77096005)(23726003)(2950100002)(68736007)(586003)(82746002)(6116002)(106356001)(66066001)(76176999)(86362001)(2906002)(50986999)(42186005)(110136003)(3846002)(97736004)(105586002)(47776003)(4326007)(97756001)(81156014)(92566002)(36756003)(57306001)(101416001)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR05MB2510; H:[172.29.37.68]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN2PR05MB2510; 23:YFF5Zms8DVRZcybC303kz6X3/OA8o4oXzvNu1HAxO?= =?us-ascii?Q?5ppTD2nYI5ameGCq203iVgJTqQfqvgsfDqqDwWY8Py2kFVownhQQgp1gOBBN?= =?us-ascii?Q?5c8dtIilsaDxacpCqaNTK29fxQCY14VUEU9QcgQPDsdWuu6NENyFKWSxzpXR?= =?us-ascii?Q?rc1ux+B+/pjv/ALOeKNDXyTh9w818GwroT3hPk6j3Xyy2Go1UvnVirOwLWuZ?= =?us-ascii?Q?QkI04L7608K3sF0apL+UYFpp50TaAPDOrcJLpYJfATvYWHPrsC5YaLG0ePtY?= =?us-ascii?Q?hwbNqyRmhA+yngbU9/t9VB/KimJRcdUDhedXFE0G++OgSK9sg1jKhRKWJicL?= =?us-ascii?Q?LXoE/zG1wvTPJ32M156237R0LfS4br1YBx9+YpLrFoNah0e7oOJd4Whx2vmv?= =?us-ascii?Q?5ccpUN28Cui0mZ97LSfGhldiU+7WuoC6vBO/gjk1RKBOcH6oItrvdvqhd9Qw?= =?us-ascii?Q?NDxhYWtQW2A+3+HyyJftwdFi3Cq2No9Vd49Xw6Lop0S5Gu2d4q6nQaM0AQfi?= =?us-ascii?Q?GJAsliwdk0HO+eUMBxJq/lVXCy95ugYXiTww32x4ZAK/beWopzdi7ekkhNZz?= =?us-ascii?Q?787QZhqfvUCznMkfrjId7ppbuj0F/1BVpAs0jCFQwpErp+/ocVriC9/SuQnH?= =?us-ascii?Q?yUJGNFKK2amvcuPuLkYWO26ZyuBJhIgJuw8/ve3VJc5D0i/Fm5U/jGxrVEiw?= =?us-ascii?Q?kD2p6okpsD1UCnDE0lQ6V49D697MQT9+A2X7fQl7sPcz4J3s1x0afmzkw6ZE?= =?us-ascii?Q?kxgNxbbwcknuw/5gdebcsTpHQ4TOaHpwVciFgmnquAbvqDvsSEvKd27ofTML?= =?us-ascii?Q?k+iUFbCgLBH6qcjRiTygYQuKTcR+riHZcXijjnrHoZYOPoxg80Fx+3Zlrv3+?= =?us-ascii?Q?sZNGgTlgLa7Xd7Q/k71k7vB8wiD9bZMNYJGi/NSd+pOxusMDzzNVVeV1gHhJ?= =?us-ascii?Q?oK9CXF5UKdw/r3ZAl6fVyzpUzuwbng9/fEbVsIH2S7WaXhGMPLbjDTRpVHTh?= =?us-ascii?Q?7VQetYicSl3RVXTplqJh0CnQ2Uvi17gQonnIlaHwRXWYchBt80U1hzV5Ye1g?= =?us-ascii?Q?7Lrux8PeyPTS4Ic4TqjU8X7YxG0xncH2YX2kJxg4jKl21hwJOmbppoE+C+v0?= =?us-ascii?Q?wL8cJBXG9O/g1Ebuftk/YlE15e5q6Kogx53tIDhr2lGL2pg48ddhZ/ZJRdpL?= =?us-ascii?Q?e8qc47U8uZJ403sTo0e6BD45kBIU8ujDDRaWFH7h28Q78gMUDQOncn4gubyG?= =?us-ascii?Q?rZ7mXKnXhizZt4NMXRAz0PLHjmbJNw7KGdil/clGwaSvKKzeVgFlxNRka6cH?= =?us-ascii?B?dz09?= X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2510; 6:Rm6tdIseGyX7KVOpOvKYtSFsXbxNOdbqus//c8fE900VfdNXIJSITs+yFSkMGz7dwuoB8INGz77kWTqWi8ePjtU7vHV5ReFd6DcQeRCxg4TpEFS0FbykMbcDnpcOMURZjQqy7sCDZzGkVW2i3ESfoNV8fRaaZ4cu1Bf+NOB8lefxoyZrqbcn2t1D3/lQs6ELS+QelMHRqmlH/qvb2dagvm5rHxNfT1aOIBwKUTQC6qgUtcaASUSs/LkSNkbG0tuw5T+MwuiE1GB4AYRcmng02BO4DIhsZqblYHGf9rFzldo8WgQS/yLPm6gvFjqBGppZzPMDAJSC+J8eibq4SDUIVMOYprSR6xrlWzVYx11qk5A=; 5:Zlstb3mzKnQtaiTtxeCWX9xvvuP+Q/Vxum+pzswNIwJliV9psI0SyiV9Ajr4DIA9vjaAk82GPCZUfqSJ17ndWSGLNMemuqdmPIugRWfreQzZxeQii30jDM0OfYDvDwKPWbm5V3qSFv4UEnbYFpNKLA==; 24:7uBL+W3jXjxkVUD+7xHrub8eKbS7zkMoe3K3YtuoABbUZhV2G2cXYalYxYjSWR3QALaNPxGk2lWJ7DEM+7zcLufflpjWx6c4lxZu8MIVoVE= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2510; 7:bdNymHMBavj9xniKwCE3dSpllfE8cdf0Ecbk/SgovE0E67Mwt7CnNry3nXBHHESMVvQtOaIIjn0lLPNmKor6dkVcIggRlDHUIQOoJllw+LBssLpnK4xEeQjciVtpB9ekNsdHaO8Fm8MPGiqrk3yC56KFlqPT7ZsWpKPIqEEiewXt61p+6GxV/yvHeq6kMNLIRwSpGFg3Cc24OzZPsRQBVl+YHqIKFeOhZ1bL6Gb4RCOLVQtDAbkdhp6u2kEwSDcHZpK2PM8DEVLJAB2CpxB+kK4c2QN3ycStDuF5eIYuhpt4+IE5cexPmRTv6asjRjBJGErc7asXxucJo4y3Wszcx9F6oPK6uT1YOZb1CKof9cc= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Nov 2016 16:20:19.3638 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR05MB2510 Archived-At: Cc: IETF IDR Working Group Subject: Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129 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, 01 Nov 2016 16:20:22 -0000 On Nov 1, 2016, at 10:53 AM, John G. Scudder wrote: > On Nov 1, 2016, at 10:40 AM, Jeffrey Haas wrote: >> 1. Do we actually need a draft published to request IANA to block out >> allocation of these code points? If so, we're going to end up with a = number >> of trivial drafts for these corrective actions. I'm interested in = hearing >> the IESG's opinion on this point. >=20 > IANA did specifically request an RFC to reference although they = stopped short of explicitly saying "if you don't promise to give us a = document, we won't do this action". I have asked them to clarify and = will report back, but I suggest that for now the WG should assume that = we do actually need to publish draft and progress it to RFC. Update: Michelle @ IANA confirms that they do require RFC for = deprecation from a Standards Action registry but agrees there is no = documentation of this requirement specific to deprecation, they've just = inferred it from the requirement to assign one. She says she'll bring it = up on the Thursday IESG telechat. Again, for now the WG should assume we do need an RFC. --John= From nobody Tue Nov 1 09:20:55 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B56E1295B8 for ; Tue, 1 Nov 2016 09:20:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.497, 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 f_7vaacaLXAr for ; Tue, 1 Nov 2016 09:20:42 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 909AA12957A for ; Tue, 1 Nov 2016 09:20:40 -0700 (PDT) Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id 7A5E51E1F0; Tue, 1 Nov 2016 12:23:11 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_0A663D0B-0CD3-4941-B93B-AEBB9CDFE89F" Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Jeffrey Haas In-Reply-To: <20161101150148.GM1589@hanna.meerval.net> Date: Tue, 1 Nov 2016 12:20:38 -0400 Message-Id: References: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> <20161101133240.GK1581@hanna.meerval.net> <20161101141229.GK1589@hanna.meerval.net> <20161101142807.GL1589@hanna.meerval.net> <20161101150148.GM1589@hanna.meerval.net> To: Job Snijders X-Mailer: Apple Mail (2.3251) Archived-At: Cc: IETF IDR Working Group , Robert Raszuk Subject: Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129 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, 01 Nov 2016 16:20:54 -0000 --Apple-Mail=_0A663D0B-0CD3-4941-B93B-AEBB9CDFE89F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Nov 1, 2016, at 11:01 AM, Job Snijders wrote: >=20 >> Few days back You and others complained that Wide was not implemented >> by anyone for so many years. Now when we see it actually was >> implemented at least by few BGP code basis it is again bad. >=20 > You might not view it this way, but I am actually looking out for = Wide's > chances of deployment. At this point it is not known which version of > the wide draft was implemented, or even if the implementation is > compatible with said specification. It really is in -wide-'s best > interest to _not_ use attribute 129. FWIW, I concur with this point. For the time being, making sure 129 is = out of the pool makes sense. Robert and I will be discussing reverting the most recent changes to the = common header in our attempt to get that onto Large communities. That = should put the document back in harmony with the likely implementation. = (That, and removing code point 2 since it's covered by Large now = anyway.) -- Jeff --Apple-Mail=_0A663D0B-0CD3-4941-B93B-AEBB9CDFE89F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Nov 1, 2016, at 11:01 AM, Job Snijders <job@ntt.net> = wrote:

Few days back You and others = complained that Wide was not implemented
by anyone for so = many years. Now when we see it actually was
implemented at = least by few BGP code basis it is again bad.

You might not view it this way, but I am = actually looking out for Wide's
chances of deployment. At this point it = is not known which version of
the wide draft was implemented, or even = if the implementation is
compatible with said specification. It = really is in -wide-'s best
interest to _not_ use attribute = 129.

FWIW, I concur with this point.  For the time being, = making sure 129 is out of the pool makes sense.

Robert and I will be discussing = reverting the most recent changes to the common header in our attempt to = get that onto Large communities.  That should put the document back = in harmony with the likely implementation.  (That, and removing = code point 2 since it's covered by Large now anyway.)

-- Jeff

= --Apple-Mail=_0A663D0B-0CD3-4941-B93B-AEBB9CDFE89F-- From nobody Tue Nov 1 09:21:20 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFA1C129576 for ; Tue, 1 Nov 2016 09:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, 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 Mute5Uz80P-R for ; Tue, 1 Nov 2016 09:21:14 -0700 (PDT) Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3964C1295B8 for ; Tue, 1 Nov 2016 09:20:56 -0700 (PDT) Received: by guelah.shrubbery.net (Postfix, from userid 7053) id 013B074754; Tue, 1 Nov 2016 16:20:55 +0000 (UTC) Date: Tue, 1 Nov 2016 16:20:55 +0000 From: heasley To: Jeffrey Haas Message-ID: <20161101162055.GA75985@shrubbery.net> References: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> <20161101144036.GB10519@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161101144036.GB10519@pfrc.org> X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc X-note: live free, or die! X-homer: i just want to have a beer while i am caring. X-Claimation: an engineer needs a manager like a fish needs a bicycle X-reality: only YOU can put an end to the embarrassment that is Tom Cruise User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Cc: IETF IDR Working Group Subject: Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129 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, 01 Nov 2016 16:21:16 -0000 Tue, Nov 01, 2016 at 10:40:36AM -0400, Jeffrey Haas: > 2b. Some of these things are early implementations that are against drafts > that aren't fully mature. This means there will be versioning issues. > Either the code point gets re-used and deals with the versioning problem or > the code point needs deprecation. > > And even then, the fact that there's an early implementation means that > eventually a code point is needed. shouldnt that implementation be done with 255 AND, regardless of an early allocation, never leave the lab? meaning that versioning is unnecessary, in this scenario. From nobody Tue Nov 1 09:30:29 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD61E12946B for ; Tue, 1 Nov 2016 09:30:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, 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 dGd-PygvzGI5 for ; Tue, 1 Nov 2016 09:30:27 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 05708129463 for ; Tue, 1 Nov 2016 09:30:27 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 52DDC1E337; Tue, 1 Nov 2016 12:32:58 -0400 (EDT) Date: Tue, 1 Nov 2016 12:32:58 -0400 From: Jeffrey Haas To: heasley Message-ID: <20161101163258.GG10519@pfrc.org> References: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> <20161101144036.GB10519@pfrc.org> <20161101162055.GA75985@shrubbery.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161101162055.GA75985@shrubbery.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: IETF IDR Working Group Subject: Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129 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, 01 Nov 2016 16:30:28 -0000 On Tue, Nov 01, 2016 at 04:20:55PM +0000, heasley wrote: > Tue, Nov 01, 2016 at 10:40:36AM -0400, Jeffrey Haas: > > 2b. Some of these things are early implementations that are against drafts > > that aren't fully mature. This means there will be versioning issues. > > Either the code point gets re-used and deals with the versioning problem or > > the code point needs deprecation. > > > > And even then, the fact that there's an early implementation means that > > eventually a code point is needed. > > shouldnt that implementation be done with 255 AND, regardless of an early > allocation, never leave the lab? meaning that versioning is unnecessary, > in this scenario. To be clear, I have a strong opinion about what should be done to not get us into a squatting situation. I submitted a draft that gives a proposal to hopefully not get us into that situation again. However, 2b is intended to cover the situation we're in today. -- Jeff From nobody Tue Nov 1 09:37:53 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA8061294A3 for ; Tue, 1 Nov 2016 09:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.019 X-Spam-Level: X-Spam-Status: No, score=-16.019 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=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable 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 8cRIQOCKNnhs for ; Tue, 1 Nov 2016 09:37:50 -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 ADE71129443 for ; Tue, 1 Nov 2016 09:29:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1371; q=dns/txt; s=iport; t=1478017762; x=1479227362; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=s1PH+TJz2qVxbxd9eclj0zwPJoMgRs8hzVuzlhG15d4=; b=B1k718S18KEwWQTDVifPFFJT//OqTlQc5m7shapE6FfldU6J74GEz3VJ hlT0XX6ZLYEEZcXbvkHpeBoATZvjgbiTUxhDkaPn3XUVuQkOexc0R9Y4Y NoI2oAryjXkpknJhO8xOkHXYHntxiAM/nh1bRElSnww/Fan4NPn17HMhn Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BQAgBmwhhY/4gNJK1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgyoBAQEBAR9YfAcBjS6XAZRFggcdDYV4AoIPPxQBAgEBAQEBAQFiKIR?= =?us-ascii?q?hAQEBBAEBARodNBcEAgEIEQQBAR8JBycLFAkIAgQBEgiITA63HgEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBARcFhj2EVYonBZQ8hV4BiTmGdIF1hG6JKo0ThAMBHjZgg1i?= =?us-ascii?q?BO3IBhk8BgQsBAQE?= X-IronPort-AV: E=Sophos;i="5.31,580,1473120000"; d="scan'208";a="169837745" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Nov 2016 16:29:21 +0000 Received: from XCH-ALN-012.cisco.com (xch-aln-012.cisco.com [173.36.7.22]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id uA1GTLOp023535 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 1 Nov 2016 16:29:21 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-012.cisco.com (173.36.7.22) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 1 Nov 2016 11:29:20 -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; Tue, 1 Nov 2016 11:29:20 -0500 From: "Jakob Heitz (jheitz)" To: "John G. Scudder" , "idr@ietf.org" Thread-Topic: [Idr] Working group adoption call for draft-gredler-idr-bgp-ls-segment-routing-ext Thread-Index: AQHSM7wVYuzSWgrz+USYpjTSs+MofKDEUqvw Date: Tue, 1 Nov 2016 16:29:20 +0000 Message-ID: <8a0b859987274d38ab8c02c425919cf9@XCH-ALN-014.cisco.com> References: 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.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] Working group adoption call for draft-gredler-idr-bgp-ls-segment-routing-ext 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, 01 Nov 2016 16:37:52 -0000 support. Thanks, Jakob. > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of John G. Scudder > Sent: Monday, October 31, 2016 2:16 PM > To: idr@ietf.org > Subject: [Idr] Working group adoption call for draft-gredler-idr-bgp-ls-s= egment-routing-ext >=20 > Hi Everyone, >=20 > The authors have asked (some time ago actually) for the WG to adopt draft= -gredler-idr-bgp-ls-segment-routing-ext. >=20 > If you support or oppose adoption please reply indicating so. Reasons for= your position are helpful, as volunteering > to review, comment, and/or shepherd. >=20 > The adoption call will end November 13. >=20 > Thanks, >=20 > --John >=20 > P.S.: https://www.ietf.org/id/draft-gredler-idr-bgp-ls-segment-routing-ex= t-04.txt >=20 > Abstract >=20 > Segment Routing (SR) allows for a flexible definition of end-to-end > paths within IGP topologies by encoding paths as sequences of > topological sub-paths, called "segments". These segments are > advertised by the link-state routing protocols (IS-IS, OSPF and > OSPFv3). >=20 > This draft defines extensions to the BGP Link-state address-family in > order to carry segment information via BGP. > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Tue Nov 1 09:44:28 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C78431294BC for ; Tue, 1 Nov 2016 09:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 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=-1.497, 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 8VlZqyTIScRJ for ; Tue, 1 Nov 2016 09:44:26 -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 F3FCF1294A3 for ; Tue, 1 Nov 2016 09:44:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3330; q=dns/txt; s=iport; t=1478018665; x=1479228265; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=PCbPbGY8nElqLoAKTC5pwDvHcmbXCZDEHhR3SrLaJZo=; b=cA/gMAqiTxxsW41ZFa3pD/DEScxHS/OfLMLJBAj4hPlv9ykmMoOfw559 0u5IbGx9ND1ZEp9JBKHwhhk0DQc/dka0ZdXt2TthA+QtEu7PqZIgjkj0L lIRNeCTF9LWL3NUbibhL+MfZvLX2Am54maoNweEdZGoSZKgYguiJ9k+QH Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DBAQAgxhhY/5pdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgyoBAQEBAR9YfAcBjS6XAZRFggcdC4V6AhqBdj8UAQIBAQEBAQE?= =?us-ascii?q?BYiiEYQEBAQQBAQEgEToLDAQCAQgRBAEBAQICIwMCAgIlCxQBCAgCBAENBQgTi?= =?us-ascii?q?DkOqiyMeAEBAQEBAQEBAQEBAQEBAQEBAQEBARcFgQeFNoRVhBkRAYMgglwFmho?= =?us-ascii?q?BhjCJfYF1iCiFcI0ThAMBHjZghRNyhTCBIAGBCwEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,580,1473120000"; d="scan'208";a="341027724" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Nov 2016 16:44:25 +0000 Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id uA1GiP19000698 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 1 Nov 2016 16:44:25 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 1 Nov 2016 11:44:24 -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; Tue, 1 Nov 2016 11:44:24 -0500 From: "Jakob Heitz (jheitz)" To: "John G. Scudder" , Robert Raszuk Thread-Topic: [Idr] Early allocations and other ways to avoid squatting on code points Thread-Index: AQHSNFFYQbYshjrfZESTJ2mO+uOKraDEVFbA Date: Tue, 1 Nov 2016 16:44:24 +0000 Message-ID: References: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> <20161101133240.GK1581@hanna.meerval.net> <20161101141229.GK1589@hanna.meerval.net> <20161101142807.GL1589@hanna.meerval.net> <89B7215E-505D-4EEF-94E6-DB9B7CC23A8D@juniper.net> In-Reply-To: <89B7215E-505D-4EEF-94E6-DB9B7CC23A8D@juniper.net> 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.35] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: IETF IDR Working Group Subject: Re: [Idr] Early allocations and other ways to avoid squatting on code points 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, 01 Nov 2016 16:44:28 -0000 SSBzdXBwb3J0IGFuIGVhcmx5IGF0dHJpYnV0ZSBjb2RlIGFsbG9jYXRpb24gZm9yIHdpZGUgY29t bXVuaXRpZXMuDQpJJ20gaGFwcHkgZm9yIGl0IHRvIGhhdmUgMTI5IGlmIHRoYXQncyB3aGF0IGl0 J3MgYmVlbiB1c2luZy4NCk9mIGNvdXJzZSwgaXQncyBub3QgbXkgY2FsbCB0byBtYWtlLCBqdXN0 IG15IG9waW5pb24uDQoNClRoYW5rcywNCkpha29iLg0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gRnJvbTogSWRyIFttYWlsdG86aWRyLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBKb2huIEcuIFNjdWRkZXINCj4gU2VudDogVHVlc2RheSwgTm92ZW1iZXIgMDEsIDIw MTYgODowNSBBTQ0KPiBUbzogUm9iZXJ0IFJhc3p1ayA8cm9iZXJ0QHJhc3p1ay5uZXQ+DQo+IENj OiBJRVRGIElEUiBXb3JraW5nIEdyb3VwIDxpZHJAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFtJZHJd IEVhcmx5IGFsbG9jYXRpb25zIGFuZCBvdGhlciB3YXlzIHRvIGF2b2lkIHNxdWF0dGluZyBvbiBj b2RlIHBvaW50cw0KPiANCj4gSSBoYXZlIGNoYW5nZWQgdGhlIHN1YmplY3QgbGluZSB0byByZWZs ZWN0IHRoZSBmYWN0IHdlIGFyZSBvZmYgb24gYSB0YW5nZW50IGFuZCBubyBsb25nZXIgcmVsZXZh bnQgdG8gYWRvcHRpb24gb2YNCj4gdGhlIGRyYWZ0IGluIHF1ZXN0aW9uLg0KPiANCj4gT24gTm92 IDEsIDIwMTYsIGF0IDEwOjQxIEFNLCBSb2JlcnQgUmFzenVrIDxyb2JlcnRAcmFzenVrLm5ldD4g d3JvdGU6DQo+ID4g4oCLRmV3IGRheXMgYmFjayBZb3UgYW5kIG90aGVycyBjb21wbGFpbmVkIHRo YXQgV2lkZSB3YXMgbm90IGltcGxlbWVudGVkIGJ5IGFueW9uZSBmb3Igc28gbWFueSB5ZWFycy4g Tm93IHdoZW4gd2Ugc2VlDQo+IGl0IGFjdHVhbGx5IHdhcyBpbXBsZW1lbnRlZCBhdCBsZWFzdCBi eSBmZXcgQkdQIGNvZGUgYmFzaXMg4oCLaXQgaXMgYWdhaW4gYmFkLg0KPiANCj4gSSdtIG5vdCBz dXJlIHdoYXQgeW91IG1lYW4gYnkgIml0IGlzIGFnYWluIGJhZCIgYnV0IHNlZSB0aGUgbWVzc2Fn ZSBJIGp1c3Qgc2VudCAtLSB3ZSB3ZXJlIG5vdCBhc2tlZCBmb3IgYW4NCj4gYWxsb2NhdGlvbiBm b3IgdGhlIGNvZGUgYmFzZSBpbiBxdWVzdGlvbiAobm90IHN1cmUgd2hhdCBvdGhlciBjb2RlIGJh c2VzIHlvdSBhcmUgaW5jbHVkaW5nIGluICJmZXciLCBJIHRoaW5rIG9uZSB3YXMNCj4gcmVwb3J0 ZWQpLg0KPiANCj4gV2hlbiB0aGUgcXVlc3Rpb24gb2YgZWFybHkgYWxsb2NhdGlvbiBmb3Igd2lk ZSBjYW1lIHVwIHJlY2VudGx5IChJIGRvbid0IHJlY2FsbCBpZiBpdCB3YXMgb24gdGhlIGxpc3Qs IGluIHByaXZhdGUNCj4gZW1haWwsIGluIGNvbnZlcnNhdGlvbiBvciB3aGF0LCBzb3JyeSkgbXkg ZmVlZGJhY2sgd2FzIHRvIGFzayB3aGV0aGVyIHdpZGUgc2F0aXNmaWVzIHRoZSBzdGFiaWxpdHkg cmVxdWlyZW1lbnQgZ2l2ZW4NCj4gaW4gUkZDIDcxMjAgU2VjdGlvbiAyIChjKS4gQ2VydGFpbmx5 IGlmIHRoZXJlIGlzIG5lZWQgZm9yIGFuIGFsbG9jYXRpb24gZm9yIHdpZGUgYW5kIGl0IGNhbiBz YXRpc2Z5IHRoZSBSRkMgNzEyMA0KPiByZXF1aXJlbWVudHMsIGxldCdzIGRvIGl0LiBJZiBpdCBj YW4ndCBzYXRpc2Z5IHRoZSByZXF1aXJlbWVudHMsIHJlYWQgb246DQo+IA0KPiA+IFNvIHRvIG1l IHRoZSBwcm9ibGVtIHdlIG5lZWQgdG8gc29sdmUgaXMgaG93IHRvIGFsbG93IGVhcmx5IGltcGxl bWVudGF0aW9ucyBmb3IgYW55IHByb3Bvc2FsIG9uIHRoZSB0YWJsZQ0KPiBlc3BlY2lhbGx5IG5v dyB3aGVuIHdlIGhhdmUgbm8gdHdvIGJ1dCBhdCBsZWFzdCA4IHByb2R1Y3Rpb24gQkdQIGltcGxl bWVudGF0aW9ucyAoYW5kIGdyb3dpbmcpLiBGb3JiaWRkaW5nIGl0IGRvZXMNCj4gbm90IHNlZW1z IHRvIG1lIGxpa2UgYSBzb2x1dGlvbiB0byB0aGUgbWFpbiBwcm9ibGVtLg0KPiANCj4gSSBleHBl Y3Qgd2Ugd2lsbCBiZSBkaXNjdXNzaW5nIHRoaXMgYXQgb3VyIHVwY29taW5nIG1lZXRpbmcsIGFs dGhvdWdoIHRoYXQncyBubyByZWFzb24gbm90IHRvIGNvbnRpbnVlIHRoZQ0KPiBjb252ZXJzYXRp b24gb24gdGhlIGxpc3QgcmlnaHQgbm93LCBvbiB0aGUgY29udHJhcnkuIEplZmYgaGFzIGFsc28g d3JpdHRlbiBhIGRyYWZ0IHRoYXQgdHJpZXMgdG8gYWRkcmVzcyB0aGUgcHJvYmxlbSwNCj4gaGUg cG9zdGVkIGEgcG9pbnRlciB0byBpdCB5ZXN0ZXJkYXksIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWhhYXMtaWRyLWV4dGVuZGVkLWV4cGVyaW1lbnRhbC8NCj4gDQo+IFRo YW5rcywNCj4gDQo+IC0tSm9obg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiBJZHIgbWFpbGluZyBsaXN0DQo+IElkckBpZXRmLm9yZw0KPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkcg0K From nobody Tue Nov 1 09:57:03 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC611294D0 for ; Tue, 1 Nov 2016 09:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 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=-1.497, 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 OQ2KHpPWhIYV for ; Tue, 1 Nov 2016 09:57:01 -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 1FEE21294BF for ; Tue, 1 Nov 2016 09:57:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2763; q=dns/txt; s=iport; t=1478019421; x=1479229021; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=z5fGLoOQYm0ebu+Qg7Y1aLlAL0+tkeCxTVwcb+cSv78=; b=LbinTJ/CeNshS8G7+anEltBsBw4HhSSsYjFQKJqY3v2Pln5w4zYi3Csl XS5TmBHdo0MCx8hAuvw0ufDDEJ1TnFPs+QNG+UCa+EE8PbKclnYVTgnug 9JcrJImHMhqrEP6OBh9VxAG5v/mayxwJxHhfcUHgzyWy7ARI+rCrSeznX Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BRAgDOyBhY/4QNJK1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgyoBAQEBAR9YfAcBjS6XAZRFggcdC4V6AoIQPxQBAgEBAQEBAQFiKIR?= =?us-ascii?q?hAQEBBAEBATc0FwQCAQgOAwMBAQEfCQcnCxQJCAIEARIIAYhLDrcoAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBHIY9hFWEeYUuBYYmk3QBhjCDCYMHg22BdU6EIIkqLYh?= =?us-ascii?q?jhAOEAwEeNmCDWA6BLXIBhk8BgQsBAQE?= X-IronPort-AV: E=Sophos;i="5.31,580,1473120000"; d="scan'208";a="164379460" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Nov 2016 16:57:00 +0000 Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id uA1Gv0n5008686 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 1 Nov 2016 16:57:00 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 1 Nov 2016 11:56: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; Tue, 1 Nov 2016 11:56:59 -0500 From: "Jakob Heitz (jheitz)" To: Jeffrey Haas , "idr@ietf.org" Thread-Topic: [Idr] [internet-drafts@ietf.org: I-D Action: draft-haas-idr-extended-experimental-00.txt] Thread-Index: AQHSM7jDIB+7ENsXFkWPGA8uuqU2ZqDEWiQQ Date: Tue, 1 Nov 2016 16:56:59 +0000 Message-ID: <13f73d9614a84dda8f679a0e393d62b3@XCH-ALN-014.cisco.com> References: <20161031205515.GA25507@pfrc.org> In-Reply-To: <20161031205515.GA25507@pfrc.org> 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.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] [internet-drafts@ietf.org: I-D Action: draft-haas-idr-extended-experimental-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: Tue, 01 Nov 2016 16:57:02 -0000 Jeff, This is good and I support adoption, should you ask for it. It should fix the problem. Thanks, Jakob. > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jeffrey Haas > Sent: Monday, October 31, 2016 1:55 PM > To: idr@ietf.org > Subject: [Idr] [internet-drafts@ietf.org: I-D Action: draft-haas-idr-exte= nded-experimental-00.txt] >=20 > IDR, >=20 > There's a larger conversation to be had about proper stewardship and use = of > code points of all sorts, but path attributes have our attention for the > moment. >=20 > A quick draft for consideration and to motivate discussion. >=20 > -- Jeff >=20 > P.S. I'm sure there's a number of rough edges in this. I knocked it off = in > less than two hours after not enough sleep. >=20 > ----- Forwarded message from internet-drafts@ietf.org ----- >=20 > Date: Sun, 30 Oct 2016 07:53:04 -0700 > From: internet-drafts@ietf.org > To: i-d-announce@ietf.org > Subject: I-D Action: draft-haas-idr-extended-experimental-00.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >=20 >=20 > Title : Extended Experimental Path Attributes for BGP > Author : Jeffrey Haas > Filename : draft-haas-idr-extended-experimental-00.txt > Pages : 7 > Date : 2016-10-30 >=20 > 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. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-haas-idr-extended-experimental/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-haas-idr-extended-experimental-00 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > 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 > _______________________________________________ > 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 >=20 > ----- End forwarded message ----- >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Tue Nov 1 10:03:38 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD311129479 for ; Tue, 1 Nov 2016 10:03:33 -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_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=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 910E1ePLCyLs for ; Tue, 1 Nov 2016 10:03:24 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0050.outbound.protection.outlook.com [104.47.34.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D28DC129561 for ; Tue, 1 Nov 2016 10:03:24 -0700 (PDT) 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=Q54nPj33umK8uZLrBT+m8HwXBJ2Ool7wmmSXRbjBMLE=; b=CHciNToNDugIez30LaIgsW0sLKqIGp6wLRiN+MvzAfUIk9x0RdUhRSpjZhrjxGxPhY/87CLLcYgbwjweyf/a2C50Wz2DXxr33KcXau2Vg4fpyFTefdfVCwORhzObpL7EX+E+YFs8Znto6BupjCKlPLsDdh7wSWetTs/R4FyI+vg= 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.693.12; Tue, 1 Nov 2016 17:03:23 +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.0693.009; Tue, 1 Nov 2016 17:03:22 +0000 From: Keyur Patel To: "Jakob Heitz (jheitz)" Thread-Topic: [Idr] Early allocations and other ways to avoid squatting on code points Thread-Index: AQHSNF86XZS4wAjYq0aSyuh/AAdkJ6DEWvaR Date: Tue, 1 Nov 2016 17:03:22 +0000 Message-ID: <960A93B5-2D91-4247-B8BD-51BA7B38A9C6@arrcus.com> References: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> <20161101133240.GK1581@hanna.meerval.net> <20161101141229.GK1589@hanna.meerval.net> <20161101142807.GL1589@hanna.meerval.net> <89B7215E-505D-4EEF-94E6-DB9B7CC23A8D@juniper.net>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=keyur@arrcus.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [67.169.5.26] x-ms-office365-filtering-correlation-id: 8221430c-4688-445c-75ed-08d40278fcfd x-microsoft-exchange-diagnostics: 1; BY2PR18MB0263; 7:u85jXnS5UX3oIqr8j6+BVlPjTmGthFghmVG7OD+KwKUKCB5Iac5p6a9fAjg2ImcrNKvKIhdZerrzqAihaBjJFzPlnG1w/Ne6JhbJDwFJRK2JhcTNvFgm769LP40y5P84oD+9VaBUU9N70tUSuzo1X/5A/FkZS/kHrEfLzaRC9VLIBJ1GSETdLlsRPDl8LJWd5vXXanVeYom2KhiBRDUCI5+BlazsSoidDUtuKU+Pd4knh4VOi2vywfizZ0BTY/asBItHfCWGGPKgLxiXKt7t9BZvewiBHc14DUA4dQSnYCgvo6Qa8eoQ5VFYJbssf+1yd5Yr+zPnJF/kD5nvaniimPe+eJsFhKwDPf8WEzbp2oA= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR18MB0263; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6043046)(6042046); SRVR:BY2PR18MB0263; BCL:0; PCL:0; RULEID:; SRVR:BY2PR18MB0263; x-forefront-prvs: 01136D2D90 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(24454002)(13464003)(377454003)(199003)(189002)(8936002)(8676002)(10400500002)(2906002)(19580395003)(19580405001)(93886004)(81166006)(36756003)(81156014)(110136003)(122556002)(9886003)(82746002)(2950100002)(2900100001)(77096005)(68736007)(92566002)(15975445007)(83716003)(6916009)(5660300001)(66066001)(3660700001)(189998001)(106356001)(50986999)(106116001)(99286002)(101416001)(5003630100001)(105586002)(87936001)(76176999)(7846002)(54356999)(8666005)(586003)(3846002)(102836003)(6116002)(33656002)(561944003)(86362001)(305945005)(7736002)(3280700002)(4326007)(5002640100001)(97736004)(7059030)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR18MB0263; H:BY2PR18MB0262.namprd18.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: arrcus.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: arrcus.com X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Nov 2016 17:03:22.6539 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 697b3529-5c2b-40cf-a019-193eb78f6820 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR18MB0263 Archived-At: Cc: Robert Raszuk , IETF IDR Working Group Subject: Re: [Idr] Early allocations and other ways to avoid squatting on code points 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, 01 Nov 2016 17:03:34 -0000 KzEuIA0KDQpSZWdhcmRzLA0KS2V5dXINCg0KU2VudCBmcm9tIG15IGlQaG9uZQ0KDQo+IE9uIE5v diAxLCAyMDE2LCBhdCA5OjQ0IEFNLCBKYWtvYiBIZWl0eiAoamhlaXR6KSA8amhlaXR6QGNpc2Nv LmNvbT4gd3JvdGU6DQo+IA0KPiBJIHN1cHBvcnQgYW4gZWFybHkgYXR0cmlidXRlIGNvZGUgYWxs b2NhdGlvbiBmb3Igd2lkZSBjb21tdW5pdGllcy4NCj4gSSdtIGhhcHB5IGZvciBpdCB0byBoYXZl IDEyOSBpZiB0aGF0J3Mgd2hhdCBpdCdzIGJlZW4gdXNpbmcuDQo+IE9mIGNvdXJzZSwgaXQncyBu b3QgbXkgY2FsbCB0byBtYWtlLCBqdXN0IG15IG9waW5pb24uDQo+IA0KPiBUaGFua3MsDQo+IEph a29iLg0KPiANCj4gDQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogSWRy IFttYWlsdG86aWRyLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKb2huIEcuIFNjdWRk ZXINCj4+IFNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDAxLCAyMDE2IDg6MDUgQU0NCj4+IFRvOiBS b2JlcnQgUmFzenVrIDxyb2JlcnRAcmFzenVrLm5ldD4NCj4+IENjOiBJRVRGIElEUiBXb3JraW5n IEdyb3VwIDxpZHJAaWV0Zi5vcmc+DQo+PiBTdWJqZWN0OiBbSWRyXSBFYXJseSBhbGxvY2F0aW9u cyBhbmQgb3RoZXIgd2F5cyB0byBhdm9pZCBzcXVhdHRpbmcgb24gY29kZSBwb2ludHMNCj4+IA0K Pj4gSSBoYXZlIGNoYW5nZWQgdGhlIHN1YmplY3QgbGluZSB0byByZWZsZWN0IHRoZSBmYWN0IHdl IGFyZSBvZmYgb24gYSB0YW5nZW50IGFuZCBubyBsb25nZXIgcmVsZXZhbnQgdG8gYWRvcHRpb24g b2YNCj4+IHRoZSBkcmFmdCBpbiBxdWVzdGlvbi4NCj4+IA0KPj4+IE9uIE5vdiAxLCAyMDE2LCBh dCAxMDo0MSBBTSwgUm9iZXJ0IFJhc3p1ayA8cm9iZXJ0QHJhc3p1ay5uZXQ+IHdyb3RlOg0KPj4+ IOKAi0ZldyBkYXlzIGJhY2sgWW91IGFuZCBvdGhlcnMgY29tcGxhaW5lZCB0aGF0IFdpZGUgd2Fz IG5vdCBpbXBsZW1lbnRlZCBieSBhbnlvbmUgZm9yIHNvIG1hbnkgeWVhcnMuIE5vdyB3aGVuIHdl IHNlZQ0KPj4gaXQgYWN0dWFsbHkgd2FzIGltcGxlbWVudGVkIGF0IGxlYXN0IGJ5IGZldyBCR1Ag Y29kZSBiYXNpcyDigItpdCBpcyBhZ2FpbiBiYWQuDQo+PiANCj4+IEknbSBub3Qgc3VyZSB3aGF0 IHlvdSBtZWFuIGJ5ICJpdCBpcyBhZ2FpbiBiYWQiIGJ1dCBzZWUgdGhlIG1lc3NhZ2UgSSBqdXN0 IHNlbnQgLS0gd2Ugd2VyZSBub3QgYXNrZWQgZm9yIGFuDQo+PiBhbGxvY2F0aW9uIGZvciB0aGUg Y29kZSBiYXNlIGluIHF1ZXN0aW9uIChub3Qgc3VyZSB3aGF0IG90aGVyIGNvZGUgYmFzZXMgeW91 IGFyZSBpbmNsdWRpbmcgaW4gImZldyIsIEkgdGhpbmsgb25lIHdhcw0KPj4gcmVwb3J0ZWQpLg0K Pj4gDQo+PiBXaGVuIHRoZSBxdWVzdGlvbiBvZiBlYXJseSBhbGxvY2F0aW9uIGZvciB3aWRlIGNh bWUgdXAgcmVjZW50bHkgKEkgZG9uJ3QgcmVjYWxsIGlmIGl0IHdhcyBvbiB0aGUgbGlzdCwgaW4g cHJpdmF0ZQ0KPj4gZW1haWwsIGluIGNvbnZlcnNhdGlvbiBvciB3aGF0LCBzb3JyeSkgbXkgZmVl ZGJhY2sgd2FzIHRvIGFzayB3aGV0aGVyIHdpZGUgc2F0aXNmaWVzIHRoZSBzdGFiaWxpdHkgcmVx dWlyZW1lbnQgZ2l2ZW4NCj4+IGluIFJGQyA3MTIwIFNlY3Rpb24gMiAoYykuIENlcnRhaW5seSBp ZiB0aGVyZSBpcyBuZWVkIGZvciBhbiBhbGxvY2F0aW9uIGZvciB3aWRlIGFuZCBpdCBjYW4gc2F0 aXNmeSB0aGUgUkZDIDcxMjANCj4+IHJlcXVpcmVtZW50cywgbGV0J3MgZG8gaXQuIElmIGl0IGNh bid0IHNhdGlzZnkgdGhlIHJlcXVpcmVtZW50cywgcmVhZCBvbjoNCj4+IA0KPj4+IFNvIHRvIG1l IHRoZSBwcm9ibGVtIHdlIG5lZWQgdG8gc29sdmUgaXMgaG93IHRvIGFsbG93IGVhcmx5IGltcGxl bWVudGF0aW9ucyBmb3IgYW55IHByb3Bvc2FsIG9uIHRoZSB0YWJsZQ0KPj4gZXNwZWNpYWxseSBu b3cgd2hlbiB3ZSBoYXZlIG5vIHR3byBidXQgYXQgbGVhc3QgOCBwcm9kdWN0aW9uIEJHUCBpbXBs ZW1lbnRhdGlvbnMgKGFuZCBncm93aW5nKS4gRm9yYmlkZGluZyBpdCBkb2VzDQo+PiBub3Qgc2Vl bXMgdG8gbWUgbGlrZSBhIHNvbHV0aW9uIHRvIHRoZSBtYWluIHByb2JsZW0uDQo+PiANCj4+IEkg ZXhwZWN0IHdlIHdpbGwgYmUgZGlzY3Vzc2luZyB0aGlzIGF0IG91ciB1cGNvbWluZyBtZWV0aW5n LCBhbHRob3VnaCB0aGF0J3Mgbm8gcmVhc29uIG5vdCB0byBjb250aW51ZSB0aGUNCj4+IGNvbnZl cnNhdGlvbiBvbiB0aGUgbGlzdCByaWdodCBub3csIG9uIHRoZSBjb250cmFyeS4gSmVmZiBoYXMg YWxzbyB3cml0dGVuIGEgZHJhZnQgdGhhdCB0cmllcyB0byBhZGRyZXNzIHRoZSBwcm9ibGVtLA0K Pj4gaGUgcG9zdGVkIGEgcG9pbnRlciB0byBpdCB5ZXN0ZXJkYXksIGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWhhYXMtaWRyLWV4dGVuZGVkLWV4cGVyaW1lbnRhbC8NCj4+ IA0KPj4gVGhhbmtzLA0KPj4gDQo+PiAtLUpvaG4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBJZHIgbWFpbGluZyBsaXN0DQo+PiBJZHJAaWV0 Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRyDQo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IElkciBtYWls aW5nIGxpc3QNCj4gSWRyQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vaWRyDQo= From nobody Tue Nov 1 10:04:25 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 147911293EB for ; Tue, 1 Nov 2016 10:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, 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 Bfw9rsGz4Bro for ; Tue, 1 Nov 2016 10:04:22 -0700 (PDT) Received: from seele.lamehost.it (seele.lamehost.it [80.76.80.23]) by ietfa.amsl.com (Postfix) with ESMTP id 5D2DB129569 for ; Tue, 1 Nov 2016 10:04:16 -0700 (PDT) Received: from www.lamehost.it (unknown [80.76.80.23]) (Authenticated sender: marco@lamehost.it) by seele.lamehost.it (Postfix) with ESMTPSA id 8412F746D0; Tue, 1 Nov 2016 18:04:10 +0100 (CET) Mime-Version: 1.0 Date: Tue, 01 Nov 2016 17:04:10 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-ID: X-Mailer: RainLoop/1.10.3.151 From: marco@lamehost.it To: "John G.Scudder" , "IETF IDR Working Group" In-Reply-To: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> References: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> X-Originating-IP: 79.24.77.5 X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.11 (seele.lamehost.it [0.0.0.0]); Tue, 01 Nov 2016 18:04:10 +0100 (CET) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.11 (seele.lamehost.it [0.0.0.0]); Tue, 01 Nov 2016 18:04:10 +0100 (CET) X-Virus-Scanned: clamav-milter 0.99.2 at seele X-Virus-Status: Clean Archived-At: Subject: Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129 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, 01 Nov 2016 17:04:24 -0000 October 31, 2016 10:19 PM, "John G.Scudder" wrote:=0A> = Hi Everyone,=0A> =0A> The author has asked for the WG to adopt draft-snij= ders-idr-deprecate-30-31-129. =0A> =0A> If you support or oppose adoption= please reply indicating so. Reasons for your position are=0A> helpful, a= s volunteering to review, comment, and/or shepherd. As an aside, I will n= ote that I don't=0A> think the WG has the option of doing nothing, so if = you oppose adoption please address what you=0A> think should be done inst= ead.=0A> =0A> The adoption call will end November 13.=0A> =0A> Thanks,=0A= > =0A> --John=0A> =0A> P.S.: https://tools.ietf.org/html/draft-snijders-i= dr-deprecate-30-31-129-01=0A> =0A> Abstract=0A> =0A> This document reques= ts IANA to deprecate the following BGP path=0A> attributes values: 30, 31= and 129.=0A> =0A> _______________________________________________=0A> Id= r mailing list=0A> Idr@ietf.org=0A> https://www.ietf.org/mailman/listinfo= /idr=0A=0ASupport From nobody Tue Nov 1 10:04:35 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E84C1293EB for ; Tue, 1 Nov 2016 10:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497, SPF_HELO_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 lF8Z84BfVdbs for ; Tue, 1 Nov 2016 10:04:23 -0700 (PDT) Received: from gir.theapt.org (gir.theapt.org [81.209.183.113]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D143129487 for ; Tue, 1 Nov 2016 10:04:17 -0700 (PDT) Received: from gir.theapt.org (unknown [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/0 bits)) (Client did not present a certificate) (Authenticated sender: phessler) by gir.theapt.org (Postfix) with ESMTPSA id 1942878985 for ; Tue, 1 Nov 2016 18:04:16 +0100 (CET) Date: Tue, 1 Nov 2016 18:04:14 +0100 From: Peter Hessler To: idr@ietf.org Message-ID: <20161101170414.GD24817@gir.theapt.org> References: <20161031205515.GA25507@pfrc.org> <13f73d9614a84dda8f679a0e393d62b3@XCH-ALN-014.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <13f73d9614a84dda8f679a0e393d62b3@XCH-ALN-014.cisco.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [Idr] [internet-drafts@ietf.org: I-D Action: draft-haas-idr-extended-experimental-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: Tue, 01 Nov 2016 17:04:26 -0000 same and same. if adopted by the WG, I'd be interested in tightening it up a bit more but that can be handled then. On 2016 Nov 01 (Tue) at 16:56:59 +0000 (+0000), Jakob Heitz (jheitz) wrote: :Jeff, : :This is good and I support adoption, should you ask for it. :It should fix the problem. : :Thanks, :Jakob. : : :> -----Original Message----- :> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jeffrey Haas :> Sent: Monday, October 31, 2016 1:55 PM :> To: idr@ietf.org :> Subject: [Idr] [internet-drafts@ietf.org: I-D Action: draft-haas-idr-extended-experimental-00.txt] :> :> IDR, :> :> There's a larger conversation to be had about proper stewardship and use of :> code points of all sorts, but path attributes have our attention for the :> moment. :> :> A quick draft for consideration and to motivate discussion. :> :> -- Jeff :> :> P.S. I'm sure there's a number of rough edges in this. I knocked it off in :> less than two hours after not enough sleep. :> :> ----- Forwarded message from internet-drafts@ietf.org ----- :> :> Date: Sun, 30 Oct 2016 07:53:04 -0700 :> From: internet-drafts@ietf.org :> To: i-d-announce@ietf.org :> Subject: I-D Action: draft-haas-idr-extended-experimental-00.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-00.txt :> Pages : 7 :> Date : 2016-10-30 :> :> 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-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/ :> :> _______________________________________________ :> 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 ----- :> :> _______________________________________________ :> 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 -- You are here: *** *** ********* ******* ***** *** * But you're not all there. From nobody Tue Nov 1 10:05:59 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21FC61294A5 for ; Tue, 1 Nov 2016 10:05:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, 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 EIS7Me67zxsl for ; Tue, 1 Nov 2016 10:05:57 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 20B891293EB for ; Tue, 1 Nov 2016 10:05:57 -0700 (PDT) Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id 58B761E1F0; Tue, 1 Nov 2016 13:08:28 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Jeffrey Haas In-Reply-To: Date: Tue, 1 Nov 2016 13:05:55 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: John Scudder X-Mailer: Apple Mail (2.3251) Archived-At: Cc: IETF IDR Working Group Subject: Re: [Idr] Working group adoption call for draft-gredler-idr-bgp-ls-segment-routing-ext 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, 01 Nov 2016 17:05:58 -0000 > On Oct 31, 2016, at 5:16 PM, John G. Scudder wrote: >=20 > Hi Everyone, >=20 > The authors have asked (some time ago actually) for the WG to adopt = draft-gredler-idr-bgp-ls-segment-routing-ext.=20 >=20 > If you support or oppose adoption please reply indicating so. Reasons = for your position are helpful, as volunteering to review, comment, = and/or shepherd. >=20 > The adoption call will end November 13. I support adoption. Also, in light of not only code shipping and in recent discussions... = there are a number of code point points in this document pertinent to = BGP-LS that need early allocation. The chairs should consider that as = part of adoption work. -- Jeff From nobody Tue Nov 1 10:07:23 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26025129575 for ; Tue, 1 Nov 2016 10:07:21 -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, 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 NYtD5JNk-112 for ; Tue, 1 Nov 2016 10:07:19 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c: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 C5571129569 for ; Tue, 1 Nov 2016 10:07:18 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id p190so217601332wmp.1 for ; Tue, 01 Nov 2016 10:07:18 -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=ihapLgGqv7qavDjUjHglGagcqMqoEsohd4pSyPMVasg=; b=VwXOEEzNZG35AMesRKJoBPeUbWSymM2paKg5hdBTvPNvQ1OPtgn35rmSBtgCckX71U oWS1NPr8XoRv5Re+jUaARClmr35gLH0mJnBggBJJE24GIx4wES4A6xs+kO3agIu5ypQY KCYee3eUvZkLdmg6zVlm9mz3mu4mdqEn2RjWieTCb9V+eLGFl2E+WcPTtflHcu/v/uN2 8BFf6QO6trG5vi827qx6TITXxeqnUBegHwfiC2JaxCNFKrSbK73d7JTIeee/+CIH7T6X Sapgv7sZ0roKTpJHvj7v1XooD9y50XMHRCmvV8MRwKUCYxVjsm4dNZnOokTfdGRBeTEw dQ0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=ihapLgGqv7qavDjUjHglGagcqMqoEsohd4pSyPMVasg=; b=GBMXf4kQn6nbH52+G5w4u6Pi2YNiophm7BGfxX+ueVLx/dZW1uoGZvIJk7WlaeSrjA jtCNNIlt/axXlO5waCqSkqAvRbra3sZ6alyDw+/gkP2ByMhKVRa20rWNq8W6liQOqLal wSjH7zP9sLOnEQd7qNDQ5Fudw/tavGWNUOfwNAt2QQQXue9U5g/udoW2zodB6nWVqhuW EozCiCq5jpkmVQKNKTeUg/cpqsdQIs6vGbEOsPILwk7ETnI56M0a3OTpSjLEYHxBKZWA azz3oVb30QlalgC0pZr4ICtQz7RqoqN5B4+qP8ADpeLenn0mBJ2GZaXj9qvvNOJTl+V2 k7+w== X-Gm-Message-State: ABUngveA/koT8dzbF2OGINkXbDEcX7geLQa3Ym+pU2ZkUPLrJisE4D1Dqf1UjTRZ9nZFvA== X-Received: by 10.28.58.14 with SMTP id h14mr2298361wma.7.1478020037298; Tue, 01 Nov 2016 10:07:17 -0700 (PDT) Received: from localhost ([2001:67c:208c:10:bdbd:6a1d:622a:537a]) by smtp.gmail.com with ESMTPSA id u64sm31399141wmd.6.2016.11.01.10.07.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Nov 2016 10:07:16 -0700 (PDT) Date: Tue, 1 Nov 2016 18:07:13 +0100 From: Job Snijders To: Keyur Patel Message-ID: <20161101170713.GP19772@Vurt.local> References: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> <20161101133240.GK1581@hanna.meerval.net> <20161101141229.GK1589@hanna.meerval.net> <20161101142807.GL1589@hanna.meerval.net> <89B7215E-505D-4EEF-94E6-DB9B7CC23A8D@juniper.net> <960A93B5-2D91-4247-B8BD-51BA7B38A9C6@arrcus.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <960A93B5-2D91-4247-B8BD-51BA7B38A9C6@arrcus.com> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.0 (2016-08-17) Archived-At: Cc: IETF IDR Working Group , Robert Raszuk Subject: Re: [Idr] Early allocations and other ways to avoid squatting on code points 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, 01 Nov 2016 17:07:21 -0000 Keyur, Patel, this is not a thread about -wide- early allocation... On Tue, Nov 01, 2016 at 05:03:22PM +0000, Keyur Patel wrote: > +1. > > Regards, > Keyur > > Sent from my iPhone > > > On Nov 1, 2016, at 9:44 AM, Jakob Heitz (jheitz) wrote: > > > > I support an early attribute code allocation for wide communities. > > I'm happy for it to have 129 if that's what it's been using. > > Of course, it's not my call to make, just my opinion. > > > > Thanks, > > Jakob. > > > > > >> -----Original Message----- > >> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of John G. Scudder > >> Sent: Tuesday, November 01, 2016 8:05 AM > >> To: Robert Raszuk > >> Cc: IETF IDR Working Group > >> Subject: [Idr] Early allocations and other ways to avoid squatting on code points > >> > >> I have changed the subject line to reflect the fact we are off on a tangent and no longer relevant to adoption of > >> the draft in question. > >> > >>> On Nov 1, 2016, at 10:41 AM, Robert Raszuk wrote: > >>> ​Few days back You and others complained that Wide was not implemented by anyone for so many years. Now when we see > >> it actually was implemented at least by few BGP code basis ​it is again bad. > >> > >> I'm not sure what you mean by "it is again bad" but see the message I just sent -- we were not asked for an > >> allocation for the code base in question (not sure what other code bases you are including in "few", I think one was > >> reported). > >> > >> When the question of early allocation for wide came up recently (I don't recall if it was on the list, in private > >> email, in conversation or what, sorry) my feedback was to ask whether wide satisfies the stability requirement given > >> in RFC 7120 Section 2 (c). Certainly if there is need for an allocation for wide and it can satisfy the RFC 7120 > >> requirements, let's do it. If it can't satisfy the requirements, read on: > >> > >>> So to me the problem we need to solve is how to allow early implementations for any proposal on the table > >> especially now when we have no two but at least 8 production BGP implementations (and growing). Forbidding it does > >> not seems to me like a solution to the main problem. > >> > >> I expect we will be discussing this at our upcoming meeting, although that's no reason not to continue the > >> conversation on the list right now, on the contrary. Jeff has also written a draft that tries to address the problem, > >> he posted a pointer to it yesterday, https://datatracker.ietf.org/doc/draft-haas-idr-extended-experimental/ > >> > >> Thanks, > >> > >> --John > >> _______________________________________________ > >> Idr mailing list > >> Idr@ietf.org > >> https://www.ietf.org/mailman/listinfo/idr > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Tue Nov 1 10:11:07 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA454129569 for ; Tue, 1 Nov 2016 10:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, 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 HMZ9YxfaKAOl for ; Tue, 1 Nov 2016 10:11:04 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by ietfa.amsl.com (Postfix) with ESMTP id E4EF9129562 for ; Tue, 1 Nov 2016 10:11:03 -0700 (PDT) Received: from [IPv6:2603:3015:3603:8e00:51e0:59a6:676c:7860] (unknown [IPv6:2603:3015:3603:8e00:51e0:59a6:676c:7860]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id 15DDB5407CF; Tue, 1 Nov 2016 13:11:01 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Jared Mauch In-Reply-To: <20161101170414.GD24817@gir.theapt.org> Date: Tue, 1 Nov 2016 13:10:59 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20161031205515.GA25507@pfrc.org> <13f73d9614a84dda8f679a0e393d62b3@XCH-ALN-014.cisco.com> <20161101170414.GD24817@gir.theapt.org> To: Peter Hessler X-Mailer: Apple Mail (2.3251) Archived-At: Cc: idr@ietf.org Subject: Re: [Idr] [internet-drafts@ietf.org: I-D Action: draft-haas-idr-extended-experimental-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: Tue, 01 Nov 2016 17:11:06 -0000 I=E2=80=99m for adopting this draft as well. I would like to clean up the security text, as there is a lot of history = behind the section 6 text: - snip - 6. Security Considerations This document does not introduce any new security considerations into the BGP-4 protocol. While the injection of unknown or badly formatted Optional-Transitive Path Attributes has been and remains an issue impacting the stability of the Internet, this proposal doesn't increase exposure to that issue. It is rather expected that this proposal helps remediate the accidental attack surface that incremental BGP protocol work exposes to the Internet at large. - snip - I believe it should acknowledge that in the pre-7606 world the handling was as defined but subsequently considered harmful and with 7606 covers the risks from this document. Simply put, striking the text after the = first paragraph and saying the handling in 7606 covers the risk SHOULD be sufficient. - Jared > On Nov 1, 2016, at 1:04 PM, Peter Hessler wrote: >=20 > same and same. >=20 > if adopted by the WG, I'd be interested in tightening it up a bit more > but that can be handled then. >=20 >=20 > On 2016 Nov 01 (Tue) at 16:56:59 +0000 (+0000), Jakob Heitz (jheitz) = wrote: > :Jeff, > : > :This is good and I support adoption, should you ask for it. > :It should fix the problem. > : > :Thanks, > :Jakob. > : > : > :> -----Original Message----- > :> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jeffrey Haas > :> Sent: Monday, October 31, 2016 1:55 PM > :> To: idr@ietf.org > :> Subject: [Idr] [internet-drafts@ietf.org: I-D Action: = draft-haas-idr-extended-experimental-00.txt] > :>=20 > :> IDR, > :>=20 > :> There's a larger conversation to be had about proper stewardship = and use of > :> code points of all sorts, but path attributes have our attention = for the > :> moment. > :>=20 > :> A quick draft for consideration and to motivate discussion. > :>=20 > :> -- Jeff > :>=20 > :> P.S. I'm sure there's a number of rough edges in this. I knocked = it off in > :> less than two hours after not enough sleep. > :>=20 > :> ----- Forwarded message from internet-drafts@ietf.org ----- > :>=20 > :> Date: Sun, 30 Oct 2016 07:53:04 -0700 > :> From: internet-drafts@ietf.org > :> To: i-d-announce@ietf.org > :> Subject: I-D Action: draft-haas-idr-extended-experimental-00.txt > :>=20 > :>=20 > :> A New Internet-Draft is available from the on-line Internet-Drafts = directories. > :>=20 > :>=20 > :> Title : Extended Experimental Path Attributes for = BGP > :> Author : Jeffrey Haas > :> Filename : draft-haas-idr-extended-experimental-00.txt > :> Pages : 7 > :> Date : 2016-10-30 > :>=20 > :> 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. > :>=20 > :>=20 > :>=20 > :> The IETF datatracker status page for this draft is: > :> = https://datatracker.ietf.org/doc/draft-haas-idr-extended-experimental/ > :>=20 > :> There's also a htmlized version available at: > :> https://tools.ietf.org/html/draft-haas-idr-extended-experimental-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 > :> _______________________________________________ > :> 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 > :>=20 > :> ----- End forwarded message ----- > :>=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 >=20 > --=20 > You are here: > *** > *** > ********* > ******* > ***** > *** > * >=20 > But you're not all there. >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Tue Nov 1 10:15:50 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 443811294D0 for ; Tue, 1 Nov 2016 10:15:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, 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 kuGAg2OvF6fG for ; Tue, 1 Nov 2016 10:15:47 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by ietfa.amsl.com (Postfix) with ESMTP id 1A2421294A5 for ; Tue, 1 Nov 2016 10:15:47 -0700 (PDT) Received: from [IPv6:2603:3015:3603:8e00:51e0:59a6:676c:7860] (unknown [IPv6:2603:3015:3603:8e00:51e0:59a6:676c:7860]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id 0D109540909; Tue, 1 Nov 2016 13:15:45 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Jared Mauch In-Reply-To: Date: Tue, 1 Nov 2016 13:15:43 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0104174F-3665-429E-B007-2E7D6A5792AC@puck.nether.net> References: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> <20161101133240.GK1581@hanna.meerval.net> <20161101141229.GK1589@hanna.meerval.net> To: Robert Raszuk X-Mailer: Apple Mail (2.3251) Archived-At: Cc: IETF IDR Working Group Subject: Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129 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, 01 Nov 2016 17:15:48 -0000 > On Nov 1, 2016, at 10:17 AM, Robert Raszuk wrote: >=20 > > An implementor should not be rewarded with the possibility=20 > > of laziness after they squat on a codepoint. >=20 > +=20 >=20 > > I argue that we cannot tolerate: >=20 > Ahh got it.=20 >=20 > So the point of the document is punishment for early attempts to = implement anything not to technically address the problem at hand. Thx = for clarification ... No, punishment is reading the IDR list. :-) You can look for malice and find it wherever you want, even where none = is found. Documenting known issues will help those in the future. It = may not prevent history from being repeated, but attempts to prevent = repeats are valuable. - Jared= From nobody Tue Nov 1 10:21:27 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43A44129508 for ; Tue, 1 Nov 2016 10:21:26 -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, 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] 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 QJRndpFBMcDC for ; Tue, 1 Nov 2016 10:21:25 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0121.outbound.protection.outlook.com [104.47.38.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 C89001294A5 for ; Tue, 1 Nov 2016 10:21:24 -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=G4SMS3/ntCzw646dlg3dfGUAc0ATxt1uQ8gWV1FgsTY=; b=OLaFQCv2bYQ7tB8vb/Zwyb/ZLgRqPSzncVC1R2nsnFsfTdLT+Dht8cElLx9UIxu+kUH1HOwthyKCsZ9mM9dpbcCA8rbhUUdqupsTXRkeoqgk84Zn2FCGO/inqCM29p7IxVIsy43tL4sRrULcADpF4hW4OsAMjenyfs9oQBihyyc= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; Received: from [172.29.37.68] (66.129.241.11) by CO2PR05MB2501.namprd05.prod.outlook.com (10.166.95.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.5; Tue, 1 Nov 2016 17:21:21 +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: Date: Tue, 1 Nov 2016 13:21:17 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: To: Jeffrey Haas X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.11] X-ClientProxiedBy: CY1PR13CA0011.namprd13.prod.outlook.com (10.162.30.149) To CO2PR05MB2501.namprd05.prod.outlook.com (10.166.95.147) X-MS-Office365-Filtering-Correlation-Id: 0f2f7193-3f3d-4d2a-f2c0-08d4027b8054 X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2501; 2:PoJH1NFaEr7pVvz2FgCNTkd2T7LLN0obh52TZLvcG2HKir4JjXzFpYCChnBKzJ7QxKPg1FFMKNCAa1yBhuku1okx0x01f6wLwDKmOxAfvctO3PNn3X48h7q2xpoJx3cDBjXfrcv1SxZGQq1RL4DRO3nmJurM0CgGtSmlSjOMwm21q3Mn1Tvn2OlTMP6ouoHTjdLKDKp3kFrSg4TapLbuUw==; 3:eaQjhva7sxvXCQAqf5FS3X10ngcgotlb/5xOGX3XdvzxizB3SiJsJClni/GsUffFsULL5OlyfmieKFZsGcZ/qyPKg3XmgN07VJ52Q6ov4YWT6MpBfvs+NW/TYQ9Ofs0lpGLaWYVUIlbA6l6FNyergQ== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR05MB2501; X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2501; 25:e9NOxtOhjWhn5nv+g+PoFsLMdEjjaVguvoz9qXZm1D6l7x1rpyXaLYOcMMnKwEOvzbcqUEfEDdmDi3k6n4VI6rC6vIcd382dxSuFROsNqqkOSXIA38OYklAFEFKTI46IxDCDE/knKLvnTrFikOg46QeIQijt0hmPXy8YDthdUtOqeFwJO8xNuZshYVbKs/3tdZ2HOkCqVHCV4s5NQkA/za/DnV+hYOulZg7Q0p5nkj2BM6sGkYRegYj5PPYtsMQmfFNAsCDoVN8vVUlLdKgxS8oqLfqQGEZpkNr4v9lAewgl2o3y6+sJN3R/yZEy3pg0ukaB02KKXanl8M5DjPeG2ra3r5HLfx7imvCF4w4s15bvbr3TgwI0npCvSJL9PLYxXRpL/tCAGAl9kPhkbUWYzaOuqzBIXfIidS7uZaR6PG3CtaI1xy26JcNySekPBGNM2aMbAtel0MA3TY6db7k5y7Ajhc3zzBbxLUk6IrWIKCpV+v/m+pToDkVjUyr0egXEMNOWP6ed7rgl1NTu+4ItFMCnorlJCQwfExlh7w/isrxEoMPYI9t3+P1pnPfBNFfX0sQrQ+6EN6ZcazALvuAu/S5N4hY2wYnM1vlMVIC4hnX5/NqoR7kBiiz0qS8cLx9rhDAuoHcU928leaxshV36jehuPaQho4g63uQ9yUTpyHB1plwDal4DczXaeLa3kYMXhTOvjjGEoOUegggLLBmnKIJUJsuofw7WUhQkp0Mzxqw= X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2501; 31:Dyt77PiV9Fs6VwB99qB74cIrIj/UW7LVB2EvNT/OOsKo3SgpRa0PyQasR/RZqlqPOeIHNVB54b6R49CsQl3k67aHgLiNYcx9twWJYDPEU1BVBu+Pik4DWGKWYqZMdd2+uJBx7XZ2+Vh63kel8IRGPPSaB62ngJW7vHoWprX9peilflYCxsvDCS8ZTkHCgrq82Isd9efOy5pmIGNu792zI3Cguu/iKBygSg2HDV/UDVGbPtdlCeOnppNCjaYBBgNX; 20:8bFK/TPXoWHKo9jCqz9Q7xcs1ULvpJWo/VudJlNyfCcRCUiKZxbrM6A3Aq9gNRBwuhRNAbOiCpLNFJhmOyutoijO7gr1IrNRGSc3TFWV3Cr/3Btd6Wyxc3KF6BGAxv1dsGDKkfSWIClWDFHgtMpQ/Qc98TF8UWTtS/qONGDnGcPAyrdbvB9Q0aJeYCy6VZ4cNCn6Excre7+bcfXK1lRJfm+u889B7QxcdIGVjn/31wXqqvQ6GT6Y+1WmUIPv1kHsnq23ChOKIGX+OYCC9TVW1+kN4FecYt3JZZv+yc6o/8OljCidPfykk46wljwzY9/lys7c9+Y8i3O63N/nS8LX811z4F1hJZuLf0QJM15NTCKXh9Uu6StLUyzCNveEW6aVet8hANHDBWW8l65BHOaXGusQDBigHI5Wm4KbJSR/PVS5tLxEZfvBZ+1ed/e32T4f9oRhe2DRQZILhyQtOq/y1iQQfoNZiKIXGVBlyLQQ6DNvdZeXRjDOUThXkuBDQZxPye2C42nfSSbt3SwhJ1q6omxityfOSwpBu31AJbRZuSaZ63GXGK5xGl6B23E43NIq6ZnCttEhBY0krKO/TXBBsgfcK1lHLTuKWDrRK7BySXU= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:CO2PR05MB2501; BCL:0; PCL:0; RULEID:; SRVR:CO2PR05MB2501; X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2501; 4:7AGSzpR+YtNZ/mqEeSaB0O0wBU5esYIpOU5qJ3RsTsfJpGrRVB4R6MR3dKrBrGnw2eQn14ka6kGk1wPbTn/4/7UqpU7PmJZl9lb9e2PWrG0WjaQB8ft3QfaEdbP0EEB1d5qumt1LtQ6gSMMz/byIaI19hif8ZDCVWkmbWXdi8W69TyU56mkKaO5f1SkYP7bfp+jfgjIil0M3voOxRnv5RDNUe3vp/PDHiTRfIPQqts8JZ0GRpgwRK2Gz/IlnDMPYLyJERvdHeFvKJ95WCXxtcn60SDETZQ28kfuGs4p2/IyeR3jz6KOt3pY3OOFWbCf50tw6nS6fvQftnTpmRzm5unKJDENr/NnnX/aQfT/B7P7ZfiloV7vfJfmFgSjD1z98SnmLKBDnXfugdf8Q5vrCkcsjn7Bq7sKnRuS9OTrZZCU= X-Forefront-PRVS: 01136D2D90 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(7916002)(189002)(377454003)(199003)(24454002)(2950100002)(82746002)(4326007)(86362001)(7736002)(50226002)(7846002)(8676002)(2906002)(586003)(68736007)(92566002)(8746002)(81166006)(3846002)(305945005)(23726003)(77096005)(106356001)(97756001)(81156014)(6116002)(36756003)(230783001)(229853001)(101416001)(5660300001)(83716003)(42186005)(105586002)(19580395003)(47776003)(46406003)(19580405001)(6666003)(76176999)(6916009)(110136003)(66066001)(50986999)(189998001)(50466002)(33656002)(97736004)(57306001)(42262002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB2501; H:[172.29.37.68]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; 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:WY7dgeLCvpus4vMPrtfR7VSpH8L0reNsHl/1lsMVX?= =?us-ascii?Q?sv5/94T/6w52wp2Qh4HCkX1+FsKs2pVddi2YV92hqNVHZg1lnMOTkF1OUU0z?= =?us-ascii?Q?d82YWFgRqsvGwVGICFvOV1ixMQRcRCE/QkMhRmUil9KzUR1aqRciY54ud8Qn?= =?us-ascii?Q?AduSSIlYR4PgvzacX9iBWJuIECawLve/PLPnhvCK/at1/0yII5bfZhOuffNd?= =?us-ascii?Q?lLanDSDKlI2gTWQBnytrYw41Vd3sr23xZM8DElkXsY+Ph7sZFjMorxu9tYhf?= =?us-ascii?Q?jyEbahsmyA8P2RarXo6hkni6k13a8WH1kpLMGiwsFsgHR3L4k85Co+y/7Bdk?= =?us-ascii?Q?wnF4ACi/59l0JaPSZuulsOrDsia98BfuUTEvpfU0YOIZMVx/cXcrYqwP+4LA?= =?us-ascii?Q?vCBnqb52qsHv92m94Lpq76csK8xNMYeBgitNd+In2A+27JSkZlzCaX19rvvY?= =?us-ascii?Q?+6XZfs4EB56WhiPgPg9lEfW8sNSXXQZ+InQHBthWGBKvxs8HiagJNgt6goew?= =?us-ascii?Q?XGRJK4lKsPXmcU4beLlA81KE4aG5phFw9XB42YkY+haIevsbJiatVsyRSOIA?= =?us-ascii?Q?nKSIASIN+sn3fT350d4Jtnd5juKuKEhN1TokgYif+Q+lAvMuHP5JZKAo78rI?= =?us-ascii?Q?2kgbetD1ahspAD72y+wnDNmAhAF2P4uEJXfcMWZHo2M/qU3BMJ0Zbq+XigR2?= =?us-ascii?Q?x0+pconb98VNnADboat2EP5nOk1dqcViAZS5TuVhvZMlVu1QfzgoXyO0tG6N?= =?us-ascii?Q?2bW2rUmhOMaxkkFofVT1UqjUoQ7VWtBOyyYT6frA8ZWSJndx0w6OoFSnmOcF?= =?us-ascii?Q?WNrm+C7qYywlTbCAoXkq2sNnewIl72up/xuZQ+MX97Hxru5pZXKq1wzpgt3R?= =?us-ascii?Q?9Mray7kJZWY+A0yXI6yuHgwqDk4mXZOQ46V3ufqEK9LcuQETi8bvtyYZVpZp?= =?us-ascii?Q?DBuobR6IbCSiJWnqMMEbjsT9JTFbjut3SdMS6KrJ/JoTbhuzySXLSzL7jVN8?= =?us-ascii?Q?P8XCIlXD2KbAchKhgjRLk0isn2avfg7olxJIh5qrVcCGoU6XRQX5Edr+/VG2?= =?us-ascii?Q?WMc99dxoPNgqutd1+reuKV87e09AEnj0cYQEEcNeg5MlZNEJitK9GINrcCiu?= =?us-ascii?Q?Yl84lFW405bm7iNo3ZaWlbCl2ewfCYypUsLvVfSEmv5jJLnOi0yErxJ8Prnx?= =?us-ascii?Q?7ksEz6FFIwPeFocsw7Xsp0xM4SeIcYLb6F5tFGuqknMyNiI6kSwYrlcvdN7p?= =?us-ascii?Q?KuMdoXkfjuVSD7OKaPs4hm9FzvdTZA2TDQFRo4W8eEbGg5WkxyApnYkgkmbi?= =?us-ascii?B?QT09?= X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2501; 6:sBxHN/U0XPg+BoTQ/mH0Cnvo9oeQcWRVoxOGveVwFccTJGlU8MeosXp/ZuH49DaYhNfrkx8LZIob1TCF1RSNsVLPQ8NIAwTicb5w1uO25vTKmKxvgwHmZjYCgVyHFDQekoTJF7QH0HjKg4/KiA5xdDMHuIJH4xJhBti9dpJARVgVjwqTwjWa8rbPfqX4vePKvd4rL8FM03TH1izipKC1Rc3jWHvbOpWHrSM6qDyCWZX7LzcCidPEFh/mF+K/wb7syh8fR6Yj0KhGhLAXgKOFj6CuJPgG2qKUuEEbjHu9ZlRX8a+c/Z0O+/9eggfopY1YjhCwCDCv6XktT0hEn7RHJjyz47n1Mv5J/obciecDCfc=; 5:f9fFJ1DjtwznJ4F2/4m6ShdjMu9JnkDb1rd1vCYMsniPsvOfAksd1wS1Pt6pQkQTOHtqgG/TZjxbogljcB5liKyVBGra7zahNptaqu6fQodp5sGjbadEAvpfqsVlMgzeB2dBGQ9zz6eJ/376djEWyUJ2a9WUKI4ybPOpzJkGPuc=; 24:+Qje+59n2s/J5v8fK/KOb5KwH/GNHlj0c6zloRVjdkV58vDWv4Z8ddgaH8QU7g737Ze4t4rKLxhg57V2NqUhk/zhto9vpQHYjUu0DdYetMw= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2501; 7:RVjKRfEjK+nq9u8sKaao+VAJecbBDGP16XaFqZPw/NacguPs7Zw4tKRgQdXsy720UcGYy4Mk8mRtEDVUeJtnKFkFnQHEa4w6YZWzeD7WUp3XxIbF5BRwaVQVfH5hDlu6MkqG8WOYo3Mz2S5PrPirazzNZC5+uxGy1lPk+4/2zjG/X+F2yj7BEV4Ujb/Z6zB8CVZRvzoRKvqqalfdlBBuoQLZ4zUzmYYGM0rvUOg9OmLJeclpjmsmrjhpjz/rfytfh2VWVyDA52HZ/b/7642ByF9mltIdMwQNiqup7Av7s3mVqDEv2PaVVNorAZ2r2IUrNK+s/T0ZLWdFJkPgAzv6oyDWDE2WvgynjuFAUyF8ZnY= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Nov 2016 17:21:21.7921 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB2501 Archived-At: Cc: IETF IDR Working Group Subject: [Idr] early allocation for draft-gredler-idr-bgp-ls-segment-routing-ext 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, 01 Nov 2016 17:21:26 -0000 On Nov 1, 2016, at 1:05 PM, Jeffrey Haas wrote: > there are a number of code point points in this document pertinent to = BGP-LS that need early allocation. The chairs should consider that as = part of adoption work. Yes, thanks for pointing that out. Let's please consider that as part of this document adoption request, we = should also discuss early allocation for the code points listed in = Section 4.1 of the draft. The registry policy is "specification = required" which follows the same RFC 7120 early allocation policy as = standards action. As a reminder, the requirements for early allocation = can be summarized as: - Stable spec - Sufficient interest We will conclude the early allocation call at the same time as the WG = adoption call, on November 13. Obviously if we DON'T adopt the document we would not pass the = "sufficient interest" bar, but otherwise I (switching to speak now as a = WG member) would support proceeding with early allocation. Thanks, --John= From nobody Tue Nov 1 10:23:19 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 485701294BB for ; Tue, 1 Nov 2016 10:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, 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 3cbri3wLcLB5 for ; Tue, 1 Nov 2016 10:23:16 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 4C53E12947C for ; Tue, 1 Nov 2016 10:23:16 -0700 (PDT) Received: from [IPv6:2603:3015:3603:8e00:51e0:59a6:676c:7860] (unknown [IPv6:2603:3015:3603:8e00:51e0:59a6:676c:7860]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id A15065407BA; Tue, 1 Nov 2016 13:23:14 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Jared Mauch In-Reply-To: Date: Tue, 1 Nov 2016 13:23:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <385159CD-1C5F-4508-993B-D776FFF17C72@puck.nether.net> References: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> <20161101133240.GK1581@hanna.meerval.net> <20161101141229.GK1589@hanna.meerval.net> <20161101142807.GL1589@hanna.meerval.net> <20161101150148.GM1589@hanna.meerval.net> To: Robert Raszuk X-Mailer: Apple Mail (2.3251) Archived-At: Cc: IETF IDR Working Group Subject: Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129 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, 01 Nov 2016 17:23:17 -0000 > On Nov 1, 2016, at 11:14 AM, Robert Raszuk wrote: >=20 >=20 > > even if the implementation is compatible with said specification >=20 > Well I think this is completely different problem regardless on how = the types/codepoints will be allocated.=20 >=20 > > Maybe a pragmatic example will help clarify the situation: If IANA > > assigns Path Attribute 30 as early allocation of > > draft-chen-idr-geo-coordinates-03 >=20 > That was not what I have tried to express ... I suggested to assign = all detected points to the drafts they belong as early allocation rather = then to deprecate them. Result is the same - geo will not be allocated = code point which is already used.=20 >=20 > So is 32 final code point for Large or early allocated one. If what LC = got is final one why geo would need to ask for early allocation vs final = one :) ?=20 My suggestion is that authors should promptly request attributes and = disclose which ones they=E2=80=99re using in testing for documentation. = It=E2=80=99s always easier to help find =E2=80=9Cwho broke the = internet=E2=80=9D if it=E2=80=99s written down somewhere vs tracking = down BGP updates, but both have been done for years. None of this seems unreasonable, but some of the positions coming from = you (Robert) seem to be outside of the WG and industry documented norms. = I saw a lot of this during the -large- vs -wide- discussion and found = it troubling. I=E2=80=99m personally grateful for the WG chairs in that = discussion, as well as here in highlighting what is outside the WG = process/norms. - Jared= From nobody Tue Nov 1 10:31:46 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E989129508 for ; Tue, 1 Nov 2016 10:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.913 X-Spam-Level: X-Spam-Status: No, score=-1.913 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486, RP_MATCHES_RCVD=-1.497, 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 w3E_r8xqYoEK for ; Tue, 1 Nov 2016 10:31:43 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id CF76C1294AD for ; Tue, 1 Nov 2016 10:31:43 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id E5B121E337; Tue, 1 Nov 2016 13:34:14 -0400 (EDT) Date: Tue, 1 Nov 2016 13:34:14 -0400 From: Jeffrey Haas To: Peter Hessler , Jared Mauch Message-ID: <20161101173414.GA19036@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20161101170414.GD24817@gir.theapt.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: idr@ietf.org Subject: Re: [Idr] [internet-drafts@ietf.org: I-D Action: draft-haas-idr-extended-experimental-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: Tue, 01 Nov 2016 17:31:45 -0000 On Tue, Nov 01, 2016 at 06:04:14PM +0100, Peter Hessler wrote: > if adopted by the WG, I'd be interested in tightening it up a bit more > but that can be handled then. On Tue, Nov 01, 2016 at 01:10:59PM -0400, Jared Mauch wrote: > I’m for adopting this draft as well. > > I would like to clean up the security text, as there is a lot of history behind the section 6 text: Feel free to suggest patches: https://github.com/jhaas-pfrc/extended-experimental > 6. Security Considerations > > This document does not introduce any new security considerations into > the BGP-4 protocol. While the injection of unknown or badly > formatted Optional-Transitive Path Attributes has been and remains an > issue impacting the stability of the Internet, this proposal doesn't > increase exposure to that issue. It is rather expected that this > proposal helps remediate the accidental attack surface that > incremental BGP protocol work exposes to the Internet at large. > - snip - > > I believe it should acknowledge that in the pre-7606 world the handling > was as defined but subsequently considered harmful and with 7606 covers > the risks from this document. Simply put, striking the text after the first > paragraph and saying the handling in 7606 covers the risk SHOULD be > sufficient. Time constraints aside, I thought a bit about this as I was scribbling up a quick security section. I think it might make sense to do some level of brief overview of the issues RFC 7606 addressed in prior sections as part of the motivation of why we need a bit better sandboxing of early work. Section 1 covers this to some extent. However, I'm not sure it belongs in the considerations for this document. -- Jeff From nobody Tue Nov 1 10:34:17 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0911279EB for ; Tue, 1 Nov 2016 10:34:16 -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_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 a8uR3JrroDak for ; Tue, 1 Nov 2016 10:34:15 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0091.outbound.protection.outlook.com [104.47.33.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD9E31293E4 for ; Tue, 1 Nov 2016 10:34:14 -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=61jsY8OvDdTT+YA+x4toNsYiY+rqp67n6UMm/PHnXXc=; b=gmCG5+k+nQ2QZLSJAi/jMLXD/5nh2rCTLMJ/xEILRttw666ce7zc+q++YbkvRqO6Vk/A42Y68J6ECrybBEmF2CENVtHY3UdYmoUR4Qy6aNUn4zuGH7zbkrO06cDAq91726aAMD9Tlb0ujUOxmQFidqklMXveg5EZn6E8HEaD9YM= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; Received: from [172.29.37.68] (66.129.241.11) 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.679.5; Tue, 1 Nov 2016 17:34:12 +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: <20161101170713.GP19772@Vurt.local> Date: Tue, 1 Nov 2016 13:34:06 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> <20161101133240.GK1581@hanna.meerval.net> <20161101141229.GK1589@hanna.meerval.net> <20161101142807.GL1589@hanna.meerval.net> <89B7215E-505D-4EEF-94E6-DB9B7CC23A8D@juniper.net> <960A93B5-2D91-4247-B8BD-51BA7B38A9C6@arrcus.com> <20161101170713.GP19772@Vurt.local> To: Job Snijders X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.11] X-ClientProxiedBy: BLUPR17CA0035.namprd17.prod.outlook.com (10.164.14.173) To CY1PR05MB2507.namprd05.prod.outlook.com (10.167.10.134) X-MS-Office365-Filtering-Correlation-Id: eeb69139-1634-436d-06de-08d4027d4bf7 X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 2:5FmqpDuz7iwGtSBsj/OCovQFWasephOsBruAkYSqvwcuvE/qHU0M/vtf9BsIz05kjlUyDRK426/i13lFnOn6Cp3J1FDlbvTM1UXdjQ8ETeGQ5Xawd+4CUUdd2fsJrpUemq0i1imSAm2jzh7teRNWqhm24rY3p85W0aaq5/1zIZqA/fkrICFOSYzwSX9hUQKqMEw+PgvLDcTNwQA2YpBweg==; 3:XipxG5ghoVAet4owxSgZ7kkOvc0Lz1HRC8Kf5SDvd/UVw7dFmv23AdwLR1Cjp/0KZGw9weqz58lLHpkCe7OgZcSM06x+basaiIUPjvrgLr5NSuAzkf9SwNBTz1XGVjvE7hgKuWTzArmeAb7xzL24rA== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR05MB2507; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 25:B6PLyTu4U0hQKPIsGMRURQWpJx47aRGlQmuOaI2KrvYUR7EwwtGzoN5u8LxSx6rxtHpgCI0B5b+o0TYsUolwMJ+ZKkP+TkxgI+/ca5H9hM+ur59pjCLt+4cbh9QqNSd1Kjv/x1f+ANIF/RT9y1315Cq8/iVou4TtcEDtIYxgZi4RCiVIX3SFNQXQQD18No4+G9RU+1TD8+E81PCyt6oSBXc+puaqUsuFD4r7EVqEel3YP21VVNLiyh2sWN3sWdDT1Cjqyw7AFg4bs/wtTAqL7AyloSgW0+5SWbSRo48vHzQsvaAI25Iizo3pPiIsnPC79DQVpE9BLCr2rp/qR4tDRQzAw9W/5pUWFvlLlNeZa+Ak4D1WoafUenV7bhgYHw1IzlEsr/p7RAskupD1LM/IbUsSF9oeQNGDFX9TzztRR2DuvZC2dTjgPdAunKAx6osxvVOs2IKqswdA5EPp/tca6DxghqR6rdYo13iW5DlCXVSMnyGHcDBnv74Pe4ZzD/nhDL2Yj3Ckl3QNfDdXa2ncZz49VUvBdTTI62prTjCSkiLKzYKRdKgBYvjzC+lbA1kLEAwDka3naYYTHHcwY6eu13f5h1DylL/yODK6od0iWsX3EJlOo+MatAN2qu3aoW6SAFnXnJzOp1Bv+/rd4NJgFMDvS9EsTi0hMuKWpubn4fgj3OrGbMx+PQflFQ4+M9Y3X0OzGLgoUV6Mnbe6ynS8KeBFWy0mqPY4XUaEqlxSWGs= X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 31:d/h265qQnQHNplXdACRQ3e0kx7dYIedTwvfmrNf2PdF02FLHZoD3ndagY54z5oF+62enrRAPYUARtShTCC65HDtBNWUd+rdxLA+BlfOPT8daRd+xcAmQk65IP6qXM0/zde7H//GjN02QMS0NUjGAQ1b33jqn+AbucPNHE71CWPirEuwfshS35CB/oQCVRVpmBkNtJNK5IT2uUSMScqzIyvSzcKfAvDl+NO3CtOFujreOZDHrY5xfXVJW+WQ4dgvuiE8mEeh1waqIWi2HxdlvHQ==; 20:9hpQJW4wAuO8H2vTPLVZPPX0xDvqbm9rRRg9LGe2kGaWhwlt2UKU82Fef4jCtJRgGoqPxOjbmCtYCoZzKP1mXxvGG929yOmdyfs6Y6KW4UI4g843oqbWRNFnQLTCH4y6QIvuscfPARB4CQNHVLwqzm+424Nmdo42cs6cfiNG8j4NzDtXxyc4yomlEoGoGj/kZSP9DUEjo/l8MJOFTh4mva0jo4ZEXw1zIdq739V9slaqkKyc7Ys5w6UocGUdH+ETv0OKPZS+LN5FOqKK9G87KIsKVv/n+qtObeu/rq7UObAOPth6+ZxyL5wQzx/Z9yfXANiWuY5MD/LifZH016HrQteTDMR9Gy2S9Vtfaqo3LivoqJ2uDoZkQ4/XHToaklDGsXqr+a5seeUdhast70+ohPH5y5Ld6jpLGpKIrgm9BCf4cMKAJVgotl/9ub1s53puCfgeYkqZWtZH1cIdc+AaC9dx3jPyxmwcBQ/RTpu96yxGigQo2RVwQUD6/1+X3cmKf2rBZ8L9tXjDR5UgOD8ib3ZdS5wP9ZSjdxwVEMfjG+XpYjllcuxkCtv31+asJJ0aUvucma8FzYkCEiKUzYU5uF5GAUqpA6OBTrp5J5dVnJ8= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:CY1PR05MB2507; BCL:0; PCL:0; RULEID:; SRVR:CY1PR05MB2507; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 4:53910T/3a5y3ixSKkLdEAcOjU6duNmqvedgqH2YTeO+zTwy/sMmsUqEylu/qWcfI4InKUa8A0Bg3Zlnjk9WXnRrOW+w4Yn00G2Qq2hXE9vgnL3vT8wXZZOzlNFNuhV7k84FC7gRt9s5DEpUrprHFode6KJnnNXtNLxg94HPipJfu3596ZPyyOKQXQPuSN/Qnh+ymqfm8cMXL0ngtdoln71+QpZRSKkKt20DX+sExpPonuLVmI8He/PTZpSYnou0M67n/10o4tNJTG5psBPgqsZ10Q2bS85E3sUK8v5JjDPI3hhllRxbDhn+G8jJHb51RYhUy9I6mxhqntM2N2jTWTWojkvvJdNwz1H4TsqGB02W+jJ05X7ac/Kj6hmZ3MFIxOfuUWk/H7fTe+2bSbZVJMgV88ztPMDoUW2Hg6llCxUc= X-Forefront-PRVS: 01136D2D90 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(7916002)(24454002)(377454003)(199003)(189002)(82746002)(93886004)(77096005)(23726003)(57306001)(86362001)(50466002)(189998001)(586003)(2906002)(7736002)(105586002)(46406003)(6666003)(106356001)(6116002)(7846002)(92566002)(36756003)(97756001)(76176999)(33656002)(42186005)(81156014)(19580395003)(81166006)(66066001)(50226002)(19580405001)(50986999)(3846002)(305945005)(8676002)(47776003)(5660300001)(110136003)(97736004)(8746002)(2950100002)(4326007)(6916009)(68736007)(101416001)(83716003)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2507; H:[172.29.37.68]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR05MB2507; 23:ThcZqZjBYzX4N9j/a2LcHKV3MJisVqfMPzVEHaPGR?= =?us-ascii?Q?WpsTTUaIU2fcw89TvYoUUrkYjxaNQJolUTlwo0uiJdVjOPdhqT3a+4YWkdIU?= =?us-ascii?Q?oUldu+QMkRg7EuPcz32awHnRcJ2iZY6Wn5fgMR0BCAQ9l38YfVTNz0sklV7k?= =?us-ascii?Q?dquRvdMawtISJ2KTuC8RHh7V8FJkPflxhSVty2Rrq66DZzIFjZyolOWKo9ko?= =?us-ascii?Q?r3P6/TLRQMCX96EzWzAIDmDydPxLhlMeLjrC3WVdsvDdhVs4zE3FnB32xGea?= =?us-ascii?Q?qqPkwRtrgacnsfATsKXZ5HsPmIfYyyG3CN5LvUMRtiqaMijrPw3QVxFmPOLz?= =?us-ascii?Q?olJMDCziV/tsIXNYsEk4VIN86RTIWySx2aoS5DFZ3JNAN6mgjcghznK146nr?= =?us-ascii?Q?pfn4nSPZyWdkMjHa1KPrah+yle4c7Grp6ns+HZDfzxXUzI0c0mfcVItlzqIV?= =?us-ascii?Q?+2hG7eq3WfqIJFDQMJMVOTcK0t1uVuNy97FwHg2vjqzqY0bvPL1mfmI6XEjb?= =?us-ascii?Q?OzzYhcLQwxAVhjM0Bny73Vv/7aInlALW6S1Ieb00ECBcv4pNucaw6x+y0UHv?= =?us-ascii?Q?Q6K4SVNJ+4M3NtHs4stzCEM7gKY9X0bH7p1lmTIJzh5z+kKcI6n3sC4+0WPQ?= =?us-ascii?Q?MQ3+OdRZPij3n0nlC3PYjeW93YUZqxfeTxfUjWIXndPq4C3X913GIw0epzLU?= =?us-ascii?Q?H1/uV6aSEYH9xvXYe73KPU7FvLrryEEort8v3itzxydwvmzSl3IKYzZbjM9h?= =?us-ascii?Q?lT2vGc+4C7Ac/qF3FxghJMFH/vvpWP1f2igN8aLXL8Cg5IOxecG8BnKUoiuG?= =?us-ascii?Q?6wnw7AQ5MbzVnnqCDi5XMkDPWXaOTUGj4XDZp46Ic8HpE9Qv3VzLJ1qERTak?= =?us-ascii?Q?n/7qsy3s9r4KFLKHj0ae1dzsDkH37hgBC0DoCdDxbvowFKgyrYOcS5YenAAn?= =?us-ascii?Q?MPZ4Gza+l5HopoHxq1UU0Ol/ZsMaUPbVqYUSHKdxbKEzqepq4Yy/4XJhW2/M?= =?us-ascii?Q?ob0e3UXLcr6rituTu3uqco+8JTdCInC+lDgIdH3Wxf4je85U4z1Fpg3oTiSl?= =?us-ascii?Q?eyzoiDWzjK3AZsNVCzENtD8JKB/a6fgdYe/B7TeUvhL27t0zWD7JFD/oQvTr?= =?us-ascii?Q?xQWujzj5Eb11cgJLdkbQiLwiCbIvclEDEy2m+pUOVnHpeB5Q+iNCOHDwuy6F?= =?us-ascii?Q?TfaKLsq8jHx9QSxpHnY6ooxclDXqQo9uPFdRDNj8eXN4fNYmC4We5MlvnFKT?= =?us-ascii?Q?QhKvn612Z7LonFuw6tPCAqUiRCtPukTF85yNgaf?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 6:UhX5gkP6VUTvTtHZXkNAQo8uULeMu6ZDKAoNyTUQP/ra0cZ7lC8f8ppIAXAKb5p6/1LGU06y+ttDvFQ15lpzHawEJEmbtm/w9AqKD36LsJ0UezO7QcKxky85f2TQkyPEPsSv2V4q8wZ5KPTQwQ+FJOydZsOz9iVGJNN+5uoJQzqv4fda3JvBlmXw7TDll8NK6PTaQ3N5qIiZDSmyJRqn3papgNzLIeCfEkGEcJPQmHara2SAChBBI7Mdj+sAAKRDeMg5XwI2jN8lB7QJr+JvHJ8Y+blBuuFCqny18rjnt29uNOCKOvDderJigBp0VzHbS0VcxL10407ik2irZhmskA==; 5:IRQg5lSS4hxZTILNovB4VJDEh2TsIJBwh55V/b/ljIHHtJFSkk35TVka7KWFbXqK5qRaA/ciE+A07rcKrpagBU7OjIHMjqZUn8N7Ev1ZxIzJ7a1GVHp+uxus7x411WYnUrp2jtXhU7RBRL5J3iO3wDVNh70XnYT0nZxOdKsApnQ=; 24:ZColk91WkZZTgB+KR0ftEbrqxHocH2WI8NX81hXZHDgSXThgm5sJpPhbmASbG1+PFiTCeMLiYSGKow+lGd7p4bKcrjnCEp2htbZ9kitYwBk= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 7:KactpFGy1QiuHoHgda5XiyAXJaoxDkBs+GrVfsdwu/G9b40B6onMKWDncGlLfuEge4B2Ir1dpUmf8k8o6KEHVARODk+sc9+b5zkdtrdGr3nitcCDz+I/u02sIQ7hUW+Vv8FW0pZtAT1l1wbShDCdrhx7wBDPHgkBujsIikIUYjcWSLljuL/vBqRj9EDBAnT+LDI9HelNTvw1Q/fBj97ks69YRGth/DrvJCuLBnSpxVxY9sfJQUF7F7Z2z4ZoqWE6DKZoXP5KCsQmxwITFrsKpySB44xjVoeIEEBk3vsQnLgAQdbWROSdJPKDXGPQR2dX8SF5sJkPQcFN9R9ttp+UodMsPCzuTyvh5j8p4fK23hc= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Nov 2016 17:34:12.8285 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2507 Archived-At: Cc: Keyur Patel , Robert Raszuk , IETF IDR Working Group Subject: Re: [Idr] Early allocations and other ways to avoid squatting on code points 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, 01 Nov 2016 17:34:16 -0000 On Nov 1, 2016, at 1:07 PM, Job Snijders wrote: > this is not a thread about -wide- early allocation... Right. Also, Jeff (wearing his coauthor of wide hat) just commented less than = an hour ago that wide's not ready yet (per the requirements we've = discussed recently): On Nov 1, 2016, at 12:20 PM, Jeffrey Haas wrote: > Robert and I will be discussing reverting the most recent changes to = the common header in our attempt to get that onto Large communities. = That should put the document back in harmony with the likely = implementation. (That, and removing code point 2 since it's covered by = Large now anyway.) So, please curb your enthusiasm while remaining ready to provide support = for an early allocation for wide when the authors are ready (sounds like = that may be soon). Regards, --John= From nobody Tue Nov 1 10:47:28 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13659129617 for ; Tue, 1 Nov 2016 10:47:27 -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, 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] 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 mfNSBj76IvSo for ; Tue, 1 Nov 2016 10:47:24 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0122.outbound.protection.outlook.com [104.47.1.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C411F1279EB for ; Tue, 1 Nov 2016 10:47:23 -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=kShj89TDEVODve6+0rWrb0bU+in8eWeVhGBgROhZhIE=; b=CSd2yuSgzkQrbalomPY9CkR1M13G3Fa/n/9KblatMzdzunlDdQnD7GGPZHl0fEnjf7+ojConxDknxMFBhpg5+RV7cibig87X8BQvShmcZ11xwFOjAh7ip3nKu3biqguPMbJuynZIl+g17T4snbUaiLEDXJQlTTTVwJ0ME6Dov08= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (81.135.210.62) by HE1PR0701MB3002.eurprd07.prod.outlook.com (10.168.93.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.707.1; Tue, 1 Nov 2016 17:47:21 +0000 Message-ID: <01c101d23467$9c8b0cc0$4001a8c0@gateway.2wire.net> From: t.petch To: "John G. Scudder" References: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> <20161101144036.GB10519@pfrc.org> <25D24BDC-5322-4B19-A971-9FDD65C07BF1@juniper.net> Date: Tue, 1 Nov 2016 17:44:27 +0000 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: [81.135.210.62] X-ClientProxiedBy: DB3PR05CA0020.eurprd05.prod.outlook.com (10.160.41.148) To HE1PR0701MB3002.eurprd07.prod.outlook.com (10.168.93.136) X-MS-Office365-Filtering-Correlation-Id: 9b8499f0-b93f-4775-3726-08d4027f21ac X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 2:P+k/WMnc90/BkT6TuvXuQQdVZLaeiyboahFSt3Y4sjT6SyIirXg6V0GK4ZAbLHtJvXcdSo9jJG8kRUIc+PeAZcw4hdeGjJPwGEnFXaM7grSoR1Ype01/9dJ1mVd5hoKKjMVXNEFlqazJ+SF5xwLkQLfo2nomkmcCyUXaRUSmr/Hh3poDOS2LGuP7qMpDlTPZ9vlxPzShlo3lgIVVokfQsA==; 3:qb4MZaF05gzj4vBgyKW4SAAv2G+WWtzbiVd4Ixyjzv2AlrIWtAi6LUNdFGnsUKnodi/y1Q6tYdHZ0ZK35tEi5r0v66TXNZdmjMIgy8EP55Us8XPJtmNBbkp7nY5DSSwVnq/uI+yVrTMjN/xN2cesYg==; 25:xLaQSIujpy5Y5q/E/Z+GphnEaAn+4v1hTwfATgZG9GuG8aMCTi3Bm3QlmEibwNjhY/GzS6oFuDBF86mx/oGwCEwv6x43sFZ2HZfwRmg/FGTN/BsZWoB4kOebJImK8hNptsMvf1cIPb2aArhjDd9H8aACQDWQgLs8vagbZRNBBxEwdSMyBoxAreKFO1v7GtupGGNocufQn8Vszhor6DgyZW7M8dpfmKJ7GugCp1z31liJ6mJBVwio5MFcLWhn27ZnPx79PVsI8h2aHRBiNqbNFKbQLIH16SUed1RxPys+/kA3WVzBG0j142agnLJfoBn9m+dPgjkwetpjW46I1tUf4S6kkjoExoLC9sujQc5HAHhHu85xLO1xo7uyn114wKVXZC2ELyZojLNC0f4E9BLOSykPhSe3pWFCGn/nxJdgyUpM2mWCbswtp1wsyNtE32fZ X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR0701MB3002; X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 31:emUC8Pn4rqnYNU2SNoblq3FaQIlMFeCeyarGchaZ29KNJNt/6dy0BkQViI9ubVTcBt/ou/+0+t5UNxGBsiDHsBnd6JmehoI/4YQC+k8/qZaCMk0QYbpW6tsQP21YlRXabEYinHNhLhfsCk157rUD+KCizlhaeE9F05uCAGPsVisTEeX6E5F4iWlnYqVZnFmWLcS9WKfoEMJ28ffNTr1OXb1YeX1iKwRuJiLy5qGw07we2HMR4jsF+PvnMPjRGZiD; 4:0i9KRVLl2+cV/qxPd23n1E4grClhS/XTQ+Z6BaneknbGIuVX8KK+h6eVvpshcmypB1c4tc+kQc7DyAaAd1Nc33B4ZKBd9O14CPbZU7JWGH0OjWqmbF9lAR/0g3HUiVrjDAhKcFI4dycJYCGp7HDiZ9MWi1D7pkOPqVvo9YUumej3XMRM15FMiihCCDoaDgWRA9Njk7/iBYhj4bjsyagGubNaYCRX+hWtIR1hfbIIz+6zYUU7M/A6HhgghsUILMWmQZmTdcYeFG5H6c9u58NuXM8igDMW9Wf4sYPES59Lj2IMlFKhIy6+YPHEZkUl8+piyVPGyY8D+ayGV9gOUGEa3SJoY4Xjj+KdaiSPvpcJmZPKofHt4AieE2eZU+M3FXtAmSzs7iu+Hb1/LCi5Rrljt8phevtpltIOgWVL0b8s3r81QkXa0G3TRriN4l/iSNPP0YiCOMxm3pL3vPpTLkXnFw== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(138986009662008); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:HE1PR0701MB3002; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB3002; X-Forefront-PRVS: 01136D2D90 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(24454002)(377454003)(189002)(199003)(5423002)(13464003)(84392002)(230700001)(4720700003)(81166006)(1556002)(9686002)(4326007)(230783001)(68736007)(8676002)(116806002)(19580395003)(19580405001)(81156014)(2906002)(44736004)(93886004)(305945005)(8666005)(6116002)(7736002)(3846002)(7846002)(586003)(50466002)(33646002)(50226002)(1456003)(77096005)(23756003)(15975445007)(86362001)(81816999)(50986999)(110136003)(62236002)(47776003)(101416001)(66066001)(92566002)(44716002)(97736004)(106356001)(105586002)(14496001)(189998001)(6916009)(1941001)(5660300001)(81686999)(61296003)(76176999)(42186005)(74416001)(7059030)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB3002; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; HE1PR0701MB3002; 23:sRczu4cb7jfecF7lQUc7gmvkm5YjuNI9zn7N3?= =?iso-8859-1?Q?CksnTtVAZf0Q/xMJlbykYYjqwkx2Y7yFYAYzcubek9tGR05zLE4DjkQ8L4?= =?iso-8859-1?Q?0cO2O/2NkcPR9zWo9RZmAA4IPxRFjB9dz1SzA+e9ve8IHq/DmP+nNymg0b?= =?iso-8859-1?Q?5TQ1dLtSYQuQduRegnwCgY36N/XaZ3JmgsRryfnml7Xy7oRkTiqglxaDP5?= =?iso-8859-1?Q?gxDbXGnNDQ2LRr6Vp47SAFAiMw6H9MKYjrVpNrVjUa/TATWISUeBvP5JGF?= =?iso-8859-1?Q?DVQDCa8oihlZg0Zq5Rzshz/PMWuu3fklNqcKafC1snyFfLqTXXwMcAMwjQ?= =?iso-8859-1?Q?MXvX93+meKnPHUhnbengPuiZCaPf89lbyS3+LCpX/myiZdwaht3g7xzvMh?= =?iso-8859-1?Q?dac2pzyYBNmMrlaJmPdMWAlgvZyaA1jaqq7+LnIjNJclQTeNWm3MEf0iDC?= =?iso-8859-1?Q?tQ6iy8GC2DV3bzPAycEhVaDZU/Ht8rTrIF+sQbF7qd94FtQU3soY4opWqs?= =?iso-8859-1?Q?So1uKrqH8RO8NlR2NiyUpmkT7F+EN4OVfIKF601RtoJbqoppW6vJ3v8k12?= =?iso-8859-1?Q?0PfyN7x7kRK0zutComqf6iBWQL7jYYMxsoN4ZWshVLLUEjL/Ku/mBagC6v?= =?iso-8859-1?Q?7gO4Twmxc9XvFac8KJ/b1PZ3LUlezBjMWIEJVBz6vX1jkc/cRxpLhSZzlY?= =?iso-8859-1?Q?f6ju5HHz59wtsq8tVXRkghHOJ+xnxd3AlaR0ZQjGUp4noXJ6uiF+UdOyDT?= =?iso-8859-1?Q?3Aoe7qwG+wp3yHZ5pGHNLzigr/PDaspelu09ElxwxLZtIqilCfvR4vnmeu?= =?iso-8859-1?Q?kgAbZxPPVuBqii+PbJuD/F+VYQ5Vf9AMaS+4zZfda4tpxA5NAkVyUxo/gq?= =?iso-8859-1?Q?eC/tfXBe1Vji59fMLcsMaiKf82Px9jaMturNGIcCY/h/eeb9PiqGf4y+bC?= =?iso-8859-1?Q?Bpu3MVEfD248qXbAYNmVAcx1ouesa9ktHUBlXyPuP09uAes2hdyZv7Fg35?= =?iso-8859-1?Q?r4hI2hDB2UlRdMPHub9tbp+bT/ylAqai400zLj1TBQ8VGzGZybXXkyt8E1?= =?iso-8859-1?Q?WG62n3F3Ui5pXOPXMsZNIaXssysUMZmLSuswdHKlMCSdTH1548q4wGpK4n?= =?iso-8859-1?Q?m1o9bl6secS/mjmmVO7lIP6PP2wc57wCRYisT4bKfAZWzBtpBSwdaprj+R?= =?iso-8859-1?Q?fjVqqLi2CBxTSgq1N+6Y7WRCLVV9Q60PdA+L8YshPBwSw+zsgd2+7GSz10?= =?iso-8859-1?Q?QNHwCj9qeYrCQjgknL/JFJ1hQtRtf7WFGyZJzDeJSyxRGi791PgDY2HcF4?= =?iso-8859-1?Q?3ZjIuKgfEoIrPF8Jk1ij1S4/zHoh10yKmDHWfBCB4QrLQ6WHAt6v8SSPvh?= =?iso-8859-1?Q?W0HKIZl32xrqWI31exIvqIo1FosVhOqztpub8JyTH8ZeE8CV0eKZH6zufb?= =?iso-8859-1?Q?g9w8FNIcinAMOMhNU3t0jkulJ3eXH3z4n4Biy8eJ0gBicn5NaFuDWTNrYA?= =?iso-8859-1?Q?xhQIVoVGYIakuSu0PEGpWFdNIHW+ETYC6dd4nJnMnuPgcdx3LlqIwXPWu9?= =?iso-8859-1?Q?nu2AwqHe7MvDkhVrK2WPfXnf0mEfdaMncqwCl5mUr1PidURJOWkAeaBv5i?= =?iso-8859-1?Q?UQ3ZRxICnJdrw=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 6:Vt7u/ULlldfDKrlBEMe3xb47pZc7ePhIYdCaa5NSNib0p2i1AFiL/RA59lCDkFzmZvEPsl+yjVMtsesxPNh/qBYQhRTir8dy+kZhAVdQ2G6OfJKsAMvB1Fi3JleGRsEb//lwWXo1j8dJT5YURK+dFPFGaZlKcLE0IgkPD5CourYBrhdvPIPPs/nnPNOr2udwUnbz0ixlGIQwyP3QPf35yLA/MPl3xikh8cROgmPl18X1dShiM5Qud7yyw64PQYBZpHCq3/sYlf1c1of9VQSQXdEvZ+oiqRVxrnSasQsHp6+C2Uh0fDm/yYSTwtXmZ9PW; 5:81R9z0F/BqPwAAUBxh/2rrF0PultJDQ6v/ixYWNMnycm/ub2Igxg6OgHHxWeYikej/uhDY7yBF1ePt9xMwFxUIst8mYmNq8YOOUKp3Q2KqFpnJgChTY/spmvhmpGkYzXGquKprSQDz7sdW2l1g7QcI6YEQmCHuZlIbZvOAG//LA=; 24:NfZhbgGd3bjPBDkiCjDA3dkxq3GB0DiTrzaklUgI4JHwqtp/IxPyLYip9fNsR2RHRDfrNdEylvOwRT4laFTmFSNu7GBWCpCCV5MWcTjEXYI= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 7:Lm8mOjYYyhPQl5h3lr/bWfChevyNFEghZiVfVzyPd9P9uU7d4LFBCTdA7he0Ao0Y46yuQTGQWMwaFjnrqPa3O7tUxkhjwTBfkDXSgtNtj1kU9D08ek0esIkMxI2MDHW39t76B1P/B1tTa8ORlW4tVcca82HRlNKlmHgWbUdz8Q8Ybpovbn8w3Ox4MNdm07H+cnWM0+eHbn1BNackyuu4bPXnEDzXBujwxIwYxzlGrQgVdKy/oG+S3kJPhzlstOm15xkB6ccvDyKdgVGgRSx/U/eucrzIJENKNJjRQeMHcnafw8kqb42pYibUX3UZ9BydGRG2BVEDyBGtOx3+UbLfwolfhtM83+OsxkNczScGD8w= X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Nov 2016 17:47:21.0715 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB3002 Archived-At: Cc: IETF IDR Working Group Subject: Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129 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, 01 Nov 2016 17:47:27 -0000 Oppose We all know what deprecate means which, based on recent discussions of other topics on this list, means we are using many divergent ones in our assessment of this I-D. 'deprecate' is a technical term in the processes of the IETF. You need to define it, or better, use the existing definition. That definition is in draft-leiba-cotton-iana-5226bis-18 which therefore MUST/SHALL be/is REQUIRED to be a Normative Reference, and yes, that means waiting for that to become an RFC before this can advance; which interaction I see as a necessity. Otherwise, we haven't a clue what we are adopting. Well we have, but it is about a dozen different clues. Likewise, but not so critical at this stage, having an RFC that starts ' This document requests IANA ..' will look, well, not very sensible. If you believe in what you are doing, then I would like you to state it as a fact. 'This memo changes the status of ... in the IANA Registry to 'deprecated' And what you have at present sits oddly with the IANA Considerations. Usually, the latter says 'IANA is asked to ...' which is edited by the RFC Editor 'IANA has ...' Yet you have an IANA Considerations of 'IANA has ... Back to front, IMHO. Tom Petch ----- Original Message ----- From: "John G. Scudder" To: "Jeffrey Haas" Cc: "IETF IDR Working Group" Sent: Tuesday, November 01, 2016 4:20 PM > On Nov 1, 2016, at 10:53 AM, John G. Scudder wrote: > > On Nov 1, 2016, at 10:40 AM, Jeffrey Haas wrote: > >> 1. Do we actually need a draft published to request IANA to block out > >> allocation of these code points? If so, we're going to end up with a number > >> of trivial drafts for these corrective actions. I'm interested in hearing > >> the IESG's opinion on this point. > > > > IANA did specifically request an RFC to reference although they stopped short of explicitly saying "if you don't promise to give us a document, we won't do this action". I have asked them to clarify and will report back, but I suggest that for now the WG should assume that we do actually need to publish draft and progress it to RFC. > > Update: Michelle @ IANA confirms that they do require RFC for deprecation from a Standards Action registry but agrees there is no documentation of this requirement specific to deprecation, they've just inferred it from the requirement to assign one. She says she'll bring it up on the Thursday IESG telechat. > > Again, for now the WG should assume we do need an RFC. > > --John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Tue Nov 1 11:00:58 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1F521294DA for ; Tue, 1 Nov 2016 11:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.432 X-Spam-Level: X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_SOFTFAIL=0.665] 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 TGCiIsysFVRp for ; Tue, 1 Nov 2016 11:00:55 -0700 (PDT) Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (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 4B831129413 for ; Tue, 1 Nov 2016 11:00:55 -0700 (PDT) Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1c1dMh-0007n5-8W (job@us.ntt.net); Tue, 01 Nov 2016 18:00:52 +0000 Date: Tue, 1 Nov 2016 19:00:47 +0100 From: Job Snijders To: "t.petch" Message-ID: <20161101180047.GN966@Vurt.local> References: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> <20161101144036.GB10519@pfrc.org> <25D24BDC-5322-4B19-A971-9FDD65C07BF1@juniper.net> <01c101d23467$9c8b0cc0$4001a8c0@gateway.2wire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01c101d23467$9c8b0cc0$4001a8c0@gateway.2wire.net> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.0 (2016-08-17) Archived-At: Cc: IETF IDR Working Group Subject: Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129 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, 01 Nov 2016 18:00:57 -0000 On Tue, Nov 01, 2016 at 05:44:27PM +0000, t.petch wrote: > We all know what deprecate means which, based on recent discussions of > other topics on this list, means we are using many divergent ones in > our assessment of this I-D. > > 'deprecate' is a technical term in the processes of the IETF. You > need to define it, or better, use the existing definition. Why does it need to be defined? Are you saying that it is unclear what the existing "deprecated" entries in http://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#bgp-parameters-2 mean? > That definition is in draft-leiba-cotton-iana-5226bis-18 which > therefore MUST/SHALL be/is REQUIRED to be a Normative Reference, and > yes, that means waiting for that to become an RFC before this can > advance; which interaction I see as a necessity. I am confused, it appears you assign normative value to something that as of yet is a draft? Why is there a dependency? Can you also point out which specific section of draft-leiba-cotton-iana-5226bis-18 you are referring to? For the working group's overview: I've taken as example: https://tools.ietf.org/html/rfc6938 . This document does not contain RFC2119 language. > Otherwise, we haven't a clue what we are adopting. Well we have, but it > is about a dozen different clues. > > Likewise, but not so critical at this stage, having an RFC that starts > ' This document requests IANA ..' will look, well, not very > sensible. If you believe in what you are doing, then I would like you > to state it as a fact. 'This memo changes the status of ... in the > IANA Registry to 'deprecated' A stylistic comment wrapped around "if you believe in what you are doing", .. really? > And what you have at present sits oddly with the IANA Considerations. > Usually, the latter says > 'IANA is asked to ...' > which is edited by the RFC Editor > 'IANA has ...' > > Yet you have an IANA Considerations of > 'IANA has ... > Back to front, IMHO. I can update the grammatical tense. No big deal. Kind regards, Job From nobody Tue Nov 1 11:20:37 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B343D129766 for ; Tue, 1 Nov 2016 11:20:35 -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, 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] 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 ErZX_x3g-7s4 for ; Tue, 1 Nov 2016 11:20:33 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0095.outbound.protection.outlook.com [104.47.34.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7386F1297AA for ; Tue, 1 Nov 2016 11:20:33 -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=4e3rGg9fLUA9W9kY70nlIy/8htNw52U+6uCboGmHLZ4=; b=DjzUC061TzXK9Z3f41CNIiHCElr3Gd6HIwRzR6+16OWJ/IYJpCpedEDDFGQ8lisRxIA1FffLtLeAmiJtbJc8zrp/M6fsUKEOUIDrSmy3xeEQ5DxeWjRc3qW829WHnz+jP731Vd2Xt9GzK39FBDVVDgY3fIsyx2oYdBq9pPZSNOw= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; Received: from [172.29.37.68] (66.129.241.11) by CY1PR05MB2508.namprd05.prod.outlook.com (10.167.10.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.679.5; Tue, 1 Nov 2016 18:20:18 +0000 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "John G. Scudder" In-Reply-To: <01c101d23467$9c8b0cc0$4001a8c0@gateway.2wire.net> Date: Tue, 1 Nov 2016 14:20:11 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <4070F36C-3D40-4EE8-B6F0-D077DB18875A@juniper.net> References: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> <20161101144036.GB10519@pfrc.org> <25D24BDC-5322-4B19-A971-9FDD65C07BF1@juniper.net> <01c101d23467$9c8b0cc0$4001a8c0@gateway.2wire.net> To: t.petch X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.11] X-ClientProxiedBy: BN3PR10CA0042.namprd10.prod.outlook.com (10.161.211.52) To CY1PR05MB2508.namprd05.prod.outlook.com (10.167.10.135) X-MS-Office365-Filtering-Correlation-Id: eeb8e627-5622-46fd-f060-08d40283bc4e X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2508; 2:rliW/wwO3vBbOstYB3v+ctXy4mjgjFrgnXHwYk/SM7Nj8eZMmSzD9ihFBgGDRvZm6HMEjMtUr1jwMSI5pAf2KeWOE/6r7neuLzN98dLATLkP/hPZGcMfzkoKcgFbTdw+gttq/wSU4Hu/BKrZphbylM7VflGzCVWf7P0TLVYjnWyEmz+wxkuWa3qMC7j6lr4VREg5w0tF2zbMe0wDhn6LOw==; 3:x1FasN4FT4690SYEMyIAnhe3WTLf1yZy9ZI+cedxKP6bVSIzpvot43G383+KgBP7MF3xoxyVC0l4Osjrp65r1um2595+7OPMMcg1YmKGwRT5FG91SI4lqLc7hXP+yPG+j4zSvErSRjV7id88XjvTrQ==; 25:+Keba2jAZ0sfmFMEUrmaU9rgcstlGY02jIfH1Gi2ORMJA3/fBC2K3R6mfhOr6yDLaG1xtwFEFGuxQlsO9XrC5I4NqX106JB65/7LWhNYtPRm+wxRdoqvo/35IULNq4Wf98c4u+cLijWX9srt1yeN0WFC7XoyVibWJZShbro/5vxnIB6r/IN5F3asLdGe4nl0L34BCLBdVGZgXqvFmSpFeWXeLPSEpU+3+XnAlHD95+XlB2KKUXRNOBoY8LXZaaOYAkeyb/prajXeRLfSMDIJQAe58zSLd9/9+3ASEEkpfPKNurvvpTjrKBxEfYHdh6sKOyBxeNGlen1mO0zg5BgwB7ehrVXud0bwlnmAUmXv6eEzb+hpCX0gilmy1Gql0OB1RxdpAu+f0SkwV2hvrK/VjBIOlhMcxq1V0+ZTZ94SzvMICp43N3+HTVvEQoq6fHuK X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR05MB2508; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2508; 31:2kUTvuVGyPB+TVDifJmnq0p6+XCJCAMF6f0gyZdIY36knfoi9lwpu/pdHAShn6Lelakfkaoycgc+lgoj3D26xCgjzI5Jh0dXhB/WAwuXChwmM0yRkllazPMQqGqMfaVb++toq4zPEMWmSGNB0PxymzP/ozIH8FHKWp5NsoXLcPQEdkMXSI0iaWn6T3sqpV9ajCDP+GBCXiGOFeZNF+B47Gr6jBkZnpzZSm2a2gJK482yc1rsVML5PbYvZhVRgR9Y; 20:JZ56+h0TCONz3E1ZJtbonmCcDAXAN2eoA+h7dM/LEMMd5WWElQ2urAhEEt8la/s+H6tUUnr4Tt3iHYUY3ncglc/2pC4cF2booVZ2CB0NxJDgxDjByvsHU1u88r072NXaQSYdygDThsM6HeJVckxvLbAauk56NsBzBOlsK58cnXZpJfjh7cfRDU9b0pngqvN0hBs2J8ubzY7EhT5xr9GclDiO6T0Yci/a9iPjfJ2811We0RyQZV7q7fQZdv+v//aIYEvW3arsDBAICtxNwTwcd+z9oUfXjZbnZWT/jv3ojpe7KNs0vkSxtyyzpM+vCZXNnD1mLOI3Lrol+H3diaZNJm0IpGNVjZo8CIPDgXvOHoZbe6sjZcj5tgOkw6+aWOGVUXLqfqrtqzbaPDOOU+5Owg7EG4kBlWIwQ+4Dq1g4c3ao2/7ognnHaRur3t8LZ/mZc+KKC2a37m8IxxS9uzPKTrDqnap4ftt24Gv7Zi2VG6RGGjO3obGRM5XWjky4qPv9l4CbkuGGwFmw0PJEsEbSsnrVY/g/TqyXmyAGJh94raJZzHng2Ij4doPE4mmkRjLCCU2KIFnMUJ65Njkn0HbU7taR8HGy0kZSR6tpuXY4/J4= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(178726229863574)(138986009662008); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:CY1PR05MB2508; BCL:0; PCL:0; RULEID:; SRVR:CY1PR05MB2508; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2508; 4:hAIDGQUNdbIlThPXJZ6TbD+m6OwiSK9txjVRiQJViWEXq61isViwVuDW8WrB9AzP38X6qIQ24itD5YHvFWqA1Sn5GUFqJAYXU+wJ1gzSMpwChGwjeUch0lkD/5rlVGYxS9l8RHJFQiglULkqTSzICcqrNeSGPURgBP0KJy7+QR4cjpNpAZyB7NPi6H2y6uxog9ATCE+KuBI4/2mzhvPLCGLFksUImHbmOZy66Q+MRdeatULozzqPFXPvonp9t7kasNH6O6F8DHUtTX3q7zasMwU9vnwrdkwfWT00CKZsxLD7C9pC2X6xaFKN9SQpUTHqv3+Zf7Lq3UPuOi0PjvWmdS7j0fGfppw2ieP/Jmrp0VSjKBoxjNalnLLNBiWD9WMCpyV4Lx4wutbsaeSx+uOMQa21uxkfuSdHaG5h4LD4Bn6qJ8uvxNNLqGEkQBe6fA3DRAqKE4+3/iK0ognI+hT+dVs+vPeyJLf+MQmfpVtSuSrRMOr5l++dWM3saW+jbv3q X-Forefront-PRVS: 01136D2D90 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(7916002)(377454003)(199003)(5423002)(189002)(24454002)(13464003)(6666003)(19580405001)(36756003)(5660300001)(8666005)(105586002)(110136003)(76176999)(93886004)(50986999)(15975445007)(77096005)(101416001)(106356001)(86362001)(92566002)(230783001)(7736002)(7846002)(4326007)(97736004)(42186005)(47776003)(50226002)(81166006)(2950100002)(189998001)(3846002)(82746002)(586003)(8746002)(2906002)(66066001)(6116002)(8676002)(83716003)(81156014)(33656002)(19580395003)(6916009)(50466002)(305945005)(68736007)(57306001)(23756003)(7059030)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2508; H:[172.29.37.68]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; CY1PR05MB2508; 23:XaVifx12nU2aYTHZ3EtETPo2mqFKSSpF89AIH0T?= =?iso-8859-1?Q?vLRfG+N8mj28niLhLilTHI6HtAERIzk5rKkOj6YchDrAuXcURdVhgtJUhp?= =?iso-8859-1?Q?/VpPu54rUpdunpEePLPXHyiexywXpADByNkwSpKsuOAQkz/2koBAkoJBEb?= =?iso-8859-1?Q?k6E8JsbdwVkMc1PdqjrjI6ulQjXlfMjKQNbRmWyxDOv+5uJT3oRQplfQMY?= =?iso-8859-1?Q?3aZDjkGrshIVath35GE4AGNzjtkDkjKisPuBQMses3keX68mSm8dHWJXfK?= =?iso-8859-1?Q?nv8VZpVB69/P2BSx881Lfvx7/bI7vp1TF9LbrezQaetRZSWa5uHsmFN7Ds?= =?iso-8859-1?Q?NQZBuxy9t6smWHMX04rIwJ9DlT8D/rj4vxBGnVxwUKvtWF1ShHvSI+3PuT?= =?iso-8859-1?Q?o9y3AOJ9uQZx2Sa5MNmFFICq6u8h24gn5DvnpoVKlj/WDYutkDFn8BTiAr?= =?iso-8859-1?Q?w73FHX3Lud2A2qVxze1UNmxT4BIte1fSZsu0bWx2DcVyv9acZOXIoPBd8B?= =?iso-8859-1?Q?tnGueVYnDdgbknG9lc7ZeystoK0zAutXar/nEn+gV6yR6if5nM55ML7rhJ?= =?iso-8859-1?Q?nkpHQw/YfNJQFkjt6jFUbyBfnebmWN5EX6xDL8MVmWBgQ5z3Lo9Dlwzs/y?= =?iso-8859-1?Q?WFogQabMgfi3Fq/e+QdK7YZjqZlVlrimz1sA0z+gSp4FmOmrZTkOHzHI72?= =?iso-8859-1?Q?fVmSzSE5E4nWksvKIf63ieOGzG2DtexNiyxv0m7eoNGTEmNAYfOZSRnm8g?= =?iso-8859-1?Q?upKLeg9csyaV2fJ1kAvzKTZpqMXY6Z113PKweZxVzTnXE5oL7tkY42/H5S?= =?iso-8859-1?Q?wL2KxaCqRyTvF0x+xP18OrbI5EbH1UvECQFVAoJdX4xFSPrnAwuc6qPBtg?= =?iso-8859-1?Q?RqVwTUNWVOMwY8v+LOBDv0tRZYsr0ZntA2sThWPSPGTnzX1KcRuI5DTJe9?= =?iso-8859-1?Q?fb1Auha+qHUQSy0GsGTfz0vgP1mc8rLI7s1056nd1RtVCoc0fXMe50Yw4J?= =?iso-8859-1?Q?IzYfJBghFXKLp06oq3LZShbI3diCKxSwTxo4ZSMnSaGXPM7htMdbN3P0HU?= =?iso-8859-1?Q?05to3vPjBhjLi8Y2aJbTxSifodIkknaEH5XEhHJYlTItBRHxdlNBGkLi1U?= =?iso-8859-1?Q?w3MrlA/Eb+RjNx5u88H0vE7yRNV/OzkkuVH5jNflqzoQiSzRI5Ejz14CiN?= =?iso-8859-1?Q?YHS5G8GKEiybIrM8fbv1p8CmJul5UtUvYAKoxeOZiYzBZx/1aQ6W1zYxZG?= =?iso-8859-1?Q?PkW2iCbTYhYrexyALeRf2XH3jS/8PxGNvKrHg2ElKpAYzOTFloyuPCprft?= =?iso-8859-1?Q?cmSr6892e08MTfWFdlvOfuf+frnAz0nF8EApab2s4AuuYvtbyKvxmm84j9?= =?iso-8859-1?Q?2Y3cVrfINsxajxnd8vopvQA+9FkEu5zL5x/ssWBrKBMKBqnTogg=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2508; 6:b7FPdj1rhLIEQ3SnyatL6F+rIwg3t7CTpsTGNy85pOMpf1obexA6P+z1//FBeGONjvIQAaf76nfSgnAZORTxfeU6i9Cfu8Di238azKFYElzSo6YGBegb50WzOG0NBJ5tgqXyGc101mkYAbmRNuUrlkon4Kc35zp2P8q5qSl/k1CYBH+C1/o0RHkJWLWY2SD49MfBHdiLjYg8l7CEHoGijZUQWsILadWvMAn8iKHPLBx37rVXLIIjjvYY8F8W3dTsVJNgzc3AKQqVs8700xtr5aP5YDHwF7pycYUCApiIInnpdvgnJ5SO0lT8RxrcAx2MbX33CIOJASlzZP4dUq/IHPqOo1Xo+sv4ZFmOuMDrxeA=; 5:UsOpLs1hPvJe7ZlQFVjzSNfbhR/5nsVMQWNfR5UnwYFLS0aT9Ux+ejEMvffYDKX6yWgV1q+NHtnYSu639HailCep5MvlZKDAm16fk8a3nl+MIN0UTlj1aMUC2tmA5/DQIfgniKDRg1Ib4WkRIcuIBV9FZm6BdLJN338rBYEWHfQ=; 24:5MqDvaHZCmgF8I/OgDeGTYYAeJWvSlog5CgE7TusrC0SpeJQjbqwO8i72lgRWnvFz89fCWWfxezH67yriAMd2QNOR+79DMH2fc6Wt24Cg1A= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2508; 7:58PePzc5VbLE06c6R2rfrN6hAw4VJ5uJRnW6eIqrW8CnQPSOOY4TJnc0UqYulyr+B+eTW6a38zJH3UqWn6jlAst8w2aDbsK/Dk3qi4xDPGO1f+i+mK21VgNZ2lmZkVf/+OzcN2k0UQHIcCztnBtfJ3tEX+eIsletebIwKo67QrFyO7QUGVUSlR5cXVLEGGqO/uza4H04iTBExhjJcEfS88qU589RjLQUIB0o8BLKsb6YVOHz06TUeT2L6Q7GU14ZOp3vr1ym50Hv1uDMfK9dZ12qUnlToI7eAcNdrer7fv2WR4o5TUBO9E1UWBnAUvOr2fVgOqH79nX+JsCqsx2Qw823NGw25KciGPB46IO9RC4= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Nov 2016 18:20:18.3508 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2508 Archived-At: Cc: IETF IDR Working Group Subject: Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129 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, 01 Nov 2016 18:20:36 -0000 Tom, I'm confused by your message.=20 It appears to relate to the proposed adoption of = draft-snijders-idr-deprecate-30-31-129 and not to my most recent message = regarding IANA process at all, even though you followed up to, and = quoted, mine. I'll proceed on that assumption. I agree that it's unfortunate there is apparently no referenceable = definition of "deprecate" but on the other hand, this has not impeded = many code points from being deprecated in the past. Somehow we have = muddled through. I suppose it wouldn't be the end of the world to do as = you suggest and normatively reference 5226bis even if it means sitting = in downref indefinitely, because I think IANA will be willing to mark = the code points deprecated on the strength of the internet draft, = following the early (de!) allocation process. But also think it would be = fine to follow the other branch of your suggestion and quote their = definition, removing the downref. Apart from the question of providing a reference/definition for what = "deprecate" means (which I thought we'd already settled), the rest seems = to be editorial minutiae.=20 None of these things (request for a definition, other editorial issues) = seems to me to be a basis for "Oppose". The question before the WG is = really "do we want to deprecate these code points", and that's what I'd = most like to see people engage with in deciding to adopt (or not) the = document.=20 To be clear, for purposes of this adoption call, I'm assuming we are = using the 5226bis Section 9.6 definition (or "definition") you refer to, = viz.: Specific entries in a registry can be marked as "obsolete" (no longer in use) or "deprecated" (use is not recommended). If someone who has already responded did so on the basis of thinking = that "deprecated" means something other than "use is not recommended" = they may of course revise their position. Regards, --John =20 > On Nov 1, 2016, at 1:44 PM, t.petch wrote: >=20 > Oppose >=20 > We all know what deprecate means which, based on recent discussions of > other topics on this list, means we are using many divergent > ones in our assessment of this I-D. >=20 > 'deprecate' is a technical term in the processes of the IETF. You = need > to define it, or better, use the existing definition. >=20 > That definition is in > draft-leiba-cotton-iana-5226bis-18 > which therefore MUST/SHALL be/is REQUIRED to be a Normative Reference, > and yes, that means waiting for that to become an RFC before this can > advance; which interaction I see as a necessity. >=20 > Otherwise, we haven't a clue what we are adopting. Well we have, but = it > is about a dozen different clues. >=20 > Likewise, but not so critical at this stage, having an RFC that starts > ' This document requests IANA ..' > will look, well, not very sensible. If you believe in what you are > doing, then I would like you to state it as a fact. > 'This memo changes the status of ... in the IANA Registry to > 'deprecated' >=20 > And what you have at present sits oddly with the IANA Considerations. > Usually, the latter says > 'IANA is asked to ...' > which is edited by the RFC Editor > 'IANA has ...' >=20 > Yet you have an IANA Considerations of > 'IANA has ... > Back to front, IMHO. >=20 > Tom Petch >=20 > ----- Original Message ----- > From: "John G. Scudder" > To: "Jeffrey Haas" > Cc: "IETF IDR Working Group" > Sent: Tuesday, November 01, 2016 4:20 PM >=20 >=20 >> On Nov 1, 2016, at 10:53 AM, John G. Scudder wrote: >>> On Nov 1, 2016, at 10:40 AM, Jeffrey Haas wrote: >>>> 1. Do we actually need a draft published to request IANA to block > out >>>> allocation of these code points? If so, we're going to end up with > a number >>>> of trivial drafts for these corrective actions. I'm interested in > hearing >>>> the IESG's opinion on this point. >>>=20 >>> IANA did specifically request an RFC to reference although they > stopped short of explicitly saying "if you don't promise to give us a > document, we won't do this action". I have asked them to clarify and > will report back, but I suggest that for now the WG should assume that > we do actually need to publish draft and progress it to RFC. >>=20 >> Update: Michelle @ IANA confirms that they do require RFC for > deprecation from a Standards Action registry but agrees there is no > documentation of this requirement specific to deprecation, they've = just > inferred it from the requirement to assign one. She says she'll bring = it > up on the Thursday IESG telechat. >>=20 >> Again, for now the WG should assume we do need an RFC. >>=20 >> --John >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >=20 From nobody Tue Nov 1 11:38:45 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F9DC129801 for ; Tue, 1 Nov 2016 11:38:43 -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 ef5Na-tTbTkK for ; Tue, 1 Nov 2016 11:38:39 -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 D1B3A129856 for ; Tue, 1 Nov 2016 11:38:35 -0700 (PDT) X-Envelope-To: idr@ietf.org Received: from cupcake.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 uA1IcVWO029657 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Nov 2016 18:38:32 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 cupcake.local Message-ID: <5818E126.2090202@foobar.org> Date: Tue, 01 Nov 2016 18:38:30 +0000 From: Nick Hilliard User-Agent: Postbox 5.0.5 (Macintosh/20161020) MIME-Version: 1.0 To: Jeffrey Haas References: <20161031205515.GA25507@pfrc.org> In-Reply-To: <20161031205515.GA25507@pfrc.org> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: Cc: idr@ietf.org Subject: Re: [Idr] [internet-drafts@ietf.org: I-D Action: draft-haas-idr-extended-experimental-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: Tue, 01 Nov 2016 18:38:43 -0000 Jeffrey Haas wrote: > There's a larger conversation to be had about proper stewardship and use of > code points of all sorts, but path attributes have our attention for the > moment. > > A quick draft for consideration and to motivate discussion. this is an interesting approach and I like it. Despite the warnings in the document, vendors are likely to want to do vendor-specific things on a permanent basis, but this is probably unavoidable and not necessarily a bad thing either - there are plenty of other situations where vendor-specific attributes are used to good effect. I'd like to see this idea progress. Nick From nobody Tue Nov 1 11:45:28 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B09C612986E for ; Tue, 1 Nov 2016 11:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, 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 txNsPgH4wO3I for ; Tue, 1 Nov 2016 11:45:23 -0700 (PDT) Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id D34DD12986A for ; Tue, 1 Nov 2016 11:45:22 -0700 (PDT) Received: by guelah.shrubbery.net (Postfix, from userid 7053) id A966774ABD; Tue, 1 Nov 2016 18:45:22 +0000 (UTC) Date: Tue, 1 Nov 2016 18:45:22 +0000 From: heasley To: Nick Hilliard Message-ID: <20161101184522.GC75985@shrubbery.net> References: <20161031205515.GA25507@pfrc.org> <5818E126.2090202@foobar.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5818E126.2090202@foobar.org> X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc X-note: live free, or die! X-homer: i just want to have a beer while i am caring. X-Claimation: an engineer needs a manager like a fish needs a bicycle X-reality: only YOU can put an end to the embarrassment that is Tom Cruise User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Cc: idr@ietf.org Subject: Re: [Idr] [internet-drafts@ietf.org: I-D Action: draft-haas-idr-extended-experimental-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: Tue, 01 Nov 2016 18:45:27 -0000 Tue, Nov 01, 2016 at 06:38:30PM +0000, Nick Hilliard: > Jeffrey Haas wrote: > > There's a larger conversation to be had about proper stewardship and use of > > code points of all sorts, but path attributes have our attention for the > > moment. > > > > A quick draft for consideration and to motivate discussion. > > this is an interesting approach and I like it. Despite the warnings in > the document, vendors are likely to want to do vendor-specific things on > a permanent basis, but this is probably unavoidable and not necessarily > a bad thing either - there are plenty of other situations where > vendor-specific attributes are used to good effect. > > I'd like to see this idea progress. perhaps encouraging its use for vendor-specific stuff isnt a bad idea. Support adoption. From nobody Tue Nov 1 11:55:33 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7210E1293F5 for ; Tue, 1 Nov 2016 11:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, 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 vrkOhmY7xt9p for ; Tue, 1 Nov 2016 11:55:29 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD9812989F for ; Tue, 1 Nov 2016 11:55:29 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 432711E337; Tue, 1 Nov 2016 14:58:00 -0400 (EDT) Date: Tue, 1 Nov 2016 14:58:00 -0400 From: Jeffrey Haas To: Nick Hilliard Message-ID: <20161101185759.GA23458@pfrc.org> References: <20161031205515.GA25507@pfrc.org> <5818E126.2090202@foobar.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5818E126.2090202@foobar.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: idr@ietf.org Subject: Re: [Idr] [internet-drafts@ietf.org: I-D Action: draft-haas-idr-extended-experimental-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: Tue, 01 Nov 2016 18:55:31 -0000 On Tue, Nov 01, 2016 at 06:38:30PM +0000, Nick Hilliard wrote: > Jeffrey Haas wrote: > > There's a larger conversation to be had about proper stewardship and use of > > code points of all sorts, but path attributes have our attention for the > > moment. > > > > A quick draft for consideration and to motivate discussion. > > this is an interesting approach and I like it. Despite the warnings in > the document, vendors are likely to want to do vendor-specific things on > a permanent basis, but this is probably unavoidable and not necessarily > a bad thing either - there are plenty of other situations where > vendor-specific attributes are used to good effect. As I mentioned, discussion. :-) One of the general issues with vendor code spaces is that it *does* motivate vendor-specific work. That's not necessarily a bad thing in the general case, but when we talk BGP we have to have a firm focus toward what the global implications of such a thing means. The document attempts to setup the expectation of filterability. Right now, path attribute filtering as a general practice is hazardous to the incremental deployment of features on expects to work across the global Internet. A feature such as this one, perhaps extended with a per-attribute form of draft-ietf-idr-bgp-attribute-announcement along with enough information to figure out when filtering wasn't done could provide some safety. The related changes to this proposal would be to simply add the 4-octets of the attribute announcement scoping and potentially the attaching AS. However, given even such vendor features are likely to need to work in an inter-as fashion, generating scopes of containment become tricky. > > I'd like to see this idea progress. > > Nick From nobody Tue Nov 1 11:58:04 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E82C1298C2 for ; Tue, 1 Nov 2016 11:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, 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 Qom4wdMXc0xe for ; Tue, 1 Nov 2016 11:58:01 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id AC76812988D for ; Tue, 1 Nov 2016 11:57:58 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 1BE3D1E369; Tue, 1 Nov 2016 15:00:30 -0400 (EDT) Date: Tue, 1 Nov 2016 15:00:30 -0400 From: Jeffrey Haas To: heasley Message-ID: <20161101190029.GB23458@pfrc.org> References: <20161031205515.GA25507@pfrc.org> <5818E126.2090202@foobar.org> <20161101184522.GC75985@shrubbery.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161101184522.GC75985@shrubbery.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: idr@ietf.org Subject: Re: [Idr] [internet-drafts@ietf.org: I-D Action: draft-haas-idr-extended-experimental-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: Tue, 01 Nov 2016 18:58:02 -0000 On Tue, Nov 01, 2016 at 06:45:22PM +0000, heasley wrote: > Tue, Nov 01, 2016 at 06:38:30PM +0000, Nick Hilliard: > > I'd like to see this idea progress. > > perhaps encouraging its use for vendor-specific stuff isnt a bad idea. > > Support adoption. FWIW, I'm not currently asking for adoption. But I'm happy to take this proposal forward after WG discussion. -- Jeff (just to suppress the +1 / -1 storm for now) From nobody Tue Nov 1 12:32:14 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4014712998E for ; Tue, 1 Nov 2016 12:32:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 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=-1.497, 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 MCu_mGQ5EF0b for ; Tue, 1 Nov 2016 12:32:11 -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 99B6D12997C for ; Tue, 1 Nov 2016 12:32:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2929; q=dns/txt; s=iport; t=1478028730; x=1479238330; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=f8KMsOSl4RrTXtlkEJ4UT3hisRbsfC5jcPEEhRm4nHE=; b=J7B7jgHQKl31TQxbW9D3On7G65jPD8dtM1IWCHRVcABCVb5wM7zNRqXU rWmJP4daJq0CcQRejIPfsr6OKvgmM+upMfpIPyfsWUUT5VLquWzm5cMrg klR3bjJLkm32Ft29hBUEjmZd3aEml76gynSFd4wOcCkhF1yLBj8vYNeNy k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AbAQBl7RhY/5xdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgyoBAQEBAR9YfAeNL5cBlEWCBx0LhXoCghM/FAECAQEBAQEBAWI?= =?us-ascii?q?ohGEBAQEEAQEBGh00CwwEAgEIEQQBAQEeCQcnCxQJCAIEAQ0FCIhMDrgtAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBFwWGPYRVhC2FegWaGgGGMIl9gXWEbokqjROEAwE?= =?us-ascii?q?eNmCDJBwYgTtyhlCBDAEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,433,1473120000"; d="scan'208";a="164447487" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Nov 2016 19:32:09 +0000 Received: from xch-rcd-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id uA1JW9Cp017771 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 1 Nov 2016 19:32:09 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 1 Nov 2016 14:32:03 -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; Tue, 1 Nov 2016 14:32:02 -0500 From: "Jakob Heitz (jheitz)" To: Job Snijders , "John G.Scudder" Thread-Topic: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129 Thread-Index: AQHSNER1PaigKM8RbUm+nYoUrzJrlaDEg+KA Date: Tue, 1 Nov 2016 19:32:02 +0000 Message-ID: <9b5c0c39c07c46c28a2aba52ea4b082d@XCH-ALN-014.cisco.com> References: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> <20161101133240.GK1581@hanna.meerval.net> In-Reply-To: <20161101133240.GK1581@hanna.meerval.net> 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.154.161.163] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: IETF IDR Working Group Subject: Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129 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, 01 Nov 2016 19:32:13 -0000 I support it for all these attribute codes. However, we should give the users of 129, 241, 242 and 243 a chance to ask = for a reservation of the codes they are using. At least give them the option to reserve them once they are deprecated by t= his document. Thanks, Jakob. > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Job Snijders > Sent: Tuesday, November 01, 2016 6:33 AM > To: John G.Scudder > Cc: IETF IDR Working Group > Subject: Re: [Idr] Working group adoption call for draft-snijders-idr-dep= recate-30-31-129 >=20 > Dear working group, >=20 > To prevent having multiple drafts in quick succession covering the same > style of issue - I'd like your feedback on the following: >=20 > I believe that bgp path attribute 241, 242, 243 should also be added to > this draft for the same reasons as 30, 31 and 129 are listed. >=20 > OLD: > This document requests IANA to deprecate the following BGP Path > attributes: 30, 31, and 129. >=20 > NEW: > This document requests IANA to deprecate the following BGP Path > attributes: 30, 31, 129, 241, 242, and 243. >=20 > Does anyone object? If so, why? >=20 > Unilaterally changing the document while in its mid-flight through the > working group adoption process might be considered bad form, hence my > request for feedback on the 241,242,243 topic. >=20 > Please note - the deprecation of an attribute can be undone if proper > process is followed. The priority here is to prevent IANA from assigning > tainted codepoints to innocent bystanders, thus a deprecation document > needs to exist. In time the working group has the power to undeprecate > them for specific purposes. >=20 > Kind regards, >=20 > Job >=20 > On Mon, Oct 31, 2016 at 05:18:57PM -0400, John G.Scudder wrote: > > Hi Everyone, > > > > The author has asked for the WG to adopt draft-snijders-idr-deprecate-= 30-31-129. > > > > If you support or oppose adoption please reply indicating so. Reasons f= or your position are helpful, as > volunteering to review, comment, and/or shepherd. As an aside, I will not= e that I don't think the WG has the option > of doing nothing, so if you oppose adoption please address what you think= should be done instead. > > > > The adoption call will end November 13. > > > > Thanks, > > > > --John > > > > P.S.: https://tools.ietf.org/html/draft-snijders-idr-deprecate-30-31-12= 9-01 > > > > Abstract > > > > This document requests IANA to deprecate the following BGP path > > attributes values: 30, 31 and 129. > > > > > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Tue Nov 1 13:40:11 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B0461294DD for ; Tue, 1 Nov 2016 13:40:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, 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 2GpzgbVp7yGK for ; Tue, 1 Nov 2016 13:40:09 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 169531294D8 for ; Tue, 1 Nov 2016 13:40:09 -0700 (PDT) Received: from [IPv6:2603:3015:3603:8e00:51e0:59a6:676c:7860] (unknown [IPv6:2603:3015:3603:8e00:51e0:59a6:676c:7860]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id 708A554075A; Tue, 1 Nov 2016 16:40:07 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Jared Mauch In-Reply-To: <9b5c0c39c07c46c28a2aba52ea4b082d@XCH-ALN-014.cisco.com> Date: Tue, 1 Nov 2016 16:40:06 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2D473D49-E8B2-4CD5-9A0B-EE9B1005B318@puck.nether.net> References: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> <20161101133240.GK1581@hanna.meerval.net> <9b5c0c39c07c46c28a2aba52ea4b082d@XCH-ALN-014.cisco.com> To: "Jakob Heitz (jheitz)" X-Mailer: Apple Mail (2.3251) Archived-At: Cc: IETF IDR Working Group Subject: Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129 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, 01 Nov 2016 20:40:10 -0000 > On Nov 1, 2016, at 3:32 PM, Jakob Heitz (jheitz) = wrote: >=20 > I support it for all these attribute codes. > However, we should give the users of 129, 241, 242 and 243 a chance to = ask for a reservation of the codes they are using. > At least give them the option to reserve them once they are deprecated = by this document. There seems to be carrot here, which I=E2=80=99m in favor of. We can = always remove items during WG LC if they attain their allocation through = implementations. - Jared From nobody Tue Nov 1 20:20:53 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4102129851 for ; Tue, 1 Nov 2016 20:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.718 X-Spam-Level: X-Spam-Status: No, score=-5.718 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, RP_MATCHES_RCVD=-1.497, 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 AFXusjmJEooR for ; Tue, 1 Nov 2016 20:20:49 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B89201294F9 for ; Tue, 1 Nov 2016 20:20:48 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CZN03439; Wed, 02 Nov 2016 03:20:46 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 2 Nov 2016 03:20:45 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Wed, 2 Nov 2016 11:20:37 +0800 From: "Dongjie (Jimmy)" To: Jeffrey Haas , "idr@ietf.org" Thread-Topic: [Idr] [internet-drafts@ietf.org: I-D Action: draft-haas-idr-extended-experimental-00.txt] Thread-Index: AQHSM7jIewH/rzAmpkOieaXMd4f3MqDE923g Date: Wed, 2 Nov 2016 03:20:37 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C927935045D8@NKGEML515-MBX.china.huawei.com> References: <20161031205515.GA25507@pfrc.org> In-Reply-To: <20161031205515.GA25507@pfrc.org> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.58195B8F.0001, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 76d5b2ea2ba801e083fdc5670f46e6ce Archived-At: Subject: Re: [Idr] [internet-drafts@ietf.org: I-D Action: draft-haas-idr-extended-experimental-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: Wed, 02 Nov 2016 03:20:51 -0000 Hi Jeff,=20 Thanks for uploading this draft, recently I also had some relevant discussi= on with people offline. Other protocols such as LDP already provide the mec= hanism for vendor specific extension, and several features have been develo= ped based on that. Maybe it is the time to discuss whether similar mechanis= m is also needed in BGP, so I think this draft is quite useful.=20 Some quick comments about the current draft: 1. In introduction, it describes the consequence of conflicting attribute p= arsing error according to RFC 4271, while the consequence according to RFC = 7606 is less disruptive, it may also be described here, which is either dis= carding the attribute or treating the update as withdraw.=20 2. In the TLV of Extended Experimental Attribute, several fields are furthe= r defined after the "Implementor IANA Private Enterprise Number" field, whi= le many implementers may follow this design under their Private enterprise = number, the mechanism chosen in LDP may also be considered, in which the fo= rmat of data after the Length and vendor-ID field are vendor-dependent.=20 3. As the Extended Experimental Attribute can contain a series of TLVs, is = it possible that TLVs belonging to different vendors, or TLVs of different = features are carried in this attribute? If this is the case, further specif= ication about the processing of unrecognized TLVs and the error handling wo= uld be needed.=20 Best regards, Jie > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jeffrey Haas > Sent: Tuesday, November 01, 2016 4:55 AM > To: idr@ietf.org > Subject: [Idr] [internet-drafts@ietf.org: I-D Action: > draft-haas-idr-extended-experimental-00.txt] >=20 > IDR, >=20 > There's a larger conversation to be had about proper stewardship and use = of > code points of all sorts, but path attributes have our attention for the = moment. >=20 > A quick draft for consideration and to motivate discussion. >=20 > -- Jeff >=20 > P.S. I'm sure there's a number of rough edges in this. I knocked it off = in less than > two hours after not enough sleep. >=20 > ----- Forwarded message from internet-drafts@ietf.org ----- >=20 > Date: Sun, 30 Oct 2016 07:53:04 -0700 > From: internet-drafts@ietf.org > To: i-d-announce@ietf.org > Subject: I-D Action: draft-haas-idr-extended-experimental-00.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >=20 >=20 > Title : Extended Experimental Path Attributes for BGP > Author : Jeffrey Haas > Filename : draft-haas-idr-extended-experimental-00.txt > Pages : 7 > Date : 2016-10-30 >=20 > 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. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-haas-idr-extended-experimental/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-haas-idr-extended-experimental-00 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > 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 > _______________________________________________ > 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 >=20 > ----- End forwarded message ----- >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Tue Nov 1 20:21:32 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A599C1294FB for ; Tue, 1 Nov 2016 20:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.718 X-Spam-Level: X-Spam-Status: No, score=-5.718 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, RP_MATCHES_RCVD=-1.497, 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 rCEr1lC9_wOD for ; Tue, 1 Nov 2016 20:21:30 -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 BF86E1294F9 for ; Tue, 1 Nov 2016 20:21:29 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CUI78723; Wed, 02 Nov 2016 03:21:27 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 2 Nov 2016 03:21:27 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Wed, 2 Nov 2016 11:21:20 +0800 From: "Dongjie (Jimmy)" To: "John G. Scudder" , "idr@ietf.org" Thread-Topic: [Idr] Working group adoption call for draft-gredler-idr-bgp-ls-segment-routing-ext Thread-Index: AQHSM7weK75Gna9gMEK2DDGtD6EYfqDD5AWA Date: Wed, 2 Nov 2016 03:21:19 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C927935045E7@NKGEML515-MBX.china.huawei.com> References: In-Reply-To: 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.58195BB8.0029, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 7216d8aca70e1b09e74f70d02851aaf9 Archived-At: Subject: Re: [Idr] Working group adoption call for draft-gredler-idr-bgp-ls-segment-routing-ext 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, 02 Nov 2016 03:21:32 -0000 Support the adoption.=20 Best regards, Jie > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of John G. Scudder > Sent: Tuesday, November 01, 2016 5:16 AM > To: idr@ietf.org > Subject: [Idr] Working group adoption call for > draft-gredler-idr-bgp-ls-segment-routing-ext >=20 > Hi Everyone, >=20 > The authors have asked (some time ago actually) for the WG to adopt > draft-gredler-idr-bgp-ls-segment-routing-ext. >=20 > If you support or oppose adoption please reply indicating so. Reasons for= your > position are helpful, as volunteering to review, comment, and/or shepherd= . >=20 > The adoption call will end November 13. >=20 > Thanks, >=20 > --John >=20 > P.S.: https://www.ietf.org/id/draft-gredler-idr-bgp-ls-segment-routing-ex= t-04.txt >=20 > Abstract >=20 > Segment Routing (SR) allows for a flexible definition of end-to-end > paths within IGP topologies by encoding paths as sequences of > topological sub-paths, called "segments". These segments are > advertised by the link-state routing protocols (IS-IS, OSPF and > OSPFv3). >=20 > This draft defines extensions to the BGP Link-state address-family in > order to carry segment information via BGP. > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Wed Nov 2 02:13:19 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A78B212947D for ; Wed, 2 Nov 2016 02:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.085 X-Spam-Level: X-Spam-Status: No, score=-4.085 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, T_KAM_HTML_FONT_INVALID=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 TIZ5CYUgVMQA for ; Wed, 2 Nov 2016 02:13:15 -0700 (PDT) Received: from cmccmta1.chinamobile.com (cmccmta1.chinamobile.com [221.176.66.79]) by ietfa.amsl.com (Postfix) with ESMTP id 58579129551 for ; Wed, 2 Nov 2016 02:13:10 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.121.19]) by rmmx-syy-dmz-app02-12002 (RichMail) with SMTP id 2ee25819ae1f371-5d21a; Wed, 02 Nov 2016 17:13:04 +0800 (CST) X-RM-TRANSID: 2ee25819ae1f371-5d21a X-RM-SPAM-FLAG: 00000000 Received: from cmcc-PC (unknown[223.69.29.24]) by rmsmtp-syy-appsvr10-12010 (RichMail) with SMTP id 2eea5819ae1e9d2-45b4c; Wed, 02 Nov 2016 17:13:03 +0800 (CST) X-RM-TRANSID: 2eea5819ae1e9d2-45b4c Date: Wed, 2 Nov 2016 17:14:46 +0800 From: "lizhenqiang@chinamobile.com" To: "Dongjie (Jimmy)" , idr References: <20161031205515.GA25507@pfrc.org>, <76CD132C3ADEF848BD84D028D243C927935045D8@NKGEML515-MBX.china.huawei.com> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 7, 164[cn] Mime-Version: 1.0 Message-ID: <2016110217144380893130@chinamobile.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart412825608608_=----" Archived-At: Subject: [Idr] New Version Notification for 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, 02 Nov 2016 09:13:17 -0000 This is a multi-part message in MIME format. ------=_001_NextPart412825608608_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCkEgbmV3IHZlcnNpb24gb2YgIGRyYWZ0LWxpLWlkci1jb25nZXN0aW9uLXN0YXR1 cy1leHRlbmRlZC1jb21tdW5pdHkgaGFzIGJlZW4gc3VibWl0dGVkIGZvciB0aGUgY29taW5nIG1l ZXRpbmcuIFlvdXIgY29tbWVudHMgYXJlIHdlbGNvbWVkLg0KDQpDb25nZXN0aW9uIHN0YXR1cyBl eHRlbmRlZCBjb21tdW5pdHkgaXMgaW50cm9kdWNlZCBpbiB0aGlzIGRvY3VtZW50IHRvIGNhcnJ5 IHRoZSBsaW5rIGNvbmdlc3Rpb24gc3RhdHVzLCBlc3BlY2lhbGx5IGZvciB0aGUgZXhpdCBsaW5r IG9mIG9uZSBBUywgdG8gb3RoZXIgQkdQIHNwZWFrZXJzLiBTb21lIGFwcGxpY2F0aW9ucywgc3Vj aCBhcyB0cmFmZmljIHN0ZWVyaW5nLCBjYW4gZ2V0IGJlbmlmaXRzIGZyb20gdGhlIGxpbmsgY29u Z2VzdGlvbiBzdGF0dXMgaW5mb3JtYXRpb24uIA0KDQoNCiBUaGUgSUVURiBkYXRhdHJhY2tlciBz dGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCiBodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1saS1pZHItY29uZ2VzdGlvbi1zdGF0dXMtZXh0ZW5kZWQtY29tbXVuaXR5 LyANCg0KIFRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWxpLWlkci1jb25nZXN0aW9uLXN0YXR1cy1l eHRlbmRlZC1jb21tdW5pdHktMDMgDQoNCg0KDQpCZXN0IFJlZ2FyZHMsDQoNCg0KbGl6aGVucWlh bmdAY2hpbmFtb2JpbGUuY29tDQoNCg== ------=_001_NextPart412825608608_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =0A
<= div style=3D"font-family: =E5=BE=AE=E8=BD=AF=E9=9B=85=E9=BB=91; line-heigh= t: 21px;">Hello,

A new version of&nb= sp; draft-li-idr-congestion-status-extended-community has been submitted for the coming meeting. Your comments are welcom= ed.

Congestion status extended community is&= nbsp;introduced in this document to carry th= e link congestion status, especially for the=  exit link of one AS, to other BGP speakers. Some= applications, such as traffic steering, can get benifits from the link co= ngestion status information. 


 The IETF datatracker = status page for this draft is:

 There's also a htmlized version available a= t:
=0A


Best Regards,
=0A
lizhenqiang@chinamobile.com
<= /div>=0A

=0A
=0A ------=_001_NextPart412825608608_=------ From nobody Wed Nov 2 03:35:50 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2501712948A for ; Wed, 2 Nov 2016 03:35: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, 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] 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 NljfLiHg2Uct for ; Wed, 2 Nov 2016 03:35:45 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0124.outbound.protection.outlook.com [104.47.0.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 38A2E129AB8 for ; Wed, 2 Nov 2016 03:35:42 -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=jM/Czt/WWqz9jEXMDajS7R27CDG4CTR0ivKY5Sm31aU=; b=EI2INkepNG7NqG8BM+RvzaVBZTBSd9iODhofT7zUqzOPykdAbWSFTL6SMvS/1Xq+qc74x1gLSFtDM0SqMNwDprT3mBWEPAm2XFS7m3QteKesHkTGXmnDINJb5CRthH/M1otweyUu173bg8Tx/K4il07nZasIAboWUn8xLBSLiRo= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (81.135.210.62) by HE1PR0701MB3003.eurprd07.prod.outlook.com (10.168.93.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.707.1; Wed, 2 Nov 2016 10:35:39 +0000 Message-ID: <025801d234f4$78232740$4001a8c0@gateway.2wire.net> From: t.petch To: "John G. Scudder" References: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> <20161101144036.GB10519@pfrc.org> <25D24BDC-5322-4B19-A971-9FDD65C07BF1@juniper.net> <01c101d23467$9c8b0cc0$4001a8c0@gateway.2wire.net> <4070F36C-3D40-4EE8-B6F0-D077DB18875A@juniper.net> Date: Wed, 2 Nov 2016 10:32:45 +0000 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: [81.135.210.62] X-ClientProxiedBy: DB6P18901CA0007.EURP189.PROD.OUTLOOK.COM (10.169.208.145) To HE1PR0701MB3003.eurprd07.prod.outlook.com (10.168.93.137) X-MS-Office365-Filtering-Correlation-Id: 5e9fe0a5-c20a-4e86-4d89-08d4030bfd97 X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3003; 2:uf3Uk1scCDxLKwlERMkWwzb3JLk4wynA2BreSL3yN3cs3LDqq8HTCR23o/j2Ca0CETQR3NsZTxRKt7sSRIZPbPZ4v0Duxh++BEU2U6fikTvIqo6VGOc+dlBedGJ97LsXhVR+n2sSE1yQeYGiUEdOsJgNLk1Kej6mvenS//r/yneq0ciHK8b6ZhUDldBRHQ7fVkp0X48G9NZt5ovhfcVxuQ==; 3:+KWx1Jy5tY+Tjv4LjIYMIVG5a0YcXTslKWcmnUSyEuFty53hfIVcqPonkcwP2/YlLdbmLOsA0t/9suQ0COXTEFRYPvKWf//DVHolA9WTcN2wNzpTyvivZWXPqwFD8sGtaloB5373XnzddsevLaZpOQ==; 25:sG52tqM2V+NaaTuT3JNG3A9XdXmLBXqABy5mnsjb13Or7NmN9bIYjdAoHI2xOf8sYUyS+Sh4Yuex0Y8SXtydh5mC0bzNtKgaRCvP87aI1WWl3IRtF2N/Qw85SJdRqNPpCe5zdM4CFNKj6fdhfLrTLqdIkdI0z3QQXSX3fMuX032E0CFBS81NXaAId+PE5mhcETySCkF+t0PMylSeLftBFBY47u3ST4s5JZlI6ePVhwkQrSmEK4WTqwKO5QH1VBNrtyzs0RajeD9j67yEsGH95HbLEdTWBjFlLLiaw57cCiJ2YEq9Vy/mGvjw1Wl6uSS1zn2Kxwq2baWK1gI/FY2CSc4ihJf7D/RdJCZkh25IZCHOC959r+liFf0/mkdchmYcZ/YshMp/nsPI29YVD9rKnRgV02DMs8ebmdY2dbSr/To= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR0701MB3003; X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3003; 31:aORJeMbpkCOlXn7lR1F95dbD5guCFQKN5018n6q+IaU27RYaMCBtakY4JRpd7GACHqAG3yHIS6J/DA09v1bNFfKumFlWcZnDRSAAEkvV4WfBgJ8qgP62U63ZYvdNyBJIMRNQOyvocdeGbaF2N1QkZYtouhNp6HFScVCFbCHt1GNf/gNSmd1JWNONrrEh8pPJpySpmBLZmDd460BsKXFyNdyvj8IFj1+GN4dk9RuRhrU6e3v/p+sGi3L5vRW1w4di1CpaI0UFg418brRn/AjhgA==; 4:j4IAfOwA2NNQ1jOZuvgLBLUvvkl5/M1L57UlKKDSe+TbLbkp0gxdBOCewbnV3+A8Itj7G07gaLPL7Ge4qRvYijbBKrXSdt0c4/ucONzBdquR6hI8BMLnWQC5DFv2OP71RGPBIO/i9lYf4SNyFOoh3X8QSbmC+uIohthcHiZRMnVOJ8l0pjhTcP//mOOMVUyJ6RJqpReLbQQ+QrAYQ63hb4/voxIr84yHvgWh12uxSsw19/48WhNuBmcGb18g8j7YUvSqOAP7lIt9B6f0mzRsirxhQWzE9rVcC4m7mt15kebdRuMcPma+INwdr80c7+ueySAIfJydXGax7KP1PB48+trfNpGnUdR7cf2FqWwMgx6DfO1kf4hflmFyNvmksppIoI/PtPy+aWl+Ep6luK3flpGrodSoWiDSKD9UB4Rdko9llSvXz8m18v0mwD0k2coe1hw8FAH/jB9UflhVeq4u/s5AmiqBoahtr64k1V8eWqk= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(178726229863574)(138986009662008); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:HE1PR0701MB3003; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB3003; X-Forefront-PRVS: 0114FF88F6 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(5423002)(24454002)(13464003)(189002)(199003)(377454003)(101416001)(84392002)(77096005)(44716002)(6666003)(23756003)(4720700003)(92566002)(50466002)(68736007)(4326007)(62236002)(47776003)(81816999)(2906002)(230700001)(81686999)(86362001)(6916009)(5660300001)(7736002)(8666005)(66066001)(14496001)(305945005)(7846002)(76176999)(116806002)(97736004)(110136003)(81156014)(50226002)(81166006)(8676002)(189998001)(3846002)(61296003)(50986999)(9686002)(6116002)(19580395003)(1456003)(15975445007)(33646002)(42186005)(93886004)(230783001)(105586002)(19580405001)(44736004)(106356001)(586003)(1556002)(1941001)(74416001)(7059030)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB3003; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; HE1PR0701MB3003; 23:e5jGlbd9vO8wv62RCun0eippkCM5VjjlXGX6z?= =?iso-8859-1?Q?YzIpD4WR0DrAlZw9KfBBuq19i1qZggsKpqhNUKwHZSPyXF4JXH2ASFOztE?= =?iso-8859-1?Q?1NkZF0+rrX3FZHCxP1NXAak1UZwoY4nPgXdQjM6Z/RV6uW10OocYoiHSQb?= =?iso-8859-1?Q?KdpAAXvc5j3FTtvlDis40C7igzn1PG9qND0WF1LtkwPaqUSxmUc2E3dstg?= =?iso-8859-1?Q?7LY4XutWpG4NwqqIjNCHepxETnVTTPtDKdbUX4twwM8E2dHIYUjAOOVdbr?= =?iso-8859-1?Q?6lXyNKPBUltyuc3VRCCIbV0zxwOWBac1o/FQix/tNkcmdnIo2QZf4Ksodi?= =?iso-8859-1?Q?vQ118c1Rd/DOYeyjskpd2oyF+nJEji6oiUBojOeIZ+eegf1ivt8JEZNMoO?= =?iso-8859-1?Q?P6gOh6Y64hDyb+XN09k9rj96H2p9bmwBvP6N1oHrlA8SwUbfscBiRBUgv1?= =?iso-8859-1?Q?NTtf/juiDxJd7HGw0tsi3fqGvpEo4mXpAsYqAb7JdB/FkFp/u33sbjFN+Z?= =?iso-8859-1?Q?U2A/dGgjSSji8A1r8xqqNDInDq+3jKfcQjB/OBh1B2GSAgix6iI6BNXCYZ?= =?iso-8859-1?Q?cCoH/xUlwwwsHMTqTWtYSJA3NbzwOZ6a7mIQKUTLL5pq2LQO2KPRp7QMdN?= =?iso-8859-1?Q?it1Z1yE8IJLPAGIFgiR5hqwk1K/Vd8QUSo/8NdOBekwK+xOC0X2KkRX2Hn?= =?iso-8859-1?Q?tNtP6ktwRgt4YbgUtbNg1DPmzcFdFmpZxwFhXjSnhJMH8JbGV+ZA4ljP37?= =?iso-8859-1?Q?lzqkRTr4T1ZN/VVH4+bQX+hLMLeX53nLwZvodjrrgGyJ1AuBHSMCUnUQ1x?= =?iso-8859-1?Q?vDKjHCcN4D/Uzv6oOVtFb7HAClxhwzhBSk1Y93bdi0YJbuUKgsoJgQnQ9F?= =?iso-8859-1?Q?EJBaQWZXEcj+bWZCpKHzBwMkOr9tZncFwczs8x1vJttAGZ91gPydQuXbOp?= =?iso-8859-1?Q?ILHmYaBPUX557uQKvhc2Ve+qvlqnqVNz7I+k1ttsrmlPJJtM5EsV5ISSg0?= =?iso-8859-1?Q?hdE8mRB71ZZ4K9OPh0t3XnD1ZxQvZLqtMmlYXHTBdng+zw/FkPRlUDqTAw?= =?iso-8859-1?Q?vElUwGAPNOx3vSZUUbGpEtppNgrjSyqlNbe3dgAooUWQVFSf87ZsEX3Bdl?= =?iso-8859-1?Q?a39qcnbI9O2PHN5r4oHufenTdTcQl02Ztze0XCp0eu1mDA/TO1dIcxT1yI?= =?iso-8859-1?Q?UrKLqDU4tz9eNdcoRadnOfDLwIt43weRnKsJqQdHTq8izcr21ovgg+CC1N?= =?iso-8859-1?Q?INbvzO6MVf05VINPxLIuuu1/zZdYN9DZ/7y/iif1X9LlByB8pdnoed0EMF?= =?iso-8859-1?Q?wbgxaz7/Cd0azEEUueQ2BjhHfNLb2tifS/7Z7JUnebw2mOSlwTqLM7/yc2?= =?iso-8859-1?Q?ZuY1/2VNM9PCM1KFJXzxvPuFEPigcpTgbZedrlbU4zQa9YGryaSsff19dl?= =?iso-8859-1?Q?bk0UcZTGvUnYJ6Yy0IzCkW001K/xqnZmtqXwRWWgOSLkteW2YbkScWOhUt?= =?iso-8859-1?Q?mAQyN9osv1O0MVA2J9u8U3PYsc6L9NR0RoWP+ApRhvyUReis10qnYOHnmg?= =?iso-8859-1?Q?IRMKkMcjXe/9bDvhRC7GDmGfKxLFEEZ/AKp87d2TXOMoPSVpeK7z130EKI?= =?iso-8859-1?Q?+0KtEgIxHyKPg=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3003; 6:b5lyRaf+Kmgduzesnx+zFLAvGgrc41WjbdWhLA/++8+UqX42up/CHsGgcW0Izv0sjOGacPWokwO8EznfRcQUY2kB3yfkgklcxdzXK95zhD62fg/cdKt1UcUONdDr8qmgRImjTduKjAjfYz0jyG4y1vSAzVtaRd/ZgkmHo0ZEitFeoQSebeXC9T2kZF6pD+E9YY+Ce2gKHetE/hN6S6ay6lrpBwWPa2A8KSztiw+OsCksYVF9h6tTzzTgQku/GcYWsOO42HD7a406ygPjfDzP9UvOcWqz+4eWmYPq/7qN/NGpn8dJw0b5gKw3purKoeZX; 5:jLalkL3Xe/drTrkoQeScIQAVB6He9NtgbvEQ6YXtZb1mF+VoQxjRSwxuzY+lxWAnL46qeBpO8uJv87sXg6gA4DoXEMfEnEE4Jr4R9y6p6fE78kJ2n/ryQJF/FILVLJw7+7glknRyOLrcqiH3HhNLsg==; 24:4WJZfDbNfn4TPHJ2/38+ZOk9wEwR4+nLbOL+qP408u0m3/fkK5cHyIV4Sy1PfghuJZ6m7i2bbaVjFrSL4T8FPvS1k2eALfrBcyVy+Mt/oXc= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3003; 7:ElMWeFFeFW435u/9+6FSyL6kAWbDpFYRFAwiOe3uJuXC+ujyFZCSJuWj4XpJCMl/Br4OTxsPcGc8vjNUJdDzvRftsfzaNOOmqgb+cjh8hyyvNFC5K4DA07UBqtXGVY5yW+S6SZe9Fz53evj+nEw4Ez6uBY+WXXiWLPF7stRznCPGISnFxhgHc/OsQA9BnwkTEuSqk/jYIBllM7rsqfqfHBcXGPOiSYYJ8CNuEt67zL7Drx6O2Lc4bOjTZ/SEfskpgQeJTPoL7UZnKwB4anFbEM6Ppsl7upXdJ7PpvYxZjyijoEHkOE1dpxenpwJa3VKoy/dzszW+SwLPU6QieeoXeCmt/FlTfbX7VWxlNsKjgk0= X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Nov 2016 10:35:39.5053 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB3003 Archived-At: Cc: IETF IDR Working Group Subject: Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129 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, 02 Nov 2016 10:35:48 -0000 John Yes, I really was replying to the adoption call, opposing adoption on the grounds that the I-D as it stands is insufficiently precise. I first saw IANA using 'deprecated' as a status in 2013 and this led to a discussion on the main IETF list, that the term had been in use for a while in SMI but that the SMI definition seemed inappropriate for the use to which IANA were now putting it and that we needed a definition. The then current version of draft-leiba-cotton-iana-5226bis was put foward as the place to define 'deprecated', IETF-wide, and AFAIK, that has been the practice since. So we have a definition that has been in use for three years, in the context of IANA, which is, to quote, " Specific entries in a registry can be marked as "obsolete" (no longer in use) or "deprecated" (use is not recommended). " I believe that this I-D cannot be understood without reference to that definition, hence my opposition to an I-D that leaves the interpretation of 'deprecated' up to the reader (who may assume that the SMI definition is appropriate). I also wonder if those agreeing to adoption still do so with that as the meaning of the term; perhaps they do, but Robert questioned whether or no 'deprecated' was really the right status and I am of like mind, although my reasons may differ from his. Tom Petch ----- Original Message ----- From: "John G. Scudder" To: "t.petch" Cc: "IETF IDR Working Group" Sent: Tuesday, November 01, 2016 6:20 PM Subject: Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129 Tom, I'm confused by your message. It appears to relate to the proposed adoption of draft-snijders-idr-deprecate-30-31-129 and not to my most recent message regarding IANA process at all, even though you followed up to, and quoted, mine. I'll proceed on that assumption. I agree that it's unfortunate there is apparently no referenceable definition of "deprecate" but on the other hand, this has not impeded many code points from being deprecated in the past. Somehow we have muddled through. I suppose it wouldn't be the end of the world to do as you suggest and normatively reference 5226bis even if it means sitting in downref indefinitely, because I think IANA will be willing to mark the code points deprecated on the strength of the internet draft, following the early (de!) allocation process. But also think it would be fine to follow the other branch of your suggestion and quote their definition, removing the downref. Apart from the question of providing a reference/definition for what "deprecate" means (which I thought we'd already settled), the rest seems to be editorial minutiae. None of these things (request for a definition, other editorial issues) seems to me to be a basis for "Oppose". The question before the WG is really "do we want to deprecate these code points", and that's what I'd most like to see people engage with in deciding to adopt (or not) the document. To be clear, for purposes of this adoption call, I'm assuming we are using the 5226bis Section 9.6 definition (or "definition") you refer to, viz.: Specific entries in a registry can be marked as "obsolete" (no longer in use) or "deprecated" (use is not recommended). If someone who has already responded did so on the basis of thinking that "deprecated" means something other than "use is not recommended" they may of course revise their position. Regards, --John > On Nov 1, 2016, at 1:44 PM, t.petch wrote: > > Oppose > > We all know what deprecate means which, based on recent discussions of > other topics on this list, means we are using many divergent > ones in our assessment of this I-D. > > 'deprecate' is a technical term in the processes of the IETF. You need > to define it, or better, use the existing definition. > > That definition is in > draft-leiba-cotton-iana-5226bis-18 > which therefore MUST/SHALL be/is REQUIRED to be a Normative Reference, > and yes, that means waiting for that to become an RFC before this can > advance; which interaction I see as a necessity. > > Otherwise, we haven't a clue what we are adopting. Well we have, but it > is about a dozen different clues. > > Likewise, but not so critical at this stage, having an RFC that starts > ' This document requests IANA ..' > will look, well, not very sensible. If you believe in what you are > doing, then I would like you to state it as a fact. > 'This memo changes the status of ... in the IANA Registry to > 'deprecated' > > And what you have at present sits oddly with the IANA Considerations. > Usually, the latter says > 'IANA is asked to ...' > which is edited by the RFC Editor > 'IANA has ...' > > Yet you have an IANA Considerations of > 'IANA has ... > Back to front, IMHO. > > Tom Petch > > ----- Original Message ----- > From: "John G. Scudder" > To: "Jeffrey Haas" > Cc: "IETF IDR Working Group" > Sent: Tuesday, November 01, 2016 4:20 PM > > >> On Nov 1, 2016, at 10:53 AM, John G. Scudder wrote: >>> On Nov 1, 2016, at 10:40 AM, Jeffrey Haas wrote: >>>> 1. Do we actually need a draft published to request IANA to block > out >>>> allocation of these code points? If so, we're going to end up with > a number >>>> of trivial drafts for these corrective actions. I'm interested in > hearing >>>> the IESG's opinion on this point. >>> >>> IANA did specifically request an RFC to reference although they > stopped short of explicitly saying "if you don't promise to give us a > document, we won't do this action". I have asked them to clarify and > will report back, but I suggest that for now the WG should assume that > we do actually need to publish draft and progress it to RFC. >> >> Update: Michelle @ IANA confirms that they do require RFC for > deprecation from a Standards Action registry but agrees there is no > documentation of this requirement specific to deprecation, they've just > inferred it from the requirement to assign one. She says she'll bring it > up on the Thursday IESG telechat. >> >> Again, for now the WG should assume we do need an RFC. >> >> --John >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr > From nobody Wed Nov 2 03:37:52 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A5AB1294C7 for ; Wed, 2 Nov 2016 03:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.097 X-Spam-Level: X-Spam-Status: No, score=-4.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497] 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 IPPL_BvjvMfR for ; Wed, 2 Nov 2016 03:37:48 -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 C9E96129AB8 for ; Wed, 2 Nov 2016 03:37:48 -0700 (PDT) X-Original-To: idr@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 4307D6289F for ; Wed, 2 Nov 2016 11:37:47 +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 D857A60F0C; Wed, 2 Nov 2016 11:37:46 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id D308C45526; Wed, 2 Nov 2016 11:37:46 +0100 (CET) Date: Wed, 2 Nov 2016 11:37:46 +0100 From: Gert Doering To: "t.petch" Message-ID: <20161102103746.GT79185@Space.Net> References: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> <20161101144036.GB10519@pfrc.org> <25D24BDC-5322-4B19-A971-9FDD65C07BF1@juniper.net> <01c101d23467$9c8b0cc0$4001a8c0@gateway.2wire.net> <4070F36C-3D40-4EE8-B6F0-D077DB18875A@juniper.net> <025801d234f4$78232740$4001a8c0@gateway.2wire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <025801d234f4$78232740$4001a8c0@gateway.2wire.net> X-NCC-RegID: de.space User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Cc: IETF IDR Working Group Subject: Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129 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, 02 Nov 2016 10:37:52 -0000 Hi, On Wed, Nov 02, 2016 at 10:32:45AM +0000, t.petch wrote: > So we have a definition that has been in use for three years, in the > context of IANA, which is, to quote, > " Specific entries in a registry can be marked as "obsolete" (no longer > in use) or "deprecated" (use is not recommended). " > > I believe that this I-D cannot be understood without reference to that > definition, hence my opposition to an I-D that leaves the interpretation > of 'deprecated' up to the reader (who may assume that the SMI definition > is appropriate). So what you're saying is "add a link to that reference, and all is good"? Why is that interfering with draft *adoption*? Sounds more like wordsmithing for the then-WG document before WGLC to me, not a fundamental reason to not accept the draft. 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 Nov 2 04:28:00 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95E081294F5 for ; Wed, 2 Nov 2016 04:27:59 -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, 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 IMHuny9oDfTP for ; Wed, 2 Nov 2016 04:27:57 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 837AB1294F3 for ; Wed, 2 Nov 2016 04:27:57 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id p190so261815340wmp.1 for ; Wed, 02 Nov 2016 04:27:57 -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=4RMEfaYU9Ca1J7bYCcEkSXy6qK6CcQCJqeIKZ+m83Z8=; b=FKkvbRIjpTS3c1GCENnTHWlapn0y73QK6qDufL/vezP+hQ+gmLCZ2Y3S8R+qckPiP7 SWs1jkK4T67kwQbvYz919bUs/ikDGaA2eRdSRmksE23kRUHB1mnzIn7X8j7dcVksGkvF h6s/fdfiznFgoBRFIT7rCaA/fmXDG2KJc0yMfvNFNS3clKYVm7I1CMI0DXWz2p57mFCO thiKHWGIWczT6aKKwOQ5WrHOzeUHhfXPcIHD8P7tRiH+jR3EyIu1REQ0s2BFBK3a2+3P xJkmXOn42eGTPlxQtLYGVKJrS2qXG/KCXSoqBMbK2Crq9EOhUo5iDXLdHEZ3JrSoad1U 58/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=4RMEfaYU9Ca1J7bYCcEkSXy6qK6CcQCJqeIKZ+m83Z8=; b=KW9EDAcM34r3eqsiDq+HZ2PUa9iRgnRT8c6wq9HLFzHIqOXptn7E3SpFKyqmJlZ1XR HJ9ZfPt6FOuRDHHujcGeyktsQ6FytioGeqHSwTDSY+HpK8vdLw4oD/fgPZFXp0MhZHef fw/Cirq88j8bTzT3YLHsEtlF0BxBxH4R/JfoTnmw+zWSxRXAvcgDk+TV43MJDlBZfdvq d9us490n41G27gkY6IyvB4XcZxiTWFdvONZdJzZ0kvZS/bv+SyLIaKD/2TcYR2KAPYM+ WbfNaQH+l/GaSWOw9RrkYXWWZrUYCu6QT+QqDA8OLFXj6GHjrp/EmYDjVw5vtoXs8Q3b y6ow== X-Gm-Message-State: ABUngvc/6j4kX3ZfggP8GQqvls4qTyw5IHfcFWeqedZPtPRYe5QD1VNtLZnDGJ25cCK2lQ== X-Received: by 10.28.198.67 with SMTP id w64mr2950764wmf.13.1478086075932; Wed, 02 Nov 2016 04:27:55 -0700 (PDT) Received: from localhost ([2001:67c:208c:10:6918:2511:d26:7937]) by smtp.gmail.com with ESMTPSA id 18sm2626992wmp.24.2016.11.02.04.27.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Nov 2016 04:27:55 -0700 (PDT) Date: Wed, 2 Nov 2016 12:27:54 +0100 From: Job Snijders To: Gert Doering Message-ID: <20161102112754.GM1581@hanna.meerval.net> References: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> <20161101144036.GB10519@pfrc.org> <25D24BDC-5322-4B19-A971-9FDD65C07BF1@juniper.net> <01c101d23467$9c8b0cc0$4001a8c0@gateway.2wire.net> <4070F36C-3D40-4EE8-B6F0-D077DB18875A@juniper.net> <025801d234f4$78232740$4001a8c0@gateway.2wire.net> <20161102103746.GT79185@Space.Net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161102103746.GT79185@Space.Net> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.1 (2016-10-04) Archived-At: Cc: IETF IDR Working Group Subject: Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129 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, 02 Nov 2016 11:27:59 -0000 On Wed, Nov 02, 2016 at 11:37:46AM +0100, Gert Doering wrote: > On Wed, Nov 02, 2016 at 10:32:45AM +0000, t.petch wrote: > > So we have a definition that has been in use for three years, in the > > context of IANA, which is, to quote, > > " Specific entries in a registry can be marked as "obsolete" (no longer > > in use) or "deprecated" (use is not recommended). " > > > > I believe that this I-D cannot be understood without reference to that > > definition, hence my opposition to an I-D that leaves the interpretation > > of 'deprecated' up to the reader (who may assume that the SMI definition > > is appropriate). > > So what you're saying is "add a link to that reference, and all is good"? > > Why is that interfering with draft *adoption*? Sounds more like wordsmithing > for the then-WG document before WGLC to me, not a fundamental reason to not > accept the draft. No, it appears that Tom is saying that IDR cannot deprecate codepoints until IETF/IANA have developed a deeper understanding of the word "deprecate". Tom, can you confirm that in retrospect you would've opposed https://tools.ietf.org/html/rfc6938 too, and that it is not clear to you what that RFC accomplishes? Tom, do you have an alternative strategy to prevent value 30 from being assigned as path attribute value to the next early allocation, other then adopting and publishing draft-snijders-idr-deprecate-30-31-129? Kind regards, Job From nobody Wed Nov 2 05:52:26 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C72A12961E for ; Wed, 2 Nov 2016 05:52:24 -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=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 EqvrpNYLb9y3 for ; Wed, 2 Nov 2016 05:52:22 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10106.outbound.protection.outlook.com [40.107.1.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 963111295BB for ; Wed, 2 Nov 2016 05:52: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=MAF90EyGfYQQ3qY7rUZbRJNskV0p8yLQU2W+BEW/GSI=; b=DWt1gRADp37lcEaceiYNKbM88R+Q1UnL068R9Ow6QxS44016dUe0aXYpE3A1yaI1bxlzwq/n+5svPh5aBaMNuDF6vwa3BvvujQoRShKvmllaHgMaeWTOIqrEfeZ+4yzY4TevEeCICDgfl0xG5VCyK2vXOOtBI6aZ8z9EN6Lu1Lo= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (81.135.210.62) by VI1PR0701MB3007.eurprd07.prod.outlook.com (10.173.72.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.707.1; Wed, 2 Nov 2016 12:52:18 +0000 Message-ID: <008b01d23507$8f17a3a0$4001a8c0@gateway.2wire.net> From: t.petch To: Job Snijders , Gert Doering References: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> <20161101144036.GB10519@pfrc.org> <25D24BDC-5322-4B19-A971-9FDD65C07BF1@juniper.net> <01c101d23467$9c8b0cc0$4001a8c0@gateway.2wire.net> <4070F36C-3D40-4EE8-B6F0-D077DB18875A@juniper.net> <025801d234f4$78232740$4001a8c0@gateway.2wire.net> <20161102103746.GT79185@Space.Net> <20161102112754.GM1581@hanna.meerval.net> Date: Wed, 2 Nov 2016 12:48:34 +0000 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: [81.135.210.62] X-ClientProxiedBy: DB5PR0101CA0007.eurprd01.prod.exchangelabs.com (10.165.200.145) To VI1PR0701MB3007.eurprd07.prod.outlook.com (10.173.72.149) X-MS-Office365-Filtering-Correlation-Id: c95df1ed-fc9f-4b01-0324-08d4031f14ad X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3007; 2:L1XyBG2Mf3gxY0p+ILOpZaUmBL++qLADdvvFjGHVmaJGpMbV1+M6D1Y72IYBpgGqZvqLyH2QSuYjEV3W0XXQUPe5IZmcwvS6YV1dVZzXipSlYX+gaW9V7lBGKMWbPHLUtp3P0GVW4Y4X4l8rKGYs8nb8YnADO3voXf3ygY0BdpSzn1x9p+ovl25zkV2YRTJzdMn+RgyQMEM2GISKdlnUbQ==; 3:pndUHV9FgFF8WGVhp5elWDfMjrKZTYypFKqpq04wiAD8Cs0WxtvZo8xPMIXqH5Fu1aKYA946vbhVdl6V3kUeVrq6aHz1q0WDPBC8NGMN66Ui3By5nwzdcAkABpa0siGgwDowRhf53RsdzHpF60aEIg==; 25:9vMC5vuWMjmVBcnAxGNxT8JjusEWnNCNGgrHbAZbiJlaVsDMsQnmLfrJrsI/EYY4qHTA1uGSLdEmJikHEohjplsHbii3YYMpdVWtQaDPTcHavk0WzMY+OX6QYL8O6LrfyyiIFfI2+G4JiWZJNjj44tggwwxI2sjKOLlLkkGeiNAgKt3TW1kcGOYwW1BFbGjxUtDph0sTpfiNan/WGXV46R/HjH3CkTkWs+b7fofwMK1Apv4WTAzFgCdGn52QtBB3ou7Uu62w0bcEXF2ts8oIksdrmedNFqWOINVvJ6vF4Ghq5hb7pjST/zo+j5PvP+S5JH9/XGCKqOHkE2QdHHmpoviTUM9m7SO4km8cRkwO8nfZm3BdeW+n9H/XboLH+nkXGHot5GOmqC1UCkwBPDfZO0jOTsLAZl7LbIBaHmmBhYpvwhXJy/ptM6Ig3YvlLJAt X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR0701MB3007; X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3007; 31:DJP0q/NxndJFKTlqBZIiDht229pC1Vnv7jp/ay5vRrpGra00Lf1M8XPFZ9OW2BReOSNs6fziqu5BUtBtoyszkpEEXrx0ZDFx+tEkAop9DtIYdUQangG5AAvnNtGxY62aM/WU5S1HAiyEUWjk7duUualqiFA1vg1ZuW8vCTpwZj2/8GF8TdV416qOpdyzvixjabeb7hUrfuKDKkqMpLs6Tg3GddujtERqjZH9QpHTa1cw+1wlfUv75xtyIBf4hF3YoXl6oRE8sLx07m1fyiOC3g==; 4:4IqzbFT3T/t0WXCgV+/7yFkxULKDzo/3FNdZd/eP1DV/+E2K+LHAV11herWli66yWd/kgu69FYbWo+7i+Qtjt2dZmI6+DIao8c/qawAmXI++utf1mboUE9CoDDJ0AJT6LnxMgxGJfX5d9aGicjrxuRA39YrCN14xWtqfmzF6244RRsgqu3DCRVhu99y/8xD8fgRbauF1kaxAVFG2q7ojrYtVhsPDClTxcQl4l/Vr88pLLW8Lyz+lmZ2CmlWtBsYsk/ynuwOYl9GBxrhsSqANSh10ik9lxDu6RTSegUBwo431WuhZtJhUxUIU8GH1UW6Ggtzk6wDbaPM+wG3HDPXqzz74QSQ03XBHXpQ+9JWKfztH2Qe4gMzEkymfKZ1A2+PF6d9a13xvMZgwwl3KRGlB3A+vZBbqbxjrG0LK57nAHOJX/Bl/yKVOfbC7Ye3n2GpgMr6u/oUVCuAToZsv7hO0iQ== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(178726229863574); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:VI1PR0701MB3007; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB3007; X-Forefront-PRVS: 0114FF88F6 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(13464003)(5423002)(377454003)(199003)(53234004)(51444003)(24454002)(189002)(97736004)(23756003)(230700001)(81816999)(116806002)(93886004)(230783001)(1456003)(86362001)(2906002)(33646002)(1556002)(66066001)(50466002)(84392002)(4326007)(77096005)(19580395003)(15975445007)(44716002)(62236002)(19580405001)(47776003)(44736004)(3846002)(6116002)(5660300001)(61296003)(9686002)(7736002)(92566002)(305945005)(7846002)(586003)(14496001)(42186005)(50226002)(105586002)(81156014)(8676002)(4720700003)(81686999)(50986999)(81166006)(76176999)(106356001)(6666003)(5001770100001)(68736007)(189998001)(101416001)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR0701MB3007; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; VI1PR0701MB3007; 23:uOsKqXu6hCIAlZzcu/mrrZirjhmIR5j/yUDSO?= =?iso-8859-1?Q?ASnfcpzceHNvHMoYU5tDqukYGOwYV6v25TIAx611b2p9DVqnXgjToTqa8p?= =?iso-8859-1?Q?7KSJnu7vcM6tChvnxfvt7CfGFkM3Jn6Gb64+eKRb9CC2mzZWEW2AFgPJy6?= =?iso-8859-1?Q?VLTDiCk3JMMDoBawivhQ0qlfTOSSup9MWDowOY7f6mkSXqrOFN8oIA303z?= =?iso-8859-1?Q?DYbA1XmTr9bDy4ej6qVv6bduv1LeHqoJXvZKAe75uE/NcdiqaFQEuk4yfv?= =?iso-8859-1?Q?hJiZVgnDsKgCotqaSqobUBt4ftTPhbg8h9vmpUUlgwpmKISIaR2U8/yjxP?= =?iso-8859-1?Q?XDhv4P+v4y3RD1yMHErY/X7c603Tj+hvOdm8Jpa60BlgRiz202LiQHcaZY?= =?iso-8859-1?Q?0JFl2ntqTcXexLGUCCyaEL/AWWLydIlids5u+IS2d4BUDRxPv7heDxsiAR?= =?iso-8859-1?Q?H/qH5nI0sybjsXsFMz9uDyNfiLM55fm1QuAivgHOriX0SveWE6GOggJhs1?= =?iso-8859-1?Q?a4nL9mUDiGFH7JylbF6efUmBjzwa7D7eQLkVRAh7jgE9pQ8BhfNPB3j8D+?= =?iso-8859-1?Q?tyLvSRD4OednLdEJ32jhv5UFZcShaQKgyA9B330dH2O+e5O1Eh/aVY5txW?= =?iso-8859-1?Q?X7FVLiQO7b8d5y5ekNnmPeETNkndqXhO/L7ldb36ayYCGpLFJHvbZkKcxr?= =?iso-8859-1?Q?oSj1gnD1o6Rs85vPeXCP9hRsLlzHwnPIJZXKbI/xrvHVR+DPOrvDaIIhkn?= =?iso-8859-1?Q?hmMSN8A7BCMTXI6AmR4MMBbmOR90m74qpduHtJJRqeCcghb5CwTFkgyleK?= =?iso-8859-1?Q?zHulECF2cyM4PzLcFG1nsVr2l3m1n+2o/ZBonjqGDASQcacVL8/9z6aGdl?= =?iso-8859-1?Q?LYXQ8neuGMTZHHC3hkBOUA1qtOQclIEufn3khKVSpi69EvIIbScBmpLXk9?= =?iso-8859-1?Q?77epDMPyn1ZJcT+SKCALx6N05yydPmwjy1x5eAS5FIW753MBIVsOANWs+3?= =?iso-8859-1?Q?HIG7JFRqMKx6FCmjfV3Vml9QTMY4dHnsIySsGWNRfrxYaIyZLPsu1yqfTW?= =?iso-8859-1?Q?xyrM/YW+9xs7z4bINBPgAbk61cc4/6SLWbqJRXQq3/mzfYbLMoYFRJDYDd?= =?iso-8859-1?Q?/79ug9b72/uMbFpJfSCeOA7N0S5p6qKcAHkNRZo5I3MMidlIFgoPsiExFv?= =?iso-8859-1?Q?OJ+9djLunJMuiDxlghh3OrkEnhz16Ad1fYGn/woLmqcrQbU86jkCdqPIPN?= =?iso-8859-1?Q?LE34EROv3wUkF6jqn5SqxiStwZnnhXlqUuYLQzqAuqNbSS5CepSSWcFzh2?= =?iso-8859-1?Q?ZxXdexHnRzh9Wb6D5c5oTbmrYm5DlTNqoQ1lFslKXW4pWX5N6gBqs3GdQ8?= =?iso-8859-1?Q?5DAMzADfeL8eA4KTW8MYiBO/baEiguerVRMEqotnn0dgVnqvmKuS+E8BpS?= =?iso-8859-1?Q?68l/A7ARP3o/Q1QqIFfCj/6HH7tQdKIaYW3vEv+bNQxtIjfeh5BJTJ6ShR?= =?iso-8859-1?Q?7yyuhOspJEOiDL2Kt0SLPRyceHB8NCZZyiYXBAWvY8pmRJUo9pBw2UFWn6?= =?iso-8859-1?Q?Sgamw4CN0vv7EdqvqDQLvkgATUO0F6/khmSH8OIH/ok5C68wI?= X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3007; 6:439JTlf0UG0G7MLaM3t9ypNviU22aPEwB+RDm9/RsYp6ZDr+tF5/pJPCK82SSmax/8uocsM7CGhnDPZ33ctauugdwKDfojw+CaSuw0OMW1kyGS+EAY0ntYjALPFi9Sg9tTIot6iZEH6kXX7zoU9PZfW7DcmxTFIdxvhy71MU4ycbZiMPjWdYxDMEFdI7604WbXsPUJGPiKyORmACasTsFIj4hW0dN/1Xz7ZXl7UQDuzZzvdLhnYqy3Gu+wKJQaOeG7m9lwLtW2BEjDNTI7CAEL8iPwMKbAdQ66otFwIk3zqNh5uY1iBciFULk7gF2Me3; 5:yUH5ceR3vdjCUsuBH0PWhuZcrZ+4a8pViRjeFfHNv1y381z5DHor/RV3Ibc8W+NA3UO7AbjmogTo+hHV65NG5s14vpf9i/D3fNWAM9Zt6QGfx0b2qIQ4olRJPphTmVCNVNErDMfmWGwaMSJA9joMeuz+J0u7M3IFvbEerKeoJmQ=; 24:m5DImOn5j/yAd1p8tsfkAbHUqYAEANTSBkdZ51wYqWy9cnPrGniDDy4aVrzDp9LJsEcLBwK6cFLqNwwSIUcT3AV0pAr4l/rdP9nnimCuAKY= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3007; 7:Npyj4dKus0S7tJWpyUWXLRcXNwazVO2WWCasn8ZuVBo3HlJTZwa/hsR5saT0qYHbpGiIoT4px5eQmp+mfUUywuEY8whVJqMKzYld8hLWRKI3/cv1XNrb24CSuwhy//JQqd25VyAV+r+bduDAQXx8ar1RCrLc5kLxqYA5tBJfBFmzLwoXfXyaeM6ziWjvTljq+b/fZkyBCqjGeGjKM0qXV7r5vKGvfXWeIkhVkfpkrPH72aZ+0YVQM5TPKVwMOKRkOcbOdjUt1+6xGa4Oo9BOwcNSeBD+R1EF7Jn8181cmrJFtJIy6xI8LFyEHn1GdDQMdOC+5ax7GlM//r98Lb1L+lelJxgriWWQz44WtFIN/uQ= X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Nov 2016 12:52:18.6780 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB3007 Archived-At: Cc: IETF IDR Working Group Subject: Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129 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, 02 Nov 2016 12:52:24 -0000 ----- Original Message ----- From: "Job Snijders" To: "Gert Doering" Cc: "t.petch" ; "IETF IDR Working Group" Sent: Wednesday, November 02, 2016 11:27 AM > On Wed, Nov 02, 2016 at 11:37:46AM +0100, Gert Doering wrote: > > On Wed, Nov 02, 2016 at 10:32:45AM +0000, t.petch wrote: > > > So we have a definition that has been in use for three years, in the > > > context of IANA, which is, to quote, > > > " Specific entries in a registry can be marked as "obsolete" (no longer > > > in use) or "deprecated" (use is not recommended). " > > > > > > I believe that this I-D cannot be understood without reference to that > > > definition, hence my opposition to an I-D that leaves the interpretation > > > of 'deprecated' up to the reader (who may assume that the SMI definition > > > is appropriate). > > > > So what you're saying is "add a link to that reference, and all is good"? > > > > Why is that interfering with draft *adoption*? Sounds more like wordsmithing > > for the then-WG document before WGLC to me, not a fundamental reason to not > > accept the draft. > > No, it appears that Tom is saying that IDR cannot deprecate codepoints > until IETF/IANA have developed a deeper understanding of the word > "deprecate". Job, Gert I think that that may go beyond what I have said. If draft leiba-cotton becomes an RFC soon, then a Normative Reference to that would be my preferred option, so that IDR is on the same page as IANA and the rest of the IETF. Note the leiba-cotton is in state IESG Evaluation AD follow up for 163 days with Pete Resnick holding a DISCUSS and Terry Manderson as AD so it is Pete (or Terry) you need to light a fire under. I did however mention another possibility in my first post, of putting in our own definition so that it is clear what is intended (if only to those wishing to adopt the I-D). Given 20 years of (different) usage in SMI, which some readers will be familiar with, I think we need a definition so include one! We could just lift the existing text from leiba-cotton then, if that does not change between now and whenever leiba-cotton becomes an RFC, we will be in line with them - which is good. I think that IETF/IANA developed all the understanding that is needed of the meaning of 'deprecated' in 2013 and all we have to do now is to use that understanding. Tom Petch > > Tom, can you confirm that in retrospect you would've opposed > https://tools.ietf.org/html/rfc6938 too, and that it is not clear to you > what that RFC accomplishes? > > Tom, do you have an alternative strategy to prevent value 30 from being > assigned as path attribute value to the next early allocation, other > then adopting and publishing draft-snijders-idr-deprecate-30-31-129? > > Kind regards, > > Job From nobody Wed Nov 2 06:03:47 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6061295D5 for ; Wed, 2 Nov 2016 06:03:46 -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, 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 XQX6V1X2AGF1 for ; Wed, 2 Nov 2016 06:03:44 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c: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 C55F6129625 for ; Wed, 2 Nov 2016 06:03:43 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id a197so139455521wmd.0 for ; Wed, 02 Nov 2016 06:03:43 -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=+P553QjvYaGQHfJb1JQljzllhMzgRpWVrXhrIcYHags=; b=XkDNbB7QxsP27SghQuLHifn8+xL0f8RPJLjRI2CxtfZGahb5WK+d2RrUqv7M30trIN 3c5QITJ6kX9lnDWyi83tt+Ac1+T3drpUouy0kJqx5uY1XlESsUsM6HFl2uY8mIwNEOYe +mUaPmkCNxMb57K4w2hcNG3PvQjdws9mlDI4FMo0oH3VrCZdTmOymLVe8xymH+gd60Fs ItJDSC/8PSfOZ1yuW0fis27rvgihpyUmI1RZtUVRYJDoDx8/jzbH9WqEl6hZ+PH1wOL+ I9xVVJflkmtQHkhz8RfwqsYJEfz3zi+HFy1Z4jrXEllHeldlP3ZnDd2rnOoTy8nl4gAf 52HQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=+P553QjvYaGQHfJb1JQljzllhMzgRpWVrXhrIcYHags=; b=aawBiFiSX5ymmSmrSrqSFuW6S61relKXP6Y6pwcrrZueCNlTwVaz8j2Tih1e0SkEz7 g51FuZ3DrlXD7bsXgoTUE9Et320bJAr/eFISNQlYb2HAmHq3CaMeJ/h3G3Skl7h6twlV /jbl2dOySmTHtzW8nJ8+PYQgFyBhi26x1/wHURu56gVRSz+M1YLUIWdpaIDuqKJi6QNX B76CZSTqAq9gNOl3uucvLcqlD7T1rIH5B943iCIdqaKJucskfHb2aHowBRmODOn+vr3b fiU2gVLGbpANPwnU6VqG8JSDd2jSq+Ft3j9paH8Xkh1iwPohwvB9NxRHcgASGA6bbVIt GAjQ== X-Gm-Message-State: ABUngvdFz+T/cLsdxyo0pKEAw64jv88Qrh6Le/0/RqYiOHtNB+z7LVWZ/wNnZp00xEpuhQ== X-Received: by 10.28.150.134 with SMTP id y128mr3149526wmd.6.1478091822151; Wed, 02 Nov 2016 06:03:42 -0700 (PDT) Received: from localhost ([31.161.139.170]) by smtp.gmail.com with ESMTPSA id im3sm2673640wjb.13.2016.11.02.06.03.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Nov 2016 06:03:41 -0700 (PDT) Date: Wed, 2 Nov 2016 14:03:39 +0100 From: Job Snijders To: "t.petch" Message-ID: <20161102130339.GA952@Vurt.local> References: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> <20161101144036.GB10519@pfrc.org> <25D24BDC-5322-4B19-A971-9FDD65C07BF1@juniper.net> <01c101d23467$9c8b0cc0$4001a8c0@gateway.2wire.net> <4070F36C-3D40-4EE8-B6F0-D077DB18875A@juniper.net> <025801d234f4$78232740$4001a8c0@gateway.2wire.net> <20161102103746.GT79185@Space.Net> <20161102112754.GM1581@hanna.meerval.net> <008b01d23507$8f17a3a0$4001a8c0@gateway.2wire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <008b01d23507$8f17a3a0$4001a8c0@gateway.2wire.net> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.1 (2016-10-04) Archived-At: Cc: IETF IDR Working Group Subject: Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129 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, 02 Nov 2016 13:03:46 -0000 On Wed, Nov 02, 2016 at 12:48:34PM +0000, t.petch wrote: > ----- Original Message ----- > From: "Job Snijders" > To: "Gert Doering" > Cc: "t.petch" ; "IETF IDR Working Group" > > Sent: Wednesday, November 02, 2016 11:27 AM > > On Wed, Nov 02, 2016 at 11:37:46AM +0100, Gert Doering wrote: > > > On Wed, Nov 02, 2016 at 10:32:45AM +0000, t.petch wrote: > > > > So we have a definition that has been in use for three years, in > the > > > > context of IANA, which is, to quote, > > > > " Specific entries in a registry can be marked as "obsolete" (no > longer > > > > in use) or "deprecated" (use is not recommended). " > > > > > > > > I believe that this I-D cannot be understood without reference to > that > > > > definition, hence my opposition to an I-D that leaves the > interpretation > > > > of 'deprecated' up to the reader (who may assume that the SMI > definition > > > > is appropriate). > > > > > > So what you're saying is "add a link to that reference, and all is > good"? > > > > > > Why is that interfering with draft *adoption*? Sounds more like > wordsmithing > > > for the then-WG document before WGLC to me, not a fundamental reason > to not > > > accept the draft. > > > > No, it appears that Tom is saying that IDR cannot deprecate codepoints > > until IETF/IANA have developed a deeper understanding of the word > > "deprecate". > > Job, Gert > > I think that that may go beyond what I have said. > > If draft leiba-cotton becomes an RFC soon, then a Normative Reference to > that would be my preferred option, so that IDR is on the same page as > IANA and the rest of the IETF. Note the leiba-cotton is in state IESG > Evaluation AD follow up for 163 days with Pete Resnick holding a DISCUSS > and Terry Manderson as AD so it is Pete (or Terry) you need to light a > fire under. > > I did however mention another possibility in my first post, of putting > in our own definition so that it is clear what is intended (if only to > those wishing to adopt the I-D). Given 20 years of (different) usage in > SMI, which some readers will be familiar with, I think we need a > definition so include one! We could just lift the existing text from > leiba-cotton then, if that does not change between now and whenever > leiba-cotton becomes an RFC, we will be in line with them - which is > good. > > I think that IETF/IANA developed all the understanding that is needed of > the meaning of 'deprecated' in 2013 and all we have to do now is to use > that understanding. Thanks for your feedback, I'll respin the draft into a -02 version based on this discussion and submit it later today. Kind regards, Job From nobody Wed Nov 2 06:47:17 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 310FD12963F for ; Wed, 2 Nov 2016 06:47:16 -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=bskyb.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 6WTga4FMmf5W for ; Wed, 2 Nov 2016 06:47:13 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10043.outbound.protection.outlook.com [40.107.1.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CBB5129658 for ; Wed, 2 Nov 2016 06:47:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=BSkyB.onmicrosoft.com; s=selector1-sky-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=dQ0ogO1cDtDCoWU9js9uo/TJRg1qO64kG/qnn9PhkKo=; b=jeE84nUf0UmZCLJ7VgkGGx3nKoPM/RisWtCKiHG6JyK3iYZP6lmUWx5IiloF6Ld4tAN4zd9s6p2s/4qaP/jNMnCjeWQzZlEV2DLujG6Q7b8DtpSHxp60O+p6+dc110ZzZ5aH4fO4ti9rM/dzIetV+PyYfUTYpDz2CRMSo2/LBjY= Authentication-Results: spf=pass (sender IP is 176.255.244.224) smtp.mailfrom=sky.uk; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=pass action=none header.from=sky.uk; Received-SPF: Pass (protection.outlook.com: domain of sky.uk designates 176.255.244.224 as permitted sender) receiver=protection.outlook.com; client-ip=176.255.244.224; helo=email.bskyb.com; From: "Dickinson, Ian" To: "John G. Scudder" , "idr@ietf.org" Thread-Topic: [Idr] Working group adoption call for draft-gredler-idr-bgp-ls-segment-routing-ext Thread-Index: AQHSM7wX4/8odhTDqEaOaydQxmLDHKDFt6ag Date: Wed, 2 Nov 2016 13:47:09 +0000 Message-ID: <9B3BFE0A18160E40BAF1950414D10FAE617138C6@WPMBX010.bskyb.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [191.255.75.235] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:176.255.244.224; IPV:CAL; SCL:-1; CTRY:GB; EFV:NLI; SFV:NSPM; SFS:(10009020)(6009001)(7916002)(2980300002)(438002)(53754006)(189002)(199003)(13464003)(46406003)(8746002)(8676002)(81156014)(81166006)(69596002)(47776003)(55846006)(9686002)(1941001)(5660300001)(19580395003)(19580405001)(5890100001)(23726003)(76176999)(50986999)(54356999)(87936001)(586003)(107886002)(102836003)(6116002)(3846002)(8936002)(230783001)(189998001)(5001770100001)(11286001)(8666005)(2906002)(2950100002)(106466001)(106116001)(2920100001)(2501003)(7846002)(15975445007)(305945005)(7736002)(66066001)(26826002)(50466002)(33656002)(97756001)(92566002)(74482002)(86362001)(7059030); DIR:OUT; SFP:1101; SCL:1; SRVR:AMXPR07MB149; H:email.bskyb.com; FPR:; SPF:Pass; PTR:b0fff4e0.bb.sky.com; MX:1; A:0; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; AM1FFO11FD012; 1:VATrKv1xncW9WUIV+ZZyL57VrB9TDcq7Uh+LYcB1H1cp1NzpAUy4nzTk4OvTaS1MaPpZVJDHUiEJ2R6NBQQiEi/x/0LIQ+TTfl1RCA35Dhm8LFZS24zdNz8T0sSpAS0uLzDYdqG5++yvM9USKdJ/862gXv7zUMtOc+gxlqlgb0UjoE2peNgGszCrb86BpCZIXTReYXlV8YKCJQNZz4UuXr2ZS2H2IKjvrkf8X8VznkNHHn96DMjesNh+8oW8NswoLxL6hWZ4ZEfaRvVR9t1PP5w2NXRrvpZUM9hg9Rw2fFYOYhlWEB6h8SaTnCH1g45RgtAC949G0uBprPGd4ZmakHW1ONv5YdI+NzQ679crJUKTv4XteLVeMeZ2YBcJqd3RJZ9Wvi/rSn9DepwSXj7kmw1V9Y0epqYVxBouTRTE4fWU70O7WyGTzMS0dGjnrq26Fj63E3HJ8/7Zx9M1x6FuNl9aZ6BD6arYbqxTQNIG9+D5oV8DqFtZAylzLC3d6ThMALEGnThTGGFVK0aDnQD3yXjOGsjaMRrxA2SKXy6GlH2sqkrDaq8wKsXa/sNwb3Vw9KHtqx83d92zgD1mfL/rbw== X-MS-Office365-Filtering-Correlation-Id: 1f995431-bc22-4873-9c33-08d40326bea5 X-Microsoft-Exchange-Diagnostics: 1; AMXPR07MB149; 2:IVOMkwvrSiTtlRMdbdugBRAgrxBenuDUElS/PWDc9rg3hbbbCi55TGMnjnWzwOxnQn5YgAY1Ba0ySf4t8gAzmzGadq3SsNTtzixD5VUPlGiiSEOQWlyT9+GJ7+GUf1L61H57CvMdsShUy65qMOtPIAZk+3nErHOwCMOxBU86polWnkc+I3vkI569RBxaOIVPrdYpbIsPFbjcSeIhpH08Ug==; 3:1GLXq0Zrfp8mzcbPcXD1QaUzWhBPJYAyij8Qda/8Dg5zXtku6dIAx61aAIIhIeY8F3KFNGNb8UXeOlAHQVMOQ/bkq25NPK8qU6ntPkgBGSm76o97S+8K7ipWBNAkMnmMg5NHyUspDc7rka6RfruvsXapIJ4kN/TdN9nrT/fqR6CObEYEv+BA35VXgMPo+m7YW9eciA+/Ad5uSa77IfHIpYIm3XFZ+xfjiEhPtEY4d60Vl0moQRtopfj8guyoez0WQ5bpgzl3aRIH+vug3puQ2TXGQCb688IVW7kt6zU6ENs= X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501002); SRVR:AMXPR07MB149; X-Microsoft-Exchange-Diagnostics: 1; AMXPR07MB149; 25:2JkwI/9iqlrG5bzG+di3/NWQhY+MUW3zEW/OfxP0gttTbvT+rCw1wsImSoT/5w1Epl0VCPgH+TyuhAr3IOL3AVQcNSbevy+U9JgDarzWHLV8Z0+kJVIo0o5xFzjxL4WHtxcpKZ3faCaBTv66lFe/rRh/eOvoA97XK14s0XTLi0tGrWgW7BY9uuPs9DcylYkvoxjwJ4PTfL6N08vfxjS7q3tKahuI8Frw/dR7E6FVVL3uHQLxr6Rgd4fzFIz/76RKmCPRH9rEM2bDEB3SGRLc9Z79ujRPiBYd07jzveIRN/loI5lmeDMSZ/wkyFP39zkL1L6jA7MWl9sYrEbI21agfZNzWzFSvIOemiHFtiwcqp9axJkteuNTvMD7SYpgB5ioW8jaKh2UaV9PnXDRnioFP+swIDDfwp5qKt2mjaaYynUVS17Gt+9qgBXkqYz5Q62W; 31:55tTUcnNCeLMylxGgA+QzeEvfhvTdCZKJXtQweFD4zo/UX7iPDuXGvLVGQWZ5XrgelCJnFJzJcmCLfEbsN3B5cafVCKzsOOpbs/NeTQ5mjL2rM0SRUiSr9D4qkBnytHK2KXZImtsnrBQUOEo1cba3X1rDXvKZrXv3egX4FHfZm5F/rRVdTAsevzFy/UXSmKexKdkYh+nB/PBgeTlHrQGJgjjOmXFue+iTmj+WSVB22Dai4iUcp9pK8bELU0z6SAt X-Microsoft-Exchange-Diagnostics: 1; AMXPR07MB149; 20:jWcHTx5E9syCwiVbYNV32kR968GCOR5IFgULeFzx77efCRASbS37KhI7La96nnKQuIUJuql1HHUzOhO3j+CNAOgXg9BqtDQR1OL6BL+UhO+ZQL0Zwe51MbzGMcaVLYQa4JRmzi267MN2Pf3IAK/xnbPNg50AyJw1f3Qe46Ofka5i95liFYoAGNMQZZ4hxrhi5XNNEOfute0kp37RHvQks3eFDkm3LmoeH7f/k0eAGY1srZbEmxlMhCKkBcOuKpVDSwMP4Ojcs3M1ULKmxWXNJdy7wap6xdUy3VNeTuyTp93twHf608VIGSrio79GxqWOowJLFW7u+kcmQNuw0Kn7b6tRm/h/Mpnqhx/VQejH/eUD7kOoaRWIj7Rfziqz/jyB+4BMe6FzGqMyBjCAih0wATUjQwooLzts5R7x8Gd7Fv69ShcXE08R9iZyk41YTBmZ+IbmmnHbzcYzJ6nDdl6c28DjeH7htilkXJnh7GShHgPPYwOQMFcV7pCzm+ZLbPps X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(13012025)(13020025)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:AMXPR07MB149; BCL:0; PCL:0; RULEID:; SRVR:AMXPR07MB149; X-Microsoft-Exchange-Diagnostics: 1; AMXPR07MB149; 4:mCJvrXRFVJlxnbFUwfl9fEyEy6ek0uIhdmm6ICx60OU/qr0oZG5ERopSw4lvIebLGG1Q+oL0GKEwezkNuPregIEUm7yLn0F30xh3DnOPavNtOzC6x8HWLV7tE9hVaHgi5vqIEWgB+DHlKxg1KMiHHJPH1m2AgjxSWkPQH9KFndHcOpLrqWcpJhuAM3s96BrsrIfMgy1OUpvm6q0YqOeoNgwGBvwILYABnq2EFzTZ1msbhxTv5SLS/yFbsPZGtOFGmNmYLx7hbFSXJZL/E7pYJY0ij401Xlmo08hr8q5Qvnd2Vxtx3Jbok+pK6UBOtC6kAerkTMruhCV6PsoChFX0+MdrDsjTh6cJopU6TeMtGjG0K8Hb1JTmbvH9MkXL8lrgr4+pyTpY7pb6KirBgIhRaGHIsJa82PJwF685HMahzob4eTuAGF2w/zH3gcDUkTm4cjoXpdGji85VO2dwv0Dk6Q== X-Forefront-PRVS: 0114FF88F6 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; AMXPR07MB149; 23:mvsXQk9SwejrseF2LKK9hiISIy39aLAUj259Thz0em?= =?us-ascii?Q?QWyfbm+vy7lA0yL+lUoB5Jwo+7VAT51ocvt5WI19aX+UNi5GAFNONryVA59Z?= =?us-ascii?Q?s7tJT9Bb2BDaQpr2r6gBNSc9sbZ8+ldNhsVDLfi/TUpQ4B3XdgEpXLVWROvC?= =?us-ascii?Q?OIah4dONqGT0lg+k5buAKUwM9aEMVMOmy0+YSu5xw1MWOL9VyTHymzV4m6Z+?= =?us-ascii?Q?hJJwZxxFNPvQl/XQsonQe4LHEkljNms5awmyReufyt1Wdt54jngJmdnRvbVU?= =?us-ascii?Q?FIrf9bppj9Goo5L+FO9rj8Fd74TXrhr/8ithNvQ3AhguR4uOy/x4RTX5TaEc?= =?us-ascii?Q?IWLoLs8JcMbKdYlXWfil6CN4pOjwEbAeWiDB06aVeflsdif8eQL5ZSkOjHDw?= =?us-ascii?Q?AlBM7O0PTeURpdlDJFC4rclmN8phM8r8JYHg57ZPoa9pBZdNMbkzjBa3rBcD?= =?us-ascii?Q?fGT9qgXf96gG1qYBKKeVRjkv70ZiWONQoSVTJsunnAl8CL4Rxt2vHKIZDreb?= =?us-ascii?Q?oVtbA6FPwOmy7yJ80Pi+IWaXmuUt//Jp7Dylk1SyUQH+u+Cvx/B3V3AWsEOp?= =?us-ascii?Q?AhG2l1n/v+4s7nSNAARUT3cIGUyo2fwgNQO35MRj/GqHc4JiC2NoFGLanlfT?= =?us-ascii?Q?Iue/NVnYPqybE98DCNi+3sW66K07Cz9Zh5k5v2VLwTf48KHyn+Bos8skIqyP?= =?us-ascii?Q?RCF+biH308hjBx6U2u58RlCxrP0z4PT7ILMTm99dPZ9wuT9mtz9dDr4KKaDk?= =?us-ascii?Q?fFLvQ6YdQnt4CKJ9YdvzxZ/mEN02XwvhPAOaRjbi/dWi5p6LmJQjj6hs6oRc?= =?us-ascii?Q?M1rbpJNTnJ5O55gJk4/YBuhVNjIkecB6NO9AhiD6IURiubZod6VBNmWNyfe3?= =?us-ascii?Q?bh76fKpRGUqIkffioDAt7GkURvCvpsCtHqv6dHF5oQD7opyXQzpeD36VpiiO?= =?us-ascii?Q?SysMFTAvlqTur5ef/Mt8+kL6lOnWXxyXdc1PvEbU0RdXfj2bBBB0Dsp5/IAd?= =?us-ascii?Q?0MAamjtgeAYJIxNXmMCSiqvC3Z8BrdEY4OA7FdB8uKFh4pEsPt2OO/yxTlov?= =?us-ascii?Q?IzhV3NJjBqPQ/FsgBAFWwezB2l3CH/J4XJM73ZvoEP4SXSTN5rCQ1hIjIvjl?= =?us-ascii?Q?x+mYPqPYFeJAigfBZde51JFElQb/jvuAB7Af0w6sPKjoWquI0i1Xut3UdfWT?= =?us-ascii?Q?HLHZXynV857pwaTLnaCTEBydxXm92RTsl1XoRjEFbmg0lYGlZgpCdnsNoZBX?= =?us-ascii?Q?afU77PIlAXApOdmO5TgS5ZR5DUnMNGEt9olt/LMT8eybfcHagd1AklC/L79l?= =?us-ascii?Q?CAY3jSqKV5ZybYI0b4TnosY7LrIwxGqGrmDXgIN4hqwDZMbVgv2qejtjsMUQ?= =?us-ascii?Q?i5+jAqVZcVduiBFF9UYD89hco=3D?= X-Microsoft-Exchange-Diagnostics: 1; AMXPR07MB149; 6:P8cuUuy6SkBniIy6ce+KK90QkoOAB9JrpfWWIDlV3XKlzNpA58CB9GVvb9c71/7riQZ1GsFWcPevZtMbjH6RRfWgcjDg8+KPeBrJQXHlXkqGgFWP5Nh/47KzlBh1sSBBL0PzASMiM7AOTlvYskMGwgpQtS5srrNSWjmUGYL/S/PDAudGenh8JOoWIToSwoEqxuOtMfvdudxfr1WgMLutwfytTr1q4/heRzwB5iJrBRR/yLcFlwxCxdxi+e+H3nPmZWCS3TwrYU3vhBWKuy4NZwGbq+9Ns0/4w7K1RbS3/DI+qsEfygsLrI+WQxvW2jH3mF5SyFj60Ai+gGqCkxRtJQO3fVrg6FiQjP5zD7Sp8rc=; 5:39+EO2ox77ZNzyIZSI6akhnqbSkqyvOVH8fpo7t+ta1NvwQRprj2wl7M7Pn2NnGoX+s9jFB5M/6a7xrEVIqgnDJKIjGapVgqkcPgTxXqq9ZL5/N0Vt9YNtyNFIuSWaH0wKG9Z5tDI8dtCEzjpW3sNg==; 24:NbDONUwpR23/i2PaqalBfUK33QFCz62EkvJjninduGUMCN3BckW6dVDyt9AyvscQDYjY2EEjlrMxI/9FRMlGqXxbe6aOq8mcpmFPRzdQVpI= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; AMXPR07MB149; 7:jtTAkruJHc1X95/uQ9QFSvCeIq2zEK/ro2IWaCPPE9V2PCJdMl6WwuslDNIyAE8lgVsoqfpvEhhmlqi5T4xzdfP0NLG0fBxkefAurNFKl7ErGIfcvY49SF4v8O8G8cKYZaRf9miEDpleEnTyEvMX7cw0rdH0imIzwwvoHyMNNnJH/aWzaQUPWRy9J2xWvjIx8XORmWes3uRnEU3y+0TTr77c6OjFDpwSpSzl2N9C+VWsm+TfrgVjrW9+G/b6tYwrdQMCLnNwWsosHEGVYQeEOOgTB/2vRPh9pBSiWztfS6IxBAOGLGQOY3xRCEr5op/iKxNrIBR46mF7ZOaYEW7Erc2KfJUSC714aYpMW6Tdc70= X-OriginatorOrg: sky.uk X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Nov 2016 13:47:10.5751 (UTC) X-MS-Exchange-CrossTenant-Id: 4f86cebc-57e2-40a0-86cc-01d73be93ba0 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f86cebc-57e2-40a0-86cc-01d73be93ba0; Ip=[176.255.244.224]; Helo=[email.bskyb.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMXPR07MB149 Archived-At: Subject: Re: [Idr] Working group adoption call for draft-gredler-idr-bgp-ls-segment-routing-ext 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, 02 Nov 2016 13:47:16 -0000 I support adoption of this draft Ian -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of John G. Scudder Sent: 31 October 2016 21:16 To: idr@ietf.org Subject: [Idr] Working group adoption call for draft-gredler-idr-bgp-ls-seg= ment-routing-ext Hi Everyone, The authors have asked (some time ago actually) for the WG to adopt draft-g= redler-idr-bgp-ls-segment-routing-ext. If you support or oppose adoption please reply indicating so. Reasons for y= our position are helpful, as volunteering to review, comment, and/or shephe= rd. The adoption call will end November 13. Thanks, --John P.S.: https://www.ietf.org/id/draft-gredler-idr-bgp-ls-segment-routing-ext-= 04.txt Abstract Segment Routing (SR) allows for a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological sub-paths, called "segments". These segments are advertised by the link-state routing protocols (IS-IS, OSPF and OSPFv3). This draft defines extensions to the BGP Link-state address-family in order to carry segment information via BGP. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr Information in this email including any attachments may be privileged, conf= idential and is intended exclusively for the addressee. The views expressed= may not be official policy, but the personal views of the originator. If y= ou have received it in error, please notify the sender by return e-mail and= delete it from your system. You should not reproduce, distribute, store, r= etransmit, use or disclose its contents to anyone. Please note we reserve t= he right to monitor all e-mail communication through our internal and exter= nal networks. SKY and the SKY marks are trademarks of Sky plc and Sky Inter= national AG and are used under licence. Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Reg= istration No. 2067075) and Sky Subscribers Services Limited (Registration N= o. 2340150) are direct or indirect subsidiaries of Sky plc (Registration No= . 2247735). All of the companies mentioned in this paragraph are incorporat= ed in England and Wales and share the same registered office at Grant Way, = Isleworth, Middlesex TW7 5QD. From nobody Wed Nov 2 06:48:12 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4D2D1294CA for ; Wed, 2 Nov 2016 06:48:10 -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=bskyb.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 DmcgzqolpJN1 for ; Wed, 2 Nov 2016 06:48:09 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40087.outbound.protection.outlook.com [40.107.4.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D94FE129635 for ; Wed, 2 Nov 2016 06:48:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=BSkyB.onmicrosoft.com; s=selector1-sky-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=bjjM/5IXkuoazOdtiac5FP4FelYBugPowQ9jz/IcsAQ=; b=Aebb/AhVUy33dG7j7W52um7rzrWW7z9w/4nvzkhGU0TljmJM9o+6sjMoM5KD2jEtMBnHtNa4tvEGkKYnOH/+5baIW1+E4K0iKYy8xQ2kOwV2a5Wu87TA+pqYDx1962hDQpWQrMgyhwYBJLvyRH8EDnWQm6bUzYmGtRaZz08xUrs= Authentication-Results: spf=pass (sender IP is 176.255.244.223) smtp.mailfrom=sky.uk; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=pass action=none header.from=sky.uk; Received-SPF: Pass (protection.outlook.com: domain of sky.uk designates 176.255.244.223 as permitted sender) receiver=protection.outlook.com; client-ip=176.255.244.223; helo=email.bskyb.com; From: "Dickinson, Ian" To: John G.Scudder , IETF IDR Working Group Thread-Topic: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129 Thread-Index: AQHSM7xyM3+azJJfo0aCoNTFjBme3aDFt+GQ Date: Wed, 2 Nov 2016 13:48:03 +0000 Message-ID: <9B3BFE0A18160E40BAF1950414D10FAE617138DD@WPMBX010.bskyb.com> References: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> In-Reply-To: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [191.255.75.235] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:176.255.244.223; IPV:CAL; SCL:-1; CTRY:GB; EFV:NLI; SFV:NSPM; SFS:(10009020)(6009001)(7916002)(2980300002)(438002)(189002)(76104003)(13464003)(5423002)(53754006)(199003)(92566002)(3846002)(230783001)(5890100001)(586003)(86362001)(2950100002)(305945005)(5660300001)(66066001)(8666005)(23726003)(7736002)(6116002)(102836003)(97756001)(87936001)(7846002)(50986999)(8746002)(69596002)(54356999)(76176999)(81166006)(81156014)(8936002)(33656002)(46406003)(74482002)(2920100001)(15975445007)(50466002)(19580405001)(19580395003)(47776003)(55846006)(106466001)(11286001)(26826002)(189998001)(107886002)(2906002)(5001770100001)(106116001)(1941001)(9686002)(7059030); DIR:OUT; SFP:1101; SCL:1; SRVR:AMSPR07MB230; H:email.bskyb.com; FPR:; SPF:Pass; PTR:b0fff4df.bb.sky.com; MX:1; A:0; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DB3FFO11FD024; 1:zZQdekVSdvuJM6X7jExOL0RQM5x2J6Qk5NcCWapVAEaK7OWQWD9BMk1NndojIFRlTrd6gg1c8Xbbs5QIJ61WPTmhzY/Cia3pI1+y0o80cXMW0pFVU8idzsPTG41QkUuBxfRh4L0982s5o29J67WzmsVRXhmhxsdoh42ypArtPBr60u60/QoD+QZuzQJykMD/aINzuFq63+r+KpuzzBXlLKOb6fFe3EE+UyZqbFlYXpxT16Q6v/Uk9hwOVbRtVHFnU6SKotifDx/wOOYqCevrw7d6up+v2z0J2VeAY/L2I7TzD8bIVA6YntEczLamwaoPXhr7d5yFLf0H5QhMwQqOlr8hZGzSD00geEubS+zvoQmw6dSrTa5lAn9gJqC06yBjdgfrXYYIM9YVoMqtl/6WqOLrFVRoNAfasMSHaKKIhGefULwmYFYDu+m6s/SQOQhFgBkX/wp/SFDLpzd5S6sWi/Z/ZHpEeTaI/+rgLvCqKhR+xo6u+AJmBLccxGJq18rR0uMje1M2xhFNYGjTBPH+xyPq6ZLyE42iq5No1gpuFxzkA6fzfhgcqfvg19jR9uEwzmDb0+8XrSNngck5mFiPvw== X-MS-Office365-Filtering-Correlation-Id: 07defe18-753b-4295-3cce-08d40326deba X-Microsoft-Exchange-Diagnostics: 1; AMSPR07MB230; 2:RTnkTBlDz6yU1LkSyRzUHR3lgtvHJuKu397sWytJcixuUk9hkN5Pbu30o07ASi0kU/qQvf0sJNXGVLPDrBPKpWSilRGpSwGGmFurElimQO5x+BnRkAl5de2jcz/cs3jyACsjLATln+q0na0juQHWv61KxqPspfg+ueGDCMLE0NFjAVfU9jhDELykiVkpSFDbEMIPqFVvXK5vKyb1tieWqg==; 3:do+wmzVtGodNyVpxZz3YegvY/nG+wuZmMqAJpFKV/TYee8Qd5UKeuov/aqx46y8ba3TShlYTJ8XkGwbTPldDmC82vJtGioJ4hlUmTWVlcb5WDdFN8uIlkVD0S0itBTKYtOIA15QBpQjlwIIELhIetR6l+X4sDgrEGwqluCjQNAqhr8kqmERbbW39NRKWkhjjwyWzopChmrNpKQ0geLYclIy32jpqkrPc9/dkND2XZ5vtR8ZX0FgpjKCpFA3yquxN5ccVvEdZmOCSN+5aSnP14T0NSaIoa+vx7QXPRfivKrY= X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501002); SRVR:AMSPR07MB230; X-Microsoft-Exchange-Diagnostics: 1; AMSPR07MB230; 25:WMq1DNnfu8o7bYEmAhO2NzgL82IcuDb4lbR4BYy+fxqGT4e5/g7o95Y+PFT9wZsY0GE8yCxfI6HNZ1ZY75VPTg02lRG9m9l1OaU4t9ATP9NyH4de35FVJ85STGZJXyJNA4ruhlydGoq/yt+9+OoR6aaeeVIzzlLj3HyjWOXXdP9PXbazBH1frQSpZG69vbgJ2dxO5SFMUeZSXzKhC/QfUh6ad5jJVrWJtV/bSxEiIMh3GKCk56Rb+3jFJvhAqvNb0SVZ6Rzzr1YS2kEZhbysANuEGcXL4VNjXkwzp7S0aoI21TVIpfVIsP5MdK/um3VPXUOSRQehhvVtMpZpMUDCOgsFHWcq9IQF67XaR2Y2LT8OiFcSLwX7ECx8VGYVI/fcV6nbeA9jGAzIZzX6Xt15KQHljP0mf6YDcUvf3Vh87bNyitaqizJ1IGlU6HxbfUgt; 31:Bo3uWLNNsMdzTXAESCHMODUnPkEbZJphnrpVnd39ykVvehngbyFR6rh3duaPLmoo0atHOx50LJ6F6H1DGu5Xxffr2BCRaCWmy+4Z/OlzzhEEAaXVBKqvHRlF8Tc7X7tW23wCOL6GSVlVdL7TNQvRDlzlHxh+n5G08Tm0eDBT+ZHARXMXUrq+CbTTbIuLhszmsr4iajdvNE2w8RivhNt3PfseARAWRdCzFO2HAdrhl3gPOuu2lhkfxqBLZ4RMRf2j2O96Dof/utlOVmNk9xYLPw== X-Microsoft-Exchange-Diagnostics: 1; AMSPR07MB230; 20:/+x+qErhg3A2Ncny9YCKDAGVGulrtAI+g4OAFVYKJ3six4m3SdI7iUP88zT3IFT0O3BvKLp+MXC7atC1JtQMjyqZY0rAvHJYWd6XGNVWsH88JV015l2OShKRFAKLwktyHVLt/m+jttFKX/3evwWDo8p27fGIFQI40Wyi0XDRYH1zUNLaomvDNIFP0kBGTF/M7xZWg56zmwNFm3pdsK7LzZyzryOZu+23z0KdInnBq5uyz24FdPFFmOi8BWi/NIsIYHd98RXXVx6vRGinL2WfzdH8Qh7K4k1ezbFRXr6JaNF9Wl3txwNZr7Jew/u+LXwaabHwN2tGZHmQ7wOnibTOZemb0vdC2QyasweDPuUx2h95nyftURsMDQLFFe2C76q7EY/x2es+Za3QrSnNbsa+r9jufJYa8g3gKMIdeS/X4TMrCyKnsJCy10FXj7RhWptgFRdNuacraHKEMjgYXK7yLP5H6Dc4/sb1rhsMT1IT/E3tWzEIwHocp4yobjmqjdtF X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(13020025)(13012025)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:AMSPR07MB230; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB230; X-Microsoft-Exchange-Diagnostics: 1; AMSPR07MB230; 4:bi2pUYc/sTUb/5ao2+MI0+OrxnHvkC1fBVc7UW4+79vnN46HgJtIEbEU3rtX8JPMvV7mVzF8EthltcOdR+TTt6VpBEifz2SNPqQIPb6r6kghvaBi5zxYyueB8oLTEImZl79pVxSkzhze2Z/W2kwwYYsdDqytOJx304ZNkUF3dBOiXTIe6SWP45KLr/g/F1Ga+x/b0C97E5Kc5wJSGojHQbr0jhceu1DDVSsiPyitU0fyu4rA+cU8RaQhnRUFQHz0KJcMEldqP8/ki5iyBVkIm0cJ0r86uBFiQ3TI+fByrMgsqs+mL89j22296Zu7XMmKilmclywj0I10gfSK3ZXYEnaVhA90nMAvJ78+F358zZycXTjP9su1AcoxcA03tSFg9r/yH1VFOLW+2C7KpEfOLlaxoBLsvm0ZjrPtVyT4TZhVftTYfXmn/a0RznFdvEZjv4JUgNuKd91ZUjmJvYvicw== X-Forefront-PRVS: 0114FF88F6 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; AMSPR07MB230; 23:noVi9KA/JJB2U+v79Rl2tt3CVqnX8/4fv02uuOhYbN?= =?us-ascii?Q?wMaoscSPsC8yttetWJJlCrp0aFnD4ahkLsqzviR/L1ZzZMqIr7dLXH7ANy10?= =?us-ascii?Q?ahGJwqjYB59ol0XbzASKg+jWMBBA8cyFgWAEDIhgzjCLeio6tAJTskb/fvrl?= =?us-ascii?Q?w/w/BRYLbV/VRLP7NMIKPxuuOcRg6y2Ng5yKQdhc5FXN5syPk7t7awETBy3S?= =?us-ascii?Q?uExj6VRijm71hWobujJ+eSQGcxtgYb/vKCnhdo4CkyGGzmD39qIJBqC6i72i?= =?us-ascii?Q?6FMgk1gPsLmq4N1eYlA4mEr03VGL09DpmY6epD/rHZ+/8KT3f3X/B/qxlmhn?= =?us-ascii?Q?fGGpB5ayb8Xip5HxLLjtDY90brLitI1Xn5dnZER/L8gXL1LlJGgAZuATqvBX?= =?us-ascii?Q?m0h+rY7cg5IiphzsRL6jOYEfOGnNRKR3jciUi7kVdSIdCFIJmOzGcS2FAJWO?= =?us-ascii?Q?2zVzdEkhq+X+YIikm2bo9fvdsCpQfSCTco1A/0DTlAdhxqQHCCrMp4mUg6fb?= =?us-ascii?Q?2eVxlP19B3Jgx/ySgH+pII2U7+koHZ8UbL8A48I9Yb4CbWrBLAtNeak0Sops?= =?us-ascii?Q?UHu+1iD1ngMj8wZ8A6TQHgjFZMfasN0NDPtdwWESz72nzbcV3iRyJ3uioMh/?= =?us-ascii?Q?9otM5Zt67a/qDqvo6obvP6rdTanl8aG7YbLahuXWeS+OG5+IPlALz/BBAC2Z?= =?us-ascii?Q?ptW9dhy7+vTIncd3lIOXrBLJRlBdIcR/dgIAi/HkNDduPnz1lMix/ZVdR38P?= =?us-ascii?Q?qHK8gS7zmob9653KWdxPxtOP4MZNQCEA2y70wj0yNyrxkxSmL0AoUXXGdc1h?= =?us-ascii?Q?GTPFAC3l6Meeqr38Ad2txZc6bzJ2RIoqLbBsfH/SyV2+GuwI0JYgcvwVQmAc?= =?us-ascii?Q?ecY7PL4um61o8ZMyxfK+3KLERgNU43gsOFKIeSINKSxbgTXrZy//l5RZRySN?= =?us-ascii?Q?LRbLt7/RvVGckVvvGLFyq5Z+78+Wpn7aSW7SkhPfRVueR34xnXw8xTW9PkRS?= =?us-ascii?Q?xTDY3NqKDD+UqV6fUCopFsQsztPOFwD0gaTH2q3qM6sRHu/1u+Iyf33cQAkF?= =?us-ascii?Q?X6nGsJDcI2Ai7qaOdBQzQhlPWoq44Jn4CzYbrPUyLl33rGGUmjj6dl6dauWx?= =?us-ascii?Q?22KuM9PtbW7h8mSXc5TveX1mGH/rL4G4p/EFePu28dJORhVyUxzeu6y7l/hE?= =?us-ascii?Q?HBiIdZRh4C5dBWbl1dL5gyd2GcJsZdUMOZk9BtOE1xwaNRyk+WtzZUKCxWhd?= =?us-ascii?Q?aXkmCu1/FAyBAnhCbvUu5fQk/EU+x5XZOXd2lhBeXBByNQxdx8iky3GTunwM?= =?us-ascii?Q?sBE4fSCUVqlMKWp1p06acmmiyvOZoSgLmHy7vjHu/mhIAosarvgrwgxmFbEu?= =?us-ascii?Q?q2HXGtOdlpMrqPEoxAdVbt2cQ=3D?= X-Microsoft-Exchange-Diagnostics: 1; AMSPR07MB230; 6:xsyfzwaeWW2JEb+wR8UgtP4/drFSdUgIn6BcYdPQWDNPMxAJ2hrVHRkmdSk1p0wwoDVTzgHvKRBsvjXgrcBdL9MMGU2Ij/GUJHgJABHzw3sPzJNGL/fU7rP34c7uOv562bqyfrbRWpZH+LWEM7NiSXASBbXGfqlz2+JH0CqkpHiQFg1m+Zyc/oaAC2z/TXv6Ic2BvePE6h/+mU/wzDdIo4OrSDXp5xY3/O9/uwhyFpICV2N+iRWXRB5A5KAyjV4BLIeBH7vlsMxDcqSNrDdzfvQZTZu0YwOg/ACLw16nUBha22GibS1w+WS8OYjQs3vK7ef1Yes82ykq+rvlFs2QrfOdAc9kWe7DI9UdyaUDQu0=; 5:TbKIkCtWnmEADbbhwxshGeRXwa8SOSYo5lHrywbtqkYXo0LczfjQsDLlPI+32Y8WZC4jWwRBHbFMIWbtsnOtfqUoKQVphemdKdAbLXL6NRJqOyPkwmsFVnxnMUBzGIDbT/B8RydbOgSu0IfKrs1dew==; 24:VcIwcfbWgWHuHj2+KtRsmmjDDeAgUFKKUkOJhfl9fv/22LdHQztvNpJqau/rErHRARJJ0KqE//SKWp8JLP3r+55cupZ4ySV9JbYSDbJvK0Y= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; AMSPR07MB230; 7:nohaxaElF+lzM2hZBSUuo1S1rhVl4Z7mzneSjYit+TDou36wGSpKUwU99U5hs5BnptTrAsOlHegG1z8Io6YKYR2IaVk4tFQPxtJk095WGhtARArt9tqEmcx/oj0hM1mafWfCSs6EqYostpwD3mYsFylcCZbNxknEiVpCyAY5k8ipoUu1YK+gniUIpN+AK0aDtdHKWtVSvZfuUOv2rBWdXZ3jsfYm3wq82EdHsuFT4Gl6vXpQgGSedL8BtyBomhi7YRYCgUflQylp2o33RLWI4/jtmI3vRbeQtqGOc6AYzv7VQ7cvJ1NvKw842PkeJEfZ2y1Gai8Fp6WGrZCgXlbmzhOdE7tHdPxX75JpaeSwVkI= X-OriginatorOrg: sky.uk X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Nov 2016 13:48:04.3974 (UTC) X-MS-Exchange-CrossTenant-Id: 4f86cebc-57e2-40a0-86cc-01d73be93ba0 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f86cebc-57e2-40a0-86cc-01d73be93ba0; Ip=[176.255.244.223]; Helo=[email.bskyb.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB230 Archived-At: Subject: Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129 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, 02 Nov 2016 13:48:11 -0000 I support adoption of this draft Ian -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of John G.Scudder Sent: 31 October 2016 21:19 To: IETF IDR Working Group Subject: [Idr] Working group adoption call for draft-snijders-idr-deprecate= -30-31-129 Hi Everyone, The author has asked for the WG to adopt draft-snijders-idr-deprecate-30-3= 1-129. If you support or oppose adoption please reply indicating so. Reasons for y= our position are helpful, as volunteering to review, comment, and/or shephe= rd. As an aside, I will note that I don't think the WG has the option of do= ing nothing, so if you oppose adoption please address what you think should= be done instead. The adoption call will end November 13. Thanks, --John P.S.: https://tools.ietf.org/html/draft-snijders-idr-deprecate-30-31-129-01 Abstract This document requests IANA to deprecate the following BGP path attributes values: 30, 31 and 129. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr Information in this email including any attachments may be privileged, conf= idential and is intended exclusively for the addressee. The views expressed= may not be official policy, but the personal views of the originator. If y= ou have received it in error, please notify the sender by return e-mail and= delete it from your system. You should not reproduce, distribute, store, r= etransmit, use or disclose its contents to anyone. Please note we reserve t= he right to monitor all e-mail communication through our internal and exter= nal networks. SKY and the SKY marks are trademarks of Sky plc and Sky Inter= national AG and are used under licence. Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Reg= istration No. 2067075) and Sky Subscribers Services Limited (Registration N= o. 2340150) are direct or indirect subsidiaries of Sky plc (Registration No= . 2247735). All of the companies mentioned in this paragraph are incorporat= ed in England and Wales and share the same registered office at Grant Way, = Isleworth, Middlesex TW7 5QD. From nobody Wed Nov 2 06:51:24 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0277A129664 for ; Wed, 2 Nov 2016 06:51:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, 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 I4WEVMkBlymg for ; Wed, 2 Nov 2016 06:51:20 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 887F7129639 for ; Wed, 2 Nov 2016 06:51:20 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id F0DE91E337; Wed, 2 Nov 2016 09:53:52 -0400 (EDT) Date: Wed, 2 Nov 2016 09:53:52 -0400 From: Jeffrey Haas To: "Dongjie (Jimmy)" Message-ID: <20161102135352.GA11431@pfrc.org> References: <20161031205515.GA25507@pfrc.org> <76CD132C3ADEF848BD84D028D243C927935045D8@NKGEML515-MBX.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <76CD132C3ADEF848BD84D028D243C927935045D8@NKGEML515-MBX.china.huawei.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] [internet-drafts@ietf.org: I-D Action: draft-haas-idr-extended-experimental-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: Wed, 02 Nov 2016 13:51:22 -0000 Jie, On Wed, Nov 02, 2016 at 03:20:37AM +0000, Dongjie (Jimmy) wrote: > Thanks for uploading this draft, recently I also had some relevant discussion with people offline. Other protocols such as LDP already provide the mechanism for vendor specific extension, and several features have been developed based on that. Maybe it is the time to discuss whether similar mechanism is also needed in BGP, so I think this draft is quite useful. > > Some quick comments about the current draft: > > 1. In introduction, it describes the consequence of conflicting attribute parsing error according to RFC 4271, while the consequence according to RFC 7606 is less disruptive, it may also be described here, which is either discarding the attribute or treating the update as withdraw. Thanks for the comment. Since I've had a similar comment from others on the list, a little more text here may be appropriate. However, I'm trying to avoid inserting too much of RFC 7606's motivation in here. > 2. In the TLV of Extended Experimental Attribute, several fields are further defined after the "Implementor IANA Private Enterprise Number" field, while many implementers may follow this design under their Private enterprise number, the mechanism chosen in LDP may also be considered, in which the format of data after the Length and vendor-ID field are vendor-dependent. Looking at RFC 5036 section 3.6.1.1, I think there's actually good similarity: - the LDP vendor-type corresponds to the Implementor Feature Code Point Number. LDP restricts this to one 255 values, which is perhaps a bit small. - The LDP vendor-private Vendor ID uses an IEEE namespace. I've chosen to use an IANA Private Enterprise Number for easy entry into this feature. IEEE charges (I believe) for their ID where IANA will give one out to any who ask for free. - The LDP vendor-private field does *not* have a version field. While it is arguable that a given vendor may choose to populate a portion of their internal PDU with versioning information, I believe it is strongly worthwhile to make this part of the PDU. We've seen too many issues in BGP with regard to versioning issues of features in development to not cause the implementor to think about this as a fundamental piece of the feature. - The LDP vendor-private field *does* contain bits related to what to do if the field is not understood (U-bit). Since that behavior causes notifications, I'm not sure it's in the spirit of RFC 7606 for BGP. - The LDP vendor-private F-bit does have somewhat the semantics of a scoping bit as has been discussed somewhat earlier in the thread. > 3. As the Extended Experimental Attribute can contain a series of TLVs, is it possible that TLVs belonging to different vendors, or TLVs of different features are carried in this attribute? If this is the case, further specification about the processing of unrecognized TLVs and the error handling would be needed. There are two intents within the draft: - If you want to use this attribute, you MUST configure something permitting it. - Filtering is strongly encouraged. Currently this draft is tailored toward experiments and development, not long term deployment of features. While the conversation is starting to move toward using this as a generic vendor-specific PA replacement, that's not the intent of the draft currently. -- Jeff From nobody Wed Nov 2 07:13:05 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4C9912956D for ; Wed, 2 Nov 2016 07:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.432 X-Spam-Level: X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_SOFTFAIL=0.665] 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 xymdhucz_f7Y for ; Wed, 2 Nov 2016 07:12:56 -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 8FA651295B3 for ; Wed, 2 Nov 2016 07:12:52 -0700 (PDT) Received: by mail3.mlpsca01.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1c1wHb-0001WR-8a (job@us.ntt.net); Wed, 02 Nov 2016 14:12:52 +0000 Date: Wed, 2 Nov 2016 15:12:48 +0100 From: Job Snijders To: idr@ietf.org Message-ID: <20161102141248.GA961@Vurt.local> References: <20161101144036.GB10519@pfrc.org> <25D24BDC-5322-4B19-A971-9FDD65C07BF1@juniper.net> <01c101d23467$9c8b0cc0$4001a8c0@gateway.2wire.net> <4070F36C-3D40-4EE8-B6F0-D077DB18875A@juniper.net> <025801d234f4$78232740$4001a8c0@gateway.2wire.net> <20161102103746.GT79185@Space.Net> <20161102112754.GM1581@hanna.meerval.net> <008b01d23507$8f17a3a0$4001a8c0@gateway.2wire.net> <20161102130339.GA952@Vurt.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161102130339.GA952@Vurt.local> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.1 (2016-10-04) Archived-At: Subject: Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129 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, 02 Nov 2016 14:13:00 -0000 On Wed, Nov 02, 2016 at 02:03:39PM +0100, Job Snijders wrote: > > If draft leiba-cotton becomes an RFC soon In previous discussion about -large- you said, and I quote: "I proposed 'registry' and 'group' because that is what draft-leiba-cotton-iana-5226bis recommends (one day, perhaps in the coming decade, that I-D will become an RFC but in the meantime, it ^^^^^^^^^^^^^ is the best guidance we have:-)." Despite the smiley, I took the 'decade' part as a serious remark about the document's volatility. > > I think that IETF/IANA developed all the understanding that is > > needed of the meaning of 'deprecated' in 2013 and all we have to do > > now is to use that understanding. > > Thanks for your feedback, I'll respin the draft into a -02 version > based on this discussion and submit it later today. Since we are past IETF Draft submission cutoff date for IETF97 in Seoul, I can't submit the draft. However this would be my proposed -02 version based on the feedback so far received in this thread. https://raw.githubusercontent.com/job/idr-deprecate/master/draft-snijders-idr-deprecate-30-31-129-02.txt Changelog o add 241, 242, 243 codepoints o add "use is not recommended" (copied im verbatim) from informative reference leiba-cotton-iana-5226bis o Change grammatical tense let me know your thoughts. Kind regards, Job From nobody Wed Nov 2 09:22:23 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0219E1296D8 for ; Wed, 2 Nov 2016 09:22:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, 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 qv1hh2P5RsOa for ; Wed, 2 Nov 2016 09:22:21 -0700 (PDT) Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id 355E11296CC for ; Wed, 2 Nov 2016 09:22:21 -0700 (PDT) Received: by guelah.shrubbery.net (Postfix, from userid 7053) id F12F5744AD; Wed, 2 Nov 2016 16:22:20 +0000 (UTC) Date: Wed, 2 Nov 2016 16:22:20 +0000 From: heasley To: Job Snijders Message-ID: <20161102162220.GB92720@shrubbery.net> References: <25D24BDC-5322-4B19-A971-9FDD65C07BF1@juniper.net> <01c101d23467$9c8b0cc0$4001a8c0@gateway.2wire.net> <4070F36C-3D40-4EE8-B6F0-D077DB18875A@juniper.net> <025801d234f4$78232740$4001a8c0@gateway.2wire.net> <20161102103746.GT79185@Space.Net> <20161102112754.GM1581@hanna.meerval.net> <008b01d23507$8f17a3a0$4001a8c0@gateway.2wire.net> <20161102130339.GA952@Vurt.local> <20161102141248.GA961@Vurt.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161102141248.GA961@Vurt.local> X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc X-note: live free, or die! X-homer: i just want to have a beer while i am caring. X-Claimation: an engineer needs a manager like a fish needs a bicycle X-reality: only YOU can put an end to the embarrassment that is Tom Cruise User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Cc: idr@ietf.org Subject: Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129 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, 02 Nov 2016 16:22:22 -0000 Wed, Nov 02, 2016 at 03:12:48PM +0100, Job Snijders: > o add "use is not recommended" (copied im verbatim) from informative > reference leiba-cotton-iana-5226bis I'll bet a beer that IANA writes "deprecated" in the registry :) From nobody Wed Nov 2 10:14:52 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B981C129543; Wed, 2 Nov 2016 10:14:51 -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 DxfJw8NqS6bP; Wed, 2 Nov 2016 10:14:50 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0122.outbound.protection.outlook.com [104.47.32.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFC85129499; Wed, 2 Nov 2016 10:14:49 -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=tZfQRSDCONBSqflgJbRntbiApfzVby7R29Kr+qfaklA=; b=Rj78SAO83YCvfMJ9QGcCjPtiDL7x6HJ4u42J75Yxf0yOnLCk5s7AqIQk371yeGRzjQ+bIL+ROFV1qJm7Dklvf8S5337JAJKYTGxm4Id571/91mVy8DuavakB/cQp1KiP4Lzu2IftoyhbnRSY5JEg49fxD3y4wbz8/QNiv4lXPR0= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; Received: from [172.29.32.86] (66.129.241.14) by SN2PR05MB2511.namprd05.prod.outlook.com (10.166.213.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.679.5; Wed, 2 Nov 2016 17:14:47 +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: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> Date: Wed, 2 Nov 2016 13:14:43 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <8B9FFAF1-DF29-48E9-9011-24CCA5B72FAC@juniper.net> References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> To: IETF IDR WG X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.14] X-ClientProxiedBy: BN6PR03CA0017.namprd03.prod.outlook.com (10.168.230.155) To SN2PR05MB2511.namprd05.prod.outlook.com (10.166.213.20) X-MS-Office365-Filtering-Correlation-Id: 3b4958a2-28c2-4403-a622-08d40343bfe8 X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2511; 2:BxmAg6W7GNgNpBG4vdN/uv4sOaqjOLKKNydi8gDVHCyK4S34SayM+dTX77ynj2ApX7x8fJWn8ObDOD6mIVY3VM8+uY1KQUwH3zaWfmRY4NPv2AjGt2mRkvCxhsEFr9E/kVNUPYBi7DiOWT1gOg+P3tPt/XcFp6RWBklyOe8MOKttQbzy0nhBcsyVIru5qWjgViuMQboR+NPkfr5eH1JHRg==; 3:qqLcLOtlPz+Ru85aLdGJ8DHsU3U0NuVUBiXP2mllzyG/kieXFNuWKCVx469kS5at0esl/2ZporMxhg5zcK2SvrwgLeIgzeGKRVVjF40NdX1QCfD8vMUJrbCjLCt8EUOyVwVR1XaOja2cgR1P6QE72Q== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN2PR05MB2511; X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2511; 25:ZkTxiTzgtxnlyITwl2k1m/sxepnX2vhc8jA7wL/HNpHbkn/jLi0XMyH73bVi3e+X+aMdFDoItYwgrbG9gSw1GK25KH2IvmXlESPcaNU8J2RxB2cOCHXtWNNfbNKwYESsKPsJzjEYVVffY0HwrT6eOlN+Q5UukzCKvChn0wUrla+9Pm4NdZ+nIICSCu6IEwH1FfSH4rO3T+nMoq67f71JgQ9UyAT/PUu8S55FyGbxjbM6DU9SFA+vIVOphuwkFCx87lTd8PxicFKRpm0cVSUQc9qHe7iyyvr1CNj/V2f2Z4QAYKI3yrBdQ60RNf6BCZvKAJSrRAWzk9ZoFyMbsMbEX9LjIR21ZXg8QIlas0/sfe9f7uffAqRFGhCRvNCUWVkBg9z2hMYGT3rMvHdMy/3NTX+18HjJta6T2uwP1KlACxu2v01oah7Nh2tz3bEsVKLhCx/VM5Py29lf2UsqZ84eqFAq7o7DQOIitEdKvtpIo9RT4JIKZR5IGPgdSg4GliycQfe8jDRfp8vMZ3hID7GCI7BnAc0f7ML3SZ0Tx3rvkwYXetBA7hgRpoptZur08woMDciRgWTUftzJX62hrF+CSgWRDjWirOEDHHv4Uev+5hl7MIdSxEy2HZlUVHxwXQBmtl+4pWRuLO1ajqsDqVARhjPWk6edP9wb9DVStdsePM1jBj7o7rs0hQieUGkianKXNWxzIcR4v3YutgqIgjcSXg== X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2511; 31:V+1JVdPz3n2hTO0SCd+gbtBTdn6ZIdj/oVaUzlWyr8nO9mISkLZxfTojSgy2zwINqJkrQ7gv6cuhEJpx0tpvcb1decegGJyMitEG9b1S3EpknU6XZbyzkAC0VAa/QgB3i2CioXRtYNw2fyTPeoDHqWOS0bbyiMMbrNwW8YQsB+xd4q39kcClYy3GQaIkxWa6NPSDLt6zMViFoayPVROJTkL+kJSSiLCSiPyAkPVq238jnbm4xPx0HXzWowbEm16s2sWghIKuhnYGz3pFSwU7Rg==; 20:NjSr2ySd7e1cTEbzoFMakzIM0hNvgk3UUtV+uIGLk0fjfMqkXMiekmQz9qEHAs+FavcUtEwkfyaLeF4FIV/oBkgEL1A+YM3YJbF5achQIuwe9/jFmer8LbnOgzEdYvVGL6lMVwPDU8FdQ7VEtMqXjKjvhlNFIl/xcuoyqYlXJLABspGYNs9beDDiz6T1FVC/dVSGCa+Vjz8mZYXzR+eYZsxISJIRn2K0pQ2livHAF7VpS9NRvCcHj5JzdJEbwee3AFg7YbUX/hOYbJujFOpC3ZRXkjQkM5jyfdbmpaiXFkXJ4YdPp1IOZLeahzFvRPSONssR49CD/dDCaTe4Mm3JORkniwwfJBtTZnl5f57zNkYdLnNbP0M6QW27Cy/JDDS1cIrpdchkJQRwVGm7bzj731YRsXI4bPeZ7IfOlGrtNsstQkm1wgq2RzpdmFVBOVQrjPaau1uLjTRD7sss+zdI6qWmfrgqLCkHmnI1nmCcedFk1kW8oWtOyesUTkFy0EsaWALaR45YKNxvecoZA+0n7U5WwdN0CI0wpWkurH7Nl7MTqYHEu6eFgoTo2p8FtnjeHQeLKppBQZURaI8LnxLlINEx/l8Etksoc5uNfE2qbPE= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(100405760836317); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:SN2PR05MB2511; BCL:0; PCL:0; RULEID:; SRVR:SN2PR05MB2511; X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2511; 4:gzdjULZYObjncJ38ZaAD5GEyygjHipxn+iPjmW81aEk2KhsrriKtp9EwbRvEqeURG75nyaC5eKz8u6otOV9wuHoRUOEXd1dBh3ewNHrsGS+yTUTphqDWB+B0XXtUahezUVTLX5HYIMzPGJLVtWkuBhBbeLZFyF1Y3WECwi96QZAH1PamhVrxZDt84Bb44zTMI8GFT0v5OlsvdgYOUNTGdFBAStAXCLosj3cghSg0tJ/SxpVYwS08uCykw/g1Brv1DCx1OG8kfdeoQXy0V1twwFGGl+aOaKuKgOOTDu9AceOPHRV8toshwa40lRiOeeabpzcqF36NTRyZMRvt67j9LZVkRyH3NoBgIxEzD2FwbGa/xomkRLae3+SbZ6tkDEa5hn6tWR1G97L7s3f7BX0cfSCtspwCku6NTy+1rJgZb/ESe/b/TOevs8NGNIv2TZkuAGcT+sqvAXUsq2Ld5RJquw== X-Forefront-PRVS: 0114FF88F6 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(7916002)(377454003)(5423002)(53754006)(199003)(24454002)(189002)(83716003)(68736007)(3846002)(50986999)(6116002)(2950100002)(6666003)(106356001)(101416001)(4326007)(2906002)(586003)(76176999)(105586002)(33656002)(77096005)(23726003)(50466002)(7736002)(97736004)(7846002)(305945005)(47776003)(46406003)(8676002)(81166006)(81156014)(66066001)(92566002)(50226002)(19580405001)(97756001)(230783001)(189998001)(57306001)(8746002)(82746002)(6916009)(36756003)(42186005)(5660300001)(110136003)(19580395003)(86362001)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR05MB2511; H:[172.29.32.86]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN2PR05MB2511; 23:tMuwqRuKG/IPMUvtFe7BpppzVL/UQ3XKGrTSrOqKR?= =?us-ascii?Q?X6g1R8mnS0d+Cs8U8S+mE1CtV9q+9u/D5R0tCGJ3hDOVyjOtvtzIo7Hoco+2?= =?us-ascii?Q?+0OYUZcpFnIJrLuu1kBOVimwg50HUtGoPKVKsP1fnidvcwFAw7XMIz1xxf6V?= =?us-ascii?Q?dwhEJi/X5FxRxlpBd7uSsYCQPz9nZYkP3SFvokB9DJNDSgsB+UoLpiX5bwYj?= =?us-ascii?Q?25V2z931vjZlYNwZs0rx+nBUTdPNuvA3sSKosslDC2ropnublolzNLS3YetW?= =?us-ascii?Q?X78SdngCEQaWYwm++KMeSSPlHnqCkazQ9808UmLEEykyDuGomI08uwTJQJSH?= =?us-ascii?Q?FoBU39TW5wZa5EIoLuDWqL9FVOOasiS63YGvd32I/3U0NYXaU2+zpRKnhNTr?= =?us-ascii?Q?aPMdNM29sf9BWyGSTycpiRfv3uBxzp0ogcZC75rPh8Sa+n1kPGqaEWxJ4BHO?= =?us-ascii?Q?0Qq4BaVGIiU0l3cNgFbODOEB07bGkdjn1PWOe0zsWRU8K6V+Zwdwgtr0hAp+?= =?us-ascii?Q?2c2K4mDU6BSrInAt4sklepD5Mxk8LPcThhrsjZ6C296JhS9Q0rFkylI9iw6r?= =?us-ascii?Q?wxxseDuCIySzmu0wKNlxgCof2WC9wCZuVgkFvEcgMklexnkImYmTBz0EJPZl?= =?us-ascii?Q?LzdPh5KHKPZ2Ji7c3V4PQXHPYkeHhAB6fmsb/BbXnrGKwUskcIXGIX11WqMX?= =?us-ascii?Q?nE2jcEem2b1+UVmD6kPMhJRhRlVm8z5Svd7DdFzX3MHjh/fM8CfMT21Le9d2?= =?us-ascii?Q?RHImhGrzsvLIUJHHC58Oai9d+LTlt2aaxfTotz9yJE1Vy4TTJ/MOuXSDcUMX?= =?us-ascii?Q?eqOiYpeYn7S/D8veGXeIKnWfJ8bj6eIYcy2+uV5oG6GWdAxe4ipj35AdkyBX?= =?us-ascii?Q?h0RsvmShhIl+krIvJDj9Yf91tNJiCskf4M506gbk1gvIk179K/XWPt7IsKIZ?= =?us-ascii?Q?1cMMYfQM3Bo/T3DxLyFgINDr25cNj5Hu0idjTNXhPd/TVKsIJdZH97LMPZGG?= =?us-ascii?Q?OZl2vojKWcXY9bAFNumuOWgH5ICOoK2OO8awfjLw3u7pLyN6d454YnTl1ugP?= =?us-ascii?Q?zuyfDbUOxq9N+Go1ryxKQF77LnxChYb1F3xAFiaIEYkBWjzHQjRjUtINAWxH?= =?us-ascii?Q?ZbGpBISYeSHAFYIzyJuyPprGuKnG2+1hZb+cJpuzi3vt3MUk3WNWj7dhIPUt?= =?us-ascii?Q?NBHMmnpLzcDh4//PsXjPr43+fivW9lo7c7jc8Mqj9WKFCAepKJeVHtv+MLh1?= =?us-ascii?Q?sPnr1qomvwc9eplgEAAW8//FO69B2iRD3nh5be44p9nE4cMQzFlvieodXlkN?= =?us-ascii?Q?lKy7JH37E6rg7OI1wApEa0=3D?= X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2511; 6:2VlIdMhBrUlhgvO0yhJ7TzyI5fa9dfGPHRzvK2X1v8QXq8WPp5HRoWONiIwa4j0RBzS2GF9kjpilf7GRsZSbYPYLalSnGzkf3dvp3BDmTjf+gFxrRcXUYuvgshrD9KHkh3pz4NpC+Xvzu4sQAG91PF6VkditkRAW4Rai+Ukym2cR0NpeYcs5s8I9r/qLzclFKwUCSLpHYj+xGRPl8OLiW29FZJ4GfMc1ivGZIColHTFoFt25xWjPX6QZmqK9Eco5LCQsICdTXE03xOtU1+c4DJ9nQ294ZtQcr2iCz7ZobjW2LpSVqSOO09h2uwFe36905FQznG34qp58y1nFiYrqHcyGfva/x+l4g7Az10JmOZg=; 5:IL+42tVQAxGeV3sEnuLaBPSg7gEDjy+RnRGUTVnWWkKmR508BYZf4CTiOsWDJi/zWp7U8Z+P7mtCNNh37zpM5wl2+VZ+QPBrhdbToId/k4vH4BSagSxfeJkVJfZVQAcw4vRnqF0N3l6J6wuKNN4mRg==; 24:Lps60e8ktkPmpq7mtOtpAfZx/A2W4+3CdpDX1v2hqHhMRBcMJdi2RLEXOdhqRigGhaEssKMBAZKgrMPaU0bG/r0fOXoC0Se59JRLoelE+QQ= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2511; 7:TEPi0hYi9KJaDLAq1+A9z3mH19GygxCSHH6iqYwrdXeI46fRjkQCCJ7YihNNFbslDq1P7vQbTpkSXnLIIe8eFU1eib0OM4SZ3s3HKqXzyzLsv+JQfAKGRIdyDBkJ+7t94DQndST8ZSoDGvZ+T6itL5fAtAJ3eGkZcAfrfyhvLmOdQgZaeiGb5xPbqPTXd9nQiZOqZ3n7UI/DaEsdPg8d2IZmdB5uYEpVlXTCuvD0/nJQy8/m/akvt5Ssj0CUgXHpUh5nJuaHld2LB1yy+mkB13jqZkudOLeCa4uyb7SshECK1YsdApWLuAkoWWkzSUeIDUsKuz+HHCA7CzDXjxA/QLESMXwlEpJRBslHqx4oCG0= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Nov 2016 17:14:47.7675 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR05MB2511 Archived-At: Cc: draft-ietf-idr-large-community@ietf.org, Susan Hares Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) 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, 02 Nov 2016 17:14:52 -0000 Hi Everybody, The working group last call has ended. We have good, although not = unanimous, consensus that the draft is ready to advance. Accordingly, we = will prepare a shepherd report and forwarded to the IESG. The area where consensus was rough (although still clear) was around the = question of the Global Administrator field. There were concerns that = "SHOULD be an Autonomous System Number" was either too prescriptive, or = not prescriptive enough, and that it should be either a MUST or a MAY. = Various proposals were advanced to resolve this concern, and some of the = text around Global Administrator was improved, however not all = disagreements have been reconciled. We will do our best to make sure the = shepherd report reflects these concerns. Thanks to the authors and the working group for your efforts so far and = in the future as we go through IETF last call and IESG review. --John > On Oct 17, 2016, at 4:27 PM, Susan Hares wrote: >=20 > This begins a 2 week WG LC on draft-ietf-idr-large-community-03.txt. = (10/17 to 10/31). Please comment if = draft-ietf-idr-large-community-03.txt is ready for publication. =20 > =20 > If you have concerns with the text, please be very specific about = what is wrong and what needs to change. If you have concerns about = operational aspects, please give a complete description of the problem = and why this draft does not solve it.=20 > =20 > This WG LC is not a place to debate whether we should have adopted = this technology. =20 > =20 > The focus of WG LC is whether this technology has implementations (see = IDR wiki for examples), and whether these implementation inter-operate. = It is also important to consider deployment issue or problems on = currently. =20 > =20 > Sue Hares and John Scudder=20 From nobody Wed Nov 2 10:43:57 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E487129579 for ; Wed, 2 Nov 2016 10:43:55 -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=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 Rh3LX7OOSM6O for ; Wed, 2 Nov 2016 10:43:51 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50132.outbound.protection.outlook.com [40.107.5.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C42A12956A for ; Wed, 2 Nov 2016 10:43:51 -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=0gKdvqiJxm+c8/0caKftywDybt7/zY8kabGFjh4TbG8=; b=W6AM4CwAp9ab5nvfNks79BUJh7kl7frwrKxKy6YV0cgS5yLIgXsyVfXCpD425ZutzYlLb8jL74SuWMIoEM/ZWW8pXangVPhKpYduikLrYBbnHblOFGuCugreDlkZN/Z89bOuAEpfA41wZyOxXmhrxOw4y40rK29uIxNiXBL/Ruo= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (81.135.210.62) by DB6PR0701MB3000.eurprd07.prod.outlook.com (10.168.84.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.707.1; Wed, 2 Nov 2016 17:43:48 +0000 Message-ID: <020c01d23530$47aba7e0$4001a8c0@gateway.2wire.net> From: t.petch To: heasley , Job Snijders References: <25D24BDC-5322-4B19-A971-9FDD65C07BF1@juniper.net> <01c101d23467$9c8b0cc0$4001a8c0@gateway.2wire.net> <4070F36C-3D40-4EE8-B6F0-D077DB18875A@juniper.net> <025801d234f4$78232740$4001a8c0@gateway.2wire.net> <20161102103746.GT79185@Space.Net> <20161102112754.GM1581@hanna.meerval.net> <008b01d23507$8f17a3a0$4001a8c0@gateway.2wire.net> <20161102130339.GA952@Vurt.local> <20161102141248.GA961@Vurt.local> <20161102162220.GB92720@shrubbery.net> Date: Wed, 2 Nov 2016 17:08:00 +0000 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: [81.135.210.62] X-ClientProxiedBy: AM4PR0101CA0006.eurprd01.prod.exchangelabs.com (10.167.254.16) To DB6PR0701MB3000.eurprd07.prod.outlook.com (10.168.84.138) X-MS-Office365-Filtering-Correlation-Id: 9237d8f2-d93f-4a63-4608-08d40347cd60 X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB3000; 2:gwPpfe6DKNrJuJ50RpCkqSf9u+NtSbauiWOwNgbHfqkR4ytpJdYctyEfVY10uBWpW95OLnTqBl+oZyG8QONZj0/k/Suoe9QPFyzQiHJM1qH4zulZy1Tu8WZEwRjrw/zSKiyEtwp2O6TyboA4W1iLP7jYI8DvBbae5wZEc7vmoughtfvPBTiZ+KfyNu9AbDN3e7X/nKuI0zcG6WAeBF1Qdw==; 3:YjswaylAWGL7LvojqgE7ZhKWgFa8HIiy0IVDUlUqTnV6NMrmWxOA0tsiBN0/Yovj5FQbPEH4K6VwoH6KrbNa3dMaqumQDT6M0n/yju3x+L5ul317SXfv3qlQUuZyN2hvcF/V13zrZeMSlP5wvD013g==; 25:Vo5jLekSNhvlKupE6YsSKl+yGprizRbpfGMgQos/VyRYZht1KMmqyKTBEMlpl5pEj4sCG+U/aszOgz0C3MEYEBwpKZEsSyMj/nSB9ZszjjKbrpS0EwZeQpJyt89vy3rQX1t1oIge667Og699HO4t0NZ7ppO2VOSOvhVKFC9rAHKnxYSxGD+NwaN9RQxEYOjv4jcQQtuS9KK++bAkb9Il88hXLDN+zejg1sKIEbY8ZRzsgr2H3D7094fvCWlLs7nswCkYAORVC+004wlWPY0JLCaw4jCzErtPzs9jqXQubXkmdXyn3i3dkAaSh+AC2zzK5hr7vA34SvSmjIooCUgdzrChSgZf+l7GtTrEeP8tyYmPcZLOHblHG7a8Y8xJgWFZr0k/bZ/16cXvLtFSqpUNZs4poOhGnstT3BkoHNEN/lxUVb0krS9mx426/fD/S16Q X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB6PR0701MB3000; X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB3000; 31:BgUJZ2gtzPZhJviA7HDh0ICkWmsyYIlz5Ohwgo/J8mcDsg87HRAK5MhKumdJkgx7lOF12Ggewle32G7QHbD1UqvlZqW6NrmbZK1XYKG0DoXtxZul5DsrARx2j7jMot2fnKiSaxC9OgJdWJ4wtpI7xTcoIrNIrVshrPQeILMsExf6JKrpSVqv5x6I3YaM/rJZTbmViuwKznnTGG8k1vIP+6De6lPj9c9ljVxn/sliHfj1HG9c7NxglZd2be/mQ53r; 4:cvoPXTotFeyVs3HOCUm+Yj1wxaV/wToeDSuz9V0iy+Lyqx4DCPQRFZR4j0GEERmV9EUxHZDx2GD2INziSSZ5E0CKIC+fH+uU4HC04cWTDXDOu9JyrcZE8lUFothpBczmdJ5qK6s+iHoumGyp1edFlfh0CdABGPe3Ksd+SIAGWVQJ4IEKTeBXFkDZqvKPQl79PXGwxVHK5g1EvRYD5Cc3sCIY682KXM8y9GmBx+wA6Uh0/CJZXYEhoCoJ5HeUWngEZhoPmW2NwbLCOQeca63sO4B0GBx77/IDGFpVlbwMdYM9Nhy8ILpa249FtRch8oGJaUJCgKc0z7PAwiBnYFhY6ynmKJQglSyzlGo3LGZ5kf32+L4AxXeH6KXqGvsFQ5f6/gWKQQT5rdyrsO7KdehYxg== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:DB6PR0701MB3000; BCL:0; PCL:0; RULEID:; SRVR:DB6PR0701MB3000; X-Forefront-PRVS: 0114FF88F6 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(199003)(189002)(5423002)(13464003)(377454003)(61296003)(62236002)(105586002)(5660300001)(586003)(50466002)(42186005)(106356001)(7736002)(81156014)(44736004)(1556002)(81166006)(8676002)(101416001)(76176999)(81686999)(3846002)(6116002)(84392002)(7846002)(50986999)(230783001)(2906002)(14496001)(189998001)(1456003)(4720700003)(86362001)(4326007)(116806002)(81816999)(305945005)(97736004)(6666003)(5001770100001)(93886004)(19580405001)(44716002)(47776003)(92566002)(50226002)(23756003)(77096005)(230700001)(9686002)(68736007)(19580395003)(66066001)(15975445007)(33646002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0701MB3000; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; DB6PR0701MB3000; 23:Dkopjh6P8tFI/rPuy7zSh/Ucg5nDbYQ5LbHZ9?= =?iso-8859-1?Q?k/sjYoZYcjp/OP02c+HzN3Hkrta5gTiEOMJsso2pvbZoGmETgCxv31pDEZ?= =?iso-8859-1?Q?LTHLLN0c1eQsTQrbGcLu8jqgAmUxWiIp4aY3f9uzVBokTjSelGVBkoEj48?= =?iso-8859-1?Q?yZxf9JuhfkSaaL0s/JuESC1WnxNjjjKSbWanDTyDRtJjm5E+WvF8lKjyL/?= =?iso-8859-1?Q?7YKcw8ih5ChRz1uejd7iRvdhfif0uSsUTTdleIEdxNR5Ewci3ZqWfLdIWm?= =?iso-8859-1?Q?19V4wesm28vvRnKSEaa4aQcpNBPFexsCbPsPsx8p+4ZR4tFUFCE9LX0z9x?= =?iso-8859-1?Q?PsCh3DtIUpqhAfXEkDOsRsgFQrm6YK8FoF996ENztv09OnFYTDAEkR7S63?= =?iso-8859-1?Q?9p8z3BY6dmVTB54Cpps9Sgcwh52d3kkgH58gReA0GBiN2s7oqbbfpWeExl?= =?iso-8859-1?Q?347hPj3ypGDm+vuK2e6fEpOAKfmNra1i8tHVyC8yk934c6ZvH82er3CljD?= =?iso-8859-1?Q?X1KSH+seXMHXTtwfl3UiSgkw396LbMpq4fnRilYfNMM0aBBab3cE6oghtK?= =?iso-8859-1?Q?8LyPuFXM47R9BGMmZ/RG0ZRzJ0rq0S1vXZV9M3/e7UM9VJh0YuSjWJZGGC?= =?iso-8859-1?Q?ugfo2RHhks5vk8giSngGGKYi+irmAacc8XH2/qmAUvEVlVHKwqCwMYOrSf?= =?iso-8859-1?Q?yL7uoHYpsqEmhWNcTXsbcK21O857xKHn/u72Xm76GM7mruoMb0W2zrFm/K?= =?iso-8859-1?Q?/9AaqOa+a2fvCMU7v2VBtKnmxHDHvdK2KI3oC6DSHfY9ZSWfBTPFG4/WjH?= =?iso-8859-1?Q?S0eZ+TxpxTMa1LkSkhVR+qgXV0vCoY7RP5z/G9pcp6y9UOWOcUaoWC39/G?= =?iso-8859-1?Q?1+RcVhBOhVtv6dMZueg62+ON/Iq4YUgv3CdOdL9Umo2bknNX06dTMFS3L+?= =?iso-8859-1?Q?b81Q9L5IUdw6vBthOJtSwYPnCAovH92NjsR6YqGrA5bejybRe6DQIUQM9W?= =?iso-8859-1?Q?Ye7MfT2LHd2IgHyJTty+bQDqQLmmL2uwFc/iTS2RWiEJObxLJ6z0lDyp9j?= =?iso-8859-1?Q?AF5JHw4MLp6OV93KK36jMT5nEkeNTySA6pjP9AT2JsEMuNaIBeEtXnz2eV?= =?iso-8859-1?Q?yP32+V32xE+bE/zbVGMB6ECh7JA3H3ZU3o1GlheRqUvw2oA3l+ko99KMHR?= =?iso-8859-1?Q?uEn4H9rafBAAOlNoIVR9C+vvbtZL+zYkvO2JXV+Wi+in1PvuQA70VDUhPS?= =?iso-8859-1?Q?+5njzgA25D1KHy9N7WpEc3IhM//FucLce1hsu9p3FjnD+92fiG/7rtKhXH?= =?iso-8859-1?Q?eysbegxMdsERiUlPDWp8EiWXKUtuqQxlsqLjGCDl3XfIRflwg/h92pSQ2o?= =?iso-8859-1?Q?+M7FGyRTemQlOGGhFFo9qFN0Di+qGFqZ0XwcwSGCYmwPi1Hu18A+EF9LaR?= =?iso-8859-1?Q?yIUGyC9SJpdnLC3GmRniY2996lqfadjfpzwaHRQx/xn2Atij34XOM9QqeN?= =?iso-8859-1?Q?b3qHvv07JGwgBIyRyURpK62zqzB35qefvK6BCIQHE2V?= X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB3000; 6:HlrTMpc1iuHlGt4JABgHCmcYcdFalgHTqniOME91+I4DQvQb8GkNgUV8+TrhRVtqBybmdDo7rdI2LtEvBi6XjBfeBbO6/d05FilVJ1FQn9oKTn+KgUjfxdZdEwwH9V1XFiRHUvWsiOnK7bQD9Dq8CKVs0NkaEEkNIx8Haj+1wp8ucWbnIhwxzGtxO8IDTrPBl/NQqBF6TBD5cmLuQeE58m6RzrfSGv1+VwARqeJmhx8/xDKFdeERkN8GSJ9AvrywIwSerpINN03/bBEmqEf7UBuVG2vnAx6SgV14V+w9vi2X3o7U/oFfxIFWxSm5itE3; 5:0Ms9S0bE0ext72C7yWjOAzvKD9Nbdjmoxjez697VGBRHB41dhmgM6tI7OxUafZUlqmrf2RiwprUO6EpQfpdk9f8QNdZjI/LnqJ3mrQUjD9pxup9/sOf/GLCxNbRkygRGMwzkS9oxDbvwliTDGbtOUw==; 24:NafulugQezaoJTu3+VB4g4ZN61GdpmTMirO7774eE1GatA0ZescT9xM7NG1CueEGKEmMWE20qeUNQ5tVMkBvGCiYp1U9dI+BpJsJslW8d7M= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB3000; 7:AMDcyF+3Db09U79tWJKJ1XgL9LxNVwWO+t7OaT3Ti9SiDs+AC0IG5y2fejx3vT4VR3TOzRKlgeo/RvuV1WDNu8xpzEXZUe/q/QXinYV31Gmdw4zd/rOlbo8iEpF+N4wH0U0X80zPiXWiFOyQtPNiSIY/XWWCcyNMA99r4l1/q+7D9ZgnOSvaO/D5mQcUO7YzwHDdE5PYQ6H6CW6bsSTLdMUURgdovNZ5C/T4AOML71NtZ8FUZi4OZJZ21+KnkZ5HTTZxb7NAdHGCmRHLMxEDmsv9fxt9ePH2baOtFrGZYjH19QtlW7TnxjSGr0F6yn+98p/KzS0yQQTwX8q5y/FxhmmDOOUVHRo4FewBmzIduFg= X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Nov 2016 17:43:48.5899 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB3000 Archived-At: Cc: idr@ietf.org Subject: Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129 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, 02 Nov 2016 17:43:55 -0000 ----- Original Message ----- From: "heasley" To: "Job Snijders" Cc: Sent: Wednesday, November 02, 2016 4:22 PM > Wed, Nov 02, 2016 at 03:12:48PM +0100, Job Snijders: > > o add "use is not recommended" (copied im verbatim) from informative > > reference leiba-cotton-iana-5226bis > > I'll bet a beer that IANA writes "deprecated" in the registry :) A fairly safe bet since it is there already (for 30!). Tom Petch > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Wed Nov 2 13:29:01 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEA9F12989E for ; Wed, 2 Nov 2016 13:28:59 -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, 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] 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 mLcTE2HZ2Jnc for ; Wed, 2 Nov 2016 13:28:57 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0129.outbound.protection.outlook.com [104.47.38.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 7E2821294B0 for ; Wed, 2 Nov 2016 13:28:57 -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=jyIv5/iYRDnx2G1+VDOZIuQJXxRu4CND4a+Z0Z9slE0=; b=dSpIQAhyX0mKUJ74Bf4n33KkZJHO0QI7jZ5zzr3Ws+OLr9RbCEcgk2XBddsFz6pno+pzNlWKEKkoa43U4GPKEq4CHETxm5zT+k34Jib3cech/PDIIJp/XVKivKGBQAb9sRwnuZ3cVSMT01WVgJlN93Ujij1X1HQ9kF4PgMx+TY0= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; Received: from [172.29.32.86] (66.129.241.14) by BN3PR05MB2500.namprd05.prod.outlook.com (10.167.3.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.679.5; Wed, 2 Nov 2016 20:28:41 +0000 From: "John G. Scudder" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <532A9822-2289-49DF-8983-32339EFB66B7@juniper.net> Date: Wed, 2 Nov 2016 16:28:33 -0400 To: MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.14] X-ClientProxiedBy: BN6PR03CA0021.namprd03.prod.outlook.com (10.168.230.159) To BN3PR05MB2500.namprd05.prod.outlook.com (10.167.3.135) X-MS-Office365-Filtering-Correlation-Id: 3d9d9e9d-bea2-4165-6969-08d4035ed61c X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2500; 2:ICPYc85srmgPG6JcvVKjJQ/TJkrm28kfrqPtvGF3dTlkKdYQ4ZdQyLWLbLP5OOzKRGUrwK8JBjd9MxAu2wVseNoaUQJes7B2D7o9KvkAMquintY6QgWqzegYSjXT//975HH7rA+bEYoQmRIovrksfVfvvaYZwhgxH9ic3zdzXVyrI/FPGjzk9xkDIb/j80gIeHXOA+Nz5OtHQPIld6TQfQ==; 3:AXSySBIK7aCMbgPeA86sWkf/ejzr3/CD40g7hwRYpU6M2dFiNBLGI7Kiefwe5WpovGMHV6HSS/+IXfqIAa4LvyURZhAqn9ss3sPIwgz5hNvNfd1YfWSvi7+aPZ5YDoBhHFwZ0DamoniixdpAvXGtJQ== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR05MB2500; X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2500; 25:dhRCZryVAkoVeY1XN/YD2pyj1+c5s5QZccg/nUiapY9VBlrRq88Ku0zs7RYsA/Ke8RykdPfjcAX3AZfACbrTOvpdDIgfiLeywa8h1p6Vr97FjCg68lHRiYSH90SK+B+7LnFdJA+BIhpmsawa9czq2BR97FiSCHxjkaH0XIYpmJg/7Gn0djoneLyUrmDRZc3s1rg/ZXIPFtuwAHGTMNIwaqTwnMqnJ3YRKl35h3bZhhwA/UxKU9QhTfY7trslnDNc7dFzLOQ3L3k1JeMn3dLK0UdSw3J251/mAriIvJCCWZTScuqiXH9oHPB9VJxfJhJWEQpWlgQ65FJGj+H1eETOEaJL0AAQriGBzUx7K7Sme8h6dnRWZGcio/5DLRpMgjjar83vQ5LVzoNyalOgZqJcukhIoTN1lx/fNAlEosnfyIJvnCVH4RLVu6LzRrAQS0JSdgthQSBkkFlTx0CfOAmrfBgE06j2mPMKeYg9A34+mm5/BQt224LEvwO//WlcUuzZuAv7U7wx0Dd8NetRIaEE4Ai3BBx2d8HI17qxMaO9/XESzTJO5mHpUrjMht1mZ7qiVV6QeC3c+K7gguBkgi/pQScWx+kqvkx1JY9KZqxJCuBdEaicU55/jh7UbXFV/WJaAa+jbUj+TtFmMyiVr+wzwaYQ+CUoct5BGUKT3b72QjV99AHsSqElIuLWIN0vjHAvlgbuyHvyzzD0Nm56JyhVNn0ZkXg7c0DI1yWiUzzmtdYFaKrwgD3k+ho2vO1BrsiD9L33Aof+Ziv5dcK3okbwAlOfPM1nIwl2DkfID/3TEFeGhLW9BVGlQZEbDMfjJIzF X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2500; 31:r2SAa7ETk3tVWvnQXCAmIsLzBSx/EeslvaXGmUZusbAYq81JtXgewjxJLHjspyN0pmEytEaL4eAHPQ3paNirNUFXCWwoHrx+nb9I1WrZMZv8pAqweqNS8ddkA47fyp62q+rMoVlcSfdS/dHcbq0gLtDfZc2fMTXKONhNcZe+NBmmbDrIzySQxxjI6dy5Q6DwkuzuGj4CGZK2nvCp1Wr7cWv7UugLG0+Tkc0wMNsnuYtyUoy+q/TK/c90QPRUfcTEqdW2jH+KnSgkw0Z1hXo2bA==; 20:c4eeNBK7qVqUTrey6tHqde/zV+iI8cGzlMv1bR+1Dm0pHEormOE48NtWBoMaYSxdhjDZioHlR927Q/J0BD1UfFBU9Y0VgqVvdsQIxndY35CUkR+x/JSxabpBbDO30AWd2RoioSN5V+ApbAePickjWc/EbfXBStchUh023yGs/mZmkbOR8g5WFZkSFtxcpQj/iq4Rbid7p/0dkypWPRSEuQZx07dt/Z0tEtn8hRZY6/fpqlEaVLimlQxdMUt5qlY964ocp5go9wWxtAggox8HwWAMZDTvJewzHlFJTZbJakz7Ifn2uMXWzHL6vZpv5OViIWGKZynuykrjA5ANE62Sbhbkyegp9fVjLpQxiIvZ4A7G/TTVkPcMnr/tWcdJxlZXffP05bf057cDZ+AY3tZwt3niTujgYBUYRwGblICrmDflrgRteh7ZmdqBKxS2mEElrI/p4mk89QovUeto2IFHOrZtHVHFlhQ4u2z6mIb63nQPpwEG0QoaQBgQRCBlB/pZyXRhizrdFIs44E37pq9NpZdaIXsb+/46gf1eqY3CQEUU6niZjd5SyxsV36iX6HtQa2IUJE3mLV8EYFG8neXzqsfu1/+bFVkhiXiOdgZmdC8= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:BN3PR05MB2500; BCL:0; PCL:0; RULEID:; SRVR:BN3PR05MB2500; X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2500; 4:Pp8Pi6pU/nPcOWduOYtYlALwsKu3cIMNLriMD8k0D1FmSA4BoGDS5L1OnW14XzoaxYaYq7mQKO9YmLhRc+mlu0leY7UFU6qMu9A0l5P5xjEeqmm7co/fkQ+ooM3A0xmVk9n4vr5Wy9BMOW8fNSPwY0HWxg1BiuDTjmVXROV/G6vPL7y4tCO8GX4PSSB/r56j5GzjgUXn1YtOfl2MaA4VlpVtDls5CB32JqEVxvTkT5bAFWWqlmiz1Xfbff4ndqoYAGXOw2DcgiKdc3EitAu4sENCUsNKfoq2ivvc5pMU2MXq1btC1ahp4l9HSQXVvBXkqpRg3fP2Mw1RxHS/B+I8SftGhsN0KbdKkb4eY3UfZOw29H3n+e/6pEeLEkHPgNj5DJNKkHFfq/bjZu3LHmPJg+ISrcfLoQncW1rSVoN0ePI= X-Forefront-PRVS: 0114FF88F6 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(7916002)(199003)(53754006)(189002)(8676002)(81156014)(97756001)(68736007)(101416001)(8746002)(50226002)(82746002)(586003)(92566002)(86362001)(83716003)(23726003)(50466002)(189998001)(33656002)(50986999)(3846002)(6116002)(77096005)(5660300001)(107886002)(42186005)(106356001)(19580395003)(7846002)(7736002)(2351001)(305945005)(229853001)(36756003)(2906002)(57306001)(15975445007)(66066001)(105586002)(97736004)(46406003)(81166006)(6916009)(450100001)(47776003)(110136003)(6666003)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR05MB2500; H:[172.29.32.86]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR05MB2500; 23:OR0u9KrZINweVfyPG5kqZBmqU3RuVZVp0nD144NFA?= =?us-ascii?Q?9kkuLmTbRvTvimXKJVDeZxAJaeXhx8zuocQCwaQOnprOAV/V7nFye5MqZYB1?= =?us-ascii?Q?lVTGwZDvGhJwq7P5W9Ug+8LDDmIqwsLBbGB8npetdouiTCefB3WnS6xgkQNy?= =?us-ascii?Q?Z8H1HsQleLJEW1Hps1YDRBPtVqIFZprEOPUQsevChJXv80/04x4fj0hBEtAV?= =?us-ascii?Q?ORDwiKdFaAj4zKyWo89VVU8114j6IT1DNAciHgSitvzu3dXoPP3GXcsF27y6?= =?us-ascii?Q?gbBxWo93UYkpSDtnldcPPuryD4jnjlzrnW5e4OqHMYVtDNxi7F4z42h/crIJ?= =?us-ascii?Q?woO8o7v26kOd/505FZtXtdmKy7OLPxruLw9quBMQx8RdyHKtzQopfo67651C?= =?us-ascii?Q?epuLmf9cPkLA+KcGMhV6H1FJj7NNGCtHLGjvjHZOOphYsTn4WXz29KEL2V4o?= =?us-ascii?Q?nWL47dTHzU9KdFxPuXuWHnzSers/8uWMDkJQ6MjU1qurMeJBZhZeZLJg1aID?= =?us-ascii?Q?+Edv0gLtBDDs3MHzFRSRQjIcmjy3UsMrK+ki74doIeJFnB+KfVqSqbdgtQcX?= =?us-ascii?Q?FUTzVyrEQEyeiao0qKIdaX2c4EIwleOqiAhN39fc6mnOcoPPkJ9xMmgruwLx?= =?us-ascii?Q?RaTCafNpO6k42o0KvikbVLmFyJTG8IW2sPg2WZzhShQDz3b62m5tMT4UPEWG?= =?us-ascii?Q?HbSCueUZyGi38a8APiO+1AQ4K6+14r5I6vfSk2ecN3C64KXobEKXXAOcC68u?= =?us-ascii?Q?vZIKYwoEqBbWRjtYQ5Ex1S7KkJVnAF+zdiRr6CNpcvKmQPdaoCWdFpGPvOLJ?= =?us-ascii?Q?Azwb7nzEIXMYM4uCWICugMq0Uir/odzklcNWyTtYgzmdUbBVLYxV1nBzO/Bj?= =?us-ascii?Q?WcGC/wE81sUgVs6UMEvpQtU5IFLbn3T5gSBkVVm8FhMkCTrDSW5IZHUwdYfz?= =?us-ascii?Q?5Voy6o3M6WMnbBsdwpCvH9qZb5ymfRnt4AJvEfKlG1puSKuPGtXCQC5TZ+rj?= =?us-ascii?Q?yPGOhoYYvVOmU5wLroNUoimbgwlEiyXz1A+4U29BdPZ3eOPtDjyOL0vp4z7r?= =?us-ascii?Q?2XWUVNlrGLiiIrS0cXhb8ymAryOgTEqn1lmPD8U++JaC5m28ugCV2HyX0vMU?= =?us-ascii?Q?kFU79FKQoff8tLEqjE7IOBK8LV2qlYnRGAjbM+8acXcXJZSa/cHNPXRvLnor?= =?us-ascii?Q?g+EMEZ2JHsO8SZJ5hy/2ITY+MRSz+EkKmVHIfHHYfcZRW8ahK/4yO2opgEFy?= =?us-ascii?Q?dlLy5ouV21O3eawlk0=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2500; 6:CMB7usTheEEtCyMtgq0ubqiT9Zim/mdUU7eelmNP6ob5PZtWficSL3zPObnTj/KDnan4DnIUNbfuSjfRgxBdhc01G6Oy3PzRkjS5k8WVmkHCBAye7YSwTzs9m0Bzg3MOME7T30rm627CXZl6Fo6pbYKWR9vthhhpaGyZtIF8j5nSxrKASiCGrIvorSBtJqDeUvMJWqvhIl19y72ZUe1DwUXro9aWbpdMWdspRhcSQ2D2Eh/AGwJJfJxvnqCH1JvXFZCy3RdIkmG4Y1HVj7vLESbYlDUX1BLaCT0CqOKCV86vJ+oRFgcxrcdlxnzITU4gAWeVdYqDPvyDB7L/mcVOkEM8gNvxjWcaaLuxNU3cTGc=; 5:eAA1soTWMsIPcEZNeJMUUTLt447slu8N1HmVJWaAdsNzSVYEMFfvST1N7mOV7RWUfGKyovg/wY/r55EHpL7gKpIbWwxSAFK8Hy6oGXiIpMt4mLS9m/gX1ileg4kz4dbB2vfaPSuDcTRx448UGBmirQ==; 24:SEJdljfO6xHaSfaCmrp7CGiFGalW+hS4rLRPBTP3tkW+zcszFpAdIXJnHiHRFzArOcZO4Y4BffFSUdYVyuuZfNmcnUmTOau8pGCIgUjzyiI= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2500; 7:PKFhzQZbi2KKH5fdBv+saaYOvlbhmmsW/29S0LWktItKCdN/oNl8iFpgBybrUKw0CbRDwqIABvnWYhTQ+nvBR6gbowRoONX7neAv8O9vjzWH5rSI1fhp4nGtOIksD0f/NQztuZcda9OwbwtueTBxizvq6KU7rSwloP39TVs/GUEVarDdqdhkpegK5fl1s6zFzIeOwF1ml4FNVA/GcJmJaaDAMW16oLu46Ibzyg+glHaCPAScyEVwdoR5M6b4oOW+xXNn04rJ2jO0yftI+LhZbbucb3kXGVcZiBFPTV7oa9TMSHAzAKj0Y7Oj7H0KyI4do/fDv2/aAL2VR2Sh0Uq4UrAo/4MuK29203P1eXkhQ+g= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Nov 2016 20:28:41.8076 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR05MB2500 Archived-At: Subject: [Idr] IETF-97 draft agenda posted 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, 02 Nov 2016 20:29:00 -0000 Hi All, The draft agenda is posted here = https://www.ietf.org/proceedings/97/agenda/agenda-97-idr-00 If you = requested agenda time and don't see yourself there, or if you need to = make a correction, please let the chairs know. If you are a presenter, please read the checklist: = https://trac.tools.ietf.org/wg/idr/trac/wiki/Checklist%20for%20presenting%= 20at%20an%20IDR%20meeting -- especially the last section.=20 Thanks, --John= From nobody Wed Nov 2 13:34:06 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 041DB129958 for ; Wed, 2 Nov 2016 13:34:05 -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, 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] 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 JbI2TUKQAN5u for ; Wed, 2 Nov 2016 13:34:03 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0132.outbound.protection.outlook.com [104.47.33.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22216129453 for ; Wed, 2 Nov 2016 13:34:03 -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=rFe3yPktzxng2mPWG7BJUELsgzwDq89+PJ6W48pdgGI=; b=KXjUyC7cryGOzfd4CIvhsYm/gJc+vZYzJvMevdH5SAyba/BhOe8y81I0AXiVlM8Rpsr1i+B9oelxBuWzirhjm51Lj1OrXmSz+PlIf+WkTsxOC5+iBiDm94I/52UFrbFj8xIVk436cYMAscaqhX/kfhAJTwSUs0onUEV1OeDoyBA= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; Received: from [172.29.32.86] (66.129.241.14) by SN2PR05MB2510.namprd05.prod.outlook.com (10.166.213.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.693.7; Wed, 2 Nov 2016 20:34:01 +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: <532A9822-2289-49DF-8983-32339EFB66B7@juniper.net> Date: Wed, 2 Nov 2016 16:33:54 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <38A1FCFD-0839-4870-8029-E0446B4D8706@juniper.net> References: <532A9822-2289-49DF-8983-32339EFB66B7@juniper.net> To: X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.14] X-ClientProxiedBy: BLUPR0201CA0027.namprd02.prod.outlook.com (10.163.116.37) To SN2PR05MB2510.namprd05.prod.outlook.com (10.166.213.19) X-MS-Office365-Filtering-Correlation-Id: f70d4da0-ee21-4a0c-6f90-08d4035f94bf X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2510; 2:asu0brPylCymt1ZWLbwI5tNIIv5h3Qn4BRiutZmEexmqL5Nd7MDcoKGYmmliyiM2ufRFFHD2stnBdWBaiSYMledFaCGGjiSvgIPtKUPJhgYlIvfMmFjVq2stv+bWDznaoJFhv9rja2iwLfLxhtW3CKpyr1J6nFiwhpAfsaz75YzL8Q7txaEXs4sK8dgEi8oxn8U3bp0ZjivSGhCgDu5/Gw==; 3:+RCXq23Ml62ASlhQ+2kWtm2leVr36i0edmS8ktbiYHxAS1sTpXp1ZZL8nxxdtplQ92OaoALsfHwp8F3sZp1LUm17mu1vO6IFJ1BuVo35n/8diSR7vXLjK9+AQIdxuTTQjnETVu5STqJ55qozkjWUzA==; 25:Y/VMSg+EBxpHr+SlNzkM3xFZ1cT9xQtI9LrRV9QiQ3o8fzHal4i+dlOzUgK8Zlx/TrEjllxYac9hxTAM84o1sEfPuDdvluBEMTxDP6iirYKFruQcuNZA8BIlrfNLFvnthUwO+pWHVP+DlBx5pNSUhCTq/Wn9DLldyAqg4Vwnrd4NG+3d7c00ifKhjMMBdrPd7v7fct0Pca/9D86XbnAdIcmL6ATDU6ZAx/Qv2Q6Drhp0dKaC6ZIxH3VNA4E8YNrOv/OCVgwjnWScfJIE/Q5wLatPWRd9PSrP5ikKzAbnV3GaH3fmui0oUaIJFt6IwILfUan70iZ4sS1iO3BwV23nPlH8MDeU1OuYDy7ryFWfXEeHG//eBrRvx3zdhH3aN89o/71ZQ/eeJhwWj9M61S0W0xv3LIL7Zf1CM9Pq9UwLuMc= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN2PR05MB2510; X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2510; 31:U5Kalmng/SQViKZfKeOsziuCSwr0GR3TVgOl/fT0FgatpKrTxR1Ux/50/jGBjy39nIGvaVWvS+ayHGEAeVRxGSQolKsV3NxUjhgk9lE5NXO5rUGDfYZySmePPEbXBLeQuJ0MYKCyt1fNMHx3MdNpxfK1TctcLwPKFso0Ioni7Bs2C7Je7n3w++thgZtDZZA8kxEGOFzeBAD90aaY9Psrj9YMt3C4bKOT1DQmg0hkMAFpHYQmQ4nvFNO0e8n9Acfm; 20:lNV5ljaw4QCJIxD65fCwKdU6DHJr1wvFeH06qzam8lmQZycgxDYTI+bJSaeI8FwPCy7zHWnTfIEdxJyzYmwFEqeWDoj5ArGXoUS+h8iE/7YhMCtamG1eUubgcOBKt4qRfF/y8ipagU9MVGFs9FOPlFZiIbSq48qPvxvMNi/yHK5vT232I/dmITXcuJhZ/94TI6IOsQwCvMnP2stozNm9rghgVpZXHUjHGSFq4A8d5z3yXpaTKQ7vi+po1VEdCU+wxWh/sRg/sox/k55TvZENV5FFKQCtRjAa6qNWE83E9vRz5KMc9l/+T0IhxU69jeBLcwlhqEGEfCBHkYkUn5RASqlZ3IcotXtoAECjWkDvDYxwe6yCL+It7xL0SihxkxqWRb5XCHOEan8863aFf0j9HU/7LR8wCuJwM7xfFHo4QeyRLYeYKgSZqEeguRUeU3j64X/Bj0uc7EPwXNIeSgUXDHh1ss1HdsHZ3qhpgzT+y19BVE+r9EdPKbEcDuvyJCuhgFgjyqQav0vzexPq42ymdoEjGC9sAmHEGrCBkt+chNaTMll3sBFdnxcJMYf/lSuKELTIPX2LS2YLNZNZNYOr3JqiyOjWsKKpcZhhxAYtIuc= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(138986009662008); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:SN2PR05MB2510; BCL:0; PCL:0; RULEID:; SRVR:SN2PR05MB2510; X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2510; 4:c3rXlV80iZKOMC6smqaK1r1TsSFhtVtB7I7lEa2Xwc/x+LoOsormjZZlwZgzIaHC/Egf4DeSwEkTYtbZdZZiRnF+k6+5Zu7htFty9CMo6Y31DfkedgwoAH04djfstO5CWmRgQJyTOtwIbDl2V4mL+jnfbhjhav6c1mpo9uGnXuINh37VuVJV2JWdamoWHiiOX3A1DaLvoKCtExNwWtxqamefF4gVw2vw/HrDMf/FOLTf9KVRV39CFrJzRU6Oz30RSiUIjstKM0NfMYezbtIs/Fmoz1IlykxTgWXxKrxCIARZgwqGaoLfKQpBq6kziC24T8s3tXjkcnAAV+fwLnqq5K/SJySk1hbrzE0ynW/TMM7fGnx4z91DPJYqDagkgsDki15FG4xQc9chU+XsFSjEPpz+1CjmuXLR0KgkW52XcInkh1C/ZgDBVUGwXWox7DvFYhr5O8tSgIyYQHPTuyg5Og== X-Forefront-PRVS: 0114FF88F6 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(7916002)(189002)(377454003)(199003)(53754006)(24454002)(6666003)(6116002)(3846002)(110136003)(50986999)(42186005)(105586002)(97736004)(2351001)(66066001)(106356001)(2906002)(86362001)(76176999)(36756003)(101416001)(6916009)(81156014)(107886002)(47776003)(97756001)(57306001)(92566002)(5660300001)(50226002)(19580395003)(19580405001)(33656002)(81166006)(7846002)(8746002)(7736002)(8676002)(305945005)(15975445007)(83716003)(77096005)(189998001)(23726003)(46406003)(68736007)(586003)(82746002)(50466002)(450100001)(2950100002)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR05MB2510; H:[172.29.32.86]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN2PR05MB2510; 23:ezZN5fnq1TRKWgqv4S65/+SH5/nd/3t+lYk9k4dTN?= =?us-ascii?Q?vt517PbTit2JClkdkgv8A9wePGo2AdDUYWxm0mWf9Ixt+fK8TEmVWJ68Znh2?= =?us-ascii?Q?Dd0dLk8izVJkhh0+jAIXeVVKGGVmmNB1ZAU7Rl5vyjeMMRcvD4UzUyng+U5g?= =?us-ascii?Q?u0cu4WREfT0fOyjeKpdSI5wtUq5OO1jBgrUTN4nnjpw1waYceLgJQN972WsO?= =?us-ascii?Q?4JP1w1JJYP2kS+WozF03j5puwM9I1nmeqqesE9J5o6RGP+XLd8j+Af6M1vS9?= =?us-ascii?Q?B1LNAG0mPMiQOKekKwfI59xF8j+fWHknkkSI0CvhyaYvjcwFcOfE1zQ1Y9OD?= =?us-ascii?Q?BZWiUnnkZY/NdqFwNGQtp+BYkQlnkHemlG8hg1vVzPTvcmYjP+yltxIAPFc9?= =?us-ascii?Q?dgTHwnJGG7ij3YudQrqD24VS82Q5mhZm1AoBFFua2TMO3q2stHxgm1rpvBq4?= =?us-ascii?Q?LAQHy29tDm3gMJBBO2YlL2zvMqe9pFRH3qXd+QrBzzNkQGVSEOmKw5NduFVn?= =?us-ascii?Q?kwpLENI7KLqiBbr2/s+j45jDmBzQm4NXLj2MeAeBJf6RA2JcuWgYaGt7O3Km?= =?us-ascii?Q?odTM86Sguoo27PbQEIWRWW1QVVxLgXF9YLfc2grcjVRLrUpTrBA+zyNBof/b?= =?us-ascii?Q?8DNWEKzCiMXwAzUT49Dv4MQAMiXQWWrB2fFh77jGufZtKUCIg3C0TJCvmrEo?= =?us-ascii?Q?EmGsJ8d5Giq6T4g6e+9RfwmKzVwuUqoiNxDu9kSVWGjWnW77a+7mAdBBg8Vw?= =?us-ascii?Q?k4ImxKv3b+KP5PhCChqaLSifM04dwGs6F1LBsO/a2Ftpf7ICNLcCaCUwF96X?= =?us-ascii?Q?mBkRYCXnM+MHYMKEiHU4laJ+Xtxa7BURfunJ9QlUNmiflqD9EibL3qC3dad3?= =?us-ascii?Q?6Si5OWDqeafHBAE7lSnx11NmTeHW9EVdFkMEfg/aZ/ZxtBm2+hRxc7o2E0RE?= =?us-ascii?Q?vnDYXdWUeARbR1pBKAd1EUJEwtXRwZMCxF0QeNtuQCMsrlsE2sSrPbUH4fiy?= =?us-ascii?Q?V6+76f3ncyB7cT/jnrey6hSy5dQrfheRePyEwucUMepECahAh7f5Vq9Jwpzp?= =?us-ascii?Q?Y03qjXas5DpC+aa6HzMFvmmqNRv/qdzmCsJHCAWVyrdn8jMGngJWT3itmBGT?= =?us-ascii?Q?tw50vbjCHubDgb5RMXGPeXVsqg8ujQ2IaTiMotXUQG+WdbwEOtNyeJeaHxcu?= =?us-ascii?Q?pxpg9yTqmUQD84fiJYRBY2d0vt4LNFJCvcGmJ7w+XLbELTW9/0e1jHTE5fsr?= =?us-ascii?Q?llocLuwuBR82bIEXrJd4jkG3Q9fWIdy3a+Ji2TH84PbyIVy+WoTPWXQXJ+n3?= =?us-ascii?Q?CgtrUlsKW8k0lUOnipzFAY9OCO2Q3wYNI/uAxSABN2HYY04SOZmQhXKKKbz+?= =?us-ascii?Q?ZhjFg=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2510; 6:edpOcF395DJWEOeMqAwg0q//QLt1GA+RDspLDyNpuuOo1KfdgWwcRyT4k6U+ib4Xs5xceMEw8mG0MyK1wJR4kIMXFRmmgBWbxuzm4hP41Tq8w6wOu/S0gzO/UIpcx72fhJivExZazWzPDBDhGHtZg88/5Okn2B9J0lYkpTDLML4cbaTsrsr0/E9MxV/U6JVQTZW210hlqe3tIyyrM8BqV5TT232klLRhq1q0zGGV3rxZAYm2SQNDYT8on4YUrpFMF/+Zz6+Oh8urFXDtjs3+MWJmflObEaItc4KPIyEDzF0Zij0/vjd5Qg9csfoJ/00C9paBY4VcCgx/GJZI+vAPCmXi3azAG0/XnSbijP9BaR0=; 5:q8qWApklnEtY6Y0s81k9e2kA2A3efuPi3B5q+C0f2uCg4wd4k54tOxdzhfCupJ9BT16atuvE0RUSGZZzXK4Ujt+TYljkhNsIZNWeYI/QVynpoOKh4e+BZkQ1MK7zpSlDaUxr2Rc6SDnaWNq+v35AMA==; 24:5jLfkPl5nYsDFIpTXCU5X2jVTt9WXjdJm+nHavmZytV4IJ7r+0UEJpQqKS/y1j0fZM7I41jcghjYcGKCC3elrar18OOaCk5ZzPRpzIfAv3E= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2510; 7:HkpgM0GDvfoCjjQB51ASDWgPs4eUjDF9aVPp3B6JllmcCrHN/Rt1T45zojgv/6S77XLX0NleKBFS73zNT9iCtJjgPhMB8MnciBoLXgP/IdVmv655Yxh/jSYOZlzabgViA9cYo+ETl5JSBcOViAjH0lMrauY4DPVBGTiV741LayjG0NAN/xUbHUVieoy6nj35nEqg3WKa00xNRx76nDH7M83ZxfeYy3TPQM6Qp39+pIPySW4e78E0ZiKOsbzlfU9iPDTkitnz0jVan4OwDFsK0GGQIJgiXSe3YFZBn8uvATxvR+MESXBIws49UGJEMuh47JW0HvoOjprFC+a8MIFGLammtWrdXWzt2pNKiieAQIM= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Nov 2016 20:34:01.5720 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR05MB2510 Archived-At: Subject: Re: [Idr] IETF-97 draft agenda posted 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, 02 Nov 2016 20:34:05 -0000 Oh, also, if you haven't yet requested agenda time and want to, now = would be a good time! Again, please consult the checklist. We'll = consider further requests up until November 7. --John > On Nov 2, 2016, at 4:28 PM, John G. Scudder wrote: >=20 > Hi All, >=20 > The draft agenda is posted here = https://www.ietf.org/proceedings/97/agenda/agenda-97-idr-00 If you = requested agenda time and don't see yourself there, or if you need to = make a correction, please let the chairs know. >=20 > If you are a presenter, please read the checklist: = https://trac.tools.ietf.org/wg/idr/trac/wiki/Checklist%20for%20presenting%= 20at%20an%20IDR%20meeting -- especially the last section.=20 >=20 > Thanks, >=20 > --John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Thu Nov 3 02:38:39 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C81D129793 for ; Thu, 3 Nov 2016 02:38:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.718 X-Spam-Level: X-Spam-Status: No, score=-5.718 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, RP_MATCHES_RCVD=-1.497, 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 opgyjOS2VQsD for ; Thu, 3 Nov 2016 02:38:35 -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 9E1B1127ABE for ; Thu, 3 Nov 2016 02:38:34 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CZP41490; Thu, 03 Nov 2016 09:38:31 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 3 Nov 2016 09:38:30 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Thu, 3 Nov 2016 17:38:22 +0800 From: "Dongjie (Jimmy)" To: Jeffrey Haas Thread-Topic: [Idr] [internet-drafts@ietf.org: I-D Action: draft-haas-idr-extended-experimental-00.txt] Thread-Index: AQHSM7jIewH/rzAmpkOieaXMd4f3MqDE923ggAA8GwCAAcFjgA== Date: Thu, 3 Nov 2016 09:38:21 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C92793504DDB@NKGEML515-MBX.china.huawei.com> References: <20161031205515.GA25507@pfrc.org> <76CD132C3ADEF848BD84D028D243C927935045D8@NKGEML515-MBX.china.huawei.com> <20161102135352.GA11431@pfrc.org> In-Reply-To: <20161102135352.GA11431@pfrc.org> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.581B0598.0238, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 76d5b2ea2ba801e083fdc5670f46e6ce Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] [internet-drafts@ietf.org: I-D Action: draft-haas-idr-extended-experimental-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: Thu, 03 Nov 2016 09:38:37 -0000 Hi Jeff,=20 > -----Original Message----- > From: Jeffrey Haas [mailto:jhaas@pfrc.org] > Sent: Wednesday, November 02, 2016 9:54 PM > To: Dongjie (Jimmy) > Cc: idr@ietf.org > Subject: Re: [Idr] [internet-drafts@ietf.org: I-D Action: > draft-haas-idr-extended-experimental-00.txt] >=20 > Jie, >=20 > On Wed, Nov 02, 2016 at 03:20:37AM +0000, Dongjie (Jimmy) wrote: > > Thanks for uploading this draft, recently I also had some relevant disc= ussion > with people offline. Other protocols such as LDP already provide the mech= anism > for vendor specific extension, and several features have been developed b= ased > on that. Maybe it is the time to discuss whether similar mechanism is als= o needed > in BGP, so I think this draft is quite useful. > > > > Some quick comments about the current draft: > > > > 1. In introduction, it describes the consequence of conflicting attribu= te parsing > error according to RFC 4271, while the consequence according to RFC 7606 = is less > disruptive, it may also be described here, which is either discarding the= attribute > or treating the update as withdraw. >=20 > Thanks for the comment. Since I've had a similar comment from others on = the > list, a little more text here may be appropriate. However, I'm trying to= avoid > inserting too much of RFC 7606's motivation in here. Understood. As you said, a little more text would be enough. > > > 2. In the TLV of Extended Experimental Attribute, several fields are fu= rther > defined after the "Implementor IANA Private Enterprise Number" field, whi= le > many implementers may follow this design under their Private enterprise > number, the mechanism chosen in LDP may also be considered, in which the > format of data after the Length and vendor-ID field are vendor-dependent. >=20 > Looking at RFC 5036 section 3.6.1.1, I think there's actually good > similarity: > - the LDP vendor-type corresponds to the Implementor Feature Code Point > Number. LDP restricts this to one 255 values, which is perhaps a bit > small. Yes, the type 0x3E00 - 0x3EFF is a reserved range of LDP TLVs for vendor sp= ecific extensions, and the type and Vendor ID field together specify how th= e Data field should be interpreted. At first I thought the type of LDP TLV = is analogous to the type of BGP path attribute, while in implementations it= is used to identify a particular vendor-private feature.=20 > - The LDP vendor-private Vendor ID uses an IEEE namespace. I've chosen t= o > use an IANA Private Enterprise Number for easy entry into this feature. > IEEE charges (I believe) for their ID where IANA will give one out to a= ny > who ask for free. This is fine to me as long as it can identify different vendors. > - The LDP vendor-private field does *not* have a version field. While it= is > arguable that a given vendor may choose to populate a portion of their > internal PDU with versioning information, I believe it is strongly > worthwhile to make this part of the PDU. We've seen too many issues in > BGP with regard to versioning issues of features in development to not > cause the implementor to think about this as a fundamental piece of the > feature. Agree version information can help the troubleshooting of interoperability = issues. > - The LDP vendor-private field *does* contain bits related to what to do = if > the field is not understood (U-bit). Since that behavior causes > notifications, I'm not sure it's in the spirit of RFC 7606 for BGP. > - The LDP vendor-private F-bit does have somewhat the semantics of a scop= ing > bit as has been discussed somewhat earlier in the thread. To my understanding, the optional transitive attribute in BGP is analogous = to an LDP TLV with both U and L bit set, so IMO no further bits are require= d for BGP.=20 >=20 > > 3. As the Extended Experimental Attribute can contain a series of TLVs,= is it > possible that TLVs belonging to different vendors, or TLVs of different f= eatures > are carried in this attribute? If this is the case, further specification= about the > processing of unrecognized TLVs and the error handling would be needed. >=20 > There are two intents within the draft: > - If you want to use this attribute, you MUST configure something permitt= ing it. > - Filtering is strongly encouraged. >=20 > Currently this draft is tailored toward experiments and development, not = long > term deployment of features. While the conversation is starting to move > toward using this as a generic vendor-specific PA replacement, that's not= the > intent of the draft currently. Understood and totally agree to make this part simple at current stage. Whi= le for some experiments in which devices from multiple vendors are involved= , it may be possible that different TLVs are carried in this attribute. Wit= h LDP this is simpler, as different features are carried in different LDP T= LVs and can be processed independently. Of course this can be left for furt= her discussion. Best regards, Jie >=20 > -- Jeff From nobody Thu Nov 3 03:10:31 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65A8712954F for ; Thu, 3 Nov 2016 03:10:27 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 DRHtMWE04ZIa for ; Thu, 3 Nov 2016 03:10:25 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67F22129549 for ; Thu, 3 Nov 2016 03:10:25 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 1DF233B44BE; Thu, 3 Nov 2016 11:10:24 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.62]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 00E6227C086; Thu, 3 Nov 2016 11:10:24 +0100 (CET) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM5E.corporate.adroot.infra.ftgroup ([fe80::2912:bfa5:91d3:bf63%19]) with mapi id 14.03.0319.002; Thu, 3 Nov 2016 11:10:23 +0100 From: To: "John G. Scudder" Thread-Topic: [Idr] early allocation for draft-gredler-idr-bgp-ls-segment-routing-ext Thread-Index: AQHSNGRl/O1HlX2eMk614GzzELIlnqDHCK/g Date: Thu, 3 Nov 2016 10:10:22 +0000 Message-ID: <28698_1478167824_581B0D10_28698_36_1_53C29892C857584299CBF5D05346208A1EC66A61@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.6.17.114517 Archived-At: Cc: IETF IDR Working Group Subject: Re: [Idr] early allocation for draft-gredler-idr-bgp-ls-segment-routing-ext 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, 03 Nov 2016 10:10:27 -0000 Hi John, Sue, I support both WG adoption and early allocation. This is the BGP-LS mapping of information defined in IGP documents which ar= e WG doc for a long time. So it makes sense to me that the BGP-LS document = also becomes an IDR WG doc. Thanks, Regards, --Bruno > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of John G. Scudder > Sent: Tuesday, November 01, 2016 6:21 PM > To: Jeffrey Haas > Cc: IETF IDR Working Group > Subject: [Idr] early allocation for draft-gredler-idr-bgp-ls-segment-rou= ting-ext >=20 > On Nov 1, 2016, at 1:05 PM, Jeffrey Haas wrote: > > there are a number of code point points in this document pertinent to = BGP-LS that need > early allocation. The chairs should consider that as part of adoption wo= rk. >=20 > Yes, thanks for pointing that out. >=20 > Let's please consider that as part of this document adoption request, we= should also > discuss early allocation for the code points listed in Section 4.1 of th= e draft. The registry > policy is "specification required" which follows the same RFC 7120 early= allocation policy > as standards action. As a reminder, the requirements for early allocatio= n can be > summarized as: >=20 > - Stable spec > - Sufficient interest >=20 > We will conclude the early allocation call at the same time as the WG ad= option call, on > November 13. >=20 > Obviously if we DON'T adopt the document we would not pass the "sufficie= nt interest" > bar, but otherwise I (switching to speak now as a WG member) would suppo= rt proceeding > with early allocation. >=20 > Thanks, >=20 > --John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Thu Nov 3 03:38:57 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5423F1294E0 for ; Thu, 3 Nov 2016 03:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 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=-1.497, 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 QGrXmwHFPPIm for ; Thu, 3 Nov 2016 03:38:50 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D370D1294D2 for ; Thu, 3 Nov 2016 03:38:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1996; q=dns/txt; s=iport; t=1478169529; x=1479379129; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=6obqSwHFdcU0wa0+QlMVmIjFnaEvSrU3sAGonmYzleo=; b=mvtYSskz5gHnJHbu3cLSkon6MYsIuzEvFLHHGimPeEyQEigZUxzqp/F3 TPSzqZlS4JjqqyT0mJ8ikY4kjFmTfAGHvw/SeWvK17SnwAozzvlkyERRe vZ/IjLtqqCY53aiC2b99TA4xgRtElljat0r8sU1fWhiI0JT9CYfwdrGN7 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAQDnEhtY/4gNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzABAQEBAR9YfAeNMJZ/lEeCCB0NhXgCGoIJPxQBAgEBAQEBAQF?= =?us-ascii?q?iKIRhAQEBAwEBAQEaBhE6CwULAgEIGAICJgICAiULFRACBA4FiE4IDq1HjQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEXBYEJhTaBfQiCUIRHgwQtgi8FmiABiT2Gf4F?= =?us-ascii?q?uhG+JLY0dhAMBHjdrg1qBRXIBhm2BDAEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,438,1473120000"; d="scan'208";a="342195769" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Nov 2016 10:38:49 +0000 Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id uA3AcmkK008784 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 3 Nov 2016 10:38:48 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, 3 Nov 2016 06:38:47 -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, 3 Nov 2016 06:38:48 -0400 From: "Stefano Previdi (sprevidi)" To: "John G. Scudder" Thread-Topic: [Idr] Working group adoption call for draft-gredler-idr-bgp-ls-segment-routing-ext Thread-Index: AQHSNb51aLtVLRwzQEW0V6I0YlFd2Q== Date: Thu, 3 Nov 2016 10:38:48 +0000 Message-ID: <8F949488-CFC4-4140-9264-834AB0B64265@cisco.com> References: 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.90.11] Content-Type: text/plain; charset="utf-8" Content-ID: <00CDDF5295EE7C47ADD6ED584E438762@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] Working group adoption call for draft-gredler-idr-bgp-ls-segment-routing-ext 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, 03 Nov 2016 10:38:55 -0000 YXMgY28tYXV0aG9yOg0KDQouIEkgc3VwcG9ydCB0aGUgYWRvcHRpb24gb2YgdGhpcyBkb2N1bWVu dCBhcyBXRyBpdGVtIGJlY2F1c2UgDQogIGl0IGRlc2NyaWJlcyBhIHVzZWZ1bCBCR1AtTFMgZXh0 ZW5zaW9uLCBhbHJlYWR5IHJlZmxlY3RlZCBpbg0KICBtdWx0aXBsZSBpbXBsZW1lbnRhdGlvbnMs IGFuZCBhbHNvIGl0IGRlZmluZXMgYSBzdWJzdGFudGlhbCANCiAgYW1vdW50IG9mIGNvZGVwb2lu dHMgdGhhdCByZXF1aXJlIElBTkEgYWxsb2NhdGlvbi4NCg0KLiBJ4oCZbSBub3QgYXdhcmUgb2Yg YW55IElQUiByZWxhdGVkIHRvIHRoaXMgZG9jdW1lbnQuDQoNClRoYW5rcy4NCnMuDQoNCg0KDQoN Cj4gT24gT2N0IDMxLCAyMDE2LCBhdCAxMDoxNiBQTSwgSm9obiBHLiBTY3VkZGVyIDxqZ3NAanVu aXBlci5uZXQ+IHdyb3RlOg0KPiANCj4gSGkgRXZlcnlvbmUsDQo+IA0KPiBUaGUgYXV0aG9ycyBo YXZlIGFza2VkIChzb21lIHRpbWUgYWdvIGFjdHVhbGx5KSBmb3IgdGhlIFdHIHRvIGFkb3B0IGRy YWZ0LWdyZWRsZXItaWRyLWJncC1scy1zZWdtZW50LXJvdXRpbmctZXh0LiANCj4gDQo+IElmIHlv dSBzdXBwb3J0IG9yIG9wcG9zZSBhZG9wdGlvbiBwbGVhc2UgcmVwbHkgaW5kaWNhdGluZyBzby4g UmVhc29ucyBmb3IgeW91ciBwb3NpdGlvbiBhcmUgaGVscGZ1bCwgYXMgdm9sdW50ZWVyaW5nIHRv IHJldmlldywgY29tbWVudCwgYW5kL29yIHNoZXBoZXJkLg0KPiANCj4gVGhlIGFkb3B0aW9uIGNh bGwgd2lsbCBlbmQgTm92ZW1iZXIgMTMuDQo+IA0KPiBUaGFua3MsDQo+IA0KPiAtLUpvaG4NCj4g DQo+IFAuUy46IGh0dHBzOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWdyZWRsZXItaWRyLWJncC1s cy1zZWdtZW50LXJvdXRpbmctZXh0LTA0LnR4dA0KPiANCj4gQWJzdHJhY3QNCj4gDQo+ICAgU2Vn bWVudCBSb3V0aW5nIChTUikgYWxsb3dzIGZvciBhIGZsZXhpYmxlIGRlZmluaXRpb24gb2YgZW5k LXRvLWVuZA0KPiAgIHBhdGhzIHdpdGhpbiBJR1AgdG9wb2xvZ2llcyBieSBlbmNvZGluZyBwYXRo cyBhcyBzZXF1ZW5jZXMgb2YNCj4gICB0b3BvbG9naWNhbCBzdWItcGF0aHMsIGNhbGxlZCAic2Vn bWVudHMiLiAgVGhlc2Ugc2VnbWVudHMgYXJlDQo+ICAgYWR2ZXJ0aXNlZCBieSB0aGUgbGluay1z dGF0ZSByb3V0aW5nIHByb3RvY29scyAoSVMtSVMsIE9TUEYgYW5kDQo+ICAgT1NQRnYzKS4NCj4g DQo+ICAgVGhpcyBkcmFmdCBkZWZpbmVzIGV4dGVuc2lvbnMgdG8gdGhlIEJHUCBMaW5rLXN0YXRl IGFkZHJlc3MtZmFtaWx5IGluDQo+ICAgb3JkZXIgdG8gY2Fycnkgc2VnbWVudCBpbmZvcm1hdGlv biB2aWEgQkdQLg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiBJZHIgbWFpbGluZyBsaXN0DQo+IElkckBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkcg0KDQo= From nobody Thu Nov 3 12:30:44 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C298B129675 for ; Thu, 3 Nov 2016 12:30: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 xJyftUKbq9br for ; Thu, 3 Nov 2016 12:30:40 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0114.outbound.protection.outlook.com [104.47.33.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 9D4C6129662 for ; Thu, 3 Nov 2016 12:30:40 -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=mCoKlkIho7qn/b6+wLYmHBt5gYV+LgRQpGVk3zatw+Q=; b=eeDd4DDmbiftZAgPWAgtmtp/WMSvVR8skkTicV8N3FsByI3tcfp66q+b6QBwzENL1GBQvzNwlQ1SY0KeWx4eWoukK3vC+Wi9jAXcOnUq5zlVTDGx0WJatNkkDJx2mlsL3BStZhMxY0Ozi3gUFGygmIGwrejN38MEWoDONjE6ZWo= Received: from CO2PR05MB2503.namprd05.prod.outlook.com (10.166.95.149) by CO2PR05MB2502.namprd05.prod.outlook.com (10.166.95.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.5; Thu, 3 Nov 2016 19:30:36 +0000 Received: from CO2PR05MB2503.namprd05.prod.outlook.com ([10.166.95.149]) by CO2PR05MB2503.namprd05.prod.outlook.com ([10.166.95.149]) with mapi id 15.01.0669.024; Thu, 3 Nov 2016 19:30:37 +0000 From: John Scudder To: Jeffrey Haas Thread-Topic: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129 Thread-Index: AQHSNgjAtQ/NyXCnu0y46j1UopLXbQ== Date: Thu, 3 Nov 2016 19:30:37 +0000 Message-ID: <933291FA-3494-4E2B-8AF8-C367225E9890@juniper.net> References: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> <20161101144036.GB10519@pfrc.org> <25D24BDC-5322-4B19-A971-9FDD65C07BF1@juniper.net> In-Reply-To: <25D24BDC-5322-4B19-A971-9FDD65C07BF1@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [75.151.14.9] x-ms-office365-filtering-correlation-id: 913cea4a-9399-4277-513f-08d4041fe37e x-microsoft-exchange-diagnostics: 1; CO2PR05MB2502; 7:3bgBouK09Htacnf3ZYQvETK2zgczkSEUBUWl0mKPwmYb60nJlSHegQAb/7m5U7teXveFyOYDtoOs0n1eEWLJ5ua9ynOafwEKlyxmAbWS5h1WGnhQYCBB/brXxjGusmTOY3gSrJFno8MK/BAEgCz25CyfdV/YwQVeNjO24yy5nP3EpWFyRqc9KMuWTdSpaewcEu4+jO0ufh/sbihXt7JyZ0TulSI3wmJUpfFsSzWSufCCbd5tSVHCqbaZGy7Po9d1/p01cjw57/gFkcnANAQObycWwoLOdkHLvIcsD872JamjPAzfiI7iuNJEDxCYJnLxudbHhzhanvVL+cPAnP7ye4vE1P9/rOgy/oOFDkanhj4= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR05MB2502; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:CO2PR05MB2502; BCL:0; PCL:0; RULEID:; SRVR:CO2PR05MB2502; x-forefront-prvs: 011579F31F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(24454002)(189002)(5423002)(377454003)(199003)(83716003)(6116002)(7736002)(3846002)(33656002)(36756003)(122556002)(106116001)(87936001)(105586002)(2900100001)(19580395003)(81156014)(19580405001)(101416001)(54356999)(76176999)(586003)(93886004)(106356001)(50986999)(102836003)(99286002)(8676002)(305945005)(3660700001)(7846002)(6916009)(110136003)(189998001)(81166006)(68736007)(10400500002)(3280700002)(97736004)(92566002)(77096005)(5660300001)(230783001)(5002640100001)(86362001)(4326007)(66066001)(2950100002)(2906002)(8936002)(82746002)(42262002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB2502; H:CO2PR05MB2503.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: <01491634D8E36E4882287BA5B95B83AB@junipernetworks.onmicrosoft.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Nov 2016 19:30:37.2345 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB2502 Archived-At: Cc: IETF IDR Working Group Subject: Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129 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, 03 Nov 2016 19:30:43 -0000 On Nov 1, 2016, at 12:20 PM, John G. Scudder wrote: > Update: Michelle @ IANA confirms that they do require RFC for deprecation= from a Standards Action registry but agrees there is no documentation of t= his requirement specific to deprecation, they've just inferred it from the = requirement to assign one. She says she'll bring it up on the Thursday IESG= telechat. Concluding update: Michelle says IESG confirmed the RFC requirement; she wi= ll update 5226bis to reflect. --John From nobody Thu Nov 3 14:28:25 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9D261294A2 for ; Thu, 3 Nov 2016 14:28:22 -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 Z9yDH3frm96y for ; Thu, 3 Nov 2016 14:28:21 -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 4155C12944A for ; Thu, 3 Nov 2016 14:28:21 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.174.111; From: "Susan Hares" To: "'John G. Scudder'" , "'Job Snijders'" References: <147750904648.2927.9899493365277493754.idtracker@ietfa.amsl.com> <20161026191854.GD37101@Vurt.local> <011701d23045$f59009e0$4001a8c0@gateway.2wire.net> <20161027114418.GT37101@Vurt.local> <95B70AF0-0782-4FBF-BCBC-D50889F56148@juniper.net> In-Reply-To: <95B70AF0-0782-4FBF-BCBC-D50889F56148@juniper.net> Date: Thu, 3 Nov 2016 17:26:00 -0400 Message-ID: <001201d23618$e0703250$a15096f0$@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: AQJEuwgqj8VOoCCba8Q5h07kthHjZAI9zeuAAfzuxjQBlqda0gJAANTxn6Iv99A= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-05.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, 03 Nov 2016 21:28:23 -0000 Job: It is my experience that the IESG reviews any document that has more than 5 authors carefully to see if the 5 authors have been actively editing the document. It often adds a 2 week additional review time period while the IESG discusses an exception to your rule. You can choose fast or exceptions to author lists - but not usually both. Sue -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of John G. Scudder Sent: Thursday, October 27, 2016 11:31 AM To: Job Snijders Cc: idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-05.txt On Oct 27, 2016, at 7:44 AM, Job Snijders wrote: > it will be > something between the RFC Editor and the Authors of this draft. Actually between the IESG and the authors, see RFC 7322 and related IESG statement (https://trac.tools.ietf.org/group/iesg/trac/wiki/FrontPageAuthors). --John _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From nobody Thu Nov 3 15:23:52 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F893129453 for ; Thu, 3 Nov 2016 15:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.017 X-Spam-Level: X-Spam-Status: No, score=-16.017 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=-1.497, 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 ZzTOCEfKGgbS for ; Thu, 3 Nov 2016 15:23:49 -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 2D517129451 for ; Thu, 3 Nov 2016 15:23:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3801; q=dns/txt; s=iport; t=1478211829; x=1479421429; h=from:to:subject:date:message-id:mime-version; bh=hu/tXINcITWW5EGoZonnqGvOjcDFx6uzOC32s5ALmZE=; b=OFDmtYnUq3zS1hecfikipsr+xucST2F0IRqZduNaNb/xm+71Q+IEdFUR Ykggt128CVNeCcTHVDYu6dLU+A2nYkQ0RK8bNIHxl3TNxrJB0wql6W8U7 pUnQGQIghTt9qoxCjlJ2apKm7Qv0N87vPCZL1zs/CGlS/92TyPxSUTLHK c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DbAQBtuBtY/40NJK1dGwEBAQMBAQEJA?= =?us-ascii?q?QEBgnM9AQEBAQEfWIEDjTCmL4UYggiIKz8UAQIBAQEBAQEBYh0LhGgtXgEMdCY?= =?us-ascii?q?BBBsMiEKfHJ0GAQEBAQYBAQEBAQEhhj+OfAWUQoVeAZA1kBGRIAEeN2uFH4dgg?= =?us-ascii?q?QwBAQE?= X-IronPort-AV: E=Sophos;i="5.31,440,1473120000"; d="scan'208,217";a="169445613" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Nov 2016 22:23:48 +0000 Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id uA3MNm7Z018252 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 3 Nov 2016 22:23:48 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 3 Nov 2016 17:23:47 -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; Thu, 3 Nov 2016 17:23:47 -0500 From: "Jakob Heitz (jheitz)" To: "idr@ietf.org" Thread-Topic: draft-ietf-idr-large-community interop in Seoul Thread-Index: AdI2H3G9LycaZPBmTxquzpQ++NbqIg== Date: Thu, 3 Nov 2016 22:23:47 +0000 Message-ID: <53e16736622942648a8fceac1ea337a7@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: [10.154.161.7] Content-Type: multipart/alternative; boundary="_000_53e16736622942648a8fceac1ea337a7XCHALN014ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [Idr] draft-ietf-idr-large-community interop in Seoul 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, 03 Nov 2016 22:23:51 -0000 --_000_53e16736622942648a8fceac1ea337a7XCHALN014ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I will bring an IOS-XR implementation of large communities on my laptop to = Seoul. I will have an ethernet switch. I'm ready to interop test with anyone who wants to bring an implementation. Let me know if you want to interop. Thanks, Jakob. --_000_53e16736622942648a8fceac1ea337a7XCHALN014ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I will bring an IOS-XR implementation of lar= ge communities on my laptop to Seoul.

I will have an ethernet switch.

I'm ready to interop test with anyone who wa= nts to bring an implementation.

Let me know if you want to interop.

 

Thanks,

Jakob.

 

--_000_53e16736622942648a8fceac1ea337a7XCHALN014ciscocom_-- From nobody Thu Nov 3 17:14:39 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AFF01299AD for ; Thu, 3 Nov 2016 17:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.398 X-Spam-Level: X-Spam-Status: No, score=-108.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 mJAtM70IW5XJ for ; Thu, 3 Nov 2016 17:14:34 -0700 (PDT) Received: from nx-mailgw.apnic.net (nx-mailgw.apnic.net [IPv6:2001:dd8:9:801::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20C381299AB for ; Thu, 3 Nov 2016 17:14:33 -0700 (PDT) Received: from nxmda2.org.apnic.net (unknown [2001:dd8:9:2::101:249]) by nx-mailgw.apnic.net (Halon) with ESMTPS id a684b2c3-a223-11e6-b23e-005056b685e3; Fri, 04 Nov 2016 10:14:28 +1000 (AEST) Received: from [202.158.221.23] (203.119.101.249) by NXMDA2.org.apnic.net (203.119.107.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 4 Nov 2016 10:14:12 +1000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Geoff Huston In-Reply-To: <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com> Date: Fri, 4 Nov 2016 11:14:29 +1100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com> <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com> To: IETF IDR WG X-Mailer: Apple Mail (2.3251) Archived-At: Cc: rtg-dir@ietf.org, Susan Hares Subject: [Idr] Review of draft-ietf-large-community-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: Fri, 04 Nov 2016 00:14:37 -0000 I have reviewed this draft and have the following 9 suggestions. All of these fall into the category of minor suggestions. I do not believe that there is may major structural deficiency in this specification, and the document is largely ready, in my view. Here are my specific suggestions. 1. ---------------- Title: Large BGP Communities to be consistent with previous attribute specifications, how about "BGP Large Communities Attribute" i.e. switch the order of "Large BGP" to "BGP Large" to be consistent = with earlier BGP Extended Communities specification in RFC4360 2. ---------------- "Network operators=20 attach BGP communities to routes to identify intrinsic properties of these routes." I don't think community attributes are an intrinsic property of a route advertisement - they are more appropriately expressed as an attached = attribute=20 that expresses some desired property. how about: =20 "Network operators attach BGP communities to routes to associate particular properties with these routes." 3. ---------------- "and may apply to an individual route or to a group of routes." I am confused - surely the attributes in an Update BGP message apply to = the collection of routes contained in the Update. It cannot be applied to a=20= single route when the update itself contains multiple routes. Why not use the text: "and is applied to all routes contained in a BGP Update Message where the Communities Attribute is included." 4. ---------------- "[RFC1997] BGP Communities attributes are four-octet values split into two two-octet words." This is not the case - RFC1997 says: "Communities are treated as 32 bit = values" I think it would be more accurate to say: "BGP Communities attributes are four-octet values [RFC1997]. Common use = of this attribute type splits this single 32-bit value field into two = 16-bit values." 5. ---------------- "The BGP Extended Communities attribute [RFC4360] is also unsuitable, as the protocol limit of six octets cannot accommodate both a four-octet Global Administrator value and a four-octet Local Administrator value, which precludes the common operational practice of encoding a target ASN in the Local Administrator field." Thats a very long sentence. Try: "The BGP Extended Communities attribute [RFC4360] is also unsuitable, as the protocol limit of six octets for each community value cannot accommodate both a four-octet Global Administrator value and a = four-octet Local Administrator value. This limitation precludes the common operational practice of encoding a target ASN in the Local Administrator field." 6. ---------------- The aggregation section contains fewer constraints then either RFC1997 = or RFC4360. It also contains a confusing non-normative =E2=80=9Cshould". For reference, RFC4360 states: By default if a range of routes is to be aggregated and the resultant aggregates path attributes do not carry the ATOMIC_AGGREGATE attribute, then the resulting aggregate should have an Extended Communities path attribute that contains the set union of all = the Extended Communities from all of the aggregated routes. The default behavior could be overridden via local configuration, in which case handling the Extended Communities attribute in the presence of route aggregation becomes a matter of the local policy of the BGP speaker that performs the aggregation. =20 Why not use this formulation? i.e. "3. Aggregation If a set of routes is to be aggregated and the resulting aggregate = route's path attributes do not include the ATOMIC_AGGREGATE attribute, then the resulting aggregate route SHOULD have a Large Communities Attribute = formed from the set union of all the Large Community values from all of the aggregated set of routes. This behavior MAY be overridden via local configuration, in which case handling the Large Communities attribute in the presence of route aggregation is determined by the local policy of = the BGP speaker that performs the aggregation." 7. ---------------- 4. Canonical Representation I am confused here - this section used an example with TWO canonical representations: "For example: 64496:4294967295:2, 64496:0:0, or (64496, 111, 222)." =20 =20 Conventionally, it's better to use a single canonical representation, so = the authors should pick either a colon-delimited list, or a bracketed = comma+space separated object. =20 8. ---------------- =20 5. Reserved Large BGP Community values The text reads:=20 "the Global Administrator values specified above could be used if there is a future need for them." =20 This is entirely unclear. Is it referring to the values that the = previous paragraph specified as "SHOULD NOT use=E2=80=9D? Also "could be used" is = a poor choice of words for a normative specification. I suggest deleting completely the paragraph that contains this quote = from the document. 9. ---------------- The text reads:=20 "The error handling of Large BGP Communities is as follows: o A Large BGP Communities attribute SHALL be considered malformed if its length is not a non-zero multiple of 12." I think the author is trying to dayL "The error handling of Large BGP Communities is as follows: o A Large Communities attribute SHALL be considered malformed if the length of the Large Communities value, expressed in octets, is not = a non-zero multiple of 12." thanks, Geoff From nobody Thu Nov 3 17:17:35 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4661F1299AE for ; Thu, 3 Nov 2016 17:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.398 X-Spam-Level: X-Spam-Status: No, score=-108.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 2CgJGyrTCadA for ; Thu, 3 Nov 2016 17:17:28 -0700 (PDT) Received: from ia-mailgw.apnic.net (ia-mailgw.apnic.net [IPv6:2001:dd8:a:851::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 962C71299B9 for ; Thu, 3 Nov 2016 17:17:28 -0700 (PDT) Received: from iamda3.org.apnic.net (unknown [2001:dd8:9:2::101:249]) by ia-mailgw.apnic.net (Halon) with ESMTPS id 101901f0-a224-11e6-a41e-005056b6f213; Fri, 04 Nov 2016 10:17:25 +1000 (AEST) Received: from [202.158.221.23] (203.119.101.249) by iamda3.org.apnic.net (203.119.111.31) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 4 Nov 2016 10:17:24 +1000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Geoff Huston In-Reply-To: Date: Fri, 4 Nov 2016 11:17:24 +1100 Content-Transfer-Encoding: quoted-printable Message-ID: <5A049C45-CD74-4B20-9C8A-357557E2EDEF@apnic.net> References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com> <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com> To: IETF IDR WG X-Mailer: Apple Mail (2.3251) Archived-At: Cc: rtg-dir@ietf.org, Susan Hares Subject: Re: [Idr] Review of draft-ietf-large-community-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: Fri, 04 Nov 2016 00:17:31 -0000 I should=E2=80=99ve added: In terms of the quality of the document I think this is sorely needed and is a pivotal specification for the broad acceptance of four octet=20 AS numbers. I support its timely progress to publication as a standards track specification. Geoff > On 4 Nov. 2016, at 11:14 am, Geoff Huston wrote: >=20 > I have reviewed this draft and have the following 9 suggestions. All = of > these fall into the category of minor suggestions. I do not believe = that > there is may major structural deficiency in this specification, and = the > document is largely ready, in my view. >=20 > Here are my specific suggestions. >=20 >=20 > 1. ---------------- >=20 > Title: Large BGP Communities >=20 > to be consistent with previous attribute specifications, how about >=20 > "BGP Large Communities Attribute" >=20 > i.e. switch the order of "Large BGP" to "BGP Large" to be consistent = with > earlier BGP Extended Communities specification in RFC4360 >=20 > 2. ---------------- >=20 > "Network operators=20 > attach BGP communities to routes to identify intrinsic properties of > these routes." >=20 > I don't think community attributes are an intrinsic property of a = route > advertisement - they are more appropriately expressed as an attached = attribute=20 > that expresses some desired property. >=20 > how about: >=20 > "Network operators attach BGP communities to routes to associate > particular properties with these routes." >=20 > 3. ---------------- >=20 > "and may apply to an individual route or to a group of routes." >=20 > I am confused - surely the attributes in an Update BGP message apply = to the > collection of routes contained in the Update. It cannot be applied to = a=20 > single route when the update itself contains multiple routes. Why not > use the text: >=20 > "and is applied to all routes contained in a BGP Update Message where > the Communities Attribute is included." >=20 > 4. ---------------- >=20 > "[RFC1997] BGP Communities attributes are four-octet values split into > two two-octet words." >=20 > This is not the case - RFC1997 says: "Communities are treated as 32 = bit values" > I think it would be more accurate to say: >=20 > "BGP Communities attributes are four-octet values [RFC1997]. Common = use of > this attribute type splits this single 32-bit value field into two = 16-bit values." >=20 > 5. ---------------- >=20 > "The BGP Extended Communities > attribute [RFC4360] is also unsuitable, as the protocol limit of six > octets cannot accommodate both a four-octet Global Administrator > value and a four-octet Local Administrator value, which precludes the > common operational practice of encoding a target ASN in the Local > Administrator field." >=20 >=20 > Thats a very long sentence. Try: >=20 > "The BGP Extended Communities attribute [RFC4360] is also unsuitable, = as > the protocol limit of six octets for each community value cannot > accommodate both a four-octet Global Administrator value and a = four-octet > Local Administrator value. This limitation precludes the common > operational practice of encoding a target ASN in the Local = Administrator > field." >=20 > 6. ---------------- >=20 > The aggregation section contains fewer constraints then either RFC1997 = or > RFC4360. It also contains a confusing non-normative =E2=80=9Cshould". >=20 > For reference, RFC4360 states: By default if a range of routes is to = be > aggregated and the resultant aggregates path attributes do not carry = the > ATOMIC_AGGREGATE attribute, then the resulting aggregate should have = an > Extended Communities path attribute that contains the set union of all = the > Extended Communities from all of the aggregated routes. The default > behavior could be overridden via local configuration, in which case > handling the Extended Communities attribute in the presence of route > aggregation becomes a matter of the local policy of the BGP speaker = that > performs the aggregation. >=20 > Why not use this formulation? i.e. >=20 > "3. Aggregation >=20 > If a set of routes is to be aggregated and the resulting aggregate = route's > path attributes do not include the ATOMIC_AGGREGATE attribute, then = the > resulting aggregate route SHOULD have a Large Communities Attribute = formed > from the set union of all the Large Community values from all of the > aggregated set of routes. This behavior MAY be overridden via local > configuration, in which case handling the Large Communities attribute = in > the presence of route aggregation is determined by the local policy of = the > BGP speaker that performs the aggregation." >=20 > 7. ---------------- >=20 > 4. Canonical Representation >=20 > I am confused here - this section used an example with TWO canonical > representations: >=20 > "For example: 64496:4294967295:2, 64496:0:0, or (64496, 111, 222)." >=20 >=20 > Conventionally, it's better to use a single canonical representation, = so the > authors should pick either a colon-delimited list, or a bracketed = comma+space > separated object. >=20 >=20 > 8. ---------------- >=20 > 5. Reserved Large BGP Community values >=20 >=20 > The text reads:=20 >=20 > "the Global Administrator values specified above could be > used if there is a future need for them." >=20 > This is entirely unclear. Is it referring to the values that the = previous > paragraph specified as "SHOULD NOT use=E2=80=9D? Also "could be used" = is a poor > choice of words for a normative specification. >=20 > I suggest deleting completely the paragraph that contains this quote = from > the document. >=20 >=20 > 9. ---------------- >=20 > The text reads:=20 >=20 > "The error handling of Large BGP Communities is as follows: >=20 > o A Large BGP Communities attribute SHALL be considered malformed = if > its length is not a non-zero multiple of 12." >=20 >=20 > I think the author is trying to dayL >=20 > "The error handling of Large BGP Communities is as follows: >=20 > o A Large Communities attribute SHALL be considered malformed if = the > length of the Large Communities value, expressed in octets, is not = a > non-zero multiple of 12." >=20 >=20 > thanks, >=20 > Geoff >=20 From nobody Thu Nov 3 17:47:36 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46E6A129408; Thu, 3 Nov 2016 17:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, 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 qQXE5aFW_4Np; Thu, 3 Nov 2016 17:47:30 -0700 (PDT) Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D9661295BB; Thu, 3 Nov 2016 17:47:25 -0700 (PDT) Received: by guelah.shrubbery.net (Postfix, from userid 7053) id 501F47C6CE; Fri, 4 Nov 2016 00:47:25 +0000 (UTC) Date: Fri, 4 Nov 2016 00:47:25 +0000 From: heasley To: Geoff Huston Message-ID: <20161104004725.GC17584@shrubbery.net> References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com> <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc X-note: live free, or die! X-homer: i just want to have a beer while i am caring. X-Claimation: an engineer needs a manager like a fish needs a bicycle X-reality: only YOU can put an end to the embarrassment that is Tom Cruise User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Cc: IETF IDR WG , Susan Hares , rtg-dir@ietf.org Subject: Re: [Idr] Review of draft-ietf-large-community-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: Fri, 04 Nov 2016 00:47:32 -0000 Fri, Nov 04, 2016 at 11:14:29AM +1100, Geoff Huston: > 2. ---------------- > > "Network operators > attach BGP communities to routes to identify intrinsic properties of > these routes." > > I don't think community attributes are an intrinsic property of a route > advertisement - they are more appropriately expressed as an attached attribute > that expresses some desired property. > > how about: > > "Network operators attach BGP communities to routes to associate > particular properties with these routes." is "particular" a useless word here? I think the original text is fine, but to consider your suggestion and follow the less-is-more mantra.... > 3. ---------------- > > "and may apply to an individual route or to a group of routes." > > I am confused - surely the attributes in an Update BGP message apply to the > collection of routes contained in the Update. It cannot be applied to a > single route when the update itself contains multiple routes. Why not > use the text: > > "and is applied to all routes contained in a BGP Update Message where > the Communities Attribute is included." You are correct about a BGP Update msg, obviously, but that text is not talking about an update, rather the utility of a community, which may apply to a single route or a group of routes - some of which may not be in a given BGP Update msg. Yes? > 7. ---------------- > > 4. Canonical Representation > > I am confused here - this section used an example with TWO canonical > representations: > > "For example: 64496:4294967295:2, 64496:0:0, or (64496, 111, 222)." > > > Conventionally, it's better to use a single canonical representation, so the > authors should pick either a colon-delimited list, or a bracketed comma+space > separated object. Are you sure; a separator is not defined in the text. I agree with the other suggestions; the authors may or not. From nobody Thu Nov 3 18:04:41 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF731295FA; Thu, 3 Nov 2016 18:04:39 -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 NQxwVyn-8MPV; Thu, 3 Nov 2016 18:04:37 -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 93A5A12941C; Thu, 3 Nov 2016 18:04:37 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=50.36.174.111; From: "Susan Hares" To: "'Geoff Huston'" , "'IETF IDR WG'" References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com> <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com> In-Reply-To: Date: Thu, 3 Nov 2016 21:02:22 -0400 Message-ID: <004801d23637$19dcfd20$4d96f760$@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: AQH7vYX/r5lvDTiDOvRZn6NWFj+MugIVEsE7AusR2FECKfMMF6A7okGQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: rtg-dir@ietf.org Subject: Re: [Idr] Review of draft-ietf-large-community-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: Fri, 04 Nov 2016 01:04:39 -0000 Geoff:=20 Thank you for this amazing quick Review of the draft.=20 Sue=20 -----Original Message----- From: Geoff Huston [mailto:gih@apnic.net]=20 Sent: Thursday, November 3, 2016 8:14 PM To: IETF IDR WG Cc: rtg-dir@ietf.org; John G. Scudder; Susan Hares Subject: Review of draft-ietf-large-community-06.txt I have reviewed this draft and have the following 9 suggestions. All of = these fall into the category of minor suggestions. I do not believe that = there is may major structural deficiency in this specification, and the = document is largely ready, in my view. Here are my specific suggestions. 1. ---------------- Title: Large BGP Communities to be consistent with previous attribute specifications, how about "BGP Large Communities Attribute" i.e. switch the order of "Large BGP" to "BGP Large" to be consistent = with earlier BGP Extended Communities specification in RFC4360 2. ---------------- "Network operators attach BGP communities to routes to identify intrinsic properties of = these routes." I don't think community attributes are an intrinsic property of a route = advertisement - they are more appropriately expressed as an attached = attribute that expresses some desired property. how about: =20 "Network operators attach BGP communities to routes to associate = particular properties with these routes." 3. ---------------- "and may apply to an individual route or to a group of routes." I am confused - surely the attributes in an Update BGP message apply to = the collection of routes contained in the Update. It cannot be applied = to a single route when the update itself contains multiple routes. Why = not use the text: "and is applied to all routes contained in a BGP Update Message where = the Communities Attribute is included." 4. ---------------- "[RFC1997] BGP Communities attributes are four-octet values split into = two two-octet words." This is not the case - RFC1997 says: "Communities are treated as 32 bit = values" I think it would be more accurate to say: "BGP Communities attributes are four-octet values [RFC1997]. Common use = of this attribute type splits this single 32-bit value field into two = 16-bit values." 5. ---------------- "The BGP Extended Communities attribute [RFC4360] is also unsuitable, as the protocol limit of six = octets cannot accommodate both a four-octet Global Administrator value = and a four-octet Local Administrator value, which precludes the common = operational practice of encoding a target ASN in the Local Administrator = field." Thats a very long sentence. Try: "The BGP Extended Communities attribute [RFC4360] is also unsuitable, as = the protocol limit of six octets for each community value cannot = accommodate both a four-octet Global Administrator value and a = four-octet Local Administrator value. This limitation precludes the = common operational practice of encoding a target ASN in the Local = Administrator field." 6. ---------------- The aggregation section contains fewer constraints then either RFC1997 = or RFC4360. It also contains a confusing non-normative =E2=80=9Cshould". For reference, RFC4360 states: By default if a range of routes is to be = aggregated and the resultant aggregates path attributes do not carry the = ATOMIC_AGGREGATE attribute, then the resulting aggregate should have an = Extended Communities path attribute that contains the set union of all = the Extended Communities from all of the aggregated routes. The default = behavior could be overridden via local configuration, in which case = handling the Extended Communities attribute in the presence of route = aggregation becomes a matter of the local policy of the BGP speaker that = performs the aggregation. =20 Why not use this formulation? i.e. "3. Aggregation If a set of routes is to be aggregated and the resulting aggregate = route's path attributes do not include the ATOMIC_AGGREGATE attribute, = then the resulting aggregate route SHOULD have a Large Communities = Attribute formed from the set union of all the Large Community values = from all of the aggregated set of routes. This behavior MAY be = overridden via local configuration, in which case handling the Large = Communities attribute in the presence of route aggregation is determined = by the local policy of the BGP speaker that performs the aggregation." 7. ---------------- 4. Canonical Representation I am confused here - this section used an example with TWO canonical representations: "For example: 64496:4294967295:2, 64496:0:0, or (64496, 111, 222)." =20 =20 Conventionally, it's better to use a single canonical representation, so = the authors should pick either a colon-delimited list, or a bracketed = comma+space separated object. =20 8. ---------------- =20 5. Reserved Large BGP Community values The text reads:=20 "the Global Administrator values specified above could be used if there = is a future need for them." =20 This is entirely unclear. Is it referring to the values that the = previous paragraph specified as "SHOULD NOT use=E2=80=9D? Also "could be = used" is a poor choice of words for a normative specification. I suggest deleting completely the paragraph that contains this quote = from the document. 9. ---------------- The text reads:=20 "The error handling of Large BGP Communities is as follows: o A Large BGP Communities attribute SHALL be considered malformed if its length is not a non-zero multiple of 12." I think the author is trying to dayL "The error handling of Large BGP Communities is as follows: o A Large Communities attribute SHALL be considered malformed if the length of the Large Communities value, expressed in octets, is not = a non-zero multiple of 12." thanks, Geoff From nobody Thu Nov 3 18:18:30 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC8412949C for ; Thu, 3 Nov 2016 18:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.398 X-Spam-Level: X-Spam-Status: No, score=-108.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 8r3A4a0LpSs4 for ; Thu, 3 Nov 2016 18:18:25 -0700 (PDT) Received: from nx-mailgw.apnic.net (nx-mailgw.apnic.net [IPv6:2001:dd8:9:801::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94CA31295F6 for ; Thu, 3 Nov 2016 18:18:25 -0700 (PDT) Received: from iamda3.org.apnic.net (unknown [2001:dd8:9:2::101:249]) by nx-mailgw.apnic.net (Halon) with ESMTPS id 91ef3513-a22c-11e6-b23e-005056b685e3; Fri, 04 Nov 2016 11:18:19 +1000 (AEST) Received: from [202.158.221.23] (203.119.101.249) by iamda3.org.apnic.net (203.119.111.31) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 4 Nov 2016 11:18:21 +1000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Geoff Huston In-Reply-To: <20161104004725.GC17584@shrubbery.net> Date: Fri, 4 Nov 2016 12:18:20 +1100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com> <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com> <20161104004725.GC17584@shrubbery.net> To: heasley X-Mailer: Apple Mail (2.3251) Archived-At: Cc: IETF IDR WG , Susan Hares , rtg-dir@ietf.org Subject: Re: [Idr] Review of draft-ietf-large-community-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: Fri, 04 Nov 2016 01:18:27 -0000 > On 4 Nov. 2016, at 11:47 am, heasley wrote: >=20 > Fri, Nov 04, 2016 at 11:14:29AM +1100, Geoff Huston: >> 2. ---------------- >>=20 >> "Network operators=20 >> attach BGP communities to routes to identify intrinsic properties of >> these routes." >>=20 >> I don't think community attributes are an intrinsic property of a = route >> advertisement - they are more appropriately expressed as an attached = attribute=20 >> that expresses some desired property. >>=20 >> how about: >>=20 >> "Network operators attach BGP communities to routes to associate >> particular properties with these routes." >=20 > is "particular" a useless word here? I think the original text is = fine, but > to consider your suggestion and follow the less-is-more mantra=E2=80=A6.= >=20 I was taking exception to the word =E2=80=9Cintrinsic=E2=80=9D The route attributes attach properties to the route - they are not = expressing an =E2=80=9Cintrinsic=E2=80=9D property of the route. I suggested =E2=80=9Cparticular=E2=80=9D to propose that the properties = expressed with=20 communities are an association added by the BGP speaker. But less is more could just drop the adjective completely and I=E2=80=99d = be equally happy! Geoff From nobody Thu Nov 3 18:21:19 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7D1A12969A for ; Thu, 3 Nov 2016 18:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.398 X-Spam-Level: X-Spam-Status: No, score=-108.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 QHih5Ghopx8D for ; Thu, 3 Nov 2016 18:21:16 -0700 (PDT) Received: from ia-mailgw.apnic.net (ia-mailgw.apnic.net [IPv6:2001:dd8:a:851::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 537BE1295AE for ; Thu, 3 Nov 2016 18:21:16 -0700 (PDT) Received: from nxmda2.org.apnic.net (unknown [2001:dd8:9:2::101:249]) by ia-mailgw.apnic.net (Halon) with ESMTPS id fa2470b0-a22c-11e6-a41e-005056b6f213; Fri, 04 Nov 2016 11:21:14 +1000 (AEST) Received: from [202.158.221.23] (203.119.101.249) by NXMDA2.org.apnic.net (203.119.107.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 4 Nov 2016 11:20:55 +1000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Geoff Huston In-Reply-To: <20161104004725.GC17584@shrubbery.net> Date: Fri, 4 Nov 2016 12:21:12 +1100 Content-Transfer-Encoding: quoted-printable Message-ID: <3480266F-B03D-4623-A2FD-82F5A09110FD@apnic.net> References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com> <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com> <20161104004725.GC17584@shrubbery.net> To: heasley X-Mailer: Apple Mail (2.3251) Archived-At: Cc: IETF IDR WG , Susan Hares , rtg-dir@ietf.org Subject: Re: [Idr] Review of draft-ietf-large-community-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: Fri, 04 Nov 2016 01:21:19 -0000 > On 4 Nov. 2016, at 11:47 am, heasley wrote: >=20 > Fri, Nov 04, 2016 at 11:14:29AM +1100, Geoff Huston: >=20 >> 3. ---------------- >>=20 >> "and may apply to an individual route or to a group of routes." >>=20 >> I am confused - surely the attributes in an Update BGP message apply = to the >> collection of routes contained in the Update. It cannot be applied to = a=20 >> single route when the update itself contains multiple routes. Why not >> use the text: >>=20 >> "and is applied to all routes contained in a BGP Update Message where >> the Communities Attribute is included." >=20 > You are correct about a BGP Update msg, obviously, but that text is = not > talking about an update, rather the utility of a community, which may > apply to a single route or a group of routes - some of which may not = be > in a given BGP Update msg. Yes? So there is the mechanism of application (BGP) and the semantics of = application. It seemed to me that the text was implicitly referring to the mechanism of application and gave the impression that a community value could be = selectively applied to only some routes contained in a single BGP update. If the text is read as a semantic specification, then yes the same = community value can be applied to any number of routes. Either way, the text could do with some small clarification, imho. Geoff From nobody Thu Nov 3 18:25:18 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D2DF129699 for ; Thu, 3 Nov 2016 18:25:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.398 X-Spam-Level: X-Spam-Status: No, score=-108.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 n-3er6v3JvYo for ; Thu, 3 Nov 2016 18:25:14 -0700 (PDT) Received: from ao-mailgw.apnic.net (ao-mailgw.apnic.net [IPv6:2001:dd8:8:701::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7D121296A3 for ; Thu, 3 Nov 2016 18:25:13 -0700 (PDT) Received: from nxmda2.org.apnic.net (unknown [2001:dd8:9:2::101:249]) by ao-mailgw.apnic.net (Halon) with ESMTPS id 85a35a96-a22d-11e6-b8ce-005056b6ee6f; Fri, 04 Nov 2016 11:25:08 +1000 (AEST) Received: from [202.158.221.23] (203.119.101.249) by NXMDA2.org.apnic.net (203.119.107.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 4 Nov 2016 11:24:52 +1000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Geoff Huston In-Reply-To: <20161104004725.GC17584@shrubbery.net> Date: Fri, 4 Nov 2016 12:25:08 +1100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com> <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com> <20161104004725.GC17584@shrubbery.net> To: heasley X-Mailer: Apple Mail (2.3251) Archived-At: Cc: IETF IDR WG , Susan Hares , rtg-dir@ietf.org Subject: Re: [Idr] Review of draft-ietf-large-community-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: Fri, 04 Nov 2016 01:25:16 -0000 > On 4 Nov. 2016, at 11:47 am, heasley wrote: >=20 >=20 >> 7. ---------------- >>=20 >> 4. Canonical Representation >>=20 >> I am confused here - this section used an example with TWO canonical >> representations: >>=20 >> "For example: 64496:4294967295:2, 64496:0:0, or (64496, 111, 222)." >>=20 >>=20 >> Conventionally, it's better to use a single canonical representation, = so the >> authors should pick either a colon-delimited list, or a bracketed = comma+space >> separated object. >=20 > Are you sure; a separator is not defined in the text. If the =E2=80=9CCanonical Representation=E2=80=9D is to represent the = Large Communities Attributes value=20 as a sequence of triplets, where the triplet is three unsigned decimal = values, but not to define the representation of the delimiter between the elements of the = triplet, nor the delineator between successive triplets, then I think that this is an incomplete = canonical representation. cheers, Geoff From nobody Thu Nov 3 18:25:26 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE6CE1296E8 for ; Thu, 3 Nov 2016 18:25:18 -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 XC4mSBMVfY77 for ; Thu, 3 Nov 2016 18:25:17 -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 50B761296B7 for ; Thu, 3 Nov 2016 18:25:17 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.174.111; From: "Susan Hares" To: "'John G. Scudder'" , "'Robert Raszuk'" References: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> <20161101133240.GK1581@hanna.meerval.net> <2393790D-F279-41ED-B5B2-E427C60B4926@juniper.net> In-Reply-To: <2393790D-F279-41ED-B5B2-E427C60B4926@juniper.net> Date: Thu, 3 Nov 2016 21:22:57 -0400 Message-ID: <034a01d23639$fa2c78e0$ee856aa0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_034B_01D23618.731C3870" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG4XNVJbFLLu0eQmTL8gVJbAkCFVwDjdK5pAXaolZsCtVg7VaDTO0EQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'IETF IDR Working Group' Subject: Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129 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, 04 Nov 2016 01:25:19 -0000 This is a multipart message in MIME format. ------=_NextPart_000_034B_01D23618.731C3870 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit John: My understanding with the IESG and IANA is that this is true. The best reference is the BIS for RFC226bis below: https://tools.ietf.org/html/draft-leiba-cotton-iana-5226bis-11 The RFC5226bis-11.txt got stalled due to the IESG wandering if the revision is needed. Based on our experience, I think it is needed. Alvaro will kick off this work, but the process of updating a "process" document should not impede this document's process. We need to think outside the box. I suggest we complete this adoption of draft-snijders-idr-deprecate-30-31-129 draft by 11/13/2016, and do a WG LC on the draft directly following this process draft (11/14 to 11/28). This should allow the draft-idr-large-communities to have the necessary registry "glue" ready so the IESG publication of large communities can go quickly. Sue From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of John G. Scudder Sent: Tuesday, November 1, 2016 10:24 AM To: Robert Raszuk Cc: IETF IDR Working Group Subject: Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129 AFAICT the function of the draft is simply to kick the IANA code point state to "deprecated". It doesn't anchor it there for all time. Presumably a later request can move the state to assigned or whatever, as we've previously discussed. I don't think any update to the current "deprecate" document would be needed to achieve this (I guess maybe the later document might list this one in its "updates" header). I'll confirm this understanding with IESG and IANA before the end of the WG adoption call. (Unless someone can point me to chapter-and-verse of a reference that explains the process clearly enough, unfortunately I have not found such.) Thanks, --John On Nov 1, 2016, at 10:02 AM, Robert Raszuk wrote: Hi Job, Have you consider marking those codepoints as "RESERVED" rather then "DEPRECIATED". Reason being that if any of the applications they have been squatted on behalf of want to use them - it would be pretty easy to allocate them. The other alternative would be to allocate them to those applications now (for which the drafts exist) as IANA early allocations. If you depreciate them now and we know that as example Contrail Multicast is important either your draft will need to quickly be moved to historic or yet another types will need to be allocated again. In any of the above Large Communities will get virgin BGP attribute type which I believe is the main point here. Cheers, R. On Tue, Nov 1, 2016 at 2:32 PM, Job Snijders wrote: Dear working group, To prevent having multiple drafts in quick succession covering the same style of issue - I'd like your feedback on the following: I believe that bgp path attribute 241, 242, 243 should also be added to this draft for the same reasons as 30, 31 and 129 are listed. OLD: This document requests IANA to deprecate the following BGP Path attributes: 30, 31, and 129. NEW: This document requests IANA to deprecate the following BGP Path attributes: 30, 31, 129, 241, 242, and 243. Does anyone object? If so, why? Unilaterally changing the document while in its mid-flight through the working group adoption process might be considered bad form, hence my request for feedback on the 241,242,243 topic. Please note - the deprecation of an attribute can be undone if proper process is followed. The priority here is to prevent IANA from assigning tainted codepoints to innocent bystanders, thus a deprecation document needs to exist. In time the working group has the power to undeprecate them for specific purposes. Kind regards, Job On Mon, Oct 31, 2016 at 05:18:57PM -0400, John G.Scudder wrote: > Hi Everyone, > > The author has asked for the WG to adopt draft-snijders-idr-deprecate-30-31-129. > > If you support or oppose adoption please reply indicating so. Reasons for your position are helpful, as volunteering to review, comment, and/or shepherd. As an aside, I will note that I don't think the WG has the option of doing nothing, so if you oppose adoption please address what you think should be done instead. > > The adoption call will end November 13. > > Thanks, > > --John > > P.S.: https://tools.ietf.org/html/draft-snijders-idr-deprecate-30-31-129-01 > > Abstract > > This document requests IANA to deprecate the following BGP path > attributes values: 30, 31 and 129. > > > _______________________________________________ > 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_034B_01D23618.731C3870 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

John:

 

My understanding with the IESG and IANA is that this is = true.   The best reference is the BIS for RFC226bis below: =

 

h= ttps://tools.ietf.org/html/draft-leiba-cotton-iana-5226bis-11

 

The RFC5226bis-11.txt got stalled due to the IESG wandering if the = revision is needed.  Based on our experience, I think it is needed. =  Alvaro will kick off this work, but the process of updating a = “process” document should not impede this document’s = process.  We need to think outside the box. =

 

I suggest we complete this adoption of = draft-snijders-idr-deprecate-30-31-129 draft by 11/13/2016, and do a WG = LC on the draft directly following this process draft (11/14 to = 11/28).    This should allow the = draft-idr-large-communities to have the necessary registry = “glue” ready so the IESG publication of large communities = can go quickly.    

 

Sue

 

From:= = Idr [mailto:idr-bounces@ietf.org] On Behalf Of John G. = Scudder
Sent: Tuesday, November 1, 2016 10:24 AM
To: = Robert Raszuk
Cc: IETF IDR Working Group
Subject: = Re: [Idr] Working group adoption call for = draft-snijders-idr-deprecate-30-31-129

<= p class=3DMsoNormal> 

AFAICT the = function of the draft is simply to kick the IANA code point state to = "deprecated". It doesn't anchor it there for all time. = Presumably a later request can move the state to assigned or whatever, = as we've previously discussed. I don't think any update to the current = "deprecate" document would be needed to achieve this (I guess = maybe the later document might list this one in its "updates" = header).

 

I'll confirm this understanding with IESG and IANA = before the end of the WG adoption call. (Unless someone can point me to = chapter-and-verse of a reference that explains the process clearly = enough, unfortunately I have not found = such.)

 

Thanks,

 

--John

 

On Nov 1, 2016, at 10:02 AM, Robert Raszuk <robert@raszuk.net> = wrote:

 

Hi = Job,

 

Have you consider marking = those codepoints as "RESERVED" rather then = "DEPRECIATED". 

 

Reason being that if any of = the applications they have been squatted on behalf of want to use them - = it would be pretty easy to allocate = them.

 

The other alternative would = be to allocate them to those applications now (for which the drafts = exist) as IANA early allocations. If you depreciate them now and we know = that as example Contrail Multicast is important either your draft will = need to quickly be moved to historic or yet another types will need to = be allocated again. 

 

In any of the above Large = Communities will get virgin BGP attribute type which I believe is the = main point here.

 

Cheers,

<= /div>

R.

=

 

 

On Tue, Nov 1, 2016 at 2:32 PM, Job Snijders <job@instituut.net> wrote:

Dear working group,

To prevent having multiple = drafts in quick succession covering the same
style of issue - I'd = like your feedback on the following:

I believe that bgp path = attribute 241, 242, 243 should also be added to
this draft for the = same reasons as 30, 31 and 129 are listed.

OLD:
    = This document requests IANA to deprecate the following BGP = Path
    attributes: 30, 31, and 129.

NEW:
  =   This document requests IANA to deprecate the following BGP = Path
    attributes: 30, 31, 129, 241, 242, and = 243.

Does anyone object? If so, why?

Unilaterally changing = the document while in its mid-flight through the
working group = adoption process might be considered bad form, hence my
request for = feedback on the 241,242,243 topic.

Please note - the deprecation = of an attribute can be undone if proper
process is followed. The = priority here is to prevent IANA from assigning
tainted codepoints to = innocent bystanders, thus a deprecation document
needs to exist. In = time the working group has the power to undeprecate
them for specific = purposes.

Kind regards,

Job

On = Mon, Oct 31, 2016 at 05:18:57PM -0400, John G.Scudder = wrote:

> Hi = Everyone,
>
> The author has asked for the WG to adopt  = draft-snijders-idr-deprecate-30-31-129.
>
> If you support = or oppose adoption please reply indicating so. Reasons for your position = are helpful, as volunteering to review, comment, and/or shepherd. As an = aside, I will note that I don't think the WG has the option of doing = nothing, so if you oppose adoption please address what you think should = be done instead.
>
> The adoption call will end November = 13.
>
> Thanks,
>
> --John
>
> P.S.: = https://tools.ietf.org/html/draft-snijders-idr-deprecat= e-30-31-129-01
>
> Abstract
>
>    = This document requests IANA to deprecate the following BGP = path
>    attributes values: 30, 31 and = 129.
>
>
> = _______________________________________________
> 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_034B_01D23618.731C3870-- From nobody Thu Nov 3 18:53:19 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A62551296CC for ; Thu, 3 Nov 2016 18:53:17 -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 WnT1bqT12Vkb for ; Thu, 3 Nov 2016 18:53: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 0ACA61294ED for ; Thu, 3 Nov 2016 18:53:14 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.174.111; From: "Susan Hares" To: "'John G. Scudder'" , "'Robert Raszuk'" References: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> <20161101133240.GK1581@hanna.meerval.net> <2393790D-F279-41ED-B5B2-E427C60B4926@juniper.net> <034a01d23639$fa2c78e0$ee856aa0$@ndzh.com> In-Reply-To: <034a01d23639$fa2c78e0$ee856aa0$@ndzh.com> Date: Thu, 3 Nov 2016 21:50:47 -0400 Message-ID: <042301d2363d$dd9944c0$98cbce40$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0424_01D2361C.56897980" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG4XNVJbFLLu0eQmTL8gVJbAkCFVwDjdK5pAXaolZsCtVg7VQEQjTOToMq/kuA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'IETF IDR Working Group' Subject: Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129 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, 04 Nov 2016 01:53:17 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0424_01D2361C.56897980 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Robert and others: The draft-snijders-idr-deprecate-30-31-129 draft should not delay an official request for the Wide Community implementation. The three requirements are: 1) Stable draft, 2) 1 or more Implementation, and testing work toward interoperability. Implementers must be able to switch to another reference point if needed. 3) Approval by the IDR working group for early adoption. https://www.ietf.org/mail-archive/web/idr/current/msg16814.html What is needed is a stable draft. I recommend you work with Jie Dong, Mach Chen, and Shunwan Zhang to make sure the next Wide communities draft aligns with their implementation. At that point, these teams can apply for an early allocation. If you complete a stable draft by the beginning of IETF week, and the implementers align their code with your draft - we can begin step 3. Your challenge is to get the stable specification that aligns with the code work so the code work can progress quickly. Sue From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Thursday, November 3, 2016 9:23 PM To: 'John G. Scudder'; 'Robert Raszuk' Cc: 'IETF IDR Working Group' Subject: Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129 John: My understanding with the IESG and IANA is that this is true. The best reference is the BIS for RFC226bis below: https://tools.ietf.org/html/draft-leiba-cotton-iana-5226bis-11 The RFC5226bis-11.txt got stalled due to the IESG wandering if the revision is needed. Based on our experience, I think it is needed. Alvaro will kick off this work, but the process of updating a "process" document should not impede this document's process. We need to think outside the box. I suggest we complete this adoption of draft-snijders-idr-deprecate-30-31-129 draft by 11/13/2016, and do a WG LC on the draft directly following this process draft (11/14 to 11/28). This should allow the draft-idr-large-communities to have the necessary registry "glue" ready so the IESG publication of large communities can go quickly. Sue From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of John G. Scudder Sent: Tuesday, November 1, 2016 10:24 AM To: Robert Raszuk Cc: IETF IDR Working Group Subject: Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129 AFAICT the function of the draft is simply to kick the IANA code point state to "deprecated". It doesn't anchor it there for all time. Presumably a later request can move the state to assigned or whatever, as we've previously discussed. I don't think any update to the current "deprecate" document would be needed to achieve this (I guess maybe the later document might list this one in its "updates" header). I'll confirm this understanding with IESG and IANA before the end of the WG adoption call. (Unless someone can point me to chapter-and-verse of a reference that explains the process clearly enough, unfortunately I have not found such.) Thanks, --John On Nov 1, 2016, at 10:02 AM, Robert Raszuk wrote: Hi Job, Have you consider marking those codepoints as "RESERVED" rather then "DEPRECIATED". Reason being that if any of the applications they have been squatted on behalf of want to use them - it would be pretty easy to allocate them. The other alternative would be to allocate them to those applications now (for which the drafts exist) as IANA early allocations. If you depreciate them now and we know that as example Contrail Multicast is important either your draft will need to quickly be moved to historic or yet another types will need to be allocated again. In any of the above Large Communities will get virgin BGP attribute type which I believe is the main point here. Cheers, R. On Tue, Nov 1, 2016 at 2:32 PM, Job Snijders wrote: Dear working group, To prevent having multiple drafts in quick succession covering the same style of issue - I'd like your feedback on the following: I believe that bgp path attribute 241, 242, 243 should also be added to this draft for the same reasons as 30, 31 and 129 are listed. OLD: This document requests IANA to deprecate the following BGP Path attributes: 30, 31, and 129. NEW: This document requests IANA to deprecate the following BGP Path attributes: 30, 31, 129, 241, 242, and 243. Does anyone object? If so, why? Unilaterally changing the document while in its mid-flight through the working group adoption process might be considered bad form, hence my request for feedback on the 241,242,243 topic. Please note - the deprecation of an attribute can be undone if proper process is followed. The priority here is to prevent IANA from assigning tainted codepoints to innocent bystanders, thus a deprecation document needs to exist. In time the working group has the power to undeprecate them for specific purposes. Kind regards, Job On Mon, Oct 31, 2016 at 05:18:57PM -0400, John G.Scudder wrote: > Hi Everyone, > > The author has asked for the WG to adopt draft-snijders-idr-deprecate-30-31-129. > > If you support or oppose adoption please reply indicating so. Reasons for your position are helpful, as volunteering to review, comment, and/or shepherd. As an aside, I will note that I don't think the WG has the option of doing nothing, so if you oppose adoption please address what you think should be done instead. > > The adoption call will end November 13. > > Thanks, > > --John > > P.S.: https://tools.ietf.org/html/draft-snijders-idr-deprecate-30-31-129-01 > > Abstract > > This document requests IANA to deprecate the following BGP path > attributes values: 30, 31 and 129. > > > _______________________________________________ > 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_0424_01D2361C.56897980 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Robert and others:

 

The draft-snijders-idr-deprecate-30-31-129 draft should not delay an = official request for the Wide Community implementation.   The = three requirements are:

 

1)      = Stable draft,

2)      = 1 or more Implementation, and testing work toward interoperability. =   Implementers must be able to switch to another reference = point if needed.

3)      = Approval by the IDR working group for early adoption. =

 

= https://www.ietf.org/mail-archive/web/idr/current/msg16814.html<= /o:p>

 

What is needed is a stable draft.   I recommend you work = with Jie Dong, Mach Chen, and Shunwan Zhang to make sure the next Wide = communities draft aligns with their implementation.  At that point, = these teams can apply for an early allocation.

 

If you complete a stable draft by the beginning of IETF week, and the = implementers align their code with your draft – we can begin step = 3.  Your challenge is to get the stable specification that aligns = with the code work so the code work can progress quickly. =

 

Sue

 

From:= = Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan = Hares
Sent: Thursday, November 3, 2016 9:23 PM
To: = 'John G. Scudder'; 'Robert Raszuk'
Cc: 'IETF IDR Working = Group'
Subject: Re: [Idr] Working group adoption call for = draft-snijders-idr-deprecate-30-31-129

<= p class=3DMsoNormal> 

John:

 

My understanding with the IESG and IANA is that this is = true.   The best reference is the BIS for RFC226bis below: =

 

h= ttps://tools.ietf.org/html/draft-leiba-cotton-iana-5226bis-11

 

The RFC5226bis-11.txt got stalled due to the IESG wandering if the = revision is needed.  Based on our experience, I think it is needed. =  Alvaro will kick off this work, but the process of updating a = “process” document should not impede this document’s = process.  We need to think outside the box. =

 

I suggest we complete this adoption of = draft-snijders-idr-deprecate-30-31-129 draft by 11/13/2016, and do a WG = LC on the draft directly following this process draft (11/14 to = 11/28).    This should allow the = draft-idr-large-communities to have the necessary registry = “glue” ready so the IESG publication of large communities = can go quickly.    

 

Sue

 

From:= = Idr [mailto:idr-bounces@ietf.org] = On Behalf Of John G. Scudder
Sent: Tuesday, November 1, = 2016 10:24 AM
To: Robert Raszuk
Cc: IETF IDR Working = Group
Subject: Re: [Idr] Working group adoption call for = draft-snijders-idr-deprecate-30-31-129

<= p class=3DMsoNormal> 

AFAICT the = function of the draft is simply to kick the IANA code point state to = "deprecated". It doesn't anchor it there for all time. = Presumably a later request can move the state to assigned or whatever, = as we've previously discussed. I don't think any update to the current = "deprecate" document would be needed to achieve this (I guess = maybe the later document might list this one in its "updates" = header).

 

I'll confirm this understanding with IESG and IANA = before the end of the WG adoption call. (Unless someone can point me to = chapter-and-verse of a reference that explains the process clearly = enough, unfortunately I have not found = such.)

 

Thanks,

 

--John

 

On Nov 1, 2016, at 10:02 AM, Robert Raszuk <robert@raszuk.net> = wrote:

 

Hi = Job,

 

Have you consider marking = those codepoints as "RESERVED" rather then = "DEPRECIATED". 

 

Reason being that if any of = the applications they have been squatted on behalf of want to use them - = it would be pretty easy to allocate = them.

 

The other alternative would = be to allocate them to those applications now (for which the drafts = exist) as IANA early allocations. If you depreciate them now and we know = that as example Contrail Multicast is important either your draft will = need to quickly be moved to historic or yet another types will need to = be allocated again. 

 

In any of the above Large = Communities will get virgin BGP attribute type which I believe is the = main point here.

 

Cheers,

<= /div>

R.

=

 

 

On Tue, Nov 1, 2016 at 2:32 PM, Job Snijders <job@instituut.net> wrote:

Dear working group,

To prevent having multiple = drafts in quick succession covering the same
style of issue - I'd = like your feedback on the following:

I believe that bgp path = attribute 241, 242, 243 should also be added to
this draft for the = same reasons as 30, 31 and 129 are listed.

OLD:
    = This document requests IANA to deprecate the following BGP = Path
    attributes: 30, 31, and 129.

NEW:
  =   This document requests IANA to deprecate the following BGP = Path
    attributes: 30, 31, 129, 241, 242, and = 243.

Does anyone object? If so, why?

Unilaterally changing = the document while in its mid-flight through the
working group = adoption process might be considered bad form, hence my
request for = feedback on the 241,242,243 topic.

Please note - the deprecation = of an attribute can be undone if proper
process is followed. The = priority here is to prevent IANA from assigning
tainted codepoints to = innocent bystanders, thus a deprecation document
needs to exist. In = time the working group has the power to undeprecate
them for specific = purposes.

Kind regards,

Job

On = Mon, Oct 31, 2016 at 05:18:57PM -0400, John G.Scudder = wrote:

> Hi = Everyone,
>
> The author has asked for the WG to adopt  = draft-snijders-idr-deprecate-30-31-129.
>
> If you support = or oppose adoption please reply indicating so. Reasons for your position = are helpful, as volunteering to review, comment, and/or shepherd. As an = aside, I will note that I don't think the WG has the option of doing = nothing, so if you oppose adoption please address what you think should = be done instead.
>
> The adoption call will end November = 13.
>
> Thanks,
>
> --John
>
> P.S.: = https://tools.ietf.org/html/draft-snijders-idr-deprecat= e-30-31-129-01
>
> Abstract
>
>    = This document requests IANA to deprecate the following BGP = path
>    attributes values: 30, 31 and = 129.
>
>
> = _______________________________________________
> 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_0424_01D2361C.56897980-- From nobody Thu Nov 3 19:36:49 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03C53129449 for ; Thu, 3 Nov 2016 19:36:48 -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 9hhi7o8EC6zf for ; Thu, 3 Nov 2016 19:36:46 -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 99D2B127ABE for ; Thu, 3 Nov 2016 19:36:46 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.174.111; From: "Susan Hares" To: "'Robert Raszuk'" , "'John G. Scudder'" References: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> <20161101133240.GK1581@hanna.meerval.net> <2393790D-F279-41ED-B5B2-E427C60B4926@juniper.net> <7FE93D56-DAB9-48BC-A577-D48E48E025B4@juniper.net> In-Reply-To: Date: Thu, 3 Nov 2016 22:34:28 -0400 Message-ID: <04b601d23643$f7c6b7f0$e75427d0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_04B7_01D23622.70B5DB40" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG4XNVJbFLLu0eQmTL8gVJbAkCFVwDjdK5pAXaolZsCtVg7VQJ3ydgGAXttr6YCEsrS1KCjFl8Q Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'IETF IDR Working Group' Subject: Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129 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, 04 Nov 2016 02:36:48 -0000 This is a multipart message in MIME format. ------=_NextPart_000_04B7_01D23622.70B5DB40 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Robert:=20 =20 =20 At the time RFC7120 was published, the IDR chairs and the RTG ADs = invited all drafts that were written and published prior to that point = to submit requests for early allocation with a simple IANA process. = Prior to RFC7210, there was an way to get this drafts done if we ask the = IESG to review the documents. The early allocation process did not = start with RFC7120, but was simplified. =20 =20 By the way, draft-vandevelde-idr-remote-next-hop-00.txt was included in: = https://datatracker.ietf.org/doc/draft-ietf-idr-tunnel-encaps/. You = will find this on the IDR web page. On the = draft-marques-l3vpn-mcast-edge-01, if the authors are working on this = draft =E2=80=93 then it is a bess draft. If the authors have problems = with the early code point allocation, then can copy me and I will = transfer information to the appropriate BESS chairs. I will ask the ADs = to present a quick summary of Early Allocation processes to the whole = Area so that people will have a better understanding of Early = Allocation. I realize the process may be frustrating to you and others. = I am willing to help solve the problems for specific drafts or via a = proposal such as Jeff Haas made for private space. However, this = discussion should be done in a separate discussion thread or privately.=20 =20 Sue=20 =20 =20 =20 From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk Sent: Tuesday, November 1, 2016 11:04 AM To: John G. Scudder Cc: IETF IDR Working Group Subject: Re: [Idr] Working group adoption call for = draft-snijders-idr-deprecate-30-31-129 =20 =E2=80=8BJohn,=E2=80=8B =20 I'm not aware of there having been an early allocation request for any = of the code points in question. =20 =E2=80=8BWell I am not sure how some of the documents in question could = ask for early allocation based on RFC7120 published in 2014 if they were = written and published well before that date ... =20 https://tools.ietf.org/html/draft-marques-l3vpn-mcast-edge-01 https://www.ietf.org/archive/id/draft-vandevelde-idr-remote-next-hop-00.t= xt ... =20 Thx, R. =20 =E2=80=8B =20 ------=_NextPart_000_04B7_01D23622.70B5DB40 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Robert:

 

<chair hat on>

At the time RFC7120 was published, the IDR chairs and the RTG ADs = invited all drafts that were written and published prior to that point = to submit requests for early allocation with a simple IANA = process.=C2=A0=C2=A0 Prior to RFC7210, there was an way to get this = drafts done if we ask the IESG to review the documents.=C2=A0 The early = allocation process did not start with RFC7120, but was simplified. = =C2=A0=C2=A0

 

By the way, draft-vandevelde-idr-remote-next-hop-00.txt was included = in: h= ttps://datatracker.ietf.org/doc/draft-ietf-idr-tunnel-encaps/.=C2=A0 = =C2=A0You will find this on the IDR web page. =C2=A0=C2=A0On the = =C2=A0draft-marques-l3vpn-mcast-edge-01,=C2=A0 if the authors are = working on this draft =E2=80=93 then it is a bess draft.=C2=A0=C2=A0 If = the authors have problems with the early code point allocation, then can = copy me and I will transfer information to the appropriate BESS chairs. = =C2=A0I will ask the ADs to present a quick summary of Early Allocation = processes to the whole Area so that people will have a better = understanding of Early Allocation.=C2=A0 I realize the process may be = frustrating to you and others.=C2=A0 I am willing to help solve the = problems for specific drafts or via a proposal such as Jeff Haas made = for private space.=C2=A0 However, this discussion should be done in a = separate discussion thread or privately.

<chair hat off>

Sue

 

 

 

From:= = Idr [mailto:idr-bounces@ietf.org] On Behalf Of Robert = Raszuk
Sent: Tuesday, November 1, 2016 11:04 AM
To: = John G. Scudder
Cc: IETF IDR Working Group
Subject: = Re: [Idr] Working group adoption call for = draft-snijders-idr-deprecate-30-31-129

 

=E2=80=8BJohn,=E2=80=8B

 

I'm not = aware of there having been an early allocation request for any of the = code points in question.

 

=E2=80=8BWell I am not sure = how some of the documents in question could ask for early allocation = based on RFC7120 published in 2014 if they were written and published = well before that date ...

------=_NextPart_000_04B7_01D23622.70B5DB40-- From nobody Thu Nov 3 20:54:08 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E92601296ED; Thu, 3 Nov 2016 20:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 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=-1.497, 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 VMSB9oG7A6gU; Thu, 3 Nov 2016 20:54:02 -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 D7ABE1294DF; Thu, 3 Nov 2016 20:54:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1946; q=dns/txt; s=iport; t=1478231641; x=1479441241; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=A04UT/XEPWo7o3PZNRAVCeQ9DYRmeHU+T+jmBeYkGuU=; b=RH7nHxq8jlFrU4F1Aiv0TxwZolycnJfOMnkZDzPX5rAMTOS/asdsoO0y OjUbDJ4Ms2TlVerjTgQKaC8avuRwrZyCIrDkFW79oumGMTWS7niQevUVY DiXJHP+IMzwZni9wZyKKJnpsdZm4byMqA8GshrEBGARvVwpE2QrN3nfL7 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B3AQC8BRxY/4sNJK1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgy4BAQEBAR+BW40xq0eCCIYjAhqBcD8UAQIBAQEBAQEBYiiEYgEBBCM?= =?us-ascii?q?RRRACAQgODAImAgICMBUQAgQBDQ0MiESuX40NAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBHIEJhTaEVYdLglwFlEKFXwGQNZARkSIBHjdrhR+HWoEMAQEB?= X-IronPort-AV: E=Sophos;i="5.31,442,1473120000"; d="scan'208";a="167279388" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Nov 2016 03:54:01 +0000 Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id uA43s0W8011208 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 4 Nov 2016 03:54:01 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 3 Nov 2016 22:54:00 -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; Thu, 3 Nov 2016 22:54:00 -0500 From: "Jakob Heitz (jheitz)" To: Geoff Huston , IETF IDR WG Thread-Topic: [Idr] Review of draft-ietf-large-community-06.txt Thread-Index: AQHSNjBz6sRcMeSZxEiIR579im5tsaDIKelQ Date: Fri, 4 Nov 2016 03:54:00 +0000 Message-ID: <4080cfba032744f590fcbbb710f0d618@XCH-ALN-014.cisco.com> References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com> <117ea01d23611$a28513e0$e78f3ba0$@ndzh.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: [10.24.32.83] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "rtg-dir@ietf.org" , Susan Hares Subject: Re: [Idr] Review of draft-ietf-large-community-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: Fri, 04 Nov 2016 03:54:03 -0000 VGhhbmtzIEdlb2ZmLCBJJ2xsIGZpeCB0aGVtLg0KDQpPbmUgdGhpbmcgYWJvdXQgdGhlIGFnZ3Jl Z2F0aW9uLg0KSSBmaXJzdCBoYWQgdGhlIGNvbmRpdGlvbiAiZG8gbm90IGluY2x1ZGUgdGhlIEFU T01JQ19BR0dSRUdBVEUiLg0KVGhlbiBzb21lb25lIGNvbW1lbnRlZCBvbiB0aGUgbGlzdCB0aGF0 IEFUT01JQ19BR0dSRUdBVEUgd2FzIGRlYWQuDQpJIHJldmlld2VkIHRoZSBmdW5jdGlvbiBvZiBB VE9NSUNfQUdHUkVHQVRFIGFuZCB3aGF0IG91ciBjb2RlIGRvZXMuDQpBVE9NSUNfQUdHUkVHQVRF IG1lYW5zIHRoYXQgaW5mb3JtYXRpb24gd2FzIGxvc3QgYnkgYWdncmVnYXRpb24uDQpJbiBvdXIg Y29kZSAoYW5kIG90aGVyIGNvZGUgdGhhdCBJIGhhdmUgd29ya2VkIG9uKSwgd2hlbiB3ZQ0KYWdn cmVnYXRlLCB3ZSBhbHdheXMgYWRkIHRoZSBBVE9NSUNfQUdHUkVHQVRFIGF0dHJpYnV0ZS4NClRo ZXJlIGlzIG5vIGNhc2Ugd2hlbiB3ZSBhZ2dyZWdhdGUgd2l0aG91dCBhZGRpbmcgdGhlIEFUT01J Q19BR0dSRUdBVEUNCmF0dHJpYnV0ZS4gQmVpbmcgb2Ygbm8gY29uc2VxdWVuY2UsIEkgcmVtb3Zl ZCB0aGF0IHBhcnQgb2YgdGhlIHRleHQuDQpJIG1lYW4sIHRoZSB0ZXh0IHRlbGxzIHlvdSBob3cg dG8gYWdncmVnYXRlIGlmIHRoZSBBVE9NSUNfQUdHUkVHQVRFDQppcyBhYnNlbnQsIGJ1dCBzYXlz IG5vdGhpbmcgYWJvdXQgaG93IHRvIGFnZ3JlZ2F0ZSBpZiBpdCdzIHByZXNlbnQuDQoNClBlcnNv bmFsbHksIEknbSBmaW5lIGVpdGhlciB3YXkuIEl0IHdpbGwgbm90IGNoYW5nZSBhbnkgY29kZSBJ IHdyaXRlLg0KDQoNCkpha29iLg0KDQoNCj4gIjMuIEFnZ3JlZ2F0aW9uDQo+IA0KPiBJZiBhIHNl dCBvZiByb3V0ZXMgaXMgdG8gYmUgYWdncmVnYXRlZCBhbmQgdGhlIHJlc3VsdGluZyBhZ2dyZWdh dGUgcm91dGUncw0KPiBwYXRoIGF0dHJpYnV0ZXMgZG8gbm90IGluY2x1ZGUgdGhlIEFUT01JQ19B R0dSRUdBVEUgYXR0cmlidXRlLCB0aGVuIHRoZQ0KPiByZXN1bHRpbmcgYWdncmVnYXRlIHJvdXRl IFNIT1VMRCBoYXZlIGEgTGFyZ2UgQ29tbXVuaXRpZXMgQXR0cmlidXRlIGZvcm1lZA0KPiBmcm9t IHRoZSBzZXQgdW5pb24gb2YgYWxsIHRoZSBMYXJnZSBDb21tdW5pdHkgdmFsdWVzIGZyb20gYWxs IG9mIHRoZQ0KPiBhZ2dyZWdhdGVkIHNldCBvZiByb3V0ZXMuICBUaGlzIGJlaGF2aW9yIE1BWSBi ZSBvdmVycmlkZGVuIHZpYSBsb2NhbA0KPiBjb25maWd1cmF0aW9uLCBpbiB3aGljaCBjYXNlIGhh bmRsaW5nIHRoZSBMYXJnZSBDb21tdW5pdGllcyBhdHRyaWJ1dGUgaW4NCj4gdGhlIHByZXNlbmNl IG9mIHJvdXRlIGFnZ3JlZ2F0aW9uIGlzIGRldGVybWluZWQgYnkgdGhlIGxvY2FsIHBvbGljeSBv ZiB0aGUNCj4gQkdQIHNwZWFrZXIgdGhhdCBwZXJmb3JtcyB0aGUgYWdncmVnYXRpb24uIg0K From nobody Thu Nov 3 21:06:08 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 456D11296ED; Thu, 3 Nov 2016 21:06:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 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=-1.497, 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 HbdYJv4mC179; Thu, 3 Nov 2016 21:06:03 -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 D925F1297AA; Thu, 3 Nov 2016 21:05:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1294; q=dns/txt; s=iport; t=1478232354; x=1479441954; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=RQkWPVBMipKu2NUHQ39WhhJA1xTeR8TU4nP6BgJo8SM=; b=c+6rFzQ9JTi7/XYXrIt1Ma++iBgovuJ0/qHWEDfvzUr60EhgFhPPt0Zq vOZwFH4b3l9YJ4EoPOYyIQ2B3J3wTap+gkUGkXMt1ht5sFHY1HqFgUlmP Eko9aclCivZ60wwrBpNAH1VT7sV578xP3deCDlGiQWM/S3waK8crNs3kR Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B4AQAfCBxY/5xdJa1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgy4BAQEBAR+BW40xlwCUR4IIhiMCGoFwPxQBAgEBAQEBAQFiKIRhAQE?= =?us-ascii?q?BAwEjEUUFCwIBCA4MAiYCAgIwFRACBAENDQyIPAiuXY0NAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBHIEJhTaEVYRegm2CXAEElEKFXwGQNZARkSIBHjdrhR+HWoEMAQE?= =?us-ascii?q?B?= X-IronPort-AV: E=Sophos;i="5.31,442,1473120000"; d="scan'208";a="169519625" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Nov 2016 04:05:53 +0000 Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id uA445sUl018422 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 4 Nov 2016 04:05:54 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 3 Nov 2016 23:05:53 -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; Thu, 3 Nov 2016 23:05:53 -0500 From: "Jakob Heitz (jheitz)" To: Geoff Huston , IETF IDR WG Thread-Topic: [Idr] Review of draft-ietf-large-community-06.txt Thread-Index: AQHSNjBz6sRcMeSZxEiIR579im5tsaDIMk6A Date: Fri, 4 Nov 2016 04:05:53 +0000 Message-ID: <288c77155de540adbdb60d8587b9f39b@XCH-ALN-014.cisco.com> References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com> <117ea01d23611$a28513e0$e78f3ba0$@ndzh.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: [10.24.32.83] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "rtg-dir@ietf.org" , Susan Hares Subject: Re: [Idr] Review of draft-ietf-large-community-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: Fri, 04 Nov 2016 04:06:04 -0000 VG8gZXhwbGFpbiB0aGlzIG9uZSwgaXQgd2FzIG9yaWdpbmFsbHkgIlRleHR1YWwgUmVwcmVzZW50 YXRpb24iDQphbmQgaXQgd2FzIHdpdGggY29sb25zIG9ubHkuIFRoZW4gd2UgZGlzY292ZXJlZCB0 aGF0IEJpcmQgdXNlcw0KY29tbWFzIGFzIGEgc2VwYXJhdG9yLiBTaW5jZSB0aGF0IGRvZXMgbm90 IGRlZ3JhZGUgdGhlIHV0aWxpdHksDQp3ZSBhbGxvd2VkIGl0LiBUaGUgcmVhbCBwb2ludCBpcyB0 aGF0IGl0IGhhcyB0byBiZSBleGFjdGx5DQozIHBvc2l0aXZlIGRlY2ltYWwgaW50ZWdlcnMuIElm IHNvbWUgaW1wbGVtZW50YXRpb25zIG9ubHkgb2ZmZXJlZCBoZXhhZGVjaW1hbA0Kb3IgdXNlZCA2 IGludDE2J3MgdGhlbiBpdCB3b3VsZCBiZWNvbWUgdmVyeSBkaWZmaWN1bHQgZm9yIElTUHMNCnRv IGNvbW11bmljYXRlIGNvbW11bml0eSBzZXR0aW5ncyB0byBjdXN0b21lcnMuDQpJIGNhbiBjaGFu Z2UgaXQgdG8gYSBzaW5nbGUgcmVwcmVzZW50YXRpb24gYW5kIGRldGFpbCB0aGUgYWxsb3dlZA0K ZGV2aWF0aW9ucyBmcm9tIGl0Lg0KDQpKYWtvYi4NCg0KDQo+IDQuICBDYW5vbmljYWwgUmVwcmVz ZW50YXRpb24NCj4gDQo+IEkgYW0gY29uZnVzZWQgaGVyZSAtIHRoaXMgc2VjdGlvbiB1c2VkIGFu IGV4YW1wbGUgd2l0aCBUV08gY2Fub25pY2FsDQo+IHJlcHJlc2VudGF0aW9uczoNCj4gDQo+ICAg ICJGb3IgZXhhbXBsZTogNjQ0OTY6NDI5NDk2NzI5NToyLCA2NDQ5NjowOjAsIG9yICg2NDQ5Niwg MTExLCAyMjIpLiINCj4gDQo+IA0KPiBDb252ZW50aW9uYWxseSwgaXQncyBiZXR0ZXIgdG8gdXNl IGEgc2luZ2xlIGNhbm9uaWNhbCByZXByZXNlbnRhdGlvbiwgc28gdGhlDQo+IGF1dGhvcnMgc2hv dWxkIHBpY2sgZWl0aGVyIGEgY29sb24tZGVsaW1pdGVkIGxpc3QsIG9yIGEgYnJhY2tldGVkIGNv bW1hK3NwYWNlDQo+IHNlcGFyYXRlZCBvYmplY3QuDQo= From nobody Fri Nov 4 00:56:38 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38546129436; Fri, 4 Nov 2016 00:56:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.432 X-Spam-Level: X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_SOFTFAIL=0.665] 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 rXrkPpgyGzTk; Fri, 4 Nov 2016 00:56:27 -0700 (PDT) Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (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 BAAA5129407; Fri, 4 Nov 2016 00:56:26 -0700 (PDT) Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1c2ZMK-0008p6-9B (job@us.ntt.net); Fri, 04 Nov 2016 07:56:21 +0000 Date: Fri, 4 Nov 2016 08:56:14 +0100 From: Job Snijders To: Geoff Huston Message-ID: <20161104075614.GU961@Vurt.local> References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com> <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com> <20161104004725.GC17584@shrubbery.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.1 (2016-10-04) Archived-At: Cc: heasley , IETF IDR WG , Susan Hares , rtg-dir@ietf.org Subject: Re: [Idr] Review of draft-ietf-large-community-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: Fri, 04 Nov 2016 07:56:33 -0000 Dear Geoff, Thank you for your time and review. On Fri, Nov 04, 2016 at 12:25:08PM +1100, Geoff Huston wrote: > > On 4 Nov. 2016, at 11:47 am, heasley wrote: > > > >> 7. ---------------- > >> > >> 4. Canonical Representation > >> > >> I am confused here - this section used an example with TWO canonical > >> representations: > >> > >> "For example: 64496:4294967295:2, 64496:0:0, or (64496, 111, 222)." > >> > >> Conventionally, it's better to use a single canonical > >> representation, so the authors should pick either a colon-delimited > >> list, or a bracketed comma+space separated object. > > > > Are you sure; a separator is not defined in the text. > > If the “Canonical Representation†is to represent the Large > Communities Attributes value as a sequence of triplets, where the > triplet is three unsigned decimal values, but not to define the > representation of the delimiter between the elements of the triplet, > nor the delineator between successive triplets, then I think that this > is an incomplete canonical representation. The working group has debated long and furiously on this element of the text. In the end we ended up with the text without specifying a separator because the separator isn't what is important at all. The 'Canonical Representation' section came to be because we want to prevent a 'asdot vs asplain'-style time waste. It should be clear that each Large Community is composed of three fields, separated by something. If you read network documentation from another party and they reference "111:333:555" it should be clear it is a Large community; even if your router makes you type in "(111, 333, 555)". Or maybe your router solely consumes XML or JSON as configuration: [111, 333, 555]. It was a conscious choice to make the representation liberal enough that all implementors currently at the table felt comfortable with it, and that the operators at the table also have guidance on what the large community will look like in communication. Given the above context, do you have a suggestion other then "pick eiher a colon-delimited or bracketed"? My personal preference would be to keep the original text. Kind regards, Job From nobody Fri Nov 4 02:00:08 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28EA2129513 for ; Fri, 4 Nov 2016 02:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.398 X-Spam-Level: X-Spam-Status: No, score=-108.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 8QX23JlK83av for ; Fri, 4 Nov 2016 02:00:03 -0700 (PDT) Received: from nx-mailgw.apnic.net (nx-mailgw.apnic.net [IPv6:2001:dd8:9:801::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A97D1294F1 for ; Fri, 4 Nov 2016 02:00:02 -0700 (PDT) Received: from iamda3.org.apnic.net (unknown [2001:dd8:9:2::101:249]) by nx-mailgw.apnic.net (Halon) with ESMTPS id 0eec55a1-a26d-11e6-b23e-005056b685e3; Fri, 04 Nov 2016 18:59:56 +1000 (AEST) Received: from dhcp150.potaroo.net (203.119.101.249) by iamda3.org.apnic.net (203.119.111.31) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 4 Nov 2016 18:59:58 +1000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Geoff Huston In-Reply-To: <4080cfba032744f590fcbbb710f0d618@XCH-ALN-014.cisco.com> Date: Fri, 4 Nov 2016 19:59:57 +1100 Content-Transfer-Encoding: quoted-printable Message-ID: <08C97932-4E8B-4EBC-B780-3A2F54A1EEF2@apnic.net> References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com> <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com> <4080cfba032744f590fcbbb710f0d618@XCH-ALN-014.cisco.com> To: "Jakob Heitz (jheitz)" X-Mailer: Apple Mail (2.3251) Archived-At: Cc: IETF IDR WG , Susan Hares , "rtg-dir@ietf.org" Subject: Re: [Idr] Review of draft-ietf-large-community-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: Fri, 04 Nov 2016 09:00:06 -0000 > On 4 Nov. 2016, at 2:54 pm, Jakob Heitz (jheitz) = wrote: >=20 > Thanks Geoff, I'll fix them. >=20 > One thing about the aggregation. > I first had the condition "do not include the ATOMIC_AGGREGATE". > Then someone commented on the list that ATOMIC_AGGREGATE was dead. > I reviewed the function of ATOMIC_AGGREGATE and what our code does. > ATOMIC_AGGREGATE means that information was lost by aggregation. > In our code (and other code that I have worked on), when we > aggregate, we always add the ATOMIC_AGGREGATE attribute. > There is no case when we aggregate without adding the ATOMIC_AGGREGATE > attribute. Being of no consequence, I removed that part of the text. > I mean, the text tells you how to aggregate if the ATOMIC_AGGREGATE > is absent, but says nothing about how to aggregate if it's present. >=20 > Personally, I'm fine either way. It will not change any code I write. >=20 I just noted that RFC1997 and RFC4360 had these constraints. It seems strange to me that an implementation would handle aggregation = differently, treating communities and extended communities one way and = large communities in a subtly different manner. Frankly I would prefer to see a consistent treatment of communities in = the case of aggregation, and reproducxing the RFC4360 text kinda makes = that clear (at least to me) Omitting it invites different handling and that would be not good Geoff =20= From nobody Fri Nov 4 02:04:56 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAF9C12951F for ; Fri, 4 Nov 2016 02:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.398 X-Spam-Level: X-Spam-Status: No, score=-108.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 KS8YRhwUkeCH for ; Fri, 4 Nov 2016 02:04:53 -0700 (PDT) Received: from nx-mailgw.apnic.net (nx-mailgw.apnic.net [IPv6:2001:dd8:9:801::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2523129417 for ; Fri, 4 Nov 2016 02:04:52 -0700 (PDT) Received: from iamda3.org.apnic.net (unknown [2001:dd8:9:2::101:249]) by nx-mailgw.apnic.net (Halon) with ESMTPS id bbdf8939-a26d-11e6-b23e-005056b685e3; Fri, 04 Nov 2016 19:04:47 +1000 (AEST) Received: from dhcp150.potaroo.net (203.119.101.249) by iamda3.org.apnic.net (203.119.111.31) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 4 Nov 2016 19:04:48 +1000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Geoff Huston In-Reply-To: <288c77155de540adbdb60d8587b9f39b@XCH-ALN-014.cisco.com> Date: Fri, 4 Nov 2016 20:04:47 +1100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com> <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com> <288c77155de540adbdb60d8587b9f39b@XCH-ALN-014.cisco.com> To: "Jakob Heitz (jheitz)" X-Mailer: Apple Mail (2.3251) Archived-At: Cc: IETF IDR WG , Susan Hares , "rtg-dir@ietf.org" Subject: Re: [Idr] Review of draft-ietf-large-community-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: Fri, 04 Nov 2016 09:04:55 -0000 >> 4. Canonical Representation >>=20 >> I am confused here - this section used an example with TWO canonical >> representations: >>=20 >> "For example: 64496:4294967295:2, 64496:0:0, or (64496, 111, 222)." >>=20 >>=20 >> Conventionally, it's better to use a single canonical representation, = so the >> authors should pick either a colon-delimited list, or a bracketed = comma+space >> separated object. > On 4 Nov. 2016, at 3:05 pm, Jakob Heitz (jheitz) = wrote: >=20 > To explain this one, it was originally "Textual Representation" > and it was with colons only. Then we discovered that Bird uses > commas as a separator. Since that does not degrade the utility, > we allowed it. The real point is that it has to be exactly > 3 positive decimal integers. If some implementations only offered = hexadecimal > or used 6 int16's then it would become very difficult for ISPs > to communicate community settings to customers. > I can change it to a single representation and detail the allowed > deviations from it. >=20 if you make a canonical a SHOULD not a MUST then you can permit = variation without breaking the standard. So what you are saying is that the canonical representation of a single = Large Community value is three unsigned decimal integer values, separated by a =E2=80=98:=E2=80=99= (colon) character, representing=20 the value as a triplet of unsigned 32-bit integer values. = Implementations SHOULD accept this representation as a valid form of representation of the value of a Large = Community. From nobody Fri Nov 4 02:10:36 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89372129519 for ; Fri, 4 Nov 2016 02:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.398 X-Spam-Level: X-Spam-Status: No, score=-108.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 QiSn1LbJDfpd for ; Fri, 4 Nov 2016 02:10:29 -0700 (PDT) Received: from ia-mailgw.apnic.net (ia-mailgw.apnic.net [IPv6:2001:dd8:a:851::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CEED129417 for ; Fri, 4 Nov 2016 02:10:28 -0700 (PDT) Received: from nxmda2.org.apnic.net (unknown [2001:dd8:9:2::101:249]) by ia-mailgw.apnic.net (Halon) with ESMTPS id 85ae3b11-a26e-11e6-a41e-005056b6f213; Fri, 04 Nov 2016 19:10:25 +1000 (AEST) Received: from dhcp150.potaroo.net (203.119.101.249) by NXMDA2.org.apnic.net (203.119.107.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 4 Nov 2016 19:10:06 +1000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Geoff Huston In-Reply-To: <20161104075614.GU961@Vurt.local> Date: Fri, 4 Nov 2016 20:10:23 +1100 Content-Transfer-Encoding: quoted-printable Message-ID: <8F8E9266-DAD3-48A7-BFFE-7CE8C103C529@apnic.net> References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com> <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com> <20161104004725.GC17584@shrubbery.net> <20161104075614.GU961@Vurt.local> To: Job Snijders X-Mailer: Apple Mail (2.3251) Archived-At: Cc: heasley , IETF IDR WG , Susan Hares , rtg-dir@ietf.org Subject: Re: [Idr] Review of draft-ietf-large-community-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: Fri, 04 Nov 2016 09:10:31 -0000 > On 4 Nov. 2016, at 6:56 pm, Job Snijders wrote: >=20 > Dear Geoff, >=20 > Thank you for your time and review. >=20 > On Fri, Nov 04, 2016 at 12:25:08PM +1100, Geoff Huston wrote: >>> On 4 Nov. 2016, at 11:47 am, heasley wrote: >>>=20 >>>> 7. ---------------- >>>>=20 >>>> 4. Canonical Representation >>>>=20 >>>> I am confused here - this section used an example with TWO = canonical >>>> representations: >>>>=20 >>>> "For example: 64496:4294967295:2, 64496:0:0, or (64496, 111, = 222)." >>>>=20 >>>> Conventionally, it's better to use a single canonical >>>> representation, so the authors should pick either a colon-delimited >>>> list, or a bracketed comma+space separated object. >>>=20 >>> Are you sure; a separator is not defined in the text. >>=20 >> If the =E2=80=9CCanonical Representation=E2=80=9D is to represent the = Large >> Communities Attributes value as a sequence of triplets, where the >> triplet is three unsigned decimal values, but not to define the >> representation of the delimiter between the elements of the triplet, >> nor the delineator between successive triplets, then I think that = this >> is an incomplete canonical representation. >=20 > The working group has debated long and furiously on this element of = the > text. In the end we ended up with the text without specifying a > separator because the separator isn't what is important at all. >=20 > The 'Canonical Representation' section came to be because we want to > prevent a 'asdot vs asplain'-style time waste. It should be clear that > each Large Community is composed of three fields, separated by > something. If you read network documentation from another party and = they > reference "111:333:555" it should be clear it is a Large community; = even > if your router makes you type in "(111, 333, 555)". Or maybe your = router > solely consumes XML or JSON as configuration: [111, 333, 555]. >=20 > It was a conscious choice to make the representation liberal enough = that > all implementors currently at the table felt comfortable with it, and > that the operators at the table also have guidance on what the large > community will look like in communication. >=20 > Given the above context, do you have a suggestion other then "pick = eiher > a colon-delimited or bracketed"? My personal preference would be to > keep the original text. >=20 I think you make a clear SHOULD support for a particular representation = of the triplet, which makes other representations still ok, but there is a = clear preference for interoperability that says =E2=80=9Cclearly state a preferred format = for representating these values". My previous response to Jakob proposes some candidate text. regards, Geoff From nobody Fri Nov 4 03:31:46 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA5E1129BDE; Fri, 4 Nov 2016 03:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, 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 GDyHVB6NWaTq; Fri, 4 Nov 2016 03:31:43 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id D64C212947D; Fri, 4 Nov 2016 03:31:43 -0700 (PDT) Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id 0A4F01E369; Fri, 4 Nov 2016 06:34:18 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Jeffrey Haas In-Reply-To: <8F8E9266-DAD3-48A7-BFFE-7CE8C103C529@apnic.net> Date: Fri, 4 Nov 2016 06:31:42 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <50FBB9EC-F6C7-408E-A544-9D64E86E8293@pfrc.org> References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com> <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com> <20161104004725.GC17584@shrubbery.net> <20161104075614.GU961@Vurt.local> <8F8E9266-DAD3-48A7-BFFE-7CE8C103C529@apnic.net> To: Geoff Huston X-Mailer: Apple Mail (2.3251) Archived-At: Cc: heasley , IETF IDR WG , rtg-dir@ietf.org, Sue Hares Subject: Re: [Idr] Review of draft-ietf-large-community-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: Fri, 04 Nov 2016 10:31:45 -0000 > On Nov 4, 2016, at 5:10 AM, Geoff Huston wrote: >=20 >=20 >> On 4 Nov. 2016, at 6:56 pm, Job Snijders wrote: >> Given the above context, do you have a suggestion other then "pick = eiher >> a colon-delimited or bracketed"? My personal preference would be to >> keep the original text. >>=20 >=20 > I think you make a clear SHOULD support for a particular = representation of the > triplet, which makes other representations still ok, but there is a = clear preference > for interoperability that says =E2=80=9Cclearly state a preferred = format for representating > these values". I believe the intent of saying it's an ordered tuple of Global Admin, = Local Admin 1, Local Admin 2 is sufficient. If you want to define delimiters, go write a yang module. -- Jeff From nobody Fri Nov 4 03:34:40 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E30612954D; Fri, 4 Nov 2016 03:34:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.497, 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 W4s-8mdk7o6J; Fri, 4 Nov 2016 03:34:28 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA9A12952F; Fri, 4 Nov 2016 03:34:28 -0700 (PDT) Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id A96621E369; Fri, 4 Nov 2016 06:37:03 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_6D25885C-CB98-4BB6-807B-F86B267219A0" Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Jeffrey Haas In-Reply-To: <08C97932-4E8B-4EBC-B780-3A2F54A1EEF2@apnic.net> Date: Fri, 4 Nov 2016 06:34:27 -0400 Message-Id: References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com> <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com> <4080cfba032744f590fcbbb710f0d618@XCH-ALN-014.cisco.com> <08C97932-4E8B-4EBC-B780-3A2F54A1EEF2@apnic.net> To: Geoff Huston X-Mailer: Apple Mail (2.3251) Archived-At: Cc: IETF IDR WG , Sue Hares , "rtg-dir@ietf.org" Subject: Re: [Idr] Review of draft-ietf-large-community-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: Fri, 04 Nov 2016 10:34:35 -0000 --Apple-Mail=_6D25885C-CB98-4BB6-807B-F86B267219A0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Nov 4, 2016, at 4:59 AM, Geoff Huston wrote: >=20 > I just noted that RFC1997 and RFC4360 had these constraints. >=20 > It seems strange to me that an implementation would handle aggregation = differently, treating communities and extended communities one way and = large communities in a subtly different manner. >=20 > Frankly I would prefer to see a consistent treatment of communities in = the case of aggregation, and reproducxing the RFC4360 text kinda makes = that clear (at least to me) >=20 > Omitting it invites different handling and that would be not good The relevant point from the thread is that the atomic-aggregate = attribute is largely protocol noise. It's a vestigial organ from the = BGP-3 to BGP-4 transition, and a poorly specified one at that. We = shouldn't include its use in specifications, particularly where = discussing aggregation. The only place its discussion would be relevant is as part of = *de-*aggregation of a prefix. -- Jeff --Apple-Mail=_6D25885C-CB98-4BB6-807B-F86B267219A0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Nov 4, 2016, at 4:59 AM, Geoff Huston <gih@apnic.net> = wrote:

I just noted that RFC1997 and RFC4360 had these = constraints.

It seems strange to = me that an implementation would handle aggregation differently, treating = communities and extended communities one way and large communities in a = subtly different manner.

Frankly I would prefer to see a consistent = treatment of communities in the case of aggregation, and reproducxing = the RFC4360 text kinda makes that clear (at least to me)

Omitting it invites different handling = and that would be not good

The relevant point from the thread is that = the atomic-aggregate attribute is largely protocol noise.  It's a = vestigial organ from the BGP-3 to BGP-4 transition, and a poorly = specified one at that.  We shouldn't include its use in = specifications, particularly where discussing aggregation.

The only place its = discussion would be relevant is as part of *de-*aggregation of a = prefix.

-- = Jeff

= --Apple-Mail=_6D25885C-CB98-4BB6-807B-F86B267219A0-- From nobody Fri Nov 4 06:14:04 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51FC1129439 for ; Fri, 4 Nov 2016 06:14:03 -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_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=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 nxs0IGfpmUW1 for ; Fri, 4 Nov 2016 06:14:00 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0107.outbound.protection.outlook.com [104.47.1.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F1B212949A for ; Fri, 4 Nov 2016 06:14:00 -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=ChfFaZOtqS++RJk0Kvd1uvbmqfaiGVH8RKqhxrtKB5Q=; b=AkfbRL6czJJgOn30SkxO6dDRmnQ+IZhlxXikIQJ6UGNy5BLIEMXsKwKNhWL3j2UkSYJwwB8qlqY9sjuynnd04OvwYvwaAz7BwyOndvH4DEB5/1n9rFbT8lJwqAzOTWOPDAtqhBcokOw5rBDbk21xnM8QfkLs9NdGtfuSVrm0t/E= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (81.135.210.62) by AM5PR0701MB2993.eurprd07.prod.outlook.com (10.168.156.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.721.4; Fri, 4 Nov 2016 13:13:57 +0000 Message-ID: <050f01d2369c$e82e1d20$4001a8c0@gateway.2wire.net> From: t.petch To: Susan Hares , "'John G. Scudder'" , 'Robert Raszuk' References: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> <20161101133240.GK1581@hanna.meerval.net> <2393790D-F279-41ED-B5B2-E427C60B4926@juniper.net> <034a01d23639$fa2c78e0$ee856aa0$@ndzh.com> Date: Fri, 4 Nov 2016 13:10:30 +0000 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: [81.135.210.62] X-ClientProxiedBy: DB4PR02CA0036.eurprd02.prod.outlook.com (10.242.174.164) To AM5PR0701MB2993.eurprd07.prod.outlook.com (10.168.156.143) X-MS-Office365-Filtering-Correlation-Id: 71fafaf2-6f91-42fd-7e08-08d404b46fab X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2993; 2:/bcYGCCtme4VszfasoefwzquJ9KbWAjxUzKzIon8z9hb1Z49+7Umpx64T0zxM5KkLiBHghA6bowMDqb6CY6tBb6ljbukslCB1iU+ONhcZ6rzheqtA+U1Smt8hGw8m52mM+LyttQV5eONNUTP8HLZ+rvpWrs6oc2JXwBfOgk+YOuWfPX4gxM+78GizOqD00pIXWkWsN6m9UCiMxbnQYaT6A==; 3:5jXA+FI+nzFE+2l3/QPhwaQ+r8HEHId8cz1nsVr6LXs84QURW0fJMTPPUYaM7nhbuvFWU8drgY+WkaDBsdm8R2yUmHOU3OmiEaJTlcLt6YOInVR01WYw5anBBEnRtTINO3R4SZ6qBd+3wzUZfgu6ug==; 25:sb7A3teRlUJC3qzkM0O2Ads11FiKVai0bmN5es0bpRvWAWIyXeCVh51jZgNoVIs5m4Jl4MP3VMOTZ80njMKmN2oLb4V4nW7YVIHutqlZIitNm+kC+o63yluVo90whSg9JOWDBWUvlmc7JGTwDd7yuPhW05c/VB9PjCZvwUL99lSq6GeqT43IlAEWUNgVxWSBCVhXfuD0T2Yssni/22MZMXvibo/SbmcPY5c6ZO4OXSii/CXV1QdVBhru/5JV+zpTU6Z2TJ5qvOXAfUcpKksl1bKKXUrTmgzeSoDwbDU7T/q9aJf07Z52HMV5c8p5LzdRqTz+NYgANNkZRryh9md/yTRBoracFpAdtbyyJGTAoNoVeNAjAanF+bx9Vdg/JjLPXeEFerGyjAMl9Xs+nJCaoW4vPh8FYn+zB8bZapiUFN0= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM5PR0701MB2993; X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2993; 31:Pi8+YhqbQEGThnqUj29rsZDrttUaRNW4kVnfF9Q53XtmLl0UNx88b0g9tt0JZrUVqca6KVsegL5gtaeqSQNJ52pnzSevRaJRHRiwppd54pxIG5SIFmpl/2A2ZaxjDirVACmg5ZV18E5wzhys8Xghy6wRYu7/3hKECwytD+e8ZkSsyZ0YXqZtuiA0kgoVlgra6HQAiGaO2VOPuPpJ+YYralyFr3cdof60uNTxfIiGp+YtJ+JjvY6DNldLEZgW7VYp7YVmzU/8YbN7TBvcHFx9nQ==; 4:8qtHS1h0OMswVutQSbhw/AbIyOzsMmeXMLp3Y8U3Cf0c0qry71lYTa7jogqL84+Q/vtKnR1aFme57mFuRZ7pbEfmR6qBKtys/iSmks+/L6zGAhYQUWGyatiWj9WuirhKw4pDa+Umn4wUG6zzuGG+8AT+OUUmlAvFdZfIuFCZvYwGgY2nKpuObfxeqHiGy2/S8aJWCnhYRGQggoKtF6KaWKavSKpIwp9LceSBJnmNUf0zQV+9zoY5KhlIwgZIcfqR3sqoI6fx9Tl90ehm6srhhhScj99NWPbXO7LZLIoOaD9AU2pfyGINngfWIb+uGUpTS8Hoi0txbHE//2ceV7pnXtSBxtJwQWCJJ3hzylkM1+7uWcOWItXN9DIgYShR+puy+b+JcNqWyWy8SO+In50xOQt4Wdj1kwwxN+pwlfjmfOQZ4+PnTfsYewN2DMtMo9taQz3Km1VJNArCRmUP+ymxpfRLzkP2qcbyR8O7iVcVzpw= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(278428928389397)(138986009662008); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:AM5PR0701MB2993; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2993; X-Forefront-PRVS: 01165471DB X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(13464003)(199003)(5423002)(189002)(24454002)(377454003)(76104003)(53754006)(9686002)(5001770100001)(14496001)(15975445007)(77096005)(23756003)(1556002)(1456003)(50226002)(86362001)(68736007)(42186005)(61296003)(105586002)(106356001)(5660300001)(97736004)(230700001)(92566002)(47776003)(66066001)(44716002)(586003)(3846002)(62236002)(50986999)(81686999)(50466002)(81816999)(101416001)(76176999)(33646002)(93886004)(6116002)(6666003)(8676002)(44736004)(19580405001)(19580395003)(230783001)(1941001)(84392002)(189998001)(4326007)(2906002)(81166006)(81156014)(8666005)(4720700003)(305945005)(7736002)(7846002)(116806002)(74416001)(7059030)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2993; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; AM5PR0701MB2993; 23:xdsc2TqKvKbGODa26Ps1Fq+366zY5KPcdIsEI?= =?iso-8859-1?Q?qvc3u1r8cgqGvU3fPyJJBzHS5TWYisT0i1mL8lvBPBepxN7gk6INCgjw7h?= =?iso-8859-1?Q?hbptcguMIrJbaAAJ6C0g8teiif+Baxo9SNIvOSe0xocKjF9fAZbBYh4/9z?= =?iso-8859-1?Q?uDlhp4vXf0zC6l2jkg5/EDetGtQnE4IMBrlnTe6A6l1w7KW9N02Xmh15QA?= =?iso-8859-1?Q?EULtms/Xz0JbNc9Q+GofTIFs0UkstIy5+vxcXgb/dIDJGwR3g7/35FxlZy?= =?iso-8859-1?Q?59tDu6X2xUOXeuzNEdlWWbvWn+HxDS9hatEyLoQDcievDIy82hKhwjRQZc?= =?iso-8859-1?Q?Ra2yYDj61CCTNlNKchD9sGRIj3XAjPNGgB8lEdg4tqFFdexrdfNev0FAWJ?= =?iso-8859-1?Q?kJoS5j+k8TDLRgTnnd2yu6Jg8kKjMC9mqmTClg0zScxQFZrvXVzYcXK5j+?= =?iso-8859-1?Q?JUyxlYt3T83triUt+yIrBvsQ7uN0YJulUZx9eN1re3BVxiESwdryIR26h0?= =?iso-8859-1?Q?CoRoe7LEux1/lvm2hv80mofoKTe9DITyAYqQSQ+wKQwfJPIe7+jDp6uZFg?= =?iso-8859-1?Q?vXWVf0g9YMzqAyklBRw/mvHAFecOnW2p+dKDCuX7PxQ4eAdPJfz8Wp2C85?= =?iso-8859-1?Q?8fPO98CqH+62z7L4q8d30Y4BR/9cukrAI5u2OkDWoXBeb+4e9XTPtgTvTa?= =?iso-8859-1?Q?f2gLBbmx1VsQqASa7QuEdZdtAWNjUUQH1udpe7MjPG5diW4t4HywgB6QbS?= =?iso-8859-1?Q?AXqlS5SN/1Nxmk8FdSm7KkrzXkLwVVQ3y0QZOZ4Y6Iviy8foj9Mlz0SGdV?= =?iso-8859-1?Q?JkWqCWOfHQareBDMQog1M/w5Jv+LVykjQuUXPCWcbcCU5f4mB1J+CbYJFD?= =?iso-8859-1?Q?lMmvZkSsOfnnhR6RPpgpI3gxc1Gx04jBnTbBhKq5mSmh6tAmSNZhJgjoWP?= =?iso-8859-1?Q?VpKMSg0X2BvlojMhPW0Z6uz8WFnhWX1kHwbJDveUE3MFIe1Ur1sl2oow70?= =?iso-8859-1?Q?qIHy8Vmz47ZiXFJB2rP4ytJEYGm0F+hNoK6iPPtdfpsVWfikfRguMQRU4Z?= =?iso-8859-1?Q?ZIwDdn6a2ss/b9yneybJtwH65t99IYKgltMm5/CmmPwR9Cytc6lpM3v3BU?= =?iso-8859-1?Q?xCdwQWGo0f8xwMCNV5ryG+4fwRWCpwZfVly859qRd2hIVeHeJ/6IAz4j+r?= =?iso-8859-1?Q?XGR8kIR2fVZYDRqkEvIoKQnlu/aRCpAzOFScWv1HZ4KddRdldg0Y1y+8Qs?= =?iso-8859-1?Q?MDesXBpYWyUx2zSBKBn5Uz+fyUtd3S3kLNZQmT86zPc9zzBlkZ6RolNUQR?= =?iso-8859-1?Q?IEq8A3+qLlhGc1AKG/+uMpbWqW+P9HKZ4nbiBde79HvnvuQzOkrDq1Jlr9?= =?iso-8859-1?Q?oAH/1SYpWIfpTA1NAxhFGhJmqqW994YBbNAL3yHlkUIuca+hN1V9fwzTPw?= =?iso-8859-1?Q?TDPgCKh6c3hXKu3hEALBCBYd2hhnLfaKS48LWIS9kuRGCiWOefxr91/WiH?= =?iso-8859-1?Q?46+OXi4dqRVUm7YjTR+3Qywrk2VNsJcGgemAR4qCajSnbrMZJHnD+tt35u?= =?iso-8859-1?Q?Eyd/QR8QfJnfmabu3Q/3wzJpioTcHR10sTBpElrEbm37CWk0Bt28v7WvND?= =?iso-8859-1?Q?EcN3X5JVw2gePD4mXDbJZXwuvcprSpGA4AfdAh0jwFXyLwfia9XEBLz?= X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2993; 6:1GESKLvCezwU6KAob401F2sFkJXyle7jnsuvMwUGXMl2vOLT5ruMbfkQwEoj86Qm8kibxDVOxq4iVnmVisKDQErvT3j5uBJt+lDleVyg+zDYomwJooIm71qHnlZLzkGo97w3I4uEG+QAbFZU+anwjvzTIK++tbuP7lav0T4S63LMm4t6VWgEbz9ZdXiVgrT+/6Nr2+NIIDITDfA+RTYb4Yp5ifGl/Jg9n69QYCxKfl53ylGveu9qcApQ+VslLzpp6Viv3CCazzCbTsaCPu3fl6NAakvNTuvDinyDkTJupCLxKsw7WlM5v64onBVKxikf; 5:97ivSS7uqaArfrTlhpL6qAtD/tuS29+yRb86XvKq9pVVPtMwLhE8y9wtkh6StQ07sE7CKkviHfK6CoF/AA1C22otdayeH/G2fctXf9Hy4HrnrhC9ZX9BT9bPs1fmkEINHvWbhPGU2V1J8rfPYZRMeclxEfLGYPnpf93lmPZV73U=; 24:shvAu9VkOPymD8gtpIRtDUjfYzAo3V/MWH8WfGzHkE+qJyDckM+Gvr0LDhN+R5XzfNFctNIErl7oT8u+2oJBO4nO6/Tq4PhNxvlLgAh7weQ= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2993; 7:8sKEmjKri+dhZ2jdafLITWvNGzTNMOzt522fNpVEOkFOY/0e1vQnite6hD2fTaBZICw0Y0hSg6axjW5mi2A0w0UbuZVg4IVpO0xGyuZdpJiTXgDP7NdDrcHQse7I2wg4YUUq6F58CTQWLrNFC7IPB5MGECyuxBMTrQXARgjaRfhpmvytDpBZNXOFb7wkxKOD1x2vQD1wa40e6IX/0RJbH+i/SDKd24h5/YY0jaFRWTF2KIKl8ITNxXeRk9CmahWdOIqswphpUpMUfLJJCjjDHg/LHkjVqSX4cfmScRBq2WQvi7XuH19pQASsBJ179adVnQOK43DC7pD9DOEmrai4nUCsRpZkr45SusgNYZTj41A= X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Nov 2016 13:13:57.4902 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2993 Archived-At: Cc: 'IETF IDR Working Group' Subject: Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129 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, 04 Nov 2016 13:14:03 -0000 ----- Original Message ----- From: "Susan Hares" To: "'John G. Scudder'" ; "'Robert Raszuk'" Cc: "'IETF IDR Working Group'" Sent: Friday, November 04, 2016 1:22 AM > John: > > My understanding with the IESG and IANA is that this is true. The best > reference is the BIS for RFC226bis below: > > https://tools.ietf.org/html/draft-leiba-cotton-iana-5226bis-11 > > The RFC5226bis-11.txt got stalled due to the IESG wandering if the revision > is needed. Based on our experience, I think it is needed. Alvaro will kick > off this work, but the process of updating a "process" document should not > impede this document's process. We need to think outside the box. > > I suggest we complete this adoption of > draft-snijders-idr-deprecate-30-31-129 draft by 11/13/2016, and do a WG LC > on the draft directly following this process draft (11/14 to 11/28). This > should allow the draft-idr-large-communities to have the necessary registry > "glue" ready so the IESG publication of large communities can go quickly. Sue The reason I am being a bit 'snarky' on this adoption call is my concern that there may be differing views of what 'deprecate' means. For example, the SMI world gives it a different (and IMO unsuitable) meaning which some on this list will know. Even the 5226bis text might not be quite right. Robert did query whether or not 'deprecate' was suitable. If we take 5226bis as gospel, then 'deprecate' is probably the option to choose but I wish that there were more alternatives. I was about to post to the main IETF list and Terry Mandelson(as responssible AD) about 5226bis (again:-) but the list has erupted with a discussion about DMARC(again) so I will hold off and see what develops. Tom Petch > > > > Sue > > > > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of John G. Scudder > Sent: Tuesday, November 1, 2016 10:24 AM > To: Robert Raszuk > Cc: IETF IDR Working Group > Subject: Re: [Idr] Working group adoption call for > draft-snijders-idr-deprecate-30-31-129 > > > > AFAICT the function of the draft is simply to kick the IANA code point state > to "deprecated". It doesn't anchor it there for all time. Presumably a later > request can move the state to assigned or whatever, as we've previously > discussed. I don't think any update to the current "deprecate" document > would be needed to achieve this (I guess maybe the later document might list > this one in its "updates" header). > > > > I'll confirm this understanding with IESG and IANA before the end of the WG > adoption call. (Unless someone can point me to chapter-and-verse of a > reference that explains the process clearly enough, unfortunately I have not > found such.) > > > > Thanks, > > > > --John > > > > On Nov 1, 2016, at 10:02 AM, Robert Raszuk wrote: > > > > Hi Job, > > > > Have you consider marking those codepoints as "RESERVED" rather then > "DEPRECIATED". > > > > Reason being that if any of the applications they have been squatted on > behalf of want to use them - it would be pretty easy to allocate them. > > > > The other alternative would be to allocate them to those applications now > (for which the drafts exist) as IANA early allocations. If you depreciate > them now and we know that as example Contrail Multicast is important either > your draft will need to quickly be moved to historic or yet another types > will need to be allocated again. > > > > In any of the above Large Communities will get virgin BGP attribute type > which I believe is the main point here. > > > > Cheers, > > R. > > > > > > On Tue, Nov 1, 2016 at 2:32 PM, Job Snijders wrote: > > Dear working group, > > To prevent having multiple drafts in quick succession covering the same > style of issue - I'd like your feedback on the following: > > I believe that bgp path attribute 241, 242, 243 should also be added to > this draft for the same reasons as 30, 31 and 129 are listed. > > OLD: > This document requests IANA to deprecate the following BGP Path > attributes: 30, 31, and 129. > > NEW: > This document requests IANA to deprecate the following BGP Path > attributes: 30, 31, 129, 241, 242, and 243. > > Does anyone object? If so, why? > > Unilaterally changing the document while in its mid-flight through the > working group adoption process might be considered bad form, hence my > request for feedback on the 241,242,243 topic. > > Please note - the deprecation of an attribute can be undone if proper > process is followed. The priority here is to prevent IANA from assigning > tainted codepoints to innocent bystanders, thus a deprecation document > needs to exist. In time the working group has the power to undeprecate > them for specific purposes. > > Kind regards, > > Job > > On Mon, Oct 31, 2016 at 05:18:57PM -0400, John G.Scudder wrote: > > > Hi Everyone, > > > > The author has asked for the WG to adopt > draft-snijders-idr-deprecate-30-31-129. > > > > If you support or oppose adoption please reply indicating so. Reasons for > your position are helpful, as volunteering to review, comment, and/or > shepherd. As an aside, I will note that I don't think the WG has the option > of doing nothing, so if you oppose adoption please address what you think > should be done instead. > > > > The adoption call will end November 13. > > > > Thanks, > > > > --John > > > > P.S.: > https://tools.ietf.org/html/draft-snijders-idr-deprecate-30-31-129-01 > > > > Abstract > > > > This document requests IANA to deprecate the following BGP path > > attributes values: 30, 31 and 129. > > > > > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > > > > > ------------------------------------------------------------------------ -------- > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > From nobody Fri Nov 4 06:40:50 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD695129521 for ; Fri, 4 Nov 2016 06:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 Uv56Myo1ALfZ for ; Fri, 4 Nov 2016 06:40:47 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003: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 06B7A129418 for ; Fri, 4 Nov 2016 06:40:45 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id 128so161975394oih.0 for ; Fri, 04 Nov 2016 06:40:45 -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=cPn6EMtFAJ63ewCCdAxNsXpCWo8APC8dHBK16EE1OzQ=; b=m4xnZ6NYauUWJx1OPvfyo+VBxaKRgAcACSs7wpM7AsoKXvCSjw5VlasyeBOBycFqIm 4XFJ86DoaAvHmYZvW32xtePtiTLanrD55+2XWdghUiJpgHhoXAaeapOz7ojGZzyHvP4u RAV4tUcNXWkzBh08pMA3ZYyUuVbTR6DPREKELEIrYYj7Cm3UZFu4HWRkzdZu4rR3Kuf9 XBSTpr8sPTSu5XixBMKVnXXS25OvPQaJAszzpIz+78oiNA22yg6Bh03REI+2o5tAR2mY DDuK5vjRlJRyiJ7gEm5vBGwwpGi5JqyxX7mUPqRz9ZxmBkOxZk33TjEjNHevp6gGT7oL BIWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cPn6EMtFAJ63ewCCdAxNsXpCWo8APC8dHBK16EE1OzQ=; b=gEq0TjqMobrxOjQBjtnAF9JOW+5rT5PJVyIRiNnTM43x5QtC/FOADAkQtWzE3bSfaM cppr3wPoniqsc8pT4/02HafS96mxWCJDmvNd/Rm+RHz5oWn3t24miJasQYve4kVsFuDc tUNGSjfBKaYj6S9qS3M/RPHucV3qZ5YpSfYs9Xqt8jCDaZ1PWOLl/13L6qm9qKgoHBoo WWv+fenAGypf7H5POFSUOGg2mHpIC6RqzvPMRRBPZfFeTSCrFQ6qgM4VQSScVNfPQmoI 2gOXxGZU4RkO5NeJtaWkywWTEDf0EMCGUIpegXrPXBWTfO1mAYIygP0fc8rWtkWkm0t5 aG5A== X-Gm-Message-State: ABUngvfsiuZzjD3lfuRBHonRwYFIEW7y/k/uvv9p9M7oedeEHSuC/tC8OIVNUfkm2Rq8zyTL7fgaulWjkO2jJA== X-Received: by 10.202.8.205 with SMTP id 196mr13626753oii.13.1478266844563; Fri, 04 Nov 2016 06:40:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.144.163 with HTTP; Fri, 4 Nov 2016 06:40:43 -0700 (PDT) X-Originating-IP: [188.206.66.42] In-Reply-To: <050f01d2369c$e82e1d20$4001a8c0@gateway.2wire.net> References: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> <20161101133240.GK1581@hanna.meerval.net> <2393790D-F279-41ED-B5B2-E427C60B4926@juniper.net> <034a01d23639$fa2c78e0$ee856aa0$@ndzh.com> <050f01d2369c$e82e1d20$4001a8c0@gateway.2wire.net> From: Job Snijders Date: Fri, 4 Nov 2016 14:40:43 +0100 Message-ID: To: "t.petch" Content-Type: multipart/alternative; boundary=94eb2c12f99c276e97054079d239 Archived-At: Cc: Robert Raszuk , Susan Hares , IETF IDR Working Group Subject: Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129 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, 04 Nov 2016 13:40:50 -0000 --94eb2c12f99c276e97054079d239 Content-Type: text/plain; charset=UTF-8 For clarity, do you still oppose the proposed -02 i shared earlier? Job On Friday, 4 November 2016, t.petch wrote: > ----- Original Message ----- > From: "Susan Hares" > > To: "'John G. Scudder'" >; "'Robert > Raszuk'" > > > Cc: "'IETF IDR Working Group'" > > Sent: Friday, November 04, 2016 1:22 AM > > > John: > > > > My understanding with the IESG and IANA is that this is true. The > best > > reference is the BIS for RFC226bis below: > > > > https://tools.ietf.org/html/draft-leiba-cotton-iana-5226bis-11 > > > > The RFC5226bis-11.txt got stalled due to the IESG wandering if the > revision > > is needed. Based on our experience, I think it is needed. Alvaro > will kick > > off this work, but the process of updating a "process" document should > not > > impede this document's process. We need to think outside the box. > > > > I suggest we complete this adoption of > > draft-snijders-idr-deprecate-30-31-129 draft by 11/13/2016, and do a > WG LC > > on the draft directly following this process draft (11/14 to 11/28). > This > > should allow the draft-idr-large-communities to have the necessary > registry > > "glue" ready so the IESG publication of large communities can go > quickly. > > Sue > > The reason I am being a bit 'snarky' on this adoption call is my concern > that there may be differing views of what 'deprecate' means. For > example, the SMI world gives it a different (and IMO unsuitable) meaning > which some on this list will know. Even the 5226bis text might not be > quite right. Robert did query whether or not 'deprecate' was suitable. > > If we take 5226bis as gospel, then 'deprecate' is probably the option to > choose but I wish that there were more alternatives. > > I was about to post to the main IETF list and Terry Mandelson(as > responssible AD) about 5226bis (again:-) but the list has erupted with a > discussion about DMARC(again) so I will hold off and see what develops. > > Tom Petch > > > > > > > > > Sue > > > > > > > > From: Idr [mailto:idr-bounces@ietf.org ] On Behalf Of > John G. Scudder > > Sent: Tuesday, November 1, 2016 10:24 AM > > To: Robert Raszuk > > Cc: IETF IDR Working Group > > Subject: Re: [Idr] Working group adoption call for > > draft-snijders-idr-deprecate-30-31-129 > > > > > > > > AFAICT the function of the draft is simply to kick the IANA code point > state > > to "deprecated". It doesn't anchor it there for all time. Presumably a > later > > request can move the state to assigned or whatever, as we've > previously > > discussed. I don't think any update to the current "deprecate" > document > > would be needed to achieve this (I guess maybe the later document > might list > > this one in its "updates" header). > > > > > > > > I'll confirm this understanding with IESG and IANA before the end of > the WG > > adoption call. (Unless someone can point me to chapter-and-verse of a > > reference that explains the process clearly enough, unfortunately I > have not > > found such.) > > > > > > > > Thanks, > > > > > > > > --John > > > > > > > > On Nov 1, 2016, at 10:02 AM, Robert Raszuk > wrote: > > > > > > > > Hi Job, > > > > > > > > Have you consider marking those codepoints as "RESERVED" rather then > > "DEPRECIATED". > > > > > > > > Reason being that if any of the applications they have been squatted > on > > behalf of want to use them - it would be pretty easy to allocate them. > > > > > > > > The other alternative would be to allocate them to those applications > now > > (for which the drafts exist) as IANA early allocations. If you > depreciate > > them now and we know that as example Contrail Multicast is important > either > > your draft will need to quickly be moved to historic or yet another > types > > will need to be allocated again. > > > > > > > > In any of the above Large Communities will get virgin BGP attribute > type > > which I believe is the main point here. > > > > > > > > Cheers, > > > > R. > > > > > > > > > > > > On Tue, Nov 1, 2016 at 2:32 PM, Job Snijders > > wrote: > > > > Dear working group, > > > > To prevent having multiple drafts in quick succession covering the > same > > style of issue - I'd like your feedback on the following: > > > > I believe that bgp path attribute 241, 242, 243 should also be added > to > > this draft for the same reasons as 30, 31 and 129 are listed. > > > > OLD: > > This document requests IANA to deprecate the following BGP Path > > attributes: 30, 31, and 129. > > > > NEW: > > This document requests IANA to deprecate the following BGP Path > > attributes: 30, 31, 129, 241, 242, and 243. > > > > Does anyone object? If so, why? > > > > Unilaterally changing the document while in its mid-flight through the > > working group adoption process might be considered bad form, hence my > > request for feedback on the 241,242,243 topic. > > > > Please note - the deprecation of an attribute can be undone if proper > > process is followed. The priority here is to prevent IANA from > assigning > > tainted codepoints to innocent bystanders, thus a deprecation document > > needs to exist. In time the working group has the power to undeprecate > > them for specific purposes. > > > > Kind regards, > > > > Job > > > > On Mon, Oct 31, 2016 at 05:18:57PM -0400, John G.Scudder wrote: > > > > > Hi Everyone, > > > > > > The author has asked for the WG to adopt > > draft-snijders-idr-deprecate-30-31-129. > > > > > > If you support or oppose adoption please reply indicating so. > Reasons for > > your position are helpful, as volunteering to review, comment, and/or > > shepherd. As an aside, I will note that I don't think the WG has the > option > > of doing nothing, so if you oppose adoption please address what you > think > > should be done instead. > > > > > > The adoption call will end November 13. > > > > > > Thanks, > > > > > > --John > > > > > > P.S.: > > https://tools.ietf.org/html/draft-snijders-idr-deprecate-30-31-129-01 > > > > > > Abstract > > > > > > This document requests IANA to deprecate the following BGP path > > > attributes values: 30, 31 and 129. > > > > > > > > > _______________________________________________ > > > 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 > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --94eb2c12f99c276e97054079d239 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable For clarity, do you still=C2=A0oppose=C2=A0the proposed -02 i shared=C2=A0e= arlier?

Job

On Friday, 4 November 2016, t.petch &= lt;ietfc@btconnect.com> wrote= :
----- Original Message -----
From: "Susan Hares" <shares@ndzh.com> To: "'John G. Scudder'" <jgs@juniper.ne= t>; "'Robert Raszuk'"
<robert@raszuk.net>
Cc: "'IETF IDR Working Group'" <idr@ietf.o= rg>
Sent: Friday, November 04, 2016 1:22 AM

> John:
>
> My understanding with the IESG and IANA is that this is true.=C2=A0 = =C2=A0The
best
> reference is the BIS for RFC226bis below:
>
> https://tools.ietf.org/html/draft-leiba-cotton-= iana-5226bis-11
>
> The RFC5226bis-11.txt got stalled due to the IESG wandering if the
revision
> is needed.=C2=A0 Based on our experience, I think it is needed.=C2=A0 = Alvaro
will kick
> off this work, but the process of updating a "process" docum= ent should
not
> impede this document's process.=C2=A0 We need to think outside the= box.
>
> I suggest we complete this adoption of
> draft-snijders-idr-deprecate-30-31-129 draft by 11/13/2016, and d= o a
WG LC
> on the draft directly following this process draft (11/14 to 11/28). This
> should allow the draft-idr-large-communities to have the necessary
registry
> "glue" ready so the IESG publication of large communities ca= n go
quickly.

Sue

The reason I am being a bit 'snarky' on this adoption call is my co= ncern
that there may be differing views of what 'deprecate' means.=C2=A0 = For
example, the SMI world gives it a different (and IMO unsuitable) meaning which some on this list will know.=C2=A0 Even the 5226bis text might not be=
quite right.=C2=A0 Robert did query whether or not 'deprecate' was = suitable.

If we take 5226bis as gospel, then 'deprecate' is probably the opti= on to
choose but I wish that there were more alternatives.

I was about to post to the main IETF list and Terry Mandelson(as
responssible AD) about 5226bis (again:-) but the list has erupted with a discussion about DMARC(again) so I will hold off and see what develops.

Tom Petch

>
>
>
> Sue
>
>
>
> From: Idr [mailto:idr-bounces@ietf.org] On Beh= alf Of John G. Scudder
> Sent: Tuesday, November 1, 2016 10:24 AM
> To: Robert Raszuk
> Cc: IETF IDR Working Group
> Subject: Re: [Idr] Working group adoption call for
> draft-snijders-idr-deprecate-30-31-129
>
>
>
> AFAICT the function of the draft is simply to kick the IANA code point=
state
> to "deprecated". It doesn't anchor it there for all time= . Presumably a
later
> request can move the state to assigned or whatever, as we've
previously
> discussed. I don't think any update to the current "deprecate= "
document
> would be needed to achieve this (I guess maybe the later document
might list
> this one in its "updates" header).
>
>
>
> I'll confirm this understanding with IESG and IANA before the end = of
the WG
> adoption call. (Unless someone can point me to chapter-and-verse of a<= br> > reference that explains the process clearly enough, unfortunately I have not
> found such.)
>
>
>
> Thanks,
>
>
>
> --John
>
>
>
> On Nov 1, 2016, at 10:02 AM, Robert Raszuk <robert= @raszuk.net> wrote:
>
>
>
> Hi Job,
>
>
>
> Have you consider marking those codepoints as "RESERVED" rat= her then
> "DEPRECIATED".
>
>
>
> Reason being that if any of the applications they have been squatted on
> behalf of want to use them - it would be pretty easy to allocate them.=
>
>
>
> The other alternative would be to allocate them to those applications<= br> now
> (for which the drafts exist) as IANA early allocations. If you
depreciate
> them now and we know that as example Contrail Multicast is important either
> your draft will need to quickly be moved to historic or yet another types
> will need to be allocated again.
>
>
>
> In any of the above Large Communities will get virgin BGP attribute type
> which I believe is the main point here.
>
>
>
> Cheers,
>
> R.
>
>
>
>
>
> On Tue, Nov 1, 2016 at 2:32 PM, Job Snijders <job@= instituut.net>
wrote:
>
> Dear working group,
>
> To prevent having multiple drafts in quick succession covering the
same
> style of issue - I'd like your feedback on the following:
>
> I believe that bgp path attribute 241, 242, 243 should also be added to
> this draft for the same reasons as 30, 31 and 129 are listed.
>
> OLD:
>=C2=A0 =C2=A0 =C2=A0This document requests IANA to deprecate the follow= ing BGP Path
>=C2=A0 =C2=A0 =C2=A0attributes: 30, 31, and 129.
>
> NEW:
>=C2=A0 =C2=A0 =C2=A0This document requests IANA to deprecate the follow= ing BGP Path
>=C2=A0 =C2=A0 =C2=A0attributes: 30, 31, 129, 241, 242, and 243.
>
> Does anyone object? If so, why?
>
> Unilaterally changing the document while in its mid-flight through the=
> working group adoption process might be considered bad form, hence my<= br> > request for feedback on the 241,242,243 topic.
>
> Please note - the deprecation of an attribute can be undone if proper<= br> > process is followed. The priority here is to prevent IANA from
assigning
> tainted codepoints to innocent bystanders, thus a deprecation document=
> needs to exist. In time the working group has the power to undeprecate=
> them for specific purposes.
>
> Kind regards,
>
> Job
>
> On Mon, Oct 31, 2016 at 05:18:57PM -0400, John G.Scudder wrote:
>
> > Hi Everyone,
> >
> > The author has asked for the WG to adopt
> draft-snijders-idr-deprecate-30-31-129.
> >
> > If you support or oppose adoption please reply indicating so.
Reasons for
> your position are helpful, as volunteering to review, comment, and/or<= br> > shepherd. As an aside, I will note that I don't think the WG has t= he
option
> of doing nothing, so if you oppose adoption please address what you think
> should be done instead.
> >
> > The adoption call will end November 13.
> >
> > Thanks,
> >
> > --John
> >
> > P.S.:
> https://tools.ietf.org/html/draft-snijde= rs-idr-deprecate-30-31-129-01
> >
> > Abstract
> >
> >=C2=A0 =C2=A0 This document requests IANA to deprecate the followi= ng BGP path
> >=C2=A0 =C2=A0 attributes values: 30, 31 and 129.
> >
> >
> > _______________________________________________
> > 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
>

_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr
--94eb2c12f99c276e97054079d239-- From nobody Fri Nov 4 06:50:42 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30ACF129503; Fri, 4 Nov 2016 06:50:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.017 X-Spam-Level: X-Spam-Status: No, score=-16.017 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=-1.497, 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 lfA5gPCSfnwY; Fri, 4 Nov 2016 06:50:35 -0700 (PDT) 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 4A3D412946B; Fri, 4 Nov 2016 06:50:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8338; q=dns/txt; s=iport; t=1478267434; x=1479477034; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=oH3lwZ6+BhMY66i9DyhgPplXOwpUfvmGVVxOXlrs3q8=; b=Z4yD/MOH+qzH4gxOThOf/wSSdf+4wMXUgXCAdQCl0KjmIRk4Ta063ErM Yx+O3Ixwsk/+g4mVwD/P/sOeUBDvzGjEyYP90ENm/7tFoB1/emy2TfCYB wjnv4INd5Y6jsnCW00e1XVyUJ7i8ojsxEmk91Yk5ENDczN0Try6BbB1iV Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DkAQDvkBxY/4ENJK1dHAEBBAEBCgEBg?= =?us-ascii?q?nM7AQEBAQEfgVSNOKYuhRiCCIYjAoIWPxQBAgEBAQEBAQFiKIRiAQEEeRACAQg?= =?us-ascii?q?OMQcyFBECBA4FFIhEvCoBAQEBAQEBAQEBAQEBAQEBAQEBAQEchj+BfQiCUId4g?= =?us-ascii?q?i8FlESFXwGQPwKQCI0hhAMBHjdshSFyh3QBAQE?= X-IronPort-AV: E=Sophos;i="5.31,443,1473120000"; d="scan'208,217";a="344262040" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Nov 2016 13:50:33 +0000 Received: from XCH-ALN-015.cisco.com (xch-aln-015.cisco.com [173.36.7.25]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id uA4DoXwB013288 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 4 Nov 2016 13:50:33 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; Fri, 4 Nov 2016 08:50:32 -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, 4 Nov 2016 08:50:32 -0500 From: "Jakob Heitz (jheitz)" To: Jeffrey Haas Thread-Topic: [Idr] Review of draft-ietf-large-community-06.txt Thread-Index: AQHSNjBz6sRcMeSZxEiIR579im5tsaDIKelQgACxKYCAABpngP//4vhM Date: Fri, 4 Nov 2016 13:50:32 +0000 Message-ID: <98041685-2554-452C-B707-C1AF26BE1FA7@cisco.com> References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com> <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com> <4080cfba032744f590fcbbb710f0d618@XCH-ALN-014.cisco.com> <08C97932-4E8B-4EBC-B780-3A2F54A1EEF2@apnic.net>, 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 Content-Type: multipart/alternative; boundary="_000_980416852554452CB707C1AF26BE1FA7ciscocom_" MIME-Version: 1.0 Archived-At: Cc: IETF IDR WG , Sue Hares , "rtg-dir@ietf.org" Subject: Re: [Idr] Review of draft-ietf-large-community-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: Fri, 04 Nov 2016 13:50:39 -0000 --_000_980416852554452CB707C1AF26BE1FA7ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The text in RFCs 1997 and 4360 is not a constraint: If a range of routes is to be aggregated and the resultant aggregates attribute section does not carry the ATOMIC_AGGREGATE attribute, then the resulting aggregate should have a COMMUNITIES path attribute which contains all communities from all of the aggregated routes. It does not describe how to aggregate if ATOMIC_AGGREGATE is present. The t= ext is more constrained if ATOMIC_AGGREGATE is left out of it. Thanks, Jakob. On Nov 4, 2016, at 4:24 AM, Jeffrey Haas > wrote: On Nov 4, 2016, at 4:59 AM, Geoff Huston > wrote: I just noted that RFC1997 and RFC4360 had these constraints. It seems strange to me that an implementation would handle aggregation diff= erently, treating communities and extended communities one way and large co= mmunities in a subtly different manner. Frankly I would prefer to see a consistent treatment of communities in the = case of aggregation, and reproducxing the RFC4360 text kinda makes that cle= ar (at least to me) Omitting it invites different handling and that would be not good The relevant point from the thread is that the atomic-aggregate attribute i= s largely protocol noise. It's a vestigial organ from the BGP-3 to BGP-4 t= ransition, and a poorly specified one at that. We shouldn't include its us= e in specifications, particularly where discussing aggregation. The only place its discussion would be relevant is as part of *de-*aggregat= ion of a prefix. -- Jeff --_000_980416852554452CB707C1AF26BE1FA7ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
The text in RFCs 1997 and 4360 is not a constraint:

If a ra=
nge of routes is to be aggregated and the resultant aggregates
   attribute section does not carry the ATOMIC_AGGREGATE attribute, then
   the resulting aggregate should have a COMMUNITIES path attribute
   which contains all communities from all of the aggregated routes.=

It does not describe how to aggregate if ATOMIC_AGGREGATE is present. = The text is more constrained if ATOMIC_AGGREGATE is left out of it.

Thanks,
Jakob.


On Nov 4, 2016, at 4:24 AM, Jeffrey Haas <jhaas@pfrc.org> wrote:


On Nov 4, 2016, at 4:59 AM, Geoff Huston <gih@apnic.net> wrote:

I just noted that RFC1997 and RFC4360 had these constraints.

It seems strange to me that an implementation would handle aggregation differ= ently, treating communities and extended communities one way and large comm= unities in a subtly different manner.

Frankly I would prefer to see a consistent treatment of communities in the case of= aggregation, and reproducxing the RFC4360 text kinda makes that clear (at = least to me)

Omitting it invites different handling and that would be not good

The relevant point from the thread is that the atomic-aggre= gate attribute is largely protocol noise.  It's a vestigial organ from= the BGP-3 to BGP-4 transition, and a poorly specified one at that.  W= e shouldn't include its use in specifications, particularly where discussing aggregation.

The only place its discussion would be relevant is as part = of *de-*aggregation of a prefix.

-- Jeff

--_000_980416852554452CB707C1AF26BE1FA7ciscocom_-- From nobody Fri Nov 4 07:20:49 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B112129450 for ; Fri, 4 Nov 2016 07:20:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.008 X-Spam-Level: X-Spam-Status: No, score=-16.008 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=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, 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 wQl5evy4fJZg for ; Fri, 4 Nov 2016 07:20: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 7A3F61288B8 for ; Fri, 4 Nov 2016 07:20:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=147406; q=dns/txt; s=iport; t=1478269244; x=1479478844; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=JDeZDpZzfACu5w+L89kunItYGcdQUoUqO69iexlWX9w=; b=jdJ/NrqIHPu9APMUrjgi3WsrLCmDoKkyxtZTo/boZSKaUqyz+YmREady V7CP7vcv/fux3yzLSX96ULPFVAytlJLlptXvsv7v98001mkZeDhByDXLm /tTrospLTEmArIYNLSgQq9FGFXBCMJPxw13GkGTSQElEr9/KufLoc251l g=; X-Files: draft-ietf-idr-large-community.xml, draft-ietf-idr-large-community-07.txt, draft-ietf-idr-large-community-07-diff-from-06.html : 17835, 18213, 63837 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AXAQCumBxY/4cNJK1TChkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMuAQEBAQEfWHyFTYdrlwCHYIxmggUDHQEMhB+BVQMCAhqBfD8?= =?us-ascii?q?UAQIBAQEBAQEBYiiEYQEBAQQBAQEXARI5AQcXBAIBGQQBASEBBgUCAh8GCxQHA?= =?us-ascii?q?ggCBAESDgYGiCQDFw6RdZ05CIMIhXANg3sBAQEBAQEBAQEBAQEBAQEBAQEBAQE?= =?us-ascii?q?ODoY/gX0IglCCR4FHCwYFAwMBMxWCVDGCLwWIS4F4iEiDWnuCDjUBg0mCaoMLg?= =?us-ascii?q?wdEgzaBbhc3hCGIBIEphymBWIQghAMBHjdsgm02BRyBXXIBhTcBBQkXghYBAQE?= X-IronPort-AV: E=Sophos;i="5.31,443,1473120000"; d="xml'217?txt'217?html'217,217?scan'217,217,208,217";a="344299115" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Nov 2016 14:20:41 +0000 Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id uA4EKfWQ020022 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 4 Nov 2016 14:20:41 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 4 Nov 2016 09:20:40 -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, 4 Nov 2016 09:20:40 -0500 From: "Jakob Heitz (jheitz)" To: "gih@apnic.net" , "idr@ietf.org" Thread-Topic: [Idr] Review of draft-ietf-large-community-06.txt Thread-Index: AQHSNjBz6sRcMeSZxEiIR579im5tsaDIY72wgAB9DlI= Date: Fri, 4 Nov 2016 14:20:40 +0000 Message-ID: <40D942F5-0710-46D1-BF09-76C827377479@cisco.com> References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com> <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com> , <6c5d83aa1d6a4a04b651b8f14f4b445b@XCH-ALN-014.cisco.com> In-Reply-To: <6c5d83aa1d6a4a04b651b8f14f4b445b@XCH-ALN-014.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/mixed; boundary="_004_40D942F5071046D1BF0976C827377479ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [Idr] Fwd: Review of draft-ietf-large-community-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: Fri, 04 Nov 2016 14:20:48 -0000 --_004_40D942F5071046D1BF0976C827377479ciscocom_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 R2VvZmYsDQoNCkhlcmUgaXMgbXkgcHJvcG9zZWQgcmV2aXNpb24uIEkgbWFkZSBhbGwgdGhlIGNo YW5nZXMsIGV4Y2VwdCB0aGUgQVRPTUlDX0FHR1JFR0FURS4gSWYgYWZ0ZXIgdGhlIGxhdGVzdCBk aXNjdXNzaW9uLCB5b3Ugc3RpbGwgd2FudCBpdCwgSSdsbCBtYWtlIHRoYXQgY2hhbmdlIHRvby4N Cg0KVGhhbmtzLA0KSmFrb2IuDQoNCg0KQmVnaW4gZm9yd2FyZGVkIG1lc3NhZ2U6DQoNCj4+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBJZHIgW21haWx0bzppZHItYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEdlb2ZmIEh1c3Rvbg0KPj4gU2VudDogVGh1cnNkYXks IE5vdmVtYmVyIDAzLCAyMDE2IDU6MTQgUE0NCj4+IFRvOiBJRVRGIElEUiBXRyA8aWRyQGlldGYu b3JnPg0KPj4gQ2M6IHJ0Zy1kaXJAaWV0Zi5vcmc7IFN1c2FuIEhhcmVzIDxzaGFyZXNAbmR6aC5j b20+DQo+PiBTdWJqZWN0OiBbSWRyXSBSZXZpZXcgb2YgZHJhZnQtaWV0Zi1sYXJnZS1jb21tdW5p dHktMDYudHh0DQo+PiANCj4+IEkgaGF2ZSByZXZpZXdlZCB0aGlzIGRyYWZ0IGFuZCBoYXZlIHRo ZSBmb2xsb3dpbmcgOSBzdWdnZXN0aW9ucy4gQWxsIG9mDQo+PiB0aGVzZSBmYWxsIGludG8gdGhl IGNhdGVnb3J5IG9mIG1pbm9yIHN1Z2dlc3Rpb25zLiBJIGRvIG5vdCBiZWxpZXZlIHRoYXQNCj4+ IHRoZXJlIGlzIG1heSBtYWpvciBzdHJ1Y3R1cmFsIGRlZmljaWVuY3kgaW4gdGhpcyBzcGVjaWZp Y2F0aW9uLCBhbmQgdGhlDQo+PiBkb2N1bWVudCBpcyBsYXJnZWx5IHJlYWR5LCBpbiBteSB2aWV3 Lg0KPj4gDQo+PiBIZXJlIGFyZSBteSBzcGVjaWZpYyBzdWdnZXN0aW9ucy4NCj4+IA0KPj4gDQo+ PiAxLiAtLS0tLS0tLS0tLS0tLS0tDQo+PiANCj4+IFRpdGxlOiBMYXJnZSBCR1AgQ29tbXVuaXRp ZXMNCj4+IA0KPj4gdG8gYmUgY29uc2lzdGVudCB3aXRoIHByZXZpb3VzIGF0dHJpYnV0ZSBzcGVj aWZpY2F0aW9ucywgaG93IGFib3V0DQo+PiANCj4+ICJCR1AgTGFyZ2UgQ29tbXVuaXRpZXMgQXR0 cmlidXRlIg0KPj4gDQo+PiBpLmUuIHN3aXRjaCB0aGUgb3JkZXIgb2YgIkxhcmdlIEJHUCIgdG8g IkJHUCBMYXJnZSIgdG8gYmUgY29uc2lzdGVudCB3aXRoDQo+PiBlYXJsaWVyIEJHUCBFeHRlbmRl ZCBDb21tdW5pdGllcyBzcGVjaWZpY2F0aW9uIGluIFJGQzQzNjANCj4+IA0KPj4gMi4gLS0tLS0t LS0tLS0tLS0tLQ0KPj4gDQo+PiAiTmV0d29yayBvcGVyYXRvcnMNCj4+IGF0dGFjaCBCR1AgY29t bXVuaXRpZXMgdG8gcm91dGVzIHRvIGlkZW50aWZ5IGludHJpbnNpYyBwcm9wZXJ0aWVzIG9mDQo+ PiB0aGVzZSByb3V0ZXMuIg0KPj4gDQo+PiBJIGRvbid0IHRoaW5rIGNvbW11bml0eSBhdHRyaWJ1 dGVzIGFyZSBhbiBpbnRyaW5zaWMgcHJvcGVydHkgb2YgYSByb3V0ZQ0KPj4gYWR2ZXJ0aXNlbWVu dCAtIHRoZXkgYXJlIG1vcmUgYXBwcm9wcmlhdGVseSBleHByZXNzZWQgYXMgYW4gYXR0YWNoZWQg YXR0cmlidXRlDQo+PiB0aGF0IGV4cHJlc3NlcyBzb21lIGRlc2lyZWQgcHJvcGVydHkuDQo+PiAN Cj4+IGhvdyBhYm91dDoNCj4+IA0KPj4gIk5ldHdvcmsgb3BlcmF0b3JzIGF0dGFjaCBCR1AgY29t bXVuaXRpZXMgdG8gcm91dGVzIHRvIGFzc29jaWF0ZQ0KPj4gcGFydGljdWxhciBwcm9wZXJ0aWVz IHdpdGggdGhlc2Ugcm91dGVzLiINCj4+IA0KPj4gMy4gLS0tLS0tLS0tLS0tLS0tLQ0KPj4gDQo+ PiAiYW5kIG1heSBhcHBseSB0byBhbiBpbmRpdmlkdWFsIHJvdXRlIG9yIHRvIGEgZ3JvdXAgb2Yg cm91dGVzLiINCj4+IA0KPj4gSSBhbSBjb25mdXNlZCAtIHN1cmVseSB0aGUgYXR0cmlidXRlcyBp biBhbiBVcGRhdGUgQkdQIG1lc3NhZ2UgYXBwbHkgdG8gdGhlDQo+PiBjb2xsZWN0aW9uIG9mIHJv dXRlcyBjb250YWluZWQgaW4gdGhlIFVwZGF0ZS4gSXQgY2Fubm90IGJlIGFwcGxpZWQgdG8gYQ0K Pj4gc2luZ2xlIHJvdXRlIHdoZW4gdGhlIHVwZGF0ZSBpdHNlbGYgY29udGFpbnMgbXVsdGlwbGUg cm91dGVzLiBXaHkgbm90DQo+PiB1c2UgdGhlIHRleHQ6DQo+PiANCj4+ICJhbmQgaXMgYXBwbGll ZCB0byBhbGwgcm91dGVzIGNvbnRhaW5lZCBpbiBhIEJHUCBVcGRhdGUgTWVzc2FnZSB3aGVyZQ0K Pj4gdGhlIENvbW11bml0aWVzIEF0dHJpYnV0ZSBpcyBpbmNsdWRlZC4iDQo+PiANCj4+IDQuIC0t LS0tLS0tLS0tLS0tLS0NCj4+IA0KPj4gIltSRkMxOTk3XSBCR1AgQ29tbXVuaXRpZXMgYXR0cmli dXRlcyBhcmUgZm91ci1vY3RldCB2YWx1ZXMgc3BsaXQgaW50bw0KPj4gdHdvIHR3by1vY3RldCB3 b3Jkcy4iDQo+PiANCj4+IFRoaXMgaXMgbm90IHRoZSBjYXNlIC0gUkZDMTk5NyBzYXlzOiAiQ29t bXVuaXRpZXMgYXJlIHRyZWF0ZWQgYXMgMzIgYml0IHZhbHVlcyINCj4+IEkgdGhpbmsgaXQgd291 bGQgYmUgbW9yZSBhY2N1cmF0ZSB0byBzYXk6DQo+PiANCj4+ICJCR1AgQ29tbXVuaXRpZXMgYXR0 cmlidXRlcyBhcmUgZm91ci1vY3RldCB2YWx1ZXMgW1JGQzE5OTddLiBDb21tb24gdXNlIG9mDQo+ PiB0aGlzIGF0dHJpYnV0ZSB0eXBlIHNwbGl0cyB0aGlzIHNpbmdsZSAzMi1iaXQgdmFsdWUgZmll bGQgaW50byB0d28gMTYtYml0IHZhbHVlcy4iDQo+PiANCj4+IDUuIC0tLS0tLS0tLS0tLS0tLS0N Cj4+IA0KPj4gIlRoZSBCR1AgRXh0ZW5kZWQgQ29tbXVuaXRpZXMNCj4+IGF0dHJpYnV0ZSBbUkZD NDM2MF0gaXMgYWxzbyB1bnN1aXRhYmxlLCBhcyB0aGUgcHJvdG9jb2wgbGltaXQgb2Ygc2l4DQo+ PiBvY3RldHMgY2Fubm90IGFjY29tbW9kYXRlIGJvdGggYSBmb3VyLW9jdGV0IEdsb2JhbCBBZG1p bmlzdHJhdG9yDQo+PiB2YWx1ZSBhbmQgYSBmb3VyLW9jdGV0IExvY2FsIEFkbWluaXN0cmF0b3Ig dmFsdWUsIHdoaWNoIHByZWNsdWRlcyB0aGUNCj4+IGNvbW1vbiBvcGVyYXRpb25hbCBwcmFjdGlj ZSBvZiBlbmNvZGluZyBhIHRhcmdldCBBU04gaW4gdGhlIExvY2FsDQo+PiBBZG1pbmlzdHJhdG9y IGZpZWxkLiINCj4+IA0KPj4gDQo+PiBUaGF0cyBhIHZlcnkgbG9uZyBzZW50ZW5jZS4gVHJ5Og0K Pj4gDQo+PiAiVGhlIEJHUCBFeHRlbmRlZCBDb21tdW5pdGllcyBhdHRyaWJ1dGUgW1JGQzQzNjBd IGlzIGFsc28gdW5zdWl0YWJsZSwgYXMNCj4+IHRoZSBwcm90b2NvbCBsaW1pdCBvZiBzaXggb2N0 ZXRzIGZvciBlYWNoIGNvbW11bml0eSB2YWx1ZSBjYW5ub3QNCj4+IGFjY29tbW9kYXRlIGJvdGgg YSBmb3VyLW9jdGV0IEdsb2JhbCBBZG1pbmlzdHJhdG9yIHZhbHVlIGFuZCBhIGZvdXItb2N0ZXQN Cj4+IExvY2FsIEFkbWluaXN0cmF0b3IgdmFsdWUuIFRoaXMgbGltaXRhdGlvbiBwcmVjbHVkZXMg dGhlIGNvbW1vbg0KPj4gb3BlcmF0aW9uYWwgcHJhY3RpY2Ugb2YgZW5jb2RpbmcgYSB0YXJnZXQg QVNOIGluIHRoZSBMb2NhbCBBZG1pbmlzdHJhdG9yDQo+PiBmaWVsZC4iDQo+PiANCj4+IDYuIC0t LS0tLS0tLS0tLS0tLS0NCj4+IA0KPj4gVGhlIGFnZ3JlZ2F0aW9uIHNlY3Rpb24gY29udGFpbnMg ZmV3ZXIgY29uc3RyYWludHMgdGhlbiBlaXRoZXIgUkZDMTk5NyBvcg0KPj4gUkZDNDM2MC4gSXQg YWxzbyBjb250YWlucyBhIGNvbmZ1c2luZyBub24tbm9ybWF0aXZlIKGwc2hvdWxkIi4NCj4+IA0K Pj4gRm9yIHJlZmVyZW5jZSwgUkZDNDM2MCBzdGF0ZXM6IEJ5IGRlZmF1bHQgaWYgYSByYW5nZSBv ZiByb3V0ZXMgaXMgdG8gYmUNCj4+IGFnZ3JlZ2F0ZWQgYW5kIHRoZSByZXN1bHRhbnQgYWdncmVn YXRlcyBwYXRoIGF0dHJpYnV0ZXMgZG8gbm90IGNhcnJ5IHRoZQ0KPj4gQVRPTUlDX0FHR1JFR0FU RSBhdHRyaWJ1dGUsIHRoZW4gdGhlIHJlc3VsdGluZyBhZ2dyZWdhdGUgc2hvdWxkIGhhdmUgYW4N Cj4+IEV4dGVuZGVkIENvbW11bml0aWVzIHBhdGggYXR0cmlidXRlIHRoYXQgY29udGFpbnMgdGhl IHNldCB1bmlvbiBvZiBhbGwgdGhlDQo+PiBFeHRlbmRlZCBDb21tdW5pdGllcyBmcm9tIGFsbCBv ZiB0aGUgYWdncmVnYXRlZCByb3V0ZXMuICBUaGUgZGVmYXVsdA0KPj4gYmVoYXZpb3IgY291bGQg YmUgb3ZlcnJpZGRlbiB2aWEgbG9jYWwgY29uZmlndXJhdGlvbiwgaW4gd2hpY2ggY2FzZQ0KPj4g aGFuZGxpbmcgdGhlIEV4dGVuZGVkIENvbW11bml0aWVzIGF0dHJpYnV0ZSBpbiB0aGUgcHJlc2Vu Y2Ugb2Ygcm91dGUNCj4+IGFnZ3JlZ2F0aW9uIGJlY29tZXMgYSBtYXR0ZXIgb2YgdGhlIGxvY2Fs IHBvbGljeSBvZiB0aGUgQkdQIHNwZWFrZXIgdGhhdA0KPj4gcGVyZm9ybXMgdGhlIGFnZ3JlZ2F0 aW9uLg0KPj4gDQo+PiBXaHkgbm90IHVzZSB0aGlzIGZvcm11bGF0aW9uPyBpLmUuDQo+PiANCj4+ ICIzLiBBZ2dyZWdhdGlvbg0KPj4gDQo+PiBJZiBhIHNldCBvZiByb3V0ZXMgaXMgdG8gYmUgYWdn cmVnYXRlZCBhbmQgdGhlIHJlc3VsdGluZyBhZ2dyZWdhdGUgcm91dGUncw0KPj4gcGF0aCBhdHRy aWJ1dGVzIGRvIG5vdCBpbmNsdWRlIHRoZSBBVE9NSUNfQUdHUkVHQVRFIGF0dHJpYnV0ZSwgdGhl biB0aGUNCj4+IHJlc3VsdGluZyBhZ2dyZWdhdGUgcm91dGUgU0hPVUxEIGhhdmUgYSBMYXJnZSBD b21tdW5pdGllcyBBdHRyaWJ1dGUgZm9ybWVkDQo+PiBmcm9tIHRoZSBzZXQgdW5pb24gb2YgYWxs IHRoZSBMYXJnZSBDb21tdW5pdHkgdmFsdWVzIGZyb20gYWxsIG9mIHRoZQ0KPj4gYWdncmVnYXRl ZCBzZXQgb2Ygcm91dGVzLiAgVGhpcyBiZWhhdmlvciBNQVkgYmUgb3ZlcnJpZGRlbiB2aWEgbG9j YWwNCj4+IGNvbmZpZ3VyYXRpb24sIGluIHdoaWNoIGNhc2UgaGFuZGxpbmcgdGhlIExhcmdlIENv bW11bml0aWVzIGF0dHJpYnV0ZSBpbg0KPj4gdGhlIHByZXNlbmNlIG9mIHJvdXRlIGFnZ3JlZ2F0 aW9uIGlzIGRldGVybWluZWQgYnkgdGhlIGxvY2FsIHBvbGljeSBvZiB0aGUNCj4+IEJHUCBzcGVh a2VyIHRoYXQgcGVyZm9ybXMgdGhlIGFnZ3JlZ2F0aW9uLiINCj4+IA0KPj4gNy4gLS0tLS0tLS0t LS0tLS0tLQ0KPj4gDQo+PiA0LiAgQ2Fub25pY2FsIFJlcHJlc2VudGF0aW9uDQo+PiANCj4+IEkg YW0gY29uZnVzZWQgaGVyZSAtIHRoaXMgc2VjdGlvbiB1c2VkIGFuIGV4YW1wbGUgd2l0aCBUV08g Y2Fub25pY2FsDQo+PiByZXByZXNlbnRhdGlvbnM6DQo+PiANCj4+ICAgIkZvciBleGFtcGxlOiA2 NDQ5Njo0Mjk0OTY3Mjk1OjIsIDY0NDk2OjA6MCwgb3IgKDY0NDk2LCAxMTEsIDIyMikuIg0KPj4g DQo+PiANCj4+IENvbnZlbnRpb25hbGx5LCBpdCdzIGJldHRlciB0byB1c2UgYSBzaW5nbGUgY2Fu b25pY2FsIHJlcHJlc2VudGF0aW9uLCBzbyB0aGUNCj4+IGF1dGhvcnMgc2hvdWxkIHBpY2sgZWl0 aGVyIGEgY29sb24tZGVsaW1pdGVkIGxpc3QsIG9yIGEgYnJhY2tldGVkIGNvbW1hK3NwYWNlDQo+ PiBzZXBhcmF0ZWQgb2JqZWN0Lg0KPj4gDQo+PiANCj4+IDguIC0tLS0tLS0tLS0tLS0tLS0NCj4+ IA0KPj4gNS4gIFJlc2VydmVkIExhcmdlIEJHUCBDb21tdW5pdHkgdmFsdWVzDQo+PiANCj4+IA0K Pj4gVGhlIHRleHQgcmVhZHM6DQo+PiANCj4+ICJ0aGUgR2xvYmFsIEFkbWluaXN0cmF0b3IgdmFs dWVzIHNwZWNpZmllZCBhYm92ZSBjb3VsZCBiZQ0KPj4gdXNlZCBpZiB0aGVyZSBpcyBhIGZ1dHVy ZSBuZWVkIGZvciB0aGVtLiINCj4+IA0KPj4gVGhpcyBpcyBlbnRpcmVseSB1bmNsZWFyLiBJcyBp dCByZWZlcnJpbmcgdG8gdGhlIHZhbHVlcyB0aGF0IHRoZSBwcmV2aW91cw0KPj4gcGFyYWdyYXBo IHNwZWNpZmllZCBhcyAiU0hPVUxEIE5PVCB1c2WhsT8gQWxzbyAiY291bGQgYmUgdXNlZCIgaXMg YSBwb29yDQo+PiBjaG9pY2Ugb2Ygd29yZHMgZm9yIGEgbm9ybWF0aXZlIHNwZWNpZmljYXRpb24u DQo+PiANCj4+IEkgc3VnZ2VzdCBkZWxldGluZyBjb21wbGV0ZWx5IHRoZSBwYXJhZ3JhcGggdGhh dCBjb250YWlucyB0aGlzIHF1b3RlIGZyb20NCj4+IHRoZSBkb2N1bWVudC4NCj4+IA0KPj4gDQo+ PiA5LiAtLS0tLS0tLS0tLS0tLS0tDQo+PiANCj4+IFRoZSB0ZXh0IHJlYWRzOg0KPj4gDQo+PiAi VGhlIGVycm9yIGhhbmRsaW5nIG9mIExhcmdlIEJHUCBDb21tdW5pdGllcyBpcyBhcyBmb2xsb3dz Og0KPj4gDQo+PiAgIG8gIEEgTGFyZ2UgQkdQIENvbW11bml0aWVzIGF0dHJpYnV0ZSBTSEFMTCBi ZSBjb25zaWRlcmVkIG1hbGZvcm1lZCBpZg0KPj4gICAgICBpdHMgbGVuZ3RoIGlzIG5vdCBhIG5v bi16ZXJvIG11bHRpcGxlIG9mIDEyLiINCj4+IA0KPj4gDQo+PiBJIHRoaW5rIHRoZSBhdXRob3Ig aXMgdHJ5aW5nIHRvIGRheUwNCj4+IA0KPj4gIlRoZSBlcnJvciBoYW5kbGluZyBvZiBMYXJnZSBC R1AgQ29tbXVuaXRpZXMgaXMgYXMgZm9sbG93czoNCj4+IA0KPj4gICBvICBBIExhcmdlIENvbW11 bml0aWVzIGF0dHJpYnV0ZSBTSEFMTCBiZSBjb25zaWRlcmVkIG1hbGZvcm1lZCBpZiB0aGUNCj4+ ICAgICBsZW5ndGggb2YgdGhlIExhcmdlIENvbW11bml0aWVzIHZhbHVlLCBleHByZXNzZWQgaW4g b2N0ZXRzLCBpcyBub3QgYQ0KPj4gICAgIG5vbi16ZXJvIG11bHRpcGxlIG9mIDEyLiINCj4+IA0K Pj4gDQo+PiB0aGFua3MsDQo+PiANCj4+ICBHZW9mZg0KPj4gDQo+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gSWRyIG1haWxpbmcgbGlzdA0KPj4g SWRyQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lk cg0K --_004_40D942F5071046D1BF0976C827377479ciscocom_ Content-Type: text/xml; name="draft-ietf-idr-large-community.xml" Content-Description: draft-ietf-idr-large-community.xml Content-Disposition: attachment; filename="draft-ietf-idr-large-community.xml"; size=17835; creation-date="Fri, 04 Nov 2016 14:20:33 GMT"; modification-date="Fri, 04 Nov 2016 14:20:33 GMT" Content-ID: Content-Transfer-Encoding: base64 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVMtQVNDSUkiPz4NCjwhRE9DVFlQRSByZmMg U1lTVEVNICJyZmMyNjI5LmR0ZCI+DQo8P3JmYyB0b2M9InllcyI/Pg0KPD9yZmMgdG9jb21wYWN0 PSJ5ZXMiPz4NCjw/cmZjIHRvY2RlcHRoPSIzIj8+DQo8P3JmYyB0b2NpbmRlbnQ9InllcyI/Pg0K PD9yZmMgc3ltcmVmcz0ieWVzIj8+DQo8P3JmYyBzb3J0cmVmcz0ieWVzIj8+DQo8P3JmYyBjb21t ZW50cz0ieWVzIj8+DQo8P3JmYyBpbmxpbmU9InllcyI/Pg0KPD9yZmMgY29tcGFjdD0ieWVzIj8+ DQo8P3JmYyBzdWJjb21wYWN0PSJubyI/Pg0KPHJmYyBjYXRlZ29yeT0ic3RkIiBkb2NOYW1lPSJk cmFmdC1pZXRmLWlkci1sYXJnZS1jb21tdW5pdHktMDciIGlwcj0idHJ1c3QyMDA5MDIiPg0KICA8 ZnJvbnQ+DQogICAgPHRpdGxlIGFiYnJldj0iQkdQIExhcmdlIENvbW11bml0aWVzIj5CR1AgTGFy Z2UgQ29tbXVuaXRpZXM8L3RpdGxlPg0KDQogICAgPGF1dGhvciBmdWxsbmFtZT0iSmFrb2IgSGVp dHoiIGluaXRpYWxzPSJKLiIgc3VybmFtZT0iSGVpdHoiIHJvbGU9ImVkaXRvciI+DQogICAgICAg IDxvcmdhbml6YXRpb24+Q2lzY288L29yZ2FuaXphdGlvbj4NCiAgICAgICAgPGFkZHJlc3M+DQog ICAgICAgICAgICA8cG9zdGFsPg0KICAgICAgICAgICAgICAgIDxzdHJlZXQ+MTcwIFdlc3QgVGFz bWFuIERyaXZlPC9zdHJlZXQ+DQogICAgICAgICAgICAgICAgPGNpdHk+U2FuIEpvc2U8L2NpdHk+ DQogICAgICAgICAgICAgICAgPHJlZ2lvbj5DQTwvcmVnaW9uPg0KICAgICAgICAgICAgICAgIDxj b2RlPjk1MDU0PC9jb2RlPg0KICAgICAgICAgICAgICAgIDxjb3VudHJ5PlVTQTwvY291bnRyeT4N CiAgICAgICAgICAgIDwvcG9zdGFsPg0KICAgICAgICAgICAgPGVtYWlsPmpoZWl0ekBjaXNjby5j b208L2VtYWlsPg0KICAgICAgICA8L2FkZHJlc3M+DQogICAgPC9hdXRob3I+DQoNCiAgICA8YXV0 aG9yIGZ1bGxuYW1lPSJKb2IgU25pamRlcnMiIGluaXRpYWxzPSJKLiIgc3VybmFtZT0iU25pamRl cnMiIHJvbGU9ImVkaXRvciI+DQogICAgICAgIDxvcmdhbml6YXRpb24gYWJicmV2PSJOVFQiPk5U VCBDb21tdW5pY2F0aW9uczwvb3JnYW5pemF0aW9uPg0KICAgICAgICA8YWRkcmVzcz4NCiAgICAg ICAgICAgIDxwb3N0YWw+DQogICAgICAgICAgICAgICAgPHN0cmVldD5UaGVvZG9ydXMgTWFqb2Zz a2lzdHJhYXQgMTAwPC9zdHJlZXQ+DQogICAgICAgICAgICAgICAgPGNvZGU+MTA2NSBTWjwvY29k ZT4NCiAgICAgICAgICAgICAgICA8Y2l0eT5BbXN0ZXJkYW08L2NpdHk+DQogICAgICAgICAgICAg ICAgPGNvdW50cnk+VGhlIE5ldGhlcmxhbmRzPC9jb3VudHJ5Pg0KICAgICAgICAgICAgPC9wb3N0 YWw+DQogICAgICAgICAgICA8ZW1haWw+am9iQG50dC5uZXQ8L2VtYWlsPg0KICAgICAgICA8L2Fk ZHJlc3M+DQogICAgPC9hdXRob3I+DQoNCg0KICAgIDxhdXRob3IgZnVsbG5hbWU9IktleXVyIFBh dGVsIiBpbml0aWFscz0iSy4iIHN1cm5hbWU9IlBhdGVsIj4NCiAgICAgICAgPG9yZ2FuaXphdGlv biBhYmJyZXY9IkFycmN1cyI+QXJyY3VzLCBJbmM8L29yZ2FuaXphdGlvbj4NCiAgICAgICAgPGFk ZHJlc3M+DQogICAgICAgICAgICA8ZW1haWw+a2V5dXJAYXJyY3VzLmNvbTwvZW1haWw+DQogICAg ICAgIDwvYWRkcmVzcz4NCiAgICA8L2F1dGhvcj4NCg0KICAgIDxhdXRob3IgZnVsbG5hbWU9Ikln bmFzIEJhZ2RvbmFzIiBpbml0aWFscz0iSS4iIHN1cm5hbWU9IkJhZ2RvbmFzIj4NCiAgICAgICAg PG9yZ2FuaXphdGlvbj5FcXVpbml4PC9vcmdhbml6YXRpb24+DQogICAgICAgIDxhZGRyZXNzPg0K ICAgICAgICAgICAgPHBvc3RhbD4NCiAgICAgICAgICAgICAgICA8c3RyZWV0Pjwvc3RyZWV0Pg0K ICAgICAgICAgICAgICAgIDxjaXR5PkxvbmRvbjwvY2l0eT4NCiAgICAgICAgICAgICAgICA8Y291 bnRyeT5VSzwvY291bnRyeT4NCiAgICAgICAgICAgIDwvcG9zdGFsPg0KICAgICAgICAgICAgPGVt YWlsPmliYWdkb25hLmlldGZAZ21haWwuY29tPC9lbWFpbD4NCiAgICAgICAgPC9hZGRyZXNzPg0K ICAgIDwvYXV0aG9yPg0KDQogICAgPGF1dGhvciBmdWxsbmFtZT0iQWRhbSBTaW1wc29uIiBpbml0 aWFscz0iQS4iIHN1cm5hbWU9IlNpbXBzb24iPg0KICAgICAgICA8b3JnYW5pemF0aW9uPk5va2lh PC9vcmdhbml6YXRpb24+DQogICAgICAgIDxhZGRyZXNzPg0KICAgICAgICAgICAgPHBvc3RhbD4N CiAgICAgICAgICAgICAgICA8c3RyZWV0PjYwMCBNYXJjaCBSb2FkPC9zdHJlZXQ+DQogICAgICAg ICAgICAgICAgPGNpdHk+T3R0YXdhPC9jaXR5Pg0KICAgICAgICAgICAgICAgIDxjb2RlPk9udGFy aW8gSzJLIDJFNjwvY29kZT4NCiAgICAgICAgICAgICAgICA8Y291bnRyeT5DYW5hZGE8L2NvdW50 cnk+DQogICAgICAgICAgICA8L3Bvc3RhbD4NCiAgICAgICAgICAgIDxlbWFpbD5hZGFtLjEuc2lt cHNvbkBub2tpYS5jb208L2VtYWlsPg0KICAgICAgICA8L2FkZHJlc3M+DQogICAgPC9hdXRob3I+ DQoNCiAgICA8YXV0aG9yIGluaXRpYWxzPSJOIiBzdXJuYW1lPSJIaWxsaWFyZCIgZnVsbG5hbWU9 Ik5pY2sgSGlsbGlhcmQiPg0KICAgICAgPG9yZ2FuaXphdGlvbj5JTkVYPC9vcmdhbml6YXRpb24+ DQogICAgICA8YWRkcmVzcz4NCiAgICAgICAgPHBvc3RhbD4NCiAgICAgICAgICA8c3RyZWV0PjQw MjcgS2luZ3N3b29kIFJvYWQ8L3N0cmVldD4NCiAgICAgICAgICA8Y2l0eT5EdWJsaW48L2NpdHk+ DQogICAgICAgICAgPGNvZGU+MjQ8L2NvZGU+DQogICAgICAgICAgPGNvdW50cnk+SUU8L2NvdW50 cnk+DQogICAgICAgIDwvcG9zdGFsPg0KICAgICAgICA8ZW1haWw+bmlja0BpbmV4LmllPC9lbWFp bD4NCiAgICAgIDwvYWRkcmVzcz4NCiAgICA8L2F1dGhvcj4NCg0KICAgIDxkYXRlLz4NCg0KICAg IDxhcmVhPlJvdXRpbmc8L2FyZWE+DQogICAgPHdvcmtncm91cD5JRFI8L3dvcmtncm91cD4NCiAg ICA8a2V5d29yZD5CR1A8L2tleXdvcmQ+DQogICAgPGtleXdvcmQ+Y29tbXVuaXRpZXM8L2tleXdv cmQ+DQoNCiAgICA8YWJzdHJhY3Q+DQogICAgICAgIDx0Pg0KICAgICAgICAgICAgVGhpcyBkb2N1 bWVudCBkZXNjcmliZXMgdGhlIEJHUCBMYXJnZSBDb21tdW5pdGllcyBhdHRyaWJ1dGUsIGFuDQog ICAgICAgICAgICBleHRlbnNpb24gdG8gQkdQLTQuIFRoaXMgYXR0cmlidXRlIHByb3ZpZGVzIGEg bWVjaGFuaXNtIHRvDQogICAgICAgICAgICBzaWduYWwgb3BhcXVlIGluZm9ybWF0aW9uIHdpdGhp biBzZXBhcmF0ZSBuYW1lc3BhY2VzIHRvIGFpZCBpbg0KICAgICAgICAgICAgcm91dGluZyBtYW5h Z2VtZW50LiBUaGUgYXR0cmlidXRlIGlzIHN1aXRhYmxlIGZvciB1c2Ugd2l0aA0KICAgICAgICAg ICAgZm91ci1vY3RldCBBU05zLg0KICAgICAgICA8L3Q+DQogICAgPC9hYnN0cmFjdD4NCg0KICAg IDxub3RlIHRpdGxlPSJSZXF1aXJlbWVudHMgTGFuZ3VhZ2UiPg0KICAgICAgICA8dD4NCiAgICAg ICAgICAgIFRoZSBrZXkgd29yZHMgIk1VU1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlSRUQiLCAiU0hB TEwiLCAiU0hBTEwgTk9UIiwNCiAgICAgICAgICAgICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJS RUNPTU1FTkRFRCIsICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbg0KICAgICAgICAgICAgdGhpcyBk b2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluDQogICAgICAgICAg ICA8eHJlZiB0YXJnZXQ9IlJGQzIxMTkiLz4uDQogICAgICAgIDwvdD4NCiAgICA8L25vdGU+DQoN CiAgPC9mcm9udD4NCg0KICA8bWlkZGxlPg0KICAgICAgPHNlY3Rpb24gdGl0bGU9IkludHJvZHVj dGlvbiI+DQogICAgICAgICAgPHQ+DQogICAgICAgICAgICAgIEJHUCBpbXBsZW1lbnRhdGlvbnMg dHlwaWNhbGx5IHN1cHBvcnQgYSByb3V0aW5nIHBvbGljeSBsYW5ndWFnZQ0KICAgICAgICAgICAg ICB0byBjb250cm9sIHRoZSBkaXN0cmlidXRpb24gb2Ygcm91dGluZyBpbmZvcm1hdGlvbi4gIE5l dHdvcmsNCiAgICAgICAgICAgICAgb3BlcmF0b3JzIGF0dGFjaCBCR1AgY29tbXVuaXRpZXMgdG8g cm91dGVzIHRvIGFzc29jaWF0ZSBwYXJ0aWN1bGFyDQogICAgICAgICAgICAgIHByb3BlcnRpZXMg d2l0aCB0aGVzZSByb3V0ZXMuICBUaGVzZSBwcm9wZXJ0aWVzIG1heSBpbmNsdWRlDQogICAgICAg ICAgICAgIGluZm9ybWF0aW9uIHN1Y2ggYXMgdGhlIHJvdXRlIG9yaWdpbiBsb2NhdGlvbiwgb3Ig c3BlY2lmaWNhdGlvbg0KICAgICAgICAgICAgICBvZiBhIHJvdXRpbmcgcG9saWN5IGFjdGlvbiB0 byBiZSB0YWtlbiwgb3Igb25lIHRoYXQgaGFzIGJlZW4NCiAgICAgICAgICAgICAgdGFrZW4sIGFu ZCBpcyBhcHBsaWVkIHRvIGFsbCByb3V0ZXMgY29udGFpbmVkIGluIGEgQkdQIFVwZGF0ZSBNZXNz YWdlIHdoZXJlDQogICAgICAgICAgICAgIHRoZSBDb21tdW5pdGllcyBBdHRyaWJ1dGUgaXMgaW5j bHVkZWQuDQogICAgICAgICAgICAgIEJlY2F1c2UgQkdQIGNvbW11bml0aWVzIGFyZSBvcHRpb25h bCB0cmFuc2l0aXZlIEJHUA0KICAgICAgICAgICAgICBhdHRyaWJ1dGVzLCBCR1AgY29tbXVuaXRp ZXMgbWF5IGJlIGFjdGVkIHVwb24gb3Igb3RoZXJ3aXNlIHVzZWQNCiAgICAgICAgICAgICAgYnkg cm91dGluZyBwb2xpY2llcyBpbiBvdGhlciBBdXRvbm9tb3VzIFN5c3RlbXMgKEFTZXMpIG9uIHRo ZQ0KICAgICAgICAgICAgICBJbnRlcm5ldC4NCiAgICAgICAgICA8L3Q+DQogICAgICAgICAgPHQ+ DQogICAgICAgICAgICAgIEJHUCBDb21tdW5pdGllcyBhdHRyaWJ1dGVzIGFyZQ0KICAgICAgICAg ICAgICBmb3VyLW9jdGV0IHZhbHVlcyA8eHJlZiB0YXJnZXQ9IlJGQzE5OTciLz4uIENvbW1vbiB1 c2Ugb2YNCiAgICAgICAgICAgICAgdGhpcyBhdHRyaWJ1dGUgdHlwZSBzcGxpdHMgdGhpcyBzaW5n bGUgMzItYml0IHZhbHVlIGZpZWxkIGludG8gdHdvIDE2LWJpdCB2YWx1ZXMuDQogICAgICAgICAg ICAgIFRoZSBtb3N0DQogICAgICAgICAgICAgIHNpZ25pZmljYW50IHdvcmQgaXMgaW50ZXJwcmV0 ZWQgYXMgYW4gQXV0b25vbW91cyBTeXN0ZW0gTnVtYmVyDQogICAgICAgICAgICAgIChBU04pIGFu ZCB0aGUgbGVhc3Qgc2lnbmlmaWNhbnQgd29yZCBpcyBhIGxvY2FsbHkgZGVmaW5lZCB2YWx1ZQ0K ICAgICAgICAgICAgICB3aG9zZSBtZWFuaW5nIGlzIGFzc2lnbmVkIGJ5IHRoZSBvcGVyYXRvciBv ZiB0aGUgQXV0b25vbW91cw0KICAgICAgICAgICAgICBTeXN0ZW0gaW4gdGhlIG1vc3Qgc2lnbmlm aWNhbnQgd29yZC4NCiAgICAgICAgICA8L3Q+DQogICAgICAgICAgPHQ+DQogICAgICAgICAgICAg IFNpbmNlIHRoZSBhZG9wdGlvbiBvZiBmb3VyLW9jdGV0IEFTTnMgPHhyZWYgdGFyZ2V0PSJSRkM2 NzkzIi8+LCB0aGUNCiAgICAgICAgICAgICAgQkdQIENvbW11bml0aWVzIGF0dHJpYnV0ZSBjYW4g bm8gbG9uZ2VyIGFjY29tbW9kYXRlIHRoZSBhYm92ZQ0KICAgICAgICAgICAgICBlbmNvZGluZywg YXMgYSB0d28tb2N0ZXQgd29yZCBjYW5ub3QgZml0IGEgZm91ci1vY3RldCBBU04uDQogICAgICAg ICAgICAgIFRoZSBCR1AgRXh0ZW5kZWQgQ29tbXVuaXRpZXMgYXR0cmlidXRlIDx4cmVmIHRhcmdl dD0iUkZDNDM2MCIvPiBpcyBhbHNvIHVuc3VpdGFibGUsIGFzDQogICAgICAgICAgICAgIHRoZSBw cm90b2NvbCBsaW1pdCBvZiBzaXggb2N0ZXRzIGZvciBlYWNoIGNvbW11bml0eSB2YWx1ZSBjYW5u b3QNCiAgICAgICAgICAgICAgYWNjb21tb2RhdGUgYm90aCBhIGZvdXItb2N0ZXQgR2xvYmFsIEFk bWluaXN0cmF0b3IgdmFsdWUgYW5kIGEgZm91ci1vY3RldA0KICAgICAgICAgICAgICBMb2NhbCBB ZG1pbmlzdHJhdG9yIHZhbHVlLiBUaGlzIGxpbWl0YXRpb24gcHJlY2x1ZGVzIHRoZSBjb21tb24N CiAgICAgICAgICAgICAgb3BlcmF0aW9uYWwgcHJhY3RpY2Ugb2YgZW5jb2RpbmcgYSB0YXJnZXQg QVNOIGluIHRoZSBMb2NhbCBBZG1pbmlzdHJhdG9yDQogICAgICAgICAgICAgIGZpZWxkLg0KICAg ICAgICAgIDwvdD4NCiAgICAgICAgICA8dD4NCiAgICAgICAgICAgICAgVG8gYWRkcmVzcyB0aGVz ZSBzaG9ydGNvbWluZ3MsIHRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIEJHUCBMYXJnZQ0KICAgICAg ICAgICAgICBDb21tdW5pdGllcyBhdHRyaWJ1dGUgZW5jb2RlZCBhcyBvbmUgb3IgbW9yZSB0d2Vs dmUtb2N0ZXQNCiAgICAgICAgICAgICAgdmFsdWVzLCBlYWNoIGNvbnNpc3Rpbmcgb2YgYSBmb3Vy LW9jdGV0IEdsb2JhbCBBZG1pbmlzdHJhdG9yDQogICAgICAgICAgICAgIGZpZWxkIGFuZCB0d28g Zm91ci1vY3RldCBvcGVyYXRvci1kZWZpbmVkIGZpZWxkcywgZWFjaCBvZg0KICAgICAgICAgICAg ICB3aGljaCBjYW4gYmUgdXNlZCB0byBkZW5vdGUgcHJvcGVydGllcyBvciBhY3Rpb25zIHNpZ25p ZmljYW50DQogICAgICAgICAgICAgIHRvIHRoZSBvcGVyYXRvciBvZiB0aGUgQXV0b25vbW91cyBT eXN0ZW0gYXNzaWduaW5nIHRoZQ0KICAgICAgICAgICAgICB2YWx1ZXMuDQogICAgICAgICAgPC90 Pg0KICAgIDwvc2VjdGlvbj4NCg0KICAgIDxzZWN0aW9uIHRpdGxlPSJCR1AgTGFyZ2UgQ29tbXVu aXRpZXMgQXR0cmlidXRlIj4NCiAgICAgICAgPHQ+DQogICAgICAgICAgICBUaGlzIGRvY3VtZW50 IGNyZWF0ZXMgdGhlIEJHUCBMYXJnZSBDb21tdW5pdGllcyBhdHRyaWJ1dGUNCiAgICAgICAgICAg IGFzIGFuIG9wdGlvbmFsIHRyYW5zaXRpdmUgcGF0aCBhdHRyaWJ1dGUgb2YgdmFyaWFibGUgbGVu Z3RoLiAgQWxsDQogICAgICAgICAgICByb3V0ZXMgd2l0aCB0aGUgQkdQIExhcmdlIENvbW11bml0 aWVzIGF0dHJpYnV0ZSBiZWxvbmcgdG8gdGhlDQogICAgICAgICAgICBjb21tdW5pdHkgc3BlY2lm aWVkIGluIHRoZSBhdHRyaWJ1dGUuDQogICAgICAgIDwvdD4NCiAgICAgICAgPHQ+DQogICAgICAg ICAgICBUaGUgYXR0cmlidXRlIGNvbnNpc3RzIG9mIG9uZSBvciBtb3JlIHR3ZWx2ZS1vY3RldCB2 YWx1ZXMuIEVhY2gNCiAgICAgICAgICAgIHR3ZWx2ZS1vY3RldCBCR1AgTGFyZ2UgQ29tbXVuaXRp ZXMgdmFsdWUgcmVwcmVzZW50cyB0aHJlZSBmb3VyLW9jdGV0IHZhbHVlcywgYXMNCiAgICAgICAg ICAgIGZvbGxvd3M6DQo8ZmlndXJlIGFsaWduPSJjZW50ZXIiPjxhcnR3b3JrPjwhW0NEQVRBWw0K IDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAg ICAgIDMNCiAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0 IDUgNiA3IDggOSAwIDENCistKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rDQp8ICAgICAgICAgICAgICAgICAgICAgIEdsb2JhbCBB ZG1pbmlzdHJhdG9yICAgICAgICAgICAgICAgICAgICAgfA0KKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCnwgICAgICAgICAg ICAgICAgICAgICAgIExvY2FsIERhdGEgUGFydCAxICAgICAgICAgICAgICAgICAgICAgICB8DQor LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKw0KfCAgICAgICAgICAgICAgICAgICAgICAgTG9jYWwgRGF0YSBQYXJ0IDIgICAgICAg ICAgICAgICAgICAgICAgIHwNCistKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQpdXT48L2FydHdvcms+PC9maWd1cmU+DQogICAg ICAgIDwvdD4NCiAgICAgICAgPHQ+DQogICAgICAgICAgICA8bGlzdCBzdHlsZT0iaGFuZ2luZyI+ DQogICAgICAgICAgICAgICAgPHQgaGFuZ1RleHQ9Ikdsb2JhbCBBZG1pbmlzdHJhdG9yOiI+DQog ICAgICAgICAgICAgICAgICAgIEEgZm91ci1vY3RldCBuYW1lc3BhY2UgaWRlbnRpZmllci4NCiAg ICAgICAgICAgICAgICA8L3Q+DQogICAgICAgICAgICAgICAgPHQgaGFuZ1RleHQ9IkxvY2FsIERh dGEgUGFydCAxOiI+QSBmb3VyLW9jdGV0IG9wZXJhdG9yLWRlZmluZWQgdmFsdWUuPC90Pg0KICAg ICAgICAgICAgICAgIDx0IGhhbmdUZXh0PSJMb2NhbCBEYXRhIFBhcnQgMjoiPkEgZm91ci1vY3Rl dCBvcGVyYXRvci1kZWZpbmVkIHZhbHVlLjwvdD4NCiAgICAgICAgICAgIDwvbGlzdD4NCiAgICAg ICAgPC90Pg0KICAgICAgICA8dD4NCiAgICAgICAgICAgIFRoZSBHbG9iYWwgQWRtaW5pc3RyYXRv ciBmaWVsZCBpcyBpbnRlbmRlZCB0byBhbGxvdyBkaWZmZXJlbnQNCiAgICAgICAgICAgIEF1dG9u b21vdXMgU3lzdGVtcyB0byBkZWZpbmUgQkdQIExhcmdlIENvbW11bml0aWVzIHdpdGhvdXQNCiAg ICAgICAgICAgIGNvbGxpc2lvbi4NCiAgICAgICAgICAgIFRoaXMgZmllbGQgTVVTVCBiZSBlaXRo ZXIgb25lIG9mIHRoZSByZXNlcnZlZCB2YWx1ZXMgYXMgZGVmaW5lZCBiZWxvdywNCiAgICAgICAg ICAgIG9yIGFuIEF1dG9ub21vdXMgU3lzdGVtIE51bWJlciAoQVNOKS4gSWYgaXQgaXMgYSByZXNl cnZlZCB2YWx1ZSwgdGhlbg0KICAgICAgICAgICAgdGhlIExvY2FsIERhdGEgUGFydHMgYXJlIGFz IGRlZmluZWQgYnkgdGhlIHJlc2VydmVkIHZhbHVlLg0KICAgICAgICAgICAgSWYgaXQgaXMgYW4g QVNOIHRoZW4gdGhlIExvY2FsIERhdGEgUGFydHMgYXJlIHRvIGJlIGludGVycHJldGVkDQogICAg ICAgICAgICBhcyBkZWZpbmVkIGJ5IHRoZSBvd25lciBvZiB0aGUgQVNOLg0KICAgICAgICAgICAg V2hlbiB1c2VkIGluIHNtYWxsIGNsb3NlZCBlbnZpcm9ubWVudHMsIHRoZSB2YWx1ZXMgTUFZIGJl IGFueSB2YWx1ZXMuDQogICAgICAgICAgICBUaHVzLCBpbXBsZW1lbnRhdGlvbnMgTVVTVCBhbGxv dyB0aGUgb3BlcmF0b3IgdG8gc3BlY2lmeSBhbnkNCiAgICAgICAgICAgIHZhbHVlIGZvciBhbnkg b2YgdGhlIGZpZWxkcy4NCiAgICAgICAgPC90Pg0KICAgICAgICA8dD4NCiAgICAgICAgICAgIFRo ZXJlIGlzIG5vIHNpZ25pZmljYW5jZSB0byB0aGUgb3JkZXIgaW4gd2hpY2ggQkdQIExhcmdlDQog ICAgICAgICAgICBDb21tdW5pdGllcyBhcmUgZW5jb2RlZCBpbiB0aGUgQkdQIHBhdGggYXR0cmli dXRlIHBheWxvYWQuIEEgQkdQDQogICAgICAgICAgICBzcGVha2VyIGNhbiB0cmFuc21pdCB0aGVt IGluIGFueSBvcmRlci4NCiAgICAgICAgPC90Pg0KICAgICAgICA8dD4NCiAgICAgICAgICAgIER1 cGxpY2F0ZSBCR1AgTGFyZ2UgQ29tbXVuaXRpZXMgU0hPVUxEIE5PVCBiZSB0cmFuc21pdHRlZC4g IEENCiAgICAgICAgICAgIHJlY2VpdmluZyBzcGVha2VyIFNIT1VMRCBzaWxlbnRseSByZW1vdmUg ZHVwbGljYXRlIEJHUCBMYXJnZQ0KICAgICAgICAgICAgQ29tbXVuaXRpZXMgZnJvbSBhIEJHUCBV UERBVEUgbWVzc2FnZS4NCiAgICAgICAgPC90Pg0KICAgIDwvc2VjdGlvbj4NCg0KICAgIDxzZWN0 aW9uIHRpdGxlPSJBZ2dyZWdhdGlvbiI+DQogICAgICAgIDx0Pg0KICAgICAgICAgICAgSWYgYSBy YW5nZSBvZiByb3V0ZXMgaXMgYWdncmVnYXRlZCwgdGhlbiB0aGUgcmVzdWx0aW5nIGFnZ3JlZ2F0 ZQ0KICAgICAgICAgICAgc2hvdWxkIGhhdmUgYSBCR1AgTGFyZ2UgQ29tbXVuaXRpZXMgYXR0cmli dXRlIHdoaWNoIGNvbnRhaW5zIGFsbA0KICAgICAgICAgICAgb2YgdGhlIEJHUCBMYXJnZSBDb21t dW5pdGllcyBhdHRyaWJ1dGVzIGZyb20gYWxsIG9mIHRoZQ0KICAgICAgICAgICAgYWdncmVnYXRl ZCByb3V0ZXMuDQogICAgICAgIDwvdD4NCiAgICA8L3NlY3Rpb24+DQoNCgk8c2VjdGlvbiB0aXRs ZT0iQ2Fub25pY2FsIFJlcHJlc2VudGF0aW9uIj4NCiAgICAgICAgPHQ+DQogICAgICAgICAgICBU aGUgY2Fub25pY2FsIHJlcHJlc2VudGF0aW9uIG9mIEJHUCBMYXJnZSBDb21tdW5pdGllcyBpcyB0 aHJlZSBzZXBhcmF0ZQ0KICAgICAgICAgICAgdW5zaWduZWQgaW50ZWdlcnMgaW4gZGVjaW1hbCBu b3RhdGlvbiBpbiB0aGUgZm9sbG93aW5nIG9yZGVyOg0KICAgICAgICAgICAgR2xvYmFsIEFkbWlu aXN0cmF0b3IsIExvY2FsIERhdGEgMSwgTG9jYWwgRGF0YSAyLiAgTnVtYmVycyBNVVNUIE5PVA0K ICAgICAgICAgICAgY29udGFpbiBsZWFkaW5nIHplcm9zOyBhIHplcm8gdmFsdWUgTVVTVCBiZSBy ZXByZXNlbnRlZCB3aXRoIGENCiAgICAgICAgICAgIHNpbmdsZSB6ZXJvLiBFYWNoIG51bWJlciBp cyBzZXBhcmF0ZWQgZnJvbSB0aGUgbmV4dCBieSBhIHNpbmdsZSBjb2xvbi4NCiAgICAgICAgICAg IEZvciBleGFtcGxlOiA2NDQ5Njo0Mjk0OTY3Mjk1OjIsIDY0NDk2OjA6MC4NCiAgICAgICAgPC90 Pg0KICAgICAgICA8dD4NCiAgICAgICAgICAgIEJHUCBMYXJnZSBDb21tdW5pdGllcyBNVVNUIGJl IHJlcHJlc2VudGVkIGluIHRoZSBjYW5vbmljYWwgcmVwcmVzZW50YXRpb24uDQogICAgICAgICAg ICBBIHJvdXRpbmcgcG9saWN5IGxhbmd1YWdlIE1BWSB1c2Ugc2VwYXJhdG9ycyBvdGhlciB0aGFu IGNvbG9ucy4NCiAgICAgICAgICAgIEEgcm91dGluZyBwb2xpY3kgbGFuZ3VhZ2UgTUFZIHVzZSBw cmVmaXhlcyBhbmQgcG9zdGZpeGVzIGJlZm9yZSBhbmQgYWZ0ZXIgYSBMYXJnZSBDb21tdW5pdHku DQogICAgICAgIDwvdD4NCiAgICA8L3NlY3Rpb24+DQoNCiAgICA8c2VjdGlvbiB0aXRsZT0iUmVz ZXJ2ZWQgQkdQIExhcmdlIENvbW11bml0eSB2YWx1ZXMiIGFuY2hvcj0icmVzZXJ2ZWRfdmFscyI+ DQogICAgICAgIDx0Pg0KICAgICAgICAgICAgVGhlIGZvbGxvd2luZyBHbG9iYWwgQWRtaW5pc3Ry YXRvciB2YWx1ZXMgYXJlIHJlc2VydmVkOiAwICh0aGUNCiAgICAgICAgICAgIGZpcnN0IEFTTikg PHhyZWYgdGFyZ2V0PSJSRkM3NjA3Ii8+LCA2NTUzNSAoVUlOVDE2X01BWCkgYW5kDQogICAgICAg ICAgICA0Mjk0OTY3Mjk1ICh0aGUgbGFzdCBBU04pIDx4cmVmIHRhcmdldD0iUkZDNzMwMCIvPi4g IE9wZXJhdG9ycw0KICAgICAgICAgICAgU0hPVUxEIE5PVCB1c2UgdGhlc2UgR2xvYmFsIEFkbWlu aXN0cmF0b3IgdmFsdWVzLg0KICAgICAgICA8L3Q+DQogICAgICAgIDx0Pg0KICAgICAgICAgICAg QWx0aG91Z2ggdGhpcyBkb2N1bWVudCBkb2VzIG5vdCBkZWZpbmUgYW55IFNwZWNpYWwtVXNlIEJH UCBMYXJnZQ0KICAgICAgICAgICAgQ29tbXVuaXRpZXMsIHRoZSBHbG9iYWwgQWRtaW5pc3RyYXRv ciB2YWx1ZXMgc3BlY2lmaWVkIGFib3ZlIGNvdWxkDQogICAgICAgICAgICBiZSB1c2VkIGlmIHRo ZXJlIGlzIGEgZnV0dXJlIG5lZWQgZm9yIHRoZW0uDQogICAgICAgIDwvdD4NCiAgICA8L3NlY3Rp b24+DQoNCiAgICA8c2VjdGlvbiB0aXRsZT0iRXJyb3IgSGFuZGxpbmciPg0KICAgICAgICA8dD4N CiAgICAgICAgICAgIFRoZSBlcnJvciBoYW5kbGluZyBvZiBCR1AgTGFyZ2UgQ29tbXVuaXRpZXMg aXMgYXMgZm9sbG93czoNCiAgICAgICAgPC90Pg0KICAgICAgICA8dD4NCiAgICAgICAgICAgIDxs aXN0IHN0eWxlPSJzeW1ib2xzIj4NCiAgICAgICAgICAgICAgICA8dD4NCiAgICAgICAgICAgICAg ICAgICAgQSBCR1AgTGFyZ2UgQ29tbXVuaXRpZXMgYXR0cmlidXRlIFNIQUxMIGJlIGNvbnNpZGVy ZWQNCiAgICAgICAgICAgICAgICAgICAgbWFsZm9ybWVkIGlmIHRoZQ0KICAgICAgICAgICAgICAg ICAgICBsZW5ndGggb2YgdGhlIEJHUCBMYXJnZSBDb21tdW5pdGllcyB2YWx1ZSwgZXhwcmVzc2Vk IGluIG9jdGV0cywgDQogICAgICAgICAgICAgICAgICAgIGlzIG5vdCBhIG5vbi16ZXJvIG11bHRp cGxlIG9mIDEyLg0KICAgICAgICAgICAgICAgIDwvdD4NCiAgICAgICAgICAgICAgICA8dD4NCiAg ICAgICAgICAgICAgICAgICAgQSBCR1AgVVBEQVRFIG1lc3NhZ2Ugd2l0aCBhIG1hbGZvcm1lZCBC R1AgTGFyZ2UgQ29tbXVuaXRpZXMNCiAgICAgICAgICAgICAgICAgICAgYXR0cmlidXRlIFNIQUxM IGJlIGhhbmRsZWQgdXNpbmcgdGhlIGFwcHJvYWNoIG9mICJ0cmVhdC1hcy13aXRoZHJhdyINCiAg ICAgICAgICAgICAgICAgICAgYXMgZGVzY3JpYmVkIGluIDx4cmVmIHRhcmdldD0iUkZDNzYwNiI+ c2VjdGlvbiAyPC94cmVmPi4NCiAgICAgICAgICAgICAgICA8L3Q+DQogICAgICAgICAgICA8L2xp c3Q+DQogICAgICAgIDwvdD4NCiAgICAgICAgPHQ+DQogICAgICAgICAgICBUaGUgQkdQIExhcmdl IENvbW11bml0aWVzIEdsb2JhbCBBZG1pbmlzdHJhdG9yIGZpZWxkIG1heSBjb250YWluDQogICAg ICAgICAgICBhbnkgdmFsdWUsIGFuZCBhIEJHUCBMYXJnZSBDb21tdW5pdGllcyBhdHRyaWJ1dGUg TVVTVCBOT1QgYmUNCiAgICAgICAgICAgIGNvbnNpZGVyZWQgbWFsZm9ybWVkIGlmIHRoZSBHbG9i YWwgQWRtaW5pc3RyYXRvciBmaWVsZCBjb250YWlucw0KICAgICAgICAgICAgYW4gdW5hbGxvY2F0 ZWQsIHVuYXNzaWduZWQgb3IgcmVzZXJ2ZWQgQVNOIG9yIGlzIHNldCB0byBvbmUgb2YNCiAgICAg ICAgICAgIHRoZSByZXNlcnZlZCBCR1AgTGFyZ2UgQ29tbXVuaXR5IHZhbHVlcyBkZWZpbmVkIGlu IDx4cmVmDQogICAgICAgICAgICB0YXJnZXQ9InJlc2VydmVkX3ZhbHMiIC8+Lg0KICAgICAgICA8 L3Q+DQogICAgPC9zZWN0aW9uPg0KDQogICAgPHNlY3Rpb24gdGl0bGU9IlNlY3VyaXR5IENvbnNp ZGVyYXRpb25zIj4NCiAgICAgICAgPHQ+DQogICAgICAgICAgICBUaGlzIGV4dGVuc2lvbiB0byBC R1AgaGFzIHNpbWlsYXIgc2VjdXJpdHkgaW1wbGljYXRpb25zIGFzIEJHUA0KICAgICAgICAgICAg Q29tbXVuaXRpZXMgPHhyZWYgdGFyZ2V0PSJSRkMxOTk3Ii8+Lg0KICAgICAgICA8L3Q+DQogICAg ICAgIDx0Pg0KICAgICAgICAgICAgVGhpcyBkb2N1bWVudCBkb2VzIG5vdCBjaGFuZ2UgYW55IHVu ZGVybHlpbmcgc2VjdXJpdHkgaXNzdWVzDQogICAgICAgICAgICBhc3NvY2lhdGVkIHdpdGggYW55 IG90aGVyIEJHUCBDb21tdW5pdGllcyBtZWNoYW5pc20uICBTcGVjaWZpY2FsbHksDQogICAgICAg ICAgICBhbiBBUyByZWx5aW5nIG9uIHRoZSBCR1AgTGFyZ2UgQ29tbXVuaXRpZXMgYXR0cmlidXRl IGNhcnJpZWQgaW4gQkdQDQogICAgICAgICAgICBtdXN0IGhhdmUgdHJ1c3QgaW4gZXZlcnkgb3Ro ZXIgQVMgaW4gdGhlIHBhdGgsIGFzIGFueSBpbnRlcm1lZGlhdGUNCiAgICAgICAgICAgIEF1dG9u b21vdXMgU3lzdGVtIGluIHRoZSBwYXRoIG1heSBoYXZlIGFkZGVkLCBkZWxldGVkLCBvciBhbHRl cmVkDQogICAgICAgICAgICB0aGUgQkdQIExhcmdlIENvbW11bml0aWVzIGF0dHJpYnV0ZS4gU3Bl Y2lmeWluZyB0aGUgbWVjaGFuaXNtIHRvDQogICAgICAgICAgICBwcm92aWRlIHN1Y2ggdHJ1c3Qg aXMgYmV5b25kIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50Lg0KICAgICAgICA8L3Q+DQogICAg ICAgIDx0Pg0KICAgICAgICAgICAgTmV0d29yayBhZG1pbmlzdHJhdG9ycyBzaG91bGQgbm90ZSB0 aGUgcmVjb21tZW5kYXRpb25zIGluDQogICAgICAgICAgICBTZWN0aW9uIDExIG9mIEJHUCBPcGVy YXRpb25zIGFuZCBTZWN1cml0eSA8eHJlZg0KICAgICAgICAgICAgdGFyZ2V0PSJSRkM3NDU0Ii8+ Lg0KICAgICAgICA8L3Q+DQogICA8L3NlY3Rpb24+DQogICANCiAgIDxzZWN0aW9uIHRpdGxlPSJJ bXBsZW1lbnRhdGlvbiBzdGF0dXMgLSBSRkMgRURJVE9SOiBSRU1PVkUgQkVGT1JFIFBVQkxJQ0FU SU9OIj4NCiAgICAgICA8dD4NCiAgICAgICAgICAgVGhpcyBzZWN0aW9uIHJlY29yZHMgdGhlIHN0 YXR1cyBvZiBrbm93biBpbXBsZW1lbnRhdGlvbnMgb2YgdGhlDQogICAgICAgICAgIHByb3RvY29s IGRlZmluZWQgYnkgdGhpcyBzcGVjaWZpY2F0aW9uIGF0IHRoZSB0aW1lIG9mIHBvc3Rpbmcgb2YN CiAgICAgICAgICAgdGhpcyBJbnRlcm5ldC1EcmFmdCwgYW5kIGlzIGJhc2VkIG9uIGEgcHJvcG9z YWwgZGVzY3JpYmVkIGluDQogICAgICAgICAgIDx4cmVmIHRhcmdldD0iUkZDNzk0MiIgLz4uIFRo ZSBkZXNjcmlwdGlvbiBvZiBpbXBsZW1lbnRhdGlvbnMgaW4gdGhpcw0KICAgICAgICAgICBzZWN0 aW9uIGlzIGludGVuZGVkIHRvIGFzc2lzdCB0aGUgSUVURiBpbiBpdHMgZGVjaXNpb24gcHJvY2Vz c2VzIGluDQogICAgICAgICAgIHByb2dyZXNzaW5nIGRyYWZ0cyB0byBSRkNzLiAgUGxlYXNlIG5v dGUgdGhhdCB0aGUgbGlzdGluZyBvZiBhbnkNCiAgICAgICAgICAgaW5kaXZpZHVhbCBpbXBsZW1l bnRhdGlvbiBoZXJlIGRvZXMgbm90IGltcGx5IGVuZG9yc2VtZW50IGJ5IHRoZQ0KICAgICAgICAg ICBJRVRGLiAgRnVydGhlcm1vcmUsIG5vIGVmZm9ydCBoYXMgYmVlbiBzcGVudCB0byB2ZXJpZnkg dGhlDQogICAgICAgICAgIGluZm9ybWF0aW9uIHByZXNlbnRlZCBoZXJlIHRoYXQgd2FzIHN1cHBs aWVkIGJ5IElFVEYgY29udHJpYnV0b3JzLg0KICAgICAgICAgICBUaGlzIGlzIG5vdCBpbnRlbmRl ZCBhcywgYW5kIG11c3Qgbm90IGJlIGNvbnN0cnVlZCB0byBiZSwgYSBjYXRhbG9nDQogICAgICAg ICAgIG9mIGF2YWlsYWJsZSBpbXBsZW1lbnRhdGlvbnMgb3IgdGhlaXIgZmVhdHVyZXMuICBSZWFk ZXJzIGFyZSBhZHZpc2VkDQogICAgICAgICAgIHRvIG5vdGUgdGhhdCBvdGhlciBpbXBsZW1lbnRh dGlvbnMgbWF5IGV4aXN0Lg0KICAgICAgIDwvdD4NCiAgICAgICA8dD4NCiAgICAgICAgICAgQXMg b2YgdG9kYXkgdGhlc2UgdmVuZG9ycyBoYXZlIHByb2R1Y2VkIGFuIGltcGxlbWVudGF0aW9uIG9m IEJHUCBMYXJnZQ0KICAgICAgICAgICBDb21tdW5pdGllczoNCiAgICAgICAgICAgPGxpc3Qgc3R5 bGU9InN5bWJvbHMiPg0KICAgICAgICAgICAgICAgPHQ+Q2lzY28gSU9TIFhSPC90Pg0KICAgICAg ICAgICAgICAgPHQ+RXhhQkdQPC90Pg0KICAgICAgICAgICAgICAgPHQ+R29CR1A8L3Q+DQogICAg ICAgICAgICAgICA8dD5CSVJEPC90Pg0KICAgICAgICAgICAgICAgPHQ+T3BlbkJHUEQ8L3Q+DQog ICAgICAgICAgICAgICA8dD5wbWFjY3Q8L3Q+DQogICAgICAgICAgICAgICA8dD5RdWFnZ2E8L3Q+ DQogICAgICAgICAgIDwvbGlzdD4NCiAgICAgICA8L3Q+DQogICAgICAgPHQ+DQogICAgICAgICAg IFRoZSBsYXRlc3QgaW1wbGVtZW50YXRpb24gbmV3cyBpcyB0cmFja2VkIGF0DQogICAgICAgICAg IDxlcmVmIHRhcmdldD0iaHR0cDovL2xhcmdlYmdwY29tbXVuaXRpZXMubmV0Ij5odHRwOi8vbGFy Z2ViZ3Bjb21tdW5pdGllcy5uZXQvPC9lcmVmPi4NCiAgICAgICA8L3Q+DQogICA8L3NlY3Rpb24+ DQoNCiAgICA8c2VjdGlvbiB0aXRsZT0iSUFOQSBDb25zaWRlcmF0aW9ucyI+DQogICAgICAgIDx0 Pg0KICAgICAgICAgICAgSUFOQSBoYXMgbWFkZSBhbiBFYXJseSBBbGxvY2F0aW9uIG9mIHRoZSB2 YWx1ZSAzMiAoTEFSR0VfQ09NTVVOSVRZKQ0KICAgICAgICAgICAgaW4gdGhlICJCR1AgUGF0aCBB dHRyaWJ1dGVzIiByZWdpc3RyeSB1bmRlciB0aGUgIkJvcmRlciBHYXRld2F5DQogICAgICAgICAg ICBQcm90b2NvbCAoQkdQKSBQYXJhbWV0ZXJzIiBncm91cCBhbmQgaXMgbm93IGFza2VkIHRvIG1h a2UgdGhhdA0KICAgICAgICAgICAgUGVybWFuZW50Lg0KICAgICAgICA8L3Q+DQogICAgPC9zZWN0 aW9uPg0KDQogICAgPHNlY3Rpb24gdGl0bGU9IkNvbnRyaWJ1dG9ycyI+DQogICAgICAgIDx0Pg0K ICAgICAgICAgICAgVGhlIGZvbGxvd2luZyBwZW9wbGUgY29udHJpYnV0ZWQgc2lnbmlmaWNhbnRs eSB0byB0aGUgY29udGVudCBvZg0KICAgICAgICAgICAgdGhlIGRvY3VtZW50Og0KICAgICAgICA8 L3Q+DQogICAgICAgIDxmaWd1cmU+DQogICAgICAgICAgICA8cHJlYW1ibGU+PC9wcmVhbWJsZT4N CiAgICAgICAgICAgIDxhcnR3b3JrPg0KSm9obiBIZWFzbGV5DQpOVFQgQ29tbXVuaWNhdGlvbnMN Cg0KRW1haWw6IGhlYXNAc2hydWJiZXJ5Lm5ldA0KPC9hcnR3b3JrPg0KPHBvc3RhbWJsZT48L3Bv c3RhbWJsZT4NCjwvZmlndXJlPg0KPC9zZWN0aW9uPg0KDQogICAgPHNlY3Rpb24gdGl0bGU9IkFj a25vd2xlZGdtZW50cyI+DQogICAgICAgIDx0Pg0KICAgICAgICAgICAgVGhlIGF1dGhvcnMgd291 bGQgbGlrZSB0byB0aGFuayBSdWVkaWdlciBWb2xrLCBSdXNzIFdoaXRlLCBBY2VlDQogICAgICAg ICAgICBMaW5kZW0sIFNoeWFtIFNldGh1cmFtLCBKYXJlZCBNYXVjaCwgSm9lbCBNLiBIYWxwZXJu LCBKZWZmcmV5IEhhYXMsDQogICAgICAgICAgICBHdW50ZXIgdmFuIGRlIFZlbGRlLCBNYXJjbyBN YXJ6ZXR0aSwgRWR1YXJkbyBBc2NlbmNvIFJlaXMsIE1hcmsNCiAgICAgICAgICAgIFNjaG91dGVu LCBQYXVsIEhvb2dzdGVkZXIsIE1hcnRpam4gU2NobWlkdCwgR3JlZyBIYW5raW5zLCBCZXJ0cmFu ZA0KICAgICAgICAgICAgRHV2aXZpZXIsIEJhcnJ5IE8nRG9ub3ZhbiwgR3J6ZWdvcnogSmFub3N6 a2EsIExpbmRhIER1bmJhciwgTWFyY28NCiAgICAgICAgICAgIERhdmlkcywgR2F1cmFiIFJhaiBV cGFkaGF5YSwgSmVmZiBUYW50c3VyYSwgVGV1biBWaW5rLCBBZGFtDQogICAgICAgICAgICBEYXZl bnBvcnQsIFRoZW9kb3JlIEJhc2NoYWssIFBpZXIgQ2FybG8gQ2hpb2RpLCBOYWJlZWwgQ29ja2Vy LCBJYW4NCiAgICAgICAgICAgIERpY2tpbnNvbiwgSmFuIEJhZ2dlbiwgRHVuY2FuIExvY2t3b29k LCBEYXZpZCBGYXJtZXIsIFJhbmR5IEJ1c2gsDQogICAgICAgICAgICBXaW0gSGVuZGVyaWNreCwg U3RlZmFuIFBsdWcsIEtheSBSZWNodGhpZW4sIFJvYiBTaGFraXIsIFdhcnJlbg0KICAgICAgICAg ICAgS3VtYXJpLCBHZXJ0IERvZXJpbmcsIFRob21hcyBLaW5nLCBNaWthZWwgQWJyYWhhbXNzb24s IFdlc2xleQ0KICAgICAgICAgICAgU3RlZWhvdXdlciwgU2FuZGVyIFN0ZWZmYW5uLCBCcmFkIERy ZWlzYmFjaCwgTWFydGluIE1pbGxuZXJ0LA0KICAgICAgICAgICAgQ2hyaXN0b3BoZXIgTW9ycm93 LCBKYXkgQm9ya2VuaGFnZW4sIEFybm9sZCBOaXBwZXIsIEpvZSBQcm92bywNCiAgICAgICAgICAg IE5pZWxzIEJha2tlciwgQmlsbCBGZW5uZXIsIFRvbSBEYWx5LCBCZW4gTWFkZGlzb24sIEFsZXhh bmRlcg0KICAgICAgICAgICAgQXppbW92LCBCcmlhbiBEaWNrc29uLCBQZXRlciB2YW4gRGlqaywg SnVsaWFuIFNlaWZlcnQsIFRvbSBQZXRjaCwNCiAgICAgICAgICAgIFRvbSBTY2hvbGwsIEFyamVu IFpvbm5ldmVsZCwgUmVtY28gdmFuIE1vb2ssIEFkYW0gQ2hhcHBlbGwsIEp1c3NpDQogICAgICAg ICAgICBQZWx0b2xhLCBLcmlzdGlhbiBMYXJzc29uLCBNYXJrdXMgSGF1c2NoaWxkLCBSaWNoYXJk IFN0ZWVuYmVyZ2VuLA0KICAgICAgICAgICAgRGF2aWQgRnJlZWRtYW4sIFJpY2hhcmQgSGFydG1h bm4gZm9yIHRoZWlyIHN1cHBvcnQsIGluc2lnaHRmdWwNCiAgICAgICAgICAgIHJldmlldyBhbmQg Y29tbWVudHMuDQogICAgICAgIDwvdD4NCiAgICA8L3NlY3Rpb24+DQoNCiAgPC9taWRkbGU+DQoN CiAgPGJhY2s+DQogICAgPHJlZmVyZW5jZXMgdGl0bGU9Ik5vcm1hdGl2ZSBSZWZlcmVuY2VzIj4N CiAgICAgIDw/cmZjIGluY2x1ZGU9InJlZmVyZW5jZS5SRkMuMTk5NyI/Pg0KICAgICAgPD9yZmMg aW5jbHVkZT0icmVmZXJlbmNlLlJGQy4yMTE5Ij8+DQogICAgICA8P3JmYyBpbmNsdWRlPSJyZWZl cmVuY2UuUkZDLjY3OTMiPz4NCiAgICAgIDw/cmZjIGluY2x1ZGU9InJlZmVyZW5jZS5SRkMuNzYw NiI/Pg0KICAgIDwvcmVmZXJlbmNlcz4NCiAgICA8cmVmZXJlbmNlcyB0aXRsZT0iSW5mb3JtYXRp dmUgUmVmZXJlbmNlcyI+DQogICAgICA8P3JmYyBpbmNsdWRlPSJyZWZlcmVuY2UuUkZDLjQzNjAi Pz4NCiAgICAgIDw/cmZjIGluY2x1ZGU9InJlZmVyZW5jZS5SRkMuNzMwMCI/Pg0KICAgICAgPD9y ZmMgaW5jbHVkZT0icmVmZXJlbmNlLlJGQy43NjA3Ij8+DQogICAgICA8P3JmYyBpbmNsdWRlPSJy ZWZlcmVuY2UuUkZDLjc0NTQiPz4NCiAgICAgIDw/cmZjIGluY2x1ZGU9InJlZmVyZW5jZS5SRkMu Nzk0MiI/Pg0KICAgIDwvcmVmZXJlbmNlcz4NCg0KDQogIDwvYmFjaz4NCjwvcmZjPg0K --_004_40D942F5071046D1BF0976C827377479ciscocom_ Content-Type: text/plain; name="draft-ietf-idr-large-community-07.txt" Content-Description: draft-ietf-idr-large-community-07.txt Content-Disposition: attachment; filename="draft-ietf-idr-large-community-07.txt"; size=18213; creation-date="Fri, 04 Nov 2016 14:20:33 GMT"; modification-date="Fri, 04 Nov 2016 14:20:33 GMT" Content-ID: Content-Transfer-Encoding: base64 CgoKCklEUiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgSi4gSGVpdHosIEVkLgpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQ2lzY28KSW50ZW5kZWQgc3RhdHVzOiBTdGFu ZGFyZHMgVHJhY2sgICAgICAgICAgICAgICAgICAgICAgICBKLiBTbmlqZGVycywgRWQuCkV4cGly ZXM6IE1heSA3LCAyMDE3ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIE5UVAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgSy4gUGF0ZWwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQXJyY3VzCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJLiBCYWdkb25h cwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIEVxdWluaXgKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBBLiBTaW1wc29uCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBOb2tpYQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTi4g SGlsbGlhcmQKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBJTkVYCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgTm92ZW1iZXIgMywgMjAxNgoKCiAgICAgICAgICAgICAg ICAgICAgICAgICBCR1AgTGFyZ2UgQ29tbXVuaXRpZXMKICAgICAgICAgICAgICAgICAgIGRyYWZ0 LWlldGYtaWRyLWxhcmdlLWNvbW11bml0eS0wNwoKQWJzdHJhY3QKCiAgIFRoaXMgZG9jdW1lbnQg ZGVzY3JpYmVzIHRoZSBCR1AgTGFyZ2UgQ29tbXVuaXRpZXMgYXR0cmlidXRlLCBhbgogICBleHRl bnNpb24gdG8gQkdQLTQuICBUaGlzIGF0dHJpYnV0ZSBwcm92aWRlcyBhIG1lY2hhbmlzbSB0byBz aWduYWwKICAgb3BhcXVlIGluZm9ybWF0aW9uIHdpdGhpbiBzZXBhcmF0ZSBuYW1lc3BhY2VzIHRv IGFpZCBpbiByb3V0aW5nCiAgIG1hbmFnZW1lbnQuICBUaGUgYXR0cmlidXRlIGlzIHN1aXRhYmxl IGZvciB1c2Ugd2l0aCBmb3VyLW9jdGV0IEFTTnMuCgpSZXF1aXJlbWVudHMgTGFuZ3VhZ2UKCiAg IFRoZSBrZXkgd29yZHMgIk1VU1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAi U0hBTEwgTk9UIiwKICAgIlNIT1VMRCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgIk1B WSIsIGFuZCAiT1BUSU9OQUwiIGluIHRoaXMKICAgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJl dGVkIGFzIGRlc2NyaWJlZCBpbiBbUkZDMjExOV0uCgpTdGF0dXMgb2YgVGhpcyBNZW1vCgogICBU aGlzIEludGVybmV0LURyYWZ0IGlzIHN1Ym1pdHRlZCBpbiBmdWxsIGNvbmZvcm1hbmNlIHdpdGgg dGhlCiAgIHByb3Zpc2lvbnMgb2YgQkNQIDc4IGFuZCBCQ1AgNzkuCgogICBJbnRlcm5ldC1EcmFm dHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZwogICBU YXNrIEZvcmNlIChJRVRGKS4gIE5vdGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJp YnV0ZQogICB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMuICBUaGUgbGlzdCBv ZiBjdXJyZW50IEludGVybmV0LQogICBEcmFmdHMgaXMgYXQgaHR0cDovL2RhdGF0cmFja2VyLmll dGYub3JnL2RyYWZ0cy9jdXJyZW50Ly4KCiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9j dW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocwogICBhbmQgbWF5IGJlIHVw ZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueQog ICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJl ZmVyZW5jZQogICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBp biBwcm9ncmVzcy4iCgogICBUaGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIE1heSA3 LCAyMDE3LgoKCgoKSGVpdHosIGV0IGFsLiAgICAgICAgICAgICAgRXhwaXJlcyBNYXkgNywgMjAx NyAgICAgICAgICAgICAgICAgIFtQYWdlIDFdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICBC R1AgTGFyZ2UgQ29tbXVuaXRpZXMgICAgICAgICAgICBOb3ZlbWJlciAyMDE2CgoKQ29weXJpZ2h0 IE5vdGljZQoKICAgQ29weXJpZ2h0IChjKSAyMDE2IElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25z IGlkZW50aWZpZWQgYXMgdGhlCiAgIGRvY3VtZW50IGF1dGhvcnMuICBBbGwgcmlnaHRzIHJlc2Vy dmVkLgoKICAgVGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQgdGhlIElFVEYg VHJ1c3QncyBMZWdhbAogICBQcm92aXNpb25zIFJlbGF0aW5nIHRvIElFVEYgRG9jdW1lbnRzCiAg IChodHRwOi8vdHJ1c3RlZS5pZXRmLm9yZy9saWNlbnNlLWluZm8pIGluIGVmZmVjdCBvbiB0aGUg ZGF0ZSBvZgogICBwdWJsaWNhdGlvbiBvZiB0aGlzIGRvY3VtZW50LiAgUGxlYXNlIHJldmlldyB0 aGVzZSBkb2N1bWVudHMKICAgY2FyZWZ1bGx5LCBhcyB0aGV5IGRlc2NyaWJlIHlvdXIgcmlnaHRz IGFuZCByZXN0cmljdGlvbnMgd2l0aCByZXNwZWN0CiAgIHRvIHRoaXMgZG9jdW1lbnQuICBDb2Rl IENvbXBvbmVudHMgZXh0cmFjdGVkIGZyb20gdGhpcyBkb2N1bWVudCBtdXN0CiAgIGluY2x1ZGUg U2ltcGxpZmllZCBCU0QgTGljZW5zZSB0ZXh0IGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuZSBv ZgogICB0aGUgVHJ1c3QgTGVnYWwgUHJvdmlzaW9ucyBhbmQgYXJlIHByb3ZpZGVkIHdpdGhvdXQg d2FycmFudHkgYXMKICAgZGVzY3JpYmVkIGluIHRoZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNlLgoK VGFibGUgb2YgQ29udGVudHMKCiAgIDEuICBJbnRyb2R1Y3Rpb24gIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgMgogICAyLiAgQkdQIExhcmdlIENvbW11 bml0aWVzIEF0dHJpYnV0ZSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDMKICAgMy4g IEFnZ3JlZ2F0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gICA0CiAgIDQuICBDYW5vbmljYWwgUmVwcmVzZW50YXRpb24gIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNAogICA1LiAgUmVzZXJ2ZWQgQkdQIExhcmdlIENvbW11 bml0eSB2YWx1ZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDQKICAgNi4gIEVycm9yIEhh bmRsaW5nICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA1 CiAgIDcuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICAgNQogICA4LiAgSW1wbGVtZW50YXRpb24gc3RhdHVzIC0gUkZDIEVESVRP UjogUkVNT1ZFIEJFRk9SRSBQVUJMSUNBVElPTiAgIDUKICAgOS4gIElBTkEgQ29uc2lkZXJhdGlv bnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA2CiAgIDEwLiBD b250cmlidXRvcnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICAgNgogICAxMS4gQWNrbm93bGVkZ21lbnRzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAgIDYKICAgMTIuIFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA3CiAgICAgMTIuMS4gIE5vcm1h dGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNwog ICAgIDEyLjIuICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAgIDcKICAgICAxMi4zLiAgVVJJcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA4CiAgIEF1dGhvcnMnIEFkZHJlc3NlcyAgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgOAoKMS4gIEludHJv ZHVjdGlvbgoKICAgQkdQIGltcGxlbWVudGF0aW9ucyB0eXBpY2FsbHkgc3VwcG9ydCBhIHJvdXRp bmcgcG9saWN5IGxhbmd1YWdlIHRvCiAgIGNvbnRyb2wgdGhlIGRpc3RyaWJ1dGlvbiBvZiByb3V0 aW5nIGluZm9ybWF0aW9uLiAgTmV0d29yayBvcGVyYXRvcnMKICAgYXR0YWNoIEJHUCBjb21tdW5p dGllcyB0byByb3V0ZXMgdG8gYXNzb2NpYXRlIHBhcnRpY3VsYXIgcHJvcGVydGllcwogICB3aXRo IHRoZXNlIHJvdXRlcy4gIFRoZXNlIHByb3BlcnRpZXMgbWF5IGluY2x1ZGUgaW5mb3JtYXRpb24g c3VjaCBhcwogICB0aGUgcm91dGUgb3JpZ2luIGxvY2F0aW9uLCBvciBzcGVjaWZpY2F0aW9uIG9m IGEgcm91dGluZyBwb2xpY3kKICAgYWN0aW9uIHRvIGJlIHRha2VuLCBvciBvbmUgdGhhdCBoYXMg YmVlbiB0YWtlbiwgYW5kIGlzIGFwcGxpZWQgdG8gYWxsCiAgIHJvdXRlcyBjb250YWluZWQgaW4g YSBCR1AgVXBkYXRlIE1lc3NhZ2Ugd2hlcmUgdGhlIENvbW11bml0aWVzCiAgIEF0dHJpYnV0ZSBp cyBpbmNsdWRlZC4gIEJlY2F1c2UgQkdQIGNvbW11bml0aWVzIGFyZSBvcHRpb25hbAogICB0cmFu c2l0aXZlIEJHUCBhdHRyaWJ1dGVzLCBCR1AgY29tbXVuaXRpZXMgbWF5IGJlIGFjdGVkIHVwb24g b3IKICAgb3RoZXJ3aXNlIHVzZWQgYnkgcm91dGluZyBwb2xpY2llcyBpbiBvdGhlciBBdXRvbm9t b3VzIFN5c3RlbXMgKEFTZXMpCiAgIG9uIHRoZSBJbnRlcm5ldC4KCgoKCkhlaXR6LCBldCBhbC4g ICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDcsIDIwMTcgICAgICAgICAgICAgICAgICBbUGFnZSAy XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgQkdQIExhcmdlIENvbW11bml0aWVzICAgICAg ICAgICAgTm92ZW1iZXIgMjAxNgoKCiAgIEJHUCBDb21tdW5pdGllcyBhdHRyaWJ1dGVzIGFyZSBm b3VyLW9jdGV0IHZhbHVlcyBbUkZDMTk5N10uICBDb21tb24KICAgdXNlIG9mIHRoaXMgYXR0cmli dXRlIHR5cGUgc3BsaXRzIHRoaXMgc2luZ2xlIDMyLWJpdCB2YWx1ZSBmaWVsZCBpbnRvCiAgIHR3 byAxNi1iaXQgdmFsdWVzLiAgVGhlIG1vc3Qgc2lnbmlmaWNhbnQgd29yZCBpcyBpbnRlcnByZXRl ZCBhcyBhbgogICBBdXRvbm9tb3VzIFN5c3RlbSBOdW1iZXIgKEFTTikgYW5kIHRoZSBsZWFzdCBz aWduaWZpY2FudCB3b3JkIGlzIGEKICAgbG9jYWxseSBkZWZpbmVkIHZhbHVlIHdob3NlIG1lYW5p bmcgaXMgYXNzaWduZWQgYnkgdGhlIG9wZXJhdG9yIG9mCiAgIHRoZSBBdXRvbm9tb3VzIFN5c3Rl bSBpbiB0aGUgbW9zdCBzaWduaWZpY2FudCB3b3JkLgoKICAgU2luY2UgdGhlIGFkb3B0aW9uIG9m IGZvdXItb2N0ZXQgQVNOcyBbUkZDNjc5M10sIHRoZSBCR1AgQ29tbXVuaXRpZXMKICAgYXR0cmli dXRlIGNhbiBubyBsb25nZXIgYWNjb21tb2RhdGUgdGhlIGFib3ZlIGVuY29kaW5nLCBhcyBhIHR3 by0KICAgb2N0ZXQgd29yZCBjYW5ub3QgZml0IGEgZm91ci1vY3RldCBBU04uICBUaGUgQkdQIEV4 dGVuZGVkIENvbW11bml0aWVzCiAgIGF0dHJpYnV0ZSBbUkZDNDM2MF0gaXMgYWxzbyB1bnN1aXRh YmxlLCBhcyB0aGUgcHJvdG9jb2wgbGltaXQgb2Ygc2l4CiAgIG9jdGV0cyBmb3IgZWFjaCBjb21t dW5pdHkgdmFsdWUgY2Fubm90IGFjY29tbW9kYXRlIGJvdGggYSBmb3VyLW9jdGV0CiAgIEdsb2Jh bCBBZG1pbmlzdHJhdG9yIHZhbHVlIGFuZCBhIGZvdXItb2N0ZXQgTG9jYWwgQWRtaW5pc3RyYXRv cgogICB2YWx1ZS4gIFRoaXMgbGltaXRhdGlvbiBwcmVjbHVkZXMgdGhlIGNvbW1vbiBvcGVyYXRp b25hbCBwcmFjdGljZSBvZgogICBlbmNvZGluZyBhIHRhcmdldCBBU04gaW4gdGhlIExvY2FsIEFk bWluaXN0cmF0b3IgZmllbGQuCgogICBUbyBhZGRyZXNzIHRoZXNlIHNob3J0Y29taW5ncywgdGhp cyBkb2N1bWVudCBkZWZpbmVzIGEgQkdQIExhcmdlCiAgIENvbW11bml0aWVzIGF0dHJpYnV0ZSBl bmNvZGVkIGFzIG9uZSBvciBtb3JlIHR3ZWx2ZS1vY3RldCB2YWx1ZXMsCiAgIGVhY2ggY29uc2lz dGluZyBvZiBhIGZvdXItb2N0ZXQgR2xvYmFsIEFkbWluaXN0cmF0b3IgZmllbGQgYW5kIHR3bwog ICBmb3VyLW9jdGV0IG9wZXJhdG9yLWRlZmluZWQgZmllbGRzLCBlYWNoIG9mIHdoaWNoIGNhbiBi ZSB1c2VkIHRvCiAgIGRlbm90ZSBwcm9wZXJ0aWVzIG9yIGFjdGlvbnMgc2lnbmlmaWNhbnQgdG8g dGhlIG9wZXJhdG9yIG9mIHRoZQogICBBdXRvbm9tb3VzIFN5c3RlbSBhc3NpZ25pbmcgdGhlIHZh bHVlcy4KCjIuICBCR1AgTGFyZ2UgQ29tbXVuaXRpZXMgQXR0cmlidXRlCgogICBUaGlzIGRvY3Vt ZW50IGNyZWF0ZXMgdGhlIEJHUCBMYXJnZSBDb21tdW5pdGllcyBhdHRyaWJ1dGUgYXMgYW4KICAg b3B0aW9uYWwgdHJhbnNpdGl2ZSBwYXRoIGF0dHJpYnV0ZSBvZiB2YXJpYWJsZSBsZW5ndGguICBB bGwgcm91dGVzCiAgIHdpdGggdGhlIEJHUCBMYXJnZSBDb21tdW5pdGllcyBhdHRyaWJ1dGUgYmVs b25nIHRvIHRoZSBjb21tdW5pdHkKICAgc3BlY2lmaWVkIGluIHRoZSBhdHRyaWJ1dGUuCgogICBU aGUgYXR0cmlidXRlIGNvbnNpc3RzIG9mIG9uZSBvciBtb3JlIHR3ZWx2ZS1vY3RldCB2YWx1ZXMu ICBFYWNoCiAgIHR3ZWx2ZS1vY3RldCBCR1AgTGFyZ2UgQ29tbXVuaXRpZXMgdmFsdWUgcmVwcmVz ZW50cyB0aHJlZSBmb3VyLW9jdGV0CiAgIHZhbHVlcywgYXMgZm9sbG93czoKCiAgICAwICAgICAg ICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAgICAgICAgICAzCiAg ICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3 IDggOSAwIDEKICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSsKICAgfCAgICAgICAgICAgICAgICAgICAgICBHbG9iYWwgQWRt aW5pc3RyYXRvciAgICAgICAgICAgICAgICAgICAgIHwKICAgKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgfCAgICAgICAg ICAgICAgICAgICAgICAgTG9jYWwgRGF0YSBQYXJ0IDEgICAgICAgICAgICAgICAgICAgICAgIHwK ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSsKICAgfCAgICAgICAgICAgICAgICAgICAgICAgTG9jYWwgRGF0YSBQYXJ0IDIg ICAgICAgICAgICAgICAgICAgICAgIHwKICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKCiAgIEdsb2JhbCBBZG1pbmlzdHJh dG9yOiAgQSBmb3VyLW9jdGV0IG5hbWVzcGFjZSBpZGVudGlmaWVyLgoKICAgTG9jYWwgRGF0YSBQ YXJ0IDE6ICBBIGZvdXItb2N0ZXQgb3BlcmF0b3ItZGVmaW5lZCB2YWx1ZS4KCgoKCkhlaXR6LCBl dCBhbC4gICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDcsIDIwMTcgICAgICAgICAgICAgICAgICBb UGFnZSAzXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgQkdQIExhcmdlIENvbW11bml0aWVz ICAgICAgICAgICAgTm92ZW1iZXIgMjAxNgoKCiAgIExvY2FsIERhdGEgUGFydCAyOiAgQSBmb3Vy LW9jdGV0IG9wZXJhdG9yLWRlZmluZWQgdmFsdWUuCgogICBUaGUgR2xvYmFsIEFkbWluaXN0cmF0 b3IgZmllbGQgaXMgaW50ZW5kZWQgdG8gYWxsb3cgZGlmZmVyZW50CiAgIEF1dG9ub21vdXMgU3lz dGVtcyB0byBkZWZpbmUgQkdQIExhcmdlIENvbW11bml0aWVzIHdpdGhvdXQgY29sbGlzaW9uLgog ICBUaGlzIGZpZWxkIE1VU1QgYmUgZWl0aGVyIG9uZSBvZiB0aGUgcmVzZXJ2ZWQgdmFsdWVzIGFz IGRlZmluZWQKICAgYmVsb3csIG9yIGFuIEF1dG9ub21vdXMgU3lzdGVtIE51bWJlciAoQVNOKS4g IElmIGl0IGlzIGEgcmVzZXJ2ZWQKICAgdmFsdWUsIHRoZW4gdGhlIExvY2FsIERhdGEgUGFydHMg YXJlIGFzIGRlZmluZWQgYnkgdGhlIHJlc2VydmVkCiAgIHZhbHVlLiAgSWYgaXQgaXMgYW4gQVNO IHRoZW4gdGhlIExvY2FsIERhdGEgUGFydHMgYXJlIHRvIGJlCiAgIGludGVycHJldGVkIGFzIGRl ZmluZWQgYnkgdGhlIG93bmVyIG9mIHRoZSBBU04uICBXaGVuIHVzZWQgaW4gc21hbGwKICAgY2xv c2VkIGVudmlyb25tZW50cywgdGhlIHZhbHVlcyBNQVkgYmUgYW55IHZhbHVlcy4gIFRodXMsCiAg IGltcGxlbWVudGF0aW9ucyBNVVNUIGFsbG93IHRoZSBvcGVyYXRvciB0byBzcGVjaWZ5IGFueSB2 YWx1ZSBmb3IgYW55CiAgIG9mIHRoZSBmaWVsZHMuCgogICBUaGVyZSBpcyBubyBzaWduaWZpY2Fu Y2UgdG8gdGhlIG9yZGVyIGluIHdoaWNoIEJHUCBMYXJnZSBDb21tdW5pdGllcwogICBhcmUgZW5j b2RlZCBpbiB0aGUgQkdQIHBhdGggYXR0cmlidXRlIHBheWxvYWQuICBBIEJHUCBzcGVha2VyIGNh bgogICB0cmFuc21pdCB0aGVtIGluIGFueSBvcmRlci4KCiAgIER1cGxpY2F0ZSBCR1AgTGFyZ2Ug Q29tbXVuaXRpZXMgU0hPVUxEIE5PVCBiZSB0cmFuc21pdHRlZC4gIEEKICAgcmVjZWl2aW5nIHNw ZWFrZXIgU0hPVUxEIHNpbGVudGx5IHJlbW92ZSBkdXBsaWNhdGUgQkdQIExhcmdlCiAgIENvbW11 bml0aWVzIGZyb20gYSBCR1AgVVBEQVRFIG1lc3NhZ2UuCgozLiAgQWdncmVnYXRpb24KCiAgIElm IGEgcmFuZ2Ugb2Ygcm91dGVzIGlzIGFnZ3JlZ2F0ZWQsIHRoZW4gdGhlIHJlc3VsdGluZyBhZ2dy ZWdhdGUKICAgc2hvdWxkIGhhdmUgYSBCR1AgTGFyZ2UgQ29tbXVuaXRpZXMgYXR0cmlidXRlIHdo aWNoIGNvbnRhaW5zIGFsbCBvZgogICB0aGUgQkdQIExhcmdlIENvbW11bml0aWVzIGF0dHJpYnV0 ZXMgZnJvbSBhbGwgb2YgdGhlIGFnZ3JlZ2F0ZWQKICAgcm91dGVzLgoKNC4gIENhbm9uaWNhbCBS ZXByZXNlbnRhdGlvbgoKICAgVGhlIGNhbm9uaWNhbCByZXByZXNlbnRhdGlvbiBvZiBCR1AgTGFy Z2UgQ29tbXVuaXRpZXMgaXMgdGhyZWUKICAgc2VwYXJhdGUgdW5zaWduZWQgaW50ZWdlcnMgaW4g ZGVjaW1hbCBub3RhdGlvbiBpbiB0aGUgZm9sbG93aW5nCiAgIG9yZGVyOiBHbG9iYWwgQWRtaW5p c3RyYXRvciwgTG9jYWwgRGF0YSAxLCBMb2NhbCBEYXRhIDIuICBOdW1iZXJzCiAgIE1VU1QgTk9U IGNvbnRhaW4gbGVhZGluZyB6ZXJvczsgYSB6ZXJvIHZhbHVlIE1VU1QgYmUgcmVwcmVzZW50ZWQg d2l0aAogICBhIHNpbmdsZSB6ZXJvLiAgRWFjaCBudW1iZXIgaXMgc2VwYXJhdGVkIGZyb20gdGhl IG5leHQgYnkgYSBzaW5nbGUKICAgY29sb24uICBGb3IgZXhhbXBsZTogNjQ0OTY6NDI5NDk2NzI5 NToyLCA2NDQ5NjowOjAuCgogICBCR1AgTGFyZ2UgQ29tbXVuaXRpZXMgTVVTVCBiZSByZXByZXNl bnRlZCBpbiB0aGUgY2Fub25pY2FsCiAgIHJlcHJlc2VudGF0aW9uLiAgQSByb3V0aW5nIHBvbGlj eSBsYW5ndWFnZSBNQVkgdXNlIHNlcGFyYXRvcnMgb3RoZXIKICAgdGhhbiBjb2xvbnMuICBBIHJv dXRpbmcgcG9saWN5IGxhbmd1YWdlIE1BWSB1c2UgcHJlZml4ZXMgYW5kCiAgIHBvc3RmaXhlcyBi ZWZvcmUgYW5kIGFmdGVyIGEgTGFyZ2UgQ29tbXVuaXR5LgoKNS4gIFJlc2VydmVkIEJHUCBMYXJn ZSBDb21tdW5pdHkgdmFsdWVzCgogICBUaGUgZm9sbG93aW5nIEdsb2JhbCBBZG1pbmlzdHJhdG9y IHZhbHVlcyBhcmUgcmVzZXJ2ZWQ6IDAgKHRoZSBmaXJzdAogICBBU04pIFtSRkM3NjA3XSwgNjU1 MzUgKFVJTlQxNl9NQVgpIGFuZCA0Mjk0OTY3Mjk1ICh0aGUgbGFzdCBBU04pCiAgIFtSRkM3MzAw XS4gIE9wZXJhdG9ycyBTSE9VTEQgTk9UIHVzZSB0aGVzZSBHbG9iYWwgQWRtaW5pc3RyYXRvcgog ICB2YWx1ZXMuCgoKCkhlaXR6LCBldCBhbC4gICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDcsIDIw MTcgICAgICAgICAgICAgICAgICBbUGFnZSA0XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAg QkdQIExhcmdlIENvbW11bml0aWVzICAgICAgICAgICAgTm92ZW1iZXIgMjAxNgoKCiAgIEFsdGhv dWdoIHRoaXMgZG9jdW1lbnQgZG9lcyBub3QgZGVmaW5lIGFueSBTcGVjaWFsLVVzZSBCR1AgTGFy Z2UKICAgQ29tbXVuaXRpZXMsIHRoZSBHbG9iYWwgQWRtaW5pc3RyYXRvciB2YWx1ZXMgc3BlY2lm aWVkIGFib3ZlIGNvdWxkIGJlCiAgIHVzZWQgaWYgdGhlcmUgaXMgYSBmdXR1cmUgbmVlZCBmb3Ig dGhlbS4KCjYuICBFcnJvciBIYW5kbGluZwoKICAgVGhlIGVycm9yIGhhbmRsaW5nIG9mIEJHUCBM YXJnZSBDb21tdW5pdGllcyBpcyBhcyBmb2xsb3dzOgoKICAgbyAgQSBCR1AgTGFyZ2UgQ29tbXVu aXRpZXMgYXR0cmlidXRlIFNIQUxMIGJlIGNvbnNpZGVyZWQgbWFsZm9ybWVkIGlmCiAgICAgIHRo ZSBsZW5ndGggb2YgdGhlIEJHUCBMYXJnZSBDb21tdW5pdGllcyB2YWx1ZSwgZXhwcmVzc2VkIGlu CiAgICAgIG9jdGV0cywgaXMgbm90IGEgbm9uLXplcm8gbXVsdGlwbGUgb2YgMTIuCgogICBvICBB IEJHUCBVUERBVEUgbWVzc2FnZSB3aXRoIGEgbWFsZm9ybWVkIEJHUCBMYXJnZSBDb21tdW5pdGll cwogICAgICBhdHRyaWJ1dGUgU0hBTEwgYmUgaGFuZGxlZCB1c2luZyB0aGUgYXBwcm9hY2ggb2Yg InRyZWF0LWFzLQogICAgICB3aXRoZHJhdyIgYXMgZGVzY3JpYmVkIGluIHNlY3Rpb24gMiBbUkZD NzYwNl0uCgogICBUaGUgQkdQIExhcmdlIENvbW11bml0aWVzIEdsb2JhbCBBZG1pbmlzdHJhdG9y IGZpZWxkIG1heSBjb250YWluIGFueQogICB2YWx1ZSwgYW5kIGEgQkdQIExhcmdlIENvbW11bml0 aWVzIGF0dHJpYnV0ZSBNVVNUIE5PVCBiZSBjb25zaWRlcmVkCiAgIG1hbGZvcm1lZCBpZiB0aGUg R2xvYmFsIEFkbWluaXN0cmF0b3IgZmllbGQgY29udGFpbnMgYW4gdW5hbGxvY2F0ZWQsCiAgIHVu YXNzaWduZWQgb3IgcmVzZXJ2ZWQgQVNOIG9yIGlzIHNldCB0byBvbmUgb2YgdGhlIHJlc2VydmVk IEJHUCBMYXJnZQogICBDb21tdW5pdHkgdmFsdWVzIGRlZmluZWQgaW4gU2VjdGlvbiA1LgoKNy4g IFNlY3VyaXR5IENvbnNpZGVyYXRpb25zCgogICBUaGlzIGV4dGVuc2lvbiB0byBCR1AgaGFzIHNp bWlsYXIgc2VjdXJpdHkgaW1wbGljYXRpb25zIGFzIEJHUAogICBDb21tdW5pdGllcyBbUkZDMTk5 N10uCgogICBUaGlzIGRvY3VtZW50IGRvZXMgbm90IGNoYW5nZSBhbnkgdW5kZXJseWluZyBzZWN1 cml0eSBpc3N1ZXMKICAgYXNzb2NpYXRlZCB3aXRoIGFueSBvdGhlciBCR1AgQ29tbXVuaXRpZXMg bWVjaGFuaXNtLiAgU3BlY2lmaWNhbGx5LAogICBhbiBBUyByZWx5aW5nIG9uIHRoZSBCR1AgTGFy Z2UgQ29tbXVuaXRpZXMgYXR0cmlidXRlIGNhcnJpZWQgaW4gQkdQCiAgIG11c3QgaGF2ZSB0cnVz dCBpbiBldmVyeSBvdGhlciBBUyBpbiB0aGUgcGF0aCwgYXMgYW55IGludGVybWVkaWF0ZQogICBB dXRvbm9tb3VzIFN5c3RlbSBpbiB0aGUgcGF0aCBtYXkgaGF2ZSBhZGRlZCwgZGVsZXRlZCwgb3Ig YWx0ZXJlZCB0aGUKICAgQkdQIExhcmdlIENvbW11bml0aWVzIGF0dHJpYnV0ZS4gIFNwZWNpZnlp bmcgdGhlIG1lY2hhbmlzbSB0byBwcm92aWRlCiAgIHN1Y2ggdHJ1c3QgaXMgYmV5b25kIHRoZSBz Y29wZSBvZiB0aGlzIGRvY3VtZW50LgoKICAgTmV0d29yayBhZG1pbmlzdHJhdG9ycyBzaG91bGQg bm90ZSB0aGUgcmVjb21tZW5kYXRpb25zIGluIFNlY3Rpb24gMTEKICAgb2YgQkdQIE9wZXJhdGlv bnMgYW5kIFNlY3VyaXR5IFtSRkM3NDU0XS4KCjguICBJbXBsZW1lbnRhdGlvbiBzdGF0dXMgLSBS RkMgRURJVE9SOiBSRU1PVkUgQkVGT1JFIFBVQkxJQ0FUSU9OCgogICBUaGlzIHNlY3Rpb24gcmVj b3JkcyB0aGUgc3RhdHVzIG9mIGtub3duIGltcGxlbWVudGF0aW9ucyBvZiB0aGUKICAgcHJvdG9j b2wgZGVmaW5lZCBieSB0aGlzIHNwZWNpZmljYXRpb24gYXQgdGhlIHRpbWUgb2YgcG9zdGluZyBv ZiB0aGlzCiAgIEludGVybmV0LURyYWZ0LCBhbmQgaXMgYmFzZWQgb24gYSBwcm9wb3NhbCBkZXNj cmliZWQgaW4gW1JGQzc5NDJdLgogICBUaGUgZGVzY3JpcHRpb24gb2YgaW1wbGVtZW50YXRpb25z IGluIHRoaXMgc2VjdGlvbiBpcyBpbnRlbmRlZCB0bwogICBhc3Npc3QgdGhlIElFVEYgaW4gaXRz IGRlY2lzaW9uIHByb2Nlc3NlcyBpbiBwcm9ncmVzc2luZyBkcmFmdHMgdG8KICAgUkZDcy4gIFBs ZWFzZSBub3RlIHRoYXQgdGhlIGxpc3Rpbmcgb2YgYW55IGluZGl2aWR1YWwgaW1wbGVtZW50YXRp b24KICAgaGVyZSBkb2VzIG5vdCBpbXBseSBlbmRvcnNlbWVudCBieSB0aGUgSUVURi4gIEZ1cnRo ZXJtb3JlLCBubyBlZmZvcnQKICAgaGFzIGJlZW4gc3BlbnQgdG8gdmVyaWZ5IHRoZSBpbmZvcm1h dGlvbiBwcmVzZW50ZWQgaGVyZSB0aGF0IHdhcwoKCgpIZWl0eiwgZXQgYWwuICAgICAgICAgICAg ICBFeHBpcmVzIE1heSA3LCAyMDE3ICAgICAgICAgICAgICAgICAgW1BhZ2UgNV0KDApJbnRlcm5l dC1EcmFmdCAgICAgICAgICAgIEJHUCBMYXJnZSBDb21tdW5pdGllcyAgICAgICAgICAgIE5vdmVt YmVyIDIwMTYKCgogICBzdXBwbGllZCBieSBJRVRGIGNvbnRyaWJ1dG9ycy4gIFRoaXMgaXMgbm90 IGludGVuZGVkIGFzLCBhbmQgbXVzdCBub3QKICAgYmUgY29uc3RydWVkIHRvIGJlLCBhIGNhdGFs b2cgb2YgYXZhaWxhYmxlIGltcGxlbWVudGF0aW9ucyBvciB0aGVpcgogICBmZWF0dXJlcy4gIFJl YWRlcnMgYXJlIGFkdmlzZWQgdG8gbm90ZSB0aGF0IG90aGVyIGltcGxlbWVudGF0aW9ucyBtYXkK ICAgZXhpc3QuCgogICBBcyBvZiB0b2RheSB0aGVzZSB2ZW5kb3JzIGhhdmUgcHJvZHVjZWQgYW4g aW1wbGVtZW50YXRpb24gb2YgQkdQCiAgIExhcmdlIENvbW11bml0aWVzOgoKICAgbyAgQ2lzY28g SU9TIFhSCgogICBvICBFeGFCR1AKCiAgIG8gIEdvQkdQCgogICBvICBCSVJECgogICBvICBPcGVu QkdQRAoKICAgbyAgcG1hY2N0CgogICBvICBRdWFnZ2EKCiAgIFRoZSBsYXRlc3QgaW1wbGVtZW50 YXRpb24gbmV3cyBpcyB0cmFja2VkIGF0CiAgIGh0dHA6Ly9sYXJnZWJncGNvbW11bml0aWVzLm5l dC8gWzFdLgoKOS4gIElBTkEgQ29uc2lkZXJhdGlvbnMKCiAgIElBTkEgaGFzIG1hZGUgYW4gRWFy bHkgQWxsb2NhdGlvbiBvZiB0aGUgdmFsdWUgMzIgKExBUkdFX0NPTU1VTklUWSkKICAgaW4gdGhl ICJCR1AgUGF0aCBBdHRyaWJ1dGVzIiByZWdpc3RyeSB1bmRlciB0aGUgIkJvcmRlciBHYXRld2F5 CiAgIFByb3RvY29sIChCR1ApIFBhcmFtZXRlcnMiIGdyb3VwIGFuZCBpcyBub3cgYXNrZWQgdG8g bWFrZSB0aGF0CiAgIFBlcm1hbmVudC4KCjEwLiAgQ29udHJpYnV0b3JzCgogICBUaGUgZm9sbG93 aW5nIHBlb3BsZSBjb250cmlidXRlZCBzaWduaWZpY2FudGx5IHRvIHRoZSBjb250ZW50IG9mIHRo ZQogICBkb2N1bWVudDoKCiAgIEpvaG4gSGVhc2xleQogICBOVFQgQ29tbXVuaWNhdGlvbnMKCiAg IEVtYWlsOiBoZWFzQHNocnViYmVyeS5uZXQKCjExLiAgQWNrbm93bGVkZ21lbnRzCgogICBUaGUg YXV0aG9ycyB3b3VsZCBsaWtlIHRvIHRoYW5rIFJ1ZWRpZ2VyIFZvbGssIFJ1c3MgV2hpdGUsIEFj ZWUKICAgTGluZGVtLCBTaHlhbSBTZXRodXJhbSwgSmFyZWQgTWF1Y2gsIEpvZWwgTS4gIEhhbHBl cm4sIEplZmZyZXkgSGFhcywKICAgR3VudGVyIHZhbiBkZSBWZWxkZSwgTWFyY28gTWFyemV0dGks IEVkdWFyZG8gQXNjZW5jbyBSZWlzLCBNYXJrCiAgIFNjaG91dGVuLCBQYXVsIEhvb2dzdGVkZXIs IE1hcnRpam4gU2NobWlkdCwgR3JlZyBIYW5raW5zLCBCZXJ0cmFuZAoKCgpIZWl0eiwgZXQgYWwu ICAgICAgICAgICAgICBFeHBpcmVzIE1heSA3LCAyMDE3ICAgICAgICAgICAgICAgICAgW1BhZ2Ug Nl0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgIEJHUCBMYXJnZSBDb21tdW5pdGllcyAgICAg ICAgICAgIE5vdmVtYmVyIDIwMTYKCgogICBEdXZpdmllciwgQmFycnkgTydEb25vdmFuLCBHcnpl Z29yeiBKYW5vc3prYSwgTGluZGEgRHVuYmFyLCBNYXJjbwogICBEYXZpZHMsIEdhdXJhYiBSYWog VXBhZGhheWEsIEplZmYgVGFudHN1cmEsIFRldW4gVmluaywgQWRhbQogICBEYXZlbnBvcnQsIFRo ZW9kb3JlIEJhc2NoYWssIFBpZXIgQ2FybG8gQ2hpb2RpLCBOYWJlZWwgQ29ja2VyLCBJYW4KICAg RGlja2luc29uLCBKYW4gQmFnZ2VuLCBEdW5jYW4gTG9ja3dvb2QsIERhdmlkIEZhcm1lciwgUmFu ZHkgQnVzaCwgV2ltCiAgIEhlbmRlcmlja3gsIFN0ZWZhbiBQbHVnLCBLYXkgUmVjaHRoaWVuLCBS b2IgU2hha2lyLCBXYXJyZW4gS3VtYXJpLAogICBHZXJ0IERvZXJpbmcsIFRob21hcyBLaW5nLCBN aWthZWwgQWJyYWhhbXNzb24sIFdlc2xleSBTdGVlaG91d2VyLAogICBTYW5kZXIgU3RlZmZhbm4s IEJyYWQgRHJlaXNiYWNoLCBNYXJ0aW4gTWlsbG5lcnQsIENocmlzdG9waGVyIE1vcnJvdywKICAg SmF5IEJvcmtlbmhhZ2VuLCBBcm5vbGQgTmlwcGVyLCBKb2UgUHJvdm8sIE5pZWxzIEJha2tlciwg QmlsbCBGZW5uZXIsCiAgIFRvbSBEYWx5LCBCZW4gTWFkZGlzb24sIEFsZXhhbmRlciBBemltb3Ys IEJyaWFuIERpY2tzb24sIFBldGVyIHZhbgogICBEaWprLCBKdWxpYW4gU2VpZmVydCwgVG9tIFBl dGNoLCBUb20gU2Nob2xsLCBBcmplbiBab25uZXZlbGQsIFJlbWNvCiAgIHZhbiBNb29rLCBBZGFt IENoYXBwZWxsLCBKdXNzaSBQZWx0b2xhLCBLcmlzdGlhbiBMYXJzc29uLCBNYXJrdXMKICAgSGF1 c2NoaWxkLCBSaWNoYXJkIFN0ZWVuYmVyZ2VuLCBEYXZpZCBGcmVlZG1hbiwgUmljaGFyZCBIYXJ0 bWFubiBmb3IKICAgdGhlaXIgc3VwcG9ydCwgaW5zaWdodGZ1bCByZXZpZXcgYW5kIGNvbW1lbnRz LgoKMTIuICBSZWZlcmVuY2VzCgoxMi4xLiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMKCiAgIFtSRkMx OTk3XSAgQ2hhbmRyYSwgUi4sIFRyYWluYSwgUC4sIGFuZCBULiBMaSwgIkJHUCBDb21tdW5pdGll cwogICAgICAgICAgICAgIEF0dHJpYnV0ZSIsIFJGQyAxOTk3LCBET0kgMTAuMTc0ODcvUkZDMTk5 NywgQXVndXN0IDE5OTYsCiAgICAgICAgICAgICAgPGh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcv aW5mby9yZmMxOTk3Pi4KCiAgIFtSRkMyMTE5XSAgQnJhZG5lciwgUy4sICJLZXkgd29yZHMgZm9y IHVzZSBpbiBSRkNzIHRvIEluZGljYXRlCiAgICAgICAgICAgICAgUmVxdWlyZW1lbnQgTGV2ZWxz IiwgQkNQIDE0LCBSRkMgMjExOSwKICAgICAgICAgICAgICBET0kgMTAuMTc0ODcvUkZDMjExOSwg TWFyY2ggMTk5NywKICAgICAgICAgICAgICA8aHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZv L3JmYzIxMTk+LgoKICAgW1JGQzY3OTNdICBWb2hyYSwgUS4gYW5kIEUuIENoZW4sICJCR1AgU3Vw cG9ydCBmb3IgRm91ci1PY3RldAogICAgICAgICAgICAgIEF1dG9ub21vdXMgU3lzdGVtIChBUykg TnVtYmVyIFNwYWNlIiwgUkZDIDY3OTMsCiAgICAgICAgICAgICAgRE9JIDEwLjE3NDg3L1JGQzY3 OTMsIERlY2VtYmVyIDIwMTIsCiAgICAgICAgICAgICAgPGh0dHA6Ly93d3cucmZjLWVkaXRvci5v cmcvaW5mby9yZmM2NzkzPi4KCiAgIFtSRkM3NjA2XSAgQ2hlbiwgRS4sIEVkLiwgU2N1ZGRlciwg Si4sIEVkLiwgTW9oYXBhdHJhLCBQLiwgYW5kIEsuCiAgICAgICAgICAgICAgUGF0ZWwsICJSZXZp c2VkIEVycm9yIEhhbmRsaW5nIGZvciBCR1AgVVBEQVRFIE1lc3NhZ2VzIiwKICAgICAgICAgICAg ICBSRkMgNzYwNiwgRE9JIDEwLjE3NDg3L1JGQzc2MDYsIEF1Z3VzdCAyMDE1LAogICAgICAgICAg ICAgIDxodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNzYwNj4uCgoxMi4yLiAgSW5m b3JtYXRpdmUgUmVmZXJlbmNlcwoKICAgW1JGQzQzNjBdICBTYW5nbGksIFMuLCBUYXBwYW4sIEQu LCBhbmQgWS4gUmVraHRlciwgIkJHUCBFeHRlbmRlZAogICAgICAgICAgICAgIENvbW11bml0aWVz IEF0dHJpYnV0ZSIsIFJGQyA0MzYwLCBET0kgMTAuMTc0ODcvUkZDNDM2MCwKICAgICAgICAgICAg ICBGZWJydWFyeSAyMDA2LCA8aHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzQzNjA+ LgoKICAgW1JGQzczMDBdICBIYWFzLCBKLiBhbmQgSi4gTWl0Y2hlbGwsICJSZXNlcnZhdGlvbiBv ZiBMYXN0IEF1dG9ub21vdXMKICAgICAgICAgICAgICBTeXN0ZW0gKEFTKSBOdW1iZXJzIiwgQkNQ IDYsIFJGQyA3MzAwLAogICAgICAgICAgICAgIERPSSAxMC4xNzQ4Ny9SRkM3MzAwLCBKdWx5IDIw MTQsCiAgICAgICAgICAgICAgPGh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmM3MzAw Pi4KCgoKCkhlaXR6LCBldCBhbC4gICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDcsIDIwMTcgICAg ICAgICAgICAgICAgICBbUGFnZSA3XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgQkdQIExh cmdlIENvbW11bml0aWVzICAgICAgICAgICAgTm92ZW1iZXIgMjAxNgoKCiAgIFtSRkM3NDU0XSAg RHVyYW5kLCBKLiwgUGVwZWxuamFrLCBJLiwgYW5kIEcuIERvZXJpbmcsICJCR1AgT3BlcmF0aW9u cwogICAgICAgICAgICAgIGFuZCBTZWN1cml0eSIsIEJDUCAxOTQsIFJGQyA3NDU0LCBET0kgMTAu MTc0ODcvUkZDNzQ1NCwKICAgICAgICAgICAgICBGZWJydWFyeSAyMDE1LCA8aHR0cDovL3d3dy5y ZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzc0NTQ+LgoKICAgW1JGQzc2MDddICBLdW1hcmksIFcuLCBC dXNoLCBSLiwgU2NoaWxsZXIsIEguLCBhbmQgSy4gUGF0ZWwsCiAgICAgICAgICAgICAgIkNvZGlm aWNhdGlvbiBvZiBBUyAwIFByb2Nlc3NpbmciLCBSRkMgNzYwNywKICAgICAgICAgICAgICBET0kg MTAuMTc0ODcvUkZDNzYwNywgQXVndXN0IDIwMTUsCiAgICAgICAgICAgICAgPGh0dHA6Ly93d3cu cmZjLWVkaXRvci5vcmcvaW5mby9yZmM3NjA3Pi4KCiAgIFtSRkM3OTQyXSAgU2hlZmZlciwgWS4g YW5kIEEuIEZhcnJlbCwgIkltcHJvdmluZyBBd2FyZW5lc3Mgb2YgUnVubmluZwogICAgICAgICAg ICAgIENvZGU6IFRoZSBJbXBsZW1lbnRhdGlvbiBTdGF0dXMgU2VjdGlvbiIsIEJDUCAyMDUsCiAg ICAgICAgICAgICAgUkZDIDc5NDIsIERPSSAxMC4xNzQ4Ny9SRkM3OTQyLCBKdWx5IDIwMTYsCiAg ICAgICAgICAgICAgPGh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmM3OTQyPi4KCjEy LjMuICBVUklzCgogICBbMV0gaHR0cDovL2xhcmdlYmdwY29tbXVuaXRpZXMubmV0CgpBdXRob3Jz JyBBZGRyZXNzZXMKCiAgIEpha29iIEhlaXR6IChlZGl0b3IpCiAgIENpc2NvCiAgIDE3MCBXZXN0 IFRhc21hbiBEcml2ZQogICBTYW4gSm9zZSwgQ0EgIDk1MDU0CiAgIFVTQQoKICAgRW1haWw6IGpo ZWl0ekBjaXNjby5jb20KCgogICBKb2IgU25pamRlcnMgKGVkaXRvcikKICAgTlRUIENvbW11bmlj YXRpb25zCiAgIFRoZW9kb3J1cyBNYWpvZnNraXN0cmFhdCAxMDAKICAgQW1zdGVyZGFtICAxMDY1 IFNaCiAgIFRoZSBOZXRoZXJsYW5kcwoKICAgRW1haWw6IGpvYkBudHQubmV0CgoKICAgS2V5dXIg UGF0ZWwKICAgQXJyY3VzLCBJbmMKCiAgIEVtYWlsOiBrZXl1ckBhcnJjdXMuY29tCgoKCgoKCgoK CkhlaXR6LCBldCBhbC4gICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDcsIDIwMTcgICAgICAgICAg ICAgICAgICBbUGFnZSA4XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgQkdQIExhcmdlIENv bW11bml0aWVzICAgICAgICAgICAgTm92ZW1iZXIgMjAxNgoKCiAgIElnbmFzIEJhZ2RvbmFzCiAg IEVxdWluaXgKICAgTG9uZG9uCiAgIFVLCgogICBFbWFpbDogaWJhZ2RvbmEuaWV0ZkBnbWFpbC5j b20KCgogICBBZGFtIFNpbXBzb24KICAgTm9raWEKICAgNjAwIE1hcmNoIFJvYWQKICAgT3R0YXdh ICBPbnRhcmlvIEsySyAyRTYKICAgQ2FuYWRhCgogICBFbWFpbDogYWRhbS4xLnNpbXBzb25Abm9r aWEuY29tCgoKICAgTmljayBIaWxsaWFyZAogICBJTkVYCiAgIDQwMjcgS2luZ3N3b29kIFJvYWQK ICAgRHVibGluICAyNAogICBJRQoKICAgRW1haWw6IG5pY2tAaW5leC5pZQoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgpIZWl0eiwgZXQgYWwuICAgICAgICAgICAgICBFeHBpcmVzIE1heSA3LCAy MDE3ICAgICAgICAgICAgICAgICAgW1BhZ2UgOV0K --_004_40D942F5071046D1BF0976C827377479ciscocom_ Content-Type: text/html; name="draft-ietf-idr-large-community-07-diff-from-06.html" Content-Description: draft-ietf-idr-large-community-07-diff-from-06.html Content-Disposition: attachment; filename="draft-ietf-idr-large-community-07-diff-from-06.html"; size=63837; creation-date="Fri, 04 Nov 2016 14:20:33 GMT"; modification-date="Fri, 04 Nov 2016 14:20:33 GMT" Content-ID: <06491805E989354DB4D52CFC99A7EED4@emea.cisco.com> Content-Transfer-Encoding: base64 PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBYSFRNTCAxLjAgVHJhbnNpdGlvbmFs Ly9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL3hodG1sMS9EVEQveGh0bWwxLXRyYW5zaXRpb25h bC5kdGQiPgo8IS0tIEdlbmVyYXRlZCBieSByZmNkaWZmIDEuNDU6IHJmY2RpZmYgIC0tPgo8IS0t IDwhRE9DVFlQRSBodG1sIFBVQkxJQyAiLS8vVzNDLy9EVEQgSFRNTCA0LjAxIFRyYW5zaXRpb25h bCIgPiAtLT4KPCEtLSBTeXN0ZW06IExpbnV4IGRlY2hhdW5hYyAzLjIuMC00LWFtZDY0ICMxIFNN UCBEZWJpYW4gMy4yLjY4LTErZGViN3U2IHg4Nl82NCBHTlUvTGludXggLS0+CjwhLS0gVXNpbmcg YXdrOiAvdXNyL2Jpbi9nYXdrOiBHTlUgQXdrIDQuMS4xLCBBUEk6IDEuMSAoR05VIE1QRlIgMy4x LjMsIEdOVSBNUCA2LjAuMCkgLS0+CjwhLS0gVXNpbmcgZGlmZjogL3Vzci9iaW4vZGlmZjogZGlm ZiAoR05VIGRpZmZ1dGlscykgMy4zIC0tPgo8IS0tIFVzaW5nIHdkaWZmOiAvdXNyL2Jpbi93ZGlm Zjogd2RpZmYgKEdOVSB3ZGlmZikgMS4yLjIgLS0+CjxodG1sIHhtbG5zPSJodHRwOi8vd3d3Lncz Lm9yZy8xOTk5L3hodG1sIj48aGVhZD4gCiAgPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBl IiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPiAKICA8bWV0YSBodHRwLWVxdWl2 PSJDb250ZW50LVN0eWxlLVR5cGUiIGNvbnRlbnQ9InRleHQvY3NzIj4gCiAgPHRpdGxlPkRpZmY6 IGRyYWZ0LWlldGYtaWRyLWxhcmdlLWNvbW11bml0eS0wNi50eHQgLSBkcmFmdC1pZXRmLWlkci1s YXJnZS1jb21tdW5pdHktMDcudHh0PC90aXRsZT4gCiAgPHN0eWxlIHR5cGU9InRleHQvY3NzIj4g CiAgICBib2R5ICAgIHsgbWFyZ2luOiAwLjRleDsgbWFyZ2luLXJpZ2h0OiBhdXRvOyB9IAogICAg dHIgICAgICB7IH0gCiAgICB0ZCAgICAgIHsgd2hpdGUtc3BhY2U6IHByZTsgZm9udC1mYW1pbHk6 IG1vbm9zcGFjZTsgdmVydGljYWwtYWxpZ246IHRvcDsgZm9udC1zaXplOiAwLjg2ZW07fSAKICAg IHRoICAgICAgeyBmb250LXNpemU6IDAuODZlbTsgfSAKICAgIC5zbWFsbCAgeyBmb250LXNpemU6 IDAuNmVtOyBmb250LXN0eWxlOiBpdGFsaWM7IGZvbnQtZmFtaWx5OiBWZXJkYW5hLCBIZWx2ZXRp Y2EsIHNhbnMtc2VyaWY7IH0gCiAgICAubGVmdCAgIHsgYmFja2dyb3VuZC1jb2xvcjogI0VFRTsg fSAKICAgIC5yaWdodCAgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjRkZGOyB9IAogICAgLmRpZmYgICB7 IGJhY2tncm91bmQtY29sb3I6ICNDQ0Y7IH0gCiAgICAubGJsb2NrIHsgYmFja2dyb3VuZC1jb2xv cjogI0JGQjsgfSAKICAgIC5yYmxvY2sgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjRkY4OyB9IAogICAg Lmluc2VydCB7IGJhY2tncm91bmQtY29sb3I6ICM4RkY7IH0gCiAgICAuZGVsZXRlIHsgYmFja2dy b3VuZC1jb2xvcjogI0FDRjsgfSAKICAgIC52b2lkICAgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjRkZC OyB9IAogICAgLmNvbnQgICB7IGJhY2tncm91bmQtY29sb3I6ICNFRUU7IH0gCiAgICAubGluZWJy IHsgYmFja2dyb3VuZC1jb2xvcjogI0FBQTsgfSAKICAgIC5saW5lbm8geyBjb2xvcjogcmVkOyBi YWNrZ3JvdW5kLWNvbG9yOiAjRkZGOyBmb250LXNpemU6IDAuN2VtOyB0ZXh0LWFsaWduOiByaWdo dDsgcGFkZGluZzogMCAycHg7IH0gCiAgICAuZWxpcHNpc3sgYmFja2dyb3VuZC1jb2xvcjogI0FB QTsgfSAKICAgIC5sZWZ0IC5jb250IHsgYmFja2dyb3VuZC1jb2xvcjogI0RERDsgfSAKICAgIC5y aWdodCAuY29udCB7IGJhY2tncm91bmQtY29sb3I6ICNFRUU7IH0gCiAgICAubGJsb2NrIC5jb250 IHsgYmFja2dyb3VuZC1jb2xvcjogIzlEOTsgfSAKICAgIC5yYmxvY2sgLmNvbnQgeyBiYWNrZ3Jv dW5kLWNvbG9yOiAjREQ2OyB9IAogICAgLmluc2VydCAuY29udCB7IGJhY2tncm91bmQtY29sb3I6 ICMwREQ7IH0gCiAgICAuZGVsZXRlIC5jb250IHsgYmFja2dyb3VuZC1jb2xvcjogIzhBRDsgfSAK ICAgIC5zdGF0cywgLnN0YXRzIHRkLCAuc3RhdHMgdGggeyBiYWNrZ3JvdW5kLWNvbG9yOiAjRUVF OyBwYWRkaW5nOiAycHggMDsgfSAKICAgIHNwYW4uaGlkZSB7IGRpc3BsYXk6IG5vbmU7IGNvbG9y OiAjYWFhO30gICAgYTpob3ZlciBzcGFuIHsgZGlzcGxheTogaW5saW5lOyB9ICAgIHRyLmNoYW5n ZSB7IGJhY2tncm91bmQtY29sb3I6IGdyYXk7IH0gCiAgICB0ci5jaGFuZ2UgYSB7IHRleHQtZGVj b3JhdGlvbjogbm9uZTsgY29sb3I6IGJsYWNrIH0gCiAgPC9zdHlsZT4gCiAgICAgPHNjcmlwdD4K dmFyIGNodW5rX2luZGV4ID0gMDsKdmFyIG9sZF9jaHVuayA9IG51bGw7CgpmdW5jdGlvbiBmb3Jt YXRfY2h1bmsoaW5kZXgpIHsKICAgIHZhciBwcmVmaXggPSAiZGlmZiI7CiAgICB2YXIgc3RyID0g aW5kZXgudG9TdHJpbmcoKTsKICAgIGZvciAoeD0wOyB4PCg0LXN0ci5sZW5ndGgpOyArK3gpIHsK ICAgICAgICBwcmVmaXgrPScwJzsKICAgIH0KICAgIHJldHVybiBwcmVmaXggKyBzdHI7Cn0KCmZ1 bmN0aW9uIGZpbmRfY2h1bmsobil7CiAgICByZXR1cm4gZG9jdW1lbnQucXVlcnlTZWxlY3Rvcign dHJbaWQkPSInICsgbiArICciXScpOwp9CgpmdW5jdGlvbiBjaGFuZ2VfY2h1bmsob2Zmc2V0KSB7 CiAgICB2YXIgaW5kZXggPSBjaHVua19pbmRleCArIG9mZnNldDsKICAgIHZhciBuZXdfc3RyOwog ICAgdmFyIG5ld19jaHVuazsKCiAgICBuZXdfc3RyID0gZm9ybWF0X2NodW5rKGluZGV4KTsKICAg IG5ld19jaHVuayA9IGZpbmRfY2h1bmsobmV3X3N0cik7CiAgICBpZiAoIW5ld19jaHVuaykgewog ICAgICAgIHJldHVybjsKICAgIH0KICAgIGlmIChvbGRfY2h1bmspIHsKICAgICAgICBvbGRfY2h1 bmsuc3R5bGUub3V0bGluZSA9ICIiOwogICAgfQogICAgb2xkX2NodW5rID0gbmV3X2NodW5rOwog ICAgb2xkX2NodW5rLnN0eWxlLm91dGxpbmUgPSAiMXB4IHNvbGlkIHJlZCI7CiAgICB3aW5kb3cu bG9jYXRpb24uaGFzaCA9ICIjIiArIG5ld19zdHI7CiAgICB3aW5kb3cuc2Nyb2xsQnkoMCwtMTAw KTsKICAgIGNodW5rX2luZGV4ID0gaW5kZXg7Cn0KCmRvY3VtZW50Lm9ua2V5ZG93biA9IGZ1bmN0 aW9uKGUpIHsKICAgIHN3aXRjaCAoZS5rZXlDb2RlKSB7CiAgICBjYXNlIDc4OgogICAgICAgIGNo YW5nZV9jaHVuaygxKTsKICAgICAgICBicmVhazsKICAgIGNhc2UgODA6CiAgICAgICAgY2hhbmdl X2NodW5rKC0xKTsKICAgICAgICBicmVhazsKICAgIH0KfTsKICAgPC9zY3JpcHQ+IAo8L2hlYWQ+ IAo8Ym9keT4gCiAgPHRhYmxlIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5n PSIwIj4gCiAgPHRib2R5Pjx0ciBpZD0icGFydC0xIiBiZ2NvbG9yPSJvcmFuZ2UiPjx0aD48L3Ro Pjx0aD48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1p ZXRmLWlkci1sYXJnZS1jb21tdW5pdHktMDYudHh0IiBzdHlsZT0iY29sb3I6IzAwODsgdGV4dC1k ZWNvcmF0aW9uOm5vbmU7Ij4mbHQ7PC9hPiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWlkci1sYXJnZS1jb21tdW5pdHktMDYudHh0IiBzdHlsZT0i Y29sb3I6IzAwOCI+ZHJhZnQtaWV0Zi1pZHItbGFyZ2UtY29tbXVuaXR5LTA2LnR4dDwvYT4mbmJz cDs8L3RoPjx0aD4gPC90aD48dGg+Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtaWRyLWxhcmdlLWNvbW11bml0eS0wNy50eHQiIHN0eWxlPSJjb2xv cjojMDA4Ij5kcmFmdC1pZXRmLWlkci1sYXJnZS1jb21tdW5pdHktMDcudHh0PC9hPiZuYnNwOzxh IGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlmZj91cmwxPWRyYWZ0LWlldGYtaWRy LWxhcmdlLWNvbW11bml0eS0wNy50eHQiIHN0eWxlPSJjb2xvcjojMDA4OyB0ZXh0LWRlY29yYXRp b246bm9uZTsiPiZndDs8L2E+PC90aD48dGg+PC90aD48L3RyPiAKICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij5JRFIgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEouIEhlaXR6LCBFZC48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij5JRFIgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEouIEhlaXR6LCBFZC48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBDaXNjbzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBDaXNjbzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+SW50ZW5k ZWQgc3RhdHVzOiBTdGFuZGFyZHMgVHJhY2sgICAgICAgICAgICAgICAgICAgICAgICBKLiBTbmlq ZGVycywgRWQuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+SW50ZW5kZWQgc3RhdHVz OiBTdGFuZGFyZHMgVHJhY2sgICAgICAgICAgICAgICAgICAgICAgICBKLiBTbmlqZGVycywgRWQu PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDAx Ij48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsYmxvY2siPkV4cGlyZXM6IE1heSA8c3BhbiBjbGFzcz0iZGVsZXRlIj4zPC9zcGFuPiwg MjAxNyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBOVFQ8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+RXhwaXJlczogTWF5IDxzcGFuIGNsYXNz PSJpbnNlcnQiPjc8L3NwYW4+LCAyMDE3ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIE5UVDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEsu IFBhdGVsPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEsuIFBhdGVsPC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBcnJjdXM8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBBcnJjdXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBJLiBCYWdkb25hczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJ LiBCYWdkb25hczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBFcXVpbml4PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBFcXVpbml4PC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIEEuIFNpbXBzb248L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIEEuIFNpbXBzb248L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBOb2tpYTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBOb2tp YTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE4uIEhpbGxpYXJkPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIE4uIEhpbGxpYXJkPC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIElORVg8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIElORVg8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 ciBpZD0iZGlmZjAwMDIiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA8c3BhbiBjbGFzcz0iZGVsZXRlIj5PY3RvYmVyIDMw PC9zcGFuPiwgMjAxNjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxzcGFuIGNsYXNz PSJpbnNlcnQiPk5vdmVtYmVyIDM8L3NwYW4+LCAyMDE2PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMDMiPjx0ZD48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAg ICAgICAgICAgICAgICAgICAgIDxzcGFuIGNsYXNzPSJkZWxldGUiPkxhcmdlPC9zcGFuPiBCR1Ag Q29tbXVuaXRpZXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgICAgICAg ICAgICAgICAgICAgIEJHUCA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5MYXJnZTwvc3Bhbj4gQ29tbXVu aXRpZXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgICAgICAgICAgICAgIDxz cGFuIGNsYXNzPSJkZWxldGUiPmRyYWZ0LWlldGYtaWRyLWxhcmdlLWNvbW11bml0eS0wNjwvc3Bh bj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgICAgICAgICAgICAgIDxz cGFuIGNsYXNzPSJpbnNlcnQiPmRyYWZ0LWlldGYtaWRyLWxhcmdlLWNvbW11bml0eS0wNzwvc3Bh bj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+QWJzdHJhY3Q8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij5BYnN0cmFjdDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDA0Ij48dGQ+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIFRoaXMgZG9j dW1lbnQgZGVzY3JpYmVzIHRoZSA8c3BhbiBjbGFzcz0iZGVsZXRlIj5MYXJnZSBCR1A8L3NwYW4+ IENvbW11bml0aWVzIGF0dHJpYnV0ZSwgYW48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9j ayI+ICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgdGhlIDxzcGFuIGNsYXNzPSJpbnNlcnQiPkJH UCBMYXJnZTwvc3Bhbj4gQ29tbXVuaXRpZXMgYXR0cmlidXRlLCBhbjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgZXh0ZW5zaW9uIHRvIEJHUC00LiAgVGhpcyBhdHRyaWJ1dGUgcHJvdmlk ZXMgYSBtZWNoYW5pc20gdG8gc2lnbmFsPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgZXh0ZW5zaW9uIHRvIEJHUC00LiAgVGhpcyBhdHRyaWJ1dGUgcHJvdmlkZXMgYSBtZWNoYW5p c20gdG8gc2lnbmFsPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBvcGFxdWUgaW5mb3Jt YXRpb24gd2l0aGluIHNlcGFyYXRlIG5hbWVzcGFjZXMgdG8gYWlkIGluIHJvdXRpbmc8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBvcGFxdWUgaW5mb3JtYXRpb24gd2l0aGluIHNl cGFyYXRlIG5hbWVzcGFjZXMgdG8gYWlkIGluIHJvdXRpbmc8L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIG1hbmFnZW1lbnQuICBUaGUgYXR0cmlidXRlIGlzIHN1aXRhYmxlIGZvciB1c2Ug d2l0aCBmb3VyLW9jdGV0IEFTTnMuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg bWFuYWdlbWVudC4gIFRoZSBhdHRyaWJ1dGUgaXMgc3VpdGFibGUgZm9yIHVzZSB3aXRoIGZvdXIt b2N0ZXQgQVNOcy48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+UmVxdWlyZW1lbnRz IExhbmd1YWdlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+UmVxdWlyZW1lbnRzIExh bmd1YWdlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRoZSBrZXkgd29yZHMg Ik1VU1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9UIiw8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1V U1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsPC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAi TUFZIiwgYW5kICJPUFRJT05BTCIgaW4gdGhpczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICJNQVkiLCBhbmQg Ik9QVElPTkFMIiBpbiB0aGlzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBkb2N1bWVu dCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluIFtSRkMyMTE5XS48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0 ZWQgYXMgZGVzY3JpYmVkIGluIFtSRkMyMTE5XS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9InBhcnQtMiIgY2xhc3M9ImNoYW5nZSI+PHRk PjwvdGQ+PHRoPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxhIGhyZWY9IiNw YXJ0LTIiPjxlbT4gcGFnZSAxLCBsaW5lIDQ4PHNwYW4gY2xhc3M9ImhpZGUiPiDCtjwvc3Bhbj48 L2VtPjwvYT48L3RoPjx0aD4gPC90aD48dGg+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwv c21hbGw+PGEgaHJlZj0iI3BhcnQtMiI+PGVtPiBwYWdlIDEsIGxpbmUgNDg8c3BhbiBjbGFzcz0i aGlkZSI+IMK2PC9zcGFuPjwvZW0+PC9hPjwvdGg+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgSW50ZXJuZXQtRHJhZnRz IGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmc8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcg ZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZzwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgVGFzayBGb3JjZSAoSUVURikuICBOb3RlIHRoYXQgb3RoZXIgZ3JvdXBzIG1h eSBhbHNvIGRpc3RyaWJ1dGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUYXNr IEZvcmNlIChJRVRGKS4gIE5vdGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0 ZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgd29ya2luZyBkb2N1bWVudHMgYXMgSW50 ZXJuZXQtRHJhZnRzLiAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC08L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC1EcmFm dHMuICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgRHJhZnRzIGlzIGF0IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kcmFmdHMv Y3VycmVudC8uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgRHJhZnRzIGlzIGF0 IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kcmFmdHMvY3VycmVudC8uPC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1l bnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRoczwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlk IGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRoczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRv Y3VtZW50cyBhdCBhbnk8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBhbmQgbWF5 IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0 IGFueTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgdGltZS4gIEl0IGlzIGluYXBwcm9w cmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2U8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50 ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg bWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3Mu IjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUg dGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiI8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAwNSI+PHRkPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4g ICBUaGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIE1heSA8c3BhbiBjbGFzcz0iZGVs ZXRlIj4zPC9zcGFuPiwgMjAxNy48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAg VGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBNYXkgPHNwYW4gY2xhc3M9Imluc2Vy dCI+Nzwvc3Bhbj4sIDIwMTcuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPkNvcHly aWdodCBOb3RpY2U8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij5Db3B5cmlnaHQgTm90 aWNlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIENvcHlyaWdodCAoYykgMjAx NiBJRVRGIFRydXN0IGFuZCB0aGUgcGVyc29ucyBpZGVudGlmaWVkIGFzIHRoZTwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIENvcHlyaWdodCAoYykgMjAxNiBJRVRGIFRydXN0IGFu ZCB0aGUgcGVyc29ucyBpZGVudGlmaWVkIGFzIHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgZG9jdW1lbnQgYXV0aG9ycy4gIEFsbCByaWdodHMgcmVzZXJ2ZWQuPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZG9jdW1lbnQgYXV0aG9ycy4gIEFsbCByaWdodHMgcmVz ZXJ2ZWQuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRoaXMgZG9jdW1lbnQg aXMgc3ViamVjdCB0byBCQ1AgNzggYW5kIHRoZSBJRVRGIFRydXN0J3MgTGVnYWw8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8gQkNQ IDc4IGFuZCB0aGUgSUVURiBUcnVzdCdzIExlZ2FsPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICBQcm92aXNpb25zIFJlbGF0aW5nIHRvIElFVEYgRG9jdW1lbnRzPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgUHJvdmlzaW9ucyBSZWxhdGluZyB0byBJRVRGIERvY3VtZW50 czwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgKGh0dHA6Ly90cnVzdGVlLmlldGYub3Jn L2xpY2Vuc2UtaW5mbykgaW4gZWZmZWN0IG9uIHRoZSBkYXRlIG9mPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgKGh0dHA6Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbykg aW4gZWZmZWN0IG9uIHRoZSBkYXRlIG9mPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBw dWJsaWNhdGlvbiBvZiB0aGlzIGRvY3VtZW50LiAgUGxlYXNlIHJldmlldyB0aGVzZSBkb2N1bWVu dHM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBwdWJsaWNhdGlvbiBvZiB0aGlz IGRvY3VtZW50LiAgUGxlYXNlIHJldmlldyB0aGVzZSBkb2N1bWVudHM8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIGNhcmVmdWxseSwgYXMgdGhleSBkZXNjcmliZSB5b3VyIHJpZ2h0cyBh bmQgcmVzdHJpY3Rpb25zIHdpdGggcmVzcGVjdDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgIGNhcmVmdWxseSwgYXMgdGhleSBkZXNjcmliZSB5b3VyIHJpZ2h0cyBhbmQgcmVzdHJp Y3Rpb25zIHdpdGggcmVzcGVjdDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgdG8gdGhp cyBkb2N1bWVudC4gIENvZGUgQ29tcG9uZW50cyBleHRyYWN0ZWQgZnJvbSB0aGlzIGRvY3VtZW50 IG11c3Q8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB0byB0aGlzIGRvY3VtZW50 LiAgQ29kZSBDb21wb25lbnRzIGV4dHJhY3RlZCBmcm9tIHRoaXMgZG9jdW1lbnQgbXVzdDwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgaW5jbHVkZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNl IHRleHQgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNC5lIG9mPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgaW5jbHVkZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNlIHRleHQgYXMgZGVz Y3JpYmVkIGluIFNlY3Rpb24gNC5lIG9mPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB0 aGUgVHJ1c3QgTGVnYWwgUHJvdmlzaW9ucyBhbmQgYXJlIHByb3ZpZGVkIHdpdGhvdXQgd2FycmFu dHkgYXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB0aGUgVHJ1c3QgTGVnYWwg UHJvdmlzaW9ucyBhbmQgYXJlIHByb3ZpZGVkIHdpdGhvdXQgd2FycmFudHkgYXM8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGRlc2NyaWJlZCBpbiB0aGUgU2ltcGxpZmllZCBCU0QgTGlj ZW5zZS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBkZXNjcmliZWQgaW4gdGhl IFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PlRhYmxlIG9mIENvbnRlbnRzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+VGFibGUg b2YgQ29udGVudHM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgMS4gIEludHJv ZHVjdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g ICAyPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgMS4gIEludHJvZHVjdGlvbiAg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICAyPC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDA2Ij48dGQ+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs YmxvY2siPiAgIDIuICA8c3BhbiBjbGFzcz0iZGVsZXRlIj5MYXJnZSBCR1A8L3NwYW4+IENvbW11 bml0aWVzIEF0dHJpYnV0ZSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDM8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgMi4gIDxzcGFuIGNsYXNzPSJpbnNlcnQiPkJH UCBMYXJnZTwvc3Bhbj4gQ29tbXVuaXRpZXMgQXR0cmlidXRlIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICAgMzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgMy4gIEFnZ3JlZ2F0 aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA0 PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgMy4gIEFnZ3JlZ2F0aW9uIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA0PC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICA0LiAgQ2Fub25pY2FsIFJlcHJlc2VudGF0aW9uICAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICA0LiAgQ2Fub25pY2FsIFJlcHJlc2VudGF0aW9uICAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMDciPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgNS4gIFJlc2VydmVkIDxz cGFuIGNsYXNzPSJkZWxldGUiPkxhcmdlPC9zcGFuPiBCR1AgQ29tbXVuaXR5IHZhbHVlcyAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr Ij4gICA1LiAgUmVzZXJ2ZWQgQkdQIDxzcGFuIGNsYXNzPSJpbnNlcnQiPkxhcmdlPC9zcGFuPiBD b21tdW5pdHkgdmFsdWVzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA0PC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsYmxvY2siPiAgIDYuICBFcnJvciBIYW5kbGluZyAgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+NDwv c3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgNi4gIEVycm9yIEhhbmRs aW5nICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA8c3Bh biBjbGFzcz0iaW5zZXJ0Ij41PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg Ny4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gICA1PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgNy4gIFNlY3Vy aXR5IENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g ICA1PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICA4LiAgSW1wbGVtZW50YXRpb24gc3Rh dHVzIC0gUkZDIEVESVRPUjogUkVNT1ZFIEJFRk9SRSBQVUJMSUNBVElPTiAgIDU8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICA4LiAgSW1wbGVtZW50YXRpb24gc3RhdHVzIC0gUkZD IEVESVRPUjogUkVNT1ZFIEJFRk9SRSBQVUJMSUNBVElPTiAgIDU8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIDkuICBJQU5BIENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIDkuICBJQU5BIENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICAgNjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgMTAuIENvbnRy aWJ1dG9ycyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g ICA2PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgMTAuIENvbnRyaWJ1dG9ycyAg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA2PC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAxMS4gQWNrbm93bGVkZ21lbnRzIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDY8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICAxMS4gQWNrbm93bGVkZ21lbnRzIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDY8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIDEyLiBSZWZlcmVuY2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICAgNzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIDEyLiBS ZWZlcmVuY2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICAgNzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAxMi4xLiAgTm9ybWF0aXZl IFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA3PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAxMi4xLiAgTm9ybWF0aXZlIFJlZmVyZW5j ZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA3PC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICAgIDEyLjIuICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDc8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICAgIDEyLjIuICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgIDc8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgMTIu My4gIFVSSXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICAgODwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgMTIuMy4gIFVSSXMg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgODwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgQXV0aG9ycycgQWRkcmVzc2VzICAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA4PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgQXV0aG9ycycgQWRkcmVzc2VzICAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA4PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPjEuICBJbnRyb2R1Y3Rpb248L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4xLiAgSW50cm9kdWN0aW9uPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEJH UCBpbXBsZW1lbnRhdGlvbnMgdHlwaWNhbGx5IHN1cHBvcnQgYSByb3V0aW5nIHBvbGljeSBsYW5n dWFnZSB0bzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEJHUCBpbXBsZW1lbnRh dGlvbnMgdHlwaWNhbGx5IHN1cHBvcnQgYSByb3V0aW5nIHBvbGljeSBsYW5ndWFnZSB0bzwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgY29udHJvbCB0aGUgZGlzdHJpYnV0aW9uIG9mIHJv dXRpbmcgaW5mb3JtYXRpb24uICBOZXR3b3JrIG9wZXJhdG9yczwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgIGNvbnRyb2wgdGhlIGRpc3RyaWJ1dGlvbiBvZiByb3V0aW5nIGluZm9y bWF0aW9uLiAgTmV0d29yayBvcGVyYXRvcnM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMDgiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgYXR0YWNoIEJHUCBjb21t dW5pdGllcyB0byByb3V0ZXMgdG8gPHNwYW4gY2xhc3M9ImRlbGV0ZSI+aWRlbnRpZnkgaW50cmlu c2ljPC9zcGFuPiBwcm9wZXJ0aWVzIDxzcGFuIGNsYXNzPSJkZWxldGUiPm9mPC9zcGFuPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBhdHRhY2ggQkdQIGNvbW11bml0aWVzIHRv IHJvdXRlcyB0byA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5hc3NvY2lhdGUgcGFydGljdWxhcjwvc3Bh bj4gcHJvcGVydGllczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICB0aGVzZSByb3V0 ZXMuICBUaGVzZSBwcm9wZXJ0aWVzIG1heSBpbmNsdWRlIGluZm9ybWF0aW9uIHN1Y2ggYXMgdGhl PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIDxzcGFuIGNsYXNzPSJpbnNlcnQi PndpdGg8L3NwYW4+IHRoZXNlIHJvdXRlcy4gIFRoZXNlIHByb3BlcnRpZXMgbWF5IGluY2x1ZGUg aW5mb3JtYXRpb24gc3VjaCBhczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICByb3V0 ZSBvcmlnaW4gbG9jYXRpb24sIG9yIHNwZWNpZmljYXRpb24gb2YgYSByb3V0aW5nIHBvbGljeSBh Y3Rpb24gdG88L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgdGhlIHJvdXRlIG9y aWdpbiBsb2NhdGlvbiwgb3Igc3BlY2lmaWNhdGlvbiBvZiBhIHJvdXRpbmcgcG9saWN5PC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIGJlIHRha2VuLCBvciBvbmUgdGhhdCBoYXMgYmVl biB0YWtlbiwgYW5kIDxzcGFuIGNsYXNzPSJkZWxldGUiPm1heSBhcHBseSB0byBhbiBpbmRpdmlk dWFsPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBhY3Rpb24gdG8g YmUgdGFrZW4sIG9yIG9uZSB0aGF0IGhhcyBiZWVuIHRha2VuLCBhbmQgPHNwYW4gY2xhc3M9Imlu c2VydCI+aXMgYXBwbGllZDwvc3Bhbj4gdG8gPHNwYW4gY2xhc3M9Imluc2VydCI+YWxsPC9zcGFu PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICBy b3V0ZSBvcjwvc3Bhbj4gdG8gYSA8c3BhbiBjbGFzcz0iZGVsZXRlIj5ncm91cCBvZiByb3V0ZXMu PC9zcGFuPiAgQmVjYXVzZSBCR1AgY29tbXVuaXRpZXMgYXJlIG9wdGlvbmFsPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIHJvdXRlcyBjb250 YWluZWQgaW48L3NwYW4+IGEgPHNwYW4gY2xhc3M9Imluc2VydCI+QkdQIFVwZGF0ZSBNZXNzYWdl IHdoZXJlIHRoZSBDb21tdW5pdGllczwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9j ayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQi PiAgIEF0dHJpYnV0ZSBpcyBpbmNsdWRlZC48L3NwYW4+ICBCZWNhdXNlIEJHUCBjb21tdW5pdGll cyBhcmUgb3B0aW9uYWw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHRyYW5zaXRpdmUg QkdQIGF0dHJpYnV0ZXMsIEJHUCBjb21tdW5pdGllcyBtYXkgYmUgYWN0ZWQgdXBvbiBvcjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRyYW5zaXRpdmUgQkdQIGF0dHJpYnV0ZXMs IEJHUCBjb21tdW5pdGllcyBtYXkgYmUgYWN0ZWQgdXBvbiBvcjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgb3RoZXJ3aXNlIHVzZWQgYnkgcm91dGluZyBwb2xpY2llcyBpbiBvdGhlciBB dXRvbm9tb3VzIFN5c3RlbXMgKEFTZXMpPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgb3RoZXJ3aXNlIHVzZWQgYnkgcm91dGluZyBwb2xpY2llcyBpbiBvdGhlciBBdXRvbm9tb3Vz IFN5c3RlbXMgKEFTZXMpPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBvbiB0aGUgSW50 ZXJuZXQuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgb24gdGhlIEludGVybmV0 LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRp ZmYwMDA5Ij48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsYmxvY2siPiAgIDxzcGFuIGNsYXNzPSJkZWxldGUiPltSRkMxOTk3XTwvc3Bh bj4gQkdQIENvbW11bml0aWVzIGF0dHJpYnV0ZXMgYXJlIGZvdXItb2N0ZXQgdmFsdWVzIDxzcGFu IGNsYXNzPSJkZWxldGUiPnNwbGl0PC9zcGFuPiBpbnRvPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyYmxvY2siPiAgIEJHUCBDb21tdW5pdGllcyBhdHRyaWJ1dGVzIGFyZSBmb3VyLW9jdGV0IHZh bHVlcyA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5bUkZDMTk5N10uICBDb21tb248L3NwYW4+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIHR3byA8c3BhbiBjbGFzcz0iZGVsZXRlIj50d28t b2N0ZXQgd29yZHMuPC9zcGFuPiAgVGhlIG1vc3Qgc2lnbmlmaWNhbnQgd29yZCBpcyBpbnRlcnBy ZXRlZCBhcyBhbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0i aW5zZXJ0Ij4gICB1c2Ugb2YgdGhpcyBhdHRyaWJ1dGUgdHlwZSBzcGxpdHMgdGhpcyBzaW5nbGUg MzItYml0IHZhbHVlIGZpZWxkPC9zcGFuPiBpbnRvPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICB0d28gPHNwYW4gY2xhc3M9 Imluc2VydCI+MTYtYml0IHZhbHVlcy48L3NwYW4+ICBUaGUgbW9zdCBzaWduaWZpY2FudCB3b3Jk IGlzIGludGVycHJldGVkIGFzIGFuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBBdXRv bm9tb3VzIFN5c3RlbSBOdW1iZXIgKEFTTikgYW5kIHRoZSBsZWFzdCBzaWduaWZpY2FudCB3b3Jk IGlzIGE8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBBdXRvbm9tb3VzIFN5c3Rl bSBOdW1iZXIgKEFTTikgYW5kIHRoZSBsZWFzdCBzaWduaWZpY2FudCB3b3JkIGlzIGE8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGxvY2FsbHkgZGVmaW5lZCB2YWx1ZSB3aG9zZSBtZWFu aW5nIGlzIGFzc2lnbmVkIGJ5IHRoZSBvcGVyYXRvciBvZjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgIGxvY2FsbHkgZGVmaW5lZCB2YWx1ZSB3aG9zZSBtZWFuaW5nIGlzIGFzc2ln bmVkIGJ5IHRoZSBvcGVyYXRvciBvZjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgdGhl IEF1dG9ub21vdXMgU3lzdGVtIGluIHRoZSBtb3N0IHNpZ25pZmljYW50IHdvcmQuPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgdGhlIEF1dG9ub21vdXMgU3lzdGVtIGluIHRoZSBt b3N0IHNpZ25pZmljYW50IHdvcmQuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg IFNpbmNlIHRoZSBhZG9wdGlvbiBvZiBmb3VyLW9jdGV0IEFTTnMgW1JGQzY3OTNdLCB0aGUgQkdQ IENvbW11bml0aWVzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgU2luY2UgdGhl IGFkb3B0aW9uIG9mIGZvdXItb2N0ZXQgQVNOcyBbUkZDNjc5M10sIHRoZSBCR1AgQ29tbXVuaXRp ZXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGF0dHJpYnV0ZSBjYW4gbm8gbG9uZ2Vy IGFjY29tbW9kYXRlIHRoZSBhYm92ZSBlbmNvZGluZywgYXMgYSB0d28tPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgYXR0cmlidXRlIGNhbiBubyBsb25nZXIgYWNjb21tb2RhdGUg dGhlIGFib3ZlIGVuY29kaW5nLCBhcyBhIHR3by08L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIG9jdGV0IHdvcmQgY2Fubm90IGZpdCBhIGZvdXItb2N0ZXQgQVNOLiAgVGhlIEJHUCBFeHRl bmRlZCBDb21tdW5pdGllczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG9jdGV0 IHdvcmQgY2Fubm90IGZpdCBhIGZvdXItb2N0ZXQgQVNOLiAgVGhlIEJHUCBFeHRlbmRlZCBDb21t dW5pdGllczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgYXR0cmlidXRlIFtSRkM0MzYw XSBpcyBhbHNvIHVuc3VpdGFibGUsIGFzIHRoZSBwcm90b2NvbCBsaW1pdCBvZiBzaXg8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBhdHRyaWJ1dGUgW1JGQzQzNjBdIGlzIGFsc28g dW5zdWl0YWJsZSwgYXMgdGhlIHByb3RvY29sIGxpbWl0IG9mIHNpeDwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAxMCI+PHRkPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBv Y3RldHMgY2Fubm90IGFjY29tbW9kYXRlIGJvdGggYSBmb3VyLW9jdGV0IEdsb2JhbCBBZG1pbmlz dHJhdG9yPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIG9jdGV0cyA8c3BhbiBj bGFzcz0iaW5zZXJ0Ij5mb3IgZWFjaCBjb21tdW5pdHkgdmFsdWU8L3NwYW4+IGNhbm5vdCBhY2Nv bW1vZGF0ZSBib3RoIGEgZm91ci1vY3RldDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4g ICB2YWx1ZSBhbmQgYSBmb3VyLW9jdGV0IExvY2FsIEFkbWluaXN0cmF0b3IgPHNwYW4gY2xhc3M9 ImRlbGV0ZSI+dmFsdWUsIHdoaWNoPC9zcGFuPiBwcmVjbHVkZXMgdGhlPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyYmxvY2siPiAgIEdsb2JhbCBBZG1pbmlzdHJhdG9yIHZhbHVlIGFuZCBhIGZv dXItb2N0ZXQgTG9jYWwgQWRtaW5pc3RyYXRvcjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2Nr Ij4gICBjb21tb24gb3BlcmF0aW9uYWwgcHJhY3RpY2Ugb2YgZW5jb2RpbmcgYSB0YXJnZXQgQVNO IGluIHRoZSBMb2NhbDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICA8c3BhbiBj bGFzcz0iaW5zZXJ0Ij52YWx1ZS4gIFRoaXMgbGltaXRhdGlvbjwvc3Bhbj4gcHJlY2x1ZGVzIHRo ZSBjb21tb24gb3BlcmF0aW9uYWwgcHJhY3RpY2Ugb2Y8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxi bG9jayI+ICAgQWRtaW5pc3RyYXRvciBmaWVsZC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJi bG9jayI+ICAgZW5jb2RpbmcgYSB0YXJnZXQgQVNOIGluIHRoZSBMb2NhbCBBZG1pbmlzdHJhdG9y IGZpZWxkLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIg aWQ9ImRpZmYwMDExIj48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIFRvIGFkZHJlc3MgdGhlc2Ugc2hvcnRjb21pbmdz LCB0aGlzIGRvY3VtZW50IGRlZmluZXMgYSA8c3BhbiBjbGFzcz0iZGVsZXRlIj5MYXJnZSBCR1A8 L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIFRvIGFkZHJlc3MgdGhl c2Ugc2hvcnRjb21pbmdzLCB0aGlzIGRvY3VtZW50IGRlZmluZXMgYSA8c3BhbiBjbGFzcz0iaW5z ZXJ0Ij5CR1AgTGFyZ2U8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBDb21t dW5pdGllcyBhdHRyaWJ1dGUgZW5jb2RlZCBhcyBvbmUgb3IgbW9yZSB0d2VsdmUtb2N0ZXQgdmFs dWVzLDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIENvbW11bml0aWVzIGF0dHJp YnV0ZSBlbmNvZGVkIGFzIG9uZSBvciBtb3JlIHR3ZWx2ZS1vY3RldCB2YWx1ZXMsPC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBlYWNoIGNvbnNpc3Rpbmcgb2YgYSBmb3VyLW9jdGV0IEds b2JhbCBBZG1pbmlzdHJhdG9yIGZpZWxkIGFuZCB0d288L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICBlYWNoIGNvbnNpc3Rpbmcgb2YgYSBmb3VyLW9jdGV0IEdsb2JhbCBBZG1pbmlz dHJhdG9yIGZpZWxkIGFuZCB0d288L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGZvdXIt b2N0ZXQgb3BlcmF0b3ItZGVmaW5lZCBmaWVsZHMsIGVhY2ggb2Ygd2hpY2ggY2FuIGJlIHVzZWQg dG88L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBmb3VyLW9jdGV0IG9wZXJhdG9y LWRlZmluZWQgZmllbGRzLCBlYWNoIG9mIHdoaWNoIGNhbiBiZSB1c2VkIHRvPC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICBkZW5vdGUgcHJvcGVydGllcyBvciBhY3Rpb25zIHNpZ25pZmlj YW50IHRvIHRoZSBvcGVyYXRvciBvZiB0aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICBkZW5vdGUgcHJvcGVydGllcyBvciBhY3Rpb25zIHNpZ25pZmljYW50IHRvIHRoZSBvcGVy YXRvciBvZiB0aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEF1dG9ub21vdXMgU3lz dGVtIGFzc2lnbmluZyB0aGUgdmFsdWVzLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIEF1dG9ub21vdXMgU3lzdGVtIGFzc2lnbmluZyB0aGUgdmFsdWVzLjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDEyIj48dGQ+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPjIuICA8c3BhbiBjbGFzcz0iZGVsZXRlIj5MYXJnZSBCR1A8L3NwYW4+IENvbW11bml0aWVz IEF0dHJpYnV0ZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4yLiAgPHNwYW4gY2xh c3M9Imluc2VydCI+QkdQIExhcmdlPC9zcGFuPiBDb21tdW5pdGllcyBBdHRyaWJ1dGU8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAxMyI+ PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGJsb2NrIj4gICBUaGlzIGRvY3VtZW50IGNyZWF0ZXMgdGhlIDxzcGFuIGNsYXNzPSJkZWxl dGUiPkxhcmdlIEJHUDwvc3Bhbj4gQ29tbXVuaXRpZXMgYXR0cmlidXRlIGFzIGFuPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIFRoaXMgZG9jdW1lbnQgY3JlYXRlcyB0aGUgPHNw YW4gY2xhc3M9Imluc2VydCI+QkdQIExhcmdlPC9zcGFuPiBDb21tdW5pdGllcyBhdHRyaWJ1dGUg YXMgYW48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG9wdGlvbmFsIHRyYW5zaXRpdmUg cGF0aCBhdHRyaWJ1dGUgb2YgdmFyaWFibGUgbGVuZ3RoLiAgQWxsIHJvdXRlczwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG9wdGlvbmFsIHRyYW5zaXRpdmUgcGF0aCBhdHRyaWJ1 dGUgb2YgdmFyaWFibGUgbGVuZ3RoLiAgQWxsIHJvdXRlczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAxNCI+PHRkPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICB3aXRoIHRo ZSA8c3BhbiBjbGFzcz0iZGVsZXRlIj5MYXJnZSBCR1A8L3NwYW4+IENvbW11bml0aWVzIGF0dHJp YnV0ZSBiZWxvbmcgdG8gdGhlIGNvbW11bml0eTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJs b2NrIj4gICB3aXRoIHRoZSA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5CR1AgTGFyZ2U8L3NwYW4+IENv bW11bml0aWVzIGF0dHJpYnV0ZSBiZWxvbmcgdG8gdGhlIGNvbW11bml0eTwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgc3BlY2lmaWVkIGluIHRoZSBhdHRyaWJ1dGUuPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgc3BlY2lmaWVkIGluIHRoZSBhdHRyaWJ1dGUuPC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRoZSBhdHRyaWJ1dGUgY29uc2lzdHMgb2Yg b25lIG9yIG1vcmUgdHdlbHZlLW9jdGV0IHZhbHVlcy4gIEVhY2g8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICBUaGUgYXR0cmlidXRlIGNvbnNpc3RzIG9mIG9uZSBvciBtb3JlIHR3 ZWx2ZS1vY3RldCB2YWx1ZXMuICBFYWNoPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHIgaWQ9ImRpZmYwMDE1Ij48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIHR3ZWx2ZS1vY3RldCA8c3Bh biBjbGFzcz0iZGVsZXRlIj5MYXJnZSBCR1A8L3NwYW4+IENvbW11bml0aWVzIHZhbHVlIHJlcHJl c2VudHMgdGhyZWUgZm91ci1vY3RldDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4g ICB0d2VsdmUtb2N0ZXQgPHNwYW4gY2xhc3M9Imluc2VydCI+QkdQIExhcmdlPC9zcGFuPiBDb21t dW5pdGllcyB2YWx1ZSByZXByZXNlbnRzIHRocmVlIGZvdXItb2N0ZXQ8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIHZhbHVlcywgYXMgZm9sbG93czo8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICB2YWx1ZXMsIGFzIGZvbGxvd3M6PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgICAwICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAgMiAg ICAgICAgICAgICAgICAgICAzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgIDAg ICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAg IDM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAg MSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDE8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcg OCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rPC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB8ICAgICAgICAgICAgICAgICAgICAgIEdsb2Jh bCBBZG1pbmlzdHJhdG9yICAgICAgICAgICAgICAgICAgICAgfDwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgIHwgICAgICAgICAgICAgICAgICAgICAgR2xvYmFsIEFkbWluaXN0cmF0 b3IgICAgICAgICAgICAgICAgICAgICB8PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAr LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rPC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB8ICAgICAgICAgICAgICAgICAgICAgICBMb2NhbCBE YXRhIFBhcnQgMSAgICAgICAgICAgICAgICAgICAgICAgfDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgIHwgICAgICAgICAgICAgICAgICAgICAgIExvY2FsIERhdGEgUGFydCAxICAg ICAgICAgICAgICAgICAgICAgICB8PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICArLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rPC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB8ICAgICAgICAgICAgICAgICAgICAgICBMb2NhbCBEYXRh IFBhcnQgMiAgICAgICAgICAgICAgICAgICAgICAgfDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgIHwgICAgICAgICAgICAgICAgICAgICAgIExvY2FsIERhdGEgUGFydCAyICAgICAg ICAgICAgICAgICAgICAgICB8PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICArLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst KzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rPC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMTYiPjx0ZD48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxi bG9jayI+ICAgR2xvYmFsIEFkbWluaXN0cmF0b3I6ICBBIGZvdXItb2N0ZXQgbmFtZXNwYWNlIGlk ZW50aWZpZXIuICA8c3BhbiBjbGFzcz0iZGVsZXRlIj5UaGlzPC9zcGFuPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmJsb2NrIj4gICBHbG9iYWwgQWRtaW5pc3RyYXRvcjogIEEgZm91ci1vY3Rl dCBuYW1lc3BhY2UgaWRlbnRpZmllci48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNw YW4gY2xhc3M9ImRlbGV0ZSI+ICAgICAgU0hPVUxEIGJlIGFuIEF1dG9ub21vdXMgU3lzdGVtIE51 bWJlci48L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBMb2NhbCBEYXRhIFBhcnQgMTogIEEgZm91ci1vY3Rl dCBvcGVyYXRvci1kZWZpbmVkIHZhbHVlLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIExvY2FsIERhdGEgUGFydCAxOiAgQSBmb3VyLW9jdGV0IG9wZXJhdG9yLWRlZmluZWQgdmFs dWUuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIExvY2FsIERhdGEgUGFydCAy OiAgQSBmb3VyLW9jdGV0IG9wZXJhdG9yLWRlZmluZWQgdmFsdWUuPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgTG9jYWwgRGF0YSBQYXJ0IDI6ICBBIGZvdXItb2N0ZXQgb3BlcmF0 b3ItZGVmaW5lZCB2YWx1ZS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhl IEdsb2JhbCBBZG1pbmlzdHJhdG9yIGZpZWxkIGlzIGludGVuZGVkIHRvIGFsbG93IGRpZmZlcmVu dDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRoZSBHbG9iYWwgQWRtaW5pc3Ry YXRvciBmaWVsZCBpcyBpbnRlbmRlZCB0byBhbGxvdyBkaWZmZXJlbnQ8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMTciPjx0ZD48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAg QXV0b25vbW91cyBTeXN0ZW1zIHRvIGRlZmluZSA8c3BhbiBjbGFzcz0iZGVsZXRlIj5MYXJnZTwv c3Bhbj4gQkdQIENvbW11bml0aWVzIHdpdGhvdXQgY29sbGlzaW9uLjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmJsb2NrIj4gICBBdXRvbm9tb3VzIFN5c3RlbXMgdG8gZGVmaW5lIEJHUCA8c3Bh biBjbGFzcz0iaW5zZXJ0Ij5MYXJnZTwvc3Bhbj4gQ29tbXVuaXRpZXMgd2l0aG91dCBjb2xsaXNp b24uPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIDxzcGFuIGNsYXNzPSJkZWxldGUi PkltcGxlbWVudGF0aW9uczwvc3Bhbj4gTVVTVCBhbGxvdyB0aGUgb3BlcmF0b3IgdG8gc3BlY2lm eSBhbnkgdmFsdWUgZm9yIHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICA8 c3BhbiBjbGFzcz0iaW5zZXJ0Ij5UaGlzIGZpZWxkIE1VU1QgYmUgZWl0aGVyIG9uZSBvZiB0aGUg cmVzZXJ2ZWQgdmFsdWVzIGFzIGRlZmluZWQ8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs YmxvY2siPiAgIDxzcGFuIGNsYXNzPSJkZWxldGUiPkdsb2JhbCBBZG1pbmlzdHJhdG9yIGZpZWxk Ljwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imlu c2VydCI+ICAgYmVsb3csIG9yIGFuIEF1dG9ub21vdXMgU3lzdGVtIE51bWJlciAoQVNOKS4gIElm IGl0IGlzIGEgcmVzZXJ2ZWQ8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICB2 YWx1ZSwgdGhlbiB0aGUgTG9jYWwgRGF0YSBQYXJ0cyBhcmUgYXMgZGVmaW5lZCBieSB0aGUgcmVz ZXJ2ZWQ8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICB2YWx1ZS4gIElmIGl0 IGlzIGFuIEFTTiB0aGVuIHRoZSBMb2NhbCBEYXRhIFBhcnRzIGFyZSB0byBiZTwvc3Bhbj48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv Y2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIGludGVycHJldGVkIGFzIGRlZmluZWQgYnkgdGhl IG93bmVyIG9mIHRoZSBBU04uICBXaGVuIHVzZWQgaW4gc21hbGw8L3NwYW4+PC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3Bh biBjbGFzcz0iaW5zZXJ0Ij4gICBjbG9zZWQgZW52aXJvbm1lbnRzLCB0aGUgdmFsdWVzIE1BWSBi ZSBhbnkgdmFsdWVzLiAgVGh1cyw8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2si PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4g ICBpbXBsZW1lbnRhdGlvbnM8L3NwYW4+IE1VU1QgYWxsb3cgdGhlIG9wZXJhdG9yIHRvIHNwZWNp ZnkgYW55IHZhbHVlIGZvciA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5hbnk8L3NwYW4+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48 c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBvZjwvc3Bhbj4gdGhlIDxzcGFuIGNsYXNzPSJpbnNlcnQi PmZpZWxkcy48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0ciBpZD0iZGlmZjAwMTgiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgVGhlcmUgaXMgbm8gc2lnbmlmaWNh bmNlIHRvIHRoZSBvcmRlciBpbiB3aGljaCA8c3BhbiBjbGFzcz0iZGVsZXRlIj5MYXJnZSBCR1A8 L3NwYW4+IENvbW11bml0aWVzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIFRo ZXJlIGlzIG5vIHNpZ25pZmljYW5jZSB0byB0aGUgb3JkZXIgaW4gd2hpY2ggPHNwYW4gY2xhc3M9 Imluc2VydCI+QkdQIExhcmdlPC9zcGFuPiBDb21tdW5pdGllczwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgYXJlIGVuY29kZWQgaW4gdGhlIEJHUCBwYXRoIGF0dHJpYnV0ZSBwYXlsb2Fk LiAgQSBCR1Agc3BlYWtlciBjYW48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBh cmUgZW5jb2RlZCBpbiB0aGUgQkdQIHBhdGggYXR0cmlidXRlIHBheWxvYWQuICBBIEJHUCBzcGVh a2VyIGNhbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgdHJhbnNtaXQgdGhlbSBpbiBh bnkgb3JkZXIuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgdHJhbnNtaXQgdGhl bSBpbiBhbnkgb3JkZXIuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0ciBpZD0iZGlmZjAwMTkiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgRHVwbGljYXRlIDxzcGFuIGNsYXNz PSJkZWxldGUiPkxhcmdlPC9zcGFuPiBCR1AgQ29tbXVuaXRpZXMgU0hPVUxEIE5PVCBiZSB0cmFu c21pdHRlZC4gIEE8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgRHVwbGljYXRl IEJHUCA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5MYXJnZTwvc3Bhbj4gQ29tbXVuaXRpZXMgU0hPVUxE IE5PVCBiZSB0cmFuc21pdHRlZC4gIEE8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAg cmVjZWl2aW5nIHNwZWFrZXIgU0hPVUxEIHNpbGVudGx5IHJlbW92ZSBkdXBsaWNhdGUgPHNwYW4g Y2xhc3M9ImRlbGV0ZSI+TGFyZ2U8L3NwYW4+IEJHUDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmJsb2NrIj4gICByZWNlaXZpbmcgc3BlYWtlciBTSE9VTEQgc2lsZW50bHkgcmVtb3ZlIGR1cGxp Y2F0ZSBCR1AgPHNwYW4gY2xhc3M9Imluc2VydCI+TGFyZ2U8L3NwYW4+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICBDb21tdW5pdGllcyBmcm9tIGEgQkdQIFVQREFURSBtZXNzYWdlLjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIENvbW11bml0aWVzIGZyb20gYSBCR1Ag VVBEQVRFIG1lc3NhZ2UuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjMuICBBZ2dy ZWdhdGlvbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjMuICBBZ2dyZWdhdGlvbjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBJZiBhIHJhbmdlIG9mIHJvdXRlcyBp cyBhZ2dyZWdhdGVkLCB0aGVuIHRoZSByZXN1bHRpbmcgYWdncmVnYXRlPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgSWYgYSByYW5nZSBvZiByb3V0ZXMgaXMgYWdncmVnYXRlZCwg dGhlbiB0aGUgcmVzdWx0aW5nIGFnZ3JlZ2F0ZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAyMCI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBzaG91bGQgaGF2ZSBh IDxzcGFuIGNsYXNzPSJkZWxldGUiPkxhcmdlPC9zcGFuPiBCR1AgQ29tbXVuaXRpZXMgYXR0cmli dXRlIHdoaWNoIGNvbnRhaW5zIGFsbCBvZjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr Ij4gICBzaG91bGQgaGF2ZSBhIEJHUCA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5MYXJnZTwvc3Bhbj4g Q29tbXVuaXRpZXMgYXR0cmlidXRlIHdoaWNoIGNvbnRhaW5zIGFsbCBvZjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGJsb2NrIj4gICB0aGUgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+TGFyZ2U8L3NwYW4+ IEJHUCBDb21tdW5pdGllcyBhdHRyaWJ1dGVzIGZyb20gYWxsIG9mIHRoZSBhZ2dyZWdhdGVkPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIHRoZSBCR1AgPHNwYW4gY2xhc3M9Imlu c2VydCI+TGFyZ2U8L3NwYW4+IENvbW11bml0aWVzIGF0dHJpYnV0ZXMgZnJvbSBhbGwgb2YgdGhl IGFnZ3JlZ2F0ZWQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHJvdXRlcy48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICByb3V0ZXMuPC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPjQuICBDYW5vbmljYWwgUmVwcmVzZW50YXRpb248L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij40LiAgQ2Fub25pY2FsIFJlcHJlc2VudGF0aW9uPC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMjEiPjx0ZD48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxi bG9jayI+ICAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+TGFyZ2U8L3NwYW4+IEJHUCBDb21tdW5pdGll cyA8c3BhbiBjbGFzcz0iZGVsZXRlIj5NVVNUIGJlIHJlcHJlc2VudGVkIGFzPC9zcGFuPiB0aHJl ZSBzZXBhcmF0ZSB1bnNpZ25lZDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICA8 c3BhbiBjbGFzcz0iaW5zZXJ0Ij5UaGUgY2Fub25pY2FsIHJlcHJlc2VudGF0aW9uIG9mPC9zcGFu PiBCR1AgPHNwYW4gY2xhc3M9Imluc2VydCI+TGFyZ2U8L3NwYW4+IENvbW11bml0aWVzIDxzcGFu IGNsYXNzPSJpbnNlcnQiPmlzPC9zcGFuPiB0aHJlZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJs b2NrIj4gICBpbnRlZ2VycyBpbiBkZWNpbWFsIG5vdGF0aW9uIGluIHRoZSBmb2xsb3dpbmcgb3Jk ZXI6IEdsb2JhbDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBzZXBhcmF0ZSB1 bnNpZ25lZCBpbnRlZ2VycyBpbiBkZWNpbWFsIG5vdGF0aW9uIGluIHRoZSBmb2xsb3dpbmc8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgQWRtaW5pc3RyYXRvciwgTG9jYWwgRGF0YSAx LCBMb2NhbCBEYXRhIDIuICBOdW1iZXJzIE1VU1QgTk9UIGNvbnRhaW48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJibG9jayI+ICAgb3JkZXI6IEdsb2JhbCBBZG1pbmlzdHJhdG9yLCBMb2NhbCBE YXRhIDEsIExvY2FsIERhdGEgMi4gIE51bWJlcnM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9j ayI+ICAgbGVhZGluZyB6ZXJvczsgYSB6ZXJvIHZhbHVlIE1VU1QgYmUgcmVwcmVzZW50ZWQgd2l0 aCBhIHNpbmdsZSB6ZXJvLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBNVVNU IE5PVCBjb250YWluIGxlYWRpbmcgemVyb3M7IGEgemVybyB2YWx1ZSBNVVNUIGJlIHJlcHJlc2Vu dGVkIHdpdGg8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgRm9yIGV4YW1wbGU6IDY0 NDk2OjQyOTQ5NjcyOTU6MiwgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+NjQ0OTY6MDowLCBvciAoNjQ0 OTYsIDExMSwgMjIyKS48L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAg IGEgc2luZ2xlIHplcm8uICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5FYWNoIG51bWJlciBpcyBzZXBh cmF0ZWQgZnJvbSB0aGUgbmV4dCBieSBhIHNpbmdsZTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNz PSJpbnNlcnQiPiAgIGNvbG9uLjwvc3Bhbj4gIEZvciBleGFtcGxlOiA2NDQ5Njo0Mjk0OTY3Mjk1 OjIsIDxzcGFuIGNsYXNzPSJpbnNlcnQiPjY0NDk2OjA6MC48L3NwYW4+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMjIiPjx0ZD48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9j ayI+NS4gIFJlc2VydmVkIDxzcGFuIGNsYXNzPSJkZWxldGUiPkxhcmdlPC9zcGFuPiBCR1AgQ29t bXVuaXR5IHZhbHVlczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICA8c3BhbiBj bGFzcz0iaW5zZXJ0Ij5CR1AgTGFyZ2UgQ29tbXVuaXRpZXMgTVVTVCBiZSByZXByZXNlbnRlZCBp biB0aGUgY2Fub25pY2FsPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgcmVw cmVzZW50YXRpb24uICBBIHJvdXRpbmcgcG9saWN5IGxhbmd1YWdlIE1BWSB1c2Ugc2VwYXJhdG9y cyBvdGhlcjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIHRoYW4gY29sb25z LiAgQSByb3V0aW5nIHBvbGljeSBsYW5ndWFnZSBNQVkgdXNlIHByZWZpeGVzIGFuZDwvc3Bhbj48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy YmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIHBvc3RmaXhlcyBiZWZvcmUgYW5kIGFmdGVy IGEgTGFyZ2UgQ29tbXVuaXR5Ljwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si PjUuICBSZXNlcnZlZCBCR1AgPHNwYW4gY2xhc3M9Imluc2VydCI+TGFyZ2U8L3NwYW4+IENvbW11 bml0eSB2YWx1ZXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhlIGZvbGxv d2luZyBHbG9iYWwgQWRtaW5pc3RyYXRvciB2YWx1ZXMgYXJlIHJlc2VydmVkOiAwICh0aGUgZmly c3Q8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGUgZm9sbG93aW5nIEdsb2Jh bCBBZG1pbmlzdHJhdG9yIHZhbHVlcyBhcmUgcmVzZXJ2ZWQ6IDAgKHRoZSBmaXJzdDwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgQVNOKSBbUkZDNzYwN10sIDY1NTM1IChVSU5UMTZfTUFY KSBhbmQgNDI5NDk2NzI5NSAodGhlIGxhc3QgQVNOKTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgIEFTTikgW1JGQzc2MDddLCA2NTUzNSAoVUlOVDE2X01BWCkgYW5kIDQyOTQ5Njcy OTUgKHRoZSBsYXN0IEFTTik8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFtSRkM3MzAw XS4gIE9wZXJhdG9ycyBTSE9VTEQgTk9UIHVzZSB0aGVzZSBHbG9iYWwgQWRtaW5pc3RyYXRvcjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFtSRkM3MzAwXS4gIE9wZXJhdG9ycyBT SE9VTEQgTk9UIHVzZSB0aGVzZSBHbG9iYWwgQWRtaW5pc3RyYXRvcjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgdmFsdWVzLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IHZhbHVlcy48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy IGlkPSJkaWZmMDAyMyI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBBbHRob3VnaCB0aGlzIGRvY3VtZW50IGRvZXMg bm90IGRlZmluZSBhbnkgU3BlY2lhbC1Vc2UgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+TGFyZ2UgQkdQ PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBBbHRob3VnaCB0aGlz IGRvY3VtZW50IGRvZXMgbm90IGRlZmluZSBhbnkgU3BlY2lhbC1Vc2UgPHNwYW4gY2xhc3M9Imlu c2VydCI+QkdQIExhcmdlPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgQ29t bXVuaXRpZXMsIHRoZSBHbG9iYWwgQWRtaW5pc3RyYXRvciB2YWx1ZXMgc3BlY2lmaWVkIGFib3Zl IGNvdWxkIGJlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgQ29tbXVuaXRpZXMs IHRoZSBHbG9iYWwgQWRtaW5pc3RyYXRvciB2YWx1ZXMgc3BlY2lmaWVkIGFib3ZlIGNvdWxkIGJl PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB1c2VkIGlmIHRoZXJlIGlzIGEgZnV0dXJl IG5lZWQgZm9yIHRoZW0uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgdXNlZCBp ZiB0aGVyZSBpcyBhIGZ1dHVyZSBuZWVkIGZvciB0aGVtLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij42LiAgRXJyb3IgSGFuZGxpbmc8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij42LiAgRXJyb3IgSGFuZGxpbmc8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAyNCI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBUaGUgZXJyb3IgaGFu ZGxpbmcgb2YgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+TGFyZ2UgQkdQPC9zcGFuPiBDb21tdW5pdGll cyBpcyBhcyBmb2xsb3dzOjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBUaGUg ZXJyb3IgaGFuZGxpbmcgb2YgPHNwYW4gY2xhc3M9Imluc2VydCI+QkdQIExhcmdlPC9zcGFuPiBD b21tdW5pdGllcyBpcyBhcyBmb2xsb3dzOjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDI1Ij48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIG8gIEEgPHNwYW4g Y2xhc3M9ImRlbGV0ZSI+TGFyZ2U8L3NwYW4+IEJHUCBDb21tdW5pdGllcyBhdHRyaWJ1dGUgU0hB TEwgYmUgY29uc2lkZXJlZCBtYWxmb3JtZWQgaWY8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJi bG9jayI+ICAgbyAgQSBCR1AgPHNwYW4gY2xhc3M9Imluc2VydCI+TGFyZ2U8L3NwYW4+IENvbW11 bml0aWVzIGF0dHJpYnV0ZSBTSEFMTCBiZSBjb25zaWRlcmVkIG1hbGZvcm1lZCBpZjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICA8c3BhbiBjbGFzcz0iZGVsZXRlIj5pdHM8L3Nw YW4+IGxlbmd0aCBpcyBub3QgYSBub24temVybyBtdWx0aXBsZSBvZiAxMi48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgPHNwYW4gY2xhc3M9Imluc2VydCI+dGhlPC9zcGFu PiBsZW5ndGggPHNwYW4gY2xhc3M9Imluc2VydCI+b2YgdGhlIEJHUCBMYXJnZSBDb21tdW5pdGll cyB2YWx1ZSwgZXhwcmVzc2VkIGluPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2Nr Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ ICAgICAgb2N0ZXRzLDwvc3Bhbj4gaXMgbm90IGEgbm9uLXplcm8gbXVsdGlwbGUgb2YgMTIuPC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAw MjYiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxibG9jayI+ICAgbyAgQSBCR1AgVVBEQVRFIG1lc3NhZ2Ugd2l0aCBhIG1hbGZvcm1l ZCA8c3BhbiBjbGFzcz0iZGVsZXRlIj5MYXJnZSBCR1A8L3NwYW4+IENvbW11bml0aWVzPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIG8gIEEgQkdQIFVQREFURSBtZXNzYWdlIHdp dGggYSBtYWxmb3JtZWQgPHNwYW4gY2xhc3M9Imluc2VydCI+QkdQIExhcmdlPC9zcGFuPiBDb21t dW5pdGllczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgYXR0cmlidXRlIFNIQUxM IGJlIGhhbmRsZWQgdXNpbmcgdGhlIGFwcHJvYWNoIG9mICJ0cmVhdC1hcy08L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBhdHRyaWJ1dGUgU0hBTEwgYmUgaGFuZGxlZCB1c2lu ZyB0aGUgYXBwcm9hY2ggb2YgInRyZWF0LWFzLTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgICAgd2l0aGRyYXciIGFzIGRlc2NyaWJlZCBpbiBzZWN0aW9uIDIgW1JGQzc2MDZdLjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIHdpdGhkcmF3IiBhcyBkZXNjcmliZWQg aW4gc2VjdGlvbiAyIFtSRkM3NjA2XS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAyNyI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBUaGUgPHNwYW4gY2xh c3M9ImRlbGV0ZSI+TGFyZ2U8L3NwYW4+IEJHUCBDb21tdW5pdGllcyBHbG9iYWwgQWRtaW5pc3Ry YXRvciBmaWVsZCBtYXkgY29udGFpbiBhbnk8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9j ayI+ICAgVGhlIEJHUCA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5MYXJnZTwvc3Bhbj4gQ29tbXVuaXRp ZXMgR2xvYmFsIEFkbWluaXN0cmF0b3IgZmllbGQgbWF5IGNvbnRhaW4gYW55PC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsYmxvY2siPiAgIHZhbHVlLCBhbmQgYSA8c3BhbiBjbGFzcz0iZGVsZXRlIj5M YXJnZTwvc3Bhbj4gQkdQIENvbW11bml0aWVzIGF0dHJpYnV0ZSBNVVNUIE5PVCBiZSBjb25zaWRl cmVkPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIHZhbHVlLCBhbmQgYSBCR1Ag PHNwYW4gY2xhc3M9Imluc2VydCI+TGFyZ2U8L3NwYW4+IENvbW11bml0aWVzIGF0dHJpYnV0ZSBN VVNUIE5PVCBiZSBjb25zaWRlcmVkPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBtYWxm b3JtZWQgaWYgdGhlIEdsb2JhbCBBZG1pbmlzdHJhdG9yIGZpZWxkIGNvbnRhaW5zIGFuIHVuYWxs b2NhdGVkLDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG1hbGZvcm1lZCBpZiB0 aGUgR2xvYmFsIEFkbWluaXN0cmF0b3IgZmllbGQgY29udGFpbnMgYW4gdW5hbGxvY2F0ZWQsPC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDI4Ij48 dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsYmxvY2siPiAgIHVuYXNzaWduZWQgb3IgcmVzZXJ2ZWQgQVNOIG9yIGlzIHNldCB0byBvbmUg b2YgdGhlIHJlc2VydmVkIDxzcGFuIGNsYXNzPSJkZWxldGUiPkxhcmdlIEJHUDwvc3Bhbj48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgdW5hc3NpZ25lZCBvciByZXNlcnZlZCBB U04gb3IgaXMgc2V0IHRvIG9uZSBvZiB0aGUgcmVzZXJ2ZWQgPHNwYW4gY2xhc3M9Imluc2VydCI+ QkdQIExhcmdlPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgQ29tbXVuaXR5 IHZhbHVlcyBkZWZpbmVkIGluIFNlY3Rpb24gNS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICBDb21tdW5pdHkgdmFsdWVzIGRlZmluZWQgaW4gU2VjdGlvbiA1LjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij43LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnM8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij43LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnM8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhpcyBleHRlbnNpb24gdG8gQkdQIGhh cyBzaW1pbGFyIHNlY3VyaXR5IGltcGxpY2F0aW9ucyBhcyBCR1A8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICBUaGlzIGV4dGVuc2lvbiB0byBCR1AgaGFzIHNpbWlsYXIgc2VjdXJp dHkgaW1wbGljYXRpb25zIGFzIEJHUDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgQ29t bXVuaXRpZXMgW1JGQzE5OTddLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIENv bW11bml0aWVzIFtSRkMxOTk3XS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg VGhpcyBkb2N1bWVudCBkb2VzIG5vdCBjaGFuZ2UgYW55IHVuZGVybHlpbmcgc2VjdXJpdHkgaXNz dWVzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhpcyBkb2N1bWVudCBkb2Vz IG5vdCBjaGFuZ2UgYW55IHVuZGVybHlpbmcgc2VjdXJpdHkgaXNzdWVzPC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICBhc3NvY2lhdGVkIHdpdGggYW55IG90aGVyIEJHUCBDb21tdW5pdGll cyBtZWNoYW5pc20uICBTcGVjaWZpY2FsbHksPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgYXNzb2NpYXRlZCB3aXRoIGFueSBvdGhlciBCR1AgQ29tbXVuaXRpZXMgbWVjaGFuaXNt LiAgU3BlY2lmaWNhbGx5LDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyIGlkPSJkaWZmMDAyOSI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBhbiBBUyByZWx5aW5nIG9uIHRoZSA8c3Bh biBjbGFzcz0iZGVsZXRlIj5MYXJnZSBCR1A8L3NwYW4+IENvbW11bml0aWVzIGF0dHJpYnV0ZSBj YXJyaWVkIGluIEJHUDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBhbiBBUyBy ZWx5aW5nIG9uIHRoZSA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5CR1AgTGFyZ2U8L3NwYW4+IENvbW11 bml0aWVzIGF0dHJpYnV0ZSBjYXJyaWVkIGluIEJHUDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgbXVzdCBoYXZlIHRydXN0IGluIGV2ZXJ5IG90aGVyIEFTIGluIHRoZSBwYXRoLCBhcyBh bnkgaW50ZXJtZWRpYXRlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgbXVzdCBo YXZlIHRydXN0IGluIGV2ZXJ5IG90aGVyIEFTIGluIHRoZSBwYXRoLCBhcyBhbnkgaW50ZXJtZWRp YXRlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBBdXRvbm9tb3VzIFN5c3RlbSBpbiB0 aGUgcGF0aCBtYXkgaGF2ZSBhZGRlZCwgZGVsZXRlZCwgb3IgYWx0ZXJlZCB0aGU8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBBdXRvbm9tb3VzIFN5c3RlbSBpbiB0aGUgcGF0aCBt YXkgaGF2ZSBhZGRlZCwgZGVsZXRlZCwgb3IgYWx0ZXJlZCB0aGU8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMzAiPjx0ZD48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgPHNw YW4gY2xhc3M9ImRlbGV0ZSI+TGFyZ2UgQkdQPC9zcGFuPiBDb21tdW5pdGllcyBhdHRyaWJ1dGUu ICBTcGVjaWZ5aW5nIHRoZSBtZWNoYW5pc20gdG8gcHJvdmlkZTwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmJsb2NrIj4gICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5CR1AgTGFyZ2U8L3NwYW4+IENv bW11bml0aWVzIGF0dHJpYnV0ZS4gIFNwZWNpZnlpbmcgdGhlIG1lY2hhbmlzbSB0byBwcm92aWRl PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBzdWNoIHRydXN0IGlzIGJleW9uZCB0aGUg c2NvcGUgb2YgdGhpcyBkb2N1bWVudC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICBzdWNoIHRydXN0IGlzIGJleW9uZCB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgTmV0d29yayBhZG1pbmlzdHJhdG9ycyBzaG91 bGQgbm90ZSB0aGUgcmVjb21tZW5kYXRpb25zIGluIFNlY3Rpb24gMTE8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICBOZXR3b3JrIGFkbWluaXN0cmF0b3JzIHNob3VsZCBub3RlIHRo ZSByZWNvbW1lbmRhdGlvbnMgaW4gU2VjdGlvbiAxMTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgb2YgQkdQIE9wZXJhdGlvbnMgYW5kIFNlY3VyaXR5IFtSRkM3NDU0XS48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBvZiBCR1AgT3BlcmF0aW9ucyBhbmQgU2VjdXJpdHkg W1JGQzc0NTRdLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij44LiAgSW1wbGVtZW50 YXRpb24gc3RhdHVzIC0gUkZDIEVESVRPUjogUkVNT1ZFIEJFRk9SRSBQVUJMSUNBVElPTjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjguICBJbXBsZW1lbnRhdGlvbiBzdGF0dXMgLSBS RkMgRURJVE9SOiBSRU1PVkUgQkVGT1JFIFBVQkxJQ0FUSU9OPC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIFRoaXMgc2VjdGlvbiByZWNvcmRzIHRoZSBzdGF0dXMgb2Yga25vd24g aW1wbGVtZW50YXRpb25zIG9mIHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IFRoaXMgc2VjdGlvbiByZWNvcmRzIHRoZSBzdGF0dXMgb2Yga25vd24gaW1wbGVtZW50YXRpb25z IG9mIHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgcHJvdG9jb2wgZGVmaW5lZCBi eSB0aGlzIHNwZWNpZmljYXRpb24gYXQgdGhlIHRpbWUgb2YgcG9zdGluZyBvZiB0aGlzPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgcHJvdG9jb2wgZGVmaW5lZCBieSB0aGlzIHNw ZWNpZmljYXRpb24gYXQgdGhlIHRpbWUgb2YgcG9zdGluZyBvZiB0aGlzPC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICBJbnRlcm5ldC1EcmFmdCwgYW5kIGlzIGJhc2VkIG9uIGEgcHJvcG9z YWwgZGVzY3JpYmVkIGluIFtSRkM3OTQyXS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICBJbnRlcm5ldC1EcmFmdCwgYW5kIGlzIGJhc2VkIG9uIGEgcHJvcG9zYWwgZGVzY3JpYmVk IGluIFtSRkM3OTQyXS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRoZSBkZXNjcmlw dGlvbiBvZiBpbXBsZW1lbnRhdGlvbnMgaW4gdGhpcyBzZWN0aW9uIGlzIGludGVuZGVkIHRvPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhlIGRlc2NyaXB0aW9uIG9mIGltcGxl bWVudGF0aW9ucyBpbiB0aGlzIHNlY3Rpb24gaXMgaW50ZW5kZWQgdG88L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIGFzc2lzdCB0aGUgSUVURiBpbiBpdHMgZGVjaXNpb24gcHJvY2Vzc2Vz IGluIHByb2dyZXNzaW5nIGRyYWZ0cyB0bzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIGFzc2lzdCB0aGUgSUVURiBpbiBpdHMgZGVjaXNpb24gcHJvY2Vzc2VzIGluIHByb2dyZXNz aW5nIGRyYWZ0cyB0bzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgUkZDcy4gIFBsZWFz ZSBub3RlIHRoYXQgdGhlIGxpc3Rpbmcgb2YgYW55IGluZGl2aWR1YWwgaW1wbGVtZW50YXRpb248 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBSRkNzLiAgUGxlYXNlIG5vdGUgdGhh dCB0aGUgbGlzdGluZyBvZiBhbnkgaW5kaXZpZHVhbCBpbXBsZW1lbnRhdGlvbjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgaGVyZSBkb2VzIG5vdCBpbXBseSBlbmRvcnNlbWVudCBieSB0 aGUgSUVURi4gIEZ1cnRoZXJtb3JlLCBubyBlZmZvcnQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICBoZXJlIGRvZXMgbm90IGltcGx5IGVuZG9yc2VtZW50IGJ5IHRoZSBJRVRGLiAg RnVydGhlcm1vcmUsIG5vIGVmZm9ydDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgaGFz IGJlZW4gc3BlbnQgdG8gdmVyaWZ5IHRoZSBpbmZvcm1hdGlvbiBwcmVzZW50ZWQgaGVyZSB0aGF0 IHdhczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGhhcyBiZWVuIHNwZW50IHRv IHZlcmlmeSB0aGUgaW5mb3JtYXRpb24gcHJlc2VudGVkIGhlcmUgdGhhdCB3YXM8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHN1cHBsaWVkIGJ5IElFVEYgY29udHJpYnV0b3JzLiAgVGhp cyBpcyBub3QgaW50ZW5kZWQgYXMsIGFuZCBtdXN0IG5vdDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgIHN1cHBsaWVkIGJ5IElFVEYgY29udHJpYnV0b3JzLiAgVGhpcyBpcyBub3Qg aW50ZW5kZWQgYXMsIGFuZCBtdXN0IG5vdDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg YmUgY29uc3RydWVkIHRvIGJlLCBhIGNhdGFsb2cgb2YgYXZhaWxhYmxlIGltcGxlbWVudGF0aW9u cyBvciB0aGVpcjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGJlIGNvbnN0cnVl ZCB0byBiZSwgYSBjYXRhbG9nIG9mIGF2YWlsYWJsZSBpbXBsZW1lbnRhdGlvbnMgb3IgdGhlaXI8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGZlYXR1cmVzLiAgUmVhZGVycyBhcmUgYWR2 aXNlZCB0byBub3RlIHRoYXQgb3RoZXIgaW1wbGVtZW50YXRpb25zIG1heTwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIGZlYXR1cmVzLiAgUmVhZGVycyBhcmUgYWR2aXNlZCB0byBu b3RlIHRoYXQgb3RoZXIgaW1wbGVtZW50YXRpb25zIG1heTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgZXhpc3QuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZXhpc3Qu PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlm ZjAwMzEiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxibG9jayI+ICAgQXMgb2YgdG9kYXkgdGhlc2UgdmVuZG9ycyBoYXZlIHByb2R1 Y2VkIGFuIGltcGxlbWVudGF0aW9uIG9mIDxzcGFuIGNsYXNzPSJkZWxldGUiPkxhcmdlPC9zcGFu PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBBcyBvZiB0b2RheSB0aGVzZSB2 ZW5kb3JzIGhhdmUgcHJvZHVjZWQgYW4gaW1wbGVtZW50YXRpb24gb2YgQkdQPC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsYmxvY2siPiAgIEJHUCBDb21tdW5pdGllczo8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJibG9jayI+ICAgPHNwYW4gY2xhc3M9Imluc2VydCI+TGFyZ2U8L3NwYW4+IENvbW11 bml0aWVzOjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBvICBDaXNjbyBJT1Mg WFI8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBvICBDaXNjbyBJT1MgWFI8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgbyAgRXhhQkdQPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgbyAgRXhhQkdQPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDMyIj48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgbyAgR29CR1A8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBvICBHb0JHUDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICBvICBCSVJEPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg byAgQklSRDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBvICBPcGVuQkdQRDwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG8gIE9wZW5CR1BEPC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG8gIHBtYWNjdDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgIG8gIHBtYWNjdDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICBvICBRdWFnZ2E8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBvICBRdWFnZ2E8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KCiAgICAgPHRyPjx0ZD48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48 dGQ+PC90ZD48L3RyPgogICAgIDx0ciBpZD0iZW5kIiBiZ2NvbG9yPSJncmF5Ij48dGggY29sc3Bh bj0iNSIgYWxpZ249ImNlbnRlciI+Jm5ic3A7RW5kIG9mIGNoYW5nZXMuIDMyIGNoYW5nZSBibG9j a3MuJm5ic3A7PC90aD48L3RyPgogICAgIDx0ciBjbGFzcz0ic3RhdHMiPjx0ZD48L3RkPjx0aD48 aT41MyBsaW5lcyBjaGFuZ2VkIG9yIGRlbGV0ZWQ8L2k+PC90aD48dGg+PGk+IDwvaT48L3RoPjx0 aD48aT42OCBsaW5lcyBjaGFuZ2VkIG9yIGFkZGVkPC9pPjwvdGg+PHRkPjwvdGQ+PC90cj4KICAg ICA8dHI+PHRkIGNvbHNwYW49IjUiIGNsYXNzPSJzbWFsbCIgYWxpZ249ImNlbnRlciI+PGJyPlRo aXMgaHRtbCBkaWZmIHdhcyBwcm9kdWNlZCBieSByZmNkaWZmIDEuNDUuIFRoZSBsYXRlc3QgdmVy c2lvbiBpcyBhdmFpbGFibGUgZnJvbSA8YSBocmVmPSJodHRwOi8vd3d3LnRvb2xzLmlldGYub3Jn L3Rvb2xzL3JmY2RpZmYvIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvdG9vbHMvcmZjZGlmZi88L2E+ IDwvdGQ+PC90cj4KICAgPC90Ym9keT48L3RhYmxlPgogICAKICAgCjwvYm9keT48L2h0bWw+ --_004_40D942F5071046D1BF0976C827377479ciscocom_-- From nobody Fri Nov 4 07:51:57 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEFA612951A; Fri, 4 Nov 2016 07:51:54 -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, 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] 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 pipzHZwhZEgp; Fri, 4 Nov 2016 07:51:53 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0103.outbound.protection.outlook.com [104.47.36.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 AE10D129503; Fri, 4 Nov 2016 07:51:52 -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=7neizljorTkRfz5Ow3RQXROMZjfz1o2Nqr4FSL5SG4Y=; b=PmU79vY74oiNawL3oDF72IEEhBKgi1S/py74qCuxzFlzzi06Y0JnZOUVpEghk9WXpH8SThxbV9Y8l/LCnALJG+/0wIN0oR6ngmLbrG1sxVBRRY3J4knsPE3kp5bMJo3NexkBF07SZ8ppSbq94wzgrK1HyfGR/vP40fUEl+O62rA= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; Received: from [172.29.33.22] (66.129.241.11) by BN3PR05MB2497.namprd05.prod.outlook.com (10.167.3.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.679.4; Fri, 4 Nov 2016 14:51:50 +0000 From: "John G. Scudder" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 4 Nov 2016 10:51:45 -0400 Message-ID: <5EEFB890-8371-4DA3-8587-D62EA9C87B8B@juniper.net> To: MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.11] X-ClientProxiedBy: BN3PR04CA0022.namprd04.prod.outlook.com (10.166.70.160) To BN3PR05MB2497.namprd05.prod.outlook.com (10.167.3.26) X-MS-Office365-Filtering-Correlation-Id: 0bfea77c-c023-460c-4fab-08d404c21c59 X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2497; 2:u1ziBVCcP9cA0wOoH/t0JexuDakZRZ/3IhlgNp3NHuahqQDEN9A/Wf+NLa+BcSD9HhUAhBvNUZH+Fnay2VlJ2Z/cckfgGn+H84HEZOaB1bEQZ8oXqhuA8v1EEO37JXTDeB78FPW8f/JijiNauzc7CMxxyGhZbjHwMD+zm7h9Gd3zXpuBSdfe66w1dpXoJhsz6Vja336Y1RCRVqqrEU/99g==; 3:kpQPAk49BW/s7Owp86t/T6H+II0P8PXhbqWd4ZCSN+Tojy9H4l9C0Pc1/dyyWaxsN7uIVSNihVwtPcWkA0Wo3ITtg9y4SNGZalSv3idNX9rQ+ht1OzK3dSDbJzbuJ5oxS1KKftLqI/HxhQ/93rjQrA==; 25:MY7j3oHv4rPjj8WDTO7bZOxTVISH0zDeKaX2pWLTGOelwMvIY+OHcJl0UXjoCAzSSkNA1Rjekz2Zq0HzVK0XVaF5hnCBAf7xkVtE5cmiAsYSderhSD0VfvcGfqGoRxrea+jgSAF9KEmy7cJkrFuf+uttnZG3tmPXgi8r058bbpgDl5X3WPf5WuO7ok4FqvwHkikAalghCnKkQOV736gZmx/njaLyKiqvI9twQ2xlz83VsJA8Q9saNNuo02de1YV1bwJ/gENUY3LL7BVNP6EvK4vlGNtB59efV5DRxkz8KVsr1MCv1KADTPsG8ZYjrOcfyir9whNPHcSF8t1mKduQVujnm6wUEpviRijzK23O2INV+pwOMBw8RzS9iOKZqwY2MoHg1bFbpl5lTt7myWk0ehKwBxXZGhE1k8nQh7P7zll+NMmcNFDP1KxM9fsWFedI X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR05MB2497; X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2497; 31:5+XgLFNm2MDWyTPACCer3OHg8MW7HnWOvloFiEZ/A1opnM0JEGxV/q9Hj/ttwc8R7KR2QOghri4+9m9bvOqxxwxDwASkmYQ5H6mKIviiEYLMJM64lQ6E4lq3+Clgdh+N1UFttUF00jZMa7yBPoS0GT5mnwmLRlFrNqdX77ixD63XL2hhAsepU10/mB5iIx7dFxcLXnnX0poTpASAvh7kABpCAtlfdHsIuPcJ645SYnKcVzEog3924VRf8j4I6TLDORON+kXDCWnoTJ7A6ivIcQ==; 20:i3hAaeNHToKLgUtUrDXGTh6AsKx83BIFSgHma7zb0kTNUrYQPvekYTwT/3xavgoc1Ysp4GMi+iV2fzzgswMG9NvG0C7UmxeNeontqKN24fbFpnHm883I1vvw5cym6GCEOYKDP6EDHPsnUbei8kHd6tdXEtWBP6JOl4JsCHJjIv6JmjFiRACUreUio2+D+gzm/KEDtwArOeZbHF7KSfCUhPPlngWFOfIreO5elxYXozcW5XhekQZZk6g8vHzjtNM5o2E8xjxFCLh7THtArX0njo463JbIU8U6uiRd8+vnZNoAXDq9ZJlxjeyjqrq71qDJyvu/7svOYHHuXL45NxfofOTGexxzTBS/26n2sJOPsWzHRGjMZyQN8a8xHeACaMkhyIBixSruZgT1aTm8CfxtLcMrIqYsA+ZxDkIYE3JVB3yMHQzrWYpmIWnZAQNGCmFSxggxUH/mn9aH2SVrZ6gR8lXGnrrabquRcM5p6d0kaM073vdU/5UW5+9r7Tx6sC7pFUD7yZVOp3VTdtB7BcfJoZ2QJjvuMe0LcsCzR/X3WDRkIXxZXuB7SY0q7qcANi4U1CsRV9ZSap4t76Tmx4FnACRKGo2DCg4i+iUeu0EDcC4= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:BN3PR05MB2497; BCL:0; PCL:0; RULEID:; SRVR:BN3PR05MB2497; X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2497; 4:/kr79kTW5F29hQxi6SpcZC9RMS3zwJkct7RPX84K8YyyZGOtEwcEO5o8ND8mOeg/2JZl4kBnZuJaq0P0LSsWe3+VBP4M7CgXdxk6BEeI7Py+usNZmNtcVsKeGcvn7vZRcrBUMQxgwMHcgr6+scWdeXPAfr9rO0vk0bcmiD3qay5RP484IbiI/ntoa6uu5E1bOnN+kRdIaIgH2GFbSEXfUCmXh5mELjylFVtMAjD3D4dFdY37GZVOHMqfPYEfTALwECGZDrGLUL8anfcIJXxt9REmFELIjzznUp0ruECGdSdWM1wLDyMl5d78S20IVMDbt9TM3OZ8FfRHPuhcEZIOBJANp92F0bQuDCcM5Z5ibuWshZoCq6MmwQ0I0OZKEDOBv45/LekTrPW+MX9R5W9JdxrFWHcvCc+lLk/OXfiHeHU= X-Forefront-PRVS: 01165471DB X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(7916002)(199003)(189002)(6916009)(81166006)(92566002)(42186005)(50466002)(105586002)(81156014)(4326007)(106356001)(101416001)(82746002)(189998001)(50986999)(77096005)(2906002)(450100001)(97736004)(6666003)(229853001)(46406003)(110136003)(2351001)(50226002)(8746002)(47776003)(5660300001)(6116002)(57306001)(8676002)(97756001)(586003)(36756003)(83716003)(7736002)(86362001)(7846002)(3846002)(305945005)(68736007)(23726003)(66066001)(33656002)(42262002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR05MB2497; H:[172.29.33.22]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR05MB2497; 23:JQxiSaGAsteCWVxx/7lo2o24+KZtd0lT8+1fpPWt1?= =?us-ascii?Q?V3F/nUZ57zs14FCM3X3tIfdmoPROrDj4r8FDUli0zy3v09YWGIYDOiEPogAS?= =?us-ascii?Q?l8IHv4QwIhpCBLheRLgKiPshkC6PikhCJ6QH17vsbz7KIhp3PW3l80jtMWuj?= =?us-ascii?Q?f2s2MpBknvnySlIH/24M8etnzZVqokjww+MPNUpacEJ0BLJ3BhzzI42Dp0KX?= =?us-ascii?Q?t3cfuieWd/+enV/MtYkQj4CAVckDvIbJwqyYuni3EjywjE1vdMe0ai3ZthJG?= =?us-ascii?Q?mUr2It91tyNEHA55KLdiPxI8keNhzOOsEr0ZXjnuYxSe1A5v3/hgL7lgao+J?= =?us-ascii?Q?LVJMJzGn/miEk6OOo5rUuwxYYIrY6gVDgtCgwV/R+r1OaQlUWHQXZorT1ZqH?= =?us-ascii?Q?TRdB9M45/emgTigMfzeGu9Rp/lPTVxo6haXp0mKlg/eK9lXKeyucxtULAM6s?= =?us-ascii?Q?BIIPMmA2ckM4GhPuiF9Pi903CdrvyuCB+blNGGkUaxo7iRg8+dB4uY8jA/cO?= =?us-ascii?Q?1Jf8VGiIsupCc3FfYl///1S8dMQC9vKLLbz0aD6zJEdchLZAXvgCFoAjy6hH?= =?us-ascii?Q?BFcjJ/1dk6KT0UYkmJXfV2Xhju7fmGwdDpnSFxo5gZk5jfy9bcY/phbF7jCc?= =?us-ascii?Q?FB0T1dDvwIVUTCMiCOfiQc4l+f/f+bgdcVvHyyYoxKwBBbiQx05Pgq6LpVOH?= =?us-ascii?Q?1bpzMla4zOzIv0pO3tte0NyI1ABSVHbJl74kZLTZ17pElPu31EH8x1/Lbfpg?= =?us-ascii?Q?v3c8qktLJG5zJQfBpK5eaV1U16vCFBR67CcVtel0WiExylfve+yfa8weL8eG?= =?us-ascii?Q?hFaXkMIv02puZiF6qXwclNkQyraIx/1QjBvAfRD7KR9uaLN21qmx8stPFuLO?= =?us-ascii?Q?5rfXjtd0Pewx5wYiDCIJZ6d+uGav2k2ut0IH0uDoO6Qdqu5OtL/UME+Tr4HI?= =?us-ascii?Q?gMwM5EytPEHatPm+ggBqEmrOUqvGkzaNNyES3q1V6hMOskW9WDY0xgyW61b8?= =?us-ascii?Q?OOgHoBHMge7wI5YNgETR+CF0QmrPZBv03QBvrp4CNNFOKVkjTYmPWUStmihi?= =?us-ascii?Q?sONM13X3/q4npZ/ynNG8rKgXezgtf0bNcRX+j3Yk9rUdhoyrfoXqYfH2hgXA?= =?us-ascii?Q?/nRa7Cj8gNexH5UvheJ67FlVnHD4+F3sKlvqWnYeygfZeJq2jbibnulfSF4R?= =?us-ascii?Q?BeUJnWm/FnlSEQ=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2497; 6:4eS+2ysLJQubytIk993byM+pC1wh0LNnGdc5atQS+eBvszBPNRDu+SAlmaflJy7MY5lro8wdOkeW12rGYzT0uNmYGHOdj0Cr4QC+3uBYFeZI0bYzNRb6EhF+3ZM0CuQUBtBqNVAx7mXBLYs1KA86NLesl7xLy7RGXEjXtTda6dLuExn8aD/lxmYbfSV91plIHUu3gw25ZDswA3xdlTW7DDc9KIbleipC9CzOTlgV2Q9mLfT5Y98ijJ84oIaRqNeokNFX74SckcyO9ZJ99fDzWlnQIbI6uXKvM3x6chAkVcfYRK170euNthaHzujP0ewdMikbtH99swZCURWqg8yEcj7OVktzuH/DnH9MtVr6KVA=; 5:D/m2R9MkQ/sQKimIT6F0gfdwx0m8zfrELfass6xMp92g7qBajb6OiragZ29q5lmE3snveuTl0gBBkGxENJqmhmTU7G8VtI7JZcPIlv1Pch7cnrEEzMDF7DmqTSmjHIpxA6TobfhIF7MfrTSqJrC/ow==; 24:Z9/hSarMxP/y7Pxt5FzFll8wKlouk+oZWq1q0L0zaGhZTL+z4bzS5GUrdMmaBaRT0mvRDalvX/TBnM6/5Pk97mTklXLx20KvMP1DB6f39ds= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2497; 7:UlKiFGaP5eaYr/Vm2tB85n00/3s0g+5hB2R2+OxFWpB7ZJQSf4abu0KSAKPMcMgDxnmKK+5HEych3qOW7inZtFR9WVUAm8lijVKQON6gXD63tLhx2s5KOrrUL5ey7uQDTP8NfAFlduu3e/RUyu5Tbm0IqWv9VkTDc39bPbsOxheu1Y6rRj3R9/eE1R1WRTAgNelocK6kCK+xXfh7efCBYgoqA3T2W0yBj12SsEBKWzfcR2NZBK3eedgSp6DszSSJVH0ykOPqh85cGMzfMSsRO4N9c2f5OiJRCyzwTMK6hVgLN6sUHROYZfosbqiJFSdTrnbpPbXhgaoiQWnBPOhZQIMSYmghsViqqOrm1+n37Os= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Nov 2016 14:51:50.9151 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR05MB2497 Archived-At: Cc: idr@ietf.org Subject: [Idr] IPR declaration needed for advancing large-community 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, 04 Nov 2016 14:51:55 -0000 Hi Large Authors, As part of preparing the shepherd report, I need to answer the following = question: (7) Has each author confirmed that any and all appropriate IPR = disclosures required for full conformance with the provisions of BCP 78 = and BCP 79 have already been filed. If not, explain why? So: Each author listed on the front page, please confirm this for me by = replying to this email. Please leave the working group in the cc. Thanks. I realize some of you have already done this earlier in the = process, and I appreciate your willingness to do it again. --John= From nobody Fri Nov 4 07:54:32 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73127129554 for ; Fri, 4 Nov 2016 07:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 Ao_FquAHibws for ; Fri, 4 Nov 2016 07:54:26 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::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 4D0701294A0 for ; Fri, 4 Nov 2016 07:54:24 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id 128so165951073oih.0 for ; Fri, 04 Nov 2016 07:54:24 -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=WkYWXEZ9u0rJUxilCgyQfMLWk15gbwW48LwKP9MAB9k=; b=kmwZrzsXxraZI79TfG35OSjYuzGcsPxsrTTIIXOrzBmIRgyamqfLxoZusTOHhbi+A9 wiCNBwz5yq6onpfPzxFDfFWlvNul96ZtNmc4b5dZfZrJ8NhFl4PrwerpvblZiCKw2vXq KKxCXaHzyNugmceCg3xollVuoAMv+YAl+/W9WhuuUuopiw2mzMwg65HukTBibqFPzX2L o5J1aHvzeE35jhUtHeumUMUBCS4ghNW8naQIL7fon/0BxeHrpDnDl1TWnxFwR4gZA0uc 8ijXktw89wNItSOXcpy/KAnqtn+hyh0TjoE2eClMR+SHwZO9EB+JC1iMCSVti/9/p8V0 Z69A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WkYWXEZ9u0rJUxilCgyQfMLWk15gbwW48LwKP9MAB9k=; b=h10/yShgjEyRAS7SaBBUJ8fFUJlPBc5e1S3q4tnFwR3NhU8PJvfMd1IBmK8wFXhK9k Rqj1IHu83tYn05U2GADD1Z06gAQvdJXi6CMM0/MCnmxtDCkM7tzEJiPiSLMyhUqt0SPw UNL0vE+ChedvPpY3Te+7qA7ytczVDVZrxFItzrL+ROBF4JO6geS6bv62FhHEYxUWUNG7 MeAAT1IRmGVene7HQ98TrcL6DGUcWJi6JvNmzes0OceYO3XsSlOe0/HYYH61IMp4jrKI uzkSBcXngYSrgc14J+FiRy0PcRnjbrbS0RTKo3oN5wLpYqWHhJ6Cds5pPMUxCSjLkKzj wvpQ== X-Gm-Message-State: ABUngvecpI6d7g1PJyFwiiBrrheDz/3Ogucs9oINk9pXVgzIjpU32ahzn3lPVXeUIjLYXReWNcSil6s04SmZCA== X-Received: by 10.157.29.72 with SMTP id m66mr11207693otm.152.1478271263708; Fri, 04 Nov 2016 07:54:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.144.163 with HTTP; Fri, 4 Nov 2016 07:54:22 -0700 (PDT) X-Originating-IP: [188.206.66.42] In-Reply-To: <5EEFB890-8371-4DA3-8587-D62EA9C87B8B@juniper.net> References: <5EEFB890-8371-4DA3-8587-D62EA9C87B8B@juniper.net> From: Job Snijders Date: Fri, 4 Nov 2016 15:54:22 +0100 Message-ID: To: "John G. Scudder" Content-Type: multipart/alternative; boundary=001a113ba4c08e33e405407ad9ba Archived-At: Cc: "idr@ietf.org" , "draft-ietf-idr-large-community@ietf.org" Subject: Re: [Idr] IPR declaration needed for advancing large-community 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, 04 Nov 2016 14:54:28 -0000 --001a113ba4c08e33e405407ad9ba Content-Type: text/plain; charset=UTF-8 I have no IPR related to this work. Cheers! Job On Friday, 4 November 2016, John G. Scudder wrote: > Hi Large Authors, > > As part of preparing the shepherd report, I need to answer the following > question: > > (7) Has each author confirmed that any and all appropriate IPR disclosures > required for full conformance with the provisions of BCP 78 and BCP 79 have > already been filed. If not, explain why? > > So: Each author listed on the front page, please confirm this for me by > replying to this email. Please leave the working group in the cc. > > Thanks. I realize some of you have already done this earlier in the > process, and I appreciate your willingness to do it again. > > --John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --001a113ba4c08e33e405407ad9ba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I have no IPR related to this work.=C2=A0

<= div>Cheers!

Job

On Friday, 4 November 2016,= John G. Scudder <jgs@juniper.net= > wrote:
Hi Large Authors,

As part of preparing the shepherd report, I need to answer the following qu= estion:

(7) Has each author confirmed that any and all appropriate IPR disclosures = required for full conformance with the provisions of BCP 78 and BCP 79 have= already been filed. If not, explain why?

So: Each author listed on the front page, please confirm this for me by rep= lying to this email. Please leave the working group in the cc.

Thanks. I realize some of you have already done this earlier in the process= , and I appreciate your willingness to do it again.

--John
_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr
--001a113ba4c08e33e405407ad9ba-- From nobody Fri Nov 4 07:56:31 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E36881294A0; Fri, 4 Nov 2016 07:56:28 -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, 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 sqkPPiQQHqjv; Fri, 4 Nov 2016 07:56:27 -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 EB813129559; Fri, 4 Nov 2016 07:56:23 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id n67so55010961wme.1; Fri, 04 Nov 2016 07:56:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=ANYJ/dcKpjhVStqK8vvSgf3IL8mu7ovk3bMSaSifYyU=; b=iKgmcOk69eLMgL7tff5h5Q8AEqg18MTu0j+UGTo8WA7tr936167Dxji+0A6b5Ba0PJ PMZ4rs/0xcU25zBiM9St1PIJPlloCfZ8Mf/S68v6GtECmxxV2dq983jjExPyMk0mMNM7 uFLZE7MigAy7yFRmvRyTxbs2SMBseMEndmELRkYGMJWSIFM2JMqEf+bbla+PNGCiA/bB kkVDdqZooyH1vxU+EXZd3AgBrCp2QuYZTmQx1wC+yAT8eTfXNGBGzs4G1QdS2PmG5bM4 cZthu2IlFIc63SrbmPDALriJdStfTuMPEx93AlM3xjWllQtriIm/0dO62UtXRjfNUKAt WU0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=ANYJ/dcKpjhVStqK8vvSgf3IL8mu7ovk3bMSaSifYyU=; b=Gk9BbbWT+W7h/MYurrYRAktnKpBLDbp88nim+yWGi58hDD5YXjr4By0X+fSMQmqoEI DjtcA2BlYGuLJyHRySjWTAoH2CE1EFyr9PHGQS8A7QZIliTKlSOTepoGzXYVYgej+mIs ztWNgCgeeuu8ZpH5w/ecCHPFYQdq3lIrlz0qdiXS1ixkYIrfN3B7HE8Z8R6Um4VFmuN+ BkHePLm8ZtTa4mBa+0iGjsn+TWde68ksPtkFU5K2ywtlmhV2n+pFlZPuAbR8HXT0pI/K M9DhVJURFpxOZcA5zVVCbRjY1KGnzKbIRkc7BnGjs/cgeNK4SkRBT+WH43Q/MJ2Rm8HT PCqg== X-Gm-Message-State: ABUngvdzctdYPhBSC438MbS8vn1/6bmIePoJij889wAJ7j9uefFr3jnQyV0JF/r/4DBogA== X-Received: by 10.28.71.14 with SMTP id u14mr4218322wma.10.1478271382048; Fri, 04 Nov 2016 07:56:22 -0700 (PDT) Received: from [192.168.191.217] ([80.69.10.100]) by smtp.gmail.com with ESMTPSA id kq7sm14599325wjb.0.2016.11.04.07.56.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Nov 2016 07:56:20 -0700 (PDT) To: "John G. Scudder" , draft-ietf-idr-large-community@ietf.org References: <5EEFB890-8371-4DA3-8587-D62EA9C87B8B@juniper.net> From: Ignas Bagdonas Message-ID: <62e00e6e-d02e-beb9-dbab-1386de0d76f2@gmail.com> Date: Fri, 4 Nov 2016 14:56:18 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <5EEFB890-8371-4DA3-8587-D62EA9C87B8B@juniper.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: idr@ietf.org Subject: Re: [Idr] IPR declaration needed for advancing large-community 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, 04 Nov 2016 14:56:29 -0000 Hi John, I do not hold and I am not aware of any IPR related to the document. Ignas On 04/11/2016 14:51, John G. Scudder wrote: > Hi Large Authors, > > As part of preparing the shepherd report, I need to answer the following question: > > (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? > > So: Each author listed on the front page, please confirm this for me by replying to this email. Please leave the working group in the cc. > > Thanks. I realize some of you have already done this earlier in the process, and I appreciate your willingness to do it again. > > --John From nobody Fri Nov 4 07:58:06 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEA98129406; Fri, 4 Nov 2016 07:58:04 -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, 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] 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 Vj_l9_A-7njl; Fri, 4 Nov 2016 07:58:02 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0082.outbound.protection.outlook.com [104.47.42.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 1E15C1293EC; Fri, 4 Nov 2016 07:58:02 -0700 (PDT) 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=yci60dH8AExd6iglLlqilCWio9xT4aDq/QJ26wswaYw=; b=e13/DbaRGgA7GtV+bz/5bVJiMv87EWci1rFaHonerXTO22S916hZzIoqO1E3mMSdHPKdk2viGtHmDc8r0PTpde5eltFzMD5CZMSdhqbjHtE7t+zVLvlReryf4SXUj2Iv7HEiKua2DIT2Y8ydMyX1RK3LNu3AHgLGDZ8KtywmoyE= Received: from BY2PR18MB0262.namprd18.prod.outlook.com (10.163.72.152) by BY2PR18MB0262.namprd18.prod.outlook.com (10.163.72.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.693.12; Fri, 4 Nov 2016 14:57:59 +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.0693.016; Fri, 4 Nov 2016 14:57:59 +0000 From: Keyur Patel To: "John G. Scudder" Thread-Topic: IPR declaration needed for advancing large-community Thread-Index: AQHSNqr+0fCegQbgM0WHDbfx3RgQ/KDI6lR/ Date: Fri, 4 Nov 2016 14:57:59 +0000 Message-ID: <81D5114C-A99E-48E5-AF98-4D57FDF8A6EE@arrcus.com> References: <5EEFB890-8371-4DA3-8587-D62EA9C87B8B@juniper.net> In-Reply-To: <5EEFB890-8371-4DA3-8587-D62EA9C87B8B@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=keyur@arrcus.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2601:646:8980:4f18:404d:de6f:1aed:d6de] x-ms-office365-filtering-correlation-id: 63b70c66-30e3-4058-542c-08d404c2f7c9 x-microsoft-exchange-diagnostics: 1; BY2PR18MB0262; 7:w6O/tt5venYfBmfYhquAssWGZM0bn1m3NAHO8YWaWsFcdj5y/i2ii4TCSWPc1+X08SEyvhOYS21KN6WruV1rsewJ/pgYeEs1+BaYrnwuMRJQmfd8Ncok6BrkUrffEU4ZO0ZEdX6cMPN08SK6wKUs1evdlz4Ai8Tr7J4gMlAGA4ykxujvjC1nDl16UCDQyY+SSBhLjl6odJB8YeSLpy+3x8UL/hFDj2LudUQfAwXDTFHLVY04V9ynw3vhtTGhW1uwzwDQL1sn+6VbaAyQi6hqtuSHTSSpMZ8Uf1lYB5rWC6IIPFch1dD7PFWEpi6lPv/BnWnuk+MpJO68j8MWZLS1NMxMBreBCUYW3eGLHy45yRk= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR18MB0262; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6042046)(6043046); SRVR:BY2PR18MB0262; BCL:0; PCL:0; RULEID:; SRVR:BY2PR18MB0262; x-forefront-prvs: 01165471DB x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(199003)(189002)(24454002)(377454003)(106356001)(189998001)(10400500002)(1941001)(9886003)(106116001)(110136003)(5660300001)(8666005)(2950100002)(122556002)(8936002)(3280700002)(7846002)(105586002)(76176999)(54356999)(11100500001)(101416001)(50986999)(305945005)(3660700001)(68736007)(7736002)(99286002)(2900100001)(82746002)(83716003)(77096005)(5002640100001)(8676002)(19580395003)(6916009)(36756003)(586003)(92566002)(4326007)(19580405001)(2906002)(87936001)(6116002)(97736004)(86362001)(5003630100001)(33656002)(81166006)(102836003)(81156014)(7059030)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR18MB0262; H:BY2PR18MB0262.namprd18.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:3; LANG:en; received-spf: None (protection.outlook.com: arrcus.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arrcus.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Nov 2016 14:57:59.1263 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 697b3529-5c2b-40cf-a019-193eb78f6820 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR18MB0262 Archived-At: Cc: "idr@ietf.org" , "draft-ietf-idr-large-community@ietf.org" Subject: Re: [Idr] IPR declaration needed for advancing large-community 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, 04 Nov 2016 14:58:04 -0000 I have no IPR related to this work. Regards, Keyur Sent from my iPhone > On Nov 4, 2016, at 7:51 AM, John G. Scudder wrote: >=20 > Hi Large Authors, >=20 > As part of preparing the shepherd report, I need to answer the following = question: >=20 > (7) Has each author confirmed that any and all appropriate IPR disclosure= s required for full conformance with the provisions of BCP 78 and BCP 79 ha= ve already been filed. If not, explain why? >=20 > So: Each author listed on the front page, please confirm this for me by r= eplying to this email. Please leave the working group in the cc. >=20 > Thanks. I realize some of you have already done this earlier in the proce= ss, and I appreciate your willingness to do it again. >=20 > --John From nobody Fri Nov 4 08:14:16 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28B04129470 for ; Fri, 4 Nov 2016 08:14:14 -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 F73PYEA3VMui for ; Fri, 4 Nov 2016 08:14: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 3C8D81288B8 for ; Fri, 4 Nov 2016 08:14:12 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.175.1; From: "Susan Hares" To: "'t.petch'" , "'John G. Scudder'" , "'Robert Raszuk'" References: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> <20161101133240.GK1581@hanna.meerval.net> <2393790D-F279-41ED-B5B2-E427C60B4926@juniper.net> <034a01d23639$fa2c78e0$ee856aa0$@ndzh.com> <050f01d2369c$e82e1d20$4001a8c0@gateway.2wire.net> In-Reply-To: <050f01d2369c$e82e1d20$4001a8c0@gateway.2wire.net> Date: Fri, 4 Nov 2016 11:11:46 -0400 Message-ID: <01d901d236ad$c315beb0$49413c10$@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: AQG4XNVJbFLLu0eQmTL8gVJbAkCFVwDjdK5pAXaolZsCtVg7VQEQjTOTAOpitqKgxE0yAA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'IETF IDR Working Group' Subject: Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129 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, 04 Nov 2016 15:14:14 -0000 Tom: The IETF list discussion of RFC5226bis is the right place to make progress on this work. Alvaro Retana (the AD for IDR) has agreed to help push this along as well. Send Alvaro notes on your concerns. With a reference to RFC5226bis, then draft-snijders-idr-deprecate-30-31-129 will be able to "deprecate" the code points at this point. When the RFC5226bis comes out, Michelle Cotton (and all the great folks at IANA) will adjust the tables. As the IDR list has indicated, deprecate needs to be carefully defined. I appreciate you working on this topic on the IETF list. Otherwise, we'll have this conversation again with 2-3 years. Sue Hares -----Original Message----- From: t.petch [mailto:ietfc@btconnect.com] Sent: Friday, November 4, 2016 9:11 AM To: Susan Hares; 'John G. Scudder'; 'Robert Raszuk' Cc: 'IETF IDR Working Group' Subject: Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129 ----- Original Message ----- From: "Susan Hares" To: "'John G. Scudder'" ; "'Robert Raszuk'" Cc: "'IETF IDR Working Group'" Sent: Friday, November 04, 2016 1:22 AM > John: > > My understanding with the IESG and IANA is that this is true. The best > reference is the BIS for RFC226bis below: > > https://tools.ietf.org/html/draft-leiba-cotton-iana-5226bis-11 > > The RFC5226bis-11.txt got stalled due to the IESG wandering if the revision > is needed. Based on our experience, I think it is needed. Alvaro will kick > off this work, but the process of updating a "process" document should not > impede this document's process. We need to think outside the box. > > I suggest we complete this adoption of > draft-snijders-idr-deprecate-30-31-129 draft by 11/13/2016, and do a WG LC > on the draft directly following this process draft (11/14 to 11/28). This > should allow the draft-idr-large-communities to have the necessary registry > "glue" ready so the IESG publication of large communities can go quickly. Sue The reason I am being a bit 'snarky' on this adoption call is my concern that there may be differing views of what 'deprecate' means. For example, the SMI world gives it a different (and IMO unsuitable) meaning which some on this list will know. Even the 5226bis text might not be quite right. Robert did query whether or not 'deprecate' was suitable. If we take 5226bis as gospel, then 'deprecate' is probably the option to choose but I wish that there were more alternatives. I was about to post to the main IETF list and Terry Mandelson(as responssible AD) about 5226bis (again:-) but the list has erupted with a discussion about DMARC(again) so I will hold off and see what develops. Tom Petch > > > > Sue > > > > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of John G. Scudder > Sent: Tuesday, November 1, 2016 10:24 AM > To: Robert Raszuk > Cc: IETF IDR Working Group > Subject: Re: [Idr] Working group adoption call for > draft-snijders-idr-deprecate-30-31-129 > > > > AFAICT the function of the draft is simply to kick the IANA code point state > to "deprecated". It doesn't anchor it there for all time. Presumably a later > request can move the state to assigned or whatever, as we've previously > discussed. I don't think any update to the current "deprecate" document > would be needed to achieve this (I guess maybe the later document might list > this one in its "updates" header). > > > > I'll confirm this understanding with IESG and IANA before the end of the WG > adoption call. (Unless someone can point me to chapter-and-verse of a > reference that explains the process clearly enough, unfortunately I have not > found such.) > > > > Thanks, > > > > --John > > > > On Nov 1, 2016, at 10:02 AM, Robert Raszuk wrote: > > > > Hi Job, > > > > Have you consider marking those codepoints as "RESERVED" rather then > "DEPRECIATED". > > > > Reason being that if any of the applications they have been squatted on > behalf of want to use them - it would be pretty easy to allocate them. > > > > The other alternative would be to allocate them to those applications now > (for which the drafts exist) as IANA early allocations. If you depreciate > them now and we know that as example Contrail Multicast is important either > your draft will need to quickly be moved to historic or yet another types > will need to be allocated again. > > > > In any of the above Large Communities will get virgin BGP attribute type > which I believe is the main point here. > > > > Cheers, > > R. > > > > > > On Tue, Nov 1, 2016 at 2:32 PM, Job Snijders wrote: > > Dear working group, > > To prevent having multiple drafts in quick succession covering the same > style of issue - I'd like your feedback on the following: > > I believe that bgp path attribute 241, 242, 243 should also be added to > this draft for the same reasons as 30, 31 and 129 are listed. > > OLD: > This document requests IANA to deprecate the following BGP Path > attributes: 30, 31, and 129. > > NEW: > This document requests IANA to deprecate the following BGP Path > attributes: 30, 31, 129, 241, 242, and 243. > > Does anyone object? If so, why? > > Unilaterally changing the document while in its mid-flight through the > working group adoption process might be considered bad form, hence my > request for feedback on the 241,242,243 topic. > > Please note - the deprecation of an attribute can be undone if proper > process is followed. The priority here is to prevent IANA from assigning > tainted codepoints to innocent bystanders, thus a deprecation document > needs to exist. In time the working group has the power to undeprecate > them for specific purposes. > > Kind regards, > > Job > > On Mon, Oct 31, 2016 at 05:18:57PM -0400, John G.Scudder wrote: > > > Hi Everyone, > > > > The author has asked for the WG to adopt > draft-snijders-idr-deprecate-30-31-129. > > > > If you support or oppose adoption please reply indicating so. Reasons for > your position are helpful, as volunteering to review, comment, and/or > shepherd. As an aside, I will note that I don't think the WG has the option > of doing nothing, so if you oppose adoption please address what you think > should be done instead. > > > > The adoption call will end November 13. > > > > Thanks, > > > > --John > > > > P.S.: > https://tools.ietf.org/html/draft-snijders-idr-deprecate-30-31-129-01 > > > > Abstract > > > > This document requests IANA to deprecate the following BGP path > > attributes values: 30, 31 and 129. > > > > > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > > > > > ------------------------------------------------------------------------ -------- > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > From nobody Fri Nov 4 09:41:21 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55E8512950D; Fri, 4 Nov 2016 09:41: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, 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 ImyfdF0j26P1; Fri, 4 Nov 2016 09:41:14 -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 A9BDC1295C1; Fri, 4 Nov 2016 09:41:13 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.175.1; From: "Susan Hares" To: "'Jeffrey Haas'" , "'Geoff Huston'" References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com> <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com> <4080cfba032744f590fcbbb710f0d618@XCH-ALN-014.cisco.com> <08C97932-4E8B-4EBC-B780-3A2F54A1EEF2@apnic.net> In-Reply-To: Date: Fri, 4 Nov 2016 12:38:56 -0400 Message-ID: <043a01d236b9$f07058f0$d1510ad0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_043B_01D23698.695F7C40" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH7vYX/r5lvDTiDOvRZn6NWFj+MugIVEsE7AusR2FECKfMMFwHKxisSAhTYCDcBtVkRzqAQADnA Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'IETF IDR WG' , rtg-dir@ietf.org Subject: Re: [Idr] Review of draft-ietf-large-community-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: Fri, 04 Nov 2016 16:41:16 -0000 This is a multipart message in MIME format. ------=_NextPart_000_043B_01D23698.695F7C40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Jeff: Should atomic-aggregate be deemed "historical" at this point? This can happen in parallel to this work. Sue From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jeffrey Haas Sent: Friday, November 4, 2016 6:34 AM To: Geoff Huston Cc: IETF IDR WG; Sue Hares; rtg-dir@ietf.org Subject: Re: [Idr] Review of draft-ietf-large-community-06.txt On Nov 4, 2016, at 4:59 AM, Geoff Huston wrote: I just noted that RFC1997 and RFC4360 had these constraints. It seems strange to me that an implementation would handle aggregation differently, treating communities and extended communities one way and large communities in a subtly different manner. Frankly I would prefer to see a consistent treatment of communities in the case of aggregation, and reproducxing the RFC4360 text kinda makes that clear (at least to me) Omitting it invites different handling and that would be not good The relevant point from the thread is that the atomic-aggregate attribute is largely protocol noise. It's a vestigial organ from the BGP-3 to BGP-4 transition, and a poorly specified one at that. We shouldn't include its use in specifications, particularly where discussing aggregation. The only place its discussion would be relevant is as part of *de-*aggregation of a prefix. -- Jeff ------=_NextPart_000_043B_01D23698.695F7C40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Jeff:

 

Should atomic-aggregate be deemed “historical” at this = point?  This can happen in parallel to this work. =

 

Sue

 

From:= = Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jeffrey = Haas
Sent: Friday, November 4, 2016 6:34 AM
To: = Geoff Huston
Cc: IETF IDR WG; Sue Hares; = rtg-dir@ietf.org
Subject: Re: [Idr] Review of = draft-ietf-large-community-06.txt

 

 

On Nov 4, 2016, at 4:59 AM, Geoff Huston <gih@apnic.net> = wrote:

 

I just = noted that RFC1997 and RFC4360 had these constraints.

It seems = strange to me that an implementation would handle aggregation = differently, treating communities and extended communities one way and = large communities in a subtly different manner.

Frankly I would = prefer to see a consistent treatment of communities in the case of = aggregation, and reproducxing the RFC4360 text kinda makes that clear = (at least to me)

Omitting it invites different handling and that = would be not good

 

The = relevant point from the thread is that the atomic-aggregate attribute is = largely protocol noise.  It's a vestigial organ from the BGP-3 to = BGP-4 transition, and a poorly specified one at that.  We shouldn't = include its use in specifications, particularly where discussing = aggregation.

 

The only place its discussion would be relevant is as = part of *de-*aggregation of a prefix.

 

-- Jeff

 

------=_NextPart_000_043B_01D23698.695F7C40-- From nobody Fri Nov 4 09:46:50 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C01031295B0; Fri, 4 Nov 2016 09:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, 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 DzuRx-1hmRQM; Fri, 4 Nov 2016 09:46:48 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id F18B1129469; Fri, 4 Nov 2016 09:46:47 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 01B001E377; Fri, 4 Nov 2016 12:49:23 -0400 (EDT) Date: Fri, 4 Nov 2016 12:49:23 -0400 From: Jeffrey Haas To: Susan Hares Message-ID: <20161104164923.GA30743@pfrc.org> References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com> <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com> <4080cfba032744f590fcbbb710f0d618@XCH-ALN-014.cisco.com> <08C97932-4E8B-4EBC-B780-3A2F54A1EEF2@apnic.net> <043a01d236b9$f07058f0$d1510ad0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <043a01d236b9$f07058f0$d1510ad0$@ndzh.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: 'IETF IDR WG' , rtg-dir@ietf.org Subject: Re: [Idr] Review of draft-ietf-large-community-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: Fri, 04 Nov 2016 16:46:49 -0000 Sue, On Fri, Nov 04, 2016 at 12:38:56PM -0400, Susan Hares wrote: > Should atomic-aggregate be deemed "historical" at this point? This can > happen in parallel to this work. I'd argue, yes. You might recall some of the reasoning as fallout to my introduction to IETF and the resultant churn in the 1771bis work as we tried to get the feature to make sense. :-) While I'm happy to write such a document at some point, it's something that's very low priority for the WG. In the meantime, I'll just keep pushing back on things that refer to it. -- Jeff From nobody Fri Nov 4 09:57:36 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72D171295D8; Fri, 4 Nov 2016 09:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5] 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 aRv3gw5lGZ7o; Fri, 4 Nov 2016 09:57:30 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 3E1051295DB; Fri, 4 Nov 2016 09:57:30 -0700 (PDT) Received: from pps.filterd (m0049459.ppops.net [127.0.0.1]) by m0049459.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id uA4GtDff024416; Fri, 4 Nov 2016 12:57:29 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049459.ppops.net-00191d01. with ESMTP id 26gwe9v76b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 04 Nov 2016 12:57:29 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id uA4GvSWr008831; Fri, 4 Nov 2016 12:57:29 -0400 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id uA4GvJUr008709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 4 Nov 2016 12:57:22 -0400 Received: from alpi153.aldc.att.com (alpi153.aldc.att.com [130.8.42.31]) by alpi132.aldc.att.com (RSA Interceptor); Fri, 4 Nov 2016 16:57:01 GMT Received: from aldc.att.com (localhost [127.0.0.1]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id uA4Gv1tb016889; Fri, 4 Nov 2016 12:57:01 -0400 Received: from oz.mt.att.com (oz.mt.att.com [135.16.165.23]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id uA4Guowi016116; Fri, 4 Nov 2016 12:56:50 -0400 Received: by oz.mt.att.com (Postfix, from userid 1000) id BE1D2A410BC; Fri, 4 Nov 2016 12:56:49 -0400 (EDT) X-Mailer: emacs 24.3.1 (via feedmail 11-beta-1 I); VM 8.2.0b under 24.3.1 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22556.48590.936986.153377@oz.mt.att.com> Date: Fri, 4 Nov 2016 12:56:46 -0400 From: Jay Borkenhagen To: Jeffrey Haas In-Reply-To: <20161104164923.GA30743@pfrc.org> References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com> <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com> <4080cfba032744f590fcbbb710f0d618@XCH-ALN-014.cisco.com> <08C97932-4E8B-4EBC-B780-3A2F54A1EEF2@apnic.net> <043a01d236b9$f07058f0$d1510ad0$@ndzh.com> <20161104164923.GA30743@pfrc.org> X-GPG-Fingerprint: DDDB 542E D988 94D0 82D3 D198 7DED 6648 2308 D3C0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-11-04_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1034 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1611040317 Archived-At: Cc: 'IETF IDR WG' , Susan Hares , rtg-dir@ietf.org Subject: Re: [Idr] Review of draft-ietf-large-community-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Jay Borkenhagen List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 16:57:31 -0000 Jeffrey Haas writes: > Sue, > > On Fri, Nov 04, 2016 at 12:38:56PM -0400, Susan Hares wrote: > > Should atomic-aggregate be deemed "historical" at this point? This can > > happen in parallel to this work. > > I'd argue, yes. > > You might recall some of the reasoning as fallout to my introduction to IETF > and the resultant churn in the 1771bis work as we tried to get the feature > to make sense. :-) > > While I'm happy to write such a document at some point, it's something > that's very low priority for the WG. In the meantime, I'll just keep > pushing back on things that refer to it. > > -- Jeff > I agree with making atomic-aggregate 'historical'. In the meantime, the -large- work should not attempt to maintain parallels with atomic-aggregate specifications for rfc1997 communities. Thanks. Jay B. From nobody Fri Nov 4 10:16:14 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D73141295EC for ; Fri, 4 Nov 2016 10:16:12 -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, 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] 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 HE9p3B9-m_li for ; Fri, 4 Nov 2016 10:16:11 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0093.outbound.protection.outlook.com [104.47.42.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 EE72A129505 for ; Fri, 4 Nov 2016 10:16:10 -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=mbaFO6bXC2Yqo+IyA+82XO0NCzR4DAuUWH87wVjAyDY=; b=YhlFaQQRqTjw0hkZyUz/vwJOoTRuKCQKcznUibQdQsDc4b6KTB5hRJl8Dt2F6Dc3atZVWS97kpNxQI0y9D0eGeho2tB7MLX/We+S7t3OUddr12vKZqwigX38aMQki5gFdy01TdA31qI7meBsLON0JtWWfdhpVaT57PG53//kjSk= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; Received: from [172.29.33.22] (66.129.241.11) 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.679.5; Fri, 4 Nov 2016 17:16:09 +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: <532A9822-2289-49DF-8983-32339EFB66B7@juniper.net> Date: Fri, 4 Nov 2016 13:16:03 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <00F837F1-ADE4-486D-8B0A-42C0D3EB11E7@juniper.net> References: <532A9822-2289-49DF-8983-32339EFB66B7@juniper.net> To: X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.11] X-ClientProxiedBy: BN3PR10CA0033.namprd10.prod.outlook.com (10.161.211.43) To CY1PR05MB2507.namprd05.prod.outlook.com (10.167.10.134) X-MS-Office365-Filtering-Correlation-Id: b57a51c1-b1c0-469c-810d-08d404d64570 X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 2:NRf2ny+HpbE09Qolv6gpOgUZfarTuDyzo6VP1AC5Ku980w2BNS1CSR4ViS6vzBA3gvfCycBSZ/JO3f32aVrihQhz9RISsujhTBtwnkJX5xS+256U7A45pEnhELlCkzRh2jKh49jyVCR0nXfVKTBZXUDrhe1tZvA1f1TUsCWn9jKZx7pkO9slxNP3lR28inkHwLGzMfIVnKnqA50FEyvyxw==; 3:EpWPqylB37dvg4BCOPsxvYmMO2rPE6ZW7Q5x2k62+61/22Aws//LAB0DDVUuu0IDJovF1YQuoXBYJ2oB8Xg3t3bqPjroIGD7o2Xk38yM/81MU81MDJxdjDAt2348RKkEzXQPZEWs/Wkcf13wrAigDA==; 25:5xCFp6IS5zXpnmrSwOZCKnrufV93X8Jl8+bEZlOAz+wgT3Ud6zIu75/79JSlBESEYPsXfYLfWQmdVeFrq80JNH+534B42FYk6+jZnbIW3jB74DQFzu1kiHj35fJuiLAwQMnh246LR4pk736PYgc2Yo4uXutBedSIhJ2Sw5Dwuz5ErBbjHZUIr6tOnzPxxXWC7tfFGfu/Dq00VTau/fOoj9tTze9VL+76WYgkobV79ADkwwCGEAHjbnZC2bBjTHIpQQ715+QtAJl3BTlcKuSDx3MC5hFFEu6nikNuT8uOIdX7BID8efrarSMJp2w9zOSNUz64SW8lQKEPWrIbl/lG59aybCpJ9spfrzKeKzzuhwCCMk8lWWaKXuinSUwYWPECYNqpR/jLQ8Lw+yg1UWDVSQ6eDMOENt4AqpVr/n2a32w7HEkKPcjplSjcKhJmR9AH X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR05MB2507; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 31:cya76WNW1aewj9+ZRD0bf4bO4mmGKt5GsB7LaR4FSsjnaB4LERiMBMt22x/twfi7Nzf94KoyESZnitJJWfiwDAcQU9iqOpN0E9IpPcTvGWs0y47VfqYy2A98xJc/AgHpeG1ikvM6ahRGZLHpnLJTytaLaYvtwhETQirVMNVX6EVD3uvkNjyd+r0Gvhr8gyDX1IIBNRKy+Ebz8tyj7NzdyQcxznz9JOb8MoBBFEd4pX/e7epaIvFbbf93RF7RfczuKPaqLzj0XcQaFUEDg36Z5w==; 20:tfKgIl+1szD+imbHzRjll2AIr0B6lhryGdYXC9Ns6aqNN4MC/+g7IIHCT0pXevjMyMZBmCT1QfO0cEkvknwnqhKaBClMSMgrNJ/RzJbmwr8ayAEH5tAA1DRFy8wIfHz3TDIPKF1DpaYAzU7D5ibyeVrsmbNa6nvDAsPP7liAMqfWLpE3Oqm/PyW4CqqFRxZQU2LliB21PZai6ky7TOxZAUJr/vdRDqTWWXCCaIdHzhXtWSCfhcPbNOR6chrYh9yeggO/26phDzD8e7q2hljwOqpIHjBNkpd4wIDzLCDx/PB0WbVhz4yGZT/jS1UnkkaLbGYj64KmT67lbtxY0pX6jaVcf3lmZ13N0tK63ls5aXcF7ufYPMoJmgabncn/31yfP0VA1+NOJ61NJoPQ1PHXJ+nNWejO6SFLaOdnmugwcVhUKUwcrifJxvmZ9qt2+7/UjyzpVvBsp03xnzoNUWmqlk31VxOlD7vSenHC/1hc7IdBtNgg3JLVmHdzWSu2PlBf4w8VFxHEulNw4EEfXi6DWCtq52DOpObVLquzfr61GsDeieUub+hlqrE+MMxtMspeZ1S2lxZZyo8KSuWngyg4Imzun0P2gnAoczUgkvUSJ0Q= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(138986009662008); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:CY1PR05MB2507; BCL:0; PCL:0; RULEID:; SRVR:CY1PR05MB2507; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 4:h8cqmniifN6C3NXfQKDxvRv1M9FBMAZ3m4iZUHdUYr9urrSeqquLaLqKZsXoVqblEsEb3ygB5spakU4Amo4oxUoEKiAqUmS1TtE/soq6rAx4ahHhm/5jBiQOcRyo3pewNoR8oB0N5veYf1ZlT2kx0SlHAf1GX8Tlhe43zEUk/jM/iw9I6KCC46/y2Dw1Z+NHhbfMzDGLW7JUMjwLHwAeOX7KQN7dsAsR2hcQ4a872ZnMYG7xwFrAPgbFG7l2LpISO66oHlqv6Mt1DgK5s2jNgW+tTCDEcu9XED2u4hs8sB5jYhfcXn/+cHm8Hq0DHrpAmRPo9aTmyf6OQ7MDSmnmVkzjQvy8dWGbAGxfTXuE8sm0ipwJCySZTPrVAjnnKwkOtt/F/QV48zIvh9UAjMF6oYzTiMio+iXQLRx9yzL+HORoHSfW9YY1qRhpQP7dlR95JbRo8eGffdVhlJ+XSjwM2g== X-Forefront-PRVS: 01165471DB X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(7916002)(53754006)(189002)(24454002)(199003)(377454003)(8676002)(19580395003)(305945005)(50986999)(5660300001)(50226002)(19580405001)(66066001)(42186005)(76176999)(97756001)(97736004)(110136003)(33656002)(81156014)(101416001)(47776003)(81166006)(8746002)(2950100002)(68736007)(6916009)(189998001)(83716003)(50466002)(2351001)(36756003)(3846002)(77096005)(82746002)(57306001)(586003)(46406003)(106356001)(23726003)(6666003)(105586002)(7736002)(92566002)(7846002)(450100001)(15975445007)(6116002)(107886002)(2906002)(86362001)(42262002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2507; H:[172.29.33.22]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR05MB2507; 23:8ZtZuWhSRiTrUUQr1Mxe22wAi2wdbjPPCAFt6s8Kj?= =?us-ascii?Q?tb8Z7R3RxMUsisZ7JhUDIOYTbMsQO2mOfPzMV1ggDknpwEzhU8WOK4xDGRxR?= =?us-ascii?Q?t1ECRNtLo17sHOPC0xh4yd93yVjRnUFOHhfcDD1Jg1xqPo257iQnqiDBmAog?= =?us-ascii?Q?33uAPFQyRCh00mWPqUib4z2S/lYc9+Rox3b30R6omvCLqLO1Bu93Q1jWhldp?= =?us-ascii?Q?TnPgNsup4dE8cFla1lSFnnyMv0mBcUjeHRa4ffk/K9VTLUWKe7NhvN1VQ+8z?= =?us-ascii?Q?9nQoKGzJRkIBV/KRTz4tVn3yVABOFcJtE4M6pqt4si62IRRCT1wmgFVqYM4U?= =?us-ascii?Q?7MWXhlJGaJs5Dyjaudjbsw0UmK3+HExHi7+i5cd18URHIBot13bzHZuxavhS?= =?us-ascii?Q?DybjqWSmWEBLxzpR3viE/LrbXn205VF/MPg/RMkiY08YlyzGBwKPK2USeDHU?= =?us-ascii?Q?0k6FjLexmOeGi9INm287EMNZX768n0zUCv0Q1h4d3x2Gdr97sWo/tlyAsPLq?= =?us-ascii?Q?1peiYIu7ejCIN6bQePVD6waN3HEt49lR24qenvcTkS9toFyBrZKmgUnghO4R?= =?us-ascii?Q?eqzvKaNzbQ31ddmvwW0QVFZxWRgyyo0BF7aBVJ3ZQy9vgWn3Aj/Nmg+/NMa2?= =?us-ascii?Q?ihFkGbnBbB71bf4NFZsGcUnvahj8DEfk0OpZik/Gs9rkO5S20dYpuCsYHHN9?= =?us-ascii?Q?2gbkG/VFtNJ1YbFJS/+3tSPwSr10QC9QqfH3p9pnjQwFTf7kP2T00bNWO69W?= =?us-ascii?Q?PRWrDixNcnC0fegOFUNZOR0AQAuySGh+HKipXOA9Cr2RVJCPhQLNnWf7hZk2?= =?us-ascii?Q?vpkA0TgHcsTwHgymVpu64oaYvRFOb/e9AE9+HBFCr8zSlSX36V+FFusA+Oov?= =?us-ascii?Q?hSaFn6Yr1vDu4lI7q/Tj+CfqAnLYvm9oLWXTobgQhd9PoLVEbiACEN+svWph?= =?us-ascii?Q?53vNpGC2BhlzafXb/0s2hYxyPSLQqcnLqdEIBNyBThE0cbBaGY0jbnRJqPom?= =?us-ascii?Q?wCtJYyDT1oTZp4D0vg9AqXuNkUcanJHBTzhgCSuXK1IUTzZp8mYc4ZfjpFUj?= =?us-ascii?Q?frW6YJ7Qh7ipagKpGcIuvBc1w+ZCf1gn/nTBO5Y2vAgeWT3k7IgastQc5PFA?= =?us-ascii?Q?UaxQhTE+m6j3Wlz2XsyLl4rh/Yqucx39Lm7Lmo3rXDWR353yVCRVX5qgKQJJ?= =?us-ascii?Q?l3iKxp7FIkzqKAZZEBMhQk0AjDB/30+D/Dco3gpvLYKsJzra1SnD+ei2haUx?= =?us-ascii?Q?OEYrPlRCTfF2Xho+dN25Jk8NVZ5pl4n3E4TllO1Td5un0M+cyQxtAGSR+Rzx?= =?us-ascii?Q?H1YcCyjwYsQ4yKD+hWk1lpNmmAVnDK/DK2T+H6mICuUy49lJsVJ6WyxqZ+LK?= =?us-ascii?Q?0Bxew=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 6:8GA5uNFpgsmevyJpvNJHcCAyFagteJeTpEYdRJT6ygR63LYkWwNu/ipMMrvP6VUVBKOx2qRXHD7zU45hUERxH3C8cWTgchVI2s1i2x8pgwGEz5OLFAR3NrkAKc0UVgWnqaZH/5j+IyTwUtS3BJ7o8DKjwuGgQwvofEYyQvHeCYk6vm8E2mi7FpHMTsD8urziwDurToBF6mLPTnmhyxZfiWgNVav3N12QrtoSurBxDCuc10h6VdsXIohetRBzdNT/rNqlbnlp05HJMHx/Zgx2deWI3CI9MNbgq7fslzsmB1N+Xpg3GaKpT/jOqZdFcA8tQ57y522J05/u575WrOtyMGbDD9v0C9YQ2a4h+oYGyKk=; 5:m6Bi6XMlq/7lB7cv7blo/YOcNscC8dpIFfeINeTxMzVNAzzuozAe38LY+/176x1H4p6ThprXgXUHGTIRXAojNkwXaAMQinkHWevreb4gm+mB0XC0DKG2v4zH9OHE78PR5PkPTpjMgoA/g2C31aSsyw==; 24:IGwSodQGDkujlJkUEkz+7DCMvQ8WMGKw5go9/DN2AZoiscgHygQr/iAKv4Ihpc1/5FKWQRAK1TBvVAYnZo8U7+MU6kskkmM8XxWwsqaeA0Q= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 7:VBa4B7cbQOAFYR0gzrs9RtYk8Zw4e6pGvhLVZFJtqcM//5d9d/5vAXegAFOy9firfTb3kknnmmSlquN6Lsy+NgXOoH0MhjuN731EmVVW+Vdc9OIMySQXgyzGvhLHtaKtsfEbghNJlyXjN6vkHLv6qrbRN7SRH/QfD+jEOy58cZzvxo93fC0BBCjsv6+abkySvyuM+zyfDyCFdOHwvKjU96d8AeJyXZbBdq8WzeMLzKmeMJtrODoQvuLmdy0nB9QqRArQ9XTVvY2MvuAWcl41uKr+6WsoZ6R/pAUywi8OumG+ik1x9Eq6m5gcHhpcK6nu2iAfcUOcrYOsLgg7n3tcw3hnnjVe5y1zouwvjUprDAo= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Nov 2016 17:16:09.7002 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2507 Archived-At: Subject: Re: [Idr] IETF-97 draft agenda posted 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, 04 Nov 2016 17:16:13 -0000 Updated agenda posted: https://www.ietf.org/proceedings/97/agenda/agenda-97-idr-01 All our time is now allocated. --John > On Nov 2, 2016, at 4:28 PM, John G. Scudder wrote: >=20 > Hi All, >=20 > The draft agenda is posted here = https://www.ietf.org/proceedings/97/agenda/agenda-97-idr-00 If you = requested agenda time and don't see yourself there, or if you need to = make a correction, please let the chairs know. >=20 > If you are a presenter, please read the checklist: = https://trac.tools.ietf.org/wg/idr/trac/wiki/Checklist%20for%20presenting%= 20at%20an%20IDR%20meeting -- especially the last section.=20 >=20 > Thanks, >=20 > --John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Fri Nov 4 10:18:50 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03865129505; Fri, 4 Nov 2016 10:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.432 X-Spam-Level: X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_SOFTFAIL=0.665] 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 f9LxivgBEwBu; Fri, 4 Nov 2016 10:18:43 -0700 (PDT) Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (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 A1B391295B2; Fri, 4 Nov 2016 10:18:43 -0700 (PDT) Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1c2i8T-0000Xb-DY (job@us.ntt.net); Fri, 04 Nov 2016 17:18:38 +0000 Date: Fri, 4 Nov 2016 18:18:34 +0100 From: Job Snijders To: Geoff Huston Message-ID: <20161104171834.GE961@Vurt.local> References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com> <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com> <288c77155de540adbdb60d8587b9f39b@XCH-ALN-014.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.1 (2016-10-04) Archived-At: Cc: IETF IDR WG , Susan Hares , "rtg-dir@ietf.org" Subject: Re: [Idr] Review of draft-ietf-large-community-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: Fri, 04 Nov 2016 17:18:45 -0000 On Fri, Nov 04, 2016 at 08:04:47PM +1100, Geoff Huston wrote: > >> 4. Canonical Representation > >> > >> I am confused here - this section used an example with TWO > >> canonical representations: > >> > >> "For example: 64496:4294967295:2, 64496:0:0, or (64496, 111, 222)." > >> Conventionally, it's better to use a single canonical > >> representation, so the authors should pick either a colon-delimited > >> list, or a bracketed comma+space separated object. > > > On 4 Nov. 2016, at 3:05 pm, Jakob Heitz (jheitz) wrote: > > > > To explain this one, it was originally "Textual Representation" and > > it was with colons only. Then we discovered that Bird uses commas as > > a separator. Since that does not degrade the utility, we allowed it. > > The real point is that it has to be exactly 3 positive decimal > > integers. If some implementations only offered hexadecimal or used 6 > > int16's then it would become very difficult for ISPs to communicate > > community settings to customers. I can change it to a single > > representation and detail the allowed deviations from it. > > if you make a canonical a SHOULD not a MUST then you can permit > variation without breaking the standard. > > So what you are saying is that the canonical representation of a > single Large Community value is three unsigned decimal integer values, > separated by a ‘:’ (colon) character, representing the value as a > triplet of unsigned 32-bit integer values. Implementations SHOULD > accept this representation as a valid form of representation of the > value of a Large Community. It appears the word "canonical" is maybe triggering something. The key element is that its three separate values. Nobody cares whether it is a colon, comma or a hypen. Does removing the word "canonical" address the raised remark? """ 4. Representation Large BGP Communities MUST be represented as three separate unsigned integers in decimal notation in the following order: Global Administrator, Local Data 1, Local Data 2. Numbers MUST NOT contain leading zeros; a zero value MUST be represented with a single zero. For example: 64496:4294967295:2, 64496:0:0, or (64496, 111, 222). """ Kind regards, Job From nobody Fri Nov 4 10:30:17 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95DC5129467; Fri, 4 Nov 2016 10:30:12 -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 hFIRrNbljGj4; Fri, 4 Nov 2016 10:30:11 -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 8FA481293F3; Fri, 4 Nov 2016 10:30:11 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.175.1; From: "Susan Hares" To: "'Jeffrey Haas'" References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com> <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com> <4080cfba032744f590fcbbb710f0d618@XCH-ALN-014.cisco.com> <08C97932-4E8B-4EBC-B780-3A2F54A1EEF2@apnic.net> <043a01d236b9$f07058f0$d1510ad0$@ndzh.com> <20161104164923.GA30743@pfrc.org> In-Reply-To: <20161104164923.GA30743@pfrc.org> Date: Fri, 4 Nov 2016 13:27:54 -0400 Message-ID: <076001d236c0$c790c4e0$56b24ea0$@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: AQH7vYX/r5lvDTiDOvRZn6NWFj+MugIVEsE7AusR2FECKfMMFwHKxisSAhTYCDcBtVkRzgJ+o7uXAuC5phyf5RLOAA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'IETF IDR WG' , rtg-dir@ietf.org Subject: Re: [Idr] Review of draft-ietf-large-community-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: Fri, 04 Nov 2016 17:30:13 -0000 Jeff: My understanding of the process - is that you do not need to have an RFC to deem something historical. You simply do a WG LC on historical and then pass it to the IESG. Sue -----Original Message----- From: Jeffrey Haas [mailto:jhaas@pfrc.org] Sent: Friday, November 4, 2016 12:49 PM To: Susan Hares Cc: 'Geoff Huston'; 'IETF IDR WG'; rtg-dir@ietf.org Subject: Re: [Idr] Review of draft-ietf-large-community-06.txt Sue, On Fri, Nov 04, 2016 at 12:38:56PM -0400, Susan Hares wrote: > Should atomic-aggregate be deemed "historical" at this point? This > can happen in parallel to this work. I'd argue, yes. You might recall some of the reasoning as fallout to my introduction to IETF and the resultant churn in the 1771bis work as we tried to get the feature to make sense. :-) While I'm happy to write such a document at some point, it's something that's very low priority for the WG. In the meantime, I'll just keep pushing back on things that refer to it. -- Jeff From nobody Fri Nov 4 11:03:49 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F0421294E1 for ; Fri, 4 Nov 2016 11:03:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.398 X-Spam-Level: X-Spam-Status: No, score=-108.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 RP_24qQqKGgc for ; Fri, 4 Nov 2016 11:03:46 -0700 (PDT) Received: from nx-mailgw.apnic.net (nx-mailgw.apnic.net [IPv6:2001:dd8:9:801::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABFE01294C5 for ; Fri, 4 Nov 2016 11:03:45 -0700 (PDT) Received: from nxmda2.org.apnic.net (unknown [2001:dd8:9:2::101:249]) by nx-mailgw.apnic.net (Halon) with ESMTPS id 036a44c9-a2b9-11e6-b23e-005056b685e3; Sat, 05 Nov 2016 04:03:39 +1000 (AEST) Received: from dhcp150.potaroo.net (203.119.101.249) by NXMDA2.org.apnic.net (203.119.107.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sat, 5 Nov 2016 04:03:23 +1000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Geoff Huston In-Reply-To: <50FBB9EC-F6C7-408E-A544-9D64E86E8293@pfrc.org> Date: Sat, 5 Nov 2016 05:03:40 +1100 Content-Transfer-Encoding: quoted-printable Message-ID: <8142B1B3-2911-47B5-8535-89C2D8EC9EBE@apnic.net> References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com> <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com> <20161104004725.GC17584@shrubbery.net> <20161104075614.GU961@Vurt.local> <8F8E9266-DAD3-48A7-BFFE-7CE8C103C529@apnic.net> <50FBB9EC-F6C7-408E-A544-9D64E86E8293@pfrc.org> To: Jeffrey Haas X-Mailer: Apple Mail (2.3251) Archived-At: Cc: heasley , IETF IDR WG , rtg-dir@ietf.org, Sue Hares Subject: Re: [Idr] Review of draft-ietf-large-community-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: Fri, 04 Nov 2016 18:03:48 -0000 > On 4 Nov. 2016, at 9:31 pm, Jeffrey Haas wrote: >=20 >=20 >> On Nov 4, 2016, at 5:10 AM, Geoff Huston wrote: >>=20 >>=20 >>> On 4 Nov. 2016, at 6:56 pm, Job Snijders wrote: >>> Given the above context, do you have a suggestion other then "pick = eiher >>> a colon-delimited or bracketed"? My personal preference would be to >>> keep the original text. >>>=20 >>=20 >> I think you make a clear SHOULD support for a particular = representation of the >> triplet, which makes other representations still ok, but there is a = clear preference >> for interoperability that says =E2=80=9Cclearly state a preferred = format for representating >> these values". >=20 > I believe the intent of saying it's an ordered tuple of Global Admin, = Local Admin 1, Local Admin 2 is sufficient. >=20 > If you want to define delimiters, go write a yang module. >=20 > -- Jeff >=20 For me thats a bit like saying that an IPv5 address is represented as a = sequence of decimal values representing 8-bit values. Its not enough to = be useful without the delimiter. I like the way we are now spending time on the one part of the draft = that is truly of least relevant. So if all this generates too much angst then drop the entire canonical = representation part from the draft and let coders do what they want. = Like extended communities, no doubt there will be some canonical format = emerge from this process in time. From nobody Fri Nov 4 11:07:53 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D212B129604 for ; Fri, 4 Nov 2016 11:07:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.398 X-Spam-Level: X-Spam-Status: No, score=-108.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 QHpaJL0jfq3T for ; Fri, 4 Nov 2016 11:07:48 -0700 (PDT) Received: from ao-mailgw.apnic.net (ao-mailgw.apnic.net [IPv6:2001:dd8:8:701::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D5841294E1 for ; Fri, 4 Nov 2016 11:07:48 -0700 (PDT) Received: from iamda3.org.apnic.net (unknown [2001:dd8:9:2::101:249]) by ao-mailgw.apnic.net (Halon) with ESMTPS id 9441502b-a2b9-11e6-b8ce-005056b6ee6f; Sat, 05 Nov 2016 04:07:42 +1000 (AEST) Received: from dhcp150.potaroo.net (203.119.101.249) by iamda3.org.apnic.net (203.119.111.31) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sat, 5 Nov 2016 04:07:44 +1000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Geoff Huston In-Reply-To: Date: Sat, 5 Nov 2016 05:07:42 +1100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com> <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com> <4080cfba032744f590fcbbb710f0d618@XCH-ALN-014.cisco.com> <08C97932-4E8B-4EBC-B780-3A2F54A1EEF2@apnic.net> To: Jeffrey Haas X-Mailer: Apple Mail (2.3251) Archived-At: Cc: IETF IDR WG , Sue Hares , "rtg-dir@ietf.org" Subject: Re: [Idr] Review of draft-ietf-large-community-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: Fri, 04 Nov 2016 18:07:51 -0000 > On 4 Nov. 2016, at 9:34 pm, Jeffrey Haas wrote: >=20 >=20 >> On Nov 4, 2016, at 4:59 AM, Geoff Huston wrote: >>=20 >> I just noted that RFC1997 and RFC4360 had these constraints. >>=20 >> It seems strange to me that an implementation would handle = aggregation differently, treating communities and extended communities = one way and large communities in a subtly different manner. >>=20 >> Frankly I would prefer to see a consistent treatment of communities = in the case of aggregation, and reproducxing the RFC4360 text kinda = makes that clear (at least to me) >>=20 >> Omitting it invites different handling and that would be not good >=20 > The relevant point from the thread is that the atomic-aggregate = attribute is largely protocol noise. It's a vestigial organ from the = BGP-3 to BGP-4 transition, and a poorly specified one at that. We = shouldn't include its use in specifications, particularly where = discussing aggregation. >=20 > The only place its discussion would be relevant is as part of = *de-*aggregation of a prefix. >=20 I have to disagree with this position. I am more than happy if you want = to push out a spec that updates RFC1997 and RFC4360 and drops the = atomic-aggregation conditions and applies the same considerations to = this document as well. But having current specs that say =E2=80=9Cdo = with communities and extended communities and do with = large communities=E2=80=9D is bonkers! We should be consistent here and = not just deliberately generate inconsistencies here - that is not doing = anyone a favour. From nobody Fri Nov 4 11:11:14 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0D6E1294E1 for ; Fri, 4 Nov 2016 11:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.398 X-Spam-Level: X-Spam-Status: No, score=-108.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 HVr_x2b3MNSa for ; Fri, 4 Nov 2016 11:11:09 -0700 (PDT) Received: from ia-mailgw.apnic.net (ia-mailgw.apnic.net [IPv6:2001:dd8:a:851::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DEF4129446 for ; Fri, 4 Nov 2016 11:11:09 -0700 (PDT) Received: from nxmda2.org.apnic.net (unknown [2001:dd8:9:2::101:249]) by ia-mailgw.apnic.net (Halon) with ESMTPS id 0e6e8c3a-a2ba-11e6-a41e-005056b6f213; Sat, 05 Nov 2016 04:11:07 +1000 (AEST) Received: from dhcp150.potaroo.net (203.119.101.249) by NXMDA2.org.apnic.net (203.119.107.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sat, 5 Nov 2016 04:10:48 +1000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Geoff Huston In-Reply-To: <98041685-2554-452C-B707-C1AF26BE1FA7@cisco.com> Date: Sat, 5 Nov 2016 05:11:05 +1100 Content-Transfer-Encoding: quoted-printable Message-ID: <9C984D2D-F468-4E77-B693-09EA7FE569C4@apnic.net> References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com> <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com> <4080cfba032744f590fcbbb710f0d618@XCH-ALN-014.cisco.com> <08C97932-4E8B-4EBC-B780-3A2F54A1EEF2@apnic.net> <98041685-2554-452C-B707-C1AF26BE1FA7@cisco.com> To: "Jakob Heitz (jheitz)" X-Mailer: Apple Mail (2.3251) Archived-At: Cc: IETF IDR WG , Sue Hares , "rtg-dir@ietf.org" Subject: Re: [Idr] Review of draft-ietf-large-community-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: Fri, 04 Nov 2016 18:11:11 -0000 > On 5 Nov. 2016, at 12:50 am, Jakob Heitz (jheitz) = wrote: >=20 > The text in RFCs 1997 and 4360 is not a constraint: >=20 > If a range of routes is to be aggregated and the resultant aggregates = attribute section does not carry the ATOMIC_AGGREGATE attribute, then = the resulting aggregate should have a COMMUNITIES path attribute which = contains all communities from all of the aggregated routes. >=20 > It does not describe how to aggregate if ATOMIC_AGGREGATE is present. = The text is more constrained if ATOMIC_AGGREGATE is left out of it. >=20 My suggestion was a cut and paste from RFC4360. My motivation to propose = this was along the grounds of consistent treatment of BGP communities = irrespective of the size of the community value. If you want to specify = a standard manner for BGP to treat ALL communities under aggregation and = deaggregation of routes then please do so. But trying to achieve this by = specifying inconsistent behaviours between the various community types = is not the way to achieve a good outcome here, imho. From nobody Fri Nov 4 11:14:04 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 128B11295ED; Fri, 4 Nov 2016 11:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.432 X-Spam-Level: X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_SOFTFAIL=0.665] 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 qkwndW1H_5sf; Fri, 4 Nov 2016 11:13:57 -0700 (PDT) Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (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 AD9B312961E; Fri, 4 Nov 2016 11:13:06 -0700 (PDT) Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1c2iz7-0006a9-Hy (job@us.ntt.net); Fri, 04 Nov 2016 18:13:02 +0000 Date: Fri, 4 Nov 2016 19:12:59 +0100 From: Job Snijders To: Geoff Huston Message-ID: <20161104181259.GH961@Vurt.local> References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com> <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com> <288c77155de540adbdb60d8587b9f39b@XCH-ALN-014.cisco.com> <20161104171834.GE961@Vurt.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161104171834.GE961@Vurt.local> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.1 (2016-10-04) Archived-At: Cc: IETF IDR WG , Susan Hares , "rtg-dir@ietf.org" Subject: Re: [Idr] Review of draft-ietf-large-community-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: Fri, 04 Nov 2016 18:13:58 -0000 If we consider this as Option B: On Fri, Nov 04, 2016 at 06:18:34PM +0100, Job Snijders wrote: > Does removing the word "canonical" address the raised remark? > > """ > 4. Representation > > Large BGP Communities MUST be represented as three separate unsigned > integers in decimal notation in the following order: Global > Administrator, Local Data 1, Local Data 2. Numbers MUST NOT contain > leading zeros; a zero value MUST be represented with a single zero. > For example: 64496:4294967295:2, 64496:0:0, or (64496, 111, 222). > """ Option C: 4. Canonical Representation Large BGP Communities SHOULD be represented as three separate unsigned integers in decimal notation, separated by a colon, in the following order: Global Administrator, Local Data 1, Local Data 2. Numbers MUST NOT contain leading zeros; a zero value MUST be represented with a single zero. For example: 64496:4294967295:2 or 64496:0:0. Option D: remove the section and let the market figure it out. Some might argue "this is a minute detail" - however I do think that the proliferation of ways to notate extended communities have not really helped the extended communities effort. this is a good chance and a good place to shortcut some of that proces and provide guidance. Option C is basically as watered down as possible. Settle on that and move on? Kind regards, Job From nobody Fri Nov 4 11:23:09 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE774129608 for ; Fri, 4 Nov 2016 11:23:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.398 X-Spam-Level: X-Spam-Status: No, score=-108.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 2tMC2B-JOO-A for ; Fri, 4 Nov 2016 11:23:04 -0700 (PDT) Received: from nx-mailgw.apnic.net (nx-mailgw.apnic.net [IPv6:2001:dd8:9:801::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F6481295ED for ; Fri, 4 Nov 2016 11:23:03 -0700 (PDT) Received: from iamda3.org.apnic.net (unknown [2001:dd8:9:2::101:249]) by nx-mailgw.apnic.net (Halon) with ESMTPS id b655b986-a2bb-11e6-b23e-005056b685e3; Sat, 05 Nov 2016 04:22:58 +1000 (AEST) Received: from dhcp150.potaroo.net (203.119.101.249) by iamda3.org.apnic.net (203.119.111.31) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sat, 5 Nov 2016 04:23:00 +1000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Geoff Huston In-Reply-To: <20161104171834.GE961@Vurt.local> Date: Sat, 5 Nov 2016 05:22:59 +1100 Content-Transfer-Encoding: quoted-printable Message-ID: <4EAB2E28-E839-4007-9155-EE4B5AAD0997@apnic.net> References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com> <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com> <288c77155de540adbdb60d8587b9f39b@XCH-ALN-014.cisco.com> <20161104171834.GE961@Vurt.local> To: Job Snijders X-Mailer: Apple Mail (2.3251) Archived-At: Cc: IETF IDR WG , Susan Hares , "rtg-dir@ietf.org" Subject: Re: [Idr] Review of draft-ietf-large-community-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: Fri, 04 Nov 2016 18:23:07 -0000 > On 5 Nov. 2016, at 4:18 am, Job Snijders wrote: >=20 > On Fri, Nov 04, 2016 at 08:04:47PM +1100, Geoff Huston wrote: >>>> 4. Canonical Representation >>>>=20 >>>> I am confused here - this section used an example with TWO >>>> canonical representations: >>>>=20 >>>> "For example: 64496:4294967295:2, 64496:0:0, or (64496, 111, = 222)." >>>> Conventionally, it's better to use a single canonical >>>> representation, so the authors should pick either a colon-delimited >>>> list, or a bracketed comma+space separated object. >>=20 >>> On 4 Nov. 2016, at 3:05 pm, Jakob Heitz (jheitz) = wrote: >>>=20 >>> To explain this one, it was originally "Textual Representation" and >>> it was with colons only. Then we discovered that Bird uses commas as >>> a separator. Since that does not degrade the utility, we allowed it. >>> The real point is that it has to be exactly 3 positive decimal >>> integers. If some implementations only offered hexadecimal or used 6 >>> int16's then it would become very difficult for ISPs to communicate >>> community settings to customers. I can change it to a single >>> representation and detail the allowed deviations from it. >>=20 >> if you make a canonical a SHOULD not a MUST then you can permit >> variation without breaking the standard. >>=20 >> So what you are saying is that the canonical representation of a >> single Large Community value is three unsigned decimal integer = values, >> separated by a =E2=80=98:=E2=80=99 (colon) character, representing = the value as a >> triplet of unsigned 32-bit integer values. Implementations SHOULD >> accept this representation as a valid form of representation of the >> value of a Large Community. >=20 > It appears the word "canonical" is maybe triggering something. The key > element is that its three separate values. Nobody cares whether it is = a > colon, comma or a hypen. >=20 > Does removing the word "canonical" address the raised remark? >=20 > """ > 4. Representation >=20 > Large BGP Communities MUST be represented as three separate unsigned > integers in decimal notation in the following order: Global > Administrator, Local Data 1, Local Data 2. Numbers MUST NOT contain > leading zeros; a zero value MUST be represented with a single zero. > For example: 64496:4294967295:2, 64496:0:0, or (64496, 111, 222). > =E2=80=9C=E2=80=9D >=20 change the MUST to a SHOULD and drop the example that contains two = different delimiters (as the text is fully functional and the example = provides no further information, but adds confusion). I suspect that the second sentence is overly normative (!!) If you simply said that: =E2=80=9CThe decimal notation does not use = leading zeros, and a zero value is represented as a single =E2=80=980=E2=80= =99.=E2=80=9D then I suspect that you are consistent with a SHOULD, and = adequately convey the minimal intent you are aiming at here =20 regards, Geoff From nobody Fri Nov 4 11:26:30 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A5E81295ED for ; Fri, 4 Nov 2016 11:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.398 X-Spam-Level: X-Spam-Status: No, score=-108.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 nblk2gZWWoE2 for ; Fri, 4 Nov 2016 11:26:25 -0700 (PDT) Received: from ao-mailgw.apnic.net (ao-mailgw.apnic.net [IPv6:2001:dd8:8:701::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 316C012960D for ; Fri, 4 Nov 2016 11:26:25 -0700 (PDT) Received: from iamda3.org.apnic.net (unknown [2001:dd8:9:2::101:249]) by ao-mailgw.apnic.net (Halon) with ESMTPS id 2e7b6063-a2bc-11e6-b8ce-005056b6ee6f; Sat, 05 Nov 2016 04:26:20 +1000 (AEST) Received: from dhcp150.potaroo.net (203.119.101.249) by iamda3.org.apnic.net (203.119.111.31) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sat, 5 Nov 2016 04:26:21 +1000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Geoff Huston In-Reply-To: <076001d236c0$c790c4e0$56b24ea0$@ndzh.com> Date: Sat, 5 Nov 2016 05:26:20 +1100 Content-Transfer-Encoding: quoted-printable Message-ID: <56935F2E-B81D-4EAB-9737-FC76AD47579A@apnic.net> References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com> <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com> <4080cfba032744f590fcbbb710f0d618@XCH-ALN-014.cisco.com> <08C97932-4E8B-4EBC-B780-3A2F54A1EEF2@apnic.net> <043a01d236b9$f07058f0$d1510ad0$@ndzh.com> <20161104164923.GA30743@pfrc.org> <076001d236c0$c790c4e0$56b24ea0$@ndzh.com> To: Jeffrey Haas X-Mailer: Apple Mail (2.3251) Archived-At: Cc: IETF IDR WG , Susan Hares , rtg-dir@ietf.org Subject: Re: [Idr] Review of draft-ietf-large-community-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: Fri, 04 Nov 2016 18:26:27 -0000 Jeff,=20 I, for one, would encourage you do write this and get atomic-aggregate = declared historic. It would result in an update to RFC1997 and RFC4360 = and thereby make them consistent with the current text in the Large = Communities draft. Geoff > On 5 Nov. 2016, at 4:27 am, Susan Hares wrote: >=20 > Jeff:=20 >=20 > My understanding of the process - is that you do not need to have an = RFC to > deem something historical. You simply do a WG LC on historical and = then > pass it to the IESG. =20 >=20 > Sue=20 >=20 > -----Original Message----- > From: Jeffrey Haas [mailto:jhaas@pfrc.org]=20 > Sent: Friday, November 4, 2016 12:49 PM > To: Susan Hares > Cc: 'Geoff Huston'; 'IETF IDR WG'; rtg-dir@ietf.org > Subject: Re: [Idr] Review of draft-ietf-large-community-06.txt >=20 > Sue, >=20 > On Fri, Nov 04, 2016 at 12:38:56PM -0400, Susan Hares wrote: >> Should atomic-aggregate be deemed "historical" at this point? This=20= >> can happen in parallel to this work. >=20 > I'd argue, yes. >=20 > You might recall some of the reasoning as fallout to my introduction = to IETF > and the resultant churn in the 1771bis work as we tried to get the = feature > to make sense. :-) >=20 > While I'm happy to write such a document at some point, it's something > that's very low priority for the WG. In the meantime, I'll just keep > pushing back on things that refer to it. >=20 > -- Jeff >=20 From nobody Fri Nov 4 11:27:53 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0B161295D8; Fri, 4 Nov 2016 11:27:52 -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 dxqZEK5GRpla; Fri, 4 Nov 2016 11:27:51 -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 C5793129562; Fri, 4 Nov 2016 11:27:50 -0700 (PDT) X-Envelope-To: idr@ietf.org Received: from cupcake.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 uA4IRmOn090689 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Nov 2016 18:27:48 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 cupcake.local Message-ID: <581CD329.1040603@foobar.org> Date: Fri, 04 Nov 2016 18:27:53 +0000 From: Nick Hilliard User-Agent: Postbox 5.0.5 (Macintosh/20161020) MIME-Version: 1.0 To: "John G. Scudder" References: <5EEFB890-8371-4DA3-8587-D62EA9C87B8B@juniper.net> In-Reply-To: <5EEFB890-8371-4DA3-8587-D62EA9C87B8B@juniper.net> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: Cc: idr@ietf.org, draft-ietf-idr-large-community@ietf.org Subject: Re: [Idr] IPR declaration needed for advancing large-community 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, 04 Nov 2016 18:27:52 -0000 John G. Scudder wrote: > So: Each author listed on the front page, please confirm this for me > by replying to this email. Please leave the working group in the > cc. I have no IPR relating to this document. Nick From nobody Fri Nov 4 11:32:06 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF0221295EF; Fri, 4 Nov 2016 11:32:04 -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 mvpEUJjWImZo; Fri, 4 Nov 2016 11:32:03 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0127.outbound.protection.outlook.com [104.47.33.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 108AC12962B; Fri, 4 Nov 2016 11:32:02 -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=0+UbjEReuViFfiYDt+EL9dNq2YDlv5oRmHy9kUfY5NQ=; b=heMUBpSsIiRMQhqXskYj8S3fuWIRnNCn91fS22iXJYqBadRaLRio2O6u5v0IwR1g8VuoSRJUOjMTYldd4Q2kHLCSYXfcllk0bz7pdSqc9y9QqtQMLQDYdBy28htgrPeiyD/FsGucWqsuYW/zN1ZBUJrLLjs7zuEq1V9HtbcAGnY= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; Received: from [172.29.33.22] (66.129.241.11) by SN2PR05MB2509.namprd05.prod.outlook.com (10.166.213.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.679.5; Fri, 4 Nov 2016 18:32:00 +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: <4EAB2E28-E839-4007-9155-EE4B5AAD0997@apnic.net> Date: Fri, 4 Nov 2016 14:31:53 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <947C1BD7-5FC0-4737-8DA8-F831C78D7B9F@juniper.net> References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com> <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com> <288c77155de540adbdb60d8587b9f39b@XCH-ALN-014.cisco.com> <20161104171834.GE961@Vurt.local> <4EAB2E28-E839-4007-9155-EE4B5AAD0997@apnic.net> To: Geoff Huston X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.11] X-ClientProxiedBy: CY1PR0801CA0033.namprd08.prod.outlook.com (10.163.136.171) To SN2PR05MB2509.namprd05.prod.outlook.com (10.166.213.18) X-MS-Office365-Filtering-Correlation-Id: 2f251d1f-a4de-48d1-c8cb-08d404e0de5e X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2509; 2:MB4mfaluRwZyTtoieUoxNdgRygEVWxaPMweh20EJtnhm9nu/CYRyVLTAjphbQVD22CmwDrCF6EgAoDhnKdsHZ6eUiCNvwnBokOvaWClZY333Qtg5LQ/K7sZNzNOOK8QWBHGIGBelQUVIgg+ndK907BH/X6AL0jQ2oopC8+IgLOeWTwWpfriEJB8HVOoJTWiQCGo0292CBPsCjD2dPLRKXQ==; 3:AJkCP4Ohrh0vQSzkHwdFdhCFtvhYO9lxSeHAUPqj6AxKUFKPTWambeSiBQCZFNRsgB0j5yZi1mQ1MFACk7uZeviJmNsKKjiOSoqEEXln5AXU4i4UNJ7Ir0bL45Sdhb59lqnOKZcg2RL00ZZRKZKVyw== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN2PR05MB2509; X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2509; 25:QfvMTKCZW3S9/8WdnVCCwAtYc3qhB+Q6nh1tGnjDztl6j/l96daAwnqb1TTUCACcg6USek3xDSIRiLvXNmCp2vgfTKlAj06iFIl29ROiNCrOewao4PsxwkErb8CYe9O6cEE0aKXdlPt0Foc/SfBYI+btpDX26sPBaHFwAtXG9QXmEAp5D70DJA9KLPlvrXp2DvawUdiY/zYheqbVnj0ntJ0grwIR+M4fR3LeB5FPfQEMjmE2BZedvU+1qe6hlckg+++8QU57UxaqhOHV/z68r1k6wXKsGJ2OGiD8KFKzQ/HWWXO+/LMeoKgHWOzGBdUkwlStihQVRS8t2kDntjzBXRSRO6o6INTxnhY5FD4lATggJmv7q/4h+/SW8PaZQxryH/vN6HQ22NpDIXmV+Mt/jIRifX419JUtHmfgxiGumUbjMzbr8uQxD97FMv8kZ5Q7dfxfSn2Xhhyq97eL7nDM6WpYiHxaLPurUr80QYR/Jz1yCxv/KiBeKntHfvzyDj1/cTeasS2VRQpbi7OhDtj71feQEZ7OrSDxDYdibqfZu8NFkbigqklAZyr8HbQrYQ5UPHe8mJg+n5spaQ0EfYju5QLasAh0uAfxui0PTatOebVK87pImXVxh8eMGISPdjr95nPQXvoxjsGRw3hrxWPqwV9WR3h2dfxc9lM69oU/waL0qx2dj7P5TsAq+BLFHW8f1z8LRf4gvCbNhqqWuBBkgA== X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2509; 31:R3XcXQReQZBjuPwh/6C3MOOq2NfB/z0U4rXkmv8HszotlN17n/9skYWmNHWMb8w7r67j+J8ZSYu9KlBFwGWM4Tx3QwpP1aNLTI7pdKleUW6aR+T5rkGqixgZDA8RlmPZlHn9U9Jtda1xn9/XmGYBuJ36eaTye6QvOu21FUsk3ut7WtnzK1mquJPZbKfw2gNE8UymFC5TM3P3JYibGNggRWTPQ/Q5EF1hNs1NOY+OjSVbNpRaxm/UvxH2PavvEQet; 20:POlYoBziQjSXmrKe9CJaYzozjyU3v4cGhL0/ivoO6ccr8bV8qcMhHkCFazO3Y73MuoNEnxznQnFR5OsI8wqdeTlJcvBxZi5jZyRvtrh3OLMBh0Mx8MSM7PFO0ICdLBlhKZMurs9/wm1dEPx0n9FVErebet0F3rfyCxz/PzZY98scm7JfkZ0EIuLYtNV+RLxNrUIzo/10FW2YN8u5OjpfWdTR/RBP/B0YQvQC3XtG3yiQryYBEPvJVueZ6AV9MtsMQhxDMHhbLLd2Ds1JVvdMZReivSAkxPmK4lqB5pYbAAIISfnvT+8odaiSQUgXfI9VjCS5DodKgAAzmXpM+prV3NdxyF+rkYbY8S5IrzEvEvoprj//vQAoEi94mLXwprFQegvTtcBySgvqadHggTnLlE5u9EpAAS8e/i2HOanlYC5P9AiE6eyeUfIAfgrtNK0I8nwQ4f4ajPJL8bK9VAr7CVzHNN09RsDqMm1ueaPU3GZKCCUHUr5SufqlFDFoYrGtp0Z2LH4tb0Z/9G5U0NkA00Lwb/lFEDMLclyKiYQcbwxvDVoxL1PR2akWvWy6ClkdxCUjEGcupztWrJe2ILLl2PNIqZ2PeuEHwBJOFU6wJjA= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(100405760836317); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:SN2PR05MB2509; BCL:0; PCL:0; RULEID:; SRVR:SN2PR05MB2509; X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2509; 4:7gQYS5nRnGakuI2TC+oNBvvhtFAMMCxgeR4evV2ejTBwiR9RJZW15rYaiLLO3VhUZapfblPgamLnzrHkveJtoxRmaMjTy+71NXmS3OmkL9RPkDl2xQsWbsERiHj+rZGj/WjnVQpaP8ImTZcD3sgw83yzOKbmCdpsQZxsHsDkRYXMeDICG4TuWZncZ9n27STVXleiTnr239P5WYG4huYcs8u08PH9tSY+Yi+xPOEYqQ0DDfmC5mnqK5I/mKIyABJOmt5D8JHpOk8V0KeHePGbIqLxCEnTwEt5OdH+z+tucR/EPx/spgTFdZ+pCdAbYM6HugJs1KN+uvEEAZS+yLpoWjMzHV7DebwD4nsDgwGEbn+XfRcvET8PSfuAVqXQt3X6cAEeZdNElpJBzUoyi6Ail5I4JE2GXuoimJzUSsmhhXIaZAJx1eSl+RUF4THqZ/MoxrUIFyaS6qrUBS5EqwYVEQ== X-Forefront-PRVS: 01165471DB X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(7916002)(199003)(189002)(92566002)(66066001)(189998001)(8746002)(77096005)(82746002)(47776003)(6666003)(97736004)(36756003)(57306001)(83716003)(50226002)(586003)(230783001)(50466002)(42186005)(5660300001)(86362001)(105586002)(7736002)(7846002)(46406003)(4326007)(305945005)(68736007)(2906002)(97756001)(23726003)(110136003)(2950100002)(101416001)(106356001)(6916009)(3846002)(33656002)(6116002)(93886004)(81156014)(50986999)(76176999)(81166006)(8676002)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR05MB2509; H:[172.29.33.22]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN2PR05MB2509; 23:UcJMjXP7nFcB6mKzCIxfWwJjzCWvkjTFlK9ss88Cw?= =?us-ascii?Q?2jAeSr+qjsp9RqGsuEjirKIkZfiQni4FUXq7bFTaeB1z90aq0dOd/q7s21rb?= =?us-ascii?Q?oyvnSVkAPC7sj661UQ6jEDbn4sgmQoB3Ohn1JIlA08zjfw0io9jv5tvMWihc?= =?us-ascii?Q?IlEx8WecEOQOqozFpgyVRUsOwTMvyLAqOSkbOADOXNmvUds1pdvg1ZhqMc/v?= =?us-ascii?Q?B2NRXegtnKr6DCPb/gg0Ju1NnFoDL62HacYbp4ikkjLPz6rHrWG7COEFbPsD?= =?us-ascii?Q?DEQu0JEx7BSd4Um3kQvRqt2kqNy5mEgyCbArQerJBM922zmzcDjCz9OAQKcf?= =?us-ascii?Q?2DfjFYLdqX9wW8tJjeEJSFeZ2bbN2ieaPj4fdMTxVCFtTXWgHZYX+HB63pqJ?= =?us-ascii?Q?32t9EqO68WfcvgAxtGtFKhLhj93Nwozd5KU7UoTjcfydT2UZM/B59ihIjkaT?= =?us-ascii?Q?/0cxWPjeTHsjs/OvhG3sFnjnCfoaissZ24+x3RF1HVLNbbZwC8S75wK8OJtR?= =?us-ascii?Q?fYjeazQULfPVU1caDBmXt2eJs/MRyqLz6Cvmaw4bVu3PdkIFY2kuuhPy43fx?= =?us-ascii?Q?TNvS1MHwBFxAqebuNiu/j8/GvXKT+mPvj1XsHiyHK+ltcsVmkpsy72rezWDH?= =?us-ascii?Q?oI5MfwYawfZQCIurtFtqcoO4UhRddgrUn9F4JUVy1Jr13Em0tPdGITg+hIKB?= =?us-ascii?Q?SoXVtn+GiuBfEK2KrLaV3DwI6bwLleKe+sr89DkPl+HyzO35ISnnA+pIxWI3?= =?us-ascii?Q?uDiBrHznWqUEO30FFnYFGlrHsUPr8eLDQVfNzMWUkGPgbKRPS4QK64nXilaR?= =?us-ascii?Q?jVLfdFQx3xgbjHLQqlqPHT/IdELH7v2BEw12fR8p3y1rwy+KrhX5fgxHq32F?= =?us-ascii?Q?fjxbw8sdbQ3dWGAtT3JSrODJ0r2xg7cpSflHtSeWJ8tIast57kdvl2GMKVxu?= =?us-ascii?Q?82YnQTqw8XThsjjs34fI2Q8gjlaEmRVGbbEietFGSTy1wCBDaX6otgaahr8a?= =?us-ascii?Q?kDgHfJHDPZImIAqQvmTnjJmsy1OvcrPSWMVQ0Ak7DYc7hv+tIbKYPbrUpN87?= =?us-ascii?Q?QeybPjJE0k0z6lzWm6K9IOscIITS8UYxAxqZV1eRqkTlBf49NloQ7SFcczXJ?= =?us-ascii?Q?AgR/uAp+B3+PsD+/+TTKyJzCGKARneHSXTQpDiL5RUpRPtny+22IzytZBeo4?= =?us-ascii?Q?4gZNtpeWSBGvfZNdVP3srN2tLcPADTJvv9e?= X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2509; 6:jSn+jFpgZLElHN2xwEA+QvnAj3mNx5ITvdviz67YNPUttr0pN8ygrBBZwroGMPKBF8lhY5SxkQ8X2OTBC5s3csh0YquHdggxP6QdbG8t/k7UK7v7AdYe/yFAGmu9cTOqNbh9f4cEt1tjLg1K499voabyLh9sTsJ2EkHhuFBRjLRDBFbcVuih81R8A0hpsE2Ug9jcnW4eD6/QPSTWxOS1ACJv7iyElKIWWqHvGUECZwL6N4wf0oEEXT+B99kpBHlhbVODCQOigL0G3XjB6OEEQCcFGVCZl6W5w3MIyTXrHgIFky5Rzuzc6SxkRldUxwJJRybrqDVhnpa54Oh60JnXgfakgrZqR9x+2xtfqug1Bso=; 5:nniZM/kqPqyvIXVYkQuuiPU/VfJww2mL6sjOCSzBfGebYuq9peb3Dy85e+ObZuRjTPf8EFsqF7Pnj076bZpOBefwExNEij0ccDcqlZNKlfK/ZX0TI49x50cLOQgjukgO6O2faVfv4zSgQwOPYD+BxihUPhVGLe5Ek9m50nQGjYw=; 24:tRmDqQgPhZQYsvAjJrr9gTfAY/N/GXLPYR4bf96pC8ADPwWaTQQ/uikE2q/2hZyMth4jk/GehaNFQdi19INc5wdujRKSuh4A1pOi6h8RvnA= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2509; 7:PSU3zcB+As9/sNPhWD/hcZmklEakScgJfhKYb7shwHTshX4ON6NWUVt9+36TUzZiwdlMIpMQpgzMHf+7V1D/PH/HyNjJixOspQlmdnBy5Y1Xu/a4fOMTF5SG8Kw3JlY962hefjgLw5XzbZ6ySj/lzwT2W2teIvUzzkWdDthkJIMHyDRO9FmhQ7XGxPLrTFPcyNNI5JHd7qyjcbjKJBVK/LEq5XVeXw2LUDZFH9EqJcKN1sbx/h05tMl1TY6eXz3ElKfS4cnfbuYobba8y7caJxuO8Sq5XCYhcq9J6UBxVQunlJa5X/9rsO3FFvC7T5W73GS4HcqkDtGRE1NbvQiddLCfiUAGpr/+5dgSwONiJ0s= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Nov 2016 18:32:00.4902 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR05MB2509 Archived-At: Cc: IETF IDR WG , "rtg-dir@ietf.org" , Susan Hares Subject: Re: [Idr] [RTG-DIR] Review of draft-ietf-large-community-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: Fri, 04 Nov 2016 18:32:05 -0000 Geoff and Job, I note that the WG already discussed this topic in some detail while the = document was being developed and the text as it stands represents a = consensus reached with knowledge of the tradeoffs. Certainly, if you can = improve the readability, that's great. Or if you've identified some = fundamental flaw, then we have to fix it. But short of that, I would = caution against making changes that go much past the editorial. (It does seem as though you are spiraling in to agreeing on some helpful = editorial changes that stop short of going against the previous = consensus, which is a relief to me.) Thanks! --John= From nobody Fri Nov 4 12:41:44 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E77B2129570 for ; Fri, 4 Nov 2016 12:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.398 X-Spam-Level: X-Spam-Status: No, score=-108.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 yNjsJzewS9TE for ; Fri, 4 Nov 2016 12:41:40 -0700 (PDT) Received: from ia-mailgw.apnic.net (ia-mailgw.apnic.net [IPv6:2001:dd8:a:851::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F0981293DB for ; Fri, 4 Nov 2016 12:41:38 -0700 (PDT) Received: from nxmda2.org.apnic.net (unknown [2001:dd8:9:2::101:249]) by ia-mailgw.apnic.net (Halon) with ESMTPS id b252a061-a2c6-11e6-a41e-005056b6f213; Sat, 05 Nov 2016 05:41:36 +1000 (AEST) Received: from dhcp150.potaroo.net (203.119.101.249) by NXMDA2.org.apnic.net (203.119.107.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sat, 5 Nov 2016 05:41:15 +1000 From: Geoff Huston Message-ID: <95F42982-7DCF-46A9-A26C-71EF70DB3C59@apnic.net> Content-Type: multipart/mixed; boundary="Apple-Mail=_6F6C9D5D-E354-4EB4-A767-DF1ADDA4C0E2" MIME-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Date: Sat, 5 Nov 2016 06:41:32 +1100 In-Reply-To: <40D942F5-0710-46D1-BF09-76C827377479@cisco.com> To: "Jakob Heitz (jheitz)" References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com> <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com> <6c5d83aa1d6a4a04b651b8f14f4b445b@XCH-ALN-014.cisco.com> <40D942F5-0710-46D1-BF09-76C827377479@cisco.com> X-Mailer: Apple Mail (2.3251) Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] Review of draft-ietf-large-community-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: Fri, 04 Nov 2016 19:41:43 -0000 --Apple-Mail=_6F6C9D5D-E354-4EB4-A767-DF1ADDA4C0E2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Jakob, Many thanks for sending this. I have used Word to mark up my reactions to this proposed revisions for = your further review as this tool has a good track changes option - the = PDF of the marked up text is attached to this note. My suggested changes to your proposed test are: 1) change to the Introduction to alter the description of Communities to = conform more exactly to the language used in RFC 1997 2) change to the considerations of RFC4360 in the Introduction. (I also = note that RFC4360 calls the Global Administrator and Local Administrator = parts of the community value =E2=80=9Csub-fileds=E2=80=9D rather than = =E2=80=9Cfields=E2=80=9D, while this draft calls these elements just = =E2=80=9Cfields=E2=80=9D ) 3) the set of values is explicitly called out to be =E2=80=9Cunordered=E2=80= =9D in the Introduction 4) The description of the attribute fields is altered to be consistent = with RFC4360 5) the treatment of the Global Administrator value is unclear. I have = proposed removing the last two sentences and propose changing the MUST = to a SHOULD, as, later in the draft in Section 6, it is noted that the = Global Administrator field can be any value! 6) I have explicitly called out that the values are in any order, and = allowed for two or more individual Large Communities attributes to be = contained in a single BGP Update message, again in any order. If this is = not your intent then you should look at this part of section 2 and = tighten up the wording. 7) you have not explicitly disambiguated between duplicate instances of = the same attribute and duplicate instances of the same Community value. = I have offerred some text to clarify this to the level of values. 8) I have proposed changing the MUST to a SHOULD in rthe canonical = representation section 9) The sentences about the use of a colon make no sense given that you = have not specified a colon separator in the preceeding paragraph. You = probably need to either drop the reference to the colon, or add a colon = as part of the Canonical Representation. I have proposed the former. 10) - in section 6 I changed the =E2=80=9Cmay=E2=80=9D to a =E2=80=9CMAY=E2= =80=9D - seemed like the right thing to do. 11) I added a paragraph in the Security Considerations section = explicitly that the values in this attribute are not specifically = protected and then pointed to BGP security (just because an ASN is used = in a community attribute, that does not mean that the ASN in question = attached that attribute, or that the ASN will honour that attribute. - = its just a signal without any integrity protection) 12) I have added my name as a reviewer - hope that=E2=80=99s ok! :-) I _assume_ that the atomic aggregator mess will be fixed up by the = action of making this an historic attribute, so I have left the text on = aggregation unaltered. Regards, Geoff --Apple-Mail=_6F6C9D5D-E354-4EB4-A767-DF1ADDA4C0E2 Content-Disposition: inline; filename="draft-ietf-idr-large-community-07.pdf" Content-Type: application/pdf; x-unix-mode=0644; name="draft-ietf-idr-large-community-07.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjMKJcTl8uXrp/Og0MTGCjQgMCBvYmoKPDwgL0xlbmd0aCA1IDAgUiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PgpzdHJlYW0KeAHNXcty2zgW3esrUFmlqzIwQfDZO8dxT3smdl5KzUx194KW aJsdiVRIKp30188BRVACLIkCbUqMF6YdlXVwce77AvpKPpCvJKTcdXj9zQqJ63vU9XwS2JyygDGS x+Q/JCVnFwUjk4JYNHRCi4Xe+mm0/l0xITz0qM1YSGzHoZbNHcICTjn3PeKGDg1dLxB/827z3W3u U9cPPOLYFnV44DQvHelvTyx84W2+4v2ZJ2CIr9Ujx5/3eEj8gNEwdDwymZPXY4LliRetvo3Gc3I2 HjPCyPiOvCQ/kfGf5HIMNBvS2I1nUxwjIY7qqw2Pz6nLtuMhNZ7R0/FU20OsUbt8PJfalmNvk4/E U8ln9CT51HggoWIy2rtfrkd9+wA8Yr9GnfdrE89+/jgBdRgPRiv+WNRilkfGE5VJiqTIy6s3H0nH f/+i5Nc4Kf9+RS6ntNcFui6U22LEV1eoaIi2LlMN6aaxPKQh50HNyJXER20ST8s4T+PSUIWNAPoW dQPXg01RESoS02zKPwwBGdkU36UWDKStA9pBUg3amzy6Kzux9CIpJtlxuFlLutY+RdKn4SajnvBj m9bgEG6m03hKijIql8XP5FMZpdMonxZknEeTL7v2AKbgU5r8OY3z4ojWgK9WOBiJi9jDMZT45fdF kseQ9HX0g/iviG0xX5Fyo5UjY0/f6jkQKdEQekn8GrqR61Bg7vihV9VzbMQDCNk6ob8ZjxvRHhZE GVlg3vgslRWKXdDMnKnPMrLATZTJHBpwrpiFR0GCDmzH7h76615ZwIQPDjjxVwszovC/KXkflfHs OExQJH96IlgekqjjEoH0GwjbAQ0c7hN/tTQjKpzn+WRZHIcIiuRPTgQv9GngH5EIvZoDyNYNkCvU qzLiwBUlr6P7aZb2SgPHo56LtHqb3NsCtOg4DFWhnZ6hQYgE0JaVkcOShkOd087X9UpT26E8BEvr lRnR9PLrMkmT772SVIYvEuC2ooseJRgC6hS+eAhZreCoVOiVBwzL4XYAIqzWZUSEc6RdyXxR9Gyw 1lxQZH96s+Db1PdtWRA8klnoOYbhnNqh5xCvXpwRIW6yL0lkqIbd0hoJbzB2wXMgt2fnQp+yZIEI wD2XeNuwt0UCO90W+GnWHDAjQBNfdQF9g5JxMpslqCj1CrKxWCrI01ssAAsDphaM+86+BVN69WFo g/lOaBOvXp2Rybq6ufzvcbigyv70XHDQPbSOxAUh4VG3fmFrFdEOEMsyYcfqFRnt/032LZ7fxjnh VfHTU7gwqvu8h3U2W5E2RTkNqcKFUxTr0f5F07nhgoLnJFE2t6jPmGweKHikfI7Z+vVslHp5g2dH pAdko80m+S4XqVBMjhLsppiRf0S/nNoBbOE2xG0+/fU/35O3UX4fk4tsPl+mSZnEvSb8NnjnB8J0 q3CVDT8JARmnoY3RjWoUYsd+68Ae73evO43CM6I3n3hbsLbt9DTvNUxn3Ib40Njpgu2u19Y0cxgN 7JBr0PYxrtfOdKOwW3axLTJL4vLOkGJGRQ+G8NUK7XCfrDRz/BRZ1f5z9yQO8wLqOi5Kl4cISzPH yTTvVVayl6liU3h1VFk12V0HWc2EE+hTWrYVYDrAguFX0J1MWjZgWP4jpu8w/BqzJrWz/NFNYqNm SHDfVJztiu6+j8LMbolpDukputg6pWe7PvUs0ehQ8OyQmIbM8ruJqpqnbIfmoQdjPTIT+8hlWrPY NKOtZku2vj3LpY4jg4qtcI45P+ii78Y4RvT2BjmazTq/LUpM4pi66E15te5fMz2mIdwqsWOmAW4A q+U2EtuK56g7GFiUO7CiJjsoqjFmBbrNzavIDg+9c1oWI5Lcti2foAt6ADjNMIwfkoJMs8lyHqcl mcbFJE9u44KUDzHZmp2QqCzxkmUZvyJR2muZSXb35cLqMsNuFpjPSRuletKsuD4iWk9jQVsCYM4C I2xrFnQBF38v47RIspSUmdh2Q74aIcXM/SqN0sSobKvG0l4dK0NrFmU5DPNvE11bSuBQQiolavSC LPLsWwJVIhGZx5OHKE2KuRBskdyn0eboEabNn7neJSfk5FIGozIezlYEQ1WZLuCyRfR1GZMkvcvy eVQK3fkrKR+SlBTxIsoxZEbSaB4Xi2gizGlGomSKV5M8W5ZJen8cw1kvbDAsQEXe8kK1GzIYw9kF 3DxKo/t43qe99EPqhKI063YBCK9eGah47bcJPH6xTMrodobzTVlOlkVccRc/LPM+iWkjAPZ8TELJ pRxATFPTb+SLuGVTZiPHk4CUwK6NmdmkjEty/ummoH0SgLuMMgvzehrIfQ7zKRFna7rQxEEofbtB o84KHi2LeQqeg9M9lwfU9kPZxNiRGWu1hI8xhqvyWIS/BWrx6f0SCt3ndjKEtQ56LUSDq4hPi3+e Ir7Dt9NGbwDnEWsdUPCcZDttRp0gVFTyUTSm7aZ5lL2Za7WKah1lH4JN28QxUqov8Q/yVyaO17y4 /vxp/OLV6ju5eVc9f7z88Pnq4+Ub8ftPv56/fds8rF7Rp3HmckzVXa3tANtsSksz21yfknVFpRAn frWUe7SVn/K4rHHKbQRtTYMt2Nq8Bjb23ee39RaLp/XmX7y7vr68ebPa/+vz/2H3cRqLvHj3fnz1 7ub87QsRQCLGLHrlQeNuVosbDA8shyJ2VKtnbcI2twcdidAFXFN2iXB6HBnCrUgncFa0V++DIJIF vkvcLogXeVzisGCEklFdKapymt8+/nIhztL/sY6Deji8tg7WauhDYaZTXSXQMFMxTJoPMLWYRt5J xmVOgPks3uDZEQdpyHDwEwdASXa3qmZcx/OsVx7KKpAG9vTCE/mWGOhY+RsFzymiIAfF+dBp8OzY zBOFQYeB05hWVcuujnAoHrch4LwobJ0GU9lTDZxpummkoIxZ1BOFYw3Qjk3VoK0OxVfJ++08KYUh Rjhwt5zNyCRblaHSSZ3Jo3yvaO9zz9XJM5hyIYMxxZ5NPe4Ps8LkdAFXFZNFab6yza8v3uPamCoq rB7DtcclH569nMxCiwYWRnck8sFss+tQhpt4thlpTWuO43EdFwdRUUfSkhT1JhYdmXGSYmRsmiTF 6QKuo32uEI42rmHaN2GB+5ZC3KLkEw3hyewzus24FsoNdUAG9hlNHwTzSPG/oMjfNFYr3RUtVSlW cpneJ2kc56IV0OOoNu6zWo3qSxEPRoMBjKMWrGjMULI5HCk3BzeOii/klyyHC/795dXl+Jfff0Ll /SZDI8h0eMMoB21mBjuhfohKkoGZOblHZ2pRkDmuJYlmRUamCQZPqkZ/HUkgpXv+G0l4fS5Wgh8M P8XwQTBUfnYB99gmIY2X9qjPYJH5PnVcFLyRVlUyPWCPTcNwM42Rk6MSkJERqsLwom6qzaAkImee LPNcDNBo8uxHZWShVsI/tTybBpUENJiwDNc0ur6vbO+jDsKporIO2FbUE/1bWO2Hslz8fHY2jVC4 EVd1xTkV4+k0y+/PcNrgrizOalaeVUlCX6fBmrKcuBQT0j6AjaYxuZF2N1UwZmOWXm7+vpjSFI5R GN7AsThO3nhq+XowZOwCTrN1RleTmqcIKsJ922nqO4y2c50iqICMU4RKRTcShG/RDANCYhwDU2PR 92S+nAvHUiTfyTxLy4eeez71hZtOvaqhKDEPXYqJaVVrhpImdAInGnoixr5VQq72OUAjG9iwtBPE mCwXcCvx9BVUYzHDABueQMzstshmVQPo9kedNMgWVuWRovTHURqTclGDISlO/oShJ1sGK1MwGJJ2 AVcm8xgR7lUpYo0kjRaoQi7yRAw1ok8p5sUa49/jPcc2h/JznDNHL6sS8AEbbmr8jdSqOT0rASmR ZduO19Ebsq48vouRLkzUGv0z2wCZWWtY93nOowRCqM7jlnFNW4YSCHUCh/FfFPKimbCRUI9JItTk IYb/rgorJSbARcv8hcjARcsGynSPK2AL+qJXcykvbpFrOkB7TAlgpD0yEuboaNqWO5jiPfcYrnVv 8BwWyZkPlhiFmU3xvhO443dYNZj7jIyphTaSW9Nh1QAdtqmVhcYoNDqqcXVNM8FU/8Y9zZvNtvVn UjzTRRLN+U4N+j5ZmuqrkSwbfcVBWNtp9EPBc4qJCI4P7AjxaSDbqkwSzzEPBSJEQX3zADxH+lgI 3C6Ig8vuYMw9ZgU8BHFaa3Tv/Gb9MROYrlfOSz27zq3zpC0g2+I5BMib/+qL3TftxeZ/r55/e4/p csL+6NXxY8Sv+vQMvlrUcIjAxIf4yFxesSN6EdYwOTayawz6ihvkQ8JxF+cuQNKQbDnt/H+tNZQn CmVuZHN0cmVhbQplbmRvYmoKNSAwIG9iagozMjI4CmVuZG9iagoyIDAgb2JqCjw8IC9UeXBlIC9Q YWdlIC9QYXJlbnQgMyAwIFIgL1Jlc291cmNlcyA2IDAgUiAvQ29udGVudHMgNCAwIFIgL01lZGlh Qm94IFswIDAgNTk1LjI3NTYgODQxLjg4OThdCi9Sb3RhdGUgMCAvVGh1bWIgOSAwIFIgPj4KZW5k b2JqCjYgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0Nz MSA3IDAgUiA+PiAvRm9udCA8PCAvVFQxIDggMCBSCj4+ID4+CmVuZG9iago5IDAgb2JqCjw8IC9M ZW5ndGggMTAgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMTgyIC9I ZWlnaHQgMjU2IC9Db2xvclNwYWNlCjcgMCBSIC9CaXRzUGVyQ29tcG9uZW50IDggL0ZpbHRlciAv RENURGVjb2RlID4+CnN0cmVhbQr/2P/gABBKRklGAAEBAABIAEgAAP/hAExFeGlmAABNTQAqAAAA CAABh2kABAAAAAEAAAAaAAAAAAADoAEAAwAAAAEAAQAAoAIABAAAAAEAAAC2oAMABAAAAAEAAAEA AAAAAP/tADhQaG90b3Nob3AgMy4wADhCSU0EBAAAAAAAADhCSU0EJQAAAAAAENQdjNmPALIE6YAJ mOz4Qn7/wAARCAEAALYDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL /8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2Jy ggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo 6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQD BAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRom JygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaX mJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6 /9sAQwACAgICAgIDAgIDBQMDAwUGBQUFBQYIBgYGBgYICggICAgICAoKCgoKCgoKDAwMDAwMDg4O Dg4PDw8PDw8PDw8P/9sAQwECAgIEBAQHBAQHEAsJCxAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ/90ABAAM/9oADAMBAAIRAxEAPwD+f+iiigAooooAKKKK ACiiigAooooAKKKKACiiigAr+1D9lj/k2L4Q/wDYn+H/AP03wV/FfX9qH7LH/JsXwh/7E/w//wCm +CgD3iiiigAooooAKKKKAP4rf2pP+Tmvi5/2N+v/APpwnrwmvdv2pP8Ak5r4uf8AY36//wCnCevC aAP/0P5/6KKKACiiigAooooAKKKKACiiigAooooAKKKKACv7UP2WP+TYvhD/ANif4f8A/TfBX8V9 f2ofssf8mxfCH/sT/D//AKb4KAPeKKKKACiiigAooooA/it/ak/5Oa+Ln/Y36/8A+nCevCa92/ak /wCTmvi5/wBjfr//AKcJ68JoA//R/n/ooooAKKKKACiiigAooooAKKKKACiiigAooooAK/tQ/ZY/ 5Ni+EP8A2J/h/wD9N8FfxX1/ah+yx/ybF8If+xP8P/8ApvgoA94ooooAKKKKACiiigD+K39qT/k5 r4uf9jfr/wD6cJ68Jr3b9qT/AJOa+Ln/AGN+v/8ApwnrwmgD/9L+f+iiigAooooAKKKKACiiigAo oooAKKKKACiiigAr+1D9lj/k2L4Q/wDYn+H/AP03wV/FfX9qH7LH/JsXwh/7E/w//wCm+CgD3iii igAooooAKKKKAP4rf2pP+Tmvi5/2N+v/APpwnrwmvdv2pP8Ak5r4uf8AY36//wCnCevCaAP/0/5/ 6KKKACiiigAooooAKKKKACiiigAooooAKKKKACv7UP2WP+TYvhD/ANif4f8A/TfBX8V9f2ofssf8 mxfCH/sT/D//AKb4KAPeKKKKACiiigAooooA/it/ak/5Oa+Ln/Y36/8A+nCevCa92/ak/wCTmvi5 /wBjfr//AKcJ68JoA//U/n/ooooAKKKKACiiigAooooAKKKKACiiigAooooAK/tQ/ZY/5Ni+EP8A 2J/h/wD9N8FfxX1/ah+yx/ybF8If+xP8P/8ApvgoA94ooooAKKKKACiiigD+K39qT/k5r4uf9jfr /wD6cJ68Jr3b9qT/AJOa+Ln/AGN+v/8ApwnrwmgD/9X+f+iiigAooooAKKKKACiiigAooooAKKKK ACiiigAr+1D9lj/k2L4Q/wDYn+H/AP03wV/FfX9qH7LH/JsXwh/7E/w//wCm+CgD3iiiigAooooA KKKKAP4rf2pP+Tmvi5/2N+v/APpwnrwmvdv2pP8Ak5r4uf8AY36//wCnCevCaAP/1v5/6KKKACii igAooooAKKKKACiiigAooooAKKKKACv7UP2WP+TYvhD/ANif4f8A/TfBX8V9f2ofssf8mxfCH/sT /D//AKb4KAPeKKKKACiiigAooooA/it/ak/5Oa+Ln/Y36/8A+nCevCa92/ak/wCTmvi5/wBjfr// AKcJ68JoA//X/n/ooooAKKKKACiiigAooooAKKKKACiiigAooooAK/tQ/ZY/5Ni+EP8A2J/h/wD9 N8FfxX1/ah+yx/ybF8If+xP8P/8ApvgoA94ooooAKKKKACiiigD+K39qT/k5r4uf9jfr/wD6cJ68 Jr3b9qT/AJOa+Ln/AGN+v/8ApwnrwmgD/9D+f+iiigAooooAKKKKACiiigAooooAKKKKACiiigAr +1D9lj/k2L4Q/wDYn+H/AP03wV/FfX9qH7LH/JsXwh/7E/w//wCm+CgD3iiiigAooooAKKKKAP4r f2pP+Tmvi5/2N+v/APpwnrwmvdv2pP8Ak5r4uf8AY36//wCnCevCaAP/0f5/6KKKACiiigAooooA KKKKACiiigAooooAKKKKACv7UP2WP+TYvhD/ANif4f8A/TfBX8V9f2ofssf8mxfCH/sT/D//AKb4 KAPeKKKKACiiigAooooA/it/ak/5Oa+Ln/Y36/8A+nCevCa92/ak/wCTmvi5/wBjfr//AKcJ68Jo A//S/n/ooooAKKKKACiiigAooooAKKKKACiiigAooooAK/pE+Bv/AAU7/ZZ8A/BP4feBfEN7qyar 4c8PaTpt2I9PZ0FxZ2kUMoVt3zLvU4Pcc1/N3RQB/Uv/AMPZ/wBkL/n+1n/wWv8A/F0f8PZ/2Qv+ f7Wf/Ba//wAXX8tFFAH9S/8Aw9n/AGQv+f7Wf/Ba/wD8XR/w9n/ZC/5/tZ/8Fr//ABdfy0UUAf1L /wDD2f8AZC/5/tZ/8Fr/APxdH/D2f9kL/n+1n/wWv/8AF1/LRRQB6j8cPFmkePfjT4/8c+H2dtL8 ReINV1K0Mi7HNvd3ck0RZf4W2sMjsa8uoooA/9P+f+iiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKAP/U/n/ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigD/1f5/6KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooA/9b+f+iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKAP/ZCmVuZHN0cmVhbQplbmRvYmoKMTAgMCBvYmoKMjY2OAplbmRvYmoKMTEgMCBvYmoK PDwgL0xlbmd0aCAxMiAwIFIgL04gMyAvQWx0ZXJuYXRlIC9EZXZpY2VSR0IgL0ZpbHRlciAvRmxh dGVEZWNvZGUgPj4Kc3RyZWFtCngBnZZ3VFPZFofPvTe90BIiICX0GnoJINI7SBUEUYlJgFAChoQm dkQFRhQRKVZkVMABR4ciY0UUC4OCYtcJ8hBQxsFRREXl3YxrCe+tNfPemv3HWd/Z57fX2Wfvfde6 AFD8ggTCdFgBgDShWBTu68FcEhPLxPcCGBABDlgBwOFmZgRH+EQC1Py9PZmZqEjGs/buLoBku9ss v1Amc9b/f5EiN0MkBgAKRdU2PH4mF+UClFOzxRky/wTK9JUpMoYxMhahCaKsIuPEr2z2p+Yru8mY lybkoRpZzhm8NJ6Mu1DemiXho4wEoVyYJeBno3wHZb1USZoA5fco09P4nEwAMBSZX8znJqFsiTJF FBnuifICAAiUxDm8cg6L+TlongB4pmfkigSJSWKmEdeYaeXoyGb68bNT+WIxK5TDTeGIeEzP9LQM jjAXgK9vlkUBJVltmWiR7a0c7e1Z1uZo+b/Z3x5+U/09yHr7VfEm7M+eQYyeWd9s7KwvvRYA9iRa mx2zvpVVALRtBkDl4axP7yAA8gUAtN6c8x6GbF6SxOIMJwuL7OxscwGfay4r6Df7n4Jvyr+GOfeZ y+77VjumFz+BI0kVM2VF5aanpktEzMwMDpfPZP33EP/jwDlpzcnDLJyfwBfxhehVUeiUCYSJaLuF PIFYkC5kCoR/1eF/GDYnBxl+nWsUaHVfAH2FOVC4SQfIbz0AQyMDJG4/egJ961sQMQrIvrxorZGv c48yev7n+h8LXIpu4UxBIlPm9gyPZHIloiwZo9+EbMECEpAHdKAKNIEuMAIsYA0cgDNwA94gAISA SBADlgMuSAJpQASyQT7YAApBMdgBdoNqcADUgXrQBE6CNnAGXARXwA1wCwyAR0AKhsFLMAHegWkI gvAQFaJBqpAWpA+ZQtYQG1oIeUNBUDgUA8VDiZAQkkD50CaoGCqDqqFDUD30I3Qaughdg/qgB9Ag NAb9AX2EEZgC02EN2AC2gNmwOxwIR8LL4ER4FZwHF8Db4Uq4Fj4Ot8IX4RvwACyFX8KTCEDICAPR RlgIG/FEQpBYJAERIWuRIqQCqUWakA6kG7mNSJFx5AMGh6FhmBgWxhnjh1mM4WJWYdZiSjDVmGOY VkwX5jZmEDOB+YKlYtWxplgnrD92CTYRm40txFZgj2BbsJexA9hh7DscDsfAGeIccH64GFwybjWu BLcP14y7gOvDDeEm8Xi8Kt4U74IPwXPwYnwhvgp/HH8e348fxr8nkAlaBGuCDyGWICRsJFQQGgjn CP2EEcI0UYGoT3QihhB5xFxiKbGO2EG8SRwmTpMUSYYkF1IkKZm0gVRJaiJdJj0mvSGTyTpkR3IY WUBeT64knyBfJQ+SP1CUKCYUT0ocRULZTjlKuUB5QHlDpVINqG7UWKqYup1aT71EfUp9L0eTM5fz l+PJrZOrkWuV65d7JU+U15d3l18unydfIX9K/qb8uAJRwUDBU4GjsFahRuG0wj2FSUWaopViiGKa Yolig+I1xVElvJKBkrcST6lA6bDSJaUhGkLTpXnSuLRNtDraZdowHUc3pPvTk+nF9B/ovfQJZSVl W+Uo5RzlGuWzylIGwjBg+DNSGaWMk4y7jI/zNOa5z+PP2zavaV7/vCmV+SpuKnyVIpVmlQGVj6pM VW/VFNWdqm2qT9QwaiZqYWrZavvVLquNz6fPd57PnV80/+T8h+qwuol6uPpq9cPqPeqTGpoavhoZ GlUalzTGNRmabprJmuWa5zTHtGhaC7UEWuVa57VeMJWZ7sxUZiWzizmhra7tpy3RPqTdqz2tY6iz WGejTrPOE12SLls3Qbdct1N3Qk9LL1gvX69R76E+UZ+tn6S/R79bf8rA0CDaYItBm8GooYqhv2Ge YaPhYyOqkavRKqNaozvGOGO2cYrxPuNbJrCJnUmSSY3JTVPY1N5UYLrPtM8Ma+ZoJjSrNbvHorDc WVmsRtagOcM8yHyjeZv5Kws9i1iLnRbdFl8s7SxTLessH1kpWQVYbbTqsPrD2sSaa11jfceGauNj s86m3ea1rakt33a/7X07ml2w3Ra7TrvP9g72Ivsm+zEHPYd4h70O99h0dii7hH3VEevo4bjO8Yzj Byd7J7HTSaffnVnOKc4NzqMLDBfwF9QtGHLRceG4HHKRLmQujF94cKHUVduV41rr+sxN143ndsRt xN3YPdn9uPsrD0sPkUeLx5Snk+cazwteiJevV5FXr7eS92Lvau+nPjo+iT6NPhO+dr6rfS/4Yf0C /Xb63fPX8Of61/tPBDgErAnoCqQERgRWBz4LMgkSBXUEw8EBwbuCHy/SXyRc1BYCQvxDdoU8CTUM XRX6cxguLDSsJux5uFV4fnh3BC1iRURDxLtIj8jSyEeLjRZLFndGyUfFRdVHTUV7RZdFS5dYLFmz 5EaMWowgpj0WHxsVeyR2cqn30t1Lh+Ps4grj7i4zXJaz7NpyteWpy8+ukF/BWXEqHhsfHd8Q/4kT wqnlTK70X7l35QTXk7uH+5LnxivnjfFd+GX8kQSXhLKE0USXxF2JY0muSRVJ4wJPQbXgdbJf8oHk qZSQlKMpM6nRqc1phLT4tNNCJWGKsCtdMz0nvS/DNKMwQ7rKadXuVROiQNGRTChzWWa7mI7+TPVI jCSbJYNZC7Nqst5nR2WfylHMEeb05JrkbssdyfPJ+341ZjV3dWe+dv6G/ME17msOrYXWrlzbuU53 XcG64fW+649tIG1I2fDLRsuNZRvfbore1FGgUbC+YGiz7+bGQrlCUeG9Lc5bDmzFbBVs7d1ms61q 25ciXtH1YsviiuJPJdyS699ZfVf53cz2hO29pfal+3fgdgh33N3puvNYmWJZXtnQruBdreXM8qLy t7tX7L5WYVtxYA9pj2SPtDKosr1Kr2pH1afqpOqBGo+a5r3qe7ftndrH29e/321/0wGNA8UHPh4U HLx/yPdQa61BbcVh3OGsw8/rouq6v2d/X39E7Ujxkc9HhUelx8KPddU71Nc3qDeUNsKNksax43HH b/3g9UN7E6vpUDOjufgEOCE58eLH+B/vngw82XmKfarpJ/2f9rbQWopaodbc1om2pDZpe0x73+mA 050dzh0tP5v/fPSM9pmas8pnS8+RzhWcmzmfd37yQsaF8YuJF4c6V3Q+urTk0p2usK7ey4GXr17x uXKp2737/FWXq2euOV07fZ19ve2G/Y3WHruell/sfmnpte9tvelws/2W462OvgV95/pd+y/e9rp9 5Y7/nRsDiwb67i6+e/9e3D3pfd790QepD14/zHo4/Wj9Y+zjoicKTyqeqj+t/dX412apvfTsoNdg z7OIZ4+GuEMv/5X5r0/DBc+pzytGtEbqR61Hz4z5jN16sfTF8MuMl9Pjhb8p/rb3ldGrn353+71n YsnE8GvR65k/St6ovjn61vZt52To5NN3ae+mp4req74/9oH9oftj9MeR6exP+E+Vn40/d3wJ/PJ4 Jm1m5t/3hPP7CmVuZHN0cmVhbQplbmRvYmoKMTIgMCBvYmoKMjYxMgplbmRvYmoKNyAwIG9iagpb IC9JQ0NCYXNlZCAxMSAwIFIgXQplbmRvYmoKMTQgMCBvYmoKPDwgL0xlbmd0aCAxNSAwIFIgL0Zp bHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBzV3Ldts4Et3rK2rXyTkZhCT47J3tONM+J51k HGVmMZkFLdE2OxKpkJTd6q+fC75E0rIosEMa0cKKpWNdVF3UC6jSD/oX/SCPccvk5Q/NI8uxmWU7 5Bqc6a6uUxLQfyiitxepTouUNOaZnqZ79v7ZbP+7dEHcs5mh6x4Zpsk0g5uku5xx7thkeSbzLNsV f/O2+ekGd5jluDaZhsZM7pr1W2fdjycND3zMD3y+bgsY4lE85fjzNvfIcXXmeaZNizWdz/Gqpmv2 bL4gLFS8vfwxX9Pb+Vwnnea39OoqyoIkCrLXNP+DLueA1xDPTwLoaMxyLfsJwhauWRvXPyQBNRU2 EwrLH89IzLGYBnEbh0VGXZF1oL1L/NuMGv/O//mZPvjJXUAX8Xq9jcIsDNLG6/QxfgjWN0FChqbb r2dSkm4uLGfisYVxywKNNb1e2KzgQkvS1JY0SUp6GDcdziy95mYLT0e8sniaAurVfL1XbIsZGhhw RD6zYof8HTylwmb9e9eymWPUeIq9+4SI0NyssXcv4s0uCe/uMxAsCxfBmIqEKYHAHIucNtKX16Tp MlPnrjKa5B7zeI3nNE3CWEgqT4r1EBE3oD1yTgLX2ZB7mn17tfj2OjdidHU5f0/zZJtm5EdLyu4D 2gRJGkcphcsgysLbMFiSn4pXRrV4hstck++XpozF4zqzRRwg443leSBljRs8GABuGS+2a6iW/G12 HycpIzpbrSi3QGmbv7Myvno+gGjyt9etISJjHjw2+FvgLpX8/OZqhjhJkAbJQ7BkkltMSrSGAYiO y2uIh+xRZ2O1ZVbFpKfJ7HRPJyJas+Zhy15XkcCknk43mct5a1v0OTr5bdGkV6+o9tviFGwdJc7v w5TqrYHn6fbmj2CRURbT+cVnRGK1gdzbzF9S+hDc+atRLaMuHJFgZLEqZQwjIgluPSHA7CAzyyxF ngBSm3dPgAPY+jKoz0n8EKah8HzXwcrPwuhO6D5X9rvSZKal6ZmdmF416dtrHQ2dM80xkF4V6FVR tO05zHXUVPQhbH2K/vbqPss2v759m4mwJwhYGGS3LE7u3q4QfEfpPv6GmusSw2nmvFfJuqcxV/M4 lchPULJsCi21ZXQPCZRtVHC65vzobg6j2xhxZBhRcHsrTGUc5QHk0s8Cim/HdNO8ChfbBGjZno6B n8RL266HxN1o126euMUusomyhkHgNtsbbAuYQyg3voV+G24SkePnVeCnAezcQxg8Cu3jP5UXTcd1 ixYzXcuialUn7CRZCkjtpKokYSPI1dwOBfps0lSOcRC4hZ8Eo+7murA4CN52tdq9KVPUHS2DdJGE NwHt4m1SJTUitUX6kCXhQhA5pccwuxe/2cBsjcrSqpBXrUwZljoGcxyjKpydVmSejKVDwCFW6xqn i3iZ13I3cYR8N6XgzyzxFxkKGrdJvG6/ndYIBsalgs50DXGUXa5OGSrYJjM8VakwBFwYLVZbqP5L uN6sigrW+Zd39KEI7ygDD4S9qEzFUoQwX2AJhI8zWR67jFncNw2UYHHEZJdrU4YIMFaeq1clWMVs whBwopxZFDfzNJ0aOZ5wCfBrtBFp3xIm4TEcc/cblijfOCbZ5TpKpZ9W+kKdbpvRo58kfpTtwN1W bP2Tq3T72LoNtRVcVyWnKrFvAeovgQ2LrEycs2qq8nMIuJYFEmQ9bLHyiufs9FNdubKDYePQWie7 XIAy1ghnHJpRa7vFvm4CJcm+pnx6q4p1XM815uh6+yCgL7Wb+zcr4U9woowDesQgkkil9omua8y2 NSTzbagvLzoDHo/XomvhqQzJlLVrG5U2z8CFkMYFiyea7BzSyse+UiyrS5cnYevwX0cijgsgSbzc FkEMMckHkTGm96vvM5SrU8bGaCgimE+IcLTqJU8EqU28J8IBbH1lBANEOHyL5SxD8nuzRWHuODWI +DREKFanChEs1Lh1rrXrdn3SnooJg8Bxcax7d5fgeCrPa2q1j+qBLI/ZJjxQB3LL4neMl2xRTsqs 6kixNA9nKh1Az4TdHWi1zHo3jTmmVGvr2VnEi0m1Coks12W21dk1TxxpR6jyu0ZK47X9HATOxK65 8KM4Qsl7hXPAjbh0EGXFFuphQcEWInMSA1otTxkL6mqMi63fDKqUsaBDwFngwnV55+SAV93Rg7/a 4oLo81ZiOi4UsleGC47OXJGIKMmFIeBscOEySeKEfkPhaCXuBhzRe5cRoxoEw2Tc03HzvZB5yYFn HFyVbZVlGwGUyJrGebXl/vLOy8a9frdDUmWc1xBwDpSJMvY2CVEjRMEhRV0zyV3XMSPVJKvgwpiV bxQU82vtVrk8ZQwWgGm2p2bl2xoCzgUXrnD6EYibnkX4kuLntnPB8ydXavfhdhvzsc0ue71FKhrU bZdZpoXmnSOAKqM4RQlKx+Gf54kWoTag5+11s1Pg+v0FXb67mn+6/pWuL3//9O9LOr98/+n6kj5/ Pf9wdXE2v/r0cTqL3l7CMSWPmuTV6YiJ5i+3s4uVsehDwHliF599PBtmzQvvPk2jklUuTxmLzl1m OF67Wq9MOjIEHIr7+SlCXsbDtf19ADpm+La36EMwN2OLY8+JJmJpuQhlWGp4zEGvp5qJ0hBwOs4i zhbfo/hxFSzvRPBxauxZ8WMyLpTLU4cLOi40ei0qwHkpcRZhoSumi63PmOo4jLgOboMkiBaijbbS 7+k/iZxpspFidcoQQfQBoJe9WTw5gQjSl4iljqUshxmGY6GyfwDdCVQQR5Qf42SNVOQhaPKilw6j UqC6Rl6u6sUpwDmu4tnIDgZIGRLGhhmx/39/DtFC9/Jxv2YyJO/tw7sT4n7pHVOmnrN6msSxHv79 jhkCD9ZTHOZeocViyKbJqTBJJadc3IvvnHJ4hpnP7+hwoc8+QVrSXBhmPQfBAxfEae7X6yvZWKow rkTuqEYUZYC8qlctThkuuA5zuDwXxrSh9fGkOQTcWdGx/QudLZc4mUzl46rJuFAuTxkuOB4zDbc6 knpxn2Wi58UzazzPlP86R+fde15jErUeFNJB+vKSsw1mc7RjF/FxC8+Uldyq6mhaJtMx/qkbr1dz mkqA7ZEv8v5Gquy9tzIngevQTNwgE50TkvTKEc4as7aORUcYquVhVJZDp4mvg3B/qoHBJLuNuKyx 2qFjf7OJE7R2UILr8uKMdhOjd3FHKz+62/qY65TFozrCqrGjWpMyxs+0MFwFzQfNlPKEoEiSAFIh 0Z6iQ8AtcJ06iVei4ZSWoWjsw93GskW1Ur5oT85j5zgSyWeQPcbJd4ox3sbPUD8dlwk2LkZhTJZZ Lk4ZJmBUHbdVZcIQcH6W+Yv7/H7OojG1Dd2AggcIkPDMT9N4EYqu9I2fYMLWduUnovEHVBAj3qZh Qrk4ZZggSh+uqkwYAi7v6S060AvVY9fP84b0vapp7e/Q7Ve0B8JAjKl6HD/hFhRGWiHuzEVdqv6Z WK+KXcqrOZXpglcDvUfu+LLK1tQO0oOx1ZQdX2KgpuU4Lb91Qil0Gr91AFufTxXuKucmxRi3ha7T VVyMVniDX5DoRke36n7YQjeQGZOtdddfKXNl7BSqH5qnKAUOYOujAPrPRZwCr4QZBZn/PYhy3aND HcGMn9E9GpNvggDvKF4TfaoYueFv0MmMLlXhzVbjzpuqyznF6pQhgsYZhuy2q7x90pbPswYGsUPA lQGKiGX9MIJyYRD8PJL5usln6PyOEo9IWx7vcYqWx7qNwbTjGoPiUqlZLksVDnBMK0KXjpocGARu 35eFTV4GJksELufBwt+2u0V/cpt3PYyxwi0VngRPIm4fFI03wriNPQ+vHPzTwf3iwQoqzbjah1la KmbZg8BhWgouEecntqImhFSr6CFM3zzRvoir4dCK6SpbDFxBQDOuhSrnxVYLU8ZEObhxqqvKgiHg YkStyWOIwV7bFE7qZtcur4kZ6XBc+bsIBxRxFK9j3DP+ssNwvXVK316dfQnSb69HZUMVs6AunEtf HTZomPVitYvDqgQtHGcQ0uBE7Iospvq+gVGH8eJ7GHCyaDnUQdoy9Z3S8CQ3jbmtY8x7rdYWniqP n+I2eXUGgTmszDCP48nz9tmrvyOf5nTL2bGvsOD48gwP38xRusKD8qnrCGNeUyhvBXCOGSeWZSpj FlAR0k2rFSn01TV+C8LsrzcU4HxjhQCx+e/yz02I42D6HU7YeSMGuzvNl/F8VOOLcbWWiy+rECUE rEoqjhTYxryyVA1PLrG1JN5nh//7WSRfxv9GBVh7rhYlWjvmRSwcBGfbFUNbcKY0cDo2rmPgS3F4 P54DBu7/ybrdBAplbmRzdHJlYW0KZW5kb2JqCjE1IDAgb2JqCjMyMzEKZW5kb2JqCjEzIDAgb2Jq Cjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgMyAwIFIgL1Jlc291cmNlcyAxNiAwIFIgL0NvbnRlbnRz IDE0IDAgUiAvTWVkaWFCb3gKWzAgMCA1OTUuMjc1NiA4NDEuODg5OF0gL1JvdGF0ZSAwIC9UaHVt YiAxNyAwIFIgPj4KZW5kb2JqCjE2IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9D b2xvclNwYWNlIDw8IC9DczEgNyAwIFIgPj4gL0ZvbnQgPDwgL1RUMSA4IDAgUgo+PiA+PgplbmRv YmoKMTcgMCBvYmoKPDwgL0xlbmd0aCAxOCAwIFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0lt YWdlIC9XaWR0aCAxODIgL0hlaWdodCAyNTYgL0NvbG9yU3BhY2UKNyAwIFIgL0JpdHNQZXJDb21w b25lbnQgOCAvRmlsdGVyIC9EQ1REZWNvZGUgPj4Kc3RyZWFtCv/Y/+AAEEpGSUYAAQEAAEgASAAA /+EATEV4aWYAAE1NACoAAAAIAAGHaQAEAAAAAQAAABoAAAAAAAOgAQADAAAAAQABAACgAgAEAAAA AQAAALagAwAEAAAAAQAAAQAAAAAA/+0AOFBob3Rvc2hvcCAzLjAAOEJJTQQEAAAAAAAAOEJJTQQl AAAAAAAQ1B2M2Y8AsgTpgAmY7PhCfv/AABEIAQAAtgMBIgACEQEDEQH/xAAfAAABBQEBAQEBAQAA AAAAAAAAAQIDBAUGBwgJCgv/xAC1EAACAQMDAgQDBQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEU MoGRoQgjQrHBFVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2Rl ZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK 0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4+fr/xAAfAQADAQEBAQEBAQEBAAAAAAAAAQIDBAUG BwgJCgv/xAC1EQACAQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFRB2FxEyIygQgUQpGhscEJIzNS 8BVictEKFiQ04SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4 eXqCg4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2dri 4+Tl5ufo6ery8/T19vf4+fr/2wBDAAICAgICAgMCAgMFAwMDBQYFBQUFBggGBgYGBggKCAgICAgI CgoKCgoKCgoMDAwMDAwODg4ODg8PDw8PDw8PDw//2wBDAQICAgQEBAcEBAcQCwkLEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBD/3QAEAAz/2gAMAwEAAhED EQA/AP5/6KKKACiiigAooooAKKKKACiiigAooooAKKKKACv7UP2WP+TYvhD/ANif4f8A/TfBX8V9 f2ofssf8mxfCH/sT/D//AKb4KAPeKKKKACiiigAooooA/it/ak/5Oa+Ln/Y36/8A+nCevCa92/ak /wCTmvi5/wBjfr//AKcJ68JoA//Q/n/ooooAKKKKACiiigAooooAKKKKACiiigAooooAK/tQ/ZY/ 5Ni+EP8A2J/h/wD9N8FfxX1/ah+yx/ybF8If+xP8P/8ApvgoA94ooooAKKKKACiiigD+K39qT/k5 r4uf9jfr/wD6cJ68Jr3b9qT/AJOa+Ln/AGN+v/8ApwnrwmgD/9H+f+iiigAooooAKKKKACiiigAo oooAKKKKACiiigAr+1D9lj/k2L4Q/wDYn+H/AP03wV/FfX9qH7LH/JsXwh/7E/w//wCm+CgD3iii igAooooAKKKKAP4rf2pP+Tmvi5/2N+v/APpwnrwmvdv2pP8Ak5r4uf8AY36//wCnCevCaAP/0v5/ 6KKKACiiigAooooAKKKKACiiigAooooAKKKKACv7UP2WP+TYvhD/ANif4f8A/TfBX8V9f2ofssf8 mxfCH/sT/D//AKb4KAPeKKKKACiiigAooooA/it/ak/5Oa+Ln/Y36/8A+nCevCa92/ak/wCTmvi5 /wBjfr//AKcJ68JoA//T/n/ooooAKKKKACiiigAooooAKKKKACiiigAooooAK/tQ/ZY/5Ni+EP8A 2J/h/wD9N8FfxX1/ah+yx/ybF8If+xP8P/8ApvgoA94ooooAKKKKACiiigD+K39qT/k5r4uf9jfr /wD6cJ68Jr3b9qT/AJOa+Ln/AGN+v/8ApwnrwmgD/9T+f+iiigAooooAKKKKACiiigAooooAKKKK ACiiigAr+1D9lj/k2L4Q/wDYn+H/AP03wV/FfX9qH7LH/JsXwh/7E/w//wCm+CgD3iiiigAooooA KKKKAP4rf2pP+Tmvi5/2N+v/APpwnrwmvdv2pP8Ak5r4uf8AY36//wCnCevCaAP/1f5/6KKKACii igAooooAKKKKACiiigAooooAKKKKACv7UP2WP+TYvhD/ANif4f8A/TfBX8V9f2ofssf8mxfCH/sT /D//AKb4KAPeKKKKACiiigAooooA/it/ak/5Oa+Ln/Y36/8A+nCevCa92/ak/wCTmvi5/wBjfr// AKcJ68JoA//W/n/ooooAKKKKACiiigAooooAKKKKACiiigAooooAK/tQ/ZY/5Ni+EP8A2J/h/wD9 N8FfxX1/ah+yx/ybF8If+xP8P/8ApvgoA94ooooAKKKKACiiigD+K39qT/k5r4uf9jfr/wD6cJ68 Jr3b9qT/AJOa+Ln/AGN+v/8ApwnrwmgD/9f+f+iiigAooooAKKKKACiiigAooooAKKKKACiiigAr +1D9lj/k2L4Q/wDYn+H/AP03wV/FfX9qH7LH/JsXwh/7E/w//wCm+CgD3iiiigAooooAKKKKAP4r f2pP+Tmvi5/2N+v/APpwnrwmvdv2pP8Ak5r4uf8AY36//wCnCevCaAP/0P5/6KKKACiiigAooooA KKKKACiiigAooooAKKKKACv7UP2WP+TYvhD/ANif4f8A/TfBX8V9f2ofssf8mxfCH/sT/D//AKb4 KAPeKKKKACiiigAooooA/it/ak/5Oa+Ln/Y36/8A+nCevCa92/ak/wCTmvi5/wBjfr//AKcJ68Jo A//R/n/ooooAKKKKACiiigAooooAKKKKACiiigAooooAK/tQ/ZY/5Ni+EP8A2J/h/wD9N8FfxX1/ ah+yx/ybF8If+xP8P/8ApvgoA94ooooAKKKKACiiigD+K39qT/k5r4uf9jfr/wD6cJ68Jr3b9qT/ AJOa+Ln/AGN+v/8ApwnrwmgD/9L+f+iiigAooooAKKKKACiiigAooooAKKKKACiiigAr+kT4G/8A BTv9lnwD8E/h94F8Q3urJqvhzw9pOm3Yj09nQXFnaRQyhW3fMu9Tg9xzX83dFAH9S/8Aw9n/AGQv +f7Wf/Ba/wD8XR/w9n/ZC/5/tZ/8Fr//ABdfy0UUAf1L/wDD2f8AZC/5/tZ/8Fr/APxdH/D2f9kL /n+1n/wWv/8AF1/LRRQB/Uv/AMPZ/wBkL/n+1n/wWv8A/F0f8PZ/2Qv+f7Wf/Ba//wAXX8tFFAHq Pxw8WaR49+NPj/xz4fZ20vxF4g1XUrQyLsc293dyTRFl/hbawyOxry6iigD/0/5/6KKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA/9T+f+iiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAP/V/n/ooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigD/1v5/6KKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooA/9kKZW5kc3RyZWFtCmVuZG9iagoxOCAwIG9iagoyNjY4 CmVuZG9iagoyMCAwIG9iago8PCAvTGVuZ3RoIDIxIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+ PgpzdHJlYW0KeAHNfdtyIzeW7Tu/Ao/lGHc675d+c7s9c+ZET0d7rIh58PiBJVEuTkhiWaRcXSfm 48/auCeYF2xSmVJXRJsJkcmVwMK+YQH8XfwkfhddUlRlof+TdqJq6qSqG9HmRZK1WSaed+K/xJP4 7odjJm6PIk26skuzrnavNq7teCuKrk7yLOtEXpZJmhelyNoiKYqmFlVXJl1Vt3TPe//b86JJqqat RZmnSVm0pX3rJvx6keIfvuZ3fH9WEwz6p14WuH1ddKJps6TrylrcPoq/3OCvaZbWm5tbgQelt+v/ 3DyK725uMpGJm3vx4d+fTrvnp93pG3HzP+LHG8DzuueVADZpUrVVfYawh2vTx/UnJiB/wDY0YPLf SI81VZKiu/PhLhNhlwXQ/vq8vT8J739/+bd/iL9tn3/biR8Oj48vT/vTfnf0/i7+fvhj9/hx9yzy NKu/2bB62n8wycSpByuqCjROM/tgG8WFXk+Lfk8LZk9fxs2mSKrMcrOHJ+heLh6/g2ZH3s6Vukry FAyY6J+NmiHX4NEDtpmfu1WdNLnFo+buGRExchtv7oJizLFj9VXZJkWep41oosAFw0iTwp8O29Pp ef/x5YSZsYV1YwI/I13SpF2bwuqhq4qsaPKqIntITXk+Zimztobdryv7RHp6jHe3byq34o/t8377 8WEnHnZPv50+CftM4vbwdNwfT/un38ThXmzF4CRXTifK25w/HdyN93T0JGUGh9VUJSZWB3fTZUnZ wIdor3CFs7mob+3MAm3KrGhZXXvcnajfDk87cXgWj4c+QTbWX487JJ/Zs2YSfhpmskLvXQL2/vDy fC19p4w42JwgbqgtuiEjFcy2Rd1lVmZJm3dFCGhk2gTQDrcnjO4f24eX3fHabruImVkHW1/D2V8y 2N+K3fb2E5Hzy6c9Xhw/7273918xxW+1r/86ONdfialFlSVZ2riuv9ihjxofvml1Ux0xL8xZWyZ1 kRrLQ/e7hzlCpxcVYr5SvSlDaNLWuXkXzddFg+GiS7qiaFnB8C//+a8/ZF3X/JoI6bsOT9cSdnKe Z1WSZTm6qI/17YOjIktqSmH8ROIsGAmm+WrByCXgXo5wLPfi9Ik5nmDppp8Gnjvm+bCjRSDV1TQX NHaWb9yJ/dPd/o/93cv2QZtR9Sx7aU438Ukby0fmaQsSpDCbfdA9dq6ZSuRZkaSNnC4D9JzLc12o dvr6eQcz/rA/HUGI/VEcEbUhpityTY5NZA7M6s4CCVDRIDGL702uTz8z5FPGp2ga+PQCIdDQfJrr zY/703AE/4pehmZN22DS5B0CSlRJMlRJ8rI2HkT5mahqBW+kTDmFSkFlUbImqwxzxP1+93CHaXs6 9OzNRledXik2QHUH7rdBNtNH+mYz1MYFWZm0RRG6j80kMHYuy6K7y2UHsM2x/fTlIFC3WbJCZgtS PXi9Dgv8Ldc6+HNgtkzSYMp1WVaKpocnLuAn46DCfYRRS/aaS5QGUM4N6s2nHRLN4wnm/7en/f3+ dvt0El8Oz5i3R5q6u+fPz7vT7k5sUbB4WjTGL3PMY5SOdWdfHOKP2xXWXLHTGPalqN7pNB7ANjfi 37+cDk+Hx8PLUfz89XjaPYq/v8iq7H9/+P7nv//3NxjmO0QEVN3ZjvBiuw4P1MO9Fx7UHUIFpKBB NvAuzPkQtjkePBxutw8PX8Xd7n7/hAmufPaXTwckCY+77RMV8WADtkeyDPj7x6+SFYfPu+ftCeWp w/0qLNCP9m5Y0FLNLOetLvGTQpalsl69vgQcTfVzm7B/kqM96BqSJQc+x6pUiZVH8yzvZ+CzJG3t wE/FJFxvz4pJjFuqmzxpGhT5A3tk1jcVwCBa4hORhc0R8RJwP++fbneSdcxoCRj75YmpjK/Lk7bs ilyMdeCkQd/eHT6f9ocnKj0sXgCvsYTeIdMPkE5Rb9FwOKvbpCqrOgQUFw+rAjhCjKOgAmPddMWv 38rhDtbImKPPMpW2kMzo03WmMwY7pzW7dzmdLwHnSk3IKcTTQTwcnn7D4v/2lpYMDnfbk5rs24+Q BYjd0+3hDiHHtzLREMg1l3QyRVGgt1FDqfWTRXgZ7tTi8RKLXU3ZwSr1u3pqrq/DS6xXdG3WX0B4 L0Xw+hJwyg7JFBfEfDqcUKc6YSFrcXMOn9h1WJkOUE8NMZdzLG+dofZZVhRqXd6NMOeoblARgYz4 j/887Z7ukCt4iodlrbnW+QRPMNWl68yaEpK29L3OmkvAOWtOzrss6vRXmR0+HA/i5en4sj+RImTJ wc4z9GlO0ccQ/rlsV7L0WngXrbvnWNZsWjLtGrf2NSNRU7CWhDWa/T/fBnedJ2mVtyHu3uQK0HLt 1ZmPvKyHa6hWU48ZrB5W/kBLmeTq6M4ZssEgZHR1xze/Si57vk7aFzAROdoS4rK6hFCga0QGpUPe Ij15Y/0SlLTQ72Y8/ZIy+2/C1hqLoW0KXcVFwPenr6r+9SbYszRLIGDDTOt3+tRM47qxs5k2lSPb JTUDqJeVzJlaLBjcPrzcQeFIpSUZ7CNflmVDZM5Yvf/8vL097ZHrL1xCTPMky5szSvC7dXTCn/Xq rP2y5ZuiTtoM686Y7na20+0i1UBnpmZqPN2XpkmD9SyWfeTXjM56ZQqbqxkVChyLayZtvHo6zA7c 0JYDq2iB7ovfsZRwCOl93sbqFMhHckjDAvD86fFKC252HdMAYjEBmcjbdGOFoS9KePA+B6a68WoB 6NSEIoVh1kIPYQDpbuwBCuvCzK7zrc/sKnpWdUldQkIVABoJgANoWIi4FtxFczuz6Xp/XEdQB4Hw xwN08eT+/u3h8BEu7/u7x/0TlPFq6YxWWAcjy/GZ5Pf4rLC7yEtI7ZDYXwKdUP+N1gaH+/0VfaGR NtU56soplN4lYs6s7CubMsyvNqUI2b4rKVO5A03uAFMyW8jKkG4X7k0UR5eUvag4enHPmkO8UDA9 a58UTJafOdmLWI417SLFDiB03AUPcHz5+CaosyxN6posSh91z8QFM/Lq1HTS5hoNswHEcl1SJ/c2 HWn2WBjcEXXwZZ2X2WNhAEU4r4TZdb4pnXdepNtvHdOG8BimTe6UG7WbPpxe0QCVguE9XTRpG2x6 gi4ZOTrsJipjbWpMHd0PGw8wsvC5ZBH1m0rfbC5uD6FS7vIsgk7DXmbcEZ7Zval5aROfFKKCEluY vS3BWMSYXOpdLe8ZwDaXYt8cxPbu7nl3lDk2BDvHT4fnE1JtrKAdaVEVwp27w+3L4w5qPiXwgZJH 1ujlDt1Fgw+7tqYe7L1woMK0yYr0fSp3LgLnrbJ4ezBlSqwEm9YwQst/yebBgZCiX74cSorNPrPB R5pbOcSWUZ6+2Lee0pgPYJ7fmoIICIcIoFRkQLMqJC9P0MvuntHnTPBntuwy8Cih1B0y0IvA6z2n 1yKfssI5dNRtjU0WBmDPDs/ZOn837OnL7uGPRVeZsLCFTAJ5Q4C1F1oGKSo3tDzj7FTnFRAElFjf DAERTBizmUMa1OLG4ODOBSQbd+jH+SpGf0rZXY7yjI+8agf3Ql5mgyb7Ru9RqZBJ1sggWbNWafO/ HeybVwo/sC6VFbSqYwAORY8Bmbg2hEcm22FpUlBJJgiI3oV4sGovACe3J4fHDywu6TCVrQDymxmL DMZCSgYDQBxjMVixWnKW5Ng4XWQ4jmIQ9Jx7UJvM5J4FaMZ4wcOZ/502Nnp/SgBzarDXmcxYQ2qp GvIuJ/Ml4C6Ytywz6OxyH11vKIOs/honrwu24+ff2KOhqj6gkXkLaP4BOMrJY4WVSX/dZ87RT9Hf 1tziIAZeTda9F4VnVrMCeL0hDUBdM6TzhSNTWgsAjQxpAM1syrmkyzbeeW2TI2pWOC5CKO0uag39 c0FI6vtxJ3DQAPaQLWuOTZkhQD814OuY4xpb3CFFeZ/m+BJwdzuoZHeQbZCIQx7qhu1fJOHAaU+9 faOng1zz8raI0fWixSYsCrUlpZb6wd5NtQmrsGnd9XXTc7HMWiXH6hJw53vE1NZA2idIa4Z6rzNZ rMUO48hxtGODZT7zAO9mtLFKULV2tN/eBhVtgqoL7+iaHBrZ4TMcvzeH1jHdESu+zjpa6MXxWlUf /Nt3Jk7eaHCi6FDyHgSJ1ziY2SDRLGZUmAVl2037lyBE5FsWVkBtRVxR2IJY56a3WnH7vMPOIKUd HGajkqJrKi5ySk2OelJTQ7KtH4dVV8LZjvqwhCWTUev3emR4+7lCpxPhLLR3mYpegE3t9oQWBsod HG152mOr2udt78xLSMaDAzFhR79/eBDPBzrmc9HoxxyZUalHezfuEMspiH3e6VLbJeC+7LWea8ok 0cz/uKNtjsh9ZExE4mc6CHnZwxFtJqSf7L3QoJSHgb9TGlwETh17uUdyq89HsNuiuCIUXmhkNl4H oN/c3Jcttq0WdoR7eN4iNCrpxCaS6yj/M4hHnvi++XB1qGbWakdlOkOL49jggfOKcQprgFRVhebz wyUDcBvEXYTtR5wPuyQ6W7MN0PXGOIgsh8d4buFT/tpBnJYAw4kTDSuMZpPkdFRoi83SbV+J9dOr n9tsEoESZeOubHNWeMrPBFimyiORAtcLBecIfu5dr6WUmaVYsB4W0w3NUqz/4xBx7IwOerjHNWPf 9C9IfL0W6WSp1lS3DaAhAxdF/vGVbVbCZ/dqBIDiqtvqqClmh52tVlw2tGaF1ABnTR7I6jx5VSBW uuBcy8lH2Iz8bAfOk8YvqmC91DxCb4qdKUKCSkBmzneN/Y0TnxeoUWARi/6NYcPPvuQlDvELsA3O HK2XvWYZZrZokhtxVABohKhBZ12yO8vvrzgvMmSCcrLtFUqdBvcaQf0kHUeHXB/YFQAd72D/xyR+ f8F5k5QfLVkryXByVwFJl0HYmy9zLunb4SBi3I6y3GWBn2DoCm+YWdhwJuf94eHh8OX450U7EOlH lyGqDjqwN6mjvM8rhl7SR2cUewFdgwOKBX4BpEHNzts4v5F6mLzz3gRtEX7MpR+h0VxrG+yYc7fC TbrKu9dmyW25JU5agDzS7LXvdWsQZSxLRq0OK/FjKhl+kYvFRcSVi4Kr6Lg77JG/CFxK6IL/ZcE1 XeYDbcWiFTy9U8881RpWfsp/29QCx1G0JQTRfiF3zlRS5y1phywFLgGXIk7PBfypwM5YgZ+4E/jR pPi2RUlgCnilfrB3wwLSsJAsnsmCJUngEsw+uJ7VDJzRvzABnYVwU1PGsnICj7Hia0S8FZUiGjgv yCL80et1kAGki2HXdJAOwWVOgFKHdr8yS1A/zGiPZokGJD78acn55kpJuoci5hu3h1hRoJX/TfVQ wOlrsqZZ8Zr9ZcgpQIZDmtTcHvIn2WwaZ0/ijwGkSX1ND82SGr9q2uG3Spv4WSY+/MuSpLZnkZge iiA1t4dYpLYH7RpA2ov07FBA6ms4NEtqu9d9ClBAam4PsUhtz32KAbSGpbbnPkUDWthSW9GxARRB ai6HWKTOzEZ/AyiC1NdwaJbU9jccpwAFpOb2EI/UyGhwFAfS8fjw45oemrXUrpgfC2hhS40tYerg JdNDEaTm9hCP1NQx9EubBlAEqa/h0DypzSkQU4ACUnN7iEdqfQpEDJ5VDLU5dCoa0NKG2hw6ZQBF cJpLIR6nzdY8AyiC09dQaJ7TduEpwgytEVLb0/yneshMsjVCanviVjSgpQ21OSDbAIogNZdDPFK3 0L+nOLLPAIogNXeW+XZxntTml8SnABkOrVH8sCLyGECrWGr9q8vReJY21B3E7BkOizCAIjjNpRCL 0/boDQMogtPcScbitP3F1ylAAae5PeQDmq192F98jQG0hqG2J7FHA1rYUOdmX5ABFEFqLod4pM7r pCygH5rw9WuWPnIcBNm2M44j4DS3g3icthqWiR4ygNaw0/aU/qkh6wFa2FDnVkmjeyiC01wzxOO0 VdJMDFlA6ms4NBt85BX9MjFWp2KGbI2IOsfSS52m09O+x6ENFjp4ypeBWTa+8pKbn3CI6SE5y5Y2 1Fh6kb/UYABFkJrbQzxSW5lVPKm5s8wfsnlSGzXVBB5DoTUCant2lxmxofDMAFrFUJvTYqIBLW2o zWZBAyiC01wK8Tjd4cfNctJgTnBoVUONlReoCKbri4ZDaxhqHHmsfhliqocMoDUiahxLif3jHM+x sKEurGZScyiC1Isa6gILL2WLY/CmhiwgNXeWsQy1U25OzDLDoTUstTn0faqDDJ41DDUUt+pojmhA Cxtq+6OPBlAEp7kUYhnqAsyRP/poAA351oDTXIEdj9NGAEpD1wa6r7ONBSEytviPhc3pvi4B978D wk40DZ51N/TW/11SuuF4oB8tgphcHvCIaXmQQlPdaFpaRf+7ODa7xLnmDtubiUqs+m8cjjG6azgB J/6bx7OGE3Dav0g8C/sAJ/1TeCJm2qIuwCn/xvsnsLPcMItlZZ3wbxxPwGdu//h4ZmvfTvc3j2eN QN3J/iLxLBynO9WfwhPBZy5/WJ7Dif7G+yfg8zX8mS2nOM3fOJ6Az9z+YfHZSf7m8axhn53iLxLP wvbZCf4Ungg+c/nD4rPT+433T8Dna/gzy2cn9xvHE/CZ2z88Plu13zyeNeyzE/tF4lnYPjutn8IT wWcuf3h8pmKFlPqN90/A52v4M89nq/QbxxPwmds/PD4bod88nFXMs9X5ReJZ2jxbmZ/CE0FnLn14 dLYqv/H+Ceh8DX3m6WxFfuN4Ajpz+4dHZ3tw1DyeVcyzOXJ6Ins3/SPxLG2ercIvms9c/vD4bAV+ 4+MV8Pka/szz2er7xvGY8VqjvOHkffN4VrHPRt0XCYfM84LnI2dW3KfwvLV5dtq+8f4J6MydXr45 nKWzk/aN4wnofM30mq1uOGXfPJ41zLMT9kXiWdg8O12fwhPBZy5/WOY5N7K+8e4J6HwNfebpbFV9 43gCOnO7x59e83S2or55PGtYZ6fpi8SzcPTsJH0KTwSdufzh0dkq+sb7J+DzNfyZ57MV9I3jCfjM 7R8en62ebx7PKubZyvki8Sxtnq2aT+GJ4DOXPzw+WzHfeP8EfL6GP/N8Nlq+cTgBnbndw6Oz+RnO 2ORrgxMLllSnWiXffP/I6bW0ebZCvmg6c/uHR2er4xvvn4DO1/Bnns5WxjeOJ+Azt39YfHYqvnk8 a5hnJ+KLxLOweXYaPoXnrc2zk/CN90/A52v4M8tnp+AbxxPw+Zr5NRs+WwHfPJw1omen34vEs7B5 dvI9hSeCzlz6sMyzp9qKVSJxRVu+OZynsxFtZTl+A/ZMtAXhrDzFTP0nmGf8g/tY0Jx27wJsI9I9 8bfDLX6X5a/b01b8Y/t8wpQY/t9K0j31ZBGk5JKAR0pDgrRImhZHerzLk/v64KaIyZ3BLFpa7d4E njUdgBPvRQBawwU49V4soIV9gJPvaUAR841LIdZ8c/q9iR4KjO01QcSsF3ACvglAAam5PeRPstmo xin4IgCtEaY7CV8soIXjdKfh04AiSM3lEIvUTsQ30UMBqa/h0CypnYpvAlBAam4PsUjtZHwRgNaw 1E7HFwtoYUvthHwaUASpuRxikdop+SZ6KCD1NRyaJbWT8k0ACkjN7SEeqa2WLwLQGpbaifliAS1s qZ2aTwOKIDWXQzxSWznfRA8FpL6GQ/Oktnq+CUABqbk9xCO1EfRF4FnFUFtFXyygpQ21lfRpQBGc 5lKIx2mr6ZvooYDT11BontNW1DcBKOA0t4d4nLaqvghAqxhqK+uLBbS0oba6Pg0ogtRcDvFIbYV9 Ez0UkPoaDs2T2ir7JgAFpOb2EI/U5uffywhAq1hqo+2LxbO0obbiPg0ogtNcCrE47dR9Ez0UcPoa Cs1y2sn7JgAFnOb2EIvTTt8XAWgNQ+0EfrGAFjbUTuGnAUWQmsshHqmNxG+igwJOX0OheU5bjd8E oIDT3A7icdqK/CIArWGnncovFtDChtrJ/DSgCE5zOcTjtNX5TfRQQOprODRPaiv0mwAUkJrbQzxS W6VfBKBVDLWV+sUCWtpQW62fBhRBai6HeKS2Yr+JHgpIfQ2H5klt1H4TeAJOczuIx2kr94sAtIqh tnq/WEBLG2or+NOAIjjNpRCP01bxN9FDAaev4dA8p63kbwJQQGpuD7FI7TR/EYDWMNRO9BcLaGFD 7VR/GlAEqbkcYpHayf4meigg9TUcmiW10/1NAApIze0hHqnNj8BG4FnDUDvlXyyghQ21k/5pQBGc 5lKIx2l7ct9EDwWc5uq+fArNc1rrvgoUrWCS+rqv93Jy30XgYuV/Qz/dTILAdeR/5tEiiMnlAY+Y hgco73Zdnb9L/V/RB/fm+r8pPGv6Aav/iwG0hiOw+r9oQAs7Aqv/M4Ai5tuijsDq/wygiCNcr4kl Zh2B1f9NAQpIze0h3zPF6/9iAK0RsVv9XzSghSN2q/8zgCJIzeUQy4lY/Z8BFEHqazg0S2qr/5sC FJCa20MsUlv9XwygNSy11f9FA1rYUlv9nwEUQWouh1iktvo/AyiC1NdwaJbUVv83BSggNbeHeKQ2 +r8YQGtYaqv/iwa0sKW2+j8DKILUXA7xSG30fwZQBKmv4dA8qY3+bwpQQGpuD/FIrfV/MXhWMdRG /xcNaGlDbfR/BlAEp7kU4nHa6P8MoAhOX0OheU4b/d8UoIDT3B7icdro/2IArWKojf4vGtDShtro /wygCFJzOcQjtdH/GUARpL6GQ/OkNvq/KUABqbk9xCO10f/FAFrFUmv9XzSepQ210f8ZQBGc5lKI xWmr/zOAIjh9DYVmOW31f1OAAk5ze4jFaav/iwG0hqG2+r9oQAsbaqv/M4AiSM3lEI/UWv9n8ERw +hoKzXPa6P+mAAWc5nYQj9NG/xcDaA07bfV/0YAWNtRW/2cARXCayyEep43+zwCKIPU1HJontdH/ TQEKSM3tIR6pjf4vBtAqhtro/6IBLW2ojf7PAIogNZdDPFIb/Z8BFEHqazg0T2qt/5vCE3Ca20E8 Thv9XwygVQy10f9FA1raUBv9nwEUwWkuhXicNvo/AyiC09dwaJ7TRv83BSggNbeHWKS2+r8YQGsY aqv/iwa0sKG2+j8DKILUXA6xSG31fwZQBKmv4dAsqa3+bwpQQGpuD/FIrfV/MXjWMNRW/xcNaGFD bfV/BlAEp7kU4nHa6P8MoAhOc3VfPoXmOW10X02bVJnVffWkVQGlr8Ezq/ooLJ40ydOq1f1jf0K2 fxohkG2+u7nJJLnFB6j2rjh3eLav7GmEBULIeXCBjHPoJ4P/LMT34v7w8syEzeJcZmvafdi9MQ7A XmO2ZvsxszXtPqCRQQ6gHW5Pu5N42j7ujp+3tzuxv9s9nfb3+91zsmQvugCiD3qqFxdlo50pENs1 uZ0pPTxvMnORo+elxTMyqG81c6PABYw7OzB0nWlrVw/7mHsDHCBddtra1cM+oJERDqCpaXv4vHve ng6L2rvcVj77ON+s43Jb+ewDiuu4u939/ml3J/7YPrzsFjVxuU3a+jinOm4dE1ciKiiqcihYehMT V9RJWU3j0fH2Nf2jgyWcvny83fwu0iSru1qexaxfWheQt0lWVlPdYyIkcpGbH2/ET/j3u+gS9Goh ckSlFU79FfQDD2XRlqLq0ONV3fqxpA8Hn52Ak3VJXVcRsTa3d1hxj+2dLKPH7G9t2dzcnoWSwgsl /89uf/p/3wpEGtuHpH8+9I///Lx/3h3Ff2y/iuZbkadZ038DXf3yj+1vO1H8+s3m5n/EUv0NBU5V p5mg1J2e8N30eJonbWN7/M3sR4Z52mCZR1DwNgYoyoCoiZJ2ompq9Hkj2rxIEMdmZoL8IipRil8x O+/Edz8cs80PP2OGNGnXpvh+WPoiKxClVTRtqCnPxc8/9GfRn/SM6jAFu0y0RQ4jk8pBzYs2E1Wb ikeR500maiB5ED/LOezNw5E7kF2gj23oY48iy5rKuwOhlVN7Gu3xFkzvkqbAwzcF+FZ3G9w2aAIq WkxvMjxAk3ewWGUu2xrcPavMJ2VTcLMH8Unci19UF/bMi3ssaa2oYyq8osfKKJeoYK4wKvLR6HKj Lh/kk6Idj43/p8uaXri/ep+lb6f+pFQyg73FQFdJ1zbdpqGUPaeOM014CtX0IOnQIdq1TRWSrbrF kKOjkq7Gcfq9lrQoNnRv8yYY7hITmG5km5qkrDFliGnq1lhZblLg1ojQsarhdlNmZdLWDb5NNz2I MivgK7PcNlFDhgFBg76z16K+HqZQvwlPW4OrBRCZJvck1KJurZ/ffb1uuJVjmIsv4vfNIC/PBrAo SjC7ou61Lx/oJQY0RyfgL0VRZZuqLpKyaXJ5Jaq6E7fqZZ2VAEvvETX8TpXnLa70x+u8pAv8CS9A YMyrDb0ES4u2ohvKv8jpZT+tr9QHaN7hy+QH6KVGYT6+IYB0W4mUHp9IlMp/IFHWJm1FXQ88mPQl Zn+Vtq3IMIBdWpLxuHdvwnzJSzIW8j0Ympb8nXtDDe+c5tijqd9RFAlsgvTR7k3kuZsKhRzvNvie jXtHiTi+KYthMBQV0LDWXVuAMW2SF+jgDDlmWXUgVdKmWc1ywyUeNs9LshqA7/++RNp15IaLRnaX /s/NI7nhXMUrv4gPf919A8P64eEbUYsP6vXpGxhb/fruG5GLD39Gy+YDoolfxc3/Ve62Z0E0F8sS 4U1W48F6UEIAfklp72oKw3cs0UOwDhN3DBKho7ujF4LFOZiNczDi9R1MljY15qH0MNiGQSaT7WLk 52CXaRp692A4GcwZcpSbumwwHZqSEOk2YdswHzNyKTB9dVklaZnXNEdBtbpLi/77wvtd5mhyhJOV yFLscarg+DL/Gl9ND0x/R7cpX5PneKN+v/y793lca2+D3z7ueRtRI/WqU/nU1t7bNs/f2DbjODY1 fpWiLcleGVdSV1nSZZi+nsepkUrlDSyR53LgbZKizMlVKZeDvgf4FibCYTAt5Cu007Hv8ryObTPu A/fSdzctGB2NwfkdPLfG6jke+0TG8eAZde84DKbFcz0wfTZTGokdKFKWjgHjRYGDe+05H/k36Vnw ClEZvIW+qpFr6dcY8Y32PxltFSKvZf1PluWpvje9Uh4IJMFrzwXJa+l1zB025kp9BoOKfVo0H1W7 QWO8EP6Kp5BuSL4yfgj2RYYI0phTr4O+5HysMe8aBArwMf8lnmTUOpviWWNew6Mh5dQZBww7jDkd FxDa0mhjvoGRd8YctfxoY66h6OyXoLT5mF+h6XZzLz58K7ZHcfq08xLQQfPewJnWcPHnj9vmY49r vuPz8+F0cMZ+8P5Yt2/h8i+5/e3hQTzsH/cncbgXx/0/3Td994/d8+3u8+ll+7B53sOhU3aIXJ7C kixBulojWkHGTwG513nf/ftjIf56QPwS45fCGICeWpsy+PsSs6AuUQaA6cb0IsOSIv50bdqUZZVr 25DhqjrEUjVWWjpZhvBb0o5ifmne9LtA6A5ZpjJlug3GButYuBdMmbp7jmIERsvDoFtwL0zrHKkc vlG34V4VIq+ic22I8eBqKNCTpgx3l92nWzQGupd9V4s4B1jpXl4bPRHuZe+ue8fDoFuUKZMuk5y8 /DeeLPZCam3XlOuhJT1t26QrktfavpXIIuHv6R2waYgVcdXiYwhl1PUG1xgOZefk32HpcC1tnb6m CBrVB4q25f3kzkRp7+h+6gomAWyAz9TX+LwsN+GLdAuuEcjSlb6fvaavoc+rvys88vN4P+HTeO39 9PPI7zNPZ2whurM4M28pHKbq4ES+RDUlaVFpxEiXCLWNeUO+TKOg/6Mi1EJZEkSoSZLAjCApbcSH X7JffbvlVQWQD71GNQBWzjgHpDU2WJNs4wZr6PKqRCxTERfwEmNLt4iP1UCgJKdEoS5owjYUFwVN uKfcYtymmOhUjilQ+aC2KsnrAlNdfVI2BTe7KE6TNgRPg+2ExH15CerJS7IT1EzPiv/gsqZgzfsr Ed5ejhUEbIjjVQRsG32HztttmwvI5CZHSnh1iIbgCIRDZUrbNVk5qEF3BMD9EA30KrLWhWjoODwK kj3cSxcqbIsfopl3+SGaaXMBmbm7adlYDH6IZrD6IZp5IhOiSUsqQ0cTorlgkheikT9XYRmFS+o1 RlKGTmGAheQffym9EC0rKHRS4RrVu6TZone1MCpeiIY7tmQCMSjylQ3R0NoL0XCtgzJ9B32Fe9Nn 2gx3wneaEM2gcSEaIVchGr0yZqmXb1Ovpy2WToMQLfS1tr4wGFOYfLvGslOWo7b3KP5yg5iYQrSx uGjhfPscykD4FOTJey9RHnxOBAlp2cFW956zF4AGt5yL9pCD4KcPySiFPTcfUcpQbHvaH568b+EE Up6vUCZ4gQQ/T12Cj11YYCvXZ2xAXkrJEf0g57W3YPgMGPwqRTmoRg2mrKTPCJoAC8VylL+o0k0l KBT1ZBvCjFoOuPykbApudpHPaJAQkd3vlM+Ql5jN8vKBnpT+SpvWyCQ0iGrtm3Hpf9am9S4WDm2z 7zOMHfZ9hmkzHkJ2U5uiRmxaUMDsQFMk535aj2qDrNTRvXQlGbE3vDN62nkk+gFcqpw7n2FafJ9h 2nyfYdqMh8DA6LubFuDSGHyfYbD6PoPW5+mJnM8wT+18hmm52GfAXlufIW255zNwrT1D66f1Gbhl fEZeki1X70J9P/AZeWXSenplfAa99n0GXSsvYe5grkxaTyzTfkb6H4XG8xnS6yAj0r5JhSR9n4Fe T2tkWa/jM+goj/dRo0Wd3oPSM+uBeGjrUt9hR6FrtBN3ZDoK63rGMQZ3RM3aLAQPYrSuJ/qOc08N s4W0t6UFjrF+DDB6qpxhjKBnh4gz/o6/zTw1llMKpNPxN8QCwGQ31k2Cs1Y4d5wbGKj9uhIrH/EY mf7f1N+k/1+2wA/338AqygI/Vm6pcsL2//JzyPOalhZ/zS3i/T+SCFTssViOXUZZU7TIGcMmMrxU CkFxv6RkSq6/IUaoM5T2zefwpvBzqMNesoSM3UWI7VMc70YuI6PLjb5EICJLJPSk0vtnOLDCvhl/ 9T877v1LrDVWRaEqYSoiELbN8/62zfrwEl/QNFhfNi2bEjjbAr3veX/qJalH9rx/ibQwr2lh0uSj WEtB5IUCsPX+tsXz/rbN8/62zfh6jIK+u2nZWAye97dYPe9vn8h6f/vU1vvblgu9P2I1inMpq8NI ygqh9f7yWvp19BjiSFPUxxUUQsrj5zimjUhIi8p4rZaizR02OSpV8t74G15p7y9fe95fXkt/b+9g rtRnkDHK79QZo0Vjvb9EKjNG+WowY6ReTwus9nre//IVWnRG0qWIJd5ByjiAZT5nHNH/xyyuYv1h 0cVVHOmQv5LthcD1QtsLB44lVGtDyfYGTWRWUaGmcq6zvViJLXMEqr7tDT53me3NURG05hSOiS6d 7SUhL/1V216ICNybadZ4n52wvcbqeZmXtWe+7TXvM5YWT1ug7C+FNyqjgo3DEmsGO+7bXpT425YU Iu6DFZyWVK9Y04uWDEsKzvLqBt/w6ibf7uomY2RFiQZ5Z69Ffj1ERa7JoPStrnkWZ3XN8xqri+dV /gH3IjcqVTwRS6m2Tictnq7ZKWu4MTZTWUptT2WZXy+l5rJApS0tRtpa3RyLzL06HQ78oKUJ1Onk K2N1qdW3unSt7Ky5g77CvXWdTn6nsbpq0aGhzyg9kLbbcJzy1bDV1WNujS7AQqol5Tr8pdQSO+Tb hjz6KoW6XvaIAoxkb/gkJii1cZ1cABmRIVtZzcCTDNjsQHB5g1XY7en0vP/4ctqJ28PTcX88HWlR 8/C0E4fnIJwmusr17DHolxVLoW7CZLeS1bhV5McD1s5PX3YPf8zlJVj1y1OUis3X6HXzMKv1Fcje Xo7BbIwOesgxHYJbKuRza9NqN4bcUnCEvNllVe+sYgmbb0WvmNBUK+FnLPQ5ci7wmu4WltnTy3IQ 8TkXiboV6m49r6maAMt6Tajr6gpaejRZt+neZd2mvtdFKYt2fXSqqHoy6TbVJRk26TbxqPgrLpXb dH+VbtNcji1ykachj+V7TeugXEqhmzzXBytagNZeC5ZlusZXvZZYL26lnMW9C2C7HCuJ7tZogYrH ukxR6gZP9WqafJep3+W8obmz16K+3rnMTYkFQYCkMTNqWeSo6kmcx9QP6xymbvD8JUf1Kv2Y8ZfK jzl/iWt4T8o/cijNXZaSY93cZCk51g1NloJkuecv8Tls49D+EroD6y/R2vOXuNYeUt/BXFF9Wb/G dxp/qdHQGrT2l8rjkr+kV8P+Ug+49TJKRiqdzIarPCox06C29LZzDEmPdGnrgnWtQHr0E3beOJ8z 8SDREiqULaQI1TxIhC/wilR99z2Mh+cCSY1HElaDR8chPd8UVAq/9B0Gp39mdwcTDLmuN4UniCE8 9xvTP4PRzQamftDRmtJsDB4pCtmQWtmUKS/GQ5sQeip6I2I2hd1oPOLDH4THbfvijNeZZsZKKy0e +DQqCxs8EXxmjhePz7qobOBE0NkLtbjDNU9nU5KewhPQ2VMNcvHY4Rqlsylox+DRdL5dks7IOqXE MhqP+CDN4VJ0poJvmyNU137mrekMlVtBokiDJ4LPTHfhm8N5PuP835yElVN4Aj4z8wuDJ1RELLCn DrGyjKBpU52XHPT8gJOQ9/bl0TjIXXXyc1BEwIV6t4jPLzLsDIBelApuNsE4a0MAlpE6qKEk0qUY FMZDDU4LJTbHOPvsZbW5BiIYVN9UooDHo0vUvmXOAd0DFvbpr4iupSoCQap9M/7qf3aiNqeDdT/J 0E1+ZU43eckConVapfZaKEbuba0rAaFFeuzX5WhHcOpvrcMuKLlx2tTlsCVYNfhJhm7ykwzd5JIF NMg7ey3q6/0kAxshABKI3LsQe8kncUmGfliXZOiGi5MMBPg2yZDBv5dkIDHQSQZOtPOSDHhzk2QU 2MtokowCcP2iHPIDiNdVkoFXNsmgVj/JoGuVSpg76Cvc2yYZ+E6bZCg0fpIh0xSZZODVcJKhB/x1 kgza0Nj7OcQVk4yJB+EnGfpBIryYt9WtH3UM4+EFZTbJ6HfsVJIxGiQO4zFegwzvvBezScYEnsCL eXpE6h99dkLM2tLSO8MhgH+tKhmcDM6DuKRMJotSsCZYJdGuSC/ooM13T3QaSpVhN4XnxmgzXUlC cvtZMgUoVPXud1GtDA+kPBU5LhKo+9ewOPTAvieDgyMVuHV04fvHNu4Zz+H7Mus5XFVLNznPhW9H KaWRm1+k/LsE0BIG019jQgmvxSkTvi+Dw21xkIBXMKMTCSD3Nb5sgz04Sv8r6xdym7hp8n2Zfpfz SebOXov8eph316RB+r5MP4l8k9wmbrrE+TL99LebyxaYyI8YX6Z8jPFlcBX4m/JlBbYEOl9WgGnG l5VSr6reBbcb+DLAlL5sg6q6Kn6Rv6HXvi+ja+W9zB3MlSuY0XcqXwZcGg3epQtmyhvSvenVsC/T Ax74Mp7JNTpw7I0lJVi/YPZGQvABLAMrREG16Xn3Geet4JQ32rL3vMOW+LET80aNsem5MKUQry+y zhF50nLDK6QUOLnvwpwCB0BAXYVzE6xBxbzRbb6RpZNjkMz1cooC+7wypJz994X3u8wYN6SE0saV jLF/TcYYD9wzxg3Wrc375d+9z+N61Bhro+YbY93kJxa6yRljaGmLOvONMVTOJYoBvjHGCkGDlRHf GKNnW5wN4RljtKgMRQvAS91ANlRvnzZNvjHW73J21tzZa5Ff3zPGGqRvjPWTeMZYP6z7et1wqTEm Q2iMMb2mJAHlaOQHyoBqM4ut+84Yl/IYDv0XJeuTaxxSeuDtyoHZBfMpscC98MqsXtDrnjGm+UFn 49BBAdKc6yvc2yQW9J3GGJcajTPGhFxprOjVsDHWA/46xhjqB7k8+BaL/cMPYgNnt21Y0Lbhzfm2 4RIpbIrqD2jlHuO19w2XOMYlo10KNHv1vmHbpqevLEDp97l9w3J4K9rqqzcSlzgkgg49UtNX7hCm idRg66iev7oN8xenDbhdwzQ3cbQQaSUtAt2Ce5ldw/ZdQGX29Zo2t2uYWujubjewxUD30juEDVS6 lW3C3CFU7t66ZzwEukWVB2TR6Yo9w/BdFPyqaU2GV13rqU2iMN2CKSwXmUvaWInCl7rGZCULgO62 f5cnLsn6gXo/pmlvzzAmrtqDLHdo6it8Xu0Z1tf4vNnja96v9gTjSt/PXMvvo8+rqF7hkZ+HIyF8 Gq+7n3xi9X3m6YwZQHcy9gzTqFY411mn2nCqsZuG896m4Z/+P3WlcloKZW5kc3RyZWFtCmVuZG9i agoyMSAwIG9iagoxMjE3MwplbmRvYmoKMTkgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAz IDAgUiAvUmVzb3VyY2VzIDIyIDAgUiAvQ29udGVudHMgMjAgMCBSIC9NZWRpYUJveApbMCAwIDU5 NS4yNzU2IDg0MS44ODk4XSAvUm90YXRlIDAgL1RodW1iIDI4IDAgUiA+PgplbmRvYmoKMjIgMCBv YmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IC9JbWFnZUIgL0ltYWdlQyAvSW1hZ2VJIF0gL0Nv bG9yU3BhY2UgPDwgL0NzMSA3IDAgUgovQ3MzIDI2IDAgUiA+PiAvRm9udCA8PCAvVFQzIDI3IDAg UiAvVFQyIDIzIDAgUiAvVFQxIDggMCBSID4+IC9YT2JqZWN0IDw8Ci9JbTMgMjQgMCBSID4+ID4+ CmVuZG9iagoyOCAwIG9iago8PCAvTGVuZ3RoIDI5IDAgUiAvVHlwZSAvWE9iamVjdCAvU3VidHlw ZSAvSW1hZ2UgL1dpZHRoIDE4MiAvSGVpZ2h0IDI1NiAvQ29sb3JTcGFjZQo3IDAgUiAvQml0c1Bl ckNvbXBvbmVudCA4IC9GaWx0ZXIgL0RDVERlY29kZSA+PgpzdHJlYW0K/9j/4AAQSkZJRgABAQAA SABIAAD/4QBMRXhpZgAATU0AKgAAAAgAAYdpAAQAAAABAAAAGgAAAAAAA6ABAAMAAAABAAEAAKAC AAQAAAABAAAAtqADAAQAAAABAAABAAAAAAD/7QA4UGhvdG9zaG9wIDMuMAA4QklNBAQAAAAAAAA4 QklNBCUAAAAAABDUHYzZjwCyBOmACZjs+EJ+/8AAEQgBAAC2AwEiAAIRAQMRAf/EAB8AAAEFAQEB AQEBAAAAAAAAAAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNR YQcicRQygZGhCCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldY WVpjZGVmZ2hpanN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TF xsfIycrS09TV1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAAB AgMEBQYHCAkKC//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGx wQkjM1LwFWJy0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpz dHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW 19jZ2uLj5OXm5+jp6vLz9PX29/j5+v/bAEMAAgICAgICAwICAwUDAwMFBgUFBQUGCAYGBgYGCAoI CAgICAgKCgoKCgoKCgwMDAwMDA4ODg4ODw8PDw8PDw8PD//bAEMBAgICBAQEBwQEBxALCQsQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEP/dAAQADP/aAAwD AQACEQMRAD8A/n/ooooAKKKKACiiigAooooAKKKKACiiigAooooAK/tQ/ZY/5Ni+EP8A2J/h/wD9 N8FfxX1/ah+yx/ybF8If+xP8P/8ApvgoA94ooooAKKKKACiiigD+K39qT/k5r4uf9jfr/wD6cJ68 Jr3b9qT/AJOa+Ln/AGN+v/8ApwnrwmgD/9D+f+iilGO5oASinfL6n8qPl9T+VA7DaKU47UlAgoop wPr/ACFA0Nop+R6/oKMj1/QUDsMop+R6/oKMj1/QUBYZRT8j1/QUhb0/kKAsNr+1D9lj/k2L4Q/9 if4f/wDTfBX8WBOa/tN/ZaYL+zD8ICc/8if4fHAJOTp8A6CgVux71RSZf/nlJ/37f/CjL/8APKT/ AL9v/hRcfI+wtFJl/wDnlJ/37f8Awoy//PKT/v2/+FFw5H2FopMv/wA8pP8Av2/+FISw58qT/v2/ +FFw5H2P4r/2pP8Ak5r4uf8AY36//wCnCevCa91/aiYN+0x8W2XkHxfr5H/gwmrwqgk//9H+f+ii igApQcUlFADtx9vyo3H2/Km0UDux24+35UB2Ugjgj2ptFAczFzRmkooC4uaM0lFAXFzRmkooC4ua /tM/ZZX/AIxi+EDISjDwh4fIYdQRp8B96/iyr+1D9lj/AJNi+EP/AGJ/h/8A9N8FAJs98+0Xv/Pz J/47/hR9ovf+fmT/AMd/wqOigrnZJ9ovf+fmT/x3/Cj7Re/8/Mn/AI7/AIVHRQHOyT7Re/8APzJ/ 47/hR9ovP+fmT/x3/Co6KA52fxV/tQoI/wBpf4tovRfF2vAZ56ahNXhde7ftSf8AJzXxc/7G/X// AE4T14TQQ2f/0v5/6KKUAeuKAEop2B6ijA9RQOw2inEAEgHIHekKkYzxnmgOViUUv40fjQFhKKcc EDjGP1oyvp/OgdvMbRT8r6D9aMr6D9aA5fMZRT8r6D9aMr6D9aA5fMZX9qH7LH/JsXwh/wCxP8P/ APpvgr+LHK+g/Wv7Rv2XBn9mP4P7yoX/AIRLw7zINyf8eNv1AIzQOMLtK59AUVc8uH+9Zf8Afg// ABVHlw/3rL/vwf8A4qi5r7Dz/Ap0Vc8uH+9Zf9+D/wDFUeXD/esv+/B/+KouHsPP8CnRVzy4f71l /wB+D/8AFVC1pbtuLyWnzekTADj2ei4ew8/wP4p/2pP+Tmvi5/2N+v8A/pwnrwmvbv2mOf2j/isS c/8AFWa7yOAf9PmrxGgwkrOx/9P+f+iiigApQxHSkooBMcXb1x+NJuNJRQPmYoLDocUu9/7xptKD 7ZoBSYu9/wC8aN7/AN40ZHoKMj0FBV33De/940b3/vGkJHpikoFzPuKST1OaMmkooFcXJr+0z9ll T/wzH8IGRtjjwh4eIYAZBGnwHuCK/iyr+1D9lj/k2L4Q/wDYn+H/AP03wUAmz3/7ZqH/AD9P/wB8 p/8AE0fbNQ/5+n/75T/4moKKCudk/wBs1D/n6f8A75T/AOJo+2ah/wA/T/8AfKf/ABNQUUBzsn+2 ah/z9P8A98p/8TSG7vzx9qf/AL5T/wCJqGigOdn8Vf7UKhP2l/i2g6L4u14c+2oTV4XXu37Un/Jz Xxc/7G/X/wD04T14TQQz/9T+f+iiigAooooAKKKKACiiigAooooAKKKKACiiigAr+1D9lj/k2L4Q /wDYn+H/AP03wV/FfX9qH7LH/JsXwh/7E/w//wCm+CgD3iiiigAooooAKKKKAP4rf2pP+Tmvi5/2 N+v/APpwnrwmvdv2pP8Ak5r4uf8AY36//wCnCevCaAP/1f5/6KKeqbgTuAx6mgaV9EMop20+350b T7fnQFmNop20+350bT7fnQFmNop20+350bT7fnQFmNop20+350bT7fnQFmNop20+350bT7fnQFmN op20+350bT7fnQFmNr+1D9lj/k2L4Q/9if4f/wDTfBX8WO0+351/aR+y1IP+GY/hAm4Jnwj4eXc3 QZsIB060DUW9D36ip/sv/T5F/wB8N/jR9l/6fIv++G/xouV7JkFFT/Zf+nyL/vhv8aPsv/T5F/3w 3+NFw9kyCip/sv8A0+Rf98N/jSG144vIv++G/wDiqLh7Jn8U/wC1J/yc18XP+xv1/wD9OE9eE17l +08/m/tK/FmT+/4t14/nfzV4bQQ1bQ//1v5/6UMVOVOD7e9JRQCYuTRk0lFA7i5NOMjsSzMSTyST TKKA5mPEjjox/OjzJP7x/OmUUD5n3JBLKDkOQR7mkMkhOSxJ+tMooDnl3HiSQdGP50ommByHYH6m o6KBqpLuP8x/7x/OjzH/ALx/OmUUC533H+Y/94/nX9on7Kcs8f7NXwgACuw8J+Hiu5towbGDvg9P pX8XFf2j/svjb+zJ8HJMgf8AFJeHRyhkH/Hjb/wjBNBdN3kkz6g+2X3/ADxg/wC/5/8AiKPtl9/z xg/7/n/4is7zv9uP/wAApf8A4qjzv9uP/wAApf8A4qg39mu35mj9svv+eMH/AH/P/wARR9svv+eM H/f8/wDxFZ3nf7cf/gFL/wDFUed/tx/+AUv/AMVQHs12/M0ftl9/zxg/7/n/AOIpDeX+DiGD/v8A n/4is/zv9uP/AMApf/iqje6RQQZYgR/05S//ABVIFTXb8z+Jz9polv2kfiuxxk+LNd6HI/4/5u9e IV7d+0zz+0h8Vj/1Nmu9sf8AL/N27V4jTOafxM//1/5/6KKKACiiigAooooAKKKKACiiigAooooA KKKKACv7Tv2WQ3/DMPwg2sUI8IeHyCOoI0+A981/FjX9qH7LH/JsXwh/7E/w/wD+m+CgaZ779pvf +fl//Hf8KPtN7/z8v/47/hUVFBXOyX7Te/8APy//AI7/AIUfab3/AJ+X/wDHf8KiooDnZL9pvf8A n5f/AMd/wqHfd7mb7S+WOTwh7Y7rS0UC52fxVftQIsf7S3xajXoni7XgM+g1CavDK92/ak/5Oa+L n/Y36/8A+nCevCaCT//Q/n/ooooAKKKKACiiigAooooAKKKKACiiigAooooAK/tQ/ZY/5Ni+EP8A 2J/h/wD9N8FfxX1/ah+yx/ybF8If+xP8P/8ApvgoA94ooooAKKKKACiiigD+K39qT/k5r4uf9jfr /wD6cJ68Jr3b9qT/AJOa+Ln/AGN+v/8ApwnrwmgD/9H+f+iiigAooooAKKKKACiiigAooooAKKKK ACiiigAr+1D9lj/k2L4Q/wDYn+H/AP03wV/FfX9qH7LH/JsXwh/7E/w//wCm+CgD3iiiigAooooA KKKKAP4rf2pP+Tmvi5/2N+v/APpwnrwmvdv2pP8Ak5r4uf8AY36//wCnCevCaAP/0v5/6KKKACii igAooooAKKKKACiiigAooooAKKKKACv6RPgb/wAFO/2WfAPwT+H3gXxDe6smq+HPD2k6bdiPT2dB cWdpFDKFbd8y71OD3HNfzd0UAf1L/wDD2f8AZC/5/tZ/8Fr/APxdH/D2f9kL/n+1n/wWv/8AF1/L RRQB/Uv/AMPZ/wBkL/n+1n/wWv8A/F0f8PZ/2Qv+f7Wf/Ba//wAXX8tFFAH9S/8Aw9n/AGQv+f7W f/Ba/wD8XR/w9n/ZC/5/tZ/8Fr//ABdfy0UUAeo/HDxZpHj340+P/HPh9nbS/EXiDVdStDIuxzb3 d3JNEWX+FtrDI7GvLqKKAP/T/n/ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigD/1P5/6KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooA/9X+f+iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK AP/W/n/ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigD/2Qpl bmRzdHJlYW0KZW5kb2JqCjI5IDAgb2JqCjM3MTgKZW5kb2JqCjI0IDAgb2JqCjw8IC9MZW5ndGgg MjUgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMTYgL0hlaWdodCAx MiAvSW50ZXJwb2xhdGUKdHJ1ZSAvQ29sb3JTcGFjZSA3IDAgUiAvSW50ZW50IC9QZXJjZXB0dWFs IC9TTWFzayAzMCAwIFIgL0JpdHNQZXJDb21wb25lbnQKOCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+ PgpzdHJlYW0KeAH7/58e4PvPf90b3ns0PZVNeyCdCkZABgSlPpBKeSCZdB/ZHcUL3shkPJTLfqiQ +wiO5HMeQZBc1kOZ9IfI6jULHykVPFYtfaJe8RSI1MqfIssqFz1WyHuELKIFVqld91yn4YVO/XOt mufIsqqlT4FakEWSZr/Rqn2u1/zSoO2lXvMLoEZkWdWypyrFT5BFXn3607LlY8ist2D1L4F6kWWB 7kRTjywLdJJG1TNkEeXiJ8pFKOYjy2pWPwM6AFkEGBRAhCxCOzYAk8vi6AplbmRzdHJlYW0KZW5k b2JqCjI1IDAgb2JqCjIwNQplbmRvYmoKMzAgMCBvYmoKPDwgL0xlbmd0aCAzMSAwIFIgL1R5cGUg L1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAxNiAvSGVpZ2h0IDEyIC9Db2xvclNwYWNl Ci9EZXZpY2VHcmF5IC9JbnRlcnBvbGF0ZSB0cnVlIC9CaXRzUGVyQ29tcG9uZW50IDggL0ZpbHRl ciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBY2BwnXDmz38oOKzDMB/GBtOHE1C4//9vR+N/RuN/ Q+PvQuNXo/EZ1qEKMDCET0MWYQCCwyCBwxASxNcBMg/rQEgAKPSl8gplbmRzdHJlYW0KZW5kb2Jq CjMxIDAgb2JqCjcyCmVuZG9iagozMiAwIG9iago8PCAvTGVuZ3RoIDMzIDAgUiAvTiAzIC9BbHRl cm5hdGUgL0RldmljZVJHQiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAGFVVuIG1UY /pM5yQq7ztPa1S2kQ710KbtLthXdpbSaW5O0axqy2dUWQbOTk2TM7CTOTNILfSqC4ourvklBvL0t CILSesHWB/tSqVBWd+siKD60eEEo9EW38TuTZCZZaptlz3zz/d/5b+efGaKBtUK9rvsVoiXDNnPJ qPLc0WPKwDr56SEapFEaLKhWPZLNzhJ+Qiuu/b9bP5BPMFcn7mzvV2+5GyxySyXy3Qe+VrTUJeAT RIGzat20iQaGwU8ft+sCixyGTSQI/KLA5TaGjYYX2/g1R5PPxaA5CyyrlUIReAV4fLGHL/fgdg5Q wE+SG9zUVEX0ImvWSprOHUN7uYe5R3k3uKQ3ULPz24F1yKrOHcZ1DLW/UizEBZ4EXlELiTngR4Cv NbWFTAffrtvRHPBjRP6djep8BHg3cKpkHpwHhh+/WWmkuvidU5X8s+C3gf/GWMwc6exdU60Yekk7 wd+u8LTob4hIUjQ7nQeGH+mAWcsJPXKQSkUeTwCPA79erR0WOcCn9JnVnBO8yGftVCUm8hT85ZcK h7LAo8C/cj0p9Igl/Vu3s50cWMjQMyIuYrE4t5x64YeF7Eo+BR5xmW6b+c5etlzSDqY7+k8qZkrw Yu+1uu7MKHIL+M1GTtSOWIHJgplIAsNnIMuNedFPgZu04CsQpxotYlXJoE1SKEdJiuJaJxOWEmmk g+GwcjAcd13NhLPPoip4jZqOzcKadZTtnV2tQmWwBl13tCrFQh9RA54q9AfYiutToRjuGuDK/+On ncuNjp8aG2Fhthf/+9gs28+m2Qwp7Cn2NDvA4mBn2D7XdxZ7uhWJfG4gStvPy4jIHd0Car+IGm0q YP0FihpZroe+riyPNsY8yxnzBU298sbfPb3SsLPqKib6OnrkXj0P/Ba4HljFuh7YcH0ogZ8CG/hb R2+8WmqevdNlcVIaTrTWp9t6Fl1VBJXqzs4ldEFDzbyn5oleH5dOf/mgF22VnXv+6tCl0yVjedRj RRf4q5lbGToz7rHhH8N/hlfD74U/DP8uvS19Kn0lnZc+ly6TIl2QLkpfS99KH0tfuPq7zZB79iQy F3Ml8hbT1a2wt9eYWDkqb5cfluPyDvlRedZVKfKIPCWn5F2wbHfPzZtvpbdy9OUoonX7c+dY4lnR XE84A9/9mADNi9g3A/PIWKPj8Gmi32LeDDoJbe+T16mIhdgUS2+Z7mkx813fwUQwHoyQEtwdnAlO BQ8J3H2Wg7tgm8Ga6M0N8+Eq+irlNj8hvicUq9VPmlq5Yit7wuEnlQg+fVxJG+rkuFLQdcUxWYrJ LW42eXGSxHdT7CO6mXO+h75tVzzOfoZo/194933vcccaRCsW0cjjHjeGd+UD7xKde0JtmM22P/L5 viOySnv3OPe+oSjeXz+3WjfxHht4i2jzzVbrn/dbrc0P4H+D6IL+H6CffFUKZW5kc3RyZWFtCmVu ZG9iagozMyAwIG9iagoxMDc5CmVuZG9iagoyNiAwIG9iagpbIC9JQ0NCYXNlZCAzMiAwIFIgXQpl bmRvYmoKMzUgMCBvYmoKPDwgL0xlbmd0aCAzNiAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4K c3RyZWFtCngBzZ1Zc+NGksff8SnqsR3hoXET6H3qsb2z3hh7PNNyzG7Yjg1aorq1S5E9kto9PZ9+ f5l1oACeoESJ7ggLKAKFrCvzn0dl/cP81fzDtJOiKgv3J21NNa0nVT01TV5MsibLzN3c/N0szVdf 32fm8t6kk7Zs06ytu6ukK7u/NEVbT/Isa01elpM0L0qTNcWkKKa1qdpy0lZ1I3Vex1/Pi+mkmja1 KfN0UhZNGR5Nhp83Kf/4zD/4flYLGfLPXhZUXxetmTbZpG3L2lzemj9e8GuapXVycWloqDzu/lzc mq8uLjKTmYtr8+q75cP8bjl/+MJc/K/59gLyou55IgKn6aRqqnqNwh5dSZ+uP4wkKB6wRAZM/23p sWk1SenufHOXmWGXDUj75m52/WCi//74px/Nn2d37+bm69Xt7cflzcPN/D763fyw+n1++9v8zuRp Vn+RjOrpuGE6E3c1rKgqpnGahYYldi70etr0e9qM7Onj5ua0mFRZmJs9egbdO5aeuIP2jnxYK3U1 yVNmwI7+SewKeQw9bsCS/Wu3qifTPNBj1+7aRGTkkmjtMsVGjt2oviqbSZHn6dRMDyJuMIx/Xl3O Fuab2cPM/Di7ezD5a2PemOvVx7uRNI+ab1kN921zWE2f5l0T7qSsJqubSVVW9ZCgLSM86MTV5cP8 waw+zO9mJ+XQeY7omDbFZir3yZDVSYc0L9JJ0xTNkLYXG9K8qBDsdTUk6LAhvZpf3yznV+b32eLj fHLKtZC300k9heeOWAsnZSiB+cJZyowRPRfmW7STtgj0bBnHl2K+BxE34BsX7+fmT4vVb3DgN1e3 N8ub+wc4yOpu7PCO471VO6nLFFS1ieR9TOT6Zr64Mjf35gZEurxihTyszGyxWH0yVzfX1/O7+dKz wORAkBpLu/3QKZNJICzQUX820KnIJrUoFGNg/XhoMGqoO2hwDHFvPj6slqvb1cd78/bz/cP89l7G 2jJGsxlMf7p5eL/6+GAuV4vFzf3Najl5Hhjtmnc2c0HU0/Jc58IxxF28Z8nbtf9YWTiZpm2TogjD wIusmOZVJSqyFOX5NuUZGVmkaAJm6qh3Q71dCMTa89v/+MtPf/7mRQjPcpBuhs1gQHgPFj2nqpfl SPUpphNP0CiG9dvczFnj6Mir5dysrg3X8O/7+d3vHizdm9m94xJXJ139mGWmZYsc60+J8T1rrUwb zEtrzHbv3JV5OsVANcVUhJiqDZwpLTAqWSOQVHigbWmcVPS2paycNEUxanE8mwyytI2cbgCLLw2I aLY0Q3nUW8+JMxVut4WN6tBsOp2UlaySI3r01vzwUe1Iv7x68/aHX76YGPPdtbl5ENg0C6vledZG j/zxS2N7d66tjZ0GLz8/0xqLbtGbA5hPkp2EjTafjCKtw0gbaNuHhlU7/FKY4FI54cCawnCz4Dt2 aH773GOYJ50C8PmmLGBFtl3ngo1qWGQzPc8psIm2g6ZAb4XDqd7+sGdOAKR/m590+DMRPHljXJvO ZvibFtN3Ps778Vwiqj6GOFGE7z7czR8AQOtLffVpKWDJAiXmxUkVorzClJTiV/ANOZ9RZzY2YdR7 7H5gExlr+4jF+sF+hXqaT6ZT1I1YWV+z4w8pGy2IRtEWBNFRxGFKQtQAMJYrc3/zbnlzfXM5W17O RWUXjL66u2Ie3izNp/c3l+/7nXwEdtoJhJMt/rxueh7U/QNL3sOn+eL3eQ/0ef/wdpSyNgI7Cd+m feZNOSkyTMl+aA5YV2PdFWug5UhKm8m0RikaUHqYnmz9GCO7+GkIL7JqUjaYAo4ivO/W/bx5em9V 8+JJYqMIdpkoZHbrTC6bKdTiNMd6b0TPr/EfOWf/4XreE3WfA9g1jrUcO4qboIcNu6JYxaovMvTT dlK2WVaaAfE9KfHUJpKjVhehIi0BIAx7v5t3UTqWYz3NfGhwCrd11Q4pPWxCLC9XYtl/kdlAcA4r qlrr48MoR8DNHk33Lk02K7NJk7dF6NgehNinLPT5FOEnL9LFeUZAUw6zGjGNH92pRy244PAeUHrY ZJg9PNzd/PbxYf4lqOjxTrXjWsBKtAK5zzIOawHT+UVmCLb2SZYj1o7q94A3X4b2MidmiBC/Ae27 mPTmXt4KGMbzaO9Tr+scRUjwAlaZpuzbhWVdllUBBgpPgSoaWakvDSsIWGubrBkFK5zS+yKToK4n WUFkhamPoVycmy9CdgcwjiF7TbqYwAHvH2tr2sD8iKzd47XL0wafOKEGfhScsBwuxV603MiOH4B3 iNoF3rdqeFkxSacEpEWUJiE6d80yMECjN5h3Pq3ETXG7Avnff0TDjrqemN3k8JjdQYNY+usN2t/1 RVmjjxBVFDVIwo1P2vW7gFNRZZMsxfC7hyD12+6M6dzKlrf2HN212dUc2HJVYA+a4q3LJL7Ts2Wp 8EB33ZpI2NkXXlsrAWJ4h0dhyGczhh5DnPg75k59ALwIEhBm+mH2EK0Ibj8vVrNHe4ePWhiM7qRu SyRDv30nXRgbKBWRvjvmIWdSZqWAsI7Sw3kS0neGJXD5bmGH4KcPV7OHubmd39/P3qlS+hietHN2 NxIk3WKFdnSPQg2TR0venbS11aSGNwbaNkmkod13o0Q6iAupQXrv4OuUrFqET0m4O6CFoMtJWpVl DPuIpgv7YQ6zd+6PpfNsiFC6NB+J7t7owr7/MJ/9H4ZlbM29XjrCpLxr2LIsndS1AIk+qcNFGwf9 nHYeha5DPIvtKnYk7LMCPBsHJyR7NHFEoC7vbwlWgHffisNgtvxsvQcnjYIOAfh1n+jeCB+0MA9b HIe7inLUySKMcI8eDwN3wpXD6Dl4C0oNUm1zdrtFu8c24dMepn4uz9UhtA0G8ZuPHxa4qhBN6yGl PZay39mzhsH2ct5N+/QynFNtS8Se6+lR0uuz3TDwaLveLmbYaVW97u7NzEEnj+WFMZLeu1LyoDv1 6Nli4RpQZkMzzQ9/uSAgwnjmgy+dkIo3jx3/Xb1YBDNRj+rxvfiEQCBj+x3qADqS6CFZnRv2sNRZ z/xzShyQ4oMrs1ET/tlkmaWtx/b2ydm7+eX85ncgsPEwxc22+5sF2xQWn5nmt+z5NFfrPOix9pKd Uy/4Onsd3pt6XrS4/b9jF/AaK9xJjwMzFaFZWZGeZ2zOUcT5jb6PZSRHCZJgzPOkj1pYzyFJgq/N U3i0NnQYyNkrSkK0/ICgw2TJ9d3qFqVXcMRPP37z5uJbr+2eFLnmqCTThpCLAc295TyQepuX8xNK Epl7slFUkxrkVbNBkJi/JqdSKCucXnVFVgMLUns98SKMrUknhWx5i0HzPulRCAJ59+5u/m72wE6m x7KQXQw4SxH3FWbHqk9or+MOmkJPtA69XbSa4u0WvXvHQD6n8lPVJOtoAj1b2AJT7CW0n8OIGwwj GwPYEjBbkpVidX3aOUbmk3RamQGZLzbHgk1nQNCWQR302x3bDMneITsq3BqdX0WB+GxJ+rh4EOgX fg6dewoEXRQY7moyw7gJejacDz9iWrfn6WGojiHung2m7EB+PwO3W1m/w+3pol0vV8uH2c2SubJY yDI7ZWoX73fzjTubmQBhVXOuM+EY4rxzacf4s2dVMaEOu3qjAjt4tPdpl0Bn44XdfIMHVnv9bGYB noV82p6nvbo6hjgrCE6K8EOA6oDAFxOdAZ7lqB7kEjsbeEZ+mrJpezB7n226BGZ/PVuulhiBF+Zv c3bS3GOcOT3m9mkwqh7RLz+mYk1lL/K5IO6UuPaWjcyx6rRvTMcbBUcZnMNOmeog4gbI8YKYBNyV bsLd2QkXwOEJ8uqFkOGN5O5TQ91SkC1k6w4SSWAHBH54fzc/7W5C4hALPPq+BecizkpN5ziYnft6 dPzsHGVNDbPzKOLu5x9m5ACam49L2cZFFL7sL3w3v5OMO6RVuLy5hU0uV5ZBSpnAoGvyraw+oe6c FNp6UOMbdjazoCEThCRbiHnU2cyCY4jT3XqvN+aG+tJEm8yz3l2OKLWZBx4d7rkT3PrEG2yA0n4/ m3kgQC1vvLXKGhLOZh4cQ9z3P729UN+o02DNYj67EqvGv+Z3q/t/QwGWC+tzNvowTlQn0mAbV0YS Mp2UJ6DCaybT0jXvfOaC5P0927lwBHGn3dfEzvE8n1a5KdnROLrjXJyhTEZ40Lcz4p+XNgUK6MSL tCurjIu8Ws7/+SDJMHyE4kmnqHf0+5adzRRll0ddTM/TNlceQxxp30j5Zsy/Ewk//+fs9sNi/pqg RvDC6zInMzd7e9vqdf6lK0tfp6dNh0AC6ZIcPr4tZzPwVTnJyCi+SccbKCubHYVP7OUpCTttJNA4 xk9rOt6QsmeKKTuKuM2a0mOVvKOiAMimPRFM4tvhJuEWL8fAO/qSiet8GNyA8J6BZEDu2Nk6Sq8K Kbk8Qb3pug/mDXCR05uCHSCaGk/vFffhPp7wo/nQ1gCBtY7cO1V1WuZZxbwsSAdLahYy1eUpLiy7 1VBqPHDrS2y7OTjmnMxUk4LECaOWw7Np7o64UTMswG41XZ7UIJ0xo7KM3Wq+F89GkoiJQLa3non1 Uk7sqNjXtVOwDcIFKgDM33xGy3VB8hxxWSHCt09/j/UOxXHEwcZuFNkbluX9DWXG7mX2p5zL6Kbs 2mvqvt1nDbcMhnc8D4n5296u6qx/BxE3GEWxTQdb3kbzj4sv18SCPu/qa5PK6J9sP5dPBlC6Jo3i 2YD9Sva0j5yfaxLtMItUv9NfcMG4HAS+y3ZzoMEsmC1H514ZNUf9ci7YDEe47571MyCuU+RGjigk Jr2zmnaNaHC5bqNxZ8pQOPhf9DCOFWbzaIfBx3u2GLyHt29cWic1Qvi09b49R2PA7brfuCXjYr4x m7PbhZ0GsYjcB6bH89BRtAUeehRxNpvVSfFXNzv7vfeC/MaeLYY1ifObwmj26PG62nPGaxYYE/OU 8OMdiEF3OCSvxgqImOPFWgfqm0uWsuHstaKW/f0H0GOg56RRYm682OKdl9W4vCr/QQb2f31pOHFo toDTxf99+88PN6AC8/3ss5l+KeeYTeOf7fXPP7IB3JS/nrSB3i9Atue4hRtn5HPucSk496/lUMFN M3Ig6R4zI/fixKyQTfKcgrCLoIOW7FajgF8hPxu0fPMr4vZKD0pMvn7LEllPKiLrxmUkePt1/wjD P7glhX9NwgCaIidRkY3vz4uGnf5Fam4NDgQuWV0L81bjKKKFuKUGGQZ5LZHXbk0laZtCBd2pjjuJ JR9jK2caQJgcBQC7qZPbtSKIYntTWWPykOT8DbFcUlSz400OZXQvStGwroV5jynkZ9uBPe7SNUqP qZRuAerq3CK/2oRETlhWK2lXd5cspJXyWwWv5nsVAT/+Se66J/ntvXakHAKZSeaaCoN220yF3JZV 1dLMYZFUyCGZLVzFP0UBaYEbbSVta1DgohIykEhC9qQrEqjCBmOpyL+XNXyXtdtVTUmeE0weKHIF HGMpKefraZtMXdGCIrajFBlHNbgiKcimDLYUaM1Rif28VOQfypVIei4qci2RElu17ZLw+dD6Sx2+ 3HzaNqV7Yye4rChK5jExWNHlQkqJ5czZnMkvBelsdINwSRphf0fQlrvEjLZI7DM1Y52Th7t7HfOI /YLYSQw8gJq4XHDZ4LDAXCG3dl25txN3Z1+QBUff6QsRFd3rEGirlTgyN4n8SZsJPd7IOgtHVGAi SZvGkDEy44AVtfv5Z2o8/FmD9To8wyaV/hPMcM0U554gEH5KlJA1H4Zq2M5KJKzsY3WfGlYj+5Q4 /2zHhzhOB6DKEam2iow5Xve/UrTMF8mm0z0ybX2LJHuGzExi2Tg7iik+5ZxLk4EHykrOEGG7VJaP Q6mQkOckkpkSQNg3Q6RtKxCa5PvS6+6PPc4zt8LuZ/PqG5KwlObV4gtTm1f2mpOzKn999YXJzavX lCg2+tVc/Kc9+LXHgRyHLUtOps1qWrZOC6M3pGUg6DRwYKM2t1+2JH3ZYp5etjQsHidbGtKCHiFb 5LVbg8W7NF0NhwsX8KLMFlYa6eEL0pjDdtfKZDXiQ5+y6HmOVZNy/JOUIeYzycPq3tWyYX1HSRhS AzHRTQOgERFjbxN7u9DWyq/QJEImA2SGh+U2enermElqyZZTM4EiORPKIkETyoLEIMPSpE0JBfYl 1CVbEiXleiijUzgORPblRbKmFh6Y0otB1tRk38aJzAZLJ2ySUNJJG+pyT0XiJpQFuRFq9yXU5WiI BE6gNZI4oUVB4oRWB4kXSsbJHAFBKhEaTnG1l4lcRjJHblWecOi1iAgncxrwvZM5DcxTXkAuIX37 Midp9AWkmlw4mSOXkcyRW5Uy4W13Z19A5sjHFlYSBSqCzBECVebIhZc5PaYrHZ1xGEnMdBsOWj6O 6dZsMeVgpchu8XJMdwMt+5lu7D7fzNJpYNkKN1lrKSxoyNK9quB0qb/LiTSYuyR81NwTMoqY8edZ f/Xj/O5y/uHhI4Gkdzfoyxln8sgRVfzjmIZMzkJHQAKC+h//6rvbwnyz6p89vlVCDIc1ArHIzVJw VMuJiXIohHCXWtIvgnx8meMuhEmEMoWopMmCEbfEKLWy5RqEGkoywQ+Wu9gyJhyHywkb7p4T7sIu c+oCQGjt8A1J/NiR4AqoiS0CuO6h1BVREWwUfaErqoTp8yB8xNbMI7ZEuZt+X2ryZVCudEpVUZlt jascXul6pqPAl1jOosJLRK3+266tbYK26CgocCI6LKsJt47dcDic+x1mohIG5FURviPMxd4DaRNl O3pLpJCIGP8rzAfpgj9Z8LJWxibiSm7lT6M3vMwU8LcA+0LNmgyD/Z1bUYqEFdm6/L28Iy/bn9l5 r1/2t5bOpKtMm+k/pTeeNdGDaD2DA+hTzcgrfUqSXtmOXaMoYi3QoUybYKdhF630vPtjgV0RgN1k Ijns0AWn5tXPxa9foHp77Bap4vsSlW4f1J4KjuywLLlFb3AwKUtT6ZaxOjg5idMKbDOF10dVHA6U Moa05dxLm3k5xbkvsGRQBmG6IYJgMJvnOIUDSBldLSq8Zm3mXS0bvMtEOUIVnwLHKgO74P/SunBH dbSVUmmtzqQpCMM/Kj+GR6Fmmy4uR0AUJFuIlXFfxmsdjHHPKTNSdbxGu6vR+eISoCEqDKvLAyc6 BKYsW3gtG3NvwkaKgg0ZXtcn1z8nD2LT8CAJ+4ItoS4PUEIZdXUwxr/pIRFfdLVHJZYGrctp5QBD pdXVpep8aFFXu291R4PvryNBUks6bIeX5NJxLRTzRG4VALU0oANJrXi47A+oh2LY0Ie4tvq8MipR 7DOSICqfSvTK4SS9joCS3is2CjX4O7KyWQwln9RXsiTQEqCSkKlQSS48P+pDJT/kkX76CKgEg45M nvC2F4RKfVqGGnKctuGPHWLZjI846YQU38pEoub1qhwoun/aV6WHXDuoHFT5454qyXpMhIKwtd4g 7KJys915K9DqmXmTzsxrnl4VV0OPFzJFWjDHxwqZhARTBes3y5Ceem3rOFzK5CnGG0LHEsnPV/Of iD1XpiY5LWP1kXwcQw9dLypTjV1IysBcqeBa/66UDes7SspkmRUlOQhPpGjvnk9Lg0XU0HwVNVkm tj3ODZLn9ffofe6duMFb1zf9kk+dZK3a6o7V+7JY3PgyL0joL+BsTQZuX0IvYPTThF9xGalWZcNn LG6ki8Tk6MVNgg0UNoLk7mjwJbG48WWxuPFlXrhoXVq7L4EuR0Osk3taY53ct8iLmyT0TidufD+M EzfBDpyRhtnLG73uBA6Dx29WmIjxR0y37g5TnBc5WIwE4IpinnHetZqQO5FTMC8FGstvuEmtYNBr lR/WHqz3Vsi4GizmYzLZdwSx5XxT35FrR02QOUqpCh29iqROIj2lVlHpdXD+UD/3/CWsUMW+W454 wwhpjaI1oWJFW/oUUFborBkindZ6kFE0wVjaGUXFQRsB680SwhlFPS3O57eL997sYecY26zQcc07 oMroAKjNVHqhc3iVm9OLnoWEAIMKPxZPIJBeLEzjJYS8dwtWxRzRVRGm327PJfMyY8XXol5UePea aS322rUyCJPsd/ipANEYK2sOetYyMpeJj9C/K2Vr9R0lIDgdTvm/nDGqzeMWaai3C2mt/Ep7VRpg 7+well+jd4NsQDL0ZAOcFGe7GMVie60vi2WDL+skAd8tOacoyAHqEp+NpNoKZXQKNlwM4HRKeBPv ifhOInutlOQZll4vG5JQEsmGUBbJhlAWJIGUaO2+hLocDbFs8LTGssG3yMsG/Haud7xs6PprnGwI 9tqsYMOcM9jqdSwb5DfH9Rm9Tjao0dL9Ujorr8gGCa4VLcTLhoQSkSciG+TKywa5jmWD3FvZ4Gtw d2qIlWtmmRqHbTm2PqWGOy9doNTKBqE5kg2dx0x6XbdYP4lGUolfIcWib8OCXlQjGdDSEw6Ip1gj OVQ47KpyoD4cKhxGVHm+wiHPOULVCYdcDIpHCAd979Y0AJ+oihHCgTMpSjHpyWYcZrWaqPpFwvLV dInbTnbHFOIAlzKWS4X32L2pRf03j7NPNQCwitYo/qdpcpu424W0VH9FRomaQPLD7mFu43e3C4YS NbRVHOt5svFFkVjwRYG3S0HWsiSiEgL6qmlsn8IzxyFPQlv3FKZe3BZRvIg4qFu1srsIFl9wqfhT 4kXoV/tMJBB8kef+PONqjkrs5ztxkBCaJERCUfeUb0mQBr6xXhiEDolkgRyzBJJQwLsj1kd5NKEA pZMFjCXXkSyQexsOwpWEFzk9gQgaiehQKcFslpAOe12Q2CaWBbBnDTpBFsgV3a/8WksjWaD3yuW5 sjXYO6nbmab0m05P8NSINmFlgVJu65Y2bJQFMuCl+FUGskAVhWSpMWZrpvXQj65Lg6JQgnSK+DwD jFNreoLjmgfpCRJUsV1PiIfUk+KDJ9ZJ2eDG6xxtycW1efWY2IkuLi9RBvb0BhscIyEwLyfSkAk2 Go7re8DxXGKSQhUjOK6ohLh1dLNalinHHRRBlmxpy/Gf85RGDijHhbnlEqok29x4Ux8bVHYcFFdX EJ0jxn+aJresAb0FbJPsCH4sgZnC1cRIIrf+1/jdHRzXMbMIiXtmFnPcwBZdpJ08w1KJOS5OLj7e 47iSjWkAw3GoYv+PYXjJwSVovh0MN75Erfg2SC+U0dCONfo3O/bpa49KLA1al/MI4JgSUl1V6hAI 7ekqd03u+K4ruEzEt3NonF7A4MrznD/A8cOAoPXecVQsLx3fLZhUnu9GGDz3CNrXYCixGDzRK893 Bxhcf7Oc1tfg7gIGZwLxTct3mWqOmo7vCn/vePpmvsuwoy9GARSsmbRFtBCRd/DOmo7xas5av5nv RTF4uUbKBsY7QM4Hx09sqnxf+MQbI2klJdHOhxWn03w2CzI0f5Sw+e/f/LfEVXQ2+o37DbpOziXo Bbdcp+lsaJqXKW5rhkuYIpuXVmxXuutsUv3QDUIa10M3JBFPI2GJ7OnWT4slc1zoxtDiJ2YGMTRo 0ISGbrAJTBO8wzxD3EQoc/xNgitCmUBDDcogPxOBm9O8C+aQEiIyvKHBPQXnhwOzYKI3Nfc3OZZ9 6Ibys3aqZGn0iCtgaYfACV9ERT50wxeFAAzlnQ2Ror4kKVlq+v0odCPQKVW50A3fmrhy1zOeAupy JRZYBkmvqHK7l78XuuG4HdAf3qF+hBC74e4d2pR4C1cC3xOTEncYnIDe4Z5gFg2i0N/ha/hERM75 34WDSTXKA7U+mc0hgANeJ3dwTxvB4e55ny/Jh4RT6vOIAh7kztXn7/V78r79vVB69H19PtAb6rMt 9t+zd55D0p0j4jhkXFMi/93uuxFxHGyXiczNJ4zjAPAECyrqwTEWVKJOSzV6SkRVVMfhmE2cVAUz 2Mj+1arIpba1MpkzaKNFIToxFrhCDgyXMrlE8Pl3tWxY31G4DU6qU4RZxszCqqv3SW7vAZE0WKYc zeeP3gvCi36P398B3vBRcaJHz45a+jLH3mSDRSjrNF+ekoOngy6clOjvmW6wDGW8x8ok6QYkhjeL FjZBBi7L3qT2gp0ojUTfep09CSWRHTWURQAulAW4Fmr3JdDlaOgUZ+hytMaas29Rh+B8T3gIR12u vyyLG4/hSmL5nB2VbS3SLxEC495iOMk72WG4Sm3T9pcKeSfvYEcl4m5gR6XE2VH1ymM4KY11Z7m3 qM3X4O6o2+rOTDT1aDhs56jpMJxQbjGcXHkO1YvskF4Xt9hQdz4SwrH88u54jpfFcH1adtlRO/DU 35IT9HHnZBNnyKB5Cp6SYeXxsZ+/vJIEc9c3d/fsptgc8roZNyGGWgIcWAT2qyfBTcSZtbLjPsZN vswxFsVNvqxDP5SASGLchIXHnoWiTMTiJqYXALCHm3TpF3I2hcdNwh6wBna4yRXEuMkXCdhxIa++ KKCfrmaHh5Sp6Pdj3OTplKo8bnKt6SovQ4td0C11ub56ItxUoS2J0ICzWKGg947TKM6xT3gcpLv0 ItxUgR1i3ATPUSETnofv9HFTpV678D2963CT/ZXvB5zjnne4SLiQ1ufv9XsdbrL06PtWKOLOVJzX 1act9LjJts5zpZG4SdhW2h6Bm6rnw00k1PPOhUfiJjF5H4ebOMEAd2UfNw3LVFKx4awiUjbGTewI bolrosxiLn1uWN9xuKnFjRFwELhJ7yPcRIP1d4+b2FHZPQ+O6r2/HTcJh1DEElm9QpljbwNk4+xe 8lTW2y9ESC3qa3+/kDrLxSctdfk35ayx3n6hgrBdtkHFuMmXxLjJl8W4yZd5lGTw/djafUkSaIhw U6A1wk2hRQE3hZ4IuCmUHIubBLN43CTXjpuJ68ChHkVEsssx+BwqphhcRLES9kF9R56qM1HfIv9z XtP7wr34TcfBYhu5jnGT3FtE5Gvwd4KB5JqJxje9z6Fy1HS4SSi3dcuV51A93CS9TjKJJ8JNbLm1 cRKdVeaUOzYPasnQ6GK3dmB02Rw05EKbNrRkv33pl1c/fffDRdbBo2MITDyBmzGcnIPFwbWH0Tcw 7dX/8/2b//rliz59NrrJHQKNsVTQjEwr9uewRZmwbmsETSLV3HqiTuBVqeHcQdQQQHSMV6XivVsJ sGClhioO19A5KJCQJaw0hFLkOTsGxCfeL4IsTD+1JN+SrdGSC0T2NLDlAMXev0fR8L3jvNiaqo62 SAYaaRhBUxir7K2wRfWp0FJ+5dY6tcOv8rB/d4d48ew5Fi++LBYvviwSElPZ0ROp5ZJaKNP84JEo 8dlzYvEihsspfilFzyq8mHhNjhDq1HJfEosXXxaLF1/mhQlbw13tvgTVhv7TDD6d8zrQGosX2qgt 6sSLb3UnXnzJseJFWLsXL5btd2q53DshgqG5Ey91IWzf/YLQEZGk4qUZquVsk/bihSuvlktpT7xw 7wSKq8HdUbcXL/JNL15qR00nXqyAYo05MWYjq/s8j15nu9pTiRdWlAbAPY942S0g+rQMNec4vOlQ tRylM25er8oBJ//lVcfEN5Ppgl9H1Bmp9Rur9DsuRlT5fg+VJDPCDkeg9uEt3xfYhZZbysldI6rc Nz5e5B5OZLQpeGNXsv0SYyZS/PAqZ3u6ks1fJIKHdRxeZRTQtpHKKRt42ew2psp9c0iYcENM0wgq 940OzAt7CQL78Ia/2dOXsr9ZrEUjqny7p0o2o6QYDMZU+cO+Kgu0sVGjE0O/AzyeFcYJNq13/XAK yx1ODtLm4HyPLHehzGEPOxbuuWC5k6fY+xNZ7gqZCzhVkF/dU0y5stAY9KgMdNA0seUOBNGySVfA iHo8C1sgNTm7GZhCn0EgdpY7V4R6pZvVLe7Qmr3lTnCHfj+y3AU6pSr/pmtNVLnvGU8BKrLrA4s7 FNSO3aweezx9Fi1vSbP3TtdVy50tAWgojqzLvsez5ryF2HJXC+qywMQ+z3j0LXeSq6LzeNq7znJn 79XyRkXi8XTPO0sdsqJnubPf6yx3lh59X80ygd5guXPtcR5We+f14nGWOxlXVPsjLHd1z3L31/8H W3vi8QplbmRzdHJlYW0KZW5kb2JqCjM2IDAgb2JqCjkwMDMKZW5kb2JqCjM0IDAgb2JqCjw8IC9U eXBlIC9QYWdlIC9QYXJlbnQgMyAwIFIgL1Jlc291cmNlcyAzNyAwIFIgL0NvbnRlbnRzIDM1IDAg UiAvTWVkaWFCb3gKWzAgMCA1OTUuMjc1NiA4NDEuODg5OF0gL1JvdGF0ZSAwIC9UaHVtYiAzOCAw IFIgPj4KZW5kb2JqCjM3IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCAvSW1hZ2VCIC9J bWFnZUMgL0ltYWdlSSBdIC9Db2xvclNwYWNlIDw8IC9DczEgNyAwIFIKL0NzMyAyNiAwIFIgPj4g L0ZvbnQgPDwgL1RUMyAyNyAwIFIgL1RUMiAyMyAwIFIgL1RUMSA4IDAgUiA+PiAvWE9iamVjdCA8 PAovSW0zIDI0IDAgUiA+PiA+PgplbmRvYmoKMzggMCBvYmoKPDwgL0xlbmd0aCAzOSAwIFIgL1R5 cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAxODIgL0hlaWdodCAyNTYgL0NvbG9y U3BhY2UKNyAwIFIgL0JpdHNQZXJDb21wb25lbnQgOCAvRmlsdGVyIC9EQ1REZWNvZGUgPj4Kc3Ry ZWFtCv/Y/+AAEEpGSUYAAQEAAEgASAAA/+EATEV4aWYAAE1NACoAAAAIAAGHaQAEAAAAAQAAABoA AAAAAAOgAQADAAAAAQABAACgAgAEAAAAAQAAALagAwAEAAAAAQAAAQAAAAAA/+0AOFBob3Rvc2hv cCAzLjAAOEJJTQQEAAAAAAAAOEJJTQQlAAAAAAAQ1B2M2Y8AsgTpgAmY7PhCfv/AABEIAQAAtgMB IgACEQEDEQH/xAAfAAABBQEBAQEBAQAAAAAAAAAAAQIDBAUGBwgJCgv/xAC1EAACAQMDAgQDBQUE BAAAAX0BAgMABBEFEiExQQYTUWEHInEUMoGRoQgjQrHBFVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1 Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOk paanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4+fr/xAAf AQADAQEBAQEBAQEBAAAAAAAAAQIDBAUGBwgJCgv/xAC1EQACAQIEBAMEBwUEBAABAncAAQIDEQQF ITEGEkFRB2FxEyIygQgUQpGhscEJIzNS8BVictEKFiQ04SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdI SUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1 tre4ubrCw8TFxsfIycrS09TV1tfY2dri4+Tl5ufo6ery8/T19vf4+fr/2wBDAAICAgICAgMCAgMF AwMDBQYFBQUFBggGBgYGBggKCAgICAgICgoKCgoKCgoMDAwMDAwODg4ODg8PDw8PDw8PDw//2wBD AQICAgQEBAcEBAcQCwkLEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBD/3QAEAAz/2gAMAwEAAhEDEQA/AP5/6KKKACiiigAooooAKKKKACiiigAooooAKKKK ACv7UP2WP+TYvhD/ANif4f8A/TfBX8V9f2ofssf8mxfCH/sT/D//AKb4KAPeKKKKACiiigAooooA /it/ak/5Oa+Ln/Y36/8A+nCevCa92/ak/wCTmvi5/wBjfr//AKcJ68JoA//Q/n/ooooAKKKKACii igAooooAKKKKACiiigAooooAK/tQ/ZY/5Ni+EP8A2J/h/wD9N8FfxX1/ah+yx/ybF8If+xP8P/8A pvgoA94ooooAKKKKACiiigD+K39qT/k5r4uf9jfr/wD6cJ68Jr3b9qT/AJOa+Ln/AGN+v/8Apwnr wmgD/9H+f+iiigApy7edwJ9MHFNooGmOynofz/8ArUnHpSUUA2Lx6UcelJRQFxePSjj0pKUDJwTj 60Ag49KOPSjFGKADj0o49KMUYoAOPSv7S/2WlY/sxfCD+IDwh4eO3JXIFhBkZGT0r+LTFf2l/ssl j+zF8IFHyZ8IeHhuI3AA2EGTgHJoHG9z6C8y2/59f/Iz/wCFHmW3/Pr/AORn/wAKPsyf8/qf9+W/ +Ko+zJ/z+p/35b/4qg2u/wCrh5lt/wA+v/kZ/wDCjzLb/n1/8jP/AIUfZk/5/U/78t/8VR9mT/n9 T/vy3/xVAXf9XDzLb/n1/wDIz/4Uhe2x/wAev/kZ/wDCl+zJ/wA/qf8Aflv/AIqojBISwjuYyBwC Y2GeP96gV3/Vz+Kn9p9WX9pX4tK5yw8Xa8Dznn+0Ju5rwyvcv2nmZ/2lfiy7DDN4u14kYxgm/m7H mvDaDF7n/9L+f+lAHrikpQSOhoGhcD1FGB6ijc3qaNzepoHoGB6igqAAdwOe3P8AhRub1NG5vU0B dCfjR+NLub1NG5vU0BoAAP8AEB+dG0f3h+tG5vU0B2+v40DTQ7Cev+fyownr/n8qTef8k0bz/kmg q6Fwnr/n8qb8v+T/APWpd5/yTSbs9v50CbQhx2/z+lf2l/stMR+zF8IP4V/4RHw8C2C2AbCAE4HN fxaZHpX9p/7LH/JsXwh/7E/w/wD+m+Cgm+p79stf+fr/AMgvRstf+fr/AMgvUNFBXOuxNstf+fr/ AMgvRstf+fr/AMgvUNFAc67E2y1/5+v/ACC9IUtccXX/AJBeoqKA512P4qv2n2Zv2lvi0zjDHxdr xIxjn+0Ju1eGV7t+1J/yc18XP+xv1/8A9OE9eE0EM//T/n/ooooAKKKXI9KAEop27jGBSfhQNoB9 cUoC5G5sDvxSfhR+FA0H40fjR+FH4UCD8aPxo/Cj8KAD8aPxo/Cj8KAD8a/tJ/ZdcJ+zB8IGkYog 8IeHssvJwbCAHAIr+Lb8K/tM/ZZVv+GY/hA6HDL4Q8PEZGRxYQHpQVFq6ue8+dpH/P5N/wB8r/8A E0edpH/P5N/3yv8A8TVr7be+sf8A37/+vR9tvfWP/v3/APXoNeaP9f8ADFXztI/5/Jv++V/+Jo87 SP8An8m/75X/AOJq19tvfWP/AL9//Xo+23vrH/37/wDr0BzR/r/hir52kf8AP5N/3yv/AMTSGbSM H/TJv++V/wDiat/bb31j/wC/f/16Ptt76x/9+/8A69IOaP8AX/DH8UP7TzM37SvxZZ/vHxdrxP1+ 3zeleG17n+1Anl/tLfFqPOdvi7Xhn6ahNXhlMwluf//U/n/ooooAKKKKACiiigAooooAKKKKACii igAooooAK/tQ/ZY/5Ni+EP8A2J/h/wD9N8FfxX1/ah+yx/ybF8If+xP8P/8ApvgoA94ooooAKKKK ACiiigD+K39qT/k5r4uf9jfr/wD6cJ68Jr3b9qT/AJOa+Ln/AGN+v/8ApwnrwmgD/9X+f+iiigAo oooAKKKKACiiigAooooAKKKKACiiigAr+1D9lj/k2L4Q/wDYn+H/AP03wV/FfX9qH7LH/JsXwh/7 E/w//wCm+CgD3iiiigAooooAKKKKAP4rf2pP+Tmvi5/2N+v/APpwnrwmvdv2pP8Ak5r4uf8AY36/ /wCnCevCaAP/1v5/6KKKACiiigAopcjGMc+tKHZQQpIB9DQUkuo2in72PUn86Tcff86AaQ2inbj7 /nRuPv8AnQKw2inbj7/nRuPv+dAWG0U7cff86Nx9/wA6AsNr+039llsfsxfCBVBZj4Q8PgKOpJ0+ AV/FpuPv+df2l/srxof2Zfg95rME/wCES8Ok7SVP/HhAeq80FRSvqe//AGe8/wCfaT9P8aPs95/z 7Sfp/jWtjS/+e0v/AH9l/wAaMaX/AM9pf+/sv+NBdo+Zk/Z7z/n2k/T/ABo+z3n/AD7Sfp/jWtjS /wDntL/39l/xoxpf/PaX/v7L/jQFo+Zk/Z7z/n2k/T/GkMF4Bn7NJ+n+Na+NL/57S/8Af2X/ABqF jYksEaQgcZM0ozx9aAtE/iX/AGoWD/tMfFt16N4u14j8dQmrwuvb/wBpoY/aR+K4wVx4s13g5yP9 Pm655rxCgyktT//X/n/ooooAKUqykqwII4INJRQMXBowaSigBcGjBpKKAFwaMGkooAXBpQOCSefS m0UArDgoJAJwPXBo2+9NooHddh233r+0j9llyf2ZPg+hDKD4R8PLlRubBsIBwMGv4ta/tL/ZajVv 2Y/g+ecDwj4eJ2sUJxYQHqvIoKi1dXPon7FF/wA9Lj/v1/8AY0fYov8Anpcf9+v/ALGm+bb/AN2b /wACZf8A4qjzbf8Auzf+BMv/AMVQa+7/AFYd9ii/56XH/fr/AOxo+xRf89Lj/v1/9jTfNt/7s3/g TL/8VR5tv/dm/wDAmX/4qgPd/qw77FF/z0uP+/X/ANjUZsx83zTgDofL68f7lO823/uzf+BMv/xV RExOWy06g9ALiTpj3agG4f1Y/ij/AGnHaT9pP4sSMMF/Fuuk545N/NXh1e4ftOI0X7SfxYjbqni3 XQec8i/m7mvD6Dnlvof/0P5/6KKKACiiigAooooAKKKKACiiigAooooAKKKKACv7UP2WP+TYvhD/ ANif4f8A/TfBX8V9f2ofssf8mxfCH/sT/D//AKb4KAPeKKKKACiiigAooooA/it/ak/5Oa+Ln/Y3 6/8A+nCevCa92/ak/wCTmvi5/wBjfr//AKcJ68JoA//R/n/ooooAKKKKACiiigAooooAKKKKACii igAooooAK/tQ/ZY/5Ni+EP8A2J/h/wD9N8FfxX1/ah+yx/ybF8If+xP8P/8ApvgoA94ooooAKKKK ACiiigD+K39qT/k5r4uf9jfr/wD6cJ68Jr3b9qT/AJOa+Ln/AGN+v/8ApwnrwmgD/9L+f+iiigAo oooAKKKKACiiigAooooAKKKKACiiigAr+kT4G/8ABTv9lnwD8E/h94F8Q3urJqvhzw9pOm3Yj09n QXFnaRQyhW3fMu9Tg9xzX83dFAH9S/8Aw9n/AGQv+f7Wf/Ba/wD8XR/w9n/ZC/5/tZ/8Fr//ABdf y0UUAf1L/wDD2f8AZC/5/tZ/8Fr/APxdH/D2f9kL/n+1n/wWv/8AF1/LRRQB/Uv/AMPZ/wBkL/n+ 1n/wWv8A/F0f8PZ/2Qv+f7Wf/Ba//wAXX8tFFAHqPxw8WaR49+NPj/xz4fZ20vxF4g1XUrQyLsc2 93dyTRFl/hbawyOxry6iigD/0/5/6KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooA/9T+f+iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKAP/V/n/ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igD/1v5/6KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA/9kK ZW5kc3RyZWFtCmVuZG9iagozOSAwIG9iagozNzAwCmVuZG9iago0MSAwIG9iago8PCAvTGVuZ3Ro IDQyIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAHVXV1z28a5vuev2OmVM+Oi ABafuVNspXUnsX0i+pw5k8kFTEIWG5JQCNCu+uv7vIvdJQCCBBYURKSZqSmKhJ7dfb+/9g/2P+wP Flvc97j8x46ZHwaWH4QscrnlRI7Ddin7P7Zlf3uTO2yRM9uKvdh24uDwanZ4L18wHgeW6zgxcz3P sl3uMSfiFudhwPzYs2I/iOiZ99W/7vLQ8sMoYJ5rWx6PPP3RWfPPMxv/4c/8gb/vBASD/itfcjw+ 4DELI8eKYy9giw37YY7f2o4dzOYLhoXSx+U/8w3723zuMIfN79mrd9si3W3T4js2/xe7nQNeZXue CWBoW37kB0cIa7hmdVx/NQRUPbAZHZj478SOhb5lY7vd9i1jzS1rQHu7S+4LVvnfD3//yH5Kdl9S 9ibbbPbbVbFK88rv2fvsayrXM+u5wdX1CAI8tx7u+JYX+b5ez6xKAkfrYfWt3nxOd8y1ncBwy82I 1PfBYLajIUoqPUcDzBBQdc86aUBzTcgt39FcU8OjNmpW8soleOQZzrq5OPAt1wZtlkfYikfw7uzV M+ABVeWL2Vmp4gdW6Go8pVQ5SVJqp9jF2LBTJ/fKiyzuunbIwl7gGvx7sy4esv2XB1Y8rHK2zBb7 Tbot8AJMu83wIr1fbVOWbJ/Y3WO6WCVrTYfgXq07TgvHKh128q4L6Rj7Eddrkbx7+uDZK1PhaMSp LqSjBw3Yurdd6uRTnjItDvW2jaBTOOeWGwdeE2Zt2xoHfwlN9pcnIE7P4VFNCx/xSxPZRfzSie3A L0PAVZTaa/BMyv6+zj4na3az3Ky2q7zYJUW2Y1+T9R4MlBPH3K/SJUs+Q+uxRbZfL9nn9LuZkX1h xEJc6xa5vB4sZEoLRiykdQuPrZg3aKGLhWA4jMk4B1oYAm6f42RX90QGMFEhPhN2vy/2eL1N8Zt7 EAJ+tbFoBbP+5qTRcbtuAGsZAkouYDqn7VgBWf4tmrvJ74YnXN2fTm7X1Ee+jKfxnNDcDWSBxdjt bodz/EeyXa5X2y+GUI0YxYHh6jguPIM61utLccezIs7bjvIqRqEdwGFVcE6cJIDNKp6duRwxorKD HOmDrUFlc2iRVFDZg6Qylt0fDAfyo8YkO9jXcJ1DGA8t2Lvks3bwSPrlEHnrdfYt/35MvBww/Yic pxreq3NJEIdWFCqyrMG5BpcEUQwf060HQI5MryuxST9wDT7JGLups4WmvqQodqvP+yJld/+4+ekn mFiwtbb5agnFvGSbZA1dvBHK+kVML7W8qSjjAMEwO2rQQhdrlzGbMTk5gIkQ2a7HBuEj43udbr8U DyQu6Sfta9VCT8IWf83Sfz/u0lxYbNtRicD1LB47ek2ToYHQtcLQVaGUfgHRl6SBIfiyRZEW+Wuy vSlYkeD/t2NSrOPbVsi9kAV1tDVp3xBbpvEJI8PDgbfnRKHfBHTCKmpA+0+6y9hmvy5Wj+uUuMhx hbMyVuyb0gGuh7yAwfaZ+n9G26e8gyAAsFgzR+04r6K8caxx5HTETa6lvHuBa5CaVt6fPr69md+y DWRxgiTBtxXkd3JQ0WNyr/KVg/oCaqfdgD0q9bnctqIIEZEGoH7M26rtxtw+rjTbRLZPM6+HzKHd xSzNgxWqzXC7pGyZ6UTouTzUwboZgq/FohXeIYzYfY5AhDB4ksfHXZYshAH0l2KXJiJzOVaoSTte gVxQD9PGVPkZBUy4A7OWu+Cfth3usm+T3PD0DbFRtBOZjAa2c8LGdLPMVJ3i3vpe1fBcRdUhcGm7 Xdx7rOpGjugcuLcXvoZ0Ia223CXf/kJBkWWaL+Cdkvu5ZXm6KFbZlrns119+fBMGdvBb3eSayWqM 58qoBYiW2H7AUBQh9rkH05oqPTPGkAUaAZRf6DiTCRAHrmu5XOPpp4NHJkIdVhwEjuKKrUZCe84K eSokp6RMHFyZYYV2HNkowMEGcoeHru+jNsiht2BenyhBcSP4zE4AL2bIIfx88/+GkvxIcLagpoKi DtQI+CFuCtaSqK/OWrZrOS4iuQpQLe3apQ8RMCsSSCik+g2304z/fcdybMRJGyBriqghThVV1guy SkHZUa8mEkSdx0sEiFQ/HFMUn9luEDAHwVw7UlVlVKw2QrmDtmAdbsWuI+nnhOhRylnWqpmLHqNj OoieEpsRKcmQG7IZcO3aRRDsW6KysWxVF+fnu6T2BmytDCX//Oluzt5/mNejyaPGDr3ACnySKDXU NdZoksGovKp0tY0qGA+1n5VaSqQSZmeBvVDmPmjB1iXqqgkB4Ui1FnGUClGKRaS3tmy/TZDfWiRF unw9Kh1oGVku7uqKRdKBD43nwA2sEULXZr+UoBoEDiea56svWxjnyPIjQZDuvuL1zd17+hlh5Twt WJGxDDVwMsugP6QF27ikIEtF1fImQwtRBFk1VVoYAk6Vdj2p8q2y9lG4bXfSbfPHLeZRWsuX+Kdz 2LbFPVslj2pyv5et1s+b7V3N44eOFQUazwmLqYEsRDUPznG/WxVPyBCW6eGEvPFRI0E6RdMAff1N DNCTgfyrlOY1PMrKUCXMhlZG1cHqXeztI65sB/E0kx79wDUobk411arZoe68dDJEvyCzbt4YhO/f RQouQDQKGo602QOiVflqs1onOwpUlZyy2jyuV7B5iE8onIUPjmm5qyyDWtBkRCBscz9qUOdkbJ8h 4JS+o/4cCkY6cRw2gpGqNew0tRo5legssdzIZXBxqntZkzwNFmp3/U/jqUqe/uqER3D/49ZY5FUk oRtbIbrXanb2VGq3/F7gGscoJOFxd8kCOS0kgam7ZL9Fsdb6iVJbB9GT5yijH9W8Vs1ialWTETeu gy62uEkBk3C5/RZsXZIQblaG7iF4zjLljyPPULS1E4qnKoo2KVHFKt+QuVY2UCzgdj+N63FDIonI i1zbZMgAgSAbIc4pRl78FmydZLCFbw0ZXTI6WR7NJIW2NEeIt0LDIeeE8i0JXZ7yCfdBSX4ZcG0p Nl0kux119yBqTlbRmF09mj7LTZ8MfaJ4HCb7RCNCQ8Bt9nkBQxjdWsWOXuJs06/pTkkrUC/eIap9 TIqH12QQk/ZaUec4KoxJwo1LB8hSovWe+XJtUyEET7T8T5QQBoG72RfZNttk+5zdPeVFuqkePArW nkoqSZZLRIOR5F+nFBamsGGyBjFALIBKRqUF+Muii1wtbzK0EIWokp0qLQwBp0O9tcpyXaOlLRVh vpJw0EYMudYo0vqKVoSXoQW5vMnQQhhbHvl8VQumy0p4qZSBNwRcvl9oG2WEXm5deDQIHPr4S62V I2v5lCEBS9SYL7JHmb9AQEq5YdalBNmSVu9R6xG4lu2jaK+xvloQAKZXrXvPcMOrQQCEHwHquCql u75DZec9GkrgCRKeYZRME2h1gIxptOIoenIZUGxtwMNI8n4/s/YZeG0QaF1g4A1B3S6Ql5loA4G8 LZCvEaRPhtkXEfFH+u46BI9cThjELlMLrYnCo6hOI3CSUnnvQk7SubgwZ9BJcZWNVgsYrFtOVuyY 84FmzoCmRXGG8jGkpj1PVuzQA3uOl2oICzzgWFh0izWNx0c3LeZYGR2yOQ9WQfcrcWoba3PgQYm6 x8l+NZTF5kfbhtSn5jUPSqMOtJ+Io2EcFvvwmIrhHEhxYOKNmMPBkm8JCKV4QOH8hc77IKJxyZkP 0fGvliWppqlirq8LdT1VBSkpw34HsIIbnbPHDKUWn9FoRoMxkqqqxMwl86rnlh0/6PTZiUpT3TJQ WcdhPtyRMG7YIaR1DMn/eRgVTQ5W5PFQE4qRiscYmuT3dGeI/HkYl0M+2w6Ze3XObZJ4txU1hvKA ZosxSYK76KJ0uXt15eH5OGYU8FadpSOibFgI11ceErURTcItvgo9HtyrIahFZOcquDE/M8ZUTEiA Om5zPjqdO30ejoe5i/mfqKVuIO2nKo4Ne1mORbt+SbVwi7rotup0wkCtpYeCNi0mqmqI4c6qnuJS QTpNb9W1UTjoouxIITWSG6uL+/tbCOFgN5zsUFGVeQ3Q02M/F8nZOETjYQNpP/Yry/U/XUXEuT6N 6IL2G4T8cUmplwsH9w6jDTkjsgF7gqSBcGeEANGwDf657Ni/yhYfzPa69utH1Bb7WEaEnmGA2yAK 4Rgv4aHJv7nx5iQyhhHscSvwMByIo7DHp3bqcpT29UIomATOaSDZn8sKlqiNtBkF5w8RyquwluPY VkCl1HAvxbYbLaDsibgOcMIbolWvAdycqca2iB0P1epuDJU8ZIsxUhZFusUKFQmV+YByy1+4Txc9 5GFEoWy5kB7msKmb90zmsJo0VEHaP16lnZCrELbuhlbYJUdOj7BdndoYQtiq6O/JlESex0/VQ7Mv 3uYxlDJHRIqmN0JsWLGD+zKurZQpAhn96ZSyRG2k08opOpfMQBtkJPqh5aIHHcJ1CGg5//IqAusQ 8akjPyewTKMkz8PzsYv4aoxAb2OPzyG9jnRCpy23EdRpIu3n8dAYB5SobbeorxaDUFG/hlsdxLA1 ZXPiZ1hveizmVRJgqtlHHccJe0IkB56rFU0xJ6J/akJJd/znkIBpk4Nd9UywJ67CmNyT1aJqfwdb EmOoOEyuD2goLbdB6w4E39VVHK5mCsM/mduJgSUAbaTgdtm+oD6bxwyNfdT9VSPOAQOoFEvhBI9Z 6lQq1sFAMkztIwnXY99VMb6UAvfoCMmFPJPV2J8xCA8llleJ/8krGOQ6zI7iUJtXdj3hWCAtUFeO 0r3Vxa1PLQfTnfQ4RKtqB9OqI88K5ZNCo+HjgWxkyc1JmazLaxxkl2iKcSNYRU/sWe/zPJbEARDK GWMz/jPP2D4P5kO5D+b8moKm+cryPhvRjlVjtReTGQ4NtfcRwS5XcM5eUHOSrmLYHIRbDegJ662R 0UdLQTmqvLbHvUpkZvV7Go8r2bpNHQfBajumoqQalbSyv97ja8hdeMWW72HGU3+gD4Y7+jx852BY eByTpqvt6AliUJpO7i06SeoDIrvp4JlQx5hObFPUsoZ6VDo4N0/XiXEXYADXrcZRNTgNPqrbNWrf emmlfjWVWgnYSKzRfEOa9REFuNGgNGWFVhqhj/HwdznisUEw2Kw3iHyfOxqFh+OIMB5qmt2Ag8C9 T4tv2e53llSvd9MVpNCJVD2a4pypRDvdIgctxmTAKMWkGTHo1XEuVUBnd17VZqvVTYYUogAyD+xa TeJ1+cnPYBid2yxt/6A3zRwcgiWUFyjLiMthKLDRcczlmBQxzhdFjpigcWEp8bkl6JHxagmTOe8Q yhgR6zaLrJdYPi2Kqt5C75EeHE07ru2b1eFHaOR7h3E3Kd2BKliZ5fgXHaCX2g3nzlRfKtLAfE61 jToqXE+sOgdImSlnPcB+h9o5IcrxY5QoIEfdAHTagqpWzGO0Dbt9+27+4Zfv2S+3P3/431v2w+2P H365ZR8//fDTuzc383cf3o95wCrK2UB/7nxNCW4Yj6AYFgOaFY/U8Lzk8WrzAQVgrqfx9Dtdc51h tFcHndELXEPUibE3COwIS4CMhN1yZFmiSg1wQeLxXnbpX9ErWgo8aLvft9m3LaPxXwd5mMspmGPq OB1rV2uYjI5DUUHM/XphUteemtPnkft2Tnkc6HMIOOqUzBbZWl7zjbuJn2DP0thTNXhHUG5S9lIW q43oIkYjj4gfi+Kfy4OU55anbzNGa5/Y+8nQAse9u/5UaWEIuHc0wmSbirHclyS/zx2n7mLgdYQ1 1dOQoaOaOjp13QB0Qvc0oL3dJfeFitWzzwndLoiZRglNfACT4Frw2t0fwkWIPbccsndJM8O5PdZJ P7WkybAMUqeO59c8QjQ3TWKkGemcJrYuyT6H41+e76OQkhCHTWUpklMkTqUJgJdU7olRdxjMkI2q RFGRFXoo1ZMrmwwRIIIf4KaPMixwju/HNYExlcQJ4K7yGp5+bG882X6gxTkAGk0zx9AqMuTe3c5/ pJFFq4KuIFqsxKBXCKYF3YJKdEhS6gslGigXjNuK7vHBkYlS1SPIXZ8OUTq4URz3LkwyWIVbzozB wefNEcz4uE6hlGgoRtnlLghjDQqhI4e8KkeXLVcYT7SHtqqLr1HFk45bytVNhhRwhw7KHCdKCkPA YcYm9FQGlqcULh3xE4MGyna5cOtKk78UF6CYH/c7CI/dJtulr/EFlt6jW//i6Qhn7RVNCnJ1g0nh ZGZHeVS/MrTgsN+AZsnEHY5v7g61B3h1XLzC7t6w2jyKv8rMDvQH3fIccRdugC0yMC6PHNyg6/ps w1DJSa/RW75md2JKlPyejT9+4hkkfeh7M/G9DUM0FRmlwzP0rZOqWqIdMSYfuBEmw2G+0ozuWMLQ 5YAQyffEvUvivTXe89DxY+MuJqia2MMlfPQeRyDXxRXH6rv0XvN5a/aAeotfy608sUEQWlxskC99 ZiwIQWIsyUPBz0ws8PAz/jQtWPwesQtf/IyhLurz5e9rn38QW4v9QqoUq/bRhxdHIV3ihCIRtLlt jt9a4y3E/hFl0p9C9RTq0HBjWeDizqAQtVSVd1CiRvfe4FvqQ9gpGshKD9JvRTTFg1cejW5RXH6G N0pEs0C+sUD20kOGkEDKt9Z4CyXe3HH1W/SGE9I1yah2EU+uvCP+/IwepD5EdXQAWT6o/J5cSeXR cksOf16+sZjRQbrs2ykyPzpFzvHHHCpN3bDD6zW9xmm5HOSL33FMDaJPRZaHkjr5E92up16jQZy+ Iz6FigN8ET+VT8D3gph+IlbAKxA08Zp4DWLkoEZ6qPhZMp18gvwJz6bvCHbE3xTfoWdJNJUnAKl8 Nl4tQNTErMSjNlEUtj/y6RzUrWCgWzuKGMjLsT2SKrgyW37GUzlg+RkcPU4lINOvLEyirceo1JLZ iIQchF89HyY6XTXmBEpIaTZXKGrsJcUInoxqcbqIHNDq+sqOY/JcQP+0CvnPfEM1tBAnbA62Za/e olTOY6/W37GAvSpfw/H31evldyCJV9/jndkr2OG/sfk/y5BAKxawM/DQjW5HWDA1rYml4UPTIM1K 8P2/GdO6uwplbmRzdHJlYW0KZW5kb2JqCjQyIDAgb2JqCjUyNjkKZW5kb2JqCjQwIDAgb2JqCjw8 IC9UeXBlIC9QYWdlIC9QYXJlbnQgMyAwIFIgL1Jlc291cmNlcyA0MyAwIFIgL0NvbnRlbnRzIDQx IDAgUiAvTWVkaWFCb3gKWzAgMCA1OTUuMjc1NiA4NDEuODg5OF0gL1JvdGF0ZSAwIC9UaHVtYiA0 NCAwIFIgPj4KZW5kb2JqCjQzIDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xv clNwYWNlIDw8IC9DczEgNyAwIFIgPj4gL0ZvbnQgPDwgL1RUMiAyMyAwIFIKL1RUMSA4IDAgUiA+ PiA+PgplbmRvYmoKNDQgMCBvYmoKPDwgL0xlbmd0aCA0NSAwIFIgL1R5cGUgL1hPYmplY3QgL1N1 YnR5cGUgL0ltYWdlIC9XaWR0aCAxODIgL0hlaWdodCAyNTYgL0NvbG9yU3BhY2UKNyAwIFIgL0Jp dHNQZXJDb21wb25lbnQgOCAvRmlsdGVyIC9EQ1REZWNvZGUgPj4Kc3RyZWFtCv/Y/+AAEEpGSUYA AQEAAEgASAAA/+EATEV4aWYAAE1NACoAAAAIAAGHaQAEAAAAAQAAABoAAAAAAAOgAQADAAAAAQAB AACgAgAEAAAAAQAAALagAwAEAAAAAQAAAQAAAAAA/+0AOFBob3Rvc2hvcCAzLjAAOEJJTQQEAAAA AAAAOEJJTQQlAAAAAAAQ1B2M2Y8AsgTpgAmY7PhCfv/AABEIAQAAtgMBIgACEQEDEQH/xAAfAAAB BQEBAQEBAQAAAAAAAAAAAQIDBAUGBwgJCgv/xAC1EAACAQMDAgQDBQUEBAAAAX0BAgMABBEFEiEx QQYTUWEHInEUMoGRoQgjQrHBFVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJSlNU VVZXWFlaY2RlZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6 wsPExcbHyMnK0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4+fr/xAAfAQADAQEBAQEBAQEBAAAA AAAAAQIDBAUGBwgJCgv/xAC1EQACAQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFRB2FxEyIygQgU QpGhscEJIzNS8BVictEKFiQ04SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZn aGlqc3R1dnd4eXqCg4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS 09TV1tfY2dri4+Tl5ufo6ery8/T19vf4+fr/2wBDAAICAgICAgMCAgMFAwMDBQYFBQUFBggGBgYG BggKCAgICAgICgoKCgoKCgoMDAwMDAwODg4ODg8PDw8PDw8PDw//2wBDAQICAgQEBAcEBAcQCwkL EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBD/3QAEAAz/ 2gAMAwEAAhEDEQA/AP5/6KKKACiiigAooooAKKKKACiiigAooooAKKKKACv7UP2WP+TYvhD/ANif 4f8A/TfBX8V9f2ofssf8mxfCH/sT/D//AKb4KAPeKKKKACiiigAooooA/it/ak/5Oa+Ln/Y36/8A +nCevCa92/ak/wCTmvi5/wBjfr//AKcJ68JoA//Q/n/ooooAKKKKACiiigAooooAKKKKACiiigAo oooAK/tQ/ZY/5Ni+EP8A2J/h/wD9N8FfxX1/ah+yx/ybF8If+xP8P/8ApvgoA94ooooAKKKKACii igD+K39qT/k5r4uf9jfr/wD6cJ68Jr3b9qT/AJOa+Ln/AGN+v/8ApwnrwmgD/9H+f+iiigAooooA KKKKACiiigAooooAKKKKACiiigAr+1D9lj/k2L4Q/wDYn+H/AP03wV/FfX9qH7LH/JsXwh/7E/w/ /wCm+CgD3iiiigAooooAKKKKAP4rf2pP+Tmvi5/2N+v/APpwnrwmvdv2pP8Ak5r4uf8AY36//wCn CevCaAP/0v5/6KKKACiiigAooooAKKKKACiiigAooooAKKKKACv7UP2WP+TYvhD/ANif4f8A/TfB X8V9f2ofssf8mxfCH/sT/D//AKb4KAPeKKKKACiiigAooooA/it/ak/5Oa+Ln/Y36/8A+nCevCa9 2/ak/wCTmvi5/wBjfr//AKcJ68JoA//T/n/ooooAKKKKACiiigAooooAKKKKAFUgHJAb2P8A9alJ B6KB+dNooHcXPtRn2pKKAuLn2r+0v9lpCf2YvhAykEjwj4eYBxuXiwgPIyK/izr+1D9lj/k2L4Q/ 9if4f/8ATfBQCk1qj377Vcf887f/AL9H/wCKo+1XH/PO3/79H/4qoaKC/ayJvtVx/wA87f8A79H/ AOKo+1XH/PO3/wC/R/8AiqhooD2sib7Vcf8APO3/AO/R/wDiqDdXBGPLt/8Av0f/AIqoaKA9rI/i q/afTy/2lvi1HnO3xdrw/LUJq8Mr3b9qT/k5r4uf9jfr/wD6cJ68JoIbP//U/n/ooooAKKKKACii igAooooAKKKKACiiigAooooAK/tQ/ZY/5Ni+EP8A2J/h/wD9N8FfxX1/ah+yx/ybF8If+xP8P/8A pvgoA94ooooAKKKKACiiigD+K39qT/k5r4uf9jfr/wD6cJ68Jr3b9qT/AJOa+Ln/AGN+v/8Apwnr wmgD/9X+f+iiigAooooAKKKKACiiigAooooAKKKKACiiigAr+1D9lj/k2L4Q/wDYn+H/AP03wV/F fX9qH7LH/JsXwh/7E/w//wCm+CgD3iiiigAooooAKKKKAP4rf2pP+Tmvi5/2N+v/APpwnrwmvdv2 pP8Ak5r4uf8AY36//wCnCevCaAP/1v5/6cNuOabT1IA64/GgqO4YT1/z+VGE9f8AP5U7I/vH8/8A 61GR/eP5/wD1qC9BuE9f8/lRhPX/AD+VOyP7x/P/AOtRkf3j+f8A9agNBuE9f8/lRhPX/P5U7I/v H8//AK1GR/eP5/8A1qA0G4T1/wA/lRhPX/P5U7I/vH8//rUZH94/n/8AWoDQbhPX/P5UYT1/z+VO yP7x/P8A+tRkf3j+f/1qA0G4T1/z+VIQOxpxPo36n/Cmbm9TQS7CV/ah+yx/ybF8If8AsT/D/wD6 b4K/ivr+1D9lj/k2L4Q/9if4f/8ATfBQQe8UUUUAFFFFABRRRQB/Fb+1J/yc18XP+xv1/wD9OE9e E17t+1J/yc18XP8Asb9f/wDThPXhNAH/1/5/6cGIGKbRQNMfvP8Akmjef8k0yigfMx+8/wCSaN5/ yTTKKA5mP3n/ACTSFm9cU2igOZjtzepo3N6mm0UCux25vU0bm9TTaKAux25vU0m5vU0lFAXYV/ah +yx/ybF8If8AsT/D/wD6b4K/ivr+1D9lj/k2L4Q/9if4f/8ATfBQI94ooooAKKKKACiiigD+K39q T/k5r4uf9jfr/wD6cJ68Jr3b9qT/AJOa+Ln/AGN+v/8ApwnrwmgD/9D+f+iiigAooooAKKKKACii igAooooAKKKKACiiigAr+1D9lj/k2L4Q/wDYn+H/AP03wV/FfX9qH7LH/JsXwh/7E/w//wCm+CgD 3iiiigAooooAKKKKAP4rf2pP+Tmvi5/2N+v/APpwnrwmvdv2pP8Ak5r4uf8AY36//wCnCevCaAP/ 0f5/6KKKACiiigAooooAKKKKACiiigAooooAKKKKACv7UP2WP+TYvhD/ANif4f8A/TfBX8V9f2of ssf8mxfCH/sT/D//AKb4KAPeKKKKACiiigAooooA/it/ak/5Oa+Ln/Y36/8A+nCevCa92/ak/wCT mvi5/wBjfr//AKcJ68JoA//S/n/ooooAKKKKACiiigAooooAKKKKACiiigAooooAK/pE+Bv/AAU7 /ZZ8A/BP4feBfEN7qyar4c8PaTpt2I9PZ0FxZ2kUMoVt3zLvU4Pcc1/N3RQB/Uv/AMPZ/wBkL/n+ 1n/wWv8A/F0f8PZ/2Qv+f7Wf/Ba//wAXX8tFFAH9S/8Aw9n/AGQv+f7Wf/Ba/wD8XR/w9n/ZC/5/ tZ/8Fr//ABdfy0UUAf1L/wDD2f8AZC/5/tZ/8Fr/APxdH/D2f9kL/n+1n/wWv/8AF1/LRRQB6j8c PFmkePfjT4/8c+H2dtL8ReINV1K0Mi7HNvd3ck0RZf4W2sMjsa8uoooA/9P+f+iiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAP/U/n/ooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigD/1f5/6KKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooA/9b+f+iiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKAP/ZCmVuZHN0cmVhbQplbmRvYmoKNDUgMCBvYmoKMjk5OQpl bmRvYmoKNDcgMCBvYmoKPDwgL0xlbmd0aCA0OCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4K c3RyZWFtCngBvVVNj9MwEL37V7zjrrSatT3+vIJW4oIEUiQOiEMoLg2i6UciYPn1OG2UTcs2uwVK fLAVW543b+Y9b/AWG0Ria7ifZIT1jqzzCJpJBaWwTXiHGrcvG4VZA0nRRKmie1iJh3/NDBwdaaUi tDEkNRuowMTsHWw0FK0L3Z3zcXTNnqwPDkZLMhzMcFQch4fMI4fZ5PjKdTC6sV9yvt5xhA+KYjQO syVeFHlXKulEMUNOtDveT8USt0WhoFDMcQXgGsUX3BUZ2YiZf4TNBGKtpf8zcIuywceUajTrVLdo V/iWttX8Hu0ioarnq+2ybKtV3WUgnp/Bb8Xd0XOCXa1dro0aEhB7dic5vSSjmiWFwGEAdFa519vU ZCrTJyxS7rF2Ubb4XjaXBMzMpKMzx4APGBRHXXkmoHFFRSfXqYoOevFMVg16OcCDHo/oVfIXeHb2 ASme1q+zpKXRfUEfxbNTrbg6V7Njfno8maFmJib9xDry+hl4sotci7M85BSeaX/LZmIUh16Be3/D E/72KlXtzxukFuVXymY3+u5+rKssB7wu7+FvoKXyo91++f5N+TnBfrhogtbmx0dmjznM8HQHdIxf 0LUHhXCkyNlrHvG8/6lYxV0ndk/cBKAJyf4CoMO6XgplbmRzdHJlYW0KZW5kb2JqCjQ4IDAgb2Jq CjQ4MAplbmRvYmoKNDYgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAzIDAgUiAvUmVzb3Vy Y2VzIDQ5IDAgUiAvQ29udGVudHMgNDcgMCBSIC9NZWRpYUJveApbMCAwIDU5NS4yNzU2IDg0MS44 ODk4XSAvUm90YXRlIDAgL1RodW1iIDUwIDAgUiA+PgplbmRvYmoKNDkgMCBvYmoKPDwgL1Byb2NT ZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUiA+PiAvRm9udCA8PCAv VFQxIDggMCBSCj4+ID4+CmVuZG9iago1MCAwIG9iago8PCAvTGVuZ3RoIDUxIDAgUiAvVHlwZSAv WE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDE4MiAvSGVpZ2h0IDI1NiAvQ29sb3JTcGFj ZQo3IDAgUiAvQml0c1BlckNvbXBvbmVudCA4IC9GaWx0ZXIgL0RDVERlY29kZSA+PgpzdHJlYW0K /9j/4AAQSkZJRgABAQAASABIAAD/4QBMRXhpZgAATU0AKgAAAAgAAYdpAAQAAAABAAAAGgAAAAAA A6ABAAMAAAABAAEAAKACAAQAAAABAAAAtqADAAQAAAABAAABAAAAAAD/7QA4UGhvdG9zaG9wIDMu MAA4QklNBAQAAAAAAAA4QklNBCUAAAAAABDUHYzZjwCyBOmACZjs+EJ+/8AAEQgBAAC2AwEiAAIR AQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAAAAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAAB fQECAwAEEQUSITFBBhNRYQcicRQygZGhCCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5 OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeo qaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMB AQEBAQEBAQEAAAAAAAABAgMEBQYHCAkKC//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYS QVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNU VVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5 usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5+v/bAEMAAgICAgICAwICAwUDAwMF BgUFBQUGCAYGBgYGCAoICAgICAgKCgoKCgoKCgwMDAwMDA4ODg4ODw8PDw8PDw8PD//bAEMBAgIC BAQEBwQEBxALCQsQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEP/dAAQADP/aAAwDAQACEQMRAD8A/n/ooooAKKKKACiiigAooooAKKKKACiiigAooooAK/tQ /ZY/5Ni+EP8A2J/h/wD9N8FfxX1/ah+yx/ybF8If+xP8P/8ApvgoA94ooooAKKKKACiiigD+K39q T/k5r4uf9jfr/wD6cJ68Jr3b9qT/AJOa+Ln/AGN+v/8ApwnrwmgD/9D+f+iiigAooooAKKKKACii igAooooAKKKKACiiigAr+1D9lj/k2L4Q/wDYn+H/AP03wV/FfX9qH7LH/JsXwh/7E/w//wCm+CgD 3iiiigAooooAKKKKAP4rf2pP+Tmvi5/2N+v/APpwnrwmvdv2pP8Ak5r4uf8AY36//wCnCevCaAP/ 0f5/6KKKACiiigAooooAKKKKACiiigAooooAKKKKACv7UP2WP+TYvhD/ANif4f8A/TfBX8V9f2of ssf8mxfCH/sT/D//AKb4KAPeKKKKACiiigAooooA/it/ak/5Oa+Ln/Y36/8A+nCevCa92/ak/wCT mvi5/wBjfr//AKcJ68JoA//S/n/ooooAKKKKACiiigAooooAKKKKACiiigAooooAK/tQ/ZY/5Ni+ EP8A2J/h/wD9N8FfxX1/ah+yx/ybF8If+xP8P/8ApvgoA94ooooAKKKKACiiigD+K39qT/k5r4uf 9jfr/wD6cJ68Jr3b9qT/AJOa+Ln/AGN+v/8ApwnrwmgD/9P+f+iiigAooooAKKKKACiiigAooooA KKKKACiiigAr+1D9lj/k2L4Q/wDYn+H/AP03wV/FfX9qH7LH/JsXwh/7E/w//wCm+CgD3iiiigAo oooAKKKKAP4rf2pP+Tmvi5/2N+v/APpwnrwmvdv2pP8Ak5r4uf8AY36//wCnCevCaAP/1P5/6KKK ACiiigAooooAKKKKACiiigAooooAKKKKACv7UP2WP+TYvhD/ANif4f8A/TfBX8V9f2ofssf8mxfC H/sT/D//AKb4KAPeKKKKACiiigAooooA/it/ak/5Oa+Ln/Y36/8A+nCevCa92/ak/wCTmvi5/wBj fr//AKcJ68JoA//V/n/ooooAKKKKACiiigAooooAKKKKACiiigAooooAK/tQ/ZY/5Ni+EP8A2J/h /wD9N8FfxX1/ah+yx/ybF8If+xP8P/8ApvgoA94ooooAKKKKACiiigD+K39qT/k5r4uf9jfr/wD6 cJ68Jr3b9qT/AJOa+Ln/AGN+v/8ApwnrwmgD/9b+f+iiigAooooAKKKKACiiigAooooAKKKKACii igAr+1D9lj/k2L4Q/wDYn+H/AP03wV/FfX9qH7LH/JsXwh/7E/w//wCm+CgD3iiiigAooooAKKKK AP4rf2pP+Tmvi5/2N+v/APpwnrwmvdv2pP8Ak5r4uf8AY36//wCnCevCaAP/1/5/6KKKACiiigAo oooAKKKKACiiigAooooAKKKKACv7UP2WP+TYvhD/ANif4f8A/TfBX8V9f2ofssf8mxfCH/sT/D// AKb4KAPeKKKKACiiigAooooA/it/ak/5Oa+Ln/Y36/8A+nCevCa92/ak/wCTmvi5/wBjfr//AKcJ 68JoA//Q/n/ooooAKKKKACiiigAooooAKKKKACiiigAooooAK/tQ/ZY/5Ni+EP8A2J/h/wD9N8Ff xX1/ah+yx/ybF8If+xP8P/8ApvgoA94ooooAKKKKACiiigD+K39qT/k5r4uf9jfr/wD6cJ68Jr3b 9qT/AJOa+Ln/AGN+v/8ApwnrwmgD/9H+f+iiigAooooAKKKKACiiigAooooAKKKKACiiigAr+1D9 lj/k2L4Q/wDYn+H/AP03wV/FfX9qH7LH/JsXwh/7E/w//wCm+CgD3iiiigAooooAKKKKAP4rf2pP +Tmvi5/2N+v/APpwnrwmvdv2pP8Ak5r4uf8AY36//wCnCevCaAP/0v5/6KKKACiiigAooooAKKKK ACiiigAooooAKKKKACv6RPgb/wAFO/2WfAPwT+H3gXxDe6smq+HPD2k6bdiPT2dBcWdpFDKFbd8y 71OD3HNfzd0UAf1L/wDD2f8AZC/5/tZ/8Fr/APxdH/D2f9kL/n+1n/wWv/8AF1/LRRQB/Uv/AMPZ /wBkL/n+1n/wWv8A/F0f8PZ/2Qv+f7Wf/Ba//wAXX8tFFAH9S/8Aw9n/AGQv+f7Wf/Ba/wD8XR/w 9n/ZC/5/tZ/8Fr//ABdfy0UUAeo/HDxZpHj340+P/HPh9nbS/EXiDVdStDIuxzb3d3JNEWX+FtrD I7GvLqKKAP/T/n/ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igD/1P5/6KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA/9X+ f+iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAP/W/n/ooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigD/2QplbmRzdHJlYW0K ZW5kb2JqCjUxIDAgb2JqCjI2NjgKZW5kb2JqCjUzIDAgb2JqCjw8IC9MZW5ndGggNTQgMCBSIC9G aWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4Ac1ca1PbSBb97l9xaz4lVWyjVuuZT0syLGEq ryHeyW5NpraE3dgaZMnRA8L8+jmyLeFuHpaclSVIBYMNPn3vubfvq/sb/UrfyGfCtsTmi+GT7TrM dlzyTMG4xzmlkr5QTMdvMk6TjAzmW77Bfef+0ej+Z9mEhO8wk3OfTMtihiks4p5gQrgO2b7FfNvx yr95tf3upnCZ7XoOWabBLOFZ9UtH+tuTgU+8zTe8P3dKGOXn+qHAn3eET67Hme9bDk0W9HqMZw1u OKPxhLDQ8uWbL+MFHY/HnDiNr+jFeZzLNJb5Sxr/SadjwNsSz/8JoGsw27OdBwgVXCMV1z9aAtpW 2KhU2OrzCYm5NjMgbvNxkZEuMg3az2lwldPWx+uzT/QuSGeS3iSLRRGHeSizrefpQ3IjF5cyJdPg zstRK0lvL2zFxOcWJmwbNDZ4vbDRmguKpEmVNLWU9H7cdAWzec1NBY8m3rZ4tgW0U/O1rTg2Mw0w 4Bn5jNYW8iN4Ngob7bZd22GuWeNZ2+4DIkJzoy3bBcVa6q6VrCyPCdM0XHIbgdPUmBXLZRTKKV3e 0fnp+F80SeI8DS+LPEkzRjSehxnhX5zkFMIJxVO8NsiOKIintCiyvHzmMLayWd5gbAWCt7jwWvnx 9lxoZcf3XNgH3KVsydNW2GyXmaZrw5ur2HpzMg5njmeYlg7oCavWDAd2kuVpAWvIE7qUMAiaBHkQ JTNKrii4CcIouIwkhYtlJBcyzoM8xK9QklI+l2Haqc1YDnNsuPFK1IOxGeEzXwzVZvYBdyWDvEhl 6SovZDCVaUYBosJgehNma27AP0qoPMgpgeLTB4RYBHedcqGONTbLGw4XYH9lBN4mDj6Y/xR7gJPf wyxnXfrQ+4hYxdebD60DtTIhs2plKniqQPaggRq3mCeEwq3BxGlNsGm7zQk2jivsNNPgrtw+Mkk3 CMUQotE8uJG0TJNpMSkjs1jzL+WvIfHp1MMIwUzfwT66XthgHIzhoHzwgAOjR8m5ybMP5l8ewbar BvAgd33VpavhJsJbFyUWV4GqCE8jaadpTuVpHN9lnltpVYHTh6NxPB+pvKlWc4biaZqB07SYEL0J s0lC5x8/d0owgzPXtjzSUCoq1bB1yjCU4VBscG0dULN84D8XLYXVKsnn3Gacm76OTRFWP/znzPBq /j+KZ+VbRy9+RHnbJbXRc9VVxzWZ65pVxegJ3emS+qEKzQobakdPVo/qrLwZOI3zsMfT70G5h7er /YJfI6U2/lxF0kMRyXds8EuVn6JPDdiP6LNxBdBxLAQXtT4VPLoW2wtIbR6QsbsC6CCd8j2uVn0G 4+8bgdPUCH6dJXvRi76Mtlovz9JLoDEjPJc08Snq1HAdhl4WejtGrU4FTy/0QpJumDWep91XHwVm dK8agNPUCHq9Pr/4eR/bbMou12eWz7lFGkBFmxqsw7BLGAwhdFXiUPD0wi7TZKao8QyMXY3AaWoE uz4uZQz3tQfDmm+PyDmEgUYUOSpIRaMatMMwjMOzmuh9r3rJCpxeCGbYzLIqOAPjVxNsmg5Br+Ui mEza9t33jL0UhIoyNVwH4ZYN1nNhVKmtgqcPctkIUh27xjMsdjUDp6kR9Pq1CGazoP3u2Nx31aG9 BlHRpwbsMPzyDCYso0rVFDy98MvlzHNqPAPjVyNwmhrHc0lRkEt06dU2JMXydtXWz9Ngcl3Wjdt6 uFat33LYyrQwdWWrq1BUrmE/DAUdDH+hB/x8n0BH9kPVgp2Zb10tsPcBN8/z5avj46icc7qcLSf3 k04M42PH9Dv/o9MOlWnASZuQqIa+f1UjNzYcv0rcFTy9eBv06G2vxtPM2/hoM5+ffDjBBFucheg2 r4cKWm4frWyXY/oR45GYj1QBKwLULaQloFal0KoRYAuPma4/mOTKNn3mYrDzeV8CqvWRujcDp6lx xbR5kNECgw1la/E0SKM7OomiBKMumGZZ9SSxx9wEUSFJmPT1xUbzo4YDqtua367xPjpBi+khTFxx qhazaTQ+bTrbE7TvTi7OTv/35uP79//+cD7+79eXCkdHm0njp0dpWyEV1QCOBlUxmsrrVK1HBVA1 +vw0oFZWXBuNyZnl+TpHB9ETtR/BtqsnGsZlO5x+QgGAPgX5nE7y9fSizH6CxmYYyEjvqMDU4mrs Ci9M0vLxGaKi244Hb9BA9Szhgq4rmQ+lLW6jZGBgln577AYF7GFQ4BFsuyjwKU3yZJJEcD5gwdeX 4EEaLCTm5UGBWZoUy9Ws6mqG9Rajq2W4i5G9RXC9HsvqdDTCtNBXgcdar2swFDAshlCoyuzXDnSX nA81GmHvA+6TTBdBjCnLToNb34RF+9jnNIyKW9c20YPkMdbqWEutUAVPtc0ccvzK8lzmihrP0zv0 dizEDUS3CGzr8fMuN0SOd3PKZF+DqoiuF1WW3QzTq1JSBU8vqsSxIN+q8TRTZXtfsR1eNU+RrUbg NDWWVZGrBEHsbRjPaCkTDGjfH3vA7pCFszi8CidBnCPcxV5RhhjluQj4l03I2+mmYXPGDYw4Vasb yrZhOSZzhFul0MPaNvYCN00mRTmb3+kkXV2A1SAqpq1x9DC7hm0xjpONm1BQwdOLq7Fs7K/uMDNo qxE4TY2/JPOY3sogi+Rdp7tZNUunoVRUqmE7DMXK6pGzS6U6sgMVWJGctQf3YTyuzo+uiyBZp4qt pnA1rP0rtsxuvVqxCp5efAfOZtuuq2e11WnqDb5+im/lufGd2DQbOF3gANkrmsN3/DObp8UlziXf lSX8Ttlm+8wpO3IqYkW5Gs7DeBFuMsOvlKvA6YVrhmC4D0BNn3fNAHKO7OZkch0nt5Gczsqoo2PP gQsOOC4rsFS0ivT6UKbwbQzT1NJT8PShTaSpuI/BqRKuYSU4zcBpaiwTnKDI5+XxoNukiKYUhWWx q0xkgviaLnBqNZyhCvpbEl0f4dssoy/zMMch1pOJlJ3mNlVRtFrYUHIbpDW4+UBjwVBKYnuBexei 6r04os/zu2BBn2U+L1AXPaJfcD51Su+DYjLHN4mM6D0809sgWuKGEfxEXl2l8g4/wCn/TqlQpbnV 6oZDBQPnQOwqLRpWmitQ8WgN7qwor49Bm67L4KFOc/eCGBNajL/JaAon9D5IcfwI//8l8zw8otNp EaTThE6yiYzxzIUMcQEFnr/ulJ+1q9qIfDD8xMUFrjlUfu4D7vNknhSorh2hd1NE9DZJZlku0adb aTkP/4wJL1mE0/yIztDVg3OKr8MYJHgtU4wwxdNOiWBhahqXSpHYrG0wRLBx8NaqiaBEUlpIcJAw XWDMy8eFXUOpJwnhMMt+Hs8hz6YJeBRu2Ttz1NXYwqZd81aG+V9HJHMKImzT2x+n35chbp6AI7wj 96i8tMrdfnr9+PdPAS68cv7o1ECqKyY2CxyMfXCks04l797Mg4OGromb38TTeJ5JfP4G701S8Qpl bmRzdHJlYW0KZW5kb2JqCjU0IDAgb2JqCjI1OTEKZW5kb2JqCjUyIDAgb2JqCjw8IC9UeXBlIC9Q YWdlIC9QYXJlbnQgMyAwIFIgL1Jlc291cmNlcyA1NSAwIFIgL0NvbnRlbnRzIDUzIDAgUiAvTWVk aWFCb3gKWzAgMCA1OTUuMjc1NiA4NDEuODg5OF0gL1JvdGF0ZSAwIC9UaHVtYiA1NiAwIFIgPj4K ZW5kb2JqCjU1IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8 IC9DczEgNyAwIFIgPj4gL0ZvbnQgPDwgL1RUMSA4IDAgUgo+PiA+PgplbmRvYmoKNTYgMCBvYmoK PDwgL0xlbmd0aCA1NyAwIFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAx ODIgL0hlaWdodCAyNTYgL0NvbG9yU3BhY2UKNyAwIFIgL0JpdHNQZXJDb21wb25lbnQgOCAvRmls dGVyIC9EQ1REZWNvZGUgPj4Kc3RyZWFtCv/Y/+AAEEpGSUYAAQEAAEgASAAA/+EATEV4aWYAAE1N ACoAAAAIAAGHaQAEAAAAAQAAABoAAAAAAAOgAQADAAAAAQABAACgAgAEAAAAAQAAALagAwAEAAAA AQAAAQAAAAAA/+0AOFBob3Rvc2hvcCAzLjAAOEJJTQQEAAAAAAAAOEJJTQQlAAAAAAAQ1B2M2Y8A sgTpgAmY7PhCfv/AABEIAQAAtgMBIgACEQEDEQH/xAAfAAABBQEBAQEBAQAAAAAAAAAAAQIDBAUG BwgJCgv/xAC1EAACAQMDAgQDBQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEUMoGRoQgjQrHBFVLR 8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5 eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4eLj 5OXm5+jp6vHy8/T19vf4+fr/xAAfAQADAQEBAQEBAQEBAAAAAAAAAQIDBAUGBwgJCgv/xAC1EQAC AQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFRB2FxEyIygQgUQpGhscEJIzNS8BVictEKFiQ04SXx FxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqS k5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2dri4+Tl5ufo6ery8/T1 9vf4+fr/2wBDAAICAgICAgMCAgMFAwMDBQYFBQUFBggGBgYGBggKCAgICAgICgoKCgoKCgoMDAwM DAwODg4ODg8PDw8PDw8PDw//2wBDAQICAgQEBAcEBAcQCwkLEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBD/3QAEAAz/2gAMAwEAAhEDEQA/AP5/6KKKACii igAooooAKKKKACiiigAooooAKKKKACv7UP2WP+TYvhD/ANif4f8A/TfBX8V9f2ofssf8mxfCH/sT /D//AKb4KAPeKKKKACiiigAooooA/it/ak/5Oa+Ln/Y36/8A+nCevCa92/ak/wCTmvi5/wBjfr// AKcJ68JoA//Q/n/ooooAKKKKACiiigAooooAKKKKACiiigAooooAK/tQ/ZY/5Ni+EP8A2J/h/wD9 N8FfxX1/ah+yx/ybF8If+xP8P/8ApvgoA94ooooAKKKKACiiigD+K39qT/k5r4uf9jfr/wD6cJ68 Jr3b9qT/AJOa+Ln/AGN+v/8ApwnrwmgD/9H+f+iiigAooooAKKKKACiiigAooooAKKKKACiiigAr +1D9lj/k2L4Q/wDYn+H/AP03wV/FfX9qH7LH/JsXwh/7E/w//wCm+CgD3iiiigAooooAKKKKAP4r f2pP+Tmvi5/2N+v/APpwnrwmvdv2pP8Ak5r4uf8AY36//wCnCevCaAP/0v5/6KKKACiiigAooooA KKKKACiiigAooooAKKKKACv7UP2WP+TYvhD/ANif4f8A/TfBX8V9f2ofssf8mxfCH/sT/D//AKb4 KAPeKKKKACiiigAooooA/it/ak/5Oa+Ln/Y36/8A+nCevCa92/ak/wCTmvi5/wBjfr//AKcJ68Jo A//T/n/ooooAKKKKACiiigAooooAKKKKACiiigAooooAK/tQ/ZY/5Ni+EP8A2J/h/wD9N8FfxX1/ ah+yx/ybF8If+xP8P/8ApvgoA94ooooAKKKKACiiigD+K39qT/k5r4uf9jfr/wD6cJ68Jr3b9qT/ AJOa+Ln/AGN+v/8ApwnrwmgD/9T+f+iiigAooooAKKKKACiiigAooooAKKKKACiiigAr+1D9lj/k 2L4Q/wDYn+H/AP03wV/FfX9qH7LH/JsXwh/7E/w//wCm+CgD3iiiigAooooAKKKKAP4rf2pP+Tmv i5/2N+v/APpwnrwmvdv2pP8Ak5r4uf8AY36//wCnCevCaAP/1f5/6KKKACiiigAooooAKKKKACii igAooooAKKKKACv7UP2WP+TYvhD/ANif4f8A/TfBX8V9f2ofssf8mxfCH/sT/D//AKb4KAPeKKKK ACiiigAooooA/it/ak/5Oa+Ln/Y36/8A+nCevCa92/ak/wCTmvi5/wBjfr//AKcJ68JoA//W/n/o oooAKKKKACiiigAooooAKKKKACiiigAooooAK/tQ/ZY/5Ni+EP8A2J/h/wD9N8FfxX1/ah+yx/yb F8If+xP8P/8ApvgoA94ooooAKKKKACiiigD+K39qT/k5r4uf9jfr/wD6cJ68Jr3b9qT/AJOa+Ln/ AGN+v/8ApwnrwmgD/9f+f+iiigAooooAKKKKACiiigAooooAKKKKACiiigAr+1D9lj/k2L4Q/wDY n+H/AP03wV/FfX9qH7LH/JsXwh/7E/w//wCm+CgD3iiiigAooooAKKKKAP4rf2pP+Tmvi5/2N+v/ APpwnrwmvdv2pP8Ak5r4uf8AY36//wCnCevCaAP/0P5/6KKKACiiigAooooAKKKKACiiigAooooA KKKKACv7UP2WP+TYvhD/ANif4f8A/TfBX8V9f2ofssf8mxfCH/sT/D//AKb4KAPeKKKKACiiigAo oooA/it/ak/5Oa+Ln/Y36/8A+nCevCa92/ak/wCTmvi5/wBjfr//AKcJ68JoA//R/n/ooooAKKKK ACiiigAooooAKKKKACiiigAooooAK/tQ/ZY/5Ni+EP8A2J/h/wD9N8FfxX1/ah+yx/ybF8If+xP8 P/8ApvgoA94ooooAKKKKACiiigD+K39qT/k5r4uf9jfr/wD6cJ68Jr3b9qT/AJOa+Ln/AGN+v/8A pwnrwmgD/9L+f+iiigAooooAKKKKACiiigAooooAKKKKACiiigAr+kT4G/8ABTv9lnwD8E/h94F8 Q3urJqvhzw9pOm3Yj09nQXFnaRQyhW3fMu9Tg9xzX83dFAH9S/8Aw9n/AGQv+f7Wf/Ba/wD8XR/w 9n/ZC/5/tZ/8Fr//ABdfy0UUAf1L/wDD2f8AZC/5/tZ/8Fr/APxdH/D2f9kL/n+1n/wWv/8AF1/L RRQB/Uv/AMPZ/wBkL/n+1n/wWv8A/F0f8PZ/2Qv+f7Wf/Ba//wAXX8tFFAHqPxw8WaR49+NPj/xz 4fZ20vxF4g1XUrQyLsc293dyTRFl/hbawyOxry6iigD/0/5/6KKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooA/9T+f+iiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKAP/V/n/ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigD/1v5/6KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooA/9kKZW5kc3RyZWFtCmVuZG9iago1NyAwIG9iagoyNjY4CmVuZG9iago1OSAw IG9iago8PCAvTGVuZ3RoIDYwIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAHN XWtT20gW/e5fcStfdqbK2+j92NraKl4ZQkLCgGdSuzPzQdgNVrAlIskQ8uv3tF62hLHcmsgWVAUH Gzh9X3363tvXX+lX+kou001Dz78oLpm2xUzLJkfTmeqoKkWcPlNAB8exSuOYFOYarqK61vLRYPm9 eEy6azFNVV3SDIMpmm6Q6uhM122LTNdgrmk54nferv51TbeZaTsWGZrCDN0xypcO6n+eFHziz3zF 31ctAUN8Zg91/HpLd8l2VOa6hkXjOR2N8KyiKtZgNCYsVLw8/zKa08FopJJKo1v66V2Q8Cjgyc80 +kKnI8BbEc8PAmgrzHRM6wXCCq5BFdc/JQGtKmwgFJZ+viIx22QKxK2tFxnVRVaDdhJ5twmtfBz9 ckkfvOiO03E4ny8CP/F5nD0vuQopvWuQq2s6+vpVNCl+B/hcm1k27LGVYX4MH/n8hkekKarVpRh1 04TrK2od5ibrJElAUtZZ+rOtM1Mt/bmCh3JvGWRe/HfwpOGNlEFzfLFMpinwmiy+rMWTRpXBTz8A D/w3Hg82xjvTYrZW4sni3QvnrUuK/jY2SOpVWRkO0zVNscneClw9siwe/UefR0M68qLomT794yQM wkcvGNIv0Xd+F0bf6dwLwvj7vTekD34w8ehkEdx4+IkLLxqHPw+koviqWeZm8PrSsJcx23ARNPOl DZrsgKTtQCr+lX4CoRuq7kjtewh/kj4shW1pB23AnXiP/iSG0r1F5N3QlfeFfnvwJlPvGWo/57e3 NPKCJMaTQxrxRUC/+8H9kA4n3rxTC1BV7JuaQ3a+qN5YgO4yV++rBbQBBwvgwUMYJVDwlIeTEITw yIvHUw96vkSIoGMvmoV0PPXDiT+kj94N5zPwj/G9CB/vvKBTQzA07AQgu3a+tv4YgsosQb5lKPDO QoHeAtyJP773gzjEFoDIDxu4u+N4jKg/ho5XSfsgP9O8Ttqlwr1q28wwcRKyc9j71jGOZcwFbS8B SSn5AzzjKQwnEJ0IrvTWi+bCU668YPJMR4t4OqTP/lxIdLD9MUhKokui2ROJlhuoOPQaffWaNuDO eDDhEVzn25CuE34Lz7mcLe6G9N57pis+niZTX7jRVXhD14ipPizhMygXD+j9Yu5F/nA34TNf275d qzQE1WCOrlccC4R68DrVB8XbFZFag63pjPsLjxI6CWEJAXQ/moZzL6b36X8u/HsPG+bhTeRNvXmc BtjPPJ7xZ2EwfBounhAeOrWCkk9nK+uNESgWkmM9NYI12JqM4BoRHnxJhAHEATj9UeRN6CTifnzj jRH2cXJK/IAu/NksgMEMQaoiP07Chyl+7CKMovCpW0MoExDZ6vpiCBbyN47dT0NYh63JEM4R+4/C 6J4HUy8lUYdREM4m9NF/eBBU4DzkdBmFjyHotM9nMcjWfcqmj2AZ9JYHsI7dGEK+ut4YguMiQ6bJ JZZ3tS9YbcCNwjl44OwZwQBb/oU3mfjpDnA449+ycHH43Z+HjyJY+CAPgoWnL7jkSJcTMjKd7gzF 8apYW38MAQkAp7eG0ALcif8FB+rzxUxo+Zr7t+kGIMwDmhabg3h4PZ6GsxnyK9EXWMv/QgSCRz7D UeKKzzvOuRkWs0ykgC0cfoTke2MJtsZsWytywdvVmnYWEtqAg09jsw/zNBo4gIddQWj9fBHHPsxh loQz5NveR126vqabKBpaJln5GnKFNyS382IeWIuwY9SiMkILZnO/iPMswWDL0p7cmVbXmeZaRh3v xhNDJW1RlGJfT1tIJV6Lo4xlGQDWVwNtA+7MWyD/56dxx0ciMJqkJ5UANbIsJZTlNSLOJ3NRMbjK X3QGeotv/O0di9mK6yioM8MWdVW3NdNECVwV34KYX6m06qV9rFvyi2JNrR6CDDgPke1eazBZuuu1 2v1gtXb/ErmonS+RZygVnSxLQ5i1DUKGRlNg1lmJXVjglpX7F97TTmx5Sd/C0cB11Gppo0lqZwsc Xqq5wWYny3EPyoaHTfVzC4lMR9Hg9VV8Fa+v6XK9El/3+lVBNhb0LYupuubadUCvhM0atNswWmth Pwic7TLDVdXN0qqXKdcC2mzylXaV3OThoYWz1ky+tDAdG7lNGmqpLnpU8p6S7Q2+XXQ20Pmi1Oy6 6fy2M/rQBlwy5X5E8eIhK9ogZe/fTZPbxQx2jJLuE+FYQWO0h3AU7linFMIU2VzEMCtfR284I4pF ilYqfW/BoqQIusJs4ZerxaKm4KpqjMD7cU7gwZgX3KqTtilVUZltGg5ZVaD7F5yG8p9eCq6CZ6s4 tl1g3boxxVJ15mro01vpe3uhRwAbrPS9QY8qNPkxjOZe4j/yXekUG6bq2OD3FcwVEdZ2p043ztIX FJMZRiHCCpx9aNRE6lHVlWrGqUml8vuDFMcoWzq2A1fT4h9Xb49V17X/InG0DCaideOKIb8QeX6A x5d4LLaIEUNfz5DeiJ7Cspuwy+1CV0XvBLoIi2VJnTi7jYDoNWGOodslttzFK/ZZE/RO3MV0HORl muyzjgwGuvxYS/BeD4xSNAveoyto1aO1OJt41mGSRP7NIuFvYKJvj0mYLcrmn96RCnaI3h/7IDdm pMQWdzhtiJdY3abGi0RYsaK+kBrTUZhuKNKJsKUhyBpsW0togfPf0yR5+NfBwdPTE4tux12arIr8 gOJq6MSvCnSTq3faI65aDjMNE+37VUDbHSn5xE/CiIXR3YEf3IYHkJ5wo/+wLmWo4aTpWCJcViFv kqGs9UltmQW7MG0VwEonqeDZC72wcDUDCQwpxgiPlVSelKyW9GIrcLW9RdALcf0E9EKUt0Wlkq5B Kd68R0PDUxhNYkKWgxYxJ5S68eKYkpDeBRN/7CW8U36hGUx3VTLzZfUmcIOJK5ZbTa01bY0rUVve HFoG7jY4r/jXhR9xkWygD6JYFWMvPzq+JNXI9nRhK0Nhzl01u2lIyZmKCJ85/t7oHUzCdFrpXdL9 pfRdplRR7WuLTzpASSFckso2COv0MTXA9NLCNCOYpXBRpyrv573Oh1dja+PVBXEnTzPQr1wItzfG qDsMu3Y1BdXHINQG517YYxVohWnUtswdsccqoNbsUfjLrthjFfImGXbKiEr2qLmoTZROUsGzF/ao qcxw3H6Sx22w1RxBcEfLdnVwx9/DqUhM/crSXNQpQ65KtEmn2ajrrLaR8si34SItmXXGHly0FWgi YGfr2SJey7qz1N6H0mJ2lTXHU9F9U7z+NE66vV+9TOFVtF9xlJrOd+O4yHErKNBvzMvXgVUodkkK OriVvuQza2A26fRwgRJ7OA8XMV0/xwmf058/HV7/+TN9XKSXlq8fvHGRPxO+1W1yDH3DOPLjjJWt ZAtvkdW/lLeUgVsxGE5Y1Sx+k2Qr+u8U5tIA2uCsE9ouTXWZi2qDNLU/OuHj8j69lh79uhr3oJkI loowxyravccjI53RUbPHF1Wl/QektTib/GYfbLsGdJOCZbfn1fNdY/tP6R81QK3ZtnCZHbHtGuRN MpSNhlIyLII2yjvM1ksnqeDZB9s2RPuU5vQzV7sduFpEEXzbthQrLQULen2KRO3pBP9cjxcT3FVC z3HxnYsQfcheIkh5USF+32n3UDnloVhaX8iEIabdGDU7aAqKeyATrXBeIgmPVvM3V+gVi/mETnHp LKIzNATMcFsxPXKJhoDfLk8OR6d0weMYN5iQ0+00cV+UXIsV9cYS0KSLKlfvM/dGG5yIDSSCQ73g 3iW9RKcAJomhY7AV4iyYla0AmAthdksvi9xADW1lp6qF3N3snCbEiHlufT/vGutwNkXSvdDLKtBN Ct4RvawCak0vhYPvil5WIW+S4W6cxDDR0oVYkyWFKnj2Qi9xC18XsW9jkgrIas2jog34HTo7dtw+ WnTJoCluFXZFjHuJfaJTT1yc6YtaMVHTxLUGGa3KV/SlDlhlg4eY9tmIraZEcWYwdEvBmQHzDO5m aBEV7R0jXFIUd71O8Fh0j/6XoY/5foo7ynnS/vRbIkahTDolisUdr3xhveGJ6PFWcCeoZgNN00xW zgxdkq4y+2isgdm0G5edwZgzWm/XFGZSZ4+Z8XR8XMhnguXr6Y0VKLjg5Fgtk9BdWkA5hdZoDbFL eEsDbQPvLb+JFh5mWGqKOMxsoo8/eHCZhtsyjoM5YYVYt7BEWfooVQ4p73QXgCoRqcnV13SSCg/v lj7q5dm/qvu98wzdxf14pfTmCp590EckSjFz2+pndnI7cGuYhq0rgmmceR6GkJ5nzQD4cuFjJEY6 EwGJqphHj7g5FQYU3mLiAC4BLGuinbINU2WqgrFExeq2cG/Zk42UexeJc2SkMK65ZgpN3r1CNuTp pxTMMpy3wrmuyF30lCK8p1krGM1uWkqLFfRH8wqmBZjVxE8vNd8CZ73OLWJDOjFHbO1oJ16hIJjW /WNnkGq4MWw7GDmtI/kvJNwbjaNdFwMw+q/xNjhzrrai2G0acqWCkYp0gYG716S3AbjT+0g1hBXG Uds6ZVmkVPqgrHHXALVPQsKRu2WR5X2kGuRNMpTdqqVkWG7VGJGgGaX7VvDshUWiP93FG9Jsyp7t 8p0VMIEKs5+3wCMm/Hf5lgP5kBJxD1g1zN5Ef1yZtjCjSyaxdMb95PuQeELeDKnj1Y/Tbw+4qxPj MsQz4aItdlV79ens8R+XqPiS/Ven4sZVnfSdUERDKRbYH3mr4u2aihROxV1rIbjT8KHCLWxwEkyH eh3QVvFj+0E+YgzTAMO1VOTXTTREWwhdloJEO3LIiuOQKub24KZ3NrDn//BOZvEKZW5kc3RyZWFt CmVuZG9iago2MCAwIG9iagozNTg0CmVuZG9iago1OCAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFy ZW50IDMgMCBSIC9SZXNvdXJjZXMgNjEgMCBSIC9Db250ZW50cyA1OSAwIFIgL01lZGlhQm94Clsw IDAgNTk1LjI3NTYgODQxLjg4OThdIC9Sb3RhdGUgMCAvVGh1bWIgNjIgMCBSID4+CmVuZG9iago2 MSAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDcg MCBSID4+IC9Gb250IDw8IC9UVDEgOCAwIFIKPj4gPj4KZW5kb2JqCjYyIDAgb2JqCjw8IC9MZW5n dGggNjMgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMTgyIC9IZWln aHQgMjU2IC9Db2xvclNwYWNlCjcgMCBSIC9CaXRzUGVyQ29tcG9uZW50IDggL0ZpbHRlciAvRENU RGVjb2RlID4+CnN0cmVhbQr/2P/gABBKRklGAAEBAABIAEgAAP/hAExFeGlmAABNTQAqAAAACAAB h2kABAAAAAEAAAAaAAAAAAADoAEAAwAAAAEAAQAAoAIABAAAAAEAAAC2oAMABAAAAAEAAAEAAAAA AP/tADhQaG90b3Nob3AgMy4wADhCSU0EBAAAAAAAADhCSU0EJQAAAAAAENQdjNmPALIE6YAJmOz4 Qn7/wAARCAEAALYDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QA tRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJ ipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx 8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcF BAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygp KjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJma oqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9sA QwACAgICAgIDAgIDBQMDAwUGBQUFBQYIBgYGBgYICggICAgICAoKCgoKCgoKDAwMDAwMDg4ODg4P Dw8PDw8PDw8P/9sAQwECAgIEBAQHBAQHEAsJCxAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQ/90ABAAM/9oADAMBAAIRAxEAPwD+f+iiigAooooAKKKKACii igAooooAKKKKACiiigAr+1D9lj/k2L4Q/wDYn+H/AP03wV/FfX9qH7LH/JsXwh/7E/w//wCm+CgD 3iiiigAooooAKKKKAP4rf2pP+Tmvi5/2N+v/APpwnrwmvdv2pP8Ak5r4uf8AY36//wCnCevCaAP/ 0P5/6KKKACiiigAooooAKKKKACiiigAooooAKKKKACv7UP2WP+TYvhD/ANif4f8A/TfBX8V9f2of ssf8mxfCH/sT/D//AKb4KAPeKKKKACiiigAooooA/it/ak/5Oa+Ln/Y36/8A+nCevCa92/ak/wCT mvi5/wBjfr//AKcJ68JoA//R/n/ooooAKKKKACiiigAooooAKKKKACiiigAooooAK/tQ/ZY/5Ni+ EP8A2J/h/wD9N8FfxX1/ah+yx/ybF8If+xP8P/8ApvgoA94ooooAKKKKACiiigD+K39qT/k5r4uf 9jfr/wD6cJ68Jr3b9qT/AJOa+Ln/AGN+v/8ApwnrwmgD/9L+f+iilBI6GgBKKUknrSUAFFFFABRR RQAUUUUAFFFFABS4HqKSigYV/ah+yx/ybF8If+xP8P8A/pvgr+K+v7UP2WP+TYvhD/2J/h//ANN8 FAj3iiiigAooooAKKKKAP4rf2pP+Tmvi5/2N+v8A/pwnrwmvdv2pP+Tmvi5/2N+v/wDpwnrwmgD/ 0/5/6KKKACiiigAooooAKKKKACiiigAooooAKKKKACv7UP2WP+TYvhD/ANif4f8A/TfBX8V9f2of ssf8mxfCH/sT/D//AKb4KAPeKKKKACiiigAooooA/it/ak/5Oa+Ln/Y36/8A+nCevCa92/ak/wCT mvi5/wBjfr//AKcJ68JoA//U/n/ooooAKKKKACiiigAooooAKKKKACiiigAooooAK/tQ/ZY/5Ni+ EP8A2J/h/wD9N8FfxX1/ah+yx/ybF8If+xP8P/8ApvgoA94ooooAKKKKACiiigD+K39qT/k5r4uf 9jfr/wD6cJ68Jr3b9qT/AJOa+Ln/AGN+v/8ApwnrwmgD/9X+f+iiigAooooAKKKKACiiigAooooA KKKKACiiigAr+1D9lj/k2L4Q/wDYn+H/AP03wV/FfX9qH7LH/JsXwh/7E/w//wCm+CgD3iiiigAo oooAKKKKAP4rf2pP+Tmvi5/2N+v/APpwnrwmvdv2pP8Ak5r4uf8AY36//wCnCevCaAP/1v5/6KKK ACiiigAooooAKKKKACiiigAooooAKKKKACv7UP2WP+TYvhD/ANif4f8A/TfBX8V9f2ofssf8mxfC H/sT/D//AKb4KAPeKKKKACiiigAooooA/it/ak/5Oa+Ln/Y36/8A+nCevCa92/ak/wCTmvi5/wBj fr//AKcJ68JoA//X/n/ooooAKKKKACiiigAooooAKKKKACiiigAooooAK/tQ/ZY/5Ni+EP8A2J/h /wD9N8FfxX1/ah+yx/ybF8If+xP8P/8ApvgoA94ooooAKKKKACiiigD+K39qT/k5r4uf9jfr/wD6 cJ68Jr3b9qT/AJOa+Ln/AGN+v/8ApwnrwmgD/9D+f+iiigAooooAKKKKACiiigAooooAKKKKACii igAr+1D9lj/k2L4Q/wDYn+H/AP03wV/FfX9qH7LH/JsXwh/7E/w//wCm+CgD3iiiigAooooAKKKK AP4rf2pP+Tmvi5/2N+v/APpwnrwmvdv2pP8Ak5r4uf8AY36//wCnCevCaAP/0f5/6KKKACiiigAo oooAKKKKACiiigAooooAKKKKACv7UP2WP+TYvhD/ANif4f8A/TfBX8V9f2ofssf8mxfCH/sT/D// AKb4KAPeKKKKACiiigAooooA/it/ak/5Oa+Ln/Y36/8A+nCevCa92/ak/wCTmvi5/wBjfr//AKcJ 68JoA//S/n/ooooAKKKKACiiigAooooAKKKKACiiigAooooAK/pE+Bv/AAU7/ZZ8A/BP4feBfEN7 qyar4c8PaTpt2I9PZ0FxZ2kUMoVt3zLvU4Pcc1/N3RQB/Uv/AMPZ/wBkL/n+1n/wWv8A/F0f8PZ/ 2Qv+f7Wf/Ba//wAXX8tFFAH9S/8Aw9n/AGQv+f7Wf/Ba/wD8XR/w9n/ZC/5/tZ/8Fr//ABdfy0UU Af1L/wDD2f8AZC/5/tZ/8Fr/APxdH/D2f9kL/n+1n/wWv/8AF1/LRRQB6j8cPFmkePfjT4/8c+H2 dtL8ReINV1K0Mi7HNvd3ck0RZf4W2sMjsa8uoooA/9P+f+iiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKAP/U/n/ooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigD/1f5/6KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooA/9b+f+iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKAP/ZCmVuZHN0cmVhbQplbmRvYmoKNjMgMCBvYmoKMjY3NAplbmRvYmoKNjYgMCBv YmoKPDwgL0xlbmd0aCA2NyAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBzVxb c9NIFn73rzjFy0CVt6O+SqK2tjAJzCTsMhniKWqX4UFx5MTBlyDJsOyv3yPbEuqOLakNusQPceyU /fW59XdOn9Of4Q/4DD7hUvDdL8cH6SoilQse44R6lEIUwntYwslpTGESg0N84TvUV9+fDb6/Fk+A +4owSn1gQhCHcQHU44RzV4H0BfGl8tLPnBa/nXGXSNdTIJhDBPdE/q8D8+vBwQd+zWf8fqpSGOlj +5Tjxyvug+tR4vtCwWQBL8f4rkMdNRhPABea/vvu13gBJ+MxBQrjKTw9XyZhtAyTZzC+h1djhFcQ z08C6DpEelI9QqjhGui4/mYJqKiwQaqwzeOAxFxJHBQ32y8yMEVmQDuLgmkChZ+Xv17CP4PoNoTT 1WKxXs6SWRgX3oe3qy/h4jqMgDlUPRtYSbq4sI0lli2MS4lm7NB8YYOtLWiSBl3SYCnp42zT5UTS 3DY1PIZ4bfEUBVSp+dxXlCTMQQsokc9g6yE/gmensEG170pFXJbj2fruI0NEzQ0KvosmZqk7K1kJ j3DGHBfcWuAMNX549/rUFVJ8BDhbR8HyZggXZAiX4UM4X94Hn4Zwjn/i6/ArgbNVGM2Wt0N4kvrS 7w9hFDTqJpwT5iuRr2znJofFXgyZyWy1jC0Fb+c0uRfrgu/ea9AkBOWetsM8slLDEIqB0NpgreTm u4Q76NXg7sNZtROmpngVTtbRLPn2ZAgvTy+B+mIIaMf4gRKfnf1+DhQ3Xfx492Rn3sNG7VQwjFJI KrIF9Sacc5/43DCEKgF3YQjH4HwdXkfrIPqW7tZyCH+/S5KH5ycnX79+JdF0ojn+YMcjDxOlYsSt 3L4Zd4jnoVjdHe4a+rYlSlYexbhEDqtkDkjz/CqFhzezZBWRVXR7MltOVycovdSR/kE0GWZc/LAM rSBzoYiSyDQyGe7b4s0QZQmoqNT6lINTotLEoC+UI011RI7n8N7XCeWoBc5Q44ZyKMdFyvFmvQii 2RDeI8d4uY7vMIzjs6vJ3Ww+D6Mh/LbjHm8IXAZJOG82jFNJhCfRi3arquHWtszO0kd2GSMVxONc c2rczgca0TDTBS2MWzqOFcrv2/kemFWx58np6mY2nU2ClK3BagqjK0ycLqPVJIzjmQa7sSC+hW3F LZe3SD02jAPteKjB/MlxkvnIgVnKLTTpaqo3/MvWJo8Lk47C2swjm8yqF1t8JrAObHIPzCqbfMQf Ux3DaH27jpMt2cgVPqhVhSkKuJpcIClWvsB0bgu9L0FIoZ977iOF9y0I7YNZpfAy6viT3ZkqLDv6 zAcdZ5k72zLHorVVsh6qPCKFVAaeAyzD8Od9xBF9pVniyFyfeIq7BuIyCbYSEJXnY02PZWVdDU+2 N7dZqlJYZna8HM8BjXZUqqoHzjC3DW/0BUPeeHUXTqcpQfw32dSmRgReB1GEBBGenC8eotUXLFPB 6GsQhUskEimxeLdeLvHFRusAWUEoW15vYrfLiOuyrIy6tYWqqKht1rYudByDVMfgRAYZPofxXQio +Xm4CJfJlk1e4e91nBaLUnK5qxUxp1ELoOh0nHmQrcSKVcpGmSSnaTHI4zm2fRmu4XK2arfae7Ii v8I9kfmGdfawXLkXZ5UXbZIEDFp7ypKbVy/W800FSzWa2jJPEE6xQJStoTeRCUOm71G9VF0l0y4i 0zE4O+GVOlCNhhjO3RKx1AEd4CEGtH3MEt2lLWapQy6TYTsBUmADgpM7iYanE2qJZW+H5XgOqNSg lpQRTgD+fHdueyi32VQGhSaPsqN17ObwsUcD0wMdpCY0w9raUSIeGriU9qaurBgeWvEcTz0lYuTN ax/1OlCsGEF+lF0PnKHGD/Qj7A6B5mmbx/Xtw+R7owdpuHuG+j7qF+s2BvbuDY+iSzBsj9q0G2lw OgkeDlbZRQanntmN1sndKop/gdHNTYT5XGgbQqzSEYrnAJSmNRoNqiY5w/Qa9YqMJ0uswFHu9KbC ID2sVMocTz1VthVB6oEz1HgRfFpdw2/hLPkf/PV0S0L+emYZ8exsDXsLsfkQuw91YXZvbJ5DuHD0 kkGNpMxSWMdtD/IYcKezeLI6Dt4g7y8tox55/6QBr3tduhRLpn3V5THgqOvA+xCPY8ZBvAiWcBbN voSWurXzU4EixLM47EDWZNm9bhW2L3t91e0x4K5QnxfNOmrWVyyPwReHQzgdAfjSkaJRm+MMiRu2 GRkwu7c5zI8d5etFm97sDceA+/NqZKlJq41LYUsR+igODujgNE12QcaxAQt7/nNN7sWzmUAYPP0R ils89B6UzUZI7hE84MuS5MOUctPomx2n/VBSusGGnd8He7/zpLQeOINSvloEs/lzuL9LSeWLScpB CGalltZmt1dJrDRwzEQNwJp2DZg/ot3KQ+Y8gWGYIuPoS19SUckoNnz5ZXBaNX5M1B0cctom6j2z /TrYDJu6wFzqajm7vwmjuK10KqdpGt7uLd8R2NSDI2SlujXk11qqfAy4t+NxNka1bd5rtiTDcKIB q6cgdaydK1Zs5gl7qtijwOFB+upmFeHB+b+C+9U0/jSLkygIEhypcBrdtfDs3/dxuNJA3b2KPRe3 076q+Bhwo0WM06Q3wQJQqXgofPWfRhWb+S6O4xQF2b1isZNMMK+fJS5xDLi0CeZtmNyF0RzHpJqN yFmR3ADaA62mA9+5VjU8XaRYQjGC7YoVybJxWNrW1l8PnMFLspRmdf1imSSNn6vl4UMXpKZYA2Er 2QyOSBGK9wKUpQ9ZhmoZX4vFhV3uXD2bLIQknnBLs6s20xmRHm2oHE+/8pl64AyzehN+W0fbQSR7 hQ60eyrKzhHygRoDZPcWj67oeVUaNYTWWig7BtwoiibrGGfcl/rAaHXXP7roMRrVQfZAo3jnh+v2 JoRhk5DjZ3AOR4wuRh1FHWyG7e92yk9p3HiB/eloa60V/3S83VuawwneoZNVQDQ8XdAy7uPItFOO p83dEhNMTH9Vlozslc8GD2AlvsmraXa3FCFjxZtgFOtLozDH03XmyL1sy/C6VtgfxzMdl+3H04k9 S5wTFeV4WrVnvF/Lx8u7yraWVu2ZKyKkFL2xZ2QCVEizIFw6TrlpTBpCmEAwx1ba4s+r/z7MsDMO a3bfAIdV8UoMt/j29vmHywAvv/I+Nho/8IRzc7UVTsGkC+yNvHH6RWGta08XZJvhg6IZ4vUCPqTT OAfwlISP/wNfPBAACmVuZHN0cmVhbQplbmRvYmoKNjcgMCBvYmoKMjQxMQplbmRvYmoKNjQgMCBv YmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCA2NSAwIFIgL1Jlc291cmNlcyA2OCAwIFIgL0NvbnRl bnRzIDY2IDAgUiAvTWVkaWFCb3gKWzAgMCA1OTUuMjc1NiA4NDEuODg5OF0gL1JvdGF0ZSAwIC9U aHVtYiA2OSAwIFIgPj4KZW5kb2JqCjY4IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBd IC9Db2xvclNwYWNlIDw8IC9DczEgNyAwIFIgPj4gL0ZvbnQgPDwgL1RUMSA4IDAgUgo+PiA+Pgpl bmRvYmoKNjkgMCBvYmoKPDwgL0xlbmd0aCA3MCAwIFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUg L0ltYWdlIC9XaWR0aCAxODIgL0hlaWdodCAyNTYgL0NvbG9yU3BhY2UKNyAwIFIgL0JpdHNQZXJD b21wb25lbnQgOCAvRmlsdGVyIC9EQ1REZWNvZGUgPj4Kc3RyZWFtCv/Y/+AAEEpGSUYAAQEAAEgA SAAA/+EATEV4aWYAAE1NACoAAAAIAAGHaQAEAAAAAQAAABoAAAAAAAOgAQADAAAAAQABAACgAgAE AAAAAQAAALagAwAEAAAAAQAAAQAAAAAA/+0AOFBob3Rvc2hvcCAzLjAAOEJJTQQEAAAAAAAAOEJJ TQQlAAAAAAAQ1B2M2Y8AsgTpgAmY7PhCfv/AABEIAQAAtgMBIgACEQEDEQH/xAAfAAABBQEBAQEB AQAAAAAAAAAAAQIDBAUGBwgJCgv/xAC1EAACAQMDAgQDBQUEBAAAAX0BAgMABBEFEiExQQYTUWEH InEUMoGRoQgjQrHBFVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJSlNUVVZXWFla Y2RlZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbH yMnK0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4+fr/xAAfAQADAQEBAQEBAQEBAAAAAAAAAQID BAUGBwgJCgv/xAC1EQACAQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFRB2FxEyIygQgUQpGhscEJ IzNS8BVictEKFiQ04SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1 dnd4eXqCg4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY 2dri4+Tl5ufo6ery8/T19vf4+fr/2wBDAAICAgICAgMCAgMFAwMDBQYFBQUFBggGBgYGBggKCAgI CAgICgoKCgoKCgoMDAwMDAwODg4ODg8PDw8PDw8PDw//2wBDAQICAgQEBAcEBAcQCwkLEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBD/3QAEAAz/2gAMAwEA AhEDEQA/AP5/6KKKACiiigAooooAKKKKACiiigAooooAKKKKACv7UP2WP+TYvhD/ANif4f8A/TfB X8V9f2ofssf8mxfCH/sT/D//AKb4KAPeKKKKACiiigAooooA/it/ak/5Oa+Ln/Y36/8A+nCevCa9 2/ak/wCTmvi5/wBjfr//AKcJ68JoA//Q/n/ooooAKKKKACiiigAooooAKKKKACiiigAooooAK/tQ /ZY/5Ni+EP8A2J/h/wD9N8FfxX1/ah+yx/ybF8If+xP8P/8ApvgoA94ooooAKKKKACiiigD+K39q T/k5r4uf9jfr/wD6cJ68Jr3b9qT/AJOa+Ln/AGN+v/8ApwnrwmgD/9H+f+iiigAooooAKKKKACii igAooooAKKKKACiiigAr+1D9lj/k2L4Q/wDYn+H/AP03wV/FfX9qH7LH/JsXwh/7E/w//wCm+CgD 3iiiigAooooAKKKKAP4rf2pP+Tmvi5/2N+v/APpwnrwmvdv2pP8Ak5r4uf8AY36//wCnCevCaAP/ 0v5/6KKKACiiigAooooAKKKKACiiigAooooAKKKKACv7UP2WP+TYvhD/ANif4f8A/TfBX8V9f2of ssf8mxfCH/sT/D//AKb4KAPeKKKKACiiigAooooA/it/ak/5Oa+Ln/Y36/8A+nCevCa92/ak/wCT mvi5/wBjfr//AKcJ68JoA//T/n/ooooAKKKKACiiigAooooAKKKKACiiigAooooAK/tQ/ZY/5Ni+ EP8A2J/h/wD9N8FfxX1/ah+yx/ybF8If+xP8P/8ApvgoA94ooooAKKKKACiiigD+K39qT/k5r4uf 9jfr/wD6cJ68Jr3b9qT/AJOa+Ln/AGN+v/8ApwnrwmgD/9T+f+iiigAooooAKKKKACiiigAooooA KKKKACiiigAr+1D9lj/k2L4Q/wDYn+H/AP03wV/FfX9qH7LH/JsXwh/7E/w//wCm+CgD3iiiigAo oooAKKKKAP4rf2pP+Tmvi5/2N+v/APpwnrwmvdv2pP8Ak5r4uf8AY36//wCnCevCaAP/1f5/6KKK ACiiigAooooAKKKKACiiigAooooAKKKKACv7UP2WP+TYvhD/ANif4f8A/TfBX8V9f2ofssf8mxfC H/sT/D//AKb4KAPeKKKKACiiigAooooA/it/ak/5Oa+Ln/Y36/8A+nCevCa92/ak/wCTmvi5/wBj fr//AKcJ68JoA//W/n/ooooAKKKKACiiigAooooAKKKKACiiigAooooAK/tQ/ZY/5Ni+EP8A2J/h /wD9N8FfxX1/ah+yx/ybF8If+xP8P/8ApvgoA94ooooAKKKKACiiigD+K39qT/k5r4uf9jfr/wD6 cJ68Jr3b9qT/AJOa+Ln/AGN+v/8ApwnrwmgD/9f+f+iiigAooooAKKKKACiiigAooooAKKKKACii igAr+1D9lj/k2L4Q/wDYn+H/AP03wV/FfX9qH7LH/JsXwh/7E/w//wCm+CgD3iiiigAooooAKKKK AP4rf2pP+Tmvi5/2N+v/APpwnrwmvdv2pP8Ak5r4uf8AY36//wCnCevCaAP/0P5/6KKKACiiigAo oooAKKKKACiiigAooooAKKKKACv7UP2WP+TYvhD/ANif4f8A/TfBX8V9f2ofssf8mxfCH/sT/D// AKb4KAPeKKKKACiiigAooooA/it/ak/5Oa+Ln/Y36/8A+nCevCa92/ak/wCTmvi5/wBjfr//AKcJ 68JoA//R/n/ooooAKKKKACiiigAooooAKKKKACiiigAooooAK/tQ/ZY/5Ni+EP8A2J/h/wD9N8Ff xX1/ah+yx/ybF8If+xP8P/8ApvgoA94ooooAKKKKACiiigD+K39qT/k5r4uf9jfr/wD6cJ68Jr3b 9qT/AJOa+Ln/AGN+v/8ApwnrwmgD/9L+f+iiigAooooAKKKKACiiigAooooAKKKKACiiigAr+kT4 G/8ABTv9lnwD8E/h94F8Q3urJqvhzw9pOm3Yj09nQXFnaRQyhW3fMu9Tg9xzX83dFAH9S/8Aw9n/ AGQv+f7Wf/Ba/wD8XR/w9n/ZC/5/tZ/8Fr//ABdfy0UUAf1L/wDD2f8AZC/5/tZ/8Fr/APxdH/D2 f9kL/n+1n/wWv/8AF1/LRRQB/Uv/AMPZ/wBkL/n+1n/wWv8A/F0f8PZ/2Qv+f7Wf/Ba//wAXX8tF FAHqPxw8WaR49+NPj/xz4fZ20vxF4g1XUrQyLsc293dyTRFl/hbawyOxry6iigD/0/5/6KKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA/9T+f+iiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAP/V/n/ooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigD/1v5/6KKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooA/9kKZW5kc3RyZWFtCmVuZG9iago3MCAwIG9iagoy NjY4CmVuZG9iago3MiAwIG9iago8PCAvTGVuZ3RoIDczIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29k ZSA+PgpzdHJlYW0KeAHNW1tz2lYQftev2MdkJt2c+6VPaRJP43HipC2ddqbTBwVjV40RMZBL++u7 wqDoHIOQoEgyD8Y2Yz72+/Z69tzBT3AHHqVWcv2NedDWoDYWnJDIHecwn8BvkMPTFwsO4wUw9Moz 7s23Z8m33y3GIL1BwbkHoRQyIRVwJ1FKa0B7hV4bV/zP6+q7C2lRW2dACYZKOlW+NInfHhg96G3u 6P25KWAUj/unkv69kR6s4+i9MjCewvMR/ZVxZpLRGOiDFi9ffxtN4eloxIHD6BoenefLyTyfLB/D 6G84GxG8inn+J4CWoXbaPEAY4EpCXN+1BFQlLCkIWz12WMxqZGRusd1kEJssgvZynl4vofL1/Md3 8Dqd30zgxWw6/ZRny2yyqPwdLmefJ9P3kzkIxs3jpJWlqx9spcS6Dya1JhkzXn6w5F4LgaUhtDS0 tPRh2rQSNS+1GeCJzNsWT9VAe5kvfcVoFIwUUGOf5N5DjsGzJizZ77vaoBUlnnvffSBEYi6p+C5J rCV3rWylHEohmAXbCFxE4/lNni7geXpzNaMnLXG20hjnDI1h5M0hzv5FRhZUXLogID8gNbJbZ6Qe Au7s7lOWZ19bsrlSXVJJpnUhzHpUnnMFNgTYP5vSo5dDZfMQcK9nOTnnIWRCnpSVUS2ZZaIN8Q2A TI6mqNKqtdJgXFMeAO7Xi8OIXJW4e/OmtiiE1RRjQ2wBkZvCotPEWRTsqiRyK55VqZs8OiZZViuv pLYI5wqdlPW6ig11VB5fQaMKY2eN8S2PN8EWpaOzaZrdfg/Z+/tEjtlkef3spvgljmfTlpJrl9aL dobKdLAB7IDhCOwxDO91gbJ0ZIaaxw3DAZyY15bmqVZnjStH4y06WwunS/0b56kDEWET+iCwxobq yAGagYtE9cNVOoVfsunHRetc2U7vjKPVykGEMlBYhK0TwRtyROZKSgM8MZEnVTxVhtwYQQYKADVt lo7Dtoqw+2NsM2wRjZezD1l6GLyGddhmAhPBC7iMQHWjLSvQWrHpw3dQGSM7KlzsDfRlvjSHgDOM wZt0Pv4Lfp6lVy1JbRcwNn1vhLN/Uo1C4YdK6iHg3i6X6ZcU4G2+TOfZDC7EBYgzc1J2NUMrlQUT Au6fXZoxeseHOdUwh4B7kebp1Wnj76YPjvD1T6aiIwhWkhng6TS3r88w6ByDTk9KPDvyASHrYw7a DFyUrNYNFAlsihwX93Xks7zI+KfvoIpOxWiIgAcsR3C7yfqSYlsx4xvI9N0IgULW4+m0ieISvaCD x8pB3mB6qCbYIlFdZuMP8Cq7vc3S+WlLIurN6cSCFB+g7F/wTKNSewiNjNbVQYA5ANv55dnvLYuf 6nBjbwluDHIpPBU/AbiAxz7Sk6ZhC5ds/3Sjj/TUDFykMsWEhYssv1l8mc2uTt+zSEGRjYZ6EdiA 2QhiJylJO4dG72M2RtZRI3oQuJef3t9mOdBCSntPTYLdl7oTHi/QKS8FRBgHQChDSequT6K9EXoA uPOz9kSWS0x7Q255wqNdgC0gspeYazm64ni/pljssjjThva6XIlnd4uyWrPanIUdFSmaH/E0Axep ft2i5FSlPcvyyVc65GmptHZzqzIHhJYMlBZB7CYH0PCAGb+ZbAR4elG+oqVEV4+nU+VLh8L62rZt hQforPWUW27rYYEWHi1tPA5lyU0Ljsr5bYGqFzlTD8Rot7Umbm6iU0t3r9byjQ8qNVNIzrWpnbd6 V5dqVquN3QZ4OlKzcpYGvs4MRc2q2MQSbmve7UPOitaIvdqOp4/orIxAI21ttuhUz1ohp3XyOn/v Mjorpak1sIOJzoq27aWxW7NXL3oWDp3bjqcXPdMlBG3tXvl0tEiluEBGE6Ca7FWqme4uJM3vLmzJ XruXpzZbP4pJpKsag4nO0mukQdTWbNqHmilx0eUTWs6o4avLaoMCM104qMfTZXSWlL0E04OJztLQ tpHQbijVBm3UoVDb7dOLnukal6c7YoPRszSodD2eTvVM2YsrvTZPsyHIq0m2/PcJTJaQ3mL1fhTA 2deP2ZwuTb1p2Ym0GzxQzBQUEuR27MnulgQepf+AfVLc37Ih8OKnP96ldPfL/1liTxrdoWuXhzY3 u9bgB+O33NPlm40OAgvWuO1/R11JEQplbmRzdHJlYW0KZW5kb2JqCjczIDAgb2JqCjE2MDYKZW5k b2JqCjcxIDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgNjUgMCBSIC9SZXNvdXJjZXMgNzQg MCBSIC9Db250ZW50cyA3MiAwIFIgL01lZGlhQm94ClswIDAgNTk1LjI3NTYgODQxLjg4OThdIC9S b3RhdGUgMCAvVGh1bWIgNzUgMCBSID4+CmVuZG9iago3NCAwIG9iago8PCAvUHJvY1NldCBbIC9Q REYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDcgMCBSID4+IC9Gb250IDw8IC9UVDEgOCAw IFIKPj4gPj4KZW5kb2JqCjc1IDAgb2JqCjw8IC9MZW5ndGggNzYgMCBSIC9UeXBlIC9YT2JqZWN0 IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMTgyIC9IZWlnaHQgMjU2IC9Db2xvclNwYWNlCjcgMCBS IC9CaXRzUGVyQ29tcG9uZW50IDggL0ZpbHRlciAvRENURGVjb2RlID4+CnN0cmVhbQr/2P/gABBK RklGAAEBAABIAEgAAP/hAExFeGlmAABNTQAqAAAACAABh2kABAAAAAEAAAAaAAAAAAADoAEAAwAA AAEAAQAAoAIABAAAAAEAAAC2oAMABAAAAAEAAAEAAAAAAP/tADhQaG90b3Nob3AgMy4wADhCSU0E BAAAAAAAADhCSU0EJQAAAAAAENQdjNmPALIE6YAJmOz4Qn7/wAARCAEAALYDASIAAhEBAxEB/8QA HwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQR BRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdI SUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2 t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEB AQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMi MoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpj ZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbH yMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9sAQwACAgICAgIDAgIDBQMDAwUGBQUFBQYI BgYGBgYICggICAgICAoKCgoKCgoKDAwMDAwMDg4ODg4PDw8PDw8PDw8P/9sAQwECAgIEBAQHBAQH EAsJCxAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ/90A BAAM/9oADAMBAAIRAxEAPwD+f+iiigAooooAKKKKACiiigAooooAKKKKACiiigAr+1D9lj/k2L4Q /wDYn+H/AP03wV/FfX9qH7LH/JsXwh/7E/w//wCm+CgD3iiiigAooooAKKKKAP4rf2pP+Tmvi5/2 N+v/APpwnrwmvdv2pP8Ak5r4uf8AY36//wCnCevCaAP/0P5/6KKKACiiigAooooAKKKKACiiigAo oooAKKKKACv7UP2WP+TYvhD/ANif4f8A/TfBX8V9f2ofssf8mxfCH/sT/D//AKb4KAPeKKKKACii igAooooA/it/ak/5Oa+Ln/Y36/8A+nCevCa92/ak/wCTmvi5/wBjfr//AKcJ68JoA//R/n/ooooA KKKKACiiigAooooAKKKKACiiigAooooAK/tQ/ZY/5Ni+EP8A2J/h/wD9N8FfxX1/ah+yx/ybF8If +xP8P/8ApvgoA94ooooAKKKKACiiigD+K39qT/k5r4uf9jfr/wD6cJ68Jr3b9qT/AJOa+Ln/AGN+ v/8ApwnrwmgD/9L+f+iiigAooooAKKKKACiiigAooooAKKKKACiiigAr+1D9lj/k2L4Q/wDYn+H/ AP03wV/FfX9qH7LH/JsXwh/7E/w//wCm+CgD3iiiigAooooAKKKKAP4rf2pP+Tmvi5/2N+v/APpw nrwmvdv2pP8Ak5r4uf8AY36//wCnCevCaAP/0/5/6KKKACiiigAooooAKKKKACiiigAooooAKKKK ACv7UP2WP+TYvhD/ANif4f8A/TfBX8V9f2ofssf8mxfCH/sT/D//AKb4KAPeKKKKACiiigAooooA /it/ak/5Oa+Ln/Y36/8A+nCevCa92/ak/wCTmvi5/wBjfr//AKcJ68JoA//U/n/ooooAKKKKACii igAooooAKKKKACiiigAooooAK/tQ/ZY/5Ni+EP8A2J/h/wD9N8FfxX1/ah+yx/ybF8If+xP8P/8A pvgoA94ooooAKKKKACiiigD+K39qT/k5r4uf9jfr/wD6cJ68Jr3b9qT/AJOa+Ln/AGN+v/8Apwnr wmgD/9X+f+iiigAooooAKKKKACiiigAooooAKKKKACiiigAr+1D9lj/k2L4Q/wDYn+H/AP03wV/F fX9qH7LH/JsXwh/7E/w//wCm+CgD3iiiigAooooAKKKKAP4rf2pP+Tmvi5/2N+v/APpwnrwmvdv2 pP8Ak5r4uf8AY36//wCnCevCaAP/1v5/6KKKACiiigAooooAKKKKACiiigAooooAKKKKACv7UP2W P+TYvhD/ANif4f8A/TfBX8V9f2ofssf8mxfCH/sT/D//AKb4KAPeKKKKACiiigAooooA/it/ak/5 Oa+Ln/Y36/8A+nCevCa92/ak/wCTmvi5/wBjfr//AKcJ68JoA//X/n/ooooAKKKKACiiigAooooA KKKKACiiigAooooAK/tQ/ZY/5Ni+EP8A2J/h/wD9N8FfxX1/ah+yx/ybF8If+xP8P/8ApvgoA94o oooAKKKKACiiigD+K39qT/k5r4uf9jfr/wD6cJ68Jr3b9qT/AJOa+Ln/AGN+v/8ApwnrwmgD/9D+ f+iiigAooooAKKKKACiiigAooooAKKKKACiiigAr+1D9lj/k2L4Q/wDYn+H/AP03wV/FfX9qH7LH /JsXwh/7E/w//wCm+CgD3iiiigAooooAKKKKAP4rf2pP+Tmvi5/2N+v/APpwnrwmvdv2pP8Ak5r4 uf8AY36//wCnCevCaAP/0f5/6KKKACiiigAooooAKKKKACiiigAooooAKKKKACv7UP2WP+TYvhD/ ANif4f8A/TfBX8V9f2ofssf8mxfCH/sT/D//AKb4KAPeKKKKACiiigAooooA/it/ak/5Oa+Ln/Y3 6/8A+nCevCa92/ak/wCTmvi5/wBjfr//AKcJ68JoA//S/n/ooooAKKKKACiiigAooooAKKKKACii igAooooAK/pE+Bv/AAU7/ZZ8A/BP4feBfEN7qyar4c8PaTpt2I9PZ0FxZ2kUMoVt3zLvU4Pcc1/N 3RQB/Uv/AMPZ/wBkL/n+1n/wWv8A/F0f8PZ/2Qv+f7Wf/Ba//wAXX8tFFAH9S/8Aw9n/AGQv+f7W f/Ba/wD8XR/w9n/ZC/5/tZ/8Fr//ABdfy0UUAf1L/wDD2f8AZC/5/tZ/8Fr/APxdH/D2f9kL/n+1 n/wWv/8AF1/LRRQB6j8cPFmkePfjT4/8c+H2dtL8ReINV1K0Mi7HNvd3ck0RZf4W2sMjsa8uoooA /9P+f+iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAP/U/n/o oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigD/1f5/6KKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA/9b+f+iiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAP/ZCmVuZHN0cmVhbQplbmRvYmoK NzYgMCBvYmoKMjY2OAplbmRvYmoKNzggMCBvYmoKPDwgL0xlbmd0aCA3OSAwIFIgL0ZpbHRlciAv RmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBzVrfj9u4EX7XXzF9s4GcIoo/JPUtTdsrirui6bk4FLl7 ULxy1oVtbSzt9fLfd0iKlEWZtKT1AkGAtWLRw5khOd83w/kCH+ALFDHljHYfSQE8EzEXGeQpjUlO CJwr+BlO8PZ9Q2DbQBIXRUq4KPApZ5TQjEb4lDGeFDk0WxAiLqTEjItY4BMwQeJMAEljlktpO0jU Pxz7BYWkTP9fPmRpnFL12yLOCWfR9gh/2uCgJMkJbLZAMzW4+9gc4e1mwwBf7eAjrP5ZrvF59Vn9 rdaQwgrWwGFF1xF+/8c1MPPNR/VM1MhfL77/8xq+w5/pHx/Uj/VzqwbJ52j1sIZfYfN3+MtGuXBo A2EsZmh2xrUNoG24qjlqhZpLJTf/vS4tRZckSZG64tAlJKEjl0SuS75HjdEBtdJ+twYBK/0X58xg 9bfnNVBYNWoQmoiv9dDTOvKbSHFvoHkjpa7aCCS6YSNjNBZ5Qa7YmIj8to0Jf6usIER/pgkRaB7a lXBcc1xOlurPJBmsHG7cy93HSREXlE01a7B00QfcpRkegYTKk5HIg5Fyjo9EfpWm3dFgmdzeoohJ hnskkUdC/VHnAo+O531k3uujZX7fHa1eAk/zOCOXU5CYdfMYEXoKzmPUT55OPHN4hHCYnqQXYYYo EeqPEnFzgDXDRAClnzr/oym6GKGnmBMhGI8F6t9HCJIIuVXQdhleug99HLiOEKs3UDbQPlaB80bQ gQWjHDCgzZ/g6Vy3eH58h5kI9ATLs2XCt/UBDvvjvoV6B83+d/88KUbcVHA8UEMjQr4J+MRGZYrn dK7PAQKSCxJLAEGHLBFdb9uqbWBXn6Eqt4+wrY/H59O+/Qq/lYfnCrbl6VS3sI5860GpQOTKMFZ3 03exWgXXq7spQrwxu6ncygnrh7Kt4FPdPkKJqjyf/cvCchLnGMztdN3mDS3LdyFxeUwSjFaLfeeX LUOhSDLcQUPhIVUD62x3UIoewBA269RO3EFLRH9/qD+VB3j3cNyf9k17LlvcS3rzlKcHs6D+/ZOy OM04BvRu8m7/+L0UrQILSmkSI/0aifNsxw7rzXZUpwF+qLeuQf5VZnm3g4a+86sfpCp2kRMkPq+0 yEtEq/X0O4GkaSxYihF/KPzFXkD+jBjfbXWCOI//uo8hLF0cnCvsGvlBx66jC3YtcOkySSEWsGuB YXe4QK/DrtNXZNfGhjuxa0fct8GuHaVeyq4dcWjjvdh1MYtdO3p4zHoBu06Q/Uhqq2hnz40tLR29 d9i1eR9g12aI4q3jKUSexRTz6gC7tkN87No3wJhhI4Ca/hq7tiNms2uRZXGG+k8gKBfBy5fNC8Ev pXngDJygOIk3LhKtAAFTXh8ttDmAI/2FiCC4DtmvhQhYd6BLEYFlMRtA9ssQgXnqLfQ1EaGz4V6I MBT3jSDCUClP6JxcbxFDcXdABNEhwbx6i6OHx6zliCCwEJEHEGH8fogI9r0fEewQHyKwFGtLYUQw Q7yI4BlgEcFEAD8imBHzEQHzQIloMzM3f5DNWZxTgYUWsUTyz4/VCZ6b6gH2J2iO5QFLtTacO2U9 UuTIB7DQZma6maX1aQ6W9byohkkTl/HW1qjDFSh9Kqeh2iTRTv63PdTSH9Xpt/25Ph0v/IFE6LLM SXJZ2UrRH/00ka6yhy1QB7A6tc0bVUTTMAo/vvsPfKqgPHVllyYG2Dw+N2/8dRe8K4jTgg80kHV+ P8BGoRq5STwFJnC3V8Rx27TqwlXR0Y1y4/74dKiO6LCy3denBn78908bwK1a/0/5r36qdMGhraF5 qrb73dfei6qqhT71O9GWaBzdXuhEXmTq6iW8rRc58aroW07EWqes2O721eGhiQO7OpM3WSQDM8t9 uCsvMP3ua573TuPlbRuTyLQgjedosdzufUh+HdLGXpG0GRvuRNoccd8GaXOU8rCbyaTNEXc/0pbO S+MdPTxmLSdtHCtcijEpNjPOscfvh6TNvveTNjvEQ9rwdOE1a5C02SE+0uYbYEibjQBe0mZHzCZt HBNvNrhGnwDwIYZiSdsiye/gXD+3+9NneKoP++1XOJSnz8/l50pxCGRz0FRPpcLEBvBCpTr70Y8W WGTOsa3AaHKT1E2iEJxT5bGZ6OeHpd5jQ8kDlHbR1C/OXpj5FI0Ggp2aSvtYnvCW7IBkBEna7eV4 Ole7/e9Vg7Tkwb8UTN5GFzm2jgRMHGgybSkYUbeNM5ciUI/qnXdN9C0i8lQ3rfbGpwqvHCXjxRui XVud8Z7oh/KM2/i9uYCM/d6iGcNmB8x7+FAJ/7pN8xZFsVjB6bzl4SkuyASvGy6beXiqGPuQp+h4 e7OZh2O3iIxC/UJe4yndGZjQzKP5CBYanGYe3vGUyH4/oZkHpjXzGBs6rjUF7K60BtlmHkech6d0 Z6Z3SaCZJwo38wT6lWwzj6PUQhttM48jzsNTRjYGmnmwuBRhM09Cr143OFmubeYxenTbb2DWcNNd 5pjTm3k4TfVNnOUploeoTpvxe90EhwQAzysF+z7AU8wUlqc4U5Bc17cumnn0JLZXh5shXp4yGuDM YSJAz1PcKcyIEU+JZIwItPth66C+sdGlFH8olIUZ7218lsecojfBEadO181ujl9WOs08N9gGZ0tJ zqYiGLM548g6AhpPR3NTuGCYc6sbK6eUFATzaYULI7pPEidQwHc//eOXNXz811/fZ9gEgu2RXn+Y pNuZJryCXnG9P7ARoi82esBskFpgtA2C2eXdOcOkm+ha7OzOVIYWy6Xq/XkNzEZRzduZ6rspEa+Y dBsbrkVEo/mMzlRHnAfMhqEWm3UDYHaHzlRHqUHUNzbO6Ex1xHnAbGRjGMxkZ6oHzJwStgUzRw+P WYOTMaszVXYECcnVLJhZsFJgNn5vUUKBmX3vBzM7xIKZM4UkyJLJXoCZnsSCGaqih/jAzDfAJN02 AvRgNpqiixEjMFN9PAEwY5h0J6h/FyGWhkIDZo44P5jJVnjTC6bB7FA2LahYHojg6JIMozd6+y5q dw38DFPBCydM03oioi0RrbCMJkkIy/AyNGdCgKP70gU0nmBCXct322EilvkunRhell10lXGdfHUf uoEi65qd/9Av+of/A2rWeBsKZW5kc3RyZWFtCmVuZG9iago3OSAwIG9iagoyMzMyCmVuZG9iago3 NyAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDY1IDAgUiAvUmVzb3VyY2VzIDgwIDAgUiAv Q29udGVudHMgNzggMCBSIC9NZWRpYUJveApbMCAwIDU5NS4yNzU2IDg0MS44ODk4XSAvUm90YXRl IDAgL1RodW1iIDg1IDAgUiA+PgplbmRvYmoKODAgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9U ZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUiA+PiAvRm9udCA8PCAvVFQ3IDg0IDAgUgov VFQ1IDgyIDAgUiAvVFQ0IDgxIDAgUiA+PiA+PgplbmRvYmoKODUgMCBvYmoKPDwgL0xlbmd0aCA4 NiAwIFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAxODIgL0hlaWdodCAy NTYgL0NvbG9yU3BhY2UKNyAwIFIgL0JpdHNQZXJDb21wb25lbnQgOCAvRmlsdGVyIC9EQ1REZWNv ZGUgPj4Kc3RyZWFtCv/Y/+AAEEpGSUYAAQEAAEgASAAA/+EATEV4aWYAAE1NACoAAAAIAAGHaQAE AAAAAQAAABoAAAAAAAOgAQADAAAAAQABAACgAgAEAAAAAQAAALagAwAEAAAAAQAAAQAAAAAA/+0A OFBob3Rvc2hvcCAzLjAAOEJJTQQEAAAAAAAAOEJJTQQlAAAAAAAQ1B2M2Y8AsgTpgAmY7PhCfv/A ABEIAQAAtgMBIgACEQEDEQH/xAAfAAABBQEBAQEBAQAAAAAAAAAAAQIDBAUGBwgJCgv/xAC1EAAC AQMDAgQDBQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEUMoGRoQgjQrHBFVLR8CQzYnKCCQoWFxgZ GiUmJygpKjQ1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOU lZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T1 9vf4+fr/xAAfAQADAQEBAQEBAQEBAAAAAAAAAQIDBAUGBwgJCgv/xAC1EQACAQIEBAMEBwUEBAAB AncAAQIDEQQFITEGEkFRB2FxEyIygQgUQpGhscEJIzNS8BVictEKFiQ04SXxFxgZGiYnKCkqNTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqSk5SVlpeYmZqio6Sl pqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2dri4+Tl5ufo6ery8/T19vf4+fr/2wBDAAIC AgICAgMCAgMFAwMDBQYFBQUFBggGBgYGBggKCAgICAgICgoKCgoKCgoMDAwMDAwODg4ODg8PDw8P Dw8PDw//2wBDAQICAgQEBAcEBAcQCwkLEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBD/3QAEAAz/2gAMAwEAAhEDEQA/AP5/6KKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooA/9D+f+iiigD6M/Z0/Zf+Iv7T2s6xoXw6uNPt 7nRLeO5nOoTSQqUkfYNhjjkyc9cgV9af8OlP2n/+gj4a/wDA64/+Ra/PDwd8Q/Hvw9uLi78B+ItQ 8PT3iBJpLC5ktmkRTkKxjZSQDyAa7/8A4aY/aJ/6KZ4j/wDBrdf/ABypd+h62Fng1Be1T5vL/h0f aH/DpT9p/wD6CPhr/wADrj/5Fo/4dKftP/8AQR8Nf+B1x/8AItfF/wDw0x+0T/0UzxH/AODW6/8A jlH/AA0x+0T/ANFM8R/+DW6/+OUveOj2mXfyy/r/ALePtD/h0p+0/wD9BHw1/wCB1x/8i0f8OlP2 n/8AoI+Gv/A64/8AkWvi/wD4aY/aJ/6KZ4j/APBrdf8Axyj/AIaY/aJ/6KZ4j/8ABrdf/HKPeD2m Xfyy/r/t4+0P+HSn7T//AEEfDX/gdcf/ACLR/wAOlP2n/wDoI+Gv/A64/wDkWvi//hpj9on/AKKZ 4j/8Gt1/8co/4aY/aJ/6KZ4j/wDBrdf/AByj3g9pl38sv6/7ePtD/h0p+0//ANBHw1/4HXH/AMi0 f8OlP2n/APoI+Gv/AAOuP/kWvi//AIaY/aJ/6KZ4j/8ABrdf/HKP+GmP2if+imeI/wDwa3X/AMco 94PaZd/LL+v+3j7Q/wCHSn7T/wD0EfDX/gdcf/ItH/DpT9p//oI+Gv8AwOuP/kWvi/8A4aY/aJ/6 KZ4j/wDBrdf/AByj/hpj9on/AKKZ4j/8Gt1/8co94PaZd/LL+v8At4+0P+HSn7T/AP0EfDX/AIHX H/yLR/w6U/af/wCgj4a/8Drj/wCRa+L/APhpj9on/opniP8A8Gt1/wDHKP8Ahpj9on/opniP/wAG t1/8co94PaZd/LL+v+3j7Q/4dKftP/8AQR8Nf+B1x/8AItH/AA6U/af/AOgj4a/8Drj/AORa+L/+ GmP2if8AopniP/wa3X/xyj/hpj9on/opniP/AMGt1/8AHKPeD2mXfyy/r/t4+0P+HSn7T/8A0EfD X/gdcf8AyLR/w6U/af8A+gj4a/8AA64/+Ra+L/8Ahpj9on/opniP/wAGt1/8co/4aY/aJ/6KZ4j/ APBrdf8Axyj3g9pl38sv6/7eOG+JXgDW/hZ491z4deJHhl1Tw/dPaXLWzM8Jkj67GZVJHuVFcRWp reuax4l1a617xBezajqV65knubhzJLK56s7tksx7k8msuqR41dwc5On8N9PToFFFFMyP/9H+f+ii igAor66/ZG1n9ljRvEPiCX9qbSpdW0uS1iXTkiFyStxvJcn7NJGcbePmJHoK+7f+E6/4JB/9CZef 986p/wDJVS5eR6uGyv2kFP2kVfu0fixRX7T/APCdf8Eg/wDoTLz/AL51T/5Ko/4Tr/gkH/0Jl5/3 zqn/AMlUufyOj+xH/wA/Y/ej8WKK/af/AITr/gkH/wBCZef986p/8lUf8J1/wSD/AOhMvP8AvnVP /kqjn8g/sR/8/Y/ej8WKK/af/hOv+CQf/QmXn/fOqf8AyVR/wnX/AASD/wChMvP++dU/+SqOfyD+ xH/z9j96PxYor9p/+E6/4JB/9CZef986p/8AJVH/AAnX/BIP/oTLz/vnVP8A5Ko5/IP7Ef8Az9j9 6PxYor9p/wDhOv8AgkH/ANCZef8AfOqf/JVH/Cdf8Eg/+hMvP++dU/8Akqjn8g/sR/8AP2P3o/Fi iv2n/wCE6/4JB/8AQmXn/fOqf/JVH/Cdf8Eg/wDoTLz/AL51T/5Ko5/IP7Ef/P2P3o/Fiiv2n/4T r/gkH/0Jl5/3zqn/AMlUf8J1/wAEg/8AoTLz/vnVP/kqjn8g/sR/8/Y/ej8WKK/af/hOv+CQf/Qm Xn/fOqf/ACVR/wAJ1/wSD/6Ey8/751T/AOSqOfyD+xH/AM/Y/ej8WKK9L+Mdz8Prz4o+Jbv4UW5t fB8t5I2lxMJA0dqfuKfNLPkd9xJ9zXmlUmePXpck5QveztdbBRRRTMj/0v5/6KKKANvRPDPiPxLJ LD4c0q71WSABpFtIJJygPALCNWwD710X/Cq/ih/0J+sf+C+4/wDjdey/svftVeMP2Vtd1vX/AAfp Fhq8+u20dtKt/wCbsRI3Lgr5Tock+pr7P/4fCfHD/oS/Dv5Xn/x+pbfY9bDYbCygnUq2faz/AMmf mX/wqv4of9CfrH/gvuP/AI3R/wAKr+KH/Qn6x/4L7j/43X6af8PhPjh/0Jfh38rz/wCP0f8AD4T4 4f8AQl+HfyvP/j9K77G/1LBf8/8A8H/8ifmX/wAKr+KH/Qn6x/4L7j/43R/wqv4of9CfrH/gvuP/ AI3X6af8PhPjh/0Jfh38rz/4/R/w+E+OH/Ql+HfyvP8A4/Rd9g+pYL/n/wDg/wD5E/Mv/hVfxQ/6 E/WP/Bfcf/G6P+FV/FD/AKE/WP8AwX3H/wAbr9NP+Hwnxw/6Evw7+V5/8fo/4fCfHD/oS/Dv5Xn/ AMfou+wfUsF/z/8Awf8A8ifmX/wqv4of9CfrH/gvuP8A43R/wqv4of8AQn6x/wCC+4/+N1+mn/D4 T44f9CX4d/K8/wDj9H/D4T44f9CX4d/K8/8Aj9F32D6lgv8An/8Ag/8A5E/Mv/hVfxQ/6E/WP/Bf cf8Axuj/AIVX8UP+hP1j/wAF9x/8br9NP+Hwnxw/6Evw7+V5/wDH6P8Ah8J8cP8AoS/Dv5Xn/wAf ou+wfUsF/wA//wAH/wDIn5l/8Kr+KH/Qn6x/4L7j/wCN0f8ACq/ih/0J+sf+C+4/+N1+mn/D4T44 f9CX4d/K8/8Aj9H/AA+E+OH/AEJfh38rz/4/Rd9g+pYL/n/+D/8AkT8y/wDhVfxQ/wChP1j/AMF9 x/8AG6P+FV/FD/oT9Y/8F9x/8br9NP8Ah8J8cP8AoS/Dv5Xn/wAfo/4fCfHD/oS/Dv5Xn/x+i77B 9SwX/P8A/B//ACJ+Zf8Awqv4of8AQn6x/wCC+4/+N0f8Kr+KH/Qn6x/4L7j/AON1+mn/AA+E+OH/ AEJfh38rz/4/R/w+E+OH/Ql+HfyvP/j9F32D6lgv+f8A+D/+RPyZv9Pv9KvJdO1S2ls7qBtskMyN HIjejKwBB9iKqV6D8VviHqPxZ+I3iH4k6vaxWV74ju3vJoYN3lJJJywTcS23PTJJ9zXn1Ujx68Yq clB3V9H3QUUUUzI//9P+f+iiigAor65/ZI/ZSvP2rPEOv6BZ+JofDLaFaxXRkmtjciUSuU2gCSPB HXPNfdf/AA501z/oq9j/AOCt/wD5JqXJHoUcrr1IqcI6PzX+Z+LdFftJ/wAOdNc/6KvY/wDgrf8A +SaP+HOmuf8ARV7H/wAFb/8AyTRzI1/sXE/y/iv8z8W6K/aT/hzprn/RV7H/AMFb/wDyTR/w501z /oq9j/4K3/8AkmjmQf2Lif5fxX+Z+LdFftJ/w501z/oq9j/4K3/+SaP+HOmuf9FXsf8AwVv/APJN HMg/sXE/y/iv8z8W6K/aT/hzprn/AEVex/8ABW//AMk0f8OdNc/6KvY/+Ct//kmjmQf2Lif5fxX+ Z+LdFftJ/wAOdNc/6KvY/wDgrf8A+SaP+HOmuf8ARV7H/wAFb/8AyTRzIP7FxP8AL+K/zPxbor9p P+HOmuf9FXsf/BW//wAk0f8ADnTXP+ir2P8A4K3/APkmjmQf2Lif5fxX+Z+LdFftJ/w501z/AKKv Y/8Agrf/AOSaP+HOmuf9FXsf/BW//wAk0cyD+xcT/L+K/wAz8W6K/aT/AIc6a5/0Vex/8Fb/APyT R/w501z/AKKvY/8Agrf/AOSaOZB/YuJ/l/Ff5n4t0V6T8Yfh3J8Jfih4l+Gkt+uqP4cvZLNrpI/K WYx8bghZtoPpuNebVSZ51WlKE3CW60YUUUUGZ//U/n/ooooAmhuLi3JMErRFuu1iufyqf+0tR/5+ pf8Avtv8a92/Z9/Zn+Jf7S+satofw0+xG50WCO4n+2zmBfLkbYNpCtk57V9Uf8OpP2q/7uhf+DBv /jVS2j0sPRxTgnTvb1Pzh/tLUf8An6l/77b/ABo/tLUf+fqX/vtv8a/R7/h1J+1X/d0L/wAGDf8A xqj/AIdSftV/3dC/8GDf/GqLxNvq+N8/v/4J+cP9paj/AM/Uv/fbf40f2lqP/P1L/wB9t/jX6Pf8 OpP2q/7uhf8Agwb/AONUf8OpP2q/7uhf+DBv/jVF4h9Xxvn9/wDwT84f7S1H/n6l/wC+2/xo/tLU f+fqX/vtv8a/R7/h1J+1X/d0L/wYN/8AGqP+HUn7Vf8Ad0L/AMGDf/GqLxD6vjfP7/8Agn5w/wBp aj/z9S/99t/jR/aWo/8AP1L/AN9t/jX6Pf8ADqT9qv8Au6F/4MG/+NUf8OpP2q/7uhf+DBv/AI1R eIfV8b5/f/wT84f7S1H/AJ+pf++2/wAaP7S1H/n6l/77b/Gv0e/4dSftV/3dC/8ABg3/AMao/wCH Un7Vf93Qv/Bg3/xqi8Q+r43z+/8A4J+cP9paj/z9S/8Afbf40f2lqP8Az9S/99t/jX6Pf8OpP2q/ 7uhf+DBv/jVH/DqT9qv+7oX/AIMG/wDjVF4h9Xxvn9//AAT84f7S1H/n6l/77b/Gj+0tR/5+pf8A vtv8a/R7/h1J+1X/AHdC/wDBg3/xqj/h1J+1X/d0L/wYN/8AGqLxD6vjfP7/APgn5w/2lqP/AD9S /wDfbf40f2lqP/P1L/323+Nfo9/w6k/ar/u6F/4MG/8AjVH/AA6k/ar/ALuhf+DBv/jVF4h9Xxvn 9/8AwT815JZJnMkzl3PUsck49zTK7T4i+A9d+F/jnW/h74n8r+1dAuXtLnyHMkXmx/e2sQMj3xXF 1SPLqxlGbU9+vqFFFFBmf//V/n/ooooA7vwJ8UPiN8MLq6vvhz4l1Dw1cXyLHPJp9zJbPKinIVjG QSAecGvTP+Gtv2n/APoqviX/AMGlz/8AF12X7JHgP9mrx34g8QWv7SniibwvplraxPYSQ3CwNLOz kOpJilyAvPQfWvuv/hnj/glX/wBFcv8A/wAGKf8AyFUNxvqfQYHC4yVJSpVGo9rv9D84v+Gtv2n/ APoqviX/AMGlz/8AF0f8NbftP/8ARVfEv/g0uf8A4uv0d/4Z4/4JV/8ARXL/AP8ABin/AMhUf8M8 f8Eq/wDorl//AODFP/kKlzROv6lmH/P1/wDgUj84v+Gtv2n/APoqviX/AMGlz/8AF0f8NbftP/8A RVfEv/g0uf8A4uv0d/4Z4/4JV/8ARXL/AP8ABin/AMhUf8M8f8Eq/wDorl//AODFP/kKjmiH1LMP +fr/APApH5xf8NbftP8A/RVfEv8A4NLn/wCLo/4a2/af/wCiq+Jf/Bpc/wDxdfo7/wAM8f8ABKv/ AKK5f/8AgxT/AOQqP+GeP+CVf/RXL/8A8GKf/IVHNEPqWYf8/X/4FI/OL/hrb9p//oqviX/waXP/ AMXR/wANbftP/wDRVfEv/g0uf/i6/R3/AIZ4/wCCVf8A0Vy//wDBin/yFR/wzx/wSr/6K5f/APgx T/5Co5oh9SzD/n6//ApH5xf8NbftP/8ARVfEv/g0uf8A4uj/AIa2/af/AOiq+Jf/AAaXP/xdfo7/ AMM8f8Eq/wDorl//AODFP/kKj/hnj/glX/0Vy/8A/Bin/wAhUc0Q+pZh/wA/X/4FI/OL/hrb9p// AKKr4l/8Glz/APF0f8NbftP/APRVfEv/AINLn/4uv0d/4Z4/4JV/9Fcv/wDwYp/8hUf8M8f8Eq/+ iuX/AP4MU/8AkKjmiH1LMP8An6//AAKR+cX/AA1t+0//ANFV8S/+DS5/+Lo/4a2/af8A+iq+Jf8A waXP/wAXX6O/8M8f8Eq/+iuX/wD4MU/+QqP+GeP+CVf/AEVy/wD/AAYp/wDIVHNEPqWYf8/X/wCB SPzi/wCGtv2n/wDoqviX/wAGlz/8XR/w1t+0/wD9FV8S/wDg0uf/AIuv0d/4Z4/4JV/9Fcv/APwY p/8AIVH/AAzx/wAEq/8Aorl//wCDFP8A5Co5oh9SzD/n6/8AwKR+OfiDxDrnivWrzxH4lvptT1TU JDLcXVw5kmmkPV3c8sx7k8msevSvjFo/gXw/8UPEui/DK/bVPClneSR6bdM4kaa2H3HLhVBJHX5R 9BXmtWj5vFRnGrKM3dpu78wooopmB//W/n/ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigD/1/5/6KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooA/9D+f+iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKAP/R/n/ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igD/0v5/6KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA/9P+ f+iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAP/U/n/ooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigD/1f5/6KKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA/9b+f+iiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAP/ZCmVuZHN0cmVhbQplbmRvYmoKODYg MCBvYmoKNTg5NAplbmRvYmoKMyAwIG9iago8PCAvVHlwZSAvUGFnZXMgL1BhcmVudCA4NyAwIFIg L0NvdW50IDggL0tpZHMgWyAyIDAgUiAxMyAwIFIgMTkgMCBSIDM0IDAgUgo0MCAwIFIgNDYgMCBS IDUyIDAgUiA1OCAwIFIgXSA+PgplbmRvYmoKNjUgMCBvYmoKPDwgL1R5cGUgL1BhZ2VzIC9QYXJl bnQgODcgMCBSIC9Db3VudCAzIC9LaWRzIFsgNjQgMCBSIDcxIDAgUiA3NyAwIFIgXSA+PgplbmRv YmoKODcgMCBvYmoKPDwgL1R5cGUgL1BhZ2VzIC9NZWRpYUJveCBbMCAwIDYxMiA3OTJdIC9Db3Vu dCAxMSAvS2lkcyBbIDMgMCBSIDY1IDAgUiBdID4+CmVuZG9iago4OCAwIG9iago8PCAvVHlwZSAv Q2F0YWxvZyAvUGFnZXMgODcgMCBSIC9WZXJzaW9uIC8xLjQgPj4KZW5kb2JqCjggMCBvYmoKPDwg L1R5cGUgL0ZvbnQgL1N1YnR5cGUgL1RydWVUeXBlIC9CYXNlRm9udCAvWEhCU0dOK0NvdXJpZXJO ZXdQU01UIC9Gb250RGVzY3JpcHRvcgo4OSAwIFIgL0VuY29kaW5nIC9NYWNSb21hbkVuY29kaW5n IC9GaXJzdENoYXIgMzIgL0xhc3RDaGFyIDEyNCAvV2lkdGhzIFsgNjAwCjAgNjAwIDAgMCAwIDAg NjAwIDYwMCA2MDAgMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMAo2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCAwIDYwMCAwIDYwMCA2MDAgNjAwIDYwMCA2MDAg NjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAKNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCAwIDYwMAowIDYwMCAwIDYwMCA2MDAg NjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAKNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgMCA2MDAgXSA+PgplbmRvYmoK ODkgMCBvYmoKPDwgL1R5cGUgL0ZvbnREZXNjcmlwdG9yIC9Gb250TmFtZSAvWEhCU0dOK0NvdXJp ZXJOZXdQU01UIC9GbGFncyAzMiAvRm9udEJCb3gKWy0xMjIgLTY4MCA2MjIgMTAyMV0gL0l0YWxp Y0FuZ2xlIDAgL0FzY2VudCA4MzMgL0Rlc2NlbnQgLTMwMCAvQ2FwSGVpZ2h0IDU4NgovU3RlbVYg MCAvWEhlaWdodCA0MzggL01heFdpZHRoIDYwMCAvRm9udEZpbGUyIDkwIDAgUiA+PgplbmRvYmoK OTAgMCBvYmoKPDwgL0xlbmd0aCA5MSAwIFIgL0xlbmd0aDEgMzk3NDQgL0ZpbHRlciAvRmxhdGVE ZWNvZGUgPj4Kc3RyZWFtCngBlL0JYBRFvj9eVd0zmTPTc9/3lWRmcl9AQjqEgIJIUK4AIQEFRFFA 8D7AC+RQWK9VUcH11lVDAA2ggru6q+u63rqr7hP3IR67eD1kPcjM/1M9EyDovvf7Z6i7uru66vv9 1veqZvn5F8wjBrKSCEQ+49w5S4jy5zkFyZtnXLg8lC8bDIQUrZ+/ZMG5+bL1dkJUixYsumR+vux9 iZArV501b86Z+TI5grT+LFTky7QWaeysc5dfnC+7RULoSYsWn1Fo94ZQ/+C5cy4uPJ98iHLovDnn zsv33+RCWrJk8bLl+fKdHUhfWnL+vEJ/Op0Q3daQcThZ2YMLCymh6HUajZCTyTVERRiRSAWZQoiw WTWNiCjzdhUhZa89f2O3qek7jVaDCkLui09SxvWi/o17ckU/bhR/0qRQrVX68w64Tv3IwB2EiK/m inJvij8dbeGt/O+0XWRybq+wt29KjdyPZLiSbCuOVa9EcZveqKR92pqW1gphL1mC8CTCawgi6Ua8 olAjkCByLQi8dgOCSLYIu0kvwl6E1xF4zS7U7ELNLtTsQk2L0E+o8LTwVF8siBFs3+aOVX/V6hG2 kRwCE34lrCNh3Ht2Ie0upBuQlqF+YyG9QVjXNyJoatWiTMlXiHMIDO92V9/YidU7lUxDk5LZNFiz aRtqgq1u4S6M6i6M6i6M6i6M6ivEFHffhPpNqN+E+k1K/SZClVuFSwu3KmTu6jM5CjXItOqETmEq qcYtphfSacLUvurgntYeYQpu/aQSbxEmI79BibuVeKISr1BaVyj5xUp+sZJvUfIthTy/tkLJ5+Og kjfxWDhNOJ2U4umThHFK2iG0kzjKE1Hm6anCyUo6QRirpKeg3oX68UI7sSAdJ4xRyiejPBrlk1Dm 6VhhTN/oYGXrEpS70caISeD1ozGS0VjM0ZgkXrMBYQvCR0pNN+IVCK8hCEpPKozGrw2/VqEVV8i4 h4wWmQiCjF8LfiOFkWhpxts0I5aFJrxvEHEFQgvCRIRuhL0IryMUCU2IQ0IdqUSQEToQehBUuE8a 16UxrjSekBYyJIZ7hdl6YkMaKqRBto4EUA6wdX2BoNyqZdtJB0IPwhKElWx7n8piarWhH+9bgTAR oRthBcJmhCcRNKQFMVpkPWthLcJENlEQAd2l25qaqpW0pj6f+vz51OCpNrWeL5RimkrJZgQBQy7F kEvxqoOlIHIMoJMkexBeQ/gIgU94EpORxGQk8YJJXJ9UeqmVfl+hlEMQyGLEKxCO78OnJolXTuJZ x+7Ca0tQU4J7luCaEtyvBNP4EWKqXMHbOxA2IOxB4G0RtG1Q4hbEExEY7hHBG/CcCXFQiPQxrakf 80uHm1obMO8TEdDIbsBs3oB5u4FDCGYPsI2WlkKPDUifRFAJO/ErxS+JXwl+EfzC+IXwC+IXwOpt xG8DfjfidwN+6/Fbh9WwPZnak2LddYvrVtRtqNtc92Tdnrqi3WwOfj2sR9YRhwM00WLWeFolJpJZ xEh/VOLHlfh8JZaV2Cl7Zhn3zzK+NMt4xyzjrbOM02cZT51lHDPLWDHL2E/nys6U8YOUcWPKODVl rE8Z61LGmpSxNGVsNdNOOo0YyXNKPEqJq5U4osR+Oq3PSLTP0JkkrAHE0+T28FXBT8L9Iu0LXhPu 1yC5Ol+amU9G8MqngpXhBcF0viaRT2LhZ0XcgUyhvyVFNCWni14u6i6Si4YVlRdlikqKkkXRomCR TWPRSJpijUGj02g0ao2oYRqisfXn9snYTiixqSWeqPleSEQlLzGeR4SYMKphZBzptQrj2fjTR9Hx vXvPIOPnhnoPnx7tp7pJM3pV0VG01zKejJ88ytXbkBrfX5Q7rbcxNb5X2zFz+lZKb+xEqZdd30/J 5On9NMerrvP2Wtqm7ySUpq+7wVtIOzv5NdO3ivSGGzqJ48IWV4tlpHnYmNG/EPUolT2jU8f+XMey qRQfib/3tvGnT+991N/ZW80zOX/neMzz6aFZ03eyRlbfPnona+BJ5/SdupWssf00Xq9bORoDGexH QqgfvZOEeaL0IyHej4RO6BdgDbxfnCf5fgGlX2BIv63N4fbRW8OI8n2alT7NQ/ssGNpngdJnQaGP oIxfucXgfYr2kbDSJ1y0Txn78X0C+Wf9r33iv9jnuOmcN+q4ws+ydCcZR9/d2nZp+7xoe0+0fR5C T++6C89y9a6cGwrtJG30Xd4U6hUSPXPPOIunc+b103ej80b3tkVHh7aOUy4d2t57KW8eFx29lVza Pnn61kvleaP7xsnj2qNzRnduGzun7PEhj1sz+LitZXN+/rDeOfxmZfxZY5XrTnjW47x5LH/W4/xZ j/NnjZXHKs9SoB5gqSGjOttm5dNtTK8DAPd4w52jHNKSkQo0jwi7rvTuEgl9mOhTnb2G6KheIwIH 9ExrppU3Act4UzGqTYUm15Ujwt5d9OFCk4Rqc3QUcbUvHI1/y5YVMvni/xkvW7Zs+exls5EsW678 W7b8AqR8zcgyAs4Vb9BqUPa3IKgxp83rENYrNFpYtqxzOVHWd9kFhD99OY+OPvRY7gLcnC47HhII f+SQP7TSFMkH3G7ZBRRj4MO4IH8dXUbRiNvg0uWFOtAc8VOEm4gXaUCYix2b5D4qhH9kr8y3Zwdy OfYeOk8uBCRKbjK5FXX40Qn5lJxJ3ibnkl+RX6Ouhv6FPEJkYkLb20SgBBx7E7mZXETeIVNy36A2 TO4jX5E0GUbOymWJmawgWXoFuY8yPlOkkbxF5pGNrElIif8EcSyjlcJj9GqSwV0mk9uIk7yGO5bl dChvY37WhKsmk1eEbk06V5n7lu4VX87NJb+hTexd8QnyZ3KQRkSSvSa3LrcpdxcpJocE/8Dvc1W5 c3HVFNJDLiCXYwQryT3kVdrJmtme3BqMaTrGsII8TV6hKQBUDzi609D7WnI72UmeI6+Rv5JPKKUm WkJX0rfo2yoy8EL2hdzJubm5xaSdnEo6yEq0+mmctrIZwgzhceG9gf/O7ssFcO/J5EJyMbmMbCAb yWPkPfI38gEVmI5NZlOEx4mXNJMZZC5m82aM6RHyMvmIamgtHU5luor+ll0oCgMvYIcXiR0zeBLu dib6bsKcPkCeJC+Q18kbuOc3mFOBurH4U+gsegW9jt5Ib6EP0N/SJ+g/mYr9VRCEq8Q/iP/MvpvT 5e7MPYLneomPhMDrprEGp2A9XyVf4P3KaJq20DdZiqUFKhoGstma3NjcityLufdIlCTRtxl8bTuZ QKZh1JdA/tpN/oBrXyV/IQfIvzFLAtVRC+YiRKP0NHo6vQCjeJx+RQeYA+vXyBaxPva2kBJeFaeJ Twxsz9qzfdmvsrncY7ne3O9zf1bWtx7PacMKdJElQDG+YjvwnBfJfvI5+Q7PUNMgxnoSHY/3vR33 /4geAThp2JXstywH7nej8LLoFm/Pnpo9N3t7dluuNjcBsCWA6XKTWvyGA5qmkE7c+2rM5n3kUazM NkDPu+RL6qIBWklPplPpdNpDz6KL6RK6lF5GL8esPkK30930XfoB/ZKJTM3smKcUO4NdzW5m29kL 7F22XyDC6ZBhlgqXCTcL24XXhc9ESUyLleIEsUe8RLxUBZZM7dD8+YjzyLkDcwfuHPh9tjw7OntO dl32+ey72X/k9Lk9uU+ImlRijJ1kAcZ4Bd5/FbmRbAZ8PIoxfkw+Jf/Emn+LuRColnow4qCybm0Y 9wSMfBpYpvn4nUXPxvyvpI/RPvoM3Uufpy/TV+ib9EP6FaMYfTl+I4AFU9h8vMOd7DHWy/6G33fs ByEBrr9aqIFU0YO3WS1cj/f5tfCh8InIRLtYJZ4urhD/qBJUZ6puU21SvaB6SfWFWlLPBITmf3n6 ocTCn9nz4khhEdkC6UAQvmBvsiZ6BfuJPsT89Hk8zS90CB2sjY0Ab7QbUH4usRVtUofVYWYjUlEP vwm7g2WEaWJCMJDlwDfCZrBVrIc8SJ8hP7GTAGkXCq+yLaxb2CTeJI6k70G+eB6qACM9TFpJKx2J tXuLLMUKZYQnxb/wO6o0whHVucyYWy1+qmLCm6CDzZQJf6Iz6EHawRyYrRHsRhJFWaIHkZ4MDPwb IH8n2M5GcZ+wno1jH6BuEbmZPo933E0Wsd30N1iXRuDj+bSD3iVUkSvpUszIMHI2u4VE2BIWATxP If9Dr6Z2YO5PWJsYm09EwcjOIG+zTqz669TCyumVgNNzyTq6lqTpAN1L/sx+RerpPOG5I+6BEkaP HKRbhZPIVvqT+LL4MpjvnzCTfkCuhsqAkPtAI6YAM8NCAlDTSFQMchzwqQe4bmbf0cvZIrKQ3i58 Th9grWQimScsY2PobdnvxFahBjO2C9SkTT1MQ1RNKr9YixX/lIwENC6AhuQs8SPV1TwvvCUcynXm wtluVXH2Q3IpZuckULd1wKWTyPvUQWfTSWKOjRdzuankMfak+GHOSQ00TN7IAcOyO2gTjeVCdGlO TycBwmdz3Yu4TrxOvEC8HPvTT6Caq8hN5E7yO+wm92PfSmIeT8FszgLtWYg9ohIagzq83UgyClTp ZLR1kKmgpz2gkvPJeWQpKO/d5LdkK3ao8ZiP2bhuPjkb9cuwQ11GrgT+rybrQQNuIw+SN9ijbDNk 3OvZi+xCtpC8T94X/ijIdCp5W1wjriCnQwaeRK14cgNWKYjr1ufewtNKiRfUvxZYCsjP/TP3bu7h gddwvwcx9pvUo8g/1W2khEykh0UPVcmtk+WWkc1NI4YPa2yoq62prqqsKM+kU2WlJclEPBaNhEPB gN/n9bhdTofdZrWYJVOx0aDXaTVFapUoMErS7dExPaHeRE+vmIiedFKGl6NzUDHnuIqe3hCqxgzt 0xvi181B05CeMnrOP6GnnO8pH+1JpVATacqkQ+3RUO+ro6Ohfjpj0nTkbxgd7Qz1HlTyE5T8RiVv RD4cxgWhdtdZo0O9tCfU3jvmwrPWtveMzqTpVr2uLdo2T5dJk606PbJ65Hqd0SVbqXMkVTLM2T58 KyMaI16x1xMd3d7rjuJS3EaIt885s7dj0vT20d5wuDOT7qVtZ0Tn9hLOBaaULqRNeUyvuq23SHlM aGEv3oasC21N7127vl8ic3tShjOjZ86ZNb1XmIN7tPeaU3ju6F7npftdx4q4OfjN1ce3eoW17a6F Id557drVod4tk6Yfd603zO/Q2Yl74FoWH9OzdgwevR4rNZ5LSr3sus7pvfQ6PBI8c1x5q/z75Tn6 eM/ZoV5tdFT0rLVn92BpPGt7yWmXhPs8Hnlnbh/xtIfWTp4eDfe2eKOdc0b7ttrI2tMu2eaWQ+6h LZn0Vsmcn9itxaZCxmA8PjMPk55vU3JKd54bf9rRmaV8jNGTe2VA1BkhjGR6FO/UyKN5jWTtGY1Y APx1UlzVeyZWZGGvtq1nrTSc1+MVaa8qLkVDa78jgIDowX8NrZlTqFHHpe8Ib+RwchTUeumcwXxv KtVbVsZBpKgNa4oxjlTKdZn0hf1sYXSJFEICgYh0YG7ndA6vwPSHw3yB1/XLZC4KvSsnTc+XQ2Su t4/IFZAbWA9v2TvYYp/CW1YOthy9vCcKSN4OJoIQe68mcfSfSXJY288a3ksd/0vzvHz7+NOj4yfN mB5qX9tTgNrxk4eU8u18QjFvaCvkeq1t0wUvQx3PMa+gtAIoZ8042gWF6YZeMY5/agWoz+wv0gAq lRoaGtMr9ZyUjzt14XABZ/6vi/pzX/OrlOTYZYXX6B2eKgw0P+zeEUPKQ4ZnWCuMnwySw8ZPnrF2 rW5I2xgQs7Vrx0RDY9b2rJ3Tn1s5NxqSomt3ggFJrF3SDjKUX9H+3K513t4x6zvxKmfR4YBbRkZt jdLrJ22V6fWnz5i+E5qW0PWTp/eBtWnrGdXZmRFfJQsQoM2nOoSPxVdZF1JevxFpCukupK8iPYDw CcJ+hMcQfo/wLsILaLcgfQvhU+St+f60EeW5CLcgvIdgRpiGsALhHoTpCJsRViKcg8Dvze/bicDr XAjlCGchbCuk/JqdCBsQTkeQEOIIHQhnILyD8Tfj+U3I4534OxD+Lvy+VyLw+/KxXIEwBeFZhO0I exB2I9gRFiH8CoFfx/vza19DuAlhJsIIBP5u8xBuRTiIZzYB6CHYISawKKkhdWCiwUvwGq7Syv9x GUWFrJoUQZ+rJTqiR28jZDAT7DNmyFRW6I7txAGZjkBXTsCLexQpxM91yLhjmEQgY8RInCSw05dg Xy0jKcgnGVIO+04lqcJuXwOuiGDPhxUKoQF7/zBw8yOwHzeDC2jBPt8KXqBNkVHGkLHgQ06Gqm08 OIMJkNMmcs6RTELgfw34rSM7wJGcAV7vG6ZnVWy18LCYEbOqd9TnF4U1zZp7tY/r7tXt1w/X321g RmfxMFOD6d/SHvNNlsnWZttFdqv9D84pzmfdIY/T2+6jfjnQE0wHHw5dET4nGordGe9NLEw8lvgs qSlRl7xTur5seNnfUqvT3Zn5mbfKT6v4qXJS1QvV79TcV3tV3Tn1tQ3rGysbvx323ohHm6eMvBy6 ujaMknGeS1yAqRUws2O2qov6qWE72ACVyDMC0alVyDwlCMyjLeJ1T1Hi1ky8zJU6VTrUNGGg6VTp cNMEaQBGgKaBJh6qKmvMYXM8bA4vEMmRkLD3iKwiP5GQuBf8t449JDwvvok1NJOercWqfrZK1lGd llvJdO9pd7H7iZ49JxtC5j3m18wfmb8yq8y7qIMw9tw2Dfjufnb/jkrNYuhEn2F3YNW/oR3ElZIO dx06KA0c7jp46CDG0SQ1YWxVlTQsqNXRSCJ5LINnjVGH3O6Qmi5Qsi5PSCW+mfUkgsEEPZBPoeX8 GPrqf4qfYpylsqR6CiD6BLuJPLFBk1MePQEgmKWn5h+9f2A/aTl4/OM+5rcOu/AU8dOB/ykLh8tw A9aVPQLp4FNAZYecLDWUSUzlLLbqLA61WiU5HVb7SKtqglZr3VIcIwBqRty+P+2iKuKi7uv4bHdN GDjUJB2U8DRMtNkybBjlER7cRWstlob6mmrwdEUQHG0Wzt3h1ZMJlmBdTY8mDcUWd9F5s2efV+S2 FBviD8v022WU0dOiepdZZ/hTtv/+B7L9Lxt0Zrc+QsdlMQOZ7BG2ojDaUi3TetzM7RH5iLUWtdMh qdQYrU6HQWO8JqAYIx7//bvohMHxHubj3Y8BK8MdMlobY0V8YepqG+otdbUsiRxG73RYHGzFL472 m2XZXPbxiMGN0b5MT7r/AXrSnzBalz6SfQqjhfajTWwWJ2AYM+Uq98xgkEBn/pA0U3xIY5qp1Wp8 H5KZGudMs9k1U5I0dGZRkebDSgM1uEOajqtcKVJBlQlW5hdD5tOMVQUcYboH9iNFDhNt5pOaqDOH +djra8JmPmyH3RzmM6+Osl+5rBZXdn3A4wnQ5TxPl/M8C2ZnKXX3O61WJ/0Nz2dn8zzggqayb7M3 aDlAqkZ2/Y68SfaRr0HunhLp/7DnyZsmGAVY0TP0dhC9c6n/GMxV8BF10TAtTCVEcHP2PW/CHRVo +cBfq6NuHQzwlOxiRaKVrQCGe2QD2Yt1UjG3eMZjHIX3SwdIxQR+I3u4TrQeeYituPhijOnV3D+g bvsGFNYH/OzT6MW/6t3F5+6kATwfUzUBq4qr4grIqaPKWtazKbHGjkkNPPpmYuPwU3nA8w/kpglf qM4FSJ8rD9dqHdStFUBZtWPoydqZ2nO0F9KLtWs0a7S30Tu0D9BHtE+Rp+gf6cvad+kB+rn2MP1e 69Rrqb6fvrRD0I8kM7X9tA+Dmql5tkKgwnvmfrp76zMgAoe6BoD/+4kyL0u7uqDJycMYrc+jhrBv YJbZa3br2H16W7HZrYr9OD3uNhnsqoedxW6THiD8Cd77MxXX5FTQx7dZmC66K/ctEXKH+jKa0lYt 8iW5QySZ+zdxINhz/37KV6wt1hSzXbnviZT7ts9fnOFXlOW+laOlKl9xsDhiOVcT8FlIOU2qjJFo cbjZkm5WWVQqo6cZ9OzPT1XFmovdlffuomqgTlpB9QkHpcOY4RaA30FgDtDczCPgetsl8gxWLiVc bqfb4ba7bW6V2uf1ewPeoFdUJxMlidJEWUJU6w06g9agMRQZVGohETHHZBKyemSaUsdl7M8VMo2a wjL1uhElDGmZlDNEXNELrS/+yvCXuoo0Fv7oYEZJwQ7KdnPA6m6xBczOFjOPHIGApSXSn/tJlpFJ 2nxmRF4JkduEyFncEuVR0uYwIodIsKGfELDoWzI6RA6e89vcYX6Tf8lOZEw2Z5BfFWxhOsk80smj /OiUIR6N+LA7qV1SaEoykQA5qZMUcuh0OJyOolrUJBPRCLPbbSg7HTXVljrhs6vm3TnumnJ/u8mJ 3PirywOjJcfktjJ3ybCxN2xpS7lKhp20fgv74PXsN/dcPqIufFPz1GWvU4nnIzc1TV1x0avNUXc0 u2/vzov+0hxxx2h4L8e2/dhKPxO/B5Xf2mfRePtz38sms5potF7Z22Hp8Ipa0y72CDHQTbJWMhhM 0nNaDeM1KtRYqErF6HOagnheZPHadkFvbmYLniYqrcbgZrbd7CrsnU72F1lHFpjNdAGRqPQsWwKF 671QlysQhP0QJGzgoKRshy0HD2KjcA4j0kCzZViFi0rfHXphSKGqknTxhaWDhOwofVMVUKi+gW2k IU63BhYplCyU/dKmNbl1Grf4/U+znCB1LovVKVZOVbvNJqOG7+ePYSbeAy6laGirmrVNnv60V59S iTZC+unMHTqDrTmiAhVpGeCDq6qEVdGR+y857Y3VnmS6tHhVclXJqtIHSx4s3W3YXqY1WnSOOkNj mVgaLQukbMlASdRg03NIMX5hOej40TLgEEs0gzP54dOFiVQ9S/eDsOqpEURt5natVmfw9NMftivP 3k1ngo1kqNd8bG6OtxrZYrCDTtQG0F/PzoVy7FeDWCkdBotxGASGb2gHD7ZgfvdLB2lhTgmfUwU7 fcGYxeWIhxL2sEsm1qhZps6gTaaWGKICdl11VX6+MeVkKV2a6mwIKxugww4qHGsYyepqAa7qIvzy lDVPv9TqIlI0wK7jG8uRtyn5dunk4BOXnfeoW601SGbnwp1z7v5HYuaF2b/umhzmi3TB5Qe+XHzW xJJFD17Z5SrSOaXK+2e/v3b4nGXLsx/ey2H197l/iJgogoXftqiRkn5QrZrq6jrz8NjJsXHxtsbz iXpFeFXjreLNdbc1PlD3YONO6y7nK9ZXbK86P7D+3fkv64/OXIWZX7fDFsHCmfuxgj5kSjUmfarE LFRgIC6iivqIOxAqSaTdWPptoZAl3U9v2JZorilGusPSrI421/dTo6yzNws+3zDBM7xiF5bAx656 Wu8eVqNSG/+1i67MAzfIIt+sJ+zff6p0APA8QeJcH1+Ngf0oHgSd5ORSAXkAljlPNH21dbG41Saq 4rVRmVpVdpnG6hIytYkWmYCAYGmuwh+Sxq6ljaRxKXXkWShOTfLMSU11PdYFC6NUOJWSskqDOJLf DAXr8ku/61/0WbnJKUm2TY/f9OKcp7oCHrf7pKU333n5tJvSkllvdk275M7Nf57LHqvdMffXn86q lCySy7Ts6SXjN57OcYmunTl7Y1OtTeuUSpqn7Ll28m3Ym97l+ASOzA9Z5g3ZiP08xAJhlT/oc2Ba Dzzl9z/nMNkt/bRHthQXP2cPhcMLmABeS2DhIBRqM58WBFEVDhgDyPdBdOpn2K/8Po4GDmJCncMu 9LNrZBNVFS/w+4PEFKBAhcAudh4J05myHjhE3RFRtBuwW72J5Yhdlyosx9IJYL+XNoH3HmgChyo1 gYFqkr5UeCmFIR9oMg9TrS5PXSG94CIccb57u2kwNVVVLqXhOlpjHuQnBjMFQlRjNkepIAy8Rd96 ckzQ4wmOUeLsSzx/dzo7jXbPEZJH/sznLvvdIDWi3eyjgTDg/AUO55i5NPkvOaL3an0Rbal7uEuV KT2ltLv0vNLbS192f+D6p0vj5kDs4EBsRcYbimpsUijmCHpo0B8mz2Ki4pyOYDb2y1p/syjqSCJu 7af/LWudzTpPs1REi3ax60gpW7QDPRfEY/30709L7kxc1A2C8LE5m3AI4pJ0cKArD76cpa84CKrN QVhh7TkcK0TF5fKptD4V9m+XFpFX7ZepW+M8BrlA4VSqayk1F1gdgCTf84ZAbjSSJyeDRJ6uGHd9 8z3vfL39ovNOlRMuyWz9dd/Nex9cec01ISMY8XGchIg3ZecFg/+146Xv6+INYYfFbbnh5YdufLxd cjlYhtMhkE8LZtcDKhIllfRR2VAescVqI4FUIBxI7Modhqr9H3JxnThC0yaO10wRZ2jUcUzwNsxv qJBiw0c5Whvrz70t6zj1wNUxjbEfV64QRVFjE22ahJjQlFmHW8dbZ1rPtl5ivd56XWy3dUfsff37 ln8arXqq0hSF1Am3KRaKh+eFzghfEr6kZFnFksptkd1l7xr+oTtgsMzQgOmRzJaQ1Ra0Bxx+p1ty GSMkZjTE9Qkdraxg5WnsIqVFqTKVU11sjFUBRx7YkWkWBK23n/6X7Ag221TJZq3R9bG6mZRJZaGy yjKx7Fn2KrQHMRojBvbg05HmymJa7K7aTRvpVXmapQgXfO8Y6FKERWwgfK3381Xmu19+BwRv54un Q2HRKpnMJotJUBuMeiNTp8UymYaskX76W9lOEjrwcvFYiQaVKVVGpmFTkLfoadyYlElpEaICIyc1 KZwcp2tLlQ2es0yFrSc1yBVz6sUhBdsOF8EKcmM0Quw2sE95osdBhy469YF5q15/7qFzn61va6nc 8s7lkxtdDrPRUtr8++wed+K+xUs2b5k3Z0YTsy4776P7b/th1brH37zn+oWb50VMbotTZ8tu/TT8 xlN3Pbn+mt+e3gCsfCuXFd4FVtrJyq1agbNAapCuMqZWC+w5rcFoXGAnNrud2MFMGJx6u4EIEmUL 9DqzSdKJkkG/C5hI2cPbnVq3A/vDUfZ5/wSF8WmROOEB3XEq2MSRaXVxeaqYU6AT9m1aF1beG4xj 2E4VpQEmRLhq4EFOSwQh+4TGUWxxqcVFCQUtNq/66SWP2SXpLKDCn0Jm+FSRGeKkiq6WR1seivyJ fEm+NIge0W9PZaal5jGVvlh0eYttrrWuW+idmjv1Nyc3p+7KPELvS+5ge3S7DLtSr+r+lLJeQh8I sypbBpxNny8a6M/9va8yWr4r93cIG99vN2tKSoAlf+8rK4nsyv2LxHNf9CUjYc4GWVIlsibaXFqq 9jdbVRXNaiPcvf4mS6WlDinRLHzsaW5xTHQwRz89KOtrQs3Sx+lmrbv6BLEDIHqIa1E4KTrAmTMF ThUaVJmp8gbNdlETsIRk4rOBDpUXQWaoVGEbDZpBkbx2RBlNhUyqIGAcEyb4xvpzSYJ00a6lZClk iZ0klftsG6QBvMhn2yAk8FSuhIygcqGkciFHeY7ynMplM7TYXehu53V2XmfndaCAx/46j+7foIEN g6QQ0F2kblCYK4gCgG3rcXnBuvCcfVu27Dvn7Fllw9+57ddvDy813nvB8ns3X3jRZudvV6787eMr VjzO1tU81HPr++/f2v1Qbd2wSXPXvvba2rkdwz9ftOmus+fefHO2aPH99593/sMPgy5aQRedgIs4 qaEdcqZII5YVpUj5o7FdMXWCE8loGlGxC5GxOFBda4ggqnbUpJNpO+fETDOrPrH8EP2fskPlqj2E VnEqya/q54vuwPp/QaoxTxlcpbbtqHqh6q0qcbbGGCOJYkNSX6Itg/SHnDGBCqNoipU261Scnsm6 ChA0XbjZYUzsAs0ysgdlXazZ5KnzfFzUnH6WPUxqj5Eu6dAAGK3DEw4e+gTwoFCtlrw8ARg5RriS yfJIVLQbiw3FTG0GO2OVbJKoVsXLtICREj1gJJmI2LEf/la20nKRC5uaUlQWI4pKYdTvIBk1wGYQ bo4RL9KVAqecWkqP0jDkFSTNb3CQ6Pi6KtzycXseqauFMAgOLb/UDfXCntZts6fd17Nny/nP1LYN S9w868rrZwzzuMwGZ7LmHVptq7t74Tm/+c38EctqwuwPy5af+fzZdw7cuPrxT/ou7LitoiUiucxO vZXWfFr211du3n7Dmm0yXDJZXlcizIWuxEuqZK2pz6HX9BG1ZTf0lm4iUscOvd7t9h1TnkBfmpci FK3hIMujsJXWIaXjFCqKVkWJhLkdDSNO5WFgw1EtC6ONuTJ4h/BRuMh02by3+PXiv0r7ij+Xvi7+ QSpygkl5dFuliZr6qUfWYnym/5Ged4j91CEb9bXFb5oc1PG+m6gLoyQtFITgEN+xwMwdRBaMCJRN Q4YnQPVU4H3Z5HjjxI4GRJNmUU32E7vb7Aqpjxvqn7OVEUvAbrByuWMuaRWHQVtnJtfIga1qqtFq Y4TaiFZHuC44RszIQ0WsmUn5sIluprlVSx8lOvhjGNhtkIcfIxr6TJ96J+1njwGecU+3hUy8ytVP o2BJ3RXUpWy5+w8exD/iPuQ66JYQrdbk6T9Sl7IR8Jey0rx4VURpYfebK6x36M3uyJHDgjbiNusd bCz9EbpHtzXbke2wImPAE2/BW5yjvMUqObJH/YbhW4MwZPTHv9VMqKnwJnijVj3ehL8Ff5vCm2Ab ewy6uZ0VaqrGi3RchhcJH/8iA/v/H17kmMKLFjg/8Zwjy5U3EXRH/l14k6xaeRPaS3vzb8LIe7kr IambYeUYS7t2Qo+1d5svUGvpz+2VtZZArVFG1ILSNqTWQupSUldtG+/ltLhqd2mekZlFqjBGJeEs TchPm+uH9dNiWVdfX91MxbEjR/v7BZWsdVeliz8cOVPX3C8IsllMjx7t1qljabc+9MSwkfWQU8bI RoduZF19bOTYGJxSIBhu7mtNwzBRIesd9ljGEct0pGn6GfopDDB/5ApybgCAwAH5fABKQM5UQwaR DnG1fAsoFhcNAcn7QbAswxTRQ2oiXcqmdlpLW7xW5SpLlaZKUslUIgW1ts1iM9skm6iuSNTEW7St JcQVd3QTU6W9mxir9SW0TYU6WTOyhDpT7m5iKy/upoba4hI6Sj26JE+/Clo0rkfLc1+FnYnWFTCm vkaR8bmIr7abbZaa6qP6e4Uf4zuWOa/Egn5ZkUXVUZgzCrRMmOkus1x29+8fvX7+2JaUr7J92+23 jTdLZldTz6aO6zK+UyXn9YvuOW3t2Tab0eoafe2t5841x220XC+Kty+6bOuc89bH3LGWrddkd/wu +++xkksKJZpH1AZvGz5pCTyLyG+ubr934cBeBvbOrqX76NWTT5mv4mefzLAW7YG3ZxnUmU/JqXoz ZtQ7Mt2QGWs52XNKekwGKi5Ht6c73ZH5vsyUImVl6XLKWEYnwXIjO4wbjJuN7CMjNZaajUbJ7NeZ LdFS3lScSNSUJRKlZf5oWVoLMRRVanWNwgz6tSzjtipVDsdUi8NhtfjdFnPEx6tOCpLgyuDGoPB6 kAZLvcEgtKERr8eTLisLeD02r9djMZsDLAM5OBOLRuHpQmggZSoPwj2tXOvOpBMeawLGDc8uuIKm 6UjZVpbwyiZtCzFTE5Sq+7xfe0Uw/+mnKlnCnElYdtGRxAxcMOtaoO7YK0voazJTYp4Ia1XOLALR 09sq2hcBhaHMBWQuBWMC8AN08iwgEQYRLh1zHqsLwKoYrFarFNF4NejS6isgIWuOKuu+6VpaAX3d cRX/v4rK1UVghXnIGwyEAhUfFK5pQaURHiTvgw2CEBWEywb+uvReLgtm/8DjVrrse57Sh+idrUr1 H7kQvuXmz4If09XZVweFb+ELbt/46XeDZbqanTFwN1QY8O0kYidgyAc7bDWdLz/7ZNljqT/oXtS/ p1NtKFubuju0Kb459URcfVlsRXxZ6oLMBt0G27rYhrhmijRPWqFbIi0xL7EssRaNC00Inxwbn1pV rKo2jQgNDw+Pt5SNSLWbxkoabYU75At7494yb0XUVJbSXCI9E/tjhTAmdHL8wtCq0NrKW0MPhHaE NGkN1Cc4WeF3MI0qRalfUxkqFqIlxdWhpL804UgmNAF/oKq62qFhDk00bjIEDRWGFsNEQ7dhMdTr /fQauTQTJ0A+ZjJvNO81v27eZ/7arDZ7apMlUKBwU97XfIOqGXdJHib41rS0YDvtUhQnXNcPaFDU AYr4rygAuMp2qKJEoVmBWNpi0+mtiVS8zJbJ0LgumqFpSylOUekTGZpXZinqLLK0iy5dClNIV1fc PLjIipGwQFAKC20Ng/pw5VYUVttqJYcsJUv5+jLp7hcfuObSjgfmDCiGrRdpaffE5tG3XJTdRh+Z dPHIznvWZd+cnF/uHZfe2V1x1+zJ6+ZybTCrj/rObph43RHHSWcPky8eiUlYkftIPEV8HJb1j+SL MzZaAav6RCKoHHbHVOc825mOheVLbMscS1zbnboGX33lOMe4+pnOmXVnO8+qu853R4WupsoU8kbg bqspdjgbqkPRgAmaMIs+uj1liTfo14mBeKpBEFlKW5zQ9IQTCc9wb8JUFayqqGqpEqvcw1YftwgT DnLOdmCAT79ia+F8WV4eV8wteR0iuFwwP2R8r/708b0x+NjsJD5IZ+BRuAjmz/1rB6wMPpeDa9Dx 18nFGmD6oEZXMRnmDRCc2hepYYUgED2O0nuuqykX6upqLeBDhL9ytHFazU6mmrr8ljlT5cSopI9K 2xc91mG2Wxyp015dOHP2SbPXVF/36erXxeAIvkSfBz0u7+TWzlQwc2r3mOk3P5P95+xuu8PsrJjV FfWe9Nivpj12OeUHMOEFTsQLgXt+kDqDHL5Rt0Z/vWWNdY1tvX1DcENobfiG5NrSDWUG7HLJUKkP gtg+WXtHckeYtWmcfk5v9Z5S4vH4id+pYbxcpypVdO1+jbncFAw4HP6AU5MKaLUsoGGxhAkspylk YiZPeToQoCGsNgzbmd10GNUc040cQwauXIdOTIm4dmSInWJIQcGF2lCZzl5sMpoMJr1JVCfiyXhJ vDQuqq0Wm4Wpw/EyXaychuzRcho3pcppxBIs5zs0lxVh4Soo4qEdOR4/uIkIi4Slig5SQgUruDyR hEQRpv6xCgl84ewnyyeW+s+/7oyrs028ZhOtOntnlzs2KrZ+Uva1AlJMb+w+e8LC5Vd9O2MUx4q1 z8++/dTmzo70ycCH6ViPCqxHHbXInu7gYvUKtWDWF6csFr8+4gvWRaN+n6BVc17LFGjhqZw2uVvU Uxnza20eZ8pq9XtqyzmAs6pUXZ2/PJnheilWlkok/BkohhbJTR5GE/poLOGpg7YyQIjew/SaSMLk o1/5cj7ma4Ubr5Z2aLdoX9fu036tVWnrEolykpEyLNOPHdERj4M9D2hPs1ZYvrJ8bREs7vpxixU7 cFfThIMDXOt7iO9kUtdSiApLC9RMYcMQ4R+oGHSc33W93XQ0U6BsSn0qNdjwttIXqmFukoI5qoBE gwb3mqNUrGCJrwPBGuyTt83X0SlsFcehI3P4iixVaJiwjNcMPEgVnSVWwcXqskFlH8tu54uSJ1/Z j/glr2bHd/M0+yWPu7FKm7FKy7FKteQbeXaPipq0hpQk+bVhb6AuEvF7azKmymAlq0zV1voz2Ebq +TZicdtTZrPfnUiTUqmUlabicX86Ek24a6G9S8BBCauidTOtpjaeiSdIWkp3pAXYRUbK6VgsSmhC iiSIN+RlHd4t3tcVPkTlPc0ckiiRVkobpa8lUXLXHd7J8UhxD+FbCiYf862sB9AITjktKHIWmLPE Az+b/cH9ZejqHLcIEPkG1cWDqJBfAlCv8P+yBnfljYVZ7+AamPQB4W4+8QNXDF2EQf5AWQGj7peX AGuwEjvHddg5mmhCblwfujPEKqQWaaIknGwYE5uq7zJMjT2ofzD2jHqXQStGndGEIRlNxOpj6noy bCMZNoz46+sqOMGqMVXT6vry6uqKcn+dThNMShkrDThd2J4y9WVBvySEvU2J+opE/fw6uESE48UC 2L+Fcshms7KyuKgNzC8vzwQoJZ6RyYRJE4RHkLt59eJje7uyrShOUdxXh5sKQc84t7f/2PaSV/Ar EgnnoY+jbF1542zeUCvBqHjcztOqg3D2L6KCD0Ia6p9ShJLcFztijogjOrj/YANa2sU3IDMXNcpZ YWNx1uZNA3k9Jydj3MAIMifyvWgQwVSKI4tarOjZ07361Rsnrvly/Svri7ju02UxO6n6jcuW755U T8nHp1w9Lb9U9JaAR7LRvuztdfUdG/vW3LmWqtYurrKZPIHngm6nf8qieTd2XXjHG4dDJbQBWOii TqvRUYQVPQdYtRhY1UZ/Jxss9zqeqNjm2FMh5kUFvTFVkBA8Ib5qxZKf+lNhvz8U9nvS1UoVfDQq SmsqKqpr/OmmUbxKMrXAWaAl1dbSMqrN35SXI/TqVEGMyAsRekdpQYZIxZX7mEpoSSpWUhKP+VMj 6nhVG+wpjanaxsa6Wv+IaCQAow90pYl0OhVKeOKJVCovMzSNGKGDQFETiNUGYm2yL1i7ue3JNrah 7aM21tbPdsvedksgHDYHKpmMQ9A4ef46YybWzRbDJvcMjnSM5gcxufx6qAuYCzjhnGGKi7KQEbjX EZcUeLUScxDiVPaoGb8AKqjmRv2hpRNM/D8HsF+86sR7KAKDoqKt4MoAk63FISOqwEb0dLEVBURc tO2k4Z+Z7AoM56DKCE6BJ9acIIcI1wy8pZDr7IcK5a3lgsUPCgVhmSUwoQZ/4DW1eeqMPu7gElaf DQwhIeCdrM7sKXQ7T3k44hhsB8x9AgHkc8BckLwnZyrEclXUEDKGbCF7ha8iMFJVY6i0VdpbfC2B U1VtBtkm28f7JvonBuz8lDx4H0O94rLh17qDStlXT3y+IPG787yQHpSfO3D4NS4Lb0/a6812u8Xs dwUTbkvC7WIsoTEl4I/GhVDzRHhuuEPrPxrcSRUnSr7YfNVBx/+Dt8ZxS3nCIiurdQK9xgZZcFYb 9FE7wY9jH59gBiyGtW/kscnK74h8ArnG7jFQ3ycxbwnyrXz5lcIK66W2NWy9sMG61va9Q6Nlepve LtzJ7i56tOhT6RPbJw61KM2XnpKesonVmkQoCp9af8gd9H3gcvmDRSaLXi+GgswCaupyclIqG81w rzVILfsI7PwgrSWm+cUBjaaINxTxhpUwrbqTd++k7xS2O7BwnMZy5bQiYhe8UDF5gGyopn9JdIpI Dqa2O2yIzSoTqK5JXWQVnBkqqUGDHcySyTOHHPVSnDvkAhS2wDwPX/D2ExywHHB56YSZFZ7cf0/3 04v4Jkcn/HrcaSc3zMw+zQGWzc9P7oDnjn3TzqD1vJT9duzYksCNk9iBQTjFW3eCIt6BWR7FzpS7 XBlXvac1VlNX01A/NjyzdUF4UetF4ctb18prW++QN7U+2bq79ZUaq4nU17TXTKsVTZFU/Zja1rqp VS+0/F7e26rxRrxVCyMLq26pfTLzSP1nkR8yP9TrqkcRUjUIzakh0FxMfNRXEwJAh/zuskoOwI5Q ZmOGVWZoJrOxKpOprPKXVZE8rBfDYUlVMwTc9WB48uBeGuVXdyRMiWCiEq72qQjfb/ylkXBrrVwv toyKVBELCYQjtnA4QsJVETFEKxNl0URZaam7KhIJAV+AMC7W2JAY2dKi0UgJKK1hvLh0ezjs0lb3 0+lPh0aNqiKjEtU4io2jb5fKTrmjqqdqSZUAJXxVR5Wwr+pr8MStDbuh1wlBn10vm0eHQxzv4DH1 NUe9tnG76ORjQogikjc1QVHsGXCBDi/1cMcSTnQ9bmX7Puhq8XCuihsVFQGFZ/kP2MqlRng3cM84 N5EDTYBmXwMidzUiZwaRraRFMW2kOlerrngB93UOcx2n1OniWp3/gPOcKh/XtaJr6ZC+JxLtomKo evIuVztJJLcPX/Gp5ZJcH1IMoZOTCUVE/U8ku+DOGjUPaoYGaTiMahCOBksMntVTN3EIz27hMJ3n tWkPr9nERs/i6b95QyRbveD6lljPQl7zm2u3r6Z/yq4dpMrHCM3AT/CILlDt7BllVy5v/Zp3ogtf 4/7TZCWwYzqwI0wWyY0Qkuq4kMRZcNAWL4SkDwoyUR2XiVhC7+VijklLtR5w0wGrxR154BKF1Oal zQNd4I7zphjFGUXhgY+yvoOcMeYKG9egm2+ekh6TQvIklb7DyhWfrB7+si+9xGP6CY85QaWn8o0q O/uYmKEQVcpPKYh78T6NLCkP/4f/QICNIeMa9+LU9Vv0r743/IfJYXrYr4uTpD8ZSDSO9U3zPRzY GXibvE3f9n9BP/MbpweoQdlorJu5mB2EmF1qNZksVr8hqLA2Eol0RFikNBGJxBP+YIXC3Oir8b2b 6rp6f4Ue/vfY1TQ1okajEv16r52XrZtd1OQKupir1OZy2W1+b3kJry8mqQ6cSC5NplIlSX95f26d 7PNTEvL5/QHKbJTHgUZCoC6zoQrY6pf1gTg86wMBnz8BU41fHufzeRsbmGBPeFl5RbI+UVGh1xtE a8KgSSQbG/2BgL+hPgAPhtdoMNmdXJx8MrknqUrCX742KVvqTMkNydeT+5Jfo66ffSzb/UHaTdkG +hqc2ano84mMiVBTXCI7rCFBtImBidbXrB9Zv7KKVvew3xVk1gkciT1u6aDLPKwi/69rKYpdqdRS l3TAA0EpX8sFKEVyUoTYJuS5aIUCZ8cUtoyrbaGvVexJKjgWpODbdHTfHoqXJyDtEAweUvj5ZQDC 88HTL8Wh9+h/wtkaOqi9/YUu7J6e7LPSJg6S2T/xeGwdj/+Ck8vD/sKRsjbvT/UKVObBTRbuOHUi JzCQZm9zwD2+nmMl1CniVYDiNF0sQ0VKtT63j/2RUT1Ve73U4RX1ZgXIikvhlGYGxsZTeWAC012a LilJpf1xnah0KaoRiopEwa/z2JQytBtOpw3IHAvwciRc4w+HA35/zAunIxrweW2AJuol1lQiHg8k YjEopC59ymtLAPNhG7gUTuJ6nY5q/L4A7Ihp2UtIWo7XmdIT093pxekN6Y/S6rSnnMEJ2cu7Wy3d 1sXWDdavraLJSq3uzPBzjgp1S7mmA4DBuQ3OdxzIM2tctOPkHyn+KU5bhV3ARDWg+NRm9iGSvIp3 Qqei2j8GIEOW/T8XhgIE9zNVyHc4Sv8zMAzy2oOkXGSLBm7N0+pX+IKPURjtD9kiAIU7mOdJxorO I81DyfJPnwovDpJkAs3dWeADz4IUbiRuekTOvWx60c0sBxwHXD9IP1gOOQ651X90/E36m+Vdx3uu z6XPLUUeyWOxOxwu8Y+WH02HrcLd2lsN97NHVI9o7zf8Sf0njeYatl51g2alAUpI+y1sk0rToG7Q 1GibDMOlGkuNY7hLU8ZShgopbok7KlwjcBLCtEfqs/RZ++y9jj2uXW7N46YnpAcsv7HeZ7/f8aTr UbdmmnWSo8u1WbrVerPjLtcdbk27td3e7hjnOsU9wzRDOs2iKXUNN9VbG+zDXKeaxkntFo1erdN4 1V5NqSlpTdohF7upqLGajCIpcoJJNcd1QnGcq/JDOCq2BUfRLrLFi9zbPG2XKjsKlGBw4uPuMorK mLszc8V7QfcOzO3qAmeww6GDVzzMqoe3IZXgGr7N4mqBu+H3crHN2+JwOfwtLh5psVlvg5oPTV/w VNWfe/doWW/h5d9tQ4p+Sgqb7O+2gVGG28i+QnpILgbTbIcn30hrABHlrjVw2IdTnZIynkr2FkMh hTn3W/Da1pG0GJEhwnNcsBv6l2dgUp3QzdkYtAuwekCV7bAU1TLuXs/12hbxrOu/WvNK9hVa98qa L9dM+fLZrT/Rogee/ZKNeTj78RZ8O6IY59mnb8n+45FX6Zjsyx9+kX2PtnPY2gZKMhOUJEoy5GvZ BecpbxHO7lm9lmDcW+dt9+5M6cosyf7cl7J0gedaD0tqyjQ3e24NKt8w49LZID/7y9JY1VH2NK3I YlESiFtMsZYYi8VcEMlK49CI+jwVGbCIkrv88DFDwaB6mp964dJFF/8qj2yKyViDGKRiRHoTl4M7 OWc4RET/z1jN8Zh7tJClcLyHtqaAqUPVbNCyKTyG4goeL9hmoIDuPVG/Bo7js8c/GFs9vmP41OwP 1NB13/hHr86+Q/dllw/F6D+vmXR1vNFjnXz6xSPPgDmA47RZwelyMpy+LHevTq2qXFv769QdtQ+X PFh2f7nGcnbVwhqmSwopb9KWsmUSZFxlW21b/cnDxg/vis2IT012VZ5eM6V2WsPMYbOGn5k6s2pB bU/DE5X31W5peLbyqZq+2t6GncP/kPpDZaTS0ABof2q4rlIT49lDfVWaGiRyZ8qQ1JRmSofVlbSU Dc8MH3ZybGzqhti65DWpa8uvrVxTvym2KXlzamP5rZV31D9AHky9lfp82I+Vh2sP1/843FffMGy4 WFtTKaQTMA2RQDRiw5Ek/3zgKAj/1D79fHgPrJGtQtzZCFV3dbzUWSpEtcXz0ziK0NVHD8LrIC27 6iriXA0bSlemt6RV6Yvq4gn3CGC4YsjlLuccy+FjsJ+r9VoquFYP8ucgo12U29unlWpTnfvdn7hQ r7AGxVe8cIwiKO5LeSMRPtvBPd/kMdEmHI8pPxPebKkSROWcQtQHENXyqJ6foKnlUX0A/er5CZpa HtXzEzS1PErZgPhDUZVAHdOlKoI1yalIqgq/rkBQBFJYIQP/xoYEq+P4y7HYehwGs/OXnF4/fUpT ePhYnwGem/ZxjfVlt7RXnTSv2aY1u5y7H/oKyA0Ez77+wVH0Dk82h5wVFqfVpHeF3PUGsxmOejZp dSkd9xlH+OzD2W+y32UfYmcej/ZMsYA8B6zPkAZ6L77blntBPjUUHpmyQSM7s25+1QVVQlFqeNW4 qhme6VXLQ8vTF9fdUPdA2aNVryXeCb4V+ijxTuarhBlKlar24JjwxenrgmvTvwr+JvhY+qXQy+ED KWNgN45mafG9rF+iEEMF2BHHKEQwVJYKqyOZdBQGo/qCNJohgYpyjvSIsGrlGlcpRNYyrs8J7mKX kgzbIhtx9JcGpJq4jyRoAuC1Y4VvA4ws/bQEbRHaEdkSeT3ydUSMcH7YZJYlWgFdPpPcjeMKPgOD 9uGupfu79ndxTRC4Tn4eTGE6Fb8BEOJBIVTRIStAdhzr+X+QnUbolC0Fa2Zf0BDaBYVyOHdoe8pQ 5whif+qrDcHd8Is8rOI0RF6lDCj7jxxHgUxBPjxOOsTxwIJZmU75uZx45O73rrtrxsobZM6KLrnr scXZ7z45b9ukRy7JvsJ02XFDydYfr5ixuW7kXd/yWup8rm5yx6LGybeD/9wJjsQGjmQ0+UAua645 xTuxpqvmIscqx2rPGu/6YXeM0p0cGtPKOEg80vrwqHecB5zfOYtwLutwn9VVD59K0B65tHmEx2VS 2QhtKK6ujArltdyqbNa7E01NteZ4G+zK5euStfFwG0zLSU1YMS43xLsDiwMs4Blji8tViWhCbl1c uqJ0Q+nm0idLVaXu9rt30eAx9cIEeKJJ3OCMc7F5i/OgyXkA0kbB7Jx3VR6muIRzozNWgHL24URr Mtfe220Bxk2VBae1QQdmRVY96rnNLZYFn0jh5jwnZ3FS1X3Xrru//JSe+Y+1Tus88PsPruHTioCW 3ffc8/SY9srb35g1663He8WRPr467+IUj3fyqg1zqk+rCZp9/uTa2RtfWVPJmz7jtudZv75n0agF AbsHX4y57trnuFywAbt5k7Kb3yiXwWBWxw1mMGnWc5MmbGR13EZmdTvqIcW7oxYIHjCFaXCQZfFT kmSGlRKUe7EcknwVvh7faz7R5GvxTfR1+5YAm570feTT+D6Pc4GOa/9wbBdiWv5c9KCR66gkP1Su 5/J8AUKP7rSDhiwI+nkbopltfJ+/24CivXg/+zCfHuFxPn1DVaTZv3Neml6UXaOk0DOQ0wGPl+O9 K2lkN/wEvifB3Pd9QcnHD4h6welFLvLuVx/wfRH8gX2n/s77ffCnkFbPRDX16oPXeTep1RYXF3Yk YpfszF7jtttdbr8lr44rJtDElRIo4oi/zKxThCRjqdZo1Gn95rzObWyipqBrgz4NCrXSUlfCoktY zMwPPjYShrJ1MdaGmWCI7+ZHgqvdHuhZJ2q7tYu1K7QbYPx1Vx0n90DsKUg9+Zxizzoq8Py/iDJD pReUOG/Mt0IAd0GzClc3xTTAjYp5lUrUrLhnQ8dasBkU6oWBfz205IlLYX4vNgTyUsum564+fc0C RbbNV4gjB0Zt/XruHy9mz2HFjDq+bAOj1v3ulHvOUGoUqwBWSgKE8p0nRTtlH07WuSrJKa5xqR7/ TdLr/h9cP6R0D5OH/cygCKPFklRjx3kuu99gd0TK+NSDwC9JMJKQEj2J13E8JVEKm3tZyh9JEb3i wOZaXET56e3FRZBrS1lRkcD8ekbDbn71yX5/jcvvd7v8YZfTDu1FAHgMXMZhdAJrpM3pxCeayhIR dyJsSxiEhD6C780Y9IzA3gv3hUSlq8PV6/raJYI9GSnrnSxRYe+277ELdpS34VNYzl30Gqi0X9+W VnzRzoQv2qEDXfDuh43pIHRfYFQHtRjc5lBRMajL+AUXtBM9zoByv6CRPF5FWVhmyKhYQO6Nqiwt J1U4LY4PO/5CLXvggmxnq9NmNNqcdJjLaiy2Ou+lq9T0qi0uGwou2phPZXGk1m4w2LX5+IhD+OL4 Mqc+kNXE+7G2JeybPH8mu+wu5nCq1DgIpinx2NSJkIFpY8xemt86OdfehCnhalmcRZVPX+xZ7F3s W+y/3rHKuVe11/aZQ9sj9Zh7LD1W8TVGJYfklB2yU3QxrzPgDvoDJaXOelbvqHKOYWMcrc5OOtMx 3Xm982Hny+wlx/t4LcWD0Sx1QPVcZ5Mkq81vtNnD0GPdLwdiodiSGCMxKdYR2xt7PaaKbSyJxZIl /nAJMaiVLlqTNqhlJu0e7Ufar7Q5IOpGlVarVvkNKjHk4V1s/m4YSevcfr/HDWsLzmY5nKH+7I9y rV0UQjaVKAbsNpyoscFJNeByQ7kHHwQm0IDLibwTNkkqBGAdsdsdLOHsZxfKAVcCpk9o6wRRk0yE PfxfKGRNGNUJowEHlWma4Gsr2KHcmPQuufo1Nw26qVsuq3PLtfW17pUVyERjtW45kax1J2RTSbCk u2RFyYaSzSWvlXxVoinZzS6BCOIE++104DKHXIGASx2yp87k+Eo5sDJ9O5MTdVDuXNKnCtmfxeNs RMCjRZqR7UEb3WujtoSkwkdLJqo2qF5TiTj1C6cL0q5o9zngY484CJj90i3th3YvNbCUi7WuA25p YKnHdVCRcZd27UerS/oSmFGgb0jy9tcmnMrj2KGBhg+p61iGV+TxBfc7XkevqPOPQ4ifOXH+vAJI BtI4vjcBxqwMbmZPs5XM4/Q4PAqt7ESL56gDGoMDGtM48fGkrQ6p0K6o9Lu6OsNw2owKQ+lm1Gqt sVpPqBPeu/bLz6+9PMi3OtrId7AXFv/3VZ+f+6JSUc8rgkLLEXxdMc84QPkXESqOvCH812AZmNYB TFsJTGtjNfKtljo6PNwYrWuTDRMdE8tbGycZuh1d5ZMa5xjOc5xXPqfxnvKNjQ9F+i394f7a/raX LC+FX6p9qe2v5F+1X7UcbPs3vufyjRRx4bbV1NJmtrRFpQgOh+BDdjRcW9tmscCcXgubUW11FEdM AjiyQWk1A58twdSksyYsiXACFvpRibZEbaIuMaIqUZ2A+8DFsg98uk7j0YxgZeyrWlqbaGtraWxs iUbLy5NtnDW3tLSqpASlKoNB5fcb4MYG/qNENptUFaoWwFW3SqXytFcncKiqZEdyvh9P4u26icC5 xX7B7x69myYUlzZ7/mMt7gk4byAd4kcPOM/nnrDfBc1BXq/sRk5pVOrcKKA+X8mNEtwXUWEWD3KO cTDiAMhFxoDEjUoSNypJ3Kgk4VxFi1RsdCAy2AZFQa5q5JCJK3YSS+7tbbgGmqe3t+EyJcWVSD+D S3++jOt5fd/QW5jwp+zXyn1qct/I1mJ88MEEraZZZecRdEhctyRbURV2obGNR5ILXgLK/ZFWo/1p pOZiyHSDoqqiSuo8qrQeZMZOqKiHWrsAtYNyxc8q2B10Q4iDbPZbHq/KPpB9ZJVSPsRdU2ro2uz1 Cox/wiF6Nh1NR83muQO8T4hNGxjg7B03z9DnsqPy+WKHGoTx00E4z3bR+wbzAM4zAPNnAear6V3c wPbpNnyiAodYP5XroGF7KkK1UW21O+quXhhdWK2eYZnt6PbPCIua8JmRWyIPRMR/h7+PwjdRG7WH 3VF8D4LTbj0YZP41CL827+9iPOrsEo6kqtBjm1ROy/vZ72R9dXl5VbU/VV0wxOrBSuedDtxW/v0k B+9z1Em+LMbvXpNMRZPJWNRfFo1EqBQxE8GtrY5aqxKpWCJVFkqUecIWi+IHDyY8muiAi1Q/27MD VD1hhuv+HtkUThDLRMsG7vxXczx/iINhXOEFnkJhKfLmEthHALmwQvLtFBvssONII//4xDHCeOKn KI5v4pzjf+6pgCU+tjm+1w2yGAfB3EZcZlfBAXcp4OvnnP7/DUs3H2X83cH3sxuqOYx8yqPT8dXk mtOOwk01k7Kjj8LNM6x8EDyySfq3wTznRN6Bx0kWsIKdUR52iUAtc7Rz7D2OJbql+iUOdb/wGfvM JGgYgikoOE0lrEJoZPhPKoQVwkWmC6U17HrBlOcA9NqphQ0/78dUBtkpfxZCMjHBLKoCxUZmgehE NSY5VGeS/QhuX60pAfPKpXLUnef5F+PbQh6vOWFoDVE6EV8gXkG/piJ1e7CqeT9CSKqcZEHrybdG LGteqcnP0RYYfuVzF0MKys5lP7o/mXLfbmXFfC24LxoF9dgh8A/BQOn9j22F9GnosZhgCvJDylxj FcYXAI6ewzXjHK590PAqZI+8xx4deIMbWdk7A1PZtXyGLxWeLfo3XxA6/qIjo7Q0zvM4SdWcHRBu xbliMxkjJ2An/paQaj0kzm+xV2j0OkljITSmlXSVug6doHNb5j1yvAMO99Yb8nECvNlRiXFQSct+ 9WeFwOzLq2HFm37cw0ek+oKPEKtOm7ID7BZlDCPl0IljkPQWrS5GWwAdg08/wmebu2ue+GzVUQFo 0NuEtbzCn01D2X08fVLVyj1OflS8nHBHMoAv7mWjsNAYtxfNpHqxoiL/RaQhbkDirT/dx68Wu4Ju 98BrRwGWkY2QX6cKK0kJjl7NlSc9WnR/8NFyIVEUD44Ql1sv8lzoXWm7znOT7VbPY0VbbPd7nqjY UfRM8Vbbds/OwCvFh6rsOnzct4wKd5pv8bDLyteWbyp/9P+r7EvAo6qydc8+Nc/TqarUkKpzqlJJ KgOVoQKBCsmBQFCRQQQBJWozKINeBqVthyvx2U+xHRFRcbjmXafbggETkEkbriJiY4v9RFttu0Ee 2n27scV+Nu1rTPH+tU9VSGLr+178ck6dU0VMzt5r7bX+9f9rOzeNeKP+/frP6s2VQL161HAqo6RS CSVR6S31BdMjFWFkmuka7ZYaiL2OqZeytZWCtVHR2SwKAbIrwItN5+z2SukJt1Jqojccgiwr0Im1 uRSWUdqUacoVylPKFmWvclQxK+Hm4P11ipHeX258yrjXeNSoN4ZGVe0ZgHI7WfWU/s9plkOSoz16 oLlc3prpxKu2Fq6BLngvEDQ9gymaFKgV/A7pAfYKJiT32bOnhCZ8h85+3ec1jzAjKsMXSiXkokg6 IOGje4QYPuI7u4/eAazTqTShjFKUsRYkYfzGqIJAoDj3dMSgQWGK58WjdHN2vPvIC8d+M2bttK6u +S/JFnfQ6lzwxPSneleQFbyR++n5O66eesOqa/csuPGxjctvetnlXjvxqtFWsDitrnDVkwv6UcwF kvbvHve03IwLF8++gioBtRj72Zi1UaGSlb1ECUuPanNneLKScEQDdO0LZfyhUMCfiMZMOmaTy+2d aM21YHu5YpEVxEwL1CpdFD7PZLGVKi48edEYrkrOFOyyXyJZlUtaLh2V4AzSl983eDhoEDiXi4os IGZQMI41JHSihHR7JMf4XrCBD4a94HvUmUstrM5WVzap8pLKhZU/TzxbtoPtsr0Se7liv+GQ+Yj+ E/MJw5/MnoC+njUYxtra2TTb+bFL2CxDp6nTtpBdZbjGtlq82Xpz7Mb4XbHd8VcT21MBRDinem3u SmCiL8U40ZYzw+ai3wbgc9S9IOHwF+OUosUiyhwQH7OqR3+zkxnzf9/+yXoeXhd46f/28YMPfkzf aBT43oH8317bnz914FmKRfSt5Eu+PfjU7373FL5h2cTBmwzLrBJObVesAKBR7jut1uDFm/5PUh9V HIsfU/6c+lOFqcxfEZggT0lNqZgld6YurVjqWhpakrorZEc98a/qdT5pru8S/7LUVRWnwwYjeBD+ MAjq3lT4Z+7H3Q+XbAg/638Wn00CNHKFpAgjrU0oGtQQUWGtR0mbbH16Y/Tfg0rS5syZ53bH2QPx fXExHq6RFCR5lrbuckbUrwdA/QpV7x80zrA2zo6G7Il0cOijhP8wwNQCgwKFIEwNtoYLDCqhRES/ w0peFNNw9aRGXi5YAgYAqIIJVgS9N4oZujfIHYJkDAWNcctDe1774IX5h2b40R9p0dMHD+XPMNuh /9Q5omQlv4ijr+akrj898vSR86ZLQU/1+GVM9+Yhhq55onArnvYm2EIMz/vTl8+vWlyFLQDIADjx LcNDroQ5BrCuR3VHMsFIpCSYiFkDiUpLpxVm0Fep4HnDHOSEIsUEu00yIVdGLyiL3EW7PTAWrkkp XQADdrJ7+qqrujRjcJ9eyRdfyMKIakKmQEwTtJo68TXZwfcYAYfVJm8NFIygz4ldhMjFTN5atItd 6El3sleWKgiILEfMmjSXhQZ81MASl+T+SANsGoLFqTy4TYJe1FzMg5+u+vWNN/76uk8e5tcrPtzw 8IcfPrzhQ/0fzlxLvuX5gzceu+EnR286yD7WZnL3J59000wWOZc/g5kcQjn9XXWJNbDRLzaI48UZ 2O3ggHjA98vQx96PQ59E/lfJZ/F/BByhaFU0KzbHLohcGJ8XuTS+PHJN/NbIPZGN0Y2xHQbX6sDu 6H7dfu9b0bdiRvMbnrAsYwX2lCpBk17x2Owzw7luga2ABe1kn6nBhJxjuW6JLZf2SofhivToOVe1 +ZwrWjkFWRcBBpy7T0sCxbdodjjoYfYGJGhxTm2LSPEYKuknB1w9iHVMIX7oEHmXNjMFE7lwo0lf ++1/BD77+eXvjPM5obyt+9ttH+aPMtfBd5h1duj99euPhNmTT7/Z2ugKeTzuhtks8tYOeI7/fdvd PZvvxQxCX39BfylmZlY4pKZU+3RDl+F2+2313fZe+7bq16qPVFuDoL3ZD7rdCUt2BFqSIH3Qo4Up tABmw06mqmHGEuayyoSQ6kwrpYLglUMjakuMFrMVLWbugWAbZB45fJhPzQ2qI+NX/Sv87/r1/lDT 6l3s7QL/dgqX/LSggSRBiS0UJPbzhjZYKQdHMRD9FG9wyZazqjqCAa2JC9WRdBxyRYbOW9+rMxnZ CKE0bHygzMF9qr8AB4sZxnks/cspmDn0Mh1f3nzfDXc2oiOI2ffI4n+5gd1FN3WO/knFaF3cRfNx zdInAuaA1xvUBa+ZuEaL20ThX/O36m/FzKxAz46YWj9RWiGJnyjvpU4qJ1JnlK/LjMvS19YuyCxo vMlxS3pl4z3prsYn0+saN6W7G3fHnKKZvMF8YsZmLAaD2ZIQhVh1fYnsDsoYS2dsfb0iW6sVYX25 CVAExP6sslRmstXqhvhqq0XnshAQv8VyGOheuGmE0pV8INmd3JrU700eTh5Lnkrqk6Fs1Y+GTFYe xBCPEQ6DAsi2E+RSKYzlStJBHoM7iUGzeA8KEl8LYVThq8zI0b/pjYFii6sacx2d0naU5r/prQ2A 7V8sBRYmOkUurKmYkXskk1NEwZ2HMeiLNmpkE3kRdLGDrH2w69Ddpq19ZSUr5k3h6qqvLrihInDn +y+eOfPi+3ceuvfeX/7y3nsPiQcf4x5j18zxNZdXIjYtYReeXzXu212Mbd/OhPzkh97+1fqHfvUr 2MIs2MK1sIVmtkqt3Rg+I4t65mcLjauND7CHxG72jLiV9YnWZ43PmbYZtpsOmD40HQ2bwmYP4E34 bZcUl0RpHgrVwZKEJw19EAKemnl1NTWZukTajQoL+XvI1efxIkvCrcWvttS8QvzajDS5R002Zeqb mhrqE82MRJP6dGUlhrtZ0JvcVrNFDh0tYVgnnlZtYwRFrt9bdxhasZ3sz32jJxWGkrItnkTjWHD5 vNbr+V6Hj9T43FJAifK5qyEXeKtIUGAQEaK5FmKZY70QJyNBnssN0h2OGEzGVMQAHljYFNVMEjaJ mVKsEe8SjGe/3i7b45IW/SBbowBI6zaG/gTDK2oU+YBn8J37hTnCZkxff9n8u+ZdjuQjnv+S1uLL b189b1zmmsHCO27ZiIvOzJ408f5p/X8fsF/dZTfVyjf0nyze0EIlrCuvYjYE0MdChwh2jVqVCDWE 1NCM0ILQ9aGfhkw+h3uOJCUcRrtljsGQsAeioQ1+xLG6N8Sd7KGXo0aHHf1H9jAqi4lIQ5x6PeDm aQCXQ6UXrTmXI6Iexsl/badhYUNSxXN+DubhTzb5ivliMfcqrqfiA7esYRfQ391fQu6JXfA3Yl4a PB99lL/oW17kphgQngqxDEUj2/K36pr5X1YqPKVWu0FhB2VAd5lrbhTRXfR6V5fQxbrELt0Gl3Oq +X7zU+ZN0d1RQ9QcodJ+FNZssJl3shdf1usTNu0PVp02Y3hmSPb6nIH1AA12sitUD5oF6mJxu0Mu LZ2GSkkotpttZ78ueHxeCkQQkhkot/afaDvdX3gIWCARrqF7Iv/LB/7iwTJaA3omikdvuS3vINKh OGnOnLEz83/jD8Cy7Kf01/d/yy1/wbIHauPc8O+5Gla+F+O6HlaOGsAuiN729YH3kiZNLLo+0Vmd ht6xV/ue84n7s6xKqkqNSFdlK5tGl7WlxqbbskulpUnbVT6W9I30idXStPRHqY+yJ1Mns2dSZ7Lm Makx2aVlS5s2SZuSxjIobrHXE/cDAz48SknrNuz9GAc3Yl8feHV0Vt2IvOPzkvF4IpmIgrTWyL1F XV1Htq6uMZuozTZ5bPwHOTNWp9NmTXiIX40MSiNXl2zk7OpERPLVlNP9Sen0vFQ6XZ5K1KTKUmVl clNWgngviW1afLKQRN/UpOBrKpMMSZbIRaP+XMRYnqtpzNXW1tSItpzXI5hzTLRKlEJblqPw9liq bFbTbtYtpHDHsSLblRXlbF32yqwuS96odBSa8Xix+qywdFlEt0W21OEFrUNGS2jkHvYkGPclDOWT Ih+Fc59J34tuFhreV6yP0FpTlGxDB6HnSPUu5LlH+iCFAD3xSB/UEPwMHJqfgUPTufecLIKRLgId 2kqqiUldMgj6++o79cchPg4X52DC4Z9F9pAZ7h+HCCR84EyGy7K0w2afy0P9bY714kz4NPwjqi7n IugkImjJnKIGz9mzp2ktLGot0RgAofd0ZPi7hCR4nalQVuZvE1OXIG9WNP0B8UDjgLqiWPMehn03 Avt+ZVCy+AZbVM1txUGO40d59MX5Eb3Kn6K7ufwj7Mf5nw1KHf/Bash9kEHl/5KfW/SW2L+PYb8z AayZP0CD0Klm5/uv89/uR/Bhn0MxI6LEORQhekv8GzweVGMQGApM9rihtt3r1rlDocHekKK/H/CC 3+sB1w31f38l/1dMHc79ERTv+vG77kVM1iFWqS3YIaEZ+ySMcbW4xrpUV7trosVbbh9p3xbprdFX sJFMnBWdb5ofvd50fdQw0tQQnWiaGJ1lMtSZR43l9nl0DBvT0TpmzNjWxCg/oPceNSZ72XTvu95j kLbrBa/bqwLk7nB6vS5nwp+C0A+BgpBwQ0fREUsk4rFEaiTEUXSz0d0oNnZkGhvrMomRHSrdXHS0 nbV3tLW3q22J2owxVj6itrI0amSmqlFqTugwVim6sGKx6EwQkKVSfqvDKaPwGW+qC3Sh1vlteWlM riin6/Iu9O7/tlXIyG2tBGQJrXtbD2MT5tCkqhe1tUgDrmCJRAUrnDAaVNTXoj8UL4v4OxD475Ml DDGloZYCUerwd4vBhJG8MA8mhgcVhahCrkyXoAG93mBLpfUVcWYwhqxBbKxnqIqzEjtAWwLoq6nJ G28P2NmJcCNSSF8hc7ae/Yugx7fp7MeIPT7GPt/vFWNPpvUMBN+yLxBu5b0RcEZYs68XZ263aOrl J2AgCNoB9bQsBiJJD8dkBgIT7XpQpDIcw/njsmvGzVearxtz2chJvOfD41MbR1w1roMs7vFp9bU1 Y9v57eN0Q/uEbv6s6yZ2dEzMXXhp/3YyOvERdebERf3v8dfr2meXphdqFzTNtWQEs/wazPLZmOXN 7E511PvG983ifuN+s/i0udfYa9atNHWZxAWmheaFEd3jkWeN4s3xPrZN1EXjS+OghED2EoO98lnp 8sdBHOrgxKGEd3hMqy1JTgEdSjsKq5IW07qFlDslDgtsHU0dWmDbkGs2st3smCAD0fCVKnoTYlwv wESLVQ4fRcmfFhQ3D28fqOtGeBui2JavHATsYXZqMROfnGiB1PbFwHQcPsMGRbJDZ+PwDxan4vfF tVIkip6w2EJZNKJ1bpxFzFALUbpJws5zk60XDALQAF+KSOSwBeLsg7uPljnMr82eQdOnqP8aOouK tcuii2ez59w398ppzZfxqfEp+eiO/3btxTetHBzd8vd089fMnZCO3X1+/5dF9yzq5t7c/t/7vxq4 5tkqxYDrgEi1YIbYQJc4T232BvQBdGjVvcXesr0v/tbwO9P7NuMy0xKPuEhcpF9iXmJd6rjGs8h3 VdDsV3QuxQI43WRXkOGhl0iojZ9RqaWz6vA3bRWYG9qGKxH87hTvVEu8wM/xMaOKzywHhH7YeMx4 ymgw7mTH+0rggordrbC4gRa9Eo+1moBbigQ4VFJslrMHXd2/FiSQS92SUwruPnscYcHxPkfME+MG zR86qWw1QrQtQGIZEIcj1F3rNIKlWJtNwsFsxcFEB9w/qZYi4jNJoOJCeextC0ieYKtEB59Ehead YBF78cJqRbBmpgMvNDHaz3bI11xG2G0Rn+HDquGK+pb8FwBj/8K8+19jvlmfdnd/St9sy778KebZ uw9bbZz6z3/7/dEnnzh2FGNTC9yArJc6wNaqbfVW1+gKfDfVXoR2JJ2OhQxjYlzmuJ7dXLVqhO11 4z7rR6aPLB9XfFT/ufEzNNHHdpg3m+7RbdRtxv6d0C4hDQ1lStE1sjQR0FYpm/fgkCVpXCJTWI3Q TC3jyvmjObDHnBnFZk0rbL3eJMRzKWO54jIzc7ixRnDKMVfpNM5W0JeGGgaD72ShXNjEd/Vo4QDC P8MPhhjgsAs+5sVIqbfSXkd5Ry2nFDtkRqNef/Z3L1UkB8acjzgmjWZlRGIlEL3oqL9jUoOGhlVN 3rz6lv95Xb7/1U/v0epwHP4pQOpPvvfoxiNHNj5yRDd/42Xzrj+8anv+7I68keyJylz6HA+Ilqw7 /O4D6949jLHrwti9gLFLop/EhdSL9nSvazTSitNqs2t0j/B8pCelmyFcEV4o/Et4qYIdY8M/HnG7 cG/4jhEby5+oeWTEz8s31zw3wvNMkj2e3iRvSuu0/EHDiQswkOabbf6DBbesueEZ5IaLyYEQrqgt yXkpkHfWKlH0lQBCVAGsKGEqw5YpIbnLylzWY9ZTKFqG66sUanrXHd8a1x+OH4ufiuvioboiiMwD 9iLOTmJHgApAhUi1zMlNQ4HkH/ayQwc2rDW9yiAQTkk11KS4UqpGQ+KX0sNGVkPtBxCi4QAB4CEY XdkweGjzG+QrV3A8OY+GD4D07j7+Sr6f6X5x7O4jjz56hL7FtzbSCJ6BLk0bUfaPHQCGXj6bn7zu 8OF16959F6vpJqyml+pugLf3q9ItTlZjmWZd6r3Re5f3YeOTPhPP6FRb/GAhe4v4d4s9SHZU1VJI yqg1SI86rXIq7wuSqLY5Jb5NpsHkwCadktNtLUvlhGqjtc2NxRC5GKVkEavLdAqb9YRrBUkucyWn JzUA71TSmAzV9N93bkHE1gVEwZyiJU4YFd4OkMZFi9jQr+Z7AJ1hdveDiyBWOU8hpNruk5wBb1Rb 4iA34msb0TER8RSawQwL1QcSFVF85umJk28L+axOXzIbGvX4XnY9jVP/tZTFH+ICQt38Iw/NWhT2 AWVJhudsymf54KBljPgKDRZG5PDZo7o8rGwC+0pdK7VFx4neC9HwYMmEzfLmUf+j+W3fW+N/7/sg 8EHrb8f/2Xci+8fx3/q+zn4z3mvzGQOGVsv4uM8f8LdGxt+d2JDd47LN9l3avKR5ae6m5ltzdzXf lXtW6pWs9+W2x8WLzNVQZdSrY1uy4PQ7TX77aCELUr9+xEiXEx1awesP5caORV+MdtRpmrbpZCLW sIfVaPlIRRFyplmjlWkxovbrQO2vn5nMpf2KSqtkAOuhOnd5moHb327SGcutiu3yQt2GUDu+L0Xn lK9ZNemCCJflTH8aY67iAMmL+gjwYlehJzmve6HmxYG45lHjvXI05UsFW/1xIRcZHWejZBy843EZ aCuJC+BPjR1T2oJYJpxraY6PjAvSOA8PpSmwQjSNA2Wb+OIxTnH0t+WkrDX6ytk/CEG0D5oAs22V IL862ZcItNCc0L5457qVpFTcJTRjjbUg7chJODTTilsCpldOwmECLbETJCyqEyRAIFH6OXgy9KEd FFhIdNB+CTqSWJBrEqilGp9tFRwdpPbyg+QLRAxGeFUo9OE9KqJQx7UyTh9GYe8WLZulul7zjDvv nZrrqLtjy4QfXfHOm2+uMfsdXMAQCiY3Ln+m+6IZ+TfXXnhkfY+uuhQz9YFYOBBqqWgeXd3UUhl1 +UqSt5y37PlFCckZjr2ISewfEa9ru2nC1ExGzi5uuWYNZZ0PItrKgbdTI7yllp2JMEckHBGfsW63 vmZ9z3rCavix8w7nBudzzgO2D2zGoJn2fegBI3WV6jfr9SYzWFaSxY9O9R6vZAjZ0zvZ06onlisr M+UYE4x2JWST1qL98s9VqaYGGHG5ckCIuqMy9A17gdvtFD/rq6VED5PoBJwDIuhiKymSn2uFUk6s GuwmtPpKOGK12cKWuGCN2OPoZ0L1FV6uxl5hGrseOgd6uqDba7VT/uSL0atWbwn4Ee7zTgb55tUr Zx0YJTmwV4L895XrezjV/nEaDN18Mu7+X58/v1F20L4/ypSfrRYzdJP3VqPneBme41zdfKECnthu 1W8PiJUBFkaBigc59ozZbreYEy6tkGqLTC0UUisUeh8tLVlZh1xWpsiJChZwSbKSEyqswZIcegq4 zJYcGrhIoIOg4icEQU94WrWk3R7ZfBjNYghgrxwOsONBUtmZazRhLAVi05C66g8sh0UsHcJylZB0 eQiM7vVRv3Of3hMXvEZJe/KaGfoKTvhVNPE/iXj4OBiZx2FzRA7hBBBq9juQetLYjDp3WVg6dXds PnizejEHxd9YPPVXm/gwfMnTiJufaJ+zWozxwbh3xtJXtJcajkxjkMNq+CDGIAmIt34T2+Td7NPJ Vtkm22WH7JRdMjK3HGv2jvFdJV7tWSItSW7Bh17wedU4o3ZcPaofdCK3I+PQOabytlwJNO7VFlH8 tQBGz8Gg1HMLRROjcR5vugU4CfsC0K22EhdvKjF1APb0QPUge9H8GN9JQcCuHJLPB7QTW0EWAM6I O2fV5awWYzIHWHOpavOJuYynzbPFo8O2kEsFH7Oo6E7N6rzLvd2AcPTeV9kWzJkUUzToEonnys+5 5gHDXuR1E637B+UOw8nbw+DH4W/TtcZG7NT0DuTEBkA9rnUYfEfcel/++UsoumE5Ot7Nsik2gvdW ZS1UEZmlc9BQ8uGcpAEE9JpGsvnsWf1DGMlKXY36bGWgIniH7oXAsyhm7QpsC5oF0S2uCdwf2BL4 ReBoIB8wd4tbxcOizqw3+yEU8VeKaX2lvyLYrG/2n6c/zz9bP1ua458TmlN5FVumX+y/Onh16OrK m/U/8T8aeDj4nLhJ/x/+7uB2cY9+p39rcEdoR+VbgTeDvw0cCf5X4ESw2haIBNAQJFAdvDN0Z+Xm wJ7AAcMB6ZPAH9kfg9+IZwLfBD0ahwjimSKJSFM89Kg1K8qYANWDWqY7Ra+6IXrQrSjrKhNJAgFF 9kauf0gU9A89avoKLk8CShlHkVT3pYVt4VII3GAWy0bOjEwUpBA9qqe0NMN1EAnoIDZwHcTZC9SG og4CXKSCDkIepIOQB+kg5IIOYi8wjyC7HrPpGB6/H0B6Ui/MhCZipt5akVPCOdmXcxhzdkWWHQ67 cTkqfa+HUEu5Ry0X1ofUOugfKquhf0hB/6CWxnAIhXEAwBzKqVeiB8Ye9jxykCC7GwKIWaJaPzor 0udE+pyouj1ZFKeeVx0G+UoQIl+X9OulHOT/+3rrmujU1zw6yy+rtUv8b/ht/AR+xr/nZ/wwOqve QDBrUP1NayCUEEkvIUIrcVxID7KY053og1L4+oI0EZ0kmcBXPxdMdBYFE9VfQz9xolMo0SBHinJ4 NAsxHtgqKEf//0omhllZBhDMyu/ojP7ZzYJuoog4bK80h8x6UkUUAhq2SjHpdBVFSUQxKRksiSje 061dvGvn4p402eUf6LBsQ9/CnfcvJXT6cwp6K5kYBc1hkIVeJUr9J0VesS5a6SL426Ww0nbxQXVD 3BP3it5mz2yPGCGMJZ64kl3rXa4sT17Z/jp73f2O9x3l7eTbDa9lX2t3oZen8GhC98/kD1zyIGuS By6FkDUphAg6iysHR+nLeXNKTs6F63MNubJcMlc1Pteea8plczm1KHeogN6hba4hu5ON2Ca3PwY+ LmZ0hGQPihKA9EHANhCQPjzmMizH1IDgAe/3JR+rwK5i+JzyWMVcV2mmACMYIHqwWsPWKmPO+Plu ZoKNoOH5oED4xMC+CxQLFxQQnSR1wDfVEWlXhhPhL0rQmr+gfyicw0LJOeHDuVe0f1hB0PDLYYKG zX2aoOF0nzdJwoPjfcCtcP59b6SlVZvNgyQRatI9kkQUNQMiCiv+mTtGyoUYAl53YuBfoV3Xv+4n GYSWaW33lDhc2UYoGnpxRphLNSLeb7OgkDiOLRNs2BITqBQ+dVy9AC881kCw1YMls7V9HET+jA7t o6DvZ3RoHwV9P6NDO1GkUW52tSnWUrk168KhQQpFWrGXip9kFCepZQf+Kn7Gzgv7+9wSId/7VQde JFtwUOhQyAEKVsxPWkROwThr0CTDRYxlWNmJJBeaZK+xaBXDJBfY6Lab3VaOFp/x/F/JKO7O78rv 4QtY/stY2OUrZ7flXyjz4f3PaD1byCKsdCGZ0Gf0bhl7I3+/KYCAnQBwNjr/poZ1oisoEtPzzPwd rHf5L5lHWwftAfRLFDYAp3kUVtXAXkEwIZR4SxLVDiUI0rhnmkMNnvH9n4TNgv3BLkgsZos9P/H9 JLHWtzaxy/Oqb3fiQOI3CScWUG+D19Pg02KamMORGQhmIolYF7a625iIAVWLJJKkuejZNqKO54bB gugiUd3gs2gkQINho0YBtKBZIRSiWHKCdRBdZnjLokTY10DKix712oqKDJdeJCC98DWgYTnvTeHx emXa8cTrE1gD3vBiAwFzzODFzuaJXCQi5cJhWLRIoU9Zrqo+h27VTiE2PSauiB2LnaLMNDvdAMGb 2yAbVhiOGU4ZjIZQY9VuRnEP30P2ROdKYAwrB0CGQcFPgWlJm6FQpZVkQv+PguvwiGeYqx54GybN 3F91ZtzDK7Ims7vFTNsPrOxUCiIMMLsKWt/vTK9iJ6vCDFXEa/I3hWJhhz/ANTsr2Ww2gwfCUPS4 pRH9J28nV53nUnVmgm/2YtsKHj5NE1/SphAm1znEiCKpL8BR/gtmU1D4L9XqJIiYmZ1W8VXsWOcA Q9Iq6DF6NlOGt6RKWAM8DJ7gy7h82J0tEXAy0SvKDifUqk5IIZ0s4BDtzOmShSC2L5Ox/S7r1Odc 1jbrcsLrQoHO5bTddMnqAl5AEN2UAt+ZhOtaJlJgwY4GIgBXR7KJXYKoibdAM9xH4i1+hq/D+cNe +Csybt5XaogcY8gFHjsl+AxgGFMKCbYJYouBPc90H/TfLTZzvkW/IK7qP60ld5P7x/Ltqw9OFl9b RU/4TagrSNmwDpVjh6DswjNqxPZBAssKZSZzyFlQUgBPpmQV/1tdQU/P839xHVi53OhL9D3/uJN+ oOFGuA/QYhEB8S/oFmbiBdOuBh1n4LUObZesqH7YBafggnrbI3gFQHGoDwcwiiVgk4axA1MUve3R NUhQgOeWAY8vB5evEmLQKqEauXwt+pVlUOaox359jWBQNgkjhVECdqMWkAEJLdgBp1VQhfHCBGGi 0CFMwgYz5wsXCJOFC4UpwlRI5qcLFwkzhIvxW84SLsFOFnMAYV0qXCbMEzohp6cvht9K+/2NVLme c974iydNrW5fvnrVkkWrpi66YfrFU2YK/xe1sHYWCmVuZHN0cmVhbQplbmRvYmoKOTEgMCBvYmoK MjczNzQKZW5kb2JqCjgyIDAgb2JqCjw8IC9UeXBlIC9Gb250IC9TdWJ0eXBlIC9UcnVlVHlwZSAv QmFzZUZvbnQgL1RJWE1LSitDb3VyaWVyTmV3UFNNVCAvRm9udERlc2NyaXB0b3IKOTIgMCBSIC9F bmNvZGluZyAvTWFjUm9tYW5FbmNvZGluZyAvRmlyc3RDaGFyIDMyIC9MYXN0Q2hhciAxMjEgL1dp ZHRocyBbIDYwMAowIDAgMCAwIDAgMCAwIDYwMCA2MDAgMCAwIDYwMCA2MDAgNjAwIDAgNjAwIDAg MCA2MDAgMCAwIDYwMCA2MDAgMCAwIDAgMCAwCjAgMCAwIDAgNjAwIDAgNjAwIDAgMCA2MDAgNjAw IDAgMCAwIDAgNjAwIDYwMCA2MDAgMCAwIDAgNjAwIDYwMCA2MDAgNjAwIDAKNjAwIDAgNjAwIDAg NjAwIDAgNjAwIDAgMCAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDAgMCA2 MDAgNjAwCjYwMCA2MDAgNjAwIDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCBdID4+ CmVuZG9iago5MiAwIG9iago8PCAvVHlwZSAvRm9udERlc2NyaXB0b3IgL0ZvbnROYW1lIC9USVhN S0orQ291cmllck5ld1BTTVQgL0ZsYWdzIDMyIC9Gb250QkJveApbLTEyMiAtNjgwIDYyMiAxMDIx XSAvSXRhbGljQW5nbGUgMCAvQXNjZW50IDgzMyAvRGVzY2VudCAtMzAwIC9DYXBIZWlnaHQgNjI1 Ci9TdGVtViAwIC9YSGVpZ2h0IDQzOCAvTWF4V2lkdGggNjAwIC9Gb250RmlsZTIgOTMgMCBSID4+ CmVuZG9iago5MyAwIG9iago8PCAvTGVuZ3RoIDk0IDAgUiAvTGVuZ3RoMSAyNjU0MCAvRmlsdGVy IC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAGVvAlgVNXZN37OuXf2mcydfV/uzGQmyWTfCCQkF0IC gggISIJEAoiChUIEdyvYqiigoKhVsZX3VdsqCoGABlChiluVohWXqi3UF5eqVO2Htm8hM//fuTPB hC7f/8vk7Ofee+45z36ec1defsVCYiariUCUBUvnLSfqn+8gktcXXLkymiubzYTo1l+y/NKlubLj PkI0Sy5dcs0lubL/JCHnGhctnHdxrkxOI61fhIpcmdYiTSxauvLqXNknIj2wZNmCfLt/I8rzl867 Ov988iHK0R/OW7ow1//Sm5AWLV+2YmW+zJObll++MN+fdhBi3IG6abn2fEyRVtIYOYf8hGgIIxKp IDMJER7SzCIiyrxdQ0jJ4V/fMdfa9K3eoFcvfLhwmjquF01v/jyr+8dG8ZQ+jQaD2p/3wHXaxwbu J0Q8lNVlfyeeOtOiXo+oci+ZkT0gHNg5s0bpRzJKTfoKEtWrUewzWdR0p6GmZUyFcIAsR9iOcBhB JHMRr8rXCCSCXAsCr92AIJItwj7Si3AA4Q0EXrMXNXtRsxc1e1HTIvQTKjwtPLUzEcEIdvX5EtVf jfELfSSLwIQ7hXVExr0vyqdz8+kGpCWo35hPbxfW7WyMWMcYUKbkK8RZBIZ3e3Dn+CnVe9TMiCY1 s3mwZnMfaiJjfMKDGNWDGNWDGNWDGNVXiCnuvhn1m1G/GfWb1frNhKq3kovzt8pnHtxpdedrkBlj FDqFC0g1btGRT2cJF+ysjuwf0y3MxK23q/EWYQbyG9R4rhpPUeNVausqNb9MzS9T8y1qviWf59dW qPlcHFHzVh4L5wvTSTGePk2YqKZThTZSiPIUlHl6nnCOmk4Wxqvpuaj3on6S0EbsSCcK7Wr5HJTH oTwBZZ6OF9p3jotUjlmO8ly0MWIVeP04jGQcFnMcJonXbEDYgnBUrZmLeBXCYQRB7UmFcfi14jdG GIMrFNxDQYtCBEHBrwW/ZqEZLaPxNqMRK0IT3jeCuAKhBWEKwlyEAwhvIOiEJsRRoY5UIigIUxG6 ETS4TymuK8W4SvGEUqGMJHAvma0nTqTRfBph60gY5TBbtzMcUcYY2C4yFaEbYTnCarZrp8ZuHeNE P963AmEKwlyEVQgPIWxH0JMWxGhRTKyFtQhT2BRBBHQX9zU1VatpTX0uDYZyqdlfbR1zuVCMaSom DyEIGHIxhlyMVx0sRZBjAJ0U2Y9wGOEoAp/wFCYjhclI4QVTuD6l9tKq/b5CKYsgkGWIVyEM7cOn JoVXTuFZ39+F1xahpgj3LMI1RbhfEabxKGKqXsHbpyJsQNiPwNtiaNugxi2IpyAw3COGN+A5K+KI ENvJDNZ+zC8dZR0zAvM+BQGN7HbM5u2Yt9s5hGD2ANtoacn32IB0O4JG2INfMX4p/Irwi+En4xfF L4JfGKu3Eb8N+N2B3+34rcdvHVbDuT29P83m1i2rW1W3oe6huu11++t0+9g8/LpZt2Ikbjdoot2m 94+RmEjmEAv9hxo/qcaXq7Gixh7FP8dyfI7llTmW++dY7plj6ZhjOW+OpX2OpWKOpZ/OVzxpywdp y8a05YK0pT5tqUtbatKW4rRljI120lnEQp5T47FqXK3GMTUO0Vk7LcTwDL2QyHpAPE3tkm+MfCz3 i3Rn5Cdyvx7Jj3OlC3NJI698KlIpXxopzdUkc0lCflbEHchM+gTR0bRSqntVN1en6EbqynVluiJd ShfXRXROvV0v6Qv0Zr1Rr9dr9aKe6Yne2Z89poCdUOLUSjzRghdSIqp5ifE8IsSEUT0jE0mvQ5jE Jk0fSyf1HlhAJs2P9n43Pd5PjdNm92riY2mvfRKZNGOst3dEelK/Lnt+b0N6Uq9h6oUdOyi9oxOl XnZrPyUzOvppllfdHOi1t3bsIZSW3nx7IJ92dvJrOnaI9PbbO4n7yhZvi73ZNrJ93L+IutXK7nHp 7/+832fTaT6SUO+9k6Z39D4e6uyt5plsqHMS5nl6dE7HHtbA6tvG7WEjeNLZsce4mjW0nc/rjavH YSCD/UgU9eP2EJknaj8S5f1I9Kx+YTaC9yvkSa5fWO0XHtZvx2i5bdwOGVGuz2i1z+jhfS4d3udS tc+l+T6COn71FoP30R0jstpH1h1Txz60Tzj3rP/Yp/Bf9hkynQvHDin8U5buIRPpOztar21bGG/r jrctROjuXXflIm/v6vnR6B7SSt/hTdFeIdk9f8Eins5b2E/fiS8c19saHxfdMVG9dHh777W8eWJ8 3A5ybduMjh3XKgvH7ZyoTGyLzxvX2Td+XsmTwx532+DjdpTM++eH9c7jNyvhzxqvXnfWs57kzeP5 s57kz3qSP2u8Ml59lgr1AEs9GdvZOieX9jGTEQDcHZA7x7ql5c0qNDfK3hsCe0VCf0VM6c5ec3xs rwWBA3rZmLIxvAlYxpsKUG3NN3lvaJQDe+mv8k0Sqm3xscTbtngc/lesyGdyxf9rvGLFipUXrbgI yYqV6v+KlVcg5WtGVhBIrniDMWaVv0VAjTltXoewXqXRwooVnSuJur4rriD86St5dOah3+euwM3p iqGQQPgjh/2hlaZJLuB2K66gGAMfxhW56+gKikbcBpeuzNeB5oifItxFAkjDwnxwbJI9mg8fZW7I tWcGsln2LjrPyAckam4GuQd1+NHJuZRcTI6QpeRO8lPU1dDfkseIQqxoO0IESiCxN5FN5CryNpmZ /Qa1MnmYfEVKyUiyKJshNrKKZOiPyMOU8ZkiDeQtspBsZE1CWvwCxLGEVgpb6Y9JGe4yg9xLPOQw 7liSNaLcx0KsCVfNIK8Jc/Wl2crsX+kB8dXsfPLftIm9I24jr5MTNCaSzE+y67Kbsw+SAnJSCA28 kK3KLsVVM0k3uYJcjxGsJj8nh2gnG832Z2/DmDowhlXkafIaTQOguiHRnY/eN5H7yB7yHDlM3iMf U0qttIiupm/RIxoycDBzMHtOdn52GWkj55GpZDVaQ7SQjmGzhdnCk8K7A/+TOZYN494zyJXkanId 2UA2kq3kXfJ78gEVmJHNYDOFJ0mAjCazyXzM5iaM6THyKjlK9bSWjqIKvYU+wa4UhYGD4PAicWEG J+BuF6PvZszpo2Q7OUjeIG/int9gTgXqw+LPpHPoj+jN9A56N32UPkG30S+Yhr0nCMKN4kviF5l3 ssbsA9nH8NwACZIoZN1SrMG5WM9D5HO8XwktpS30dyzNSgUqmgcymZrs+Oyq7IvZd0mcpNB3NOTa NjKZzMKor4H+tY+8hGsPkd+ST8jfMEsCNVI75iJK4/R8Op1egVE8Sb+iA8yN9WtgS9hOdkRIC4fE WeK2gV0ZV2Zn5qtMNrs125t9Ifu6ur71eE4rVqCLLAeK8RXbjee8SI6TP5Nv8QwtjWCsE+gkvO99 uP9RehrgpGc3sCdYFtLvRuFV0SfelzkvszRzX6YvW5udDNgSIHT5SC1+owBNM0kn7v1jzObD5HGs TB+g5x3yF+qlYVpJz6EX0A7aTRfRZXQ57aHX0esxq4/RXXQffYd+QP/CRKZlLsxTmi1gP2ab2C52 kL3DjgtEmA4dpke4Ttgk7BLeED4TJbFUrBQni93iNeK1GohkWrf+9dOe00sH5g88MPBCpjwzLvOD zLrMrzPvZD7KmrL7sx8TLanEGDvJpRjjj/D+t5A7yEOAj8cxxj+RT8kXWPO/Yi4EaqB+jDiirlsr xj0ZI58FkekS/BbRyzD/q+lWupM+Qw/QX9NX6Wv0d/RD+hWjGH05fo3AgpnsErzDA2wr62W/x+9b 9r9CElJ/tVADraIbb7NGuBXv81PhQ+FjkYkusUqcLq4SX9YImos192o2aw5qXtF8rpW0FwJCc78c /VBj4XX2a7FZWEK2QDsQhM/Z71gT/RE7RX/JQvTXeFpImCpMZa2sEbLRPkD5UuLUbdbKWpk5iaTr 5jdh97MyYZaYFMxkJfCNsNnsFtZNfkGfIafYBEDalcIhtoXNFTaLd4nN9F3oF7+GKcBCvyNjyBja jLV7i/RghcqE7eJv+R01euG0ZimzZNeIn2qY8DvQwdGUCb+hs+kJOpW5MVuN7A4SR1miJ5CeAwz8 PSB/D8TOBvGYsJ5NZB+gbgnZRH+Nd9xHlrB99L+xLg3Ax8vpVPqgUEVuoD2YkZHkMnY3ibHlLAZ4 nkn+D/0xdQFzT2FtEuwSIgoWtoAcYZ1Y9TeonZXTGwCnS8k6upaU0gF6gLzO7iT1dKHw3GnfQBGj p0/QHcIEsoOeEl8VX4XwfQozGQLk6qkCCHkYNGImMFMWkoCaBqJh0OOAT93AdRv7ll7PlpDF9D7h z/RRNoZMIQuFFayd3pv5Vhwj1GDG9oKatGpH6ommSRMSa7Hin5JmQOOlsJAsEo9qfszzwlvCyWxn Vs7M1RRkPiTXYnYmgLqtAy5NIO9TN72IThOzbJKYzV5AtrLt4odZDzVTmbyZBYZldtMmmshGaU/W RKcBwi/ithdxnXizeIV4PfjTKVDNW8hd5AHyPLjJI+BbKczjuZjNOaA9i8EjKmExqMPbNZOxoErn oG0quQD0tBtU8hLyQ9IDyvsz8gTZAQ41CfNxEa67hFyG+hXgUNeRG4D/a8h60IB7yS/Im+xx9hB0 3FvZi+xKtpi8T94XXhYUegE5It4mriLToQNPow48eQRWKYLr1mffwtOKSQDUvxZYCsjPfpF9J/ur gcO43y8w9ru0Y8kX2lZSRKbQ70Q/1ShjZigtzaObGkeNbBhRV1tTXVVZUV5Wmi4pLkolCxPxmByN hEPBgN/n9bhdTofdJlkLLGaT0aDXaTWiwCgpbYu3d0d7k929YjI+YUIZL8fnoWLekIru3iiq2of3 6Y3y6+ahaVhPBT0vOaunkuupnOlJpWgTaSorjbbFo72HxsWj/XT2tA7kbx8X74z2nlDzk9X8RjVv QV6WcUG0zbtoXLSXdkfbetuvXLS2rXtcWSndYTK2xlsXGstKyQ6jCVkTcr2e+PId1NNM1QzztI3a wYjeglfs9cfHtfX64rgUtxEK2+Zd3Dt1WkfbuIAsd5aV9tLWBfH5vYRLgWm1C2lVH9Orbe3VqY+J Lu7F25B10R2lB9au75fI/O60+eL4xfPmdPQK83CPtl5bGs8d1+u59rj3+yJuDnlzzdDWgLC2zbs4 yjuvXbsm2rtlWseQawMyv0NnJ+6Ba1lhe/fadjx6PVZqEteUetnNnR299GY8EjJzofpWuffLSfSF 3ZdFew3xsfFFay/rxtL41/aS86+Rd/r9yp7sMeJvi66d0RGXe1sC8c5544I7nGTt+df0+ZSob3hL WekOyZab2B0F1nzGbBmaWYhJz7WpObU7z006/8zMUj7G+Dm9CiBqQRQj6YjjnRp4tLCBrF3QgAXA XyfFVb0XY0UW9xpau9dKo3g9XpH2agqleHTttwQQED/x5fCaefkabaH0LeGNHE7OgFovnTeY702n e0tKOIjoWrGmGGOzWq4rK72yny2OL5eiSKAQkamY23mdoyow/bLMF3hdv0Lmo9C7elpHrhwl8wM7 iVIBvYF185YDgy2umbxl9WDLmcu744DkXRAiCHH16pNn/q2S29G2aFQvdf+H5oW59knT45Omze6I tq3tzkPtpBnDSrl2PqGYN7Tlc72O1g4hwFDHcywgqK0Ayjmzz3RBocPcKxbiX6sC9cX9Oj2gUq2h 0fZeqXtCLu40ynIeZ/5vF/Vnv+ZXqcn3l+Vfo3dUOj/Q3LB7G4eVhw3PvFaYNAMkh02aMXvtWuOw tnYQs7Vr2+PR9rXda+f1Z1fPj0el+No9EECSa5e3gQzlVrQ/u3ddoLd9fSdeZREdBbhlZOyOOL11 2g6F3jp9dsceWFqit87o2AnRprV7bGdnmXiIXIoAaz7rEg9RlCHfHyJ7kR5C+jHCC8jbkb6FYENY hfAQwup88CItR+hA2IOwAWE6QiHCAtx3NK5vQn4jAn/eVoQbEPj17yL8CGEmwrMI+xBcCEsQ7kQY 7H8Y+bsQLkRoRGhAWIhwD4ANChVigp0cLTQRvCD4Ta5GrVYjBs7O/0TIt1qkOrWU2/IwEKNaGh6Z UMTOD/4s0JEG/6zYR7HlC3bigKXXhRK38HkQvAg+BP7nV7WHELf9YkQyiam1cfDHQpIEl8aeDrhi CUlDuygj5did4X8j8LsDmpSLVtCZ7EphsrhYPKT5Srtd16OfrX/eWGgKmpssestNBZ1SgS1hu8T2 sP2/HMudKefbrpXumPsfXur9ofegf0RgQtAdPBl6NuKK7IleJ3fHaxJ/TGrwBMblE/FSZAXMQvsO ra6fmneBZWpEnhGIUatB5ilBYH6Djtc9RYlPP+U6b/o86WTT5IGm86TvmiZLAzCYNw008VBVWWOT bYWyTb5UJKejwoHTioacIlHxAKGsK3Ma0uSnmI2pSqrYXCIxjafAYbS7tVqN5HE7XM0OzWSDwbGl IEEwuYz4gr/ZSzXES3038yd2TR442SSdkI7jcS1NNvvIkZRHVZW0i9ba7SPqa6ohA+igaDjtXBrQ xmOpJEuyrqbHU+YCu0/3w4su+qHOZy8wF/5KoX9dQRk9P27y2ozm32T6H3k00/+q2WjzmWJ0YgZ2 wbLMabYqP9piAzP4fcznF/mIDXatxy1ptBit0YhBY7xWLC0j/tAje+nkwfF+x8d7HANWhztstE7G dBhdsq52RL29rpalkMPoPW67m636l6P9ZkUmm3kyZvZhtK/SCY88Sif8BqP1mmKZp/ho05kj7E1a jt25GsX7PPkdOUa+Bog/JdL/w35NfmeFIZbpnqH3AcCX0hDxpqXvuo4PHCcVJ9Tpk2l+OFB7bJl3 A0lfXKDlA+9Vx31GgD4le5lOdLBVgBS/YiYH8K4a5hMXbOWgcFz6hFRM5jdyyXWi4/Qv2aqrr8aY DmU/gonjG2BNUDHSnXqT+J7JV7B0Dw3j+VjPyZgZXFWoLps2rs5HPZuZaJg6bQSPvpnSMOo8HjC1 H+Nen2m4RlpBn+yzM2N8b/avRMie3FmmLx5jQL4oe5Kksn8jbgRX9m9PBQsMBfoCtjf7dyJl/7oz VFDGryjJ/lWJF2uCBZGCmH2pPhy0k3Ka0lhi8QJ5tL10tMau0Vj8o0k/e/2pqsToAl/lf+2lWixp qQqCk09I32HULYDCE1hRgJ+NR4DB1muU2axcSnp9Hp/b5/I5fRptMBAKhAORgKhNJYuSxcmSpKg1 mY1mg1lv1pk1WiEZsyUUEnX4FZrWFiqgcRUKjVtlhQZ8iJLmUoWUM0TcYAXrFf5K8Je+kTTk/+hg Rk3B1hSXLezwtTjDNk+LjUfucNjeEuvPnlIUZFLOoA1RQELksyLyFLTEeZRyui3IIRKc6CeE7aaW MiMiN8+FnD6Z3+RLxYOM1emJ8KsiLcwo2Zo9PMqNTh3imYgPu5O6JBXWU8kkwLxOUtHU43Z73Lpa 1KSS8RhzuZwoe9w11fY64bMbFz4w8SfloTarB7lJPy4Pj5PcM1pLfEUjx9++pTXtLRo5Yf0W9sEb mW9+fn1jnXzX6AtWvEElno/d1XTBqqsOjY774pljB/Zc9dvRMV+Cygc4BL+Q/UikgKAGautb0kBJ PyChprq6zjYqcU5iYmFrw+VEu0q+peEecVPdvQ2P1v2iYY9jr+c1x2vOQ54PHH/wfOn4hydbYePX 7XbGAolaW3/2j0oQmWK91ZQusgkVctjvJZp4kPjC0aJkqa+fXtgXjdpL++ntfcnRNQVId9tHa+Oj 6/upRTG6RgvB4EjBP6piLwWOsBufNvlG1mi0li/30tU5kAOoUY4px4+fJ31iH1kxWTpx8gSRBo7j H8UTgD0OgqCDnpH4t+UAMVhblyh0OEVNYW1coQ6NS6GJuqRCnaJdIVgUrNWN+EPS0NXTQBp6qDtH LvkK5QhRTXV9XW0Sa6NWeNRSPKbVaQfJVg5pBcfKa7/tX/JZudUjSc7NT9714rynusJ+n29Cz6YH rp91V6lkM9m8s6554KHX57Ottbvn//TTOZWSXfJaVzy9fNLG6R6H3UvXXnjRxqZap8EjFY2euf+m GffCrmHHavmxWnF4LjyumMtjzkRtLJwOy+Hk3ux3UHc/UgrqxEZ9qzhJP1OcrdcWYjX6sBjRfApg RTlem+jPHlGMfJVwdUJv6ceVq0RR1DtFpz4pJvUljlGOSY4LHZc5rnHc6rg5sc+xO/G+6X37FxaH iWr0uqg26bMmooXywugC+Rr5mqIVFcsr+2L7St4xf2T8xGyfrQfCSjZ71OGMuMLukMcneS0xkrCY C01JI62sYOWlYpG+WJcu0Xi0BZZEFYjLo7vLRguCIdBP/6i4I6OdmtRog8X7J+1oUiKVREsqS8SS Z9kh6OsJmiBm9ounY6MrC2iBr2ofbaA3niFHXZMBDtJAFwh5y4mWEyBJFSeOc6bI4YEHlS4FC0uj suiQrDar3SpozRaThWlLxRKFRh2xfvqE4iJJI+hQYaJIj8q0pkyhsjXCW0y00JJSSLEOUZ4ISU0q FeLw09PFqQ5Hd6LmGtK0PseEOZRwWBrRzDhby/PieIy4nED9HHDFYzotXXLeowtveeO5Xy59tr61 pXLL29fPaPC6bRZ78egXMvt9yYeXLX9oy8J5s5uYY8UPjz5y7//esu7J3/381sUPLYxZfXaP0ZnZ 8an85lMPbl//kyemjwCWv5XNCO+Aa7vI6h0GYS97jGhpt1LCtFqBPWcwWyyXuojT5SIuuLGYPSaX mQgSZZeajDarZBQls2kvvRCiyq92eQw+N/DwDOk/PlkC5oHyNzVJEHRsHlX44Mi3pqA8XfAj6aCX SgOjsQJeIn178iC4YZ2svjeInuyig4gj3DjwCw71gpDZpncX2L1acUlyYtjvDz90y6lX/DavZLSD 30GyFPdjF6IE7OkpJV1vA54HmktHlI23n+M/t7S9bKp9qnuuf27p1LK/l1jTpKSktJwyVmaU+tkj ituywfKQhR21UEuxzWKRbCGjzR4v5k0FyWRNSTJZXBKKl5QaBLVKq61RJyhkYGU+h1rldl9gd7sd 9pDPbosFedWECImsjmyMCG9EaKQ4EImAu8UCfn9pSUk44HcGAn67zRZmZZBtyhLxOCwwhIbT1vII zKblBl9ZadLvSEKI8u/FFkUpbVacJcmAYjW0EBu1gkkeC3wdEIEQpU9VsqStLGnfS5uJLXugz2Zs Aak9oEjoa7VRYpti+8qWtYk29O2raFviRXozl2d6QNCADmDRPDvAl6sJ2MElxYouVUDF0q3RlKex WGvKvek1PzroJfr8olHpm66eipMHh1b8PxXVq3UADx5yQpWQl2zkHBWtoXlyKtOzGgQhLgjXDbzX 818cEDIv8XgMXfF3ntJf0gfGqNUvR/z+yJZNn0X+RNdkDnEg8todHuFzj8PhOfX8YJmuYQsGfsY5 3qrsUfFc8UlY/I4qV5c5aQVpge1S0Lhd7gs8C50XuxeXL3eucC/37vIYRwTrKye6J9Zf6Lmw7jLP orqbg/dXGGuqrNFADFsB+gK3Z0R1NB62WohgN8V3pe2FI0zrxHBheoQgsrShIKnvlpNJ/6hA0loV qaqoaqkSq3wj11yTWxxVeD8BbWHywABHIlV+4jJUjk6pIlSOh0GmAtEik3pN0yf1JqD/7yHB7Jc7 bU6yN/slCWW/3A3JIeh158WeTtrVQ7DaKtdyQ4zIER4uVOjArHRaVBGQmzO6AdpT5UJdXa0dhEp4 j0+dx2HzMM0FK++ed4GSHJsKUmnXkq1TbS67O33+ocUXXjThotuqb/50zRtipJEvw58jfm9gxpjO dKTsvLntHZueyXxx0VyX2+apmNMVD0zYeuesrddT1U3sIeDwSuBwLflGuahbQ60Gc1qSQgY5EK6L xUKBmjJrZaSSVaZra0NlTK+ppzSkt/tcaZst5EuWkmKpmBWnCwtDpbF40lcL+pyEUslo0uBjBn1t YVlhkpRKpVNLBUgYzUppIhEnNCnFkiQQDbCpgS2BN1Ss0gTOt0UlSqTV0kbpa0mUfHXf7aH6nBDe 1QNFrquH4wko28muE8ARTuYGmoA1AyggR6HDSN92HYEuQ6VvjzSRfDpYnWs/06wCv03mypg2Pgj7 NhX2sQ6yTV0kEEWbnF+2wRr6II2qkB7gcU9P2G81hYWfAcq9Az+iZd4cxHtZXSYyCO0q9FuMmaP8 ikOZSXPV6//C47kcB1YDB24GDjTRpNKwPvpAlFVILdIUSTjH3J64wNRlviDxC9MvEs9o95oNYtwT T5pT8WSiPqGtJyM3kpEjSai+roKTvxprNa2uL6+urigP1Rn1kZRU5qBhj7eZ0LL6kkhIEuRAU7K+ Ill/SR2UILmwQAAxW6xEnU4HKykUDeFLysvLwpQSf3MqadVH4AbjG71m2VkIoqrTXMM90YLZbuEC XsXx7xElp/HmpT77SEiCKsfBqnSBdKEE9oOCBPYzBIfGGKECfUk00JBKs5+TYoSi7Oe7E7ASxAcx qaET7Jyjko1zqnKWRxFPbY6jD2IWECuHVSLHKlt+dTXqWmvFiu79c9ccumPKbX9Z/9p6HeduXrvN Q7VvXrdy37R6Sv507o9n5ZaK3h32S066M3NfXf3UjTtve2At1axdVuW0+sPPRXye0MwlC+/ouvL+ N7+LFtERwFIv9Tgsbh1fUWBVB7BKJkuUBpupoM5uD5k4ShESCggG7QeMhQxOv6fO4Qj5WdIU8DOT 3mqgBj+wI+yw+2KPXjPEgPFJF6Ads445VmFbhekzoDwI6QBp2DW4aOx2Db50TQ6kAdE5SKdvs3IO oqe7OfS98gqP6cc8FptPu+l5EIsjmYu+J9mc9uB9YCkSD+B9GlhKGfVR6JMwaycTGw5gr/ot+l7w zdB35Dv6XchYSFKhVDjZMD44K/ir8J7wEXKEHgl9Tj8LWTrC1GznMOp4yEqt1oiVWYsdVqvdETJH Cnm9RGJTYyxWnIzFCpOhSEUdrzRVw0uwuq4+VGHSqGV9jajXa8SQKeDK3cxLrd6Il3mLnV6vyxkK lBfx+gKSnop93OJUOl2UCpX3Z9cpwRAl0WAoFKbMSXkcbiAkHAo7UQVhN6SYwoXJSCQcDoaSlJcn BoOBhhFMcCUDrLwiVZ+sqDCZzKIjadYnUw0NoXA4NKI+DJnzMI2k5qaWpban9qc0KViNalOKvc6a 2pB6I3Us9TXq+tmfFFcoQudStoEehkmHisGgyJgY6mfXKG5HVBCdYniK47DjqOMrh+jwjXx+mbr8 kJ1B3fw+6YTXNrIi99/Vg2JXOt3jlT7xc8lBbeAEUaWEnBZKTchzUonCCUTcIHWCCxWQJtboIVVo IF2kIQOejZlcMuR42pND1Hzx3xfyCD3kMgDh5cDRHrgKxG1nSRCDsFhDB2WLf9GF/bw786y0mYNk 5jc8Hl/H499iv3fkb7lwUdvO48xrEOgim+10Ljt62j2M0noGStkRDrhD6zmdLQcU3wgoLqXLFLee UUPQF2QvM2qi2kCAugOiyaYCWUGxvaDABowtTOeAqYgWFZcWFaVLQ4VGUe2iqxF0OlEIGf1OtexJ g0c7gcyJMC/H5JqQLIdDoUQAaiINBwNOQBMNEEc6WVgYTiYSrJ9d+1TAmQTmQ3K9FrYnk9FI9aFg mEJUVAKElCqFddbSKaVzS5eVbig9Wqot9ZczmDwCvLvDPtexzLHB8bVDtDqow1c26gdniHRPVxNM QKrhsysNqvGJavvkQMBFTQAU/1etkmvK09waY6V6Z1ELddqCiKRACzeTdKqC5/cA8u9hYFjLcIDg GoYq+8hx+u+BYRAs8iQqLrIlA/dszi0yj9vBY/3hD9kSAIUvQutVoBA9p0cPX/VTnwov5kQlkCxo Jx1Y7eew2mVkBP0v+CZmDyrnReXmtBP88MK6S6quqBJ06VFVE6tm+zuqVkZXll5dd3vdoyWPVx1O vh15K3o0+XbZV0mbNWmoaou0y1eX3hxZW3pn5L8jW0tfib4qf5K2hPfBbGeATxjoFIQms9kKuUmP hUVZUwMzDoOo5FWJXiPkJZfLbgt5SyPRkrSsjZWVxiPlpD7p89mTXlZGwhXlisnegsjaUl6u9xbH kyUlBoNeH9nLriVlbItigbmdhqWawiBJ0mQ/7dq9KrghCOihRWiL0amxLbE3Yl/HxBinXlabItEK SFJM8jVMzOsfXMTNiVLHu453gSiASqi2QpVEqDoIFGiuhXAQUTm4KvEOIRTDVvusAnC/ARzdnpeK d0bM0b1g53L25K60uc4d6c9+t7M2WtWf/TwvGZM8QwfA/Vv4yEGFDhJ1nprEWTIFc2w9t/3EZToz BylbOFRwaQz87PTP3r35wdmrb1d4afmDW5dlvv34h33THrsm8xozZiYOB5uXfzT7obrmB//Ka6nn uboZU5c0zLgP1GIPpDInpLJx5AOlZHTNuYEpNV01V7lvca/x3xZYP/L+scZzou1jGAeJx8b8auzb nk8833p0Af6SDm89t7t1ppXi0Y1+r1XjJHREQXVlXCiv5dqJzeRLNjXV2gpboZ+Ur0vVFsqtUFFS ellVUkYUzg0vC7Owv91ZqFQl40llzLLiVcUbih8q3l6sKfa1/WwvjQyxrxw/AbSG4gJbfk5zGVRd BsAb8upLzhSg2t/sXHnBClCQ6a6ztRIuO7mcYcYtnXmTyKCBQJUszlhGuFU0b4kTNuXwzu6hmodv WvdI+bndl2wdM6vzkxc++AmfVgS07Pv5z59ub6u87805c956sldsDvLVeQfWyMCMWzbMqz6/JmIL hlJrL9r42m2VvOkzrsPM+enPl4y9NOzywyvi5puwXQb3euB1E/A6Tu5QSqCu1HF1JRaM1MfjoSA0 lDquoTh87nrIXL64HWwCiogeds5lT0mSLYxbIKtEpWBFsDt4OChagy3BKcG5weXApu3Bo0F98M+F nP1yDR1bOeCmub2cQRXjjNw1XArj0tfZ/G5QjYBYltMnbGzj+/zdBv7G4/czv+LTIzzJp4/LX7yU k70yf+CUj16VuU1NIRWS6YDH6/HeOCW1D/rm30kk+/edESnINw8C2b8rsasCx7WfBD+P/C/7Vvtt 4O+RU1GDiYlaGjBFbg5s1mrtXk6aJOKSXMxV43O5vL6QvaSSVxaQMlpWTMrKKkmoxGZUSZil2GCx GA0hW3Gcl8cna2Lc1hoqrgRliieLi71JuzFpt7EQFIeYDK1hGdaGWaG+z+VbMNU+f1ivn2KYa1hm WGXYYNAYfFVDuBSYVJ5H5XKqNnGGPf3/YTzDeQ1KWALV2gfgprkJT9Z9r9LlBOC4zclNe/X5hjOC sTDw5S+Xb7t2fNhfYA7neMzm5348/bZLVUkkVyE2D4zd8fX8l69mz2HFLEa+bANj1z1/7s8XqDXQ 0lVpuRAQ+ghWqoh9s0PLWmd0KF6Xl7k9Gq1IRX2R36lNRs3MkGCu4hx55buSTep2IbeGBpTpy/zL AsuCy0K3um/xHNAccH7mNnRL3bZue7dDPMyo5JY8ilvxiF4W8IR9kVC4qNhTz+rdVZ521u4e4+mk F7o7PLd6fuV5lb3ift/jtKgWM5s0VaJSnVOSHM6QxemSIZk+ooQT0cTyBCMJKTE1cSDxRkKT2FiU SKSKQnIRMWvVLgarIWJgVsN+w1HDV4YsFnOjxmDQakJmjRj18y7O0NwQDdX5QiG/LxT1eQleONqf +YdS6xKFqFMjimGXE1ZNZxHEbq8P4jqsBEygYa8HeQ+DG5QQdrnRw82Snn52pRL2JrFBB/lbEPWp pOzn/9GoI2nRJi1mRp+jpQR72KBi2MOmXUr1YR+N+KhPKanzKbX1tb7VFcjEE7U+JZmq9SUVa1Gk aG7RqqINRQ8VHS76qkhftI9dA0HBA3nL48ZlbqUCAZe6FX+d1f2Vm7n7accupiTrwNWv2amJup7F 45xwii4lIi1TXBEnPeCkzqSkwYb0FM0GzWGNqHkWrcWkjc7A4C7OGf1OgJT8xScdh7yeHujhxmjv Jz5poMfvPcEL6Z6u42j1Sn9RrYGqiAZU4OIaOPOJAVV213OLoAbC+5nM9yZC3G+oTbDrLKPgPxkN /7kCVwB9JvUmwbxLYNJ6mq1mfo/f7Qej4Gx6Uq//jLGLwdjF9B44kexwS/l21cLV1dUpw0gYFwZt iHmcczhqHI6z6oR3b/rLn2+6PsIJIW3gVO7gsv+58c9LX1Qr6nlFRGg5DS9TjlU8nI4JFaffFP44 WAZNXABMWwRMq6YP7iGx7Kd92O7DpsqnSh22F5+KUUPcUO2L+6oXxxdXa2fbL3LPDc2WRb18cezu 2KMx8W/y3+NMKxviLtkXF/mhLC7K1eVFOT/cjx5RLKG0HApF5ZBfjqWrUNMnldPyfvY8lNPy8qrq ULqaDAp9dXmhz+fYyx4hbt7njIG6JMHvVpNKx1OpRDxUEo/FqBSzEcFnqI47qpLpRDJdEk2W+GW7 XbVBg2nFk1Nh0Oln+3cDwpM2mM33K1Y5SexT7Bvsgt1XM5SeYpsFZIRbxwBEnKKosAPwgZzXBNku JwEMARNsAJxVGkZ1vzc6q3abIcV/Fvu4xgfJzwcQKQTw9BGvzdsAqIHw38P38v6JMw5amQdlOnp2 Bdt0hlH6Iu9nNlRzsPiUR9PhSV9zPoePT3ixmkmZcYOMkz7DygfBI5Oivx/MY/rY6MyAcA92XWyk XUnCJvNXQqpNkBf+Smm13mSU9HZCEwbJWGmcahSMPvvCx3IqOPch4eaXs+yKQ/n9oB2R3fk6H1Lm WM5EKN71j/18BJrPuckFY6BNmQF2tzqGZiV69hgkk91gTNAWwPXg00+DN6pPH27TrKrUnFGaBi09 rOU1/mwazRzj6XbNGG6S/IcqU4DIbYT0cIGwGl489XS+Mu1x3SORx8uFpK4w0iiudFzlvzKw2nmz /y7nPf6tui3OR/zbKnbrninY4dzl3xN+reBklcsI9+ESKjxgu9vPritfW765/PGCreUvVr1d9XGV vgg6xzbFX1ghFxbG5FiRPeTwFNfLpL6YCjVmQyn2ko8ps+mtRcRYIwsmg8xtwsthEy5uNJuLnA9K ckjHGywkGpUVi7vFKtMKuUWeIs+VH5K3y/vlo7Je9jd4NlTKWt6+TPuQdr/2qFbU+kaU7Duj+nbR 9OSBT7gojM2V3NQNbjlWdCHX0nRSVWsGpWEY8ofpNqpFkkMxt+rvJzqIVrXZr0kdgi97ss+uL9eD 3uGvE1bIvPHSia77SBhdHNkDvAVCdZdcBwNlbp/a7eGKCkz9eeMyzMvcQJeHfIHLVNgCUKWSEULH 02/89PFj7466dcrq1fN3RA2Sx1iw4MGpD+1czgH+xcabznn60vOuunzpvgXXPHD/smufskq3tl0y 0ggLptHqL/nZggEYPqDH/LdNmtJ4/rmLZsG+zEgZ1n4WoC5IimhiBxcFtikmqUIVA2KWoJuXHb4K l8/ndsWCYZ1ATdGkucvUTxfsTsqGqAyJeYFSIgThhKUzmEKyFTPPtP6S+AxijrqcfIPM6lzmPOoU nL7ii+4Yuhx8EeAXAN1E3VNp4mwOFMl33Hsc+iXfVBlGdIYW1MUw5xdDmXGZgVaaKhPjiy4ourjo sdijiafpHtMz4adSBzWv6Y+IH+qPaz7X29xiFa3WjDa10immc8IX0JmaLl2X6WJ6iWaJ6Qp2nfG6 8DWR28J7I8/Gdhe6KVjYTpNUBI10R1g1MvPF6+mkNqwRtoEJNmJc+XU8Y0mlfDXzC0ZL7nu3n2oz f9v94SaVceU0UOHn79911/s8iJ8OvPVS5tvnD2a+fulRLtqLzar59ZWH/vCHhxCA61uxOpOAmSXk 692yEeq/CyqkUorMy64PC3+fOhY5Jn9R+HlKl3Cl3OOikwsnp2ZGuwpnpy6zXuZbXHibz+zmbiIr HM5OxwWuHxRekvrOr9HCZujyY3PGXuhfK22W7vXe43/U9Sj6xiGyW33OgLpj5gt6cvooudUmF+tM faI2+N8eOW4qaNR3bonQjZEDERbxlzpliE+Gli1Jak1Gkhvhx+lLHxyyzsC2yaoG2jOZ72ie4Kh2 AgvMN/jzjh980wwFLCqX0SGoc6V/cEtM3XhOcVQYxAQVSeAnh+34ulrsjgkvcnIGAzv2wbTb7973 /DuPz3/tfJdk8yx8+JXXMqeo6bVfC5Ygx5LnIn5PYPzqz3/68JEJU50eW3rsD6jw8msUPmKM3IDZ 3gpcCGO+//TUOSWLSnDIiCNAAdFQTYXKwGP6MFSlbYoUqPAEAl5PLGx0x4oMXUagQV+RjPkGOkRj sjNMzCanDlIo9UQM0dX8PBml/tJCeTXE7H66vi9dsjqHDNJ3Pfn54SYXzk+wSS+dOI7/kxwPhsL9 EIqkKjWTet15JOgrwDllTmIm9Q7ixR54i325M+pMcTUwCQkork/4ztCoM4w3rtIjTpAwsZ5B5uEY Asoiy5GYu/50+ZvXXPPmig/vVcvL37vn3vfeu/ee98RPTy3ltOWXr1xz7Kqrj177Cn0/B8lbPvxw C4dkpu5jVQCSffAgfUNZbHTf72LVbCw7H+epXmIvOX7je9/+vu/DwP94P478w23xBUuCtawhPDFw bmROYHZkWWBJ5IbA+sD9wfvDT2usV7j3Bg8KB+2vBl8Na/Uv2vzRKDioLSR7dKJsM5ln+Bu3ELoc GNRPP1Y8sWgjbdzipMuc+52HQYpEeIOVPPE9KeqZDCsJ+MKJnBsKTNZcRIJr35DJ3Ol2akESdgWc kTCDI9kZUg9Bhspu91mbtDnIJDoVbnVi2elfuT9+7KLfjnEUSF6p8tsb38scpdZXfkuNs3xvb9p0 xE9/9vDLzTVWn80mVc+igVefBuX4Pzeu2/bE7YAgnBwi4mxAZi15TSlUzFM1qzU/Md9YtcW807wr /Xz6SNrowRaR+RVJihlqy0kVhTAqPkUI9sH0mn6qKH5KY/pEUYwUdhXLIRzij/rKy7xag94IB5r1 irEehu+o/7AKmvcolgqX4lruesMlunx1V+yhr+e3Wief5G4ITXCX5FJkE/ItA6q7DjjlUCkEO62D FaoDT0FJOoAFLY2QdKA4QvmRVnjfdGFLKqcEDN9jra+pUXH/jJFJRX1Xvi+roKolb2AZF2Vee4rH Tz1xx1Vralxep97x00U/vIrexisFy8D4QdmP7eHwuOqyB916t93uETxL2lbl5C5GfpS5QbwBkJki NTSsVLU5lzvZh/JbhV/KxwtPyScT2h8ULy1bULGg5lrL9cU9NeuLV9f8rPjOmq3FW2r2hguYnlOD +SqBMGg0ekOMkXC6yhuVPFGsZUF4U5UcNaZlsimp0zcyLQ4zFoWiNGo0SoYthl6DYDVwM8h2w2Ho zf66cnl1fGN8S7w3Lu6PH44fi38dF+O+2pJ5w4BVFWL4nh8WA+TiRMtxTlK5GKpaZodQDJVIDIHi fTAHnSR+uJ2W6Kv7YSQK6+EQeHJnqb6SJ8XmGl5Z5q743hCbB3QuudC6QZnc5tQVsLzHaw2860bU 13EqwuCXUFM9lHQIN+Z4X8K7fM5kdVv7m4lXpdxr3n7y1Kkn317z2u23/+Y3t9/+GnvlAZVi7Jkx tvSiIgjGXnruOSVjTu+hdPduSjKT7n790Ka7Dx0CLswELiwFLjTQy5Wy+/2nokyEj/nF2iu0G+nd bAt9hPXSPmZ8VPsL3S7Nbt1Luvd0R/06v94GwwHottUZcTLnHK8Ttv6YrRh74xB4SudUlpZWVMaK Jdi3OL2H49Ec1cQVk3Lyq6lwTl5+bYDStU2J11VU1dVVV8UaaLQ4KIvFRUVY7gYi6iSj3hD1HYX3 ej97WDGNInK0an/lYfhJ9NMv+kaOzy8l6A0nMipG5Um+amm3/VuCP0y1Gm7gOrspZ1rCVyHgfgTX Qcgyx3ba/LVQtzpVhJT8AY1OWxjQYM/ErwvmUBI4CUgZtNDvIdrsyd1Rc8SZk36gsHEByMaZBKy/ gzLqGdTl7AIOK/9UnxeR6PlTN104/7Y5F0V82EX+ivPii35yxZwxFUuGejyomA256NSs8W0bpgz8 7Qz+ChdeWxa9auDLwYqcqAS+8iygwa2BqgwJdpVSEvNV+xTf+b4FvpW+m3w6h0XqcDpjFq3Z0KHR xMzuoO8eF+RY4UXWT+9+Kqi1mI0EZ3y5UZJBDSkQRRhypsBs4wtNW/W9jgdrpLpR1vIdMEzdZh+k b4MpVL4u6orXOc6iafIgP2Ubr19FJ/L3HvBy8kQnfst3KTW23/8+M+20usXAZUBQKsgynObvw5s5 Aede0qXUznetcP3EBWJh7uA0HlS9g1N0u9d1j80W8xIQckKjNgmeIfslQfL5ho6eU+v/MOp/O+I7 h4/3r3y8g6z+e3mVjxUnR8T9oKHtrERpso6wNhSMtI6yNllHWxVrq7XNYE+a6827AjtLxRStp2xm cL5ufnClbmVQU6+rDrbp2oIzdZpK/YjRKvYdHUVHtTePGjW6OTbCBcPLNiUctdOp9jfsx+xf20Vi l+wKTBztBXa7tSDmKozwLvARkOAj0B6OxSLhWGE9bNe8skaqYTXtFTU1lRWx+naFVy482kpb21ta W5WWWFmFNpwsLysKBbVUVzJCaSTt2hJZ8MsGg6AbUV9fWOgyWgqiMAFG6irdq2H1O50MhaOpJC8n V+N0xulmUhFtaeaKJ2ne33wYn2XyjS95Mgc7OUUTSM43zvIJVoNbX3LUGma8QesLvGH+3Zb72eg9 VAo8az8edGEQ+bVAfreK/GcTgTwViBYVe3E8QtSYCovFVIRqtD6jB0ftNSUR6jVji4GbZ9LcX5Z7 W5OuLpCHQF7chEuOMfsXIiLosu+DVrwPYvPWIK+gPdg73oMWjMDfDLlJTUGGDuxEGbeFW32Xw8VJ iUeVOr8nKHGbKnieISS58hDKcrbO9dkPloyZLzesGHVh/XiY6P3hzefVlF8ypl3NTqkqKx3dqlZ/ xCtyPYT5M1e0tbe3NZ47e2A3Jynsp8qMtoUDb6n5O1tnhYovzhXyKIkugPIlgPJZgPIGukYZ8bb2 bT07qD2oZw/rd2p36oUe3WodW6C7WH9xQNgceFTLrov00V1MCEYui+AbdXDpCANfVai0uiLYZmlX t1li9rN5kM3EOxUQ+Eu3GwsKTMaYLceDJFIoFbKzGJGlrj3HiKobG7R0Lz1GotBAHCFZ1IEn2aH8 G4xR/1EYvzk7klR2tLFyC9iRj/Mi9VwSV8QHOVEOOOF82nLiDDj+J/gb1jasMAQU/x0fcgaC8FDH R5WYNqgBwAX08ITh4mGJyosGgW0nbOnYNN0RcALAYETp4Zp4T1cXKG4OeoaAT95V9SwoOsOmBtnR rI47OrunNFyogsafOFlu//HS6df2DOVGapswf1XnuOLwunMGvhpkPkzovK715oFvzpRV6ZJrkHdC g2wChJiwcTBBabC7RTf8xYVX6aumt9kHmj/o3jZpf6BbbGML2UJxsX6x8TLLEttCxyUevUsWrLIB 5i+dWYZEdqDP6mtR0wKPmioWV10voRIOwXeDWfWzNYrXDnsXumkV9FkGk9dh7THt11qNtp9+1OcF CRr0K4Y2fQIukvzYBDe0cClRVW0GXVT34czRSeLEVrzkLHB69mY/grnqoz5L2BZWEVqddMw4BADu EmJyc0cQJ4/g1/yd4rCGW0xORHojIh2PUP+lEsK5G50TjgsmHrmdNk+zk0cOp9XJexxU7MgYjWYJ VyJigjXSxD94M/yvk3Jby6A+NVQrbcqcgPHkL9R+8HnqmPmnLVv+xAPdfiDzNbXt5wfBvv71z/94 9GcPHjuKtSmDnM+xtxDqUZnSUmW0jkwh1JVNw/HELsvFFGui/YFlJb2u5PJy0wvaA8bf635veD/1 +6pPtB8b9T58IOM63XrhfuEJfNEDfjkQG30VIZ8vGIq5c1zKZH9lGEsaE6vIcyO4sVdYG13BRkhO BRWyyVgs002ijkQaC7VJ2aqnen9NKSmIhq2hKdgrWxYSQ77qocYyjqH8tKJqKjvRpAr8/0reH4aA ZxWGq7NF5krugFGmOmBYopSvelX2DztS8TNrrq44N8WoWMa3/LnR699KeEOWhpZMeuKK63+3IjPw 7J/W5+zeqrqWN4H97K377j9y5P6fHhHm33/hnJWHL9+dyT6d0XJ84jZxsZHrApnFdx5+Y+OdbxwG 5d0KyjtbuAqUwaU4ry+gpYYpxsvs19hvs9+r/ZlDF1RNzKbIK/FIJBaPBQOuvWwbdtgUxaC6/sUC afgRblOmFJ2XKCoqTMTSpgKn+pEFjc6CTzw4CyRjorCRpLXGFgmE09UYiDXCKcto1X2NY4f+MuKM JqzxqfGccvZ1XBv3lQ7c8T3xxOEmuGHmvDC5hQvcHpYbbrzJcXf44f4bK85ZazTIu/8lwQT7teXZ 726Hs8BtD+bIIT5Yk1uhYU6uZ4l1Z2yUjD3ycNukG30OY4EjXusbsXk/XamKpUu5C9VrqiOVMP/I 3TMX+h2QoOP+jq2ZWnVp4ArLnlHVZkoOZ48KGWDTOPqNcquzJTiG2c/FB2wWj3si+sSI/2p43fHq 2D863nG/0/zB2C8cx2s/G3vacbL272PtJofWrWk2jI04XG5Xc2Dsutg9tfusplmO2Q2LGy5rvLbh hsbbGm5rfNS502m8o3F3hE3Tp+HvVKWMbqqFt0yBzmUeSWrhLiOW11sLzIIRHjO+xtGj4YzdChtc 3S4hyrfg6L1KMFkvy6RRN3OkPCXMnWYEOM1UzYg3FrtkhZ/HcIN2Kp3Liim8Zlp1gjZplE0X5W1y XCNTT651TT5J03CGytmpuQ8NJ5+qf1TOgSbnNpM/TaPaNHHSRVWyGkaMtUeDhY5CT7MrQhoDIyN0 RBSRfSyK7hZvhMDbbPSoUBP4nr+xqSFSHyHOMTZV7OISIiQvRMA//qfyw8HV39XorDUGn8l+Sjxw ix4HI1+zcwRIbl/M3cRhIveX22LrUiWxBtBjA0TURieiBk6dvZILJUTjODke5wQBHueEYTnI74OZ 4Z2e5kzIyaPcIHiM3Q2a8yMehLbcYQV+MGqIY5BTNdvCCZvLeN8fmkolE8nc1odwPVd0vKrNtuH8 Nbef19heecv2cfPm/vbll1fpXRbVNcjnid+/7JEt087PvHzruUc2bRPSIXDqjWG/29eUahiZrmsq Clod3vj1E37wy4UxZ4E//CSA2FUeqWy5dtx5FRXR2kVNS1ZxDeUucOZG7AaXkleVxKkAtQT8AfaI cbfxeeNbxuNGzZUFtxTcU/CLgpdM75i0Hj3VcQoiwsTg0ouiTo/9WKfBhTNWNrtT4zMX99OHFVu4 MZHQNVJ8+9Es+0zOW3HC/DHFWVoK/T8pv0SCUjAKz6H9QQ24xcd9ZVwpAAU/DuIAaWvQRZ674XIi odrCh5OJnO3MHzCaTH5DhBgD5ggOsXHbmboV0UUHzWc5v5Xc5hHs4jDEDDq3DNrS3C6IhqpHd6bh ip6ZL41wWnDKL/q3nk3bVCeWzXwxhPkcuQfePGd+TdTis1kt8uS1V7AKXqme5OHzeCHmsVOYT1Kg xGajuNvNitzUD+OjyhDNFXqz2aCPWXNGclPgvLyRPCXzdnxWlibao4mEHI2lqNvqjMqNJGX0eBvh W23VGxolq9aJrT5Yc4kHW08PK4ZiyRbVH9ZRHO3/oq/obOMJJpJvKQzuaOfO8A+3mf8HQ8mgqgQH W4VbSaLDTCR2h6jVFDpEW4TYtc7czOfQ0JEnws/inPaXkJ0+IvbsR8A5vvGnbu7B921Q7a9R12bE 98W8BU245YlXrlOmqwaPFxedd2irugxfqSLndQ+2dlzBwupi3H7+Zc/ksjkbAV+DRnDDu7AGcTpX qdpKt9qfcAhRY9QUNUct0YKoNQopv5E22Ec5LmGX2hY7F8e3o9PjDrsSofx83TbFZSEWyVJhESzn qcfrYjhel2OieFscj5uTZ6Rxwk/YQRnRaueoJ+xgeqDcvX6b0uK1qs715+U5rNNhg+961G5zQudw xgnBeVKnw4FPGlFi5NwUTDUgNRqFRqNBG2909tPLFJODNVbYWmzbbYJtL72MOKhBsSh2WmlfZt8C dV+0P0u3A2YKqZz3l4GP6ifwYlCPMn7vsNzSVFEx6ML+r87FneXyclbxnzxicv4u/DQJfJPzCkMe 1eL4BOJZNaz3jswvL1BNOo08XkdrC2n5erWiiVu7ZgoWvpTqco7PWaJ5nq9kQzYr3o2VLBJKlUeL 3CnPLcLj7kdhqNzj3uXREyaxVe4N7u3u59xH3Rm3fgs+2HaYCfgErcsrel1FrFgscqU8DWKDa4I4 wTVLnOXscHX4OoouoT8QF7ku9Vzqu7ToOvFq133uez2/YFvFX7m2eHazfWK/q9fztO/polfdL3s+ cB/x/Nl93JM2uQNuHIxwpz1rfGuKnnDvc7+kecn5ofsz+pnn7+yU++8eW25/uEA6s0Gc8xPbppQu T1ACXzElIXzNc1vgKiYsT6xOMO44xhKJ+1WvsVjea2ybUjxXdfyDRSsCA7jwlYFuVx3IUEENhvtV B7JY3oFsm2ILhSpU77EYvMfuUb3HshOV6kHvMewz573HokO8x6JDvMeiee+x/dCPPXQloOkYpt8F k19cxHctqTBDNKYaZX9j1NFo0Taa5WjUYjFrl8GK+4IPW9zrlSTZ5FMq4TVWlIbXWCG8xpRQGJHP j8hqq/U1Kt04C7CP/hK6hoeug9vYTKZUjaxlvB/j/Zgi2WphePylYtFEu13U9YJT3ORs1HCzSGUd T/oaRtaqxXSuiMeo1biDmuJ6NcXNeKrY3Z5ajeKqWwX3Msa9zBg8zD4ixUMw5rsunAfJ/53gnmRd 3NEMfwOqm1nXoJtZ+iS8zo53EW/OPMWlHP5rgZsrdiKx1fD/6mh2FpZVQF3v4WdHvncW+obX/XNl 3ttsUDvdXaT36UXuS5YXaOjlsk7A563zeJgnqPGhjmSDdcKti/b0L9pWzJHxUx794J6+i/s3XMYt mZ9wobeIsiC2sIZg6CXMOfAlU3cjBrF0IejtZcDSVnaXck/EFrEze4Ntlo0FuD4eiXXTpfZl8rJ4 d+sL9AXpt/bfyq/HX69+vvb5VivOKJL7YgJ80OytNntrXIrFJRlfgaNybXUcnxGI0monXIxqW+12 e1SudcpyLcNWpbURhNLRaG+UG6ON/qrG6sZEY7yxZGxja2NdY21jo9La2tLQ0BKPp8rLUy2dmtp+ Wr4r2vpACzaWjykBSjVmWXabzRrixpcRQvQBq2YZQMPfVo32vvgDKbvaT34g1WkNVeRVTk3IN85o 9BtLtI3aT/ZSHXAEx5KHCMLHfSe9J3wSIq6I+iYf92KjtAtSsA8BTLeCtx73n/BKx3klr8infuKV TuDvrEiTO2OyB+zzN32+6hY7PnXQ5ynj6RN9OHWC9Ls+e5ynH/XBxoH0jzsDTc05aOanUPgpaG6S iEv1uF4qxcWSgitxBj3eIoVxjRSGwCvFzlylHl6x4i+nae22eS3WWmx6fbYTKcRc7I9wtbcrZ8Cs yX6kGGDGsIVhwUCvj5SJyNiMbk+zDSyzuXUMPjVCedQ6At8loTxqHYGPk1AetfIvlGArwdoiG0PR 5loromqnL9Ascbm7mgvaSPFWatoKi0if5GyGpeugYkEm3oRI5lFeB8hjsZrkJHIujFO+HTPkoOqZ A1Q5m1c9TlTBOZsL4oNYcZZDnTaOXbMbkzi6GMn8lSPFusyezD6VgWW+whFWR5LemHk84UD7x5yf XUwDNHQxRyEcDrQ6EvTFzAadGwI7N5bSkZmXc3YxnHaEYjpBr7aA32W+orYcHzS7cbSe3AN7zH3A qmr6DIQJ4rV7Y2mL7KmjdbYpFsVzyvG/MZMBX7aYGFtEF9mudlwdu9Vxa2yP7VnH3thLsXdjBWCg 9mq7rdqRk2nCFkvFGWEmEAuvDtPw/bEwLDCBWJx7Z27bVV6p6oaevHtmLF3tMOQcPDSa+3PuHQac b8WxLbAcT6WHeirUo1sxv6Oa+2huU5amUhWqk2YMTpqOahwpjzmxDWoD+hLYqewOQqvRYMcxf31Y Y8f3uGIQe5yNfj8wmnHRJ9FYUtWIz+AUkPDUMFsePhb+mmumtVM1cBOWNFHNcs0xzdcarcZXU7KX crlH/XLP8a4e2Bh6zhgZhgg/eS8aHN5Tz+5xnID37zCn37No8dkSz79rVk/8fdNVIQ2n2icP6vRS k55/JKCnS87LQ/8BvAZP9OWNsDJbkrnWF/ZbXG7VS7MHH7A9XxWEP47gTG35wJc/4aQ6ox4CoTrQ ZrvFZVDFpylsRw6EAFyncKIrZy+Ckw14rvqXieOrnFyyOvuvEhUC7LJmkvvumQNfOvPhy2YJklS/ XVYBw2oVvi5aj6+WNahfDG4mCs73tJF2Mh7fNz0Hn/CfhC+OTsE3R6fhe9HTsQ99Ab6K3AGjx2xy Ib5Ryv8ogaOomtPyPbEZ53RMnjQx3brsissXL7z8vIVXTZ0+eQb5/wCkMHv6CmVuZHN0cmVhbQpl bmRvYmoKOTQgMCBvYmoKMTgzMTgKZW5kb2JqCjg0IDAgb2JqCjw8IC9UeXBlIC9Gb250IC9TdWJ0 eXBlIC9UcnVlVHlwZSAvQmFzZUZvbnQgL0JCWktFVCtDYWxpYnJpIC9Gb250RGVzY3JpcHRvcgo5 NSAwIFIgL1RvVW5pY29kZSA5NiAwIFIgL0ZpcnN0Q2hhciAzMyAvTGFzdENoYXIgMzMgL1dpZHRo cyBbIDIyNiBdID4+CmVuZG9iago5NiAwIG9iago8PCAvTGVuZ3RoIDk3IDAgUiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PgpzdHJlYW0KeAFdkMFuwyAQRO98xR6TQwTOLRJCqlJF8qFNVKcfgGFtIcUL wvjgvy8QN5V62AMz82BYfm7fW3IJ+C1602GCwZGNOPslGoQeR0esOYJ1Jm2nqplJB8Yz3K1zwqml wYOUDIB/ZWROcYXdm/U97ot2jRajoxF23+euKt0SwgMnpASCKQUWh3zdhw6fekLgFT20NvsurYdM /SXua0DIjTLRPCsZb3EO2mDUNCKTQih5uSiGZP9ZG9APW/LYKFlGCHGq+V+noOWLr0pmiTG3qXuo RUsBR/haVfChPFjnB3BGcBkKZW5kc3RyZWFtCmVuZG9iago5NyAwIG9iagoyMjQKZW5kb2JqCjk1 IDAgb2JqCjw8IC9UeXBlIC9Gb250RGVzY3JpcHRvciAvRm9udE5hbWUgL0JCWktFVCtDYWxpYnJp IC9GbGFncyA0IC9Gb250QkJveCBbLTUwMyAtMzA3IDEyNDAgMTAyNl0KL0l0YWxpY0FuZ2xlIDAg L0FzY2VudCA5NTIgL0Rlc2NlbnQgLTI2OSAvQ2FwSGVpZ2h0IDg0NiAvU3RlbVYgMCAvWEhlaWdo dAo2MzUgL01heFdpZHRoIDEzMjggL0ZvbnRGaWxlMiA5OCAwIFIgPj4KZW5kb2JqCjk4IDAgb2Jq Cjw8IC9MZW5ndGggOTkgMCBSIC9MZW5ndGgxIDY1MiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+Pgpz dHJlYW0KeAErKSpNZeBgaGBgZmBIzk0sYAADxgQgJZWeU5kG5bcA6RcZqYkpED7DHyBtlgEUgMqb AGmVjNySCig/Akhz5OQnw+RrgHy23MQKqPkMd4B8hbzE3FSIeqYcEB+3fDrIfo2C/OISiPp0ENVS UJQKcy/QPq6NQLFAiDyUZATSTIwKDAIMhxnYGZiAtD5DG1SOhYERCIGuYuoX0TyREs9v85VBkgMs uft1zRkQ42LvKfffv/52c77hMANyOYEmQABQH/u8v7eAdi74/evXAs43YJOgkmCKiYWPgYHxPJgN sYeBgYeBDYgZGBShNoMkS4CQgYGVgeFfMfMlVj5gLLAzWDL4MvgBdQsqCoKxCB8TO7sIm7KSHpOp upqZsbGRHZOpiZqyEh8TWMzEzNyO2dhIjokZqBIiYscE4jMyX/oTxez/l42pTtk+zJhVTopfhJeN lUlGQkjXRlUgOFrVRk+WnZmdjZmVg13D3EnJO8dV6Ra7oKyomKwQB4eQrJiorCD739usfL8+sfL9 dmbJ+T2Fmc06xl6FeQYXBxMLG9sOOQlJLWtFzzB+YQEWbmEBQTEOdiFBHg2XmL9tojIgM2RERSFm /fUF+ZeRQQgaVmwMwBBycorydg3Rdk7MyUwqygQA0pdl1wplbmRzdHJlYW0KZW5kb2JqCjk5IDAg b2JqCjQ4NAplbmRvYmoKODEgMCBvYmoKPDwgL1R5cGUgL0ZvbnQgL1N1YnR5cGUgL1RydWVUeXBl IC9CYXNlRm9udCAvT1RFTEFBK1RpbWVzTmV3Um9tYW5QUy1Cb2xkTVQKL0ZvbnREZXNjcmlwdG9y IDEwMCAwIFIgL0VuY29kaW5nIC9NYWNSb21hbkVuY29kaW5nIC9GaXJzdENoYXIgMzIgL0xhc3RD aGFyCjExNyAvV2lkdGhzIFsgMjUwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAyNzggNTAw IDUwMCA1MDAgNTAwIDUwMCA1MDAKNTAwIDAgMCA1MDAgMzMzIDAgMCAwIDAgMCAwIDAgMCAwIDcy MiAwIDAgNzc4IDc3OCAwIDAgMCAwIDAgMCAwIDYxMSAwIDAgMAowIDAgMCAwIDAgMCAwIDMzMyAw IDMzMyAwIDAgMCA1MDAgMCAwIDU1NiA0NDQgMzMzIDUwMCAwIDAgMCAwIDI3OCAwIDU1NiA1MDAK MCAwIDAgMzg5IDMzMyA1NTYgXSA+PgplbmRvYmoKMTAwIDAgb2JqCjw8IC9UeXBlIC9Gb250RGVz Y3JpcHRvciAvRm9udE5hbWUgL09URUxBQStUaW1lc05ld1JvbWFuUFMtQm9sZE1UIC9GbGFncyAz MgovRm9udEJCb3ggWy01NTggLTMwNyAyMDAwIDEwMjZdIC9JdGFsaWNBbmdsZSAwIC9Bc2NlbnQg ODkxIC9EZXNjZW50IC0yMTYgL0NhcEhlaWdodAo2NDQgL1N0ZW1WIDAgL0xlYWRpbmcgNDIgL1hI ZWlnaHQgNTU0IC9NYXhXaWR0aCAyMDAwIC9Gb250RmlsZTIgMTAxIDAgUiA+PgplbmRvYmoKMTAx IDAgb2JqCjw8IC9MZW5ndGggMTAyIDAgUiAvTGVuZ3RoMSAyMDE2OCAvRmlsdGVyIC9GbGF0ZURl Y29kZSA+PgpzdHJlYW0KeAG9vHl8W8XVPzwzV6u1XcmSJUu2r3bbkh05trzGsa9XsjlxIIAdYuKs ZCOxk7CELQk7ZkvLnkCTshfaRpazKAQat9ACLZBQWkqBJ0mLn5bSmqRtoE8hlt7vXJkAz9vP+34+ vz9+kuecWc7MnTlz5syZM1fevPGKFcRIthGByMsuXzJAlE+gDOiVZVdu9mbT9kcJ0YVXDlx2eTZd 8Aoh6n9ctm7Lymw6CPqIedWKJcuzaXIWuGYVMrJpGgcOrrp889XZtD8FvHndhmWT5YHTSDdevuTq yeeTD5H2rl9y+Yos/dyHgSsGNmzaPJluBF40sHHFJD3tISS3BXnzs+WTkAIXkn+QRnIv0RBGRBIj F2Ekd7JXiBppXq42vlkXmX58saXxM12+Tqn4+EfVnTzy8+HPv/PlHRN3iURXDVq9Qs8LUE/rS3eQ i0Xy5R1fnBCVHF5w7lM4vMCbUhlHjOZKjpO5zsqUyjBS4pUsLaLKRrYhMGIBbEZYjCAokBJZZUte XSWngDZm0fosWpNFC6rkF0E+i1RlRlW2EaerktOO5Bgrt3Gs0/O0NbmwSm7Rq6wYLqezkguyONnN W7Emu3grVnJeNnekvSNbqzWb3TRJ3FAltQRB5kWQEQYQ9iKcRtCg91YSQ9iBkEFQKSlOtxXhXoQ9 CCcRNLwLSV2VpcWjElEiKmMXiYRYDEEg/SrO3YQCLSoduKIj8xB2q7REpcpJknXSITQijHR08J4K I9EpCk6WlFYqBUl3QeVLKoE9QoqJBEqazPMoJSTZ2joZqanLRkYi5ZUnWnJUhJxCYCqioqQkW2uk ZErl6SNIUyFNLJTyXOHsiGjH04SJEUtupdwiCv8m3QiMJIRhMorAyAbhM7IVgYF8b7J8Kn+QsHck x1wpgv4U8SJsQxDIHkCqpGXEOP2pkdw83vyfkxarUu9EsiKejYyIrsruFrvwIfrzuvBrEiCS8Efg IuBXgQuBfyG8RkxKP58csYiV2/C8J0D+hLCFlKL4KeEaUgn8rHAD8Shkv0+as8/5fbIkUtmSIzwj XKeQbBIGSRyk64S1yUrJe1h4Ej2Vhb+N6A28f39Lio7Kl4S/CGuJHVRjoHJKlpeE9SSGwEeSGtGb Kne0GIUUhpkCWyT0kZLdCpSFXyfREJ73A2EbyUPZUWE7cQA/J9yYdEijh4V/Kc/7nLeC5z0OieFo xGSuHG3RC4+jNCH8Axz/h/K0MyPhukrSEhbuIhUIDEz9CLGPEBOFTxH7FNP0KabmU0zNp+jFpxBa IoyjZBw0MeE4GRA+IDsQdiOuwgC2JMFBPnVbksGSykPC9cJ14IR4GLyjyL1hRG/mPbsuactVyK7j C7z5JeF3ZB4CA7Pe4ytyw2HhHmUoO0ZcHl7hN0m9Eay7NjsXaOkaPgcvCduEGxVObFc4kPgJkpRY hJuUypkRo7VyK2Z/AZIbAO9FOIZwCkEFsgUYwwKyGAHKW+geMVsqLYeFhUrlmUlzlfSSMANDn6Fw a0bS4Vf6fN5kRGVJeooqf4K1YiHl0GiVKrNKk4xJ8w8LsyE/84S5yeUS+j4/iXY5T+aO1DVUVhwW 5iq8mJuUAtnsZG6+EulM6rNy1TaSY+U9aVcIo0mdWSmPTi5JITJid1ZKLaLQoIy2CpAItZi+WkxN LdZJlTIZlSOiDdK/XKhURlRJ+hHbg5BAUGGOK0FeiTmuJCeVHItQg+HWkAyCgLmtIacRoGaFqaQZ 4V6EIwgnEdRKbj9iDPkVeEI/4A4EhhZjSIuAMkI/wjaEPQijCKcRtOSoUI7nlIO6AnAbQgLhBIIK c1WGfpShzCZ4yQQ2FYlsZY/IDXQr2Uq3sq3CVtVW9VZxq1UnV4fKKuU1HEzhoASgtl8/oN+mFyr0 sr5bL4h6r56lMqNJbUMVkGzTNFS93/VJ1xddgq12h2aHlh1tMVIrOYFwCkEgR6mIlIiUKN8mHG06 0XSqSTjadaLrVJdw9PiJ46eOC0fLT5SfKhfkLk9DZe1iuoFupfdSlURjtJnOo6rFwgZhq3CvoJKE mNAMWVD1GwYM2wxChUE2dBsE0eA1sB2GPYaEYdRwzKBOaEY1xzQnNac16m5Nv2ZAs02zQ7NHo5G0 MW2zVtaoTre0sQ/A1D2ACQRGtgHuUGIiICWjgMeUNM/FdAAOKGkZsFuJBQAreAwhgLbeB902wB0I WHxKOgBYwdMIAWj334NmAHAHAmO/lwv8FUE5yMSgN8hIkJ4O0mPBk0GWCI4G2WhLA3sP9HsAEwi8 l++hJo8FACt4DCGA3v5Oofsd6PjC3wa4Q4ntAfzfef3IG1BKZcBuJRYArOAx9rtkoNbS4mS70OJi wN0IJxAEEgNsRtigpCRAynYBymznSHEZNny2MxmGjgTyZ1FRFhUoaCTfXbm4xcJ2osmdaHInmuQp CaGZpzKj7JFkO6d9JDk9ixqqTrTUYhflXXmE7EVgZB7gbiUWA2xWYrwEqupcOoHYSaVkAHCPEuP1 eCvYBwC/qiuwnfg+ghwLuwa518gGRvLyYDrZrDpbir2QXG2TUmxfskQEGsmiJEctuUwA7030UwX+ WIG7FXi/Ai9WoEU2BEz/Dph+HjA9EzC15LBZJIhKpxX4FwWukc1B08dB0y+CpieCpseDpsP0I+IH kU92+03/7Tf9l9900G96zm+6z29a5DfN95vm+HlTJcRLTKyQQ3qpAgtkp9d01mv6g9f0K6/pNa/p +15Tr9fU4AU5/QeJg/BRBT6kwOqDcZMUNxXGTS8waCZ6SdJC9IcZo5cQk5CTjDRJKUGvIOZLdoXA gYJkVwuQJ9l1PpA72bURKDfZdZ/UomcWOgxjRWJmOqzj2JiMbEexIYt0ycilSKmTkXopRdPJSADo y+TKQqAvkiuLgD5ProwDfcbRi/SfZCVDM/TvyZXfQ/P0E1LCm6V/JmH2PHAq2dUM6oPZp9N9pImG kJ2EdcjJfpiMoHP02WSkBOiZZCQI9HQWPZGMSEh9P7lyCtD3kivvA3osuXIMaGeyZB1/3COkRGnn YRJW8KZklwfFg8ku3tBAsisGtCHZVQ20Ntn0JtDqZNMYr3oZHaaQbLqSRJSeLkmujKB48eRA+kiJ UryIVCstn5fs4izp5I20mGjH5EDaaRu3+WgrHVZakZORCpA1JSNhoOlZzjUmV0aRqkuWgNW0Nlny PXCuZvIBpXx+XqRBdIM3FEhGngeRlFxZClSUXNkB5OE10efcyafaSJPSKWsywqnEZMQr/YQayEql yzkkTHcekCbQ7pdNKXpRUvpCTuloUvpXCdAB6W9dS6W/dqVg8UqfYCU/f0A6AdLjTYjKBunDyJj0 wUq/9MsIKGSP9HpkivRyeIuUKjksjXQVScPoWGLlUmnvSqWFH4dRLSk9W5JiFLX3rJwjPRyJSg+F MUkHpO+C+Db+DDR0S2SLdGN4u3QFBHFz1x3SpkihNFByqbSmhD/IKa2OnC+twkAuQ50VKy+TlkTu k/qrlR5fGnlTuoBHk9LslcqIZjYpBTNWni91ogcoaOYF6ME0yGUlqk6pPsx5BEulbeRN6cLaFxl2 YboNYaM8RfuS9gbtUu0CbSv2m2JtSOvTFmntOptO1Jl1Rl2OTqfT6FQ6piM6wuypzEk5yo9sdo1y ctPgEEAJjiGAIuMQAJAwqmM4aCVyhdls9gWtidro7JQ2c36iLjo7oeu+pGeY0nt66ezE6DIye6k3 8fkFgRTNmb8woQ600oRtNpm9oNUF4gS7PUXJgp4UzfAat3gStraeQ4TSslvu9nDcecvdvb0k78pm V7OtyVrf2f4fQL+S2d/e0R79+uP6OoqYK1qYeHD2BT2J5wp7E5U8kinsnZ0ovcC7qOcQW8fWdLQf Yms56u05RFexdR3n83y6qr0XZNMUMtLE1oKMdHEEMraINHEy5C/6BhkdRnb7cBMAJ5pHhzkRFs08 hWih0hZt+yaRcCdtU4jahDsVou9lHxhBP/BAmSO0pV5HIsoDI+p1CpmLkw2Hw3jcSoDenuHKMAiG w5VK8fyvi0uyxT/KFv+IF6co/bq8Wik/BB3OKQ5BpZWA5lss/L+cWNH6f/BAOjL9yvU9HSsCHf2B jhUI/Yk7r1zlSmxb6vUOr7+SF3gTQrh/6bJVHC9ZkbgysKI9sT7Q7h2ertT7X8U9vHh6oH2Y9HQs 6BnukVe0J6fL0zsCS9p7R+Zurxv81rPuOPesuu3/4VnbeWN1/FlzlXr/61mDvHguf9Ygf9Ygf9Zc ea7yrNnnt9LZ3T3DOtLa24Y553iEGXKwWvo9vt7WPHGgSVk603yuGzwvqAh9lhiivQljoDVhQuCr qrylvIUXYUnzIjOyLZNFrhum+Twv0Gcni0RkWwOtZLOrY3U7/jbhs3nzFfhgTjZtyk4ML+P50Q6l HASbEQPEB5SI84CMr8s3E97G5CcazdKSTdG2nuGurg7X6nYPjPgRbndHezeRaBSUyrMInolRK4Z+ nmLoGzR5Vb/t+u+uz7qEUcXCPwbr/qRi4Y/Cuj+GcBIWfpEw2nSs6WSTMNp1rOskaI8fO37yuDBa fqz8ZLlQO9kD/qheiq5+/b0iuukKnh2lymiVcSOFnM3RTWAB4CQbkELBZgTOJV7Go7xqFM0phdHs KJCTjSg1N21GgldQcpUsXofXuoI3z4v/X5/JXKhg9T1EUs9RQoFwP7wXJPMHhDGEj9OzMmfVa0kg vSZzUsiFug5mw6QHLkRuhqH3MXmQHCF95FewGzvoFNIDT4+L5EOx15PZYJ+TqGkOXD8BMpt0wxUx i/w3NZG9ZCr5hHaS7bBt5pFHYRfOxSG9hXyH7KHnZf5CtpN36GryPGo/S2W4m+bQGZkTZD7pzhzE MwiZRh4iO6kZm9UcmkMDmeNoYRO5jbxA3iUZspA8rN6DVrrJ+WR95iBZRN6mC+klmQIyk6wnN5CH yffJS2SM3k5HVepMP6kmS8lGqqW5tES4MfMsqVO/p9+feSVzDN7M9aB9gfyNRVWdmU+JTD5W0cwq GPm5pArf9eRxcoB8SF20WmgjZpifi8CL68heoQR9nEHuwNheoNfSvYI58yRGU0uWka0QqavpKPOp 31OfzlxDbBhfHD0dIk+Sn5KXyV/RWiddIFyebs7AD4D9NEo68KSbya3kx+Dcz/B9hVqoj85Eyz+l x+kfhPXCn9DyM2ScfE7+h5bQ1fQG1sxuVFdObM/sJ2GMUEYbM8nFZB35IQ1TmV6Cuo+yq9gNOCof ED5UlahOZeoyL8N9gyM5uZE8h3G9Rd4hv8N8ddIu+i67QRhR35q5Fv2NkVUYxc3kKXKIfEbVVE+N 1E69tIrWYmTX0lH6B1bIAqxHWCrsVd+V2ZK5m/ggK31kBWquITeRW8hBcpT8kfyVjFM3asZQs5l2 07txRH6FHRUuFhYJD6pk1YOq51U/U51VW9U/S7+dPgmu83YqSBe+fWQluQa8TuH7MnmfCtRDi9DS dDoLLS2mK+l1dAd9gD5Bn6YH6Kv0GP0LPUX/zVzsLnY/O8x+zo6yY0KhEBHahd3CGyqf6n3Vl9ol E4XpI+lTGUMmmqnK7Mg8mvkgM67MQgEJkWbSBulaS7Zh9DvIA+Qx8HwfeZP8FnJ3QvmOkdOYgy+p BtKUjx75aYAW0zKM7mLaQ6+iQ/Q++iT9Bf0DHaNnGWFG5sc3wmrYLLaI3cj+xs4KOUJAaBGuFh4S fi18odqirsT3efV+9WnNmDake+PsronjaZJenX4wvStTDVnUQPJysebipBUyNwuzvJwM4ruRXEmu Ao+uAccfheTsJUlymLxG3gDvj5IPcANwgowp379gJs6QCZKmDPOppjp8s32vwMy0QVr66QrMbfZ7 Lb2R3kEfxncX/R79Pvj7Nv01fYeeoB/RzzAmwspZCzsPI+pml7A+fBezZWw7u5Ptw/ct9i77gP2R fSGIglWQhGKhQ7hMuF0YEhLCPuE3wm9VYVWLaoZqrepV1dsY+Qz1TPVi9TL1nervq59Q/0z9S/WY OqO5T/O4JqX5WJujrdF2wyy9Q/sD7WHth9qMrhjy1IXel07qKY7uo5eoYmwHzbAUxv0Ttln4Fbuf Pv8NCqIeQg+W4zCdEl5ij123A07gH7IbCVG1K1TTocXeIC+SN9TvqBzqj8mrzE0+hT68X1jCfoKj tovWCNNUt6jegNbZgn4+wU4wLdsLir9iNhaTC2k++YfqInIK/D+qHgJPO9lx+jz7BY7OfeQ98iQ7 THCoJytoLXq3nOwnX5Dv0EOClx6A3G0lx8jfyMmv+6uKTbSyZo2LXalpwAwdovMzr7LSzF+x6v9A byEfCF9A9i+ic2mMPE0+wqz/lsappEqrPORtaL4isgtS+2cygjX4S1UQK+gzckiIk4Wqk5DX2MTr 6Xb1ZuEm+jlrwXQ6Fc09j2tj6OCHoau4HjWTvVjr0CLKiv4reZP6sZ+8o3mf7CT3khcEBwkJT7Ft LCO8pvKS78IlOAdPvR76qQB3Vc+Sy8lqcNeb+VP6SbSwhtSROrqULiTtKJlBijKXo+dPQxfJmUWZ R9S96ih5i86hDnIE2ssFLj6o1qfHQbkP6/ADMoPeSUbSy8ko9hUXDdFKSNO4+kr1DvVz6n3qn6jf 1EwlV2PV7sIs/pGcwa7hpcvAi0/IvyDrrVg9ZVg/LejFDOxh61iv8BJpo24yAB1YAr3dCh4sxExu Qis3kruwnp7CHvIWOU1Fuoj8hLyHlePEOl+G5+vQzmxyIWZ9E3ka2vEmOoKc5bhSiGCdfUHNtI5t xvO4nn0QenYUffqQ/AmaI6P0q4xOo+2YvWXkX3wt4wk1pBvnAZI5QOqxU7YLb5D/hmNNJK3QL0+i Xj9kw4yrinr1R5SRsvTcTB1bLbxE87AbmiFVC7CzT6eD6IUF45ggDjqPVKfPQ2vPQ5d1q5/C7hvF zuBgDtXF6gvR7/exk71FNmZ66E4tVoDceuECublpeuO0hvq62up4VeXUitiU8rJopLSkOBwKBvw+ r1RUWOBx57uceQ57rs0qWswmoyFHr9Nq1Lg1oqSsI9DZ702E+xOqcGDGjHKeDixBxpJvZPQnvMjq /DZNwsvrLUHRtyhlUK78X5RyllI+R0lFbyNpLC/zdgS8iTfbA94UXTi/B/G72wO93sS4Eu9S4juU uAlxnw8VvB2uVe3eBO33diQ6r1w11NHfXl5Ghw05bYG2FTnlZWQ4x4CoAbGEMzAwTJ1NVIkwZ0fD MCM6E4aYcAfaOxL5AVRFM0KoY8nyRPf8no52j8/XW16WoG3LAksThBvRUYWEtCmPSWjaElrlMd7V CYyG3OkdLhsduislkqX9UePywPIli3oSwhK00ZGwRvHc9oTzmjHX10k0DnP9tm+WeoQhmMdeTjw0 dJs3sWd+zzfqeny8hd5etIG6LNTZP9SJR9+FmZrNj3gJdktvT4LegkfiyBFSRpUdX/Y8FOpf403o A62BVUNr+jE17qEEOX+LL+l2y4cyJ4m7wzu0oCfgSzR7Ar1L2guG7WTo/C0j+bI3/9sl5WXDojXL 2GGzZTJiNH0zsgJMz5YpMYWcx2aff46zlPcxMDMhQ6KWedGTngDGVMfBijoytKwOE4BPL0WtxHLM yOqEvq1/SGzg+RgiTahDYsA79BmBBATG//btnCWTOZqQ+BnhhVxOzolagi75Kp6IRhORCBcRbRvm FH1sUtLV5WVXptjuwIDoBcJxknSDt0t6G2Jgv8/HJ/jOlEyWIpHYNr8nm/aSpR44AmM4drF+XjL6 VYnjQl6y7auSc9X7A5DkfdzTQhwJXfjcn0XMy+1Y1ZCgef8fxSuy5bMvCMyev7DH2zHUPym1sxd8 K5Ut5wwF31A2GUvktvUIHoY8HmMeQSmFUC5aeI4EiR5jQhXCn0YR6uUprQ5SqeRQb2dC7J+Rhb05 Pt/kmvn/q5TKnOa1FPR1tclhJBqikx3Ndjsx7Vvpb3XPOCTMXgCVw2YvWDg0lPOtsk4os6GhzoC3 c6h/aEkqs21pwCsGhg7BnikeGuiAGsrOaCrzwp2eROddvRjKKtoAuWWkdThAb58/LNPbL1jYcwhe Me/tC3qSjLK2/tbe4SDKeg55oXSVXHYul9N4eQonK0h6kumUIs8hmZBtCq1KyVDSy+AQU/KyRMij ZFmKZfNEha63l88Na1vQM8kbZeK4/GMiCdHU0wJG4KOr5xf4ZBbCbQiVCD6EKoQOhDkIzew5slf9 KvFo6skFCFHVRySOvHcR2lC+SLUJ17d345rjOdKKdBfajCKvE/FZQiGZj/ww0s14HF4MACR4Y0aD vRG8IRdN5ijZ/wEw2MAqoga9FqclvUKRQwz/gdKo5JmwJ377Y/l2cjKFiSHWybhNwbm4lndgr/zq 40SEn3azHzd22QIlWkNqyBJYK/thR1BhjWqW6u/q76jf1jyi3a17TN+k36F/z7DAeLEpbDprmWt5 02q1/iP3u3adQ4tzM1pQF6hxXYvRtO5j9GWNNiXo5FyiVr0skByt6mVK8nUa9ctMeJG2ED2MnYuI Kyp+3jjROFc809g10UiaERfPAkyt8Fl91hAALVCRs15h9KysJl/idZNRzmmW+QNrxhlfIDVyIdyk zUywMyYQgVJmEPYSt5ruZWWqFzvQ/pnxueLnXeNou7nxNvWU6PXiK1MrKMxF1pxu20aPqNd+caV6 COJCZmXGhP3qVdymoLPkfL1HI2lC+lKn1uVxeB0hV6leq6NX6Qrhyk3a1MVAIxqTzZkScuQQkYPh OJGjUwCqagCmTY/LsFn2oI/ucpvFL+G8xCnN95qoSc51xE35ZZ/93RVF56Ibu8b72npkp18OFsf9 vBE/b8TPG9ngp4PcEdILQiXSNc5dxE54ikDs5B4j0CsYVTjej1r9zslapHm8eXxqRdsWeSmNeH2S j2ksZtHMNMFAKMA0BmOOUW/UGVUaR549j2nyXW6XxyVoGI6lKipoItHSKNMUWf1LSVgLUJDrXEpL 1AA+c+FSGjAWLyWuPMSiFDHeT8pBZPKznQzSQWrXmlnAHy7GtzpeW1NTVZnnzFOLPB3wazUaq+jM y6uqrK2pFfbX+zd996Kl35te5os2VR3bfOWbFW3pN1Q54fy6aH7IbbfUTanMj2jY079KrBuav7yv ffCRJ/7r0CNPfP/2wx/S5dPunOp1BYYnTqVPLj2vwlt3BZeV2yCSyzCrTnLTi8RMf0SriY4+dcC/ WLtByyhueHiOlv4brp48+hSx0H/BzKwmeYzJZouOqHVaIzIl2Mm4fpNFs7nbssGy1yKIFmrJd5l/ AlWjY78gLuakJxR5HoM09/U1dokTfVyim231n42fpZ9FaV8Ugme1Y6xVDl91VWVNTbU1HuY8KA6x XXmdXdJETfDiWW7bVG/VTBv9p3rVl89f31EWCpV0bmNHLo35vMExPqJKjOhRjKiAfCwHb2c/Zj8U hGLjAwLLMeQYKFF7bHvy9uWxvAKGPuUYdAUp2n/AFnMmnMyZov4ktem42BhMcV1KCO4zqyley6Fn ZA9Ri2qm/tD2jqWAHimgBe4ivOd0hFKaX/gCvAA7MLy54ljfoPh532DXmYm+MdLcPM5dk3KuTs4z Netkpxkg3wJgqueC0AsmoDwrr6BQ5BRECvaICk4WWJsV2jFrfb3VVk8R+qz1tnokxdfBsj7S5/NV E1t1XOGVIkCw1bUa6gMPa6uE7rN/pBseu/HSnReGaj7ccdlz/bNWpH9IQ+taIv5gHt1Pp+xYfedO 02iq/5mZt9xxKL3fFu3gfPRlPhKGwMcoOSpLWovTsiq6JXqL45a8XbkP5P3A9nTeC7mG8oLmAmbX 0RR9QIaG5q+nEZ8BN3T9UNk+9gauCt4ibqIDP01W8BPY5gBmbx2QzWq3idhxI7vPS6k65wX6ADFQ 94GiLJuhDA5a3yGlYikr5YrBanFSp7vcUkSLuHooyi/7Bs+j4PkgtMSZ8T7xzIS1PpbvHm8kruZm 93g0Kk6MiWO2+ljfuK0+yy5a3cS+yS2HXaPNA8uIz8/XIFagsuJqQENjG3vkLQvvWhqa8Yehuw9e eMkV16bfTKd/OK++NeorFF++cNaaUfZswFd/ReMFV91veubZH26afWd1/TM3/Cb9u/qS5iktZt3u Kxbe8Wcwpgpy+SPwMwcvnT0iu5pN8KxRbHFMq89R60xGotKZTAZDii6SRULtmAIDoVqdwURV5DA9 i50wh4myUUfVOqOJ4IaO6Q4LejSspf2yK6ZqVjGLSlIxldtCOItIvjmrQcewi/T1dZ1pVFZcMzaT zxshPFyQbPW3TYmqoPMtFkuWN7m0ylrlCGB78dX6rFXs5muuuy49nnYsgY8rI6w++9DR9DFacZQ5 ISEd2BFG4Gf20255illD9Tn5OSWkRFDZcxweR4FQp5mpOagWDGrq9uQUqApFwEIVdasELCg+Sj9G 6Yf2p8QvKhuAfp8NnmZVip46YPMKRwQGQv8I7hjduEaVcyy5Ui7L/dBoYin22gh9W0cOMw2cxIX0 M9kt67p1e3SCzh0U377XT/2cB/78QJYHZ7CLjEFIxsUx8QwW5njfOHZTvvhkuyBjiQky1pvAV6jA 16qy4tKDyuLE+20joFBx6QWRgkGnYJBynLQblSrR3vE+Xkku8vNG/bxRP2/Uzxv1yyDzyzZDljba O7nhEqvNyafDCfkkg310Y98g9Qk+rYqfuTWqwFdSiX3BiZ0Achn0+bVwN1y7YuKTKtr7wiP3pNM7 n+5taokWdy+ZXiYVn78pvSd9xlOjnpNO32bafdPL15/a3lRWF231tkdE49ULEh/yu9o5mL+fKbq/ GGtcbxfoyrwr81hOKvM/ssNmj0eEoONVh9CsU/tdLkmtDzteYr+EPfEArCE93bk/HBaJGvfuOftE k/9DY4r+YYS4S10p9vp+i1tyMzdfuAY7nwh7fslXE4F1qtgcn8PoGIf6j42L42OKLHKJVDbjKZ5Q Tm4wXOAp9DCNLWQOh3L8S2mR1b2UeC2IBQzhpdSTKy0lPhMA31mVjTUaiW7fTvqwl/RRh5lpa2r5 bgoearDBYsnbglTjsNuyTMQOG/ALP9v/wdZAWWFL68O/Wv/LTdf/5qoP6H3p13XVU3zlU2a0RWeW qFcVTPnO0UeK9Pb/OnLryWvuoLpdY/SOv0ysH5KH0ul4aO2T1L66HdxsBjcPgpt58CyNyp4cwQ0n tPCw/ll9Sv+aUdWuUzsDap1TKqaHFQ7qKN5Fwju34J9stKiJyfk2yRfzWT7nmi3XHQl8aHibcubR /NJzzMvaa5ObS5Z53+ZdpTust/lCprA15HEXuAvdgiYU9poDS0mRmL+UhvWI+Y3SUuq2AQRzYJic 418EjOQMpH1OqMhahW3Qh5yJNoedqShE7yu7xAGzpKqy+ek/3+Zpurhi55sb3tpw1W9ueDO9hpbm RFyx/JLKguLW6MzigoLw/e/f480//tNbT1x7ezr91Lvpq8fZ7QMXHnjs4tK86LSn038F+8C/vZk/ 07PCz2DhO0nlIZKfGZXzbblxzUyiNc60GSzCTH3ZEQd15LveO8p32jNQadwoViw4WFjKRGOe0eHc b8TpRR1LlnQgtHcuWcqx8DMliejERiWjowMsYLDyiXoQ2swD+9YgL3Jv0+fEAxyIHEQ5uCx3leuy 0M7SVIn6MutqJB6yPpz3ZK5mmVnrLSR+v85baPYHCqZYzMxf7fEQna28wFIoFbLCJl2FlnZrqfb6 sun7s70fhE3P7SCYtiIJi2EW7iJ20V5hF+w1n/d1/aXPcyDcVWGnSmq8F7aSCJ2FDW1qxewLtgxf qoPVOisQFd22XGsu05QUlxZHigXN1ymmyXM4HS5HvkOlCYaiYjhEIxwE3ADFuQUcRJEXDTn8IRIV G79pnmbFgKvBKm6L1U4aY4FqHzZHCANWlyYgwFzjUlBbY1XsVU/5tGaLPq+tvpwt/uf9+w8v+u6R oek3LRRzPVXP9Fx9fsvKGaGQ17FauG5VvDjUOj+dOnrv3x9b7DaqMl8eXxDOsWzcCQ+p+tFryiTs LhdkTmqC6nWkiq6T83JEdVAImUuvlm6Xbg7eHLq79PZITgDn8xFMi3ESayZxBFhuQ8Eq7SrDVYar goeEn6hSmoPBg+GDkZz2QGepHLmt9NaI+pHwQ5FnNE9onzX8PPSrUu0ss4sr7AEXLXqt0LXIz80w 2Y6crU5qfa3Q6Q9UFZKFrJDC3rHLfrKw4gfRIomKksnpcvnV1VHBVO3XE6toZdYmWuSu5vX1RjFe bSvJj1e/SC/ARdd6ehKGYnTuma62ngMWvaRnej7Xw/qucRxiop83Qj8qQo3F3WjDNo1AxL+dGafi +JlxbiZnTWXChaCDC0GlN6KxGMLh4lBxEAKgDRkD+hAx+8RWil9NiJoIUjnFphCxeE2tRFeqDnFl STHhfMondSYdRMO4wx6k1kAYjl8Ng6LE1NbUKkY45t2h0Wg1Divfj/CscLVIuCgoJOpbQm3pM7sf /uWCRW/ePfWymryOqQF23+xpov7G9J8f+mnm5dpO+mPauWJ+2c9tBRV29dq0/5U3nk+/9f2X0+8P OezU3R0Lh0JqKZg7K/2nhmmrn1879DytpE+Lutml9dwWxVtHGjvWZhttlm1t/gDxeUVvoc7vd/Hd 1MX5bK4taCYu0bXHJXi9hdiEfn/QX+ktjPj9Dbw4F3QNMmgsDVLD3gah1VvYAJoDfi1vQXuuBa2o 3aMVqLdQy1sIWL182ku/aqFUaaFUKt1bKgS8haWgkS8NVHkL6/3wlZe0wREvwd2BQ36ktNTlcrKG +nqdTqsLkFaxlbU2VVqqKP4WV9Gq60lHfweTO7o79nQkOlQd3uwpqslKRLxNRbtFKl7fPv3KSV2x cVJZ9A3icJFNcIWAbxba6jfG4BhQZINPLp9MBWShIKobQQvHwTdPWDhSfr2sHfywySfYd27Cv8r5 +kyWrcEqnFjiE9PKpwXdZoOy3H/O4xYDPZHXXl/GXilrDCDF4xON2Ti7K72Ir/qQw+x3rcxqgGw8 vY1u+7rk7M1fx3EJAr0cx33SU5h7N+6Ijx4i3sz/JI31Xm6jLDLUzwvTh1yfOz/3/tuviugKCDVi 5vx+zJ/GHzB5C23+gGeKjUwpKNDk2qCydKKP+o73523L250n5A3FwjTsyTK+3ESMopF1G/uNzHh9 KPwiZVit06k2u1r7zs0AdDNfoWB8dvsFpxX2KpZLkRSwu13OfCfTBOy+GJXcAH5HMEa9zqIY32mx 9iJZ5coTynkXx91zp91qn5cbLFqNYOVLix9TWKmnY9HEvEvbPJ72PjaPBtNP7ljyZ5/1mptvvomt TN++vt4fCgXq1gsDPHbs0Ztf9LvYwxMH2HcefuguvnreTQ+xVeCgSNa8xBJwflF2H7Gx78qSVfdC nF3n178QF68LwFMpEptOL+Pom1VMKfYPmTvRKLx3IjzhA/B6vEgfJ1Zcdt+lHHfP9GEbwyk2qpzl IX+QsM72zvaZ7blWH0RKA4Gycy1R5XiXfre8tdyp0k+dUZ4e0vws4qle8cVn/eagP4g+tqWH6G+V Pl4o27/dKxuOlXp+dpT16Fn25MN7ZiY4f/PJ4y/hZztmIz+id6Nj/AgO8/6bvbKe8ykUw6kQqKa/ Ta8/1x/1nH83hd01y9XGfnMgUAKpW5T5p3BceBlvtDSyWbJDI4r1Kq9YXyk3tsfvrL5Pu6taaOJd WjK7+kA9vUH7dPkPGw+W/6L8Pd/vyt+r/lO5vlrboZ2VO8s5s7rHuVL3ANlV/RReWDigM1bh7cum R1Q7yx+dqiJN3U3L8vqbNjofdOylTzUcoSebcnR53U2bpwkzdMxhc7Bp/CmvOOtPTaOVVTrcu0XL SqJloWhZaWPV81WHqwRV1fSqrqrrq+6u2l31o6qXqt6q+q+q8SrDAHTMNLvOp1uhu0KnYrppujm6 a3R36Hbrnta9pvu9Tm/QeXQDOsFu0wkuU1iKosXSlbFpM1jlQ6QvFmMuuTQat7gk12LXBtdu117X EZf2hOtvrrMuweWSzWLcxSQtM1jKpLJYWXOZqqy9tM0SkkIs9AkhMX2zfqv+iF7lBWJEL2KbS9HD sig3bWticlN/E2t6FsYcf6dLLukuac54qCdKasVaVluplgOh+Ab1aTWrUMvqbnW/WqXOn153oStF p96iWH6D0a7xwTOD0Z/2iX2DcCdtbIQMfj6GZYkDRTTWN8g3tzM4WIgTZ8bEcauzHloTfpPBjZMH X7hOdGKjubGRnxY2Dmu4u3yf0VXoYqSvV1nJlXUNBYEcUVBZQoVhX8gQrg+bi6xFxOjVF1F/oEGo LSJigamI5vgB6lTTiibtaGVThVKAJb19O9042EcQ4G8k3D8Z4icRWKghLGzursFxRDnkZXNrFN8f VgzfVmudiv1dbOVaGVRVlWzm87d3r0nRaqdc0hJxF4RnTmu+cOMb62/Z5TTn2E1u/CppbXv3wpwt 04p9+eWVQw+tnrf2+XsuXVNbWmhzOaRoydSOOVUzbuocbI08lH5A9okh16y22Q/Q+vPm19ROCcAA xk8WMmOqDqzDIrwwfI0ceNj0rOmQ6WCeymar1eEEUcScUrle53pcKvp5wKKFAGhT9NN99HH8YiVF Lzmoi95sNOoMONQslvOdW3xhuxZNwQfI3RURvj8zV4TySTdX5jdb8JMZloAHzR1DVnJ2NUcjcNBy jMOyOd4dOxZjA7E9MRaToKtlkRc4eFWRVoiy2C0eE1Vi/pS67ZMbJQSjb67YtxG8hg7gqfGsnxHG E7egRcXb2BcVzNgOGxtpnzLZJf6IKTcYCoRw3AxzS5ppzCF/briYREwAIauvmBZbosWTChw2E3Q4 DPfYgGkgd8A/EEnERmOaAfNW25XOrYGB0mvLb3UOlT9seihvV9nTec+XvVBm3ma5w8r46b6Pv6N5 iMQw0nxfszJil1fB+FVgMzfNenECU7Sm06Gu5kKgeKUU4bDi/BUOVOcqsgOxyJrfwq81uvK69BXn begcWbVg1f5Vbaum6Y0VrbfNWhtyhWLxcmdJz1z1nC/fuNzu86p8Xfdf1LTnxpceOnVNvIW61+YV FkQmbr3HLj36/eHnwrlDWSkQ+qD9HMRLq+UejW22vc++wb7KscK1xa4N5TyDN1xet77N3hbeM73n +KfwP6acrY6sy+UiYaWwwX+VsNV/k3Cr+RPTxw59RJfJozq9PsrFwAsXTZ/am0doZ16KluzzhHO1 arzhP2I06PP47Bowu3lyvj+et5ogfYBPNjYIREcM5jjHsstaTdwxf7N/sf+UX+X3lma38EouHSOg V3CRLYvDFXFFaowQp2OwqvJ9dfdkhQWsjuIMBo903+fRKBeWKN8xcKDEwZIrkL4xKr4+mN3YrUWF oezGXmCTiojbngdXpNVTRJ0OgMmNPbodRhefZDhwsr6a7CrmE2jD4tbGJ736DofQN5HRL+xY0ri0 zj8nteXY2osmnrvn7U8DIUcg7ptGP3th3QVtF+ft2r5n+5FPqOMvj3//aslW1bsrAFa0wpPYivud chqVF8kxqsmVgsyCezJJI2pVkSj261KraDIabcRkjooWY1DS/txPg5IGa9YjeZo9wl6o28rwjQ5a br6pDCTQMTkx7qiyxKTYiZgQczrdVLGrK/I9cVdRqV8G9u8ojb1/opyWv0tI6STTI8ZjcPW/e8xM ze+aTLZSHMZGR9AQx3KstDLuNR4zMqhNY4Vxm3GHcY9Rww2tfiV6zHjaqDXme2MVMTYl9kvfC3Q5 1XCDa3AuLAss4q6xRnFscGwQ6l2J/Qn3QWd+ij2gY0X7n8BqboY18sux5nF43uDshUrHwtZyPAn5 EucuDWVJ1cLWgvPXGqiuqi7mnl5ubCnKF6Yw1hYsFpyZqxz0hN170cTvm6vtt99O39l37VWzpsen a1RG0VlYzIaEjomrLnWFhGCQeirmsDuWdsR2jC6qK2+t8ekLrBZHjqWieu9V8CoIpCvdKXyAlVRB puOt1jfk+SHRYGkuC92mv738vtL9qkP6ZOmBKaeDn7Xn5FTpqzX1mmneuWodlm2pvlSqk2ZId+lu iezSP1P+TJtBnhFs9ZlKXfjhd4M2aG8qNcWMihXihrA3ybb6JjlcHG+SiyQAhyte0UR58YjNFW9K CSrZYc864wprHzIaC2NMkGNT40JKKJCNkOCpD8W0HeFCywxexWBr5ljOQW+9M+iMGS4co44pqtfU QBsqXRtxPbRR0tIYnBopQSOXlrXKqARgaY61UkurhAPPDJ/IMwGQKVKLKIlMTAlq2R6OV2Chsji1 xKU4i8u+cLSMP09CbplcUhov40aApWxD2b1lQnfZsTJWdlUXTADFtMO6HWvk8y2O9+GkMwkn+gbP QlrGlWwcZZWF3DgRbYSDLAbnfzQ2uc/bZckXh6s2qhx5o9lc/FIDww6BfehGslCKQw+j4ldXLhzz YOU+WqzvPniJYOBikWfdi8UQHHteVS2OxIr5zg/J2Odrs4DDqkptloZb9cVhQdn8sasrqTB7jE4b mZrr2nBklmZj+fTaph/9et7gqgu3P3vDsYUdl964ZtOtV59M9M1q6J5X09hd7r1ipa/+yifu3G3x XC48un5qSc205fddoJ5WGpzCpsi3XHinb+rUiyumzMyXN3bcWDF1z+o7Xm+6IvXAhvW7R1oqvvy7 VaquumBWW761CJfeyumaBRXbe1QusG2zOpv7bfgdDoVTUkNESS3C+tUYoD74Vs/1CPT1p/sCUCsi InJeACcLjToH5ji/B4wYDTKaMHA2NlRzNFIejyvYG1CwHMh1xhMGei+u4wyigRmulWx7bAmbELM1 2+61jdpO2tQ2Xm9qPM7xgfIpcevcUcx9NMoPwHyh45O9z4ACQJwvcop8fqByYo1PnmyLq+nIlLa0 tqnIPqUVG+CVy2pVwSDzO5cJry2tVYX46DtxvqzFCo0y1SH8w4WP9xvq9RpajufKdbOru8upWq3W hDTC79m7wm/dgkNTre5kwrv0hIfZLGacEaOSWfSJ0b2WIxa8X1tgD0qWFPtAtvrDQckX8OcEJZwp CoISXgl6X3YEioNSNBDweb0Wizknf6VaUGk9MJdGjsEOSmX2yxe5qukWGBqaHElP9RGHwy77Wprt 8vRqi5167UftzC53nBe3y23Vdrm+AZHqGoCKqQDRcoDiEgB/EAB6wC6L1rgILyK3vi1SeaKcxcoH ylm53FTNxziCFhSMRhSMdhRcNiWL0ZqSRlscyxY4pOHVhJ+DkUhxcZjnmdHB07grC4+Gj4UFnjVS 2xBXMBSMQqIvDMbD+WVzs3YaZgyTlb0ExqRmP9yS/yqulEe5Vc8PluKZ6CCst0ZuweGrEAlcxdPs 9akXD4QXB04BnBFxx2LhFy1KKhfXLhZlX+P3rhbu3rOAKumzT97BYJVjQW/kOzaMRtjo1KH4u7GM vy1K3OL6dg6E6+UZN8+55Gq7WNyULq52irao+6JZxdXp4mn51uIm4Zktc89bMbv+8fT966q1waA2 lL+M7tnU6Ls2bVhdhwyNN28dE9fEdZDD7PsVByGHJuKjC2TXq25abKS2i3XmsIkSrTOs1esMhTK/ bVJsZ5UcxvEMl2VuuEG57ayg87KoWUEj9dPjPFcOlkTjo4FjAUYCcqA/wKM4Y+0OsIDFJtmYTT5m oMoChfJVMJrm+ABMJkO+n/tZ9xVX1w1yvyXmApOTtbL5Do0Pf/NCeYWET1Bj9n2KdorjBQtJRd4i prHnOuCh1oQ9Be6C/AJBYzHZijHKwiKap7cVEZe2sJhajeZiWiSYi2hujrOIFKidxfxeInuxA3sb dxPc4p5aQuvxE4mZ4hajekCz1bhVHMjfprnXeK+4Lf819gspZ6sWNrllq+te7TbTNsu9Lh2/IB/s hcbGDQF0M9zWfn4V5OS+CcU1wV+tqIHTqzhM09f8+vIV1/zunbG/HK2a6TQbZkwpLyo22cMht/Dy DR8PvXrr47Tk5ddp9Lyuj365tu+8Wfn+6Yup77mthQ6uSeZnxthvMIOV7Dn4piocuCsUTaV2sbBU pbHn2X8R+kX49+In4r9FbakYitSJNZHbDA8EHgj+wPBEIGXYFzCojWqTrtRhPM8w26iRDbKR2Sol sotJlHKJxg9Lbc27uZqgHXhzaJcthox47J9Rl5S/yyO53XzKQLLDTXFfulYuyt+V90+bTR2Oam1F YZvBllXQMq7g6SU2H37OuU9v11zII3KO3s4uJD7Rx5CEEW6wxLMpv5mnGyAZEkw8tyVOY/F58cXx DfGt8b1xTdym8/JGOGQXWnQSznnY7ePZmN9dWsI7hdqWEsqj8Ieb4yX5VVyYuCzB6h4b7wPiL0rs 13mxQHWczIkqOtnua9Y1OgIAeSEkMTYuElizMNkHP9/Ij3dfVfV5wSFlKHq04bsU9flIRtCEgtGK gtEQx8lzbUV7x6LKnW0+lUtcYDIubqksegDMTgBTXvahuIEZ530sKiqyNBelMn8cMdqzGBQ8nQS5 0jmF7hBRQ5nbQKsuAqG6CFRq+1ck3KEPzwN36cO5r7wkYonJOdbmmKyHqcRnmw+TE2Wp+JND5ega 1uUxfh0NfFLWQ6mFymFtI/WOrEckVA6NF0pl/j6CwyTw2EEcLo0FOGkqq4n3D+dLnGmUoyi3YnID 3BOhrAXVV8YMV3YBoUrx7sNTkX03CRYM90LU1LL7Lf7pN7WUNti9NNw3956L2gaKDL48n+gvf6yz YnrjqkfKWx+4e855HqstzyX8NP3Te1bVBj35pa/eedHcB7sjhkraffPN0yIVneetqTt/2bq9IYsl wNdPOPNP9qBqAm/ePYwXwQz3GpkCDEaSn6IH5HyqstsFx02MarwG/v80BMNG/Qqzgb8kYJYL1YYD RreHqvAPXtQSXtSJ5OY5ttjtuTK4n8tFSiz0x2O5o7nHcoXcfPdc2JL8EhF2RBdeieA7DbYW5WU4 JEnzxFgff9+ObzhnGnEMhH2BX99Q5eWIr/wzMPJwssNhAu/Z0NTx45aw2NJQNP9A77XWnGtuGG5V TaSfWzZxZH6scFne6LLp/gfpvwO9r2Bzp/y2WDVVeIb46XcPkSB69zRsjeCxINMbPcaIcaZRVW/c WfCDglSB6pT2Ux3zc6+sT3HNqkkubLJc1QktzWgpN8cCAUtQyg0EioKSPxBQwxbLX6HH2064kgQD NEQTmTTNijTcdNDAltDAfNBw80HDLQcNNxo03GjQcBtCwy0HDbccjmqoRUO9mqMaRjSihsEEPCzn BLlFEoQFEeQrDI0oGO0oGJYDx8lIthgtK9lokmM5HwbEaJBKwUSQxYIDQRa0S/AERixc0YygYQXD flAw7AeO0RhHci7MiNNmGjOPmo+ZBXN+YNKg+Mok5FeqUA3ZfYnLOpyD30hxmxFvBmXNCMWgUKwJ vG/B7Ud+/YWD4sZzVqTigMMEYwVU+ya9csqFWHG18EbJ9PRNbbdeMO/aSHETvT631BMsLKnju/5E cC22++u7Zy658XG6iW/vE9uXNxTluufRM9nNHru98sn48Bu3//QpRKaA3+R99WaqU3kftQC/BYFH CrdhVaSJyPhNzXn4XctM/DZsHn7Bcz7eqL0Yv3Lh0mVD4B8NapB5CzrmtLREF6y+fMWmuSuuOn/D 5UvWd19Q3rph3fKuBeT/AYoKwfcKZW5kc3RyZWFtCmVuZG9iagoxMDIgMCBvYmoKMTQ3MTEKZW5k b2JqCjI3IDAgb2JqCjw8IC9UeXBlIC9Gb250IC9TdWJ0eXBlIC9UcnVlVHlwZSAvQmFzZUZvbnQg L1JSVVRSTCtUaW1lc05ld1JvbWFuUFNNVCAvRm9udERlc2NyaXB0b3IKMTAzIDAgUiAvRW5jb2Rp bmcgL01hY1JvbWFuRW5jb2RpbmcgL0ZpcnN0Q2hhciAzMiAvTGFzdENoYXIgOTMgL1dpZHRocyBb IDI1MAowIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDI1MCAwIDAgNTAwIDUwMCA1MDAgNTAwIDUw MCA1MDAgMCAwIDAgMCAwIDAgMCAwCjAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMzMzIDAgMzMzIF0gPj4KZW5kb2JqCjEwMyAwIG9iago8PCAv VHlwZSAvRm9udERlc2NyaXB0b3IgL0ZvbnROYW1lIC9SUlVUUkwrVGltZXNOZXdSb21hblBTTVQg L0ZsYWdzIDMyIC9Gb250QkJveApbLTU2OCAtMzA3IDIwMDAgMTAwNl0gL0l0YWxpY0FuZ2xlIDAg L0FzY2VudCA4OTEgL0Rlc2NlbnQgLTIxNiAvQ2FwSGVpZ2h0Cjc5MiAvU3RlbVYgMCAvTGVhZGlu ZyA0MiAvWEhlaWdodCA1OTQgL01heFdpZHRoIDIwMDAgL0ZvbnRGaWxlMiAxMDQgMCBSID4+CmVu ZG9iagoxMDQgMCBvYmoKPDwgL0xlbmd0aCAxMDUgMCBSIC9MZW5ndGgxIDEwOTM2IC9GaWx0ZXIg L0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4Aa16C3xU1dXv2nufM49MJjN5T55zJicTQiYhISRAcEpO XgiE90MSaswkvEFMIEALhSY+KBhA0FIfVUnUglSwnEyETsCvpN7afra2YN/6WcGKrbal5bNqtULm /s+ZiNLb372/+7v3nKy1915r7b3XXnvtdfbek00bN6+geOohQdqy9W2dZD65ryM5uGzLJiVWdvcT WV9b2blqfazs2U5kGb/q9q0rY2XvbqK4H69e0bY8VqarSCeuBiFWZhVI81ev3/TlWDlXR1p8e8ey Ub7X6Nezvu3Lo/2T0b9yR9v6FTH5or2GfGdH16bR8iKkkzs3rhiVZ01ErgbQ5sf4o5ghddB7FKTH yUqc3FRKt0Bzv/RnklE2+HL8T5d4Dpa1uoIf2DJsZsUn38p5wci8OPDhgU82XdvrJlsCinZT3mCg ntU30kBL3PTJpn9ecJsUg3H9cQzRIvGXQVHkra5JFZcoJN6lPvE2XQBI5AbFjVw1oBP5KECODos3 BxsayrUI0sA4Mw0Xji0fMhjhzOzy/xBv8uM0hrwgXAinZZmcN8K1taOZiZNjmcGikvILNXHiDfob gIs3xAUqjNUaLBxXfqXGCQITXyUXY+SlfvE70gGcNPHaYH5Bed9Z8TL4PxYv0XKz2kthZ2I5GvyR +C4lkVecEidHOScHExLLqaZL7INNhoHPAy4CrgAk6hBPUzdgP+AEQCIXsBdQCphrUMQxcQx6HkZ9 F3ApoAOwHyDBhM+Avs7A4qhYS3mou1ccpFSke8TXzfRbSDNRfhL0XKRPoGykfaPlR5Ea/G+O0h9B OQ3lh0fTh0DPQvlBlI30G6PlLWKzWW/TaNovusK5XndNLvgKoAwgkDuI3EGY7iBKBMzE3eJ2U4MB pOVocX0sxaztCPtUc452DKZnlPfDpDtg+h2w3A5YbgdJkNn+qcz2mEyJ2A6Z7ZDZDpntsEqZ6EJ/ XZgwAnYDFICA3btgd4OuAw8DzgME3QN8ANBvlMSXYMex0OpesTZc6IWzrRqs0sqrz4iVMLUmVg5m 5JTv/6xkjzMcceWgPWE0dRmyK0zZFYP2eIO6YjAzJ5ZCal1NglhGXwFwSgHOB1QA6gGSWBbOL/We FnNovY20BG837xbdUrcsldWzpLOinOZhBXopSZRQEAJjva1BNilk77T32IXbrtjL7Jp9nl3uEN1i vxBeUSqqxVzRKuRIdDhsnTIBiXazZcqEA45+h+4Ydpx3yLpl2HLectFyxSIrljKLZplnCVk6LT2W A5Z+i/2A5YCVhxydjh6HcDsUR5lDc8xzyF4r66/ZKdoxTAJ2AzoBBwASbNwKuiJuA7RiNlphtttA J2BCyQ04j/xFpDJKLsi5IOcC1QWqC1QCNjjzACFAJ8DgWq5zPq1jyF8xOIAx4CagpQTiaCcBdOQA M1FyouREyQmp8/wqNHQDK4B5AGHSLiIHrwH+lFc2yg8htZDBvwLgZj2DpwEEv6q1jRkey/SxrH8s OzCWacHqmnItDygpKalVbfW3FrYeljrUDn9HYcdhaa461z+3cO5hqVqt9lcXVh+WStVSf2lh6WHJ q3r93kLvYWn/rBOzzs46N0tqndUxq3uWmISpGwwHysrNNM9vpCfDGZnlk1w1N/ETGE4rcB/gAkCQ F7gUUA3oAEj8BLCXPwvqs6A+S3MBrQAZNZ5FfRewwTd4Br0PIJu5C8jxG/j4GPLj4SkT5tbMRMht BfQBBNo+jvrHTelY7oRJ14EvmvS5wIZ8P8DQ8vj1OgIBbqmhB7AXUA1oBXQCZDonluDjsMRoGdgL 6AScAEhiKd4lYgl/Fu9xflwUa87xqV5KS8PnJinR5q5x83j4gJMdNfHDJr7XxNUmztcSZjo/nOn8 3kzn12Y6xyDDC6kGFQ6a2Kc5apzP1Tjn1jjH1jjRWjr5yMlTTWwxMPuzieeYuFhL8Tk/9jn/7nP+ t8/5uM+5wef8gs+ol4216+QpJnYYmD1o4pkmLtAcXucPvc4lXuckr7PGyQ4x6EC1Js41cZaB2XvP uepdZD/D3qN6tMfCwbHeCCczYdFwsMYbYSPh4M1IroWDh5D8Mxz8uvd59jEzP2nsw3D+JW9NKnuf zZDwiWN/H03/m82gYyhfQboK6REKMj/Sb4WDdxryT6H+N1F+kvJsRr0naJ5Zv4/NMOmPj9Z7LFzc jl4fDRdvRa/fpGJmSD8ULr4E6tfDxfcieSBcfDuS/WG/oeDacLDIW5PIVlE+N2SXkZ8bmswa7XE6 Wr4d5ZtjlRvCxUateqODCKsLq+ORjDG0fJ6pNM/szhtWzUHmkGoql02qqXQW+c00gblM5Z2UZ6a2 sHonWrE857/k/UfwjDFw+oC5woe8bz2P8d2C4u/ZjPAx7ytDhrnC3nPFEeY/5f2Zesb7Yn6E3RL2 DhdHbGCcLY5wdtI7ACPrkOXslPdE8Srvs6rJPayCi6nuC5Z4H1WXeh/xoxz23ln8vKEGrceIbwG7 uXiqd1bwmHeaP8LA1oLoTIvzTlE3eqtAnhxhMwaPecfnRwxVytDGsVPeIvRYoJqqLJ50mleSlW3W iq2brO3WW6zzrTdZJ1hLrIo1x5ptTbEl2dy2BFu8Lc5ms1lsko3byJYSiV7UAsZ2LcVi7tosCNuM JDPvRmhkWIDmbo4zG8fa0ZNFI29cWMv0pEZqXFSrTwo0RqzRBfrkQKNum/fFpgHG7mtGSee7I4wW NUVY1CDtzNKT6pqGiLHSnfuyjHT7zn3NzaxRH15Gje2K/uFCjCNu/lJdVms9lLal2lOdNDWxalr9 v0EhkxiqD3z2eD7LIufJ0R9sXNikP5PTrJcbmWhOc6N+80Ll1qYhvoF3NNQP8U4jaW4aYtv4hoYF Bp1tq2++LkZ5vBNiFDQSQ2yQ8gwxymODptgsszW4aV5D/UAekCH0ApthCMF9XjCFVplC8PENRlvz jARiPJfyzbbyea4hBn+INeb6fGPxxFxmY654MhvLNoQG/H70VwzU3DQwyQ+BAf8kk33sM7ZqsodY MxkCQ+RnzWY/zOwn1kRhTAZeMCrDbZC5wYz/r4UVtf8XLbDBtteXL2tYoTaE1IYVgJC+Z8tqj97T rigDy183GIouCkLty1YbadsK/XV1Rb2+XK1XBtrMev/CXmaw29T6AVrWsKhpYJm2oj7cprU1qG31 zYNHuusab+jr3ut91XX/m766jcbqjL6OmPX+pa9Gg33E6KvR6KvR6OuIdsTsq3FBLWuc1zRgo9rm OkygkQ5yRxzWQyjL11yb5u6cai6Om3yer2adlgifLUegWY9Xa3UnwFg3JTUlNQYLq9NgJYDsGmV5 vnqTL+s0OzrKcoOcqNZSgDwNa+qv/3V1dW0yYPPmAPCmzQYTGSxa38JGfdr8pU16UA826FqovpkZ s7Z59Klr0txng+eCvCPYHdwf7AueCMqbNzeDnHQ271web83ryOvO25/Xl3ciz2Iwbm06pQX78v6W JzbDm9gmPA1GV+gaKf6M4qbNUKari9BJFyDWXWBzoK6pJo+WYbfLsDMvoWSACpgAWAiQ6X8A/wLw FuDvAInuBv464CnAoEERJaKkwbOm3uixGS0OkUeUD5ZVlk+OIG1bGUsXLo2lDXNiabCm3AN+uHpC XI0LG29Gp4F/DHgN8CfAPwGyKBflZuPQ2Xiau6grwGAtQmGTgboCm1gAGWaYe1NXIAABowwCSrCt aV6URx9iXZsJpsCEIIGQSe8yqqEP1B19DAZCsXwfYBZ5Adk4XWURRd8EXAK8MzIzelVeR+rI2uhF kQzhZ0eByE8PUh/l0xU2nl6gYUTyI9jqzKODdDOdoxOUQFvZT2BNFTuMo4gXXsT9aZTOZHqEXqVb aSO9TRdxam6kN1gS2mmgTpwaq6LvAjfS7ugQpOKojr5Dp9ntbCHuFepoOi+GJfy0PzpM6VQY/Wn0 tyg9Tm+z/OgATUfuD5SI3Xk33Y9j9Fr6cdS4JcmndnqabWfvYm8Voj1ShdQbXUc30Un6FWtEbjZt lX9rP4ndwf30FEtnw9EL0T/S9/AtXYGW7qLd0DhMw3ycqJP7SaEC+gLNoTZwv0KvsmQ2XmjRMdHa 6COgPk3v8QD/obBCjwDNoFbaR0/AGr+mS9gKOFgle5wdw/sK+6v8W+jWSJtpG/VA8yOoe5yG2Hg2 nqdjf8gxwrG0GLz9dBj9D9J51sia2TD7vjgsl41UR1OiqdE/RqNURE3QsI++jz7eZ2WQQQ8iT2yS cqVNcvm1OzHC5fQYnadXoMcbsPsH9BErwvsm/yrvji6JHo2+DV1s2DtMxv3OUuqgLfQlehKz+gL9 gP6bfcLtkDwnvShvk69EH4BtC6gWus+F9EK0vQezFKYI3l9jlIlMwSgmszlsAVvF9rMHWYS9yl7l Fu7Dp/JPQhc/Ea9LE2U5OgUtpRkneXjJElqNGfgqrP0AxnuUXqSXWCorYCUY0a9R/0N+E6/H+xQ/ x98QO8V+6ar8tZGLI38e+STai7unevhdE6z5DKzwN5YGHcaytayLvQXND/DnRIJwC1VUihqxSDSL 3eKg+E/xM2mjdEx6TZ4ht8nHrG0jd4y8Em2M3gNbMJzVcuFJxVRBk+A/K+FN66BfJ96NtJ3upF66 D/7yAPVjvxuhs/QS/Yp+R3/BDBDzQec16H09vG4nuw/vI+w4+z57kb3E3mQfGi/Pw1vIJ/JqXsen 8VV8J96D/Dz/NX9HZItlOH/34D2Eq6BXEaUlKSqX450u75GftvzEWmidbm23vXz18rWia83X3hih kcyRL448OPL9kT9Gb4luhf5+KqFx0HQXtHwEPngY7zPwxFP0Q3qZfmPq+h7jTIbHe5gKbyjGrFWz m7HVmMFms/l4F+NdwpbibWPtbDXebtbD7mJ3s3vYPvYN830YYzvMvs1O4f0uO433V+wC+wP7E3uP w4m5gDf7+Rheyqsw0jp+M5/LF+BdxTvwdvKNfAtm6Gk+yIf4r0Wy8CPatokN4hHxHfGC+KX4WOJS sVQqBaVbpFXS3dI56RXpt9InsldukFfLh+QXLFmWCstiy1rLw5YTlncsV60W6zxsV7dbf2mN2vyI WD/CuE9iTj97Si3nWJecIn2ZX8C68IhOeRdbDItZ+CJxu7hP/Fxeya4Ihb3GesUasS76lJjGPxId 7BZ+luUJrzwFVzl7KcqO8Tf5+/yPUipbxN9lhdL97Lu8Q9Rx3DEgpv5CSpXult/BbcBvaArfwYb5 i7i5ujv6HzRFPsQuyIf4K6RIF3kyXcCq3sUfQqWf8TV8DzVJFfIntAZ2/7b8Zdh7Kt/NisQvpUP0 tlD533G6ehBR46dsppTPb+NV7Bgi7jWWS5fZBupk3yCNnWG/YxHsiY+Kp9ksHo/Z0rmTTcJly0+F j/1SxFGzoSMr4KlsHr/CF4vnLedFJY495+nntI0JVgbf+fQZoTuwAg7yMYhpDYgmv2Dl5KGHEO/f H3neiNjyb+U98LMnRDEtoDJq4T+hKVgbb+Ntoq/hju40fHA3lfGHaXu0hy1H3J+N+MkJ5zYqZQ5E y3To1o3vRRrPQyxsRdcfIf7/GFG/kf2VvsQUrKxhKpQMzl6pAZEphPi7B+9yakHpMXrAclL+Bc1l 6USSMnIIXv463YZvzlvoPxM31Pcjsj0hFUNrBZF5A2o8NjKdNLxfo58wTjug81Ss83nSdETeB6Nr McI1+EbNwjfxJVoTfYjqMHcLondH91Br9InorTjhLoweRfzdEg3TRNolN/Nb5IBUgRj7EvsBvkf/ xfYgbk+n1xCP/MxDf8L7Heg/VT5DvdJvEDuro3ujv8ItayFuXh9BnJmJ6LWe/gq7TRfDNGFkDh+I ThOd+EJdoPnRp6NeFkero7cj8j5Ph60yYk8P5cqH4bt7pJW8DPqOpTRWCuqtch+RVrt4kVY99QvB m6ZUTZ40sbJiQvn4stJxJcWBorGFYwr8+WqeT/Hm5mRnZWZ40tNSkpMS3a4EZ7wjzm6zWmRJ4Chd 3KBOCyl6QUiXCtTp00uMstoGQtvnCCFdAWnajTK6YtRrA+sGSQ2SK/9FUotJatclmVsJUrCkWGlQ Ff2n9aoSYUvnNyG/r15tVvTLZn62mT9g5p3I+3yooDR4VtcrOgspDfq0Lat7G0L1JcVswBFXp9at iCsppoE4B7IO5PR0tXOApU9lZoanN0wZ4GRzYoh6plrfoGeoqIpmhL+hbbk+b35TQ32Wz9dcUqyz umVqu07GrjlgilCd2Y1uqdOtZjfKGh2joT3KQPFw796Im9pDgfjl6vK2W5t00YY2GvTEAPqt19O3 XfJ8VkTj2J/v+jw3S/Rih6gYwr29uxS9f37T5+pm+YwWmpvRhs7900K909DxXsxTo3F80/nO5iad 7USHOGH4zTHFRhc7/vhDaxXdrtaqq3vXhjAxmb06LdjqC2dmakPRi5TZoPQualJ9enWW2txWnz2Q Qr0Ltg5maErGjZyS4gF3YsysAwmu0Uy88/OZFTB5jGfmTHEj17jgul2ZoaM6A4cGXVmmQJMmFWOa bKAVk6l32WSYH08zQy19OeZjjW6vC/W6p4DuxhCZLvvdqtL7AWH+1ct/uZHSNkqx+N0fkME0vOS6 o+n4yI06nR4I6EVFhoNY6zCj0HGqWa4sKd4S4bra6VaQ4PRI82DbtuYppTC+z2dM756IRu0o6D3z m2JlhdqzwqSV4pTFQwZn+FNO6mKD0/Mp53r1kAo/fg7fcKJU3VZw/c/lTktuWD1FZ2n/G/aKGL9x odqIM5jS0Bsa9dnGRTeUYnzDoLAbeKM5FqsIg+uSX7f4Z6hwvQU4zIGAP9k/TW1YE5qOpQYd9eS6 JpHF0YCR41nCbAr+e+vST9szCk3xRluS32L6//KI1QYHNilMmaa7Q9NjuDnO5xtdXv+nSpHoFaOW mXxWbXTM+pTA6KhiY9RvuqF8g3rxvaJxEaITb1y0tLc37gbeNMS93t5pqjKtN9TbFon2tKuKW+0d Ek2iqbezARErNv2R6Ok9Wfq0vc0Yymo2BU7OqXZAZbvnD2hs98KlTUO4/FJ2L2oKc8brQrXNA/ng NQ0piM8mlRtUg2iIKEYB3zysijC3mfJZQxpRj8mVTIJZXobbMJMWEwKN0TJc4po096dyHDQpRtNM WjMeI1LULWoatZc587CY4QmE326rWLZxRQe4XyK6AigGLAQogHZAE3+GjgIaIYbtLjDhF24LvqOQ wTc0RjHJ/wsymsaPLPjSy6hhxanj/9djR0NxZmM34XS3Cmez73NdVImo9LzslrHbYNnYlWUbPw2h 39kDnJ3h3zN04GfDJEsR/r3nBMVZjcxJRhk2i3wWfE6CjSU7W8duI0/A/WHwWnCO+/3g7GtBqkbe fRVofJkv0ZfoB2LZEl1VxPBVTaZPYK9h2OL+6CXWgR2KgwJaNmkWh9Ds2pRKu1Zd2WpnffYTdm7f Gb92m9H6ho2BwGWqvjy+zF+elppiUfMKKismMirVasaNq6l5wcTjSjXD7lcwEIu8Gieoh7QUzRPy 9HsueiTyaB6+BVPBE2qScQqpge792F0IM29DXkXlj/DT9BrsFGqQf0/DRbYLRzwm223xXODA/Q+I z9CSEhJcWmJlmavbdcDV75JcGemneT67BDvABC2B4Gz35Utuww7VwcSkKpZYRR9cvso+CATGYw/I NrQk+yckpqSlpaf6KqfyysSKMQUFap71CpvpSw7eOsJDk9PirP5Mf630oyc+2bVxci73+3nO+G38 9YNFSq7XGGMxxngMY8xlq7W7rB5HVbon+wsVHg0ow0Cu3LS0sdagdYb121aLpnxRWmr7YvpSzzrb psRNSY85Hk94JPG443jCS/JL6f/peTX9Vc9F5WPp4/TUVJYjZchZqRlpGek5Hqs93eFx5FRk3Jxx b/p+xerJ4Dw9MyM+w+IUGVy2YGuUmmJNlpwRqGG3aynx1T12Zo+ICVq8W87cn8H6Mk5k8IzTYgIM t2+Q8fjcCNunOcny+7nJrckdyd3JUnKEWbVkDYPKJEVTehQRUvoVrmScYR/DI51M01JacSTq5vv5 WRxyL/C/Yf1neE/j+MhGTT77UvDyHHfLhg9bZr/fctkNTwlevtayIVh9bcOAxVjS391vZ2ft5+yc WjY0By4lJqVXmTOTVFXF3TGR53Zk7MsAvzkhuMst7/hBwg/Gl7ENG1swY7gYogATvkqiygpMlcWq Tpw4wXBEHKq41Vc+ceIkcaz16kV8KpVDdyzvK/BnnHv08O/KZh75eCprv33JtEwmj3ziZ7Xs4W/f eWTzhqEf/vLAqlVPnhy5Mtk93riDWxh9R9yC+Sxns4YoLnoxHF9lN35SDsZX1dgb4qY5GvOkc3Y2 duzksVpFqOJcxcWKf8RZqYLV2LvVbeOeyR/KPz3upXEX1Av+/xr3p7x3/fEzbGMjbO9gYaGbIvzS 4PkyVhYRFSeF7E5jaRHWdzJHC5RW5OA3nkG3c2zhGbaaUsjO38Kv0JgDfsCcA8zkoB7P4iPsAOgl PSX8QEl/CS8B/WSrtRtjj/C3tTitgvVXDFfwCpxbpn5XSz6bzJMzJpxmueyd6xNkzs7llg2Yn5YN lxApsJoDlzdWX265nFRVioVdt1WbOK40tyDOJVnyfKov3+f3SRbZn1BQEKe0s1KppJ3lupDzOca0 szj7OEtZO/M6c9px5ecOjl72Fd2Jx1xjG2lDIJBsTJPppGnmZPnMsGGQ0tLTJpRj4z+mwFh8qrEO jZm1rp4ycM9TS2pP7+jpfGDkz/cuK/VlZCZ+Od1ftPIhNdMbeHCOMrdv+p2hR1dLM+/9xtq5Sw8e Gn/qK/qdR+vH5BTb5GqL49Dtcxsn5xTW5Mbdds/cVd1HjA+GgtU6hNmNw4+Ov9EK05zMRQ1OzSU0 FyuKZ6lWxi1M2GULk+IdTpLinZIl3olVla0lWW0pVqvNJiSrJR43UU7mPMMeQ3R2sD7NKTOL3Wax 2GQpPl46g59IBNnYSs1ht7sE6xMnBBcR9g/Nw6rN5eViIcSriy7hsmhWZs1I+Nwa2hA0ZyiIBYTs H9xGHK+uKnUH8V52X9sYTKxKRChLqto1LiDtcP/AyLpcLkS0jS2sZcNGlqomqom+SjYBCRNDpw5f e4FvvuPwSD57/76Rb7KVPeKuq3v5E9dwUGXUDn/fiptVH8vV6r4lsaTm3DW53XK3pTtnr7Qvx1rJ K32LxWJliW9d9hZ5a/Yu3pvZm/2UOGrvVy+qLvzw6HInJiWnpqXbUpxcYJTZWqLiS1GEpPgys7KF 1SPJoPYNKoov+TQiiUcka7Ap+z3x3/t8+MyeZlMpi918ssfab/gx+wB+rDJNDalcxQL5+JSb9/uY z2hEsyuau9/N3Rl5p3G5867p1JdaEObdLYZ1jMBz+RKCDvKXqy+bDo2ob0SZXbZxARnmIqMQCzSa cyPbyDcqd7G7+F2KBRHHCDSIM9gRao51UkfS8txOuTNHbmlmLczqs0qGB1ss1tGvHgLPqPPCd8cw sXXOyOpmZn9055J75ndt3dYxTs0cU9o4e/PAoT3rn2eSPOuZU2MO7Y6sO9UzZtLC8uyA21cx0P2V X00psXKX4Z1NmIsBeKcHp+2rWtFm+5a4LyXcZX/V/67fYhFsh9gmbUvbmS4FbYUWWagZhRkWobTa mA2x45RSwAoKXLjJ3DfoIRmnUcugy4krfaYZc6QlOTKpSCviWlGoqL/oYpFUlBGzO1iU7E5WksuS teQDyf3J1uSMsUbEiIX0qy2zr10yI/rsy2aoQEBHmGi5vBFmhOt9asvnHLjmMoK2GT+Ks/32pJzs 3GxuSfQ7C/x2FRHCndVOvgTk8uMK2ll2ktJOefFA5i8F5pU/goYZMlhqgrB+GtfVvDEFiRVJ+RMn MEtqynWLI/iLB+95+ql1+Qfu3/Pyqu0v72n73gPM9dG6ay8n3Txtwowl9+7eUbBEXu13zn3yR/cu u6g/s/eZWwdZzik2faTpWv2uhaE3a0u/9fCxfypYBUdH1vIQfkew0p2aR7MzstqFJBcI7rZaCogl 2dPTMwU+A2Gt0kymGEmPpk6qdAtFdOIeVOoRBwTvF0zski06w51ViHOeYbNH2PhB38+X4tfaOe9v wIbkWhDrGpuowJyGFfV/gKtio2bs04xlXAX/a2HYpaUCeGhkOouMvMHyRtZa2dyPH4OejSNruDD1 vEfL1+z9dh6yM2hqsRbgn31kHBNEUjU+/FCXMa5bzH+KmlJpJFoulJUVuVPukaUe+YDM+2Um7yrD jSvHXtL+PBtPPlrE8E+YhqrG99tQ09xNGpq2fE7VmKbYPkHNSkAj9JwOPd+Q1300MteyHHvc2C6a oj7cfv27xwGiwK1aCu6W0vBLgocysC/XQGW4c4cWeCyg0oIFixctmBVYtGb9iq45K760oGN92x3z Fs7Gf3/+T/2TmU8KZW5kc3RyZWFtCmVuZG9iagoxMDUgMCBvYmoKNzc5NwplbmRvYmoKMjMgMCBv YmoKPDwgL1R5cGUgL0ZvbnQgL1N1YnR5cGUgL1RydWVUeXBlIC9CYXNlRm9udCAvUkZMR1lCK1Rp bWVzTmV3Um9tYW5QUy1Cb2xkTVQKL0ZvbnREZXNjcmlwdG9yIDEwNiAwIFIgL0VuY29kaW5nIC9N YWNSb21hbkVuY29kaW5nIC9GaXJzdENoYXIgMzIgL0xhc3RDaGFyCjExNiAvV2lkdGhzIFsgMjUw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMzMzIDAK MCAwIDAgMCAwIDAgMCAwIDcyMiAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMAowIDAgMCAwIDU1NiA0NDQgMCAwIDAgMCAwIDAgMjc4IDAgMCAwIDAg MCAwIDAgMzMzIF0gPj4KZW5kb2JqCjEwNiAwIG9iago8PCAvVHlwZSAvRm9udERlc2NyaXB0b3Ig L0ZvbnROYW1lIC9SRkxHWUIrVGltZXNOZXdSb21hblBTLUJvbGRNVCAvRmxhZ3MgMzIKL0ZvbnRC Qm94IFstNTU4IC0zMDcgMjAwMCAxMDI2XSAvSXRhbGljQW5nbGUgMCAvQXNjZW50IDg5MSAvRGVz Y2VudCAtMjE2IC9DYXBIZWlnaHQKNzkyIC9TdGVtViAwIC9MZWFkaW5nIDQyIC9YSGVpZ2h0IDU5 NCAvTWF4V2lkdGggMjAwMCAvRm9udEZpbGUyIDEwNyAwIFIgPj4KZW5kb2JqCjEwNyAwIG9iago8 PCAvTGVuZ3RoIDEwOCAwIFIgL0xlbmd0aDEgMTEyOTYgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4K c3RyZWFtCngBvXp5fFvFtf+ZmavFlmVfy/sqWdeWHcmOjWzHJostrwSMEicxYIeY2HFsHLI5CykJ lDihbGZJWngsgZawFHjQ18hXISgJAT+ghbbQhPa1TYFfEkrasmV5lKSvEFvvO1dmCb9+ftsfP12f c2bmnDkzc86Z5c71+rXX9lMCDZOgQN/K3iEyfu7DIC/3bVjviuVTHyayegaGrl4Zy+e+SmT69OoV GwdieS0Efvxgf+/SWJ7OgU4bREEsz6pACwdXrr8ulndHQF0rVvdN8jXoJ8fK3usm26d3JX9V78r+ mLzvNGjF0Op16yfzL4BWDa3tn5RnnUQpDSibF+NPYgZqpU9pJm0jM3FSqZwuR9Ed/FUyIS/5poQ3 a72zjixOmnnGmmU1Kj72fnWrTPxs9Oz3v7h9/E6VrNWQjTPkJQP1LAUTLXSFSl/c/vlR1SiRjK9+ 1tEOV0RJCCck+iXVUzL8EcUWLnE5kxpUxUHDAE5JwPWAxQBhYEYBxaFfVxmIgKyNkVUxck2MdFQG XoD4JVQZHVMc4YxMv5QNxyf4hyW1xsl8sr6wMtAQpyRjuFIumRbEqN4utSTrQaklmS6KlYabW2K1 GmPFdZPC0yudDYUQcwECgCHALsBpgBm9T6ZywHZAFKAYOSm3GbANsBNwDGCWXdCtlUkNOYoKjmqM XSUnUuUAQT2KtG7IwEmKFVax0lzAI4qFFCVepxXOvVAiwi0tsqci7JtqUL1kit9g6Nm5/gOK4A9S MTkhyfT0HINDemPjZGJabSwR9pb5jzbEK0SnAFwhhVFJrFa4ZKr/9EvIMzFBSYzJUnEurKaiNTEe TkrxBxpU8Q9qB3AKiVEaA3BaLc7QZgCH+C697ALZkNgVjk/0q5A/RS7AMEDQTmBm5ANISflT4ZR0 qf6velKyUe+oXlEVS4TVTH97Q6p4F/35hfgNaeQUfwLNB30NNA/05+J1shv9fCKcpPqH0d7jEH9c bKQpYP9YbCI/6NPiRsoxxP6oJ8ba+aNe4vU3xIunxA2GyDqxhqogukIs1/1O137xBHoaEJ+E42yy f5/oapr/gPhQLKdUSB2HVIYz6YBYReUAOZJIOM7u396QICIYZgRmcaKPjB4xcED8RocitPevYpjS wTsotlAa6DNiq57mHNsv/m60d1ZqQXuPIWIkCdsT/WMNceIxcEPiU1j8U6O1z8KeWj81eMSdVAHg MOr7SL2PlCpOInUSbjoJ15yEa06iFycRtCROgHMCMuXiCA2Jd2g74BGkFQxgow4LStdt1AtL/HvF d8UNsIS6H7ZjKL0xHJcoe3aD7kgxxG6QE7z+gPgDzQVwGOuwnJGr94u7jaFsD2fmyAr/occlwHTX x3wBTZukDw6IYbHVsMQWwwKhF5FllCRuMipHwwnJ/s3wfgeyq4G3AQ4BTgEUiHVgDB20GIDFW7SH E5P8SfvFQqPyxXpipfOAmI2hzzasNVtPcxt9vmgyoSTpOfn+FzFXkqgMK5pfSVTMerlz3n7RhviZ K+boS53o+zwdeqVN5oRrp/sr9os5hi3m6E4tVqynZBmJVj0uFldN4fhk2ZNmQ9CnWxMNvm9ySgpv ODXD72xQxXRjtJXAJGrgvhq4pgbzpNJwhj+sOhD9S4XfGJGfepDaCQgBFPjYD3E/fOynY0ZJkpiG 4U6jKEDAt9PoNADLrLiA6gHbAC8BjgFMRmkPUhzlFWihB3g7gENjOfIqcADQAxgG7ASMAU4DLHRQ lKGdMkhXAA8DQoCjAAW+KkU/SsFzCBeNY1Nx0mb+YGA620yb2Wa+WWxWNps2q5uTrYHqolJ/4BqJ pkpUAlTTEzcUNxwnKuICce1xQo1zxfFIdEy3TK8ECTjM0yvfDn4U/DwoHDXbzdst/GBDAkumo4BT AEEHmYqcipwauFUcrDtad6pOHAweDZ4KioNHjh45dUQcLDtadqpMBII50/01i9lqtpltY4qTlbN6 Npcpi8VqsVlsE4pTlIt6xILSYxuyDdtEhS1ga7cJ1eay8e22nbaQbcx2yGYKmcfMh8zHzKfNpnZz j3nIPGzebt5pNjst5ZZ6S8CsnG5o4u/AqDuBQwBOw8DbjZQKzGgM+JCRl6VwB/CQkQ8AtxspDbhC pgAadL0NuWHg7QBMPiOvAVfIPEDD6v5HyAwBbwdw/sdArruiMFDI1UJXIadCdrqQHSo8VshDhWOF fKxhOj8M+Z3AIYDs5WHUlCkNuEKmABp6+wdD7g+QkxN/GHi7kdoJ/O2yHpQNGdwAcLuR0oArZIr/ Qddqkhoy+EPQuBj4EcBRgKBy4HrAaiPnBGb8IeAA3xEuLsWGz3foHqyRIO4YyY+RXIOEs7L9ixuS +A6o3AGVO6BS5pyAepmLjvEH9WYp+6A+K0amVx5tqMEuKrvyIO0CcJoL/IiRKgeuN1KSg6Xqq3wI qWMGZwh4p5GS9aQW7APAX9YVfAeeB1GSxDehdFPAxik9HUcnR7LVEeH79GUOZ4Tv1ktUkHCM6JI0 pHAB29vZSQP/1MCPGPheA19h4KSATbP/Q7P/TLM/pdkb4vklVIhKpw38oYGvCSQW2j8otP+80P54 of2xQvt+9j65IVQQyHbb/+y2/w+3/Xm3/Rm3/R63fZHbPs9tv9QtVZWQi+w8T2J2lYFzAxku+zmX /T2X/Vcu++su+6Mue5fLPt0FcfYpVUHwYQPfb+Dq56vszip7XpV9H8fKxK7UkyhuP+fsSrKLeN1b 54yIOIPwAj1YBAvk6sEGkBw9OB8kWw+uBUnRg/c4G+J4EhvFYcXJE9moVdIE3bsFbFuMWHXvVciZ dO+Fzgib0L0ayBf6QB7I5/pAPshZfaAK5IwkL7C/0QCHGvaf+sCPoJ59RCVSLfsrefizoBE9WA/p 52Ots91Ux4pQrON0KMV+onvROfa07i0BeUr3FoI8GSOP614nco/qA1NBfqQP3APyQ33gOMgOvWSF bO5BKjH0PEAeg67Tgzlgr9GDUtGQHiwHWa0Hq0GW63VvgizT647LqlezUYbIZgPkNXraqw94wV48 OZBuKjHYi6ja0HyRHpQmaZVKGuysZXIgzaxJnvlYIxs1tAR0bwXE6nSvB2RWzHIz9QEfcrV6CUzN avSSH8Fy0yYbmCL98wIrRDekIk33Pgshpz4wBSRfH2gByZE10eeUyVYdVGd0Kln3SilV97qcLzIb DRhdjicP27HHOQ69X9RF2OW68/NAxMp0599LQPY4PwkucX4cjODE6/wIM/nZPc6jED1Sh2TA5nzX e9z5zoDb+UsvJAI5zl94pzpf8Wx0Rkr2O8PBfOcoOhYaWOLcNWBo+KkH1XTn0yURzlB758Clzge8 Puf9Hjhpj/MHEL5VtgFFN3s3Ord6tjivRSCuD97uXOfNcw6VXOW8pkQ2lOFc5p3vHMRArkad/oGr nb3ee5w91UaPr/K+6Vwgk7qzbcAY0cV1BmP2wHxnK3oARr1koAczEJd+VJ1avV/aCCeVpvCbzstq XuDYhdkwYG1gquWA5UbLEkuHpRH7TbGlyFJgybekWh1W1ZpoTbDGW61Ws1WxciveBnlqJHos4JOv bKlm483NjJcARngNAVa5xEDAxJmV40UrlCLaeNuCxlCNry1iic4P1fraQtb2KztHGbu7i7WFxvqo bYkrdHaBFmHx8xaGTFojCznaqK2jMRPCIX5bhFFHZ4RFZY2bc0KOps69xFjpzXflSNp6811dXZS+ oT6z3lGXfGFr8z9BPUZhT3NLs+/rX+bXSaQyfXmh+9oWdIaeyesK+WUimtfVFpqywLWocy9fwa9p ad7Ll0vS1bmXDfIVLfNlORts7oLYDEOM6vhyiFFQEojxRVQnxVC+6BtibBTFzaN1QFJoLhuVQpg0 cw2hhYYu1vRNIXEHazKEmsQdhtCPYg160Q80GJAEukwryGs06DWtMMQypdiox4PmBoC6Okf9HgiM evwGe97X7JIY+99i7H+T7AhjX/OrDf5erOFSYi+WtBLInGfC/8+Z/sb/hwZZeNaGVZ0t/VpLj9bS D+gJ3bFhMDM0vMTlGl21QTJcIeHpWdI3KGlvf2iD1t8cWqU1u0ZnGfW+xe6U7Fla8yh1tnR0jnYG +pv1WYFZLVpvc1d4zpbaNee1dftXbdVu+SdtbZHKamVbc4x632prjWTPkW2tkW2tkW3NCcwx2mqb 38ja2jtHrdTY1QSfSxrmtnjMlp6cgq7GdHWozpg6Mwoyb8zZpxB7mmy+rlCC1hiyA+SsKmsoa5As TGnJSkRx0iQr88YZBTn72NOTLBXFyVojrc9sWdaMv3X4rV9/LX7wybp1McdIniz3tRh8CKxHChg/ SCItAQVf89eT1DH58/lisrTO19Q5Ggy2ZC5rzsEhPizP3b6udeTzQdJoi9AmRm0c9NONg77NnF75 u+Cfg2eCYsw44R/C6f6YccIfw+n+EOAYTvj5YqzuUN2xOjEWPBQ8Btkjh44cOyLGyg6VHSsTNZM9 kE11MXT16+da37prZbGPGaM1xo0cStb71sEEwJNmQA6M9QBpJcmTSVnVB3UG0xcbBUpiCaPmuvXI yApGqVEk68ha10r1kv0//SZLsQSb7ian6VIDcsW9uL2g6HuA44APJi6JnjMtJ23imugxkYLlujAG kzdwRfQ9HPQ+oPvoJeqmX+Hc2MKmUiduejIpCwv7hdQG82WQicXj6kejNmrHVcQl9Gdmp110AX3E WmkLzjZz6WGcC+fgJb2Bvk872UXRD2kL/ZYto2dR+2kWwHXTpWx29CjNo/bo82iDaAbdTztYIjar S1k806JHoGEd3Ur76PcUpYX0gGkntLTTfFoVfZ4W0VtsIbsymksX0yq6kR6gR+kAHWe3sTHFFO2h alpCa5mFpbASsTX6NNWaDsc9F301egi3masgu48+4T6lNXqSAvSBwqKDOOSnUCWeVfQY7aF3WSar Fk2UiOPnItjiBtolStDH2XQ7xraPXc92icToExhNDfXRZoTUdWyMF5gOm05HN5ED46tCT0foCfp3 eoU+hrZW1iFWTtRHcQ+A/dRHLWjpe3QL/RSWexnPqyyJFbCLofnf2RH2nlgl/gLNT9EJOkv/xUrY MnYjr+dbTf7xLdHnyIMRBqDjYrqCVtBPmIcF2JWo+zD/Dr8Rr8p7xLtKiXIqWht9Bdc3eCWnrfQM xvVr+i39Af5qZUH2e36jCJtuiV6P/pbTIEbxPfox7aUzzMTiWAJLZS5WyWowsuvZGHuP53GNd4ol YpfpzujG6F1UgFjppn7UvIZuopvpeTpIf6KP6QTLRs1y1Kxn7ewuvCK/yg+KK8QicZ8SUO5TnlVe Vs6Zkk0vT7w1cQxWl3oqKIinmwZoE2wdwfMKvc0Ey2H50DSLXQJNi9kAu4FtZ//CHmdPsj3sNXaI fchOsX/wTH4nv5fv5z/jB/khkSe8olk8It5QCpS3lS8sveN5Ey9NnIraor5oZXR79OHoO9EThhdy qYjqqQnRtZyGMfrt9C/0Q9h8N71Jv0PcHTWe43QaPviCmRFNWeiRm2msmJVidFewTvYdNsLuYU+w n7P32HF2jhNP4G48Xj6NX8IX8a38E35OxAtNNIjrxP3iN+JzZaPJj+dZ03Om0+bjliLrG+ceGj8y QRPLJu6beChajVg0I/JSMOeqqBExdwm8vJTW4FlLG+g7sNEmWPxhRM4u0mk/vU5vwPYH6R18AThK x43nQ3jiMxqnCcbhTxOz4on1vQKeaUK09LB++Db2XM+2stvZA3geYj9ij8K+b7HfsN+yo+x9dgZj Il7GG/hFGFE7v5J341nM+/gWfgffjefX/Pf8Hf4n/rlQRbJwimLRIq4Wt4kRERK7xX+I3ykepUGZ rSxXXlPewshnmy42LTb1me4wPWp63PSy6Zem46ao+R7zY+aI+QNLvGWapR3H0tst/2rZb3nXErUW I56C6P2UyXVKknvYlUo5386iPIJxv8jXi1/xe9mz35Ag0wh6sBQv0xFxgP/whu24BP4J30qkNBtS s7CKvUEv0Bum3ypppg/oNZ5NJ7Ee3it6+Yt41c5k08QM5WblDaw6G9HPx/lRbuG7IPExvLGYLmNZ 9KlyOZ2C/Q+aRmDTVn6EPct/jlfnbjpMT/D9hJd66mc16N1Seo4+p++zvcLF9iDuNtMh+oSOfd1f pXy8kdebM/kG83R4aC+bF32NT4l+jFn/HruZ3hGfI/YvZ3NYOT1J78Prv2NVzKlMKDn0Fla+fHoI UftXCmMO/lIpxAw6Q3tFFS1UjiFey8d/MdFsWi9uYmd5A9yZYazcc+VqjDX4AaxVch1NpF2Y61hF jBn9Mb3J3NhPfmt+m3bQNton0qhI/JgP86h4XXHRD3AleCla/S7Wp1x8q3qaVtIyWNcV/cvEE9Bw DdVSLVvCFlIzOLMpP7oSPX8Sa1Eguij6oKnL5KNfs0tZGr2E1SsTVrzPFDdxApK7MQ/fodnsDgpP LKUx7CuZrIj5EU0nTBtM203PmHabXjS9ab6ArsOsfQhe/BN9hl3Dxfpgi4/o74j1RsyeUsyfBvRi NvawFbxLHKAmlk1DWANLsG43wgYL4cl10LKV7sR8+jH2kF/TaaayRfQiHcbMycA870P7Vuhpo8vg 9XX0JFbHm1gYJUvxScGLefY5S2S1fD3ak+vsfVhnx9Cnd+kvWDmiRr9K2QzWDO/10d/lXEYL06gd 7wMU3UMXYqdsFm/Qn3GxplIj1pcnUK8HsZGITxUXmt5nnEon5kRr+TJxgKVjN0xEVHVgZ5/F1qAX SRjHOKWxuVQ9cRG0PYu1rN30Y+y+PuwMaTxNucJ0Gfr9NnayX9PaaCfbYcEMCDRe1hGor5s1c8b0 C2trqqsq/RdUlE8tK/V5p5QUe4oKNXeBy5mfl5uTnZWZkZ6WmuJIVpMS7Qm2+DirxWzCVyNGpS1a a48r5OkJKR5t9uwymdd6UdD7jYKekAtFrefLhFyyXi9Y50kGIDnwLclATDLwlSRTXTNpZlmpq0Vz hd5s1lwRtnBeJ9J3NWtdrtAJIx000tuNtB3pggJUcLVkDja7QqzH1RJq3TA40tLTXFbKRm3xTVpT f3xZKY3G25C0IRXK0IZGWUYdMxI8o2X6KCerHUMMZWvNLaEsDVWhRhS19C4Ntc/rbGnOKSjoKisN saY+bUmI5CHaZ4hQk9FMyNwUshjNuJaFMBq6wzVaOjZyZ0SlJT2+hKXa0t5FnSHRCx0toWQf2m0O ZWw6nvl1FspxXL/1m9wcMYLjsUsKj4zc6grtnNf5jbo5BVJDVxd0oC4vau0ZaUXTd8JTbfIVL8Rv 7uoMsZvRJF45ioxRxcYXex8q6rnGFYrTGrXBkWt64JrskRDN31igZ2cH9kaPUXaLa6SjUysI1edo Xb3NuaOpNDJ/Yzgr4Mo6n1NWOqomxww7mpg0mUiwfzPRD6PHeEbKEJeptvlfWZbJPmoXhwKIqD4X etKpYUy1EvXX0khfLRyAXxdDrdBSeGRZKK6pZ0SdLssxRBYyFamaa+QMIQK0E5+cX9I7WWIuUs+Q ZMo4+SrUQqz3y3TI5wt5vTJELE3wKfpYZ+Sry0o3RPgj2pDqAsHrJLXDtr1d08th/oIC6eA7IgFa gkxoeF5nLO+iJTm4CCzHaxfvkZyxLzlpl0nO8Jecr6r3aIjk3fKmhdJCVs9Xf0lqekrL4PQQS/9f sPtj/LYFWtu8hZ2ulpGeyaht6zgvF+NLg8Ju4E2mQilNnSKHo0ymeI4wuAjKRQu/EkGmMyGkFOHP bAT10ojFiqg0SpirNaT2zI7hrviCgsk587+rFImelrUM8nW1yWGEpvsmOxrrdmjGefnzupcwIto6 sOTwto6FIyPx5/FasZiNjLRqrtaRnpHeSHR4ieZStZG9OM8Ujwy1YBmKeTQS3XdHTqj1zi4MZZBN R9xyahzV2G3zRgPstgULO/fiVsx1W0enzhlv6mnsGi0Er3OvC4uuUcq/KpUyLpnDmxUiXedWg5Wz N0A0bMgqRoGR78OFmFEWE0IZo74Ij5WphlxXl/QNb+ronLSN4TgZ/3AkkflClssJd3TP0C7Ta5Sj rMMn2LvwqeJC8qHMAxY+4gMT/rvFjH0Y48CuFysxiv+PkWzm2z/x7YL/y7xCpvNq4MP0eT/LZG4a TaMNrI434Dy6TZF1OMvFSSYXSYHPkI27OXvFbIkIayCFTMorguItyiuMsqxm0ytcvMAaKA4Hjssp 06eenTk+c4762czg+EyqR1o9B3RBRUFyQXIREMtV6JxLjJ0LmOgL/MvHGNqiXdG/snPiZbLhfOXf S1n4/pjlSKkyX0yWhIsdtiRxcVzpS2ksLSvz8MFMH7R3Bz+T6k/Un7iggvmYH9utWXN7qqumpXwj zS5v6e1tATS39i6RVLxsZJEcX2sUtLQske3jnd+0BncAOeRjtsCi7OG4+CpNIlUin0RXpwxmXl20 Y0qkxHR18jJk7k9+IP2JFHNfosWVR2631ZWX6NZypyYlcnd1Tg5ZHWW5SXnOPJ5XZ62wsHYLs3y3 dNZzsd6vgXW6ZwbVps6ASh7Vwz1BSlVTK1JF6rSz3cEPu3P2eIIVqczIneiCHdUT9TNP+HwXVLQt 2Dh6lbVpY+ASzadmO1KSU7i5pHhKsbdYmL/OcXN6WkZaZlpWmmIuLPKpniLmlUjLBipOyZXIhzJf UZq7iHzqTFzPyCsSr/xt2ULdrFtmK6sr/dNqplUnV3k8mlZd4M9Id6SlJnKLWRPJqekZ6ZX+mmnJ arGn2JNTNqM+KS696cIyvvhv9z63f9EPXhqZddNCNSWn8qnO6+Y3DMwuKnKlLRM3DFYVFzXOm4gc 3PafP1ycnaBEvzjS4YlPWrsD5z3Tw5tKnfDH3OhxpQX+yMdF/KaA9oD9afte+/PpisNRY6V8NZ9n OMvirJmPOfN/piVZnBZuibCTu9lj+BIcYVc+b/V9LyHBasNHjsWBrIyNBZ5UC1ThP7JUXM57KVPN 5JleJr9yJ/qz6pPwKZqHGGPZ5fJarK1akvCMWVWSBlITEqvayw+V86HyneW83OlhnoAqGWmyqsoq 1IDarh5SFTVrau2WSff6gie656jda2HCs91rZO5Et5wN9Sc+gx/VE+qZE+fYmW6fSFRn4se6L6iA R0vcXntKYZFWxM0Oj/QpNycWuVM8xeS1AxUlFxSz4iRfMeFKTHrL64OrEELlQ/ahlCH3kDdUPlZu Hkrc7NiQsVkbmnJ92S0ZI2UP2O9Pf6j0yfRnS/eVJg4n3Z7MaQ3cK+8+91I5RppVUG+MONNlUPy3 Tb3U3oUgSE7NSE/PSDNVmzG7iuX0mlbpT89IripGPFSneDS3xWxOmwwE8Ruztax24tqLVreGBzsG nxtsGpwRl1DReOsly4syi8qryjJKOueYLv3ijZWpBS6lIHjv5XU7tx64/9SmqgaWvTw9L9c7fsvd qc6HHx19xpMyEosC0S1ewY2Zi1UHOs2OttTu1NWpg2n9mRtTLUXxT+HN8RfJb/G3xGH74bS/if+y x29OY+5ASlrV5WJArHZ/R2x23yRuSfzI/kFanNcaTWfWuDifDAOXVVi7Ta50Yq3pEVayO8eTYjHh y1k4wRaXLr1rg3fTA1nuqvRlhPwe6Wws60iGbYlVkgYyk6spu9xd717sPuVW3K4pScyJNyC/jI4w 5A2a74hRT0WVETUJCKdDKlOzCmrvjgULTO3DanAc8XLW55PB4vPFljYscepMrHXHmfqLNUaE5Cfn 5xVlZmRlcHOuw5lP2anp+Sw/OSefZaQBxeLC69uC2SudvIYVGHN0Wk3Glw50wH+WKsxX6bq0NNE9 Ho1b2NI7c0mt+9LIxkPLLx9/5u63TmpFaVpVwQx2Zt+KBU1XpD+0ZeeWlz5iaR8+9uh1Tkdl10Ma TIFvW7wQc1SlsUCuYzg5o77Hge9RLMmEjVB1mlSzqppthU6znJpuVuiEfU/u1hIKnSoSgXQNNc2m eIpZzZtgC0CFDbbTp1dLEi6rqjKoSzNoQEvJqArZ2DYbI5tq47brnY6djpBDlDvqHdscY45jDpND 1rugqkrSPWVTq5LnjGFH8vm615ztxjyUv5lYeOVMxIrnk/OOoRxxjigvqJ5c6oqrWXhq04SlLj91 aiMCdkNfjVJYyN0ZfeL1JTVKkdzzPdG/8fuUcbwzPxBI3GbblsANZEugrAjbE8hiSmqqSLuJM7PL Jv+bRdjWxvUn2riIsMRAnsm2JyE7hyn49yqT08RN3pT0tI2pqSmBhNT6FPQ9oOa5q8pTxlIOpYiU rOw5l30ZKtgzPpupYgiIjDnq2eAJZKl+/Hi33GmNaJmJYMGocPfFkivTNIxMLtIZcnfEBE7WqqdN q2GRI0eSPGrD9Px5e7quT47fdONoozI+8Uzf+EvzyvP60sf6ZrnvY//Qul7diFUTM9H4RQtwx/jP fvLfWQXevIvxj56zcZd9hSHEcEsaOweZwaP5rZde1NXo61i2sn/dnP7vzF+9sndV+4KyxtUrlgY7 6L8BbFhB2gplbmRzdHJlYW0KZW5kb2JqCjEwOCAwIG9iago3ODY2CmVuZG9iagoxMDkgMCBvYmoK KE1pY3Jvc29mdCBXb3JkIC0gKQplbmRvYmoKMTEwIDAgb2JqCihNYWMgT1MgWCAxMC4xMi4xIFF1 YXJ0eiBQREZDb250ZXh0KQplbmRvYmoKMTExIDAgb2JqCihXb3JkKQplbmRvYmoKMTEyIDAgb2Jq CihEOjIwMTYxMTA0MTkzNjA2WjAwJzAwJykKZW5kb2JqCjEgMCBvYmoKPDwgL1RpdGxlIDEwOSAw IFIgL1Byb2R1Y2VyIDExMCAwIFIgL0NyZWF0b3IgMTExIDAgUiAvQ3JlYXRpb25EYXRlIDExMiAw IFIKL01vZERhdGUgMTEyIDAgUiA+PgplbmRvYmoKeHJlZgowIDExMwowMDAwMDAwMDAwIDY1NTM1 IGYgCjAwMDAxNzMzNzEgMDAwMDAgbiAKMDAwMDAwMzM0NCAwMDAwMCBuIAowMDAwMDkxNjE3IDAw MDAwIG4gCjAwMDAwMDAwMjIgMDAwMDAgbiAKMDAwMDAwMzMyNCAwMDAwMCBuIAowMDAwMDAzNDgx IDAwMDAwIG4gCjAwMDAwMDkxNjggMDAwMDAgbiAKMDAwMDA5MTk4NyAwMDAwMCBuIAowMDAwMDAz NTc4IDAwMDAwIG4gCjAwMDAwMDY0MTEgMDAwMDAgbiAKMDAwMDAwNjQzMiAwMDAwMCBuIAowMDAw MDA5MTQ3IDAwMDAwIG4gCjAwMDAwMTI1MzIgMDAwMDAgbiAKMDAwMDAwOTIwNCAwMDAwMCBuIAow MDAwMDEyNTExIDAwMDAwIG4gCjAwMDAwMTI2NzMgMDAwMDAgbiAKMDAwMDAxMjc3MSAwMDAwMCBu IAowMDAwMDE1NjA1IDAwMDAwIG4gCjAwMDAwMjc4OTcgMDAwMDAgbiAKMDAwMDAxNTYyNiAwMDAw MCBuIAowMDAwMDI3ODc1IDAwMDAwIG4gCjAwMDAwMjgwMzggMDAwMDAgbiAKMDAwMDE2NDYxMCAw MDAwMCBuIAowMDAwMDMyMTI4IDAwMDAwIG4gCjAwMDAwMzI1NTEgMDAwMDAgbiAKMDAwMDAzNDA1 NSAwMDAwMCBuIAowMDAwMTU2MTI3IDAwMDAwIG4gCjAwMDAwMjgyMjMgMDAwMDAgbiAKMDAwMDAz MjEwNyAwMDAwMCBuIAowMDAwMDMyNTcxIDAwMDAwIG4gCjAwMDAwMzI4MzMgMDAwMDAgbiAKMDAw MDAzMjg1MiAwMDAwMCBuIAowMDAwMDM0MDM0IDAwMDAwIG4gCjAwMDAwNDMxOTIgMDAwMDAgbiAK MDAwMDAzNDA5MiAwMDAwMCBuIAowMDAwMDQzMTcxIDAwMDAwIG4gCjAwMDAwNDMzMzMgMDAwMDAg biAKMDAwMDA0MzUxOCAwMDAwMCBuIAowMDAwMDQ3Mzg0IDAwMDAwIG4gCjAwMDAwNTI3NzEgMDAw MDAgbiAKMDAwMDA0NzQwNSAwMDAwMCBuIAowMDAwMDUyNzUwIDAwMDAwIG4gCjAwMDAwNTI5MTIg MDAwMDAgbiAKMDAwMDA1MzAyMiAwMDAwMCBuIAowMDAwMDU2MTg3IDAwMDAwIG4gCjAwMDAwNTY3 ODQgMDAwMDAgbiAKMDAwMDA1NjIwOCAwMDAwMCBuIAowMDAwMDU2NzY0IDAwMDAwIG4gCjAwMDAw NTY5MjUgMDAwMDAgbiAKMDAwMDA1NzAyMyAwMDAwMCBuIAowMDAwMDU5ODU3IDAwMDAwIG4gCjAw MDAwNjI1NjYgMDAwMDAgbiAKMDAwMDA1OTg3OCAwMDAwMCBuIAowMDAwMDYyNTQ1IDAwMDAwIG4g CjAwMDAwNjI3MDcgMDAwMDAgbiAKMDAwMDA2MjgwNSAwMDAwMCBuIAowMDAwMDY1NjM5IDAwMDAw IG4gCjAwMDAwNjkzNDEgMDAwMDAgbiAKMDAwMDA2NTY2MCAwMDAwMCBuIAowMDAwMDY5MzIwIDAw MDAwIG4gCjAwMDAwNjk0ODIgMDAwMDAgbiAKMDAwMDA2OTU4MCAwMDAwMCBuIAowMDAwMDcyNDIw IDAwMDAwIG4gCjAwMDAwNzQ5NDkgMDAwMDAgbiAKMDAwMDA5MTc0MCAwMDAwMCBuIAowMDAwMDcy NDQxIDAwMDAwIG4gCjAwMDAwNzQ5MjggMDAwMDAgbiAKMDAwMDA3NTA5MSAwMDAwMCBuIAowMDAw MDc1MTg5IDAwMDAwIG4gCjAwMDAwNzgwMjMgMDAwMDAgbiAKMDAwMDA3OTc0NyAwMDAwMCBuIAow MDAwMDc4MDQ0IDAwMDAwIG4gCjAwMDAwNzk3MjYgMDAwMDAgbiAKMDAwMDA3OTg4OSAwMDAwMCBu IAowMDAwMDc5OTg3IDAwMDAwIG4gCjAwMDAwODI4MjEgMDAwMDAgbiAKMDAwMDA4NTI3MSAwMDAw MCBuIAowMDAwMDgyODQyIDAwMDAwIG4gCjAwMDAwODUyNTAgMDAwMDAgbiAKMDAwMDA4NTQxMyAw MDAwMCBuIAowMDAwMTQwNjM0IDAwMDAwIG4gCjAwMDAxMjAyMjYgMDAwMDAgbiAKMDAwMDAwMDAw MCAwMDAwMCBuIAowMDAwMTM5MzM2IDAwMDAwIG4gCjAwMDAwODU1MzYgMDAwMDAgbiAKMDAwMDA5 MTU5NiAwMDAwMCBuIAowMDAwMDkxODMwIDAwMDAwIG4gCjAwMDAwOTE5MjIgMDAwMDAgbiAKMDAw MDA5MjUxMSAwMDAwMCBuIAowMDAwMDkyNzM5IDAwMDAwIG4gCjAwMDAxMjAyMDQgMDAwMDAgbiAK MDAwMDEyMDY3NyAwMDAwMCBuIAowMDAwMTIwOTA1IDAwMDAwIG4gCjAwMDAxMzkzMTQgMDAwMDAg biAKMDAwMDEzOTgxOSAwMDAwMCBuIAowMDAwMTM5NDk5IDAwMDAwIG4gCjAwMDAxMzk3OTkgMDAw MDAgbiAKMDAwMDE0MDA0MSAwMDAwMCBuIAowMDAwMTQwNjE0IDAwMDAwIG4gCjAwMDAxNDEwNDgg MDAwMDAgbiAKMDAwMDE0MTMwMCAwMDAwMCBuIAowMDAwMTU2MTA0IDAwMDAwIG4gCjAwMDAxNTY0 NTEgMDAwMDAgbiAKMDAwMDE1NjY5OCAwMDAwMCBuIAowMDAwMTY0NTg4IDAwMDAwIG4gCjAwMDAx NjQ5ODAgMDAwMDAgbiAKMDAwMDE2NTIzMiAwMDAwMCBuIAowMDAwMTczMTkxIDAwMDAwIG4gCjAw MDAxNzMyMTMgMDAwMDAgbiAKMDAwMDE3MzI1MCAwMDAwMCBuIAowMDAwMTczMzA0IDAwMDAwIG4g CjAwMDAxNzMzMjggMDAwMDAgbiAKdHJhaWxlcgo8PCAvU2l6ZSAxMTMgL1Jvb3QgODggMCBSIC9J bmZvIDEgMCBSIC9JRCBbIDw3Y2NhMDM4NzE3ZjdiODUwMGIzZGFjYzg3YzVkOTEzZT4KPDdjY2Ew Mzg3MTdmN2I4NTAwYjNkYWNjODdjNWQ5MTNlPiBdID4+CnN0YXJ0eHJlZgoxNzM0ODEKJSVFT0YK --Apple-Mail=_6F6C9D5D-E354-4EB4-A767-DF1ADDA4C0E2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" > On 5 Nov. 2016, at 1:20 am, Jakob Heitz (jheitz) = wrote: >=20 > Geoff, >=20 > Here is my proposed revision. I made all the changes, except the = ATOMIC_AGGREGATE. If after the latest discussion, you still want it, = I'll make that change too. >=20 > Thanks, > Jakob. >=20 >=20 > Begin forwarded message: >=20 >>> -----Original Message----- >>> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Geoff Huston >>> Sent: Thursday, November 03, 2016 5:14 PM >>> To: IETF IDR WG >>> Cc: rtg-dir@ietf.org; Susan Hares >>> Subject: [Idr] Review of draft-ietf-large-community-06.txt >>>=20 >>> I have reviewed this draft and have the following 9 suggestions. All = of >>> these fall into the category of minor suggestions. I do not believe = that >>> there is may major structural deficiency in this specification, and = the >>> document is largely ready, in my view. >>>=20 >>> Here are my specific suggestions. >>>=20 >>>=20 >>> 1. ---------------- >>>=20 >>> Title: Large BGP Communities >>>=20 >>> to be consistent with previous attribute specifications, how about >>>=20 >>> "BGP Large Communities Attribute" >>>=20 >>> i.e. switch the order of "Large BGP" to "BGP Large" to be consistent = with >>> earlier BGP Extended Communities specification in RFC4360 >>>=20 >>> 2. ---------------- >>>=20 >>> "Network operators >>> attach BGP communities to routes to identify intrinsic properties of >>> these routes." >>>=20 >>> I don't think community attributes are an intrinsic property of a = route >>> advertisement - they are more appropriately expressed as an attached = attribute >>> that expresses some desired property. >>>=20 >>> how about: >>>=20 >>> "Network operators attach BGP communities to routes to associate >>> particular properties with these routes." >>>=20 >>> 3. ---------------- >>>=20 >>> "and may apply to an individual route or to a group of routes." >>>=20 >>> I am confused - surely the attributes in an Update BGP message apply = to the >>> collection of routes contained in the Update. It cannot be applied = to a >>> single route when the update itself contains multiple routes. Why = not >>> use the text: >>>=20 >>> "and is applied to all routes contained in a BGP Update Message = where >>> the Communities Attribute is included." >>>=20 >>> 4. ---------------- >>>=20 >>> "[RFC1997] BGP Communities attributes are four-octet values split = into >>> two two-octet words." >>>=20 >>> This is not the case - RFC1997 says: "Communities are treated as 32 = bit values" >>> I think it would be more accurate to say: >>>=20 >>> "BGP Communities attributes are four-octet values [RFC1997]. Common = use of >>> this attribute type splits this single 32-bit value field into two = 16-bit values." >>>=20 >>> 5. ---------------- >>>=20 >>> "The BGP Extended Communities >>> attribute [RFC4360] is also unsuitable, as the protocol limit of six >>> octets cannot accommodate both a four-octet Global Administrator >>> value and a four-octet Local Administrator value, which precludes = the >>> common operational practice of encoding a target ASN in the Local >>> Administrator field." >>>=20 >>>=20 >>> Thats a very long sentence. Try: >>>=20 >>> "The BGP Extended Communities attribute [RFC4360] is also = unsuitable, as >>> the protocol limit of six octets for each community value cannot >>> accommodate both a four-octet Global Administrator value and a = four-octet >>> Local Administrator value. This limitation precludes the common >>> operational practice of encoding a target ASN in the Local = Administrator >>> field." >>>=20 >>> 6. ---------------- >>>=20 >>> The aggregation section contains fewer constraints then either = RFC1997 or >>> RFC4360. It also contains a confusing non-normative =E2=80=9Cshould". >>>=20 >>> For reference, RFC4360 states: By default if a range of routes is to = be >>> aggregated and the resultant aggregates path attributes do not carry = the >>> ATOMIC_AGGREGATE attribute, then the resulting aggregate should have = an >>> Extended Communities path attribute that contains the set union of = all the >>> Extended Communities from all of the aggregated routes. The default >>> behavior could be overridden via local configuration, in which case >>> handling the Extended Communities attribute in the presence of route >>> aggregation becomes a matter of the local policy of the BGP speaker = that >>> performs the aggregation. >>>=20 >>> Why not use this formulation? i.e. >>>=20 >>> "3. Aggregation >>>=20 >>> If a set of routes is to be aggregated and the resulting aggregate = route's >>> path attributes do not include the ATOMIC_AGGREGATE attribute, then = the >>> resulting aggregate route SHOULD have a Large Communities Attribute = formed >>> from the set union of all the Large Community values from all of the >>> aggregated set of routes. This behavior MAY be overridden via local >>> configuration, in which case handling the Large Communities = attribute in >>> the presence of route aggregation is determined by the local policy = of the >>> BGP speaker that performs the aggregation." >>>=20 >>> 7. ---------------- >>>=20 >>> 4. Canonical Representation >>>=20 >>> I am confused here - this section used an example with TWO canonical >>> representations: >>>=20 >>> "For example: 64496:4294967295:2, 64496:0:0, or (64496, 111, 222)." >>>=20 >>>=20 >>> Conventionally, it's better to use a single canonical = representation, so the >>> authors should pick either a colon-delimited list, or a bracketed = comma+space >>> separated object. >>>=20 >>>=20 >>> 8. ---------------- >>>=20 >>> 5. Reserved Large BGP Community values >>>=20 >>>=20 >>> The text reads: >>>=20 >>> "the Global Administrator values specified above could be >>> used if there is a future need for them." >>>=20 >>> This is entirely unclear. Is it referring to the values that the = previous >>> paragraph specified as "SHOULD NOT use=E2=80=9D? Also "could be = used" is a poor >>> choice of words for a normative specification. >>>=20 >>> I suggest deleting completely the paragraph that contains this quote = from >>> the document. >>>=20 >>>=20 >>> 9. ---------------- >>>=20 >>> The text reads: >>>=20 >>> "The error handling of Large BGP Communities is as follows: >>>=20 >>> o A Large BGP Communities attribute SHALL be considered malformed = if >>> its length is not a non-zero multiple of 12." >>>=20 >>>=20 >>> I think the author is trying to dayL >>>=20 >>> "The error handling of Large BGP Communities is as follows: >>>=20 >>> o A Large Communities attribute SHALL be considered malformed if = the >>> length of the Large Communities value, expressed in octets, is = not a >>> non-zero multiple of 12." >>>=20 >>>=20 >>> thanks, >>>=20 >>> Geoff >>>=20 >>> _______________________________________________ >>> Idr mailing list >>> Idr@ietf.org >>> https://www.ietf.org/mailman/listinfo/idr > = --Apple-Mail=_6F6C9D5D-E354-4EB4-A767-DF1ADDA4C0E2-- From nobody Fri Nov 4 12:43:38 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 827E2129607 for ; Fri, 4 Nov 2016 12:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.398 X-Spam-Level: X-Spam-Status: No, score=-108.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 qZ-x8TbIlaCM for ; Fri, 4 Nov 2016 12:43:35 -0700 (PDT) Received: from ao-mailgw.apnic.net (ao-mailgw.apnic.net [IPv6:2001:dd8:8:701::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DBD5129452 for ; Fri, 4 Nov 2016 12:43:34 -0700 (PDT) Received: from iamda3.org.apnic.net (unknown [2001:dd8:9:2::101:249]) by ao-mailgw.apnic.net (Halon) with ESMTPS id f59b4bb6-a2c6-11e6-b8ce-005056b6ee6f; Sat, 05 Nov 2016 05:43:29 +1000 (AEST) Received: from dhcp150.potaroo.net (203.119.101.249) by iamda3.org.apnic.net (203.119.111.31) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sat, 5 Nov 2016 05:43:28 +1000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Geoff Huston In-Reply-To: <20161104181259.GH961@Vurt.local> Date: Sat, 5 Nov 2016 06:43:30 +1100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com> <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com> <288c77155de540adbdb60d8587b9f39b@XCH-ALN-014.cisco.com> <20161104171834.GE961@Vurt.local> <20161104181259.GH961@Vurt.local> To: Job Snijders X-Mailer: Apple Mail (2.3251) Archived-At: Cc: IETF IDR WG , Susan Hares , "rtg-dir@ietf.org" Subject: Re: [Idr] Review of draft-ietf-large-community-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: Fri, 04 Nov 2016 19:43:36 -0000 > On 5 Nov. 2016, at 5:12 am, Job Snijders wrote: >=20 > If we consider this as Option B: >=20 > On Fri, Nov 04, 2016 at 06:18:34PM +0100, Job Snijders wrote: >> Does removing the word "canonical" address the raised remark? >>=20 >> """ >> 4. Representation >>=20 >> Large BGP Communities MUST be represented as three separate = unsigned >> integers in decimal notation in the following order: Global >> Administrator, Local Data 1, Local Data 2. Numbers MUST NOT = contain >> leading zeros; a zero value MUST be represented with a single zero. >> For example: 64496:4294967295:2, 64496:0:0, or (64496, 111, 222). >> """ >=20 > Option C: >=20 > 4. Canonical Representation >=20 > Large BGP Communities SHOULD be represented as three separate > unsigned integers in decimal notation, separated by a colon, in the > following order: Global Administrator, Local Data 1, Local Data 2. > Numbers MUST NOT contain leading zeros; a zero value MUST be > represented with a single zero. For example: 64496:4294967295:2 > or 64496:0:0. >=20 >=20 > Option D: >=20 > remove the section and let the market figure it out. >=20 > Some might argue "this is a minute detail" - however I do think that = the > proliferation of ways to notate extended communities have not really > helped the extended communities effort. this is a good chance and a = good > place to shortcut some of that proces and provide guidance. >=20 > Option C is basically as watered down as possible. Settle on that and > move on? >=20 I say =E2=80=9CYES=E2=80=9D - thanks Job Geoff From nobody Fri Nov 4 12:53:57 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6443A1295E5 for ; Fri, 4 Nov 2016 12:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.432 X-Spam-Level: X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_SOFTFAIL=0.665] 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 0W16Ok4YTGIH for ; Fri, 4 Nov 2016 12:53:53 -0700 (PDT) Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (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 684AE129579 for ; Fri, 4 Nov 2016 12:53:53 -0700 (PDT) Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1c2kYf-0000vG-8i (job@us.ntt.net); Fri, 04 Nov 2016 19:53:52 +0000 Date: Fri, 4 Nov 2016 20:53:46 +0100 From: Job Snijders To: Geoff Huston Message-ID: <20161104195346.GK961@Vurt.local> References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com> <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com> <6c5d83aa1d6a4a04b651b8f14f4b445b@XCH-ALN-014.cisco.com> <40D942F5-0710-46D1-BF09-76C827377479@cisco.com> <95F42982-7DCF-46A9-A26C-71EF70DB3C59@apnic.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <95F42982-7DCF-46A9-A26C-71EF70DB3C59@apnic.net> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.1 (2016-10-04) Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] Review of draft-ietf-large-community-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: Fri, 04 Nov 2016 19:53:55 -0000 Hi Geoff, Jakob, I'll incorporate the proposed changes into our XML and email out an rfcdiff for easier viewing. At first glance these look like good suggestions! Kind regards, Job ps. This may be the first time I receive a patch for a file packaged as PDF written with word.exe - what ever happened to good ole' 'ed' and 'diff' ;-) On Sat, Nov 05, 2016 at 06:41:32AM +1100, Geoff Huston wrote: > Jakob, > > Many thanks for sending this. > > I have used Word to mark up my reactions to this proposed revisions > for your further review as this tool has a good track changes option - > the PDF of the marked up text is attached to this note. > > My suggested changes to your proposed test are: > > 1) change to the Introduction to alter the description of Communities > to conform more exactly to the language used in RFC 1997 > > 2) change to the considerations of RFC4360 in the Introduction. (I > also note that RFC4360 calls the Global Administrator and Local > Administrator parts of the community value “sub-fileds†rather than > “fieldsâ€, while this draft calls these elements just “fields†) > > 3) the set of values is explicitly called out to be “unordered†in the > Introduction > > 4) The description of the attribute fields is altered to be consistent > with RFC4360 > > 5) the treatment of the Global Administrator value is unclear. I have > proposed removing the last two sentences and propose changing the MUST > to a SHOULD, as, later in the draft in Section 6, it is noted that the > Global Administrator field can be any value! > > 6) I have explicitly called out that the values are in any order, and > allowed for two or more individual Large Communities attributes to be > contained in a single BGP Update message, again in any order. If this > is not your intent then you should look at this part of section 2 and > tighten up the wording. > > 7) you have not explicitly disambiguated between duplicate instances > of the same attribute and duplicate instances of the same Community > value. I have offerred some text to clarify this to the level of > values. > > 8) I have proposed changing the MUST to a SHOULD in rthe canonical > representation section > > 9) The sentences about the use of a colon make no sense given that you > have not specified a colon separator in the preceeding paragraph. You > probably need to either drop the reference to the colon, or add a > colon as part of the Canonical Representation. I have proposed the > former. > > 10) - in section 6 I changed the “may†to a “MAY†- seemed like the > right thing to do. > > 11) I added a paragraph in the Security Considerations section > explicitly that the values in this attribute are not specifically > protected and then pointed to BGP security (just because an ASN is > used in a community attribute, that does not mean that the ASN in > question attached that attribute, or that the ASN will honour that > attribute. - its just a signal without any integrity protection) > > 12) I have added my name as a reviewer - hope that’s ok! :-) > > I _assume_ that the atomic aggregator mess will be fixed up by the > action of making this an historic attribute, so I have left the text > on aggregation unaltered. > > Regards, > > Geoff > > > > > On 5 Nov. 2016, at 1:20 am, Jakob Heitz (jheitz) wrote: > > > > Geoff, > > > > Here is my proposed revision. I made all the changes, except the ATOMIC_AGGREGATE. If after the latest discussion, you still want it, I'll make that change too. > > > > Thanks, > > Jakob. > > > > > > Begin forwarded message: > > > >>> -----Original Message----- > >>> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Geoff Huston > >>> Sent: Thursday, November 03, 2016 5:14 PM > >>> To: IETF IDR WG > >>> Cc: rtg-dir@ietf.org; Susan Hares > >>> Subject: [Idr] Review of draft-ietf-large-community-06.txt > >>> > >>> I have reviewed this draft and have the following 9 suggestions. All of > >>> these fall into the category of minor suggestions. I do not believe that > >>> there is may major structural deficiency in this specification, and the > >>> document is largely ready, in my view. > >>> > >>> Here are my specific suggestions. > >>> > >>> > >>> 1. ---------------- > >>> > >>> Title: Large BGP Communities > >>> > >>> to be consistent with previous attribute specifications, how about > >>> > >>> "BGP Large Communities Attribute" > >>> > >>> i.e. switch the order of "Large BGP" to "BGP Large" to be consistent with > >>> earlier BGP Extended Communities specification in RFC4360 > >>> > >>> 2. ---------------- > >>> > >>> "Network operators > >>> attach BGP communities to routes to identify intrinsic properties of > >>> these routes." > >>> > >>> I don't think community attributes are an intrinsic property of a route > >>> advertisement - they are more appropriately expressed as an attached attribute > >>> that expresses some desired property. > >>> > >>> how about: > >>> > >>> "Network operators attach BGP communities to routes to associate > >>> particular properties with these routes." > >>> > >>> 3. ---------------- > >>> > >>> "and may apply to an individual route or to a group of routes." > >>> > >>> I am confused - surely the attributes in an Update BGP message apply to the > >>> collection of routes contained in the Update. It cannot be applied to a > >>> single route when the update itself contains multiple routes. Why not > >>> use the text: > >>> > >>> "and is applied to all routes contained in a BGP Update Message where > >>> the Communities Attribute is included." > >>> > >>> 4. ---------------- > >>> > >>> "[RFC1997] BGP Communities attributes are four-octet values split into > >>> two two-octet words." > >>> > >>> This is not the case - RFC1997 says: "Communities are treated as 32 bit values" > >>> I think it would be more accurate to say: > >>> > >>> "BGP Communities attributes are four-octet values [RFC1997]. Common use of > >>> this attribute type splits this single 32-bit value field into two 16-bit values." > >>> > >>> 5. ---------------- > >>> > >>> "The BGP Extended Communities > >>> attribute [RFC4360] is also unsuitable, as the protocol limit of six > >>> octets cannot accommodate both a four-octet Global Administrator > >>> value and a four-octet Local Administrator value, which precludes the > >>> common operational practice of encoding a target ASN in the Local > >>> Administrator field." > >>> > >>> > >>> Thats a very long sentence. Try: > >>> > >>> "The BGP Extended Communities attribute [RFC4360] is also unsuitable, as > >>> the protocol limit of six octets for each community value cannot > >>> accommodate both a four-octet Global Administrator value and a four-octet > >>> Local Administrator value. This limitation precludes the common > >>> operational practice of encoding a target ASN in the Local Administrator > >>> field." > >>> > >>> 6. ---------------- > >>> > >>> The aggregation section contains fewer constraints then either RFC1997 or > >>> RFC4360. It also contains a confusing non-normative “should". > >>> > >>> For reference, RFC4360 states: By default if a range of routes is to be > >>> aggregated and the resultant aggregates path attributes do not carry the > >>> ATOMIC_AGGREGATE attribute, then the resulting aggregate should have an > >>> Extended Communities path attribute that contains the set union of all the > >>> Extended Communities from all of the aggregated routes. The default > >>> behavior could be overridden via local configuration, in which case > >>> handling the Extended Communities attribute in the presence of route > >>> aggregation becomes a matter of the local policy of the BGP speaker that > >>> performs the aggregation. > >>> > >>> Why not use this formulation? i.e. > >>> > >>> "3. Aggregation > >>> > >>> If a set of routes is to be aggregated and the resulting aggregate route's > >>> path attributes do not include the ATOMIC_AGGREGATE attribute, then the > >>> resulting aggregate route SHOULD have a Large Communities Attribute formed > >>> from the set union of all the Large Community values from all of the > >>> aggregated set of routes. This behavior MAY be overridden via local > >>> configuration, in which case handling the Large Communities attribute in > >>> the presence of route aggregation is determined by the local policy of the > >>> BGP speaker that performs the aggregation." > >>> > >>> 7. ---------------- > >>> > >>> 4. Canonical Representation > >>> > >>> I am confused here - this section used an example with TWO canonical > >>> representations: > >>> > >>> "For example: 64496:4294967295:2, 64496:0:0, or (64496, 111, 222)." > >>> > >>> > >>> Conventionally, it's better to use a single canonical representation, so the > >>> authors should pick either a colon-delimited list, or a bracketed comma+space > >>> separated object. > >>> > >>> > >>> 8. ---------------- > >>> > >>> 5. Reserved Large BGP Community values > >>> > >>> > >>> The text reads: > >>> > >>> "the Global Administrator values specified above could be > >>> used if there is a future need for them." > >>> > >>> This is entirely unclear. Is it referring to the values that the previous > >>> paragraph specified as "SHOULD NOT useâ€? Also "could be used" is a poor > >>> choice of words for a normative specification. > >>> > >>> I suggest deleting completely the paragraph that contains this quote from > >>> the document. > >>> > >>> > >>> 9. ---------------- > >>> > >>> The text reads: > >>> > >>> "The error handling of Large BGP Communities is as follows: > >>> > >>> o A Large BGP Communities attribute SHALL be considered malformed if > >>> its length is not a non-zero multiple of 12." > >>> > >>> > >>> I think the author is trying to dayL > >>> > >>> "The error handling of Large BGP Communities is as follows: > >>> > >>> o A Large Communities attribute SHALL be considered malformed if the > >>> length of the Large Communities value, expressed in octets, is not a > >>> non-zero multiple of 12." > >>> > >>> > >>> thanks, > >>> > >>> Geoff > >>> > >>> _______________________________________________ > >>> Idr mailing list > >>> Idr@ietf.org > >>> https://www.ietf.org/mailman/listinfo/idr > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Fri Nov 4 13:16:58 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE6C1295DA for ; Fri, 4 Nov 2016 13:16:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.421 X-Spam-Level: X-Spam-Status: No, score=-3.421 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_SOFTFAIL=0.665, T_HTML_ATTACH=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 E2SOym9o1zeU for ; Fri, 4 Nov 2016 13:16:49 -0700 (PDT) Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (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 127A112958D for ; Fri, 4 Nov 2016 13:16:49 -0700 (PDT) Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1c2kuh-0003YV-UY (job@us.ntt.net); Fri, 04 Nov 2016 20:16:48 +0000 Date: Fri, 4 Nov 2016 21:16:31 +0100 From: Job Snijders To: Geoff Huston Message-ID: <20161104201631.GA35942@Vurt.lan> References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com> <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com> <6c5d83aa1d6a4a04b651b8f14f4b445b@XCH-ALN-014.cisco.com> <40D942F5-0710-46D1-BF09-76C827377479@cisco.com> <95F42982-7DCF-46A9-A26C-71EF70DB3C59@apnic.net> <20161104195346.GK961@Vurt.local> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="J/dobhs11T7y2rNN" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20161104195346.GK961@Vurt.local> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.1 (2016-10-04) Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] Review of draft-ietf-large-community-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: Fri, 04 Nov 2016 20:16:56 -0000 --J/dobhs11T7y2rNN Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit Hi everyone, Attached is the rfcdiff html file that represents the current -06 -> -07 changes with the work from Jakob and Geoff and some nits that were picked by John Scudder. I should note the following, in "Reserved BGP Large Community values" the 'reasons' behind each reserved value were removed. Some in the working group made a case that it could be good to provide a justification what makes these numbers special. Other then that, i feel that these changes have improved the document's flow and readability. Kind regards, Job On Fri, Nov 04, 2016 at 08:53:46PM +0100, Job Snijders wrote: > On Sat, Nov 05, 2016 at 06:41:32AM +1100, Geoff Huston wrote: > > Jakob, > > > > Many thanks for sending this. > > > > I have used Word to mark up my reactions to this proposed revisions > > for your further review as this tool has a good track changes option - > > the PDF of the marked up text is attached to this note. > > > > My suggested changes to your proposed test are: > > > > 1) change to the Introduction to alter the description of Communities > > to conform more exactly to the language used in RFC 1997 > > > > 2) change to the considerations of RFC4360 in the Introduction. (I > > also note that RFC4360 calls the Global Administrator and Local > > Administrator parts of the community value “sub-fileds†rather than > > “fieldsâ€, while this draft calls these elements just “fields†) > > > > 3) the set of values is explicitly called out to be “unordered†in the > > Introduction > > > > 4) The description of the attribute fields is altered to be consistent > > with RFC4360 > > > > 5) the treatment of the Global Administrator value is unclear. I have > > proposed removing the last two sentences and propose changing the MUST > > to a SHOULD, as, later in the draft in Section 6, it is noted that the > > Global Administrator field can be any value! > > > > 6) I have explicitly called out that the values are in any order, and > > allowed for two or more individual Large Communities attributes to be > > contained in a single BGP Update message, again in any order. If this > > is not your intent then you should look at this part of section 2 and > > tighten up the wording. > > > > 7) you have not explicitly disambiguated between duplicate instances > > of the same attribute and duplicate instances of the same Community > > value. I have offerred some text to clarify this to the level of > > values. > > > > 8) I have proposed changing the MUST to a SHOULD in rthe canonical > > representation section > > > > 9) The sentences about the use of a colon make no sense given that you > > have not specified a colon separator in the preceeding paragraph. You > > probably need to either drop the reference to the colon, or add a > > colon as part of the Canonical Representation. I have proposed the > > former. > > > > 10) - in section 6 I changed the “may†to a “MAY†- seemed like the > > right thing to do. > > > > 11) I added a paragraph in the Security Considerations section > > explicitly that the values in this attribute are not specifically > > protected and then pointed to BGP security (just because an ASN is > > used in a community attribute, that does not mean that the ASN in > > question attached that attribute, or that the ASN will honour that > > attribute. - its just a signal without any integrity protection) > > > > 12) I have added my name as a reviewer - hope that’s ok! :-) > > > > I _assume_ that the atomic aggregator mess will be fixed up by the > > action of making this an historic attribute, so I have left the text > > on aggregation unaltered. > > > > Regards, > > > > Geoff > > > > > > > > > On 5 Nov. 2016, at 1:20 am, Jakob Heitz (jheitz) wrote: > > > > > > Geoff, > > > > > > Here is my proposed revision. I made all the changes, except the ATOMIC_AGGREGATE. If after the latest discussion, you still want it, I'll make that change too. > > > > > > Thanks, > > > Jakob. > > > > > > > > > Begin forwarded message: > > > > > >>> -----Original Message----- > > >>> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Geoff Huston > > >>> Sent: Thursday, November 03, 2016 5:14 PM > > >>> To: IETF IDR WG > > >>> Cc: rtg-dir@ietf.org; Susan Hares > > >>> Subject: [Idr] Review of draft-ietf-large-community-06.txt > > >>> > > >>> I have reviewed this draft and have the following 9 suggestions. All of > > >>> these fall into the category of minor suggestions. I do not believe that > > >>> there is may major structural deficiency in this specification, and the > > >>> document is largely ready, in my view. > > >>> > > >>> Here are my specific suggestions. > > >>> > > >>> > > >>> 1. ---------------- > > >>> > > >>> Title: Large BGP Communities > > >>> > > >>> to be consistent with previous attribute specifications, how about > > >>> > > >>> "BGP Large Communities Attribute" > > >>> > > >>> i.e. switch the order of "Large BGP" to "BGP Large" to be consistent with > > >>> earlier BGP Extended Communities specification in RFC4360 > > >>> > > >>> 2. ---------------- > > >>> > > >>> "Network operators > > >>> attach BGP communities to routes to identify intrinsic properties of > > >>> these routes." > > >>> > > >>> I don't think community attributes are an intrinsic property of a route > > >>> advertisement - they are more appropriately expressed as an attached attribute > > >>> that expresses some desired property. > > >>> > > >>> how about: > > >>> > > >>> "Network operators attach BGP communities to routes to associate > > >>> particular properties with these routes." > > >>> > > >>> 3. ---------------- > > >>> > > >>> "and may apply to an individual route or to a group of routes." > > >>> > > >>> I am confused - surely the attributes in an Update BGP message apply to the > > >>> collection of routes contained in the Update. It cannot be applied to a > > >>> single route when the update itself contains multiple routes. Why not > > >>> use the text: > > >>> > > >>> "and is applied to all routes contained in a BGP Update Message where > > >>> the Communities Attribute is included." > > >>> > > >>> 4. ---------------- > > >>> > > >>> "[RFC1997] BGP Communities attributes are four-octet values split into > > >>> two two-octet words." > > >>> > > >>> This is not the case - RFC1997 says: "Communities are treated as 32 bit values" > > >>> I think it would be more accurate to say: > > >>> > > >>> "BGP Communities attributes are four-octet values [RFC1997]. Common use of > > >>> this attribute type splits this single 32-bit value field into two 16-bit values." > > >>> > > >>> 5. ---------------- > > >>> > > >>> "The BGP Extended Communities > > >>> attribute [RFC4360] is also unsuitable, as the protocol limit of six > > >>> octets cannot accommodate both a four-octet Global Administrator > > >>> value and a four-octet Local Administrator value, which precludes the > > >>> common operational practice of encoding a target ASN in the Local > > >>> Administrator field." > > >>> > > >>> > > >>> Thats a very long sentence. Try: > > >>> > > >>> "The BGP Extended Communities attribute [RFC4360] is also unsuitable, as > > >>> the protocol limit of six octets for each community value cannot > > >>> accommodate both a four-octet Global Administrator value and a four-octet > > >>> Local Administrator value. This limitation precludes the common > > >>> operational practice of encoding a target ASN in the Local Administrator > > >>> field." > > >>> > > >>> 6. ---------------- > > >>> > > >>> The aggregation section contains fewer constraints then either RFC1997 or > > >>> RFC4360. It also contains a confusing non-normative “should". > > >>> > > >>> For reference, RFC4360 states: By default if a range of routes is to be > > >>> aggregated and the resultant aggregates path attributes do not carry the > > >>> ATOMIC_AGGREGATE attribute, then the resulting aggregate should have an > > >>> Extended Communities path attribute that contains the set union of all the > > >>> Extended Communities from all of the aggregated routes. The default > > >>> behavior could be overridden via local configuration, in which case > > >>> handling the Extended Communities attribute in the presence of route > > >>> aggregation becomes a matter of the local policy of the BGP speaker that > > >>> performs the aggregation. > > >>> > > >>> Why not use this formulation? i.e. > > >>> > > >>> "3. Aggregation > > >>> > > >>> If a set of routes is to be aggregated and the resulting aggregate route's > > >>> path attributes do not include the ATOMIC_AGGREGATE attribute, then the > > >>> resulting aggregate route SHOULD have a Large Communities Attribute formed > > >>> from the set union of all the Large Community values from all of the > > >>> aggregated set of routes. This behavior MAY be overridden via local > > >>> configuration, in which case handling the Large Communities attribute in > > >>> the presence of route aggregation is determined by the local policy of the > > >>> BGP speaker that performs the aggregation." > > >>> > > >>> 7. ---------------- > > >>> > > >>> 4. Canonical Representation > > >>> > > >>> I am confused here - this section used an example with TWO canonical > > >>> representations: > > >>> > > >>> "For example: 64496:4294967295:2, 64496:0:0, or (64496, 111, 222)." > > >>> > > >>> > > >>> Conventionally, it's better to use a single canonical representation, so the > > >>> authors should pick either a colon-delimited list, or a bracketed comma+space > > >>> separated object. > > >>> > > >>> > > >>> 8. ---------------- > > >>> > > >>> 5. Reserved Large BGP Community values > > >>> > > >>> > > >>> The text reads: > > >>> > > >>> "the Global Administrator values specified above could be > > >>> used if there is a future need for them." > > >>> > > >>> This is entirely unclear. Is it referring to the values that the previous > > >>> paragraph specified as "SHOULD NOT useâ€? Also "could be used" is a poor > > >>> choice of words for a normative specification. > > >>> > > >>> I suggest deleting completely the paragraph that contains this quote from > > >>> the document. > > >>> > > >>> > > >>> 9. ---------------- > > >>> > > >>> The text reads: > > >>> > > >>> "The error handling of Large BGP Communities is as follows: > > >>> > > >>> o A Large BGP Communities attribute SHALL be considered malformed if > > >>> its length is not a non-zero multiple of 12." > > >>> > > >>> > > >>> I think the author is trying to dayL > > >>> > > >>> "The error handling of Large BGP Communities is as follows: > > >>> > > >>> o A Large Communities attribute SHALL be considered malformed if the > > >>> length of the Large Communities value, expressed in octets, is not a > > >>> non-zero multiple of 12." > > >>> > > >>> > > >>> thanks, > > >>> > > >>> Geoff > > >>> > > >>> _______________________________________________ > > >>> 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 --J/dobhs11T7y2rNN Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="draft-ietf-idr-large-community-07.txt" IDR J. Heitz, Ed. Internet-Draft Cisco Intended status: Standards Track J. Snijders, Ed. Expires: May 8, 2017 NTT K. Patel Arrcus I. Bagdonas Equinix N. Hilliard INEX November 4, 2016 BGP Large Communities draft-ietf-idr-large-community-07 Abstract This document describes the BGP Large Communities attribute, an extension to BGP-4. This attribute provides a mechanism to signal opaque information within separate namespaces to aid in routing management. The attribute is suitable for use with four-octet Autonomous System Numbers. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 8, 2017. Heitz, et al. Expires May 8, 2017 [Page 1] Internet-Draft BGP Large Communities November 2016 Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. BGP Large Communities Attribute . . . . . . . . . . . . . . . 3 3. Aggregation . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Canonical Representation . . . . . . . . . . . . . . . . . . 4 5. Reserved BGP Large Community values . . . . . . . . . . . . . 4 6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 5 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 8. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 5 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 12.1. Normative References . . . . . . . . . . . . . . . . . . 7 12.2. Informative References . . . . . . . . . . . . . . . . . 7 12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction BGP implementations typically support a routing policy language to control the distribution of routing information. Network operators attach BGP communities to routes to associate particular properties with these routes. These properties may include information such as the route origin location, or specification of a routing policy action to be taken, or one that has been taken, and is applied to all routes contained in a BGP Update Message where the Communities Attribute is included. Because BGP communities are optional transitive BGP attributes, BGP communities may be acted upon or otherwise used by routing policies in other Autonomous Systems (ASes) on the Internet. Heitz, et al. Expires May 8, 2017 [Page 2] Internet-Draft BGP Large Communities November 2016 BGP Communities attributes are a variable length attribute consisting of a set of one or more four-octet values, each of which specify a community [RFC1997]. Common use of the individual values of this attribute type split this single 32-bit value into two 16-bit values. The most significant word is interpreted as an Autonomous System Number (ASN) and the least significant word is a locally defined value whose meaning is assigned by the operator of the Autonomous System in the most significant word. Since the adoption of four-octet ASNs [RFC6793], the BGP Communities attribute can no longer accommodate the above encoding, as a two- octet word cannot fit a four-octet ASN. The BGP Extended Communities attribute [RFC4360] is also unsuitable. The six-octet length of the Extended Community value precludes the common operational practise of encoding four-octet ASNs in both the Global Administrator and the Local Administrator sub-fields. To address these shortcomings, this document defines a BGP Large Communities attribute encoded as an unordered set of one or more twelve-octet values, each consisting of a four-octet Global Administrator field and two four-octet operator-defined fields, each of which can be used to denote properties or actions significant to the operator of the Autonomous System assigning the values. 2. BGP Large Communities Attribute This document creates the BGP Large Communities attribute as an optional transitive path attribute of variable length. All routes with the BGP Large Communities attribute belong to the communities specified in the attribute. Each BGP Large Community value is encoded as a 12-octet quantity, as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Global Administrator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Data Part 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Data Part 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Global Administrator: A four-octet namespace identifier. Local Data Part 1: A four-octet operator-defined value. Heitz, et al. Expires May 8, 2017 [Page 3] Internet-Draft BGP Large Communities November 2016 Local Data Part 2: A four-octet operator-defined value. The Global Administrator field is intended to allow different Autonomous Systems to define BGP Large Communities without collision. This field SHOULD be either one of the reserved values as defined below, or an Autonomous System Number (ASN). If it is a reserved value, then the Local Data Parts are as defined by the reserved value. If it is an ASN then the Local Data Parts are to be interpreted as defined by the owner of the ASN. There is no significance to the order in which twelve-octet Large Community values are encoded in a Large Communities attribute, nor in the order of the BGP Large Communities attributes if two or more such attributes are encoded in the BGP path attribute payload of a single BGP Update message. A BGP speaker can transmit them in any order. Duplicate BGP Large Community values SHOULD NOT be transmitted. A receiving speaker SHOULD silently remove duplicate BGP Large Community values from a BGP UPDATE message. 3. Aggregation If a range of routes is aggregated, then the resulting aggregate should have a BGP Large Communities attribute which contains all of the BGP Large Communities attributes from all of the aggregated routes. 4. Canonical Representation The canonical representation of BGP Large Communities is three separate unsigned integers in decimal notation in the following order: Global Administrator, Local Data 1, Local Data 2. Numbers MUST NOT contain leading zeros; a zero value MUST be represented with a single zero. Each number is separated from the next by a single colon. For example: 64496:4294967295:2, 64496:0:0. BGP Large Communities SHOULD be represented in the canonical representation. 5. Reserved BGP Large Community values The following Global Administrator values are reserved: 0, 65535, and 4294967295. Operators SHOULD NOT use these Global Administrator values. Although this document does not define any Special-Use BGP Large Communities, the Global Administrator values specified above could be used if there is a future need for them. Heitz, et al. Expires May 8, 2017 [Page 4] Internet-Draft BGP Large Communities November 2016 6. Error Handling The error handling of BGP Large Communities is as follows: o A BGP Large Communities attribute SHALL be considered malformed if the length of the BGP Large Communities value, expressed in octets, is not a non-zero multiple of 12. o A BGP UPDATE message with a malformed BGP Large Communities attribute SHALL be handled using the approach of "treat-as- withdraw" as described in section 2 [RFC7606]. The BGP Large Communities Global Administrator field MAY contain any value, and a BGP Large Communities attribute MUST NOT be considered malformed if the Global Administrator field contains an unallocated, unassigned or reserved ASN or is set to one of the reserved BGP Large Community values defined in Section 5. 7. Security Considerations This extension to BGP has similar security implications as BGP Communities [RFC1997]. This document does not change any underlying security issues associated with any other BGP Communities mechanism. Specifically, an AS relying on the BGP Large Communities attribute carried in BGP must have trust in every other AS in the path, as any intermediate Autonomous System in the path may have added, deleted, or altered the BGP Large Communities attribute. Specifying the mechanism to provide such trust is beyond the scope of this document. BGP Large Communities do not protect the integrity of each community value. Operators should be aware that it is possible for a BGP speaker to alter BGP Large Community values in a BGP Update Message. Protecting the integrity of the transitive handling of BGP Large Community attributes in a manner consistent with the intent of expressed BGP routing policies falls within the broader scope of securing BGP, and is not specifically addressed here. Network administrators should note the recommendations in Section 11 of BGP Operations and Security [RFC7454]. 8. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in [RFC7942]. The description of implementations in this section is intended to Heitz, et al. Expires May 8, 2017 [Page 5] Internet-Draft BGP Large Communities November 2016 assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist. As of today these vendors have produced an implementation of BGP Large Communities: o Cisco IOS XR o ExaBGP o GoBGP o BIRD o OpenBGPD o pmacct o Quagga The latest implementation news is tracked at http://largebgpcommunities.net/ [1]. 9. IANA Considerations IANA has made an Early Allocation of the value 32 (LARGE_COMMUNITY) in the "BGP Path Attributes" registry under the "Border Gateway Protocol (BGP) Parameters" group and is now asked to make that Permanent. 10. Contributors The following people contributed significantly to the content of the document: John Heasley NTT Communications Email: heas@shrubbery.net Adam Simpson Nokia Email: adam.1.simpson@nokia.com Heitz, et al. Expires May 8, 2017 [Page 6] Internet-Draft BGP Large Communities November 2016 11. Acknowledgments The authors would like to thank Ruediger Volk, Russ White, Acee Lindem, Shyam Sethuram, Jared Mauch, Joel M. Halpern, Jeffrey Haas, Gunter van de Velde, Marco Marzetti, Eduardo Ascenco Reis, Mark Schouten, Paul Hoogsteder, Martijn Schmidt, Greg Hankins, Bertrand Duvivier, Barry O'Donovan, Grzegorz Janoszka, Linda Dunbar, Marco Davids, Gaurab Raj Upadhaya, Jeff Tantsura, Teun Vink, Adam Davenport, Theodore Baschak, Pier Carlo Chiodi, Nabeel Cocker, Ian Dickinson, Jan Baggen, Duncan Lockwood, David Farmer, Randy Bush, Wim Henderickx, Stefan Plug, Kay Rechthien, Rob Shakir, Warren Kumari, Gert Doering, Thomas King, Mikael Abrahamsson, Wesley Steehouwer, Sander Steffann, Brad Dreisbach, Martin Millnert, Christopher Morrow, Jay Borkenhagen, Arnold Nipper, Joe Provo, Niels Bakker, Bill Fenner, Tom Daly, Ben Maddison, Alexander Azimov, Brian Dickson, Peter van Dijk, Julian Seifert, Tom Petch, Tom Scholl, Arjen Zonneveld, Remco van Mook, Adam Chappell, Jussi Peltola, Kristian Larsson, Markus Hauschild, Richard Steenbergen, David Freedman, Richard Hartmann and Geoff Huston for their support, insightful review and comments. 12. References 12.1. Normative References [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet Autonomous System (AS) Number Space", RFC 6793, DOI 10.17487/RFC6793, December 2012, . [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", RFC 7606, DOI 10.17487/RFC7606, August 2015, . 12.2. Informative References [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, February 2006, . Heitz, et al. Expires May 8, 2017 [Page 7] Internet-Draft BGP Large Communities November 2016 [RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454, February 2015, . [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, . 12.3. URIs [1] http://largebgpcommunities.net Authors' Addresses Jakob Heitz (editor) Cisco 170 West Tasman Drive San Jose, CA 95054 USA Email: jheitz@cisco.com Job Snijders (editor) NTT Communications Theodorus Majofskistraat 100 Amsterdam 1065 SZ The Netherlands Email: job@ntt.net Keyur Patel Arrcus, Inc Email: keyur@arrcus.com Ignas Bagdonas Equinix London UK Email: ibagdona.ietf@gmail.com Heitz, et al. Expires May 8, 2017 [Page 8] Internet-Draft BGP Large Communities November 2016 Nick Hilliard INEX 4027 Kingswood Road Dublin 24 IE Email: nick@inex.ie Heitz, et al. Expires May 8, 2017 [Page 9] --J/dobhs11T7y2rNN Content-Type: text/html; charset=us-ascii Content-Disposition: attachment; filename="draft-ietf-idr-large-community-07-from-6.diff.html" Diff: draft-ietf-idr-large-community-06.txt - draft-ietf-idr-large-community-07.txt
 draft-ietf-idr-large-community-06.txt   draft-ietf-idr-large-community-07.txt 
IDR J. Heitz, Ed. IDR J. Heitz, Ed.
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Standards Track J. Snijders, Ed. Intended status: Standards Track J. Snijders, Ed.
Expires: May 2, 2017 NTT Expires: May 8, 2017 NTT
K. Patel K. Patel
Arrcus Arrcus
I. Bagdonas I. Bagdonas
Equinix Equinix
A. Simpson
Nokia
N. Hilliard N. Hilliard
INEX INEX
October 29, 2016 November 4, 2016
Large BGP Communities BGP Large Communities
draft-ietf-idr-large-community-06 draft-ietf-idr-large-community-07
Abstract Abstract
This document describes the Large BGP Communities attribute, an This document describes the BGP Large Communities attribute, an
extension to BGP-4. This attribute provides a mechanism to signal extension to BGP-4. This attribute provides a mechanism to signal
opaque information within separate namespaces to aid in routing opaque information within separate namespaces to aid in routing
management. The attribute is suitable for use with four-octet ASNs. management. The attribute is suitable for use with four-octet
Autonomous System Numbers.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 48 skipping to change at page 1, line 47
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 2, 2017. This Internet-Draft will expire on May 8, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Large BGP Communities Attribute . . . . . . . . . . . . . . . 3 2. BGP Large Communities Attribute . . . . . . . . . . . . . . . 3
3. Aggregation . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Aggregation . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Canonical Representation . . . . . . . . . . . . . . . . . . 4 4. Canonical Representation . . . . . . . . . . . . . . . . . . 4
5. Reserved Large BGP Community values . . . . . . . . . . . . . 4 5. Reserved BGP Large Community values . . . . . . . . . . . . . 4
6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 4 6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5
8. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 5 8. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 5
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
12.1. Normative References . . . . . . . . . . . . . . . . . . 7 12.1. Normative References . . . . . . . . . . . . . . . . . . 7
12.2. Informative References . . . . . . . . . . . . . . . . . 7 12.2. Informative References . . . . . . . . . . . . . . . . . 7
12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 8 12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
BGP implementations typically support a routing policy language to BGP implementations typically support a routing policy language to
control the distribution of routing information. Network operators control the distribution of routing information. Network operators
attach BGP communities to routes to identify intrinsic properties of attach BGP communities to routes to associate particular properties
these routes. These properties may include information such as the with these routes. These properties may include information such as
route origin location, or specification of a routing policy action to the route origin location, or specification of a routing policy
be taken, or one that has been taken, and may apply to an individual action to be taken, or one that has been taken, and is applied to all
route or to a group of routes. Because BGP communities are optional routes contained in a BGP Update Message where the Communities
Attribute is included. Because BGP communities are optional
transitive BGP attributes, BGP communities may be acted upon or transitive BGP attributes, BGP communities may be acted upon or
otherwise used by routing policies in other Autonomous Systems (ASes) otherwise used by routing policies in other Autonomous Systems (ASes)
on the Internet. on the Internet.
[RFC1997] BGP Communities attributes are four-octet values split into BGP Communities attributes are a variable length attribute consisting
two two-octet words. The most significant word is interpreted as an of a set of one or more four-octet values, each of which specify a
Autonomous System Number (ASN) and the least significant word is a community [RFC1997]. Common use of the individual values of this
locally defined value whose meaning is assigned by the operator of attribute type split this single 32-bit value into two 16-bit values.
the Autonomous System in the most significant word. The most significant word is interpreted as an Autonomous System
Number (ASN) and the least significant word is a locally defined
value whose meaning is assigned by the operator of the Autonomous
System in the most significant word.
Since the adoption of four-octet ASNs [RFC6793], the BGP Communities Since the adoption of four-octet ASNs [RFC6793], the BGP Communities
attribute can no longer accommodate the above encoding, as a two- attribute can no longer accommodate the above encoding, as a two-
octet word cannot fit a four-octet ASN. The BGP Extended Communities octet word cannot fit a four-octet ASN. The BGP Extended Communities
attribute [RFC4360] is also unsuitable, as the protocol limit of six attribute [RFC4360] is also unsuitable. The six-octet length of the
octets cannot accommodate both a four-octet Global Administrator Extended Community value precludes the common operational practise of
value and a four-octet Local Administrator value, which precludes the encoding four-octet ASNs in both the Global Administrator and the
common operational practice of encoding a target ASN in the Local Local Administrator sub-fields.
Administrator field.
To address these shortcomings, this document defines a Large BGP To address these shortcomings, this document defines a BGP Large
Communities attribute encoded as one or more twelve-octet values, Communities attribute encoded as an unordered set of one or more
each consisting of a four-octet Global Administrator field and two twelve-octet values, each consisting of a four-octet Global
four-octet operator-defined fields, each of which can be used to Administrator field and two four-octet operator-defined fields, each
denote properties or actions significant to the operator of the of which can be used to denote properties or actions significant to
Autonomous System assigning the values. the operator of the Autonomous System assigning the values.
2. Large BGP Communities Attribute 2. BGP Large Communities Attribute
This document creates the Large BGP Communities attribute as an This document creates the BGP Large Communities attribute as an
optional transitive path attribute of variable length. All routes optional transitive path attribute of variable length. All routes
with the Large BGP Communities attribute belong to the community with the BGP Large Communities attribute belong to the communities
specified in the attribute. specified in the attribute.
The attribute consists of one or more twelve-octet values. Each Each BGP Large Community value is encoded as a 12-octet quantity, as
twelve-octet Large BGP Communities value represents three four-octet follows:
values, as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global Administrator | | Global Administrator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Data Part 1 | | Local Data Part 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Data Part 2 | | Local Data Part 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Global Administrator: A four-octet namespace identifier. This Global Administrator: A four-octet namespace identifier.
SHOULD be an Autonomous System Number.
Local Data Part 1: A four-octet operator-defined value. Local Data Part 1: A four-octet operator-defined value.
Local Data Part 2: A four-octet operator-defined value. Local Data Part 2: A four-octet operator-defined value.
The Global Administrator field is intended to allow different The Global Administrator field is intended to allow different
Autonomous Systems to define Large BGP Communities without collision. Autonomous Systems to define BGP Large Communities without collision.
Implementations MUST allow the operator to specify any value for the This field SHOULD be either one of the reserved values as defined
Global Administrator field. below, or an Autonomous System Number (ASN). If it is a reserved
value, then the Local Data Parts are as defined by the reserved
value. If it is an ASN then the Local Data Parts are to be
interpreted as defined by the owner of the ASN.
There is no significance to the order in which Large BGP Communities There is no significance to the order in which twelve-octet Large
are encoded in the BGP path attribute payload. A BGP speaker can Community values are encoded in a Large Communities attribute, nor in
transmit them in any order. the order of the BGP Large Communities attributes if two or more such
attributes are encoded in the BGP path attribute payload of a single
BGP Update message. A BGP speaker can transmit them in any order.
Duplicate Large BGP Communities SHOULD NOT be transmitted. A Duplicate BGP Large Community values SHOULD NOT be transmitted. A
receiving speaker SHOULD silently remove duplicate Large BGP receiving speaker SHOULD silently remove duplicate BGP Large
Communities from a BGP UPDATE message. Community values from a BGP UPDATE message.
3. Aggregation 3. Aggregation
If a range of routes is aggregated, then the resulting aggregate If a range of routes is aggregated, then the resulting aggregate
should have a Large BGP Communities attribute which contains all of should have a BGP Large Communities attribute which contains all of
the Large BGP Communities attributes from all of the aggregated the BGP Large Communities attributes from all of the aggregated
routes. routes.
4. Canonical Representation 4. Canonical Representation
Large BGP Communities MUST be represented as three separate unsigned The canonical representation of BGP Large Communities is three
integers in decimal notation in the following order: Global separate unsigned integers in decimal notation in the following
Administrator, Local Data 1, Local Data 2. Numbers MUST NOT contain order: Global Administrator, Local Data 1, Local Data 2. Numbers
leading zeros; a zero value MUST be represented with a single zero. MUST NOT contain leading zeros; a zero value MUST be represented with
For example: 64496:4294967295:2, 64496:0:0, or (64496, 111, 222). a single zero. Each number is separated from the next by a single
colon. For example: 64496:4294967295:2, 64496:0:0.
5. Reserved Large BGP Community values BGP Large Communities SHOULD be represented in the canonical
representation.
The following Global Administrator values are reserved: 0 (the first 5. Reserved BGP Large Community values
ASN) [RFC7607], 65535 (UINT16_MAX) and 4294967295 (the last ASN)
[RFC7300]. Operators SHOULD NOT use these Global Administrator The following Global Administrator values are reserved: 0, 65535, and
4294967295. Operators SHOULD NOT use these Global Administrator
values. values.
Although this document does not define any Special-Use Large BGP Although this document does not define any Special-Use BGP Large
Communities, the Global Administrator values specified above could be Communities, the Global Administrator values specified above could be
used if there is a future need for them. used if there is a future need for them.
6. Error Handling 6. Error Handling
The error handling of Large BGP Communities is as follows: The error handling of BGP Large Communities is as follows:
o A Large BGP Communities attribute SHALL be considered malformed if o A BGP Large Communities attribute SHALL be considered malformed if
its length is not a non-zero multiple of 12. the length of the BGP Large Communities value, expressed in
octets, is not a non-zero multiple of 12.
o A BGP UPDATE message with a malformed Large BGP Communities o A BGP UPDATE message with a malformed BGP Large Communities
attribute SHALL be handled using the approach of "treat-as- attribute SHALL be handled using the approach of "treat-as-
withdraw" as described in section 2 [RFC7606]. withdraw" as described in section 2 [RFC7606].
The Large BGP Communities Global Administrator field may contain any The BGP Large Communities Global Administrator field MAY contain any
value, and a Large BGP Communities attribute MUST NOT be considered value, and a BGP Large Communities attribute MUST NOT be considered
malformed if the Global Administrator field contains an unallocated, malformed if the Global Administrator field contains an unallocated,
unassigned or reserved ASN or is set to one of the reserved Large BGP unassigned or reserved ASN or is set to one of the reserved BGP Large
Community values defined in Section 5. Community values defined in Section 5.
7. Security Considerations 7. Security Considerations
This extension to BGP has similar security implications as BGP This extension to BGP has similar security implications as BGP
Communities [RFC1997]. Communities [RFC1997].
This document does not change any underlying security issues This document does not change any underlying security issues
associated with any other BGP Communities mechanism. Specifically, associated with any other BGP Communities mechanism. Specifically,
an AS relying on the Large BGP Communities attribute carried in BGP an AS relying on the BGP Large Communities attribute carried in BGP
must have trust in every other AS in the path, as any intermediate must have trust in every other AS in the path, as any intermediate
Autonomous System in the path may have added, deleted, or altered the Autonomous System in the path may have added, deleted, or altered the
Large BGP Communities attribute. Specifying the mechanism to provide BGP Large Communities attribute. Specifying the mechanism to provide
such trust is beyond the scope of this document. such trust is beyond the scope of this document.
BGP Large Communities do not protect the integrity of each community
value. Operators should be aware that it is possible for a BGP
speaker to alter BGP Large Community values in a BGP Update Message.
Protecting the integrity of the transitive handling of BGP Large
Community attributes in a manner consistent with the intent of
expressed BGP routing policies falls within the broader scope of
securing BGP, and is not specifically addressed here.
Network administrators should note the recommendations in Section 11 Network administrators should note the recommendations in Section 11
of BGP Operations and Security [RFC7454]. of BGP Operations and Security [RFC7454].
8. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 8. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION
This section records the status of known implementations of the This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [RFC7942]. Internet-Draft, and is based on a proposal described in [RFC7942].
The description of implementations in this section is intended to The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation RFCs. Please note that the listing of any individual implementation
here does not imply endorsement by the IETF. Furthermore, no effort here does not imply endorsement by the IETF. Furthermore, no effort
has been spent to verify the information presented here that was has been spent to verify the information presented here that was
supplied by IETF contributors. This is not intended as, and must not supplied by IETF contributors. This is not intended as, and must not
be construed to be, a catalog of available implementations or their be construed to be, a catalog of available implementations or their
features. Readers are advised to note that other implementations may features. Readers are advised to note that other implementations may
exist. exist.
As of today these vendors have produced an implementation of Large As of today these vendors have produced an implementation of BGP
BGP Communities: Large Communities:
o Cisco IOS XR o Cisco IOS XR
o ExaBGP o ExaBGP
o GoBGP o GoBGP
o BIRD o BIRD
o OpenBGPD o OpenBGPD
o pmacct o pmacct
o Quagga o Quagga
skipping to change at page 6, line 31 skipping to change at page 6, line 47
Protocol (BGP) Parameters" group and is now asked to make that Protocol (BGP) Parameters" group and is now asked to make that
Permanent. Permanent.
10. Contributors 10. Contributors
The following people contributed significantly to the content of the The following people contributed significantly to the content of the
document: document:
John Heasley John Heasley
NTT Communications NTT Communications
Email: heas@shrubbery.net Email: heas@shrubbery.net
Adam Simpson
Nokia
Email: adam.1.simpson@nokia.com
11. Acknowledgments 11. Acknowledgments
The authors would like to thank Ruediger Volk, Russ White, Acee The authors would like to thank Ruediger Volk, Russ White, Acee
Lindem, Shyam Sethuram, Jared Mauch, Joel M. Halpern, Jeffrey Haas, Lindem, Shyam Sethuram, Jared Mauch, Joel M. Halpern, Jeffrey Haas,
Gunter van de Velde, Marco Marzetti, Eduardo Ascenco Reis, Mark Gunter van de Velde, Marco Marzetti, Eduardo Ascenco Reis, Mark
Schouten, Paul Hoogsteder, Martijn Schmidt, Greg Hankins, Bertrand Schouten, Paul Hoogsteder, Martijn Schmidt, Greg Hankins, Bertrand
Duvivier, Barry O'Donovan, Grzegorz Janoszka, Linda Dunbar, Marco Duvivier, Barry O'Donovan, Grzegorz Janoszka, Linda Dunbar, Marco
Davids, Gaurab Raj Upadhaya, Jeff Tantsura, Teun Vink, Adam Davids, Gaurab Raj Upadhaya, Jeff Tantsura, Teun Vink, Adam
Davenport, Theodore Baschak, Pier Carlo Chiodi, Nabeel Cocker, Ian Davenport, Theodore Baschak, Pier Carlo Chiodi, Nabeel Cocker, Ian
Dickinson, Jan Baggen, Duncan Lockwood, David Farmer, Randy Bush, Wim Dickinson, Jan Baggen, Duncan Lockwood, David Farmer, Randy Bush, Wim
Henderickx, Stefan Plug, Kay Rechthien, Rob Shakir, Warren Kumari, Henderickx, Stefan Plug, Kay Rechthien, Rob Shakir, Warren Kumari,
Gert Doering, Thomas King, Mikael Abrahamsson, Wesley Steehouwer, Gert Doering, Thomas King, Mikael Abrahamsson, Wesley Steehouwer,
Sander Steffann, Brad Dreisbach, Martin Millnert, Christopher Morrow, Sander Steffann, Brad Dreisbach, Martin Millnert, Christopher Morrow,
Jay Borkenhagen, Arnold Nipper, Joe Provo, Niels Bakker, Bill Fenner, Jay Borkenhagen, Arnold Nipper, Joe Provo, Niels Bakker, Bill Fenner,
Tom Daly, Ben Maddison, Alexander Azimov, Brian Dickson, Peter van Tom Daly, Ben Maddison, Alexander Azimov, Brian Dickson, Peter van
Dijk, Julian Seifert, Tom Petch, Tom Scholl, Arjen Zonneveld, Remco Dijk, Julian Seifert, Tom Petch, Tom Scholl, Arjen Zonneveld, Remco
van Mook, Adam Chappell, Jussi Peltola, Kristian Larsson, Markus van Mook, Adam Chappell, Jussi Peltola, Kristian Larsson, Markus
Hauschild, Richard Steenbergen, David Freedman, Richard Hartmann for Hauschild, Richard Steenbergen, David Freedman, Richard Hartmann and
their support, insightful review and comments. Geoff Huston for their support, insightful review and comments.
12. References 12. References
12.1. Normative References 12.1. Normative References
[RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities
Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996,
<http://www.rfc-editor.org/info/rfc1997>. <http://www.rfc-editor.org/info/rfc1997>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 7, line 36 skipping to change at page 8, line 5
Patel, "Revised Error Handling for BGP UPDATE Messages", Patel, "Revised Error Handling for BGP UPDATE Messages",
RFC 7606, DOI 10.17487/RFC7606, August 2015, RFC 7606, DOI 10.17487/RFC7606, August 2015,
<http://www.rfc-editor.org/info/rfc7606>. <http://www.rfc-editor.org/info/rfc7606>.
12.2. Informative References 12.2. Informative References
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, Communities Attribute", RFC 4360, DOI 10.17487/RFC4360,
February 2006, <http://www.rfc-editor.org/info/rfc4360>. February 2006, <http://www.rfc-editor.org/info/rfc4360>.
[RFC7300] Haas, J. and J. Mitchell, "Reservation of Last Autonomous
System (AS) Numbers", BCP 6, RFC 7300,
DOI 10.17487/RFC7300, July 2014,
<http://www.rfc-editor.org/info/rfc7300>.
[RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations [RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations
and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454, and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454,
February 2015, <http://www.rfc-editor.org/info/rfc7454>. February 2015, <http://www.rfc-editor.org/info/rfc7454>.
[RFC7607] Kumari, W., Bush, R., Schiller, H., and K. Patel,
"Codification of AS 0 Processing", RFC 7607,
DOI 10.17487/RFC7607, August 2015,
<http://www.rfc-editor.org/info/rfc7607>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205, Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016, RFC 7942, DOI 10.17487/RFC7942, July 2016,
<http://www.rfc-editor.org/info/rfc7942>. <http://www.rfc-editor.org/info/rfc7942>.
12.3. URIs 12.3. URIs
[1] http://largebgpcommunities.net [1] http://largebgpcommunities.net
Authors' Addresses Authors' Addresses
skipping to change at page 9, line 4 skipping to change at page 9, line 4
Arrcus, Inc Arrcus, Inc
Email: keyur@arrcus.com Email: keyur@arrcus.com
Ignas Bagdonas Ignas Bagdonas
Equinix Equinix
London London
UK UK
Email: ibagdona.ietf@gmail.com Email: ibagdona.ietf@gmail.com
Adam Simpson
Nokia
600 March Road
Ottawa Ontario K2K 2E6
Canada
Email: adam.1.simpson@nokia.com
Nick Hilliard Nick Hilliard
INEX INEX
4027 Kingswood Road 4027 Kingswood Road
Dublin 24 Dublin 24
IE IE
Email: nick@inex.ie Email: nick@inex.ie
 End of changes. 43 change blocks. 
95 lines changed or deleted 98 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
--J/dobhs11T7y2rNN-- From nobody Fri Nov 4 13:40:01 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C05C81295D6 for ; Fri, 4 Nov 2016 13:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.297 X-Spam-Level: X-Spam-Status: No, score=-5.297 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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WEmD8WbDcewH for ; Fri, 4 Nov 2016 13:39:53 -0700 (PDT) Received: from mta-p6.oit.umn.edu (mta-p6.oit.umn.edu [134.84.196.206]) (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 8453F12958D for ; Fri, 4 Nov 2016 13:39:53 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p6.oit.umn.edu (Postfix) with ESMTP id 0353B602 for ; Fri, 4 Nov 2016 20:39:53 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p6.oit.umn.edu ([127.0.0.1]) by localhost (mta-p6.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id inuxZ62EVzac for ; Fri, 4 Nov 2016 15:39:52 -0500 (CDT) Received: from mail-qt0-f197.google.com (mail-qt0-f197.google.com [209.85.216.197]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p6.oit.umn.edu (Postfix) with ESMTPS id B7BF69E0 for ; Fri, 4 Nov 2016 15:39:52 -0500 (CDT) Received: by mail-qt0-f197.google.com with SMTP id n6so43442073qtd.4 for ; Fri, 04 Nov 2016 13:39:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=g1BJG/G7Ur4Wvcce2dzsDypyupQiwihgl93eow69aaA=; b=Ksue/p9kEs0xA+kCR3E88hNpBIIdUgkSDQ0Mxi6ANJOhCJSpAHv75byPooc3dOpW1O wx+ZxUrDOh0edt0vvK8pgIFFflKKWSx0L1gxouQ64SdbJ+HQ9j3Vh1anrfAWr+3AMSOI XoLcC+5XHydmOpfqBTws5h0hbuG1XGuqHmOhLJ1y3wdWcN9Wb849MxaDAK36WVsKWs6t r70uHU5YOidusSOvXFkfj17/gNA72NAV4vm9SFRVsT12f+8Zv63Dc2cFTcMmhZ44y01H 783efYyphwUxZcEgqosvh03oxNb0TL9At13nJEmGZXqMkLJH3+VYs7PG8P5kAa85eJyz 7FoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=g1BJG/G7Ur4Wvcce2dzsDypyupQiwihgl93eow69aaA=; b=PlZF8iFqAacCuZyhSNnSlmbMmizCgKuyG5UnP+9tn1nGKI1uBNR0HyJIYgGWSI9Xkr VAmg+v94MFcD5mMbbMZlwF5845zg7ZqYNxvTZnPvQ8dqnoESSPocZdbhaD5pOLnZdW+Q uTp5cz2w1s7u//Og0A/llY6bkIUQZbViJv6+uFVLqdHBuEjlkX9rnNjTy9GHBlCb4ScJ 0Q0MfWPqt4XUgCdsktLAohtE0snD0yo/eUjnD637Yhhs2wjUgszBzeJg6CHg/Wqr0KOH ZWUe4PL59LJsj0jzpPSOBW5ofUYl0GALsFi249Hncn5xU8rd0YyW+jGJ/vtEGT2HCaLy m5PQ== X-Gm-Message-State: ABUngvfzW2w4b4aDwNGCAJv2Z3kCs9DRYbCQKgE7UMSdM778CFBB/8DcEsQELJ0EYmWFHzTTNAPAgtVvVVN1za3FcD1qjG/NwqzHFTwr3bAHKQ3uzREGduL1EYEZBGJKF9eXgKwGUBZcWJJgjQ== X-Received: by 10.55.91.193 with SMTP id p184mr6655975qkb.301.1478291992179; Fri, 04 Nov 2016 13:39:52 -0700 (PDT) X-Received: by 10.55.91.193 with SMTP id p184mr6655961qkb.301.1478291991988; Fri, 04 Nov 2016 13:39:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.50.253 with HTTP; Fri, 4 Nov 2016 13:39:51 -0700 (PDT) In-Reply-To: <20161104171834.GE961@Vurt.local> References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com> <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com> <288c77155de540adbdb60d8587b9f39b@XCH-ALN-014.cisco.com> <20161104171834.GE961@Vurt.local> From: David Farmer Date: Fri, 4 Nov 2016 15:39:51 -0500 Message-ID: To: Job Snijders Content-Type: multipart/alternative; boundary=001a114e2cf60ea45b05407fadfa Archived-At: Cc: IETF IDR WG , Susan Hares , "rtg-dir@ietf.org" Subject: Re: [Idr] Review of draft-ietf-large-community-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: Fri, 04 Nov 2016 20:39:56 -0000 --001a114e2cf60ea45b05407fadfa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Nov 4, 2016 at 12:18 PM, Job Snijders wrote: > On Fri, Nov 04, 2016 at 08:04:47PM +1100, Geoff Huston wrote: > > >> 4. Canonical Representation > > >> > > >> I am confused here - this section used an example with TWO > > >> canonical representations: > > >> > > >> "For example: 64496:4294967295:2, 64496:0:0, or (64496, 111, 222).= " > > >> Conventionally, it's better to use a single canonical > > >> representation, so the authors should pick either a colon-delimited > > >> list, or a bracketed comma+space separated object. > > > > > On 4 Nov. 2016, at 3:05 pm, Jakob Heitz (jheitz) > wrote: > > > > > > To explain this one, it was originally "Textual Representation" and > > > it was with colons only. Then we discovered that Bird uses commas as > > > a separator. Since that does not degrade the utility, we allowed it. > > > The real point is that it has to be exactly 3 positive decimal > > > integers. If some implementations only offered hexadecimal or used 6 > > > int16's then it would become very difficult for ISPs to communicate > > > community settings to customers. I can change it to a single > > > representation and detail the allowed deviations from it. > > > > if you make a canonical a SHOULD not a MUST then you can permit > > variation without breaking the standard. > > > > So what you are saying is that the canonical representation of a > > single Large Community value is three unsigned decimal integer values, > > separated by a =E2=80=98:=E2=80=99 (colon) character, representing the = value as a > > triplet of unsigned 32-bit integer values. Implementations SHOULD > > accept this representation as a valid form of representation of the > > value of a Large Community. > > It appears the word "canonical" is maybe triggering something. The key > element is that its three separate values. Nobody cares whether it is a > colon, comma or a hypen. > > Does removing the word "canonical" address the raised remark? > > """ > 4. Representation > > Large BGP Communities MUST be represented as three separate unsigned > integers in decimal notation in the following order: Global > Administrator, Local Data 1, Local Data 2. Numbers MUST NOT contain > leading zeros; a zero value MUST be represented with a single zero. > For example: 64496:4294967295:2, 64496:0:0, or (64496, 111, 222). > """ > I won't try to speak for Geoff, but it doesn't do it for me. I think we should just say what you've said previously as a summary of the intent, but use normative language. I'd propose something like the following. 4. Canonical Representation The canonical representation for Large BGP Communities is three separate unsigned integers in decimal notation separated by colons in the following order: Global Administrator, Local Data 1, Local Data 2. For example: 64496:4294967295:2, 64496:0:0, or 64496:111:222 Implementations SHOULD use the above canonical representation, especially when representing a Large BGP Community for output. Implementations MAY use other delimiters than colons, especially for compatibility with a configuration syntax. However, Large BGP Communities MUST be represented as three separate unsigned integers in decimal notation, regardless of the delimiters used. Further, the numbers MUST NOT contain leading zeros, and a zero value MUST be represented with a single zero. --=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --001a114e2cf60ea45b05407fadfa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Nov 4, 2016 at 12:18 PM, Job Snijders <job@ntt.net> wr= ote:
On Fri, Nov 04, 2= 016 at 08:04:47PM +1100, Geoff Huston wrote:
> >> 4.=C2=A0 Canonical Representation
> >>
> >> I am confused here - this section used an example with TWO > >> canonical representations:
> >>
> >>=C2=A0 =C2=A0"For example: 64496:4294967295:2, 64496:0:0,= or (64496, 111, 222)."
> >> Conventionally, it's better to use a single canonical
> >> representation, so the authors should pick either a colon-del= imited
> >> list, or a bracketed comma+space separated object.
>
> > On 4 Nov. 2016, at 3:05 pm, Jakob Heitz (jheitz) <jheitz@cisco.com> wrote:
> >
> > To explain this one, it was originally "Textual Representati= on" and
> > it was with colons only. Then we discovered that Bird uses commas= as
> > a separator. Since that does not degrade the utility, we allowed = it.
> > The real point is that it has to be exactly 3 positive decimal > > integers. If some implementations only offered hexadecimal or use= d 6
> > int16's then it would become very difficult for ISPs to commu= nicate
> > community settings to customers.=C2=A0 I can change it to a singl= e
> > representation and detail the allowed deviations from it.
>
> if you make a canonical a SHOULD not a MUST then you can permit
> variation without breaking the standard.
>
> So what you are saying is that the canonical representation of a
> single Large Community value is three unsigned decimal integer values,=
> separated by a =E2=80=98:=E2=80=99 (colon) character, representing the= value as a
> triplet of unsigned 32-bit integer values. Implementations SHOULD
> accept this representation as a valid form of representation of the > value of a Large Community.

It appears the word "canonical" is maybe triggering something. Th= e key
element is that its three separate values. Nobody cares whether it is a
colon, comma or a hypen.

Does removing the word "canonical" address the raised remark?

"""
4.=C2=A0 Representation

=C2=A0 =C2=A0Large BGP Communities MUST be represented as three separate un= signed
=C2=A0 =C2=A0integers in decimal notation in the following order: Global =C2=A0 =C2=A0Administrator, Local Data 1, Local Data 2.=C2=A0 Numbers MUST = NOT contain
=C2=A0 =C2=A0leading zeros; a zero value MUST be represented with a single = zero.
=C2=A0 =C2=A0For example: 64496:4294967295:2, 64496:0:0, or (64496, 111, 22= 2).
"""

I won't try to s= peak for Geoff, but it doesn't do it for me.=C2=A0

=
I think we should just say what you've said previously as a summar= y of the intent, but use normative language.

I'= ;d propose something like the following.

4.=C2=A0 Canonical Representation<= br>
=C2=A0 =C2=A0The canonical representation for Large BGP Communities = is three separate unsigned
=C2=A0 =C2=A0int= egers in decimal notation separated by colons in the following order: Globa= l
=C2=A0 =C2=A0Administrator, Local Data 1, Local Data 2.=C2=A0 For exam= ple: 64496:4294967295:2,=C2=A0
=C2=A0 =C2= =A064496:0:0, =C2=A0or 64496:111:222

=C2=A0 =C2=A0Implementations SHOULD use the = above canonical representation, especially when=C2=A0
=C2=A0 =C2=A0representing a Large BGP Community for output. =C2= =A0 Implementations MAY use other=C2=A0
=C2= =A0 =C2=A0delimiters than colons, especially for compatibility with a confi= guration syntax.=C2=A0 However,=C2=A0
=C2= =A0 =C2=A0Large BGP Communities MUST be represented as three separate unsig= ned integers=C2=A0
=C2=A0 =C2=A0in decimal = notation, regardless of the delimiters used. Further, the numbers MUST NOT = contain=C2=A0
=C2=A0 =C2=A0leading zeros, a= nd a zero value MUST be represented with a single zero.


=C2=A0=C2=A0




= --
=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
Networking & Telecommunication = Services
Office of Information Technology
University of Minnesota=C2= =A0=C2=A0
2218 University Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-= 626-0815
Minneapolis, MN 55414-3029=C2=A0=C2=A0 Cell: 612-812-9952
= =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--001a114e2cf60ea45b05407fadfa-- From nobody Fri Nov 4 13:45:52 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2670F129668 for ; Fri, 4 Nov 2016 13:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.398 X-Spam-Level: X-Spam-Status: No, score=-108.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 i38ewmZMT_Pk for ; Fri, 4 Nov 2016 13:45:49 -0700 (PDT) Received: from ao-mailgw.apnic.net (ao-mailgw.apnic.net [IPv6:2001:dd8:8:701::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44DEC12966D for ; Fri, 4 Nov 2016 13:45:48 -0700 (PDT) Received: from nxmda2.org.apnic.net (unknown [2001:dd8:9:2::101:249]) by ao-mailgw.apnic.net (Halon) with ESMTPS id a71a21f7-a2cf-11e6-b8ce-005056b6ee6f; Sat, 05 Nov 2016 06:45:43 +1000 (AEST) Received: from dhcp150.potaroo.net (203.119.101.249) by NXMDA2.org.apnic.net (203.119.107.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sat, 5 Nov 2016 06:45:27 +1000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Geoff Huston In-Reply-To: <20161104201631.GA35942@Vurt.lan> Date: Sat, 5 Nov 2016 07:45:43 +1100 Content-Transfer-Encoding: quoted-printable Message-ID: <5941CFD9-715C-4BB9-8226-39B4A6A0A6FB@apnic.net> References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com> <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com> <6c5d83aa1d6a4a04b651b8f14f4b445b@XCH-ALN-014.cisco.com> <40D942F5-0710-46D1-BF09-76C827377479@cisco.com> <95F42982-7DCF-46A9-A26C-71EF70DB3C59@apnic.net> <20161104195346.GK961@Vurt.local> <20161104201631.GA35942@Vurt.lan> To: Job Snijders X-Mailer: Apple Mail (2.3251) Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] Review of draft-ietf-large-community-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: Fri, 04 Nov 2016 20:45:51 -0000 > On 5 Nov. 2016, at 7:16 am, Job Snijders wrote: >=20 > Hi everyone, >=20 > Attached is the rfcdiff html file that represents the current -06 -> = -07 > changes with the work from Jakob and Geoff and some nits that were > picked by John Scudder. >=20 > I should note the following, in "Reserved BGP Large Community values" > the 'reasons' behind each reserved value were removed. Some in the > working group made a case that it could be good to provide a > justification what makes these numbers special. >=20 > Other then that, i feel that these changes have improved the = document's > flow and readability. >=20 > Kind regards, >=20 > Job >=20 Thanks indeed for this - my comments are all resolved at this point in = the proposed -07 version. regards, Geoff From nobody Fri Nov 4 13:46:55 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47DBA129666 for ; Fri, 4 Nov 2016 13:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XAOCmj10bwAo for ; Fri, 4 Nov 2016 13:46:50 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4746F129668 for ; Fri, 4 Nov 2016 13:46:50 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id t79so72272851wmt.0 for ; Fri, 04 Nov 2016 13:46:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=4q5DRwKzPWWV6ouJDBUtnvyB+E8SOvxqVPFstwoI+mU=; b=ubMcKObxvr0lzjujQzkB2AbyaWQUnocanbjtLAtbOIxpgbq0OSFERSqmXb3+r1JqTr E0Y1YY08kyyohxuV+izXwsFrbEXYHkwxsMhgSkHLti9UDScy6PRcxt8XuNp/36tLY6fY 0E4WtdAeYJRYyK/UdVG6kw4qK5pamP4QNqT5Y+TRYZ9mZM/i2e2by0dGvXrxBshEkn/p sxd3BJXAMykekJS/fWqyzHcbr6TnhG1X2rZC6pa6ik+/qzGBOag72moxiu+MYwrTcl1U +HTG3uZG8X9NZM2E2rQH6hp0ZDgtn9js197DrIX9s/K70yQzVLZVYr7mtuPJABTtZ3T0 ymVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=4q5DRwKzPWWV6ouJDBUtnvyB+E8SOvxqVPFstwoI+mU=; b=Hn2ABxlP1Pp6LtOzZ/Vv3HGX75kflSwPIbIgfG7ERxSlLLyc7Ay70eOopr9soN4paL FR2s2grSxvdmqlxs6MSZFB/aRH1MPO4GY4ui//x+wwij3DEcKpKUJNPvgMfmugE7c3Zv WGxpsXuGfeTyH4SGzy/vvSnNoKJsEzg0irGsujTw0JIiSc6IcdbJb1XQHguwU7wglL/s gWD0EXpZksMkiuDeX172OYP5YKv5Wudjh37M60yGcRcH6hhbh1wTbjgJVZk4+jMe50Pn 3Ifgo/h4XymcDxxSm8Q4AvIBrHDXKbNb5BVHafj2NNVEwjpIQKxz9k1lWHeg3IgFd8e4 2BMw== X-Gm-Message-State: ABUngvdAVzxxi/oPfd9Ug93lBJo5nFJ0Yu0jcZqID1pQrattiWRQQga2ckNAQIJpjtwbgQ== X-Received: by 10.194.158.131 with SMTP id wu3mr13156598wjb.93.1478292408392; Fri, 04 Nov 2016 13:46:48 -0700 (PDT) Received: from [192.168.191.136] ([80.69.10.100]) by smtp.gmail.com with ESMTPSA id c7sm16113345wjk.19.2016.11.04.13.46.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Nov 2016 13:46:47 -0700 (PDT) To: Geoff Huston , "Jakob Heitz (jheitz)" References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com> <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com> <6c5d83aa1d6a4a04b651b8f14f4b445b@XCH-ALN-014.cisco.com> <40D942F5-0710-46D1-BF09-76C827377479@cisco.com> <95F42982-7DCF-46A9-A26C-71EF70DB3C59@apnic.net> From: Ignas Bagdonas Message-ID: <79ca5727-d42e-d253-f929-2cd35261628a@gmail.com> Date: Fri, 4 Nov 2016 20:46:44 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <95F42982-7DCF-46A9-A26C-71EF70DB3C59@apnic.net> Content-Type: multipart/alternative; boundary="------------6DD2D3175DD1AFA561DECBF4" Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] Review of draft-ietf-large-community-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: Fri, 04 Nov 2016 20:46:54 -0000 This is a multi-part message in MIME format. --------------6DD2D3175DD1AFA561DECBF4 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Geoff, On your changes 6 and 7 - RFC7606 error handling requires to interpret only the first path attribute of the same type, ignoring the other instances. Within the path attribute duplicate identical community values are treated as one, and the case of multiple large community path attributes is handled by interpreting only the first path attribute. This has been discussed on the list around -02 or -03 revision timeframe. Making a deviation for multiple path attributes would be in violation of 7606 here. Ignas On 04/11/2016 19:41, Geoff Huston wrote: > Jakob, > > Many thanks for sending this. > > I have used Word to mark up my reactions to this proposed revisions for your further review as this tool has a good track changes option - the PDF of the marked up text is attached to this note. > > My suggested changes to your proposed test are: > > 1) change to the Introduction to alter the description of Communities to conform more exactly to the language used in RFC 1997 > > 2) change to the considerations of RFC4360 in the Introduction. (I also note that RFC4360 calls the Global Administrator and Local Administrator parts of the community value “sub-fileds” rather than “fields”, while this draft calls these elements just “fields” ) > > 3) the set of values is explicitly called out to be “unordered” in the Introduction > > 4) The description of the attribute fields is altered to be consistent with RFC4360 > > 5) the treatment of the Global Administrator value is unclear. I have proposed removing the last two sentences and propose changing the MUST to a SHOULD, as, later in the draft in Section 6, it is noted that the Global Administrator field can be any value! > > 6) I have explicitly called out that the values are in any order, and allowed for two or more individual Large Communities attributes to be contained in a single BGP Update message, again in any order. If this is not your intent then you should look at this part of section 2 and tighten up the wording. > > 7) you have not explicitly disambiguated between duplicate instances of the same attribute and duplicate instances of the same Community value. I have offerred some text to clarify this to the level of values. > > 8) I have proposed changing the MUST to a SHOULD in rthe canonical representation section > > 9) The sentences about the use of a colon make no sense given that you have not specified a colon separator in the preceeding paragraph. You probably need to either drop the reference to the colon, or add a colon as part of the Canonical Representation. I have proposed the former. > > 10) - in section 6 I changed the “may” to a “MAY” - seemed like the right thing to do. > > 11) I added a paragraph in the Security Considerations section explicitly that the values in this attribute are not specifically protected and then pointed to BGP security (just because an ASN is used in a community attribute, that does not mean that the ASN in question attached that attribute, or that the ASN will honour that attribute. - its just a signal without any integrity protection) > > 12) I have added my name as a reviewer - hope that’s ok! :-) > > I _assume_ that the atomic aggregator mess will be fixed up by the action of making this an historic attribute, so I have left the text on aggregation unaltered. > > Regards, > > Geoff > > > > >> On 5 Nov. 2016, at 1:20 am, Jakob Heitz (jheitz) wrote: >> >> Geoff, >> >> Here is my proposed revision. I made all the changes, except the ATOMIC_AGGREGATE. If after the latest discussion, you still want it, I'll make that change too. >> >> Thanks, >> Jakob. >> >> >> Begin forwarded message: >> >>>> -----Original Message----- >>>> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Geoff Huston >>>> Sent: Thursday, November 03, 2016 5:14 PM >>>> To: IETF IDR WG >>>> Cc: rtg-dir@ietf.org; Susan Hares >>>> Subject: [Idr] Review of draft-ietf-large-community-06.txt >>>> >>>> I have reviewed this draft and have the following 9 suggestions. All of >>>> these fall into the category of minor suggestions. I do not believe that >>>> there is may major structural deficiency in this specification, and the >>>> document is largely ready, in my view. >>>> >>>> Here are my specific suggestions. >>>> >>>> >>>> 1. ---------------- >>>> >>>> Title: Large BGP Communities >>>> >>>> to be consistent with previous attribute specifications, how about >>>> >>>> "BGP Large Communities Attribute" >>>> >>>> i.e. switch the order of "Large BGP" to "BGP Large" to be consistent with >>>> earlier BGP Extended Communities specification in RFC4360 >>>> >>>> 2. ---------------- >>>> >>>> "Network operators >>>> attach BGP communities to routes to identify intrinsic properties of >>>> these routes." >>>> >>>> I don't think community attributes are an intrinsic property of a route >>>> advertisement - they are more appropriately expressed as an attached attribute >>>> that expresses some desired property. >>>> >>>> how about: >>>> >>>> "Network operators attach BGP communities to routes to associate >>>> particular properties with these routes." >>>> >>>> 3. ---------------- >>>> >>>> "and may apply to an individual route or to a group of routes." >>>> >>>> I am confused - surely the attributes in an Update BGP message apply to the >>>> collection of routes contained in the Update. It cannot be applied to a >>>> single route when the update itself contains multiple routes. Why not >>>> use the text: >>>> >>>> "and is applied to all routes contained in a BGP Update Message where >>>> the Communities Attribute is included." >>>> >>>> 4. ---------------- >>>> >>>> "[RFC1997] BGP Communities attributes are four-octet values split into >>>> two two-octet words." >>>> >>>> This is not the case - RFC1997 says: "Communities are treated as 32 bit values" >>>> I think it would be more accurate to say: >>>> >>>> "BGP Communities attributes are four-octet values [RFC1997]. Common use of >>>> this attribute type splits this single 32-bit value field into two 16-bit values." >>>> >>>> 5. ---------------- >>>> >>>> "The BGP Extended Communities >>>> attribute [RFC4360] is also unsuitable, as the protocol limit of six >>>> octets cannot accommodate both a four-octet Global Administrator >>>> value and a four-octet Local Administrator value, which precludes the >>>> common operational practice of encoding a target ASN in the Local >>>> Administrator field." >>>> >>>> >>>> Thats a very long sentence. Try: >>>> >>>> "The BGP Extended Communities attribute [RFC4360] is also unsuitable, as >>>> the protocol limit of six octets for each community value cannot >>>> accommodate both a four-octet Global Administrator value and a four-octet >>>> Local Administrator value. This limitation precludes the common >>>> operational practice of encoding a target ASN in the Local Administrator >>>> field." >>>> >>>> 6. ---------------- >>>> >>>> The aggregation section contains fewer constraints then either RFC1997 or >>>> RFC4360. It also contains a confusing non-normative “should". >>>> >>>> For reference, RFC4360 states: By default if a range of routes is to be >>>> aggregated and the resultant aggregates path attributes do not carry the >>>> ATOMIC_AGGREGATE attribute, then the resulting aggregate should have an >>>> Extended Communities path attribute that contains the set union of all the >>>> Extended Communities from all of the aggregated routes. The default >>>> behavior could be overridden via local configuration, in which case >>>> handling the Extended Communities attribute in the presence of route >>>> aggregation becomes a matter of the local policy of the BGP speaker that >>>> performs the aggregation. >>>> >>>> Why not use this formulation? i.e. >>>> >>>> "3. Aggregation >>>> >>>> If a set of routes is to be aggregated and the resulting aggregate route's >>>> path attributes do not include the ATOMIC_AGGREGATE attribute, then the >>>> resulting aggregate route SHOULD have a Large Communities Attribute formed >>>> from the set union of all the Large Community values from all of the >>>> aggregated set of routes. This behavior MAY be overridden via local >>>> configuration, in which case handling the Large Communities attribute in >>>> the presence of route aggregation is determined by the local policy of the >>>> BGP speaker that performs the aggregation." >>>> >>>> 7. ---------------- >>>> >>>> 4. Canonical Representation >>>> >>>> I am confused here - this section used an example with TWO canonical >>>> representations: >>>> >>>> "For example: 64496:4294967295:2, 64496:0:0, or (64496, 111, 222)." >>>> >>>> >>>> Conventionally, it's better to use a single canonical representation, so the >>>> authors should pick either a colon-delimited list, or a bracketed comma+space >>>> separated object. >>>> >>>> >>>> 8. ---------------- >>>> >>>> 5. Reserved Large BGP Community values >>>> >>>> >>>> The text reads: >>>> >>>> "the Global Administrator values specified above could be >>>> used if there is a future need for them." >>>> >>>> This is entirely unclear. Is it referring to the values that the previous >>>> paragraph specified as "SHOULD NOT use”? Also "could be used" is a poor >>>> choice of words for a normative specification. >>>> >>>> I suggest deleting completely the paragraph that contains this quote from >>>> the document. >>>> >>>> >>>> 9. ---------------- >>>> >>>> The text reads: >>>> >>>> "The error handling of Large BGP Communities is as follows: >>>> >>>> o A Large BGP Communities attribute SHALL be considered malformed if >>>> its length is not a non-zero multiple of 12." >>>> >>>> >>>> I think the author is trying to dayL >>>> >>>> "The error handling of Large BGP Communities is as follows: >>>> >>>> o A Large Communities attribute SHALL be considered malformed if the >>>> length of the Large Communities value, expressed in octets, is not a >>>> non-zero multiple of 12." >>>> >>>> >>>> thanks, >>>> >>>> Geoff >>>> >>>> _______________________________________________ >>>> 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 --------------6DD2D3175DD1AFA561DECBF4 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Hi Geoff,

On your changes 6 and 7 - RFC7606 error handling requires to interpret only the first path attribute of the same type, ignoring the other instances. Within the path attribute duplicate identical community values are treated as one, and the case of multiple large community path attributes is handled by interpreting only the first path attribute. This has been discussed on the list around -02 or -03 revision timeframe. Making a deviation for multiple path attributes would be in violation of 7606 here.


Ignas



On 04/11/2016 19:41, Geoff Huston wrote:
Jakob,

Many thanks for sending this.

I have used Word to mark up my reactions to this proposed revisions for your further review as this tool has a good track changes option - the PDF of the marked up text is attached to this note.

My suggested changes to your proposed test are:

1) change to the Introduction to alter the description of Communities to conform more exactly to the language used in RFC 1997

2) change to the considerations of RFC4360 in the Introduction. (I also note that RFC4360 calls the Global Administrator and Local Administrator parts of the community value “sub-fileds” rather than “fields”, while this draft calls these elements just “fields” )

3) the set of values is explicitly called out to be “unordered” in the Introduction

4) The description of the attribute fields is altered to be consistent with RFC4360

5) the treatment of the Global Administrator value is unclear. I have proposed removing the last two sentences and propose changing the MUST to a SHOULD, as, later in the draft in Section 6, it is noted that the Global Administrator field can be any value!

6) I have explicitly called out that the values are in any order, and allowed for two or more individual Large Communities attributes to be contained in a single BGP Update message, again in any order. If this is not your intent then you should look at this part of section 2 and tighten up the wording.

7) you have not explicitly disambiguated between duplicate instances of the same attribute and duplicate instances of the same Community value. I have offerred some text to clarify this to the level of values.

8) I have proposed changing the MUST to a SHOULD in rthe canonical representation section

9) The sentences about the use of a colon make no sense given that you have not specified a colon separator in the preceeding paragraph. You probably need to either drop the reference to the colon, or add a colon as part of the Canonical Representation. I have proposed the former.

10) - in section 6 I changed the “may” to a “MAY” - seemed like the right thing to do.

11) I added a paragraph in the Security Considerations section explicitly that the values in this attribute are not specifically protected and then pointed to BGP security (just because an ASN is used in a community attribute, that does not mean that the ASN in question attached that attribute, or that the ASN will honour that attribute. - its just a signal without any integrity protection)

12) I have added my name as a reviewer - hope that’s ok! :-)

I _assume_ that the atomic aggregator mess will be fixed up by the action of making this an historic attribute, so I have left the text on aggregation unaltered.

Regards,

  Geoff






On 5 Nov. 2016, at 1:20 am, Jakob Heitz (jheitz) <jheitz@cisco.com> wrote:

Geoff,

Here is my proposed revision. I made all the changes, except the ATOMIC_AGGREGATE. If after the latest discussion, you still want it, I'll make that change too.

Thanks,
Jakob.


Begin forwarded message:


-----Original Message-----
From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Geoff Huston
Sent: Thursday, November 03, 2016 5:14 PM
To: IETF IDR WG <idr@ietf.org>
Cc: rtg-dir@ietf.org; Susan Hares <shares@ndzh.com>
Subject: [Idr] Review of draft-ietf-large-community-06.txt

I have reviewed this draft and have the following 9 suggestions. All of
these fall into the category of minor suggestions. I do not believe that
there is may major structural deficiency in this specification, and the
document is largely ready, in my view.

Here are my specific suggestions.


1. ----------------

Title: Large BGP Communities

to be consistent with previous attribute specifications, how about

"BGP Large Communities Attribute"

i.e. switch the order of "Large BGP" to "BGP Large" to be consistent with
earlier BGP Extended Communities specification in RFC4360

2. ----------------

"Network operators
attach BGP communities to routes to identify intrinsic properties of
these routes."

I don't think community attributes are an intrinsic property of a route
advertisement - they are more appropriately expressed as an attached attribute
that expresses some desired property.

how about:

"Network operators attach BGP communities to routes to associate
particular properties with these routes."

3. ----------------

"and may apply to an individual route or to a group of routes."

I am confused - surely the attributes in an Update BGP message apply to the
collection of routes contained in the Update. It cannot be applied to a
single route when the update itself contains multiple routes. Why not
use the text:

"and is applied to all routes contained in a BGP Update Message where
the Communities Attribute is included."

4. ----------------

"[RFC1997] BGP Communities attributes are four-octet values split into
two two-octet words."

This is not the case - RFC1997 says: "Communities are treated as 32 bit values"
I think it would be more accurate to say:

"BGP Communities attributes are four-octet values [RFC1997]. Common use of
this attribute type splits this single 32-bit value field into two 16-bit values."

5. ----------------

"The BGP Extended Communities
attribute [RFC4360] is also unsuitable, as the protocol limit of six
octets cannot accommodate both a four-octet Global Administrator
value and a four-octet Local Administrator value, which precludes the
common operational practice of encoding a target ASN in the Local
Administrator field."


Thats a very long sentence. Try:

"The BGP Extended Communities attribute [RFC4360] is also unsuitable, as
the protocol limit of six octets for each community value cannot
accommodate both a four-octet Global Administrator value and a four-octet
Local Administrator value. This limitation precludes the common
operational practice of encoding a target ASN in the Local Administrator
field."

6. ----------------

The aggregation section contains fewer constraints then either RFC1997 or
RFC4360. It also contains a confusing non-normative “should".

For reference, RFC4360 states: By default if a range of routes is to be
aggregated and the resultant aggregates path attributes do not carry the
ATOMIC_AGGREGATE attribute, then the resulting aggregate should have an
Extended Communities path attribute that contains the set union of all the
Extended Communities from all of the aggregated routes.  The default
behavior could be overridden via local configuration, in which case
handling the Extended Communities attribute in the presence of route
aggregation becomes a matter of the local policy of the BGP speaker that
performs the aggregation.

Why not use this formulation? i.e.

"3. Aggregation

If a set of routes is to be aggregated and the resulting aggregate route's
path attributes do not include the ATOMIC_AGGREGATE attribute, then the
resulting aggregate route SHOULD have a Large Communities Attribute formed
from the set union of all the Large Community values from all of the
aggregated set of routes.  This behavior MAY be overridden via local
configuration, in which case handling the Large Communities attribute in
the presence of route aggregation is determined by the local policy of the
BGP speaker that performs the aggregation."

7. ----------------

4.  Canonical Representation

I am confused here - this section used an example with TWO canonical
representations:

 "For example: 64496:4294967295:2, 64496:0:0, or (64496, 111, 222)."


Conventionally, it's better to use a single canonical representation, so the
authors should pick either a colon-delimited list, or a bracketed comma+space
separated object.


8. ----------------

5.  Reserved Large BGP Community values


The text reads:

"the Global Administrator values specified above could be
used if there is a future need for them."

This is entirely unclear. Is it referring to the values that the previous
paragraph specified as "SHOULD NOT use”? Also "could be used" is a poor
choice of words for a normative specification.

I suggest deleting completely the paragraph that contains this quote from
the document.


9. ----------------

The text reads:

"The error handling of Large BGP Communities is as follows:

 o  A Large BGP Communities attribute SHALL be considered malformed if
    its length is not a non-zero multiple of 12."


I think the author is trying to dayL

"The error handling of Large BGP Communities is as follows:

 o  A Large Communities attribute SHALL be considered malformed if the
   length of the Large Communities value, expressed in octets, is not a
   non-zero multiple of 12."


thanks,

Geoff

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

<draft-ietf-idr-large-community.xml><draft-ietf-idr-large-community-07.txt><draft-ietf-idr-large-community-07-diff-from-06.html>


      

      

      

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


    

    

  


--------------6DD2D3175DD1AFA561DECBF4--


From nobody Fri Nov  4 14:55:55 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAA2E1297C3 for ; Fri,  4 Nov 2016 14:55:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.018
X-Spam-Level: 
X-Spam-Status: No, score=-16.018 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=-1.497, 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 uIH5rPOVeppv for ; Fri,  4 Nov 2016 14:55:51 -0700 (PDT)
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 B45591297D4 for ; Fri,  4 Nov 2016 14:55:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18602; q=dns/txt; s=iport; t=1478296551; x=1479506151; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=KGStD/vF96DrTqSX8B+8zQL3kXxfqyhFK785Z7hokoI=; b=Qiva+AoT0dgmDzfAUfN5SKHbKmik3mTXGNzRC/RHq4pkEYXRmZ5+nnup AW8ijyfBkrIcAr69I5ZBaRhEMfOFgSvNUIqREI5NjwIrXAxj+cd3C+7RM c1VzIk3p7Dd5CEVPBC079Pg+Z6DUR4bshy0wiItVc4SfIeUw5I4wdcIk/ U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAQAsAx1Y/5ldJa1SChkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMuAQEBAQEfWHwHjTGXAJRGgggdC4V7AhqBfj8UAQIBAQEBAQE?= =?us-ascii?q?BYiiEYQEBAQQBAQEgBA06CwwEAgEIEQQBAQECAiMDAgICJQsUAQgIAgQBDQUID?= =?us-ascii?q?IhEDq8tjHkBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYEJhTaEVYQfBTqCbYJcAQS?= =?us-ascii?q?IS4YIi1ABiT6GeoF1jhyHKYV4hAMBHjdsgyOBfnKFCYEvgQwBAQE?=
X-IronPort-AV: E=Sophos;i="5.31,445,1473120000"; d="scan'208";a="344340987"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Nov 2016 21:55:50 +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 uA4LtoIK011436 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 4 Nov 2016 21:55:50 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; Fri, 4 Nov 2016 16:55:49 -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, 4 Nov 2016 16:55:49 -0500
From: "Jakob Heitz (jheitz)" 
To: Job Snijders , Geoff Huston 
Thread-Topic: [Idr] Review of draft-ietf-large-community-06.txt
Thread-Index: AQHSNjBz6sRcMeSZxEiIR579im5tsaDIY72wgAB9DlKAAK2JAIAAA2sAgAAGW4D//8SNUA==
Date: Fri, 4 Nov 2016 21:55:49 +0000
Message-ID: <8a293ce4fc134657aa98134b5017d92e@XCH-ALN-014.cisco.com>
References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com>  <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com>  <6c5d83aa1d6a4a04b651b8f14f4b445b@XCH-ALN-014.cisco.com> <40D942F5-0710-46D1-BF09-76C827377479@cisco.com> <95F42982-7DCF-46A9-A26C-71EF70DB3C59@apnic.net> <20161104195346.GK961@Vurt.local> <20161104201631.GA35942@Vurt.lan>
In-Reply-To: <20161104201631.GA35942@Vurt.lan>
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.32.152.140]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Cc: "idr@ietf.org" 
Subject: Re: [Idr] Review of draft-ietf-large-community-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: Fri, 04 Nov 2016 21:55:54 -0000

QWxsIGdvb2QsIGV4Y2VwdCBvbmUuIFlvdSBhZGRlZDoNCg0KICAgVGhlcmUgaXMgbm8gc2lnbmlm
aWNhbmNlIHRvIHRoZSBvcmRlcg0KICAgLi4uDQogICBvZiB0aGUgQkdQIExhcmdlIENvbW11bml0
aWVzIGF0dHJpYnV0ZXMgaWYgdHdvIG9yIG1vcmUgc3VjaA0KICAgYXR0cmlidXRlcyBhcmUgZW5j
b2RlZCBpbiB0aGUgQkdQIHBhdGggYXR0cmlidXRlIHBheWxvYWQgb2YgYSBzaW5nbGUNCiAgIEJH
UCBVcGRhdGUgbWVzc2FnZS4NCg0KVGhpcyBpcyBpbiBjb25mbGljdCB3aXRoIFJGQyA3NjA2Og0K
DQogICAgICAgSWYgYW55IG90aGVyIGF0dHJpYnV0ZSAod2hldGhlcg0KICAgICAgIHJlY29nbml6
ZWQgb3IgdW5yZWNvZ25pemVkKSBhcHBlYXJzIG1vcmUgdGhhbiBvbmNlIGluIGFuIFVQREFURQ0K
ICAgICAgIG1lc3NhZ2UsIHRoZW4gYWxsIHRoZSBvY2N1cnJlbmNlcyBvZiB0aGUgYXR0cmlidXRl
IG90aGVyIHRoYW4gdGhlDQogICAgICAgZmlyc3Qgb25lIFNIQUxMIGJlIGRpc2NhcmRlZCBhbmQg
dGhlIFVQREFURSBtZXNzYWdlIHdpbGwgY29udGludWUNCiAgICAgICB0byBiZSBwcm9jZXNzZWQu
DQoNCkkgd291bGQgbGVhdmUgb3V0IGFueSBtZW50aW9uIG9mIG11bHRpcGxlIGF0dHJpYnV0ZXMu
DQpXaGF0IHRoaXMgaXMgbWVhbnQgdG8gc2F5IGlzIHRoYXQgdGhlIG9yZGVyIG9mIGNvbW11bml0
eSB2YWx1ZXMgd2l0aGluDQp0aGUgYXR0cmlidXRlIGlzIGlycmVsZXZhbnQuIEkgcHV0IHRoYXQg
aW4sIGJlY2F1c2UgaXQgaGFzIGNhdXNlZA0KY29uZnVzaW9uIGluIHRoZSBwYXN0LiBJIHdhcyB0
aGlua2luZyB0byBhZGQgdGhhdCAiYSByb3V0ZXIgbWF5IHJlb3JkZXINCnRoZSBjb21tdW5pdHkg
dmFsdWVzIHdoZW4gZm9yd2FyZGluZyB0byB0aGUgbmV4dCByb3V0ZXIiLCBiZWNhdXNlIA0KdGhp
cyBwb2ludCB3YXMgdGhlIGFjdHVhbCBzb3VyY2Ugb2YgY29uZnVzaW9uIGluIG1vcmUgdGhhbiBv
bmUgaW5zdGFuY2UuDQoNClRoYW5rcywNCkpha29iLg0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNz
YWdlLS0tLS0NCj4gRnJvbTogSWRyIFttYWlsdG86aWRyLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl
aGFsZiBPZiBKb2IgU25pamRlcnMNCj4gU2VudDogRnJpZGF5LCBOb3ZlbWJlciAwNCwgMjAxNiAx
OjE3IFBNDQo+IFRvOiBHZW9mZiBIdXN0b24gPGdpaEBhcG5pYy5uZXQ+DQo+IENjOiBpZHJAaWV0
Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtJZHJdIFJldmlldyBvZiBkcmFmdC1pZXRmLWxhcmdlLWNv
bW11bml0eS0wNi50eHQNCj4gDQo+IEhpIGV2ZXJ5b25lLA0KPiANCj4gQXR0YWNoZWQgaXMgdGhl
IHJmY2RpZmYgaHRtbCBmaWxlIHRoYXQgcmVwcmVzZW50cyB0aGUgY3VycmVudCAtMDYgLT4gLTA3
DQo+IGNoYW5nZXMgd2l0aCB0aGUgd29yayBmcm9tIEpha29iIGFuZCBHZW9mZiBhbmQgc29tZSBu
aXRzIHRoYXQgd2VyZQ0KPiBwaWNrZWQgYnkgSm9obiBTY3VkZGVyLg0KPiANCj4gSSBzaG91bGQg
bm90ZSB0aGUgZm9sbG93aW5nLCBpbiAiUmVzZXJ2ZWQgQkdQIExhcmdlIENvbW11bml0eSB2YWx1
ZXMiDQo+IHRoZSAncmVhc29ucycgYmVoaW5kIGVhY2ggcmVzZXJ2ZWQgdmFsdWUgd2VyZSByZW1v
dmVkLiBTb21lIGluIHRoZQ0KPiB3b3JraW5nIGdyb3VwIG1hZGUgYSBjYXNlIHRoYXQgaXQgY291
bGQgYmUgZ29vZCB0byBwcm92aWRlIGENCj4ganVzdGlmaWNhdGlvbiB3aGF0IG1ha2VzIHRoZXNl
IG51bWJlcnMgc3BlY2lhbC4NCj4gDQo+IE90aGVyIHRoZW4gdGhhdCwgaSBmZWVsIHRoYXQgdGhl
c2UgY2hhbmdlcyBoYXZlIGltcHJvdmVkIHRoZSBkb2N1bWVudCdzDQo+IGZsb3cgYW5kIHJlYWRh
YmlsaXR5Lg0KPiANCj4gS2luZCByZWdhcmRzLA0KPiANCj4gSm9iDQo+IA0KPiBPbiBGcmksIE5v
diAwNCwgMjAxNiBhdCAwODo1Mzo0NlBNICswMTAwLCBKb2IgU25pamRlcnMgd3JvdGU6DQo+ID4g
T24gU2F0LCBOb3YgMDUsIDIwMTYgYXQgMDY6NDE6MzJBTSArMTEwMCwgR2VvZmYgSHVzdG9uIHdy
b3RlOg0KPiA+ID4gSmFrb2IsDQo+ID4gPg0KPiA+ID4gTWFueSB0aGFua3MgZm9yIHNlbmRpbmcg
dGhpcy4NCj4gPiA+DQo+ID4gPiBJIGhhdmUgdXNlZCBXb3JkIHRvIG1hcmsgdXAgbXkgcmVhY3Rp
b25zIHRvIHRoaXMgcHJvcG9zZWQgcmV2aXNpb25zDQo+ID4gPiBmb3IgeW91ciBmdXJ0aGVyIHJl
dmlldyBhcyB0aGlzIHRvb2wgaGFzIGEgZ29vZCB0cmFjayBjaGFuZ2VzIG9wdGlvbiAtDQo+ID4g
PiB0aGUgUERGIG9mIHRoZSBtYXJrZWQgdXAgdGV4dCBpcyBhdHRhY2hlZCB0byB0aGlzIG5vdGUu
DQo+ID4gPg0KPiA+ID4gTXkgc3VnZ2VzdGVkIGNoYW5nZXMgdG8geW91ciBwcm9wb3NlZCB0ZXN0
IGFyZToNCj4gPiA+DQo+ID4gPiAxKSBjaGFuZ2UgdG8gdGhlIEludHJvZHVjdGlvbiB0byBhbHRl
ciB0aGUgZGVzY3JpcHRpb24gb2YgQ29tbXVuaXRpZXMNCj4gPiA+IHRvIGNvbmZvcm0gbW9yZSBl
eGFjdGx5IHRvIHRoZSBsYW5ndWFnZSB1c2VkIGluIFJGQyAxOTk3DQo+ID4gPg0KPiA+ID4gMikg
Y2hhbmdlIHRvIHRoZSBjb25zaWRlcmF0aW9ucyBvZiBSRkM0MzYwIGluIHRoZSBJbnRyb2R1Y3Rp
b24uIChJDQo+ID4gPiBhbHNvIG5vdGUgdGhhdCBSRkM0MzYwIGNhbGxzIHRoZSBHbG9iYWwgQWRt
aW5pc3RyYXRvciBhbmQgTG9jYWwNCj4gPiA+IEFkbWluaXN0cmF0b3IgcGFydHMgb2YgdGhlIGNv
bW11bml0eSB2YWx1ZSDigJxzdWItZmlsZWRz4oCdIHJhdGhlciB0aGFuDQo+ID4gPiDigJxmaWVs
ZHPigJ0sIHdoaWxlIHRoaXMgZHJhZnQgY2FsbHMgdGhlc2UgZWxlbWVudHMganVzdCDigJxmaWVs
ZHPigJ0gKQ0KPiA+ID4NCj4gPiA+IDMpIHRoZSBzZXQgb2YgdmFsdWVzIGlzIGV4cGxpY2l0bHkg
Y2FsbGVkIG91dCB0byBiZSDigJx1bm9yZGVyZWTigJ0gaW4gdGhlDQo+ID4gPiBJbnRyb2R1Y3Rp
b24NCj4gPiA+DQo+ID4gPiA0KSBUaGUgZGVzY3JpcHRpb24gb2YgdGhlIGF0dHJpYnV0ZSBmaWVs
ZHMgaXMgYWx0ZXJlZCB0byBiZSBjb25zaXN0ZW50DQo+ID4gPiB3aXRoIFJGQzQzNjANCj4gPiA+
DQo+ID4gPiA1KSB0aGUgdHJlYXRtZW50IG9mIHRoZSBHbG9iYWwgQWRtaW5pc3RyYXRvciB2YWx1
ZSBpcyB1bmNsZWFyLiBJIGhhdmUNCj4gPiA+IHByb3Bvc2VkIHJlbW92aW5nIHRoZSBsYXN0IHR3
byBzZW50ZW5jZXMgYW5kIHByb3Bvc2UgY2hhbmdpbmcgdGhlIE1VU1QNCj4gPiA+IHRvIGEgU0hP
VUxELCBhcywgbGF0ZXIgaW4gdGhlIGRyYWZ0IGluIFNlY3Rpb24gNiwgaXQgaXMgbm90ZWQgdGhh
dCB0aGUNCj4gPiA+IEdsb2JhbCBBZG1pbmlzdHJhdG9yIGZpZWxkIGNhbiBiZSBhbnkgdmFsdWUh
DQo+ID4gPg0KPiA+ID4gNikgSSBoYXZlIGV4cGxpY2l0bHkgY2FsbGVkIG91dCB0aGF0IHRoZSB2
YWx1ZXMgYXJlIGluIGFueSBvcmRlciwgYW5kDQo+ID4gPiBhbGxvd2VkIGZvciB0d28gb3IgbW9y
ZSBpbmRpdmlkdWFsIExhcmdlIENvbW11bml0aWVzIGF0dHJpYnV0ZXMgdG8gYmUNCj4gPiA+IGNv
bnRhaW5lZCBpbiBhIHNpbmdsZSBCR1AgVXBkYXRlIG1lc3NhZ2UsIGFnYWluIGluIGFueSBvcmRl
ci4gSWYgdGhpcw0KPiA+ID4gaXMgbm90IHlvdXIgaW50ZW50IHRoZW4geW91IHNob3VsZCBsb29r
IGF0IHRoaXMgcGFydCBvZiBzZWN0aW9uIDIgYW5kDQo+ID4gPiB0aWdodGVuIHVwIHRoZSB3b3Jk
aW5nLg0KPiA+ID4NCj4gPiA+IDcpIHlvdSBoYXZlIG5vdCBleHBsaWNpdGx5IGRpc2FtYmlndWF0
ZWQgYmV0d2VlbiBkdXBsaWNhdGUgaW5zdGFuY2VzDQo+ID4gPiBvZiB0aGUgc2FtZSBhdHRyaWJ1
dGUgYW5kIGR1cGxpY2F0ZSBpbnN0YW5jZXMgb2YgdGhlIHNhbWUgQ29tbXVuaXR5DQo+ID4gPiB2
YWx1ZS4gSSBoYXZlIG9mZmVycmVkIHNvbWUgdGV4dCB0byBjbGFyaWZ5IHRoaXMgdG8gdGhlIGxl
dmVsIG9mDQo+ID4gPiB2YWx1ZXMuDQo+ID4gPg0KPiA+ID4gOCkgSSBoYXZlIHByb3Bvc2VkIGNo
YW5naW5nIHRoZSBNVVNUIHRvIGEgU0hPVUxEIGluIHJ0aGUgY2Fub25pY2FsDQo+ID4gPiByZXBy
ZXNlbnRhdGlvbiBzZWN0aW9uDQo+ID4gPg0KPiA+ID4gOSkgVGhlIHNlbnRlbmNlcyBhYm91dCB0
aGUgdXNlIG9mIGEgY29sb24gbWFrZSBubyBzZW5zZSBnaXZlbiB0aGF0IHlvdQ0KPiA+ID4gaGF2
ZSBub3Qgc3BlY2lmaWVkIGEgY29sb24gc2VwYXJhdG9yIGluIHRoZSBwcmVjZWVkaW5nIHBhcmFn
cmFwaC4gWW91DQo+ID4gPiBwcm9iYWJseSBuZWVkIHRvIGVpdGhlciBkcm9wIHRoZSByZWZlcmVu
Y2UgdG8gdGhlIGNvbG9uLCBvciBhZGQgYQ0KPiA+ID4gY29sb24gYXMgcGFydCBvZiB0aGUgQ2Fu
b25pY2FsIFJlcHJlc2VudGF0aW9uLiBJIGhhdmUgcHJvcG9zZWQgdGhlDQo+ID4gPiBmb3JtZXIu
DQo+ID4gPg0KPiA+ID4gMTApIC0gaW4gc2VjdGlvbiA2IEkgY2hhbmdlZCB0aGUg4oCcbWF54oCd
IHRvIGEg4oCcTUFZ4oCdIC0gc2VlbWVkIGxpa2UgdGhlDQo+ID4gPiByaWdodCB0aGluZyB0byBk
by4NCj4gPiA+DQo+ID4gPiAxMSkgSSBhZGRlZCBhIHBhcmFncmFwaCBpbiB0aGUgU2VjdXJpdHkg
Q29uc2lkZXJhdGlvbnMgc2VjdGlvbg0KPiA+ID4gZXhwbGljaXRseSB0aGF0IHRoZSB2YWx1ZXMg
aW4gdGhpcyBhdHRyaWJ1dGUgYXJlIG5vdCBzcGVjaWZpY2FsbHkNCj4gPiA+IHByb3RlY3RlZCBh
bmQgdGhlbiBwb2ludGVkIHRvIEJHUCBzZWN1cml0eSAoanVzdCBiZWNhdXNlIGFuIEFTTiBpcw0K
PiA+ID4gdXNlZCBpbiBhIGNvbW11bml0eSBhdHRyaWJ1dGUsIHRoYXQgZG9lcyBub3QgbWVhbiB0
aGF0IHRoZSBBU04gaW4NCj4gPiA+IHF1ZXN0aW9uIGF0dGFjaGVkIHRoYXQgYXR0cmlidXRlLCBv
ciB0aGF0IHRoZSBBU04gd2lsbCBob25vdXIgdGhhdA0KPiA+ID4gYXR0cmlidXRlLiAtIGl0cyBq
dXN0IGEgc2lnbmFsIHdpdGhvdXQgYW55IGludGVncml0eSBwcm90ZWN0aW9uKQ0KPiA+ID4NCj4g
PiA+IDEyKSBJIGhhdmUgYWRkZWQgbXkgbmFtZSBhcyBhIHJldmlld2VyIC0gaG9wZSB0aGF04oCZ
cyBvayEgOi0pDQo+ID4gPg0KPiA+ID4gSSBfYXNzdW1lXyB0aGF0IHRoZSBhdG9taWMgYWdncmVn
YXRvciBtZXNzIHdpbGwgYmUgZml4ZWQgdXAgYnkgdGhlDQo+ID4gPiBhY3Rpb24gb2YgbWFraW5n
IHRoaXMgYW4gaGlzdG9yaWMgYXR0cmlidXRlLCBzbyBJIGhhdmUgbGVmdCB0aGUgdGV4dA0KPiA+
ID4gb24gYWdncmVnYXRpb24gdW5hbHRlcmVkLg0KPiA+ID4NCj4gPiA+IFJlZ2FyZHMsDQo+ID4g
Pg0KPiA+ID4gICBHZW9mZg0KPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4gPiBPbiA1IE5vdi4g
MjAxNiwgYXQgMToyMCBhbSwgSmFrb2IgSGVpdHogKGpoZWl0eikgPGpoZWl0ekBjaXNjby5jb20+
IHdyb3RlOg0KPiA+ID4gPg0KPiA+ID4gPiBHZW9mZiwNCj4gPiA+ID4NCj4gPiA+ID4gSGVyZSBp
cyBteSBwcm9wb3NlZCByZXZpc2lvbi4gSSBtYWRlIGFsbCB0aGUgY2hhbmdlcywgZXhjZXB0IHRo
ZSBBVE9NSUNfQUdHUkVHQVRFLiBJZiBhZnRlciB0aGUgbGF0ZXN0DQo+IGRpc2N1c3Npb24sIHlv
dSBzdGlsbCB3YW50IGl0LCBJJ2xsIG1ha2UgdGhhdCBjaGFuZ2UgdG9vLg0KPiA+ID4gPg0KPiA+
ID4gPiBUaGFua3MsDQo+ID4gPiA+IEpha29iLg0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiBC
ZWdpbiBmb3J3YXJkZWQgbWVzc2FnZToNCj4gPiA+ID4NCj4gPiA+ID4+PiAtLS0tLU9yaWdpbmFs
IE1lc3NhZ2UtLS0tLQ0KPiA+ID4gPj4+IEZyb206IElkciBbbWFpbHRvOmlkci1ib3VuY2VzQGll
dGYub3JnXSBPbiBCZWhhbGYgT2YgR2VvZmYgSHVzdG9uDQo+ID4gPiA+Pj4gU2VudDogVGh1cnNk
YXksIE5vdmVtYmVyIDAzLCAyMDE2IDU6MTQgUE0NCj4gPiA+ID4+PiBUbzogSUVURiBJRFIgV0cg
PGlkckBpZXRmLm9yZz4NCj4gPiA+ID4+PiBDYzogcnRnLWRpckBpZXRmLm9yZzsgU3VzYW4gSGFy
ZXMgPHNoYXJlc0BuZHpoLmNvbT4NCj4gPiA+ID4+PiBTdWJqZWN0OiBbSWRyXSBSZXZpZXcgb2Yg
ZHJhZnQtaWV0Zi1sYXJnZS1jb21tdW5pdHktMDYudHh0DQo+ID4gPiA+Pj4NCj4gPiA+ID4+PiBJ
IGhhdmUgcmV2aWV3ZWQgdGhpcyBkcmFmdCBhbmQgaGF2ZSB0aGUgZm9sbG93aW5nIDkgc3VnZ2Vz
dGlvbnMuIEFsbCBvZg0KPiA+ID4gPj4+IHRoZXNlIGZhbGwgaW50byB0aGUgY2F0ZWdvcnkgb2Yg
bWlub3Igc3VnZ2VzdGlvbnMuIEkgZG8gbm90IGJlbGlldmUgdGhhdA0KPiA+ID4gPj4+IHRoZXJl
IGlzIG1heSBtYWpvciBzdHJ1Y3R1cmFsIGRlZmljaWVuY3kgaW4gdGhpcyBzcGVjaWZpY2F0aW9u
LCBhbmQgdGhlDQo+ID4gPiA+Pj4gZG9jdW1lbnQgaXMgbGFyZ2VseSByZWFkeSwgaW4gbXkgdmll
dy4NCj4gPiA+ID4+Pg0KPiA+ID4gPj4+IEhlcmUgYXJlIG15IHNwZWNpZmljIHN1Z2dlc3Rpb25z
Lg0KPiA+ID4gPj4+DQo+ID4gPiA+Pj4NCj4gPiA+ID4+PiAxLiAtLS0tLS0tLS0tLS0tLS0tDQo+
ID4gPiA+Pj4NCj4gPiA+ID4+PiBUaXRsZTogTGFyZ2UgQkdQIENvbW11bml0aWVzDQo+ID4gPiA+
Pj4NCj4gPiA+ID4+PiB0byBiZSBjb25zaXN0ZW50IHdpdGggcHJldmlvdXMgYXR0cmlidXRlIHNw
ZWNpZmljYXRpb25zLCBob3cgYWJvdXQNCj4gPiA+ID4+Pg0KPiA+ID4gPj4+ICJCR1AgTGFyZ2Ug
Q29tbXVuaXRpZXMgQXR0cmlidXRlIg0KPiA+ID4gPj4+DQo+ID4gPiA+Pj4gaS5lLiBzd2l0Y2gg
dGhlIG9yZGVyIG9mICJMYXJnZSBCR1AiIHRvICJCR1AgTGFyZ2UiIHRvIGJlIGNvbnNpc3RlbnQg
d2l0aA0KPiA+ID4gPj4+IGVhcmxpZXIgQkdQIEV4dGVuZGVkIENvbW11bml0aWVzIHNwZWNpZmlj
YXRpb24gaW4gUkZDNDM2MA0KPiA+ID4gPj4+DQo+ID4gPiA+Pj4gMi4gLS0tLS0tLS0tLS0tLS0t
LQ0KPiA+ID4gPj4+DQo+ID4gPiA+Pj4gIk5ldHdvcmsgb3BlcmF0b3JzDQo+ID4gPiA+Pj4gYXR0
YWNoIEJHUCBjb21tdW5pdGllcyB0byByb3V0ZXMgdG8gaWRlbnRpZnkgaW50cmluc2ljIHByb3Bl
cnRpZXMgb2YNCj4gPiA+ID4+PiB0aGVzZSByb3V0ZXMuIg0KPiA+ID4gPj4+DQo+ID4gPiA+Pj4g
SSBkb24ndCB0aGluayBjb21tdW5pdHkgYXR0cmlidXRlcyBhcmUgYW4gaW50cmluc2ljIHByb3Bl
cnR5IG9mIGEgcm91dGUNCj4gPiA+ID4+PiBhZHZlcnRpc2VtZW50IC0gdGhleSBhcmUgbW9yZSBh
cHByb3ByaWF0ZWx5IGV4cHJlc3NlZCBhcyBhbiBhdHRhY2hlZCBhdHRyaWJ1dGUNCj4gPiA+ID4+
PiB0aGF0IGV4cHJlc3NlcyBzb21lIGRlc2lyZWQgcHJvcGVydHkuDQo+ID4gPiA+Pj4NCj4gPiA+
ID4+PiBob3cgYWJvdXQ6DQo+ID4gPiA+Pj4NCj4gPiA+ID4+PiAiTmV0d29yayBvcGVyYXRvcnMg
YXR0YWNoIEJHUCBjb21tdW5pdGllcyB0byByb3V0ZXMgdG8gYXNzb2NpYXRlDQo+ID4gPiA+Pj4g
cGFydGljdWxhciBwcm9wZXJ0aWVzIHdpdGggdGhlc2Ugcm91dGVzLiINCj4gPiA+ID4+Pg0KPiA+
ID4gPj4+IDMuIC0tLS0tLS0tLS0tLS0tLS0NCj4gPiA+ID4+Pg0KPiA+ID4gPj4+ICJhbmQgbWF5
IGFwcGx5IHRvIGFuIGluZGl2aWR1YWwgcm91dGUgb3IgdG8gYSBncm91cCBvZiByb3V0ZXMuIg0K
PiA+ID4gPj4+DQo+ID4gPiA+Pj4gSSBhbSBjb25mdXNlZCAtIHN1cmVseSB0aGUgYXR0cmlidXRl
cyBpbiBhbiBVcGRhdGUgQkdQIG1lc3NhZ2UgYXBwbHkgdG8gdGhlDQo+ID4gPiA+Pj4gY29sbGVj
dGlvbiBvZiByb3V0ZXMgY29udGFpbmVkIGluIHRoZSBVcGRhdGUuIEl0IGNhbm5vdCBiZSBhcHBs
aWVkIHRvIGENCj4gPiA+ID4+PiBzaW5nbGUgcm91dGUgd2hlbiB0aGUgdXBkYXRlIGl0c2VsZiBj
b250YWlucyBtdWx0aXBsZSByb3V0ZXMuIFdoeSBub3QNCj4gPiA+ID4+PiB1c2UgdGhlIHRleHQ6
DQo+ID4gPiA+Pj4NCj4gPiA+ID4+PiAiYW5kIGlzIGFwcGxpZWQgdG8gYWxsIHJvdXRlcyBjb250
YWluZWQgaW4gYSBCR1AgVXBkYXRlIE1lc3NhZ2Ugd2hlcmUNCj4gPiA+ID4+PiB0aGUgQ29tbXVu
aXRpZXMgQXR0cmlidXRlIGlzIGluY2x1ZGVkLiINCj4gPiA+ID4+Pg0KPiA+ID4gPj4+IDQuIC0t
LS0tLS0tLS0tLS0tLS0NCj4gPiA+ID4+Pg0KPiA+ID4gPj4+ICJbUkZDMTk5N10gQkdQIENvbW11
bml0aWVzIGF0dHJpYnV0ZXMgYXJlIGZvdXItb2N0ZXQgdmFsdWVzIHNwbGl0IGludG8NCj4gPiA+
ID4+PiB0d28gdHdvLW9jdGV0IHdvcmRzLiINCj4gPiA+ID4+Pg0KPiA+ID4gPj4+IFRoaXMgaXMg
bm90IHRoZSBjYXNlIC0gUkZDMTk5NyBzYXlzOiAiQ29tbXVuaXRpZXMgYXJlIHRyZWF0ZWQgYXMg
MzIgYml0IHZhbHVlcyINCj4gPiA+ID4+PiBJIHRoaW5rIGl0IHdvdWxkIGJlIG1vcmUgYWNjdXJh
dGUgdG8gc2F5Og0KPiA+ID4gPj4+DQo+ID4gPiA+Pj4gIkJHUCBDb21tdW5pdGllcyBhdHRyaWJ1
dGVzIGFyZSBmb3VyLW9jdGV0IHZhbHVlcyBbUkZDMTk5N10uIENvbW1vbiB1c2Ugb2YNCj4gPiA+
ID4+PiB0aGlzIGF0dHJpYnV0ZSB0eXBlIHNwbGl0cyB0aGlzIHNpbmdsZSAzMi1iaXQgdmFsdWUg
ZmllbGQgaW50byB0d28gMTYtYml0IHZhbHVlcy4iDQo+ID4gPiA+Pj4NCj4gPiA+ID4+PiA1LiAt
LS0tLS0tLS0tLS0tLS0tDQo+ID4gPiA+Pj4NCj4gPiA+ID4+PiAiVGhlIEJHUCBFeHRlbmRlZCBD
b21tdW5pdGllcw0KPiA+ID4gPj4+IGF0dHJpYnV0ZSBbUkZDNDM2MF0gaXMgYWxzbyB1bnN1aXRh
YmxlLCBhcyB0aGUgcHJvdG9jb2wgbGltaXQgb2Ygc2l4DQo+ID4gPiA+Pj4gb2N0ZXRzIGNhbm5v
dCBhY2NvbW1vZGF0ZSBib3RoIGEgZm91ci1vY3RldCBHbG9iYWwgQWRtaW5pc3RyYXRvcg0KPiA+
ID4gPj4+IHZhbHVlIGFuZCBhIGZvdXItb2N0ZXQgTG9jYWwgQWRtaW5pc3RyYXRvciB2YWx1ZSwg
d2hpY2ggcHJlY2x1ZGVzIHRoZQ0KPiA+ID4gPj4+IGNvbW1vbiBvcGVyYXRpb25hbCBwcmFjdGlj
ZSBvZiBlbmNvZGluZyBhIHRhcmdldCBBU04gaW4gdGhlIExvY2FsDQo+ID4gPiA+Pj4gQWRtaW5p
c3RyYXRvciBmaWVsZC4iDQo+ID4gPiA+Pj4NCj4gPiA+ID4+Pg0KPiA+ID4gPj4+IFRoYXRzIGEg
dmVyeSBsb25nIHNlbnRlbmNlLiBUcnk6DQo+ID4gPiA+Pj4NCj4gPiA+ID4+PiAiVGhlIEJHUCBF
eHRlbmRlZCBDb21tdW5pdGllcyBhdHRyaWJ1dGUgW1JGQzQzNjBdIGlzIGFsc28gdW5zdWl0YWJs
ZSwgYXMNCj4gPiA+ID4+PiB0aGUgcHJvdG9jb2wgbGltaXQgb2Ygc2l4IG9jdGV0cyBmb3IgZWFj
aCBjb21tdW5pdHkgdmFsdWUgY2Fubm90DQo+ID4gPiA+Pj4gYWNjb21tb2RhdGUgYm90aCBhIGZv
dXItb2N0ZXQgR2xvYmFsIEFkbWluaXN0cmF0b3IgdmFsdWUgYW5kIGEgZm91ci1vY3RldA0KPiA+
ID4gPj4+IExvY2FsIEFkbWluaXN0cmF0b3IgdmFsdWUuIFRoaXMgbGltaXRhdGlvbiBwcmVjbHVk
ZXMgdGhlIGNvbW1vbg0KPiA+ID4gPj4+IG9wZXJhdGlvbmFsIHByYWN0aWNlIG9mIGVuY29kaW5n
IGEgdGFyZ2V0IEFTTiBpbiB0aGUgTG9jYWwgQWRtaW5pc3RyYXRvcg0KPiA+ID4gPj4+IGZpZWxk
LiINCj4gPiA+ID4+Pg0KPiA+ID4gPj4+IDYuIC0tLS0tLS0tLS0tLS0tLS0NCj4gPiA+ID4+Pg0K
PiA+ID4gPj4+IFRoZSBhZ2dyZWdhdGlvbiBzZWN0aW9uIGNvbnRhaW5zIGZld2VyIGNvbnN0cmFp
bnRzIHRoZW4gZWl0aGVyIFJGQzE5OTcgb3INCj4gPiA+ID4+PiBSRkM0MzYwLiBJdCBhbHNvIGNv
bnRhaW5zIGEgY29uZnVzaW5nIG5vbi1ub3JtYXRpdmUg4oCcc2hvdWxkIi4NCj4gPiA+ID4+Pg0K
PiA+ID4gPj4+IEZvciByZWZlcmVuY2UsIFJGQzQzNjAgc3RhdGVzOiBCeSBkZWZhdWx0IGlmIGEg
cmFuZ2Ugb2Ygcm91dGVzIGlzIHRvIGJlDQo+ID4gPiA+Pj4gYWdncmVnYXRlZCBhbmQgdGhlIHJl
c3VsdGFudCBhZ2dyZWdhdGVzIHBhdGggYXR0cmlidXRlcyBkbyBub3QgY2FycnkgdGhlDQo+ID4g
PiA+Pj4gQVRPTUlDX0FHR1JFR0FURSBhdHRyaWJ1dGUsIHRoZW4gdGhlIHJlc3VsdGluZyBhZ2dy
ZWdhdGUgc2hvdWxkIGhhdmUgYW4NCj4gPiA+ID4+PiBFeHRlbmRlZCBDb21tdW5pdGllcyBwYXRo
IGF0dHJpYnV0ZSB0aGF0IGNvbnRhaW5zIHRoZSBzZXQgdW5pb24gb2YgYWxsIHRoZQ0KPiA+ID4g
Pj4+IEV4dGVuZGVkIENvbW11bml0aWVzIGZyb20gYWxsIG9mIHRoZSBhZ2dyZWdhdGVkIHJvdXRl
cy4gIFRoZSBkZWZhdWx0DQo+ID4gPiA+Pj4gYmVoYXZpb3IgY291bGQgYmUgb3ZlcnJpZGRlbiB2
aWEgbG9jYWwgY29uZmlndXJhdGlvbiwgaW4gd2hpY2ggY2FzZQ0KPiA+ID4gPj4+IGhhbmRsaW5n
IHRoZSBFeHRlbmRlZCBDb21tdW5pdGllcyBhdHRyaWJ1dGUgaW4gdGhlIHByZXNlbmNlIG9mIHJv
dXRlDQo+ID4gPiA+Pj4gYWdncmVnYXRpb24gYmVjb21lcyBhIG1hdHRlciBvZiB0aGUgbG9jYWwg
cG9saWN5IG9mIHRoZSBCR1Agc3BlYWtlciB0aGF0DQo+ID4gPiA+Pj4gcGVyZm9ybXMgdGhlIGFn
Z3JlZ2F0aW9uLg0KPiA+ID4gPj4+DQo+ID4gPiA+Pj4gV2h5IG5vdCB1c2UgdGhpcyBmb3JtdWxh
dGlvbj8gaS5lLg0KPiA+ID4gPj4+DQo+ID4gPiA+Pj4gIjMuIEFnZ3JlZ2F0aW9uDQo+ID4gPiA+
Pj4NCj4gPiA+ID4+PiBJZiBhIHNldCBvZiByb3V0ZXMgaXMgdG8gYmUgYWdncmVnYXRlZCBhbmQg
dGhlIHJlc3VsdGluZyBhZ2dyZWdhdGUgcm91dGUncw0KPiA+ID4gPj4+IHBhdGggYXR0cmlidXRl
cyBkbyBub3QgaW5jbHVkZSB0aGUgQVRPTUlDX0FHR1JFR0FURSBhdHRyaWJ1dGUsIHRoZW4gdGhl
DQo+ID4gPiA+Pj4gcmVzdWx0aW5nIGFnZ3JlZ2F0ZSByb3V0ZSBTSE9VTEQgaGF2ZSBhIExhcmdl
IENvbW11bml0aWVzIEF0dHJpYnV0ZSBmb3JtZWQNCj4gPiA+ID4+PiBmcm9tIHRoZSBzZXQgdW5p
b24gb2YgYWxsIHRoZSBMYXJnZSBDb21tdW5pdHkgdmFsdWVzIGZyb20gYWxsIG9mIHRoZQ0KPiA+
ID4gPj4+IGFnZ3JlZ2F0ZWQgc2V0IG9mIHJvdXRlcy4gIFRoaXMgYmVoYXZpb3IgTUFZIGJlIG92
ZXJyaWRkZW4gdmlhIGxvY2FsDQo+ID4gPiA+Pj4gY29uZmlndXJhdGlvbiwgaW4gd2hpY2ggY2Fz
ZSBoYW5kbGluZyB0aGUgTGFyZ2UgQ29tbXVuaXRpZXMgYXR0cmlidXRlIGluDQo+ID4gPiA+Pj4g
dGhlIHByZXNlbmNlIG9mIHJvdXRlIGFnZ3JlZ2F0aW9uIGlzIGRldGVybWluZWQgYnkgdGhlIGxv
Y2FsIHBvbGljeSBvZiB0aGUNCj4gPiA+ID4+PiBCR1Agc3BlYWtlciB0aGF0IHBlcmZvcm1zIHRo
ZSBhZ2dyZWdhdGlvbi4iDQo+ID4gPiA+Pj4NCj4gPiA+ID4+PiA3LiAtLS0tLS0tLS0tLS0tLS0t
DQo+ID4gPiA+Pj4NCj4gPiA+ID4+PiA0LiAgQ2Fub25pY2FsIFJlcHJlc2VudGF0aW9uDQo+ID4g
PiA+Pj4NCj4gPiA+ID4+PiBJIGFtIGNvbmZ1c2VkIGhlcmUgLSB0aGlzIHNlY3Rpb24gdXNlZCBh
biBleGFtcGxlIHdpdGggVFdPIGNhbm9uaWNhbA0KPiA+ID4gPj4+IHJlcHJlc2VudGF0aW9uczoN
Cj4gPiA+ID4+Pg0KPiA+ID4gPj4+ICAiRm9yIGV4YW1wbGU6IDY0NDk2OjQyOTQ5NjcyOTU6Miwg
NjQ0OTY6MDowLCBvciAoNjQ0OTYsIDExMSwgMjIyKS4iDQo+ID4gPiA+Pj4NCj4gPiA+ID4+Pg0K
PiA+ID4gPj4+IENvbnZlbnRpb25hbGx5LCBpdCdzIGJldHRlciB0byB1c2UgYSBzaW5nbGUgY2Fu
b25pY2FsIHJlcHJlc2VudGF0aW9uLCBzbyB0aGUNCj4gPiA+ID4+PiBhdXRob3JzIHNob3VsZCBw
aWNrIGVpdGhlciBhIGNvbG9uLWRlbGltaXRlZCBsaXN0LCBvciBhIGJyYWNrZXRlZCBjb21tYStz
cGFjZQ0KPiA+ID4gPj4+IHNlcGFyYXRlZCBvYmplY3QuDQo+ID4gPiA+Pj4NCj4gPiA+ID4+Pg0K
PiA+ID4gPj4+IDguIC0tLS0tLS0tLS0tLS0tLS0NCj4gPiA+ID4+Pg0KPiA+ID4gPj4+IDUuICBS
ZXNlcnZlZCBMYXJnZSBCR1AgQ29tbXVuaXR5IHZhbHVlcw0KPiA+ID4gPj4+DQo+ID4gPiA+Pj4N
Cj4gPiA+ID4+PiBUaGUgdGV4dCByZWFkczoNCj4gPiA+ID4+Pg0KPiA+ID4gPj4+ICJ0aGUgR2xv
YmFsIEFkbWluaXN0cmF0b3IgdmFsdWVzIHNwZWNpZmllZCBhYm92ZSBjb3VsZCBiZQ0KPiA+ID4g
Pj4+IHVzZWQgaWYgdGhlcmUgaXMgYSBmdXR1cmUgbmVlZCBmb3IgdGhlbS4iDQo+ID4gPiA+Pj4N
Cj4gPiA+ID4+PiBUaGlzIGlzIGVudGlyZWx5IHVuY2xlYXIuIElzIGl0IHJlZmVycmluZyB0byB0
aGUgdmFsdWVzIHRoYXQgdGhlIHByZXZpb3VzDQo+ID4gPiA+Pj4gcGFyYWdyYXBoIHNwZWNpZmll
ZCBhcyAiU0hPVUxEIE5PVCB1c2XigJ0/IEFsc28gImNvdWxkIGJlIHVzZWQiIGlzIGEgcG9vcg0K
PiA+ID4gPj4+IGNob2ljZSBvZiB3b3JkcyBmb3IgYSBub3JtYXRpdmUgc3BlY2lmaWNhdGlvbi4N
Cj4gPiA+ID4+Pg0KPiA+ID4gPj4+IEkgc3VnZ2VzdCBkZWxldGluZyBjb21wbGV0ZWx5IHRoZSBw
YXJhZ3JhcGggdGhhdCBjb250YWlucyB0aGlzIHF1b3RlIGZyb20NCj4gPiA+ID4+PiB0aGUgZG9j
dW1lbnQuDQo+ID4gPiA+Pj4NCj4gPiA+ID4+Pg0KPiA+ID4gPj4+IDkuIC0tLS0tLS0tLS0tLS0t
LS0NCj4gPiA+ID4+Pg0KPiA+ID4gPj4+IFRoZSB0ZXh0IHJlYWRzOg0KPiA+ID4gPj4+DQo+ID4g
PiA+Pj4gIlRoZSBlcnJvciBoYW5kbGluZyBvZiBMYXJnZSBCR1AgQ29tbXVuaXRpZXMgaXMgYXMg
Zm9sbG93czoNCj4gPiA+ID4+Pg0KPiA+ID4gPj4+ICBvICBBIExhcmdlIEJHUCBDb21tdW5pdGll
cyBhdHRyaWJ1dGUgU0hBTEwgYmUgY29uc2lkZXJlZCBtYWxmb3JtZWQgaWYNCj4gPiA+ID4+PiAg
ICAgaXRzIGxlbmd0aCBpcyBub3QgYSBub24temVybyBtdWx0aXBsZSBvZiAxMi4iDQo+ID4gPiA+
Pj4NCj4gPiA+ID4+Pg0KPiA+ID4gPj4+IEkgdGhpbmsgdGhlIGF1dGhvciBpcyB0cnlpbmcgdG8g
ZGF5TA0KPiA+ID4gPj4+DQo+ID4gPiA+Pj4gIlRoZSBlcnJvciBoYW5kbGluZyBvZiBMYXJnZSBC
R1AgQ29tbXVuaXRpZXMgaXMgYXMgZm9sbG93czoNCj4gPiA+ID4+Pg0KPiA+ID4gPj4+ICBvICBB
IExhcmdlIENvbW11bml0aWVzIGF0dHJpYnV0ZSBTSEFMTCBiZSBjb25zaWRlcmVkIG1hbGZvcm1l
ZCBpZiB0aGUNCj4gPiA+ID4+PiAgICBsZW5ndGggb2YgdGhlIExhcmdlIENvbW11bml0aWVzIHZh
bHVlLCBleHByZXNzZWQgaW4gb2N0ZXRzLCBpcyBub3QgYQ0KPiA+ID4gPj4+ICAgIG5vbi16ZXJv
IG11bHRpcGxlIG9mIDEyLiINCj4gPiA+ID4+Pg0KPiA+ID4gPj4+DQo+ID4gPiA+Pj4gdGhhbmtz
LA0KPiA+ID4gPj4+DQo+ID4gPiA+Pj4gR2VvZmYNCj4gPiA+ID4+Pg0KPiA+ID4gPj4+IF9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiA+Pj4gSWRy
IG1haWxpbmcgbGlzdA0KPiA+ID4gPj4+IElkckBpZXRmLm9yZw0KPiA+ID4gPj4+IGh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRyDQo+ID4gPiA+IDxkcmFmdC1pZXRmLWlk
ci1sYXJnZS1jb21tdW5pdHkueG1sPjxkcmFmdC1pZXRmLWlkci1sYXJnZS1jb21tdW5pdHktMDcu
dHh0PjxkcmFmdC1pZXRmLWlkci1sYXJnZS1jb21tdW5pdHktMDctDQo+IGRpZmYtZnJvbS0wNi5o
dG1sPg0KPiA+ID4NCj4gPg0KPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18NCj4gPiA+IElkciBtYWlsaW5nIGxpc3QNCj4gPiA+IElkckBpZXRmLm9y
Zw0KPiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZHINCj4gPg0K
PiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4g
SWRyIG1haWxpbmcgbGlzdA0KPiA+IElkckBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYu
b3JnL21haWxtYW4vbGlzdGluZm8vaWRyDQo=


From nobody Fri Nov  4 14:59:43 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2832F1294B8; Fri,  4 Nov 2016 14:59:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.018
X-Spam-Level: 
X-Spam-Status: No, score=-16.018 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=-1.497, 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 uQ-W9SYLs4tm; Fri,  4 Nov 2016 14:59:40 -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 CA9731296BF; Fri,  4 Nov 2016 14:59:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=994; q=dns/txt; s=iport; t=1478296779; x=1479506379; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=wWm6RCQFhNcdPCpMbP4hlZXa4a3OB+8zHaQmOmb2ZP8=; b=CG/rI7Ya5IzTAMgz7Xgl0jFh5O96WA1rM//VzL/OgoZrbmdmYqM3n62t V/XgVfrVIXWxLDe8ngyGNAowohWwVBQ7DX+Mi59Ao9bFg12/iXLW3PpOU MhdFms4JCUALIYA3ogKgedergQxcIRsQ1PGP+2v2hnzo44VBRgAJaMc+N M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BtAQCABB1Y/4YNJK1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgy4BAQEBAR+BVAeNMZcAlEaCCIYjAoIYPxQBAgEBAQEBAQFiKIRhAQE?= =?us-ascii?q?BBDo/DAQCAQgRBAEBHwkHMhQJCAIEAQ0FCAyIRLw1AQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBHIY/hFWEGREBhXwBBJojAZA4gXWEb4ktjSGEAwEeN2yFIXKFF4EhgQw?= =?us-ascii?q?BAQE?=
X-IronPort-AV: E=Sophos;i="5.31,445,1473120000"; d="scan'208";a="169822883"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Nov 2016 21:59:38 +0000
Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id uA4LxcXd003452 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 4 Nov 2016 21:59:39 GMT
Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 4 Nov 2016 16:59:37 -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, 4 Nov 2016 16:59:38 -0500
From: "Jakob Heitz (jheitz)" 
To: "John G. Scudder" , "draft-ietf-idr-large-community@ietf.org" 
Thread-Topic: IPR declaration needed for advancing large-community
Thread-Index: AQHSNqsEm9R9YYRZn0u4wsx/Ij0DFKDJX90Q
Date: Fri, 4 Nov 2016 21:59:38 +0000
Message-ID: <8dfe370ebdc847509aec241ceca0499c@XCH-ALN-014.cisco.com>
References: <5EEFB890-8371-4DA3-8587-D62EA9C87B8B@juniper.net>
In-Reply-To: <5EEFB890-8371-4DA3-8587-D62EA9C87B8B@juniper.net>
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.32.152.140]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: "idr@ietf.org" 
Subject: Re: [Idr] IPR declaration needed for advancing large-community
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, 04 Nov 2016 21:59:41 -0000

I have no and am not aware of any IPR related to BGP large communities.

Thanks,
Jakob.


> -----Original Message-----
> From: John G. Scudder [mailto:jgs@juniper.net]
> Sent: Friday, November 04, 2016 7:52 AM
> To: draft-ietf-idr-large-community@ietf.org
> Cc: idr@ietf.org
> Subject: IPR declaration needed for advancing large-community
>=20
> Hi Large Authors,
>=20
> As part of preparing the shepherd report, I need to answer the following =
question:
>=20
> (7) Has each author confirmed that any and all appropriate IPR disclosure=
s required for full conformance with the
> provisions of BCP 78 and BCP 79 have already been filed. If not, explain =
why?
>=20
> So: Each author listed on the front page, please confirm this for me by r=
eplying to this email. Please leave the
> working group in the cc.
>=20
> Thanks. I realize some of you have already done this earlier in the proce=
ss, and I appreciate your willingness to do
> it again.
>=20
> --John


From nobody Fri Nov  4 15:10:51 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9613E1298B7 for ; Fri,  4 Nov 2016 15:10:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.421
X-Spam-Level: 
X-Spam-Status: No, score=-3.421 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_SOFTFAIL=0.665, T_HTML_ATTACH=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 8-XLY2SNNOGR for ; Fri,  4 Nov 2016 15:10:43 -0700 (PDT)
Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (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 B76271298B2 for ; Fri,  4 Nov 2016 15:10:43 -0700 (PDT)
Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1c2mgz-000Fgf-D5 (job@us.ntt.net); Fri, 04 Nov 2016 22:10:42 +0000
Date: Fri, 4 Nov 2016 23:10:30 +0100
From: Job Snijders 
To: "Jakob Heitz (jheitz)" 
Message-ID: <20161104221030.GD37681@Vurt.lan>
References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com>  <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com>  <6c5d83aa1d6a4a04b651b8f14f4b445b@XCH-ALN-014.cisco.com> <40D942F5-0710-46D1-BF09-76C827377479@cisco.com> <95F42982-7DCF-46A9-A26C-71EF70DB3C59@apnic.net> <20161104195346.GK961@Vurt.local> <20161104201631.GA35942@Vurt.lan> <8a293ce4fc134657aa98134b5017d92e@XCH-ALN-014.cisco.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="s9fJI615cBHmzTOP"
Content-Disposition: inline
In-Reply-To: <8a293ce4fc134657aa98134b5017d92e@XCH-ALN-014.cisco.com>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.7.1 (2016-10-04)
Archived-At: 
Cc: "idr@ietf.org" 
Subject: Re: [Idr] Review of draft-ietf-large-community-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: Fri, 04 Nov 2016 22:10:48 -0000

--s9fJI615cBHmzTOP
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Fri, Nov 04, 2016 at 09:55:49PM +0000, Jakob Heitz (jheitz) wrote:
> All good, except one. You added:
> 
>    There is no significance to the order
>    ...
>    of the BGP Large Communities attributes if two or more such
>    attributes are encoded in the BGP path attribute payload of a single
>    BGP Update message.
> 
> This is in conflict with RFC 7606:
> 
>        If any other attribute (whether
>        recognized or unrecognized) appears more than once in an UPDATE
>        message, then all the occurrences of the attribute other than the
>        first one SHALL be discarded and the UPDATE message will continue
>        to be processed.
> 
> I would leave out any mention of multiple attributes.  What this is
> meant to say is that the order of community values within the
> attribute is irrelevant. I put that in, because it has caused
> confusion in the past. I was thinking to add that "a router may
> reorder the community values when forwarding to the next router",
> because this point was the actual source of confusion in more than one
> instance.

Good catch, Ignas provided text to fix it. Attached are rfcdiff & txt.

Can you double check if that confirms your understanding too with regard
to duplicate attributes & duplicate attribute values.

Kind regards,

Job

--s9fJI615cBHmzTOP
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="draft-ietf-idr-large-community-07.txt"





IDR                                                        J. Heitz, Ed.
Internet-Draft                                                     Cisco
Intended status: Standards Track                        J. Snijders, Ed.
Expires: May 8, 2017                                                 NTT
                                                                K. Patel
                                                                  Arrcus
                                                             I. Bagdonas
                                                                 Equinix
                                                             N. Hilliard
                                                                    INEX
                                                        November 4, 2016


                         BGP Large Communities
                   draft-ietf-idr-large-community-07

Abstract

   This document describes the BGP Large Communities attribute, an
   extension to BGP-4.  This attribute provides a mechanism to signal
   opaque information within separate namespaces to aid in routing
   management.  The attribute is suitable for use with four-octet
   Autonomous System Numbers.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on May 8, 2017.





Heitz, et al.              Expires May 8, 2017                  [Page 1]

Internet-Draft            BGP Large Communities            November 2016


Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  BGP Large Communities Attribute . . . . . . . . . . . . . . .   3
   3.  Aggregation . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Canonical Representation  . . . . . . . . . . . . . . . . . .   4
   5.  Reserved BGP Large Community values . . . . . . . . . . . . .   4
   6.  Error Handling  . . . . . . . . . . . . . . . . . . . . . . .   5
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   8.  Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION   5
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   10. Contributors  . . . . . . . . . . . . . . . . . . . . . . . .   6
   11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   7
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     12.1.  Normative References . . . . . . . . . . . . . . . . . .   7
     12.2.  Informative References . . . . . . . . . . . . . . . . .   7
     12.3.  URIs . . . . . . . . . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   BGP implementations typically support a routing policy language to
   control the distribution of routing information.  Network operators
   attach BGP communities to routes to associate particular properties
   with these routes.  These properties may include information such as
   the route origin location, or specification of a routing policy
   action to be taken, or one that has been taken, and is applied to all
   routes contained in a BGP Update Message where the Communities
   Attribute is included.  Because BGP communities are optional
   transitive BGP attributes, BGP communities may be acted upon or
   otherwise used by routing policies in other Autonomous Systems (ASes)
   on the Internet.




Heitz, et al.              Expires May 8, 2017                  [Page 2]

Internet-Draft            BGP Large Communities            November 2016


   BGP Communities attributes are a variable length attribute consisting
   of a set of one or more four-octet values, each of which specify a
   community [RFC1997].  Common use of the individual values of this
   attribute type split this single 32-bit value into two 16-bit values.
   The most significant word is interpreted as an Autonomous System
   Number (ASN) and the least significant word is a locally defined
   value whose meaning is assigned by the operator of the Autonomous
   System in the most significant word.

   Since the adoption of four-octet ASNs [RFC6793], the BGP Communities
   attribute can no longer accommodate the above encoding, as a two-
   octet word cannot fit a four-octet ASN.  The BGP Extended Communities
   attribute [RFC4360] is also unsuitable.  The six-octet length of the
   Extended Community value precludes the common operational practise of
   encoding four-octet ASNs in both the Global Administrator and the
   Local Administrator sub-fields.

   To address these shortcomings, this document defines a BGP Large
   Communities attribute encoded as an unordered set of one or more
   twelve-octet values, each consisting of a four-octet Global
   Administrator field and two four-octet operator-defined fields, each
   of which can be used to denote properties or actions significant to
   the operator of the Autonomous System assigning the values.

2.  BGP Large Communities Attribute

   This document creates the BGP Large Communities attribute as an
   optional transitive path attribute of variable length.  All routes
   with the BGP Large Communities attribute belong to the communities
   specified in the attribute.

   Each BGP Large Community value is encoded as a 12-octet quantity, as
   follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Global Administrator                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Local Data Part 1                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Local Data Part 2                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Global Administrator:  A four-octet namespace identifier.

   Local Data Part 1:  A four-octet operator-defined value.




Heitz, et al.              Expires May 8, 2017                  [Page 3]

Internet-Draft            BGP Large Communities            November 2016


   Local Data Part 2:  A four-octet operator-defined value.

   The Global Administrator field is intended to allow different
   Autonomous Systems to define BGP Large Communities without collision.
   This field SHOULD be either one of the reserved values as defined
   below, or an Autonomous System Number (ASN).  If it is a reserved
   value, then the Local Data Parts are as defined by the reserved
   value.  If it is an ASN then the Local Data Parts are to be
   interpreted as defined by the owner of the ASN.

   There is no significance to the order in which twelve-octet Large
   Community Attribute values are encoded in a Large Communities
   attribute, A BGP speaker can transmit them in any order.

   Duplicate BGP Large Community values SHOULD NOT be transmitted.  A
   receiving speaker SHOULD ignore duplicate BGP Large Community values
   from a BGP UPDATE message.

3.  Aggregation

   If a range of routes is aggregated, then the resulting aggregate
   should have a BGP Large Communities attribute which contains all of
   the BGP Large Communities attributes from all of the aggregated
   routes.

4.  Canonical Representation

   The canonical representation of BGP Large Communities is three
   separate unsigned integers in decimal notation in the following
   order: Global Administrator, Local Data 1, Local Data 2.  Numbers
   MUST NOT contain leading zeros; a zero value MUST be represented with
   a single zero.  Each number is separated from the next by a single
   colon.  For example: 64496:4294967295:2, 64496:0:0.

   BGP Large Communities SHOULD be represented in the canonical
   representation.

5.  Reserved BGP Large Community values

   The following Global Administrator values are reserved: 0, 65535, and
   4294967295.  Operators SHOULD NOT use these Global Administrator
   values.

   Although this document does not define any Special-Use BGP Large
   Communities, the Global Administrator values specified above could be
   used if there is a future need for them.





Heitz, et al.              Expires May 8, 2017                  [Page 4]

Internet-Draft            BGP Large Communities            November 2016


6.  Error Handling

   The error handling of BGP Large Communities is as follows:

   o  A BGP Large Communities attribute SHALL be considered malformed if
      the length of the BGP Large Communities Attribute value, expressed
      in octets, is not a non-zero multiple of 12.

   o  A BGP UPDATE message with a malformed BGP Large Communities
      attribute SHALL be handled using the approach of "treat-as-
      withdraw" as described in section 2 [RFC7606].

   The BGP Large Communities Global Administrator field MAY contain any
   value, and a BGP Large Communities attribute MUST NOT be considered
   malformed if the Global Administrator field contains an unallocated,
   unassigned or reserved ASN or is set to one of the reserved BGP Large
   Community values defined in Section 5.

7.  Security Considerations

   This extension to BGP has similar security implications as BGP
   Communities [RFC1997].

   This document does not change any underlying security issues
   associated with any other BGP Communities mechanism.  Specifically,
   an AS relying on the BGP Large Communities attribute carried in BGP
   must have trust in every other AS in the path, as any intermediate
   Autonomous System in the path may have added, deleted, or altered the
   BGP Large Communities attribute.  Specifying the mechanism to provide
   such trust is beyond the scope of this document.

   BGP Large Communities do not protect the integrity of each community
   value.  Operators should be aware that it is possible for a BGP
   speaker to alter BGP Large Community Attribute values in a BGP Update
   Message.  Protecting the integrity of the transitive handling of BGP
   Large Community attributes in a manner consistent with the intent of
   expressed BGP routing policies falls within the broader scope of
   securing BGP, and is not specifically addressed here.

   Network administrators should note the recommendations in Section 11
   of BGP Operations and Security [RFC7454].

8.  Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION

   This section records the status of known implementations of the
   protocol defined by this specification at the time of posting of this
   Internet-Draft, and is based on a proposal described in [RFC7942].
   The description of implementations in this section is intended to



Heitz, et al.              Expires May 8, 2017                  [Page 5]

Internet-Draft            BGP Large Communities            November 2016


   assist the IETF in its decision processes in progressing drafts to
   RFCs.  Please note that the listing of any individual implementation
   here does not imply endorsement by the IETF.  Furthermore, no effort
   has been spent to verify the information presented here that was
   supplied by IETF contributors.  This is not intended as, and must not
   be construed to be, a catalog of available implementations or their
   features.  Readers are advised to note that other implementations may
   exist.

   As of today these vendors have produced an implementation of BGP
   Large Communities:

   o  Cisco IOS XR

   o  ExaBGP

   o  GoBGP

   o  BIRD

   o  OpenBGPD

   o  pmacct

   o  Quagga

   The latest implementation news is tracked at
   http://largebgpcommunities.net/ [1].

9.  IANA Considerations

   IANA has made an Early Allocation of the value 32 (LARGE_COMMUNITY)
   in the "BGP Path Attributes" registry under the "Border Gateway
   Protocol (BGP) Parameters" group and is now asked to make that
   Permanent.

10.  Contributors

   The following people contributed significantly to the content of the
   document:

   John Heasley
   NTT Communications
   Email: heas@shrubbery.net

   Adam Simpson
   Nokia
   Email: adam.1.simpson@nokia.com



Heitz, et al.              Expires May 8, 2017                  [Page 6]

Internet-Draft            BGP Large Communities            November 2016


11.  Acknowledgments

   The authors would like to thank Ruediger Volk, Russ White, Acee
   Lindem, Shyam Sethuram, Jared Mauch, Joel M.  Halpern, Jeffrey Haas,
   Gunter van de Velde, Marco Marzetti, Eduardo Ascenco Reis, Mark
   Schouten, Paul Hoogsteder, Martijn Schmidt, Greg Hankins, Bertrand
   Duvivier, Barry O'Donovan, Grzegorz Janoszka, Linda Dunbar, Marco
   Davids, Gaurab Raj Upadhaya, Jeff Tantsura, Teun Vink, Adam
   Davenport, Theodore Baschak, Pier Carlo Chiodi, Nabeel Cocker, Ian
   Dickinson, Jan Baggen, Duncan Lockwood, David Farmer, Randy Bush, Wim
   Henderickx, Stefan Plug, Kay Rechthien, Rob Shakir, Warren Kumari,
   Gert Doering, Thomas King, Mikael Abrahamsson, Wesley Steehouwer,
   Sander Steffann, Brad Dreisbach, Martin Millnert, Christopher Morrow,
   Jay Borkenhagen, Arnold Nipper, Joe Provo, Niels Bakker, Bill Fenner,
   Tom Daly, Ben Maddison, Alexander Azimov, Brian Dickson, Peter van
   Dijk, Julian Seifert, Tom Petch, Tom Scholl, Arjen Zonneveld, Remco
   van Mook, Adam Chappell, Jussi Peltola, Kristian Larsson, Markus
   Hauschild, Richard Steenbergen, David Freedman, Richard Hartmann and
   Geoff Huston for their support, insightful review and comments.

12.  References

12.1.  Normative References

   [RFC1997]  Chandra, R., Traina, P., and T. Li, "BGP Communities
              Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996,
              .

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              .

   [RFC6793]  Vohra, Q. and E. Chen, "BGP Support for Four-Octet
              Autonomous System (AS) Number Space", RFC 6793,
              DOI 10.17487/RFC6793, December 2012,
              .

   [RFC7606]  Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K.
              Patel, "Revised Error Handling for BGP UPDATE Messages",
              RFC 7606, DOI 10.17487/RFC7606, August 2015,
              .

12.2.  Informative References

   [RFC4360]  Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
              Communities Attribute", RFC 4360, DOI 10.17487/RFC4360,
              February 2006, .



Heitz, et al.              Expires May 8, 2017                  [Page 7]

Internet-Draft            BGP Large Communities            November 2016


   [RFC7454]  Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations
              and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454,
              February 2015, .

   [RFC7942]  Sheffer, Y. and A. Farrel, "Improving Awareness of Running
              Code: The Implementation Status Section", BCP 205,
              RFC 7942, DOI 10.17487/RFC7942, July 2016,
              .

12.3.  URIs

   [1] http://largebgpcommunities.net

Authors' Addresses

   Jakob Heitz (editor)
   Cisco
   170 West Tasman Drive
   San Jose, CA  95054
   USA

   Email: jheitz@cisco.com


   Job Snijders (editor)
   NTT Communications
   Theodorus Majofskistraat 100
   Amsterdam  1065 SZ
   The Netherlands

   Email: job@ntt.net


   Keyur Patel
   Arrcus, Inc

   Email: keyur@arrcus.com


   Ignas Bagdonas
   Equinix
   London
   UK

   Email: ibagdona.ietf@gmail.com






Heitz, et al.              Expires May 8, 2017                  [Page 8]

Internet-Draft            BGP Large Communities            November 2016


   Nick Hilliard
   INEX
   4027 Kingswood Road
   Dublin  24
   IE

   Email: nick@inex.ie












































Heitz, et al.              Expires May 8, 2017                  [Page 9]

--s9fJI615cBHmzTOP
Content-Type: text/html; charset=us-ascii
Content-Disposition: attachment; filename="draft-ietf-idr-large-community-07-from-6.diff.html"

 
 

 
 
 
 
 
 
   
   
  Diff: draft-ietf-idr-large-community-06.txt - draft-ietf-idr-large-community-07.txt 
   
 
 
  
 
  
 draft-ietf-idr-large-community-06.txt   draft-ietf-idr-large-community-07.txt 
 
      
 

      
IDR                                                        J. Heitz, Ed. IDR                                                        J. Heitz, Ed.

      
Internet-Draft                                                     Cisco Internet-Draft                                                     Cisco

      
Intended status: Standards Track                        J. Snijders, Ed. Intended status: Standards Track                        J. Snijders, Ed.

      

      
Expires: May 2, 2017                                                 NTT Expires: May 8, 2017                                                 NTT

      
                                                                K. Patel                                                                 K. Patel

      
                                                                  Arrcus                                                                   Arrcus

      
                                                             I. Bagdonas                                                              I. Bagdonas

      
                                                                 Equinix                                                                  Equinix

      

      
                                                              A. Simpson 

      
                                                                   Nokia 

      
                                                             N. Hilliard                                                              N. Hilliard

      
                                                                    INEX                                                                     INEX

      

      
                                                        October 29, 2016                                                         November 4, 2016

      
 

      

      
                         Large BGP Communities                          BGP Large Communities

      
                   draft-ietf-idr-large-community-06                    draft-ietf-idr-large-community-07

      
 

      
Abstract Abstract

      
 

      

      
   This document describes the Large BGP Communities attribute, an    This document describes the BGP Large Communities attribute, an

      
   extension to BGP-4.  This attribute provides a mechanism to signal    extension to BGP-4.  This attribute provides a mechanism to signal

      
   opaque information within separate namespaces to aid in routing    opaque information within separate namespaces to aid in routing

      

      
   management.  The attribute is suitable for use with four-octet ASNs.    management.  The attribute is suitable for use with four-octet

      
    Autonomous System Numbers.

      
 

      
Requirements Language Requirements Language

      
 

      
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

      
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this

      
   document are to be interpreted as described in [RFC2119].    document are to be interpreted as described in [RFC2119].

      
 

      
Status of This Memo Status of This Memo

      
 

      
   This Internet-Draft is submitted in full conformance with the    This Internet-Draft is submitted in full conformance with the

      
 

      
skipping to change at page 1, line 48 skipping to change at page 1, line 47

      
   Internet-Drafts are working documents of the Internet Engineering    Internet-Drafts are working documents of the Internet Engineering

      
   Task Force (IETF).  Note that other groups may also distribute    Task Force (IETF).  Note that other groups may also distribute

      
   working documents as Internet-Drafts.  The list of current Internet-    working documents as Internet-Drafts.  The list of current Internet-

      
   Drafts is at http://datatracker.ietf.org/drafts/current/.    Drafts is at http://datatracker.ietf.org/drafts/current/.

      
 

      
   Internet-Drafts are draft documents valid for a maximum of six months    Internet-Drafts are draft documents valid for a maximum of six months

      
   and may be updated, replaced, or obsoleted by other documents at any    and may be updated, replaced, or obsoleted by other documents at any

      
   time.  It is inappropriate to use Internet-Drafts as reference    time.  It is inappropriate to use Internet-Drafts as reference

      
   material or to cite them other than as "work in progress."    material or to cite them other than as "work in progress."

      
 

      

      
   This Internet-Draft will expire on May 2, 2017.    This Internet-Draft will expire on May 8, 2017.

      
 

      
Copyright Notice Copyright Notice

      
 

      
   Copyright (c) 2016 IETF Trust and the persons identified as the    Copyright (c) 2016 IETF Trust and the persons identified as the

      
   document authors.  All rights reserved.    document authors.  All rights reserved.

      
 

      
   This document is subject to BCP 78 and the IETF Trust's Legal    This document is subject to BCP 78 and the IETF Trust's Legal

      
   Provisions Relating to IETF Documents    Provisions Relating to IETF Documents

      
   (http://trustee.ietf.org/license-info) in effect on the date of    (http://trustee.ietf.org/license-info) in effect on the date of

      
   publication of this document.  Please review these documents    publication of this document.  Please review these documents

      
   carefully, as they describe your rights and restrictions with respect    carefully, as they describe your rights and restrictions with respect

      
   to this document.  Code Components extracted from this document must    to this document.  Code Components extracted from this document must

      
   include Simplified BSD License text as described in Section 4.e of    include Simplified BSD License text as described in Section 4.e of

      
   the Trust Legal Provisions and are provided without warranty as    the Trust Legal Provisions and are provided without warranty as

      
   described in the Simplified BSD License.    described in the Simplified BSD License.

      
 

      
Table of Contents Table of Contents

      
 

      
   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2

      

      
   2.  Large BGP Communities Attribute . . . . . . . . . . . . . . .   3    2.  BGP Large Communities Attribute . . . . . . . . . . . . . . .   3

      
   3.  Aggregation . . . . . . . . . . . . . . . . . . . . . . . . .   4    3.  Aggregation . . . . . . . . . . . . . . . . . . . . . . . . .   4

      
   4.  Canonical Representation  . . . . . . . . . . . . . . . . . .   4    4.  Canonical Representation  . . . . . . . . . . . . . . . . . .   4

      

      
   5.  Reserved Large BGP Community values . . . . . . . . . . . . .   4    5.  Reserved BGP Large Community values . . . . . . . . . . . . .   4

      
   6.  Error Handling  . . . . . . . . . . . . . . . . . . . . . . .   4    6.  Error Handling  . . . . . . . . . . . . . . . . . . . . . . .   5

      
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   5    7.  Security Considerations . . . . . . . . . . . . . . . . . . .   5

      
   8.  Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION   5    8.  Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION   5

      
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6    9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6

      
   10. Contributors  . . . . . . . . . . . . . . . . . . . . . . . .   6    10. Contributors  . . . . . . . . . . . . . . . . . . . . . . . .   6

      

      
   11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   6    11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   7

      
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .   7    12. References  . . . . . . . . . . . . . . . . . . . . . . . . .   7

      
     12.1.  Normative References . . . . . . . . . . . . . . . . . .   7      12.1.  Normative References . . . . . . . . . . . . . . . . . .   7

      
     12.2.  Informative References . . . . . . . . . . . . . . . . .   7      12.2.  Informative References . . . . . . . . . . . . . . . . .   7

      
     12.3.  URIs . . . . . . . . . . . . . . . . . . . . . . . . . .   8      12.3.  URIs . . . . . . . . . . . . . . . . . . . . . . . . . .   8

      
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8    Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

      
 

      
1.  Introduction 1.  Introduction

      
 

      
   BGP implementations typically support a routing policy language to    BGP implementations typically support a routing policy language to

      
   control the distribution of routing information.  Network operators    control the distribution of routing information.  Network operators

      

      
   attach BGP communities to routes to identify intrinsic properties of    attach BGP communities to routes to associate particular properties

      
   these routes.  These properties may include information such as the    with these routes.  These properties may include information such as

      
   route origin location, or specification of a routing policy action to    the route origin location, or specification of a routing policy

      
   be taken, or one that has been taken, and may apply to an individual    action to be taken, or one that has been taken, and is applied to all

      
   route or to a group of routes.  Because BGP communities are optional    routes contained in a BGP Update Message where the Communities

      
    Attribute is included.  Because BGP communities are optional

      
   transitive BGP attributes, BGP communities may be acted upon or    transitive BGP attributes, BGP communities may be acted upon or

      
   otherwise used by routing policies in other Autonomous Systems (ASes)    otherwise used by routing policies in other Autonomous Systems (ASes)

      
   on the Internet.    on the Internet.

      
 

      

      
   [RFC1997] BGP Communities attributes are four-octet values split into    BGP Communities attributes are a variable length attribute consisting

      
   two two-octet words.  The most significant word is interpreted as an    of a set of one or more four-octet values, each of which specify a

      
   Autonomous System Number (ASN) and the least significant word is a    community [RFC1997].  Common use of the individual values of this

      
   locally defined value whose meaning is assigned by the operator of    attribute type split this single 32-bit value into two 16-bit values.

      
   the Autonomous System in the most significant word.    The most significant word is interpreted as an Autonomous System

      
    Number (ASN) and the least significant word is a locally defined

      
    value whose meaning is assigned by the operator of the Autonomous

      
    System in the most significant word.

      
 

      
   Since the adoption of four-octet ASNs [RFC6793], the BGP Communities    Since the adoption of four-octet ASNs [RFC6793], the BGP Communities

      
   attribute can no longer accommodate the above encoding, as a two-    attribute can no longer accommodate the above encoding, as a two-

      
   octet word cannot fit a four-octet ASN.  The BGP Extended Communities    octet word cannot fit a four-octet ASN.  The BGP Extended Communities

      

      
   attribute [RFC4360] is also unsuitable, as the protocol limit of six    attribute [RFC4360] is also unsuitable.  The six-octet length of the

      
   octets cannot accommodate both a four-octet Global Administrator    Extended Community value precludes the common operational practise of

      
   value and a four-octet Local Administrator value, which precludes the    encoding four-octet ASNs in both the Global Administrator and the

      
   common operational practice of encoding a target ASN in the Local    Local Administrator sub-fields.

      
   Administrator field. 

      
 

      

      
   To address these shortcomings, this document defines a Large BGP    To address these shortcomings, this document defines a BGP Large

      
   Communities attribute encoded as one or more twelve-octet values,    Communities attribute encoded as an unordered set of one or more

      
   each consisting of a four-octet Global Administrator field and two    twelve-octet values, each consisting of a four-octet Global

      
   four-octet operator-defined fields, each of which can be used to    Administrator field and two four-octet operator-defined fields, each

      
   denote properties or actions significant to the operator of the    of which can be used to denote properties or actions significant to

      
   Autonomous System assigning the values.    the operator of the Autonomous System assigning the values.

      
 

      

      
2.  Large BGP Communities Attribute 2.  BGP Large Communities Attribute

      
 

      

      
   This document creates the Large BGP Communities attribute as an    This document creates the BGP Large Communities attribute as an

      
   optional transitive path attribute of variable length.  All routes    optional transitive path attribute of variable length.  All routes

      

      
   with the Large BGP Communities attribute belong to the community    with the BGP Large Communities attribute belong to the communities

      
   specified in the attribute.    specified in the attribute.

      
 

      

      
   The attribute consists of one or more twelve-octet values.  Each    Each BGP Large Community value is encoded as a 12-octet quantity, as

      
   twelve-octet Large BGP Communities value represents three four-octet    follows:

      
   values, as follows: 

      
 

      
    0                   1                   2                   3     0                   1                   2                   3

      
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

      
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      
   |                      Global Administrator                     |    |                      Global Administrator                     |

      
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      
   |                       Local Data Part 1                       |    |                       Local Data Part 1                       |

      
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      
   |                       Local Data Part 2                       |    |                       Local Data Part 2                       |

      
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      
 

      

      
   Global Administrator:  A four-octet namespace identifier.  This    Global Administrator:  A four-octet namespace identifier.

      
      SHOULD be an Autonomous System Number. 

      
 

      
   Local Data Part 1:  A four-octet operator-defined value.    Local Data Part 1:  A four-octet operator-defined value.

      
 

      
   Local Data Part 2:  A four-octet operator-defined value.    Local Data Part 2:  A four-octet operator-defined value.

      
 

      
   The Global Administrator field is intended to allow different    The Global Administrator field is intended to allow different

      

      
   Autonomous Systems to define Large BGP Communities without collision.    Autonomous Systems to define BGP Large Communities without collision.

      
   Implementations MUST allow the operator to specify any value for the    This field SHOULD be either one of the reserved values as defined

      
   Global Administrator field.    below, or an Autonomous System Number (ASN).  If it is a reserved

      
    value, then the Local Data Parts are as defined by the reserved

      
    value.  If it is an ASN then the Local Data Parts are to be

      
    interpreted as defined by the owner of the ASN.

      
 

      

      
   There is no significance to the order in which Large BGP Communities    There is no significance to the order in which twelve-octet Large

      
   are encoded in the BGP path attribute payload.  A BGP speaker can    Community Attribute values are encoded in a Large Communities

      
   transmit them in any order.    attribute, A BGP speaker can transmit them in any order.

      
 

      

      
   Duplicate Large BGP Communities SHOULD NOT be transmitted.  A    Duplicate BGP Large Community values SHOULD NOT be transmitted.  A

      
   receiving speaker SHOULD silently remove duplicate Large BGP    receiving speaker SHOULD ignore duplicate BGP Large Community values

      
   Communities from a BGP UPDATE message.    from a BGP UPDATE message.

      
 

      
3.  Aggregation 3.  Aggregation

      
 

      
   If a range of routes is aggregated, then the resulting aggregate    If a range of routes is aggregated, then the resulting aggregate

      

      
   should have a Large BGP Communities attribute which contains all of    should have a BGP Large Communities attribute which contains all of

      
   the Large BGP Communities attributes from all of the aggregated    the BGP Large Communities attributes from all of the aggregated

      
   routes.    routes.

      
 

      
4.  Canonical Representation 4.  Canonical Representation

      
 

      

      
   Large BGP Communities MUST be represented as three separate unsigned    The canonical representation of BGP Large Communities is three

      
   integers in decimal notation in the following order: Global    separate unsigned integers in decimal notation in the following

      
   Administrator, Local Data 1, Local Data 2.  Numbers MUST NOT contain    order: Global Administrator, Local Data 1, Local Data 2.  Numbers

      
   leading zeros; a zero value MUST be represented with a single zero.    MUST NOT contain leading zeros; a zero value MUST be represented with

      
   For example: 64496:4294967295:2, 64496:0:0, or (64496, 111, 222).    a single zero.  Each number is separated from the next by a single

      
    colon.  For example: 64496:4294967295:2, 64496:0:0.

      
 

      

      
5.  Reserved Large BGP Community values    BGP Large Communities SHOULD be represented in the canonical

      
    representation.

      
 

      

      
   The following Global Administrator values are reserved: 0 (the first 5.  Reserved BGP Large Community values

      
   ASN) [RFC7607], 65535 (UINT16_MAX) and 4294967295 (the last ASN)                                                                          

      
   [RFC7300].  Operators SHOULD NOT use these Global Administrator    The following Global Administrator values are reserved: 0, 65535, and

      
    4294967295.  Operators SHOULD NOT use these Global Administrator

      
   values.    values.

      
 

      

      
   Although this document does not define any Special-Use Large BGP    Although this document does not define any Special-Use BGP Large

      
   Communities, the Global Administrator values specified above could be    Communities, the Global Administrator values specified above could be

      
   used if there is a future need for them.    used if there is a future need for them.

      
 

      
6.  Error Handling 6.  Error Handling

      
 

      

      
   The error handling of Large BGP Communities is as follows:    The error handling of BGP Large Communities is as follows:

      
 

      

      
   o  A Large BGP Communities attribute SHALL be considered malformed if    o  A BGP Large Communities attribute SHALL be considered malformed if

      
      its length is not a non-zero multiple of 12.       the length of the BGP Large Communities Attribute value, expressed

      
       in octets, is not a non-zero multiple of 12.

      
 

      

      
   o  A BGP UPDATE message with a malformed Large BGP Communities    o  A BGP UPDATE message with a malformed BGP Large Communities

      
      attribute SHALL be handled using the approach of "treat-as-       attribute SHALL be handled using the approach of "treat-as-

      
      withdraw" as described in section 2 [RFC7606].       withdraw" as described in section 2 [RFC7606].

      
 

      

      
   The Large BGP Communities Global Administrator field may contain any    The BGP Large Communities Global Administrator field MAY contain any

      
   value, and a Large BGP Communities attribute MUST NOT be considered    value, and a BGP Large Communities attribute MUST NOT be considered

      
   malformed if the Global Administrator field contains an unallocated,    malformed if the Global Administrator field contains an unallocated,

      

      
   unassigned or reserved ASN or is set to one of the reserved Large BGP    unassigned or reserved ASN or is set to one of the reserved BGP Large

      
   Community values defined in Section 5.    Community values defined in Section 5.

      
 

      
7.  Security Considerations 7.  Security Considerations

      
 

      
   This extension to BGP has similar security implications as BGP    This extension to BGP has similar security implications as BGP

      
   Communities [RFC1997].    Communities [RFC1997].

      
 

      
   This document does not change any underlying security issues    This document does not change any underlying security issues

      
   associated with any other BGP Communities mechanism.  Specifically,    associated with any other BGP Communities mechanism.  Specifically,

      

      
   an AS relying on the Large BGP Communities attribute carried in BGP    an AS relying on the BGP Large Communities attribute carried in BGP

      
   must have trust in every other AS in the path, as any intermediate    must have trust in every other AS in the path, as any intermediate

      
   Autonomous System in the path may have added, deleted, or altered the    Autonomous System in the path may have added, deleted, or altered the

      

      
   Large BGP Communities attribute.  Specifying the mechanism to provide    BGP Large Communities attribute.  Specifying the mechanism to provide

      
   such trust is beyond the scope of this document.    such trust is beyond the scope of this document.

      
 

      

      
    BGP Large Communities do not protect the integrity of each community

      
    value.  Operators should be aware that it is possible for a BGP

      
    speaker to alter BGP Large Community Attribute values in a BGP Update

      
    Message.  Protecting the integrity of the transitive handling of BGP

      
    Large Community attributes in a manner consistent with the intent of

      
    expressed BGP routing policies falls within the broader scope of

      
    securing BGP, and is not specifically addressed here.

      
                                                                          

      
   Network administrators should note the recommendations in Section 11    Network administrators should note the recommendations in Section 11

      
   of BGP Operations and Security [RFC7454].    of BGP Operations and Security [RFC7454].

      
 

      
8.  Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 8.  Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION

      
 

      
   This section records the status of known implementations of the    This section records the status of known implementations of the

      
   protocol defined by this specification at the time of posting of this    protocol defined by this specification at the time of posting of this

      
   Internet-Draft, and is based on a proposal described in [RFC7942].    Internet-Draft, and is based on a proposal described in [RFC7942].

      
   The description of implementations in this section is intended to    The description of implementations in this section is intended to

      
   assist the IETF in its decision processes in progressing drafts to    assist the IETF in its decision processes in progressing drafts to

      
   RFCs.  Please note that the listing of any individual implementation    RFCs.  Please note that the listing of any individual implementation

      
   here does not imply endorsement by the IETF.  Furthermore, no effort    here does not imply endorsement by the IETF.  Furthermore, no effort

      
   has been spent to verify the information presented here that was    has been spent to verify the information presented here that was

      
   supplied by IETF contributors.  This is not intended as, and must not    supplied by IETF contributors.  This is not intended as, and must not

      
   be construed to be, a catalog of available implementations or their    be construed to be, a catalog of available implementations or their

      
   features.  Readers are advised to note that other implementations may    features.  Readers are advised to note that other implementations may

      
   exist.    exist.

      
 

      

      
   As of today these vendors have produced an implementation of Large    As of today these vendors have produced an implementation of BGP

      
   BGP Communities:    Large Communities:

      
 

      
   o  Cisco IOS XR    o  Cisco IOS XR

      
 

      
   o  ExaBGP    o  ExaBGP

      

      
                                                                          

      
   o  GoBGP    o  GoBGP

      
 

      
   o  BIRD    o  BIRD

      
 

      
   o  OpenBGPD    o  OpenBGPD

      
 

      
   o  pmacct    o  pmacct

      
 

      
   o  Quagga    o  Quagga

      
 

      
 

      
skipping to change at page 6, line 31 skipping to change at page 6, line 47

      
   Protocol (BGP) Parameters" group and is now asked to make that    Protocol (BGP) Parameters" group and is now asked to make that

      
   Permanent.    Permanent.

      
 

      
10.  Contributors 10.  Contributors

      
 

      
   The following people contributed significantly to the content of the    The following people contributed significantly to the content of the

      
   document:    document:

      
 

      
   John Heasley    John Heasley

      
   NTT Communications    NTT Communications

      

      
                                                                          

      
   Email: heas@shrubbery.net    Email: heas@shrubbery.net

      
 

      

      
    Adam Simpson

      
    Nokia

      
    Email: adam.1.simpson@nokia.com

      
                                                                          

      
11.  Acknowledgments 11.  Acknowledgments

      
 

      
   The authors would like to thank Ruediger Volk, Russ White, Acee    The authors would like to thank Ruediger Volk, Russ White, Acee

      
   Lindem, Shyam Sethuram, Jared Mauch, Joel M.  Halpern, Jeffrey Haas,    Lindem, Shyam Sethuram, Jared Mauch, Joel M.  Halpern, Jeffrey Haas,

      
   Gunter van de Velde, Marco Marzetti, Eduardo Ascenco Reis, Mark    Gunter van de Velde, Marco Marzetti, Eduardo Ascenco Reis, Mark

      
   Schouten, Paul Hoogsteder, Martijn Schmidt, Greg Hankins, Bertrand    Schouten, Paul Hoogsteder, Martijn Schmidt, Greg Hankins, Bertrand

      
   Duvivier, Barry O'Donovan, Grzegorz Janoszka, Linda Dunbar, Marco    Duvivier, Barry O'Donovan, Grzegorz Janoszka, Linda Dunbar, Marco

      
   Davids, Gaurab Raj Upadhaya, Jeff Tantsura, Teun Vink, Adam    Davids, Gaurab Raj Upadhaya, Jeff Tantsura, Teun Vink, Adam

      
   Davenport, Theodore Baschak, Pier Carlo Chiodi, Nabeel Cocker, Ian    Davenport, Theodore Baschak, Pier Carlo Chiodi, Nabeel Cocker, Ian

      
   Dickinson, Jan Baggen, Duncan Lockwood, David Farmer, Randy Bush, Wim    Dickinson, Jan Baggen, Duncan Lockwood, David Farmer, Randy Bush, Wim

      
   Henderickx, Stefan Plug, Kay Rechthien, Rob Shakir, Warren Kumari,    Henderickx, Stefan Plug, Kay Rechthien, Rob Shakir, Warren Kumari,

      
   Gert Doering, Thomas King, Mikael Abrahamsson, Wesley Steehouwer,    Gert Doering, Thomas King, Mikael Abrahamsson, Wesley Steehouwer,

      
   Sander Steffann, Brad Dreisbach, Martin Millnert, Christopher Morrow,    Sander Steffann, Brad Dreisbach, Martin Millnert, Christopher Morrow,

      
   Jay Borkenhagen, Arnold Nipper, Joe Provo, Niels Bakker, Bill Fenner,    Jay Borkenhagen, Arnold Nipper, Joe Provo, Niels Bakker, Bill Fenner,

      
   Tom Daly, Ben Maddison, Alexander Azimov, Brian Dickson, Peter van    Tom Daly, Ben Maddison, Alexander Azimov, Brian Dickson, Peter van

      
   Dijk, Julian Seifert, Tom Petch, Tom Scholl, Arjen Zonneveld, Remco    Dijk, Julian Seifert, Tom Petch, Tom Scholl, Arjen Zonneveld, Remco

      
   van Mook, Adam Chappell, Jussi Peltola, Kristian Larsson, Markus    van Mook, Adam Chappell, Jussi Peltola, Kristian Larsson, Markus

      

      
   Hauschild, Richard Steenbergen, David Freedman, Richard Hartmann for    Hauschild, Richard Steenbergen, David Freedman, Richard Hartmann and

      
   their support, insightful review and comments.    Geoff Huston for their support, insightful review and comments.

      
 

      
12.  References 12.  References

      
 

      
12.1.  Normative References 12.1.  Normative References

      
 

      
   [RFC1997]  Chandra, R., Traina, P., and T. Li, "BGP Communities    [RFC1997]  Chandra, R., Traina, P., and T. Li, "BGP Communities

      
              Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996,               Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996,

      
              <http://www.rfc-editor.org/info/rfc1997>.               <http://www.rfc-editor.org/info/rfc1997>.

      
 

      
   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate

      
 

      
skipping to change at page 7, line 36 skipping to change at page 8, line 5

      
              Patel, "Revised Error Handling for BGP UPDATE Messages",               Patel, "Revised Error Handling for BGP UPDATE Messages",

      
              RFC 7606, DOI 10.17487/RFC7606, August 2015,               RFC 7606, DOI 10.17487/RFC7606, August 2015,

      
              <http://www.rfc-editor.org/info/rfc7606>.               <http://www.rfc-editor.org/info/rfc7606>.

      
 

      
12.2.  Informative References 12.2.  Informative References

      
 

      
   [RFC4360]  Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended    [RFC4360]  Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended

      
              Communities Attribute", RFC 4360, DOI 10.17487/RFC4360,               Communities Attribute", RFC 4360, DOI 10.17487/RFC4360,

      
              February 2006, <http://www.rfc-editor.org/info/rfc4360>.               February 2006, <http://www.rfc-editor.org/info/rfc4360>.

      
 

      

      
   [RFC7300]  Haas, J. and J. Mitchell, "Reservation of Last Autonomous 

      
              System (AS) Numbers", BCP 6, RFC 7300, 

      
              DOI 10.17487/RFC7300, July 2014, 

      
              <http://www.rfc-editor.org/info/rfc7300>. 

      
                                                                          

      
   [RFC7454]  Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations    [RFC7454]  Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations

      
              and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454,               and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454,

      
              February 2015, <http://www.rfc-editor.org/info/rfc7454>.               February 2015, <http://www.rfc-editor.org/info/rfc7454>.

      
 

      

      
   [RFC7607]  Kumari, W., Bush, R., Schiller, H., and K. Patel, 

      
              "Codification of AS 0 Processing", RFC 7607, 

      
              DOI 10.17487/RFC7607, August 2015, 

      
              <http://www.rfc-editor.org/info/rfc7607>. 

      
                                                                          

      
   [RFC7942]  Sheffer, Y. and A. Farrel, "Improving Awareness of Running    [RFC7942]  Sheffer, Y. and A. Farrel, "Improving Awareness of Running

      
              Code: The Implementation Status Section", BCP 205,               Code: The Implementation Status Section", BCP 205,

      
              RFC 7942, DOI 10.17487/RFC7942, July 2016,               RFC 7942, DOI 10.17487/RFC7942, July 2016,

      
              <http://www.rfc-editor.org/info/rfc7942>.               <http://www.rfc-editor.org/info/rfc7942>.

      
 

      
12.3.  URIs 12.3.  URIs

      
 

      
   [1] http://largebgpcommunities.net    [1] http://largebgpcommunities.net

      
 

      
Authors' Addresses Authors' Addresses

      
 

      
skipping to change at page 9, line 4 skipping to change at page 9, line 4

      
   Arrcus, Inc    Arrcus, Inc

      
 

      
   Email: keyur@arrcus.com    Email: keyur@arrcus.com

      
 

      
   Ignas Bagdonas    Ignas Bagdonas

      
   Equinix    Equinix

      
   London    London

      
   UK    UK

      
 

      
   Email: ibagdona.ietf@gmail.com    Email: ibagdona.ietf@gmail.com

      

      
   Adam Simpson 

      
   Nokia 

      
   600 March Road 

      
   Ottawa  Ontario K2K 2E6 

      
   Canada 

      
 

      
   Email: adam.1.simpson@nokia.com 

      
                                                                          

      
   Nick Hilliard    Nick Hilliard

      
   INEX    INEX

      
   4027 Kingswood Road    4027 Kingswood Road

      
   Dublin  24    Dublin  24

      
   IE    IE

      
 

      
   Email: nick@inex.ie    Email: nick@inex.ie


     
 

     
 End of changes. 43 change blocks. 

     
95 lines changed or deleted 96 lines changed or added

     

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ 

   

   
   

--s9fJI615cBHmzTOP--


From nobody Fri Nov  4 15:52:54 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17EA6129952 for ; Fri,  4 Nov 2016 15:52:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.018
X-Spam-Level: 
X-Spam-Status: No, score=-16.018 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=-1.497, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable 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 1wlMPjCdFtmy for ; Fri,  4 Nov 2016 15:52:50 -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 C8B6712986D for ; Fri,  4 Nov 2016 15:44:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2197; q=dns/txt; s=iport; t=1478299498; x=1479509098; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=G0l7dkEZrMNWQ822k9N0gUYOeL17MXs6f5ncGYc5n3o=; b=AiYbDqORuDe7doJvNmDsHua9mVjl+2heJyumBqmvw2jQdc44ak9199zz /0df6Rw+mw/QtjbynmFvBTVtJFGeDvPUFce97e2qUN+YHkGf2ygYHfnBM YF7M6WXpfZ8uGEnVkPUZs186+N7spA9Nl2wHFLGLIWK4F5uHOkQ8RMlAK o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAQCVDh1Y/4cNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgy4BAQEBAR+BVAeNMZcAlEaCCIYjAoIYPxQBAgEBAQEBAQFiKIR?= =?us-ascii?q?hAQEBBDo/DAQCAQgRBAEBAR4JBzIUCQgCBA4FCAyIRLw/AQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBHIY/hFWKJwWaIwGJPoZ6gXWOHIcphXiEAwEeN2yFIXKFCAaBKoE?= =?us-ascii?q?MAQEB?=
X-IronPort-AV: E=Sophos;i="5.31,445,1473120000"; d="scan'208";a="165759022"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Nov 2016 22:44:57 +0000
Received: from XCH-RCD-015.cisco.com (xch-rcd-015.cisco.com [173.37.102.25]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id uA4MivMw024231 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 4 Nov 2016 22:44:57 GMT
Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-015.cisco.com (173.37.102.25) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 4 Nov 2016 17:44:57 -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, 4 Nov 2016 17:44:57 -0500
From: "Jakob Heitz (jheitz)" 
To: Job Snijders 
Thread-Topic: [Idr] Review of draft-ietf-large-community-06.txt
Thread-Index: AQHSNjBz6sRcMeSZxEiIR579im5tsaDIY72wgAB9DlKAAK2JAIAAA2sAgAAGW4D//8SNUIAAW0wA//+1BgA=
Date: Fri, 4 Nov 2016 22:44:57 +0000
Message-ID: <0919e676e12d49d1a2ba30f4acc3b273@XCH-ALN-014.cisco.com>
References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com>  <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com>  <6c5d83aa1d6a4a04b651b8f14f4b445b@XCH-ALN-014.cisco.com> <40D942F5-0710-46D1-BF09-76C827377479@cisco.com> <95F42982-7DCF-46A9-A26C-71EF70DB3C59@apnic.net> <20161104195346.GK961@Vurt.local> <20161104201631.GA35942@Vurt.lan> <8a293ce4fc134657aa98134b5017d92e@XCH-ALN-014.cisco.com> <20161104221030.GD37681@Vurt.lan>
In-Reply-To: <20161104221030.GD37681@Vurt.lan>
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.32.152.140]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: "idr@ietf.org" 
Subject: Re: [Idr] Review of draft-ietf-large-community-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: Fri, 04 Nov 2016 22:52:52 -0000

There has been enough confusion about whether it's the value or the attribu=
te.
Change this:

   Duplicate BGP Large Community values SHOULD NOT be transmitted.  A
   receiving speaker SHOULD ignore duplicate BGP Large Community values
   from a BGP UPDATE message.

to this:

   Duplicate BGP Large Community values SHOULD NOT be transmitted.  A
   receiving speaker SHOULD silently remove duplicate BGP Large Community
   values from a BGP Large Community attribute.

Thanks,
Jakob.


> -----Original Message-----
> From: Job Snijders [mailto:job@ntt.net]
> Sent: Friday, November 04, 2016 3:11 PM
> To: Jakob Heitz (jheitz) 
> Cc: Geoff Huston ; idr@ietf.org
> Subject: Re: [Idr] Review of draft-ietf-large-community-06.txt
>=20
> On Fri, Nov 04, 2016 at 09:55:49PM +0000, Jakob Heitz (jheitz) wrote:
> > All good, except one. You added:
> >
> >    There is no significance to the order
> >    ...
> >    of the BGP Large Communities attributes if two or more such
> >    attributes are encoded in the BGP path attribute payload of a single
> >    BGP Update message.
> >
> > This is in conflict with RFC 7606:
> >
> >        If any other attribute (whether
> >        recognized or unrecognized) appears more than once in an UPDATE
> >        message, then all the occurrences of the attribute other than th=
e
> >        first one SHALL be discarded and the UPDATE message will continu=
e
> >        to be processed.
> >
> > I would leave out any mention of multiple attributes.  What this is
> > meant to say is that the order of community values within the
> > attribute is irrelevant. I put that in, because it has caused
> > confusion in the past. I was thinking to add that "a router may
> > reorder the community values when forwarding to the next router",
> > because this point was the actual source of confusion in more than one
> > instance.
>=20
> Good catch, Ignas provided text to fix it. Attached are rfcdiff & txt.
>=20
> Can you double check if that confirms your understanding too with regard
> to duplicate attributes & duplicate attribute values.
>=20
> Kind regards,
>=20
> Job


From nobody Fri Nov  4 16:05:44 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 151031299D5 for ; Fri,  4 Nov 2016 16:05:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.432
X-Spam-Level: 
X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_SOFTFAIL=0.665] 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 dA7d5NEB2lbK for ; Fri,  4 Nov 2016 16:05:42 -0700 (PDT)
Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (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 7A43E1299D7 for ; Fri,  4 Nov 2016 16:05:41 -0700 (PDT)
Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1c2nYJ-0004m4-Cf (job@us.ntt.net); Fri, 04 Nov 2016 23:05:40 +0000
Date: Sat, 5 Nov 2016 00:05:36 +0100
From: Job Snijders 
To: "Jakob Heitz (jheitz)" 
Message-ID: <20161104230536.GJ37681@Vurt.lan>
References: <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com>  <6c5d83aa1d6a4a04b651b8f14f4b445b@XCH-ALN-014.cisco.com> <40D942F5-0710-46D1-BF09-76C827377479@cisco.com> <95F42982-7DCF-46A9-A26C-71EF70DB3C59@apnic.net> <20161104195346.GK961@Vurt.local> <20161104201631.GA35942@Vurt.lan> <8a293ce4fc134657aa98134b5017d92e@XCH-ALN-014.cisco.com> <20161104221030.GD37681@Vurt.lan> <0919e676e12d49d1a2ba30f4acc3b273@XCH-ALN-014.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <0919e676e12d49d1a2ba30f4acc3b273@XCH-ALN-014.cisco.com>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.7.1 (2016-10-04)
Archived-At: 
Cc: "idr@ietf.org" 
Subject: Re: [Idr] Review of draft-ietf-large-community-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: Fri, 04 Nov 2016 23:05:43 -0000

On Fri, Nov 04, 2016 at 10:44:57PM +0000, Jakob Heitz (jheitz) wrote:
> There has been enough confusion about whether it's the value or the attribute.
> Change this:
> 
>    Duplicate BGP Large Community values SHOULD NOT be transmitted.  A
>    receiving speaker SHOULD ignore duplicate BGP Large Community values
>    from a BGP UPDATE message.
> 
> to this:
> 
>    Duplicate BGP Large Community values SHOULD NOT be transmitted.  A
>    receiving speaker SHOULD silently remove duplicate BGP Large Community
>    values from a BGP Large Community attribute.

Thanks Jakob, this is helpful. I've updated the XML in github.

Kind regards,

Job


From nobody Sat Nov  5 03:29:13 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23E14129688 for ; Sat,  5 Nov 2016 03:29:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.718
X-Spam-Level: 
X-Spam-Status: No, score=-5.718 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, RP_MATCHES_RCVD=-1.497, 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 J4r78m7R4A6H for ; Sat,  5 Nov 2016 03:29:10 -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 30758129675 for ; Sat,  5 Nov 2016 03:29:10 -0700 (PDT)
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 CZS75684; Sat, 05 Nov 2016 10:29:07 +0000 (GMT)
Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Sat, 5 Nov 2016 10:29:07 +0000
Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Sat, 5 Nov 2016 18:28:58 +0800
From: Zhuangshunwan 
To: "idr@ietf.org" 
Thread-Topic: [Idr] Review of draft-ietf-large-community-06.txt
Thread-Index: AQHSNtOFwS3wa5eAwkW/x/SKbM7wb6DItooAgAAGXICAABu+gIAABBoAgAAJoICAAAXFAIABO1Bw
Date: Sat, 5 Nov 2016 10:28:58 +0000
Message-ID: <19AB2A007F56DB4E8257F949A2FB9858C87AFC6E@NKGEML515-MBX.china.huawei.com>
References: <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com>  <6c5d83aa1d6a4a04b651b8f14f4b445b@XCH-ALN-014.cisco.com> <40D942F5-0710-46D1-BF09-76C827377479@cisco.com> <95F42982-7DCF-46A9-A26C-71EF70DB3C59@apnic.net> <20161104195346.GK961@Vurt.local> <20161104201631.GA35942@Vurt.lan> <8a293ce4fc134657aa98134b5017d92e@XCH-ALN-014.cisco.com> <20161104221030.GD37681@Vurt.lan> <0919e676e12d49d1a2ba30f4acc3b273@XCH-ALN-014.cisco.com> <20161104230536.GJ37681@Vurt.lan>
In-Reply-To: <20161104230536.GJ37681@Vurt.lan>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.86.254]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.581DB474.0023, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: d8daaf6d9f8b6e413243f5c8ab079b5c
Archived-At: 
Subject: Re: [Idr] Review of draft-ietf-large-community-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: Sat, 05 Nov 2016 10:29:12 -0000

Hi authors,

I have read this document and it looks good to me!

One comment:

In most of the network operating systems, we must enable neighbor/peer send=
-community command knob in order BGP speaker include community in routes an=
nouncement.=20
By default, the BGP speaker does not send/transmit community attributes. Ev=
en if the COMMUNITIES path attribute is an optional transitive attribute. T=
his is the current reality application.

So the following case describing in draft-ietf-idr-large-community-06 maybe=
 cannot reflect the reality:
   "Because BGP communities are optional
   transitive BGP attributes, BGP communities may be acted upon or
   otherwise used by routing policies in other Autonomous Systems (ASes)
   on the Internet."

Some customers from IDC/OTT complain that ISPs can not transmit their commu=
nity attributes, because ISPs do not transmit community attributes in most =
cases.

Should we clearly define whether LargeCommunity should act different from (=
or the same with) the RFC1997's Community?

Best Regards,
Shunwan


From nobody Sat Nov  5 03:35:34 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54444129704 for ; Sat,  5 Nov 2016 03:35:32 -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, 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 s11DI3b1K027 for ; Sat,  5 Nov 2016 03:35:30 -0700 (PDT)
Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c: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 8EC89129766 for ; Sat,  5 Nov 2016 03:35:30 -0700 (PDT)
Received: by mail-wm0-x234.google.com with SMTP id t79so92957920wmt.0 for ; Sat, 05 Nov 2016 03:35:30 -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=JIgKyq8ojN1ZnFsLHDMJuIquKt94QZs85mGr5JGi+IA=; b=Ugo7nFik63A9wYxuYIZ60qGPbAssJUzv91oFzcLc+uz9uf6F5Q8Pgt/UaW9Q7Ci2Sm PKE0fRW7fe690flzlnjE5i2KBos3wXZDIy7fH394SThsTP2K45mAlS3dDzblZKSlOxqi 3EUHmyEDEIFAP7IQn1I+uttOVkUEWk22gqF7G6U1o15ZIJQLFfzOXgVk+vH337l+3n3E m2kmmfycxn2PJqXqLSLn8NNDPh5H2rdcKsHo1bCIbTXUZAnuqcirx+3DQq0JSDgGw9R2 GAmVEgwqfyafVNukXYNo7QvabNYmpgjgcSGuZn32Oy72HRB+CvUhczCFE0q867gNLjPl lwyw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=JIgKyq8ojN1ZnFsLHDMJuIquKt94QZs85mGr5JGi+IA=; b=i9nthnEz9/Y8SP796RGDVMLac27WgJMPGLGyVADYCOX56Zg00Em78b6OVer4vrT9MC CUauaZ+Iy/yPr4NQfRLevw/M18ayjL/hfebG/Io84xkO8OD5e3NIrzRnNSX1j2/63OC+ lSA34y0LbFLmGXywB4RzBmQ58khl947NofYdPkxBpI6akMYWXGfVTVFKZyqAoE077v/L UFKu60YVAMdg+ghzxjPwEOPV85mYyTbDoTUkmz/zDfqTvLyGePtyw3zSHfuCla17w983 TEUA3O35QKo9+xpCNXg3vjfT4FoelghQF7J3OmSuTYn6w7EDK0d57E0FSIp5XPkJzepp JOaQ==
X-Gm-Message-State: ABUngvfUpvET8DLzeNg6uFA7s/EqGEn3eis7bULZP9qFv5YzDSAACaGSPb36F3sv1tGo4g==
X-Received: by 10.194.235.7 with SMTP id ui7mr15116231wjc.66.1478342128893; Sat, 05 Nov 2016 03:35:28 -0700 (PDT)
Received: from localhost ([188.206.66.42]) by smtp.gmail.com with ESMTPSA id ym3sm19011445wjc.6.2016.11.05.03.35.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 05 Nov 2016 03:35:28 -0700 (PDT)
Date: Sat, 5 Nov 2016 11:35:26 +0100
From: Job Snijders 
To: Zhuangshunwan 
Message-ID: <20161105103526.GM952@Vurt.local>
References: <6c5d83aa1d6a4a04b651b8f14f4b445b@XCH-ALN-014.cisco.com> <40D942F5-0710-46D1-BF09-76C827377479@cisco.com> <95F42982-7DCF-46A9-A26C-71EF70DB3C59@apnic.net> <20161104195346.GK961@Vurt.local> <20161104201631.GA35942@Vurt.lan> <8a293ce4fc134657aa98134b5017d92e@XCH-ALN-014.cisco.com> <20161104221030.GD37681@Vurt.lan> <0919e676e12d49d1a2ba30f4acc3b273@XCH-ALN-014.cisco.com> <20161104230536.GJ37681@Vurt.lan> <19AB2A007F56DB4E8257F949A2FB9858C87AFC6E@NKGEML515-MBX.china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <19AB2A007F56DB4E8257F949A2FB9858C87AFC6E@NKGEML515-MBX.china.huawei.com>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.7.1 (2016-10-04)
Archived-At: 
Cc: "idr@ietf.org" 
Subject: Re: [Idr] Review of draft-ietf-large-community-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: Sat, 05 Nov 2016 10:35:32 -0000

On Sat, Nov 05, 2016 at 10:28:58AM +0000, Zhuangshunwan wrote:
> I have read this document and it looks good to me!

Thank you for the kind words!

> One comment:
> 
> In most of the network operating systems, we must enable neighbor/peer
> send-community command knob in order BGP speaker include community in
> routes announcement. 
> By default, the BGP speaker does not send/transmit community
> attributes. Even if the COMMUNITIES path attribute is an optional
> transitive attribute. This is the current reality application.

Then change your default!

> So the following case describing in draft-ietf-idr-large-community-06
> maybe cannot reflect the reality:
>
>    "Because BGP communities are optional transitive BGP attributes,
>    BGP communities may be acted upon or otherwise used by routing
>    policies in other Autonomous Systems (ASes) on the Internet."
> 
> Some customers from IDC/OTT complain that ISPs can not transmit their
> community attributes, because ISPs do not transmit community
> attributes in most cases.

I find it hard to make or accept quantative statements in this context,
I know some ISP that scrub all communities, and I know some ISPs that
pass on as much communities as possible. The market will decide.

> Should we clearly define whether LargeCommunity should act different
> from (or the same with) the RFC1997's Community?

I consider it a feature that the behaviour is exactly aligned with
RFC1997 communities. Some OTT operators might desire slightly different
behaviour, but that is really a commercial dicussion outside of IETF
scope. 

Thanks for the feedback.

Kind regards,

Job


From nobody Sat Nov  5 10:18:44 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C25C612942F for ; Sat,  5 Nov 2016 10:18:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level: 
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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 sjMlupUoJFsJ for ; Sat,  5 Nov 2016 10:18:39 -0700 (PDT)
Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21CB8129400 for ; Sat,  5 Nov 2016 10:18:39 -0700 (PDT)
Received: by mail-wm0-x22e.google.com with SMTP id p190so107523579wmp.1 for ; Sat, 05 Nov 2016 10:18:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=gRvwT3e6LjCEl0q0lwrdXGb39L3WOuAL9N81kUTdI/I=; b=XDn4bW+tJX0Lod+G+3bgsqZK7LJ1GxAynrLImer+z1LF0haIaOHVz9YUWdj8gsSfVJ 3mqquBlMSBbenJyLthYCklvJxor6L9/8GPTWs8ezhnMKrXmg9sWfK1g1yem8tRDAGs3K 36wrAwmnXbAubEkEqK0GbyIYLwyxVClQqp8lY3VbThIEcWyn8Q5GzimY+6RhUp8cEtpw tmj+3aSamSJS4rKFxkAjSV0Op1kOui7ml//SnzVkwIZKKI9Hv9UdU4iNfOzT5PEnAL1Y q221BTIngctGT6tu0PMe9t3TKpJIjmyeR9iJg1Klz/2NJYijq5NzSZZYvHNamf3HpZjJ uWPQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=gRvwT3e6LjCEl0q0lwrdXGb39L3WOuAL9N81kUTdI/I=; b=jdR55CXH7EwOROoYRDHOkHFAeJR4uOQ8XCXOBRrVFTyP1+ir4bOsPEkrnD0Jxn1dF0 bGR+pkH6femwBLy5ITocb3H1w+S2PNurO9+gOCGT7hlaMeYLpp5RSwXOl88iraGtCQvm 14rufa9EzlJnD9iJ/Um+e+ZQtLFf52mvLsU5Q2J+iJHl2q0y1ZF9j7RnBe1uzkvYWMwU zJoRQ0cCrdUGtP0T/Ln5v4AevScj3VGiD/yIIhgaro11VoFBLvOzoA0sNLHXX2ZXlmoI Pip/r7UX0NbZWbZV3ZDDa2/VGR/i32kaCVWlhRiR5NTW21HwxXtLvsXx89de95J3XdwF HaqQ==
X-Gm-Message-State: ABUngvfKtY6A8WcMGgGyYRxww19BAoWCMKot/wHx5uWambAJ8u2A5zibhPvpZfYCntIP8CDWaAZqm8UYcLH/pw==
X-Received: by 10.28.46.15 with SMTP id u15mr2367514wmu.61.1478366317720; Sat, 05 Nov 2016 10:18:37 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.80.137.69 with HTTP; Sat, 5 Nov 2016 10:18:36 -0700 (PDT)
In-Reply-To: <20161105103526.GM952@Vurt.local>
References: <6c5d83aa1d6a4a04b651b8f14f4b445b@XCH-ALN-014.cisco.com> <40D942F5-0710-46D1-BF09-76C827377479@cisco.com> <95F42982-7DCF-46A9-A26C-71EF70DB3C59@apnic.net> <20161104195346.GK961@Vurt.local> <20161104201631.GA35942@Vurt.lan> <8a293ce4fc134657aa98134b5017d92e@XCH-ALN-014.cisco.com> <20161104221030.GD37681@Vurt.lan> <0919e676e12d49d1a2ba30f4acc3b273@XCH-ALN-014.cisco.com> <20161104230536.GJ37681@Vurt.lan> <19AB2A007F56DB4E8257F949A2FB9858C87AFC6E@NKGEML515-MBX.china.huawei.com> <20161105103526.GM952@Vurt.local>
From: Robert Raszuk 
Date: Sat, 5 Nov 2016 18:18:36 +0100
X-Google-Sender-Auth: TSbNUJDDROQvGk3kSslaPldZdjM
Message-ID: 
To: Job Snijders 
Content-Type: multipart/alternative; boundary=001a1142532c373dad054090fbe3
Archived-At: 
Cc: "idr@ietf.org" 
Subject: Re: [Idr] Review of draft-ietf-large-community-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: Sat, 05 Nov 2016 17:18:41 -0000

--001a1142532c373dad054090fbe3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Job,

> By default, the BGP speaker does not send/transmit community
> > attributes. Even if the COMMUNITIES path attribute is an optional
> > transitive attribute. This is the current reality application.
>
> *=E2=80=8B=E2=80=8BThen change your default!*
>

=E2=80=8BAre you making a recommendation here =E2=80=8Bthat BGP implementat=
ions should now
be modified to send BGP communities to EBGP (and obviously IBGP) peers by
default ?

Do you mean that only for large communities or also for standards and
extended communities ?

I think Shunwan's point is very valid and it seems by making above
recommendation to modify the BGP implementations default you agree with it.
If so draft should reflect this as this is no longer market nor EBGP peers
agreement.

Thx,
R.

--001a1142532c373dad054090fbe3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Job,

> By default, the BGP speaker does not send/tran=
smit community

> attributes. Even if the COMMUNITIES path attribute is an optional

> transitive attribute. This is the current reality application.




=E2=80=8B=E2=80=8B
Then change your default!

=E2=80=8BAre you making a recommendation here =E2=80=8Bthat BGP =
implementations should now be modified to send BGP communities to EBGP (and=
 obviously IBGP) peers by default ?=C2=A0

<=
/font>
Do you mean that only for large communities or =
also for standards and extended communities ?=C2=A0

I think=C2=A0Shunwan's point is very valid and it seems by making above re=
commendation to modify the BGP implementations default you agree with it. I=
f so draft should reflect this as this is no longer market nor EBGP peers a=
greement.=C2=A0

Thx,
R.




--001a1142532c373dad054090fbe3--


From nobody Sat Nov  5 10:27:30 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D848129A85 for ; Sat,  5 Nov 2016 10:27:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, WEIRD_PORT=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 Iymnhnv2wuos for ; Sat,  5 Nov 2016 10:27:25 -0700 (PDT)
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0098.outbound.protection.outlook.com [104.47.34.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6C7E129A84 for ; Sat,  5 Nov 2016 10:27:25 -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=/OaaHo463TEm0mom2bLG9S0gAvEP2iGOtzCD2lirWZM=; b=E3VpKBzyQE6d7OEbG5bAnF542XsZwZylzEpX3I49ns+kxcwMGQfmNltPHEjnb1H14/Iv2T/FWhkfVZZ/NA7MwO+/Bu+63HbKYmM41PkIG0wgbdM4coiJp+wbqa6s/ohDOHt8AZbvQm8Q+4s75PWsMBacIJgo4FEDSX+U3bDgurg=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; 
Received: from [172.29.33.22] (66.129.241.11) by CY1PR05MB2506.namprd05.prod.outlook.com (10.167.10.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.679.5; Sat, 5 Nov 2016 17:27:24 +0000
From: "John G. Scudder" 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Message-ID: <576FE282-CBBA-4411-9E99-EAEAAD57C573@juniper.net>
Date: Sat, 5 Nov 2016 13:27:20 -0400
To: 
MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Mailer: Apple Mail (2.3124)
X-Originating-IP: [66.129.241.11]
X-ClientProxiedBy: BN6PR20CA0017.namprd20.prod.outlook.com (10.173.158.155) To CY1PR05MB2506.namprd05.prod.outlook.com (10.167.10.27)
X-MS-Office365-Filtering-Correlation-Id: 39adccc9-a83d-49d0-b843-08d405a10201
X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2506; 2:ULeQLQiriJzhf2tpMZMBMfP9pfKymIKQQPLqnApWrp78SLGxikUj5LfArXeF+f8fbXlr9eRQOfIEsWAIhozwPaDirRMu3LkYrBm1wYwfH87LGAIStWugDQ016woLnOgGOzjDhhwsTXKe/9og7jjW2t53RTtBQ/E+SgVj+1H2XF638NAIlqp2DFC72cCOPpkVHlj+MaRHyPFb+oAzghsQMQ==; 3:AS9FZ4JbYUSkP2Mq3447RvLOdsSyC0TEmUinmJvyP4+kFnyfvKq10BQOWN+zCEvdgWm1cPxf6DOIWfjAQ8NbbBVfF01LXvmaf3UKvwGf/OthCVNfRYHMA/8rIteEeIroEnM3u6ehEy3fngC9lzs+5g==; 25:VyngtLQgxTdgH8h6T4s1QZvA+nFAeQMMe4LfDKQ85XQu9RF+int1b3jPOpxSphjxCvIvBtgWXkHRU2LV8ZNXLn+5e7UmfTgYfFGLZwmARA+C5T33euJ5JFOqUeYVr3nV/W5V3O7i/eA48+8rvddCsMts9Q6GW20SmIOpaAJbeiZLWwtNLPEv9iK9qB2qnuTvef7IheQzMffsMrPCjArRnvDLkZ9+GD5r53oQXDJfWrVXJXzO6CoFAL+muDBwbYlX2KEzornI98mMqwTGg1jlGJXVpcXmvxvH9EZEF7pAUe1T8UXzOKMasbMjRozZFeealcDHvahXgebQotPp6A/ogu8rARgbVQ5S9ym5gki9NPbi/8yDdF3Fd4XruJsEAXJZQ5Xz7v+mI8rD7gOg/XD35PV3nJLYBep6NN/yUUGAIUhVp+F/oM6kdTN0joFIy+Ru
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR05MB2506;
X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2506; 31:32KK67nbA5qQlBH+XfHCea483mjXiHjQws1IIURSyWOyoQ13eW+ol5vM4i8jLRWhYPlOJmgK6Y5WNFyZ8iz/O+17Q5ATE0KH4kkdxJ6PlZvk53s4hqnHUScg4leN0GG7Cmtje4p6xCznaqEW03JV8Wa1N68S0F0QzfMxbM6ZRGTDS2z/F10Ne9nRQ7mK+MGA8fKwJXV/ajAXBW+rJq/VxpQA72vXSDtUg+PXI3n5cS3c5WmXWqnLQBqzofidljSi; 20:rZpKF2O+0X6UmKw/NSEx20lrwiq0cOkvt1l6zIMJkW1raPKPO4frtU7pPJfaJb/wbM7h5Vb61htEhDgy46gVWnpWga4FfppjHc18D3Sa+va7iNEzOCPoF3+pwbf2+pUIN+7kOJczNhkfEwvHnT1cYWZCF+cGc8oXfsUr50oGUtqvvVnBmmw0FaM6xRAxpr7eMUtU8uqalOKayDEyqvfVnwfvpsUWXgJJfCcTV6FdIIe0+XOM0YYUiFvPgCy3lVjMkCVIgjl8186dFB6FYVtf9MVm+sT82a3xQMGWtPAAQ7XTuqzs8PWeGspxswH7qa+PL0B7lgPQhbhAIlzEKO277vLnIlVBbPwXSD/l+YRLJ6ka+dvAG+dda81TXb67Q+2n0Mr1rsNoqi/iW39kw8VFoPwxA0zvSQecZsSVI9kSV0vcZ4ODxgwJh6VeSgYY4ctFcp9xnwZyAM9fn99QbSPDLnfLCX386kGHi/e9br+0e4yoWBWanmEWGlhTOjp9liOr6c7qRxi3EEC9Tli/eqlFQjWRHxtd3M+lxm5N/vH+D8hG2lQsCKuWJSVt1f58txtRUPMCQfw40KKSUDHIav3zqMQjThliS7lUWbH9OwJquns=
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:CY1PR05MB2506; BCL:0; PCL:0; RULEID:; SRVR:CY1PR05MB2506; 
X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2506; 4:iJrjp6W1lKK/we+ztwELyq+2OASQnboYtwNIWuI8hlaPJa1i0CJwX+LOh8+zOUnpT1cO/YzhCt8i8gq3KE7tbgIUW+rNdJLX2CoHC49X9hHhfShwYbMuJq1RI9eBxZgGM1TNPsYA9gWrtNoFDnwAccoDNXzWAKDAWaHzGTlZVC4FHf6or1MIGaxsIep+YIO00NBhz3qrVSmfxdiJBzGikf3uNWWmpByGNX86W0IxxV1VsuMXwcOJgMkPGaLwY5a0N9FdAV+mGfUwyY4oXvULAOf91xP0aKRRQ7ppxl7Sf6hQapkK3O4UhbyWX3Si7Q0gwL/hF5is0TqGIy0je7o5HpDM6ZCbd6t93Ui75xPY+oOSCWFKenCT6r1VZ91lCEhWA56VzHjf0y8+HdJzKRxVNm9Bhw9J94JePQcB0ee8uQs=
X-Forefront-PRVS: 011787B9DD
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(7916002)(279900001)(199003)(53754006)(51874003)(189002)(57306001)(101416001)(86362001)(7846002)(42186005)(2351001)(7736002)(83716003)(81156014)(23726003)(305945005)(97736004)(8676002)(3846002)(6916009)(110136003)(19580405001)(82746002)(8746002)(81166006)(6666003)(50466002)(6116002)(36756003)(46406003)(189998001)(105586002)(97756001)(19580395003)(586003)(229853001)(106356001)(50226002)(92566002)(450100001)(77096005)(5660300001)(2906002)(68736007)(66066001)(47776003)(19625305001)(15975445007)(33656002)(50986999)(107886002)(42262002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2506; H:[172.29.33.22]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR05MB2506; 23:sINtxiLhNP2gMs+4nknC6xw/JKo75a526HAqrYhIz?= =?us-ascii?Q?mWLxtNCnAG79XSbKOEWuy2mcuVJJAubSUhgYWLyK87tAbb1lmt0Gc1rerNIz?= =?us-ascii?Q?yRAiDQM4iug4xCMK1vGjYhE1OMcyJtWlZhzq6A/7UE2p/sLUXKjhyhGY16OE?= =?us-ascii?Q?ri2VB8cI9xfctQDcqIWTPHKmPlk/Wlpj7py2an4RwWYY/UHQnxiS9DTURJCk?= =?us-ascii?Q?3fq7cnv5TiDxp3sSLVX+oedFiA6SXpYLlkNKVi7qBnRJQ0WrjqMUqnwYrhxf?= =?us-ascii?Q?lvIpYGVRE44+haJDRMyk+tIo203ty80HGWBbflx1DKoOItqwDfdeRsjaKkxy?= =?us-ascii?Q?2ZJYSHqLQ9zyX+7e3Cs2maIAloeMPXhF/cU5gN6TEQ89NawBZ4NyZYAW6StC?= =?us-ascii?Q?KZFto6JjAyiOswvGkmXhjUmRibESqFp5z3j5a00XZM7vVTqZfCYpMvzcYcSQ?= =?us-ascii?Q?FXCRACmqpfi6QgN/KRAg9EpOwGDATpInXkBRPX7c/e7tULtxEhEa0MCmZbbZ?= =?us-ascii?Q?ayCWqxsMZ1XkHCBWXdIbSWkwgeUsbshE1linyQbLYRPuY/yBVB+JHXV55wop?= =?us-ascii?Q?XdJIsP28nOKnecTuV5wrxZgLgB2a4n4Mg1u7ysGJosUKeHerjVERXzNKEjHH?= =?us-ascii?Q?3uXDMhtc0x/UfK5mCS1XeyidDf0jNQtffFy+P9iSCPJkB7v5YDVw+UbkAxpt?= =?us-ascii?Q?Sy+AMDPjXp+fWykNlf6CV1WRFENCnoWVtqIr++vgjANQMGthST8LzeFrt8gU?= =?us-ascii?Q?rJs4s5jXUWD8XzkgGk8pElRGFvWBccgaMkJRaU4wMxFMoG+duI/bUJQtyTw6?= =?us-ascii?Q?g2Ke+bvQpabSF9Sl6UkiO45BykJ3LT/hZJnqF1/9NfSjs0aob3lUnNDzNfZ6?= =?us-ascii?Q?dLPxumClp21hcDwMdN1kF9BnAvqQ9PPSQoA6vFH7x4OHcfLlIjkAlAHjqIWY?= =?us-ascii?Q?EIbsPBc6vlCE/qVHmGvLdsr3lq/IDCJOG8NfXBShg/bRswTsyNVFbmd8UaO1?= =?us-ascii?Q?r0uJDkTBJZ1RSR2vCr/NaehMQNlYWitevJHdLwlvMqQoRJGFldlNIMm1swoD?= =?us-ascii?Q?FnidALgaU1oT27qT3WrIiAMDPVFRu9Q7+QWb8b4CIB7cwY84MRpAyo/BSLVA?= =?us-ascii?Q?TCKJEtxjiETj/1mowthG7bd2fX6qhpIdEmSBZBSi8IXdSzJMBM/qVOSqMXAX?= =?us-ascii?Q?vr6ci+9NNG9dnNBGvSCMvh+mRS2OOoZy8sdXoAMUf2zifEmPT7d7gtLszM5B?= =?us-ascii?Q?xnJAqqXMHZJ48MfP6AdOMoV3LCgdaJrdvI4q15NTzMhzG5oFuLFJXA6/n4b3?= =?us-ascii?Q?UgnaY7QBaTTSDNj33TmtBhnHh3uYgzDnEjBRCoIOimF9DQ8NZSFpw5y87Z94?= =?us-ascii?Q?WwGVQ=3D=3D?=
X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2506; 6:H6U5piRw52fqft69EQY/hRUOnMg/QEuDkrnZ19om3macibSOSn2JBxTR87z60RcSwMdTnOsOde2zUgM6Kr+IaJjJuaUghlqn9ipPVy/+9Fw6uUhc88Pea1xWoc9pvr/kUvrgVn1mS0Sv6d6F2KbN4Lgih14yy6L8TR0pxqEVP0M6i1b9ilfaYy89a3S/GV25dnbhpx4H24Qmy/nMHgFDW6xN7q6NGRVz/IN14IOdQibdI780EDuieXUuhmni8ODFJlF/I09FG07ITldOqP7WlHK2A6txlPGhkfopk1a42gSakz5g5LdlE6icb587taVEw8e/cwcq1iw6CuHuzalhEJeqXK9dtzIKX/5J3H58Zqo=; 5:fAGflgG96kuiDXMPxveL6Zk38mtqWYwseoL793C7L5VDp5OVes8pMsk4fJWFB7NZe1UA70V0Lr3fVB1Licel4Svdnf0XauOBxLf3JvyFJvI7O4G/5GuLerCeIdrZjdxWmkcJmWwW5dxv0M5EdfAHRO4ygRAyPhef8Vc8uuUKyHo=; 24:dcXjYW/8mfIifD8GREr2xkuQTMvvGlKaRfhPl3Uo+YA2mInCxloB1BplgmlflrmKYA+t0bxuBSZRfZwUd6DzLwvj2ANMOwMS7zYweTtmCW0=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2506; 7:/H7FsG1UKzHx5YYoQt/IVzeCgwxDD76+iYaI3P8issJ1rfjvX/BLqIvgHJKvnwjVWihcL8+jCkIKhTcV/JxFixM5gIrz6fHKXzAlFLqMUwkSmUQ4eZzKgczP/hySHZ5fbXshQk7uelYHNMrGv4CtnOdUirHvKRsFSgjZJAah5b+xCdd2Qj9YbgSkH/VsSbZmgnamijt7Lov5ODCJcfnxPnjD2WlV3vOaBRtVTipCruKEl6v9aMHnb8ASC35J1YOxiwfpey5a36ZREAIweX7v1cXy1Rf2qi2e6fh7BFOqzYn6udXiTNN6y4rCtzx4/PQBbE4yoSWtGC/F9R5R1KJ7AcqRI4ewyby+mwa1oGsvu4E=
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Nov 2016 17:27:24.4210 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2506
Archived-At: 
Subject: [Idr] IETF-97 IDR meeting logistics, first call for volunteers
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, 05 Nov 2016 17:27:28 -0000

Hi Everybody,

In case you hadn't noticed yet, we have a completely full agenda for =
Korea. This means that if we want to have a productive meeting, we will =
need to start punctually. Our meeting time follows the afternoon =
beverage and snack break,  if you plan to attend please try to be in the =
room and settled down by our scheduled 15:50 start time.

We also will need to have at least one note-taker, and it would be very =
helpful to have a Jabber scribe since I know some WG members will be =
remote this time. The chairs (and WG!) would appreciate it you volunteer =
ahead of time. As most of you know, if we don't have volunteers ahead of =
time, it means we aren't able to start the meeting punctually and have =
to go through the phase of everyone awkwardly pretending to be very busy =
reading their mail while the chairs try to catch the eye of a =
victimteer.

Note-taking:=20

For those who haven't done this before, note-taking doesn't require =
capturing a full transcript. In particular, anything shown on the slides =
need not appear in the notes. The most important thing is for the notes =
to capture questions and answers, and especially decisions and action =
items. One good option for note-taking is Etherpad, a collaborative =
editor linked from the datatracker agenda =
(http://etherpad.tools.ietf.org:9000/p/notes-ietf-97-idr?useMonospaceFont=3D=
true). While it's beneficial to use this since others can pitch in and =
help with the notes, if you're willing to volunteer but aren't =
comfortable using Etherpad, that's fine. Use whatever application you're =
comfortable with, even a yellow pad and pencil if you must.

If two or more people want to volunteer to collaboratively take notes, =
so that no single person has the complete load, that would be fine.

Going to the mic:

If you make a comment at the mic, of course you should state your name, =
and you probably should enunciate it more slowly and clearly than you =
intuitively think is necessary because the person taking the notes might =
not get it right otherwise. You should also consider double-checking the =
notes in Etherpad to make sure your name got spelled right, and while =
you're at it you can make sure your comment was represented accurately.

Jabber:

Similar to note-taking, being Jabber scribe doesn't mean you have to =
capture a full transcript. Primarily, our request is that you make it =
known to the Jabber room that you are available to relay questions to =
the mic. If you want to also keep the Jabber room apprised of what slide =
is currently being projected, that would be great too. (For convenience =
in doing this, presenters are all asked to number their slides.) The =
Jabber room is also linked from the datatracker agenda =
(xmpp:idr@jabber.ietf.org?join).

Thanks in advance, and I'll send this out again as a reminder closer to =
the meeting time.

--John=


From nobody Sat Nov  5 10:42:32 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4002812995C for ; Sat,  5 Nov 2016 10:42:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.699
X-Spam-Level: 
X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, 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 EiIpJOJTC5PG for ; Sat,  5 Nov 2016 10:42:29 -0700 (PDT)
Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0C1B129964 for ; Sat,  5 Nov 2016 10:42:29 -0700 (PDT)
Received: by guelah.shrubbery.net (Postfix, from userid 7053) id 80F0274D90; Sat,  5 Nov 2016 17:42:29 +0000 (UTC)
Date: Sat, 5 Nov 2016 17:42:29 +0000
From: heasley 
To: Robert Raszuk 
Message-ID: <20161105174229.GG98782@shrubbery.net>
References: <95F42982-7DCF-46A9-A26C-71EF70DB3C59@apnic.net> <20161104195346.GK961@Vurt.local> <20161104201631.GA35942@Vurt.lan> <8a293ce4fc134657aa98134b5017d92e@XCH-ALN-014.cisco.com> <20161104221030.GD37681@Vurt.lan> <0919e676e12d49d1a2ba30f4acc3b273@XCH-ALN-014.cisco.com> <20161104230536.GJ37681@Vurt.lan> <19AB2A007F56DB4E8257F949A2FB9858C87AFC6E@NKGEML515-MBX.china.huawei.com> <20161105103526.GM952@Vurt.local> 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc
X-note: live free, or die!
X-homer: i just want to have a beer while i am caring.
X-Claimation: an engineer needs a manager like a fish needs a bicycle
X-reality: only YOU can put an end to the embarrassment that is Tom Cruise
User-Agent: Mutt/1.6.1 (2016-04-27)
Archived-At: 
Cc: "idr@ietf.org" 
Subject: Re: [Idr] Review of draft-ietf-large-community-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: Sat, 05 Nov 2016 17:42:31 -0000

Sat, Nov 05, 2016 at 06:18:36PM +0100, Robert Raszuk:
> Hi Job,
> 
> > By default, the BGP speaker does not send/transmit community
> > > attributes. Even if the COMMUNITIES path attribute is an optional
> > > transitive attribute. This is the current reality application.
> >
> > *​​Then change your default!*
> >
> 
> ​Are you making a recommendation here ​that BGP implementations should now
> be modified to send BGP communities to EBGP (and obviously IBGP) peers by
> default ?
> 
> Do you mean that only for large communities or also for standards and
> extended communities ?
> 
> I think Shunwan's point is very valid and it seems by making above
> recommendation to modify the BGP implementations default you agree with it.
> If so draft should reflect this as this is no longer market nor EBGP peers
> agreement.

I do not believe Job made either recommendation.  He merely said that
Shunwan as an implementer (I am assuming) could change their implementation's
default.

Job did write that it was adventageous for -large- to have similar properties
as rfc1997.  neither docs make recommendations about the feature to which
Shunwan is referring.


From nobody Sat Nov  5 10:55:29 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 817BB1294D8 for ; Sat,  5 Nov 2016 10:55:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level: 
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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 nwFTlIs8nPX8 for ; Sat,  5 Nov 2016 10:55:26 -0700 (PDT)
Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B57BC1294F8 for ; Sat,  5 Nov 2016 10:55:25 -0700 (PDT)
Received: by mail-wm0-x22e.google.com with SMTP id a197so108322795wmd.0 for ; Sat, 05 Nov 2016 10:55:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=rzNF8z6bVN1+xyZEWlVEyOpcLYowyZ69iDN2yOTdkik=; b=BgkPy64ddmbXq63+W8DVskIwDmYe63tDBdphSLNlSIkcaUskjFFy11eL/ftbWG/YSP gEnpY/Svybo2sgp8eYeKH5tGPWIGBpjlaKQlBcH5g+4Qib6UCWpQxbNctwx8Q1I31tNe kORTY2SCYdU+a32qKr7FEWF2S9osTHpoP/Dm4XF2SLrOTb3dH8L7mR4kiVkbUFxDE0QV uoEBvmgPHWeCokKJJDCU5u0d8IUpVo7jXhKfsK+4I4KoV7Db8KrkdblCKCqZcskMv6VO +rgQdraPtNHtdjJvR/P+MW7s3G9CLG0CCSD/jLHmg3xvTe2NR6fAO597LpzZECbggS7Q JU6w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=rzNF8z6bVN1+xyZEWlVEyOpcLYowyZ69iDN2yOTdkik=; b=FN2zoThpkjaJlvWczTbqfsSyZ65Tenh6h4vTcN1fAlhHEGBx42Ymr7Aa1pvlHq+Nmn 5qyh0XTQ2172rl6NZCA6luiUGCBUgfMXz+RPZbsKBU9aFuC9ibATtEVr0PEzmDi2PxVy KJyJKm/h/NSHo5pCcAcAil/2+Usclc3r+RsFED+dKWqwoOiZGbMCho+oezvk+aoqCz8m u31OsyCIlnYS1drRmdopxtzrU5WkCJEpq5JfdBtw+yZOZv3os3mS8WhJfnIMdWxslm52 I0MDoCMSvOkshsGU48R8rYeT/QKUC6xI9XPuaaFu3JkiOObuUCu/giXTnaYvvs104mMP aUEw==
X-Gm-Message-State: ABUngvfKT0cwD0PDZHACfhFe3PPnbhuSWnf0BnIDiBvYDGL0+/E58oS5qcFrw78+fTcS7u/Q1zerRsJb9st2hw==
X-Received: by 10.194.187.103 with SMTP id fr7mr9260092wjc.99.1478368524218; Sat, 05 Nov 2016 10:55:24 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.80.137.69 with HTTP; Sat, 5 Nov 2016 10:55:22 -0700 (PDT)
In-Reply-To: <20161105174229.GG98782@shrubbery.net>
References: <95F42982-7DCF-46A9-A26C-71EF70DB3C59@apnic.net> <20161104195346.GK961@Vurt.local> <20161104201631.GA35942@Vurt.lan> <8a293ce4fc134657aa98134b5017d92e@XCH-ALN-014.cisco.com> <20161104221030.GD37681@Vurt.lan> <0919e676e12d49d1a2ba30f4acc3b273@XCH-ALN-014.cisco.com> <20161104230536.GJ37681@Vurt.lan> <19AB2A007F56DB4E8257F949A2FB9858C87AFC6E@NKGEML515-MBX.china.huawei.com> <20161105103526.GM952@Vurt.local>  <20161105174229.GG98782@shrubbery.net>
From: Robert Raszuk 
Date: Sat, 5 Nov 2016 18:55:22 +0100
X-Google-Sender-Auth: e4OElIA3sW78D5eISDRg2O8h63A
Message-ID: 
To: heasley 
Content-Type: multipart/alternative; boundary=047d7bd6bc9cbbb8080540917eea
Archived-At: 
Cc: "idr@ietf.org" 
Subject: Re: [Idr] Review of draft-ietf-large-community-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: Sat, 05 Nov 2016 17:55:28 -0000

--047d7bd6bc9cbbb8080540917eea
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Heas,

All true .. I posted my question as perhaps it really makes sense to modify
the defaults for both 1997 and large.

To share the experience from a lot of global deployments of SAFI 128
propagation of extended communities was the biggest pain for 100s customers
to keep remembering to enable send-community extended|both knob on each
session.

And as you know SAFI 128 is pretty useless without RTs so keeping such
defaults there on both IBGP and EBGP sessions was just wrong.

Here in the case of Large Communities folks clearly indicated need to use
it across multiple ASNs. And that is cool. Except you have zero control how
peer of your provider will handle it.

So today non upgraded eBGP router will propagate it. When new OS is loaded
(maybe for completely different reason) which can recognize LC attribute
unless the knob is in place it will be dropped.

Perhaps it make sense to spell this out in the draft that large communities
attribute should be propagated by default unless otherwise suppressed by
policy ?

Thx,
r.


On Sat, Nov 5, 2016 at 6:42 PM, heasley  wrote:

> Sat, Nov 05, 2016 at 06:18:36PM +0100, Robert Raszuk:
> > Hi Job,
> >
> > > By default, the BGP speaker does not send/transmit community
> > > > attributes. Even if the COMMUNITIES path attribute is an optional
> > > > transitive attribute. This is the current reality application.
> > >
> > > *=E2=80=8B=E2=80=8BThen change your default!*
> > >
> >
> > =E2=80=8BAre you making a recommendation here =E2=80=8Bthat BGP impleme=
ntations should
> now
> > be modified to send BGP communities to EBGP (and obviously IBGP) peers =
by
> > default ?
> >
> > Do you mean that only for large communities or also for standards and
> > extended communities ?
> >
> > I think Shunwan's point is very valid and it seems by making above
> > recommendation to modify the BGP implementations default you agree with
> it.
> > If so draft should reflect this as this is no longer market nor EBGP
> peers
> > agreement.
>
> I do not believe Job made either recommendation.  He merely said that
> Shunwan as an implementer (I am assuming) could change their
> implementation's
> default.
>
> Job did write that it was adventageous for -large- to have similar
> properties
> as rfc1997.  neither docs make recommendations about the feature to which
> Shunwan is referring.
>

--047d7bd6bc9cbbb8080540917eea
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Heas,

All true .. I posted my question as perhaps it really m=
akes sense to modify the defaults for both 1997 and large.=C2=A0

To share the experience from a l=
ot of global deployments of SAFI 128 propagation of extended communities wa=
s the biggest pain for 100s customers to keep remembering to enable send-co=
mmunity extended|both knob on each session.=C2=A0
<=
br>
And as you know SAFI 128 is pretty useless with=
out RTs so keeping such defaults there on both IBGP and EBGP sessions was j=
ust wrong.

Here in the=
 case of Large Communities folks clearly indicated need to use it across mu=
ltiple ASNs. And that is cool. Except you have zero control how peer of you=
r provider will handle it.=C2=A0

So today non upgraded eBGP router will propagate it. When new OS=
 is loaded (maybe for completely different reason) which can recognize LC a=
ttribute unless the knob is in place it will be dropped.=C2=A0

Perhaps it make sense to spell thi=
s out in the draft that large communities attribute should be propagated by=
 default unless otherwise suppressed by policy ?
Thx,
r.


On Sat, Nov 5, 2016 at 6:42 PM, heasley <heas@shrubbery.net&g=
t; wrote:
Sat, Nov 05, 2016 at 06:=
18:36PM +0100, Robert Raszuk:

> Hi Job,

>

> > By default, the BGP speaker does not send/transmit community

> > > attributes. Even if the COMMUNITIES path attribute is an opt=
ional

> > > transitive attribute. This is the current reality applicatio=
n.

> >

> > *=E2=80=8B=E2=80=8BThen change your default!*

> >

>

> =E2=80=8BAre you making a recommendation here =E2=80=8Bthat BGP implem=
entations should now

> be modified to send BGP communities to EBGP (and obviously IBGP) peers=
 by

> default ?

>

> Do you mean that only for large communities or also for standards and<=
br>
> extended communities ?

>

> I think Shunwan's point is very valid and it seems by making above=


> recommendation to modify the BGP implementations default you agree wit=
h it.

> If so draft should reflect this as this is no longer market nor EBGP p=
eers

> agreement.



I do not believe Job made either recommendation.=C2=A0 He merely sai=
d that

Shunwan as an implementer (I am assuming) could change their implementation=
's

default.



Job did write that it was adventageous for -large- to have similar properti=
es

as rfc1997.=C2=A0 neither docs make recommendations about the feature to wh=
ich

Shunwan is referring.





--047d7bd6bc9cbbb8080540917eea--


From nobody Sat Nov  5 11:35:21 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FB161294BA for ; Sat,  5 Nov 2016 11:35:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.699
X-Spam-Level: 
X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, 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 F8y2G1qY85OF for ; Sat,  5 Nov 2016 11:35:18 -0700 (PDT)
Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D42F12947D for ; Sat,  5 Nov 2016 11:35:18 -0700 (PDT)
Received: by guelah.shrubbery.net (Postfix, from userid 7053) id AC1CD74E03; Sat,  5 Nov 2016 18:35:17 +0000 (UTC)
Date: Sat, 5 Nov 2016 18:35:17 +0000
From: heasley 
To: Robert Raszuk 
Message-ID: <20161105183517.GI98782@shrubbery.net>
References: <20161104201631.GA35942@Vurt.lan> <8a293ce4fc134657aa98134b5017d92e@XCH-ALN-014.cisco.com> <20161104221030.GD37681@Vurt.lan> <0919e676e12d49d1a2ba30f4acc3b273@XCH-ALN-014.cisco.com> <20161104230536.GJ37681@Vurt.lan> <19AB2A007F56DB4E8257F949A2FB9858C87AFC6E@NKGEML515-MBX.china.huawei.com> <20161105103526.GM952@Vurt.local>  <20161105174229.GG98782@shrubbery.net> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc
X-note: live free, or die!
X-homer: i just want to have a beer while i am caring.
X-Claimation: an engineer needs a manager like a fish needs a bicycle
X-reality: only YOU can put an end to the embarrassment that is Tom Cruise
User-Agent: Mutt/1.6.1 (2016-04-27)
Archived-At: 
Cc: "idr@ietf.org" 
Subject: Re: [Idr] Review of draft-ietf-large-community-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: Sat, 05 Nov 2016 18:35:19 -0000

Sat, Nov 05, 2016 at 06:55:22PM +0100, Robert Raszuk:
> Heas,
> 
> All true .. I posted my question as perhaps it really makes sense to modify
> the defaults for both 1997 and large.
> 
> To share the experience from a lot of global deployments of SAFI 128
> propagation of extended communities was the biggest pain for 100s customers
> to keep remembering to enable send-community extended|both knob on each
> session.
> 
> And as you know SAFI 128 is pretty useless without RTs so keeping such
> defaults there on both IBGP and EBGP sessions was just wrong.
> 
> Here in the case of Large Communities folks clearly indicated need to use
> it across multiple ASNs. And that is cool. Except you have zero control how
> peer of your provider will handle it.
> 
> So today non upgraded eBGP router will propagate it. When new OS is loaded
> (maybe for completely different reason) which can recognize LC attribute
> unless the knob is in place it will be dropped.
> 
> Perhaps it make sense to spell this out in the draft that large communities
> attribute should be propagated by default unless otherwise suppressed by
> policy ?

rfc4360 also does not make such a recommendation about a 'send-community
extended' (in cisco-ese) feature.  As I recall, it is one vendor who started
that, though I can not recall why, and many who copy their CLI have followed
suit.  One vendor has no such knob that I know of; communities are always
sent unless removed by RPL.  And, I believe there are a few open
implementations that also send communities by default.

I do wish that implementations that have this feature would default to
enabled/send, rather than disabled/filter.

However, given the heated discussion about prescribing a canonical
representation for -large-communities, is this a subject for an IDR rfc?
Isn't it a subject for a customer-vendor meeting?  Is changing the language
about propagating recognized transitive attributes going to change these
vendor's defaults?


From nobody Sat Nov  5 11:57:34 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E84AF12997B for ; Sat,  5 Nov 2016 11:57:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level: 
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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 jYAkfMrhYCbr for ; Sat,  5 Nov 2016 11:57:31 -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 3E015129973 for ; Sat,  5 Nov 2016 11:57:31 -0700 (PDT)
Received: by mail-wm0-x232.google.com with SMTP id f82so48287228wmf.1 for ; Sat, 05 Nov 2016 11:57:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=xuBO8Qxb69//6djAE6yhnCSMxbJl2z1qwZKUeyzDP/A=; b=SLG3X3BxnsyK73SZJR6+nV8AxJGKWJCyaUMkiU7+s605zOXyMj35EV6L2R9Mgsmzhk f89W02iN4Rmr7ikYbe+scnWtYKExP8oN4B4uNHj5x3NrmMNcVZ+EjbPmHTnszuH8xpeY ZhdpAuGB4cksdjQ+57s6N2+EWmlppTkkZKvhh86ByRuNpigfaB3SZG4wdbxcqs5R5SqM TDcbzAQZWrnAZyj7DudiyDZLjtGEUQ74ioO1YsYJ9jz0ffTuA6oQctkj+3vKVZdFOpYC ajRG03+DGPHnpxCU3sOXZXScSxk9NVHx+V5XzMJqbMyoT0n/nsnux/qOhDx7RACXetMn +KHA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=xuBO8Qxb69//6djAE6yhnCSMxbJl2z1qwZKUeyzDP/A=; b=Eontd22UCkVD+tJz3o1MR+GWHgqwS7/pwHCd1HHZkhG7oxeWe3QXpjQM+oxqN+sAUp uhda2q4e7JKYIPm9aBITF7mvH1+pS6loeOdR9ZyfquR9n+s6U5HHDujPJhKICi9V9iGl R0bzxuwZr4OXWw2HEg4s3fUQ353RA3kij4jvoNDa1JS4OeO3elIjZTY0x4E4uwsEFvSr 3+eGsLAwOPB8rV3QojJWtuzy4qF4J9+D4xvltMo6AcwFF4WBVCoQl1A9MoqhsRXtOCsC NyzGsfG90KxGtrbSdrTUVCI0516h++z5aO8r5VLMRAXN8SuK6364/O2s0sv50hSDdwVG FAQQ==
X-Gm-Message-State: ABUngvcU0H6HtOWrSDIvqnjrB3oJKmSrYM03fzgGY1N8QtumL82JfY7b1T+gG6O3B3gbBgi4Ji+rs1n114H00Q==
X-Received: by 10.194.187.103 with SMTP id fr7mr9378846wjc.99.1478372249756; Sat, 05 Nov 2016 11:57:29 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.80.137.69 with HTTP; Sat, 5 Nov 2016 11:57:28 -0700 (PDT)
In-Reply-To: <20161105183517.GI98782@shrubbery.net>
References: <20161104201631.GA35942@Vurt.lan> <8a293ce4fc134657aa98134b5017d92e@XCH-ALN-014.cisco.com> <20161104221030.GD37681@Vurt.lan> <0919e676e12d49d1a2ba30f4acc3b273@XCH-ALN-014.cisco.com> <20161104230536.GJ37681@Vurt.lan> <19AB2A007F56DB4E8257F949A2FB9858C87AFC6E@NKGEML515-MBX.china.huawei.com> <20161105103526.GM952@Vurt.local>  <20161105174229.GG98782@shrubbery.net>  <20161105183517.GI98782@shrubbery.net>
From: Robert Raszuk 
Date: Sat, 5 Nov 2016 19:57:28 +0100
X-Google-Sender-Auth: luJFZ4Xc4NBQPE6on9g4eOM3sv8
Message-ID: 
To: heasley 
Content-Type: multipart/alternative; boundary=047d7bd6bc9ccaeb5e0540925cb5
Archived-At: 
Cc: "idr@ietf.org" 
Subject: Re: [Idr] Review of draft-ietf-large-community-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: Sat, 05 Nov 2016 18:57:33 -0000

--047d7bd6bc9ccaeb5e0540925cb5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

=E2=80=8B=E2=80=8B

> =E2=80=8B=E2=80=8B
> However, given the heated discussion about prescribing a canonical
> representation for -large-communities, is this a subject for an IDR rfc?
>

=E2=80=8BIMO it is. Reason being that RFC will be read by someone who is ta=
sked to
implement it and unless spec clearly at least recommends=E2=80=8B one way w=
e will
have a mix of behaviors.


> Isn't it a subject for a customer-vendor meeting?


Honestly customer-vendor =E2=80=8Bmeetings are for new policy knobs. I real=
ly do
not recall any EBC where customer were successful in asking vendor to
change any deployed defaults. Defaults once set during implementation
usually stay for a long time.


> Is changing the language
> =E2=80=8B
> about propagating recognized transitive attributes going to change these
> vendor's defaults?
>

=E2=80=8BWell I believe so. Notice that as much as folks likes large to be =
"like"
1997 it is not 100%. Even by your cisco example .. there is already
send-community standard vs extended knob. Large =E2=80=8Bwill be new additi=
on and
in addition to "both" they will likely add also "all" keyword.

So if we want to make large nicely transitive I think it is now a good time
to add this to draft/rfc just to have a common agreed way on the expected
outcome in any implementation.

As to why we have this knob in the first place from the early days I recall
it was based on ISPs who wanted to have RFC1997 local within their AS only
by default - such that they do not need any extra policy in order not to
propagate it over eBGP. Does the same design applies to Large ?

Note that I am not suggesting large must be propagate by default. But I
think it would be good to have mandated by the spec consistency across BGP
implementations - propagate or do not propagate.

Thx,
r.

--047d7bd6bc9ccaeb5e0540925cb5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8B
However, given the hea=
ted discussion about prescribing a canonical

representation for -large-communities, is this a subject for an IDR rfc?

=E2=80=8BIMO it is. Re=
ason being that RFC will be read by someone who is tasked to implement it a=
nd unless spec clearly at least recommends=E2=80=8B one way we will have a =
mix of behaviors.=C2=A0
=C2=A0

Isn't it a subject for a customer-vendor meeting?=C2=A0 

Honestly customer-vendor =E2=80=8Bmeet=
ings are for new policy knobs. I really do not recall any EBC where custome=
r were successful in asking vendor to change any deployed defaults. Default=
s once set during implementation usually stay for a long time.=C2=A0
<=
div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif=
;font-size:small">=C2=A0
Is changing the language=E2=80=8B=C2=A0
about propagating recog=
nized transitive attributes going to change these

vendor's defaults?



=
=E2=80=8BWell I believe so. Notice that as much as folks likes large to be =
"like" 1997 it is not 100%. Even by your cisco example .. there i=
s already send-community standard vs extended knob. Large =E2=80=8Bwill be =
new addition and in addition to "both" they will likely add also =
"all" keyword.=C2=A0

So if we want to make large nicely transitive I think it is now a =
good time to add this to draft/rfc just to have a common agreed way on the =
expected outcome in any implementation.=C2=A0

<=
/div>
As to why we have this knob in the first place from=
 the early days I recall it was based on ISPs who wanted to have RFC1997 lo=
cal within their AS only by default - such that they do not need any extra =
policy in order not to propagate it over eBGP. Does the same design applies=
 to Large ?

Note that =
I am not suggesting large must be propagate by default. But I think it woul=
d be good to have mandated by the spec consistency across BGP implementatio=
ns - propagate or do not propagate.=C2=A0

Thx,
r.


--047d7bd6bc9ccaeb5e0540925cb5--


From nobody Sat Nov  5 12:52:56 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 805D81294BD for ; Sat,  5 Nov 2016 12:52:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7wwPe_A9tHD for ; Sat,  5 Nov 2016 12:52:52 -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 57F01129569 for ; Sat,  5 Nov 2016 12:52:52 -0700 (PDT)
Received: by mail-wm0-x22b.google.com with SMTP id p190so111764962wmp.1 for ; Sat, 05 Nov 2016 12:52:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:from:date:message-id:subject:to:cc; bh=NVnTvBj+sdfEdLf1nw+iG/2Cn9p1z3h//RdWAMuSVeE=; b=o7W2DPs8Ud8IhHGBFwwWAlt7aVqR7imHuqwMmmxIW98nVPvmlmWixEMG0RnLERfzsb 4c4kJkBLBwsFhWLsJaZ/JBJquqUhPDnHv3ChBpWK6HJ6T7IC19V4N6LcP8tp7O2Jivga WDxwHDfH4JzuSl5xowH37DsdCN68cic0xaWc4vSs7y5gPKMXdBu9CMKfUpL3q5CeKkst bD1OkGZJDlJrYgSmbikdC03q3NRlckQHT4QANLmA5zObKUGjZWgYpcv0nHS22Sr4yHa8 cnj+LvR4VAk2Sg7daD8BWGumZeqb6slsbDEKrmZEHVROw5EdKVVFcqfuELdcRLSCf3Jz jitg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=NVnTvBj+sdfEdLf1nw+iG/2Cn9p1z3h//RdWAMuSVeE=; b=duDIwbHkMNHCMYsj1GoJweCGMDLCXiAonve/1rjKncInDSP3w7gAwliZdKdMVS+J9O ljjhMHr6G/YKFNnpJDb5SfXbRMfKSUBjCHN2Pt4RwVDUvgtIM7M5GJFSsLAH9LI8VP7r W1+pjilD0jHSuR9jj6e1KYK3/CleCpoYuLW0aZHq2khidhtaxBaUFyi3bN1ZBiKErGwo X3YVA1bow+X922+YPxI2UC5941fWOaDJ6KAvmKMv+AtNVsw0mWsE8Ux9vv0Qh5yQTwgt anRDMKfRa8+c1b4rZbBV2wcp+oCUlxjacaV0xvyhWL7CStYv8XLwjYkgBHiAs5IcRoQT 8Hzw==
X-Gm-Message-State: ABUngvcheFzYeBkgcj5i58hYprx3q8GEVSp1fF565nm1kXoHFHR4gnjfPzivUE+kzAooJwCSfHdM+okBzegt9A==
X-Received: by 10.28.227.215 with SMTP id a206mr2536014wmh.84.1478375570908; Sat, 05 Nov 2016 12:52:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.197.132 with HTTP; Sat, 5 Nov 2016 12:52:50 -0700 (PDT)
From: Brian Dickson 
Date: Sat, 5 Nov 2016 12:52:50 -0700
Message-ID: 
To: Robert Raszuk 
Content-Type: multipart/alternative; boundary=001a114b16b8bfabb605409322cd
Archived-At: 
Cc: heasley , "idr@ietf.org" 
Subject: [Idr] Vendor Defaults (was Re: Review of draft-ietf-large-community-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: Sat, 05 Nov 2016 19:52:54 -0000

--001a114b16b8bfabb605409322cd
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sat, Nov 5, 2016 at 11:57 AM, Robert Raszuk  wrote:

> =E2=80=8B=E2=80=8B
>
>> =E2=80=8B=E2=80=8B
>> However, given the heated discussion about prescribing a canonical
>> representation for -large-communities, is this a subject for an IDR rfc?
>>
>
> =E2=80=8BIMO it is. Reason being that RFC will be read by someone who is =
tasked to
> implement it and unless spec clearly at least recommends=E2=80=8B one way=
 we will
> have a mix of behaviors.
>
>
>>
How about this: convert "Make it work exactly how you do RFC 1997" into an
I-D?


> I really do not recall any EBC where customer were successful in asking
> vendor to change any deployed defaults. Defaults once set during
> implementation usually stay for a long time.
>

My experience has been, unexposed defaults can clearly only be changed by
the vendor.
Mixing versions of code, which contain DIFFERENT defaults is fraught with
peril.
No sane customer would EVER ask a vendor for different unexposed defaults.

What I have always done is, ask/tell vendor: "Expose defaults explicitly in
configs. Give us knobs to change defaults globally."  Having knobs to
change defaults based on customer-provided values, solves the
consistent-defaults problem while giving the customer control over what
that default is.

While I am sure many customers ask several vendors for this, it has not
generally happened.

(Feel free to convey this back to your management, BTW.)



>
>
>> Is changing the language
>> =E2=80=8B
>> about propagating recognized transitive attributes going to change these
>> vendor's defaults?
>>
>
> =E2=80=8BWell I believe so. Notice that as much as folks likes large to b=
e "like"
> 1997 it is not 100%. Even by your cisco example .. there is already
> send-community standard vs extended knob. Large =E2=80=8Bwill be new addi=
tion and
> in addition to "both" they will likely add also "all" keyword.
>

That is a vendor design decision issue.

There is nothing to prevent a vendor from implementing large, by making
large lock-step with 1997. For example, the implementation which supports
large, could apply different semantics to "send community" to send BOTH
1997 AND large communities, without changing the syntax.
(Such a change in semantics would probably be well advised to allow
optional parameters to provide knobs for "1997-only", "large-only",
"wide-only", "extended-only", or any combination of 1997, large, wide, and
extended).


> As to why we have this knob in the first place from the early days I
> recall it was based on ISPs who wanted to have RFC1997 local within their
> AS only by default - such that they do not need any extra policy in order
> not to propagate it over eBGP. Does the same design applies to Large ?
>

I don't recall any explanation for the default being the way it was. IMHO,
vendors are free to change THEIR default, but SHOULD apply the same default
to both 1997 and large.

Also IMHO, the "principal of least surprise" is something that vendors
should adhere to.
I cannot tell you how severely undisclosed and uncontrolled changes to
defaults across upgrades have adversely affected networks I built and ran,
and those of my compatriots.

Please, stop trying to make "better" defaults. Just give us the knobs.


> Note that I am not suggesting large must be propagate by default. But I
> think it would be good to have mandated by the spec consistency across BG=
P
> implementations - propagate or do not propagate.
>
>
Until the knobs are universally in place across vendors: No, and please
stop trying to advocate for this sort of thing.

Brian

--001a114b16b8bfabb605409322cd
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Sat, Nov 5, 2016 at 11:57 AM, Robert Raszuk <robert@raszuk.net&=
gt; wrote:
=E2=80=8B=
=E2=80=8B
=E2=80=8B=E2=80=8BHowever, given the heated discussion about prescribing a canonical

representation for -large-communities, is this a subject for an IDR rfc?

=E2=80=8BIMO it is. Reason being that R=
FC will be read by someone who is tasked to implement it and unless spec cl=
early at least recommends=E2=80=8B one way we will have a mix of behaviors.=
=C2=A0
=C2=A0



How about this: convert "Make it work exactly how you do RFC 1=
997" into an I-D?
=C2=A0
I r=
eally do not recall any EBC where customer were successful in asking vendor=
 to change any deployed defaults. Defaults once set during implementation u=
sually stay for a long time.=C2=A0

My experience has been, unexposed defaults can clearl=
y only be changed by the vendor.
Mixing versions of code, which c=
ontain DIFFERENT defaults is fraught with peril.
No sane customer=
 would EVER ask a vendor for different unexposed defaults.

What I have always done is, ask/tell vendor: "Expose defaults=
 explicitly in configs. Give us knobs to change defaults globally." =
=C2=A0Having knobs to change defaults based on customer-provided values, so=
lves the consistent-defaults problem while giving the customer control over=
 what that default is.

While I am sure many custom=
ers ask several vendors for this, it has not generally happened.
=

(Feel free to convey this back to your management, BTW.)

=C2=A0
=C2=A0
Is changing the language
=E2=
=80=8B=C2=A0
about propagating recognized transitive attributes going =
to change these

vendor's defaults?



=E2=80=8BWell I=
 believe so. Notice that as much as folks likes large to be "like"=
; 1997 it is not 100%. Even by your cisco example .. there is already send-=
community standard vs extended knob. Large =E2=80=8Bwill be new addition an=
d in addition to "both" they will likely add also "all"=
 keyword.=C2=A0

That is a=
 vendor design decision issue.

There is nothing to=
 prevent a vendor from implementing large, by making large lock-step with 1=
997. For example, the implementation which supports large, could apply diff=
erent semantics to "send community" to send BOTH 1997 AND large c=
ommunities, without changing the syntax.
(Such a change in semant=
ics would probably be well advised to allow optional parameters to provide =
knobs for "1997-only", "large-only", "wide-only&qu=
ot;, "extended-only", or any combination of 1997, large, wide, an=
d extended).
=C2=A0
As to why we have this knob in the first pl=
ace from the early days I recall it was based on ISPs who wanted to have RF=
C1997 local within their AS only by default - such that they do not need an=
y extra policy in order not to propagate it over eBGP. Does the same design=
 applies to Large ?

I don=
't recall any explanation for the default being the way it was. IMHO, v=
endors are free to change THEIR default, but SHOULD apply the same default =
to both 1997 and large.

Also IMHO, the "princ=
ipal of least surprise" is something that vendors should adhere to.
I cannot tell you how severely undisclosed and uncontrolled changes=
 to defaults across upgrades have adversely affected networks I built and r=
an, and those of my compatriots.

Please, stop tryi=
ng to make "better" defaults. Just give us the knobs.
=
=C2=A0
Note that I am not suggesting large must be propagate by default. Bu=
t I think it would be good to have mandated by the spec consistency across =
BGP implementations - propagate or do not propagate.=C2=A0


Until the knobs are universally in =
place across vendors: No, and please stop trying to advocate for this sort =
of thing.

Brian=C2=A0


--001a114b16b8bfabb605409322cd--


From nobody Sat Nov  5 13:15:03 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D6B0129555 for ; Sat,  5 Nov 2016 13:15:02 -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 1v_UdbL_61G4 for ; Sat,  5 Nov 2016 13:15:01 -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 AA9D8129552 for ; Sat,  5 Nov 2016 13:15:00 -0700 (PDT)
X-Envelope-To: idr@ietf.org
Received: from crumpet.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id uA5KEvAw041344 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 5 Nov 2016 20:14:58 GMT (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be crumpet.local
Message-ID: <581E3DC0.3020207@foobar.org>
Date: Sat, 05 Nov 2016 21:14:56 +0100
From: Nick Hilliard 
User-Agent: Postbox 5.0.5 (Macintosh/20161020)
MIME-Version: 1.0
To: Robert Raszuk 
References: <95F42982-7DCF-46A9-A26C-71EF70DB3C59@apnic.net> <20161104195346.GK961@Vurt.local> <20161104201631.GA35942@Vurt.lan> <8a293ce4fc134657aa98134b5017d92e@XCH-ALN-014.cisco.com> <20161104221030.GD37681@Vurt.lan> <0919e676e12d49d1a2ba30f4acc3b273@XCH-ALN-014.cisco.com> <20161104230536.GJ37681@Vurt.lan> <19AB2A007F56DB4E8257F949A2FB9858C87AFC6E@NKGEML515-MBX.china.huawei.com> <20161105103526.GM952@Vurt.local>  <20161105174229.GG98782@shrubbery.net> 
In-Reply-To: 
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: "idr@ietf.org" 
Subject: Re: [Idr] Review of draft-ietf-large-community-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: Sat, 05 Nov 2016 20:15:02 -0000

Robert Raszuk wrote:
> All true .. I posted my question as perhaps it really makes sense to
> modify the defaults for both 1997 and large. 

I concur with Brian - if you're serious about this, you should post a
new I-D.  As you suggest, it's not specifically an LC issue, so
therefore it would not be helpful to address it in the LC draft.

Nick


From nobody Sat Nov  5 16:13:55 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9013912943E for ; Sat,  5 Nov 2016 16:13:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.017
X-Spam-Level: 
X-Spam-Status: No, score=-16.017 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=-1.497, 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 SDuuSimjXl60 for ; Sat,  5 Nov 2016 16:13:51 -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 4848A129421 for ; Sat,  5 Nov 2016 16:13:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18741; q=dns/txt; s=iport; t=1478387631; x=1479597231; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=vl5Tp8pFwhj9KqkwaPOKcmwostNkJVnViLIY+R1iMcs=; b=DGGJH2mgWldWhU0sysmWAKDknuCi3YeszsjBjKdm3RV6bCMJryKXLIOk ai/p3chRXOx8i/leLrbaJybAneKnVmch7jsY4hUu+Sfx9ZprOuiu3KW5W wVMAHrwc+Etuv5t4RGzAioV3pYApRCt5rc3QgpJMgVLpNbn5m4HPhaOyM Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C+AgDxZh5Y/49dJa1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgy4BAQEBAR9YLU+NOJ5nh1CFGoIIHgEKhXsCGoFvPxQBAgEBAQEBAQF?= =?us-ascii?q?iKIRiAQEEAQEBIEsLEAIBBgI/AwICAh8GCxQRAgQOBRSIKgMXDpJonT+CQIc9D?= =?us-ascii?q?YNuAQEBAQEBAQEBAQEBAQEBAQEBAQEBHIY+gX0IglCCR4FzS4JGLYIvBZRHhSs?= =?us-ascii?q?1AYk/gwdEgzmBbheEWYM7hXeJCIQihAUBHjd6G4UPcgGFEYI6AQEB?=
X-IronPort-AV: E=Sophos;i="5.31,450,1473120000";  d="scan'208,217";a="167836330"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Nov 2016 23:13:46 +0000
Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id uA5NDlVU007483 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 5 Nov 2016 23:13:47 GMT
Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sat, 5 Nov 2016 18:13:45 -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; Sat, 5 Nov 2016 18:13:47 -0500
From: "Jakob Heitz (jheitz)" 
To: Brian Dickson 
Thread-Topic: [Idr] Vendor Defaults (was Re: Review of draft-ietf-large-community-06.txt)
Thread-Index: AQHSN546iba0WaPSYk6woE67Sz8aq6DLBUg9
Date: Sat, 5 Nov 2016 23:13:46 +0000
Message-ID: <86860386-9C2B-4BD5-B457-2A6DA5446CF3@cisco.com>
References: 
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
Content-Type: multipart/alternative; boundary="_000_868603869C2B4BD5B4572A6DA5446CF3ciscocom_"
MIME-Version: 1.0
Archived-At: 
Cc: heasley , "idr@ietf.org" , Robert Raszuk 
Subject: Re: [Idr] Vendor Defaults (was Re: Review of draft-ietf-large-community-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: Sat, 05 Nov 2016 23:13:53 -0000

--_000_868603869C2B4BD5B4572A6DA5446CF3ciscocom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SU9TLVhSIGRvZXMgbm90IHNlbmQgY29tbXVuaXRpZXMgb3IgZXh0ZW5kZWQgY29tbXVuaXRpZXMg
dG8gZUJHUCBuZWlnaGJvcnMgYnkgZGVmYXVsdC4NClRvIHNlbmQgY29tbXVuaXRpZXMsIHlvdSBu
ZWVkIHRvIGNvbmZpZ3VyZQ0KICBzZW5kLWNvbW11bml0eS1lYmdwDQpVbmRlciB0aGUgbmVpZ2hi
b3IgYWRkcmVzcy1mYW1pbHkuDQpUbyBzZW5kIGV4dGVuZGVkIGNvbW11bml0aWVzLCB5b3UgbmVl
ZCB0byBjb25maWd1cmUNCiAgc2VuZC1leHRlbmRlZC1jb21tdW5pdHktZWJncA0KDQpUaGUgcmVh
c29uIGlzIHRoYXQgbWFueSBvcGVyYXRvcnMgdXNlIGNvbW11bml0aWVzIGludGVybmFsIHRvIGFu
IEFTIGZvciBtYW55IHJlYXNvbnMgYW5kIHdlIGRvbid0IHdhbnQgdGhlc2UgdG8gYWNjaWRlbnRh
bGx5IGxlYWsgb3V0IHRvIHRoZSB3aWRlciBpbnRlcm5ldC4gSWYgYW4gb3BlcmF0b3IgaW50ZW5k
cyB0byBzZW5kIGNvbW11bml0aWVzIG91dHNpZGUgb2YgdGhlaXIgb3duIEFTLCB0aGVuIHRoZXkg
bmVlZCB0byBtYWtlIGEgY29uc2Npb3VzIGRlY2lzaW9uIHRvIGRvIHNvLiBBbG9uZyB3aXRoIHRo
YXQgY29uc2Npb3VzIGRlY2lzaW9uLCB0aGV5IHNob3VsZCBmaWx0ZXIgb3V0IGFsbCB0aGUgaW50
ZXJuYWxseSB1c2VkIGNvbW11bml0aWVzIGluIGEgcm91dGUtcG9saWN5Lg0KDQpJbiBteSBsYXJn
ZS1jb21tdW5pdHkgY29kZSwgSSBoYXZlIGx1bXBlZCB0aGVtIHVuZGVyIHNlbmQtY29tbXVuaXR5
LWViZ3AuIEF0IHRoaXMgcG9pbnQsIEkgYW0gdmVyeSBvcGVuIHRvIHN1Z2dlc3Rpb25zIGZvciBj
b25maWd1cmF0aW9uLiBPbmNlIHRoZSBjb2RlIGlzIHJlbGVhc2VkLCBpdCBnZXRzIG11Y2ggaGFy
ZGVyIHRvIGNoYW5nZSBjb25maWdzLg0KDQpUaGFua3MsDQpKYWtvYi4NCg0KDQpPbiBOb3YgNSwg
MjAxNiwgYXQgMTI6NTMgUE0sIEJyaWFuIERpY2tzb24gPGJyaWFuLnBldGVyLmRpY2tzb25AZ21h
aWwuY29tPG1haWx0bzpicmlhbi5wZXRlci5kaWNrc29uQGdtYWlsLmNvbT4+IHdyb3RlOg0KDQoN
Cg0KT24gU2F0LCBOb3YgNSwgMjAxNiBhdCAxMTo1NyBBTSwgUm9iZXJ0IFJhc3p1ayA8cm9iZXJ0
QHJhc3p1ay5uZXQ8bWFpbHRvOnJvYmVydEByYXN6dWsubmV0Pj4gd3JvdGU6DQrigIvigIsNCuKA
i+KAiw0KSG93ZXZlciwgZ2l2ZW4gdGhlIGhlYXRlZCBkaXNjdXNzaW9uIGFib3V0IHByZXNjcmli
aW5nIGEgY2Fub25pY2FsDQpyZXByZXNlbnRhdGlvbiBmb3IgLWxhcmdlLWNvbW11bml0aWVzLCBp
cyB0aGlzIGEgc3ViamVjdCBmb3IgYW4gSURSIHJmYz8NCg0K4oCLSU1PIGl0IGlzLiBSZWFzb24g
YmVpbmcgdGhhdCBSRkMgd2lsbCBiZSByZWFkIGJ5IHNvbWVvbmUgd2hvIGlzIHRhc2tlZCB0byBp
bXBsZW1lbnQgaXQgYW5kIHVubGVzcyBzcGVjIGNsZWFybHkgYXQgbGVhc3QgcmVjb21tZW5kc+KA
iyBvbmUgd2F5IHdlIHdpbGwgaGF2ZSBhIG1peCBvZiBiZWhhdmlvcnMuDQoNCg0KSG93IGFib3V0
IHRoaXM6IGNvbnZlcnQgIk1ha2UgaXQgd29yayBleGFjdGx5IGhvdyB5b3UgZG8gUkZDIDE5OTci
IGludG8gYW4gSS1EPw0KDQpJIHJlYWxseSBkbyBub3QgcmVjYWxsIGFueSBFQkMgd2hlcmUgY3Vz
dG9tZXIgd2VyZSBzdWNjZXNzZnVsIGluIGFza2luZyB2ZW5kb3IgdG8gY2hhbmdlIGFueSBkZXBs
b3llZCBkZWZhdWx0cy4gRGVmYXVsdHMgb25jZSBzZXQgZHVyaW5nIGltcGxlbWVudGF0aW9uIHVz
dWFsbHkgc3RheSBmb3IgYSBsb25nIHRpbWUuDQoNCk15IGV4cGVyaWVuY2UgaGFzIGJlZW4sIHVu
ZXhwb3NlZCBkZWZhdWx0cyBjYW4gY2xlYXJseSBvbmx5IGJlIGNoYW5nZWQgYnkgdGhlIHZlbmRv
ci4NCk1peGluZyB2ZXJzaW9ucyBvZiBjb2RlLCB3aGljaCBjb250YWluIERJRkZFUkVOVCBkZWZh
dWx0cyBpcyBmcmF1Z2h0IHdpdGggcGVyaWwuDQpObyBzYW5lIGN1c3RvbWVyIHdvdWxkIEVWRVIg
YXNrIGEgdmVuZG9yIGZvciBkaWZmZXJlbnQgdW5leHBvc2VkIGRlZmF1bHRzLg0KDQpXaGF0IEkg
aGF2ZSBhbHdheXMgZG9uZSBpcywgYXNrL3RlbGwgdmVuZG9yOiAiRXhwb3NlIGRlZmF1bHRzIGV4
cGxpY2l0bHkgaW4gY29uZmlncy4gR2l2ZSB1cyBrbm9icyB0byBjaGFuZ2UgZGVmYXVsdHMgZ2xv
YmFsbHkuIiAgSGF2aW5nIGtub2JzIHRvIGNoYW5nZSBkZWZhdWx0cyBiYXNlZCBvbiBjdXN0b21l
ci1wcm92aWRlZCB2YWx1ZXMsIHNvbHZlcyB0aGUgY29uc2lzdGVudC1kZWZhdWx0cyBwcm9ibGVt
IHdoaWxlIGdpdmluZyB0aGUgY3VzdG9tZXIgY29udHJvbCBvdmVyIHdoYXQgdGhhdCBkZWZhdWx0
IGlzLg0KDQpXaGlsZSBJIGFtIHN1cmUgbWFueSBjdXN0b21lcnMgYXNrIHNldmVyYWwgdmVuZG9y
cyBmb3IgdGhpcywgaXQgaGFzIG5vdCBnZW5lcmFsbHkgaGFwcGVuZWQuDQoNCihGZWVsIGZyZWUg
dG8gY29udmV5IHRoaXMgYmFjayB0byB5b3VyIG1hbmFnZW1lbnQsIEJUVy4pDQoNCg0KDQpJcyBj
aGFuZ2luZyB0aGUgbGFuZ3VhZ2UNCuKAiw0KYWJvdXQgcHJvcGFnYXRpbmcgcmVjb2duaXplZCB0
cmFuc2l0aXZlIGF0dHJpYnV0ZXMgZ29pbmcgdG8gY2hhbmdlIHRoZXNlDQp2ZW5kb3IncyBkZWZh
dWx0cz8NCg0K4oCLV2VsbCBJIGJlbGlldmUgc28uIE5vdGljZSB0aGF0IGFzIG11Y2ggYXMgZm9s
a3MgbGlrZXMgbGFyZ2UgdG8gYmUgImxpa2UiIDE5OTcgaXQgaXMgbm90IDEwMCUuIEV2ZW4gYnkg
eW91ciBjaXNjbyBleGFtcGxlIC4uIHRoZXJlIGlzIGFscmVhZHkgc2VuZC1jb21tdW5pdHkgc3Rh
bmRhcmQgdnMgZXh0ZW5kZWQga25vYi4gTGFyZ2Ug4oCLd2lsbCBiZSBuZXcgYWRkaXRpb24gYW5k
IGluIGFkZGl0aW9uIHRvICJib3RoIiB0aGV5IHdpbGwgbGlrZWx5IGFkZCBhbHNvICJhbGwiIGtl
eXdvcmQuDQoNClRoYXQgaXMgYSB2ZW5kb3IgZGVzaWduIGRlY2lzaW9uIGlzc3VlLg0KDQpUaGVy
ZSBpcyBub3RoaW5nIHRvIHByZXZlbnQgYSB2ZW5kb3IgZnJvbSBpbXBsZW1lbnRpbmcgbGFyZ2Us
IGJ5IG1ha2luZyBsYXJnZSBsb2NrLXN0ZXAgd2l0aCAxOTk3LiBGb3IgZXhhbXBsZSwgdGhlIGlt
cGxlbWVudGF0aW9uIHdoaWNoIHN1cHBvcnRzIGxhcmdlLCBjb3VsZCBhcHBseSBkaWZmZXJlbnQg
c2VtYW50aWNzIHRvICJzZW5kIGNvbW11bml0eSIgdG8gc2VuZCBCT1RIIDE5OTcgQU5EIGxhcmdl
IGNvbW11bml0aWVzLCB3aXRob3V0IGNoYW5naW5nIHRoZSBzeW50YXguDQooU3VjaCBhIGNoYW5n
ZSBpbiBzZW1hbnRpY3Mgd291bGQgcHJvYmFibHkgYmUgd2VsbCBhZHZpc2VkIHRvIGFsbG93IG9w
dGlvbmFsIHBhcmFtZXRlcnMgdG8gcHJvdmlkZSBrbm9icyBmb3IgIjE5OTctb25seSIsICJsYXJn
ZS1vbmx5IiwgIndpZGUtb25seSIsICJleHRlbmRlZC1vbmx5Iiwgb3IgYW55IGNvbWJpbmF0aW9u
IG9mIDE5OTcsIGxhcmdlLCB3aWRlLCBhbmQgZXh0ZW5kZWQpLg0KDQpBcyB0byB3aHkgd2UgaGF2
ZSB0aGlzIGtub2IgaW4gdGhlIGZpcnN0IHBsYWNlIGZyb20gdGhlIGVhcmx5IGRheXMgSSByZWNh
bGwgaXQgd2FzIGJhc2VkIG9uIElTUHMgd2hvIHdhbnRlZCB0byBoYXZlIFJGQzE5OTcgbG9jYWwg
d2l0aGluIHRoZWlyIEFTIG9ubHkgYnkgZGVmYXVsdCAtIHN1Y2ggdGhhdCB0aGV5IGRvIG5vdCBu
ZWVkIGFueSBleHRyYSBwb2xpY3kgaW4gb3JkZXIgbm90IHRvIHByb3BhZ2F0ZSBpdCBvdmVyIGVC
R1AuIERvZXMgdGhlIHNhbWUgZGVzaWduIGFwcGxpZXMgdG8gTGFyZ2UgPw0KDQpJIGRvbid0IHJl
Y2FsbCBhbnkgZXhwbGFuYXRpb24gZm9yIHRoZSBkZWZhdWx0IGJlaW5nIHRoZSB3YXkgaXQgd2Fz
LiBJTUhPLCB2ZW5kb3JzIGFyZSBmcmVlIHRvIGNoYW5nZSBUSEVJUiBkZWZhdWx0LCBidXQgU0hP
VUxEIGFwcGx5IHRoZSBzYW1lIGRlZmF1bHQgdG8gYm90aCAxOTk3IGFuZCBsYXJnZS4NCg0KQWxz
byBJTUhPLCB0aGUgInByaW5jaXBhbCBvZiBsZWFzdCBzdXJwcmlzZSIgaXMgc29tZXRoaW5nIHRo
YXQgdmVuZG9ycyBzaG91bGQgYWRoZXJlIHRvLg0KSSBjYW5ub3QgdGVsbCB5b3UgaG93IHNldmVy
ZWx5IHVuZGlzY2xvc2VkIGFuZCB1bmNvbnRyb2xsZWQgY2hhbmdlcyB0byBkZWZhdWx0cyBhY3Jv
c3MgdXBncmFkZXMgaGF2ZSBhZHZlcnNlbHkgYWZmZWN0ZWQgbmV0d29ya3MgSSBidWlsdCBhbmQg
cmFuLCBhbmQgdGhvc2Ugb2YgbXkgY29tcGF0cmlvdHMuDQoNClBsZWFzZSwgc3RvcCB0cnlpbmcg
dG8gbWFrZSAiYmV0dGVyIiBkZWZhdWx0cy4gSnVzdCBnaXZlIHVzIHRoZSBrbm9icy4NCg0KTm90
ZSB0aGF0IEkgYW0gbm90IHN1Z2dlc3RpbmcgbGFyZ2UgbXVzdCBiZSBwcm9wYWdhdGUgYnkgZGVm
YXVsdC4gQnV0IEkgdGhpbmsgaXQgd291bGQgYmUgZ29vZCB0byBoYXZlIG1hbmRhdGVkIGJ5IHRo
ZSBzcGVjIGNvbnNpc3RlbmN5IGFjcm9zcyBCR1AgaW1wbGVtZW50YXRpb25zIC0gcHJvcGFnYXRl
IG9yIGRvIG5vdCBwcm9wYWdhdGUuDQoNCg0KVW50aWwgdGhlIGtub2JzIGFyZSB1bml2ZXJzYWxs
eSBpbiBwbGFjZSBhY3Jvc3MgdmVuZG9yczogTm8sIGFuZCBwbGVhc2Ugc3RvcCB0cnlpbmcgdG8g
YWR2b2NhdGUgZm9yIHRoaXMgc29ydCBvZiB0aGluZy4NCg0KQnJpYW4NCl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJZHIgbWFpbGluZyBsaXN0DQpJZHJA
aWV0Zi5vcmc8bWFpbHRvOklkckBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt
YW4vbGlzdGluZm8vaWRyDQo=

--_000_868603869C2B4BD5B4572A6DA5446CF3ciscocom_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8
ZGl2PklPUy1YUiBkb2VzIG5vdCBzZW5kIGNvbW11bml0aWVzIG9yIGV4dGVuZGVkIGNvbW11bml0
aWVzIHRvIGVCR1AgbmVpZ2hib3JzIGJ5IGRlZmF1bHQuPC9kaXY+DQo8ZGl2PlRvIHNlbmQgY29t
bXVuaXRpZXMsIHlvdSBuZWVkIHRvIGNvbmZpZ3VyZSZuYnNwOzwvZGl2Pg0KPGRpdj4mbmJzcDsm
bmJzcDs8YSBocmVmPSJzZW5kLWNvbW11bml0eS1lYmdwIj5zZW5kLWNvbW11bml0eS1lYmdwPC9h
PjwvZGl2Pg0KPGRpdj5VbmRlciB0aGUgbmVpZ2hib3IgYWRkcmVzcy1mYW1pbHkuPC9kaXY+DQo8
ZGl2PlRvIHNlbmQgZXh0ZW5kZWQgY29tbXVuaXRpZXMsIHlvdSBuZWVkIHRvIGNvbmZpZ3VyZTwv
ZGl2Pg0KPGRpdj4mbmJzcDsmbmJzcDs8YSBocmVmPSJzZW5kLWV4dGVuZGVkLWNvbW11bml0eS1l
YmdwIj5zZW5kLWV4dGVuZGVkLWNvbW11bml0eS1lYmdwPC9hPjwvZGl2Pg0KPGRpdj48YnI+DQo8
L2Rpdj4NCjxkaXY+VGhlIHJlYXNvbiBpcyB0aGF0IG1hbnkgb3BlcmF0b3JzIHVzZSBjb21tdW5p
dGllcyBpbnRlcm5hbCB0byBhbiBBUyBmb3IgbWFueSByZWFzb25zIGFuZCB3ZSBkb24ndCB3YW50
IHRoZXNlIHRvIGFjY2lkZW50YWxseSBsZWFrIG91dCB0byB0aGUgd2lkZXIgaW50ZXJuZXQuIElm
IGFuIG9wZXJhdG9yIGludGVuZHMgdG8gc2VuZCBjb21tdW5pdGllcyBvdXRzaWRlIG9mIHRoZWly
IG93biBBUywgdGhlbiB0aGV5IG5lZWQgdG8gbWFrZSBhIGNvbnNjaW91cw0KIGRlY2lzaW9uIHRv
IGRvIHNvLiBBbG9uZyB3aXRoIHRoYXQgY29uc2Npb3VzIGRlY2lzaW9uLCB0aGV5IHNob3VsZCBm
aWx0ZXIgb3V0IGFsbCB0aGUgaW50ZXJuYWxseSB1c2VkIGNvbW11bml0aWVzIGluIGEgcm91dGUt
cG9saWN5LjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SW4gbXkgbGFyZ2UtY29tbXVu
aXR5IGNvZGUsIEkgaGF2ZSBsdW1wZWQgdGhlbSB1bmRlciBzZW5kLWNvbW11bml0eS1lYmdwLiBB
dCB0aGlzIHBvaW50LCBJIGFtIHZlcnkgb3BlbiB0byBzdWdnZXN0aW9ucyBmb3IgY29uZmlndXJh
dGlvbi4gT25jZSB0aGUgY29kZSBpcyByZWxlYXNlZCwgaXQgZ2V0cyBtdWNoIGhhcmRlciB0byBj
aGFuZ2UgY29uZmlncy48YnI+DQo8YnI+DQo8ZGl2PlRoYW5rcyw8YnI+DQo8ZGl2Pkpha29iLjwv
ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCk9uIE5v
diA1LCAyMDE2LCBhdCAxMjo1MyBQTSwgQnJpYW4gRGlja3NvbiAmbHQ7PGEgaHJlZj0ibWFpbHRv
OmJyaWFuLnBldGVyLmRpY2tzb25AZ21haWwuY29tIj5icmlhbi5wZXRlci5kaWNrc29uQGdtYWls
LmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0i
Y2l0ZSI+DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PGJyPg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0
cmEiPjxicj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBTYXQsIE5vdiA1LCAyMDE2IGF0
IDExOjU3IEFNLCBSb2JlcnQgUmFzenVrIDxzcGFuIGRpcj0ibHRyIj4NCiZsdDs8YSBocmVmPSJt
YWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQiIHRhcmdldD0iX2JsYW5rIj5yb2JlcnRAcmFzenVrLm5l
dDwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVv
dGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtw
YWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1p
bHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj7igIvigIs8L2Rp
dj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj48
c3BhbiBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1h
cmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDox
ZXgiPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7
Zm9udC1zaXplOnNtYWxsO2Rpc3BsYXk6aW5saW5lIj4NCuKAi+KAizwvZGl2Pg0KSG93ZXZlciwg
Z2l2ZW4gdGhlIGhlYXRlZCBkaXNjdXNzaW9uIGFib3V0IHByZXNjcmliaW5nIGEgY2Fub25pY2Fs
PGJyPg0KcmVwcmVzZW50YXRpb24gZm9yIC1sYXJnZS1jb21tdW5pdGllcywgaXMgdGhpcyBhIHN1
YmplY3QgZm9yIGFuIElEUiByZmM/PGJyPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnI+DQo8L2Rp
dj4NCjwvc3Bhbj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRp
Y2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPuKAi0lNTyBpdCBpcy4gUmVhc29uIGJlaW5n
IHRoYXQgUkZDIHdpbGwgYmUgcmVhZCBieSBzb21lb25lIHdobyBpcyB0YXNrZWQgdG8gaW1wbGVt
ZW50IGl0IGFuZCB1bmxlc3Mgc3BlYyBjbGVhcmx5IGF0IGxlYXN0IHJlY29tbWVuZHPigIsgb25l
IHdheSB3ZSB3aWxsIGhhdmUgYSBtaXggb2YgYmVoYXZpb3JzLiZuYnNwOzwvZGl2Pg0KPC9kaXY+
DQo8c3BhbiBjbGFzcz0iIj4NCjxkaXY+Jm5ic3A7PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBj
bGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDox
cHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4N
CjxkaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJp
Zjtmb250LXNpemU6c21hbGwiPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5Ib3cgYWJvdXQgdGhpczog
Y29udmVydCAmcXVvdDtNYWtlIGl0IHdvcmsgZXhhY3RseSBob3cgeW91IGRvIFJGQyAxOTk3JnF1
b3Q7IGludG8gYW4gSS1EPzwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxibG9ja3F1b3RlIGNs
YXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFw
eCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2IGNs
YXNzPSJnbWFpbF9leHRyYSI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQo8ZGl2Pg0KPGRp
diBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXpl
OnNtYWxsIj5JIHJlYWxseSBkbyBub3QgcmVjYWxsIGFueSBFQkMgd2hlcmUgY3VzdG9tZXIgd2Vy
ZSBzdWNjZXNzZnVsIGluIGFza2luZyB2ZW5kb3IgdG8gY2hhbmdlIGFueSBkZXBsb3llZCBkZWZh
dWx0cy4gRGVmYXVsdHMgb25jZSBzZXQgZHVyaW5nIGltcGxlbWVudGF0aW9uIHVzdWFsbHkgc3Rh
eSBmb3IgYSBsb25nIHRpbWUuJm5ic3A7PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pk15IGV4cGVyaWVu
Y2UgaGFzIGJlZW4sIHVuZXhwb3NlZCBkZWZhdWx0cyBjYW4gY2xlYXJseSBvbmx5IGJlIGNoYW5n
ZWQgYnkgdGhlIHZlbmRvci48L2Rpdj4NCjxkaXY+TWl4aW5nIHZlcnNpb25zIG9mIGNvZGUsIHdo
aWNoIGNvbnRhaW4gRElGRkVSRU5UIGRlZmF1bHRzIGlzIGZyYXVnaHQgd2l0aCBwZXJpbC48L2Rp
dj4NCjxkaXY+Tm8gc2FuZSBjdXN0b21lciB3b3VsZCBFVkVSIGFzayBhIHZlbmRvciBmb3IgZGlm
ZmVyZW50IHVuZXhwb3NlZCBkZWZhdWx0cy48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2
PldoYXQgSSBoYXZlIGFsd2F5cyBkb25lIGlzLCBhc2svdGVsbCB2ZW5kb3I6ICZxdW90O0V4cG9z
ZSBkZWZhdWx0cyBleHBsaWNpdGx5IGluIGNvbmZpZ3MuIEdpdmUgdXMga25vYnMgdG8gY2hhbmdl
IGRlZmF1bHRzIGdsb2JhbGx5LiZxdW90OyAmbmJzcDtIYXZpbmcga25vYnMgdG8gY2hhbmdlIGRl
ZmF1bHRzIGJhc2VkIG9uIGN1c3RvbWVyLXByb3ZpZGVkIHZhbHVlcywgc29sdmVzIHRoZSBjb25z
aXN0ZW50LWRlZmF1bHRzIHByb2JsZW0gd2hpbGUgZ2l2aW5nIHRoZQ0KIGN1c3RvbWVyIGNvbnRy
b2wgb3ZlciB3aGF0IHRoYXQgZGVmYXVsdCBpcy48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8
ZGl2PldoaWxlIEkgYW0gc3VyZSBtYW55IGN1c3RvbWVycyBhc2sgc2V2ZXJhbCB2ZW5kb3JzIGZv
ciB0aGlzLCBpdCBoYXMgbm90IGdlbmVyYWxseSBoYXBwZW5lZC48L2Rpdj4NCjxkaXY+PGJyPg0K
PC9kaXY+DQo8ZGl2PihGZWVsIGZyZWUgdG8gY29udmV5IHRoaXMgYmFjayB0byB5b3VyIG1hbmFn
ZW1lbnQsIEJUVy4pPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4N
CjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4
O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBkaXI9
Imx0ciI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90
ZSI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMt
c2VyaWY7Zm9udC1zaXplOnNtYWxsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsc2Fu
cy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8c3BhbiBjbGFzcz0i
Ij4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAu
OGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KSXMgY2hh
bmdpbmcgdGhlIGxhbmd1YWdlDQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRp
Y2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGw7ZGlzcGxheTppbmxpbmUiPg0K4oCLJm5ic3A7
PC9kaXY+DQphYm91dCBwcm9wYWdhdGluZyByZWNvZ25pemVkIHRyYW5zaXRpdmUgYXR0cmlidXRl
cyBnb2luZyB0byBjaGFuZ2UgdGhlc2U8YnI+DQp2ZW5kb3IncyBkZWZhdWx0cz88YnI+DQo8L2Js
b2NrcXVvdGU+DQo8L3NwYW4+PC9kaXY+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWls
X2V4dHJhIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNl
cmlmO2ZvbnQtc2l6ZTpzbWFsbCI+4oCLV2VsbCBJIGJlbGlldmUgc28uIE5vdGljZSB0aGF0IGFz
IG11Y2ggYXMgZm9sa3MgbGlrZXMgbGFyZ2UgdG8gYmUgJnF1b3Q7bGlrZSZxdW90OyAxOTk3IGl0
IGlzIG5vdCAxMDAlLiBFdmVuIGJ5IHlvdXIgY2lzY28gZXhhbXBsZSAuLiB0aGVyZSBpcyBhbHJl
YWR5IHNlbmQtY29tbXVuaXR5IHN0YW5kYXJkIHZzIGV4dGVuZGVkIGtub2IuIExhcmdlDQog4oCL
d2lsbCBiZSBuZXcgYWRkaXRpb24gYW5kIGluIGFkZGl0aW9uIHRvICZxdW90O2JvdGgmcXVvdDsg
dGhleSB3aWxsIGxpa2VseSBhZGQgYWxzbyAmcXVvdDthbGwmcXVvdDsga2V5d29yZC4mbmJzcDs8
L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0K
PGRpdj5UaGF0IGlzIGEgdmVuZG9yIGRlc2lnbiBkZWNpc2lvbiBpc3N1ZS48L2Rpdj4NCjxkaXY+
PGJyPg0KPC9kaXY+DQo8ZGl2PlRoZXJlIGlzIG5vdGhpbmcgdG8gcHJldmVudCBhIHZlbmRvciBm
cm9tIGltcGxlbWVudGluZyBsYXJnZSwgYnkgbWFraW5nIGxhcmdlIGxvY2stc3RlcCB3aXRoIDE5
OTcuIEZvciBleGFtcGxlLCB0aGUgaW1wbGVtZW50YXRpb24gd2hpY2ggc3VwcG9ydHMgbGFyZ2Us
IGNvdWxkIGFwcGx5IGRpZmZlcmVudCBzZW1hbnRpY3MgdG8gJnF1b3Q7c2VuZCBjb21tdW5pdHkm
cXVvdDsgdG8gc2VuZCBCT1RIIDE5OTcgQU5EIGxhcmdlIGNvbW11bml0aWVzLCB3aXRob3V0DQog
Y2hhbmdpbmcgdGhlIHN5bnRheC48L2Rpdj4NCjxkaXY+KFN1Y2ggYSBjaGFuZ2UgaW4gc2VtYW50
aWNzIHdvdWxkIHByb2JhYmx5IGJlIHdlbGwgYWR2aXNlZCB0byBhbGxvdyBvcHRpb25hbCBwYXJh
bWV0ZXJzIHRvIHByb3ZpZGUga25vYnMgZm9yICZxdW90OzE5OTctb25seSZxdW90OywgJnF1b3Q7
bGFyZ2Utb25seSZxdW90OywgJnF1b3Q7d2lkZS1vbmx5JnF1b3Q7LCAmcXVvdDtleHRlbmRlZC1v
bmx5JnF1b3Q7LCBvciBhbnkgY29tYmluYXRpb24gb2YgMTk5NywgbGFyZ2UsIHdpZGUsIGFuZCBl
eHRlbmRlZCkuPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGJsb2NrcXVvdGUgY2xhc3M9Imdt
YWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mg
c29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXYgY2xhc3M9Imdt
YWlsX2V4dHJhIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5z
LXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTph
cmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPkFzIHRvIHdoeSB3ZSBo
YXZlIHRoaXMga25vYiBpbiB0aGUgZmlyc3QgcGxhY2UgZnJvbSB0aGUgZWFybHkgZGF5cyBJIHJl
Y2FsbCBpdCB3YXMgYmFzZWQgb24gSVNQcyB3aG8gd2FudGVkIHRvIGhhdmUgUkZDMTk5NyBsb2Nh
bCB3aXRoaW4gdGhlaXIgQVMgb25seSBieSBkZWZhdWx0IC0gc3VjaCB0aGF0IHRoZXkgZG8gbm90
IG5lZWQNCiBhbnkgZXh0cmEgcG9saWN5IGluIG9yZGVyIG5vdCB0byBwcm9wYWdhdGUgaXQgb3Zl
ciBlQkdQLiBEb2VzIHRoZSBzYW1lIGRlc2lnbiBhcHBsaWVzIHRvIExhcmdlID88L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JIGRv
bid0IHJlY2FsbCBhbnkgZXhwbGFuYXRpb24gZm9yIHRoZSBkZWZhdWx0IGJlaW5nIHRoZSB3YXkg
aXQgd2FzLiBJTUhPLCB2ZW5kb3JzIGFyZSBmcmVlIHRvIGNoYW5nZSBUSEVJUiBkZWZhdWx0LCBi
dXQgU0hPVUxEIGFwcGx5IHRoZSBzYW1lIGRlZmF1bHQgdG8gYm90aCAxOTk3IGFuZCBsYXJnZS48
L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkFsc28gSU1ITywgdGhlICZxdW90O3ByaW5j
aXBhbCBvZiBsZWFzdCBzdXJwcmlzZSZxdW90OyBpcyBzb21ldGhpbmcgdGhhdCB2ZW5kb3JzIHNo
b3VsZCBhZGhlcmUgdG8uPC9kaXY+DQo8ZGl2PkkgY2Fubm90IHRlbGwgeW91IGhvdyBzZXZlcmVs
eSB1bmRpc2Nsb3NlZCBhbmQgdW5jb250cm9sbGVkIGNoYW5nZXMgdG8gZGVmYXVsdHMgYWNyb3Nz
IHVwZ3JhZGVzIGhhdmUgYWR2ZXJzZWx5IGFmZmVjdGVkIG5ldHdvcmtzIEkgYnVpbHQgYW5kIHJh
biwgYW5kIHRob3NlIG9mIG15IGNvbXBhdHJpb3RzLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N
CjxkaXY+UGxlYXNlLCBzdG9wIHRyeWluZyB0byBtYWtlICZxdW90O2JldHRlciZxdW90OyBkZWZh
dWx0cy4gSnVzdCBnaXZlIHVzIHRoZSBrbm9icy48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8
YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDti
b3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgZGlyPSJs
dHIiPg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6
YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj5Ob3RlIHRoYXQgSSBh
bSBub3Qgc3VnZ2VzdGluZyBsYXJnZSBtdXN0IGJlIHByb3BhZ2F0ZSBieSBkZWZhdWx0LiBCdXQg
SSB0aGluayBpdCB3b3VsZCBiZSBnb29kIHRvIGhhdmUgbWFuZGF0ZWQgYnkgdGhlIHNwZWMgY29u
c2lzdGVuY3kgYWNyb3NzIEJHUCBpbXBsZW1lbnRhdGlvbnMgLSBwcm9wYWdhdGUgb3IgZG8gbm90
IHByb3BhZ2F0ZS4mbmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhl
bHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+PGJyPg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VW50aWwgdGhl
IGtub2JzIGFyZSB1bml2ZXJzYWxseSBpbiBwbGFjZSBhY3Jvc3MgdmVuZG9yczogTm8sIGFuZCBw
bGVhc2Ugc3RvcCB0cnlpbmcgdG8gYWR2b2NhdGUgZm9yIHRoaXMgc29ydCBvZiB0aGluZy48L2Rp
dj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkJyaWFuJm5ic3A7PC9kaXY+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNp
dGUiPg0KPGRpdj48c3Bhbj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXzwvc3Bhbj48YnI+DQo8c3Bhbj5JZHIgbWFpbGluZyBsaXN0PC9zcGFuPjxicj4NCjxz
cGFuPjxhIGhyZWY9Im1haWx0bzpJZHJAaWV0Zi5vcmciPklkckBpZXRmLm9yZzwvYT48L3NwYW4+
PGJyPg0KPHNwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by9pZHIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRyPC9hPjwvc3Bh
bj48YnI+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_868603869C2B4BD5B4572A6DA5446CF3ciscocom_--


From nobody Sat Nov  5 16:16:11 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09546129604 for ; Sat,  5 Nov 2016 16:16:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level: 
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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 5aGkXz9B7AmS for ; Sat,  5 Nov 2016 16:16:07 -0700 (PDT)
Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c: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 D075C129608 for ; Sat,  5 Nov 2016 16:16:06 -0700 (PDT)
Received: by mail-wm0-x236.google.com with SMTP id f82so54224894wmf.1 for ; Sat, 05 Nov 2016 16:16:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=SuCQRcgRIUCLxucHG6jkPvtPZYcibW6zoa61pDw2tNA=; b=mpfvrmSEezdOhZ85pzReIM9zPBB/lbRqGlGNialvITbbAl/h1nrKPNZZQE8bAU1GtF xXWoBns30WasEz4jU63FworkPJ+DJyiqA7ob0KHVmSinurPNZvfWORHEdS6CMC+QGMAw uiLF0H6KbhtCLDpNglF0cqv4d+T8iOPrlz3MojqwHfnsd4VQhjGMXJ8RK+ns6mMYG+JO zy/6ReQGooShCT7hNzs0cXHcIFCHRfmwClpmZeiVmip1WNqkymPwHEfRKEPCq9aVzwEr mZAiVzFprd8QQF/9qxZoueoYnKWZtI0hsGP5KStfF3wcTXnpu+zmfAZ89/Ba0bepDxCR bRow==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=SuCQRcgRIUCLxucHG6jkPvtPZYcibW6zoa61pDw2tNA=; b=TH9qvRylaOoX7TX3zCFqumdoD6zepur4NYUxccIujOH6P3vDebtiRjSsy+gLo/7Uiw WXkFQUd8M1MQKIUQ3CrO5jbg/Ok6XMkwdjxj/+GPJ/61mgmixY54T/a46gYWWW942fal fTg0Goxf7yPCQ9oOpwjI6isB7fyJr1lp5hmEU9Nm6QMIuzdj8gCmBZzqngPxSV411Exx Bg++LOflO6/7ZQtS28gjx2RIkQPWGtw/ceBmHhH9vUE2gisDWqYB1qreanjsRljyy/dH 9A3y7jnshpqV+5oF9os8ZDsxMVIkF7dgOl4ePqMbAHEbQQ70Oo32jv21TRP8K1T1j2Wc 0kMg==
X-Gm-Message-State: ABUngvcjEK9rwbyQDjqR+Kr0C4ruTOD1VALAbw1wNfHiUoneb03zcQ6RK1tJY9XAc6SPtVv3OK1FPPZBljKmaQ==
X-Received: by 10.194.188.83 with SMTP id fy19mr71586wjc.227.1478387765074; Sat, 05 Nov 2016 16:16:05 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.80.137.69 with HTTP; Sat, 5 Nov 2016 16:16:04 -0700 (PDT)
In-Reply-To: <86860386-9C2B-4BD5-B457-2A6DA5446CF3@cisco.com>
References:  <86860386-9C2B-4BD5-B457-2A6DA5446CF3@cisco.com>
From: Robert Raszuk 
Date: Sun, 6 Nov 2016 00:16:04 +0100
X-Google-Sender-Auth: _66vAMBCNSlGonKmAXCITSrifBs
Message-ID: 
To: "Jakob Heitz (jheitz)" 
Content-Type: multipart/alternative; boundary=047d7bdc19d093f652054095f99b
Archived-At: 
Cc: heasley , "idr@ietf.org" 
Subject: Re: [Idr] Vendor Defaults (was Re: Review of draft-ietf-large-community-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: Sat, 05 Nov 2016 23:16:10 -0000

--047d7bdc19d093f652054095f99b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Jakob,

Would you mind to elaborate how do you plan to address IOS XE BGP code base
concerning the same topic ?

Thx,
R.


On Sun, Nov 6, 2016 at 12:13 AM, Jakob Heitz (jheitz) 
wrote:

> IOS-XR does not send communities or extended communities to eBGP neighbor=
s
> by default.
> To send communities, you need to configure
>   send-community-ebgp
> Under the neighbor address-family.
> To send extended communities, you need to configure
>   send-extended-community-ebgp
>
> The reason is that many operators use communities internal to an AS for
> many reasons and we don't want these to accidentally leak out to the wide=
r
> internet. If an operator intends to send communities outside of their own
> AS, then they need to make a conscious decision to do so. Along with that
> conscious decision, they should filter out all the internally used
> communities in a route-policy.
>
> In my large-community code, I have lumped them under send-community-ebgp.
> At this point, I am very open to suggestions for configuration. Once the
> code is released, it gets much harder to change configs.
>
> Thanks,
> Jakob.
>
>
> On Nov 5, 2016, at 12:53 PM, Brian Dickson 
> wrote:
>
>
>
> On Sat, Nov 5, 2016 at 11:57 AM, Robert Raszuk  wrote:
>
>> =E2=80=8B=E2=80=8B
>>
>>> =E2=80=8B=E2=80=8B
>>> However, given the heated discussion about prescribing a canonical
>>> representation for -large-communities, is this a subject for an IDR rfc=
?
>>>
>>
>> =E2=80=8BIMO it is. Reason being that RFC will be read by someone who is=
 tasked
>> to implement it and unless spec clearly at least recommends=E2=80=8B one=
 way we
>> will have a mix of behaviors.
>>
>>
>>>
> How about this: convert "Make it work exactly how you do RFC 1997" into a=
n
> I-D?
>
>
>> I really do not recall any EBC where customer were successful in asking
>> vendor to change any deployed defaults. Defaults once set during
>> implementation usually stay for a long time.
>>
>
> My experience has been, unexposed defaults can clearly only be changed by
> the vendor.
> Mixing versions of code, which contain DIFFERENT defaults is fraught with
> peril.
> No sane customer would EVER ask a vendor for different unexposed defaults=
.
>
> What I have always done is, ask/tell vendor: "Expose defaults explicitly
> in configs. Give us knobs to change defaults globally."  Having knobs to
> change defaults based on customer-provided values, solves the
> consistent-defaults problem while giving the customer control over what
> that default is.
>
> While I am sure many customers ask several vendors for this, it has not
> generally happened.
>
> (Feel free to convey this back to your management, BTW.)
>
>
>
>>
>>
>>> Is changing the language
>>> =E2=80=8B
>>> about propagating recognized transitive attributes going to change thes=
e
>>> vendor's defaults?
>>>
>>
>> =E2=80=8BWell I believe so. Notice that as much as folks likes large to =
be "like"
>> 1997 it is not 100%. Even by your cisco example .. there is already
>> send-community standard vs extended knob. Large =E2=80=8Bwill be new add=
ition and
>> in addition to "both" they will likely add also "all" keyword.
>>
>
> That is a vendor design decision issue.
>
> There is nothing to prevent a vendor from implementing large, by making
> large lock-step with 1997. For example, the implementation which supports
> large, could apply different semantics to "send community" to send BOTH
> 1997 AND large communities, without changing the syntax.
> (Such a change in semantics would probably be well advised to allow
> optional parameters to provide knobs for "1997-only", "large-only",
> "wide-only", "extended-only", or any combination of 1997, large, wide, an=
d
> extended).
>
>
>> As to why we have this knob in the first place from the early days I
>> recall it was based on ISPs who wanted to have RFC1997 local within thei=
r
>> AS only by default - such that they do not need any extra policy in orde=
r
>> not to propagate it over eBGP. Does the same design applies to Large ?
>>
>
> I don't recall any explanation for the default being the way it was. IMHO=
,
> vendors are free to change THEIR default, but SHOULD apply the same defau=
lt
> to both 1997 and large.
>
> Also IMHO, the "principal of least surprise" is something that vendors
> should adhere to.
> I cannot tell you how severely undisclosed and uncontrolled changes to
> defaults across upgrades have adversely affected networks I built and ran=
,
> and those of my compatriots.
>
> Please, stop trying to make "better" defaults. Just give us the knobs.
>
>
>> Note that I am not suggesting large must be propagate by default. But I
>> think it would be good to have mandated by the spec consistency across B=
GP
>> implementations - propagate or do not propagate.
>>
>>
> Until the knobs are universally in place across vendors: No, and please
> stop trying to advocate for this sort of thing.
>
> Brian
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
>

--047d7bdc19d093f652054095f99b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Jakob,

<=
/div>
Would you mind to elaborate how do you plan to addr=
ess IOS XE BGP code base concerning the same topic ?=C2=A0

Thx,
R.
=



On Sun, Nov 6, 2016 at 12:13 AM, Jakob Heitz (jheitz) <jh=
eitz@cisco.com> wrote:







IOS-XR does not send communities or extended communities to eBGP neigh=
bors by default.


To send communities, you need to configure=C2=A0



Under the neighbor address-family.


To send extended communities, you need to configure








The reason is that many operators use communities internal to an AS fo=
r many reasons and we don't want these to accidentally leak out to the =
wider internet. If an operator intends to send communities outside of their=
 own AS, then they need to make a conscious
 decision to do so. Along with that conscious decision, they should filter =
out all the internally used communities in a route-policy.







In my large-community code, I have lumped them under send-community-eb=
gp. At this point, I am very open to suggestions for configuration. Once th=
e code is released, it gets much harder to change configs.




Thanks,


Jakob.













On Nov 5, 2016, at 12:53 PM, Brian Dickson <brian.peter.dickson@gmail.com> wrote:
















On Sat, Nov 5, 2016 at 11:57 AM, Robert Raszuk <=
span dir=3D"ltr">
<robert@raszuk.ne=
t> wrote:






=E2=
=80=8B=E2=80=8B









=E2=80=8B=E2=80=8B

However, given the heated discussion about prescribing a canonical

representation for -large-communities, is this a subject for an IDR rfc?











=E2=
=80=8BIMO it is. Reason being that RFC will be read by someone who is taske=
d to implement it and unless spec clearly at least recommends=E2=80=8B one =
way we will have a mix of behaviors.=C2=A0





=C2=A0




























How about this: convert "Make it work exactly how you do RFC 1997=
" into an I-D?


=C2=A0












I rea=
lly do not recall any EBC where customer were successful in asking vendor t=
o change any deployed defaults. Defaults once set during implementation usu=
ally stay for a long time.=C2=A0

















My experience has been, unexposed defaults can clearly only be changed=
 by the vendor.


Mixing versions of code, which contain DIFFERENT defaults is fraught w=
ith peril.


No sane customer would EVER ask a vendor for different unexposed defau=
lts.







What I have always done is, ask/tell vendor: "Expose defaults exp=
licitly in configs. Give us knobs to change defaults globally." =C2=A0=
Having knobs to change defaults based on customer-provided values, solves t=
he consistent-defaults problem while giving the
 customer control over what that default is.







While I am sure many customers ask several vendors for this, it has no=
t generally happened.







(Feel free to convey this back to your management, BTW.)







=C2=A0












=C2=A0








Is changing the language


=E2=80=8B=C2=A0

about propagating recognized transitive attributes going to change these
vendor's defaults?












=E2=
=80=8BWell I believe so. Notice that as much as folks likes large to be &qu=
ot;like" 1997 it is not 100%. Even by your cisco example .. there is a=
lready send-community standard vs extended knob. Large
 =E2=80=8Bwill be new addition and in addition to "both" they wil=
l likely add also "all" keyword.=C2=A0













That is a vendor design decision issue.







There is nothing to prevent a vendor from implementing large, by makin=
g large lock-step with 1997. For example, the implementation which supports=
 large, could apply different semantics to "send community" to se=
nd BOTH 1997 AND large communities, without
 changing the syntax.


(Such a change in semantics would probably be well advised to allow op=
tional parameters to provide knobs for "1997-only", "large-o=
nly", "wide-only", "extended-only", or any combina=
tion of 1997, large, wide, and extended).


=C2=A0










As to=
 why we have this knob in the first place from the early days I recall it w=
as based on ISPs who wanted to have RFC1997 local within their AS only by d=
efault - such that they do not need
 any extra policy in order not to propagate it over eBGP. Does the same des=
ign applies to Large ?













I don't recall any explanation for the default being the way it wa=
s. IMHO, vendors are free to change THEIR default, but SHOULD apply the sam=
e default to both 1997 and large.







Also IMHO, the "principal of least surprise" is something th=
at vendors should adhere to.


I cannot tell you how severely undisclosed and uncontrolled changes to=
 defaults across upgrades have adversely affected networks I built and ran,=
 and those of my compatriots.







Please, stop trying to make "better" defaults. Just give us =
the knobs.


=C2=A0








Note =
that I am not suggesting large must be propagate by default. But I think it=
 would be good to have mandated by the spec consistency across BGP implemen=
tations - propagate or do not propagate.=C2=A0


















Until the knobs are universally in place across vendors: No, and pleas=
e stop trying to advocate for this sort of thing.







Brian=C2=A0














_______________________________________________

Idr mailing list

Idr@ietf.org

https://www.ietf.org/mailman/listinfo/idr












--047d7bdc19d093f652054095f99b--


From nobody Sat Nov  5 21:08:52 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF06412943E for ; Sat,  5 Nov 2016 21:08:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.699
X-Spam-Level: 
X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, 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 JX3TntnlyKsw for ; Sat,  5 Nov 2016 21:08:50 -0700 (PDT)
Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1027B12943D for ; Sat,  5 Nov 2016 21:08:50 -0700 (PDT)
Received: by guelah.shrubbery.net (Postfix, from userid 7053) id 87A347A15C; Sun,  6 Nov 2016 04:08:49 +0000 (UTC)
Date: Sun, 6 Nov 2016 04:08:49 +0000
From: heasley 
To: "Jakob Heitz (jheitz)" 
Message-ID: <20161106040849.GB18931@shrubbery.net>
References:  <86860386-9C2B-4BD5-B457-2A6DA5446CF3@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <86860386-9C2B-4BD5-B457-2A6DA5446CF3@cisco.com>
X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc
X-note: live free, or die!
X-homer: i just want to have a beer while i am caring.
X-Claimation: an engineer needs a manager like a fish needs a bicycle
X-reality: only YOU can put an end to the embarrassment that is Tom Cruise
User-Agent: Mutt/1.6.1 (2016-04-27)
Archived-At: 
Cc: heasley , "idr@ietf.org" , Robert Raszuk 
Subject: Re: [Idr] Vendor Defaults (was Re: Review of draft-ietf-large-community-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: Sun, 06 Nov 2016 04:08:52 -0000

Sat, Nov 05, 2016 at 11:13:46PM +0000, Jakob Heitz (jheitz):
> IOS-XR does not send communities or extended communities to eBGP neighbors by default.
> To send communities, you need to configure
>   send-community-ebgp
> Under the neighbor address-family.
> To send extended communities, you need to configure
>   send-extended-community-ebgp
> 
> The reason is that many operators use communities internal to an AS for many reasons and we don't want these to accidentally leak out to the wider internet. If an operator intends to send communities outside of their own AS, then they need to make a conscious decision to do so. Along with that conscious decision, they should filter out all the internally used communities in a route-policy.
> 
> In my large-community code, I have lumped them under send-community-ebgp. At this point, I am very open to suggestions for configuration. Once the code is released, it gets much harder to change configs.

If you consider draft-grow-bgp-reject, does that change your opinion about
filtering needing to be the default?


From nobody Sat Nov  5 22:16:50 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CCFB12969B for ; Sat,  5 Nov 2016 22:16:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.699
X-Spam-Level: 
X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, 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 o05oYVv05LEd for ; Sat,  5 Nov 2016 22:16:48 -0700 (PDT)
Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F2EE129690 for ; Sat,  5 Nov 2016 22:16:48 -0700 (PDT)
Received: by guelah.shrubbery.net (Postfix, from userid 7053) id 8580E7A277; Sun,  6 Nov 2016 05:16:47 +0000 (UTC)
Date: Sun, 6 Nov 2016 05:16:47 +0000
From: heasley 
To: Robert Raszuk 
Message-ID: <20161106051647.GD18931@shrubbery.net>
References: <20161104221030.GD37681@Vurt.lan> <0919e676e12d49d1a2ba30f4acc3b273@XCH-ALN-014.cisco.com> <20161104230536.GJ37681@Vurt.lan> <19AB2A007F56DB4E8257F949A2FB9858C87AFC6E@NKGEML515-MBX.china.huawei.com> <20161105103526.GM952@Vurt.local>  <20161105174229.GG98782@shrubbery.net>  <20161105183517.GI98782@shrubbery.net> 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc
X-note: live free, or die!
X-homer: i just want to have a beer while i am caring.
X-Claimation: an engineer needs a manager like a fish needs a bicycle
X-reality: only YOU can put an end to the embarrassment that is Tom Cruise
User-Agent: Mutt/1.6.1 (2016-04-27)
Archived-At: 
Cc: heasley , "idr@ietf.org" 
Subject: Re: [Idr] Review of draft-ietf-large-community-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: Sun, 06 Nov 2016 05:16:49 -0000

Sat, Nov 05, 2016 at 07:57:28PM +0100, Robert Raszuk:
> > However, given the heated discussion about prescribing a canonical
> > representation for -large-communities, is this a subject for an IDR rfc?
> >
> 
> ​IMO it is. Reason being that RFC will be read by someone who is tasked to
> implement it and unless spec clearly at least recommends​ one way we will
> have a mix of behaviors.
> 
> 
> > Isn't it a subject for a customer-vendor meeting?
> 
> 
> Honestly customer-vendor ​meetings are for new policy knobs. I really do
> not recall any EBC where customer were successful in asking vendor to
> change any deployed defaults. Defaults once set during implementation
> usually stay for a long time.

i'd be shocked if operators dont remember a few that they've been requesting
for 2 decades (sorry to pick on cisco)

	no ip proxy-arp
	no ip redirects
	no ip directed-broadcast

iirc, all 3 are the default on ios-xr.

> > Is changing the language
> > ​
> > about propagating recognized transitive attributes going to change these
> > vendor's defaults?
> >
> 
> ​Well I believe so. Notice that as much as folks likes large to be "like"
> 1997 it is not 100%. Even by your cisco example .. there is already
> send-community standard vs extended knob. Large ​will be new addition and
> in addition to "both" they will likely add also "all" keyword.
> 
> So if we want to make large nicely transitive I think it is now a good time
> to add this to draft/rfc just to have a common agreed way on the expected
> outcome in any implementation.

shouldnt you clarify in 4271 - that which is transitive is transitive (by
default), recognized or not.

> As to why we have this knob in the first place from the early days I recall
> it was based on ISPs who wanted to have RFC1997 local within their AS only
> by default - such that they do not need any extra policy in order not to
> propagate it over eBGP. Does the same design applies to Large ?

not imo; doesnt apply to 1997 either - not in year 1997 either, again - imo.


From nobody Sat Nov  5 22:43:46 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12F7B129579 for ; Sat,  5 Nov 2016 22:43:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.018
X-Spam-Level: 
X-Spam-Status: No, score=-16.018 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=-1.497, 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 rYBhB_wvG4Cp for ; Sat,  5 Nov 2016 22:43:43 -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 0B9DE129532 for ; Sat,  5 Nov 2016 22:43:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1580; q=dns/txt; s=iport; t=1478411022; x=1479620622; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ncZEF1VBIjBDizTXTVpqruC6LY6mW8F79GaCLa7reLs=; b=KvBRSrKyV7OP8mY6H7NhZSYbbTVu99dyqJauziON/JkvTLuFHucetCIl XVFdDP3VnQnRmnkzoBkyCXl5K01lbY3BD4dnlIEeRDjbx2dqb7rGIt1/m XRzbqYrRXQ2T2yXleUC73ymolDugZld4FWP+WXYdbIsL6IJ3GfQYIL1QX 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DaAwDSwR5Y/40NJK1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgy4BAQEBAR+BVKQ2llqGJAKCCUIRAQIBAQEBAQEBYiiEYQEBAQMBOj8?= =?us-ascii?q?FCwIBCBgdARAyJQIEDgUUiDwIskeLMgEBAQEBAQEBAQEBAQEBAQEBAQEBHYY+g?= =?us-ascii?q?X2CWIRHgzGCLwEEmicBkEOQEI0qhAUBNCF6hSpyh0wBAQE?=
X-IronPort-AV: E=Sophos;i="5.31,600,1473120000"; d="scan'208";a="170883225"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Nov 2016 05:43:42 +0000
Received: from XCH-ALN-012.cisco.com (xch-aln-012.cisco.com [173.36.7.22]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id uA65hgga008139 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 6 Nov 2016 05:43:42 GMT
Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-012.cisco.com (173.36.7.22) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 6 Nov 2016 00:43:41 -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; Sun, 6 Nov 2016 00:43:42 -0500
From: "Jakob Heitz (jheitz)" 
To: heasley 
Thread-Topic: [Idr] Vendor Defaults (was Re: Review of draft-ietf-large-community-06.txt)
Thread-Index: AQHSN546iba0WaPSYk6woE67Sz8aq6DLBUg9gAC3BID//7Xu+A==
Date: Sun, 6 Nov 2016 05:43:42 +0000
Message-ID: <5BD3C90E-CC0E-42D2-9ACD-5787FC75BF0A@cisco.com>
References:  <86860386-9C2B-4BD5-B457-2A6DA5446CF3@cisco.com>, <20161106040849.GB18931@shrubbery.net>
In-Reply-To: <20161106040849.GB18931@shrubbery.net>
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: 
Cc: "idr@ietf.org" , Robert Raszuk 
Subject: Re: [Idr] Vendor Defaults (was Re: Review of draft-ietf-large-community-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: Sun, 06 Nov 2016 05:43:45 -0000

It does not change my opinion. My opinion is that we should filter by defau=
lt at the EBGP boundary. IOS-XR does that. Cisco recognized the problem add=
ressed by draft-grow-bgp-reject back when IOS-XR was designed. Unfortunatel=
y, it was too late to change the default in IOS. If IOS changes that defaul=
t, it would break many existing deployments.

Thanks,
Jakob.


> On Nov 5, 2016, at 9:08 PM, heasley  wrote:
>=20
> Sat, Nov 05, 2016 at 11:13:46PM +0000, Jakob Heitz (jheitz):
>> IOS-XR does not send communities or extended communities to eBGP neighbo=
rs by default.
>> To send communities, you need to configure
>>  send-community-ebgp
>> Under the neighbor address-family.
>> To send extended communities, you need to configure
>>  send-extended-community-ebgp
>>=20
>> The reason is that many operators use communities internal to an AS for =
many reasons and we don't want these to accidentally leak out to the wider =
internet. If an operator intends to send communities outside of their own A=
S, then they need to make a conscious decision to do so. Along with that co=
nscious decision, they should filter out all the internally used communitie=
s in a route-policy.
>>=20
>> In my large-community code, I have lumped them under send-community-ebgp=
. At this point, I am very open to suggestions for configuration. Once the =
code is released, it gets much harder to change configs.
>=20
> If you consider draft-grow-bgp-reject, does that change your opinion abou=
t
> filtering needing to be the default?


From nobody Sat Nov  5 22:50:05 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2689C1294E9 for ; Sat,  5 Nov 2016 22:50:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.017
X-Spam-Level: 
X-Spam-Status: No, score=-16.017 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=-1.497, 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 qCuULSSOqCHB for ; Sat,  5 Nov 2016 22:50:02 -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 DB8E312949A for ; Sat,  5 Nov 2016 22:50:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21681; q=dns/txt; s=iport; t=1478411401; x=1479621001; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=nzpoPY/qtJQdJw2ykMkbIdhasYPodU/4EoLINuYHm8Y=; b=QUJRZyCUJAPssDIYr1lioCQe78QN2KW1umqEDo4ERnm1abQfjKfMhViU E7+EGgvKCHt33lYe2MSU+osI1uHYa1k7Z0tVfcJ3yI/zvAoF8dGTcntFH 2f8Z1pfl5kkkCFIk8GAyOrCJpzdmAX2/8E1aBN7ToolJnON9QNx9qmv19 E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CBAwD/wx5Y/5BdJa1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgy4BAQEBAR9YLU+NOJlehQiHUIUagggeAQqFewIagW8/FAECAQEBAQE?= =?us-ascii?q?BAWIohGIBAQQBAQEgSwsQAgEGAjUKAwICAh8GCxQRAgQOBRSIKgMXDpI7nT+CQ?= =?us-ascii?q?Ic3DYNuAQEBAQEBAQEBAQEBAQEBAQEBAQEBHIY+gX0IglCCR4FzS4JGLYIvBZR?= =?us-ascii?q?HhSs1AYk/gwdEgzmBbheEWYM7hXeJCIQihAUBHjd6G4JbgjRyAYURgjoBAQE?=
X-IronPort-AV: E=Sophos;i="5.31,600,1473120000";  d="scan'208,217";a="170884077"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Nov 2016 05:50:00 +0000
Received: from XCH-RCD-012.cisco.com (xch-rcd-012.cisco.com [173.37.102.22]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id uA65o0kf027223 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 6 Nov 2016 05:50:00 GMT
Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-012.cisco.com (173.37.102.22) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 6 Nov 2016 00:50:01 -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; Sun, 6 Nov 2016 00:50:01 -0500
From: "Jakob Heitz (jheitz)" 
To: Robert Raszuk 
Thread-Topic: [Idr] Vendor Defaults (was Re: Review of draft-ietf-large-community-06.txt)
Thread-Index: AQHSN546iba0WaPSYk6woE67Sz8aq6DLBUg9gABUdQCAABpB7Q==
Date: Sun, 6 Nov 2016 05:50:01 +0000
Message-ID: <225A5668-BE11-4575-A81F-115D9A03A96C@cisco.com>
References:  <86860386-9C2B-4BD5-B457-2A6DA5446CF3@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
Content-Type: multipart/alternative; boundary="_000_225A5668BE114575A81F115D9A03A96Cciscocom_"
MIME-Version: 1.0
Archived-At: 
Cc: heasley , "idr@ietf.org" 
Subject: Re: [Idr] Vendor Defaults (was Re: Review of draft-ietf-large-community-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: Sun, 06 Nov 2016 05:50:04 -0000

--_000_225A5668BE114575A81F115D9A03A96Cciscocom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SSBjYW5ub3QgdGVsbCB5b3UgdGhhdCBSb2JlcnQuDQoNClRoYW5rcywNCkpha29iLg0KDQoNCk9u
IE5vdiA1LCAyMDE2LCBhdCA0OjE2IFBNLCBSb2JlcnQgUmFzenVrIDxyb2JlcnRAcmFzenVrLm5l
dDxtYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQ+PiB3cm90ZToNCg0KSGkgSmFrb2IsDQoNCldvdWxk
IHlvdSBtaW5kIHRvIGVsYWJvcmF0ZSBob3cgZG8geW91IHBsYW4gdG8gYWRkcmVzcyBJT1MgWEUg
QkdQIGNvZGUgYmFzZSBjb25jZXJuaW5nIHRoZSBzYW1lIHRvcGljID8NCg0KVGh4LA0KUi4NCg0K
DQpPbiBTdW4sIE5vdiA2LCAyMDE2IGF0IDEyOjEzIEFNLCBKYWtvYiBIZWl0eiAoamhlaXR6KSA8
amhlaXR6QGNpc2NvLmNvbTxtYWlsdG86amhlaXR6QGNpc2NvLmNvbT4+IHdyb3RlOg0KSU9TLVhS
IGRvZXMgbm90IHNlbmQgY29tbXVuaXRpZXMgb3IgZXh0ZW5kZWQgY29tbXVuaXRpZXMgdG8gZUJH
UCBuZWlnaGJvcnMgYnkgZGVmYXVsdC4NClRvIHNlbmQgY29tbXVuaXRpZXMsIHlvdSBuZWVkIHRv
IGNvbmZpZ3VyZQ0KICBzZW5kLWNvbW11bml0eS1lYmdwPGh0dHA6Ly9zZW5kLWNvbW11bml0eS1l
YmdwPg0KVW5kZXIgdGhlIG5laWdoYm9yIGFkZHJlc3MtZmFtaWx5Lg0KVG8gc2VuZCBleHRlbmRl
ZCBjb21tdW5pdGllcywgeW91IG5lZWQgdG8gY29uZmlndXJlDQogIHNlbmQtZXh0ZW5kZWQtY29t
bXVuaXR5LWViZ3A8aHR0cDovL3NlbmQtZXh0ZW5kZWQtY29tbXVuaXR5LWViZ3A+DQoNClRoZSBy
ZWFzb24gaXMgdGhhdCBtYW55IG9wZXJhdG9ycyB1c2UgY29tbXVuaXRpZXMgaW50ZXJuYWwgdG8g
YW4gQVMgZm9yIG1hbnkgcmVhc29ucyBhbmQgd2UgZG9uJ3Qgd2FudCB0aGVzZSB0byBhY2NpZGVu
dGFsbHkgbGVhayBvdXQgdG8gdGhlIHdpZGVyIGludGVybmV0LiBJZiBhbiBvcGVyYXRvciBpbnRl
bmRzIHRvIHNlbmQgY29tbXVuaXRpZXMgb3V0c2lkZSBvZiB0aGVpciBvd24gQVMsIHRoZW4gdGhl
eSBuZWVkIHRvIG1ha2UgYSBjb25zY2lvdXMgZGVjaXNpb24gdG8gZG8gc28uIEFsb25nIHdpdGgg
dGhhdCBjb25zY2lvdXMgZGVjaXNpb24sIHRoZXkgc2hvdWxkIGZpbHRlciBvdXQgYWxsIHRoZSBp
bnRlcm5hbGx5IHVzZWQgY29tbXVuaXRpZXMgaW4gYSByb3V0ZS1wb2xpY3kuDQoNCkluIG15IGxh
cmdlLWNvbW11bml0eSBjb2RlLCBJIGhhdmUgbHVtcGVkIHRoZW0gdW5kZXIgc2VuZC1jb21tdW5p
dHktZWJncC4gQXQgdGhpcyBwb2ludCwgSSBhbSB2ZXJ5IG9wZW4gdG8gc3VnZ2VzdGlvbnMgZm9y
IGNvbmZpZ3VyYXRpb24uIE9uY2UgdGhlIGNvZGUgaXMgcmVsZWFzZWQsIGl0IGdldHMgbXVjaCBo
YXJkZXIgdG8gY2hhbmdlIGNvbmZpZ3MuDQoNClRoYW5rcywNCkpha29iLg0KDQoNCk9uIE5vdiA1
LCAyMDE2LCBhdCAxMjo1MyBQTSwgQnJpYW4gRGlja3NvbiA8YnJpYW4ucGV0ZXIuZGlja3NvbkBn
bWFpbC5jb208bWFpbHRvOmJyaWFuLnBldGVyLmRpY2tzb25AZ21haWwuY29tPj4gd3JvdGU6DQoN
Cg0KDQpPbiBTYXQsIE5vdiA1LCAyMDE2IGF0IDExOjU3IEFNLCBSb2JlcnQgUmFzenVrIDxyb2Jl
cnRAcmFzenVrLm5ldDxtYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQ+PiB3cm90ZToNCuKAi+KAiw0K
4oCL4oCLDQpIb3dldmVyLCBnaXZlbiB0aGUgaGVhdGVkIGRpc2N1c3Npb24gYWJvdXQgcHJlc2Ny
aWJpbmcgYSBjYW5vbmljYWwNCnJlcHJlc2VudGF0aW9uIGZvciAtbGFyZ2UtY29tbXVuaXRpZXMs
IGlzIHRoaXMgYSBzdWJqZWN0IGZvciBhbiBJRFIgcmZjPw0KDQrigItJTU8gaXQgaXMuIFJlYXNv
biBiZWluZyB0aGF0IFJGQyB3aWxsIGJlIHJlYWQgYnkgc29tZW9uZSB3aG8gaXMgdGFza2VkIHRv
IGltcGxlbWVudCBpdCBhbmQgdW5sZXNzIHNwZWMgY2xlYXJseSBhdCBsZWFzdCByZWNvbW1lbmRz
4oCLIG9uZSB3YXkgd2Ugd2lsbCBoYXZlIGEgbWl4IG9mIGJlaGF2aW9ycy4NCg0KDQpIb3cgYWJv
dXQgdGhpczogY29udmVydCAiTWFrZSBpdCB3b3JrIGV4YWN0bHkgaG93IHlvdSBkbyBSRkMgMTk5
NyIgaW50byBhbiBJLUQ/DQoNCkkgcmVhbGx5IGRvIG5vdCByZWNhbGwgYW55IEVCQyB3aGVyZSBj
dXN0b21lciB3ZXJlIHN1Y2Nlc3NmdWwgaW4gYXNraW5nIHZlbmRvciB0byBjaGFuZ2UgYW55IGRl
cGxveWVkIGRlZmF1bHRzLiBEZWZhdWx0cyBvbmNlIHNldCBkdXJpbmcgaW1wbGVtZW50YXRpb24g
dXN1YWxseSBzdGF5IGZvciBhIGxvbmcgdGltZS4NCg0KTXkgZXhwZXJpZW5jZSBoYXMgYmVlbiwg
dW5leHBvc2VkIGRlZmF1bHRzIGNhbiBjbGVhcmx5IG9ubHkgYmUgY2hhbmdlZCBieSB0aGUgdmVu
ZG9yLg0KTWl4aW5nIHZlcnNpb25zIG9mIGNvZGUsIHdoaWNoIGNvbnRhaW4gRElGRkVSRU5UIGRl
ZmF1bHRzIGlzIGZyYXVnaHQgd2l0aCBwZXJpbC4NCk5vIHNhbmUgY3VzdG9tZXIgd291bGQgRVZF
UiBhc2sgYSB2ZW5kb3IgZm9yIGRpZmZlcmVudCB1bmV4cG9zZWQgZGVmYXVsdHMuDQoNCldoYXQg
SSBoYXZlIGFsd2F5cyBkb25lIGlzLCBhc2svdGVsbCB2ZW5kb3I6ICJFeHBvc2UgZGVmYXVsdHMg
ZXhwbGljaXRseSBpbiBjb25maWdzLiBHaXZlIHVzIGtub2JzIHRvIGNoYW5nZSBkZWZhdWx0cyBn
bG9iYWxseS4iICBIYXZpbmcga25vYnMgdG8gY2hhbmdlIGRlZmF1bHRzIGJhc2VkIG9uIGN1c3Rv
bWVyLXByb3ZpZGVkIHZhbHVlcywgc29sdmVzIHRoZSBjb25zaXN0ZW50LWRlZmF1bHRzIHByb2Js
ZW0gd2hpbGUgZ2l2aW5nIHRoZSBjdXN0b21lciBjb250cm9sIG92ZXIgd2hhdCB0aGF0IGRlZmF1
bHQgaXMuDQoNCldoaWxlIEkgYW0gc3VyZSBtYW55IGN1c3RvbWVycyBhc2sgc2V2ZXJhbCB2ZW5k
b3JzIGZvciB0aGlzLCBpdCBoYXMgbm90IGdlbmVyYWxseSBoYXBwZW5lZC4NCg0KKEZlZWwgZnJl
ZSB0byBjb252ZXkgdGhpcyBiYWNrIHRvIHlvdXIgbWFuYWdlbWVudCwgQlRXLikNCg0KDQoNCklz
IGNoYW5naW5nIHRoZSBsYW5ndWFnZQ0K4oCLDQphYm91dCBwcm9wYWdhdGluZyByZWNvZ25pemVk
IHRyYW5zaXRpdmUgYXR0cmlidXRlcyBnb2luZyB0byBjaGFuZ2UgdGhlc2UNCnZlbmRvcidzIGRl
ZmF1bHRzPw0KDQrigItXZWxsIEkgYmVsaWV2ZSBzby4gTm90aWNlIHRoYXQgYXMgbXVjaCBhcyBm
b2xrcyBsaWtlcyBsYXJnZSB0byBiZSAibGlrZSIgMTk5NyBpdCBpcyBub3QgMTAwJS4gRXZlbiBi
eSB5b3VyIGNpc2NvIGV4YW1wbGUgLi4gdGhlcmUgaXMgYWxyZWFkeSBzZW5kLWNvbW11bml0eSBz
dGFuZGFyZCB2cyBleHRlbmRlZCBrbm9iLiBMYXJnZSDigIt3aWxsIGJlIG5ldyBhZGRpdGlvbiBh
bmQgaW4gYWRkaXRpb24gdG8gImJvdGgiIHRoZXkgd2lsbCBsaWtlbHkgYWRkIGFsc28gImFsbCIg
a2V5d29yZC4NCg0KVGhhdCBpcyBhIHZlbmRvciBkZXNpZ24gZGVjaXNpb24gaXNzdWUuDQoNClRo
ZXJlIGlzIG5vdGhpbmcgdG8gcHJldmVudCBhIHZlbmRvciBmcm9tIGltcGxlbWVudGluZyBsYXJn
ZSwgYnkgbWFraW5nIGxhcmdlIGxvY2stc3RlcCB3aXRoIDE5OTcuIEZvciBleGFtcGxlLCB0aGUg
aW1wbGVtZW50YXRpb24gd2hpY2ggc3VwcG9ydHMgbGFyZ2UsIGNvdWxkIGFwcGx5IGRpZmZlcmVu
dCBzZW1hbnRpY3MgdG8gInNlbmQgY29tbXVuaXR5IiB0byBzZW5kIEJPVEggMTk5NyBBTkQgbGFy
Z2UgY29tbXVuaXRpZXMsIHdpdGhvdXQgY2hhbmdpbmcgdGhlIHN5bnRheC4NCihTdWNoIGEgY2hh
bmdlIGluIHNlbWFudGljcyB3b3VsZCBwcm9iYWJseSBiZSB3ZWxsIGFkdmlzZWQgdG8gYWxsb3cg
b3B0aW9uYWwgcGFyYW1ldGVycyB0byBwcm92aWRlIGtub2JzIGZvciAiMTk5Ny1vbmx5IiwgImxh
cmdlLW9ubHkiLCAid2lkZS1vbmx5IiwgImV4dGVuZGVkLW9ubHkiLCBvciBhbnkgY29tYmluYXRp
b24gb2YgMTk5NywgbGFyZ2UsIHdpZGUsIGFuZCBleHRlbmRlZCkuDQoNCkFzIHRvIHdoeSB3ZSBo
YXZlIHRoaXMga25vYiBpbiB0aGUgZmlyc3QgcGxhY2UgZnJvbSB0aGUgZWFybHkgZGF5cyBJIHJl
Y2FsbCBpdCB3YXMgYmFzZWQgb24gSVNQcyB3aG8gd2FudGVkIHRvIGhhdmUgUkZDMTk5NyBsb2Nh
bCB3aXRoaW4gdGhlaXIgQVMgb25seSBieSBkZWZhdWx0IC0gc3VjaCB0aGF0IHRoZXkgZG8gbm90
IG5lZWQgYW55IGV4dHJhIHBvbGljeSBpbiBvcmRlciBub3QgdG8gcHJvcGFnYXRlIGl0IG92ZXIg
ZUJHUC4gRG9lcyB0aGUgc2FtZSBkZXNpZ24gYXBwbGllcyB0byBMYXJnZSA/DQoNCkkgZG9uJ3Qg
cmVjYWxsIGFueSBleHBsYW5hdGlvbiBmb3IgdGhlIGRlZmF1bHQgYmVpbmcgdGhlIHdheSBpdCB3
YXMuIElNSE8sIHZlbmRvcnMgYXJlIGZyZWUgdG8gY2hhbmdlIFRIRUlSIGRlZmF1bHQsIGJ1dCBT
SE9VTEQgYXBwbHkgdGhlIHNhbWUgZGVmYXVsdCB0byBib3RoIDE5OTcgYW5kIGxhcmdlLg0KDQpB
bHNvIElNSE8sIHRoZSAicHJpbmNpcGFsIG9mIGxlYXN0IHN1cnByaXNlIiBpcyBzb21ldGhpbmcg
dGhhdCB2ZW5kb3JzIHNob3VsZCBhZGhlcmUgdG8uDQpJIGNhbm5vdCB0ZWxsIHlvdSBob3cgc2V2
ZXJlbHkgdW5kaXNjbG9zZWQgYW5kIHVuY29udHJvbGxlZCBjaGFuZ2VzIHRvIGRlZmF1bHRzIGFj
cm9zcyB1cGdyYWRlcyBoYXZlIGFkdmVyc2VseSBhZmZlY3RlZCBuZXR3b3JrcyBJIGJ1aWx0IGFu
ZCByYW4sIGFuZCB0aG9zZSBvZiBteSBjb21wYXRyaW90cy4NCg0KUGxlYXNlLCBzdG9wIHRyeWlu
ZyB0byBtYWtlICJiZXR0ZXIiIGRlZmF1bHRzLiBKdXN0IGdpdmUgdXMgdGhlIGtub2JzLg0KDQpO
b3RlIHRoYXQgSSBhbSBub3Qgc3VnZ2VzdGluZyBsYXJnZSBtdXN0IGJlIHByb3BhZ2F0ZSBieSBk
ZWZhdWx0LiBCdXQgSSB0aGluayBpdCB3b3VsZCBiZSBnb29kIHRvIGhhdmUgbWFuZGF0ZWQgYnkg
dGhlIHNwZWMgY29uc2lzdGVuY3kgYWNyb3NzIEJHUCBpbXBsZW1lbnRhdGlvbnMgLSBwcm9wYWdh
dGUgb3IgZG8gbm90IHByb3BhZ2F0ZS4NCg0KDQpVbnRpbCB0aGUga25vYnMgYXJlIHVuaXZlcnNh
bGx5IGluIHBsYWNlIGFjcm9zcyB2ZW5kb3JzOiBObywgYW5kIHBsZWFzZSBzdG9wIHRyeWluZyB0
byBhZHZvY2F0ZSBmb3IgdGhpcyBzb3J0IG9mIHRoaW5nLg0KDQpCcmlhbg0KX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklkciBtYWlsaW5nIGxpc3QNCklk
ckBpZXRmLm9yZzxtYWlsdG86SWRyQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9pZHINCg0K

--_000_225A5668BE114575A81F115D9A03A96Cciscocom_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8
ZGl2PkkgY2Fubm90IHRlbGwgeW91IHRoYXQgUm9iZXJ0Ljxicj4NCjxicj4NClRoYW5rcyw8YnI+
DQo8ZGl2Pkpha29iLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnI+
DQpPbiBOb3YgNSwgMjAxNiwgYXQgNDoxNiBQTSwgUm9iZXJ0IFJhc3p1ayAmbHQ7PGEgaHJlZj0i
bWFpbHRvOnJvYmVydEByYXN6dWsubmV0Ij5yb2JlcnRAcmFzenVrLm5ldDwvYT4mZ3Q7IHdyb3Rl
Ojxicj4NCjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2Pg0KPGRp
diBkaXI9Imx0ciI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1p
bHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj4NCkhpIEpha29i
LDwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFy
aWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQo8YnI+DQo8L2Rpdj4N
CjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2
ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPg0KV291bGQgeW91IG1pbmQgdG8gZWxh
Ym9yYXRlIGhvdyBkbyB5b3UgcGxhbiB0byBhZGRyZXNzIElPUyBYRSBCR1AgY29kZSBiYXNlIGNv
bmNlcm5pbmcgdGhlIHNhbWUgdG9waWMgPyZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxf
ZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2Zv
bnQtc2l6ZTpzbWFsbCI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQi
IHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6
c21hbGwiPg0KVGh4LDwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZv
bnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQpS
LjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFy
aWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQo8YnI+DQo8L2Rpdj4N
CjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxicj4NCjxkaXYgY2xhc3M9ImdtYWls
X3F1b3RlIj5PbiBTdW4sIE5vdiA2LCAyMDE2IGF0IDEyOjEzIEFNLCBKYWtvYiBIZWl0eiAoamhl
aXR6KSA8c3BhbiBkaXI9Imx0ciI+DQombHQ7PGEgaHJlZj0ibWFpbHRvOmpoZWl0ekBjaXNjby5j
b20iIHRhcmdldD0iX2JsYW5rIj5qaGVpdHpAY2lzY28uY29tPC9hPiZndDs8L3NwYW4+IHdyb3Rl
Ojxicj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAg
MCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRp
diBkaXI9ImF1dG8iPg0KPGRpdj5JT1MtWFIgZG9lcyBub3Qgc2VuZCBjb21tdW5pdGllcyBvciBl
eHRlbmRlZCBjb21tdW5pdGllcyB0byBlQkdQIG5laWdoYm9ycyBieSBkZWZhdWx0LjwvZGl2Pg0K
PGRpdj5UbyBzZW5kIGNvbW11bml0aWVzLCB5b3UgbmVlZCB0byBjb25maWd1cmUmbmJzcDs8L2Rp
dj4NCjxkaXY+Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iaHR0cDovL3NlbmQtY29tbXVuaXR5LWViZ3Ai
IHRhcmdldD0iX2JsYW5rIj5zZW5kLWNvbW11bml0eS1lYmdwPC9hPjwvZGl2Pg0KPGRpdj5VbmRl
ciB0aGUgbmVpZ2hib3IgYWRkcmVzcy1mYW1pbHkuPC9kaXY+DQo8ZGl2PlRvIHNlbmQgZXh0ZW5k
ZWQgY29tbXVuaXRpZXMsIHlvdSBuZWVkIHRvIGNvbmZpZ3VyZTwvZGl2Pg0KPGRpdj4mbmJzcDsm
bmJzcDs8YSBocmVmPSJodHRwOi8vc2VuZC1leHRlbmRlZC1jb21tdW5pdHktZWJncCIgdGFyZ2V0
PSJfYmxhbmsiPnNlbmQtZXh0ZW5kZWQtY29tbXVuaXR5LWViZ3A8L2E+PC9kaXY+DQo8ZGl2Pjxi
cj4NCjwvZGl2Pg0KPGRpdj5UaGUgcmVhc29uIGlzIHRoYXQgbWFueSBvcGVyYXRvcnMgdXNlIGNv
bW11bml0aWVzIGludGVybmFsIHRvIGFuIEFTIGZvciBtYW55IHJlYXNvbnMgYW5kIHdlIGRvbid0
IHdhbnQgdGhlc2UgdG8gYWNjaWRlbnRhbGx5IGxlYWsgb3V0IHRvIHRoZSB3aWRlciBpbnRlcm5l
dC4gSWYgYW4gb3BlcmF0b3IgaW50ZW5kcyB0byBzZW5kIGNvbW11bml0aWVzIG91dHNpZGUgb2Yg
dGhlaXIgb3duIEFTLCB0aGVuIHRoZXkgbmVlZCB0byBtYWtlIGEgY29uc2Npb3VzDQogZGVjaXNp
b24gdG8gZG8gc28uIEFsb25nIHdpdGggdGhhdCBjb25zY2lvdXMgZGVjaXNpb24sIHRoZXkgc2hv
dWxkIGZpbHRlciBvdXQgYWxsIHRoZSBpbnRlcm5hbGx5IHVzZWQgY29tbXVuaXRpZXMgaW4gYSBy
b3V0ZS1wb2xpY3kuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JbiBteSBsYXJnZS1j
b21tdW5pdHkgY29kZSwgSSBoYXZlIGx1bXBlZCB0aGVtIHVuZGVyIHNlbmQtY29tbXVuaXR5LWVi
Z3AuIEF0IHRoaXMgcG9pbnQsIEkgYW0gdmVyeSBvcGVuIHRvIHN1Z2dlc3Rpb25zIGZvciBjb25m
aWd1cmF0aW9uLiBPbmNlIHRoZSBjb2RlIGlzIHJlbGVhc2VkLCBpdCBnZXRzIG11Y2ggaGFyZGVy
IHRvIGNoYW5nZSBjb25maWdzLjxicj4NCjxicj4NCjxkaXY+VGhhbmtzLDxicj4NCjxkaXY+SmFr
b2IuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2
IGNsYXNzPSJoNSI+DQo8ZGl2Pjxicj4NCk9uIE5vdiA1LCAyMDE2LCBhdCAxMjo1MyBQTSwgQnJp
YW4gRGlja3NvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJyaWFuLnBldGVyLmRpY2tzb25AZ21haWwu
Y29tIiB0YXJnZXQ9Il9ibGFuayI+YnJpYW4ucGV0ZXIuZGlja3NvbkBnbWFpbC5jb208L2E+PHdi
cj4mZ3Q7IHdyb3RlOjxicj4NCjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+
DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PGJyPg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxi
cj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBTYXQsIE5vdiA1LCAyMDE2IGF0IDExOjU3
IEFNLCBSb2JlcnQgUmFzenVrIDxzcGFuIGRpcj0ibHRyIj4NCiZsdDs8YSBocmVmPSJtYWlsdG86
cm9iZXJ0QHJhc3p1ay5uZXQiIHRhcmdldD0iX2JsYW5rIj5yb2JlcnRAcmFzenVrLm5ldDwvYT4m
Z3Q7PC9zcGFuPiB3cm90ZTo8YnI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0
eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5n
LWxlZnQ6MWV4Ij4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6YXJp
YWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj7igIvigIs8L2Rpdj4NCjxk
aXYgY2xhc3M9ImdtYWlsX2V4dHJhIj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj48c3Bhbj4N
CjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4
O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBzdHls
ZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxs
O2Rpc3BsYXk6aW5saW5lIj4NCuKAi+KAizwvZGl2Pg0KSG93ZXZlciwgZ2l2ZW4gdGhlIGhlYXRl
ZCBkaXNjdXNzaW9uIGFib3V0IHByZXNjcmliaW5nIGEgY2Fub25pY2FsPGJyPg0KcmVwcmVzZW50
YXRpb24gZm9yIC1sYXJnZS1jb21tdW5pdGllcywgaXMgdGhpcyBhIHN1YmplY3QgZm9yIGFuIElE
UiByZmM/PGJyPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjwvc3Bhbj4NCjxk
aXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtm
b250LXNpemU6c21hbGwiPuKAi0lNTyBpdCBpcy4gUmVhc29uIGJlaW5nIHRoYXQgUkZDIHdpbGwg
YmUgcmVhZCBieSBzb21lb25lIHdobyBpcyB0YXNrZWQgdG8gaW1wbGVtZW50IGl0IGFuZCB1bmxl
c3Mgc3BlYyBjbGVhcmx5IGF0IGxlYXN0IHJlY29tbWVuZHPigIsgb25lIHdheSB3ZSB3aWxsIGhh
dmUgYSBtaXggb2YgYmVoYXZpb3JzLiZuYnNwOzwvZGl2Pg0KPC9kaXY+DQo8c3Bhbj4NCjxkaXY+
Jm5ic3A7PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxl
PSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxl
ZnQ6MWV4Ij4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJmb250
LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxi
cj4NCjwvZGl2Pg0KPGRpdj5Ib3cgYWJvdXQgdGhpczogY29udmVydCAmcXVvdDtNYWtlIGl0IHdv
cmsgZXhhY3RseSBob3cgeW91IGRvIFJGQyAxOTk3JnF1b3Q7IGludG8gYW4gSS1EPzwvZGl2Pg0K
PGRpdj4mbmJzcDs8L2Rpdj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9
Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVm
dDoxZXgiPg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+DQo8ZGl2
IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6YXJp
YWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj5JIHJlYWxseSBkbyBub3Qg
cmVjYWxsIGFueSBFQkMgd2hlcmUgY3VzdG9tZXIgd2VyZSBzdWNjZXNzZnVsIGluIGFza2luZyB2
ZW5kb3IgdG8gY2hhbmdlIGFueSBkZXBsb3llZCBkZWZhdWx0cy4gRGVmYXVsdHMgb25jZSBzZXQg
ZHVyaW5nIGltcGxlbWVudGF0aW9uIHVzdWFsbHkgc3RheSBmb3IgYSBsb25nIHRpbWUuJm5ic3A7
PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxk
aXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pk15IGV4cGVyaWVuY2UgaGFzIGJlZW4sIHVuZXhwb3NlZCBk
ZWZhdWx0cyBjYW4gY2xlYXJseSBvbmx5IGJlIGNoYW5nZWQgYnkgdGhlIHZlbmRvci48L2Rpdj4N
CjxkaXY+TWl4aW5nIHZlcnNpb25zIG9mIGNvZGUsIHdoaWNoIGNvbnRhaW4gRElGRkVSRU5UIGRl
ZmF1bHRzIGlzIGZyYXVnaHQgd2l0aCBwZXJpbC48L2Rpdj4NCjxkaXY+Tm8gc2FuZSBjdXN0b21l
ciB3b3VsZCBFVkVSIGFzayBhIHZlbmRvciBmb3IgZGlmZmVyZW50IHVuZXhwb3NlZCBkZWZhdWx0
cy48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PldoYXQgSSBoYXZlIGFsd2F5cyBkb25l
IGlzLCBhc2svdGVsbCB2ZW5kb3I6ICZxdW90O0V4cG9zZSBkZWZhdWx0cyBleHBsaWNpdGx5IGlu
IGNvbmZpZ3MuIEdpdmUgdXMga25vYnMgdG8gY2hhbmdlIGRlZmF1bHRzIGdsb2JhbGx5LiZxdW90
OyAmbmJzcDtIYXZpbmcga25vYnMgdG8gY2hhbmdlIGRlZmF1bHRzIGJhc2VkIG9uIGN1c3RvbWVy
LXByb3ZpZGVkIHZhbHVlcywgc29sdmVzIHRoZSBjb25zaXN0ZW50LWRlZmF1bHRzIHByb2JsZW0g
d2hpbGUgZ2l2aW5nIHRoZQ0KIGN1c3RvbWVyIGNvbnRyb2wgb3ZlciB3aGF0IHRoYXQgZGVmYXVs
dCBpcy48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PldoaWxlIEkgYW0gc3VyZSBtYW55
IGN1c3RvbWVycyBhc2sgc2V2ZXJhbCB2ZW5kb3JzIGZvciB0aGlzLCBpdCBoYXMgbm90IGdlbmVy
YWxseSBoYXBwZW5lZC48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PihGZWVsIGZyZWUg
dG8gY29udmV5IHRoaXMgYmFjayB0byB5b3VyIG1hbmFnZW1lbnQsIEJUVy4pPC9kaXY+DQo8ZGl2
Pjxicj4NCjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFp
bF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNv
bGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2IGNsYXNzPSJnbWFp
bF9leHRyYSI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i
Zm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj48
c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxi
cj4NCjwvZGl2Pg0KPC9kaXY+DQo8c3Bhbj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90
ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3Bh
ZGRpbmctbGVmdDoxZXgiPg0KSXMgY2hhbmdpbmcgdGhlIGxhbmd1YWdlDQo8ZGl2IHN0eWxlPSJm
b250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGw7ZGlz
cGxheTppbmxpbmUiPg0K4oCLJm5ic3A7PC9kaXY+DQphYm91dCBwcm9wYWdhdGluZyByZWNvZ25p
emVkIHRyYW5zaXRpdmUgYXR0cmlidXRlcyBnb2luZyB0byBjaGFuZ2UgdGhlc2U8YnI+DQp2ZW5k
b3IncyBkZWZhdWx0cz88YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+PC9kaXY+DQo8YnI+DQo8
L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5
OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+4oCLV2VsbCBJIGJl
bGlldmUgc28uIE5vdGljZSB0aGF0IGFzIG11Y2ggYXMgZm9sa3MgbGlrZXMgbGFyZ2UgdG8gYmUg
JnF1b3Q7bGlrZSZxdW90OyAxOTk3IGl0IGlzIG5vdCAxMDAlLiBFdmVuIGJ5IHlvdXIgY2lzY28g
ZXhhbXBsZSAuLiB0aGVyZSBpcyBhbHJlYWR5IHNlbmQtY29tbXVuaXR5IHN0YW5kYXJkIHZzIGV4
dGVuZGVkIGtub2IuIExhcmdlDQog4oCLd2lsbCBiZSBuZXcgYWRkaXRpb24gYW5kIGluIGFkZGl0
aW9uIHRvICZxdW90O2JvdGgmcXVvdDsgdGhleSB3aWxsIGxpa2VseSBhZGQgYWxzbyAmcXVvdDth
bGwmcXVvdDsga2V5d29yZC4mbmJzcDs8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv
dGU+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGF0IGlzIGEgdmVuZG9yIGRlc2lnbiBkZWNp
c2lvbiBpc3N1ZS48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoZXJlIGlzIG5vdGhp
bmcgdG8gcHJldmVudCBhIHZlbmRvciBmcm9tIGltcGxlbWVudGluZyBsYXJnZSwgYnkgbWFraW5n
IGxhcmdlIGxvY2stc3RlcCB3aXRoIDE5OTcuIEZvciBleGFtcGxlLCB0aGUgaW1wbGVtZW50YXRp
b24gd2hpY2ggc3VwcG9ydHMgbGFyZ2UsIGNvdWxkIGFwcGx5IGRpZmZlcmVudCBzZW1hbnRpY3Mg
dG8gJnF1b3Q7c2VuZCBjb21tdW5pdHkmcXVvdDsgdG8gc2VuZCBCT1RIIDE5OTcgQU5EIGxhcmdl
IGNvbW11bml0aWVzLCB3aXRob3V0DQogY2hhbmdpbmcgdGhlIHN5bnRheC48L2Rpdj4NCjxkaXY+
KFN1Y2ggYSBjaGFuZ2UgaW4gc2VtYW50aWNzIHdvdWxkIHByb2JhYmx5IGJlIHdlbGwgYWR2aXNl
ZCB0byBhbGxvdyBvcHRpb25hbCBwYXJhbWV0ZXJzIHRvIHByb3ZpZGUga25vYnMgZm9yICZxdW90
OzE5OTctb25seSZxdW90OywgJnF1b3Q7bGFyZ2Utb25seSZxdW90OywgJnF1b3Q7d2lkZS1vbmx5
JnF1b3Q7LCAmcXVvdDtleHRlbmRlZC1vbmx5JnF1b3Q7LCBvciBhbnkgY29tYmluYXRpb24gb2Yg
MTk5NywgbGFyZ2UsIHdpZGUsIGFuZCBleHRlbmRlZCkuPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2
Pg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44
ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2IGRp
cj0ibHRyIj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFt
aWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+PC9kaXY+DQo8
ZGl2IHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNp
emU6c21hbGwiPkFzIHRvIHdoeSB3ZSBoYXZlIHRoaXMga25vYiBpbiB0aGUgZmlyc3QgcGxhY2Ug
ZnJvbSB0aGUgZWFybHkgZGF5cyBJIHJlY2FsbCBpdCB3YXMgYmFzZWQgb24gSVNQcyB3aG8gd2Fu
dGVkIHRvIGhhdmUgUkZDMTk5NyBsb2NhbCB3aXRoaW4gdGhlaXIgQVMgb25seSBieSBkZWZhdWx0
IC0gc3VjaCB0aGF0IHRoZXkgZG8gbm90IG5lZWQNCiBhbnkgZXh0cmEgcG9saWN5IGluIG9yZGVy
IG5vdCB0byBwcm9wYWdhdGUgaXQgb3ZlciBlQkdQLiBEb2VzIHRoZSBzYW1lIGRlc2lnbiBhcHBs
aWVzIHRvIExhcmdlID88L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2
Pjxicj4NCjwvZGl2Pg0KPGRpdj5JIGRvbid0IHJlY2FsbCBhbnkgZXhwbGFuYXRpb24gZm9yIHRo
ZSBkZWZhdWx0IGJlaW5nIHRoZSB3YXkgaXQgd2FzLiBJTUhPLCB2ZW5kb3JzIGFyZSBmcmVlIHRv
IGNoYW5nZSBUSEVJUiBkZWZhdWx0LCBidXQgU0hPVUxEIGFwcGx5IHRoZSBzYW1lIGRlZmF1bHQg
dG8gYm90aCAxOTk3IGFuZCBsYXJnZS48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkFs
c28gSU1ITywgdGhlICZxdW90O3ByaW5jaXBhbCBvZiBsZWFzdCBzdXJwcmlzZSZxdW90OyBpcyBz
b21ldGhpbmcgdGhhdCB2ZW5kb3JzIHNob3VsZCBhZGhlcmUgdG8uPC9kaXY+DQo8ZGl2PkkgY2Fu
bm90IHRlbGwgeW91IGhvdyBzZXZlcmVseSB1bmRpc2Nsb3NlZCBhbmQgdW5jb250cm9sbGVkIGNo
YW5nZXMgdG8gZGVmYXVsdHMgYWNyb3NzIHVwZ3JhZGVzIGhhdmUgYWR2ZXJzZWx5IGFmZmVjdGVk
IG5ldHdvcmtzIEkgYnVpbHQgYW5kIHJhbiwgYW5kIHRob3NlIG9mIG15IGNvbXBhdHJpb3RzLjwv
ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+UGxlYXNlLCBzdG9wIHRyeWluZyB0byBtYWtl
ICZxdW90O2JldHRlciZxdW90OyBkZWZhdWx0cy4gSnVzdCBnaXZlIHVzIHRoZSBrbm9icy48L2Rp
dj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0
eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5n
LWxlZnQ6MWV4Ij4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPg0K
PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1z
aXplOnNtYWxsIj5Ob3RlIHRoYXQgSSBhbSBub3Qgc3VnZ2VzdGluZyBsYXJnZSBtdXN0IGJlIHBy
b3BhZ2F0ZSBieSBkZWZhdWx0LiBCdXQgSSB0aGluayBpdCB3b3VsZCBiZSBnb29kIHRvIGhhdmUg
bWFuZGF0ZWQgYnkgdGhlIHNwZWMgY29uc2lzdGVuY3kgYWNyb3NzIEJHUCBpbXBsZW1lbnRhdGlv
bnMgLSBwcm9wYWdhdGUgb3IgZG8gbm90IHByb3BhZ2F0ZS4mbmJzcDs8L2Rpdj4NCjxkaXYgc3R5
bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFs
bCI+PGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnI+
DQo8L2Rpdj4NCjxkaXY+VW50aWwgdGhlIGtub2JzIGFyZSB1bml2ZXJzYWxseSBpbiBwbGFjZSBh
Y3Jvc3MgdmVuZG9yczogTm8sIGFuZCBwbGVhc2Ugc3RvcCB0cnlpbmcgdG8gYWR2b2NhdGUgZm9y
IHRoaXMgc29ydCBvZiB0aGluZy48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkJyaWFu
Jm5ic3A7PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90
ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXY+PHNwYW4+
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPHdicj5fX19fX19fX19fX19fX19fXzwvc3Bh
bj48YnI+DQo8c3Bhbj5JZHIgbWFpbGluZyBsaXN0PC9zcGFuPjxicj4NCjxzcGFuPjxhIGhyZWY9
Im1haWx0bzpJZHJAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5JZHJAaWV0Zi5vcmc8L2E+PC9z
cGFuPjxicj4NCjxzcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vaWRyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi88
d2JyPmxpc3RpbmZvL2lkcjwvYT48L3NwYW4+PGJyPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8
L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv
Y2txdW90ZT4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_225A5668BE114575A81F115D9A03A96Cciscocom_--


From nobody Sat Nov  5 23:26:57 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A99C129608 for ; Sat,  5 Nov 2016 23:26:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.017
X-Spam-Level: 
X-Spam-Status: No, score=-16.017 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=-1.497, 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 pJqR3Y20bhhj for ; Sat,  5 Nov 2016 23:26:53 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9812012960A for ; Sat,  5 Nov 2016 23:26:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4604; q=dns/txt; s=iport; t=1478413613; x=1479623213; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=A0UajCog+s0awWVWmBuateyNnQElGMbofTiHyfcyyYQ=; b=JSFDgDlL64ld1DBGRuFP0tUHw0oYNkwpUN8yoJzNLFo6/tjUW0IY1QcH qKLQyPmW4dZ0xIm+KN1DWcFpgxiEC/mWetFleB9Pk0C42pL9bZIA3uY/t RONnBeJqNSGgOH75tESFLLr8xH2hQvyPks+cXMMXYBbT9biO72VTQvIWo 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CNAQAbzB5Y/5RdJa1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgy4BAQEBAR9YfI04ln6POIUaggglhX8CGoFvPxQBAgEBAQEBAQFiKIR?= =?us-ascii?q?iAQEEI1YQAgEGAgQ7AwICAjAUEQIEDgUUiESSSp0/gkCLMwEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBARcFhj6BfYJYh0stgi8FjlSFc4VgAYY0ig+BboRwiTKNKoQFAR4?= =?us-ascii?q?3eoUqcodMAQEB?=
X-IronPort-AV: E=Sophos;i="5.31,600,1473120000";  d="scan'208,217";a="342888567"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Nov 2016 06:26:52 +0000
Received: from XCH-RCD-015.cisco.com (xch-rcd-015.cisco.com [173.37.102.25]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id uA66QqX2032305 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 6 Nov 2016 06:26:52 GMT
Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-015.cisco.com (173.37.102.25) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 6 Nov 2016 01:26:53 -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; Sun, 6 Nov 2016 01:26:53 -0500
From: "Jakob Heitz (jheitz)" 
To: Zhuangshunwan 
Thread-Topic: [Idr] Review of draft-ietf-large-community-06.txt
Thread-Index: AQHSNjBz6sRcMeSZxEiIR579im5tsaDIY72wgAB9DlKAAK2JAIAAA2sAgAAGW4D//8SNUIAAW0wA//+1BgCAAFpfAIAAvu4AgAABzgCAAV2lgA==
Date: Sun, 6 Nov 2016 06:26:53 +0000
Message-ID: <804168D3-12A6-478A-A390-19A02791A0D0@cisco.com>
References: <6c5d83aa1d6a4a04b651b8f14f4b445b@XCH-ALN-014.cisco.com> <40D942F5-0710-46D1-BF09-76C827377479@cisco.com> <95F42982-7DCF-46A9-A26C-71EF70DB3C59@apnic.net> <20161104195346.GK961@Vurt.local> <20161104201631.GA35942@Vurt.lan> <8a293ce4fc134657aa98134b5017d92e@XCH-ALN-014.cisco.com> <20161104221030.GD37681@Vurt.lan> <0919e676e12d49d1a2ba30f4acc3b273@XCH-ALN-014.cisco.com> <20161104230536.GJ37681@Vurt.lan> <19AB2A007F56DB4E8257F949A2FB9858C87AFC6E@NKGEML515-MBX.china.huawei.com> <20161105103526.GM952@Vurt.local>
In-Reply-To: <20161105103526.GM952@Vurt.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: multipart/alternative; boundary="_000_804168D312A6478AA39019A02791A0D0ciscocom_"
MIME-Version: 1.0
Archived-At: 
Cc: "idr@ietf.org" 
Subject: Re: [Idr] Review of draft-ietf-large-community-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: Sun, 06 Nov 2016 06:26:55 -0000

--_000_804168D312A6478AA39019A02791A0D0ciscocom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

U2h1bndhbiwNCg0KT24gTm92IDUsIDIwMTYsIGF0IDM6MzUgQU0sIEpvYiBTbmlqZGVycyA8am9i
QGluc3RpdHV1dC5uZXQ8bWFpbHRvOmpvYkBpbnN0aXR1dXQubmV0Pj4gd3JvdGU6DQoNCk9uIFNh
dCwgTm92IDA1LCAyMDE2IGF0IDEwOjI4OjU4QU0gKzAwMDAsIFpodWFuZ3NodW53YW4gd3JvdGU6
DQoNClNvbWUgY3VzdG9tZXJzIGZyb20gSURDL09UVCBjb21wbGFpbiB0aGF0IElTUHMgY2FuIG5v
dCB0cmFuc21pdCB0aGVpcg0KY29tbXVuaXR5IGF0dHJpYnV0ZXMsIGJlY2F1c2UgSVNQcyBkbyBu
b3QgdHJhbnNtaXQgY29tbXVuaXR5DQphdHRyaWJ1dGVzIGluIG1vc3QgY2FzZXMuDQoNCkkgZmlu
ZCBpdCBoYXJkIHRvIG1ha2Ugb3IgYWNjZXB0IHF1YW50YXRpdmUgc3RhdGVtZW50cyBpbiB0aGlz
IGNvbnRleHQsDQpJIGtub3cgc29tZSBJU1AgdGhhdCBzY3J1YiBhbGwgY29tbXVuaXRpZXMsIGFu
ZCBJIGtub3cgc29tZSBJU1BzIHRoYXQNCnBhc3Mgb24gYXMgbXVjaCBjb21tdW5pdGllcyBhcyBw
b3NzaWJsZS4gVGhlIG1hcmtldCB3aWxsIGRlY2lkZS4NCg0KQW5vdGhlciByZWFzb24gaXMgdGhh
dCBzb21lIElTUHMgdXNlIHByaXZhdGUgQVNOcyByYXRoZXIgdGhhbiB0aGVpciBvd24gQVNOIGlu
IHRoZSBmaXJzdCAxNiBiaXRzIG9mIHRoZSBjb21tdW5pdHksIGJlY2F1c2UgdGhlcmUgaXMgbm90
IGVub3VnaCBsZWZ0b3ZlciBiaXRzIHRvIGV4cHJlc3MgdGhlIGFjdGlvbi4gVGhhdCBtYWtlcyBp
dCBpbXBvc3NpYmxlIGZvciBhbiBJU1AgdG8gdHJhbnNtaXQgdGhlbSB0byBhbm90aGVyIElTUCwg
YmVjYXVzZSBvZiBuYW1lIHNwYWNlIGNsYXNoZXMuIFRoYXQgc2hvdWxkIG5vIGxvbmdlciBiZSBh
IHByb2JsZW0gd2l0aCBsYXJnZSBjb21tdW5pdGllcy4NClNlZSBodHRwczovL29uZXN0ZXAubmV0
L2NvbW11bml0aWVzPGh0dHBzOi8vb25lc3RlcC5uZXQvY29tbXVuaXRpZXMvPi8gZm9yIGV4YW1w
bGVzIG9mIGNvbW11bml0aWVzLiBCVFcsIEkgZG9uJ3QgcmVjb2duaXplIGFueSBDaGluZXNlIElT
UHMgb24gdGhhdCBzaXRlLiBDYW4geW91IHNoYXJlIHNvbWUgY29tbXVuaXR5IHNwZWNpZmljYXRp
b25zIGZvciBhbnkgQ2hpbmVzZSBJU1BzLCBwbGVhc2U/DQoNCuiwouiwoiwNCkpha29iLg0KDQo=

--_000_804168D312A6478AA39019A02791A0D0ciscocom_
Content-Type: text/html; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8
ZGl2PlNodW53YW4sPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5PbiBOb3YgNSwgMjAx
NiwgYXQgMzozNSBBTSwgSm9iIFNuaWpkZXJzICZsdDs8YSBocmVmPSJtYWlsdG86am9iQGluc3Rp
dHV1dC5uZXQiPmpvYkBpbnN0aXR1dXQubmV0PC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8ZGl2Pjxi
cj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2PjxzcGFuPk9uIFNhdCwg
Tm92IDA1LCAyMDE2IGF0IDEwOjI4OjU4QU0gJiM0MzswMDAwLCBaaHVhbmdzaHVud2FuIHdyb3Rl
Ojwvc3Bhbj48YnI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YnI+DQo8L2Jsb2NrcXVvdGU+
DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj5Tb21lIGN1c3RvbWVycyBmcm9tIElEQy9P
VFQgY29tcGxhaW4gdGhhdCBJU1BzIGNhbiBub3QgdHJhbnNtaXQgdGhlaXI8L3NwYW4+PGJyPg0K
PC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+Y29tbXVuaXR5IGF0
dHJpYnV0ZXMsIGJlY2F1c2UgSVNQcyBkbyBub3QgdHJhbnNtaXQgY29tbXVuaXR5PC9zcGFuPjxi
cj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPmF0dHJpYnV0
ZXMgaW4gbW9zdCBjYXNlcy48L3NwYW4+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPHNwYW4+PC9zcGFu
Pjxicj4NCjxzcGFuPkkgZmluZCBpdCBoYXJkIHRvIG1ha2Ugb3IgYWNjZXB0IHF1YW50YXRpdmUg
c3RhdGVtZW50cyBpbiB0aGlzIGNvbnRleHQsPC9zcGFuPjxicj4NCjxzcGFuPkkga25vdyBzb21l
IElTUCB0aGF0IHNjcnViIGFsbCBjb21tdW5pdGllcywgYW5kIEkga25vdyBzb21lIElTUHMgdGhh
dDwvc3Bhbj48YnI+DQo8c3Bhbj5wYXNzIG9uIGFzIG11Y2ggY29tbXVuaXRpZXMgYXMgcG9zc2li
bGUuIFRoZSBtYXJrZXQgd2lsbCBkZWNpZGUuPC9zcGFuPjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K
PGRpdj48YnI+DQo8L2Rpdj4NCkFub3RoZXIgcmVhc29uIGlzIHRoYXQgc29tZSBJU1BzIHVzZSBw
cml2YXRlIEFTTnMgcmF0aGVyIHRoYW4gdGhlaXIgb3duIEFTTiBpbiB0aGUgZmlyc3QgMTYgYml0
cyBvZiB0aGUgY29tbXVuaXR5LCBiZWNhdXNlIHRoZXJlIGlzIG5vdCBlbm91Z2ggbGVmdG92ZXIg
Yml0cyB0byBleHByZXNzIHRoZSBhY3Rpb24uIFRoYXQgbWFrZXMgaXQgaW1wb3NzaWJsZSBmb3Ig
YW4gSVNQIHRvIHRyYW5zbWl0IHRoZW0gdG8gYW5vdGhlciBJU1AsIGJlY2F1c2UNCiBvZiBuYW1l
IHNwYWNlIGNsYXNoZXMuIFRoYXQgc2hvdWxkIG5vIGxvbmdlciBiZSBhIHByb2JsZW0gd2l0aCBs
YXJnZSBjb21tdW5pdGllcy4NCjxkaXY+U2VlJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9vbmVzdGVw
Lm5ldC9jb21tdW5pdGllcy8iPmh0dHBzOi8vb25lc3RlcC5uZXQvY29tbXVuaXRpZXM8L2E+LyBm
b3IgZXhhbXBsZXMgb2YgY29tbXVuaXRpZXMuIEJUVywgSSBkb24ndCByZWNvZ25pemUgYW55IENo
aW5lc2UgSVNQcyBvbiB0aGF0IHNpdGUuIENhbiB5b3Ugc2hhcmUgc29tZSBjb21tdW5pdHkgc3Bl
Y2lmaWNhdGlvbnMgZm9yIGFueSBDaGluZXNlIElTUHMsIHBsZWFzZT88L2Rpdj4NCjxkaXY+DQo8
ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogcmdi
YSgyNTUsIDI1NSwgMjU1LCAwKTsiPuiwouiwoiw8YnI+DQo8L3NwYW4+DQo8ZGl2PjxzcGFuIHN0
eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiByZ2JhKDI1NSwgMjU1LCAyNTUsIDApOyI+SmFrb2IuPC9z
cGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8
L2h0bWw+DQo=

--_000_804168D312A6478AA39019A02791A0D0ciscocom_--


From nobody Sun Nov  6 11:23:43 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81937129565 for ; Sun,  6 Nov 2016 11:23:41 -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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lamehost-it.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 9vBU9AYP1DMP for ; Sun,  6 Nov 2016 11:23:39 -0800 (PST)
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 50114129542 for ; Sun,  6 Nov 2016 11:23:38 -0800 (PST)
Received: by mail-wm0-x232.google.com with SMTP id a197so144662575wmd.0 for ; Sun, 06 Nov 2016 11:23:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lamehost-it.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pF7D91WM19n80n4NXhA0rm0mk0qIIQmNsvAQjuttYds=; b=VRAjUQGz4XfMFbURAuz1Sm6Nj/fVnKudqIq3e8JkWHyClDebHHZqkEwJ4ZtZ1Kc8vP vaAsk+bfbGc5RscQCpURGJqL/ugoXfvOGEyr0GZAtl3ktGDqScqqENx1SKg6JmxMNvri VG2KWb0sDooGpxVQtKGXHe553tl7g1qQ9eWbhFoPpzdUrtFnmjhi/TiTvIEG4pyo8xOg 9/VAg4GYHQCl8RLh+wSecWp1XX+SMvoqe827N28jquQUr6RVuQiMhCAwpV76hi9s+snV 4je+97i3Ih2NxR8yPeLfGWFATtavwh3IyKSWFghbvUXMOoeshurCG9dEy1rAAkzHsHNP DpzA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pF7D91WM19n80n4NXhA0rm0mk0qIIQmNsvAQjuttYds=; b=IlUAv67UOQ+HtJdMXhSq2+mS2PKNiMK0JDNWbsgmsXzJG+mXDHkyHu5KZRDDRIvolA /alKeeEPGW7BYGvUOZ6nEjeG09nBZxbmDvsXIjuOP9AXLUolaqM9pPh76wxi6zUf7lXi n08subSkBchf/6ENpCkSS4P5BO07xp4+a5DlHL1hXhIAtykNbqTqQSYoM3Lj86j9uX7/ 0CqBg4c7w1SXj7ljjC0aWrEwZzBFBc/3cgKtrF3tTddFOQ1x3dMS1IdCqAAZIl7PJLsX iaEkHKESQmEu7ulAErJ/KoPZKykeKgBQI8q4dK+xiB8yUf5O3nJUO4LNRAfDMN96fN1d 7FWQ==
X-Gm-Message-State: ABUngvdEoylTlAmOocy1lb+hCpAFT0FhizMlawP1Vqnr0G2qwoIQdIMNCiR9XcczQqOUP+tDtrR73aMIc8a8rw==
X-Received: by 10.28.69.91 with SMTP id s88mr6251445wma.18.1478460217510; Sun, 06 Nov 2016 11:23:37 -0800 (PST)
MIME-Version: 1.0
Received: by 10.28.47.132 with HTTP; Sun, 6 Nov 2016 11:23:36 -0800 (PST)
X-Originating-IP: [79.24.77.5]
In-Reply-To: <20161101185759.GA23458@pfrc.org>
References: <20161031205515.GA25507@pfrc.org> <5818E126.2090202@foobar.org> <20161101185759.GA23458@pfrc.org>
From: Marco Marzetti 
Date: Sun, 6 Nov 2016 20:23:36 +0100
Message-ID: 
To: Jeffrey Haas 
Content-Type: multipart/alternative; boundary=94eb2c0723a614652a0540a6d890
Archived-At: 
Cc: idr@ietf.org
Subject: Re: [Idr] [internet-drafts@ietf.org: I-D Action: draft-haas-idr-extended-experimental-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: Sun, 06 Nov 2016 19:23:41 -0000

--94eb2c0723a614652a0540a6d890
Content-Type: text/plain; charset=UTF-8

On Tue, Nov 1, 2016 at 7:58 PM, Jeffrey Haas  wrote:

>
> A feature such as this one, perhaps extended with a per-attribute form of
> draft-ietf-idr-bgp-attribute-announcement along with enough information to
> figure out when filtering wasn't done could provide some safety.
>
> The related changes to this proposal would be to simply add the 4-octets of
> the attribute announcement scoping and potentially the attaching AS.
> However, given even such vendor features are likely to need to work in an
> inter-as fashion, generating scopes of containment become tricky.
>
>
I have always wondered if we should add and N bit to
draft-ietf-idr-bgp-attribute-announcement to limit the advertisements to
neighbor ASes only.

--94eb2c0723a614652a0540a6d890
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



=
On Tue, Nov 1, 2016 at 7:58 PM, Jeffrey Haas <jhaas@pfrc.org> =
wrote:


A feature such as this one, perhaps extended with a per-attribute form of
draft-ietf-idr-bgp-attribute-announcement along with enough informatio=
n to

figure out when filtering wasn't done could provide some safety.



The related changes to this proposal would be to simply add the 4-octets of=


the attribute announcement scoping and potentially the attaching AS.

However, given even such vendor features are likely to need to work in an
inter-as fashion, generating scopes of containment become tricky.




I have always wondered if we should add and N bit=
 to draft-ietf-idr-bgp-attribute-announcement to limit the advertiseme=
nts to neighbor ASes only.=C2=A0


--94eb2c0723a614652a0540a6d890--


From nobody Sun Nov  6 11:40:22 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2054D1294AB for ; Sun,  6 Nov 2016 11:40:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.399
X-Spam-Level: 
X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, 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 xnfEF9wbnpk0 for ; Sun,  6 Nov 2016 11:40:19 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 3C3F41294BB for ; Sun,  6 Nov 2016 11:40:19 -0800 (PST)
Received: by slice.pfrc.org (Postfix, from userid 1001) id AF9AF1E337; Sun,  6 Nov 2016 14:42:58 -0500 (EST)
Date: Sun, 6 Nov 2016 14:42:58 -0500
From: Jeffrey Haas 
To: "Jakob Heitz (jheitz)" 
Message-ID: <20161106194258.GB5113@pfrc.org>
References:  <86860386-9C2B-4BD5-B457-2A6DA5446CF3@cisco.com> <20161106040849.GB18931@shrubbery.net> <5BD3C90E-CC0E-42D2-9ACD-5787FC75BF0A@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5BD3C90E-CC0E-42D2-9ACD-5787FC75BF0A@cisco.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: 
Cc: heasley , "idr@ietf.org" , Robert Raszuk 
Subject: Re: [Idr] Vendor Defaults (was Re: Review of draft-ietf-large-community-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: Sun, 06 Nov 2016 19:40:20 -0000

On Sun, Nov 06, 2016 at 05:43:42AM +0000, Jakob Heitz (jheitz) wrote:
> Unfortunately, it was too late to change the default in IOS. If IOS
> changes that default, it would break many existing deployments.

This is a point I'm also strongly sympathetic to.  Changing the core
defaults is simply Not Done.  

Supporting such default changes will likely have to be done via a new knob
that imposes a new set of defaults.  Admittedly, not fully "default" since
you have to configure something, but at least something that changes
expectations.

-- Jeff


From nobody Sun Nov  6 13:50:31 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE744129578 for ; Sun,  6 Nov 2016 13:50:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level: 
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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 K713e-nbxTUp for ; Sun,  6 Nov 2016 13:50:28 -0800 (PST)
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 C4A31129575 for ; Sun,  6 Nov 2016 13:50:27 -0800 (PST)
Received: by mail-wm0-x230.google.com with SMTP id a197so148695432wmd.0 for ; Sun, 06 Nov 2016 13:50:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=CW1TF9Srbj5hGK+5E6x2ecT03Tn2JISXJkMJWxDTek8=; b=R0bWdzQ08px7nXOZ0Vrbm3TOoTxOqOzxOkF/UDKOQiQ8q15o1KsuupSBcfqEplG7ky 0sy1mLZe/aqFjOrGVDCCU3FT/k/embs7GOb8C243D4dz46XSwOuYU7MCiulV5bn+0Oem hSaYIU0TA3XbStkaocknp2xuhWgFj68JiTKlHViZWxAma7jHg3p/EYMmJpKPSZTzprgo xYKtUiH+N0x3e+nc7aGCKEfXvkK0At89jBJo+Ecpqugz7OBPlbMXkPGxmEiQG4j51DBa Pn6PN8aZ/Z5k/sIXNhX55NHuyQKANlCtrPmhwWO96880wJAeg2QmxNXZRk9x9kJ68unx aK6g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=CW1TF9Srbj5hGK+5E6x2ecT03Tn2JISXJkMJWxDTek8=; b=GOwtaQLwTK82s1yZrO/K1YCLKrIS4sI6ZCi3zp+EagJELgb5sWHjxLvipHNNvK7B7Q dwalK2HoV7aIFzzKCmdeWzWq3DlWq+BYOSxDeiuiN8nsw7dzpTqF2Ml37FDRZJeX5NjP a31JBtlBA9scNt46cNTG15AQPEQ2/5sf8kBL3z9WdUSLSfsxRWGbaDlo0+e1njw1CX+o k6rsvWI2CXmg0+u0gZPjoPWXEiu3zlc9r+w0qi2fG6xOJDTos9Fd5Wb0lLk2d44nR9zq TyYPIQAihABqUi4gNDc+qoE9dh/kFxo5lEbvtzBk7ySTtq/aoFUmxsVaM1IrL335BLRa cpaQ==
X-Gm-Message-State: ABUngvc4OVTq6rO7sRyQvM/bEyAad9PW47kx8+MpvtMbU9JDshz7GmWSdFixZLYjfrbdUSKpb5p0S8ltORgsDg==
X-Received: by 10.28.46.15 with SMTP id u15mr6509881wmu.61.1478469026143; Sun, 06 Nov 2016 13:50:26 -0800 (PST)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.80.137.69 with HTTP; Sun, 6 Nov 2016 13:50:24 -0800 (PST)
In-Reply-To: <20161106194258.GB5113@pfrc.org>
References:  <86860386-9C2B-4BD5-B457-2A6DA5446CF3@cisco.com> <20161106040849.GB18931@shrubbery.net> <5BD3C90E-CC0E-42D2-9ACD-5787FC75BF0A@cisco.com> <20161106194258.GB5113@pfrc.org>
From: Robert Raszuk 
Date: Sun, 6 Nov 2016 22:50:24 +0100
X-Google-Sender-Auth: MyHlSP0Bow-DkEb3TbfhhWEcBSc
Message-ID: 
To: Jeffrey Haas 
Content-Type: multipart/alternative; boundary=001a1142532c1d64840540a8e5d6
Archived-At: 
Cc: heasley , "idr@ietf.org" 
Subject: Re: [Idr] Vendor Defaults (was Re: Review of draft-ietf-large-community-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: Sun, 06 Nov 2016 21:50:30 -0000

--001a1142532c1d64840540a8e5d6
Content-Type: text/plain; charset=UTF-8

Hi Jeff,

Just to clarify my intention here ...

I really wanted to make sure that large is deployed with defaults which
make most sense and such defaults are identical between implementations.
And we can do it now or never as when the code is shipped out in first
production release the gave is over.

When I mentioned RFC1997 it was only due to heavy influence by some for the
enforcement of functional symmetry between standard and large communities.
As far as propagation defaults IMO they do not need to be identical.

Bottom line I am not advocating to change RFC1997 propagation rules. Only
to define one way or another what should be such rules regarding large
communities if implementation recognizes the new attribute and no policy is
in place to overwrite the default behavior.

Thank you,
Robert.


On Sun, Nov 6, 2016 at 8:42 PM, Jeffrey Haas  wrote:

> On Sun, Nov 06, 2016 at 05:43:42AM +0000, Jakob Heitz (jheitz) wrote:
> > Unfortunately, it was too late to change the default in IOS. If IOS
> > changes that default, it would break many existing deployments.
>
> This is a point I'm also strongly sympathetic to.  Changing the core
> defaults is simply Not Done.
>
> Supporting such default changes will likely have to be done via a new knob
> that imposes a new set of defaults.  Admittedly, not fully "default" since
> you have to configure something, but at least something that changes
> expectations.
>
> -- Jeff
>

--001a1142532c1d64840540a8e5d6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Jeff,

Jus=
t to clarify my intention here ...=C2=A0
=

I really wanted to make sure that la=
rge is deployed with defaults which make most sense and such defaults are i=
dentical between implementations. And we can do it now or never as when the=
 code is shipped out in first production release the gave is over.

When I men=
tioned RFC1997 it was only due to heavy influence by some for the enforceme=
nt of functional symmetry between standard and large communities. As far as=
 propagation defaults IMO they do not need to be identical.=C2=A0

Bottom line=
 I am not advocating to change RFC1997 propagation rules. Only to define on=
e way or another what should be such rules regarding large communities if i=
mplementation recognizes the new attribute and no policy is in place to ove=
rwrite the default behavior.=C2=A0

Thank you,
Robert.
=C2=A0

On Sun, Nov 6, 2016 at 8:42 PM, J=
effrey Haas <jhaas@pfrc.org> wrote:
On Sun, Nov 06, 2016 at 05:43:42AM +0000, Jakob He=
itz (jheitz) wrote:

> Unfortunately, it was too late to change the default in IOS. If IOS
> changes that default, it would break many existing deployments.



This is a point I'm also strongly sympathetic to.=C2=A0 Changing=
 the core

defaults is simply Not Done.



Supporting such default changes will likely have to be done via a new knob<=
br>
that imposes a new set of defaults.=C2=A0 Admittedly, not fully "defau=
lt" since

you have to configure something, but at least something that changes

expectations.



-- Jeff





--001a1142532c1d64840540a8e5d6--


From nobody Sun Nov  6 14:56:30 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D6EB129702 for ; Sun,  6 Nov 2016 14:56:29 -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, 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 8sBa3wLgHmb4 for ; Sun,  6 Nov 2016 14:56:27 -0800 (PST)
Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A37521296F8 for ; Sun,  6 Nov 2016 14:56:27 -0800 (PST)
Received: by mail-pf0-x22a.google.com with SMTP id d2so80982572pfd.0 for ; Sun, 06 Nov 2016 14:56:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vzItWCt2gKNj+4u44s+uw2uVd7WMcIEbEfQC8NHXxgs=; b=JVwjpfxrbr/da2/7HjlPNh6xdfaNjiYpx2/r5yuXQK7dlhQ2xE4zyAmGfDHSBFwU2b wH0OxL3A7kZqup1swp27dJZcs97T7uUaRVsvmeKSqWkBaL3nSp4XNSW38kJoq+Fq6+jS OFLA5MtZF11Vbh7UGkxMDegTTLNkdiWP88LzAe4iVhIhy/mWU2PRqYhL2f+UNi45SVA6 qXLqxfby01Pn+rZm9CRNna/8w50R0QGdSNN2i3x9UN/32ZMngOwPbkcP/WqaUiT/MkPX sdQupDgeLF41Izp2gXUjUeKCCtFDwcjQ9mYIeUgkHeOmnOFH75sIHAgB+wCOy+yGGXjr YYFg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vzItWCt2gKNj+4u44s+uw2uVd7WMcIEbEfQC8NHXxgs=; b=Fe6mnDF1ooubqEJpQqO/jp3+X98tRFhGvcITUexZ9Vy6DHPhT+u5FZTLCnrN8BV/E5 2esOHartr+6lIiEj0QtczegGw7qVcDE46GCmZtKlGLQu2JUIvO6I3vgfFp/6DiRRdrxN QYtl09bCrkFGKHHAK2bI0RHATB3t1gOxFLBZcWSBD9i4eY3mV7VEOEDBuqaCsKflt3D0 +8G+ku7hL2O+MWcu69xXWivFAZQJ/w+zw8N9FRcI44E2QnU0tBsyu0LJyzoDTVLeKPUY eTKxOrmmZPUXqYvMKYpbTUj3jH/FxIQ7Z+Y5Gak7tOkYCUeKCb1uYAfZys+Hxk4s5wbZ gjCA==
X-Gm-Message-State: ABUngvfpX3VxZc1wX/0311ceq+TaHbQo0cOpDQO5HI9jOG96X+9FB4PZudVVMGXSpde2Ng==
X-Received: by 10.99.115.65 with SMTP id d1mr6221088pgn.56.1478472987216; Sun, 06 Nov 2016 14:56:27 -0800 (PST)
Received: from [192.168.5.105] (c-73-92-109-167.hsd1.ca.comcast.net. [73.92.109.167]) by smtp.gmail.com with ESMTPSA id c5sm35008624pfj.71.2016.11.06.14.56.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 06 Nov 2016 14:56:25 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Brian Dickson 
X-Mailer: iPhone Mail (14B100)
In-Reply-To: <86860386-9C2B-4BD5-B457-2A6DA5446CF3@cisco.com>
Date: Sun, 6 Nov 2016 14:56:24 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <17E646EF-4633-423B-9AC4-B53D49C90632@gmail.com>
References:  <86860386-9C2B-4BD5-B457-2A6DA5446CF3@cisco.com>
To: "Jakob Heitz (jheitz)" 
Archived-At: 
Cc: heasley , "idr@ietf.org" , Robert Raszuk 
Subject: Re: [Idr] Vendor Defaults (was Re: Review of draft-ietf-large-community-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: Sun, 06 Nov 2016 22:56:29 -0000

Sent from my iPhone

> On Nov 5, 2016, at 4:13 PM, Jakob Heitz (jheitz)  wrote:=

> In my large-community code, I have lumped them under send-community-ebgp. A=
t this point, I am very open to suggestions for configuration. Once the code=
 is released, it gets much harder to change configs.

The following is my opinion, but I am confident that most operators concur w=
ith it:

Large is not a "new" attribute per se.
Large is providing parity for RFC1997, for use with 32-bit ASNs.

For that reason alone, the only sane implementation approach is "off by defa=
ult", so as to be consistent with the default for 1997.

If someone does not use 1997 today, either choice would be okay.

However, for those using 1997, all of their BGP peering configs are well-bak=
ed, and whatever they use for managing them has 1997 built into it.

Those ASNs will be the early adopters and heaviest receive-side users (defin=
ing their name spaces in particular). When they ask for feature parity, that=
 includes consistency with how they deploy and manage all types of communiti=
es.

Changing the default behavior between 1997 and large would likely cause chao=
s, anger, and frustration.

If anyone advocates for this change, it is clear they are not listening to o=
perators, or do not understand what they want and why they want it. Operator=
s who have 16-bit ASNs and use 1997, want to offer identical features as rel=
ates to 32-bit target ASNs. Operators with 32-bit ASN need this to do any 19=
97-type things, as clients (setting large communities) or as servers (receiv=
e-side handling). It augments 1997, and is not a new or different or separat=
e thing.

I will give an example. Suppose a largish ISP has 1000 customers and 500 pee=
rs. They allow customers to send communities with only a standard config. Ho=
wever , they only send communities to a select few, and then only in highly c=
ustomized configs. They don't send communities to peers, and do pass communi=
ties from customers up to their transit providers.

Making the default "on" instead of "off", means large communities will leak e=
verywhere. Filtering will happen, but not everywhere at once. This will make=
 it harder to track down the places where filtering should be done, since wh=
ether large communities show up may depend on path selection at any given mo=
ment. The attributes changing will induce BGP churn as updates propagate. Th=
at churn may in fact trigger load-induced brown-outs and further induce chur=
n.

Note that all of the above occurs as soon as large communities are used, eve=
n if the ISP above was a 16-bit ASN with only 16-bit ASN peers.

In other words, it is conceivable that an unintended consequence could be a l=
ong-duration or even permanent instability to the global Internet.

The use case is, IMNSHO, not compelling, so please, let's keep the default t=
he same as it is for 1997.

(But by all means provide knobs for changing the default for a single router=
.)

Brian=


From nobody Sun Nov  6 15:16:46 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD67E1299CA for ; Sun,  6 Nov 2016 15:16:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level: 
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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 biWHlrg8RvJL for ; Sun,  6 Nov 2016 15:16:44 -0800 (PST)
Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6A9A1299BF for ; Sun,  6 Nov 2016 15:16:43 -0800 (PST)
Received: by mail-wm0-x22e.google.com with SMTP id p190so151133265wmp.1 for ; Sun, 06 Nov 2016 15:16:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=JOagD5CR5w4brtIl23Tt8IsSNvlUKs+e8IZPCW3FNV8=; b=BAl44Dx7hmzYUtuJdkPtvRrWsT5292zL2T33AXFP1OYl0wzP1vywgBtUzZPDB8jj93 kmmWtrdkWKO4U75h4Y3Kv5hk71GcwH34Dh+w81wKCCowAXc/B9NxvthltDUI4yI2pXlH qfUjksalUMK0tcZ5YIEEO1Ig8MEhYVcvD2XloLt8eYVpvbcVLS6jEocjWfYUmpllxBnY c37sWxBc3GSsxSXXlb1/q7xaG1jkYbKGWC4yrfaQQRRkYkAl0aKNQV0GP5k1fzwDDp61 fLUUZOkSmKL9k8kxP4jldeeVUzmjn9zWfCoXFTdOUooxJrLtXgkaNfnxsmtnRH+6a4pj ArDQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=JOagD5CR5w4brtIl23Tt8IsSNvlUKs+e8IZPCW3FNV8=; b=OuR0tVcp1QA1niGjF6ec3PxAtSaxv5brm3jxZbN4wUNfmIo7b0HYHdkM5FHhF2NrPs WcJGBe0zRzVyUYs3F1s2nLmrvCnWm6mXPluFrXHYsBC3i1FZ4LPCy+VYeZltBhjY1DoE 8v0x3moDMdFd7XUuN6RAK0WHTa6RoUaPfJvLd9Jte6BYEonM5T9AXHkbXhur8ZaEO6Zz w5W3hg38sR0IvYsDUk6WdX56oUchEhNStKbaW6vx+UHyLMFyc8vjE/0nEjxnpIHrji6N LESP5hkyD3Jv88fRD79PxAyIO8lJqDlXVRY65ZrRpURKG3j44Wt+A22iRtGpt8CsOawB qumw==
X-Gm-Message-State: ABUngve6nqnJzLJgep2RaEaUqBfSpzBk+4Q7Sa2BCNgL8/YhGZ26ez8NSmZlDF4iUPhkqDoluJyx/o9qtEHecg==
X-Received: by 10.194.26.133 with SMTP id l5mr3080405wjg.4.1478474202321; Sun, 06 Nov 2016 15:16:42 -0800 (PST)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.80.137.69 with HTTP; Sun, 6 Nov 2016 15:16:41 -0800 (PST)
In-Reply-To: <17E646EF-4633-423B-9AC4-B53D49C90632@gmail.com>
References:  <86860386-9C2B-4BD5-B457-2A6DA5446CF3@cisco.com> <17E646EF-4633-423B-9AC4-B53D49C90632@gmail.com>
From: Robert Raszuk 
Date: Mon, 7 Nov 2016 00:16:41 +0100
X-Google-Sender-Auth: WbQ8dv_PJVwbR-gO4aHSxHcwJ-8
Message-ID: 
To: Brian Dickson 
Content-Type: multipart/alternative; boundary=089e0160a4d6a39b560540aa191e
Archived-At: 
Cc: heasley , "idr@ietf.org" 
Subject: Re: [Idr] Vendor Defaults (was Re: Review of draft-ietf-large-community-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: Sun, 06 Nov 2016 23:16:46 -0000

--089e0160a4d6a39b560540aa191e
Content-Type: text/plain; charset=UTF-8

Hello Brian,

> The attributes changing will induce BGP churn as updates propagate.
> That churn may in fact trigger load-induced brown-outs and further
> induce churn.

BGP communities are not used in best path selection and their presence or
non presence have zero influence to change in bgp path selection hence no
direct relation to bgp churn what so ever (leave alone quote "permanent
instability to the global Internet").

If you are concerned that honoring by advertiser his own published
community will introduce BGP churn (as embedded actions may result in for
example AS_PATH prepend action) and that you are going to save the global
Internet by default filtering large communities  which otherwise may reach
the given's community advertising AS - it is your understanding on how BGP
works .. not mine.

Kind regards,
Robert.


On Sun, Nov 6, 2016 at 11:56 PM, Brian Dickson <
brian.peter.dickson@gmail.com> wrote:

>
>
> Sent from my iPhone
>
> > On Nov 5, 2016, at 4:13 PM, Jakob Heitz (jheitz) 
> wrote:
> > In my large-community code, I have lumped them under
> send-community-ebgp. At this point, I am very open to suggestions for
> configuration. Once the code is released, it gets much harder to change
> configs.
>
> The following is my opinion, but I am confident that most operators concur
> with it:
>
> Large is not a "new" attribute per se.
> Large is providing parity for RFC1997, for use with 32-bit ASNs.
>
> For that reason alone, the only sane implementation approach is "off by
> default", so as to be consistent with the default for 1997.
>
> If someone does not use 1997 today, either choice would be okay.
>
> However, for those using 1997, all of their BGP peering configs are
> well-baked, and whatever they use for managing them has 1997 built into it.
>
> Those ASNs will be the early adopters and heaviest receive-side users
> (defining their name spaces in particular). When they ask for feature
> parity, that includes consistency with how they deploy and manage all types
> of communities.
>
> Changing the default behavior between 1997 and large would likely cause
> chaos, anger, and frustration.
>
> If anyone advocates for this change, it is clear they are not listening to
> operators, or do not understand what they want and why they want it.
> Operators who have 16-bit ASNs and use 1997, want to offer identical
> features as relates to 32-bit target ASNs. Operators with 32-bit ASN need
> this to do any 1997-type things, as clients (setting large communities) or
> as servers (receive-side handling). It augments 1997, and is not a new or
> different or separate thing.
>
> I will give an example. Suppose a largish ISP has 1000 customers and 500
> peers. They allow customers to send communities with only a standard
> config. However , they only send communities to a select few, and then only
> in highly customized configs. They don't send communities to peers, and do
> pass communities from customers up to their transit providers.
>
> Making the default "on" instead of "off", means large communities will
> leak everywhere. Filtering will happen, but not everywhere at once. This
> will make it harder to track down the places where filtering should be
> done, since whether large communities show up may depend on path selection
> at any given moment. The attributes changing will induce BGP churn as
> updates propagate. That churn may in fact trigger load-induced brown-outs
> and further induce churn.
>
> Note that all of the above occurs as soon as large communities are used,
> even if the ISP above was a 16-bit ASN with only 16-bit ASN peers.
>
> In other words, it is conceivable that an unintended consequence could be
> a long-duration or even permanent instability to the global Internet.
>
> The use case is, IMNSHO, not compelling, so please, let's keep the default
> the same as it is for 1997.
>
> (But by all means provide knobs for changing the default for a single
> router.)
>
> Brian

--089e0160a4d6a39b560540aa191e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hello Brian,
> The attributes changing will induce BGP churn as updates=
 propagate.=C2=A0
> That churn may in fact trigger loa=
d-induced brown-outs and further=C2=A0
> induce churn.=


BGP communities are not used=
 in best path selection and their presence or non presence have zero influe=
nce to change in bgp path selection hence no direct relation to bgp churn w=
hat so ever (leave alone quote "permanent instability to the global Internet=
").=C2=A0

If you are concerned tha=
t honoring by advertiser his own published community will introduce BGP chu=
rn (as embedded actions may result in for example AS_PATH prepend action) a=
nd that you are going to save the global Internet by default filtering larg=
e communities =C2=A0which otherwise may reach the given's community adv=
ertising AS - it is your understanding on how BGP works .. not mine.=C2=A0<=
/span>

Kind regards,
Robert.


On Sun, Nov 6, 2016 at 11:56 PM, Brian Dickson <brian.peter.dickson@gmail.com> wrote:




Sent from my iPhone



> On Nov 5, 2016, at 4:13 PM, Jakob Heitz (jheitz) <jheitz@cisco.com> wrote:

> In my large-community code, I have lumped them under send-community-eb=
gp. At this point, I am very open to suggestions for configuration. Once th=
e code is released, it gets much harder to change configs.



The following is my opinion, but I am confident that most operators =
concur with it:



Large is not a "new" attribute per se.

Large is providing parity for RFC1997, for use with 32-bit ASNs.



For that reason alone, the only sane implementation approach is "off b=
y default", so as to be consistent with the default for 1997.



If someone does not use 1997 today, either choice would be okay.



However, for those using 1997, all of their BGP peering configs are well-ba=
ked, and whatever they use for managing them has 1997 built into it.



Those ASNs will be the early adopters and heaviest receive-side users (defi=
ning their name spaces in particular). When they ask for feature parity, th=
at includes consistency with how they deploy and manage all types of commun=
ities.



Changing the default behavior between 1997 and large would likely cause cha=
os, anger, and frustration.



If anyone advocates for this change, it is clear they are not listening to =
operators, or do not understand what they want and why they want it. Operat=
ors who have 16-bit ASNs and use 1997, want to offer identical features as =
relates to 32-bit target ASNs. Operators with 32-bit ASN need this to do an=
y 1997-type things, as clients (setting large communities) or as servers (r=
eceive-side handling). It augments 1997, and is not a new or different or s=
eparate thing.



I will give an example. Suppose a largish ISP has 1000 customers and 500 pe=
ers. They allow customers to send communities with only a standard config. =
However , they only send communities to a select few, and then only in high=
ly customized configs. They don't send communities to peers, and do pas=
s communities from customers up to their transit providers.



Making the default "on" instead of "off", means large c=
ommunities will leak everywhere. Filtering will happen, but not everywhere =
at once. This will make it harder to track down the places where filtering =
should be done, since whether large communities show up may depend on path =
selection at any given moment. The attributes changing will induce BGP chur=
n as updates propagate. That churn may in fact trigger load-induced brown-o=
uts and further induce churn.



Note that all of the above occurs as soon as large communities are used, ev=
en if the ISP above was a 16-bit ASN with only 16-bit ASN peers.



In other words, it is conceivable that an unintended consequence could be a=
 long-duration or even permanent instability to the global Internet.



The use case is, IMNSHO, not compelling, so please, let's keep the defa=
ult the same as it is for 1997.



(But by all means provide knobs for changing the default for a single route=
r.)



Brian



--089e0160a4d6a39b560540aa191e--


From nobody Sun Nov  6 15:25:56 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19AD7129A68 for ; Sun,  6 Nov 2016 15:25:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.018
X-Spam-Level: 
X-Spam-Status: No, score=-16.018 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=-1.497, 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 C3OKiwR2-9Cq for ; Sun,  6 Nov 2016 15:25:54 -0800 (PST)
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 EC5F1129A6B for ; Sun,  6 Nov 2016 15:25:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1098; q=dns/txt; s=iport; t=1478474753; x=1479684353; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=mDn8Hui9Lb4AfYGqRX/gCsMahTtCJs4FoDuSlKYTcPA=; b=ZpTdy87rhA2oj/V+SCaYlBNjquqJ24sOu9LrzKqOEpRWRK0GhhhSS0pr curxE8FINLNh2SR7cQdgKcN8urcBn6Rugl+RlVd1e8So+dgPvRNykDOze BlJzvG+uQstQtyDMLyqt93J1nlKTEcTiB22ToJgZbDZOdPWRrJOfMUgfu 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DJAQCyux9Y/49dJa1dGwEBAQMBAQEJA?= =?us-ascii?q?QEBgy4BAQEBAR+PDKtSggiGJAKCCT8UAQIBAQEBAQEBYh0LhGIBAQQ6TwIBCDY?= =?us-ascii?q?QMiUCBCeIRLMMizsBAQEBAQEBAQEBAQEBAQEBAQEBHoY+gX0IglCER4Mxgi8Fm?= =?us-ascii?q?icBkEOQEJEvAR43eoUqiG8BAQE?=
X-IronPort-AV: E=Sophos;i="5.31,603,1473120000"; d="scan'208";a="166260628"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Nov 2016 23:25:28 +0000
Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id uA6NPSBs031490 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Sun, 6 Nov 2016 23:25:28 GMT
Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 6 Nov 2016 17:25:28 -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; Sun, 6 Nov 2016 17:25:28 -0600
From: "Jakob Heitz (jheitz)" 
To: "idr@ietf.org" 
Thread-Topic: [Idr] Vendor Defaults (was Re: Review of draft-ietf-large-community-06.txt)
Thread-Index: AQHSN546iba0WaPSYk6woE67Sz8aq6DLBUg9gAHyDwD//6OKGg==
Date: Sun, 6 Nov 2016 23:25:27 +0000
Message-ID: <6CAFC026-6102-42BF-97FA-779457D84ECE@cisco.com>
References:  <86860386-9C2B-4BD5-B457-2A6DA5446CF3@cisco.com>, <17E646EF-4633-423B-9AC4-B53D49C90632@gmail.com>
In-Reply-To: <17E646EF-4633-423B-9AC4-B53D49C90632@gmail.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] Vendor Defaults (was Re: Review of draft-ietf-large-community-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: Sun, 06 Nov 2016 23:25:55 -0000

The question:
Should Large Communities be transmitted across EBGP by default?

Note: there is a knob to change the default, so the discussion is how to ac=
t with the knob unconfigured.

Arguments to block:
1. Principle of least surprise: Do same as 1997.
2. Accidental leakage of internally used communities will cause unintended =
routing.

Arguments to pass:
1. Legacy code will pass it, because the attribute is transitive. Upgrade t=
o LC aware code should do the same by default.
2. It is convenient to pass a community through your first level transit to=
 fix a problem further upstream. A default block frustrates this effort.

The problem of accidental leakage is greater with 1997 communities, because=
 many ISPs use private ASNs. This is as problem if a community intended for=
 a distant ISP is interpreted by a near ISP when they use the same private =
ASN. This problem SHOULD disappear with Large Communities, because the need=
 to use private ASNs no longer exists.

I would like to hear other arguments and gauge support for each case.

Thanks,
Jakob.


From nobody Sun Nov  6 15:30:56 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE0C0129A4D for ; Sun,  6 Nov 2016 15:30:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level: 
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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 npn31qQSi-Zz for ; Sun,  6 Nov 2016 15:30:52 -0800 (PST)
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 68195129A4E for ; Sun,  6 Nov 2016 15:30:52 -0800 (PST)
Received: by mail-wm0-x235.google.com with SMTP id a197so151130678wmd.0 for ; Sun, 06 Nov 2016 15:30:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=P+Y4K2C8KaW2ig+OAG3MzkBJcvERhkglw05q5wam5mE=; b=y1uqUIv0xKSC/wrymfBpk0VLLtiGuANmY+B97HNwBCs46DMjRQPPLJ9eQF42n4bYdb SM+O3Ue38ysY4S1aHqz05k+gGN4TZXd0OjIL/putexfm6ihgfvkBZvR0/5OkeStnm3x2 mpRIi4t6/7wISNzCghsvaKMN1VHmQtbZe51Tpy8ijxYDkhH/jGGAOKMV7wI1u2W5OaAR TJIRr0l7A9HgblOzsgZbBItHNxd3g6YWcO1gv+w7NkiSTfFLRKOA9gJO1ynS/bPIJnlu ZVcm1iwUri7oOgKjg/ahTPbd/1q5/Lu5fCqq+LwTpb0+uG9KAJoPxXsEXS3QVAcRyYfW VzkQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=P+Y4K2C8KaW2ig+OAG3MzkBJcvERhkglw05q5wam5mE=; b=deRuZT6c97nhAd5xD9XqkDutwjXP7Ub7kaBZqjheAgMkXaAz7hbceiPkbddLrOQW83 H8aeGgfWQMfNOI64F4XaZF6y8KZ9+PYUhsqXs4ka0hErTa00U54PumMaJp/68nBJwwj2 6yJRzyk3wmKXImwM2eNKQLt/oZ4uAlsKetQdGpkYdxFcXk7RcIQ7WZMj/zXy+zoxfC95 haty3TAI8lQyvQvGjL2/yvaGmG0Me1voXiXmtX0wVpSiRQkLNTf4WGowvpOcjSm8d41C fZp40/U2iOIgwXX4NOCzr5krv/+xGCJ/LA/y97tWTdWmFTJq5RW1dlwyb0cmwr3a2x7e wdwA==
X-Gm-Message-State: ABUngvdA0Y/Mlrb3Y6V9LG/Jnal8RV7vHjMorlruPNz3ilV4xRjf45P9Bi5NGZflSP755LiUCMOyaVvZ44UUSw==
X-Received: by 10.28.17.134 with SMTP id 128mr4503373wmr.17.1478475050813; Sun, 06 Nov 2016 15:30:50 -0800 (PST)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.80.137.69 with HTTP; Sun, 6 Nov 2016 15:30:49 -0800 (PST)
In-Reply-To: <6CAFC026-6102-42BF-97FA-779457D84ECE@cisco.com>
References:  <86860386-9C2B-4BD5-B457-2A6DA5446CF3@cisco.com> <17E646EF-4633-423B-9AC4-B53D49C90632@gmail.com> <6CAFC026-6102-42BF-97FA-779457D84ECE@cisco.com>
From: Robert Raszuk 
Date: Mon, 7 Nov 2016 00:30:49 +0100
X-Google-Sender-Auth: mvwWoQXsdecBi4BcTGDlbl8RlVg
Message-ID: 
To: "Jakob Heitz (jheitz)" 
Content-Type: multipart/alternative; boundary=001a114706703690580540aa4cfd
Archived-At: 
Cc: "idr@ietf.org" 
Subject: Re: [Idr] Vendor Defaults (was Re: Review of draft-ietf-large-community-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: Sun, 06 Nov 2016 23:30:54 -0000

--001a114706703690580540aa4cfd
Content-Type: text/plain; charset=UTF-8

Hi Jakob,

Very fair and good summary !

One question: What is "unintended routing" ? Are you alluding to "churn" If
so pls see my reply to previous post.

Just to reiterate ... I do recommend that whatever option gets more support
it should be spelled out in the Large Community RFC such that all
implementations can be consistent.

Best,
Robert


On Mon, Nov 7, 2016 at 12:25 AM, Jakob Heitz (jheitz) 
wrote:

> The question:
> Should Large Communities be transmitted across EBGP by default?
>
> Note: there is a knob to change the default, so the discussion is how to
> act with the knob unconfigured.
>
> Arguments to block:
> 1. Principle of least surprise: Do same as 1997.
> 2. Accidental leakage of internally used communities will cause unintended
> routing.
>
> Arguments to pass:
> 1. Legacy code will pass it, because the attribute is transitive. Upgrade
> to LC aware code should do the same by default.
> 2. It is convenient to pass a community through your first level transit
> to fix a problem further upstream. A default block frustrates this effort.
>
> The problem of accidental leakage is greater with 1997 communities,
> because many ISPs use private ASNs. This is as problem if a community
> intended for a distant ISP is interpreted by a near ISP when they use the
> same private ASN. This problem SHOULD disappear with Large Communities,
> because the need to use private ASNs no longer exists.
>
> I would like to hear other arguments and gauge support for each case.
>
> Thanks,
> Jakob.
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>

--001a114706703690580540aa4cfd
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Jakob,

<=
/div>
Very fair and good summary !=C2=A0

One question: What is "unintended routing&quo=
t; ? Are you alluding to "churn" If so pls see my reply to previo=
us post.=C2=A0

=
Just to reiterate ... I do recommend that whatever option gets more support=
 it should be spelled out in the Large Community RFC such that all implemen=
tations can be consistent.=C2=A0

Best,
Robert

On M=
on, Nov 7, 2016 at 12:25 AM, Jakob Heitz (jheitz) <jheitz@cisco.com>=
 wrote:
The question:

Should Large Communities be transmitted across EBGP by default?



Note: there is a knob to change the default, so the discussion is how to ac=
t with the knob unconfigured.



Arguments to block:

1. Principle of least surprise: Do same as 1997.

2. Accidental leakage of internally used communities will cause unintended =
routing.



Arguments to pass:

1. Legacy code will pass it, because the attribute is transitive. Upgrade t=
o LC aware code should do the same by default.

2. It is convenient to pass a community through your first level transit to=
 fix a problem further upstream. A default block frustrates this effort.


The problem of accidental leakage is greater with 1997 communities, because=
 many ISPs use private ASNs. This is as problem if a community intended for=
 a distant ISP is interpreted by a near ISP when they use the same private =
ASN. This problem SHOULD disappear with Large Communities, because the need=
 to use private ASNs no longer exists.



I would like to hear other arguments and gauge support for each case.



Thanks,

Jakob.




_______________________________________________

Idr mailing list

Idr@ietf.org

https://www.ietf.org/mailman/listinfo/idr





--001a114706703690580540aa4cfd--


From nobody Sun Nov  6 16:04:22 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BDFB1296B4 for ; Sun,  6 Nov 2016 16:04:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.017
X-Spam-Level: 
X-Spam-Status: No, score=-16.017 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=-1.497, 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 VtPFMOBdwReM for ; Sun,  6 Nov 2016 16:04:20 -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 F05811296B3 for ; Sun,  6 Nov 2016 16:04:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7086; q=dns/txt; s=iport; t=1478477059; x=1479686659; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=GWPeDve+XAsUvzZHvMxi0laH6NzTDhbKZNyC8PeD2H8=; b=gQtCXbK3Izj/ffFyO4mTyk15somDaayYH0koPd3GoOT3uCsT5nZ8aaTc q9FBxa2Q7qfIiZkZ1kYG8aI3csOV3SLMg8jDT71e3j6AYVcg99NW3vsg2 +toZ5PbeYu/lXeAgwxxKeJfq0J8FSlirbkdGq+u12f2s316q+c1YNSt+X o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B1AQCixB9Y/5NdJa1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgnM7AQEBAQEfWHyEK4kNpjiFGoIIHgEKhXsCggk/FAECAQEBAQEBAWI?= =?us-ascii?q?ohGIBAQQBAQFrCxACAQg/BycLFBECBA4FFIhEDrJ0izsBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEXBYY+gX2CWId4gi8FlEeFYAGGNIoPkBCNKoQFAR43ehuCW4I0cod?= =?us-ascii?q?9AQEB?=
X-IronPort-AV: E=Sophos;i="5.31,603,1473120000";  d="scan'208,217";a="168088919"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Nov 2016 00:04:12 +0000
Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id uA704CPn021313 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 7 Nov 2016 00:04:12 GMT
Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 6 Nov 2016 18:04:12 -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; Sun, 6 Nov 2016 18:04:11 -0600
From: "Jakob Heitz (jheitz)" 
To: Robert Raszuk 
Thread-Topic: [Idr] Vendor Defaults (was Re: Review of draft-ietf-large-community-06.txt)
Thread-Index: AQHSN546iba0WaPSYk6woE67Sz8aq6DLBUg9gAHyDwD//6OKGoAAZhSA//+kvhQ=
Date: Mon, 7 Nov 2016 00:04:11 +0000
Message-ID: 
References:  <86860386-9C2B-4BD5-B457-2A6DA5446CF3@cisco.com> <17E646EF-4633-423B-9AC4-B53D49C90632@gmail.com> <6CAFC026-6102-42BF-97FA-779457D84ECE@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
Content-Type: multipart/alternative; boundary="_000_C2C26B2F75A049FBB9474B957611A23Eciscocom_"
MIME-Version: 1.0
Archived-At: 
Cc: "idr@ietf.org" 
Subject: Re: [Idr] Vendor Defaults (was Re: Review of draft-ietf-large-community-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: Mon, 07 Nov 2016 00:04:21 -0000

--_000_C2C26B2F75A049FBB9474B957611A23Eciscocom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

An example of unintended routing:
Both AS2914 and AS49544 use the private ASN 65501 to prepend one time.
If a route using 65501 in the community traverses both these ASes, then eac=
h AS will prepend, resulting in (likely unintended) double prepending.
https://onestep.net/communities/as2914/
https://onestep.net/communities/as49544/

Thanks,
Jakob.


On Nov 6, 2016, at 3:30 PM, Robert Raszuk > wrote:

Hi Jakob,

Very fair and good summary !

One question: What is "unintended routing" ? Are you alluding to "churn" If=
 so pls see my reply to previous post.

Just to reiterate ... I do recommend that whatever option gets more support=
 it should be spelled out in the Large Community RFC such that all implemen=
tations can be consistent.

Best,
Robert


On Mon, Nov 7, 2016 at 12:25 AM, Jakob Heitz (jheitz) > wrote:
The question:
Should Large Communities be transmitted across EBGP by default?

Note: there is a knob to change the default, so the discussion is how to ac=
t with the knob unconfigured.

Arguments to block:
1. Principle of least surprise: Do same as 1997.
2. Accidental leakage of internally used communities will cause unintended =
routing.

Arguments to pass:
1. Legacy code will pass it, because the attribute is transitive. Upgrade t=
o LC aware code should do the same by default.
2. It is convenient to pass a community through your first level transit to=
 fix a problem further upstream. A default block frustrates this effort.

The problem of accidental leakage is greater with 1997 communities, because=
 many ISPs use private ASNs. This is as problem if a community intended for=
 a distant ISP is interpreted by a near ISP when they use the same private =
ASN. This problem SHOULD disappear with Large Communities, because the need=
 to use private ASNs no longer exists.

I would like to hear other arguments and gauge support for each case.

Thanks,
Jakob.

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


--_000_C2C26B2F75A049FBB9474B957611A23Eciscocom_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable







An example of unintended routing:


Both AS2914 and AS49544 use the private ASN 65501 to prepend one time.=



If a route using 65501 in the community traverses both these ASes, the=
n each AS will prepend, resulting in (likely unintended) double prepending.=







On Nov 6, 2016, at 3:30 PM, Robert Raszuk <robert@raszuk.net> wrote:













Hi Jakob,









Very fair and good summary ! 









One question: What is "unintended routing" ? Are you alluding to "churn&q=
uot; If so pls see my reply to previous post. 









Just to reiterate ... I do recommend that whatever option gets more support=
 it should be spelled out in the Large Community RFC such that all implemen=
tations can be consistent. 









Best,



Robert













On Mon, Nov 7, 2016 at 12:25 AM, Jakob Heitz (jh=
eitz) 
<jheitz@cisco.com<=
/a>> wrote:



The question:

Should Large Communities be transmitted across EBGP by default?



Note: there is a knob to change the default, so the discussion is how to ac=
t with the knob unconfigured.



Arguments to block:

1. Principle of least surprise: Do same as 1997.

2. Accidental leakage of internally used communities will cause unintended =
routing.



Arguments to pass:

1. Legacy code will pass it, because the attribute is transitive. Upgrade t=
o LC aware code should do the same by default.

2. It is convenient to pass a community through your first level transit to=
 fix a problem further upstream. A default block frustrates this effort.


The problem of accidental leakage is greater with 1997 communities, because=
 many ISPs use private ASNs. This is as problem if a community intended for=
 a distant ISP is interpreted by a near ISP when they use the same private =
ASN. This problem SHOULD disappear
 with Large Communities, because the need to use private ASNs no longer exi=
sts.



I would like to hear other arguments and gauge support for each case.



Thanks,

Jakob.






_______________________________________________

Idr mailing list

Idr@ietf.org

https://www.ietf.org/mailman/listinfo/idr




















--_000_C2C26B2F75A049FBB9474B957611A23Eciscocom_--


From nobody Sun Nov  6 16:12:25 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0EDF1299A1 for ; Sun,  6 Nov 2016 16:12:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level: 
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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 TdgFhQ2eXtkY for ; Sun,  6 Nov 2016 16:12:21 -0800 (PST)
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 6E09A12999E for ; Sun,  6 Nov 2016 16:12:21 -0800 (PST)
Received: by mail-wm0-x235.google.com with SMTP id t79so147692518wmt.0 for ; Sun, 06 Nov 2016 16:12:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=41yUUKcsWF58yvTYe6C/AeQZmehyH+qvR9Gd1TSUwwo=; b=0fnYV/EUHVL3nQpXcDXs3ss8qpZbjKe7/Bazxbx/DLkZr38NIdKufL0jMcQeujqJpU 2SZgE1wFVbsEJBH5cYgt4zLzi1vxuZ/IkFgUAs1HFj1yfHiR8oYRvofmWOqfju7G098o F/aH4Q15zNDa3qNx5/Gve/QmzSKwE0R/8tZHym+Z12FzgDg0AGY6sdxrUksFb/R7+syR rND8Jby/zd7TygT+msdRGTg1KGyBwir4+SfsNWXVDOxK+abKTPc9+FokiX6ozdIxLRe2 OFplUza+Ktlc4j1yuQxkqFWQn6bcHidMXfejBO7vzBlXZ75xz90mv8tADGfrD99V6iaC W/nQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=41yUUKcsWF58yvTYe6C/AeQZmehyH+qvR9Gd1TSUwwo=; b=NFCfLQts/NY9RgaaTipbu3AaJzUDTceJZlyNG9h/+24cXLnDD7zXQrGDWrYnsKnzAh BJ9Kd71wBUppf0OT57tkCMpTYbveN4Tpek9gF+PX/Hh5cZbLwb/67zdRcvBIvSUMHEBL IHybUAoA0tuaYml1nO6mw31RY032qjDyVk0IpgrtUUVEMZLJ513/UYDxB7DgRVIvnRvy bqiRP3nCe7P1a5y/EbyFOcbD6Uc1VOC+o7V0mnnMSeKTQxRuCa+GvDukIgVWpuFls0ff shRPRRpr/cQYDFf9Jzm0bUSAgnsDMw5OTWdGLCAFLIvDbQPdx6cAxyQ2hxT4CBFCVlOs KeIQ==
X-Gm-Message-State: ABUngvf2W80MYmdjDUgUkXCGoIQcMtSprQSUOqiRTY7RWPLSYe1tyV6b2uERG5LaVey+LTM1Cy7xKBk+MSukgw==
X-Received: by 10.28.210.195 with SMTP id j186mr6079887wmg.73.1478477539953; Sun, 06 Nov 2016 16:12:19 -0800 (PST)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.80.137.69 with HTTP; Sun, 6 Nov 2016 16:12:18 -0800 (PST)
In-Reply-To: 
References:  <86860386-9C2B-4BD5-B457-2A6DA5446CF3@cisco.com> <17E646EF-4633-423B-9AC4-B53D49C90632@gmail.com> <6CAFC026-6102-42BF-97FA-779457D84ECE@cisco.com>  
From: Robert Raszuk 
Date: Mon, 7 Nov 2016 01:12:18 +0100
X-Google-Sender-Auth: hTpvCeZF2zi04yShHP-GDVXeh3w
Message-ID: 
To: "Jakob Heitz (jheitz)" 
Content-Type: multipart/alternative; boundary=001a11468e1493d1850540aae0e5
Archived-At: 
Cc: "idr@ietf.org" 
Subject: Re: [Idr] Vendor Defaults (was Re: Review of draft-ietf-large-community-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: Mon, 07 Nov 2016 00:12:24 -0000

--001a11468e1493d1850540aae0e5
Content-Type: text/plain; charset=UTF-8

Isn't the main motivation of LC to avoid overloading the target ASN with
private ASN values to embed the action ?

Besides both are applicable to their directly connected customers so really
regardless of the default those should be dropped by policy after
execution/application.

Thanks,
R.

On Mon, Nov 7, 2016 at 1:04 AM, Jakob Heitz (jheitz) 
wrote:

> An example of unintended routing:
> Both AS2914 and AS49544 use the private ASN 65501 to prepend one time.
> If a route using 65501 in the community traverses both these ASes, then
> each AS will prepend, resulting in (likely unintended) double prepending.
> https://onestep.net/communities/as2914/
> https://onestep.net/communities/as49544/
>
> Thanks,
> Jakob.
>
>
> On Nov 6, 2016, at 3:30 PM, Robert Raszuk  wrote:
>
> Hi Jakob,
>
> Very fair and good summary !
>
> One question: What is "unintended routing" ? Are you alluding to "churn"
> If so pls see my reply to previous post.
>
> Just to reiterate ... I do recommend that whatever option gets more
> support it should be spelled out in the Large Community RFC such that all
> implementations can be consistent.
>
> Best,
> Robert
>
>
> On Mon, Nov 7, 2016 at 12:25 AM, Jakob Heitz (jheitz) 
> wrote:
>
>> The question:
>> Should Large Communities be transmitted across EBGP by default?
>>
>> Note: there is a knob to change the default, so the discussion is how to
>> act with the knob unconfigured.
>>
>> Arguments to block:
>> 1. Principle of least surprise: Do same as 1997.
>> 2. Accidental leakage of internally used communities will cause
>> unintended routing.
>>
>> Arguments to pass:
>> 1. Legacy code will pass it, because the attribute is transitive. Upgrade
>> to LC aware code should do the same by default.
>> 2. It is convenient to pass a community through your first level transit
>> to fix a problem further upstream. A default block frustrates this effort.
>>
>> The problem of accidental leakage is greater with 1997 communities,
>> because many ISPs use private ASNs. This is as problem if a community
>> intended for a distant ISP is interpreted by a near ISP when they use the
>> same private ASN. This problem SHOULD disappear with Large Communities,
>> because the need to use private ASNs no longer exists.
>>
>> I would like to hear other arguments and gauge support for each case.
>>
>> Thanks,
>> Jakob.
>>
>> _______________________________________________
>> 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
>
>

--001a11468e1493d1850540aae0e5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



Isn't =
the main motivation of LC to avoid overloading the target ASN with private =
ASN values to embed the action ?=C2=A0

Besides both are applicable to their directly connected cu=
stomers so really regardless of the default those should be dropped by poli=
cy after execution/application.=C2=A0

Thanks,
R.

On Mon, Nov 7, 2016 at 1:04 AM=
, Jakob Heitz (jheitz) <jheitz@cisco.com> wrote:







An example of unintended routing:


Both AS2914 and AS49544 use the private ASN 65501 to prepend one time.=



If a route using 65501 in the community traverses both these ASes, the=
n each AS will prepend, resulting in (likely unintended) double prepending.=








On Nov 6, 2016, at 3:30 PM, Robert Raszuk <robert@raszuk.net> wrote:













Hi Jakob,









Very fair and good summary !=C2=A0









One question: What is "unintended routing" ? Are you alluding to "churn&q=
uot; If so pls see my reply to previous post.=C2=A0









Just to reiterate ... I do recommend that whatever option gets more support=
 it should be spelled out in the Large Community RFC such that all implemen=
tations can be consistent.=C2=A0









Best,



Robert













On Mon, Nov 7, 2016 at 12:25 AM, Jakob Heitz (jh=
eitz) 
<jheitz@cisco.com<=
/a>> wrote:



The question:

Should Large Communities be transmitted across EBGP by default?



Note: there is a knob to change the default, so the discussion is how to ac=
t with the knob unconfigured.



Arguments to block:

1. Principle of least surprise: Do same as 1997.

2. Accidental leakage of internally used communities will cause unintended =
routing.



Arguments to pass:

1. Legacy code will pass it, because the attribute is transitive. Upgrade t=
o LC aware code should do the same by default.

2. It is convenient to pass a community through your first level transit to=
 fix a problem further upstream. A default block frustrates this effort.


The problem of accidental leakage is greater with 1997 communities, because=
 many ISPs use private ASNs. This is as problem if a community intended for=
 a distant ISP is interpreted by a near ISP when they use the same private =
ASN. This problem SHOULD disappear
 with Large Communities, because the need to use private ASNs no longer exi=
sts.



I would like to hear other arguments and gauge support for each case.



Thanks,

Jakob.






_______________________________________________

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





--001a11468e1493d1850540aae0e5--


From nobody Sun Nov  6 17:07:06 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2195B129A62 for ; Sun,  6 Nov 2016 17:07:04 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i9MTVLFm_Ubt for ; Sun,  6 Nov 2016 17:07:01 -0800 (PST)
Received: from mail.i3d.net (mail.i3d.nl [213.163.77.240]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58F3C129A5F for ; Sun,  6 Nov 2016 17:07:00 -0800 (PST)
X-Footer: aTNkLm5s
Received: from localhost ([127.0.0.1]) by mail.i3d.net with ESMTPSA (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256 bits)); Mon, 7 Nov 2016 02:06:52 +0100
User-Agent: K-9 Mail for Android
In-Reply-To: 
References:  <86860386-9C2B-4BD5-B457-2A6DA5446CF3@cisco.com> <17E646EF-4633-423B-9AC4-B53D49C90632@gmail.com> <6CAFC026-6102-42BF-97FA-779457D84ECE@cisco.com>,  
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----74QWZWGQKBXHPV3KF7DLGSP2YFIOEX"
Content-Transfer-Encoding: 8bit
From: martijnschmidt@i3d.net
Date: Mon, 07 Nov 2016 02:06:38 +0100
To: "Jakob Heitz (jheitz)" , Robert Raszuk 
Message-ID: <0EB44887-7C06-4598-8911-D8DBA8532D53@i3d.net>
Archived-At: 
Cc: "idr@ietf.org" 
Subject: Re: [Idr] Vendor Defaults (was Re: Review of draft-ietf-large-community-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: Mon, 07 Nov 2016 01:07:04 -0000

------74QWZWGQKBXHPV3KF7DLGSP2YFIOEX
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;
 charset=UTF-8

Worse still, if a certain ISP is dualhomed one could make the prefix partially unreachable for a significant portion of the Internet. Say that AS49544 would be multihomed between AS2914 + AS3356 and a customer of the first network sets 65500:3356, then both networks would not export to AS3356. Because neither AS2914 nor AS3356 buys transit, the result would be that singlehomed customers of AS3356 don't receive the prefix at all. Fortunately, that problem goes away with Large Communities thanks to the Global Administrator field. Jakob, I think this addresses your 2nd "argument to block". 

Continuing my argument, today's routers (at least Brocade) have the following default behaviour when handling RFC1997 communities: accept everything, but don't pass it on to your neighbors, neither iBGP nor eBGP. Of course that default doesn't work for us since the former would pose a security risk, and the latter would effectively break any community system. Since any neighbor can unilaterally enable send-community to begin transmitting RFC1997 communities, an ISP writing any kind of routing policy involving BGP communities must already decide for themselves how they're going to handle the receipt of a community tag from their neighbors (ignore, sanitize, pass through, etc). On the other hand, if an ISP doesn't use BGP communities in their routing policy at all the attribute means nothing and can (should?) be passed on transparently. Especially in case of Large Communities where legacy code will already behave that way. 

The takeaway from all this is that it's harmless to send communities by default. I think it's beneficial to receive as much information from your neighbors as possible. It makes debugging easier and could allow for receiving ISPs to optimise routing policy. 

Best regards, 
Martijn Schmidt 

On 7 November 2016 01:04:11 CET, "Jakob Heitz (jheitz)"  wrote:
>An example of unintended routing:
>Both AS2914 and AS49544 use the private ASN 65501 to prepend one time.
>If a route using 65501 in the community traverses both these ASes, then
>each AS will prepend, resulting in (likely unintended) double
>prepending.
>https://onestep.net/communities/as2914/
>https://onestep.net/communities/as49544/
>
>Thanks,
>Jakob.
>
>
>On Nov 6, 2016, at 3:30 PM, Robert Raszuk
>> wrote:
>
>Hi Jakob,
>
>Very fair and good summary !
>
>One question: What is "unintended routing" ? Are you alluding to
>"churn" If so pls see my reply to previous post.
>
>Just to reiterate ... I do recommend that whatever option gets more
>support it should be spelled out in the Large Community RFC such that
>all implementations can be consistent.
>
>Best,
>Robert
>
>
>On Mon, Nov 7, 2016 at 12:25 AM, Jakob Heitz (jheitz)
>> wrote:
>The question:
>Should Large Communities be transmitted across EBGP by default?
>
>Note: there is a knob to change the default, so the discussion is how
>to act with the knob unconfigured.
>
>Arguments to block:
>1. Principle of least surprise: Do same as 1997.
>2. Accidental leakage of internally used communities will cause
>unintended routing.
>
>Arguments to pass:
>1. Legacy code will pass it, because the attribute is transitive.
>Upgrade to LC aware code should do the same by default.
>2. It is convenient to pass a community through your first level
>transit to fix a problem further upstream. A default block frustrates
>this effort.
>
>The problem of accidental leakage is greater with 1997 communities,
>because many ISPs use private ASNs. This is as problem if a community
>intended for a distant ISP is interpreted by a near ISP when they use
>the same private ASN. This problem SHOULD disappear with Large
>Communities, because the need to use private ASNs no longer exists.
>
>I would like to hear other arguments and gauge support for each case.
>
>Thanks,
>Jakob.
>
>_______________________________________________
>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

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
------74QWZWGQKBXHPV3KF7DLGSP2YFIOEX
Content-Type: text/html;
 charset=utf-8
Content-Transfer-Encoding: 8bit

Worse still, if a certain ISP is dualhomed one could make the prefix partially unreachable for a significant portion of the Internet. Say that AS49544 would be multihomed between AS2914 + AS3356 and a customer of the first network sets 65500:3356, then both networks would not export to AS3356. Because neither AS2914 nor AS3356 buys transit, the result would be that singlehomed customers of AS3356 don't receive the prefix at all. Fortunately, that problem goes away with Large Communities thanks to the Global Administrator field. Jakob, I think this addresses your 2nd "argument to block". 



Continuing my argument, today's routers (at least Brocade) have the following default behaviour when handling RFC1997 communities: accept everything, but don't pass it on to your neighbors, neither iBGP nor eBGP. Of course that default doesn't work for us since the former would pose a security risk, and the latter would effectively break any community system. Since any neighbor can unilaterally enable send-community to begin transmitting RFC1997 communities, an ISP writing any kind of routing policy involving BGP communities must already decide for themselves how they're going to handle the receipt of a community tag from their neighbors (ignore, sanitize, pass through, etc). On the other hand, if an ISP doesn't use BGP communities in their routing policy at all the attribute means nothing and can (should?) be passed on transparently. Especially in case of Large Communities where legacy code will already behave that way. 



The takeaway from all this is that it's harmless to send communities by default. I think it's beneficial to receive as much information from your neighbors as possible. It makes debugging easier and could allow for receiving ISPs to optimise routing policy. 



Best regards, 

Martijn Schmidt 

On 7 November 2016 01:04:11 CET, "Jakob Heitz (jheitz)" <jheitz@cisco.com> wrote:







An example of unintended routing:


Both AS2914 and AS49544 use the private ASN 65501 to prepend one time.


If a route using 65501 in the community traverses both these ASes, then each AS will prepend, resulting in (likely unintended) double prepending.






On Nov 6, 2016, at 3:30 PM, Robert Raszuk <robert@raszuk.net> wrote:













Hi Jakob,









Very fair and good summary ! 









One question: What is "unintended routing" ? Are you alluding to "churn" If so pls see my reply to previous post. 









Just to reiterate ... I do recommend that whatever option gets more support it should be spelled out in the Large Community RFC such that all implementations can be consistent. 









Best,



Robert













On Mon, Nov 7, 2016 at 12:25 AM, Jakob Heitz (jheitz) 
<jheitz@cisco.com> wrote:



The question:

Should Large Communities be transmitted across EBGP by default?



Note: there is a knob to change the default, so the discussion is how to act with the knob unconfigured.



Arguments to block:

1. Principle of least surprise: Do same as 1997.

2. Accidental leakage of internally used communities will cause unintended routing.



Arguments to pass:

1. Legacy code will pass it, because the attribute is transitive. Upgrade to LC aware code should do the same by default.

2. It is convenient to pass a community through your first level transit to fix a problem further upstream. A default block frustrates this effort.



The problem of accidental leakage is greater with 1997 communities, because many ISPs use private ASNs. This is as problem if a community intended for a distant ISP is interpreted by a near ISP when they use the same private ASN. This problem SHOULD disappear
 with Large Communities, because the need to use private ASNs no longer exists.



I would like to hear other arguments and gauge support for each case.



Thanks,

Jakob.






_______________________________________________

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


-- 

Sent from my Android device with K-9 Mail. Please excuse my brevity.
------74QWZWGQKBXHPV3KF7DLGSP2YFIOEX--



From nobody Sun Nov  6 19:46:16 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74E77129B55 for ; Sun,  6 Nov 2016 19:46:15 -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, MIME_QP_LONG_LINE=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 s70hJhferf2S for ; Sun,  6 Nov 2016 19:46:13 -0800 (PST)
Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::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 32D7E129B4F for ; Sun,  6 Nov 2016 19:46:13 -0800 (PST)
Received: by mail-pf0-x232.google.com with SMTP id d2so84122384pfd.0 for ; Sun, 06 Nov 2016 19:46:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7C2yq9zZlc5OQIyPQdeI6Nvz1LxQDoRaWwHnwhlD1Yk=; b=MEMch5xzbWQB0Qn2BlX408oGI7uGFAlRPTGyS1xf5RL9WiQ9GoRrOcfAreacjDcKDF Ny/zDTvMCy/MziWrX3lZS7ZNie5PT2NfK5Q4e9O4ZBq7Jpb4GoMioxce/wS/pcBC1s4d DOEGqIBL64nr8s/5hJvwZMJdjKOIFT4vBS/FgAgpW4Eepu3D8eDARpxMh25LYalZyR4l u9YdLLBZQQw/ZNOHJbwmcJr5zGqCP6BrKgx/TPJhKsVm1+MEv3ug7eTYHmi3HoI7l+24 eqpnQhahd8oT31aCbgHWUXENaLa4KNnBSIiiVxQkGg+VIri6V5IpVS7lFP9XAV8XoqTx Xwgg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7C2yq9zZlc5OQIyPQdeI6Nvz1LxQDoRaWwHnwhlD1Yk=; b=NyaCn0mGRRAaB4M/erGYE+dhkArY50OWll4YfcWmQX9lwCS5YCMiuHTShSucwdonYP OiQ+wSMuE1jFsrNbMQYrZrBK13QJq3buGirXBDkZlr4Oge61VQ3U1ctyqUBUpgBG22ee FJVYt0fkMv2O/PVVSMIETS45CEgt7TammtCRTAXxPwXExkp6KYdRbFnwPPgrKN6LVYFn v2JNDsYhXo6/3ZrgB59BdqAGNPMpHB2ZYTPewgETOf+wUXsrPfZOrLTdHb87GSu0BOkg jP/KkFlxealZX+346wsrHubhpPOeip1q0ZBAxW2ID7Mpin2hZnK8uoBMhLCnRLOJzLRf c5Lw==
X-Gm-Message-State: ABUngveOAaNbj6JmSicU7EBdTGkBB/BQZQo0aKQXUvyv3NO5qwGQBMCXkRt06H/B9e9P6g==
X-Received: by 10.98.55.67 with SMTP id e64mr9768427pfa.80.1478490372699; Sun, 06 Nov 2016 19:46:12 -0800 (PST)
Received: from [192.168.5.105] (c-73-92-109-167.hsd1.ca.comcast.net. [73.92.109.167]) by smtp.gmail.com with ESMTPSA id p68sm18381819pfd.11.2016.11.06.19.46.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 06 Nov 2016 19:46:11 -0800 (PST)
Content-Type: multipart/alternative; boundary=Apple-Mail-D39CB469-0A0C-4F2E-9662-CAFB3226645A
Mime-Version: 1.0 (1.0)
From: Brian Dickson 
X-Mailer: iPhone Mail (14B100)
In-Reply-To: 
Date: Sun, 6 Nov 2016 19:46:10 -0800
Content-Transfer-Encoding: 7bit
Message-Id: <96108A84-8016-4A24-8D9D-C08F65D07572@gmail.com>
References:  <86860386-9C2B-4BD5-B457-2A6DA5446CF3@cisco.com> <17E646EF-4633-423B-9AC4-B53D49C90632@gmail.com> <6CAFC026-6102-42BF-97FA-779457D84ECE@cisco.com>   
To: Robert Raszuk 
Archived-At: 
Cc: "idr@ietf.org" 
Subject: Re: [Idr] Vendor Defaults (was Re: Review of draft-ietf-large-community-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: Mon, 07 Nov 2016 03:46:15 -0000

--Apple-Mail-D39CB469-0A0C-4F2E-9662-CAFB3226645A
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable



Sent from my iPhone

> On Nov 6, 2016, at 4:12 PM, Robert Raszuk  wrote:
>=20
>=20
> Isn't the main motivation of LC to avoid overloading the target ASN with p=
rivate ASN values to embed the action ?=20

It may be the motivation for having 3 x 32-bits, but the MAIN motivation is s=
upport for 32-bit ASNs.

It might be the case that initial deployment could incorporate 16-bit ASNs i=
n 32-bit fields, including private ASNs.

Those using 1997 might want to migrate to large-only, rather than continue s=
upporting both large and 1997. That migration could start with accepting bot=
h (1997 and large-encoded 1997 of 0000ASN16:0000ASN16:0), having customers a=
dd or switch to large, and then dropping 1997 support.

So, let's consider the implications of having large be sent by default, vs n=
ot.

When customers add the large communities, they will go everywhere if they do=
n't filter, i.e. if they aren't aware of the need to filter large communitie=
s.

So, why would that migration be expected or considered reasonable, if the lo=
ng term goal of LC is GA:target:action? Because it is the simplest, cleanest=
, and safest path.=20

Having 1997 and large simultaneously used means possible corner cases or inc=
onsistencies can occur.=20

Once the 1997 semantics are transliterated, only then can real LC be impleme=
nted on the receiving side.

That would involve two windows of overlap: 1997 to transliterated; and trans=
literated to "real" LC.

And in both windows, the 1997-semantics large communities can collide, just l=
ike the conflicting cases Jakob listed.

That issue is a non-issue if the default is "off".

> Besides both are applicable to their directly connected customers so reall=
y regardless of the default those should be dropped by policy after executio=
n/application.=20

I believe this is called "blaming the victim".

There is no easy way to tell how many such conflicts would be exposed by def=
ault "on".

20 years of  RFC1997. All with default off. 20 years of industry consolidati=
on, staff turnover, undocumented implementations.=20

Assuming that no migration will occur, isn't helpful. Changing the default b=
ehavior across such migration is the risk.

Having the same behavior for large guarantees zero incremental risk, which i=
s why I am advocating for it.

Brian


>> On Mon, Nov 7, 2016 at 1:04 AM, Jakob Heitz (jheitz)  w=
rote:
>> An example of unintended routing:
>> Both AS2914 and AS49544 use the private ASN 65501 to prepend one time.
>> If a route using 65501 in the community traverses both these ASes, then e=
ach AS will prepend, resulting in (likely unintended) double prepending.
>> https://onestep.net/communities/as2914/
>> https://onestep.net/communities/as49544/
>>=20
>> Thanks,
>> Jakob.
>>=20
>>=20
>> On Nov 6, 2016, at 3:30 PM, Robert Raszuk  wrote:
>>=20
>>> Hi Jakob,
>>>=20
>>> Very fair and good summary !=20
>>>=20
>>> One question: What is "unintended routing" ? Are you alluding to "churn"=
 If so pls see my reply to previous post.=20
>>>=20
>>> Just to reiterate ... I do recommend that whatever option gets more supp=
ort it should be spelled out in the Large Community RFC such that all implem=
entations can be consistent.=20
>>>=20
>>> Best,
>>> Robert
>>>=20
>>>=20
>>>> On Mon, Nov 7, 2016 at 12:25 AM, Jakob Heitz (jheitz)  wrote:
>>>> The question:
>>>> Should Large Communities be transmitted across EBGP by default?
>>>>=20
>>>> Note: there is a knob to change the default, so the discussion is how t=
o act with the knob unconfigured.
>>>>=20
>>>> Arguments to block:
>>>> 1. Principle of least surprise: Do same as 1997.
>>>> 2. Accidental leakage of internally used communities will cause uninten=
ded routing.
>>>>=20
>>>> Arguments to pass:
>>>> 1. Legacy code will pass it, because the attribute is transitive. Upgra=
de to LC aware code should do the same by default.
>>>> 2. It is convenient to pass a community through your first level transi=
t to fix a problem further upstream. A default block frustrates this effort.=

>>>>=20
>>>> The problem of accidental leakage is greater with 1997 communities, bec=
ause many ISPs use private ASNs. This is as problem if a community intended f=
or a distant ISP is interpreted by a near ISP when they use the same private=
 ASN. This problem SHOULD disappear with Large Communities, because the need=
 to use private ASNs no longer exists.
>>>>=20
>>>> I would like to hear other arguments and gauge support for each case.
>>>>=20
>>>> Thanks,
>>>> Jakob.
>>>>=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
>>=20
>=20
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr

--Apple-Mail-D39CB469-0A0C-4F2E-9662-CAFB3226645A
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable




Sent from my iPhone
=

On Nov 6, 2016, at 4:12 PM, Robert Raszuk <robert@raszuk.net> wrote:


I=
sn't the main motivation of LC to avoid overloading the target ASN with priv=
ate ASN values to embed the action ? 

It may be the motivation for having 3 x 32-bits, but the MA=
IN motivation is support for 32-bit ASNs.

It might b=
e the case that initial deployment could incorporate 16-bit ASNs in 32-bit f=
ields, including private ASNs.

Those using 1997 mig=
ht want to migrate to large-only, rather than continue supporting both large=
 and 1997. That migration could start with accepting both (1997 and large-en=
coded 1997 of 0000ASN16:0000ASN16:0), having customers add or switch to larg=
e, and then dropping 1997 support.

So, let's consid=
er the implications of having large be sent by default, vs not.
When customers add the large communities, they will go everywhe=
re if they don't filter, i.e. if they aren't aware of the need to filter lar=
ge communities.

So, why would that migration be exp=
ected or considered reasonable, if the long term goal of LC is GA:target:act=
ion? Because it is the simplest, cleanest, and safest path. 
=

Having 1997 and large simultaneously used means possible corn=
er cases or inconsistencies can occur. 

Once t=
he 1997 semantics are transliterated, only then can real LC be implemented o=
n the receiving side.

That would involve two window=
s of overlap: 1997 to transliterated; and transliterated to "real" LC.
=


And in both windows, the 1997-semantics large communitie=
s can collide, just like the conflicting cases Jakob listed.

<=
/div>
That issue is a non-issue if the default is "off".

Besides both are appl=
icable to their directly connected customers so really regardless of the def=
ault those should be dropped by policy after execution/application. 

I believe this is called "blaming the v=
ictim".

There is no easy way to tell how many such confli=
cts would be exposed by default "on".

20 years of &=
nbsp;RFC1997. All with default off. 20 years of industry consolidation, staf=
f turnover, undocumented implementations. 

Ass=
uming that no migration will occur, isn't helpful. Changing the default beha=
vior across such migration is the risk.

Having the s=
ame behavior for large guarantees zero incremental risk, which is why I am a=
dvocating for it.

Brian


O=
n Mon, Nov 7, 2016 at 1:04 AM, Jakob Heitz (jheitz) <jheitz@cisco.com>=
 wrote:







An example of unintended routing:


Both AS2914 and AS49544 use the private ASN 65501 to prepend one time.<=
/div>

If a route using 65501 in the community traverses both these ASes, then=
 each AS will prepend, resulting in (likely unintended) double prepending.






On Nov 6, 2016, at 3:30 PM, Robert Raszuk <robert@raszuk.net> wrote:













Hi Jakob,









Very fair and good summary ! 









One question: What is "unintended routing" ? Are you alluding to "churn" If so pls see my r=
eply to previous post. 









Just to reiterate ... I do recommend that whatever option gets more support i=
t should be spelled out in the Large Community RFC such that all implementat=
ions can be consistent. 









Best,



Robert













On Mon, Nov 7, 2016 at 12:25 AM, Jakob Heitz (jhe=
itz) 
<jheitz@cisco.com> wrote:



The question:

Should Large Communities be transmitted across EBGP by default?



Note: there is a knob to change the default, so the discussion is how to act=
 with the knob unconfigured.



Arguments to block:

1. Principle of least surprise: Do same as 1997.

2. Accidental leakage of internally used communities will cause unintended r=
outing.



Arguments to pass:

1. Legacy code will pass it, because the attribute is transitive. Upgrade to=
 LC aware code should do the same by default.

2. It is convenient to pass a community through your first level transit to f=
ix a problem further upstream. A default block frustrates this effort.



The problem of accidental leakage is greater with 1997 communities, because m=
any ISPs use private ASNs. This is as problem if a community intended for a d=
istant ISP is interpreted by a near ISP when they use the same private ASN. T=
his problem SHOULD disappear
 with Large Communities, because the need to use private ASNs no longer exis=
ts.



I would like to hear other arguments and gauge support for each case.



Thanks,

Jakob.






_______________________________________________

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-D39CB469-0A0C-4F2E-9662-CAFB3226645A--


From nobody Mon Nov  7 02:23:13 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E49C2129684 for ; Mon,  7 Nov 2016 02:23:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.398
X-Spam-Level: 
X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, SPF_HELO_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 RgBl1X08GxMs for ; Mon,  7 Nov 2016 02:23:09 -0800 (PST)
Received: from gir.theapt.org (gir.theapt.org [IPv6:2001:470:1f0b:8b2::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54A7E1294D8 for ; Mon,  7 Nov 2016 02:23:09 -0800 (PST)
Received: from gir.theapt.org (unknown [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/0 bits)) (Client did not present a certificate) (Authenticated sender: phessler) by gir.theapt.org (Postfix) with ESMTPSA id A1C6F788FC for ; Mon,  7 Nov 2016 11:23:07 +0100 (CET)
Date: Mon, 7 Nov 2016 11:23:06 +0100
From: Peter Hessler 
To: idr@ietf.org
Message-ID: <20161107102306.GV24817@gir.theapt.org>
References:  <86860386-9C2B-4BD5-B457-2A6DA5446CF3@cisco.com> <20161106040849.GB18931@shrubbery.net> <5BD3C90E-CC0E-42D2-9ACD-5787FC75BF0A@cisco.com> <20161106194258.GB5113@pfrc.org> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: 
Subject: Re: [Idr] Vendor Defaults (was Re: Review of draft-ietf-large-community-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: Mon, 07 Nov 2016 10:23:12 -0000

On 2016 Nov 06 (Sun) at 22:50:24 +0100 (+0100), Robert Raszuk wrote:
:I really wanted to make sure that large is deployed with defaults which
:make most sense and such defaults are identical between implementations.
:And we can do it now or never as when the code is shipped out in first
:production release the gave is over.
:

In OpenBGPD our default is to propagate communities; normal, extended,
and large.

We have no intention on changing that default.

Additionally, I see no reason why implementations should be have
identical defaults.  Cisco is not OpenBGPD, OpenBGPD is not Huewai, and
Huewai is not Quagga.

This is implementation specific, and has nothing to do with the
standardization process.

-- 
I am so optimistic about beef prices that I've just leased a pot roast
with an option to buy.


From nobody Mon Nov  7 04:10:11 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0695B1295D5 for ; Mon,  7 Nov 2016 04:10:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.097
X-Spam-Level: 
X-Spam-Status: No, score=-4.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497] 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 ijzi81m1cTbJ for ; Mon,  7 Nov 2016 04:10:08 -0800 (PST)
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 42257129471 for ; Mon,  7 Nov 2016 04:10:07 -0800 (PST)
X-Original-To: idr@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 7EECF606F3 for ; Mon,  7 Nov 2016 13:10:05 +0100 (CET)
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 24F8760645; Mon,  7 Nov 2016 13:10:05 +0100 (CET)
Received: by moebius4.space.net (Postfix, from userid 1007) id 211DD45ECC; Mon,  7 Nov 2016 13:10:05 +0100 (CET)
Date: Mon, 7 Nov 2016 13:10:05 +0100
From: Gert Doering 
To: "Jakob Heitz (jheitz)" 
Message-ID: <20161107121005.GS79185@Space.Net>
References:  <86860386-9C2B-4BD5-B457-2A6DA5446CF3@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <86860386-9C2B-4BD5-B457-2A6DA5446CF3@cisco.com>
X-NCC-RegID: de.space
User-Agent: Mutt/1.6.1 (2016-04-27)
Archived-At: 
Cc: heasley , "idr@ietf.org" , Robert Raszuk 
Subject: Re: [Idr] Vendor Defaults (was Re: Review of draft-ietf-large-community-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: Mon, 07 Nov 2016 12:10:10 -0000

Hi,

On Sat, Nov 05, 2016 at 11:13:46PM +0000, Jakob Heitz (jheitz) wrote:
> IOS-XR does not send communities or extended communities to eBGP neighbors by default.
> To send communities, you need to configure
>   send-community-ebgp
> Under the neighbor address-family.
> To send extended communities, you need to configure
>   send-extended-community-ebgp

This would work for our use case - "1997 and large" is "the standard
community to be sent to upstreams and customers", while "extended" is
"something special, only to used in particular cases".

I consider "large" to be "the logical extension to 1997", so I do not
see a reason to operationally differenciate here ("1997-only" or 
"large-only").

[..]
> In my large-community code, I have lumped them under send-community-ebgp. 

Works for us.

Gert Doering
        -- Operator, some exposure to BGP in the past
-- 
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 Mon Nov  7 04:13:01 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 141B01294FB for ; Mon,  7 Nov 2016 04:13:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.097
X-Spam-Level: 
X-Spam-Status: No, score=-4.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497] 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 Lu0OUT0Pl9fS for ; Mon,  7 Nov 2016 04:12:54 -0800 (PST)
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 0EC001294EF for ; Mon,  7 Nov 2016 04:12:54 -0800 (PST)
X-Original-To: idr@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 4CC8B604B9 for ; Mon,  7 Nov 2016 13:12:52 +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 EC608602A9; Mon,  7 Nov 2016 13:12:51 +0100 (CET)
Received: by moebius4.space.net (Postfix, from userid 1007) id DE25945EFD; Mon,  7 Nov 2016 13:12:51 +0100 (CET)
Date: Mon, 7 Nov 2016 13:12:51 +0100
From: Gert Doering 
To: Robert Raszuk 
Message-ID: <20161107121251.GT79185@Space.Net>
References:  <86860386-9C2B-4BD5-B457-2A6DA5446CF3@cisco.com> <17E646EF-4633-423B-9AC4-B53D49C90632@gmail.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.6.1 (2016-04-27)
Archived-At: 
Cc: heasley , "idr@ietf.org" 
Subject: Re: [Idr] Vendor Defaults (was Re: Review of draft-ietf-large-community-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: Mon, 07 Nov 2016 12:13:00 -0000

Hi,

On Mon, Nov 07, 2016 at 12:16:41AM +0100, Robert Raszuk wrote:
> > The attributes changing will induce BGP churn as updates propagate.
> > That churn may in fact trigger load-induced brown-outs and further
> > induce churn.
> 
> BGP communities are not used in best path selection 

While the communities *themselves* are not, many (most? all?) major transit
providers offer communities to influence the value local-pref is set to,
on ingress from their customers.

So, if a customer sends 5539:70 or 5539:130 to us, this will end up 
setting local-pref 70 or local-pref 130, and that *will* influence 
path selection.

So, while your statement is true, it's lacking real-world consideration.

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 Mon Nov  7 04:15:05 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 689261299FC for ; Mon,  7 Nov 2016 04:15:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.097
X-Spam-Level: 
X-Spam-Status: No, score=-4.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497] 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 d8XveESRdWUf for ; Mon,  7 Nov 2016 04:15:01 -0800 (PST)
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 6D3571299E5 for ; Mon,  7 Nov 2016 04:15:01 -0800 (PST)
X-Original-To: idr@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id A738C60659 for ; Mon,  7 Nov 2016 13:14:59 +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 756BA6014D; Mon,  7 Nov 2016 13:14:59 +0100 (CET)
Received: by moebius4.space.net (Postfix, from userid 1007) id 6658F45F1B; Mon,  7 Nov 2016 13:14:59 +0100 (CET)
Date: Mon, 7 Nov 2016 13:14:59 +0100
From: Gert Doering 
To: heasley 
Message-ID: <20161107121459.GU79185@Space.Net>
References:  <86860386-9C2B-4BD5-B457-2A6DA5446CF3@cisco.com> <20161106040849.GB18931@shrubbery.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20161106040849.GB18931@shrubbery.net>
X-NCC-RegID: de.space
User-Agent: Mutt/1.6.1 (2016-04-27)
Archived-At: 
Cc: "idr@ietf.org" , Robert Raszuk 
Subject: Re: [Idr] Vendor Defaults (was Re: Review of draft-ietf-large-community-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: Mon, 07 Nov 2016 12:15:05 -0000

Hi,

On Sun, Nov 06, 2016 at 04:08:49AM +0000, heasley wrote:
> If you consider draft-grow-bgp-reject, does that change your opinion about
> filtering needing to be the default?

IOS XR is doing exactly that.  What is your point?

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 Mon Nov  7 04:18:52 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99A17129AB3 for ; Mon,  7 Nov 2016 04:18:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level: 
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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 Pi65j2xm5H5W for ; Mon,  7 Nov 2016 04:18:47 -0800 (PST)
Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80CA0129568 for ; Mon,  7 Nov 2016 04:18:47 -0800 (PST)
Received: by mail-wm0-x22e.google.com with SMTP id p190so178939851wmp.1 for ; Mon, 07 Nov 2016 04:18:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=A+16JXWe7AUFFpVh3Q7sMyD5S0v787A4cJkiHp5srOM=; b=SjKn638aiwvxf4GcEZGRwOU+Zd/5EgAqYhTIWTJ/7emGDxwX4MdV8vESocTt1geRRU 0sBMGSsbimM0zRNgsoCaS7/IkgXfWJ3oS5bRGJW4XSX1OkRJoq0+6fFEMXUlZPa/j+Po BXwmUEaRvQ4EdG3KcqiPDxae0jAoFMblzRRtkGiuny+ZC8wzvqqfHwoVuvKaHADTY/tj YPyiqEvHMTgyrL6p6HB3yOLwuE/rpikOj+x74noUpyb03yAnKSmJwptboLh0FixkK3wK tQnVgRYb4v7bzNehBDvewHcRLsfQh+RxuLN2by5bpIlLgl5tTSSA7dnf2nGSpwszwpTS 4VbA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=A+16JXWe7AUFFpVh3Q7sMyD5S0v787A4cJkiHp5srOM=; b=ZTZ9bfImjy8cMcTQJb0v272Rcz3jboN1kzE+T3xwheGOre8SvbhsIyfZhawBcFwX1r 0cKOvPeU7JJumpBaPTmGf1ddQ3p04Fx1kqqY5aea2lCLHPfinh9zULfJttB/w2DWKr64 GzXTVgvfPz5m7kl5kRsYCqq4sEcgWC/HmzHWrgi2X1f7RX0mQ7JzqOfdBpEn0K9n/uis CBdTx6jHYplP92sZHUi4WX6Ll2abkGCW53gHEu4+Ka6HlWpedNr4YIqnzz3BEpdoM1bI 11Rj+HcbhRFIa9Z8K+xXa9SvP5j4cxEaZim+CDU+qQasVPHzKMn7OWtKNPymvAWZclPI AfXQ==
X-Gm-Message-State: ABUngvd8FP7OwMhfZn9pCXnjVXxHECNon1qLzxQOlLeiTT/kUdFUaXYE1Qahob5qV0i8sst6beu1RoLhXnGAjw==
X-Received: by 10.194.103.5 with SMTP id fs5mr4228069wjb.227.1478521126088; Mon, 07 Nov 2016 04:18:46 -0800 (PST)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.80.137.69 with HTTP; Mon, 7 Nov 2016 04:18:44 -0800 (PST)
Received: by 10.80.137.69 with HTTP; Mon, 7 Nov 2016 04:18:44 -0800 (PST)
In-Reply-To: <20161107121251.GT79185@Space.Net>
References:  <86860386-9C2B-4BD5-B457-2A6DA5446CF3@cisco.com> <17E646EF-4633-423B-9AC4-B53D49C90632@gmail.com>  <20161107121251.GT79185@Space.Net>
From: Robert Raszuk 
Date: Mon, 7 Nov 2016 13:18:44 +0100
X-Google-Sender-Auth: Z5vMlzjAY6arRB7RZ3gH6r0li2c
Message-ID: 
To: Gert Doering 
Content-Type: multipart/alternative; boundary=047d7bf10ad68378760540b50664
Archived-At: 
Cc: heasley , idr wg 
Subject: Re: [Idr] Vendor Defaults (was Re: Review of draft-ietf-large-community-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: Mon, 07 Nov 2016 12:18:51 -0000

--047d7bf10ad68378760540b50664
Content-Type: text/plain; charset=UTF-8

Gert,

My example was very clear and I provided example of AS_PATH prepend.

The point which you are missing is that if you execute community you should
clean up and delete it. Blind default on or off is not the way to stop
propagation of selected communities.

And if someone is inserting 5539:* it seems obvious that the intention is
that such community should get to 5539.

Best,
R.

On Nov 7, 2016 1:12 PM, "Gert Doering"  wrote:

> Hi,
>
> On Mon, Nov 07, 2016 at 12:16:41AM +0100, Robert Raszuk wrote:
> > > The attributes changing will induce BGP churn as updates propagate.
> > > That churn may in fact trigger load-induced brown-outs and further
> > > induce churn.
> >
> > BGP communities are not used in best path selection
>
> While the communities *themselves* are not, many (most? all?) major transit
> providers offer communities to influence the value local-pref is set to,
> on ingress from their customers.
>
> So, if a customer sends 5539:70 or 5539:130 to us, this will end up
> setting local-pref 70 or local-pref 130, and that *will* influence
> path selection.
>
> So, while your statement is true, it's lacking real-world consideration.
>
> 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
>

--047d7bf10ad68378760540b50664
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Gert,


My example was very clear and I provided example of AS_PATH =
prepend.


The point which you are missing is that if you execute commu=
nity you should clean up and delete it. Blind default on or off is not the =
way to stop propagation of selected communities.


And if someone is inserting 5539:* it seems obvious that the=
 intention is that such community should get to 5539.


Best,

R.



On Nov 7, 2016 1:=
12 PM, "Gert Doering" <gert@=
space.net> wrote:
Hi,



On Mon, Nov 07, 2016 at 12:16:41AM +0100, Robert Raszuk wrote:

> > The attributes changing will induce BGP churn as updates propagat=
e.

> > That churn may in fact trigger load-induced brown-outs and furthe=
r

> > induce churn.

>

> BGP communities are not used in best path selection



While the communities *themselves* are not, many (most? all?) major transit=


providers offer communities to influence the value local-pref is set to,
on ingress from their customers.



So, if a customer sends 5539:70 or 5539:130 to us, this will end up

setting local-pref 70 or local-pref 130, and that *will* influence

path selection.



So, while your statement is true, it's lacking real-world consideration=
.



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




--047d7bf10ad68378760540b50664--


From nobody Mon Nov  7 04:23:02 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A4E712953A for ; Mon,  7 Nov 2016 04:23:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.699
X-Spam-Level: 
X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, 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 rUtI9PW609Fy for ; Mon,  7 Nov 2016 04:22:50 -0800 (PST)
Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 2BE82129DF4 for ; Mon,  7 Nov 2016 04:22:48 -0800 (PST)
Received: from [IPv6:2603:3015:3603:8e00:dce:b8ba:3538:f68b] (unknown [IPv6:2603:3015:3603:8e00:dce:b8ba:3538:f68b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id 557B1540C41; Mon,  7 Nov 2016 07:22:47 -0500 (EST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
From: Jared Mauch 
In-Reply-To: <5BD3C90E-CC0E-42D2-9ACD-5787FC75BF0A@cisco.com>
Date: Mon, 7 Nov 2016 07:22:46 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <8035244C-BC7D-4756-88FF-6C93330291B3@puck.nether.net>
References:  <86860386-9C2B-4BD5-B457-2A6DA5446CF3@cisco.com> <20161106040849.GB18931@shrubbery.net> <5BD3C90E-CC0E-42D2-9ACD-5787FC75BF0A@cisco.com>
To: "Jakob Heitz (jheitz)" 
X-Mailer: Apple Mail (2.3251)
Archived-At: 
Cc: John Heasley , "idr@ietf.org" , Robert Raszuk 
Subject: Re: [Idr] Vendor Defaults (was Re: Review of draft-ietf-large-community-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: Mon, 07 Nov 2016 12:23:00 -0000

> On Nov 6, 2016, at 1:43 AM, Jakob Heitz (jheitz)  =
wrote:
>=20
>  it would break many existing deployments.

I think you mean bring security to these deployments.

Advocating for this is like advocating to keep ip directed-broadcast or =
open relays on the internet.  It=E2=80=99s a security risk to the =
ecosystem imposed by a vendor blindly saying =E2=80=9Cchange is hard, my =
customers can=E2=80=99t handle the technology they use=E2=80=9D.

- Jared=


From nobody Mon Nov  7 04:30:34 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB8E1295C9 for ; Mon,  7 Nov 2016 04:30:33 -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, 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bskyb.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 6dI_p7WGSMbs for ; Mon,  7 Nov 2016 04:30:30 -0800 (PST)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0068.outbound.protection.outlook.com [104.47.2.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21349129400 for ; Mon,  7 Nov 2016 04:30:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=BSkyB.onmicrosoft.com;  s=selector1-sky-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version;  bh=KP5OPutF8Vor7/sho/iY8MBE6pf1iT65wO5C5Lw1Jrs=; b=CSY9aacHDgcr3n5HQTtWv53FbSPfYDbu0eAX7cJr7mP5eg+sSDA6q1SUyeDMMNmSxTgTDsjh1dox2FwYOhs1GP0MALXGa4x36+CYZxDvOucs3EoMoTReB1v6VcwqMxVWcMcPQFZnaHqOemGgKlFPL8bmeHiYEQUSvhVsqXgcY5w=
Authentication-Results: spf=pass (sender IP is 176.255.244.223) smtp.mailfrom=sky.uk; shrubbery.net; dkim=none (message not signed) header.d=none;shrubbery.net; dmarc=pass action=none header.from=sky.uk;
Received-SPF: Pass (protection.outlook.com: domain of sky.uk designates 176.255.244.223 as permitted sender) receiver=protection.outlook.com; client-ip=176.255.244.223; helo=email.bskyb.com;
X-IncomingTopHeaderMarker: OriginalChecksum:; UpperCasedChecksum:; SizeAsReceived:1610; Count:21
From: "Dickinson, Ian" 
To: Robert Raszuk , Gert Doering 
Thread-Topic: [Idr] Vendor Defaults (was Re: Review of draft-ietf-large-community-06.txt)
Thread-Index: AQHSN54+IFsJE4jkH0y8iFuaN68kcaDLBUcAgAGNewCAAAWrgIAA2NuAgAABpQCAAAHOEA==
Date: Mon, 7 Nov 2016 12:30:25 +0000
Message-ID: <9B3BFE0A18160E40BAF1950414D10FAE61714CB7@WPMBX010.bskyb.com>
References:  <86860386-9C2B-4BD5-B457-2A6DA5446CF3@cisco.com> <17E646EF-4633-423B-9AC4-B53D49C90632@gmail.com>  <20161107121251.GT79185@Space.Net> 
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [191.255.75.235]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-IncomingHeaderCount: 21
X-EOPAttributedMessage: 0
X-MS-Office365-Filtering-HT: Tenant
X-Forefront-Antispam-Report: CIP:176.255.244.223; IPV:CAL; SCL:-1; CTRY:GB; EFV:NLI; SFV:NSPM; SFS:(10009020)(6009001)(7916002)(2980300002)(438002)(189002)(199003)(5660300001)(50466002)(305945005)(26826002)(74482002)(8676002)(106116001)(2920100001)(55846006)(586003)(87936001)(9686002)(69596002)(8936002)(86362001)(5890100001)(2906002)(11286001)(47776003)(2950100002)(33656002)(81156014)(50986999)(7846002)(5001770100001)(81166006)(230783001)(3846002)(102836003)(54356999)(6116002)(93886004)(23676002)(106466001)(92566002)(66066001)(76176999)(189998001)(7736002)(4326007); DIR:OUT; SFP:1101; SCL:1; SRVR:AMSPR07MB231; H:email.bskyb.com; FPR:; SPF:Pass; PTR:b0fff4df.bb.sky.com; MX:1; A:0; LANG:en; 
X-Microsoft-Exchange-Diagnostics: 1; DB3FFO11FD036; 1:hnkSCskWBy8EcWnfFUXLezSmOUSzZkTLxhdaLqgbRnzUg/eVy7L/pYXcep4ixKFny1xOOz2uNiM4KaXu+ZBNvebDaAf18rbb4VQWDQwo3OXHlVuwL2Wu59Mrb2wVolDEWjHNspOU029deB0W2E1Hti7TZ7XAPjxiHkbe2pp7zwxFVGxOJC5J8UeLYmRyyLs82xcXImU9BhtMhuMTXgAmdeCpNodG4ssg9gyqxTzPTO7Mg3L8FQ1IcH2KVXsmmbfEdwxRUvU2wR6C7NkZkfWEDs0ydylqQil09Z28Yu4d7md+n5IZvjAjzWPSBZavy46PiQO9G1AWUusGzKSM6L1yTOTeDPebqn9wCKfJR/Oyb1jYahytnKBjg6015eK2oJqID+sogxSbZekYR0EPxyTr9uBsyHEiP7h0N39yQqCY1LQlmRkqC4WgQwyPeopVpHheDbt0Btua5gJOAw/N6ZEJDZ/5yPkCt4frLmLaUNgo65wfdWgmUICLz8g1cG81EfGw1VuBob97vuXk9Wxvzs3pb/5SLeuZyHrdrDqftaBdSXoiW5AaKZa1Sf5jQG/zZKIS
X-MS-Office365-Filtering-Correlation-Id: b6270045-ec1a-4998-398e-08d40709da94
X-Microsoft-Exchange-Diagnostics: 1; AMSPR07MB231; 2:6sLi8CpnEIj/GnezfLgN7yLRRgst31cBMqimc1i+TfHioFl5M7Vd2c5jdA3xjMLHcxTqnkthFQ52oUTuu8vvmJJRiOL9GYNSmquiEzycP6lxkK1lINpxYlKaJwSiXoeki/Z8LDEyXrUq+Z68jtzfIgnfuSFPVWzbKr3e0PdyLqh0oZFlJIzrRVV9MK+jsf9sR6/Rp90cW1CYn8TGegnBvQ==; 3:vQEdPJKqa449WO4NZxLVBXyKv4I8ocNWplxCskW3D3IOPjGFfGpjrKwDHXHvH+3wOjfzch9utloqhsNa+ZwY5ictNOyuJ7//Zf3qJGtDqXtu3CUCAmQ8hdjx3POr/CklnIof4I6spLKjtsEUHNKvHBYSH38cu+YYoM/2YpAkTeq30H8gS5fEEanHwp01yKUQrXWfwm4UTDTf/3ZHMu3eL7Xg5IL4IAhat0GgE01/J+tzdW0XYeZvduEKCmAwL90IhR4XSHUB9mLya+rp2ySc7mBwj2aAW/NkklIWzffKaJE=
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501002); SRVR:AMSPR07MB231; 
X-Microsoft-Exchange-Diagnostics: 1; AMSPR07MB231; 25:im+6bCNejQ4AUseW2/bGFpyF7g8gNfya9wJT8qGl0WZfOvW3i2YzernTm4Mi/GDsMQdIRZPCwhUZy2AI0uty60Hz2NiukOaDMupl4GbZSc0SK98DouqFbaWOSrwQmnv8Odir8HshTlHeSnNbpdWeDEAt7qDdntiO/NwDE5J14JXivhuzTU58q6TPTM2fbpnpB8qst38cDOK+UMXLV4ieeK+zXrhBD6eTL3QRNLWAEKKqmWToUqvVvInk7EaCVNIYdp1SmDKeD+QA9LeA8wwlmhhJzw+H+ZDigPqoyoPkUfjanyrr4tWdDCf0JNz0H86XGN4K5bGTDWN0ee4VNIBDtyUGgf9dk5PtvueS4y9YoMO7BjvmZirffSIKBDMf+5lBrnjqJjKX1Zaz+oTIpfETGjs+rBLa4T0eG0VpgViwtBCC8OGTOGjRTC3QxIDtaZRq; 31:TMsz3Qx0Zx+8VA1t51MGFYMSVLLmf3NejXIf7j5Bu9wY9jFIcZZs5DBwcMpKDNpfgVH+6uep7aAyhVEIdGdzFxjg11/37IsBHdFzDOLi5YP3feb/Zk8TfbNaL8qTB+hSyuB8hSWzqgTWKIzS2sgFZkvS+CPvBR7sdOogRfyCFbGsYK9JybN2IIE6sLtvA4r00d1XdzfxggXlTMbxzA39OVdQn1PIU9lEf6rTu+y7aMGGZgLQFnhS295RpsitrthLkwF/8ii2ZuKXTNs5dsmzAg==
X-Microsoft-Exchange-Diagnostics: 1; AMSPR07MB231; 20:TFQjcgQumHXgEANVADbHCvxd/nYzpx/FYtY4NBm3IqerRaXN5vkcDEBgxYnJBWkUwIi84PjIZ9M+bBl2Ld7ELQEepX1wV6wWR9BNV8hqgAfv4q53e0StKxJEG1IGlXQTU5AgTMrC7we7nmBmooblZjzbc6X9g1t9aWxogEN/Ufi3/6v8NRmFVPhXGxba6g39Ey6bZfC8qQBwIvdgMkU9eKpeShQ1Lsfj8BeVx0fQY8CrMCHfdSHd6AFoxkDhyrY4gqsw9mKE5htPtFaco9S6zQZG8Tj8sxZ9SH6U89TDDIeqI0tismPmINGtJeSSbbCd1qzbb5TKJR2JVQAMgdEegATHCo1bw/83y7324IYmsZxHH2Bu/iOo57Lmg2Wj16m5jJKsWqTEM7GJ6YnR8swBBUqDXl2+4MD3y/WD/W6qYpLzkb13zTzuZ5D/AfBnjk2aAs2t2eyLOyTJi8R9fK+4wLmm35InQN6cVqvhjCmZC0sXQv+JhoGD3rDlkjaP3osg
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(13020025)(8121501046)(13012025)(10201501046)(3002001)(6055026); SRVR:AMSPR07MB231; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB231; 
X-Microsoft-Exchange-Diagnostics: 1; AMSPR07MB231; 4:3oQvhd7Z1RsCExIVM2QWibc9W6z+UWOVMWAigRoPSsPHAOq4EriHaq89quN9f4i4P70fdmw8rSqMMh92wLKxlU6ifriRUcy+zxh8Ej+uFQULEIvNW0qi3esCZvv4vOk+sKuVUSzDcuCpBnAyBGIxMOPDaHMcsmcKpYZWzTLVoCMJi1Izju9c0CSDZIO/FwsNM3jqlOMiq2SA+oil2hkFONAai7f6H0znkPeyEcLQHI4X+3gtOK5DeELQpEbaU01LS9dj5XARnDUXA/KAOcmy69fjdGH6pg3euTc8nat3PuhuibA4nVbaqKYjqgGJ6cwEpvNVQy3geuztW9UUoowStulJ178jg9T9+shBM0QBxlwAXuyiHKb0E1qtqfcUxqfh3epUyNda9sx9NwfvGeXJsVGcDyrDFupzemJHHA1pY+pODqSKH1KBtiVkPi59oG4oo7NLaFDuOAqLUKVEoYtrDg==
X-Forefront-PRVS: 0119DC3B5E
X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTVNQUjA3TUIyMzE7MjM6ZzBBUnpsaEFMUktUSk1mbEE2bjFaakF3V1hN?= =?utf-8?B?Vm14eFRmQVJtU094T1Q5NFhrbU5EWVpUNEVScTdXbmZSYlo2dnQxMkVuMzh2?= =?utf-8?B?RlQ4b2Y0S1BZQloxR3ZtMHFDR1RDRXFMenRnUll4SndyWkNhUmpXdEZTMmlU?= =?utf-8?B?MW53YVhRN1dHa1NraDRZVjJoL1NEM24xZWJFV2RGWWZuWWY2alFBODZKUFR0?= =?utf-8?B?YUtSRDdBWm9Qbk9RL0hmQ3VrRnB2QVJMWmZXYnQvbFlNQXIyT1lwMnNTUEZK?= =?utf-8?B?aVM2N1k3V2dIRHBXZ3VIS0FGMWN0Z0cwYS96dkRPVzRsYStiNjlvL3VzNnU3?= =?utf-8?B?clZNL0J1ZjNvV29BNitDLytHR2c0WHB0MGZHcGVtL3YrdmI0ek9sazVBQlI5?= =?utf-8?B?QnNrd0V0bVhJZlFYUzRLY1JlRHhUVVFhZ1A0L0x0czBoaVNsQUQzdWZJNjd5?= =?utf-8?B?aEhYV3BhN05MSzFFbFRQc2M4a2hVZ2JrSUoxSmg5Sy9wb3lnTjI2eTJlK3U5?= =?utf-8?B?ZjJyVGRHT3Uza0hsWkZmejl3c0prQU9VRkhOUnRWeU9INGgvd2dVNHRIcjU2?= =?utf-8?B?MXRtWHRjSVNUNmgxOTV2WjBRalJaclZrKytUODBhdlJ5Wms1LzVuejRzS3gr?= =?utf-8?B?TXFsZFdSTXpVNno0WEVZR0ljbEZxdWVFVDRpaG9PMG9vMEQ5MGUvNldOZGps?= =?utf-8?B?UmZCdFM2TUgvQTNwRTRvdUtBbWJ2amZvQzdPc28xaG5WdFZOSUZOK2tWdGJj?= =?utf-8?B?eXJENjFJM1pQMERhRzFUSjdoSlMrREZvdytJQXk5NnJLaE10TVkxaGE3Y01t?= =?utf-8?B?RHh2cERYT2pLRHNFcDBoQnZNdE1DTUFjSDk4SmFGZncwZU10TDVuYTRndkh4?= =?utf-8?B?L05IdzZrOXZmUVdpeGwrOXhDWmNqSFc2VEVuVzFEMzdCb2ZOTzc2ZDN4Uk9a?= =?utf-8?B?SkdTY1VxV3JtK1NsZW1mMUpZaFlIM3hKZ1c3dGY5WGNVRTZYN0ppWk1HU1hU?= =?utf-8?B?b29ZbHRSdjc0Vi9DcW5PU0lBUWxZMEhOSjQrR0QrNDFHdlVNZ0RXYzQ4QmpC?= =?utf-8?B?eGEzQktHUjFZV1BrdGhJU3RHV1BDbGJJZENPQURRT01oTGs2aytxTzI2V29u?= =?utf-8?B?TGNOcFRmOGllbDRodGdScVpCL3I1dTFYTWVxcS9mNEdhZFBEcjlQK2dXOFhP?= =?utf-8?B?bWNpa084eU5DZ2lMeGtzdi9XWUF2ZFdFWnJxMUw2SlZaLzFyWG41VU43OXQy?= =?utf-8?B?YS9xTHQyUS9vZkRRZ2JNV1RqanZvVWVqSU5Wd0E3eEhyL1FKTTAwc0VhZ0w2?= =?utf-8?B?K2dkaUIyakU5a2VlMWpBbEhuc2F5QWc4bEF6cFduQk5HTXprZkJsTVgzYURD?= =?utf-8?B?OVhUWU8xSGZLWXpjYWNWYlJJRDJJVm9tRFIrYTdRZDJxV3ViYkZ3UTBVV3ZI?= =?utf-8?B?T0E0MkRiblh6SW9jWVFCMm1aRnNzUlJIMzYrVFl2SHJXWmEvRjNjaVhFZmhi?= =?utf-8?Q?ph6nwNjtM+ekynE4VjUR2isVfUVAa5z3rJfN+0Ff2D0/2?=
X-Microsoft-Exchange-Diagnostics: 1; AMSPR07MB231; 6:FNHQkB/cwzXyiapCY5ljDFIVyFiXewkCR1kGdmWs5NIoO1HSQc+fUL9KG00M7uqm80tJp/VjEc8Ez4Zw/iVVAk1uHXVuYQPoVEhZzAgVV8r/sEzPXI6ZPVrEfh3mPDR7osSm+3AEy1xn5Fr0wcwEiZgEXGmtJ9THCMIziawVUtmT93Sqgl/FsGSX8YC0n7B+414XK8I6KbMmgZ/2b5Da4LKL8sr9zJrE8S0/+fq4pkskqLmnmfr/I5FRWnBi1ZmR/jtJWfK/TvBf3BljwU1S7iO/2fANe+CMEF3qDHNGbdA/WgDo9D2v/4FN/W8I2moXwukVQikmRxmqR9b1ESNCowdgfZRzoCXA+xj4IhKjmL4=; 5:EQ/4dP7rzsakRApj89NzHUQbAGM6h5F2Vr9hRTXmEKU0rntWJYnEyOgCGXrzBUHSBCjwkO/+iUbgv6m2D/gS12+Ytocl3PiqD+EERaCj+3Es2qrQLO7i44g4pT+Djfbzu9z/mPzwlWu5pb9V/tRjGw==; 24:MRR9mq32JcPhGTyYhaSaMkla7j2Q3NIVFwA0AGx7E0XG1+ekIXPQd7ceGUwP1Ds+UTqDWo8n4ofVbj1Qn4Z6/n1izuK5PoDgHz3JnQySwp0=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; AMSPR07MB231; 7:UwX06vs6fNzV6i+dVrn7YFa4REdHzulPQpgNFYGIZd8O8b2zmCk8EPZD6XB4Fm6FHu150xJp6GZU8U+HtH6HYznShKs82s8seclCfizkM+cuIAYrT6fFoAn/PmGARvQx1TmGaDcod5L20neSJdq5zwkNeDGx8WVOLL6Stwf1rUWuZyEJYCeWJykTDotzOGPSZlsgEyTn72NZ7iV/nt9xFnYw+KabwuyLS9gv5VQpg6sWXqWRA7UQY6EQy8bYHTjupjdM8TpPyND3F10mFp745YfTyWo3V2hrQQCdcf9oMifISZetxQLGvsxxidN6pH0ICbMTRTHH6zshJ8MjdeS1pMxrcMuD1jhihJjD5I0Fc04=
X-OriginatorOrg: sky.uk
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Nov 2016 12:30:26.6833 (UTC)
X-MS-Exchange-CrossTenant-Id: 4f86cebc-57e2-40a0-86cc-01d73be93ba0
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f86cebc-57e2-40a0-86cc-01d73be93ba0; Ip=[176.255.244.223];  Helo=[email.bskyb.com]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB231
Archived-At: 
Cc: heasley , idr wg 
Subject: Re: [Idr] Vendor Defaults (was Re: Review of draft-ietf-large-community-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: Mon, 07 Nov 2016 12:30:34 -0000

SGkgUm9iZXJ0LA0KDQo+TXkgZXhhbXBsZSB3YXMgdmVyeSBjbGVhciBhbmQgSSBwcm92aWRlZCBl
eGFtcGxlIG9mIEFTX1BBVEggcHJlcGVuZC4NCj5UaGUgcG9pbnQgd2hpY2ggeW91IGFyZSBtaXNz
aW5nIGlzIHRoYXQgaWYgeW91IGV4ZWN1dGUgY29tbXVuaXR5IHlvdSBzaG91bGQgY2xlYW4gdXAg
YW5kIGRlbGV0ZSBpdC4NCj5CbGluZCBkZWZhdWx0IG9uIG9yIG9mZiBpcyBub3QgdGhlIHdheSB0
byBzdG9wIHByb3BhZ2F0aW9uIG9mIHNlbGVjdGVkIGNvbW11bml0aWVzLg0KPkFuZCBpZiBzb21l
b25lIGlzIGluc2VydGluZyA1NTM5OiogaXQgc2VlbXMgb2J2aW91cyB0aGF0IHRoZSBpbnRlbnRp
b24gaXMgdGhhdCBzdWNoIGNvbW11bml0eSBzaG91bGQgZ2V0IHRvIDU1MzkuDQoNCkkgd291bGQg
c3VnZ2VzdCB0aGF0ICJjbGVhbiB1cCBhbmQgZGVsZXRlIiBpcyBub3QgcmVwcmVzZW50YXRpdmUg
b2YgYWxsIGN1cnJlbnQgdXNhZ2UgdGhhdCBJIGtub3cgb2YuDQpUaGUgY29tbXVuaXR5IGlzIG9m
dGVuIGxlZnQgaW4gcGxhY2UgdG8gc2hvdyB3aHkgYSBjaGFuZ2UgaW4gYmVoYXZpb3VyIHdhcyB0
cmlnZ2VyZWQgZS5nLiByYWlzaW5nIGxvY2FsIHByZWZlcmVuY2UuDQpUaGlzIGFpZHMgdHJvdWJs
ZXNob290aW5nIHdpdGhpbiBJQkdQIGFuZCBmb3IgZG93bnN0cmVhbSBBU05zLg0KDQpJYW4NCg0K
SW5mb3JtYXRpb24gaW4gdGhpcyBlbWFpbCBpbmNsdWRpbmcgYW55IGF0dGFjaG1lbnRzIG1heSBi
ZSBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIGV4Y2x1c2l2ZWx5IGZv
ciB0aGUgYWRkcmVzc2VlLiBUaGUgdmlld3MgZXhwcmVzc2VkIG1heSBub3QgYmUgb2ZmaWNpYWwg
cG9saWN5LCBidXQgdGhlIHBlcnNvbmFsIHZpZXdzIG9mIHRoZSBvcmlnaW5hdG9yLiBJZiB5b3Ug
aGF2ZSByZWNlaXZlZCBpdCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGJ5IHJl
dHVybiBlLW1haWwgYW5kIGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtLiBZb3Ugc2hvdWxkIG5v
dCByZXByb2R1Y2UsIGRpc3RyaWJ1dGUsIHN0b3JlLCByZXRyYW5zbWl0LCB1c2Ugb3IgZGlzY2xv
c2UgaXRzIGNvbnRlbnRzIHRvIGFueW9uZS4gUGxlYXNlIG5vdGUgd2UgcmVzZXJ2ZSB0aGUgcmln
aHQgdG8gbW9uaXRvciBhbGwgZS1tYWlsIGNvbW11bmljYXRpb24gdGhyb3VnaCBvdXIgaW50ZXJu
YWwgYW5kIGV4dGVybmFsIG5ldHdvcmtzLiBTS1kgYW5kIHRoZSBTS1kgbWFya3MgYXJlIHRyYWRl
bWFya3Mgb2YgU2t5IHBsYyBhbmQgU2t5IEludGVybmF0aW9uYWwgQUcgYW5kIGFyZSB1c2VkIHVu
ZGVyIGxpY2VuY2UuDQoNClNreSBVSyBMaW1pdGVkIChSZWdpc3RyYXRpb24gTm8uIDI5MDY5OTEp
LCBTa3ktSW4tSG9tZSBTZXJ2aWNlIExpbWl0ZWQgKFJlZ2lzdHJhdGlvbiBOby4gMjA2NzA3NSkg
YW5kIFNreSBTdWJzY3JpYmVycyBTZXJ2aWNlcyBMaW1pdGVkIChSZWdpc3RyYXRpb24gTm8uIDIz
NDAxNTApIGFyZSBkaXJlY3Qgb3IgaW5kaXJlY3Qgc3Vic2lkaWFyaWVzIG9mIFNreSBwbGMgKFJl
Z2lzdHJhdGlvbiBOby4gMjI0NzczNSkuIEFsbCBvZiB0aGUgY29tcGFuaWVzIG1lbnRpb25lZCBp
biB0aGlzIHBhcmFncmFwaCBhcmUgaW5jb3Jwb3JhdGVkIGluIEVuZ2xhbmQgYW5kIFdhbGVzIGFu
ZCBzaGFyZSB0aGUgc2FtZSByZWdpc3RlcmVkIG9mZmljZSBhdCBHcmFudCBXYXksIElzbGV3b3J0
aCwgTWlkZGxlc2V4IFRXNyA1UUQuDQo=


From nobody Mon Nov  7 05:05:19 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85C78129560 for ; Mon,  7 Nov 2016 05:05:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.097
X-Spam-Level: 
X-Spam-Status: No, score=-4.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497] 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 UI7iPjijH_tw for ; Mon,  7 Nov 2016 05:05:16 -0800 (PST)
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 CE0AC129442 for ; Mon,  7 Nov 2016 05:05:15 -0800 (PST)
X-Original-To: idr@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 96BDB60651 for ; Mon,  7 Nov 2016 14:05:13 +0100 (CET)
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 46A45602AF; Mon,  7 Nov 2016 14:05:13 +0100 (CET)
Received: by moebius4.space.net (Postfix, from userid 1007) id 374AE45187; Mon,  7 Nov 2016 14:05:13 +0100 (CET)
Date: Mon, 7 Nov 2016 14:05:13 +0100
From: Gert Doering 
To: "Dickinson, Ian" 
Message-ID: <20161107130513.GV79185@Space.Net>
References:  <86860386-9C2B-4BD5-B457-2A6DA5446CF3@cisco.com> <17E646EF-4633-423B-9AC4-B53D49C90632@gmail.com>  <20161107121251.GT79185@Space.Net>  <9B3BFE0A18160E40BAF1950414D10FAE61714CB7@WPMBX010.bskyb.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="f6DRPUp0q/j2osqN"
Content-Disposition: inline
In-Reply-To: <9B3BFE0A18160E40BAF1950414D10FAE61714CB7@WPMBX010.bskyb.com>
X-NCC-RegID: de.space
User-Agent: Mutt/1.6.1 (2016-04-27)
Archived-At: 
Cc: heasley , idr wg , Robert Raszuk 
Subject: Re: [Idr] Vendor Defaults (was Re: Review of draft-ietf-large-community-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: Mon, 07 Nov 2016 13:05:17 -0000

--f6DRPUp0q/j2osqN
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,

On Mon, Nov 07, 2016 at 12:30:25PM +0000, Dickinson, Ian wrote:
> I would suggest that "clean up and delete" is not representative of all c=
urrent usage that I know of.
> The community is often left in place to show why a change in behaviour wa=
s triggered e.g. raising local preference.
> This aids troubleshooting within IBGP and for downstream ASNs.

What Ian says.

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

--f6DRPUp0q/j2osqN
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJYIHwGAAoJEN9WwGXkzn/FwNoP/3MlhEN/e6Pn58Gvr2wWaeNS
3nO+ss/VZntwWM3uidpOCmvRez2m9CBAalMSh+lds3meWxS5Xr+gKdgVFdYU4Fno
PvUReF405jNJLzjvN1ZLzWTNuSBSTgnbqQZNMASnBy0z6iC8yuBLLuQn/Ir85aZE
1pKHnrjzte1jpkcAWFMQ1GmcB2LsrD+Cvg++5Z51oIuMJxk04pBavIco11rc3VBN
kNtQo02ja2obEXF8j7DLvTvVVphujghvkLuQEQBh6VMOGfRILUeWUZzgWsj4BUSK
nEKhk536Oio8RtgM8y2e2LAWPQ1yMqD72qEyjDykbR7lyaxOPaUnrCGJZ10/8aYt
bh6VwM7xDDyo5FQamCZGzUrfihig3Rf3YNzhrao4UFrR3UZwUcp5NZha0RhU9zVZ
B6aW4OQJrLtoyqKMFQY5eu/3dm08VGyzkoSxh/nY8QVlUKOnd5yGszDlwEgPOs+X
9tnTs2WCnMp/1L44Ak3UPR5Kx1RB9VBSFf6vGcdBz4u7lgR52Dm2J98zss5dLcgj
78gAlP/Z47aIQQJiN668vTvNCeuUb4RrfKQVHf4C9Pi32dUfyoYk0sLfuYFNY/5p
NXw+u5JI0xbA/I/cRJCtyZORhe+b883EwFsNyH7rwomm9zx+kroLvndizJvGQPD/
zWQTftLSDoKEYeni6DLr
=jUiI
-----END PGP SIGNATURE-----

--f6DRPUp0q/j2osqN--


From nobody Mon Nov  7 06:55:07 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AD9D129860 for ; Mon,  7 Nov 2016 06:55:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.398
X-Spam-Level: 
X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, 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 jRaGt9LKZgYi for ; Mon,  7 Nov 2016 06:55:04 -0800 (PST)
Received: from mailhosting.spakka.net (mailhosting.spakka.net [IPv6:2a02:af8:cafe:f00d::25]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92A47129841 for ; Mon,  7 Nov 2016 06:55:04 -0800 (PST)
Received: from [193.0.20.124] by mailhosting.spakka.net with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1c3lKA-00075Q-FE; Mon, 07 Nov 2016 14:55:02 +0000
To: Jeffrey Haas 
References: <20161031205515.GA25507@pfrc.org> <76CD132C3ADEF848BD84D028D243C927935045D8@NKGEML515-MBX.china.huawei.com> <20161102135352.GA11431@pfrc.org>
From: Colin Petrie 
Message-ID: 
Date: Mon, 7 Nov 2016 15:55:01 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <20161102135352.GA11431@pfrc.org>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-SMTP-Authenticated-User: colin@spakka.net
Archived-At: 
Cc: "idr@ietf.org" 
Subject: Re: [Idr] [internet-drafts@ietf.org: I-D Action: draft-haas-idr-extended-experimental-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: Mon, 07 Nov 2016 14:55:06 -0000

Hi Jeff, and thanks for this draft.

On 02/11/16 14:53, Jeffrey Haas wrote:
> Currently this draft is tailored toward experiments and development, not
> long term deployment of features.  While the conversation is starting to
> move toward using this as a generic vendor-specific PA replacement, that's
> not the intent of the draft currently.

It may not be the intent, but some people have asked about that, and
your draft is a fairly pragmatic approach to giving each vendor a huge
playground space. If it prevents the squatting, I'm all for it :)

Anyway, fully support further discussion on this.

Cheers,
Colin






From nobody Mon Nov  7 07:18:51 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6EBF1299A3 for ; Mon,  7 Nov 2016 07:18:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.399
X-Spam-Level: 
X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, 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 KKLsqbDCyzY2 for ; Mon,  7 Nov 2016 07:18:47 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 082391299A2 for ; Mon,  7 Nov 2016 07:18:47 -0800 (PST)
Received: by slice.pfrc.org (Postfix, from userid 1001) id D69EF1E337; Mon,  7 Nov 2016 10:21:27 -0500 (EST)
Date: Mon, 7 Nov 2016 10:21:27 -0500
From: Jeffrey Haas 
To: Brian Dickson 
Message-ID: <20161107152127.GA25256@pfrc.org>
References:  <86860386-9C2B-4BD5-B457-2A6DA5446CF3@cisco.com> <17E646EF-4633-423B-9AC4-B53D49C90632@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <17E646EF-4633-423B-9AC4-B53D49C90632@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: 
Cc: heasley , "idr@ietf.org" , Robert Raszuk 
Subject: Re: [Idr] Vendor Defaults (was Re: Review of draft-ietf-large-community-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: Mon, 07 Nov 2016 15:18:48 -0000

On Sun, Nov 06, 2016 at 02:56:24PM -0800, Brian Dickson wrote:
> The following is my opinion, but I am confident that most operators concur with it:
> 
> Large is not a "new" attribute per se.
> Large is providing parity for RFC1997, for use with 32-bit ASNs.
> 
> For that reason alone, the only sane implementation approach is "off by default", so as to be consistent with the default for 1997.

If that's what your vendor does with its 1997 implementation, being
consistent is reasonable.

That's not what our implementation will do, for the same reason.

-- Jeff


From nobody Mon Nov  7 07:23:38 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCE8A129A62 for ; Mon,  7 Nov 2016 07:23:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.399
X-Spam-Level: 
X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, 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 d71kwdikFwUu for ; Mon,  7 Nov 2016 07:23:35 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id A6995129A44 for ; Mon,  7 Nov 2016 07:23:35 -0800 (PST)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 91C1F1E337; Mon,  7 Nov 2016 10:26:16 -0500 (EST)
Date: Mon, 7 Nov 2016 10:26:16 -0500
From: Jeffrey Haas 
To: Marco Marzetti 
Message-ID: <20161107152616.GB25256@pfrc.org>
References: <20161031205515.GA25507@pfrc.org> <5818E126.2090202@foobar.org> <20161101185759.GA23458@pfrc.org> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: 
Cc: idr@ietf.org
Subject: Re: [Idr] [internet-drafts@ietf.org: I-D Action: draft-haas-idr-extended-experimental-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: Mon, 07 Nov 2016 15:23:37 -0000

Marco,

On Sun, Nov 06, 2016 at 08:23:36PM +0100, Marco Marzetti wrote:
> On Tue, Nov 1, 2016 at 7:58 PM, Jeffrey Haas  wrote:
> 
> >
> > A feature such as this one, perhaps extended with a per-attribute form of
> > draft-ietf-idr-bgp-attribute-announcement along with enough information to
> > figure out when filtering wasn't done could provide some safety.
> >
> > The related changes to this proposal would be to simply add the 4-octets of
> > the attribute announcement scoping and potentially the attaching AS.
> > However, given even such vendor features are likely to need to work in an
> > inter-as fashion, generating scopes of containment become tricky.
> >
> >
> I have always wondered if we should add and N bit to
> draft-ietf-idr-bgp-attribute-announcement to limit the advertisements to
> neighbor ASes only.

Such a thing was discussed among the authors of the attribute-announcement
draft.  What this would mean is such a bit would need to be set and then
automatically reset into the M-bits (C+A) at the next boundary.

The general challenges about what to do when intervening routers did not
understand the header remain.

-- Jeff


From nobody Mon Nov  7 07:31:44 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A31D3129A62 for ; Mon,  7 Nov 2016 07:31:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.717
X-Spam-Level: 
X-Spam-Status: No, score=-5.717 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=-1.497, 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 M2I4SvyAp1sy for ; Mon,  7 Nov 2016 07:31:39 -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 8AEA71299C9 for ; Mon,  7 Nov 2016 07:31:38 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CZW31436; Mon, 07 Nov 2016 15:31:33 +0000 (GMT)
Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 7 Nov 2016 15:31:32 +0000
Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Mon, 7 Nov 2016 23:31:27 +0800
From: Zhuangshunwan 
To: "Jakob Heitz (jheitz)" 
Thread-Topic: [Idr] Review of draft-ietf-large-community-06.txt
Thread-Index: AQHSN1BcX5oGwTVUrUSuyFaP3/PvrqDK+MqAgAKstyA=
Date: Mon, 7 Nov 2016 15:31:26 +0000
Message-ID: <19AB2A007F56DB4E8257F949A2FB9858C87B1DCE@NKGEML515-MBX.china.huawei.com>
References: <6c5d83aa1d6a4a04b651b8f14f4b445b@XCH-ALN-014.cisco.com> <40D942F5-0710-46D1-BF09-76C827377479@cisco.com> <95F42982-7DCF-46A9-A26C-71EF70DB3C59@apnic.net> <20161104195346.GK961@Vurt.local> <20161104201631.GA35942@Vurt.lan> <8a293ce4fc134657aa98134b5017d92e@XCH-ALN-014.cisco.com> <20161104221030.GD37681@Vurt.lan> <0919e676e12d49d1a2ba30f4acc3b273@XCH-ALN-014.cisco.com> <20161104230536.GJ37681@Vurt.lan> <19AB2A007F56DB4E8257F949A2FB9858C87AFC6E@NKGEML515-MBX.china.huawei.com> <20161105103526.GM952@Vurt.local> <804168D3-12A6-478A-A390-19A02791A0D0@cisco.com>
In-Reply-To: <804168D3-12A6-478A-A390-19A02791A0D0@cisco.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.86.254]
Content-Type: multipart/alternative; boundary="_000_19AB2A007F56DB4E8257F949A2FB9858C87B1DCENKGEML515MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.58209E56.00E3, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: d8daaf6d9f8b6e413243f5c8ab079b5c
Archived-At: 
Cc: "idr@ietf.org" 
Subject: Re: [Idr] Review of draft-ietf-large-community-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: Mon, 07 Nov 2016 15:31:41 -0000

--_000_19AB2A007F56DB4E8257F949A2FB9858C87B1DCENKGEML515MBXchi_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

DQoNCuWPkeS7tuS6ujogSmFrb2IgSGVpdHogKGpoZWl0eikgW21haWx0bzpqaGVpdHpAY2lzY28u
Y29tXQ0K5Y+R6YCB5pe26Ze0OiAyMDE25bm0MTHmnIg25pelIDE0OjI3DQrmlLbku7bkuro6IFpo
dWFuZ3NodW53YW4NCuaKhOmAgTogaWRyQGlldGYub3JnOyBKb2IgU25pamRlcnMNCuS4u+mimDog
UmU6IFtJZHJdIFJldmlldyBvZiBkcmFmdC1pZXRmLWxhcmdlLWNvbW11bml0eS0wNi50eHQNCg0K
U2h1bndhbiwNCg0KT24gTm92IDUsIDIwMTYsIGF0IDM6MzUgQU0sIEpvYiBTbmlqZGVycyA8am9i
QGluc3RpdHV1dC5uZXQ8bWFpbHRvOmpvYkBpbnN0aXR1dXQubmV0Pj4gd3JvdGU6DQoNCk9uIFNh
dCwgTm92IDA1LCAyMDE2IGF0IDEwOjI4OjU4QU0gKzAwMDAsIFpodWFuZ3NodW53YW4gd3JvdGU6
DQoNCg0KU29tZSBjdXN0b21lcnMgZnJvbSBJREMvT1RUIGNvbXBsYWluIHRoYXQgSVNQcyBjYW4g
bm90IHRyYW5zbWl0IHRoZWlyDQpjb21tdW5pdHkgYXR0cmlidXRlcywgYmVjYXVzZSBJU1BzIGRv
IG5vdCB0cmFuc21pdCBjb21tdW5pdHkNCmF0dHJpYnV0ZXMgaW4gbW9zdCBjYXNlcy4NCg0KSSBm
aW5kIGl0IGhhcmQgdG8gbWFrZSBvciBhY2NlcHQgcXVhbnRhdGl2ZSBzdGF0ZW1lbnRzIGluIHRo
aXMgY29udGV4dCwNCkkga25vdyBzb21lIElTUCB0aGF0IHNjcnViIGFsbCBjb21tdW5pdGllcywg
YW5kIEkga25vdyBzb21lIElTUHMgdGhhdA0KcGFzcyBvbiBhcyBtdWNoIGNvbW11bml0aWVzIGFz
IHBvc3NpYmxlLiBUaGUgbWFya2V0IHdpbGwgZGVjaWRlLg0KDQpBbm90aGVyIHJlYXNvbiBpcyB0
aGF0IHNvbWUgSVNQcyB1c2UgcHJpdmF0ZSBBU05zIHJhdGhlciB0aGFuIHRoZWlyIG93biBBU04g
aW4gdGhlIGZpcnN0IDE2IGJpdHMgb2YgdGhlIGNvbW11bml0eSwgYmVjYXVzZSB0aGVyZSBpcyBu
b3QgZW5vdWdoIGxlZnRvdmVyIGJpdHMgdG8gZXhwcmVzcyB0aGUgYWN0aW9uLiBUaGF0IG1ha2Vz
IGl0IGltcG9zc2libGUgZm9yIGFuIElTUCB0byB0cmFuc21pdCB0aGVtIHRvIGFub3RoZXIgSVNQ
LCBiZWNhdXNlIG9mIG5hbWUgc3BhY2UgY2xhc2hlcy4gVGhhdCBzaG91bGQgbm8gbG9uZ2VyIGJl
IGEgcHJvYmxlbSB3aXRoIGxhcmdlIGNvbW11bml0aWVzLg0KW1NodW53YW5dIFRoYW5rIHlvdSBm
b3IgeW91ciBleHBsYW5hdGlvbiENCg0KU2VlIGh0dHBzOi8vb25lc3RlcC5uZXQvY29tbXVuaXRp
ZXM8aHR0cHM6Ly9vbmVzdGVwLm5ldC9jb21tdW5pdGllcy8+LyBmb3IgZXhhbXBsZXMgb2YgY29t
bXVuaXRpZXMuIEJUVywgSSBkb24ndCByZWNvZ25pemUgYW55IENoaW5lc2UgSVNQcyBvbiB0aGF0
IHNpdGUuIENhbiB5b3Ugc2hhcmUgc29tZSBjb21tdW5pdHkgc3BlY2lmaWNhdGlvbnMgZm9yIGFu
eSBDaGluZXNlIElTUHMsIHBsZWFzZT8NCltTaHVud2FuXSBTb3JyeSwgSSBsb29rZWQgdGhyb3Vn
aCB0aGUgZW50aXJlIGxpc3QsIGJ1dCBubyBDaGluZXNlIElTUHMgd2VyZSBmb3VuZCBvbiB0aGlz
IGxpc3QgYXMgZmFyIGFzIEkga25vdy4NCg0K6LCi6LCiLA0KW1NodW53YW5dIFlvdXIgQ2hpbmVz
ZSBpcyB2ZXJ5IGdvb2QhDQoNClRoYW5rcywNClNodW53YW4NCg0KSmFrb2IuDQoNCg==

--_000_19AB2A007F56DB4E8257F949A2FB9858C87B1DCENKGEML515MBXchi_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm
b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0
O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg
MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ
cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K
cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K
CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5
OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0
eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp
dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN
Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWls
U3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi
Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQN
Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFn
ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5
MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp
b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1
bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt
LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp
ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl
bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0i
cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv
cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij7l
j5Hku7bkuro8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9
IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+IEpha29iIEhlaXR6IChqaGVpdHopIFtt
YWlsdG86amhlaXR6QGNpc2NvLmNvbV0NCjxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdCI+5Y+R6YCB5pe26Ze0PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9z
cGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiAyMDE2
PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij7lubQ8c3BhbiBsYW5nPSJFTi1V
UyI+MTE8L3NwYW4+5pyIPHNwYW4gbGFuZz0iRU4tVVMiPjY8L3NwYW4+5pelPHNwYW4gbGFuZz0i
RU4tVVMiPiAxNDoyNzxicj4NCjwvc3Bhbj48Yj7mlLbku7bkuro8c3BhbiBsYW5nPSJFTi1VUyI+
Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBaaHVhbmdzaHVud2FuPGJyPg0KPC9zcGFu
PjxiPuaKhOmAgTxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1V
UyI+IGlkckBpZXRmLm9yZzsgSm9iIFNuaWpkZXJzPGJyPg0KPC9zcGFuPjxiPuS4u+mimDxzcGFu
IGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IFJlOiBbSWRyXSBS
ZXZpZXcgb2YgZHJhZnQtaWV0Zi1sYXJnZS1jb21tdW5pdHktMDYudHh0PG86cD48L286cD48L3Nw
YW4+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5TaHVud2FuLDxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9
IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T24gTm92IDUsIDIwMTYsIGF0IDM6
MzUgQU0sIEpvYiBTbmlqZGVycyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpvYkBpbnN0aXR1dXQubmV0
Ij5qb2JAaW5zdGl0dXV0Lm5ldDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJt
YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6NS4wcHQ7bWFyZ2luLXJpZ2h0OjM2
LjBwdDttYXJnaW4tYm90dG9tOjBjbTttYXJnaW4tbGVmdDozNi4wcHQ7bWFyZ2luLWJvdHRvbTou
MDAwMXB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIj5PbiBTYXQsIE5vdiAwNSwgMjAxNiBhdCAxMDoy
ODo1OEFNICYjNDM7MDAwMCwgWmh1YW5nc2h1bndhbiB3cm90ZTo8YnI+DQo8YnI+DQo8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10
b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OjUuMHB0O21hcmdpbi1yaWdodDo3Mi4wcHQ7bWFyZ2luLWJv
dHRvbTo1LjBwdDttYXJnaW4tbGVmdDo3Mi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPlNvbWUg
Y3VzdG9tZXJzIGZyb20gSURDL09UVCBjb21wbGFpbiB0aGF0IElTUHMgY2FuIG5vdCB0cmFuc21p
dCB0aGVpcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3Rl
IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDo1LjBwdDttYXJnaW4tcmlnaHQ6
NzIuMHB0O21hcmdpbi1ib3R0b206NS4wcHQ7bWFyZ2luLWxlZnQ6NzIuMHB0Ij4NCjxzcGFuIGxh
bmc9IkVOLVVTIj5jb21tdW5pdHkgYXR0cmlidXRlcywgYmVjYXVzZSBJU1BzIGRvIG5vdCB0cmFu
c21pdCBjb21tdW5pdHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8Ymxv
Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6NS4wcHQ7bWFyZ2lu
LXJpZ2h0OjcyLjBwdDttYXJnaW4tYm90dG9tOjUuMHB0O21hcmdpbi1sZWZ0OjcyLjBwdCI+DQo8
c3BhbiBsYW5nPSJFTi1VUyI+YXR0cmlidXRlcyBpbiBtb3N0IGNhc2VzLjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6MGNtO21hcmdpbi1yaWdodDozNi4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw
dDttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCkkgZmluZCBp
dCBoYXJkIHRvIG1ha2Ugb3IgYWNjZXB0IHF1YW50YXRpdmUgc3RhdGVtZW50cyBpbiB0aGlzIGNv
bnRleHQsPGJyPg0KSSBrbm93IHNvbWUgSVNQIHRoYXQgc2NydWIgYWxsIGNvbW11bml0aWVzLCBh
bmQgSSBrbm93IHNvbWUgSVNQcyB0aGF0PGJyPg0KcGFzcyBvbiBhcyBtdWNoIGNvbW11bml0aWVz
IGFzIHBvc3NpYmxlLiBUaGUgbWFya2V0IHdpbGwgZGVjaWRlLjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5Bbm90aGVyIHJlYXNvbiBpcyB0
aGF0IHNvbWUgSVNQcyB1c2UgcHJpdmF0ZSBBU05zIHJhdGhlciB0aGFuIHRoZWlyIG93biBBU04g
aW4gdGhlIGZpcnN0IDE2IGJpdHMgb2YgdGhlIGNvbW11bml0eSwgYmVjYXVzZSB0aGVyZSBpcyBu
b3QgZW5vdWdoIGxlZnRvdmVyIGJpdHMgdG8gZXhwcmVzcyB0aGUgYWN0aW9uLiBUaGF0IG1ha2Vz
IGl0IGltcG9zc2libGUgZm9yIGFuIElTUCB0bw0KIHRyYW5zbWl0IHRoZW0gdG8gYW5vdGhlciBJ
U1AsIGJlY2F1c2Ugb2YgbmFtZSBzcGFjZSBjbGFzaGVzLiBUaGF0IHNob3VsZCBubyBsb25nZXIg
YmUgYSBwcm9ibGVtIHdpdGggbGFyZ2UgY29tbXVuaXRpZXMuDQo8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+W1NodW53YW5dIFRo
YW5rIHlvdSBmb3IgeW91ciBleHBsYW5hdGlvbiE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5T
ZWUmbmJzcDs8YSBocmVmPSJodHRwczovL29uZXN0ZXAubmV0L2NvbW11bml0aWVzLyI+aHR0cHM6
Ly9vbmVzdGVwLm5ldC9jb21tdW5pdGllczwvYT4vIGZvciBleGFtcGxlcyBvZiBjb21tdW5pdGll
cy4gQlRXLCBJIGRvbid0IHJlY29nbml6ZSBhbnkgQ2hpbmVzZSBJU1BzIG9uIHRoYXQgc2l0ZS4g
Q2FuIHlvdSBzaGFyZSBzb21lIGNvbW11bml0eSBzcGVjaWZpY2F0aW9ucyBmb3IgYW55DQogQ2hp
bmVzZSBJU1BzLCBwbGVhc2U/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5bU2h1bndhbl0g
U29ycnksIEkgbG9va2VkIHRocm91Z2ggdGhlIGVudGlyZSBsaXN0LCBidXQgbm8gQ2hpbmVzZSBJ
U1BzIHdlcmUgZm91bmQgb24gdGhpcyBsaXN0IGFzIGZhciBhcyBJIGtub3cuPG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPuiwouiwojxzcGFuIGxhbmc9IkVOLVVTIj4sPGJyPg0KW1NodW53YW5dIFlvdXIgQ2hpbmVz
ZSBpcyB2ZXJ5IGdvb2QhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGFua3MsPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlNodW53YW48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF
Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5KYWtvYi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO
LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_19AB2A007F56DB4E8257F949A2FB9858C87B1DCENKGEML515MBXchi_--


From nobody Mon Nov  7 08:14:37 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5603912946F for ; Mon,  7 Nov 2016 08:14:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.017
X-Spam-Level: 
X-Spam-Status: No, score=-16.017 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=-1.497, 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 x0KWwYikgWWL for ; Mon,  7 Nov 2016 08:14:35 -0800 (PST)
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 1739E1293EB for ; Mon,  7 Nov 2016 08:14:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1846; q=dns/txt; s=iport; t=1478535273; x=1479744873; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=KuqJNKmVGt4unu1fDBeIG8EP2wwALTvoj8glSoCi3NM=; b=YaMasqE+JDbF1JKo74RUxBR/DvlPHal7SQsTlyGiqDXcqduyyfx64y1a xIFxVLh0pGVaMKe6iDxzyE0sFBZUuxLw5kXigJmH34YnwWevngbuxa1+W 4rdLg271HMZO2n0f+3udTdRyW5llH+XNXHl9ZLaQZMLbYt70p1aLYFVcH w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DmAQBspyBY/49dJa1dGwEBAQMBAQEJA?= =?us-ascii?q?QEBgy4BAQEBAR9YfIQriQ2mOYUagggphXsCggk/FAECAQEBAQEBAWIohGIBAQR?= =?us-ascii?q?5EAIBCAQBOgcyFBECBA4FFIhEDrQMi0ABAQEBAQEBAQEBAQEBAQEBAQEBAQEch?= =?us-ascii?q?j6BfYJYh3iCLwWUR4VgAZBDkBCNKoQFAR43eoUqcgGHSQEBAQ?=
X-IronPort-AV: E=Sophos;i="5.31,606,1473120000";  d="scan'208,217";a="343494868"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Nov 2016 16:14:33 +0000
Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id uA7GEXxe021826 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 7 Nov 2016 16:14:33 GMT
Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 7 Nov 2016 10:14:32 -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; Mon, 7 Nov 2016 10:14:32 -0600
From: "Jakob Heitz (jheitz)" 
To: Robert Raszuk 
Thread-Topic: [Idr] Vendor Defaults (was Re: Review of draft-ietf-large-community-06.txt)
Thread-Index: AQHSN546iba0WaPSYk6woE67Sz8aq6DLBUg9gAHyDwCAAAWrgIAA2NyAgAABpQD//91M+g==
Date: Mon, 7 Nov 2016 16:14:32 +0000
Message-ID: 
References:  <86860386-9C2B-4BD5-B457-2A6DA5446CF3@cisco.com> <17E646EF-4633-423B-9AC4-B53D49C90632@gmail.com>  <20161107121251.GT79185@Space.Net>, 
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
Content-Type: multipart/alternative; boundary="_000_B245D36ADB4D402E87ED3DBF31699B2Bciscocom_"
MIME-Version: 1.0
Archived-At: 
Cc: heasley , idr wg 
Subject: Re: [Idr] Vendor Defaults (was Re: Review of draft-ietf-large-community-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: Mon, 07 Nov 2016 16:14:36 -0000

--_000_B245D36ADB4D402E87ED3DBF31699B2Bciscocom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

On Nov 7, 2016, at 4:19 AM, Robert Raszuk > wrote:

And if someone is inserting 5539:* it seems obvious that the intention is t=
hat such community should get to 5539.

Not always true.

5539:100 is used by 5539 to tell its neighbors that the route was learned i=
n Frankfurt/DECIX.
http://www.space.net/static/bgp_communities.html

Thanks,
Jakob.


--_000_B245D36ADB4D402E87ED3DBF31699B2Bciscocom_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable







On Nov 7, 2016, at 4:19 AM, Robert Raszuk <robert@raszuk.net> wrote:



And if someone is inserting 5539:* it seems obvious that the intention is t=
hat such community should get to 5539.



Not always true.







5539:100 is =
used by 5539 to tell its neighbors that the route was learned in Frankfurt/=
DECIX.





Thanks,



Jakob.











--_000_B245D36ADB4D402E87ED3DBF31699B2Bciscocom_--


From nobody Mon Nov  7 08:21:06 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E416712969C for ; Mon,  7 Nov 2016 08:21:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.097
X-Spam-Level: 
X-Spam-Status: No, score=-4.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497] 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 Q-_KKLzgPzsG for ; Mon,  7 Nov 2016 08:21:02 -0800 (PST)
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 8B9B612960B for ; Mon,  7 Nov 2016 08:21:01 -0800 (PST)
X-Original-To: idr@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 37877604E7 for ; Mon,  7 Nov 2016 17:21:00 +0100 (CET)
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 4BD82602A9; Mon,  7 Nov 2016 17:20:59 +0100 (CET)
Received: by moebius4.space.net (Postfix, from userid 1007) id 3BE1C45C27; Mon,  7 Nov 2016 17:20:59 +0100 (CET)
Date: Mon, 7 Nov 2016 17:20:59 +0100
From: Gert Doering 
To: "Jakob Heitz (jheitz)" 
Message-ID: <20161107162059.GE79185@Space.Net>
References:  <86860386-9C2B-4BD5-B457-2A6DA5446CF3@cisco.com> <17E646EF-4633-423B-9AC4-B53D49C90632@gmail.com>  <20161107121251.GT79185@Space.Net>  
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="uANtsCJ0la+JAbPL"
Content-Disposition: inline
In-Reply-To: 
X-NCC-RegID: de.space
User-Agent: Mutt/1.6.1 (2016-04-27)
Archived-At: 
Cc: heasley , idr wg , Robert Raszuk 
Subject: Re: [Idr] Vendor Defaults (was Re: Review of draft-ietf-large-community-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: Mon, 07 Nov 2016 16:21:05 -0000

--uANtsCJ0la+JAbPL
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,

On Mon, Nov 07, 2016 at 04:14:32PM +0000, Jakob Heitz (jheitz) wrote:
> 5539:100 is used by 5539 to tell its neighbors that the route was learned=
 in Frankfurt/DECIX.
> http://www.space.net/static/bgp_communities.html

Indeed, and sorry for the 5539:70 and 5539:130 example, these were=20
obviously incorrect - the list (and our configs) say it's 5539:3070,
5539:3100 and 5539:3130 to set local-pref in our network.

But this example prominently documents why operators think that the model
"5539 defines the namespace for 5539:*" is the only thing that makes sense
- there are communities set *by* 5539, to declare "information about a=20
prefix", and there are other community values sent *to* 5539 to cause some=
=20
sort of policy effect in our network, but both have to be declared by=20
5539 to be a valid reflection of our configured BGP policy.

2914:5539 would not have any meaning for us, even if it might tell 2914
"do not announce to 5539" or anything else - not our namespace.

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

--uANtsCJ0la+JAbPL
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJYIKnoAAoJEN9WwGXkzn/Fh9oP/jRWgltb03/4/orsOoRYKnmg
0E738CBHrClWu6E52tYq7FiZaNTyCwfM+xKv/OJN5wL2KEcOQGfmgKzvf4AQQzkH
o0rEH7tIt+y58zFaA00D72lO00w4QpLJSb0ZvmaqFTxix75WWQJhzkCXtGDZorPD
oTWJEgt4LGdaFVIas5JHsIgBGckynC6xX0I70fsaHgw+8PqDg+MCrbYD5FZc9Ddb
QMXOrlNxCW9AztjNd+uHxoKuRGOUm5uWqyVBTN8RcVlZP5FJrUh8iV3bRoJMt1lr
iv9vlqUG/BhLQ0wrTGuMQGQL0wv0PCtXIR3cpHCSmvvpnZIQZNEMWFO67NHrIzwY
hNP519XQ00Vqc3twnPK8piWKMYkG7YbIIXdlhmgTMQ5xnb4xpsJ3whKWIh/DWH7u
bI8CLhzEEjmDizpu0Ev7cFP1GkT4dZd/0e2hzpp6P4lUPbM1c9JEuDo3x+V5PCTh
J1juk00ccxSuPcBGgaj8/jkZ1PuBc3PNF17/JY5Q6AHlRngXAzIDmHZdgGQfuWvU
a1E0Kpz22Z7+peINBNGAxiOdawcyzUUTGeylgJ87/QaqkNymHHZbXoWjuYemAImr
RyK4UJtR9x0Ebsp6yB7eWqJSgXRdvI8GraFLRDvhKO15wh8Pah8HBmpS/rb1qHJb
sXfuTiTwlBpxEdB5brzH
=QdQc
-----END PGP SIGNATURE-----

--uANtsCJ0la+JAbPL--


From nobody Mon Nov  7 08:35:24 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9C30129863 for ; Mon,  7 Nov 2016 08:35:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level: 
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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 21k4B7DLSr6V for ; Mon,  7 Nov 2016 08:35:21 -0800 (PST)
Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c: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 1BD2712961E for ; Mon,  7 Nov 2016 08:35:21 -0800 (PST)
Received: by mail-wm0-x236.google.com with SMTP id t79so188157018wmt.0 for ; Mon, 07 Nov 2016 08:35:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=sl5SAs1sw7MF4lPM5gj1lilrhcMW7THhwIkHP84815s=; b=pVTSZb/JIqupdowUiOX3TVQ6CT3Wr4Nv+SCSrIs8SfQy11f4lJCVVByd36Ze2eXMDk 2E2lRaXQxb5tKnB4gei9FHArdEbM+vUvvWEfYISfmPhbFoXT57ONmyN7wCrp7p7ym4De HrliXMdUDdNKR2N1xGLzcaNT12ewi0G5YwBalvKwL+1f7sYJQm7Fv7Wny+pufibKoY/h fRUrh8L9TNqQUdTpeIN5z8oxrSvKrkhaPAql57LF/HZu2v3rvSOzz40nXL1jmOYq5dyY GT7H94+o5xv0VTWFaDvTQMaMZHnDVNRJHGKEIrZNxma3xQWOV4X4r7aan6QRyDYB1R5/ /HTg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=sl5SAs1sw7MF4lPM5gj1lilrhcMW7THhwIkHP84815s=; b=lPSmBwJ/SdZNk81e7ctXJwAK9vcL+QlN/2RnP4Z9bCjXQuPVUXX1quFcHZhgDW4Q6f XpazMJKHdkeMPe+6QQ7m6G1ZZrQ2uzaS+fyNNhYzLbyBTYFnhGa7epSBjWOItj81K9KK JcPzE9n6FgtjNajG7QkAohzTnrNPW3mKtWPypQ1CtY43nTG7MCL8SOXA11VCEBWzc6n+ UYfzeK6Go2HAP94V994N67iwEoL+uuq8HK/luZdeYP6AnDz/2jQSJopyiGxBV7LkG0b4 qiDa8VhdrWphGuD1NrbyN64Xn5cklzi/598UwH58a10/Akx4a0kIl3uVArQ4cDTBdcAA b5lg==
X-Gm-Message-State: ABUngvdtEDiUGJUIJckTxggGG+wvaXNyHZpAwThM54MSKI/SqpxBaYXp5qP8lKIInSP9q4yjMEnTDtuODmNR8Q==
X-Received: by 10.194.187.103 with SMTP id fr7mr5939072wjc.99.1478536519472; Mon, 07 Nov 2016 08:35:19 -0800 (PST)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.80.137.69 with HTTP; Mon, 7 Nov 2016 08:35:18 -0800 (PST)
In-Reply-To: 
References:  <86860386-9C2B-4BD5-B457-2A6DA5446CF3@cisco.com> <17E646EF-4633-423B-9AC4-B53D49C90632@gmail.com>  <20161107121251.GT79185@Space.Net>  
From: Robert Raszuk 
Date: Mon, 7 Nov 2016 17:35:18 +0100
X-Google-Sender-Auth: KWi1XJ6DeOiC_M1kjyzl27BVExQ
Message-ID: 
To: "Jakob Heitz (jheitz)" 
Content-Type: multipart/alternative; boundary=047d7bd6bc9c07dc1a0540b89c06
Archived-At: 
Cc: heasley , idr wg 
Subject: Re: [Idr] Vendor Defaults (was Re: Review of draft-ietf-large-community-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: Mon, 07 Nov 2016 16:35:22 -0000

--047d7bd6bc9c07dc1a0540b89c06
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Jakob,

And if someone is inserting 5539:* it seems obvious that the intention is
> that such community should get to 5539.
>
> Not always true.
>

=E2=80=8BI was hoping it is obvious that "someone" means "someone other the=
n 5539"
which now makes it always true in the above.

For the reverse direction not sure if say at GROW or NANOG/RIPE there could
not be common agreement that for informational announcements associated
with given route first 4 octets of LC should be marked with well understood
by everyone value say 0xFFFFFFFE (4294967294).

Thx,
r.

--047d7bd6bc9c07dc1a0540b89c06
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Jakob,

A=
nd if someone is inserting 5539:* it seems obvious that the intention is th=
at such community should get to 5539.



Not always true.

=E2=80=8BI was hoping it is obvious that "someone" me=
ans "someone other then 5539" which now makes it always true in t=
he above.=C2=A0

For th=
e reverse direction not sure if say at GROW or NANOG/RIPE there could not b=
e common agreement that for informational announcements associated with giv=
en route first 4 octets of LC should be marked with well understood by ever=
yone value say 0xFFFFFFFE (4294967294).

Thx,
r.
=



--047d7bd6bc9c07dc1a0540b89c06--


From nobody Mon Nov  7 08:42:07 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 971B9129850 for ; Mon,  7 Nov 2016 08:42:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.399
X-Spam-Level: 
X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, 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 f3rZ02NgpBH8 for ; Mon,  7 Nov 2016 08:42:04 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 8CAFC12973D for ; Mon,  7 Nov 2016 08:42:04 -0800 (PST)
Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id 37DF81E1F0; Mon,  7 Nov 2016 11:44:45 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
From: Jeffrey Haas 
In-Reply-To: <20161107162059.GE79185@Space.Net>
Date: Mon, 7 Nov 2016 11:42:02 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <1369BD67-5A14-4A37-AAF7-3B05BA518191@pfrc.org>
References:  <86860386-9C2B-4BD5-B457-2A6DA5446CF3@cisco.com> <17E646EF-4633-423B-9AC4-B53D49C90632@gmail.com>  <20161107121251.GT79185@Space.Net>   <20161107162059.GE79185@Space.Net>
To: Gert Doering 
X-Mailer: Apple Mail (2.3251)
Archived-At: 
Cc: heasley , idr wg , Robert Raszuk 
Subject: Re: [Idr] Vendor Defaults (was Re: Review of draft-ietf-large-community-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: Mon, 07 Nov 2016 16:42:05 -0000

Gert,

> On Nov 7, 2016, at 11:20 AM, Gert Doering  wrote:
>=20
> Hi,
>=20
> On Mon, Nov 07, 2016 at 04:14:32PM +0000, Jakob Heitz (jheitz) wrote:
>> 5539:100 is used by 5539 to tell its neighbors that the route was =
learned in Frankfurt/DECIX.
>> http://www.space.net/static/bgp_communities.html
>=20
> Indeed, and sorry for the 5539:70 and 5539:130 example, these were=20
> obviously incorrect - the list (and our configs) say it's 5539:3070,
> 5539:3100 and 5539:3130 to set local-pref in our network.
>=20
> But this example prominently documents why operators think that the =
model
> "5539 defines the namespace for 5539:*" is the only thing that makes =
sense
> - there are communities set *by* 5539, to declare "information about a=20=

> prefix", and there are other community values sent *to* 5539 to cause =
some=20
> sort of policy effect in our network, but both have to be declared by=20=

> 5539 to be a valid reflection of our configured BGP policy.

The general issue is that the context for the use of the community is a =
bit overloaded. =20

If the namespace, e.g. AS 5539, has communities meant to be addressed =
*to* it and it also has communities internal that it sets itself, it =
likely should use 5539:*:* for both.  The thing that keeps the =
properties of the externally originated and internally originated would =
have to be the Local1:Local2.  Enforcement of this can be done via =
import policy dropping internal communities at ASBRs.

The same would hold for items attached by the context AS as information =
for external consumers.  Unfortunately, nothing stops an external party =
from attaching such a community; it's up to the downstream consumer to =
check the AS_PATH to see if the route has transited 5539 and to hope =
that none of the intervening routers have added 5539 internal =
communities. =20

With regard to the internal vs. externally added routes, this is part of =
the motivation in the common header in the wide communities draft.  In =
that header, the SRC AS is the one attaching the community whereas the =
Context AS is how you interpret it.  Externally vs. internally attached =
communities are clear in that case, although with no additional =
protections against maliciously setting values in the protocol.

-- Jeff (and even SIDR wasn't willing to touch that in their first =
pass...)=


From nobody Mon Nov  7 09:05:56 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB63112967B for ; Mon,  7 Nov 2016 09:05:54 -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, 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 7_6hHLqwiTY4 for ; Mon,  7 Nov 2016 09:05:52 -0800 (PST)
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 C42A6129850 for ; Mon,  7 Nov 2016 09:05:51 -0800 (PST)
Received: by mail-wm0-x22d.google.com with SMTP id p190so195903516wmp.1 for ; Mon, 07 Nov 2016 09:05:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=date:from:to:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=XYPIDJ4a7eLnXpNZIFeCQk/gB1gTyMeiEeQOz4IOgr4=; b=CPqKtT6qBnj9UIM9Vw8LPy5qoWCXQIPm34gTrXNPWOKhLJY64SnyYvV0fH6Jkr7toa 7SojLAdCLBHBNBXQimATjE4ki1xs3Ga+xM8hJnm1CygLAaliIuM3GrdZuRoS7glrm+pn IzCDtjhmU72/1cetoQhqwnkQSHVcUJ3Xsj5wbQUEQtNQCfem5ceGSHJL1T2Hsng16Vtz mZEdcDQfuLQbo2b+wwnk9AWEQ0VCjfT7N5+K2/OmpNGqNypmFzrQFo+Jd0PNbJC+Q2zw lI2K5d1LISBBBE94NacnuYvtuVY/pP7u1Zs2YqYtnZuYbRadOYeEWHWY905lgCCiqm1d LVWQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=XYPIDJ4a7eLnXpNZIFeCQk/gB1gTyMeiEeQOz4IOgr4=; b=HOiAOQYTqvLkhEwRzz3EDJXR+CrazeMrZZy2x+gKvFNFGhoXhGl12FqxpvBcon1ssS R+PLN2sG3/YFKIKtKU/iaFVCe9MdJB66UfYpcwVOh0vI3a2MXME+Rp2MW89Ms4Vpyacj vRXT32rlb+mHXePG4H+njDQ5dxNWgS2pBgjsbmvrfikE7Vmn1nS6REeWCWO7Rv2Z17ML fEoQ5y8+tR7GH31U5PwgbXgy4w+VbNkpma/p7ttBjV86APmHIzjyT7g6CAdIJylywFTM LgshEGVFt+aBax1QSZoHplZ2sDoGUftGiKq7IUWvwA31zLymDhQDDbBpdeOMMwv9Mr/D ZBDA==
X-Gm-Message-State: ABUngve3IUTOBFIy9PeOpmF2RB2ca8tBse9IfmIQb6I8BVzcZNwKC02mmRZ8qXn9l/u5KQ==
X-Received: by 10.194.102.100 with SMTP id fn4mr6292875wjb.199.1478538349592;  Mon, 07 Nov 2016 09:05:49 -0800 (PST)
Received: from localhost ([2001:67c:208c:10:a99f:2e7f:ead6:6fcd]) by smtp.gmail.com with ESMTPSA id r72sm14578059wmd.21.2016.11.07.09.05.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Nov 2016 09:05:48 -0800 (PST)
Date: Mon, 7 Nov 2016 18:05:47 +0100
From: Job Snijders 
To: idr@ietf.org
Message-ID: <20161107170547.GA2473@Hanna.local>
References:  <86860386-9C2B-4BD5-B457-2A6DA5446CF3@cisco.com> <17E646EF-4633-423B-9AC4-B53D49C90632@gmail.com>  <20161107121251.GT79185@Space.Net>   
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.7.1 (2016-10-04)
Archived-At: 
Subject: Re: [Idr] Vendor Defaults (was Re: Review of draft-ietf-large-community-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: Mon, 07 Nov 2016 17:05:55 -0000

Hi,

While some keep trying to add to or change Large Communities, others are
going ahead and are deploying Large Communities for the benefit of their
respective operational communities. This here is the real news:

    "INEX has become the first organisation in the World to enable BGP
    Large Communities in production"

    source: https://twitter.com/ComePeerWithMe/status/795670632243625986

We should focus on publishing draft-ietf-large-community instead of
deviating into topics which can be handled after we've gleaned more
experience with the technology.

Regards,

Job


From nobody Mon Nov  7 09:38:17 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9384512959C for ; Mon,  7 Nov 2016 09:38:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.699
X-Spam-Level: 
X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, 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 tlU6ynM0edg5 for ; Mon,  7 Nov 2016 09:38:14 -0800 (PST)
Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id E84EE1293F4 for ; Mon,  7 Nov 2016 09:38:11 -0800 (PST)
Received: by guelah.shrubbery.net (Postfix, from userid 7053) id 65A4F7C061; Mon,  7 Nov 2016 17:38:11 +0000 (UTC)
Date: Mon, 7 Nov 2016 17:38:11 +0000
From: heasley 
To: Gert Doering 
Message-ID: <20161107173811.GA62252@shrubbery.net>
References:  <86860386-9C2B-4BD5-B457-2A6DA5446CF3@cisco.com> <20161106040849.GB18931@shrubbery.net> <20161107121459.GU79185@Space.Net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20161107121459.GU79185@Space.Net>
X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc
X-note: live free, or die!
X-homer: i just want to have a beer while i am caring.
X-Claimation: an engineer needs a manager like a fish needs a bicycle
X-reality: only YOU can put an end to the embarrassment that is Tom Cruise
User-Agent: Mutt/1.6.1 (2016-04-27)
Archived-At: 
Cc: heasley , "idr@ietf.org" , Robert Raszuk 
Subject: Re: [Idr] Vendor Defaults (was Re: Review of draft-ietf-large-community-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: Mon, 07 Nov 2016 17:38:15 -0000

Mon, Nov 07, 2016 at 01:14:59PM +0100, Gert Doering:
> Hi,
> 
> On Sun, Nov 06, 2016 at 04:08:49AM +0000, heasley wrote:
> > If you consider draft-grow-bgp-reject, does that change your opinion about
> > filtering needing to be the default?
> 
> IOS XR is doing exactly that.  What is your point?

XR is Jakob's attention, but IOS{-XE} and others do not.  but, the point is
that if, by implementing that draft (or by having already implemented that
draft in the case of XR), the implementation is not leaking communities (or
any NLRI) and requires RPL to do so.

Since the suggested argument for existance of this 'send-communities' knob
was to require configuration to send-communities - it is redundant, policy
is already required to send (or rx) any NLRI.

Not sending communities by default is a problem for leaf networks (eg CLECs,
regional telephone companies) that are behind ISPs who do not understand
routing well.  I do not see a disadvantage (or sum of) that is greater than
this advantatge.


From nobody Mon Nov  7 09:54:44 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DDEA12989D for ; Mon,  7 Nov 2016 09:54:31 -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, 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] 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 K0R_7k1BEhZp for ; Mon,  7 Nov 2016 09:54:28 -0800 (PST)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0107.outbound.protection.outlook.com [104.47.2.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE943129958 for ; Mon,  7 Nov 2016 09:54:27 -0800 (PST)
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=/sAneSpwjzFEe5mI6EOQY2BbSRSmRnHDr5kwBxbP5+I=; b=CEFaOS7OhGKJuLmcbpu0m99cE9RLcoPkrtUdHpYPFnWIp49qmIrmLFOJYwqCKos1F2hw/q/KSdjSgtcIIkZrlPr9MwqC+4tixGtvzBT7Ug7GPFdKap/9ypLWBcOVcEE/Bk7o/iI+kLMv0HyFcy7AHGaq9q31F9h85WKIS/vtjZw=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
Received: from pc6 (81.135.210.62) by HE1PR0701MB3002.eurprd07.prod.outlook.com (10.168.93.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.721.4; Mon, 7 Nov 2016 17:54:24 +0000
Message-ID: <022901d2391f$928dc660$4001a8c0@gateway.2wire.net>
From: t.petch 
To: Peter Hessler , 
References:  <86860386-9C2B-4BD5-B457-2A6DA5446CF3@cisco.com> <20161106040849.GB18931@shrubbery.net> <5BD3C90E-CC0E-42D2-9ACD-5787FC75BF0A@cisco.com> <20161106194258.GB5113@pfrc.org>  <20161107102306.GV24817@gir.theapt.org>
Date: Mon, 7 Nov 2016 17:40:56 +0000
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: [81.135.210.62]
X-ClientProxiedBy: DB6PR0601CA0047.eurprd06.prod.outlook.com (10.169.209.33) To HE1PR0701MB3002.eurprd07.prod.outlook.com (10.168.93.136)
X-MS-Office365-Filtering-Correlation-Id: 83da3584-9cfe-4f4a-d5ae-08d407371cb4
X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 2:K2XzkZgbjAlC7CJoZSosCKfDrG7wiR764H8lwgr1rnGvR6qFiauJe5ta6pMP32XJMBQe5jQEjD8ur04Lja/hJ7XoPIW1rZXtuHrSgv1gFpmIrB92VdbefbOKN4YlVuz0S+k0rHhQCv3WhhhUV5RdqPT0bfViayFWnxTgKTMcCu3Nu2UuKS/deL7yGUCPEYQXXIdQ0phJLhIwj8UPFwa8Yg==; 3:/AgrBo96X4/PA7wzyWUmVkxqT2FCstxnVmbccKdahW8Pndcfy2+GM3qwbolXnjMeWXKd+zCY8dh9Fv0AEmWoC+TbPY9bd0b4uSXlhtOF/MWgJ4Q+TfoUnw7W9CYaJFdmEIo4wGokVK/8YxpSQHNxJw==
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR0701MB3002;
X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 25:BcfNIDhCAZ8Pd/b0Mktdx9DcZQcxVqh7xYO7faWysXOi1VRFHuDCwhp6IG6ChFJu1awJppy9WAkDcEW0y5T+ikJ8be6hCL3EuH3w6dWceeuy4bw9nUJVE5UJ9oi/x8t43nQV2eYpQ2gZzJnVya5FKwXGxu5L97nduD+6fdi8q2ximDn7LVwGXMWILc9P+b/9BZG3c5kbXa0E6et8duyZK7Fm4GGvfjwyS9ayMyMVm65M2bOSOdv0hy9AzzYTvFEg7V3H2X7BLDrywUB4Jkv04edgWbUsL5LIygiOR36ACiXKhFtSbZPV/j5Yes6hxHiej33MGO/FDlYicLBsKuQGE/ivrq+llkqYsmV+X4LD1vfaS9BBcBKiCn74uVDR+qqBW4yEanS5t6FzbkTxz5Bma+0Mz0a2dEE5hx3Pjl2s//hU0x+jkbRu10UnQYiBaZZkizYhnyJhzDi9v+6PDyh/cVLtxwzpD78RM7ckI55V1+73i+/XkzTfSE2GFGvfttoc9dQP0lHBlSqD04iueTxs2CtNpuCWa1j6icqFC1zLBBMQUBMY/qZP5/o6C0Q2Mq/XIJrSyi+6GaBLI/OVrKViZxUUx20GZbJioH6IuH+zhUBdN88hDGzWVicL4r/X8IQb1dmOk5jxm/2dII2KTrvEioq6TneawXkGJGN2sAQdUId1jbOhM0Pj4g1a7yDEtSXSoYPrrwZspFpXPHyEOuL5xI3lZ3EvgPFsjYfPhpUUXYKHI8zCu22fYw7xwwT2HKy7hjFnsWQY6uDBhoBvoDXp2G3B7lI/nVDVrzbQ6nN1w9ONue5Up5nYvPajeqMSxtZRzWiceMrru3mcAbt0vJtttA==
X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 31:00Vy3D5rGYBCnmuZhc96IuEviTWZ5n47aD1TRcxSsN0o2woNs1IFa4+WBLcLT/GdwNO7UhzzgDn2mK1zE7FConItvWS9McOiP6Sbxuj6zzOWPYSp5Ml+S8RgSWIIHATMzdob6XCWTZ6ha/5s1NqSCPAwPswPVgPPS4w18tLtR+BSbgRd6rrgmdUtgLY7j+15LXJrqliV5/zDYru0D0drG9A3TVl/7cbc9golLrUJlzrXt7GGm+Nl3KjRxKaAb/wXy6Xjr9pRYTTRdAiEG44EJg==; 4:Qp03YKCBI2HI7Bjkbhec/JXnEsZTXQ1lume84rEeE1v3cSim1OSzvHGW+VxrOAn2jkGL6QPCrS+wJyJD5d+uuzB1VKGebVsqQjI0DEX47ed9yLrBYB6JHNWjKGVxDKJViWBRJH70evYQt+eTOe5nk+jp9rg9Wne+lnl3SYV0Mfv42s5dT47kcKt9m5ZhQVkA0hQD/QyajJ1YqY4kXf1TSscEovE4Vl8I4OGolPzMWwJ1ihqHWPjkGzb4BztnDKiYd3GNGxildzKwoxvj7hA/uf2xelXjoP5musqw2y/uNlXJFqw6U8hgvMGRE6fic3holSR/54DoFjngQ3f7U+I9xOonC4EmD/2sV2vqvEY1qPVIVLcEvcpOoV4vyj/lx68IWtvGYZ4fGK/U2jbRJHX6LQ==
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046);  SRVR:HE1PR0701MB3002; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB3002; 
X-Forefront-PRVS: 0119DC3B5E
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(51444003)(199003)(189002)(13464003)(24454002)(377454003)(6116002)(50986999)(3846002)(230783001)(33646002)(586003)(9686002)(68736007)(116806002)(44736004)(6666003)(86362001)(5660300001)(50226002)(23756003)(1556002)(19580395003)(19580405001)(93886004)(2906002)(77096005)(7846002)(47776003)(44716002)(62236002)(189998001)(15975445007)(101416001)(81156014)(81166006)(50466002)(84392002)(1456003)(42186005)(7736002)(8676002)(305945005)(106356001)(97736004)(5001770100001)(105586002)(92566002)(230700001)(66066001)(107886002)(14496001)(76176999)(81816999)(81686999)(4720700003)(61296003)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB3002; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; 
Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; HE1PR0701MB3002; 23:GZKp8vM3d2iquS3kpUEQXK7S3XT4HTP1ewLz1?= =?iso-8859-1?Q?OpRRjzd/nRat2uAZTBH5YD1zqo5LH1u7xjDMPncLb8lNTNGR0uCONuw67E?= =?iso-8859-1?Q?F7dFUxfjZm6EDRnMg70cVbV7E1AlH6LqmiP4NJkWYvVEENfQ+9KE4Surir?= =?iso-8859-1?Q?mUwtAp5aQ1zIuccJVeA9GkKB8gpM7FjrSoG/oyMzmTIijsoc3EJn+qSjKw?= =?iso-8859-1?Q?yqh+EkzwV3m27K7gJZVBe1lCL/VAuFBBYOCs/gtFZV+iji8sRf4AZxyU7i?= =?iso-8859-1?Q?sbdPKkDPHSN17fyap0FLqNSgv6aDdwVagqq0luQvor/RX5acDGMMYKnZIN?= =?iso-8859-1?Q?Erd280NcMM4Zkw8bjHntiBJTYhBmXMkZ6tFQVunrCo2fjjBCtToRTqXIPm?= =?iso-8859-1?Q?M69RtmmLN7RJLr8JL1va+0RY9K+IUKlsPRQT9Sek0AgOqKlJNE8IrzVg7p?= =?iso-8859-1?Q?iScqT2hoH592vLgdx18/Rsi7eZ+8yi/LjH/NaqpguUSs0nvSt6HhWPcpiK?= =?iso-8859-1?Q?2kWHo4JL2uvV/MgHEo1OPpnJ8W9tnWYO5QwdcVauerJVf1qCoEoYpHRv7m?= =?iso-8859-1?Q?HCpv68KsRZxdjES18Jh2rlRsGqTPLeQPZmyLQpJsjInzLtwGQke88sDtRl?= =?iso-8859-1?Q?ReyEqHWDpOFNONKxrtAHWaU5UxjkPKSf6X1KtROVktdQYK4n9OxPY2BBax?= =?iso-8859-1?Q?g2KkSFSkZhDDt9sI6HSWEPh0Xmut2i/92HdmlRpT0n9elInT6tpXLyG0+J?= =?iso-8859-1?Q?geM/bB5nn3T8e4oNiNbAwDylXn57HtZTJ2//MVV5+1al5uynASK3Iy2Uhx?= =?iso-8859-1?Q?qc2NfV65tgvzfFsim7E2u09a2KqBnWnf3Ru16gNxzL9Q7gDXfGB85E50ru?= =?iso-8859-1?Q?tjYblD4zv2lTOejYfuayW2Q1vAgOIDdbG1DB+unpbdYBTg0099GN9Hf/sg?= =?iso-8859-1?Q?fKYFFvHKBO7e62ZGRqujGnk/A8r8t0y2AOePDWjQ2L9n5L0SWSMYK4yBmG?= =?iso-8859-1?Q?ft9KHJ4YjHdYzen0yvEqTXbPFm9f+ZEs2xbbIq4Pon9TMkifGgrrt9txmZ?= =?iso-8859-1?Q?LY67ktGkxToU8hwTEEeRikd9WO/yUXUTAQq07t/hevsr/3JFkymh+vD6cN?= =?iso-8859-1?Q?oV4iHKxY8VIEDjItN3TcCFEFjogE6kyd/UNC+GTgS4YQM5u7M+21g+qvJf?= =?iso-8859-1?Q?HovSz56fm84452PBk7NczIH9orkuj6QhebykTBmj6GEwX0KQNXXAbOd8GJ?= =?iso-8859-1?Q?+AO7v2Ew6llzTpiIwzkjw7SfQCa/3e7uQlo3W01pRIYNKTcpID91hON+zZ?= =?iso-8859-1?Q?pcblXRh7bmN5xRu+ZizM/kOtaD1CMLXH1rK/qT67/R80lJhyrV07GA+VWa?= =?iso-8859-1?Q?5MQhSAf3uCxlEBQKAmqsDmot0Z8EMGdAFEvVHgy0aDAKqeqdpvwsqLr6+b?= =?iso-8859-1?Q?eI2XGzUJ4mDqt5IHf8hQWfI3Uq7xmz96cN8/0c3XJ9siCF6qsvexRNLl1p?= =?iso-8859-1?Q?jotcGHgSca3YB8XBalQdaH5F6ynRHqxS+hUozw6snfOwem5umNUeS9A/Za?= =?iso-8859-1?Q?yI53OPmH1oKZE7I1Sub2hj0F5PUA=3D?=
X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 6:APomAqZC3xZSrINS+Qln4+nINkHdKXFJt0CrwkolmFbttLPl0hY5TyhjMpAzgyG5yiNbdyrakdXR9FMKnKbRj1ndcZhTwJaPu18GdKlDai0orKHCTMrulVPMK8FAcw9IG/B/c2OKN0VDtneDr1XTh4L0gCv6gtt6RkpVco9H8AJ9c/bWQFwTt7fxVxkjs4q0idJYb8Gmt04uoZfyKoDhD2HgnUGD+4YSgNu18VUsxftoAOnBlgBvP5au0BzlNNmLI3u+GcwCiqmyT38esnaIEiC14/MJLk4fUZnuT0WjF71n+wozcTl6N/uqwmBIv6R0; 5:B5VhDZdWrqB9JSSpKuFBhYwkqQbEZlg91S+0KsncmW29KoTne8BPq40Ca9vF2qByi+TNOiBbg34kZvHEzY4V+/9mD4LGtM1oIHdXUnIhLWuB9tnaKMMfjHxNUaob1buuS/bBBkFKXvO11Ye+Zp+rKKAWmkhy14wdtqb9diaKDPI=; 24:eOD3o/9CPXsl+afUlE+G8HcsZgfJY10fZHIvoYxHHvxw+tm4m7evsLPStnOccm4AdgoT18SRFcvQmNjILGI2MLSGoeQvVVWZsug1qSbmFDM=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 7:3aip7jM1pHbnpLiYa4MimzxzOuy9etxdqmYcXgDbsrDsM5QUU9pCJhxdu6OGmEyykgQBbp/xjQTXIvzGOSt70QVKy/tTG3Wuv2TDmYB1tJecmYOHbXrDVsQfuqGB6BYhjUV2J0sVAdbcV+qeqpFqBLq0ocbqHq04bdRQOZ+mDlFnPyOjbYr/qJW3IBZgxruApTgVxwJcv+TfFVWkR7uiu1YBuE3qOMB+PtgBxLyxoGnMNYGwPfihY5YcrZgV9Yq+LG0dBADr4kYx8o6ADddK2+K05q1HQJY7JrG9HRmNwkYovY/bkcSl0m92+jy4XEsXHT8yWYqY3wpee8vz6sUT7fQyNpTPC5Ml4Rr6DTq9MEc=
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Nov 2016 17:54:24.7907 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB3002
Archived-At: 
Subject: Re: [Idr] Vendor Defaults (was Re: Review of draft-ietf-large-community-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: Mon, 07 Nov 2016 17:54:31 -0000

----- Original Message -----
From: "Peter Hessler" 
To: 
Sent: Monday, November 07, 2016 10:23 AM

> On 2016 Nov 06 (Sun) at 22:50:24 +0100 (+0100), Robert Raszuk wrote:
> :I really wanted to make sure that large is deployed with defaults
which
> :make most sense and such defaults are identical between
implementations.
> :And we can do it now or never as when the code is shipped out in
first
> :production release the gave is over.
>
> In OpenBGPD our default is to propagate communities; normal, extended,
> and large.
>
> We have no intention on changing that default.
>
> Additionally, I see no reason why implementations should be have
> identical defaults.  Cisco is not OpenBGPD, OpenBGPD is not Huewai,
and
> Huewai is not Quagga.
>
> This is implementation specific, and has nothing to do with the
> standardization process.

Peter

I think that that is spot on.

Customers will expect consistent behaviour from a supplier (and equally
should be prepared for change if and when they change supplier).

Of course, it may not always be that straightforward as implementations
need to interoperate, first and foremost; but if they have been doing
that, albeit not following the precise specification of a transitive
attribute, then I think that consistency is what is needed.

Tom Petch







>
> --
> I am so optimistic about beef prices that I've just leased a pot roast
> with an option to buy.
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr


From nobody Mon Nov  7 10:15:28 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F57412948D for ; Mon,  7 Nov 2016 10:15:27 -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, 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] 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 hpPPUuGVkVKR for ; Mon,  7 Nov 2016 10:15:25 -0800 (PST)
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 2FE6E124281 for ; Mon,  7 Nov 2016 10:15:24 -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=WArl7CwG6SENKI3vvwuzxtavWfYyYijp2CsbKp8JQa0=; b=fnnUpgxH9clc+uqYgopvEMDhVU0sRw/jQR/jKQy6tCFmMPWoBUYa19uEc8DMVQ2GDwHPNZ7QGZovjJvFapDAwOJ75lqMKBvK97k+TuSPCRDJcyk9K1gOnYtc0RU1QWKULu189gd1sZvDcXIzAN3YXJGrEAbxzHcPnIQLRGeXqno=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; 
Received: from choy-sslvpn-nc.jnpr.net (66.129.241.13) by CO2PR05MB2503.namprd05.prod.outlook.com (10.166.95.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.5; Mon, 7 Nov 2016 18:15:23 +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: <20161107152616.GB25256@pfrc.org>
Date: Mon, 7 Nov 2016 13:15:17 -0500
Content-Transfer-Encoding: quoted-printable
Message-ID: <6FE43655-81D0-45E9-9817-D5583213DE2D@juniper.net>
References: <20161031205515.GA25507@pfrc.org> <5818E126.2090202@foobar.org> <20161101185759.GA23458@pfrc.org>  <20161107152616.GB25256@pfrc.org>
To: Jeffrey Haas 
X-Mailer: Apple Mail (2.3124)
X-Originating-IP: [66.129.241.13]
X-ClientProxiedBy: BN3PR11CA0040.namprd11.prod.outlook.com (10.162.169.50) To CO2PR05MB2503.namprd05.prod.outlook.com (10.166.95.149)
X-MS-Office365-Filtering-Correlation-Id: 7b8e8123-1e8b-49f6-cd4f-08d4073a0ae8
X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2503; 2:9KfqvADOJX9n+J7l/O+YkRnUBqO5xmccold/01qX8B2Xu0VQqbOWCzffd3OnFGbNsYu4fgnhOWqwxpkj+GTjGpnXCTxKpJmttoTiNXGL2iOqyUt4re3TXEPou1oKKZI3zGvd0cYy9yhrpkWn1TBpGyZ7VIegi8CJePCY1ofwKPl5RBbc28uIiQPmvKXDyWUYLltCmnT0wm4fEVJFFd3pLA==; 3:R+u9zQH1xbxFwpZPAC0FHLC22ntO6D2cHuOsGp3fnTI1blwJaWx1N1HUbRiMvkKZ7FRnmAIQOYzjt3zZ12vGfJiLwF6HyTP8tLb58BkAW6WeYvHtQ8fQHtcD85Vxo0ycRtHEkeZGv7no7hJ0i3D6uw==; 25:vNa+y/oseB9PW+oJC/56UJVMdBTtZ6L47N++kumsEZ/3YJOcaRK7yP4T9DZjuJ3TdCbFDb95JZZaq+2dcKq2Pou3oe1I/Hp8NCj1NOhjVubOZqOQWIIn8TEI3Muw4JFECkNC/6BLXfH4J1I+JjwUOoPhiTZLlOVRwriie5p6tsppac6MzWFljFZaaBin10pPC/coORbC3LDvhcHd0e0Be0wIG6qvrzlxLr5vRz7yCNgu1Lmo+uQ/1409zi6pUbYJdPcXkx08dZhXIoPrjGQcz+KutKsmoRLsr3asI9ygNmiPIvOyqo1CHZGhKU/XOV3pXx0OPfw90FwUBcvSraL9dux00XhSzia8rbgp86+nF+RXIL0jU868mDbmnLuGhom1H/8X21022s1zP8qol43s6CwaieahVMi7lrd4voTNcWKBoA5sLVyOnMGhng5q/L3Z
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR05MB2503;
X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2503; 31:GB5ya3fObvz0zTkGXmwH/Epo1X8uY33Chq6ySGZgoT8r4HzUCeW3rLo+IQXrzeX4FwRMdUsfBjSuuzlZz/ahGDfdRIYLvzW9VI2ViV52YsiGELtcH3d49hWP0Vxt+wQTFwE/eUh+pd4+9MmsCUjejzWoIA5YAF2XIVlMlLhZW3TOkRm7k8iDhE5CXFPq96rvMEUsi4ePD55yw/JWHKobHD6ZqiVxqzZVOyywLUcWnf7ZjpVialeTDvp0Huu2hizE; 20:lFcoayd5AvRn/TH9PRcXWrpr5kfY69wlPOtGBllzVQNMJyHe3idvwZ07JX9F3zWdKAxlGqjJdNbRWzThSnu9mLyK+AhLNTt7yXixze0PNG889G6uwoKOwgtidg1G6JC4ArXnkIl2mkGicHi+/lGy2QRjcCOODOYniEAhrwePFM2xbUk4lRuYOWcIrgJUA1VGEnE14xlUCniaczxbq3j5u8VQJ7dRqiwf0NGx7lnR2ey5lMNU/mfwnkmNGYPY7PNAiAAsqn0r6HpJnTqPgP9puOCIkNZCzFSX+2sKJsarnMpRQCBy/aogC/1MFO+zn1WCc5nz4q78xJKwxDDMWHaok5ZwUgsypFlOLUEt3lgXayXquVn1aAOWcx5rSeXExuB6oGTJ5NWTZicbc3q45/6A4vU4aBxApv62bq/JsbLtzgOalggwPYTydi3rewxopWGnAqmHNtMAVuKrWj+KsIus7KRLTbYKQ7zQ+FqokbEy7OZmGSwckEJ4ZkEKEM/9kEDDV0gMz9+6MW/H1V0KNWSNNU7aBnnuu4LE818YZzX55pVLh3fkrL6fkWvGRPFnGhQgTn3u+rr9y7hMIHBnK0nafHaOs8aqNvjGf9dokLyChUQ=
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(190756311086443);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:CO2PR05MB2503; BCL:0; PCL:0; RULEID:; SRVR:CO2PR05MB2503; 
X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2503; 4:r/AyniksYrwwTrfVM7UYqXx6zSnArLv5gDe/Hm36Xavvh+AYczZHu0UdYoBH/+Lw5D5n24qrf7EDUPenBV/0OXlJd/w5d5sVTEfpwWAemnzffCh+n1bXl8Brad5dEdNbhU6uI8U11TyuYe7RJghY3eqM5dZRbpentS/qQ2Le2yjYakjbKunLVjB8ApjaMa5Tgwus4fCHLWu3ZvKAYSqc0Svi+35dNSHl8Ej2pfbqiCjfkQPM7KbqXNU5gtWHtR4NOxwPF5rs19kqfpCejzVFETfXKhfasKSi2kFHQrNXLfoCTk5PS83U0Iu4tvgaqkpoaDi8TBr51rAGH4aSckW7YdE19RnJNEy4GdQ9pw+Kpabc2XF7dbQ9XdmQlhxAlCYsKrcxGbKvRJRzxiQYLVoRt2ljdb5yD3RfGkb2arfBshUj0FUpahodMmt+WmxVnIUNGZRWhpvS9+Mqau5chnSORQ==
X-Forefront-PRVS: 0119DC3B5E
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(377454003)(189002)(199003)(24454002)(110136003)(23726003)(33656002)(66066001)(42186005)(586003)(47776003)(189998001)(6116002)(3846002)(5890100001)(19580405001)(19580395003)(5660300001)(92566002)(8676002)(561944003)(81156014)(82746002)(81166006)(230783001)(46406003)(83716003)(53416004)(86362001)(7736002)(97736004)(106356001)(8746002)(77096005)(36756003)(6916009)(2950100002)(101416001)(105586002)(7846002)(57306001)(69596002)(50986999)(76176999)(97756001)(93886004)(68736007)(50226002)(4326007)(2906002)(305945005)(6666003)(50466002)(42262002)(104396002)(222073002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB2503; H:choy-sslvpn-nc.jnpr.net; FPR:;  SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CO2PR05MB2503; 23:aauWGpQ7RG+4epISY7ZCTAXkIj1vqqhRwOpQ/+DHT?= =?us-ascii?Q?GHZ41SLqnHhnmY/VCBFKALX43J/Q+fkiXLOC/KDxuT0oTdzm4A7BGQ6ssS/y?= =?us-ascii?Q?wJChn0H9OWIMu/rGIld/eaT209k9IHBYr8VTrWf073LnINAbc1rN/nB5Z2sP?= =?us-ascii?Q?M+H+3/Vfc4RqDnDqksPd0FnChyIotjtn2YTueApH5TbJWb0EmsBEGTFSqXkE?= =?us-ascii?Q?nvFISoxoL0+w7p4FnrMUHptCiiSQ2SDnL2ugbwqLz3yx+PDZD/sT7tleiyp/?= =?us-ascii?Q?VzWkJbJMfvZvL9yNY9k8qKt4VdPvqRZ2rGKTwTombTTEncTdB1X7pCOprWyW?= =?us-ascii?Q?Jmq5OB/LOvgG5Ik7WA/MBNYgoaYObqfpP+4lVjJxJo5dV38Fuwjv8+ZSyaRG?= =?us-ascii?Q?sNLHj6b2Mgs1bTNPiPg0/bnCjP5ul7k5f/jk0GnuSTeJC/6pkocBxKhoRy8J?= =?us-ascii?Q?xfmVDN8mdY/uV0MDTwDFPqYXk2RZhYSvLfg0fVCqtEL2AQi131zBOiCcVMZF?= =?us-ascii?Q?s2NCcrtNC0jGGQtPx7WncE5t95W+oy0zpPL3zQUAIKc0d7wioEi6725FRjnY?= =?us-ascii?Q?Yi/FSQsw9oTIK2+AxgXXhUDhTM3HB8RdYEqpTo5Fwja/BHnscCcznvL6I4Mb?= =?us-ascii?Q?Yg4rKMdensYn7UDF9xaD2J9EMw+YI/KkNQhTUuRY/VgcsAV3UX+sbzIJ8I7W?= =?us-ascii?Q?bJtkKdAil/Y0WvIr9QJj7sxKC+VqR2HmcExy0XRW8t3BWA9NKYw/Q54LTiQs?= =?us-ascii?Q?2VWFVpBcx3GeiMAHsmRI1SkEGgkVPxAtLhhcDU9TUFDcrWO4IgDesODmFlvK?= =?us-ascii?Q?P7BDEbCpMikACXb5LZ6zM/p1BgOkLVOV/F/N3T1EvVk+Tf4VRoszvhrjbYYd?= =?us-ascii?Q?4ZNqB6RzPg3aQgcSTu1LkVy3OaD/Um5yW7iqhsZyZi9hX/WioZ1POI/wKMYy?= =?us-ascii?Q?HmBEELQ+D9YaeQ0cXu+2De+u6LHp4lPiJKeCnMS9Zm1Szhfs1sH+v4EcVqVQ?= =?us-ascii?Q?rfpEuQsZSUFi6YnYOpCetV4lY0fPhCE650ICOZ+dooKNvNoWQdJEg2k0bt4Y?= =?us-ascii?Q?FRD6J7P4EcKJZ/XyHeTyyc8nXmXa1iSF6Uz2l+EXbZ4e1sjMnB3mx0cwPDWo?= =?us-ascii?Q?i0Taktp7sEtqa1q4tiPHI3xVTtKoIMKSq8X9G8k/RzuLXlVjEAnSn9YavKrb?= =?us-ascii?Q?G9rO98dtRVs2MCE0xqKUyIkLx92KdqhQS9wGrNcUwiNPmos64hwDGG+2g8VC?= =?us-ascii?Q?1uzrJM6Insn098LTvvy0Xv+WWUfXRT93PjZ3OHPOCz1+B8U3ZXCZEF12dit7?= =?us-ascii?Q?ID+AjP4tl1vPa9sp/9XLZzD2nuvcVjKYqXIG+qQj4KwGcBftaWvLY+aF9Pnf?= =?us-ascii?Q?eItzr0OcCP27EV+ku5JU9417N8CVowwwnzT1Iq2+2jVzLqa?=
X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2503; 6:Wjo4DOAm867QADqJW3+ix4TVPnA3hlFqAgUuez5epY6SnLdqmXdRADg+jUw3pjqGevja8SgLytKnaUFdMkJgAId7DG2ivJfjSJe1hPESE5euAOi4Y0/EV+OSg/bRjVHo0KBS7b2YJvsvJDfWhEO4YM1P5iC9ikaNEv8hgsaKI+rVv9wUNJQRljChg67U/K4v3cbAubOG3JQTlmASxMKX7ptHiLmsQylPiksqrJXUSAhwu+7oj6lDoZhm83GTxIYl9TONQ1uIszR9o+Rg2UlbIb23un9ZBARcgGMEUInN4BBcg/dkiYTHpEfmrcQazSNWjJitVdJo2CwTUxo1FaPNDu3U42HFL4t75/WXaNII3GM=; 5:4KylHzHjhTcUgNI6sylsvyQ8+YC005jpgvsh1b6ekWHj9PaoWpCCWsDnX4ds6G7JQEuxxPMhhTneU0vEm7HQctboo4TDc+NtELls/4WirbtyMp9SebV2722a+Jir9OwlWJVL9N8EEVrfvFAo2EBBoYGO+Pro4rj8Msq9fUD3FcE=; 24:n3Jha+FgY9ceTsUod/uiG2yLPq5/IHHIfq1UBceiDa8vHqjZHeJXBOHbT1kBgz84IemJZR6UrK5RDTHVvpk0h7SKQ/JrQAAwl1JV8oMBGTQ=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2503; 7:KBn/sNWxWb3/BedYqNPxh9cCZScWuruwY7/14qoHOGN4m3YHYYVEZljmO3WzhjSCMmcNB10j3qHYWViVzjvZ1gfk8eIFB7RvzGaIout9MAtwn3IFJq5N4sSVH2tYnTL9UcQBfDC8oirvVe4arWmDNnzSpvMI/cy95Dg0mJz/fjkPLPKqFcPX8zREbD4mUubYPprczjGX6rDGADLTNr9vNPALdlHQyD1CwSz5A62Dvr/u1MYUob4TpWREAUMwhI6UripoO5dFzoPhgJcWuegQKCYt9qVJcqAhXU0TXqQlqke+2n8Su6Xdy7t5U6QfGkIkr1JUwlwrOadbbBVzmcryiQ4jWMumMahpWCSAbxqF1Eo=
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Nov 2016 18:15:23.1793 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB2503
Archived-At: 
Cc: idr@ietf.org
Subject: Re: [Idr] [internet-drafts@ietf.org: I-D Action: draft-haas-idr-extended-experimental-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: Mon, 07 Nov 2016 18:15:27 -0000

> On Nov 7, 2016, at 10:26 AM, Jeffrey Haas  wrote:
>=20
> Marco,
>=20
> On Sun, Nov 06, 2016 at 08:23:36PM +0100, Marco Marzetti wrote:
>> On Tue, Nov 1, 2016 at 7:58 PM, Jeffrey Haas  wrote:
>>=20
>>>=20
>>> A feature such as this one, perhaps extended with a per-attribute =
form of
>>> draft-ietf-idr-bgp-attribute-announcement along with enough =
information to
>>> figure out when filtering wasn't done could provide some safety.
>>>=20
>>> The related changes to this proposal would be to simply add the =
4-octets of
>>> the attribute announcement scoping and potentially the attaching AS.
>>> However, given even such vendor features are likely to need to work =
in an
>>> inter-as fashion, generating scopes of containment become tricky.
>>>=20
>>>=20
>> I have always wondered if we should add and N bit to
>> draft-ietf-idr-bgp-attribute-announcement to limit the advertisements =
to
>> neighbor ASes only.
>=20
> Such a thing was discussed among the authors of the =
attribute-announcement
> draft.  What this would mean is such a bit would need to be set and =
then
> automatically reset into the M-bits (C+A) at the next boundary.

I'll also observe that we already have the NO_EXPORT community which has =
virtually the same semantics if you apply it as you're sending the route =
to your peer. And then there was AS_PATHLIMIT, which never achieved =
escape velocity. Regarding NO_EXPORT, you might remark that you have to =
apply it at your border router instead of at the origin, and that's =
true, but I'm not sure if it's a big deal. You might also remark that =
NO_EXPORT doesn't survive if your neighbor strips inbound communities =
(or explicitly blows away NO_EXPORT), and that's true too -- but if =
operators are deliberately dishonoring NO_EXPORT, is there any reason to =
think they wouldn't insist implementations have a way to dishonor the =
mooted N bit?

--John=


From nobody Mon Nov  7 11:11:09 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E1D1129558 for ; Mon,  7 Nov 2016 11:11:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.699
X-Spam-Level: 
X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, 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 5QA5y6wSY_-e for ; Mon,  7 Nov 2016 11:11:06 -0800 (PST)
Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id A59521294EA for ; Mon,  7 Nov 2016 11:11:06 -0800 (PST)
Received: by guelah.shrubbery.net (Postfix, from userid 7053) id 4DCFD7C4D1; Mon,  7 Nov 2016 19:11:06 +0000 (UTC)
Date: Mon, 7 Nov 2016 19:11:06 +0000
From: heasley 
To: Brian Dickson , heasley , "idr@ietf.org" 
Message-ID: <20161107191106.GF62252@shrubbery.net>
References:  <86860386-9C2B-4BD5-B457-2A6DA5446CF3@cisco.com> <17E646EF-4633-423B-9AC4-B53D49C90632@gmail.com>  <20161107121251.GT79185@Space.Net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20161107121251.GT79185@Space.Net>
X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc
X-note: live free, or die!
X-homer: i just want to have a beer while i am caring.
X-Claimation: an engineer needs a manager like a fish needs a bicycle
X-reality: only YOU can put an end to the embarrassment that is Tom Cruise
User-Agent: Mutt/1.6.1 (2016-04-27)
Archived-At: 
Subject: Re: [Idr] Vendor Defaults (was Re: Review of draft-ietf-large-community-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: Mon, 07 Nov 2016 19:11:07 -0000

Mon, Nov 07, 2016 at 01:12:51PM +0100, Gert Doering:
> Hi,
> 
> On Mon, Nov 07, 2016 at 12:16:41AM +0100, Robert Raszuk wrote:
> > > The attributes changing will induce BGP churn as updates propagate.
> > > That churn may in fact trigger load-induced brown-outs and further
> > > induce churn.
> > 
> > BGP communities are not used in best path selection 
> 
> While the communities *themselves* are not, many (most? all?) major transit
> providers offer communities to influence the value local-pref is set to,
> on ingress from their customers.
> 
> So, if a customer sends 5539:70 or 5539:130 to us, this will end up 
> setting local-pref 70 or local-pref 130, and that *will* influence 
> path selection.
> 
> So, while your statement is true, it's lacking real-world consideration.

I do not understand this churn argument as it applies to large-communities.

The receiving party has to take action - ie: create policy to act upon the
large-communities - for them to affect route-selection.  There may be one
IX that is the only AS on earth that currently supports large-communities.
if large-communities are sent by default today, they only affect the size of
RIBs and size and number of BGP messages - and possibly that IX.

the only communities that take effect without adding policy are the
well-knowns and they are not present without policy to add them - and
there are no well-known large-communities.


From nobody Mon Nov  7 11:26:29 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 838BA1294CF for ; Mon,  7 Nov 2016 11:26:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.399
X-Spam-Level: 
X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, 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 gyG9aaviDiAu for ; Mon,  7 Nov 2016 11:26:27 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 3586F129517 for ; Mon,  7 Nov 2016 11:26:27 -0800 (PST)
Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id 3866D1E1F0; Mon,  7 Nov 2016 14:29:08 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
From: Jeffrey Haas 
In-Reply-To: <6FE43655-81D0-45E9-9817-D5583213DE2D@juniper.net>
Date: Mon, 7 Nov 2016 14:26:25 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20161031205515.GA25507@pfrc.org> <5818E126.2090202@foobar.org> <20161101185759.GA23458@pfrc.org>  <20161107152616.GB25256@pfrc.org> <6FE43655-81D0-45E9-9817-D5583213DE2D@juniper.net>
To: John Scudder 
X-Mailer: Apple Mail (2.3251)
Archived-At: 
Cc: idr@ietf.org
Subject: Re: [Idr] [internet-drafts@ietf.org: I-D Action: draft-haas-idr-extended-experimental-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: Mon, 07 Nov 2016 19:26:28 -0000

> On Nov 7, 2016, at 1:15 PM, John G. Scudder  wrote:
>=20
>=20
>> On Nov 7, 2016, at 10:26 AM, Jeffrey Haas  wrote:
>>=20
>> Marco,
>>=20
>> On Sun, Nov 06, 2016 at 08:23:36PM +0100, Marco Marzetti wrote:
>>> On Tue, Nov 1, 2016 at 7:58 PM, Jeffrey Haas  wrote:
>>>=20
>>>>=20
>>>> A feature such as this one, perhaps extended with a per-attribute =
form of
>>>> draft-ietf-idr-bgp-attribute-announcement along with enough =
information to
>>>> figure out when filtering wasn't done could provide some safety.
>>>>=20
>>>> The related changes to this proposal would be to simply add the =
4-octets of
>>>> the attribute announcement scoping and potentially the attaching =
AS.
>>>> However, given even such vendor features are likely to need to work =
in an
>>>> inter-as fashion, generating scopes of containment become tricky.
>>>>=20
>>>>=20
>>> I have always wondered if we should add and N bit to
>>> draft-ietf-idr-bgp-attribute-announcement to limit the =
advertisements to
>>> neighbor ASes only.
>>=20
>> Such a thing was discussed among the authors of the =
attribute-announcement
>> draft.  What this would mean is such a bit would need to be set and =
then
>> automatically reset into the M-bits (C+A) at the next boundary.
>=20
> I'll also observe that we already have the NO_EXPORT community which =
has virtually the same semantics if you apply it as you're sending the =
route to your peer. And then there was AS_PATHLIMIT, which never =
achieved escape velocity. Regarding NO_EXPORT, you might remark that you =
have to apply it at your border router instead of at the origin, and =
that's true, but I'm not sure if it's a big deal. You might also remark =
that NO_EXPORT doesn't survive if your neighbor strips inbound =
communities (or explicitly blows away NO_EXPORT), and that's true too -- =
but if operators are deliberately dishonoring NO_EXPORT, is there any =
reason to think they wouldn't insist implementations have a way to =
dishonor the mooted N bit?

Agreed.  Also, arguably the issue is worse during initial deployment of =
the attribute-announce feature due to the number of boxes that simply =
don't understand it.

That said, this is one step beyond "no-export".  It's "set no-export at =
my asbr boundary".

-- Jeff

>=20
> --John


From nobody Mon Nov  7 12:25:59 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C33A1295B8 for ; Mon,  7 Nov 2016 12:25:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.699
X-Spam-Level: 
X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, 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 TnFKpJJwn_95 for ; Mon,  7 Nov 2016 12:25:54 -0800 (PST)
Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC5D912948C for ; Mon,  7 Nov 2016 12:25:54 -0800 (PST)
Received: by guelah.shrubbery.net (Postfix, from userid 7053) id 514FC7C640; Mon,  7 Nov 2016 20:25:54 +0000 (UTC)
Date: Mon, 7 Nov 2016 20:25:54 +0000
From: heasley 
To: Brian Dickson 
Message-ID: <20161107202554.GI62252@shrubbery.net>
References:  <86860386-9C2B-4BD5-B457-2A6DA5446CF3@cisco.com> <17E646EF-4633-423B-9AC4-B53D49C90632@gmail.com> <6CAFC026-6102-42BF-97FA-779457D84ECE@cisco.com>    <96108A84-8016-4A24-8D9D-C08F65D07572@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <96108A84-8016-4A24-8D9D-C08F65D07572@gmail.com>
X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc
X-note: live free, or die!
X-homer: i just want to have a beer while i am caring.
X-Claimation: an engineer needs a manager like a fish needs a bicycle
X-reality: only YOU can put an end to the embarrassment that is Tom Cruise
User-Agent: Mutt/1.6.1 (2016-04-27)
Archived-At: 
Cc: "idr@ietf.org" , Robert Raszuk 
Subject: Re: [Idr] Vendor Defaults (was Re: Review of draft-ietf-large-community-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: Mon, 07 Nov 2016 20:25:58 -0000

Sun, Nov 06, 2016 at 07:46:10PM -0800, Brian Dickson:
> > On Nov 6, 2016, at 4:12 PM, Robert Raszuk  wrote:
> > 
> > 
> > Isn't the main motivation of LC to avoid overloading the target ASN with private ASN values to embed the action ? 
> 
> It may be the motivation for having 3 x 32-bits, but the MAIN motivation is support for 32-bit ASNs.

both of these are motivations for -large-; support 32-bit ASNs AND stop
over-loading.

> It might be the case that initial deployment could incorporate 16-bit ASNs in 32-bit fields, including private ASNs.

What?  is there a case where a 16bit ASN doesnt fit in 32bits?

> Those using 1997 might want to migrate to large-only, rather than continue supporting both large and 1997. That migration could start with accepting both (1997 and large-encoded 1997 of 0000ASN16:0000ASN16:0), having customers add or switch to large, and then dropping 1997 support.
> 
> So, let's consider the implications of having large be sent by default, vs not.
> 
> When customers add the large communities, they will go everywhere if they don't filter, i.e. if they aren't aware of the need to filter large communities.
> 
> So, why would that migration be expected or considered reasonable, if the long term goal of LC is GA:target:action? Because it is the simplest, cleanest, and safest path. 
> 
> Having 1997 and large simultaneously used means possible corner cases or inconsistencies can occur. 
> 
> Once the 1997 semantics are transliterated, only then can real LC be implemented on the receiving side.
> 
> That would involve two windows of overlap: 1997 to transliterated; and transliterated to "real" LC.
> 
> And in both windows, the 1997-semantics large communities can collide, just like the conflicting cases Jakob listed.
> 
> That issue is a non-issue if the default is "off".
> 
> > Besides both are applicable to their directly connected customers so really regardless of the default those should be dropped by policy after execution/application. 
> 
> I believe this is called "blaming the victim".
> 
> There is no easy way to tell how many such conflicts would be exposed by default "on".
> 
> 20 years of  RFC1997. All with default off. 20 years of industry consolidation, staff turnover, undocumented implementations. 

20 years in that implementation...

> Assuming that no migration will occur, isn't helpful. Changing the default behavior across such migration is the risk.
> 
> Having the same behavior for large guarantees zero incremental risk, which is why I am advocating for it.

given a BGP topology of AS1 - AS2 - AS3, where AS1 & 3 recognize LCs and
AS1 sends LC 3:n:n to affect their local-pref (or whatever), this will
potentially break when AS2 updates to an o/s that recognizes LCs.  surprise!


From nobody Mon Nov  7 12:38:50 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8C012948A for ; Mon,  7 Nov 2016 12:38:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FittRNpntTjz for ; Mon,  7 Nov 2016 12:38:47 -0800 (PST)
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 56B88129543 for ; Mon,  7 Nov 2016 12:38:47 -0800 (PST)
Received: by mail-wm0-x22a.google.com with SMTP id f82so142243021wmf.1 for ; Mon, 07 Nov 2016 12:38:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IcBWRZipju/VKAzlMtxKMNKNxdnxLZcweuDZe0AMt3U=; b=XJTizCDDNPyLflzH82yUXEoJe5Jk2lNQ+WfGlb3gvCiwa/0MdJYcB6lSZlebk73TV2 qjE3u+KWXMIj4kjEEarYTeARgi7onoUVbHPdiv5StDuB2VrmvueHpzOEN+Fvunp8w+hI +s9gDefZ4u+M2dc9t3myG01GrTjo6KKYQL663Uri7DfycJj0IqvuQwTYfWxtv5RRDIkL bqt1KWMICgVuy3uM+0aH8w3VetzxOdCVPcHuBsScFbPxtFgT37ikOlaAk2jB7J6cBk14 5pQGPsPELhZI6iScsOp7tpJCbwEUQ56N5AaWqOZsis7ol/PbmXUervLbHX3Vnbg+6trq gLxw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IcBWRZipju/VKAzlMtxKMNKNxdnxLZcweuDZe0AMt3U=; b=cUngf36ZwlC3dlHL969g5/brkB91TEqHFGCMJIbmh5b25v0Ocxva0PFhYT4VMCS86G FKcuxvPgfM+bUdT2b2CfvZovqd/FCC5a+SD66U496aQ8XoS/hWvRx/7LgwHYVcyWj4r0 pXM2b72FTst33DjBYsv7TjFclR6rVJvltl0tAgoBH47aqZP8bpgwNPZ2QjKjTxVwqdhZ nGgylbYE2RjMhFTM2XJETALeNhhVjhbklLTX8HwyOgZS0RAct96fzuRe+0HAtPkqd5OM FWpOa+tlg3Ykt0CwTeKB3w/G1yy9PgkhdeYoqNnX5o19tgZhHVP2o2nbNXc7xGm6MaEp yH6Q==
X-Gm-Message-State: ABUngvf+jrnHwEWv1J88NMYaDGSHwjnclzMkYANpHyPt6CzjlwP48MyYuvtnBnRu4vjeIq7ITfAA97zMr7davg==
X-Received: by 10.194.93.234 with SMTP id cx10mr7229697wjb.140.1478551125901;  Mon, 07 Nov 2016 12:38:45 -0800 (PST)
MIME-Version: 1.0
Received: by 10.28.197.132 with HTTP; Mon, 7 Nov 2016 12:38:44 -0800 (PST)
In-Reply-To: <022901d2391f$928dc660$4001a8c0@gateway.2wire.net>
References:  <86860386-9C2B-4BD5-B457-2A6DA5446CF3@cisco.com> <20161106040849.GB18931@shrubbery.net> <5BD3C90E-CC0E-42D2-9ACD-5787FC75BF0A@cisco.com> <20161106194258.GB5113@pfrc.org>  <20161107102306.GV24817@gir.theapt.org> <022901d2391f$928dc660$4001a8c0@gateway.2wire.net>
From: Brian Dickson 
Date: Mon, 7 Nov 2016 12:38:44 -0800
Message-ID: 
To: "t.petch" 
Content-Type: multipart/alternative; boundary=047d7beb9340a448600540bc0203
Archived-At: 
Cc: IETF IDR , Peter Hessler 
Subject: Re: [Idr] Vendor Defaults (was Re: Review of draft-ietf-large-community-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: Mon, 07 Nov 2016 20:38:49 -0000

--047d7beb9340a448600540bc0203
Content-Type: text/plain; charset=UTF-8

On Mon, Nov 7, 2016 at 9:40 AM, t.petch  wrote:

> ----- Original Message -----
> From: "Peter Hessler" 
> To: 
> Sent: Monday, November 07, 2016 10:23 AM
>
> > In OpenBGPD our default is to propagate communities; normal, extended,
> > and large.
> >
> > We have no intention on changing that default.
> >
> [snip]
> > This is implementation specific, and has nothing to do with the
> > standardization process.
>
> Peter
>
> I think that that is spot on.
>
> Customers will expect consistent behaviour from a supplier (and equally
> should be prepared for change if and when they change supplier).
>
> Of course, it may not always be that straightforward as implementations
> need to interoperate, first and foremost; but if they have been doing
> that, albeit not following the precise specification of a transitive
> attribute, then I think that consistency is what is needed.
>
>
What I think need to be (re-)emphasized, and which is the reason I started
this thread:
Interoperability is an issue, both INTRA-ASN as well as INTER-ASN.

Incremental deployability in a heterogenous environment, of an incremental
method for supporting an existing function, is something that requires
operator control.

So, while defaults matter, knobs to control those behaviors matter more.

Say someone has a network with vendors X, Y, and Z. Say they use RFC1997
communities substantially, and want to deploy LC.

Doing so requires incrementally upgrading some subset of routers, with
several iterations. Some of those upgrades are likely to be "some of X
only", etc.

Without a knob to disable (or possibly enable) propagation of LC, when
doing an upgrade to a version where LC is understood (on a single router),
the behavior will depend entirely on what vendor X's upgraded code does.

I don't consider that sufficiently constrained behavior for an incremental
upgrade. Not having a knob means either "random behavior", or "flag day"
(requiring simultaneous upgrades to all routers of all vendors).

What matters to me, as an operator, is that I can control all my routers,
especially if the default behavior of each router "flavor" differs, and
most especially if that behavior differs across software versions.

Most of the discussion has presumed homogenous ASNs, which is not
universally the case (and in my experience is seldom the case these days.)

The fact that LC will be incrementally deployed alongside 1997, makes the
issue much more significant, IMHO.

Maybe folks from various vendors (including open source implementations)
could chime in on the availability of knobs for changing global (default)
behavior on 1997 and LC, and whether those traditionally have the same
default and/or are controlled by one knob (versus two)?

Brian

--047d7beb9340a448600540bc0203
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Mon, Nov 7, 2016 at 9:40 AM, t.petch <ietfc@btconnect.com&g=
t; wrote:
----- O=
riginal Message -----

From: "Peter Hessler" <=
phessler@theapt.org>

To: <idr@ietf.org>

Sent: Monday, November 07, 2016 10:23 AM


> In OpenBGPD our default is to propagate communities; normal, extended,=


> and large.

>

> We have no intention on changing that default.

>
[snip]

> This is implementation specific, and has nothing to do with the

> standardization process.



Peter



I think that that is spot on.



Customers will expect consistent behaviour from a supplier (and equally

should be prepared for change if and when they change supplier).



Of course, it may not always be that straightforward as implementations

need to interoperate, first and foremost; but if they have been doing

that, albeit not following the precise specification of a transitive

attribute, then I think that consistency is what is needed.



What I think need to be (re-)emphasize=
d, and which is the reason I started this thread:
Interoperabilit=
y is an issue, both INTRA-ASN as well as INTER-ASN.

Incremental deployability in a heterogenous environment, of an incrementa=
l method for supporting an existing function, is something that requires op=
erator control.

So, while defaults matter, knobs t=
o control those behaviors matter more.

Say someone=
 has a network with vendors X, Y, and Z. Say they use RFC1997 communities s=
ubstantially, and want to deploy LC.

Doing so requ=
ires incrementally upgrading some subset of routers, with several iteration=
s. Some of those upgrades are likely to be "some of X only", etc.=


Without a knob to disable (or possibly enable) pr=
opagation of LC, when doing an upgrade to a version where LC is understood =
(on a single router), the behavior will depend entirely on what vendor X=
9;s upgraded code does.

I don't consider that =
sufficiently constrained behavior for an incremental upgrade. Not having a =
knob means either "random behavior", or "flag day" (req=
uiring simultaneous upgrades to all routers of all vendors).

=

What matters to me, as an operator, is that I can control all my=
 routers, especially if the default behavior of each router "flavor&qu=
ot; differs, and most especially if that behavior differs across software v=
ersions.

Most of the discussion has presumed homog=
enous ASNs, which is not universally the case (and in my experience is seld=
om the case these days.)

The fact that LC will be =
incrementally deployed alongside 1997, makes the issue much more significan=
t, IMHO.

Maybe folks from various vendors (includi=
ng open source implementations) could chime in on the availability of knobs=
 for changing global (default) behavior on 1997 and LC, and whether those t=
raditionally have the same default and/or are controlled by one knob (versu=
s two)?

Brian

=C2=A0


--047d7beb9340a448600540bc0203--


From nobody Mon Nov  7 12:46:10 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0D4112998A for ; Mon,  7 Nov 2016 12:46:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level: 
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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 VjktTOjs7OuP for ; Mon,  7 Nov 2016 12:46:07 -0800 (PST)
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 0CD5B12968A for ; Mon,  7 Nov 2016 12:46:07 -0800 (PST)
Received: by mail-wm0-x22a.google.com with SMTP id p190so207515580wmp.1 for ; Mon, 07 Nov 2016 12:46:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=V2Ll2rzDGbyjYAN70xC+7TvfkCaCKa9L+kXGVIsLkT0=; b=0w1RQFaii86HCnhtlHcCxWUqq2FpMlufaLJ4Z1w4c7Euuzz2Ud2fqFH5IlYG+WNTUO Cz8nnhZ2sgdU6W8Gyb2vJZOB8jNGCJcqu2yowhbsl9BwL4OWVtKhG0zNXJN07Ua+9ZMx KNgoZAut76CNTGq/pIPvFb9DLkC124f4N9mc4Z6dw+vzkgHq5/3YB+D9DNkNkLivcSbI yAwkMiWh+DASYJgZWMUDeUMItpqndqspdbLZCrC2mfZfOOAhlVu1FMxd0E/G27LB4SAC DdgCOfYSWGKZNd7IGc/bkC04Tlhx8O+KPudTSgLTmodTZvRTvG+04iUEn37HSZsd8RsT MBTQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=V2Ll2rzDGbyjYAN70xC+7TvfkCaCKa9L+kXGVIsLkT0=; b=jPC4/BYvBWm71DKowoqaT4q1D1djwKEi/IG91KFnxE+MfUxjvsCVojXg/PFd1bXnD+ Wgi+pezfUxXG4Xgf3CyQ95K08y2gYv7Rtt42JTXHjjc/5H/0QV85zHAeFfv313jBKKKg EHYzbpac4A62KRcwJGxOssOpZ1pF0B4XLBRgpLi8zSaHDBUhkbyRwmD5D7THV7MQvgOJ Z8EyzyuMLnE/9HsuV/fv5ftYU++IUk0ssNLq9y34JaUtaXRJTWWVvWjoAZPy81LC2Knd BJwwj+2LvssDtSPkQNT770hPkXMwShbLJPr3k1/SkBBl47V1e0g8dH6QELVGS7DgTZe3 +4pg==
X-Gm-Message-State: ABUngvfyjl94Su5lbHqdyRUxWYXfXwr3oXtj60hQ0BucPi4k9qUxekoG2eJTftbsTz0gLzAzg1bz17WfDtxoIA==
X-Received: by 10.194.103.5 with SMTP id fs5mr6156024wjb.227.1478551565619; Mon, 07 Nov 2016 12:46:05 -0800 (PST)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.80.137.69 with HTTP; Mon, 7 Nov 2016 12:46:04 -0800 (PST)
In-Reply-To: 
References:  <86860386-9C2B-4BD5-B457-2A6DA5446CF3@cisco.com> <20161106040849.GB18931@shrubbery.net> <5BD3C90E-CC0E-42D2-9ACD-5787FC75BF0A@cisco.com> <20161106194258.GB5113@pfrc.org>  <20161107102306.GV24817@gir.theapt.org> <022901d2391f$928dc660$4001a8c0@gateway.2wire.net> 
From: Robert Raszuk 
Date: Mon, 7 Nov 2016 21:46:04 +0100
X-Google-Sender-Auth: oPtxgHHSg7rB41MLHm7bggbIJHQ
Message-ID: 
To: Brian Dickson 
Content-Type: multipart/alternative; boundary=047d7bf10ad6d9da230540bc1c75
Archived-At: 
Cc: IETF IDR , Peter Hessler 
Subject: Re: [Idr] Vendor Defaults (was Re: Review of draft-ietf-large-community-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: Mon, 07 Nov 2016 20:46:08 -0000

--047d7bf10ad6d9da230540bc1c75
Content-Type: text/plain; charset=UTF-8

Hi Brian,

> Maybe folks from various vendors (including open source implementations)
> could chime in on the availability of knobs for changing global (default)

Maybe we should move this thread to GROW maybe not, but since you started
the pool here I would add a question to indicate by any implementation that
if it drops an attribute (as it is not enabled to be sent over a session)
would it log it in syslog and if so with what error level. The worse
operationally are silent drops in any control plane.

r.

--047d7bf10ad6d9da230540bc1c75
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Brian,

&=
gt; Maybe folks from various vendors (including open source implementations=
)=C2=A0
> could chime in on the availability of knobs =
for changing global (default)=C2=A0

=

Maybe we should move this thread to GROW maybe not, but since you sta=
rted the pool here I would add a question to indicate by any implementation=
 that if it drops an attribute (as it is not enabled to be sent over a sess=
ion) would it log it in syslog and if so with what error level. The worse o=
perationally are silent drops in any control plane.

=

r.



--047d7bf10ad6d9da230540bc1c75--


From nobody Mon Nov  7 13:06:22 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A070E12956F for ; Mon,  7 Nov 2016 13:06:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Q-nTqFoBU8E for ; Mon,  7 Nov 2016 13:06:20 -0800 (PST)
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 C669D129431 for ; Mon,  7 Nov 2016 13:06:19 -0800 (PST)
Received: by mail-wm0-x22a.google.com with SMTP id a197so207814294wmd.0 for ; Mon, 07 Nov 2016 13:06:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CJ7kYXYR9GA65XcDL9s8urGC97BTOzCsAP5RG6PBrYw=; b=gd36IJDz4wJru4O0EkYNrSsQrcK6FY/clOXyCjqlNX1tOEZpx7NSjuCuFBBGgsqhVr yuC/j5MdBTinsIuQyDL/ulNabRzjcA5iTAnPgted2nR42+paqVddDaE0DKfxJ81BFIPd 73vOzGLVi45ln2PMNWkNf/o6AQwtZOrH3hsYZVzDmN7NmSSAAIEYHnCRNk+qld6QoR4/ syupyU2eA1zVJWWUDMnOMB7l4E7qDKbfQwHlkSFvjnFJa1V8lDYvM1GEbbzTqi1um8NC E2A2MIZGBpXf7HVdPC5eYVl4HecwuGNEAyOfeUeyZWcJ7HbFZt0bTqSs5eVNtHwdQSK9 f0DA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CJ7kYXYR9GA65XcDL9s8urGC97BTOzCsAP5RG6PBrYw=; b=bV16DNGBmBQRL4vyTIaIii0CvtkBQYR4a+vxoNhTZLnpjlY+fsxd12tcW1qnlMu07A 1hvKzXp5JId1doW2LLEbuDeNVW4189jk/IWwV7UYty0x58K9qCJQ/fvFg51C0lJoU+5f /0Ih5GMoslEIfthJ8GyJS3GB92rpJAWUi6cDzmzBzO3r8zLYGCaEqqjeaNtwaQ3mWDEd dIlw1fCbnbV0RUU09sRmsyXcllxsmDi2gPcDjoowI2ppCx6jtVmWX/KAHKIOSdv7obJ5 Ybkisg0/xMyLQzTg63wOgEjv2HbJlraPGj3slyTaTArJ7CKPkReYEMejBeaItqSJC8wj r27w==
X-Gm-Message-State: ABUngvd+JRO4/3+M2tKxIRZ2xJtuPC2Y/IpLwqHIQTjQEWGmeuvtPghmgqcbUKONcNPDntVozmxaGudpDZl/wA==
X-Received: by 10.194.78.195 with SMTP id d3mr6979989wjx.96.1478552778336; Mon, 07 Nov 2016 13:06:18 -0800 (PST)
MIME-Version: 1.0
Received: by 10.28.197.132 with HTTP; Mon, 7 Nov 2016 13:06:17 -0800 (PST)
In-Reply-To: <20161107202554.GI62252@shrubbery.net>
References:  <86860386-9C2B-4BD5-B457-2A6DA5446CF3@cisco.com> <17E646EF-4633-423B-9AC4-B53D49C90632@gmail.com> <6CAFC026-6102-42BF-97FA-779457D84ECE@cisco.com>    <96108A84-8016-4A24-8D9D-C08F65D07572@gmail.com> <20161107202554.GI62252@shrubbery.net>
From: Brian Dickson 
Date: Mon, 7 Nov 2016 13:06:17 -0800
Message-ID: 
To: heasley 
Content-Type: multipart/alternative; boundary=047d7bfd001022902b0540bc6536
Archived-At: 
Cc: "idr@ietf.org" , Robert Raszuk 
Subject: Re: [Idr] Vendor Defaults (was Re: Review of draft-ietf-large-community-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: Mon, 07 Nov 2016 21:06:21 -0000

--047d7bfd001022902b0540bc6536
Content-Type: text/plain; charset=UTF-8

On Mon, Nov 7, 2016 at 12:25 PM, heasley  wrote:

> Sun, Nov 06, 2016 at 07:46:10PM -0800, Brian Dickson:
> > > On Nov 6, 2016, at 4:12 PM, Robert Raszuk  wrote:
>
>
> > It might be the case that initial deployment could incorporate 16-bit
> ASNs in 32-bit fields, including private ASNs.
>
> What?  is there a case where a 16bit ASN doesnt fit in 32bits?
>

No, what I am saying is, it might be the case that the very first LCs seen
are "65501:3356:0" (which, in my hypothetical scenario, are transliterated
RFC1997 communities, understood by both AS2914 and AS49544)

The difference being:

   - RFC1997 propagation might be affected by some implementations of
   RFC1997 defaulting to "do not send" and router configurations relying on
   that default.
   - LC propagation, if not consistent with RFC1997 propagation, might
   result in the LC community going where the RFC1997 has not gone, and might
   result in changes to routing.



> > 20 years of  RFC1997. All with default off. 20 years of industry
> consolidation, staff turnover, undocumented implementations.
>
> 20 years in that implementation...
>

... which should not REQUIRE implementation/configuration changes
overnight, IMHO.

>
> > Assuming that no migration will occur, isn't helpful. Changing the
> default behavior across such migration is the risk.
> >
> > Having the same behavior for large guarantees zero incremental risk,
> which is why I am advocating for it.
>
> given a BGP topology of AS1 - AS2 - AS3, where AS1 & 3 recognize LCs and
> AS1 sends LC 3:n:n to affect their local-pref (or whatever), this will
> potentially break when AS2 updates to an o/s that recognizes LCs.
> surprise!
>

There are 3 ASNs involved, and two peering connections.
Does AS2 already do RFC1997?
Does AS1 send RFC1997 communities to AS2?
Is the reason AS1 isn't sending RFC1997, that AS3 is a 32-bit ASN?
Presumably AS2 doesn't send RFC1997 to AS3 either, for the same 32-bit ASN
reason.

I think the scenarios boil down to:

   - AS2 already does RFC1997, and does its upgrade with LC as part of the
   plan.
      - I would expect AS2 to monitor for LCs in their BGP updates before
      upgrading, and use an upgrade config that passes LCs.
   - AS2 does not do RFC1997, in which case expecting it to do LCs is not
   entirely reasonable on the part of AS1.
      - AS1 should discuss their expectations with AS2, and encourage them
      to do LCs AND RFC1997.

In other words, in neither case should the breakage be a surprise; it
either should not break, or should be expected to break.

I'm not advocating for breakage, obviously, and am a big advocate of both
RFC1997 and LC.

But, vendor code isn't best place to try to get communities propagated -
the contracts or peering agreements between ASNs is a much better place.

Brian

--047d7bfd001022902b0540bc6536
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Mon, Nov 7, 2016 at 12:25 PM, heasley <heas@shrubbery.net>=
 wrote:
Sun, Nov 06, 2016 at 07:46=
:10PM -0800, Brian Dickson:

> > On Nov 6, 2016, at 4:12 PM, Robert Raszuk <robert@raszuk.net> wrote:




> It might be the case that initial deployment could incorporate 16-bit =
ASNs in 32-bit fields, including private ASNs.



What?=C2=A0 is there a case where a 16bit ASN doesnt fit in 32bits?<=
br>

No, what I am saying is, it might be th=
e case that the very first LCs seen are "65501:3356:0" (which, in=
 my hypothetical scenario, are transliterated RFC1997 communities, understo=
od by both AS2914 and AS49544)

The difference bein=
g:
  • RFC1997 propagation might be affected by some implemen=
tations of RFC1997 defaulting to "do not send" and router configu=
rations relying on that default.
  • LC propagation, if not consist=
ent with RFC1997 propagation, might result in the LC community going where =
the RFC1997 has not gone, and might result in changes to routing.
=

=C2=A0

> 20 years of=C2=A0 RFC1997. All with default off. 20 years of industry =
consolidation, staff turnover, undocumented implementations.



20 years in that implementation...

... which should not REQUIRE implementation/configuration changes overni=
ght, IMHO.=C2=A0



> Assuming that no migration will occur, isn't helpful. Changing the=
 default behavior across such migration is the risk.

>

> Having the same behavior for large guarantees zero incremental risk, w=
hich is why I am advocating for it.



given a BGP topology of AS1 - AS2 - AS3, where AS1 & 3 recognize=
 LCs and

AS1 sends LC 3:n:n to affect their local-pref (or whatever), this will

potentially break when AS2 updates to an o/s that recognizes LCs.=C2=A0 sur=
prise!

There are 3 ASNs involved, and t=
wo peering connections.
Does AS2 already do RFC1997?
Do=
es AS1 send RFC1997 communities to AS2?
Is the reason AS1 isn'=
;t sending RFC1997, that AS3 is a 32-bit ASN?
Presumably AS2 does=
n't send RFC1997 to AS3 either, for the same 32-bit ASN reason.

I think the scenarios boil down to:
  • AS2=
 already does RFC1997, and does its upgrade with LC as part of the plan.
    • I would expect AS2 to monitor for LCs in their BGP updates before=
 upgrading, and use an upgrade config that passes LCs.
  • AS2 doe=
s not do RFC1997, in which case expecting it to do LCs is not entirely reas=
onable on the part of AS1.=C2=A0
    • AS1 should discuss their expec=
tations with AS2, and encourage them to do LCs AND RFC1997.
<=
div>In other words, in neither case should the breakage be a surprise; it e=
ither should not break, or should be expected to break.
I'm not advocating for breakage, obviously, and am a big ad=
vocate of both RFC1997 and LC.=C2=A0

But, vendor c=
ode isn't best place to try to get communities propagated - the contrac=
ts or peering agreements between ASNs is a much better place.
Brian



--047d7bfd001022902b0540bc6536--


From nobody Mon Nov  7 13:09:43 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 144FE129465 for ; Mon,  7 Nov 2016 13:09:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lmhpjT-61CCP for ; Mon,  7 Nov 2016 13:09:40 -0800 (PST)
Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c: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 6B20E12943C for ; Mon,  7 Nov 2016 13:09:40 -0800 (PST)
Received: by mail-wm0-x22f.google.com with SMTP id c184so31638146wmd.0 for ; Mon, 07 Nov 2016 13:09:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EEFBld2NojvsnXquZwgP8iXfEmV5qdYwl8sJ3Jda/Sg=; b=Ohg9IddulsGSKt3Lbn/jjqE/bE6mBZo7ZOYFno1h8kKdV42463nQ9VvEKCe3xvLOau eq1panVCqEKj3acxKRc0233nXs2CnssZBrrMv6izv+Wr93jA12kk+kVsPXOUIiv74/Yv O8KU9g53kzmzMiPQk/9Dr+DZyYnYNuDCV6dIDsdh36HzHnYH22fx9IJe5hrlX9xP/qzY oceEEgF3SI3SYXgJFdgNwIIY+8wk4R4vne5WbHYHxQNIXFuPuhMCUsJNhgBVso8vmRaJ LpaWXwS3Yw5mbkaz1dGTJ6PZ67S/xvfa8jREoCXlvrQAp3MgMIceg9TwzfVRpy4jQ2h4 JzEw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EEFBld2NojvsnXquZwgP8iXfEmV5qdYwl8sJ3Jda/Sg=; b=l9ODOGdsLa5zLS+olRCHpWYLhwYFk7xc/NmxpT0QI38ErtnIRVYB9ZnxDH9kn/h2C+ KioyNo0YoSKJnfmkZzoS2jMrNqJsyVOodhPX3m/k0/KHePW/quQkuMW4hONkP+IPS7ok r8ZQzND2IuFKIPNqK6V3Lp1gvfIHcIXlhCr6pV0fZcRrciOjjad3A0O8tan0+GxKwKDW hfw8BFHkRcTXdfKLIwhc27mZ9dpeT9jxZ1udpO/MOhBS6pBoxOLAwgeGwysk2ViEf8Jl B6gWAOEdBgk3QWStMALgKJGLjegCHMmFnDK5IUOSV9Noy5YerExRhoCRWqGnEUUONyiY WmOw==
X-Gm-Message-State: ABUngvc9GT2DceLX3n9iImmPG1ME2DHbfVyLjWFM3qwvo+CJcabABGI7gQGvyBK8HvYq2TEOt/gIoRzyWTNBeA==
X-Received: by 10.28.213.74 with SMTP id m71mr12639459wmg.39.1478552978968; Mon, 07 Nov 2016 13:09:38 -0800 (PST)
MIME-Version: 1.0
Received: by 10.28.197.132 with HTTP; Mon, 7 Nov 2016 13:09:37 -0800 (PST)
In-Reply-To: 
References:  <86860386-9C2B-4BD5-B457-2A6DA5446CF3@cisco.com> <20161106040849.GB18931@shrubbery.net> <5BD3C90E-CC0E-42D2-9ACD-5787FC75BF0A@cisco.com> <20161106194258.GB5113@pfrc.org>  <20161107102306.GV24817@gir.theapt.org> <022901d2391f$928dc660$4001a8c0@gateway.2wire.net>  
From: Brian Dickson 
Date: Mon, 7 Nov 2016 13:09:37 -0800
Message-ID: 
To: Robert Raszuk 
Content-Type: multipart/alternative; boundary=001a1146977017d76d0540bc71eb
Archived-At: 
Cc: IETF IDR , Peter Hessler 
Subject: Re: [Idr] Vendor Defaults (was Re: Review of draft-ietf-large-community-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: Mon, 07 Nov 2016 21:09:42 -0000

--001a1146977017d76d0540bc71eb
Content-Type: text/plain; charset=UTF-8

On Mon, Nov 7, 2016 at 12:46 PM, Robert Raszuk  wrote:

> Hi Brian,
>
> > Maybe folks from various vendors (including open source implementations)
> > could chime in on the availability of knobs for changing global
> (default)
>
> Maybe we should move this thread to GROW maybe not, but since you started
> the pool here I would add a question to indicate by any implementation that
> if it drops an attribute (as it is not enabled to be sent over a session)
> would it log it in syslog and if so with what error level. The worse
> operationally are silent drops in any control plane.
>
>
>
I would definitely be in favor of including that detail.

Also, I am not aware of whether attribute-sending is flagged in the
capabilities negotiation of an OPEN. That would, IMHO, be a better place to
signal attribute passing vs dropping, rather than on each UPDATE. What do
vendors think of that (or is it already done?)?

Brian

--001a1146977017d76d0540bc71eb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Mon, Nov 7, 2016 at 12:46 PM, Robert Raszuk <robert@raszuk.net&=
gt; wrote:
Hi Brian,
>=
 Maybe folks from various vendors (including open source implementations)=
=C2=A0
> could chime in on the availability of knobs for changing global (defa=
ult)=C2=A0

Maybe we should move this thread to GROW maybe not, but sinc=
e you started the pool here I would add a question to indicate by any imple=
mentation that if it drops an attribute (as it is not enabled to be sent ov=
er a session) would it log it in syslog and if so with what error level. Th=
e worse operationally are silent drops in any control plane.



I would definitely be in favor of including that=
 detail.

Also, I am not aware of whether attribute=
-sending is flagged in the capabilities negotiation of an OPEN. That would,=
 IMHO, be a better place to signal attribute passing vs dropping, rather th=
an on each UPDATE. What do vendors think of that (or is it already done?)?<=
/div>

Brian=C2=A0


--001a1146977017d76d0540bc71eb--


From nobody Mon Nov  7 13:17:48 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 414A612956F for ; Mon,  7 Nov 2016 13:17:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level: 
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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 tXfMKJ7dmO5j for ; Mon,  7 Nov 2016 13:17:45 -0800 (PST)
Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8EFD129715 for ; Mon,  7 Nov 2016 13:17:44 -0800 (PST)
Received: by mail-wm0-x22e.google.com with SMTP id t79so202535569wmt.0 for ; Mon, 07 Nov 2016 13:17:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=/BwTLWsrvvaueV3lDXBIs1horRb5bdM/Je4ny16pGbQ=; b=VFZTj4NgQMobk3jPVTVB7nn1/Kc7gZGdYIntny8+4D6INw+VbsujlGTnMUrErUOLwk naY2vNVV1mteh+x9A1hyOJX7+NGmK01UkvM1ZOI6r0Nyf4mTb+qTxpv9yQcA11Zgs/Hx Kq/hlJ+OTSJzwUIplWQlBid6DjcS103QbURDXcEylVGjKXByKRvHjhFJnXsrh+Nbkrxi JNAFWgMon4FdxJd1i8S2b03LtfPankucevx5YIA7k03b92zlb/kCTL2LNsFqKPJq8AB5 eY7Za3k76A0aJ1jz57zvi0Lmrp9V3+Bz86B+oeFUCWS9MhO2Gi1vG2IrnNF2NHGL+y6F P4vg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=/BwTLWsrvvaueV3lDXBIs1horRb5bdM/Je4ny16pGbQ=; b=QRpxNDcFYwz/Ma6en0K2+GKxl2ephMTKZMIZF5AWEJxYSHbII2B7eTnAn5aafs++mm mO7DMumlVoZEgPeZBWRA02mpJV466G597QSJVqKybb8LiGSU6YbQFgAx1h6M79AjEcna moup/M6QlrSF7BmnkdKawmPb80FAopydaFBRf6EBI4MtkSk5o189F90zeE+ltl7X2XRZ rsEXaG/wdEaJLvFydg/hsEdIr2aqYTpP6Bl4HFNL7kgn9jn1qbHDGrOIfSfgBX9BlIko DFG+K9GlwyxB8947ZlC9nkW2OZNw+UY4Vnwl6tJs9aWShQRsC6yCCZIdN3qJJ3TSrchw uNsw==
X-Gm-Message-State: ABUngvepTZ4+RDC/sIo7D45km9ZjyiS8BPbZt5Z00FcbAW4F8P7694cDtP2o2r22od3QbeQ8NWU5x0TTMaslMw==
X-Received: by 10.28.17.213 with SMTP id 204mr2046970wmr.17.1478553463075; Mon, 07 Nov 2016 13:17:43 -0800 (PST)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.80.137.69 with HTTP; Mon, 7 Nov 2016 13:17:41 -0800 (PST)
In-Reply-To: 
References:  <86860386-9C2B-4BD5-B457-2A6DA5446CF3@cisco.com> <20161106040849.GB18931@shrubbery.net> <5BD3C90E-CC0E-42D2-9ACD-5787FC75BF0A@cisco.com> <20161106194258.GB5113@pfrc.org>  <20161107102306.GV24817@gir.theapt.org> <022901d2391f$928dc660$4001a8c0@gateway.2wire.net>   
From: Robert Raszuk 
Date: Mon, 7 Nov 2016 22:17:41 +0100
X-Google-Sender-Auth: _5yKWqbVAhOnJjicidmeH-4K2j0
Message-ID: 
To: Brian Dickson 
Content-Type: multipart/alternative; boundary=001a1145aa78f2c4070540bc8d78
Archived-At: 
Cc: IETF IDR , Peter Hessler 
Subject: Re: [Idr] Vendor Defaults (was Re: Review of draft-ietf-large-community-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: Mon, 07 Nov 2016 21:17:47 -0000

--001a1145aa78f2c4070540bc8d78
Content-Type: text/plain; charset=UTF-8

Hi Brian,

> Also, I am not aware of whether attribute-sending is flagged in the
capabilities
> negotiation of an OPEN. That would, IMHO, be a better place to signal
> attribute passing vs dropping, rather than on each UPDATE. What do
> vendors think of that (or is it already done?)?

Large Community does not require capability negotiation hence its support
or not
will not be signaled in OPEN msg.

Assuming that you are proposing a new capability which would indicate if a
given
transitive attribute it to be propagated or not based on local
configuration that
while may be nice idea requires dynamic capabilities which as you very well
know is for number of years and after number of attempts to support it
nowhere.

Rgs,
R.

PS. Perhaps the right place for this would be Operational Message which
Rob, Dave
and myself proposed few years back but due to lack of support the idea died
in spite
of already being a WG supported draft ...

https://tools.ietf.org/html/draft-ietf-idr-operational-message-00





On Mon, Nov 7, 2016 at 10:09 PM, Brian Dickson <
brian.peter.dickson@gmail.com> wrote:

>
>
> On Mon, Nov 7, 2016 at 12:46 PM, Robert Raszuk  wrote:
>
>> Hi Brian,
>>
>> > Maybe folks from various vendors (including open source
>> implementations)
>> > could chime in on the availability of knobs for changing global
>> (default)
>>
>> Maybe we should move this thread to GROW maybe not, but since you started
>> the pool here I would add a question to indicate by any implementation that
>> if it drops an attribute (as it is not enabled to be sent over a session)
>> would it log it in syslog and if so with what error level. The worse
>> operationally are silent drops in any control plane.
>>
>>
>>
> I would definitely be in favor of including that detail.
>
> Also, I am not aware of whether attribute-sending is flagged in the
> capabilities negotiation of an OPEN. That would, IMHO, be a better place to
> signal attribute passing vs dropping, rather than on each UPDATE. What do
> vendors think of that (or is it already done?)?
>
> Brian
>

--001a1145aa78f2c4070540bc8d78
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Brian,

=

>=C2=A0Als=
o, I am not aware of whether attribute-sending is flagged in the capabiliti=
es=C2=A0
> attribute passing vs dropping, rather than on each UPDATE. What do=C2=
=A0
>=
; vendors think of that (or is it already done?)?

Large Community does not require capability negotiation henc=
e its support or not=C2=A0
=
will n=
ot be signaled=C2=A0in OPEN msg.=C2=A0

Assuming that you are =
proposing a new capability which would indicate if a given=C2=A0
<=
span style=3D"font-size:12.8px">transitive=C2=A0attribute it to be propagated or not based on local configurat=
ion that=C2=A0
while may be=C2=
=A0nice idea requires dynamic capab=
ilities which as you very well=C2=A0
know is for number=C2=A0of year=
s and after number of attempts to support it=C2=A0nowhere.=C2=A0
Rgs,
R.

PS. Perhaps the right place for this would be Operational Message=
 which Rob, Dave=C2=A0
and myself proposed few years back but due to lack of suppo=
rt the idea died in spite=C2=A0
of already being a WG supported draft ...<=
/span>

=
https://tools.ietf.org/html/draft-ietf-=
idr-operational-message-00




On Mon, Nov 7, 2016 at 10:09 PM, Brian Dic=
kson <brian.peter.dickson@gmail.com> wrote:
<=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex">


On Mon, Nov 7, 2016 at 1=
2:46 PM, Robert Raszuk <robert@raszuk.net> wrote:
Hi Brian,

> Maybe folks from various vendors (incl=
uding open source implementations)=C2=A0
> could chime in on the availability =
of knobs for changing global (default)=C2=A0

Maybe we should move thi=
s thread to GROW maybe not, but since you started the pool here I would add=
 a question to indicate by any implementation that if it drops an attribute=
 (as it is not enabled to be sent over a session) would it log it in syslog=
 and if so with what error level. The worse operationally are silent drops =
in any control plane.



I would definitely be in favor of including that detail.

Also, I am not aware of whether attribute-sending is =
flagged in the capabilities negotiation of an OPEN. That would, IMHO, be a =
better place to signal attribute passing vs dropping, rather than on each U=
PDATE. What do vendors think of that (or is it already done?)?

Brian=C2=A0





--001a1145aa78f2c4070540bc8d78--


From nobody Mon Nov  7 14:54:20 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F22D0129B22 for ; Mon,  7 Nov 2016 14:54:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.699
X-Spam-Level: 
X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, 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 duVCURZ6VEMW for ; Mon,  7 Nov 2016 14:54:17 -0800 (PST)
Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DBE4129B52 for ; Mon,  7 Nov 2016 14:54:17 -0800 (PST)
Received: by guelah.shrubbery.net (Postfix, from userid 7053) id 223D37C8D8; Mon,  7 Nov 2016 22:54:17 +0000 (UTC)
Date: Mon, 7 Nov 2016 22:54:17 +0000
From: heasley 
To: Brian Dickson 
Message-ID: <20161107225417.GA67860@shrubbery.net>
References:  <86860386-9C2B-4BD5-B457-2A6DA5446CF3@cisco.com> <17E646EF-4633-423B-9AC4-B53D49C90632@gmail.com> <6CAFC026-6102-42BF-97FA-779457D84ECE@cisco.com>    <96108A84-8016-4A24-8D9D-C08F65D07572@gmail.com> <20161107202554.GI62252@shrubbery.net> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc
X-note: live free, or die!
X-homer: i just want to have a beer while i am caring.
X-Claimation: an engineer needs a manager like a fish needs a bicycle
X-reality: only YOU can put an end to the embarrassment that is Tom Cruise
User-Agent: Mutt/1.6.1 (2016-04-27)
Archived-At: 
Cc: heasley , "idr@ietf.org" , Robert Raszuk 
Subject: Re: [Idr] Vendor Defaults (was Re: Review of draft-ietf-large-community-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: Mon, 07 Nov 2016 22:54:19 -0000

Mon, Nov 07, 2016 at 01:06:17PM -0800, Brian Dickson:
> On Mon, Nov 7, 2016 at 12:25 PM, heasley  wrote:
> > Sun, Nov 06, 2016 at 07:46:10PM -0800, Brian Dickson:
> > > > On Nov 6, 2016, at 4:12 PM, Robert Raszuk  wrote:
> > > It might be the case that initial deployment could incorporate 16-bit
> > ASNs in 32-bit fields, including private ASNs.
> >
> > What?  is there a case where a 16bit ASN doesnt fit in 32bits?
> 
> No, what I am saying is, it might be the case that the very first LCs seen
> are "65501:3356:0" (which, in my hypothetical scenario, are transliterated
> RFC1997 communities, understood by both AS2914 and AS49544)
> 
> The difference being:
> 
>    - RFC1997 propagation might be affected by some implementations of
>    RFC1997 defaulting to "do not send" and router configurations relying on
>    that default.
>    - LC propagation, if not consistent with RFC1997 propagation, might
>    result in the LC community going where the RFC1997 has not gone, and might
>    result in changes to routing.

Everyone involved would have to actively change their policy to add that
LC and to take action on it.

And, why would an operator expend the effort to use 1997 communities in LCs
with an extra 0 field?  Leave the 1997s alone, add LCs specified to take
advantage of LCs (no over-loading, AS4) and stop taking action on and/or
marking routes with 1997s after some transition period.

> > > 20 years of  RFC1997. All with default off. 20 years of industry
> > consolidation, staff turnover, undocumented implementations.
> >
> > 20 years in that implementation...
> 
> ... which should not REQUIRE implementation/configuration changes
> overnight, IMHO.

it doesnt; LCs dont exist yet.

> > > Assuming that no migration will occur, isn't helpful. Changing the
> > default behavior across such migration is the risk.
> > >
> > > Having the same behavior for large guarantees zero incremental risk,
> > which is why I am advocating for it.
> >
> > given a BGP topology of AS1 - AS2 - AS3, where AS1 & 3 recognize LCs and
> > AS1 sends LC 3:n:n to affect their local-pref (or whatever), this will
> > potentially break when AS2 updates to an o/s that recognizes LCs.
> > surprise!
> 
> There are 3 ASNs involved, and two peering connections.
> Does AS2 already do RFC1997?

whatever - that's irrelevant in my PoV; 1997 & LC are not the same.

> Does AS1 send RFC1997 communities to AS2?

irrelevant.

> Is the reason AS1 isn't sending RFC1997, that AS3 is a 32-bit ASN?

maybe.  maybe AS3 never supported 1997.  maybe they have transitioned
away from 1997.  maybe its an "action" community with a "target" ASN
(AS3:prependonce:AS4).  or AS3 marks their routes with LC in some manner
that interests AS1, such the rt's region origin and AS4's path between two
regions is routinely congested.

> Presumably AS2 doesn't send RFC1997 to AS3 either, for the same 32-bit ASN
> reason.

irrelevant.

fact is that it would work until AS2 upgrades, unless AS2 adds the config
to disable to default filtering - that is assuming that they are clueful
enough to do so.  that's an element of surprise.  vs. AS2 deciding that
they will start using LCs and discovering that their customers & transits
are already using them.

> I think the scenarios boil down to:
> 
>    - AS2 already does RFC1997, and does its upgrade with LC as part of the
>    plan.
>       - I would expect AS2 to monitor for LCs in their BGP updates before
>       upgrading, and use an upgrade config that passes LCs.
>    - AS2 does not do RFC1997, in which case expecting it to do LCs is not
>    entirely reasonable on the part of AS1.
>       - AS1 should discuss their expectations with AS2, and encourage them
>       to do LCs AND RFC1997.
> 
> In other words, in neither case should the breakage be a surprise; it
> either should not break, or should be expected to break.
> 
> I'm not advocating for breakage, obviously, and am a big advocate of both
> RFC1997 and LC.
> 
> But, vendor code isn't best place to try to get communities propagated -
> the contracts or peering agreements between ASNs is a much better place.
> 
> Brian


From nobody Mon Nov  7 15:30:07 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E643A129450 for ; Mon,  7 Nov 2016 15:30:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level: 
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=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=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 3D0eJJmPtnnH for ; Mon,  7 Nov 2016 15:30:05 -0800 (PST)
Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 033CF129443 for ; Mon,  7 Nov 2016 15:30:05 -0800 (PST)
Received: by mail-wm0-x229.google.com with SMTP id p190so213941663wmp.1 for ; Mon, 07 Nov 2016 15:30:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=wq2PkAtecVgt/nTvyY6ih4TYvluUNLaVJm3HsCOJD9s=; b=f6Y5o1arKZiLVbT+5n/zc8scBpGI6ASe46KtDLnxLMGQPejDXa57PCf/XefIvEVJcD 2BRxjHBWU3lFCE4dEy+ssjCrKhxJFzDEFOdbRbdBfet6reXbMK7+bw9BMpAiPc4VF1Yu VNffn7prfn8iQDXQ7qSRtc2wRYW4/nAxHQatGnAPwuoXZgJ6U+4mwViyinxb2mlAfwdf Ug8voi7y/90vdaZK65A+hzP5QOQ9uZiEadFY89RWslP7OLcXM9kLfUc/6DUi5bFqeJYt GNLpAzgkz2tzFrTMX3hj3qabjz0nGIdb4oK5Xi5kAuQo0xNraG6D7Znqq5PckWCRyxdJ RifA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=wq2PkAtecVgt/nTvyY6ih4TYvluUNLaVJm3HsCOJD9s=; b=MAyc4BGmrm0jap7JObpuYePW3sL1HBLIC/ybF1LGp/ZXWjP2/YzCCoUpmwnAZVJ74l 8dXLNumpft0yGovNUBIcY7RNtKeHhOkojyJt+CXSbZ68GAlx8N+KnIvzg8tGl7RjZsNb cxkKM6+aCu5Jcj5Zmnh6V08XUNeH9Azmzkt83yR5db2wDi/ePVJW1JzqaKdOvpTFGz1Z LoET/5wa0VX2sL0h+UyNHVOWj/GSzxX64ABo3EDHWhwh6Yf1V8uDIwORMkWAKbXJYjPN G84LjHgxmevvnYz1XhXC2nh//p55j9hqH1mltIzp8a88Pnk0a63+EDisuR4A03oRcwNG SR9g==
X-Gm-Message-State: ABUngvdisCKhtXGvlALowXHWCE2JHOcNMU8Fg5dEOFevu2w5HWb3FJ933sVYNsdenA0EfVwRcAEDnFJT49l9TA==
X-Received: by 10.28.185.203 with SMTP id j194mr8886192wmf.73.1478561403435; Mon, 07 Nov 2016 15:30:03 -0800 (PST)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.80.137.69 with HTTP; Mon, 7 Nov 2016 15:30:01 -0800 (PST)
In-Reply-To: <20161107225417.GA67860@shrubbery.net>
References:  <86860386-9C2B-4BD5-B457-2A6DA5446CF3@cisco.com> <17E646EF-4633-423B-9AC4-B53D49C90632@gmail.com> <6CAFC026-6102-42BF-97FA-779457D84ECE@cisco.com>    <96108A84-8016-4A24-8D9D-C08F65D07572@gmail.com> <20161107202554.GI62252@shrubbery.net>  <20161107225417.GA67860@shrubbery.net>
From: Robert Raszuk 
Date: Tue, 8 Nov 2016 00:30:01 +0100
X-Google-Sender-Auth: vtZP9lN5fj52XiSBVzr3wEKjjrY
Message-ID: 
To: heasley 
Content-Type: multipart/alternative; boundary=001a1148ebca3b1d230540be6799
Archived-At: 
Cc: "idr@ietf.org" 
Subject: Re: [Idr] Vendor Defaults (was Re: Review of draft-ietf-large-community-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: Mon, 07 Nov 2016 23:30:07 -0000

--001a1148ebca3b1d230540be6799
Content-Type: text/plain; charset=UTF-8

FWIW Heas is extremely right here.

> 1997 & LC are not the same.

Indeed and those who claim to say so in order to progress Large under the
cover of RFC1997 are just wrong (sorry).

We are defining a new world wide functionality in BGP and we should take
all what it takes to do it right.

If some folks want parity with RFC1997 Large should be 4:4 no more. It is
not 4:4 and it is a new attribute so whoever in their policy decides to use
new attribute to modify routes he/she better understands what are the
consequences.

While this may be taken as "distraction" or attempt to "derail" large I am
spending my private time on this list to make the best for BGP as protocol
realizing how hard it is to deploy new BGP extension worldwide.

And if so progressing large should be able to accommodate operators voice
captured in this document:

https://tools.ietf.org/html/draft-ietf-idr-registered-wide-bgp-communities-02

... and we are just few millimeters far from addressing 90% of those use
cases if we would not take a selfish view and turn large into 4:4:4:4.

With respect to all,
Robert.


On Mon, Nov 7, 2016 at 11:54 PM, heasley  wrote:

> Mon, Nov 07, 2016 at 01:06:17PM -0800, Brian Dickson:
> > On Mon, Nov 7, 2016 at 12:25 PM, heasley  wrote:
> > > Sun, Nov 06, 2016 at 07:46:10PM -0800, Brian Dickson:
> > > > > On Nov 6, 2016, at 4:12 PM, Robert Raszuk 
> wrote:
> > > > It might be the case that initial deployment could incorporate 16-bit
> > > ASNs in 32-bit fields, including private ASNs.
> > >
> > > What?  is there a case where a 16bit ASN doesnt fit in 32bits?
> >
> > No, what I am saying is, it might be the case that the very first LCs
> seen
> > are "65501:3356:0" (which, in my hypothetical scenario, are
> transliterated
> > RFC1997 communities, understood by both AS2914 and AS49544)
> >
> > The difference being:
> >
> >    - RFC1997 propagation might be affected by some implementations of
> >    RFC1997 defaulting to "do not send" and router configurations relying
> on
> >    that default.
> >    - LC propagation, if not consistent with RFC1997 propagation, might
> >    result in the LC community going where the RFC1997 has not gone, and
> might
> >    result in changes to routing.
>
> Everyone involved would have to actively change their policy to add that
> LC and to take action on it.
>
> And, why would an operator expend the effort to use 1997 communities in LCs
> with an extra 0 field?  Leave the 1997s alone, add LCs specified to take
> advantage of LCs (no over-loading, AS4) and stop taking action on and/or
> marking routes with 1997s after some transition period.
>
> > > > 20 years of  RFC1997. All with default off. 20 years of industry
> > > consolidation, staff turnover, undocumented implementations.
> > >
> > > 20 years in that implementation...
> >
> > ... which should not REQUIRE implementation/configuration changes
> > overnight, IMHO.
>
> it doesnt; LCs dont exist yet.
>
> > > > Assuming that no migration will occur, isn't helpful. Changing the
> > > default behavior across such migration is the risk.
> > > >
> > > > Having the same behavior for large guarantees zero incremental risk,
> > > which is why I am advocating for it.
> > >
> > > given a BGP topology of AS1 - AS2 - AS3, where AS1 & 3 recognize LCs
> and
> > > AS1 sends LC 3:n:n to affect their local-pref (or whatever), this will
> > > potentially break when AS2 updates to an o/s that recognizes LCs.
> > > surprise!
> >
> > There are 3 ASNs involved, and two peering connections.
> > Does AS2 already do RFC1997?
>
> whatever - that's irrelevant in my PoV; 1997 & LC are not the same.
>
> > Does AS1 send RFC1997 communities to AS2?
>
> irrelevant.
>
> > Is the reason AS1 isn't sending RFC1997, that AS3 is a 32-bit ASN?
>
> maybe.  maybe AS3 never supported 1997.  maybe they have transitioned
> away from 1997.  maybe its an "action" community with a "target" ASN
> (AS3:prependonce:AS4).  or AS3 marks their routes with LC in some manner
> that interests AS1, such the rt's region origin and AS4's path between two
> regions is routinely congested.
>
> > Presumably AS2 doesn't send RFC1997 to AS3 either, for the same 32-bit
> ASN
> > reason.
>
> irrelevant.
>
> fact is that it would work until AS2 upgrades, unless AS2 adds the config
> to disable to default filtering - that is assuming that they are clueful
> enough to do so.  that's an element of surprise.  vs. AS2 deciding that
> they will start using LCs and discovering that their customers & transits
> are already using them.
>
> > I think the scenarios boil down to:
> >
> >    - AS2 already does RFC1997, and does its upgrade with LC as part of
> the
> >    plan.
> >       - I would expect AS2 to monitor for LCs in their BGP updates before
> >       upgrading, and use an upgrade config that passes LCs.
> >    - AS2 does not do RFC1997, in which case expecting it to do LCs is not
> >    entirely reasonable on the part of AS1.
> >       - AS1 should discuss their expectations with AS2, and encourage
> them
> >       to do LCs AND RFC1997.
> >
> > In other words, in neither case should the breakage be a surprise; it
> > either should not break, or should be expected to break.
> >
> > I'm not advocating for breakage, obviously, and am a big advocate of both
> > RFC1997 and LC.
> >
> > But, vendor code isn't best place to try to get communities propagated -
> > the contracts or peering agreements between ASNs is a much better place.
> >
> > Brian
>

--001a1148ebca3b1d230540be6799
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



FWIW Heas =
is extremely right here.=C2=A0

>=
 1997 & LC are not the same.

Indeed and those who claim to say so in order to progress Large under th=
e cover of RFC1997 are just wrong (sorry).=C2=A0

We are defining a new world wide functionality in BGP and we=
 should take all what it takes to do it right.=C2=A0

=

If some folks want parity with RFC1997 Large should be 4=
:4 no more. It is not 4:4 and it is a new attribute so whoever in their pol=
icy decides to use new attribute to modify routes he/she better understands=
 what are the consequences.=C2=A0

While this may be t=
aken as "distraction" or attempt to "derail" large I am=
 spending my private time on this list to make the best for BGP as protocol=
 realizing how hard it is to deploy new BGP extension worldwide.=C2=A0

<=
/span>
A=
nd if so progressing large should be able to accommodate operators voice ca=
ptured in this document:=C2=A0

https://tools.ietf.org/htm=
l/draft-ietf-idr-registered-wide-bgp-communities-02

... and we are j=
ust few millimeters=C2=A0far from addressing 90% of those use cases if we w=
ould not take a selfish view and turn large into 4:4:4:4.=C2=A0

With r=
espect to all,
Robert.


On Mon, Nov 7, 2016 at 11:54 PM, heasley <heas@shrubbery.net>=
 wrote:
Mon, Nov 07, 2016 at 01:06=
:17PM -0800, Brian Dickson:

> On Mon, Nov 7, 2016 at 12:25 PM, heasley <heas@shrubbery.net> wrote:

> > Sun, Nov 06, 2016 at 07:46:10PM -0800, Brian Dickson:

> > > > On Nov 6, 2016, at 4:12 PM, Robert Raszuk <robert@raszuk.net> wrote:

> > > It might be the case that initial deployment could incorpora=
te 16-bit

> > ASNs in 32-bit fields, including private ASNs.

> >

> > What?=C2=A0 is there a case where a 16bit ASN doesnt fit in 32bit=
s?

>

> No, what I am saying is, it might be the case that the very first LCs =
seen

> are "65501:3356:0" (which, in my hypothetical scenario, are =
transliterated

> RFC1997 communities, understood by both AS2914 and AS49544)

>

> The difference being:

>

>=C2=A0 =C2=A0 - RFC1997 propagation might be affected by some im=
plementations of

>=C2=A0 =C2=A0 RFC1997 defaulting to "do not send&=
quot; and router configurations relying on

>=C2=A0 =C2=A0 that default.

>=C2=A0 =C2=A0 - LC propagation, if not consistent with RFC1997 p=
ropagation, might

>=C2=A0 =C2=A0 result in the LC community going where t=
he RFC1997 has not gone, and might

>=C2=A0 =C2=A0 result in changes to routing.



Everyone involved would have to actively change their policy to add =
that

LC and to take action on it.



And, why would an operator expend the effort to use 1997 communities in LCs=


with an extra 0 field?=C2=A0 Leave the 1997s alone, add LCs specified to ta=
ke

advantage of LCs (no over-loading, AS4) and stop taking action on and/or
marking routes with 1997s after some transition period.



> > > 20 years of=C2=A0 RFC1997. All with default off. 20 years of=
 industry

> > consolidation, staff turnover, undocumented implementations.

> >

> > 20 years in that implementation...

>

> ... which should not REQUIRE implementation/configuration changes

> overnight, IMHO.



it doesnt; LCs dont exist yet.



> > > Assuming that no migration will occur, isn't helpful. Ch=
anging the

> > default behavior across such migration is the risk.

> > >

> > > Having the same behavior for large guarantees zero increment=
al risk,

> > which is why I am advocating for it.

> >

> > given a BGP topology of AS1 - AS2 - AS3, where AS1 & 3 recogn=
ize LCs and

> > AS1 sends LC 3:n:n to affect their local-pref (or whatever), this=
 will

> > potentially break when AS2 updates to an o/s that recognizes LCs.=


> > surprise!

>

> There are 3 ASNs involved, and two peering connections.

> Does AS2 already do RFC1997?



whatever - that's irrelevant in my PoV; 1997 & LC are not th=
e same.



> Does AS1 send RFC1997 communities to AS2?



irrelevant.



> Is the reason AS1 isn't sending RFC1997, that AS3 is a 32-bit ASN?=




maybe.=C2=A0 maybe AS3 never supported 1997.=C2=A0 maybe they have t=
ransitioned

away from 1997.=C2=A0 maybe its an "action" community with a &quo=
t;target" ASN

(AS3:prependonce:AS4).=C2=A0 or AS3 marks their routes with LC in some mann=
er

that interests AS1, such the rt's region origin and AS4's path betw=
een two

regions is routinely congested.



> Presumably AS2 doesn't send RFC1997 to AS3 either, for the same 32=
-bit ASN

> reason.



irrelevant.



fact is that it would work until AS2 upgrades, unless AS2 adds the config
to disable to default filtering - that is assuming that they are clueful
enough to do so.=C2=A0 that's an element of surprise.=C2=A0 vs. AS2 dec=
iding that

they will start using LCs and discovering that their customers & transi=
ts

are already using them.



> I think the scenarios boil down to:

>

>=C2=A0 =C2=A0 - AS2 already does RFC1997, and does its upgrade w=
ith LC as part of the

>=C2=A0 =C2=A0 plan.

>=C2=A0 =C2=A0 =C2=A0 =C2=A0- I would expect AS2 to monitor for LCs in t=
heir BGP updates before

>=C2=A0 =C2=A0 =C2=A0 =C2=A0upgrading, and use an upgra=
de config that passes LCs.

>=C2=A0 =C2=A0 - AS2 does not do RFC1997, in which case expecting=
 it to do LCs is not

>=C2=A0 =C2=A0 entirely reasonable on the part of AS1.<=
br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0- AS1 should discuss their expectatio=
ns with AS2, and encourage them


>=C2=A0 =C2=A0 =C2=A0 =C2=A0to d=
o LCs AND RFC1997.

>

> In other words, in neither case should the breakage be a surprise; it<=
br>
> either should not break, or should be expected to break.

>

> I'm not advocating for breakage, obviously, and am a big advocate =
of both

> RFC1997 and LC.

>

> But, vendor code isn't best place to try to get communities propag=
ated -

> the contracts or peering agreements between ASNs is a much better plac=
e.

>

> Brian





--001a1148ebca3b1d230540be6799--


From nobody Mon Nov  7 17:33:57 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D22061294D6 for ; Mon,  7 Nov 2016 17:33:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cpzZPShuLggt for ; Mon,  7 Nov 2016 17:33:54 -0800 (PST)
Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA8F5127071 for ; Mon,  7 Nov 2016 17:33:53 -0800 (PST)
Received: by mail-wm0-x22e.google.com with SMTP id f82so152308483wmf.1 for ; Mon, 07 Nov 2016 17:33:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Gmq/R45r6X5gsUrKXYOEu4IgmOp1WfhHz6Qtmf5p6sM=; b=m9VcCG9JOo7520IaoaZbESO6LhTQfQbuk4sHVoXemR88GVJXZFzQiP4oLwcjb8Z8m5 0OlNdqgQKU2CiaSLW3Ja/jPw7sWGZjY1USYG69b45Otg9rsmFnmOVYXYZLPXR6RebTgG P6fRZ2YAqJ+wuweQ0qgNW6yoXVxXe+7EcQI/mPWE+a/xuJO9rXlKEJhktq9f5vRRsFmk 0BkgF0CGPNvAWD4GnCmehy6OOrIwXoK36+4RBy4pFk+PCcbomxsmIOHnIno3fjFvWyQb OfksN2Xx8pQfWFR/29ajJV+59YxVdDpnsoGEspo2ZQvOLc0XtMwWetrRLM86wWYpY6Sz cD+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Gmq/R45r6X5gsUrKXYOEu4IgmOp1WfhHz6Qtmf5p6sM=; b=ij9TjDdolShF4frdm84OZXyQmSoK0QwkpAi+TSo48f0gihV1ZpNjwzu81Qf5Yz8oDJ 7ZyUK3A6uNRPX/+fre1e8YghUbz3w0EMSdSavA2pJgTzpCpreM3Mj3Qv+Ja7PZKC04XR w+CPwwuSjozseDTRyewrBZPLXaC1uPOADq36aZ67+D2P+2w/eX9HrT7H9Q4Am82KwMjZ 54QELKKGF7m730qSI9U9Kqby5TfR5VPL1tk4BUZKFXDs2S/tMQ7tIjqnL750tYAqdLR8 3PO2mlOJ91Fhq24GGC3PMOMJZ40TkE+vClBKyeNNkd9IyOGzt/h0pJ0wFWR7+NXUwpXJ BlFQ==
X-Gm-Message-State: ABUngvddL8q6jTKxBa+bMYjGKHKjSEGMcUou3YWw5aqmf7Few9EI9f5mrIv6NXf5O0se9wd6ragJdoOoRKOSDg==
X-Received: by 10.194.78.195 with SMTP id d3mr7682221wjx.96.1478568832381; Mon, 07 Nov 2016 17:33:52 -0800 (PST)
MIME-Version: 1.0
Received: by 10.28.197.132 with HTTP; Mon, 7 Nov 2016 17:33:50 -0800 (PST)
In-Reply-To: 
References:  <86860386-9C2B-4BD5-B457-2A6DA5446CF3@cisco.com> <17E646EF-4633-423B-9AC4-B53D49C90632@gmail.com> <6CAFC026-6102-42BF-97FA-779457D84ECE@cisco.com>    <96108A84-8016-4A24-8D9D-C08F65D07572@gmail.com> <20161107202554.GI62252@shrubbery.net>  <20161107225417.GA67860@shrubbery.net> 
From: Brian Dickson 
Date: Mon, 7 Nov 2016 17:33:50 -0800
Message-ID: 
To: Robert Raszuk 
Content-Type: multipart/alternative; boundary=047d7bfd001007ba270540c0225f
Archived-At: 
Cc: heasley , "idr@ietf.org" 
Subject: Re: [Idr] Vendor Defaults (was Re: Review of draft-ietf-large-community-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, 08 Nov 2016 01:33:57 -0000

--047d7bfd001007ba270540c0225f
Content-Type: text/plain; charset=UTF-8

On Mon, Nov 7, 2016 at 3:30 PM, Robert Raszuk  wrote:

>
> FWIW Heas is extremely right here.
>
> > 1997 & LC are not the same.
>
> Indeed and those who claim to say so in order to progress Large under the
> cover of RFC1997 are just wrong (sorry).
>

RFC1997 is 32 bits, used as "16-bit ASN" : "local".

LC is 96 bits, defined as "Global Administrator (aka 32-bit
ASN)":"local1":"local2".

LC provides more than 4:4 (which would have been the absolute minimum for
parity), and that extra 4 is appreciated and noted.

Upgrading RFC1997 to give parity back to it, would require "2:2:2" or
"2:2:4", and might have been useful 15 years ago, but whatever.
Having 4:4:4 available gives somewhere for RFC1997 to move to, and it can
do so without any collisions.
Global Administrator for 16-bit ASNs works just fine.

Concerning my earlier brief description and explanation of why things like
"65501:2914:0" might be among the first LC values seen:

I think understanding the rationale will be helpful in understanding,
generally, why all operators want/need is "32-bit ASNs and 32-bits of
non-overloaded space to design their own methodology".

So, here goes, again, this time with more words and hopefully clearer logic
and explanations.
(I should have known better than to try to do this using my smartphone.
Apologies for the earlier cryptic explanation.)

The following "table" shows the minimum level of support for doing "generic
communities" across 16-/32-bit ASN:

SRC \ DST  16-bit 32-bit
16-bit       1997   LC
32-bit     1997/LC* LC

The following table shows an "upgrade" path for 16-bit ASNs peering with
16-bit ASNs, who want parity with LC:

SRC \ DST  16-bit 32-bit
16-bit        LC    LC
32-bit        LC    LC

(* NB: RFC1997 was really only feasible for use between 16-bit ASNs, or
where the destination ASN's "action" target was a third-party 16-bit ASN.)

1997 and LC are not "the same". 1997 is the predecessor, and a subset, of
LC, in the same sense that 16 bit ASNs are the predecessors of, and a
subset of, 32-bit ASNs.

Here's what the operator community wants:

   - 32-bit ASNs and an extra 32 bits to play with.


Here's what the operator community wants the Global Administrator field to
mean:

   - The ASN of the entity defining the values and semantics for Local1 and
   Local2.


Here's what the operator wants the meanings of Local1 and Local2 to be:

   - 


This is not new functionality; it is parity with RFC1997, with more bits
(32 more bits, after expanding the second 16 bits of 1997 to 32 bits).

The semantics of RFC1997 were tortured to death, often by abusing the
private ASN values, which had the potential for causing communities
collisions.

It should be obvious that the availability of LC provides the means to end
this overloading, by providing enough room in Local1:Local2 to handle
any/all use cases that any 16-bit ASN requires.
(I say 16-bit ASN here, because, by definition, they are the only
globally-unique ASNs that were able to make use of RFC1997, without
squatting.)

Moving from RFC1997->LC give the potential to do more -- but to state the
obvious, does not require one to do more, or at least not in any specific
timeframe.

Suppose I am a 16-bit ASN, and I was using private ASNs in order to handle
use cases that exceeded the overall capacity of the lower 16-bits of
RFC1997.
So, I had two sets of RFC1997 communities:
MY_ASN:xxxx
yyyy:zzzz
(for many private ASNs yyyy)

The very first thing I would want to do is to get away from private-ASN
RFC1997 values, and I would deploy LC for those:
MY_ASN:yyyy:zzzz
I might also want to provide:
yyyy:zzzz:0
to ensure less-capable customers are able to make the right thing happen,
even if that LC is likely to collide with anyone else using it.

But now I am doing both RFC1997 and LC, which complicates my route
processing, and increases my maintenance.
So, I am going to migrate the rest of my RFC1997 communities, by some kind
of transliteration:
MY_ASN:0:xxxx
 or
MY_ASN:xxxx:0

Once, and only after, I have all my customers migrated, I can (and would)
decommission RFC1997 entirely (in my network, that is).

Now I can begin improving the capabilities offered, and migrate off of
overloaded xxxx's and yyyy:zzzz values.

HOWEVER, and this is really important, LC gives me the right NOT to do so,
or to do anything I want, no matter how foolish it is, so long I use
MY_ASN:Local1:Local2.

As an operator, I am not asking the IETF-IDR WG to do anything other than
give me the tools to do whatever I want, however I want.

This gives me independence from vendor lock-in, and the ability to switch
vendors without pain or delay.

This gives me the ability to operate a multi-vendor network, and to
interoperate with other operators' networks regardless of vendor.

This gives me the ability to acquire another operators' network, and
integrate it without significant problems

In this regard, this is precisely WHY the operator community only wants
parity with RFC1997.

The limited capabilities offered by vendors for fancy things was a FEATURE
of RFC1997, not a bug.

We had kind of hoped you (collective you, meaning all the vendors) had
learned this lesson over the last 20 years...


> We are defining a new world wide functionality in BGP and we should take
> all what it takes to do it right.
>

Give us MY_ASN:Local1:Local2.

That is what it takes to do it right. Anything else would be an abject
failure.

(We're fine if you insist on calling it Global Administrator:Local1:Local2.)


>
> If some folks want parity with RFC1997 Large should be 4:4 no more.
>

Wanting parity doesn't mean wanting _only_ parity. You can build a house
"to code" by building substantially better than "code". ("Code" means
minimum code.)


> It is not 4:4 and it is a new attribute so
>

(IMHO this whole "it is a new attribute" is a non sequitur...)


> whoever in their policy decides to use new attribute to modify routes
> he/she better understands what are the consequences.
>

I fail to see how that is any different than the implicit rules for RFC1997.


>
> While this may be taken as "distraction" or attempt to "derail" large I am
> spending my private time on this list to make the best for BGP as protocol
> realizing how hard it is to deploy new BGP extension worldwide.
>
> And if so progressing large should be able to accommodate operators voice
> captured in this document:
>

Irrelevant to LC...

"Have fun storming the castle!"

The massive -wide- thing fails to understand the fundamentals of operators'
reality:

   - Avoiding vendor lock-in
   - Avoiding vendor implementation delay
   - Avoiding vendor heterogenous version issues
   - Avoiding heterogenous-vendor networks issues
   - Speed to deployment of differentiating services based on RFC1997 (now
   LC) capabilities
   - One size never fits all
   - Customer size does not correlate to customers' importance to the
   Internet
      - For example, consider the relative number of routers for ICANN,
      IETF, ISOC, etc. versus a regional fast-food chain.
   - The IETF, in the vendor hardware/firmware space, operates so slowly
   that most features are already obsolete by the time they reach full
   standard. Sorry.
      - Large Communities has been the exception that proves the rule.

No offense intended towards anyone, just trying to make the operators'
position and reasoning as clear as possible, to those who aren't or haven't
been.

Sincerely,
Brian

--047d7bfd001007ba270540c0225f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Mon, Nov 7, 2016 at 3:30 PM, Robert Raszuk <robert@raszuk.net&g=
t; wrote:

FWIW Heas is extremely right here.=C2=A0

> 1997 & LC are not the same.

=

Indeed and those w=
ho claim to say so in order to progress Large under the cover of RFC1997 ar=
e just wrong (sorry).=C2=A0

<=
div>RFC1997 is 32 bits, used as "16-bit ASN" : "local".=


LC is 96 bits, defined as "Global Administra=
tor (aka 32-bit ASN)":"local1":"local2".

LC provides more than 4:4 (which would have been the absolu=
te minimum for parity), and that extra 4 is appreciated and noted.

Upgrading RFC1997 to give parity back to it, would require=
 "2:2:2" or "2:2:4", and might have been useful 15 year=
s ago, but whatever.
Having 4:4:4 available gives somewhere for R=
FC1997 to move to, and it can do so without any collisions.
Globa=
l Administrator for 16-bit ASNs works just fine.

C=
oncerning my earlier brief description and explanation of why things like &=
quot;65501:2914:0" might be among the first LC values seen:
=

I think understanding the rationale will be helpful in under=
standing, generally, why all operators want/need is "32-bit ASNs and 3=
2-bits of non-overloaded space to design their own methodology".
=


So, here goes, again, this time with more words and hop=
efully clearer logic and explanations.
(I should have known bette=
r than to try to do this using my smartphone. Apologies for the earlier cry=
ptic explanation.)

The following "table"=
 shows the minimum level of support for doing "generic communities&quo=
t; across 16-/32-bit ASN:

SRC \ DST =C2=A016-bit 32-bit
16-bit =C2=A0 =C2=A0 =C2=A0 1997 =C2=A0 LC
=

32-bit =C2=A0 =C2=A0 1997/LC* LC

The following table shows an "upgrade&q=
uot; path for 16-bit ASNs peering with 16-bit ASNs, who want parity with LC=
:

SRC \ D=
ST =C2=A016-bit 32-bit
16-bit =C2=A0 =C2=A0 =C2=A0 =C2=A0LC =C2=A0 =C2=A0LC
32-bit =C2=A0 =C2=A0 =C2=A0 =C2=A0LC =C2=A0=
 =C2=A0LC

(* NB: RFC1997 was really o=
nly feasible for use between 16-bit ASNs, or where the destination ASN'=
s "action" target was a third-party 16-bit ASN.)

1997 and LC are not "the same". 1997 is the predecessor,=
 and a subset, of LC, in the same sense that 16 bit ASNs are the predecesso=
rs of, and a subset of, 32-bit ASNs.

Here's wh=
at the operator community wants:
  • 32-bit ASNs and an extra=
 32 bits to play with.

Here's wh=
at the operator community wants the Global Administrator field to mean:
  • The ASN of the entity defining the values and semantics for =
Local1 and Local2.

Here's what t=
he operator wants the meanings of Local1 and Local2 to be:
    <whatever the Global Administrator says>
This is not new functionality; it is parity with RFC1997, with=
 more bits (32 more bits, after expanding the second 16 bits of 1997 to 32 =
bits).

The semantics of RFC1997 were tortured to d=
eath, often by abusing the private ASN values, which had the potential for =
causing communities collisions.

It should be obvio=
us that the availability of LC provides the means to end this overloading, =
by providing enough room in Local1:Local2 to handle any/all use cases that =
any 16-bit ASN requires.
(I say 16-bit ASN here, because, by defi=
nition, they are the only globally-unique ASNs that were able to make use o=
f RFC1997, without squatting.)

Moving from RFC1997=
->LC give the potential to do more -- but to state the obvious, does not=
 require one to do more, or at least not in any specific timeframe.

Suppose I am a 16-bit ASN, and I was using private ASNs i=
n order to handle use cases that exceeded the overall capacity of the lower=
 16-bits of RFC1997.
So, I had two sets of RFC1997 communities:
MY_ASN:xxxx
<=
font face=3D"monospace, monospace">yyyy:zzzz=C2=A0
(for ma=
ny private ASNs yyyy)

The very first thing I would=
 want to do is to get away from private-ASN RFC1997 values, and I would dep=
loy LC for those:
MY_ASN:yyyy=
:zzzz
I might also want to provide:
yyyy:zzzz:0
to ensure less-capab=
le customers are able to make the right thing happen, even if that LC is li=
kely to collide with anyone else using it.

But now=
 I am doing both RFC1997 and LC, which complicates my route processing, and=
 increases my maintenance.
So, I am going to migrate the rest of =
my RFC1997 communities, by some kind of transliteration:
MY_ASN:0:xxxx
=C2=A0or
MY_ASN:xxxx:0

<=
/div>
Once, and only after, I have all my customers migrated, I can (an=
d would) decommission RFC1997 entirely (in my network, that is).
=

Now I can begin improving the capabilities offered, and migr=
ate off of overloaded xxxx's and yyyy:zzzz values.

=

HOWEVER, and this is really important, LC gives me the right NOT to do=
 so, or to do anything I want, no matter how foolish it is, so long I use M=
Y_ASN:Local1:Local2.

As an operator, I am not aski=
ng the IETF-IDR WG to do anything other than give me the tools to do whatev=
er I want, however I want.

This gives me independe=
nce from vendor lock-in, and the ability to switch vendors without pain or =
delay.

This gives me the ability to operate a mult=
i-vendor network, and to interoperate with other operators' networks re=
gardless of vendor.

This gives me the ability to a=
cquire another operators' network, and integrate it without significant=
 problems

In this regard, this is precisely WHY th=
e operator community only wants parity with RFC1997.

The limited capabilities offered by vendors for fancy things was a FEATU=
RE of RFC1997, not a bug.

We had kind of hoped you=
 (collective you, meaning all the vendors) had learned this lesson over the=
 last 20 years...


We are defining a new world wide functionality in BGP and we sho=
uld take all what it takes to do it right.=C2=A0

Give us MY_ASN:Local1:Local2.

=

That is what it takes to do it right. Anything else would be an abject=
 failure.

(We're fine if you insist on calling=
 it Global Administrator:Local1:Local2.)
=C2=A0

If some folks want parity with RFC1997 =
Large should be 4:4 no more. 

Wanting parity doesn't mean wanting _only_ parity. You can build =
a house "to code" by building substantially better than "cod=
e". ("Code" means minimum code.)
=C2=A0
It is not 4:4 and it is a new a=
ttribute so
=C2=A0
(IMHO this=
 whole "it is a new attribute" is a non sequitur...)
=
=C2=A0
<=
span style=3D"font-family:arial,sans-serif;font-size:12.8px">whoever in the=
ir policy decides to use new attribute to modify routes he/she better under=
stands what are the consequences.=C2=A0

I fail to see how that is any different than the implicit r=
ules for RFC1997.
=C2=A0

While =
this may be taken as "distraction" or attempt to "derail&quo=
t; large I am spending my private time on this list to make the best for BG=
P as protocol realizing how hard it is to deploy new BGP extension worldwid=
e.=C2=A0

And if so progressing large should b=
e able to accommodate operators voice captured in this document:=C2=A0

Irrelevant to LC...

"Have fun storming the castle!"

The massive -wide- thing fails to understand the fundamentals of o=
perators' reality:
  • Avoiding vendor lock-in
  • Av=
oiding vendor implementation delay
  • Avoiding vendor heterogenous ver=
sion issues
  • Avoiding heterogenous-vendor networks issues
  • Sp=
eed to deployment of differentiating services based on RFC1997 (now LC) cap=
abilities
  • One size never fits all
  • Customer size does not co=
rrelate to customers' importance to the Internet
    • For exampl=
e, consider the relative number of routers for ICANN, IETF, ISOC, etc. vers=
us a regional fast-food chain.
  • The IETF, in the vendor hardwar=
e/firmware space, operates so slowly that most features are already obsolet=
e by the time they reach full standard. Sorry.
    • Large Communitie=
s has been the exception that proves the rule.
No offens=
e intended towards anyone, just trying to make the operators' position =
and reasoning as clear as possible, to those who aren't or haven't =
been.

Sincerely,
Brian
=



--047d7bfd001007ba270540c0225f--


From nobody Mon Nov  7 22:23:11 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 511C1129A59 for ; Mon,  7 Nov 2016 22:23:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.718
X-Spam-Level: 
X-Spam-Status: No, score=-5.718 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, RP_MATCHES_RCVD=-1.497, 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 NDjetJgkekJN for ; Mon,  7 Nov 2016 22:23:08 -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 EDC001294A6 for ; Mon,  7 Nov 2016 22:23:07 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CZX29055; Tue, 08 Nov 2016 06:23:04 +0000 (GMT)
Received: from SZXEMA412-HUB.china.huawei.com (10.82.72.71) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 8 Nov 2016 06:23:02 +0000
Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.175]) by SZXEMA412-HUB.china.huawei.com ([10.82.72.71]) with mapi id 14.03.0235.001; Tue, 8 Nov 2016 14:22:54 +0800
From: Mach Chen 
To: IETF IDR WG 
Thread-Topic: Review of draft-ietf-large-community-06
Thread-Index: AdI5iIlDv+X8FqL1SIqxamyskn+T7w==
Date: Tue, 8 Nov 2016 06:22:54 +0000
Message-ID: 
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.102.135]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.58216F49.0021, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.3.175, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 1174214b812387ac53bd14a5b3e5450b
Archived-At: 
Subject: [Idr] Review of draft-ietf-large-community-06
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, 08 Nov 2016 06:23:10 -0000

Hi,=20

I have review the latest version(06) of this document. The draft is well wr=
itten and is basically ready for publication. I have some minor comments as=
 bellows:

1.=20

Section 2, the first sentence:
"This document creates the Large BGP Communities attribute as an..."

Although RFC1997 also uses "creates", I'd suggest to use "defines" here, it=
 also aligns with the convention of most of the RFCs.


2.
Section 2, the last sentence:
"A receiving speaker SHOULD silently remove duplicate Large BGP
   Communities from a BGP UPDATE message."

IMHO, whether remove the duplicate communities from a BGP UPDATE message is=
 not significant, since the life of the message is over once the message pr=
ocessed. The key point is that the receiving speaker should ignore the dupl=
icate Large BGP Communities.=20

How about:

"A receiving speaker SHOULD silently ignore the duplicate Large BGP
   Communities within a Large BGP Communities attribute. "

3.

In Section 5 says:
   "Operators SHOULD NOT use these Global Administrator
   values."

Later, in Section 6:
"The Large BGP Communities Global Administrator field may contain any
   value, and a Large BGP Communities attribute MUST NOT be considered
   malformed if the Global Administrator field contains an unallocated,
   unassigned or reserved ASN or is set to one of the reserved Large BGP
   Community values defined in Section 5."

The "SHOULD NOT", "may contain any value" and "MUST NOT" seems little bit c=
onfusion and self-contradiction. Since the first sentence is not a specific=
ation to the Large BGP Communities attribute, but just a recommendation to =
the Operators.

How about changing it as:

"It is recommended that operators do not use these Global Administrator val=
ues."=20

Or using some other similar text.

Hope this comments helps!


Best regards,
Mach


From nobody Tue Nov  8 03:00:27 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB90129B65 for ; Tue,  8 Nov 2016 03:00:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.097
X-Spam-Level: 
X-Spam-Status: No, score=-4.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497] 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 XtKo2zNib4oQ for ; Tue,  8 Nov 2016 03:00:23 -0800 (PST)
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 6078512989C for ; Tue,  8 Nov 2016 02:59:41 -0800 (PST)
X-Original-To: idr@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 0EC336065A for ; Tue,  8 Nov 2016 11:59:40 +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 CB6BB602A9; Tue,  8 Nov 2016 11:59:39 +0100 (CET)
Received: by moebius4.space.net (Postfix, from userid 1007) id BC9FE3393F; Tue,  8 Nov 2016 11:59:39 +0100 (CET)
Date: Tue, 8 Nov 2016 11:59:39 +0100
From: Gert Doering 
To: Robert Raszuk 
Message-ID: <20161108105939.GK79185@Space.Net>
References: <17E646EF-4633-423B-9AC4-B53D49C90632@gmail.com> <6CAFC026-6102-42BF-97FA-779457D84ECE@cisco.com>    <96108A84-8016-4A24-8D9D-C08F65D07572@gmail.com> <20161107202554.GI62252@shrubbery.net>  <20161107225417.GA67860@shrubbery.net> 
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.6.1 (2016-04-27)
Archived-At: 
Cc: heasley , "idr@ietf.org" 
Subject: Re: [Idr] Vendor Defaults (was Re: Review of draft-ietf-large-community-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, 08 Nov 2016 11:00:26 -0000

HI,

On Tue, Nov 08, 2016 at 12:30:01AM +0100, Robert Raszuk wrote:
> With respect to all,

I don't think it is.

Throwing wrenches into the process all the time is not respectful to those
that have waited for too-many years for something workable to show up,
and have clearly stated their support for -large already, and multiple
times.

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 Nov  8 03:26:24 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E1401295D4 for ; Tue,  8 Nov 2016 03:26:22 -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, 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 1jlEr9EMac8k for ; Tue,  8 Nov 2016 03:26:20 -0800 (PST)
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 325BE1295A4 for ; Tue,  8 Nov 2016 03:26:20 -0800 (PST)
Received: by mail-wm0-x22a.google.com with SMTP id t79so232748576wmt.0 for ; Tue, 08 Nov 2016 03:26:19 -0800 (PST)
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=ILFFQOT/zbyqQmj0lj9ehNvFQFg/KMWNe8n8NAaW1xE=; b=jzzCRcq+KkVPBhtAhBLUi6CUbAsjmk9mZgdIQADoXEFo4FoQ9xj30Un8Y8BFUUtb3T 7str0DvS/Z/KF4uhRjvIqR8CTmiTHkt/Bg6HkgvpGprICstJfaiUC4sO/HKABU5056Ot 3jfVjDFpXjyep+EfCCQYlNle+V14iVSq1fHBShQ1ywC0SOJmK22Mg52exVzdTDH63awU zBBsnc0k4H6HXVdr5FpUuDL7F/w1Z2Cys2s149kh44TteEHjzd5h1z4bCYji2e3HTvJG b7+PVmdU/DtiYMQOZb2mN1apqSJ6i1GlI2SZ0+/5Ui5X1tBOOkMLc+SffxF3XXGpGJ90 fYGg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=ILFFQOT/zbyqQmj0lj9ehNvFQFg/KMWNe8n8NAaW1xE=; b=iubWaxt3/UXFIhcghOVyQ9egkHSpzgO5MOLux/bidWiAln6dU90VKZjSw58TWIV+GB ATwdPYOk++f+7IpowJijJ3ETa2+O3CfqPPK65aeR1R+hfMNdkaFd4y65QTXvMJcET/XY ULbJH9AUNTFK3yBGtbYvpcbyWPYEObq7tx09j3hAMyfujBvxYpHUngYg81OtKG6svcQw U3cK6N47xDkddOJYNfHDVyvU8FsajdfokrDgroW9RCqe6BBzEnkHS3+LNrGGVWh3N2XZ arWqXHH81dRlxCT9rbO5Hbk0FNr6pX1oYTB68ylsV8AEihB3rTEJReSkMAhnsFj3TbDF 6HYg==
X-Gm-Message-State: ABUngvdQgUT2Tz2NfADHRvPsdtv2j96CrVUYEaOCxCemif49re7KDJF6EfzFh36uDx5WeA==
X-Received: by 10.28.97.139 with SMTP id v133mr15964609wmb.117.1478604378529;  Tue, 08 Nov 2016 03:26:18 -0800 (PST)
Received: from localhost ([2001:67c:208c:10:319f:c386:86c3:ad6a]) by smtp.gmail.com with ESMTPSA id o62sm469213wmg.12.2016.11.08.03.26.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 08 Nov 2016 03:26:17 -0800 (PST)
Date: Tue, 8 Nov 2016 12:26:16 +0100
From: Job Snijders 
To: Mach Chen 
Message-ID: <20161108112616.GD2473@Hanna.local>
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.7.1 (2016-10-04)
Archived-At: 
Cc: IETF IDR WG 
Subject: Re: [Idr] Review of draft-ietf-large-community-06
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, 08 Nov 2016 11:26:22 -0000

On Tue, Nov 08, 2016 at 06:22:54AM +0000, Mach Chen wrote:
> I have review the latest version(06) of this document. The draft is
> well written and is basically ready for publication. I have some minor
> comments as bellows:
> 
> 1. 
> 
> Section 2, the first sentence:
> "This document creates the Large BGP Communities attribute as an..."
> 
> Although RFC1997 also uses "creates", I'd suggest to use "defines"
> here, it also aligns with the convention of most of the RFCs.

Good suggestion, accepted.

> 2.
> Section 2, the last sentence:
> "A receiving speaker SHOULD silently remove duplicate Large BGP
> Communities from a BGP UPDATE message."
> 
> IMHO, whether remove the duplicate communities from a BGP UPDATE
> message is not significant, since the life of the message is over once
> the message processed. The key point is that the receiving speaker
> should ignore the duplicate Large BGP Communities. 
> 
> How about:
> 
> "A receiving speaker SHOULD silently ignore the duplicate Large BGP
>    Communities within a Large BGP Communities attribute. "

After the latest round of review from Geoff Huston and Jakob Heitz the
following text was produced.

The below text is queued to be in -07 of the draft, but -07 can't be
posted yet as we are in the 'cutoff' period before the IETF meeting in
Seoul.

"""
	Duplicate BGP Large Community values SHOULD NOT be transmitted. A
	receiving speaker SHOULD silently remove duplicate BGP Large
	Community values from a BGP Large Community attribute.
"""

I think the above text aligns with your suggestion, right?

> 3.
> 
> In Section 5 says:
>    "Operators SHOULD NOT use these Global Administrator values."
> 
> Later, in Section 6:
> "The Large BGP Communities Global Administrator field may contain any
> value, and a Large BGP Communities attribute MUST NOT be considered
> malformed if the Global Administrator field contains an unallocated,
> unassigned or reserved ASN or is set to one of the reserved Large BGP
> Community values defined in Section 5."
> 
> The "SHOULD NOT", "may contain any value" and "MUST NOT" seems little
> bit confusion and self-contradiction. Since the first sentence is not
> a specification to the Large BGP Communities attribute, but just a
> recommendation to the Operators.
> 
> How about changing it as:
> 
> "It is recommended that operators do not use these Global
> Administrator values." 
> 
> Or using some other similar text.

I don't see the contradiction, its text that gradually narrows down into
specifics for specific audiences. The text in section 5 is for
operators, the text in section 6 is for implementors and bgp developers.
I don't think that removing the 2119 language will increase the clarity.

> Hope this comments helps!

Very much appreciated!

Kind regards,

Job


From nobody Tue Nov  8 03:50:20 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA0EB12941A; Tue,  8 Nov 2016 03:50:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.344
X-Spam-Level: 
X-Spam-Status: No, score=-2.344 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.741, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, T_KAM_HTML_FONT_INVALID=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 U3gtt-HyG4N4; Tue,  8 Nov 2016 03:50:17 -0800 (PST)
Received: from cmccmta3.chinamobile.com (cmccmta3.chinamobile.com [221.176.66.81]) by ietfa.amsl.com (Postfix) with ESMTP id 5C2DF12961A; Tue,  8 Nov 2016 03:50:08 -0800 (PST)
Received: from spf.mail.chinamobile.com (unknown[172.16.121.13]) by rmmx-syy-dmz-app12-12012 (RichMail) with SMTP id 2eec5821bbeabe1-82c96; Tue, 08 Nov 2016 19:50:02 +0800 (CST)
X-RM-TRANSID: 2eec5821bbeabe1-82c96
X-RM-SPAM-FLAG: 00000000
Received: from cmcc-PC (unknown[223.69.29.92]) by rmsmtp-syy-appsvr07-12007 (RichMail) with SMTP id 2ee75821bbe8225-76103; Tue, 08 Nov 2016 19:50:01 +0800 (CST)
X-RM-TRANSID: 2ee75821bbe8225-76103
Date: Tue, 8 Nov 2016 19:51:52 +0800
From: "lizhenqiang@chinamobile.com" 
To: idr , idr-chairs ,  draft-ietf-idr-wide-bgp-communities.all ,  draft-ietf-idr-large-community.all 
X-Priority: 3
X-Has-Attach: no
X-Mailer: Foxmail 7, 2, 7, 164[cn]
Mime-Version: 1.0
Message-ID: <2016110819514874384911@chinamobile.com>
Content-Type: multipart/alternative; boundary="----=_001_NextPart520786431010_=----"
Archived-At: 
Subject: [Idr] Why do we define so many communities for BGP
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, 08 Nov 2016 11:50:19 -0000

This is a multi-part message in MIME format.

------=_001_NextPart520786431010_=----
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: base64

SGVsbG8gYWxsLA0KDQpJIGFtIGNvbmZ1c2VkIGJ5IGxhcmdlIGNvbW11bml0eSBkZWZpbmVkIGlu
IGRyYWZ0LWlldGYtaWRyLWxhcmdlLWNvbW11bml0eSwgd2lkZSBjb21tdW5pdHkgZGVmaW5lZCBp
biBkcmFmdC1pZXRmLWlkci13aWRlLWJncC1jb21tdW5pdGllcywgZXh0ZW5kZWQgY29tbXVuaXR5
IGRlZmluZWQgaW4gUkZDNDM2MCwgY29tbXVuaXR5IGRlZmluZWQgaW4gUkZDMTk5Ny4gV2h5IGRv
IHdlIG5lZWQgc28gbWFueSBraW5kcyBvZiBCR1AgY29tbXVuaXRpZXM/IENhbiB0aGUgbGFyZ2Ug
Y29tbXVuaXR5IGJlIGVuY29kZWQgaW4gdHlwZSAzIHdpZGUgY29tbXVuaXR5PyBUaGFuayB5b3Ug
Zm9yIHlvdXIgZXhwbGFpbmF0aW9uLg0KDQpCZXN0IFJlZ2FyZHMsDQoNCg0KDQpsaXpoZW5xaWFu
Z0BjaGluYW1vYmlsZS5jb20NCg==

------=_001_NextPart520786431010_=----
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<=
body>=0A
Hello all,

I am confuse=
d by large community defined in draft-ietf-idr-large-c=
ommunity, wide community defined in draft-ietf-=
idr-wide-bgp-communities, extended community defined in RFC4360, community=
 defined in RFC1997. Why do we need so many kin=
ds of BGP communities? Can the large community be encoded in type 3 <=
/span>wide community? Thank you for your explaination.

Best Regards,
=0A

<=
/div>
=0A
lizhenqiang@chinamobile.com
<=
/div>=0A
------=_001_NextPart520786431010_=------




From nobody Tue Nov  8 03:58:06 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 101741294B7 for ; Tue,  8 Nov 2016 03:58:05 -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 lJOBSDAESTIt for ; Tue,  8 Nov 2016 03:58:03 -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 18D3F12953B for ; Tue,  8 Nov 2016 03:57:58 -0800 (PST)
X-Envelope-To: idr@ietf.org
Received: from crumpet.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id uA8BvoiW065268 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Nov 2016 11:57:50 GMT (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be crumpet.local
Message-ID: <5821BDBC.7040408@foobar.org>
Date: Tue, 08 Nov 2016 12:57:48 +0100
From: Nick Hilliard 
User-Agent: Postbox 5.0.5 (Macintosh/20161020)
MIME-Version: 1.0
To: "lizhenqiang@chinamobile.com" 
References: <2016110819514874384911@chinamobile.com>
In-Reply-To: <2016110819514874384911@chinamobile.com>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: idr 
Subject: Re: [Idr] Why do we define so many communities for BGP
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, 08 Nov 2016 11:58:05 -0000

lizhenqiang@chinamobile.com wrote:
> I am confused by large community defined
> in draft-ietf-idr-large-community, wide community defined
> in draft-ietf-idr-wide-bgp-communities, extended community defined in
> RFC4360, community defined in RFC1997. Why do we need so many kinds of
> BGP communities? Can the large community be encoded in type 3 wide
> community? Thank you for your explaination.

this issue has already been addressed extensively on the IDR mailing
list.  Please see the list archives:

http://www.ietf.org/mail-archive/web/idr/

The relevant discussion starts on Sep 3 and ended around Sep 27.  There
were over 400 emails in several threads.

Nick


From nobody Tue Nov  8 04:14:35 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7F1B129ACE for ; Tue,  8 Nov 2016 04:14:31 -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, 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 NLBXuUVWAFgS for ; Tue,  8 Nov 2016 04:14:30 -0800 (PST)
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 9888E129B09 for ; Tue,  8 Nov 2016 04:14:04 -0800 (PST)
Received: by mail-wm0-x22b.google.com with SMTP id t79so235259536wmt.0 for ; Tue, 08 Nov 2016 04:14:04 -0800 (PST)
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=691UsepOnz7DZvpJqdjFy4zxA+/swk7NwCik+a/3cAk=; b=j2ZKjM3+/WqK8a6nzrzX+zifDIGEdrtH4WfkmV1wQ0RzR2A1BU8iygy7NchHZDGG1G rN9c25uPIbdxJSRsGk96fXGj4XZsaASXqhxmtJ36PKss9zgBdBjSkwFca6xxDcBH9Faw k8eZfOcxeZL8BoplEE2EKl6lIm+zrqpm4NkHJtir48KvUq7sSQ2GMfFJuu62jF6FSDpB jNWT7mUO3GgnIQ8mGXYVfvrmmahcBQOTFDMb3fVhHdvc3Qq9zCqe38nsEjqGGA2y0qVp nd8DQe33m49gVk6w2CgV7WDr2gG7GCuKgRPOfpTF7sfeW07pDA5dpqrvuolvO4bDae4+ lfNA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=691UsepOnz7DZvpJqdjFy4zxA+/swk7NwCik+a/3cAk=; b=kooCNIgFms6Cx7oSgnu9BM6LgfdQB/4gZam7gI6cNoNdUiyZWoua3PYi+IbHfSZk0I GBiyXfjwmwj7NNETLpba/9IKN2aAPwfOi/qPQuEPexBZr4pNCpDosoEFBZLiwvNNzrvG uSbMXftQpIFP6V3NC63Gk2/GWsKNiXdN3cTVde0TYxcSAFzaVcAUMR+88oVsHFE5YgED Lngbacxyx7Sf8wVdieKQTtE9IpiOz5qNIuqO7RKd9fbqy5kk3R41bGUTqxC4iOT3tc7O eo9rPZZDG5a5jR3DenUnX+r0hSTMf0MDTiQ0RGeimXck5aIU73ZAiaG0SeuunDzrktx/ NkPA==
X-Gm-Message-State: ABUngveiMfd7VjUq15O+QBmGF9Dyb7M6Im4w+/B9nVk9DEmJF71UplJm7GqiMub8G0SEuA==
X-Received: by 10.194.235.34 with SMTP id uj2mr9613831wjc.144.1478607242822; Tue, 08 Nov 2016 04:14:02 -0800 (PST)
Received: from localhost ([2001:67c:208c:10:319f:c386:86c3:ad6a]) by smtp.gmail.com with ESMTPSA id i10sm36802769wjd.15.2016.11.08.04.14.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 08 Nov 2016 04:14:01 -0800 (PST)
Date: Tue, 8 Nov 2016 13:14:00 +0100
From: Job Snijders 
To: "lizhenqiang@chinamobile.com" 
Message-ID: <20161108121400.GF2473@Hanna.local>
References: <2016110819514874384911@chinamobile.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <2016110819514874384911@chinamobile.com>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.7.1 (2016-10-04)
Archived-At: 
Cc: idr 
Subject: Re: [Idr] Why do we define so many communities for BGP
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, 08 Nov 2016 12:14:32 -0000

Dear,

On Tue, Nov 08, 2016 at 07:51:52PM +0800, lizhenqiang@chinamobile.com wrote:
> I am confused by large community defined in
> draft-ietf-idr-large-community, wide community defined in
> draft-ietf-idr-wide-bgp-communities, extended community defined in
> RFC4360, community defined in RFC1997. Why do we need so many kinds of
> BGP communities?

It is healthy for the IETF that ideas can compete with each other.

Without competing drafts, the IETF would suffer from a anti-pattern
where someone (metaphorically) takes a cookie, licks it and puts it back
on the cookie tray, essentially preventing anyone else from having it,
but not eating it by himself or herself.

This anti-pattern can be often seen within volunteer communities when
discussing a certain issue or an improvement. Someone says "I've already
done draft on this topic,". This would prevent others from working on
the feature as there is already someone who started working on it. If
it's not followed up on by this person, it's essentially a dead project.
Nobody else touches it, but nothing real gets done.

Regarding RFC4360 - it has been documented that RFC4360 communities are
unsuitable, this is described as following in the draft:

    """Since the adoption of four-octet ASNs [RFC6793], the BGP
    Communities attribute can no longer accommodate the above encoding,
    as a two- octet word cannot fit a four-octet ASN.  The BGP Extended
    Communities attribute [RFC4360] is also unsuitable.  The six-octet
    length of the Extended Community value precludes the common
    operational practise of encoding four-octet ASNs in both the Global
    Administrator and the Local Administrator sub-fields."""

> Can the large community be encoded in type 3 wide community?

No. There was disagreement on the transivity behaviourisms between
various parties involved. And in the end, there is no reason the two
technologies can't co-exist.

I want to conclude with an emphasis on the fact that the Large BGP
Communities effort has running code, lots of it. Please take a look
here: http://largebgpcommunities.net/implementations/

You can see that not only the BGP implementations have taken on to
support Large BGP Communities, but that the entire ecosystem is being
upgraded to work with large communities: tcpdump, wireshark, pmacct,
pgbpp, zebra-dump-parser, mrtparse, and the list is growing weekly.

Perhaps the following saying is applicable?

兩鳥在林ä¸å¦‚一鳥在手

Kind regards,

Job


From nobody Tue Nov  8 07:14:26 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 574A1129781; Tue,  8 Nov 2016 07:14:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.399
X-Spam-Level: 
X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, 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 72phC3vd7Q8X; Tue,  8 Nov 2016 07:14:19 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id B6A681296D6; Tue,  8 Nov 2016 07:14:18 -0800 (PST)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 3E6341E337; Tue,  8 Nov 2016 10:17:01 -0500 (EST)
Date: Tue, 8 Nov 2016 10:17:01 -0500
From: Jeffrey Haas 
To: "lizhenqiang@chinamobile.com" 
Message-ID: <20161108151701.GA23018@pfrc.org>
References: <2016110819514874384911@chinamobile.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2016110819514874384911@chinamobile.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: 
Cc: idr , "draft-ietf-idr-large-community.all" , "draft-ietf-idr-wide-bgp-communities.all" , idr-chairs 
Subject: Re: [Idr] Why do we define so many communities for BGP
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, 08 Nov 2016 15:14:25 -0000

[Removing individual draft aliases.]

On Tue, Nov 08, 2016 at 07:51:52PM +0800, lizhenqiang@chinamobile.com wrote:
> I am confused by large community defined in draft-ietf-idr-large-community, wide community defined in draft-ietf-idr-wide-bgp-communities, extended community defined in RFC4360, community defined in RFC1997. Why do we need so many kinds of BGP communities? Can the large community be encoded in type 3 wide community? Thank you for your explaination.

With specific regard to version wide communities draft -03, as part of
discussion with the large communities authors on various encoding options,
-03 was issued to provide suitable talking points about how various
behaviors could be accomplished under a common header.  As Job noted, the
fundamental differences in the proposals resulted in large communities not
utilizing the common header.

Wide communities was not really intended to be a generic 1997 replacement
and is intended to cover different goals.  We will be restoring the -02
common header format so Huawei's prototype is again conformant and other
prototypes will utilize that format.

The Type 2 wide community which covered the 4:4 will similarly be removed
since its functionality is covered by large comms.

----

With regard to the more general question, routing marking mechanisms
continue to vary in format mostly to cover differing use cases.  Extended
communities, for example, were originally deployed primarily for BGP VPN use
cases.  They've proven flexible enough to cover similar abstract marking for
a number of other applications, although as Job noted the 4:4 case wasn't
able to fit into that format.

RFC 1997 communities proved to be a good marking mechanism for generic
applications over the years.  For single-state marking, the well known
communities fit well into that.  Large communities covered the general need
to expand the ability to fit AS numbers in a 1997 style marking mechanism
for 4-byte ASes.  As you've also noticed, those authors also added an
additional field expanding the scope of 1997 communities to add the
flexibility to add another "parameter".

Wide communities is intended to cover more "intent-based" route marking.

As a fundamental CS observation, it is understood that all marking
mechanisms that have scoped namespaces can be collapsed into a smaller
number of equivalence classes.  This is effectively how 1997 community
policy has been implemented over the years, with the mapping of
functionality in those ECs present in a service provider's published
community policy.  However, equivalence classes make operational work more
difficult since it removes more natural human and machine readable versions
of the policy elements.  It's this property that has encouraged a
diversification in marking mechanisms.

-- Jeff


From nobody Tue Nov  8 07:19:55 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD05F1293EE for ; Tue,  8 Nov 2016 07:19:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.399
X-Spam-Level: 
X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, 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 raCpgk-zmn_X for ; Tue,  8 Nov 2016 07:19:51 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id E087B12948B for ; Tue,  8 Nov 2016 07:19:51 -0800 (PST)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 6C4A51E337; Tue,  8 Nov 2016 10:22:34 -0500 (EST)
Date: Tue, 8 Nov 2016 10:22:34 -0500
From: Jeffrey Haas 
To: idr@ietf.org
Message-ID: <20161108152234.GB23018@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] Requested WG state change on draft-ietf-idr-as4octet-extcomm-generic-subtype
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, 08 Nov 2016 15:19:53 -0000

Chairs,

The authors of the Generic Subtype for BGP Four-octet AS specific extended
community draft, draft-ietf-idr-as4octet-extcomm-generic-subtype, would like
to request a WG state change to "Dead WG Document".  The functionality
intended to be covered by this feature has been supplanted in a better
fashion by BGP Large Communities.

-- Jeff 


From nobody Tue Nov  8 09:02:45 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24DAB129619 for ; Tue,  8 Nov 2016 09:02:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.018
X-Spam-Level: 
X-Spam-Status: No, score=-16.018 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=-1.497, 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 LKSh5Elytr4k for ; Tue,  8 Nov 2016 09:02:43 -0800 (PST)
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 21E7912956C for ; Tue,  8 Nov 2016 09:02:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2204; q=dns/txt; s=iport; t=1478624562; x=1479834162; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=KyKxdE2xqd8+oQWr+3R/5P1waxDelRDdBsO3JFEXiwc=; b=dEQVQsnpl6+8nMQuQW0p29aHr8Lof8up4MmvXXxeidEJCsLSKOn+ruaV chWEoQT1Ok3xQ5P6tw0P35Pmwai3fd9eDC+cPWwt09W7+n6yhim6T+KAo eBQR01KVyBaSKqOnfyUNYl2jn8X/HzPw7twyi2TESG4Tu+mkW8dwT1QjH E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAQD1AyJY/5BdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgy8BAQEBAR+BV405lwWUU4IIhiQCgg8/FAECAQEBAQEBAWIohGE?= =?us-ascii?q?BAQEDATotEgULAgEIGB4QMiUBAQQOBRQFiDsItHKLSgEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBARyGPoF9glqESIMxgi8Fmi8BiUCHB4FujiaHMoV+hAUBHjd6hSpyhH4?= =?us-ascii?q?GgjYBAQE?=
X-IronPort-AV: E=Sophos;i="5.31,462,1473120000"; d="scan'208";a="344095925"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Nov 2016 17:02:41 +0000
Received: from XCH-ALN-012.cisco.com (xch-aln-012.cisco.com [173.36.7.22]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id uA8H2f0c003428 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 8 Nov 2016 17:02:41 GMT
Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-012.cisco.com (173.36.7.22) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 8 Nov 2016 11:02:40 -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; Tue, 8 Nov 2016 11:02:40 -0600
From: "Jakob Heitz (jheitz)" 
To: Job Snijders 
Thread-Topic: [Idr] Review of draft-ietf-large-community-06
Thread-Index: AdI5iIlDv+X8FqL1SIqxamyskn+T7wAXKyIA///5aAI=
Date: Tue, 8 Nov 2016 17:02:40 +0000
Message-ID: <658B78AB-70F9-43CB-B2FA-2A14ACC6A273@cisco.com>
References: ,  <20161108112616.GD2473@Hanna.local>
In-Reply-To: <20161108112616.GD2473@Hanna.local>
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: 
Cc: IETF IDR WG 
Subject: Re: [Idr] Review of draft-ietf-large-community-06
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, 08 Nov 2016 17:02:44 -0000

> On Nov 8, 2016, at 3:26 AM, Job Snijders  wrote:
>=20
>> On Tue, Nov 08, 2016 at 06:22:54AM +0000, Mach Chen wrote:
>>=20
>> Section 2, the last sentence:
>> "A receiving speaker SHOULD silently remove duplicate Large BGP
>> Communities from a BGP UPDATE message."
>>=20
>> IMHO, whether remove the duplicate communities from a BGP UPDATE
>> message is not significant, since the life of the message is over once
>> the message processed.

That's not what happens. After a route is originated, it passes through man=
y BGP speakers and typically ends up in most routing tables on earth. Each =
speaker that sees the route may or may not interpret all the communities an=
d may or may not propagate the communities. However, any BGP speaker that r=
eceives a community attribute SHOULD remove duplicate communities before pr=
opagating the attribute. Also any BGP speaker is free to propagate communit=
ies in a different order than it received them.

What actually happens in two code bases that I have worked on: A receiving =
speaker will sort the received communities and remove duplicates. This happ=
ens even if the receiving speaker simply propagates the communities without=
 interpretation. This applies to legacy communities and the same behavior i=
s carried on in my large community code.


>> The key point is that the receiving speaker
>> should ignore the duplicate Large BGP Communities.=20
>>=20
>> How about:
>>=20
>> "A receiving speaker SHOULD silently ignore the duplicate Large BGP
>>   Communities within a Large BGP Communities attribute. "
>=20
> After the latest round of review from Geoff Huston and Jakob Heitz the
> following text was produced.
>=20
> The below text is queued to be in -07 of the draft, but -07 can't be
> posted yet as we are in the 'cutoff' period before the IETF meeting in
> Seoul.
>=20
> """
>    Duplicate BGP Large Community values SHOULD NOT be transmitted. A
>    receiving speaker SHOULD silently remove duplicate BGP Large
>    Community values from a BGP Large Community attribute.
> """
>=20
> I think the above text aligns with your suggestion, right?


Thanks,
Jakob.


From nobody Tue Nov  8 11:49:28 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4F2212954A for ; Tue,  8 Nov 2016 11:49:26 -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 OEBYH-dkNKjl for ; Tue,  8 Nov 2016 11:49:24 -0800 (PST)
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0119.outbound.protection.outlook.com [104.47.40.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D6BB129DDD for ; Tue,  8 Nov 2016 11:49:23 -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=u+nEXGdJhOhxW27j82pfsC6VNtHN+3cZPr3u6pTpz0w=; b=hWsjm40r6SqYNRrm8b1GNhLfeZapLYNHwu1DrE/bu40kVirCyyrbyMubhI9QeLWtCz/WQOgDHSxjEGjo8MiYHR0udA842qQgh6vHJGoVcUPACNRB2kA8DsLp0x85FwDyrNY6kpeYP3oQij17lCKl0HcypTkPvP9nwh+xidOcdI4=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; 
Received: from choy-sslvpn-nc.jnpr.net (66.129.241.13) by SN2PR05MB2511.namprd05.prod.outlook.com (10.166.213.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.679.5; Tue, 8 Nov 2016 19:49:22 +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: <20161108152234.GB23018@pfrc.org>
Date: Tue, 8 Nov 2016 14:49:17 -0500
Content-Transfer-Encoding: quoted-printable
Message-ID: <6EA3AD0E-5BE9-41B8-979D-BC7BB4354749@juniper.net>
References: <20161108152234.GB23018@pfrc.org>
To: Jeffrey Haas 
X-Mailer: Apple Mail (2.3124)
X-Originating-IP: [66.129.241.13]
X-ClientProxiedBy: BN6PR10CA0021.namprd10.prod.outlook.com (10.172.16.159) To SN2PR05MB2511.namprd05.prod.outlook.com (10.166.213.20)
X-MS-Office365-Filtering-Correlation-Id: 7a60e537-b5fb-4c46-bfc3-08d40810565c
X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2511; 2:SwxiPU0Z+vTl+w0uFIGWJ021aGlOc40Pb0L9YEPmLJc0k0Xu8ZmqqgLVNKICbg60NXGiIpsun60hzaamK4JpLuemD0VR3OokoNV0F26PfSe5NCirF/CxGwYmlVVWRj5n7WlxAKv4fk/HxQezzeGX+dKXAF7g+ugn9ELIYX4o4j4JPF6GqKtinSUIdw8ke8p2HmLJg82CQQgjfqtVGtV/Cw==; 3:Bkjwzg9x4wCoqIt/N7mDxyA32mlRiL/0IQn06ld1+E4pkSlFFfj6aWKF5+tvZhbO3g4nsQhRfhPPgFc7tK96XiFIe6jyo1nexVeOdYnM2Dgm0eUKWcMHiD87de64DeGcjKT8cXdCAIoAGxc8o0wtGQ==
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN2PR05MB2511;
X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2511; 25:a0wgVi0zFM6SLh2pV5M9IE1uZz1YYhbWMZXICgOdfkSVmzmbRzAuNvpF9Kr4iGlk7UWyfYjYewHR4mJ/RdBbJKTiO5UmFUnt1+0najq/vi6/bGhXId32t1hM1m5SXo7yfQ2DG5d02yCXVWsNFUxxSPicAzc1oAIzqeN60Ie5gpY9r8XTGPgJwActvXzYx+occWlzgo41w5iDGFfPW8/XYojxM07ZzJbC+vA7fdRqc3K22rvdPqyXFBn3pBq2gmwsjZ3T7WCtvwY9+G/+XhWGSlWtd/Iv8E75VwobnLzXIQXZM+yr29K3X7s1xlHi5IQLZxUM9LUIjFLqWRm8UisGWeeQYMkwfSG9sOqYy1kpHScYRkiumhSE+2m+LdLIzDwEG+FztqToO+MKss64fhbmDVx/+9Psm0T9IwY7FkhHAX8vNMHk07LlSb/GMPsI4B6YBMcevyLj7wmu4U+NkVR0WNYUk5pzMNu9DBuNIbNKztffOaRHEidg7X61EAJ6O858QXRjXqmxZ/UkgJJXXovTMtjICDCONc7J7zaWEVQX7w8s2rVBxSeSwSVLYMOZM35GyUzGQdpjq34WdYZDxFpBrmwA6ADMRASMC+F626lHXh6yRQCfVpYCwjaaFsZGPhRdbzHwaJlFZ3GXYfMQbkkwGCg0JXoEgAUzPUPV8939sgSoTBfSbaowbEpUkBzQcpvyfKSo7CPMjKqYYIrTl3tHHczMxD3wnSIj+GQ/UUmw21OYsVMJUQ5nN3nsiuVIEtXkw4nKSTZ10DV75nT/d7KbRD8PSH6ycrC0mqJknUB1mjFXTPeXhv97OiMA3ZheXI7RTykj7EoMUFOONmTX4HaO9g==
X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2511; 31:2ulJOBBvSIOqCgR7WAI56+iE7g2TjH3IAi3MpLNiKpHo0hOFC8gspwKmt6JkqzixISB5CHcvz391zi4qT4J2Qzma+SlLlABXQfkwVaIrzmOZJIhhBCi/cedlrlR5kJkGgeMIf2Pz5NVIAQEXXvHtg6ywmrnjCezkNDn5TBOESldmvuykOMML3RWdb033yqQeQ1VH2SWdrMjJZrwQZGdqHvp2QfgW5I6XxWZVN+UR0R4A/bPXFUGgavR0eVSIqNYr; 20:qvA8c33VDkmllStw0JSLWLrQ18Ubwk1TDu7dSV5OPwd0L6fKxPvnhhS4yicmIro9z7AfmM8XLQm+N4I9ZNN2U3l/uEcbdUfNs2/dKwcPYn4asMZjlfYkkbf5oUwZHa3cfbHZmWVwtIQ7pA+GzITg2w+WGq5dzcvykO+PHkXuEyhf7dEzMLc9asf7CffrhhIeBOJpwSdRrCrKt0sreHWFQ1H32hwM/nPJJpyGHRFaiu0HkhrKar/5y+eQmA8c5+fG+FsBieM3d8ktxEKbk/2VBo8nM7iPaS/HvUbwmDt0Q3A4IYOpXhAO7Jf0ebJ/rAuc+urnoDtPjxwcNNqM8oBUvEk628i5kuyAfvv7fBOJ5ETg5H578T0EMfIv9f2+OOMv7b9PsfzWZp3Uc7AAP1rn6I/1tqoURiyofKPHXdYVfN7XU6rM4N7pKjYv6mBg20c8/xc5ehsP44G9BvLrGWBvCYhuEg4/SiAoCLSZMflxW5Glxl9KxRQrqeCyxSdN8axCAH2H8a4YerAoP1BDZaqJXU+0qWZQO2tcOuH18WLGowTJZHphxy0/CxhkLHZ0VXvUhCtjL3uD6o+4ZPug/ibw+ihJ5hyhQH4Mlr3v6txPxoU=
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:SN2PR05MB2511; BCL:0; PCL:0; RULEID:; SRVR:SN2PR05MB2511; 
X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2511; 4:ZYmEcSi5vy8RntESCMb/ZTKcjb0bczRd2LEZiBfwckKhj9evaniMFHuU47rk+oK1MWEQlIGiN53c9OEmb4SAvIlmhvokL731KJWpad0ahjLFq4a1mhVbD9RvK1LFs+ImLnTY0xaj8gxbuP33zHstiEXnTijr0xht2HaS975CDp3hPjvLfFdNZhTCF/X4zZJw9bZq5PHqmzbXuNBxTXCgXVlCS9g8DB0h8ph7BriZoA0ZjthdvF8zNhj2Zrg80FyigNEzy7i7EKg7P/JsJ+7nqRLCdv6xP6xNF91An9jU1V4hJ0L+7GCqy1J3LyddJBJdvxDDtJJDdYaq5lLIKAxMZ2WeqIshG/jBp9viae1SU7OdZod6K09P1EMbc/sc+aK9dGD4OTuGuGXrJ62+koHAmNxqf52o/Gq1nWvAToitIlk=
X-Forefront-PRVS: 01208B1E18
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(377454003)(199003)(24454002)(189002)(2950100002)(6916009)(6666003)(110136003)(586003)(53416004)(2906002)(3846002)(33656002)(50986999)(76176999)(561944003)(92566002)(105586002)(4326007)(101416001)(7736002)(106356001)(83716003)(23726003)(47776003)(97736004)(7846002)(69596002)(305945005)(50226002)(8676002)(66066001)(230783001)(81156014)(50466002)(189998001)(68736007)(6116002)(46406003)(36756003)(42186005)(86362001)(82746002)(8746002)(77096005)(97756001)(57306001)(5660300001)(81166006)(41533002)(42262002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR05MB2511; H:choy-sslvpn-nc.jnpr.net; FPR:;  SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN2PR05MB2511; 23:lC7gTn/INovaZyB8IwZdmq9OdMqqsYv4YCJappaQ6?= =?us-ascii?Q?5Lf4xH+E5FZTfTvSx+nSwnKvAF7jMosjvARybIP+aGwh8HSMr2HLuCcIRvZd?= =?us-ascii?Q?cAlSxRw3/D8IwxZdXK5qoTAT+GgrRggV0I5+axs+cyE//MEAUOyHwtYbMrWG?= =?us-ascii?Q?0WFKuDRMme3FErFjcdYGyZJUMM0IjLGN5EH+NyVvOVwH3FjS7qqbPhJCxGpA?= =?us-ascii?Q?IeHxt71wq4VmKPu8/1qLbmzAJDxlCEa5I3+e2UlyITIB3tXqQUKcozSdpoSX?= =?us-ascii?Q?wVtPtYogI1MSdOz+4wvAgSJGhUiVbnKo9PojpEWgVunu3+TUpArjzb7W9F31?= =?us-ascii?Q?B7QCGrwddCT4X0sP5eIoVSkWQZUgIrnTyf/NPlEMdeyb/2d7GYz95PofpkTF?= =?us-ascii?Q?+hDn8CUSPQ7PckCTIzUzmYAfAtx23gn1+a/IML8XTj6xE5cqFf9/h6go+vut?= =?us-ascii?Q?hYNHXhuyHdU63EkMA3RYwfBWz0s8OS/Ix3Z+HD8cnxs8S9/IL/SpZ9pv8gCS?= =?us-ascii?Q?HEo/mdGkN0HxctewO8dbVd46pnBuAiS6ZnmpNTy/IzpG5BfdrzzW3JQunKN1?= =?us-ascii?Q?lDSIE8sus1azsMyKTThFKsxmlMMxapouOQTm1hG7sMXvASZWf5MFiL+6TZJA?= =?us-ascii?Q?DPRECWGMgPXTYvBjbkm9gEmgnthjKhUJLc59PAeovddg7teYD2kBYD2XK0vV?= =?us-ascii?Q?nJDbwwKV5/vOvdftYJSVMBEKnx42UyS2IxkEzchihK7QLjft9+35g2ueaT/l?= =?us-ascii?Q?8f9BQtkq9m+V8bOiIzlhPakKBZZmx7pxb+DIVT32X8Ty7sVcJ+w5whTD+qyz?= =?us-ascii?Q?apJhgV4tVZhFM6F/zbOjSHDFyrYOJ7oFI9YyLSwqVwresUZEYgi8MIKFGpQ0?= =?us-ascii?Q?pjvg0JGjPWVM8/GmGBqLiGB/qhNs4YUU4zAlRcKRJdlTaCcBzDfytsWj0No1?= =?us-ascii?Q?BuzBqRFft18Iva7ugmBnJ+hLhp3pwkmi8d8EhwEeoImT00P78AjAgV7gMjlk?= =?us-ascii?Q?wSK8Q2s/2KdBX3J2VR4j7C7RKF0rIiWcHa1S8xVlL5mtl741p28OPHXBaJQd?= =?us-ascii?Q?SOC1Q++eowH/6CW3TbA2SNpwrvd2bIL5GJpyy2a6qielOW54aYpwX//XQkQV?= =?us-ascii?Q?oAMfq3CKUa9ngFuxfhIqufsYeE3OcBi6tLsoXq2GQrZuubmDPCOjMlhIf63z?= =?us-ascii?Q?9yz2aaFKf+U26ZPNd6xwAZJ1lY16qMIBLjaR50zEHesF8A06vR3Hw/uU+tjl?= =?us-ascii?Q?H7XRJaPk4UR0RyMEQFxJ9ZdUxBYfTmrLOBH10dLfe8Y0VXmdCS37ZyaCi3Q5?= =?us-ascii?B?Zz09?=
X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2511; 6:xCqgPtsl9v8syLagr44wmFJaA1MWvXOd6I+MpwK9CpKBg2kuhhaTg90ugPf9LWGMquHEdpjQE3+OaarUDKIBJJxi+tTMj4Eh26N3dHui651lchbNbIkw3jTH2nxt2fAZPOGU/HUI5VsEUDtjLVz1e8AxNCRTbdXj8zRHhGPL1W56nXPIDzPxXEXBZBecx/kzeay2umEp8SZJW3gkAvCZ5HUgcdBcEkX+5m9KT6//WBRzgJHscUU7LtSETAkHi2LMb/zO/lr6gIGWndGpktM6+dWhSlZCaHvGPOtT7mEPdL2idYZpXi7mBjyxqhL6iyhfBn5jw1Io+3uLrWa6Z2MCcw==; 5:h2dGNogbDbjZz6svzBztna+8Q3qvUa/BpZ73HMhHMpo3c0IlwnvZR6pQUImydSA+U11ejl+XC8dprQi/uLb/okOdpLYdLpji2q2m9XgC3t0cHsXN8DhCm9VhiU1Uj0sTowfNPdKBosRNFUMSddACnOQ8LdYxpMpSCJuR2cKqwyw=; 24:pHhZ5RwiXzxoQH2sMb25ZoSIEtP1qQ1RGCq+D4aleaJCtWR0sPU2mxdcvwAzfT+ba6MouCeP6q4MnET08843CxJ0pAKl2xxUIxTrB7YFHNk=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2511; 7:7y0W9r+jabgehWDBxnQxPGMQvxFjSuvHl9+LU01CP+QxGErlvWLT9U7Cg0rj6/a4avZGBCzUiiOUP1PeVZ5vLXYsSndJZ6rhvdSl3rmR6ZAzDFi33HGzLwY81DHK8N1x9GjZY0AcwWz05fwJBVXVnLL6W8rpIFx/TKDbAcTY45CGiQTe5kMfAahTVv3iIaRJVHm82V1JhcWnSL71hShCaRTqqmJducdVjoBA0wkaV5AI10EOnb/hJ++jgHrtlcsEkziKgdeP1p01RPaFJ235niHBe6ahjZhwa+hFYJn1Aqn1KF0/SBWm1ijxYxbxQNv5HUgVqyTOD13JH1UZFXAzv9dFAAxiyph6QSy9SyUqbbk=
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Nov 2016 19:49:22.3457 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR05MB2511
Archived-At: 
Cc: idr@ietf.org
Subject: Re: [Idr] Requested WG state change on draft-ietf-idr-as4octet-extcomm-generic-subtype
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, 08 Nov 2016 19:49:27 -0000

In the unlikely event anyone objects to this, please speak up, otherwise =
we'll consider the document dead (and will make the state change).

Silence will be taken as consent so feel free to remain silent if you =
agree with Jeff's proposal. :-)

Thanks,

--John

> On Nov 8, 2016, at 10:22 AM, Jeffrey Haas  wrote:
>=20
> Chairs,
>=20
> The authors of the Generic Subtype for BGP Four-octet AS specific =
extended
> community draft, draft-ietf-idr-as4octet-extcomm-generic-subtype, =
would like
> to request a WG state change to "Dead WG Document".  The functionality
> intended to be covered by this feature has been supplanted in a better
> fashion by BGP Large Communities.
>=20
> -- Jeff=20
>=20
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr


From nobody Tue Nov  8 12:01:57 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54BF1129DEC for ; Tue,  8 Nov 2016 12:01:55 -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_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 dL5_46LhWSRW for ; Tue,  8 Nov 2016 12:01:53 -0800 (PST)
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0105.outbound.protection.outlook.com [104.47.37.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 2CE17129DDF for ; Tue,  8 Nov 2016 12:01:44 -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=YU65MFUxyalLANLHgLOB9bOWkK8GLNoWrkYpiYN4aKk=; b=gvy9UezmWicBxc2JNpnC06d6x0LjQ3ec9iCncKGcRT/jktikqfg45+mAsbEZi9PZ3P42vFQKXHEg48EEWf/R4C185sQwigzly38NSxwvhJ7jNAI6T4v7mm56VzccHCwQR678GlE7V32gD2nHmphNiy2nZ0GvW7Bdet/qBIMO3lw=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; 
Received: from choy-sslvpn-nc.jnpr.net (66.129.241.13) by SN2PR05MB2509.namprd05.prod.outlook.com (10.166.213.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.679.5; Tue, 8 Nov 2016 20:01:40 +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: <6FE43655-81D0-45E9-9817-D5583213DE2D@juniper.net>
Date: Tue, 8 Nov 2016 15:01:35 -0500
Content-Transfer-Encoding: quoted-printable
Message-ID: <715BB278-8930-4E80-BF01-15F7BF597151@juniper.net>
References: <20161031205515.GA25507@pfrc.org> <5818E126.2090202@foobar.org> <20161101185759.GA23458@pfrc.org>  <20161107152616.GB25256@pfrc.org> <6FE43655-81D0-45E9-9817-D5583213DE2D@juniper.net>
To: Jeffrey Haas 
X-Mailer: Apple Mail (2.3124)
X-Originating-IP: [66.129.241.13]
X-ClientProxiedBy: DM5PR10CA0018.namprd10.prod.outlook.com (10.172.33.28) To SN2PR05MB2509.namprd05.prod.outlook.com (10.166.213.18)
X-MS-Office365-Filtering-Correlation-Id: eff4a3a3-ca2a-4530-44a4-08d408120e84
X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2509; 2:fwVhqng3oOx0gMR0z1ZtWqthEviQIQEhKvSV8Z9IgO5bMHMoskgsj/NIQ4UvTk0IKPximSbLvFUm8y5X+mxSOJEgOJppkEQ0VgFYjH6S6X/FzyxN4VmnORwY2zHQgqx0IjBS/udxErzVG1tFX7OKnLVEeaBI4qY5IT6BHQNpySh+ChaBMTqJK4Aq5xAB80QG333MijoBjqhLdzKhFsXVmA==; 3:oxZJJpa7otPoPmI1+iJOSnNOhycGxKwgHqRK2pb+lAiKgxr07Zg8u3uayDPYrhKZnkJZIRm1ASL36zS5YQs4ASBpsA+FH6oRVPtsQkDNa2L5PLy3sYeCNms5wHLiW816Nj8BmaFr61YyTCgAkYGQbA==
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN2PR05MB2509;
X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2509; 25:CGL9FlO/3MH6b/72kr1PCy0wtEwWYXCTLEDSplPtlw7FEBhpbSOPO9hzDiYbEsrE8IjEiqMCBq8a37CpVCIp9S+373/s978pvxAKV3iDyYXin4gTrRnIK/hulfnV/CZTxt2q8A/RwYFJY0i80figNjA+KvkwDT0vAH4gV++3e1GTBpaKxyuQCKJMDytRuS8MBwy2H1JrPWXxWJp12iWhubxIuInu33Aibs9kvvsNYiQ5jftVgvQgB5xS9o1QO2NBBgCumUp+vhesAmBIyWJrTvl5GTKtYybpzialIsTNZ71qseg6yy4ie9WJSqHS4DbyxD+zKoZXd1SijWQb5VgPJouIqpIzGcZ48xXj8ONJrWt9/kBxt16NQWaZ2WE2Wu8GiA7Ru9/ZpdGDKdwHNpIkh6sSks6RE4G4LOl/3ERNEcB1WrZeI6Pr14h2ld+bu+5O0ioiZyIVGF7++l2sHPpKlytb8vQV4QpG91nFsOgqoXpnILeJsrxlMqNbpaQ21BLQRfOpOiPnACPd1m+1fdRPv6ddUqKwPs/w+avzPOBPrHZUrIz3v1INe3icMxTZ7wZw/iEE1gGUYijhDSo4yVw8A1lEzfrzA11CmoKmYkTW9mo9DwFmSGVSGqnhZGbAhc4t7FbiM0ErFiGJnyQSdJSuyqsbiJMNaS8WoxI0duHz39PzA0AH4ZMhkmN2027UqO4YHXJFKZQwGECahRl3RjMStmRmIzlFWLOWkOJnQxy7qJebpYWu/4oxf1D1v10ApVdM
X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2509; 31:QPNGZy5+c6B4p0hFos0KMJvFwljoi01FEzNWA3eNjM70dRBFytvv0yow9TL9Ll0xKlDh3ygugIqg8OvsiqkBUBhOtBnZm7AgUIthRdukqM7wVMhbA1AJTCWU22CI2wduMBpW0pjEwfq1WOPQRF+etf8TrzjxfYA3T9ZjC8oZFpyql0ptQsjcOHMB4tvv5IIbOOm0OJyPB6xBRI/JC0LgxVviMky8/7i60+e3cfjVLp58jvEIAH/yHVIRexHxbM9Qlj+MutojzOoR68rum5Xb+AEFjhJollh11/8ffVg+rO8=; 20:+FrbMfJQk4+xEoCJ3/rQg1gYEJZEJJIs7RdXJN3JnNZP5nIVgeqMHMSypjIwE5PjTBXSVGYMTk4qOIdwo8AWv524jqtJldUMy7yG0eP7WqCxIQI+sM2lTFPEoGu7Mh6iFeuyz+E+x0ZWSu63f24YKFtrTfpslAZfkzL/s1F+IwbGlVabCIi2XGs4ekDDVoJuR8SLY9IWnghsxKk1Nt69mAhLppuFUV78CbvEX6WS9S6uyZrd1QSTU36YPPSDnAb+fWkTqjG1V8mdxx28jH1P/GB/0Hqtg8AIEaXSLmFXgbNlpU55Ebfho/Y1y8FMlNEDSZkGuIoGwKBY2CNAJbOeDquQwzcuT/j0LvD2zLFu/v6SKLh6UDdYwnIqIBfgJuzoWj5Oek8Oz5kvuzCcIE64vD1uTniwwmBiW6H0CHwaOUY5GYz1dkMtTaeETCaTd5C+/zW/wdAa7Y4Doj8RHxdY1ac0iSpXS2j4tyUEZjiI07vrHptPUbSFz2ZWcdeDjeXGF4lJXpwYcj8gfHKYbgxL+8Vu9k2V/Y9KdB5GOyyFVf+x+bxddg+X7Thz5FbUyM4d5nvYvafe+24bwCVyLmQrI8vDLSlNOtdsXfM+yyvbESE=
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(190756311086443)(138986009662008);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:SN2PR05MB2509; BCL:0; PCL:0; RULEID:; SRVR:SN2PR05MB2509; 
X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2509; 4:7BFrUnOht5LG7nU8EM+79p6GqCUr3nyINb/ydEaIJDJ9v3t2eDje05OYrBi0CqTFLCl5o9RLhDBucKrj/Sb0vFQIJKhX5D2Vq3qLGx2J3x21Tkn2nXWxD7XqoH5ZH7qCrFkxhEIrdoqRejJ3URdQIACEHNEl/YbNLfhffoGy8bwyHtCPvvbmUpYJZlW4AFvE2/RRjdhdWLNyzK8I3l6c6/E//LYDbM9NvwmqrApm5INvnFA73na5mSF75GeChRFHmbXFkOT+h/Ef/Tzrt9uvpgPc3WotXtkQ03dHMq7x9pQ0PMgQtjqxKeLohAfMR/wHqLucGSXN0O6ZdtCRKLLvKsQb7ofH4o+swB/JirKlY7kYkX3rbhQHTUK2RQrfzeV+t3bCo2YiGzZZA7n0JAzFyKsBQBTOI8NOvdZgwGIobq633WUkOMyEZKc4gEWHV9Xao4QmRUxn5cfFswhiI003M7ZXdtZjV9rCcFmML4tPtVL1irn+iXoTSs5DlnMymEBZ
X-Forefront-PRVS: 01208B1E18
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(189002)(199003)(377454003)(24454002)(92566002)(33656002)(77096005)(189998001)(6666003)(47776003)(82746002)(101416001)(66066001)(586003)(36756003)(57306001)(83716003)(5890100001)(50226002)(8746002)(86362001)(50466002)(5660300001)(7736002)(42186005)(230783001)(105586002)(97736004)(4326007)(7846002)(97756001)(46406003)(2906002)(106356001)(6916009)(81156014)(93886004)(561944003)(110136003)(50986999)(3846002)(2950100002)(23726003)(305945005)(68736007)(81166006)(6116002)(53416004)(69596002)(76176999)(8676002)(104396002)(42262002)(222073002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR05MB2509; H:choy-sslvpn-nc.jnpr.net; FPR:;  SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN2PR05MB2509; 23:9kIIcFjV6isvBa2jL9bjuB20PAjIWUzaSsBAljTAe?= =?us-ascii?Q?tVspefOcLz9fai1ByiZCwEZOK2TpEw1H2hXebcYEuDOpDsniuNZ3Q2EcSZQs?= =?us-ascii?Q?fVAeGRZydwiEmDs3YLy6kzyigYTSdm0lXcB8p1ZpI6RUIPGugX7vR7bo0/T9?= =?us-ascii?Q?0tXwscJdEb8+g/Y07eLHO222jjBqqsD3N24fvA18uoZy08OEyZiLPZuoQQu6?= =?us-ascii?Q?OLFM6hTTt1utCUVSEoxnxR8njpW3QI915NJHpb6gT6KEE04Z5kInq+JYRBWw?= =?us-ascii?Q?MZHTaztC//hFkDHZmFLRf6MOdsVAD3yhj5bYOpTrn0CEy+3uDw2ZucGW4xbX?= =?us-ascii?Q?IFZUhDat5lCIJSqMkUQvUZBjgTL6A2x2YaIuIlgbzgPxgAAnbPNw4C9rKRfD?= =?us-ascii?Q?5VUnPeToZEGBiJb+UHPQJYoohGz+ranZ4LDo1ZvOxYSG4H8hwoUyzmO+sLG4?= =?us-ascii?Q?2z5+7uM1/IN+rVWEDjV21HoL50bPumsTcTYF84o2/hHaOxpfmKmHnGxnokZI?= =?us-ascii?Q?ahNTPzyjJahY/g6B9j3P9Y8ZYiG5oTbK5AdevDkKp/bQJXvX1mapceqPRjMB?= =?us-ascii?Q?xqDk51YcRYxFbdTcZKHt+nprvWMW1c2+YiwsM57OA9AvDoZNYzgJYSZ1n5GY?= =?us-ascii?Q?Zn/lZy2sRcY8W5P6LFqv/h3dJODK0nSDRQ9UpAtF7z4aLRygopI6b6lqT+ps?= =?us-ascii?Q?8xKgU0GxFslrcnLMevQyCadnnEHgyEgELEVHMZ6z3Rgm5Vgli+FEDWDOqDXa?= =?us-ascii?Q?y5nR63vcIuxZK1LYe7ACZ7IUyW47Fr8/fQDTJlDYBDSueENj39iebLMumFQh?= =?us-ascii?Q?bh9kHUx1JPTFScIKoO6tcIc9cRNOXBpWVy6Dg7Lp/7JtKbAUzM7YcVhAMPMt?= =?us-ascii?Q?m3eo/Ze3ihDSFtqjHytxD7glJZJ2bjQpNtVIRaEhg4677his+AA7zH4xK9s/?= =?us-ascii?Q?/yRBMvAXfC7y8orHlANKn53nOrkYDbq0BmC6Vm7qtHoEmlyOUUGQC+e9KTPZ?= =?us-ascii?Q?dVKI/4+DxL6Lv/6gn3p3BPQYJGP2hS7pxi2dARm3RwH8EuLr9iauX7/+gEGr?= =?us-ascii?Q?W7kIDm0KHR6ryQ55Zn2ajwh3IRKYEY24EtlxS06vCWsMLBw9F461lskGID3m?= =?us-ascii?Q?Nqbul2SPiY1Bxu17GECZYOvvc5nCT6Kl9w+PgbaMsV7eywWcJa+s6nEqum/3?= =?us-ascii?Q?kWmzkysYclxRWHkvIngU/qB4GrvOmH9Df67AgYMFQrltccRsZkozp+yYPcE0?= =?us-ascii?Q?AeOBUkCbIYO3wOiVigI1tzvJKswCsfP3+I670wqp+stBJhBrO57KX1ETGYDI?= =?us-ascii?Q?difVWYyrgf4VElOT4WczquqfrYXQGt+kw5aJrSMWhEl?=
X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2509; 6:zTr6ry5BXro1izlySG38NtbzX9u+MSjwvO1Y80BJZ5XkpB7IV7S8wRwLGkgxOMaQvweeci/3W9SqXAzjU+n5gFhfhhSjcUpZ1XMds9noKivOdSIPdM8rRhMTNhwvtHTFeO/d8MDGQruAK++/UfWtXmkwRFAU3WkM/CYPFyOCacSXNx04NjIaH9MEXCEnpbO2Gaj5bUbZxMfzvvdXfYg8V/ao62YleCMcnWy7AYx15vazUeQ5H9HQvJOvn0hin/CieyE/5hzeGqhNTcIWQpT0nA9NUL4FHsSSVdI6BXJzEH4QtMT/z4PztOYLklEZW9KX6XRLc4suIhrz1wKzeE+0NaXD63on8z6/xg1CoSZh44o=; 5:KXMmjwY9LlLrP40i5QsQ+rVeYaA20iVsvt0pc68DSqJNnM3BE+bpU4Bz9xRZJA8VrNfVbjZHIrs6YQ9ZzqzmmFY4dI2yTFa9Vim+p2isc7fU1cY1TmEh83Og0Ege0mIYgkriibmL9WJ6dyzGV3HKQnpJHT0KBDM1Oj94EF06Ld8=; 24:93yfV9uydN2zIjWySt5vJncMACVNNpBCXpan7uYSweDQpg4d7+IS3QKqKMtH9mVAQ1JyBaqVWnqE421uaG7V07K+0pIyvq/fqBc61dNDGbI=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2509; 7:ryAtJCe1An0WDWhfFmw2P+O/bDRhIOw0w3eATnQCcJLyujNIMWS+3auFpHIJ3jcSVs6duz41OoDZ2RLR5sIdby7gOSGxzO08/4T7cBDdDloYr+JSC3x7vmz6imp6y3xl8mj7jp4eca0hTyLCNiMGEUK84BYmYfwzVtrceTdpyINTNiXfIawyqm+hJpzLPEIW/fyz31T0kl6+PHl1bPATkQ8rt9/awcSTXufAXdf9R35TqqMzUAvKJ0np65h1sMRDkxptVUTNwnBvdX5dXCMZPI5GLpy/BRI6GN+GoRn+alVi44/9FXEpFo6FrNp2CWKrct2gDbQRjnkEB4FB/IbaDXViffHvn5ZeU68kHmYJMd4=
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Nov 2016 20:01:40.3758 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR05MB2509
Archived-At: 
Cc: idr@ietf.org
Subject: Re: [Idr] [internet-drafts@ietf.org: I-D Action: draft-haas-idr-extended-experimental-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: Tue, 08 Nov 2016 20:01:55 -0000

On Nov 7, 2016, at 1:15 PM, John G. Scudder  wrote:
>=20
>> On Nov 7, 2016, at 10:26 AM, Jeffrey Haas  wrote:
>>=20
>> Marco,
>>=20
>> On Sun, Nov 06, 2016 at 08:23:36PM +0100, Marco Marzetti wrote:
>>> On Tue, Nov 1, 2016 at 7:58 PM, Jeffrey Haas  wrote:
>>>=20
>>>>=20
>>>> A feature such as this one, perhaps extended with a per-attribute =
form of
>>>> draft-ietf-idr-bgp-attribute-announcement along with enough =
information to
>>>> figure out when filtering wasn't done could provide some safety.
>>>>=20
>>>> The related changes to this proposal would be to simply add the =
4-octets of
>>>> the attribute announcement scoping and potentially the attaching =
AS.
>>>> However, given even such vendor features are likely to need to work =
in an
>>>> inter-as fashion, generating scopes of containment become tricky.
>>>>=20
>>>>=20
>>> I have always wondered if we should add and N bit to
>>> draft-ietf-idr-bgp-attribute-announcement to limit the =
advertisements to
>>> neighbor ASes only.
>>=20
>> Such a thing was discussed among the authors of the =
attribute-announcement
>> draft.  What this would mean is such a bit would need to be set and =
then
>> automatically reset into the M-bits (C+A) at the next boundary.
>=20
> I'll also observe that we already have the NO_EXPORT community which =
has virtually the same semantics if you apply it as you're sending the =
route to your peer. And then there was AS_PATHLIMIT, which never =
achieved escape velocity. Regarding NO_EXPORT, you might remark that you =
have to apply it at your border router instead of at the origin, and =
that's true, but I'm not sure if it's a big deal. You might also remark =
that NO_EXPORT doesn't survive if your neighbor strips inbound =
communities (or explicitly blows away NO_EXPORT), and that's true too -- =
but if operators are deliberately dishonoring NO_EXPORT, is there any =
reason to think they wouldn't insist implementations have a way to =
dishonor the mooted N bit?

Marco pointed out privately that NO_EXPORT applies to the entire route =
whereas the suggested flag would apply to the attribute, so not the same =
thing. That's right of course, sorry for my confusion. It's not the =
first time I've made that mistake, but I'll try to let it be the last.

I think the question about whether there will be demand for policy to =
dishonor the N bit is still worth thinking about though. For some =
protocol constructs, we seem to have resisted the urge to make them =
configurable, e.g. AS_PATH loop detection (OK it's a little bit =
configurable). For others, we seem to consider them little more than =
decorations to be respected or rejected at the pleasure of the network =
operator, e.g. NO_EXPORT. I bet it will be important to figure out which =
category attribute-announcement falls in.

Regards,

--John=


From nobody Tue Nov  8 18:06:58 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2C3F129444 for ; Tue,  8 Nov 2016 18:06:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.398
X-Spam-Level: 
X-Spam-Status: No, score=-8.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, 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 vHHkgtcxA-mt for ; Tue,  8 Nov 2016 18:06:55 -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 D48AB128874 for ; Tue,  8 Nov 2016 18:06:55 -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 1c4IHr-0003rS-VB; Wed, 09 Nov 2016 02:06:52 +0000
Date: Wed, 09 Nov 2016 11:06:50 +0900
Message-ID: 
From: Randy Bush 
To: Job Snijders 
In-Reply-To: <20161108121400.GF2473@Hanna.local>
References: <2016110819514874384911@chinamobile.com> <20161108121400.GF2473@Hanna.local>
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: idr , "lizhenqiang@chinamobile.com" 
Subject: Re: [Idr] Why do we define so many communities for BGP
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, 09 Nov 2016 02:06:57 -0000

> It is healthy for the IETF that ideas can compete with each other.

that's what we say until somebody competes with our draft :-)/2


From nobody Tue Nov  8 18:29:29 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CB601293F8 for ; Tue,  8 Nov 2016 18:29:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.718
X-Spam-Level: 
X-Spam-Status: No, score=-5.718 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, RP_MATCHES_RCVD=-1.497, 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 EW9q5eV1LFDO for ; Tue,  8 Nov 2016 18:29:26 -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 EAF33127071 for ; Tue,  8 Nov 2016 18:29:25 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CUU34952; Wed, 09 Nov 2016 02:29:23 +0000 (GMT)
Received: from SZXEMA414-HUB.china.huawei.com (10.82.72.73) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 9 Nov 2016 02:29:22 +0000
Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.175]) by SZXEMA414-HUB.china.huawei.com ([10.82.72.73]) with mapi id 14.03.0235.001; Wed, 9 Nov 2016 10:29:18 +0800
From: Mach Chen 
To: "Jakob Heitz (jheitz)" , Job Snijders 
Thread-Topic: [Idr] Review of draft-ietf-large-community-06
Thread-Index: AdI5iIlDv+X8FqL1SIqxamyskn+T7///zqcAgABd/QD//u534A==
Date: Wed, 9 Nov 2016 02:29:18 +0000
Message-ID: 
References: ,  <20161108112616.GD2473@Hanna.local> <658B78AB-70F9-43CB-B2FA-2A14ACC6A273@cisco.com>
In-Reply-To: <658B78AB-70F9-43CB-B2FA-2A14ACC6A273@cisco.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.102.135]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.58228A03.01F1, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.3.175, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 4f7be1e766ba6a8201d281b04e98e920
Archived-At: 
Cc: IETF IDR WG 
Subject: Re: [Idr] Review of draft-ietf-large-community-06
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, 09 Nov 2016 02:29:28 -0000

Hi Jakob,

Thanks for your prompt response!

Please see my reply inline...

> -----Original Message-----
> From: Jakob Heitz (jheitz) [mailto:jheitz@cisco.com]
> Sent: Wednesday, November 09, 2016 1:03 AM
> To: Job Snijders
> Cc: Mach Chen; IETF IDR WG
> Subject: Re: [Idr] Review of draft-ietf-large-community-06
>=20
>=20
> > On Nov 8, 2016, at 3:26 AM, Job Snijders  wrote:
> >
> >> On Tue, Nov 08, 2016 at 06:22:54AM +0000, Mach Chen wrote:
> >>
> >> Section 2, the last sentence:
> >> "A receiving speaker SHOULD silently remove duplicate Large BGP
> >> Communities from a BGP UPDATE message."
> >>
> >> IMHO, whether remove the duplicate communities from a BGP UPDATE
> >> message is not significant, since the life of the message is over
> >> once the message processed.
>=20
> That's not what happens. After a route is originated, it passes through m=
any
> BGP speakers and typically ends up in most routing tables on earth. Each
> speaker that sees the route may or may not interpret all the communities =
and
> may or may not propagate the communities. However, any BGP speaker that
> receives a community attribute SHOULD remove duplicate communities before
> propagating the attribute. Also any BGP speaker is free to propagate
> communities in a different order than it received them.

Yes, this is true and I agree.

>=20
> What actually happens in two code bases that I have worked on: A receivin=
g
> speaker will sort the received communities and remove duplicates. This

This also aligns with my worked codes. But the point is that it does not re=
move the duplicate values from the received message. The duplicate values s=
hould be ignored and dropped.
Normally, a BGP message will be terminated at the receiving speaker, when i=
t needs to send messages to other speakers, the messages are actually new g=
enerated ones. Of cause, this is more about implementation details.

I am fine with the new text Job proposed in the upcoming version 07.

Thanks,
Mach

> happens even if the receiving speaker simply propagates the communities
> without interpretation. This applies to legacy communities and the same
> behavior is carried on in my large community code.
>=20
>=20
> >> The key point is that the receiving speaker should ignore the
> >> duplicate Large BGP Communities.
> >>
> >> How about:
> >>
> >> "A receiving speaker SHOULD silently ignore the duplicate Large BGP
> >>   Communities within a Large BGP Communities attribute. "
> >
> > After the latest round of review from Geoff Huston and Jakob Heitz the
> > following text was produced.
> >
> > The below text is queued to be in -07 of the draft, but -07 can't be
> > posted yet as we are in the 'cutoff' period before the IETF meeting in
> > Seoul.
> >
> > """
> >    Duplicate BGP Large Community values SHOULD NOT be transmitted. A
> >    receiving speaker SHOULD silently remove duplicate BGP Large
> >    Community values from a BGP Large Community attribute.
> > """
> >
> > I think the above text aligns with your suggestion, right?
>=20
>=20
> Thanks,
> Jakob.


From nobody Tue Nov  8 18:43:05 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B65A1129496 for ; Tue,  8 Nov 2016 18:43:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.718
X-Spam-Level: 
X-Spam-Status: No, score=-5.718 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, RP_MATCHES_RCVD=-1.497, 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 yRqkc4jeDQCH for ; Tue,  8 Nov 2016 18:43:02 -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 97FAA128874 for ; Tue,  8 Nov 2016 18:43:01 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CZZ47626; Wed, 09 Nov 2016 02:42:58 +0000 (GMT)
Received: from SZXEMA417-HUB.china.huawei.com (10.82.72.34) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 9 Nov 2016 02:42:57 +0000
Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.175]) by SZXEMA417-HUB.china.huawei.com ([10.82.72.34]) with mapi id 14.03.0235.001; Wed, 9 Nov 2016 10:42:51 +0800
From: Mach Chen 
To: Job Snijders 
Thread-Topic: [Idr] Review of draft-ietf-large-community-06
Thread-Index: AdI5iIlDv+X8FqL1SIqxamyskn+T7///zqcA//59h6A=
Date: Wed, 9 Nov 2016 02:42:51 +0000
Message-ID: 
References:  <20161108112616.GD2473@Hanna.local>
In-Reply-To: <20161108112616.GD2473@Hanna.local>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.102.135]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.58228D33.00F0, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.3.175, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 78ca36416e9be1cb184ad998701ae391
Archived-At: 
Cc: IETF IDR WG 
Subject: Re: [Idr] Review of draft-ietf-large-community-06
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, 09 Nov 2016 02:43:03 -0000

Hi Job,

Thanks for your prompt response!

Please see replies inline...

> -----Original Message-----
> From: Job Snijders [mailto:job@instituut.net]
> Sent: Tuesday, November 08, 2016 7:26 PM
> To: Mach Chen
> Cc: IETF IDR WG
> Subject: Re: [Idr] Review of draft-ietf-large-community-06
>=20
> On Tue, Nov 08, 2016 at 06:22:54AM +0000, Mach Chen wrote:
> > I have review the latest version(06) of this document. The draft is
> > well written and is basically ready for publication. I have some minor
> > comments as bellows:
> >
> > 1.
> >
> > Section 2, the first sentence:
> > "This document creates the Large BGP Communities attribute as an..."
> >
> > Although RFC1997 also uses "creates", I'd suggest to use "defines"
> > here, it also aligns with the convention of most of the RFCs.
>=20
> Good suggestion, accepted.
>=20
> > 2.
> > Section 2, the last sentence:
> > "A receiving speaker SHOULD silently remove duplicate Large BGP
> > Communities from a BGP UPDATE message."
> >
> > IMHO, whether remove the duplicate communities from a BGP UPDATE
> > message is not significant, since the life of the message is over once
> > the message processed. The key point is that the receiving speaker
> > should ignore the duplicate Large BGP Communities.
> >
> > How about:
> >
> > "A receiving speaker SHOULD silently ignore the duplicate Large BGP
> >    Communities within a Large BGP Communities attribute. "
>=20
> After the latest round of review from Geoff Huston and Jakob Heitz the
> following text was produced.
>=20
> The below text is queued to be in -07 of the draft, but -07 can't be post=
ed yet as
> we are in the 'cutoff' period before the IETF meeting in Seoul.
>=20
> """
> 	Duplicate BGP Large Community values SHOULD NOT be transmitted. A
> 	receiving speaker SHOULD silently remove duplicate BGP Large
> 	Community values from a BGP Large Community attribute.
> """
>=20
> I think the above text aligns with your suggestion, right?

Yes, I am fine with the text.

>=20
> > 3.
> >
> > In Section 5 says:
> >    "Operators SHOULD NOT use these Global Administrator values."
> >
> > Later, in Section 6:
> > "The Large BGP Communities Global Administrator field may contain any
> > value, and a Large BGP Communities attribute MUST NOT be considered
> > malformed if the Global Administrator field contains an unallocated,
> > unassigned or reserved ASN or is set to one of the reserved Large BGP
> > Community values defined in Section 5."
> >
> > The "SHOULD NOT", "may contain any value" and "MUST NOT" seems little
> > bit confusion and self-contradiction. Since the first sentence is not
> > a specification to the Large BGP Communities attribute, but just a
> > recommendation to the Operators.
> >
> > How about changing it as:
> >
> > "It is recommended that operators do not use these Global
> > Administrator values."
> >
> > Or using some other similar text.
>=20
> I don't see the contradiction, its text that gradually narrows down into =
specifics
> for specific audiences. The text in section 5 is for operators, the text =
in section
> 6 is for implementors and bgp developers.
> I don't think that removing the 2119 language will increase the clarity.

Although I am not fully convinced, I am OK to move the document forward and=
 let's leave this to the picky IESG review :-)

Best regards,
Mach
>=20
> > Hope this comments helps!
>=20
> Very much appreciated!
>=20
> Kind regards,
>=20
> Job


From nobody Thu Nov 10 07:11:51 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD941296F6 for ; Thu, 10 Nov 2016 07:11:50 -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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, WEIRD_PORT=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 uqNV1a-TeICW for ; Thu, 10 Nov 2016 07:11:47 -0800 (PST)
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0105.outbound.protection.outlook.com [104.47.38.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 3753A129731 for ; Thu, 10 Nov 2016 07:11:41 -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=7/1Q6SF0ucgykYO5BW8JsO4LyHnoZePDk03W7XlaKME=; b=ds5yoKfpSG7gnN6iuz4BTYA7HOKu1Si//9lbI88BFJxESqtsaS+XUWVtKAiOMdG4tkN5+idnqUv7d4OgfyXUYN4LpePX2Pw/1CO2qtykazmwnb4Zthg6hd2oNark6caF5QbbWLrE8BPA1Vd9tPnd4itX365C9zIb6ObE+v3TcMc=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; 
Received: from [172.29.33.184] (66.129.241.13) by CO2PR05MB2504.namprd05.prod.outlook.com (10.166.95.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.5; Thu, 10 Nov 2016 15:11:39 +0000
From: "John G. Scudder" 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 10 Nov 2016 10:11:33 -0500
References: <576FE282-CBBA-4411-9E99-EAEAAD57C573@juniper.net>
To: 
Message-ID: <9BC70810-84EB-4E1C-A759-1C4253C48F7A@juniper.net>
MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Mailer: Apple Mail (2.3124)
X-Originating-IP: [66.129.241.13]
X-ClientProxiedBy: BN6PR03CA0016.namprd03.prod.outlook.com (10.168.230.154) To CO2PR05MB2504.namprd05.prod.outlook.com (10.166.95.150)
X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2504; 2:Bx5aI6a83KJ09vr8kYHlitX74RvmR/VXIxQNhLFvX1HsYo0OPOEUxqkbkIY9TzzeJyhBUiq9PaY1PdEnsl9dgbFqDsijf6GJRcTQ/9NYjfX3eRkTx9/JvqRT1cAWYb1qinXFhg0p7+xfrQZw3raO2JM463rQ7ggDlb/bBdFuMXU=; 3:eywfJDI8D8kTePjuRPMLIUZHqb7zL2kWboyO+Lp92hliBtKmAV9G21Sfc0FcX4IOWzJdNPlKKO0e1fX9uSj7qRRVOFs+QzkYJ6MIj0pp8HUjN0KcAZ0X0q4B/J5VfftWDYhEzDUGNaYmL1Lh41gMiocwftWWs8JJxIsGqI9xkks=
X-MS-Office365-Filtering-Correlation-Id: ec477275-a81c-412d-ffa8-08d4097bdf68
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CO2PR05MB2504;
X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2504; 25:QyhwyE7WtCptZa17+tAfQmMDVXEKNGrxz32auiJpuvwWZFVUirADd+w/5SuuQphdUzoG0sW28YTOvZHxBu3xEPtaZGYvdwAYsYfDXoGzf9FJfLcL+1cUNxgTu0Cf5SXykB7OyYJsb2mIEHEjXrq6cbskO565365MpN+iZdoKYsx6WZTTOn0NZPtf3ZdtC83MxpKzuxK4kp2gDFAwWgndXnOnUVA+uFvU8h5Q1/eaVgVcE4xpuove3QMmni2vx9stBaaa+1zWRwLdM6SnqeefzyKPFgNZj1GG6EyMdkM5jV5rgEMa9DPuoTkP5/zz/JfYWogfcwya6NkcDXBNblwGe+JtJ+xiqBIo0T5oFDQE73RlO2fDJS7ykZvEcZMeUkG28ygkkcPbzZOtu29r8wN6WyJpKX5hxg0ZQ6H5Wq9a/d9LcDU+euWymEDZlfJdc2g9LcQuOHpMH8VRbfkg6blCpkfN1PY1Xztw40/VwtekXGxabsQ/f/GbUfMIV4Wr5823c/wS72aJf/oc7vIygjxT4hTODtp/37z3w453MaBySauQ/l2NUDEDIpJGXt92zIUQwk5LN5rTqkYI6783DKXuPMsVcpXKIffaMnukhP7drdZGauGx4EJf+ZXtddyQohuQdYlZQLtVAPH4z9XT0ldp6EMhPEDP6aYQEcHEqQTwtMSFN8lI9ZXq4OTxKhjYXjlt4nyKiSuQU8UoW3Y4K96AmLXvNThP+TDgAinpIhUweH0DE22GFCLl1n+ziCb0gk9qJ9kMKYX3KujW0sxtUM66VhOp1FsgGez+6V1QCZLsfSXRq/B5ndbFj7Tsrks6h2MR42lWif3sZLuK8QgG65/GIg==
X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2504; 31:eWtLEDzMJQrwUB7SwkouGQiy8vAvQzZj9A8YFyL3aOpEOtmFcSGHMwtcykXpmTMZRO/AbyY6W00KSSIdjAqzvAuoL7UhfjI/ArCyMJ7JRxzsqeAf4UCdNuxSImtHZ9TtMZ1LcA1q7BpPZ7NJl7RTsaQi7mPuR7X4+z7DHIbxlq3qzK8SQ3KThf5Yi68cuBxMm9JWeAcYukIH9oGdBOQCHELBE9mKzurN+UR6H3CZ7LEvu8p/pb2FPGpItHb/msXxLxzW4p1g9YWDzvQCfyZ5rg==; 20:PUwOlr345qfzY6Y7PYcY1MxdJb+15/dDgZPWxbfyw0Me2Pi5oOgaCKkQCF416rJBA0eGMXlJxnolgkLEq4Qkwlb3KEeB8J9Dej9V3gWiB6VVkE/t17ItPrhKvJRYj0eILk4aU101dk+tycUCejmZyy982tf1Em4XskEEwUcyb6vM17dcsjAHY5MBtldsMIvqtHLl3IluPZ9vDjrTFawzOde4GSLPa45Rdsdgh1QzgxsvMBnuLsZITEupceYACKCrTQCcm3ElgWvvSF4nWb2ns30iAA75CpCYSDe5zKA5hAhTQJc6j0LB8yvIipHCdUVGQ6g2tueUgQ9+WV22sRFFBvtWv9/R7tXGFCwle1iD8Qbk8MXXqlB/hx/PujHojYTcSxmws8M9Sa72CSy7k6Pu+Y47orTIbsUzadx7j4DscncfWu7kRyoGrafz4raeMHgvJccHv4sphT0hbo1uEsQejVvhPATcMRciQEosUmFmfdlswngqvQ8Vl0ctM69PhuIdkRsWjoiUcq4TOBQRssPShKGnN3Fuxv2cJvAH1IJetv1vX45ls3F9KRD4ljMEirSAjoKfXIiPqAB0OJOKuu+1ec4D/kC99esHNV80jSkAZhY=
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(138986009662008);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:CO2PR05MB2504; BCL:0; PCL:0; RULEID:; SRVR:CO2PR05MB2504; 
X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2504; 4:a9H/yK+MNMP42D69DvrhxYatRCajpY8XdiX6m5V2GunArrXoCAbKiQmOYsuC0oHgKX8GbdLz/VEAA07JaKMHouetxJw2WTnoBzPuafxENEmsI2063wKZ27thH0teg7sqNQ7ZLdzNY/AolN499e/4rN290OYjoHoFTM9npMwgJf/W70PKSnFnriW6ey6QB+IjIGp4rNm40UOcWPblLPNTXz/Cs2OzbbOQ56//Jm2r8M0h+9ZLTR2oxm3qx9TCmDD2D9PlMDnxnnL0ndjDFR2XuQz0Wjq5637QuDwtLH+LUcVf/kktDtkzji869o5+l+RNiVoir9awEVTdTHYeJG9axmxVJK3siP8AZCvxEj4vIomvFF1IzoLA3An9r1KG8JMVH41rwc3ZPNKcqaK+RxVVpMiB5/USNaIi7tHJvO3y8/DytFj/Pin0+Nmv9Bk3AdUdcMo9xCZoxnaMeL7JhMES2w==
X-Forefront-PRVS: 01221E3973
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(7916002)(279900001)(51874003)(189002)(53754006)(199003)(377454003)(8746002)(305945005)(6916009)(6666003)(7736002)(8676002)(81156014)(92566002)(81166006)(68736007)(42186005)(101416001)(7846002)(50226002)(2906002)(97736004)(110136003)(23726003)(19625305001)(46406003)(33656002)(77096005)(450100001)(5660300001)(86362001)(57306001)(47776003)(50466002)(6116002)(3846002)(97756001)(66066001)(586003)(189998001)(36756003)(107886002)(82746002)(2351001)(83716003)(50986999)(76176999)(106356001)(105586002)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB2504; H:[172.29.33.184]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CO2PR05MB2504; 23:63+w1BzNaMkIEUExzl54c8WVuFErhdIeac8J/wzPW?= =?us-ascii?Q?gs9im/cY0uF8zJATIYqWefHupz+lVU4GUaZpYlP0rexoV7NDyfmTsySOq/xb?= =?us-ascii?Q?/sRknFz/VTi2toQ90x1ztD9ifUsCuP0k51m3M4WEZjDUSdb/cn5FRzzPdQVn?= =?us-ascii?Q?iYy0TROgmoKiIFM/xfPt8PV65MphXIE+CkQ0UEJT1bnt17XXQrKbMny2wkfr?= =?us-ascii?Q?GMhRMLM2LuS1DVQukTv+nr1AA/mzrFfoJCOiDWIWD924tWq93hLiIPRCFdBr?= =?us-ascii?Q?oQmuTUL+kzp10AgjE1TdvzuhHPfBA1+OI+QzJaFNATufjYnHIsPheJSM9jlt?= =?us-ascii?Q?WDbJeHz1wxOKkBI5mywWIFTwZkqJ5RShBi1n4AVDQvn+WHWelv+8ybJboPWW?= =?us-ascii?Q?O+fJIb/j3/jd0qi9f7AZ07a6n+LS0vfgt+2uzS6rYK4Iq3QvLskM41//f00S?= =?us-ascii?Q?DT1WS+6RW4hpOxY+elM6aO5fFzz66Uxrue4bH06AgeruMBCx5THh6X3RnN/6?= =?us-ascii?Q?baCD81NlwI4yMBfh11XXcn/CN6V5sIv+WaSTpf/2ut6X9T3D8r4F8OV0vrf0?= =?us-ascii?Q?+mBcLYUqDopXDotGvpquEuWUUnlp1m+6s5Hp0W+f7arXjKt46mdX10fzc09S?= =?us-ascii?Q?kfTLIfB+QC8Sw0lIzalMsFp6LGS9QBFgCYcygYPbxJePvpLwPjCazBLfy5hp?= =?us-ascii?Q?XHBm9uvb5f+D2MUV+b++spkg4+F3/3a5j47a4ye0RDrgu+lP3owDvEYoaNKq?= =?us-ascii?Q?KQ4R/XnJrUQ/jV3VzSXxHwNeUroNaCmJVjb2eQ8PtfsCCLY3cvv9molrKY/i?= =?us-ascii?Q?PAzuhrx9grLVDO0U3OR+ohOY3VhD05ZHkjRrBXcbHg4FxQw0qWr/w7kr8uhH?= =?us-ascii?Q?PgREwoA+wUNn3xWxodZWwAlgY5jFkNihnrHMFERtWlTS46NCVAAIcSvLpi0G?= =?us-ascii?Q?Gb20KEHHauByWW4mgLZG+xXdZYhE6reYFiPiydN2+L0dBmJsG7rQj9M6f1yU?= =?us-ascii?Q?BvNDHrhM2ZEkNtqNWofCd4DlODqOu9tNjYtkKxTIyF6PVZF24jPuIlZRVH5e?= =?us-ascii?Q?+hOcqlOXCUGbUH8FnQRtWq/g+upZ1E7l0Ffw/6ieo5+j4FGZ25rG27kJnGdN?= =?us-ascii?Q?BHFbsSVn6jArei+zKGpZTyIfXCuzKQYAIDF/Z/wUhCNgm73RaQUkTVrLUIqr?= =?us-ascii?Q?T1F78oYJMNIJJ+LHBYtTBNjN1WgpDitN1uysJCperXN1FH1cwLYF2eThoWzN?= =?us-ascii?Q?W3gmkOh1PkFqU+wio7ZnDZBE5AsiSpX4uEZWVB7toWHNoCxjZMi6DEDL0ftC?= =?us-ascii?B?QT09?=
X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2504; 6:raMWU8zJACqb7qihWg9/3PdJMl8Ow+QISY/JhmmNNVnIgpPdDYvUYc8UA8Rddq0vfHau+SbmR/7+5/GjRDLducQKOpiRvDGb4j1D8MJo81mDxNB0uRkK2DeTgHoXP/Epm+NA1zDQWhFkCtRnF7R2qQZCJfHvwGv2GbnlFza6YnDK6jvK+WDPhvzNxYibCmjyZng5pGv7gSxWklOkE3TLRsyHwhKgm1bHRB/W58lxd9u91CTUzUgwMcnj98cQLu/Q8IErtjKMRsuAAPIvhFTH4Eim/9fjQXtlXcnJ9HKNOUiXWpSMqCWbQ2gXqLduiZ0rhoKqIF9N99mRVDGqFku60Hpr3pL/VkKdxEDQZLS3S4U=; 5:tP8bRGzaWmQgtt+fieFz0iQIUPYmUMgHXdT4QlVf+AuF0JfbGowru0ju7e/Mgk+zZBiQa7Wo9/WaUYImFQyrYEo/U5nY+un78j3ah6tKqCsB2SmE3VV34NBEkJnhZTifLtBVQ5OSD3JfuD0OSikqqatZFZ1+NndirwMHVlSeawM=; 24:0I6wVVOF9mpGIoUnVYOp2pSyi+ti9W/pyjF8jjmJYKwLqI+529c3BljHo2B8XcccF36E0kldZP6tCiXop9X/3ppjuNLLgL1IKmxsKRKZ+Go=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2504; 7:ZIlr2XO12P3IXDjQUw9N8u4TECJtYZuRSPiF1iOPuyS48GrNUSXPWfUEtZ0ccn5cSb+Xke0xJmtBzG79S1oqYGT2kKsGZN9pROHsOJyZ6y3HTv2kLMQxempCk9Tgv3tEWSNIPQgahjO5MrBJ+sf8yUJEQWEBWsG63RDlY9H3JD0nnH1rIzLs6yfzPkGQ3Mx7HtKsB+jRD60mpjxaH9V8SlyheEQK6zD31q//sZ7hG3yj+MBt9h9KuyuoQLUqD9pHQOO49ozTGxJz+9MDfw1FzM3I2TKFAOsJSMsRE9myX3PTI/Sar/iPlDsnEu5Rl3MpTit2Ye5EmAddIIY9Yornn9fbJb3vq4sJNRxTz2BXcpU=
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Nov 2016 15:11:39.5116 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB2504
Archived-At: 
Subject: [Idr] IETF-97 IDR meeting logistics, second call for volunteers
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, 10 Nov 2016 15:11:50 -0000

Hi Everyone,

Still looking for volunteers. Please consider stepping up.=20

It's been raised to me unicast that note-taking can be problematic for =
those wanting to actively contribute at the mic. If this is discouraging =
you from volunteering, please let the chairs know, maybe we can work =
something out, for example we can make an exception for the scribe when =
closing the mic line. This is also a perfect use for the collaborative =
note-taking approach -- if there is a main note-taker but also one or =
more people who volunteer to assist, if the main person goes to the mic, =
the others can fill in until the main one is back at their keyboard.

Speakers should also be well along in preparing their slides at this =
point. If you have draft slides, please consider sharing them, and let =
the chairs know if it's OK to publish them to the meeting materials =
site. You can still update them up to 24 hours before the meeting, but =
not having to do it all at the last minute helps. =
(https://trac.tools.ietf.org/wg/idr/trac/wiki/Checklist%20for%20presenting=
%20at%20an%20IDR%20meeting)

Thanks,

--John

> Begin forwarded message:
>=20
> From: "John G. Scudder" 
> Subject: [Idr] IETF-97 IDR meeting logistics, first call for =
volunteers
> Date: November 5, 2016 at 1:27:20 PM EDT
> To: 
>=20
> Hi Everybody,
>=20
> In case you hadn't noticed yet, we have a completely full agenda for =
Korea. This means that if we want to have a productive meeting, we will =
need to start punctually. Our meeting time follows the afternoon =
beverage and snack break,  if you plan to attend please try to be in the =
room and settled down by our scheduled 15:50 start time.
>=20
> We also will need to have at least one note-taker, and it would be =
very helpful to have a Jabber scribe since I know some WG members will =
be remote this time. The chairs (and WG!) would appreciate it you =
volunteer ahead of time. As most of you know, if we don't have =
volunteers ahead of time, it means we aren't able to start the meeting =
punctually and have to go through the phase of everyone awkwardly =
pretending to be very busy reading their mail while the chairs try to =
catch the eye of a victimteer.
>=20
> Note-taking:=20
>=20
> For those who haven't done this before, note-taking doesn't require =
capturing a full transcript. In particular, anything shown on the slides =
need not appear in the notes. The most important thing is for the notes =
to capture questions and answers, and especially decisions and action =
items. One good option for note-taking is Etherpad, a collaborative =
editor linked from the datatracker agenda =
(http://etherpad.tools.ietf.org:9000/p/notes-ietf-97-idr?useMonospaceFont=3D=
true). While it's beneficial to use this since others can pitch in and =
help with the notes, if you're willing to volunteer but aren't =
comfortable using Etherpad, that's fine. Use whatever application you're =
comfortable with, even a yellow pad and pencil if you must.
>=20
> If two or more people want to volunteer to collaboratively take notes, =
so that no single person has the complete load, that would be fine.
>=20
> Going to the mic:
>=20
> If you make a comment at the mic, of course you should state your =
name, and you probably should enunciate it more slowly and clearly than =
you intuitively think is necessary because the person taking the notes =
might not get it right otherwise. You should also consider =
double-checking the notes in Etherpad to make sure your name got spelled =
right, and while you're at it you can make sure your comment was =
represented accurately.
>=20
> Jabber:
>=20
> Similar to note-taking, being Jabber scribe doesn't mean you have to =
capture a full transcript. Primarily, our request is that you make it =
known to the Jabber room that you are available to relay questions to =
the mic. If you want to also keep the Jabber room apprised of what slide =
is currently being projected, that would be great too. (For convenience =
in doing this, presenters are all asked to number their slides.) The =
Jabber room is also linked from the datatracker agenda =
(xmpp:idr@jabber.ietf.org?join).
>=20
> Thanks in advance, and I'll send this out again as a reminder closer =
to the meeting time.
>=20
> --John
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr


From nobody Thu Nov 10 14:36:16 2016
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 74C5A12986F; Thu, 10 Nov 2016 14:36:14 -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.37.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <147881737447.19568.6243042923882629926.idtracker@ietfa.amsl.com>
Date: Thu, 10 Nov 2016 14:36:14 -0800
Archived-At: 
Subject: [Idr] The IDR WG has placed draft-snijders-idr-deprecate-30-31-129 in state "Call For Adoption By WG Issued"
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, 10 Nov 2016 22:36:14 -0000

The IDR WG has placed draft-snijders-idr-deprecate-30-31-129 in state 
Call For Adoption By WG Issued (entered by Susan Hares)

The document is available at
https://datatracker.ietf.org/doc/draft-snijders-idr-deprecate-30-31-129/


From nobody Fri Nov 11 06:40:39 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F4FB12954F for ; Fri, 11 Nov 2016 06:40:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.503
X-Spam-Level: 
X-Spam-Status: No, score=-0.503 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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 X3HUSiOD7003 for ; Fri, 11 Nov 2016 06:40:34 -0800 (PST)
Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.137]) by ietfa.amsl.com (Postfix) with ESMTP id 6A7531299A3 for ; Fri, 11 Nov 2016 06:40:32 -0800 (PST)
Received: from [85.158.139.163] by server-1.bemta-5.messagelabs.com id 8F/95-16850-F58D5285; Fri, 11 Nov 2016 14:40:31 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgleJIrShJLcpLzFFi42IJWKH5VTf+hmq EwdOz4havbj9jcmD0WLLkJ1MAYxRrZl5SfkUCa8aLnlbGAtmKpxO3MDYwynQxcnEICRxgkjg5 fy07hLOWUWJ1Uz9bFyMnB5uAkcSEdftZuhg5OEQEFCVWfkoGCQsLlEisO38NrEREoFRi+sepL BC2nsSrOSdZQWwWAVWJyxOngtm8AvYS3a+uMIPYjAKyEl8aV4PZzALiEreezGcCsSUEBCSW7D nPDGGLSrx8/A+sVxRo5qfbq1kg4goSFxd0sYGcwyygKbF+lz7EGFuJrfNvQI1UlJjS/ZAdYq2 gxMmZT1gmMArPQrJtFkL3LCTds5B0z0LSvYCRdRWjRnFqUVlqka6RmV5SUWZ6RkluYmaOrqGB qV5uanFxYnpqTmJSsV5yfu4mRmA81DMwMO5gvD3Z7xCjJAeTkihv+iXVCCG+pPyUyozE4oz4o tKc1OJDjDIcHEoSvHrXgXKCRanpqRVpmTnAyIRJS3DwKInwsoGkeYsLEnOLM9MhUqcYjTkWnX j+gInj3eZ3D5iEWPLy81KlxHmtQUoFQEozSvPgBsESxiVGWSlhXkYGBgYhnoLUotzMElT5V4z iHIxKwrwhIFN4MvNK4Pa9AjqFCeiUGXEqIKeUJCKkpBoYM39dXF5ZrSP3bB7jpPypS/V4y+9s ecc9teH5yXOvPziqBatJ79uyZlqbTKXBUQnNeN8Avj616+maW2/vbSxL7V6sVKd2VU3ii0ysx Ivw5xO0zObMVXeeuz2OuWC5yUxzg2fTTmxhzp8S6LO4+83CLe/fvj3yiddM8mrcicRFEc+PHl Od7/k0WImlOCPRUIu5qDgRADgD/xQTAwAA
X-Env-Sender: david.freedman@uk.clara.net
X-Msg-Ref: server-2.tower-188.messagelabs.com!1478875231!71935655!1
X-Originating-IP: [80.168.41.245]
X-StarScan-Received: 
X-StarScan-Version: 9.0.13; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30113 invoked from network); 11 Nov 2016 14:40:31 -0000
Received: from staff03.mail.eu.clara.net (HELO staff03.mail.eu.clara.net) (80.168.41.245) by server-2.tower-188.messagelabs.com with SMTP; 11 Nov 2016 14:40:31 -0000
Received: from [80.168.41.252] (port=6471 helo=SRVGREXCAS02.claranet.local) by staff03.mail.eu.clara.net (staff03.mail.eu.clara.net [80.168.41.245]:25) with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) id 1c5D0J-0007a8-AN  for idr@ietf.org (return-path ); Fri, 11 Nov 2016 14:40:31 +0000
Received: from SRVGREXMB01.claranet.local ([fe80::64bc:5d10:5203:a830]) by SRVGREXCAS02.claranet.local ([::1]) with mapi id 14.03.0319.002; Fri, 11 Nov 2016 14:38:14 +0000
From: David Freedman 
To: "idr@ietf.org" 
Thread-Topic: The IDR WG has placed draft-snijders-idr-deprecate-30-31-129 in state "Call For Adoption By WG Issued"
Thread-Index: AQHSPCk7i8LxU2YxskyR9uTZHh/Gow==
Date: Fri, 11 Nov 2016 14:38:13 +0000
Message-ID: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.1b.0.161010
x-originating-ip: [172.26.6.254]
Content-Type: text/plain; charset="utf-8"
Content-ID: <79610D4E78442A428A10AE9FBF7C806B@claranet.local>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Idr] The IDR WG has placed draft-snijders-idr-deprecate-30-31-129 in state "Call For Adoption By WG Issued"
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, 11 Nov 2016 14:40:38 -0000

U3VwcG9ydC4NCg0KRGF2ZS4NCg0K


From nobody Fri Nov 11 08:52:45 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88DC51297C4 for ; Fri, 11 Nov 2016 08:52:43 -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, 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bskyb.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 BwW1j6pnisrw for ; Fri, 11 Nov 2016 08:52:41 -0800 (PST)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0067.outbound.protection.outlook.com [104.47.1.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E470D12961D for ; Fri, 11 Nov 2016 08:52:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=BSkyB.onmicrosoft.com;  s=selector1-sky-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version;  bh=4Q6VQ3whAkXeUmf9XPYUeSkK+riaWaG3mi/cHaR6bjY=; b=ZS5Bbcmun/YWyN/fUYPnPkkhtJDAx7IKExRIVWNpHtvgxQ7J6MGzhhMwBk32xu6kOzRc+7rmGFxSO5vW9U6doVoVwPwZVKr0dWDhnAsrlK9bplzJOIWYEVEoCiOv77d2doSj5WcWHMOhYunB9kGA2+qMl4thT9f0H9WdCN+QN0Q=
Authentication-Results: spf=pass (sender IP is 176.255.244.223) smtp.mailfrom=sky.uk; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=pass action=none header.from=sky.uk;
Received-SPF: Pass (protection.outlook.com: domain of sky.uk designates 176.255.244.223 as permitted sender) receiver=protection.outlook.com; client-ip=176.255.244.223; helo=email.bskyb.com;
X-IncomingTopHeaderMarker: OriginalChecksum:; UpperCasedChecksum:; SizeAsReceived:1286; Count:20
From: "Dickinson, Ian" 
To: David Freedman , "idr@ietf.org" 
Thread-Topic: The IDR WG has placed draft-snijders-idr-deprecate-30-31-129 in state "Call For Adoption By WG Issued"
Thread-Index: AQHSPCk7i8LxU2YxskyR9uTZHh/Go6DT/27A
Date: Fri, 11 Nov 2016 16:52:35 +0000
Message-ID: <9B3BFE0A18160E40BAF1950414D10FAE61715E6C@WPMBX010.bskyb.com>
References: 
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [191.255.72.199]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-IncomingHeaderCount: 20
X-EOPAttributedMessage: 0
X-MS-Office365-Filtering-HT: Tenant
X-Forefront-Antispam-Report: CIP:176.255.244.223; IPV:CAL; SCL:-1; CTRY:GB; EFV:NLI; SFV:NSPM; SFS:(10009020)(6009001)(7916002)(2980300002)(438002)(189002)(5423002)(13464003)(199003)(106116001)(102836003)(2920100001)(5001770100001)(586003)(106466001)(55846006)(229853002)(50466002)(46406003)(87936001)(107886002)(11286001)(92566002)(189998001)(7736002)(5660300001)(5890100001)(7846002)(74482002)(9686002)(3846002)(50986999)(6116002)(230783001)(69596002)(54356999)(8676002)(26826002)(66066001)(47776003)(86362001)(81166006)(2501003)(2950100002)(81156014)(23726003)(33656002)(305945005)(8746002)(8936002)(2906002)(97756001)(76176999); DIR:OUT; SFP:1101; SCL:1; SRVR:AMSPR07MB147; H:email.bskyb.com; FPR:; SPF:Pass; PTR:b0fff4df.bb.sky.com; MX:1; A:0; LANG:en; 
X-Microsoft-Exchange-Diagnostics: 1; DB3FFO11FD037; 1:mq93RFVqxGQAVPG7yk1xim5HeF+e7bEi0lawCTMljgRfundHqtEVqALLXXI8rZfat0/zPnFwV2alSx1HE/O7jJDIXSt4d+8+v2wwhPA+V62zNQTqZOhz6qp4V/a7sR9imG4MURebIiapNlT+RG2WqkttUsteNN8ibMXGQJTBVbJCuZfFjA6xkmi1XRVKo09HeOm5jL8OQMkv8AV42TmW9I/Tx2vnBIpG9nBMxQGQq4GuEwVLioj0u8TU+NuJ8mI+Ks6mYV0/5N78X3a8dyNoqnr4G5cszLEld44OknlwVWUqnk7IZyUr1bZ3bXSBsVR3LcXkA8kRJngXHXL80ie4y3Ww+Odrg8+fS/miPvpm1L4LBpFMMzHJcDcnd6hUayxhKwgBYORbDfvZBiugv0CJK237RRfakO9+YfKYFQXsBjECpxrk9WAeOKkL5mOwyC262gst2OQBWOS7EHmoDJ/MMgJqjSoTLUjo5LfwYUwdWQyJeNrdYh2DOknZQo2S4xPhGbg+c0ymUgCA89CwIyqbT14TwxC3d3jQG7yUaUQ0TXapH4Tfng9j0vaSgGput56edZeM8jpuBypxzRYxaY/+Gw==
X-Microsoft-Exchange-Diagnostics: 1; AMSPR07MB147; 2:Hv76HskOGYKeUfzQ0euVDigRm0siyVpiopRx4JEccWVkKO26DwijVnMtA8VZadYeuD/kJnbxP/k+Mr6TYD9mlltzHbOlMiSMzcslbG+I1AmJ8b9w2lzTt4WB7mw8K5DS/+2acgoSwTZcFRziu/Mrzvj+MvnbAoqimd7tMi808NE=; 3:qKEN4oZBNp7LqHgAyRJ3hoRelOU4EjXWomth39xGrXJIP2/SOXtmQa++7EgBoZxuiUIYMI/G3SK2otpc2riJz1alrDoQP9rpS4UvWNc9m7DP48k2IP4dvft52AG264RDW3+DfsXgdXHBu4kjxeDRMN6Z101SKKRhsSbOSly+Lksu61Qbdy7e6cPqCNbaroybESBuJoEFojuZuomJjR6xsxVvpqUZROe3KDUeJTQDeZZKwrGs2t8h4Q9RQGoeCGpUkZwdftX/mgXk3mF04IYaHdUJTM0JDccDHmjLW6ObLX4=
X-MS-Office365-Filtering-Correlation-Id: 5df30f12-453f-4109-610d-08d40a532458
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(8251501002); SRVR:AMSPR07MB147; 
X-Microsoft-Exchange-Diagnostics: 1; AMSPR07MB147; 25:/ewBk4DHz5ia4doQyqz3XVhyxAwswhxBufQhv8PH3DyIJNAYzrJTrnRyIFN2ULRNjy0pUxJioIpaA9Lru4lOaKSbHNpbaBz8WFzMATR6eoJs/zcIA91xfXE2A+JB5J6t/zKnfdYJ3SHvYf/CCcNFY/P+P1MVr9lQcDMvBhQxvv5tSWgLe1B7KEkwIZwiOUgspfZBDUIJC/gMvB8dzhQQrOdrkHiRWl1DxiFM1YwYmJB+sk6Pilrvjx/uSYjYKLVkuX8ErGCHyyCBAzEGJCMOkeH2hjxQqystn3uUsjMhruEXeBae3PGjU2MkFF5FYW4IvDhZfkTPBGuTpJMgVBMS3gbSN8bs8IyK8AETZk867Rjpcb0C33UtYoTZlB1dssd/Ax4EUi7MKLNvTWCtqQ+vMCDc6XjTVg/BeP2n3TL5XzbbopXRUkMIn9Puz3vh8uPfqwA/oCRc2zgFybjgAlPYMKzbqdgozn3g3tevGJnC8yzM9AwGzSb2FhAfzHj3qGIiH59cwI8MGtL+1EZg3bhAiUgUV2Vvj7EexzfBIkwdk8H4N5X2GBydaYzWBXB0G5IujlhD0BZGFe61od6QMgXfI5s2eTo9+R3M5GIKr+KoxGMY8+AnvZOIymTKbiBiMAzKtbOxZ7BFqvPtnarSSISr8v8lcxjXmaGOoFQbFLU6FS/ji1cqT1xnHmLk+CFu9VyfKnvjYkmtrdfXPR364uwZ7ygt0X9+9o59xrhZzpJihPcDeJe88tXgkGnKRlcAlOJt2Y2EIZMDHvur29Q0iR0B+JZYxOGj48btcwbVwYcp7rPJlXEJ+T0TjsT0yDili3NOSLdNlTxHkLBDIsBSlImWV7Ak67pkrkypPq3uM47Ik7EK8bZ20/FhpFmsBRX4JteQ3nmVneGyqsIdmNn8em0bUVtw9crOnRrcmfEi5xI32LVUxLnHOXKgv0QRBumvNZAc
X-Microsoft-Exchange-Diagnostics: 1; AMSPR07MB147; 31:qGOI7hedMwJAmyuU0XMdilzzRSsL64FJqfJBONVGNsVwNpqlAUQ7hDZClMk9wOUzMdsUH+q1cFyHqBlpEcAsra5bvL//FuLarFf4Sc9ANP1ht5WyO4xur2YM1NvnvgJKNBS+Ocx1xky8wO94R4awMEe9U0dXx7Ig4Ico0oFLAJ0KMnoYi8FbA8S6JuGtvka3cVIoSdkQ08ZJxfWSpCJX6IttamrDewpNiK80HSGQR6M9NJ+hRUBFQG6x7jb0FUoKuGX5wEquUZ4LlhCCpCaPrg==; 20:IOWej93i/IM5/p8/D/PREmZRmt5kQ/eqqbTsQIiAYEcKQ4Inl8y0uwZif3LhnlSWXIFJPLOHlz/xPasbR0vVm3ZbtRnhZXFT3HNvbMGCoFKISRUoXQyXsSrX0nsGD1Os5akLHG4w281psiap5F46Af/QC2hVfO8FC3AIo1Yl3mYm82N+CSFHZER6nNFZrDAQenetJQfVWhwK46gKLSmr6eloT0JEsl/PCYwKbL5Hhg4Mg7Zac3qLZxoET0t/ln2I1pL2eF2TyT2DmC3VGHn3uryM3V7G6SfENim+L4am5B1AiBafVpaCCc+PeZwIlcxBOhNx5GLhGk95MIeHDtuu2rlIncFeKWIsTCV5OH06PNueR7f2iTsxhphHNoYDwQaGsalrh0jSef291rhGOaHKvXZ44pk16vEmi2FTqRDtpxo0kC5xWtjEnGcn6aCdlzvfYz8Zat+g16BoPOUW9mwCIHnW6hPRpBgViJ4DA8KoZO3miWLNjEVOxmuU7636tvkk
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6060305)(601004)(2401047)(13012025)(8121501046)(5005006)(13020025)(10201501046)(3002001)(6055026)(6061300); SRVR:AMSPR07MB147; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB147; 
X-Microsoft-Exchange-Diagnostics: 1; AMSPR07MB147; 4:gm1mG2fWO1JyqtbnGB+/SGR2yEhPyJNgR5q0FLGV0UL8OfM04l143ezCwLXUJ5yEhyDk7eLwxp9EMACcZddMdcuG7B/rG8n2oa9IUQLwCy9CIZQc+zYYJZuAMq46UWFc7pzw4aw9GnULL7dhQhkJWmpqn2gMMh7OIANAIOTb8uEREX9qWqboCvnNnSaQWSZfRf88ApmrqJdHOxLMbYmTm2chrZtmC7baCiM6luOQJ/q3GjqX1VTMIBjDlK2r8qx1cJScAVMNWzqu+P7hs6CE4124PN8UDpdEztab7garSAzcm7g8DklFcEEzMMdOk/gsNtFQKmc3H673TIw09mybXyF4hwycEBGoH210exEipk6yccFrjOr79nASUoji5PZMhZp6MAlt5K0v+LheX4YXxA4drwYYr82Dqf1z2wQVGbbOZ/1LvLFsrLTjNBBQdzj5K6ZWvz8WWwNES7ZD9RRojMHl+NnyL1SY9D3wML6lI9E=
X-Forefront-PRVS: 012349AD1C
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; AMSPR07MB147; 23:zC6wyAZZNN71g+9IeGLhhQE2ngAU8Kl2tD7Flunu8L?= =?us-ascii?Q?Eu+iGTsMOyejILXkvbdoxDZJYghi/6cOW7W/FFR6vXBHHm7LbwbRhM7tJkLB?= =?us-ascii?Q?TtVcR9eqKIQK2N6rz8WVqMILmnn2GvUCWCSell3oLFt3DlJACznZkSpLOJn5?= =?us-ascii?Q?dplP/BRnk2KbcIOZCfyBgbhlRD7M9h/ihGMBDH2ilNuCEizhZu9Bi0+W0ye/?= =?us-ascii?Q?Niue2BqaSqpBHXGo/U5cRWfQ3RgC2PMMZJalLgzkkZ0Bk5Rw25UL2FT3pktQ?= =?us-ascii?Q?xiOfWKn/2EoObS4Qgo3+UpTKGOvumQ3I+us+zHjmsuxUeAVpQo/izkAmzB/0?= =?us-ascii?Q?Of9IyhEPKCBCZ1LLHcnVwMpCHYwGE/mqWKLGgWnO+ZO4Yii+8vrIiLhyl+ov?= =?us-ascii?Q?JnfEoDzIT5AjPYpXGdnUUTQiVYWkxLFYsYmbkeH99cMlmdiRXXcx9v/2jvCV?= =?us-ascii?Q?CeTZ4NPM/k2oNnc1Xfrplsbq6sbxAE9Y5ZG2rFFV0LpL0nsopEjChcEqFTx3?= =?us-ascii?Q?YqMZy172QvshGtbRF6vrajM3gaq6NIHrUOrCcEuUsuBwQvOqTCELPuZuBxkM?= =?us-ascii?Q?K1Td0pWb4MdD2V6KKFanZoa/X2pB0VlYx47Gi1OvNNV6MYLvnA6VRM/91RML?= =?us-ascii?Q?ZAPDEN1+gskaF73TiNy2PomODbttqrpzTrB3MBWkGnw9z0NKz8oDnB7mH9zv?= =?us-ascii?Q?QSvQpwVXAyeybwqER2hcWJEUjFJKecWquZY3Td18ePxhyZZy1l/qyVSS4TJz?= =?us-ascii?Q?vDHUk+ZsR/OKIOC3i02wbEK7wwJxRbKfZ4A8nq4cf6StVQzTL5WUAfeqqNz+?= =?us-ascii?Q?JCSVFJGp0UQHJn0vmmSwPZug/KoG7f9D2a9voSIuKj9SuMk5AFDdwEmBCmoM?= =?us-ascii?Q?XeZiE1VRlIJ7pge4POFiwK1JMObp6wZn0OqQf1TjMpXm0rG01x45qkrMYbgX?= =?us-ascii?Q?b2DM7SPQEpXPO35no4CG4kyboXMqWrHB87Kan4PcfsCEq7ZLPo8JqOXNUwgE?= =?us-ascii?Q?5m7kNK6UrGfgPL0fOK+k5wplZYKmDzCGM0Vc/4TfFvQ6xvl6JTXJu4YHxGGt?= =?us-ascii?Q?kO6iIV4cb4rjOaWldlWhEqkAjuCKYLsL008dxMUHU003TzAlxOvKjQtYPxCK?= =?us-ascii?Q?u5VqIWimP17X9n3sU7YMpB0b++Hv80ZTJ9SFohXWwlm8YvGWzQ/KXuuIrq/X?= =?us-ascii?Q?3JKrZ4g07hLbJi/N3J63xOnLL+K6EfysZXDBcyFH4qWfxR+cInqUDV9GdfVV?= =?us-ascii?Q?aaR7HA15BxDseTctTcJ7Gd88gIYvpfssqsrh3Z?=
X-Microsoft-Exchange-Diagnostics: 1; AMSPR07MB147; 6:VKf/4WZ4iI/L2zDh6RZPwlVflYnmd++fvwkJVIMbm5lr76imPzJ9sBDGrsa5CDMFupfjOZ1Stnh1bbmZns5yfXFGg4VFKFbq5+6nfAzw/gZ2sihdQHnVs/vubt6UOHhWnh9XX+nBTMYMg49Bpcxz+NnDuRxdw4B0jie3VBhE/hwCQ5KL4NNDiMHUxv4VFY8X1sS3By3fKCaeVnc8RscRkBa7jAEOQHsLdqOuNAC5rEjZncSl/GW2ZNkVeHPdiz2zAEruN1guBJXcPIdSQVAkzYXKWJmvUqtuWmfgWUrO1ptXQSgiipwEIZQMKwtYmImEPdthwTozJ4w3/0RUeoi3vnlD3xUNA9M1xSlPuZ2mR3M=; 5:b/I4QyPTMEI8yJn5qrS0WY4RSnch+YIEq0r/gcJzyWcbRlLd2jOuEPGsDrydmoyITE20eBd7GaaH8BcuJyDWLPeHffovnuzqBNGfZoqMxZ0Eehta3gNGP6F3oP5Ro1PJybqQD7wz6X03jMmehqk4mg==; 24:yTvNqSr7xEE00iXQ7V06zjeNubumBGLFesFo35tnK/iHljNRIfbWcOTF94B0piU30Mbdbjd1x2X9HBhoNKBdBhmuwpKvnqdiNekunaERy+0=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; AMSPR07MB147; 7:kwG8kJHMr4WdxJUAvGJIIprmWJDqPHPvDBl+8CYxUveg3HXNtGSJ02lD2/67oeNHwiZS/QvvMIvbI/vekmj6hrmnGYffC0OxiOKsQic1akJ2gkuGaCfSdYpE8gPNT1PqrDkkbc9uOBT2LWBt4d6Z8ZizoaI8CcYEOOSmt9DSf1uUKYUEdGVksRzeTvCEntfOAuHke/F7GONXhAjIvXARqGIBaLDrkXfgiK9jD9YYm2833kqYx0ZtOIFFR8IDKCJYb/mxnkaRvaJ+wEVVv8qTrnO2JYKjsDs1ZcaZ3Yu6lC/iGGBy1pt99G4rDIR7JgNtfufP1ZTewhFZzqBmf2HyqAgR3nAUYRiUl0D/d06dzIo=
X-OriginatorOrg: sky.uk
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Nov 2016 16:52:37.1921 (UTC)
X-MS-Exchange-CrossTenant-Id: 4f86cebc-57e2-40a0-86cc-01d73be93ba0
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f86cebc-57e2-40a0-86cc-01d73be93ba0; Ip=[176.255.244.223];  Helo=[email.bskyb.com]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB147
Archived-At: 
Subject: Re: [Idr] The IDR WG has placed draft-snijders-idr-deprecate-30-31-129 in state "Call For Adoption By WG Issued"
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, 11 Nov 2016 16:52:43 -0000

I also support adoption

Ian

-----Original Message-----
From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of David Freedman
Sent: 11 November 2016 14:38
To: idr@ietf.org
Subject: Re: [Idr] The IDR WG has placed draft-snijders-idr-deprecate-30-31=
-129 in state "Call For Adoption By WG Issued"

Support.

Dave.

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr
Information in this email including any attachments may be privileged, conf=
idential and is intended exclusively for the addressee. The views expressed=
 may not be official policy, but the personal views of the originator. If y=
ou have received it in error, please notify the sender by return e-mail and=
 delete it from your system. You should not reproduce, distribute, store, r=
etransmit, use or disclose its contents to anyone. Please note we reserve t=
he right to monitor all e-mail communication through our internal and exter=
nal networks. SKY and the SKY marks are trademarks of Sky plc and Sky Inter=
national AG and are used under licence.

Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Reg=
istration No. 2067075) and Sky Subscribers Services Limited (Registration N=
o. 2340150) are direct or indirect subsidiaries of Sky plc (Registration No=
. 2247735). All of the companies mentioned in this paragraph are incorporat=
ed in England and Wales and share the same registered office at Grant Way, =
Isleworth, Middlesex TW7 5QD.


From nobody Fri Nov 11 08:59:57 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F28731294D0; Fri, 11 Nov 2016 08:59:56 -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=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 gnxZiAU7ABD8; Fri, 11 Nov 2016 08:59:55 -0800 (PST)
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10090.outbound.protection.outlook.com [40.107.1.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D181129871; Fri, 11 Nov 2016 08:59:53 -0800 (PST)
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=WsGV5NGrKUKPP14uoRHT96nlAexnLYYWZOouOleQM6Y=; b=kOYMBg2C60dP69s2YNeNidMll+iQHNUOMIf30t9U3jbC9HRcg+ztGnVx+DQGKrEpqBBkENiN+Mtdu5lr4EiTA/aAO1DZ+hnpM2TevHfnlKOBYC1w0YB+gEhb7kcFZeQx0lBJ1t1w6Tp8/2SGb04Yonp2bFJHAekRLXeizwMLcTs=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
Received: from pc6 (81.135.210.62) by AM5PR0701MB2993.eurprd07.prod.outlook.com (10.168.156.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.721.10; Fri, 11 Nov 2016 16:59:50 +0000
Message-ID: <007f01d23c3c$992f8ba0$4001a8c0@gateway.2wire.net>
From: t.petch 
To: , idr 
References: <147881737447.19568.6243042923882629926.idtracker@ietfa.amsl.com>
Date: Fri, 11 Nov 2016 16:56:40 +0000
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: [81.135.210.62]
X-ClientProxiedBy: HE1PR06CA0076.eurprd06.prod.outlook.com (10.164.28.172) To AM5PR0701MB2993.eurprd07.prod.outlook.com (10.168.156.143)
X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2993; 2:8PlL+uQEYhhN2oxT2uee1XCgY7ycUpTNqO8ZHNFsMAY+1cM781K96lMy0kysj99DL7l9ZaHoN0dM/voD1pjpqYgCMyEcbEEojsaKqxfANzOMARrfecuh51QIv4FdUo0z9v0Ifa7YO5qbnXXneyToPBDeoQO4TakGvOJ84CBA+Jo=; 3:zdY6iBTaKgxdj5kNE+VDnpAq56/qnahkcWP6PIUu/ZkuEt+csZAxXT5J5o3wfP3kLZpQViuwfGxe1Blqr9d7tmGIN3UNwDLbpGu45KErcGYYYirMHD35h/0ggbUu722LtWlC2EqsYbaUVCGngOFiYcLqz5KQHm38vrKomQQu7Hs=
X-MS-Office365-Filtering-Correlation-Id: 7bce897c-3d26-4079-7773-08d40a5426d9
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:AM5PR0701MB2993; 
X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2993; 25:ucrWZNrqAA0G2YKsbPfMk7GaLhQtqs30b/4dqlQgxhj4npsirxJDlnnRHgpDu6WxH1D3Q4IuNWDjptyIHh7I0iJoDsvWtoHDQKzn5GTulYst49qN9GiJQxae2Dzhg0gUQhEP6lk9mJwN9EVH0kNpu6MGPvMzCjb8g4QZVfRyngDfrA0HROxb/oMSR58+jiqw9+y90vIvVbhHFGkfMbBtiuJHFp2w2CjWpspZL+BfRu38kzVG+CYW2khv+RgzUXJLQMPXTCgwrSmQIqyl0dwQe9wWis/D6/BaLprS2MxVUJX5nFmpIuqHbj7HcWoHNo3+H0jtWv2flv4zSul0vwyaRNoatjwm9lZz0UKYlmUrxIseoXTaQ0QR2JeT/7AyAo78OHXABweVMaDYGZbVJgYnHLTCs1PFsY6vP85IIpuip9NqxHIqd9sa4MZlwSEArBA3PuPIWuWWN1uzC3a/zg923xMLaXOi1oSkKCHLu+EHy3IMVZ/6zulabnaadInEPH56VobCf/Gfg33jaNESyKj97jHklqdwhjjVmRfyGrh2DLYl5V57WES77UEa6y1XcCDGTHRgrmuh4ufSrJgd4Mo3QPaJPgm+kFFhn0JeDQ9kHoxYf1f+SqxhTgLaE2t09AxgIUR9FYniX/nvtwkW/anomQmwXP6OEAHolteGh0UMab3+GWrhkX9ISiOHfdGwyRgQ9LItLUUkWhqJ0MLAl223GL3V3W1ie49UOsoB/8G5I8diJEm37Leww4uk0EfNoMIR6iuUNMk4z3KrGN6Jft6VwVCu946rkUsuy8+foBN7iksQ8FHYUeXi5Qz7RR4xkOhZigfbXj6ibgOv98y2+Pib+A==
X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2993; 31:L73bKvl1+pJ9hDl+J7CMLaQk9XGnrGfpnqiAjvDC65hQVjYEAiTUMBGRz4W94siOi7SnpxIcbRbYMGemHWGIdhfuwKhaCZrYhjBp1cCAi6nErmkThcRaGUVbJM4bOubODFesTK9qiB0fcNBAI41OJJY2fZdnQErbnAsN5UKDivnqQfapCOz4kd375wThS5Uwrv5CUS9TrIBi0Nyb3rkY1HE3FyelLAANQj1hsW2FVrYagUbqemgeMRl9l60laz0lbZ/j9ZVgrBM9HYaqE411aA==; 4:sjZMPl8dlvIDtLP33TCStxIWeKb3viA0Gci4jaSd7kCcy9eb+EqWtt6hE2DmuKa/99kkk7ELchD0W6XqrpmFckRGdqKLbzwzHRzD2AVluaS7vkCxmpyexzTuAe7L/atbfenBmDwuiIiVrzHeQEARyVkOLc7+JiEfv3H7a8+4s+73+q0nMS3dP+01AyLyhLO+nqWDYVB3yMcsTYoPhG8pEkoeS7YkKEjAuo5Y59NEyQzCUxZ1Eh/mpNbwp8WwIycCaWtGwECuftsuX3BIuN3+u1zPKUTmBFcDk4ZZxOzX4ok05Dh+F0u9PR50JeUVNLDGQj/UooOs+3fY7gYZbd6L0pVtn6FxmhuytYZtNYPwrApfkRzUqPp3sp1eXVI2QwmK3GNnPSm5Qx5uniMRUHwy5Gkl3AXlXKMsmdGM0zwhTZYntTdfjx+GunqgZSk1iZum
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(120809045254105);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046);  SRVR:AM5PR0701MB2993; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2993; 
X-Forefront-PRVS: 012349AD1C
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(199003)(13464003)(189002)(5423002)(377454003)(47776003)(450100001)(1456003)(44716002)(1556002)(77096005)(92566002)(4720700003)(61296003)(106356001)(229853002)(230700001)(14496001)(62236002)(66066001)(86362001)(81166006)(8676002)(81156014)(42186005)(81816999)(3846002)(50986999)(76176999)(586003)(44736004)(6666003)(6116002)(7846002)(105586002)(9686002)(81686999)(50226002)(5001770100001)(33646002)(50466002)(97736004)(305945005)(7736002)(2906002)(101416001)(68736007)(189998001)(107886002)(23756003)(5660300001)(84392002)(116806002)(230783001)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2993; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; 
Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; AM5PR0701MB2993; 23:8p8uhD41AGqSXds4aaVBfzOb0TTDhXHzb+0Jx?= =?iso-8859-1?Q?qdREZImQULilLzEgFJ15BDNoWZAuZqsO0f43i2+vh/fzkTziLH2OkhBGaV?= =?iso-8859-1?Q?si02eK88oYEYgY9XbNVziNU4zRLIDRDc8/1Iau+n4tcppQ5cYS5JvbRXGN?= =?iso-8859-1?Q?02E1r1KfiUlIf1ZfEO8AFd30o0AQzR1tWPmL+ez1EKmacdu3Se+md2qMJc?= =?iso-8859-1?Q?byA7Tu6uIJHz1S/pDRz0O7EYQXuspDATUNyWTQlonGatr2BiYsGxpl8Wtm?= =?iso-8859-1?Q?IXXFNBTG1XmieXwoTvEcWXJS0KycnYSG4tZzlCoet+uv5eqYhY29EpRxLT?= =?iso-8859-1?Q?In5mhVMMddOoCuUm2Wu6kCkXR4AVRpf4CTL3Oezx9xPSKwyi0oFnM6hyIb?= =?iso-8859-1?Q?bxniXjVAbMpYFQIuERxrW0e/8IwmGz+tcUy8C5BZ8bZrdsrHK+r/VK7jSO?= =?iso-8859-1?Q?FjXhFGqjmsJTcUngkqmfgVyz7VZmadUskwoyLcRqUNqJSZ2y8HfA8gEeeN?= =?iso-8859-1?Q?JYBs89y7ygitfyhNL5WZZDSOEVGGiAseNGUMOlYMo2sqqi5Y5vTMmFZr0Y?= =?iso-8859-1?Q?W1AuG/+HrXHAIILLlTa7sArozZMp73cpwp/tyGc7ZXgsrQDeIlJEa/S5k/?= =?iso-8859-1?Q?X9uSeDXqJQtDgPTqx1kvkLRuHQjTgzNxLWpe24O05buI0WI+XQUyUnPM2E?= =?iso-8859-1?Q?kUb0SYjZIri3chAeiTPt64ePq8zwB/bSL7xVwVDp1uaEn4yo+Eo2Ub5x1m?= =?iso-8859-1?Q?aFQqChENztCIJs+8DFtX3lZyDY56BxFFlAwqopAfyyJwFpNsjyECT3E3Wx?= =?iso-8859-1?Q?ChNaMOyq4Da93wrMvgwXBKdxIy2W78YLVYtXt6DNLtinAdFAuNSF4OrRT7?= =?iso-8859-1?Q?0h3cJpW33uPoul+S5ivKBZsF2zc+ZO2tUysnJTnIGwpQZu18duERzeMhaC?= =?iso-8859-1?Q?mjQyJCBscX3JxYWQ87xKFtN/I3+Hw6UTNaQGD2/PJ1GmPQ1rQ2GCgK2nom?= =?iso-8859-1?Q?+SuQITb4qLPMCUMkLmsDxVbTB+fl08pSXFTdhKix+VbslybZ99fsEnJZAp?= =?iso-8859-1?Q?9qyUOkZOCy5MFnyVkf2UH9fjaMqZxKLf44RbMWBdGkGwnbCDlycg0xF4pv?= =?iso-8859-1?Q?RckaVdjCGcccdOC+TXwLIeniQIFkAjdLA15HO5N3wsJxNo2c7oiMBYwTOF?= =?iso-8859-1?Q?hyW6WB9toTbNh173FgpOapxHDTwyM7d/t7oNrjIhoffy83obB2Sezk8IA4?= =?iso-8859-1?Q?GuaAjmQQJC0kNw2a7jV6Lll+0V57uKO/jPPwLg1fiHBgd0pLnovqmO1YMh?= =?iso-8859-1?Q?pzp7YZzCdyKCOrJU6YN047qFQLO+rMuc77fM2Ns4bArn4KtQR/Sx40oCAq?= =?iso-8859-1?Q?2uEWGF5eCWt0okufak00x6IZs6PUrqSTtnumPAfZh8QhdxDeZSj4gSq5ex?= =?iso-8859-1?Q?dp96aJqzsHjiIWM24e2Bbf2MBo34LZYxriGZOGi+lSoehRxjpF/azIXVBp?= =?iso-8859-1?B?Zz09?=
X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2993; 6:MV4DmLLn5CtW/o7Tgw/r6ZM417BxhSZa2YShYZWsPaFGLlaZFGXkVOL6DNCdOIlY3+oADWC5rGX9cVt13X+u/QBpYUgV9Q6Z2uo7WeQW3Wvgkzspm3FgLUUhlg4UlFJc0q9Dn7VOUDNeeUGehGlHA7rPoAE3YACELLgpcbYQtLb3j3l1C4d+xGvaB8LIcgjebJQrDoCAKG7X4jSpuEV7rxX/pUpJtGzJrSJObBGeco6x0qe7wSOXrk+LRZ5aCYdYgEizhRchfQQMdHxnd+FsKtHFpxdFBqBQuQbfeq/Z7nJtZ5xsifMAoe2gEI5ZA+E4; 5:Em6Dj6ELydTOrborkuLc1rTKeCtyhLXEznc5rHNfMuqaH2CuyxUxUsiIW5FdhJY5WhmHEa5boqQuE47+iDcPqaIvRls+wvLLdQOTQPaGvvWxoshOCsn0yV6FadcYbViwxtzvY7OQngrUlGg4qXwL9g==; 24:X4ATSGmA51KOoJZfvc5Hzb//vu3Pl0SrIO+TKxQbJUikz+0l171BXd3h3WlZK2uuNXl5hij898piTFmRVNEjrhudtA2mzJTMYQbUVMOgrp4=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2993; 7:DFIPnCX9myA8kswizF7+pFqKNMaM+Q6+Fp/7qTY0QwE1T+NAbJwO9kq2x6iN8kLGW/Ky+EZYeN9ugIFMlDWjLWinUm1cNgbjCiquWYOAhKMeNfO/6x0ug9poItuM5F169WA65d5WZbb7/UgLLQuuReuKvAgviQ1G2Gs5LO2W5RAxi0ZAJ3WHQRG/P1Ycpv+uQRq0sk9GsdXs7NPOUL7LhuMafjUFL9snrdZOlVjqgQLsflO1oPITHcodIuQZ8FhqKNTqwgRc6RDQ08lVravrBgT/0GTx9/DsAePPhmMkcMTCmdIcvaAE5VbkW7JPo3CIam4sPvwizifqjjCIALzfthDJQtCyO9QnkNK+XpL8oBo=
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Nov 2016 16:59:50.7025 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2993
Archived-At: 
Subject: Re: [Idr] The IDR WG has placed draft-snijders-idr-deprecate-30-31-129 in state "Call For Adoption By WG Issued"
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, 11 Nov 2016 16:59:57 -0000

I am unclear why this message has appeared now, when we had a discussion
about this 10 days ago.  The timing is unfortunate since, 10 days ago,
Job told us that he had a version -02 (I note that this announcement is
not version specific) which may well overcome the objection I raised to
the adoption of the first version.

So, I await the announcement of a new version with interest after which
I will post my views.

Tom Petch

----- Original Message -----
From: "IETF Secretariat" 
To: ;
; 
Sent: Thursday, November 10, 2016 10:36 PM
Subject: [Idr] The IDR WG has placed
>
> The IDR WG has placed draft-snijders-idr-deprecate-30-31-129 in state
> Call For Adoption By WG Issued (entered by Susan Hares)
>
> The document is available at
>
https://datatracker.ietf.org/doc/draft-snijders-idr-deprecate-30-31-129/
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr


From nobody Fri Nov 11 09:03:24 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2FF61295DE for ; Fri, 11 Nov 2016 09:03:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.946
X-Spam-Level: 
X-Spam-Status: No, score=-1.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_SOFTFAIL=0.665] 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 oSAqS6z594Jr for ; Fri, 11 Nov 2016 09:03:21 -0800 (PST)
Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (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 BDE6B129452 for ; Fri, 11 Nov 2016 09:03:21 -0800 (PST)
Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1c5FEW-0001eZ-F2 (job@us.ntt.net); Fri, 11 Nov 2016 17:03:21 +0000
Date: Fri, 11 Nov 2016 18:03:18 +0100
From: Job Snijders 
To: idr@ietf.org
Message-ID: <20161111170318.GP17920@Vurt.local>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <9B3BFE0A18160E40BAF1950414D10FAE61715E6C@WPMBX010.bskyb.com> 
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.7.1 (2016-10-04)
Archived-At: 
Subject: Re: [Idr] The IDR WG has placed draft-snijders-idr-deprecate-30-31-129 in state "Call For Adoption By WG Issued"
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, 11 Nov 2016 17:03:23 -0000

Hi Group, Chairs,

Didn't we kind of already do this call and subsequent shoutouts for (or
against) support? As far as I know the call ends on November 13th

Kind regards,

Job


From nobody Fri Nov 11 09:09:13 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 713581297CA; Fri, 11 Nov 2016 09:09:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.432
X-Spam-Level: 
X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_SOFTFAIL=0.665] 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 Wf2P8-Nvv0Vg; Fri, 11 Nov 2016 09:09:10 -0800 (PST)
Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (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 653D01293DC; Fri, 11 Nov 2016 09:09:10 -0800 (PST)
Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1c5FK8-0002Gk-DK (job@us.ntt.net); Fri, 11 Nov 2016 17:09:09 +0000
Date: Fri, 11 Nov 2016 18:09:05 +0100
From: Job Snijders 
To: "t.petch" 
Message-ID: <20161111170905.GQ17920@Vurt.local>
References: <147881737447.19568.6243042923882629926.idtracker@ietfa.amsl.com> <007f01d23c3c$992f8ba0$4001a8c0@gateway.2wire.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="aM3YZ0Iwxop3KEKx"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <007f01d23c3c$992f8ba0$4001a8c0@gateway.2wire.net>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.7.1 (2016-10-04)
Archived-At: 
Cc: idr-chairs@ietf.org, idr 
Subject: Re: [Idr] The IDR WG has placed draft-snijders-idr-deprecate-30-31-129 in state "Call For Adoption By WG Issued"
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, 11 Nov 2016 17:09:12 -0000

--aM3YZ0Iwxop3KEKx
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit

On Fri, Nov 11, 2016 at 04:56:40PM +0000, t.petch wrote:
> I am unclear why this message has appeared now, when we had a
> discussion about this 10 days ago.  The timing is unfortunate since,
> 10 days ago, Job told us that he had a version -02 (I note that this
> announcement is not version specific) which may well overcome the
> objection I raised to the adoption of the first version.
> 
> So, I await the announcement of a new version with interest after
> which I will post my views.

Since the call ends on November 13th, and the draft submission re-opens
after that (2016-11-14 00:00 KST), it will not be possible to post an
updated version during the call for adoption. Instead, I've attached the
-02 version which I will post. If that's not good enough ... ¯\_(ツ)_/¯ 

Kind regards,

Job

--aM3YZ0Iwxop3KEKx
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="draft-snijders-idr-deprecate-30-31-129-02.txt"





IDR                                                          J. Snijders
Internet-Draft                                                       NTT
Intended status: Standards Track                        November 2, 2016
Expires: May 6, 2017


Deprecation of BGP Path Attribute values 30, 31, 129, 241, 242, and 234
               draft-snijders-idr-deprecate-30-31-129-02

Abstract

   This document requests IANA to mark BGP path attribute values 30, 31,
   129, 241, 242, and 243 as "deprecated".

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on May 6, 2017.

Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.






Snijders                   Expires May 6, 2017                  [Page 1]

Internet-Draft Deprecation Of Squatted BGP Path Attributes November 2016


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   2
   3.  Security Considerations . . . . . . . . . . . . . . . . . . .   2
   4.  Informative References  . . . . . . . . . . . . . . . . . . .   2
   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .   3
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   3

1.  Introduction

   It has been discovered that certain BGP Path Attribute values have
   been used in BGP implementations which have been deployed in the wild
   while not being assigned by the IANA for such usage.  This has led to
   deployment problems for new technologies such as Large BGP
   Communities [I-D.ietf-idr-large-community].

   The squatting of values 30, 31, 129, 241, 242 and 243 has been
   confirmed by the involved vendors or through source code review.

2.  IANA Considerations

   Per this document, IANA is requested to mark values 30, 31, 129, 241,
   242, and 243 as "deprecated" in the "BGP Path Attributes" registry
   under the "Border Gateway Protocol (BGP) Parameters" group.  The
   marking "deprecated" meaning "use is not recommended"
   ([I-D.leiba-cotton-iana-5226bis]).

3.  Security Considerations

   There are no meaningful security consequences arising from this
   registry update.

4.  Informative References

   [I-D.ietf-idr-large-community]
              Heitz, J., Snijders, J., Patel, K., Bagdonas, I., Simpson,
              A., and N. Hilliard, "Large BGP Communities", draft-ietf-
              idr-large-community-05 (work in progress), October 2016.

   [I-D.leiba-cotton-iana-5226bis]
              Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", draft-
              leiba-cotton-iana-5226bis-18 (work in progress), September
              2016.






Snijders                   Expires May 6, 2017                  [Page 2]

Internet-Draft Deprecation Of Squatted BGP Path Attributes November 2016


Appendix A.  Acknowledgements

   The author would like to gratefully acknowledge Marlien Vijfhuizen
   who helped discover the squatting of value 30.

Author's Address

   Job Snijders
   NTT Communications
   Theodorus Majofskistraat 100
   Amsterdam  1065 SZ
   NL

   Email: job@ntt.net





































Snijders                   Expires May 6, 2017                  [Page 3]

--aM3YZ0Iwxop3KEKx--


From nobody Fri Nov 11 09:12:56 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69FEB12987F for ; Fri, 11 Nov 2016 09:12:55 -0800 (PST)
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 ok6ZbAFnN4S2 for ; Fri, 11 Nov 2016 09:12: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 5C2C6129878 for ; Fri, 11 Nov 2016 09:12:54 -0800 (PST)
X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=31.133.148.72; 
From: "Susan Hares" 
To: "'Job Snijders'" , 
References: <9B3BFE0A18160E40BAF1950414D10FAE61715E6C@WPMBX010.bskyb.com>  <20161111170318.GP17920@Vurt.local>
In-Reply-To: <20161111170318.GP17920@Vurt.local>
Date: Fri, 11 Nov 2016 12:10:23 -0500
Message-ID: <00df01d23c3e$7ea7c9d0$7bf75d70$@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: AQG2EddqsoxNcyN6C0hSlOG/K9JbOKEMWGyw
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com 
Archived-At: 
Subject: Re: [Idr] The IDR WG has placed draft-snijders-idr-deprecate-30-31-129 in state "Call For Adoption By WG Issued"
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, 11 Nov 2016 17:12:55 -0000

Job: 

Yes!   It ends on November 13th.   This is just an web-site flag.   Some
people look for the flags to respond to WG adoption - so I set the flag
tonight so those people would respond to the adoption call.   AFAIK tell -
there is overwhelming support for adoption. 

Sue 

-----Original Message-----
From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Job Snijders
Sent: Friday, November 11, 2016 12:03 PM
To: idr@ietf.org
Subject: Re: [Idr] The IDR WG has placed
draft-snijders-idr-deprecate-30-31-129 in state "Call For Adoption By WG
Issued"

Hi Group, Chairs,

Didn't we kind of already do this call and subsequent shoutouts for (or
against) support? As far as I know the call ends on November 13th

Kind regards,

Job

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


From nobody Fri Nov 11 09:16:57 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27203129955; Fri, 11 Nov 2016 09:16:56 -0800 (PST)
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 gmA23WYY-pBA; Fri, 11 Nov 2016 09:16:55 -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 47D351298B5; Fri, 11 Nov 2016 09:16:53 -0800 (PST)
X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=31.133.148.72; 
From: "Susan Hares" 
To: "'Job Snijders'" , "'t.petch'" 
References: <147881737447.19568.6243042923882629926.idtracker@ietfa.amsl.com> <007f01d23c3c$992f8ba0$4001a8c0@gateway.2wire.net> <20161111170905.GQ17920@Vurt.local>
In-Reply-To: <20161111170905.GQ17920@Vurt.local>
Date: Fri, 11 Nov 2016 12:14:19 -0500
Message-ID: <00e101d23c3f$0b0f1630$212d4290$@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: AQFb8j8fA8EzIZ98gYvRB91vsWTIZgKRIVvsAll+uryhmUOT0A==
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com 
Archived-At: 
Cc: idr-chairs@ietf.org, 'idr' 
Subject: Re: [Idr] The IDR WG has placed draft-snijders-idr-deprecate-30-31-129 in state "Call For Adoption By WG Issued"
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, 11 Nov 2016 17:16:56 -0000

Tom:=20

The WG calls ends on November 13th, and Job can post a new draft on =
11/14/2016.  We'll look forward to seeing your comments on 11/14/2016 =
(if at all possible).   After the 11/15/2016 IDR WG session, we may move =
quickly to WG LC - so please actively engage in the debate.=20

Sue=20

-----Original Message-----
From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Job Snijders
Sent: Friday, November 11, 2016 12:09 PM
To: t.petch
Cc: idr-chairs@ietf.org; idr
Subject: Re: [Idr] The IDR WG has placed =
draft-snijders-idr-deprecate-30-31-129 in state "Call For Adoption By WG =
Issued"

On Fri, Nov 11, 2016 at 04:56:40PM +0000, t.petch wrote:
> I am unclear why this message has appeared now, when we had a=20
> discussion about this 10 days ago.  The timing is unfortunate since,
> 10 days ago, Job told us that he had a version -02 (I note that this=20
> announcement is not version specific) which may well overcome the=20
> objection I raised to the adoption of the first version.
>=20
> So, I await the announcement of a new version with interest after=20
> which I will post my views.

Since the call ends on November 13th, and the draft submission re-opens =
after that (2016-11-14 00:00 KST), it will not be possible to post an =
updated version during the call for adoption. Instead, I've attached the
-02 version which I will post. If that's not good enough ... =
=C2=AF\_(=E3=83=84)_/=C2=AF=20

Kind regards,

Job


From nobody Sun Nov 13 07:01:38 2016
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 EC94D129663; Sun, 13 Nov 2016 07:01:33 -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.37.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <147904929396.5505.15815142944266750219.idtracker@ietfa.amsl.com>
Date: Sun, 13 Nov 2016 07:01:33 -0800
Archived-At: 
Cc: idr@ietf.org
Subject: [Idr] I-D Action: draft-ietf-idr-large-community-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: Sun, 13 Nov 2016 15:01:34 -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 Large Communities
        Authors         : Jakob Heitz
                          Job Snijders
                          Keyur Patel
                          Ignas Bagdonas
                          Nick Hilliard
	Filename        : draft-ietf-idr-large-community-07.txt
	Pages           : 9
	Date            : 2016-11-13

Abstract:
   This document describes the BGP Large Communities attribute, an
   extension to BGP-4.  This attribute provides a mechanism to signal
   opaque information within separate namespaces to aid in routing
   management.  The attribute is suitable for use with four-octet
   Autonomous System Numbers.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-idr-large-community/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-idr-large-community-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-large-community-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 Sun Nov 13 07:01:48 2016
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 D86AF1296A7; Sun, 13 Nov 2016 07:01:40 -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.37.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <147904930088.5582.11045248912873783464.idtracker@ietfa.amsl.com>
Date: Sun, 13 Nov 2016 07:01:40 -0800
Archived-At: 
Cc: idr@ietf.org
Subject: [Idr] I-D Action: draft-snijders-idr-deprecate-30-31-129-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: Sun, 13 Nov 2016 15:01:41 -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           : Deprecation of BGP Path Attribute values 30, 31, 129, 241, 242, and 234 
        Author          : Job Snijders
	Filename        : draft-snijders-idr-deprecate-30-31-129-02.txt
	Pages           : 3
	Date            : 2016-11-13

Abstract:
   This document requests IANA to mark BGP path attribute values 30, 31,
   129, 241, 242, and 243 as "deprecated".


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-snijders-idr-deprecate-30-31-129/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-snijders-idr-deprecate-30-31-129-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-snijders-idr-deprecate-30-31-129-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 Sun Nov 13 19:01:32 2016
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 A9E9A129441; Sun, 13 Nov 2016 19:01:25 -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.37.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <147909248568.5603.13125553403060798059.idtracker@ietfa.amsl.com>
Date: Sun, 13 Nov 2016 19:01:25 -0800
Archived-At: 
Cc: idr@ietf.org
Subject: [Idr] I-D Action: draft-ietf-idr-bgpls-segment-routing-epe-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: Mon, 14 Nov 2016 03:01:26 -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
                          Saikat Ray
                          Keyur Patel
                          Jie Dong
                          Mach (Guoyi) Chen
	Filename        : draft-ietf-idr-bgpls-segment-routing-epe-06.txt
	Pages           : 19
	Date            : 2016-11-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-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgpls-segment-routing-epe-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 Sun Nov 13 22:20:43 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A727F129459 for ; Sun, 13 Nov 2016 22:20:41 -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, 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] 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 M6megUEohcnR for ; Sun, 13 Nov 2016 22:20:39 -0800 (PST)
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0139.outbound.protection.outlook.com [104.47.41.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE76B127077 for ; Sun, 13 Nov 2016 22:20:39 -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=JTOVhUjaY2F38zGmlArT6uosmGtVbRv3zQzfELZLDv4=; b=M66vtDeQAnHxaPPSdWwqfW7RreBMLPg2Rbsg7/0eqzdHSMWhLREmTvlwKYcVlWhSEQ9kn9yGAs1eCYT2ivKCyTEqGmNW9DQSfu7Ia1MB1fKTrOBjBY7r5xqLZ283r/QPm2rQUdHBsktdGd2jAjf7UwQAzUVEa+3t5V7FS21Lhus=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; 
Received: from [172.29.192.68] (116.197.188.11) by CY1PR05MB2506.namprd05.prod.outlook.com (10.167.10.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.734.2; Mon, 14 Nov 2016 06:20:37 +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: <39EE14CE-8B69-4DD6-883F-0700C25A605B@juniper.net>
Date: Mon, 14 Nov 2016 15:20:37 +0900
Content-Transfer-Encoding: quoted-printable
Message-ID: 
References: <39EE14CE-8B69-4DD6-883F-0700C25A605B@juniper.net>
To: idr wg 
X-Mailer: Apple Mail (2.3124)
X-Originating-IP: [116.197.188.11]
X-ClientProxiedBy: HK2PR04CA0001.apcprd04.prod.outlook.com (10.162.205.139) To CY1PR05MB2506.namprd05.prod.outlook.com (10.167.10.27)
X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2506; 2:uud8my9tOP+8KMN5Kg5x+Yg0yWrTa8HdZaCQ1GIn65PbmYVItPKLR+hSb+inGColcoLNWt41Dd1esGGdGii6g2nKtuu7WcVC+zmu5AI/80YP3STYGZIfy2yXlz0Ycv/QTcQlaEsQlMN89Mwn6i7LWhZ5qpJw2o01rfKkVAREHOs=; 3:eQ89Xx/TwaNCBKLqhuNYnuYSKNLohbHDU1AJnhKJHx6cXZ22JZGWD76XBeRSbvCbN8vmCCZmeKueduHW9NxHNrewRkASLeFMKoBoeHCnQr6d4/+eFuYQphu/DEqRpT7cj60PC/x2SWC2iuzxpKUvw3ymhdJFs17wELb3KLQCxkA=; 25:SCXl774i3IIiKdnXfdTOI4SLwvlhKYfub5+TW8gyW5iPxpx0LDkCVmZUmLAs/iSB1lQsvhFTX5mGTQkXGuPhAt9VjBruS1pKPuMPWhhG+Qo8yWMqZK97bkvSsECaP3nxufMUP3Pck8aJHzVeRxySCV1q2NTUiYIhMD1RwnQj08RCwLnnDte7dTuDq0xY07o13ERJzKa9C2qq7zFHCO9BPNHpb4yQDyJqEuss+WC2an9xdGdGP0wV2UJY5CAFBOro27kSuj2lDT1WlLrA5CP57el78bso9tkQW6L2hYVTRFAyNNTcbS/NwaPHguC8st8FO7Oc9u4r1ak7Oh7qPNPP4mJO2meh/3hC8SzRQ+Kn3KcIUWWQ6UFSo42UBN5K9zpDR3YZFloK9c64ROHYws8z3xseSrGuJ48ofADaWelD+oQBdSXSRioHhDFzt8lau4b/
X-MS-Office365-Filtering-Correlation-Id: 84ddb1f2-7e6a-4b4d-7497-08d40c565a43
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR05MB2506;
X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2506; 31:m3YJa/c+D0cKvZKzVF7M1/GxAQhsyadHU+YIvS1kv5o5MtE3wdjCY+jm4/v/2FkOg4684y5jhmpxbeSOHDndGZv40Z6d77oJHjq9dVgWBda6jLpYPCixVn8qxHaboIICQylseG5YvUwIVDvXjPP57u+5pnnR382iCx6pkkNh36MlQ1JPu52kh3EdwOd5s6DaReT4VykfTdVHXhxBjMSm8gOCRQ9iilGpA60i+BOiBIaQoAY2Mi5VMtXTECtDn4Y9yAW0TuMO46qBVcNsAt2QIA==; 20:gqXSZ72Y7SDngBnhdDlCLam7mxrsOX7jRG0XDdrLinUZ6ZCaT7KulVsqRh7R71agC/GUOWKheu7YNZWenYiHOiEplg4Y0W3GUH71vsKWLXsCaPitigaScBPdFDkib42hyHWYEE4rLs39h4kdrZ3p2sCXMBexRnd0Bxtf5T47ni3w/1+oJ/WIda/AjHrnNeOk+HbWNukFSt/eIJ6mg7YnHCWrUzv13aDLR03IAEhz0o65C9bee6Vhz1ir/OnyEOJeqemqwVO0FiKTeyXokfRVk1UsXMm1lbMNsYpfG2s5cAw3Fjfe6HjRZzhwtvxDhksWOUFXPzb3TLcQul5qGUIvwG7ZrHisjrixgId0iG0riT8S6OUG4Yh0OLyxbaMeR3K4OvfZPia/RlvzMQh/+TxqiQ5k3i2qgGSIOFscJdV37PC0n+xFdwl7fly7PKWF6jarS45feKE0eJesSDzBwf9gMfucmnTLKZPLZl/pHu2o5kv3l/0dV8tJvsoMuVXVW0Rj
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(138986009662008);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:CY1PR05MB2506; BCL:0; PCL:0; RULEID:; SRVR:CY1PR05MB2506; 
X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2506; 4:ZTvoJ3vdVr0l9MCGTGrtQeAozE8bHzvPOOHWlzZusO85Wpu6Leh47Y96bGc3kcEQ/XJ+CS6JOg4EZSsR18LblJFbm0HfHTsJfHp9Ixjjm/B3jrm3HqPkjkssaPzgm5EBsqd44ZBQ/DoemuACjxj6AhjPuUS5fu19L3NR7K+jaH9qqHchaiBkLIl9CLTGxcwR0JcPh+YfYiVhp1rtrdyjXlJ7x4lkvZmO2VzD6j8+4yptyS/01UcXeDRcyY65ehHxTDwAVSzXbVyICZSfl+i7Yu8T9YoRFIcZvrmxi4vS15+jjHOStxgQxHT3mNyw8jWnpLl/WkKFSYuA3/zZJMJeuOUSQrsPnRbE4Q4FiGs+9zEaNeC4i29z2OpfTfqqN1BYa80aXFkKH7LaveMwJgPfL3VWH7+YuFrE5RcixPPvgkE0sjPL4WdRuhAVIJEo0HR14VYx5NKPZAlaUeSrUPp+bA==
X-Forefront-PRVS: 0126A32F74
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(7916002)(53754006)(24454002)(51874003)(199003)(377454003)(189002)(47776003)(23726003)(50226002)(6116002)(46406003)(3846002)(105586002)(42186005)(106356001)(101416001)(76176999)(50986999)(8746002)(33656002)(586003)(50466002)(81156014)(81166006)(36756003)(57306001)(66066001)(7846002)(7736002)(305945005)(8676002)(6916009)(2950100002)(230783001)(5660300001)(110136003)(229853002)(92566002)(450100001)(77096005)(2906002)(68736007)(189998001)(86362001)(107886002)(83716003)(82746002)(97756001)(97736004)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2506; H:[172.29.192.68]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR05MB2506; 23:kUjk78KP5Pn1NTFM7wueZYtvkK4gLGDf1kAxTpqWM?= =?us-ascii?Q?vkPMmD/lCg/Ibh6X4TMhufgv/FAOjXXJoxqBgLZgVYWab6HzRTP29IE0C/u0?= =?us-ascii?Q?MK449FBBa7cWmCGC1heZHg0KqGbDadi8uhkmO+I1qlDCbbBoxkJZJ4Hv8hvb?= =?us-ascii?Q?d9Xp93FKT+5jOj7Gf46NNqb046hiV6PJ2l074A045h9KVRSi6R82OH4xqOuB?= =?us-ascii?Q?RoxMMWfZuosDRaahSX1GTwOoKSVXGGC+18VSVG0oq4cXO3LxrzvZlzf6711/?= =?us-ascii?Q?5qa7+UBNjqOUdvv5oTu13h4MfMMW/1y8Bml952llmdFVR750BU1IgOv+bLBr?= =?us-ascii?Q?ZZxyN8Qpp8L9wBmWkVE8HuMtyLwsZCCqoVvfyuR7ibM5yLhrkR+T8gHYOH/W?= =?us-ascii?Q?hCFhWSHmd3WcfWXP9KIQepru5Yv86zmx3Oxl7wd/O5G5ojMmybMXVZ/AW6Zg?= =?us-ascii?Q?2tnOJHOy85GJnRZDV9asDmflDIXTP2YWHtCOlRkAUvoQBHUjlUJS7hVvpZu6?= =?us-ascii?Q?YyC7tLycyCMFCrWKWiLmQcU/+iARdBgdgrEm43ML8h9gpIPRgC+s48X5s5ax?= =?us-ascii?Q?ocHfT3KkGqyENYbda9ldgP5l9zPchKj9vrPZ47Sn+rNT1NlOq2iE92l7fltC?= =?us-ascii?Q?SVVjXfwvjaARPZPEoo1HYlS7bxiFcI2R9xSfgcl9dn4WdHxdJTI5ZFb4W6ET?= =?us-ascii?Q?fP3QF/LAdjpqvwHjhabSfFztw8xRAkLxIXfN0M9lpg+8g9MaH3aznIn3FdkS?= =?us-ascii?Q?cS97KLjI0tyDAomdsVXFObERudcpC2amoqccl+ExP0BQky0udjRdYw6XPaiX?= =?us-ascii?Q?CjqPsvpNADQ0sf5pu2/B7hnoYZ9h1ugOF9kC8C8KZhLpLP8KLGRQEoUbwc6t?= =?us-ascii?Q?aIFrz/k45MWJR0HO6Bbzbcn8owNc7ibPETfqrl0llBboeexlX+lOpFvQvtD4?= =?us-ascii?Q?jR+H3IxBXI8OCYrJ4Q25JNYIs8hq2AcflyQ4PkRU4rhKtffL1m+UiWGH85dD?= =?us-ascii?Q?FqZA8M/xvB5DRb/2F7+Civ1/y6xmXGB8JpIF5JeUOPY1SV6eCtpqi/0inKzs?= =?us-ascii?Q?x5P39+URdtcPtFTPUoXhqD/E0nPvxgL1c5QJTLi5TKOR2eEvGmUtXyC1pw6P?= =?us-ascii?Q?rp2RmsmplFbtF5b3tZCReNZIa8kJsyCJSGWZ1XOT3cc4lXhbyG5A+qB6g/os?= =?us-ascii?Q?tEYRdmGIQrZmZSKLr/uC9r7OfbAQd1eBGmWrCuLdV7tnYOUOSsiAzB05KjhK?= =?us-ascii?Q?rnG80Nfkhs5a5hj/nTI0ZM4M8jobDxfWNrQFfNVbwYGyK+Owbp5flSYjpF//?= =?us-ascii?B?QT09?=
X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2506; 6:fQAEkG/0c9iS6Z8s1k3TC5MV9Ld9ijMtl9gGZCV598MlugaZKKG+3Z+B4dk1TjFdhi2b0uFS92j1K0vrI2dpaUQnCyBzySwDIyhzXmBh84MeE7YbdPcLgjzykTnLrvGyN4xTP6W1Xz8xd7tm0SdJgXaEqIbN1fX0tDQAp4asbh1Hj7n2ZmGt6iSbQClTAa8h8/BSEvdE9ZYMNbTJ54GiMyBOeod6ofyhj8Oz1HUtxDFNn0lVgHNZrYlffkD6TRyBmbBy4V2h3LUixLpfNZksB0sWkBne8PCC5Q8KmW4i5fjFdH5dVMYE4GnTIxW7ax3m45EpBV688gDYkSysOpCm7g==; 5:jT8PxdKJWrre2+VUsWrM2QVN51I0fVzfL6yVi+S2QyjeNKRni1gA54WSTX0paoE55ianlgoP4B8Dfrfw0DtJElkMpL9TirRqDqwntLHCwTlyOIwQAEBHjst6nCB3Lu5OUDEzd9bWqn8ca31izJV54g==; 24:0AslxvgFREkprZTMxSUK/YZKL5bl9OYsmgSFGEMMIchrzbt8bxhiNWypYnCi00PgHBPEga5NJgjc4QlAdIoUAR2SVw4l3v/EH1GY2xS1IjQ=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2506; 7:E0Uox9CtBtm8DU6nDZtWiJHYmSsBoE/31KiKjOKNqRDDaOIq5k1A3//6TSq5scFW+n9j/zOYTu6L+d6PvYVu3Gy5nWjQX8oMLzP+clJijOt1DuT9SckhPG+xicKZt9cKqyzU3JTkavjhWN23wG4kMapMgFGRfut41A1goB5aTaStblj9sUwgmazutgt8WmbUED/Kgd7gVYtNRA3FLdEETIdBek2csYJVF4/H+QagWVNi4/5mWzOegCuXPsbkraXpYNiMl99wBnpGEznrlnekLDHaiVB3uZVkQKpmafl4hV7+Xf9wclvSzzendh3jEyXm5NYEnWn2gTpIcmkgtImd15J6A3t+wxgwJc79jPrGoX8=
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Nov 2016 06:20:37.9447 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2506
Archived-At: 
Subject: Re: [Idr] Implementations for draft-ietf-idr-rtc-no-rt-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: Mon, 14 Nov 2016 06:20:42 -0000

Still nothing reported...

--John

> On Mar 26, 2016, at 12:20 AM, John G. Scudder  wrote:
>=20
> Hi All,
>=20
> As part of advancing draft-ietf-idr-rtc-no-rt I would like to ask for =
anyone with an implementation to tell us about it. The easiest way to do =
this is to add to the implementation wiki: =
http://trac.tools.ietf.org/wg/idr/trac/wiki/draft-ietf-idr-rtc-no-rt%20imp=
lementations (and tell us you've done so). However, if you prefer some =
other method, that's OK too -- feel free to email your report to me and =
I can paste it into the Wiki, for example.
>=20
> Thanks in advance,
>=20
> --John
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr


From nobody Mon Nov 14 00:05:48 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2585E1297AA for ; Mon, 14 Nov 2016 00:05:47 -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 HZV0RXE6sCGM for ; Mon, 14 Nov 2016 00:05:45 -0800 (PST)
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0100.outbound.protection.outlook.com [104.47.38.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8F641297A7 for ; Mon, 14 Nov 2016 00:05:44 -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=JDOwqAA6YhmPIHGB9zMkTPYavfTqxUcnzsDW9JLANDs=; b=JOY2o8xkM3mFpQIjVf7ngx5+YD+gPZSrMYRd2TqGFARaykJvfZinue9q5LTCaIKuJQu3uImTDlX1YEePvVBKVzUH9BsHqZ8u97Mhc++mV7cao0N2bDBQvXQmp7QKMKOBXdV/Vwl8eWGXcihV/XCWFEa6QaclVgvtXlnuNDYD64E=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; 
Received: from [172.29.192.68] (116.197.188.11) by CY1PR05MB2505.namprd05.prod.outlook.com (10.167.10.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.734.2; Mon, 14 Nov 2016 08:05:40 +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: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net>
Date: Mon, 14 Nov 2016 17:05:25 +0900
Content-Transfer-Encoding: quoted-printable
Message-ID: <993452C3-1C1D-49BC-B886-643F1CDF0B08@juniper.net>
References: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net>
To: IETF IDR Working Group 
X-Mailer: Apple Mail (2.3124)
X-Originating-IP: [116.197.188.11]
X-ClientProxiedBy: HK2PR04CA0016.apcprd04.prod.outlook.com (10.162.205.154) To CY1PR05MB2505.namprd05.prod.outlook.com (10.167.10.26)
X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2505; 2:8yMFpuJO/XVrME4y7iDTXX7mJSyrOn8JI71bKV33qgkZMML0YEefLQihQ6wJp6PRc+Y98p2uvdR0UFIlC8fkrpR43IBKb35yP41I69W7RsS1Om7kfd5TMYZts19V5btE+AlBdPsaNZ1VWYUI3cbewULt/SsCLUPI24/zuYZu+l8=; 3:W4KLUVjsVUW9RvE4jIAuZQvCYH1JPtWsl2Otxh5R4049pri+TD0I4M9mUvv1fb5eC8fVkhNdgugUJnTSseZ0ohbYGYx+qoEyL720LGlQXhJnK7fo2HZ9bX/FyA2uf2sBqj3poQE7GyXA1pDnJy1YEqW8MkDiNvrZ6+qn+QrIDmw=
X-MS-Office365-Filtering-Correlation-Id: 8458b696-3881-44d0-4ccd-08d40c650734
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR05MB2505;
X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2505; 25:1HK9+0kKwtHawpFTRYiZxw7zpLb3s8gKUEwJSpqNXVG0IsFwfb/G/ycgiMc35iGJbrxwMCInpLTKFku0SeKv4ue38I4FLjhg7O+0JfRp3pf0W9YX2CSVdIEK2fgcd2WVkCCqwm9FmJ0cZBPJVWRPbzPdBTOKsUM9yAAKlZFySUeYmsyFD0RtFMb5ZvaV2L30k2f/O98CqxE+sy7TqY7hvOUwwz8v8bDYQ8AQbALFJzt8noIisC8SZOZIc9K1lDbga1Pa2tqVvzCL2I7O1FlwaQ5sPp079XGRpMTIp4NJmQVWWslRcn4JoEsyVW39Dj5UOm5z99EJsMPxzYAXN6PH8R/hPC+jAB55nNSEpaz3dwhZrCeiuP0nYpc79zIPV8q4QjliekJ7oWq1iWZzsDuQ7FPIeaBGF7/xICahs4KgMSZoTI4kqmLQgrxkwQZ1mVAhg1n7+T+oIoPCBjxH3MM2DNDPp1Y0Hv5y8JhuYZCkch4Bn5pyl+7co5kMzUc8EekZhFOKtGqu1pNygsNn33jbjdcRZCACpm0mXMIig1pFx3xMk7HADUe5twHs4Wp/LW+4xK8mu0k93DdDNTsvh0vLStQh471aNxg0Y9zbKOe0wZ/IlKjKIrMVwisYVgAb1He4pNhUTPdzYYJhGrQ7U/0CQv6UODtUz6sKs6Gf4CNbue3Jnq0kOswg3Ldm9mVg16rsJHLlXr0GhU4pujKbuCcXHv/jFuv1dn+psI/HMQyvEZ5Sq9lNhMa7dKmYw7trBV4KAk0k4LUIFsyHdiZXK7MOFu52tgpMLYl7Y+siZgBWlxLqHTHLNoLjd2yHmZmNXqQ8Smlc3gSdbthNODksxm5qyA==
X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2505; 31:YwOlIrn9rcn47TlNqHagBoeqtGHmgDrrjFYsak+5UaI9MWTUMAiGGU0HYBj2v9Ufg18yV8gbNL2hgdOVFSrm1t33GNa3Nx0UESYuE4pvF0HPfP7fI3ROwMNnV1rg2gCF4U5pDnWp49PbT0nmnLLL9WDJ5Wkj7l4MX93Lq+muSngchwiIXhkR89g9SIFJNB1NV0k2h8ZhDARPWQxuyG5/VzgbETbq1TlCoZ4hE5zVn9umOTiPUiOk3v+qkRue9PUyyQ/Z6s3hJ4QtJWY+xbI12TN0DspjSYms0FRum7EXdNo=; 20:VK0l/dfvgX/+16E7XzmPuiEJ64XkoPHxkfSTBlMu2q9mhWv6GQ+m4CmdWtSVqETd9TG0Vpwx8uh605d/sF4A/qeD81KWT8Dzv1BdQw6UXFd6DjPxT75WPaMgjoio1EKA+YAWVZ6/q14y4nhJ5EHCsI7/WX1yo7E+SQoOIpWr11XjNTeyu4jfCcXGT2WidK013tqqUKq+N+pPfOFEBmoKpvryZVpHkxLOJtVtlJE4M7M0hAaA6Hhyd6rMjCxhdGdbsutCzGhYWPt0ta/f/GaT5O7OiwSmcKxmyTD9QM1aHSuVFBGkQqGcRXA+byEzNSbNy3Pg4wYWbbPXCCciBo1koIY2ScrUorKDr6ne7SNgrCOeNgWH2fK+nVH9251OhTYdFKW4V5WtO6+/YQxT4beQcIZSxRBAF6JQ9Byt50RMc0ms861uM6etzZgLja6N9XtjPd+Y8a6nbIs7ASZsRGUGJsfg7RcYrKFWFwWWpaLZ3jCEvhlIujDESnfEfvSi42kq
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(138986009662008)(100405760836317);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6060325)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6061320); SRVR:CY1PR05MB2505; BCL:0; PCL:0; RULEID:; SRVR:CY1PR05MB2505; 
X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2505; 4:uKf/dbvdcLfH2yStwlk66/0awElduXuVsRGBfFgjsqXDgu44US/w7xdNpBmbS9Cfuc9lLDh5rN+MAEKqeWI8iMh20Xjq4y+E8N+otHLkKRPbK0pBnRTz0FAxYb8vxrRBvsEZSQmZObunV5rXMK3o/ncUCZds+8VllYE6n+b9kx8+hH625NZgcL/9BwI3GPH16NmMhFeiNBYpD1SGpV2Kyk9clKMx3z23qKZG62F8GrUihcLvR+RgLj5UWTfbAI8gjfoaiAIFthXAuM5jbGkyCXJ1QRuRxFt3IGa2qYIf/pVGMHAf5xT/sWmfpjU93eLTphz3VwW8+xmkPRIKnPYADVh0VbKWdH+B1ndh8CpD/EJx7CzHheDfbslcQlQJ8WrpKU/EGzYqx6nWCUiz1E+DR+PLrtBpIWSMDlVh84o9dm0Y0d8IyqUilfOzjJk7tmijq+RMNro55339BEw2OBPZjp3mBTwh0hX6s9s6BrNJJxKzarZ5r4JCGEkg4SWOecmSK2NpmS6/MBVMqlfspsrJJw==
X-Forefront-PRVS: 0126A32F74
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(7916002)(189002)(53754006)(377454003)(199003)(24454002)(76104003)(5423002)(36756003)(6916009)(46406003)(2906002)(50226002)(97756001)(57306001)(586003)(97736004)(101416001)(23726003)(42186005)(66066001)(33656002)(92566002)(110136003)(47776003)(50986999)(76176999)(229853002)(5660300001)(6116002)(4326007)(3846002)(105586002)(106356001)(230783001)(189998001)(77096005)(6666003)(82746002)(83716003)(86362001)(8746002)(68736007)(7736002)(305945005)(7846002)(81156014)(2950100002)(50466002)(81166006)(42262002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2505; H:[172.29.192.68]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR05MB2505; 23:NY0TrX6dQvOR78fB2slrn9o9kPtXVws6NPmqsKaj+?= =?us-ascii?Q?yTKjprdqCC7+H9xXx4tfNPlLEp6E+35+rVTVf6ZTZkzggTrqZr9irQZpBN8G?= =?us-ascii?Q?Vj0zgQuVGK88VYfzbctdpSC2kCNiBs85FtScloqLOv0nJN8pKjVczJkljxou?= =?us-ascii?Q?M0wEt+g/3qHdXpnTXWN9p0cmt4mVIRTodX/qz+DeeMl1J2FoXSCguyjVsZ/A?= =?us-ascii?Q?Mi47nWjpZ341e03uZq6fBb+vELnFQAU+Mu6MmPM2ZjuAwIvaJc1EU2l0gHMs?= =?us-ascii?Q?AsOJn5+gWBrq0idhFubASTqMYfTY4j5gnSj4Hc+3yNa+9IyE6yr4S7mN6o3/?= =?us-ascii?Q?tflvjspU4omraXFDakk4C6Xg4HGRTa35JurGWPGhn6SFnNSlSm1Rkj989cRm?= =?us-ascii?Q?ff3o3hoM7erHCBJAZXDmLFqkGcWc+tpVYFU1ThEnnppACqD8R2D37TlA/DvQ?= =?us-ascii?Q?6CSiEZ05UL/PfBYhWOb57JQkumRWrfVJPomXTiLleHbk3NxbBVZFTI8PnicW?= =?us-ascii?Q?BovPZuc8bwRfmhlPWrtKqj/goYtSnluwBaJ6O+UXdXmCnMCvisc85apBJnvy?= =?us-ascii?Q?oLs3mIDN3oFF+V265RwNZkFJgp1hxtmVKu+azAtVGUcuvt36pAOgkc2DvP/9?= =?us-ascii?Q?ihiiptgATuHcAPuVfoCKCQgmx5GE6pgovtwhiTLKEBRNhOeAiwdXd+1t+Vax?= =?us-ascii?Q?3mhw+Q6+/3fDQNDYWQwHD8YUw8N8luz7vZCZESgXTRT0yUTp2S4zymYHbFqd?= =?us-ascii?Q?BHIfhwck2bM2zanYUTL/ZtbcgNPmWqeMssCr4/RzVo7aKxYzDVTHYzoFm4PV?= =?us-ascii?Q?Ck7cjNxGDaHieqsia1NVQI5KMN8WoYKID581Wb348pkYf8BhZ8bBXhVwjY99?= =?us-ascii?Q?geGWKhCpM9NWnD6wI82xaMGwHIyYttc+DW0N5OBs3oigiKOdQZvSDCVB50Pq?= =?us-ascii?Q?ZVNP7QD6USV9M2rHieYQ7YjJDLEhWbu1B/h68oz+TY+gMaRBtxW1aAnv1J/t?= =?us-ascii?Q?1xNsfIebC+UDXDG12IoE217T+l+jvVYTyCaBNiaRb6n1eUUz1Muj4V7fQ5Kr?= =?us-ascii?Q?TA41hJocKOOqbgUtXztKUqmTU5FeP5z9U8rLvVdf7jJSEW6nYzReNnRgt5QY?= =?us-ascii?Q?9t2C7d2RyYaSasTOjr8MSj1bg+w3vuM/mniLPMYHZ0UkYkTc6/9NdnIF9X2g?= =?us-ascii?Q?lKDg57YcGamao53kJz0P6xmw5OAW/RLw9uiTpw+ZZYiQMIZ8ovGrl0dvCRhy?= =?us-ascii?Q?D84Lv5ThiVLWvzo4MhaOCLHQaQlvO0f83V+CVpMgyLjpUj9TUh4/XMMUnAAe?= =?us-ascii?B?dz09?=
X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2505; 6:ErXns5jTJzMnRqHwVltBljY6+03gZs7qsn3GxOLGCbiKdO5Z6hHWJ/iSoYX6E4Taom7zcphVtT7KwF8hJfcrCYZPZ1Y/D14nxHrn+kL9Nr64tHGCNS961+kRRGdBKDhy8XAWY8x5vTRV5+5MiC7L0oQKFr8rDx1fje1lf+2YXnDsi3jx28WE+CR8Ip3gErizHiyx6L9WxmW+0kKqxKbHkt4vmQAwXIqbRhnxxNIDK00X7i7dmdbyApU7hyvlYRTDilyADHaFibpnzosF5boQZ1PvyYirYUIuZmuCs/jzTKHAfk2NgemuAo3e0H1awT6ATHGf/3tqfjf9KzxrjOjr5BTi/Re90eFLQuLMKO+lCu+1qGPluoo/6B4MkmzXdnB6; 5:QBJFUqhHyDcr3TcYL/QMo5XhWJc/peMSVfLP0UY5zeIRVYWqghoZ1KfSOXgeyZfvON4rsSR3fYbNXneW4CAF8PqFl1PPvnbfa8iJgUts4dAFIxJrbC2x7AT3uR76Ibp2+1pvu7ePbhNlB9/RZk3OwPSaREU+hU/NXekPXDI6/G8=; 24:+/k+RVRqQr8KYDkpqqnMUoOSkUd0DshDEgEszYJEjhpJQ7cQe4ZEJiYoyOmgpieAoH+nlu+Eq7dNs0Rgo9Y6UGre9LSfQXur1D1a80guVCY=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2505; 7:w+Tp89BGj9pV9WKmwEkGxMWSgc3ZA53mV9ocCYVgm6pf5U7EQnIqfNYhZ+CeegHfJAn5L98wksvxWQvbRCjUAO7tGo5R6lpzYSS9i9Ka/V3j4BGGISeYq3G5JAVnZOKqJLhGpchYJ55tCFayjpIrBH/0MUKX1fk5EZIGh7LYHUL+Gv1dwopiceEY1YU6UKEMz+zZokclosCuXWbhPo9vW7voV31qKRAM6mZ7Slw2ftSkmXEqau+p53Yff6fftPWgnpdpi2zIuvBF103Pa9P+JqqV/SC4CNQzaoVE5sFFQO/iQN0jRjKrYF/mHiqEAtKj4+1tcpiQ/3EUWHFoWJRKoksrbylNrOTICohYzN0SCVs=
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Nov 2016 08:05:40.7462 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2505
Archived-At: 
Subject: Re: [Idr] Working group adoption call for	draft-snijders-idr-deprecate-30-31-129
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, 14 Nov 2016 08:05:47 -0000

The WG has consensus to adopt the document. Job, please resubmit as =
draft-ietf-idr- etc.

Also, I can't see why we wouldn't start a WGLC for it. We can discuss at =
our meeting tomorrow.

Thanks,

--John

> On Nov 1, 2016, at 6:18 AM, John G.Scudder  wrote:
>=20
> Hi Everyone,
>=20
> The author has asked for the WG to adopt  =
draft-snijders-idr-deprecate-30-31-129.=20
>=20
> If you support or oppose adoption please reply indicating so. Reasons =
for your position are helpful, as volunteering to review, comment, =
and/or shepherd. As an aside, I will note that I don't think the WG has =
the option of doing nothing, so if you oppose adoption please address =
what you think should be done instead.
>=20
> The adoption call will end November 13.
>=20
> Thanks,
>=20
> --John
>=20
> P.S.: =
https://tools.ietf.org/html/draft-snijders-idr-deprecate-30-31-129-01
>=20
> Abstract
>=20
>   This document requests IANA to deprecate the following BGP path
>   attributes values: 30, 31 and 129.


From nobody Mon Nov 14 00:08:23 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38FF31295BE; Mon, 14 Nov 2016 00:08:22 -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, 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] 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 b2tB2bxw01ri; Mon, 14 Nov 2016 00:08:20 -0800 (PST)
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0134.outbound.protection.outlook.com [104.47.32.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AA09129400; Mon, 14 Nov 2016 00:08:20 -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=ZpjKXg82Dk+bpVt4KUz3l6b5qNmSQMPCtEJa7WWZUEo=; b=aIbvxD7xZBD8/mXbjinr0khux8V8I80O3l3m2ZVgwrFOTzO98EOi9Udg7lVjczJSHlLQ8RdrlcVGxejtKFXBmbOIRPuTWnKhWxa/wRi6Cteblov4m0mSuuapzm9P3N6zOqjR1zt8tLerfL2XXWa5kBu4Z6MNFqhjpSo5jA0SnKM=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; 
Received: from [172.29.192.68] (116.197.188.11) by SN2PR05MB2512.namprd05.prod.outlook.com (10.166.213.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.679.5; Mon, 14 Nov 2016 08:08:17 +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: 
Date: Mon, 14 Nov 2016 17:08:01 +0900
Content-Transfer-Encoding: quoted-printable
Message-ID: <5EE54AB3-CECC-493F-9C17-A8B8DC77A290@juniper.net>
References: 
To: 
X-Mailer: Apple Mail (2.3124)
X-Originating-IP: [116.197.188.11]
X-ClientProxiedBy: HK2PR04CA0002.apcprd04.prod.outlook.com (10.162.205.140) To SN2PR05MB2512.namprd05.prod.outlook.com (10.166.213.21)
X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2512; 2:GUdXQ4IGhVr/YUZTg5WYdfnrxhzRY+i9AflMxEzz11kMQ5rOLyQw1ly8oyt2uJpvaPYTdaAjciA56N7ouu8k9NGvU1xP07APzRjfLlHCAvzQAEiFoQr7+49yZzyBojwPd5o9UjoEBzhokO/MyZLfByydxsCbgWU6PVTcZ02maU0=; 3:Tke29ugDJ8KKt77NFe8fRwFrK0J1rmvp7KbQVQvkZwEBlc8CoVhnwGAA8K0Xg9f4X0+5AfyZax9yu4YycYI6Cnd5F/IQ2FGzMlWrOp3h1zjtWzwtc4tcQEPIlRgbjQRMIE2Q/L0HnJ2np7hnI7ERt+0+zWjQxMpUOx0v7QiUvkE=; 25:nbUcRWBHAaIvTQsiKEkZJKOqGbSwkIDrUd3bCLuKwCAAReIV1o2Si35wwA53FzOraS2a0gB4kb9Rzp4Wf79mkcmimXDp81I54djUNZQ82m5AmFDsJEddR/bLxo5UbgKQVEoZNUrtRx6WO5RDYog0dRUCWm8Atqk8KXzdtOib5meRgTrHeTnNWnCRg2e10P8JGS9/lnv0PHiaCcNmQ5AWz0D1uY4SUqX6RZbqbcQq38avyhi3czKdwCsHqHk9gB4gwPouFC8KX0kRZHaRUb1AmhlVpwsW6Mq9KPzaqEcQd/ksvMrSlHTjx23CuQeQXYbAgsI9BWjsP1RBPz7fAE0sbLr8c5mPDT4A7E3fSJAK7yilylZ+sxAg3RBhBWHmY6kFF/GWjX1fp1+KgQRrTqwtiee6ptHC7UYM/RoJKW6kxkg=
X-MS-Office365-Filtering-Correlation-Id: 4b6ed24c-b312-490d-82b0-08d40c656465
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SN2PR05MB2512;
X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2512; 31:bygZ68aSnDy8O/UZNcmUNm4A3vEbXb6L3voarEeQQRi5b9yjipHqeWVLpa7OUHKk/RlIR0+nNGY7AVBs9fgegRcD4znYOa0LdS9VGnotUBHUb6H8KHuVJgCJv4lY4Sum3byzCJ4X4Bd4FS+dNmUQVVXiZKYjGgZ4lA5lEjFMHwkNaLFngv7gee49d5YTGA2aG2mp3bbgHGsXHgg0/1FzehoXj3mHIQEUj1T7G7QCFalYiJH2fmSTKD2wc7EVmkPt; 20:1VMkgudhufe3gdWp1J//C+pMoLp27OeP5MdnIu/qkME8BrEvt5KxZMVe27sM8QuLwB9pRFCds5gdCSECvXhkC9hHFxXJ4dzt+vmnN5es42wl3PbSNIJGlB21taIoA0VZh/Zoyejm1M94OuWcIbLPBdxdPRdj+LXkzwMwXs0moJCQtsoggu3l0q0xzxq9oaSPRg5b9ibOZeg3J+6QWpeEWC8URK5hLO17CvKp4Ptwr0Hn8QU8aiproQe35VQTzhQmDHTIUHKJJKXVsA0/LZT6XS+VY5aDOEUKhLooa6HGk0X0N7R7kzk0WYse+els35+wTMo0/01ttoXKRDtZ9dNp/STjO9VXAHEboIJUiaHAJ2wIFpVaUfjcw5lxrzqx8yXz2KI9U4TIej6PVlERDMzP6fkMbPbfsliaF0KKqr4hqeJOLIhY5QtjZbhQaemum4fOnaXrBaADw8pbVawiFVh4h7idNCpktV6yj9dbCU4Wo1qdyZbYhp0iweeUp+ebIxHe
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(138986009662008)(100405760836317);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6060325)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6061320); SRVR:SN2PR05MB2512; BCL:0; PCL:0; RULEID:(304825118); SRVR:SN2PR05MB2512; 
X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2512; 4:+mUKspl4tMs6GkViIk29sKgLChWvT3mvuP3t5nuCm0CTBQFdBl8x7BV4+w9fJO79Ncil590JGD5amMHQ/l5dY/b1ESb/UKniSP8AdtKGiA7MlfOKTSDVtHqgzozYPZso8T2a/9tKJ048eftxfo+LR60ksw14aaH5BzDJjF4wDWkNkLFHjSfKgGNqdgOii6ehl7AxvuZSFSMNjT0UbTgpb83pkFfCTGqABv7oMxeKRQvsMNZ4oYpr/oQ8v0J5kbentprikTbIvFi3W+4t0WHzUjuolorS5LblrdqUfGevzkoS+Yk2OivB48KiJDsO31KH2oYjhfGdFZcPylHKE+vxB74/OZwqwF92FZnG7rIR4S9fZG4Sab8kJrOide2iRm5iM7sBvnnPi2KZkuILQCUrG0I7ASQgCA6CSgQpmZlDezq+/3A3iBIGwOg0EzXYUnK0JjnrRFpy409qAauBzCvqUh1kM8JeKelL1hltZLQd1YpoUkNMbY3tjTaJSXytpYQrAtMz0MDocZ/KvfSrhKtF7Q==
X-Forefront-PRVS: 0126A32F74
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(979002)(6009001)(6049001)(7916002)(189002)(377454003)(199003)(53754006)(24454002)(7736002)(68736007)(7846002)(86362001)(47776003)(4326007)(2906002)(8746002)(6116002)(83716003)(33656002)(229853002)(97736004)(586003)(3846002)(23726003)(50226002)(92566002)(82746002)(81166006)(6916009)(66066001)(8676002)(5660300001)(110136003)(97756001)(6666003)(77096005)(305945005)(101416001)(450100001)(81156014)(2351001)(36756003)(2950100002)(46406003)(105586002)(42186005)(50466002)(106356001)(57306001)(76176999)(230783001)(50986999)(189998001)(104396002)(42262002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR05MB2512; H:[172.29.192.68]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN2PR05MB2512; 23:jsYdeEtROVLL8OkiGD41LDOnVro1IeJypU8VCEoX4?= =?us-ascii?Q?fErMMZdllDmqNO8Lsi5GeaFJwOxxmv09D5cOWjoUBxHBQvJM58xChLkflmg0?= =?us-ascii?Q?KG9p1kbAs/gqddlyWLWenx7NpAfko7/JMsPU8rOiJTvji3/BDE5184Kp3nJQ?= =?us-ascii?Q?Uw383dXgcWW7HhyP1wWpLfJOzdZTsS9BdFClfmyl5iIv949I/XDA30o5UXXK?= =?us-ascii?Q?qPC5h9nd/rDWbKTDD9nhH8RFsFyrJeftrqcVik5smFb0AOfKm92e2/HYzLV4?= =?us-ascii?Q?WosM6PWrxP1tKdEk5sFkf7XSbQQcyoxSbz5Bes5R4FCLsFZA3r6VXF0yt5NW?= =?us-ascii?Q?C7gbZRLiPLLCOun9VjAvK1j+J94ws893OvNDKsIL1mSZMTLNZOmRudFzJUzs?= =?us-ascii?Q?lhkvRRBnnBR7ErdyNPEIoxc0rNJpoJxBciTaSbp9qCtSNWeeDt5GA1t7CTi5?= =?us-ascii?Q?2WvooiA4m6tx/Rj+Olx5kQ+AILwXEAoW8gCWkLuZ6+S1z13gYaZRPkyLgtUe?= =?us-ascii?Q?d82BDCUdb80ENQNd+njgZ8GmzbKEkRAvgIADR8kO+W2qh/qfVJKVSCSFLGv/?= =?us-ascii?Q?dd4ZojsEWJMVQmjcN0M7zUfnr0M3DYrDO8G7SqECAEqnPLUarnGXYnbPCxsq?= =?us-ascii?Q?VPn04g6QsVj9vPglqZSYthzR0I8wsPhmklgGERpinKMr//nbV/zfEEPbI5X1?= =?us-ascii?Q?Nhhtb6Q3XQxtjoVGU0ZYUrpAt3rm83QrEkZEqo05Psd3Bpjj12BWi6TKEh8b?= =?us-ascii?Q?Y31YNz1Hy+WM60UFfkoswoI8Z/bqf9a/yVgnMOEd2z02gOp/vNJZH9rDvccs?= =?us-ascii?Q?S2qU4lwbzmMJXu4MpP0M5H9gP5+pYdS6+T5eCHOYOLi6WMFpeZPZZk5QR4Bm?= =?us-ascii?Q?RdnfGCeI5YhBnEj7jRCA+ioIm5gG8ASmpCA4uNQUyvN9b44QkqG+k9OuVRxf?= =?us-ascii?Q?KjiE44yHW1e3x34Y8bPc/YL7EZV4JsOWgQy2TxRM693TUopPVHfsyA3BB8h1?= =?us-ascii?Q?SM+MTjbII3xd/lRvDQxhWlnusv++PLRYGFoHY+05JXe5obaH9wDmYhLel/3G?= =?us-ascii?Q?9lq8RM1Ix1MYH+40+VYy+TGU90qrNasNCeVrYZffV+1KA34tJeYZfxN1pS/u?= =?us-ascii?Q?Sf3Fla4ojcMF1StRdZMSKX1E5rUaEcgvYBIrOAadX5MLP+YesXCz977vkYsM?= =?us-ascii?Q?IUPZ6bZW/i7FrwSeUT9Z0bK09BcxuekgxkW1Rfb+dA3Rs7FiHCKZ02v8XeqY?= =?us-ascii?Q?upZyH29DRz4OeIOmvs4wGL0e0IZvIgihk9gsht07RvfvLEfC5WFn5niUiiKe?= =?us-ascii?Q?PSqujDNL9XuVozeEKJf6EAXuZBhPsQ8Bomig02ErHfn57qtMOCCAExkVhcKF?= =?us-ascii?Q?oMmkSTDtRvvxU/UNEN/BMeSxZy/Zv0lE5YHhxKnQsbfpXb5?=
X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2512; 6:HMO5Of58wrgpL2bsATOFVS6ta0Wubk3I/VNem9JFyAh0549ALVLASSE3tDQjCRYAL7/NpiARHOmDXloNWKv7NBcvXQeEu9dmdA9sfLUZq3p0NHJ/Cw9+9VunhOdqK6roaArAPySLC+xJ4Teip+zyx/JkhRD7t49KhJDKy76+ZwYV0wbZXgi71Bi4kjSyEQ90Cc/iiUisA2t3tOrB0iHdE8TWNQw6i3A7zSGLK/6Qt18S5fZy20rM92bDTz6UhqGnLOFwFGZwpB7kJDleecl4bO34T90vOVBwbbucGW8KcvT42RSM3QDPvZyJjvXRUYQzoFreVfmzGPUDwYvQMIHODBsueLdvakUA/FdpH/BODT/DtclpnEpabT2fAi8vkvFp; 5:FFrQA9Mx4iaPYo9ck1fxGSl7UI3PfE4hKfLhja+95mlraW1oKuyDa4Bnjg4AxtS/B50g9a9wZjkiR/f2oY4QB07Zu2IPS/xVSKnbKErEsql9LOpPo5lNI8upypo27tIBleLmywnjsptCw+NMlk2G1jPOiJm3GlhVTIVnpvB9+8TPAqWuWEQQkYGODsOL+n7H; 24:7FYSt7eMkXTP+hSIdUd0FFobPHFp5j2hzehlinTSBJ2oxGI8sgzOCQqlXlUlWmIj7mV4L4b5iugX6gTw1ebhfnEPClLm6OSM9dILUfTgXtY=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2512; 7:M8gFD+5iMyiRpgDMdDbFUlV0H9IRDUAjwxv+HimcxqGUUjr14KTiKkNVi8yL42L5ikbcKB16ohffnpjZdgWGdOu5qp/fXdUdxC2lX5KMfSNHkYPIDNo620FUkRPleMTCWgvRr/jYgbC25vubpq7WAFaEm4OGST3aHP9GyzzeINd032zkegemYcvYkan3Aot5k2q2qezSQInyBcuEChw9xMPIsZDZcBrA08ZIe6NWdrFUKF52pg2bf8j36CPqLTZ12Fwqub/BQeHWJBxxf1jitG5HVfGy8zOi3aD2JLOtXxbGf59REPRuNA1wriWJ0BRo37xLEj2JzRqLDKViLbfiHBpuCDLfveuFhpakWHb/aIY=
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Nov 2016 08:08:17.0577 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR05MB2512
Archived-At: 
Cc: draft-gredler-idr-bgp-ls-segment-routing-ext@ietf.org
Subject: Re: [Idr] Working group adoption call for draft-gredler-idr-bgp-ls-segment-routing-ext
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, 14 Nov 2016 08:08:22 -0000

We have consensus to adopt the document. Authors, please resubmit as =
draft-ietf-idr- etc.

Also, we have consensus for early allocation of the required code =
points. The chairs will work with the AD and IANA.

--John

> On Nov 1, 2016, at 6:16 AM, John G. Scudder  wrote:
>=20
> Hi Everyone,
>=20
> The authors have asked (some time ago actually) for the WG to adopt =
draft-gredler-idr-bgp-ls-segment-routing-ext.=20
>=20
> If you support or oppose adoption please reply indicating so. Reasons =
for your position are helpful, as volunteering to review, comment, =
and/or shepherd.
>=20
> The adoption call will end November 13.
>=20
> Thanks,
>=20
> --John
>=20
> P.S.: =
https://www.ietf.org/id/draft-gredler-idr-bgp-ls-segment-routing-ext-04.tx=
t
>=20
> Abstract
>=20
>   Segment Routing (SR) allows for a flexible definition of end-to-end
>   paths within IGP topologies by encoding paths as sequences of
>   topological sub-paths, called "segments".  These segments are
>   advertised by the link-state routing protocols (IS-IS, OSPF and
>   OSPFv3).
>=20
>   This draft defines extensions to the BGP Link-state address-family =
in
>   order to carry segment information via BGP.


From nobody Mon Nov 14 00:17:26 2016
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 F13A01297AB; Mon, 14 Nov 2016 00:17:24 -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.37.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <147911144494.870.16491202689150685454.idtracker@ietfa.amsl.com>
Date: Mon, 14 Nov 2016 00:17:24 -0800
Archived-At: 
Cc: idr@ietf.org
Subject: [Idr] I-D Action: draft-ietf-idr-deprecate-30-31-129-00.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, 14 Nov 2016 08:17:25 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing of the IETF.

        Title           : Deprecation of BGP Path Attribute values 30, 31, 129, 241, 242, and 234 
        Author          : Job Snijders
	Filename        : draft-ietf-idr-deprecate-30-31-129-00.txt
	Pages           : 3
	Date            : 2016-11-14

Abstract:
   This document requests IANA to mark BGP path attribute values 30, 31,
   129, 241, 242, and 243 as "deprecated".


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-idr-deprecate-30-31-129/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-idr-deprecate-30-31-129-00


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

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


From nobody Mon Nov 14 00:47:14 2016
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 858D11293E3; Mon, 14 Nov 2016 00:47:13 -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.37.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <147911323354.1013.14370244901854041920.idtracker@ietfa.amsl.com>
Date: Mon, 14 Nov 2016 00:47:13 -0800
Archived-At: 
Cc: idr@ietf.org
Subject: [Idr] I-D Action: draft-ietf-idr-large-community-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, 14 Nov 2016 08:47: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           : BGP Large Communities
        Authors         : Jakob Heitz
                          Job Snijders
                          Keyur Patel
                          Ignas Bagdonas
                          Nick Hilliard
	Filename        : draft-ietf-idr-large-community-08.txt
	Pages           : 9
	Date            : 2016-11-14

Abstract:
   This document describes the BGP Large Communities attribute, an
   extension to BGP-4.  This attribute provides a mechanism to signal
   opaque information within separate namespaces to aid in routing
   management.  The attribute is suitable for use with four-octet
   Autonomous System Numbers.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-idr-large-community/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-idr-large-community-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-large-community-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 Nov 14 01:11:19 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28B0D1296D3 for ; Mon, 14 Nov 2016 01:11:19 -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, 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] 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 6viY13obOM9f for ; Mon, 14 Nov 2016 01:11:17 -0800 (PST)
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0092.outbound.protection.outlook.com [104.47.37.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36AFA1296CF for ; Mon, 14 Nov 2016 01:11:17 -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=lFIiZi4pVuXmCsXORH7VYjUf15UXAiAsa8DBw83kXUM=; b=Z9n9GcegcliiOpd/JYRWQihH+22vWE9QVFxChn59U1Vu9Af7Ch7tn6CHPDuWjaPJF0GB+QsxrAUTH1DYdt8etafjBy456cSoF+QJashD4e89uDViueJ+eVeCiuDmkAcb3fnS++9Zjl5NBWU3bfH9MKD5dO+pGR+WQr4YYqMiu/E=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; 
Received: from [172.29.192.68] (116.197.188.11) by CO2PR05MB2503.namprd05.prod.outlook.com (10.166.95.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.734.2; Mon, 14 Nov 2016 09:11:12 +0000
From: "John G. Scudder" 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Message-ID: 
Date: Mon, 14 Nov 2016 18:10:59 +0900
To: 
MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Mailer: Apple Mail (2.3124)
X-Originating-IP: [116.197.188.11]
X-ClientProxiedBy: HKXPR02CA0040.apcprd02.prod.outlook.com (10.161.48.25) To CO2PR05MB2503.namprd05.prod.outlook.com (10.166.95.149)
X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2503; 2:NlR/zRhJQePh/0Khf6lR4Vs3kE2Oi2stTL3dm+XFsZqUXbIkHRVyC5SsBuyMlmJjfxhx2uUijzUzeLdXZa1yII/Sy/gS5BEo3XkajOzdKBnNBaNYIrCXengG2oQQLZYDcB5l6Rlwr8foNZpASrf+PbCVpWBqZop332YQjAje/zA=; 3:uSm0CBvUqJvtbREYSFMdwLou+K5deRtNgq+1YV2u1f+KUqrBKN90tFUbjozwlU/fiomyo1SUf6NdlWi27rE4FWNZsQAazjc+AFwkCBBkgJcPkf99RTWnZ2cb81ATLJ6yUM/XMvtgSfuPnomwby9g7iX6khSl/OORv1y061HSr7U=
X-MS-Office365-Filtering-Correlation-Id: b37890b7-b65a-4a8d-64d8-08d40c6e2eb6
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CO2PR05MB2503;
X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2503; 25:N1wcUg/n2n2HoSLwSFUl6WliJyUuhoWEplZkypdbCz6gZwKVbQseyxUVxQakE993y2WE2BbbtjklOTMXy5479jmntSoho5wtfverPuNqi9EbIG8Vs0sNrHUG5SoJjRqpMpGt+l+cxDyFiHvdWU8DqqkWZpmH10X2GPQJc7IqF0tTCQr2f07oE3ATWfEDB37nb/038hoBrtrVIlkTGEA60XRmolhjmIT9iyoL7cG5d2Mmaj8lMKDXbMM6kDgg0DMvNCtbHtIPNvXKsC7FGx2H1MkzKP6wqJrcp7mCu4Odki3rU1w1A81wnH8UltHoXyRW9wpHy6IUYXyiE13n1me8qv3dfu/ed1en5nOrpCqa4+hJUH6tCKB5TdfduPIVRXunpEqLf1U0Ami3RpezP3nk4Itj9JLFunVhFTSfp51hfPE1Rav1eBNedJ0SQhYHAjKQ+vGk95fMOo3xtDNykqWlQtFFpk9oq9wZEIFi5Ve3B92qUB59sfqvKkAhDIhexdPnZpgNJYkRM1zgORoTX5D7khw8pWFvbZLED5fuoS/Wo0g1c36vryVEi36CWI+EhpXzgYYCgPArVJv26CpIc368WOY4C7WlIlVqd+REl+8My/ruAqW3dl2cBYfIC4e8g6aiyCbe74heoevGUemLUUZZsPBp90movP53eUgHVe1sOPKNObinj9naTI/rlir/8SNQGQMfr1X29vHzPp+8WIbUe1wXACivrQMavqqwKQioYkoxBWSMNgOcJN49K7ZQ0dwTYbYy8XyBxIzeWouXBlhzWRzzoNeFfgfXpauVihst9wp+fZt0UhbAoswrUgSYCqYO
X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2503; 31:+AoxVGZYM5lMVGLtFwdJLQ66wIoNjHssrdoy5cu6xIsMQTBKd+qxp6BIkH4TpzIOIjC6B257radIV3VsZlwUggDH1TWfRdhaDCpKgjt4jIcaUQRbgHdNBjh4jFdHhOgOLrcotKp0fVmTdOsgS3WYjWqPVCnVfjdcxIaWDyOPwvZVNLV7hMTppgwYYqu1RCi4Hbty2oHkwdjvRvhpFb9D7i7PkPXQvuDJzgwpj4DYgDIsnOGmgSWorNA2iAnhpCSNZR/qcEQuV8edJ7EgLuGSyG0hcDzFDjipyqxCgEWrPwY=; 20:PoOwBc3zsYPQb8OGQT/TYz0hKgYtI3AU7uWngWiXj2AZSX6cRrI93hnw2iKhBuIjw7WYb9B2CI/tK1IPUyHPv2MOP67MbL+rIUXEK67fYHOThRLpi2RmiCKqyklsEtbKLK9dsk4aVIKgCwyrGhBO/WJRBTCdliMX3zw+l3ENGBvXG6wN0iC586wMcjxr5CvSVG9nvRHAl1wktaBOJ4e15Tfgjwk1DbMwb1S4gG+1OnCCQ0Z5QhHlMFxHzciccyxnyNvYTHBvplg7JQzo069He2WWlZ4l9kjKHwJ0GltLsGtPzp63MtUDPRtXOr+nQ/zpm0zuBBHN49zUHwCUA2+Ht6RHh2c3zuu0qG5Ekku5KbloT/OJOiGezQqpFvCf+Jhylkdl0VmlCo2waaZ0gbnTivQEYwGlOum97l3jorlNC3km7JZvyEjq1Zjm2JdK+2JUMehQ1kg/sq93wK+zi1Gh/81Rq9qzVObhUyZT7p8FADhp48ZBvvxG1vPp60P1eQF0
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6060326)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6061321)(6072148); SRVR:CO2PR05MB2503; BCL:0; PCL:0; RULEID:; SRVR:CO2PR05MB2503; 
X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2503; 4:1cz073ssR+jKAmVRGyWcAN/49Rdi2mr/Zk6DVLIY5Si0S0rr+8urG9cszRrP1X7X0Py07HPJ3pcsmZ0OArus1LgjUgavllrpqXdGZFZXlh7JQtTgJDrgNDslDhcqgjNSZ6Q0C3IAObDqmG07cvRWC3biJVZ9l6iYa4ynFEk4i5vrs98CLmrUetbMKngtwxbwETKdphLQrUftqx3a7qEYEYmJrlQyWcaL4cNoIxSlxO0OrUeHTFjrj1NHcM45mbnVVSJAJ/FwuNVbuPqJMRX5unD66VMsskEW0Ky1o9Wo5S/ddo4YaXxMLBpHzfNSWAmDK+DQQujw9VC3dWDUS+kF6ziMcQqit/R17BOmgMDREfNvoPEXLFmRISiFfM+KX4MPCB5Y9cR9VJXMVIF3DXKlFoepMyhWeFGcw/UBTeF73a9CercxrOQSmaAGNchz0MMBkk+1Dls/YRcfoq+dy6VAow==
X-Forefront-PRVS: 0126A32F74
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(7916002)(53754006)(189002)(199003)(7846002)(7736002)(305945005)(50466002)(189998001)(450100001)(2351001)(586003)(3846002)(2906002)(6116002)(23726003)(68736007)(97736004)(6666003)(81156014)(81166006)(6916009)(83716003)(50986999)(82746002)(101416001)(106356001)(105586002)(42186005)(230783001)(47776003)(33656002)(86362001)(97756001)(36756003)(57306001)(46406003)(8676002)(110136003)(92566002)(66066001)(50226002)(107886002)(8746002)(77096005)(5660300001)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB2503; H:[172.29.192.68]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CO2PR05MB2503; 23:78e0AFJ5oMd+HgeULhiV4k3694tTjAWi7es8BvCqd?= =?us-ascii?Q?fCmSZrnf4FVD8ie8jAQcVITDJLABmfMoFbcU/XTOGFY41KNU9SumTsRsOKrr?= =?us-ascii?Q?ODUyKU9q/2DfdHguhaeBXdnzFx48b8ME+Yxo3M2mahXg6vejVL3XsRTzAWEH?= =?us-ascii?Q?Q6E36IxSxALAtA6QZzDT01GbfqzAO35YasdJhMft43zjcxLViTij4aFRcrWs?= =?us-ascii?Q?v3PUPps6/NI5XBx0YpzSJLzoDiMrR7tVn+jU9O39TGMC8itcjgQsffALe8TX?= =?us-ascii?Q?EhrMtUuPU/p9y6TZBO7utI90YZSv8jHrUKs94cJVox3Vdl8OXjiWjd6KliiC?= =?us-ascii?Q?RuBTG/UOZTNtV1xQivdBAyELbDp02E47qh5genSyotsPTriJWkhsElzO0Ysh?= =?us-ascii?Q?xn6lb3YPlOldlebyepaIaE+S6t8hYCDuDMcVvlp0ydPA0TXAhVmdWmSNr7x1?= =?us-ascii?Q?31NSVJhGkP9dLUWt8LKCUczJ+IGvR+UAARwcVkWb2shxQ04qNHPer61jyeLm?= =?us-ascii?Q?4Y8ysQ55Ewqva4zgAiIY43BgxseOpN5W5qNwGwcJjbia9TTM6LXRJSLdBVVT?= =?us-ascii?Q?Nn/URAkupGqHGYGsMFI1s0qloDq+4r0FkHqUX0Zhh+HvV2+IjtEMPgkpzisO?= =?us-ascii?Q?t/0klu3XR8nOpjH0NEI809HwSyOf186I3kgTlJtblHRKLeyYLrdoK7ci4SRG?= =?us-ascii?Q?yFRYu233foyLsyRy1UtEo838+5hmdvkrvJFhylGO/IviGwek+Hp1NZTEQplu?= =?us-ascii?Q?JJcc6OR/QQnsKgZv4darMKUvR8W3k/l0F7hYjMysnwtice1kypUTLHVqvgEM?= =?us-ascii?Q?nYINSjId7x9J4lqmq0lkkMzJwwQ8yqspQKkhNpToyWwVPtvobROTsQnekDF0?= =?us-ascii?Q?GnZV92f3d03q3/Yif/+I6ZVWbiT0w6cEah9KDSQ8J5iX/Mn5iJLivN5P3lb3?= =?us-ascii?Q?itEny01DLsIuynyDrd7ESbL5XrOvZYXUEGE6o1BSbj1gmr1znn6Q77VrOhdf?= =?us-ascii?Q?8VVe0SuWDTc5aHtpARrLDDmNXa+SNRE8D5eq62C39NTvpAUAXF6b8EoTQ1Hp?= =?us-ascii?Q?yFUZDoO/wZ6xq17XtE/GlbekNtQ3zgqeWCmPCYxZsdzoSIK5SLgKQgQrPsF4?= =?us-ascii?Q?uC+Co7zqvk+424loc8ssu5guOSINz/pIEH/No4CoB3trmk7WvGwZBnN0ZVeU?= =?us-ascii?Q?hFB0RnFOvelQbLC1FU9NGYpwZP1bEwpV+r4?=
X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2503; 6:l3BnU6Olt0DfUqZYvL/YTAnSvYaEFumhtHcfm6t3lm6T74TynFpd2CzonYjUl3ImG9bLaqwvfv49iM8vFTIbirFSC9qVS/DcDxD+TMIE4W8QQtetzzP+GbMEVZbKg4iPKibjivqb+9ZOMKguhGAZBBhxhLesc1sQvl3RRlw32QcHPQn62xR6+SNSAHA78YHV8rkgrURVTrKfEzcm/SotuEhDZCDbnpUMag5/SvzYQOTmh40bVRbXoy8Y/X+a4lBhuehnaBRjpDPavPU1r7KaTaWka4sEonuLYNvapMMZsfftYTcv9hbm0pmlBoQ5oGqE3s0xJLw1yiWobCRYP/EvUbAIbfv+14rbC+senT1BvhPJMMXOjo1r75y9l6njZ63B; 5:na1BMu9pZkf5gyvgPfmUVUh6rhaKCSuh+yzJcDOobiEmBBRjXDVfjHXhmuDgrNmofRPhfESN6iJQCvqRvWJBaUF0hGBTN12wsK6WG2ZG+om7cFcAXop8SA4RMvkI9VQGnqQ5tO3blFfxX/Yg1637kw==; 24:Sg459l2t4fsi4QCsY5dim/2FfW8twVMk8V/fKodUai0bMXCYVvZLMEoH6SYMBV3Bqo1HoREQtmLELVS2YI3NjOYhKP6fh8FNC/kE90QVtlk=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2503; 7:gN74XLZvH8/fNYOmLONi6r//4X01kEGeMdNEjVb40u+My2DzKfun5ci7ZyRMFxRblb0zUCym3rM77Tvmze+b2bB5jzOM5zCpwVVeyFk2lCZ5hOnyFoh16k7uTEyrISpFp0aeCHIbTvG9LK/Rg8b7DDr08yRbyia3E8T5p6kDVXAeRQZ5/rXCxLfSR9a8/zKcJIv+H+8GXL1J/QRqpBW4OoABnkCnOfCDHEuwIA+L+DI2c8op6bZ3uBctKWn//oxf3M+HdskgIcDUsnMWghcaiA260FTxbu54AtWEKlHyFuy3kJtkJeqh5Gzn2psQ8g/DjmFxXjphUVTgjahfnocGjcrngRTZp3COSI3/Yn+RJnE=
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Nov 2016 09:11:12.1812 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB2503
Archived-At: 
Subject: [Idr] One week extension to WGLC for draft-ietf-idr-large-community
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, 14 Nov 2016 09:11:19 -0000

Hi All,

We originally WGLC'd -03. The document is now at -08 as a result of =
WGLC, RTG-DIR and Document Shepherd review comments. Most of the changes =
are editorial but there are a couple that rise beyond that level, and I =
would like to call the WG's attention to them. The ones I've identified =
are:

1. Canonical Representation. -08 specifies that the fields SHOULD be =
colon-separated. -03 did not.

If anyone has an objection to this change, that was not already =
discussed when it was first proposed/introduced, now's the time to raise =
it. Please don't reiterate a comment that was already discussed. =
(Consensus so far supports the change.)

2. Duplicate values. -03 used SHOULD:

   Duplicate BGP Large Community values SHOULD NOT be transmitted.  A
   receiving speaker SHOULD silently remove duplicate BGP Large
   Community values from a BGP Large Community attribute.

-08 uses MUST:

   Duplicate BGP Large Community values MUST NOT be transmitted.  A
   receiving speaker MUST silently remove duplicate BGP Large
   Community values from a BGP Large Community attribute.

This is a new change made at the suggestion of the Document Shepherd =
(that is, me). If anyone has an objection, please raise it.

Other than that, the rest of the changes are editorial and shouldn't be =
controversial AFAICT. If you disagree, please explain why.

The rfcdiff from -03 to -08:

=
https://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=3Dhttps://tools.iet=
f.org/id/draft-ietf-idr-large-community-03.txt&url2=3Dhttps://tools.ietf.o=
rg/id/draft-ietf-idr-large-community-08.txt

Please raise any objections by November 21. In this case, silence will =
be taken as consent assuming you've already supported publication.

Thanks,

--John=


From nobody Mon Nov 14 01:23:44 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34E951296F0 for ; Mon, 14 Nov 2016 01:23:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.398
X-Spam-Level: 
X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497, SPF_HELO_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 WVm5_z5XzzAk for ; Mon, 14 Nov 2016 01:23:41 -0800 (PST)
Received: from gir.theapt.org (gir.theapt.org [81.209.183.113]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D99D12969F for ; Mon, 14 Nov 2016 01:23:41 -0800 (PST)
Received: from gir.theapt.org (unknown [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/0 bits)) (Client did not present a certificate) (Authenticated sender: phessler) by gir.theapt.org (Postfix) with ESMTPSA id 0319E7892C; Mon, 14 Nov 2016 10:23:39 +0100 (CET)
Date: Mon, 14 Nov 2016 10:23:38 +0100
From: Peter Hessler 
To: "John G. Scudder" 
Message-ID: <20161114092338.GF24817@gir.theapt.org>
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: 
Cc: idr@ietf.org
Subject: Re: [Idr] One week extension to WGLC for draft-ietf-idr-large-community
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, 14 Nov 2016 09:23:43 -0000

On 2016 Nov 14 (Mon) at 18:10:59 +0900 (+0900), John G. Scudder wrote:
:Hi All,
:
:We originally WGLC'd -03. The document is now at -08 as a result of WGLC, RTG-DIR and Document Shepherd review comments. Most of the changes are editorial but there are a couple that rise beyond that level, and I would like to call the WG's attention to them. The ones I've identified are:
:
:1. Canonical Representation. -08 specifies that the fields SHOULD be colon-separated. -03 did not.
:
:If anyone has an objection to this change, that was not already discussed when it was first proposed/introduced, now's the time to raise it. Please don't reiterate a comment that was already discussed. (Consensus so far supports the change.)
:

I support this.


:2. Duplicate values. -03 used SHOULD:
:
:   Duplicate BGP Large Community values SHOULD NOT be transmitted.  A
:   receiving speaker SHOULD silently remove duplicate BGP Large
:   Community values from a BGP Large Community attribute.
:
:-08 uses MUST:
:
:   Duplicate BGP Large Community values MUST NOT be transmitted.  A
:   receiving speaker MUST silently remove duplicate BGP Large
:   Community values from a BGP Large Community attribute.
:
:This is a new change made at the suggestion of the Document Shepherd (that is, me). If anyone has an objection, please raise it.
:

I object.

RFC 1997 and 4360 communities have no such restrictions.  Why should
Large have them?

I would prefer leaving them as SHOULD NOT, or dropping that paragraph.


:Other than that, the rest of the changes are editorial and shouldn't be controversial AFAICT. If you disagree, please explain why.
:

With the exception of the duplicate values issue noted above, I support
the draft.



:The rfcdiff from -03 to -08:
:
:https://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/id/draft-ietf-idr-large-community-03.txt&url2=https://tools.ietf.org/id/draft-ietf-idr-large-community-08.txt
:
:Please raise any objections by November 21. In this case, silence will be taken as consent assuming you've already supported publication.
:
:Thanks,
:
:--John


-- 
"MacDonald has the gift on compressing the largest amount of words into
the smallest amount of thoughts."
		-- Winston Churchill


From nobody Mon Nov 14 02:25:56 2016
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 0C035129536; Mon, 14 Nov 2016 02:25: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.37.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <147911915104.902.1955127410215681131.idtracker@ietfa.amsl.com>
Date: Mon, 14 Nov 2016 02:25:51 -0800
Archived-At: 
Cc: idr@ietf.org
Subject: [Idr] I-D Action: draft-psarkar-idr-bgp-ls-node-admin-tag-extension-05.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, 14 Nov 2016 10:25: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           : Advertising Node Admin Tags in BGP Link-State Advertisements
        Authors         : Pushpasis Sarkar
                          Hannes Gredler
                          Stephane Litkowski
	Filename        : draft-psarkar-idr-bgp-ls-node-admin-tag-extension-05.txt
	Pages           : 11
	Date            : 2016-11-14

Abstract:
   This document describes the protocol extensions to collect node
   administrative tags adevertised in IGP Link State advertisements and
   disseminate the same in BGP Link-State advertisement protocol, to
   facilitate inter-AS TE applications that may need the same node
   administrative tags to associate a subset of network devices spanning
   across more than one AS with a specific functionality.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-psarkar-idr-bgp-ls-node-admin-tag-extension/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-psarkar-idr-bgp-ls-node-admin-tag-extension-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-psarkar-idr-bgp-ls-node-admin-tag-extension-05


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

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


From nobody Mon Nov 14 04:23:24 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AABE129540 for ; Mon, 14 Nov 2016 04:23:22 -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, 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] 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 iuvKQmg-cPP5 for ; Mon, 14 Nov 2016 04:23:21 -0800 (PST)
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0092.outbound.protection.outlook.com [104.47.34.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5467129468 for ; Mon, 14 Nov 2016 04:23:20 -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=sA0ruu6krXW7CN7+M0+ERvcIu2Kpd3VNACvuPSyxONs=; b=lKCAhE1Z+Lv3WLXjhy3gc5KvK1WinqQYa+YZmoPrrcxBw1b12pBp1qG0KN73kMV7PTJUodqsUCpD0J6tuc2CyENY4Ifnr1O5VTSwE2GIKkn/UxTPdhoov7z/jsLX91gTKYtsVGkGaFla9gaXYt3T/xYcBsz/7WuamBw3F13yKf4=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; 
Received: from [172.29.192.68] (116.197.188.11) by CO2PR05MB2503.namprd05.prod.outlook.com (10.166.95.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.734.2; Mon, 14 Nov 2016 12:23:04 +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: <20161114092338.GF24817@gir.theapt.org>
Date: Mon, 14 Nov 2016 21:22:45 +0900
Content-Transfer-Encoding: quoted-printable
Message-ID: <18460A64-11D9-46A1-9388-5D751648A88C@juniper.net>
References:  <20161114092338.GF24817@gir.theapt.org>
To: Peter Hessler 
X-Mailer: Apple Mail (2.3124)
X-Originating-IP: [116.197.188.11]
X-ClientProxiedBy: HKXPR02CA0030.apcprd02.prod.outlook.com (10.161.48.15) To CO2PR05MB2503.namprd05.prod.outlook.com (10.166.95.149)
X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2503; 2:0C5NrCoohWhxy4D5HzdxCoM7CLo51HZF1wzdEVfDqfCLKVpkmx/A2CZXUXIVUJyiPfxku0MojhJP6gveMvsMNt6cQoaXxq86zc4LSfyYJ/TnG0QOHxxqSFdq6LBg38h1vex5PcGz1RlaRP6YDE/cACTXqeP+idsrnH9l8tVufsw=; 3:M/Yo94FDyevF3TR9BJ0QihdfToXxTen/PQjIRZBC1Dby7BMC+AcSsoh1ifRi5+5u4LBWEDo8a/Q/dlUtQmHyjj77verw5pvsdAvD/USoxq99QF0MQ7UqqD1HchuKQnMz85jyGXnmmzgyxZx8v5a+z4U2Ye8+DngDgZ/IGAyNkEE=; 25:SPCxnOqrVTmrRKDuxvcEuQw3aHPcx2OWfpAEUUDOncLpL6xEGBh9GM1+8Ln8q18xmx+dOwL1lF1uZnjfb9/qVPfoIy6poO6oqB1FaIbvdaiapW5hm12jNx3kLMqs5zA4aFRZB2vEKOYTbl5Gc7qyBYW1KCO6Po+Dn1n2610rNsykU9XidW5Ilikhf6uxGDa1Avlt7Bg1LLkoPLyJ1jSjFTbf4unQAQa49HRcGsz6xMVBzmJfXCmirP8JABPvfcbXcVYnOTMC9HfjBX9bwNYUbQDLrINxdYZdcudqCvDOgXWRQwcFFmZfCawxqrDGWcIaNCUniFP4rkToOTDc+v+af97ZmJapBZepVLKzxcKQZCMFRgSMMy0gV86xa/prYzUTj6Z/16Y9ZusOFZOReu3xQRq1q0jii9cztFlCWz+QgVGCmujLoapeBKU9ipd7FHlL
X-MS-Office365-Filtering-Correlation-Id: 9656c42e-4f47-4bf5-c1ff-08d40c88fccd
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CO2PR05MB2503;
X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2503; 31:jH+fGp7+X0zI9x8FStntsowB0b/zFb/oOX1iQ/xuDpeexb0nZbwkDs/aQtyDur7WWhSDAwVYrHoW/BX5eUO/n4heDWLAUWhFEoe8pdFjgPZ15UE0sKGWay6plMUW3Hwl2wdJRPBchAjnrgT+1nGWsqoeUQcSq8x+doXPvEm90mPGEAQMyOeVvE/KqvAR9fQV9QNbe+RLfH8uhK1vt5jEXom7+mCOVcAW+QjT8Ix+o10/ksd5VztRg/7aatQ2gjx3; 20:fNMohqYBKCx3IdTHUi4Kbxl35tCCYcqfqzImBK7xcs7WhnuwcUmdZdxle793qLC9jqYZsrAYvZgD6l+BmmhbB7NTk8sjEHJb7zJfXJzM734SodjjeZRD2twGCfscgAW5C1onUuw/9Bwd6NgLzp93SGBc9awVVyxvcsOBXc0D5EcPMK/Nc/ryxmGXgnleH8ZJD7QdpWwe3btCWM/0Q9A7GeVfMEvZyVTgIFqbJlsQY9KCsFTYQO6Iga+YwLIe/ZBpCdnw5fAAI0lNuprVRkvoRexQJfKztdsVvBSsg8E1JZcKlX8vSwWzqe1XKmqj982x4ScYdNcHaQ10J9PV782MDaEoZvG+0uk3xGJr7QRGMDqGLuT7EO9BeENyc8ceg1lWcSIVRd6m2KRhGHF+g1ijOioXFJ0N7D+gYrPl+Ki2sPz2ONcNt6DtPn3ihnpfWU/zDnQUxxnw1LOmzWK1losdANP3G4loCfSqgrdyfCMYBgVRR1GvStEvgYr54cHIBS8t
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(100405760836317);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6060326)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6061321)(6072148); SRVR:CO2PR05MB2503; BCL:0; PCL:0; RULEID:; SRVR:CO2PR05MB2503; 
X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2503; 4:sXNofuS/Vx+lHo6zqnfFIglGrYPIgk0xL9pg58gKbbLJviVHXmdj8Osm9IQDNnDLHkLa9d5yu3pKLOi01R/wZSHTB2F3eFRgbZ/EGG4EmH8By4twKL4tIjGC4JoWDkoYQVS765P6WCXcuWHFdaH3W4+xJ0H6rY0RnEKgJXHBCttsT+EoBojTHJtdZzxzVm05FtKiQWS2nELu3b6Lt+kuJ1ygLjoZM2bNR+qMgAnwdQq3bFpOg0io1PW7Gmxhk0SPv/TlZyMSQ3mmv1p96qQgDCxe8Ofr399I9rjuRMyNE3XvoFggzXJytqJHd2nscMmeH2vx6MCCTOdVxN/vbE/JhRn6M9LYBAi+g1Dh69Hr8mptYKdvuYfbjZuinCKXdapowKGbeumyNcw33xIDsIDo/trbSIQVqOIo5NbunXVRlwEV4RC6GN6aWtgiV18vSER2QjSohfc+65XjPZSghnDr8D0S9JmD5CPiUflZWoQRSXr854z3/mLzObb0cZ3WHMpX
X-Forefront-PRVS: 0126A32F74
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(7916002)(377454003)(199003)(189002)(24454002)(86362001)(33656002)(57306001)(46406003)(97756001)(36756003)(47776003)(77096005)(5660300001)(92566002)(66066001)(110136003)(8676002)(8746002)(50226002)(81166006)(81156014)(6916009)(6666003)(2950100002)(97736004)(50466002)(189998001)(305945005)(7846002)(7736002)(2906002)(6116002)(4326007)(3846002)(23726003)(68736007)(586003)(106356001)(42186005)(230783001)(105586002)(229853002)(76176999)(50986999)(83716003)(82746002)(101416001)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB2503; H:[172.29.192.68]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CO2PR05MB2503; 23:j+L50K3jrQGYcez371lrX1r0TLn6SdA744IQmdqZE?= =?us-ascii?Q?fbSvu+llsj77SDGVKfeiREm7XOzySL7rggmLv2siQQf9YPbXG6NhHfHVLXXd?= =?us-ascii?Q?R7MpbAQgW6s/LRrRhZEVGUnRc/PmhZZ9lssl500ZIJoW39nZ6Z1mofIB5cLA?= =?us-ascii?Q?Cny1tVzc93hrnqdp/34l6vjc5Np6NWGtltZEukCXY9ZWDnjI3Kc1/aANqtyn?= =?us-ascii?Q?vCAtVfrO/4VbT/ET2ff+TlXciymn7xM6yjg9HQDYWwy1KGPyl9S7JgjNpFqy?= =?us-ascii?Q?U0k9QIy0TGuZdBiX9lCO1NJFoWbbC4mAtmRe0K6Y+XfCCHPiaSdwtrzITWJ6?= =?us-ascii?Q?1IloSWw2kwDMrTrMF30G4ANCwuUON0cJ/g7fO5F34JVpKxF4+S0pMUhsYyfq?= =?us-ascii?Q?bdQx6JQn2WF00+1PgzwEoJcMMKl/D+RUDB/URRgKlPiBLoVNG2RfwbTnjzcw?= =?us-ascii?Q?Y/zzdoYEwYlmireq1ZPb78mRYJIX/RpfetHUBAy/3R2F14H2l/aR5XAb2OIy?= =?us-ascii?Q?8n8Tmi3Xjj+3qDPIwiaApEagTWM7VsUsYez8W3vz34hEOiSvvqX2RdhYoIm8?= =?us-ascii?Q?tJg5bO0gbkCdVWRsuQhE8r/Fytb+4ROcl+J1FT5gOfqHn4rFbjcuMA0K1nXD?= =?us-ascii?Q?Gzum76sNWd26jiBe6Qq1qFn75bzXpB5i9dCk6T9y4P+OHqTeYpxuzZRdd+TP?= =?us-ascii?Q?A8d5Gkdtyt2io8WNI0tKW1hjm9vcei3bu8Nl1uhyDQxIl3UM85mNgzPEtk7m?= =?us-ascii?Q?thtFvPqEuKzyyW3gvD1coNxMt8JN15aqbjpDq4y9WGXEgjIPrmmoYkCAlwNy?= =?us-ascii?Q?eMMl+pjqV3p3juDaZEUa0HFF0Jyi45GRQWWChjXp6lbZd+KJSPnjh65lhfKr?= =?us-ascii?Q?i+C2b921Y6zcTxB2oq+JEUCXw0CQr1nY2xoD4eXUvhzvhQVbsmgBssOzjrrc?= =?us-ascii?Q?mZfuZSWQTw6njtaeiw4LEGLXUiZz/Z28C5xh0jUKXarUS33mB4yH3avr9rEY?= =?us-ascii?Q?zBKsfdXy/MBZ9+HxHRv0mOnZdzuNfP19+eg1EkboFdpM82tkqx7cDJECvZNM?= =?us-ascii?Q?l+RO81gYz9Fle5eycIyWp70HYaupMQd6EXHshL/iJdcP3UmRVxZN/XiDQyEZ?= =?us-ascii?Q?BWqVdTnJz4Tprvmm79irDqUBCsNRIJnbyjj0cIBhzPiTjb4tRkKVPon3wyKd?= =?us-ascii?Q?VmeX+HBLXVmpe3zYv0Rh/A70M0iYaGHo+2ngvVLWcg4Sq4vfdiK13TD7ddPB?= =?us-ascii?Q?1PO8cPHynVhv7cKlp8=3D?=
X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2503; 6:XEqFUjz8n9WCsL3CCskVVvy9mxkAfKycn59i6shIJ+CxPgqiJZ3LM5UtY2dM2lw9ptBLMl4rp4aipRdgHxqXPodjywP7LlbJ4zVqyDlTo2GE7FykbEvXC6vEbGy4yFQPqyRm2SPVPq7EjShkaTn002uncWS9OB8Lp4e25XkLWWNdZAZk9g2nOldyqzEUWU2ORjTTSNxKvmcz3q9CjNCSdG/4hjRvZlhvhr3xjy78x3dM/wNKY0zvb0k8OlU4nZbhPp3YrLGUozYnE0UhFpv5Ib/iuDTvTddU4XuE0LbWLPSPFG3uWCGKjuCDGyWHKEsD51cATWMmUV/rkM2aA5ahXXsoS2EDCNMBO2pJHY13f6x4IeUQ928tWv+wYzk7hzAV; 5:CuQHFgTV3DMlDzciih1cn7Es72hCaJvXXOv2htornYN0NBsnpQzkL1Ov7JKcbVoaglWYCzdjhvLBJH0zpKYDjExsivnI/i2s8MNcZzUCQfiSNqwc1spUp5w1hK+J01zH3nea4Lgh0moNkr0MH21JMA==; 24:vZ/QebgH0tPdBGR5PUgvWC5Dr7NXsE3hSuZiaMcTuHhAF92mHezLmh+Ukp1NM5HA2kCR096KL/GkbnmTtrSOdmzztI24QKPE5je5cOsPmLU=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2503; 7:RlpS+t5KYkI+iq4PoVnEhEu7jBsvx5qSDWD/Q/VNxkRFBxCmaJBJCE0ynNm6IlkP+VzoCyi0hiuwMrB+DqvhQ/okac2L8a9QZ+XcyRhu8jHB5MBCVnuVWAahc+YY2RJQDUxTUhVfrNX1LMvmDLw5zSR5k4LysYGa2B4DWZtAcea/vTAGHYBv21F0FkEY7k75melofRmjbZ+ibKAHUMF/dHmLeA5+dzaqJk26OW9W5aEDTTpf+kWQ/gPFNFrOJp37B5v8QvkrVnWOIV1gabc2ODcqyRh6TgAEZpKmwsstR2FdiSPTOiRmX8B/UYJGaiwpOah2Az8+nBlwwtgF+nqdhqhH4Ne3EcyGRIc3zkqqjZM=
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Nov 2016 12:23:04.5146 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB2503
Archived-At: 
Cc: idr@ietf.org
Subject: Re: [Idr] One week extension to WGLC for draft-ietf-idr-large-community
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, 14 Nov 2016 12:23:22 -0000

Writing solely in my role as a WG contributor:

On Nov 14, 2016, at 6:23 PM, Peter Hessler  wrote:
>=20
> :2. Duplicate values. -03 used SHOULD:
> :
> :   Duplicate BGP Large Community values SHOULD NOT be transmitted.  A
> :   receiving speaker SHOULD silently remove duplicate BGP Large
> :   Community values from a BGP Large Community attribute.
> :
> :-08 uses MUST:
> :
> :   Duplicate BGP Large Community values MUST NOT be transmitted.  A
> :   receiving speaker MUST silently remove duplicate BGP Large
> :   Community values from a BGP Large Community attribute.
> :
> :This is a new change made at the suggestion of the Document Shepherd =
(that is, me). If anyone has an objection, please raise it.
> :
>=20
> I object.
>=20
> RFC 1997 and 4360 communities have no such restrictions. =20

I assume you're not talking about the deduplication requirement itself, =
since that already was discussed and went through WGLC. I'm reading your =
"such restrictions" as relating specifically to the change from the =
less-restrictive SHOULD to the more-restrictive MUST, and that's what =
I'm addressing here.

> Why should
> Large have them?

For clarity. RFC 1997 doesn't even have RFC 2119 keywords (of course). =
That doesn't justify omitting them from Large. Similar principle =
applies.

> I would prefer leaving them as SHOULD NOT, or dropping that paragraph.

In writing and reviewing documents, when I see a "SHOULD NOT" I =
generally try to ask the question implied by its RFC 2119 definition:

4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
   there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label.

So, if the authors choose SHOULD NOT, it means they (or the WG =
consensus) believe "valid reasons in particular circumstances when the =
particular behavior is acceptable or even useful".

In thinking about this one, I haven't come up with a plausible, =
non-contrived reason or circumstance when duplicate large communities =
would be useful. This is especially true since even if one came up with =
some clever hack that involved sending dups, one couldn't count on them =
being received (since most implementations could be assumed to follow =
the "silently remove" clause) and certainly couldn't count on them being =
propagated. That being the case, RFC 2119 suggests MUST NOT is =
appropriate. This makes the spec easier to implement -- if an =
implementor sees MUST NOT, the document isn't asking them to pause and =
consider their options. If they see SHOULD NOT, the document is subtly =
(or not so subtly) implying that they'd better stop and think about the =
consequences of following, or not following, the relevant clause.=20

I'll also point out that the text (whether with SHOULD NOT or MUST NOT) =
embodies Postel's law.

I will concede up front that narrowly-construed, transmission or =
propagation of duplicate large community values is "acceptable" insofar =
as it would be unlikely to cause any serious harm. However, I'll be =
interested to hear if you have in mind a "valid reason in particular =
circumstances when [this] behavior is ... useful". Because if there's no =
reasonable expectation it would ever be useful, I see no reason to make =
the spec even marginally more complex to accommodate it.

I don't see a downside to making the change (well, obviously, or I =
wouldn't have suggested it) and I do see an upside, namely that it makes =
the spec easier to implement.=20

Regards,

--John=


From nobody Mon Nov 14 05:48:06 2016
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 CFB5C1296F6; Mon, 14 Nov 2016 05:48:03 -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.37.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <147913128384.903.5840562891454389181.idtracker@ietfa.amsl.com>
Date: Mon, 14 Nov 2016 05:48:03 -0800
Archived-At: 
Cc: idr@ietf.org
Subject: [Idr] I-D Action: draft-ietf-idr-rtc-no-rt-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: Mon, 14 Nov 2016 13:48: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           : Route Target Constrained Distribution of Routes with no Route Targets
        Authors         : Eric C. Rosen
                          Keyur Patel
                          Jeffrey Haas
                          Robert Raszuk
	Filename        : draft-ietf-idr-rtc-no-rt-06.txt
	Pages           : 7
	Date            : 2016-11-14

Abstract:
   There are a variety of BGP-enabled services in which the originator
   of a BGP route may attach one or more "Route Targets" to the route.
   By means of a procedure known as "RT Constrained Distribution" (RTC),
   a given BGP speaker (call it "B") can announce the set of RTs in
   which it has interest.  The implication is that if a particular route
   (call it "R") carries any RTs at all, BGP speaker B wants to receive
   route R if and only if B has announced interest in one of the RTs
   carried by R.  However, if route R does not carry any RTs at all,
   prior specifications do not make it clear whether B's use of RTC
   implies that it does not want to receive route R.  This has caused
   interoperability problems in the field, as some implementations of
   RTC do not allow B to receive R, but some services presuppose that B
   will receive R.  This document updates RFC 4684 by clarifying the
   effect of the RTC mechanism on routes that do not have any RTs.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-idr-rtc-no-rt/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-idr-rtc-no-rt-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-rtc-no-rt-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 Nov 14 06:12:31 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0602D1293EC for ; Mon, 14 Nov 2016 06:12:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.397
X-Spam-Level: 
X-Spam-Status: No, score=-8.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, 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 g4-5o9KIpVbD for ; Mon, 14 Nov 2016 06:12:28 -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 D580312711D for ; Mon, 14 Nov 2016 06:12:28 -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 1c6Hzn-0005p7-5X for idr@ietf.org; Mon, 14 Nov 2016 14:12:27 +0000
Resent-Message-Id: 
Resent-From: Randy Bush 
Resent-Date: Mon, 14 Nov 2016 23:12:24 +0900
Resent-To: idr@ietf.org
Received: from psg.com ([2001:418:1::62]) by ran.psg.com with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1c69sa-0003zG-ON for randy@ran.psg.com; Mon, 14 Nov 2016 05:32:28 +0000
Received: from mail.ietf.org ([4.31.198.44]) by psg.com with esmtps (TLSv1.2:AECDH-AES256-SHA:256) (Exim 4.87 (FreeBSD)) (envelope-from ) id 1c69sa-0007UJ-30 for randy@psg.com; Mon, 14 Nov 2016 05:32:28 +0000
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D936612969F; Sun, 13 Nov 2016 21:32:27 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: "Eugene Bogomazov" , "Kotikalapudi Sriram" , "Keyur Patel" , "Alexander Azimov" , "Randy Bush" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.37.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <147910154788.10388.9578791609428008498.idtracker@ietfa.amsl.com>
Date: Sun, 13 Nov 2016 21:32:27 -0800
Archived-At: 
Subject: [Idr] New Version Notification for draft-ymbk-idr-bgp-open-policy-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: Mon, 14 Nov 2016 14:12:30 -0000

A new version of I-D, draft-ymbk-idr-bgp-open-policy-02.txt
has been successfully submitted by Randy Bush and posted to the
IETF repository.

Name:		draft-ymbk-idr-bgp-open-policy
Revision:	02
Title:		Route Leak Detection and Filtering using Roles in Update and Open messages
Document date:	2016-11-14
Group:		Individual Submission
Pages:		11
URL:            https://www.ietf.org/internet-drafts/draft-ymbk-idr-bgp-open-policy-02.txt
Status:         https://datatracker.ietf.org/doc/draft-ymbk-idr-bgp-open-policy/
Htmlized:       https://tools.ietf.org/html/draft-ymbk-idr-bgp-open-policy-02
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ymbk-idr-bgp-open-policy-02

Abstract:
   Route Leaks are the propagation of BGP prefixes which violate
   assumptions of BGP topology relationships; e.g. passing a route
   learned from one peer to another peer or to a transit provider,
   passing a route learned from one transit provider to another transit
   provider or to a peer.  Today, approaches to leak prevention rely on
   marking routes according to operator configuration options without
   any check that the configuration corresponds to that of the BGP
   neighbor, or enforcement that the two BGP speakers agree on the
   relationship.  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 a eOTC and iOTC
   attributes according to agreed relationship allowing prevention and
   detection of route leaks.


                                                                                  


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


From nobody Mon Nov 14 06:12:36 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1AE4129453 for ; Mon, 14 Nov 2016 06:12:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.397
X-Spam-Level: 
X-Spam-Status: No, score=-8.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, 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 b8Oek3FF6CFA for ; Mon, 14 Nov 2016 06:12:31 -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 69B521293EC for ; Mon, 14 Nov 2016 06:12:31 -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 1c6Hzq-0005pB-83 for idr@ietf.org; Mon, 14 Nov 2016 14:12:30 +0000
Resent-Message-Id: 
Resent-From: Randy Bush 
Resent-Date: Mon, 14 Nov 2016 23:12:28 +0900
Resent-To: idr@ietf.org
Received: from psg.com ([2001:418:1::62]) by ran.psg.com with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1c69su-0003zQ-3U for randy@ran.psg.com; Mon, 14 Nov 2016 05:32:48 +0000
Received: from mail.ietf.org ([4.31.198.44]) by psg.com with esmtps (TLSv1.2:AECDH-AES256-SHA:256) (Exim 4.87 (FreeBSD)) (envelope-from ) id 1c69st-0007V3-90 for randy@psg.com; Mon, 14 Nov 2016 05:32:47 +0000
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B3F251296BA; Sun, 13 Nov 2016 21:32:46 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: "Eugene Bogomazov" , "Kotikalapudi Sriram" , "Keyur Patel" , "Alexander Azimov" , "Randy Bush" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.37.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <147910156673.10437.7728173017077767030.idtracker@ietfa.amsl.com>
Date: Sun, 13 Nov 2016 21:32:46 -0800
Archived-At: 
Subject: [Idr] New Version Notification for draft-ymbk-idr-isp-border-00.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, 14 Nov 2016 14:12:33 -0000

A new version of I-D, draft-ymbk-idr-isp-border-00.txt
has been successfully submitted by Randy Bush and posted to the
IETF repository.

Name:		draft-ymbk-idr-isp-border
Revision:	00
Title:		New definition of ISP internal eBGP border using BGP Roles
Document date:	2016-11-14
Group:		Individual Submission
Pages:		4
URL:            https://www.ietf.org/internet-drafts/draft-ymbk-idr-isp-border-00.txt
Status:         https://datatracker.ietf.org/doc/draft-ymbk-idr-isp-border/
Htmlized:       https://tools.ietf.org/html/draft-ymbk-idr-isp-border-00


Abstract:
   This document proposes a new definition of ISP borders using BGP
   Roles.  It may be used to improve the BGP best path selection
   algorithm for better support of hot-potato routing between different
   internal ASNs of an ISP.  It may also be used to enable transmission
   of local attributes between different internal ASNs of an ISP.


                                                                                  


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


From nobody Mon Nov 14 06:46:51 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 399AF12957B; Mon, 14 Nov 2016 06:46:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.398
X-Spam-Level: 
X-Spam-Status: No, score=-103.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 SayzopzARMSq; Mon, 14 Nov 2016 06:46:48 -0800 (PST)
Received: from mail.tcb.net (mail.tcb.net [64.78.239.75]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B07C212950B; Mon, 14 Nov 2016 06:46:47 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.tcb.net (Postfix) with ESMTP id 2E392BD; Mon, 14 Nov 2016 07:46:47 -0700 (MST)
X-Virus-Scanned: Debian amavisd-new at mailnew.seatmates.net
Received: from mail.tcb.net ([127.0.0.1]) by localhost (mail.chasingbugles.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zb2rw9EOBh5J; Mon, 14 Nov 2016 07:46:45 -0700 (MST)
Received: from mail.tcb.net (localhost [127.0.0.1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.tcb.net (Postfix) with ESMTPSA id 3C516BB; Mon, 14 Nov 2016 07:46:45 -0700 (MST)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Date: Mon, 14 Nov 2016 09:46:45 -0500
From: Danny McPherson 
To: idr@ietf.org, rtg-dir@ietf.org
Message-ID: <1d8e529a370f4c98b599b48eee7e82ed@tcb.net>
X-Sender: danny@tcb.net
User-Agent: Roundcube Webmail/0.9.5
Archived-At: 
Subject: [Idr] RTG-DIR REVIEW: draft-ietf-idr-large-community-08
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, 14 Nov 2016 14:46:50 -0000

RTG-DIR REVIEW: draft-ietf-idr-large-community-08


Hello,

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 (as is the case here). The purpose of the 
review is to provide assistance to the Routing ADs. For more information 
about the Routing Directorate, please see 
http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it 
would be helpful if you could consider them along with any other IETF 
Last Call comments that you receive, and strive to resolve them through 
discussion or by updating the draft.



Document: draft-ietf-idr-large-community-08.txt

Reviewer: Danny McPherson

Review Date: November 14, 2016

Intended Status: Standards Track



Summary:

I have no major concerns with the content of this document and believe 
it is ready for publication.  Some minor comments are provided below, 
although only with the intention to inform the authors, WG, and routing 
ADs during their deliberations with regard to the publication of this 
document.




Comments:

I believe the draft is technically sound and addresses an immediate 
operational need in a pragmatic manner.




Major Issues:

I have no “Major†issues with this I-D, I believe it is ready for 
publication as a Standards Track RFC.




Minor Issues:


S.2: Regarding the change in the -08 version to "MUST NOT" in "Duplicate 
BGP Large Community values MUST NOT be transmitted", I agree with John 
Scudder's November 14th email to the IDR WG on this topic, connecting it 
to RFC 2119 definitions and Postel's law.  I believe MUST NOT is a good 
statement, particularly when considering implications of lazy 
implementations doing things such as including duplicates when creating 
aggregates such as outlined in S.3.  Upon further consideration, to 
Peter Hessler's question on the same mailing list thread, perhaps RFC 
1997 and 4360 communities SHOULD have such a restriction - for the sake 
of global routing system hygiene, at least!

S.3: Regarding an aggregate inheriting all the BGP Large Communities 
from all of the aggregated routes, it would seem to me such an 
instruction may result in unintended operational impacts where regional 
or other intra-AS and routing policy functions based on community are 
promoted to the aggregate and trigger undesirable behavior.  Operators 
should certainly be aware of the potential implications of this in their 
operational environments.


S.7: I believe the reference to S.11 of RFC 7454 is appropriate, 
although upon rereading I am not sure I agree with the advice of that 
BCP.  Specifically, suggesting that communities not be scrubbed on 
ingress (other than to enforce "high order bit" feasibility) leads to 
more unique path attributes that result in systemic effects (e.g., less 
efficient update packing, more memory consumption and unnecessary global 
routing system state, path churn resulting from community changes, 
etc..).  Of course, that's well outside the scope of this document but 
this will certainly have implications related to those practices, as 
well as the default "scrubbing" practices by many operators.


S.8: The editors call for the RFC Editor to remove section 8 
"Implementation Status" before publication.  I believe there is value in 
keeping this section in the document in order to memorialize the current 
implementation and operational status of the proposal, unless the 
intention is to create an external "Implementation Report" associated 
with Large Communities now or at a later time when progression along the 
Standards Track is desired.

S.11: That's a solid list of acknowledgements there, it may be simpler 
to list who didn't contribute :-)


Nits:

None.


From nobody Mon Nov 14 07:18:37 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B943C12971E for ; Mon, 14 Nov 2016 07:18:36 -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, 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 0GrvIXcmznPo for ; Mon, 14 Nov 2016 07:18:35 -0800 (PST)
Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02D5612945F for ; Mon, 14 Nov 2016 07:18:35 -0800 (PST)
Received: by mail-pf0-x234.google.com with SMTP id i88so30061044pfk.2 for ; Mon, 14 Nov 2016 07:18:34 -0800 (PST)
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=e3cCQ7Hr2GCEP2xRzzEWgeZADzhQCzKfumEobXHNnyM=; b=BDTnlowmyVubeEyKtWJIUXSqc66jDF0Joy0IOMz0y6qtYEIVB0FRBDgZK8qCwLpvOR x7PtDxiyPqrsIJw1FqzHPgEtqFTK5O+KNT6RLUWKXiYiU7/ZSyIOdd91kdLjHfBpGfaC iCLhu/KCSX2brlGWwQ8q4nw/XmQ7013NdIhJwRXe3GaJJERyrPmXAXdMlOTAEQL5dYqX Tt3g8zo64onZ/tdLL93Q6rdq4CxO0U9wGW20jj3QLtlh/Bidik2poVUFyNt5GQhAJpZy eXFoIGPe+sjHQ7GtP7M9DxASLIS9719g6myOHFI5rIQ+zJ3aUj4PoWElRkXmQAlt/Kv8 BI6Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=e3cCQ7Hr2GCEP2xRzzEWgeZADzhQCzKfumEobXHNnyM=; b=DoQPG9kZKq4YF2iNKCUdYhZbmXG6/0tam/AlVAqGcKh4ScAVJD6EOk7wPLJxe+Ei6G xIlC1NZGSTNdVs/BQZ4tDPz5RKhBmEmPaJEOOIoECjLNWOaCzeC9sNIB7N+Tot8Ooekh KYFJlP4axJvO+yoA+0YDjzrt+nRAyGGAZAuSCMtxjxXQcTl6dqb8g+N84Xx1t/CI6Wu8 In1/bhUjtT4AHQyV2C5woTBOjJqvBJKdrVjAQQdViGONZfrD3bHEBJY8ZCiGLX6RaCdz IZfn3qLss8rcID7gTsmJtiVx5A5G1fXhkp8hFKXl04hMOeuvMVA77RMY2y9GgrsG6wqr tLSw==
X-Gm-Message-State: ABUngvfY51/lbVrq32L7mE/7BVNqEEnhdg1FeEaym3fJRuhF+NTlnvpDjeyFZbUob0N+Rg==
X-Received: by 10.98.74.18 with SMTP id x18mr36870085pfa.58.1479136714391; Mon, 14 Nov 2016 07:18:34 -0800 (PST)
Received: from localhost ([2001:67c:370:144:61f5:85e9:4f01:aa8c]) by smtp.gmail.com with ESMTPSA id d15sm36053608pfl.46.2016.11.14.07.18.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 14 Nov 2016 07:18:33 -0800 (PST)
Date: Tue, 15 Nov 2016 00:18:29 +0900
From: Job Snijders 
To: Danny McPherson 
Message-ID: <20161114151829.GC67788@dhcp-9341.meeting.ietf.org>
References: <1d8e529a370f4c98b599b48eee7e82ed@tcb.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1d8e529a370f4c98b599b48eee7e82ed@tcb.net>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.7.1 (2016-10-04)
Archived-At: 
Cc: idr@ietf.org, rtg-dir@ietf.org
Subject: Re: [Idr] RTG-DIR REVIEW: draft-ietf-idr-large-community-08
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, 14 Nov 2016 15:18:36 -0000

Dear Danny,

(snipped some text)

On Mon, Nov 14, 2016 at 09:46:45AM -0500, Danny McPherson wrote:
> RTG-DIR REVIEW: draft-ietf-idr-large-community-08
> Document: draft-ietf-idr-large-community-08.txt
> Reviewer: Danny McPherson
> Review Date: November 14, 2016
> Intended Status: Standards Track
> 
> Summary:
> 
> I have no major concerns with the content of this document and believe
> it is ready for publication.
> 
> Minor Issues:
> 
> S.2: Regarding the change in the -08 version to "MUST NOT" in
> "Duplicate BGP Large Community values MUST NOT be transmitted", I
> agree with John Scudder's November 14th email to the IDR WG on this
> topic, connecting it to RFC 2119 definitions and Postel's law.  I
> believe MUST NOT is a good statement, particularly when considering
> implications of lazy implementations doing things such as including
> duplicates when creating aggregates such as outlined in S.3.  Upon
> further consideration, to Peter Hessler's question on the same mailing
> list thread, perhaps RFC 1997 and 4360 communities SHOULD have such a
> restriction - for the sake of global routing system hygiene, at least!

I agree rationale. I wish I had learned earlier on in this process more
about some of the nuances between MUST and SHOULD.

To put this in different words: if the paragraphs remains as it was
(like in -07) with the words "SHOULD", implicitly we acknowledge that
there _might_ be a semantic meaning in signalling duplicate communities.

For instance, if community "1:2:3" means "prepend at location X", I'd
never want an abomination implementation to exist in this multiverse
where it would be legal routing policy construct to match "if community
1:2:3 is present _twice_ in the attribute, prepend twice".

By changing the wording to MUST, it becomes clear that the presence of
duplicate Large Community has no intrinsic meaning, and is just the
artifact of a software bug on the sending side. This was the WGs
intention all along because that is how we understand and treat RFC1997
comms too.

The s/SHOULD/MUST/ change does not trigger any software updates for any
of the currently known implementations. However it does (or should) put
Q&A people on higher alert.

> S.8: The editors call for the RFC Editor to remove section 8
> "Implementation Status" before publication.  I believe there is value
> in keeping this section in the document in order to memorialize the
> current implementation and operational status of the proposal, unless
> the intention is to create an external "Implementation Report"
> associated with Large Communities now or at a later time when
> progression along the Standards Track is desired.

I'd rather scrub the document clean before publishing, and in doing so
avoid creating any suggestion for the future readers, years from now,
that the implementation is limited to a subset of software.

Over time, software may start to support large communities or drop
support for large communities.

A more lively overview of implementations is available here:
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-large-community%20implementations
(inside ietf scope) and here http://largebgpcommunities.net/implementations/
(maintained outside ietf scope)

> S.11: That's a solid list of acknowledgements there, it may be simpler
> to list who didn't contribute :-)

Attestation and acknowledgement are important.

Kind regards,

Job


From nobody Mon Nov 14 08:18:03 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EA97129879 for ; Mon, 14 Nov 2016 08:18:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.398
X-Spam-Level: 
X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497, SPF_HELO_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 o7cpVq21D9GR for ; Mon, 14 Nov 2016 08:18:01 -0800 (PST)
Received: from gir.theapt.org (gir.theapt.org [81.209.183.113]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E56DC12940B for ; Mon, 14 Nov 2016 08:18:00 -0800 (PST)
Received: from gir.theapt.org (unknown [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/0 bits)) (Client did not present a certificate) (Authenticated sender: phessler) by gir.theapt.org (Postfix) with ESMTPSA id 994F07892C for ; Mon, 14 Nov 2016 17:17:59 +0100 (CET)
Date: Mon, 14 Nov 2016 17:17:58 +0100
From: Peter Hessler 
To: idr@ietf.org
Message-ID: <20161114161757.GJ24817@gir.theapt.org>
References:  <20161114092338.GF24817@gir.theapt.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20161114092338.GF24817@gir.theapt.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: 
Subject: Re: [Idr] One week extension to WGLC for draft-ietf-idr-large-community
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, 14 Nov 2016 16:18:02 -0000

On 2016 Nov 14 (Mon) at 10:23:38 +0100 (+0100), Peter Hessler wrote:
:On 2016 Nov 14 (Mon) at 18:10:59 +0900 (+0900), John G. Scudder wrote:
::2. Duplicate values. -03 used SHOULD:
::
::   Duplicate BGP Large Community values SHOULD NOT be transmitted.  A
::   receiving speaker SHOULD silently remove duplicate BGP Large
::   Community values from a BGP Large Community attribute.
::
::-08 uses MUST:
::
::   Duplicate BGP Large Community values MUST NOT be transmitted.  A
::   receiving speaker MUST silently remove duplicate BGP Large
::   Community values from a BGP Large Community attribute.
::
::This is a new change made at the suggestion of the Document Shepherd (that is, me). If anyone has an objection, please raise it.
::
:
:I object.
:
:RFC 1997 and 4360 communities have no such restrictions.  Why should
:Large have them?
:
:I would prefer leaving them as SHOULD NOT, or dropping that paragraph.
:

After the discussions from John, Danny, and Job; I withdraw my
objection.



-- 
No violence, gentlemen -- no violence, I beg of you! Consider
the furniture!
		-- Sherlock Holmes


From nobody Mon Nov 14 08:18:14 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1845129886 for ; Mon, 14 Nov 2016 08:18:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=steffann.nl
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z_I4Tq6VU-1l for ; Mon, 14 Nov 2016 08:18:12 -0800 (PST)
Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:9e0:803::6]) (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 7883F129884 for ; Mon, 14 Nov 2016 08:18:11 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 7F3AD3A; Mon, 14 Nov 2016 17:18:09 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:message-id:date:date:in-reply-to:from:from :subject:subject:mime-version:content-type:content-type:received :received; s=mail; t=1479140286; bh=bSwzjONE2a5Ivnc8DnAH941zI3XT Sm2tawIVDzpPRCE=; b=mFzvDbI3PX90XC3jy1l80IaCWRyeKWkVhfPjIoeuuOAE mUNzJSG4cdBzUps09Ntt08IWRE20ia7xMApg9H93RGPMnCBs1LNzcW5lMHe4+JIz HCVIwqI6aQ26j42ymfFoYd78weac5D4WV6I/Z0vOykj1D3yK3KlSSR2j9Um+LPQ=
X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl
Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id MRioC7NjxUzm; Mon, 14 Nov 2016 17:18:06 +0100 (CET)
Received: from [IPv6:2a02:a213:a300:9300:e144:6027:b4db:dee1] (unknown [IPv6:2a02:a213:a300:9300:e144:6027:b4db:dee1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.sintact.nl (Postfix) with ESMTPSA id 9576738; Mon, 14 Nov 2016 17:18:06 +0100 (CET)
Content-Type: multipart/signed; boundary="Apple-Mail=_E940C141-6A80-40B4-BFBD-130279633F0C"; protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Clacks-Overhead: GNU Terry Pratchett
From: Sander Steffann 
In-Reply-To: <18460A64-11D9-46A1-9388-5D751648A88C@juniper.net>
Date: Mon, 14 Nov 2016 17:18:05 +0100
Message-Id: <363A2F4B-2FCC-4A99-ABE5-C3AC70223A3B@steffann.nl>
References:  <20161114092338.GF24817@gir.theapt.org> <18460A64-11D9-46A1-9388-5D751648A88C@juniper.net>
To: "John G. Scudder" 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: idr@ietf.org, Peter Hessler 
Subject: Re: [Idr] One week extension to WGLC for draft-ietf-idr-large-community
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, 14 Nov 2016 16:18:13 -0000

--Apple-Mail=_E940C141-6A80-40B4-BFBD-130279633F0C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi John,

> Op 14 nov. 2016, om 13:22 heeft John G. Scudder  het =
volgende geschreven:
>=20
> Writing solely in my role as a WG contributor:
>=20
> On Nov 14, 2016, at 6:23 PM, Peter Hessler  =
wrote:
>>=20
>> :2. Duplicate values. -03 used SHOULD:
>> :
>> :   Duplicate BGP Large Community values SHOULD NOT be transmitted.  =
A
>> :   receiving speaker SHOULD silently remove duplicate BGP Large
>> :   Community values from a BGP Large Community attribute.
>> :
>> :-08 uses MUST:
>> :
>> :   Duplicate BGP Large Community values MUST NOT be transmitted.  A
>> :   receiving speaker MUST silently remove duplicate BGP Large
>> :   Community values from a BGP Large Community attribute.
>> :
>> :This is a new change made at the suggestion of the Document Shepherd =
(that is, me). If anyone has an objection, please raise it.
>> :
>>=20
>> I object.
>>=20
>> RFC 1997 and 4360 communities have no such restrictions.
>=20
> I assume you're not talking about the deduplication requirement =
itself, since that already was discussed and went through WGLC. I'm =
reading your "such restrictions" as relating specifically to the change =
from the less-restrictive SHOULD to the more-restrictive MUST, and =
that's what I'm addressing here.
>=20
>> Why should
>> Large have them?
>=20
> For clarity. RFC 1997 doesn't even have RFC 2119 keywords (of course). =
That doesn't justify omitting them from Large. Similar principle =
applies.
>=20
>> I would prefer leaving them as SHOULD NOT, or dropping that =
paragraph.
>=20
> In writing and reviewing documents, when I see a "SHOULD NOT" I =
generally try to ask the question implied by its RFC 2119 definition:
>=20
> 4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
>   there may exist valid reasons in particular circumstances when the
>   particular behavior is acceptable or even useful, but the full
>   implications should be understood and the case carefully weighed
>   before implementing any behavior described with this label.
>=20
> So, if the authors choose SHOULD NOT, it means they (or the WG =
consensus) believe "valid reasons in particular circumstances when the =
particular behavior is acceptable or even useful".
>=20
> In thinking about this one, I haven't come up with a plausible, =
non-contrived reason or circumstance when duplicate large communities =
would be useful.

Useful: no, but acceptable: maybe, as you write below.

> This is especially true since even if one came up with some clever =
hack that involved sending dups, one couldn't count on them being =
received (since most implementations could be assumed to follow the =
"silently remove" clause) and certainly couldn't count on them being =
propagated. That being the case, RFC 2119 suggests MUST NOT is =
appropriate. This makes the spec easier to implement -- if an =
implementor sees MUST NOT, the document isn't asking them to pause and =
consider their options. If they see SHOULD NOT, the document is subtly =
(or not so subtly) implying that they'd better stop and think about the =
consequences of following, or not following, the relevant clause.

The MUST/MUST NOT wording makes it mandatory for a router to evaluate =
the communities to make sure there are no duplicates. A router that just =
forwards the attribute (it doesn't know about large or it doesn't care) =
might have a reason to not inspect and validate them. It should never =
receive them in the first place of course, but you never know what =
strange stuff you receive :)

Based on this I think SHOULD is better than MUST: it allows routers to =
forward the attribute as received without spending cycles on evaluating =
it if they don't want/need to. It also aligns better with the behaviour =
of routers that don't understand the large attribute at all.

Cheers,
Sander


--Apple-Mail=_E940C141-6A80-40B4-BFBD-130279633F0C
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJYKeO9AAoJEKAtA7D+JBO5RsMH+wUBxYic/YBYK8quDyRpiQPL
ip1ITWtJBPCjaLErmNoUwuJdCYI9THW4JmXy1c5/u9XeyOv7Q7jyyHiZf7qMfyF1
4BDIRNqx9omnVYoaxqhjjeTTX8lwu+UyYfnOdJDrY5Ev/JSQOq/FfU3r+LGohfJp
fCqTUjp/Une0zPO3l4yUCGKkBTXXikiU9+HlQ0fCAR/hUvknzZvW5/JErr6Sfy5U
iXmkV9BOdU+1xZD+HiNMjSu7wQkr2W53prKw1MU6DGC9UL9a+0YeKtHfT0dDs73n
kej0yax+7GjpPM9UFx9vZj0RMLuJPD3PS4zJDFJXQHpl7ce+YMMmPG0sPT11pQA=
=3VG1
-----END PGP SIGNATURE-----

--Apple-Mail=_E940C141-6A80-40B4-BFBD-130279633F0C--


From nobody Mon Nov 14 08:24:21 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D3AE128E19; Mon, 14 Nov 2016 08:24:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level: 
X-Spam-Status: No, score=-4.301 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_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=steffann.nl
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJCGj3jE0ivD; Mon, 14 Nov 2016 08:24:15 -0800 (PST)
Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.6]) (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 38FC0127735; Mon, 14 Nov 2016 08:24:15 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 3EBB53A; Mon, 14 Nov 2016 17:24:13 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:message-id:date:date:in-reply-to:from:from :subject:subject:mime-version:content-type:content-type:received :received; s=mail; t=1479140651; bh=szLWa2cVv8MicYwHr8hMHFdB0tbH 2yQuwyG4rkAVaq8=; b=BX8m3/SM8oA5NEIVV8qzyJFsacROUFTMDB5tJTprnkqC C3ZJqCKXcKBCZQ1FyIKRZaX8jRglL2RkJBtgx8MBjIgONoOhAEqSoal7e5r6z5ou zcdLLdYBEi9SvEr39UZAv0ulkMkMJGCwx9ApvtWV8TN7lxiU96D6RhSHo/LT1d0=
X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl
Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id fppkl_O-IJOw; Mon, 14 Nov 2016 17:24:11 +0100 (CET)
Received: from [IPv6:2a02:a213:a300:9300:e144:6027:b4db:dee1] (unknown [IPv6:2a02:a213:a300:9300:e144:6027:b4db:dee1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.sintact.nl (Postfix) with ESMTPSA id 3463E38; Mon, 14 Nov 2016 17:24:11 +0100 (CET)
Content-Type: multipart/signed; boundary="Apple-Mail=_0D266D3C-1512-4B38-9879-F45D375BAAA1"; protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Clacks-Overhead: GNU Terry Pratchett
From: Sander Steffann 
In-Reply-To: <20161114151829.GC67788@dhcp-9341.meeting.ietf.org>
Date: Mon, 14 Nov 2016 17:24:10 +0100
Message-Id: <9E85C422-42DB-438B-98BC-DB678E403B12@steffann.nl>
References: <1d8e529a370f4c98b599b48eee7e82ed@tcb.net> <20161114151829.GC67788@dhcp-9341.meeting.ietf.org>
To: Job Snijders 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: idr@ietf.org, rtg-dir@ietf.org, Danny McPherson 
Subject: Re: [Idr] RTG-DIR REVIEW: draft-ietf-idr-large-community-08
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, 14 Nov 2016 16:24:16 -0000

--Apple-Mail=_0D266D3C-1512-4B38-9879-F45D375BAAA1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi Job,

Please see my previous email to John about SHOULD/MUST here. With that =
in mind:

> To put this in different words: if the paragraphs remains as it was
> (like in -07) with the words "SHOULD", implicitly we acknowledge that
> there _might_ be a semantic meaning in signalling duplicate =
communities.

I agree that there MUST NOT be semantic meaning in duplicate =
communities. How about:

"""
Duplicate BGP Large Community values SHOULD NOT be transmitted.  A
receiving speaker SHOULD silently remove duplicate BGP Large
Community values from a BGP Large Community attribute. If a community
value is received multiple times this MUST NOT be treated differently
than a community value that is received only once.
"""

as a middle ground?

Cheers,
Sander


--Apple-Mail=_0D266D3C-1512-4B38-9879-F45D375BAAA1
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJYKeUqAAoJEKAtA7D+JBO5yOwH/jywpVZ0sbbn4TmzqLqVCpv9
E2MiuFSBL5ZjI+BC5/Zib3Npaf9hAUw54HMXwk+s5dTDT9HhckYtu64q6/vdfzvl
TTUu15bOAoL1nSqFumaX4oALnjqKb//DhUvhsb9U3MN/JIRT6prxdujF9QswXwe0
HlzthB+BEvMZjX+k71rr1EzxyDj4cDz3Tytz2ah2Xpx/k0bBSitWuo50bN7TFXIc
z1ZAIjfYbq0FQVQObN0YX9z6NzTBi+Clqe8q17F4LjJnT35gjm3X+MWcpjHkW8Xf
YzH0824aTHTvZ7r9V18keISgtPOn9a+Irtep+5+vlL6AmCOHUDei0DrcBnzwRvU=
=bV+d
-----END PGP SIGNATURE-----

--Apple-Mail=_0D266D3C-1512-4B38-9879-F45D375BAAA1--


From nobody Mon Nov 14 08:50:57 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A41FD129482 for ; Mon, 14 Nov 2016 08:50:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5UOk4-sx4LYA for ; Mon, 14 Nov 2016 08:50:44 -0800 (PST)
Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBFD9129408 for ; Mon, 14 Nov 2016 08:50:43 -0800 (PST)
Received: by mail-it0-x22c.google.com with SMTP id q124so129712963itd.1 for ; Mon, 14 Nov 2016 08:50:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=j5gzFoLVeib6vCDsPNmpasJ2ARvzLCclAOzn0ucpVMU=; b=Ci5Ki2ZKkH1wpKsQPUoSgM8T65oBXGt1xo27BD4ItexDvHjkLI5E/gCzbRyo4HNC4V OlKnFwo/11lOHOtbIOEcyscs6G488V0vrHmQW4AuC2ajSW+yhNlq7cOnPfd/zwbHd2lQ +1eL2By2PpzQ9bZtcz1l9TPxKq+oLamF4MWE4fSnWdrHrm8mId/jskD6GC6cjI1Dd+91 gOVG0WS3NolNfmxvtr0Ms1IdGMScIE0I/bq3rH8VoWEZpbNKLi9erd78ow47FJJTQfam VVZvtOavlGSSL9HsoLOxH82Ex7YfoAMy1MFuUXbasQKeu5P6KHFthRRIt5Q/DNT7ysas oz8A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=j5gzFoLVeib6vCDsPNmpasJ2ARvzLCclAOzn0ucpVMU=; b=isJaOufQU7n5+cBq6diaVr+JwC7QKhahG2YJSVJZhyiH9W1sXn/yAhmlO0s8rJyUXu zVIXYcj0deQd3CelqUK6jTbpD39p77NwWnFzrhgsedOmTw6qSy858ejrobz5RFQcdJ0Q /qAeR9mXqxbxDx2d/HLAHsMC08NnlvwRFiF0abowadbgaSaIP9N2grxpYNL987qjAJvK qwe5sKeWtCSm393+nvKXt5W4TKt7X7vhpWsQEyWSAO6NZuHRU62yNhc3MReuCU6BVCeR Bb/zqiwWJUQEG39DWMdSB4tsift5vjyUnD6lMr0aWNn91N2b7QyIfku9dPaoRrZ5WGiL L/aA==
X-Gm-Message-State: ABUngvc3lTW+KAnWJGKMzdURL86IqQ73vleEmde5tszvxL6BxjzqaOb0vg3sr5G4ahAGWTemAHnIckclBUuwnw==
X-Received: by 10.107.33.194 with SMTP id h185mr25060904ioh.18.1479142243141;  Mon, 14 Nov 2016 08:50:43 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.14.208 with HTTP; Mon, 14 Nov 2016 08:50:42 -0800 (PST)
In-Reply-To: 
References: 
From: Adam Chappell 
Date: Mon, 14 Nov 2016 17:50:42 +0100
Message-ID: 
To: "John G. Scudder" 
Content-Type: multipart/alternative; boundary=001a1140ecb0f9c3f5054145a329
Archived-At: 
Cc: IETF IDR WG 
Subject: Re: [Idr] One week extension to WGLC for draft-ietf-idr-large-community
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, 14 Nov 2016 16:50:55 -0000

--001a1140ecb0f9c3f5054145a329
Content-Type: text/plain; charset=UTF-8

Hi John, all.

On 14 November 2016 at 10:10, John G. Scudder  wrote:

> Hi All,
>
> 2. Duplicate values. -03 used SHOULD:
>
>    Duplicate BGP Large Community values SHOULD NOT be transmitted.  A
>    receiving speaker SHOULD silently remove duplicate BGP Large
>    Community values from a BGP Large Community attribute.
>
> -08 uses MUST:
>
>    Duplicate BGP Large Community values MUST NOT be transmitted.  A
>    receiving speaker MUST silently remove duplicate BGP Large
>    Community values from a BGP Large Community attribute.
>
>
Regardless of 2119 language, perhaps it might be more useful to tackle the
duplication issue again on the Postel front, especially because of the
opaque-ness through non-aware implementations which certainly won't weed
out dupes between misbehaving implementations.

I think that we really want an implementation to not send duplicates, but
tolerate receiving them with no ill effect. Certainly not to encourage
dupes to have meaning. But we also want to make it easy to implement
correctly, and hard to mess up.

Maybe it is better to state the idempotence property that we expect (and
that I saw in the other window that Job just outlined) in section 2
explicitly. Eg.

"
This document defines the BGP Large Communities attribute as an
optional transitive path attribute of variable length. A route carrying a
BGP Large Communities attribute is idempotently associated with the
community indicated in the attribute.
"

This together with the clear statement that community ordering is not
significant and that duplicates should not be transmitted offers a broad
hint to a lazy implementor that communities could be stored in a
set/map/hash, rather than a list/array to achieve the right behaviour.

Let's not require a receiver to take any special action in order to
sanitise/cleanse received attributes. At least not more than he would
already need to do for his own operation.

-- Adam.

--001a1140ecb0f9c3f5054145a329
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi John, all.

On 14 November 2016 at 10:1=
0, John G. Scudder <jgs@juniper.net> wrote:
Hi All,


2. Duplicate values. -03 used SHOULD:



=C2=A0 =C2=A0Duplicate BGP Large Community values SHOULD NOT be transmitted=
.=C2=A0 A

=C2=A0 =C2=A0receiving speaker SHOULD silently remove duplicate BGP Large
=C2=A0 =C2=A0Community values from a BGP Large Community attribute.



-08 uses MUST:



=C2=A0 =C2=A0Duplicate BGP Large Community values MUST NOT be transmitted.=
=C2=A0 A

=C2=A0 =C2=A0receiving speaker MUST silently remove duplicate BGP Large

=C2=A0 =C2=A0Community values from a BGP Large Community attribute.



Regardless of 2119 language, per=
haps it might be more useful to tackle the duplication issue again on the P=
ostel front, especially because of the opaque-ness through non-aware implem=
entations which certainly won't weed out dupes between misbehaving impl=
ementations.

I think that we really want an implem=
entation to not send duplicates, but tolerate receiving them with no ill ef=
fect. Certainly not to encourage dupes to have meaning. But we also want to=
 make it easy to implement correctly, and hard to mess up.

Maybe it is better to state the i=
dempotence property that we expect (and that I saw in the other window that=
 Job just outlined) in section 2 explicitly. Eg.

&=
quot;
This document defines the BGP Large Communities attribute a=
s an
optional transitive path attribute of variable length. A=
 route carrying a
BGP Large Communities attribute is idempotently=
 associated with the
community indicated in the attribute.
<=
div>"

This together with the clear statement =
that community ordering is not significant and that duplicates should not b=
e transmitted offers a broad hint to a lazy implementor that communities co=
uld be stored in a set/map/hash, rather than a list/array to achieve the ri=
ght behaviour.

Let's not require a receiver to=
 take any special action in order to sanitise/cleanse received attributes. =
At least not more than he would already need to do for his own operation.

-- Adam.





--001a1140ecb0f9c3f5054145a329--


From nobody Mon Nov 14 08:55:13 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7375129557 for ; Mon, 14 Nov 2016 08:55:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ByyUt-q9EYPL for ; Mon, 14 Nov 2016 08:55:10 -0800 (PST)
Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::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 5EB4E1293F5 for ; Mon, 14 Nov 2016 08:55:10 -0800 (PST)
Received: by mail-it0-x232.google.com with SMTP id q124so114110840itd.1 for ; Mon, 14 Nov 2016 08:55:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KkxUBch0ukz6cbznrL7bdCzxxJ4HRt80AVRg7YkigVg=; b=KY9DjxfpwPialv1VJ4d/E6Iw+kekvvz1Q+SQtwbE7lH61ow44oPa2HrKcUztoaCFxS YssZeEQuGGIs23toHErw4aZuQy1o+fMnAaTG1uRfHtQiVUbHsZ0iMrN81MXppD/Ru8VJ kWt4VfgR4Qb5oEyKVaWHcgjtegCgNIirjnhqT2DpVReGHUmNBERy8WvvjTi+MawvD/Zf ig7Nda3Nou7O9U1eUMOuoxm8N2yn1YlKpj2N73RvE1fwAOP2c38um+DUs4BV2uKw0dDL EGvsx8MxWukssy1/GiYPzl4DBO65ZDYvpwXxcuz4n3NUxCGtofr5l9dFcFU4xcRM6nvf MF8Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KkxUBch0ukz6cbznrL7bdCzxxJ4HRt80AVRg7YkigVg=; b=CQiJbxLaOYv7sFKOzCkfwk55ljvWtuTj1GoxxGDBckvlBq7TUtaleJVwgKqy3b7Lcz caddjNqDYX/BMVhJouCXTxORHaD0yug0lde96cfjOSGFYwMGDbn9Fgoj1tzxAMqYyNkU 8+5R3hzyqNxfUa4eb7FDpYkgkHv+XDxNm/rXAcFg13FT22NdmYFBC9YqLs1LjkZcoDK7 ZuFtrvP/MZXBgTJr+njy7EsEK3Pc/fveEwdb1m+xzbhDNmi4jnfaeEggwuE/EcywveHk WnrRyTfPwWu3KW/zhzpWjibbpbtTLxYfGd9yoTAC68iAN80eHqTGdJtGsoTP3eT715jP jYWg==
X-Gm-Message-State: ABUngvdRD3a1y4rRaGe2GhFQpNThdoE/Ks7kDBLAqxPddzzra6cDMdFy0ftzMjHfnKDMCp2xWCxFmC796KuU3A==
X-Received: by 10.107.134.26 with SMTP id i26mr25728076iod.182.1479142509662;  Mon, 14 Nov 2016 08:55:09 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.14.208 with HTTP; Mon, 14 Nov 2016 08:55:09 -0800 (PST)
In-Reply-To: 
References:  
From: Adam Chappell 
Date: Mon, 14 Nov 2016 17:55:09 +0100
Message-ID: 
To: "John G. Scudder" 
Content-Type: multipart/alternative; boundary=001a113ecf34dc5b53054145b301
Archived-At: 
Cc: IETF IDR WG 
Subject: Re: [Idr] One week extension to WGLC for draft-ietf-idr-large-community
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, 14 Nov 2016 16:55:11 -0000

--001a113ecf34dc5b53054145b301
Content-Type: text/plain; charset=UTF-8

On 14 November 2016 at 17:50, Adam Chappell  wrote:

>
> This together with the clear statement that community ordering is not
> significant and that duplicates should not be transmitted offers a broad
> hint to a lazy implementor that communities could be stored in a
> set/map/hash, rather than a list/array to achieve the right behaviour.
>

Aargh - "duplicates MUST NOT be transmitted" that should have read. Sorry
for the confusion.

-- Adam.

--001a113ecf34dc5b53054145b301
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On 1=
4 November 2016 at 17:50, Adam Chappell <adam.chappell@gmail.com=
> wrote:

This togeth=
er with the clear statement that community ordering is not significant and =
that duplicates should not be transmitted offers a broad hint to a lazy imp=
lementor that communities could be stored in a set/map/hash, rather than a =
list/array to achieve the right behaviour.

Aargh - "duplicates MUST NOT be transmitted" th=
at should have read. Sorry for the confusion.

-- Adam.




--001a113ecf34dc5b53054145b301--


From nobody Mon Nov 14 10:30:16 2016
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 1407812956C; Mon, 14 Nov 2016 10:30:13 -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.37.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <147914821304.1009.5450612503460154021.idtracker@ietfa.amsl.com>
Date: Mon, 14 Nov 2016 10:30:13 -0800
Archived-At: 
Cc: idr@ietf.org
Subject: [Idr] I-D Action: draft-ietf-idr-bgp-ls-segment-routing-ext-00.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, 14 Nov 2016 18:30: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           : BGP Link-State extensions for Segment Routing
        Authors         : Stefano Previdi
                          Peter Psenak
                          Clarence Filsfils
                          Hannes Gredler
                          Mach(Guoyi) Chen
                          Jeff Tantsura
	Filename        : draft-ietf-idr-bgp-ls-segment-routing-ext-00.txt
	Pages           : 35
	Date            : 2016-11-14

Abstract:
   Segment Routing (SR) allows for a flexible definition of end-to-end
   paths within IGP topologies by encoding paths as sequences of
   topological sub-paths, called "segments".  These segments are
   advertised by the link-state routing protocols (IS-IS, OSPF and
   OSPFv3).

   This draft defines extensions to the BGP Link-state address-family in
   order to carry segment information via BGP.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-ext/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-ext-00


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

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


From nobody Mon Nov 14 10:31:25 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C01A612997A; Mon, 14 Nov 2016 10:31:24 -0800 (PST)
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 69xlIiZ8LgCJ; Mon, 14 Nov 2016 10:31:23 -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 1329B129978; Mon, 14 Nov 2016 10:31:23 -0800 (PST)
X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=31.133.152.135; 
From: "Susan Hares" 
To: "'Danny McPherson'" , , 
References: <1d8e529a370f4c98b599b48eee7e82ed@tcb.net>
In-Reply-To: <1d8e529a370f4c98b599b48eee7e82ed@tcb.net>
Date: Mon, 14 Nov 2016 13:28:55 -0500
Message-ID: <016a01d23ea4$f642b050$e2c810f0$@ndzh.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Content-Language: en-us
Thread-Index: AQKoIgr88MYxeznhV/2V127EC8jvmp8tBcVQ
X-Authenticated-User: skh@ndzh.com 
Archived-At: 
Subject: Re: [Idr] [RTG-DIR] RTG-DIR REVIEW: draft-ietf-idr-large-community-08
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, 14 Nov 2016 18:31:25 -0000

Danny:

Thank you for reviewing this document carefully!

Sue=20

-----Original Message-----
From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Danny =
McPherson
Sent: Monday, November 14, 2016 9:47 AM
To: idr@ietf.org; rtg-dir@ietf.org
Subject: [RTG-DIR] RTG-DIR REVIEW: draft-ietf-idr-large-community-08



RTG-DIR REVIEW: draft-ietf-idr-large-community-08


Hello,

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 (as is the case here). The purpose of the =
review is to provide assistance to the Routing ADs. For more information =
about the Routing Directorate, please see =
http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it =
would be helpful if you could consider them along with any other IETF =
Last Call comments that you receive, and strive to resolve them through =
discussion or by updating the draft.



Document: draft-ietf-idr-large-community-08.txt

Reviewer: Danny McPherson

Review Date: November 14, 2016

Intended Status: Standards Track



Summary:

I have no major concerns with the content of this document and believe =
it is ready for publication.  Some minor comments are provided below, =
although only with the intention to inform the authors, WG, and routing =
ADs during their deliberations with regard to the publication of this =
document.




Comments:

I believe the draft is technically sound and addresses an immediate =
operational need in a pragmatic manner.




Major Issues:

I have no =E2=80=9CMajor=E2=80=9D issues with this I-D, I believe it is =
ready for=20
publication as a Standards Track RFC.




Minor Issues:


S.2: Regarding the change in the -08 version to "MUST NOT" in "Duplicate =

BGP Large Community values MUST NOT be transmitted", I agree with John=20
Scudder's November 14th email to the IDR WG on this topic, connecting it =

to RFC 2119 definitions and Postel's law.  I believe MUST NOT is a good=20
statement, particularly when considering implications of lazy=20
implementations doing things such as including duplicates when creating=20
aggregates such as outlined in S.3.  Upon further consideration, to=20
Peter Hessler's question on the same mailing list thread, perhaps RFC=20
1997 and 4360 communities SHOULD have such a restriction - for the sake=20
of global routing system hygiene, at least!

S.3: Regarding an aggregate inheriting all the BGP Large Communities=20
from all of the aggregated routes, it would seem to me such an=20
instruction may result in unintended operational impacts where regional=20
or other intra-AS and routing policy functions based on community are=20
promoted to the aggregate and trigger undesirable behavior.  Operators=20
should certainly be aware of the potential implications of this in their =

operational environments.


S.7: I believe the reference to S.11 of RFC 7454 is appropriate,=20
although upon rereading I am not sure I agree with the advice of that=20
BCP.  Specifically, suggesting that communities not be scrubbed on=20
ingress (other than to enforce "high order bit" feasibility) leads to=20
more unique path attributes that result in systemic effects (e.g., less=20
efficient update packing, more memory consumption and unnecessary global =

routing system state, path churn resulting from community changes,=20
etc..).  Of course, that's well outside the scope of this document but=20
this will certainly have implications related to those practices, as=20
well as the default "scrubbing" practices by many operators.


S.8: The editors call for the RFC Editor to remove section 8=20
"Implementation Status" before publication.  I believe there is value in =

keeping this section in the document in order to memorialize the current =

implementation and operational status of the proposal, unless the=20
intention is to create an external "Implementation Report" associated=20
with Large Communities now or at a later time when progression along the =

Standards Track is desired.

S.11: That's a solid list of acknowledgements there, it may be simpler=20
to list who didn't contribute :-)


Nits:

None.



From nobody Mon Nov 14 10:42:31 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE3E12997A for ; Mon, 14 Nov 2016 10:42:29 -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, 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] 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 HpmxeONYwJm8 for ; Mon, 14 Nov 2016 10:42:27 -0800 (PST)
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0097.outbound.protection.outlook.com [104.47.42.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 71B1712997B for ; Mon, 14 Nov 2016 10:42:27 -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=TSf0A9BLF5l5Z9ZImAANphPiGqWpveznU4U7G2AlmBk=; b=KclWmxOnLBXLZwd+vA48kbX9BL1VGa2WJ8zGbpLxPalwrTHAI61AJ9RVr1on76UXmcajGojVBKXRJcXy3aNFeKLC6Dp/JKdrYeqaVTtqKAqeZ4HRA81K4O45mYZAv6ZFZMo6nO7sCdcwbIgA1vCm1St0utI/h1UDh4P9gRl3y5U=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; 
Received: from [172.29.192.68] (116.197.188.11) by CO2PR05MB2504.namprd05.prod.outlook.com (10.166.95.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.734.2; Mon, 14 Nov 2016 18:42:24 +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: <363A2F4B-2FCC-4A99-ABE5-C3AC70223A3B@steffann.nl>
Date: Tue, 15 Nov 2016 03:42:05 +0900
Content-Transfer-Encoding: quoted-printable
Message-ID: <4788D7D5-31F2-4FA9-A9AF-29D6F33E8FF1@juniper.net>
References:  <20161114092338.GF24817@gir.theapt.org> <18460A64-11D9-46A1-9388-5D751648A88C@juniper.net> <363A2F4B-2FCC-4A99-ABE5-C3AC70223A3B@steffann.nl>
To: Sander Steffann 
X-Mailer: Apple Mail (2.3124)
X-Originating-IP: [116.197.188.11]
X-ClientProxiedBy: HK2PR02CA0056.apcprd02.prod.outlook.com (10.165.70.24) To CO2PR05MB2504.namprd05.prod.outlook.com (10.166.95.150)
X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2504; 2:lDlKF9lkKFogfjH9QkDqMfef8SF8YhB7nTzd2Crit2k3IHGQnEzy2vYdfTibLOnFZn31IGJuPH/0/0LpdhMimWNWp+2e3eO5AGHupEbOhFO37r27NooXnaJeihklznS2EWxQKUqukrK73n1y3a81VcJXfNwxWaRwxtw1uhtrdXI=; 3:uYr8qPn7HumqW4dXtjcdo9ICJi6F4QiTbx4S9yFva5U8as+nQc0njzxY6hVZl3jwXvnTxAOhVYL1U6BXL2l3oeVKx6HbOk1QL3xWR6Lyy1OEsbWCAZ9tDShTChO9HJz4HVQi75cy0UTpW9lZa3yRc7K+GAjPLF/Xou6KTTuETrA=; 25:AG3zbr8xxwnTZtQfiMwANREF2amx1emEmddM+4sfKCDVy37vkHwrdHaoqJE/rK7h6xMYHYQyT2EU4Rz2unfsyBnR8tsvPVk8MISTMwajK8T3pPqEXy/2fkdARKLVpZAGSJQKRR0Zhbo6zx9re2x4nv+LP/0dBAhCIxoaWyaigw2knbULuOAApdKjl6nu2z3dxEwSKfFWlj9QT/dsuR3VpyfpQa2E8s/LWvmzpjzr6I02XXD54u106LALsPnbwOh6tWGh+kYzVLxX1n3CIPCszLtsgFOaYrZhgx7LLVeVGY5bBqkL/kF36KAt3hsoff/o3Crb7c2wOQ5kLV46Fiat5mXN7jAD2v//QrgqeSGEOKjj5npP6iv75bGlCugYM75qUpWMnnQNj9b5Ov6nv9CMyOFiq4SHQuv/Mq71Sz4i8eHM7eGRjQKTzb3uVfqTxd1l
X-MS-Office365-Filtering-Correlation-Id: 07bd1882-5a51-47ab-1791-08d40cbdfad7
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CO2PR05MB2504;
X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2504; 31:kzyqmLQT/05ie18FYjFG50X+CJ+PYNgPye5rhxpJJwhZJq9uEUQZJRIcUzSsk4yYqQ+p9/Lh6QGGiE2W8m82ixtsYIhamr+BYEdb9ReP+0E/81R/k7wDVUDy7q/l8pk6E4NNOkPsgH+MoF1NIGjreLUq0mWshiNHqU6BsaekkKTlQSsnzp1uv39HAp4l/10kLt59V1i5kaeq+Q9okt9d/R/bsdZmMvPhrapbmHJZYt5CpPIqkICes964COemwvZq; 20:4dQcyWzwDbTqXBlI7AL9nDcO124q5YAUxuEsFkNRBatCX5jLWZSjhuCOGcMVODyrzDvf9TENaytAcJje3fTLZzHD66oMca48FFtrwb58LnbkNIyQf9cUbiy8lwk92/s9MfmQNH5u7qS82xb1heBz0zWefsfD9fA/vRPn4RuyYlZqKLIKVOlQ6DU+ouV+31Kl26G4hWWmHVq1v5FaPWhTcyLQI1Ejqywu3yiD7jmTqvytEFaSi5AoaWHGxZGPphGKP3pvnNITCde6iU50kwPq9sPnwIjo9gjllIysYv64a+VSu48p1OpqMQk09Z769ZO8uKqPLd0wSFrLgrh6FRhtxdl8xrQ6NGf2XvIcvnm0/6nDD5+S1atQQk2GZZTGAfNwkytotKDxM/kzmybDkj+6Tnlg8ppciacewGb6pC/ONTuIXNfkx0V0i3YF1F8xHUKBCSHe4+pNbOK3YgxoVMk9ARZxoa1RxNkmkg7E3VkCpC3rPnuvsSCpwN0lJ2i7fjmj
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6060326)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6061324); SRVR:CO2PR05MB2504; BCL:0; PCL:0; RULEID:; SRVR:CO2PR05MB2504; 
X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2504; 4:BV0ef541k3RFS2BMg5Gxjv4RbPi61f5gCZs6uPzhOt9f+lsBwt0nWNhcVTq+bcSEi/ZptK41D79IkMR1RHsqaZNfy7HjXePtLsB8VF0hHvrFWNH/hXZBePdlKKMygO35+fTAcbLvV7aZn0Cqtnq4oNgBJyDeKlE4qS6Pv0nU+egFNSEC+LOPlecWLB/ECe9K+uzLmWrcy3xLDzTikqjhoVFwfQ1BVS1DkQWE1hHdYdVfQsrvx3j3hjRr2f8vvuKZyA0M5LT7ea1QdYj41o/C5h5VHhw9oxEYQDBbzLGatXCY2yUZXieTysA4/lW7NbR4rfknl/YMlGGuT1xLEsp/0VZvPf1VeJjkWzP0PisjVo9idSKF3xd+0lpvc2G+kA/jp45KnyJkqkTw/r7JRMOaX8lqw1Ed6EDjqDIzcYxpVRj5xZDmzEghUZSdEXsMn/cZ
X-Forefront-PRVS: 0126A32F74
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(7916002)(199003)(24454002)(377454003)(189002)(6916009)(46406003)(83716003)(3846002)(57306001)(77096005)(305945005)(229853002)(110136003)(97736004)(68736007)(8676002)(4326007)(86362001)(92566002)(82746002)(81156014)(76176999)(5660300001)(8746002)(42186005)(2906002)(97756001)(6666003)(81166006)(36756003)(50986999)(47776003)(2950100002)(101416001)(33656002)(93886004)(106356001)(50226002)(105586002)(50466002)(586003)(6116002)(7846002)(66066001)(230783001)(189998001)(7736002)(23726003)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB2504; H:[172.29.192.68]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CO2PR05MB2504; 23:yUoWneABP0soOeD2aGNp6JniwmvAnMjmHm6ZXGyRF?= =?us-ascii?Q?YsTwR4+zT85QVTKqxfQbVl/qU9kRlh9YNfmkLEuInF8hE5wp05x5q93alxLA?= =?us-ascii?Q?zzLL/TxsimTjamj71irNMkTjrjlpSmrxdtQ/H7Qhft/j0vc6FI1nbHUiiKvx?= =?us-ascii?Q?7d4Q4sspT7AV3j660z5b4EreansdIkUIgjooN2PEBwv/qzDlTGDZr6yEPR8Z?= =?us-ascii?Q?tsvoK0ImZ5C+NxC6bpJjoRIMQz2tLRNR1ecO5lIccxLEPVuP/tO7HVXapuEg?= =?us-ascii?Q?3/RigVv/Br9I4Azi01iDFKBZJIGDRsRJ7ftRouKi0VF6meFddjnmQaAoAMuQ?= =?us-ascii?Q?4EV9PJmErn5vU+QaFmuN5RfOA7wchZCipsZLqirdt932XlyR7FpFXn5onSJz?= =?us-ascii?Q?7QcRfgBn/9P+krV6sSfj3XPPJK1yKHVOIs6TZ0q0Mv33YJ+j6OLxM660t5Ut?= =?us-ascii?Q?sAe1ROWrf+L6jU/e0pS5BW0mEILjCQjEtKglvKpDwdL6NH9u6rEN2boEN2SA?= =?us-ascii?Q?KN1YEnahBi7WKaakYLnjcxRKgJPTKpvaQ++w7OuPB8wCY9S2B6DW+CZdnc1c?= =?us-ascii?Q?fWy0k8yMX2xZewCseyatPn8bM0Uho87nOshAkvF4P9TDzvRBoaAe8rWqKWP6?= =?us-ascii?Q?qMlLnG7JOn5CPqr0tvofIwQab0yXXq64cxrre565mt4YRfyd7Vy6bPoB1gEv?= =?us-ascii?Q?inUJjNdtAc8XLY5y+rm/px3b4SbEViOD3mFCX2jsuQ1QXp15wa9MDoDRxvsw?= =?us-ascii?Q?WMXJV8v2ggKIwtRU3o+h7k40a86YJ9IqlifPqGXI00RibFQf8+e4YshV5vA9?= =?us-ascii?Q?bnrGybgGHNQf6B7HIB3Sd2b2KMjzamSFNbGLUiBmMHzoVw7JKlWZHzJJRUKt?= =?us-ascii?Q?TjvzxLXlSfWpEg+gfwCrCzovPurL+Or56Iav3qzx8d0vHdroeL6IG/OMWTOC?= =?us-ascii?Q?Ch8sfND2QlEWZVaoP+FhH2xzE10P45jMRVsqziI/mzFsyfYy47+ByFTPRRXo?= =?us-ascii?Q?hhMWdbHMn0Ng8WRso+hqruSNmeDIBEE5+nR8efOgibaUjf5UQkXJIdHy8heS?= =?us-ascii?Q?0vpYWsruWxK34prm9ka0oHjy7rwVc13T2BlwyOIobehl6JHuKZCyVXKET9L4?= =?us-ascii?Q?wugG6p9QAMGZvLKcl59yxMs9P/vq/75+Nrn2/dMF6P9ignlAtwCiISs+OqGk?= =?us-ascii?Q?kw1A0K3NdRvDVfNPQ5LjWiSFAhLZzkuFUJEtgIVQ5ZcoBnOoSiK6BSrSxkEK?= =?us-ascii?Q?KHQW2rtnbu9f8OMOHLYBjbjnUALU38maC/e7PY4?=
X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2504; 6:sMxRx1ndyMNBsqXWSbFbTM4gs0jW7jME9vjy0CJnMoXMHu7otUFYTo34xqb1fqB6ojXrvl8iWMyqm37ZykLHSEJ8ob4wVkdN38VINYILx0htoU0udLQxkA9I5n+OgM733+kAkvQvCtiES1d/gqePHMR4p7VjXaAoTKaL5EtcVePVhjVu3KNEQfwK+y+DHfSgzbPiNrgq65mfR2NOXJxK8kJc5mnxAGVRAUbKDDgPwtH9AbGQvIAHJ5PLn6QSObLNrFF8D/fmwa5p/opaXgCSmu3C36MYWYqW0XQxlvkXIfWushYLMi8/z9JhczEG7+NrEdYtvLARIPHosZSJYUX8stSYQNyzs1Tfh1pahCOC0d5ALQYsUL0AJE0qHk7ozDRE; 5:jdCrWoiyrULinWT7p64KCwiN4kAbuivq1ZMJRimSL8DE0Z59eTBOWWmEKeiOyK2YXW/ZXwNwz0N/f2SZJHOL7rq8wznPqKMV2eEyVg6xvpBc3FFFhkFtjnIB1hhpV6OAXWYr9oDlHdOixwmH/3NFww==; 24:6pSMXjMZrsdL1RyP2oq+3PEN5pDqA69Rqr4/fuWr8RUza5+hayWFeiVULqM+G/Pw4RSIhBKP0hByEqdenTdufjVid3h+6ocRD3+suYYBQk0=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2504; 7:TFO+Sdm/fGZ4LzSNo0ENwxFoTv/zDiq1SsGR9Hm5p26mfbi3diiGM9p/S282SgiDGP4HFgDwy48Gbv6akfhUiK/yu8dV0n9VHG3gctMOfJzI6jgz/8xM5/XvZOYjZpuYjcs8w7RoupnF6mAjE2vwZ3oApsxwteuu/AdVKJJyWuew/YRB/zY/NKHaNe37Sw1Wxy9RzcM51VlwT0Rb2pvFM/j/0omopaRHotGOsM6xAUBKHLSrmfg94HOCKFqVvjTe8TAldLYFHqflaHtKa2RsDtEaUb5HM6fYjRX3L3J2JaZ779Pct2niSAD68Bxu5/t7m7vJ0dnSY7g6WoXLnQBov/iudvh1EO/EQdNyJrCBjHI=
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Nov 2016 18:42:24.9003 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB2504
Archived-At: 
Cc: IETF IDR Working Group 
Subject: Re: [Idr] One week extension to WGLC for draft-ietf-idr-large-community
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, 14 Nov 2016 18:42:29 -0000

Remember that the attribute is transitive optional. This means that it's =
completely valid per RFC 4271 S. 5 for a router that doesn't implement =
the spec to receive and transmit the attribute without scrubbing it, no =
matter what instructions we provide in the spec. So --

On Nov 15, 2016, at 1:18 AM, Sander Steffann  wrote:
> The MUST/MUST NOT wording makes it mandatory for a router

Implicitly, a router that implements the large communities spec. It's =
not necessary to call this out explicitly in the large comms spec since =
RFC 4271 covers the case explicitly: "It is not required or expected =
that all BGP implementations support all optional attributes."

> to evaluate the communities to make sure there are no duplicates. A =
router that just forwards the attribute (it doesn't know about large or =
it doesn't care)

The "doesn't care" case implies an implementation that has large comms =
code but is configured to pretend it doesn't; the feature is present but =
disabled. This distinction is admittedly a little unclear in RFC 4271 =
but IMO it's fine for a router to pretend to fall into the "I don't =
support this attribute" case, if for some reason it needs to, as long as =
it behaves consistently according to that pretense. Basically this comes =
down to what "support" means in the sentence I quoted above -- does it =
mean the code is present? Or does it mean the code path is present and =
enabled in configuration? I'm fine with the latter and in my experience =
this is the common interpretation. (I think this nuance is well beyond =
the scope of the present draft to fix, in any case.)

> might have a reason to not inspect and validate them. It should never =
receive them in the first place of course,

On the contrary, it's in the nature of transitive optional attributes =
that it's normal to receive and propagate them.

> but you never know what strange stuff you receive :)
>=20
> Based on this I think SHOULD is better than MUST: it allows routers to =
forward the attribute as received without spending cycles on evaluating =
it if they don't want/need to. It also aligns better with the behaviour =
of routers that don't understand the large attribute at all.

As discussed above, in my opinion MUST is completely consistent with the =
behaviour of routers that don't understand the large attribute at all.

Regards,

--John=


From nobody Mon Nov 14 10:50:18 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E59B129984 for ; Mon, 14 Nov 2016 10:50:16 -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, 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] 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 a5Jo-u0jDPD7 for ; Mon, 14 Nov 2016 10:50:15 -0800 (PST)
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0121.outbound.protection.outlook.com [104.47.37.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 2F104129983 for ; Mon, 14 Nov 2016 10:50:13 -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=LX4VhP7JbCNey9NipouhKjn1DWZg5iPa9sBKLuwHhzo=; b=PCVS9Vp5uL6x1pmqu66VtSVf2vFX8VuR9ccJQSskGB7QmX6s4DgvXSSoXntgX6Tgq4gar+W+2BabWgPfJmS0nkHLO704r03qF+CZhzIuBuBC1C6js2rp9svH8td4k3hnIToguazzGwh1uepElGpV09QqLWpSINTEb9KAYnBE0pc=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; 
Received: from [172.29.192.68] (116.197.188.11) by BN3PR05MB2498.namprd05.prod.outlook.com (10.167.3.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.734.2; Mon, 14 Nov 2016 18:50:10 +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: 
Date: Tue, 15 Nov 2016 03:49:50 +0900
Content-Transfer-Encoding: quoted-printable
Message-ID: 
References: 
To: 
X-Mailer: Apple Mail (2.3124)
X-Originating-IP: [116.197.188.11]
X-ClientProxiedBy: HKXPR02CA0033.apcprd02.prod.outlook.com (10.161.48.18) To BN3PR05MB2498.namprd05.prod.outlook.com (10.167.3.27)
X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2498; 2:ifj25Tn6Mx22aIx0z6Ppk3NdVuTBhaYIIzQ7czbVP77v7DpfDEmrfdT1AdAZUX+xoYfUa+J9M/gu12BQ0ureOCaMJ3gSbgn0Hg4FxqQ7248OLeEMYobvNlND8CT3SbyNkhmMGGn6dFeYIq6tw4xEOEOIlc29KOk0B9GRByZTMSw=; 3:qMEFLYhVIQzHRvxJ7G05un6wByYUWpQvv+QS52FK3RaP+QAGIyinhI8Hk6SB3aMsJ9gOTV5U6Lqc26cByS53/z48iUceBoJRXIMXlcl/SAUTztq4Y9YYkFZ6jJN/gZD+YfJteEuUcH6IRZUuoS5OoUk0RT0cXij+jbNhnfn6ih8=
X-MS-Office365-Filtering-Correlation-Id: 613225b2-776a-4c9a-a63e-08d40cbf1061
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN3PR05MB2498;
X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2498; 25:vy22+qQo4TflZA7pjno6gCz25bbZ3ikvKUb5lvmPjCGsbVJ1hdDuy3VUiUu+m3wD8DNNIVX+Rg/aV/1SUgzLj1bP0X13gWUREvINJhyts7i7WWFaZ2ukFWSyw6wGElZ5xr0prVL/4ns2mslIyzLTVS7K/lhDPJXmTeoU6jk9mVrrTgFUXy8/y7hNbCzuercRjNQZUaWC5BiX12F4Q+4mIQUSK/kFWfhvSctP7mZg98y9PNewR3sfi/Sf+bZSzYu9mqGhgtb4NIJYrQF1hfu7kQqhZujN+P3p2A6jsESd8y6h6lbiT47H3q56LNJ/LRdnehgkxS7IYX9jOQwtgUUN4ijOao7RQGaOGhvSefY5Yl5naXGdKqkTZXU2O6/6uWVUzoGW39OKsFSdDUzmaPbBASHT3c+tu4WPfAQO9p7ZubIzlugEdM3yTwmdTFZ8qtoc6Lnxklq5VGHiCzIje1BC6bMl4nYK6OT9A7g0WPx71yWb5+zpqyY19qhLvMMWSmTBzfUb1mDnxlh0HvT5kKlXX96+GPBm600j47d2XDoV61plXz8ebVDZZBYAHaau/F8m8zKrMMFgj2bvJzIbYJHYAx44SWQwKRcUc8miXyluVaBHy8oxTpfotEHy2DoRumUicuxb7dskKcMGdH9HED+JG6N99zJANk6r+W7xGFljeSZ0a3lr4UTbk+1KRr/cSsGuU4XArbsVpQ2OUevHfmkfEA==
X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2498; 31:xQ3IyD5qpQOCSrnxd+59DXKA3HP+710BKheiZKStd4J5LNBit3g0wdsNVR1SPTyPJeJMeZKqmEWz42wRJd26Fxtot08rX+TNf9VDBu8Jbxy8eqxCmPaUPkxlwfXdx33KmZ+WDdef4ZbOHt3WPgUrC0V7EuqAD/mnY4miDO2zaBes+2dc87o3Ngg1bzxCpEgdXnXzWd1/2d5//m9cMGKY09OTcSQNLQbQqPDxKqp7AHHtBRV8wXKi/9Bh1QofJJNd; 20:9oOqE/ATpOQ+mZKZAVaAM7HPp6jmEQw+vbytc4GTRIpoK1F6UPWT3H8yqwxlv9btM3lys3+Ge6EHk7fetWV6vTNE5J2W7y0VX6TZSi8/uidDsKTSUIdMrvYkRo1O7PTfLvkD/IOSKkp2NRnpzqNdQsDXcXGgIiis+ccu6HAPklJBREqoHqgrt106xdFOFlnInCwJYQ1695TqE66TUddKpBzJLEUvo92j0ODMGZtNBRdKEdRDAWqW9Aj4jrGkVgj3uBnWh0yOTLT1AzmvnE94cYPGvimvrE5/9+dqfnUX8r3hEWmkswnYDUJ4nNa2e7XQIuWkrmSnkYobG7d6v6aZMm26HitMUJl/xzfQda/X+Fnrli0zYawppE4X1Cfjfp26i996GhOqdnRnodsyG2Ztr5S/nRHblsQV37jW0LIUipPDrfOBejKcBWQ7MkfDcDojuagfkorWDV9rY+ckVpcaEwAbpn6WptaKapqjmOfqnnGExO6KNTRl/Fw4TtfjMUz4
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(138986009662008)(100405760836317);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6060326)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6061324); SRVR:BN3PR05MB2498; BCL:0; PCL:0; RULEID:; SRVR:BN3PR05MB2498; 
X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2498; 4:PDvTbVREiHSJp8JXnQQlEDC7Aw5iy5Mzm8+4q8w9iqJwmMLyRdor6AZLim1zQjs0tC+EHHw/JI3+AqeMjg8Rc/SSQWquaSV6wIhBxi9vM8pCMaeGA5OJeLT8kgHerRrTp0ZJxzYBvIxJqbhDxA0dVLbr0qD2rwPcxDVFo8rpOzkuSL0cZ3zITRDTQrcvojoglNZ76GXvwoy4T5ojSO+LvWgu8R6hzvadGVeyf9SXJeQAnggfW1KhPWEotM11w9JsdxT2psryVOXF8zIibf/S4L+BtZR43BshI6GupunfEOWcv4lCDCXPkl3jhzQs5ENP5eIqgFezedv9pLYBEkEpcOSXKjf5EMcwnozT/+FiTXl4PbH8tgVla2CYbXelf+3VY8DkHkf/OXAXuc4QW8K2TO3dGDZkdB7cOHTSQMbiXJz13epLre5q4HX5v9bdlQvfSp7I80fHp+SdVf2+25mY8Po8GIn2zeR7Umz2/pH1RO5didAJKeHa9asmfIMP5lysjaJCZAHRQHcEPsVDPEB+xQ==
X-Forefront-PRVS: 0126A32F74
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(7916002)(199003)(189002)(377454003)(24454002)(5660300001)(83716003)(68736007)(82746002)(2906002)(8746002)(36756003)(81166006)(50226002)(450100001)(81156014)(6916009)(6666003)(57306001)(76176999)(3846002)(6116002)(23726003)(50986999)(47776003)(230783001)(110136003)(2950100002)(66066001)(7736002)(42186005)(8676002)(107886002)(101416001)(7846002)(92566002)(229853002)(305945005)(77096005)(586003)(97756001)(50466002)(46406003)(105586002)(86362001)(189998001)(106356001)(97736004)(33656002)(2351001)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR05MB2498; H:[172.29.192.68]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR05MB2498; 23:2nylNNwvoqkBOU6LP/zVMLub1MDI9NqWmSG2OTDoK?= =?us-ascii?Q?vx+roiCreatlEKGAQKi/LiKz/ybmGWvT4E2sH9yk6ML0I+576Cm5c2ERqTUe?= =?us-ascii?Q?hbh98fbK94dcmHfxcSMNYBUTf5U+bCtJ4Wq6TyW5B//vGSMo2HVPmoDJ30JP?= =?us-ascii?Q?9btFLd2Z44DDuD7/z91naxTCd8XCbmpsiORllTgbVGd2a/FcfPhRNKzofw6y?= =?us-ascii?Q?ipTXfAJ9i4Oc5uKvyAJ99x+q3Vs2jTyF2qURsEWiy+ZIE6ghMb6tfzN1KdHd?= =?us-ascii?Q?EwRbVZc3j7+R8OPZNXD+dT5NzYj0bzulXU3l41WD0GF0adsFPwj3sqliCZrB?= =?us-ascii?Q?Rhyr1r1toP7FYgqCq5GgKjQ7zYEi1YZaEDvraP9ikHRf7tonfizCpFOxnR+m?= =?us-ascii?Q?ZysFFvj8gRc8RUkZUxbGli59afojO6PwxpwrtGPlmQvt/o4RIoki5gEGYfc7?= =?us-ascii?Q?MPW7hmrJuj+xvY2Ms/Txvtjt2JKz/LItKQEFa/rqlYsrfhvmKXxQBRXlwsmF?= =?us-ascii?Q?w4MBF2tt4tOF5O1WUsLpChk7g0xoqpe90Rpugm3Fm9N1AwzU71i21roopU4T?= =?us-ascii?Q?eyM+RlfecslZ7azpYzfBsgtLd08ldnUXinROF3E5Qm9MfYwuZXyifPvjYVW0?= =?us-ascii?Q?PwEF49hANKGsq4Q1cMcET/F6LZaXT1DRddbAt9j/IU/TQu6le1hikYkS/9fI?= =?us-ascii?Q?ZvgjeVKlf7gb6a+dpUQbHrAmeVC3pMyNkKfHZ2nHPzJSuf3lI5tpFF+M/5rj?= =?us-ascii?Q?JT7xdJmo/d/unH+8lky8km425CjWUyesmjrCScbFuUctlnk6CwYNznNdmwTj?= =?us-ascii?Q?tAnknliLnceBqWu88UxjZ+M4Hy+VSKAXfL139jHskf67vPrCwS70pDsZjWsP?= =?us-ascii?Q?yFCEUgfpEh6o0lQ4lrisXU3X2MHjja1umCZEIlkLJBGzn4zn6PY+TcPGn12F?= =?us-ascii?Q?GD+ygEZ3kxqtHm37XSNjBrvE9zi+bETIQXWVvqB/nCald8UH0NOElSgSCPGn?= =?us-ascii?Q?bmzJD6glGkZf3BLm3rrLaxf/UyQybtNh78d6qFtlQnsq0uAoYp7y1RB82qVa?= =?us-ascii?Q?Cj0sxSr2HF9q0cvKfRxoAVq6QN91pBxZiX7zTTxwMM7Cp+HRXK9SUwMmcLOs?= =?us-ascii?Q?hLOSxdHEWbWppjv5U/Nli1Xg+T/G0tCJb30fT3HCYrKTOKrgHRyLhTL057H2?= =?us-ascii?Q?cHLRxCBHOZ3ONg/XyKxK+bNTWnSXziv9uRi0UxWeITphCY/RPQWg+rRhfM5i?= =?us-ascii?Q?iknyTvF6uFZnagAkRIf9RzdOdFaTKo85X/DAaXGPgLgN8UYHGwxgXDKQ06ky?= =?us-ascii?B?QT09?=
X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2498; 6:HSspC5AccXLUUSf9eUqGI/s13X14EJaZXYCOemaY2YjLPTfogG1iPSsWTEdW47OQGRPofMXZTTyA5Oh/euCJzXmZsUYcottAzDEQa0mf91L6NSpopZHiY57xCvjxnMHzGd/7Vo4HSz5xdpAr6etvJykBexYoXjfYspOdQfC01vw5UKN98bJHAougp77k6QZuOas0+VekrGY3j+QiUKYFNSZKIYO/56nPaCXi1upiZg1g3NxQeGcsVxj/ktWvXUFM/x2iJp08QdCHYLr1Jl0Q29eGXt564768tM4c3O15I9lTNh86XypNnFVZ8ExNX6FVIxNmgNiRnEziyWUMzMe730Ff0PflRwJngBqz24NP9uC+qPxBGG+4glUS4h6F3yAr; 5:ik7RCXjNM0YJh1GaGrFMfen1vDjGukxwJnwDfaTRubu0hZDZxFK0zacN6GRjxY9W4cbckMlojDhqw7K9T5iw9tcUHh1Rrh3bfTEC4dY1ljUbrVRAhI9p9s4hqtlK51ATtoAPEg8Pz++N8kRM9kqlEw==; 24:8fOYjLYoVTRUH+CZVF9fGP3PlIUqnev7L/Oj7lIDGk93XoUcHHWO3z/V0ZpPb4tb6VrkwkdWMKbI9cbwtAqL1x0K4JoLJTPoucHWgh8nRDs=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2498; 7:F8ksMIZBDclJtM2kGERqqyVkd6RzvooLRPey7fV11DX1d6eWT7L1ePRkXJePF4v4ZykhbMuBc9+M2jRKfTq3Vmpu3zKYRhzuYpmtQJT31iaCDaGNbl1lfV3FCIaLpbv6hNR2eI7qYdxkAmyM6bqNm1NJuPo4vO/2c74gDD65CwDXo+2AuLMJaA8ItgqR9AinhDucOtqxxNMuj3XqpUuK+KiI8eAOJLDXo7bkrra3ChwtvoJNgLcYvmUYSXt72L4M2gPVDk9d0dP1ctvwrYG+7pXvTdBhYEvefJl9yB3hZLYsNJUUuV16FbYsplH4pb+CnJNU8p9oBQ5qTfFPGqVC+uhrZXKE1aZ2qoG0pMzF2sE=
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Nov 2016 18:50:10.6774 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR05MB2498
Archived-At: 
Subject: Re: [Idr] One week extension to WGLC for draft-ietf-idr-large-community
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, 14 Nov 2016 18:50:16 -0000

In my role as co-chair:

On Nov 14, 2016, at 6:10 PM, John G. Scudder  wrote:
> Please raise any objections by November 21. In this case, silence will =
be taken as consent assuming you've already supported publication.

Given there's debate regarding the SHOULD/MUST change, I think it's not =
appropriate to assume silence gives consent to the change. So, I take =
that back and expect we will judge consensus for this item in the usual =
way. (The same would apply to the canonical representation item if there =
were to be debate about it.)

--John=


From nobody Mon Nov 14 11:24:06 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF8281299B5 for ; Mon, 14 Nov 2016 11:24:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hsM25C8eYDu0 for ; Mon, 14 Nov 2016 11:24:04 -0800 (PST)
Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c: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 E6C621299B1 for ; Mon, 14 Nov 2016 11:24:03 -0800 (PST)
Received: by mail-wm0-x233.google.com with SMTP id a197so117072567wmd.0 for ; Mon, 14 Nov 2016 11:24:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JDYFlJIeF9NVdVyeqLE8pFBI8ke5R8BMWmbSo26y8HU=; b=TOXLEPCJgvVp1RDOqMd+PDmBNVpTR09l4McR632lORuL3+HYfwtZ6pKZfmYkLAs4UU xEVk729pdAqOYzm4WNYBwNugEKNxiLJ/T8YV6I8bgOcYv6BO0Pr+3QfHz9Fqv2t+bWEk HFJfwnXLokJ2KMTW0oSmko0587BshwRJft2MxrRTuxqZBX0W28K9oLCPuECswWpCDEed 8S8wbxshfqpZe77WeY6fq2K6K7T0T3UAYaAwAWg7PsUB8Fbm7S8kIR5ujSfP32FQzW0s l8tVfilKu66xRLBO8EW3Img+rz2r0HXXZJlhNDxwkULZxYSi80rfvgyNCis1KNaGsWep 3VhA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JDYFlJIeF9NVdVyeqLE8pFBI8ke5R8BMWmbSo26y8HU=; b=Mihi4q7etA3JEGzQETmmz5M9CJfkvC9eOs7HLBgurLuCNVAjX4UdqPoJ7AKa/2NTYT F8s36VpAJksQbWKKtx0rCqR+Jpsztf+u0F3zqRlYmdP/vA4GTq+yUlkZ66PSoyfE45nW FYVEwAU3okmxgiOfvGDHPTVARSUNmFab1gnz1erLh6Z+JsykAXBrDd7bYkTRn0KP8+/C UB33dASqThYAnBrtYNJ6sn+YDTu0ACF+KwktH2viivdkGxN5T2U1cHeF4gQRJ1zrpfk3 EuyvKLfgG+xfiErKdmdVmhnD5amSrwqbI6Qre1nXbt2IQ30nNTelmJNUC+CIf7+bOuOX 2ZsA==
X-Gm-Message-State: ABUngvfE8aUa8jhoEn3IIoF55H9lI2FAI5oRIYIoaoVxd1lUR292cea9AHDPLpRTb2nxM4jeaYPH78xXoWbPog==
X-Received: by 10.28.0.210 with SMTP id 201mr11473985wma.49.1479151442396; Mon, 14 Nov 2016 11:24:02 -0800 (PST)
MIME-Version: 1.0
Received: by 10.28.197.132 with HTTP; Mon, 14 Nov 2016 11:24:01 -0800 (PST)
In-Reply-To: 
References:  
From: Brian Dickson 
Date: Mon, 14 Nov 2016 11:24:01 -0800
Message-ID: 
To: "John G. Scudder" 
Content-Type: multipart/alternative; boundary=001a113ca7ac4b0faa054147c8b1
Archived-At: 
Cc: IETF IDR 
Subject: Re: [Idr] One week extension to WGLC for draft-ietf-idr-large-community
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, 14 Nov 2016 19:24:06 -0000

--001a113ca7ac4b0faa054147c8b1
Content-Type: text/plain; charset=UTF-8

On Mon, Nov 14, 2016 at 10:49 AM, John G. Scudder  wrote:

> In my role as co-chair:
>
> On Nov 14, 2016, at 6:10 PM, John G. Scudder  wrote:
> > Please raise any objections by November 21. In this case, silence will
> be taken as consent assuming you've already supported publication.
>
> Given there's debate regarding the SHOULD/MUST change, I think it's not
> appropriate to assume silence gives consent to the change. So, I take that
> back and expect we will judge consensus for this item in the usual way.
> (The same would apply to the canonical representation item if there were to
> be debate about it.)


I have read and reviewed the document, and believe it is ready to go.
I support its publication in the -08 revision.

(And just to be clear, I have withdrawn any/all objections on previous
versions, this one is exactly right.)

Brian Dickson

P.S. One of the author's email addresses appears to be broken -- Keyur
Patel's email domain, arrcus.com, appears not to be registered.

--001a113ca7ac4b0faa054147c8b1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Mon, Nov 14, 2016 at 10:49 AM, John G. Scudder <=
;jgs@juniper.net&g=
t; wrote:
In my role as co-chair:<=
br>


On Nov 14, 2016, at 6:10 PM, John G. Scudder <jgs@juniper.net> wrote:

> Please raise any objections by November 21. In this case, silence will=
 be taken as consent assuming you've already supported publication.



Given there's debate regarding the SHOULD/MUST change, I think i=
t's not appropriate to assume silence gives consent to the change. So, =
I take that back and expect we will judge consensus for this item in the us=
ual way. (The same would apply to the canonical representation item if ther=
e were to be debate about it.)

I have read =
and reviewed the document, and believe it is ready to go.
I suppo=
rt its publication in the -08 revision.

(And just =
to be clear, I have withdrawn any/all objections on previous versions, this=
 one is exactly right.)

Brian Dickson
P.S. One of the author's email addresses appears to be bro=
ken -- Keyur Patel's email domain, arrcus=
.com, appears not to be registered.=C2=A0


--001a113ca7ac4b0faa054147c8b1--


From nobody Mon Nov 14 13:39:47 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCDCD129404 for ; Mon, 14 Nov 2016 13:39:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.396
X-Spam-Level: 
X-Spam-Status: No, score=-3.396 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RP_MATCHES_RCVD=-1.497, 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 Gi4GoGphhsOx for ; Mon, 14 Nov 2016 13:39:44 -0800 (PST)
Received: from relais-inet.orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 215C212941A for ; Mon, 14 Nov 2016 13:39:44 -0800 (PST)
Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id F1650C00EC; Mon, 14 Nov 2016 22:39:41 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.63]) by opfedar05.francetelecom.fr (ESMTP service) with ESMTP id 1352860060; Mon, 14 Nov 2016 22:39:42 +0100 (CET)
Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM6E.corporate.adroot.infra.ftgroup ([fe80::f5a7:eab1:c095:d9ec%18]) with mapi id 14.03.0319.002; Mon, 14 Nov 2016 22:39:41 +0100
From: 
To: "John G. Scudder" , "idr@ietf.org" 
Thread-Topic: [Idr] One week extension to WGLC for draft-ietf-idr-large-community
Thread-Index: AQHSPqfgDdafmc/HhUu/Grx1sqOoJaDY+BGg
Date: Mon, 14 Nov 2016 21:39:42 +0000
Message-ID: <27701_1479159582_582A2F1E_27701_6903_1_53C29892C857584299CBF5D05346208A1EC77FE1@OPEXCLILM21.corporate.adroot.infra.ftgroup>
References:  
In-Reply-To: 
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.168.234.3]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Idr] One week extension to WGLC for draft-ietf-idr-large-community
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, 14 Nov 2016 21:39:46 -0000

John, Sue,

 > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of John G. Scudder  > =
Sent: Monday, November 14, 2016 7:50 PM
>=20
 > In my role as co-chair:
 >=20
 > On Nov 14, 2016, at 6:10 PM, John G. Scudder  wrote:
 > > Please raise any objections by November 21. In this case, silence will=
 be taken as
 > consent assuming you've already supported publication.
 >=20
 > Given there's debate regarding the SHOULD/MUST change, I think it's not =
appropriate to
 > assume silence gives consent to the change. So, I take that back and exp=
ect we will judge
 > consensus for this item in the usual way.=20

1) I support the "MUST".
In addition to the reasons already provided, IMHO, I would say that this al=
so seems aligned with RFC 7606. (but I would prefer not to re-open the 7606=
 error handling debate).

2) If "MUST" is kept, on a side note,=20

- I'm less sure about the "silently" part of "MUST silently" as I'm not sur=
e why logging the error should be considered as a protocol violation. (and =
7606 was rather calling for logging the error). So I would propose to remov=
e "silently.

- If we now have ' Duplicate BGP Large Community values MUST NOT be transmi=
tted.', receiving a duplicate is a clear protocol error. In the general cas=
e, it's difficult to know whether the error is on the sending side or the r=
eceiving side. (Although the receiving side will typically consider that he=
 is (obviously always) right, hence the sender must be in error). Given tha=
t large community has an impact on route preference or selection, this may =
call for "treat-as-withdraw"...
I already hear the objection that "both value are the same hence it has no =
influence", but it's the receiver which claims that both value are the same=
. If the error is on the receiving side, possibly both values were sent as =
different. (e.g. oops, the test was only considering the first 64 bits. And=
 the error had never been detected so far, because the first 64 bits had be=
en different during testing, or the duplicate silently removed))

--Bruno

> (The same would apply to the canonical
 > representation item if there were to be debate about it.)
 >=20
 > --John
 > _______________________________________________
 > Idr mailing list
 > Idr@ietf.org
 > https://www.ietf.org/mailman/listinfo/idr

___________________________________________________________________________=
______________________________________________

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

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


From nobody Mon Nov 14 14:59:48 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC43C1294DC for ; Mon, 14 Nov 2016 14:59:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.699
X-Spam-Level: 
X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, 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 0rYq0ZDN4fhw for ; Mon, 14 Nov 2016 14:59:44 -0800 (PST)
Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC9EA129462 for ; Mon, 14 Nov 2016 14:59:44 -0800 (PST)
Received: by guelah.shrubbery.net (Postfix, from userid 7053) id 83CDA7AE7F; Mon, 14 Nov 2016 22:59:44 +0000 (UTC)
Date: Mon, 14 Nov 2016 22:59:44 +0000
From: heasley 
To: "John G. Scudder" 
Message-ID: <20161114225944.GA68064@shrubbery.net>
References:  
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc
X-note: live free, or die!
X-homer: i just want to have a beer while i am caring.
X-Claimation: an engineer needs a manager like a fish needs a bicycle
X-reality: only YOU can put an end to the embarrassment that is Tom Cruise
User-Agent: Mutt/1.6.1 (2016-04-27)
Archived-At: 
Cc: idr@ietf.org
Subject: Re: [Idr] One week extension to WGLC for draft-ietf-idr-large-community
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, 14 Nov 2016 22:59:46 -0000

Tue, Nov 15, 2016 at 03:49:50AM +0900, John G. Scudder:
> In my role as co-chair:
> 
> On Nov 14, 2016, at 6:10 PM, John G. Scudder  wrote:
> > Please raise any objections by November 21. In this case, silence will be taken as consent assuming you've already supported publication.
> 
> Given there's debate regarding the SHOULD/MUST change, I think it's not appropriate to assume silence gives consent to the change. So, I take that back and expect we will judge consensus for this item in the usual way. (The same would apply to the canonical representation item if there were to be debate about it.)

I agree with your analysis of the keywords and thank you for your replies in  
this debate.


From nobody Mon Nov 14 14:59:58 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 175A7129632 for ; Mon, 14 Nov 2016 14:59:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.019
X-Spam-Level: 
X-Spam-Status: No, score=-16.019 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=-1.497, 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 atJxJhOhB574 for ; Mon, 14 Nov 2016 14:59:49 -0800 (PST)
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 22F0D12961F for ; Mon, 14 Nov 2016 14:59:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4127; q=dns/txt; s=iport; t=1479164389; x=1480373989; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=SH3s66yrRkGsM4ToJAnTLLMKWBvX9jbjv4UCT8fqJXY=; b=jc/kjclEmGkZWvY2PdonP8ri7tIYW6Qr1C0/UHaxjl3JYTqPtm7FU43W Y14YLzn8frsGm61nhdUsHONgSTDTeF5GoPjZ2szkWFMJ0mpeAf3kEvzCh C9Mt8Gh6DPeeDJ/lZ1y9e/2V27Khlcgp+6ffVJ7QsF9GhZfuZK7LwXBMH w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AXAQBbQSpY/4QNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzEBAQEBAR9YgQCNPpcKlGCCBx0LhXsCgic/FAECAQEBAQEBAWI?= =?us-ascii?q?dC4RhAQEBAwEBAQEaHTQLBQsCAQgVAQIeCQcnCxQRAgQOBRSIRQgOsiCLVwEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBARcFhjyBfYJdhBgCEQEcgzGCMAWaQQGQXIFvhHa?= =?us-ascii?q?JO41EhAkBHjdaKRyFGnKFQAYJF4IWAQEB?=
X-IronPort-AV: E=Sophos;i="5.31,640,1473120000"; d="scan'208";a="348459607"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Nov 2016 22:59:48 +0000
Received: from xch-rcd-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id uAEMxmH1007709 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 14 Nov 2016 22:59:48 GMT
Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 14 Nov 2016 16:59:47 -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; Mon, 14 Nov 2016 16:59:47 -0600
From: "Jakob Heitz (jheitz)" 
To: "bruno.decraene@orange.com" 
Thread-Topic: [Idr] One week extension to WGLC for draft-ietf-idr-large-community
Thread-Index: AQHSPlcVO6RKnaa63k2qyfOXORnq2aDZN6gAgAAvdgD//7HLXw==
Date: Mon, 14 Nov 2016 22:59:47 +0000
Message-ID: <736EA2CC-3DD1-4F14-96ED-2916E62F6F02@cisco.com>
References:  , <27701_1479159582_582A2F1E_27701_6903_1_53C29892C857584299CBF5D05346208A1EC77FE1@OPEXCLILM21.corporate.adroot.infra.ftgroup>
In-Reply-To: <27701_1479159582_582A2F1E_27701_6903_1_53C29892C857584299CBF5D05346208A1EC77FE1@OPEXCLILM21.corporate.adroot.infra.ftgroup>
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: 
Cc: "idr@ietf.org" 
Subject: Re: [Idr] One week extension to WGLC for draft-ietf-idr-large-community
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, 14 Nov 2016 22:59:51 -0000

Receipt of a duplicate MUST NOT trigger any error handling. It is not a pro=
tocol error. It MUST NOT cause treat-as-withdraw and MUST NOT cause attribu=
te discard. Simply deleting the duplicate is enough. Even a log of the dele=
tion is noise. Log it if you must, but my code does not. This is consistent=
 with legacy community handling.

Therefore, I support SHOULD.

Thanks,
Jakob.


> On Nov 15, 2016, at 6:39 AM, "bruno.decraene@orange.com"  wrote:
>=20
> John, Sue,
>=20
>> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of John G. Scudder  > =
Sent: Monday, November 14, 2016 7:50 PM
>>=20
>> In my role as co-chair:
>>=20
>>> On Nov 14, 2016, at 6:10 PM, John G. Scudder  wrote:
>>> Please raise any objections by November 21. In this case, silence will =
be taken as
>> consent assuming you've already supported publication.
>>=20
>> Given there's debate regarding the SHOULD/MUST change, I think it's not =
appropriate to
>> assume silence gives consent to the change. So, I take that back and exp=
ect we will judge
>> consensus for this item in the usual way.=20
>=20
> 1) I support the "MUST".
> In addition to the reasons already provided, IMHO, I would say that this =
also seems aligned with RFC 7606. (but I would prefer not to re-open the 76=
06 error handling debate).
>=20
> 2) If "MUST" is kept, on a side note,=20
>=20
> - I'm less sure about the "silently" part of "MUST silently" as I'm not s=
ure why logging the error should be considered as a protocol violation. (an=
d 7606 was rather calling for logging the error). So I would propose to rem=
ove "silently.
>=20
> - If we now have ' Duplicate BGP Large Community values MUST NOT be trans=
mitted.', receiving a duplicate is a clear protocol error. In the general c=
ase, it's difficult to know whether the error is on the sending side or the=
 receiving side. (Although the receiving side will typically consider that =
he is (obviously always) right, hence the sender must be in error). Given t=
hat large community has an impact on route preference or selection, this ma=
y call for "treat-as-withdraw"...
> I already hear the objection that "both value are the same hence it has n=
o influence", but it's the receiver which claims that both value are the sa=
me. If the error is on the receiving side, possibly both values were sent a=
s different. (e.g. oops, the test was only considering the first 64 bits. A=
nd the error had never been detected so far, because the first 64 bits had =
been different during testing, or the duplicate silently removed))
>=20
> --Bruno
>=20
>> (The same would apply to the canonical
>> representation item if there were to be debate about it.)
>>=20
>> --John
>> _______________________________________________
>> Idr mailing list
>> Idr@ietf.org
>> https://www.ietf.org/mailman/listinfo/idr
>=20
> _________________________________________________________________________=
________________________________________________
>=20
> Ce message et ses pieces jointes peuvent contenir des informations confid=
entielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re=
cu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages =
electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme o=
u falsifie. Merci.
>=20
> This message and its attachments may contain confidential or privileged i=
nformation 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 de=
lete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have bee=
n modified, changed or falsified.
> Thank you.
>=20
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr


From nobody Mon Nov 14 15:05:12 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF18C1293E9 for ; Mon, 14 Nov 2016 15:05:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.697
X-Spam-Level: 
X-Spam-Status: No, score=-6.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, URIBL_BLACK=1.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 A4LBmrEwNbAb for ; Mon, 14 Nov 2016 15:05:10 -0800 (PST)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (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 3F9BF129593 for ; Mon, 14 Nov 2016 15:05:10 -0800 (PST)
Received: from dhcp-96cc.meeting.ietf.org (dhcp-96cc.meeting.ietf.org [31.133.150.204]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id uAEN4sYk022171 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 14 Nov 2016 23:04:57 GMT (envelope-from joelja@bogus.com)
To: Brian Dickson , "John G. Scudder" 
References:   
From: joel jaeggli 
Message-ID: <536f5f9f-9db7-7492-eac4-10dbf5aa271a@bogus.com>
Date: Tue, 15 Nov 2016 08:04:52 +0900
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:50.0) Gecko/20100101 Thunderbird/50.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="eeKWkvUpuB08Ov2tWqrA5LoWj3L7kbVa2"
Archived-At: 
Cc: IETF IDR , keyur@arrcus.com
Subject: Re: [Idr] One week extension to WGLC for draft-ietf-idr-large-community
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, 14 Nov 2016 23:05:12 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--eeKWkvUpuB08Ov2tWqrA5LoWj3L7kbVa2
Content-Type: multipart/mixed; boundary="jFUfaxLxhXhlVHObLWJ9SSVClKbRtNaRB";
 protected-headers="v1"
From: joel jaeggli 
To: Brian Dickson ,
 "John G. Scudder" 
Cc: IETF IDR , keyur@arrcus.com
Message-ID: <536f5f9f-9db7-7492-eac4-10dbf5aa271a@bogus.com>
Subject: Re: [Idr] One week extension to WGLC for
 draft-ietf-idr-large-community
References: 
 
 
In-Reply-To: 

--jFUfaxLxhXhlVHObLWJ9SSVClKbRtNaRB
Content-Type: text/plain; charset=windows-1252
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

On 11/15/16 4:24 AM, Brian Dickson wrote:
>=20
>=20
> On Mon, Nov 14, 2016 at 10:49 AM, John G. Scudder  > wrote:
>=20
>     In my role as co-chair:
>=20
>     On Nov 14, 2016, at 6:10 PM, John G. Scudder      > wrote:
>     > Please raise any objections by November 21. In this case, silence=
 will be taken as consent assuming you've already supported publication.
>=20
>     Given there's debate regarding the SHOULD/MUST change, I think it's=

>     not appropriate to assume silence gives consent to the change. So, =
I
>     take that back and expect we will judge consensus for this item in
>     the usual way. (The same would apply to the canonical representatio=
n
>     item if there were to be debate about it.)
>=20
>=20
> I have read and reviewed the document, and believe it is ready to go.
> I support its publication in the -08 revision.
>=20
> (And just to be clear, I have withdrawn any/all objections on previous
> versions, this one is exactly right.)
>=20
> Brian Dickson
>=20
> P.S. One of the author's email addresses appears to be broken -- Keyur
> Patel's email domain, arrcus.com , appears not to be=

> registered.=20

keyur@arrcus.com

J@mb:~$host arrcus.com
arrcus.com has address 50.63.202.51
arrcus.com mail is handled by 10 mx1-us1.ppe-hosted.com.
arrcus.com mail is handled by 20 mx2-us1.ppe-hosted.com.

he responds to email there...

not everything is a webserver

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



--jFUfaxLxhXhlVHObLWJ9SSVClKbRtNaRB--

--eeKWkvUpuB08Ov2tWqrA5LoWj3L7kbVa2
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iEYEARECAAYFAlgqQxQACgkQ8AA1q7Z/VrIpvQCfRGjfrILkHSZ71itndGEs4lP0
IxoAniy6+nJ7ELr/6yUGCijSJ54V41uq
=XSyP
-----END PGP SIGNATURE-----

--eeKWkvUpuB08Ov2tWqrA5LoWj3L7kbVa2--


From nobody Mon Nov 14 15:09:51 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8E6D129593 for ; Mon, 14 Nov 2016 15:09:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.9
X-Spam-Level: 
X-Spam-Status: No, score=-0.9 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, SPF_PASS=-0.001, URIBL_BLACK=1.7] autolearn=no 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 QVy8qasKyWfF for ; Mon, 14 Nov 2016 15:09:48 -0800 (PST)
Received: from dispatch2-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 23303128874 for ; Mon, 14 Nov 2016 15:09:48 -0800 (PST)
Received: from mx7-us1.ppe-hosted.com (unknown [10.110.55.254]) by dispatch2-us1.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTP id 8E0FB60093; Mon, 14 Nov 2016 23:09:47 +0000 (UTC)
X-Virus-Scanned: Proofpoint Essentials engine
Received: from mx7-us1.ppe-hosted.com (localhost.localdomain [127.0.0.1]) by mx7-us1.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTP id 25E8D380055; Mon, 14 Nov 2016 23:09:47 +0000 (UTC)
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03lp0049.outbound.protection.outlook.com [216.32.180.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx7-us1.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id E8CB154005A; Mon, 14 Nov 2016 23:09:43 +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=68JOduqU1Z4NMq3XX75QwYspTmZTUZV4m/o6gFjxKYo=; b=Y66VM9JDakL8SUmgJtEOaSjeULFTNTVmDsaJ2slkiwsDMpSpNZD8dCageHQFaku9qV4F5p/kzkeBWsvBa20Zl/ZmLLm0q/BN6lvmOFoYmFIJ2px1qb18usyQzKfItE9JFJwpF82izvvWZVuHfsNENHAeYdJjNWFbjRGelMndyFE=
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.707.6; Mon, 14 Nov 2016 23:09:27 +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.0707.015; Mon, 14 Nov 2016 23:09:27 +0000
From: Keyur Patel 
To: joel jaeggli , Brian Dickson , "John G. Scudder" 
Thread-Topic: [Idr] One week extension to WGLC for draft-ietf-idr-large-community
Thread-Index: AQHSPlcVq4gXtKpUIkmyaHq6LB30b6DY0xMAgAAJjYCAAD20AIAAASmK
Date: Mon, 14 Nov 2016 23:09:27 +0000
Message-ID: 
References:   , <536f5f9f-9db7-7492-eac4-10dbf5aa271a@bogus.com>
In-Reply-To: <536f5f9f-9db7-7492-eac4-10dbf5aa271a@bogus.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=keyur@arrcus.com; 
x-originating-ip: [132.245.82.53]
x-microsoft-exchange-diagnostics: 1; BY2PR18MB0261; 7:G/LBHl1EkE61izMdiYBiPYE8luSGj8xgocYRXHd0XLaEUU1+3I6iF7RcysfcZVWzLQku5OUv6hRJd/hX0+kJv6w8yuAuo/PafSi/eFUf+QlkBTD5N3PyjxVXPDA3iUctbCmDVve4Dfdy0t7yhfn1+xGBvPlAqsuRbgK0U+BC3JejuAJI+LITB7NJ/sodY/6+F0sXw0aewbREedweIbuEDf4cf5vnW2neIb6lFBrbM3y28GqmrOmX1TU+E2+S5mKuVc8q1owiOimOQOdUAi2Hr9jxR/2UIAhGW276dPM1JPyP+pKux78tP71qG6lBKl+VVNPWatFHLg64cxroqbXTbrZTgk+3VHVu0Vs91bKcVZg=
x-ms-office365-filtering-correlation-id: b4088c76-245f-4716-3b19-08d40ce34805
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BY2PR18MB0261;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(158342451672863)(138986009662008)(265273979862326)(100405760836317)(62015456732948);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6060326)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(2002001)(6061324)(6043046); SRVR:BY2PR18MB0261; BCL:0; PCL:0; RULEID:; SRVR:BY2PR18MB0261; 
x-forefront-prvs: 0126A32F74
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(199003)(24454002)(377454003)(189002)(106116001)(76576001)(5001770100001)(74316002)(189998001)(4326007)(8666005)(105586002)(87936001)(99286002)(106356001)(3846002)(3660700001)(7736002)(97736004)(68736007)(122556002)(3280700002)(6116002)(102836003)(2906002)(7846002)(5660300001)(9686002)(66066001)(50986999)(8936002)(54356999)(230783001)(2900100001)(76176999)(16601075003)(92566002)(77096005)(33656002)(81156014)(7906003)(8676002)(86362001)(2950100002)(93886004)(7696004)(1941001)(101416001)(81166006)(229853002)(50929005)(7099028)(7059030); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR18MB0261; H:BY2PR18MB0262.namprd18.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: arrcus.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BY2PR18MB02620D3C848E91E285162E4DC1BC0BY2PR18MB0262namp_"
MIME-Version: 1.0
X-OriginatorOrg: arrcus.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Nov 2016 23:09:27.0433 (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: EgKuocTIYq8Z
Archived-At: 
Cc: IETF IDR 
Subject: Re: [Idr] One week extension to WGLC for draft-ietf-idr-large-community
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, 14 Nov 2016 23:09:50 -0000

--_000_BY2PR18MB02620D3C848E91E285162E4DC1BC0BY2PR18MB0262namp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Thanks Joel. [?]


Hi Brian,


I did send you an offline email asking for clarification. [?]


Regards,

Keyur

________________________________
From: joel jaeggli 
Sent: Monday, November 14, 2016 3:04:52 PM
To: Brian Dickson; John G. Scudder
Cc: IETF IDR; Keyur Patel
Subject: Re: [Idr] One week extension to WGLC for draft-ietf-idr-large-comm=
unity

On 11/15/16 4:24 AM, Brian Dickson wrote:
>
>
> On Mon, Nov 14, 2016 at 10:49 AM, John G. Scudder  > wrote:
>
>     In my role as co-chair:
>
>     On Nov 14, 2016, at 6:10 PM, John G. Scudder      > wrote:
>     > Please raise any objections by November 21. In this case, silence w=
ill be taken as consent assuming you've already supported publication.
>
>     Given there's debate regarding the SHOULD/MUST change, I think it's
>     not appropriate to assume silence gives consent to the change. So, I
>     take that back and expect we will judge consensus for this item in
>     the usual way. (The same would apply to the canonical representation
>     item if there were to be debate about it.)
>
>
> I have read and reviewed the document, and believe it is ready to go.
> I support its publication in the -08 revision.
>
> (And just to be clear, I have withdrawn any/all objections on previous
> versions, this one is exactly right.)
>
> Brian Dickson
>
> P.S. One of the author's email addresses appears to be broken -- Keyur
> Patel's email domain, arrcus.com , appears not to be
> registered.

keyur@arrcus.com

J@mb:~$host arrcus.com
arrcus.com has address 50.63.202.51
arrcus.com mail is handled by 10 mx1-us1.ppe-hosted.com.
arrcus.com mail is handled by 20 mx2-us1.ppe-hosted.com.

he responds to email there...

not everything is a webserver

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



--_000_BY2PR18MB02620D3C848E91E285162E4DC1BC0BY2PR18MB0262namp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable















Thanks Joel. 3D"&=







Hi Brian,







I did send you an offline email asking for clarification. 3D"��"







Regards,


Keyur






From: joel jaeggli <jo=
elja@bogus.com>

Sent: Monday, November 14, 2016 3:04:52 PM

To: Brian Dickson; John G. Scudder

Cc: IETF IDR; Keyur Patel

Subject: Re: [Idr] One week extension to WGLC for draft-ietf-idr-lar=
ge-community

 







On 11/15/16 4:24 AM, Brian Dickson wrote:

> 

> 

> On Mon, Nov 14, 2016 at 10:49 AM, John G. Scudder <jgs@juniper.net<=
br>
> <mailto:jgs@juniper.net>&=
gt; wrote:

> 

>     In my role as co-chair:

> 

>     On Nov 14, 2016, at 6:10 PM, John G. Scudder &=
lt;jgs@juniper.net

>     <mailto:=
jgs@juniper.net>> wrote:

>     > Please raise any objections by November 2=
1. In this case, silence will be taken as consent assuming you've already s=
upported publication.

> 

>     Given there's debate regarding the SHOULD/MUST=
 change, I think it's

>     not appropriate to assume silence gives consen=
t to the change. So, I

>     take that back and expect we will judge consen=
sus for this item in

>     the usual way. (The same would apply to the ca=
nonical representation

>     item if there were to be debate about it.)

> 

> 

> I have read and reviewed the document, and believe it is ready to go.<=
br>
> I support its publication in the -08 revision.

> 

> (And just to be clear, I have withdrawn any/all objections on previous=


> versions, this one is exactly right.)

> 

> Brian Dickson

> 

> P.S. One of the author's email addresses appears to be broken -- Keyur=


> Patel's email domain, arrcus.com <htt=
p://arrcus.com>, appears not to be

> registered. 



keyur@arrcus.com



J@mb:~$host arrcus.com

arrcus.com has address 50.63.202.51

arrcus.com mail is handled by 10 mx1-us1.ppe-hosted.com.

arrcus.com mail is handled by 20 mx2-us1.ppe-hosted.com.



he responds to email there...



not everything is a webserver



> 

> _______________________________________________

> Idr mailing list

> Idr@ietf.org

> https://www.ietf=
.org/mailman/listinfo/idr

> 











--_000_BY2PR18MB02620D3C848E91E285162E4DC1BC0BY2PR18MB0262namp_--


From nobody Mon Nov 14 15:15:51 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A26F129497 for ; Mon, 14 Nov 2016 15:15:49 -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, 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] 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 OIzDhjUgnqJv for ; Mon, 14 Nov 2016 15:15:47 -0800 (PST)
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0113.outbound.protection.outlook.com [104.47.42.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 347731294DC for ; Mon, 14 Nov 2016 15:15:47 -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=CMQ80lY/kK0h0Y6mc+kyUDArs2femFN81TEQ+9C2Z0o=; b=fA+ptV8aIV5Han/rKgRMVILR9AzlyVNYRHNDnbSapqtgypXZ7c2DGohJokk3USudL+kb+CKPSyKsrNNUqS6SKtFcVuA8sdrZSrlDy/mPfLvxRpLlcyXD5kMo4m8kSEMfphLzeFAhoF9kamfsKxS9qXxNKlHGCMHxTw/e49sFK78=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; 
Received: from [172.29.192.68] (116.197.188.11) 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.734.2; Mon, 14 Nov 2016 23:15:44 +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: <736EA2CC-3DD1-4F14-96ED-2916E62F6F02@cisco.com>
Date: Tue, 15 Nov 2016 08:15:21 +0900
Content-Transfer-Encoding: quoted-printable
Message-ID: <09C80B75-B846-45EE-AC91-A07EB9887CBB@juniper.net>
References:   <27701_1479159582_582A2F1E_27701_6903_1_53C29892C857584299CBF5D05346208A1EC77FE1@OPEXCLILM21.corporate.adroot.infra.ftgroup> <736EA2CC-3DD1-4F14-96ED-2916E62F6F02@cisco.com>
To: "Jakob Heitz (jheitz)" 
X-Mailer: Apple Mail (2.3124)
X-Originating-IP: [116.197.188.11]
X-ClientProxiedBy: HKXPR02CA0041.apcprd02.prod.outlook.com (10.161.48.26) To CY1PR05MB2507.namprd05.prod.outlook.com (10.167.10.134)
X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 2:nVqYhDlZ0L9+gLUeDhb/oeUfvYBLDT3HOQOOUGlHnxEG7LQ7mCgE8rXY+cUqUHSBoA4DH4meTA4pVvg7uZcwSUIpJJwMx9VBOK1Yx1mPKBDwfjeHRc+dE7Jbuci6U+WzR/Xaq16FB/ZS2z6XuqfpvljHj2RF5g+IPVkWVMViyY4=; 3:sHKVqk0TEu22Ch5/Pzs954dXqRM/V/L/RHPM2Xj+NSpRa46wdsufJx9xvEbqdRoxz7s40cOBya5/SyB6tcITVSRD0xIr/vk+LSrGPmHJ9VkaY1r6+2UQdaXSlGPb4OOatA4AWgZsvvldhxNHGyszuwGIHhHYAh+qPBaRB+DKPI0=
X-MS-Office365-Filtering-Correlation-Id: 8de92f19-6d37-41b2-8fd7-08d40ce429ff
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR05MB2507;
X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 25:gi0m73eec3ALWzCqSoYrFW4o4IFLbKxlc5ghmbfXwH7SAux9kCMbUqRULVQ15BhvCv7lSrVNU6AaAiHvpOmDxqNYfFfieUN2Em/sJxhvut+vuhaKuhNHCg1aswARsgxvlEbe82eINS3OjDe2BFBAEjLYbTS7dMz/QQM7BrfDkYZb5ffCwvBpBycH785XwK7l3PJ4XwICe2OEbydQzVbkEU8tg61+EXnYZ6tjPBHIJ8mwdKXR4tSBAuQNG4It2nL5MVM4XT7W3Vu7UU+ft9w7pfivxO713iMU5gHfe/cA0rI8WhFgT93SrbYkceapz2y2iz/X8j2ahs34Oy+w2dpXYaHD6br48sC/FDOG6UEePx/5/EviGpfl3i04r+ewyZunOvpQIxdf93/5yB+Np9l6yUPPTEY1GsiHoGNK/ZbcOtVq1O8/GlVs0ASeJnI2Xw4m6iUkT14PHrQUy+cmj5bEblsynhZCU2ED0LZoOJ1+NSLXcXAVbZCy07YDNhWYuRr/5VJKXcf3l3bHneUVMhr4wTX3raQe9x4ROCKK2DpaVg+P9vwbF1yhznoTj0WoF3sCdyEkpFmhWdjJoKOb5UmlkYLwRlLSt3qMf6qrF1TKZqVwwbYpPsjrKYMz8zcnKGFvCDDkIwByHoC0XuB7V0VCfp/2UrdVm+WDmHDUyIaAt5w0AfSPiz/wvcMdVu+rVLDJIkvf0SzwrEeaDTM0I7dffnywVZmuLHBHsGj5imEdZdL3o7OetQyYQwIoPSg9RnaVnBH10xxd2MxYRaqqm3803c8B9rvF3u7ku86aH+9hO8snumsedq8kRMEFMEyqlaPC+sa4uPmFYohUMca0ukx5iNEzMYTh3MrQzU63f4LcpVk=
X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 31:59ki+5mIlyUONP8F0cFAHaWJir3G4Gx1H7VcvKw/bW6SslwaYgjm2lTTv6cgYJdDFi1LnGIWOOO/j5qy9QKIeyYtYfgDNaEAPsuZkdb7LMHjLVrAwfxCw8zYJ5izwQLGs72HrMSiDyyTArtLFBNl8vNphgzPzTFXC52qdVRcVBNj6BOQqU2dDszYWIg31hW50yaKUm1mPgcye9O7W1lAXREkthq8gCXngv//4zCS241yeyBD6WCuu44xxEi0O1jeInFtyskPgEIiQNQ68BAJNQ==; 20:AHxtgUUzmADLBsdzeIHjF5jGdbOfFRhk+bPPcKJ9dqZotU2qP++qQusH/Qy6ObWrzOAdXXybgbwxuZO6ILglSM2fSgJmPPvABD9R4b2ox6BU+I1BNaQPNnn8gmihkeJhur0JXW3j0BAnlOH3J/r6xj3s3HvYTvONbdagLaTxRjACubYommi+q0natHwbFTrrWY4ROKUGcwUTRGrk0lRV0J8smnMsdMzOFMD5syz1Di357FIg57A6P23Ooav74v5Y/yh1zcJ1MruTb94jUgU2TvNYEXIriVJdnCPwY/STp3FHPd+IglEyviESgy4+UvolJ+OYvd8Wb34YBz80HA/nXBVEYp5Qg3FUd7UBp6/cDuNtiy4UDB2bNeNOAxuoYE4RgtbgEvK6AhVD86dU0PvCci35sf5dQGRHGzkSrLFEHur9NbE8SYe5bFcP7H0iUS66SkawUyIKaH938d+e4uLe/e54x9hH5Goza0l3TFuFQr8vJ4MdnFbXrcNpWNXhe8dV
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(138986009662008)(100405760836317)(95692535739014)(18271650672692); 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6060326)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6061324); SRVR:CY1PR05MB2507; BCL:0; PCL:0; RULEID:; SRVR:CY1PR05MB2507; 
X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 4:tqt46lI4Y0x5wtxU27lmfAQ1mlYcpjL3+RBvS2lf4oUwxti846T+4OZEFqOYa4qctlgO0YFkMr8WCHrO9XN4L0+YzmlDdJnFe38DfNLwgKd2dqEBi3coHGDLrQRRnQIIpZfM1QWKr2mEg2K1NBqeKr7TtWce7KSuf9/QDbm9g9GsJFSCVQeh8BzlP+xSvFBtsq4Fy9BTG5EmbQ1xsOeqGoonebcdZzd288R1xDyBJzrl/4IklxMKS7wJTw2PE/M+1l4W94QR43WoNiCLfz5MsW2h9JfdARS4w2Z8+0JS4HbSy8owfTkXUXmbylLYRJDxVDt+QovHZri8GhFY2R9WkG/T2zcy3SAsS0Vvwdudvse8bn+cHFKSHLq4YDgGBuS0jOQyazLMInJVretkAOxF/Od38Zh/sWM63jn2zH4XQOylhYjgYu0kA7KNTv7gm5tEibcp+WFQhxueiVW/tAKy5HV0RfakCmZmGO1xemN2jB13WrdeF75ZMxmBKZZD/bOkYMXolC5dU8zVvXzwDxCmWVrlZ4AftLrXJrAT6oKop5odfkWIUH+QM66TFdbAP2oxCzdhWkI7MKQx+R/CNtLU4A==
X-Forefront-PRVS: 0126A32F74
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(7916002)(199003)(377454003)(189002)(24454002)(3846002)(23726003)(66066001)(47776003)(82746002)(305945005)(7736002)(189998001)(36756003)(97736004)(92566002)(2906002)(7846002)(8676002)(4326007)(6116002)(50466002)(77096005)(83716003)(86362001)(229853002)(230783001)(93886004)(46406003)(50986999)(76176999)(5660300001)(33656002)(5890100001)(81166006)(81156014)(8746002)(97756001)(50226002)(6666003)(68736007)(57306001)(101416001)(2950100002)(106356001)(105586002)(42186005)(6916009)(110136003)(42262002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2507; H:[172.29.192.68]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR05MB2507; 23:H4vZ2vKa5W1v2JAuSFTebgYHPAmdMUZoIk41dXmZ9?= =?us-ascii?Q?8MxMXzmnZNTIWS56MPXjrJGouBaERo+tuhUbhubs4x2/0rOrwBXMdAGzToRA?= =?us-ascii?Q?FIKiFrIZDH4bv+9ttDlWXtLrfPcd+9OJqgUu+Vmmi4gC9wSbii2sGWPbJFId?= =?us-ascii?Q?uXuu5uKRtQHRia+PvMlPZZ21e/EDD8uy6KMr0C18ZtR2aiVeHVaRxAiu/jVA?= =?us-ascii?Q?G7MSpjjMoSUm5LvjoVWRg4s2fN19+joJg95BU92YTUpg3Xk+Epw4Tqo3QVXl?= =?us-ascii?Q?zDZtONDeJk514PvK/QYbhGKMfqEoRj6L6jTMhf5xa1jT9IAu/hix0lOyTIet?= =?us-ascii?Q?CzL3dBbtd1VT9cvGbokVQuKJ1vlAp0cG2E1meaT12Y3tAjCEw5fA7on+Yw+B?= =?us-ascii?Q?XOzoCksjg9CwVHFK0CV/5PkGRFCg7Tpk93/6jRaAADuDErpGgJPpWZzDJbGg?= =?us-ascii?Q?cg9X7uGVvbm9qPcue8O7MsWczCRK6jFudz3vD+SFx58feNZjBj0nmBWgZzVk?= =?us-ascii?Q?XA0VHzfk4h0r+JaNC0E+wsdTSQ88AezBV6eTq2iQsjtx9hUOuI1crtI/1XKB?= =?us-ascii?Q?eCfSwOqmRO+MS029S0nS2eqASpJtAV3WL6slOJrOfsJtSQnRxVt9Jd9RB+Af?= =?us-ascii?Q?uTTxDxP3vjSKObRje6odwCwcr954I0QQDhv3gQd2T+4ohncrgeB+Y75pXdvT?= =?us-ascii?Q?fYMooH0NR/kDkKBjnVo3w07jY7gu6ATjcC935VBrxRGEyZySLYLxTHzkRrJc?= =?us-ascii?Q?qDZqCSkoZPSSWKXweuzAgo0wUJGUi3uIlE9695167SyooLUY7kaaZepTLm08?= =?us-ascii?Q?2+tKC/YhbNSBydXkDmCgbxAB1eU4uuTRjIwA9amHK/+O9NxoQEs9kQ2CmXd1?= =?us-ascii?Q?7dl/ZajarIgeZuKh4LA8Fjr+XmAochhMwAIW4b1eUgG1QYO2FkWF+YOzrKc+?= =?us-ascii?Q?G8T40DI/0nLhtI3Lg5h+bNtTyM1KQCK04/mfv9SNZT7zCuPnWntEJ2p9+ceL?= =?us-ascii?Q?U8qc7dwlmQzWu9gbdRtymp0xy7ESt4Mx3XGjfa+svz4n8iufVcn/ui9yBHQA?= =?us-ascii?Q?86syuLVMhhkIoTlX3nvCNgXwp3NMYKi+71uH43lWPuHIzlSFNEiLUFc8DKiV?= =?us-ascii?Q?TzABtS2ckeFWTsMnOSSuZ+p6Dvd4sKnIHyI3ULVfO6NRLpEmQGT98PmA1WX5?= =?us-ascii?Q?32CRCUqNJ1HiGA8UQKptX77Uoys/BXDsc3vIJWOL9JdSI/vZ3M/1BT9rgvsq?= =?us-ascii?Q?+hQIPoByJL7I6fSyLUSz0DWaCSyPTWJijlYMr3F?=
X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 6:mZq+3SV+VwJOhawht7jvwyMVOttPOe6z4Aa1F7CJsqA1Kmkhzg5MMA5TtSfj9e5mt7vKHR6z3Xs8fbQyE4ZVWWsXqhgebsXKBpdUnzdk2ywUA2pViiAtrptnnwWoIL4dSnF1qKuwVKpHpjqR3CPc+7EVQOIlQMtZS85qavCimSQdxhRWGV+9L/GiGvmm50kiea8Q+I0QlMe7NzOxGsoSCTUWEXgPA3GnhTbIIuET/kVnyrYoXC9LcwPjrhN+tbGmvrGXim3ac1jiNpMyXYE2GywkID5THqvd6SN3qzDZii/xxV91+guSV1/vi4pP86IrgIplq1CoMx2KGlon8O4WjeOPjgLXZTlFmOZMOmmPxSQn1dxksSjWKK4DGZyBj2oH; 5:pcqRncFFjL9lmqG6eT8DQ8b01kWTS1+N1anrFGsc0owV7+cO+TC8ANsn5U8GKJ9pupX9aFicF9fMHR3S9XEj82ZlZU/EKWvXay5AtoyMnydhlixVh8n7QihokTNOkThM1fTdCHwYrtzwfDkMtphngw==; 24:KqrShc+V7u+9AND565sTb608uXJpyXIo2TzfmQagfug7/94bgDamz2fynfYx44JLZbDoazV0rjUg5byUwjSzVq3DIy20fLpsCodUhTckgkQ=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 7:OiGq44xg95HSzkGthUvmtijE5m6O+cgwS4o5PDqnyGPEkpVm2sVdAT3co0Jn53/XaTrwlnvKwMx9bbSo/Pu6VfBd7c+JUAUc3Qefzy5RZWb702WjEKD48VcBbk9DYK9Rw/UXECKNCfYXe8Ck9lWAyHRowrHcy6/rZPZIJUbube/J/8AfJq1fjDKd8lQjv8kUZVydcnw9JPNqDlL3W36DfPVWQwgXQFvWGfRXYa4sDE6+eMo6m1Ebl5eR4yl4m4KXq+s7ZruQbg5QAuiqNQul0gCtfU0jHGek1J4RM3bSGRCaz+6sk2G6UPfieZWrMZ1jPKPAGULV9ZrfLOs5bAO177jG+uODE8qLUsD0MPvG2Lo=
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Nov 2016 23:15:44.2366 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2507
Archived-At: 
Cc: "bruno.decraene@orange.com" , "idr@ietf.org" 
Subject: Re: [Idr] One week extension to WGLC for draft-ietf-idr-large-community
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, 14 Nov 2016 23:15:49 -0000

FWIW I think your concerns are still addressed if the MUST language is =
used. They would apply if the change implied by Bruno's final bullet =
were to be adopted.

For my own part (again, in my role as a WG contributor)=20

- I think Bruno's point about the -08 language appearing to forbid =
logging is well-taken, and I would support fixing it, for example by =
dropping the word "silently". A sentence like "In case such a duplicate =
Large Community is received an error MAY be logged" could be added if =
wanted (the "or may not" branch is implicit) but personally I'd opt for =
just dropping "silently" and leaving it to implementor discretion as we =
already do for a plethora of other things.

- Although I take Bruno's point about it being a protocol error, I would =
not support the change implied in the final bullet, and would prefer the =
text as written, modulo dropping "silently". Also, changing the text =
back to SHOULD wouldn't really address Bruno's concern anyhow, except in =
a spec-lawyer kind of way, IMO.

Thanks,

--John

On Nov 15, 2016, at 7:59 AM, Jakob Heitz (jheitz)  =
wrote:
>=20
> Receipt of a duplicate MUST NOT trigger any error handling. It is not =
a protocol error. It MUST NOT cause treat-as-withdraw and MUST NOT cause =
attribute discard. Simply deleting the duplicate is enough. Even a log =
of the deletion is noise. Log it if you must, but my code does not. This =
is consistent with legacy community handling.
>=20
> Therefore, I support SHOULD.
>=20
> Thanks,
> Jakob.
>=20
>=20
>> On Nov 15, 2016, at 6:39 AM, "bruno.decraene@orange.com" =
 wrote:
>>=20
>> John, Sue,
>>=20
>>> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of John G. Scudder =
 > Sent: Monday, November 14, 2016 7:50 PM
>>>=20
>>> In my role as co-chair:
>>>=20
>>>> On Nov 14, 2016, at 6:10 PM, John G. Scudder  =
wrote:
>>>> Please raise any objections by November 21. In this case, silence =
will be taken as
>>> consent assuming you've already supported publication.
>>>=20
>>> Given there's debate regarding the SHOULD/MUST change, I think it's =
not appropriate to
>>> assume silence gives consent to the change. So, I take that back and =
expect we will judge
>>> consensus for this item in the usual way.=20
>>=20
>> 1) I support the "MUST".
>> In addition to the reasons already provided, IMHO, I would say that =
this also seems aligned with RFC 7606. (but I would prefer not to =
re-open the 7606 error handling debate).
>>=20
>> 2) If "MUST" is kept, on a side note,=20
>>=20
>> - I'm less sure about the "silently" part of "MUST silently" as I'm =
not sure why logging the error should be considered as a protocol =
violation. (and 7606 was rather calling for logging the error). So I =
would propose to remove "silently.
>>=20
>> - If we now have ' Duplicate BGP Large Community values MUST NOT be =
transmitted.', receiving a duplicate is a clear protocol error. In the =
general case, it's difficult to know whether the error is on the sending =
side or the receiving side. (Although the receiving side will typically =
consider that he is (obviously always) right, hence the sender must be =
in error). Given that large community has an impact on route preference =
or selection, this may call for "treat-as-withdraw"...
>> I already hear the objection that "both value are the same hence it =
has no influence", but it's the receiver which claims that both value =
are the same. If the error is on the receiving side, possibly both =
values were sent as different. (e.g. oops, the test was only considering =
the first 64 bits. And the error had never been detected so far, because =
the first 64 bits had been different during testing, or the duplicate =
silently removed))
>>=20
>> --Bruno
>>=20
>>> (The same would apply to the canonical
>>> representation item if there were to be debate about it.)
>>>=20
>>> --John
>>> _______________________________________________
>>> Idr mailing list
>>> Idr@ietf.org
>>> https://www.ietf.org/mailman/listinfo/idr
>>=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


From nobody Mon Nov 14 15:36:15 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BDCD12941C for ; Mon, 14 Nov 2016 15:36:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=steffann.nl
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-Bp4cuzKlGA for ; Mon, 14 Nov 2016 15:36:12 -0800 (PST)
Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:9e0:803::6]) (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 5F3E7129593 for ; Mon, 14 Nov 2016 15:36:12 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 1525D3A; Tue, 15 Nov 2016 00:36:10 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= references:message-id:content-transfer-encoding:date:date :in-reply-to:x-mailer:from:from:subject:subject:mime-version :content-type:content-type:received:received; s=mail; t= 1479166568; bh=YwI4vAjvr8lKcgfiWcCHzpwPwmLEgiOcUenHoB4tIrk=; b=B scBD5Xa2urOsE+PjmlABeySd7zcgUGk+7KJ40caWyL7Nzqg3iO2w+hqmwqGbYAe7 xk+RtHIJuIEIdW7IUqeYtM6XzrtciXUxkzZ7z3cZxkJPwOljYM8/f3UXTbkz+xlI 4B2eFst+QSqxGhcdAmhW7KFT4uSohezcCtZTxG5UnQ=
X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl
Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id cj73Na-LIGZx; Tue, 15 Nov 2016 00:36:08 +0100 (CET)
Received: from [IPv6:2a02:a213:a300:9300:5c84:e6a0:1710:92f] (unknown [IPv6:2a02:a213:a300:9300:5c84:e6a0:1710:92f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.sintact.nl (Postfix) with ESMTPSA id 25CF138; Tue, 15 Nov 2016 00:36:08 +0100 (CET)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
X-Clacks-Overhead: GNU Terry Pratchett
From: Sander Steffann 
X-Mailer: iPhone Mail (14B100)
In-Reply-To: <4788D7D5-31F2-4FA9-A9AF-29D6F33E8FF1@juniper.net>
Date: Tue, 15 Nov 2016 00:36:07 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <20161114092338.GF24817@gir.theapt.org> <18460A64-11D9-46A1-9388-5D751648A88C@juniper.net> <363A2F4B-2FCC-4A99-ABE5-C3AC70223A3B@steffann.nl> <4788D7D5-31F2-4FA9-A9AF-29D6F33E8FF1@juniper.net>
To: "John G. Scudder" 
Archived-At: 
Cc: IETF IDR Working Group 
Subject: Re: [Idr] One week extension to WGLC for draft-ietf-idr-large-community
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, 14 Nov 2016 23:36:14 -0000

Hi John,

> Remember that the attribute is transitive optional. This means that it's c=
ompletely valid per RFC 4271 S. 5 for a router that doesn't implement the sp=
ec to receive and transmit the attribute without scrubbing it, no matter wha=
t instructions we provide in the spec. So --
>=20
>> On Nov 15, 2016, at 1:18 AM, Sander Steffann  wrote:
>> The MUST/MUST NOT wording makes it mandatory for a router
>=20
> Implicitly, a router that implements the large communities spec. It's not n=
ecessary to call this out explicitly in the large comms spec since RFC 4271 c=
overs the case explicitly: "It is not required or expected that all BGP impl=
ementations support all optional attributes."
>=20
>> to evaluate the communities to make sure there are no duplicates. A route=
r that just forwards the attribute (it doesn't know about large or it doesn'=
t care)
>=20
> The "doesn't care" case implies an implementation that has large comms cod=
e but is configured to pretend it doesn't; the feature is present but disabl=
ed. This distinction is admittedly a little unclear in RFC 4271 but IMO it's=
 fine for a router to pretend to fall into the "I don't support this attribu=
te" case, if for some reason it needs to, as long as it behaves consistently=
 according to that pretense. Basically this comes down to what "support" mea=
ns in the sentence I quoted above -- does it mean the code is present? Or do=
es it mean the code path is present and enabled in configuration? I'm fine w=
ith the latter and in my experience this is the common interpretation. (I th=
ink this nuance is well beyond the scope of the present draft to fix, in any=
 case.)

That covers the case I worried about then :)

>> might have a reason to not inspect and validate them. It should never rec=
eive them in the first place of course,
>=20
> On the contrary, it's in the nature of transitive optional attributes that=
 it's normal to receive and propagate them.

I meant large attributes that contain duplicate community values.

>> but you never know what strange stuff you receive :)
>>=20
>> Based on this I think SHOULD is better than MUST: it allows routers to fo=
rward the attribute as received without spending cycles on evaluating it if t=
hey don't want/need to. It also aligns better with the behaviour of routers t=
hat don't understand the large attribute at all.
>=20
> As discussed above, in my opinion MUST is completely consistent with the b=
ehaviour of routers that don't understand the large attribute at all.

If an implementation is allowed to forward the attribute as-is without looki=
ng at it (code path present but disabled, treating it as an unknown optional=
 transitive attribute) then I'm fine with that.

Please count me as neutral on the issue. I'm fine with either wording, I jus=
t wanted to make sure this wouldn't cause problems.

Cheers,
Sander



From nobody Mon Nov 14 15:40:57 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FC48129593 for ; Mon, 14 Nov 2016 15:40:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.999
X-Spam-Level: 
X-Spam-Status: No, score=-0.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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLACK=1.7] 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 XNkE3LiHqjtf for ; Mon, 14 Nov 2016 15:40:53 -0800 (PST)
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 AA275128874 for ; Mon, 14 Nov 2016 15:40:53 -0800 (PST)
Received: by mail-wm0-x230.google.com with SMTP id f82so131581636wmf.1 for ; Mon, 14 Nov 2016 15:40:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CqDMJ3lZIzZOMa/n8iFwgneOSq6tUgUz1HEynRNrLlw=; b=Oyqf2ZrM1ON/TuGiiCCOlh/6ime62l/9v3nU6xwm6XSyequN4eOuf5unCESIf3N7Up ChzqN3mAAqI/+oCW82joI3YwadzB5PBBgXtjjsp4ikJ4MXs7oAldw40p+sjxjNu7gp1e OuR68OE9OY29RGEMn27Cvvaxv1g/gzN5Bv5FK2H81V4or6bHIHW4hf1GewPkw0J2zbbi YQhI4wM0n4Mn4Q0JoUgXa+soTMfedJi+QkPPaibPgeEuW3kXj4fx/516i18ydq3o9+UL VDmhHYhH6xisv8fZLsQqiVIVLVydhE+WR574GhmTalDbgDISaQzyr2IGM18CGHGOYCRq shsQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CqDMJ3lZIzZOMa/n8iFwgneOSq6tUgUz1HEynRNrLlw=; b=m6NGoDJVcHEvZG8w7idZdjO1egWzrtA/F58fwng4brPHzZbr6zHE0nkzOxUWipG63c akTVaH33mTygAEQySOUhklHDHawb2ZcWg2U8gmrE6Ut0KTexPXO3rq+YDzHwp3cVj1NU GfUvU1O1x/uVNzZU2SuNTDRcKfguqrVmFA87X/U2F7d4bSJvpxWkp0XqVrGUtZANFQX7 Y+LQ3/bDuJjYRLsdGc+R/XEzEcyMRN1s0TnZ9DJGfKTLsoc26GZL6mFX6bAuPVrKTPPA 7K3+NbRnxFToA8OtGqSNVlZpHk+y21SxTylVLjyb83UXXbmIsH7ViyT14m4Akq13XPjD 5DSA==
X-Gm-Message-State: ABUngvdvw5XQIwPe9kthF96RJRbq8uIxZsEV/fOGStiw4GvU/qQawyVeTPRGcETIQ+y888TVm6fjC2bk1Kf0+A==
X-Received: by 10.194.112.196 with SMTP id is4mr25072730wjb.92.1479166852130;  Mon, 14 Nov 2016 15:40:52 -0800 (PST)
MIME-Version: 1.0
Received: by 10.28.197.132 with HTTP; Mon, 14 Nov 2016 15:40:51 -0800 (PST)
In-Reply-To: <536f5f9f-9db7-7492-eac4-10dbf5aa271a@bogus.com>
References:    <536f5f9f-9db7-7492-eac4-10dbf5aa271a@bogus.com>
From: Brian Dickson 
Date: Mon, 14 Nov 2016 15:40:51 -0800
Message-ID: 
To: joel jaeggli 
Content-Type: multipart/alternative; boundary=001a1130c8ecc8ec4005414b5ed1
Archived-At: 
Cc: Keyur Patel , IETF IDR 
Subject: Re: [Idr] One week extension to WGLC for draft-ietf-idr-large-community
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, 14 Nov 2016 23:40:55 -0000

--001a1130c8ecc8ec4005414b5ed1
Content-Type: text/plain; charset=UTF-8

On Mon, Nov 14, 2016 at 3:04 PM, joel jaeggli  wrote:

> On 11/15/16 4:24 AM, Brian Dickson wrote:
> >
> >
> > On Mon, Nov 14, 2016 at 10:49 AM, John G. Scudder  > > wrote:
> >
> >     In my role as co-chair:
> >
> >     On Nov 14, 2016, at 6:10 PM, John G. Scudder  >     > wrote:
> >     > Please raise any objections by November 21. In this case, silence
> will be taken as consent assuming you've already supported publication.
> >
> >     Given there's debate regarding the SHOULD/MUST change, I think it's
> >     not appropriate to assume silence gives consent to the change. So, I
> >     take that back and expect we will judge consensus for this item in
> >     the usual way. (The same would apply to the canonical representation
> >     item if there were to be debate about it.)
> >
> >
> > I have read and reviewed the document, and believe it is ready to go.
> > I support its publication in the -08 revision.
> >
> > (And just to be clear, I have withdrawn any/all objections on previous
> > versions, this one is exactly right.)
> >
> > Brian Dickson
> >
> > P.S. One of the author's email addresses appears to be broken -- Keyur
> > Patel's email domain, arrcus.com , appears not to be
> > registered.
>
> keyur@arrcus.com
>
> J@mb:~$host arrcus.com
> arrcus.com has address 50.63.202.51
> arrcus.com mail is handled by 10 mx1-us1.ppe-hosted.com.
> arrcus.com mail is handled by 20 mx2-us1.ppe-hosted.com.
>
> he responds to email there...
>
> not everything is a webserver
>

Sorry, my bad.
(I was curious about what Keyur is up to, which lead to the wrong
conclusion.)

Brian

--001a1130c8ecc8ec4005414b5ed1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



=
On Mon, Nov 14, 2016 at 3:04 PM, joel jaeggli <joelja@bogus.com> wrote:
On 11/15/16 4=
:24 AM, Brian Dickson wrote:

>

>

> On Mon, Nov 14, 2016 at 10:49 AM, John G. Scudder <jgs@juniper.net

> <mailto:=
jgs@juniper.net>> wrote:

>

>=C2=A0 =C2=A0 =C2=A0In my role as co-chair:

>

>=C2=A0 =C2=A0 =C2=A0On Nov 14, 2016, at 6:10 PM, John G. Scudder <jgs@juniper.net

>=C2=A0 =C2=A0 =C2=A0<mailto:jgs@juniper.net>> wrote:

>=C2=A0 =C2=A0 =C2=A0> Please raise any objections by November 21. In=
 this case, silence will be taken as consent assuming you've already su=
pported publication.

>

>=C2=A0 =C2=A0 =C2=A0Given there's debate regarding the SHOULD/MUST =
change, I think it's

>=C2=A0 =C2=A0 =C2=A0not appropriate to assume silence gives consent to =
the change. So, I

>=C2=A0 =C2=A0 =C2=A0take that back and expect we will judge consensus f=
or this item in

>=C2=A0 =C2=A0 =C2=A0the usual way. (The same would apply to the canonic=
al representation

>=C2=A0 =C2=A0 =C2=A0item if there were to be debate about it.)

>

>

> I have read and reviewed the document, and believe it is ready to go.<=
br>
> I support its publication in the -08 revision.

>

> (And just to be clear, I have withdrawn any/all objections on previous=


> versions, this one is exactly right.)

>

> Brian Dickson

>

> P.S. One of the author's email addresses appears to be broken -- K=
eyur

> Patel's email domain, arrcus.com <http://arrcus.com>, appears=
 not to be

> registered.



keyur@arrcus.com



J@mb:~$host arrcus.com

arrcus.c=
om has address 50.63.202.51

arrcus.c=
om mail is handled by 10 mx1-us1.ppe-hosted.com.

arrcus.c=
om mail is handled by 20 mx2-us1.ppe-hosted.com.



he responds to email there...



not everything is a webserver



=

Sorry, my bad.
(I was curious about what Keyur is up to, which lead to the wrong conc=
lusion.)

Brian


--001a1130c8ecc8ec4005414b5ed1--


From nobody Mon Nov 14 15:52:12 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FAC9126CD8 for ; Mon, 14 Nov 2016 15:52:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.699
X-Spam-Level: 
X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, 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 ByQknSxZl2Br for ; Mon, 14 Nov 2016 15:51:59 -0800 (PST)
Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 8D7AF1293FD for ; Mon, 14 Nov 2016 15:51:53 -0800 (PST)
Received: from t2001067c037001446d53789767aa2406.hotel-wired.v6.meeting.ietf.org (unknown [IPv6:2001:67c:370:144:6d53:7897:67aa:2406]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id 95BD9540757; Mon, 14 Nov 2016 18:51:50 -0500 (EST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
From: Jared Mauch 
In-Reply-To: <09C80B75-B846-45EE-AC91-A07EB9887CBB@juniper.net>
Date: Mon, 14 Nov 2016 18:51:25 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <788CA5F1-90E1-4913-837C-9DA84B0DCFDE@puck.nether.net>
References:   <27701_1479159582_582A2F1E_27701_6903_1_53C29892C857584299CBF5D05346208A1EC77FE1@OPEXCLILM21.corporate.adroot.infra.ftgroup> <736EA2CC-3DD1-4F14-96ED-2916E62F6F02@cisco.com> <09C80B75-B846-45EE-AC91-A07EB9887CBB@juniper.net>
To: "John G. Scudder" 
X-Mailer: Apple Mail (2.3251)
Archived-At: 
Cc: "bruno.decraene@orange.com" , "idr@ietf.org" 
Subject: Re: [Idr] One week extension to WGLC for draft-ietf-idr-large-community
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, 14 Nov 2016 23:52:10 -0000

> On Nov 14, 2016, at 6:15 PM, John G. Scudder  wrote:
>=20
> FWIW I think your concerns are still addressed if the MUST language is =
used. They would apply if the change implied by Bruno's final bullet =
were to be adopted.
>=20
> For my own part (again, in my role as a WG contributor)=20
>=20
> - I think Bruno's point about the -08 language appearing to forbid =
logging is well-taken, and I would support fixing it, for example by =
dropping the word "silently". A sentence like "In case such a duplicate =
Large Community is received an error MAY be logged" could be added if =
wanted (the "or may not" branch is implicit) but personally I'd opt for =
just dropping "silently" and leaving it to implementor discretion as we =
already do for a plethora of other things.

I think simply saying duplicates are not errors is sufficient.  I =
don=E2=80=99t think the SHOULD/MUST discussion merits a lot of bits =
typed as it=E2=80=99s unlikely to have a real impact. =20

Due to the opaque nature of the attribute, it seems SHOULD NOT is =
enough.  Saying it should be ignored/dropped seems a step beyond that is =
necessary to describe in the protocol standard.  The same is true for =
the logging prohibition, that is an operational aspect of the routing =
platform or implementation vs a protocol issue, which should not be =
addressed here and is therefore out of scope.  Simply stating it is not =
an error should be sufficient.

I do understand the desire to not send duplicates, and agree =
implementors SHOULD NOT and MUST take care to not send them, but =
software is imperfect and we should ensure the least disruption =
feasible.  This was the point behind RFC7606 to provide safe degradation =
of BGP speakers.

- Jared (hopefully my only comment on the thread)

> - Although I take Bruno's point about it being a protocol error, I =
would not support the change implied in the final bullet, and would =
prefer the text as written, modulo dropping "silently". Also, changing =
the text back to SHOULD wouldn't really address Bruno's concern anyhow, =
except in a spec-lawyer kind of way, IMO.
>=20
> Thanks,
>=20
> --John
>=20
> On Nov 15, 2016, at 7:59 AM, Jakob Heitz (jheitz)  =
wrote:
>>=20
>> Receipt of a duplicate MUST NOT trigger any error handling. It is not =
a protocol error. It MUST NOT cause treat-as-withdraw and MUST NOT cause =
attribute discard. Simply deleting the duplicate is enough. Even a log =
of the deletion is noise. Log it if you must, but my code does not. This =
is consistent with legacy community handling.
>>=20
>> Therefore, I support SHOULD.
>>=20
>> Thanks,
>> Jakob.
>>=20
>>=20
>>> On Nov 15, 2016, at 6:39 AM, "bruno.decraene@orange.com" =
 wrote:
>>>=20
>>> John, Sue,
>>>=20
>>>> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of John G. =
Scudder  > Sent: Monday, November 14, 2016 7:50 PM
>>>>=20
>>>> In my role as co-chair:
>>>>=20
>>>>> On Nov 14, 2016, at 6:10 PM, John G. Scudder  =
wrote:
>>>>> Please raise any objections by November 21. In this case, silence =
will be taken as
>>>> consent assuming you've already supported publication.
>>>>=20
>>>> Given there's debate regarding the SHOULD/MUST change, I think it's =
not appropriate to
>>>> assume silence gives consent to the change. So, I take that back =
and expect we will judge
>>>> consensus for this item in the usual way.=20
>>>=20
>>> 1) I support the "MUST".
>>> In addition to the reasons already provided, IMHO, I would say that =
this also seems aligned with RFC 7606. (but I would prefer not to =
re-open the 7606 error handling debate).
>>>=20
>>> 2) If "MUST" is kept, on a side note,=20
>>>=20
>>> - I'm less sure about the "silently" part of "MUST silently" as I'm =
not sure why logging the error should be considered as a protocol =
violation. (and 7606 was rather calling for logging the error). So I =
would propose to remove "silently.
>>>=20
>>> - If we now have ' Duplicate BGP Large Community values MUST NOT be =
transmitted.', receiving a duplicate is a clear protocol error. In the =
general case, it's difficult to know whether the error is on the sending =
side or the receiving side. (Although the receiving side will typically =
consider that he is (obviously always) right, hence the sender must be =
in error). Given that large community has an impact on route preference =
or selection, this may call for "treat-as-withdraw"...
>>> I already hear the objection that "both value are the same hence it =
has no influence", but it's the receiver which claims that both value =
are the same. If the error is on the receiving side, possibly both =
values were sent as different. (e.g. oops, the test was only considering =
the first 64 bits. And the error had never been detected so far, because =
the first 64 bits had been different during testing, or the duplicate =
silently removed))
>>>=20
>>> --Bruno
>>>=20
>>>> (The same would apply to the canonical
>>>> representation item if there were to be debate about it.)
>>>>=20
>>>> --John
>>>> _______________________________________________
>>>> Idr mailing list
>>>> Idr@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/idr
>>>=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
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr


From nobody Mon Nov 14 18:52:43 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8802E1299FA for ; Mon, 14 Nov 2016 18:52:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.398
X-Spam-Level: 
X-Spam-Status: No, score=-108.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 a-otp2qGCyOD for ; Mon, 14 Nov 2016 18:52:37 -0800 (PST)
Received: from ia-mailgw.apnic.net (ia-mailgw.apnic.net [IPv6:2001:dd8:a:851::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80BAF129677 for ; Mon, 14 Nov 2016 18:52:37 -0800 (PST)
Received: from nxmda2.org.apnic.net (unknown [2001:dd8:9:2::101:249]) by ia-mailgw.apnic.net (Halon) with ESMTPS id 8fd5f403-aade-11e6-a41e-005056b6f213; Tue, 15 Nov 2016 12:52:35 +1000 (AEST)
Received: from dhcp-868f.meeting.ietf.org (203.119.101.249) by NXMDA2.org.apnic.net (203.119.107.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 15 Nov 2016 12:52:11 +1000
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
From: Geoff Huston 
In-Reply-To: <9E85C422-42DB-438B-98BC-DB678E403B12@steffann.nl>
Date: Tue, 15 Nov 2016 13:52:27 +1100
Content-Transfer-Encoding: quoted-printable
Message-ID: <34A7D25B-1B64-475A-8116-87BD9A651D75@apnic.net>
References: <1d8e529a370f4c98b599b48eee7e82ed@tcb.net> <20161114151829.GC67788@dhcp-9341.meeting.ietf.org> <9E85C422-42DB-438B-98BC-DB678E403B12@steffann.nl>
To: Sander Steffann 
X-Mailer: Apple Mail (2.3251)
Archived-At: 
Cc: idr@ietf.org, Danny McPherson , rtg-dir@ietf.org
Subject: Re: [Idr] RTG-DIR REVIEW: draft-ietf-idr-large-community-08
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, 15 Nov 2016 02:52:41 -0000

> On 15 Nov. 2016, at 3:24 am, Sander Steffann  =
wrote:
> Please see my previous email to John about SHOULD/MUST here. With that =
in mind:
>=20
>> To put this in different words: if the paragraphs remains as it was
>> (like in -07) with the words "SHOULD", implicitly we acknowledge that
>> there _might_ be a semantic meaning in signalling duplicate =
communities.
>=20
> I agree that there MUST NOT be semantic meaning in duplicate =
communities. How about:
>=20
> """
> Duplicate BGP Large Community values SHOULD NOT be transmitted.  A
> receiving speaker SHOULD silently remove duplicate BGP Large
> Community values from a BGP Large Community attribute. If a community
> value is received multiple times this MUST NOT be treated differently
> than a community value that is received only once.
> """
>=20
> as a middle ground?
>=20

I think this test is a good way forward.

Geoff



From nobody Mon Nov 14 20:40:41 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7E5D1293EE for ; Mon, 14 Nov 2016 20:40:39 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] 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 xOrAHdCbIuXV for ; Mon, 14 Nov 2016 20:40:38 -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 C7098129589 for ; Mon, 14 Nov 2016 20:40:33 -0800 (PST)
Received: by mail-pg0-x230.google.com with SMTP id p66so62026378pga.2 for ; Mon, 14 Nov 2016 20:40:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=date:from:to:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=4WVKTG5NsYzlHVFvFchwxaUPPQcyank45DHRJ6LJIIY=; b=BGvNktZlLu1P0wxhe7TR5PS8MQStFqDqTWjrhfucuOXgYbNzUUNRdADSGkCiKUnt3P XtMbDDAQGdnDhBJHhgk6dQq5oOxoAEpThKqB0Skqe3zBb7cgyH7nRaSxgoWEsyuMeGFG 89YOhudTpYXElufLu2QXlfvVtDCJhlBfs8B0Oplk9tJfHHtfspuih4KVGxf0/2wdFEv5 hjU0GEMcEOnIj79XRj3+KpcfMnXBsG6jOf4eCB0XLrNbdx7vKYrTZk0lSxGP57h+XsLC m9zkJyAzPSLyJy2tJzeb+xtxGiRtpBZlNQkcGvW3j7g4fcYRNG6xJBv1kKHQPoGW5G+h FTuQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=4WVKTG5NsYzlHVFvFchwxaUPPQcyank45DHRJ6LJIIY=; b=SOOpqTO9eSF8mXKrYNbAy9rE9dLL6lxQRqPdsAPkRl8RjQxNqHwBQ7Z+GgAErN5n1q wYjXJDx6VL6fKwxnTozl6jqLgLoJ1eAj67fADTjoRnvzfnAWhlrGc/SnUmJy/6h4VU7h sCjn2uReVDkyV4YAQrHU6xCh1s9It0CQVJk6Ss+7JmXPufupMzvnasIkle5uiBvWdev9 nvV/+9O+pjRD09POnpU/JDUHrQr6DT8F1IfXoNKDAURILfb2zwgsvmPu3Rgwd8I0pvyk o5DXL4qkNKrYfUBzc0UngIlZ1/ZraC0TVQ/YiCdBwP5dzpFWvSU67KfJaEaa1mhsSf8g 47Lw==
X-Gm-Message-State: ABUngvf8yQJEGA68mnEXFtG+sYlU6QEV5dYyUhXKg6Qp3PsdpBIh3j5EaWu2Cd8lcvpetw==
X-Received: by 10.98.63.1 with SMTP id m1mr42803570pfa.31.1479184832675; Mon, 14 Nov 2016 20:40:32 -0800 (PST)
Received: from localhost (t2001067c037001447d5d6e2df7db8cf6.hotel-wired.v6.meeting.ietf.org. [2001:67c:370:144:7d5d:6e2d:f7db:8cf6]) by smtp.gmail.com with ESMTPSA id y89sm17636617pfk.83.2016.11.14.20.40.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 14 Nov 2016 20:40:30 -0800 (PST)
Date: Tue, 15 Nov 2016 13:40:27 +0900
From: Job Snijders 
To: idr@ietf.org
Message-ID: <20161115044027.GI67788@dhcp-9341.meeting.ietf.org>
References: <147910154788.10388.9578791609428008498.idtracker@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <147910154788.10388.9578791609428008498.idtracker@ietfa.amsl.com>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.7.1 (2016-10-04)
Archived-At: 
Subject: Re: [Idr] New Version Notification for draft-ymbk-idr-bgp-open-policy-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, 15 Nov 2016 04:40:40 -0000

Hi,

Reviewing this document, the following question came up:

Have you considered using two BGP Well-known Communities instead of
defining two new attributes 'IOTC' and 'EOTC'?

The advantage of well-known communities would be that one can
incrementally deploy the concepts described in the draft. It can quite
some time to deploy new software on all devices in certain networks,
while on the other hand deploying a new configuration is a much smaller
timescale.

For instance if router A supports 'OPEN', it can mark the routes with
the well-known community IOTC, and router B (which has no support for
'OPEN'), can be configured to act upon the well-known community IOTC.

I'd like to learn more about the considerations.

Kind regards,

Job

On Sun, Nov 13, 2016 at 09:32:27PM -0800, internet-drafts@ietf.org wrote:
> 
> A new version of I-D, draft-ymbk-idr-bgp-open-policy-02.txt
> has been successfully submitted by Randy Bush and posted to the
> IETF repository.
> 
> Name:		draft-ymbk-idr-bgp-open-policy
> Revision:	02
> Title:		Route Leak Detection and Filtering using Roles in Update and Open messages
> Document date:	2016-11-14
> Group:		Individual Submission
> Pages:		11
> URL:            https://www.ietf.org/internet-drafts/draft-ymbk-idr-bgp-open-policy-02.txt
> Status:         https://datatracker.ietf.org/doc/draft-ymbk-idr-bgp-open-policy/
> Htmlized:       https://tools.ietf.org/html/draft-ymbk-idr-bgp-open-policy-02
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ymbk-idr-bgp-open-policy-02
> 
> Abstract:
>    Route Leaks are the propagation of BGP prefixes which violate
>    assumptions of BGP topology relationships; e.g. passing a route
>    learned from one peer to another peer or to a transit provider,
>    passing a route learned from one transit provider to another transit
>    provider or to a peer.  Today, approaches to leak prevention rely on
>    marking routes according to operator configuration options without
>    any check that the configuration corresponds to that of the BGP
>    neighbor, or enforcement that the two BGP speakers agree on the
>    relationship.  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 a eOTC and iOTC
>    attributes according to agreed relationship allowing prevention and
>    detection of route leaks.
> 
> 
>                                                                                   
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr


From nobody Mon Nov 14 20:41:57 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56686129694 for ; Mon, 14 Nov 2016 20:41:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.398
X-Spam-Level: 
X-Spam-Status: No, score=-8.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, 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 d95XQp94xJeB for ; Mon, 14 Nov 2016 20:41:50 -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 5DCEA129473 for ; Mon, 14 Nov 2016 20:41:50 -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 1c6VZ6-0001Nc-6a; Tue, 15 Nov 2016 04:41:48 +0000
Date: Tue, 15 Nov 2016 13:41:44 +0900
Message-ID: 
From: Randy Bush 
To: Job Snijders 
In-Reply-To: <20161115043725.GH67788@dhcp-9341.meeting.ietf.org>
References: <147910154788.10388.9578791609428008498.idtracker@ietfa.amsl.com> <20161115043725.GH67788@dhcp-9341.meeting.ietf.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: 
Cc: Interminable Discussion Room 
Subject: Re: [Idr] New Version Notification for draft-ymbk-idr-bgp-open-policy-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, 15 Nov 2016 04:41:55 -0000

> Have you considered using two BGP Well-known Communities instead of
> defining two new attributes 'IOTC' and 'EOTC'?

yes.  as it says in the introduction to the draft

   [I-D.ietf-idr-route-leak-detection-mitigation] describes a method of
   marking and detecting leaks which relies on operator maintained
   markings.  Unfortunately, in most cases, a leaking router will likely
   also be misconfigured to mark incorrectly.  The mechanism proposed in
   that draft provides the opportunity to detect route leaks made by
   third parties but provides no support to strongly prevent route leak
   creation.  The leak prevention still relies on communities which are
   optional and often missed due to mistakes or misunderstanding of the
   BGP configuration process.

randy


From nobody Mon Nov 14 20:49:56 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F227129501 for ; Mon, 14 Nov 2016 20:49:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.432
X-Spam-Level: 
X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_SOFTFAIL=0.665] 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 NC7s1hdR4quq for ; Mon, 14 Nov 2016 20:49:53 -0800 (PST)
Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (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 83A07129473 for ; Mon, 14 Nov 2016 20:49:53 -0800 (PST)
Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1c6Vgu-0008Io-EY (job@us.ntt.net); Tue, 15 Nov 2016 04:49:53 +0000
Date: Tue, 15 Nov 2016 05:49:50 +0100
From: Job Snijders 
To: idr@ietf.org
Message-ID: <20161115044950.GG87204@hanna.meerval.net>
References: <147910154788.10388.9578791609428008498.idtracker@ietfa.amsl.com> <20161115043725.GH67788@dhcp-9341.meeting.ietf.org> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.7.1 (2016-10-04)
Archived-At: 
Subject: Re: [Idr] New Version Notification for draft-ymbk-idr-bgp-open-policy-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, 15 Nov 2016 04:49:54 -0000

On Tue, Nov 15, 2016 at 01:41:44PM +0900, Randy Bush wrote:
> > Have you considered using two BGP Well-known Communities instead of
> > defining two new attributes 'IOTC' and 'EOTC'?
> 
> yes.  as it says in the introduction to the draft
> 
>    [I-D.ietf-idr-route-leak-detection-mitigation] describes a method of
>    marking and detecting leaks which relies on operator maintained
>    markings.  Unfortunately, in most cases, a leaking router will likely
>    also be misconfigured to mark incorrectly.  The mechanism proposed in
>    that draft provides the opportunity to detect route leaks made by
>    third parties but provides no support to strongly prevent route leak
>    creation.  The leak prevention still relies on communities which are
>    optional and often missed due to mistakes or misunderstanding of the
>    BGP configuration process.

No, the act of marking described in draft-ymbk-idr-bgp-open-policy-02 is
not manual from what i understand. The introduction text argues against
manual marking.

Also, the proposed 'BGP Internal Only To Customer' attribute is
optional, just like communities.

Kind regards,

Job


From nobody Mon Nov 14 21:51:42 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3EB21295C3 for ; Mon, 14 Nov 2016 21:51:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.399
X-Spam-Level: 
X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, 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 0lAAnHU5q1o8 for ; Mon, 14 Nov 2016 21:51:38 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id C3DF4127058 for ; Mon, 14 Nov 2016 21:51:38 -0800 (PST)
Received: by slice.pfrc.org (Postfix, from userid 1001) id F39C31E337; Tue, 15 Nov 2016 00:54:31 -0500 (EST)
Date: Tue, 15 Nov 2016 00:54:31 -0500
From: Jeffrey Haas 
To: idr@ietf.org
Message-ID: <20161115055431.GB5875@pfrc.org>
References: <147910154788.10388.9578791609428008498.idtracker@ietfa.amsl.com> <20161115044027.GI67788@dhcp-9341.meeting.ietf.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20161115044027.GI67788@dhcp-9341.meeting.ietf.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: 
Subject: Re: [Idr] New Version Notification for draft-ymbk-idr-bgp-open-policy-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, 15 Nov 2016 05:51:40 -0000

On Tue, Nov 15, 2016 at 01:40:27PM +0900, Job Snijders wrote:
> Have you considered using two BGP Well-known Communities instead of
> defining two new attributes 'IOTC' and 'EOTC'?

Some providers seem to strip even well known communities.  :-)

Path attributes deploy a bit more pervasively.  Modulo filtering, of course.

-- Jeff


From nobody Mon Nov 14 22:47:02 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39011129A32 for ; Mon, 14 Nov 2016 22:47:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.398
X-Spam-Level: 
X-Spam-Status: No, score=-8.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, 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 8tlWKMUlpQeE for ; Mon, 14 Nov 2016 22:46:59 -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 31605129A2B for ; Mon, 14 Nov 2016 22:46:59 -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 1c6XWD-0001kF-GV; Tue, 15 Nov 2016 06:46:57 +0000
Date: Tue, 15 Nov 2016 15:46:56 +0900
Message-ID: 
From: Randy Bush 
To: Jeffrey Haas 
In-Reply-To: <20161115055431.GB5875@pfrc.org>
References: <147910154788.10388.9578791609428008498.idtracker@ietfa.amsl.com> <20161115044027.GI67788@dhcp-9341.meeting.ietf.org> <20161115055431.GB5875@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: 
Cc: idr@ietf.org
Subject: Re: [Idr] New Version Notification for draft-ymbk-idr-bgp-open-policy-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, 15 Nov 2016 06:47:00 -0000

> Some providers seem to strip even well known communities.  :-)

no!  really?  and they never misconfigure them either, of course.

> Path attributes deploy a bit more pervasively.

and rigorously, when open insists that they correspond.

randy


From nobody Tue Nov 15 01:22:18 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B77DA1296CD for ; Tue, 15 Nov 2016 01:22:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.398
X-Spam-Level: 
X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497, SPF_HELO_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 vdlKlGh-q8I9 for ; Tue, 15 Nov 2016 01:22:15 -0800 (PST)
Received: from gir.theapt.org (gir.theapt.org [81.209.183.113]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 190E7129A83 for ; Tue, 15 Nov 2016 01:22:14 -0800 (PST)
Received: from gir.theapt.org (unknown [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/0 bits)) (Client did not present a certificate) (Authenticated sender: phessler) by gir.theapt.org (Postfix) with ESMTPSA id C3C67788FC for ; Tue, 15 Nov 2016 10:22:12 +0100 (CET)
Date: Tue, 15 Nov 2016 10:22:11 +0100
From: Peter Hessler 
To: idr@ietf.org
Message-ID: <20161115092211.GK24817@gir.theapt.org>
References: <147910154788.10388.9578791609428008498.idtracker@ietfa.amsl.com> <20161115044027.GI67788@dhcp-9341.meeting.ietf.org> <20161115055431.GB5875@pfrc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20161115055431.GB5875@pfrc.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: 
Subject: Re: [Idr] New Version Notification for draft-ymbk-idr-bgp-open-policy-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, 15 Nov 2016 09:22:17 -0000

On 2016 Nov 15 (Tue) at 00:54:31 -0500 (-0500), Jeffrey Haas wrote:
:On Tue, Nov 15, 2016 at 01:40:27PM +0900, Job Snijders wrote:
:> Have you considered using two BGP Well-known Communities instead of
:> defining two new attributes 'IOTC' and 'EOTC'?
:
:Some providers seem to strip even well known communities.  :-)

As I understand it, this is only intended to matter for directly
connected peers so filtering can (and should) be done before any
stripping is done.

Of course, if a provider is stripping and ignoring even NO_EXPORT, then
you'll have the exact same problems as before.


-- 
The brain is a wonderful organ; it starts working the moment you get up
in the morning, and does not stop until you get to school.


From nobody Tue Nov 15 01:25:12 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACD12129A30 for ; Tue, 15 Nov 2016 01:25:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.097
X-Spam-Level: 
X-Spam-Status: No, score=-4.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497] 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 i9Wvi3GkkkzG for ; Tue, 15 Nov 2016 01:25:08 -0800 (PST)
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 8D40E129450 for ; Tue, 15 Nov 2016 01:25:08 -0800 (PST)
X-Original-To: idr@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 5944960DAE for ; Tue, 15 Nov 2016 10:25:06 +0100 (CET)
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 E595160835; Tue, 15 Nov 2016 10:25:05 +0100 (CET)
Received: by moebius4.space.net (Postfix, from userid 1007) id D78C610A76; Tue, 15 Nov 2016 10:25:05 +0100 (CET)
Date: Tue, 15 Nov 2016 10:25:05 +0100
From: Gert Doering 
To: Jeffrey Haas 
Message-ID: <20161115092505.GQ79185@Space.Net>
References: <147910154788.10388.9578791609428008498.idtracker@ietfa.amsl.com> <20161115044027.GI67788@dhcp-9341.meeting.ietf.org> <20161115055431.GB5875@pfrc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20161115055431.GB5875@pfrc.org>
X-NCC-RegID: de.space
User-Agent: Mutt/1.6.1 (2016-04-27)
Archived-At: 
Cc: idr@ietf.org
Subject: Re: [Idr] New Version Notification for draft-ymbk-idr-bgp-open-policy-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, 15 Nov 2016 09:25:11 -0000

Hi,

On Tue, Nov 15, 2016 at 12:54:31AM -0500, Jeffrey Haas wrote:
> On Tue, Nov 15, 2016 at 01:40:27PM +0900, Job Snijders wrote:
> > Have you considered using two BGP Well-known Communities instead of
> > defining two new attributes 'IOTC' and 'EOTC'?
> 
> Some providers seem to strip even well known communities.  :-)

These communities must not leave the local AS (because what is a 
customer prefix to one AS might be a *peer* to another), so stripping
on AS boundaries is a desirable feature.

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 Nov 15 05:46:22 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34482126B6D for ; Tue, 15 Nov 2016 05:46:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.396
X-Spam-Level: 
X-Spam-Status: No, score=-3.396 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RP_MATCHES_RCVD=-1.497, 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 XR49IbrxiLtu for ; Tue, 15 Nov 2016 05:46:19 -0800 (PST)
Received: from relais-inet.orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 042991294FF for ; Tue, 15 Nov 2016 05:46:19 -0800 (PST)
Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar27.francetelecom.fr (ESMTP service) with ESMTP id 7D582600B8; Tue, 15 Nov 2016 14:46:14 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.31]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 6B49B4004C; Tue, 15 Nov 2016 14:46:15 +0100 (CET)
Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM22.corporate.adroot.infra.ftgroup ([fe80::8c90:f4e9:be28:2a1%19]) with mapi id 14.03.0319.002; Tue, 15 Nov 2016 14:46:15 +0100
From: 
To: "Jakob Heitz (jheitz)" , "John G. Scudder" 
Thread-Topic: [Idr] One week extension to WGLC for draft-ietf-idr-large-community
Thread-Index: AQHSPlcVO6RKnaa63k2qyfOXORnq2aDZN6gAgAAvdgD//7HLX4AAnUfQ
Date: Tue, 15 Nov 2016 13:46:15 +0000
Message-ID: <26709_1479217575_582B11A7_26709_12999_1_53C29892C857584299CBF5D05346208A1EC79584@OPEXCLILM21.corporate.adroot.infra.ftgroup>
References:  , <27701_1479159582_582A2F1E_27701_6903_1_53C29892C857584299CBF5D05346208A1EC77FE1@OPEXCLILM21.corporate.adroot.infra.ftgroup> <736EA2CC-3DD1-4F14-96ED-2916E62F6F02@cisco.com>
In-Reply-To: <736EA2CC-3DD1-4F14-96ED-2916E62F6F02@cisco.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.168.234.5]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: "idr@ietf.org" 
Subject: Re: [Idr] One week extension to WGLC for draft-ietf-idr-large-community
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, 15 Nov 2016 13:46:21 -0000

TL;DR: I'm fine with -08 (MUST NOT send, MUST de-duplicate). I'm not fine w=
ith -06, unless some text is added, because it may open different interpret=
ation.

> From: Jakob Heitz (jheitz) [mailto:jheitz@cisco.com]  > Sent: Tuesday, No=
vember 15, 2016 12:00 AM
>=20
 > Receipt of a duplicate MUST NOT trigger any error handling. It is not a =
protocol error. It
 > MUST NOT cause treat-as-withdraw and MUST NOT cause attribute discard. S=
imply
 > deleting the duplicate is enough. Even a log of the deletion is noise. L=
og it if you must, but
 > my code does not. This is consistent with legacy community handling.
 >=20
 > Therefore, I support SHOULD.

If you believe that this is not an error, there is no need for specific act=
ion, not to mention trying to correct the .... error. ("SHOULD remove the d=
uplicate" is trying to correct it).

Taking a step back, I think that what we really must specify, is whether a =
community received N times, MUST be considered as received N times or 1 tim=
e, because this impacts the meaning, hence the interop. e.g. if the communi=
ty means prepend one, does sending it N times means prepend N or prepend 1)
>From the current text, it seems that people want to only have the community=
 interpreted once. (which is a restriction of what we could do).

If so, it seems to never make sense to send the same value multiple times. =
So it seems clearer to completely forbid it (MUST NOT) rather than leaving =
the option to re-open the discussion latter or consider how the receiver ne=
ed to react to "keep the meaning" intended by the originator. Especially si=
nce some combination seems to make less sense. e.g. "SHOULD NOT be sent, SH=
OULD be removed" where we are opening the option to send duplicate, but we =
don't define how such duplicate will propagate, so the originator has even =
less reason to try an innovative unspecified behavior.

Now, if we have "MUST NOT be sent", then I think that this is an error cond=
ition if we receive duplicate. And I see 3 options:
a) leave them all, (i.e. no correction) but specify that N times as the sam=
e value that 1 time.
b) try to stop the error, by correcting it (i.e. "remove duplicate") but th=
at seem to assume that the error is on the sending side, while the error co=
uld in fact be on the receiving side. It's bothers me a little that this po=
int had never been discussed by the WG, especially since for the receiver (=
coder), there is a clear bias in favor of trusting itself (himself). While =
we had real world example where the error was on the receiving side or at l=
east not on the sending side (e.g. error due to code point collision, e.g. =
VPN extended community 0x010a, and more recently attributes in draft-ietf-i=
dr-deprecate-30-31-129)
c) try to stop the error, with no assumption on the source of the error, by=
 withdrawing the error (Attribute discard or Treat-As-Withdraw). Would be T=
AW in our case.

I had suggested "treat-as-withdraw" as a provocation to trigger the discuss=
ion, which had never happened. But personally I don't care much on the acti=
on, provided that the interpretation is not ambiguous. e.g. MUST be conside=
red as received 1 time.

Again, I fine with latest version (-08). I'm less fine with the -06 version=
, especially as the behavior on the receiving side is not strictly defined =
and may not be interoperable (-06 allows keeping duplicate while not defini=
ng its meaning)

Thanks,
--Bruno
=20
 > Thanks,
 > Jakob.
 >=20
 >=20
 > > On Nov 15, 2016, at 6:39 AM, "bruno.decraene@orange.com"
 >  wrote:
 > >
 > > John, Sue,
 > >
 > >> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of John G. Scudder =
 > Sent: Monday,
 > November 14, 2016 7:50 PM
 > >>
 > >> In my role as co-chair:
 > >>
 > >>> On Nov 14, 2016, at 6:10 PM, John G. Scudder  wrote:
 > >>> Please raise any objections by November 21. In this case, silence wi=
ll be taken as
 > >> consent assuming you've already supported publication.
 > >>
 > >> Given there's debate regarding the SHOULD/MUST change, I think it's n=
ot appropriate
 > to
 > >> assume silence gives consent to the change. So, I take that back and =
expect we will
 > judge
 > >> consensus for this item in the usual way.
 > >
 > > 1) I support the "MUST".
 > > In addition to the reasons already provided, IMHO, I would say that th=
is also seems
 > aligned with RFC 7606. (but I would prefer not to re-open the 7606 error=
 handling debate).
 > >
 > > 2) If "MUST" is kept, on a side note,
 > >
 > > - I'm less sure about the "silently" part of "MUST silently" as I'm no=
t sure why logging
 > the error should be considered as a protocol violation. (and 7606 was ra=
ther calling for
 > logging the error). So I would propose to remove "silently.
 > >
 > > - If we now have ' Duplicate BGP Large Community values MUST NOT be tr=
ansmitted.',
 > receiving a duplicate is a clear protocol error. In the general case, it=
's difficult to know
 > whether the error is on the sending side or the receiving side. (Althoug=
h the receiving side
 > will typically consider that he is (obviously always) right, hence the s=
ender must be in
 > error). Given that large community has an impact on route preference or =
selection, this
 > may call for "treat-as-withdraw"...
 > > I already hear the objection that "both value are the same hence it ha=
s no influence",
 > but it's the receiver which claims that both value are the same. If the =
error is on the
 > receiving side, possibly both values were sent as different. (e.g. oops,=
 the test was only
 > considering the first 64 bits. And the error had never been detected so =
far, because the
 > first 64 bits had been different during testing, or the duplicate silent=
ly removed))
 > >
 > > --Bruno
 > >
 > >> (The same would apply to the canonical
 > >> representation item if there were to be debate about it.)
 > >>
 > >> --John
 > >> _______________________________________________
 > >> Idr mailing list
 > >> Idr@ietf.org
 > >> https://www.ietf.org/mailman/listinfo/idr
 > >
 > >
 > _________________________________________________________________________
 > ________________________________________________
 > >
 > > Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou
 > privilegiees et ne doivent donc
 > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=
 recu ce message
 > par erreur, veuillez le signaler
 > > a l'expediteur et le detruire ainsi que les pieces jointes. Les messag=
es electroniques
 > etant susceptibles d'alteration,
 > > Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie.
 > Merci.
 > >
 > > This message and its attachments may contain confidential or privilege=
d information
 > that may be protected by law;
 > > they should not be distributed, used or copied without authorisation.
 > > 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

___________________________________________________________________________=
______________________________________________

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

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


From nobody Tue Nov 15 06:19:31 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C445129531 for ; Tue, 15 Nov 2016 06:19:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level: 
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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 yh7v-v-G6xAx for ; Tue, 15 Nov 2016 06:19:26 -0800 (PST)
Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::244]) (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 A8112126BF7 for ; Tue, 15 Nov 2016 06:19:25 -0800 (PST)
Received: by mail-wm0-x244.google.com with SMTP id g23so295301wme.1 for ; Tue, 15 Nov 2016 06:19:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ApuH/tv6wSgY/2yxvW176kg5PyUzT1ipaXNSJ/BLkyU=; b=yb6dfzyjZtzVksYRaGztZeI1vxCOlp+11f7cYhLn8CpuAPDRamWv08TNvElX25GDKi mehP2IWE4RXgIPkFMDHiOT9WfPUG7jztvV+O2jbxKoY5hRBRNRYQGXGUDvnCJnfCDsRH cEtxOko7clK2NADltMBi+zVMpzGA+THYjJLJzjkIwhaNojm7xOBWyCvLkKBEUXIzJKcz TuQIu2TweCYKJqrTxWuIqil1lV9g4bTlVl8OUfZgYeXA1z9bOqVtFUzfNJpoCJbUzqP8 sYDZPQVMc8XKzTsp5d7TPaTq39ssWEigfp+t1n5D4J1KQL3wSefTYHkI6+1Zr7f0XYOR 8srg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=ApuH/tv6wSgY/2yxvW176kg5PyUzT1ipaXNSJ/BLkyU=; b=OdByHpismLFjFu2UDc8W+dfkYSRgemE3Z6lUZ8YI8hHLeCULJFIUdfJeVPOXwS+txK nbNgQOukVM6G/rSynSxvv0MWlWq0AFs8PzdeTQqNZG4U/RoiInls/16BGI8o5dW5kk82 eWB8HMEptCGaBUaahXQQ0ssKKInKmA3tMmUzf0j6OhzVtdMhWmlMfe+XMw5yAclAh6eO khVJ8tk8iarq4RJQP73xY5AlDJ/NNwN9TA1VdzZ3/miNoV5ETDV8Llp6MhpolZh/XW1T qL7QqQN23OaVgBkIm3/YLdRPnLmU6VABl+OMkL+o2ET4kmf1xo7Wj0wz1ohW4qyjySlb JqVQ==
X-Gm-Message-State: ABUngvd2IDORx/hZ0zLNtZB6BbyKH9dc9hO8aefqOTHmi3r8c2RPVt5R7rwg22ocpHA6u7WSoXzFC2qNr2B8nw==
X-Received: by 10.194.187.103 with SMTP id fr7mr23211621wjc.99.1479219563786;  Tue, 15 Nov 2016 06:19:23 -0800 (PST)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.80.137.69 with HTTP; Tue, 15 Nov 2016 06:19:22 -0800 (PST)
Received: by 10.80.137.69 with HTTP; Tue, 15 Nov 2016 06:19:22 -0800 (PST)
In-Reply-To: <26709_1479217575_582B11A7_26709_12999_1_53C29892C857584299CBF5D05346208A1EC79584@OPEXCLILM21.corporate.adroot.infra.ftgroup>
References:   <27701_1479159582_582A2F1E_27701_6903_1_53C29892C857584299CBF5D05346208A1EC77FE1@OPEXCLILM21.corporate.adroot.infra.ftgroup> <736EA2CC-3DD1-4F14-96ED-2916E62F6F02@cisco.com> <26709_1479217575_582B11A7_26709_12999_1_53C29892C857584299CBF5D05346208A1EC79584@OPEXCLILM21.corporate.adroot.infra.ftgroup>
From: Robert Raszuk 
Date: Tue, 15 Nov 2016 15:19:22 +0100
X-Google-Sender-Auth: Ixmkrbq6IQfCY5Y6_Fl68zEzErI
Message-ID: 
To: bruno.decraene@orange.com
Content-Type: multipart/alternative; boundary=047d7bd6bc9ca5150f054157a464
Archived-At: 
Cc: idr wg 
Subject: Re: [Idr] One week extension to WGLC for draft-ietf-idr-large-community
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, 15 Nov 2016 14:19:29 -0000

--047d7bd6bc9ca5150f054157a464
Content-Type: text/plain; charset=UTF-8

Hi Bruno,

Since I was going to ask the same question let me provide an example:

AS1 ---- AS2 ---- AS3 ---- peer_X

AS3 publishes community with action if I receive this community I will
PREPEND my AS# one time towards my peer X.

Now AS1 comes with a need for such prepend on PI prefix P. Then AS2 for
perhaps completely different reason also comes up with idea to hint AS3 to
execute prepend on the same very prefix P.

So AS3 is receiving the two communities which both are valid and truely
intended. Why we would drop it ?

I admit when the topic came up originally the major concern to me was to
prevent stuffing community with N identical sets of values by same AS.

But even this case can be legitimate. Let's consider that said AS2  needs
prepend by 2 to some prefixes and AS3 offers *only* community of single
PREPEND. Why not adding it twice to such selected prefixes not be a way to
signal such requirement ?

Regards,
R.

On Nov 15, 2016 10:46 PM,  wrote:

> TL;DR: I'm fine with -08 (MUST NOT send, MUST de-duplicate). I'm not fine
> with -06, unless some text is added, because it may open different
> interpretation.
>
> > From: Jakob Heitz (jheitz) [mailto:jheitz@cisco.com]  > Sent: Tuesday,
> November 15, 2016 12:00 AM
> >
>  > Receipt of a duplicate MUST NOT trigger any error handling. It is not a
> protocol error. It
>  > MUST NOT cause treat-as-withdraw and MUST NOT cause attribute discard.
> Simply
>  > deleting the duplicate is enough. Even a log of the deletion is noise.
> Log it if you must, but
>  > my code does not. This is consistent with legacy community handling.
>  >
>  > Therefore, I support SHOULD.
>
> If you believe that this is not an error, there is no need for specific
> action, not to mention trying to correct the .... error. ("SHOULD remove
> the duplicate" is trying to correct it).
>
> Taking a step back, I think that what we really must specify, is whether a
> community received N times, MUST be considered as received N times or 1
> time, because this impacts the meaning, hence the interop. e.g. if the
> community means prepend one, does sending it N times means prepend N or
> prepend 1)
> >From the current text, it seems that people want to only have the
> community interpreted once. (which is a restriction of what we could do).
>
> If so, it seems to never make sense to send the same value multiple times.
> So it seems clearer to completely forbid it (MUST NOT) rather than leaving
> the option to re-open the discussion latter or consider how the receiver
> need to react to "keep the meaning" intended by the originator. Especially
> since some combination seems to make less sense. e.g. "SHOULD NOT be sent,
> SHOULD be removed" where we are opening the option to send duplicate, but
> we don't define how such duplicate will propagate, so the originator has
> even less reason to try an innovative unspecified behavior.
>
> Now, if we have "MUST NOT be sent", then I think that this is an error
> condition if we receive duplicate. And I see 3 options:
> a) leave them all, (i.e. no correction) but specify that N times as the
> same value that 1 time.
> b) try to stop the error, by correcting it (i.e. "remove duplicate") but
> that seem to assume that the error is on the sending side, while the error
> could in fact be on the receiving side. It's bothers me a little that this
> point had never been discussed by the WG, especially since for the receiver
> (coder), there is a clear bias in favor of trusting itself (himself). While
> we had real world example where the error was on the receiving side or at
> least not on the sending side (e.g. error due to code point collision, e.g.
> VPN extended community 0x010a, and more recently attributes in
> draft-ietf-idr-deprecate-30-31-129)
> c) try to stop the error, with no assumption on the source of the error,
> by withdrawing the error (Attribute discard or Treat-As-Withdraw). Would be
> TAW in our case.
>
> I had suggested "treat-as-withdraw" as a provocation to trigger the
> discussion, which had never happened. But personally I don't care much on
> the action, provided that the interpretation is not ambiguous. e.g. MUST be
> considered as received 1 time.
>
> Again, I fine with latest version (-08). I'm less fine with the -06
> version, especially as the behavior on the receiving side is not strictly
> defined and may not be interoperable (-06 allows keeping duplicate while
> not defining its meaning)
>
> Thanks,
> --Bruno
>
>  > Thanks,
>  > Jakob.
>  >
>  >
>  > > On Nov 15, 2016, at 6:39 AM, "bruno.decraene@orange.com"
>  >  wrote:
>  > >
>  > > John, Sue,
>  > >
>  > >> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of John G.
> Scudder  > Sent: Monday,
>  > November 14, 2016 7:50 PM
>  > >>
>  > >> In my role as co-chair:
>  > >>
>  > >>> On Nov 14, 2016, at 6:10 PM, John G. Scudder 
> wrote:
>  > >>> Please raise any objections by November 21. In this case, silence
> will be taken as
>  > >> consent assuming you've already supported publication.
>  > >>
>  > >> Given there's debate regarding the SHOULD/MUST change, I think it's
> not appropriate
>  > to
>  > >> assume silence gives consent to the change. So, I take that back and
> expect we will
>  > judge
>  > >> consensus for this item in the usual way.
>  > >
>  > > 1) I support the "MUST".
>  > > In addition to the reasons already provided, IMHO, I would say that
> this also seems
>  > aligned with RFC 7606. (but I would prefer not to re-open the 7606
> error handling debate).
>  > >
>  > > 2) If "MUST" is kept, on a side note,
>  > >
>  > > - I'm less sure about the "silently" part of "MUST silently" as I'm
> not sure why logging
>  > the error should be considered as a protocol violation. (and 7606 was
> rather calling for
>  > logging the error). So I would propose to remove "silently.
>  > >
>  > > - If we now have ' Duplicate BGP Large Community values MUST NOT be
> transmitted.',
>  > receiving a duplicate is a clear protocol error. In the general case,
> it's difficult to know
>  > whether the error is on the sending side or the receiving side.
> (Although the receiving side
>  > will typically consider that he is (obviously always) right, hence the
> sender must be in
>  > error). Given that large community has an impact on route preference or
> selection, this
>  > may call for "treat-as-withdraw"...
>  > > I already hear the objection that "both value are the same hence it
> has no influence",
>  > but it's the receiver which claims that both value are the same. If the
> error is on the
>  > receiving side, possibly both values were sent as different. (e.g.
> oops, the test was only
>  > considering the first 64 bits. And the error had never been detected so
> far, because the
>  > first 64 bits had been different during testing, or the duplicate
> silently removed))
>  > >
>  > > --Bruno
>  > >
>  > >> (The same would apply to the canonical
>  > >> representation item if there were to be debate about it.)
>  > >>
>  > >> --John
>  > >> _______________________________________________
>  > >> Idr mailing list
>  > >> Idr@ietf.org
>  > >> https://www.ietf.org/mailman/listinfo/idr
>  > >
>  > >
>  > ____________________________________________________________
> _____________
>  > ________________________________________________
>  > >
>  > > Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou
>  > privilegiees et ne doivent donc
>  > > pas etre diffuses, exploites ou copies sans autorisation. Si vous
> avez recu ce message
>  > par erreur, veuillez le signaler
>  > > a l'expediteur et le detruire ainsi que les pieces jointes. Les
> messages electroniques
>  > etant susceptibles d'alteration,
>  > > Orange decline toute responsabilite si ce message a ete altere,
> deforme ou falsifie.
>  > Merci.
>  > >
>  > > This message and its attachments may contain confidential or
> privileged information
>  > that may be protected by law;
>  > > they should not be distributed, used or copied without authorisation.
>  > > If you have received this email in error, please notify the sender
> and delete this
>  > message and its attachments.
>  > > As emails may be altered, Orange is not liable for messages that have
> been modified,
>  > changed or falsified.
>  > > Thank you.
>  > >
>  > > _______________________________________________
>  > > Idr mailing list
>  > > Idr@ietf.org
>  > > https://www.ietf.org/mailman/listinfo/idr
>
> ____________________________________________________________
> _____________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>

--047d7bd6bc9ca5150f054157a464
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Bruno,


Since I was going to ask the same question let me provide an=
 example:


AS1 ---- AS2 ---- AS3 ---- peer_X


AS3 publishes community with action if I receive this commun=
ity I will PREPEND my AS# one time towards my peer X.


Now AS1 comes with a need for such prepend on PI prefix P. T=
hen AS2 for perhaps completely different reason also comes up with idea to =
hint AS3 to execute prepend on the same very prefix P.


So AS3 is receiving the two communities which both are valid=
 and truely intended. Why we would drop it ?


I admit when the topic came up originally the major concern =
to me was to prevent stuffing community with N identical sets of values by =
same AS. 


But even this case can be legitimate. Let's consider tha=
t said AS2=C2=A0 needs prepend by 2 to some prefixes and AS3 offers *only* =
community of single PREPEND. Why not adding it twice to such selected prefi=
xes not be a way to signal such requirement ?


Regards,

R.



On Nov 15, 2016 1=
0:46 PM,  <bruno.decraene@o=
range.com> wrote:
TL;DR: I'm fine with -08 (MUST NOT send, MUST de-duplicate). I'=
;m not fine with -06, unless some text is added, because it may open differ=
ent interpretation.



> From: Jakob Heitz (jheitz) [mailto:jheitz@cisco.com]=C2=A0 > Sent: Tuesday, November 15, 2016 12:00 AM=


>

=C2=A0> Receipt of a duplicate MUST NOT trigger any error handling. It i=
s not a protocol error. It

=C2=A0> MUST NOT cause treat-as-withdraw and MUST NOT cause attribute di=
scard. Simply

=C2=A0> deleting the duplicate is enough. Even a log of the deletion is =
noise. Log it if you must, but

=C2=A0> my code does not. This is consistent with legacy community handl=
ing.

=C2=A0>

=C2=A0> Therefore, I support SHOULD.



If you believe that this is not an error, there is no need for specific act=
ion, not to mention trying to correct the .... error. ("SHOULD remove =
the duplicate" is trying to correct it).



Taking a step back, I think that what we really must specify, is whether a =
community received N times, MUST be considered as received N times or 1 tim=
e, because this impacts the meaning, hence the interop. e.g. if the communi=
ty means prepend one, does sending it N times means prepend N or prepend 1)=


>From the current text, it seems that people want to only have the commu=
nity interpreted once. (which is a restriction of what we could do).



If so, it seems to never make sense to send the same value multiple times. =
So it seems clearer to completely forbid it (MUST NOT) rather than leaving =
the option to re-open the discussion latter or consider how the receiver ne=
ed to react to "keep the meaning" intended by the originator. Esp=
ecially since some combination seems to make less sense. e.g. "SHOULD =
NOT be sent, SHOULD be removed" where we are opening the option to sen=
d duplicate, but we don't define how such duplicate will propagate, so =
the originator has even less reason to try an innovative unspecified behavi=
or.



Now, if we have "MUST NOT be sent", then I think that this is an =
error condition if we receive duplicate. And I see 3 options:

a) leave them all, (i.e. no correction) but specify that N times as the sam=
e value that 1 time.

b) try to stop the error, by correcting it (i.e. "remove duplicate&quo=
t;) but that seem to assume that the error is on the sending side, while th=
e error could in fact be on the receiving side. It's bothers me a littl=
e that this point had never been discussed by the WG, especially since for =
the receiver (coder), there is a clear bias in favor of trusting itself (hi=
mself). While we had real world example where the error was on the receivin=
g side or at least not on the sending side (e.g. error due to code point co=
llision, e.g. VPN extended community 0x010a, and more recently attributes i=
n draft-ietf-idr-deprecate-30-31-129)

c) try to stop the error, with no assumption on the source of the error, by=
 withdrawing the error (Attribute discard or Treat-As-Withdraw). Would be T=
AW in our case.



I had suggested "treat-as-withdraw" as a provocation to trigger t=
he discussion, which had never happened. But personally I don't care mu=
ch on the action, provided that the interpretation is not ambiguous. e.g. M=
UST be considered as received 1 time.



Again, I fine with latest version (-08). I'm less fine with the -06 ver=
sion, especially as the behavior on the receiving side is not strictly defi=
ned and may not be interoperable (-06 allows keeping duplicate while not de=
fining its meaning)



Thanks,

--Bruno



=C2=A0> Thanks,

=C2=A0> Jakob.

=C2=A0>

=C2=A0>

=C2=A0> > On Nov 15, 2016, at 6:39 AM, "bruno.decraene@orange.com"

=C2=A0> <bruno.decraene@=
orange.com> wrote:

=C2=A0> >

=C2=A0> > John, Sue,

=C2=A0> >

=C2=A0> >> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of John G. Scudder=C2=A0 > Sent: =
Monday,

=C2=A0> November 14, 2016 7:50 PM

=C2=A0> >>

=C2=A0> >> In my role as co-chair:

=C2=A0> >>

=C2=A0> >>> On Nov 14, 2016, at 6:10 PM, John G. Scudder <jgs@juniper.net> wrote:

=C2=A0> >>> Please raise any objections by November 21. In this=
 case, silence will be taken as

=C2=A0> >> consent assuming you've already supported publicati=
on.

=C2=A0> >>

=C2=A0> >> Given there's debate regarding the SHOULD/MUST chan=
ge, I think it's not appropriate

=C2=A0> to

=C2=A0> >> assume silence gives consent to the change. So, I take =
that back and expect we will

=C2=A0> judge

=C2=A0> >> consensus for this item in the usual way.

=C2=A0> >

=C2=A0> > 1) I support the "MUST".

=C2=A0> > In addition to the reasons already provided, IMHO, I would =
say that this also seems

=C2=A0> aligned with RFC 7606. (but I would prefer not to re-open the 76=
06 error handling debate).

=C2=A0> >

=C2=A0> > 2) If "MUST" is kept, on a side note,

=C2=A0> >

=C2=A0> > - I'm less sure about the "silently" part of =
"MUST silently" as I'm not sure why logging

=C2=A0> the error should be considered as a protocol violation. (and 760=
6 was rather calling for

=C2=A0> logging the error). So I would propose to remove "silently.=


=C2=A0> >

=C2=A0> > - If we now have ' Duplicate BGP Large Community values=
 MUST NOT be transmitted.',

=C2=A0> receiving a duplicate is a clear protocol error. In the general =
case, it's difficult to know

=C2=A0> whether the error is on the sending side or the receiving side. =
(Although the receiving side

=C2=A0> will typically consider that he is (obviously always) right, hen=
ce the sender must be in

=C2=A0> error). Given that large community has an impact on route prefer=
ence or selection, this

=C2=A0> may call for "treat-as-withdraw"...

=C2=A0> > I already hear the objection that "both value are the =
same hence it has no influence",

=C2=A0> but it's the receiver which claims that both value are the s=
ame. If the error is on the

=C2=A0> receiving side, possibly both values were sent as different. (e.=
g. oops, the test was only

=C2=A0> considering the first 64 bits. And the error had never been dete=
cted so far, because the

=C2=A0> first 64 bits had been different during testing, or the duplicat=
e silently removed))

=C2=A0> >

=C2=A0> > --Bruno

=C2=A0> >

=C2=A0> >> (The same would apply to the canonical

=C2=A0> >> representation item if there were to be debate about it=
.)

=C2=A0> >>

=C2=A0> >> --John

=C2=A0> >> _______________________________________________
=C2=A0> >> Idr mailing list

=C2=A0> >> Idr@ietf.org

=C2=A0> >> https://www.ietf.org/mailman/listi=
nfo/idr

=C2=A0> >

=C2=A0> >

=C2=A0> ___________________________________________________________=
______________

=C2=A0> ________________________________________________

=C2=A0> >

=C2=A0> > Ce message et ses pieces jointes peuvent contenir des infor=
mations confidentielles ou

=C2=A0> privilegiees et ne doivent donc

=C2=A0> > pas etre diffuses, exploites ou copies sans autorisation. S=
i vous avez recu ce message

=C2=A0> par erreur, veuillez le signaler

=C2=A0> > a l'expediteur et le detruire ainsi que les pieces join=
tes. Les messages electroniques

=C2=A0> etant susceptibles d'alteration,

=C2=A0> > Orange decline toute responsabilite si ce message a ete alt=
ere, deforme ou falsifie.

=C2=A0> Merci.

=C2=A0> >

=C2=A0> > This message and its attachments may contain confidential o=
r privileged information

=C2=A0> that may be protected by law;

=C2=A0> > they should not be distributed, used or copied without auth=
orisation.

=C2=A0> > If you have received this email in error, please notify the=
 sender and delete this

=C2=A0> message and its attachments.

=C2=A0> > As emails may be altered, Orange is not liable for messages=
 that have been modified,

=C2=A0> changed or falsified.

=C2=A0> > Thank you.

=C2=A0> >

=C2=A0> > _______________________________________________

=C2=A0> > Idr mailing list

=C2=A0> > Idr@ietf.org

=C2=A0> > https://www.ietf.org/mailman/listinf=
o/idr



_________________________________________________________________=
________________________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les message=
s electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.



This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and dele=
te this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.

Thank you.



_______________________________________________

Idr mailing list

Idr@ietf.org

https://www.ietf.org/mailman/listinfo/idr




--047d7bd6bc9ca5150f054157a464--


From nobody Tue Nov 15 06:28:44 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D1481296B9 for ; Tue, 15 Nov 2016 06:28:40 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZMl9ZIBegRKm for ; Tue, 15 Nov 2016 06:28:36 -0800 (PST)
Received: from mail.i3d.net (mail.i3d.nl [213.163.77.240]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDA0A126BF7 for ; Tue, 15 Nov 2016 06:28:35 -0800 (PST)
X-Footer: aTNkLm5s
Received: from localhost ([127.0.0.1]) by mail.i3d.net with ESMTPSA (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128 bits)); Tue, 15 Nov 2016 15:28:30 +0100
To: Robert Raszuk , bruno.decraene@orange.com
References:   <27701_1479159582_582A2F1E_27701_6903_1_53C29892C857584299CBF5D05346208A1EC77FE1@OPEXCLILM21.corporate.adroot.infra.ftgroup> <736EA2CC-3DD1-4F14-96ED-2916E62F6F02@cisco.com> <26709_1479217575_582B11A7_26709_12999_1_53C29892C857584299CBF5D05346208A1EC79584@OPEXCLILM21.corporate.adroot.infra.ftgroup> 
From: "i3D.net - Martijn Schmidt" 
Organization: i3D.net
Message-ID: 
Date: Tue, 15 Nov 2016 15:28:32 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------C0649810195E90C0C198F652"
Archived-At: 
Cc: idr wg 
Subject: Re: [Idr] One week extension to WGLC for draft-ietf-idr-large-community
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, 15 Nov 2016 14:28:40 -0000

This is a multi-part message in MIME format.
--------------C0649810195E90C0C198F652
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit

Hi Robert,

Route-maps don't work that way in today's router software, every clause
is evaluated once and then the route-map execution either stops (if no
continue statement is given) or proceeds to the next clause (if a
continue statement is given). Either way, the community will only be
matched once even if it's been tagged twice on the same prefix.

Best regards,
Martijn

On 11/15/2016 03:19 PM, Robert Raszuk wrote:
>
> Hi Bruno,
>
> Since I was going to ask the same question let me provide an example:
>
> AS1 ---- AS2 ---- AS3 ---- peer_X
>
> AS3 publishes community with action if I receive this community I will
> PREPEND my AS# one time towards my peer X.
>
> Now AS1 comes with a need for such prepend on PI prefix P. Then AS2
> for perhaps completely different reason also comes up with idea to
> hint AS3 to execute prepend on the same very prefix P.
>
> So AS3 is receiving the two communities which both are valid and
> truely intended. Why we would drop it ?
>
> I admit when the topic came up originally the major concern to me was
> to prevent stuffing community with N identical sets of values by same AS.
>
> But even this case can be legitimate. Let's consider that said AS2 
> needs prepend by 2 to some prefixes and AS3 offers *only* community of
> single PREPEND. Why not adding it twice to such selected prefixes not
> be a way to signal such requirement ?
>
> Regards,
> R.
>
>
> On Nov 15, 2016 10:46 PM,  > wrote:
>
>     TL;DR: I'm fine with -08 (MUST NOT send, MUST de-duplicate). I'm
>     not fine with -06, unless some text is added, because it may open
>     different interpretation.
>
>     > From: Jakob Heitz (jheitz) [mailto:jheitz@cisco.com
>     ]  > Sent: Tuesday, November 15, 2016
>     12:00 AM
>     >
>      > Receipt of a duplicate MUST NOT trigger any error handling. It
>     is not a protocol error. It
>      > MUST NOT cause treat-as-withdraw and MUST NOT cause attribute
>     discard. Simply
>      > deleting the duplicate is enough. Even a log of the deletion is
>     noise. Log it if you must, but
>      > my code does not. This is consistent with legacy community
>     handling.
>      >
>      > Therefore, I support SHOULD.
>
>     If you believe that this is not an error, there is no need for
>     specific action, not to mention trying to correct the .... error.
>     ("SHOULD remove the duplicate" is trying to correct it).
>
>     Taking a step back, I think that what we really must specify, is
>     whether a community received N times, MUST be considered as
>     received N times or 1 time, because this impacts the meaning,
>     hence the interop. e.g. if the community means prepend one, does
>     sending it N times means prepend N or prepend 1)
>     >From the current text, it seems that people want to only have the
>     community interpreted once. (which is a restriction of what we
>     could do).
>
>     If so, it seems to never make sense to send the same value
>     multiple times. So it seems clearer to completely forbid it (MUST
>     NOT) rather than leaving the option to re-open the discussion
>     latter or consider how the receiver need to react to "keep the
>     meaning" intended by the originator. Especially since some
>     combination seems to make less sense. e.g. "SHOULD NOT be sent,
>     SHOULD be removed" where we are opening the option to send
>     duplicate, but we don't define how such duplicate will propagate,
>     so the originator has even less reason to try an innovative
>     unspecified behavior.
>
>     Now, if we have "MUST NOT be sent", then I think that this is an
>     error condition if we receive duplicate. And I see 3 options:
>     a) leave them all, (i.e. no correction) but specify that N times
>     as the same value that 1 time.
>     b) try to stop the error, by correcting it (i.e. "remove
>     duplicate") but that seem to assume that the error is on the
>     sending side, while the error could in fact be on the receiving
>     side. It's bothers me a little that this point had never been
>     discussed by the WG, especially since for the receiver (coder),
>     there is a clear bias in favor of trusting itself (himself). While
>     we had real world example where the error was on the receiving
>     side or at least not on the sending side (e.g. error due to code
>     point collision, e.g. VPN extended community 0x010a, and more
>     recently attributes in draft-ietf-idr-deprecate-30-31-129)
>     c) try to stop the error, with no assumption on the source of the
>     error, by withdrawing the error (Attribute discard or
>     Treat-As-Withdraw). Would be TAW in our case.
>
>     I had suggested "treat-as-withdraw" as a provocation to trigger
>     the discussion, which had never happened. But personally I don't
>     care much on the action, provided that the interpretation is not
>     ambiguous. e.g. MUST be considered as received 1 time.
>
>     Again, I fine with latest version (-08). I'm less fine with the
>     -06 version, especially as the behavior on the receiving side is
>     not strictly defined and may not be interoperable (-06 allows
>     keeping duplicate while not defining its meaning)
>
>     Thanks,
>     --Bruno
>
>      > Thanks,
>      > Jakob.
>      >
>      >
>      > > On Nov 15, 2016, at 6:39 AM, "bruno.decraene@orange.com
>     "
>      > >
>     wrote:
>      > >
>      > > John, Sue,
>      > >
>      > >> From: Idr [mailto:idr-bounces@ietf.org
>     ] On Behalf Of John G. Scudder  >
>     Sent: Monday,
>      > November 14, 2016 7:50 PM
>      > >>
>      > >> In my role as co-chair:
>      > >>
>      > >>> On Nov 14, 2016, at 6:10 PM, John G. Scudder
>     > wrote:
>      > >>> Please raise any objections by November 21. In this case,
>     silence will be taken as
>      > >> consent assuming you've already supported publication.
>      > >>
>      > >> Given there's debate regarding the SHOULD/MUST change, I
>     think it's not appropriate
>      > to
>      > >> assume silence gives consent to the change. So, I take that
>     back and expect we will
>      > judge
>      > >> consensus for this item in the usual way.
>      > >
>      > > 1) I support the "MUST".
>      > > In addition to the reasons already provided, IMHO, I would
>     say that this also seems
>      > aligned with RFC 7606. (but I would prefer not to re-open the
>     7606 error handling debate).
>      > >
>      > > 2) If "MUST" is kept, on a side note,
>      > >
>      > > - I'm less sure about the "silently" part of "MUST silently"
>     as I'm not sure why logging
>      > the error should be considered as a protocol violation. (and
>     7606 was rather calling for
>      > logging the error). So I would propose to remove "silently.
>      > >
>      > > - If we now have ' Duplicate BGP Large Community values MUST
>     NOT be transmitted.',
>      > receiving a duplicate is a clear protocol error. In the general
>     case, it's difficult to know
>      > whether the error is on the sending side or the receiving side.
>     (Although the receiving side
>      > will typically consider that he is (obviously always) right,
>     hence the sender must be in
>      > error). Given that large community has an impact on route
>     preference or selection, this
>      > may call for "treat-as-withdraw"...
>      > > I already hear the objection that "both value are the same
>     hence it has no influence",
>      > but it's the receiver which claims that both value are the
>     same. If the error is on the
>      > receiving side, possibly both values were sent as different.
>     (e.g. oops, the test was only
>      > considering the first 64 bits. And the error had never been
>     detected so far, because the
>      > first 64 bits had been different during testing, or the
>     duplicate silently removed))
>      > >
>      > > --Bruno
>      > >
>      > >> (The same would apply to the canonical
>      > >> representation item if there were to be debate about it.)
>      > >>
>      > >> --John
>      > >> _______________________________________________
>      > >> Idr mailing list
>      > >> Idr@ietf.org 
>      > >> https://www.ietf.org/mailman/listinfo/idr
>     
>      > >
>      > >
>      >
>     _________________________________________________________________________
>      > ________________________________________________
>      > >
>      > > Ce message et ses pieces jointes peuvent contenir des
>     informations confidentielles ou
>      > privilegiees et ne doivent donc
>      > > pas etre diffuses, exploites ou copies sans autorisation. Si
>     vous avez recu ce message
>      > par erreur, veuillez le signaler
>      > > a l'expediteur et le detruire ainsi que les pieces jointes.
>     Les messages electroniques
>      > etant susceptibles d'alteration,
>      > > Orange decline toute responsabilite si ce message a ete
>     altere, deforme ou falsifie.
>      > Merci.
>      > >
>      > > This message and its attachments may contain confidential or
>     privileged information
>      > that may be protected by law;
>      > > they should not be distributed, used or copied without
>     authorisation.
>      > > If you have received this email in error, please notify the
>     sender and delete this
>      > message and its attachments.
>      > > As emails may be altered, Orange is not liable for messages
>     that have been modified,
>      > changed or falsified.
>      > > Thank you.
>      > >
>      > > _______________________________________________
>      > > Idr mailing list
>      > > Idr@ietf.org 
>      > > https://www.ietf.org/mailman/listinfo/idr
>     
>
>     _________________________________________________________________________________________________________________________
>
>     Ce message et ses pieces jointes peuvent contenir des informations
>     confidentielles ou privilegiees et ne doivent donc
>     pas etre diffuses, exploites ou copies sans autorisation. Si vous
>     avez recu ce message par erreur, veuillez le signaler
>     a l'expediteur et le detruire ainsi que les pieces jointes. Les
>     messages electroniques etant susceptibles d'alteration,
>     Orange decline toute responsabilite si ce message a ete altere,
>     deforme ou falsifie. Merci.
>
>     This message and its attachments may contain confidential or
>     privileged information that may be protected by law;
>     they should not be distributed, used or copied without authorisation.
>     If you have received this email in error, please notify the sender
>     and delete this message and its attachments.
>     As emails may be altered, Orange is not liable for messages that
>     have been modified, changed or falsified.
>     Thank you.
>
>     _______________________________________________
>     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

-- 
Met vriendelijke groet / Kindest regards,
Martijn Schmidt


i3D.net performance hosting 	
*Martijn Schmidt | Network Architect*
Email: martijnschmidt@i3d.net  | Tel:
+31 10 8900070

*i3D.net B.V. | Global Backbone AS49544*
Van Nelleweg 1, 3044 BC Rotterdam, The Netherlands
VAT: NL 8202.63.886.B01

Website

| Case Studies

| LinkedIn 
	


--------------C0649810195E90C0C198F652
Content-Type: multipart/related;
 boundary="------------53E1BA8499B15D93BB67BFDC"


--------------53E1BA8499B15D93BB67BFDC
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    Hi Robert,

    

    Route-maps don't work that way in today's router software, every
    clause is evaluated once and then the route-map execution either
    stops (if no continue statement is given) or proceeds to the next
    clause (if a continue statement is given). Either way, the community
    will only be matched once even if it's been tagged twice on the same
    prefix.

    

    Best regards,

    Martijn

    

    
On 11/15/2016 03:19 PM, Robert Raszuk
      wrote:

    

    

      
Hi Bruno,

      
Since I was going to ask the same question let me
        provide an example:

      
AS1 ---- AS2 ---- AS3 ---- peer_X

      
AS3 publishes community with action if I receive this
        community I will PREPEND my AS# one time towards my peer X.

      
Now AS1 comes with a need for such prepend on PI
        prefix P. Then AS2 for perhaps completely different reason also
        comes up with idea to hint AS3 to execute prepend on the same
        very prefix P.

      
So AS3 is receiving the two communities which both
        are valid and truely intended. Why we would drop it ?

      
I admit when the topic came up originally the major
        concern to me was to prevent stuffing community with N identical
        sets of values by same AS. 

      
But even this case can be legitimate. Let's consider
        that said AS2  needs prepend by 2 to some prefixes and AS3
        offers *only* community of single PREPEND. Why not adding it
        twice to such selected prefixes not be a way to signal such
        requirement ?

      
Regards,

        R.

      


        
On Nov 15, 2016 10:46 PM, <bruno.decraene@orange.com>
          wrote:

          
TL;DR: I'm
            fine with -08 (MUST NOT send, MUST de-duplicate). I'm not
            fine with -06, unless some text is added, because it may
            open different interpretation.

            

            > From: Jakob Heitz (jheitz) [mailto:jheitz@cisco.com] 
            > Sent: Tuesday, November 15, 2016 12:00 AM

            >

             > Receipt of a duplicate MUST NOT trigger any error
            handling. It is not a protocol error. It

             > MUST NOT cause treat-as-withdraw and MUST NOT cause
            attribute discard. Simply

             > deleting the duplicate is enough. Even a log of the
            deletion is noise. Log it if you must, but

             > my code does not. This is consistent with legacy
            community handling.

             >

             > Therefore, I support SHOULD.

            

            If you believe that this is not an error, there is no need
            for specific action, not to mention trying to correct the
            .... error. ("SHOULD remove the duplicate" is trying to
            correct it).

            

            Taking a step back, I think that what we really must
            specify, is whether a community received N times, MUST be
            considered as received N times or 1 time, because this
            impacts the meaning, hence the interop. e.g. if the
            community means prepend one, does sending it N times means
            prepend N or prepend 1)

            >From the current text, it seems that people want to only
            have the community interpreted once. (which is a restriction
            of what we could do).

            

            If so, it seems to never make sense to send the same value
            multiple times. So it seems clearer to completely forbid it
            (MUST NOT) rather than leaving the option to re-open the
            discussion latter or consider how the receiver need to react
            to "keep the meaning" intended by the originator. Especially
            since some combination seems to make less sense. e.g.
            "SHOULD NOT be sent, SHOULD be removed" where we are opening
            the option to send duplicate, but we don't define how such
            duplicate will propagate, so the originator has even less
            reason to try an innovative unspecified behavior.

            

            Now, if we have "MUST NOT be sent", then I think that this
            is an error condition if we receive duplicate. And I see 3
            options:

            a) leave them all, (i.e. no correction) but specify that N
            times as the same value that 1 time.

            b) try to stop the error, by correcting it (i.e. "remove
            duplicate") but that seem to assume that the error is on the
            sending side, while the error could in fact be on the
            receiving side. It's bothers me a little that this point had
            never been discussed by the WG, especially since for the
            receiver (coder), there is a clear bias in favor of trusting
            itself (himself). While we had real world example where the
            error was on the receiving side or at least not on the
            sending side (e.g. error due to code point collision, e.g.
            VPN extended community 0x010a, and more recently attributes
            in draft-ietf-idr-deprecate-30-31-129)

            c) try to stop the error, with no assumption on the source
            of the error, by withdrawing the error (Attribute discard or
            Treat-As-Withdraw). Would be TAW in our case.

            

            I had suggested "treat-as-withdraw" as a provocation to
            trigger the discussion, which had never happened. But
            personally I don't care much on the action, provided that
            the interpretation is not ambiguous. e.g. MUST be considered
            as received 1 time.

            

            Again, I fine with latest version (-08). I'm less fine with
            the -06 version, especially as the behavior on the receiving
            side is not strictly defined and may not be interoperable
            (-06 allows keeping duplicate while not defining its
            meaning)

            

            Thanks,

            --Bruno

            

             > Thanks,

             > Jakob.

             >

             >

             > > On Nov 15, 2016, at 6:39 AM, "bruno.decraene@orange.com"

             > <bruno.decraene@orange.com>
            wrote:

             > >

             > > John, Sue,

             > >

             > >> From: Idr [mailto:idr-bounces@ietf.org]
            On Behalf Of John G. Scudder  > Sent: Monday,

             > November 14, 2016 7:50 PM

             > >>

             > >> In my role as co-chair:

             > >>

             > >>> On Nov 14, 2016, at 6:10 PM, John G.
            Scudder <jgs@juniper.net>
            wrote:

             > >>> Please raise any objections by November
            21. In this case, silence will be taken as

             > >> consent assuming you've already supported
            publication.

             > >>

             > >> Given there's debate regarding the
            SHOULD/MUST change, I think it's not appropriate

             > to

             > >> assume silence gives consent to the change.
            So, I take that back and expect we will

             > judge

             > >> consensus for this item in the usual way.

             > >

             > > 1) I support the "MUST".

             > > In addition to the reasons already provided,
            IMHO, I would say that this also seems

             > aligned with RFC 7606. (but I would prefer not to
            re-open the 7606 error handling debate).

             > >

             > > 2) If "MUST" is kept, on a side note,

             > >

             > > - I'm less sure about the "silently" part of
            "MUST silently" as I'm not sure why logging

             > the error should be considered as a protocol
            violation. (and 7606 was rather calling for

             > logging the error). So I would propose to remove
            "silently.

             > >

             > > - If we now have ' Duplicate BGP Large Community
            values MUST NOT be transmitted.',

             > receiving a duplicate is a clear protocol error. In
            the general case, it's difficult to know

             > whether the error is on the sending side or the
            receiving side. (Although the receiving side

             > will typically consider that he is (obviously always)
            right, hence the sender must be in

             > error). Given that large community has an impact on
            route preference or selection, this

             > may call for "treat-as-withdraw"...

             > > I already hear the objection that "both value are
            the same hence it has no influence",

             > but it's the receiver which claims that both value are
            the same. If the error is on the

             > receiving side, possibly both values were sent as
            different. (e.g. oops, the test was only

             > considering the first 64 bits. And the error had never
            been detected so far, because the

             > first 64 bits had been different during testing, or
            the duplicate silently removed))

             > >

             > > --Bruno

             > >

             > >> (The same would apply to the canonical

             > >> representation item if there were to be
            debate about it.)

             > >>

             > >> --John

             > >> _______________________________________________

             > >> Idr mailing list

             > >> Idr@ietf.org

             > >> https://www.ietf.org/mailman/listinfo/idr

             > >

             > >

             > _________________________________________________________________________

             > ________________________________________________

             > >

             > > Ce message et ses pieces jointes peuvent contenir
            des informations confidentielles ou

             > privilegiees et ne doivent donc

             > > pas etre diffuses, exploites ou copies sans
            autorisation. Si vous avez recu ce message

             > par erreur, veuillez le signaler

             > > a l'expediteur et le detruire ainsi que les
            pieces jointes. Les messages electroniques

             > etant susceptibles d'alteration,

             > > Orange decline toute responsabilite si ce message
            a ete altere, deforme ou falsifie.

             > Merci.

             > >

             > > This message and its attachments may contain
            confidential or privileged information

             > that may be protected by law;

             > > they should not be distributed, used or copied
            without authorisation.

             > > If you have received this email in error, please
            notify the sender and delete this

             > message and its attachments.

             > > As emails may be altered, Orange is not liable
            for messages that have been modified,

             > changed or falsified.

             > > Thank you.

             > >

             > > _______________________________________________

             > > Idr mailing list

             > > Idr@ietf.org

             > > https://www.ietf.org/mailman/listinfo/idr

            

            _________________________________________________________________________________________________________________________

            

            Ce message et ses pieces jointes peuvent contenir des
            informations confidentielles ou privilegiees et ne doivent
            donc

            pas etre diffuses, exploites ou copies sans autorisation. Si
            vous avez recu ce message par erreur, veuillez le signaler

            a l'expediteur et le detruire ainsi que les pieces jointes.
            Les messages electroniques etant susceptibles d'alteration,

            Orange decline toute responsabilite si ce message a ete
            altere, deforme ou falsifie. Merci.

            

            This message and its attachments may contain confidential or
            privileged information that may be protected by law;

            they should not be distributed, used or copied without
            authorisation.

            If you have received this email in error, please notify the
            sender and delete this message and its attachments.

            As emails may be altered, Orange is not liable for messages
            that have been modified, changed or falsified.

            Thank you.

            

            _______________________________________________

            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


    

    

    
-- 

      
Met vriendelijke groet / Kindest regards,
        

        Martijn Schmidt

      

      

      

        
          

            
              i3D.net performance hosting
            
            
              

                Martijn Schmidt | Network
                  Architect

                Email: martijnschmidt@i3d.net
                | Tel: +31 10 8900070

                

                i3D.net B.V. | Global Backbone AS49544

                Van Nelleweg 1, 3044 BC Rotterdam, The Netherlands

                VAT: NL 8202.63.886.B01

                

                Website
                |
                Case
                  Studies |
                LinkedIn
              

            		
            
              

            		
          

        
      

    

  


--------------53E1BA8499B15D93BB67BFDC
Content-Type: image/png;
 name="i3Dlogo-email.png"
Content-Transfer-Encoding: base64
Content-ID: 
Content-Disposition: inline;
 filename="i3Dlogo-email.png"

iVBORw0KGgoAAAANSUhEUgAAAOkAAACCCAMAAACU2h9IAAAAGXRFWHRTb2Z0d2FyZQBBZG9i
ZSBJbWFnZVJlYWR5ccllPAAAA0xpVFh0WE1MOmNvbS5hZG9iZS54bXAAAAAAADw/eHBhY2tl
dCBiZWdpbj0i77u/IiBpZD0iVzVNME1wQ2VoaUh6cmVTek5UY3prYzlkIj8+IDx4OnhtcG1l
dGEgeG1sbnM6eD0iYWRvYmU6bnM6bWV0YS8iIHg6eG1wdGs9IkFkb2JlIFhNUCBDb3JlIDUu
Ni1jMTMyIDc5LjE1OTI4NCwgMjAxNi8wNC8xOS0xMzoxMzo0MCAgICAgICAgIj4gPHJkZjpS
REYgeG1sbnM6cmRmPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgt
bnMjIj4gPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIgeG1sbnM6eG1wTU09Imh0dHA6
Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9tbS8iIHhtbG5zOnN0UmVmPSJodHRwOi8vbnMuYWRv
YmUuY29tL3hhcC8xLjAvc1R5cGUvUmVzb3VyY2VSZWYjIiB4bWxuczp4bXA9Imh0dHA6Ly9u
cy5hZG9iZS5jb20veGFwLzEuMC8iIHhtcE1NOkRvY3VtZW50SUQ9InhtcC5kaWQ6MEM3NkQ1
NTY3NkE4MTFFNkI0OTI5NERBQkYxNEIxQUEiIHhtcE1NOkluc3RhbmNlSUQ9InhtcC5paWQ6
MEM3NkQ1NTU3NkE4MTFFNkI0OTI5NERBQkYxNEIxQUEiIHhtcDpDcmVhdG9yVG9vbD0iQWRv
YmUgUGhvdG9zaG9wIENDIDIwMTUuNSAoV2luZG93cykiPiA8eG1wTU06RGVyaXZlZEZyb20g
c3RSZWY6aW5zdGFuY2VJRD0iYWRvYmU6ZG9jaWQ6cGhvdG9zaG9wOmYwMGZmMDc1LTc2YTUt
MTFlNi1iZDIzLWJhYTI4MGRmODBkYyIgc3RSZWY6ZG9jdW1lbnRJRD0iYWRvYmU6ZG9jaWQ6
cGhvdG9zaG9wOmYwMGZmMDc1LTc2YTUtMTFlNi1iZDIzLWJhYTI4MGRmODBkYyIvPiA8L3Jk
ZjpEZXNjcmlwdGlvbj4gPC9yZGY6UkRGPiA8L3g6eG1wbWV0YT4gPD94cGFja2V0IGVuZD0i
ciI/Pu9aRCwAAABgUExURf7+/uuxsufn5+ONj9nZ2fPz86qqq5SUlWNjZHt7fM/Pz7i4uFZW
V4aGh0FBQsPDw0pKS/TU1T8/QN93efv29ttmaW9vcNU+Q/nq6vHIydhTV/bf4OijpNIjKkBA
Qf///zh9ticAAAfaSURBVHja7Nxro3ssAABw5n4dj+x66Pt/ywddFEr6m5mtN8fZWvVDqYQB
vyUYP+lP+rnSug+hIA4I3cCPs7pOszjwopMoLb+eDll8SVz7Hfs0rf8z1KVhkg1K7rvOIikK
cWLvWhpOFj9zwWJpEy72bqUgER6hUENap56xT+lJUvbU1ZA2Z76zR+kplhba1ZFuS1WUOvFM
oSMdaX0xdicN5sqcnXSktbc3abT48ChKU3tfUiNWKHSkI62DfUkjpebF0JHW9luk5z44y4sd
akmTt0gFcexx9cqymTLz0hiHLB03ZWBHUm9QNq/toYPzsD3ODKGUHm7D9jLZqfBm6eD4nETV
156XTvRBvP1IAXfKpSfhwXaVpNBO39L6Kkht4SFwMmFFlUgH3ZB4P9JIfFXghze+ovTMnwpg
N1JX2OwMdkKsKHV46Wk3Uq42XiQndmqoSWH8jsZXQZqI24/B0XEUpf5OpYG4S2MIz0Mp5sJ9
eX6D1O4DUJLC9EOl02WTSbOf9OBS58OlkceESCYFHy6VBU6awuNKDa3e4CdKHeGo5GjSUDjM
OZrUFRb5YFKD86TOcaX8oO0CDyu1M/HU9pGkwOWhsXEw6Tlqg+sG2YK7FR8p9dVusBxXGjtf
Io1P8DukgQO/QhpHBvwKqX+ajXaUY5q560odnwR8wyBC/7V71PPHoY3l+pNh5/XUGY6O3H6a
KhDcovamLwnrt72jlUXrSC/7k9Y+eIUUD492JR1OGq4jxd/tSzr4xUpS741St50LTQJ/tDbD
f4U0FkjTjAmdFG+TywEOa4zaQBSrr9LRlqLbAmNpMDMt6646Encuyqt09KXRHqQQxItX6SyW
JruQDiZBFVfpLJN2Mxnvl/Jzg6qrdBZJu933fumgbQ9eIXX3IY1ecl8GSzNq2oGUX7uSrSsN
6ArKHUgHa1eMVaVeTH67AynUW6WjKPVIh3ArKXCYACYTXnedA5GeSe3fSrr5ig4idVI8cju8
FCdynpLOnGSfJiUVVTZqCw4hDfHI7fhSgJI/HV+KI0ZfIEXEZA/S+rVSG8+cbyTdfCVzL8UP
1CUjaRyQ4K4oVV6dXq+0Or2X4r0cb9RzcEXjFe0nDlL5EweMNBpGfKl09adIwpmnSBjpaVOp
+MkgoPdkUDLzZBAj5U70149lUtFj0qs87XWRSr0tpYNS9zeGz+lrnuBjpedNpaOnMtssjTDR
eCoTnhSeymSlbOv1eun4SdssjtNFT9riW9RxpvKkLStlexkbzK6oPBC/4tPTnNTbVOqqFDnW
eyI+nJGGm0rB695ycIEzUiPbUqrymgN/vTdXcFKmT7+F1LgsLfK/vI3EmVq4stV874veMEPX
gdhoYBJOSO0paT+WaYK96sy2nS07NkrSfl3lmd1fvLRv+WXrHFacw7clR1X3TVB9x1ImTTaW
Qkf45iC9t3vVCdNnkEmjraVNcabf2OY5UEPqcznIpKftpdA4B8NOoN5b+LJkkL5MStPaUNp2
Is4eXouUxpdk+ZsV68wP3HDU15VKvfWlzD01+QvGjNH9kFGtFgRxgn2uxuCOC2DKBCbSNMb5
ghkpPHL4SX/Sn/Qn3am06kJpNm10RQLZfFhty00+NZvtm3WtrtYN8jGKZqtoUzPRryHMK/IR
+SX6ApglziwnyRaoIM1W3v/p8+k2u2zMqv8JitZu38ZJS6VNHDCWVtUVcNLbFX1642MUBEg3
ulI9iNSi0pJmJpUy+Tyv5BfTUhMnDfqkZ6TNTyak1R8ntfCmxcfogM8mtQcnrYi0Arg4Zp+W
VMrkU9BfTEutcdJiaQ5Bk3RJMqP5gqL9dPAxypGP0ZXmTlj04JKid991XzQfW93BKTope6Jx
0j4fQDZLNhYjfeCkS5J0KZWifIdSeO9NkNQ+8iUbo8D78kmlTb4Fgyc7vudIpUw+/aZAWoFR
0hrSfFaa91ILuck5W1q0JWoq3L9Ki6IQSe+bS8u2rlxRjObgWiZticq2EmtKb7he8LF66aNp
J7aVFu1fq/3TxmgOrnlHVaZts6pBcfI8V5W2jRzTnI6kFmpfuNZEQ9o1HVIpitE2NO1xK9o/
FWp6zT7ys5oojqrU7JvnKWnzNVgipW0vafa7T28luVzhFmckxTGKLse2wqB2ub1KdDHwZb05
p29TUvaiQC8hA2l3xaFHdSRt0mXaTXo9V7ueFky+JZBIaYwmg+YrE3R/KnSRAa0PlaYtrKkt
7boEhDqSNmf330Jp30dipXc4J70jWLNvrbw7UVGMKzrSqDT3Cp/WOlJEtURS0jaoSkm/Nx/m
m0vqKY1RdJW8NFFdbzpz3e76o9dRwHS9ltZTQjUFUpNPerbt5ZJh66klbZFwjFZatG0sbnjy
7lPanpHenc5VBk0qPXAnekL6XEO6pI/UHsEr6pB2xkdRlOTXcGrHK7e9pomyuU1L4XUN6YLr
KcKYKKc/emoDejrrSvnDOyG1tpbmjLRgKjEzWnuN1HyFdDSWYaSAgV3pgAbTSXGYAYfiWAaW
ZBMIpM9qOExSkvKN5EjKj085aVdfAGlqH1iKe4GkOBrjU5OLNiGF1yXjU1UpP+fASws6ZMn7
uZaCnE6P4cSA6pwD/sn1KZQWw+kMDSmo8CiE9ii5eSQao8DNUEEvcX9Y+iBSS3seCVgPsjkt
NRXnkeC3hJ/0J/1Jf9Kf9Cd9XfhfgAEA6npi4QQJPOEAAAAASUVORK5CYII=
--------------53E1BA8499B15D93BB67BFDC--

--------------C0649810195E90C0C198F652--


From nobody Tue Nov 15 06:34:55 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27F2612961D for ; Tue, 15 Nov 2016 06:34:54 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] 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 G4MK0LPi3wrB for ; Tue, 15 Nov 2016 06:34:52 -0800 (PST)
Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A04F126BF7 for ; Tue, 15 Nov 2016 06:34:51 -0800 (PST)
Received: by mail-pg0-x22d.google.com with SMTP id x23so64630920pgx.1 for ; Tue, 15 Nov 2016 06:34:51 -0800 (PST)
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=CbjkbcHbQzuE07/aFx7+6JZ2YcUW3trccIsjqeDcNsI=; b=U5GtApScEpkQlQEK0VtsDVM61b0CkvnT3pbrFP6/t2L/XR1c81puTgYrzgsz9BQ/+X d3CGyK4F+sr7OZ4m2t4rc7njr3jv1eSwOPXRI1yEcTgbtVfsfzbjOvW9gnEBFtZSXaLV ZaWx8SGtnKMR+0pYFFpdquZGWDRRmZlWcFd9N1ii9sqpHxeaytWZbWi1UNT+9tmNXNjr usFxUg7LE4BAQOZUQlVpKxMaa6/+wU5uOdpOmlj5V7fvy4BHuMz6dWDADVqXHmAQNHav SZcgduRGg5KytQrUa89rTXyWuXKf74JyCFlSangtPc20EMBUmCj/WiHe8DiA8R6Na1nt EwPg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=CbjkbcHbQzuE07/aFx7+6JZ2YcUW3trccIsjqeDcNsI=; b=Uh0ORnX6Kf0g80O9rGrmH/2XLUmzayxvUPXBkWz1ozJ0y3cDGb6p1iXDS4S9IXy95f B/uq69GI3X12KQCyr9FIvw0Xdad+9xi9PWVNlQ/kO9f7+X2sTOhUE0lTA+b9qkiVjw90 7ZCMg4XAiZmI1zbyGbP4E6NmaVHLil7TQluVUL+kZ5W6+Qc79J6f/z6aAhiLJF6Kd9W7 zVsVKy3AX+c7A/TmSzwsJtOx9Bzr5rIVi3eSDXhaSiJ4bZQqi7lcdDmScexpuQRo8R3t Ag/J/tjwTJ1Tg0m23yQEAZxTFrNqIcR0DFKL6s3XRa+XU+Pp7KcVkMcEQMNsliNvpcAD VSew==
X-Gm-Message-State: ABUngvfCYEyCIueQjqCnD2H8+1SP2TsPzhYPg+ghAZ0ULi5Dy1bDGQIX4rpRVYgPsIVPvg==
X-Received: by 10.99.48.68 with SMTP id w65mr38636067pgw.68.1479220491456; Tue, 15 Nov 2016 06:34:51 -0800 (PST)
Received: from localhost ([2001:67c:370:144:c037:cf52:2860:3776]) by smtp.gmail.com with ESMTPSA id b126sm43581038pfg.90.2016.11.15.06.34.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Nov 2016 06:34:50 -0800 (PST)
Date: Tue, 15 Nov 2016 23:34:43 +0900
From: Job Snijders 
To: Robert Raszuk 
Message-ID: <20161115143443.GP67788@dhcp-9341.meeting.ietf.org>
References:   <27701_1479159582_582A2F1E_27701_6903_1_53C29892C857584299CBF5D05346208A1EC77FE1@OPEXCLILM21.corporate.adroot.infra.ftgroup> <736EA2CC-3DD1-4F14-96ED-2916E62F6F02@cisco.com> <26709_1479217575_582B11A7_26709_12999_1_53C29892C857584299CBF5D05346208A1EC79584@OPEXCLILM21.corporate.adroot.infra.ftgroup> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.7.1 (2016-10-04)
Archived-At: 
Cc: bruno.decraene@orange.com, idr wg 
Subject: Re: [Idr] One week extension to WGLC for draft-ietf-idr-large-community
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, 15 Nov 2016 14:34:54 -0000

On Tue, Nov 15, 2016 at 03:19:22PM +0100, Robert Raszuk wrote:
> Since I was going to ask the same question let me provide an example:
> 
> AS1 ---- AS2 ---- AS3 ---- peer_X
> 
> AS3 publishes community with action if I receive this community I will
> PREPEND my AS# one time towards my peer X.
> 
> Now AS1 comes with a need for such prepend on PI prefix P. Then AS2 for
> perhaps completely different reason also comes up with idea to hint AS3 to
> execute prepend on the same very prefix P.
> 
> So AS3 is receiving the two communities which both are valid and truely
> intended. Why we would drop it ?
> 
> I admit when the topic came up originally the major concern to me was to
> prevent stuffing community with N identical sets of values by same AS.
> 
> But even this case can be legitimate. Let's consider that said AS2  needs
> prepend by 2 to some prefixes and AS3 offers *only* community of single
> PREPEND. Why not adding it twice to such selected prefixes not be a way to
> signal such requirement ?

You copy+pasted what i described as an "abomination implementation" here
https://mailarchive.ietf.org/arch/msg/idr/0Uv77wdj2U_kAskiz8LOqGUIFKc

- Job


From nobody Tue Nov 15 10:09:12 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B03D612940D for ; Tue, 15 Nov 2016 10:09:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level: 
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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 aeJniaz1qkum for ; Tue, 15 Nov 2016 10:09:07 -0800 (PST)
Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c: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 DE4411293E4 for ; Tue, 15 Nov 2016 10:09:06 -0800 (PST)
Received: by mail-wm0-x234.google.com with SMTP id g23so183675427wme.1 for ; Tue, 15 Nov 2016 10:09:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=lRAeLXLDtg/uS/Q8l5akSA3mLYY+ApKIHiiwXB1pnns=; b=PygbZoCR3SYNIiKb3h9otKPLPbJvbYFQ3/tQ3CBSdlyRIPGJlL6qQpZnQqluIHpWtk oFPPRsCx7UjRdhtWvqKxA59iE/HkjnPtLaVOnMFdKZN1JMz1/2k/hJhL7QTP9BFA/pUg fYUMaEugmQpVL8B+zIC4MrQk+oVDYQlNNyNZHvn/WIfssUCXLxuhFmLyMj2SCLyC/5yP B9Bp5IdEtcQNDNhiSeSzoVboWByHhhu8/6Wd4DbhMlLD0DFxqAJOQkHZ+KiZ3MLvezA/ TA8fKkmtrPPC83FUSihbkP7FOt6r9JUL9Bv0MHG7mJnL64jFav83OWYn1+o8TzbOQnna xKQg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=lRAeLXLDtg/uS/Q8l5akSA3mLYY+ApKIHiiwXB1pnns=; b=FX4ZYAKpasMSQA30bW49UvIniuiQL9RP50a6wvH5CVONrWobWG+UHNgQk+cMVyrtNd gYU0oUzaX/UU6NxMt5ToU3zmFcw2uKrPvYyss30LMLaDtfriiGouq1ylcEYphCjjWPo2 v+v8iiSSa2HlDKwAOAChvxFYzjHur9sSVIBM/WwJH+BaSwE/gcVt/QSqz+wFEwzj7+yL qqLLGYUWmc2JZS6EnGZ/tHEFC224fdCNotUh4USh69qcX5wZyRlHfs3Q+Z2LL6rIJNvA mCuoOEgZYpurE5SW6moYea0odfbVTXIzjLBOgcYtvjNiw/BbrjL6x9iIguGWxcI+voFn 0fTg==
X-Gm-Message-State: ABUngve1MVT3gsKTe7mHOrEekW5RGeGjkhgvw/DZ6DqaI3/4bEZMaveLfBpF6slNiELp9WOqVjb/UAcNAkDCAg==
X-Received: by 10.28.196.207 with SMTP id u198mr5064487wmf.102.1479233345343;  Tue, 15 Nov 2016 10:09:05 -0800 (PST)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.80.137.69 with HTTP; Tue, 15 Nov 2016 10:09:03 -0800 (PST)
Received: by 10.80.137.69 with HTTP; Tue, 15 Nov 2016 10:09:03 -0800 (PST)
In-Reply-To: 
References:   <27701_1479159582_582A2F1E_27701_6903_1_53C29892C857584299CBF5D05346208A1EC77FE1@OPEXCLILM21.corporate.adroot.infra.ftgroup> <736EA2CC-3DD1-4F14-96ED-2916E62F6F02@cisco.com> <26709_1479217575_582B11A7_26709_12999_1_53C29892C857584299CBF5D05346208A1EC79584@OPEXCLILM21.corporate.adroot.infra.ftgroup>  
From: Robert Raszuk 
Date: Tue, 15 Nov 2016 19:09:03 +0100
X-Google-Sender-Auth: ny4ui185QxVAXOlTF5Fkrg2XhOY
Message-ID: 
To: "i3D. net - Martijn Schmidt" 
Content-Type: multipart/related; boundary=94eb2c1930f416f34705415ada9b
Archived-At: 
Cc: bruno.decraene@orange.com, idr wg 
Subject: Re: [Idr] One week extension to WGLC for draft-ietf-idr-large-community
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, 15 Nov 2016 18:09:11 -0000

--94eb2c1930f416f34705415ada9b
Content-Type: multipart/alternative; boundary=94eb2c1930f416f34305415ada9a

--94eb2c1930f416f34305415ada9a
Content-Type: text/plain; charset=UTF-8

And what stops you from having a bit smarter clauses where you regex match
on exactly one, two or N occurences of a given community string anywhere in
your received community list following different local PREPEND action ???

Expanded matches for communities have been supported for years.

Thx,
R.

On Nov 15, 2016 11:28 PM, "i3D.net - Martijn Schmidt" <
martijnschmidt@i3d.net> wrote:

> Hi Robert,
>
> Route-maps don't work that way in today's router software, every clause is
> evaluated once and then the route-map execution either stops (if no
> continue statement is given) or proceeds to the next clause (if a continue
> statement is given). Either way, the community will only be matched once
> even if it's been tagged twice on the same prefix.
>
> Best regards,
> Martijn
>
> On 11/15/2016 03:19 PM, Robert Raszuk wrote:
>
> Hi Bruno,
>
> Since I was going to ask the same question let me provide an example:
>
> AS1 ---- AS2 ---- AS3 ---- peer_X
>
> AS3 publishes community with action if I receive this community I will
> PREPEND my AS# one time towards my peer X.
>
> Now AS1 comes with a need for such prepend on PI prefix P. Then AS2 for
> perhaps completely different reason also comes up with idea to hint AS3 to
> execute prepend on the same very prefix P.
>
> So AS3 is receiving the two communities which both are valid and truely
> intended. Why we would drop it ?
>
> I admit when the topic came up originally the major concern to me was to
> prevent stuffing community with N identical sets of values by same AS.
>
> But even this case can be legitimate. Let's consider that said AS2  needs
> prepend by 2 to some prefixes and AS3 offers *only* community of single
> PREPEND. Why not adding it twice to such selected prefixes not be a way to
> signal such requirement ?
>
> Regards,
> R.
>
> On Nov 15, 2016 10:46 PM,  wrote:
>
>> TL;DR: I'm fine with -08 (MUST NOT send, MUST de-duplicate). I'm not fine
>> with -06, unless some text is added, because it may open different
>> interpretation.
>>
>> > From: Jakob Heitz (jheitz) [mailto:jheitz@cisco.com]  > Sent: Tuesday,
>> November 15, 2016 12:00 AM
>> >
>>  > Receipt of a duplicate MUST NOT trigger any error handling. It is not
>> a protocol error. It
>>  > MUST NOT cause treat-as-withdraw and MUST NOT cause attribute discard.
>> Simply
>>  > deleting the duplicate is enough. Even a log of the deletion is noise.
>> Log it if you must, but
>>  > my code does not. This is consistent with legacy community handling.
>>  >
>>  > Therefore, I support SHOULD.
>>
>> If you believe that this is not an error, there is no need for specific
>> action, not to mention trying to correct the .... error. ("SHOULD remove
>> the duplicate" is trying to correct it).
>>
>> Taking a step back, I think that what we really must specify, is whether
>> a community received N times, MUST be considered as received N times or 1
>> time, because this impacts the meaning, hence the interop. e.g. if the
>> community means prepend one, does sending it N times means prepend N or
>> prepend 1)
>> >From the current text, it seems that people want to only have the
>> community interpreted once. (which is a restriction of what we could do).
>>
>> If so, it seems to never make sense to send the same value multiple
>> times. So it seems clearer to completely forbid it (MUST NOT) rather than
>> leaving the option to re-open the discussion latter or consider how the
>> receiver need to react to "keep the meaning" intended by the originator.
>> Especially since some combination seems to make less sense. e.g. "SHOULD
>> NOT be sent, SHOULD be removed" where we are opening the option to send
>> duplicate, but we don't define how such duplicate will propagate, so the
>> originator has even less reason to try an innovative unspecified behavior.
>>
>> Now, if we have "MUST NOT be sent", then I think that this is an error
>> condition if we receive duplicate. And I see 3 options:
>> a) leave them all, (i.e. no correction) but specify that N times as the
>> same value that 1 time.
>> b) try to stop the error, by correcting it (i.e. "remove duplicate") but
>> that seem to assume that the error is on the sending side, while the error
>> could in fact be on the receiving side. It's bothers me a little that this
>> point had never been discussed by the WG, especially since for the receiver
>> (coder), there is a clear bias in favor of trusting itself (himself). While
>> we had real world example where the error was on the receiving side or at
>> least not on the sending side (e.g. error due to code point collision, e.g.
>> VPN extended community 0x010a, and more recently attributes in
>> draft-ietf-idr-deprecate-30-31-129)
>> c) try to stop the error, with no assumption on the source of the error,
>> by withdrawing the error (Attribute discard or Treat-As-Withdraw). Would be
>> TAW in our case.
>>
>> I had suggested "treat-as-withdraw" as a provocation to trigger the
>> discussion, which had never happened. But personally I don't care much on
>> the action, provided that the interpretation is not ambiguous. e.g. MUST be
>> considered as received 1 time.
>>
>> Again, I fine with latest version (-08). I'm less fine with the -06
>> version, especially as the behavior on the receiving side is not strictly
>> defined and may not be interoperable (-06 allows keeping duplicate while
>> not defining its meaning)
>>
>> Thanks,
>> --Bruno
>>
>>  > Thanks,
>>  > Jakob.
>>  >
>>  >
>>  > > On Nov 15, 2016, at 6:39 AM, "bruno.decraene@orange.com"
>>  >  wrote:
>>  > >
>>  > > John, Sue,
>>  > >
>>  > >> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of John G.
>> Scudder  > Sent: Monday,
>>  > November 14, 2016 7:50 PM
>>  > >>
>>  > >> In my role as co-chair:
>>  > >>
>>  > >>> On Nov 14, 2016, at 6:10 PM, John G. Scudder 
>> wrote:
>>  > >>> Please raise any objections by November 21. In this case, silence
>> will be taken as
>>  > >> consent assuming you've already supported publication.
>>  > >>
>>  > >> Given there's debate regarding the SHOULD/MUST change, I think it's
>> not appropriate
>>  > to
>>  > >> assume silence gives consent to the change. So, I take that back
>> and expect we will
>>  > judge
>>  > >> consensus for this item in the usual way.
>>  > >
>>  > > 1) I support the "MUST".
>>  > > In addition to the reasons already provided, IMHO, I would say that
>> this also seems
>>  > aligned with RFC 7606. (but I would prefer not to re-open the 7606
>> error handling debate).
>>  > >
>>  > > 2) If "MUST" is kept, on a side note,
>>  > >
>>  > > - I'm less sure about the "silently" part of "MUST silently" as I'm
>> not sure why logging
>>  > the error should be considered as a protocol violation. (and 7606 was
>> rather calling for
>>  > logging the error). So I would propose to remove "silently.
>>  > >
>>  > > - If we now have ' Duplicate BGP Large Community values MUST NOT be
>> transmitted.',
>>  > receiving a duplicate is a clear protocol error. In the general case,
>> it's difficult to know
>>  > whether the error is on the sending side or the receiving side.
>> (Although the receiving side
>>  > will typically consider that he is (obviously always) right, hence the
>> sender must be in
>>  > error). Given that large community has an impact on route preference
>> or selection, this
>>  > may call for "treat-as-withdraw"...
>>  > > I already hear the objection that "both value are the same hence it
>> has no influence",
>>  > but it's the receiver which claims that both value are the same. If
>> the error is on the
>>  > receiving side, possibly both values were sent as different. (e.g.
>> oops, the test was only
>>  > considering the first 64 bits. And the error had never been detected
>> so far, because the
>>  > first 64 bits had been different during testing, or the duplicate
>> silently removed))
>>  > >
>>  > > --Bruno
>>  > >
>>  > >> (The same would apply to the canonical
>>  > >> representation item if there were to be debate about it.)
>>  > >>
>>  > >> --John
>>  > >> _______________________________________________
>>  > >> Idr mailing list
>>  > >> Idr@ietf.org
>>  > >> https://www.ietf.org/mailman/listinfo/idr
>>  > >
>>  > >
>>  > ____________________________________________________________
>> _____________
>>  > ________________________________________________
>>  > >
>>  > > Ce message et ses pieces jointes peuvent contenir des informations
>> confidentielles ou
>>  > privilegiees et ne doivent donc
>>  > > pas etre diffuses, exploites ou copies sans autorisation. Si vous
>> avez recu ce message
>>  > par erreur, veuillez le signaler
>>  > > a l'expediteur et le detruire ainsi que les pieces jointes. Les
>> messages electroniques
>>  > etant susceptibles d'alteration,
>>  > > Orange decline toute responsabilite si ce message a ete altere,
>> deforme ou falsifie.
>>  > Merci.
>>  > >
>>  > > This message and its attachments may contain confidential or
>> privileged information
>>  > that may be protected by law;
>>  > > they should not be distributed, used or copied without authorisation.
>>  > > If you have received this email in error, please notify the sender
>> and delete this
>>  > message and its attachments.
>>  > > As emails may be altered, Orange is not liable for messages that
>> have been modified,
>>  > changed or falsified.
>>  > > Thank you.
>>  > >
>>  > > _______________________________________________
>>  > > Idr mailing list
>>  > > Idr@ietf.org
>>  > > https://www.ietf.org/mailman/listinfo/idr
>>
>> ____________________________________________________________
>> _____________________________________________________________
>>
>> Ce message et ses pieces jointes peuvent contenir des informations
>> confidentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
>> recu ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
>> electroniques etant susceptibles d'alteration,
>> Orange decline toute responsabilite si ce message a ete altere, deforme
>> ou falsifie. Merci.
>>
>> This message and its attachments may contain confidential or privileged
>> information that may be protected by law;
>> they should not be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender and
>> delete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have
>> been modified, changed or falsified.
>> Thank you.
>>
>> _______________________________________________
>> Idr mailing list
>> Idr@ietf.org
>> https://www.ietf.org/mailman/listinfo/idr
>>
>
>
> _______________________________________________
> Idr mailing listIdr@ietf.orghttps://www.ietf.org/mailman/listinfo/idr
>
>
> --
> Met vriendelijke groet / Kindest regards,
> Martijn Schmidt
>
>
> [image: i3D.net performance hosting]
> *Martijn Schmidt | Network Architect*
> Email: martijnschmidt@i3d.net  | Tel: +31 10
> 8900070
>
> *i3D.net B.V. | Global Backbone AS49544*
> Van Nelleweg 1, 3044 BC Rotterdam, The Netherlands
> VAT: NL 8202.63.886.B01
>
> Website
> 
> | Case Studies
> 
> | LinkedIn 
>
>

--94eb2c1930f416f34305415ada9a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




And what stops you from having a bit smarter clauses where you regex match =
on exactly one, two or N occurences of a given community string anywhere in=
 your received community list following different local PREPEND action ???<=
/p>

Expanded matches for communities have been supported for yea=
rs. 


Thx,

R.



On Nov 15, 2016 1=
1:28 PM, "i3D.net - Martijn Schmidt" <martijnschmidt@i3d.net> wrote:

 =20
   =20
 =20
  

    Hi Robert,

    

    Route-maps don't work that way in today's router software, ever=
y
    clause is evaluated once and then the route-map execution either
    stops (if no continue statement is given) or proceeds to the next
    clause (if a continue statement is given). Either way, the community
    will only be matched once even if it's been tagged twice on the sam=
e
    prefix.

    

    Best regards,

    Martijn

    

    
On 11/15/2016 03:19=
 PM, Robert Raszuk
      wrote:

    

    

      
Hi Bruno,

      
Since I was going to ask the same question let me
        provide an example:

      
AS1 ---- AS2 ---- AS3 ---- peer_X

      
AS3 publishes community with action if I receive this
        community I will PREPEND my AS# one time towards my peer X.

      
Now AS1 comes with a need for such prepend on PI
        prefix P. Then AS2 for perhaps completely different reason also
        comes up with idea to hint AS3 to execute prepend on the same
        very prefix P.

      
So AS3 is receiving the two communities which both
        are valid and truely intended. Why we would drop it ?

      
I admit when the topic came up originally the major
        concern to me was to prevent stuffing community with N identical
        sets of values by same AS. 

      
But even this case can be legitimate. Let's consid=
er
        that said AS2=C2=A0 needs prepend by 2 to some prefixes and AS3
        offers *only* community of single PREPEND. Why not adding it
        twice to such selected prefixes not be a way to signal such
        requirement ?

      
Regards,

        R.

      


        
On Nov 15, 2016 10:46 PM, <bruno.decraene@orange.=
com>
          wrote:

          
TL;DR: I'm
            fine with -08 (MUST NOT send, MUST de-duplicate). I'm not
            fine with -06, unless some text is added, because it may
            open different interpretation.

            

            > From: Jakob Heitz (jheitz) [mailto:jheitz@cisco.com]=C2=A0
            > Sent: Tuesday, November 15, 2016 12:00 AM

            >

            =C2=A0> Receipt of a duplicate MUST NOT trigger any error
            handling. It is not a protocol error. It

            =C2=A0> MUST NOT cause treat-as-withdraw and MUST NOT cause
            attribute discard. Simply

            =C2=A0> deleting the duplicate is enough. Even a log of the
            deletion is noise. Log it if you must, but

            =C2=A0> my code does not. This is consistent with legacy
            community handling.

            =C2=A0>

            =C2=A0> Therefore, I support SHOULD.

            

            If you believe that this is not an error, there is no need
            for specific action, not to mention trying to correct the
            .... error. ("SHOULD remove the duplicate" is trying =
to
            correct it).

            

            Taking a step back, I think that what we really must
            specify, is whether a community received N times, MUST be
            considered as received N times or 1 time, because this
            impacts the meaning, hence the interop. e.g. if the
            community means prepend one, does sending it N times means
            prepend N or prepend 1)

            >From the current text, it seems that people want to only
            have the community interpreted once. (which is a restriction
            of what we could do).

            

            If so, it seems to never make sense to send the same value
            multiple times. So it seems clearer to completely forbid it
            (MUST NOT) rather than leaving the option to re-open the
            discussion latter or consider how the receiver need to react
            to "keep the meaning" intended by the originator. Esp=
ecially
            since some combination seems to make less sense. e.g.
            "SHOULD NOT be sent, SHOULD be removed" where we are =
opening
            the option to send duplicate, but we don't define how such
            duplicate will propagate, so the originator has even less
            reason to try an innovative unspecified behavior.

            

            Now, if we have "MUST NOT be sent", then I think that=
 this
            is an error condition if we receive duplicate. And I see 3
            options:

            a) leave them all, (i.e. no correction) but specify that N
            times as the same value that 1 time.

            b) try to stop the error, by correcting it (i.e. "remove
            duplicate") but that seem to assume that the error is on t=
he
            sending side, while the error could in fact be on the
            receiving side. It's bothers me a little that this point ha=
d
            never been discussed by the WG, especially since for the
            receiver (coder), there is a clear bias in favor of trusting
            itself (himself). While we had real world example where the
            error was on the receiving side or at least not on the
            sending side (e.g. error due to code point collision, e.g.
            VPN extended community 0x010a, and more recently attributes
            in draft-ietf-idr-deprecate-30-31-129)

            c) try to stop the error, with no assumption on the source
            of the error, by withdrawing the error (Attribute discard or
            Treat-As-Withdraw). Would be TAW in our case.

            

            I had suggested "treat-as-withdraw" as a provocation =
to
            trigger the discussion, which had never happened. But
            personally I don't care much on the action, provided that
            the interpretation is not ambiguous. e.g. MUST be considered
            as received 1 time.

            

            Again, I fine with latest version (-08). I'm less fine with
            the -06 version, especially as the behavior on the receiving
            side is not strictly defined and may not be interoperable
            (-06 allows keeping duplicate while not defining its
            meaning)

            

            Thanks,

            --Bruno

            

            =C2=A0> Thanks,

            =C2=A0> Jakob.

            =C2=A0>

            =C2=A0>

            =C2=A0> > On Nov 15, 2016, at 6:39 AM, "bruno.decraene@orange.co=
m"

            =C2=A0> <bruno.decraene@orange.com>
            wrote:

            =C2=A0> >

            =C2=A0> > John, Sue,

            =C2=A0> >

            =C2=A0> >> From: Idr [mailto:idr-bounces@ietf.org]
            On Behalf Of John G. Scudder=C2=A0 > Sent: Monday,

            =C2=A0> November 14, 2016 7:50 PM

            =C2=A0> >>

            =C2=A0> >> In my role as co-chair:

            =C2=A0> >>

            =C2=A0> >>> On Nov 14, 2016, at 6:10 PM, John G.
            Scudder <jgs@juniper.net>
            wrote:

            =C2=A0> >>> Please raise any objections by November
            21. In this case, silence will be taken as

            =C2=A0> >> consent assuming you've already support=
ed
            publication.

            =C2=A0> >>

            =C2=A0> >> Given there's debate regarding the
            SHOULD/MUST change, I think it's not appropriate

            =C2=A0> to

            =C2=A0> >> assume silence gives consent to the change.
            So, I take that back and expect we will

            =C2=A0> judge

            =C2=A0> >> consensus for this item in the usual way.
            =C2=A0> >

            =C2=A0> > 1) I support the "MUST".

            =C2=A0> > In addition to the reasons already provided,
            IMHO, I would say that this also seems

            =C2=A0> aligned with RFC 7606. (but I would prefer not to
            re-open the 7606 error handling debate).

            =C2=A0> >

            =C2=A0> > 2) If "MUST" is kept, on a side note,=


            =C2=A0> >

            =C2=A0> > - I'm less sure about the "silently&qu=
ot; part of
            "MUST silently" as I'm not sure why logging

            =C2=A0> the error should be considered as a protocol
            violation. (and 7606 was rather calling for

            =C2=A0> logging the error). So I would propose to remove
            "silently.

            =C2=A0> >

            =C2=A0> > - If we now have ' Duplicate BGP Large Comm=
unity
            values MUST NOT be transmitted.',

            =C2=A0> receiving a duplicate is a clear protocol error. In
            the general case, it's difficult to know

            =C2=A0> whether the error is on the sending side or the
            receiving side. (Although the receiving side

            =C2=A0> will typically consider that he is (obviously always=
)
            right, hence the sender must be in

            =C2=A0> error). Given that large community has an impact on
            route preference or selection, this

            =C2=A0> may call for "treat-as-withdraw"...

            =C2=A0> > I already hear the objection that "both va=
lue are
            the same hence it has no influence",

            =C2=A0> but it's the receiver which claims that both val=
ue are
            the same. If the error is on the

            =C2=A0> receiving side, possibly both values were sent as
            different. (e.g. oops, the test was only

            =C2=A0> considering the first 64 bits. And the error had nev=
er
            been detected so far, because the

            =C2=A0> first 64 bits had been different during testing, or
            the duplicate silently removed))

            =C2=A0> >

            =C2=A0> > --Bruno

            =C2=A0> >

            =C2=A0> >> (The same would apply to the canonical

            =C2=A0> >> representation item if there were to be
            debate about it.)

            =C2=A0> >>

            =C2=A0> >> --John

            =C2=A0> >> ______________________________________=
_________

            =C2=A0> >> Idr mailing list

            =C2=A0> >> Idr@ietf.org

            =C2=A0> >> https://www.ietf.org/mailma=
n/listinfo/idr

            =C2=A0> >

            =C2=A0> >

            =C2=A0> _______________________________________________=
__________________________

            =C2=A0> _______________________________________________=
_

            =C2=A0> >

            =C2=A0> > Ce message et ses pieces jointes peuvent conten=
ir
            des informations confidentielles ou

            =C2=A0> privilegiees et ne doivent donc

            =C2=A0> > pas etre diffuses, exploites ou copies sans
            autorisation. Si vous avez recu ce message

            =C2=A0> par erreur, veuillez le signaler

            =C2=A0> > a l'expediteur et le detruire ainsi que les
            pieces jointes. Les messages electroniques

            =C2=A0> etant susceptibles d'alteration,

            =C2=A0> > Orange decline toute responsabilite si ce messa=
ge
            a ete altere, deforme ou falsifie.

            =C2=A0> Merci.

            =C2=A0> >

            =C2=A0> > This message and its attachments may contain
            confidential or privileged information

            =C2=A0> that may be protected by law;

            =C2=A0> > they should not be distributed, used or copied
            without authorisation.

            =C2=A0> > If you have received this email in error, pleas=
e
            notify the sender and delete this

            =C2=A0> message and its attachments.

            =C2=A0> > As emails may be altered, Orange is not liable
            for messages that have been modified,

            =C2=A0> changed or falsified.

            =C2=A0> > Thank you.

            =C2=A0> >

            =C2=A0> > __________________________________________=
_____

            =C2=A0> > Idr mailing list

            =C2=A0> > Idr@ietf.org

            =C2=A0> > https://www.ietf.org/mailman/l<=
wbr>istinfo/idr

            

            __________________________________________________________=
_______________________________________________________________

            

            Ce message et ses pieces jointes peuvent contenir des
            informations confidentielles ou privilegiees et ne doivent
            donc

            pas etre diffuses, exploites ou copies sans autorisation. Si
            vous avez recu ce message par erreur, veuillez le signaler

            a l'expediteur et le detruire ainsi que les pieces jointes.
            Les messages electroniques etant susceptibles d'alteration,=


            Orange decline toute responsabilite si ce message a ete
            altere, deforme ou falsifie. Merci.

            

            This message and its attachments may contain confidential or
            privileged information that may be protected by law;

            they should not be distributed, used or copied without
            authorisation.

            If you have received this email in error, please notify the
            sender and delete this message and its attachments.

            As emails may be altered, Orange is not liable for messages
            that have been modified, changed or falsified.

            Thank you.

            

            _______________________________________________

            Idr mailing list

            Idr@ietf.org<=
/a>

            https://www.ietf.org/mailman/listinfo/idr<=
/a>

          

        

      

      

      

      

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


    

    

    
-- 

      
Met vriendelijke groet / Kindest regards,
        

        Martijn Schmidt

      

      

      

        
          

            
              3D"i3D.=
            
            
              

                Martijn Schmidt | Network
                  Architect

                Email: martijnschmidt@i3d.net
                | Tel: +31 10 8900070

                

                i3D.net B.V. | Global Backbone AS49544

                Van Nelleweg 1, 3044 BC Rotterdam, The Netherlands

                VAT: NL 8202.63.886.B01

                

                Website
                |
                Case
                  Studies |
                LinkedIn
              

            		
            
              

            		
          

        
      

    

  





--94eb2c1930f416f34305415ada9a--

--94eb2c1930f416f34705415ada9b
Content-Type: image/png; name="i3Dlogo-email.png"
Content-Disposition: inline; filename="i3Dlogo-email.png"
Content-Transfer-Encoding: base64
Content-ID: 
X-Attachment-Id: 534c4faeb61594e2_0.1.1

iVBORw0KGgoAAAANSUhEUgAAAOkAAACCCAMAAACU2h9IAAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJ
bWFnZVJlYWR5ccllPAAAA0xpVFh0WE1MOmNvbS5hZG9iZS54bXAAAAAAADw/eHBhY2tldCBiZWdp
bj0i77u/IiBpZD0iVzVNME1wQ2VoaUh6cmVTek5UY3prYzlkIj8+IDx4OnhtcG1ldGEgeG1sbnM6
eD0iYWRvYmU6bnM6bWV0YS8iIHg6eG1wdGs9IkFkb2JlIFhNUCBDb3JlIDUuNi1jMTMyIDc5LjE1
OTI4NCwgMjAxNi8wNC8xOS0xMzoxMzo0MCAgICAgICAgIj4gPHJkZjpSREYgeG1sbnM6cmRmPSJo
dHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjIj4gPHJkZjpEZXNjcmlw
dGlvbiByZGY6YWJvdXQ9IiIgeG1sbnM6eG1wTU09Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEu
MC9tbS8iIHhtbG5zOnN0UmVmPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvc1R5cGUvUmVz
b3VyY2VSZWYjIiB4bWxuczp4bXA9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8iIHhtcE1N
OkRvY3VtZW50SUQ9InhtcC5kaWQ6MEM3NkQ1NTY3NkE4MTFFNkI0OTI5NERBQkYxNEIxQUEiIHht
cE1NOkluc3RhbmNlSUQ9InhtcC5paWQ6MEM3NkQ1NTU3NkE4MTFFNkI0OTI5NERBQkYxNEIxQUEi
IHhtcDpDcmVhdG9yVG9vbD0iQWRvYmUgUGhvdG9zaG9wIENDIDIwMTUuNSAoV2luZG93cykiPiA8
eG1wTU06RGVyaXZlZEZyb20gc3RSZWY6aW5zdGFuY2VJRD0iYWRvYmU6ZG9jaWQ6cGhvdG9zaG9w
OmYwMGZmMDc1LTc2YTUtMTFlNi1iZDIzLWJhYTI4MGRmODBkYyIgc3RSZWY6ZG9jdW1lbnRJRD0i
YWRvYmU6ZG9jaWQ6cGhvdG9zaG9wOmYwMGZmMDc1LTc2YTUtMTFlNi1iZDIzLWJhYTI4MGRmODBk
YyIvPiA8L3JkZjpEZXNjcmlwdGlvbj4gPC9yZGY6UkRGPiA8L3g6eG1wbWV0YT4gPD94cGFja2V0
IGVuZD0iciI/Pu9aRCwAAABgUExURf7+/uuxsufn5+ONj9nZ2fPz86qqq5SUlWNjZHt7fM/Pz7i4
uFZWV4aGh0FBQsPDw0pKS/TU1T8/QN93efv29ttmaW9vcNU+Q/nq6vHIydhTV/bf4OijpNIjKkBA
Qf///zh9ticAAAfaSURBVHja7Nxro3ssAABw5n4dj+x66Pt/ywddFEr6m5mtN8fZWvVDqYQBvyUY
P+lP+rnSug+hIA4I3cCPs7pOszjwopMoLb+eDll8SVz7Hfs0rf8z1KVhkg1K7rvOIikKcWLvWhpO
Fj9zwWJpEy72bqUgER6hUENap56xT+lJUvbU1ZA2Z76zR+kplhba1ZFuS1WUOvFMoSMdaX0xdicN
5sqcnXSktbc3abT48ChKU3tfUiNWKHSkI62DfUkjpebF0JHW9luk5z44y4sdakmTt0gFcexx9cqy
mTLz0hiHLB03ZWBHUm9QNq/toYPzsD3ODKGUHm7D9jLZqfBm6eD4nETV156XTvRBvP1IAXfKpSfh
wXaVpNBO39L6Kkht4SFwMmFFlUgH3ZB4P9JIfFXghze+ovTMnwpgN1JX2OwMdkKsKHV46Wk3Uq42
XiQndmqoSWH8jsZXQZqI24/B0XEUpf5OpYG4S2MIz0Mp5sJ9eX6D1O4DUJLC9EOl02WTSbOf9OBS
58OlkceESCYFHy6VBU6awuNKDa3e4CdKHeGo5GjSUDjMOZrUFRb5YFKD86TOcaX8oO0CDyu1M/HU
9pGkwOWhsXEw6Tlqg+sG2YK7FR8p9dVusBxXGjtfIo1P8DukgQO/QhpHBvwKqX+ajXaUY5q560od
nwR8wyBC/7V71PPHoY3l+pNh5/XUGY6O3H6aKhDcovamLwnrt72jlUXrSC/7k9Y+eIUUD492JR1O
Gq4jxd/tSzr4xUpS741St50LTQJ/tDbDf4U0FkjTjAmdFG+TywEOa4zaQBSrr9LRlqLbAmNpMDMt
6646Encuyqt09KXRHqQQxItX6SyWJruQDiZBFVfpLJN2Mxnvl/Jzg6qrdBZJu933fumgbQ9eIXX3
IY1ecl8GSzNq2oGUX7uSrSsN6ArKHUgHa1eMVaVeTH67AynUW6WjKPVIh3ArKXCYACYTXnedA5Ge
Se3fSrr5ig4idVI8cju8FCdynpLOnGSfJiUVVTZqCw4hDfHI7fhSgJI/HV+KI0ZfIEXEZA/S+rVS
G8+cbyTdfCVzL8UP1CUjaRyQ4K4oVV6dXq+0Or2X4r0cb9RzcEXjFe0nDlL5EweMNBpGfKl09adI
wpmnSBjpaVOp+MkgoPdkUDLzZBAj5U70149lUtFj0qs87XWRSr0tpYNS9zeGz+lrnuBjpedNpaOn
MtssjTDReCoTnhSeymSlbOv1eun4SdssjtNFT9riW9RxpvKkLStlexkbzK6oPBC/4tPTnNTbVOqq
FDnWeyI+nJGGm0rB695ycIEzUiPbUqrymgN/vTdXcFKmT7+F1LgsLfK/vI3EmVq4stV874veMEPX
gdhoYBJOSO0paT+WaYK96sy2nS07NkrSfl3lmd1fvLRv+WXrHFacw7clR1X3TVB9x1ImTTaWQkf4
5iC9t3vVCdNnkEmjraVNcabf2OY5UEPqcznIpKftpdA4B8NOoN5b+LJkkL5MStPaUNp2Is4eXouU
xpdk+ZsV68wP3HDU15VKvfWlzD01+QvGjNH9kFGtFgRxgn2uxuCOC2DKBCbSNMb5ghkpPHL4SX/S
n/Qn3am06kJpNm10RQLZfFhty00+NZvtm3WtrtYN8jGKZqtoUzPRryHMK/IR+SX6ApglziwnyRao
IM1W3v/p8+k2u2zMqv8JitZu38ZJS6VNHDCWVtUVcNLbFX1642MUBEg3ulI9iNSi0pJmJpUy+Tyv
5BfTUhMnDfqkZ6TNTyak1R8ntfCmxcfogM8mtQcnrYi0Arg4Zp+WVMrkU9BfTEutcdJiaQ5Bk3RJ
MqP5gqL9dPAxypGP0ZXmTlj04JKid991XzQfW93BKTope6Jx0j4fQDZLNhYjfeCkS5J0KZWifIdS
eO9NkNQ+8iUbo8D78kmlTb4Fgyc7vudIpUw+/aZAWoFR0hrSfFaa91ILuck5W1q0JWoq3L9Ki6IQ
Se+bS8u2rlxRjObgWiZticq2EmtKb7he8LF66aNpJ7aVFu1fq/3TxmgOrnlHVaZts6pBcfI8V5W2
jRzTnI6kFmpfuNZEQ9o1HVIpitE2NO1xK9o/FWp6zT7ys5oojqrU7JvnKWnzNVgipW0vafa7T28l
uVzhFmckxTGKLse2wqB2ub1KdDHwZb05p29TUvaiQC8hA2l3xaFHdSRt0mXaTXo9V7ueFky+JZBI
aYwmg+YrE3R/KnSRAa0PlaYtrKkt7boEhDqSNmf330Jp30dipXc4J70jWLNvrbw7UVGMKzrSqDT3
Cp/WOlJEtURS0jaoSkm/Nx/mm0vqKY1RdJW8NFFdbzpz3e76o9dRwHS9ltZTQjUFUpNPerbt5ZJh
66klbZFwjFZatG0sbnjy7lPanpHenc5VBk0qPXAnekL6XEO6pI/UHsEr6pB2xkdRlOTXcGrHK7e9
pomyuU1L4XUN6YLrKcKYKKc/emoDejrrSvnDOyG1tpbmjLRgKjEzWnuN1HyFdDSWYaSAgV3pgAbT
SXGYAYfiWAaWZBMIpM9qOExSkvKN5EjKj085aVdfAGlqH1iKe4GkOBrjU5OLNiGF1yXjU1UpP+fA
Sws6ZMn7uZaCnE6P4cSA6pwD/sn1KZQWw+kMDSmo8CiE9ii5eSQao8DNUEEvcX9Y+iBSS3seCVgP
sjktNRXnkeC3hJ/0J/1Jf9Kf9Cd9XfhfgAEA6npi4QQJPOEAAAAASUVORK5CYII=
--94eb2c1930f416f34705415ada9b--


From nobody Tue Nov 15 10:26:51 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2879B12947A for ; Tue, 15 Nov 2016 10:26:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.699
X-Spam-Level: 
X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, 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 S_VX3L_VAMLU for ; Tue, 15 Nov 2016 10:26:48 -0800 (PST)
Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF6F6127078 for ; Tue, 15 Nov 2016 10:26:48 -0800 (PST)
Received: by guelah.shrubbery.net (Postfix, from userid 7053) id B86537C7AC; Tue, 15 Nov 2016 18:26:48 +0000 (UTC)
Date: Tue, 15 Nov 2016 18:26:48 +0000
From: heasley 
To: Robert Raszuk 
Message-ID: <20161115182648.GD94469@shrubbery.net>
References:   <27701_1479159582_582A2F1E_27701_6903_1_53C29892C857584299CBF5D05346208A1EC77FE1@OPEXCLILM21.corporate.adroot.infra.ftgroup> <736EA2CC-3DD1-4F14-96ED-2916E62F6F02@cisco.com> <26709_1479217575_582B11A7_26709_12999_1_53C29892C857584299CBF5D05346208A1EC79584@OPEXCLILM21.corporate.adroot.infra.ftgroup>   
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc
X-note: live free, or die!
X-homer: i just want to have a beer while i am caring.
X-Claimation: an engineer needs a manager like a fish needs a bicycle
X-reality: only YOU can put an end to the embarrassment that is Tom Cruise
User-Agent: Mutt/1.6.1 (2016-04-27)
Archived-At: 
Cc: bruno.decraene@orange.com, idr wg 
Subject: Re: [Idr] One week extension to WGLC for draft-ietf-idr-large-community
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, 15 Nov 2016 18:26:50 -0000

Tue, Nov 15, 2016 at 07:09:03PM +0100, Robert Raszuk:
> And what stops you from having a bit smarter clauses where you regex match
> on exactly one, two or N occurences of a given community string anywhere in
> your received community list following different local PREPEND action ???
> 
> Expanded matches for communities have been supported for years.

why would AS3 not just offer communities for 1 - 6 prepends?  at some point,
the number of prepends is pointless and AS1 could cause AS2 to prepend or
prepend itself to achieve the same effect.

> On Nov 15, 2016 11:28 PM, "i3D.net - Martijn Schmidt" <
> martijnschmidt@i3d.net> wrote:
> 
> > Hi Robert,
> >
> > Route-maps don't work that way in today's router software, every clause is
> > evaluated once and then the route-map execution either stops (if no
> > continue statement is given) or proceeds to the next clause (if a continue
> > statement is given). Either way, the community will only be matched once
> > even if it's been tagged twice on the same prefix.
> >
> > Best regards,
> > Martijn
> >
> > On 11/15/2016 03:19 PM, Robert Raszuk wrote:
> >
> > Hi Bruno,
> >
> > Since I was going to ask the same question let me provide an example:
> >
> > AS1 ---- AS2 ---- AS3 ---- peer_X
> >
> > AS3 publishes community with action if I receive this community I will
> > PREPEND my AS# one time towards my peer X.
> >
> > Now AS1 comes with a need for such prepend on PI prefix P. Then AS2 for
> > perhaps completely different reason also comes up with idea to hint AS3 to
> > execute prepend on the same very prefix P.
> >
> > So AS3 is receiving the two communities which both are valid and truely
> > intended. Why we would drop it ?
> >
> > I admit when the topic came up originally the major concern to me was to
> > prevent stuffing community with N identical sets of values by same AS.
> >
> > But even this case can be legitimate. Let's consider that said AS2  needs
> > prepend by 2 to some prefixes and AS3 offers *only* community of single
> > PREPEND. Why not adding it twice to such selected prefixes not be a way to
> > signal such requirement ?
> >
> > Regards,
> > R.


From nobody Tue Nov 15 12:44:09 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2776A1294EB for ; Tue, 15 Nov 2016 12:44:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5L0D8TGT0ie for ; Tue, 15 Nov 2016 12:44:06 -0800 (PST)
Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c: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 A23451294E6 for ; Tue, 15 Nov 2016 12:44:06 -0800 (PST)
Received: by mail-wm0-x234.google.com with SMTP id f82so25330218wmf.1 for ; Tue, 15 Nov 2016 12:44:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=a04GOHaREXzPihxAL4/t2vYhpIbTTqozULVfL0hIghk=; b=W13nfDu57b+eupOueyOvZGGRRxBKmrlocJ53Me3fhzQHHz7zaEe3qqBGGn7lpyiyLp rvzgZY/qe/rWqOsAp69KVN1yVVu+YiYzPY5VEyp8ogu1vZUjM0x4LN2jO6YK6WXe4UaI ItiGTrmAbMZfRqI4mP46IgrUtCrgf0P1Q6zBayu6a0vRmGmjaMmfTAOpZRaP3p/+WNsN 74ExhBxrMMTZVBTa6VarcVGVVD1CSgYOw0unCpm4ptQ3HN+ORTo+o8y/RB4bPinKJhGm VzjcnMB9l9WVIbgAbVpwtBhPe0o1k7MhT+E2CeZMP+jIQQNlh9CsWhXOOYRoyCLXzW1a MvCg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=a04GOHaREXzPihxAL4/t2vYhpIbTTqozULVfL0hIghk=; b=AtpCplr+IN/V5bE5fn0I9BVk1RXLD0ejy2ra8qKr/7Lx3JkWc7RivBtaKIAyNOQROu IkedpTsX8RF/kfQwduzRzJFvgb8Cp9v3jar6MbUQS4rIf1e+oJeUlRuKiP6/zDJf4eu3 JcWx6kM6u95WgM1e3tqlxE9v34T+7sq5es5og9fjarjwv3p/P7ITXFEDSXHO5NhlkR4E DHb3n0HYASixHUJRhrr+SRs2zsYeeWr/zkap+atXhrr3DK2l/2s6PcFrdovDhuJJ0S7F FsRlSfTg+09HD5pgPeLvJotL57VdiKe8ovJLSoOy+VqQ9cQV+40eDOU+8ZIRDBPlubTs s3HQ==
X-Gm-Message-State: ABUngveaQ4yOXBcY1VLIAWvEY+YbGU+ccfSt/WG+YYgLP/50S18+t3tAu54oQ1kTRwSLDwYxwOLw1ijKIFx0cA==
X-Received: by 10.194.115.70 with SMTP id jm6mr12867249wjb.140.1479242645164;  Tue, 15 Nov 2016 12:44:05 -0800 (PST)
MIME-Version: 1.0
Received: by 10.28.197.132 with HTTP; Tue, 15 Nov 2016 12:44:04 -0800 (PST)
In-Reply-To: 
References:   <27701_1479159582_582A2F1E_27701_6903_1_53C29892C857584299CBF5D05346208A1EC77FE1@OPEXCLILM21.corporate.adroot.infra.ftgroup> <736EA2CC-3DD1-4F14-96ED-2916E62F6F02@cisco.com> <26709_1479217575_582B11A7_26709_12999_1_53C29892C857584299CBF5D05346208A1EC79584@OPEXCLILM21.corporate.adroot.infra.ftgroup> 
From: Brian Dickson 
Date: Tue, 15 Nov 2016 12:44:04 -0800
Message-ID: 
To: Robert Raszuk 
Content-Type: multipart/alternative; boundary=001a1130ccf266d82105415d04ef
Archived-At: 
Cc: bruno.decraene@orange.com, idr wg 
Subject: Re: [Idr] One week extension to WGLC for draft-ietf-idr-large-community
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, 15 Nov 2016 20:44:08 -0000

--001a1130ccf266d82105415d04ef
Content-Type: text/plain; charset=UTF-8

On Tue, Nov 15, 2016 at 6:19 AM, Robert Raszuk  wrote:

> Hi Bruno,
>
> Since I was going to ask the same question let me provide an example:
>
> AS1 ---- AS2 ---- AS3 ---- peer_X
>
> AS3 publishes community with action if I receive this community I will
> PREPEND my AS# one time towards my peer X.
>
> Now AS1 comes with a need for such prepend on PI prefix P. Then AS2 for
> perhaps completely different reason also comes up with idea to hint AS3 to
> execute prepend on the same very prefix P.
>

Regardless of the rationale on the parts of AS1 and/or AS2, here is the
semantic issue:
A given community is a FLAG. You can use any number of DIFFERENT flags
(community values), but each community value can only be "present" or
"absent".

So, in your example, the presence or absence of the specific community
(AS3->X prepend once), has been defined by AS3. Its presence triggers the
behavior, and its absence does not.
Regardless of who sets the community (adds it to the set), that is the only
available behavior defined by (and for) AS3.
What AS2 does, is in effect, a logical "OR" between the received prefix's
"presence", and the locally asserted "presence".
It passes an unset flag, or passes a set flag, or sets an unset flag, or
sets an already-set flag  (which is a no-op).
There is no "send two copies".


> So AS3 is receiving the two communities which both are valid and truely
> intended. Why we would drop it ?
>
You should not drop it, you should silently drop every copy beyond the
first, and then act on it. There is only one community, in the sense of a
specific community value as a flag.

> I admit when the topic came up originally the major concern to me was to
> prevent stuffing community with N identical sets of values by same AS.
>
> But even this case can be legitimate. Let's consider that said AS2  needs
> prepend by 2 to some prefixes and AS3 offers *only* community of single
> PREPEND. Why not adding it twice to such selected prefixes not be a way to
> signal such requirement ?
>
This boils down to the namespace. The name space is "owned" by AS3, and
what AS3 offers or does not offer, is entirely up to AS3.

If AS2 wants something that AS3 does not offer, the only options that exist
are in "meat space": the operators of AS2 can try to persuade the operators
of AS3 to offer it. Unless and until they do, there is no mechanism for AS2
to "force" AS3 to do what it wants. This is by design.

AS2 might want a pony. AS2 might think it NEEDS a pony. Nothing AS2 does
can make AS3 give AS2 a pony.

(If AS2 is able to achieve the same result with local action, such as doing
prepends itself, the issue is moot and not in scope for communities, and
probably sufficient to solve the problem)
(AS2 might also want to investigate the use of the "origin" attribute,
which can be set differentially to various peers, and influence the path
choice, similar to a "fractional AS prepend".)

Brian

--001a1130ccf266d82105415d04ef
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Tue, Nov 15, 2016 at 6:19 AM, Robert Raszuk <robert@raszuk.net&=
gt; wrote:
Hi Bruno,


Since I was going to ask the same question let me provide an=
 example:


AS1 ---- AS2 ---- AS3 ---- peer_X


AS3 publishes community with action if I receive this commun=
ity I will PREPEND my AS# one time towards my peer X.


Now AS1 comes with a need for such prepend on PI prefix P. T=
hen AS2 for perhaps completely different reason also comes up with idea to =
hint AS3 to execute prepend on the same very prefix P.

Regardless of the rationale on the parts of AS1 and/or AS2,=
 here is the semantic issue:
A given community is a FLAG. You can=
 use any number of DIFFERENT flags (community values), but each community v=
alue can only be "present" or "absent".

<=
/div>
So, in your example, the presence or absence of the specific comm=
unity (AS3->X prepend once), has been defined by AS3. Its presence trigg=
ers the behavior, and its absence does not.
Regardless of who set=
s the community (adds it to the set), that is the only available behavior d=
efined by (and for) AS3.
What AS2 does, is in effect, a logical &=
quot;OR" between the received prefix's "presence", and t=
he locally asserted "presence".
It passes an unset flag=
, or passes a set flag, or sets an unset flag, or sets an already-set flag =
=C2=A0(which is a no-op).
There is no "send two copies"=
.
=C2=A0


So AS3 is receiving the two communities which both are valid=
 and truely intended. Why we would drop it ?
You shoul=
d not drop it, you should silently drop every copy beyond the first, and th=
en act on it. There is only one community, in the sense of a specific commu=
nity value as a flag.=C2=A0


I admit when the topic came up originally the major concern =
to me was to prevent stuffing community with N identical sets of values by =
same AS. 


But even this case can be legitimate. Let's consider tha=
t said AS2=C2=A0 needs prepend by 2 to some prefixes and AS3 offers *only* =
community of single PREPEND. Why not adding it twice to such selected prefi=
xes not be a way to signal such requirement ?
This boi=
ls down to the namespace. The name space is "owned" by AS3, and w=
hat AS3 offers or does not offer, is entirely up to AS3.

If AS2 wants something that AS3 does not offer, the only options tha=
t exist are in "meat space": the operators of AS2 can try to pers=
uade the operators of AS3 to offer it. Unless and until they do, there is n=
o mechanism for AS2 to "force" AS3 to do what it wants. This is b=
y design.

AS2 might want a pony. AS2 might think i=
t NEEDS a pony. Nothing AS2 does can make AS3 give AS2 a pony.
(If AS2 is able to achieve the same result with local action, =
such as doing prepends itself, the issue is moot and not in scope for commu=
nities, and probably sufficient to solve the problem)
(AS2 might =
also want to investigate the use of the "origin" attribute, which=
 can be set differentially to various peers, and influence the path choice,=
 similar to a "fractional AS prepend".)

=
Brian=C2=A0


--001a1130ccf266d82105415d04ef--


From nobody Tue Nov 15 13:17:18 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03CA2129570 for ; Tue, 15 Nov 2016 13:17:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.017
X-Spam-Level: 
X-Spam-Status: No, score=-16.017 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=-1.497, 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 46dgiTBmEL04 for ; Tue, 15 Nov 2016 13:17:15 -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 EBCA91294AA for ; Tue, 15 Nov 2016 13:17:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9714; q=dns/txt; s=iport; t=1479244635; x=1480454235; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=dGFWEkqR1tG1fFfbSV+2kqCHeClajm67vef7cLpT8GA=; b=F41v9/xj8nsncU0LtF99I12a2DXoKu/dkQsv++oz0m3uoRAK5VGwuOBv 6r3G7Sq6gzbGTV/hBZe+btMA0NEG7FmrVEK53fbSTUiHw24NpeU38P2Gy LMzKnyDsINe9EV9wzavJ+BGoNrjdakTPVunCdQ90N6YB/QZLGf8DTB/bE g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DPAwAeeytY/5FdJa1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgzcBAQEBAR9YgQCsNodahRyCBx0BCoV7AoIkQBMBAgEBAQEBAQFiKIR?= =?us-ascii?q?iAQEEAQEBJEcLEAIBCD8HIQYLFBECBA4FFIg+AxcOs0U9h0ENhBABAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEXBYY8gX2CXYJIhTGCMAWOYIV5hTM1AY0Zg0iQIokehCm?= =?us-ascii?q?ECQEfATWBBByDIxyBXXIBiBkBAQE?=
X-IronPort-AV: E=Sophos;i="5.31,496,1473120000";  d="scan'208,217";a="348120291"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Nov 2016 21:17:02 +0000
Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id uAFLH2TE018146 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 15 Nov 2016 21:17:02 GMT
Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 15 Nov 2016 15:17:01 -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; Tue, 15 Nov 2016 15:17:01 -0600
From: "Jakob Heitz (jheitz)" 
To: Brian Dickson 
Thread-Topic: [Idr] One week extension to WGLC for draft-ietf-idr-large-community
Thread-Index: AQHSPlcVO6RKnaa63k2qyfOXORnq2aDZN6gAgAAvdgD//7HLX4AAnUfQgADIPACAAGt8AP//pKB1
Date: Tue, 15 Nov 2016 21:17:01 +0000
Message-ID: <01E10ECE-EA2F-4C08-9A2E-0719473FEA06@cisco.com>
References:   <27701_1479159582_582A2F1E_27701_6903_1_53C29892C857584299CBF5D05346208A1EC77FE1@OPEXCLILM21.corporate.adroot.infra.ftgroup> <736EA2CC-3DD1-4F14-96ED-2916E62F6F02@cisco.com> <26709_1479217575_582B11A7_26709_12999_1_53C29892C857584299CBF5D05346208A1EC79584@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-transport-fromentityheader: Hosted
Content-Type: multipart/alternative; boundary="_000_01E10ECEEA2F4C089A2E0719473FEA06ciscocom_"
MIME-Version: 1.0
Archived-At: 
Cc: "bruno.decraene@orange.com" , Robert Raszuk , idr wg 
Subject: Re: [Idr] One week extension to WGLC for draft-ietf-idr-large-community
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, 15 Nov 2016 21:17:17 -0000

--_000_01E10ECEEA2F4C089A2E0719473FEA06ciscocom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

You could also add a community to say 1 prepend and another community to sa=
y 2 prepends, to achieve 3 prepends. That won't happen. Some ISPs have text=
 to that effect in their community specifications.

Likewise, we are saying in our draft that duplicates are of no significance=
. We could add some significance, but we won't. This is consistent with the=
 behavior of 1997 communities, even though RFC 1997 doesn't say it in so ma=
ny words.

Thanks,
Jakob.


On Nov 16, 2016, at 5:44 AM, Brian Dickson > wrote:



On Tue, Nov 15, 2016 at 6:19 AM, Robert Raszuk > wrote:

Hi Bruno,

Since I was going to ask the same question let me provide an example:

AS1 ---- AS2 ---- AS3 ---- peer_X

AS3 publishes community with action if I receive this community I will PREP=
END my AS# one time towards my peer X.

Now AS1 comes with a need for such prepend on PI prefix P. Then AS2 for per=
haps completely different reason also comes up with idea to hint AS3 to exe=
cute prepend on the same very prefix P.

Regardless of the rationale on the parts of AS1 and/or AS2, here is the sem=
antic issue:
A given community is a FLAG. You can use any number of DIFFERENT flags (com=
munity values), but each community value can only be "present" or "absent".

So, in your example, the presence or absence of the specific community (AS3=
->X prepend once), has been defined by AS3. Its presence triggers the behav=
ior, and its absence does not.
Regardless of who sets the community (adds it to the set), that is the only=
 available behavior defined by (and for) AS3.
What AS2 does, is in effect, a logical "OR" between the received prefix's "=
presence", and the locally asserted "presence".
It passes an unset flag, or passes a set flag, or sets an unset flag, or se=
ts an already-set flag  (which is a no-op).
There is no "send two copies".


So AS3 is receiving the two communities which both are valid and truely int=
ended. Why we would drop it ?

You should not drop it, you should silently drop every copy beyond the firs=
t, and then act on it. There is only one community, in the sense of a speci=
fic community value as a flag.

I admit when the topic came up originally the major concern to me was to pr=
event stuffing community with N identical sets of values by same AS.

But even this case can be legitimate. Let's consider that said AS2  needs p=
repend by 2 to some prefixes and AS3 offers *only* community of single PREP=
END. Why not adding it twice to such selected prefixes not be a way to sign=
al such requirement ?

This boils down to the namespace. The name space is "owned" by AS3, and wha=
t AS3 offers or does not offer, is entirely up to AS3.

If AS2 wants something that AS3 does not offer, the only options that exist=
 are in "meat space": the operators of AS2 can try to persuade the operator=
s of AS3 to offer it. Unless and until they do, there is no mechanism for A=
S2 to "force" AS3 to do what it wants. This is by design.

AS2 might want a pony. AS2 might think it NEEDS a pony. Nothing AS2 does ca=
n make AS3 give AS2 a pony.

(If AS2 is able to achieve the same result with local action, such as doing=
 prepends itself, the issue is moot and not in scope for communities, and p=
robably sufficient to solve the problem)
(AS2 might also want to investigate the use of the "origin" attribute, whic=
h can be set differentially to various peers, and influence the path choice=
, similar to a "fractional AS prepend".)

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

--_000_01E10ECEEA2F4C089A2E0719473FEA06ciscocom_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable







You could also add a community to say 1 prepend and another community =
to say 2 prepends, to achieve 3 prepends. That won't happen. Some ISPs have=
 text to that effect in their community specifications.







Likewise, we are saying in our draft that du=
plicates are of no significance. We could add some significance, but we won=
't. This is consistent with the behavior of 1997 communities, even though R=
FC 1997 doesn't say it in so many
 words.



Thanks,


Jakob.











On Nov 16, 2016, at 5:44 AM, Brian Dickson <brian.peter.dickson@gmail.com> wrote:
















On Tue, Nov 15, 2016 at 6:19 AM, Robert Raszuk <=
span dir=3D"ltr">
<robert@raszuk.ne=
t> wrote:




Hi Bruno,


Since I was going to ask the same question let me provide an=
 example:


AS1 ---- AS2 ---- AS3 ---- peer_X


AS3 publishes community with action if I receive this commun=
ity I will PREPEND my AS# one time towards my peer X.


Now AS1 comes with a need for such prepend on PI prefix P. T=
hen AS2 for perhaps completely different reason also comes up with idea to =
hint AS3 to execute prepend on the same very prefix P.









Regardless of the rationale on the parts of AS1 and/or AS2, here is th=
e semantic issue:


A given community is a FLAG. You can use any number of DIFFERENT flags=
 (community values), but each community value can only be "present&quo=
t; or "absent".







So, in your example, the presence or absence of the specific community=
 (AS3->X prepend once), has been defined by AS3. Its presence triggers t=
he behavior, and its absence does not.


Regardless of who sets the community (adds it to the set), that is the=
 only available behavior defined by (and for) AS3.


What AS2 does, is in effect, a logical "OR" between the rece=
ived prefix's "presence", and the locally asserted "presence=
".


It passes an unset flag, or passes a set flag, or sets an unset flag, =
or sets an already-set flag  (which is a no-op).


There is no "send two copies".


 




So AS3 is receiving the two communities which both are valid=
 and truely intended. Why we would drop it ?




You should not drop it, you should silently drop every copy beyond the=
 first, and then act on it. There is only one community, in the sense of a =
specific community value as a flag. 






I admit when the topic came up originally the major concern =
to me was to prevent stuffing community with N identical sets of values by =
same AS.



But even this case can be legitimate. Let's consider that sa=
id AS2  needs prepend by 2 to some prefixes and AS3 offers *only* comm=
unity of single PREPEND. Why not adding it twice to such selected prefixes =
not be a way to signal such requirement
 ?




This boils down to the namespace. The name space is "owned" =
by AS3, and what AS3 offers or does not offer, is entirely up to AS3.







If AS2 wants something that AS3 does not offer, the only options that =
exist are in "meat space": the operators of AS2 can try to persua=
de the operators of AS3 to offer it. Unless and until they do, there is no =
mechanism for AS2 to "force" AS3 to do what
 it wants. This is by design.







AS2 might want a pony. AS2 might think it NEEDS a pony. Nothing AS2 do=
es can make AS3 give AS2 a pony.







(If AS2 is able to achieve the same result with local action, such as =
doing prepends itself, the issue is moot and not in scope for communities, =
and probably sufficient to solve the problem)


(AS2 might also want to investigate the use of the "origin" =
attribute, which can be set differentially to various peers, and influence =
the path choice, similar to a "fractional AS prepend".)







Brian 
















_______________________________________________

Idr mailing list

Idr@ietf.org

https://www.iet=
f.org/mailman/listinfo/idr








--_000_01E10ECEEA2F4C089A2E0719473FEA06ciscocom_--


From nobody Tue Nov 15 14:17:11 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADF901295AF for ; Tue, 15 Nov 2016 14:17:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level: 
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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 m5soJdA-zaaX for ; Tue, 15 Nov 2016 14:17:09 -0800 (PST)
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 A1F19128E18 for ; Tue, 15 Nov 2016 14:17:08 -0800 (PST)
Received: by mail-wm0-x22b.google.com with SMTP id g23so198094541wme.1 for ; Tue, 15 Nov 2016 14:17:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=EqF29TgrBOOo6XYFekmSmfC+vL5hgKZiyIwNdy58uOc=; b=yJWjX2iABQCRb9Km1VMiN62GhsMkn6bvaQVyDtWn0+V5Yl8I9ZkqZymE6I22RJYECi qmjV1viGVxzXGzNCjqGbqjmocydPyGLxKqZciZ+LwEX/YUQZb2sYwWYPKGpLbtmYJJ4J eoJSyXSADz1mf20xGyfds0gV7Um5J9c7UtHMcX1qDxuUf4PMTwHscIE6cqKwcB28wmZf 0F7CzdWmfsJ0JzaiSZJgfInISK3h/6fizlKND08XjOrUfEwXaRO14g3wO6NsKjIIKA/H SL0DgmqglL2iVuNDe/HAOupCNTzOBxF3mjTmatvQfh1yMUJ614nXHpvBPmVYi9CCtn0j dklw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=EqF29TgrBOOo6XYFekmSmfC+vL5hgKZiyIwNdy58uOc=; b=XMx6+nbQcLEcikIIiHCxObY6+zekGfgSN+kdG2/lvCcrkHNU6HIV12icVi8JMoPrnK kQhz/xDwrGs/VuRdvJOBciToHG5SFypR1/TGs+xtzS7oDRLRuG69agS9UB0kOcJzEvc2 zXB8zoSDQrlYg+TTXo9FE6nk96bR3dlJL3+S5fL5zMRPJkwiJID8Qx6aMxhexevuNyKE Vj9ceVkLliWz2FGxeG7gdyJQUtCo/zjGxHnVO9LW1o3NX+Y6GC8kXP5k93uOtS7Gk6+P 7KmvAI8lrKTHwB2/v85M2+6U1DeKJezYPe6CLeH9nO8mPtCGo1SWKrpIc4cGaHCHkM0D rYnQ==
X-Gm-Message-State: ABUngvf5VCD331uGeVdwzJQrqheZRfIEeXo+41NrigAsiYYY96J57fXPYLfadmsTWVt/jwARtyfVQ4jsD0xUvA==
X-Received: by 10.28.9.80 with SMTP id 77mr6205878wmj.68.1479248227159; Tue, 15 Nov 2016 14:17:07 -0800 (PST)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.80.137.69 with HTTP; Tue, 15 Nov 2016 14:17:06 -0800 (PST)
Received: by 10.80.137.69 with HTTP; Tue, 15 Nov 2016 14:17:06 -0800 (PST)
In-Reply-To: <20161115182648.GD94469@shrubbery.net>
References:   <27701_1479159582_582A2F1E_27701_6903_1_53C29892C857584299CBF5D05346208A1EC77FE1@OPEXCLILM21.corporate.adroot.infra.ftgroup> <736EA2CC-3DD1-4F14-96ED-2916E62F6F02@cisco.com> <26709_1479217575_582B11A7_26709_12999_1_53C29892C857584299CBF5D05346208A1EC79584@OPEXCLILM21.corporate.adroot.infra.ftgroup>    <20161115182648.GD94469@shrubbery.net>
From: Robert Raszuk 
Date: Tue, 15 Nov 2016 23:17:06 +0100
X-Google-Sender-Auth: lMx3SEnS2ZAgZTrUKyUWRdriJCM
Message-ID: 
To: heasley 
Content-Type: multipart/alternative; boundary=001a11444da81d54d605415e51f2
Archived-At: 
Cc: bruno.decraene@orange.com, idr wg 
Subject: Re: [Idr] One week extension to WGLC for draft-ietf-idr-large-community
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, 15 Nov 2016 22:17:10 -0000

--001a11444da81d54d605415e51f2
Content-Type: text/plain; charset=UTF-8

Hi,

If AS1 or AS2 can prepend themselves there is no issue.

However the issue with AS3 offering 1-6 is that if AS2 end point is to
prepend at AS3 just by 1 AS2 would need to delete community  set by AS1 and
replace it by offered by AS3 prepend by 2.

As to the last point Jakob made that AS3 would not execute +1 prepend and
+2 prepend communities it is interesting how does AS3 knows who set each of
those and which one to not execute.

Thx,
R.

On Nov 16, 2016 3:26 AM, "heasley"  wrote:

> Tue, Nov 15, 2016 at 07:09:03PM +0100, Robert Raszuk:
> > And what stops you from having a bit smarter clauses where you regex
> match
> > on exactly one, two or N occurences of a given community string anywhere
> in
> > your received community list following different local PREPEND action ???
> >
> > Expanded matches for communities have been supported for years.
>
> why would AS3 not just offer communities for 1 - 6 prepends?  at some
> point,
> the number of prepends is pointless and AS1 could cause AS2 to prepend or
> prepend itself to achieve the same effect.
>
> > On Nov 15, 2016 11:28 PM, "i3D.net - Martijn Schmidt" <
> > martijnschmidt@i3d.net> wrote:
> >
> > > Hi Robert,
> > >
> > > Route-maps don't work that way in today's router software, every
> clause is
> > > evaluated once and then the route-map execution either stops (if no
> > > continue statement is given) or proceeds to the next clause (if a
> continue
> > > statement is given). Either way, the community will only be matched
> once
> > > even if it's been tagged twice on the same prefix.
> > >
> > > Best regards,
> > > Martijn
> > >
> > > On 11/15/2016 03:19 PM, Robert Raszuk wrote:
> > >
> > > Hi Bruno,
> > >
> > > Since I was going to ask the same question let me provide an example:
> > >
> > > AS1 ---- AS2 ---- AS3 ---- peer_X
> > >
> > > AS3 publishes community with action if I receive this community I will
> > > PREPEND my AS# one time towards my peer X.
> > >
> > > Now AS1 comes with a need for such prepend on PI prefix P. Then AS2 for
> > > perhaps completely different reason also comes up with idea to hint
> AS3 to
> > > execute prepend on the same very prefix P.
> > >
> > > So AS3 is receiving the two communities which both are valid and truely
> > > intended. Why we would drop it ?
> > >
> > > I admit when the topic came up originally the major concern to me was
> to
> > > prevent stuffing community with N identical sets of values by same AS.
> > >
> > > But even this case can be legitimate. Let's consider that said AS2
> needs
> > > prepend by 2 to some prefixes and AS3 offers *only* community of single
> > > PREPEND. Why not adding it twice to such selected prefixes not be a
> way to
> > > signal such requirement ?
> > >
> > > Regards,
> > > R.
>

--001a11444da81d54d605415e51f2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi,


If AS1 or AS2 can prepend themselves there is no issue.


However the issue with AS3 offering 1-6 is that if AS2 end p=
oint is to prepend at AS3 just by 1 AS2 would need to delete community=C2=
=A0 set by AS1 and replace it by offered by AS3 prepend by 2.


As to the last point Jakob made that AS3 would not execute +=
1 prepend and +2 prepend communities it is interesting how does AS3 knows w=
ho set each of those and which one to not execute.


Thx,

R.



On Nov 16, 2016 3=
:26 AM, "heasley" <heas@=
shrubbery.net> wrote:
Tue, Nov 15, 2016 at 07:09:03PM +0100, Robert Raszuk:

> And what stops you from having a bit smarter clauses where you regex m=
atch

> on exactly one, two or N occurences of a given community string anywhe=
re in

> your received community list following different local PREPEND action =
???

>

> Expanded matches for communities have been supported for years.



why would AS3 not just offer communities for 1 - 6 prepends?=C2=A0 at some =
point,

the number of prepends is pointless and AS1 could cause AS2 to prepend or
prepend itself to achieve the same effect.



> On Nov 15, 2016 11:28 PM, "i3D.net - Martijn Schmidt" <
> martijnschmidt@i3d.net&g=
t; wrote:

>

> > Hi Robert,

> >

> > Route-maps don't work that way in today's router software=
, every clause is

> > evaluated once and then the route-map execution either stops (if =
no

> > continue statement is given) or proceeds to the next clause (if a=
 continue

> > statement is given). Either way, the community will only be match=
ed once

> > even if it's been tagged twice on the same prefix.

> >

> > Best regards,

> > Martijn

> >

> > On 11/15/2016 03:19 PM, Robert Raszuk wrote:

> >

> > Hi Bruno,

> >

> > Since I was going to ask the same question let me provide an exam=
ple:

> >

> > AS1 ---- AS2 ---- AS3 ---- peer_X

> >

> > AS3 publishes community with action if I receive this community I=
 will

> > PREPEND my AS# one time towards my peer X.

> >

> > Now AS1 comes with a need for such prepend on PI prefix P. Then A=
S2 for

> > perhaps completely different reason also comes up with idea to hi=
nt AS3 to

> > execute prepend on the same very prefix P.

> >

> > So AS3 is receiving the two communities which both are valid and =
truely

> > intended. Why we would drop it ?

> >

> > I admit when the topic came up originally the major concern to me=
 was to

> > prevent stuffing community with N identical sets of values by sam=
e AS.

> >

> > But even this case can be legitimate. Let's consider that sai=
d AS2=C2=A0 needs

> > prepend by 2 to some prefixes and AS3 offers *only* community of =
single

> > PREPEND. Why not adding it twice to such selected prefixes not be=
 a way to

> > signal such requirement ?

> >

> > Regards,

> > R.




--001a11444da81d54d605415e51f2--


From nobody Tue Nov 15 14:27:41 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B4961294A1 for ; Tue, 15 Nov 2016 14:27:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.699
X-Spam-Level: 
X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, 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 fJYxa6rpGEY3 for ; Tue, 15 Nov 2016 14:27:38 -0800 (PST)
Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADB4C127A91 for ; Tue, 15 Nov 2016 14:27:38 -0800 (PST)
Received: by guelah.shrubbery.net (Postfix, from userid 7053) id 79F0B81E8B; Tue, 15 Nov 2016 22:27:38 +0000 (UTC)
Date: Tue, 15 Nov 2016 22:27:38 +0000
From: heasley 
To: Robert Raszuk 
Message-ID: <20161115222738.GW94469@shrubbery.net>
References:   <27701_1479159582_582A2F1E_27701_6903_1_53C29892C857584299CBF5D05346208A1EC77FE1@OPEXCLILM21.corporate.adroot.infra.ftgroup> <736EA2CC-3DD1-4F14-96ED-2916E62F6F02@cisco.com> <26709_1479217575_582B11A7_26709_12999_1_53C29892C857584299CBF5D05346208A1EC79584@OPEXCLILM21.corporate.adroot.infra.ftgroup>    <20161115182648.GD94469@shrubbery.net> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc
X-note: live free, or die!
X-homer: i just want to have a beer while i am caring.
X-Claimation: an engineer needs a manager like a fish needs a bicycle
X-reality: only YOU can put an end to the embarrassment that is Tom Cruise
User-Agent: Mutt/1.6.1 (2016-04-27)
Archived-At: 
Cc: idr wg 
Subject: Re: [Idr] One week extension to WGLC for draft-ietf-idr-large-community
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, 15 Nov 2016 22:27:39 -0000

Tue, Nov 15, 2016 at 11:17:06PM +0100, Robert Raszuk:
> As to the last point Jakob made that AS3 would not execute +1 prepend and
> +2 prepend communities it is interesting how does AS3 knows who set each of
> those and which one to not execute.

it does not know; i think that jakob is just commenting on the manner in which
RPLs normally function.  the communities are checked in an order, and once
seen the checking ceases.  Some RPLs offer ways to check all, but the operator
would have to account for that.

i think this discussion is becoming silly.  can god make a boulder so big that
he himself can not lift it.


From nobody Tue Nov 15 14:57:03 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FCCF1294E2 for ; Tue, 15 Nov 2016 14:57:02 -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 yjGic78B1N31 for ; Tue, 15 Nov 2016 14:57:00 -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 25C83129429 for ; Tue, 15 Nov 2016 14:56:59 -0800 (PST)
X-Envelope-To: idr@ietf.org
Received: from cupcake.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 uAFMuuVJ082557 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Nov 2016 22:56:57 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 cupcake.local
Message-ID: <582B92B7.9080309@foobar.org>
Date: Tue, 15 Nov 2016 22:56:55 +0000
From: Nick Hilliard 
User-Agent: Postbox 5.0.5 (Macintosh/20161020)
MIME-Version: 1.0
To: heasley 
References:   <27701_1479159582_582A2F1E_27701_6903_1_53C29892C857584299CBF5D05346208A1EC77FE1@OPEXCLILM21.corporate.adroot.infra.ftgroup> <736EA2CC-3DD1-4F14-96ED-2916E62F6F02@cisco.com> <26709_1479217575_582B11A7_26709_12999_1_53C29892C857584299CBF5D05346208A1EC79584@OPEXCLILM21.corporate.adroot.infra.ftgroup>    <20161115182648.GD94469@shrubbery.net>  <20161115222738.GW94469@shrubbery.net>
In-Reply-To: <20161115222738.GW94469@shrubbery.net>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: idr wg , Robert Raszuk 
Subject: Re: [Idr] One week extension to WGLC for draft-ietf-idr-large-community
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, 15 Nov 2016 22:57:02 -0000

heasley wrote:
> i think this discussion is becoming silly.  can god make a boulder so big that
> he himself can not lift it.

+1

the existing semantics work nicely in practice. There is no compelling
reason to change them.

Nick


From nobody Tue Nov 15 15:17:48 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 624931295C8; Tue, 15 Nov 2016 15:17:43 -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 ATs93DKa0Ijz; Tue, 15 Nov 2016 15:17:41 -0800 (PST)
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0107.outbound.protection.outlook.com [104.47.34.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8F0B1295D1; Tue, 15 Nov 2016 15:17:41 -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=FgyIkOt7BRQdtH3bUZ1WsMD2t30OJJsyocN39Dqwb/w=; b=LGcbRKxH4ulrOZ7t9kgPPJUgnkxQMZ5K0gfJ6gzZ1KPvp+cSf8yCGcfxTb0AbiyBttt2d5YGCSv9SSEhL1kapd7jUd6D/vZoaOS6cfTqFfc+PHxJV05DQ+7F0sUxLVVlmP41q9IMPKIPVhN2svgEKl82cCtlPCUizGa4YjnQ3vY=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; 
Received: from [172.29.192.68] (116.197.188.11) by CY1PR05MB2506.namprd05.prod.outlook.com (10.167.10.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.734.2; Tue, 15 Nov 2016 23:17:37 +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: <34A7D25B-1B64-475A-8116-87BD9A651D75@apnic.net>
Date: Wed, 16 Nov 2016 08:17:15 +0900
Content-Transfer-Encoding: quoted-printable
Message-ID: 
References: <1d8e529a370f4c98b599b48eee7e82ed@tcb.net> <20161114151829.GC67788@dhcp-9341.meeting.ietf.org> <9E85C422-42DB-438B-98BC-DB678E403B12@steffann.nl> <34A7D25B-1B64-475A-8116-87BD9A651D75@apnic.net>
To: Geoff Huston 
X-Mailer: Apple Mail (2.3124)
X-Originating-IP: [116.197.188.11]
X-ClientProxiedBy: HK2PR02CA0056.apcprd02.prod.outlook.com (10.165.70.24) To CY1PR05MB2506.namprd05.prod.outlook.com (10.167.10.27)
X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2506; 2:8yjVGN3+3LMWV+GVhXbQawD4VYvWfU5kW5JAAxuxYCZg2EnJMGY/H+4dTN5HpIuoIDytlXegfrhfgsMRziH0I1e2H0vF++h5DVvFRc9eQWuqCOXVxUb+zLedKWMSleWpFHop6kmC/9tuKCj97q+IsLCjtG1VEP5K/D0NvRUIUCA=; 3:zDw0/X8uxDkZZlQfXbgVMwcZXhdimaot1nbrFDxEfqcnzoEYUD/SyTOkEqcL5PB4PvYVWzwdmdVwavuErTU5BZ04ydBGxbbEJ/uqkmik8u99GgxOS+laFEBBENoUyIEt/ElQUgQ5caFPgPc/3xRtJqXVQw/qJpm3uJ6jnIjOYGM=; 25:Q8V9H57QCLE4AcqI9K5cnzmtFCrZM9Ys2Jxutg3ePtG+x5qv+VYtQZG4E4MNU+rAaDOOqrx9lgJpBiH3mOdozF6zhiYqfUSCsv6nIqucMpxGi7KIDNw2eit0lQYlfWqmngmHj18hnJw4STygfBR1gG+zDESnI7vPWJeKw+iUj5Ql5XyYjpZk6MfvX6WSwzgN4eWwPWPCyW6iUNsYmn1AdRfbPA6sP1crSRLwC7KmBdsANRutA187rZIdsFXKt8Qqkc4Fz8faYTMWeJFsxlZ11/sd4i6zf/LDOJ+TXTGSy8BQFmNreH8xtonGuqF+i/L/LCtPgPYReQi/DxNBBO5B0AKsr6BWmbJGTobi0EsGV/IQW0eLD0dqFk6QYvzELv6Aw9h2Vduk8isulV2SKTgpma6CQ9SPQWZOoh/aLmvXaQEPrr1KHWamBWkvNztV6upuLrRhUZ2V+Q8rW2xbpAQYpQ==
X-MS-Office365-Filtering-Correlation-Id: 213eb711-b29e-4283-1a8e-08d40dad9884
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR05MB2506;
X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2506; 31:cXwjqb0qsfAHCus0J0hZAaqAh686KFJbwRQo7pTAf8bCClTHjXvfGizDyuowiR+4dfnkmg4WHwCZaE3mip21lIO43oWskDy4EEJ+ZwBkTBsn5C1U0i4Z1IhGC4LB79hzHyO5csNSdxkofGCWWa58yPhTZB2NU5SKUogcPb1ml0u2uEOd4mYZLmLO7A+Gq+xue74atW7eTZAC5e4ZjjscQwSTRyySg1kpUudRQiZbvrviqfBoRKvpusxJUmoYmxAiCsKRbw8mwKKUOzblTiUdJwRBhpINuT5CRouv2msSYL4=; 20:M2jKXF18j3WxoT4mIICvJP9WHzBraE0iaRtWiFf7s+Qsg/jjLCoNAjbRDPIaZfqD1woPyEm/UZAub67Dl8+RarXWRJ9jt4Lb7JHSJH3Ou7+ZzGRUYofcMD8cTOH5qkGh6XXZZQ9kE1rdtenRUJ/Uz/docWHn2JdhUWiWARxv417GB4NrNGJlPnziLVghJuvlAAmaJnS1I4Trf0Nor3TWloLVenrHJJDqJh90atM3/CuGJKafSPGvVwHsaHz21mvqESqaAlIn4iGKylkI5iEhPoXUpjUrWAbsjqZKSbiCWXU3HBZ0BRsVBxq32b3u8GdLUiwA+PFgmbAIkhfVtH64QbEh7evJiosu4F5cJSMeGDrtutZhQW/FNscXpEYa6saM79Xs6iTKx0YuFNEg3byUu/x5TSvtFZ9E2VM56b68il+dhuemNR4N5DfUhhTXHm43D1YWWkjFPE3HZKnouFNwFjyyb7spSZY+BLyPKxJaHdff3VTciGxTpSTEu5prtVfh
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6060326)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6061324); SRVR:CY1PR05MB2506; BCL:0; PCL:0; RULEID:; SRVR:CY1PR05MB2506; 
X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2506; 4:5JTpQ25tDjEUNvpoIr0IjYTUo2ea8E2szbyLi0BYF4xCpXjC7t+HfUrvuV1f8gz8nOBAOQQEBWM6KeE7ObX9UyhKcRvuuLoQvNVd4xBPn+WmhQUczdlAFTcUl1xZL5oWHu6sbqm15s4b+pWDuexdRJ3i3QmWUYRhnh+xGbu57yE8JWCoDxrd+GO/knzEvRjFvkogHomYrt3UQL8n0Ol7FNVYqS+1VcVJOeoSO/dpaa4ybJaHg4WyOWQ9VSJFEBlyvbT7R6t5OEXF5h3TcgY2xKmB+1E3BZsvaFdM6R+2hWBtFD3sbrQat6jFEib5E461f20FDM4aivaYaIw5q0BDrdQAOrA49lRXNCeQBTKWU4W2al7hAn8RsLdu76DhZ5FwNWL3JC1bEHTU6Ui9NFBEySCxzvMiFNBPddTgIpaI0DE2X+02SiQq9zqMJX9qilWy
X-Forefront-PRVS: 012792EC17
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(7916002)(377454003)(189002)(199003)(24454002)(5660300001)(230783001)(4326007)(229853002)(110136003)(92566002)(93886004)(6666003)(305945005)(6916009)(2950100002)(7736002)(86362001)(82746002)(97756001)(83716003)(2906002)(189998001)(77096005)(68736007)(7846002)(76176999)(105586002)(50986999)(101416001)(42186005)(23726003)(50226002)(97736004)(47776003)(46406003)(6116002)(106356001)(3846002)(81156014)(8746002)(57306001)(66066001)(36756003)(33656002)(50466002)(561944003)(81166006)(42262002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2506; H:[172.29.192.68]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR05MB2506; 23:W5eyd/zrPEImqAgO3WKwj/oALdtEbpgXxir4dHWQ3?= =?us-ascii?Q?UoMB0Usj7Sxx4yHgY0OONfCmmpI2xOc2k+xcRNfBpqzw4dOMQgPKMl/KLxPY?= =?us-ascii?Q?eBQeDCQhNl2SsdUafQAFciB8c8vwETZoruIgmT05Vf8bknoGPv8U0BbE86Uo?= =?us-ascii?Q?AsaXWqFB1fHqUfJFAcRHpz3AX4hJ0hoAZiRWwQ33/7AFuWXBjig1OIfL6JvX?= =?us-ascii?Q?jMxVy2QucQm4M50MAAocrRPg4217JgNfh8f9yPFO/4lF012PZ+3EzFcTuEmB?= =?us-ascii?Q?zNaWXSecnSn2kfdpVpWUkaGoZawi6rtfQ6mzHaXURXOFyrmGdHYpIwuc8sfg?= =?us-ascii?Q?FPyjPIS0H5CUMG88yDaIsHsHjZVSpR1XPKGETXg+WDaWaEHN/17vn/mH5ump?= =?us-ascii?Q?sOakxRcBVoi/QSFtQ76i/jMXMGYyJYvW0acTVAAlEAH6OaFnkCLONs/msxZ7?= =?us-ascii?Q?d9kB1Rjxuu63MHZZ19IYXL79L+151YJ6DvAgnTpQl5nQxD1SYtEZQJ1oPIvp?= =?us-ascii?Q?WbLSN/e6beIB3fkfWX2JuSkZQseOqrGygFF/NZMUr17k4QP9FW4XckLRt9L6?= =?us-ascii?Q?4IaeQApDy3Ho5kPoVQR6hbf1tVLH6cAimFk/WExubry6QKIHv6LPBY3dLQmJ?= =?us-ascii?Q?XlDTQX2YZgPecrSn/mxJaVmhHCxj38SzVbty+1aQzW6aHdpNtNE0Gx2HuYvR?= =?us-ascii?Q?rLKjcvkKji0V5QzOKedT7NnHFehdTDGfJ5iNZZLzUs5KruVjyQtPwrd2Kc3P?= =?us-ascii?Q?do0G34E6UufrddCeyp7MnhxO0PnZcuKHLhnxmzJaDLguVrs7xT1aG95XqLcv?= =?us-ascii?Q?qDH+T7H2ltQ3YWe8zn077IhpkQG7q7W+M7yrOgju/pffd+JRuAEQsL6w2Rky?= =?us-ascii?Q?5z2E7s/PMLbteik6xSK4g8YSyufD7jeqfhCn8hQXf1cgRb3becXXBBMlqMvS?= =?us-ascii?Q?qvQdyOJJHGTHZRWY+SP4bZ9fEkAM46PYlaRfZ+oZRcu9PZEoh4vL+Z7N848c?= =?us-ascii?Q?Udm1+xkH0I54S8srGe3jWPFShFPnvTZa/NX6RsoVNPUeDh+RQSpZGUHXeBxG?= =?us-ascii?Q?BbYrRzISOMfPH5Y/coj7FivNZG9ezxHzxrPBhuCdHakOtaj3kTLOjSaLm7Q5?= =?us-ascii?Q?sZ5AcknaAK2RgVDammYHxrHdP8zb8CLGyzR9+MRXaLn0It0EdbIEKJmqNmBH?= =?us-ascii?Q?vlSrJ6s1urh9tD1AsZoaS9enMzmEOWgJnEDtTvE7eTH5A4b3SdGpMu6gmvYk?= =?us-ascii?Q?m9M7eI2LjEbIZMu3sA=3D?=
X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2506; 6:E5iXsGkQu3P1w+VFJ6QjSrFrpHQwwlk6wzxs4OOsiyJoVW5Irf+gA5A/cacIz96gdlp+ueOWmTt2Pcm5cVIZSDoE4aEaUfDZ0pxJC3bngCg/bX6SKYJ/q/oVbonlxdCRnwqCeHfLIbr8MxAbaIL10abnLeeug1dVNFJQMMDHao1Rp0NTArBz+Jz62tKLH8kAyRLZiGpYsRA9lphSCPmYvdkfKsyt3qebIqr0mtm5+dWofyaqH5BE/ZDNOTAUa7yptDbOjaCr2fYY6e03UjLV/5dgRoQiMnkXpilini9r3DeWkQoSGgC7z2NUW8NjM2EH6qbU0xf4PeHnzyhMO3juJqRwWEouuVSWpgX+Cjimik4f8JeQGVuK5F2VrpKR87K1; 5:Zs7P40UzVgboGhypq1cdEBWoJXBPp7Eh+2zlt+VTTHlfyEhlr/XScavTbTaM8fejNkcyQ8CwWWgctwWdOqZdA+x0ttLf8tYzLnPFBIVaGeQhpOkQ8CnyvSousbgL/ysBPBXb4o8Ca599bFbkkk3JXw==; 24:Vwin15Q12vzkqgRoTZdOFhdQZVQdDV8RwsV9qc5IAVqDTV8daval0tkYlHTueqZsYuK+dG0LT5zhB/+EQS4rtygFihycqwgDzfrje5YKTH4=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2506; 7:py5hvWFYGiYZX7J9m/VyBZFIjPCwVWnhwDzbB2Rb34SIxn0GvnJmoTxQOlejqZxnhcnIMeq9j0/Uc3olZLlPhBuRa+WYTYDZFOX0YE4/26kpTp9RnDHp5ELaiDaqgHAN5qgYvvjBYgOS3CFsBGZ+tI8VWJvxhH2YQacUrl3aRJ89awJAJBTD77q6mg3TLQ+SPUUpCDPD/WTmscRl6d7okXBe3bqffkPWb5PuCXrL5iNgB6H+e4Dxv/gQQCqh/rBC4zJRlOSKa06RBNedIlogmHGmFKrUjFvKbC5LVwvoa/R/hTh3QtaEh3RJWvAEkGYSjxhd9DxeK0KEexIHosR0HG7qO0yTMO2v/9OasqVsz4A=
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Nov 2016 23:17:37.5805 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2506
Archived-At: 
Cc: idr@ietf.org, rtg-dir@ietf.org, Danny McPherson 
Subject: Re: [Idr] [RTG-DIR] RTG-DIR REVIEW:	draft-ietf-idr-large-community-08
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, 15 Nov 2016 23:17:43 -0000

Geoff and Sander,

> On Nov 15, 2016, at 11:52 AM, Geoff Huston  wrote:
>> On 15 Nov. 2016, at 3:24 am, Sander Steffann  =
wrote:
>> Please see my previous email to John about SHOULD/MUST here. With =
that in mind:
>>=20
>>> To put this in different words: if the paragraphs remains as it was
>>> (like in -07) with the words "SHOULD", implicitly we acknowledge =
that
>>> there _might_ be a semantic meaning in signalling duplicate =
communities.
>>=20
>> I agree that there MUST NOT be semantic meaning in duplicate =
communities. How about:
>>=20
>> """
>> Duplicate BGP Large Community values SHOULD NOT be transmitted.  A
>> receiving speaker SHOULD silently remove duplicate BGP Large
>> Community values from a BGP Large Community attribute. If a community
>> value is received multiple times this MUST NOT be treated differently
>> than a community value that is received only once.
>> """
>>=20
>> as a middle ground?
>=20
> I think this test is a good way forward.

I got a little confused because the conversation took place in two =
threads. However, in looking at time stamps I think Sander's proposal =
quoted above was overtaken by his later, in the other thread:

On Nov 15, 2016, at 8:36 AM, Sander Steffann  wrote:
> Please count me as neutral on the issue. I'm fine with either wording,=20=


and so on (this is in the thread "One week extension to WGLC for =
draft-ietf-idr-large-community"). So, unless Sander says otherwise, I'll =
suppose his concern from this thread has also been addressed without =
need for "middle ground" text. I think the case for why the "SHOULD" =
text is not needed and is (mildly) harmful has been made already, but to =
summarize for convenience: Since we agree "there MUST NOT be semantic =
meaning in duplicate communities", there seems no value in leaving the =
door ajar (with a SHOULD) for such semantically meaningless dups to be =
transmitted anyway. There also seems no practical value to leaving it =
ajar for them to be stored on receipt, although as a practical matter =
there's not going to be a way to detect this in a black-box test as long =
as the MUST NOT transmit and MUST NOT have semantic meaning parts are =
honored. The value of MUST discard duplicates is principally in telling =
the implementor "you don't need to go to any trouble to store dups much =
less affording them special semantics."=20

Geoff, if you feel there is a need for the "middle ground" text quoted =
above, I would be interested in knowing why. (We could also chat f2f if =
that's easier for you.) Or if your concerns have also been assuaged, if =
you could confirm that to the list it would be helpful.

Thanks,

--John=


From nobody Tue Nov 15 15:40:10 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A53871293D8 for ; Tue, 15 Nov 2016 15:40:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level: 
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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 E7phCX9EsiFa for ; Tue, 15 Nov 2016 15:40:06 -0800 (PST)
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 BD8231294FD for ; Tue, 15 Nov 2016 15:40:05 -0800 (PST)
Received: by mail-wm0-x22a.google.com with SMTP id a197so201634220wmd.0 for ; Tue, 15 Nov 2016 15:40:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=m5z0LAAZ70c8Oee9oo5YBNeOB2K8e5mRkq7Ld7gjMRY=; b=k+Tf0HZlEYlQDoZwKcciMRXiFfs63V1A5V9UZQp3b0kTKUWzCkBqu+96ulEuoWeCqj r/TZUHZwP7wxKdgkqx76cIswwIWLbXiXu81K/Oe0cO1rI29SILc3tB2mCOcYD0DOatT/ H7W4wlUoI6Sy7TuL4S/InBCjfs0xlNG22dOu+/c59iHYoodLWmwKfzdvRY4FMUvlK9Mj Gh4DCtTBIRTYU4ZK0R6A10CzPgU+WwawbgqV6r006/jS6bhaZiHgTmbXHxf7GBcigbea vhGmY2QoGtxJQUOEv/xg3aQK93qhJvI8AJf7hqqpgHzvJUM+AMX913eZnOdWJdNMP2yg Y4xg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=m5z0LAAZ70c8Oee9oo5YBNeOB2K8e5mRkq7Ld7gjMRY=; b=UTlc3UoEub2ZO8SN1fheaNaGOHaPEDzyB8itUTXc28urYRKrvYwTaK1VTqZC9MdnqT Alk7zpCmj7leW0OF1mv05cjRogST1A6gKERhZ36yS9EBtHa07Cv3Q4KNr+AVNCNCIcbI aGGeiPSbMUTsmaTsYzJClUco7Vvp3MdtCV6Ck3Yfm7VVXQxM6qehCwySJSIlwAMq8Dll zT+lEyWOUtExH07TbeUFcT2c+Om7SPVDeViKAMwFQiH3KyvZLqdEXZNctwwf6mpu7Dx3 ZoXW65iSNFQCKekrOqNtMMYHsUGkh2WSfnr1F7vrniIbj3xDVCQ5CHig4me3GJr5MD6a Lgiw==
X-Gm-Message-State: ABUngvfKR1hOIzUKx3UEthvm8tEe2UfLfhicH0z2ozafHYWY8J5l0zm5qsohx8KIrbxw2u4IzsSquktoLypxYQ==
X-Received: by 10.194.26.133 with SMTP id l5mr26336662wjg.4.1479253204351; Tue, 15 Nov 2016 15:40:04 -0800 (PST)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.80.137.69 with HTTP; Tue, 15 Nov 2016 15:40:03 -0800 (PST)
Received: by 10.80.137.69 with HTTP; Tue, 15 Nov 2016 15:40:03 -0800 (PST)
In-Reply-To: 
References:   <27701_1479159582_582A2F1E_27701_6903_1_53C29892C857584299CBF5D05346208A1EC77FE1@OPEXCLILM21.corporate.adroot.infra.ftgroup> <736EA2CC-3DD1-4F14-96ED-2916E62F6F02@cisco.com> <26709_1479217575_582B11A7_26709_12999_1_53C29892C857584299CBF5D05346208A1EC79584@OPEXCLILM21.corporate.adroot.infra.ftgroup>    <20161115182648.GD94469@shrubbery.net>  <20161115222738.GW94469@shrubbery.net> <582B92B7.9080309@foobar.org>  
From: Robert Raszuk 
Date: Wed, 16 Nov 2016 00:40:03 +0100
X-Google-Sender-Auth: _fpC8kFkgK-w1UDMr3z5Zl-MAwc
Message-ID: 
To: Nick Hilliard 
Content-Type: multipart/alternative; boundary=089e0160a4d6c7407605415f79a9
Archived-At: 
Cc: heasley , idr wg 
Subject: Re: [Idr] One week extension to WGLC for draft-ietf-idr-large-community
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, 15 Nov 2016 23:40:08 -0000

--089e0160a4d6c7407605415f79a9
Content-Type: text/plain; charset=UTF-8

If large is to be like 1997 and if current semantics works why is this
entire debate of special handling duplicates.

Entire section can be removed and what the guy who is inserting and the one
who is acting on be left completely up to them.

Thx,
R.

On Nov 16, 2016 7:57 AM, "Nick Hilliard"  wrote:

heasley wrote:
> i think this discussion is becoming silly.  can god make a boulder so big
that
> he himself can not lift it.

+1

the existing semantics work nicely in practice. There is no compelling
reason to change them.

Nick

--089e0160a4d6c7407605415f79a9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


If large is to be like 1997 and if current semantics works w=
hy is this entire debate of special handling duplicates.


Entire section can be removed and what the guy who is insert=
ing and the one who is acting on be left completely up to them.


Thx,

R.



On Nov 16, 2016 7=
:57 AM, "Nick Hilliard" <ni=
ck@foobar.org> wrote:
heasley wrote:

> i think this discussion is becoming silly.=C2=A0 can god make a boulde=
r so big that

> he himself can not lift it.




+1



the existing semantics work nicely in practice. There is no compelling

reason to change them.



Nick





--089e0160a4d6c7407605415f79a9--


From nobody Tue Nov 15 15:54:05 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A13731293D8 for ; Tue, 15 Nov 2016 15:54:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SAMjJfsb05hR for ; Tue, 15 Nov 2016 15:54:02 -0800 (PST)
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 2469B127076 for ; Tue, 15 Nov 2016 15:54:01 -0800 (PST)
Received: by mail-wm0-x230.google.com with SMTP id a197so202175583wmd.0 for ; Tue, 15 Nov 2016 15:54:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dtoaFtK9Dasvlnt0lgJiNGAA+Vmr0lDcvlGdR/6s8sg=; b=ZvBNuLdaCwlFOAYhy57g0WHwGzrA4oyiJVJWPjS6yidUO7wbf9nzP3WG5fvKwzuxMY qPGqJrza5q/aa/IvrwRa7tfjjMIJx/U4cy2EeYIMwhchRVyDWxZIU9H4/aol4ThxLWHK KWe9NCE5JrF3fXAeOwucQLKxiAkE1Jm68ci4vvI1rMj39uc6rvDO9laFj1Tw0kv+4oam EcwcaDAuLHBkYVhkbqDAwhYdNzVMSj9hjBVWbbm6BlhHAVq3Fo2+fAfQjeIjMGl4t2so xl2bcEZB7f1VWDbD4PdD6iX1TxxH5qdhnBElYn/Og0+t5piyfDiogIfRj8VPvjZLS7NC hseQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dtoaFtK9Dasvlnt0lgJiNGAA+Vmr0lDcvlGdR/6s8sg=; b=kDvlEyxyvmjOepm5WcOe6gzeVPr1qjupzgSfXXT7WKK15NUOo0OaD99ybkRFWH3U0e hOooAtInXRlELwUElAgQcxJPgHy0Ux1I/PmoPyrIE/mPXgIs0aSSBLEc5DbuZbkAaL1P c+luWjVMXj0QF/Av0cUW6uHIz/XTCcYqC7/WxpnUS/hHEqXJ+OFeHZSMtaQDhYcPDtei KxT7kfcX5j3PXi1clH9TGYri+4JJYzOA2SLL6Do1Xiom9GQKn8iLAMpMfWQWfDG2udyJ 1r+YShZFRg+BQeFAu6u9bfzj2gilsmwPyOJhfmpP6hq6FtBKfybsomcD3KnIIaEiUD0g zxFg==
X-Gm-Message-State: ABUngvdTJTwVSFveWsGm/j1rdf+DIgZPS7cxMqrcvHshe2pXAkUphdVUoZjjkJgTQSwkmmvU3NvrQxPA5Vas8Q==
X-Received: by 10.28.208.203 with SMTP id h194mr6225017wmg.45.1479254039667; Tue, 15 Nov 2016 15:53:59 -0800 (PST)
MIME-Version: 1.0
Received: by 10.28.197.132 with HTTP; Tue, 15 Nov 2016 15:53:58 -0800 (PST)
In-Reply-To: 
References:   <27701_1479159582_582A2F1E_27701_6903_1_53C29892C857584299CBF5D05346208A1EC77FE1@OPEXCLILM21.corporate.adroot.infra.ftgroup> <736EA2CC-3DD1-4F14-96ED-2916E62F6F02@cisco.com> <26709_1479217575_582B11A7_26709_12999_1_53C29892C857584299CBF5D05346208A1EC79584@OPEXCLILM21.corporate.adroot.infra.ftgroup>    <20161115182648.GD94469@shrubbery.net>  <20161115222738.GW94469@shrubbery.net> <582B92B7.9080309@foobar.org>   
From: Brian Dickson 
Date: Tue, 15 Nov 2016 15:53:58 -0800
Message-ID: 
To: Robert Raszuk 
Content-Type: multipart/alternative; boundary=94eb2c193eac91287005415fab3f
Archived-At: 
Cc: heasley , idr wg 
Subject: Re: [Idr] One week extension to WGLC for draft-ietf-idr-large-community
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, 15 Nov 2016 23:54:03 -0000

--94eb2c193eac91287005415fab3f
Content-Type: text/plain; charset=UTF-8

The current IMPLEMENTATIONS handle the issue of duplicates.

The "large" I-D raised the question of whether to memorialize the correct
behavior.

IMHO, the absence of it in 1997, is an issue to raise in a future 1997-bis.
(I think it's a bit too big to do as an errata.)

The current language in large needs to be kept.

IMHO.

Brian

On Tue, Nov 15, 2016 at 3:40 PM, Robert Raszuk  wrote:

> If large is to be like 1997 and if current semantics works why is this
> entire debate of special handling duplicates.
>
> Entire section can be removed and what the guy who is inserting and the
> one who is acting on be left completely up to them.
>
> Thx,
> R.
>
> On Nov 16, 2016 7:57 AM, "Nick Hilliard"  wrote:
>
> heasley wrote:
> > i think this discussion is becoming silly.  can god make a boulder so
> big that
> > he himself can not lift it.
>
> +1
>
> the existing semantics work nicely in practice. There is no compelling
> reason to change them.
>
> Nick
>
>
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
>

--94eb2c193eac91287005415fab3f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


The current IMPLEMENTATIONS handle the issue of duplicates=
.

The "large" I-D raised the question of wheth=
er to memorialize the correct behavior.

IMHO, the =
absence of it in 1997, is an issue to raise in a future 1997-bis.
(I think it's a bit too big to do as an errata.)

<=
div>The current language in large needs to be kept.

IMHO.

Brian

On Tue, Nov 15, 2016 at 3:40 PM, Robert Ra=
szuk <robert@raszuk.net> wrote:
If large is to be like 1997 and if current semantics w=
orks why is this entire debate of special handling duplicates.


Entire section can be removed and what the guy who is insert=
ing and the one who is acting on be left completely up to them.


Thx,

R.



On Nov 16, 2016 7=
:57 AM, "Nick Hilliard" <nick@foobar.org> wrote:
heasley wrote:

> i think this discussion is becoming silly.=C2=A0 can god make a boulde=
r so big that

> he himself can not lift it.




+1



the existing semantics work nicely in practice. There is no compelling

reason to change them.



Nick






_______________________________________________

Idr mailing list

Idr@ietf.org

https://www.ietf.org/mailman/listinfo/idr





--94eb2c193eac91287005415fab3f--


From nobody Tue Nov 15 16:09:54 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72266129556 for ; Tue, 15 Nov 2016 16:09:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.399
X-Spam-Level: 
X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, 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 SQqvtBK0T3Eq for ; Tue, 15 Nov 2016 16:09:52 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 937F01294A6 for ; Tue, 15 Nov 2016 16:09:52 -0800 (PST)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 152981E337; Tue, 15 Nov 2016 19:12:47 -0500 (EST)
Date: Tue, 15 Nov 2016 19:12:46 -0500
From: Jeffrey Haas 
To: Brian Dickson 
Message-ID: <20161116001246.GB27230@pfrc.org>
References:   <27701_1479159582_582A2F1E_27701_6903_1_53C29892C857584299CBF5D05346208A1EC77FE1@OPEXCLILM21.corporate.adroot.infra.ftgroup> <736EA2CC-3DD1-4F14-96ED-2916E62F6F02@cisco.com> <26709_1479217575_582B11A7_26709_12999_1_53C29892C857584299CBF5D05346208A1EC79584@OPEXCLILM21.corporate.adroot.infra.ftgroup>  
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: 
Cc: bruno.decraene@orange.com, Robert Raszuk , idr wg 
Subject: Re: [Idr] One week extension to WGLC for draft-ietf-idr-large-community
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, 16 Nov 2016 00:09:53 -0000

On Tue, Nov 15, 2016 at 12:44:04PM -0800, Brian Dickson wrote:
> Regardless of the rationale on the parts of AS1 and/or AS2, here is the
> semantic issue:
> A given community is a FLAG. You can use any number of DIFFERENT flags
> (community values), but each community value can only be "present" or
> "absent".

For what it's worth, I always explain communities as being a "set", in a
mathematical sense.

In that notion, A union A yields the set containing A, etc.

Match operations are typically either intersect or proper subset operations.

-- Jeff


From nobody Tue Nov 15 16:15:51 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2E431294A6 for ; Tue, 15 Nov 2016 16:15:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.399
X-Spam-Level: 
X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, 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 zYn6nrTfKlRh for ; Tue, 15 Nov 2016 16:15:49 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id AEE2F127076 for ; Tue, 15 Nov 2016 16:15:49 -0800 (PST)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 620581E337; Tue, 15 Nov 2016 19:18:44 -0500 (EST)
Date: Tue, 15 Nov 2016 19:18:44 -0500
From: Jeffrey Haas 
To: Gert Doering 
Message-ID: <20161116001844.GC27230@pfrc.org>
References: <147910154788.10388.9578791609428008498.idtracker@ietfa.amsl.com> <20161115044027.GI67788@dhcp-9341.meeting.ietf.org> <20161115055431.GB5875@pfrc.org> <20161115092505.GQ79185@Space.Net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20161115092505.GQ79185@Space.Net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: 
Cc: idr@ietf.org
Subject: Re: [Idr] New Version Notification for draft-ymbk-idr-bgp-open-policy-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: Wed, 16 Nov 2016 00:15:50 -0000

[responding to this item in preference to the others]

On Tue, Nov 15, 2016 at 10:25:05AM +0100, Gert Doering wrote:
> On Tue, Nov 15, 2016 at 12:54:31AM -0500, Jeffrey Haas wrote:
> > On Tue, Nov 15, 2016 at 01:40:27PM +0900, Job Snijders wrote:
> > > Have you considered using two BGP Well-known Communities instead of
> > > defining two new attributes 'IOTC' and 'EOTC'?
> > 
> > Some providers seem to strip even well known communities.  :-)
> 
> These communities must not leave the local AS (because what is a 
> customer prefix to one AS might be a *peer* to another), so stripping
> on AS boundaries is a desirable feature.

My sarcasm was missed.  Mostly, communities are not sufficiently safe from
meddling as part of *standard* operational procedures for them to be great
candidates for providing enforcement in this proposal.  As noted in other
conversations, mostly on grow in prior months, they're *sufficient* from an
encoding standpoint to make a start for this.

I support the idea of encoding this in path attributes mostly since it
insulates it better from accidental deletion.

With respect to your point about relationship differences, I'm not sure the
authors of the draft would agree with your assessment.  I'll leave it to
them to comment on the case in question.

-- Jeff


From nobody Tue Nov 15 19:03:14 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C78E1295E5 for ; Tue, 15 Nov 2016 19:03:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.398
X-Spam-Level: 
X-Spam-Status: No, score=-8.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, 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 bUtsDZd6pnAM for ; Tue, 15 Nov 2016 19:03:09 -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 4F2531295C9 for ; Tue, 15 Nov 2016 19:03:09 -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 1c6qV9-000764-1v; Wed, 16 Nov 2016 03:03:07 +0000
Date: Wed, 16 Nov 2016 12:03:05 +0900
Message-ID: 
From: Randy Bush 
To: Peter Hessler 
In-Reply-To: <20161115092211.GK24817@gir.theapt.org>
References: <147910154788.10388.9578791609428008498.idtracker@ietfa.amsl.com> <20161115044027.GI67788@dhcp-9341.meeting.ietf.org> <20161115055431.GB5875@pfrc.org> <20161115092211.GK24817@gir.theapt.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: 
Cc: idr@ietf.org
Subject: Re: [Idr] New Version Notification for draft-ymbk-idr-bgp-open-policy-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: Wed, 16 Nov 2016 03:03:13 -0000

>>> Have you considered using two BGP Well-known Communities instead of
>>> defining two new attributes 'IOTC' and 'EOTC'?
>> Some providers seem to strip even well known communities.  :-)
> 
> As I understand it, this is only intended to matter for directly
> connected peers so filtering can (and should) be done before any
> stripping is done.

this may all be true, but is irrelevant.  this is not a community, but
an attribute; speifically to avoid my fat fingers.

randy


From nobody Tue Nov 15 19:09:04 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B1891295E5 for ; Tue, 15 Nov 2016 19:09:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.432
X-Spam-Level: 
X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_SOFTFAIL=0.665] 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 qFEh4qqSPYhK for ; Tue, 15 Nov 2016 19:09:02 -0800 (PST)
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 81678129632 for ; Tue, 15 Nov 2016 19:08:58 -0800 (PST)
Received: by mail3.mlpsca01.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1c6qam-000CqF-Ix (job@us.ntt.net); Wed, 16 Nov 2016 03:08:57 +0000
Date: Wed, 16 Nov 2016 12:08:53 +0900
From: Job Snijders 
To: Randy Bush 
Message-ID: <20161116030853.GD1073@dhcp-9341.meeting.ietf.org>
References: <147910154788.10388.9578791609428008498.idtracker@ietfa.amsl.com> <20161115044027.GI67788@dhcp-9341.meeting.ietf.org> <20161115055431.GB5875@pfrc.org> <20161115092211.GK24817@gir.theapt.org> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.7.1 (2016-10-04)
Archived-At: 
Cc: idr@ietf.org, Peter Hessler 
Subject: Re: [Idr] New Version Notification for draft-ymbk-idr-bgp-open-policy-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: Wed, 16 Nov 2016 03:09:03 -0000

On Wed, Nov 16, 2016 at 12:03:05PM +0900, Randy Bush wrote:
> >>> Have you considered using two BGP Well-known Communities instead of
> >>> defining two new attributes 'IOTC' and 'EOTC'?
> >> Some providers seem to strip even well known communities.  :-)
> > 
> > As I understand it, this is only intended to matter for directly
> > connected peers so filtering can (and should) be done before any
> > stripping is done.
> 
> this may all be true, but is irrelevant.  this is not a community, but
> an attribute; speifically to avoid my fat fingers.

yes, however a downside is that there is no "backwards compatibility",
in the sense that I can't implement it myself in routing policy and
require my vendor to give me new software.

Working group should be aware of that consequence.

Kind regards,

Job


From nobody Tue Nov 15 19:11:33 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68B77129621 for ; Tue, 15 Nov 2016 19:11:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.398
X-Spam-Level: 
X-Spam-Status: No, score=-8.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, 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 AzceNn6ZEr6G for ; Tue, 15 Nov 2016 19:11:31 -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 0442A12957F for ; Tue, 15 Nov 2016 19:11:31 -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 1c6qdD-000795-N2; Wed, 16 Nov 2016 03:11:28 +0000
Date: Wed, 16 Nov 2016 12:11:25 +0900
Message-ID: 
From: Randy Bush 
To: Job Snijders 
In-Reply-To: <20161116030853.GD1073@dhcp-9341.meeting.ietf.org>
References: <147910154788.10388.9578791609428008498.idtracker@ietfa.amsl.com> <20161115044027.GI67788@dhcp-9341.meeting.ietf.org> <20161115055431.GB5875@pfrc.org> <20161115092211.GK24817@gir.theapt.org>  <20161116030853.GD1073@dhcp-9341.meeting.ietf.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: 
Cc: idr@ietf.org, Peter Hessler 
Subject: Re: [Idr] New Version Notification for draft-ymbk-idr-bgp-open-policy-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: Wed, 16 Nov 2016 03:11:32 -0000

>> this may all be true, but is irrelevant.  this is not a community, but
>> an attribute; speifically to avoid my fat fingers.
> 
> yes, however a downside is that there is no "backwards compatibility",
> in the sense that I can't implement it myself in routing policy and
> require my vendor to give me new software.
> 
> Working group should be aware of that consequence.

that's why it is in idr not grow.  our fat fingers have been making
negative news headlines for over two decades, and it needs to stop.

randy


From nobody Tue Nov 15 20:01:25 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2878129575 for ; Tue, 15 Nov 2016 20:01:23 -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 gsNWWut8wmDF for ; Tue, 15 Nov 2016 20:01:22 -0800 (PST)
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0129.outbound.protection.outlook.com [104.47.42.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 C26541294F7 for ; Tue, 15 Nov 2016 20:01:21 -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=CDAw0szAII54Ax8gj7XycxejA7AtB1G8pDw1daPwPNg=; b=R1BTv/fS4JaDstruDixL8UwmcR/z7OuRaHkXyr2Dx7qpY8CbVdBmtbrew3zq1TtD6uDbcVxjiynIqjM0v1sgXF+hd4UdZ9j+CnMP0A7k6a+nAAnDws8gF5qnUUd0LFO6mVGaO8lrutk14Io2cREX/fFucZyM6DcrjozJxX/WjnA=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; 
Received: from [172.29.192.68] (116.197.188.11) by CY1PR05MB2506.namprd05.prod.outlook.com (10.167.10.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.734.2; Wed, 16 Nov 2016 04:01:19 +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: <20161116001246.GB27230@pfrc.org>
Date: Wed, 16 Nov 2016 13:01:03 +0900
Content-Transfer-Encoding: quoted-printable
Message-ID: <4EB6222D-86A4-4A83-AF8C-364CB52B8422@juniper.net>
References:   <27701_1479159582_582A2F1E_27701_6903_1_53C29892C857584299CBF5D05346208A1EC77FE1@OPEXCLILM21.corporate.adroot.infra.ftgroup> <736EA2CC-3DD1-4F14-96ED-2916E62F6F02@cisco.com> <26709_1479217575_582B11A7_26709_12999_1_53C29892C857584299CBF5D05346208A1EC79584@OPEXCLILM21.corporate.adroot.infra.ftgroup>   <20161116001246.GB27230@pfrc.org>
To: idr wg 
X-Mailer: Apple Mail (2.3124)
X-Originating-IP: [116.197.188.11]
X-ClientProxiedBy: HK2PR04CA0021.apcprd04.prod.outlook.com (10.162.205.159) To CY1PR05MB2506.namprd05.prod.outlook.com (10.167.10.27)
X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2506; 2:nydSg+04q5jH//exWCRz/eki+/fERPUOyyq94VQxAbl6D3JMtP8bhtmNQIaMiMDr0MBR0oSUBA3Jx1VIKHMCFm8uaD2cYKNZjeaO7wn+nbBWCjWEYV9ip6ScNRa1fw8rJ5rLrPy0584qv8mRh2ER4j78P821VKDvMNjZTc+rs6w=; 3:wSyYnmc5UVj+LNrsrehzY/KFOwgGgC/2EbblMDmyrbQgxsA2JykwLf1NbUUDxfRbcozkFuUKwA6GJPNmgSElohkL56+axyB9K86LQ6qFKiOfg5TVQbY+x+6gq4SSFnXZbgpXq2xxovZLZ1MDehKNvD9dGLzT9nR0h5pOJQhXsGo=; 25:/wH/HebLQ9CHUPTIEp5w0fBf5uGcD4miQz212YSeEXr9t8jpglSmDF9X2209PfM85a0TeWGUWGFcm0f5rFAir6LzDPYAXEGzvtxYqRf4nAMqYeqQL4t0M1y1/DoUabpXB1cfb9ocEFNUJ+Nxd2RLr3I+Tjojt0+moS8XLk51eq1aChMHicB9SV8fsfanlbBw43FBrRPbianYcfR92HDiE23JS7mRHchZRNt+iTw+vBuQV5wgRdZ4ggjo67XlZxWC1Wj++fARxhhToljpxmyMeGttLtf/dvoegi03nvK9VmG8M389Hl/SBmqNhjtqlEgtvVnhnA/JzuPUCl/QxMb+9M3FOnNMl+0swwIBGOR/uFgDeYTlaZtjyS3W4zR5oS5j2jUP7KmY3XW4q7CF1YaCKK4Iwdd5CmnogSq7lY7znAodbTAExbLnCurbdE/AEIzkE4UdXq5++pJsSN/i+2zRSA==
X-MS-Office365-Filtering-Correlation-Id: 2c4f5217-ccd5-46d6-2b12-08d40dd53959
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR05MB2506;
X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2506; 31:AOFzCgBAtJGydtlmQ0SVzj01fth0znPok8Gtyd9KZD4YFizy0NSKoEdZBg0TXwCH41lIuL0gKe4xInasLfgDqBnODrXGKyRiheyJPeFiWyd8i2kNlgCr8Qk8oFxqI3R9Ex3JQTafx7QlmxqEjm8j8WhVzviMRym7YUCPDxs9hcWNOYc4/m9sUTuLd3PagIX4QzzjoiAseGgktfMMpkZM7N7KeS8UdAnpcT1YD+ikvCFKziFCmndCE7IpRvalQSuO25FUe+dTm3jFrtj/HvhFYw==; 20:3/qBAct4QZecBqIgOMPMwunZhYw/vb6dfGI1YHdPNfoMRzvlAJ+d/SPBe3iLYmy+vliWndKtaCCIeSjnef8lWyWQNE9JIjHDLrzMg+XXF5OPDlI8vatwPtCdH6c87lF+lPA5wH2xYe3czxRDB/US1vRyIXPkE8ElGvtNysJwRwq0y9K1qhCEDeUd4mdDlRNL2aPpngRsRoKAh4ZgTH5vBRdSYZ/aADgQ4SkgTSuTr0lQWA5Qq417+/ke+UQWauFkd5X+xLHNr6jlz3sDruI4SfLbqQ9hRGDmF2uootE59TjUUaxTbWKO8SbTpDB0kRNqMGpg0JU0E8N7HZ+G8TpgwiVEYZcgr4SLaMzAjYjPzJLIIEtkbZ53QCWM7Qv3aCavlax1I86FkQIg+JppB+qmC5SM00UJJUneUHUtpCY2PJI4WOtIfeK9SMTkh+jNefiKrCGXm3Je+2AKEU2KvA/ofo8syW7spZF908bbLyXqTffwcSQyVr+sAViQjR3ldvDS
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(100405760836317);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6060326)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6061324)(6072148); SRVR:CY1PR05MB2506; BCL:0; PCL:0; RULEID:; SRVR:CY1PR05MB2506; 
X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2506; 4:LDysbNmYSCzcEo7mc2P8V9cjY36thz1HYvR4V3J0fi6zm37nBuF9CZ3gr1/+50F6VEzGt1CcWn8twKd0u6LOR2AtTPJBkT1lLFhDMX2JGbGJ3bZpkfIGiiwrDP9gO3Ev8BnvA7nBZAUiuzegikO2umEXPpQtewT3s2BKTMhF5eBuxmwBC2jVY+D2iHpfu1Kk2b3Be0cIi7j+QbnJfqYhlIiqnSoKUiKlE6oxsuMjv6qIkYQAVEw/pG6PXIGcGytoxhUVeyjNIvKOZ24yIKxhcaUTNvsRUlK3sfVK63ugHMieOpBWEs+vuZw73AuHRZZyHfDzzE/VYZHrtlqmn9XsL5cjtnLNH2JmlQz3bGoECbp/KoKDH5vEW8bofHNYYgkI26XkyTXXu68wrJ8dpBl+UcvwRpYVHl8JtfmVFtQyFzATETnPTz6HLifb0CxDA3ffjzCbDR3n5MeSxkYtFA/xMt3Wk0URurkOBHsLjIWzw+8m7aXTh+VyhWhxhf5cHYSO
X-Forefront-PRVS: 01283822F8
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(7916002)(53754006)(199003)(189002)(47776003)(23726003)(97736004)(50226002)(6116002)(81156014)(3846002)(106356001)(46406003)(7846002)(101416001)(42186005)(50986999)(105586002)(76176999)(81166006)(50466002)(8746002)(36756003)(33656002)(57306001)(66066001)(305945005)(6916009)(6666003)(7736002)(2950100002)(230783001)(229853002)(110136003)(5660300001)(93886004)(92566002)(8676002)(189998001)(2906002)(107886002)(77096005)(68736007)(450100001)(97756001)(82746002)(86362001)(83716003)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2506; H:[172.29.192.68]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR05MB2506; 23:DX1s0nvhdypymq8Zp3jXvpT78ylVnKLtl9i+6pFE7?= =?us-ascii?Q?NBjPpjFdC1WLWk83fseSycbc/JodJTBSz7M2WQHR5o8ICpAejMbBLQK4NSOX?= =?us-ascii?Q?/3awxLJPGVqCuePYon4T/7kgQIF0k706bvL/2ljMQLJMmZCQ5GeubU2+Nhyt?= =?us-ascii?Q?ESchbaniol81Y6tNJjDlKCRTcjfcTLNCA5whJruJxFhxet/HeQC4xQ5twig5?= =?us-ascii?Q?sZ05x1zm9t209lDMEI/xKXxaE6Y7PJwWe6uojTv9884IB/ACtHh7bur+lGzm?= =?us-ascii?Q?M4VeU0KwwlWL7YN50HJr6DBDr7qFyJ46QiHpeiJfYN0Hbb4eCmNF+TWBmHtP?= =?us-ascii?Q?a6h+eeQNfYrk8r7IVx+aYkZ1DZN6kzKfgiwXY8U/XCM85UyX+Ct0d2XdP8Oj?= =?us-ascii?Q?nNkP2E1LYY27REOPZjzt/zDFkehP8MtIpzPyv96Rhp9HVG8xajI9aAWQZ4p5?= =?us-ascii?Q?5/cVY3Oc5Jj2PTfFEAlKA1YkfCSus9WgTKgN1N8VDjeZIBdjXIWaYBYpaYwx?= =?us-ascii?Q?tMgC7vfHYs15+PJGSupL+sfP8dXMjCdYYWk9Fa0hfDiPqc5/4QZPLY6+51Wg?= =?us-ascii?Q?HbeRBGHgkKie5wMxcjiZdqlGKWp0b5GVdvZEulmnQrGeFJ/PWPycYjsNBBFm?= =?us-ascii?Q?yVFtaniQjsqDN54U78/JFt9ahu5D0do4aCnChOl/qv9T6t4xF7+FCN3WYPin?= =?us-ascii?Q?FDnKp+rBwphSaqsxMIT9nOBK1dPtMKJg7Xa114iKPgkCZB5zvEnH1+ZafRw/?= =?us-ascii?Q?UGshe0emyCLRuB+tQc9wH0j5PoHzB5XUiaTS9+Pll4q8QCW5PmoV8RbykTDb?= =?us-ascii?Q?4DMMTvH8wkRE9ImiP7KygTAbzfCymgJ+CyZNhzw2BUh+uuiKQKS5L+ag7V4B?= =?us-ascii?Q?WfOlLZrzQnj+A+IjjxzvGJMqgUeTr5szkVe14UBo34B99itvwC6J3b8IyHYf?= =?us-ascii?Q?BFDSHF6vknQ95/yG+HfeGR4zwk2pgKPBlsHc3fBHcMywbCCR/KgSlK7wI53y?= =?us-ascii?Q?3XM79dLxWElxDIEDKcSKnShy4fP3wV6s4HvdvXPueeyCreRi4Hl5pEiRm3TD?= =?us-ascii?Q?D58v88MToYAjFsGSmuk0i6dyXVr2bGbGPlWFawjKoashau84KdKO+cn2+AVs?= =?us-ascii?Q?Utcu1WpGGIIeJL+r/BUvXiuAcrTmmHBmmJum0af5s6cB3X6AP/OZ86AfGBIb?= =?us-ascii?Q?8lfDhnQIiPmhoM4X7AdACoM/7/4qjwKQKIi/phr/TmgtOxeJl+RrRty7ZzIg?= =?us-ascii?Q?5JUyqjG3/EB2fz/IWw=3D?=
X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2506; 6:X2pYkBwairGrNZTaVSCe+W20qVT+ZtIPVPwde7P/60HVC1KxcOLzNecmcaB+Akz8Jxm/llsR5UU3HtszyktXBa7IYfzPxHayXYPx4YpWA37slTAmu8i3Bkivv868O4qZh4lvC+9EiTDOVyzq2SMGsAIKZz6DDRms6Zo4TWHIDf1cjDOGnCd01l5GuA6zrmE0e2BIRy43nP/hyxnJ+E6dlJUSU+JLs9i60NgQq3KK9dlvYfHnasRUklOlGmYF4g5xKoqCfjPULx3tFxEiiauh9ugREI7FS1tuzRAkuo8N2k+n/NdMY1NNKl+/uk0AdZpDYZHc60pcXE6xeSE0cuRGV5pE9prnx9tLWVanoA58lTFg20/xjkWlS3N87WcjLH/C; 5:Jsb6epmFcJNWufIKk0D9CMxlU1tFee+JHu5dhEHNhzws/xgHrLtwOS++BkUO6fRD257UVEhOaGBxtlMUuWbIqxho6xBGellbE7HMHLVXExou+gJvfuNvqhinv8/tw1z/5izxcXSL+0kRo/PW15zPow==; 24:ZHGqGlApV/wsPDwJwI3l7Pg+r9uzbGdmRUBDL45ITZiU7zPCq3nfoTjyz7mQBym5GNv+5wXC3T4kjlfHgrzAUW6q05OUK8GnozmyWnOYuaQ=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2506; 7:01HUZRljeNnq1LT/ZC30R/+qLk9EcsFnGgz72F+c/+fQZnn54VXuqrj0Wdk9kPkhkaN7NDGFg+kNGopNlmVZz+ETAg8UQ3cx1I3PiXuBJxh/ONOAM3UZL3lWAGzB1Pw7qrxgPM7lK1qZ1ZtQRcgdQWoSQApa6ucbhUJ6aqM5vzYV7VvD0J7ES3Hxi/vujbYNFtWuslMyCZbNiq7UzE0xCZYfnfKLWn0mv9l0nMKa33ctwi4qIwSLjGGNFDP7nDNAm9blkuZGYVHIpRTH8SrDFBbwlFMP6RF4jpr0KlescKglLpkHki2Dh2YGM2rIS3Yxg/kAiwwMm4j4vR1gE9wMx62eqHnzTOIxC28pjnAF9EA=
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Nov 2016 04:01:19.6143 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2506
Archived-At: 
Subject: Re: [Idr] One week extension to WGLC for draft-ietf-idr-large-community
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, 16 Nov 2016 04:01:24 -0000

Hi Everyone,

After Bruno's comments regarding RFC 7606 style error handling being =
invoked to react to duplicate community values, a few people have =
expressed (on and off list) concern that even though that is not =
intended, the -08 text as written could possibly be misinterpreted by a =
zealous implementor. To resolve this, I propose adding the following, or =
similar, to the Error Handling section:

o A BGP Large Communities attribute SHALL NOT be considered malformed =
due=20
  solely to presence of duplicate community values. Such duplicates MUST =
be handled=20
  by removing them as specified in Section 2.

IMO this clarifies the intent of the document and doesn't represent a =
normative change. Hopefully it will resolve the concerns of those who =
were concerned about and opposed to 7606-style handling for duplicates.

The authors have indicated they'll incorporate the text in an -09 =
(assuming of course that the consensus of the WGLC doesn't go against =
the change).

Regards,

--John=


From nobody Tue Nov 15 20:17:02 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7BA71294F7 for ; Tue, 15 Nov 2016 20:16:58 -0800 (PST)
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 RnaQuwZQHBdH for ; Tue, 15 Nov 2016 20:16:57 -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 4311312948C for ; Tue, 15 Nov 2016 20:16:57 -0800 (PST)
X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=31.133.133.143; 
From: "Susan Hares" 
To: "'John G. Scudder'" , "'idr wg'" 
References:   <27701_1479159582_582A2F1E_27701_6903_1_53C29892C857584299CBF5D05346208A1EC77FE1@OPEXCLILM21.corporate.adroot.infra.ftgroup> <736EA2CC-3DD1-4F14-96ED-2916E62F6F02@cisco.com> <26709_1479217575_582B11A7_26709_12999_1_53C29892C857584299CBF5D05346208A1EC79584@OPEXCLILM21.corporate.adroot.infra.ftgroup>   <20161116001246.GB27230@pfrc.org> <4EB6222D-86A4-4A83-AF8C-364CB52B8422@juniper.net>
In-Reply-To: <4EB6222D-86A4-4A83-AF8C-364CB52B8422@juniper.net>
Date: Tue, 15 Nov 2016 23:14:26 -0500
Message-ID: <235d01d23fbf$ec68f2d0$c53ad870$@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: AQFJUP4HVIpB2UMZiJF07EtPoYzpHAGix6xGAugKeycB9SiVYgJBUUWmAbNiDaAA05SgpQHNWREJAs4rf8Ohbb+L4A==
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com 
Archived-At: 
Subject: Re: [Idr] One week extension to WGLC for draft-ietf-idr-large-community
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, 16 Nov 2016 04:16:59 -0000

John: 

+1 on the new text. 

Sue 

-----Original Message-----
From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of John G. Scudder
Sent: Tuesday, November 15, 2016 11:01 PM
To: idr wg
Subject: Re: [Idr] One week extension to WGLC for
draft-ietf-idr-large-community

Hi Everyone,

After Bruno's comments regarding RFC 7606 style error handling being invoked
to react to duplicate community values, a few people have expressed (on and
off list) concern that even though that is not intended, the -08 text as
written could possibly be misinterpreted by a zealous implementor. To
resolve this, I propose adding the following, or similar, to the Error
Handling section:

o A BGP Large Communities attribute SHALL NOT be considered malformed due 
  solely to presence of duplicate community values. Such duplicates MUST be
handled 
  by removing them as specified in Section 2.

IMO this clarifies the intent of the document and doesn't represent a
normative change. Hopefully it will resolve the concerns of those who were
concerned about and opposed to 7606-style handling for duplicates.

The authors have indicated they'll incorporate the text in an -09 (assuming
of course that the consensus of the WGLC doesn't go against the change).

Regards,

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


From nobody Tue Nov 15 20:41:00 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12274129641 for ; Tue, 15 Nov 2016 20:41:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.398
X-Spam-Level: 
X-Spam-Status: No, score=-108.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 jxfazVaWTo0O for ; Tue, 15 Nov 2016 20:40:58 -0800 (PST)
Received: from ao-mailgw.apnic.net (ao-mailgw.apnic.net [IPv6:2001:dd8:8:701::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFFF412962D for ; Tue, 15 Nov 2016 20:40:57 -0800 (PST)
Received: from iamda3.org.apnic.net (unknown [2001:dd8:9:2::101:249]) by ao-mailgw.apnic.net (Halon) with ESMTPS id d6948901-abb6-11e6-b8ce-005056b6ee6f; Wed, 16 Nov 2016 14:40:45 +1000 (AEST)
Received: from dhcp-868f.meeting.ietf.org (203.119.101.249) by iamda3.org.apnic.net (203.119.111.31) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 16 Nov 2016 14:40:53 +1000
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
From: Geoff Huston 
In-Reply-To: <4EB6222D-86A4-4A83-AF8C-364CB52B8422@juniper.net>
Date: Wed, 16 Nov 2016 15:40:48 +1100
Content-Transfer-Encoding: quoted-printable
Message-ID: <09178499-6D25-4059-BC7B-A96CA0DAECC6@apnic.net>
References:   <27701_1479159582_582A2F1E_27701_6903_1_53C29892C857584299CBF5D05346208A1EC77FE1@OPEXCLILM21.corporate.adroot.infra.ftgroup> <736EA2CC-3DD1-4F14-96ED-2916E62F6F02@cisco.com> <26709_1479217575_582B11A7_26709_12999_1_53C29892C857584299CBF5D05346208A1EC79584@OPEXCLILM21.corporate.adroot.infra.ftgroup>   <20161116001246.GB27230@pfrc.org> <4EB6222D-86A4-4A83-AF8C-364CB52B8422@juniper.net>
To: "John G. Scudder" 
X-Mailer: Apple Mail (2.3251)
Archived-At: 
Cc: idr wg 
Subject: Re: [Idr] One week extension to WGLC for draft-ietf-idr-large-community
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, 16 Nov 2016 04:41:00 -0000

> On 16 Nov. 2016, at 3:01 pm, John G. Scudder  wrote:
>=20
> Hi Everyone,
>=20
> After Bruno's comments regarding RFC 7606 style error handling being =
invoked to react to duplicate community values, a few people have =
expressed (on and off list) concern that even though that is not =
intended, the -08 text as written could possibly be misinterpreted by a =
zealous implementor. To resolve this, I propose adding the following, or =
similar, to the Error Handling section:
>=20
> o A BGP Large Communities attribute SHALL NOT be considered malformed =
due=20
>  solely to presence of duplicate community values. Such duplicates =
MUST be handled=20
>  by removing them as specified in Section 2.
>=20
> IMO this clarifies the intent of the document and doesn't represent a =
normative change. Hopefully it will resolve the concerns of those who =
were concerned about and opposed to 7606-style handling for duplicates.
>=20
> The authors have indicated they'll incorporate the text in an -09 =
(assuming of course that the consensus of the WGLC doesn't go against =
the change).
>=20

As someone who has commented on previous wordings of this intent, I=E2=80=99=
d like to say that I am very happy with this wording.

Geoff



From nobody Tue Nov 15 21:10:06 2016
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 54799129472 for ; Tue, 15 Nov 2016 21:10:05 -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 PMKbICF6LwKZ for ; Tue, 15 Nov 2016 21:10:04 -0800 (PST)
Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17491129481 for ; Tue, 15 Nov 2016 21:10:03 -0800 (PST)
Received: by mail-pf0-x234.google.com with SMTP id c4so28615055pfb.1 for ; Tue, 15 Nov 2016 21:10:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=M9jE3RRwJ5mB2xK1bm0KvNBn9Xc/N+QyL+h5VRl0Ke0=; b=os8F+scNCRg6nJwiRcFB0+oxWfORBux6jQnkSWXY1jMc6hd2pJRcRRu2AkqZcdEhcA peQ3rKMu/kP4I0ZLa8t2D4V6bQ72HHJB1ZuEW9M6msj6UR103E7dtixcOlHpNGzbqA4A J4gCFIIVLzA0oPO4z3Ml0oYHnGgTFRZzV3hFyBLo641CfuiyLI0/yi+zTE9mJSz68W7P oO4IGRnkALWaSpj5x6A4LgUnYTbeNMLK8yxeLOZgxAfctVsLd/37zZpod5AqkK9RuPd8 0eP5zYCvKhqXGgd2VGhu5zcjRYBb6oMC+liS62VkpGK61079LzjrFQaK7YPQlAEP1BEo eBdw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; 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=M9jE3RRwJ5mB2xK1bm0KvNBn9Xc/N+QyL+h5VRl0Ke0=; b=D5NGSXq6TTDxtw4Z9IDpGTysUvwpUXmodJL7WK/T6hCQ+sKeduoHSYWyUeoLptej7M 1LpXsEkGqeaI9tYB2PbxrUvZSDeqnjgc6JkhLBVZ7KI0lNajIiuCgJUdDw8tpvPy0Wa9 g9m/4+1k2P9naRcebWdNNQ4omGyrobQWM1TYLjTYpRov84AR+nZGmfIqMb2fqteiTakS 4/ZWuZJxTX4hQ9PAjLunBZohUwX2xzr2ngeuohyfVz+AoeTKN4PU1XnJS+vDdMtYHHOi MWpZewv9fMXwtSwUrhCvsmJ8PARkpUrW3ZnTALWqglBI0+cyiXgxXX4esVPvrPqH64Dc boMg==
X-Gm-Message-State: ABUngvcGmWvGYImyY6LRv8vhp7punbZQtw54w+I2yix92hXJc5LBlgQaUybWB0iN71I8bw==
X-Received: by 10.99.146.7 with SMTP id o7mr4136049pgd.6.1479273003307; Tue, 15 Nov 2016 21:10:03 -0800 (PST)
Received: from Russ ([2001:67c:370:144:f8a9:311c:e907:4da8]) by smtp.gmail.com with ESMTPSA id t67sm48320174pfg.13.2016.11.15.21.10.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Nov 2016 21:10:02 -0800 (PST)
From: "Russ White" <7riw77@gmail.com>
To: "'Geoff Huston'" , "'John G. Scudder'" 
References:   <27701_1479159582_582A2F1E_27701_6903_1_53C29892C857584299CBF5D05346208A1EC77FE1@OPEXCLILM21.corporate.adroot.infra.ftgroup> <736EA2CC-3DD1-4F14-96ED-2916E62F6F02@cisco.com> <26709_1479217575_582B11A7_26709_12999_1_53C29892C857584299CBF5D05346208A1EC79584@OPEXCLILM21.corporate.adroot.infra.ftgroup>   <20161116001246.GB27230@pfrc.org> <4EB6222D-86A4-4A83-AF8C-364CB52B8422@juniper.net> <09178499-6D25-4059-BC7B-A96CA0DAECC6@apnic.net>
In-Reply-To: <09178499-6D25-4059-BC7B-A96CA0DAECC6@apnic.net>
Date: Wed, 16 Nov 2016 00:09:53 -0500
Message-ID: <001901d23fc7$addab8c0$09902a40$@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: AQFJUP4HVIpB2UMZiJF07EtPoYzpHAGix6xGAugKeycB9SiVYgJBUUWmAbNiDaAA05SgpQHNWREJAs4rf8MCY5ti06Fash/Q
Content-Language: en-us
Archived-At: 
Cc: 'idr wg' 
Subject: Re: [Idr] One week extension to WGLC for draft-ietf-idr-large-community
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, 16 Nov 2016 05:10:05 -0000

> > o A BGP Large Communities attribute SHALL NOT be considered =
malformed
> > due  solely to presence of duplicate community values. Such =
duplicates
> > MUST be handled  by removing them as specified in Section 2.

This is a useful addition... And it seems to resolve the problem at hand =
well.

:-)

Russ



From nobody Tue Nov 15 22:16:25 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5E321296A7; Tue, 15 Nov 2016 22:16:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.432
X-Spam-Level: 
X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_SOFTFAIL=0.665] 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 wAS1jifccLdn; Tue, 15 Nov 2016 22:16:03 -0800 (PST)
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 0622712966C; Tue, 15 Nov 2016 22:16:03 -0800 (PST)
Received: by mail3.mlpsca01.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1c6tVo-000EUl-Tq (job@us.ntt.net); Wed, 16 Nov 2016 06:16:02 +0000
Date: Wed, 16 Nov 2016 15:15:56 +0900
From: Job Snijders 
To: grow@ietf.org, idr@ietf.org
Message-ID: <20161116061556.GG1073@dhcp-9341.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: Mutt/1.7.1 (2016-10-04)
Archived-At: 
Subject: [Idr] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 16 Nov 2016 06:16:19 -0000

Hi GROW,

>From an operational perspective it is really useful if you can drop a
line in the peer's syslog which covers why you shutdown a BGP session.
A common use case is to provide a reference between the shutdown event
and an emailed maintenance notification, or maybe you want to make an
emotional statement.

Fictional IOS example:

	o00.frnkge02.de.bb#conf t
	Enter configuration commands, one per line.  End with CNTL/Z.
	o00.frnkge02.de.bb(config)#router bgp 65001
	o00.frnkge02.de.bb(config-router)#neighbor 129.250.6.5 shutdown "Maintenance [V-NOC-248244242] software upgrade o00.frnkge02.de.bb"

Fictional OpenBGPD example:

	[job@kiera ~]$ bgpctl neighbor down AS15562_scarlett_IPv6 "I hate you, depeered"
	request processed
	[job@kiera ~]$

In the above examples, the other side might find something like this in
their logs:

	Nov 16 00:20:41 frankfurt-router 589711: RP/0/RSP0/CPU0:Nov 16 00:20:41.653 : bgp[1059]: %ROUTING-BGP-5-ADJCHANGE : neighbor X.Y.Z.A Down - Peer closing down the session (VRF: default) (AS: 35994) (Shutdown Communication: "Maintenance [V-NOC-248244242] software upgrade o00.frnkge02.de.bb")

or perhaps:

	Nov 16 06:59:50 herpaderp bgpd[99938]: neighbor 165.254.255.1 (AS15562_scarlett_IPv4): received notification: Cease, shutdown communication: "I hate you, depeered"

Some might wonder, why "Cease"?

The beauty of using a new Cease subcode, is that the NOTIFICATION
message type already allows extra data to be attached, so for most
implementations it will be very simple to bolt what is specified in
draft-snijders-idr-shutdown-00 on top of their existing code. In some
cases we are looking at just a handful of lines.

Out of all the moments in the lifecycle of BGP interactions, I believe
that the 'shutdown' moment is the most critical one to decorate with
some freeform text. This is low hanging fruit and as should be treated
accordingly. There other moments where one might want to chat with the
neighbor, but those are out of scope for this document, you can always
call or email them!

Previous attempts such as draft-ietf-idr-advisory-00 and
draft-ietf-idr-operational-message-00 failed to deliver for various
reasons (feature creep comes to mind), therefore we are trying to do
this as simple as possible. 

Kind regards,

Job


----- Forwarded message from internet-drafts@ietf.org -----

Date: Tue, 15 Nov 2016 21:30:15 -0800
From: internet-drafts@ietf.org
To: Jakob Heitz , Job Snijders , John Scudder 
Subject: New Version Notification for draft-snijders-idr-shutdown-00.txt

A new version of I-D, draft-snijders-idr-shutdown-00.txt
has been successfully submitted by Job Snijders and posted to the
IETF repository.

Name:		draft-snijders-idr-shutdown
Revision:	00
Title:		The Shutdown Communication BGP Cease Notification Message subcode 
Document date:	2016-11-15
Group:		Individual Submission
Pages:		6
URL:            https://www.ietf.org/internet-drafts/draft-snijders-idr-shutdown-00.txt
Status:         https://datatracker.ietf.org/doc/draft-snijders-idr-shutdown/
Htmlized:       https://tools.ietf.org/html/draft-snijders-idr-shutdown-00


Abstract:
   This document defines the BGP Cease NOTIFICATION message "Shutdown
   Communication" subcode for operators to transmit a short freeform
   message to describe why a BGP session was shutdown.

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

----- End forwarded message -----


From nobody Wed Nov 16 00:16:26 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17594129693 for ; Wed, 16 Nov 2016 00:16:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.699
X-Spam-Level: 
X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, 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 RA0FhQUG7q5J for ; Wed, 16 Nov 2016 00:16:23 -0800 (PST)
Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2FCD12968A for ; Wed, 16 Nov 2016 00:16:23 -0800 (PST)
Received: by guelah.shrubbery.net (Postfix, from userid 7053) id 94FAC5E2E7; Wed, 16 Nov 2016 08:16:23 +0000 (UTC)
Date: Wed, 16 Nov 2016 08:16:23 +0000
From: heasley 
To: "John G. Scudder" 
Message-ID: <20161116081623.GA17479@shrubbery.net>
References:   <27701_1479159582_582A2F1E_27701_6903_1_53C29892C857584299CBF5D05346208A1EC77FE1@OPEXCLILM21.corporate.adroot.infra.ftgroup> <736EA2CC-3DD1-4F14-96ED-2916E62F6F02@cisco.com> <26709_1479217575_582B11A7_26709_12999_1_53C29892C857584299CBF5D05346208A1EC79584@OPEXCLILM21.corporate.adroot.infra.ftgroup>   <20161116001246.GB27230@pfrc.org> <4EB6222D-86A4-4A83-AF8C-364CB52B8422@juniper.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4EB6222D-86A4-4A83-AF8C-364CB52B8422@juniper.net>
X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc
X-note: live free, or die!
X-homer: i just want to have a beer while i am caring.
X-Claimation: an engineer needs a manager like a fish needs a bicycle
X-reality: only YOU can put an end to the embarrassment that is Tom Cruise
User-Agent: Mutt/1.6.1 (2016-04-27)
Archived-At: 
Cc: idr wg 
Subject: Re: [Idr] One week extension to WGLC for draft-ietf-idr-large-community
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, 16 Nov 2016 08:16:25 -0000

Wed, Nov 16, 2016 at 01:01:03PM +0900, John G. Scudder:
> Hi Everyone,
> 
> After Bruno's comments regarding RFC 7606 style error handling being invoked to react to duplicate community values, a few people have expressed (on and off list) concern that even though that is not intended, the -08 text as written could possibly be misinterpreted by a zealous implementor. To resolve this, I propose adding the following, or similar, to the Error Handling section:
> 
> o A BGP Large Communities attribute SHALL NOT be considered malformed due 
>   solely to presence of duplicate community values. Such duplicates MUST be handled 
>   by removing them as specified in Section 2.
> 
> IMO this clarifies the intent of the document and doesn't represent a normative change. Hopefully it will resolve the concerns of those who were concerned about and opposed to 7606-style handling for duplicates.

I do not understand why this is necessary.  -08 already indicates that
duplicates should be silently ignored.  And, nothing in section 6 implies
that it would be considered an error.

I dont object, but i do think this is redundant and unnecessary.

> The authors have indicated they'll incorporate the text in an -09 (assuming of course that the consensus of the WGLC doesn't go against the change).
> 
> Regards,
> 
> --John
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr


From nobody Wed Nov 16 00:26:35 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6D0A12969D; Wed, 16 Nov 2016 00:26:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.699
X-Spam-Level: 
X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, 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 Msn3w449qpFw; Wed, 16 Nov 2016 00:26:27 -0800 (PST)
Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by ietfa.amsl.com (Postfix) with ESMTP id 5F6361296A1; Wed, 16 Nov 2016 00:26:25 -0800 (PST)
Received: by puck.nether.net (Postfix, from userid 507) id 1951F5409F8; Wed, 16 Nov 2016 03:26:25 -0500 (EST)
Date: Wed, 16 Nov 2016 03:26:24 -0500
From: Jon Mitchell 
To: Job Snijders 
Message-ID: <20161116082624.GB10860@puck.nether.net>
References: <20161116061556.GG1073@dhcp-9341.meeting.ietf.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20161116061556.GG1073@dhcp-9341.meeting.ietf.org>
User-Agent: Mutt/1.7.1 (2016-10-04)
Archived-At: 
Cc: idr@ietf.org, grow@ietf.org
Subject: Re: [Idr] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 16 Nov 2016 08:26:29 -0000

On 16/11/16 15:15 +0900, Job Snijders wrote:
> Hi GROW,
> 
> >From an operational perspective it is really useful if you can drop a

I agree with this statement, this looks very useful for communicating
ticket information related to maintenance, the document also appears
well written and fairly complete already.

-Jon


From nobody Wed Nov 16 01:31:56 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C37DE1296B0 for ; Wed, 16 Nov 2016 01:31:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.398
X-Spam-Level: 
X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, SPF_HELO_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 P6x7uJ9Co-8j for ; Wed, 16 Nov 2016 01:31:54 -0800 (PST)
Received: from gir.theapt.org (gir.theapt.org [IPv6:2001:470:1f0b:8b2::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DC471296BA for ; Wed, 16 Nov 2016 01:31:53 -0800 (PST)
Received: from gir.theapt.org (unknown [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/0 bits)) (Client did not present a certificate) (Authenticated sender: phessler) by gir.theapt.org (Postfix) with ESMTPSA id C2AEE788FC for ; Wed, 16 Nov 2016 10:31:51 +0100 (CET)
Date: Wed, 16 Nov 2016 10:31:50 +0100
From: Peter Hessler 
To: idr@ietf.org
Message-ID: <20161116093150.GN24817@gir.theapt.org>
References:   <27701_1479159582_582A2F1E_27701_6903_1_53C29892C857584299CBF5D05346208A1EC77FE1@OPEXCLILM21.corporate.adroot.infra.ftgroup> <736EA2CC-3DD1-4F14-96ED-2916E62F6F02@cisco.com> <26709_1479217575_582B11A7_26709_12999_1_53C29892C857584299CBF5D05346208A1EC79584@OPEXCLILM21.corporate.adroot.infra.ftgroup>   <20161116001246.GB27230@pfrc.org> <4EB6222D-86A4-4A83-AF8C-364CB52B8422@juniper.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4EB6222D-86A4-4A83-AF8C-364CB52B8422@juniper.net>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: 
Subject: Re: [Idr] One week extension to WGLC for draft-ietf-idr-large-community
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, 16 Nov 2016 09:31:56 -0000

On 2016 Nov 16 (Wed) at 13:01:03 +0900 (+0900), John G. Scudder wrote:
:Hi Everyone,
:
:After Bruno's comments regarding RFC 7606 style error handling being invoked to react to duplicate community values, a few people have expressed (on and off list) concern that even though that is not intended, the -08 text as written could possibly be misinterpreted by a zealous implementor. To resolve this, I propose adding the following, or similar, to the Error Handling section:
:
:o A BGP Large Communities attribute SHALL NOT be considered malformed due 
:  solely to presence of duplicate community values. Such duplicates MUST be handled 
:  by removing them as specified in Section 2.
:

+100

This exactly addresses my original objection.


:IMO this clarifies the intent of the document and doesn't represent a normative change. Hopefully it will resolve the concerns of those who were concerned about and opposed to 7606-style handling for duplicates.
:
:The authors have indicated they'll incorporate the text in an -09 (assuming of course that the consensus of the WGLC doesn't go against the change).
:
:Regards,
:
:--John

-- 
Do not believe in miracles -- rely on them.


From nobody Wed Nov 16 01:41:35 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D772F1296A5 for ; Wed, 16 Nov 2016 01:41:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.097
X-Spam-Level: 
X-Spam-Status: No, score=-4.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497] 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 Pg4LYoBmH1CZ for ; Wed, 16 Nov 2016 01:41:32 -0800 (PST)
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 DC67412969A for ; Wed, 16 Nov 2016 01:41:31 -0800 (PST)
X-Original-To: idr@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 46D986034B for ; Wed, 16 Nov 2016 10:41:29 +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 D26F8602E3; Wed, 16 Nov 2016 10:41:27 +0100 (CET)
Received: by moebius4.space.net (Postfix, from userid 1007) id CF5539679; Wed, 16 Nov 2016 10:41:27 +0100 (CET)
Date: Wed, 16 Nov 2016 10:41:27 +0100
From: Gert Doering 
To: heasley 
Message-ID: <20161116094127.GV79185@Space.Net>
References:  <27701_1479159582_582A2F1E_27701_6903_1_53C29892C857584299CBF5D05346208A1EC77FE1@OPEXCLILM21.corporate.adroot.infra.ftgroup> <736EA2CC-3DD1-4F14-96ED-2916E62F6F02@cisco.com> <26709_1479217575_582B11A7_26709_12999_1_53C29892C857584299CBF5D05346208A1EC79584@OPEXCLILM21.corporate.adroot.infra.ftgroup>    <20161115182648.GD94469@shrubbery.net>  <20161115222738.GW94469@shrubbery.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20161115222738.GW94469@shrubbery.net>
X-NCC-RegID: de.space
User-Agent: Mutt/1.6.1 (2016-04-27)
Archived-At: 
Cc: idr wg , Robert Raszuk 
Subject: Re: [Idr] One week extension to WGLC for draft-ietf-idr-large-community
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, 16 Nov 2016 09:41:34 -0000

Hi,

On Tue, Nov 15, 2016 at 10:27:38PM +0000, heasley wrote:
> i think this discussion is becoming silly.  can god make a boulder so big that
> he himself can not lift it.

+1

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 Nov 16 02:55:41 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 199FC129688 for ; Wed, 16 Nov 2016 02:55:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.097
X-Spam-Level: 
X-Spam-Status: No, score=-4.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497] 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 qCTiQmjDT1fK for ; Wed, 16 Nov 2016 02:55:38 -0800 (PST)
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 49D581288B8 for ; Wed, 16 Nov 2016 02:55:38 -0800 (PST)
X-Original-To: idr@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id E7CA1603BD for ; Wed, 16 Nov 2016 11:55:35 +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 B3EA660367; Wed, 16 Nov 2016 11:55:35 +0100 (CET)
Received: by moebius4.space.net (Postfix, from userid 1007) id A502B9B0C; Wed, 16 Nov 2016 11:55:35 +0100 (CET)
Date: Wed, 16 Nov 2016 11:55:35 +0100
From: Gert Doering 
To: Job Snijders 
Message-ID: <20161116105535.GW79185@Space.Net>
References: <20161116061556.GG1073@dhcp-9341.meeting.ietf.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20161116061556.GG1073@dhcp-9341.meeting.ietf.org>
X-NCC-RegID: de.space
User-Agent: Mutt/1.6.1 (2016-04-27)
Archived-At: 
Cc: idr@ietf.org, grow@ietf.org
Subject: Re: [Idr] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 16 Nov 2016 10:55:40 -0000

Hi,

On Wed, Nov 16, 2016 at 03:15:56PM +0900, Job Snijders wrote:
> Out of all the moments in the lifecycle of BGP interactions, I believe
> that the 'shutdown' moment is the most critical one to decorate with
> some freeform text. This is low hanging fruit and as should be treated
> accordingly. There other moments where one might want to chat with the
> neighbor, but those are out of scope for this document, you can always
> call or email them!

Sounds tremendously useful.

There's rat-holing risks here (like, charset), though.

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 Nov 16 03:29:38 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3D26129785; Wed, 16 Nov 2016 03:29:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.399
X-Spam-Level: 
X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, 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 L_eChhsX6act; Wed, 16 Nov 2016 03:29:31 -0800 (PST)
Received: from relay.dacor.de (relay.dacor.de [217.24.56.24]) by ietfa.amsl.com (Postfix) with ESMTP id 2F09B12944D; Wed, 16 Nov 2016 03:29:31 -0800 (PST)
Received: from exchange.dacor.de (astaro1.dacor.de [217.24.48.66]) by relay.dacor.de (Postfix) with ESMTPS id B2E85E301B; Wed, 16 Nov 2016 12:29:29 +0100 (CET)
Received: from ex02.suecdacor.local (192.168.1.16) by ex02.suecdacor.local (192.168.1.16) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 16 Nov 2016 12:29:28 +0100
Received: from ex02.suecdacor.local ([::1]) by ex02.suecdacor.local ([::1]) with mapi id 15.00.1210.000; Wed, 16 Nov 2016 12:29:28 +0100
From: Julian Seifert 
To: Gert Doering , Job Snijders 
Thread-Topic: [Idr] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
Thread-Index: AQHSP9EEvaj+T+0foEeSjmvODONxM6DbX4SAgAAXzjs=
Date: Wed, 16 Nov 2016 11:29:28 +0000
Message-ID: <1479295774707.77855@dacor.de>
References: <20161116061556.GG1073@dhcp-9341.meeting.ietf.org>, <20161116105535.GW79185@Space.Net>
In-Reply-To: <20161116105535.GW79185@Space.Net>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [88.133.178.43]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: "idr@ietf.org" , "grow@ietf.org" 
Subject: Re: [Idr] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 16 Nov 2016 11:29:33 -0000

Hi,=0A=
=0A=
I agree with both points. Maybe not use utf8/unicode or reduce to only alph=
anumerics?=0A=
=0A=
I really like the idea of this feature as we experienced that ourselves lat=
ely when enquiring about a shutdown=0A=
session because nobody entered the (announced) maintenance into our system.=
=0A=
=0A=
So full support,=0A=
=0A=
kind regards,=0A=
=0A=
  Julian=


From nobody Wed Nov 16 03:47:55 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2436A129692; Wed, 16 Nov 2016 03:47:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.879
X-Spam-Level: 
X-Spam-Status: No, score=-0.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001] 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 KG4X8HokPTkb; Wed, 16 Nov 2016 03:47:50 -0800 (PST)
Received: from attila.bofh.it (attila.bofh.it [IPv6:2001:4b78:2000::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10014129485; Wed, 16 Nov 2016 03:39:01 -0800 (PST)
Received: by attila.bofh.it (Postfix, from userid 10) id 4CD701266F0; Wed, 16 Nov 2016 12:38:58 +0100 (CET)
Received: by bongo.bofh.it (Postfix, from userid 1000) id CBAFF2C01FE; Wed, 16 Nov 2016 12:38:49 +0100 (CET)
Date: Wed, 16 Nov 2016 12:38:49 +0100
Message-ID: <20161116113849.udbrfvdhaj3be7nx@bongo.bofh.it>
References: <20161116061556.GG1073@dhcp-9341.meeting.ietf.org> <20161116105535.GW79185@Space.Net> <1479295774707.77855@dacor.de>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jfzoichjyvf2glhy"
Content-Disposition: inline
In-Reply-To: <1479295774707.77855@dacor.de>
User-Agent: NeoMutt/20161104 (1.7.1)
From: md@Linux.IT (Marco d'Itri)
Archived-At: 
Cc: "idr@ietf.org" , "grow@ietf.org" 
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 16 Nov 2016 11:47:51 -0000

--jfzoichjyvf2glhy
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Nov 16, Julian Seifert  wrote:

> I agree with both points. Maybe not use utf8/unicode or reduce to only al=
phanumerics?
Not supporting UTF-8 is not acceptable for a new IETF protocol and would=20
preclude using it in some cultures.

Customers with really crappy management infrastructure could ask their=20
vendors to implement a knob to report the strings as base64, but=20
I really wonder which real world use cases there are for this.

--=20
ciao,
Marco

--jfzoichjyvf2glhy
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQGzBAABCAAdFiEEGBsIcS5ipP0URKfyK/WlwSLE96QFAlgsRUkACgkQK/WlwSLE
96TyOQwAv+0kCeiowrcuE3qrRGTac5wgS3tbyY3pZYmFcnpLyPQDpegHr7UCRmgd
VFock06fDJxWwDs4SX5iR+XdRZz0nP8dadtc7GLK2kmH/lZvtKJCYQKY1mNH5T/t
I+b2g/XMnoFmDnup3V2sd2EB/tGSzttpLWpSeT+IUo51nzjHk1IpJlZ11KSMOtsb
7U+ynqt89mUshbjqY8S9JZpqZSosWwxT7vm1/14xNBRd2raC4X+iz01KB9m8N/s6
mYPUOZHY6P1ySs2RN8C7xnCZVI0Re3b/SRezbOYxCTUQjXUT134qmzMI2tNNW9XA
I6CWjdSbFda0AW9PBP5wzqbn3/qY+FIznbwqEVKerdPMhWCThxuTVSRIWTv6MU34
FVeNszUtVJICmZdPFwoPMCLeXUUAvGpw7Ef9lxAfdT4TwilOKD9pLmrwuv4/Ektw
C+r5z08JCn1xAt/dMBpXWMVC3Dks/PIB+F8/kEc78gpx1HcQrqKzfciQzd4CA3Vi
NfJR25ZE
=c8sl
-----END PGP SIGNATURE-----

--jfzoichjyvf2glhy--


From nobody Wed Nov 16 05:01:21 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36A641296DE; Wed, 16 Nov 2016 05:01:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.432
X-Spam-Level: 
X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_SOFTFAIL=0.665] 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 qpefbz0w7JUC; Wed, 16 Nov 2016 05:01:15 -0800 (PST)
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 812C6129598; Wed, 16 Nov 2016 05:01:15 -0800 (PST)
Received: by mail3.mlpsca01.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1c6zpy-00030A-42 (job@us.ntt.net); Wed, 16 Nov 2016 13:01:15 +0000
Date: Wed, 16 Nov 2016 22:01:10 +0900
From: Job Snijders 
To: Marco d'Itri 
Message-ID: <20161116130110.GK1073@dhcp-9341.meeting.ietf.org>
References: <20161116061556.GG1073@dhcp-9341.meeting.ietf.org> <20161116105535.GW79185@Space.Net> <1479295774707.77855@dacor.de> <20161116113849.udbrfvdhaj3be7nx@bongo.bofh.it>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20161116113849.udbrfvdhaj3be7nx@bongo.bofh.it>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.7.1 (2016-10-04)
Archived-At: 
Cc: "idr@ietf.org" , "grow@ietf.org" 
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 16 Nov 2016 13:01:17 -0000

On Wed, Nov 16, 2016 at 12:38:49PM +0100, Marco d'Itri wrote:
> On Nov 16, Julian Seifert  wrote:
> > I agree with both points. Maybe not use utf8/unicode or reduce to
> > only alphanumerics?
>
> Not supporting UTF-8 is not acceptable for a new IETF protocol and
> would preclude using it in some cultures.
> 
> Customers with really crappy management infrastructure could ask their
> vendors to implement a knob to report the strings as base64, but I
> really wonder which real world use cases there are for this.

Yes, I can't imagine folks using Cyrillic or Kanji for their daily
communication to be happy if the Shutdown Communication only allows use
of Latin characters.

Unless some implementors make significant arguments along the lines of
"we CANNOT implement this Shutdown Communication functionality, SOLELY
because of utf8 and lack of representation filtering capabilities", i'd
water down the utf8 requirement to 7bit ascii (because in the end its
better to have 'something' than nothing). Another line of argumentation
against utf8 would be if major security concerns are articulated.

I hope to capture in the draft that an implementation can choose which
characters of the Shutdown Communication they represent in the syslog or
'show bgp neighbor xxx' output. For instance, I'd recommend to squash
all newline/newpage/newfeed/newparagraph style chars and make sure that
the Communication is represented on a single line. I don't have the
proper words for the draft to express that (yet).

Also I don't mind if an implementation consciously chooses to only
represent 7bit ASCII. That should be an implementor decision. They can
upgrade later. In theory the protocol spec shouldn't be delayed or
obstructed due to an implementor's current internationalisation
capabilities (which can change over time).

Kind regards,

Job


From nobody Wed Nov 16 05:47:16 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3B5912957A; Wed, 16 Nov 2016 05:47:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.398
X-Spam-Level: 
X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, SPF_HELO_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 o6ZqIXtaZL2M; Wed, 16 Nov 2016 05:47:10 -0800 (PST)
Received: from gir.theapt.org (gir.theapt.org [IPv6:2001:470:1f0b:8b2::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DD9F129468; Wed, 16 Nov 2016 05:47:10 -0800 (PST)
Received: from gir.theapt.org (unknown [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/0 bits)) (Client did not present a certificate) (Authenticated sender: phessler) by gir.theapt.org (Postfix) with ESMTPSA id E302C788FC; Wed, 16 Nov 2016 14:47:08 +0100 (CET)
Date: Wed, 16 Nov 2016 14:47:07 +0100
From: Peter Hessler 
To: idr@ietf.org, grow@ietf.org
Message-ID: <20161116134707.GP24817@gir.theapt.org>
References: <20161116061556.GG1073@dhcp-9341.meeting.ietf.org> <20161116105535.GW79185@Space.Net> <1479295774707.77855@dacor.de> <20161116113849.udbrfvdhaj3be7nx@bongo.bofh.it> <20161116130110.GK1073@dhcp-9341.meeting.ietf.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20161116130110.GK1073@dhcp-9341.meeting.ietf.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: 
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 16 Nov 2016 13:47:12 -0000

On 2016 Nov 16 (Wed) at 22:01:10 +0900 (+0900), Job Snijders wrote:
:I hope to capture in the draft that an implementation can choose which
:characters of the Shutdown Communication they represent in the syslog or
:'show bgp neighbor xxx' output. For instance, I'd recommend to squash
:all newline/newpage/newfeed/newparagraph style chars and make sure that
:the Communication is represented on a single line. I don't have the
:proper words for the draft to express that (yet).

I've been thinking about wording for protecting the receiving system
from possible bad input.  I'm not worried about (valid) UTF-8 display
chars, nor about whitespace things.  I am worried about Little Bobby
Tables, though.

We also have to consider that this will be displayed possibly in a Unix
Shell, Windows Shell, Syslog, SQL server, Web Server; and different
chars have different meanings there.

I'm not quite happy with the wording, but I would like something along
these lines added.  Possibly in the Security section, or at the end of
Section #2.

====
Receiving systems SHOULD filter the message for the intended output
environment and MAY change octets or sequences of octets for their   
local environment.
As the message may be displayed on a command line, stored
in a syslog server, in an SQL database, or even a Web Server different
outputs MAY happen.
Sending systems MUST NOT depend on changes to their
sequences not happening.
====

(Consider, Little Bobby Tables https://www.xkcd.com/327/, printf
escapes, Javascript/HTML, etc) 


-- 
Taxes, n.:
	Of life's two certainties, the only one for which you can get
	an extension.


From nobody Wed Nov 16 06:54:43 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74B5C129639; Wed, 16 Nov 2016 06:54:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.2
X-Spam-Level: 
X-Spam-Status: No, score=-2.2 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_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (384-bit key) header.from=ghankins@mindspring.com header.d=mindspring.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 t-vfpc_OOh-h; Wed, 16 Nov 2016 06:54:36 -0800 (PST)
Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4DB112940C; Wed, 16 Nov 2016 06:54:36 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=khhOqeneRQnEkxSxVyO5aQiZ72dnoJ96kSviK4IaHKH9fX+8wN8w8n7FE2lRLOAw; h=X-Authentication-Warning:Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:User-Agent:X-ELNK-Trace:X-Originating-IP;
Received: from [24.125.34.202] (helo=deathraid.twoguys.org) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1c71bO-0004h7-1F; Wed, 16 Nov 2016 09:54:18 -0500
Received: from deathraid.twoguys.org (localhost.twoguys.org [127.0.0.1]) by deathraid.twoguys.org (8.14.4/8.12.11) with ESMTP id uAGEsGnD027576; Wed, 16 Nov 2016 09:54:16 -0500
Received: (from ghankins@localhost) by deathraid.twoguys.org (8.14.4/8.14.4/Submit) id uAGEsGF3027575; Wed, 16 Nov 2016 09:54:16 -0500
X-Authentication-Warning: deathraid.twoguys.org: ghankins set sender to ghankins@mindspring.com using -f
Date: Wed, 16 Nov 2016 09:54:16 -0500
From: Greg Hankins 
To: Job Snijders 
Message-ID: <20161116145416.GA27144@nokia.com>
References: <20161116061556.GG1073@dhcp-9341.meeting.ietf.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20161116061556.GG1073@dhcp-9341.meeting.ietf.org>
User-Agent: Mutt/1.5.19 (2009-01-05)
X-ELNK-Trace: 176464c9115cf5b39c7f779228e2f6aeda0071232e20db4d140ed259708326c51d3c05d63f5b6c31350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 24.125.34.202
Archived-At: 
Cc: idr@ietf.org, grow@ietf.org
Subject: Re: [Idr] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 16 Nov 2016 14:54:39 -0000

I like the idea, and I think it solves an immediate network operator problem.
I also like the concept of keeping it simple.  

There are a few ongoing efforts to standardize maintenance
notificatications[1], so I suggest that the format and content of the
message be explicitly noted as out of scope and left to the operator.
Though there shouldn't be anything to prevent the operator from using a
common maintenance notification format.

Greg

[1] This one comes to mind:
https://www.peering-forum.eu/system/documents/40/original/20150923_1000_barry_odonmovan_EPF10-INEX-B_ODonovan-MaintenanceNotifications_final.pdf
https://www.maintenancemanager.org/

-- 
Greg Hankins 

-----Original Message-----
Date: Wed, 16 Nov 2016 15:15:56 +0900
From: Job Snijders 
To: grow@ietf.org, idr@ietf.org
Subject: [Idr] draft-snijders-idr-shutdown-00: Drop a line in the peer's
	syslog at shutdown

Hi GROW,

>From an operational perspective it is really useful if you can drop a
line in the peer's syslog which covers why you shutdown a BGP session.
A common use case is to provide a reference between the shutdown event
and an emailed maintenance notification, or maybe you want to make an
emotional statement.

Fictional IOS example:

	o00.frnkge02.de.bb#conf t
	Enter configuration commands, one per line.  End with CNTL/Z.
	o00.frnkge02.de.bb(config)#router bgp 65001
	o00.frnkge02.de.bb(config-router)#neighbor 129.250.6.5 shutdown "Maintenance [V-NOC-248244242] software upgrade o00.frnkge02.de.bb"

Fictional OpenBGPD example:

	[job@kiera ~]$ bgpctl neighbor down AS15562_scarlett_IPv6 "I hate you, depeered"
	request processed
	[job@kiera ~]$

In the above examples, the other side might find something like this in
their logs:

	Nov 16 00:20:41 frankfurt-router 589711: RP/0/RSP0/CPU0:Nov 16 00:20:41.653 : bgp[1059]: %ROUTING-BGP-5-ADJCHANGE : neighbor X.Y.Z.A Down - Peer closing down the session (VRF: default) (AS: 35994) (Shutdown Communication: "Maintenance [V-NOC-248244242] software upgrade o00.frnkge02.de.bb")

or perhaps:

	Nov 16 06:59:50 herpaderp bgpd[99938]: neighbor 165.254.255.1 (AS15562_scarlett_IPv4): received notification: Cease, shutdown communication: "I hate you, depeered"

Some might wonder, why "Cease"?

The beauty of using a new Cease subcode, is that the NOTIFICATION
message type already allows extra data to be attached, so for most
implementations it will be very simple to bolt what is specified in
draft-snijders-idr-shutdown-00 on top of their existing code. In some
cases we are looking at just a handful of lines.

Out of all the moments in the lifecycle of BGP interactions, I believe
that the 'shutdown' moment is the most critical one to decorate with
some freeform text. This is low hanging fruit and as should be treated
accordingly. There other moments where one might want to chat with the
neighbor, but those are out of scope for this document, you can always
call or email them!

Previous attempts such as draft-ietf-idr-advisory-00 and
draft-ietf-idr-operational-message-00 failed to deliver for various
reasons (feature creep comes to mind), therefore we are trying to do
this as simple as possible. 

Kind regards,

Job


----- Forwarded message from internet-drafts@ietf.org -----

Date: Tue, 15 Nov 2016 21:30:15 -0800
From: internet-drafts@ietf.org
To: Jakob Heitz , Job Snijders , John Scudder 
Subject: New Version Notification for draft-snijders-idr-shutdown-00.txt

A new version of I-D, draft-snijders-idr-shutdown-00.txt
has been successfully submitted by Job Snijders and posted to the
IETF repository.

Name:		draft-snijders-idr-shutdown
Revision:	00
Title:		The Shutdown Communication BGP Cease Notification Message subcode 
Document date:	2016-11-15
Group:		Individual Submission
Pages:		6
URL:            https://www.ietf.org/internet-drafts/draft-snijders-idr-shutdown-00.txt
Status:         https://datatracker.ietf.org/doc/draft-snijders-idr-shutdown/
Htmlized:       https://tools.ietf.org/html/draft-snijders-idr-shutdown-00


Abstract:
   This document defines the BGP Cease NOTIFICATION message "Shutdown
   Communication" subcode for operators to transmit a short freeform
   message to describe why a BGP session was shutdown.

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

----- End forwarded message -----

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


From nobody Wed Nov 16 07:06:15 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1587B129612 for ; Wed, 16 Nov 2016 07:06:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=steffann.nl
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XV2uZdboYgdw for ; Wed, 16 Nov 2016 07:06:11 -0800 (PST)
Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:9e0:803::6]) (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 0F633129445 for ; Wed, 16 Nov 2016 07:06:11 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id C813638; Wed, 16 Nov 2016 16:06:08 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:message-id:date:date:in-reply-to:from:from :subject:subject:mime-version:content-type:content-type:received :received; s=mail; t=1479308764; bh=pb39e3XI8eBET/roZPft4UlGD/v9 EJXP2/oSv/g6MJo=; b=RrwLN6LKRRoCSYhATHGX33v5MtUEhVIBxSI2d3ApLiU+ LQPxOVVRKd+2cnwMBqziwbNwRUEGE1QOBXx2U5tLd9z2Gv0Jan7MA+1Ty137BtpB CxdprRq9Y7OSrcDEow7/H8tutf/vIOYhszU+p+GIhH+Fhq6yHx2Dy9rCthn86mY=
X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl
Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 2dH8Dujjpyno; Wed, 16 Nov 2016 16:06:04 +0100 (CET)
Received: from [IPv6:2a02:a213:a300:9300:84f7:9a92:ff46:6dc6] (unknown [IPv6:2a02:a213:a300:9300:84f7:9a92:ff46:6dc6]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.sintact.nl (Postfix) with ESMTPSA id CFABB37; Wed, 16 Nov 2016 16:06:03 +0100 (CET)
Content-Type: multipart/signed; boundary="Apple-Mail=_2317DC57-49F4-4748-BD55-F68592134A69"; protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Clacks-Overhead: GNU Terry Pratchett
From: Sander Steffann 
In-Reply-To: <09178499-6D25-4059-BC7B-A96CA0DAECC6@apnic.net>
Date: Wed, 16 Nov 2016 16:05:57 +0100
Message-Id: 
References:   <27701_1479159582_582A2F1E_27701_6903_1_53C29892C857584299CBF5D05346208A1EC77FE1@OPEXCLILM21.corporate.adroot.infra.ftgroup> <736EA2CC-3DD1-4F14-96ED-2916E62F6F02@cisco.com> <26709_1479217575_582B11A7_26709_12999_1_53C29892C857584299CBF5D05346208A1EC79584@OPEXCLILM21.corporate.adroot.infra.ftgroup>   <20161116001246.GB27230@pfrc.org> <4EB6222D-86A4-4A83-AF8C-364CB52B8422@juniper.net> <09178499-6D25-4059-BC7B-A96CA0DAECC6@apnic.net>
To: idr wg 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Subject: Re: [Idr] One week extension to WGLC for draft-ietf-idr-large-community
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, 16 Nov 2016 15:06:13 -0000

--Apple-Mail=_2317DC57-49F4-4748-BD55-F68592134A69
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi,

> Op 16 nov. 2016, om 05:40 heeft Geoff Huston  het =
volgende geschreven:
>=20
>> On 16 Nov. 2016, at 3:01 pm, John G. Scudder  wrote:
>>=20
>> Hi Everyone,
>>=20
>> After Bruno's comments regarding RFC 7606 style error handling being =
invoked to react to duplicate community values, a few people have =
expressed (on and off list) concern that even though that is not =
intended, the -08 text as written could possibly be misinterpreted by a =
zealous implementor. To resolve this, I propose adding the following, or =
similar, to the Error Handling section:
>>=20
>> o A BGP Large Communities attribute SHALL NOT be considered malformed =
due
>> solely to presence of duplicate community values. Such duplicates =
MUST be handled
>> by removing them as specified in Section 2.
>>=20
>> IMO this clarifies the intent of the document and doesn't represent a =
normative change. Hopefully it will resolve the concerns of those who =
were concerned about and opposed to 7606-style handling for duplicates.
>>=20
>> The authors have indicated they'll incorporate the text in an -09 =
(assuming of course that the consensus of the WGLC doesn't go against =
the change).
>>=20
>=20
> As someone who has commented on previous wordings of this intent, =
I=E2=80=99d like to say that I am very happy with this wording.

Same for me: +1
Sander


--Apple-Mail=_2317DC57-49F4-4748-BD55-F68592134A69
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJYLHXVAAoJEKAtA7D+JBO5dUIIAINWZtwlr6FnZ6rr9nJSpjJ0
ZoJBlKkflVH+qSBLD3UYD1728EizI9Ajj5sr2ehhCFclkKtz030RdI0QaObLej1Y
Pz+5IRIdAbH5bQJLKcBcmbzW3jQI/8cCm6u6lUMZhVvWcpYVoqbK6QkJ2T0CUJ27
ssi1zdsq6KitCpuf63RTA4yKXaJuBrCtl8thZvqXknalj7EJqD0q8dG787yDRsLe
uglbcyXh8yffpcg/j+1pyZAkLpX5gfRykSqbwKscWsfyYU5pCjnj9ybI9yEvEDgC
G3Eun9M/VqsoSxP9XlKPwkMKwX48utQOyQD2XliZeTNjx8v+RF9d/i9IvdC2MXA=
=szdx
-----END PGP SIGNATURE-----

--Apple-Mail=_2317DC57-49F4-4748-BD55-F68592134A69--


From nobody Wed Nov 16 07:10:05 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6131A129608; Wed, 16 Nov 2016 07:10:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=steffann.nl
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N2c7S4j3QQvM; Wed, 16 Nov 2016 07:10:01 -0800 (PST)
Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:9e0:803::6]) (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 2541912940C; Wed, 16 Nov 2016 07:10:01 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id E980238; Wed, 16 Nov 2016 16:09:59 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:message-id:date:date:in-reply-to:from:from :subject:subject:mime-version:content-type:content-type:received :received; s=mail; t=1479308998; bh=bR+y7/XG6jzKqxJlD/CncPshmG/g CPAzAwlecioInEA=; b=BYIMaMm+tgU95oEWrTJX6fReBRLU2dtm43b/Xs8Mde1G t+gUInbvmYWY+8fK4KPlo7tTiR2/9PTJUJMQsayv2Nw9W06ChwGwrJWI87+1wz2J AF2mzdrus0jrhfI6TvYSEvLZSBYG9SgtqU28DMsUJc06+wHbnGXhGpvxZbPy0P8=
X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl
Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id B6TnqBu5aJ7l; Wed, 16 Nov 2016 16:09:58 +0100 (CET)
Received: from [IPv6:2a02:a213:a300:9300:84f7:9a92:ff46:6dc6] (unknown [IPv6:2a02:a213:a300:9300:84f7:9a92:ff46:6dc6]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.sintact.nl (Postfix) with ESMTPSA id 2D88137; Wed, 16 Nov 2016 16:09:58 +0100 (CET)
Content-Type: multipart/signed; boundary="Apple-Mail=_21E75D90-C823-4B7A-B83B-E1B97A9E880C"; protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Clacks-Overhead: GNU Terry Pratchett
From: Sander Steffann 
In-Reply-To: <20161116061556.GG1073@dhcp-9341.meeting.ietf.org>
Date: Wed, 16 Nov 2016 16:09:57 +0100
Message-Id: <6EA877B8-86BB-4405-A40E-2D33A84E91B8@steffann.nl>
References: <20161116061556.GG1073@dhcp-9341.meeting.ietf.org>
To: Job Snijders 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: idr@ietf.org, grow@ietf.org
Subject: Re: [Idr] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 16 Nov 2016 15:10:03 -0000

--Apple-Mail=_21E75D90-C823-4B7A-B83B-E1B97A9E880C
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=us-ascii

Hi Job,

> From an operational perspective it is really useful if you can drop a
> line in the peer's syslog which covers why you shutdown a BGP session.

Very useful indeed, this would be a very welcome feature!

Cheers,
Sander


--Apple-Mail=_21E75D90-C823-4B7A-B83B-E1B97A9E880C
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJYLHbFAAoJEKAtA7D+JBO5UukIAIgVynTzOIaBzMIFwngRMrum
2SAIWv8VOtS3Y/PbdV0xNx9Jt0NbwRBM4buF2dhk71sTcOS8PIpj85qNDB3BPhES
89y9F0QItA7eehVXKxItJlvb0wHlXZhcbXvdXTcIAp2OAwgLaIc16fp8fM4f1vD2
L8rSB1ruCiba6twAT0XLCirB21sYPofhqQjqshCNPLemuFntEn/Eeh5igHrHUlJ9
4yLSleeyog1TJ+xeNTtRds93GaNYQyBtlyLbX/EiMW+bm8BSr+xELdI5PdXbNI2N
fHIe/QsCiARRpGj9vfS8H3e96FnYivYLOHj1mKUkSW3goPoV1wK76J6QBGRzuyg=
=oBNF
-----END PGP SIGNATURE-----

--Apple-Mail=_21E75D90-C823-4B7A-B83B-E1B97A9E880C--


From nobody Wed Nov 16 07:19:18 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 362A612969C for ; Wed, 16 Nov 2016 07:19:17 -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 CIAA1mv06vMr for ; Wed, 16 Nov 2016 07:19:16 -0800 (PST)
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0096.outbound.protection.outlook.com [104.47.33.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7241F12968D for ; Wed, 16 Nov 2016 07:19:12 -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=KmKFJTA5JXods92ZhHsXIDLR41OBGzTUQWVsPdje5BY=; b=GXCD33UlhpPDgrthz5yyiRrUsa92VZPuFieHHlLejXKjgdEPEXkFjBedEv2aH/SX+z1j5r7CtDjmE1P5R9jPcJkAjcNxAaa7X+9D0m9S4RhKRgijH22Tc/+VftuAdO6OQPjrLwbVNeXbmY6iwxV6uxUdv5/I/u/ljurINfj/Ax4=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; 
Received: from [172.29.192.68] (116.197.188.11) by CO2PR05MB2503.namprd05.prod.outlook.com (10.166.95.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.734.2; Wed, 16 Nov 2016 15:19:09 +0000
From: "John G. Scudder" 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Message-ID: 
Date: Thu, 17 Nov 2016 00:18:55 +0900
To: 
MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Mailer: Apple Mail (2.3124)
X-Originating-IP: [116.197.188.11]
X-ClientProxiedBy: HK2PR02CA0080.apcprd02.prod.outlook.com (10.165.70.48) To CO2PR05MB2503.namprd05.prod.outlook.com (10.166.95.149)
X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2503; 2:bws+1Nqvt13djQgSBZuhTVI1eXgy0dWj7a8ASvSFBkW0cyzz6f4mqMTZvvrKZ9mxFz5l7VMScNvWybiK1BrnVc2TUKU8yut21l8uNrXR6DYvLdDa1gTGG2cdq7QL8xsA98IRzQtX/bWmIO2bDdF6fRhE8mXlB+lKGgJJiai3pXc=; 3:7cx2TLsSWmEearoVaeoqlBHJvL0w+FChtUDmKyiBTy3QQpUBU0SJT1kUEWs5d3E6J7TLOsExA3w5++nFzBpL6w2z7wAHvy16gPXMAVi1eQQ5jwq2FFk/IRzAS7QkNTu04WA+v2SNd44AzlMHnWGSDz61F0z03PbfyfyjK7l9+gw=; 25:xGqoC5evjIX9f4Uk6KFzvrB8x3ZwgpJXKldi/GKdpD31mAFoZz6FpbHjyDpK2gpG+9/UCgm2XCuIAAxhDTx8G4gj5eaBNmRv3GwhiuHpkJHHVeiVd91bu75VwWhSY9uT3yKvRsEjuvIyNj3bzKCjEz3hXlUHuO1CxlZKHdEFzgm8qARWM/qyWu1z9BB657VbcJlpZSWa8bAlWtyymSJWh4ICxke4LN4mtc1ufL923mtG06F2lO5Z7nwSt2qBIstA88Y6EcSD/jQuI5PrMuJveojeeuXO1X/PoR1Z+wp5JPvFnQ/C/Vt977LkQGzyUL5cPoTx1JmA+DAzhLEXxr0U6UNAHmWdGD28F0vFjkl9LT7AYwqjM1yOZHmTZ07TD4wYJAhfC1GdqqnoGLPMXTRDqhnUOfZ1WT9K+bHuAFG+1b3610XB7s7TIcSQns8owflHZsQxUe/kggEoambCfcVj4Q==
X-MS-Office365-Filtering-Correlation-Id: 6413d6b3-9f1f-4f05-3e34-08d40e33eab7
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CO2PR05MB2503;
X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2503; 31:H1tbRtsQ3OOPc43qEYUz9in2DMJfFqNZ5iXGjtgRcjvwTB2RKKLUbh3mKXnlj40aVno4eWuSEuyd5QGj1OkM2v19jM7IyI8dBnsDz6fEh/YFbizbUVeHqrOB9tD19buQLWIKRmEWBrPRByZgHsDheAVp0cXBIDw5UavBjjDLgJREzYTc17CXfLqCFtZkQbf0+DjMrNPpQBCMuvSkrcMGdcqnlaoChEkzm7vfEb//ZUn4r3vH/aRuS1rsiUQRxxXiTyYBIil6HptRj9lAYwh8KYKePsWXspLZQjijBYNffkfjnlzqJFknydvik6DbOiAX; 20:xCEvoadzUV1BBclfet7WQjS3l4IQH3JnD7QQYUZZEUERwUia5l0nMgmb471d2wo2r0Erbi4dLSVtJrqcedCwpQ2m+vHWCX/+2vwjXw3ShxPhN4tOKXpxdHZ+jalqjs5aXZKPpFmKiGcjfvibPffWsKnKMXHddq9BboQhALPnJ5dHsESYX+05pyBCfwEdwAGZhoVgut0EOvDUbGFdk7ILiOlRrRztyZQelCn08Hn8FsJc3hIkil/E65eXy+4E39yPrwfuwc5CgFAVN88ffxEXX0gc0MQ8blDUwvP5erWocBhh0rSu9MBvI1UD8w6OH7bZyDI/n0Xloa0/M+VYhBdD6usL6BvDtPrW+eI+gRCqqfED+LgFOPnfhpSgptVJpcE4M52TGtiUctI6ZSSi3FZUa7oz1BV8ZjzUqtuJCANGE9A80w/qf/F9jFYamjryF5cijNMg38soBxfHKg92JqXhXPJMwGoPrVr7/GCJ36e3rp5+pizNxOPYfxuQe4bU1q3L
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6060326)(6040281)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041223)(6061324); SRVR:CO2PR05MB2503; BCL:0; PCL:0; RULEID:; SRVR:CO2PR05MB2503; 
X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2503; 4:NkmsLOZTiQ223lOSt6vstiQIVCU7qcFvntpSBca2iwTp48B6ACc1d76ONasWQs3bz9j1jMK53lGwrH0Uk55plKQGNudfsIkJML1RDgSV6a+0WTUegGU95jMAdN9U8lkvRRplgUQEUM8BF/JuXd4W+3niqhJ3OKMBK6rZPDvtqvIIv1dkvBteWMHBtXS9M3jMrOdGXciUvNq9laZnH+ZcZYBVSxkee7+Is4shGecZhOxutAHjwJi/9BE+sMJhny8Q+tVQNGsHQImzoyGuI2kmGMbX91erBYuUWkpz/f6H8svLBucTqnNKZi23v/OiMBhdxhny06hIDCYX0I1YTdROCsEgXTuXm4zz5NOniwbJx9k0oi1RiH9n2EzU1JRx67D4W/SN28njtDyw+aQQU0DZfafYAji5NxeuQpizoC8VffeQlc8jQNJXae3KEUGFdyMW5hdQyIHv1/cm/XFzGr05sSeQgepDmpdkbYt4+K7OzEs=
X-Forefront-PRVS: 01283822F8
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(7916002)(189002)(199003)(53754006)(5423002)(86362001)(97756001)(33656002)(46406003)(57306001)(36756003)(47776003)(2351001)(77096005)(8676002)(50226002)(5660300001)(110136003)(107886002)(66066001)(8746002)(92566002)(6916009)(97736004)(450100001)(50466002)(7736002)(305945005)(189998001)(2906002)(23726003)(6666003)(3846002)(68736007)(81166006)(6116002)(81156014)(42186005)(230783001)(7846002)(105586002)(83716003)(106356001)(101416001)(82746002)(50986999)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB2503; H:[172.29.192.68]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CO2PR05MB2503; 23:zGLjQV9tzDtiTobA4HaW2WtPy36wk6MuGiA5xLp2f?= =?us-ascii?Q?m5rsTG9p0vAHXnE1ZzxoOO1GKK4fiCTFnABjF3YvLvbX3wASJ94fGuKw1YfW?= =?us-ascii?Q?S75+Bz/56UlGE3SVW3S5JhwLA+Et3k51jrtiwsLqsPK5r2wmqoKOvPnAj7IB?= =?us-ascii?Q?rBRqtOgriNNMj/OhyFl93BR3vlbUTBZ+/yVQe0yZtmVO/xz9CeuKozCl9FB+?= =?us-ascii?Q?jeL6ErLs/PkTko1SCK86p/bUNvlrYcnK+1pUQBH4Jx9Dm1TEw08rCfd8/hQo?= =?us-ascii?Q?FS5X2IBtIIM6ITB7+/ry93Sav+X3ktjbWdRmiodE1VxbOhCcsyvBV3XS6ovn?= =?us-ascii?Q?/PCsyjgylXIbqrV9kbFM2nEOx2wlJnroUEPu5LjPZnJAVEegB0ICDfLyTvKY?= =?us-ascii?Q?p46J+kZD4bhiXiC01wt/SL1VgP/bgK7OdojHrqMYmipXqJlQI1zBd1I14sQu?= =?us-ascii?Q?DtRgLPCHD5Pq1NmNdYm591NCsgH2OWmoaytXrjpiyPfooZB1HhENyc5VE3jO?= =?us-ascii?Q?xv7i+ZcPblH/ezMkaaib+8dIct5ELWR94FqINTGuFwIpixvR6GV+nsZpweU1?= =?us-ascii?Q?MkZFPG0YLUO/PMPd3pirYNqpLTHsc64EWg1/q02NgOxALRM0I9zwOm+jEXFY?= =?us-ascii?Q?SaMxEGbH7/JW0N9zgGgxSQ8hzOc/TDIYvLAyTp/8uF58cXYu1VMfwD90Lju9?= =?us-ascii?Q?kHnlmOnruxskHeUmv+lDjCQh8V6Wy/vcvRBA3ttUCKfzW1rf09kfYJEjCZcr?= =?us-ascii?Q?7qCtWusdY0ncWdfVLWjiQkG+hCRTMrid7Cpuwe0wgtBxar5SbjqPYTGQ+x8I?= =?us-ascii?Q?iojQMf/eDkxt5yyvEwlNJC+CbzhxvgZjFYWbsXVni3eXLd9w7LXrk73SaWKk?= =?us-ascii?Q?FfKm7iIZwG0MM11yjPz14bPwZkISp4cm6HAxONvGPXqexE+X3oJLZPE3RX6K?= =?us-ascii?Q?pUGgnvZxjfEvXIFX3b3YwbFhk3s72tDg2KnUg72OcfZUOpQXVJyCJ6vRa5iV?= =?us-ascii?Q?S/YeCaQsof8ra/md+8zewc63+gLbQldo/jAM40BKx48kyalbrKZTpWdobU87?= =?us-ascii?Q?RKpAWlYHhqzmSqR6f7fE/zVayXTHGPPOUUb+OqcnN4ZmVSVY/mVqnOwnl9Y1?= =?us-ascii?Q?fFVITeU0Zmdkn82aW/RIKw5LPce9awbTV72bkoUWIB8Rfg3d+JNUVLbNYOUk?= =?us-ascii?Q?PQrKwFRvE9bqwtC1tn0h65LJPtxZlOeusW/?=
X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2503; 6:AHAd1gNiddXDYxeWJlsJG7jngKjRv6cvOVreBnYywFhZuNdOIvByrHwf5HKKhR7e9/VX1YhSSXcw75IUtwuzVUW5r9+5H/wk68dwCkqjgoEJ7V2DXiQdwc/Aq9WPZlJV7y6YqKJ4CT3lK596jmVnWWQ7s8kk03+EqJp9xt8QPLvcoCVVRGYZLC7Fgm8NdqqzFspaVJPJBjasumFWMHIk7TPui2nPAvoUVxXK4knIfGRgPhEzcWo7krEaVuEWU+p8kZ84EghcViaFv+PgC5ldAc+ij1RYvgbdzyWBqJAf3CM/giLtbUOZ47Ky1IkulRSw5lxfd90F5aEfhU6Tsxtn0Pn61O1s3Dp8NcZ4maFTmMH2RY1PpZEObG+N/pv+F5N9; 5:wc90ZtmrVYQn9zqCMMv9N+R0J/SJ6YUZDfFQ2UDBFjLRxAWOy2l9URLBqlEGikBBHvZEIb13iXYMg+4hDl+dNOUDWvZZpg9F5ay3qtyHqNXwU4REARH/p2TX24Cy7H0RswU8/Q/OIqrNEqGlkUTEuA==; 24:20ISiENR12lEj6zK+oEhqdNq8ezWaB9TC1OXQeuzBxdfOFtgUZC7Vc0JXHwSLZUqdR8WDD2mMmNn9cet2RRWSmJGMj85nxS6DMoZ8QLR1jo=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2503; 7:Qc9qBDW7Gr4lc+t1gw1zN231VetchKgmNOE0CVi2Y0KIhVhqzJwOXedxIsplTmCuIdu+0e0VKd6B/AXq7XKn80WPo7nKzY97sub45kuoKrXg4UiBp6waDp/NIuvk3hNrlTxp0IBfJjiffwkEBRWLHrFqM29lrjihLmNCpsslQGDA/Z3QVLx8CzNvzI4mQhvWEmbNlK7WgidQztEeUgGKhSnVvw3zXw0xtJGJFCzUMsu+zaMNeaQ4WmRCEOTcN5XxuF1JBQyaNmkBMppwFFN0s2zmFMOzgobJYHKOySVH/fcGkxEJOO4WoRpP2WBirby5mxP9iOKtErSV9uximth55NAr1VMhWqAnhpBnWb2DUWc=
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Nov 2016 15:19:09.8301 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB2503
Archived-At: 
Subject: [Idr] WGLC for draft-ietf-idr-deprecate-30-31-129-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: Wed, 16 Nov 2016 15:19:17 -0000

Hi All,

As we discussed at our meeting Tuesday, this begins a working group last =
call for draft-ietf-idr-deprecate-30-31-129-00.txt. Please send your =
comments to the list by December 1.=20

Because I am optimistically supposing this to be non-controversial, in =
interest of not cluttering up the list with "+1" I'm going to suggest we =
make this one "silence gives assent". If there is any objection, we'll =
revert to normal procedures.

Thanks,

--John=


From nobody Wed Nov 16 08:57:11 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C33E12959B; Wed, 16 Nov 2016 08:57:05 -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 Lpb5VK_OnMsP; Wed, 16 Nov 2016 08:57:03 -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 19CE0129561; Wed, 16 Nov 2016 08:57:02 -0800 (PST)
X-Envelope-To: idr@ietf.org
Received: from crumpet.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id uAGGuxZr015474 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Nov 2016 16:57:00 GMT (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be crumpet.local
Message-ID: <582C8FDA.4030207@foobar.org>
Date: Wed, 16 Nov 2016 16:56:58 +0000
From: Nick Hilliard 
User-Agent: Postbox 5.0.5 (Macintosh/20161020)
MIME-Version: 1.0
To: Job Snijders 
References: <20161116061556.GG1073@dhcp-9341.meeting.ietf.org>
In-Reply-To: <20161116061556.GG1073@dhcp-9341.meeting.ietf.org>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: idr@ietf.org, grow@ietf.org
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 16 Nov 2016 16:57:05 -0000

Job Snijders wrote:
>>From an operational perspective it is really useful if you can drop a
> line in the peer's syslog which covers why you shutdown a BGP session.
> A common use case is to provide a reference between the shutdown event
> and an emailed maintenance notification, or maybe you want to make an
> emotional statement.

Can we please adopt this as a WG doc in whatever WG is most appropriate?
 IDR? This looks like a ridiculously useful operational tool.

UTF8 please, considering the extent to which us-ascii does not provide
an adequate character set for a huge percentage of the world's operator
population.

Nick


From nobody Wed Nov 16 13:08:38 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C933012948B for ; Wed, 16 Nov 2016 13:08:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.646
X-Spam-Level: ***
X-Spam-Status: No, score=3.646 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 61BYOV5XJ7NG for ; Wed, 16 Nov 2016 13:08:36 -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 E4CD7129456 for ; Wed, 16 Nov 2016 13:08:35 -0800 (PST)
X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=31.133.152.135; 
From: "Susan Hares" 
To: "'idr wg'" 
Date: Wed, 16 Nov 2016 16:06:02 -0500
Message-ID: <013f01d2404d$3dfff610$b9ffe230$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0140_01D24023.552A3C30"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdJATQXKePgAmF1nTgStU0J//yEVUA==
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com 
Archived-At: 
Subject: [Idr] WG Adoption call for draft-snijders-idr-shutdown (11/16 to 11/30)
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, 16 Nov 2016 21:08:37 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0140_01D24023.552A3C30
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

This begins a 2 week WG Adoption call for draft-snijders-idr-shutdown
(11/16/2016 to 11/30/2016).   The discussion should consider whether this is
useful to operators and technical issues. 

 

 

Sue 


------=_NextPart_000_0140_01D24023.552A3C30
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


This =
begins a 2 week WG Adoption call for draft-snijders-idr-shutdown =
(11/16/2016 to 11/30/2016).   The discussion should consider =
whether this is useful to operators and technical issues. =

 
 
Sue =


------=_NextPart_000_0140_01D24023.552A3C30--


From nobody Wed Nov 16 13:29:56 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 564141294E6 for ; Wed, 16 Nov 2016 13:29:55 -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 VhybhRDqjQ9b for ; Wed, 16 Nov 2016 13:29:53 -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 D0377129437 for ; Wed, 16 Nov 2016 13:29:52 -0800 (PST)
X-Envelope-To: idr@ietf.org
Received: from cupcake.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 uAGLTohh023689 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Nov 2016 21:29:50 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 cupcake.local
Message-ID: <582CCFCD.8060306@foobar.org>
Date: Wed, 16 Nov 2016 21:29:49 +0000
From: Nick Hilliard 
User-Agent: Postbox 5.0.5 (Macintosh/20161020)
MIME-Version: 1.0
To: Susan Hares 
References: <013f01d2404d$3dfff610$b9ffe230$@ndzh.com>
In-Reply-To: <013f01d2404d$3dfff610$b9ffe230$@ndzh.com>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: 'idr wg' 
Subject: Re: [Idr] WG Adoption call for draft-snijders-idr-shutdown (11/16 to 11/30)
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, 16 Nov 2016 21:29:55 -0000

Susan Hares wrote:
> This begins a 2 week WG Adoption call for draft-snijders-idr-shutdown
> (11/16/2016 to 11/30/2016).   The discussion should consider whether
> this is useful to operators and technical issues.

yes, please let's adopt.  This is a useful tool.

Nick


From nobody Wed Nov 16 13:30:48 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 915BF1294E6 for ; Wed, 16 Nov 2016 13:30:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.017
X-Spam-Level: 
X-Spam-Status: No, score=-16.017 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=-1.497, 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 VB6_zd7YJXee for ; Wed, 16 Nov 2016 13:30:46 -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 2314B129437 for ; Wed, 16 Nov 2016 13:30:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5657; q=dns/txt; s=iport; t=1479331846; x=1480541446; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=RItoxg+EH/nL7XOigZk/VQ/nqPdmWX045F+3+bGS6ro=; b=TbbWRgsy5zKZN+XqnBIpg9a09Cg8Z9PCrogI2GKgXwVaWhTDCxAZnU2Q 7dmXgAAv1NOxix9gl1WYz9lIEJaSnnkPSqJ5rHPEhI0D4D8tyvdKvnlFR aH/K4d13Ttvc399ErOty8Yjd0bYseU/aXcF9/v61jcZO+M4MmUoSrMWZi A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CiAQDMzixY/5xdJa1eGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgnNEAQEBAQEfWIEAB403lw6PR4UbggeGIQIagXg/FAECAQEBAQEBAWI?= =?us-ascii?q?ohGgBAQEEHQYKXAIBCA4DAwECKAMCAgIwFAkIAgQBEohssnGCKYtjAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBHIsWhGmCZIJdBZpCAZBngXCINYV+jU2ECQEeN4EHHIU?= =?us-ascii?q?dcocagQwBAQE?=
X-IronPort-AV: E=Sophos;i="5.31,650,1473120000";  d="scan'208,217";a="175044211"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Nov 2016 21:30:45 +0000
Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id uAGLUjdK002257 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 16 Nov 2016 21:30:45 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 16 Nov 2016 16:30:44 -0500
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, 16 Nov 2016 16:30:44 -0500
From: "Acee Lindem (acee)" 
To: Susan Hares , "'idr wg'" 
Thread-Topic: [Idr] WG Adoption call for draft-snijders-idr-shutdown (11/16 to 11/30)
Thread-Index: AQHSQFCwHU1ohLQvaES9fbNIo1ancA==
Date: Wed, 16 Nov 2016 21:30:44 +0000
Message-ID: 
References: <013f01d2404d$3dfff610$b9ffe230$@ndzh.com>
In-Reply-To: <013f01d2404d$3dfff610$b9ffe230$@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.24.70.254]
Content-Type: multipart/alternative; boundary="_000_D452FF028996Aaceeciscocom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Idr] WG Adoption call for draft-snijders-idr-shutdown (11/16 to 11/30)
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, 16 Nov 2016 21:30:47 -0000

--_000_D452FF028996Aaceeciscocom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SSBqdXN0IHJlYWQgdGhlIGRyYWZ0IGFuZCBzdXBwb3J0IFdHIGFkb3B0aW9uLg0KVGhhbmtzLA0K
QWNlZQ0KDQpGcm9tOiBJZHIgPGlkci1ib3VuY2VzQGlldGYub3JnPG1haWx0bzppZHItYm91bmNl
c0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBTdXNhbiBIYXJlcyA8c2hhcmVzQG5kemguY29tPG1h
aWx0bzpzaGFyZXNAbmR6aC5jb20+Pg0KRGF0ZTogV2VkbmVzZGF5LCBOb3ZlbWJlciAxNiwgMjAx
NiBhdCA0OjA2IFBNDQpUbzogSURSIExpc3QgPGlkckBpZXRmLm9yZzxtYWlsdG86aWRyQGlldGYu
b3JnPj4NClN1YmplY3Q6IFtJZHJdIFdHIEFkb3B0aW9uIGNhbGwgZm9yIGRyYWZ0LXNuaWpkZXJz
LWlkci1zaHV0ZG93biAoMTEvMTYgdG8gMTEvMzApDQoNClRoaXMgYmVnaW5zIGEgMiB3ZWVrIFdH
IEFkb3B0aW9uIGNhbGwgZm9yIGRyYWZ0LXNuaWpkZXJzLWlkci1zaHV0ZG93biAoMTEvMTYvMjAx
NiB0byAxMS8zMC8yMDE2KS4gICBUaGUgZGlzY3Vzc2lvbiBzaG91bGQgY29uc2lkZXIgd2hldGhl
ciB0aGlzIGlzIHVzZWZ1bCB0byBvcGVyYXRvcnMgYW5kIHRlY2huaWNhbCBpc3N1ZXMuDQoNCg0K
U3VlDQo=

--_000_D452FF028996Aaceeciscocom_
Content-Type: text/html; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx
NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5JIGp1c3QgcmVh
ZCB0aGUgZHJhZnQgYW5kIHN1cHBvcnQgV0cgYWRvcHRpb24uJm5ic3A7PC9kaXY+DQo8ZGl2PlRo
YW5rcyw8L2Rpdj4NCjxkaXY+QWNlZTwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlk
PSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJp
OyBmb250LXNpemU6MTFwdDsgdGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJP
VFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RU
T006IDBpbjsgUEFERElORy1MRUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRP
UDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkct
VE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj5J
ZHIgJmx0OzxhIGhyZWY9Im1haWx0bzppZHItYm91bmNlc0BpZXRmLm9yZyI+aWRyLWJvdW5jZXNA
aWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2YgU3VzYW4gSGFyZXMgJmx0OzxhIGhyZWY9Im1h
aWx0bzpzaGFyZXNAbmR6aC5jb20iPnNoYXJlc0BuZHpoLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4g
c3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5XZWRuZXNkYXksIE5vdmVtYmVy
IDE2LCAyMDE2IGF0IDQ6MDYgUE08YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+
VG86IDwvc3Bhbj5JRFIgTGlzdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlkckBpZXRmLm9yZyI+aWRy
QGlldGYub3JnPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3Vi
amVjdDogPC9zcGFuPltJZHJdIFdHIEFkb3B0aW9uIGNhbGwgZm9yIGRyYWZ0LXNuaWpkZXJzLWlk
ci1zaHV0ZG93biAoMTEvMTYgdG8gMTEvMzApPGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2
Pg0KPGJsb2NrcXVvdGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0
eWxlPSJCT1JERVItTEVGVDogI2I1YzRkZiA1IHNvbGlkOyBQQURESU5HOjAgMCAwIDU7IE1BUkdJ
TjowIDAgMCA1OyI+DQo8ZGl2IHhtbG5zOnY9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206dm1s
IiB4bWxuczpvPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiIHhtbG5z
Onc9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOndvcmQiIHhtbG5zOm09Imh0dHA6
Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6
Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250
ZW50PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0K
LyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJp
YSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7
Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQov
KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z
b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp
emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5r
LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1
ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl
cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K
CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0
eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt
c2VyaWYiOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl
LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9
DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGlu
IDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv
bjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs
dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t
W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk
bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu
ZGlmXS0tPg0KPGRpdiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8
ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBiZWdp
bnMgYSAyIHdlZWsgV0cgQWRvcHRpb24gY2FsbCBmb3IgZHJhZnQtc25pamRlcnMtaWRyLXNodXRk
b3duICgxMS8xNi8yMDE2IHRvIDExLzMwLzIwMTYpLiAmbmJzcDsmbmJzcDtUaGUgZGlzY3Vzc2lv
biBzaG91bGQgY29uc2lkZXIgd2hldGhlciB0aGlzIGlzIHVzZWZ1bCB0byBvcGVyYXRvcnMgYW5k
IHRlY2huaWNhbCBpc3N1ZXMuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TdWUgPG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+DQo8L2JvZHk+DQo8L2h0
bWw+DQo=

--_000_D452FF028996Aaceeciscocom_--


From nobody Wed Nov 16 14:21:37 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E59D1293FB for ; Wed, 16 Nov 2016 14:21:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.018
X-Spam-Level: 
X-Spam-Status: No, score=-16.018 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=-1.497, 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 BJRneAmO-SUB for ; Wed, 16 Nov 2016 14:21:35 -0800 (PST)
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 1270B129446 for ; Wed, 16 Nov 2016 14:21:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6148; q=dns/txt; s=iport; t=1479334895; x=1480544495; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=qZVo04yK1IoAhXzt+a03vNFld5J27He/UIS3+8i4LkI=; b=Qfx02Btx1DCSt6YBlPpM0IefLlozoQUG04QtRXQR/i+Q3v9ESNrZkR/m r0zjr5Qb3P6ACm0x0Ua8UoKSGoK1qjmstRwPqYT7CKOsJtSvXgnyzLiI2 C33LE4lz18weOxuITMpPSU0/rG1B7awweGnrcrPQWCn8akRFkr9DXpsQL U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CiAQDG2ixY/5RdJa1eGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgnNEAQEBAQEfWIEAB403lw6PR4UbggeGIQIagXg/FAECAQEBAQEBAWI?= =?us-ascii?q?ohGgBAQEEHQZmAgEIDgMDAQIoAwICAjAUCQgCBAESiGyybIIpL4szAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBHIY8gX0IglWEaRaCTi2CMAWUWoVoAZBnkCONTYQJAR4?= =?us-ascii?q?3gQcchR1yhxqBDAEBAQ?=
X-IronPort-AV: E=Sophos;i="5.31,650,1473120000";  d="scan'208,217";a="349419187"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Nov 2016 22:21:34 +0000
Received: from XCH-RTP-007.cisco.com (xch-rtp-007.cisco.com [64.101.220.147]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id uAGMLXka025489 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 16 Nov 2016 22:21:34 GMT
Received: from xch-rtp-008.cisco.com (64.101.220.148) by XCH-RTP-007.cisco.com (64.101.220.147) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 16 Nov 2016 17:21:33 -0500
Received: from xch-rtp-008.cisco.com ([64.101.220.148]) by XCH-RTP-008.cisco.com ([64.101.220.148]) with mapi id 15.00.1210.000; Wed, 16 Nov 2016 17:21:33 -0500
From: "Harold Ritter (hritter)" 
To: Susan Hares , "'idr wg'" 
Thread-Topic: [Idr] WG Adoption call for draft-snijders-idr-shutdown (11/16 to 11/30)
Thread-Index: AQHSQFC2C2/sWwkUJUWbwsdQv3GCR6DcLvGA
Date: Wed, 16 Nov 2016 22:21:33 +0000
Message-ID: <24729686-3E0A-4A45-8210-FF1D464E4623@cisco.com>
References: <013f01d2404d$3dfff610$b9ffe230$@ndzh.com> 
In-Reply-To: 
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.1c.0.161115
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.82.183.1]
Content-Type: multipart/alternative; boundary="_000_247296863E0A4A458210FF1D464E4623ciscocom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Idr] WG Adoption call for draft-snijders-idr-shutdown (11/16 to 11/30)
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, 16 Nov 2016 22:21:36 -0000

--_000_247296863E0A4A458210FF1D464E4623ciscocom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SSBzdXBwb3J0IHRoaXMgZHJhZnQuDQoNCg0KRnJvbTogSWRyIDxpZHItYm91bmNlc0BpZXRmLm9y
ZzxtYWlsdG86aWRyLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgU3VzYW4gSGFyZXMg
PHNoYXJlc0BuZHpoLmNvbTxtYWlsdG86c2hhcmVzQG5kemguY29tPj4NCkRhdGU6IFdlZG5lc2Rh
eSwgTm92ZW1iZXIgMTYsIDIwMTYgYXQgNDowNiBQTQ0KVG86IElEUiBMaXN0IDxpZHJAaWV0Zi5v
cmc8bWFpbHRvOmlkckBpZXRmLm9yZz4+DQpTdWJqZWN0OiBbSWRyXSBXRyBBZG9wdGlvbiBjYWxs
IGZvciBkcmFmdC1zbmlqZGVycy1pZHItc2h1dGRvd24gKDExLzE2IHRvIDExLzMwKQ0KDQpUaGlz
IGJlZ2lucyBhIDIgd2VlayBXRyBBZG9wdGlvbiBjYWxsIGZvciBkcmFmdC1zbmlqZGVycy1pZHIt
c2h1dGRvd24gKDExLzE2LzIwMTYgdG8gMTEvMzAvMjAxNikuICAgVGhlIGRpc2N1c3Npb24gc2hv
dWxkIGNvbnNpZGVyIHdoZXRoZXIgdGhpcyBpcyB1c2VmdWwgdG8gb3BlcmF0b3JzIGFuZCB0ZWNo
bmljYWwgaXNzdWVzLg0KDQoNClN1ZQ0K

--_000_247296863E0A4A458210FF1D464E4623ciscocom_
Content-Type: text/html; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iVGl0cmUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJNb3RzIGNsw6lzIiBjb250
ZW50PSIiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAx
NSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAq
Lw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToy
IDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN
CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq
Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNt
Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt
aWx5OkNhbGlicmk7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp
b3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6
dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6
OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5F
bWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6Q2Fs
aWJyaTsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHls
ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2lu
ZG93dGV4dDt9DQpzcGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglt
c28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRl
YWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u
dC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4w
cHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rp
b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBi
Z2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRlIiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRp
diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SSBzdXBwb3J0IHRoaXMgZHJhZnQuPC9zcGFu
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l
dyBSb21hbiZxdW90Oztjb2xvcjpibGFjayI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+PGJyIGNsZWFy
PSJhbGwiPg0KJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHls
ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w
cHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4t
VVMiIHN0eWxlPSJjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1V
UyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5JZHIgJmx0Ozwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6
YmxhY2siPjxhIGhyZWY9Im1haWx0bzppZHItYm91bmNlc0BpZXRmLm9yZyI+PHNwYW4gbGFuZz0i
RU4tVVMiPmlkci1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gbGFuZz0i
RU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0Ow0KIG9uIGJlaGFsZiBvZiBTdXNhbiBIYXJl
cyAmbHQ7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PGEgaHJlZj0ibWFpbHRvOnNo
YXJlc0BuZHpoLmNvbSI+PHNwYW4gbGFuZz0iRU4tVVMiPnNoYXJlc0BuZHpoLmNvbTwvc3Bhbj48
L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDs8YnI+
DQo8Yj5EYXRlOiA8L2I+V2VkbmVzZGF5LCBOb3ZlbWJlciAxNiwgMjAxNiBhdCA0OjA2IFBNPGJy
Pg0KPGI+VG86IDwvYj5JRFIgTGlzdCAmbHQ7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj
ayI+PGEgaHJlZj0ibWFpbHRvOmlkckBpZXRmLm9yZyI+PHNwYW4gbGFuZz0iRU4tVVMiPmlkckBp
ZXRmLm9yZzwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6
YmxhY2siPiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+W0lkcl0gV0cgQWRvcHRpb24gY2FsbCBm
b3IgZHJhZnQtc25pamRlcnMtaWRyLXNodXRkb3duICgxMS8xNiB0byAxMS8zMCk8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs
YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGlt
ZXMgTmV3IFJvbWFuJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N
CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQjVDNERG
IDQuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQ7bWFyZ2luLWxlZnQ6My43NXB0O21hcmdp
bi1yaWdodDowY20iIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIj4NCjxk
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoaXMg
YmVnaW5zIGEgMiB3ZWVrIFdHIEFkb3B0aW9uIGNhbGwgZm9yIGRyYWZ0LXNuaWpkZXJzLWlkci1z
aHV0ZG93biAoMTEvMTYvMjAxNiB0byAxMS8zMC8yMDE2KS4gJm5ic3A7Jm5ic3A7VGhlIGRpc2N1
c3Npb24gc2hvdWxkIGNvbnNpZGVyIHdoZXRoZXIgdGhpcyBpcyB1c2VmdWwgdG8gb3BlcmF0b3Jz
IGFuZCB0ZWNobmljYWwgaXNzdWVzLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+
U3VlIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+
DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_247296863E0A4A458210FF1D464E4623ciscocom_--


From nobody Wed Nov 16 14:36:52 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8952F129570 for ; Wed, 16 Nov 2016 14:36:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=steffann.nl
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id el8w8-z8holF for ; Wed, 16 Nov 2016 14:36:49 -0800 (PST)
Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:9e0:803::6]) (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 D66201293EB for ; Wed, 16 Nov 2016 14:36:48 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id A375638; Wed, 16 Nov 2016 23:36:46 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:message-id:date:date:in-reply-to:from:from :subject:subject:mime-version:content-type:content-type:received :received; s=mail; t=1479335805; bh=EDWycJvVfwGHps0qe42RC+xfEYYu kkriu5suwpm4uQU=; b=rOBnXUSEN7bNNcAH9fZN1AHaufRi0MIQ7Qvd7IHqjsla IYXvo1+QYfRlXBf/k5C+/UQkua+pQCHB4kDzaFKY8yVID26HMserBU9jj/5ilzOv PYZ+ZaGio3CbAjy+xPYAr/jx9l77v/1pIW8pzuvj0Saa3mVatFqEVZN7VUIgkeI=
X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl
Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id OxqHfxIwSJsm; Wed, 16 Nov 2016 23:36:45 +0100 (CET)
Received: from [IPv6:2a02:a213:a300:9300:25e8:ade7:8748:8030] (unknown [IPv6:2a02:a213:a300:9300:25e8:ade7:8748:8030]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.sintact.nl (Postfix) with ESMTPSA id 1DA8837; Wed, 16 Nov 2016 23:36:45 +0100 (CET)
Content-Type: multipart/signed; boundary="Apple-Mail=_20032FF6-3C49-451C-AA32-E8E8C48A993A"; protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Clacks-Overhead: GNU Terry Pratchett
From: Sander Steffann 
In-Reply-To: <013f01d2404d$3dfff610$b9ffe230$@ndzh.com>
Date: Wed, 16 Nov 2016 23:36:44 +0100
Message-Id: <027F930B-5CB9-4BDE-8D77-985E2F819D6F@steffann.nl>
References: <013f01d2404d$3dfff610$b9ffe230$@ndzh.com>
To: Susan Hares 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: idr wg 
Subject: Re: [Idr] WG Adoption call for draft-snijders-idr-shutdown (11/16 to 11/30)
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, 16 Nov 2016 22:36:50 -0000

--Apple-Mail=_20032FF6-3C49-451C-AA32-E8E8C48A993A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi,

> Op 16 nov. 2016, om 22:06 heeft Susan Hares  het =
volgende geschreven:
>=20
> This begins a 2 week WG Adoption call for draft-snijders-idr-shutdown =
(11/16/2016 to 11/30/2016).   The discussion should consider whether =
this is useful to operators and technical issues.

Very useful to operators! Please adopt.

Cheers,
Sander


--Apple-Mail=_20032FF6-3C49-451C-AA32-E8E8C48A993A
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJYLN98AAoJEKAtA7D+JBO5zcAH/24RtszkpbxN7r/Dh/Lr6Vjh
socgHyn5ru4kJqC7pQW4wWCa1Ph3FfJT8cj7fYZkYnmgKD6j5h5b8LFcAL0wtbMi
jIaAhJUmMfz2kUemfA0IDJ8o6pbJXQ0AkjHabiuOqCB1YHpRzXFygpGz2yEfz7Gy
Tq41dDW03FqfX2c3/1LzrNdjtiiEvNUV0dz+dQpDKsC8gpOF6t29RxB7GBqnZ9EI
xS5JOdFB1ghCNnKbIs989kUUloMqNgitXkSSKg4nSZsBqApIbJgD6uECgCtmlD6g
kZT113bPLl7eDXkxVfbBrutnLeOg7SS172EMzrs2cOIPXo7A5gJb8ajHm47jKLg=
=wM5v
-----END PGP SIGNATURE-----

--Apple-Mail=_20032FF6-3C49-451C-AA32-E8E8C48A993A--


From nobody Wed Nov 16 15:12:13 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD1EB1295AD for ; Wed, 16 Nov 2016 15:12:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6PqHM86ofVYR for ; Wed, 16 Nov 2016 15:12:10 -0800 (PST)
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 D64A7129432 for ; Wed, 16 Nov 2016 15:12:08 -0800 (PST)
Received: by mail-wm0-x22b.google.com with SMTP id t79so107158930wmt.0 for ; Wed, 16 Nov 2016 15:12:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ctdAi6hySPI6D1bGgBiT7xytyeLjmXjY+jmWgAIVtzM=; b=nXucNNSfQWnt1qdi6D2IE0hL6YfnbJkvldknN6OeimlSODDiHEcFQunUmZhFxPJLk5 KGGw752cQS/kUvtWN1Njn1eXg4iUBvdi6POYIv72rtUmgiHiUcyOwXmqM3xgquEzW1HR GSaYMsVkCl7NlwO8q3zj4OGDhqXj0O0liQmlClCoOvzAIzFUgegR9S9M1L3kVFqy1U1O ryIaZxIBNZC0PBJXOJ6zORW/o8PThO0Thh5+eu5b5o0qFFaeCqOewHw4NPY6ADh/J3NZ CKCitbSbva9F2sUQJYh/WOVAZKaNWV8ZGWSyiVXWy4crRBaORvdvFrkxavKTPZgZMw8r fwmA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ctdAi6hySPI6D1bGgBiT7xytyeLjmXjY+jmWgAIVtzM=; b=klOkxGNccwGzaZ+MvyQ6bwNuKjXlV4Gf0klImukyz/JtESjog8oRztjm8iFe5xkGzO rVxwYqtP+6nV1+UDK7tAu5cVU+yFF7ULlmJwcBXc/SyfUrOFJKzOpSRyaDlH4vwzeSxm MXqD+LqjqGELbsTBRo7w8+4X9xWTxeSRXbqEHZEw+O8ymfWjfGeU8U5LhkPfS6hTWGbL V1YBjFcXZSA1ANvlJoG2XHa+SW5R87MRtj7n0uiLXeBe0ZyRpMNC44aLl/TcXtnISeqo DAR3DCUgN0wy/zf/6dAzqv/8fLMRGdf/odhb/b3bD3E05THtaEBI0+vox7U/ibXMVDJx o+Eg==
X-Gm-Message-State: AKaTC018qcPmXF7SkmlHsdQ1VUUiVDWs3gcRjVms5HeXNWPwRmfFlyMFqlr9I8c2NUdZnkKNiIkXJOWqhlE6NA==
X-Received: by 10.194.78.195 with SMTP id d3mr45707wjx.96.1479337927414; Wed, 16 Nov 2016 15:12:07 -0800 (PST)
MIME-Version: 1.0
Received: by 10.28.197.132 with HTTP; Wed, 16 Nov 2016 15:12:06 -0800 (PST)
In-Reply-To: <013f01d2404d$3dfff610$b9ffe230$@ndzh.com>
References: <013f01d2404d$3dfff610$b9ffe230$@ndzh.com>
From: Brian Dickson 
Date: Wed, 16 Nov 2016 15:12:06 -0800
Message-ID: 
To: Susan Hares 
Content-Type: multipart/alternative; boundary=047d7bfd0010aa97590541733327
Archived-At: 
Cc: idr wg 
Subject: Re: [Idr] WG Adoption call for draft-snijders-idr-shutdown (11/16 to 11/30)
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, 16 Nov 2016 23:12:11 -0000

--047d7bfd0010aa97590541733327
Content-Type: text/plain; charset=UTF-8

Useful to operators. Support adoption.

Brian

On Wed, Nov 16, 2016 at 1:06 PM, Susan Hares  wrote:

> This begins a 2 week WG Adoption call for draft-snijders-idr-shutdown
> (11/16/2016 to 11/30/2016).   The discussion should consider whether this
> is useful to operators and technical issues.
>
>
>
>
>
> Sue
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
>

--047d7bfd0010aa97590541733327
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Useful to operators. Support adoption.

=
Brian

=
On Wed, Nov 16, 2016 at 1:06 PM, Susan Hares <shares@ndzh.com> wrote:
This begins a 2 week WG Adoption call for draft-snijders-id=
r-shutdown (11/16/2016 to 11/30/2016). =C2=A0=C2=A0The discussion should co=
nsider whether this is useful to operators and technical issues. =

=C2=A0
=C2=A0
Sue 

_______________________________________________

Idr mailing list

Idr@ietf.org

https://www.ietf.org/mailman/listinfo/idr





--047d7bfd0010aa97590541733327--


From nobody Wed Nov 16 16:26:27 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C1001295B7 for ; Wed, 16 Nov 2016 16:26:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.797
X-Spam-Level: 
X-Spam-Status: No, score=-5.797 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_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sunet.se
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1pyWEKAHTvY0 for ; Wed, 16 Nov 2016 16:26:20 -0800 (PST)
Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) (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 83C001295DE for ; Wed, 16 Nov 2016 16:26:20 -0800 (PST)
Received: from smtp1.sunet.se (smtp1.sunet.se [192.36.171.214]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id uAH0QHHi003252 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 17 Nov 2016 01:26:17 +0100
Received: from kerio.sunet.se (kerio.sunet.se [192.36.171.210]) by smtp1.sunet.se (8.14.9/8.14.9) with ESMTP id uAH0QEEW000091 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Nov 2016 00:26:16 GMT
VBR-Info: md=sunet.se; mc=all; mv=swamid.se
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sunet.se; s=default; t=1479342377; bh=FWj0q2ZAyh7kWv5FkWzqRHE62VNcKzEZK4UyaPovVco=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=iYp9z/02to9b4fuWPxk3MPFh7zxs/Hk7eoKKMiAMDKsX2HpyXzOhnYWxwgVLDE168 +EJ/vKnndZGPkaJBQzt97Vpd8MmnGqC9ZbRCNK0FaBUnE1XzxeYOduxxJR8I6dSS3u AizC8f+HD3T0Z6MNuhhhQWAotbgKrgB5fVWLFXKY=
X-Footer: c3VuZXQuc2U=
Received: from dhcp-86bf.meeting.ietf.org ([31.133.134.191]) (authenticated user per@sunet.se) by kerio.sunet.se (Kerio Connect 9.1.1) with ESMTPSA (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256 bits)); Thu, 17 Nov 2016 01:26:11 +0100
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/alternative; boundary="Apple-Mail=_8787E84C-1B7D-4C4D-8E11-BCCF83903759"
From: =?utf-8?Q?Per_Nihl=C3=A9n?= 
In-Reply-To: <013f01d2404d$3dfff610$b9ffe230$@ndzh.com>
Date: Thu, 17 Nov 2016 09:25:52 +0900
Message-Id: <24FA30F8-8308-4292-97E7-4F1A4823C3D3@sunet.se>
References: <013f01d2404d$3dfff610$b9ffe230$@ndzh.com>
To: Susan Hares 
X-Mailer: Apple Mail (2.3124)
X-CanIt-Geo: ip=192.36.171.210; country=SE; latitude=59.3294; longitude=18.0686; http://maps.google.com/maps?q=59.3294,18.0686&z=6
X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default)
X-Canit-Stats-ID: 09S8Mqhvj - e7c9c7500882 - 20161117
X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw
Received-SPF: neutral (e-mailfilter01.sunet.se: 192.36.171.210 is neither permitted nor denied by domain per@sunet.se) receiver=e-mailfilter01.sunet.se; client-ip=192.36.171.210; envelope-from=; helo=smtp1.sunet.se; identity=mailfrom
X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.36.171.201
Archived-At: 
Cc: idr wg 
Subject: Re: [Idr] WG Adoption call for draft-snijders-idr-shutdown (11/16 to 11/30)
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, 17 Nov 2016 00:26:24 -0000

--Apple-Mail=_8787E84C-1B7D-4C4D-8E11-BCCF83903759
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I support this as an operator.

=E2=80=94=20
 Per

> On 17 Nov 2016, at 06:06, Susan Hares  wrote:
>=20
> This begins a 2 week WG Adoption call for draft-snijders-idr-shutdown =
(11/16/2016 to 11/30/2016).   The discussion should consider whether =
this is useful to operators and technical issues.=20
> =20
> =20
> Sue=20
> _______________________________________________
> Idr mailing list
> Idr@ietf.org 
> https://www.ietf.org/mailman/listinfo/idr =


--Apple-Mail=_8787E84C-1B7D-4C4D-8E11-BCCF83903759
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

I support this as an operator.

=E2=80=94 
 Per

On 17 Nov 2016, at 06:06, Susan =
Hares <shares@ndzh.com> wrote:

This begins a 2 week WG =
Adoption call for draft-snijders-idr-shutdown (11/16/2016 to =
11/30/2016).   The discussion should consider whether this is =
useful to operators and technical issues. 
 
 
Sue 
_______________________________________________
Idr mailing =
list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

=

--Apple-Mail=_8787E84C-1B7D-4C4D-8E11-BCCF83903759--


From nobody Wed Nov 16 17:02:29 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C92BC129604 for ; Wed, 16 Nov 2016 17:02:27 -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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 hHmu0SV4ho0Z for ; Wed, 16 Nov 2016 17:02:25 -0800 (PST)
Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EB6A1295F7 for ; Wed, 16 Nov 2016 17:02:23 -0800 (PST)
Received: by mail-pg0-x22d.google.com with SMTP id p66so84971623pga.2 for ; Wed, 16 Nov 2016 17:02:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=user-agent:date:subject:from:to:message-id:thread-topic:references :in-reply-to:mime-version; bh=YiSoiS833yE4Z4mcJeUEyFHYtHJEVGzLPIu9G7uvNAE=; b=03uzBvvcNo3IBH87iDUILtKRShMRfCGshaksJezqf5nBChnD4i4V2W+MHFDPeG3fCV aA86PcO7zLPPkbjzDWffDueSFqJd8GzfbbwzesXbebuTm87oykg1feMpOzKmDSlkaVI1 WOK9d4Da6ZqITSOVsaf4HmzZSpFrymp3BsrnHIt7OyfcQgLlk6taiDtuuVbVW+qrCyOm P1o5VBcYW65XBNhJ5+csGEHQzJQUnST+Ff/q2zVp5iU80DL7be6COBeNAQy2cJALfpkE IrjwxY7jeNHJyjRJngXXMsEh5FeQUexFZ17zitXb6s6WRdo9Da92P7RZkQQIqkp02URu Fh5w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:references:in-reply-to:mime-version; bh=YiSoiS833yE4Z4mcJeUEyFHYtHJEVGzLPIu9G7uvNAE=; b=Ci0cJME9Fya7irJtlbltphdIRmqLutZw8IDjCjcjEC0BccSg2hDBG3lVpiMdN+7je4 eQ+tLNffdsx6kQyC6gcJV+97fCe7Snd+b6MT532GI6pfxBkR6YXgWitPsQ90edbKgCHD ig5OATe9VBfj38FR+DttZslE6NU+2e+JQyutKmq+9/oI2IX8/TfyFRFNpxMSVmvimyEh XlzuV3UDHANi3CD2UGRFIdnlZzsQN5luruccBEE2gKdM9Si4KNItYXa1HWry135Oj5JT AD3z1YjwZ0YAzEeW+iqX5ynAeI1YcwsJ0pWbS5kuYDvTRmhGw8GIiftBglpAB+H/pLLW Nagw==
X-Gm-Message-State: ABUngvfEdz0xx9l8udv5R+TDL5Y5+0P8oKDX8Bgb07kUd2Jx1okoChn2CdO/Sh1DgKYu1w==
X-Received: by 10.98.8.84 with SMTP id c81mr720099pfd.114.1479344542931; Wed, 16 Nov 2016 17:02:22 -0800 (PST)
Received: from [31.133.129.79] ([2001:67c:370:128:6c39:eec9:7c6b:75f5]) by smtp.gmail.com with ESMTPSA id n24sm557418pfb.0.2016.11.16.17.02.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Nov 2016 17:02:22 -0800 (PST)
User-Agent: Microsoft-MacOutlook/f.1b.0.161010
Date: Wed, 16 Nov 2016 17:02:53 -0800
From: Jeff Tantsura 
To: Susan Hares , 'idr wg' 
Message-ID: <5E6E3C09-8181-4870-BE3C-9D0A4553DA96@gmail.com>
Thread-Topic: [Idr] WG Adoption call for draft-snijders-idr-shutdown (11/16 to 11/30)
References: <013f01d2404d$3dfff610$b9ffe230$@ndzh.com>
In-Reply-To: <013f01d2404d$3dfff610$b9ffe230$@ndzh.com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3562160581_523745619"
Archived-At: 
Subject: Re: [Idr] WG Adoption call for draft-snijders-idr-shutdown (11/16 to 11/30)
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, 17 Nov 2016 01:02:28 -0000

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3562160581_523745619
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: 7bit

Support!

 

Cheers,

Jeff

 

 

From: Idr  on behalf of Susan Hares 
Date: Wednesday, November 16, 2016 at 13:06
To: 'idr wg' 
Subject: [Idr] WG Adoption call for draft-snijders-idr-shutdown (11/16 to 11/30)

 

This begins a 2 week WG Adoption call for draft-snijders-idr-shutdown (11/16/2016 to 11/30/2016).   The discussion should consider whether this is useful to operators and technical issues. 

 

 

Sue 

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


--B_3562160581_523745619
Content-type: text/html;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable


Support!
 
Cheers,<=
o:p>
Jeff
 <=
/p>
 
From: Idr <idr-=
bounces@ietf.org> on behalf of Susan Hares <shares@ndzh.com>
=
Date: Wednesday, November 16, 2016 at 13:06
To: 'idr wg' <i=
dr@ietf.org>
Subject: [Idr] WG Adoption call for draft-snijders=
-idr-shutdown (11/16 to 11/30)
 
This begins a 2 week WG Adoption call for draft-snijders-idr-shutdo=
wn (11/16/2016 to 11/30/2016).   The discussion should consider wh=
ether this is useful to operators and technical issues. 
 
 
<=
p class=3DMsoNormal>Sue 
___________________________=
____________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mail=
man/listinfo/idr 


--B_3562160581_523745619--



From nobody Wed Nov 16 17:17:14 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C64B0129863; Wed, 16 Nov 2016 17:17:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.399
X-Spam-Level: 
X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, 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 AxOcfR266vqf; Wed, 16 Nov 2016 17:17:08 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 79FC0129855; Wed, 16 Nov 2016 17:16:49 -0800 (PST)
Received: by slice.pfrc.org (Postfix, from userid 1001) id A60901E369; Wed, 16 Nov 2016 20:19:45 -0500 (EST)
Date: Wed, 16 Nov 2016 20:19:45 -0500
From: Jeffrey Haas 
To: Job Snijders 
Message-ID: <20161117011945.GA6217@pfrc.org>
References: <20161116061556.GG1073@dhcp-9341.meeting.ietf.org> <20161116105535.GW79185@Space.Net> <1479295774707.77855@dacor.de> <20161116113849.udbrfvdhaj3be7nx@bongo.bofh.it> <20161116130110.GK1073@dhcp-9341.meeting.ietf.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20161116130110.GK1073@dhcp-9341.meeting.ietf.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: 
Cc: "idr@ietf.org" , "grow@ietf.org" , Marco d'Itri 
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 17 Nov 2016 01:17:11 -0000

On Wed, Nov 16, 2016 at 10:01:10PM +0900, Job Snijders wrote:
> Unless some implementors make significant arguments along the lines of
> "we CANNOT implement this Shutdown Communication functionality, SOLELY
> because of utf8 and lack of representation filtering capabilities", i'd
> water down the utf8 requirement to 7bit ascii (because in the end its
> better to have 'something' than nothing). Another line of argumentation
> against utf8 would be if major security concerns are articulated.

In general, IESG comments will push any user-displayable string to UTF-8
anyway, so I wouldn't stress over this being the requirement.  It's pretty
much an IETF-wide expectation these days.

I think your doc is the first one that I've seen bothering to cite the
unicode considerations documents.  Ideally that'd be a pointer to somewhere
else in a single ref, but I don't think I've seen such an IETF document.

> I hope to capture in the draft that an implementation can choose which
> characters of the Shutdown Communication they represent in the syslog or
> 'show bgp neighbor xxx' output. For instance, I'd recommend to squash
> all newline/newpage/newfeed/newparagraph style chars and make sure that
> the Communication is represented on a single line. I don't have the
> proper words for the draft to express that (yet).

Again, perhaps too much to tackle in this document.

A portion of what you're interested in is covered under the control
characters section:

https://en.wikipedia.org/wiki/Unicode_control_characters

If you try to get too normative you're going to spend a huge amount of text
trying to close all of the holes.

> Also I don't mind if an implementation consciously chooses to only
> represent 7bit ASCII. That should be an implementor decision. They can
> upgrade later. In theory the protocol spec shouldn't be delayed or
> obstructed due to an implementor's current internationalisation
> capabilities (which can change over time).

ASCII is conformant UTF-8, which is one of the nice properties about that
encoding.  What tends to be problematic in many people's implementations is
emitting Latin-1 or similar encodings that are 8-bit as if they're valid
UTF-8, which they're not.

The better question is what the general expected behavior is when things
cannot be displayed.  Some of that will depend on the i18n capabilities of
someone's implementation.


-- Jeff


From nobody Wed Nov 16 17:24:21 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 813E71295D8 for ; Wed, 16 Nov 2016 17:24:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level: 
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=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=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 FMvbn-Dk0-5M for ; Wed, 16 Nov 2016 17:24:16 -0800 (PST)
Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::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 A80F21293FD for ; Wed, 16 Nov 2016 17:24:15 -0800 (PST)
Received: by mail-it0-x22b.google.com with SMTP id j191so9156429ita.1 for ; Wed, 16 Nov 2016 17:24:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=ZTTaGQRqVNAtlzDv/rXtIKx/EKEHff0DRz9pX8VhdmA=; b=PI099+2CzewB7sIg7FmsFzOYGuK2peTBhTqeqpa/wYCD0ow7ndzaiNiwbcXDU2Fk1R 4NhGbm8LAEYTZBVI1XGqyQzj3vtrYs6nR6D6j/BodD0x5ippXmj0eUYOwQ4DBZ9TV0f9 /VUm7GXhlA6dn348c4LBhoOLrjzIPL9wtRA35HL/1u9jvIe78RbeQ5LiczQyEHtrnBG7 eesWLKdRGFLqrB8AnRUsRD9PT/L/OcthaBzULgqdO4i4ecSB1JHJUb8Wj6Gtf9SB7l75 UYwC/vOVRQNbCyeEfUQzdkh0QY/Cc5oUGn4oOshJvBI7+2EyvJUxCkSxKRXT2jjGRAPU 21YQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=ZTTaGQRqVNAtlzDv/rXtIKx/EKEHff0DRz9pX8VhdmA=; b=Up1ESl6uoZYqxbE+V5V2tM3lQWTgedLALf18j+QZx2AGtcqZMss52ur7VmHl6fBx9E 7fd4Yb4GjJxvUR1oROiHk/PUKJPA3QG60zrGOts+osBOVPeSTO6nuoGgtrTQeQTa9eWS s6DRIrpaE9MTFg9WMCCuoynq+7WLx06AF2MPweK2yL7E70zHp196j+wxfq4Z9bv+SGpw tBEvWYyV2PzGyYbLTWOxmahtGK9h7DIra/6UrB9VqZr+4vWDMnvZ1ybB/4xlBAr+qXUY 6NXbO0luW7tJRkSpyJ8lR9wQ3M7cKqxrhfW9VV09aUy171/Td1sLZw0mB0mJ4UR4FK57 GmsA==
X-Gm-Message-State: ABUngvd5fhBGOpPuwXAz7keUInLH1XOFgZwWO/BfNIly21wx46rqRo/yAnSylWvuQuTy8MCoRH8Q+zp1pL75lg==
X-Received: by 10.36.125.65 with SMTP id b62mr921354itc.10.1479345854712; Wed, 16 Nov 2016 17:24:14 -0800 (PST)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.107.1.16 with HTTP; Wed, 16 Nov 2016 17:24:13 -0800 (PST)
Received: by 10.107.1.16 with HTTP; Wed, 16 Nov 2016 17:24:13 -0800 (PST)
In-Reply-To: <013f01d2404d$3dfff610$b9ffe230$@ndzh.com>
References: <013f01d2404d$3dfff610$b9ffe230$@ndzh.com>
From: Robert Raszuk 
Date: Thu, 17 Nov 2016 02:24:13 +0100
X-Google-Sender-Auth: dbpCQojG3rBPdpN_P7qnvUYB0oI
Message-ID: 
To: idr wg , Susan Hares 
Content-Type: multipart/alternative; boundary=001a1144d62a2b919e0541750c7c
Archived-At: 
Subject: Re: [Idr] WG Adoption call for draft-snijders-idr-shutdown (11/16 to 11/30)
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, 17 Nov 2016 01:24:20 -0000

--001a1144d62a2b919e0541750c7c
Content-Type: text/plain; charset=UTF-8

I support adoption of this draft.

One suggestion for text clarification.

The draft says:

" It is RECOMMENDED that a BGP speaker receiving a Shutdown
   Communication observe retry behaviour in line with the RFC4486
   [RFC4486] behaviour for "Administrative Shutdown" (sec 4.0)."

This means that new cease subtype defined here would be effectively
replacing subcode 2 of cease msg as defined by RFC4486 (when string to be
send is configured). Perhaps text in the draft could state it explicitely.

Regards,
R.

On Nov 17, 2016 6:08 AM, "Susan Hares"  wrote:

> This begins a 2 week WG Adoption call for draft-snijders-idr-shutdown
> (11/16/2016 to 11/30/2016).   The discussion should consider whether this
> is useful to operators and technical issues.
>
>
>
>
>
> Sue
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
>

--001a1144d62a2b919e0541750c7c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


I support adoption of this draft.


One suggestion for text clarification.


The draft says:


" It is RECOMMENDED that a BGP speaker receiving a Shut=
down

=C2=A0=C2=A0 Communication observe retry behaviour in line with the RFC4486=


=C2=A0=C2=A0 [RFC4486] behaviour for "Administrative Shutdown" (s=
ec 4.0)."


This means that new cease subtype defined here would be effe=
ctively replacing subcode 2 of cease msg as defined by RFC4486 (when string=
 to be send is configured). Perhaps text in the draft could state it explic=
itely.


Regards,

R.



On Nov 17, 2016 6=
:08 AM, "Susan Hares" <shares@ndzh.com> wrote:
T=
his begins a 2 week WG Adoption call for draft-snijders-idr-shutdown (11/16=
/2016 to 11/30/2016). =C2=A0=C2=A0The discussion should consider whether th=
is is useful to operators and technical issues. 
=C2=A0
=C2=A0=

Sue 

___=
____________________________________________

Idr mailing list

Idr@ietf.org

https://www.ietf.org/mailman/listinfo/idr




--001a1144d62a2b919e0541750c7c--


From nobody Wed Nov 16 17:25:01 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F5101293FD; Wed, 16 Nov 2016 17:25:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.432
X-Spam-Level: 
X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_SOFTFAIL=0.665] 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 7UU7OyAfPhfM; Wed, 16 Nov 2016 17:24:46 -0800 (PST)
Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (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 6DEC71295F3; Wed, 16 Nov 2016 17:24:35 -0800 (PST)
Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1c7BRJ-00052D-5n (job@us.ntt.net); Thu, 17 Nov 2016 01:24:34 +0000
Date: Thu, 17 Nov 2016 10:24:28 +0900
From: Job Snijders 
To: Jeffrey Haas 
Message-ID: <20161117012428.GG22270@dhcp-9341.meeting.ietf.org>
References: <20161116061556.GG1073@dhcp-9341.meeting.ietf.org> <20161116105535.GW79185@Space.Net> <1479295774707.77855@dacor.de> <20161116113849.udbrfvdhaj3be7nx@bongo.bofh.it> <20161116130110.GK1073@dhcp-9341.meeting.ietf.org> <20161117011945.GA6217@pfrc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20161117011945.GA6217@pfrc.org>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.7.1 (2016-10-04)
Archived-At: 
Cc: "idr@ietf.org" , "grow@ietf.org" , Marco d'Itri 
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 17 Nov 2016 01:25:00 -0000

On Wed, Nov 16, 2016 at 08:19:45PM -0500, Jeffrey Haas wrote:
> On Wed, Nov 16, 2016 at 10:01:10PM +0900, Job Snijders wrote:
> > Unless some implementors make significant arguments along the lines of
> > "we CANNOT implement this Shutdown Communication functionality, SOLELY
> > because of utf8 and lack of representation filtering capabilities", i'd
> > water down the utf8 requirement to 7bit ascii (because in the end its
> > better to have 'something' than nothing). Another line of argumentation
> > against utf8 would be if major security concerns are articulated.
> 
> In general, IESG comments will push any user-displayable string to UTF-8
> anyway, so I wouldn't stress over this being the requirement.  It's pretty
> much an IETF-wide expectation these days.
> 
> I think your doc is the first one that I've seen bothering to cite the
> unicode considerations documents.  Ideally that'd be a pointer to somewhere
> else in a single ref, but I don't think I've seen such an IETF document.

I took inspiration from syslog's security considerations https://tools.ietf.org/html/rfc5424

> > I hope to capture in the draft that an implementation can choose which
> > characters of the Shutdown Communication they represent in the syslog or
> > 'show bgp neighbor xxx' output. For instance, I'd recommend to squash
> > all newline/newpage/newfeed/newparagraph style chars and make sure that
> > the Communication is represented on a single line. I don't have the
> > proper words for the draft to express that (yet).
> 
> Again, perhaps too much to tackle in this document.
> 
> A portion of what you're interested in is covered under the control
> characters section:
> 
> https://en.wikipedia.org/wiki/Unicode_control_characters
> 
> If you try to get too normative you're going to spend a huge amount of text
> trying to close all of the holes.

Yes, and UNICODE is somewhat of a moving target, a wall of text won't be
effective.

> > Also I don't mind if an implementation consciously chooses to only
> > represent 7bit ASCII. That should be an implementor decision. They can
> > upgrade later. In theory the protocol spec shouldn't be delayed or
> > obstructed due to an implementor's current internationalisation
> > capabilities (which can change over time).
> 
> ASCII is conformant UTF-8, which is one of the nice properties about that
> encoding.  What tends to be problematic in many people's implementations is
> emitting Latin-1 or similar encodings that are 8-bit as if they're valid
> UTF-8, which they're not.
> 
> The better question is what the general expected behavior is when things
> cannot be displayed.  Some of that will depend on the i18n capabilities of
> someone's implementation.

I'd just skip over them.

grã©gory -> grgory

Kind regards,

Job


From nobody Wed Nov 16 17:33:49 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C73881294EC; Wed, 16 Nov 2016 17:33:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.399
X-Spam-Level: 
X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, 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 TEBljad5Czvc; Wed, 16 Nov 2016 17:33:46 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 9BD0112961E; Wed, 16 Nov 2016 17:33:44 -0800 (PST)
Received: by slice.pfrc.org (Postfix, from userid 1001) id E1AA21E369; Wed, 16 Nov 2016 20:36:40 -0500 (EST)
Date: Wed, 16 Nov 2016 20:36:40 -0500
From: Jeffrey Haas 
To: Job Snijders 
Message-ID: <20161117013640.GB6217@pfrc.org>
References: <20161116061556.GG1073@dhcp-9341.meeting.ietf.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20161116061556.GG1073@dhcp-9341.meeting.ietf.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: 
Cc: idr@ietf.org, grow@ietf.org
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 17 Nov 2016 01:33:48 -0000

On Wed, Nov 16, 2016 at 03:15:56PM +0900, Job Snijders wrote:
> Some might wonder, why "Cease"?
> 
> The beauty of using a new Cease subcode, is that the NOTIFICATION
> message type already allows extra data to be attached, so for most
> implementations it will be very simple to bolt what is specified in
> draft-snijders-idr-shutdown-00 on top of their existing code. In some
> cases we are looking at just a handful of lines.

As I commented elsewhere, changing subcodes ends up being painful from a
conformance standpoint.  I would honestly not recommend a new subcode.

BGP implementations usually deal with the notification data section that may
not have information in a format they recognize by simply ignoring or making
the contents available in something like hexadecimal prints.

What I would suggest is simply take the RFC 4486 subcodes that don't already
return additional information (e.g. max prefix) and simply add this shutdown
reason as the data.  From the list of code points, here's the ones I would
suggest updating:

:         2        Administrative Shutdown
:         3        Peer De-configured
:         6        Other Configuration Change

Ones that possibly shouldn't be changed:


:         1        Maximum Number of Prefixes Reached

This one is fully specified.

:         4        Administrative Reset

I'm not sure returning something here makes sense.  This seems to be more
the "clear bgp neighbor" case.  Unless you think adding information about
why the user did the clear makes sense.

:         5        Connection Rejected

Here's where things get a little odd.  You should get one of the other
subcodes on clear.  If you're preventing it from coming back up, this code
may be returned.  This means that even if you're storing the last received
string, it might be overwritten by this.

:         7        Connection Collision Resolution
:         8        Out of Resources

I suspect these shouldn't return anything.

> Previous attempts such as draft-ietf-idr-advisory-00 and
> draft-ietf-idr-operational-message-00 failed to deliver for various
> reasons (feature creep comes to mind), therefore we are trying to do
> this as simple as possible. 

IMO, they more likely failed as low priority features that couldn't get past
product managers.

If, especially the existing code points are re-used and don't alter existing
implementation conformance, I suspect this draft would be closer to a
trivial modification that has a better chance of getting shipped quickly.

I also have to ask about:

:    As of today these vendors have produced an implementation of the
:    Shutdown Communication:
: 
:    o  ExaBGP

And exactly which code point did you squat on to do the prototype? ;-)

(I'm not exactly concerned about this since it's local in impact but you'd
think after the discussions this week...)

-- Jeff


From nobody Wed Nov 16 17:35:27 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29BFE1295C8; Wed, 16 Nov 2016 17:35:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.399
X-Spam-Level: 
X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, 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 JQmVFil5Yxn8; Wed, 16 Nov 2016 17:35:22 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id E496B1294DC; Wed, 16 Nov 2016 17:35:21 -0800 (PST)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 4C0181E369; Wed, 16 Nov 2016 20:38:18 -0500 (EST)
Date: Wed, 16 Nov 2016 20:38:18 -0500
From: Jeffrey Haas 
To: Job Snijders 
Message-ID: <20161117013818.GC6217@pfrc.org>
References: <20161116061556.GG1073@dhcp-9341.meeting.ietf.org> <20161116105535.GW79185@Space.Net> <1479295774707.77855@dacor.de> <20161116113849.udbrfvdhaj3be7nx@bongo.bofh.it> <20161116130110.GK1073@dhcp-9341.meeting.ietf.org> <20161117011945.GA6217@pfrc.org> <20161117012428.GG22270@dhcp-9341.meeting.ietf.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20161117012428.GG22270@dhcp-9341.meeting.ietf.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: 
Cc: "idr@ietf.org" , "grow@ietf.org" , Marco d'Itri 
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 17 Nov 2016 01:35:23 -0000

On Thu, Nov 17, 2016 at 10:24:28AM +0900, Job Snijders wrote:
> On Wed, Nov 16, 2016 at 08:19:45PM -0500, Jeffrey Haas wrote:
> > I think your doc is the first one that I've seen bothering to cite the
> > unicode considerations documents.  Ideally that'd be a pointer to somewhere
> > else in a single ref, but I don't think I've seen such an IETF document.
> 
> I took inspiration from syslog's security considerations https://tools.ietf.org/html/rfc5424

IMO, just refer to that and delete a bunch of text from yours. :-)

-- Jeff


From nobody Wed Nov 16 17:35:30 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBA1B1294DC for ; Wed, 16 Nov 2016 17:35:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.432
X-Spam-Level: 
X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_SOFTFAIL=0.665] 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 8mmzpiyv2omq for ; Wed, 16 Nov 2016 17:35:23 -0800 (PST)
Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (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 0F79D1293FD for ; Wed, 16 Nov 2016 17:35:23 -0800 (PST)
Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1c7Bbm-00065r-12 (job@us.ntt.net); Thu, 17 Nov 2016 01:35:22 +0000
Date: Thu, 17 Nov 2016 10:35:17 +0900
From: Job Snijders 
To: Robert Raszuk 
Message-ID: <20161117013517.GH22270@dhcp-9341.meeting.ietf.org>
References: <013f01d2404d$3dfff610$b9ffe230$@ndzh.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.7.1 (2016-10-04)
Archived-At: 
Cc: idr wg , Susan Hares 
Subject: Re: [Idr] WG Adoption call for draft-snijders-idr-shutdown (11/16 to 11/30)
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, 17 Nov 2016 01:35:24 -0000

Hi Robert,

On Thu, Nov 17, 2016 at 02:24:13AM +0100, Robert Raszuk wrote:
> I support adoption of this draft.
> 
> One suggestion for text clarification.
> 
> The draft says:
> 
> " It is RECOMMENDED that a BGP speaker receiving a Shutdown
>    Communication observe retry behaviour in line with the RFC4486
>    [RFC4486] behaviour for "Administrative Shutdown" (sec 4.0)."
> 
> This means that new cease subtype defined here would be effectively
> replacing subcode 2 of cease msg as defined by RFC4486 (when string to
> be send is configured). Perhaps text in the draft could state it
> explicitely.

Thanks for the feedback.

Kind regards,

Job


From nobody Wed Nov 16 17:39:37 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A69301295C8 for ; Wed, 16 Nov 2016 17:39:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.399
X-Spam-Level: 
X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, 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 mnw-yJPHBmaI for ; Wed, 16 Nov 2016 17:39:35 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id AD9F11294CC for ; Wed, 16 Nov 2016 17:39:35 -0800 (PST)
Received: by slice.pfrc.org (Postfix, from userid 1001) id F051F1E369; Wed, 16 Nov 2016 20:42:31 -0500 (EST)
Date: Wed, 16 Nov 2016 20:42:31 -0500
From: Jeffrey Haas 
To: Susan Hares 
Message-ID: <20161117014231.GD6217@pfrc.org>
References: <013f01d2404d$3dfff610$b9ffe230$@ndzh.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <013f01d2404d$3dfff610$b9ffe230$@ndzh.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: 
Cc: 'idr wg' 
Subject: Re: [Idr] WG Adoption call for draft-snijders-idr-shutdown (11/16 to 11/30)
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, 17 Nov 2016 01:39:37 -0000

On Wed, Nov 16, 2016 at 04:06:02PM -0500, Susan Hares wrote:
> This begins a 2 week WG Adoption call for draft-snijders-idr-shutdown
> (11/16/2016 to 11/30/2016).   The discussion should consider whether this is
> useful to operators and technical issues. 

I'm in favor of adoption.

I'd also suggest the chairs consider if prior work on BGP Advisory Message
should be de-chartered.

FWIW, the display issues are exactly the same between Advisory and this
proposal.

-- Jeff


From nobody Wed Nov 16 17:42:26 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4C31129631; Wed, 16 Nov 2016 17:42:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.432
X-Spam-Level: 
X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_SOFTFAIL=0.665] 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 hEPrvhL3OR0n; Wed, 16 Nov 2016 17:42:21 -0800 (PST)
Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (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 25C2B1295C8; Wed, 16 Nov 2016 17:42:20 -0800 (PST)
Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1c7BiV-0006xp-2X (job@us.ntt.net); Thu, 17 Nov 2016 01:42:19 +0000
Date: Thu, 17 Nov 2016 10:42:15 +0900
From: Job Snijders 
To: Jeffrey Haas 
Message-ID: <20161117014215.GI22270@dhcp-9341.meeting.ietf.org>
References: <20161116061556.GG1073@dhcp-9341.meeting.ietf.org> <20161117013640.GB6217@pfrc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20161117013640.GB6217@pfrc.org>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.7.1 (2016-10-04)
Archived-At: 
Cc: idr@ietf.org, grow@ietf.org
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 17 Nov 2016 01:42:22 -0000

On Wed, Nov 16, 2016 at 08:36:40PM -0500, Jeffrey Haas wrote:
> On Wed, Nov 16, 2016 at 03:15:56PM +0900, Job Snijders wrote:
> > Some might wonder, why "Cease"?
> > 
> > The beauty of using a new Cease subcode, is that the NOTIFICATION
> > message type already allows extra data to be attached, so for most
> > implementations it will be very simple to bolt what is specified in
> > draft-snijders-idr-shutdown-00 on top of their existing code. In some
> > cases we are looking at just a handful of lines.
> 
> As I commented elsewhere, changing subcodes ends up being painful from a
> conformance standpoint.  I would honestly not recommend a new subcode.

I don't follow, it seems you recommend to not change the behaviour of an
existing subcode (conformance), but you also recommend against getting a
new subcode?  Can you clarify?


From nobody Wed Nov 16 17:44:06 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64BA6129516; Wed, 16 Nov 2016 17:44:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.399
X-Spam-Level: 
X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, 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 2Lif797LnrGn; Wed, 16 Nov 2016 17:44:05 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 82FB41294DC; Wed, 16 Nov 2016 17:44:05 -0800 (PST)
Received: by slice.pfrc.org (Postfix, from userid 1001) id B7AD01E369; Wed, 16 Nov 2016 20:47:01 -0500 (EST)
Date: Wed, 16 Nov 2016 20:47:01 -0500
From: Jeffrey Haas 
To: Job Snijders 
Message-ID: <20161117014701.GE6217@pfrc.org>
References: <20161116061556.GG1073@dhcp-9341.meeting.ietf.org> <20161117013640.GB6217@pfrc.org> <20161117014215.GI22270@dhcp-9341.meeting.ietf.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20161117014215.GI22270@dhcp-9341.meeting.ietf.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: 
Cc: idr@ietf.org, grow@ietf.org
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 17 Nov 2016 01:44:06 -0000

On Thu, Nov 17, 2016 at 10:42:15AM +0900, Job Snijders wrote:
> On Wed, Nov 16, 2016 at 08:36:40PM -0500, Jeffrey Haas wrote:
> > On Wed, Nov 16, 2016 at 03:15:56PM +0900, Job Snijders wrote:
> > > Some might wonder, why "Cease"?
> > > 
> > > The beauty of using a new Cease subcode, is that the NOTIFICATION
> > > message type already allows extra data to be attached, so for most
> > > implementations it will be very simple to bolt what is specified in
> > > draft-snijders-idr-shutdown-00 on top of their existing code. In some
> > > cases we are looking at just a handful of lines.
> > 
> > As I commented elsewhere, changing subcodes ends up being painful from a
> > conformance standpoint.  I would honestly not recommend a new subcode.
> 
> I don't follow, it seems you recommend to not change the behaviour of an
> existing subcode (conformance), but you also recommend against getting a
> new subcode?  Can you clarify?

No new subcodes.
Add the text to the NOTIFICATION Data section of existing subcodes, when it
makes sense and that Data section isn't otherwise specified.

-- Jeff


From nobody Wed Nov 16 17:46:24 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04F821294EC; Wed, 16 Nov 2016 17:46:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.432
X-Spam-Level: 
X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_SOFTFAIL=0.665] 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 zRFVNlCX9sud; Wed, 16 Nov 2016 17:46:18 -0800 (PST)
Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (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 1E6BE129604; Wed, 16 Nov 2016 17:46:18 -0800 (PST)
Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1c7BmK-0007NQ-Vr (job@us.ntt.net); Thu, 17 Nov 2016 01:46:17 +0000
Date: Thu, 17 Nov 2016 10:46:13 +0900
From: Job Snijders 
To: Jeffrey Haas 
Message-ID: <20161117014613.GJ22270@dhcp-9341.meeting.ietf.org>
References: <20161116061556.GG1073@dhcp-9341.meeting.ietf.org> <20161117013640.GB6217@pfrc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20161117013640.GB6217@pfrc.org>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.7.1 (2016-10-04)
Archived-At: 
Cc: idr@ietf.org, grow@ietf.org
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 17 Nov 2016 01:46:19 -0000

On Wed, Nov 16, 2016 at 08:36:40PM -0500, Jeffrey Haas wrote:
> I also have to ask about:
> 
> :    As of today these vendors have produced an implementation of the
> :    Shutdown Communication:
> : 
> :    o  ExaBGP
> 
> And exactly which code point did you squat on to do the prototype? ;-)
> 
> (I'm not exactly concerned about this since it's local in impact but
> you'd think after the discussions this week...)

I learned the lesson: as you can see in the draft the codepoint is
referenced as "TBD". :-) 

If you want to do interop testing ping me offlist and we'll negotiate a
subcode for our locally confined experiment.

Kind regards,

Job


From nobody Wed Nov 16 17:57:40 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0D581295D8 for ; Wed, 16 Nov 2016 17:57:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.432
X-Spam-Level: 
X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_SOFTFAIL=0.665] 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 DyXO17N5v6E5 for ; Wed, 16 Nov 2016 17:57:36 -0800 (PST)
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 C104E1294B5 for ; Wed, 16 Nov 2016 17:57:36 -0800 (PST)
Received: by mail3.mlpsca01.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1c7BxH-000FfY-QJ (job@us.ntt.net); Thu, 17 Nov 2016 01:57:36 +0000
Date: Thu, 17 Nov 2016 10:57:31 +0900
From: Job Snijders 
To: Jeffrey Haas 
Message-ID: <20161117015731.GK22270@dhcp-9341.meeting.ietf.org>
References: <20161116061556.GG1073@dhcp-9341.meeting.ietf.org> <20161117013640.GB6217@pfrc.org> <20161117014215.GI22270@dhcp-9341.meeting.ietf.org> <20161117014701.GE6217@pfrc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20161117014701.GE6217@pfrc.org>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.7.1 (2016-10-04)
Archived-At: 
Cc: idr@ietf.org
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 17 Nov 2016 01:57:39 -0000

(snipped grow@)

On Wed, Nov 16, 2016 at 08:47:01PM -0500, Jeffrey Haas wrote:
> On Thu, Nov 17, 2016 at 10:42:15AM +0900, Job Snijders wrote:
> > On Wed, Nov 16, 2016 at 08:36:40PM -0500, Jeffrey Haas wrote:
> > > On Wed, Nov 16, 2016 at 03:15:56PM +0900, Job Snijders wrote:
> > > > Some might wonder, why "Cease"?
> > > > 
> > > > The beauty of using a new Cease subcode, is that the NOTIFICATION
> > > > message type already allows extra data to be attached, so for most
> > > > implementations it will be very simple to bolt what is specified in
> > > > draft-snijders-idr-shutdown-00 on top of their existing code. In some
> > > > cases we are looking at just a handful of lines.
> > > 
> > > As I commented elsewhere, changing subcodes ends up being painful from a
> > > conformance standpoint.  I would honestly not recommend a new subcode.
> > 
> > I don't follow, it seems you recommend to not change the behaviour of an
> > existing subcode (conformance), but you also recommend against getting a
> > new subcode?  Can you clarify?
> 
> No new subcodes.
> Add the text to the NOTIFICATION Data section of existing subcodes, when it
> makes sense and that Data section isn't otherwise specified.

What will existing, deployed implementations do if they get trailing
data after a subcode 2? Can you comment on Juniper JunOS?

Equally:

What will existing, deployed implementations do if they encounter a
cease subcode they don't recognise? ExaBGP would emit 'unknow reason'.

Kind regards,

Job


From nobody Wed Nov 16 18:23:14 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 731BB1294B5 for ; Wed, 16 Nov 2016 18:23:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.399
X-Spam-Level: 
X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, 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 lOYSlpl8KXLO for ; Wed, 16 Nov 2016 18:23:00 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id BE4931293D6 for ; Wed, 16 Nov 2016 18:23:00 -0800 (PST)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 07E591E369; Wed, 16 Nov 2016 21:25:56 -0500 (EST)
Date: Wed, 16 Nov 2016 21:25:56 -0500
From: Jeffrey Haas 
To: Job Snijders 
Message-ID: <20161117022556.GA10478@pfrc.org>
References: <20161116061556.GG1073@dhcp-9341.meeting.ietf.org> <20161117013640.GB6217@pfrc.org> <20161117014215.GI22270@dhcp-9341.meeting.ietf.org> <20161117014701.GE6217@pfrc.org> <20161117015731.GK22270@dhcp-9341.meeting.ietf.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20161117015731.GK22270@dhcp-9341.meeting.ietf.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: 
Cc: idr@ietf.org
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 17 Nov 2016 02:23:02 -0000

On Thu, Nov 17, 2016 at 10:57:31AM +0900, Job Snijders wrote:
> On Wed, Nov 16, 2016 at 08:47:01PM -0500, Jeffrey Haas wrote:
> > No new subcodes.
> > Add the text to the NOTIFICATION Data section of existing subcodes, when it
> > makes sense and that Data section isn't otherwise specified.
> 
> What will existing, deployed implementations do if they get trailing
> data after a subcode 2? Can you comment on Juniper JunOS?

In a small number of cases where it understands the contents, e.g. max
prefix, hard reset (long lived graceful restart), unsupported capability, it
will print something useful.  Otherwise, it's Data: .

This behavior is generally useful since it means specs like this can happen
and the contents can happen and you can still get some visibility.  I
heartily recommend the practice.

> 
> Equally:
> 
> What will existing, deployed implementations do if they encounter a
> cease subcode they don't recognise? ExaBGP would emit 'unknow reason'.

Same, displaying the subcode and any Data.

Anyway, my general point is the subcodes have existing semantics.  Use those
as much as makes sense.

-- Jeff


From nobody Wed Nov 16 19:03:42 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 370CD12957B for ; Wed, 16 Nov 2016 19:03:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.415
X-Spam-Level: 
X-Spam-Status: No, score=-3.415 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, 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 hAqv5Fbs9h0c for ; Wed, 16 Nov 2016 19:03:34 -0800 (PST)
Received: from relais-inet.orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89CA9129559 for ; Wed, 16 Nov 2016 19:03:34 -0800 (PST)
Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 442121201DC; Thu, 17 Nov 2016 04:03:33 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.17]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id 20623C0057; Thu, 17 Nov 2016 04:03:33 +0100 (CET)
Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM24.corporate.adroot.infra.ftgroup ([fe80::a1e6:3e6a:1f68:5f7e%18]) with mapi id 14.03.0319.002; Thu, 17 Nov 2016 04:03:32 +0100
From: 
To: Susan Hares , 'idr wg' , Robert Raszuk 
Thread-Topic: [Idr] WG Adoption call for draft-snijders-idr-shutdown (11/16 to	11/30)
Thread-Index: AdJATQXKePgAmF1nTgStU0J//yEVUAAMZM4Q
Date: Thu, 17 Nov 2016 03:03:32 +0000
Message-ID: <29352_1479351813_582D1E05_29352_19421_1_9E32478DFA9976438E7A22F69B08FF921DBB17E3@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
References: <013f01d2404d$3dfff610$b9ffe230$@ndzh.com>
In-Reply-To: <013f01d2404d$3dfff610$b9ffe230$@ndzh.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.168.234.1]
Content-Type: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF921DBB17E3OPEXCLILMA4corp_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Idr] WG Adoption call for draft-snijders-idr-shutdown (11/16 to	11/30)
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, 17 Nov 2016 03:03:41 -0000

--_000_9E32478DFA9976438E7A22F69B08FF921DBB17E3OPEXCLILMA4corp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I support it as conveying informations between BGP Speakers is useful but t=
his is a sort of subset of a previous operational message work on BGP that =
has never been achieved. Was it just because of lack of implementations ? I=
 do not have history on this.
I would like to avoid falling into the same issues.


From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Thursday, November 17, 2016 06:06
To: 'idr wg'
Subject: [Idr] WG Adoption call for draft-snijders-idr-shutdown (11/16 to 1=
1/30)

This begins a 2 week WG Adoption call for draft-snijders-idr-shutdown (11/1=
6/2016 to 11/30/2016).   The discussion should consider whether this is use=
ful to operators and technical issues.


Sue

___________________________________________________________________________=
______________________________________________

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

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


--_000_9E32478DFA9976438E7A22F69B08FF921DBB17E3OPEXCLILMA4corp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











I support it as convey=
ing informations between BGP Speakers is useful but this is a sort of subse=
t of a previous operational message work on BGP that has never been achieve=
d. Was it just because of lack of implementations
 ? I do not have history on this.


I would like to avoid =
falling into the same issues.


 


 






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

Sent: Thursday, November 17, 2016 06:06

To: 'idr wg'

Subject: [Idr] WG Adoption call for draft-snijders-idr-shutdown (11/=
16 to 11/30)






 


This begins a 2 week WG Adoption call for draft-snij=
ders-idr-shutdown (11/16/2016 to 11/30/2016).   The discussion sh=
ould consider whether this is useful to operators and technical issues.



 


 


Sue 




______________________________________________________________________=
___________________________________________________

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

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




--_000_9E32478DFA9976438E7A22F69B08FF921DBB17E3OPEXCLILMA4corp_--


From nobody Wed Nov 16 19:06:41 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88E83129855; Wed, 16 Nov 2016 19:06:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.432
X-Spam-Level: 
X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_SOFTFAIL=0.665] 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 hj_-M-XEWJy9; Wed, 16 Nov 2016 19:06:36 -0800 (PST)
Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (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 8AF6B129478; Wed, 16 Nov 2016 19:06:36 -0800 (PST)
Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1c7D23-000FXw-93 (job@us.ntt.net); Thu, 17 Nov 2016 03:06:36 +0000
Date: Thu, 17 Nov 2016 12:06:32 +0900
From: Job Snijders 
To: Jeffrey Haas 
Message-ID: <20161117030632.GO22270@dhcp-9341.meeting.ietf.org>
References: <20161116061556.GG1073@dhcp-9341.meeting.ietf.org> <20161117013640.GB6217@pfrc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20161117013640.GB6217@pfrc.org>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.7.1 (2016-10-04)
Archived-At: 
Cc: idr@ietf.org, grow@ietf.org
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 17 Nov 2016 03:06:38 -0000

On Wed, Nov 16, 2016 at 08:36:40PM -0500, Jeffrey Haas wrote:
> On Wed, Nov 16, 2016 at 03:15:56PM +0900, Job Snijders wrote:
> > Some might wonder, why "Cease"?
> > 
> > The beauty of using a new Cease subcode, is that the NOTIFICATION
> > message type already allows extra data to be attached, so for most
> > implementations it will be very simple to bolt what is specified in
> > draft-snijders-idr-shutdown-00 on top of their existing code. In some
> > cases we are looking at just a handful of lines.
> 
> As I commented elsewhere, changing subcodes ends up being painful from
> a conformance standpoint.  I would honestly not recommend a new
> subcode.
> 
> BGP implementations usually deal with the notification data section
> that may not have information in a format they recognize by simply
> ignoring or making the contents available in something like
> hexadecimal prints.
> 
> What I would suggest is simply take the RFC 4486 subcodes that don't
> already return additional information (e.g. max prefix) and simply add
> this shutdown reason as the data.  From the list of code points,
> here's the ones I would suggest updating:
> 
> :         2        Administrative Shutdown
> :         3        Peer De-configured
> :         6        Other Configuration Change

> 

I checked with Jakob, according to him IOS XR won't choke on a cease
subcode 2 if there is trailing data.

The UI or configuration concept of some operating systems might have
trouble properly sending a 'cease "Peer De-configured"' with trailing
data, so I'd skip that one for now. Same applies for 'other
configuration change'.

>From the looks of it, we can retrofit 'shutdown' under subcode 2 and
forgo requesting a new cease subcode. I think I'd leave 3 and 6 as they
are.

Does anyone object to using subcode 2 for draft-snijders-idr-shutdown-01?

The length of the NOTIFICATION will signal whether there is a shutdown
communication or not.

Kind regards,

Job


From nobody Wed Nov 16 19:13:56 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F243129544 for ; Wed, 16 Nov 2016 19:13:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level: 
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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 bnbCvLaJ1ZUe for ; Wed, 16 Nov 2016 19:13:53 -0800 (PST)
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 EF7D51294D8 for ; Wed, 16 Nov 2016 19:13:52 -0800 (PST)
Received: by mail-it0-x231.google.com with SMTP id c20so250550390itb.0 for ; Wed, 16 Nov 2016 19:13:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=1XB2NXbBD8oDTcDGDu+VTjIFFbDO5JxvPEbnlNY/AtU=; b=F5tiHZOVFLkmpzS1jY/mtbBqhKtdYqpq8FzSC869UMnlGrJsCaMdNeEWhn1hy9ltZY gJz3Iha7D+nFkCe3BHvU62KGWUU4jISWNi+zZiQeTAN07dpqUEy6/9U6hAW7tHD8HK2V KgmKuuHYlWtaq8WV54sbuXQRjH1HUsFYyeB6r3n1FVdh7R8LL94f17c0aFOWToICN6qL uAX3iKTtHx3/wFVEullV+LNCmMNtmyVj3qKKBXGYxQt6YcJ/9nllzzs2IfXuSGrh6h28 wNdI2pJ4whXdLTwJjwdKd9JJIE2a5XgXxzB3T1xBIuwMzm7D9s155mwfXjha5XMe7rz+ BFEA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=1XB2NXbBD8oDTcDGDu+VTjIFFbDO5JxvPEbnlNY/AtU=; b=HUsGysewBucx8gpV8nHVgAwjETIACgHprtEE7lmbkh0tsEyzcyHQlSQ/3ZvxVqx1yj Cks4QuduatQAndUbvAFhfgAonWUI8gQWQ0ei3va1ySWmdsId8U1U+QVfBsL3yBpf+4ZR ZtNKV6fZbI/lKwbnC2t+gzl6FK6jVupS9e3SLxnLQrV6fJIf+PM9gpj97uaSxEFhTZu8 9GwWp6OQk5w5tDGExLscdai9KtRbOaRzj6Jgs+qeGNHI8nIdm6pVrfWCe3FK+bwOXv/L W34ajT+M6apnx0Yz9lmIR6IRnDCTm8G9+D+8DVS/oA+Jh1mFHA51suH4czyvY7ajdehM RpgQ==
X-Gm-Message-State: ABUngvdeYbC1fgwhzC6XqNHhIq/Dau55X4TELEQ0Ns9v4ZbMo/7RonjQ46ZJSyh/y0QtOrtiIWq6AVxjgheCcA==
X-Received: by 10.36.224.200 with SMTP id c191mr1247986ith.118.1479352432218;  Wed, 16 Nov 2016 19:13:52 -0800 (PST)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.107.1.16 with HTTP; Wed, 16 Nov 2016 19:13:51 -0800 (PST)
Received: by 10.107.1.16 with HTTP; Wed, 16 Nov 2016 19:13:51 -0800 (PST)
In-Reply-To: <29352_1479351813_582D1E05_29352_19421_1_9E32478DFA9976438E7A22F69B08FF921DBB17E3@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
References: <013f01d2404d$3dfff610$b9ffe230$@ndzh.com> <29352_1479351813_582D1E05_29352_19421_1_9E32478DFA9976438E7A22F69B08FF921DBB17E3@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
From: Robert Raszuk 
Date: Thu, 17 Nov 2016 04:13:51 +0100
X-Google-Sender-Auth: YZtoHUA5X6zvRYyLgEbh0d-5igA
Message-ID: 
To: "" 
Content-Type: multipart/alternative; boundary=94eb2c19dc10385a170541769428
Archived-At: 
Cc: idr wg , Susan Hares 
Subject: Re: [Idr] WG Adoption call for draft-snijders-idr-shutdown (11/16 to 11/30)
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, 17 Nov 2016 03:13:54 -0000

--94eb2c19dc10385a170541769428
Content-Type: text/plain; charset=UTF-8

Yes Stephan,

The previous work on Operational Msg and Advisory Msg was an IDR WG, but
vendors did not implement it hence it expired.

Here we are dealing with "inline" tiny subset of it, what essentially may
be much easier to implement.

Deployment wise I am not sure how many implementations will crash receiving
it though if current subcodes of cease will get "extended" ;)

That is why new subcode seems cleaner at least to me here to achieve this
form of additional info.

Many thx
R.

--94eb2c19dc10385a170541769428
Content-Type: text/html; charset=UTF-8


Yes Stephan,


The previous work on Operational Msg and Advisory Msg was an IDR WG, but vendors did not implement it hence it expired.


Here we are dealing with "inline" tiny subset of it, what essentially may be much easier to implement. 


Deployment wise I am not sure how many implementations will crash receiving it though if current subcodes of cease will get "extended" ;)


That is why new subcode seems cleaner at least to me here to achieve this form of additional info.


Many thx

R.


--94eb2c19dc10385a170541769428--


From nobody Wed Nov 16 19:19:06 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 685AA12956F for ; Wed, 16 Nov 2016 19:19:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.415
X-Spam-Level: 
X-Spam-Status: No, score=-2.415 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, 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 TpHcAvjy81ey for ; Wed, 16 Nov 2016 19:19:01 -0800 (PST)
Received: from relais-inet.orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BE111294D8 for ; Wed, 16 Nov 2016 19:19:01 -0800 (PST)
Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id 04F6F1201EF; Thu, 17 Nov 2016 04:19:00 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.66]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id D92A04004C; Thu, 17 Nov 2016 04:18:59 +0100 (CET)
Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILMA1.corporate.adroot.infra.ftgroup ([fe80::95e2:eb4b:3053:fabf%19]) with mapi id 14.03.0319.002; Thu, 17 Nov 2016 04:18:59 +0100
From: 
To: Robert Raszuk 
Thread-Topic: [Idr] WG Adoption call for draft-snijders-idr-shutdown (11/16 to 11/30)
Thread-Index: AQHSQICg3rx3bZwSOE+R2WDHFDxe2qDcgTFw
Date: Thu, 17 Nov 2016 03:18:58 +0000
Message-ID: <16146_1479352739_582D21A3_16146_2541_1_9E32478DFA9976438E7A22F69B08FF921DBB18F0@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
References: <013f01d2404d$3dfff610$b9ffe230$@ndzh.com> <29352_1479351813_582D1E05_29352_19421_1_9E32478DFA9976438E7A22F69B08FF921DBB17E3@OPEXCLILMA4.corporate.adroot.infra.ftgroup> 
In-Reply-To: 
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.168.234.1]
Content-Type: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF921DBB18F0OPEXCLILMA4corp_"
MIME-Version: 1.0
Archived-At: 
Cc: idr wg , Susan Hares 
Subject: Re: [Idr] WG Adoption call for draft-snijders-idr-shutdown (11/16 to 11/30)
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, 17 Nov 2016 03:19:03 -0000

--_000_9E32478DFA9976438E7A22F69B08FF921DBB18F0OPEXCLILMA4corp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

U291bmRzIGdvb2QgdG8gbWUsIGV2ZW4gaWYgaW4gdGVybSBvZiBpbXBsZW1lbnRhdGlvbnMgSSB3
b3VsZCBoYXZlIHByZWZlcnJlZCBhIG1vcmUgZmxleGlibGUgbWVjaGFuaXNtLiBJIHRob3VnaHQg
dGhhdCBjdXN0b21lcnMgd2VyZSBraW5nIOKYuiB0aGF0IGRvZXMgIG5vdCBsb29rIHRvIGJlIHRy
dWUg4oCmDQoNCkFueXdheSwgdGhpcyBpcyB1c2VmdWwuIFNvIEkgc3VwcG9ydCB0aGUgd29yay4N
Cg0KRnJvbTogcnJhc3p1a0BnbWFpbC5jb20gW21haWx0bzpycmFzenVrQGdtYWlsLmNvbV0gT24g
QmVoYWxmIE9mIFJvYmVydCBSYXN6dWsNClNlbnQ6IFRodXJzZGF5LCBOb3ZlbWJlciAxNywgMjAx
NiAxMjoxNA0KVG86IExJVEtPV1NLSSBTdGVwaGFuZSBPQlMvT0lOSVMNCkNjOiBTdXNhbiBIYXJl
czsgaWRyIHdnDQpTdWJqZWN0OiBSRTogW0lkcl0gV0cgQWRvcHRpb24gY2FsbCBmb3IgZHJhZnQt
c25pamRlcnMtaWRyLXNodXRkb3duICgxMS8xNiB0byAxMS8zMCkNCg0KDQpZZXMgU3RlcGhhbiwN
Cg0KVGhlIHByZXZpb3VzIHdvcmsgb24gT3BlcmF0aW9uYWwgTXNnIGFuZCBBZHZpc29yeSBNc2cg
d2FzIGFuIElEUiBXRywgYnV0IHZlbmRvcnMgZGlkIG5vdCBpbXBsZW1lbnQgaXQgaGVuY2UgaXQg
ZXhwaXJlZC4NCg0KSGVyZSB3ZSBhcmUgZGVhbGluZyB3aXRoICJpbmxpbmUiIHRpbnkgc3Vic2V0
IG9mIGl0LCB3aGF0IGVzc2VudGlhbGx5IG1heSBiZSBtdWNoIGVhc2llciB0byBpbXBsZW1lbnQu
DQoNCkRlcGxveW1lbnQgd2lzZSBJIGFtIG5vdCBzdXJlIGhvdyBtYW55IGltcGxlbWVudGF0aW9u
cyB3aWxsIGNyYXNoIHJlY2VpdmluZyBpdCB0aG91Z2ggaWYgY3VycmVudCBzdWJjb2RlcyBvZiBj
ZWFzZSB3aWxsIGdldCAiZXh0ZW5kZWQiIDspDQoNClRoYXQgaXMgd2h5IG5ldyBzdWJjb2RlIHNl
ZW1zIGNsZWFuZXIgYXQgbGVhc3QgdG8gbWUgaGVyZSB0byBhY2hpZXZlIHRoaXMgZm9ybSBvZiBh
ZGRpdGlvbmFsIGluZm8uDQoNCk1hbnkgdGh4DQpSLg0KCl9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQg
c2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25m
aWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBk
aWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBh
dmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwn
ZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBM
ZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9u
LApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRl
IGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0
cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZv
cm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUg
ZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91
IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2Vu
ZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWls
cyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQg
aGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK

--_000_9E32478DFA9976438E7A22F69B08FF921DBB18F0OPEXCLILMA4corp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K
CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9
DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg
MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl
LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv
Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJn
aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt
ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv
LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy
bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl
LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l
O30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRv
Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFy
Z2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l
dyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpw
ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNv
bG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u
bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2Vj
dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu
MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls
ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi
IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+
PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0
IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk
Pg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj
bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Tb3VuZHMgZ29vZCB0byBtZSwgZXZlbiBpZiBp
biB0ZXJtIG9mIGltcGxlbWVudGF0aW9ucyBJIHdvdWxkIGhhdmUgcHJlZmVycmVkIGEgbW9yZSBm
bGV4aWJsZSBtZWNoYW5pc20uIEkgdGhvdWdodCB0aGF0IGN1c3RvbWVycyB3ZXJlIGtpbmcNCjwv
c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3M7
Y29sb3I6IzFGNDk3RCI+Sjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6
IzFGNDk3RCI+IHRoYXQgZG9lcyAmbmJzcDtub3QgbG9vayB0byBiZSB0cnVlIOKApjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3
RCI+QW55d2F5LCB0aGlzIGlzIHVzZWZ1bC4gU28gSSBzdXBwb3J0IHRoZSB3b3JrLjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3Nw
YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh
aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gcnJhc3p1a0BnbWFpbC5jb20gW21h
aWx0bzpycmFzenVrQGdtYWlsLmNvbV0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+Um9iZXJ0IFJhc3p1
azxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgTm92ZW1iZXIgMTcsIDIwMTYgMTI6MTQ8YnI+
DQo8Yj5Ubzo8L2I+IExJVEtPV1NLSSBTdGVwaGFuZSBPQlMvT0lOSVM8YnI+DQo8Yj5DYzo8L2I+
IFN1c2FuIEhhcmVzOyBpZHIgd2c8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtJZHJdIFdHIEFk
b3B0aW9uIGNhbGwgZm9yIGRyYWZ0LXNuaWpkZXJzLWlkci1zaHV0ZG93biAoMTEvMTYgdG8gMTEv
MzApPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8cD5ZZXMgU3RlcGhhbiw8bzpwPjwvbzpwPjwvcD4NCjxwPlRoZSBwcmV2
aW91cyB3b3JrIG9uIE9wZXJhdGlvbmFsIE1zZyBhbmQgQWR2aXNvcnkgTXNnIHdhcyBhbiBJRFIg
V0csIGJ1dCB2ZW5kb3JzIGRpZCBub3QgaW1wbGVtZW50IGl0IGhlbmNlIGl0IGV4cGlyZWQuPG86
cD48L286cD48L3A+DQo8cD5IZXJlIHdlIGFyZSBkZWFsaW5nIHdpdGggJnF1b3Q7aW5saW5lJnF1
b3Q7IHRpbnkgc3Vic2V0IG9mIGl0LCB3aGF0IGVzc2VudGlhbGx5IG1heSBiZSBtdWNoIGVhc2ll
ciB0byBpbXBsZW1lbnQuDQo8bzpwPjwvbzpwPjwvcD4NCjxwPkRlcGxveW1lbnQgd2lzZSBJIGFt
IG5vdCBzdXJlIGhvdyBtYW55IGltcGxlbWVudGF0aW9ucyB3aWxsIGNyYXNoIHJlY2VpdmluZyBp
dCB0aG91Z2ggaWYgY3VycmVudCBzdWJjb2RlcyBvZiBjZWFzZSB3aWxsIGdldCAmcXVvdDtleHRl
bmRlZCZxdW90OyA7KTxvOnA+PC9vOnA+PC9wPg0KPHA+VGhhdCBpcyB3aHkgbmV3IHN1YmNvZGUg
c2VlbXMgY2xlYW5lciBhdCBsZWFzdCB0byBtZSBoZXJlIHRvIGFjaGlldmUgdGhpcyBmb3JtIG9m
IGFkZGl0aW9uYWwgaW5mby48bzpwPjwvbzpwPjwvcD4NCjxwPk1hbnkgdGh4PGJyPg0KUi48bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPFBSRT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVj
ZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVs
bGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMs
IGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1
IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRl
dXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3Nh
Z2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3Jhbmdl
IGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUs
IGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNo
bWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24g
dGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1
dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJl
Y2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQg
ZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJl
IGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVl
biBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KPC9QUkU+PC9ib2R5
Pg0KPC9odG1sPg0K

--_000_9E32478DFA9976438E7A22F69B08FF921DBB18F0OPEXCLILMA4corp_--


From nobody Wed Nov 16 19:27:59 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90EEA12953C; Wed, 16 Nov 2016 19:27:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level: 
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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 biBgEntj54P3; Wed, 16 Nov 2016 19:27:55 -0800 (PST)
Received: from mail-it0-x241.google.com (mail-it0-x241.google.com [IPv6:2607:f8b0:4001:c0b::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 EB2EE129619; Wed, 16 Nov 2016 19:27:53 -0800 (PST)
Received: by mail-it0-x241.google.com with SMTP id o1so12046557ito.1; Wed, 16 Nov 2016 19:27:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Y1EgJWJ7Y/7zzNfPP6siqgZ0uZEWiVdlZtL5KmT4jVM=; b=LUStjtewPi5KvTaMkDR1Zrpr7vPQ5p+f62ln98b0j08IGNMBEHXLY+Dpv0MO2hJjJv 066da85CAFTCjKNKlyakdumYUBv0LZ9/rhhJtyVejxottTQko2Q1twJKBNJR2px+H5Xi pVrVkdVlug46nq5I4eZ4ehX5cZzABlFCq8kMi6W8tcTTpLog9f9ZiP5ztt2IHgWG6GKe XCwf/tV8FlN2RjHSXJqGdJVxrkzUJISx/9GNkZl4OQXVct21t80RSQ3MhxWGsuHdVy7l JQTCC0zGch57AtleJUmVF0Wd/ZENBICK9KXIIOjLcZDbTMciWTmp2TlWAU/qXANfNNgK RaHw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Y1EgJWJ7Y/7zzNfPP6siqgZ0uZEWiVdlZtL5KmT4jVM=; b=eCxEMvTUi9N/Kj9Rxr4ChyY4jc0ZskYPowSYF984SEIG8bNxKYjgG+pcuSaiwbp1VW QkDc4EEl/aXdKe+JsRaW9l5oUPGvpxSURQQkl5uJ0wQ0y2m+fRzwASmISIY8mp3Vp3hJ xncwiUUDhrwoR5jr5fF1wukpCkGqVchHcfbzIMoUreLzuQ1L/aWDi3rI0XlhGQ9dWN7g KxcX6utq0mUMFvfRHUW2nz3ZYErlnUo9orRFesWbeSkon8mvUP6wCip23MpOQQITXOEC xsmbzp42uZYgneXl9IGeKom5UAzZfcufQHKQk+JLw174VuLcUrR6V5XQP9nOJq9EvTVS dNfA==
X-Gm-Message-State: AKaTC01pQHtQ8qksbYyc1uHtLETYPMUguBXObwRmoRorjjc0yPy2ZcC7gQDnbxi38+/P3DcSHDnOQj3DcDNE8w==
X-Received: by 10.107.3.83 with SMTP id 80mr1177036iod.52.1479353273320; Wed, 16 Nov 2016 19:27:53 -0800 (PST)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.107.1.16 with HTTP; Wed, 16 Nov 2016 19:27:52 -0800 (PST)
Received: by 10.107.1.16 with HTTP; Wed, 16 Nov 2016 19:27:52 -0800 (PST)
In-Reply-To: <20161117030632.GO22270@dhcp-9341.meeting.ietf.org>
References: <20161116061556.GG1073@dhcp-9341.meeting.ietf.org> <20161117013640.GB6217@pfrc.org> <20161117030632.GO22270@dhcp-9341.meeting.ietf.org>
From: Robert Raszuk 
Date: Thu, 17 Nov 2016 04:27:52 +0100
X-Google-Sender-Auth: IXnvIgCSZERBJfdCIDCWtj2qe3w
Message-ID: 
To: Job Snijders 
Content-Type: multipart/alternative; boundary=001a113f12625a8cf0054176c6fc
Archived-At: 
Cc: idr wg , grow@ietf.org
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 17 Nov 2016 03:27:57 -0000

--001a113f12625a8cf0054176c6fc
Content-Type: text/plain; charset=UTF-8

Hi Job,

If safe extending subcode 2 would be fine, but even if router does not
crash or choke are we sure that all NMS reporting tools will also take the
new msg size just fine ?

If so or if we don't care I would say go for it. But if we are changing the
encoding now perhaps it would be better to issue 4486bis instead ...

Thx
R.

On Nov 17, 2016 12:06 PM, "Job Snijders"  wrote:

> On Wed, Nov 16, 2016 at 08:36:40PM -0500, Jeffrey Haas wrote:
> > On Wed, Nov 16, 2016 at 03:15:56PM +0900, Job Snijders wrote:
> > > Some might wonder, why "Cease"?
> > >
> > > The beauty of using a new Cease subcode, is that the NOTIFICATION
> > > message type already allows extra data to be attached, so for most
> > > implementations it will be very simple to bolt what is specified in
> > > draft-snijders-idr-shutdown-00 on top of their existing code. In some
> > > cases we are looking at just a handful of lines.
> >
> > As I commented elsewhere, changing subcodes ends up being painful from
> > a conformance standpoint.  I would honestly not recommend a new
> > subcode.
> >
> > BGP implementations usually deal with the notification data section
> > that may not have information in a format they recognize by simply
> > ignoring or making the contents available in something like
> > hexadecimal prints.
> >
> > What I would suggest is simply take the RFC 4486 subcodes that don't
> > already return additional information (e.g. max prefix) and simply add
> > this shutdown reason as the data.  From the list of code points,
> > here's the ones I would suggest updating:
> >
> > :         2        Administrative Shutdown
> > :         3        Peer De-configured
> > :         6        Other Configuration Change
>
> > 
>
> I checked with Jakob, according to him IOS XR won't choke on a cease
> subcode 2 if there is trailing data.
>
> The UI or configuration concept of some operating systems might have
> trouble properly sending a 'cease "Peer De-configured"' with trailing
> data, so I'd skip that one for now. Same applies for 'other
> configuration change'.
>
> >From the looks of it, we can retrofit 'shutdown' under subcode 2 and
> forgo requesting a new cease subcode. I think I'd leave 3 and 6 as they
> are.
>
> Does anyone object to using subcode 2 for draft-snijders-idr-shutdown-01?
>
> The length of the NOTIFICATION will signal whether there is a shutdown
> communication or not.
>
> Kind regards,
>
> Job
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>

--001a113f12625a8cf0054176c6fc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Job,


If safe extending subcode 2 would be fine, but even if route=
r does not crash or choke are we sure that all NMS reporting tools will als=
o take the new msg size just fine ?


If so or if we don't care I would say go for it. But if =
we are changing the encoding now perhaps it would be better to issue 4486bi=
s instead ...


Thx

R.



On Nov 17, 2016 1=
2:06 PM, "Job Snijders" <job@nt=
t.net> wrote:
On Wed, Nov 16, 2016 at 08:36:40PM -0500, Jeffrey Haas wrote:

> On Wed, Nov 16, 2016 at 03:15:56PM +0900, Job Snijders wrote:

> > Some might wonder, why "Cease"?

> >

> > The beauty of using a new Cease subcode, is that the NOTIFICATION=


> > message type already allows extra data to be attached, so for mos=
t

> > implementations it will be very simple to bolt what is specified =
in

> > draft-snijders-idr-shutdown-00 on top of their existing code. In =
some

> > cases we are looking at just a handful of lines.

>

> As I commented elsewhere, changing subcodes ends up being painful from=


> a conformance standpoint.=C2=A0 I would honestly not recommend a new
> subcode.

>

> BGP implementations usually deal with the notification data section
> that may not have information in a format they recognize by simply

> ignoring or making the contents available in something like

> hexadecimal prints.

>

> What I would suggest is simply take the RFC 4486 subcodes that don'=
;t

> already return additional information (e.g. max prefix) and simply add=


> this shutdown reason as the data.=C2=A0 From the list of code points,<=
br>
> here's the ones I would suggest updating:

>

> :=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02=C2=A0 =C2=A0 =C2=A0 =C2=A0 Admini=
strative Shutdown

> :=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03=C2=A0 =C2=A0 =C2=A0 =C2=A0 Peer D=
e-configured

> :=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A06=C2=A0 =C2=A0 =C2=A0 =C2=A0 Other =
Configuration Change



> <snipped the codes that aren't suitable for decoration>



I checked with Jakob, according to him IOS XR won't choke on a cease
subcode 2 if there is trailing data.



The UI or configuration concept of some operating systems might have

trouble properly sending a 'cease "Peer De-configured"' w=
ith trailing

data, so I'd skip that one for now. Same applies for 'other

configuration change'.



>From the looks of it, we can retrofit 'shutdown' under subcode =
2 and

forgo requesting a new cease subcode. I think I'd leave 3 and 6 as they=


are.



Does anyone object to using subcode 2 for draft-snijders-idr-shutdown-=
01?



The length of the NOTIFICATION will signal whether there is a shutdown

communication or not.



Kind regards,



Job



_______________________________________________

Idr mailing list

Idr@ietf.org

https://www.ietf.org/mailman/listinfo/idr




--001a113f12625a8cf0054176c6fc--


From nobody Wed Nov 16 20:54:03 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 442CB12987D; Wed, 16 Nov 2016 20:54:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.398
X-Spam-Level: 
X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.497, 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 wX6_l5rrugsz; Wed, 16 Nov 2016 20:54:01 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id E4A4C129575; Wed, 16 Nov 2016 20:54:00 -0800 (PST)
Received: from tnishiyama-sslvpn-nc.jnpr.net (122x216x203x178.ap122.ftth.ucom.ne.jp [122.216.203.178]) by slice.pfrc.org (Postfix) with ESMTPSA id 2BB311E337; Wed, 16 Nov 2016 23:56:55 -0500 (EST)
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
Content-Type: multipart/alternative; boundary="Apple-Mail=_6CAB52D1-FB33-4723-B888-163D1F33C303"
From: Jeffrey Haas 
In-Reply-To: 
Date: Thu, 17 Nov 2016 13:53:56 +0900
Message-Id: 
References: <20161116061556.GG1073@dhcp-9341.meeting.ietf.org> <20161117013640.GB6217@pfrc.org> <20161117030632.GO22270@dhcp-9341.meeting.ietf.org> 
To: Robert Raszuk 
X-Mailer: Apple Mail (2.2104)
Archived-At: 
Cc: idr wg , grow@ietf.org
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 17 Nov 2016 04:54:02 -0000

--Apple-Mail=_6CAB52D1-FB33-4723-B888-163D1F33C303
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


> On Nov 17, 2016, at 12:27 PM, Robert Raszuk  wrote:
>=20
> Hi Job,
>=20
> If safe extending subcode 2 would be fine, but even if router does not =
crash or choke are we sure that all NMS reporting tools will also take =
the new msg size just fine ?
>=20
>=20
It's clearly worth checking a few more implementations, but:
- The notification PDU makes allowances for optional data.
- If you get unexpected optional data, what are you going to do?  Send a =
notification? :-)
- If you crash, you have a much greater problem.


> If so or if we don't care I would say go for it. But if we are =
changing the encoding now perhaps it would be better to issue 4486bis =
instead ...
>=20
>=20
Making this work a -bis is one way to proceed if the discussed behavior =
makes sense.  That said, it's perfectly fine to update a single sub-type =
in a standalone document that updates 4486.


-- Jeff


--Apple-Mail=_6CAB52D1-FB33-4723-B888-163D1F33C303
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii


On Nov 17, 2016, at 12:27 PM, Robert Raszuk <robert@raszuk.net> =
wrote:

Hi Job,
If safe =
extending subcode 2 would be fine, but even if router does not crash or =
choke are we sure that all NMS reporting tools will also take the new =
msg size just fine ?

It's clearly worth checking a few =
more implementations, but:
- The notification PDU makes =
allowances for optional data.
- If you get unexpected optional =
data, what are you going to do?  Send a notification? =
:-)
- If you crash, you have a much greater =
problem.


If so =
or if we don't care I would say go for it. But if we are changing the =
encoding now perhaps it would be better to issue 4486bis instead =
...

Making =
this work a -bis is one way to proceed if the discussed behavior makes =
sense.  That said, it's perfectly fine to update a single sub-type =
in a standalone document that updates 4486.


-- Jeff

=

--Apple-Mail=_6CAB52D1-FB33-4723-B888-163D1F33C303--


From nobody Wed Nov 16 22:01:05 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F36E01295DB; Wed, 16 Nov 2016 22:01:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.018
X-Spam-Level: 
X-Spam-Status: No, score=-16.018 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=-1.497, 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 Uwc9PyqNb42b; Wed, 16 Nov 2016 22:00:59 -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 C0F2D1294D0; Wed, 16 Nov 2016 22:00:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2030; q=dns/txt; s=iport; t=1479362459; x=1480572059; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=zYWjVx35oVVuUVaXDo/Og5Q3lqa4p50eT8QBylDiptU=; b=YQNP+e9OHOLbIfiUowvFu2T5I5arnGsMhXI7Ik7xvQUQKM9hVSA4tzYZ Zfvdd9upzh9KihBQhwJ4r0wbxLC+N6DyvE8b2XjvdFK3SzyQtY+njErhM qczQG1S9Gtd5kUNghEWaFkOGZ6SKGl1pt7/9Nc3L3wZc5bqtsgDEow3hh 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ATAQCGRi1Y/5ldJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzcBAQEBAR9YgQAHjTiXDpRjggcdC4V5AoIUPxQBAgEBAQEBAQF?= =?us-ascii?q?iKIRoAQEBBAEBATc0CwwEAgEIDgMEAQEBHgkHJwsUCQgCBAENBQiIZA60XotjA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBFwWGPIRaiioFmkIBkGGQKo1NhAkBHjeBBxy?= =?us-ascii?q?DWIFFcoVsK4EDgQwBAQE?=
X-IronPort-AV: E=Sophos;i="5.31,504,1473120000"; d="scan'208";a="348609841"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Nov 2016 06:00:58 +0000
Received: from xch-rcd-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id uAH60wdF024200 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 17 Nov 2016 06:00:58 GMT
Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 17 Nov 2016 00:00:57 -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, 17 Nov 2016 00:00:58 -0600
From: "Jakob Heitz (jheitz)" 
To: Jeffrey Haas , Job Snijders 
Thread-Topic: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
Thread-Index: AQHSQHPb7Ylg/KY+GEqhCKuFLFiUKKDczKiA///gs2A=
Date: Thu, 17 Nov 2016 06:00:58 +0000
Message-ID: 
References: <20161116061556.GG1073@dhcp-9341.meeting.ietf.org> <20161117013640.GB6217@pfrc.org> <20161117014215.GI22270@dhcp-9341.meeting.ietf.org> <20161117014701.GE6217@pfrc.org>
In-Reply-To: <20161117014701.GE6217@pfrc.org>
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.126.227]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: "idr@ietf.org" , "grow@ietf.org" 
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 17 Nov 2016 06:01:02 -0000

I'm happy to keep the current subcode.

In today's IOS-XR implementation, we simply hexdump and trailing
octets after the subcode in "show bgp neighbor".
The new code could be to additionally print it in UTF8, after
validating it (no terminal escape sequences or other rubbish)
and truncating it at 128 octets. And syslog it if a valid string exists.

Thanks,
Jakob.


> -----Original Message-----
> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jeffrey Haas
> Sent: Wednesday, November 16, 2016 5:47 PM
> To: Job Snijders 
> Cc: idr@ietf.org; grow@ietf.org
> Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in =
the peer's syslog at shutdown
>=20
> On Thu, Nov 17, 2016 at 10:42:15AM +0900, Job Snijders wrote:
> > On Wed, Nov 16, 2016 at 08:36:40PM -0500, Jeffrey Haas wrote:
> > > On Wed, Nov 16, 2016 at 03:15:56PM +0900, Job Snijders wrote:
> > > > Some might wonder, why "Cease"?
> > > >
> > > > The beauty of using a new Cease subcode, is that the NOTIFICATION
> > > > message type already allows extra data to be attached, so for most
> > > > implementations it will be very simple to bolt what is specified in
> > > > draft-snijders-idr-shutdown-00 on top of their existing code. In so=
me
> > > > cases we are looking at just a handful of lines.
> > >
> > > As I commented elsewhere, changing subcodes ends up being painful fro=
m a
> > > conformance standpoint.  I would honestly not recommend a new subcode=
.
> >
> > I don't follow, it seems you recommend to not change the behaviour of a=
n
> > existing subcode (conformance), but you also recommend against getting =
a
> > new subcode?  Can you clarify?
>=20
> No new subcodes.
> Add the text to the NOTIFICATION Data section of existing subcodes, when =
it
> makes sense and that Data section isn't otherwise specified.
>=20
> -- Jeff
>=20
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr


From nobody Wed Nov 16 22:01:56 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28E501295DB for ; Wed, 16 Nov 2016 22:01:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.699
X-Spam-Level: 
X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, 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 OQHg8s7YOKNg for ; Wed, 16 Nov 2016 22:01:52 -0800 (PST)
Received: from sidehack.sat.gweep.net (sidehack.sat.gweep.net [72.93.233.150]) by ietfa.amsl.com (Postfix) with SMTP id 37F1F1296E3 for ; Wed, 16 Nov 2016 22:01:52 -0800 (PST)
Received: (qmail 21294 invoked by uid 524); 17 Nov 2016 00:55:10 -0500
Date: Thu, 17 Nov 2016 00:55:10 -0500
From: Joe Provo 
To: 'idr wg' 
Message-ID: <20161117055510.GA31180@gweep.net>
References: <013f01d2404d$3dfff610$b9ffe230$@ndzh.com> <20161117014231.GD6217@pfrc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20161117014231.GD6217@pfrc.org>
X-PGP-Key: http://www.gweep.net/~crimson/pgp.txt
X-Disclaimer: "I'm the only one foolish enough to claim these opinions."
Organization: Russell Street UN*X Consultations - If we don't do it, you don't need it.
X-Do-Not-Email-Here: jzp@suespammers.org
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: 
Subject: Re: [Idr] WG Adoption call for draft-snijders-idr-shutdown (11/16 to 11/30)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: jzp-idr@rsuc.gweep.net
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Nov 2016 06:01:55 -0000

On Wed, Nov 16, 2016 at 08:42:31PM -0500, Jeffrey Haas wrote:
> On Wed, Nov 16, 2016 at 04:06:02PM -0500, Susan Hares wrote:
> > This begins a 2 week WG Adoption call for draft-snijders-idr-shutdown
> > (11/16/2016 to 11/30/2016).   The discussion should consider whether this is
> > useful to operators and technical issues. 
> 
> I'm in favor of adoption.

Same.

> I'd also suggest the chairs consider if prior work on BGP Advisory Message
> should be de-chartered.

Very much not the same.  The vast majority of operational issues I 
hoped we'd see fixed with -advisory- or -operational-message- as 
there's a swath of useful community not tied directly to session 
shutdown.
 
Cheers!

Joe

-- 
        RSUC / GweepNet / Spunk / FnB / CotSG / Usenix / NANOG


From nobody Thu Nov 17 01:03:22 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97A241294E4 for ; Thu, 17 Nov 2016 01:03:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=steffann.nl
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8gFojca-aJFH for ; Thu, 17 Nov 2016 01:03:19 -0800 (PST)
Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:9e0:803::6]) (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 18C0D129693 for ; Thu, 17 Nov 2016 01:03:04 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 026F137; Thu, 17 Nov 2016 10:03:01 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:in-reply-to:date:date:subject:subject :mime-version:content-type:content-type:message-id:from:from :received:received; s=mail; t=1479373379; bh=mz8zm5f5daNGHPwiAiP eYMfhH/sKMKiyRrM5LbJVQWU=; b=HELVQAqmPR9kJHt8sxGoUAWhYQ/uSIwr8Xm YWAklauzFhaUWt9vodGDd4cyUhM7Lst3i2f0fRFhTUnZwgnUDm2NOHFHh1p2PQqg Oa/523o6+67sFEsy0IwlAnOMtp1CozcxhXHjjlrDgd/Acu54co4Rl7D+/V/9r1wt FGcbdJQw=
X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl
Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Kt8nO7uXXx3R; Thu, 17 Nov 2016 10:02:59 +0100 (CET)
Received: from surfer-172-29-252-41-hotspot.s-bit.nl (unknown [78.108.136.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.sintact.nl (Postfix) with ESMTPSA id 37B2436; Thu, 17 Nov 2016 10:02:59 +0100 (CET)
X-Clacks-Overhead: GNU Terry Pratchett
From: Sander Steffann 
Message-Id: <75D3D2B3-EECA-4EB5-A515-3D563480CC7F@steffann.nl>
Content-Type: multipart/signed; boundary="Apple-Mail=_9E290C4E-9694-485F-A0CD-9B487924A46A"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
Date: Thu, 17 Nov 2016 10:02:57 +0100
In-Reply-To: <20161117055510.GA31180@gweep.net>
To: Joe Provo 
References: <013f01d2404d$3dfff610$b9ffe230$@ndzh.com> <20161117014231.GD6217@pfrc.org> <20161117055510.GA31180@gweep.net>
X-Mailer: Apple Mail (2.3251)
Archived-At: 
Cc: idr wg 
Subject: Re: [Idr] WG Adoption call for draft-snijders-idr-shutdown (11/16 to 11/30)
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, 17 Nov 2016 09:03:22 -0000

--Apple-Mail=_9E290C4E-9694-485F-A0CD-9B487924A46A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi Joe,

Op 17 nov. 2016, om 06:55 heeft Joe Provo  het =
volgende geschreven:
> On Wed, Nov 16, 2016 at 08:42:31PM -0500, Jeffrey Haas wrote:
>> On Wed, Nov 16, 2016 at 04:06:02PM -0500, Susan Hares wrote:
>>> This begins a 2 week WG Adoption call for =
draft-snijders-idr-shutdown
>>> (11/16/2016 to 11/30/2016).   The discussion should consider whether =
this is
>>> useful to operators and technical issues.=20
>>=20
>> I'm in favor of adoption.
>=20
> Same.
>=20
>> I'd also suggest the chairs consider if prior work on BGP Advisory =
Message
>> should be de-chartered.
>=20
> Very much not the same.  The vast majority of operational issues I=20
> hoped we'd see fixed with -advisory- or -operational-message- as=20
> there's a swath of useful community not tied directly to session=20
> shutdown.

I think that -shutdown- is a very good idea, and notification messages =
at shutdown are very useful. I'd love to see -advisory- revived at some =
point as well, as it provides useful notifications in other situations. =
I think -shutdown- and -advisory- would both be very useful to have as =
complementary features.

I think that -operational-message- is suffering from feature bloat. It =
tries to do too much. If we still want the query features of =
-operational-message- then those should be done as a separate draft. =
Notifications and querying are two orthogonal features and should not be =
mixed together in one specification.

Cheers,
Sander


--Apple-Mail=_9E290C4E-9694-485F-A0CD-9B487924A46A
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFSDCCBUQw
ggMsoAMCAQICARMwDQYJKoZIhvcNAQEFBQAwdjELMAkGA1UEBhMCTkwxEjAQBgNVBAcTCUFwZWxk
b29ybjEVMBMGA1UEChMMU0pNIFN0ZWZmYW5uMR0wGwYDVQQDExRTSk0gU3RlZmZhbm4gUm9vdCBD
QTEdMBsGCSqGSIb3DQEJARYOY2FAc3RlZmZhbm4ubmwwHhcNMTUwNTExMDg1MjM1WhcNMTgwODIz
MDg1MjM1WjB1MQswCQYDVQQGEwJOTDESMBAGA1UEBxMJQXBlbGRvb3JuMRUwEwYDVQQKEwxTSk0g
U3RlZmZhbm4xGDAWBgNVBAMTD1NhbmRlciBTdGVmZmFubjEhMB8GCSqGSIb3DQEJARYSc2FuZGVy
QHN0ZWZmYW5uLm5sMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC9b7oVFaA35FKgKq2dZXbh
X1kQl2mgPnaI3OurSyefZ6dyv8JFNM6CAA77kb/Gh5FXVDEJujcRPnE93Lmvmx+82J140WSiTpez
7QY8oBYNDCRP0KksXzwfClZjrG2Afw8S1jH14ymK0HufZ9kEkSWD5WzrxEDSqwnQTyFhsGCrbQID
AQABo4IBYDCCAVwwCQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBLAwKwYJYIZIAYb4QgENBB4W
HFRpbnlDQSBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFMBr5zy4rYkQJ/JeoU3+6lnw
Ebd5MIGoBgNVHSMEgaAwgZ2AFOH79lsAHFEBG+6Vrq192mCYPEg6oXqkeDB2MQswCQYDVQQGEwJO
TDESMBAGA1UEBxMJQXBlbGRvb3JuMRUwEwYDVQQKEwxTSk0gU3RlZmZhbm4xHTAbBgNVBAMTFFNK
TSBTdGVmZmFubiBSb290IENBMR0wGwYJKoZIhvcNAQkBFg5jYUBzdGVmZmFubi5ubIIJALBR3gny
oySYMBkGA1UdEgQSMBCBDmNhQHN0ZWZmYW5uLm5sMB0GA1UdEQQWMBSBEnNhbmRlckBzdGVmZmFu
bi5ubDALBgNVHQ8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBAFhAYYTBnxV8QzZPT+qs+WLWNRKL
4JQq0dpmSleofioAUrHj8m2BITvJY1pnIY7mdegJXic6+/uCKMAG8FrA6tSNu/hUoTXYMVcUUih5
xZyCWsIFmSBbTuel0nmPvZDayelIwi7GDN0u9IvrmyinSiYJ5jjgiKg3Z1HmMP5t9MR8vpS38bxT
WKef8RlACK9jeynmk2U8PFRT+ZVYDW3Us8z4wje+g+q0aEm8UZzoYE245C6aFBqiXS56AN9VcK2C
9Z4wSBnq+I0wRof0BIYIh7V1cFCtz3uhdcbVbfKPHP2GGv69nz/jqSz9hPbIEhC3/kv11FHvIA2x
t1scHJOw5DPKaogCtp4BEiOayepZRYo8SCILVTUH07QEP+6D/nLQnNavQT2ClQaSq9ufuD689TvC
r5BApB8glktKaPzsiW5gQncIp4GyY593cGkBdh2jPAVpYCyAG96xtY6E0NsjgoghSojeHRfaZOmR
iDfaszo4JlIer+VPTcsIl984275cOE/LJcXLSb3AA9AyffEr+6Eszs6HzkfWlzdTedGbqPFhkSlg
gBCTZAz/MCT//MVZiDq542xAU8nBpfKWfOyL3oK2PPQAGdpGxFNRzCBngi64n0mB+JrNS44j6WyP
qWp2IGSu05o7x6lcUgsjtNmpYvZy4NoyPu4je4+QuzBpFYgCMYICnjCCApoCAQEwezB2MQswCQYD
VQQGEwJOTDESMBAGA1UEBxMJQXBlbGRvb3JuMRUwEwYDVQQKEwxTSk0gU3RlZmZhbm4xHTAbBgNV
BAMTFFNKTSBTdGVmZmFubiBSb290IENBMR0wGwYJKoZIhvcNAQkBFg5jYUBzdGVmZmFubi5ubAIB
EzAJBgUrDgMCGgUAoIIBeTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xNjExMTcwOTAyNThaMCMGCSqGSIb3DQEJBDEWBBSvgobjlDJwpCSVnPIlRJOa2UU+/jCBigYJ
KwYBBAGCNxAEMX0wezB2MQswCQYDVQQGEwJOTDESMBAGA1UEBxMJQXBlbGRvb3JuMRUwEwYDVQQK
EwxTSk0gU3RlZmZhbm4xHTAbBgNVBAMTFFNKTSBTdGVmZmFubiBSb290IENBMR0wGwYJKoZIhvcN
AQkBFg5jYUBzdGVmZmFubi5ubAIBEzCBjAYLKoZIhvcNAQkQAgsxfaB7MHYxCzAJBgNVBAYTAk5M
MRIwEAYDVQQHEwlBcGVsZG9vcm4xFTATBgNVBAoTDFNKTSBTdGVmZmFubjEdMBsGA1UEAxMUU0pN
IFN0ZWZmYW5uIFJvb3QgQ0ExHTAbBgkqhkiG9w0BCQEWDmNhQHN0ZWZmYW5uLm5sAgETMA0GCSqG
SIb3DQEBAQUABIGAozb/Q8+6nnYhOZSQgYlW5AV8l7I6sA5OVk44EDoj90SG0NUEfFsDkCB4Q3qa
UWtMc9mE7xSgzGZtKfvfLKr3HzN3baqsY09Rv2OSJ4oVxQAco7vPolcLXIVW7J2/Pzpb3FIUMQ11
CekV0KrC46bp+DpMvNueSJRi7GNJp2XulUAAAAAAAAA=
--Apple-Mail=_9E290C4E-9694-485F-A0CD-9B487924A46A--


From nobody Thu Nov 17 02:16:51 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69E6A12964D for ; Thu, 17 Nov 2016 02:16:50 -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, 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=kumari-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 u5Kesa-3RjQL for ; Thu, 17 Nov 2016 02:16:48 -0800 (PST)
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 038151297BC for ; Thu, 17 Nov 2016 02:16:47 -0800 (PST)
Received: by mail-qt0-x233.google.com with SMTP id w33so126507860qtc.3 for ; Thu, 17 Nov 2016 02:16:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8WxYKqM+kKhRC7OyMdwEBIuZ/8am2Xn6LKCMj9qxFgw=; b=Eqee298U6Er+W2LVBarOpLAE8kd+fOAt6+ah0R50Ng2qDwa8nejrbdm9S4vdY2yhEP DtbyoMbv4buPbkxklAkISA7TTEds0ON5GdSDXF1JXPCV+sCFWkNR/uPwWb7a/5UQKBgv oH+2sjGsKx71/HFAgWeKIL4VX8lvbqBsxnaL8p7qslxvD/YNMu6vm71m6KbEV2lWjArg TMuxfVODrWV21J37B7zZq9cpl7xElCUyLa5QbzeT8FEAPjRURUIDgxff45Elcuy8uOZO DEZprlWxa9xpNf9GNm5H6Qv/b1gpZEeO95ZmLj8hUPNS4cARbsOnCOOHmY62Ia19bNlu 4PUQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8WxYKqM+kKhRC7OyMdwEBIuZ/8am2Xn6LKCMj9qxFgw=; b=DTcC9QZVjaLoanskkG4i8nunxXHwMK4UabQyuOOZq1+Z7DMaSbU8brkm8E8i62vWng h58K7m59a4DajY3fWn/RNKvkiFl5nndUE2twrgaeLACs95xJVy6e13EBTNdEU7w4w2XU o4Cmh65wnSKINxhqFfncxAOJQtQMPGcMmBra72l2uw2Gb6KLlTjuwjuQh8ztgn41dHFC z8gKMnvRU2qEstJhjrC+Zk7qWA+8SteHOlVSMfsvWZORuAdjZDfZ5C7atPr1rAO2Pc4t D4EUzU0pDdNTmcAxpcvDI4XuxhpXNR+DWthZvOhlTnyfOLwNndM8ssygJem+IIJ9Xe7U CIPQ==
X-Gm-Message-State: AKaTC00V2CJnr0W3gaO3QruZGolKq5EveFM2COckScdvdLlH5QA/VltS1eW4YIBJm8wUYGqiupUMjHwZWLwIQbKv
X-Received: by 10.200.47.140 with SMTP id l12mr1433839qta.51.1479377806844; Thu, 17 Nov 2016 02:16:46 -0800 (PST)
MIME-Version: 1.0
Received: by 10.12.162.197 with HTTP; Thu, 17 Nov 2016 02:16:16 -0800 (PST)
In-Reply-To: <013f01d2404d$3dfff610$b9ffe230$@ndzh.com>
References: <013f01d2404d$3dfff610$b9ffe230$@ndzh.com>
From: Warren Kumari 
Date: Thu, 17 Nov 2016 19:16:16 +0900
Message-ID: 
To: Susan Hares 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: idr wg 
Subject: Re: [Idr] WG Adoption call for draft-snijders-idr-shutdown (11/16 to 11/30)
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, 17 Nov 2016 10:16:50 -0000

On Thu, Nov 17, 2016 at 6:06 AM, Susan Hares  wrote:
> This begins a 2 week WG Adoption call for draft-snijders-idr-shutdown
> (11/16/2016 to 11/30/2016).   The discussion should consider whether this is
> useful to operators and technical issues.
>

I support adoption, and am willing to read, review, fold, spindle,
mutilate and / or contribute in any other way needed.
W

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



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf


From nobody Thu Nov 17 05:44:54 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB6512975C for ; Thu, 17 Nov 2016 05:44:53 -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=bskyb.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 m1VTMXdT-JAM for ; Thu, 17 Nov 2016 05:44:51 -0800 (PST)
Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20061.outbound.protection.outlook.com [40.107.2.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB4B81295A3 for ; Thu, 17 Nov 2016 05:44:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=BSkyB.onmicrosoft.com;  s=selector1-sky-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version;  bh=vXbtvcSzHRMmck+Tvm3Y/C4E9KeyE+IZpTp2Ap5ysFM=; b=WxcBnwaGO70bHL9vMccw2Upew/fdoUh5xFSdv1whm7lAfWE6DjJ4XTGhHvTS0sxOVu4ABazWN/ls1oRqSJSSwyNix8J9J+RatXPuG312ZxBZb4XsCYBDVZfSxeEYIWd1xspGGM7+YFlCXDCKWJXn/MmOzNzs+F7q2miaroWzZys=
Authentication-Results: spf=pass (sender IP is 176.255.244.223) smtp.mailfrom=sky.uk; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=pass action=none header.from=sky.uk;
Received-SPF: Pass (protection.outlook.com: domain of sky.uk designates 176.255.244.223 as permitted sender) receiver=protection.outlook.com; client-ip=176.255.244.223; helo=email.bskyb.com;
X-IncomingTopHeaderMarker: OriginalChecksum:; UpperCasedChecksum:; SizeAsReceived:1185; Count:20
From: "Dickinson, Ian" 
To: Susan Hares , 'idr wg' 
Thread-Topic: [Idr] WG Adoption call for draft-snijders-idr-shutdown (11/16 to	11/30)
Thread-Index: AdJATQXKePgAmF1nTgStU0J//yEVUAAi3PYQ
Date: Thu, 17 Nov 2016 13:44:46 +0000
Message-ID: <9B3BFE0A18160E40BAF1950414D10FAE6173FB79@WPMBX010.bskyb.com>
References: <013f01d2404d$3dfff610$b9ffe230$@ndzh.com>
In-Reply-To: <013f01d2404d$3dfff610$b9ffe230$@ndzh.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [191.255.72.199]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-IncomingHeaderCount: 20
X-EOPAttributedMessage: 0
X-MS-Office365-Filtering-HT: Tenant
X-Forefront-Antispam-Report: CIP:176.255.244.223; IPV:CAL; SCL:-1; CTRY:GB; EFV:NLI; SFV:NSPM; SFS:(10009020)(6009001)(7916002)(2980300002)(438002)(199003)(189002)(69596002)(2950100002)(5660300001)(305945005)(47776003)(5890100001)(92566002)(26826002)(9686002)(106466001)(230783001)(189998001)(74482002)(5001770100001)(229853002)(107886002)(86362001)(87936001)(102836003)(2906002)(81166006)(3846002)(8936002)(6116002)(11286001)(8746002)(50986999)(23756003)(54356999)(76176999)(81156014)(2920100001)(7736002)(7846002)(66066001)(55846006)(50466002)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:AMXPR07MB150; H:email.bskyb.com; FPR:; SPF:Pass; PTR:b0fff4df.bb.sky.com; A:0; MX:1; LANG:en; 
X-Microsoft-Exchange-Diagnostics: 1; AM1FFO11FD001; 1:TPM73ONviSPDOdT/j9z9o9r0NJj846ZnKFTXQejo1NNXwuIbumkUeigfDTsj6qiYLbI6ni3E0TxQUEZBNLBPuvUCBGxzoznEfKqbrX5Oh+XCQAbXIbZuFZGtjMQlBlp8SZRyVuqNBKCCNEDJreMOw+tRnwMKbeNd7HyQjWNq2kmmSq/tW37K6kUb9ebuxrbXuDB0emXSjQeA2ain8BIAN+c8iH1IzOd/tmfp6FRla5OlLZ/Kg//Dq3876VB+LP9ECyvxiMQYJK6F5UpRhG5l2e4HH4TbkII6Dxlmysg6VzFQFtDZVEM8kf0Fue2Tvakq3ThuGoGEOsq5cilT8m9U49IEERtfPI3hMBugt7WoJ4TnJNt7fsOOqDooj1QiaMeTDgjIGl/tnxc5Yb5eZKWTwwDPSWlUGkgLm2knrPwvFBVW7LYNVGRkVfocEH8WgN5XkDttVhWjKR22Hcc5G/h5FyyVrZHNxWtlgqd9AM8d8zTZ06WWGuvc0EfZs/k7SAB5gkM4wwhX1gf26hABjRUj0h2v82M8/BHO+oGOnzq151/eqhxLRPnUq5NI/Tcvwpjc
X-Microsoft-Exchange-Diagnostics: 1; AMXPR07MB150; 2:id+WQZwVl3YkHqL0JLwv4AfRa2WHMLd7C5aGvGo2QvXPthb5cC+K4o310T7WRgK0ZPm+SkbTvkWtgZUBUgWCMgfuj7hlAU6m5Uy1dlb9AvPH56b+CZbjWm7p7Q+3gBg7nTthihlbBJvwhGQ45T6k9J4Y/723PcwpzDBYuj/qML0=; 3:mR1zpA4JeUttw3skqbnoDtgylEbMBMnisxt2PfrKz92Z4FVgIOk2HAJnaSS/JLAjFuAgwWhXlTaVFeY+HnkXGgcChGb7G7SYQ2ImRvaIF5qmBZ5B36bkTXoBpsGcMU2ht3avi0kjCVAgsLC3gaBTneXYK6CDAJXL5I7HLUtKf9/0eoNRkEVN/WP01Xn3jURubUOFjl3usmjAhzxd0LVZz6nafRSAuAotchzZj0k2vn7KbgQXnwWbuLeO+3wnz3Pj2zcQKdiXDb65WreksYfrLI17LP7ruU8ChfsTSdxH8sw=
X-MS-Office365-Filtering-Correlation-Id: e7f66d9e-32fd-48a9-1508-08d40eefe5c3
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(8251501002); SRVR:AMXPR07MB150; 
X-Microsoft-Exchange-Diagnostics: 1; AMXPR07MB150; 25:tSwmSfOEvKqLd/gAxOoqlYcsYP5JcGbRiODvoXVbfuvAbSggp8lqNt6QPMkDHAJsG96O97bQYWzPuTxBY5mj2Fcibnpb2LH2KjN8f75NslgiSl+HQsgx+mqFFXC0YZ323EVu/xN+5GlSOre871l761Da6soLqDAZPy7BtSh1rKDyvsEqji2/QHxvvoI/TU7AFJ1AaQCUM1YCKuwxM48dAbhG0tqok80VccC6RAcLkvNrQhwozQkT8JKXme+gwSZkiAFGVGV7RxpOGnvG4488MUd+hIPMEYLxhmcesIn6y7Q3mMfZoDIhO8ghqyD7ERggIo52qZwTvHsLwsG8F+hkMz/SyFw4XECKwlXeOubfQNYtytgpXiX3VWm1Xou6675dKZEXoz+a+FCng/R4uoFMwPTzeg+f/1VbDcQw63O5VcgXDDIJj+cF3C+ojjkfHchRP9j0PDCeuWCuLz4SzoyehbKPU9MxXkWLZho8a31kV/ij3sht+RJdSyz0+9P17hOHWM15mwHNtcpYeaxdfW4upXrjfpooKdlLMdRebHoZB6IgnqRzdKx/4PFOzk7/47wbMY5LGVGjdq6Jm036PY6POJLk1HBaRWMgll3CQ2AOgjFKzXgOidghBhKpk/dukRRN+hFzmP0YHPz9PYFGx3a9fYpWfF9uS0teKoMxEebiIAN417+H0uHKsg+gmQrf4RXJmr90TIn4AEaY0nSSolykaihuvDGCD3+PjYIo82ZNDopoCIYRtNwANt+OBkTn8APkLEqbUMuruooM6x64pYz94L/ncXcnM+/EIyTFLXlghgifvGmuhzQ1N3AZByakF087M0jDY9JQGrA30f+32pvAyw==
X-Microsoft-Exchange-Diagnostics: 1; AMXPR07MB150; 31:1cElqY5px65zihOV04UYpIBG+EOoce3RMTWMLZoGpPv0IW/KCkLLUhpV/1U1Hb/SeMFqWY1gqWPqEmSOqC+Gt3/3GGLbIl/gU1X23CB6aVYXtqn7wdqUEymq8x7/vmr2/BwAhWI+pYzAEuSf7P1QwAR4Fl6NzQMNCt5rE5SYjuyF83mMmTwDLYC4NVtGFgtM559B20eNtfPA61WbkG8kvvsa9Mn/+yH1747GZ4PKw6ouvTqY2M/5+E5gN09XVsvSXGsU37WylxRBlLYgIm70IYYIFKcES1qluYyemdBBkMs=; 20:QKzeq8Df1thMzdNaSdlQl+ZNxHy+oYuzsuNiqmmmU1BWqMom+BZ9nFha0dAH/rprd3db5JIc2+/RbEDfz6msuef0jHOPdvG5vUMQ9XFzz1Ae0PtNBxxl89xHpFC5oN7lhvR8heiVvLtNtZANDAl2zqUrzJalpQbdoxuUic06kSzQDPEisQl/TxtePYb1GLwPmTQPK0r//HyF4GCXKSI4UJEdntk0uoUkBk2/7SCwLCDygjAwa//iQ/QizT9BuNmsMaHkCK2Ka03qgxa+Q1mM6IDTujRIT5UbaO81CAl+QkjSoKKhO1xqZa8gssQ9paxyRT+VLQsdZaujs154QOSeDdZW7GLgmdnp2sNJgyiqqkGQELMMU1+46CKLvA2Y4qOYuF7tyEgj+wfK9DKqI07mgVWRr3uB3wmIqtQcdfWK3KRxhU0AjgW17vyhpcTUl3ZPsg+6yhGKY10oJtYaAzNmOf8+/pUKV60DtPiAvg4E6yKPQqOV3aDJwoKcw8f3yojp
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6060326)(6040281)(601004)(2401047)(13012025)(13020025)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6061324)(6041223); SRVR:AMXPR07MB150; BCL:0; PCL:0; RULEID:; SRVR:AMXPR07MB150; 
X-Microsoft-Exchange-Diagnostics: 1; AMXPR07MB150; 4:hqbLtqPlmFk8fS2j+r8MOkjbvOaiGiEJ5ZlC0jNjdzREZqA9gbaRakBgwrCoZz9ijwKyCzkw4JU/P8k3Olz7VqxFvwNh/rn8wkDxKTJ+hWgteC7v5WO5hv+bT+sJTSke/mvAgt7FfNWZTn/eRBiErlV7XwicxviqxefK4AdcjcoGv/y3nD/+E63RcuWSuzdSp/VevLiVuPCFInkUNdnFYvTzA7IKnYXdCqTL+ioe9+vBgaP4QioshE+6di1/hXqiGn0VRHVTJxUb0iL3/zAB1pCd4R7JXIqRo6FOO/Ais4QHbi8B61NzIx3NvDkPK+BCKZETnH0GnRS8LsMVSYkdlzALs8Uu4inMr2EooJzWp6eE0g77jLH+QD0HvvAxUEpoumNbGuqF8Q+so63hlQz8BtefS5kcIkd9RpITpXv5JHmgNta/5+Sd8uEJpfZMYKPI1lKMTZw75dLLqG3N+SOPIZLyvHp4WXdFqCS9PkNWpE8IADQV6IzPcoZ7UYgP88/EYaOAbSL9yswedQUpKVxl9g==
X-Forefront-PRVS: 01294F875B
X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; AMXPR07MB150; 23:CpVSCx6Zv0HMZykrx5k5O/bp62TnTX4mHGazfVOM?= =?iso-8859-1?Q?NCZRyTvnRJijo8gpxNSLMqhzyUBNDJVgNInBv447jXrcofzCgTrZcJzfnL?= =?iso-8859-1?Q?mdoIjkf+nz3tRJLyJTriTKMwVzZTxhgC4s4dBrebK+/gtKUTN3t3AFyKO8?= =?iso-8859-1?Q?HKfmfOaROmapLLaWjcHuhDrvZNfE5GKW55nQO7qIlPngz9iYDZ1h2LhH5n?= =?iso-8859-1?Q?2P11p+oLh5G06jSOUn8NUd9yB+yICI0HAPZTcwi1ZmNLB7fqSTC1x076rS?= =?iso-8859-1?Q?Uh5Prwq40JwTeMDCI0B4jcFRhem2xzSrxcWNeQEs97758JtT6EBv8XsxaH?= =?iso-8859-1?Q?YtOZB2LGsPQzZr1kYc/NylrW3G+xMR9KIdorE0q6yydRHiPCguRYbALJ4e?= =?iso-8859-1?Q?Ljk93g3ARPGnD2mqH0y36K4cP8rZNV2wCuqBWdGNi68xeQm0/Slc3JFGSn?= =?iso-8859-1?Q?n/R/5BtnQAJcwHhbzC1Z61n9JaO2U+k12hQqa3Ic578mFHZzFQpTEduuh7?= =?iso-8859-1?Q?VN3pxc/d25VtKuBOejtU/2KWcfZbCi+rpiV32ZpaM8OXTTuAd44/Pom6NT?= =?iso-8859-1?Q?/PEyTALJw7aNopCLpjz+O8RuQru9puU+D7yNbn2ahll3yavtXM0hshF98d?= =?iso-8859-1?Q?5kHiabsVdFum+hP7/eIL8T0AgGO3lXqa8Tptc1/aLEkM1uUqeOGgfVR1tS?= =?iso-8859-1?Q?lSbCFhJtOi1QgKBndSZCGjLEqxGVfiRxMa4iGdc7eOKAVB9VHB3fpmIETC?= =?iso-8859-1?Q?qSB299YQSRWVpFcDc2SM5SEFqKoQL3EMarfiggP7lQl56Q7IeKFyJNiqnY?= =?iso-8859-1?Q?dp4vXfhAh36hSYhLO4fCxJ5GKO3THb2BVi6pX177qCOpaKsnvhexWBow70?= =?iso-8859-1?Q?dN+rgdZWWzbMzXX2N3purvhX7DQVk7cFQW5i5ki2wsP2BG1BV18gi/HABP?= =?iso-8859-1?Q?Lx9HDEE/VY6H1Zh2MS3t1uRWP/uLom334u8ZbIeruxMHRdJJaEKo3ThgKM?= =?iso-8859-1?Q?zcnNSOtMxepfq0ynzlqzFovzq6WJjpN6lmtChbEcX8EDwrE0Sm6xktjaQz?= =?iso-8859-1?Q?wBN2v2tistB2PcdpkZm3K74BTlPuE12DyAWO08JKV+LW+T7dz8oaaPaUED?= =?iso-8859-1?Q?tG9hjcURHI2bSU8MgQK1EjudHg=3D=3D?=
X-Microsoft-Exchange-Diagnostics: 1; AMXPR07MB150; 6:206ccJvcbCqDR6PzMyqkXUWbDMLDft4K093z2AWgB78QGvn2UU/nVNF939bQhRgtBoGrnMT+WVPh1kPD0ItQj1NBIOrG2XCzvxC6VcnBZ7pCjz1mna67ypP5aW9xiwnqUHxazVpocG+GnKrB5DVFPBXNHDzbLyzhts88kyi7mIG+F9U9PVABmJgty40LHSv4cw0UPdOHLqRO1rM42xYWaf321/c77QpSlJI4HkYaPpgkg9SJvM4e1oe3HivRdwaMHGKchBZ0KHLiCe2BfQnqMpr61bgX45HY4rQzRqm2xNGAhodXnw5H+o+RUq9zUooAghx7FZiI7jwIJEHFuHKxvuSCmo/b/Bt2oidALEIRDffcd37u/X9gMzaSdp+OJvHX; 5:Ci7z+rC/+JIhGcLY3gmVK2fRzO8Qc/Vg65PfG7Cd2gpfhp21R0Ipcv7hwm0C021eZoJtiKX+WTIkXNUBcYtACAnsyEMB+3/VRYO4nCTzjTGNijqXKTPvRhkHoE4DvDY8FTe/q9BENtGU9eGjvdjeUw==; 24:0SEyuVQaVVO1HXlzPGbWmgFkLcTv45h3yHkBaGW5sOPEaQ/pD9deJD3isCOhwHgtmd/bpbCRzOvs+laXHdYdS4DJz/XMvhdn0quSYfh8l5w=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; AMXPR07MB150; 7:xh2UlpEIBaZ7Ou/3GQOiDQnUT3GoCRweAy1yX83ndWTWZ0YxyZ3c/diexZ1dOBcgUEL4T2rgw5XpskjxbryH5f9Xo5KIuasYU/cjZWODiSay3NnAL6phydld56MFnjY0jwaTh6zY0IJ1bqPMCehNZUDWhbi5VIg9zLBFOUstXhiUXXu3WeVKzy1nrLJp2CIVz+Iu1sBRFQqRkDHy3HKJUfEEXl2IAJwbQCoB9YGEf/e8Mk+vQhoDdToAfzhjBMnvPjU5uZvIyDeWrrWRdoQnFmwy+DXDxZJtSxDS6ygZY1EKZ26InFs2FOlg81guWZQMjg5+TgpVL2fIarp99gJmKCOHHHeNzbwKesxR+v9AUuM=
X-OriginatorOrg: sky.uk
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Nov 2016 13:44:47.8482 (UTC)
X-MS-Exchange-CrossTenant-Id: 4f86cebc-57e2-40a0-86cc-01d73be93ba0
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f86cebc-57e2-40a0-86cc-01d73be93ba0; Ip=[176.255.244.223];  Helo=[email.bskyb.com]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMXPR07MB150
Archived-At: 
Subject: Re: [Idr] WG Adoption call for draft-snijders-idr-shutdown (11/16 to	11/30)
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, 17 Nov 2016 13:44:53 -0000

I support adoption.

This is useful for operators.

(As an aside, I'm not convinced that -advisory- is a dead end yet - as ther=
e are other scenarios that can be covered)

Thanks,

Ian

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: 16 November 2016 21:06
To: 'idr wg' 
Subject: [Idr] WG Adoption call for draft-snijders-idr-shutdown (11/16 to 1=
1/30)

This begins a 2 week WG Adoption call for draft-snijders-idr-shutdown (11/1=
6/2016 to 11/30/2016).   The discussion should consider whether this is use=
ful to operators and technical issues.


Sue
Information in this email including any attachments may be privileged, conf=
idential and is intended exclusively for the addressee. The views expressed=
 may not be official policy, but the personal views of the originator. If y=
ou have received it in error, please notify the sender by return e-mail and=
 delete it from your system. You should not reproduce, distribute, store, r=
etransmit, use or disclose its contents to anyone. Please note we reserve t=
he right to monitor all e-mail communication through our internal and exter=
nal networks. SKY and the SKY marks are trademarks of Sky plc and Sky Inter=
national AG and are used under licence.

Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Reg=
istration No. 2067075) and Sky Subscribers Services Limited (Registration N=
o. 2340150) are direct or indirect subsidiaries of Sky plc (Registration No=
. 2247735). All of the companies mentioned in this paragraph are incorporat=
ed in England and Wales and share the same registered office at Grant Way, =
Isleworth, Middlesex TW7 5QD.


From nobody Thu Nov 17 06:00:55 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6598612941D for ; Thu, 17 Nov 2016 06:00:54 -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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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 SqLAf_UhvUHB for ; Thu, 17 Nov 2016 06:00:53 -0800 (PST)
Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.146]) by ietfa.amsl.com (Postfix) with ESMTP id D2C5512945B for ; Thu, 17 Nov 2016 06:00:52 -0800 (PST)
Received: from [85.158.139.163] by server-10.bemta-5.messagelabs.com id F4/E2-21400-318BD285; Thu, 17 Nov 2016 14:00:51 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLIsWRWlGSWpSXmKPExsUSsELzi67wDt0 Ig7O/dSxe3X7G5MDosWTJT6YAxijWzLyk/IoE1oy/S58wF4hW7F+R3cAo0sXIxSEkcJBJ4uy0 DYwQzlpGiQk/JwM5nBxsAkYSE9btZ+li5OAQEVCUWPkpGSQsLBAq8XfHShYQW0QgTGLRlGnsE LaexJm/G8FsFgFVianfZrOB2LwC9hJ3e44ygdiMArISXxpXM4PYzALiEreezAeLSwgISCzZc5 4ZwhaVePn4HyuILQo089Pt1SwQcQWJiwu62EDOYRbQlFi/Sx/CtJVYtEAZYqKixJTuh+wQWwU lTs58wjKBUXgWkmWzEJpnITTPQtI8C0nzAkbWVYwaxalFZalFuoYmeklFmekZJbmJmTm6hgam ermpxcWJ6ak5iUnFesn5uZsYgZHAAAQ7GM+e9jzEKMnBpCTK+3SKboQQX1J+SmVGYnFGfFFpT mrxIUYZDg4lCd6i7UA5waLU9NSKtMwcYEzCpCU4eJREeAVA0rzFBYm5xZnpEKlTjMYci048f8 DE8W7zuwdMQix5+XmpUuK8diClAiClGaV5cINgqeISo6yUMC8j0GlCPAWpRbmZJajyrxjFORi VhHn1twFN4cnMK4Hb9wroFCagU/YI6ICcUpKIkJJqYJSPObTVxStCjWfT/ZXpEUW1+de1fWqO LObY9jU7qOWKwXY16aDAAsOG4E6pjcmPU1eaLj3oLmF+MZM3dTfr1k9LWf4zTxRaJG97Si/38 sLQ/KjguZc7budNnblBf//dlPe7FT8viGxWyhYPunuhUtFgT2vB/HOdSwRmb1Bo2ZMVEDLxyt LtwUosxRmJhlrMRcWJADtBtGgQAwAA
X-Env-Sender: david.freedman@uk.clara.net
X-Msg-Ref: server-10.tower-188.messagelabs.com!1479391250!73054472!1
X-Originating-IP: [80.168.41.244]
X-StarScan-Received: 
X-StarScan-Version: 9.0.16; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5649 invoked from network); 17 Nov 2016 14:00:50 -0000
Received: from staff02.mail.eu.clara.net (HELO staff02.mail.eu.clara.net) (80.168.41.244) by server-10.tower-188.messagelabs.com with SMTP; 17 Nov 2016 14:00:50 -0000
Received: from [80.168.41.252] (port=27021 helo=SRVGREXCAS01.claranet.local) by staff02.mail.eu.clara.net (staff02.mail.eu.clara.net [80.168.41.244]:25) with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) id 1c7NFC-0006vw-7F  for idr@ietf.org (return-path ); Thu, 17 Nov 2016 14:00:50 +0000
Received: from SRVGREXMB01.claranet.local ([fe80::64bc:5d10:5203:a830]) by SRVGREXCAS01.claranet.local ([::1]) with mapi id 14.03.0319.002; Thu, 17 Nov 2016 13:57:30 +0000
From: David Freedman 
To: "idr@ietf.org" 
Thread-Topic: [Idr] WG Adoption call for draft-snijders-idr-shutdown (11/16 to 11/30)
Thread-Index: AQHSQNqJ6N+tPLuQjkSUAzSviFEOHA==
Date: Thu, 17 Nov 2016 13:57:29 +0000
Message-ID: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.1b.0.161010
x-originating-ip: [172.26.6.254]
Content-Type: text/plain; charset="utf-8"
Content-ID: <61F7ED957AADC946B20BAFC1B6BC64A8@claranet.local>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Idr] WG Adoption call for draft-snijders-idr-shutdown (11/16 to 11/30)
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, 17 Nov 2016 14:00:54 -0000

U3VwcG9ydC4gDQoNCg0K


From nobody Thu Nov 17 08:29:00 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53C02129509; Thu, 17 Nov 2016 08:28:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.416
X-Spam-Level: 
X-Spam-Status: No, score=-3.416 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, 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 5aR30vyUgBiy; Thu, 17 Nov 2016 08:28:53 -0800 (PST)
Received: from relais-inet.orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A6F512942F; Thu, 17 Nov 2016 08:28:53 -0800 (PST)
Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id 8F917C0163; Thu, 17 Nov 2016 17:28:51 +0100 (CET)
Received: from Exchangemail-eme3.itn.ftgroup (unknown [xx.xx.50.46]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 6A50A180062; Thu, 17 Nov 2016 17:28:51 +0100 (CET)
Received: from OPEXCNORM2F.corporate.adroot.infra.ftgroup ([fe80::994e:c3e:1d70:d2b4]) by OPEXCNORM3D.corporate.adroot.infra.ftgroup ([fe80::e4bd:f641:7b12:33fc%21]) with mapi id 14.03.0319.002; Thu, 17 Nov 2016 17:28:51 +0100
From: 
To: Jeffrey Haas , Job Snijders 
Thread-Topic: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
Thread-Index: AQHSQHMLlLQVzfHXk0yqMHFGykdY7qDdVdIg
Date: Thu, 17 Nov 2016 16:28:50 +0000
Message-ID: <16426_1479400131_582DDAC3_16426_1669_1_53C29892C857584299CBF5D05346208A1EC87201@OPEXCNORM2F.corporate.adroot.infra.ftgroup>
References: <20161116061556.GG1073@dhcp-9341.meeting.ietf.org> <20161117013640.GB6217@pfrc.org>
In-Reply-To: <20161117013640.GB6217@pfrc.org>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.168.234.5]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: "idr@ietf.org" , "grow@ietf.org" 
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 17 Nov 2016 16:28:55 -0000

I support the draft.
I also support Jeff's idea to re-use existing sub-code(s).

1 possible comment: the length of the "Shutdown Communication" field seems =
implied from the length of the data field, rather than being explicitly ind=
icated. If so, it seems that we are closing the possibility to advertise ad=
ditional data/usage, in some future. What about adding a TLV format?

Thanks,
--Bruno


> From: Jeffrey Haas  Sent: Thursday, November 17, 2016 2:37 AM
 > To: Job Snijders
 > Cc: idr@ietf.org; grow@ietf.org
 > Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in=
 the peer's syslog
 > at shutdown
 >=20
 > On Wed, Nov 16, 2016 at 03:15:56PM +0900, Job Snijders wrote:
 > > Some might wonder, why "Cease"?
 > >
 > > The beauty of using a new Cease subcode, is that the NOTIFICATION
 > > message type already allows extra data to be attached, so for most
 > > implementations it will be very simple to bolt what is specified in
 > > draft-snijders-idr-shutdown-00 on top of their existing code. In some
 > > cases we are looking at just a handful of lines.
 >=20
 > As I commented elsewhere, changing subcodes ends up being painful from a
 > conformance standpoint.  I would honestly not recommend a new subcode.
 >=20
 > BGP implementations usually deal with the notification data section that=
 may
 > not have information in a format they recognize by simply ignoring or ma=
king
 > the contents available in something like hexadecimal prints.
 >=20
 > What I would suggest is simply take the RFC 4486 subcodes that don't alr=
eady
 > return additional information (e.g. max prefix) and simply add this shut=
down
 > reason as the data.  From the list of code points, here's the ones I wou=
ld
 > suggest updating:
 >=20
 > :         2        Administrative Shutdown
 > :         3        Peer De-configured
 > :         6        Other Configuration Change
 >=20
 > Ones that possibly shouldn't be changed:
 >=20
 >=20
 > :         1        Maximum Number of Prefixes Reached
 >=20
 > This one is fully specified.
 >=20
 > :         4        Administrative Reset
 >=20
 > I'm not sure returning something here makes sense.  This seems to be more
 > the "clear bgp neighbor" case.  Unless you think adding information about
 > why the user did the clear makes sense.
 >=20
 > :         5        Connection Rejected
 >=20
 > Here's where things get a little odd.  You should get one of the other
 > subcodes on clear.  If you're preventing it from coming back up, this co=
de
 > may be returned.  This means that even if you're storing the last receiv=
ed
 > string, it might be overwritten by this.
 >=20
 > :         7        Connection Collision Resolution
 > :         8        Out of Resources
 >=20
 > I suspect these shouldn't return anything.
 >=20
 > > Previous attempts such as draft-ietf-idr-advisory-00 and
 > > draft-ietf-idr-operational-message-00 failed to deliver for various
 > > reasons (feature creep comes to mind), therefore we are trying to do
 > > this as simple as possible.
 >=20
 > IMO, they more likely failed as low priority features that couldn't get =
past
 > product managers.
 >=20
 > If, especially the existing code points are re-used and don't alter exis=
ting
 > implementation conformance, I suspect this draft would be closer to a
 > trivial modification that has a better chance of getting shipped quickly.
 >=20
 > I also have to ask about:
 >=20
 > :    As of today these vendors have produced an implementation of the
 > :    Shutdown Communication:
 > :
 > :    o  ExaBGP
 >=20
 > And exactly which code point did you squat on to do the prototype? ;-)
 >=20
 > (I'm not exactly concerned about this since it's local in impact but you=
'd
 > think after the discussions this week...)
 >=20
 > -- Jeff
 >=20
 > _______________________________________________
 > Idr mailing list
 > Idr@ietf.org
 > https://www.ietf.org/mailman/listinfo/idr

___________________________________________________________________________=
______________________________________________

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

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


From nobody Thu Nov 17 11:14:45 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BC881294E8 for ; Thu, 17 Nov 2016 11:14:44 -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] 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 iysD4LLuVfMR for ; Thu, 17 Nov 2016 11:14:41 -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 B5157128DF6 for ; Thu, 17 Nov 2016 11:14:41 -0800 (PST)
Received: from 80-110-123-236.cgn.dynamic.surfer.at ([80.110.123.236] helo=[192.168.67.254]) by mail.hated.at with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1c7S0A-0002Q8-Cv; Thu, 17 Nov 2016 20:05:39 +0100
From: Christoph Loibl 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
Message-Id: 
Date: Thu, 17 Nov 2016 20:14:37 +0100
To: idr wg 
X-Mailer: Apple Mail (2.3251)
Archived-At: 
Cc: Danny McPherson , Christoph Loibl , Susan Hares , Robert Raszuk 
Subject: [Idr] New Version Notification for draft-hr-idr-rfc5575bis-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: Thu, 17 Nov 2016 19:14:44 -0000

Hi,

We submitted an updated version of our draft and are happy to receive =
feedback:

Name:		draft-hr-idr-rfc5575bis
Revision:	02
Title:		Dissemination of Flow Specification Rules
Document date:	2016-11-16
Group:		Individual Submission
Pages:		31
URL:            =
https://www.ietf.org/internet-drafts/draft-hr-idr-rfc5575bis-02.txt
Status:         =
https://datatracker.ietf.org/doc/draft-hr-idr-rfc5575bis/
Htmlized:       https://tools.ietf.org/html/draft-hr-idr-rfc5575bis-02
Diff:           =
https://www.ietf.org/rfcdiff?url2=3Ddraft-hr-idr-rfc5575bis-02

The draft is meant to replace RFC5575, to correct unclear specifications =
in the flow filter types, redefine (clarify) the traffic-redirect action =
and add a traffic-rate-packets action. It also provides originally =
missing rules for interfering traffic filtering actions and corrects =
many smaller errors found in RFC5575.

This is the output of may discussions regarding flow specification =
scaling, stability and of a multi-vendor interop test performed. We =
joined forces in order to address many/all of the issues found.

See the abstact below.

Christoph


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.


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


From nobody Thu Nov 17 15:44:35 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 785EB12955E for ; Thu, 17 Nov 2016 15:44:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.346
X-Spam-Level: **
X-Spam-Status: No, score=2.346 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 EDF9-1c049nc for ; Thu, 17 Nov 2016 15:44:32 -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 1B3321294FB for ; Thu, 17 Nov 2016 15:44:32 -0800 (PST)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=31.133.133.143; 
From: "Susan Hares" 
To: "'idr wg'" 
Date: Thu, 17 Nov 2016 18:41:41 -0500
Message-ID: <001201d2412c$30428d00$90c7a700$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01D24102.476DE490"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdJBLCV/S+pm775ZQ1GZqF929igoAA==
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com 
Archived-At: 
Subject: [Idr] draft-psarkar-idr-bgp-ls-node-admin-tag-extension - 1 week period to comment (11/17 - 11/24/2016)
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, 17 Nov 2016 23:44:33 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0013_01D24102.476DE490
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

IDR-WG:  

 

Mea culpa.  draft-psarkar-idr-bgp-ls-node-admin-tag-extension was accepted
during a WG LC call in 2015.  However, I forgot to ask for IPR (see threads
below).   Pushpasis asked the chairs (John and Sue) last April and we did
not answer him.   There is an IPR statement:

https://datatracker.ietf.org/ipr/2558/

 

Please consider the IPR statement.   Silence on the list means we will
accept the draft with the IPR. 

 

Sue Hares 

 

Thread refs:

https://www.ietf.org/mail-archive/web/idr/current/msg15213.html

https://www.ietf.org/mail-archive/web/idr/current/msg14888.html

 

 

 

 


------=_NextPart_000_0013_01D24102.476DE490
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


IDR-WG:  
 
Mea =
culpa.  draft-psarkar-idr-bgp-ls-node-admin-tag-extension was =
accepted during a WG LC call in 2015.  However, I forgot to ask for =
IPR (see threads below).   Pushpasis asked the chairs (John =
and Sue) last April and we did not answer him.   There is an =
IPR statement:
https://datatracker.ietf.=
org/ipr/2558/
 
Please =
consider the IPR statement.   Silence on the list means we =
will accept the draft with the IPR. 
 
Sue Hares =

 
Thread refs:
=
https://www.ietf.org/mail-archive/web/idr/current/msg15213.html<=
/o:p>
=
https://www.ietf.org/mail-archive/web/idr/current/msg14888.html<=
/o:p>
 
 
 
 

------=_NextPart_000_0013_01D24102.476DE490--


From nobody Thu Nov 17 15:56:12 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6090129570 for ; Thu, 17 Nov 2016 15:56:10 -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, 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 L4L0DSzfmSJj for ; Thu, 17 Nov 2016 15:56:08 -0800 (PST)
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0138.outbound.protection.outlook.com [104.47.37.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 D9082129530 for ; Thu, 17 Nov 2016 15:56:08 -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=Q2/g0cR9nuLjTCZMu0mJjv1BfTC+TWa+Y+Orc/VmZaI=; b=HqRdDQaHGyLndocBDuTPF5Es6w7Bkkbv4nasj8wJO7YcP7THsQ//riUEj6b2FnMa9vw3xaaw9o0+b3/Q/7rO2PEQF679+Qth8139YRl0PwEPBCbp681dLbmos4htuWOFOGBMU9lK9Z2jLOXgbLtGme3Zf/IkLkGlQHZQnIb+FSM=
Received: from CY1PR05MB2507.namprd05.prod.outlook.com (10.167.10.134) by CY1PR05MB2505.namprd05.prod.outlook.com (10.167.10.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.734.2; Thu, 17 Nov 2016 23:56:07 +0000
Received: from CY1PR05MB2507.namprd05.prod.outlook.com ([10.167.10.134]) by CY1PR05MB2507.namprd05.prod.outlook.com ([10.167.10.134]) with mapi id 15.01.0734.007; Thu, 17 Nov 2016 23:56:07 +0000
From: John Scudder 
To: Susan Hares 
Thread-Topic: draft-psarkar-idr-bgp-ls-node-admin-tag-extension - 1 week period to comment  (11/17 - 11/24/2016) 
Thread-Index: AdJBLCV/S+pm775ZQ1GZqF929igoAAAAgROw
Date: Thu, 17 Nov 2016 23:56:07 +0000
Message-ID: <03A099E0-D178-422D-B26E-07654EB49174@juniper.net>
References: <001201d2412c$30428d00$90c7a700$@ndzh.com>
In-Reply-To: <001201d2412c$30428d00$90c7a700$@ndzh.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [107.77.211.213]
x-microsoft-exchange-diagnostics: 1; CY1PR05MB2505; 7:+0chu78WX0CHMstVMnvGXa8NWtUyWUOpiaO9BA3tfhWiCk/6Ba092pQIyPIDfPhvgObtwSsMNCRxY+vIBhtx6umGqswSjL82BC0x86GobcMJggzipU7eQ8HQFAAarHzdnvc6odu2bA8qP1giJk6RYpm1Lsvs9c2rQ+JpztP8EuDPTDaULM2UsB7PvW30UtzGJYEaxG0LNJGe7jqal6kqlR0LOWPyZoMxUJ8sRtRQtJFzmmHwpKxrK42NhWptai5Ty1SC3gTGNN5Fi7+4QoCi7/JvyTGSzfEFGKjWnViO51Z31ch+i9+Ab48c6up5Gsxtd7PjzFTfKy6h4CDcLqwkQC7spkJhFNKWBNHuKgVQvGE=
x-ms-office365-filtering-correlation-id: 1c263be8-ed62-4b94-bf5d-08d40f454c6e
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR05MB2505;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(120809045254105);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040281)(6060326)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6061324)(6041223); SRVR:CY1PR05MB2505; BCL:0; PCL:0; RULEID:; SRVR:CY1PR05MB2505; 
x-forefront-prvs: 01294F875B
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(189002)(24454002)(5423002)(377454003)(199003)(2906002)(4326007)(3280700002)(230783001)(6116002)(3660700001)(36756003)(87936001)(790700001)(102836003)(6512003)(189998001)(83716003)(7906003)(122556002)(3846002)(606004)(7736002)(7846002)(6506003)(68736007)(82746002)(81156014)(110136003)(2950100002)(81166006)(33656002)(8676002)(77096005)(101416001)(99286002)(105586002)(86362001)(66066001)(6916009)(8936002)(229853002)(50986999)(106356001)(76176999)(2900100001)(97736004)(54356999)(92566002)(5660300001)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2505; H:CY1PR05MB2507.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_03A099E0D178422DB26E07654EB49174junipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Nov 2016 23:56:07.3547 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2505
Archived-At: 
Cc: idr wg 
Subject: Re: [Idr] draft-psarkar-idr-bgp-ls-node-admin-tag-extension - 1 week period to comment (11/17 - 11/24/2016)
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, 17 Nov 2016 23:56:11 -0000

--_000_03A099E0D178422DB26E07654EB49174junipernet_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

One thing to add: let's set a timeout of November 25.

--John

On Nov 18, 2016, at 8:44 AM, Susan Hares > wrote:

IDR-WG:

Mea culpa.  draft-psarkar-idr-bgp-ls-node-admin-tag-extension was accepted =
during a WG LC call in 2015.  However, I forgot to ask for IPR (see threads=
 below).   Pushpasis asked the chairs (John and Sue) last April and we did =
not answer him.   There is an IPR statement:
https://datatracker.ietf.org/ipr/2558/

Please consider the IPR statement.   Silence on the list means we will acce=
pt the draft with the IPR.

Sue Hares


Thread refs:

https://www.ietf.org/mail-archive/web/idr/current/msg15213.html

https://www.ietf.org/mail-archive/web/idr/current/msg14888.html








--_000_03A099E0D178422DB26E07654EB49174junipernet_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable









One thing to add: let's set a timeout of November 25. 







--John 




On Nov 18, 2016, at 8:44 AM, Susan Hares <shares@ndzh.com> wrote:














IDR-WG:  


 


Mea culpa.  draft-psarkar-idr-bgp-ls-node-admin=
-tag-extension was accepted during a WG LC call in 2015.  However, I f=
orgot to ask for IPR (see threads below).   Pushpasis asked the c=
hairs (John and Sue) last April and we did not answer
 him.   There is an IPR statement:


h=
ttps://datatracker.ietf.org/ipr/2558/


 


Please consider the IPR statement.   Silen=
ce on the list means we will accept the draft with the IPR.



 


Sue Hares 


 


Thread refs:


https://www.ietf.org/mail-archive/web/idr/curren=
t/msg15213.html


https://www.ietf.org/mail-archive/web/idr/curren=
t/msg14888.html


 


 


 


 










--_000_03A099E0D178422DB26E07654EB49174junipernet_--


From nobody Thu Nov 17 16:46:02 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 024E8128E18 for ; Thu, 17 Nov 2016 16:45:58 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable 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 7m7l-Xfjeeb9 for ; Thu, 17 Nov 2016 16:45:55 -0800 (PST)
Received: from mail-pg0-x242.google.com (mail-pg0-x242.google.com [IPv6:2607:f8b0:400e:c05::242]) (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 A49E812946F for ; Thu, 17 Nov 2016 16:45:55 -0800 (PST)
Received: by mail-pg0-x242.google.com with SMTP id e9so18540491pgc.1 for ; Thu, 17 Nov 2016 16:45:55 -0800 (PST)
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=8i0aBipOvBMRiWTPltti6vfADfRPEEc7Gx1ffi6/ib0=; b=Hv7Hj+FL2gmN+b5464f+u+6dOK362bXJyYsUSAyk9SCfIKmASpMeNE39aPCiMV2arZ ya0B0XdNkLmxP0GbogJOArjp3EU+HjXMLH2dNy9idSyZYBnRBtu7Iocr4aFpCdFfNIlc XWMG176zUL9CVfmA9eSEz0Q0wiKCgxqKvtGxbVghh4vEMoiBghS5eRZ2R/gF+9cUC2sn j6q/L8b7m0W8aIHtLT41FMTq6NkTcG2T1T3+lmXYby1O9Zhg2mIYwY7Eykf/NcA4I5P+ kMsoIAVuAQT+SBkkBJEKfyfPLsu6q24DvpKbGhC4nlBAJtXrAy0LCTjF69IFeEJe8H2+ lEcw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=8i0aBipOvBMRiWTPltti6vfADfRPEEc7Gx1ffi6/ib0=; b=jrZvGeSYULE9jlkFbUWUwVcbIGid2TSPdFP4h+WRbJ1n6yjXMz2dVkvYC0DlFYa7jE WoI2Eubby68egkyIJ3aQS+NplIZdX3YoLurFVbYHW5zgpKUqRtvzKgb2SZc/4QhUiBOk jV4RL7MUnz08dLwj857bDH8FTqrVMdf6Yt1kzD/U+Wehh86zlBe6NtKzd1Fh6bJqDJN2 YsxIAjrp6p7KnAfeJ2RiIMlIpSJfoOXEYWOb9IWPfifucX4jwrHhDuF2JNrqlndUwxFx 1fqQeCU3Y0EyVfIR8ZxZZPfvQjT12I5fJVTZiuTElv3TbPnqEGtK4urWy+FtfETFHiv1 OXKw==
X-Gm-Message-State: ABUngvc/H9wx5sDEWuk04hCt6Tf3V1kxW+Qw/HlNZpF//XmW9HWR+cF1WLpOFSwire40eQ==
X-Received: by 10.98.76.8 with SMTP id z8mr7957194pfa.167.1479429954538; Thu, 17 Nov 2016 16:45:54 -0800 (PST)
Received: from localhost ([2001:67c:370:144:b99e:f1c3:d062:489b]) by smtp.gmail.com with ESMTPSA id l11sm11173740pfb.28.2016.11.17.16.45.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Nov 2016 16:45:53 -0800 (PST)
Date: Fri, 18 Nov 2016 09:45:48 +0900
From: Job Snijders 
To: bruno.decraene@orange.com
Message-ID: <20161118004548.GK1072@dhcp-9341.meeting.ietf.org>
References: <20161116061556.GG1073@dhcp-9341.meeting.ietf.org> <20161117013640.GB6217@pfrc.org> <16426_1479400131_582DDAC3_16426_1669_1_53C29892C857584299CBF5D05346208A1EC87201@OPEXCNORM2F.corporate.adroot.infra.ftgroup>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <16426_1479400131_582DDAC3_16426_1669_1_53C29892C857584299CBF5D05346208A1EC87201@OPEXCNORM2F.corporate.adroot.infra.ftgroup>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.7.1 (2016-10-04)
Archived-At: 
Cc: "idr@ietf.org" , "grow@ietf.org" 
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 18 Nov 2016 00:45:58 -0000

On Thu, Nov 17, 2016 at 04:28:50PM +0000, bruno.decraene@orange.com wrote:
> I support the draft.
> I also support Jeff's idea to re-use existing sub-code(s).

Thanks for your support. Based on the feedback received so far the next
version of this draft will recycle Cease subcode 2.

> 1 possible comment: the length of the "Shutdown Communication" field
> seems implied from the length of the data field, rather than being
> explicitly indicated. 

The text is explicit about the length:

    "followed by a freeform UTF-8 encoded string with a REQUIRED maximum
    length of 128 octets. "

and further:

    "This document tries to minimize the effects of visual spoofing by
    allowing UNICODE only where local script is expected and needed, and
    by limiting the length of the Shutdown Communication."

> If so, it seems that we are closing the possibility to advertise
> additional data/usage, in some future. What about adding a TLV format?

I object to using a TLV. Don't forget this is already at a TLV level:
Cease NOTIFICATION. If one would want to define a TLV inside this TLV, a
new Cease subcode can be requested from IANA.

Kind regards,

Job


From nobody Fri Nov 18 00:32:26 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 664F41294C1; Fri, 18 Nov 2016 00:32:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.116
X-Spam-Level: 
X-Spam-Status: No, score=-4.116 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=-1.497, 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 F79MPn4Td2cR; Fri, 18 Nov 2016 00:32:22 -0800 (PST)
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 C459C12943F; Fri, 18 Nov 2016 00:32:21 -0800 (PST)
Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 1BB26202F7; Fri, 18 Nov 2016 09:32:20 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.72]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id DB5381A0067; Fri, 18 Nov 2016 09:32:19 +0100 (CET)
Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541%19]) with mapi id 14.03.0319.002; Fri, 18 Nov 2016 09:32:19 +0100
From: 
To: Job Snijders 
Thread-Topic: [GROW] [Idr] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
Thread-Index: AQHSQTUgzgPaS1LkJkWurev+wE+hi6DeaEhA
Date: Fri, 18 Nov 2016 08:32:19 +0000
Message-ID: <16418_1479457940_582EBC93_16418_290_1_53C29892C857584299CBF5D05346208A1EC8DEA5@OPEXCLILM21.corporate.adroot.infra.ftgroup>
References: <20161116061556.GG1073@dhcp-9341.meeting.ietf.org> <20161117013640.GB6217@pfrc.org> <16426_1479400131_582DDAC3_16426_1669_1_53C29892C857584299CBF5D05346208A1EC87201@OPEXCNORM2F.corporate.adroot.infra.ftgroup> <20161118004548.GK1072@dhcp-9341.meeting.ietf.org>
In-Reply-To: <20161118004548.GK1072@dhcp-9341.meeting.ietf.org>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.168.234.1]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: "idr@ietf.org" , "grow@ietf.org" 
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 18 Nov 2016 08:32:23 -0000

> From: Job Snijders [mailto:job@instituut.net]  > Sent: Friday, November 1=
8, 2016 1:46 AM
>=20
 > On Thu, Nov 17, 2016 at 04:28:50PM +0000, bruno.decraene@orange.com wrot=
e:
 > > I support the draft.
 > > I also support Jeff's idea to re-use existing sub-code(s).
 >=20
 > Thanks for your support. Based on the feedback received so far the next
 > version of this draft will recycle Cease subcode 2.
 >=20
 > > 1 possible comment: the length of the "Shutdown Communication" field
 > > seems implied from the length of the data field, rather than being
 > > explicitly indicated.
 >=20
 > The text is explicit about the length:
 >=20
 >     "followed by a freeform UTF-8 encoded string with a REQUIRED maximum
 >     length of 128 octets. "
 >=20
 > and further:
 >=20
 >     "This document tries to minimize the effects of visual spoofing by
 >     allowing UNICODE only where local script is expected and needed, and
 >     by limiting the length of the Shutdown Communication."
 >=20
 > > If so, it seems that we are closing the possibility to advertise
 > > additional data/usage, in some future. What about adding a TLV format?
 >=20
 > I object to using a TLV. Don't forget this is already at a TLV level:
 > Cease NOTIFICATION. If one would want to define a TLV inside this TLV, a
 > new Cease subcode can be requested from IANA.

What if someone needs to advertise additional info to an existing cease sub=
code? cf Jeff's email regarding the pain of changing subcodes.
So let's forget about the TLV. What about just adding the length of the str=
ing? This would still allow adding fields after the string, while having a =
negligible/null cost?

Kind regards,
-- Bruno=20

 > Kind regards,
 >=20
 > Job

___________________________________________________________________________=
______________________________________________

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

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


From nobody Fri Nov 18 00:46:16 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 959BE12953C for ; Fri, 18 Nov 2016 00:46:11 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 7qXc_yJ_JFQs for ; Fri, 18 Nov 2016 00:46:09 -0800 (PST)
Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::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 B62AD1295B4 for ; Fri, 18 Nov 2016 00:46:08 -0800 (PST)
Received: by mail-oi0-x231.google.com with SMTP id z62so81845673oiz.1 for ; Fri, 18 Nov 2016 00:46:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4BllRRNqRIl/G1itSmRKxAjOoxrdbELguU4Bbl/ZmW4=; b=iaOGjq3etFPf4RQPNBfIs/YsyMGa26ShnN1/+AyJyZAX1bbKX7B2+djF/nYd0yHGgm 9+YKAl1M2P/Rpmff/RsSWtU27MnkCdcm/G8eoDObYI/QIAkPDRQRxhpxDiwOzxutr9qq Zui1hr+qoxa9+BtjuZB+K3SkA+2ejgsMVMU8OM0BFAExWuKMnRNqS4Xy7HK1OyOVHGN8 mwfrah4Yjl29qsrfZEOWY24xZll6w5KhacLcx7+cMG8n02Eu4EsaBdPM/LcMQ8Nm/nl+ EQyD0zu92y7dmWoU2ETBAFuZq/YIS1lmJCEjDyXyh5Sb8/zgU/DoX6NxsylzVGxUGF2k xVmg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4BllRRNqRIl/G1itSmRKxAjOoxrdbELguU4Bbl/ZmW4=; b=QpHsiaCkB51xgGqO+Yp5D1lkmouv0z6Hn802T1FNxcZ9DCOeMcN1iDMuOIkEYt4l1v 7u2GsxX2ov02TuEfAnKYFf0FRqalIUDd7StAHYDNiA47srthRb1EnNsuvPJSVCeAcRhw UEsitg1rINpVYnylYKx9j+hmduVZPNH3o7HEPxh8QE6q+YQJH9MkiCqE8eci7UI9ECCL ZkLYApKgptzWHodUw89AEP74gyQYB4fVjRMwURRL+RxztMRDjpFP0jNtQ7biX0f0hWjb xDzxO9bBXv5ppX5g2tkG5egi8UL1HFqrZJFAR0P9gE+jY50KOzpw5AB74FpplPAbviGz zwtw==
X-Gm-Message-State: AKaTC03i3pamVr9gCGMb1y5jeVmys6d9DVsBzIcRdkT5dqeQ4T3VCWyK/KWX58FJVXGSGssshu7cOBlPp3HPFw==
X-Received: by 10.157.48.112 with SMTP id w45mr4080489otd.198.1479458767975; Fri, 18 Nov 2016 00:46:07 -0800 (PST)
MIME-Version: 1.0
References: <20161116061556.GG1073@dhcp-9341.meeting.ietf.org> <20161117013640.GB6217@pfrc.org> <16426_1479400131_582DDAC3_16426_1669_1_53C29892C857584299CBF5D05346208A1EC87201@OPEXCNORM2F.corporate.adroot.infra.ftgroup> <20161118004548.GK1072@dhcp-9341.meeting.ietf.org> <16418_1479457940_582EBC93_16418_290_1_53C29892C857584299CBF5D05346208A1EC8DEA5@OPEXCLILM21.corporate.adroot.infra.ftgroup>
In-Reply-To: <16418_1479457940_582EBC93_16418_290_1_53C29892C857584299CBF5D05346208A1EC8DEA5@OPEXCLILM21.corporate.adroot.infra.ftgroup>
From: Job Snijders 
Date: Fri, 18 Nov 2016 08:45:56 +0000
Message-ID: 
To: bruno.decraene@orange.com
Content-Type: multipart/alternative; boundary=001a1141f8705345a405418f5679
Archived-At: 
Cc: "idr@ietf.org" , "grow@ietf.org" 
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 18 Nov 2016 08:46:11 -0000

--001a1141f8705345a405418f5679
Content-Type: text/plain; charset=UTF-8

Hi Bruno,

John Scudder was kind enough to provide extensive argumentation offlist on
why something along these lines should be done. We'll work on a proposal.
The length indicator is a neat idea, thanks for sharing.

Job

On Fri, 18 Nov 2016 at 17:32,  wrote:

>
>
> > From: Job Snijders [mailto:job@instituut.net]  > Sent: Friday, November
> 18, 2016 1:46 AM
> >
>  > On Thu, Nov 17, 2016 at 04:28:50PM +0000, bruno.decraene@orange.com
> wrote:
>  > > I support the draft.
>  > > I also support Jeff's idea to re-use existing sub-code(s).
>  >
>  > Thanks for your support. Based on the feedback received so far the next
>  > version of this draft will recycle Cease subcode 2.
>  >
>  > > 1 possible comment: the length of the "Shutdown Communication" field
>  > > seems implied from the length of the data field, rather than being
>  > > explicitly indicated.
>  >
>  > The text is explicit about the length:
>  >
>  >     "followed by a freeform UTF-8 encoded string with a REQUIRED maximum
>  >     length of 128 octets. "
>  >
>  > and further:
>  >
>  >     "This document tries to minimize the effects of visual spoofing by
>  >     allowing UNICODE only where local script is expected and needed, and
>  >     by limiting the length of the Shutdown Communication."
>  >
>  > > If so, it seems that we are closing the possibility to advertise
>  > > additional data/usage, in some future. What about adding a TLV format?
>  >
>  > I object to using a TLV. Don't forget this is already at a TLV level:
>  > Cease NOTIFICATION. If one would want to define a TLV inside this TLV, a
>  > new Cease subcode can be requested from IANA.
>
> What if someone needs to advertise additional info to an existing cease
> subcode? cf Jeff's email regarding the pain of changing subcodes.
> So let's forget about the TLV. What about just adding the length of the
> string? This would still allow adding fields after the string, while having
> a negligible/null cost?
>
> Kind regards,
> -- Bruno
>
>  > Kind regards,
>  >
>  > Job
>
>
> _________________________________________________________________________________________________________________________
>
> 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.
>
>

--001a1141f8705345a405418f5679
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Bruno,

John Scudder was kind =
enough to provide extensive argumentation offlist on why something along th=
ese lines  should be done. We'll work on a proposal. The length indicat=
or is a neat idea, thanks for sharing. 

Job

On Fri, 18 Nov 2016 at 17:32, <bruno.decraene@orange.com> wrote:




> From: Job Snijders [mailto:job@instituut.net]=C2=A0 > Sent: Fr=
iday, November 18, 2016 1:46 AM

>

=C2=A0> On Thu, Nov 17, 2016 at 04:28:50PM +0000, bruno.decraene=
@orange.com wrote:

=C2=A0> > I support the draft.

=C2=A0> > I also support Jeff's idea to re-use existing sub-code(=
s).

=C2=A0>

=C2=A0> Thanks for your support. Based on the feedback received so far t=
he next

=C2=A0> version of this draft will recycle Cease subcode 2.

=C2=A0>

=C2=A0> > 1 possible comment: the length of the "Shutdown Commun=
ication" field

=C2=A0> > seems implied from the length of the data field, rather tha=
n being

=C2=A0> > explicitly indicated.

=C2=A0>

=C2=A0> The text is explicit about the length:

=C2=A0>

=C2=A0>=C2=A0 =C2=A0 =C2=A0"followed by a freeform UTF-8 encoded st=
ring with a REQUIRED maximum

=C2=A0>=C2=A0 =C2=A0 =C2=A0length of 128 octets. "

=C2=A0>

=C2=A0> and further:

=C2=A0>

=C2=A0>=C2=A0 =C2=A0 =C2=A0"This document tries to minimize the eff=
ects of visual spoofing by

=C2=A0>=C2=A0 =C2=A0 =C2=A0allowing UNICODE only where local script is e=
xpected and needed, and

=C2=A0>=C2=A0 =C2=A0 =C2=A0by limiting the length of the Shutdown Commun=
ication."

=C2=A0>

=C2=A0> > If so, it seems that we are closing the possibility to adve=
rtise

=C2=A0> > additional data/usage, in some future. What about adding a =
TLV format?

=C2=A0>

=C2=A0> I object to using a TLV. Don't forget this is already at a T=
LV level:

=C2=A0> Cease NOTIFICATION. If one would want to define a TLV inside thi=
s TLV, a

=C2=A0> new Cease subcode can be requested from IANA.



What if someone needs to advertise additional info to an existing cease sub=
code? cf Jeff's email regarding the pain of changing subcodes.

So let's forget about the TLV. What about just adding the length of the=
 string? This would still allow adding fields after the string, while havin=
g a negligible/null cost?



Kind regards,

-- Bruno



=C2=A0> Kind regards,

=C2=A0>

=C2=A0> Job



___________________________________________________________________________=
______________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les message=
s electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.



This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and dele=
te this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.

Thank you.






--001a1141f8705345a405418f5679--


From nobody Fri Nov 18 00:52:19 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2E741295CE; Fri, 18 Nov 2016 00:52:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.415
X-Spam-Level: 
X-Spam-Status: No, score=-3.415 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, 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 OhBKUpW5rVWl; Fri, 18 Nov 2016 00:52:16 -0800 (PST)
Received: from relais-inet.orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E974B1294CF; Fri, 18 Nov 2016 00:52:15 -0800 (PST)
Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 76FD31200E4; Fri, 18 Nov 2016 09:52:14 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.3]) by opfedar05.francetelecom.fr (ESMTP service) with ESMTP id 4741960060; Fri, 18 Nov 2016 09:52:14 +0100 (CET)
Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM5D.corporate.adroot.infra.ftgroup ([fe80::9898:741c:bc1d:258d%19]) with mapi id 14.03.0319.002; Fri, 18 Nov 2016 09:52:13 +0100
From: 
To: Job Snijders 
Thread-Topic: [GROW] [Idr] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
Thread-Index: AQHSQXg2KbFzYan870q9OfXmWDMsk6Debx7Q
Date: Fri, 18 Nov 2016 08:52:12 +0000
Message-ID: <13357_1479459134_582EC13E_13357_5786_1_53C29892C857584299CBF5D05346208A1EC8FF18@OPEXCLILM21.corporate.adroot.infra.ftgroup>
References: <20161116061556.GG1073@dhcp-9341.meeting.ietf.org> <20161117013640.GB6217@pfrc.org> <16426_1479400131_582DDAC3_16426_1669_1_53C29892C857584299CBF5D05346208A1EC87201@OPEXCNORM2F.corporate.adroot.infra.ftgroup> <20161118004548.GK1072@dhcp-9341.meeting.ietf.org> <16418_1479457940_582EBC93_16418_290_1_53C29892C857584299CBF5D05346208A1EC8DEA5@OPEXCLILM21.corporate.adroot.infra.ftgroup> 
In-Reply-To: 
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.168.234.1]
Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A1EC8FF18OPEXCLILM21corp_"
MIME-Version: 1.0
Archived-At: 
Cc: "idr@ietf.org" , "grow@ietf.org" 
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 18 Nov 2016 08:52:18 -0000

--_000_53C29892C857584299CBF5D05346208A1EC8FF18OPEXCLILM21corp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VGhhbmtzLg0KLS1CcnVubw0KDQpGcm9tOiBKb2IgU25pamRlcnMgW21haWx0bzpqb2JAaW5zdGl0
dXV0Lm5ldF0NClNlbnQ6IEZyaWRheSwgTm92ZW1iZXIgMTgsIDIwMTYgOTo0NiBBTQ0KVG86IERF
Q1JBRU5FIEJydW5vIElNVC9PTE4NCkNjOiBKZWZmcmV5IEhhYXM7IEpvYiBTbmlqZGVyczsgZ3Jv
d0BpZXRmLm9yZzsgaWRyQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0dST1ddIFtJZHJdIGRyYWZ0
LXNuaWpkZXJzLWlkci1zaHV0ZG93bi0wMDogRHJvcCBhIGxpbmUgaW4gdGhlIHBlZXIncyBzeXNs
b2cgYXQgc2h1dGRvd24NCg0KSGkgQnJ1bm8sDQoNCkpvaG4gU2N1ZGRlciB3YXMga2luZCBlbm91
Z2ggdG8gcHJvdmlkZSBleHRlbnNpdmUgYXJndW1lbnRhdGlvbiBvZmZsaXN0IG9uIHdoeSBzb21l
dGhpbmcgYWxvbmcgdGhlc2UgbGluZXMgc2hvdWxkIGJlIGRvbmUuIFdlJ2xsIHdvcmsgb24gYSBw
cm9wb3NhbC4gVGhlIGxlbmd0aCBpbmRpY2F0b3IgaXMgYSBuZWF0IGlkZWEsIHRoYW5rcyBmb3Ig
c2hhcmluZy4NCg0KSm9iDQoNCk9uIEZyaSwgMTggTm92IDIwMTYgYXQgMTc6MzIsIDxicnVuby5k
ZWNyYWVuZUBvcmFuZ2UuY29tPG1haWx0bzpicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tPj4gd3Jv
dGU6DQoNCg0KPiBGcm9tOiBKb2IgU25pamRlcnMgW21haWx0bzpqb2JAaW5zdGl0dXV0Lm5ldDxt
YWlsdG86am9iQGluc3RpdHV1dC5uZXQ+XSAgPiBTZW50OiBGcmlkYXksIE5vdmVtYmVyIDE4LCAy
MDE2IDE6NDYgQU0NCj4NCiA+IE9uIFRodSwgTm92IDE3LCAyMDE2IGF0IDA0OjI4OjUwUE0gKzAw
MDAsIGJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb208bWFpbHRvOmJydW5vLmRlY3JhZW5lQG9yYW5n
ZS5jb20+IHdyb3RlOg0KID4gPiBJIHN1cHBvcnQgdGhlIGRyYWZ0Lg0KID4gPiBJIGFsc28gc3Vw
cG9ydCBKZWZmJ3MgaWRlYSB0byByZS11c2UgZXhpc3Rpbmcgc3ViLWNvZGUocykuDQogPg0KID4g
VGhhbmtzIGZvciB5b3VyIHN1cHBvcnQuIEJhc2VkIG9uIHRoZSBmZWVkYmFjayByZWNlaXZlZCBz
byBmYXIgdGhlIG5leHQNCiA+IHZlcnNpb24gb2YgdGhpcyBkcmFmdCB3aWxsIHJlY3ljbGUgQ2Vh
c2Ugc3ViY29kZSAyLg0KID4NCiA+ID4gMSBwb3NzaWJsZSBjb21tZW50OiB0aGUgbGVuZ3RoIG9m
IHRoZSAiU2h1dGRvd24gQ29tbXVuaWNhdGlvbiIgZmllbGQNCiA+ID4gc2VlbXMgaW1wbGllZCBm
cm9tIHRoZSBsZW5ndGggb2YgdGhlIGRhdGEgZmllbGQsIHJhdGhlciB0aGFuIGJlaW5nDQogPiA+
IGV4cGxpY2l0bHkgaW5kaWNhdGVkLg0KID4NCiA+IFRoZSB0ZXh0IGlzIGV4cGxpY2l0IGFib3V0
IHRoZSBsZW5ndGg6DQogPg0KID4gICAgICJmb2xsb3dlZCBieSBhIGZyZWVmb3JtIFVURi04IGVu
Y29kZWQgc3RyaW5nIHdpdGggYSBSRVFVSVJFRCBtYXhpbXVtDQogPiAgICAgbGVuZ3RoIG9mIDEy
OCBvY3RldHMuICINCiA+DQogPiBhbmQgZnVydGhlcjoNCiA+DQogPiAgICAgIlRoaXMgZG9jdW1l
bnQgdHJpZXMgdG8gbWluaW1pemUgdGhlIGVmZmVjdHMgb2YgdmlzdWFsIHNwb29maW5nIGJ5DQog
PiAgICAgYWxsb3dpbmcgVU5JQ09ERSBvbmx5IHdoZXJlIGxvY2FsIHNjcmlwdCBpcyBleHBlY3Rl
ZCBhbmQgbmVlZGVkLCBhbmQNCiA+ICAgICBieSBsaW1pdGluZyB0aGUgbGVuZ3RoIG9mIHRoZSBT
aHV0ZG93biBDb21tdW5pY2F0aW9uLiINCiA+DQogPiA+IElmIHNvLCBpdCBzZWVtcyB0aGF0IHdl
IGFyZSBjbG9zaW5nIHRoZSBwb3NzaWJpbGl0eSB0byBhZHZlcnRpc2UNCiA+ID4gYWRkaXRpb25h
bCBkYXRhL3VzYWdlLCBpbiBzb21lIGZ1dHVyZS4gV2hhdCBhYm91dCBhZGRpbmcgYSBUTFYgZm9y
bWF0Pw0KID4NCiA+IEkgb2JqZWN0IHRvIHVzaW5nIGEgVExWLiBEb24ndCBmb3JnZXQgdGhpcyBp
cyBhbHJlYWR5IGF0IGEgVExWIGxldmVsOg0KID4gQ2Vhc2UgTk9USUZJQ0FUSU9OLiBJZiBvbmUg
d291bGQgd2FudCB0byBkZWZpbmUgYSBUTFYgaW5zaWRlIHRoaXMgVExWLCBhDQogPiBuZXcgQ2Vh
c2Ugc3ViY29kZSBjYW4gYmUgcmVxdWVzdGVkIGZyb20gSUFOQS4NCg0KV2hhdCBpZiBzb21lb25l
IG5lZWRzIHRvIGFkdmVydGlzZSBhZGRpdGlvbmFsIGluZm8gdG8gYW4gZXhpc3RpbmcgY2Vhc2Ug
c3ViY29kZT8gY2YgSmVmZidzIGVtYWlsIHJlZ2FyZGluZyB0aGUgcGFpbiBvZiBjaGFuZ2luZyBz
dWJjb2Rlcy4NClNvIGxldCdzIGZvcmdldCBhYm91dCB0aGUgVExWLiBXaGF0IGFib3V0IGp1c3Qg
YWRkaW5nIHRoZSBsZW5ndGggb2YgdGhlIHN0cmluZz8gVGhpcyB3b3VsZCBzdGlsbCBhbGxvdyBh
ZGRpbmcgZmllbGRzIGFmdGVyIHRoZSBzdHJpbmcsIHdoaWxlIGhhdmluZyBhIG5lZ2xpZ2libGUv
bnVsbCBjb3N0Pw0KDQpLaW5kIHJlZ2FyZHMsDQotLSBCcnVubw0KDQogPiBLaW5kIHJlZ2FyZHMs
DQogPg0KID4gSm9iDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18NCg0KQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50
ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBw
cml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jDQpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9p
dGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVz
c2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcg0KYSBsJ2V4cGVkaXRldXIgZXQg
bGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVs
ZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwNCk9yYW5nZSBkZWNs
aW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZv
cm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVu
dHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhh
dCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsNCnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRl
ZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KSWYgeW91IGhhdmUgcmVj
ZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBk
ZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQpBcyBlbWFpbHMgbWF5IGJl
IGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVl
biBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQpUaGFuayB5b3UuDQoKX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoK
Q2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5m
b3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBk
b25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0
aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxl
IHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGll
Y2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxl
cyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNl
IG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMg
bWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBw
cml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkg
c2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jp
c2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ug
bm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2ht
ZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3Ig
bWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpU
aGFuayB5b3UuCgo=

--_000_53C29892C857584299CBF5D05346208A1EC8FF18OPEXCLILM21corp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ
e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov
KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z
b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp
emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps
aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6
Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I
eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl
Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv
LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z
LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10
eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ
bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6
NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0
O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48
IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw
aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht
bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk
YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0K
PGJvZHkgbGFuZz0iRlIiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i
V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5
N0QiPi0tQnJ1bm88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg
Ymx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxl
PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw
dCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4g
Sm9iIFNuaWpkZXJzIFttYWlsdG86am9iQGluc3RpdHV1dC5uZXRdDQo8YnI+DQo8Yj5TZW50Ojwv
Yj4gRnJpZGF5LCBOb3ZlbWJlciAxOCwgMjAxNiA5OjQ2IEFNPGJyPg0KPGI+VG86PC9iPiBERUNS
QUVORSBCcnVubyBJTVQvT0xOPGJyPg0KPGI+Q2M6PC9iPiBKZWZmcmV5IEhhYXM7IEpvYiBTbmlq
ZGVyczsgZ3Jvd0BpZXRmLm9yZzsgaWRyQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl
OiBbR1JPV10gW0lkcl0gZHJhZnQtc25pamRlcnMtaWRyLXNodXRkb3duLTAwOiBEcm9wIGEgbGlu
ZSBpbiB0aGUgcGVlcidzIHN5c2xvZyBhdCBzaHV0ZG93bjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv
cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBCcnVubyw8YnI+DQo8YnI+DQpKb2hu
IFNjdWRkZXIgd2FzIGtpbmQgZW5vdWdoIHRvIHByb3ZpZGUgZXh0ZW5zaXZlIGFyZ3VtZW50YXRp
b24gb2ZmbGlzdCBvbiB3aHkgc29tZXRoaW5nIGFsb25nIHRoZXNlIGxpbmVzIHNob3VsZCBiZSBk
b25lLiBXZSdsbCB3b3JrIG9uIGEgcHJvcG9zYWwuIFRoZSBsZW5ndGggaW5kaWNhdG9yIGlzIGEg
bmVhdCBpZGVhLCB0aGFua3MgZm9yIHNoYXJpbmcuDQo8YnI+DQo8YnI+DQpKb2I8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZyaSwgMTggTm92IDIwMTYg
YXQgMTc6MzIsICZsdDs8YSBocmVmPSJtYWlsdG86YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbSI+
YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg
I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0
O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i
b3R0b206MTIuMHB0Ij48YnI+DQo8YnI+DQomZ3Q7IEZyb206IEpvYiBTbmlqZGVycyBbbWFpbHRv
OjxhIGhyZWY9Im1haWx0bzpqb2JAaW5zdGl0dXV0Lm5ldCIgdGFyZ2V0PSJfYmxhbmsiPmpvYkBp
bnN0aXR1dXQubmV0PC9hPl0mbmJzcDsgJmd0OyBTZW50OiBGcmlkYXksIE5vdmVtYmVyIDE4LCAy
MDE2IDE6NDYgQU08YnI+DQomZ3Q7PGJyPg0KJm5ic3A7Jmd0OyBPbiBUaHUsIE5vdiAxNywgMjAx
NiBhdCAwNDoyODo1MFBNICYjNDM7MDAwMCwgPGEgaHJlZj0ibWFpbHRvOmJydW5vLmRlY3JhZW5l
QG9yYW5nZS5jb20iIHRhcmdldD0iX2JsYW5rIj4NCmJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb208
L2E+IHdyb3RlOjxicj4NCiZuYnNwOyZndDsgJmd0OyBJIHN1cHBvcnQgdGhlIGRyYWZ0Ljxicj4N
CiZuYnNwOyZndDsgJmd0OyBJIGFsc28gc3VwcG9ydCBKZWZmJ3MgaWRlYSB0byByZS11c2UgZXhp
c3Rpbmcgc3ViLWNvZGUocykuPGJyPg0KJm5ic3A7Jmd0Ozxicj4NCiZuYnNwOyZndDsgVGhhbmtz
IGZvciB5b3VyIHN1cHBvcnQuIEJhc2VkIG9uIHRoZSBmZWVkYmFjayByZWNlaXZlZCBzbyBmYXIg
dGhlIG5leHQ8YnI+DQombmJzcDsmZ3Q7IHZlcnNpb24gb2YgdGhpcyBkcmFmdCB3aWxsIHJlY3lj
bGUgQ2Vhc2Ugc3ViY29kZSAyLjxicj4NCiZuYnNwOyZndDs8YnI+DQombmJzcDsmZ3Q7ICZndDsg
MSBwb3NzaWJsZSBjb21tZW50OiB0aGUgbGVuZ3RoIG9mIHRoZSAmcXVvdDtTaHV0ZG93biBDb21t
dW5pY2F0aW9uJnF1b3Q7IGZpZWxkPGJyPg0KJm5ic3A7Jmd0OyAmZ3Q7IHNlZW1zIGltcGxpZWQg
ZnJvbSB0aGUgbGVuZ3RoIG9mIHRoZSBkYXRhIGZpZWxkLCByYXRoZXIgdGhhbiBiZWluZzxicj4N
CiZuYnNwOyZndDsgJmd0OyBleHBsaWNpdGx5IGluZGljYXRlZC48YnI+DQombmJzcDsmZ3Q7PGJy
Pg0KJm5ic3A7Jmd0OyBUaGUgdGV4dCBpcyBleHBsaWNpdCBhYm91dCB0aGUgbGVuZ3RoOjxicj4N
CiZuYnNwOyZndDs8YnI+DQombmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsmcXVvdDtmb2xs
b3dlZCBieSBhIGZyZWVmb3JtIFVURi04IGVuY29kZWQgc3RyaW5nIHdpdGggYSBSRVFVSVJFRCBt
YXhpbXVtPGJyPg0KJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7bGVuZ3RoIG9mIDEyOCBv
Y3RldHMuICZxdW90Ozxicj4NCiZuYnNwOyZndDs8YnI+DQombmJzcDsmZ3Q7IGFuZCBmdXJ0aGVy
Ojxicj4NCiZuYnNwOyZndDs8YnI+DQombmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsmcXVv
dDtUaGlzIGRvY3VtZW50IHRyaWVzIHRvIG1pbmltaXplIHRoZSBlZmZlY3RzIG9mIHZpc3VhbCBz
cG9vZmluZyBieTxicj4NCiZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO2FsbG93aW5nIFVO
SUNPREUgb25seSB3aGVyZSBsb2NhbCBzY3JpcHQgaXMgZXhwZWN0ZWQgYW5kIG5lZWRlZCwgYW5k
PGJyPg0KJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7YnkgbGltaXRpbmcgdGhlIGxlbmd0
aCBvZiB0aGUgU2h1dGRvd24gQ29tbXVuaWNhdGlvbi4mcXVvdDs8YnI+DQombmJzcDsmZ3Q7PGJy
Pg0KJm5ic3A7Jmd0OyAmZ3Q7IElmIHNvLCBpdCBzZWVtcyB0aGF0IHdlIGFyZSBjbG9zaW5nIHRo
ZSBwb3NzaWJpbGl0eSB0byBhZHZlcnRpc2U8YnI+DQombmJzcDsmZ3Q7ICZndDsgYWRkaXRpb25h
bCBkYXRhL3VzYWdlLCBpbiBzb21lIGZ1dHVyZS4gV2hhdCBhYm91dCBhZGRpbmcgYSBUTFYgZm9y
bWF0Pzxicj4NCiZuYnNwOyZndDs8YnI+DQombmJzcDsmZ3Q7IEkgb2JqZWN0IHRvIHVzaW5nIGEg
VExWLiBEb24ndCBmb3JnZXQgdGhpcyBpcyBhbHJlYWR5IGF0IGEgVExWIGxldmVsOjxicj4NCiZu
YnNwOyZndDsgQ2Vhc2UgTk9USUZJQ0FUSU9OLiBJZiBvbmUgd291bGQgd2FudCB0byBkZWZpbmUg
YSBUTFYgaW5zaWRlIHRoaXMgVExWLCBhPGJyPg0KJm5ic3A7Jmd0OyBuZXcgQ2Vhc2Ugc3ViY29k
ZSBjYW4gYmUgcmVxdWVzdGVkIGZyb20gSUFOQS48YnI+DQo8YnI+DQpXaGF0IGlmIHNvbWVvbmUg
bmVlZHMgdG8gYWR2ZXJ0aXNlIGFkZGl0aW9uYWwgaW5mbyB0byBhbiBleGlzdGluZyBjZWFzZSBz
dWJjb2RlPyBjZiBKZWZmJ3MgZW1haWwgcmVnYXJkaW5nIHRoZSBwYWluIG9mIGNoYW5naW5nIHN1
YmNvZGVzLjxicj4NClNvIGxldCdzIGZvcmdldCBhYm91dCB0aGUgVExWLiBXaGF0IGFib3V0IGp1
c3QgYWRkaW5nIHRoZSBsZW5ndGggb2YgdGhlIHN0cmluZz8gVGhpcyB3b3VsZCBzdGlsbCBhbGxv
dyBhZGRpbmcgZmllbGRzIGFmdGVyIHRoZSBzdHJpbmcsIHdoaWxlIGhhdmluZyBhIG5lZ2xpZ2li
bGUvbnVsbCBjb3N0Pzxicj4NCjxicj4NCktpbmQgcmVnYXJkcyw8YnI+DQotLSBCcnVubzxicj4N
Cjxicj4NCiZuYnNwOyZndDsgS2luZCByZWdhcmRzLDxicj4NCiZuYnNwOyZndDs8YnI+DQombmJz
cDsmZ3Q7IEpvYjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQo8YnI+DQpDZSBtZXNzYWdlIGV0IHNl
cyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlk
ZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmM8YnI+DQpwYXMgZXRy
ZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91
cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcjxi
cj4NCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpv
aW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2Fs
dGVyYXRpb24sPGJyPg0KT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2Ug
bWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLjxicj4NCjxi
cj4NClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVu
dGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBs
YXc7PGJyPg0KdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3
aXRob3V0IGF1dGhvcmlzYXRpb24uPGJyPg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFp
bCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNz
YWdlIGFuZCBpdHMgYXR0YWNobWVudHMuPGJyPg0KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBP
cmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQs
IGNoYW5nZWQgb3IgZmFsc2lmaWVkLjxicj4NClRoYW5rIHlvdS48bzpwPjwvbzpwPjwvcD4NCjwv
YmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxQUkU+X19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVz
c2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRp
b25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBh
cyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBT
aSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25h
bGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpv
aW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2Fs
dGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3Nh
Z2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2Fn
ZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxl
Z2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxk
IG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9u
LgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5
IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4K
QXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2Fn
ZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5
b3UuCjwvUFJFPjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_53C29892C857584299CBF5D05346208A1EC8FF18OPEXCLILM21corp_--


From nobody Fri Nov 18 03:07:48 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C22E129641 for ; Fri, 18 Nov 2016 03:07:46 -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, 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] 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 W0lPPo6qP9kj for ; Fri, 18 Nov 2016 03:07:43 -0800 (PST)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0112.outbound.protection.outlook.com [104.47.1.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 715D21296B5 for ; Fri, 18 Nov 2016 03:07:42 -0800 (PST)
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=LWCbxHtpuIeBh6HX2rWzQzP/KgVs4HiEO02Wp8/4LCM=; b=M3RrGBkArTIYBzXp4Lubuzk0bxtNlLiKTMJyAqEAGYythVjZGPPzwRUAKvaGpACjP3kYZvO0Y0eWshG9/n21vNX+hJknmvTn2Ba5A+v/b7fK4LglB+Lir9nxszUBEdaFzfr8Lte4BeKO1KSd9cd/sXbE01TNBB37jS3hSWkMF1Q=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
Received: from pc6 (81.135.210.62) by HE1PR0701MB3003.eurprd07.prod.outlook.com (10.168.93.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.734.2; Fri, 18 Nov 2016 11:07:39 +0000
Message-ID: <004201d2418b$887208c0$4001a8c0@gateway.2wire.net>
From: t.petch 
To: "John G. Scudder" , idr wg 
References:   <27701_1479159582_582A2F1E_27701_6903_1_53C29892C857584299CBF5D05346208A1EC77FE1@OPEXCLILM21.corporate.adroot.infra.ftgroup> <736EA2CC-3DD1-4F14-96ED-2916E62F6F02@cisco.com> <26709_1479217575_582B11A7_26709_12999_1_53C29892C857584299CBF5D05346208A1EC79584@OPEXCLILM21.corporate.adroot.infra.ftgroup>   <20161116001246.GB27230@pfrc.org> <4EB6222D-86A4-4A83-AF8C-364CB52B8422@juniper.net>
Date: Fri, 18 Nov 2016 10:58:23 +0000
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: [81.135.210.62]
X-ClientProxiedBy: DB5PR09CA0013.eurprd09.prod.outlook.com (10.161.191.23) To HE1PR0701MB3003.eurprd07.prod.outlook.com (10.168.93.137)
X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3003; 2:ooVew4bFXuJTuDsWh+nKUkVtQsJVxaAhe4HQK5NFAGHeTQksS6/IJV9gXyGEQ+obgj6TdFSD234jwUy12y3dhCOINST82xn/0zhOGP4xznvAu67il4kBbD/J9Vx/CkP0wWbiBUn+Pey+HrPgb9Z8rTnfWfOcYlCcGkEYRGl0sUU=; 3:l4NtTS+LFApZY2+t4LPYDLo9NY36zP5jos3vRA3J/vb2R/uvIyDZJzfiTOG8rNUF/HwS3mVf77AuCc67AAuS6nRMhNE/wxC6P6XOI+pyShWgeCqqAJbSzfNaITfe+r/AaGcy1wsfknSD4AgcDe8BvvUPBb4jFVxIHXH3sPnRjsE=
X-MS-Office365-Filtering-Correlation-Id: c0fa4029-f204-4634-b151-08d40fa31cb8
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:HE1PR0701MB3003; 
X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3003; 25:HWRv6SbhyNL2zL/pBVP39lkLoWLT7CYUDBNmvQU73wLU4myzQkA+hVwCBwHuejBs6GuHEZgmPBvrFpD/xOGT0NnBbtJo2prozhFZB70mqGoegntz8pTqn6M+ctIutdQ8AfRHnxWoRy3DsyZfY0NdNP0ii6aDBbbiUZYGxHPG/la9BS0HOfOMqi3QVpSfdd03RS3ZiGfCmSJbF/RHULpES0aX8DUb1i4WbuMHXHyLjiCFslez8sMM8G9lsARTnGq/6AwUL88k+AVSiFFdCLjWSi5oMM54u14eLzE46tBPlEnwTF41E17Vq7WGc5BhB0igP6HeHp7RpHHUH/4gGLL74eI4aX23Dguyr3AUSNLQUyAeyfshPXanieXOF1giGGRJCcfwfs5+kPRsc0HMoy57vDIalT7IsCHtJEM87S8Z0MhV7q+CbauSXSSVmn7oYyRmsgz1L0w1fbr1SE7y51ITIyVnleOVnfu9FGKi3C+/9ECV8wSpUHDJv4qzD3idmZP5sXkMkwpTtdK5qxaga9ac0qwI5C6gVM29laZTyTpp70h76/EGeFZno5OEMMn6Y32yORBNPMsK8Yun2Z3QiTxjWmKm5LDpOGcCn0iIthE3D7qkX96CKT8kGm+NUXYbAOhDyAx113ZuoK5bGayMp9exOC+ecg0mmqVDkRcx11Zbtqo9JGCgMSHhl+OBmi3dkSEeqq6XfR9y7I35B0BYbYRxCHOdzyv7M3hvZTCJm9O8sIwW33gfro+8PVveHbwjFqXnEP9RrvEoly0ZSnAwUFnXf9cTUx37OoVQiNmBFaz6nNSv6REsSZvaNHCzD09u8E5PjzME/AJP1hKWv2ULhgCyl0eSLuldYqV6a8/pTrD+z0I=
X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3003; 31:jx/nlqsbSMX6eZxOc3bFG7RkORUwj7lUoxXxicoWx6OAawtpsW6rBc7SCi67RYEJLSkVYMvyQOYLv+zGp25+QC4I3UUUkNGOmqVuJoj0dy43iVr/mEekgPbD8wYno2dUOj2C5E7UsXXPl5X9fNY4HVS6ocYFKbyQNOtMnZ//d9JDI9r2zFoFFKIXZFIwFKUwxPG1XQRe3P3nQRzeN8RRIN9rc0TW0NEKgEgb8PvKESS4by3Y8499qPqq/gkgCSeyq0YPCCHpH2U9rIAkmzoVseJ75yukCWXzsJrBCVI5HZQ=; 4:sPTotDwR3d57PMF2LG+tlRmmOaRdvHZ5M4q7pwqS9nK8Ggtj4O4armzP2+dNnFO8bMjAYEHhNPRc0xFZq6kM6MNAwygpYsGiO+flDVtOyPM5PwTH4zQNWXvBZSgimWjsk0LuET5FEbNU6YbiDhc4TLIoEe1FTLHZXlHLLVty+hViorAsInroV2jWOW9+bK1k9cYL8yHKu6GFR/HlyN94BNGnHmxTAeRkv7m59odiBRjDvnDOfde2WarlpDjTJzCf0G/d3nV7OOtQ36/RXpJqw/Vpegd6k3Y7BNyvBh8iVRqKyt4/Ef/mU5kQtxkDHOOxJM2zrsIT3vOxn1ExT50HiudURan9ob/bbdLDiUchZtPM24t4ZhwjekawEfxOiOmqS2ClCF4MU17y3wELI1XtD00QHl9m9Ho6XfcyvurekO2FlfxEHneI53baH3zFoHxZ6otTcyA/IAwqPsBTnB5A5Km/My+YOglIVDS6qyBEfIbIZ5MkAGPLx0xs2PkTGkP1abb//2kWprZkVpNa2pwYelhONeQ/flAXNeoMINAvUm8=
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(138986009662008)(100405760836317);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6060326)(6040281)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6061324)(6041223); SRVR:HE1PR0701MB3003; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB3003; 
X-Forefront-PRVS: 01304918F3
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(13464003)(199003)(377454003)(189002)(53754006)(8676002)(4720700003)(189998001)(84392002)(42186005)(77096005)(92566002)(6666003)(97736004)(93886004)(76176999)(50986999)(44736004)(50226002)(229853002)(116806002)(81166006)(14496001)(61296003)(5660300001)(81156014)(1456003)(33646002)(230783001)(107886002)(230700001)(81686999)(50466002)(101416001)(62236002)(8666005)(105586002)(2906002)(81816999)(305945005)(44716002)(106356001)(9686002)(7846002)(23756003)(47776003)(6116002)(3846002)(5001770100001)(86362001)(66066001)(1556002)(1941001)(68736007)(7736002)(38730400001)(74416001)(7059030)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB3003; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; 
Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; HE1PR0701MB3003; 23:nLnWGZK8By8+DUpfxuvXz/yPnuYaBfSqiK8DM?= =?iso-8859-1?Q?JTOMHRX0KpV4HDycB6Cq8YlMqVp2oaq/BYvOYIu7KhDcbsJl76BHqv1CaJ?= =?iso-8859-1?Q?mCHMgSVSb8GYLb2SS5LeHPhkhAZAfIfRhimzhbKNEecsCku6jMl5tkm+t3?= =?iso-8859-1?Q?L/DDoUPIhVkHc6Vzhhm0gO19ly+ByyB2YJNjEdZhwHHTIJ7CgPBnvKHzyu?= =?iso-8859-1?Q?REs68Lgc8a0MCYYz1Jjr6F5PK6Oh8mZr8RMOE789KqbkT/SfhKY2B60YI6?= =?iso-8859-1?Q?QbOkSynwDzxvC5o+fnIgMgs4it/CS9yKLm7liKWlhmeHY6DNsuj6CFiJw0?= =?iso-8859-1?Q?M/FtXdNsERfyVOQ2o+96uqe4ttL4t9/jVqTI+Zp9arFvpsuiehmLCXPc4Y?= =?iso-8859-1?Q?p/n42o/m4PNoFvKR8R4EGrAxqVgwM9s7Gfzn/0Zl2yicc24Vr6WX/6LBVh?= =?iso-8859-1?Q?FIMCVSpswFNsiKDPVXqkNcBGy9z0RxKMquPuNaWq5wNgUaWBbe0JX77AFj?= =?iso-8859-1?Q?vtGlfmWpiUlPoQJtfnPF7+pysm4rVA2jnuyu4RDrn/P0i+NDWev26d9eDr?= =?iso-8859-1?Q?tljRWrzaAWCOGArMumy6D57AmvLkrNITtrBSI6glFnp3Y6ipOBndikOYqE?= =?iso-8859-1?Q?UH+iMxp7FYlA6sXVS3c0a66J4TqFJmMdR+A5KnFdySFyEFl16UDKjnNP4V?= =?iso-8859-1?Q?TAp4jsvowIiPOndGUTK17yWXD9Hm3yuCYqut6okzOrWz78XSJT0+M8VpaC?= =?iso-8859-1?Q?DskKpVdKh4V6uz9MgXpBsg2aCnpHfE5ebNZQhXP7zIyF3NUNJ5yU5TZvcG?= =?iso-8859-1?Q?ZummTLm5JA6nZkanCPQbU1bUuYfbPmtXNXXnElBRPgNWRbWE9pyW06i0jx?= =?iso-8859-1?Q?sz/v0EtnOzbu7YYS31XE4hTRxjJeQ2PKddnV4HA0T7Z+SMuxm8GD+xTN6d?= =?iso-8859-1?Q?NgZIXXZtdMbnft0q79HkAz1CGeUPZAii0hhCFgGgK3me004+0UOMhOxZk5?= =?iso-8859-1?Q?3NJWM8gyyaZLEsWpIsP57FjaQkLxV2gSGfAXv6NJgj22j9TkW/h0kMuOFX?= =?iso-8859-1?Q?H/x9A9yxzqpQRP0zn1g7UWiu9xAeZAk2lAQbEAV4WsFOkw4pZ+2LdsBlEM?= =?iso-8859-1?Q?kL6rLqbIGVkBpt8UJJYgZzl3keyBZfC1bejomhPSzeEK11JumtH4dVBXv6?= =?iso-8859-1?Q?aR3QF15UjN1rFPryC62zRdRmyJlKoklXe0C+Pj2jvsUZGW48QKfXuXSozI?= =?iso-8859-1?Q?sw5yKg0UI3KPSJIS574qCLX9dg7eT9J+xymUvW3QF8gqBtReL3FZNO65RX?= =?iso-8859-1?Q?i3pf/UmRbGJvgHCitH9qpKq9Ed2KSPpdO0LE3iHK7Gn6l40NWCsBO7pc3w?= =?iso-8859-1?Q?EY7XDOsv9msJB7Z9jKKT80jbXYW/wk3iwe1zqHfYBmPPxblBtE66t0yRJr?= =?iso-8859-1?Q?byLzEtmYf2HdSpGO00tC5QH3LeMlXki79593demOgHftCfeOYWpnoR7Vee?= =?iso-8859-1?Q?ZUz7lRYQMUPuPeJPKtcJLp/m4NzQQavwDusEHfTSl7znvwM+sz1i/ahGse?= =?iso-8859-1?Q?tXenQeQ=3D=3D?=
X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3003; 6:ekIM7MrLUR2Z/NELFIQ71CJ/NXvO60mIIm8vqyHXJ7umI1gtnLk5EAnw7a9YRPdsZ2gppw+ogbu91pjqAFTMa3KbtiKAdFOBqis2wC6hEGBAT5UkNTUzD8eg8vrZXYuJ8iIDrE9HKwLvLzIWqClSISQqSKwEqbGKJ25jzsFgx062nMC8BlW7vq4B69AfnSSytTGiy/4yLGA4ID0pveQ6vE+GFrxfg972iEEzC1p5X/kb+d1UvZd6UXkfDyZqD4jGVVSrV1uWWxHAROtkbLbiZZ4kM5KhY8FnKG74QNAsd669QOTt5m1Rl+t+Zc1SCSEtG9p85R8L/KWRHYQ0pE/mJQGlOmw9yX6sGJKwHj9zFRo=; 5:24s0zncEkEI+eHU5yQWEMor8IEscV676Vt531Zf5LX2aE4hiXElPlzv5fR+BtsRYAl4l9GHo4iuUXpUALdpLDsqVVNm8BDvPCwOT/QFRAkGwmMFjefJIaKMc+f40FypceliVyDT3gN//nI9L9bPgeA==; 24:1xRJT6dCf6lK0HXV2yljjzMLdWSLi12oPO1hguh4iVxW2LVPvLrVhZL8+SPSaOI6AnN473xbMjvF7xWOajgkesBr2hBbuIUEHLfi1bucwSk=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3003; 7:lvnNfitqvUBeumhi3rMycmnQ0D8zgSv+7KrjIK49kps2JBFN9/c2XwTb3nJVFju06qnGCyarjcfxHX5SM4Jq0PTZLMeYIAZ0ilsnhAzo/jfNRdA8I3cpFnzp/15DZxAy3sON7LXrzW4MhhZ0H5fLy+rXHgOyjeEdirgtHSPNBAw9qhjzOj54XEaScjUzJg9PXhyU5nmtqNOBF2+902KV/QcM6pLaAX98O/W8dLpBR4o5yH5BZP09Cdr/8SCN+tp6/TLa5oLpHaNs712PDiCs7wYj9GZlZQ9Nsw4/4RHbAx7EjGlLhuaopv0kT3W2ZVXn5D0e3iJvDD1/v/22bfMCAqDyGMhw6h/FElD2YKhTKhY=
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Nov 2016 11:07:39.7730 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB3003
Archived-At: 
Subject: Re: [Idr] One week extension to WGLC for draft-ietf-idr-large-community
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, 18 Nov 2016 11:07:46 -0000

John

I am happy with the proposed text but ...

An issue that came up earlier and that I did not see resolved was what
constitutes a duplicate.  This is binary so we don't have the issues
that
character comparisons do but is it the same bit pattern from start to
finish, the same semantics or something between the two?  A case I have
in mind is when the same semantics appear in RFC1997 format and also
in LC format; is that a duplicate?.

Tom Petch

----- Original Message -----
From: "John G. Scudder" 
To: "idr wg" 
Sent: Wednesday, November 16, 2016 4:01 AM

> Hi Everyone,
>
> After Bruno's comments regarding RFC 7606 style error handling being
invoked to react to duplicate community values, a few people have
expressed (on and off list) concern that even though that is not
intended, the -08 text as written could possibly be misinterpreted by a
zealous implementor. To resolve this, I propose adding the following, or
similar, to the Error Handling section:
>
> o A BGP Large Communities attribute SHALL NOT be considered malformed
due
>   solely to presence of duplicate community values. Such duplicates
MUST be handled
>   by removing them as specified in Section 2.
>
> IMO this clarifies the intent of the document and doesn't represent a
normative change. Hopefully it will resolve the concerns of those who
were concerned about and opposed to 7606-style handling for duplicates.
>
> The authors have indicated they'll incorporate the text in an -09
(assuming of course that the consensus of the WGLC doesn't go against
the change).
>
> Regards,
>
> --John
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr


From nobody Fri Nov 18 03:47:10 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B28301294F3 for ; Fri, 18 Nov 2016 03:47:08 -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=bskyb.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 vmqLJegUMJ4Y for ; Fri, 18 Nov 2016 03:47:06 -0800 (PST)
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40086.outbound.protection.outlook.com [40.107.4.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A34D1294D4 for ; Fri, 18 Nov 2016 03:47:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=BSkyB.onmicrosoft.com;  s=selector1-sky-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version;  bh=X9l5TSb73spHwx//OL17YHNpr7D9baEHjm/5ynNlwVs=; b=mjp5ADqX0BAOy1a6hztDio/A7seCC7efv5Gb3Jm5xV/H93nxC+jriu6aY9x7KfpbTysI8UzT0NUJvnqQP/T09If8FYqKVyENT0xbgZ7+NOK5qq3sszsVOnCfkKpCGxdNNh3BGWDD9bmldwqhw3kH6vHSXwsrb2HfC5jD2+uaRZM=
Authentication-Results: spf=pass (sender IP is 176.255.244.224) smtp.mailfrom=sky.uk; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=pass action=none header.from=sky.uk;
Received-SPF: Pass (protection.outlook.com: domain of sky.uk designates 176.255.244.224 as permitted sender) receiver=protection.outlook.com; client-ip=176.255.244.224; helo=email.bskyb.com;
X-IncomingTopHeaderMarker: OriginalChecksum:; UpperCasedChecksum:; SizeAsReceived:1931; Count:20
From: "Dickinson, Ian" 
To: t.petch , "John G. Scudder" , idr wg 
Thread-Topic: [Idr] One week extension to WGLC for draft-ietf-idr-large-community
Thread-Index: AQHSPlcYK8Lmm+ESl0iNXVRf9Ey5oKDY0xMAgAAvdgCAABZggIAA962AgAAJQQCAAGt7AIAAOlAAgAA/yICAA5v/ZIAACk6Q
Date: Fri, 18 Nov 2016 11:47:01 +0000
Message-ID: <9B3BFE0A18160E40BAF1950414D10FAE6174003E@WPMBX010.bskyb.com>
References:   <27701_1479159582_582A2F1E_27701_6903_1_53C29892C857584299CBF5D05346208A1EC77FE1@OPEXCLILM21.corporate.adroot.infra.ftgroup> <736EA2CC-3DD1-4F14-96ED-2916E62F6F02@cisco.com> <26709_1479217575_582B11A7_26709_12999_1_53C29892C857584299CBF5D05346208A1EC79584@OPEXCLILM21.corporate.adroot.infra.ftgroup>   <20161116001246.GB27230@pfrc.org> <4EB6222D-86A4-4A83-AF8C-364CB52B8422@juniper.net> <004201d2418b$887208c0$4001a8c0@gateway.2wire.net>
In-Reply-To: <004201d2418b$887208c0$4001a8c0@gateway.2wire.net>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [191.255.72.199]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-IncomingHeaderCount: 20
X-EOPAttributedMessage: 0
X-MS-Office365-Filtering-HT: Tenant
X-Forefront-Antispam-Report: CIP:176.255.244.224; IPV:CAL; SCL:-1; CTRY:GB; EFV:NLI; SFV:NSPM; SFS:(10009020)(979002)(6009001)(7916002)(2980300002)(438002)(199003)(53754006)(377454003)(13464003)(189002)(5001770100001)(230783001)(47776003)(55846006)(106466001)(107886002)(106116001)(86362001)(74482002)(229853002)(76176999)(38730400001)(54356999)(26826002)(97756001)(1941001)(189998001)(69596002)(50986999)(93886004)(11286001)(50466002)(3846002)(7846002)(7736002)(102836003)(46406003)(6116002)(8666005)(66066001)(305945005)(23726003)(2906002)(81156014)(81166006)(33656002)(8936002)(8746002)(2950100002)(92566002)(2920100001)(87936001)(8676002)(9686002)(5660300001)(5890100001)(7059030)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:AMSPR07MB146; H:email.bskyb.com; FPR:; SPF:Pass; PTR:b0fff4e0.bb.sky.com; A:0; MX:1; LANG:en; 
X-Microsoft-Exchange-Diagnostics: 1; AM1FFO11OLC008; 1:eq0+bZn3fkyHnvp+FVFSoRHo53b4GJ2lA5bCKdiJxNhJ1FBLf9kbpplRDYWpZvXGcqUSZbFn/aGZNnM6EPHzTVdCL/ggiibllSNHNPi4fdFCU1XXYr/9S1aDzQAiF6/Lrqj3NiYNsRHCTHgOYZS1mMlEYr2vAKOpKiJVkVJFxeXkurMj4EHRhouFGEMk0zJxZ2FifkIZdaK5BfqUr8/V6nZr9IxCmOx8Xxc8Rt7HMzAA1lZkeLqZcLwI8hr2cxp8bhRnzOxaOikY40AiDAjEvyidTl2qpmL/pp528JX9j359Klh6kMxEU1t1I0glO3j7ynwlVivi6fMLAOVE9SUQfjHjqwGvo+o4qwYHQiwHJ1xOEaQDW3nWZAvKlzMsfxMOUPnZpa4BGC04kDCgjTL2U3Zl8eoGjqh1YeTJYe+fZIKdKXFy6k2GGt7bRN9Hr0ndhNhSCUBkBqoxjFzPm8k3IG5qx5nGxP0WrNwzElTMcGnkB4n04es9wHxy5AUp7oDTQgQoun5MHuqaLoyxUDDO914boJ+6ORu5mLm2FYmT2EjiVXVeqriMcP5pszYfzZix73gu9IDz5oTrXrqymrb7hQ==
X-Microsoft-Exchange-Diagnostics: 1; AMSPR07MB146; 2:QMX4aLwI++/o2tZ1yYCW5QBk0bTtO2oKSNTbS9FEZ3NO6EBXOxowTwV/nzh0yuXY1hYfsocIb2d999x+a6BSps3Wl8fDUlMBjerre1FEjc32/pOnVNwOBStlpTewS3Mvxs2kYglJFeTo2qnznoaUJDYokFwJeR9+nPKTfmWm7q8=; 3:e392fKmd859fjdLkA22lYsC88a8HuH3yp9Dz7NRoI4cwOLjX8ZxA8caU1cMkLOKH1R+xsl8SMMqxt/XISm7EDpoZ6DyVCAZ8Vn4Mpw4pn4nexcjmP004QpaFNqsMGoEcqJlfS2tXBb0cAbpbKjsjySk6/+J5za3KA5u0hVDWnUdvQ495Gvvs5/JTyNauDQdc9siW5fCkLQs2X6MZK1hHfidK6sCxWr8woOAU7BZYtMoE9b4r9wGfIcdRAnbOO6n+tdU0eYnjLPsy5S74wdJeqS7UVosMkyZCIyrZJU7fagujeTLB7lDiVkV9Z0J8FhVx
X-MS-Office365-Filtering-Correlation-Id: 23372320-f68e-4e7c-765e-08d40fa89da6
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(8251501002); SRVR:AMSPR07MB146; 
X-Microsoft-Exchange-Diagnostics: 1; AMSPR07MB146; 25:SIBM7LbVJpsOyhCXTGdZREKYNCnXq5MIgE1juWwJXgUErjrWyIOdZPvBbtGGM9EhyG22Y0kiHaGQzzuuSZBgVBziAWjYgt1m0yjIw9I47/goAuPmVPUcjUM+4VbWVEaHq1EI4YWClnF3sQoBy6KSZHO/kXtxSUZKC+qqFUA9VmjM3NZE2ySbaH/WBaZV4jc1moPCAFKLEoNuE2W/s9jmop4Ip+tPBE9HBMvZkaEgzoC/G/jJjhyTopCNBM/KkJjVRD3NlX0a1h2G9/oCQIbElRGmkmjxlG8n02z1jW5HVs++WvSf41zgfBkEJdE+kp+Gl7Z34JhGw2qTZBG97ra0RZzNAN8rj0o7gLN6+dRG6frOwSfq+jxo48oKS7xTCVfJVOZZjSfDWw8kz3ZKHPIkisq0MUivjIIKFBPvuzxCih84JafQUq2ycakl9G7IkMR6b6WZJ5fmXvp8FC35F6/fownnBqNm/F445jp7nLcZCPonAi8YodBlgDpMcTD/PexV+x88dNJYnhPTQ5s0SZmQRC2aepq7kq3V/TphpuouPSDdKcfeOMBgNi+tiwJnF9BcRpV/R49EnIm8ROug8kY/77npxqYvw+dQg0NnzLigH2FiNSGzeMhTUhI/rw7U8/Rta1/EHDW8iG0Q0IhM5W1IxYQDliH3EVEqD2NPW1L7Judf+gEhffuRHgJVTUevvgDK4PgNGnHIKxrecF5VxEY3PQyE0pIijFn7WdeHMMTiL5ZKLNejodlCilNffPzi7b3/cDmYN+wqoMOBk/rlbeyyTG/ioKz+mknW6MNX88uTt5AhR2FhFwgk1lK6MAhFbd/tqH775lMGf0kBsv2J/2eGbo9LduIvhSagoFjTrgtL+Cpgov7S0MPuHCJjn4isCCwBUU9Iq0lbfRgMjcnei8Ofa3XPQ6JaM23fFiKJTlcOqu1E/oZxWCHE+8vIFpwZYLw4
X-Microsoft-Exchange-Diagnostics: 1; AMSPR07MB146; 31:95LUJLdRZ7KrtKs5LudcP6mhq069rwrkSicJwzPQI22a3I2AYpJsS/VvE06Uwpy2dfX6joNibVBKHG3qqx2LoBci/Ua1OkZYV08VBjaE3wRlBQFs9GEDAD7xZd1gKlOn2SMCAtFB/PAgxCsFnwIH95/lS9wh6aWid4dMSSfBolNW7dcMh0c4pVS3U+tLogYJexJwsvfwvAmw3xW17s9qIp19KwSKgUMnxZtB+w9t45LBELy03QllDL28Oa+F7N6uOJDHNBFXAxg0IHaS3eHBlA==; 20:S1Mh6LxEBIzL9131H7HXd1gWxWZ5ErE4fjvZnGdbDEs5d23g0PZBPO1vNO/MhjIOSylQHgcGompPNglbcWs+08Q+r3B12O24l7I8FV8AEc0PZy1yCykQsJzQvTOtR4U6fer4SPK8DPQ5pgqclMz0N7TPN8U+/IgVGV19iYRSaKEvB4vp9oNZ6y3VPnsO5dkKsdamKkrMWJLxK13c0mbA7jTuQNmbQTF0PQFsyfaixgH1aHt2wTqIvmp3nI7H2cH68BP83Fq6SBeMuclv0v5sgzt5tcY2oiWpk81EotX7Psr+Ohqp6kwyjYHM2FIb1hShfD8sqdLd8H406vl//5zuf1jILX7bBrUmZOJQFFW7zkewGpDiv6l271u1YOGhZ0TFZ+BxPrLy4N+4YA+LtGAOSZO5bDFmwE/gD6Gtrm+OwxD5b+DvvjwMBBp3FBv9cHu9SypOZMDjRp+GHihKc/Jqwa3QyZkSLvmXsxb3cHNYcFWnoC8HumZtLZQjhMbf7OWH
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(138986009662008)(100405760836317);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6060326)(6040281)(601004)(2401047)(8121501046)(13012025)(13020025)(5005006)(3002001)(10201501046)(6055026)(6061324)(6041223); SRVR:AMSPR07MB146; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB146; 
X-Microsoft-Exchange-Diagnostics: 1; AMSPR07MB146; 4:PxZ4YnSN8Xvd+KuLF/k+eJ0i2mKoxR2gFksYRe3EaQkyKduWzB4jdfYKrx3e4KbS3NyGSVGlCHP88EadsYvinR+sVFZfAkKLjKvbMGajE9+OA2JdfOYhim8H24SB9Byl1OaDIgBsUcEBAcZ5snimI9bDHTn51TW//gKuTg7cRdnt8K4hnrJ6+NJFzN7a6NMZbeSRz1AMIJ6oERgQ6LLCSGKH5mfQ7SJWoieBH4maWqAEvf1j3377YljQzYWHb1dmVb/54BlW2yT6pqq3Sx+Kq3SNfP5ZhCTzscizgDOpPlCVuWGkt0m6F8NbYqMWf3gh5CpHnIFJBEIMBUNw36qv72LtKDQz9+ejJ2rDeiNPjpCu8haYXe4kI29nuqvYc0vwjaf2t2U2/WtcnxzviHDrUjthZpXABU+gg59tjXlafvs8IIsIp1j81LJlHEPFACRMn7BEHjkAdpK/cZPyS4V4beCaKzQ5MFybiH4mX4dSWDhUlHI13CmhEoFTZuiq3rxn798fd6GOsUzxRNAxu4j2ChyecE93SuYnWPKZJzmH107pxUhVP9UJBQbuLBss9qUfygFigEvdw3BV/lPENqfJbA==
X-Forefront-PRVS: 01304918F3
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; AMSPR07MB146; 23:oN7DE1oz8e3B8ze3y3c7bc3653UbdR+TjVdwNcxxRV?= =?us-ascii?Q?FCxJWU09OZ/fqeaz/leWrhBHuVDeIC9VdwWP0Rr/rFpcM6mfXlmjhMeXFWDf?= =?us-ascii?Q?KCHuAUfzBJQfEMFuFGUI3NGLPbDMQTLj/HgWi21P3pFeJpRsbTMnQScTB9Eb?= =?us-ascii?Q?iBSVsfMq7LHIwNr2Sx0NzNrUfOF46yrcB8bgKcEJzXZ/w/wWdYQftq81jCbt?= =?us-ascii?Q?j13wPacUg2ZXImvp5/OaRxPUooK8e/76SFn72i0yG3+4Cd9tSaXp/AUs74G5?= =?us-ascii?Q?HdGZYIeD/jRMVlTu4B70joTKCW2unq7l8BCZ1sIRLlrppt/VofdlkSVOmj2L?= =?us-ascii?Q?cM32iT5zrNWH5M0Yr3UOYp8p1WUEe6S5EvNRXP+z5ny6WwAa+iWale0ZoeUW?= =?us-ascii?Q?J0KvsxLo0fI1x3JWDRPBP1hVHzXkw/3pMaYin8GQiJOxNAA8DA54WnvemC9W?= =?us-ascii?Q?MV8fBmbRTOtPF3u0JaeMtgN6tPRSPKShwTS7XvFxCwJuqRFXv78AjWgJa93R?= =?us-ascii?Q?FfQQiyX+H5cuQ/jjVFMHqOBOdeUg/h+fZKKgnLUBKV0PnC8WWqhZiK//WQk2?= =?us-ascii?Q?HoqD+7k9vH4+t8UVnED6Qbv7fRqxtkZMg+1gkfgWDBDM53sNgcA/6GO5VESU?= =?us-ascii?Q?uBccNtM2QccfQN3XFBGBfWcotdACXwXteysqAQ2if43fL2oiYsMuFIN2tlMf?= =?us-ascii?Q?68jaKHoStfvKbnUwYZG+t6I40LajSgJ1o8MCFchQD+99coTzs2c3gbWUvGoz?= =?us-ascii?Q?gnXIWHUH6n28CbwkaVlFgGICfFYQwg0Ud94lRRH9vYpxWg8LNDDbUxaokG1f?= =?us-ascii?Q?P6TRYr0QgHbJJLtCX5kFJxdS3IayARSjfKqIWWl2+Lu9DmhtMRTRvfj+n5kr?= =?us-ascii?Q?2yawI3ulC/KLu/6WeWJ4mJ24T+uzu5QUbWDT5grTGScWHrxfPQo2DGDuuq+G?= =?us-ascii?Q?P0CN2CQpAntJ4RYWqibm0M1JC8WF7ZqwfTuArmHFsWWcwl20lzzaGsSu2FGV?= =?us-ascii?Q?fRx1qm4RuQPV9Ya0DKniE/bw07vy7LgYSfO0UN+jh6cdXpel8ksmd2krlqRf?= =?us-ascii?Q?7xTs++apbheJKx0a4qYfYIzvIAf/yF2VNdaJZBn7vkfn8R/HIevxhv3h+4vZ?= =?us-ascii?Q?JInRTckRP6owzQUfu4ILkx9UMKR47bqjiVMT1A/iev5WkRhIyUahF+61pVAu?= =?us-ascii?Q?LqjNZjDkU4BLzhNFErHqinnsdS699KVd0q3RUTupsh9FhtKmnDQfgyYCBhBO?= =?us-ascii?Q?o5skYFvsZ53N4TNPj8ItUM94O1WEwSjaPDGFkkHwGJdG1Enb7VWTEt9U9Gll?= =?us-ascii?Q?14PVEjJ/7tCwiFWLMYGr4mgtNtTpBAAi4t3l+4hmpGy5r9lOugrvXFrVqFow?= =?us-ascii?Q?5lQMDCYluuiM+wTCol8y49mongGx4oz8Jy53NiGrVILvPndWsm/uAHwsOMLc?= =?us-ascii?Q?POUTRNhUh1Ev14IhlcbZ9njrTpKMcUwPTl/2ZH0jmFzeEWM8Cu?=
X-Microsoft-Exchange-Diagnostics: 1; AMSPR07MB146; 6:hAMkLIVwdvEZ8PGkDWDMblctncdoTICG69atnPz8O41nYXfTCJT+fZFLhif6MQ93DwPNfSGHisFsOwFfh75y1BYjIHvZNG1orwxd4CxTFnSIBW//HHQbHZxCbUVfpyGcV59Md4vjQEbDuvlLAL8tJVNHVPgQv1IoMtmGfXdyWoBayhKhkfQLzKDetsij6sYLleOrfJ297prV8hfMg+DubZpqfcIhu+M8/e1oasyxQ0pNmGbLc0lZfMXYHgCAVPSh1n4SdDTohOd6JHw58/fB7SQH5/zX4VQ4hEjlxCaA7k+0kKzWYUw5STuUHJ8g+msQNayDBYNGWQi1L88fNO0AfuAcof6QJ/MElPexp4QELGnRYPP/BBb4PZ+U1if0wXtv; 5:JEw8NfN/5ZVeGUCaZwxUyxLr8Lqwdz4wc8AfHNefqyidocJC87+QkB96ScZDn+VAy3YHy4lgmDG3RX/rUDR1S1NuBnufG4DVG3eUXaPFIN/8ycnoqHCe7lz3hWHEFVsoxoN6fn/0GSnM7xnG5xsvCQ==; 24:7hoMBjW+yjKb7bA+dvx+TkgbhyAt42ezc9O7RdkW+G/dAMb8whRDBGOIFK+SKDAXmn9rey0Kg4h1wDR4KtA/+MDX/F13lfiTmZB0r13Dyt4=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; AMSPR07MB146; 7:HYFRv2s+4aa1j5lKEi8hplX8j/RNAPXEOUYhSUvk0t/JfOnZcnMXr79Gy1fPWEFogsnGWLk/ssRVWKnEinasMKoMt1hXGi6FkWdSXhDH1uCbxGpOZSDdqryrDPF6754+1H8bkWDj55pXaDwTL02D7BjLnx8aNktdnF7Q3jZGnqpydfU2b9j9Kw0CosoI+H70FQjrHhBlysI639fXgKi+Ibh54IthkoPjRQxqdf5cm71d+Uee9Whx52KttbgA6G8p/B8JhREmTQ0YSHTrmS4zcCefVAecDBhdeljkn1luYRZ+OlG9Uulzkc1F+PqVnlq6xWh3unruIoZc0obFEdtAeEqEJN+dA657UwHXSLB425o=
X-OriginatorOrg: sky.uk
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Nov 2016 11:47:03.7441 (UTC)
X-MS-Exchange-CrossTenant-Id: 4f86cebc-57e2-40a0-86cc-01d73be93ba0
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f86cebc-57e2-40a0-86cc-01d73be93ba0; Ip=[176.255.244.224];  Helo=[email.bskyb.com]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB146
Archived-At: 
Subject: Re: [Idr] One week extension to WGLC for draft-ietf-idr-large-community
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, 18 Nov 2016 11:47:09 -0000

I would say that large and 1997 communities are different things and cannot=
 be duplicates at the protocol level.
Operators can configure policy that would choose which took precedence (reg=
ardless of semantic equivalence or otherwise).

Ian

-----Original Message-----
From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of t.petch
Sent: 18 November 2016 10:58
To: John G. Scudder ; idr wg 
Subject: Re: [Idr] One week extension to WGLC for draft-ietf-idr-large-comm=
unity

John

I am happy with the proposed text but ...

An issue that came up earlier and that I did not see resolved was what
constitutes a duplicate.  This is binary so we don't have the issues
that
character comparisons do but is it the same bit pattern from start to
finish, the same semantics or something between the two?  A case I have
in mind is when the same semantics appear in RFC1997 format and also
in LC format; is that a duplicate?.

Tom Petch

----- Original Message -----
From: "John G. Scudder" 
To: "idr wg" 
Sent: Wednesday, November 16, 2016 4:01 AM

> Hi Everyone,
>
> After Bruno's comments regarding RFC 7606 style error handling being
invoked to react to duplicate community values, a few people have
expressed (on and off list) concern that even though that is not
intended, the -08 text as written could possibly be misinterpreted by a
zealous implementor. To resolve this, I propose adding the following, or
similar, to the Error Handling section:
>
> o A BGP Large Communities attribute SHALL NOT be considered malformed
due
>   solely to presence of duplicate community values. Such duplicates
MUST be handled
>   by removing them as specified in Section 2.
>
> IMO this clarifies the intent of the document and doesn't represent a
normative change. Hopefully it will resolve the concerns of those who
were concerned about and opposed to 7606-style handling for duplicates.
>
> The authors have indicated they'll incorporate the text in an -09
(assuming of course that the consensus of the WGLC doesn't go against
the change).
>
> Regards,
>
> --John
> _______________________________________________
> 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
Information in this email including any attachments may be privileged, conf=
idential and is intended exclusively for the addressee. The views expressed=
 may not be official policy, but the personal views of the originator. If y=
ou have received it in error, please notify the sender by return e-mail and=
 delete it from your system. You should not reproduce, distribute, store, r=
etransmit, use or disclose its contents to anyone. Please note we reserve t=
he right to monitor all e-mail communication through our internal and exter=
nal networks. SKY and the SKY marks are trademarks of Sky plc and Sky Inter=
national AG and are used under licence.

Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Reg=
istration No. 2067075) and Sky Subscribers Services Limited (Registration N=
o. 2340150) are direct or indirect subsidiaries of Sky plc (Registration No=
. 2247735). All of the companies mentioned in this paragraph are incorporat=
ed in England and Wales and share the same registered office at Grant Way, =
Isleworth, Middlesex TW7 5QD.


From nobody Fri Nov 18 03:58:15 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FA4D1295F7 for ; Fri, 18 Nov 2016 03:58:13 -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=bskyb.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 Rq0sk76HL1lT for ; Fri, 18 Nov 2016 03:58:11 -0800 (PST)
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30069.outbound.protection.outlook.com [40.107.3.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 6301C1294D4 for ; Fri, 18 Nov 2016 03:58:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=BSkyB.onmicrosoft.com;  s=selector1-sky-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version;  bh=jqjEO/sgfA6E5hTWg+Xtsjn90aBTgVpHJl8grnh7qQ0=; b=JbkaR+0wqaQyH4cPQty1iA2lBkRh57PDZnC1z0RpEPHFZCKbZdankXiI9uwYWpVbeTrZDeWriuD0T66sCmW4ZQzwG8Xex7TOuBqokFQm33/Me0Apx1e2Et6TU5HPNL0wGhhsinqKlmNCHBZUMMaFu7cVY4SRKa71QToKuDFFxaM=
Authentication-Results: spf=pass (sender IP is 176.255.244.224) smtp.mailfrom=sky.uk; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=pass action=none header.from=sky.uk;
Received-SPF: Pass (protection.outlook.com: domain of sky.uk designates 176.255.244.224 as permitted sender) receiver=protection.outlook.com; client-ip=176.255.244.224; helo=email.bskyb.com;
X-IncomingTopHeaderMarker: OriginalChecksum:; UpperCasedChecksum:; SizeAsReceived:2014; Count:20
From: "Dickinson, Ian" 
To: t.petch , "John G. Scudder" , idr wg 
Thread-Topic: [Idr] One week extension to WGLC for draft-ietf-idr-large-community
Thread-Index: AQHSPlcYK8Lmm+ESl0iNXVRf9Ey5oKDY0xMAgAAvdgCAABZggIAA962AgAAJQQCAAGt7AIAAOlAAgAA/yICAA5v/ZIAACk6QgAACdEA=
Date: Fri, 18 Nov 2016 11:58:04 +0000
Message-ID: <9B3BFE0A18160E40BAF1950414D10FAE6174005D@WPMBX010.bskyb.com>
References:   <27701_1479159582_582A2F1E_27701_6903_1_53C29892C857584299CBF5D05346208A1EC77FE1@OPEXCLILM21.corporate.adroot.infra.ftgroup> <736EA2CC-3DD1-4F14-96ED-2916E62F6F02@cisco.com> <26709_1479217575_582B11A7_26709_12999_1_53C29892C857584299CBF5D05346208A1EC79584@OPEXCLILM21.corporate.adroot.infra.ftgroup>   <20161116001246.GB27230@pfrc.org> <4EB6222D-86A4-4A83-AF8C-364CB52B8422@juniper.net> <004201d2418b$887208c0$4001a8c0@gateway.2wire.net> <9B3BFE0A18160E40BAF1950414D10FAE6174003E@WPMBX010.bskyb.com>
In-Reply-To: <9B3BFE0A18160E40BAF1950414D10FAE6174003E@WPMBX010.bskyb.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [191.255.72.199]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-IncomingHeaderCount: 20
X-EOPAttributedMessage: 0
X-MS-Office365-Filtering-HT: Tenant
X-Forefront-Antispam-Report: CIP:176.255.244.224; IPV:CAL; SCL:-1; CTRY:GB; EFV:NLI; SFV:NSPM; SFS:(10009020)(6009001)(7916002)(2980300002)(438002)(199003)(13464003)(377454003)(189002)(53754006)(5660300001)(66066001)(33656002)(2950100002)(81156014)(8676002)(46406003)(305945005)(76176999)(54356999)(38730400001)(106116001)(87936001)(7736002)(2940100001)(81166006)(97756001)(5890100001)(26826002)(7846002)(2920100001)(8666005)(92566002)(8936002)(102836003)(93886004)(55846006)(1941001)(5001770100001)(106466001)(230783001)(189998001)(9686002)(11286001)(107886002)(2906002)(8746002)(229853002)(50986999)(3846002)(6116002)(74482002)(47776003)(50466002)(86362001)(69596002)(23726003)(7059030); DIR:OUT; SFP:1101; SCL:1; SRVR:AMXPR07MB151; H:email.bskyb.com; FPR:; SPF:Pass; PTR:b0fff4e0.bb.sky.com; A:0; MX:1; LANG:en; 
X-Microsoft-Exchange-Diagnostics: 1; DB3FFO11FD027; 1:w7znXankpjNnnzVi8STkB0UdoQ+4iJaAJywWOPPrzOzG+Y+vdGYux+JtvKGXjoDpPsHfN+1Ob6bqA4JmowsqQFYhpAS04Hcl02qxwLfY3gdMZDlGJ85jys8JY65t8cC2j2SsGvJJa8tv0KJEU74P7BRGkQe+3ZgMvA5qrHbS4Uog8p3C7f1jW5cPlQekxT8CUGTZ2nZyP3jJ5v9xSoqe5iqEgyEzg7zkdWr8xK4dPqzVs5uKSUzhCAs2F9iXF8Wu6mwNUqEqluBlGp2Recfe83rpSXyxvdsYlyhRamH6mrUBzqsNXQSwX9uD/XssXtd3tbJ8//jxsBW4Z3iMI2weV+sXw6SXq0zBmCGzmTm6mPkHQ8YAsDYtTsPDG2AK9RZOX/7t3l2WMH0doRH1psgGfkc92w0vH22WpWcwUPWQWlLJI9OIfdY7mVVeGIu+7X7xfl3th4c2dB8QRVwk7M3sT9zJEizfsrk7G4XWDFQ8g3xbrtlEWhv5Edvw3i9hsDrPif9xCwLej9habfdMAFaxLYKendzOGQplRDy34gwDCVAwspvtL4/SdK2RgCnBFXPxDRtz5VDiAQQYInD/XQtMnA==
X-Microsoft-Exchange-Diagnostics: 1; AMXPR07MB151; 2:9m3047TRZNqXFYrgU8HCBdnmr5Xu6PTUZK4zFjcBt2zRCMUbA9rssmUMK6lYI8ClmqWRnbjQXZlyPj862oX2mcB5AKTIpzFhazJJmznfsnwq9ZCUJNGRjnxGOPqEBOK7krNRzsgwx+5Sh+1OtNidsCJtXfHyTN+SYEfIpovER8Q=; 3:ToITgr4yHAzFo7+PhcwJ3/l3qoioaJUij1mr3/HAxCXcOCDl0ssQgoWA/ST5WZg0dUBp2LYSLdbZ8Fu4oiAWUZaPEvRbKJSXDv2buFtDsAvD5ETGQmGrQ1eiVduwhDVAKlVeI4kzmL+JI30A6CoMlOGVD7ibZ0Ss2px8eMnQFtakNnO/i/zo4szPH7OB5k3wqN0oJ1OVdmsBr7A36t7hV0urBioATRAmkL/mzgZI/ychusb6RHO/3aTztkZ71AOzGw2R92PZYCbFfn2ywD46+syzAv+9Or233TKqW6661few7S8DxywWWBxtrchiz/rC
X-MS-Office365-Filtering-Correlation-Id: b44fbbbf-08ae-4fb0-b16f-08d40faa2975
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(8251501002); SRVR:AMXPR07MB151; 
X-Microsoft-Exchange-Diagnostics: 1; AMXPR07MB151; 25:2YXiiShT84Qdi79izzNRsVISnHp2Vj7lM9tB8M3oy0gh+KTorkQHpTtfc0lBsdHc9HlsdyckbJy5P//ZbuBL2bIKwedzn9HjS2XjQ7iGEiTUwY20Xuyy5c2QG1btCkrWujN4uE8/143dzp8CPxhloxWr6wL/ksRGuRil6DNZF+JZOK68f17VXrSGlGKzG/7uDMYxAdY/t7dwCIJq8iSsSl6PB9E0jwOrdFcjJRyq+m1evjMXCPYObJpko2DvXeEnsgHRyBw+3FuewC/gB2eh+PkhbQuD/UVhJ8OEznNNDD6aCJMG3AHTo9HGlAjahCYuK81FXRncOQEJtFxC69nmtAYSqO+rzAfzzQabxKwQdachb6+Oc5KLSL/nibx1aE3kbF+h42cenwqiKyxAwazo78dIhLMNcb1lbjywzYVNQoe9A8pwyXm8Y/PHd0d5y3+wHSnQiqMA1xg+p0diXMWs4Q==; 31:Y+XpPQLOv0MzqaJVi9x7dHJPL7iDFFFnRuxbKVhm9tmp3iReuQRdkNMFrD2LgnEaD6+jriLUjMX7GIM+OWPQnn+Qz2n1X0caI2M2wuDhY4N7Ilwqya9gaxmc5f6cKqicYf0/ol6FLzHo59xkBvKRjHBxkKzvTzuW7SEn/RP9qKUNcBcZpEan+N29DNzXJ/iuXsXCoCptVaISGIBUAFieHVbURppPwaJ6978YRDrzFT4OlcPokHb2zhxO8xsTuX6IN4WKdVtAA9BxAej6Dt6iUA==
X-Microsoft-Exchange-Diagnostics: 1; AMXPR07MB151; 20:Y+OZzFBegOvyZnWJ8vqOYB+0kkEqNjlGZtwkpTIF2FUT1/8Ytj8e6D8Uu5YERhaij+LG1xnXw5dINUF7iVhFKpcIGgS9Kn8oFlABeOu2svYEof9nJkvN2Lo/TCJRjplMfwwzdugjqhNt2o5xtEXV4czL0C/HN7maorQtovSNMdsV2yEBBXx2R0LAJ1VYH1VoeczppWiW6VxQzhCgCXzxoIZbScm3XLH9q1HuqxOdYVbItVohQUvUEZyFytiXo8e/YxBIiN7x2oidtcrV9bEr9R3krO1XocsPS7A8F2/PNMa62e5Q6hVme3YPTMVQvDWavjiaD1ABa3MioebZedIbGrRJ9Y1EqR4/4qS8ilOoaivQNQ76PnQz9goVD6oMC3dOYljBsp1zYzVOyPl7+2ObsZxme/E6MDExDLALe+dxCoV2iopOFOSPmUB5FfsGAAMMpGm/FBVFPb14e7tCBoWODW+Xi2Cg1+fX3HifPpMOZNQwWdyDxkq87PwDyVMyzcZP
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(178726229863574)(138986009662008)(100405760836317); 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6060326)(6040281)(601004)(2401047)(13012025)(5005006)(13020025)(8121501046)(3002001)(10201501046)(6055026)(6061324)(6041223); SRVR:AMXPR07MB151; BCL:0; PCL:0; RULEID:; SRVR:AMXPR07MB151; 
X-Microsoft-Exchange-Diagnostics: 1; AMXPR07MB151; 4:sbAwkpRnXgl46niL1JmGA82rYKAlH+vL2/pyECLS5exPHrN+rVsThWZr3EE2mOzFutUOrRB4wbS0gEZYr5QevvC0Fd0IPrbMwJSpNw6UssGj7uzqG1/k/HjlIqRx69Z0hMDo088Dxt02DTC1pR7rGKxulY0UIiQGKBqJF2QToECnSEyntMNFCsmrZ9aIsKC2aA7aQzusVJWaHsx3weVHGtPO+ikMJo9FvSJVYHxPUV4HIiJlfCUIiS8k4FQTkjTC0hFusC3CkIlHr4pVIOHpJmS0/Z2UfoBsW6pOenbMCDE+I/vAHijParWceyZBmBcKQx+AnQRzUBzUHflcTzCd2ebPkk08StbrDg78pQmO0uaV06P33ARLiHPR5meyU4RkqBdcejsQADyTLr275ZUsydyn6LLopK5upRN75WZRtAQh4U/pkmBxL2x3QlzZLHPC9DvIzC0q79Z35g2FjvAHvxciCNAvpemPvYdUN80PSnaH3Actlrq4i7DI1NqmfMkfks16eXxC4J+05mXUQqZGLVwzQp2AkV0PSoxhzuRkAf8sXiXpZmjWxESzcuqPN062bqMJi8bcrlEyEJ7kelxt1AP+lfADic8bu8bxq7bDdNDvg92Jrg2mA5fn3KLRM2AH
X-Forefront-PRVS: 01304918F3
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; AMXPR07MB151; 23:+pXc87PXKQYctweIyakDbejZ3auCRFg9xTGmv38TES?= =?us-ascii?Q?KDMrLPNo4X3I6RLyK61jhyacM4WU7cqNR60/TcKMdKj4T7CT2uc6ttxXdgOW?= =?us-ascii?Q?Cb5j4GJrIwMFvKvsfH44cS9DnkSpbC7rFYaI8Fdzxz79vI1pymKjQFPZFo+F?= =?us-ascii?Q?hkR9BdPYZBrui35DTtSxdT8cZIMtEHMBAwkLnXUrgRvsS7cILr0qtQ41JOBK?= =?us-ascii?Q?v50m9oMtEje25NXSUXxPfXRDfkaUaZPD+IZrOPnoy2H+o59glzCwvkkhIXva?= =?us-ascii?Q?IYzO0VDhtRzGUDF4goHbySGtaa1a6spGGQtAezqwh0HygXcBREJZP1XUdKi1?= =?us-ascii?Q?Tyfii2h6gPkl2jBfJOv8XQByu6KhmpFCII2B3nFGAVCCwe1CMzy4Oy32PxQY?= =?us-ascii?Q?3s1HBvRdNHfpx3SA9l8LLutc61Twthobooihf+stpqaNLfLplZgwC3i9ikl1?= =?us-ascii?Q?WQVguMsYlalAWCqSPjoEtUTMt5AbvmPrf+fEyy4BsewJZuwZzDWQxFFgkHLq?= =?us-ascii?Q?fLZ3t0cLvmHsOXDWTfpXpPCTZTWh2Eo0SECOAQGDiAw0m4J4ML4/ItQXHMw1?= =?us-ascii?Q?oc5YjdSOZSqbG9pGYTdy/l3p4SZ1gClYf5VTYsvmoW31n1+OciX6QOTIjfAK?= =?us-ascii?Q?3/FXy8BrrW8Ext8kp2CD9gqVPc8HoKJdNF3NHUOV0GkN3RrYrpXhevP4LPeh?= =?us-ascii?Q?LQmm7Wsvr5M0XWSB8zH2M9JqU6ZjNxlSuao9yHq2mBOF7n29z0r/SPOgSGxJ?= =?us-ascii?Q?LHalykTNDynx89ZEOqW7HJywXnbZkl6m0Gb089x38dCh3v2B6vnz+LBO+d8a?= =?us-ascii?Q?+lwzBBQz0V/621IPDjupOiUy2IWOuS18E+o+3cSwy67HBVxxhDUSb/xIi5+o?= =?us-ascii?Q?cf1a36rg5xk9/1jdfbc2/ggDKGHg1X3eMiKgBNUbsTiqypLwYdfY3uYsEf2C?= =?us-ascii?Q?aZDeltXEl4zzIBMCkCNQLyzo6VfFu1G2u2FouVucES02sZW+BnARMvTfzcLf?= =?us-ascii?Q?HvxoldeREgGO0fsEsSMahMmHjrnvKK4l4yHh5IilLDZznDBSH38Nk3PnW0rP?= =?us-ascii?Q?sLqWIJgY+9ut2uztlgR17E0umSW68QUr4736ZeEwotkHjOYmtr2P7awdMRDo?= =?us-ascii?Q?vdTTh2Ck9giuq2JzQppmUB9hIxYhne3q9727gIVyQi0NgLS2XlYWDS7W+Irc?= =?us-ascii?Q?yE/6ddVHzG/JAZTsWvOyl5ReJF4zpq449NNIc+k527U8ujQ8gpvLihiM9oX5?= =?us-ascii?Q?MP2LG2D9joJg7rmwgud82utkiJLZL4i6AjkrPudaEGj2PvH6kFOQulneYlp+?= =?us-ascii?Q?a/a/LWCdVM2PHiFHCLQNTXkVMDGsvAPLBth7tqOi6VMjEKOZa1TXpYvMDeJy?= =?us-ascii?Q?1UcayF3wD2lsOLYioo+W9GaGY=3D?=
X-Microsoft-Exchange-Diagnostics: 1; AMXPR07MB151; 6:TZwDyk5TrCxEvsvphcvoK92dpd9wcR2hAoBWMHkoz7LXbOApE3PM/IdvBItSBjPP5EQbK6TJUjw81B08xziQqjD0OjeGNs8JWza8U9p9+5UtkF1HyPVveZxKSZE12IAIDb2tZch0gvtM8MxA4Qe1FWlk0AjkSeIiyhq0G5GkZFCTHG41txbaFtOg2/ZWQ88OOnHS+E07d2iwkwlJChZ6UX3WWnprz3G4v2vnVV3MdOs5Q0Ma3vb51iVsQkINS1LbCNHPw7ZECOPhjG1AE2cdRUS82K51G0WraV1FAwBhU3encSwr2onMJnqKixP+SnIssTkCzuO1MyT/ScHkde0rkSUuUrgpOLNMojb2nsjMCvoA9F/r0pxYWwqHx6lfv21D; 5:rYPfq7j+60KuqEQ0UleSzrj7i3lEyOxkkVDjqiATqIgE+EulSmQ4NHE/jJDlBT89hakVjZouQnYg6ReEkvtZsYKIvO3X2AHvFCBYbJXQP2P5Y7LQldZ36Sk5xChgi57HkIU1D4EK8xkCjK20DBAsKg==; 24:iGmFMYz8DKQbRnmg09cmx78O2JYnm+/2YCoZakmrBtWLuZisfKZL5zrKdcQ/xKmqTStwViejtc94ehozPR2BT+XgcY4zdIVNzGKiKMPa7Cs=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; AMXPR07MB151; 7:dt5Qwz1OgiOhqnfBvr/872qlTAEvO0SWuH5+gqk63zz72GIgd8uIV8614vnmwDKoAbTYd304vTKVHrBAolfkBnnJ8ySuhgxinal6uVSxy5EiLl3YnjPvx3dqrpd2P7odAiPamF/S/FlCZ8IzqbocJ5UsADNUct07qoe82ORx3wd+GjzIs6LyRJnxlutP/Qyjy/5guFFTqNKB2ukrOQGRl5quSkFTTXLAQHtNnsJsHppGHvfRrvzSVbBint9nvLcV//F1yeoPL7b9PtPlzcrAIVeh/8LCreEae2BTW8YOREZ7iG4MXTa9ctGyTGD7BwWUcTnvwxIaQPBZBDH3pTvhGYdj6EeMHIcGX8pNtjVUic8=
X-OriginatorOrg: sky.uk
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Nov 2016 11:58:07.0534 (UTC)
X-MS-Exchange-CrossTenant-Id: 4f86cebc-57e2-40a0-86cc-01d73be93ba0
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f86cebc-57e2-40a0-86cc-01d73be93ba0; Ip=[176.255.244.224];  Helo=[email.bskyb.com]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMXPR07MB151
Archived-At: 
Subject: Re: [Idr] One week extension to WGLC for draft-ietf-idr-large-community
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, 18 Nov 2016 11:58:13 -0000

Apologies for a 2nd post - I hit send too early. The intended version is be=
low:

Only bit pattern duplication makes sense here, as protocol cannot understan=
d operator defined semantics.
I would say that large and 1997 communities are different things and cannot=
 be duplicates at the protocol level.
Both would be required to be able to perform a viable transition from 1997 =
to large..
Operators can configure policy that would choose which took precedence (reg=
ardless of semantic equivalence or otherwise).

Ian

-----Original Message-----
From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Dickinson, Ian
Sent: 18 November 2016 11:47
To: t.petch ; John G. Scudder ; idr w=
g 
Subject: Re: [Idr] One week extension to WGLC for draft-ietf-idr-large-comm=
unity

I would say that large and 1997 communities are different things and cannot=
 be duplicates at the protocol level.
Operators can configure policy that would choose which took precedence (reg=
ardless of semantic equivalence or otherwise).

Ian

-----Original Message-----
From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of t.petch
Sent: 18 November 2016 10:58
To: John G. Scudder ; idr wg 
Subject: Re: [Idr] One week extension to WGLC for draft-ietf-idr-large-comm=
unity

John

I am happy with the proposed text but ...

An issue that came up earlier and that I did not see resolved was what
constitutes a duplicate.  This is binary so we don't have the issues
that
character comparisons do but is it the same bit pattern from start to
finish, the same semantics or something between the two?  A case I have
in mind is when the same semantics appear in RFC1997 format and also
in LC format; is that a duplicate?.

Tom Petch

----- Original Message -----
From: "John G. Scudder" 
To: "idr wg" 
Sent: Wednesday, November 16, 2016 4:01 AM

> Hi Everyone,
>
> After Bruno's comments regarding RFC 7606 style error handling being
invoked to react to duplicate community values, a few people have
expressed (on and off list) concern that even though that is not
intended, the -08 text as written could possibly be misinterpreted by a
zealous implementor. To resolve this, I propose adding the following, or
similar, to the Error Handling section:
>
> o A BGP Large Communities attribute SHALL NOT be considered malformed
due
>   solely to presence of duplicate community values. Such duplicates
MUST be handled
>   by removing them as specified in Section 2.
>
> IMO this clarifies the intent of the document and doesn't represent a
normative change. Hopefully it will resolve the concerns of those who
were concerned about and opposed to 7606-style handling for duplicates.
>
> The authors have indicated they'll incorporate the text in an -09
(assuming of course that the consensus of the WGLC doesn't go against
the change).
>
> Regards,
>
> --John

Information in this email including any attachments may be privileged, conf=
idential and is intended exclusively for the addressee. The views expressed=
 may not be official policy, but the personal views of the originator. If y=
ou have received it in error, please notify the sender by return e-mail and=
 delete it from your system. You should not reproduce, distribute, store, r=
etransmit, use or disclose its contents to anyone. Please note we reserve t=
he right to monitor all e-mail communication through our internal and exter=
nal networks. SKY and the SKY marks are trademarks of Sky plc and Sky Inter=
national AG and are used under licence.

Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Reg=
istration No. 2067075) and Sky Subscribers Services Limited (Registration N=
o. 2340150) are direct or indirect subsidiaries of Sky plc (Registration No=
. 2247735). All of the companies mentioned in this paragraph are incorporat=
ed in England and Wales and share the same registered office at Grant Way, =
Isleworth, Middlesex TW7 5QD.


From nobody Fri Nov 18 11:37:15 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAEFE1294F9 for ; Fri, 18 Nov 2016 11:37:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.518
X-Spam-Level: 
X-Spam-Status: No, score=-15.518 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=-1.497, 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 zFx38DCL4b84 for ; Fri, 18 Nov 2016 11:37:12 -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 DE961129736 for ; Fri, 18 Nov 2016 11:37:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4543; q=dns/txt; s=iport; t=1479497831; x=1480707431; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=jrfvjhLdhUF7ts4e8Pjz9p5ImygUkOOXDyMJNJ5VEsI=; b=Gas7HbodFK4+w+PJEuM5lL0m7wlgEda5kafzHWr2V8tDRQMk2uYkc5wA GHez6F+L1tiyl2ASTexRDHJxK9NGTR+H8NiYzURFj3mMyMuJz4SM4/cu9 guCKqDFus0GRdS2CpDzrfAvUHTtbYcE/pv27TVDg66gF7pPcRPTm6vXVk 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AdAQD+Vy9Y/40NJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzcBAQEBAR9YgQCNP5cPlGaCBx0LhXkCggw/FAECAQEBAQEBAWI?= =?us-ascii?q?ohGgBAQEDAQEBATc0CwUHBAIBCBEEAQEBHgkHJwsUCQgCBA4FFIhQCA6uQItIA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBFwWGPIF9gl2EGwoHARwHMYJ5gjAFmksBkHG?= =?us-ascii?q?BcIR3iUCNW4QKAR43XS4dgygcgV1yhgcPF4IWAQEB?=
X-IronPort-AV: E=Sophos;i="5.31,659,1473120000"; d="scan'208";a="172975605"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Nov 2016 19:37:10 +0000
Received: from xch-rcd-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id uAIJbAX0022487 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 18 Nov 2016 19:37:10 GMT
Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 18 Nov 2016 13:37:09 -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; Fri, 18 Nov 2016 13:37:09 -0600
From: "Jakob Heitz (jheitz)" 
To: "Dickinson, Ian" 
Thread-Topic: [Idr] One week extension to WGLC for draft-ietf-idr-large-community
Thread-Index: AQHSPlcVO6RKnaa63k2qyfOXORnq2aDZN6gAgAAvdgD//7HLX4AAnUfQgADIPACAAGt8AIAAOk8AgAA/yICAAzdhPIAAb3mAgAADFwCAABuwow==
Date: Fri, 18 Nov 2016 19:37:09 +0000
Message-ID: <990BE5BA-03E1-4A31-B86C-76BB2DACDFFE@cisco.com>
References:   <27701_1479159582_582A2F1E_27701_6903_1_53C29892C857584299CBF5D05346208A1EC77FE1@OPEXCLILM21.corporate.adroot.infra.ftgroup> <736EA2CC-3DD1-4F14-96ED-2916E62F6F02@cisco.com> <26709_1479217575_582B11A7_26709_12999_1_53C29892C857584299CBF5D05346208A1EC79584@OPEXCLILM21.corporate.adroot.infra.ftgroup>   <20161116001246.GB27230@pfrc.org> <4EB6222D-86A4-4A83-AF8C-364CB52B8422@juniper.net> <004201d2418b$887208c0$4001a8c0@gateway.2wire.net> <9B3BFE0A18160E40BAF1950414D10FAE6174003E@WPMBX010.bskyb.com>, <9B3BFE0A18160E40BAF1950414D10FAE6174005D@WPMBX010.bskyb.com>
In-Reply-To: <9B3BFE0A18160E40BAF1950414D10FAE6174005D@WPMBX010.bskyb.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: 
Cc: idr wg 
Subject: Re: [Idr] One week extension to WGLC for draft-ietf-idr-large-community
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, 18 Nov 2016 19:37:14 -0000

What he said

Thanks,
Jakob.

> On Nov 18, 2016, at 3:58 AM, Dickinson, Ian  wrote:
>=20
> Apologies for a 2nd post - I hit send too early. The intended version is =
below:
>=20
> Only bit pattern duplication makes sense here, as protocol cannot underst=
and operator defined semantics.
> I would say that large and 1997 communities are different things and cann=
ot be duplicates at the protocol level.
> Both would be required to be able to perform a viable transition from 199=
7 to large..
> Operators can configure policy that would choose which took precedence (r=
egardless of semantic equivalence or otherwise).
>=20
> Ian
>=20
> -----Original Message-----
> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Dickinson, Ian
> Sent: 18 November 2016 11:47
> To: t.petch ; John G. Scudder ; idr=
 wg 
> Subject: Re: [Idr] One week extension to WGLC for draft-ietf-idr-large-co=
mmunity
>=20
> I would say that large and 1997 communities are different things and cann=
ot be duplicates at the protocol level.
> Operators can configure policy that would choose which took precedence (r=
egardless of semantic equivalence or otherwise).
>=20
> Ian
>=20
> -----Original Message-----
> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of t.petch
> Sent: 18 November 2016 10:58
> To: John G. Scudder ; idr wg 
> Subject: Re: [Idr] One week extension to WGLC for draft-ietf-idr-large-co=
mmunity
>=20
> John
>=20
> I am happy with the proposed text but ...
>=20
> An issue that came up earlier and that I did not see resolved was what
> constitutes a duplicate.  This is binary so we don't have the issues
> that
> character comparisons do but is it the same bit pattern from start to
> finish, the same semantics or something between the two?  A case I have
> in mind is when the same semantics appear in RFC1997 format and also
> in LC format; is that a duplicate?.
>=20
> Tom Petch
>=20
> ----- Original Message -----
> From: "John G. Scudder" 
> To: "idr wg" 
> Sent: Wednesday, November 16, 2016 4:01 AM
>=20
>> Hi Everyone,
>>=20
>> After Bruno's comments regarding RFC 7606 style error handling being
> invoked to react to duplicate community values, a few people have
> expressed (on and off list) concern that even though that is not
> intended, the -08 text as written could possibly be misinterpreted by a
> zealous implementor. To resolve this, I propose adding the following, or
> similar, to the Error Handling section:
>>=20
>> o A BGP Large Communities attribute SHALL NOT be considered malformed
> due
>>  solely to presence of duplicate community values. Such duplicates
> MUST be handled
>>  by removing them as specified in Section 2.
>>=20
>> IMO this clarifies the intent of the document and doesn't represent a
> normative change. Hopefully it will resolve the concerns of those who
> were concerned about and opposed to 7606-style handling for duplicates.
>>=20
>> The authors have indicated they'll incorporate the text in an -09
> (assuming of course that the consensus of the WGLC doesn't go against
> the change).
>>=20
>> Regards,
>>=20
>> --John
>=20
> Information in this email including any attachments may be privileged, co=
nfidential and is intended exclusively for the addressee. The views express=
ed may not be official policy, but the personal views of the originator. If=
 you have received it in error, please notify the sender by return e-mail a=
nd delete it from your system. You should not reproduce, distribute, store,=
 retransmit, use or disclose its contents to anyone. Please note we reserve=
 the right to monitor all e-mail communication through our internal and ext=
ernal networks. SKY and the SKY marks are trademarks of Sky plc and Sky Int=
ernational AG and are used under licence.
>=20
> Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (R=
egistration No. 2067075) and Sky Subscribers Services Limited (Registration=
 No. 2340150) are direct or indirect subsidiaries of Sky plc (Registration =
No. 2247735). All of the companies mentioned in this paragraph are incorpor=
ated in England and Wales and share the same registered office at Grant Way=
, Isleworth, Middlesex TW7 5QD.
>=20
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr


From nobody Fri Nov 18 11:40:51 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E030B1294C2 for ; Fri, 18 Nov 2016 11:40:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.018
X-Spam-Level: 
X-Spam-Status: No, score=-16.018 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=-1.497, 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 dVJFH88bpf94 for ; Fri, 18 Nov 2016 11:40:48 -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 1E4C41293F8 for ; Fri, 18 Nov 2016 11:40:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4948; q=dns/txt; s=iport; t=1479498048; x=1480707648; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Wky1GtVn5glCg3hc6OS/IP9C0tsj6KhRzpF9IkkzfMY=; b=jD6/94JMeO2HCWuwW/MEuHJoC2fxdVyCm34FnG/8EEr2s3VWRhGZoZoL VMYtvRQoOYITKW1UN8Zkw2IrtBGbeT2oFt3DPnsR+6FRdBdYJ27cKXCvT kunng+PWo6S+AC/+XAhHr32TusbGL7MpreIqPdKNXSxlZ17ToBs196V/h 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AdAQDDWC9Y/4QNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzcBAQEBAR9YgQCNP5cPlGaCBx0LhXkCggw/FAECAQEBAQEBAWI?= =?us-ascii?q?ohGgBAQEDAQEBATc0CwUHBAIBCBEEAQEBHgkHJwsUCQgCBA4FFIhQCA6uQItIA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBFwWGPIF9CIJVhBsKBwEcBzGCeYIwBZpLAZB?= =?us-ascii?q?xgXCEd4lAjVuECgEeN10uHYMoHIFdcoYHDxeCFgEBAQ?=
X-IronPort-AV: E=Sophos;i="5.31,659,1473120000"; d="scan'208";a="350304599"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Nov 2016 19:40:47 +0000
Received: from XCH-ALN-012.cisco.com (xch-aln-012.cisco.com [173.36.7.22]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id uAIJek0q024764 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 18 Nov 2016 19:40:47 GMT
Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-012.cisco.com (173.36.7.22) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 18 Nov 2016 13:40:45 -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; Fri, 18 Nov 2016 13:40:46 -0600
From: "Jakob Heitz (jheitz)" 
To: "Dickinson, Ian" 
Thread-Topic: [Idr] One week extension to WGLC for draft-ietf-idr-large-community
Thread-Index: AQHSPlcVO6RKnaa63k2qyfOXORnq2aDZN6gAgAAvdgD//7HLX4AAnUfQgADIPACAAGt8AIAAOk8AgAA/yICAAzdhPIAAb3mAgAADFwCAABuwo4AAAQKT
Date: Fri, 18 Nov 2016 19:40:46 +0000
Message-ID: <500D9234-E929-4134-884C-ADDF024AF77A@cisco.com>
References:   <27701_1479159582_582A2F1E_27701_6903_1_53C29892C857584299CBF5D05346208A1EC77FE1@OPEXCLILM21.corporate.adroot.infra.ftgroup> <736EA2CC-3DD1-4F14-96ED-2916E62F6F02@cisco.com> <26709_1479217575_582B11A7_26709_12999_1_53C29892C857584299CBF5D05346208A1EC79584@OPEXCLILM21.corporate.adroot.infra.ftgroup>   <20161116001246.GB27230@pfrc.org> <4EB6222D-86A4-4A83-AF8C-364CB52B8422@juniper.net> <004201d2418b$887208c0$4001a8c0@gateway.2wire.net> <9B3BFE0A18160E40BAF1950414D10FAE6174003E@WPMBX010.bskyb.com>, <9B3BFE0A18160E40BAF1950414D10FAE6174005D@WPMBX010.bskyb.com>, <990BE5BA-03E1-4A31-B86C-76BB2DACDFFE@cisco.com>
In-Reply-To: <990BE5BA-03E1-4A31-B86C-76BB2DACDFFE@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: 
Cc: idr wg 
Subject: Re: [Idr] One week extension to WGLC for draft-ietf-idr-large-community
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, 18 Nov 2016 19:40:50 -0000

I don't believe that any text is required to resolve this.

Thanks,
Jakob.

> On Nov 18, 2016, at 11:37 AM, Jakob Heitz (jheitz)  wro=
te:
>=20
> What he said
>=20
> Thanks,
> Jakob.
>=20
>> On Nov 18, 2016, at 3:58 AM, Dickinson, Ian  wrote=
:
>>=20
>> Apologies for a 2nd post - I hit send too early. The intended version is=
 below:
>>=20
>> Only bit pattern duplication makes sense here, as protocol cannot unders=
tand operator defined semantics.
>> I would say that large and 1997 communities are different things and can=
not be duplicates at the protocol level.
>> Both would be required to be able to perform a viable transition from 19=
97 to large..
>> Operators can configure policy that would choose which took precedence (=
regardless of semantic equivalence or otherwise).
>>=20
>> Ian
>>=20
>> -----Original Message-----
>> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Dickinson, Ian
>> Sent: 18 November 2016 11:47
>> To: t.petch ; John G. Scudder ; id=
r wg 
>> Subject: Re: [Idr] One week extension to WGLC for draft-ietf-idr-large-c=
ommunity
>>=20
>> I would say that large and 1997 communities are different things and can=
not be duplicates at the protocol level.
>> Operators can configure policy that would choose which took precedence (=
regardless of semantic equivalence or otherwise).
>>=20
>> Ian
>>=20
>> -----Original Message-----
>> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of t.petch
>> Sent: 18 November 2016 10:58
>> To: John G. Scudder ; idr wg 
>> Subject: Re: [Idr] One week extension to WGLC for draft-ietf-idr-large-c=
ommunity
>>=20
>> John
>>=20
>> I am happy with the proposed text but ...
>>=20
>> An issue that came up earlier and that I did not see resolved was what
>> constitutes a duplicate.  This is binary so we don't have the issues
>> that
>> character comparisons do but is it the same bit pattern from start to
>> finish, the same semantics or something between the two?  A case I have
>> in mind is when the same semantics appear in RFC1997 format and also
>> in LC format; is that a duplicate?.
>>=20
>> Tom Petch
>>=20
>> ----- Original Message -----
>> From: "John G. Scudder" 
>> To: "idr wg" 
>> Sent: Wednesday, November 16, 2016 4:01 AM
>>=20
>>> Hi Everyone,
>>>=20
>>> After Bruno's comments regarding RFC 7606 style error handling being
>> invoked to react to duplicate community values, a few people have
>> expressed (on and off list) concern that even though that is not
>> intended, the -08 text as written could possibly be misinterpreted by a
>> zealous implementor. To resolve this, I propose adding the following, or
>> similar, to the Error Handling section:
>>>=20
>>> o A BGP Large Communities attribute SHALL NOT be considered malformed
>> due
>>> solely to presence of duplicate community values. Such duplicates
>> MUST be handled
>>> by removing them as specified in Section 2.
>>>=20
>>> IMO this clarifies the intent of the document and doesn't represent a
>> normative change. Hopefully it will resolve the concerns of those who
>> were concerned about and opposed to 7606-style handling for duplicates.
>>>=20
>>> The authors have indicated they'll incorporate the text in an -09
>> (assuming of course that the consensus of the WGLC doesn't go against
>> the change).
>>>=20
>>> Regards,
>>>=20
>>> --John
>>=20
>> Information in this email including any attachments may be privileged, c=
onfidential and is intended exclusively for the addressee. The views expres=
sed may not be official policy, but the personal views of the originator. I=
f you have received it in error, please notify the sender by return e-mail =
and delete it from your system. You should not reproduce, distribute, store=
, retransmit, use or disclose its contents to anyone. Please note we reserv=
e the right to monitor all e-mail communication through our internal and ex=
ternal networks. SKY and the SKY marks are trademarks of Sky plc and Sky In=
ternational AG and are used under licence.
>>=20
>> Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (=
Registration No. 2067075) and Sky Subscribers Services Limited (Registratio=
n No. 2340150) are direct or indirect subsidiaries of Sky plc (Registration=
 No. 2247735). All of the companies mentioned in this paragraph are incorpo=
rated in England and Wales and share the same registered office at Grant Wa=
y, Isleworth, Middlesex TW7 5QD.
>>=20
>> _______________________________________________
>> Idr mailing list
>> Idr@ietf.org
>> https://www.ietf.org/mailman/listinfo/idr
>=20
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr


From nobody Fri Nov 18 12:01:54 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B97761293F0; Fri, 18 Nov 2016 12:01:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.017
X-Spam-Level: 
X-Spam-Status: No, score=-16.017 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=-1.497, 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 cZrmUONvpQPY; Fri, 18 Nov 2016 12:01:48 -0800 (PST)
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 5409F129699; Fri, 18 Nov 2016 12:01:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14572; q=dns/txt; s=iport; t=1479499292; x=1480708892; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=K8QBLOglY2sP+p0LxVvZNPhxqewNYyFxF0xuUOLB37A=; b=GPaRpQra3lEsfiEyLha06Rvh572ypybjTFdfrI3KaV9j7SSqI6oNK2qQ 7kejE0j+e5tdHRslOhTbUiDM9lXFICGv83nko6Xq9yjmxrnuJ8Rr9GxNo mS3VeqQ8D3vhfV/tcraZMSOi7NmWBB3vGmkIzNHJ9jAz2vU2Hy+kOVTll 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AjAQD7XC9Y/4oNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgnNEAQEBAQEfWIEAjT+XD49LhRuCBx0BCoV5AoIOPxQBAgEBAQE?= =?us-ascii?q?BAQFiHQuEaAEBAQMBAQEBKkELBQsCAQgRBAEBAScHJwsUCQgCBA4FiGQIDq5Gi?= =?us-ascii?q?0cBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYY8gX0IglWEGxEBUoJ7gjAFlGOFaAG?= =?us-ascii?q?QcQKBboR3iUCNW4QKAR43XS4dg1yBRXKGBwcIF4IWAQEB?=
X-IronPort-AV: E=Sophos;i="5.31,659,1473120000";  d="scan'208,217";a="348406598"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Nov 2016 20:01:31 +0000
Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id uAIK1V4D005154 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 18 Nov 2016 20:01:31 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; Fri, 18 Nov 2016 14:01:30 -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; Fri, 18 Nov 2016 14:01:30 -0600
From: "Jakob Heitz (jheitz)" 
To: "bruno.decraene@orange.com" 
Thread-Topic: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
Thread-Index: AQHSQXkWcwxsdEyE5EyI6kdWHGEfNaDfKimQ
Date: Fri, 18 Nov 2016 20:01:30 +0000
Message-ID: <37224750-4065-40E3-B6F4-571DED698563@cisco.com>
References: <20161116061556.GG1073@dhcp-9341.meeting.ietf.org> <20161117013640.GB6217@pfrc.org> <16426_1479400131_582DDAC3_16426_1669_1_53C29892C857584299CBF5D05346208A1EC87201@OPEXCNORM2F.corporate.adroot.infra.ftgroup> <20161118004548.GK1072@dhcp-9341.meeting.ietf.org> <16418_1479457940_582EBC93_16418_290_1_53C29892C857584299CBF5D05346208A1EC8DEA5@OPEXCLILM21.corporate.adroot.infra.ftgroup> , <13357_1479459134_582EC13E_13357_5786_1_53C29892C857584299CBF5D05346208A1EC8FF18@OPEXCLILM21.corporate.adroot.infra.ftgroup>
In-Reply-To: <13357_1479459134_582EC13E_13357_5786_1_53C29892C857584299CBF5D05346208A1EC8FF18@OPEXCLILM21.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: multipart/alternative; boundary="_000_37224750406540E3B6F4571DED698563ciscocom_"
MIME-Version: 1.0
Archived-At: 
Cc: "idr@ietf.org" , "grow@ietf.org" 
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 18 Nov 2016 20:01:51 -0000

--_000_37224750406540E3B6F4571DED698563ciscocom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Not necessary. You can already send whatever you want. In iOS-XR, it just h=
exdumps it all. The only thing that will change is that it will print it in=
 UTF8 as well. It will still hexdump. If you want no hexdump, then we need =
a new subcode.

Thanks,
Jakob.

On Nov 18, 2016, at 12:52 AM, "bruno.decraene@orange.com" > wrote:

Thanks.
--Bruno

From: Job Snijders [mailto:job@instituut.net]
Sent: Friday, November 18, 2016 9:46 AM
To: DECRAENE Bruno IMT/OLN
Cc: Jeffrey Haas; Job Snijders; grow@ietf.org; idr@ie=
tf.org
Subject: Re: [GROW] [Idr] draft-snijders-idr-shutdown-00: Drop a line in th=
e peer's syslog at shutdown

Hi Bruno,

John Scudder was kind enough to provide extensive argumentation offlist on =
why something along these lines should be done. We'll work on a proposal. T=
he length indicator is a neat idea, thanks for sharing.

Job

On Fri, 18 Nov 2016 at 17:32, > wrote:


> From: Job Snijders [mailto:job@instituut.net]  =
> Sent: Friday, November 18, 2016 1:46 AM
>
 > On Thu, Nov 17, 2016 at 04:28:50PM +0000, bruno.decraene@orange.com wrote:
 > > I support the draft.
 > > I also support Jeff's idea to re-use existing sub-code(s).
 >
 > Thanks for your support. Based on the feedback received so far the next
 > version of this draft will recycle Cease subcode 2.
 >
 > > 1 possible comment: the length of the "Shutdown Communication" field
 > > seems implied from the length of the data field, rather than being
 > > explicitly indicated.
 >
 > The text is explicit about the length:
 >
 >     "followed by a freeform UTF-8 encoded string with a REQUIRED maximum
 >     length of 128 octets. "
 >
 > and further:
 >
 >     "This document tries to minimize the effects of visual spoofing by
 >     allowing UNICODE only where local script is expected and needed, and
 >     by limiting the length of the Shutdown Communication."
 >
 > > If so, it seems that we are closing the possibility to advertise
 > > additional data/usage, in some future. What about adding a TLV format?
 >
 > I object to using a TLV. Don't forget this is already at a TLV level:
 > Cease NOTIFICATION. If one would want to define a TLV inside this TLV, a
 > new Cease subcode can be requested from IANA.

What if someone needs to advertise additional info to an existing cease sub=
code? cf Jeff's email regarding the pain of changing subcodes.
So let's forget about the TLV. What about just adding the length of the str=
ing? This would still allow adding fields after the string, while having a =
negligible/null cost?

Kind regards,
-- Bruno

 > Kind regards,
 >
 > Job

___________________________________________________________________________=
______________________________________________

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

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

___________________________________________________________________________=
______________________________________________

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

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


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

--_000_37224750406540E3B6F4571DED698563ciscocom_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable







Not necessary. You can already send whatever you want. In iOS-XR, it j=
ust hexdumps it all. The only thing that will change is that it will print =
it in UTF8 as well. It will still hexdump. If you want no hexdump, then we =
need a new subcode.




Thanks,

Jakob.




On Nov 18, 2016, at 12:52 AM, "bruno.decraene@orange.com" <bruno.decraene@orange.com> wrote:














Thanks.=



--Bruno=



 <=
/p>







From: Job Snij=
ders [mailto:job@instituut.net]


Sent: Friday, November 18, 2016 9:46 AM

To: DECRAENE Bruno IMT/OLN

Cc: Jeffrey Haas; Job Snijders; gro=
w@ietf.org;
idr@ietf.org

Subject: Re: [GROW] [Idr] draft-snijders-idr-shutdown-00: Drop a lin=
e in the peer's syslog at shutdown






 




Hi Bruno,



John Scudder was kind enough to provide extensive argumentation offlist on =
why something along these lines should be done. We'll work on a proposal. T=
he length indicator is a neat idea, thanks for sharing.




Job




 






On Fri, 18 Nov 2016 at 17:32, <bruno.decraene@orange.com> wrote:










> From: Job Snijders [mailto:job@instituut.net]  > Sent: Friday, November 18, 20=
16 1:46 AM

>

 > On Thu, Nov 17, 2016 at 04:28:50PM +0000, 
bruno.decraene@orange.com wrote:

 > > I support the draft.

 > > I also support Jeff's idea to re-use existing sub-code(s).<=
br>
 >

 > Thanks for your support. Based on the feedback received so far t=
he next

 > version of this draft will recycle Cease subcode 2.

 >

 > > 1 possible comment: the length of the "Shutdown Commun=
ication" field

 > > seems implied from the length of the data field, rather tha=
n being

 > > explicitly indicated.

 >

 > The text is explicit about the length:

 >

 >     "followed by a freeform UTF-8 encoded st=
ring with a REQUIRED maximum

 >     length of 128 octets. "

 >

 > and further:

 >

 >     "This document tries to minimize the eff=
ects of visual spoofing by

 >     allowing UNICODE only where local script is e=
xpected and needed, and

 >     by limiting the length of the Shutdown Commun=
ication."

 >

 > > If so, it seems that we are closing the possibility to adve=
rtise

 > > additional data/usage, in some future. What about adding a =
TLV format?

 >

 > I object to using a TLV. Don't forget this is already at a TLV l=
evel:

 > Cease NOTIFICATION. If one would want to define a TLV inside thi=
s TLV, a

 > new Cease subcode can be requested from IANA.



What if someone needs to advertise additional info to an existing cease sub=
code? cf Jeff's email regarding the pain of changing subcodes.

So let's forget about the TLV. What about just adding the length of the str=
ing? This would still allow adding fields after the string, while having a =
negligible/null cost?



Kind regards,

-- Bruno



 > Kind regards,

 >

 > Job



___________________________________________________________________________=
______________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.



This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and dele=
te this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.

Thank you.










______________________________________________________________________=
___________________________________________________

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

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









_______________________________________________

Idr mailing list

Idr@ietf.org

https://www.iet=
f.org/mailman/listinfo/idr








--_000_37224750406540E3B6F4571DED698563ciscocom_--


From nobody Fri Nov 18 21:19:28 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00498129558 for ; Fri, 18 Nov 2016 21:19:27 -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 EamkLTfRRtn7 for ; Fri, 18 Nov 2016 21:19:25 -0800 (PST)
Received: from mail-yb0-x233.google.com (mail-yb0-x233.google.com [IPv6:2607:f8b0:4002: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 71A05129417 for ; Fri, 18 Nov 2016 21:19:25 -0800 (PST)
Received: by mail-yb0-x233.google.com with SMTP id v78so84645443ybe.3 for ; Fri, 18 Nov 2016 21:19:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=k4M+N9OepRgAbOUlQb/L/vPoVNMxBPqf5Q00gx2gQPY=; b=iHzVkbgXe2Ypk4ZOwcojo2SvsGCrWBd+V+RPtGbBceaU9XPHNn9dyjny4EuLu5wNaf zxO+1Z6Cu1EcXUmZX7KmUl/QPHCgXuKcTJn/nJ9bp501YWM+xUztIwbpUVJQfC4/U3aG 2l+UBH7Dlh3Hg+w+kJnSXbkd7M67HPYY7+30BN2I1YMwluOZCdwi674/d3d7XPWO/XRt T4En2RpfC1wxRPvwbImmfcrZHMYFSIUAY1D28bZWnPXMnJW0CWXlUnstu0KuL0qjlDUJ oAthrUtzRTGkFTKBtmn6QcfXeJxEirTm6G9Ay5KMh75jOx7xgecLxiWq82dRKoZ1lttp hudw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=k4M+N9OepRgAbOUlQb/L/vPoVNMxBPqf5Q00gx2gQPY=; b=I0c3e6JE/VuFJOHwI2czh3ZLzHK+BXYP1dPC7661mPI97117iho1hwsu0wBlD8oL7B CFFdCLJwW0dR+pNeHX+7948uY0s4oRIISpk4KaxCzvg44PseeRBIYAR9vWqLMKfrKeEo 8cM9RoqrNykMmy/A41dEWrJyMKIoA1bkTrx0CD8rDciSlfRxkcgco+GEYx9oF4r7M36m 45onAQ9jpjZVal9keDzz4G9VciTua8iAy5EMsBx4qk4gsRd0NMda+vJEZfZV4Rrduhe4 lOgLfNWNf/0PxuygoFTR8TZDghNq5Zx7RYbYZeUkdHdB0beFtzormxFQzLKQ1plgU0nx i2tQ==
X-Gm-Message-State: AKaTC02d7NjlcJ6ceWUKo1WDXYvSQDo6F4lXEpGDsM5p9doWEg5nDxK2CdDWpNTqkd1W+6LawksPh4OKw+Xycg==
X-Received: by 10.37.108.8 with SMTP id h8mr1769372ybc.77.1479532764517; Fri, 18 Nov 2016 21:19:24 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.207.2 with HTTP; Fri, 18 Nov 2016 21:19:23 -0800 (PST)
In-Reply-To: <001201d2412c$30428d00$90c7a700$@ndzh.com>
References: <001201d2412c$30428d00$90c7a700$@ndzh.com>
From: Pushpasis Sarkar 
Date: Sat, 19 Nov 2016 10:49:23 +0530
Message-ID: 
To: Susan Hares 
Content-Type: multipart/alternative; boundary=001a11489cc2dcd9c90541a09095
Archived-At: 
Cc: idr wg 
Subject: Re: [Idr] draft-psarkar-idr-bgp-ls-node-admin-tag-extension - 1 week period to comment (11/17 - 11/24/2016)
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, 19 Nov 2016 05:19:27 -0000

--001a11489cc2dcd9c90541a09095
Content-Type: text/plain; charset=UTF-8

Hi Chairs,

I am not aware of any other IPR other than the one already disclosed
against this draft.

Thanks and Regards
-Pushpasis

On Fri, Nov 18, 2016 at 5:11 AM, Susan Hares  wrote:

> IDR-WG:
>
>
>
> Mea culpa.  draft-psarkar-idr-bgp-ls-node-admin-tag-extension was
> accepted during a WG LC call in 2015.  However, I forgot to ask for IPR
> (see threads below).   Pushpasis asked the chairs (John and Sue) last April
> and we did not answer him.   There is an IPR statement:
>
> https://datatracker.ietf.org/ipr/2558/
>
>
>
> Please consider the IPR statement.   Silence on the list means we will
> accept the draft with the IPR.
>
>
>
> Sue Hares
>
>
>
> Thread refs:
>
> https://www.ietf.org/mail-archive/web/idr/current/msg15213.html
>
> https://www.ietf.org/mail-archive/web/idr/current/msg14888.html
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
>

--001a11489cc2dcd9c90541a09095
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Chairs,

I am not aware of any other =
IPR other than the one already disclosed against this draft.

=

Thanks and Regards
-Pushpasis

On Fri, Nov 18, 2016 at 5:11 A=
M, Susan Hares <shares@ndzh.com> wrote:
IDR-WG:=C2=A0=
 
=C2=A0
Mea culpa.=C2=A0 draft-psarkar-idr-bgp-ls-node-admin-ta=
g-extension was accepted during a WG LC call in 2015.=C2=A0 However, I forg=
ot to ask for IPR (see threads below).=C2=A0 =C2=A0Pushpasis asked the chai=
rs (John and Sue) last April and we did not answer him. =C2=A0=C2=A0There i=
s an IPR statement:
https://datatracker.i=
etf.org/ipr/2558/
=
=C2=A0
Please consider the IPR statement.=
=C2=A0=C2=A0 Silence on the list means we will accept the draft with the IP=
R. 
=C2=A0
Sue Hares 
=
=C2=A0
Thread refs=
:
https://www.ietf.org/mail-archive/web/idr/current/msg=
15213.html
https://www.ietf.org/mail-archive/web/idr/curre=
nt/msg14888.html
=C2=A0
=C2=A0
=C2=A0
=C2=A0<=
/p>

_______________________________________________

Idr mailing list

Idr@ietf.org

https://www.ietf.org/mailman/listinfo/idr





--001a11489cc2dcd9c90541a09095--


From nobody Sat Nov 19 02:32:35 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8054A129651 for ; Sat, 19 Nov 2016 02:32:34 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] 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 g_ND9YgMmibV for ; Sat, 19 Nov 2016 02:32:32 -0800 (PST)
Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4261712946F for ; Sat, 19 Nov 2016 02:32:32 -0800 (PST)
Received: by mail-wm0-x229.google.com with SMTP id g23so73444558wme.1 for ; Sat, 19 Nov 2016 02:32:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=date:from:to:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=+i8vUkcGD2zC9313w6hSMUZQI0yEkwKD5L5YOEjoYas=; b=trKXOftAi0SduYvMkpBb7EAFvhF8QiJzSwHezvHGnV3H2vM26oa0s547HGTtJat5Su N8T4AxvvD6z6CpT44ZUjxicQ1Dk3dUn4UI8WcyfK+spCe/ds9aUlScDPrP84oDuFwTtD dy9W7ERiSYrxvhTDeokUB3TOql6zxav8C7FAYTAkMpI82O9zZ1hZ3OvO81uAwrHLZIbq VFjzIfeF47+1PswA7Y7qnOe6G6o3PNVi9vH7GLc5ggyUK0FEoTbyaEbNU0ol8XcNMyre 4gCz16I+AO0edH7HDq4wVNQdtSq80vb4JpVnqbCVHHktQWKk0AE2c3GLWIZ59NEdQUcq a3/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=+i8vUkcGD2zC9313w6hSMUZQI0yEkwKD5L5YOEjoYas=; b=RIa0erpyujNiyJtbD+RQh4KCAinJWRv6BlfWU8z3VO13amzsq3cnjnVof7yNusSUGo MS3D+AEQewEoIXcsLchLSsUaxAn/iWT5JhPqx0jbtXp0VdF6Ggw5JWYgBuavF9lA3Bd/ lsjGLAtCVMDLBNZWNyQFZCpm3JdlNZqWfUIXODVXOahfRStp6TlrOETuEAWYnPJ3vWNl XiNoHrkT7Ucq8CXmsDwn6uk39cN60Syzzfp8Ge10CdTs66FGShXvxJRhHl+ZrbPHgMp4 FCAO67BOccKPeTJwGR1pkEk65VBRfKudSTY3nHOUxUbQSdu0kpBpyD9zzjUeM6hStfbg FKNw==
X-Gm-Message-State: AKaTC03yogCRsxyrH1DEi8kXFw0Wu9sczUi0/N0X2QrtabpDhcr28DIMpcOq0PfBvKX0Pg==
X-Received: by 10.28.149.79 with SMTP id x76mr2774736wmd.27.1479551550505; Sat, 19 Nov 2016 02:32:30 -0800 (PST)
Received: from localhost ([2001:67c:208c:10:1d57:e1da:9ff:e79d]) by smtp.gmail.com with ESMTPSA id v10sm13524273wji.29.2016.11.19.02.32.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 19 Nov 2016 02:32:28 -0800 (PST)
Date: Sat, 19 Nov 2016 11:32:26 +0100
From: Job Snijders 
To: idr@ietf.org
Message-ID: <20161119103226.GN1072@dhcp-9341.meeting.ietf.org>
References: <20161116061556.GG1073@dhcp-9341.meeting.ietf.org> <20161117013640.GB6217@pfrc.org> <16426_1479400131_582DDAC3_16426_1669_1_53C29892C857584299CBF5D05346208A1EC87201@OPEXCNORM2F.corporate.adroot.infra.ftgroup> <20161118004548.GK1072@dhcp-9341.meeting.ietf.org> <16418_1479457940_582EBC93_16418_290_1_53C29892C857584299CBF5D05346208A1EC8DEA5@OPEXCLILM21.corporate.adroot.infra.ftgroup>  <13357_1479459134_582EC13E_13357_5786_1_53C29892C857584299CBF5D05346208A1EC8FF18@OPEXCLILM21.corporate.adroot.infra.ftgroup> <37224750-4065-40E3-B6F4-571DED698563@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <37224750-4065-40E3-B6F4-571DED698563@cisco.com>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.7.1 (2016-10-04)
Archived-At: 
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 19 Nov 2016 10:32:34 -0000

Hi Jakob, Working group,

It is for "defensive" purposes: what if utf8 turns out to be terrible,
then cease subcode 2 can still be used but we can put something else in
the datafield trailing the subcode.

the advantage of using a length field is that we avoid discussing types
and semantics, but future protocol developers have an option to use the
trailing data in the NOTIFICATION message for some purpose.

It would look like this:

-----

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Error code 6  |   Subcode 2   |    Length     |     ...       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   ... Shutdown Communication ...              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length:
        The Length value can range from 0 to 128 and indicates how many
        bytes of UTF-8 for the Shutdown Communication follow. If the
        length field is set to 0, no UTF-8 bytes follow.

-----

This is an very lightweight approach to leave the door somewhat open ,
should the need to do something else with the trailing data arise, and
it only costs 1 byte.

Kind regards,

Job


On Fri, Nov 18, 2016 at 08:01:30PM +0000, Jakob Heitz (jheitz) wrote:
> Not necessary. You can already send whatever you want. In iOS-XR, it
> just hexdumps it all. The only thing that will change is that it will
> print it in UTF8 as well. It will still hexdump. If you want no
> hexdump, then we need a new subcode.
> 
> Thanks,
> Jakob.
> 
> On Nov 18, 2016, at 12:52 AM,
> > wrote:
> 
> Thanks.
> --Bruno
> 
> From: Job Snijders [mailto:job@instituut.net]
> Sent: Friday, November 18, 2016 9:46 AM
> To: DECRAENE Bruno IMT/OLN
> Cc: Jeffrey Haas; Job Snijders; grow@ietf.org; idr@ietf.org
> Subject: Re: [GROW] [Idr] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
> 
> Hi Bruno,
> 
> John Scudder was kind enough to provide extensive argumentation
> offlist on why something along these lines should be done. We'll work
> on a proposal. The length indicator is a neat idea, thanks for
> sharing.
> 
> Job
> 
> On Fri, 18 Nov 2016 at 17:32, > wrote:
> 
> 
> > From: Job Snijders [mailto:job@instituut.net]  > Sent: Friday, November 18, 2016 1:46 AM
> >
>  > On Thu, Nov 17, 2016 at 04:28:50PM +0000, bruno.decraene@orange.com wrote:
>  > > I support the draft.
>  > > I also support Jeff's idea to re-use existing sub-code(s).
>  >
>  > Thanks for your support. Based on the feedback received so far the next
>  > version of this draft will recycle Cease subcode 2.
>  >
>  > > 1 possible comment: the length of the "Shutdown Communication" field
>  > > seems implied from the length of the data field, rather than being
>  > > explicitly indicated.
>  >
>  > The text is explicit about the length:
>  >
>  >     "followed by a freeform UTF-8 encoded string with a REQUIRED maximum
>  >     length of 128 octets. "
>  >
>  > and further:
>  >
>  >     "This document tries to minimize the effects of visual spoofing by
>  >     allowing UNICODE only where local script is expected and needed, and
>  >     by limiting the length of the Shutdown Communication."
>  >
>  > > If so, it seems that we are closing the possibility to advertise
>  > > additional data/usage, in some future. What about adding a TLV format?
>  >
>  > I object to using a TLV. Don't forget this is already at a TLV level:
>  > Cease NOTIFICATION. If one would want to define a TLV inside this TLV, a
>  > new Cease subcode can be requested from IANA.
> 
> What if someone needs to advertise additional info to an existing
> cease subcode? cf Jeff's email regarding the pain of changing
> subcodes.  So let's forget about the TLV. What about just adding the
> length of the string? This would still allow adding fields after the
> string, while having a negligible/null cost?
> 
> Kind regards,
> -- Bruno


From nobody Sat Nov 19 03:13:05 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCE261295A0 for ; Sat, 19 Nov 2016 03:13:03 -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 8WGVPpFCtGgP for ; Sat, 19 Nov 2016 03:13:02 -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 07A54127058 for ; Sat, 19 Nov 2016 03:13:01 -0800 (PST)
X-Envelope-To: idr@ietf.org
Received: from crumpet.foobar.org (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 uAJBCvxl032810 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 19 Nov 2016 11:12:58 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.foobar.org
Message-ID: <583033B8.5010006@foobar.org>
Date: Sat, 19 Nov 2016 11:12:56 +0000
From: Nick Hilliard 
User-Agent: Postbox 5.0.7 (Macintosh/20161117)
MIME-Version: 1.0
To: "t.petch" 
References:   <27701_1479159582_582A2F1E_27701_6903_1_53C29892C857584299CBF5D05346208A1EC77FE1@OPEXCLILM21.corporate.adroot.infra.ftgroup> <736EA2CC-3DD1-4F14-96ED-2916E62F6F02@cisco.com> <26709_1479217575_582B11A7_26709_12999_1_53C29892C857584299CBF5D05346208A1EC79584@OPEXCLILM21.corporate.adroot.infra.ftgroup>   <20161116001246.GB27230@pfrc.org> <4EB6222D-86A4-4A83-AF8C-364CB52B8422@juniper.net> <004201d2418b$887208c0$4001a8c0@gateway.2wire.net>
In-Reply-To: <004201d2418b$887208c0$4001a8c0@gateway.2wire.net>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: idr wg 
Subject: Re: [Idr] One week extension to WGLC for draft-ietf-idr-large-community
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, 19 Nov 2016 11:13:04 -0000

t.petch wrote:
> An issue that came up earlier and that I did not see resolved was
> what constitutes a duplicate.  This is binary so we don't have the
> issues that character comparisons do but is it the same bit pattern
> from start to finish, the same semantics or something between the
> two?  A case I have in mind is when the same semantics appear in
> RFC1997 format and also in LC format; is that a duplicate?.

rfc1997 and LC being different namespaces, no.

Nick


From nobody Sat Nov 19 03:24:56 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3965129529 for ; Sat, 19 Nov 2016 03:24:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level: 
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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 78UiNI9Y4kVe for ; Sat, 19 Nov 2016 03:24:53 -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 1192B127058 for ; Sat, 19 Nov 2016 03:24:53 -0800 (PST)
Received: by mail-qk0-x22f.google.com with SMTP id x190so296794103qkb.0 for ; Sat, 19 Nov 2016 03:24:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=6Xvtrt/oS1+NynLSp7qXhwTbMENTDEVQfA3vzOzCFAM=; b=OGcdfOP9Op9M55ObgMR4bztmjFidFFr8BYfheI+ho8kBR0mTM20yAU6jabP5/ci4M3 bwrw8eGKmzR6BOJRfQZvruunyGEJCinVTkw/iK/csG4gcV0BQwAT9psksCfRegVvvM8Y zkrY6TjkE3SHnL7tYW8HSCejsakab7Gj5NoZXM5NlXUb1I8Oja77IdVup53kf2bWjsXw rLq66i22XMqasDPWKaQ4J3sPsmHtZsH1gn2aNTNt1ZU1UCzs2G5EXB0Fbpm0kuao4n65 BiTRVQCRZd2pj/cttzjnh2CYyZQepis0W8Zq3pFf4Yu7ZjWgefwURHpYsCzCU6XrMmLQ XaCA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=6Xvtrt/oS1+NynLSp7qXhwTbMENTDEVQfA3vzOzCFAM=; b=HLhP3T0rZaPMvZm2546k2ix/H06jbX3dgkUdsc1XjgrLTWqavNzXql7t1H48vbIo6i fEkRgiZ4WwjIunCksREykmhr3uROIezWwSkcWBJ8Bx7q5PlIhIJ3APzyJ2ZqPbKXSj3s MkVuNU4YcJwQnPPec68JBsxGgkoTJ7ttLZlppjKLFBndWK22GnORodNkxqIsZiojsmgF EbpLZzlXRZFUTjl5URZXEyXebxYjCd1CqDh1+hNIMslpTPaD+/OAocJUOB/kQcnhLjvv z8mYBKwJHF6F4THWY+8HnKgDSmFLPdThEwVJ+mZbCv8hkZYohj2s7azxCg8y9bnJPH4O xLOw==
X-Gm-Message-State: AKaTC00qxq4swWhE+P+hoMy3cNKueb7YtV+Y3F2/LjcW4CNV8aDldvAu5opO7uJfbu3rjHyOfJ/LvpB/hvVbEg==
X-Received: by 10.55.9.77 with SMTP id 74mr4739916qkj.225.1479554692136; Sat, 19 Nov 2016 03:24:52 -0800 (PST)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.140.16.50 with HTTP; Sat, 19 Nov 2016 03:24:51 -0800 (PST)
In-Reply-To: <20161119103226.GN1072@dhcp-9341.meeting.ietf.org>
References: <20161116061556.GG1073@dhcp-9341.meeting.ietf.org> <20161117013640.GB6217@pfrc.org> <16426_1479400131_582DDAC3_16426_1669_1_53C29892C857584299CBF5D05346208A1EC87201@OPEXCNORM2F.corporate.adroot.infra.ftgroup> <20161118004548.GK1072@dhcp-9341.meeting.ietf.org> <16418_1479457940_582EBC93_16418_290_1_53C29892C857584299CBF5D05346208A1EC8DEA5@OPEXCLILM21.corporate.adroot.infra.ftgroup>  <13357_1479459134_582EC13E_13357_5786_1_53C29892C857584299CBF5D05346208A1EC8FF18@OPEXCLILM21.corporate.adroot.infra.ftgroup> <37224750-4065-40E3-B6F4-571DED698563@cisco.com> <20161119103226.GN1072@dhcp-9341.meeting.ietf.org>
From: Robert Raszuk 
Date: Sat, 19 Nov 2016 12:24:51 +0100
X-Google-Sender-Auth: Ph0RWqBuGuiqOwVGLuXMJYYKpVQ
Message-ID: 
To: Job Snijders 
Content-Type: multipart/alternative; boundary=001a114c877ed9c41a0541a5ab39
Archived-At: 
Cc: idr wg 
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 19 Nov 2016 11:24:55 -0000

--001a114c877ed9c41a0541a5ab39
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

=E2=80=8BHi,

The alternative to the below which could be attractive both to senders and
receivers is indirection ... meaning that we would only extend current
cease sub 2 with say 21 octets which would be basic UTF8 string of URL
shortcut: *https://goo.gl/V5as9h *

=E2=80=8BThat way anyone receiving the link in the cease admin down or any =
other
sub type can click on it and read any arbitrary info or even get guide how
to configure his peer to say support new peering types being currently
prepared for cooking.

Cheers,
R.

On Sat, Nov 19, 2016 at 11:32 AM, Job Snijders  wrote:

> Hi Jakob, Working group,
>
> It is for "defensive" purposes: what if utf8 turns out to be terrible,
> then cease subcode 2 can still be used but we can put something else in
> the datafield trailing the subcode.
>
> the advantage of using a length field is that we avoid discussing types
> and semantics, but future protocol developers have an option to use the
> trailing data in the NOTIFICATION message for some purpose.
>
> It would look like this:
>
> -----
>
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    | Error code 6  |   Subcode 2   |    Length     |     ...       |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                   ... Shutdown Communication ...              |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                              ...                              |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>    Length:
>         The Length value can range from 0 to 128 and indicates how many
>         bytes of UTF-8 for the Shutdown Communication follow. If the
>         length field is set to 0, no UTF-8 bytes follow.
>
> -----
>
> This is an very lightweight approach to leave the door somewhat open ,
> should the need to do something else with the trailing data arise, and
> it only costs 1 byte.
>
> Kind regards,
>
> Job
>
>
> On Fri, Nov 18, 2016 at 08:01:30PM +0000, Jakob Heitz (jheitz) wrote:
> > Not necessary. You can already send whatever you want. In iOS-XR, it
> > just hexdumps it all. The only thing that will change is that it will
> > print it in UTF8 as well. It will still hexdump. If you want no
> > hexdump, then we need a new subcode.
> >
> > Thanks,
> > Jakob.
> >
> > On Nov 18, 2016, at 12:52 AM,
> > > wrote:
> >
> > Thanks.
> > --Bruno
> >
> > From: Job Snijders [mailto:job@instituut.net]
> > Sent: Friday, November 18, 2016 9:46 AM
> > To: DECRAENE Bruno IMT/OLN
> > Cc: Jeffrey Haas; Job Snijders; grow@ietf.org;
> idr@ietf.org
> > Subject: Re: [GROW] [Idr] draft-snijders-idr-shutdown-00: Drop a line
> in the peer's syslog at shutdown
> >
> > Hi Bruno,
> >
> > John Scudder was kind enough to provide extensive argumentation
> > offlist on why something along these lines should be done. We'll work
> > on a proposal. The length indicator is a neat idea, thanks for
> > sharing.
> >
> > Job
> >
> > On Fri, 18 Nov 2016 at 17:32,  bruno.decraene@orange.com>> wrote:
> >
> >
> > > From: Job Snijders [mailto:job@instituut.net]
> > Sent: Friday, November 18, 2016 1:46 AM
> > >
> >  > On Thu, Nov 17, 2016 at 04:28:50PM +0000, bruno.decraene@orange.com<
> mailto:bruno.decraene@orange.com> wrote:
> >  > > I support the draft.
> >  > > I also support Jeff's idea to re-use existing sub-code(s).
> >  >
> >  > Thanks for your support. Based on the feedback received so far the
> next
> >  > version of this draft will recycle Cease subcode 2.
> >  >
> >  > > 1 possible comment: the length of the "Shutdown Communication" fie=
ld
> >  > > seems implied from the length of the data field, rather than being
> >  > > explicitly indicated.
> >  >
> >  > The text is explicit about the length:
> >  >
> >  >     "followed by a freeform UTF-8 encoded string with a REQUIRED
> maximum
> >  >     length of 128 octets. "
> >  >
> >  > and further:
> >  >
> >  >     "This document tries to minimize the effects of visual spoofing =
by
> >  >     allowing UNICODE only where local script is expected and needed,
> and
> >  >     by limiting the length of the Shutdown Communication."
> >  >
> >  > > If so, it seems that we are closing the possibility to advertise
> >  > > additional data/usage, in some future. What about adding a TLV
> format?
> >  >
> >  > I object to using a TLV. Don't forget this is already at a TLV level=
:
> >  > Cease NOTIFICATION. If one would want to define a TLV inside this
> TLV, a
> >  > new Cease subcode can be requested from IANA.
> >
> > What if someone needs to advertise additional info to an existing
> > cease subcode? cf Jeff's email regarding the pain of changing
> > subcodes.  So let's forget about the TLV. What about just adding the
> > length of the string? This would still allow adding fields after the
> > string, while having a negligible/null cost?
> >
> > Kind regards,
> > -- Bruno
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>

--001a114c877ed9c41a0541a5ab39
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


=E2=80=8BHi,
The alternative to the below which could be attr=
active both to senders and receivers is indirection ... meaning that we wou=
ld only extend current cease sub 2 with say 21 octets which would be basic =
UTF8 string of URL shortcut: https://g=
oo.gl/V5as9h

=
=E2=80=8BThat way anyone receiving the link in the cease admin down or any =
other sub type can click on it and read any arbitrary info or even get guid=
e how to configure his peer to say support new peering types being currentl=
y prepared for cooking.

Cheers,
R.
=

On Sat, Nov 19, 2016 at 11:32 AM, Job Snijde=
rs <job@instituut.net> wrote:
Hi Jakob, Working group,



It is for "defensive" purposes: what if utf8 turns out to be terr=
ible,

then cease subcode 2 can still be used but we can put something else in

the datafield trailing the subcode.



the advantage of using a length field is that we avoid discussing types

and semantics, but future protocol developers have an option to use the

trailing data in the NOTIFICATION message for some purpose.



It would look like this:



-----



=C2=A0 =C2=A0 0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A01=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A02=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A03

=C2=A0 =C2=A0 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0=
 1

=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+

=C2=A0 =C2=A0| Error code 6=C2=A0 |=C2=A0 =C2=A0Subcode 2=C2=A0 =C2=A0|=C2=
=A0 =C2=A0 Length=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0...=C2=A0 =C2=A0 =
=C2=A0 =C2=A0|

=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+

=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0... Shutdown Communication ...=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 |

=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+

=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 |

=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+



=C2=A0 =C2=A0Length:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 The Length value can range from 0 to 128 and in=
dicates how many

=C2=A0 =C2=A0 =C2=A0 =C2=A0 bytes of UTF-8 for the Shutdown Communication f=
ollow. If the

=C2=A0 =C2=A0 =C2=A0 =C2=A0 length field is set to 0, no UTF-8 bytes follow=
.



-----



This is an very lightweight approach to leave the door somewhat open ,

should the need to do something else with the trailing data arise, and

it only costs 1 byte.



Kind regards,



Job





On Fri, Nov 18, 2016 at 08:01:30PM +0000, Jakob Heitz (jheitz) wrote:

> Not necessary. You can already send whatever you want. In iOS-XR, it
> just hexdumps it all. The only thing that will change is that it will<=
br>
> print it in UTF8 as well. It will still hexdump. If you want no

> hexdump, then we need a new subcode.

>

> Thanks,

> Jakob.

>

> On Nov 18, 2016, at 12:52 AM,

> <bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>> wrote:

>

> Thanks.

> --Bruno

>

> From: Job Snijders [mailto:job@in=
stituut.net]

> Sent: Friday, November 18, 2016 9:46 AM

> To: DECRAENE Bruno IMT/OLN

> Cc: Jeffrey Haas; Job Snijders; grow@ietf.org<mailto:grow@ie=
tf.org>; idr@ietf.org<mailto:=
idr@ietf.org>

> Subject: Re: [GROW] [Idr] draft-snijders-idr-shutdown=
-00: Drop a line in the peer's syslog at shutdown

>

> Hi Bruno,

>

> John Scudder was kind enough to provide extensive argumentation

> offlist on why something along these lines should be done. We'll w=
ork

> on a proposal. The length indicator is a neat idea, thanks for

> sharing.

>

> Job

>

> On Fri, 18 Nov 2016 at 17:32, <bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>> w=
rote:

>

>

> > From: Job Snijders [mailto:j=
ob@instituut.net<mailto:jo=
b@instituut.net>]=C2=A0 > Sent: Friday, November 18, 2016 1:46 AM=



> >

>=C2=A0 > On Thu, Nov 17, 2016 at 04:28:50PM +0000, bruno.decraene@orange.com<mailto:bruno.decraene@orange.com> wrote:

>=C2=A0 > > I support the draft.

>=C2=A0 > > I also support Jeff's idea to re-use existing sub-=
code(s).

>=C2=A0 >

>=C2=A0 > Thanks for your support. Based on the feedback received so =
far the next

>=C2=A0 > version of this draft will recycle Cease subcode 2.

>=C2=A0 >

>=C2=A0 > > 1 possible comment: the length of the "Shutdown C=
ommunication" field

>=C2=A0 > > seems implied from the length of the data field, rathe=
r than being

>=C2=A0 > > explicitly indicated.

>=C2=A0 >

>=C2=A0 > The text is explicit about the length:

>=C2=A0 >

>=C2=A0 >=C2=A0 =C2=A0 =C2=A0"followed by a freeform UTF-8 encod=
ed string with a REQUIRED maximum

>=C2=A0 >=C2=A0 =C2=A0 =C2=A0length of 128 octets. "

>=C2=A0 >

>=C2=A0 > and further:

>=C2=A0 >

>=C2=A0 >=C2=A0 =C2=A0 =C2=A0"This document tries to minimize th=
e effects of visual spoofing by

>=C2=A0 >=C2=A0 =C2=A0 =C2=A0allowing UNICODE only where local script=
 is expected and needed, and

>=C2=A0 >=C2=A0 =C2=A0 =C2=A0by limiting the length of the Shutdown C=
ommunication."

>=C2=A0 >

>=C2=A0 > > If so, it seems that we are closing the possibility to=
 advertise

>=C2=A0 > > additional data/usage, in some future. What about addi=
ng a TLV format?

>=C2=A0 >

>=C2=A0 > I object to using a TLV. Don't forget this is already a=
t a TLV level:

>=C2=A0 > Cease NOTIFICATION. If one would want to define a TLV insid=
e this TLV, a

>=C2=A0 > new Cease subcode can be requested from IANA.

>

> What if someone needs to advertise additional info to an existing

> cease subcode? cf Jeff's email regarding the pain of changing

> subcodes.=C2=A0 So let's forget about the TLV. What about just add=
ing the

> length of the string? This would still allow adding fields after the
> string, while having a negligible/null cost?

>

> Kind regards,

> -- Bruno




_______________________=
________________________

Idr mailing list

Idr@ietf.org

https://www.ietf.org/mailman/listinfo/idr





--001a114c877ed9c41a0541a5ab39--


From nobody Sat Nov 19 03:47:03 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75935129683 for ; Sat, 19 Nov 2016 03:47:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level: 
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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 ieVv2KXGbP3K for ; Sat, 19 Nov 2016 03:46:59 -0800 (PST)
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 336B4129680 for ; Sat, 19 Nov 2016 03:46:59 -0800 (PST)
Received: by mail-qk0-x236.google.com with SMTP id n21so297484005qka.3 for ; Sat, 19 Nov 2016 03:46:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:from:date:message-id:subject:to; bh=6NvxzspWSltFnwTR0ULQiLjPyOtsd5nv7l/6kW4cCz4=; b=r4ohYLDXyxlWokK5AxV7Hu9eJn+Llu1j5K9bPn4BaxsrVNCib5pPWu4j1Ayw/kE4Qp xCra+vAfApRIdEVx6iviN3UJ9MK41pO7wyv5n3UJ78yRzYatzXDq9L2UI+9w5lSrBK03 koEU5V+KFDabcXSxjPbX3CcCmU+WmNPKXS9G76PjwZhMpB9+6byWsGBk/njnmyFC8VfT voAxIuDxcDx211nY/DKjyIoBtMTzTC7PJJmbV2S0npc5Q/403OHrO1XExqdOq1bS+Kp2 IKoL2uSZ7TNmrGjwCaotCXzrvwt0KWQwLMxkbsMolAZWtK2VMI7p5TLuq6P/ojBU4S2z upQQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=6NvxzspWSltFnwTR0ULQiLjPyOtsd5nv7l/6kW4cCz4=; b=fh2M/6Lly2GeTa91NKwyREPY89XQ63yDwa3NNYih37SdAWqf6bQWq3wGS/ER+njNbc 7ICg1TvODfcYqzwpj8pOmwoYkEyHg9E4s5eX2ZThqOb3OZnDn5EQ+Sy2U4dBPZyXnXVW 4d4hZAiM0Bry6f7SaQp4feee/KIaCpd1XwgxJLMllrE9LTjNykLoFN3624OctYRUyNqf gKlhCSOC5v8m9oPht1bEzb1R2PYwrfet9kxz8FBfg8iLs2o9aOFkMBN/WWgqQ8PMZx4G tPshvxabL6/x9Vmt25WwcuM4Kn1iRv6q/0Wf6Bm1XZ50f/HSK0IrGxiMNBcbHmJ5OKCg 52aA==
X-Gm-Message-State: AKaTC01a7iH2/d2g9S34PCtv3mK6ok1B9zUh7L0tWY443xGB8WsSNqeM4/DMN3Iolng/ngx8awj9nio75Z06lQ==
X-Received: by 10.55.162.83 with SMTP id l80mr4979518qke.168.1479556018194; Sat, 19 Nov 2016 03:46:58 -0800 (PST)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.140.16.50 with HTTP; Sat, 19 Nov 2016 03:46:57 -0800 (PST)
From: Robert Raszuk 
Date: Sat, 19 Nov 2016 12:46:57 +0100
X-Google-Sender-Auth: xutXNeX2Nle6W2E6yfaRp5chmOU
Message-ID: 
To: idr wg 
Content-Type: multipart/alternative; boundary=001a114faecce3d24c0541a5fab9
Archived-At: 
Subject: [Idr] draft-ymbk-idr-bgp-open-policy
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, 19 Nov 2016 11:47:00 -0000

--001a114faecce3d24c0541a5fab9
Content-Type: text/plain; charset=UTF-8

Dear Authors and WG,

I would like to share few observations on this proposal.

Let me start with comment that hardcoded automation is a good thing and
this does provide for automate filtering so it is very good direction which
I support.

Observations:

1. What role would be assign to peering to route server ?

2. This proposal to twick session capabilites looks very innocent on the
surface till we have seen proposal to leak local pref or send med based on
those capabilities. I am sure just around the corner there would be
proposals to stop next hop self on ebgp or to ignore extended community
transitive bit when sending to internal (even if internal is another AS).

So here I would propose to instead to hide this under the table clearly
define new types of BGP sessions with clear semantics on what is expected
from said new types of BGP sessions: to peers, to same admin peer AS, to
customers, to complex or to providers etc ...

3. It has been suggested that the default should be "customer" I think this
would be very bad idea deployment wise as it will take ages for all
customers to upgrade their routers. Instead I would propose that customers
sessions would be exactly what we have today as basic eBGP. The new
attribute imposition may be associated with current customers peerings.

Many thx,
R.

--001a114faecce3d24c0541a5fab9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Dear Authors and WG,=C2=A0

I would like to share few observat=
ions on this proposal.=C2=A0

Let me start with comment that hardcoded automation is a good thin=
g and this does provide for automate filtering so it is very good direction=
 which I support.=C2=A0

Observations:

1. Wha=
t role would be assign to peering to route server ?=C2=A0

2. This proposal to twick session cap=
abilites looks very innocent on the surface till we have seen proposal to l=
eak local pref or send med based on those capabilities. I am sure just arou=
nd the corner there would be proposals to stop next hop self on ebgp or to =
ignore extended community transitive bit when sending to internal (even if =
internal is another AS).=C2=A0

So here I would propose to instead to hide this under the table cl=
early define new types of BGP sessions with clear semantics on what is expe=
cted from said new types of BGP sessions: to peers, to same admin peer AS, =
to customers, to complex or to providers etc ...=C2=A0

3. It has been suggested that the default =
should be "customer" I think this would be very bad idea deployme=
nt wise as it will take ages for all customers to upgrade their routers. In=
stead I would propose that customers sessions would be exactly what we have=
 today as basic eBGP. The new attribute imposition may be associated with c=
urrent customers peerings.=C2=A0

Many thx,
R.






--001a114faecce3d24c0541a5fab9--


From nobody Sat Nov 19 04:11:25 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E89F8129860 for ; Sat, 19 Nov 2016 04:11:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.432
X-Spam-Level: 
X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_SOFTFAIL=0.665] 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 hjse8DFMFClg for ; Sat, 19 Nov 2016 04:11:22 -0800 (PST)
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 98AA11296A4 for ; Sat, 19 Nov 2016 04:11:22 -0800 (PST)
Received: by mail3.mlpsca01.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1c84UJ-0006yo-6T (job@us.ntt.net); Sat, 19 Nov 2016 12:11:22 +0000
Date: Sat, 19 Nov 2016 13:11:15 +0100
From: Job Snijders 
To: idr@ietf.org
Message-ID: <20161119121115.GA47336@dhcp-9d92.meeting.ietf.org>
References: <20161116061556.GG1073@dhcp-9341.meeting.ietf.org> <20161117013640.GB6217@pfrc.org> <16426_1479400131_582DDAC3_16426_1669_1_53C29892C857584299CBF5D05346208A1EC87201@OPEXCNORM2F.corporate.adroot.infra.ftgroup> <20161118004548.GK1072@dhcp-9341.meeting.ietf.org> <16418_1479457940_582EBC93_16418_290_1_53C29892C857584299CBF5D05346208A1EC8DEA5@OPEXCLILM21.corporate.adroot.infra.ftgroup>  <13357_1479459134_582EC13E_13357_5786_1_53C29892C857584299CBF5D05346208A1EC8FF18@OPEXCLILM21.corporate.adroot.infra.ftgroup> <37224750-4065-40E3-B6F4-571DED698563@cisco.com> <20161119103226.GN1072@dhcp-9341.meeting.ietf.org> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.7.1 (2016-10-04)
Archived-At: 
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 19 Nov 2016 12:11:24 -0000

Hi Robert,

On Sat, Nov 19, 2016 at 12:24:51PM +0100, Robert Raszuk wrote:
> The alternative to the below which could be attractive both to senders and
> receivers is indirection ... meaning that we would only extend current
> cease sub 2 with say 21 octets which would be basic UTF8 string of URL
> shortcut: https://goo.gl/V5as9h 

While I am aware that David Wheeler said: "All problems in computer
science can be solved by another level of indirection", there are some
practicalities to be considered:

    https://www.schneier.com/blog/archives/2016/04/security_risks_11.html
    https://freedom-to-tinker.com/2016/04/14/gone-in-six-characters-short-urls-considered-harmful-for-cloud-services/
    https://www.cs.cornell.edu/~shmat/shmat_urls.pdf

In addition to that, the user behind the router which received the
Shutdown Communication might no longer have access to the web due to
that shutdown event.

> That way anyone receiving the link in the cease admin down or any
> other sub type can click on it and read any arbitrary info or even get
> guide how to configure his peer to say support new peering types being
> currently prepared for cooking.

Ofcourse, people are free to put a URL in the 128 octets worth of
Shutdown Communication. This is for the operators to decide.

Kind regards,

Job


From nobody Sat Nov 19 04:32:35 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C86FF129867 for ; Sat, 19 Nov 2016 04:32:33 -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, SPF_HELO_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 2gMpGhWv5mGi for ; Sat, 19 Nov 2016 04:32:31 -0800 (PST)
Received: from freesbee.wheel.dk (freesbee.wheel.dk [IPv6:2001:6c8:130::97]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F10D8129591 for ; Sat, 19 Nov 2016 04:32:30 -0800 (PST)
Received: by freesbee.wheel.dk (Postfix, from userid 1001) id 1D29B32371A; Sat, 19 Nov 2016 13:32:29 +0100 (CET)
Date: Sat, 19 Nov 2016 13:32:29 +0100
From: Jesper Skriver 
To: Robert Raszuk 
Message-ID: <20161119123229.GD4992@skriver.dk>
References: <20161116061556.GG1073@dhcp-9341.meeting.ietf.org> <20161117013640.GB6217@pfrc.org> <16426_1479400131_582DDAC3_16426_1669_1_53C29892C857584299CBF5D05346208A1EC87201@OPEXCNORM2F.corporate.adroot.infra.ftgroup> <20161118004548.GK1072@dhcp-9341.meeting.ietf.org> <16418_1479457940_582EBC93_16418_290_1_53C29892C857584299CBF5D05346208A1EC8DEA5@OPEXCLILM21.corporate.adroot.infra.ftgroup>  <13357_1479459134_582EC13E_13357_5786_1_53C29892C857584299CBF5D05346208A1EC8FF18@OPEXCLILM21.corporate.adroot.infra.ftgroup> <37224750-4065-40E3-B6F4-571DED698563@cisco.com> <20161119103226.GN1072@dhcp-9341.meeting.ietf.org> 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
X-PGP-Fingerprint: 6B88 9CE8 66E9 E631 C9C5  5EB4 22AB F0EC F956 1C31
X-PGP-Public-Key: http://freesbee.wheel.dk/~jesper/gpgkey.pub
User-Agent: Mutt/1.7.1 (2016-10-04)
Archived-At: 
Cc: idr wg 
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 19 Nov 2016 12:32:34 -0000

On Sat, Nov 19, 2016 at 12:24:51PM +0100, Robert Raszuk wrote:
> ​Hi,
> 
> The alternative to the below which could be attractive both to senders and
> receivers is indirection ... meaning that we would only extend current
> cease sub 2 with say 21 octets which would be basic UTF8 string of URL
> shortcut: *https://goo.gl/V5as9h *

That seems to raise the bar for using it significantly, it require
more work if I first have to setup a page somewhere, generate a
short URL for it, and then type the URL into my router when doing

neighbor FOO shutdown http://some.url

versus

neighbor FOO shutdown "having issues, ETA 05:00"

/Jesper

> ​That way anyone receiving the link in the cease admin down or any other
> sub type can click on it and read any arbitrary info or even get guide how
> to configure his peer to say support new peering types being currently
> prepared for cooking.
> 
> Cheers,
> R.
> 
> On Sat, Nov 19, 2016 at 11:32 AM, Job Snijders  wrote:
> 
> > Hi Jakob, Working group,
> >
> > It is for "defensive" purposes: what if utf8 turns out to be terrible,
> > then cease subcode 2 can still be used but we can put something else in
> > the datafield trailing the subcode.
> >
> > the advantage of using a length field is that we avoid discussing types
> > and semantics, but future protocol developers have an option to use the
> > trailing data in the NOTIFICATION message for some purpose.
> >
> > It would look like this:
> >
> > -----
> >
> >     0                   1                   2                   3
> >     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    | Error code 6  |   Subcode 2   |    Length     |     ...       |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                   ... Shutdown Communication ...              |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                              ...                              |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >    Length:
> >         The Length value can range from 0 to 128 and indicates how many
> >         bytes of UTF-8 for the Shutdown Communication follow. If the
> >         length field is set to 0, no UTF-8 bytes follow.
> >
> > -----
> >
> > This is an very lightweight approach to leave the door somewhat open ,
> > should the need to do something else with the trailing data arise, and
> > it only costs 1 byte.
> >
> > Kind regards,
> >
> > Job
> >
> >
> > On Fri, Nov 18, 2016 at 08:01:30PM +0000, Jakob Heitz (jheitz) wrote:
> > > Not necessary. You can already send whatever you want. In iOS-XR, it
> > > just hexdumps it all. The only thing that will change is that it will
> > > print it in UTF8 as well. It will still hexdump. If you want no
> > > hexdump, then we need a new subcode.
> > >
> > > Thanks,
> > > Jakob.
> > >
> > > On Nov 18, 2016, at 12:52 AM,
> > > > wrote:
> > >
> > > Thanks.
> > > --Bruno
> > >
> > > From: Job Snijders [mailto:job@instituut.net]
> > > Sent: Friday, November 18, 2016 9:46 AM
> > > To: DECRAENE Bruno IMT/OLN
> > > Cc: Jeffrey Haas; Job Snijders; grow@ietf.org;
> > idr@ietf.org
> > > Subject: Re: [GROW] [Idr] draft-snijders-idr-shutdown-00: Drop a line
> > in the peer's syslog at shutdown
> > >
> > > Hi Bruno,
> > >
> > > John Scudder was kind enough to provide extensive argumentation
> > > offlist on why something along these lines should be done. We'll work
> > > on a proposal. The length indicator is a neat idea, thanks for
> > > sharing.
> > >
> > > Job
> > >
> > > On Fri, 18 Nov 2016 at 17:32,  > bruno.decraene@orange.com>> wrote:
> > >
> > >
> > > > From: Job Snijders [mailto:job@instituut.net]
> > > Sent: Friday, November 18, 2016 1:46 AM
> > > >
> > >  > On Thu, Nov 17, 2016 at 04:28:50PM +0000, bruno.decraene@orange.com<
> > mailto:bruno.decraene@orange.com> wrote:
> > >  > > I support the draft.
> > >  > > I also support Jeff's idea to re-use existing sub-code(s).
> > >  >
> > >  > Thanks for your support. Based on the feedback received so far the
> > next
> > >  > version of this draft will recycle Cease subcode 2.
> > >  >
> > >  > > 1 possible comment: the length of the "Shutdown Communication" field
> > >  > > seems implied from the length of the data field, rather than being
> > >  > > explicitly indicated.
> > >  >
> > >  > The text is explicit about the length:
> > >  >
> > >  >     "followed by a freeform UTF-8 encoded string with a REQUIRED
> > maximum
> > >  >     length of 128 octets. "
> > >  >
> > >  > and further:
> > >  >
> > >  >     "This document tries to minimize the effects of visual spoofing by
> > >  >     allowing UNICODE only where local script is expected and needed,
> > and
> > >  >     by limiting the length of the Shutdown Communication."
> > >  >
> > >  > > If so, it seems that we are closing the possibility to advertise
> > >  > > additional data/usage, in some future. What about adding a TLV
> > format?
> > >  >
> > >  > I object to using a TLV. Don't forget this is already at a TLV level:
> > >  > Cease NOTIFICATION. If one would want to define a TLV inside this
> > TLV, a
> > >  > new Cease subcode can be requested from IANA.
> > >
> > > What if someone needs to advertise additional info to an existing
> > > cease subcode? cf Jeff's email regarding the pain of changing
> > > subcodes.  So let's forget about the TLV. What about just adding the
> > > length of the string? This would still allow adding fields after the
> > > string, while having a negligible/null cost?
> > >
> > > Kind regards,
> > > -- Bruno
> >
> > _______________________________________________
> > 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


/Jesper

-- 
Jesper Skriver, jesper(at)skriver(dot)dk  -  CCIE #5456

One Unix to rule them all, One Resolver to find them,
One IP to bring them all and in the zone to bind them.


From nobody Sat Nov 19 04:34:33 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AFD9129635; Sat, 19 Nov 2016 04:34:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.699
X-Spam-Level: 
X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, 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 jaSUH1meHvLd; Sat, 19 Nov 2016 04:34:31 -0800 (PST)
Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by ietfa.amsl.com (Postfix) with ESMTP id 3C9B712986B; Sat, 19 Nov 2016 04:34:31 -0800 (PST)
Received: by puck.nether.net (Postfix, from userid 162) id D262C540D88; Sat, 19 Nov 2016 07:34:30 -0500 (EST)
Date: Sat, 19 Nov 2016 07:34:30 -0500
From: Jared Mauch 
To: "Jakob Heitz (jheitz)" 
Message-ID: <20161119123430.GA2472@puck.nether.net>
References: <20161116061556.GG1073@dhcp-9341.meeting.ietf.org> <20161117013640.GB6217@pfrc.org> <16426_1479400131_582DDAC3_16426_1669_1_53C29892C857584299CBF5D05346208A1EC87201@OPEXCNORM2F.corporate.adroot.infra.ftgroup> <20161118004548.GK1072@dhcp-9341.meeting.ietf.org> <16418_1479457940_582EBC93_16418_290_1_53C29892C857584299CBF5D05346208A1EC8DEA5@OPEXCLILM21.corporate.adroot.infra.ftgroup>  <13357_1479459134_582EC13E_13357_5786_1_53C29892C857584299CBF5D05346208A1EC8FF18@OPEXCLILM21.corporate.adroot.infra.ftgroup> <37224750-4065-40E3-B6F4-571DED698563@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <37224750-4065-40E3-B6F4-571DED698563@cisco.com>
User-Agent: Mutt/1.7.1 (2016-10-04)
Archived-At: 
Cc: "bruno.decraene@orange.com" , "grow@ietf.org" , "idr@ietf.org" 
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 19 Nov 2016 12:34:32 -0000

On Fri, Nov 18, 2016 at 08:01:30PM +0000, Jakob Heitz (jheitz) wrote:
> Not necessary. You can already send whatever you want. In iOS-XR, it just hexdumps it all. The only thing that will change is that it will print it in UTF8 as well. It will still hexdump. If you want no hexdump, then we need a new subcode.
> 

	One other thing we will need from the vendors is
the information to be available in the show commands around the
BGP neighbor as well, eg:

Router#show bgp neighbor

BGP neighbor is fe80::1
 Remote AS 65000, local AS 65000, internal link

  Connections established 1; dropped 0
  Last reset 2d03h, due to BGP Notification sent: code/text here
  Time since last notification sent to neighbor: 2d03h
  Error Code: appropriate code goes here
  Notification data received (or sent):
    UTF-8 string goes here






-- 
Jared Mauch  | pgp key available via finger from jared@puck.nether.net
clue++;      | http://puck.nether.net/~jared/  My statements are only mine.


From nobody Sat Nov 19 04:36:47 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6450129873 for ; Sat, 19 Nov 2016 04:36:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.699
X-Spam-Level: 
X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, 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 IgZnIdMscsq6 for ; Sat, 19 Nov 2016 04:36:45 -0800 (PST)
Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id B6784129869 for ; Sat, 19 Nov 2016 04:36:45 -0800 (PST)
Received: by puck.nether.net (Postfix, from userid 162) id 76602540DFA; Sat, 19 Nov 2016 07:36:45 -0500 (EST)
Date: Sat, 19 Nov 2016 07:36:45 -0500
From: Jared Mauch 
To: Jesper Skriver 
Message-ID: <20161119123645.GB2472@puck.nether.net>
References: <20161117013640.GB6217@pfrc.org> <16426_1479400131_582DDAC3_16426_1669_1_53C29892C857584299CBF5D05346208A1EC87201@OPEXCNORM2F.corporate.adroot.infra.ftgroup> <20161118004548.GK1072@dhcp-9341.meeting.ietf.org> <16418_1479457940_582EBC93_16418_290_1_53C29892C857584299CBF5D05346208A1EC8DEA5@OPEXCLILM21.corporate.adroot.infra.ftgroup>  <13357_1479459134_582EC13E_13357_5786_1_53C29892C857584299CBF5D05346208A1EC8FF18@OPEXCLILM21.corporate.adroot.infra.ftgroup> <37224750-4065-40E3-B6F4-571DED698563@cisco.com> <20161119103226.GN1072@dhcp-9341.meeting.ietf.org>  <20161119123229.GD4992@skriver.dk>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20161119123229.GD4992@skriver.dk>
User-Agent: Mutt/1.7.1 (2016-10-04)
Archived-At: 
Cc: idr wg , Robert Raszuk 
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 19 Nov 2016 12:36:47 -0000

On Sat, Nov 19, 2016 at 01:32:29PM +0100, Jesper Skriver wrote:
> On Sat, Nov 19, 2016 at 12:24:51PM +0100, Robert Raszuk wrote:
> > ​Hi,
> > 
> > The alternative to the below which could be attractive both to senders and
> > receivers is indirection ... meaning that we would only extend current
> > cease sub 2 with say 21 octets which would be basic UTF8 string of URL
> > shortcut: *https://goo.gl/V5as9h *
> 
> That seems to raise the bar for using it significantly, it require
> more work if I first have to setup a page somewhere, generate a
> short URL for it, and then type the URL into my router when doing
> 
> neighbor FOO shutdown http://some.url
> 
> versus
> 
> neighbor FOO shutdown "having issues, ETA 05:00"

	I'm certainly not against allowing people to send a URL
or other data, but our use case is likely to be the ticket# and/or
a phone number for contacting our NOC to streamline communication.

	- Jared


From nobody Sat Nov 19 05:22:41 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE305127A90 for ; Sat, 19 Nov 2016 05:22:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level: 
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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 u3n6YvUtf7A5 for ; Sat, 19 Nov 2016 05:22:37 -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 DC1241298AC for ; Sat, 19 Nov 2016 05:22:35 -0800 (PST)
Received: by mail-qk0-x22f.google.com with SMTP id x190so298794313qkb.0 for ; Sat, 19 Nov 2016 05:22:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=FqefBiG/TNy5bBQEO4gQIjslELKc1UTjVkWo9U9nfgw=; b=O9jv8UoNWqxfhXMJ2CM3hzi0Gl9rWgQHojibqp8jLsTxsL9oLWEBnstYPZi2sr7dXl 3HGsb0NIdmpoQxCH+Ube08H5IeH6VuiUwjQQDVaetjkcHqrjWjJsmlWdB7GOInu4PPKb cr4F8tS5an5bptIvQ26/UJSpcfp8tPVP8uFvFNm1a9qU1Sw0ncDTcBhBZtEEBOPE1Zsl 1D48Yy8lK8gs629v8pI4y+zklQuK4ava643afjbmnruVPhlN+JhJyShgjLGZJ/OR5Qgb NA7K+PKlrwcGpt9/4RwgSnc673nmY6x+FN157/FDaKPN/U2f1PTY8JpouvGssB4cl/A7 hmKw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=FqefBiG/TNy5bBQEO4gQIjslELKc1UTjVkWo9U9nfgw=; b=DULUPRWra8H7mybCd6lbMVvtpfxGnM6q2twj4qqdKuZ1v+8D7QsjUCA1unD0+SGP6c K5wDlJjPhuyb2rsjHPL/sD2jafwXcR6baqO4TMsc2xj9zdefuFr13aPmZaLxt/KPqcsu Q9xfO+PDqXhD75i3J9g4rxgfZCy+1koO/pGOWhziQSt8x0F4V92pUquoZnE6AMj6GrD7 tkSiXN8izUTNGas91fdf5S+mNTk7rFaKydzGVz20Agsp+lxR7EoWtQvPMrP0mIC4tHAg Hu2wTyrDpIt3l7+GJXOLkgrM7d1YnqbTcrBOndU6zOB3fymQznwqlWnt3G1CS4suxnLZ aCtg==
X-Gm-Message-State: AKaTC00zx73GnFbtFoGZm5JjxMtIk8a30wRgIywNrRF/DYvpYz1hGksyged/oKIRjMVxjlZqZhw65rARpYNs7g==
X-Received: by 10.55.162.83 with SMTP id l80mr5429684qke.168.1479561755029; Sat, 19 Nov 2016 05:22:35 -0800 (PST)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.140.16.50 with HTTP; Sat, 19 Nov 2016 05:22:34 -0800 (PST)
In-Reply-To: <20161119123645.GB2472@puck.nether.net>
References: <20161117013640.GB6217@pfrc.org> <16426_1479400131_582DDAC3_16426_1669_1_53C29892C857584299CBF5D05346208A1EC87201@OPEXCNORM2F.corporate.adroot.infra.ftgroup> <20161118004548.GK1072@dhcp-9341.meeting.ietf.org> <16418_1479457940_582EBC93_16418_290_1_53C29892C857584299CBF5D05346208A1EC8DEA5@OPEXCLILM21.corporate.adroot.infra.ftgroup>  <13357_1479459134_582EC13E_13357_5786_1_53C29892C857584299CBF5D05346208A1EC8FF18@OPEXCLILM21.corporate.adroot.infra.ftgroup> <37224750-4065-40E3-B6F4-571DED698563@cisco.com> <20161119103226.GN1072@dhcp-9341.meeting.ietf.org>  <20161119123229.GD4992@skriver.dk> <20161119123645.GB2472@puck.nether.net>
From: Robert Raszuk 
Date: Sat, 19 Nov 2016 14:22:34 +0100
X-Google-Sender-Auth: K7OF7NYOeR000QXAMAS0BK01_5w
Message-ID: 
To: Jared Mauch 
Content-Type: multipart/alternative; boundary=001a114faeccd4f4710541a750b5
Archived-At: 
Cc: idr wg 
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 19 Nov 2016 13:22:39 -0000

--001a114faeccd4f4710541a750b5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

>
> I'm certainly not against allowing people to send a URL
> or other data, but our use case is likely to be the ticket# and/or
> a phone number for contacting our NOC to streamline communication.


=E2=80=8BActually what drove my suggestion for URL was as usual desire for
automation.

As 128 octets of unstructured free form text is proposed that still
requires human reading the text which is something we should try to avoid
IMHO. Worse it requires someone to pick up the phone and make a call ...

At min perhaps draft should define =E2=80=8Bfew optional prefixes/key words=
 which
could be machine recognized: "url:", "mail:", "phone:", "description:",
"eta:", "ticket:", "duration:" etc ....

Reason ... if the outage is to last 5-10 min in the middle of the night (ad
delta from current time vs eta or duration) the analyzing script will not
raise the alarm and will save few folks to being woken up. Simple and
useful IMHO. Not everyone has 24/7 NOC.

And btw - while good idea - adding it show bgp neighbor will likely break
many parsers and will require yang model extension :).

Cheers,
R.

PS. Do we need to extend BMP too ?

--001a114faeccd4f4710541a750b5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


I'm certainly not against=
 allowing people to send a URL

or other data, but our use case is likely to be the ticket# and/or

a phone number for contacting our NOC to streamline communication.

=E2=80=8BActually what drove my =
suggestion for URL was as usual desire for automation.=C2=A0

As 128 octets of unstructured free f=
orm text is proposed that still requires human reading the text which is so=
mething we should try to avoid IMHO. Worse it requires someone to pick up t=
he phone and make a call ...=C2=A0

At min perhaps draft should define =E2=80=8Bfew optional pref=
ixes/key words which could be machine recognized: "url:", "m=
ail:", "phone:", "description:", "eta:",=
 "ticket:", "duration:" etc ....

Reason ... if the outage is to last 5-10=
 min in the middle of the night (ad delta from current time vs eta or durat=
ion) the analyzing script will not raise the alarm and will save few folks =
to being woken up. Simple and useful IMHO. Not everyone has 24/7 NOC.=C2=A0=


And btw - while good =
idea - adding it=C2=A0show bgp neighbor=C2=A0will likely break many parsers and w=
ill require yang model extension :).

Cheers,
R.

PS. Do we need to extend BMP too ?=C2=A0



--001a114faeccd4f4710541a750b5--


From nobody Sat Nov 19 05:40:03 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD315129495 for ; Sat, 19 Nov 2016 05:40:01 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=lamehost-it.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 EIAN7ymYBh8k for ; Sat, 19 Nov 2016 05:40:00 -0800 (PST)
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 BB942129404 for ; Sat, 19 Nov 2016 05:39:59 -0800 (PST)
Received: by mail-wm0-x22b.google.com with SMTP id f82so76930968wmf.1 for ; Sat, 19 Nov 2016 05:39:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lamehost-it.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WLRLrQ0iFaEfNukKGm/2u7dyxG4Fa6KCGTQXanYPIDM=; b=J2pwLu/PkW40NmZePPHZ+EgHiu/b955kPeEXIgfxDTuSAoUJE+T7Zc2qhLs8YTOAnr FA3rob6iRBJS/Wdkbkxg8qgCmPHNTOeBp7j4aSYAPPsrAosD+zoHjzwZTLJX4B3UCysk BeWQ4uVGoL2JEorRuuRl7iAIz9Xm5yudoUBzLtdsUfASj6FRjGc9sDtSNTQlPFdvjvVr kp0Kxu4gf2W/ohhb1Ccmb7jXRJs5oPDnE1FnGEh72W8fv/SkluRdVz5LABtecypI/LTF WnzmXmWePyUs9OCCFRS8MaXwRY4r87uI5b3BPv+2P9902cKhxcySsrw26T6ecCUSx/Oj Y6gw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WLRLrQ0iFaEfNukKGm/2u7dyxG4Fa6KCGTQXanYPIDM=; b=loKKbUfGmA/IAL+Tl83RRe5XVW6hL5FXVoDowH4LT8a+LIVhNaz6/8D0LxoOn6llWH y/vTgUzn3eYHSSe6x1HvON7kgli1/kH2NzGPpJdMDzCP8dC1kWJjaAiXeenPxoAP/UUP 6p14WKWPJ0C7Vei164tlDqsLM+hXkxolGiHU3EpolE582kIw6v2mwxPOUEb7fdLVP9Kk 1LC4Qxo+EatIeJ3Z2kcYcK0PgPW2B5KeJYLEWx6Cr6AZOYfbHHdzGONi9gvjYTZI20BE 0CU375aE+NKjsufSnm2qifrJ5aNA67c8a9bd6oonkdz6OtnJEkgI4t8ES5e0/9dtn20e oznA==
X-Gm-Message-State: AKaTC01OH1KNTcZPB3h1vhsELMtDJw7kCKApnGEVQ6nFfPIYjX/DHMuYkLOUqECszxgZMq4jHInYgb7EkWJgJg==
X-Received: by 10.46.76.1 with SMTP id z1mr2580325lja.41.1479562798282; Sat, 19 Nov 2016 05:39:58 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.202.14 with HTTP; Sat, 19 Nov 2016 05:39:57 -0800 (PST)
X-Originating-IP: [79.24.77.5]
In-Reply-To: 
References: <20161117013640.GB6217@pfrc.org> <16426_1479400131_582DDAC3_16426_1669_1_53C29892C857584299CBF5D05346208A1EC87201@OPEXCNORM2F.corporate.adroot.infra.ftgroup> <20161118004548.GK1072@dhcp-9341.meeting.ietf.org> <16418_1479457940_582EBC93_16418_290_1_53C29892C857584299CBF5D05346208A1EC8DEA5@OPEXCLILM21.corporate.adroot.infra.ftgroup>  <13357_1479459134_582EC13E_13357_5786_1_53C29892C857584299CBF5D05346208A1EC8FF18@OPEXCLILM21.corporate.adroot.infra.ftgroup> <37224750-4065-40E3-B6F4-571DED698563@cisco.com> <20161119103226.GN1072@dhcp-9341.meeting.ietf.org>  <20161119123229.GD4992@skriver.dk> <20161119123645.GB2472@puck.nether.net> 
From: Marco Marzetti 
Date: Sat, 19 Nov 2016 14:39:57 +0100
Message-ID: 
To: Robert Raszuk 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: idr wg 
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 19 Nov 2016 13:40:02 -0000

Robert,

Despite i like the idea to use this feature in automation, it sounds
overkill to me to force TLVs.
Wouldn't be simpler to define the message as UTF8 string and let
operators do what they think is more reasonable?

AFAIK we don't have standards that defines "assurance messages" (do
we?) and this draft is not the right place to define it

Regards

On Sat, Nov 19, 2016 at 2:22 PM, Robert Raszuk  wrote:
>> I'm certainly not against allowing people to send a URL
>> or other data, but our use case is likely to be the ticket# and/or
>> a phone number for contacting our NOC to streamline communication.
>
>
> Actually what drove my suggestion for URL was as usual desire for
> automation.
>
> As 128 octets of unstructured free form text is proposed that still requires
> human reading the text which is something we should try to avoid IMHO. Worse
> it requires someone to pick up the phone and make a call ...
>
> At min perhaps draft should define few optional prefixes/key words which
> could be machine recognized: "url:", "mail:", "phone:", "description:",
> "eta:", "ticket:", "duration:" etc ....
>
> Reason ... if the outage is to last 5-10 min in the middle of the night (ad
> delta from current time vs eta or duration) the analyzing script will not
> raise the alarm and will save few folks to being woken up. Simple and useful
> IMHO. Not everyone has 24/7 NOC.
>
> And btw - while good idea - adding it show bgp neighbor will likely break
> many parsers and will require yang model extension :).
>
> Cheers,
> R.
>
> PS. Do we need to extend BMP too ?
>
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>



-- 
Marco


From nobody Sat Nov 19 05:47:53 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1391129485 for ; Sat, 19 Nov 2016 05:47:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level: 
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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=unavailable 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 1w_SKApmDWBQ for ; Sat, 19 Nov 2016 05:47:50 -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 B1A1C129404 for ; Sat, 19 Nov 2016 05:42:49 -0800 (PST)
Received: by mail-qk0-x233.google.com with SMTP id n204so299774513qke.2 for ; Sat, 19 Nov 2016 05:42:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=4pSjrLZcjVaspd1vkSWfFdaoldVb1SB6thi29UNiNuU=; b=WFEpD6AhrkcNImA1lq/Xqwj1V8cXps54NGbHyv4lrCy4M87La9pnmnu1BED/N00HQn 8dioLxatLh5aF5fq0x+mcFjU3rqOm4i005d+yi42IcuFZVoSow2pA4xxJMsWs8wevSri JkdXklOj+Ly/CX1Bsh0ijehFjoVp6LTCE6XoU1QmHesK0oGWxOJGFKXDIcdSrqu2BfhB 00g9aP8Z7rZmNh0R2RKRFwUOSTnvDZ1P8/okWfZDPjINVYh/63JUX/Rqo3LuNEt3i6Gs nfc6Z6FHXF/mMv9ibZ5hpzCAXTEqye7kRyInr0NRtGIzJro7ZVmsRNRomgEsNErlrDt4 0g8A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=4pSjrLZcjVaspd1vkSWfFdaoldVb1SB6thi29UNiNuU=; b=NIqvX/ZM6b6J04FoDGveNBrfGP0A3WOS7a/9iR+khNQaisKDGCUCttnz8Y2DiPHhMe vhnllVHQJss/7oNSCcyjlR8Ozjz9nnV+YVR873NoZA6rnOtsqEnJEoUoXPubLwhHnAM2 BZmsIZrKA8jbvGQaJ9/5bacE5UaRTvZghHQA07s4dcmvQJaKlpLNInieN4/4hG5rOQ+Q fNivEuyazIehWDg+OP4JLt7oiWuEaYZ8hmKhmvZ9VKhNV3NV4vqZzZtQzq+SzaYKwq0I /eJXO5ib9/RZ5l4Q3EhTvdIoMvXPj8Pka/M+SMZ/wwVlXAhaAyWdq4AnpNnrdBwxGuG8 DFUA==
X-Gm-Message-State: AKaTC01sejmwmmaht5FTFEKO1DpZGs6raJCUIorayuzFA2LpJ3r2RukhfIXpyy7KMVulkkFDQGcDyit6Jm5bLw==
X-Received: by 10.55.9.77 with SMTP id 74mr5347258qkj.225.1479562968827; Sat, 19 Nov 2016 05:42:48 -0800 (PST)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.140.16.50 with HTTP; Sat, 19 Nov 2016 05:42:47 -0800 (PST)
In-Reply-To: 
References: <20161117013640.GB6217@pfrc.org> <16426_1479400131_582DDAC3_16426_1669_1_53C29892C857584299CBF5D05346208A1EC87201@OPEXCNORM2F.corporate.adroot.infra.ftgroup> <20161118004548.GK1072@dhcp-9341.meeting.ietf.org> <16418_1479457940_582EBC93_16418_290_1_53C29892C857584299CBF5D05346208A1EC8DEA5@OPEXCLILM21.corporate.adroot.infra.ftgroup>  <13357_1479459134_582EC13E_13357_5786_1_53C29892C857584299CBF5D05346208A1EC8FF18@OPEXCLILM21.corporate.adroot.infra.ftgroup> <37224750-4065-40E3-B6F4-571DED698563@cisco.com> <20161119103226.GN1072@dhcp-9341.meeting.ietf.org>  <20161119123229.GD4992@skriver.dk> <20161119123645.GB2472@puck.nether.net>  
From: Robert Raszuk 
Date: Sat, 19 Nov 2016 14:42:47 +0100
X-Google-Sender-Auth: pbX1loypuKzMNYgVdPUys7qwwtY
Message-ID: 
To: Marco Marzetti 
Content-Type: multipart/alternative; boundary=001a114c877e2e0d420541a799ea
Archived-At: 
Cc: idr wg 
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 19 Nov 2016 13:47:52 -0000

--001a114c877e2e0d420541a799ea
Content-Type: text/plain; charset=UTF-8

Hi Marco,

No no ... I did not intended to define any TLVs .. that indeed would be
indeed an overkill here. Just few loose keywords to be optionally present
in the free form text which any basic script could detect and make educated
action.

Best,
R.


On Sat, Nov 19, 2016 at 2:39 PM, Marco Marzetti  wrote:

> Robert,
>
> Despite i like the idea to use this feature in automation, it sounds
> overkill to me to force TLVs.
> Wouldn't be simpler to define the message as UTF8 string and let
> operators do what they think is more reasonable?
>
> AFAIK we don't have standards that defines "assurance messages" (do
> we?) and this draft is not the right place to define it
>
> Regards
>
> On Sat, Nov 19, 2016 at 2:22 PM, Robert Raszuk  wrote:
> >> I'm certainly not against allowing people to send a URL
> >> or other data, but our use case is likely to be the ticket# and/or
> >> a phone number for contacting our NOC to streamline communication.
> >
> >
> > Actually what drove my suggestion for URL was as usual desire for
> > automation.
> >
> > As 128 octets of unstructured free form text is proposed that still
> requires
> > human reading the text which is something we should try to avoid IMHO.
> Worse
> > it requires someone to pick up the phone and make a call ...
> >
> > At min perhaps draft should define few optional prefixes/key words which
> > could be machine recognized: "url:", "mail:", "phone:", "description:",
> > "eta:", "ticket:", "duration:" etc ....
> >
> > Reason ... if the outage is to last 5-10 min in the middle of the night
> (ad
> > delta from current time vs eta or duration) the analyzing script will not
> > raise the alarm and will save few folks to being woken up. Simple and
> useful
> > IMHO. Not everyone has 24/7 NOC.
> >
> > And btw - while good idea - adding it show bgp neighbor will likely break
> > many parsers and will require yang model extension :).
> >
> > Cheers,
> > R.
> >
> > PS. Do we need to extend BMP too ?
> >
> >
> > _______________________________________________
> > Idr mailing list
> > Idr@ietf.org
> > https://www.ietf.org/mailman/listinfo/idr
> >
>
>
>
> --
> Marco
>

--001a114c877e2e0d420541a799ea
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Marco,

<=
/div>
No no ... I did not intended to define any TLVs .. =
that indeed would be indeed an overkill here. Just few loose keywords to be=
 optionally present in the free form text which any basic script could dete=
ct and make educated action.=C2=A0

Best,
R.

=


On Sa=
t, Nov 19, 2016 at 2:39 PM, Marco Marzetti <marco@lamehost.it> wrote:
Robert,



Despite i like the idea to use this feature in automation, it sounds

overkill to me to force TLVs.

Wouldn't be simpler to define the message as UTF8 string and let

operators do what they think is more reasonable?



AFAIK we don't have standards that defines "assurance messages&quo=
t; (do

we?) and this draft is not the right place to define it



Regards




On Sat, Nov 19, 2016 at 2:22 PM, Robert Raszuk <robert@raszuk.net> wrote:

>> I'm certainly not against allowing people to send a URL

>> or other data, but our use case is likely to be the ticket# and/or=


>> a phone number for contacting our NOC to streamline communication.=


>

>

> Actually what drove my suggestion for URL was as usual desire for

> automation.

>

> As 128 octets of unstructured free form text is proposed that still re=
quires

> human reading the text which is something we should try to avoid IMHO.=
 Worse

> it requires someone to pick up the phone and make a call ...

>

> At min perhaps draft should define few optional prefixes/key words whi=
ch

> could be machine recognized: "url:", "mail:", &quo=
t;phone:", "description:",

> "eta:", "ticket:", "duration:" etc ....<=
br>
>

> Reason ... if the outage is to last 5-10 min in the middle of the nigh=
t (ad

> delta from current time vs eta or duration) the analyzing script will =
not

> raise the alarm and will save few folks to being woken up. Simple and =
useful

> IMHO. Not everyone has 24/7 NOC.

>

> And btw - while good idea - adding it show bgp neighbor will likely br=
eak

> many parsers and will require yang model extension :).

>

> Cheers,

> R.

>

> PS. Do we need to extend BMP too ?

>

>


> __________________=
_____________________________

> Idr mailing list

> Idr@ietf.org

> https://www.ietf.org/mailman/listinfo/idr

>








--

Marco





--001a114c877e2e0d420541a799ea--


From nobody Sat Nov 19 05:51:34 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FC601296D2; Sat, 19 Nov 2016 05:51:28 -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_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=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 aJpOWRNdMGqI; Sat, 19 Nov 2016 05:51:25 -0800 (PST)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0124.outbound.protection.outlook.com [104.47.2.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 419E51296CF; Sat, 19 Nov 2016 05:51:25 -0800 (PST)
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=ji6gJvbHe12FN+3Es+jtMUkkJMLW4Olc7YWTXFM1Qb8=; b=O1vlCkuL8W2TSFDNIIZvsPgGGfMNGiX1pkTpjm6JG2KpnudBZIHiKod5CmzHLyPVKT1Z1BSX3Dn1VeXr8wiPe+2xxAMBt/YlewLoP+xCuc4SWn1oWPNKlTwHHvIB6AvCcTFbzQTkP3SKylrSm5vLoNpvCYdsgON0WnYxbsm2OFk=
Received: from AM4PR03MB1425.eurprd03.prod.outlook.com (10.164.77.155) by AM4PR03MB1426.eurprd03.prod.outlook.com (10.164.77.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.721.10; Sat, 19 Nov 2016 13:51:22 +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.0721.017; Sat, 19 Nov 2016 13:51:21 +0000
From: "Neil J. McRae" 
To: Peter Hessler 
Thread-Topic: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
Thread-Index: AQHSP/9KqJ8HctM7aUO4ZcydBCJgGaDbkwIAgAAM1oCABLgufg==
Date: Sat, 19 Nov 2016 13:51:21 +0000
Message-ID: 
References: <20161116061556.GG1073@dhcp-9341.meeting.ietf.org> <20161116105535.GW79185@Space.Net> <1479295774707.77855@dacor.de> <20161116113849.udbrfvdhaj3be7nx@bongo.bofh.it> <20161116130110.GK1073@dhcp-9341.meeting.ietf.org>, <20161116134707.GP24817@gir.theapt.org>
In-Reply-To: <20161116134707.GP24817@gir.theapt.org>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=neil@domino.org; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [188.29.165.86]
x-microsoft-exchange-diagnostics: 1; AM4PR03MB1426; 7:5KCFsgJtKzouTb4oSZLmBpQYrgiXmw0YzXf4uywNHRqEpjpDJnaB0X+eSBPboSXEY0wicuiE2na0RbmPQJIvzJxYNaXFTQZoN6NQYsLVwh8MKr9ziN81kODKEk1csuD7UQWPibcPwIy4Etg5e6T9ziJlMIbg9GSZKiVFoGxuclaw15Kpj0kYcxwyl8yBORPBlC6Rgl0bw0ENjo/v9Ukwn9RvQU23gmozQ4obRh+k29Kz/LRCN6taN2lQFDkHHs/HPh9yZozidsOg882RUjmjfxSDkAh8ZXdACWJ2JPh2vzBgXrB0B9L2gyGJOEGjyvHRscaIyxyzW/ufq0Um/TL7T2X3MLJ4c3y1uXymD4hcR3o=
x-ms-office365-filtering-correlation-id: a1706a86-c143-423f-68ff-08d410832530
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:AM4PR03MB1426;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705)(144208319314845); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6060326)(6040307)(6045199)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6061324)(6041248)(2016111802025)(6043046); SRVR:AM4PR03MB1426; BCL:0; PCL:0; RULEID:; SRVR:AM4PR03MB1426; 
x-forefront-prvs: 0131D22242
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(199003)(24454002)(7846002)(33656002)(5660300001)(8676002)(122556002)(7736002)(101416001)(230783001)(93886004)(50986999)(305945005)(105586002)(106356001)(83716003)(106116001)(8936002)(66066001)(76176999)(54356999)(97736004)(87936001)(6916009)(2900100001)(2950100002)(3846002)(82746002)(6116002)(77096005)(102836003)(81166006)(2906002)(68736007)(6506003)(6512003)(81156014)(86362001)(38730400001)(3280700002)(5003630100001)(3660700001)(4326007)(229853002)(36756003)(189998001)(92566002)(110136003)(21314002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR03MB1426; H:AM4PR03MB1425.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  MX:1; A:0; LANG:en; 
received-spf: None (protection.outlook.com: domino.org does not designate permitted sender hosts)
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: 19 Nov 2016 13:51:21.6131 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 398f3eb4-3394-48e7-885c-de1ab2a9cf2e
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR03MB1426
Archived-At: 
Cc: "idr@ietf.org" , "grow@ietf.org" 
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 19 Nov 2016 13:51:28 -0000

I personally think this is a really bad idea but understand why some might =
want this - and we've had similar drafts in the past- in my view  we should=
n't be moving more towards more human related randomness in system level me=
ssages - have a set of status numbers or something that can be predictable =
but randomly "we took the peer down whilst we went to McDonald's" as oppose=
d to CEASE reason 666 - we depeered or reason 999 we have a problem call us=
 would be a much better approach. We can't keep running networks like we di=
d 20 years ago!=20

Thanks
Neil=20
Sent from my iPhone

> On 16 Nov 2016, at 13:47, Peter Hessler  wrote:
>=20
> On 2016 Nov 16 (Wed) at 22:01:10 +0900 (+0900), Job Snijders wrote:
> :I hope to capture in the draft that an implementation can choose which
> :characters of the Shutdown Communication they represent in the syslog or
> :'show bgp neighbor xxx' output. For instance, I'd recommend to squash
> :all newline/newpage/newfeed/newparagraph style chars and make sure that
> :the Communication is represented on a single line. I don't have the
> :proper words for the draft to express that (yet).
>=20
> I've been thinking about wording for protecting the receiving system
> from possible bad input.  I'm not worried about (valid) UTF-8 display
> chars, nor about whitespace things.  I am worried about Little Bobby
> Tables, though.
>=20
> We also have to consider that this will be displayed possibly in a Unix
> Shell, Windows Shell, Syslog, SQL server, Web Server; and different
> chars have different meanings there.
>=20
> I'm not quite happy with the wording, but I would like something along
> these lines added.  Possibly in the Security section, or at the end of
> Section #2.
>=20
> =3D=3D=3D=3D
> Receiving systems SHOULD filter the message for the intended output
> environment and MAY change octets or sequences of octets for their  =20
> local environment.
> As the message may be displayed on a command line, stored
> in a syslog server, in an SQL database, or even a Web Server different
> outputs MAY happen.
> Sending systems MUST NOT depend on changes to their
> sequences not happening.
> =3D=3D=3D=3D
>=20
> (Consider, Little Bobby Tables https://www.xkcd.com/327/, printf
> escapes, Javascript/HTML, etc)=20
>=20
>=20
> --=20
> Taxes, n.:
>    Of life's two certainties, the only one for which you can get
>    an extension.
>=20
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr


From nobody Sat Nov 19 05:53:16 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43C3F1296CF for ; Sat, 19 Nov 2016 05:53:15 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=lamehost-it.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 9T8Gia24ZnaW for ; Sat, 19 Nov 2016 05:53:13 -0800 (PST)
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 C980E1296EC for ; Sat, 19 Nov 2016 05:53:10 -0800 (PST)
Received: by mail-wm0-x232.google.com with SMTP id f82so77243402wmf.1 for ; Sat, 19 Nov 2016 05:53:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lamehost-it.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cnEarG2j51G4vhlol99bWrfZWrmgjd56UmmP+N53DmM=; b=cp1rFuoK9Hb64fz0E+/9Y2+ed/9qew+b6ghNesKHSBR/WipEliTCX1ZFixWYXOzowM fLPDQJeRBLADbfXvsQ3p0Y5WWUP48G5W1VRtfCoyIX5isz6xdlSqSRG+kh95koHnyTCs h/BcjZjdq7ByvhCAhTFmBxogcVuwz20CGBwx/86OnK+eMJ1HqF3qwvy3OtWkGG7fBR+5 ZjNvXa5TjWKL2pUyqGMmifCXv7xYFVsB9WGBto9wzTamG/ejlC9sWWizsJEzos6TGiR1 NGVG9IVo3dOqC49TxclCA5FoZheZDEIOmYMzunKwPmjiUh10aJj9R8Oe8P9XUCVIEndG B6gA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cnEarG2j51G4vhlol99bWrfZWrmgjd56UmmP+N53DmM=; b=cPNQA7+z+RTsnx4ngOR7QsvtRjfk35iIgi/TLdU+f2FXK/mEpUQ72jAVkDJ5w1XIKC EfoFlxgL8kQL9ISdzQbXyPpuVzONBKS9viD/zfsR8mzyj7PiT4T8di4YvwE5aAeaBw8H LInSK5a4DjHs0jVSMWUuWvWaeVEwQcd+glHtTHg17n5QE59DRkTZUxbjMltoha9wBlm2 2QKw1ohb2+k64/zmch4em6sSk+onOkHrXZ6FpguAvyPu8gp1e7reoUuSp8l0C/fqHLeH NvWGYhiCoim+VaRsllwdZNPPXdc8DOvzt3KjFuzkiWx0yEOmMHr2HDuc85l0USbad5cS JGvA==
X-Gm-Message-State: AKaTC00ybF6Cgt1EdDmyqa+RVUK+BnV4l5Q8isiNVVyxZd0IyN7jfdSBE2qlM+K6y9Oq/+bGboiY6OAuz7YRUA==
X-Received: by 10.25.75.80 with SMTP id y77mr993354lfa.173.1479563589281; Sat, 19 Nov 2016 05:53:09 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.202.14 with HTTP; Sat, 19 Nov 2016 05:53:08 -0800 (PST)
X-Originating-IP: [79.24.77.5]
In-Reply-To: 
References: <147910154788.10388.9578791609428008498.idtracker@ietfa.amsl.com> <20161115044027.GI67788@dhcp-9341.meeting.ietf.org> <20161115055431.GB5875@pfrc.org> <20161115092211.GK24817@gir.theapt.org>  <20161116030853.GD1073@dhcp-9341.meeting.ietf.org> 
From: Marco Marzetti 
Date: Sat, 19 Nov 2016 14:53:08 +0100
Message-ID: 
To: Randy Bush 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: idr wg , Peter Hessler 
Subject: Re: [Idr] New Version Notification for draft-ymbk-idr-bgp-open-policy-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: Sat, 19 Nov 2016 13:53:15 -0000

Authors,

I really don't think that we should mix business relationships with
technical needs and, in any case, that you can narrow them down to
what's available in the draft.
Not that the draft is missing anything, but everything gets complex
and "not so clear" when it comes to sales or mutual partnerships.

My understanding is you aim to negotiate the relationship during
session setup so that "who's going to send what" is clear to
everybody.
Have you ever considered to remove that part and let operators to mark
the session as they prefer?

Regards

On Wed, Nov 16, 2016 at 4:11 AM, Randy Bush  wrote:
>>> this may all be true, but is irrelevant.  this is not a community, but
>>> an attribute; speifically to avoid my fat fingers.
>>
>> yes, however a downside is that there is no "backwards compatibility",
>> in the sense that I can't implement it myself in routing policy and
>> require my vendor to give me new software.
>>
>> Working group should be aware of that consequence.
>
> that's why it is in idr not grow.  our fat fingers have been making
> negative news headlines for over two decades, and it needs to stop.
>
> randy
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr



-- 
Marco


From nobody Sat Nov 19 05:56:23 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA7681296B2 for ; Sat, 19 Nov 2016 05:56:20 -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, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lamehost-it.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 lEWcee05cMEC for ; Sat, 19 Nov 2016 05:56:18 -0800 (PST)
Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE5981296F0 for ; Sat, 19 Nov 2016 05:56:17 -0800 (PST)
Received: by mail-wm0-x229.google.com with SMTP id t79so77042392wmt.0 for ; Sat, 19 Nov 2016 05:56:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lamehost-it.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=yG/B90p+iQITuLeCEO4qkvQ2gsxUDGJ40ndh2B2xmUc=; b=EUxaY/Jlc9IrC5lQfCnSIoWZUCg2VjcpC5AZjcX9zFXLCQKa7Oao1vOWG2gMhWLmxQ 9DVOgkt2O42JMxvRni7HW3GBDK7PpBiXju+Iev3zqEvb3B1T0yUwfrnqAIB4LTT8oGfn hKxoqTWPvfyygYslO3pAPESR3JxzptJ4ng/paguufWxxOAUTFYy0yA0kKEzZluosuuZl /apRjYuBCc4NJCLEycA2ecRqF5ZUtniso4sYgBX0lU1OgmU29p5CZlsDAD/1MOZCwKAs yX8yY0AGFOTbcL0EHxuOCT2ZHWSRk7EpHVl6hfMYDqRaVhxivCzINighr+w5uNVfuvje eV8g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=yG/B90p+iQITuLeCEO4qkvQ2gsxUDGJ40ndh2B2xmUc=; b=eZhzWG+Gs5uiSuP1hq/LwE9YSSMnwhK/lAectd/9D+lKwXltaxJmNS0Rap/CnqsyYW FTukjBljAnpFvtD8bB3claG3tKmz1bbHSavItiFAk+NVHeJs/fr2ChS5hh+c7AFsZj3T tFx4GrVVQXQKhYFec53TEqc9fOPPd/S7EYyUR1XHAfzcdqRo3p82VbdThwI9Vzuzy3zt AFy48lks8WpRSk9cjbCJYWm0cPu26QCXpkNILR/t+SREhkKaoZwqqn5v1+hkXGa26P9D MHpZQdYZ/m8WMpgaeO27g3Nt4xWHsc79P4Hh/T9t0spHmOMK+K+lyJRwBe7pfjDtgbay /Saw==
X-Gm-Message-State: AKaTC02xmEq6SUpsHVs+/13ABoktA5HiHxj+cdE5jqPiPSFlbeKsusWi16+wARhLGBzq8VOI0w9FSNzwmGCcQQ==
X-Received: by 10.46.71.210 with SMTP id u201mr2680333lja.69.1479563776417; Sat, 19 Nov 2016 05:56:16 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.202.14 with HTTP; Sat, 19 Nov 2016 05:56:15 -0800 (PST)
X-Originating-IP: [79.24.77.5]
In-Reply-To: 
References: <20161116061556.GG1073@dhcp-9341.meeting.ietf.org> <20161116105535.GW79185@Space.Net> <1479295774707.77855@dacor.de> <20161116113849.udbrfvdhaj3be7nx@bongo.bofh.it> <20161116130110.GK1073@dhcp-9341.meeting.ietf.org> <20161116134707.GP24817@gir.theapt.org> 
From: Marco Marzetti 
Date: Sat, 19 Nov 2016 14:56:15 +0100
Message-ID: 
To: "Neil J. McRae" 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: "idr@ietf.org" , "grow@ietf.org" , Peter Hessler 
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 19 Nov 2016 13:56:21 -0000

Robert,

So you're suggesting to include recommendation for the formatting?
That could help (as long as it's not mandatory).

Regards


On Sat, Nov 19, 2016 at 2:51 PM, Neil J. McRae  wrote:
> I personally think this is a really bad idea but understand why some migh=
t want this - and we've had similar drafts in the past- in my view  we shou=
ldn't be moving more towards more human related randomness in system level =
messages - have a set of status numbers or something that can be predictabl=
e but randomly "we took the peer down whilst we went to McDonald's" as oppo=
sed to CEASE reason 666 - we depeered or reason 999 we have a problem call =
us would be a much better approach. We can't keep running networks like we =
did 20 years ago!
>
> Thanks
> Neil
> Sent from my iPhone
>
>> On 16 Nov 2016, at 13:47, Peter Hessler  wrote:
>>
>> On 2016 Nov 16 (Wed) at 22:01:10 +0900 (+0900), Job Snijders wrote:
>> :I hope to capture in the draft that an implementation can choose which
>> :characters of the Shutdown Communication they represent in the syslog o=
r
>> :'show bgp neighbor xxx' output. For instance, I'd recommend to squash
>> :all newline/newpage/newfeed/newparagraph style chars and make sure that
>> :the Communication is represented on a single line. I don't have the
>> :proper words for the draft to express that (yet).
>>
>> I've been thinking about wording for protecting the receiving system
>> from possible bad input.  I'm not worried about (valid) UTF-8 display
>> chars, nor about whitespace things.  I am worried about Little Bobby
>> Tables, though.
>>
>> We also have to consider that this will be displayed possibly in a Unix
>> Shell, Windows Shell, Syslog, SQL server, Web Server; and different
>> chars have different meanings there.
>>
>> I'm not quite happy with the wording, but I would like something along
>> these lines added.  Possibly in the Security section, or at the end of
>> Section #2.
>>
>> =3D=3D=3D=3D
>> Receiving systems SHOULD filter the message for the intended output
>> environment and MAY change octets or sequences of octets for their
>> local environment.
>> As the message may be displayed on a command line, stored
>> in a syslog server, in an SQL database, or even a Web Server different
>> outputs MAY happen.
>> Sending systems MUST NOT depend on changes to their
>> sequences not happening.
>> =3D=3D=3D=3D
>>
>> (Consider, Little Bobby Tables https://www.xkcd.com/327/, printf
>> escapes, Javascript/HTML, etc)
>>
>>
>> --
>> Taxes, n.:
>>    Of life's two certainties, the only one for which you can get
>>    an extension.
>>
>> _______________________________________________
>> Idr mailing list
>> Idr@ietf.org
>> https://www.ietf.org/mailman/listinfo/idr
>
> _______________________________________________
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow



--=20
Marco


From nobody Sat Nov 19 05:58:13 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21B371298AF for ; Sat, 19 Nov 2016 05:58:12 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 tQhDPk9tHaOF for ; Sat, 19 Nov 2016 05:58:10 -0800 (PST)
Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::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 6B79D1296F0 for ; Sat, 19 Nov 2016 05:58:10 -0800 (PST)
Received: by mail-oi0-x22b.google.com with SMTP id v84so117588991oie.3 for ; Sat, 19 Nov 2016 05:58:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LeVXB4cUsEdcfqxRw/B0c9cfOZa+pz9AdiBBHVaKNmY=; b=sxObaSTQFqCy+8jJ+UXJZKHirk4IPP89q7TP9z2elGjxL7XTZBnCsiarTFspms+OZE jhpxJElxY5Gsf6p7b+aLZNMzwtSRaKBCEL45SaZ1iLfBvyTK4OuGtQJQhtysabrw2P1m 276aTNa3c+7XWhtHXOEeLLxL2475hMDIW8DwEBxB4gq88y7y82r8n3M7UDTDfMzCZque a5XIhesBLm5OSoUWKesk0dU+4CFaeNsXgsrCczXSGz7/ztRM7qR4PMKREVvkeLo86MLK f+AuwhtHUSQOZ3oG/ZeJcoDyFhnXSsQyK4I+jtVIHrBfcwMrMqkUR57tUKez1b1hNCjV x7Vg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LeVXB4cUsEdcfqxRw/B0c9cfOZa+pz9AdiBBHVaKNmY=; b=iqPyo/edW4JzFURQnc+WTn/nvNuViRySP5pSAPi0zmT8wS1SHDIq+K14E87aSEclvh FkNszanvn900DIG0zzdH3Nfj6gm2EV+Xs4iEAkEJXD1Mryyesb/vJIDXv6QO4wJIBmUz VGFsB9YZGwshjiZTDte6oSbfgrjNtvhIUhPfl2xktpFPfUfW1zvxF+/QJ3iZNWlLlm5N IDUFO3rnm86+WIVzxuxSRYCIL0p8qgq8sFBDfDBYvxgWYyWKWIAr/1Lo2ABiZAXT2yWe X652XUO1G1EKkfBbl8IZhtgtPy9DTPScjKIQXfk97UzTrFhq7rmoJkEiBjETuCnWYiOJ sw1A==
X-Gm-Message-State: AKaTC03KcCgvmbluDRk9FL5x1aL91B4Jyp4CHWc3E+UMSGx3DCKy1oK/XJtS3hBqELo4JZS9K4VFNxn5fo43LA==
X-Received: by 10.157.3.98 with SMTP id 89mr2830557otv.261.1479563889787; Sat, 19 Nov 2016 05:58:09 -0800 (PST)
MIME-Version: 1.0
References: <20161117013640.GB6217@pfrc.org> <16426_1479400131_582DDAC3_16426_1669_1_53C29892C857584299CBF5D05346208A1EC87201@OPEXCNORM2F.corporate.adroot.infra.ftgroup> <20161118004548.GK1072@dhcp-9341.meeting.ietf.org> <16418_1479457940_582EBC93_16418_290_1_53C29892C857584299CBF5D05346208A1EC8DEA5@OPEXCLILM21.corporate.adroot.infra.ftgroup>  <13357_1479459134_582EC13E_13357_5786_1_53C29892C857584299CBF5D05346208A1EC8FF18@OPEXCLILM21.corporate.adroot.infra.ftgroup> <37224750-4065-40E3-B6F4-571DED698563@cisco.com> <20161119103226.GN1072@dhcp-9341.meeting.ietf.org>  <20161119123229.GD4992@skriver.dk> <20161119123645.GB2472@puck.nether.net>   
In-Reply-To: 
From: Job Snijders 
Date: Sat, 19 Nov 2016 13:57:58 +0000
Message-ID: 
To: Marco Marzetti , Robert Raszuk 
Content-Type: multipart/alternative; boundary=94eb2c0484cc12d9960541a7d069
Archived-At: 
Cc: idr wg 
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 19 Nov 2016 13:58:12 -0000

--94eb2c0484cc12d9960541a7d069
Content-Type: text/plain; charset=UTF-8

IETF's IDR doesn't need to micromanage the payload contents of free form
string. Let operators figure it out. Maybe a standard develops, maybe not.
Free form is free form.

Job

--94eb2c0484cc12d9960541a7d069
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


IETF's IDR doesn't need to micr=
omanage the payload contents of free form string. Let operators figure it o=
ut. Maybe a standard develops, maybe not. Free form is free form. 

Job


--94eb2c0484cc12d9960541a7d069--


From nobody Sat Nov 19 05:59:07 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 693511298BB for ; Sat, 19 Nov 2016 05:59:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level: 
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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 q6LULhZE6auL for ; Sat, 19 Nov 2016 05:59:04 -0800 (PST)
Received: from mail-qt0-x242.google.com (mail-qt0-x242.google.com [IPv6:2607:f8b0:400d:c0d::242]) (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 74B1F1298AE for ; Sat, 19 Nov 2016 05:59:04 -0800 (PST)
Received: by mail-qt0-x242.google.com with SMTP id n34so21154675qtb.3 for ; Sat, 19 Nov 2016 05:59:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Bj80HRtuWjtzUfljt40NTJkFbQadkr4vAup7CkLIqtg=; b=ZgTeGd18SqfPchOPo/DIlp9fYnBUpZbQzA1A29/Qyy/Oxbl/VcXsX0AesehamgPSpi +HNTEKr/r6fhGGgUb3x8/b3hyl4HSBKkISLc/BwqKcStfu7BFukLBkc3L0aL6XbC3id8 Rrl6Q5I2FoHRzlKIDTp+ubnzIbNWcaoojY1WWjEwvpt5zPHX1VyWLT9Wf0jiCXRPMKTw V4iuIzOgFFN/urNz2kgb/ItJ9NOHjNqGLijowD1ZpyagzNsnAJOsrlbROCkC2aYrbc1e a6d63O2O9OxHOgkzrpT0up2tef4v/RrK6BpUO59t3pHc6MmAuG4KsBxGrc5R+ZwTg401 x8Sw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Bj80HRtuWjtzUfljt40NTJkFbQadkr4vAup7CkLIqtg=; b=TmZSgZkCJvNKVt5cK8RM5tMr3V9qFnRcjK2XtO1/mYoqfu9cQCd6hzTu+dCXD2kEz6 /6xFwI9zzAbEmMg/HZuG88Wo9/JAzyL6juB+4IQewBK1Lw8tjNNYl69Jkkky1dlJLWWN nX/UV6bXwcOKTKvkde85YE9Dxy45TdFL4Uqg9tV9RkCtI1/8suXwkr6XKPmczbFdgd0j BdwAojjvjsBIfJ3/elT0ibv3/L5kT1I8mqjR1zLiMTw2rpAcP/bzYmbvFSjsDrKtyu9R yw6TNFmcJB1w6CUTc2pN7EUEAXN4hDJcLdR3enJ1a/RXZXwh703e6qwBstQ3c7jU8kZa tvTg==
X-Gm-Message-State: AKaTC00lz7EZ8kDxWu62WuZ633Fdmpx6bivtT6OlSXn0Y+EqczF3RYgU3w/bEGYclU/Pu9uqiXqngnK6vl7bZQ==
X-Received: by 10.237.37.77 with SMTP id w13mr3406365qtc.197.1479563943598; Sat, 19 Nov 2016 05:59:03 -0800 (PST)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.140.16.50 with HTTP; Sat, 19 Nov 2016 05:59:02 -0800 (PST)
In-Reply-To: 
References: <147910154788.10388.9578791609428008498.idtracker@ietfa.amsl.com> <20161115044027.GI67788@dhcp-9341.meeting.ietf.org> <20161115055431.GB5875@pfrc.org> <20161115092211.GK24817@gir.theapt.org>  <20161116030853.GD1073@dhcp-9341.meeting.ietf.org>  
From: Robert Raszuk 
Date: Sat, 19 Nov 2016 14:59:02 +0100
X-Google-Sender-Auth: odjKEphmXLA0nAMbF-q-KdDzkQE
Message-ID: 
To: Marco Marzetti 
Content-Type: multipart/alternative; boundary=001a114108ea47e3c60541a7d3a9
Archived-At: 
Cc: idr wg , Peter Hessler 
Subject: Re: [Idr] New Version Notification for draft-ymbk-idr-bgp-open-policy-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: Sat, 19 Nov 2016 13:59:06 -0000

--001a114108ea47e3c60541a7d3a9
Content-Type: text/plain; charset=UTF-8

Hi Marco,

What this draft is really about is to enforce by hard coding in RFC bgp
policy from ingress to egress of given network. And while the idea is
brilliant on surface I spoke with one vendor at the IETF who clearly said
"no way" we will provide knob to ignore that new attribute ... hence the
crux of the idea will be gone.

I think if we are really serious about route leaking 4271 should be updates
to add explicit few more BGP session types and by MUST enforce that those
can not be overwritten by local knobs or flags.

Best,
R.

On Sat, Nov 19, 2016 at 2:53 PM, Marco Marzetti  wrote:

> Authors,
>
> I really don't think that we should mix business relationships with
> technical needs and, in any case, that you can narrow them down to
> what's available in the draft.
> Not that the draft is missing anything, but everything gets complex
> and "not so clear" when it comes to sales or mutual partnerships.
>
> My understanding is you aim to negotiate the relationship during
> session setup so that "who's going to send what" is clear to
> everybody.
> Have you ever considered to remove that part and let operators to mark
> the session as they prefer?
>
> Regards
>
> On Wed, Nov 16, 2016 at 4:11 AM, Randy Bush  wrote:
> >>> this may all be true, but is irrelevant.  this is not a community, but
> >>> an attribute; speifically to avoid my fat fingers.
> >>
> >> yes, however a downside is that there is no "backwards compatibility",
> >> in the sense that I can't implement it myself in routing policy and
> >> require my vendor to give me new software.
> >>
> >> Working group should be aware of that consequence.
> >
> > that's why it is in idr not grow.  our fat fingers have been making
> > negative news headlines for over two decades, and it needs to stop.
> >
> > randy
> >
> > _______________________________________________
> > Idr mailing list
> > Idr@ietf.org
> > https://www.ietf.org/mailman/listinfo/idr
>
>
>
> --
> Marco
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>

--001a114108ea47e3c60541a7d3a9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Marco,

<=
/div>
What this draft is really about is to enforce by ha=
rd coding in RFC bgp policy from ingress to egress of given network. And wh=
ile the idea is brilliant on surface I spoke with one vendor at the IETF wh=
o clearly said "no way" we will provide knob to ignore that new a=
ttribute ... hence the crux of the idea will be gone.=C2=A0

I think if we are really serious abou=
t route leaking 4271 should be updates to add explicit few more BGP session=
 types and by MUST enforce that those can not be overwritten by local knobs=
 or flags.=C2=A0

Best,=

R.=C2=A0
On Sat, Nov 19, 2016 at 2:53 PM, Marco Marzetti=
 <marco@lamehost.it> wrote:


On Wed, Nov 16, 2016 at 4:11 AM, Randy Bush <randy@psg.com> wrote:

>>> this may all be true, but is irrelevant.=C2=A0 this is not a c=
ommunity, but

>>> an attribute; speifically to avoid my fat fingers.

>>

>> yes, however a downside is that there is no "backwards compat=
ibility",

>> in the sense that I can't implement it myself in routing polic=
y and

>> require my vendor to give me new software.

>>

>> Working group should be aware of that consequence.

>

> that's why it is in idr not grow.=C2=A0 our fat fingers have been =
making

> negative news headlines for over two decades, and it needs to stop.
>

> randy

>

> _______________________________________________

> Idr mailing list

> Idr@ietf.org

> https://www.ietf.org/mailman/listinfo/idr








--

Marco




_______________________________________________

Idr mailing list

Idr@ietf.org

https://www.ietf.org/mailman/listinfo/idr





--001a114108ea47e3c60541a7d3a9--


From nobody Sat Nov 19 06:07:21 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEF9F129436; Sat, 19 Nov 2016 06:07:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level: 
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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 qPOzmEiqFNgY; Sat, 19 Nov 2016 06:07:15 -0800 (PST)
Received: from mail-qt0-x242.google.com (mail-qt0-x242.google.com [IPv6:2607:f8b0:400d:c0d::242]) (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 78DDE129415; Sat, 19 Nov 2016 06:07:15 -0800 (PST)
Received: by mail-qt0-x242.google.com with SMTP id n34so21167234qtb.3; Sat, 19 Nov 2016 06:07:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=HXOhJtR6JfFHxQiBu57BsLEp6ehmK1GBHvOqDvSXwbo=; b=kOhVrX3MT0pZyDg1DoNuzr6ISkV9pJEyZwuLSScze//59hMj9GMQuyIuc8quZvA27X U0mvmrAlgCRMaDiza8QeBy/HyMAaljtJotPQhtnO0ZHkEV2ENZeLZbsFx6s/9InI/T8l J5s9umaSwIX0OOZkRZz5FK998DG/Ti4IUsvTvMB4e9fSIKLiduihuKN6vtp/Pz+UPHfU JZwXrxH6nqsvxYMmE7nDsmzLJdJ9LgQpeU3FXwwOEyeN24Ycs+//mK3JQaPVAZ0QSfbb 4TWlU06dPUv9LOdlEreZXKCwHGSFFuOhKRoDq9FnTcMF92p0cI4APzSXPxPcIxXqby5O rZrg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=HXOhJtR6JfFHxQiBu57BsLEp6ehmK1GBHvOqDvSXwbo=; b=IbL+MG0z3ZxHYfPwnMdEHDzu/HsVqJYrqTp6NqLrLF78FngQyzrtfcxf3xWfwvFgmB DeVKRhqkw3oXDLeAMgwpmC9iLC043DVnb/LmBGZu7mZ61TIfpMLkr+wLkmWdQx1VR0Tz 5DKXboEnC/RpgTvbfC2TaG1MORuydMZzsn8lRnYxVaYHQQFM5+F9ByISGdGwh5wqLahV dJYJ8RLMFrl3SL4VytA9dzR8BeFc/NbFdwnf0bfUME+/M5eQ1UMBu0IOSAIoVnxNp5R6 +Ys9NMt6euIfcU7lEbQe4L9HSUEcoYptGenxOAU28D1igFAQt+w8jlNT81XtxQ96RR8P TvHA==
X-Gm-Message-State: AKaTC03Y3dcDVqFk9onLnCOqftes50KZijOuu6G+VIIzh8Lu0zS0UiI+8WPckt9SezmGyiJuHYYCSChPCZoImw==
X-Received: by 10.200.40.27 with SMTP id 27mr2962799qtq.281.1479564434501; Sat, 19 Nov 2016 06:07:14 -0800 (PST)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.140.16.50 with HTTP; Sat, 19 Nov 2016 06:07:13 -0800 (PST)
In-Reply-To: 
References: <20161116061556.GG1073@dhcp-9341.meeting.ietf.org> <20161116105535.GW79185@Space.Net> <1479295774707.77855@dacor.de> <20161116113849.udbrfvdhaj3be7nx@bongo.bofh.it> <20161116130110.GK1073@dhcp-9341.meeting.ietf.org> <20161116134707.GP24817@gir.theapt.org>  
From: Robert Raszuk 
Date: Sat, 19 Nov 2016 15:07:13 +0100
X-Google-Sender-Auth: 8G6X1XS8SsXcfeN_DlufZgM1rC0
Message-ID: 
To: Marco Marzetti 
Content-Type: multipart/alternative; boundary=001a114072108a76200541a7f032
Archived-At: 
Cc: "idr@ietf.org" , "grow@ietf.org" , Peter Hessler 
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 19 Nov 2016 14:07:18 -0000

--001a114072108a76200541a7f032
Content-Type: text/plain; charset=UTF-8

Marco,

Yes indeed. As said it would be completely optional.

Job,

Free form is so old fashioned that it really does not even sound
reasonable. Why do you want everything to be "figured out" outside of IDR ?
Why for everything we recently propose there must be 5 documents to read
all in different forums/groups to use it ? Do you prefer to hard encode
TLVs to make the proposal parsable ?

Please remember you are extending BGP as the protocol used by many who do
not even know what IDR or GROW is. Not everyone who uses BGP has time for
IETF or NANOG or RIPE.

Cheers,
R.



On Sat, Nov 19, 2016 at 2:56 PM, Marco Marzetti  wrote:

> Robert,
>
> So you're suggesting to include recommendation for the formatting?
> That could help (as long as it's not mandatory).
>
> Regards
>
>
> On Sat, Nov 19, 2016 at 2:51 PM, Neil J. McRae  wrote:
> > I personally think this is a really bad idea but understand why some
> might want this - and we've had similar drafts in the past- in my view  we
> shouldn't be moving more towards more human related randomness in system
> level messages - have a set of status numbers or something that can be
> predictable but randomly "we took the peer down whilst we went to
> McDonald's" as opposed to CEASE reason 666 - we depeered or reason 999 we
> have a problem call us would be a much better approach. We can't keep
> running networks like we did 20 years ago!
> >
> > Thanks
> > Neil
> > Sent from my iPhone
> >
> >> On 16 Nov 2016, at 13:47, Peter Hessler  wrote:
> >>
> >> On 2016 Nov 16 (Wed) at 22:01:10 +0900 (+0900), Job Snijders wrote:
> >> :I hope to capture in the draft that an implementation can choose which
> >> :characters of the Shutdown Communication they represent in the syslog
> or
> >> :'show bgp neighbor xxx' output. For instance, I'd recommend to squash
> >> :all newline/newpage/newfeed/newparagraph style chars and make sure
> that
> >> :the Communication is represented on a single line. I don't have the
> >> :proper words for the draft to express that (yet).
> >>
> >> I've been thinking about wording for protecting the receiving system
> >> from possible bad input.  I'm not worried about (valid) UTF-8 display
> >> chars, nor about whitespace things.  I am worried about Little Bobby
> >> Tables, though.
> >>
> >> We also have to consider that this will be displayed possibly in a Unix
> >> Shell, Windows Shell, Syslog, SQL server, Web Server; and different
> >> chars have different meanings there.
> >>
> >> I'm not quite happy with the wording, but I would like something along
> >> these lines added.  Possibly in the Security section, or at the end of
> >> Section #2.
> >>
> >> ====
> >> Receiving systems SHOULD filter the message for the intended output
> >> environment and MAY change octets or sequences of octets for their
> >> local environment.
> >> As the message may be displayed on a command line, stored
> >> in a syslog server, in an SQL database, or even a Web Server different
> >> outputs MAY happen.
> >> Sending systems MUST NOT depend on changes to their
> >> sequences not happening.
> >> ====
> >>
> >> (Consider, Little Bobby Tables https://www.xkcd.com/327/, printf
> >> escapes, Javascript/HTML, etc)
> >>
> >>
> >> --
> >> Taxes, n.:
> >>    Of life's two certainties, the only one for which you can get
> >>    an extension.
> >>
> >> _______________________________________________
> >> Idr mailing list
> >> Idr@ietf.org
> >> https://www.ietf.org/mailman/listinfo/idr
> >
> > _______________________________________________
> > GROW mailing list
> > GROW@ietf.org
> > https://www.ietf.org/mailman/listinfo/grow
>
>
>
> --
> Marco
>
> _______________________________________________
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow
>

--001a114072108a76200541a7f032
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Marco,

Yes indeed. As said it would be completely optional.=
=C2=A0

Job,

Free form is so old fashioned th=
at it really does not even sound reasonable. Why do you want everything to =
be "figured out" outside of IDR ? Why for everything we recently =
propose there must be 5 documents to read all in different forums/groups to=
 use it ? Do you prefer to hard encode TLVs to make the proposal parsable ?=
=C2=A0

Please remember=
 you are extending BGP as the protocol used by many who do not even know wh=
at IDR or GROW is. Not everyone who uses BGP has time for IETF or NANOG or =
RIPE.=C2=A0

Cheers,
R.



On S=
at, Nov 19, 2016 at 2:56 PM, Marco Marzetti <marco@lamehost.it> wrote:
Robert,



So you're suggesting to include recommendation for the formatting?

That could help (as long as it's not mandatory).



Regards






On Sat, Nov 19, 2016 at 2:51 PM, Neil J. McRae <neil@domino.org> wrote:

> I personally think this is a really bad idea but understand why some m=
ight want this - and we've had similar drafts in the past- in my view=
=C2=A0 we shouldn't be moving more towards more human related randomnes=
s in system level messages - have a set of status numbers or something that=
 can be predictable but randomly "we took the peer down whilst we went=
 to McDonald's" as opposed to CEASE reason 666 - we depeered or re=
ason 999 we have a problem call us would be a much better approach. We can&=
#39;t keep running networks like we did 20 years ago!

>

> Thanks

> Neil

> Sent from my iPhone

>

>> On 16 Nov 2016, at 13:47, Peter Hessler <phessler@theapt.org> wrote:

>>

>> On 2016 Nov 16 (Wed) at 22:01:10 +0900 (+0900), Job Snijders wrote=
:

>> :I hope to capture in the draft that an implementation can choose =
which

>> :characters of the Shutdown Communication they represent in the sy=
slog or

>> :'show bgp neighbor xxx' output. For instance, I'd rec=
ommend to squash

>> :all newline/newpage/newfeed/newparagraph style chars and mak=
e sure that

>> :the Communication is represented on a single line. I don't ha=
ve the

>> :proper words for the draft to express that (yet).

>>

>> I've been thinking about wording for protecting the receiving =
system

>> from possible bad input.=C2=A0 I'm not worried about (valid) U=
TF-8 display

>> chars, nor about whitespace things.=C2=A0 I am worried about Littl=
e Bobby

>> Tables, though.

>>

>> We also have to consider that this will be displayed possibly in a=
 Unix

>> Shell, Windows Shell, Syslog, SQL server, Web Server; and differen=
t

>> chars have different meanings there.

>>

>> I'm not quite happy with the wording, but I would like somethi=
ng along

>> these lines added.=C2=A0 Possibly in the Security section, or at t=
he end of

>> Section #2.

>>

>> =3D=3D=3D=3D

>> Receiving systems SHOULD filter the message for the intended outpu=
t

>> environment and MAY change octets or sequences of octets for their=


>> local environment.

>> As the message may be displayed on a command line, stored

>> in a syslog server, in an SQL database, or even a Web Server diffe=
rent

>> outputs MAY happen.

>> Sending systems MUST NOT depend on changes to their

>> sequences not happening.

>> =3D=3D=3D=3D

>>

>> (Consider, Little Bobby Tables https://www.xkcd.com/327/, prin=
tf

>> escapes, Javascript/HTML, etc)

>>

>>

>> --

>> Taxes, n.:

>>=C2=A0 =C2=A0 Of life's two certainties, the only one for which=
 you can get

>>=C2=A0 =C2=A0 an extension.

>>

>> _______________________________________________

>> Idr mailing list

>> Idr@ietf.org

>> https://www.ietf.org/mailman/listinfo/idr=


>

> _______________________________________________

> GROW mailing list

> GROW@ietf.org

> https://www.ietf.org/mailman/listinfo/grow







--

Marco




_______________________________________________

GROW mailing list

GROW@ietf.org

https://www.ietf.org/mailman/listinfo/grow





--001a114072108a76200541a7f032--


From nobody Sat Nov 19 06:08:00 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4535D12969A; Sat, 19 Nov 2016 06:07:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level: 
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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=unavailable 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 6KkS7--YGL4g; Sat, 19 Nov 2016 06:07:54 -0800 (PST)
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 053541296B2; Sat, 19 Nov 2016 06:00:20 -0800 (PST)
Received: by mail-qk0-x22c.google.com with SMTP id x190so299462086qkb.0; Sat, 19 Nov 2016 06:00:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ctCnjbTDU1mgM7wPyJ4TMySfsCuFAln6nqKryTCtYCU=; b=cgLFPCrbzIQrifZsVNu7g9aCkgZbWldrmo13iJxPxV6sA5T1dCr3p1aZ573teqPVVF 180mm+wuAnXPXnQNcfscsvEhcNmB/K/nF2euW7zYZdLniDKVgzDw2faEz/Y3U6C1w75y ByzgPpInvLVEkMbPkkswVXe7JUMohCTekeZfSHlycT+AAt5aTe9txGQ82vmUbyKmwhnW +OKdoapDU7tVoAzwe1pckXAC5/b7F5hPfumoBibax7/Xz/0LxfTb3ZzGIgRsVFzV/M0g 4oYbZUSSczHKLCNc4gI+DCBkmXA+dCJUzCs3OLlQxfYX8EnJuqy2YcxPi1W2dRwN2CiQ MSPA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=ctCnjbTDU1mgM7wPyJ4TMySfsCuFAln6nqKryTCtYCU=; b=YEkrKcsClQPdRSpAn8iOEoLuDsJwAos0JKkOERpS91OgymkYEus3F9a5njlviavZwG BVlNEquUWQaiS04q/sL2z/fEdrM4aFtt0nD2LAU6TmS+RtbzQ2JEueZ2bew8XzTCorL/ eL3R+AE3+eHQjOGBfOxMAUxc4OZ5wV7K+ZiSoVv+TAXzGDL0DBpvrXqOz8G+5YAqEX9i 7CFVtpBJ6mXtCMyqWuMd/ZBqD5L//GkAnvPcAgB88Rkdyk15kgLFgnBiy9AL0dUUVyjb zL93TD8oH/bc904v5r5cxV+H9156QwC+o+1Inj4WB3upzca8q1FoOZ6r5VA3qyzXmUIJ DuGg==
X-Gm-Message-State: AKaTC02WXWoY+VinlZ4SsYd2MRotS3C5CjS84x1PbRFevyg249FETdQVKGVrACPjMU7SZTzQomQF7NKU3K+8kg==
X-Received: by 10.55.156.81 with SMTP id f78mr6365174qke.123.1479564019092; Sat, 19 Nov 2016 06:00:19 -0800 (PST)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.140.16.50 with HTTP; Sat, 19 Nov 2016 06:00:18 -0800 (PST)
In-Reply-To: 
References: <20161116061556.GG1073@dhcp-9341.meeting.ietf.org> <20161116105535.GW79185@Space.Net> <1479295774707.77855@dacor.de> <20161116113849.udbrfvdhaj3be7nx@bongo.bofh.it> <20161116130110.GK1073@dhcp-9341.meeting.ietf.org> <20161116134707.GP24817@gir.theapt.org> 
From: Robert Raszuk 
Date: Sat, 19 Nov 2016 15:00:18 +0100
X-Google-Sender-Auth: HanhCjJFuPP7rs-IZeNCM78JyDA
Message-ID: 
To: "Neil J. McRae" 
Content-Type: multipart/alternative; boundary=94eb2c075ab4c7d5350541a7d7a3
Archived-At: 
Cc: "idr@ietf.org" , "grow@ietf.org" , Peter Hessler 
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 19 Nov 2016 14:07:57 -0000

--94eb2c075ab4c7d5350541a7d7a3
Content-Type: text/plain; charset=UTF-8

Whow ... extremely well said !

The idea for phone number beats me ... who uses voice phones these days ???

Cheers,
R.



On Sat, Nov 19, 2016 at 2:51 PM, Neil J. McRae  wrote:

> I personally think this is a really bad idea but understand why some might
> want this - and we've had similar drafts in the past- in my view  we
> shouldn't be moving more towards more human related randomness in system
> level messages - have a set of status numbers or something that can be
> predictable but randomly "we took the peer down whilst we went to
> McDonald's" as opposed to CEASE reason 666 - we depeered or reason 999 we
> have a problem call us would be a much better approach. We can't keep
> running networks like we did 20 years ago!
>
> Thanks
> Neil
> Sent from my iPhone
>
> > On 16 Nov 2016, at 13:47, Peter Hessler  wrote:
> >
> > On 2016 Nov 16 (Wed) at 22:01:10 +0900 (+0900), Job Snijders wrote:
> > :I hope to capture in the draft that an implementation can choose which
> > :characters of the Shutdown Communication they represent in the syslog or
> > :'show bgp neighbor xxx' output. For instance, I'd recommend to squash
> > :all newline/newpage/newfeed/newparagraph style chars and make sure that
> > :the Communication is represented on a single line. I don't have the
> > :proper words for the draft to express that (yet).
> >
> > I've been thinking about wording for protecting the receiving system
> > from possible bad input.  I'm not worried about (valid) UTF-8 display
> > chars, nor about whitespace things.  I am worried about Little Bobby
> > Tables, though.
> >
> > We also have to consider that this will be displayed possibly in a Unix
> > Shell, Windows Shell, Syslog, SQL server, Web Server; and different
> > chars have different meanings there.
> >
> > I'm not quite happy with the wording, but I would like something along
> > these lines added.  Possibly in the Security section, or at the end of
> > Section #2.
> >
> > ====
> > Receiving systems SHOULD filter the message for the intended output
> > environment and MAY change octets or sequences of octets for their
> > local environment.
> > As the message may be displayed on a command line, stored
> > in a syslog server, in an SQL database, or even a Web Server different
> > outputs MAY happen.
> > Sending systems MUST NOT depend on changes to their
> > sequences not happening.
> > ====
> >
> > (Consider, Little Bobby Tables https://www.xkcd.com/327/, printf
> > escapes, Javascript/HTML, etc)
> >
> >
> > --
> > Taxes, n.:
> >    Of life's two certainties, the only one for which you can get
> >    an extension.
> >
> > _______________________________________________
> > Idr mailing list
> > Idr@ietf.org
> > https://www.ietf.org/mailman/listinfo/idr
>
> _______________________________________________
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow
>

--94eb2c075ab4c7d5350541a7d7a3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



Whow ... e=
xtremely well said !

T=
he idea for phone number beats me ... who uses voice phones these days ???<=
/div>

Cheers,
R.



On Sat, Nov 19, 2016 at 2:51 PM=
, Neil J. McRae <neil@domino.org> wrote:
I personally think this is a really bad idea but understand w=
hy some might want this - and we've had similar drafts in the past- in =
my view=C2=A0 we shouldn't be moving more towards more human related ra=
ndomness in system level messages - have a set of status numbers or somethi=
ng that can be predictable but randomly "we took the peer down whilst =
we went to McDonald's" as opposed to CEASE reason 666 - we depeere=
d or reason 999 we have a problem call us would be a much better approach. =
We can't keep running networks like we did 20 years ago!



Thanks

Neil

Sent from my iPhone




> On 16 Nov 2016, at 13:47, Peter Hessler <phessler@theapt.org> wrote:

>

> On 2016 Nov 16 (Wed) at 22:01:10 +0900 (+0900), Job Snijders wrote:
> :I hope to capture in the draft that an implementation can choose whic=
h

> :characters of the Shutdown Communication they represent in the syslog=
 or

> :'show bgp neighbor xxx' output. For instance, I'd recomme=
nd to squash

> :all newline/newpage/newfeed/newparagraph style chars and make su=
re that

> :the Communication is represented on a single line. I don't have t=
he

> :proper words for the draft to express that (yet).

>

> I've been thinking about wording for protecting the receiving syst=
em

> from possible bad input.=C2=A0 I'm not worried about (valid) UTF-8=
 display

> chars, nor about whitespace things.=C2=A0 I am worried about Little Bo=
bby

> Tables, though.

>

> We also have to consider that this will be displayed possibly in a Uni=
x

> Shell, Windows Shell, Syslog, SQL server, Web Server; and different
> chars have different meanings there.

>

> I'm not quite happy with the wording, but I would like something a=
long

> these lines added.=C2=A0 Possibly in the Security section, or at the e=
nd of

> Section #2.

>

> =3D=3D=3D=3D

> Receiving systems SHOULD filter the message for the intended output
> environment and MAY change octets or sequences of octets for their

> local environment.

> As the message may be displayed on a command line, stored

> in a syslog server, in an SQL database, or even a Web Server different=


> outputs MAY happen.

> Sending systems MUST NOT depend on changes to their

> sequences not happening.

> =3D=3D=3D=3D

>

> (Consider, Little Bobby Tables https://www.xkcd.com/327/, printf
> escapes, Javascript/HTML, etc)

>

>

> --

> Taxes, n.:

>=C2=A0 =C2=A0 Of life's two certainties, the only one for which you=
 can get

>=C2=A0 =C2=A0 an extension.

>

> _______________________________________________

> Idr mailing list

> Idr@ietf.org

> https://www.ietf.org/mailman/listinfo/idr




_______________________=
________________________

GROW mailing list

GROW@ietf.org

https://www.ietf.org/mailman/listinfo/grow





--94eb2c075ab4c7d5350541a7d7a3--


From nobody Sat Nov 19 06:17:23 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2DE6129929 for ; Sat, 19 Nov 2016 06:17:21 -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, 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] 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 kVv9HgWNLOZV for ; Sat, 19 Nov 2016 06:17:19 -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 388201298D9 for ; Sat, 19 Nov 2016 06:17:19 -0800 (PST)
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=qrmz4wShXuOp85zcwaApb9GqMHTxDwafwb7aMzIEiZA=; b=lgdga8VWoMVmI5WU3fJx/3uvAeUmn3fK0uivx+GKDIm5rjmIO9XNw86sxAwmbgnmeUb+r4YIkDS9dIPPH9EaWkMyyIqZVhdX+i5fKlTsmqvVdtLu/zx55tiIel2OwJixzqwxmveGWKTzDVsIAeLEXSMcnaOac9hzg6TZge1AIGg=
Received: from AM4PR03MB1425.eurprd03.prod.outlook.com (10.164.77.155) by AM4PR03MB1425.eurprd03.prod.outlook.com (10.164.77.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.721.10; Sat, 19 Nov 2016 14:17:14 +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.0721.017; Sat, 19 Nov 2016 14:17:14 +0000
From: "Neil J. McRae" 
To: Job Snijders 
Thread-Topic: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
Thread-Index: AQHSQHKnYZ9W52LFnkCDl9fYNxHrBKDdXnUAgACK2gCAAIJYgIAAA84AgAABwACAALsAAIAA81YAgAAOpYCAABLmgIAAATGAgAAMzQCAAATbgIAAAMuAgAAEPgCAAAVjbg==
Date: Sat, 19 Nov 2016 14:17:14 +0000
Message-ID: <1AF0DE87-6F3B-4DD7-B23F-AC570E7A088E@domino.org>
References: <20161117013640.GB6217@pfrc.org> <16426_1479400131_582DDAC3_16426_1669_1_53C29892C857584299CBF5D05346208A1EC87201@OPEXCNORM2F.corporate.adroot.infra.ftgroup> <20161118004548.GK1072@dhcp-9341.meeting.ietf.org> <16418_1479457940_582EBC93_16418_290_1_53C29892C857584299CBF5D05346208A1EC8DEA5@OPEXCLILM21.corporate.adroot.infra.ftgroup>  <13357_1479459134_582EC13E_13357_5786_1_53C29892C857584299CBF5D05346208A1EC8FF18@OPEXCLILM21.corporate.adroot.infra.ftgroup> <37224750-4065-40E3-B6F4-571DED698563@cisco.com> <20161119103226.GN1072@dhcp-9341.meeting.ietf.org>  <20161119123229.GD4992@skriver.dk> <20161119123645.GB2472@puck.nether.net>   , 
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=neil@domino.org; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [188.29.165.86]
x-microsoft-exchange-diagnostics: 1; AM4PR03MB1425; 7:3siJyBaptoXAzAQYU7x0mphO7cCGxl42LzLKFvFy3Cl7Wb7kDOhQfQ8Gqt95CYFcNoz5AHyZy9WGetMk8MJxj8npfV5k6GQ57z0T+/gE4T2g6Jp0hQfH0bsKivckvHVqR0/V74adbGQzTxELFjMIY3W/pT8VhfjJoPnvHvc4wU/sUQzn7MudXYhnyxNCXq76IGXnnXxiV8iiruMeTIXHIifgBs+fx14wpeaFE5Glvjrqfv1WLjFQy4EEa99gA4xJpRbeS51FGGpMYlj7v0aYrOJxO6XEE5g0G8pxotCIMhcr622XgPIdUz0OTNfX88Zwc1BTY2KedewzEO/I4Wghs1jr5sZ7P1MaFZ582k3u1Ws=
x-ms-office365-filtering-correlation-id: d0e9842a-87f3-425e-e2ab-08d41086c2bf
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:AM4PR03MB1425;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040307)(6060326)(6045199)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(6061324)(2016111802025)(6043046); SRVR:AM4PR03MB1425; BCL:0; PCL:0; RULEID:; SRVR:AM4PR03MB1425; 
x-forefront-prvs: 0131D22242
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(189002)(24454002)(2950100002)(33656002)(76176999)(2906002)(3846002)(54356999)(102836003)(6116002)(3280700002)(81156014)(97736004)(81166006)(50986999)(3660700001)(4326007)(305945005)(122556002)(8936002)(101416001)(6916009)(5660300001)(189998001)(110136003)(230783001)(106356001)(6506003)(105586002)(106116001)(2900100001)(83716003)(86362001)(87936001)(7846002)(66066001)(92566002)(93886004)(36756003)(38730400001)(77096005)(7736002)(6512003)(8676002)(68736007)(82746002)(229853002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR03MB1425; H:AM4PR03MB1425.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  A:0; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: domino.org does not designate permitted sender hosts)
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: 19 Nov 2016 14:17:14.4409 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 398f3eb4-3394-48e7-885c-de1ab2a9cf2e
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR03MB1425
Archived-At: 
Cc: Robert Raszuk , idr wg 
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 19 Nov 2016 14:17:21 -0000

Free form is inefficient and will drive less useful outcomes.=20

This becomes bloat because immediately I add to my peering policy that we w=
ill ignore all of these messages because I can't trigger action on them -  =
any message from the network I want to be able to automate something from i=
t like an icon on a NOC display or other notification -perhaps that auto lo=
oks up the NOC phone number (although that's not likely these days!), searc=
h the recent emails from that AS; gets the peering DB record for that AS or=
 a message that says ignore this cease for quantum X -=20

Let's not even start about the language challenges this would present. Or t=
he sales droids 1-800-Cheap-transit ;)=20

Neil=20


> On 19 Nov 2016, at 13:58, Job Snijders  wrote:
>=20
> IETF's IDR doesn't need to micromanage the payload contents of free form =
string. Let operators figure it out. Maybe a standard develops, maybe not. =
Free form is free form.=20
>=20
> Job
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr


From nobody Sat Nov 19 06:27:16 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDA2412995C for ; Sat, 19 Nov 2016 06:27:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level: 
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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 oclOxwENZEMI for ; Sat, 19 Nov 2016 06:27:12 -0800 (PST)
Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15F9812995B for ; Sat, 19 Nov 2016 06:27:12 -0800 (PST)
Received: by mail-qk0-x22a.google.com with SMTP id n21so300315044qka.3 for ; Sat, 19 Nov 2016 06:27:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=IHabg6sFR72ixaDC8/h4OITkW0I9C0N8vzYql2JpZbw=; b=xw9AbEdFZwB/2ZcsCAsyD1QNguyekFlMruTnhu/0r1zqorFmADpwJmmNjY9MdhGC17 dLIRefEj2TT4NIRSsT4CTHAMCnOWx/Vj6hwf+vItA7Ssuk5G2unzk7tVxOlmqpuCuq2c gBrtzIZrHlAZfvajI1GwQUYhAZ5djPkvTBFhZ2NwaEtQD1dWODPJaNNObJSiGc0ZRAHz wuTvbQC5fhNeX5edtXr5y6bDqIgkfXB70U0/IhXDxko0c5H6osaVqWwznU5KxR/vFeq+ 41P4hEfquPwygbx3DHWBX5Av7Sh/pMUd1Zk9csYQazjllIsvJsKPTUBzlBCUZ4BmlJm+ EIqw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=IHabg6sFR72ixaDC8/h4OITkW0I9C0N8vzYql2JpZbw=; b=bufwupr6zu0vD5AkAEXWFYaz1IJMtXOQeYKVYGZF40uKCd06c+d0EVk02/SrfViZnD VnSQnIHJOVIF0Xr7c+QCzzAS81h8r2muOJ+J7OeP7xn0bz9MFe7wtzW6grcu5v2S6ZOe 2rV914WgLKjVnCKyGZEhmrqAopBdyfIaFVwpglhIWueSudO5W1OHccXpeKPS1HdlEjam m9Z21FaRX/wKTw5BgtgLrtd+WwtF538SIXbI3Wrilgs6bUfsdIuDhZoyZh91sGHXHTqx fYGeIpRneIQ/z79x7d/G+brq0I25UOi3alp+WC+KcREockaMmvpSIE24n5Fo7aJ6N7jW LL7g==
X-Gm-Message-State: AKaTC03FvUnTG/p386BgmGkTF6ByB9myKm5NtdVXjCCk4UxxuKwnCQWc+KTL/TR51HV4v2oJ6xyXzLMdlk6Kvg==
X-Received: by 10.55.174.135 with SMTP id x129mr6473903qke.133.1479565631068;  Sat, 19 Nov 2016 06:27:11 -0800 (PST)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.140.16.50 with HTTP; Sat, 19 Nov 2016 06:27:09 -0800 (PST)
In-Reply-To: <20161119103226.GN1072@dhcp-9341.meeting.ietf.org>
References: <20161116061556.GG1073@dhcp-9341.meeting.ietf.org> <20161117013640.GB6217@pfrc.org> <16426_1479400131_582DDAC3_16426_1669_1_53C29892C857584299CBF5D05346208A1EC87201@OPEXCNORM2F.corporate.adroot.infra.ftgroup> <20161118004548.GK1072@dhcp-9341.meeting.ietf.org> <16418_1479457940_582EBC93_16418_290_1_53C29892C857584299CBF5D05346208A1EC8DEA5@OPEXCLILM21.corporate.adroot.infra.ftgroup>  <13357_1479459134_582EC13E_13357_5786_1_53C29892C857584299CBF5D05346208A1EC8FF18@OPEXCLILM21.corporate.adroot.infra.ftgroup> <37224750-4065-40E3-B6F4-571DED698563@cisco.com> <20161119103226.GN1072@dhcp-9341.meeting.ietf.org>
From: Robert Raszuk 
Date: Sat, 19 Nov 2016 15:27:09 +0100
X-Google-Sender-Auth: Yf4gSZ81H9sJaFW2wJa3HCkpiPU
Message-ID: 
To: Job Snijders 
Content-Type: multipart/alternative; boundary=94eb2c070d62dcbe7a0541a8376b
Archived-At: 
Cc: idr wg 
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 19 Nov 2016 14:27:15 -0000

--94eb2c070d62dcbe7a0541a8376b
Content-Type: text/plain; charset=UTF-8

Job,

To recap ...

RFC4271 says:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Error code    | Error subcode |   Data (variable)             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


...


Note that the length of the Data field can be determined from
         the message Length field by the formula:

                  Message Length = 21 + Data Length


RFC4486 says:

   If a BGP speaker decides to administratively shut down its peering
   with a neighbor, then the speaker SHOULD send a NOTIFICATION message
   with the Error Code Cease and the Error Subcode "Administrative
   Shutdown".



That all means there is no guarantee that if you insert length some CPEs

will not crush even if the length value will be all 0.


That means that in my network where there is 15000 CEs if at least one

crashes I can not upgrade any longer any PE OS which may be needed for

other reasons.


That would be pretty bad effect of the proposed enhancement.


If we are to continue to use subcode 2 let's stay with current 4271 format

and not update 4271 RFC with this proposal.


Or let's define new cease subcode say "INFO" which will be injected only when

operator types in a string. That way existing deployments are safe and you can

enjoy new communication channel (hopefully with some well defined keywords :).


Cheers,

R.



On Sat, Nov 19, 2016 at 11:32 AM, Job Snijders  wrote:

> Hi Jakob, Working group,
>
> It is for "defensive" purposes: what if utf8 turns out to be terrible,
> then cease subcode 2 can still be used but we can put something else in
> the datafield trailing the subcode.
>
> the advantage of using a length field is that we avoid discussing types
> and semantics, but future protocol developers have an option to use the
> trailing data in the NOTIFICATION message for some purpose.
>
> It would look like this:
>
> -----
>
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    | Error code 6  |   Subcode 2   |    Length     |     ...       |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                   ... Shutdown Communication ...              |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                              ...                              |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>    Length:
>         The Length value can range from 0 to 128 and indicates how many
>         bytes of UTF-8 for the Shutdown Communication follow. If the
>         length field is set to 0, no UTF-8 bytes follow.
>
> -----
>
> This is an very lightweight approach to leave the door somewhat open ,
> should the need to do something else with the trailing data arise, and
> it only costs 1 byte.
>
> Kind regards,
>
> Job
>
>
> On Fri, Nov 18, 2016 at 08:01:30PM +0000, Jakob Heitz (jheitz) wrote:
> > Not necessary. You can already send whatever you want. In iOS-XR, it
> > just hexdumps it all. The only thing that will change is that it will
> > print it in UTF8 as well. It will still hexdump. If you want no
> > hexdump, then we need a new subcode.
> >
> > Thanks,
> > Jakob.
> >
> > On Nov 18, 2016, at 12:52 AM,
> > > wrote:
> >
> > Thanks.
> > --Bruno
> >
> > From: Job Snijders [mailto:job@instituut.net]
> > Sent: Friday, November 18, 2016 9:46 AM
> > To: DECRAENE Bruno IMT/OLN
> > Cc: Jeffrey Haas; Job Snijders; grow@ietf.org;
> idr@ietf.org
> > Subject: Re: [GROW] [Idr] draft-snijders-idr-shutdown-00: Drop a line
> in the peer's syslog at shutdown
> >
> > Hi Bruno,
> >
> > John Scudder was kind enough to provide extensive argumentation
> > offlist on why something along these lines should be done. We'll work
> > on a proposal. The length indicator is a neat idea, thanks for
> > sharing.
> >
> > Job
> >
> > On Fri, 18 Nov 2016 at 17:32,  bruno.decraene@orange.com>> wrote:
> >
> >
> > > From: Job Snijders [mailto:job@instituut.net]
> > Sent: Friday, November 18, 2016 1:46 AM
> > >
> >  > On Thu, Nov 17, 2016 at 04:28:50PM +0000, bruno.decraene@orange.com<
> mailto:bruno.decraene@orange.com> wrote:
> >  > > I support the draft.
> >  > > I also support Jeff's idea to re-use existing sub-code(s).
> >  >
> >  > Thanks for your support. Based on the feedback received so far the
> next
> >  > version of this draft will recycle Cease subcode 2.
> >  >
> >  > > 1 possible comment: the length of the "Shutdown Communication" field
> >  > > seems implied from the length of the data field, rather than being
> >  > > explicitly indicated.
> >  >
> >  > The text is explicit about the length:
> >  >
> >  >     "followed by a freeform UTF-8 encoded string with a REQUIRED
> maximum
> >  >     length of 128 octets. "
> >  >
> >  > and further:
> >  >
> >  >     "This document tries to minimize the effects of visual spoofing by
> >  >     allowing UNICODE only where local script is expected and needed,
> and
> >  >     by limiting the length of the Shutdown Communication."
> >  >
> >  > > If so, it seems that we are closing the possibility to advertise
> >  > > additional data/usage, in some future. What about adding a TLV
> format?
> >  >
> >  > I object to using a TLV. Don't forget this is already at a TLV level:
> >  > Cease NOTIFICATION. If one would want to define a TLV inside this
> TLV, a
> >  > new Cease subcode can be requested from IANA.
> >
> > What if someone needs to advertise additional info to an existing
> > cease subcode? cf Jeff's email regarding the pain of changing
> > subcodes.  So let's forget about the TLV. What about just adding the
> > length of the string? This would still allow adding fields after the
> > string, while having a negligible/null cost?
> >
> > Kind regards,
> > -- Bruno
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>

--94eb2c070d62dcbe7a0541a8376b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Job,

=

To recap ...=C2=A0

RFC4271 says:

      0                   1     =
              2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Error code    | Error subcode |   Data (variable)             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

...

Note that the length of the Data field ca=
n be determined from
         the message Length field by the formula:

                  Message Length =3D 21 + Data Length

RFC4486 says:

   =
If a BGP speaker decides to administratively shut down its peering
   with a neighbor, then the speaker SHOULD send a NOTIFICATION message
   with the Error Code Cease and the Error Subcode "Administrative
   Shutdown".


That=
 all means there is no=C2=A0guarantee that if you insert length some CPEs
will not crush even if the length=
 value will be all 0. 

That means that in my network where there is=
 15000 CEs if at least one 
crashes =
I can not upgrade any longer any PE OS which may be needed for 
other reasons. 

That would be pretty ba=
d effect of the proposed enhancement.  

If we are to continue to us=
e subcode 2 let's stay with current 4271 format 
and not update 4271 RFC with this proposal. 

Or le=
t's define new cease subcode say "INFO" which will be injecte=
d only when 
operator types in a str=
ing. That way existing deployments are safe and you can
enjoy new communication channel (hopefully with some we=
ll defined keywords :). 

<=
pre class=3D"gmail-newpage" style=3D"font-size:13.3333px;margin-top:0px;mar=
gin-bottom:0px;color:rgb(0,0,0)">Cheers,
R.


On Sat, Nov 19, 2016 at 11:=
32 AM, Job Snijders <job@instituut.net> wrote:
Hi Jakob, Working group,



It is for "defensive" purposes: what if utf8 turns out to be terr=
ible,

then cease subcode 2 can still be used but we can put something else in

the datafield trailing the subcode.



the advantage of using a length field is that we avoid discussing types

and semantics, but future protocol developers have an option to use the

trailing data in the NOTIFICATION message for some purpose.



It would look like this:



-----



=C2=A0 =C2=A0 0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A01=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A02=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A03

=C2=A0 =C2=A0 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0=
 1

=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+

=C2=A0 =C2=A0| Error code 6=C2=A0 |=C2=A0 =C2=A0Subcode 2=C2=A0 =C2=A0|=C2=
=A0 =C2=A0 Length=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0...=C2=A0 =C2=A0 =
=C2=A0 =C2=A0|

=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+

=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0... Shutdown Communication ...=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 |

=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+

=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 |

=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+



=C2=A0 =C2=A0Length:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 The Length value can range from 0 to 128 and in=
dicates how many

=C2=A0 =C2=A0 =C2=A0 =C2=A0 bytes of UTF-8 for the Shutdown Communication f=
ollow. If the

=C2=A0 =C2=A0 =C2=A0 =C2=A0 length field is set to 0, no UTF-8 bytes follow=
.



-----



This is an very lightweight approach to leave the door somewhat open ,

should the need to do something else with the trailing data arise, and

it only costs 1 byte.



Kind regards,



Job





On Fri, Nov 18, 2016 at 08:01:30PM +0000, Jakob Heitz (jheitz) wrote:

> Not necessary. You can already send whatever you want. In iOS-XR, it
> just hexdumps it all. The only thing that will change is that it will<=
br>
> print it in UTF8 as well. It will still hexdump. If you want no

> hexdump, then we need a new subcode.

>

> Thanks,

> Jakob.

>

> On Nov 18, 2016, at 12:52 AM,

> <bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>> wrote:

>

> Thanks.

> --Bruno

>

> From: Job Snijders [mailto:job@in=
stituut.net]

> Sent: Friday, November 18, 2016 9:46 AM

> To: DECRAENE Bruno IMT/OLN

> Cc: Jeffrey Haas; Job Snijders; grow@ietf.org<mailto:grow@ie=
tf.org>; idr@ietf.org<mailto:=
idr@ietf.org>

> Subject: Re: [GROW] [Idr] draft-snijders-idr-shutdown=
-00: Drop a line in the peer's syslog at shutdown

>

> Hi Bruno,

>

> John Scudder was kind enough to provide extensive argumentation

> offlist on why something along these lines should be done. We'll w=
ork

> on a proposal. The length indicator is a neat idea, thanks for

> sharing.

>

> Job

>

> On Fri, 18 Nov 2016 at 17:32, <bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>> w=
rote:

>

>

> > From: Job Snijders [mailto:j=
ob@instituut.net<mailto:jo=
b@instituut.net>]=C2=A0 > Sent: Friday, November 18, 2016 1:46 AM=



> >

>=C2=A0 > On Thu, Nov 17, 2016 at 04:28:50PM +0000, bruno.decraene@orange.com<mailto:bruno.decraene@orange.com> wrote:

>=C2=A0 > > I support the draft.

>=C2=A0 > > I also support Jeff's idea to re-use existing sub-=
code(s).

>=C2=A0 >

>=C2=A0 > Thanks for your support. Based on the feedback received so =
far the next

>=C2=A0 > version of this draft will recycle Cease subcode 2.

>=C2=A0 >

>=C2=A0 > > 1 possible comment: the length of the "Shutdown C=
ommunication" field

>=C2=A0 > > seems implied from the length of the data field, rathe=
r than being

>=C2=A0 > > explicitly indicated.

>=C2=A0 >

>=C2=A0 > The text is explicit about the length:

>=C2=A0 >

>=C2=A0 >=C2=A0 =C2=A0 =C2=A0"followed by a freeform UTF-8 encod=
ed string with a REQUIRED maximum

>=C2=A0 >=C2=A0 =C2=A0 =C2=A0length of 128 octets. "

>=C2=A0 >

>=C2=A0 > and further:

>=C2=A0 >

>=C2=A0 >=C2=A0 =C2=A0 =C2=A0"This document tries to minimize th=
e effects of visual spoofing by

>=C2=A0 >=C2=A0 =C2=A0 =C2=A0allowing UNICODE only where local script=
 is expected and needed, and

>=C2=A0 >=C2=A0 =C2=A0 =C2=A0by limiting the length of the Shutdown C=
ommunication."

>=C2=A0 >

>=C2=A0 > > If so, it seems that we are closing the possibility to=
 advertise

>=C2=A0 > > additional data/usage, in some future. What about addi=
ng a TLV format?

>=C2=A0 >

>=C2=A0 > I object to using a TLV. Don't forget this is already a=
t a TLV level:

>=C2=A0 > Cease NOTIFICATION. If one would want to define a TLV insid=
e this TLV, a

>=C2=A0 > new Cease subcode can be requested from IANA.

>

> What if someone needs to advertise additional info to an existing

> cease subcode? cf Jeff's email regarding the pain of changing

> subcodes.=C2=A0 So let's forget about the TLV. What about just add=
ing the

> length of the string? This would still allow adding fields after the
> string, while having a negligible/null cost?

>

> Kind regards,

> -- Bruno




_______________________=
________________________

Idr mailing list

Idr@ietf.org

https://www.ietf.org/mailman/listinfo/idr





--94eb2c070d62dcbe7a0541a8376b--


From nobody Sat Nov 19 06:28:00 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97BE7129952 for ; Sat, 19 Nov 2016 06:27:57 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lamehost-it.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 xB_XOkSJ6SBB for ; Sat, 19 Nov 2016 06:27:55 -0800 (PST)
Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c: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 EECCD129968 for ; Sat, 19 Nov 2016 06:27:53 -0800 (PST)
Received: by mail-wm0-x234.google.com with SMTP id f82so78121854wmf.1 for ; Sat, 19 Nov 2016 06:27:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lamehost-it.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MTCdeCFY+c19KJL4COrbbFyvq1eUPFqMcSPxFgQV03k=; b=xGcYl6Zs9QdxJ+W6JnaPukUthf0o0aAIY1AZFpNGzN9CaFA/hPA4ELNDr0SFFHsdO6 ynQ+Xk7jtrPh8txeCZ2aCRVG739Tyo456E/PYA/QL168jeLrQok0uCIhRlx9Ku3HN30I RwUknFZG/bIyTofYN2F0T3s1rSbFXhnoiWw54H9/XbNFvVzXn1SmuMHs71vMPiIMTrAM /cwZnt90KNgMxIHL3aZZj6XBNulOldx3fVSqze6UtC1V5nGnC+bJ4BV2zShJa7PCMMv0 70o7ktyQ260upZ7zreyZOCgyWSx2CSzMinE4lTzORnQFbo4Bf++A9+lmI92MO/h5w4At cqcA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MTCdeCFY+c19KJL4COrbbFyvq1eUPFqMcSPxFgQV03k=; b=j5PfDklgpOdbbo5IOtEGjy80a/tx6RDxL3ueomWmyl4sZtLPJvzHybh3VzdMrRvpXy GQLHG4eLGUDqovvbe+QugP9npmY4fmpiKGI0N2rbMloYaJa4HoYIyHaf0op/52/8waDa xrB3O5gCuooEa5iSj3e92xlOdD8QlTqwa07LxfMgbUQ3ONox9Y9e/hjVZhfsQbF5MJtU NIHgjsmE/wiP80wLd7wHVVUiUu7MA6z9X4GkpEEfqS/wnseo4uQvhBMkcnZfRUap0po0 5IFmoId3UZdc9SPdXcv5GoeazNkyoBgBPYq56Ca3TUz0CMdX6/KlaoP4VM1iuOAX0cdg aEjA==
X-Gm-Message-State: AKaTC01bOe9nVxLEo7YvMSwnLRjJAh1t3ytEya1nHq2OQkoCzHfJNhisOT12xKLH0ApzNSX6n7ecPslaQCo8tw==
X-Received: by 10.46.76.1 with SMTP id z1mr2666439lja.41.1479565672349; Sat, 19 Nov 2016 06:27:52 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.202.14 with HTTP; Sat, 19 Nov 2016 06:27:51 -0800 (PST)
X-Originating-IP: [79.24.77.5]
In-Reply-To: 
References: <20161116061556.GG1073@dhcp-9341.meeting.ietf.org> <20161116105535.GW79185@Space.Net> <1479295774707.77855@dacor.de> <20161116113849.udbrfvdhaj3be7nx@bongo.bofh.it> <20161116130110.GK1073@dhcp-9341.meeting.ietf.org> <20161116134707.GP24817@gir.theapt.org>   
From: Marco Marzetti 
Date: Sat, 19 Nov 2016 15:27:51 +0100
Message-ID: 
To: Robert Raszuk 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "idr@ietf.org" , "grow@ietf.org" , Peter Hessler 
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 19 Nov 2016 14:27:57 -0000

Robert,

Just to be clear: i am supporting free text as i don't think that we
should enforce any kind of formatting for any reason.

Regards

On Sat, Nov 19, 2016 at 3:07 PM, Robert Raszuk  wrote:
> Marco,
>
> Yes indeed. As said it would be completely optional.
>
> Job,
>
> Free form is so old fashioned that it really does not even sound reasonable.
> Why do you want everything to be "figured out" outside of IDR ? Why for
> everything we recently propose there must be 5 documents to read all in
> different forums/groups to use it ? Do you prefer to hard encode TLVs to
> make the proposal parsable ?
>
> Please remember you are extending BGP as the protocol used by many who do
> not even know what IDR or GROW is. Not everyone who uses BGP has time for
> IETF or NANOG or RIPE.
>
> Cheers,
> R.
>
>
>
> On Sat, Nov 19, 2016 at 2:56 PM, Marco Marzetti  wrote:
>>
>> Robert,
>>
>> So you're suggesting to include recommendation for the formatting?
>> That could help (as long as it's not mandatory).
>>
>> Regards
>>
>>
>> On Sat, Nov 19, 2016 at 2:51 PM, Neil J. McRae  wrote:
>> > I personally think this is a really bad idea but understand why some
>> > might want this - and we've had similar drafts in the past- in my view  we
>> > shouldn't be moving more towards more human related randomness in system
>> > level messages - have a set of status numbers or something that can be
>> > predictable but randomly "we took the peer down whilst we went to
>> > McDonald's" as opposed to CEASE reason 666 - we depeered or reason 999 we
>> > have a problem call us would be a much better approach. We can't keep
>> > running networks like we did 20 years ago!
>> >
>> > Thanks
>> > Neil
>> > Sent from my iPhone
>> >
>> >> On 16 Nov 2016, at 13:47, Peter Hessler  wrote:
>> >>
>> >> On 2016 Nov 16 (Wed) at 22:01:10 +0900 (+0900), Job Snijders wrote:
>> >> :I hope to capture in the draft that an implementation can choose which
>> >> :characters of the Shutdown Communication they represent in the syslog
>> >> or
>> >> :'show bgp neighbor xxx' output. For instance, I'd recommend to squash
>> >> :all newline/newpage/newfeed/newparagraph style chars and make sure
>> >> that
>> >> :the Communication is represented on a single line. I don't have the
>> >> :proper words for the draft to express that (yet).
>> >>
>> >> I've been thinking about wording for protecting the receiving system
>> >> from possible bad input.  I'm not worried about (valid) UTF-8 display
>> >> chars, nor about whitespace things.  I am worried about Little Bobby
>> >> Tables, though.
>> >>
>> >> We also have to consider that this will be displayed possibly in a Unix
>> >> Shell, Windows Shell, Syslog, SQL server, Web Server; and different
>> >> chars have different meanings there.
>> >>
>> >> I'm not quite happy with the wording, but I would like something along
>> >> these lines added.  Possibly in the Security section, or at the end of
>> >> Section #2.
>> >>
>> >> ====
>> >> Receiving systems SHOULD filter the message for the intended output
>> >> environment and MAY change octets or sequences of octets for their
>> >> local environment.
>> >> As the message may be displayed on a command line, stored
>> >> in a syslog server, in an SQL database, or even a Web Server different
>> >> outputs MAY happen.
>> >> Sending systems MUST NOT depend on changes to their
>> >> sequences not happening.
>> >> ====
>> >>
>> >> (Consider, Little Bobby Tables https://www.xkcd.com/327/, printf
>> >> escapes, Javascript/HTML, etc)
>> >>
>> >>
>> >> --
>> >> Taxes, n.:
>> >>    Of life's two certainties, the only one for which you can get
>> >>    an extension.
>> >>
>> >> _______________________________________________
>> >> Idr mailing list
>> >> Idr@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/idr
>> >
>> > _______________________________________________
>> > GROW mailing list
>> > GROW@ietf.org
>> > https://www.ietf.org/mailman/listinfo/grow
>>
>>
>>
>> --
>> Marco
>>
>> _______________________________________________
>> GROW mailing list
>> GROW@ietf.org
>> https://www.ietf.org/mailman/listinfo/grow
>
>



-- 
Marco


From nobody Sat Nov 19 06:30:43 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9050129963; Sat, 19 Nov 2016 06:30:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level: 
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=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=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 u1uIhSzfG4bo; Sat, 19 Nov 2016 06:30:35 -0800 (PST)
Received: from mail-qk0-x243.google.com (mail-qk0-x243.google.com [IPv6:2607:f8b0:400d:c09::243]) (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 A666B12996D; Sat, 19 Nov 2016 06:30:35 -0800 (PST)
Received: by mail-qk0-x243.google.com with SMTP id y205so4840104qkb.1; Sat, 19 Nov 2016 06:30:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=lS5h5bGXNAckDmsOYN4D9GHPli65Zkyuutz04UejQt4=; b=Ncy8WPhDtYOR9Xvc/PfWGsXxbobB1kZU6CoW8AYTvUDd+A0QDwU4ET0y/PBY6UM1NR pwFdGGN1U0ibGWsBuWdq1/SDIeL6y/DiUgshf2m3QZSpj7T3eesrZi4pEBT92pelb3LJ 1bOWnhtSc+FyXaNhMu39AjkQg4lHR35HuPiw8rWK6A6/I6h+mHuedGc6oKhIKYHto6hB 2j9ApZqIU/D/xtMD02pSVyEVEuUTbSaA8XkFTKJIRlyznrki8npF+qBDHNwnbxZlkD/g 0HJmwNE1M82Jag+9Dcv5y/Tq8EDVYa7KglLJgG6DP6py8+dsmgNBs4sucDmCdcQP8jjt skqw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=lS5h5bGXNAckDmsOYN4D9GHPli65Zkyuutz04UejQt4=; b=f6zy4u8puL7rWTQGtZEp3irXyuDJIGkpuYpkvaC6Dkmtey1Ad1t48AanM2Fo+zpHKI Mv38eXs8DR0Lv//QGHWH/PCf/oKKkds1kkPff3z8RpM06885Y/JYgYhA2njrfyMYbvJ7 cgyLn748BMSN8OpbM6sQkndqy1e+zUpM1evM5DnLc3Mzkxv95KP2vpgQUNsvCpep74wd a2dvRi5GBRdFiZpjVNG7VFXzUViNdQEP9lshYgpd+x6vIPGsP1znoQlyK9JwLwT2BGv8 M4Yyf+w2vTyKizQx+YBTRWHxqkfV08KjCz2tY9TZ64aEMrh+ub8xgU43Wn2PbNpmkRrR X4pw==
X-Gm-Message-State: AKaTC00U1Cp+JSyoEoA2T96ImMYLUDLoP4MySeioD99DH+DBtqOQhVttmAFDNwIb/TI2MNn9Z1QtmolyuO3kqg==
X-Received: by 10.55.4.19 with SMTP id 19mr5842288qke.18.1479565834770; Sat, 19 Nov 2016 06:30:34 -0800 (PST)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.140.16.50 with HTTP; Sat, 19 Nov 2016 06:30:33 -0800 (PST)
In-Reply-To: 
References: <20161116061556.GG1073@dhcp-9341.meeting.ietf.org> <20161116105535.GW79185@Space.Net> <1479295774707.77855@dacor.de> <20161116113849.udbrfvdhaj3be7nx@bongo.bofh.it> <20161116130110.GK1073@dhcp-9341.meeting.ietf.org> <20161116134707.GP24817@gir.theapt.org>    
From: Robert Raszuk 
Date: Sat, 19 Nov 2016 15:30:33 +0100
X-Google-Sender-Auth: ee8QmR7YHFfIxE2OVE7E6ds7m1k
Message-ID: 
To: Marco Marzetti 
Content-Type: multipart/alternative; boundary=001a114c847400e2c20541a844eb
Archived-At: 
Cc: "idr@ietf.org" , "grow@ietf.org" , Peter Hessler 
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 19 Nov 2016 14:30:38 -0000

--001a114c847400e2c20541a844eb
Content-Type: text/plain; charset=UTF-8

Marco,

Just to be clear: I am also OK with free form text with the few well known
and easy to machine parse keywords (in it). Of course provided that we
either forget about new length field in subcode 2 which would update 4271
or we do it in new subcode all together.

Thx,
R.

On Sat, Nov 19, 2016 at 3:27 PM, Marco Marzetti  wrote:

> Robert,
>
> Just to be clear: i am supporting free text as i don't think that we
> should enforce any kind of formatting for any reason.
>
> Regards
>
> On Sat, Nov 19, 2016 at 3:07 PM, Robert Raszuk  wrote:
> > Marco,
> >
> > Yes indeed. As said it would be completely optional.
> >
> > Job,
> >
> > Free form is so old fashioned that it really does not even sound
> reasonable.
> > Why do you want everything to be "figured out" outside of IDR ? Why for
> > everything we recently propose there must be 5 documents to read all in
> > different forums/groups to use it ? Do you prefer to hard encode TLVs to
> > make the proposal parsable ?
> >
> > Please remember you are extending BGP as the protocol used by many who do
> > not even know what IDR or GROW is. Not everyone who uses BGP has time for
> > IETF or NANOG or RIPE.
> >
> > Cheers,
> > R.
> >
> >
> >
> > On Sat, Nov 19, 2016 at 2:56 PM, Marco Marzetti 
> wrote:
> >>
> >> Robert,
> >>
> >> So you're suggesting to include recommendation for the formatting?
> >> That could help (as long as it's not mandatory).
> >>
> >> Regards
> >>
> >>
> >> On Sat, Nov 19, 2016 at 2:51 PM, Neil J. McRae  wrote:
> >> > I personally think this is a really bad idea but understand why some
> >> > might want this - and we've had similar drafts in the past- in my
> view  we
> >> > shouldn't be moving more towards more human related randomness in
> system
> >> > level messages - have a set of status numbers or something that can be
> >> > predictable but randomly "we took the peer down whilst we went to
> >> > McDonald's" as opposed to CEASE reason 666 - we depeered or reason
> 999 we
> >> > have a problem call us would be a much better approach. We can't keep
> >> > running networks like we did 20 years ago!
> >> >
> >> > Thanks
> >> > Neil
> >> > Sent from my iPhone
> >> >
> >> >> On 16 Nov 2016, at 13:47, Peter Hessler  wrote:
> >> >>
> >> >> On 2016 Nov 16 (Wed) at 22:01:10 +0900 (+0900), Job Snijders wrote:
> >> >> :I hope to capture in the draft that an implementation can choose
> which
> >> >> :characters of the Shutdown Communication they represent in the
> syslog
> >> >> or
> >> >> :'show bgp neighbor xxx' output. For instance, I'd recommend to
> squash
> >> >> :all newline/newpage/newfeed/newparagraph style chars and make sure
> >> >> that
> >> >> :the Communication is represented on a single line. I don't have the
> >> >> :proper words for the draft to express that (yet).
> >> >>
> >> >> I've been thinking about wording for protecting the receiving system
> >> >> from possible bad input.  I'm not worried about (valid) UTF-8 display
> >> >> chars, nor about whitespace things.  I am worried about Little Bobby
> >> >> Tables, though.
> >> >>
> >> >> We also have to consider that this will be displayed possibly in a
> Unix
> >> >> Shell, Windows Shell, Syslog, SQL server, Web Server; and different
> >> >> chars have different meanings there.
> >> >>
> >> >> I'm not quite happy with the wording, but I would like something
> along
> >> >> these lines added.  Possibly in the Security section, or at the end
> of
> >> >> Section #2.
> >> >>
> >> >> ====
> >> >> Receiving systems SHOULD filter the message for the intended output
> >> >> environment and MAY change octets or sequences of octets for their
> >> >> local environment.
> >> >> As the message may be displayed on a command line, stored
> >> >> in a syslog server, in an SQL database, or even a Web Server
> different
> >> >> outputs MAY happen.
> >> >> Sending systems MUST NOT depend on changes to their
> >> >> sequences not happening.
> >> >> ====
> >> >>
> >> >> (Consider, Little Bobby Tables https://www.xkcd.com/327/, printf
> >> >> escapes, Javascript/HTML, etc)
> >> >>
> >> >>
> >> >> --
> >> >> Taxes, n.:
> >> >>    Of life's two certainties, the only one for which you can get
> >> >>    an extension.
> >> >>
> >> >> _______________________________________________
> >> >> Idr mailing list
> >> >> Idr@ietf.org
> >> >> https://www.ietf.org/mailman/listinfo/idr
> >> >
> >> > _______________________________________________
> >> > GROW mailing list
> >> > GROW@ietf.org
> >> > https://www.ietf.org/mailman/listinfo/grow
> >>
> >>
> >>
> >> --
> >> Marco
> >>
> >> _______________________________________________
> >> GROW mailing list
> >> GROW@ietf.org
> >> https://www.ietf.org/mailman/listinfo/grow
> >
> >
>
>
>
> --
> Marco
>

--001a114c847400e2c20541a844eb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Marco,

Just to be clear: I am also OK with free form text wit=
h the few well known and easy to machine parse keywords (in it). Of course =
provided that we either forget about new length field in subcode 2 which wo=
uld update 4271 or we do it in new subcode all together.=C2=A0

Thx,
R.

On Sat, =
Nov 19, 2016 at 3:27 PM, Marco Marzetti <marco@lamehost.it> =
wrote:
Robert,



Just to be clear: i am supporting free text as i don't think that we
should enforce any kind of formatting for any reason.



Regards




On Sat, Nov 19, 2016 at 3:07 PM, Robert Raszuk <robert@raszuk.net> wrote:

> Marco,

>

> Yes indeed. As said it would be completely optional.

>

> Job,

>

> Free form is so old fashioned that it really does not even sound reaso=
nable.

> Why do you want everything to be "figured out" outside of ID=
R ? Why for

> everything we recently propose there must be 5 documents to read all i=
n

> different forums/groups to use it ? Do you prefer to hard encode TLVs =
to

> make the proposal parsable ?

>

> Please remember you are extending BGP as the protocol used by many who=
 do

> not even know what IDR or GROW is. Not everyone who uses BGP has time =
for

> IETF or NANOG or RIPE.

>

> Cheers,

> R.

>

>

>

> On Sat, Nov 19, 2016 at 2:56 PM, Marco Marzetti <marco@lamehost.it> wrote:

>>

>> Robert,

>>

>> So you're suggesting to include recommendation for the formatt=
ing?

>> That could help (as long as it's not mandatory).

>>

>> Regards

>>

>>

>> On Sat, Nov 19, 2016 at 2:51 PM, Neil J. McRae <neil@domino.org> wrote:

>> > I personally think this is a really bad idea but understand w=
hy some

>> > might want this - and we've had similar drafts in the pas=
t- in my view=C2=A0 we

>> > shouldn't be moving more towards more human related rando=
mness in system

>> > level messages - have a set of status numbers or something th=
at can be

>> > predictable but randomly "we took the peer down whilst w=
e went to

>> > McDonald's" as opposed to CEASE reason 666 - we depe=
ered or reason 999 we

>> > have a problem call us would be a much better approach. We ca=
n't keep

>> > running networks like we did 20 years ago!

>> >

>> > Thanks

>> > Neil

>> > Sent from my iPhone

>> >

>> >> On 16 Nov 2016, at 13:47, Peter Hessler <phessler@theapt.org> wrote:

>> >>

>> >> On 2016 Nov 16 (Wed) at 22:01:10 +0900 (+0900), Job Snijd=
ers wrote:

>> >> :I hope to capture in the draft that an implementation ca=
n choose which

>> >> :characters of the Shutdown Communication they represent =
in the syslog

>> >> or

>> >> :'show bgp neighbor xxx' output. For instance, I&=
#39;d recommend to squash

>> >> :all newline/newpage/newfeed/newparagraph style char=
s and make sure

>> >> that

>> >> :the Communication is represented on a single line. I don=
't have the

>> >> :proper words for the draft to express that (yet).

>> >>

>> >> I've been thinking about wording for protecting the r=
eceiving system

>> >> from possible bad input.=C2=A0 I'm not worried about =
(valid) UTF-8 display

>> >> chars, nor about whitespace things.=C2=A0 I am worried ab=
out Little Bobby

>> >> Tables, though.

>> >>

>> >> We also have to consider that this will be displayed poss=
ibly in a Unix

>> >> Shell, Windows Shell, Syslog, SQL server, Web Server; and=
 different

>> >> chars have different meanings there.

>> >>

>> >> I'm not quite happy with the wording, but I would lik=
e something along

>> >> these lines added.=C2=A0 Possibly in the Security section=
, or at the end of

>> >> Section #2.

>> >>

>> >> =3D=3D=3D=3D

>> >> Receiving systems SHOULD filter the message for the inten=
ded output

>> >> environment and MAY change octets or sequences of octets =
for their

>> >> local environment.

>> >> As the message may be displayed on a command line, stored=


>> >> in a syslog server, in an SQL database, or even a Web Ser=
ver different

>> >> outputs MAY happen.

>> >> Sending systems MUST NOT depend on changes to their

>> >> sequences not happening.

>> >> =3D=3D=3D=3D

>> >>

>> >> (Consider, Little Bobby Tables https://www.xkcd.com/327/<=
/a>, printf

>> >> escapes, Javascript/HTML, etc)

>> >>

>> >>

>> >> --

>> >> Taxes, n.:

>> >>=C2=A0 =C2=A0 Of life's two certainties, the only one =
for which you can get

>> >>=C2=A0 =C2=A0 an extension.

>> >>

>> >> _______________________________________________

>> >> Idr mailing list

>> >> Idr@ietf.org

>> >> https://www.ietf.org/mailman/listinf=
o/idr

>> >

>> > _______________________________________________

>> > GROW mailing list

>> > GROW@ietf.org

>> > https://www.ietf.org/mailman/listinfo/g=
row

>>

>>

>>

>> --

>> Marco

>>

>> _______________________________________________

>> GROW mailing list

>> GROW@ietf.org

>> https://www.ietf.org/mailman/listinfo/grow

>

>








--

Marco





--001a114c847400e2c20541a844eb--


From nobody Sat Nov 19 06:44:20 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11B651293DC for ; Sat, 19 Nov 2016 06:44:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.432
X-Spam-Level: 
X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_SOFTFAIL=0.665] 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 Y8Ta2VjnYl8R for ; Sat, 19 Nov 2016 06:44:18 -0800 (PST)
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 086EB1288B8 for ; Sat, 19 Nov 2016 06:44:18 -0800 (PST)
Received: by mail3.mlpsca01.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1c86sI-0004YG-Gf (job@us.ntt.net); Sat, 19 Nov 2016 14:44:15 +0000
Date: Sat, 19 Nov 2016 15:44:08 +0100
From: Job Snijders 
To: "Neil J. McRae" 
Message-ID: <20161119144408.GC47336@dhcp-9d92.meeting.ietf.org>
References: <37224750-4065-40E3-B6F4-571DED698563@cisco.com> <20161119103226.GN1072@dhcp-9341.meeting.ietf.org>  <20161119123229.GD4992@skriver.dk> <20161119123645.GB2472@puck.nether.net>     <1AF0DE87-6F3B-4DD7-B23F-AC570E7A088E@domino.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1AF0DE87-6F3B-4DD7-B23F-AC570E7A088E@domino.org>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.7.1 (2016-10-04)
Archived-At: 
Cc: idr wg , Robert Raszuk 
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 19 Nov 2016 14:44:19 -0000

Hi Neil,

On Sat, Nov 19, 2016 at 02:17:14PM +0000, Neil J. McRae wrote:
> Free form is inefficient and will drive less useful outcomes. 
> 
> This becomes bloat because immediately I add to my peering policy that
> we will ignore all of these messages because I can't trigger action on
> them -  any message from the network I want to be able to automate
> something from it like an icon on a NOC display or other notification
> -perhaps that auto looks up the NOC phone number (although that's not
> likely these days!), search the recent emails from that AS; gets the
> peering DB record for that AS or a message that says ignore this cease
> for quantum X - 
> 
> Let's not even start about the language challenges this would present.
> Or the sales droids 1-800-Cheap-transit ;) 

You are free to ignore the free form Shutdown Communication, it is your
network. Your choice does not mean that the shutdown communication tool
should not exist for others who do want to use it.

Different networks are at different levels of automation, some might get
there and require more advanced tools, some don't. I dont think the
language challenges are real, with each of your BGP neighbors you'll
already have an agreement what the preferred language for communication
is. If you receive spam in the 128 octets of the Shutdown Communication,
you can consider shutting down the session on your side too.

Job


From nobody Sat Nov 19 06:48:09 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA0C129628; Sat, 19 Nov 2016 06:48:08 -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 GFzZiWbxWMMh; Sat, 19 Nov 2016 06:48:06 -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 0A5231288B8; Sat, 19 Nov 2016 06:48:05 -0800 (PST)
X-Envelope-To: grow@ietf.org
Received: from crumpet.foobar.org (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 uAJEm1ax038780 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 19 Nov 2016 14:48:01 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.foobar.org
Message-ID: <58306620.4000308@foobar.org>
Date: Sat, 19 Nov 2016 14:48:00 +0000
From: Nick Hilliard 
User-Agent: Postbox 5.0.7 (Macintosh/20161117)
MIME-Version: 1.0
To: Robert Raszuk 
References: <20161116061556.GG1073@dhcp-9341.meeting.ietf.org> <20161116105535.GW79185@Space.Net> <1479295774707.77855@dacor.de> <20161116113849.udbrfvdhaj3be7nx@bongo.bofh.it> <20161116130110.GK1073@dhcp-9341.meeting.ietf.org> <20161116134707.GP24817@gir.theapt.org>     
In-Reply-To: 
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: "grow@ietf.org" , Peter Hessler , "idr@ietf.org" 
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 19 Nov 2016 14:48:08 -0000

Robert Raszuk wrote:
> Just to be clear: I am also OK with free form text with the few well
> known and easy to machine parse keywords (in it).

the field should either be fully structured or free-form, and the
explicit intent of this draft is free form, utf8.  Having a half-way
house is in nobody's interest because the discussion will then rat-hole
on defining a new ad-hoc quasi-language, and the draft - if it ever gets
turned into running code - will end up being a protocol soup which
no-one will find satisying.

If you feel it should be fully structured, then please feel free to
submit an alternative draft to that effect.

Nick


From nobody Sat Nov 19 06:57:11 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9593212995C; Sat, 19 Nov 2016 06:57:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level: 
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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 hh24tMl7MGQ1; Sat, 19 Nov 2016 06:57:08 -0800 (PST)
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 21C051298C1; Sat, 19 Nov 2016 06:57:08 -0800 (PST)
Received: by mail-qt0-x231.google.com with SMTP id n6so180644478qtd.1; Sat, 19 Nov 2016 06:57:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=I0DSZ0H8vsGjiXrv2VCmwlctI5g9BSDrFWffCOTq8Dc=; b=uTXPEQGrL4qfFxF99TQ2RVOXMg+mUpsSAzzyBKqooVQtJQQxICVnqLfjY+QeldQH9S Jr5W3b9vTeFBhqT6b0oB1riqHkU9L3RzMh6WoFkeV3vMcPqzKkxobJWG3etwZDiTOhWA Id5wCOTGn9317/aXDhTqD7SW6DmDXV4TaRn9uscfV/P3OynYWmMNA3ddldoeN1VzH1Pl nm2cSU2IWaGq0Ge4mIF34bMfXWqboXBxFYe/ncOojkzIfJpKs2Xf9rAokrKExYGzGOHf eAS/jn9TpCDslfqydfhpj3cCK40H5dUPZMCcREhKUZB5vQqzLinlbI3uCIlLeag6BpbQ AjpQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=I0DSZ0H8vsGjiXrv2VCmwlctI5g9BSDrFWffCOTq8Dc=; b=N4mT887oD8QF8y8OyWx2devmInAhf3N6Yml/bq1Dvz+VznrGQOwJhZo64vWTwPFdQY r3odzj0uyjPjfKvbGWLD4Hvadnbt9C26fehF4MDmJNraugb9IPTC1obiK38oDfifW/Ov tnvIqd/uwblQZ3Jqiaouo9MxXyKf+3j/6KM2hTwnH99LaMVJwCccakZnuhsRRbU6qC+7 MgiaJUOjMxfP/wIhlhp7uLSkG6CdgnVl+V09rwKRwjsiTT1RMPcp2ffY3E/pcXwCeUvc sxbgX2crD/KMEvo6u4Q2WEUZwkbx0YYu3ehOwu65IYzxrExm5ooH/9LtVTFLFQg8AUOv DSmA==
X-Gm-Message-State: AKaTC00k17xzgVu2Xd0y893rKtd6LOoM+feGe6glNxy8rC7aHByn+dGBQk65bF8xPUSQ1sJDvINEKrVx01Oh0g==
X-Received: by 10.200.48.151 with SMTP id v23mr2980220qta.199.1479567427246; Sat, 19 Nov 2016 06:57:07 -0800 (PST)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.140.16.50 with HTTP; Sat, 19 Nov 2016 06:57:06 -0800 (PST)
In-Reply-To: <58306620.4000308@foobar.org>
References: <20161116061556.GG1073@dhcp-9341.meeting.ietf.org> <20161116105535.GW79185@Space.Net> <1479295774707.77855@dacor.de> <20161116113849.udbrfvdhaj3be7nx@bongo.bofh.it> <20161116130110.GK1073@dhcp-9341.meeting.ietf.org> <20161116134707.GP24817@gir.theapt.org>      <58306620.4000308@foobar.org>
From: Robert Raszuk 
Date: Sat, 19 Nov 2016 15:57:06 +0100
X-Google-Sender-Auth: 5OCrgLorLyCJ5u1jAIo16-oF0Lo
Message-ID: 
To: Nick Hilliard 
Content-Type: multipart/alternative; boundary=001a1143136cec21870541a8a2b5
Archived-At: 
Cc: "idr@ietf.org" , "grow@ietf.org" 
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 19 Nov 2016 14:57:09 -0000

--001a1143136cec21870541a8a2b5
Content-Type: text/plain; charset=UTF-8

Nick,

I am not going to argue with few of you here who want free form text
and do not accept any suggestions.

But if you can not parse few defined keywords in any free form text to
enable better
automated interpretation of the message I think there is more problems
here. TLV within current NOTIFICATION MSG is an overkill so do not count of
new proposal from me on it. Operational message solved that already.

Btw how are you going to handle it in IX ? I assume RS peers will not get
any info if one of the parties they used to get routes from goes down and
sends
free form msg to RS ? Routes will be get withdrawn and that's it.

Best,
R.

On Sat, Nov 19, 2016 at 3:48 PM, Nick Hilliard  wrote:

> Robert Raszuk wrote:
> > Just to be clear: I am also OK with free form text with the few well
> > known and easy to machine parse keywords (in it).
>
> the field should either be fully structured or free-form, and the
> explicit intent of this draft is free form, utf8.  Having a half-way
> house is in nobody's interest because the discussion will then rat-hole
> on defining a new ad-hoc quasi-language, and the draft - if it ever gets
> turned into running code - will end up being a protocol soup which
> no-one will find satisying.
>
> If you feel it should be fully structured, then please feel free to
> submit an alternative draft to that effect.
>
> Nick
>

--001a1143136cec21870541a8a2b5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Nick,

I am not going to argue with few of you here who want f=
ree form text=C2=A0
and do not accept any suggestio=
ns.=C2=A0

But if you c=
an not parse few defined keywords in any free form text to enable better=C2=
=A0
automated interpretation of the message I think=
 there is more problems=C2=A0
here. TLV within curr=
ent NOTIFICATION MSG is an overkill so do not count of=C2=A0
new proposal from me on it. Operational message solved that alrea=
dy.=C2=A0

Btw how are =
you going to handle it in IX ? I assume RS peers will not get=C2=A0
any info if one of the parties they used to get routes fro=
m goes down and sends=C2=A0
free form msg to RS ? R=
outes will be get withdrawn and that's it.=C2=A0

Best,
R.=C2=A0

On Sat, Nov 19, 2016 at 3:48 PM,=
 Nick Hilliard <nick@foobar.org> wrote:
Robert Raszuk wrote:

> Just to be clear: I am also OK with free form text with the few well
> known and easy to machine parse keywords (in it).



the field should either be fully structured or free-form, and the
explicit intent of this draft is free form, utf8.=C2=A0 Having a half-way
house is in nobody's interest because the discussion will then rat-hole=


on defining a new ad-hoc quasi-language, and the draft - if it ever gets
turned into running code - will end up being a protocol soup which

no-one will find satisying.



If you feel it should be fully structured, then please feel free to

submit an alternative draft to that effect.



Nick





--001a1143136cec21870541a8a2b5--


From nobody Sat Nov 19 06:59:12 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A7211296F8; Sat, 19 Nov 2016 06:59: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, 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] 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 zm_1fq2kxbRk; Sat, 19 Nov 2016 06:59:08 -0800 (PST)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0107.outbound.protection.outlook.com [104.47.2.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5FA112956B; Sat, 19 Nov 2016 06:59:07 -0800 (PST)
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=rPqheUOZdd4M+zIeN5kYUTKkdfYpL1IR83Opaf3WKKg=; b=DAy89VfSVLN698UzcMtLkVor0PVwzUFt7JxbMw7KSw4ecNUdDd7xidnPPYfgxuGTsEmJJiBZCmuilC2f0BH29p5hpwAqsl+AiAJQ7y927PoTLUpbnkfPMp2C1l4vv0ySUqNBXDsqx2ijcEVDXrh5og1894CywZ3zBrAsxCDUn64=
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.721.10; Sat, 19 Nov 2016 14:59:03 +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.0721.017; Sat, 19 Nov 2016 14:59:03 +0000
From: "Neil J. McRae" 
To: Nick Hilliard 
Thread-Topic: [GROW] [Idr] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
Thread-Index: AQHSQmy0+8tbbqf0dkKKv6LUENTaKKDgV5qAgAAFw4CAAADCgIAABOAAgAADF6s=
Date: Sat, 19 Nov 2016 14:59:03 +0000
Message-ID: <319AD952-C571-4085-8D56-C06A51F021E3@domino.org>
References: <20161116061556.GG1073@dhcp-9341.meeting.ietf.org> <20161116105535.GW79185@Space.Net> <1479295774707.77855@dacor.de> <20161116113849.udbrfvdhaj3be7nx@bongo.bofh.it> <20161116130110.GK1073@dhcp-9341.meeting.ietf.org> <20161116134707.GP24817@gir.theapt.org>     , <58306620.4000308@foobar.org>
In-Reply-To: <58306620.4000308@foobar.org>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=neil@domino.org; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [188.29.164.152]
x-microsoft-exchange-diagnostics: 1; AM4PR03MB1427; 7:Of0SMlE1FlIo8N9YQ+Gg55a5TZZvsBfs37Zn7b53hgcb9oucxZBEn6grpBwcTkVhClQbq+el3+6/6FoHC8VC1xuGbhic61z6V7uhbweA++hniCbGufNw3EKyu9FniEdVjA50mLH05jfMC0gfXvFEDlApJ98ZDl3+Z76umJZQ0XD3Rm8F6OP3yzY4SqYuq1rafK53+J89czPXvELCU+QqAWqeEUCyOL0uwQjkH3rn5R+OyTUNNK23YUIqPLEhwkUwhEVzZ4pbq9AgnxSXMxl6UOXwglHXREzklwzZTK6WFmqB+laL2j5g9EEMRefGQUDKweYHZ9Oz2/AzQ2E/Vibtr/+UY4IZpn43S2/BTM1KvZM=
x-ms-office365-filtering-correlation-id: 8ae9bd14-f5d4-47bd-cd3f-08d4108c9a73
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:AM4PR03MB1427;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6060326)(6040307)(6045199)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(6061324)(2016111802025)(6043046); SRVR:AM4PR03MB1427; BCL:0; PCL:0; RULEID:; SRVR:AM4PR03MB1427; 
x-forefront-prvs: 0131D22242
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(24454002)(189002)(199003)(6916009)(2950100002)(2906002)(4326007)(3280700002)(110136003)(3660700001)(102836003)(6116002)(3846002)(122556002)(97736004)(106116001)(305945005)(36756003)(8676002)(7846002)(7736002)(5660300001)(106356001)(189998001)(105586002)(33656002)(76176999)(54356999)(101416001)(81156014)(229853002)(77096005)(5003630100001)(83716003)(66066001)(8936002)(6506003)(82746002)(81166006)(38730400001)(6512003)(87936001)(50986999)(68736007)(230783001)(93886004)(86362001)(92566002)(2900100001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR03MB1427; H:AM4PR03MB1425.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  MX:1; A:0; LANG:en; 
received-spf: None (protection.outlook.com: domino.org does not designate permitted sender hosts)
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: 19 Nov 2016 14:59:03.7607 (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: 
Cc: "grow@ietf.org" , Peter Hessler , Robert Raszuk , "idr@ietf.org" 
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 19 Nov 2016 14:59:10 -0000

We shouldn't be encouraging folks to build networks that for routine events=
 we then require more manual intervention when it's unwarranted.=20

Why does it need to be free format?

How many reasons or signals does one need to send in a message like this? J=
ust thinking whilst I wait for the till to be rebooted in WHSmiths -  I can=
 think of 3 different cease reasons (and 1 of them is a form of the other).=
 De-peer; maintenance;  problem call/contact us - what else ? Enough to tri=
gger info is in the existing config to trigger you to the right information=
 on peeringdb or other local database.

Cheers,
Neil=20

Sent from my iPhone

> On 19 Nov 2016, at 14:48, Nick Hilliard  wrote:
>=20
> Robert Raszuk wrote:
>> Just to be clear: I am also OK with free form text with the few well
>> known and easy to machine parse keywords (in it).
>=20
> the field should either be fully structured or free-form, and the
> explicit intent of this draft is free form, utf8.  Having a half-way
> house is in nobody's interest because the discussion will then rat-hole
> on defining a new ad-hoc quasi-language, and the draft - if it ever gets
> turned into running code - will end up being a protocol soup which
> no-one will find satisying.
>=20
> If you feel it should be fully structured, then please feel free to
> submit an alternative draft to that effect.
>=20
> Nick


From nobody Sat Nov 19 07:08:20 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44161129692; Sat, 19 Nov 2016 07:08:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.399
X-Spam-Level: 
X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, 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 Is3uKFN6TRBI; Sat, 19 Nov 2016 07:08:14 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 58FDA12956B; Sat, 19 Nov 2016 07:08:14 -0800 (PST)
Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id 9170C1E337; Sat, 19 Nov 2016 10:11:14 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
From: Jeffrey Haas 
In-Reply-To: <319AD952-C571-4085-8D56-C06A51F021E3@domino.org>
Date: Sat, 19 Nov 2016 10:08:13 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <06F3A369-5B8E-4C34-BC52-7AB8B99C2048@pfrc.org>
References: <20161116061556.GG1073@dhcp-9341.meeting.ietf.org> <20161116105535.GW79185@Space.Net> <1479295774707.77855@dacor.de> <20161116113849.udbrfvdhaj3be7nx@bongo.bofh.it> <20161116130110.GK1073@dhcp-9341.meeting.ietf.org> <20161116134707.GP24817@gir.theapt.org>      <58306620.4000308@foobar.org> <319AD952-C571-4085-8D56-C06A51F021E3@domino.org>
To: "Neil J. McRae" 
X-Mailer: Apple Mail (2.3251)
Archived-At: 
Cc: "idr@ietf.org" , "grow@ietf.org" , Peter Hessler , Robert Raszuk 
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 19 Nov 2016 15:08:15 -0000

> On Nov 19, 2016, at 9:59 AM, Neil J. McRae  wrote:
>=20
> We shouldn't be encouraging folks to build networks that for routine =
events we then require more manual intervention when it's unwarranted.=20=

>=20
> Why does it need to be free format?

Part of the motivation I had for suggesting the use of an existing =
sub-code is we have *not* changed the semantics in a machine-readable =
format.  It's still "administrative shutdown".  Today, you'd have zero =
extra information what it's about.

The problem with attempting to move to the next set of levels of machine =
parseability is enumerating the full set of reasons that you would do =
such a shutdown. =20

IMO, we're better off leaving this as freeform text.  I'd also encourage =
the regional operators to think about what they'd like to *see* in such =
fields.  Just because the protocol doesn't mandate fields doesn't mean =
you couldn't provide guidance as to what goes in there. =20

Jared's case is what I find to be the normal one:
- NOC contact#
- NOC ticket#
- Short reason why the session is down. (E.g. "you didn't pay your =
bill!")

Again, the key is that the machine readable - and BGP standards backward =
compatible bit - hasn't changed.

-- Jeff


From nobody Sat Nov 19 07:10:09 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC3A1296EC; Sat, 19 Nov 2016 07:10:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level: 
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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 o2Vu8WcMWl3i; Sat, 19 Nov 2016 07:10:03 -0800 (PST)
Received: from mail-qt0-x241.google.com (mail-qt0-x241.google.com [IPv6:2607:f8b0:400d:c0d::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 F0ACF129692; Sat, 19 Nov 2016 07:10:02 -0800 (PST)
Received: by mail-qt0-x241.google.com with SMTP id n34so21258143qtb.3; Sat, 19 Nov 2016 07:10:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=WRMt2hcnr1uwZQFUlgqipIruxhoLrq83KxHajP4YnR4=; b=v6DP6JYE65OpRUWZdC3fzR+uC6i6fLWFQZsxhVydyAmrMDq9F/RPfsHsE+iEB7UQO1 1RQK5z54xdObYPjWtM78JtFiFv46QUAHzEtFS6ffYmiPRIeULXLPa+FsNOYR96P+OTXE g0Pu0i3Z0grfvGUXxrOKEFDr/8osExrvdmh+umVcBBkkimefyQkcBbmVjiiost0ajlMq y1zbYoSKcq9PYD4ovyad/iwT729gYe1IRrBzYRyIi/a5Xw+z7b7PaBGnOfUcFSXJC6pt T9uj7kFrXmTY6uoOYxBcUqbXj0NwZCkKenqQnyE2W0FBYIHuU//VgCZXGkZaDoXURQKc 88pA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=WRMt2hcnr1uwZQFUlgqipIruxhoLrq83KxHajP4YnR4=; b=kB3Ersfpd60MHCWTp6y0nAYqrm1jk5eQob1fy1WDLLq62NvXR6pgF/1xEx1OJP+0XI dmySnQdrd21UuqxMzoOdXSCD1S8GIarLPk/h1IpZnrZURXCHetV0lmjko5gTCwe5QkUP Jvh8sOgVw+B6dNbulcT9IgkTnkoxRSSSMRIfHEMPEs2An9zCNCbdzL+V9IRMbWq2boMr 5V3djrM2gvxvS+3rMRxw3BAfi8oAiopcNkGJZ90PhzfRg6qsYRr5w8N/qzXpYK69ccyW T0R8BIIYtzzg8x4ks+Dq2RQTjoJUP54fqyJ+8FxR23S6S5EueDswn1g7T9bfoG1Kh+5q MP8w==
X-Gm-Message-State: AKaTC01/4d0gIo7uQ2zcaBTf+joT9y9G4U5eQ4DGX9sYtiC2BvgWlvjWJ+gLXuHSbJB2Na6kY+TTfJXEGlnbew==
X-Received: by 10.200.36.21 with SMTP id c21mr3140370qtc.1.1479568202072; Sat, 19 Nov 2016 07:10:02 -0800 (PST)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.140.16.50 with HTTP; Sat, 19 Nov 2016 07:10:00 -0800 (PST)
In-Reply-To: <319AD952-C571-4085-8D56-C06A51F021E3@domino.org>
References: <20161116061556.GG1073@dhcp-9341.meeting.ietf.org> <20161116105535.GW79185@Space.Net> <1479295774707.77855@dacor.de> <20161116113849.udbrfvdhaj3be7nx@bongo.bofh.it> <20161116130110.GK1073@dhcp-9341.meeting.ietf.org> <20161116134707.GP24817@gir.theapt.org>      <58306620.4000308@foobar.org> <319AD952-C571-4085-8D56-C06A51F021E3@domino.org>
From: Robert Raszuk 
Date: Sat, 19 Nov 2016 16:10:00 +0100
X-Google-Sender-Auth: 0bGBmfx5_XFVpHP_hduPA7M3F0Q
Message-ID: 
To: "Neil J. McRae" 
Content-Type: multipart/alternative; boundary=001a1142abc61b07c30541a8d1da
Archived-At: 
Cc: "idr@ietf.org" , Peter Hessler , "grow@ietf.org" 
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 19 Nov 2016 15:10:05 -0000

--001a1142abc61b07c30541a8d1da
Content-Type: text/plain; charset=UTF-8

Leave alone that this all makes sense to be sent well before the planned
admin shutdown so the other side is first aware of it and can manually or
automatically take users off that peering.

But looks like we are light years away from such basic thing here ....

On Sat, Nov 19, 2016 at 3:59 PM, Neil J. McRae  wrote:

> We shouldn't be encouraging folks to build networks that for routine
> events we then require more manual intervention when it's unwarranted.
>
> Why does it need to be free format?
>
> How many reasons or signals does one need to send in a message like this?
> Just thinking whilst I wait for the till to be rebooted in WHSmiths -  I
> can think of 3 different cease reasons (and 1 of them is a form of the
> other). De-peer; maintenance;  problem call/contact us - what else ? Enough
> to trigger info is in the existing config to trigger you to the right
> information on peeringdb or other local database.
>
> Cheers,
> Neil
>
> Sent from my iPhone
>
> > On 19 Nov 2016, at 14:48, Nick Hilliard  wrote:
> >
> > Robert Raszuk wrote:
> >> Just to be clear: I am also OK with free form text with the few well
> >> known and easy to machine parse keywords (in it).
> >
> > the field should either be fully structured or free-form, and the
> > explicit intent of this draft is free form, utf8.  Having a half-way
> > house is in nobody's interest because the discussion will then rat-hole
> > on defining a new ad-hoc quasi-language, and the draft - if it ever gets
> > turned into running code - will end up being a protocol soup which
> > no-one will find satisying.
> >
> > If you feel it should be fully structured, then please feel free to
> > submit an alternative draft to that effect.
> >
> > Nick
>

--001a1142abc61b07c30541a8d1da
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



Leave alon=
e that this all makes sense to be sent well before the planned admin shutdo=
wn so the other side is first aware of it and can manually or automatically=
 take users off that peering.=C2=A0

But looks like we are light years away from such basic thing =
here ....=C2=A0

On Sat, Nov 19, 2016 at 3:59 PM, Neil J. McRae =
<neil@domino.org> wrote:
We shouldn't be e=
ncouraging folks to build networks that for routine events we then require =
more manual intervention when it's unwarranted.



Why does it need to be free format?



How many reasons or signals does one need to send in a message like this? J=
ust thinking whilst I wait for the till to be rebooted in WHSmiths -=C2=A0 =
I can think of 3 different cease reasons (and 1 of them is a form of the ot=
her). De-peer; maintenance;=C2=A0 problem call/contact us - what else ? Eno=
ugh to trigger info is in the existing config to trigger you to the right i=
nformation on peeringdb or other local database.



Cheers,

Neil



Sent from my iPhone




> On 19 Nov 2016, at 14:4=
8, Nick Hilliard <nick@foobar.org=
> wrote:

>

> Robert Raszuk wrote:

>> Just to be clear: I am also OK with free form text with the few we=
ll

>> known and easy to machine parse keywords (in it).

>

> the field should either be fully structured or free-form, and the

> explicit intent of this draft is free form, utf8.=C2=A0 Having a half-=
way

> house is in nobody's interest because the discussion will then rat=
-hole

> on defining a new ad-hoc quasi-language, and the draft - if it ever ge=
ts

> turned into running code - will end up being a protocol soup which

> no-one will find satisying.

>

> If you feel it should be fully structured, then please feel free to
> submit an alternative draft to that effect.

>

> Nick





--001a1142abc61b07c30541a8d1da--


From nobody Sat Nov 19 07:12:48 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2040212999C; Sat, 19 Nov 2016 07:12:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.398
X-Spam-Level: 
X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.497, 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 ZtDq3jBdkA8a; Sat, 19 Nov 2016 07:12:45 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 2E009129991; Sat, 19 Nov 2016 07:12:45 -0800 (PST)
Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id 5CBB71E337; Sat, 19 Nov 2016 10:15:45 -0500 (EST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_87E36665-39B3-4DC6-BEE0-2956DB593B94"
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
From: Jeffrey Haas 
In-Reply-To: 
Date: Sat, 19 Nov 2016 10:12:43 -0500
Message-Id: <220C5A51-AC49-4341-B531-594277D9CE62@pfrc.org>
References: <20161116061556.GG1073@dhcp-9341.meeting.ietf.org> <20161116105535.GW79185@Space.Net> <1479295774707.77855@dacor.de> <20161116113849.udbrfvdhaj3be7nx@bongo.bofh.it> <20161116130110.GK1073@dhcp-9341.meeting.ietf.org> <20161116134707.GP24817@gir.theapt.org>      <58306620.4000308@foobar.org> <319AD952-C571-4085-8D56-C06A51F021E3@domino.org> 
To: Robert Raszuk 
X-Mailer: Apple Mail (2.3251)
Archived-At: 
Cc: "idr@ietf.org" , "grow@ietf.org" , Peter Hessler 
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 19 Nov 2016 15:12:46 -0000

--Apple-Mail=_87E36665-39B3-4DC6-BEE0-2956DB593B94
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


> On Nov 19, 2016, at 10:10 AM, Robert Raszuk  wrote:
>=20
>=20
> Leave alone that this all makes sense to be sent well before the =
planned admin shutdown so the other side is first aware of it and can =
manually or automatically take users off that peering.=20
>=20
> But looks like we are light years away from such basic thing here ....=20=


That was part of my motivation about asking about the already-adopted =
Advisory draft still being relevant. =20

The shutdown draft requires no changes for any useful backward =
compatibility.  But in order to signal such other information, the =
routers in question would need to support Advisory.

Although, personally, I'd rather just get an email to my noc@ address =
than have to scrape my syslog that maintenance is about to occur =
unexpectedly.

-- Jeff


--Apple-Mail=_87E36665-39B3-4DC6-BEE0-2956DB593B94
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii


On Nov 19, 2016, at 10:10 AM, Robert Raszuk <robert@raszuk.net> =
wrote:


Leave alone that this all makes =
sense to be sent well before the planned admin shutdown so the other =
side is first aware of it and can manually or automatically take users =
off that peering. 

But looks =
like we are light years away from such basic thing here =
.... 

That was part of my motivation about asking about the =
already-adopted Advisory draft still being relevant.  

The shutdown draft =
requires no changes for any useful backward compatibility.  But in =
order to signal such other information, the routers in question would =
need to support Advisory.

Although, personally, I'd rather just get an email to my noc@ =
address than have to scrape my syslog that maintenance is about to occur =
unexpectedly.

--=
 Jeff

=

--Apple-Mail=_87E36665-39B3-4DC6-BEE0-2956DB593B94--


From nobody Sat Nov 19 07:16:42 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4FD81298A6; Sat, 19 Nov 2016 07:16:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level: 
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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 hsQdZa3I9Syi; Sat, 19 Nov 2016 07:16:39 -0800 (PST)
Received: from mail-qt0-x241.google.com (mail-qt0-x241.google.com [IPv6:2607:f8b0:400d:c0d::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 74A091295E8; Sat, 19 Nov 2016 07:16:39 -0800 (PST)
Received: by mail-qt0-x241.google.com with SMTP id n6so21297918qtd.0; Sat, 19 Nov 2016 07:16:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=+syvzRZta0f/sywv825RMpWxgQqN5q02nqoRxtQ+azI=; b=NZJoNP/7UeHNOaS2cWAS099S/7L/aGLNfjfvPnk7cr5gTj/3h6Jpm45ICrvYTUEEer QqMT4U088I224eOCsGJIwYg93Qh4Tj+pGgM4HqcnQ5vsH/XEjAPbR9gixG4jGJXsOHbc 8Xh9+hHmf4qelWUZFaaa/JLAMewlLMp6MxWEdZSQXGBFZiIO28xbD0hw12azxCb4lXQ4 K8qGvhCp+iPdKYSar+NQHthTWzI8AmU0fYOFp7z88BFe4Y9On2KD7NBvVVz8qZ+GPzqr fseY5dgD/IvtOBhLvmnrg/im3BTzmmWYQbd/Hw7uZKuyEUlKCMJMsmuwi2Yx7Jy5ORlh B7Dg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=+syvzRZta0f/sywv825RMpWxgQqN5q02nqoRxtQ+azI=; b=HbAWSnhWaCWva2VtQGMEcAHlDoyhSSE3gg+6TeTtQ7XUBp9PaQCpcrBCo9KUUJMFg3 Dkv0Geo7Sn77/agMKDGBqzQVoWHEZWVimqY6C94H5wgBnbz/B+3wfL9s7iJAAeWcNfib ghCXm4UfrCLG9LzACwuz601C2gI2NDuLQG6dmlUYvUryCzQl5MIMquFgh21ABGBgD0oR 8wZG0N5zu38HlDZ2fGUX+zIGgZ287BTpFcinyFy5/rCv2gmW0Bv18rIVv94buyv84VPa MmqqFumiMCogoQXnE2aXJbzMj2qAkvcjQmT9FXoDzPQZN+vA6sNJEJLf/kyj5FqJjQuj r8AA==
X-Gm-Message-State: AKaTC02M7HtqkZUTh0RC0jyqycWfkrIU3o56u2SbcyUAIwhw3Lwa6x0qlBNDmzHWyyuKKKMkfYimDoPl8qwj+A==
X-Received: by 10.200.48.151 with SMTP id v23mr3028995qta.199.1479568598628; Sat, 19 Nov 2016 07:16:38 -0800 (PST)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.140.16.50 with HTTP; Sat, 19 Nov 2016 07:16:37 -0800 (PST)
In-Reply-To: <06F3A369-5B8E-4C34-BC52-7AB8B99C2048@pfrc.org>
References: <20161116061556.GG1073@dhcp-9341.meeting.ietf.org> <20161116105535.GW79185@Space.Net> <1479295774707.77855@dacor.de> <20161116113849.udbrfvdhaj3be7nx@bongo.bofh.it> <20161116130110.GK1073@dhcp-9341.meeting.ietf.org> <20161116134707.GP24817@gir.theapt.org>      <58306620.4000308@foobar.org> <319AD952-C571-4085-8D56-C06A51F021E3@domino.org> <06F3A369-5B8E-4C34-BC52-7AB8B99C2048@pfrc.org>
From: Robert Raszuk 
Date: Sat, 19 Nov 2016 16:16:37 +0100
X-Google-Sender-Auth: yvbEjX9n4V49NB7QcF626qRjI-Q
Message-ID: 
To: Jeffrey Haas 
Content-Type: multipart/alternative; boundary=001a1143136cbe006b0541a8e852
Archived-At: 
Cc: "idr@ietf.org" , "grow@ietf.org" , Peter Hessler 
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 19 Nov 2016 15:16:40 -0000

--001a1143136cbe006b0541a8e852
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Jeff,

> Part of the motivation I had for suggesting the use of an existing
sub-code
> is we have *not* changed the semantics in a machine-readable format.
> It's still "administrative shutdown".  Today, you'd have zero extra
information
> what it's about.

=E2=80=8BMy interpretation of 4271 does not prohibit one to send more then =
one
cease notification message.

One would be subcode 2 as today .. the other would be subcode 9 INFO.

> The shutdown draft requires no changes for any useful backward
compatibility.

If you add length as proposed by Job it does.

> But in order to signal such other information, the routers in question
would need to support Advisory.

Advisory is also not structured.

> Although, personally, I'd rather just get an email to my noc@ address
than have to scrape
> my syslog that maintenance is about to occur unexpectedly.

Indeed !!! Is the problem here that one side does not know the email of the
other side and syslog will be the communicator ?

Thx,
R.
=E2=80=8B

--001a1143136cbe006b0541a8e852
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Jeff,

> Part of the motivation I had for suggesting the use of an exist=
ing sub-code=C2=A0
> is we have *not* changed the sema=
ntics in a machine-readable format.=C2=A0=C2=A0
> It&#=
39;s still "administrative shutdown".=C2=A0 Today, you'd have=
 zero extra information=C2=A0
> what it's about.

=E2=80=8BMy interpretation of 4271 does not prohibit=
 one to send more then one cease notification message.=C2=A0

One would be subcode 2 as today .. t=
he other would be subcode 9 INFO.=C2=A0

<=
div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif=
;font-size:small">
> The shutdown draft requires no changes for any useful backward com=
patibility. =C2=A0

If you add length as proposed by Job it does.=C2=A0

> But in order to signal =
such other information, the routers in question would need to support Advis=
ory.

=

Advisory=
 is also not structured.

> Although, personally, I'd rather just get an email to =
my noc@ address than have to scrape=C2=A0
> my syslog that maintenance is about t=
o occur unexpectedly.

Indeed !!! Is the problem here that one side does not know the email =
of the other side and syslog will be the communicator ?=C2=A0

Thx,
R.
=
=E2=80=8B




--001a1143136cbe006b0541a8e852--


From nobody Sat Nov 19 07:31:49 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF8C41299A1; Sat, 19 Nov 2016 07:31:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.398
X-Spam-Level: 
X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.497, 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 eUOUkfGMHTU2; Sat, 19 Nov 2016 07:31:43 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 25FDB129665; Sat, 19 Nov 2016 07:31:43 -0800 (PST)
Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id 370B61E337; Sat, 19 Nov 2016 10:34:43 -0500 (EST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_A2089FE7-9590-46FD-82F5-2FE1B076AFA7"
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
From: Jeffrey Haas 
In-Reply-To: 
Date: Sat, 19 Nov 2016 10:31:41 -0500
Message-Id: <2F4BF4C2-3AFA-41D8-991D-2EEB3A0D1721@pfrc.org>
References: <20161116061556.GG1073@dhcp-9341.meeting.ietf.org> <20161116105535.GW79185@Space.Net> <1479295774707.77855@dacor.de> <20161116113849.udbrfvdhaj3be7nx@bongo.bofh.it> <20161116130110.GK1073@dhcp-9341.meeting.ietf.org> <20161116134707.GP24817@gir.theapt.org>      <58306620.4000308@foobar.org> <319AD952-C571-4085-8D56-C06A51F021E3@domino.org> <06F3A369-5B8E-4C34-BC52-7AB8B99C2048@pfrc.org> 
To: Robert Raszuk 
X-Mailer: Apple Mail (2.3251)
Archived-At: 
Cc: "idr@ietf.org" , "grow@ietf.org" , Peter Hessler 
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 19 Nov 2016 15:31:45 -0000

--Apple-Mail=_A2089FE7-9590-46FD-82F5-2FE1B076AFA7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On Nov 19, 2016, at 10:16 AM, Robert Raszuk  wrote:
>=20
> Jeff,
>=20
> > Part of the motivation I had for suggesting the use of an existing =
sub-code=20
> > is we have *not* changed the semantics in a machine-readable format. =
=20
> > It's still "administrative shutdown".  Today, you'd have zero extra =
information=20
> > what it's about.
>=20
> =E2=80=8BMy interpretation of 4271 does not prohibit one to send more =
then one cease notification message.=20
>=20
> One would be subcode 2 as today .. the other would be subcode 9 INFO.=20=


What would the distinction between admin shutdown (clear) vs. info-read =
the friendly message be? =20

>=20
> > The shutdown draft requires no changes for any useful backward =
compatibility. =20
>=20
> If you add length as proposed by Job it does.=20

4271, section 6.4.  I'm being a bit of a pain in my interpretation here =
but simply:
- You still have a valid code and sub-code.  (The admin shutdown subcode =
is already not in 4271 and thus not in compliance with 4271-only =
implementation.)
- If you don't understand the data, you can't report it back.
- You're instructed to "bring this to the attention of the =
administration of the peer".  This is one of the motivators already for =
the hexdump many implementations use.

I derive my justification from the same used when RFC 4486 was =
discussed. :-)

>=20
> > But in order to signal such other information, the routers in =
question would need to support Advisory.
>=20
> Advisory is also not structured.

Partially my point.  "SMS over BGP" is how someone commented on this =
previously.

-- Jeff



--Apple-Mail=_A2089FE7-9590-46FD-82F5-2FE1B076AFA7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


On Nov 19, 2016, at 10:16 AM, Robert Raszuk <robert@raszuk.net> =
wrote:

Jeff,

> =
Part of the motivation I had for suggesting the use of an existing =
sub-code 
> =
is we have *not* changed the semantics in a machine-readable =
format.  
> =
It's still "administrative shutdown".  Today, you'd have zero extra =
information 
> =
what it's about.
=E2=80=8B=
My interpretation of 4271 does not prohibit one to send more then one =
cease notification message. 

One =
would be subcode 2 as today .. the other would be subcode 9 =
INFO. 

What would the distinction between admin shutdown =
(clear) vs. info-read the friendly message be?  


> =
The shutdown draft requires no changes for any useful backward =
compatibility.  

If =
you add length as proposed by Job it =
does. 

4271, section 6.4.  I'm being a bit of a pain in =
my interpretation here but simply:
- You still have a valid =
code and sub-code.  (The admin shutdown subcode is already not in =
4271 and thus not in compliance with 4271-only =
implementation.)
- If you don't understand the data, you can't =
report it back.
- You're instructed to "bring this to the =
attention of the administration of the peer".  This is one of the =
motivators already for the hexdump many implementations =
use.

I derive my justification from =
the same used when RFC 4486 was discussed. :-)


> =
But in order to signal such other information, the routers in question =
would need to support Advisory.

Advisory is also not =
structured.

Partially my point.  "SMS over BGP" is how someone =
commented on this previously.

-- =
Jeff


=

--Apple-Mail=_A2089FE7-9590-46FD-82F5-2FE1B076AFA7--


From nobody Sat Nov 19 07:48:45 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C5AF128B44; Sat, 19 Nov 2016 07:48:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level: 
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=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=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 sakWKx2uf6GA; Sat, 19 Nov 2016 07:48:39 -0800 (PST)
Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B7CB12958F; Sat, 19 Nov 2016 07:48:39 -0800 (PST)
Received: by mail-qk0-x229.google.com with SMTP id q130so301994148qke.1; Sat, 19 Nov 2016 07:48:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=TI7B38aII/N2Bmfs0b4ETyB8XlBk9wKAnpsZx9K0dTI=; b=aFQKbPxmL/M+kPwPg1o3s3RXb3rSblLQSE+++nNV7VQ3Eg1akBxzKeuqK+lALZA0Aq pdM50StGVbGmVi/am5u1Oru62tXY6a6QgsjOvc0ipWMSEoI5n4c4Z9GFPgKdEbcsM36j 3qAOwtDey1+YOvBarY1zAuijnkD1QnDgH+n6aLpbRIvs8LKTY1RP4le4RAA+CloSseoe NSyx3VizqlOq9mGqtSFzXpLri9iXOKC1qU60uqZdX/Mp7aj0OBEzk2V3woJKcCXOW7Re g/jPIujz1P67xxYf1Y2hQbzTAmBYtJYnm3UWZJ5+0NBkZXub5N+GykbZZJhO1aMcxbx3 aRXA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=TI7B38aII/N2Bmfs0b4ETyB8XlBk9wKAnpsZx9K0dTI=; b=Gtzuc32UXtswOBuI+URPhzt3RPIr2kdVix4lz28qWRlbslXduPGv9c87KGK8Q0NsZ0 CW4w0k1XKNqtmPcSEyavPS0x/DMv4b0tajkSAoK+bTFSGkfiIEMqVhdwzoMHpB5sTD0m 3U1UZDy59Mn97dWFdiuoxs0i13+UivVEc3jJQWRfvM+qkroWBCOfP14JFQ8nfbKOvMg6 H5YRl+RYHNI1GfR0bqPDHPzK36mBjj1n9vZoYF+H1OKBI/pcoTYNWtUb8A7Jr+S/jkGy /ih0av3hgXBhtcMvjpxFJUcXy3nbiEi39Z98C1OLC3ITpyghpiP4E7jD3G0dAqlvQiyY bf0Q==
X-Gm-Message-State: AKaTC01P095s9PY+u9JdVz1usY8ULGIgMUibP9fN/d223OLNjZFZeG7URCiS+MmN0XZBaM8WG2Ln/pX7AuG8GQ==
X-Received: by 10.55.4.19 with SMTP id 19mr6191420qke.18.1479570518476; Sat, 19 Nov 2016 07:48:38 -0800 (PST)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.140.16.50 with HTTP; Sat, 19 Nov 2016 07:48:37 -0800 (PST)
In-Reply-To: <2F4BF4C2-3AFA-41D8-991D-2EEB3A0D1721@pfrc.org>
References: <20161116061556.GG1073@dhcp-9341.meeting.ietf.org> <20161116105535.GW79185@Space.Net> <1479295774707.77855@dacor.de> <20161116113849.udbrfvdhaj3be7nx@bongo.bofh.it> <20161116130110.GK1073@dhcp-9341.meeting.ietf.org> <20161116134707.GP24817@gir.theapt.org>      <58306620.4000308@foobar.org> <319AD952-C571-4085-8D56-C06A51F021E3@domino.org> <06F3A369-5B8E-4C34-BC52-7AB8B99C2048@pfrc.org>  <2F4BF4C2-3AFA-41D8-991D-2EEB3A0D1721@pfrc.org>
From: Robert Raszuk 
Date: Sat, 19 Nov 2016 16:48:37 +0100
X-Google-Sender-Auth: j2IzfGtMYI-sDtvcp48OvbblUGI
Message-ID: 
To: Jeffrey Haas 
Content-Type: multipart/alternative; boundary=001a114c84742c8f6d0541a95b0a
Archived-At: 
Cc: "idr@ietf.org" , "grow@ietf.org" 
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 19 Nov 2016 15:48:40 -0000

--001a114c84742c8f6d0541a95b0a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

> What would the distinction between admin shutdown (clear) vs. info-read
the friendly message be?

Ordering ...

=E2=80=8BYou define a subcode or even new code as NOTIFICATION INFO and tha=
t is by
the spec NOT to trigger the TCP reset .. before you get subsequent error
code and subcode (when applicable).

Thx,
r.

--001a114c84742c8f6d0541a95b0a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


> What would the distinction between admin shutdown (clear) vs. in=
fo-read the friendly message be? =C2=A0
=

Ordering ...=C2=A0

=

=E2=80=8BYou de=
fine a subcode or even new code as NOTIFICATION INFO and that is by the spe=
c NOT to trigger the TCP reset .. before you get subsequent error code and =
subcode (when applicable).=C2=A0

Thx,
r.



--001a114c84742c8f6d0541a95b0a--


From nobody Sat Nov 19 07:57:00 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A8F812958F; Sat, 19 Nov 2016 07:56:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.398
X-Spam-Level: 
X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.497, 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 v3tg9bnfJNi6; Sat, 19 Nov 2016 07:56:58 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 1B141129465; Sat, 19 Nov 2016 07:56:58 -0800 (PST)
Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id 662C81E337; Sat, 19 Nov 2016 10:59:58 -0500 (EST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_20CAEBE0-E713-40DF-AF5C-08431B325418"
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
From: Jeffrey Haas 
In-Reply-To: 
Date: Sat, 19 Nov 2016 10:56:57 -0500
Message-Id: 
References: <20161116061556.GG1073@dhcp-9341.meeting.ietf.org> <20161116105535.GW79185@Space.Net> <1479295774707.77855@dacor.de> <20161116113849.udbrfvdhaj3be7nx@bongo.bofh.it> <20161116130110.GK1073@dhcp-9341.meeting.ietf.org> <20161116134707.GP24817@gir.theapt.org>      <58306620.4000308@foobar.org> <319AD952-C571-4085-8D56-C06A51F021E3@domino.org> <06F3A369-5B8E-4C34-BC52-7AB8B99C2048@pfrc.org>  <2F4BF4C2-3AFA-41D8-991D-2EEB3A0D1721@pfrc.org> 
To: Robert Raszuk 
X-Mailer: Apple Mail (2.3251)
Archived-At: 
Cc: "idr@ietf.org" , "grow@ietf.org" 
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 19 Nov 2016 15:56:59 -0000

--Apple-Mail=_20CAEBE0-E713-40DF-AF5C-08431B325418
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On Nov 19, 2016, at 10:48 AM, Robert Raszuk  wrote:
>=20
> > What would the distinction between admin shutdown (clear) vs. =
info-read the friendly message be? =20
>=20
> Ordering ...=20
>=20
> =E2=80=8BYou define a subcode or even new code as NOTIFICATION INFO =
and that is by the spec NOT to trigger the TCP reset .. before you get =
subsequent error code and subcode (when applicable).=20

A change to use a NOTIFICATION message to *NOT* reset the TCP session is =
a rather large deviation from 4271.

I would not be supportive of that.

-- Jeff


--Apple-Mail=_20CAEBE0-E713-40DF-AF5C-08431B325418
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


On Nov 19, 2016, at 10:48 AM, Robert Raszuk <robert@raszuk.net> =
wrote:

> What would the =
distinction between admin shutdown (clear) vs. info-read the friendly =
message be?  

Ordering =
... 

=E2=80=8B=
You define a subcode or even new code as NOTIFICATION INFO and that is =
by the spec NOT to trigger the TCP reset .. before you get subsequent =
error code and subcode (when =
applicable). 

A change to use a NOTIFICATION message to *NOT* reset =
the TCP session is a rather large deviation from 4271.

I would not be supportive of that.

-- Jeff

=

--Apple-Mail=_20CAEBE0-E713-40DF-AF5C-08431B325418--


From nobody Sat Nov 19 08:07:56 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC0E129507; Sat, 19 Nov 2016 08:07:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level: 
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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 qi_4OJbAGg0f; Sat, 19 Nov 2016 08:07:53 -0800 (PST)
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 0D08F129465; Sat, 19 Nov 2016 08:07:53 -0800 (PST)
Received: by mail-qt0-x232.google.com with SMTP id n6so181296006qtd.1; Sat, 19 Nov 2016 08:07:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=7ivxk49YJIzIqKet515z4acLhwb5ZaXbBVzFzudT57s=; b=W4h1bxjXt/Mp104PaUlwhquonv13KdIvnSINN0s28gGN+zf9t3Prpv+c+vZ1cJMpFi ARYVBxPe7hY6yihvK3kmi60/pNNKQM2Z8oIVteMdorHUBuMOfOnWBLzJszbyQcwJKluD W1L9FE2AoetE+hbSSLsaJzhkCgk98mfa/m4YR5S4ah5V8MhiipDWTALW0D4vIYhGj7MC C8kjf9X5Kdk+2pr/1YPGMQY3pyFFqUpee+9mcJwa81ckAu8C1CHgRDoaM0M0fjP2CLxC z1c+Y2Rc/aVxwOEYlWY9TuK4F3TQ4Nn8ApYRQXST3qlCwGHjS30k1o7iwKNUpWMtT5d4 m1iw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=7ivxk49YJIzIqKet515z4acLhwb5ZaXbBVzFzudT57s=; b=DuEPdig1t2IweVdDv/YFo4UsQLoD9lG3kiCnb4TAaTkk2kxH8Xb8FogKl7v+BdNB8Y 6lsXT8ixroAxe3Yq+0ULBtPgwzMV0YN5gpdKxquAKbFskjCApla8D2ZOM325Ho9Ls0rj DrIO/QkPDCl+Ocr3F7OwsFyXiyjr3/+Bg8SkfUxgJTOr5XcvFXECEpV2Yhj0C2Yn1+uI 3eUPY7c94Bq3IevZ+uQeY9rGSly3ngXVk3zJ0OyumyFbsdN+V0gECTu80W4nvUjzwHEr geM6tt/df3A3n+tQcFXCbM4dUzt2n20holRPRk9I7mMjxsCdy4/uFneSfLDP+uKXjW6g vYCg==
X-Gm-Message-State: AKaTC03FiQQH/n342x2Cxm3oSpLxZ0NwIucLOkUnYKUy3ztBPCcO6S9+9UlWAbnPrqQ8QTXPwH/crtIr8p0eug==
X-Received: by 10.237.60.101 with SMTP id u34mr3785648qte.53.1479571672135; Sat, 19 Nov 2016 08:07:52 -0800 (PST)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.140.16.50 with HTTP; Sat, 19 Nov 2016 08:07:50 -0800 (PST)
In-Reply-To: 
References: <20161116061556.GG1073@dhcp-9341.meeting.ietf.org> <20161116105535.GW79185@Space.Net> <1479295774707.77855@dacor.de> <20161116113849.udbrfvdhaj3be7nx@bongo.bofh.it> <20161116130110.GK1073@dhcp-9341.meeting.ietf.org> <20161116134707.GP24817@gir.theapt.org>      <58306620.4000308@foobar.org> <319AD952-C571-4085-8D56-C06A51F021E3@domino.org> <06F3A369-5B8E-4C34-BC52-7AB8B99C2048@pfrc.org>  <2F4BF4C2-3AFA-41D8-991D-2EEB3A0D1721@pfrc.org>  
From: Robert Raszuk 
Date: Sat, 19 Nov 2016 17:07:50 +0100
X-Google-Sender-Auth: QpUdU1huXj_QCt0gzu_99ygXODQ
Message-ID: 
To: Jeffrey Haas 
Content-Type: multipart/alternative; boundary=94eb2c1914ceeffd9f0541a99fb6
Archived-At: 
Cc: "idr@ietf.org" , "grow@ietf.org" 
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 19 Nov 2016 16:07:54 -0000

--94eb2c1914ceeffd9f0541a99fb6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

If you think this is too much then let's support new message type (for
example Advisory) which will be able to be sent ahead of planned admin
shutdown with all details necessary and be done.

Regards,
R.

On Sat, Nov 19, 2016 at 4:56 PM, Jeffrey Haas  wrote:

>
> On Nov 19, 2016, at 10:48 AM, Robert Raszuk  wrote:
>
> > What would the distinction between admin shutdown (clear) vs. info-read
> the friendly message be?
>
> Ordering ...
>
> =E2=80=8BYou define a subcode or even new code as NOTIFICATION INFO and t=
hat is by
> the spec NOT to trigger the TCP reset .. before you get subsequent error
> code and subcode (when applicable).
>
>
> A change to use a NOTIFICATION message to *NOT* reset the TCP session is =
a
> rather large deviation from 4271.
>
> I would not be supportive of that.
>
> -- Jeff
>
>

--94eb2c1914ceeffd9f0541a99fb6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



If you thi=
nk this is too much then let's support new message type (for example Ad=
visory) which will be able to be sent ahead of planned admin shutdown with =
all details necessary and be done.=C2=A0

=

Regards,
R.
On Sat, Nov 19, 2016 at 4:56 PM, Jeffrey Haas <=
span dir=3D"ltr"><jh=
aas@pfrc.org> wrote:

On Nov 19, 2016, at 10:48 AM, Robert Raszuk <robert@raszuk.net> wrote:
=
> What would the distinction between admin shutdown (clear) vs. info-rea=
d the friendly message be? =C2=A0

=
Ordering ...=C2=A0

=E2=80=8BYou define a =
subcode or even new code as NOTIFICATION INFO and that is by the spec NOT t=
o trigger the TCP reset .. before you get subsequent error code and subcode=
 (when applicable).=C2=A0

A change to use a NOTIFICATION message to *NOT* reset the TCP sess=
ion is a rather large deviation from 4271.

I would=
 not be supportive of that.

-- Jeff

=




--94eb2c1914ceeffd9f0541a99fb6--


From nobody Sat Nov 19 08:58:26 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6EC1299C5; Sat, 19 Nov 2016 08:58:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.432
X-Spam-Level: 
X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_SOFTFAIL=0.665] 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 YMAKu29P1u7o; Sat, 19 Nov 2016 08:58:20 -0800 (PST)
Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (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 47A3E1299BD; Sat, 19 Nov 2016 08:58:20 -0800 (PST)
Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1c88y2-0009Lq-94 (job@us.ntt.net); Sat, 19 Nov 2016 16:58:19 +0000
Date: Sat, 19 Nov 2016 17:58:14 +0100
From: Job Snijders 
To: Robert Raszuk 
Message-ID: <20161119165814.GE47336@dhcp-9d92.meeting.ietf.org>
References:   <58306620.4000308@foobar.org> <319AD952-C571-4085-8D56-C06A51F021E3@domino.org> <06F3A369-5B8E-4C34-BC52-7AB8B99C2048@pfrc.org>  <2F4BF4C2-3AFA-41D8-991D-2EEB3A0D1721@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: Mutt/1.7.1 (2016-10-04)
Archived-At: 
Cc: "idr@ietf.org" , "grow@ietf.org" 
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 19 Nov 2016 16:58:21 -0000

On Sat, Nov 19, 2016 at 05:07:50PM +0100, Robert Raszuk wrote:
> If you think this is too much then let's support new message type (for
> example Advisory) which will be able to be sent ahead of planned admin
> shutdown with all details necessary and be done.

"Shutdown" and "advisory"-style messaging are not mutually exclusive.
They do not overlap in terms of technology and usage. Shutdown is useful
for when the session goes down, 'advisory' can be useful when the
session is still up.

An advantage of the 'shutdown' message is that there is an absolute
correlation between the message contained in the Shutdown Communication
and the (in cisco-speak) "ROUTING-BGP-5-ADJCHANGE" event itself.

"Shutdown" fits neatly into the existing BGP framework and has a low
barrier to entry for implementors.

Regards,

Job


From nobody Sat Nov 19 08:59:01 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E99C1299C4 for ; Sat, 19 Nov 2016 08:58:58 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lamehost-it.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 now3JTFLv9vC for ; Sat, 19 Nov 2016 08:58:55 -0800 (PST)
Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c: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 2C0D11299C5 for ; Sat, 19 Nov 2016 08:58:55 -0800 (PST)
Received: by mail-wm0-x22f.google.com with SMTP id a197so82880512wmd.0 for ; Sat, 19 Nov 2016 08:58:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lamehost-it.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XqGsvvo3Hif8T92LsEhdktXFBIwZVxtTUuafYN7n7uE=; b=U6hGVi+Ipv+/mL6ad82Sk1KJty1NKCaJL3SP2BxsWLUAOxqwvbVm5bxWDzdHeiZOs6 NyWQD3PnHJOI4GqmnRU/2DhPEqGx+cvl8ms/GpSQQg8rG7Badv13D652XtS7xhOB2eGU 9Z34u+QxCNdLeNmuz95shlkdPPEeGqf68aiB01P8w4Q7g1Zp91+uCZ0asDgLgNVU4TwU X03AUkpTHvSufs7X9UWp7UU26TwRTkQSizFkozpXibO7HPwLKzRONj9uBGdRoz8QFFvJ dYv7aB/H/qa1qp4HyPxkcQQEJUqjZVpe9Bmir67OiwsRVXZtQCNyA5bJPcrZRsBwoBUQ R7lQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XqGsvvo3Hif8T92LsEhdktXFBIwZVxtTUuafYN7n7uE=; b=mnsImUCoxfRws7BJRZ3xKE/OgsC22zm5DpPJo/oojM11YwZ7vcdRx+ZBVjrKLZvfBR nhgWRCKUIB7/D4C8ILy/4ypF5hYVZ0kx50I1Fg978M6qkcmX96nFiosd3aos0FJ3Vdak g7jYuvcAP5gD/5hHB1GiSmIjAufWFFCO26Xsb4EthA4UCkRJcfcK9R73ktqTYasPgqzT 3UNFMfs2jkwpgJVqqskU0BnMZ6WUhgE1KnqS5OHGcsy9rZLzafoe8F8WxT/+mUmIbcmw d2tB6jpnsIGedoUYnNuGvW6lbza/ECllnCXPHAiJYLDQJ4ydN6UNTkMgdoV5rXgY8MPs dfZg==
X-Gm-Message-State: AKaTC03CwtQBzodKoEWhfl79pQt2Fa8iSjWf8BhlRMn0uVQV4YIBa3jJEMPUyTzDRp8SgJDz9mJMoziaVC8Zyw==
X-Received: by 10.46.71.18 with SMTP id u18mr2972624lja.67.1479574733700; Sat, 19 Nov 2016 08:58:53 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.202.14 with HTTP; Sat, 19 Nov 2016 08:58:52 -0800 (PST)
X-Originating-IP: [79.24.77.5]
In-Reply-To: 
References: <20161116061556.GG1073@dhcp-9341.meeting.ietf.org> <20161116105535.GW79185@Space.Net> <1479295774707.77855@dacor.de> <20161116113849.udbrfvdhaj3be7nx@bongo.bofh.it> <20161116130110.GK1073@dhcp-9341.meeting.ietf.org> <20161116134707.GP24817@gir.theapt.org>      <58306620.4000308@foobar.org> <319AD952-C571-4085-8D56-C06A51F021E3@domino.org> 
From: Marco Marzetti 
Date: Sat, 19 Nov 2016 17:58:52 +0100
Message-ID: 
To: Robert Raszuk 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "idr@ietf.org" , "grow@ietf.org" , Peter Hessler 
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 19 Nov 2016 16:58:58 -0000

Robert,

This is a wonderful easy to use solution to send informational
messages to your neighbor for a very specific case (sesssion shutdown)
It is so easy that i wonder why we're discussing for so lo long.

Changing operational patterns or having well-formatted messages is out
of the scope and don't relate to the draft.
What i mean is you can't say the proposal is not good just because
stupid people do stupid things in other circumstances (like sending
maintenance alerts)

Regards


On Sat, Nov 19, 2016 at 4:10 PM, Robert Raszuk  wrote:
>
> Leave alone that this all makes sense to be sent well before the planned
> admin shutdown so the other side is first aware of it and can manually or
> automatically take users off that peering.
>
> But looks like we are light years away from such basic thing here ....
>
> On Sat, Nov 19, 2016 at 3:59 PM, Neil J. McRae  wrote:
>>
>> We shouldn't be encouraging folks to build networks that for routine
>> events we then require more manual intervention when it's unwarranted.
>>
>> Why does it need to be free format?
>>
>> How many reasons or signals does one need to send in a message like this?
>> Just thinking whilst I wait for the till to be rebooted in WHSmiths -  I can
>> think of 3 different cease reasons (and 1 of them is a form of the other).
>> De-peer; maintenance;  problem call/contact us - what else ? Enough to
>> trigger info is in the existing config to trigger you to the right
>> information on peeringdb or other local database.
>>
>> Cheers,
>> Neil
>>
>> Sent from my iPhone
>>
>> > On 19 Nov 2016, at 14:48, Nick Hilliard  wrote:
>> >
>> > Robert Raszuk wrote:
>> >> Just to be clear: I am also OK with free form text with the few well
>> >> known and easy to machine parse keywords (in it).
>> >
>> > the field should either be fully structured or free-form, and the
>> > explicit intent of this draft is free form, utf8.  Having a half-way
>> > house is in nobody's interest because the discussion will then rat-hole
>> > on defining a new ad-hoc quasi-language, and the draft - if it ever gets
>> > turned into running code - will end up being a protocol soup which
>> > no-one will find satisying.
>> >
>> > If you feel it should be fully structured, then please feel free to
>> > submit an alternative draft to that effect.
>> >
>> > Nick
>
>



-- 
Marco


From nobody Sat Nov 19 09:23:27 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D5C71299E5; Sat, 19 Nov 2016 09:23:21 -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=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 xHD6Jsn1rMvl; Sat, 19 Nov 2016 09:23:19 -0800 (PST)
Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00107.outbound.protection.outlook.com [40.107.0.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 064651295AE; Sat, 19 Nov 2016 09:23:18 -0800 (PST)
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=LOSHJdixXssZ1F9YzwWY70GGJY6DK/Djvt2WwJLLjlk=; b=laG6XMJiCI6LFfPT3ra5oMNfSrRHHkEwSBaasbCcdtLufHhzkxKNcjbHg7y3wmhiX92Rhx9F4kftrDofsieeYyZ5VJ8dzSrqwTNVupGjUpVmahFcoIgHZcBEev91CoNYCIh77e56p1kh8oDhfwfSYm0u1ZiRYbij8dnSuV32RS4=
Received: from AM4PR03MB1425.eurprd03.prod.outlook.com (10.164.77.155) by AM4PR03MB1428.eurprd03.prod.outlook.com (10.164.77.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.721.10; Sat, 19 Nov 2016 17:23:15 +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.0721.017; Sat, 19 Nov 2016 17:23:15 +0000
From: "Neil J. McRae" 
To: Marco Marzetti 
Thread-Topic: [GROW] [Idr] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
Thread-Index: AQHSQmy0+8tbbqf0dkKKv6LUENTaKKDgV5qAgAAFw4CAAADCgIAABOAAgAADF6uAAAMOAIAAHmsAgAAG0Is=
Date: Sat, 19 Nov 2016 17:23:15 +0000
Message-ID: <058F756D-3A68-4AA6-A9DC-63A1BF9A5184@domino.org>
References: <20161116061556.GG1073@dhcp-9341.meeting.ietf.org> <20161116105535.GW79185@Space.Net> <1479295774707.77855@dacor.de> <20161116113849.udbrfvdhaj3be7nx@bongo.bofh.it> <20161116130110.GK1073@dhcp-9341.meeting.ietf.org> <20161116134707.GP24817@gir.theapt.org>      <58306620.4000308@foobar.org> <319AD952-C571-4085-8D56-C06A51F021E3@domino.org> , 
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=neil@domino.org; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [81.139.118.83]
x-microsoft-exchange-diagnostics: 1; AM4PR03MB1428; 7:NjV5VTPk6edBFFvOGA94xUHLyZns6Q7lqyr5QVgDG867ktGK8iKF08pOo++zzIWjBrGLg2D71mL7gcHMic6SWBsxMV25xmM3mDd9+G+QJnB+0l7AM0f7i1kXMVespNpYELm9PBo6HwnC9bdG6NdE/Dik+FOqRKCl7XY+EC4qQ3vtft6GQt8JisVJ4E7WoyZltNpqrCPJKIuT8zYUIrTkRpZJHbQsvw0XyWKZFeNEuiL+Nz7vBuxWRKQfpv9SJjSChSbuK0Cq6wErBo73kpRC6dkfYO60jGqdvwms7m/zUb+iH849wu4JkpyTUd8EJBshP3DLgXD6iSQoTWBuQ9CBbIzA81XHsODr96Zj7fjj2HU=
x-ms-office365-filtering-correlation-id: 3eeda98c-5d3d-4bd7-10f8-08d410a0bf11
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:AM4PR03MB1428;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040307)(6060326)(6045199)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(6061324)(2016111802025)(6043046); SRVR:AM4PR03MB1428; BCL:0; PCL:0; RULEID:; SRVR:AM4PR03MB1428; 
x-forefront-prvs: 0131D22242
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(377454003)(24454002)(199003)(5660300001)(6512003)(110136003)(6916009)(2950100002)(6506003)(38730400001)(33656002)(5003630100001)(561944003)(87936001)(81166006)(81156014)(68736007)(8936002)(76176999)(101416001)(106356001)(50986999)(229853002)(189998001)(54356999)(105586002)(97736004)(106116001)(2900100001)(66066001)(36756003)(77096005)(3280700002)(2906002)(92566002)(4326007)(3660700001)(122556002)(8676002)(86362001)(6116002)(102836003)(230783001)(7846002)(93886004)(3846002)(305945005)(83716003)(7736002)(82746002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR03MB1428; H:AM4PR03MB1425.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  MX:1; A:0; LANG:en; 
received-spf: None (protection.outlook.com: domino.org does not designate permitted sender hosts)
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: 19 Nov 2016 17:23:15.1320 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 398f3eb4-3394-48e7-885c-de1ab2a9cf2e
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR03MB1428
Archived-At: 
Cc: "idr@ietf.org" , "grow@ietf.org" , Peter Hessler , Robert Raszuk 
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 19 Nov 2016 17:23:21 -0000

It's a wonderfully useless solution when it could be a wonderfully useful s=
olution - it's just more  operational noise that we already have and we wil=
l start filtering like everything else.=20

Neil.=20

> On 19 Nov 2016, at 16:58, Marco Marzetti  wrote:
>=20
> Robert,
>=20
> This is a wonderful easy to use solution to send informational
> messages to your neighbor for a very specific case (sesssion shutdown)
> It is so easy that i wonder why we're discussing for so lo long.
>=20
> Changing operational patterns or having well-formatted messages is out
> of the scope and don't relate to the draft.
> What i mean is you can't say the proposal is not good just because
> stupid people do stupid things in other circumstances (like sending
> maintenance alerts)
>=20
> Regards
>=20
>=20
>> On Sat, Nov 19, 2016 at 4:10 PM, Robert Raszuk  wrote=
:
>>=20
>> Leave alone that this all makes sense to be sent well before the planned
>> admin shutdown so the other side is first aware of it and can manually o=
r
>> automatically take users off that peering.
>>=20
>> But looks like we are light years away from such basic thing here ....
>>=20
>>> On Sat, Nov 19, 2016 at 3:59 PM, Neil J. McRae  wrote:
>>>=20
>>> We shouldn't be encouraging folks to build networks that for routine
>>> events we then require more manual intervention when it's unwarranted.
>>>=20
>>> Why does it need to be free format?
>>>=20
>>> How many reasons or signals does one need to send in a message like thi=
s?
>>> Just thinking whilst I wait for the till to be rebooted in WHSmiths -  =
I can
>>> think of 3 different cease reasons (and 1 of them is a form of the othe=
r).
>>> De-peer; maintenance;  problem call/contact us - what else ? Enough to
>>> trigger info is in the existing config to trigger you to the right
>>> information on peeringdb or other local database.
>>>=20
>>> Cheers,
>>> Neil
>>>=20
>>> Sent from my iPhone
>>>=20
>>>> On 19 Nov 2016, at 14:48, Nick Hilliard  wrote:
>>>>=20
>>>> Robert Raszuk wrote:
>>>>> Just to be clear: I am also OK with free form text with the few well
>>>>> known and easy to machine parse keywords (in it).
>>>>=20
>>>> the field should either be fully structured or free-form, and the
>>>> explicit intent of this draft is free form, utf8.  Having a half-way
>>>> house is in nobody's interest because the discussion will then rat-hol=
e
>>>> on defining a new ad-hoc quasi-language, and the draft - if it ever ge=
ts
>>>> turned into running code - will end up being a protocol soup which
>>>> no-one will find satisying.
>>>>=20
>>>> If you feel it should be fully structured, then please feel free to
>>>> submit an alternative draft to that effect.
>>>>=20
>>>> Nick
>>=20
>>=20
>=20
>=20
>=20
> --=20
> Marco


From nobody Sat Nov 19 11:41:46 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59BD11295E6; Sat, 19 Nov 2016 11:41:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.432
X-Spam-Level: 
X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_SOFTFAIL=0.665] 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 J3th3N0hpOKN; Sat, 19 Nov 2016 11:41:44 -0800 (PST)
Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (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 11E7C129576; Sat, 19 Nov 2016 11:41:44 -0800 (PST)
Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1c8BW9-0008fl-SP (job@us.ntt.net); Sat, 19 Nov 2016 19:41:43 +0000
Date: Sat, 19 Nov 2016 20:41:38 +0100
From: Job Snijders 
To: "idr@ietf.org" , "grow@ietf.org" 
Message-ID: <20161119194138.GG47336@dhcp-9d92.meeting.ietf.org>
References:      <58306620.4000308@foobar.org> <319AD952-C571-4085-8D56-C06A51F021E3@domino.org>   <058F756D-3A68-4AA6-A9DC-63A1BF9A5184@domino.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <058F756D-3A68-4AA6-A9DC-63A1BF9A5184@domino.org>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.7.1 (2016-10-04)
Archived-At: 
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 19 Nov 2016 19:41:45 -0000

On Sat, Nov 19, 2016 at 05:23:15PM +0000, Neil J. McRae wrote:
> It's a wonderfully useless solution when it could be a wonderfully
> useful solution - it's just more  operational noise that we already
> have and we will start filtering like everything else. 

What's really useless is hyperbole argumentation. :-) Don't forget to
recognise that your network operations might differ from how other
people operate their network.

A common pattern:

    supplier: "2 weeks from now at 18:00 UTC we will do maintenance XYZ on router ABC, this work is tracked in V-NOC-24789244"
    *two weeks pass*
    *supplier starts the work*
    *customer sees BGP session with router ABC go down*
    customer calls supplier's NOC: "hey my session is down, whats up!?"

If in the above scenario the customer had seen "V-NOC-24789244 maintenace started" in their syslog (where they started their
investigation), the customer would search for the V-NOC-24789244 string
in their mailbox and all details would become clear. I think this is
useful and a good starting point.

I suspect that where Neil is coming from, the customer would have
already parsed the maintenance notification 2 weeks before the
maintenance work, and added that to their organisational-wide calendar,
pre-silenced alerts, drained the traffic away, etc.

The "shutdown" draft is not a replacement for efforts such as
https://www.maintenancemanager.org/ - but maybe, when "shutdown" is more
ubiquitously available, it could be a component in such maintenance
manager toolchains.

Maybe in 2 or 3 years time we'll revisit the topic and based on that
operational experience define a taxonomy and create a structured
approach. Maybe the structured approach will be entirely out-of-band
(companies posting yang to each others' maintenance API endpoints?).  I
think the free form approach is an excellent starting point to see (and
immediately benefit) how a tool like this is used in the wild.

Kind regards,

Job


From nobody Sat Nov 19 12:26:35 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3C63129493; Sat, 19 Nov 2016 12:26:32 -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=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 vZp89vWHGw0R; Sat, 19 Nov 2016 12:26:30 -0800 (PST)
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40120.outbound.protection.outlook.com [40.107.4.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 349A0129444; Sat, 19 Nov 2016 12:26:30 -0800 (PST)
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=HtnS7BaCX6RQNNosc/tf66K01B6Tlp3qR2yUkC5enNA=; b=nB1D3cxAvw5QuLs4ILBUGNvcd7zgikNKKqL5MdMxOnBPX8QuF0Y2VG1yDBl41T7QRi7xL1NAn9CZP7uaT6HBxZiC7Hc4wmdlamlh+kdMda8HlG8l+4At1U0kQlSNg1ul4SUsmXrxvzci39BuzaQ50BdnFLNoxtiluGneKIwre5Y=
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.721.10; Sat, 19 Nov 2016 20:26:26 +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.0721.017; Sat, 19 Nov 2016 20:26:25 +0000
From: "Neil J. McRae" 
To: Job Snijders 
Thread-Topic: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
Thread-Index: AQHSQpz7gCGRQsDpy0e2Wz93nHcpRqDgwSzZ
Date: Sat, 19 Nov 2016 20:26:25 +0000
Message-ID: <87DDAB88-78AC-431A-ABE7-55249BF5D654@domino.org>
References:      <58306620.4000308@foobar.org> <319AD952-C571-4085-8D56-C06A51F021E3@domino.org>   <058F756D-3A68-4AA6-A9DC-63A1BF9A5184@domino.org>, <20161119194138.GG47336@dhcp-9d92.meeting.ietf.org>
In-Reply-To: <20161119194138.GG47336@dhcp-9d92.meeting.ietf.org>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=neil@domino.org; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [188.29.164.72]
x-microsoft-exchange-diagnostics: 1; AM4PR03MB1427; 7:SGslck59Qs+gIydbNEpQgG3dSMs/tDNgYFBQfZ9bi5sH/5SGeCXEZ5Gqs5FbsKjWL2pQIBI11fom7xjy4ymHkPHhokQVnIYuikWQf1hlcs0Dmrr7LOd3u0Y8ZE/SceJ/4Psd4ESUy1/VdJnZ7ohIj9k9BcmQdrtG124TPYvlosnTct3DMhr/51I4Do8um9Spq2+w3QKd8h4xaTxBfNBzBsW7AUzez/6gmuYC2wS8Gr1iLdFk/eaXm32BZgy+P5QDeH4S2Bt8xAIKIxAyFFXFp2wyWyFmcVt0SCCfuqFcoAqVMIb7GihuXqCERu82r4VLWos3EMTPcOFrjiDzpJJLcEEM7BnLVuwfOR3fa8pZT7U=
x-ms-office365-filtering-correlation-id: c1fed6ea-e1f8-4b83-fe9e-08d410ba5600
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:AM4PR03MB1427;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6060326)(6040307)(6045199)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(6061324)(2016111802025)(6043046); SRVR:AM4PR03MB1427; BCL:0; PCL:0; RULEID:; SRVR:AM4PR03MB1427; 
x-forefront-prvs: 0131D22242
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(24454002)(189002)(199003)(6916009)(2950100002)(4326007)(2906002)(3280700002)(110136003)(3660700001)(122556002)(102836003)(6116002)(3846002)(97736004)(106116001)(305945005)(7846002)(7736002)(5660300001)(36756003)(189998001)(106356001)(105586002)(8676002)(33656002)(76176999)(54356999)(101416001)(50986999)(229853002)(83716003)(77096005)(81156014)(66066001)(6506003)(87936001)(8936002)(81166006)(82746002)(6512003)(38730400001)(68736007)(230783001)(93886004)(86362001)(2900100001)(92566002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR03MB1427; H:AM4PR03MB1425.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  MX:1; A:0; LANG:en; 
received-spf: None (protection.outlook.com: domino.org does not designate permitted sender hosts)
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: 19 Nov 2016 20:26:25.7999 (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: 
Cc: "idr@ietf.org" , "grow@ietf.org" 
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 19 Nov 2016 20:26:33 -0000

I just wish I thought we had the luxury of lazy operations like this!

Neil=20

> On 19 Nov 2016, at 19:41, Job Snijders  wrote:
>=20
>> On Sat, Nov 19, 2016 at 05:23:15PM +0000, Neil J. McRae wrote:
>> It's a wonderfully useless solution when it could be a wonderfully
>> useful solution - it's just more  operational noise that we already
>> have and we will start filtering like everything else.=20
>=20
> What's really useless is hyperbole argumentation. :-) Don't forget to
> recognise that your network operations might differ from how other
> people operate their network.
>=20
> A common pattern:
>=20
>    supplier: "2 weeks from now at 18:00 UTC we will do maintenance XYZ on=
 router ABC, this work is tracked in V-NOC-24789244"
>    *two weeks pass*
>    *supplier starts the work*
>    *customer sees BGP session with router ABC go down*
>    customer calls supplier's NOC: "hey my session is down, whats up!?"
>=20
> If in the above scenario the customer had seen "V-NOC-24789244 maintenace=
 started" in their syslog (where they started their
> investigation), the customer would search for the V-NOC-24789244 string
> in their mailbox and all details would become clear. I think this is
> useful and a good starting point.
>=20
> I suspect that where Neil is coming from, the customer would have
> already parsed the maintenance notification 2 weeks before the
> maintenance work, and added that to their organisational-wide calendar,
> pre-silenced alerts, drained the traffic away, etc.
>=20
> The "shutdown" draft is not a replacement for efforts such as
> https://www.maintenancemanager.org/ - but maybe, when "shutdown" is more
> ubiquitously available, it could be a component in such maintenance
> manager toolchains.
>=20
> Maybe in 2 or 3 years time we'll revisit the topic and based on that
> operational experience define a taxonomy and create a structured
> approach. Maybe the structured approach will be entirely out-of-band
> (companies posting yang to each others' maintenance API endpoints?).  I
> think the free form approach is an excellent starting point to see (and
> immediately benefit) how a tool like this is used in the wild.
>=20
> Kind regards,
>=20
> Job
>=20
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr


From nobody Sat Nov 19 13:16:44 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B45F0129626; Sat, 19 Nov 2016 13:16:40 -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 cX8sZP3b8Fig; Sat, 19 Nov 2016 13:16:39 -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 C922D12947C; Sat, 19 Nov 2016 13:16:38 -0800 (PST)
X-Envelope-To: grow@ietf.org
Received: from crumpet.local (noc.net.cablecomm.ie [92.61.192.169]) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id uAJLGWvL049824 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 19 Nov 2016 21:16:32 GMT (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.ibn.ie: Host noc.net.cablecomm.ie [92.61.192.169] claimed to be crumpet.local
Message-ID: <5830C12E.6000804@foobar.org>
Date: Sat, 19 Nov 2016 21:16:30 +0000
From: Nick Hilliard 
User-Agent: Postbox 5.0.7 (Macintosh/20161117)
MIME-Version: 1.0
To: "Neil J. McRae" 
References:      <58306620.4000308@foobar.org> <319AD952-C571-4085-8D56-C06A51F021E3@domino.org>   <058F756D-3A68-4AA6-A9DC-63A1BF9A5184@domino.org>, <20161119194138.GG47336@dhcp-9d92.meeting.ietf.org> <87DDAB88-78AC-431A-ABE7-55249BF5D654@domino.org>
In-Reply-To: <87DDAB88-78AC-431A-ABE7-55249BF5D654@domino.org>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: "idr@ietf.org" , "grow@ietf.org" 
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 19 Nov 2016 21:16:41 -0000

Neil J. McRae wrote:
> I just wish I thought we had the luxury of lazy operations like this!

there are more places in heaven and earth, Neil, including many places
where automation makes no sense and many other places where unstructured
text would be a useful tool in the operator's box.  Just because BT
wouldn't use this, that doesn't invalidate its utility.

Nick


From nobody Sat Nov 19 13:29:10 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BABF51294B1; Sat, 19 Nov 2016 13:29:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.432
X-Spam-Level: 
X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_SOFTFAIL=0.665] 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 ehFCoAWOBsM9; Sat, 19 Nov 2016 13:29:05 -0800 (PST)
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 F239E12946D; Sat, 19 Nov 2016 13:29:04 -0800 (PST)
Received: by mail3.mlpsca01.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1c8DBy-0009R3-AD (job@us.ntt.net); Sat, 19 Nov 2016 21:28:59 +0000
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Job Snijders 
X-Mailer: iPhone Mail (14C5077b)
In-Reply-To: <5830C12E.6000804@foobar.org>
Date: Sat, 19 Nov 2016 22:28:53 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <4CD759EA-1A10-4EC6-A363-46F56CB545C6@ntt.net>
References:      <58306620.4000308@foobar.org> <319AD952-C571-4085-8D56-C06A51F021E3@domino.org>   <058F756D-3A68-4AA6-A9DC-63A1BF9A5184@domino.org> <20161119194138.GG47336@dhcp-9d92.meeting.ietf.org> <87DDAB88-78AC-431A-ABE7-55249BF5D654@domino.org> <5830C12E.6000804@foobar.org>
To: Nick Hilliard 
Archived-At: 
Cc: "idr@ietf.org" , "grow@ietf.org" 
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 19 Nov 2016 21:29:06 -0000

I'd argue that, even when someone has no interest to use the Shutdown Commun=
ications sent by others, they can benefit and save time by using the feature=
 to inform their customers or peers of shutdown reasons. Sending and receivi=
ng are two separate considerations.

Kind regards,

Job

> On 19 Nov 2016, at 22:16, Nick Hilliard  wrote:
>=20
> Neil J. McRae wrote:
>> I just wish I thought we had the luxury of lazy operations like this!
>=20
> there are more places in heaven and earth, Neil, including many places
> where automation makes no sense and many other places where unstructured
> text would be a useful tool in the operator's box.  Just because BT
> wouldn't use this, that doesn't invalidate its utility.
>=20
> Nick
>=20


From nobody Sat Nov 19 13:58:15 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45D9C12711D; Sat, 19 Nov 2016 13:58:14 -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 yqMzGgaqlTi4; Sat, 19 Nov 2016 13:58:13 -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 9B5201294B4; Sat, 19 Nov 2016 13:58:11 -0800 (PST)
X-Envelope-To: grow@ietf.org
Received: from crumpet.local (noc.net.cablecomm.ie [92.61.192.169]) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id uAJLw5ET050911 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 19 Nov 2016 21:58:05 GMT (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.ibn.ie: Host noc.net.cablecomm.ie [92.61.192.169] claimed to be crumpet.local
Message-ID: <5830CAEB.7070400@foobar.org>
Date: Sat, 19 Nov 2016 21:58:03 +0000
From: Nick Hilliard 
User-Agent: Postbox 5.0.7 (Macintosh/20161117)
MIME-Version: 1.0
To: "Neil J. McRae" 
References:      <58306620.4000308@foobar.org> <319AD952-C571-4085-8D56-C06A51F021E3@domino.org>   <058F756D-3A68-4AA6-A9DC-63A1BF9A5184@domino.org>, <20161119194138.GG47336@dhcp-9d92.meeting.ietf.org> <87DDAB88-78AC-431A-ABE7-55249BF5D654@domino.org>
In-Reply-To: <87DDAB88-78AC-431A-ABE7-55249BF5D654@domino.org>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: "idr@ietf.org" , "grow@ietf.org" 
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 19 Nov 2016 21:58:14 -0000

Neil J. McRae wrote:
> I just wish I thought we had the luxury of lazy operations like this!

to clarify my previous email, it's a matter of simple economics:
automation needs scale to work properly, and in particular, bgp session
management automation only makes sense for a relatively small number of
networks worldwide because the cost*risk to return ratio is wrong in
most cases.  This is particularly the case because of poor availability
of good tooling.

Regarding the I-D, there are ~55000 asns visible in the dfz, of which
~6000-7000 are non-leaf, and probably less than a thousand where bgp
session automation makes financial sense.  No doubt, as5400/2856 would
be in the top bracket of these and it would make sense for your tooling
teams to automate the hell out of nearly everything, which would
militate against accepting free-form advisory shutdown notices like this
- but then again, BT is atypical in the general scheme of things.
Whether you like it or not, the long tail of ASNs would benefit from a
simple mechanism of this form.

Nick


From nobody Sat Nov 19 14:09:33 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 924EB129466; Sat, 19 Nov 2016 14:09:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level: 
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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 EB3fUANy-MPa; Sat, 19 Nov 2016 14:09:29 -0800 (PST)
Received: from mail-qt0-x244.google.com (mail-qt0-x244.google.com [IPv6:2607:f8b0:400d:c0d::244]) (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 B8CB01293E8; Sat, 19 Nov 2016 14:09:29 -0800 (PST)
Received: by mail-qt0-x244.google.com with SMTP id m48so21860262qta.2; Sat, 19 Nov 2016 14:09:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=HheZR9nsUu6fHPgxH+FYgeigbkek1cpSCyE07DY8+/k=; b=dgnPWZjCdJi+MOHaztN8HRxCZPSyKW4k3+52oYVZFh8FGcH/Xs3Vp4jOP5qlkLwrUS Gc3QQd40zpPAYqRKA313IZcZ0ZuSbUSGzpnjIGPRdItS/rOBk2W5X3h6/ndhH03wJnAs jNIygficBQ9z8zSLzyov0pchJJxMdEckXzwtwmpz4r07f1r/oNLjlqnSk5Vlzqpz3q+u Oq642HNWeIcfZ52jNEdu5aF/KrNTvD1Ojvvk2NEvExbJnanvXBL4HTDMwfHQkKar89HA IfnRsrMwViMjQ0Bcd+ff84eGPtNBtVQUtF2QusuGm28IduvK3O2Vocd2O4Y66SIg67wP v7qQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=HheZR9nsUu6fHPgxH+FYgeigbkek1cpSCyE07DY8+/k=; b=i9Euoy+EeDj96v6G/RPny9CHUMdHsVWzdYKnC5IMEwl5z+ZWG/Yse+Rbqxx7KOjd2x HyFFMEauJxvOWLzbWpln6bmDTsonRGiMJb4TNQHLgrPBWBhjeusDmNV8CH2QapqUKNbE bqG2DI93SOn98k4xWBh5fYzze1YWl6TuaSG95/p1coDH+qFSChtLRXSbjzod99+mwzB1 mbh+YMsn6BqlKukLAy+r7VwocgXjCUm0I6E5JPrEe4hT/s3Dc6cZFSBs+htnstGk7r7y ZJCi9zPiUWjAVvVSF0auV8DOaaNRPwZibqBW+ZXLaPmfsJJZkSBiWXZBxIFjCeadu9BZ 2vbg==
X-Gm-Message-State: AKaTC00WukwLg/zkp7x+FkpNNO3IeQc7cW2x8cvpmcEKQ1cyIwm9JWoL44wrdq5VG44XKB3LkeToiAiueGZe1A==
X-Received: by 10.237.37.77 with SMTP id w13mr4465636qtc.197.1479593368864; Sat, 19 Nov 2016 14:09:28 -0800 (PST)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.140.16.50 with HTTP; Sat, 19 Nov 2016 14:09:27 -0800 (PST)
Received: by 10.140.16.50 with HTTP; Sat, 19 Nov 2016 14:09:27 -0800 (PST)
In-Reply-To: <5830CAEB.7070400@foobar.org>
References:      <58306620.4000308@foobar.org> <319AD952-C571-4085-8D56-C06A51F021E3@domino.org>   <058F756D-3A68-4AA6-A9DC-63A1BF9A5184@domino.org> <20161119194138.GG47336@dhcp-9d92.meeting.ietf.org> <87DDAB88-78AC-431A-ABE7-55249BF5D654@domino.org> <5830CAEB.7070400@foobar.org>
From: Robert Raszuk 
Date: Sat, 19 Nov 2016 23:09:27 +0100
X-Google-Sender-Auth: vMblnZxW7BMCqhYk-g5qWZSZPwQ
Message-ID: 
To: Nick Hilliard 
Content-Type: multipart/alternative; boundary=001a114108ea29d0570541aeade2
Archived-At: 
Cc: "idr@ietf.org" , grow@ietf.org
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 19 Nov 2016 22:09:31 -0000

--001a114108ea29d0570541aeade2
Content-Type: text/plain; charset=UTF-8

Nick,

Those who do not automate may not even look at the syslog at all. I  those
cases as Jared said adding it to sh bgp neig may help with the risk of
having the screen scraping parsers broken.

As to what's the point of this discussion ... is to not change format of
NOTFICATION as per 4271 yet define someting even if not structured to be
machine readable.

Thx
R.

On Nov 20, 2016 6:58 AM, "Nick Hilliard"  wrote:

> Neil J. McRae wrote:
> > I just wish I thought we had the luxury of lazy operations like this!
>
> to clarify my previous email, it's a matter of simple economics:
> automation needs scale to work properly, and in particular, bgp session
> management automation only makes sense for a relatively small number of
> networks worldwide because the cost*risk to return ratio is wrong in
> most cases.  This is particularly the case because of poor availability
> of good tooling.
>
> Regarding the I-D, there are ~55000 asns visible in the dfz, of which
> ~6000-7000 are non-leaf, and probably less than a thousand where bgp
> session automation makes financial sense.  No doubt, as5400/2856 would
> be in the top bracket of these and it would make sense for your tooling
> teams to automate the hell out of nearly everything, which would
> militate against accepting free-form advisory shutdown notices like this
> - but then again, BT is atypical in the general scheme of things.
> Whether you like it or not, the long tail of ASNs would benefit from a
> simple mechanism of this form.
>
> Nick
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>

--001a114108ea29d0570541aeade2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Nick,


Those who do not automate may not even look at the syslog at=
 all. I=C2=A0 those cases as Jared said adding it to sh bgp neig may help w=
ith the risk of having the screen scraping parsers broken.


As to what's the point of this discussion ... is to not =
change format of NOTFICATION as per 4271 yet define someting even if not st=
ructured to be machine readable.


Thx

R.



On Nov 20, 2016 6=
:58 AM, "Nick Hilliard" <ni=
ck@foobar.org> wrote:
Neil J. McRae wrote:

> I just wish I thought we had the luxury of lazy operations like this!<=
br>


to clarify my previous email, it's a matter of simple economics:

automation needs scale to work properly, and in particular, bgp session

management automation only makes sense for a relatively small number of

networks worldwide because the cost*risk to return ratio is wrong in

most cases.=C2=A0 This is particularly the case because of poor availabilit=
y

of good tooling.



Regarding the I-D, there are ~55000 asns visible in the dfz, of which

~6000-7000 are non-leaf, and probably less than a thousand where bgp

session automation makes financial sense.=C2=A0 No doubt, as5400/2856 would=


be in the top bracket of these and it would make sense for your tooling

teams to automate the hell out of nearly everything, which would

militate against accepting free-form advisory shutdown notices like this
- but then again, BT is atypical in the general scheme of things.

Whether you like it or not, the long tail of ASNs would benefit from a

simple mechanism of this form.



Nick



_______________________________________________

Idr mailing list

Idr@ietf.org

https://www.ietf.org/mailman/listinfo/idr




--001a114108ea29d0570541aeade2--


From nobody Sun Nov 20 01:54:25 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C1821295BC for ; Sun, 20 Nov 2016 01:54:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.432
X-Spam-Level: 
X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_SOFTFAIL=0.665] 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 ajhK_Zv9Nw3r for ; Sun, 20 Nov 2016 01:54:23 -0800 (PST)
Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (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 4A85C1295A4 for ; Sun, 20 Nov 2016 01:54:23 -0800 (PST)
Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1c8OpJ-0007oo-Sj (job@us.ntt.net); Sun, 20 Nov 2016 09:54:22 +0000
Date: Sun, 20 Nov 2016 10:54:18 +0100
From: Job Snijders 
To: Robert Raszuk 
Message-ID: <20161120095418.GA1121@Vurt.local>
References: <20161116061556.GG1073@dhcp-9341.meeting.ietf.org> <20161117013640.GB6217@pfrc.org> <16426_1479400131_582DDAC3_16426_1669_1_53C29892C857584299CBF5D05346208A1EC87201@OPEXCNORM2F.corporate.adroot.infra.ftgroup> <20161118004548.GK1072@dhcp-9341.meeting.ietf.org> <16418_1479457940_582EBC93_16418_290_1_53C29892C857584299CBF5D05346208A1EC8DEA5@OPEXCLILM21.corporate.adroot.infra.ftgroup>  <13357_1479459134_582EC13E_13357_5786_1_53C29892C857584299CBF5D05346208A1EC8FF18@OPEXCLILM21.corporate.adroot.infra.ftgroup> <37224750-4065-40E3-B6F4-571DED698563@cisco.com> <20161119103226.GN1072@dhcp-9341.meeting.ietf.org> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.7.1 (2016-10-04)
Archived-At: 
Cc: idr@ietf.org
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 20 Nov 2016 09:54:24 -0000

Hi Robert,

On Sat, Nov 19, 2016 at 03:27:09PM +0100, Robert Raszuk wrote:
> RFC4271 says:
> 
>   0                   1                   2                   3
>   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  | Error code    | Error subcode |   Data (variable)             |
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> ...
> 
> Note that the length of the Data field can be determined from
> the message Length field by the formula:
> 
>   Message Length = 21 + Data Length
> 
> RFC4486 says:
> 
>    If a BGP speaker decides to administratively shut down its peering
>    with a neighbor, then the speaker SHOULD send a NOTIFICATION message
>    with the Error Code Cease and the Error Subcode "Administrative
>    Shutdown".
> 
> That all means there is no guarantee that if you insert length some
> CPEs will not crush even if the length value will be all 0.

By 'length' you mean filling in the "Data (variable)" field?

> That means that in my network where there is 15000 CEs if at least one
> crashes I can not upgrade any longer any PE OS which may be needed for
> other reasons.

If your CE crashes because there is trailing data after a Cease subcode
2, I consider your implementation to be non-compliant with how the rest
of the world understands BGP. Already today one can send you trailing
data after a Subcode 2 Cease NOTIFICATION, I've found no examples of
software which is not capable of handling that.

By using the "A device might crash somewhere"-argument you block any
innovation. Will you withdraw all your active internet-drafts?

> If we are to continue to use subcode 2 let's stay with current 4271
> format and not update 4271 RFC with this proposal.
> 
> Or let's define new cease subcode say "INFO" which will be injected
> only when operator types in a string. That way existing deployments
> are safe and you can enjoy new communication channel (hopefully with
> some well defined keywords :).

The notification message, of all the BGP messages, is uniquely (albeit
crudely) extensible without permission since there is no question of
being "punished" by having the session torn down if you send a
nonconforming message. Might as well admit that and be robust to
noncomforming extensions.

Kind regards,

Job


From nobody Sun Nov 20 01:55:05 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E25F41295BE; Sun, 20 Nov 2016 01:55:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.432
X-Spam-Level: 
X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_SOFTFAIL=0.665] 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 JhZ-nKDhrESE; Sun, 20 Nov 2016 01:55:03 -0800 (PST)
Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (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 2BB1A1295BC; Sun, 20 Nov 2016 01:55:03 -0800 (PST)
Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1c8Opx-0007t8-Un (job@us.ntt.net); Sun, 20 Nov 2016 09:55:02 +0000
Date: Sun, 20 Nov 2016 10:54:59 +0100
From: Job Snijders 
To: Robert Raszuk 
Message-ID: <20161120095459.GB1121@Vurt.local>
References:  <58306620.4000308@foobar.org> <319AD952-C571-4085-8D56-C06A51F021E3@domino.org>   <058F756D-3A68-4AA6-A9DC-63A1BF9A5184@domino.org> <20161119194138.GG47336@dhcp-9d92.meeting.ietf.org> <87DDAB88-78AC-431A-ABE7-55249BF5D654@domino.org> <5830CAEB.7070400@foobar.org> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.7.1 (2016-10-04)
Archived-At: 
Cc: idr@ietf.org, grow@ietf.org
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 20 Nov 2016 09:55:04 -0000

On Sat, Nov 19, 2016 at 11:09:27PM +0100, Robert Raszuk wrote:
> Those who do not automate may not even look at the syslog at all. I
> those cases as Jared said adding it to sh bgp neig may help with the
> risk of having the screen scraping parsers broken.

Hypothetical operators come in all shapes and sizes, but we've had a
show of hands here from a set of actual operators who find this
functionality useful in their daily workflow, and expect their peers
would as well. 

There is a wide range of scenarios that are addressed by the proposal in
it's current form, including:
    
    * An engineer actively troubleshooting a router connected to a large
    Internet Exchange wishing to tell the rest of the peers a human is
    on it (and avoid the mail flood of "you're flapping!")

    * An automated system "enriching" the session termination with ticket
    related metadata to allow a user exploring a log to find context
    
    * A set of default messages that could be implemented by a vendor
    depending on which cli command triggered the shutdown to
    transparently enrich the remote side with information
    
It is essentially an incarnation of the old 'wall' command from UNIX,
with users substituted by peers, and the delivery mechanism being BGP.
The aim is to enable an inter-domain version of:

    # echo "brb, kernel update" | wall

Nothing more.
    
Any implications on screenscrapping are an artifact of implementation,
and vendors seeking a consistent machine-parsable CLI can send the
message directly into the log instead of modifying the output of a CLI
status description command. JunOS is a good example of how
screenscraping can be avoided with their "| output xml" feature.
Shutdown will be just another leaf in such XML output.

This proposal does not aim to solve all challenges of inter-domain
operations orchestration, but to specifically provide a tool to annotate
an unexpected event to ease the triaging process by a human operator. 

In its current form, it provides an ideal fit for this purpose, while
leaving enough flexibility to experiment with structured communications
for those who intend to use BGP for general inter-domain operations
orchestration signaling.

> As to what's the point of this discussion ... is to not change format
> of NOTFICATION as per 4271 yet define someting even if not structured
> to be machine readable.

We're updating 4486, please try to keep up.

Kind regards,

Job


From nobody Sun Nov 20 02:09:23 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 848B912953C; Sun, 20 Nov 2016 02:09:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.432
X-Spam-Level: 
X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_SOFTFAIL=0.665] 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 dHZMYgCo_ZK0; Sun, 20 Nov 2016 02:09:20 -0800 (PST)
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 8148E1294D3; Sun, 20 Nov 2016 02:09:20 -0800 (PST)
Received: by mail3.mlpsca01.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1c8P3n-000E3k-9x (job@us.ntt.net); Sun, 20 Nov 2016 10:09:20 +0000
Date: Sun, 20 Nov 2016 11:09:15 +0100
From: Job Snijders 
To: Robert Raszuk 
Message-ID: <20161120100915.GC1121@Vurt.local>
References: <20161116113849.udbrfvdhaj3be7nx@bongo.bofh.it> <20161116130110.GK1073@dhcp-9341.meeting.ietf.org> <20161116134707.GP24817@gir.theapt.org>      <58306620.4000308@foobar.org> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.7.1 (2016-10-04)
Archived-At: 
Cc: idr@ietf.org, grow@ietf.org
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 20 Nov 2016 10:09:21 -0000

On Sat, Nov 19, 2016 at 03:57:06PM +0100, Robert Raszuk wrote:
> I am not going to argue with few of you here who want free form text
> and do not accept any suggestions.

No, we are just selective in which suggestions we accept. Suggestions
falling short of the mark are countered and discarded.

> But if you can not parse few defined keywords in any free form text to
> enable better automated interpretation of the message I think there is
> more problems here.

This proposal aims to accomplish a simple thing, which is to enrich an
event with additional contextual information and assist in triaging
("This is unexpected, is this a problem?" "Should we embark on a
specific procedure?") in an operator-centric workflow. By keeping it
free form, it allows enough space to experiment with structured
inter-domain signaling, and if operators find this useful a dictionary
of messages can be offered at a later date as an extension based on
operational experience.

It is absolutely is not aiming to act as a generic inter-domain
signaling protocol for operations orchestration.

> TLV within current NOTIFICATION MSG is an overkill so do not count of
> new proposal from me on it. 

Hence this is not TLV, this is LV, already explained here:
https://www.ietf.org/mail-archive/web/idr/current/msg17127.html

> Operational message solved that already.

Operational message expired in September 2012, and as such I do not
consider it an active working group document anymore.

The Operational message does not provide a strong correlation between a
Cease event and some type of additional meta-data. Same reason why
'advisory' and 'shutdown' do not preclude each other.

I'd like to ask the chairs to move 'draft-ietf-idr-operational-message-00' to 'Dead' status.

> Btw how are you going to handle it in IX ? I assume RS peers will not
> get any info if one of the parties they used to get routes from goes
> down and sends free form msg to RS ? Routes will be get withdrawn and
> that's it.

Correct. This is the expected behaviour.

Kind regards,

Job


From nobody Sun Nov 20 02:20:52 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A98F1294C1 for ; Sun, 20 Nov 2016 02:20:51 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, 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=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 ZvJdBmddggvx for ; Sun, 20 Nov 2016 02:20:47 -0800 (PST)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0128.outbound.protection.outlook.com [104.47.0.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 71A7212943F for ; Sun, 20 Nov 2016 02:20:46 -0800 (PST)
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=whrDrdSBksBwHKLhlmLdvLMW5Nn85bt6SjvP7WimfoE=; b=N67LVTOUJwGmkKbj18eXPe3XvkgVrg6J/jUe9KFZW7vTIkVzM6Fvp2AUFhRM4407fr8KNaBm9wCsUrSljz5CMIhhBP4SHuKQ+WkP6jEhAKdLdYMCdR9mtS6Xwlne7kz2zqo4S5nWfvVIktSd30lUAhYbcHLzF/a1+FTo4+5ZTks=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
Received: from pc6 (81.135.210.62) by AM5PR0701MB2996.eurprd07.prod.outlook.com (10.168.156.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.747.5; Sun, 20 Nov 2016 10:20:43 +0000
Message-ID: <016a01d24317$4cd1eaa0$4001a8c0@gateway.2wire.net>
From: t.petch 
To: Nick Hilliard 
References:   <27701_1479159582_582A2F1E_27701_6903_1_53C29892C857584299CBF5D05346208A1EC77FE1@OPEXCLILM21.corporate.adroot.infra.ftgroup> <736EA2CC-3DD1-4F14-96ED-2916E62F6F02@cisco.com> <26709_1479217575_582B11A7_26709_12999_1_53C29892C857584299CBF5D05346208A1EC79584@OPEXCLILM21.corporate.adroot.infra.ftgroup>   <20161116001246.GB27230@pfrc.org> <4EB6222D-86A4-4A83-AF8C-364CB52B8422@juniper.net> <004201d2418b$887208c0$4001a8c0@gateway.2wire.net> <583033B8.5010006@foobar.org>
Date: Sun, 20 Nov 2016 10:17:20 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
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: [81.135.210.62]
X-ClientProxiedBy: DB4PR06CA0006.eurprd06.prod.outlook.com (10.162.49.16) To AM5PR0701MB2996.eurprd07.prod.outlook.com (10.168.156.146)
X-MS-Office365-Filtering-Correlation-Id: e04a738f-ace9-4a93-ffad-08d4112ee2ac
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:AM5PR0701MB2996; 
X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2996; 3:pRGMa13Rkye5pN02X7lhX2NLe0vILEXMNVOK6bX6dZPVIhkoRdUxQIF9MyhO7Ib+iL8orU16cVtzaW70J3nVoRBNOshEDUE4shGKZbGyycmqo+pBbYy7cf6aC2sJVLBf31XFJlj4uIbhsa1RKP4KOqaLzZAQD28nPPvPpOufu/H+31nCEfbd4ttsu1PF0WBOtcPgDXt9rh+DetHeEDFKiPlxzpCJAMkc4oDdUbgt4JYLXGeRiEX6R1fIi0L9yue61jeFuyRFA7t/zLnqXdFl4g==
X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2996; 25:h8c0kCDubjHLI2oOBAr5PQ/rIXLUmfkS/uBy1S1npdeS4g6eQ6VAnVb+Hm4hYbFAskAoP8Zlg1bHcWrBpTOBrhRdhXPrzHO58dKGhIvYqxCXfMQAjFqkfI77Y5Uwemq9W2I0nietA/bogmEm4IPtt3wNSZgYTyNQejz/Cb1LFYe8M7suap6ZffXZYQDq5X5P4FXn2xYu/ValeGotELLg9ZJy2kAf2OFQdiFVCGZDi0K+N5n5VhESVVhaiJOx8+lzxzTFB5Z2Ns3D02No5Uad9F3ZhaaFt/u5HT3eopWZKVxJWYfh7y45wEa7ToosEci0nby9pVXfDgNqvHPeZ4Wd7rxnrBb/FS1hSfGR+Osyqsh/BzMUSMU/+NqDmBFKWX0RhoDP4Ib7fDU7mVkkjqHAMKh2JJyLKJCbBR7FbMo60mNLQMwsC50yUGxaZ7oMW3J6HqfdX45gyeA3wXA8ypB9Q2kg2TUt+CHeQEn/P/M0cpFyzzC2yVNvRH7RiMnJe3G+X6+K8jMfwyT//rObjwuwRxmA/SmWSFvxIIcHemwnlZHN0NCDzAAZf7c2J/ouWfWZ62o0JgUU9vn8cFW0qcRGTWRgmDnNOZOCZUaWMd3rSBQFw3eO09lcuw5wPfYiRxevqM1ZNFRy4lyk9A9VzSLcmWb+n/k7rk3Mhz0Sp/CbJuIMxY8r74n9mCi6yqWat8BPII1i2BbUnKNXVqgKO2J5QAGMMAwSkSQ3CN91ALmOBSL75hfUQMlefwBL+WAh6rn3
X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2996; 31:GvskiTcBvpoQSDetfn+W8Zt3AG96ep064pJAE5j+uhnq2JpKCHRy54tAJs4vCdcK/6oWxie3Jc+C+Cr8yCS8Xe9qVzQS+S1DmL48wYqGe6YbG6+mv3Un7StL88+arao+uYqKvzV36Xp+jJ5s+vS2imT6kvA7YviaV3a1EFeSA/5/BkLXFSb+bzPlyblp6C5mz553FKInCvKJOXAMeFxDwoTTqQEKqKe9X2U9mNtzp+QoP0CObDzdnHL4Sky4e9S9xCKt8HWy5IUpgXY/psCWPqKdDh1tiJd59VWA8/u2pAg=; 4:PWRYJDo6tzrgY7j1FWy+uTl+pj1RthD78gQQhZsOrdtIG+q8MmeXo8B8Eu9rlu2TdGIJ19esDbIQaVg0bBjN99FfFAFQ3TV6q+9zA7K97Q3sRbYMFE5hu2xdSFpp2gfqS3LGeURMD9zV7m2YLKHuAk/QN472XzV2kcOxQ7sBCmzwq99bS5kNs97iRUgzOB+lTm0/K1QVxXii7Oqi1oxBeVGWoUGsh9rESLBP+g4NoBzWunoFqR6c+lm7ZRjal3wudRYzpw4vdEJrOvKSdGnssv3AACu5Ep/R4QajmEzw4r1KNKBrnIrmneDdQMZqWETKO0iRFxdUWgzHMRYUlmvy8bZ+ssf3YFYY4CvZLaol3Am2DN72tHzrLFg+xnZ7dQxtL3Dkhp3xAMN29z/N1Sf/+qiJM/HV5y1VBdsI14NQ9KM5tdgdtmcJj6UErZQYOvZG3iHu4KoqW0NR3OUXExaVJr0YBoHPcvp8jhdgE34APsRJxmEOceXPDGGnu7gSs09g9qH21eKiJVUnk0LIAtkfY7ZxQn1Z21fXQz2ObajzS1sMlpxJvpJ5fhhWOD7dYwEAr0Bhz8eBX/CXZd1OT86QLQ==
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(178726229863574)(138986009662008);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6060326)(6045199)(6040307)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6061324)(6041248)(6072148); SRVR:AM5PR0701MB2996; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2996; 
X-Forefront-PRVS: 0132C558ED
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(24454002)(199003)(13464003)(189002)(377454003)(230700001)(84392002)(4326007)(47776003)(66066001)(76176999)(81686999)(50986999)(3846002)(68736007)(77096005)(6116002)(101416001)(81816999)(93886004)(8666005)(105586002)(106356001)(9686002)(33646002)(23676002)(7736002)(50466002)(7846002)(305945005)(6666003)(230783001)(81156014)(81166006)(42186005)(14496001)(62236002)(44716002)(2906002)(110136003)(116806002)(50226002)(61296003)(8676002)(44736004)(4720700003)(92566002)(1556002)(6916009)(38730400001)(229853002)(1456003)(97736004)(5660300001)(86362001)(189998001)(74416001)(7059030)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2996; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; 
Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTTVQUjA3MDFNQjI5OTY7MjM6WVlDWGJKTVlrQm4rb21QWHNkU3R6NHl2?= =?utf-8?B?OEJuMldVSElpUE5wbHZFMUdubXlCTjBKU1ZXVTV5elhEd0tvTmJuaHA5RTl6?= =?utf-8?B?bEhNT2xIc2VPcGZaUHVFSmhPekdnTkFDV09nMk5YdDg2RDRsWEZBbUUwM0pv?= =?utf-8?B?QmtrbE0vK3FTZkdTQjl1WXRjdS9samJvYmF3RWF3VGcyblZjNmdUWXQvQUNj?= =?utf-8?B?VEpqdzlnWnNNY1dENzZ1ek1XZm00UG1TbUFBa0hDeC9nc0ZMcHlEcTBkRUZn?= =?utf-8?B?SEhjMlJvN2tOaENMYTFwa01DMDBmK3RiSVVOTGZXL3JaVjdVNk9pcXRINkpa?= =?utf-8?B?SUdIVnY1TlFzZlhZU0FndXNCYnFtQkFKS2QyTEp4azJXTkZUbEN3YW9Pc2pm?= =?utf-8?B?dm4wUHJRNjFsVSsxenE0OG1XcjlQQTFFUFVMaVFrU2VHUkJvWTY0WThBeGZZ?= =?utf-8?B?Rmw3aUE1VFhTY01GRUY3YklEWUhXVUVSd2ROTkFyM3JGM0tPNXNzTXJrT2xV?= =?utf-8?B?SS93M2h1dkh4STcvQUhpMW1USmRsa1g5QlZmRDIxdWVGQjJUdnJzc2R3MDRU?= =?utf-8?B?OTVqU1VzaFVpUDBueXQyK0IxL0d0cFQ2T0oycVJzU2doSC9MU2JkUkZtbmFq?= =?utf-8?B?dlZEanRNSFdIQ05QL01ESFgrZ05aQkcvZldTR0JQSzQ4Rlo1a0d2UTRpbmV0?= =?utf-8?B?OVUrVHZMK0pRQjAvSldPbzRKcHNqYVhzaW5iNlFYcWlPaTZMVUh4d21STVEw?= =?utf-8?B?TjFjTU1yZzE0RWRzTFZ4bG13WUVpQ3JjSW9IYXJJS21BVEx0RjJnS0h5bXRp?= =?utf-8?B?WWVBRFNxRWFJUW9JWlU4cCs1UGlsSlpubmR4RXRzT3F4bFp0dDg2ZnVIR2cx?= =?utf-8?B?dkVnUjlsK20rRHU0ZjYyZmo3UkUxdVJZb2ZVMU1BSVVwVzVuK29KbFVkL2dB?= =?utf-8?B?ZlRFZkZCUzVJMjZwaXAvL2huTU5ROGRFOTdTYU5BMkI0bFUvSXBKTllMUWYy?= =?utf-8?B?SURCeStNNnVqeTFRdTJ1UXpsUmcrMXZ2NWJQdE5OL0g3Z3cyUkpqMm5oNlZj?= =?utf-8?B?c3d0d3FYbEdZTmJpNFBTTTBZTFB5SS80RCtBRFlMMmorZjRVWXJMSEoxZ0c2?= =?utf-8?B?RVJhdndCZm9HaHkxN2FXSXZYWFJ0OEptdUR4c0Z4MkNDeEgranZhemp2bk9Q?= =?utf-8?B?UmM5RGpaUVZsdE1VblB6Y1JPWXB1T09mRjJJNEVLWW1mRDU2NGU1THZaNWI3?= =?utf-8?B?L2tWMFpQTGROMFJRWFdMcjNBNTZGMzE5TFc3aS93QitNK1ZIb3NPQ1QzbGlV?= =?utf-8?B?ZE5PNHRTVThrTlZuN1lmUGJhVnB4R0VBK2dVWUxBaklvZHVZTlNUMmF5dzZt?= =?utf-8?B?YXhLZEQvWmtFcllhWWxqOVBkaW8yTWJqODVjZlptenROZWVHSnBONnZUN2xh?= =?utf-8?B?cEF0OHFFV3dKSnZMakpwNHBDWVBiVDk2bCt1L2pTUDdPS2lqd1U1Y253UW13?= =?utf-8?B?VmoxdjFxandHUWllK2NZZi9HYlZWcFlFWHFaTUI3NmRVRFFsSk52L1ZRVmRa?= =?utf-8?B?N2t2ZEtoSHFONWZ3YVpkZ05tbnhpVThPYnFHV090K2Y3SUE1eitQOWhxQUcz?= =?utf-8?B?a0NFOHdXS2I2bVZydVM0RUtFSGgwYUtxNlF3MlZGMlJCQVlqWUlITllVQklP?= =?utf-8?B?SUxYNUZiMTZhOXNhOE84RlJmR0xhVEl6TDdFNXB5cHZNQ0dkZGxoanJJL1Mz?= =?utf-8?B?ZVdZejRrdCtuVThHdFZaWkR1ejl4NURCVjM3ODhhWmxJby9SdDZ2bnpiczQz?= =?utf-8?B?QURMcUVwc0MyNVBKU2l0UDZTWWVBaVJQdk1xeHZOY0ZEMWNsZWdaOEFsTGE2?= =?utf-8?B?OVJ3Kys1TjJVVFZ0YkJ0VU9PZWFGemJXUFB0WC94dGhldFJUNnh5WFdiTFFo?= =?utf-8?Q?R/YHnnzzkOg1/lY2Otiiwku9551BF47Y=3D?=
X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2996; 6:PgqnXP46HLYWyxx5TCxMr0/FR4dVemEgbUhElYpPFk7a4TnqZ/c5mnKDnAKKtdU0gB5dfyOe9MBuLAvW4c5KUhJTwEG6tMIKQw4GjOngcam+89NCvvX945190KkcbnB+8Px3FCoGqJAjDNcdfMu51XrCN3cn8sJrcvf945kIsSffvfz+DeA5pM2NF9kHpoDRdQrYyK5fCiXme2DN1lSeIB0pYhPZUMHOJWtzEZ4RyEIYXSLII00fxA+twmTDV4yLkcqIcMnD9FzPpdnOGHhcR3wRRrMgE25/LDiJegJPV5z64wn98XXuX4aNLPeS9PM2/yhIfgeP5J4+0Fh3lXJ87bqJexpFRDfl4vrLKQp8NX8JQYIkVF+zxFJ7RjNRTm2Tgtxf5I8pWQ5Q3HJ8hw/IEQXbv7lJjZaqxeChKB2JKBsGrgbZfXgerG49lnuf2Mv7RCLxWs8zwdkgLLLWiDKLng==; 5:vBjQoAo2rG4I5x6J7yaPbJHOJhc6UxKZVhBsOA240QwVR0cVlSfsnKQFuTPmBTqNQlB9zHPNw8l1/wshb73dOVlDxUE8thNnCUgfbwdUX08JJD7qs5qrFLRQJGdyGxtpKgjPsbYP2+cItm65m5Ho2Q5AhN4Rbkxr2SFP9e+Qw2g=; 24:Pl9R6dURHVCCr1Xg82mI2oQoZAvixLxocPnjQqtq2iP4stVFbjBd/WCJ0A7Tlr44A0JOs8DPwOE6bSAlRbhMRMN3t7jlXpZUFAJ9Ami5klE=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2996; 7:vTDrZUEMGRE+YZ9yEs8OD0mKBeKrEKiFf+U2HtzvKrn5UQtF5aJMcfOE0PaaDpTHNSCSNVlbEx+Ol+L/YQZ21gu5wZ4t6kk7ks8iYQQohBC/uyWYwp2s/eLMbCGd8/1qR9k4ubYBqIbN43OZ/qNyivYE/RxXCur5p+NwXOJSODlDhjaGjG4s5Jw3A8Bz/9X3fCu/V3vkEMPNS/+SCSqEfqsPJqxZc/XJLLga913ujU53QUGQV/oKlp/fC0JSMbtWqdObbIBVOiTVTdFCJ6VHhT/0GwvYuwA/xIN9481NOmodF3m3vC0JvTfoDljvUEbAJ+b1GX5O8vCfY3i/K3gsnlgSK4L34q+c6UstU6DcLJIfgMuUpjQz0lf/xMJt38okZL/USfAg6FMrGak6QgamIf+Y/T/cQ6yQvTwObWD1yn3nt+FPZCjhDSlBZE1DQ4tFe6wqM+yajkCxfjZ/49RUFg==
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Nov 2016 10:20:43.1375 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2996
Archived-At: 
Cc: idr wg 
Subject: Re: [Idr] One week extension to WGLC for draft-ietf-idr-large-community
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, 20 Nov 2016 10:20:51 -0000

----- Original Message -----
From: "Nick Hilliard" 
To: "t.petch" 
Cc: "John G. Scudder" ; "idr wg" 
Sent: Saturday, November 19, 2016 11:12 AM
> t.petch wrote:
> > An issue that came up earlier and that I did not see resolved was
> > what constitutes a duplicate.  This is binary so we don't have the
> > issues that character comparisons do but is it the same bit pattern
> > from start to finish, the same semantics or something between the
> > two?  A case I have in mind is when the same semantics appear in
> > RFC1997 format and also in LC format; is that a duplicate?.
>
> rfc1997 and LC being different namespaces, no.

So you have someone been happily using RFC1997 for years with success
when one of their pesky peers goes and gets a 32-bit ASN and suddenly
they cannot use RFC1997 any more and have to start using LC, to do
exactly the same thing as they have been doing for ages.

We are now saying 'ah no, this is two separate unrelated bits of
technology that cannot be compared and you must treat as different'.
Someone with a 32-bit ASN is in a different universe to someone with a
16-bit ASN.

Mmmm not very friendly.

Tom Petch

> Nick


From nobody Sun Nov 20 04:59:46 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75BA51295FD for ; Sun, 20 Nov 2016 04:59:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.432
X-Spam-Level: 
X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_SOFTFAIL=0.665] 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 OUBKmikzyGRu for ; Sun, 20 Nov 2016 04:59:44 -0800 (PST)
Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (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 535B41295A0 for ; Sun, 20 Nov 2016 04:59:44 -0800 (PST)
Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1c8Rig-0008Ws-TN (job@us.ntt.net); Sun, 20 Nov 2016 12:59:43 +0000
Date: Sun, 20 Nov 2016 13:59:39 +0100
From: Job Snijders 
To: idr@ietf.org
Message-ID: <20161120125939.GD1121@Vurt.local>
References: <27701_1479159582_582A2F1E_27701_6903_1_53C29892C857584299CBF5D05346208A1EC77FE1@OPEXCLILM21.corporate.adroot.infra.ftgroup> <736EA2CC-3DD1-4F14-96ED-2916E62F6F02@cisco.com> <26709_1479217575_582B11A7_26709_12999_1_53C29892C857584299CBF5D05346208A1EC79584@OPEXCLILM21.corporate.adroot.infra.ftgroup>   <20161116001246.GB27230@pfrc.org> <4EB6222D-86A4-4A83-AF8C-364CB52B8422@juniper.net> <004201d2418b$887208c0$4001a8c0@gateway.2wire.net> <583033B8.5010006@foobar.org> <016a01d24317$4cd1eaa0$4001a8c0@gateway.2wire.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <016a01d24317$4cd1eaa0$4001a8c0@gateway.2wire.net>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.7.1 (2016-10-04)
Archived-At: 
Subject: Re: [Idr] One week extension to WGLC for draft-ietf-idr-large-community
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, 20 Nov 2016 12:59:45 -0000

On Sun, Nov 20, 2016 at 10:17:20AM +0000, t.petch wrote:
> > t.petch wrote:
> > > An issue that came up earlier and that I did not see resolved was
> > > what constitutes a duplicate.  This is binary so we don't have the
> > > issues that character comparisons do but is it the same bit pattern
> > > from start to finish, the same semantics or something between the
> > > two?  A case I have in mind is when the same semantics appear in
> > > RFC1997 format and also in LC format; is that a duplicate?.
> >
> > rfc1997 and LC being different namespaces, no.
> 
> So you have someone been happily using RFC1997 for years with success
> when one of their pesky peers goes and gets a 32-bit ASN and suddenly
> they cannot use RFC1997 any more and have to start using LC, to do
> exactly the same thing as they have been doing for ages.
> 
> We are now saying 'ah no, this is two separate unrelated bits of
> technology that cannot be compared and you must treat as different'.
> Someone with a 32-bit ASN is in a different universe to someone with a
> 16-bit ASN.
> 
> Mmmm not very friendly.

I find it disingenuous to refer to 32-bit ASNs as 'pesky peers', you
very well know that the 16-bit pool has been depleted: IANA no longer
has 16-bit ASNs. Most RIRs are almost out or sitting on small reserves
of 16-bit ASns. Soon there simply won't be any choice but to use 32-bit
ASNs. 

When RFC 4893 was introduced, it was obvious that there would be gaps in
terms of feature parity, such as BGP Communities and GLOP space. Things
would not be the same. Within RFC 4893 itself, there is transition
measure involving the 23456 ASN. This transition measure did not allow
for actual policy transition, as the information it communicated added
up to what was essentially "here be dragons". Until operators upgraded
to firmware with RFC4893 support, crafting uniform policy for 16-bit and
32-bit AS paths was not feasible.

In this proposal, we've chosen not to introduce such a measure, as
generic approach to mapping 96 bits into 32 bits simply isn't
reasonable, and can't be done meaningfully.

Just as the case was with RFC 4893, RFC 1997 and Large Communities will
coexist side by side for some time. Vendors can implement mapping
primitives at the router level which would allow for mapping and
transformation. But these are local considerations.

I am disappointed that you _again_ bring up the topic of mapping between
RFC 1997 and Large Communities, which has already been discussed and
concluded as out-of-scope for this draft.

The most unfriendly thing we can do now is leave our 32-bit peers out in
the cold, without functional community space they can use for
implementing policy. Please just get out of the way.

Regards,

Job


From nobody Sun Nov 20 05:34:13 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05EFE129660 for ; Sun, 20 Nov 2016 05:34:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.097
X-Spam-Level: 
X-Spam-Status: No, score=-4.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497] 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 vdif-KxqSEO4 for ; Sun, 20 Nov 2016 05:34:10 -0800 (PST)
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 469B712964D for ; Sun, 20 Nov 2016 05:34:09 -0800 (PST)
X-Original-To: idr@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 870C46014D for ; Sun, 20 Nov 2016 14:34:07 +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 3DD156010F; Sun, 20 Nov 2016 14:34:07 +0100 (CET)
Received: by moebius4.space.net (Postfix, from userid 1007) id 2E8562F443; Sun, 20 Nov 2016 14:34:07 +0100 (CET)
Date: Sun, 20 Nov 2016 14:34:07 +0100
From: Gert Doering 
To: "t.petch" 
Message-ID: <20161120133407.GN79185@Space.Net>
References: <27701_1479159582_582A2F1E_27701_6903_1_53C29892C857584299CBF5D05346208A1EC77FE1@OPEXCLILM21.corporate.adroot.infra.ftgroup> <736EA2CC-3DD1-4F14-96ED-2916E62F6F02@cisco.com> <26709_1479217575_582B11A7_26709_12999_1_53C29892C857584299CBF5D05346208A1EC79584@OPEXCLILM21.corporate.adroot.infra.ftgroup>   <20161116001246.GB27230@pfrc.org> <4EB6222D-86A4-4A83-AF8C-364CB52B8422@juniper.net> <004201d2418b$887208c0$4001a8c0@gateway.2wire.net> <583033B8.5010006@foobar.org> <016a01d24317$4cd1eaa0$4001a8c0@gateway.2wire.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <016a01d24317$4cd1eaa0$4001a8c0@gateway.2wire.net>
X-NCC-RegID: de.space
User-Agent: Mutt/1.6.1 (2016-04-27)
Archived-At: 
Cc: idr wg 
Subject: Re: [Idr] One week extension to WGLC for draft-ietf-idr-large-community
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, 20 Nov 2016 13:34:12 -0000

Hi,

On Sun, Nov 20, 2016 at 10:17:20AM +0000, t.petch wrote:
> We are now saying 'ah no, this is two separate unrelated bits of
> technology that cannot be compared and you must treat as different'.
> Someone with a 32-bit ASN is in a different universe to someone with a
> 16-bit ASN.
> 
> Mmmm not very friendly.

This is not what Nick was saying, so don't try to make it.

Nick was saying that to argue that LC de-duplication should not take 
1997 communities into account, because that's a different namespace.

But in the end, what you say is what the IETF *made* it to be, due to
the insane delay in providing a 32bit equivalent to 1997 communities - 
folks with an older implementation living in 16 bit space will now
have issues setting community values to effect 32bit AS <-> 32bit AS
relations (like, exchange point route servers) because there just is
no way to express this with 1997 communities.

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 Sun Nov 20 06:14:07 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52264129450 for ; Sun, 20 Nov 2016 06:14:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.097
X-Spam-Level: 
X-Spam-Status: No, score=-4.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497] 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 72lbyF-0vh3V for ; Sun, 20 Nov 2016 06:14:04 -0800 (PST)
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 C0F4A12947B for ; Sun, 20 Nov 2016 06:14:04 -0800 (PST)
X-Original-To: idr@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id AD749604E6 for ; Sun, 20 Nov 2016 15:14:02 +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 5959C6010F; Sun, 20 Nov 2016 15:14:02 +0100 (CET)
Received: by moebius4.space.net (Postfix, from userid 1007) id 49C1D2F505; Sun, 20 Nov 2016 15:14:02 +0100 (CET)
Date: Sun, 20 Nov 2016 15:14:02 +0100
From: Gert Doering 
To: Job Snijders 
Message-ID: <20161120141402.GO79185@Space.Net>
References: <20161116130110.GK1073@dhcp-9341.meeting.ietf.org> <20161116134707.GP24817@gir.theapt.org>      <58306620.4000308@foobar.org>  <20161120100915.GC1121@Vurt.local>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20161120100915.GC1121@Vurt.local>
X-NCC-RegID: de.space
User-Agent: Mutt/1.6.1 (2016-04-27)
Archived-At: 
Cc: idr@ietf.org, grow@ietf.org, Robert Raszuk 
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 20 Nov 2016 14:14:06 -0000

Hi,

On Sun, Nov 20, 2016 at 11:09:15AM +0100, Job Snijders wrote:
> > Btw how are you going to handle it in IX ? I assume RS peers will not
> > get any info if one of the parties they used to get routes from goes
> > down and sends free form msg to RS ? Routes will be get withdrawn and
> > that's it.
> 
> Correct. This is the expected behaviour.

... and the IXP is, of course, free to have a looking glass type web 
page where the last "shutdown info message" the RS received can be
displayed.  So it's useful in IXP context, even if not directly visible
to other RS peers.

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 Sun Nov 20 06:35:31 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C54A1129696 for ; Sun, 20 Nov 2016 06:35:29 -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 SFEhUe56MJI0 for ; Sun, 20 Nov 2016 06:35:28 -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 D9DBE12962D for ; Sun, 20 Nov 2016 06:35:27 -0800 (PST)
X-Envelope-To: idr@ietf.org
Received: from crumpet.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id uAKEZNkI084345 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 20 Nov 2016 14:35:23 GMT (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be crumpet.local
Message-ID: <5831B4AA.9050306@foobar.org>
Date: Sun, 20 Nov 2016 15:35:22 +0100
From: Nick Hilliard 
User-Agent: Postbox 5.0.7 (Macintosh/20161117)
MIME-Version: 1.0
To: "t.petch" 
References:   <27701_1479159582_582A2F1E_27701_6903_1_53C29892C857584299CBF5D05346208A1EC77FE1@OPEXCLILM21.corporate.adroot.infra.ftgroup> <736EA2CC-3DD1-4F14-96ED-2916E62F6F02@cisco.com> <26709_1479217575_582B11A7_26709_12999_1_53C29892C857584299CBF5D05346208A1EC79584@OPEXCLILM21.corporate.adroot.infra.ftgroup>   <20161116001246.GB27230@pfrc.org> <4EB6222D-86A4-4A83-AF8C-364CB52B8422@juniper.net> <004201d2418b$887208c0$4001a8c0@gateway.2wire.net> <583033B8.5010006@foobar.org> <016a01d24317$4cd1eaa0$4001a8c0@gateway.2wire.net>
In-Reply-To: <016a01d24317$4cd1eaa0$4001a8c0@gateway.2wire.net>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: idr wg 
Subject: Re: [Idr] One week extension to WGLC for draft-ietf-idr-large-community
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, 20 Nov 2016 14:35:29 -0000

t.petch wrote:
> So you have someone been happily using RFC1997 for years with success
> when one of their pesky peers goes and gets a 32-bit ASN and suddenly
> they cannot use RFC1997 any more and have to start using LC, to do
> exactly the same thing as they have been doing for ages.
> 
> We are now saying 'ah no, this is two separate unrelated bits of
> technology that cannot be compared and you must treat as different'.
> Someone with a 32-bit ASN is in a different universe to someone with a
> 16-bit ASN.

Given that this was brought up before, commented on in depth, then
closed off as not being relevant to the draft, and where this closure
was assessed as having consensus, I'm not sure why it's appropriate to
bring the topic up again.

If you have an issue with the consensus call that was previously made,
this is something that you should take up with the chairs.

Nick


From nobody Sun Nov 20 10:35:04 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15053129706; Sun, 20 Nov 2016 10:34:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.397
X-Spam-Level: 
X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497] 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 TUwRYjQ1_9Zh; Sun, 20 Nov 2016 10:34:57 -0800 (PST)
Received: from pao.lahai.com (pao.lahai.com [206.220.230.130]) by ietfa.amsl.com (Postfix) with ESMTP id 9A5FE1296F8; Sun, 20 Nov 2016 10:34:57 -0800 (PST)
Received: from image.az.lahai.com (ip98-167-187-217.ph.ph.cox.net [98.167.187.217]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: gaurab) by pao.lahai.com (Postfix) with ESMTP id CEB68B2FCA; Sun, 20 Nov 2016 18:34:46 +0000 (UTC)
To: Nick Hilliard , "Neil J. McRae" 
References:      <58306620.4000308@foobar.org> <319AD952-C571-4085-8D56-C06A51F021E3@domino.org>   <058F756D-3A68-4AA6-A9DC-63A1BF9A5184@domino.org> <20161119194138.GG47336@dhcp-9d92.meeting.ietf.org> <87DDAB88-78AC-431A-ABE7-55249BF5D654@domino.org> <5830CAEB.7070400@foobar.org>
From: Gaurab Raj Upadhaya 
Message-ID: 
Date: Sun, 20 Nov 2016 18:34:56 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <5830CAEB.7070400@foobar.org>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="71iko6GCo10slXmTO8bnrraedEIesTgHr"
Archived-At: 
Cc: "idr@ietf.org" , "grow@ietf.org" 
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 20 Nov 2016 18:34:59 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--71iko6GCo10slXmTO8bnrraedEIesTgHr
Content-Type: multipart/mixed; boundary="CoX6CPx0LTfmEKHOKVRewuxo6qOJnRuPD";
 protected-headers="v1"
From: Gaurab Raj Upadhaya 
To: Nick Hilliard , "Neil J. McRae" 
Cc: "idr@ietf.org" , "grow@ietf.org" ,
 Job Snijders 
Message-ID: 
Subject: Re: [GROW] [Idr] draft-snijders-idr-shutdown-00: Drop a line in the
 peer's syslog at shutdown
References: 
 
 
 
 
 <58306620.4000308@foobar.org>
 <319AD952-C571-4085-8D56-C06A51F021E3@domino.org>
 
 
 <058F756D-3A68-4AA6-A9DC-63A1BF9A5184@domino.org>
 <20161119194138.GG47336@dhcp-9d92.meeting.ietf.org>
 <87DDAB88-78AC-431A-ABE7-55249BF5D654@domino.org>
 <5830CAEB.7070400@foobar.org>
In-Reply-To: <5830CAEB.7070400@foobar.org>

--CoX6CPx0LTfmEKHOKVRewuxo6qOJnRuPD
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On 11/19/16 9:58 PM, Nick Hilliard wrote:
> Regarding the I-D, there are ~55000 asns visible in the dfz, of
> which ~6000-7000 are non-leaf, and probably less than a thousand
> where bgp session automation makes financial sense.  No doubt,
> as5400/2856 would be in the top bracket of these and it would make
> sense for your tooling teams to automate the hell out of nearly
> everything, which would militate against accepting free-form advisory
> shutdown notices like this - but then again, BT is atypical in the
> general scheme of things. Whether you like it or not, the long tail
> of ASNs would benefit from a simple mechanism of this form.

that sums it up neatly for me. I also think that adding complexity in
the free form at this stage may limit implementation and the numerous
ways in which it can be used for automation.

I see these quite similar to TXT records in DNS. and so, I do think that
at some point after this has been implemented, we'll need to document
widely adopted structures in a BCP.

-gaurab




--CoX6CPx0LTfmEKHOKVRewuxo6qOJnRuPD--

--71iko6GCo10slXmTO8bnrraedEIesTgHr
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

iEYEARECAAYFAlgx7NAACgkQSo7fU26F3X3zpQCfSletegOS2Y/I07/3kz/iXs2F
BW0AnjTeBVtutnGsBVjcpXYIBido3/Zo
=5fMK
-----END PGP SIGNATURE-----

--71iko6GCo10slXmTO8bnrraedEIesTgHr--


From nobody Sun Nov 20 12:02:35 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E43381294F3; Sun, 20 Nov 2016 12:02:29 -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, 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] 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 1oReWAferHaN; Sun, 20 Nov 2016 12:02:28 -0800 (PST)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0111.outbound.protection.outlook.com [104.47.0.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 67D2812948F; Sun, 20 Nov 2016 12:02:27 -0800 (PST)
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=3zNC4+VVixhg8FIt/d7xvpjrWXA/bpQdqRYBTx4Ztzc=; b=KQZGYf2mFCu+J+Tx83KzzKmv62l2HzD91GwF63tYc3FYSA52uXDnoI2+gf73wfgqlhhYjKrXEkeqCUaJkyS3tPSKZOLkzR/Y/THqAmFwOiaf7QepQjBbaMoD4D7GF8/Y93vpEcgMHFrSiZcun6GC3RAtvaUImGBpVU9HEP2y0No=
Received: from AM4PR03MB1425.eurprd03.prod.outlook.com (10.164.77.155) by AM4PR03MB1426.eurprd03.prod.outlook.com (10.164.77.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.721.10; Sun, 20 Nov 2016 20:02:21 +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.0734.013; Sun, 20 Nov 2016 20:02:21 +0000
From: "Neil J. McRae" 
To: Gaurab Raj Upadhaya 
Thread-Topic: [GROW] [Idr] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
Thread-Index: AQHSQrAEOpLRIJtiuU+cyRdbITRWCKDiNDQAgAAYbao=
Date: Sun, 20 Nov 2016 20:02:21 +0000
Message-ID: <83A8E52C-DBD8-4321-99A0-58672EBE5430@domino.org>
References:      <58306620.4000308@foobar.org> <319AD952-C571-4085-8D56-C06A51F021E3@domino.org>   <058F756D-3A68-4AA6-A9DC-63A1BF9A5184@domino.org> <20161119194138.GG47336@dhcp-9d92.meeting.ietf.org> <87DDAB88-78AC-431A-ABE7-55249BF5D654@domino.org> <5830CAEB.7070400@foobar.org>, 
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=neil@domino.org; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [81.139.119.106]
x-microsoft-exchange-diagnostics: 1; AM4PR03MB1426; 7:In/KEHp3LgUdYhGRMwwOE1xsgEYGWmlDStUXMZfiB2omzJEepHka8i729reL4ztk14SPR1LeT/layc0ClJAhfUvhg5dNaMUe/fJefG1cKEk004fX324M4H2YNAGcrCL9nFW1YYTVcV6fjZiQhCorl1HaG7xK3IrcIgiYdi4KvoPCUu6S+dwscNS1joZX7tWP5Crfi5KcsvNl6rbSAXa9dWQa9mIUB7vIFd3MwkXlA10aOqmAvHgQJBS469Nza0SHVy4E1KjaYNQvNsopD23o+Qr4LZHWyELwoRaFSf7cjz4hkFtkhraEALcQnRMrLdvazkcYpzW0u/3DjgQmjwZ0EFihLty4mqGqCjOBoki8Eiw=
x-ms-office365-filtering-correlation-id: 97be171b-11ad-49aa-63cb-08d411802384
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:AM4PR03MB1426;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6060326)(6040307)(6045199)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6061324)(6041248)(2016111802025)(6043046); SRVR:AM4PR03MB1426; BCL:0; PCL:0; RULEID:; SRVR:AM4PR03MB1426; 
x-forefront-prvs: 0132C558ED
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377454003)(43544003)(24454002)(199003)(189002)(102836003)(6116002)(77096005)(2900100001)(6916009)(2950100002)(87936001)(3846002)(82746002)(110136003)(81156014)(92566002)(3280700002)(189998001)(3660700001)(229853002)(36756003)(4326007)(86362001)(81166006)(6512003)(68736007)(6506003)(2906002)(38730400001)(7736002)(122556002)(101416001)(230783001)(5660300001)(33656002)(7846002)(93886004)(8676002)(97736004)(83716003)(8936002)(106116001)(54356999)(76176999)(105586002)(305945005)(66066001)(50986999)(106356001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR03MB1426; H:AM4PR03MB1425.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  A:0; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: domino.org does not designate permitted sender hosts)
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: 20 Nov 2016 20:02:21.3085 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 398f3eb4-3394-48e7-885c-de1ab2a9cf2e
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR03MB1426
Archived-At: 
Cc: "idr@ietf.org" , "grow@ietf.org" 
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 20 Nov 2016 20:02:30 -0000

I would be deploying automation to take care of network problems/issues/wha=
tever whether I worked at BT or I was the admin of a network with four and =
a half nodes.

We have the world and his wife automating and innovating on top of -our- in=
ternet platform and we are still encouraging behaviours like it was 1992 (I=
'd say like mission control in the 60s but I think they had more automation=
 back then!)=20

oh well if we just want to be the dumb pipe providers!=20

> On 20 Nov 2016, at 18:34, Gaurab Raj Upadhaya  wrote:
>=20
>> On 11/19/16 9:58 PM, Nick Hilliard wrote:
>> Regarding the I-D, there are ~55000 asns visible in the dfz, of
>> which ~6000-7000 are non-leaf, and probably less than a thousand
>> where bgp session automation makes financial sense.  No doubt,
>> as5400/2856 would be in the top bracket of these and it would make
>> sense for your tooling teams to automate the hell out of nearly
>> everything, which would militate against accepting free-form advisory
>> shutdown notices like this - but then again, BT is atypical in the
>> general scheme of things. Whether you like it or not, the long tail
>> of ASNs would benefit from a simple mechanism of this form.
>=20
> that sums it up neatly for me. I also think that adding complexity in
> the free form at this stage may limit implementation and the numerous
> ways in which it can be used for automation.
>=20
> I see these quite similar to TXT records in DNS. and so, I do think that
> at some point after this has been implemented, we'll need to document
> widely adopted structures in a BCP.
>=20
> -gaurab
>=20
>=20
>=20


From nobody Sun Nov 20 13:44:58 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC523129445 for ; Sun, 20 Nov 2016 13:44:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.397
X-Spam-Level: 
X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497] 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 8IbBtJxzjN9x for ; Sun, 20 Nov 2016 13:44:55 -0800 (PST)
Received: from pao.lahai.com (pao.lahai.com [206.220.230.130]) by ietfa.amsl.com (Postfix) with ESMTP id 6C265129422 for ; Sun, 20 Nov 2016 13:44:55 -0800 (PST)
Received: from image.az.lahai.com (ip98-167-187-217.ph.ph.cox.net [98.167.187.217]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: gaurab) by pao.lahai.com (Postfix) with ESMTP id 92A49B2FCA; Sun, 20 Nov 2016 21:44:44 +0000 (UTC)
To: Susan Hares , 'idr wg' 
References: <013f01d2404d$3dfff610$b9ffe230$@ndzh.com>
From: Gaurab Raj Upadhaya 
Message-ID: 
Date: Sun, 20 Nov 2016 21:44:42 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <013f01d2404d$3dfff610$b9ffe230$@ndzh.com>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6tDVpwQjTEKMbjINn13ognLjmUOkn1Kgl"
Archived-At: 
Subject: Re: [Idr] WG Adoption call for draft-snijders-idr-shutdown (11/16 to 11/30)
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, 20 Nov 2016 21:44:57 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--6tDVpwQjTEKMbjINn13ognLjmUOkn1Kgl
Content-Type: multipart/mixed; boundary="3ue4es0FibePKmQt3mop5Mw82DFWQDThj";
 protected-headers="v1"
From: Gaurab Raj Upadhaya 
To: Susan Hares , 'idr wg' 
Message-ID: 
Subject: Re: [Idr] WG Adoption call for draft-snijders-idr-shutdown (11/16 to
 11/30)
References: <013f01d2404d$3dfff610$b9ffe230$@ndzh.com>
In-Reply-To: <013f01d2404d$3dfff610$b9ffe230$@ndzh.com>

--3ue4es0FibePKmQt3mop5Mw82DFWQDThj
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On 11/16/16 9:06 PM, Susan Hares wrote:
> This begins a 2 week WG Adoption call for
> draft-snijders-idr-shutdown (11/16/2016 to 11/30/2016).   The
> discussion should consider whether this is useful to operators and
> technical issues.

yes. i would agree this go ahead with adoption as it's a useful for
operations.

-gaurab





--3ue4es0FibePKmQt3mop5Mw82DFWQDThj--

--6tDVpwQjTEKMbjINn13ognLjmUOkn1Kgl
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

iEYEARECAAYFAlgyGUsACgkQSo7fU26F3X0LhwCfQVcVfxCCk6WoWnRaPfEKsKzJ
HlIAoPqrRgmE6rDX13AbNQQvdvqXxIab
=1wRZ
-----END PGP SIGNATURE-----

--6tDVpwQjTEKMbjINn13ognLjmUOkn1Kgl--


From nobody Sun Nov 20 14:09:41 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA0F3129503; Sun, 20 Nov 2016 14:09:36 -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 gKHTyKyGW1LO; Sun, 20 Nov 2016 14:09:35 -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 F16C9128874; Sun, 20 Nov 2016 14:09:34 -0800 (PST)
X-Envelope-To: grow@ietf.org
Received: from crumpet.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id uAKM9QZP097501 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 20 Nov 2016 22:09:29 GMT (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be crumpet.local
Message-ID: <58321F15.9000105@foobar.org>
Date: Sun, 20 Nov 2016 23:09:25 +0100
From: Nick Hilliard 
User-Agent: Postbox 5.0.7 (Macintosh/20161117)
MIME-Version: 1.0
To: "Neil J. McRae" 
References:      <58306620.4000308@foobar.org> <319AD952-C571-4085-8D56-C06A51F021E3@domino.org>   <058F756D-3A68-4AA6-A9DC-63A1BF9A5184@domino.org> <20161119194138.GG47336@dhcp-9d92.meeting.ietf.org> <87DDAB88-78AC-431A-ABE7-55249BF5D654@domino.org> <5830CAEB.7070400@foobar.org>,  <83A8E52C-DBD8-4321-99A0-58672EBE5430@domino.org>
In-Reply-To: <83A8E52C-DBD8-4321-99A0-58672EBE5430@domino.org>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: "idr@ietf.org" , "grow@ietf.org" 
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 20 Nov 2016 22:09:36 -0000

Neil J. McRae wrote:
> I would be deploying automation to take care of network
> problems/issues/whatever whether I worked at BT or I was the admin of
> a network with four and a half nodes.

For sure.  e.g. we've automated the hell out of INEX (which has more
than 4.5 nodes btw).  The point is that most ASNs are a good deal
smaller than this, and less amenable to automation than IXPs.  There's
simply no point in writing automation software to handle one or two
routers with 5 or fewer ebgp sessions between them, which describes the
overwhelming majority of ASNs in the world.

> We have the world and his wife automating and innovating on top of
> -our- internet platform and we are still encouraging behaviours like
> it was 1992 (I'd say like mission control in the 60s but I think they
> had more automation back then!)

Rather than castigating people for their shortsightedness, did you take
the time to ask e.g. Job why a large carrier like NTT might want this
feature?  Their network is likely to be highly automated.

Nick


From nobody Sun Nov 20 15:10:41 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D2B5129466; Sun, 20 Nov 2016 15:10:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level: 
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=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=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 hFIeVjgoGB9m; Sun, 20 Nov 2016 15:10:39 -0800 (PST)
Received: from mail-qk0-x244.google.com (mail-qk0-x244.google.com [IPv6:2607:f8b0:400d:c09::244]) (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 0B971129424; Sun, 20 Nov 2016 15:10:39 -0800 (PST)
Received: by mail-qk0-x244.google.com with SMTP id x190so43369526qkb.0; Sun, 20 Nov 2016 15:10:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=l3f8vWQNZqOUbXSOshbPt/MI+0WYP4Wir5+2xmLr7oo=; b=LA6Kkk/q06tTxcwOq0m0d9c59XNeSAlLR3H+fHr3Grlg2K0bBh1kQobD2kYc/zckAQ u0J/hekcBYl1MgYHCCX0RDilTn9tXsL6e0yXirMdljTxOcaZzBur7cFHxye3qNm9g6NK PTrXF6UrRtIarRxXtv0CTM211+VY1Mpb+i1Ubu35lkuGDz1CSpnoY9F7CULwbEEa0+Ca t4Y2eJPeHVsSV527dwA7O7SVFZySI+euXcbGcB2IwS9j/M6uIJDAKDbBO2Q0YbUUWBTR stDjdBg8aWFOAkon4716lhrr/bHVFcPAPfJEEwSjAjkNtU86yVNOCLT9YDOwkhYDuD91 zrFw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=l3f8vWQNZqOUbXSOshbPt/MI+0WYP4Wir5+2xmLr7oo=; b=BgFmEDT5s15qx0DA7UK9SZUuzW5YCt6tFDytt+MTN/fxN8kzuJdfXernF5tTaZQoL1 GG/hkUrOojgxNZqWWRwpbgNeKZqgIml6RwIYVdeTWjoMFvNY0Gib3fsXR6Be1sFC2y/Y 7u3RYyFllXwum5tAKaXuo6TN/B642DlpltFrITcLXSFSniWV0UG5Q0y1vA7k6pRH3jUV htoayi9Iy/JBs3p24OiNa6C4mAA1bXMRKWKXZYbmtBmkU+5bETJnR98NkraILmn1e2dO 6VUb1gfumzIgjS1XfIy4g1vpSs/z0hcslLhSwCUquzNSWoQw54pwksS3RdA/QmnSAC9q sJPA==
X-Gm-Message-State: AKaTC03/72EhxsWcVL7feGG3HJB9+rLHjaL3bTVAYI+eoaIgLvBbzA4rk8U72NChvBwansRNCdl0szBV12pyYA==
X-Received: by 10.55.81.8 with SMTP id f8mr12274676qkb.101.1479683438181; Sun, 20 Nov 2016 15:10:38 -0800 (PST)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.140.16.50 with HTTP; Sun, 20 Nov 2016 15:10:36 -0800 (PST)
Received: by 10.140.16.50 with HTTP; Sun, 20 Nov 2016 15:10:36 -0800 (PST)
In-Reply-To: 
References:      <58306620.4000308@foobar.org> <319AD952-C571-4085-8D56-C06A51F021E3@domino.org>   <058F756D-3A68-4AA6-A9DC-63A1BF9A5184@domino.org> <20161119194138.GG47336@dhcp-9d92.meeting.ietf.org> <87DDAB88-78AC-431A-ABE7-55249BF5D654@domino.org> <5830CAEB.7070400@foobar.org>  <83A8E52C-DBD8-4321-99A0-58672EBE5430@domino.org>  
From: Robert Raszuk 
Date: Mon, 21 Nov 2016 00:10:36 +0100
X-Google-Sender-Auth: NgmU0RRHsdIRZHnANl1zQRD6diY
Message-ID: 
To: "Neil J. McRae" 
Content-Type: multipart/alternative; boundary=001a114a8d5eb684cd0541c3a54d
Archived-At: 
Cc: "idr@ietf.org" , grow@ietf.org
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 20 Nov 2016 23:10:40 -0000

--001a114a8d5eb684cd0541c3a54d
Content-Type: text/plain; charset=UTF-8

I am not suggesting TLV format. Just few  optional and predefind keywords
for those who like your peer to be able to parse it.

I am not taking away anything you are proposing just adding few words which
can help.

What is the problem of accepting it ?

Thx
R.

On Nov 20, 2016 21:02, "Neil J. McRae"  wrote:

I would be deploying automation to take care of network
problems/issues/whatever whether I worked at BT or I was the admin of a
network with four and a half nodes.

We have the world and his wife automating and innovating on top of -our-
internet platform and we are still encouraging behaviours like it was 1992
(I'd say like mission control in the 60s but I think they had more
automation back then!)

oh well if we just want to be the dumb pipe providers!

> On 20 Nov 2016, at 18:34, Gaurab Raj Upadhaya  wrote:
>
>> On 11/19/16 9:58 PM, Nick Hilliard wrote:
>> Regarding the I-D, there are ~55000 asns visible in the dfz, of
>> which ~6000-7000 are non-leaf, and probably less than a thousand
>> where bgp session automation makes financial sense.  No doubt,
>> as5400/2856 would be in the top bracket of these and it would make
>> sense for your tooling teams to automate the hell out of nearly
>> everything, which would militate against accepting free-form advisory
>> shutdown notices like this - but then again, BT is atypical in the
>> general scheme of things. Whether you like it or not, the long tail
>> of ASNs would benefit from a simple mechanism of this form.
>
> that sums it up neatly for me. I also think that adding complexity in
> the free form at this stage may limit implementation and the numerous
> ways in which it can be used for automation.
>
> I see these quite similar to TXT records in DNS. and so, I do think that
> at some point after this has been implemented, we'll need to document
> widely adopted structures in a BCP.
>
> -gaurab
>
>
>

_______________________________________________
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

--001a114a8d5eb684cd0541c3a54d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


I am not suggesting TLV format. Just few=C2=A0 optional and =
predefind keywords for those who like your peer to be able to parse it.


I am not taking away anything you are proposing just adding =
few words which can help.


What is the problem of accepting it ?


Thx

R.



On Nov 20, 2016 2=
1:02, "Neil J. McRae" <neil=
@domino.org> wrote:
I would be deploying automation to take care of network problems/issues/wh=
atever whether I worked at BT or I was the admin of a network with four and=
 a half nodes.



We have the world and his wife automating and innovating on top of -our- in=
ternet platform and we are still encouraging behaviours like it was 1992 (I=
'd say like mission control in the 60s but I think they had more automa=
tion back then!)



oh well if we just want to be the dumb pipe providers!




> On 20 Nov 2016, at 18:34, Gaurab Raj Upadhaya <gaurab@lahai.com> wrote:

>

>> On 11/19/16 9:58 PM, Nick Hilliard wrote:

>> Regarding the I-D, there are ~55000 asns visible in the dfz, of
>> which ~6000-7000 are non-leaf, and probably less than a thousand
>> where bgp session automation makes financial sense.=C2=A0 No doubt=
,

>> as5400/2856 would be in the top bracket of these and it would make=


>> sense for your tooling teams to automate the hell out of nearly
>> everything, which would militate against accepting free-form advis=
ory

>> shutdown notices like this - but then again, BT is atypical in the=


>> general scheme of things. Whether you like it or not, the long tai=
l

>> of ASNs would benefit from a simple mechanism of this form.

>

> that sums it up neatly for me. I also think that adding complexity in<=
br>
> the free form at this stage may limit implementation and the numerous<=
br>
> ways in which it can be used for automation.

>

> I see these quite similar to TXT records in DNS. and so, I do think th=
at

> at some point after this has been implemented, we'll need to docum=
ent

> widely adopted structures in a BCP.

>

> -gaurab

>

>

>




_____________________________________=
__________

GROW mailing list

GROW@ietf.org

https://www.ietf.org/mailman/listinfo/grow





--001a114a8d5eb684cd0541c3a54d--


From nobody Sun Nov 20 15:21:41 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F825129442; Sun, 20 Nov 2016 15:21:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level: 
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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 qws2n2mBQg7h; Sun, 20 Nov 2016 15:21:35 -0800 (PST)
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 6BD571293E3; Sun, 20 Nov 2016 15:21:35 -0800 (PST)
Received: by mail-qk0-x235.google.com with SMTP id q130so330532281qke.1; Sun, 20 Nov 2016 15:21:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=MEcUNrvH+aeu+d600T8ppT2PXOJCLw1+nsYRb7cOYeY=; b=Buxy5jdwSI5p9HJlYA42LXAEQ/4pomijoeQDhN2o2/uiM0Bv8vJqo/DSYJ2cpPsdeW g6ovXOIpA2Y/mNNrM9pe9456y4V8WEUi9BlMgmIOiyysDMoOW1dfW5OuAJoxpmfarAt1 +x0q13LQg2x5cmdHqH6PV0S1pQOJdrvfYJ/KFJDXb7jZuVRXK8Mdma6sE8kDDFHpCJ4u hpGWLM4lONK72SLtgJO4tCPS3XTV7DCpd3zIexrKqPXPXb/cY/wPlyb/PeN/Uir7becP AdODs7rZuHUW7OFmDl18X7bLRAKvCXXWBm+/HKDmL5q7fw4h64XHRKCn/BElcU9/BNXX RKag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=MEcUNrvH+aeu+d600T8ppT2PXOJCLw1+nsYRb7cOYeY=; b=QK8vLGBo045sqdzbj1VGmP00nHgdoOfd6d6tt6jodX7WuVSfBvDkCkYvYgLba2/0WQ jHST57G39jti3qvOKjIXkndN2xA4/BjM4nnROA7X26JzTrgz0xeI6Vj9+iRE+t17Abmr f6ZD/ci3GDo4HMvXxr/CtJpfpyi+kUvkXtkQ+4mssbtRt7OigallcFq+tHJRGuel9Oih emtbmoJVvppgMBkshfjV0UiMlDOq6+KpYqMqwTSb/LttUIEvla9YYCGIaOVOMQu3wUmq eQZgzkiNkCvrnzITN+JLT4LM+KXAu9F0lMHtCMQA46xbjCVkBYQd4S0l2t/iYtSbH179 ktYg==
X-Gm-Message-State: AKaTC01fXWdwx/DhanXaLBp06pFkypQBnRZLmc8Fao8LdeuNxj2/Fb6bX8sxsebHdpd9WQczNWWsE82/1orp+Q==
X-Received: by 10.55.4.19 with SMTP id 19mr12367752qke.18.1479684094465; Sun, 20 Nov 2016 15:21:34 -0800 (PST)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.140.16.50 with HTTP; Sun, 20 Nov 2016 15:21:32 -0800 (PST)
Received: by 10.140.16.50 with HTTP; Sun, 20 Nov 2016 15:21:32 -0800 (PST)
In-Reply-To: <20161120100915.GC1121@Vurt.local>
References: <20161116113849.udbrfvdhaj3be7nx@bongo.bofh.it> <20161116130110.GK1073@dhcp-9341.meeting.ietf.org> <20161116134707.GP24817@gir.theapt.org>      <58306620.4000308@foobar.org>  <20161120100915.GC1121@Vurt.local>
From: Robert Raszuk 
Date: Mon, 21 Nov 2016 00:21:32 +0100
X-Google-Sender-Auth: kOxTJsGbGYGR6DgElSSCb24uQL0
Message-ID: 
To: Job Snijders 
Content-Type: multipart/alternative; boundary=001a114c8474d49b5a0541c3cc23
Archived-At: 
Cc: idr wg , grow@ietf.org
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 20 Nov 2016 23:21:37 -0000

--001a114c8474d49b5a0541c3cc23
Content-Type: text/plain; charset=UTF-8

> I'd like to ask the chairs to move
'draft-ietf-idr-operational-message-00' to 'Dead' status.

It bothers you so much that it is a WG doc ?

Or is the issue that it does not define fixed field for plain telephone
number to dial ?

R.

--001a114c8474d49b5a0541c3cc23
Content-Type: text/html; charset=UTF-8




> I'd like to ask the chairs to move 'draft-ietf-idr-operational-message-00' to 'Dead' status.


It bothers you so much that it is a WG doc ?


Or is the issue that it does not define fixed field for plain telephone number to dial ?


R.




--001a114c8474d49b5a0541c3cc23--


From nobody Sun Nov 20 17:03:13 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 625BF1295EF for ; Sun, 20 Nov 2016 17:03:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.018
X-Spam-Level: 
X-Spam-Status: No, score=-16.018 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=-1.497, 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 SPf6fwJuRhwu for ; Sun, 20 Nov 2016 17:03:11 -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 4682D1294C9 for ; Sun, 20 Nov 2016 17:03:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=244; q=dns/txt; s=iport; t=1479690191; x=1480899791; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Biw4QXVZ51O6A9cTu4OGLZ38yo5YUljcUQwmCkp/Tac=; b=jEOyVsCfnz1kXRmTg/I7CdCGtyVnCmzWzpo205wY+13NXCP/qvgKWf+M uf/mmHDe5Ra97bmes4LqrgJfQgiuWDz9KBeRa9koWpdgS742C8n/w/IU8 /FhyIyVgC5vQ4ciequdMyMKXljwRQVIr46xEmJoMZRI6AacjMUctiCIlL o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BtAQA+RzJY/4oNJK1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgzgBAQEBAR+BX404qXGCDoIFhiECgX0/FAECAQEBAQEBAWIohGkBAQQ?= =?us-ascii?q?6PxACAQg2EDIlAgQBDQ2IZaoti0sBAQEBAQEBAQEBAQEBAQEBAQEBAQEchjyEW?= =?us-ascii?q?ooqAQSaTQGQb4FhAY5MkWkBHjeBEoN8gUWIIoEMAQEB?=
X-IronPort-AV: E=Sophos;i="5.31,524,1473120000"; d="scan'208";a="350162609"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Nov 2016 01:03:10 +0000
Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id uAL13AVT013746 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 21 Nov 2016 01:03:10 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; Sun, 20 Nov 2016 19:03:09 -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; Sun, 20 Nov 2016 19:03:09 -0600
From: "Jakob Heitz (jheitz)" 
To: Job Snijders , Robert Raszuk 
Thread-Topic: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
Thread-Index: AQHSQXkWcwxsdEyE5EyI6kdWHGEfNaDfKimQgAFX6wCAAEGUgIABRhkAgACUylA=
Date: Mon, 21 Nov 2016 01:03:09 +0000
Message-ID: <14e3bc9e25534421b665cf451d853909@XCH-ALN-014.cisco.com>
References: <20161116061556.GG1073@dhcp-9341.meeting.ietf.org> <20161117013640.GB6217@pfrc.org> <16426_1479400131_582DDAC3_16426_1669_1_53C29892C857584299CBF5D05346208A1EC87201@OPEXCNORM2F.corporate.adroot.infra.ftgroup> <20161118004548.GK1072@dhcp-9341.meeting.ietf.org> <16418_1479457940_582EBC93_16418_290_1_53C29892C857584299CBF5D05346208A1EC8DEA5@OPEXCLILM21.corporate.adroot.infra.ftgroup>  <13357_1479459134_582EC13E_13357_5786_1_53C29892C857584299CBF5D05346208A1EC8FF18@OPEXCLILM21.corporate.adroot.infra.ftgroup> <37224750-4065-40E3-B6F4-571DED698563@cisco.com> <20161119103226.GN1072@dhcp-9341.meeting.ietf.org>  <20161120095418.GA1121@Vurt.local>
In-Reply-To: <20161120095418.GA1121@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.61.17]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: "idr@ietf.org" 
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 21 Nov 2016 01:03:12 -0000

Today, IOS-XR does not put anything into the data field when sending the Ce=
ase subcode 2.
If something is received, it hexdumps it in show bgp neighbor.

Does any other implementation put anything into the data field?

Thanks,
Jakob.


From nobody Mon Nov 21 00:22:36 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78FFA1297DE; Mon, 21 Nov 2016 00:22:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.397
X-Spam-Level: 
X-Spam-Status: No, score=-8.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497] 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 WOVTlIkvrvZP; Mon, 21 Nov 2016 00:22:30 -0800 (PST)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (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 64F531297D6; Mon, 21 Nov 2016 00:22:30 -0800 (PST)
Received: from mbp-4.local ([IPv6:2601:647:4201:9e61:a1e3:bb9c:8cf7:bf8b]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id uAL8MSl6071507 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 21 Nov 2016 08:22:29 GMT (envelope-from joelja@bogus.com)
X-Authentication-Warning: nagasaki.bogus.com: Host [IPv6:2601:647:4201:9e61:a1e3:bb9c:8cf7:bf8b] claimed to be mbp-4.local
To: Robert Raszuk , Job Snijders 
References: <20161116113849.udbrfvdhaj3be7nx@bongo.bofh.it> <20161116130110.GK1073@dhcp-9341.meeting.ietf.org> <20161116134707.GP24817@gir.theapt.org>      <58306620.4000308@foobar.org>  <20161120100915.GC1121@Vurt.local> 
From: joel jaeggli 
Message-ID: <6e9e824a-30e0-62f8-d4a2-7189a1627f70@bogus.com>
Date: Mon, 21 Nov 2016 00:22:28 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:50.0) Gecko/20100101 Thunderbird/50.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2HF1vDplbbvl8s7HTKO1xkQVoQ9OVvSMn"
Archived-At: 
Cc: idr wg , grow@ietf.org
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 21 Nov 2016 08:22:31 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--2HF1vDplbbvl8s7HTKO1xkQVoQ9OVvSMn
Content-Type: multipart/mixed; boundary="QHE8NgUtFOSqr8oiIq06NKgUjTm6u0n4A";
 protected-headers="v1"
From: joel jaeggli 
To: Robert Raszuk , Job Snijders 
Cc: idr wg , grow@ietf.org
Message-ID: <6e9e824a-30e0-62f8-d4a2-7189a1627f70@bogus.com>
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the
 peer's syslog at shutdown
References: <20161116113849.udbrfvdhaj3be7nx@bongo.bofh.it>
 <20161116130110.GK1073@dhcp-9341.meeting.ietf.org>
 <20161116134707.GP24817@gir.theapt.org>
 
 
 
 
 
 <58306620.4000308@foobar.org>
 
 <20161120100915.GC1121@Vurt.local>
 
In-Reply-To: 

--QHE8NgUtFOSqr8oiIq06NKgUjTm6u0n4A
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US

On 11/20/16 3:21 PM, Robert Raszuk wrote:
>
>
> > I'd like to ask the chairs to move
> 'draft-ietf-idr-operational-message-00' to 'Dead' status.
>
> It bothers you so much that it is a WG doc ?
>
> Or is the issue that it does not define fixed field for plain
> telephone number to dial ?
>
Not revved since 2012 seems like a problem.

To me the sticking point with expressing more complex information as
with proposed dump state and control tlvs involves the opportunity to
hose up signaling in new interesting ways.

Whether I think they should be more expressive or not; job's proposal
has the inherent safety of arriving on a cease which I'm pretty sure
doesn't leave much to the imagination.

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




--QHE8NgUtFOSqr8oiIq06NKgUjTm6u0n4A--

--2HF1vDplbbvl8s7HTKO1xkQVoQ9OVvSMn
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iEYEARECAAYFAlgyrsQACgkQ8AA1q7Z/VrKRiQCcCJDISXIC3V8bnVTsJVQOijEC
E7EAn3A7EFdjQillL8nMEowm4oOrETUx
=GTsG
-----END PGP SIGNATURE-----

--2HF1vDplbbvl8s7HTKO1xkQVoQ9OVvSMn--


From nobody Mon Nov 21 01:03:44 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6E8012949C; Mon, 21 Nov 2016 01:03:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.398
X-Spam-Level: 
X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, SPF_HELO_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 Dt7Squ6DlW_x; Mon, 21 Nov 2016 01:03:38 -0800 (PST)
Received: from gir.theapt.org (gir.theapt.org [IPv6:2001:470:1f0b:8b2::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BE26129597; Mon, 21 Nov 2016 01:03:38 -0800 (PST)
Received: from gir.theapt.org (unknown [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/0 bits)) (Client did not present a certificate) (Authenticated sender: phessler) by gir.theapt.org (Postfix) with ESMTPSA id C0AE6788F8; Mon, 21 Nov 2016 10:03:36 +0100 (CET)
Date: Mon, 21 Nov 2016 10:03:35 +0100
From: Peter Hessler 
To: idr@ietf.org, grow@ietf.org
Message-ID: <20161121090335.GU24817@gir.theapt.org>
References:    <58306620.4000308@foobar.org> <319AD952-C571-4085-8D56-C06A51F021E3@domino.org>   <058F756D-3A68-4AA6-A9DC-63A1BF9A5184@domino.org> <20161119194138.GG47336@dhcp-9d92.meeting.ietf.org> <87DDAB88-78AC-431A-ABE7-55249BF5D654@domino.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87DDAB88-78AC-431A-ABE7-55249BF5D654@domino.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: 
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 21 Nov 2016 09:03:40 -0000

On 2016 Nov 19 (Sat) at 20:26:25 +0000 (+0000), Neil J. McRae wrote:
:I just wish I thought we had the luxury of lazy operations like this!
:

I have about 4 peers where they have exactly this kind of lazy
operators.  Some of them are big enough to know better.

I want this, because they at least look at the "show neighbor" output
before freaking out and spamming all of our support contacts.


:Neil 
:
:> On 19 Nov 2016, at 19:41, Job Snijders  wrote:
:> 
:>> On Sat, Nov 19, 2016 at 05:23:15PM +0000, Neil J. McRae wrote:
:>> It's a wonderfully useless solution when it could be a wonderfully
:>> useful solution - it's just more  operational noise that we already
:>> have and we will start filtering like everything else. 
:> 
:> What's really useless is hyperbole argumentation. :-) Don't forget to
:> recognise that your network operations might differ from how other
:> people operate their network.
:> 
:> A common pattern:
:> 
:>    supplier: "2 weeks from now at 18:00 UTC we will do maintenance XYZ on router ABC, this work is tracked in V-NOC-24789244"
:>    *two weeks pass*
:>    *supplier starts the work*
:>    *customer sees BGP session with router ABC go down*
:>    customer calls supplier's NOC: "hey my session is down, whats up!?"
:> 
:> If in the above scenario the customer had seen "V-NOC-24789244 maintenace started" in their syslog (where they started their
:> investigation), the customer would search for the V-NOC-24789244 string
:> in their mailbox and all details would become clear. I think this is
:> useful and a good starting point.
:> 
:> I suspect that where Neil is coming from, the customer would have
:> already parsed the maintenance notification 2 weeks before the
:> maintenance work, and added that to their organisational-wide calendar,
:> pre-silenced alerts, drained the traffic away, etc.
:> 
:> The "shutdown" draft is not a replacement for efforts such as
:> https://www.maintenancemanager.org/ - but maybe, when "shutdown" is more
:> ubiquitously available, it could be a component in such maintenance
:> manager toolchains.
:> 
:> Maybe in 2 or 3 years time we'll revisit the topic and based on that
:> operational experience define a taxonomy and create a structured
:> approach. Maybe the structured approach will be entirely out-of-band
:> (companies posting yang to each others' maintenance API endpoints?).  I
:> think the free form approach is an excellent starting point to see (and
:> immediately benefit) how a tool like this is used in the wild.
:> 
:> Kind regards,
:> 
:> Job


-- 
It's bad luck to be superstitious.
		-- Andrew W. Mathis


From nobody Mon Nov 21 01:55:55 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18E8212989C for ; Mon, 21 Nov 2016 01:55:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.432
X-Spam-Level: 
X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_SOFTFAIL=0.665] 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 7IjNXPta2YMU for ; Mon, 21 Nov 2016 01:55:53 -0800 (PST)
Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (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 17D0712951F for ; Mon, 21 Nov 2016 01:55:53 -0800 (PST)
Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1c8lKJ-000DLT-PR (job@us.ntt.net); Mon, 21 Nov 2016 09:55:52 +0000
Date: Mon, 21 Nov 2016 10:55:47 +0100
From: Job Snijders 
To: idr@ietf.org
Message-ID: <20161121095547.GC14994@Vurt.local>
References: <16426_1479400131_582DDAC3_16426_1669_1_53C29892C857584299CBF5D05346208A1EC87201@OPEXCNORM2F.corporate.adroot.infra.ftgroup> <20161118004548.GK1072@dhcp-9341.meeting.ietf.org> <16418_1479457940_582EBC93_16418_290_1_53C29892C857584299CBF5D05346208A1EC8DEA5@OPEXCLILM21.corporate.adroot.infra.ftgroup>  <13357_1479459134_582EC13E_13357_5786_1_53C29892C857584299CBF5D05346208A1EC8FF18@OPEXCLILM21.corporate.adroot.infra.ftgroup> <37224750-4065-40E3-B6F4-571DED698563@cisco.com> <20161119103226.GN1072@dhcp-9341.meeting.ietf.org>  <20161120095418.GA1121@Vurt.local> <14e3bc9e25534421b665cf451d853909@XCH-ALN-014.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <14e3bc9e25534421b665cf451d853909@XCH-ALN-014.cisco.com>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.7.1 (2016-10-04)
Archived-At: 
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 21 Nov 2016 09:55:54 -0000

On Mon, Nov 21, 2016 at 01:03:09AM +0000, Jakob Heitz (jheitz) wrote:
> Today, IOS-XR does not put anything into the data field when sending
> the Cease subcode 2.  If something is received, it hexdumps it in show
> bgp neighbor.
> 
> Does any other implementation put anything into the data field?

Not that I am aware of. An important point here is that your code is
already prepared for the eventuality that someone puts data in that
field, which is good! :-)

Kind regards,

Job


From nobody Mon Nov 21 06:49:55 2016
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 E15AC129A81; Mon, 21 Nov 2016 06:49:50 -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.38.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <147973979091.28633.17549931002846274226.idtracker@ietfa.amsl.com>
Date: Mon, 21 Nov 2016 06:49:50 -0800
Archived-At: 
Cc: idr@ietf.org
Subject: [Idr] I-D Action: draft-ietf-idr-tunnel-encaps-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: Mon, 21 Nov 2016 14:49: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           : The BGP Tunnel Encapsulation Attribute
        Authors         : Eric C. Rosen
                          Keyur Patel
                          Gunter Van de Velde
	Filename        : draft-ietf-idr-tunnel-encaps-03.txt
	Pages           : 40
	Date            : 2016-11-21

Abstract:
   RFC 5512 defines a BGP Path Attribute known as the "Tunnel
   Encapsulation Attribute".  This attribute allows one to specify a set
   of tunnels.  For each such tunnel, the attribute can provide the
   information needed to create the tunnel and the corresponding
   encapsulation header.  The attribute can also provide information
   that aids in choosing whether a particular packet is to be sent
   through a particular tunnel.  RFC 5512 states that the attribute is
   only carried in BGP UPDATEs that have the "Encapsulation Subsequent
   Address Family (Encapsulation SAFI)".  This document deprecates the
   Encapsulation SAFI (which has never been used), and specifies
   semantics for the attribute when it is carried in UPDATEs of certain
   other SAFIs.  This document adds support for additional tunnel types,
   and allows a remote tunnel endpoint address to be specified for each
   tunnel.  This document also provides support for specifying fields of
   any inner or outer encapsulations that may be used by a particular
   tunnel.

   This document obsoletes RFC 5512.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-idr-tunnel-encaps/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-idr-tunnel-encaps-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-tunnel-encaps-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 Martin.Hannigan@microsoft.com  Sun Nov 20 12:04:58 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0FD129518 for ; Sun, 20 Nov 2016 12:04:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.021
X-Spam-Level: 
X-Spam-Status: No, score=-2.021 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_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=microsoft.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 LUKjokcRKMG3 for ; Sun, 20 Nov 2016 12:04:56 -0800 (PST)
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0101.outbound.protection.outlook.com [104.47.32.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6DBA127076 for ; Sun, 20 Nov 2016 12:04:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=qcRfNX6z02RQBNIqe1QeIC7fzGhvPcQkwaK0OXYkSRM=; b=UU71mrGiq6W0YV5I5qzK1j6meSVbBS0IAQeAQHVjvpJqoymRcPKP97p6f3yZhZTxDp4PryH5clxVr0Je8TIW74zpIDXTwIp3fYdx3jwYdIfSBbsoCFMkQYw3tsawe/P467LMHY7Tj5rOp71aa5VNbEMBZ1nUPR1MSijD8eOBiFo=
Received: from SN1PR21MB0032.namprd21.prod.outlook.com (10.161.254.142) by SN1PR21MB0032.namprd21.prod.outlook.com (10.161.254.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.747.0; Sun, 20 Nov 2016 20:04:54 +0000
Received: from SN1PR21MB0032.namprd21.prod.outlook.com ([10.161.254.142]) by SN1PR21MB0032.namprd21.prod.outlook.com ([10.161.254.142]) with mapi id 15.01.0747.008; Sun, 20 Nov 2016 20:04:54 +0000
From: Martin Hannigan 
To: 'idr wg' 
Thread-Topic: [Idr] WG Adoption call for draft-snijders-idr-shutdown (11/16 to 11/30)
Thread-Index: AQHSQ2lcmqBqQCuZhkCmPhyQzg9nVQ==
Date: Sun, 20 Nov 2016 20:04:54 +0000
Message-ID: <39991BB5-28C6-414F-A1BE-F5132DE2E012@microsoft.com>
References: <013f01d2404d$3dfff610$b9ffe230$@ndzh.com>
In-Reply-To: <013f01d2404d$3dfff610$b9ffe230$@ndzh.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Martin.Hannigan@microsoft.com; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [73.149.114.165]
x-ms-office365-filtering-correlation-id: 1b7d18be-b292-46e2-37d7-08d411807edd
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SN1PR21MB0032;
x-microsoft-exchange-diagnostics: 1; SN1PR21MB0032; 7:sZj4CnEGi2T4CrMsPxbyaA5+ASkXMNBaLnXdkOjuIYi444ncRYK71wbOlSDYTYvpj/c0S9fAVIxCHUJDBaSHttSNXe2uwPZ82DknN4QHWOE/UQHnMq8l2X9nIQw/z4QSfa3t6Kg4z7UKRoSEO547AKDiJE6fvEmGk8Gw+jq7f97HfAFtnLrnqTdCuc6zOybtpTLeBbjKZmtQTgvc9ZfZa2leyEzfYdkSOEyz21QAi4n7v3mjX0AQ5E11X7RBHZTW9PFVeUf30e0oD5l5L19puvUV/FTTodxVy9OR30f0Bm4whQh5IYHvdes633srOiawVtUFz2/VxFmVrN8l1vm9hFKOzvYi69SG7jgQ8qB+MYjvOsCyVlbsxHSAxS52htDd50g0bjpbJRv1IZPPJsjoq++zKDi0fL7YNJrpoT8JH/9xKe4mrxPMAaN3BvrMJUvwAeGRNaTRQuua26kew8d9enlOmuYh51CDAtW3WXQ0BYY=
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(192374486261705)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6060326)(6040307)(6045199)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038)(6061324)(6041248)(6072148); SRVR:SN1PR21MB0032; BCL:0; PCL:0; RULEID:; SRVR:SN1PR21MB0032; 
x-forefront-prvs: 0132C558ED
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(199003)(377454003)(189002)(2906002)(83716003)(82746002)(6916009)(2950100002)(101416001)(77096005)(189998001)(92566002)(68736007)(2900100001)(6506003)(6512003)(110136003)(606004)(86362001)(97736004)(87936001)(10090500001)(5005710100001)(38730400001)(86612001)(10290500002)(107886002)(81156014)(3280700002)(229853002)(3846002)(6116002)(102836003)(8936002)(81166006)(3660700001)(66066001)(36756003)(5660300001)(50986999)(54356999)(7736002)(7846002)(76176999)(105586002)(99286002)(450100001)(106356001)(122556002)(106116001)(33656002)(8676002)(230783001)(22906008)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR21MB0032; H:SN1PR21MB0032.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_39991BB528C6414FA1BEF5132DE2E012microsoftcom_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Nov 2016 20:04:54.6276 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR21MB0032
Archived-At: 
X-Mailman-Approved-At: Mon, 21 Nov 2016 08:33:42 -0800
Subject: Re: [Idr] WG Adoption call for draft-snijders-idr-shutdown (11/16 to 11/30)
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, 20 Nov 2016 20:05:44 -0000

--_000_39991BB528C6414FA1BEF5132DE2E012microsoftcom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

DQoNClRoaXMgaXMgdXNlZnVsLiBPbiB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMsIEnigJlt
IGhhdmluZyBhIGxpdHRsZSBiaXQgb2YgYSBmYWlsIGdyb2traW5nIHdoYXQgdmlzdWFsIHNwb29m
aW5nIG1lYW5zIGluIHRoaXMgY2FzZT8gSXMgdGhlcmUgd2F5IHRvIHNwb29mIGEgY2Vhc2UgbWVz
c2FnZSBmcm9tIGEgdGhpcmQgcGFydHkgYW5kIGNyZWF0ZSBhIG1lc3NhZ2UgbGlrZSDigJx0ZWFy
IGRvd24sIGdvbmUgZm9yZXZlcuKAnSBpbiBhbiB1bnNlY3VyZWQgKG5vdCBNRDUgb3Igb3RoZXIg
c2VjdXJlZCBtZWNoYW5pc20pIG9yIGlzIHRoZSByZWZlcmVuY2UgdG8gVVRSMzYgbW9yZSBwZXJm
dW5jdG9yeSBhbmQgYWxvbmcgdGhlIGxpbmVzIG9mIOKAnGRvbuKAmXQgc2VuZCBtb25leSB0byBz
b21lb25lIHNlbmRpbmcgYSByZXF1ZXN0IGluIHRoaXMgbWVzc2FnZSBpbmNsdWRpbmcgZXhhbXBs
ZUBzYW1wbGUuY29tPG1haWx0bzpleGFtcGxlQHNhbXBsZS5jb20+IGFzIGEgdGFyZ2V0IGFkZHJl
c3M/IEFueSByZWFsIGNvbmNlcm4gb3ZlciBidWZmZXIgb3ZlcmZsb3dzPw0KDQpCZXN0LA0KDQot
TTwNCg0KDQoNCkZyb206IElkciA8aWRyLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBT
dXNhbiBIYXJlcyA8c2hhcmVzQG5kemguY29tPg0KRGF0ZTogV2VkbmVzZGF5LCBOb3ZlbWJlciAx
NiwgMjAxNiBhdCA0OjA2IFBNDQpUbzogJ2lkciB3ZycgPGlkckBpZXRmLm9yZz4NClN1YmplY3Q6
IFtJZHJdIFdHIEFkb3B0aW9uIGNhbGwgZm9yIGRyYWZ0LXNuaWpkZXJzLWlkci1zaHV0ZG93biAo
MTEvMTYgdG8gMTEvMzApDQpSZXNlbnQtRnJvbTogSm9iIFNuaWpkZXJzIDxqb2JAbnR0Lm5ldD4N
ClJlc2VudC1UbzogPG1hcnRpbi5oYW5uaWdhbkBtaWNyb3NvZnQuY29tPg0KUmVzZW50LURhdGU6
IFdlZG5lc2RheSwgTm92ZW1iZXIgMTYsIDIwMTYgYXQgNzo0OCBQTQ0KDQpUaGlzIGJlZ2lucyBh
IDIgd2VlayBXRyBBZG9wdGlvbiBjYWxsIGZvciBkcmFmdC1zbmlqZGVycy1pZHItc2h1dGRvd24g
KDExLzE2LzIwMTYgdG8gMTEvMzAvMjAxNikuICAgVGhlIGRpc2N1c3Npb24gc2hvdWxkIGNvbnNp
ZGVyIHdoZXRoZXIgdGhpcyBpcyB1c2VmdWwgdG8gb3BlcmF0b3JzIGFuZCB0ZWNobmljYWwgaXNz
dWVzLg0KDQoNClN1ZQ0K

--_000_39991BB528C6414FA1BEF5132DE2E012microsoftcom_
Content-Type: text/html; charset="utf-8"
Content-ID: <01E17471C8C7A2409838CEF732D1A5FF@namprd21.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
cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj5UaGlzIGlzIHVzZWZ1bC4gT24gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRp
b25zLCBJ4oCZbSBoYXZpbmcgYSBsaXR0bGUgYml0IG9mIGEgZmFpbCBncm9ra2luZyB3aGF0IHZp
c3VhbCBzcG9vZmluZyBtZWFucyBpbiB0aGlzIGNhc2U/IElzIHRoZXJlIHdheSB0byBzcG9vZiBh
IGNlYXNlIG1lc3NhZ2UgZnJvbSBhIHRoaXJkIHBhcnR5IGFuZCBjcmVhdGUgYSBtZXNzYWdlIGxp
a2Ug4oCcdGVhciBkb3duLCBnb25lIGZvcmV2ZXLigJ0NCiBpbiBhbiB1bnNlY3VyZWQgKG5vdCBN
RDUgb3Igb3RoZXIgc2VjdXJlZCBtZWNoYW5pc20pIG9yIGlzIHRoZSByZWZlcmVuY2UgdG8gVVRS
MzYgbW9yZSBwZXJmdW5jdG9yeSBhbmQgYWxvbmcgdGhlIGxpbmVzIG9mIOKAnGRvbuKAmXQgc2Vu
ZCBtb25leSB0byBzb21lb25lIHNlbmRpbmcgYSByZXF1ZXN0IGluIHRoaXMgbWVzc2FnZSBpbmNs
dWRpbmcNCjxhIGhyZWY9Im1haWx0bzpleGFtcGxlQHNhbXBsZS5jb20iPmV4YW1wbGVAc2FtcGxl
LmNvbTwvYT4gYXMgYSB0YXJnZXQgYWRkcmVzcz8gQW55IHJlYWwgY29uY2VybiBvdmVyIGJ1ZmZl
ciBvdmVyZmxvd3M/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJlc3QsPG86cD48L286cD48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPi1NJmx0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBz
dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6
My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9
ImNvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+
SWRyICZsdDtpZHItYm91bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mIFN1c2FuIEhhcmVz
ICZsdDtzaGFyZXNAbmR6aC5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPldlZG5lc2RheSwgTm92
ZW1iZXIgMTYsIDIwMTYgYXQgNDowNiBQTTxicj4NCjxiPlRvOiA8L2I+J2lkciB3ZycgJmx0O2lk
ckBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+W0lkcl0gV0cgQWRvcHRpb24gY2Fs
bCBmb3IgZHJhZnQtc25pamRlcnMtaWRyLXNodXRkb3duICgxMS8xNiB0byAxMS8zMCk8YnI+DQo8
Yj5SZXNlbnQtRnJvbTogPC9iPkpvYiBTbmlqZGVycyAmbHQ7am9iQG50dC5uZXQmZ3Q7PGJyPg0K
PGI+UmVzZW50LVRvOiA8L2I+Jmx0O21hcnRpbi5oYW5uaWdhbkBtaWNyb3NvZnQuY29tJmd0Ozxi
cj4NCjxiPlJlc2VudC1EYXRlOiA8L2I+V2VkbmVzZGF5LCBOb3ZlbWJlciAxNiwgMjAxNiBhdCA3
OjQ4IFBNPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PlRoaXMgYmVnaW5zIGEgMiB3ZWVrIFdHIEFkb3B0aW9uIGNhbGwgZm9yIGRyYWZ0LXNuaWpkZXJz
LWlkci1zaHV0ZG93biAoMTEvMTYvMjAxNiB0byAxMS8zMC8yMDE2KS4gJm5ic3A7Jm5ic3A7VGhl
IGRpc2N1c3Npb24gc2hvdWxkIGNvbnNpZGVyIHdoZXRoZXIgdGhpcyBpcyB1c2VmdWwgdG8gb3Bl
cmF0b3JzIGFuZCB0ZWNobmljYWwgaXNzdWVzLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu
YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U3VlIDxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_39991BB528C6414FA1BEF5132DE2E012microsoftcom_--


From nobody Mon Nov 21 08:54:26 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29335129590 for ; Mon, 21 Nov 2016 08:54:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.432
X-Spam-Level: 
X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_SOFTFAIL=0.665] 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 SV7ZxvfEw46D for ; Mon, 21 Nov 2016 08:54:23 -0800 (PST)
Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (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 A3A78129570 for ; Mon, 21 Nov 2016 08:54:23 -0800 (PST)
Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1c8rrJ-0005Y1-RY (job@us.ntt.net); Mon, 21 Nov 2016 16:54:23 +0000
Date: Mon, 21 Nov 2016 17:54:18 +0100
From: Job Snijders 
To: Martin Hannigan 
Message-ID: <20161121165418.GI1236@Hanna.local>
References: <013f01d2404d$3dfff610$b9ffe230$@ndzh.com> <39991BB5-28C6-414F-A1BE-F5132DE2E012@microsoft.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <39991BB5-28C6-414F-A1BE-F5132DE2E012@microsoft.com>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.7.1 (2016-10-04)
Archived-At: 
Cc: 'idr wg' 
Subject: Re: [Idr] WG Adoption call for draft-snijders-idr-shutdown (11/16 to 11/30)
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, 21 Nov 2016 16:54:25 -0000

On Sun, Nov 20, 2016 at 08:04:54PM +0000, Martin Hannigan wrote:
> This is useful. On the security considerations, I’m having a little
> bit of a fail grokking what visual spoofing means in this case? Is
> there way to spoof a cease message from a third party and create a
> message like “tear down, gone forever†in an unsecured (not MD5 or
> other secured mechanism) or is the reference to UTR36 more perfunctory
> and along the lines of “don’t send money to someone sending a request
> in this message including example@sample.com as a target address?

Visual spoofing exists in (at least) two forms, one is on the character
level: where innocuous characters are replaced with variants for
nefarious purposes, for example the following look alike but are
different: Greek Ο, Latin O, and Cyrillic О. The other variant is where
somehow a newline, newpage, feedpage or enough spaces to wrap the line
are inserted, and the receiving side might incorrectly think there are
more than 1 syslog messages where in reality its just 1 message,
containing a communication + syslog-like content.

To counter this the length of the string is limited to be very brief. If
one is allowed to insert say 4000 bytes worth of Shutdown Communication,
you could easily 'visually spoof' half a page worth of fake-syslog. The
receiving side might think his/her router is in big trouble and perform
an emergency reboot or upgrade based on false information.

Further reading: (search bing.com for 'visual spoofing')

    https://en.wikipedia.org/wiki/IDN_homograph_attack
    http://unicode.org/reports/tr36/#visual_spoofing

Another defense is to squash likely garbage and not print that. So one
should replace the garbage with U+FFFD "replacement character" so that
"drã©op table XXX;" becomes "dr�op table XXX;" and not "drop table
XXX;". The next version of the draft will provide more guidance on that.

This draft is breaking a lance for IDR in that it is the first draft (as
far as I know) to carefully consider the security aspects of using UTF-8
at this level.

I think UTF-8 is the right choice, it can be done (many industries have
gone before us), there is more than Roman script in this world, but
we'll need to make implementors aware.

> Any real concern over buffer overflows?

The clearly defined upperbound length of the BGP PDU, the Cease
NOTIFICATION and the length marker for the Shutdown Communication itself
can help mitigate these. I don't think there are any real new
considerations here. Normal printf, strlcpy, strlcat recommendations
apply. It was an explicit choice to not use a NUL-termination.

I welcome feedback from others, I wouldn't dare to proclaim I'm anything
close to an expert.

Kind regards,

Job


From nobody Mon Nov 21 10:04:01 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8DEA129672 for ; Mon, 21 Nov 2016 10:03:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AY4Mlyuwq3Jc for ; Mon, 21 Nov 2016 10:03:56 -0800 (PST)
Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c: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 57031129465 for ; Mon, 21 Nov 2016 10:03:56 -0800 (PST)
Received: by mail-wm0-x22c.google.com with SMTP id t79so158834612wmt.0 for ; Mon, 21 Nov 2016 10:03:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qR3jK4Dxiv1U9/kG7fYl92FIao4VCPfFchJNfw6a1d4=; b=IXZ+e6acX3L/MDqObMLGlBRJl/pI0+0Rkq4/7sr42wAufLEWWwnrvfsqHnjo9ywIXZ Nngo5kDhHbLj3K8Aho/wu3WnpFzmnWYs/JoYMwIOl6Iyn/42uMhQC/hjVS1Qu5xFNM58 Cjhu8/J98j2i7qImN/fj+Vp0ZKtvSG59OOiLhnjPdFnieVf/WjTGBcdJO8FxsJelQM8q hZyj0reuST909mN4h22+oZxJROE0krA2JBFYwwg2C/zNZsTSzRq3PH/iwVIHnzgD/9zm PPtDd8t1Jj86y790wuErRclaWH0exsxaH2CSqS/lrvVdoC9Rb5ekXpywXMLSe+nCiGUk 7KcA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qR3jK4Dxiv1U9/kG7fYl92FIao4VCPfFchJNfw6a1d4=; b=SeLWtlQKQWO/tyBohhtZFSGo7kVlwjkeeGhkgCRvDu32qBctMBusKEZMHKz43cgG9N kMVGVP/uDkVyafYyR0CaK+kZBFOCRvMZBqF0dMLdLbPvqXyp5HESTEnR+lddvVe5+vB0 9jb7AbBEodVreO6zrI6vlGsKSBCeeoursr2Tk8AW7rQs/5ocMQF+CJBpVmrKX/RyUu7F rx8mBiBvWRz26lAzyxBFo0KnHN9gs4JMU36gXeZVM0SZLLqOl61sX4acHNvjgc54qJV1 tIF39S63czPeTjAwyKjCeWPFSK454Pr1eD0rI9Mnk075/SL5AC48S3M/gxd0m4sjdt8C LNBg==
X-Gm-Message-State: AKaTC02jKkc4Ge0IWgSmHA7CSSAQGdoDyQx6AxYK0tQ0ePcygRS7cSlo85ipmIWk94wWbWeinvj85SqE5RPBEQ==
X-Received: by 10.28.130.66 with SMTP id e63mr16287098wmd.39.1479751434876; Mon, 21 Nov 2016 10:03:54 -0800 (PST)
MIME-Version: 1.0
Received: by 10.28.69.4 with HTTP; Mon, 21 Nov 2016 10:03:53 -0800 (PST)
In-Reply-To: <20161121165418.GI1236@Hanna.local>
References: <013f01d2404d$3dfff610$b9ffe230$@ndzh.com> <39991BB5-28C6-414F-A1BE-F5132DE2E012@microsoft.com> <20161121165418.GI1236@Hanna.local>
From: jim deleskie 
Date: Mon, 21 Nov 2016 14:03:53 -0400
Message-ID: 
To: Job Snijders 
Content-Type: multipart/alternative; boundary=001a1144364ca1bde80541d37a8f
Archived-At: 
Cc: idr wg 
Subject: Re: [Idr] WG Adoption call for draft-snijders-idr-shutdown (11/16 to 11/30)
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, 21 Nov 2016 18:04:00 -0000

--001a1144364ca1bde80541d37a8f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I understand people may want the characters in their language, but is there
a technical reason for UTF-8, like many of you I've worked with many
engineers, in ehe past 20 years,for who english is not their native
language. I suspect many of those of you that know me have questioned if it
is mine :)  However  these engineers typically, while thinking in their
first language, "work" in english, as its the defacto standard, much like
with air travel.


-jim

On Mon, Nov 21, 2016 at 12:54 PM, Job Snijders  wrote:

> On Sun, Nov 20, 2016 at 08:04:54PM +0000, Martin Hannigan wrote:
> > This is useful. On the security considerations, I=E2=80=99m having a li=
ttle
> > bit of a fail grokking what visual spoofing means in this case? Is
> > there way to spoof a cease message from a third party and create a
> > message like =E2=80=9Ctear down, gone forever=E2=80=9D in an unsecured =
(not MD5 or
> > other secured mechanism) or is the reference to UTR36 more perfunctory
> > and along the lines of =E2=80=9Cdon=E2=80=99t send money to someone sen=
ding a request
> > in this message including example@sample.com as a target address?
>
> Visual spoofing exists in (at least) two forms, one is on the character
> level: where innocuous characters are replaced with variants for
> nefarious purposes, for example the following look alike but are
> different: Greek =CE=9F, Latin O, and Cyrillic =D0=9E. The other variant =
is where
> somehow a newline, newpage, feedpage or enough spaces to wrap the line
> are inserted, and the receiving side might incorrectly think there are
> more than 1 syslog messages where in reality its just 1 message,
> containing a communication + syslog-like content.
>
> To counter this the length of the string is limited to be very brief. If
> one is allowed to insert say 4000 bytes worth of Shutdown Communication,
> you could easily 'visually spoof' half a page worth of fake-syslog. The
> receiving side might think his/her router is in big trouble and perform
> an emergency reboot or upgrade based on false information.
>
> Further reading: (search bing.com for 'visual spoofing')
>
>     https://en.wikipedia.org/wiki/IDN_homograph_attack
>     http://unicode.org/reports/tr36/#visual_spoofing
>
> Another defense is to squash likely garbage and not print that. So one
> should replace the garbage with U+FFFD "replacement character" so that
> "dr=C3=83=C2=A3=C3=82=C2=A9op table XXX;" becomes "dr=EF=BF=BDop table XX=
X;" and not "drop table
> XXX;". The next version of the draft will provide more guidance on that.
>
> This draft is breaking a lance for IDR in that it is the first draft (as
> far as I know) to carefully consider the security aspects of using UTF-8
> at this level.
>
> I think UTF-8 is the right choice, it can be done (many industries have
> gone before us), there is more than Roman script in this world, but
> we'll need to make implementors aware.
>
> > Any real concern over buffer overflows?
>
> The clearly defined upperbound length of the BGP PDU, the Cease
> NOTIFICATION and the length marker for the Shutdown Communication itself
> can help mitigate these. I don't think there are any real new
> considerations here. Normal printf, strlcpy, strlcat recommendations
> apply. It was an explicit choice to not use a NUL-termination.
>
> I welcome feedback from others, I wouldn't dare to proclaim I'm anything
> close to an expert.
>
> Kind regards,
>
> Job
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>

--001a1144364ca1bde80541d37a8f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable











I understand people may want=
 the characters in their language, but is there a technical reason for UTF-=
8, like many of you I've worked with many engineers, in=C2=A0ehe=
 past 20 years,for who english is not their native language. I suspect many=
 of those of you that know me have questioned if it is mine :) =C2=A0Howeve=
r =C2=A0these engineers typically, while thinking in their first language, =
"work" in english, as its the defacto standard, much like with ai=
r travel.

-jim

On Mon, Nov 2=
1, 2016 at 12:54 PM, Job Snijders <job@ntt.net> wrote:
On Sun, Nov 20, 2016 at 08:04:54PM +0000, Martin Han=
nigan wrote:

> This is useful. On the security considerations, I=E2=80=99m having a l=
ittle

> bit of a fail grokking what visual spoofing means in this case? Is

> there way to spoof a cease message from a third party and create a

> message like =E2=80=9Ctear down, gone forever=E2=80=9D in an unsecured=
 (not MD5 or

> other secured mechanism) or is the reference to UTR36 more perfunctory=


> and along the lines of =E2=80=9Cdon=E2=80=99t send money to someone se=
nding a request

> in this message including exampl=
e@sample.com as a target address?



Visual spoofing exists in (at least) two forms, one is on the character

level: where innocuous characters are replaced with variants for

nefarious purposes, for example the following look alike but are

different: Greek =CE=9F, Latin O, and Cyrillic =D0=9E. The other variant is=
 where

somehow a newline, newpage, feedpage or enough spaces to wrap the line

are inserted, and the receiving side might incorrectly think there are

more than 1 syslog messages where in reality its just 1 message,

containing a communication + syslog-like content.



To counter this the length of the string is limited to be very brief. If
one is allowed to insert say 4000 bytes worth of Shutdown Communication,
you could easily 'visually spoof' half a page worth of fake-syslog.=
 The

receiving side might think his/her router is in big trouble and perform

an emergency reboot or upgrade based on false information.



Further reading: (search bing.com for 'visual spoofing')



=C2=A0 =C2=A0 https://en.wikipedia.org/wiki/I=
DN_homograph_attack

=C2=A0 =C2=A0 http://unicode.org/reports/tr36/#=
visual_spoofing



Another defense is to squash likely garbage and not print that. So one

should replace the garbage with U+FFFD "replacement character" so=
 that

"dr=C3=83=C2=A3=C3=82=C2=A9op table XXX;" becomes "dr=EF=BF=
=BDop table XXX;" and not "drop table

XXX;". The next version of the draft will provide more guidance on tha=
t.



This draft is breaking a lance for IDR in that it is the first draft (as
far as I know) to carefully consider the security aspects of using UTF-8
at this level.



I think UTF-8 is the right choice, it can be done (many industries have

gone before us), there is more than Roman script in this world, but

we'll need to make implementors aware.



> Any real concern over buffer overflows?



The clearly defined upperbound length of the BGP PDU, the Cease

NOTIFICATION and the length marker for the Shutdown Communication itself
can help mitigate these. I don't think there are any real new

considerations here. Normal printf, strlcpy, strlcat recommendations

apply. It was an explicit choice to not use a NUL-termination.



I welcome feedback from others, I wouldn't dare to proclaim I'm any=
thing

close to an expert.



Kind regards,



Job




_______________________________________________

Idr mailing list

Idr@ietf.org

https://www.ietf.org/mailman/listinfo/idr





--001a1144364ca1bde80541d37a8f--


From nobody Mon Nov 21 10:23:31 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21900129B3E for ; Mon, 21 Nov 2016 10:23:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.398
X-Spam-Level: 
X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.497, 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 hzPQjHoUoPAx for ; Mon, 21 Nov 2016 10:23:22 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA88129603 for ; Mon, 21 Nov 2016 10:23:21 -0800 (PST)
Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id 510291E337; Mon, 21 Nov 2016 13:26:25 -0500 (EST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_63B0BC3C-39EF-41EB-81A8-2578F362D352"
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
From: Jeffrey Haas 
In-Reply-To: 
Date: Mon, 21 Nov 2016 13:23:20 -0500
Message-Id: <2A27EAB2-2057-4BC5-9D47-49316D58D601@pfrc.org>
References: <013f01d2404d$3dfff610$b9ffe230$@ndzh.com> <39991BB5-28C6-414F-A1BE-F5132DE2E012@microsoft.com> <20161121165418.GI1236@Hanna.local> 
To: jim deleskie 
X-Mailer: Apple Mail (2.3251)
Archived-At: 
Cc: idr wg 
Subject: Re: [Idr] WG Adoption call for draft-snijders-idr-shutdown (11/16 to 11/30)
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, 21 Nov 2016 18:23:28 -0000

--Apple-Mail=_63B0BC3C-39EF-41EB-81A8-2578F362D352
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Jim,

> On Nov 21, 2016, at 1:03 PM, jim deleskie  wrote:
>=20
> I understand people may want the characters in their language, but is =
there a technical reason for UTF-8, like many of you I've worked with =
many engineers, in ehe past 20 years,for who english is not their native =
language. I suspect many of those of you that know me have questioned if =
it is mine :)  However  these engineers typically, while thinking in =
their first language, "work" in english, as its the defacto standard, =
much like with air travel.
>=20
>=20

Minimally, the IESG tends to require that anything that contains textual =
strings use UTF-8 encoding.  Internationalization needs to be considered =
up front in IETF protocol and related work.  Whether an implementation =
chooses to support a subset of behaviors is up to the implementors.  =
(E.g. ASCII only.)

-- Jeff=

--Apple-Mail=_63B0BC3C-39EF-41EB-81A8-2578F362D352
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

Jim,

On Nov 21, 2016, at 1:03 PM, =
jim deleskie <deleskie@gmail.com> wrote:

I understand =
people may want the characters in their language, but is there a =
technical reason for UTF-8, like many of you I've worked with many =
engineers, in ehe past 20 years,for who english is not their =
native language. I suspect many of those of you that know me have =
questioned if it is mine :)  However  these engineers =
typically, while thinking in their first language, "work" in english, as =
its the defacto standard, much like with air travel.


Minimally, the IESG tends to require =
that anything that contains textual strings use UTF-8 encoding. =
 Internationalization needs to be considered up front in IETF =
protocol and related work.  Whether an implementation chooses to =
support a subset of behaviors is up to the implementors.  (E.g. =
ASCII only.)

-- =
Jeff
=

--Apple-Mail=_63B0BC3C-39EF-41EB-81A8-2578F362D352--


From nobody Mon Nov 21 12:40:13 2016
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 7D8A4127058; Mon, 21 Nov 2016 12:40:11 -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.38.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <147976081150.16202.3511899590425487972.idtracker@ietfa.amsl.com>
Date: Mon, 21 Nov 2016 12:40:11 -0800
Archived-At: 
Cc: idr@ietf.org
Subject: [Idr] I-D Action: draft-ietf-idr-large-community-09.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, 21 Nov 2016 20:40:11 -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 Large Communities
        Authors         : Jakob Heitz
                          Job Snijders
                          Keyur Patel
                          Ignas Bagdonas
                          Nick Hilliard
	Filename        : draft-ietf-idr-large-community-09.txt
	Pages           : 9
	Date            : 2016-11-21

Abstract:
   This document describes the BGP Large Communities attribute, an
   extension to BGP-4.  This attribute provides a mechanism to signal
   opaque information within separate namespaces to aid in routing
   management.  The attribute is suitable for use with four-octet
   Autonomous System Numbers.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-idr-large-community/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-idr-large-community-09

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-large-community-09


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

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


From nobody Mon Nov 21 14:19:01 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2C6C127735; Mon, 21 Nov 2016 14:18:56 -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 0EX7QlVKz3ws; Mon, 21 Nov 2016 14:18:55 -0800 (PST)
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0105.outbound.protection.outlook.com [104.47.33.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 AD1CE1293E0; Mon, 21 Nov 2016 14:18:54 -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=QwlInBF9dUHiqqvWZ08n1NPNiDu8W/B6oLiatvuNo5c=; b=iNoKxfPhAMsAFTtYaa2SJXqeAp49Oof5HxczAyIVncNoTRgk9vYYq0IDBCDXisthNZo5C3MnlNBYwD9TcTVv3UxorOLNWQzOj0zPp0ZFO3Kbcdt+QTGnx/yLFSPmQXRay+4s+e1CxFuop8bYftOEJWq+XWHyCdJpeBTU9TVWAoI=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; 
Received: from [172.29.34.242] (66.129.241.12) 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.747.5; Mon, 21 Nov 2016 22:18:52 +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: <20161120100915.GC1121@Vurt.local>
Date: Mon, 21 Nov 2016 17:18:46 -0500
Content-Transfer-Encoding: quoted-printable
Message-ID: <7F786328-3D43-4C18-819D-927049A8E7FF@juniper.net>
References: <20161116113849.udbrfvdhaj3be7nx@bongo.bofh.it> <20161116130110.GK1073@dhcp-9341.meeting.ietf.org> <20161116134707.GP24817@gir.theapt.org>      <58306620.4000308@foobar.org>  <20161120100915.GC1121@Vurt.local>
To: Job Snijders 
X-Mailer: Apple Mail (2.3124)
X-Originating-IP: [66.129.241.12]
X-ClientProxiedBy: BLUPR0201CA0032.namprd02.prod.outlook.com (10.163.116.42) To CY1PR05MB2507.namprd05.prod.outlook.com (10.167.10.134)
X-MS-Office365-Filtering-Correlation-Id: 05cb4940-4095-4b90-3d62-08d4125c6075
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR05MB2507;
X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 3:gsb0/1qPnUPSNPVM6qo9RQaD4pDR8gjxl++lVAxQJzjZ7p3fd3lV8nImtHpWszPlmgEIqYK1koP5WaF1lu70JyyyZ9L/HOTOTcL/K0wxhtrGBIvdX77rz9Tb7iu/AH/tboZ7hBqmmh4NHciBsRZ+UL9ma30PgJOSRNI3u5By3pN3c/BxHpGOwdHQWUxIRKSPw657dhAeKKUJ8cvSbUuUmaNu8IKyDLBJ0MCn31Lb1hbzSBfBWoDuhx4KFQKUYto3I6fPM17Fe9lHYLBwRtCnWA==
X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 25:uHNyPG4bAZixhZrUERiz+x57saUDGvojg/rHam1Fg9COOFN1qhQvP0YimskehsFY1WCKrtUo3X/3cZug3WHEYuH9TqynBE1AznzZBbtxMz0B+w229NSYQEcnWKKNWpuVPv/s1flB4KFMuM8ddOXzJ45leQxpuxOeGJSBLbq6a817BB+skXZJ0As/z8Y2scKrFR0/cMjs0eu5vqGuAJWQDho/vlOinHN3bNgoRueFwWMDakR0mxJHVZZFMxzZqfKE9n3bRpWz745I7E6OHDSckVIQN2fPWMeIn2S1b2h/JG8VYauG4jdJZ/ZZfcywJCOwPOqyyMGtGZN0IA4wc3GPaNvkID7FRp29eKwlGyXAvkXCWJ2tWlhu3cZH0TEmRLWUAv7EG2Rg/BnXUywkunU1JciElcKMVazXt2aFCUVIELyJTqfvwMVzNzcn/2FIGAX+MnWjuNU9WfTLakq4YFxtJ9Y1POBZPfUSLoRiNa6Mue368pGPc8Ple+KfOZH1Q4h33ttbzSljZftleGG78ZWPAaRp2WOeILGDCP7aHXCPrXfgsIT67xsV5AI8k5ZMQT/QdsP5VuIeCOQTQhTLCakvDhLlq95Q73PEcZgBa42WvAisqKZSxaK20MnwRW0PIRj6TYV6hkoc8nAE/dugaJngIaQVsv3Hmb0BqXKyofT+81HoBpZ5pGYnZpwGRKIyiP5XA/i2+OE/uFxSP+bExtiK0KvamoyjA1QOkZZSh3Q15JITqlx4tLhWw9kBeFeHB3S2
X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 31:s2s0fFVtkU7nHXGxphMM6VJ9wU80eBW6pl75dXph0MgIR1iT/5Jn1KJ+1eqYPD3xgDKZ3f3aRTiZ4xQDdlHdTPaDVTv5n+sAcI6mXM/qKyTcEiJtmzP7ZvB0jpJYS4rS3gic9n8ioQgZc4X6JbZ3foBeN3IxhUhXCgx2HDUKTu2LZ2fnyarpy/ZdZvhL4HPCrD/SdqgQi1xk3PMZDFTJY3UWt4R++8q0GsZMjzQQWIvyT7RWqghoSgq2/zJppi/0asnGFh86BqgaArWXQn7IzVGkCuLfRUXkS1cXlq3JfUs=; 20:2Jwnc09D6Ncfh1z6QogzDyiw9Ag14p2mA5o1Fk/4YCbpqXbftAj7PGV1WZfB8T9CD4TzqM+gu1d5XgFxyJZ2A1+tkQShLbItNb0Ewb7yFQ9MNxMuFbDUsC6uVDbpp2O95W0mym5OE9824QE/hAj7Xe2oOB930jQpUeUQNtrfnnMFBrVhh8fXDr46Lelu5jGbr1KpJKgDWYdqeBYQWUy/cPEgmdog//78ihv/9lHq3Yk6A8Sf+BhruQfNWTxSp7lYfyvPQ42gPXekcypQijr2lPUT4DeVPyytB7E0HavadKfcezG30vd4RBbGHarX7bheplC9P+NrfDRKChx+Df3uB/92MAWxVhzEQqqHrE0C0TyzqfSAlstCwN3t4V9NY/Mst7V6VtkYqO+Bcs0XE2eFz6wI8mg+LxLn0sLJXNBEmJuNmqlzhQd+EQUx+Tx79pmtf+7sivP/R6W3LTkB9hMbLpmELJiXkWdTAkqZYAJNnZfT3MOCpKrPXy7SAdu8yHY97r3Qoxygp2AEiwIncrMw4M4Fk9vsIH5F8yepuZulQQwgwd+Pde7zTHUTJ5GpeD3WPe6vDlQGRELeb2gUSD0hCtV+8P5GPBXntX2rTe1J2ms=
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6060326)(6040307)(6045199)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(6061324)(6072148)(6042181); SRVR:CY1PR05MB2507; BCL:0; PCL:0; RULEID:; SRVR:CY1PR05MB2507; 
X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 4:3eYRBiCe/d84k9x2VeiNJKL5PUZezwTeH/QT4e5BnvIuBF3SI6rJ3NuapMF6e8N4WGC/sTaT4AYGmdBjxUUPHjB80Pe9oaZSFQ9V+P44yTbLqhAV6n5rW1CcrpTrn8VydF0aTwoMu33a7vEmBEW6JKIGjGxF3liz0V7aUNzJCYk3UrBKXhcWdf1jb9wMdXblXLO7O6eizQtkVLW+D3VGjmpK6e/FNX48dkH++YCAc90t9Derm+wYLzO1SX9GN920snaziaz8RvySU9417rJvC7/umAN/W3QVsynWffTx01uO5QjKG4dOlnvOOHWcHgBreP/gFxyq4iP6tzzsl65arYX29DVSsioEUxhtA1cyQhKy+f+tz4GGUE3SvxxKU8nQuyG5H5HGqR/stptvTbfZU40f9IhJv4fqx8Pkpsox9+q2yqG4u69ihxxHnmPT92YGzZ56gFmVMcUAWN8IBFAUxuhVEyS0ozfJFbJr4hv1IAHFx8vuIEU+2OOuArbH9Tl6/QyfpKLx1cQv2eg4dwyzBA==
X-Forefront-PRVS: 01334458E5
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(7916002)(24454002)(189002)(377454003)(199003)(5660300001)(305945005)(83716003)(47776003)(50226002)(7736002)(42186005)(97736004)(66066001)(82746002)(4326007)(68736007)(8676002)(81156014)(110136003)(2906002)(230783001)(8746002)(6916009)(6666003)(7846002)(93886004)(81166006)(2950100002)(229853002)(38730400001)(76176999)(6116002)(46406003)(50986999)(33656002)(57306001)(23726003)(3846002)(92566002)(105586002)(86362001)(101416001)(106356001)(189998001)(36756003)(97756001)(77096005)(50466002)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2507; H:[172.29.34.242]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR05MB2507; 23:P8iHXFEsL6vYe9LYzTMxoI+3aYG5Wpi8S0ERU1xUP?= =?us-ascii?Q?99i6XFgKvz6Jfh/62HaYv9MtmACSRkqpaEe8+Ls7MkZKMaGprcPU4+4tZ7dL?= =?us-ascii?Q?OZxxqaWO25E0UONNXDRTvpbR3DgvnmI24uVgHDBQ6Yj+kcn22lxvLQDpcRF9?= =?us-ascii?Q?uZlVkHaYTa+85lK3fOFpjQ3Gb8Ooq68Fsawz/cVCWqVRDSSFaj/kZQ6YNA7j?= =?us-ascii?Q?wJxrujA0768P3d68H3UcUDLdMgTsoeXWWtLwRxOTTVb2SC7SeS2PcCJPg3Nr?= =?us-ascii?Q?VGrWe4yfbtjzZMbe47e2TT4jyetxKbtb9mSq5/TcybMpxXGo4K1SM9B/NYoE?= =?us-ascii?Q?tChILYoBeRnqhZkp/SUqBGS1MKqY63J10lqKdU5ai3t20ldL0zRw/GLuoLWv?= =?us-ascii?Q?jQVua/eGr9//kHKAcy26pj5xm31T4L0InPNm43VIV9Z6k35eP62Sgyt5sDEc?= =?us-ascii?Q?UMie/LGTZieeJYvVdP+FpWFAcijRjkAx3f8VvD6a3QvgUFLR7oBfNzIqRa31?= =?us-ascii?Q?AqfqnzswBIW184uY+nxnAk9It19t5w4EYH9r5CCgVaehOm/LSZ5AFvnWQjBa?= =?us-ascii?Q?ETFJ+RiE80u2HAgSlAS4M8hOxWRslAn8EbtuchKJKjxW3H07NDtI9LTDZk2u?= =?us-ascii?Q?CB8O03fNUJFbLbly4KwcRLcs4vDHYp/xDqCn7K6Kte7ZeZ6PL/bEq4NFAyxT?= =?us-ascii?Q?2fcyZaFWmsZzXWXNRZZEXNxYOHsvaG+lqgch00OJ5xTJTjyh7LMbU832mWGN?= =?us-ascii?Q?kGmhpXfseDr6v+KzdE3hhnEZz1ugR2X9Q9SBa1N+lM4EtCMywkrDWR3OgfgM?= =?us-ascii?Q?7URum69oPiH1N4LDQg0HB6deNDFBR7BRZh8kJnVErbd/wO0ghBPywuipgfPV?= =?us-ascii?Q?Z0hFabN333omjsQKKXbREISeGS5f0+Cp0wK77F0FXM9v2VgKjvwKIAsr7iXU?= =?us-ascii?Q?3yrBDoT9N4xvDpJhsPoPS7CsGLloeXTu9pjtDZAbEChba0dwqxKQX3eQw6/N?= =?us-ascii?Q?4i7N1Ncj69XKOPW68VMvHeEqgKsh57nDqTF3SPiljAFmz9zTf/brQELcjGsZ?= =?us-ascii?Q?z4Z3aTmuhuMUreB00DpI2mG2KL8g940boTXKegkDFcmtWqfwiCYQXLtJnkMT?= =?us-ascii?Q?XJC1ri3KUIq7ly8M5OquNbVlzYre5KPcLeyptcCRSsx7wDXmpFIJxsJrAV+q?= =?us-ascii?Q?cWXRhsXZx/98E9zrj7OLNhH4M2C41cOsjhwbjHEYVuyBF9L+ptsz9kepKXCX?= =?us-ascii?Q?MoIhd6V3J9zZq+3GHX5LVTNjRAZsOyjq0dzX1I8?=
X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 6:g5Mhr7S9aYRhW3xa6GXHJWXvxlcyMl+GvfxydXmNDQmknPy7KUOukdiXLDc+5Fgu1jVhgnJQTnzcUjR+dRta/QbgrGoQKeAWJVNKURvUlif59JqRma8EVV8lDWDdO3XFXvsPe/e9TzcoxB2vAdGEqKyfCfqi/2tD5+iwRZATXZliiYTrenOKbjJZ4zxJrE+nSwFP1xDdSYb0quWWllAhieg53C0UpmHQ9C3Px/h+vY8CNnwuASeHI4slQWU0CSCwVMhuPdAgvhJw6DTbdeqUSOCiU7uLVPCXUOzbDsWOw8DlPi5egOwFoLtEso91/DCEy6SNaM9/z4+bKTFDiAJi4/kkAEH86E5m6GKE8TtTMEqZsHO4ZNXCH98q4CPHvDdtpDFbfHl0MXs5QVBPfL45i+kUV8dJcUE+535iTdtwgDLK0HxIKloPhozFU0+UGRQgTKx0Wx9pHua/hgL/25YcQ0WU6xy0jmTCDls4auU5/5SJjtRqjnDaGeNt2DliuRMm; 5:0zrb7HiOim8ixoDwFzSWJAQVwptWRt6OSrVWUlF9NEJtcpmAt8lsRHD558qsaBrQLtp6gFA6nF+9WkHUnjdKK0+2Bm9+ONv7/t7PPcNojo+BGi8rIfeshRr3JCv9bRUeATVfIgxS2SP1Z36NxcxKZA==; 24:0yG3bsEz2lmQg+yqHr/FPYLy/+yyhSJZCleSzxIlSjoXCQmKqLoNUVAbC7asqtTKlIpOAjJWvjyyYV+9L2lToOkU/SnpEg+P6Ci1f6RvM6U=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 7:6YSaDxJYS5JuRxLM38THpYSddlhbU+E+6Q8ySFOj/VXOCJpbAcFUC3UrDcn07o3VpqjVLWNcky37TZ8BRnT691BtQqGsVkEA2LXOmE5p4XXJc+k6lzuuXNgH3K3hJ1QJ8KlTDcuJnEAnuVN3QyylhiTfhTEk14SliKnFuSppktTb6OZbrk7Am67tw4ebTu3+ugCq8IsreCnHjsOQ6AHyETYh7BhLtiGgvkdvruTSbMQv7/W3WrPBbYX5Ig/tOw/gDccfg1OzV9lntQGoeBfk0BEm+UpjPwdBakBl1Rbxm5VlY+rgBSS+CNqPbsv3laUVMroDtvGHsrFSB3UTRnWUy8e+fTnV3feSSEe4dfkivTJ6mDMSErcQvkyjydsn4uKWzH3nIEbEvXkIpKhH0L5tyHaDvasVnM5XPKHhFDWqPatGqwINIfNAWJvVem6EHhc8UFxydwc4NNjkd3KMcldv3w==
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Nov 2016 22:18:52.4234 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2507
Archived-At: 
Cc: idr wg , grow@ietf.org, Robert Raszuk 
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 21 Nov 2016 22:18:57 -0000

On Nov 20, 2016, at 5:09 AM, Job Snijders  wrote:
> I'd like to ask the chairs to move =
'draft-ietf-idr-operational-message-00' to 'Dead' status.

Your request is acknowledged, but IMO beyond the scope of this =
discussion.=20

Look for a discussion of zombified drafts and what to do about them at =
our next meeting (or maybe on-list before).=20

--John=


From nobody Tue Nov 22 10:08:30 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9FDB129AC1 for ; Tue, 22 Nov 2016 10:08:28 -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 JpdiI799nx0F for ; Tue, 22 Nov 2016 10:08:27 -0800 (PST)
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0094.outbound.protection.outlook.com [104.47.32.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 949C812952D for ; Tue, 22 Nov 2016 10:05:18 -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=Cmut7dMHCwfMtsBQ9EbiaT29wjs1VHKBNZxCo+azzUE=; b=WVGz6bJPZERbj7a8yHnBKGyJfAFetg13nE9Yq9Pu0s1dVSYOblj6b+PlgtH43MC8vug3G/rEoxsWCOW1RvGsxyxLe40jAQjcYn9cw52/n6bzNz5LTnd/jQL9spvhcMgopjYm4Cfyb6PyzpHVs5ufiSK2apDv98J2n2zwusZ6oEg=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; 
Received: from [172.29.34.242] (66.129.241.12) by CY1PR05MB2508.namprd05.prod.outlook.com (10.167.10.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.747.5; Tue, 22 Nov 2016 18:05:17 +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: 
Date: Tue, 22 Nov 2016 13:05:12 -0500
Content-Transfer-Encoding: quoted-printable
Message-ID: 
References: 
To: 
X-Mailer: Apple Mail (2.3124)
X-Originating-IP: [66.129.241.12]
X-ClientProxiedBy: BN6PR20CA0022.namprd20.prod.outlook.com (10.173.158.160) To CY1PR05MB2508.namprd05.prod.outlook.com (10.167.10.135)
X-MS-Office365-Filtering-Correlation-Id: 431dfa6a-d061-4cd4-82ed-08d413021dac
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR05MB2508;
X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2508; 3:L1p9GWnBbUYkJ/W7PMkPJd/PMQWO9gVvigo9ZMexHvi8Jcxf3c3a1rx0qjYx1qzGgqorpVl3vkgVmV2hb24nJD1/YdwpoHzTKHxdBFjEvt89G1qNWySivoQ9VPVWb0gPdFlXqDbLUYaS1uu+7Ax9etJyG9nkgCOT9CbjzkT0PRgcZmem1sA5auCGZE/clWUXdxZTOqwJnAdV2wx7Hel7Lvx53Ooj+kMn5CmnSs6Q3nRN8lYYOnINPtUH+OSK/3bw1ma07NRRaWrGWd7CE0YbWg==; 25:v6BxsVptLMyzK9iKT7iDcNnpLOSHVcobUJCgZNAbjODpV7lA8fSzZuoJf3wgNGMtORAdUJNI9ddUb3R8pi9K9ETpPinbHgYwtqmwOEEAyFLSomO5cYxtV8HV7cfQlDXt0VFYZN2bDvamI/ue8oHoKgJwOehIfK3D2FdZpzQaO1WtqxKim0sBAaRnpz3VFP7KoFII6VXyKPJuBRVv/aYzAurlLJzbwNC4VFAzaY3sr4+aAQ8IbVoFWwwf4FA28tDwuTH+ZgTNfmSeD8KwemDFA+A5WwGl1OQgzo3+qJcIQTBmnHWEA9xGgWct1CuPtlDfZGdVPHURDF2GGQdCEJdh75+7TksdwZA3bl8Qp6k76nbrxbgo+9qmI112FZSJ8IAtwveMZsTndj8FYQuAQn6GnWlR81ToaFdXPQNfAeV1F/2lP2Jp5WnQTXrLx+flcErjM4UUJoB7UkL3Qu66SJ4vbw==
X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2508; 31:BD8F7Op+pEwx6WLgtvq4MNDRplJDdMikMUeTyBIxW1NeifqVHk6k3xzy3bCCFHMBX7X9pHhXmc+SdEVw1NdlHHMfFUgMHXzhXgRX0sFgLnrhbHhiODQfhVzn/+XXwgSN+KRLICeC9HNlulANrUojUzoh0Lg/pE3cpZ3oEx7GC6LycaLaIoQg6O/QGFeNfldIGCE7JX+oI07U9Y1GibY023EF/m34hnGzfbrgTDOQ2qBwZpIXHN8xDkPJNOVfM6oHC062jaYpAIXn57pxeuGAbKP6uLiQwRHVoHmUPbkF5jYwjxktUg06roRpIT8hJaWG; 20:JJJa++1vT9geL5URZRaGkVusZ0GYjDknf7rWsmop32CRbZwMLQLDLBelh3HpHHeEWD70WcpMRlZFRKQ+6L3H56P89Uop2CclEulu9X9IeT/bbsW3fmzC3JE374DraZPilk0eyWFaE7VlLpSBmaWq9bequCqWdylcqd7qf/Zx8xVPFUvIlzKU8gI3gWTD7Gg3G+4x6Jenj/JH6jtvfiKXsr8GkszFk6xQsyvMFYnEWTvV9TcDAV6hFJiVn+Z52WQiGdqdEiKMxFtZEP2gBO3SpAuw3eJCJQfdadbMyydPdolMpFGRVD4FMvNOWCfJjCAfJl68pyZO1+Q+HmHJ8AdVgjROSK0DBeGz8jq+i8UUaS8AlUE1q/FeU+jSRfjSWZQqYpE/li2v8Cb7GNSSgAxVeZZBP1WNzAOoFIr5qXE7FbGfTJ+jvgLKPV3UIRQre6KcyJAUryX/h92qiee2dReTw61EtMgMelM67L+bv1CBDef+643+C3wSBoFNHH6VY4s1SvqUQpoL6VM7g4YnTvpNNUFwML3y9HsJgk3WS38njy8YEfmjc27xN3rIM0+RWwdbgGUD88mmMN0061CCQGNK9LDoP0RqguHxN/JyToIZu4A=
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(138986009662008);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6045199)(6040307)(6060326)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6061324)(6041248)(6042181)(6072148); SRVR:CY1PR05MB2508; BCL:0; PCL:0; RULEID:; SRVR:CY1PR05MB2508; 
X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2508; 4:UB2vTc9LymgQ3AKSzpvKHy7LZy4aUE+KDoTGbVQOwLqBZ/Knpmke2jpAYqgRq74qv8Sv2EFDtq2g1whEWFNzEhBPyqcH0JRCE1VE9Y0lsQNqzVSVpZw+rC2YYfWlFn4JDIOLgO/AfkyoGFT3XLE7tr7R42DtCXRRM5lJowOPVW/SAHhlITcKA76Ikdd4LIBj3FGzx/ki22v8Z6MiA3h7MWjOLhYmeLRsv3obqxcDzSbqVo/K7qIP2OElDn9jQD9jhxrv2uIdU0kHtt++l4GqIB5wYbxnCg9HOiMfhFlGicVAXe/Q1WjJIfzfTGIBpx5b89IpmnSCc/2qN/vyIcdkRpzyZFByHQr49VIRAknUOHzv+6Ew9Rbkea28DZH3ZrEANKUwUAqv+xLEw2ghDdsTqGRsfZnH8Jk3yRRZNcv+HVh0hY30G7idQD65S2p85JCFgMEIsSpkMNi/qk8RbUD2EM7ITjWt2Odw2fegZ7OGQFwEGda5gHYd0UZ0/8NUmcfu7+Z7AG+EMrWUxluH+shXO7QqgENKoApINjbgpd3Yg0Bie8MvPsAmlC9b0opwcr0Z
X-Forefront-PRVS: 0134AD334F
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(7916002)(199003)(5423002)(189002)(24454002)(53754006)(377454003)(2950100002)(6116002)(76176999)(50986999)(83716003)(97736004)(450100001)(3846002)(23726003)(50466002)(6666003)(5660300001)(229853002)(36756003)(81166006)(8676002)(81156014)(92566002)(6916009)(38730400001)(110136003)(97756001)(189998001)(8746002)(101416001)(50226002)(77096005)(4326007)(46406003)(68736007)(86362001)(47776003)(2906002)(33656002)(66066001)(230783001)(82746002)(57306001)(7736002)(7846002)(106356001)(305945005)(2351001)(105586002)(42186005)(42262002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2508; H:[172.29.34.242]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR05MB2508; 23:GAb2jdz4EyLNx3XhK/mdp4UN/4CwagQPCUFYWNTdP?= =?us-ascii?Q?Kkpx1SJw+IqNdRW9Jx2ysXaRFnNZa8rLgUeqzR7ZY1fm4gpDC9SWBHHN4rWn?= =?us-ascii?Q?wnSxhUMU7jL1dWX0MPU0P0f5Ig85s8rXT1B0RN7mVuUk3v45kLmPJIzNwVGF?= =?us-ascii?Q?lzSpzADPVllv6eM9SZRR1yaJ2JMVfaEdMNDpGcdDZMLlwgAJtoNH1urc6U9k?= =?us-ascii?Q?hzfn7i1wUzPEUnHeGV1I5Z4S9MoBV54si8O4iIBDN1dV/Iq27Tx82VIY/BHV?= =?us-ascii?Q?TPl9drQVg17pCx3gPz9XAqeFKpEe90egPcs4MtMHIMx5OPhEY2o3FLgOPnD/?= =?us-ascii?Q?mC3xvUMQvorurqzB1kh2QXPRsuPmUgdz+4W7hUtsYy0BT8jFwwzQBkS3ip8U?= =?us-ascii?Q?nLW0ttCbMOab+/GFnklFYYcZGCnSHdM+CWOeYCHF0i2LjaU3tvs33hmx0NQ4?= =?us-ascii?Q?Ih/lpEgFDTJNzZ3MRBbPU5jDX7Qi/DbfM6HrqyRXwIqAJhF4PIj74iqlsk13?= =?us-ascii?Q?T+zFfYRZnuy4h+DhWh/lcOXRXA93MCqzhrH/A+yzf8BGt9hjkV5RMgmvgrxq?= =?us-ascii?Q?UhLQI6WFQZfC0tlsf99K8j9o/bFUmOapF/ER3KTDK5iCRfhTBQv20EzgMcJ/?= =?us-ascii?Q?Li4kAkAvtsPmYuzUQYFs9XHg4K6FwFyZtXQXfisp/+gz9SesskzGZ4DbzhpY?= =?us-ascii?Q?m9sdSRHSP/E2Txph3127QZLOjM22iosiDZs1wX8NBkNXD6tV2M5uX5LmGPE5?= =?us-ascii?Q?tcGULBKElGRuCtEu96UIOMKyNM5/sYeidBzlNv3rqACdh1o8WzUJPcBW0m2l?= =?us-ascii?Q?O+4d73RV9gYm4z7HPWJij3K9QkbxSam4UoVyakquQrNkDztwrD1znx9Kff8n?= =?us-ascii?Q?uuMauZmGVQzznqB70b79jSzoIJgkC34XeL/hBQuS/5I5ygWgM7UHQ5fBA/RY?= =?us-ascii?Q?eAoHOgLdLVXIWpb8KQzofmJajI038C+mbGdMIodTv5MTe2EGusavJNUZt+rY?= =?us-ascii?Q?I0c6exmvuyWFDTVrq3cKNUrsDJG7oAbfmxhaiEc636bMuAuYfT7aOYB+L/0R?= =?us-ascii?Q?MYtVe1rqyS420P+AjpCxu2HvG0JTlLMva1PdvJYX7isNsILMW6e13SUupXNz?= =?us-ascii?Q?QNr/TvWrx0QsX/wETzkA/fnr9r13wVXEkA5M0jjl0r39v8Vj9COYdA49Zyrp?= =?us-ascii?Q?/upiLx99yp9swKOtEDrdd+FZd4ii4FjL7QH+5QCqn6Jb2CHOcgZFX6dyyAWi?= =?us-ascii?Q?Joyan48VwbQVPg0R3W0Te2BdfSgZqhZsLc941AAMeK6drZsILXrKr2c/WB0W?= =?us-ascii?Q?PeIRSOGc8BLDhUnmfe/1EElq1WNfIOxLziPywPcanCe?=
X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2508; 6:EnxCrNLgRgnPT1tOlHF6jGC927UYAsNXRmACGq9V1EgtnopYYb1tHoXiCfDRW7B3D4m5q6HerT94NNGI6UYmqi51lvSsSQdUxyOgg0taFKaVuZqCuIEVlI7NZkMywGHCdPNB8cRUMbwMAd2ZsFCRKkQ+zJ6ex6ju++s2lbq8jWqXCnpwHrwX+r5UaCs/KEoWnRFXm/MuyEykiZ2r20YZpyKLC362xZOVNvszfpmfMKVzmpQ0/1yS5lJMeHZLiZ8x6y2Ukv7mlTYvUR1TO3hN9MLy4CfeV9Gtv4TbYcZ0lELZ+D1BrHMO39kzalXaLv1QH0SBlqTD5eEUZE3wgVeYpc9UReA98nM6iQ/uliDTFgoch8gpGbkw8AsGHnk42w6omHdM3CU9Mbdm+DQIWUXpTkN7qPnDDZYkk8z3usYMt6SxnDF3TGwSzvFBlDTwJZac7/7kRFTCBboDpPeW8lCPguva6HLq+mTbuq3er+kQxa8=; 5:aQLtkF2ZNYgq+mZkm5KNgFC1+HA9EEDcZ3EXJL05/bkVsgbFr2I9OFlhZDiFBI9ukOoE/TYeuOaKK0+zCh2JdJd1MocXWoDPk5V0/g4DisurDzvuBzmgQ1Gw0PAHoffVYK2OXgKOxff+Mw8a9yox3w==; 24:8HbgCWCmWseU9iPrb4J/zQLAR0JOug1r+o8xB8iFVx4X0cdY7OX5M/lr1dDPQ7ui6LnPPRNUKngVL3o1v/TD/Rd5Eb8fl4Un+p05smHUDcc=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2508; 7:8P01t0TLGZdzC35oDdZ1v5lXXpAxK6rZ+gyDsgQSiVrd2PWyTJIsERV2f1aNC7UhK+xxSKByBRf8J9WAhFk1AtQgNRioO060Tl5KvGmJvFmEpN0Ok8mE+0tz8Bb11+i9SH6JikcCZ5l4WChUtDuOcYVCV4s39DvnLk4AfS1wL3Lf/4Uh0MTviAtWWxsQJ7HO+EssMqKAtq6w2/cQ5Zyer79VsorPxMdgJo9xxXF9zW0FS2ourmgymLOcpj2OA6Ds0a95sBnpsVgofvoG08c2FjfG5g/F2kQWduQ9RtgEACUR1wGbxpL1KyADJ20u0DJ4V/KqdVaTb7mLfe9mukqqcO5sZHQhSSNMbXNFcKwRmvijypcZwcClJZbhwrIzIkcNE4wLsLcit4IXQD7DVyYaGSNP1QJunwzEJ6VAYGY0vXCApf7VFAATfp6pa6t9gKi2KyzRiU+Y9diX4CyQstoO7g==
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Nov 2016 18:05:17.0155 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2508
Archived-At: 
Cc: idr wg 
Subject: Re: [Idr] WGLC for draft-ietf-idr-deprecate-30-31-129-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: Tue, 22 Nov 2016 18:08:29 -0000

By the way, although it is an exceptionally silly thing to ask for in =
this case, could you please confirm that any relevant IPR has been =
disclosed (or that you know of none, of course)?

Thanks,

--John

> On Nov 16, 2016, at 10:18 AM, John G. Scudder  wrote:
>=20
> Hi All,
>=20
> As we discussed at our meeting Tuesday, this begins a working group =
last call for draft-ietf-idr-deprecate-30-31-129-00.txt. Please send =
your comments to the list by December 1.=20
>=20
> Because I am optimistically supposing this to be non-controversial, in =
interest of not cluttering up the list with "+1" I'm going to suggest we =
make this one "silence gives assent". If there is any objection, we'll =
revert to normal procedures.
>=20
> Thanks,
>=20
> --John


From nobody Tue Nov 22 10:15:49 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10CA4129660 for ; Tue, 22 Nov 2016 10:15:46 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 rhle-IqNOKnV for ; Tue, 22 Nov 2016 10:15:44 -0800 (PST)
Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003: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 15E34129A7E for ; Tue, 22 Nov 2016 10:15:12 -0800 (PST)
Received: by mail-oi0-x233.google.com with SMTP id y198so27103645oia.1 for ; Tue, 22 Nov 2016 10:15:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cfVQqkFdxQyjJgnF//Y/NL49bPUTN0ljeuSD3kOj9yE=; b=rbAVCLEjEoQEQgFRPhK6cNiMlsO6ut+kH9qGahlfE9YmVwtsGafgsyHdSU+08PeRsT uNBOeiHgQ0b7M3nv0UynpZufTmwcm8AGatl/5SLK2LQhgbx+yQT1g1426NnTyddlM5Tu hxXUcfv39mAGgwAGnwWbPAUKnvMF3nBGN9o8kXRGdJw0gH9LnaRc7ULy617kqH18iKlC 6aH98PVRa81I4FYsYCovtvB27Ei8YfTcpadCo9umM1eGl9S5LYMm4UAARhXbhKSLwSef yojVyVK5jFRZXwTnzk1+hUsgpOZe7miTCtkr7444MW1HWsMlA3c8Klhksf5UjoXU5q6B pspg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cfVQqkFdxQyjJgnF//Y/NL49bPUTN0ljeuSD3kOj9yE=; b=SQNYz4S8X/HN/k9hnIFFpS4fsiQIEzIayuwxb6PDeN8WXRpDR6GsdmDBLme2axHzv1 vVUFalAOBIxITRGXWNTvPC365zU3wuVqViez07SbzIsI0/uu4bLsjcaZ+oHiA6ZRO0mI NU7oYyQDSeouBHvBtJ3VlsY7Bwgi9L01dbuOk6LEoc3yNT7rjN0p1du6GLNh6QYfMdaC mBz93g67cApL0LJgyW/+fVdvnvBa0Nh8lzXNq//crh2G/ndDYM0XdHs0HySxPeZWpjWx 7JeuYMYrDfjYIsd3sOsPcFHx64fUHQHoCvw/Ifc/WpFaZ/Enp9KcOPKj2JuJOwR7ay3r fgjA==
X-Gm-Message-State: AKaTC00CSOw48IwncyG5aeNqFuwmvH/vrtYz5ovlY/OE8Dnfw9dMkuxhvDHquTNvinXsAJxX0bOSKP6Ib7nNqg==
X-Received: by 10.157.32.6 with SMTP id n6mr13135153ota.106.1479838512331; Tue, 22 Nov 2016 10:15:12 -0800 (PST)
MIME-Version: 1.0
References:  
In-Reply-To: 
From: Job Snijders 
Date: Tue, 22 Nov 2016 18:15:01 +0000
Message-ID: 
To: "John G. Scudder" , draft-ietf-idr-deprecate-30-31-129-00@ietf.org
Content-Type: multipart/alternative; boundary=001a113d03f2daab100541e7c08a
Archived-At: 
Cc: idr wg 
Subject: Re: [Idr] WGLC for draft-ietf-idr-deprecate-30-31-129-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: Tue, 22 Nov 2016 18:15:46 -0000

--001a113d03f2daab100541e7c08a
Content-Type: text/plain; charset=UTF-8

I appreciate the diligence.

I don't have any IPR and am not aware of any IPR related to this work.

Kind regards,

Job

On Tue, 22 Nov 2016 at 19:08, John G. Scudder  wrote:

> By the way, although it is an exceptionally silly thing to ask for in this
> case, could you please confirm that any relevant IPR has been disclosed (or
> that you know of none, of course)?
>
> Thanks,
>
> --John
>
> > On Nov 16, 2016, at 10:18 AM, John G. Scudder  wrote:
> >
> > Hi All,
> >
> > As we discussed at our meeting Tuesday, this begins a working group last
> call for draft-ietf-idr-deprecate-30-31-129-00.txt. Please send your
> comments to the list by December 1.
> >
> > Because I am optimistically supposing this to be non-controversial, in
> interest of not cluttering up the list with "+1" I'm going to suggest we
> make this one "silence gives assent". If there is any objection, we'll
> revert to normal procedures.
> >
> > Thanks,
> >
> > --John
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>

--001a113d03f2daab100541e7c08a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


I appreciate the diligence. 

I d=
on't have any IPR and am not aware of any IPR related to this work.
=

Kind regards,

Job

On Tue, 22 Nov 2016 at 19:08, John G. Scudder <jgs@juniper.net> wrote:
By the way, although it is an exceptionally silly thing to a=
sk for in this case, could you please confirm that any relevant IPR has bee=
n disclosed (or that you know of none, of course)?



Thanks,



--John



> On Nov 16, 2016, at 10:18 AM, John G. Scudder <jgs@juniper.net>=
; wrote:

>

> Hi All,

>

> As we discussed at our meeting Tuesday, this begins a working group la=
st call for draft-ietf-idr-deprecate-30-31-129-00.txt. Please send your com=
ments to the list by December 1.

>

> Because I am optimistically supposing this to be non-controversial, in=
 interest of not cluttering up the list with "+1" I'm going t=
o suggest we make this one "silence gives assent". If there is an=
y objection, we'll revert to normal procedures.

>

> Thanks,

>

> --John



_______________________________________________

Idr mailing list

Idr@i=
etf.org

https://www.ietf.org/mailman/listinfo/i=
dr




--001a113d03f2daab100541e7c08a--


From nobody Tue Nov 22 12:58:26 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3920612978C; Tue, 22 Nov 2016 12:58:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.019
X-Spam-Level: 
X-Spam-Status: No, score=-16.019 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=-1.497, 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 G1iHlJb3U82p; Tue, 22 Nov 2016 12:58:24 -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 08E201295D0; Tue, 22 Nov 2016 12:58:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=341; q=dns/txt; s=iport; t=1479848304; x=1481057904; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=LuXbbXjmVUXqWeLADEDIUHMrHGt5cjfxVGMrosjvv6c=; b=EIk0AzKF4lVFsdylw9voO6ROEP9uIoCiNv2dT119txdtWnk91AwEAWOT l6xN6PQZwhlnl6sVBZbISL+8jaRh9pK2zZmsotJOYBMLmBo1UhkwY/mcB Z67alcoQxcmb4IESV5ABCcCV2vLjFPX2C3WXl8TRiThsOeaHGdlWt9KRX Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B4AQAHsTRY/5RdJa1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgzgBAQEBAR+BYI05qXiCDoIGhiECghs/FAECAQEBAQEBAWIohGkBAQQ?= =?us-ascii?q?6TwIBCDYQMiUCBAEaiGWyJYtTAQEBAQEBAQECAQEBAQEBAQEfhj6EWooqBZpOA?= =?us-ascii?q?ZB1gWIBjlCRcQEeN4ESg3yBRYdxgQ0BAQE?=
X-IronPort-AV: E=Sophos;i="5.31,682,1473120000"; d="scan'208";a="350950234"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Nov 2016 20:58:23 +0000
Received: from XCH-RCD-015.cisco.com (xch-rcd-015.cisco.com [173.37.102.25]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id uAMKwNQA005444 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 22 Nov 2016 20:58:23 GMT
Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-015.cisco.com (173.37.102.25) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 22 Nov 2016 14:58:22 -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; Tue, 22 Nov 2016 14:58:22 -0600
From: "Jakob Heitz (jheitz)" 
To: "idr@ietf.org" , "grow@ietf.org" 
Thread-Topic: [GROW] [Idr] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
Thread-Index: AQHSQ9YrqfteY+qJ4k2CZYy9uqAGrqDlfOig
Date: Tue, 22 Nov 2016 20:58:22 +0000
Message-ID: <58f468c578b64214abcfb8ba885c08f1@XCH-ALN-014.cisco.com>
References:    <58306620.4000308@foobar.org> <319AD952-C571-4085-8D56-C06A51F021E3@domino.org>   <058F756D-3A68-4AA6-A9DC-63A1BF9A5184@domino.org> <20161119194138.GG47336@dhcp-9d92.meeting.ietf.org> <87DDAB88-78AC-431A-ABE7-55249BF5D654@domino.org> <20161121090335.GU24817@gir.theapt.org>
In-Reply-To: <20161121090335.GU24817@gir.theapt.org>
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.32.152.21]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 22 Nov 2016 20:58:25 -0000

Reasons to do this:
1. A bunch of people want it.
2. It's an easy feature to implement.
3. It impacts nothing else.

Remember, it's already a free form data field.=20
We can put anything into it we like.

If you want a TLV, no big deal.
The first "T" is a UTF8 string.
Feel free to write drafts for other "T"s.

Thanks,
Jakob.


From nobody Tue Nov 22 14:04:57 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A1FD129B9C; Tue, 22 Nov 2016 14:04:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.019
X-Spam-Level: 
X-Spam-Status: No, score=-16.019 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=-1.497, 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 jS4BtZsO2aR0; Tue, 22 Nov 2016 14:04:51 -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 4E143129B8D; Tue, 22 Nov 2016 14:04:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1243; q=dns/txt; s=iport; t=1479852291; x=1481061891; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=+CB23NI7HXfAGH/JeDTs8KmHoIgKWVk8MTqImQ0vk1c=; b=b+5MT1H0Lyo+QKK0Mm+IE/2txZh1hKxAFhu9C4MasKpeX5ClUbHktrSo a0Xgf43YWu+eDVAJ2FjnmIQZFKBon54POsC6TUb21qaBSus2X8kr/TyHW o09x3MZFzVNJicwFgNSgSOim3KheyuL1IB30TEQ3bVqjSUKUqvDz+Ibh5 o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AdAQAtwDRY/5hdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzgBAQEBAR9YgQEHjTmXGZRtggYdC4V5AoIbPxQBAgEBAQEBAQF?= =?us-ascii?q?iKIRoAQEBBAEBATc0FwQCAQgRBAEBHwkHJwsUCQgCBAESCIhlDrIYi1IBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEXBYY+hFqKKgWaTgGQdZAzjWaECwEeN4ESHoNegUV?= =?us-ascii?q?yhn+BDQEBAQ?=
X-IronPort-AV: E=Sophos;i="5.31,682,1473120000"; d="scan'208";a="351884892"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Nov 2016 22:04:50 +0000
Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id uAMM4oYE011456 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 22 Nov 2016 22:04:50 GMT
Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 22 Nov 2016 16:04:49 -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; Tue, 22 Nov 2016 16:04:49 -0600
From: "Jakob Heitz (jheitz)" 
To: "idr@ietf.org" , "grow@ietf.org" 
Thread-Topic: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
Thread-Index: AQHSRQMxTJzfT4T22Uak2GrND1LtgaDljLHQ
Date: Tue, 22 Nov 2016 22:04:49 +0000
Message-ID: <5bbcf9d0da42489e8e344a18826e7110@XCH-ALN-014.cisco.com>
References:    <58306620.4000308@foobar.org> <319AD952-C571-4085-8D56-C06A51F021E3@domino.org>   <058F756D-3A68-4AA6-A9DC-63A1BF9A5184@domino.org> <20161119194138.GG47336@dhcp-9d92.meeting.ietf.org> <87DDAB88-78AC-431A-ABE7-55249BF5D654@domino.org> <20161121090335.GU24817@gir.theapt.org> <58f468c578b64214abcfb8ba885c08f1@XCH-ALN-014.cisco.com>
In-Reply-To: <58f468c578b64214abcfb8ba885c08f1@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: [10.32.152.21]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 22 Nov 2016 22:04:53 -0000

I was reminded that the data field already exists and some people may be us=
ing it.
Putting a human readable string into it should be fine.
If someone puts something else, then the result is just Jibberish,
but not harmful. OTOH, TLVs could get tricky.
If we want to use TLVs, another NOTIFICATION sub code might be wise.

(I wonder where Jibber is and whether we should hold an IETF meeting there)

Thanks,
Jakob.


> -----Original Message-----
> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jakob Heitz (jheitz)
> Sent: Tuesday, November 22, 2016 12:58 PM
> To: idr@ietf.org; grow@ietf.org
> Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in =
the peer's syslog at shutdown
>=20
> Reasons to do this:
> 1. A bunch of people want it.
> 2. It's an easy feature to implement.
> 3. It impacts nothing else.
>=20
> Remember, it's already a free form data field.
> We can put anything into it we like.
>=20
> If you want a TLV, no big deal.
> The first "T" is a UTF8 string.
> Feel free to write drafts for other "T"s.
>=20
> Thanks,
> Jakob.
>=20
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr


From nobody Tue Nov 22 14:09:22 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CDB81296C0; Tue, 22 Nov 2016 14:09:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.399
X-Spam-Level: 
X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, 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 OFM0v3dbC6Kv; Tue, 22 Nov 2016 14:09:17 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 8C4E8129585; Tue, 22 Nov 2016 14:09:17 -0800 (PST)
Received: from [172.29.32.58] (unknown [66.129.241.11]) by slice.pfrc.org (Postfix) with ESMTPSA id E8F311E337; Tue, 22 Nov 2016 17:12:22 -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: <5bbcf9d0da42489e8e344a18826e7110@XCH-ALN-014.cisco.com>
Date: Tue, 22 Nov 2016 17:09:15 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:    <58306620.4000308@foobar.org> <319AD952-C571-4085-8D56-C06A51F021E3@domino.org>   <058F756D-3A68-4AA6-A9DC-63A1BF9A5184@domino.org> <20161119194138.GG47336@dhcp-9d92.meeting.ietf.org> <87DDAB88-78AC-431A-ABE7-55249BF5D654@domino.org> <20161121090335.GU24817@gir.theapt.org> <58f468c578b64214abcfb8ba885c08f1@XCH-ALN-014.cisco.com> <5bbcf9d0da42489e8e344a18826e7110@XCH-ALN-014.cisco.com>
To: "Jakob Heitz (jheitz)" 
X-Mailer: Apple Mail (2.2104)
Archived-At: 
Cc: "idr@ietf.org" , "grow@ietf.org" 
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 22 Nov 2016 22:09:18 -0000

> On Nov 22, 2016, at 5:04 PM, Jakob Heitz (jheitz)  =
wrote:
>=20
> I was reminded that the data field already exists and some people may =
be using it.
> Putting a human readable string into it should be fine.
> If someone puts something else, then the result is just Jibberish,
> but not harmful.

Minimal sanitizing of the string to make sure it's a valid utf-8 is =
still necessary, or at least that your printf equivalent doesn't barf on =
malformed utf-8.

> OTOH, TLVs could get tricky.
> If we want to use TLVs, another NOTIFICATION sub code might be wise.

No worse than malformed utf-8.

>=20
> (I wonder where Jibber is and whether we should hold an IETF meeting =
there)

Probably should refer the question to the mtgvenue WG.=20

-- Jeff


From nobody Wed Nov 23 01:48:51 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADCF21298A0; Wed, 23 Nov 2016 01:48:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.717
X-Spam-Level: 
X-Spam-Status: No, score=-5.717 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=-1.497, 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 PmoxGBTitWln; Wed, 23 Nov 2016 01:48:48 -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 077161297C2; Wed, 23 Nov 2016 01:48:47 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DBF76699; Wed, 23 Nov 2016 09:48:45 +0000 (GMT)
Received: from BLREML407-HUB.china.huawei.com (10.20.4.45) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 23 Nov 2016 09:48:44 +0000
Received: from BLREML501-MBX.china.huawei.com ([10.20.5.198]) by BLREML407-HUB.china.huawei.com ([10.20.4.45]) with mapi id 14.03.0235.001; Wed, 23 Nov 2016 15:18:36 +0530
From: Veerendranatha Reddy Vallem 
To: "draft-ietf-ospf-ospfv3-segment-routing-extensions@ietf.org" 
Thread-Topic: =?Windows-1252?Q?Regarding_segment_routing_capability_bit_set_in_=91Route?= =?Windows-1252?Q?r_Informational_Capabilities_TLV=92__of_RI_LSA?=
Thread-Index: AdJFbsHaaun5gJXERUC39veXLL+/Iw==
Date: Wed, 23 Nov 2016 09:48:35 +0000
Message-ID: <73BFDDFFF499304EB26FE5FDEF20F788508367A6@blreml501-mbx>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.18.152.243]
Content-Type: multipart/alternative; boundary="_000_73BFDDFFF499304EB26FE5FDEF20F788508367A6blreml501mbx_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.583565FE.0061, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 29aaee0e70b8da843fd851ab3cf22b4d
Archived-At: 
Cc: "'idr@ietf.org'" 
Subject: [Idr] =?windows-1252?q?Regarding_segment_routing_capability_bit_s?= =?windows-1252?q?et_in_=91Router_Informational_Capabilities_TLV=92__of_RI?= =?windows-1252?q?_LSA?=
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, 23 Nov 2016 09:48:49 -0000

--_000_73BFDDFFF499304EB26FE5FDEF20F788508367A6blreml501mbx_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Dear Authors,
While advertising Segment Routing capabilities in RI LSA, as per draft ther=
e is =91no bit=92 is allocated in =91Router Informational Capabilities TLV=
=92  for segment routing capability.

9.  IANA Considerations

   This specification updates several existing OSPF registries.

9.1.  OSPF Router Information (RI) TLVs Registry

   o 8 (IANA Preallocated) - SR-Algorithm TLV

   o 9 (IANA Preallocated) - SID/Label Range TLV

   o 12 - SR Local Block Sub-TLV

   o 13 - SRMS Preference Sub-TLV



Whether bit set in =91Router Informational Capabilities TLV=92  is not requ=
ired for segment routing capability , to notify neighbors?

Regards,
Veerendranath

--_000_73BFDDFFF499304EB26FE5FDEF20F788508367A6blreml501mbx_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable











Dear Authors,


While advertising Segment Routing capabilities in RI=
 LSA, as per draft there is =91no bit=92 is allocated in =91Router Informat=
ional Capabilities TLV=92  for segment routing capability.<=
/p>

 


9.  IANA Considerations=



 


   This specification updates severa=
l existing OSPF registries.


 


9.1.  OSPF Router Information (RI) TLVs R=
egistry


 


   o 8 (IANA Preallocated) - SR-Algo=
rithm TLV


 


   o 9 (IANA Preallocated) - SID/Lab=
el Range TLV


 


   o 12 - SR Local Block Sub-TLV


 


   o 13 - SRMS Preference Sub-TLV


 


 


 


Whether bit set in =91Router Informational Capabilit=
ies TLV=92  is not required for segment routing capability , to notify=
 neighbors?


 


Regards,


Veerendranath 






--_000_73BFDDFFF499304EB26FE5FDEF20F788508367A6blreml501mbx_--


From nobody Wed Nov 23 03:53:43 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25D1712999E; Wed, 23 Nov 2016 03:53:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.018
X-Spam-Level: 
X-Spam-Status: No, score=-16.018 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=-1.497, 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 LosTP9B6oYqV; Wed, 23 Nov 2016 03:53:39 -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 B6C841299A7; Wed, 23 Nov 2016 03:53:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9200; q=dns/txt; s=iport; t=1479902018; x=1481111618; h=from:to:cc:subject:date:message-id:mime-version; bh=BPuu5v76onFXcid6ankMdEsTiulxpgk/PXAJDfw62+Y=; b=FMPnvfoHeTfDJeeKll6mZEDCa17fEo/byM6Qc9e0P4iM/C/WiWs+c34q pkYvzn5+fm9IpVcfTxoPi8BDh8IM6MFJ5NGHYc9Ta198mLId1EUdKgvwU Rms3NBRZm8vlrw/Otm00kPnx4LEd6mGVvcjgqX2WE9UdYOxfo8XGJi2v2 k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B4AQC9gjVY/5tdJa1eGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgnNFAQEBAQEfWIECB405lxqPVIUfggeGIYIXPxQBAgEBAQEBAQFiKIR?= =?us-ascii?q?oAQEBBC1MEgEIEQMBAiQEORQJCgQOBYhtsWuLagEBAQEBAQEBAgEBAQEBAQEBH?= =?us-ascii?q?4sZhGmFQQWaTwGQf5AxjWqECwEeN4EUHoMxHBiBRXKHOIENAQEB?=
X-IronPort-AV: E=Sophos;i="5.31,538,1473120000";  d="scan'208,217";a="178435332"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Nov 2016 11:53:37 +0000
Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id uANBrb5t026541 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 23 Nov 2016 11:53:37 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; Wed, 23 Nov 2016 06:53:36 -0500
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, 23 Nov 2016 06:53:36 -0500
From: "Acee Lindem (acee)" 
To: Veerendranatha Reddy Vallem , "draft-ietf-ospf-ospfv3-segment-routing-extensions@ietf.org" 
Thread-Topic: =?Windows-1252?Q?[Idr]_Regarding_segment_routing_capability_bit_set_in_?= =?Windows-1252?Q?=8CRouter_Informational_Capabilities_TLV=B9__of_RI_LSA?=
Thread-Index: AQHSRYA5twd4v7Xem0+i9tRll1kaOg==
Date: Wed, 23 Nov 2016 11:53:36 +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.202]
Content-Type: multipart/alternative; boundary="_000_D45AECDC8A7DBaceeciscocom_"
MIME-Version: 1.0
Archived-At: 
Cc: "'idr@ietf.org'" 
Subject: Re: [Idr] =?windows-1252?q?Regarding_segment_routing_capability_bit_s?= =?windows-1252?q?et_in_=8CRouter_Informational_Capabilities_TLV=B9__of_RI?= =?windows-1252?q?_LSA?=
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, 23 Nov 2016 11:53:41 -0000

--_000_D45AECDC8A7DBaceeciscocom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi Veerandranath,

Since an algorithm and SID/Label range is required for segment-routing oper=
ation in OSPF, no bit is necessary. If a bit were to be allocated, it would=
 go in the RI functional capabilities rather than the informational capabil=
ities.

Thanks,
Acee


From: Idr > on behalf of =
Veerendranatha Reddy Vallem >
Date: Wednesday, November 23, 2016 at 4:48 AM
To: "draft-ietf-ospf-ospfv3-segment-routing-extensions@ietf.org" >
Cc: IDR List >
Subject: [Idr] Regarding segment routing capability bit set in =91Router In=
formational Capabilities TLV=92 of RI LSA

Dear Authors,
While advertising Segment Routing capabilities in RI LSA, as per draft ther=
e is =91no bit=92 is allocated in =91Router Informational Capabilities TLV=
=92  for segment routing capability.

9.  IANA Considerations

   This specification updates several existing OSPF registries.

9.1.  OSPF Router Information (RI) TLVs Registry

   o 8 (IANA Preallocated) - SR-Algorithm TLV

   o 9 (IANA Preallocated) - SID/Label Range TLV

   o 12 - SR Local Block Sub-TLV

   o 13 - SRMS Preference Sub-TLV



Whether bit set in =91Router Informational Capabilities TLV=92  is not requ=
ired for segment routing capability , to notify neighbors?

Regards,
Veerendranath

--_000_D45AECDC8A7DBaceeciscocom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <4D509AF1BAC7564DAAE7DBA5A38B43EA@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable







Hi Veerandranath, 







Since an algorithm and SID/Label range is required for segment-routing=
 operation in OSPF, no bit is necessary. If a bit were to be allocated, it =
would go in the RI functional capabilities rather than the informational ca=
pabilities. 







Thanks,


Acee 














From: Idr <idr-bounces@ietf.org> on behalf of Veerendranatha=
 Reddy Vallem <veerendran=
atharv@huawei.com>

Date: Wednesday, November 23, 2016 =
at 4:48 AM

To: "draft-ietf-ospf-ospfv3=
-segment-routing-extensions@ietf.org" <draft-ietf-ospf-ospfv=
3-segment-routing-extensions@ietf.org>

Cc: IDR List <idr@ietf.org>

Subject: [Idr] Regarding segment ro=
uting capability bit set in =91Router Informational Capabilities TLV=92 of =
RI LSA



















Dear Authors,


While advertising Segment Routing capabilities in RI=
 LSA, as per draft there is =91no bit=92 is allocated in =91Router Informat=
ional Capabilities TLV=92  for segment routing capability.<=
/p>

 


9.  IANA Considerations=



 


   This specification updates severa=
l existing OSPF registries.


 


9.1.  OSPF Router Information (RI) TLVs R=
egistry


 


   o 8 (IANA Preallocated) - SR-Algo=
rithm TLV


 


   o 9 (IANA Preallocated) - SID/Lab=
el Range TLV


 


   o 12 - SR Local Block Sub-TLV


 


   o 13 - SRMS Preference Sub-TLV


 


 


 


Whether bit set in =91Router Informational Capabilit=
ies TLV=92  is not required for segment routing capability , to notify=
 neighbors?


 


Regards,


Veerendranath 













--_000_D45AECDC8A7DBaceeciscocom_--


From nobody Wed Nov 23 17:57:55 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF32612965F; Wed, 23 Nov 2016 17:57:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.717
X-Spam-Level: 
X-Spam-Status: No, score=-5.717 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=-1.497, 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 X3iTngicgjBU; Wed, 23 Nov 2016 17:57:52 -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 31F6E129688; Wed, 23 Nov 2016 17:57:35 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CVV79618; Thu, 24 Nov 2016 01:57:33 +0000 (GMT)
Received: from BLREML405-HUB.china.huawei.com (10.20.4.41) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 24 Nov 2016 01:56:37 +0000
Received: from BLREML501-MBX.china.huawei.com ([10.20.5.198]) by BLREML405-HUB.china.huawei.com ([10.20.4.41]) with mapi id 14.03.0235.001; Thu, 24 Nov 2016 07:26:33 +0530
From: Veerendranatha Reddy Vallem 
To: "Acee Lindem (acee)" , "draft-ietf-ospf-ospfv3-segment-routing-extensions@ietf.org" 
Thread-Topic: =?windows-1256?Q?[Idr]_Regarding_segment_routing_capability_bit_set_in_?= =?windows-1256?Q?=8CRouter_Informational_Capabilities_TLV=B9__of_RI_LSA?=
Thread-Index: AQHSRYA5twd4v7Xem0+i9tRll1kaOqDnYB1A
Date: Thu, 24 Nov 2016 01:56:32 +0000
Message-ID: <73BFDDFFF499304EB26FE5FDEF20F78850836C66@blreml501-mbx>
References: 
In-Reply-To: 
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.18.152.243]
Content-Type: multipart/alternative; boundary="_000_73BFDDFFF499304EB26FE5FDEF20F78850836C66blreml501mbx_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.5836490D.01A2, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 499ed0cb8300170523676fe77f05e7b9
Archived-At: 
Cc: "'idr@ietf.org'" 
Subject: Re: [Idr] =?cp1256?q?Regarding_segment_routing_capability_bit_set_in_?= =?cp1256?q?=8CRouter_Informational_Capabilities_TLV=B9__of_RI_LSA?=
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, 24 Nov 2016 01:57:54 -0000

--_000_73BFDDFFF499304EB26FE5FDEF20F78850836C66blreml501mbx_
Content-Type: text/plain; charset="windows-1256"
Content-Transfer-Encoding: quoted-printable

Thanks to Acee and Hannes for your reply.
I got it.

Regards,
Veerendranath

From: Acee Lindem (acee) [mailto:acee@cisco.com]
Sent: 23 November 2016 17:24
To: Veerendranatha Reddy Vallem ; draft-ietf-o=
spf-ospfv3-segment-routing-extensions@ietf.org
Cc: 'idr@ietf.org' 
Subject: Re: [Idr] Regarding segment routing capability bit set in =8CRoute=
r Informational Capabilities TLV=B9 of RI LSA

Hi Veerandranath,

Since an algorithm and SID/Label range is required for segment-routing oper=
ation in OSPF, no bit is necessary. If a bit were to be allocated, it would=
 go in the RI functional capabilities rather than the informational capabil=
ities.

Thanks,
Acee


From: Idr > on behalf of =
Veerendranatha Reddy Vallem >
Date: Wednesday, November 23, 2016 at 4:48 AM
To: "draft-ietf-ospf-ospfv3-segment-routing-extensions@ietf.org" >
Cc: IDR List >
Subject: [Idr] Regarding segment routing capability bit set in =91Router In=
formational Capabilities TLV=92 of RI LSA

Dear Authors,
While advertising Segment Routing capabilities in RI LSA, as per draft ther=
e is =91no bit=92 is allocated in =91Router Informational Capabilities TLV=
=92  for segment routing capability.

9.  IANA Considerations

   This specification updates several existing OSPF registries.

9.1.  OSPF Router Information (RI) TLVs Registry

   o 8 (IANA Preallocated) - SR-Algorithm TLV

   o 9 (IANA Preallocated) - SID/Label Range TLV

   o 12 - SR Local Block Sub-TLV

   o 13 - SRMS Preference Sub-TLV



Whether bit set in =91Router Informational Capabilities TLV=92  is not requ=
ired for segment routing capability , to notify neighbors?

Regards,
Veerendranath

--_000_73BFDDFFF499304EB26FE5FDEF20F78850836C66blreml501mbx_
Content-Type: text/html; charset="windows-1256"
Content-Transfer-Encoding: quoted-printable











Thanks to Acee and Han=
nes for your reply.


I got it.


 


Regards,


Veerendranath


 






From: Acee Lindem (acee) [mailto:acee@cisco.c=
om] 

Sent: 23 November 2016 17:24

To: Veerendranatha Reddy Vallem <veerendranatharv@huawei.com>;=
 draft-ietf-ospf-ospfv3-segment-routing-extensions@ietf.org

Cc: 'idr@ietf.org' <idr@ietf.org>

Subject: Re: [Idr] Regarding segment routing capability bit set in =
=8CRouter Informational Capabilities TLV=B9 of RI LSA






 




Hi Veer=
andranath, 






&n=
bsp;






Since a=
n algorithm and SID/Label range is required for segment-routing operation i=
n OSPF, no bit is necessary. If a bit were to be allocated, it would go in =
the RI functional capabilities rather
 than the informational capabilities. 






&n=
bsp;






Thanks,=







Acee&nb=
sp;






&n=
bsp;






&n=
bsp;






From: Idr <idr=
-bounces@ietf.org> on behalf of Veerendranatha Reddy Vallem <veerendranatharv@huawei.com&=
gt;

Date: Wednesday, November 23, 2016 at 4:48 AM

To: "draft-ietf-ospf-ospfv3-segment-routing-extensions@ietf.=
org" <draft-ietf-ospf-ospfv3-segment-routing-extensions@ietf=
.org>

Cc: IDR List <idr@ietf.org>=
;

Subject: [Idr] Regarding segment routing capability bit set in =91Ro=
uter Informational Capabilities TLV=92 of RI LSA






&n=
bsp;










Dear Authors,=



While advertising Segmen=
t Routing capabilities in RI LSA, as per draft there is =91no bit=92 is all=
ocated in =91Router Informational Capabilities TLV=92  for segment rou=
ting capability.


 =



9.  IANA Considerations


 


   This specification up=
dates several existing OSPF registries.<=
o:p>


 


9.1.  OSPF Router Information=
 (RI) TLVs Registry

 


   o 8 (IANA Preallocate=
d) - SR-Algorithm TLV<=
/p>

 


   o 9 (IANA Preallocate=
d) - SID/Label Range TLV


 


   o 12 - SR Local Block=
 Sub-TLV


 


   o 13 - SRMS Preferenc=
e Sub-TLV


 =



 =



 =



Whether bit set in =91Ro=
uter Informational Capabilities TLV=92  is not required for segment ro=
uting capability , to notify neighbors?


 =



Regards,


Veerendranath 












--_000_73BFDDFFF499304EB26FE5FDEF20F78850836C66blreml501mbx_--


From nobody Mon Nov 28 00:36:11 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C6F31296D0; Mon, 28 Nov 2016 00:36:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.717
X-Spam-Level: 
X-Spam-Status: No, score=-5.717 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=-1.497, 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 CxhTCNAnjOY6; Mon, 28 Nov 2016 00:36:08 -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 9F2011296CF; Mon, 28 Nov 2016 00:36:07 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CWD71330; Mon, 28 Nov 2016 08:36:04 +0000 (GMT)
Received: from BLREML406-HUB.china.huawei.com (10.20.4.43) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 28 Nov 2016 08:36:02 +0000
Received: from BLREML501-MBX.china.huawei.com ([10.20.5.198]) by BLREML406-HUB.china.huawei.com ([10.20.4.43]) with mapi id 14.03.0301.000; Mon, 28 Nov 2016 14:05:58 +0530
From: Veerendranatha Reddy Vallem 
To: "draft-ietf-ospf-ospfv3-segment-routing-extensions@ietf.org" 
Thread-Topic: [OSPFv3-SR] Regarding LAN Adj-SID/Label description
Thread-Index: AdJJUfDyCFrjp8UdSduDAUS+my9l7A==
Date: Mon, 28 Nov 2016 08:35:58 +0000
Message-ID: <73BFDDFFF499304EB26FE5FDEF20F7885083CF23@blreml501-mbx>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.18.152.243]
Content-Type: multipart/alternative; boundary="_000_73BFDDFFF499304EB26FE5FDEF20F7885083CF23blreml501mbx_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.583BEC75.03D5, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 7a35469fbfdd5a859aef1dd7b0adb04d
Archived-At: 
Cc: "'idr@ietf.org'" 
Subject: [Idr] [OSPFv3-SR] Regarding LAN Adj-SID/Label description
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, 28 Nov 2016 08:36:10 -0000

--_000_73BFDDFFF499304EB26FE5FDEF20F7885083CF23blreml501mbx_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Dear Authors,

As per draft, for LAN SID Sub-TLV,

7.2.  LAN Adj-SID Sub-TLV

   The LAN Adj-SID is an optional Sub-TLV of the Router-Link TLV.  It
   MAY appear multiple times in the Router-Link TLV.  It is used to
   advertise a SID/Label for an adjacency to a non-DR neighbor on a
   broadcast or NBMA network.


    0                   1                   2                   3

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |              Type             |            Length             |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |     Flags     |     Weight    |            Reserved           |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                           Neighbor ID                         |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                    SID/Label/Index (variable)                 |

   +---------------------------------------------------------------+


"LAN SID is used for non-DR neighbors." We cannot use this Sub TLV to provi=
de SID for DR router (Neighbor ID is DR's router id in this TLV) ?
It means we need to include "Adj_SID Sub TLV for DR neighbor" and LAN Adj-S=
ID for other neighbors (including BDR)  in the network while advertising Ad=
j- SID in Router Link TLV for LAN?
Can you please provide clarity for this sub TLV.

Regards,
Veerendranath



--_000_73BFDDFFF499304EB26FE5FDEF20F7885083CF23blreml501mbx_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Dear Authors,


 


As per draft, for LAN SID Sub-TLV,


 


7.2.  LAN Adj-SID Sub-TLV


 


   The LAN Adj-SID is an optional Sub-TLV of the=
 Router-Link TLV.  It


   MAY appear multiple times in the Router-Link =
TLV. 
It is used to


   advertise a SID/Label for an adjacency to =
a non-DR neighbor on a


   broadcast or NBMA network.


 


    0        &n=
bsp;          1  &nb=
sp;            =
    2         &=
nbsp;         3


    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5=
 6 7 8 9 0 1


   +-+-+-+-+-+-+-+-+-=
3;-+-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+


   |         &n=
bsp;    Type        =
     |        &=
nbsp;   Length        &nb=
sp;    |


   +-+-+-+-+-+-+-+-+-=
3;-+-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+


   |     Flags     |=
     Weight    |    =
        Reserved    =
       |


   +-+-+-+-+-+-+-+-+-=
3;-+-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+


   |         &n=
bsp;            =
;     Neighbor ID      &n=
bsp;            =
;      |


   +-+-+-+-+-+-+-+-+-=
3;-+-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+


   |         &n=
bsp;          SID/Label/Index =
(variable)           =
;      |


   +----------------------------------------------------=
-----------+


 


 


“LAN SID is used for non-DR neighbors.” =
We cannot use this Sub TLV to provide SID for DR router (Neighbor ID is DR&=
#8217;s router id in this TLV) ?


It means we need to include “Adj_SID Sub TLV f=
or DR neighbor” and LAN Adj-SID for other neighbors (including BDR) &=
nbsp;in the network while advertising Adj- SID in Router Link TLV for LAN?<=
o:p>


Can you please provide clarity for this sub TLV.


 


Regards,


Veerendranath


 


 






--_000_73BFDDFFF499304EB26FE5FDEF20F7885083CF23blreml501mbx_--


From nobody Mon Nov 28 23:39:01 2016
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 7AF251295F3; Mon, 28 Nov 2016 23:38:59 -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.38.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148040513949.5486.9246798783447106413.idtracker@ietfa.amsl.com>
Date: Mon, 28 Nov 2016 23:38:59 -0800
Archived-At: 
Cc: idr@ietf.org
Subject: [Idr] I-D Action: draft-ietf-idr-eag-distribution-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: Tue, 29 Nov 2016 07:38: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           : Distribution of MPLS-TE Extended admin Group Using BGP
        Authors         : Zitao Wang
                          Qin Wu
                          Jeff Tantsura
	Filename        : draft-ietf-idr-eag-distribution-03.txt
	Pages           : 5
	Date            : 2016-11-28

Abstract:
   As MPLS-TE network grows, administrative Groups advertised as a
   fixed-length 32-bit Bitmask is quite constraining.  "Extended
   Administrative Group" IGP TE extensions sub-TLV defined in [RFC7308]
   is introduced to provide for additional administrative groups (link
   colors) beyond the current limit of 32.  This document describes
   extensions to BGP protocol, that can be used to distribute extended
   administrative groups in MPLS-TE.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-idr-eag-distribution/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-idr-eag-distribution-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-eag-distribution-03


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

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


From nobody Mon Nov 28 23:41:22 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5F441295C2 for ; Mon, 28 Nov 2016 23:41:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.718
X-Spam-Level: 
X-Spam-Status: No, score=-5.718 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, RP_MATCHES_RCVD=-1.497, 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 DNiXJ0hZKzew for ; Mon, 28 Nov 2016 23:41:17 -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 5CEA01294F7 for ; Mon, 28 Nov 2016 23:41:16 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CWF36127; Tue, 29 Nov 2016 07:41:14 +0000 (GMT)
Received: from SZXEML429-HUB.china.huawei.com (10.82.67.184) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 29 Nov 2016 07:41:13 +0000
Received: from SZXEML501-MBX.china.huawei.com ([169.254.1.5]) by SZXEML429-HUB.china.huawei.com ([10.82.67.184]) with mapi id 14.03.0235.001; Tue, 29 Nov 2016 15:40:56 +0800
From: wangzitao 
To: "idr@ietf.org" 
Thread-Topic: [Idr] I-D Action: draft-ietf-idr-eag-distribution-03.txt
Thread-Index: AQHSShOw2APN2p8z7kSDq2lpYvAQX6Dvk1bQ
Date: Tue, 29 Nov 2016 07:40:55 +0000
Message-ID: 
References: <148040513949.5486.9246798783447106413.idtracker@ietfa.amsl.com>
In-Reply-To: <148040513949.5486.9246798783447106413.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.136.78.198]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.583D311A.03B0, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.1.5, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 7914e354efdfa5ee599fd45a549edfd0
Archived-At: 
Subject: Re: [Idr] I-D Action: draft-ietf-idr-eag-distribution-03.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, 29 Nov 2016 07:41:20 -0000

SGkgQWxsLA0KDQpXZSd2ZSB1cGRhdGVkIHRoZSBpZXRmLWlkci1lYWctZGlzdHJpYnV0aW9uIHRv
IC0wMy4NCkluIHRoaXMgbmV3IHZlcnNpb24sIHdlIGZpeGVkIHRoZSByZWZlcmVuY2Ugc2VjdGlv
biBhbmQgYXV0aG9yoa9zIGluZm9ybWF0aW9uLg0KDQpCZXN0IFJlZ2FyZHMhDQotTWljaGFlbA0K
DQotLS0tLdPKvP7Urbz+LS0tLS0NCreivP7IyzogSWRyIFttYWlsdG86aWRyLWJvdW5jZXNAaWV0
Zi5vcmddILT6se0gaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnDQq3osvNyrG85DogMjAxNsTqMTHU
wjI5yNUgMTU6MzkNCsrVvP7IyzogaS1kLWFubm91bmNlQGlldGYub3JnDQqzrcvNOiBpZHJAaWV0
Zi5vcmcNCtb3zOI6IFtJZHJdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtaWRyLWVhZy1kaXN0cmli
dXRpb24tMDMudHh0DQoNCg0KQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20g
dGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KVGhpcyBkcmFmdCBpcyBh
IHdvcmsgaXRlbSBvZiB0aGUgSW50ZXItRG9tYWluIFJvdXRpbmcgb2YgdGhlIElFVEYuDQoNCiAg
ICAgICAgVGl0bGUgICAgICAgICAgIDogRGlzdHJpYnV0aW9uIG9mIE1QTFMtVEUgRXh0ZW5kZWQg
YWRtaW4gR3JvdXAgVXNpbmcgQkdQDQogICAgICAgIEF1dGhvcnMgICAgICAgICA6IFppdGFvIFdh
bmcNCiAgICAgICAgICAgICAgICAgICAgICAgICAgUWluIFd1DQogICAgICAgICAgICAgICAgICAg
ICAgICAgIEplZmYgVGFudHN1cmENCglGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLWlkci1l
YWctZGlzdHJpYnV0aW9uLTAzLnR4dA0KCVBhZ2VzICAgICAgICAgICA6IDUNCglEYXRlICAgICAg
ICAgICAgOiAyMDE2LTExLTI4DQoNCkFic3RyYWN0Og0KICAgQXMgTVBMUy1URSBuZXR3b3JrIGdy
b3dzLCBhZG1pbmlzdHJhdGl2ZSBHcm91cHMgYWR2ZXJ0aXNlZCBhcyBhDQogICBmaXhlZC1sZW5n
dGggMzItYml0IEJpdG1hc2sgaXMgcXVpdGUgY29uc3RyYWluaW5nLiAgIkV4dGVuZGVkDQogICBB
ZG1pbmlzdHJhdGl2ZSBHcm91cCIgSUdQIFRFIGV4dGVuc2lvbnMgc3ViLVRMViBkZWZpbmVkIGlu
IFtSRkM3MzA4XQ0KICAgaXMgaW50cm9kdWNlZCB0byBwcm92aWRlIGZvciBhZGRpdGlvbmFsIGFk
bWluaXN0cmF0aXZlIGdyb3VwcyAobGluaw0KICAgY29sb3JzKSBiZXlvbmQgdGhlIGN1cnJlbnQg
bGltaXQgb2YgMzIuICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcw0KICAgZXh0ZW5zaW9ucyB0byBC
R1AgcHJvdG9jb2wsIHRoYXQgY2FuIGJlIHVzZWQgdG8gZGlzdHJpYnV0ZSBleHRlbmRlZA0KICAg
YWRtaW5pc3RyYXRpdmUgZ3JvdXBzIGluIE1QTFMtVEUuDQoNCg0KVGhlIElFVEYgZGF0YXRyYWNr
ZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQpodHRwczovL2RhdGF0cmFja2VyLmll
dGYub3JnL2RvYy9kcmFmdC1pZXRmLWlkci1lYWctZGlzdHJpYnV0aW9uLw0KDQpUaGVyZSdzIGFs
c28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5v
cmcvaHRtbC9kcmFmdC1pZXRmLWlkci1lYWctZGlzdHJpYnV0aW9uLTAzDQoNCkEgZGlmZiBmcm9t
IHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCmh0dHBzOi8vd3d3LmlldGYu
b3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWlkci1lYWctZGlzdHJpYnV0aW9uLTAzDQoNCg0K
UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhl
IHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBh
cmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpJbnRlcm5ldC1EcmFmdHMgYXJlIGFs
c28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQpmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50
ZXJuZXQtZHJhZnRzLw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXw0KSWRyIG1haWxpbmcgbGlzdA0KSWRyQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkcg0K


From nobody Tue Nov 29 11:31:51 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF2AE1295DB; Tue, 29 Nov 2016 11:31:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.998
X-Spam-Level: 
X-Spam-Status: No, score=-6.998 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, 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 4ydFbkrJf-kN; Tue, 29 Nov 2016 11:31:40 -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 5048A1295CC; Tue, 29 Nov 2016 11:31:40 -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 1cBo7u-0001AD-3t; Tue, 29 Nov 2016 19:31:38 +0000
Date: Tue, 29 Nov 2016 11:31:37 -0800
Message-ID: 
From: Randy Bush 
To: Nick Hilliard 
In-Reply-To: <5830C12E.6000804@foobar.org>
References:      <58306620.4000308@foobar.org> <319AD952-C571-4085-8D56-C06A51F021E3@domino.org>   <058F756D-3A68-4AA6-A9DC-63A1BF9A5184@domino.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: 
Cc: "idr@ietf.org" , "grow@ietf.org" 
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 29 Nov 2016 19:31:42 -0000

why do folk block syslog/514?
who can come up with the first exploit based on a tricky entry?

randy


From nobody Tue Nov 29 12:12:34 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB071129607; Tue, 29 Nov 2016 12:12:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.397
X-Spam-Level: 
X-Spam-Status: No, score=-8.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497] 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 EdY6WZcFIYRk; Tue, 29 Nov 2016 12:12:28 -0800 (PST)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (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 2AA28129497; Tue, 29 Nov 2016 12:12:28 -0800 (PST)
Received: from mbp-4.local ([IPv6:2601:647:4201:9e61:d402:330f:9c2a:db6c]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id uATKCI2v039139 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 29 Nov 2016 20:12:18 GMT (envelope-from joelja@bogus.com)
X-Authentication-Warning: nagasaki.bogus.com: Host [IPv6:2601:647:4201:9e61:d402:330f:9c2a:db6c] claimed to be mbp-4.local
To: Randy Bush , Nick Hilliard 
References:      <58306620.4000308@foobar.org> <319AD952-C571-4085-8D56-C06A51F021E3@domino.org>   <058F756D-3A68-4AA6-A9DC-63A1BF9A5184@domino.org> 
From: joel jaeggli 
Message-ID: <5c492251-a6f4-8608-9784-0eb0bcd51672@bogus.com>
Date: Tue, 29 Nov 2016 12:12:17 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:50.0) Gecko/20100101 Thunderbird/50.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pKd1SvvCtJDqdsIaO22hU8VXGCUTAItgB"
Archived-At: 
Cc: "idr@ietf.org" , "grow@ietf.org" 
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
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, 29 Nov 2016 20:12:29 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--pKd1SvvCtJDqdsIaO22hU8VXGCUTAItgB
Content-Type: multipart/mixed; boundary="V71BVFclJ5dDf2O8MDf6ur5s9gx7OXhqr";
 protected-headers="v1"
From: joel jaeggli 
To: Randy Bush , Nick Hilliard 
Cc: "idr@ietf.org" , "grow@ietf.org" 
Message-ID: <5c492251-a6f4-8608-9784-0eb0bcd51672@bogus.com>
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the
 peer's syslog at shutdown
References: 
 
 
 
 
 <58306620.4000308@foobar.org>
 <319AD952-C571-4085-8D56-C06A51F021E3@domino.org>
 
 
 <058F756D-3A68-4AA6-A9DC-63A1BF9A5184@domino.org>
 
In-Reply-To: 

--V71BVFclJ5dDf2O8MDf6ur5s9gx7OXhqr
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US

On 11/29/16 11:31 AM, Randy Bush wrote:
> why do folk block syslog/514?
because spoofing syslog entries is a thing. in general I don't let
member of the general public emit junk into my logs except of course
spammers who are quite well represented albeit indirectly, as is the
case here.
> who can come up with the first exploit based on a tricky entry?
it's a fairly narrow surface area on the syslog reciver given the
emitter is the routers syslogd so for example something like

http://www.rsyslog.com/remote-syslog-pri-vulnerability/

is under the control of the syslogd not the sender.

128 characters is of somewhat limited value in syslog spoofing as you
have to flap you bgp session in order to emit a new line.

do you think reciver operation should be more tightly specified in some w=
ay?

thanks
joel
> randy
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>



--V71BVFclJ5dDf2O8MDf6ur5s9gx7OXhqr--

--pKd1SvvCtJDqdsIaO22hU8VXGCUTAItgB
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iEYEARECAAYFAlg94SIACgkQ8AA1q7Z/VrIkVACfXe7vaeBrkAMjjmYRbKA2gBA6
YPUAnR+/4Ya8AqlWkMc8JaKFK44Ciy1p
=oREa
-----END PGP SIGNATURE-----

--pKd1SvvCtJDqdsIaO22hU8VXGCUTAItgB--


From nobody Wed Nov 30 07:10:03 2016
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 52BEC1295B0; Wed, 30 Nov 2016 07:09:54 -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.38.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148051859433.26144.11313186498622973917.idtracker@ietfa.amsl.com>
Date: Wed, 30 Nov 2016 07:09:54 -0800
Archived-At: 
Subject: [Idr] The IDR WG has placed draft-snijders-idr-shutdown in state "Adopted by a WG"
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: Wed, 30 Nov 2016 15:10:00 -0000

The IDR WG has placed draft-snijders-idr-shutdown in state 
Adopted by a WG (entered by Susan Hares)

The document is available at
https://datatracker.ietf.org/doc/draft-snijders-idr-shutdown/


From nobody Wed Nov 30 07:10:23 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0473E129417; Wed, 30 Nov 2016 07:10:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.845
X-Spam-Level: **
X-Spam-Status: No, score=2.845 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 05jEem0VwzMw; Wed, 30 Nov 2016 07:10:18 -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 106E51295B7; Wed, 30 Nov 2016 07:10:14 -0800 (PST)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.90.155; 
From: "Susan Hares" 
To: "'idr wg'" 
Date: Wed, 30 Nov 2016 10:07:11 -0500
Message-ID: <010801d24b1b$6ded8ad0$49c8a070$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0109_01D24AF1.8517F800"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdJLGcnJFXON80YxQAmJWtT5Q65g6A==
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com 
Archived-At: 
Cc: draft-snijders-idr-shutdown@ietf.org, grow@ietf.org
Subject: Re: [Idr] WG Adoption call for draft-snijders-idr-shutdown (11/16 to 11/30)
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, 30 Nov 2016 15:10:19 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0109_01D24AF1.8517F800
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

The adoption call for draft-snijders-idr-shutdown has been completed (11/16
to 11/30) and the WG consensus is that this draft should be adopted.    The
authors should submit this draft as draft-ietf-idr-shutdown-00.txt.   

Due to the fact the operators responding to the adoption call this draft
fulfills a current operational need, this draft will move rapidly from
adoption to WG LC.  Just a reminder the three things needed for entering WG
LC are:  stable specification, 2 implementations, and the routing
directorates QA reviews.  For example, if 2 implementations were completed
by 12/15, the chairs would start a WG LC beginning on 12/15.  

The authors should send the IDR chairs a note if they feel the specification
is ready for the routing directorate QA review.  The routing directorate QA
review can be done when technical content is stable (rather than when the
text is finalized).   

Sue Hares  

 


------=_NextPart_000_0109_01D24AF1.8517F800
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


The adoption call for draft-snijders-idr-shutdown =
has been completed (11/16 to 11/30) and the WG consensus is that this =
draft should be adopted.    The authors should submit =
this draft as draft-ietf-idr-shutdown-00.txt. =
  
Due to the fact the operators responding to the =
adoption call this draft fulfills a current operational need, this draft =
will move rapidly from adoption to WG LC.  Just a reminder the =
three things needed for entering WG LC are:  stable specification, =
2 implementations, and the routing directorates QA reviews.  For =
example, if 2 implementations were completed by 12/15, the chairs would =
start a WG LC beginning on 12/15.  
The authors should send the IDR chairs a note if =
they feel the specification is ready for the routing directorate QA =
review.  The routing directorate QA review can be done when =
technical content is stable (rather than when the text is =
finalized).   
Sue Hares  
 

------=_NextPart_000_0109_01D24AF1.8517F800--


From nobody Wed Nov 30 07:22:53 2016
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 DEB7D1294F1; Wed, 30 Nov 2016 07:22:45 -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.39.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148051936590.14117.13161992216583636064.idtracker@ietfa.amsl.com>
Date: Wed, 30 Nov 2016 07:22:45 -0800
Archived-At: 
Cc: idr@ietf.org
Subject: [Idr] I-D Action: draft-ietf-idr-shutdown-00.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: Wed, 30 Nov 2016 15:22:46 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing of the IETF.

        Title           : The Shutdown Communication BGP Cease Notification Message subcode 
        Authors         : Job Snijders
                          Jakob Heitz
                          John Scudder
	Filename        : draft-ietf-idr-shutdown-00.txt
	Pages           : 6
	Date            : 2016-11-30

Abstract:
   This document defines the BGP Cease NOTIFICATION message "Shutdown
   Communication" subcode for operators to transmit a short freeform
   message to describe why a BGP session was shutdown.



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-00


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

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


From nobody Wed Nov 30 08:55:05 2016
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 0BE7D120725; Wed, 30 Nov 2016 08:55:01 -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.39.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148052490104.3081.2049626653192295584.idtracker@ietfa.amsl.com>
Date: Wed, 30 Nov 2016 08:55:01 -0800
Archived-At: 
Cc: idr@ietf.org
Subject: [Idr] I-D Action: draft-ietf-idr-shutdown-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: Wed, 30 Nov 2016 16:55:01 -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 with Additional Communication 
        Authors         : Job Snijders
                          Jakob Heitz
                          John Scudder
	Filename        : draft-ietf-idr-shutdown-01.txt
	Pages           : 6
	Date            : 2016-11-30

Abstract:
   This document enhances the BGP Cease NOTIFICATION message
   "Administrative Shutdown" subcode for operators to transmit a short
   freeform message to describe why a BGP session was shutdown.



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-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-shutdown-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 Wed Nov 30 12:53:04 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD708129ACC for ; Wed, 30 Nov 2016 12:53:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.831
X-Spam-Level: 
X-Spam-Status: No, score=-4.831 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.896, SPF_SOFTFAIL=0.665] 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 3UTDLGNzYwYV for ; Wed, 30 Nov 2016 12:52:59 -0800 (PST)
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 B1340129BC0 for ; Wed, 30 Nov 2016 12:49:07 -0800 (PST)
Received: by mail3.mlpsca01.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cCBoP-000FA2-T5 (job@us.ntt.net); Wed, 30 Nov 2016 20:49:07 +0000
Date: Wed, 30 Nov 2016 21:49:03 +0100
From: Job Snijders 
To: idr@ietf.org
Message-ID: <20161130204903.GH10210@Vurt.local>
References: <148052490104.3081.2049626653192295584.idtracker@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <148052490104.3081.2049626653192295584.idtracker@ietfa.amsl.com>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.7.1 (2016-10-04)
Archived-At: 
Subject: Re: [Idr] I-D Action: draft-ietf-idr-shutdown-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: Wed, 30 Nov 2016 20:53:02 -0000

Hi all,

The significant change between -00 and -01 is the addition of the
"length" indicator as suggested by Bruno Decraene.

I manually created a PCAP file to show what the shutdown communication
looks like on the wire. This file can be used to test wireshark, tcpdump
and other packet analysers.

	http://instituut.net/~job/shutdown.pcap

This is the frame of interest:

Vurt:~ job$ tcpdump -XX -r shutdown.pcap -c 4,5 -v
reading from file shutdown.pcap, link-type EN10MB (Ethernet)
20:19:25.904210 IP (tos 0xc0, ttl 64, id 53942, offset 0, flags [DF], proto TCP (6), length 198)
    shutdown.meerval.net.45016 > kiera.meerval.net.bgp: Flags [P.], cksum 0x9754 (correct), seq 791846767:791846913, ack 3734170538, win 2048, options [nop,nop,TS val 1416108449 ecr 4177813403], length 146: BGP
    Notification Message (3), length: 146, Cease (6), subcode Administratively Shutdown (2)
    0x0000:  5254 0097 e0df 5254 0021 7f49 0800 45c0  RT....RT.!.I..E.
    0x0010:  00c6 d2b6 4000 4006 1c8b a5fe ff18 a5fe  ....@.@.........
    0x0020:  ff1a afd8 00b3 2f32 9f6f de92 ebaa 8018  ....../2.o......
    0x0030:  0800 9754 0000 0101 080a 5468 19a1 f904  ...T......Th....
    0x0040:  5f9b ffff ffff ffff ffff ffff ffff ffff  _...............
    0x0050:  ffff 0092 0306 027f 4e54 5420 7769 6c6c  ........NTT.will
    0x0060:  2070 6572 666f 726d 206d 6169 6e74 656e  .perform.mainten
    0x0070:  616e 6365 206f 6e20 7468 6973 2072 6f75  ance.on.this.rou
    0x0080:  7465 722e 2054 6869 7320 6973 2074 7261  ter..This.is.tra
    0x0090:  636b 6564 2069 6e20 5449 434b 4554 2d31  cked.in.TICKET-1
    0x00a0:  2d32 3438 3234 3239 342e 2043 6f6e 7461  -24824294..Conta
    0x00b0:  6374 206e 6f63 406e 7474 2e6e 6574 2066  ct.noc@ntt.net.f
    0x00c0:  6f72 206d 6f72 6520 696e 666f 726d 6174  or.more.informat
    0x00d0:  696f 6e2e                                ion.

Kind regards,

Job

On Wed, Nov 30, 2016 at 08:55:01AM -0800, internet-drafts@ietf.org wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Inter-Domain Routing of the IETF.
> 
>         Title           : BGP Administrative Shutdown with Additional Communication 
>         Authors         : Job Snijders
>                           Jakob Heitz
>                           John Scudder
> 	Filename        : draft-ietf-idr-shutdown-01.txt
> 	Pages           : 6
> 	Date            : 2016-11-30
> 
> Abstract:
>    This document enhances the BGP Cease NOTIFICATION message
>    "Administrative Shutdown" subcode for operators to transmit a short
>    freeform message to describe why a BGP session was shutdown.
> 
> 
> 
> 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-01
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-shutdown-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/
> 
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr


From nobody Wed Nov 30 13:00:57 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E630B129A63 for ; Wed, 30 Nov 2016 13:00:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.797
X-Spam-Level: 
X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-2.896, 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 PHt1jq_ZjRKV for ; Wed, 30 Nov 2016 13:00:51 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id D65FF129A5E for ; Wed, 30 Nov 2016 12:58:48 -0800 (PST)
Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id 571571E341; Wed, 30 Nov 2016 16:02:07 -0500 (EST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_C2DCA0A5-50E1-4662-ABB5-9CDF7F5D61D8"
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
From: Jeffrey Haas 
In-Reply-To: <20161130204903.GH10210@Vurt.local>
Date: Wed, 30 Nov 2016 15:58:47 -0500
Message-Id: 
References: <148052490104.3081.2049626653192295584.idtracker@ietfa.amsl.com> <20161130204903.GH10210@Vurt.local>
To: Job Snijders 
X-Mailer: Apple Mail (2.3251)
Archived-At: 
Cc: idr@ietf.org
Subject: Re: [Idr] I-D Action: draft-ietf-idr-shutdown-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: Wed, 30 Nov 2016 21:00:54 -0000

--Apple-Mail=_C2DCA0A5-50E1-4662-ABB5-9CDF7F5D61D8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

I'm somewhat behind in my mail, but why was the data length of the =
notification message not sufficient?

The main motivation for asking is by having two distinct length fields, =
you now have two different overruns to deal with:
1. The data overruns the length field of the string. (Extra stuff, do =
what?)
2. The length of the string overruns the data. (Not enough stuff, =
completely malformed.)

-- Jeff

> On Nov 30, 2016, at 3:49 PM, Job Snijders  wrote:
>=20
> Hi all,
>=20
> The significant change between -00 and -01 is the addition of the
> "length" indicator as suggested by Bruno Decraene.
>=20
> I manually created a PCAP file to show what the shutdown communication
> looks like on the wire. This file can be used to test wireshark, =
tcpdump
> and other packet analysers.
>=20
> 	http://instituut.net/~job/shutdown.pcap =

>=20
> This is the frame of interest:
>=20
> Vurt:~ job$ tcpdump -XX -r shutdown.pcap -c 4,5 -v
> reading from file shutdown.pcap, link-type EN10MB (Ethernet)
> 20:19:25.904210 IP (tos 0xc0, ttl 64, id 53942, offset 0, flags [DF], =
proto TCP (6), length 198)
>    shutdown.meerval.net .45016 > =
kiera.meerval.net.bgp: Flags [P.], cksum 0x9754 (correct), seq =
791846767:791846913, ack 3734170538, win 2048, options [nop,nop,TS val =
1416108449 ecr 4177813403], length 146: BGP
>    Notification Message (3), length: 146, Cease (6), subcode =
Administratively Shutdown (2)
>    0x0000:  5254 0097 e0df 5254 0021 7f49 0800 45c0  RT....RT.!.I..E.
>    0x0010:  00c6 d2b6 4000 4006 1c8b a5fe ff18 a5fe  ....@.@.........
>    0x0020:  ff1a afd8 00b3 2f32 9f6f de92 ebaa 8018  ....../2.o......
>    0x0030:  0800 9754 0000 0101 080a 5468 19a1 f904  ...T......Th....
>    0x0040:  5f9b ffff ffff ffff ffff ffff ffff ffff  _...............
>    0x0050:  ffff 0092 0306 027f 4e54 5420 7769 6c6c  ........NTT.will
>    0x0060:  2070 6572 666f 726d 206d 6169 6e74 656e  .perform.mainten
>    0x0070:  616e 6365 206f 6e20 7468 6973 2072 6f75  ance.on.this.rou
>    0x0080:  7465 722e 2054 6869 7320 6973 2074 7261  ter..This.is =
.tra
>    0x0090:  636b 6564 2069 6e20 5449 434b 4554 2d31  cked.in.TICKET-1
>    0x00a0:  2d32 3438 3234 3239 342e 2043 6f6e 7461  -24824294..Conta
>    0x00b0:  6374 206e 6f63 406e 7474 2e6e 6574 2066  ct.noc@ntt.net.f =

>    0x00c0:  6f72 206d 6f72 6520 696e 666f 726d 6174  or.more.informat
>    0x00d0:  696f 6e2e                                ion.
>=20
> Kind regards,
>=20
> Job
>=20
> On Wed, Nov 30, 2016 at 08:55:01AM -0800, internet-drafts@ietf.org =
 wrote:
>>=20
>> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
>> This draft is a work item of the Inter-Domain Routing of the IETF.
>>=20
>>        Title           : BGP Administrative Shutdown with Additional =
Communication=20
>>        Authors         : Job Snijders
>>                          Jakob Heitz
>>                          John Scudder
>> 	Filename        : draft-ietf-idr-shutdown-01.txt
>> 	Pages           : 6
>> 	Date            : 2016-11-30
>>=20
>> Abstract:
>>   This document enhances the BGP Cease NOTIFICATION message
>>   "Administrative Shutdown" subcode for operators to transmit a short
>>   freeform message to describe why a BGP session was shutdown.
>>=20
>>=20
>>=20
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-idr-shutdown/
>>=20
>> There's also a htmlized version available at:
>> https://tools.ietf.org/html/draft-ietf-idr-shutdown-01
>>=20
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-shutdown-01
>>=20
>>=20
>> Please note that it may take a couple of minutes from the time of =
submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>=20
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>=20
>> _______________________________________________
>> Idr mailing list
>> Idr@ietf.org 
>> https://www.ietf.org/mailman/listinfo/idr =

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


--Apple-Mail=_C2DCA0A5-50E1-4662-ABB5-9CDF7F5D61D8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

I'm somewhat behind in my mail, but why was the data length =
of the notification message not sufficient?

The main motivation for asking is by =
having two distinct length fields, you now have two different overruns =
to deal with:
1. The data overruns the length field =
of the string. (Extra stuff, do what?)
2. The =
length of the string overruns the data. (Not enough stuff, completely =
malformed.)

-- =
Jeff

On Nov 30, 2016, at 3:49 PM, Job Snijders =
<job@ntt.net> =
wrote:

Hi all,

The significant change between -00 and -01 is =
the addition of the
"length" indicator as suggested by Bruno =
Decraene.

I manually created =
a PCAP file to show what the shutdown communication
looks like on the =
wire. This file can be used to test wireshark, tcpdump
and other packet =
analysers.

	http://instituut.net/~job/shutdown.pcap

This is the frame of interest:

Vurt:~ job$ tcpdump -XX -r shutdown.pcap =
-c 4,5 -v
reading from file shutdown.pcap, link-type =
EN10MB (Ethernet)
20:19:25.904210 IP (tos 0xc0, ttl 64, id 53942, =
offset 0, flags [DF], proto TCP (6), length 198)
   shutdown.meerval.net.45016 > kiera.meerval.net.bgp: Flags [P.], =
cksum 0x9754 (correct), seq 791846767:791846913, ack 3734170538, win =
2048, options [nop,nop,TS val 1416108449 ecr 4177813403], length 146: =
BGP
   Notification Message (3), =
length: 146, Cease (6), subcode Administratively Shutdown (2)
   0x0000:  5254 0097 e0df 5254 0021 7f49 =
0800 45c0  RT....RT.!.I..E.
   0x0010:  00c6 d2b6 =
4000 4006 1c8b a5fe ff18 a5fe  ....@.@.........
   0x0020:  ff1a afd8 00b3 2f32 9f6f de92 =
ebaa 8018  ....../2.o......
   0x0030:  0800 9754 =
0000 0101 080a 5468 19a1 f904  ...T......Th....
   0x0040:  5f9b ffff ffff ffff ffff ffff =
ffff ffff  _...............
   0x0050:  ffff 0092 =
0306 027f 4e54 5420 7769 6c6c  ........NTT.will
   0x0060:  2070 6572 666f 726d 206d 6169 =
6e74 656e  .perform.mainten
   0x0070:  616e 6365 =
206f 6e20 7468 6973 2072 6f75  ance.on.this.rou
   0x0080:  7465 722e 2054 6869 7320 6973 =
2074 7261  ter..This.is.tra
   0x0090:  636b 6564 2069 6e20 5449 434b =
4554 2d31  cked.in.TICKET-1
   0x00a0:  2d32 3438 =
3234 3239 342e 2043 6f6e 7461  -24824294..Conta
   0x00b0:  6374 206e 6f63 406e 7474 2e6e =
6574 2066  ct.noc@ntt.net.f
   0x00c0:  6f72 206d =
6f72 6520 696e 666f 726d 6174  or.more.informat
   0x00d0:  696f 6e2e =
            &n=
bsp;           &nbs=
p;      ion.

Kind regards,

Job

On Wed, Nov 30, 2016 at 08:55:01AM -0800, internet-drafts@ietf.org wrote:

A New Internet-Draft is available from the =
on-line Internet-Drafts directories.
This draft is a work =
item of the Inter-Domain Routing of the IETF.

       Title =
          : BGP =
Administrative Shutdown with Additional Communication 
       Authors =
        : Job Snijders
          &nb=
sp;            =
;  Jakob Heitz
          &nb=
sp;            =
;  John Scudder
	Filename =
       : =
draft-ietf-idr-shutdown-01.txt
	Pages =
          : 6
	=
Date =
           : =
2016-11-30

Abstract:
  This document enhances the BGP Cease NOTIFICATION =
message
  "Administrative Shutdown" subcode for =
operators to transmit a short
  freeform message =
to describe why a BGP session was shutdown.



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-01

A diff from the previous version is available =
at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-shutdown-01<=
br class=3D"">

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

=

--Apple-Mail=_C2DCA0A5-50E1-4662-ABB5-9CDF7F5D61D8--


From nobody Wed Nov 30 13:12:28 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11B7F129548 for ; Wed, 30 Nov 2016 13:12:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.83
X-Spam-Level: 
X-Spam-Status: No, score=-4.83 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.896, SPF_SOFTFAIL=0.665] 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 HnAU_QaAJ_t8 for ; Wed, 30 Nov 2016 13:12:23 -0800 (PST)
Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (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 3C0ED129AD7 for ; Wed, 30 Nov 2016 13:11:58 -0800 (PST)
Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cCCAV-0006wy-8f (job@us.ntt.net); Wed, 30 Nov 2016 21:11:57 +0000
Date: Wed, 30 Nov 2016 22:11:35 +0100
From: job@ntt.net
To: Jeffrey Haas 
Message-ID: <9a356e5b-21ab-4ca4-be16-72326a357eea@Spark>
In-Reply-To: 
References: <148052490104.3081.2049626653192295584.idtracker@ietfa.amsl.com> <20161130204903.GH10210@Vurt.local> 
X-Readdle-Message-ID: 9a356e5b-21ab-4ca4-be16-72326a357eea@Spark
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="583f4096_6b8b4567_434"
Archived-At: 
Cc: idr@ietf.org
Subject: Re: [Idr] I-D Action: draft-ietf-idr-shutdown-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: Wed, 30 Nov 2016 21:12:26 -0000

--583f4096_6b8b4567_434
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

For future-proofness sake. John {Scudder,Heasley} and Bruno felt it is better to not fully absorb the extensibility of the Cease NOTIFICATION for this one feature. By doing "Length, Value" as payload we don't close the door on new future things. It seemed "cheap" enough to do.

Kind regards,

Job

On 30 Nov 2016, 21:58 +0100, Jeffrey Haas , wrote:
> I'm somewhat behind in my mail, but why was the data length of the notification message not sufficient?
>
> The main motivation for asking is by having two distinct length fields, you now have two different overruns to deal with:
> 1. The data overruns the length field of the string. (Extra stuff, do what?)
> 2. The length of the string overruns the data. (Not enough stuff, completely malformed.)
>
> -- Jeff
>
> > On Nov 30, 2016, at 3:49 PM, Job Snijders  wrote:
> > Hi all,
> >
> > The significant change between -00 and -01 is the addition of the
> > "length" indicator as suggested by Bruno Decraene.
> >
> > I manually created a PCAP file to show what the shutdown communication
> > looks like on the wire. This file can be used to test wireshark, tcpdump
> > and other packet analysers.
> >
> > http://instituut.net/~job/shutdown.pcap
> >
> > This is the frame of interest:
> >
> > Vurt:~ job$ tcpdump -XX -r shutdown.pcap -c 4,5 -v
> > reading from file shutdown.pcap, link-type EN10MB (Ethernet)
> > 20:19:25.904210 IP (tos 0xc0, ttl 64, id 53942, offset 0, flags [DF], proto TCP (6), length 198)
> > shutdown.meerval.net (http://shutdown.meerval.net/).45016 > kiera.meerval.net.bgp: Flags [P.], cksum 0x9754 (correct), seq 791846767:791846913 (tel:791846913), ack 3734170538 (tel:3734170538), win 2048, options [nop,nop,TS val 1416108449 (tel:1416108449) ecr 4177813403 (tel:4177813403)], length 146: BGP
> > Notification Message (3), length: 146, Cease (6), subcode Administratively Shutdown (2)
> > 0x0000: 5254 0097 (tel:5254%200097) e0df 5254 0021 (tel:5254%200021) 7f49 0800 45c0 RT....RT.!.I..E.
> > 0x0010: 00c6 d2b6 4000 4006 (tel:4000%204006) 1c8b a5fe ff18 a5fe ....@.@.........
> > 0x0020: ff1a afd8 00b3 2f32 9f6f de92 ebaa 8018 ....../2.o......
> > 0x0030: 0800 9754 0000 0101 (tel:0800%209754%200000%200101) 080a 5468 19a1 f904 ...T......Th....
> > 0x0040: 5f9b ffff ffff ffff ffff ffff ffff ffff _...............
> > 0x0050: ffff 0092 0306 (tel:0092%200306) 027f 4e54 5420 7769 (tel:5420%207769) 6c6c ........NTT.will
> > 0x0060: 2070 6572 (tel:2070%206572) 666f 726d 206d 6169 6e74 656e .perform.mainten
> > 0x0070: 616e 6365 206f 6e20 7468 6973 2072 (tel:7468%206973%202072) 6f75 ance.on.this.rou
> > 0x0080: 7465 722e 2054 6869 7320 6973 (tel:2054%206869%207320%206973) 2074 7261 ter..This.is (http://this.is/).tra
> > 0x0090: 636b 6564 2069 (tel:6564%202069) 6e20 5449 434b 4554 2d31 cked.in.TICKET-1
> > 0x00a0: 2d32 3438 3234 3239 (tel:3438%203234%203239) 342e 2043 6f6e 7461 -24824294 (tel:24824294)..Conta
> > 0x00b0: 6374 206e 6f63 406e 7474 2e6e 6574 2066 (tel:6574%202066) ct.noc@ntt.net.f (mailto:ct.noc@ntt.net.f)
> > 0x00c0: 6f72 206d 6f72 6520 696e 666f 726d 6174 or.more.informat
> > 0x00d0: 696f 6e2e ion.
> >
> > Kind regards,
> >
> > Job
> >
> > On Wed, Nov 30, 2016 at 08:55:01AM -0800, internet-drafts@ietf.org (mailto:internet-drafts@ietf.org) wrote:
> > >
> > > A New Internet-Draft is available from the on-line Internet-Drafts directories.
> > > This draft is a work item of the Inter-Domain Routing of the IETF.
> > >
> > > Title : BGP Administrative Shutdown with Additional Communication
> > > Authors : Job Snijders
> > > Jakob Heitz
> > > John Scudder
> > > Filename : draft-ietf-idr-shutdown-01.txt
> > > Pages : 6
> > > Date : 2016-11-30
> > >
> > > Abstract:
> > > This document enhances the BGP Cease NOTIFICATION message
> > > "Administrative Shutdown" subcode for operators to transmit a short
> > > freeform message to describe why a BGP session was shutdown.
> > >
> > >
> > >
> > > 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-01
> > >
> > > A diff from the previous version is available at:
> > > https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-shutdown-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/
> > >
> > > _______________________________________________
> > > Idr mailing list
> > > Idr@ietf.org (mailto:Idr@ietf.org)
> > > https://www.ietf.org/mailman/listinfo/idr
> >
> > _______________________________________________
> > Idr mailing list
> > Idr@ietf.org (mailto:Idr@ietf.org)
> > https://www.ietf.org/mailman/listinfo/idr

--583f4096_6b8b4567_434
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline







=46or future-proofness sake. John =7B=
Scudder,Heasley=7D and Bruno felt it is better to not fully absorb the ex=
tensibility of the Cease NOTI=46ICATION for this one feature. By doing =22=
Length, Value=22 as payload we don't close the door on new future things.=
 It seemed =22cheap=22 enough to do.




Kind regards,



Job




On 30 Nov 2016, 21:58 +0100, Jeffrey Haas <jhaas=40pfrc.org>, wrote=
:


I'm somewhat behind in my mail, but why was=
 the data length of the notification message not sufficient=3F




The main motivation for asking is by having two disti=
nct length fields, you now have two different overruns to deal with:

1. The data overruns the length field of the string. =
(Extra stuff, do what=3F)


2. The length of the string overruns the data. (Not e=
nough stuff, completely malformed.)





-- Jeff









On Nov 30, 2016, at 3:49 PM, Job Snijders <job=40ntt.net> wrote:=





Hi all,



The significant change between -00 and -01 is the addition of the

=22length=22 indicator as suggested by Bruno Decraene.



I manually created a PCAP file to show what the shutdown communicatio=
n

looks like on the wire. This file can be used to test wireshark, tcpd=
ump

and other packet analysers.



http://instituut.net/=7Ejob/shutdown.pcap=




This is the frame of interest:



Vurt:=7E job=24 tcpdump -XX -r shutdown.pcap -c 4,5 -v

reading from file shutdown.pcap, link-type EN10MB (Ethernet)
20:19:25.904210 IP (tos 0xc0, ttl 64, id 53942, offset 0, flags =5BD=46=
=5D, proto TCP (6), length 198)

&=23160;&=23160;&=23160;shut=
down.meerval.net.45016 > kiera.meerval.net.bgp: =46lags =5BP=
.=5D, cksum 0x9754 (correct), seq 791846767:7918469=
13, ack 3734170538, win 2048, options =5Bn=
op,nop,TS val 1416108449 ecr 4177813403=5D, length 146: BGP

&=23160;&=23160;&=23160;Notification Message (3), length: 146, Cease =
(6), subcode Administratively Shutdown (2)

&=23160;&=23160;&=23160;0x0000: &=23160;5254 =
0097 e0df 5254 0021 7f49 0800 45c0 &=231=
60;RT....RT.=21.I..E.

&=23160;&=23160;&=23160;0x0010: &=23160;00c6 d2b6 4000 4006 1c8b a5fe ff18 a5fe &=23160;....=40.=40.........

&=23160;&=23160;&=23160;0x0020: &=23160;ff1a afd8 00b3 2f32 9f6f de92=
 ebaa 8018 &=23160;....../2.o......

&=23160;&=23160;&=23160;0x0030: &=23160;0800 9754 0000 0101 080a 5468 19a1 f904 &=23160;...T......Th=
....

&=23160;&=23160;&=23160;0x0040: &=23160;5f9b ffff ffff ffff ffff ffff=
 ffff ffff &=23160;=5F...............

&=23160;&=23160;&=23160;0x0050: &=23160;ffff 0=
092 0306 027f 4e54 5420 7769 6c6c &=2316=
0;........NTT.will

&=23160;&=23160;&=23160;0x0060: &=23160;2070=
 6572 666f 726d 206d 6169 6e74 656e &=23160;.perform.mainten
&=23160;&=23160;&=23160;0x0070: &=23160;616e 6365 206f 6e20 7468 6973 2072 6f75 &=23160;ance.on.this.rou

&=23160;&=23160;&=23160;0x0080: &=23160;7465 722e 2054 6869 7320 6973 2074 7261 &=23160;ter..This.is.tra

&=23160;&=23160;&=23160;0x0090: &=23160;636b 6=
564 2069 6e20 5449 434b 4554 2d31 &=23160;cked.in.TICKET-1

&=23160;&=23160;&=23160;0x00a0: &=23160;2d32 3438 3234 3239 342e 2043 6f6e 7461 &=23160;-24824294..Conta

&=23160;&=23160;&=23160;0x00b0: &=23160;6374 206e 6f63 406e 7474 2e6e=
 6574 2066 &=23160;ct.noc=40ntt.net.f

&=23160;&=23160;&=23160;0x00c0: &=23160;6f72 206d 6f72 6520 696e 666f=
 726d 6174 &=23160;or.more.informat

&=23160;&=23160;&=23160;0x00d0: &=23160;696f 6e2e &=23160;&=23160;&=23=
160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=231=
60;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=2316=
0;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160=
;&=23160;ion.



Kind regards,



Job



On Wed, Nov 30, 2016 at 08:55:01AM -0800,&=23160;internet-drafts=40ietf.org&=23160;wrote:




A New Internet-Draft is available from the on-line Internet-Drafts direct=
ories.

This draft is a work item of the Inter-Domain Routing of the IET=46.



&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;Title &=23160;&=23=
160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;: BGP=
 Administrative Shutdown with Additional Communication&=23160;

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;Authors &=23160;&=
=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;: Job Snijders

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=
=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23=
160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;Jakob Heitz

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=
=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23=
160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;John Scudder

=46ilename &=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;: dra=
ft-ietf-idr-shutdown-01.txt

Pages &=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23=
160;&=23160;: 6

Date &=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23=
160;&=23160;&=23160;: 2016-11-30



Abstract:

&=23160;&=23160;This document enhances the BGP Cease NOTI=46ICATION messa=
ge

&=23160;&=23160;=22Administrative Shutdown=22 subcode for operators to tr=
ansmit a short

&=23160;&=23160;freeform message to describe why a BGP session was shutdo=
wn.







The IET=46 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-01



A diff from the previous version is available at:

https://www.ietf.org/rfcdiff=3Furl2=3Ddraft-ietf-idr-shutdown-01





Please note that it may take a couple of minutes from the time of submiss=
ion

until the htmlized version and diff are available at tools.ietf.org.



Internet-Drafts are also available by anonymous =46TP at:

ftp://ftp.ietf.org/internet-drafts/



=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F

Idr mailing list

Idr=40ietf.org
=
https://www.ietf.org/mailman/listinfo/idr



=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F<=
/span>

Idr mailing list

Idr=40ietf.org

https://www.ietf.org/mailm=
an/listinfo/idr














--583f4096_6b8b4567_434--



From nobody Wed Nov 30 13:13:53 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85377129ABE for ; Wed, 30 Nov 2016 13:13:50 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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 wDkhRavHPDIn for ; Wed, 30 Nov 2016 13:13:47 -0800 (PST)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0130.outbound.protection.outlook.com [104.47.36.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 D9E3B129AA1 for ; Wed, 30 Nov 2016 13:13:33 -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=t1JZd2woEZjgVgRKIfs52JdHhkJzCO000UFptcyX3cY=; b=ZczHDeW1q2eYpaLUUOQtjJZOnuzlt0wmL5AwIgw4dntY2OiNr2OzXha2ZodO0EnKxvEYFYuXGRylSrQUpa2HOrE7ptcWsOm0lsUHCidvW7+B/kPXpaVtgoT8BjGlfypGCODzbEeohL7GtaZbCuODbirGs82N4OvBwmDSbh5bsDk=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; 
Received: from [172.29.33.83] (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_256_CBC_SHA384_P384) id 15.1.761.5; Wed, 30 Nov 2016 21:13:30 +0000
Content-Type: multipart/alternative; boundary="Apple-Mail=_298CB57F-754E-492A-A411-083369E5B4CB"
MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: "John G. Scudder" 
In-Reply-To: 
Date: Wed, 30 Nov 2016 16:13:23 -0500
Message-ID: <828EC50E-0659-46F1-90E2-BD883A75A706@juniper.net>
References: <148052490104.3081.2049626653192295584.idtracker@ietfa.amsl.com> <20161130204903.GH10210@Vurt.local> 
To: Jeffrey Haas 
X-Mailer: Apple Mail (2.3124)
X-Originating-IP: [66.129.241.12]
X-ClientProxiedBy: SN1PR17CA0048.namprd17.prod.outlook.com (10.163.3.144) To CO2PR05MB2501.namprd05.prod.outlook.com (10.166.95.147)
X-MS-Office365-Filtering-Correlation-Id: a1cc6b76-2dd1-40e6-e3db-08d41965bcc3
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CO2PR05MB2501;
X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2501; 3:GpRCxCERSxluLL7Bh7nGNkqgq56YgHqoF1teKpvSjVlMamJIGI1XzzT6HPLbr3kRQCbfAkVVgL04KvP4pSYayxb8qljDLsZi3rg673HgnbSazO5G/WNM3AziwgeJyWHo2wumxHz9dqHjF/euG+a3DcDBojzvwd5mNzTwbqnDJ7KMaTJ9EY09KOdnb6wjmmPi6jhL/m3gQ7UScyhbtOF693cPgs5/1f2xGyeHi38pqKV6w/LJ44dxUEt/xF3O0wYZB3Sq3C+DW58yR33KGwh1Yg==; 25:yvVtjUtPn2ADWGbwIzxWIpOSQcLkSkPlUMCABdrE+5oI9ANH8sozohLrya53tROKPsTA59d9ekHN1Okq3duyd/G7kAhEzIm0g92QNstZggxVrpxwPQnPHMtJbTy9VAZSo3K1WJPaHfsy8BO4IQ8tNeLQILJZbXPM7hc25sDZz86iXTmHGvppZ834kKDut9jc8Mwrst9tO7MjQpbYeSdEiTae0neX2DvJthnmXVLvEWKLTHEJ3Z99+ezO0nBfazoJemWZpM2inzWAxUIqtp9x/B8DJe7x4F4A6tCWnUQemx25RBIk2gFl/QUfiPYrcgXaJ8gF/kh0nHXzCw4gSs6ChQeihoF5P+OjdWOIs9QvESiAC40RlvzzbZaFgJTTjx4ukH65BWA5iZdi3DLeMlProMoDT2732d696b63yK95Bpdx9zwu7QXL0/IOMKB+sKFQJLY2x7FX3lYMvOfWgRDcPg==
X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2501; 31:JNzqiDkZ7Je4dEonZTtV/T0QTUXqayN69zXcAyA2dFYIkGpD1Y3xFZt+ZWDM8z/T4PXXR5jdirxejdL6dNW6+Ci7eQS/Po519pLH+El4MLHM058IHTuLK8spHqTyh1ZjLxf/CR4GoyBF5cQqxRVuTZCSIpL3y0JpSuMy3lQu525iW8HgwKZuk6G3pVyZpnxMyrCSZdOky9jlA3+ZNRgcnInBXbZjHDWTsjYTh+7bPdeBqu+KPgHiYohHIWjnjRWelKCE+zfZ60wHCY8vbwT98A==; 20:uSwdbM+YWtvrSa+IJExIU52vnzz9o1AUZDmgzxknRMr4bnxsU/yQQNhByHAqE4Q0Kqs8vL8sNzG8jongua0UWz0ZjFQiQkbNCygBh99vwlLae0JpCwU/S9cpgmaKCoFtdFxcuh0FEgRvuv/E1WhHh9+KP4nmNabU2jyaFWwNO2BPQ3EhbeVjOipbHYs207OmIuH++lV6WSzKHFA/cEkFnNlklxu/a5B7lNDSiPD4eBRM8Fij4php+OQCzIbTYvfJiJyOTo4hCQ9CM5wILeA7fFvLq1VbdEAQKNjWiA3EOEF8jm3PyByTp+eHTODoHn2MMgDM92AF7hWAgwQqIOKwrRKltOMkWP7Cez59TS1SdKq7jscMk7Kq2LttC0E2enO/eqR/LXjluUh7HX1fClroW6hT9RziWoX+EzphbOjAJ4EIVZCvqL9SHw9zqIBOei7tn0LRaAqsuk3CHkPqUJel4JoG4Et090xruBQSVY3XV/wLTYln1ahE1HsKTC6ijDA5SpGxyCTJbeM39z6hP6XP8jYEGnYBJPy9M4O9w3tS1i//f0r9tg6gSNhJDocvI5qRvMIewsR9eMBgGB7JlYQAc31djm4nM5L9R0+a98noSbg=
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(170140475155365)(120809045254105);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123555025)(20161123562025)(20161123560025)(20161123564025)(6072148); SRVR:CO2PR05MB2501; BCL:0; PCL:0; RULEID:; SRVR:CO2PR05MB2501; 
X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2501; 4:5PNr5+w0fWKv/kQ9AsE89b33XYKPTM+W3fOlh0E162SiS/gdZIcve9O7AUDS3Hx/95MOz1Ki9EfVq149vC9Zr/4kZD4DN2b3lOcWeFEVdy+qU54HfX0rOcO5Fm+GNvkxkgKFlUiNwhNnA66P35uxbDtwPIPGeS6HOESlBwzn10sot/61eMza+vWdjC6t8Bse7XTaAhGRRd7Als8lIK6+3Cb6+CvO6/XktgPFiN9SGnLYRG3/udUPYOioNoDLBNKH6bxXTiXfzUtwDU+Ui37xclug81sZ5WwTfG0qaDj/sGO+SrM0LFM48G6jWjNNGMTVcMo+sM+CvheJ7I7a2qSE86KZ6FsLr2IrdJ8BPudfMAbUJMnxHcMX3YHg6qmyW/jcbszP7zF1JxWBJhKwQih0Ooa08AUr4paCKbV/Jo82dW2+1BtBpFkqRVkCoFmn82/5wKY384o/gsMdRyTNdrjWUzqi3zbTabtS1XhXv0+zCP7RLoFxVJ33I881IKwaqOwUOKEB8Du9+AqKt1Bdwj2jxxhW0uGM3otC4RNexNS2pBNWhGl1z2Bz1aOVkNq7PEi3XQtTQjpkORsoLNzRv9SDaYdVAcUL3R81Ag0TsRderC0QopZZa4Owv5ziNsPPxK98ZUiyNhBIEpfQNYMZVjHO/51g+Rs9wFyPdE8skBiH9Kc=
X-Forefront-PRVS: 0142F22657
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(7916002)(377454003)(199003)(53754006)(24454002)(377424004)(189002)(57306001)(229853002)(76176999)(82746002)(101416001)(81156014)(38730400001)(8676002)(575784001)(86362001)(69556001)(6116002)(50986999)(3846002)(606004)(260700001)(66066001)(110136003)(6916009)(6666003)(189998001)(81166006)(2950100002)(5660300001)(512954002)(50226002)(4001150100001)(68736007)(230783001)(733004)(106356001)(97736004)(39410400001)(6486002)(92566002)(39450400002)(42186005)(4326007)(84326002)(83716003)(105586002)(7906003)(15395725005)(2906002)(77096006)(7736002)(36756003)(33656002)(7846002)(104396002)(42262002)(579004)(357404004); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB2501; H:[172.29.33.83]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; 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:zYvS0B3u14XsJpZfebqfPI9RuKqQHEIQSK8EPfaho?= =?us-ascii?Q?azbyy65yS+rtRtpRlt44pl0CWaq+/y2xzORe6JYyvKdy/wf33jD4hApU6LCZ?= =?us-ascii?Q?333lHfdkUh6uieO0kdi9rsef930nlKgXLx0B9arXYPyVHgvD3NLOGUYNOOGR?= =?us-ascii?Q?YBiyMnRsyYE6Wqgcg6uZgvAOU0vqeTZZwnLkUBRoSRbQPmXT/Jr4RL1a0aAM?= =?us-ascii?Q?gJHUa6mO5evMEyvBOm7y5TDooXZvYBXfG18NCW/7GyN+TLXpNI6kmEpLtMHJ?= =?us-ascii?Q?7EW7paZrLJOSTL7qIc9HuC/AKQpRvwjFul4aWKQPySKREEBHY44wAPWSA1Ov?= =?us-ascii?Q?CIWf/F7UYmaFI0QSfnyerkQnk+lb1fmjjsLGwyohb3AMvv6HZJE3e/bZ6zGN?= =?us-ascii?Q?nMVDMjBXhWw/rNnqZ38jat/W4n+3784tHQQZht78qnaVKIZUnX86etEMxPHP?= =?us-ascii?Q?FDCFUTh5pyu3z8oGTkyv3e2NeBzHO7VhDQhlrMjc4452ELCmrNywKrUZ/NSM?= =?us-ascii?Q?LbotLXXYrZ+oYQDFwpxVTbBMqnaWt3M3eWyaVXdqYCc55/Jimn9reiMvopw1?= =?us-ascii?Q?OQd7nTlD+x46nXvGOghvV039Jw4l2KU9ZuCBcP/8+46cp9Q1CfzG5kbwr6PO?= =?us-ascii?Q?E6EaETGo+Fmuc1J1nzJ7A0khyXN3epQhdbjpWo8OkOLeKjz47UMNon0q2aUn?= =?us-ascii?Q?b1QCxhII3xhLTunx5H7Fl37/l700Zlq48XUfh0uRYJqGRwVHdRf9B+yj4Otk?= =?us-ascii?Q?shv9SmEa4nax3XjKE9EzCQPSaiIlwdKfIUzhe9L0r4sn1Ub71OybKK09kaoZ?= =?us-ascii?Q?gL7BN0LWAph1mu/gpXY8a8YfBt4MCC5ZU9SBG410J/8sBZe7yfF5HOoTZPMJ?= =?us-ascii?Q?qyHuX4XaKCHBgHMvZTRR84pYskD+CNs6FD/B5JX/3j3YlLWRnQwNosRnVLqS?= =?us-ascii?Q?dUTUL2gL/5r1E7w40d4vu9+I9k2cSx3x9Wzx58O20OWcBisGE3/yUg3xroGu?= =?us-ascii?Q?2x9HDIOwIofo1FuP0akt/PrXw6r01r46aTW6LlCtrjYxcI+5mhM6ekcZGhzO?= =?us-ascii?Q?4f61xwd/Nd7dMYR9/IERvWrl0/QO1NMFG91YugDNsv9PuveLUlMBM1LN/lZ9?= =?us-ascii?Q?m1kYcq0XQ+bNtghOgZuJZluRimNNPQaLTP/2VoMZn1BupqGfwXJnGsZ/m2Qj?= =?us-ascii?Q?h454MdQqR6vXhongAYXzs+pLolCOBWr0fbmtyhcCaoiyZp5X45B9rA/+QBfm?= =?us-ascii?Q?d++S7uOTOFXegQqbY3Rx6vwHiTGJrcSNk4HyRF9I3fpU2ETGp9CsJBEWlKZu?= =?us-ascii?Q?CRZuudwmjIe0wNO7DPDtf859HVL3a/Mcvnv5C+c7uAAQ5CG+YXRdSJG94isK?= =?us-ascii?Q?XonWrASTGCDpsI18vNK37KhfEzmZARSQ5Qq+VLRqu5RVQJ9JznebZ40+Q/IE?= =?us-ascii?Q?CjXX/0tU7fR56rXx6ThT4ziTWjhanUOR+RoYP85MMAxbl8UCyrv?=
X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2501; 6:cWyurilbzaz81UeMRdaqIAK0Tm/eKw9ayLCFrrk7YQfoaUfP7TKVUyiYUo73j7j/HuI8uo0RWpKe878Z0byqprb4kSj1Hy/iINCJzdwuXbk8fY61m7mCWgDgGVSALic+b/UnVi5ujJul5GP5zBfCv9MtuWbhb6ud7bqKR8hbcSVxKqiOZtzs0JD2YOafb82scExzifqmZa3EG4cMQhcmaVME31fxb7Kx2Hj+6HJXAsobHWQKUnorUeT1sDdp7SqpCpa6vl0abllHVYVABNWZyb2D4vDw/ScsTNx8fuu+yCtSSlJzO2t2Jf0bX36BnW4MnX8dxt4zrtHsEfyJOVpnD/Vtd6ifMhKLoitWsQH0ssJ2gWDcTRuXdMfHg3vaiJgQ5JfwVQvsH0PzxMcffCfbg2oRTpv5D7BpmHEDdTImCs4kAP7Q4SplBk7JADqnQMzdPsyNuOSxAlggi9H1vmnMJ6zA+J1VXz/G9pVJOZWry+CwFXyhP9ezBXfK52FhOqPA; 5:dFeRLfmaox6vwGOROGuliUi1ap0h0pa5T0nFyehkcNs1GtpbShIu7qa419fFY1dcG5525Wy7bix/DJhSEVqMsglgJzsO1peG/P5bDCBLkOlBKTVA2QyqFYZMusUYb7n74Fji1Hl7GqPJoNAwFPzY8Q==; 24:u3tSrrlGOVTLuzs49SafwP5HaqA6S0JQ2OOCkVpGT2PsIdBdT0xBUPRodvevu1RPufyWEsQ6F9JIoasjj01JPnp+P6gMSBaEJopJ7zHcyu4=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2501; 7:5ycgyUoi7CTsziEE69Zc1uB1fK6e/gSaGJvx4mQ9PBnioIkzGPWm/cT4+z7sjqfhcPjR9pb2w+C3EXLzdw8hBQFAfMwYwylwcWLekN9rahR/GjXLvKMTAT2nTEAizhGScd4bqCmT2f8WbdOHnIBUf8xpdOQvTyVc5YBWcndMR+M9ryFyn+9l5VxGa58SH2e7adPZ18+gf7n6CMy+cuv0CL8m/Q2oVJLf0ppiSE97igTFT8Yor5LlDX3/34KzTJ/cOlZ8pXzlu/dvj2yfQf7i8If7O9svVhL5+azr7chbhvaGJTG6yQ4Hc7wdhLW2SWjHIi+wdEnT8vPBWsME8N8pU5+81ZM1pvv7LJij1m8nnZayhT9ZrjAxx2MExXn9Dj47zdfu/NFuJkNkyPKvrwHw5uDxh716YAvei6eVtX0VWQq2n75EmEJhBLjcd23xiEyngaAANJhKJJ6beJ1R4RylJg==
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Nov 2016 21:13:30.5690 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB2501
Archived-At: 
Cc: idr@ietf.org
Subject: Re: [Idr] I-D Action: draft-ietf-idr-shutdown-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: Wed, 30 Nov 2016 21:13:50 -0000

--Apple-Mail=_298CB57F-754E-492A-A411-083369E5B4CB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="us-ascii"

On Nov 30, 2016, at 3:58 PM, Jeffrey Haas  wrote:
> I'm somewhat behind in my mail, but why was the data length of the =
notification message not sufficient?

It would have been sufficient had the string length not been limited to =
128 bytes, but it is. Beyond that, if you haven't seen these they should =
provide context.

https://www.ietf.org/mail-archive/web/idr/current/msg17117.html
https://www.ietf.org/mail-archive/web/idr/current/msg17118.html
https://www.ietf.org/mail-archive/web/idr/current/msg17170.html

> The main motivation for asking is by having two distinct length =
fields, you now have two different overruns to deal with:
> 1. The data overruns the length field of the string. (Extra stuff, do =
what?)

Presumably what everyone does now, hex dump it.

> 2. The length of the string overruns the data. (Not enough stuff, =
completely malformed.)

In any case, the connection's going down no matter what so I'm not sure =
there's a need to be as punctilious about error cases as we are for =
other message types.

--John
=20
>=20
> -- Jeff
>=20
>> On Nov 30, 2016, at 3:49 PM, Job Snijders > wrote:
>>=20
>> Hi all,
>>=20
>> The significant change between -00 and -01 is the addition of the
>> "length" indicator as suggested by Bruno Decraene.
>>=20
>> I manually created a PCAP file to show what the shutdown =
communication
>> looks like on the wire. This file can be used to test wireshark, =
tcpdump
>> and other packet analysers.
>>=20
>> 	http://instituut.net/~job/shutdown.pcap =

>>=20
>> This is the frame of interest:
>>=20
>> Vurt:~ job$ tcpdump -XX -r shutdown.pcap -c 4,5 -v
>> reading from file shutdown.pcap, link-type EN10MB (Ethernet)
>> 20:19:25.904210 IP (tos 0xc0, ttl 64, id 53942, offset 0, flags [DF], =
proto TCP (6), length 198)
>>    shutdown.meerval.net .45016 > =
kiera.meerval.net.bgp: Flags [P.], cksum 0x9754 (correct), seq =
791846767:791846913, ack 3734170538, win 2048, options [nop,nop,TS val =
1416108449 ecr 4177813403], length 146: BGP
>>    Notification Message (3), length: 146, Cease (6), subcode =
Administratively Shutdown (2)
>>    0x0000:  5254 0097 e0df 5254 0021 7f49 0800 45c0  RT....RT.!.I..E.
>>    0x0010:  00c6 d2b6 4000 4006 1c8b a5fe ff18 a5fe  ....@.@.........
>>    0x0020:  ff1a afd8 00b3 2f32 9f6f de92 ebaa 8018  ....../2.o......
>>    0x0030:  0800 9754 0000 0101 080a 5468 19a1 f904  ...T......Th....
>>    0x0040:  5f9b ffff ffff ffff ffff ffff ffff ffff  _...............
>>    0x0050:  ffff 0092 0306 027f 4e54 5420 7769 6c6c  ........NTT.will
>>    0x0060:  2070 6572 666f 726d 206d 6169 6e74 656e  .perform.mainten
>>    0x0070:  616e 6365 206f 6e20 7468 6973 2072 6f75  ance.on.this.rou
>>    0x0080:  7465 722e 2054 6869 7320 6973 2074 7261  ter..This.is =
.tra
>>    0x0090:  636b 6564 2069 6e20 5449 434b 4554 2d31  cked.in.TICKET-1
>>    0x00a0:  2d32 3438 3234 3239 342e 2043 6f6e 7461  -24824294..Conta
>>    0x00b0:  6374 206e 6f63 406e 7474 2e6e 6574 2066  ct.noc@ntt.net.f =

>>    0x00c0:  6f72 206d 6f72 6520 696e 666f 726d 6174  or.more.informat
>>    0x00d0:  696f 6e2e                                ion.
>>=20
>> Kind regards,
>>=20
>> Job
>>=20
>> On Wed, Nov 30, 2016 at 08:55:01AM -0800, internet-drafts@ietf.org =
 wrote:
>>>=20
>>> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
>>> This draft is a work item of the Inter-Domain Routing of the IETF.
>>>=20
>>>        Title           : BGP Administrative Shutdown with Additional =
Communication=20
>>>        Authors         : Job Snijders
>>>                          Jakob Heitz
>>>                          John Scudder
>>> 	Filename        : draft-ietf-idr-shutdown-01.txt
>>> 	Pages           : 6
>>> 	Date            : 2016-11-30
>>>=20
>>> Abstract:
>>>   This document enhances the BGP Cease NOTIFICATION message
>>>   "Administrative Shutdown" subcode for operators to transmit a =
short
>>>   freeform message to describe why a BGP session was shutdown.
>>>=20
>>>=20
>>>=20
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-idr-shutdown/ =

>>>=20
>>> There's also a htmlized version available at:
>>> https://tools.ietf.org/html/draft-ietf-idr-shutdown-01
>>>=20
>>> A diff from the previous version is available at:
>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-shutdown-01
>>>=20
>>>=20
>>> Please note that it may take a couple of minutes from the time of =
submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>>=20
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>=20
>>> _______________________________________________
>>> Idr mailing list
>>> Idr@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/idr =

>>=20
>> _______________________________________________
>> 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=_298CB57F-754E-492A-A411-083369E5B4CB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="us-ascii"

On Nov 30, 2016, at 3:58 PM, Jeffrey Haas <jhaas@pfrc.org> =
wrote:


I'm somewhat behind in my mail, but why was the data length =
of the notification message not =
sufficient?

It would =
have been sufficient had the string length not been limited to 128 =
bytes, but it is. Beyond that, if you haven't seen these they should =
provide context.


The main motivation for asking is by having two distinct =
length fields, you now have two different overruns to deal =
with:
1. The data overruns the length field of the =
string. (Extra stuff, do what?)

Presumably what everyone does now, hex dump =
it.

2. The length of the string overruns the data. (Not enough =
stuff, completely malformed.)

In any case, the connection's going down no matter =
what so I'm not sure there's a need to be as punctilious about error =
cases as we are for other message types.

--John
 

-- Jeff

On Nov =
30, 2016, at 3:49 PM, Job Snijders <job@ntt.net> wrote:

Hi all,

The significant change between -00 and -01 is =
the addition of the
"length" indicator as suggested by Bruno =
Decraene.

I manually created =
a PCAP file to show what the shutdown communication
looks like on the =
wire. This file can be used to test wireshark, tcpdump
and other packet =
analysers.

	http://instituut.net/~job/shutdown.pcap

This is the frame of interest:

Vurt:~ job$ tcpdump -XX -r shutdown.pcap =
-c 4,5 -v
reading from file shutdown.pcap, link-type =
EN10MB (Ethernet)
20:19:25.904210 IP (tos 0xc0, ttl 64, id 53942, =
offset 0, flags [DF], proto TCP (6), length 198)
   shutdown.meerval.net.45016 > kiera.meerval.net.bgp: Flags [P.], =
cksum 0x9754 (correct), seq 791846767:791846913, ack 3734170538, win =
2048, options [nop,nop,TS val 1416108449 ecr 4177813403], length 146: =
BGP
   Notification Message (3), =
length: 146, Cease (6), subcode Administratively Shutdown (2)
   0x0000:  5254 0097 e0df 5254 0021 7f49 =
0800 45c0  RT....RT.!.I..E.
   0x0010:  00c6 d2b6 =
4000 4006 1c8b a5fe ff18 a5fe  ....@.@.........
   0x0020:  ff1a afd8 00b3 2f32 9f6f de92 =
ebaa 8018  ....../2.o......
   0x0030:  0800 9754 =
0000 0101 080a 5468 19a1 f904  ...T......Th....
   0x0040:  5f9b ffff ffff ffff ffff ffff =
ffff ffff  _...............
   0x0050:  ffff 0092 =
0306 027f 4e54 5420 7769 6c6c  ........NTT.will
   0x0060:  2070 6572 666f 726d 206d 6169 =
6e74 656e  .perform.mainten
   0x0070:  616e 6365 =
206f 6e20 7468 6973 2072 6f75  ance.on.this.rou
   0x0080:  7465 722e 2054 6869 7320 6973 =
2074 7261  ter..This.is.tra
   0x0090:  636b 6564 2069 6e20 5449 434b =
4554 2d31  cked.in.TICKET-1
   0x00a0:  2d32 3438 =
3234 3239 342e 2043 6f6e 7461  -24824294..Conta
   0x00b0:  6374 206e 6f63 406e 7474 2e6e =
6574 2066  ct.noc@ntt.net.f
   0x00c0:  6f72 206d =
6f72 6520 696e 666f 726d 6174  or.more.informat
   0x00d0:  696f 6e2e =
            &n=
bsp;           &nbs=
p;      ion.

Kind regards,

Job

On Wed, Nov 30, 2016 at 08:55:01AM -0800, internet-drafts@ietf.org wrote:

A New Internet-Draft is available from the =
on-line Internet-Drafts directories.
This draft is a work =
item of the Inter-Domain Routing of the IETF.

       Title =
          : BGP =
Administrative Shutdown with Additional Communication 
       Authors =
        : Job Snijders
          &nb=
sp;            =
;  Jakob Heitz
          &nb=
sp;            =
;  John Scudder
	Filename =
       : =
draft-ietf-idr-shutdown-01.txt
	Pages =
          : 6
	=
Date =
           : =
2016-11-30

Abstract:
  This document enhances the BGP Cease NOTIFICATION =
message
  "Administrative Shutdown" subcode for =
operators to transmit a short
  freeform message =
to describe why a BGP session was shutdown.



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-01

A diff from the previous version is available =
at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-shutdown-01<=
br class=3D"">

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

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

=

--Apple-Mail=_298CB57F-754E-492A-A411-083369E5B4CB--


From nobody Wed Nov 30 13:21:30 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E14C1294B9 for ; Wed, 30 Nov 2016 13:21:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.797
X-Spam-Level: 
X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-2.896, 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 bGlM0h9tdd-V for ; Wed, 30 Nov 2016 13:21:26 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 6A9BC129AB0 for ; Wed, 30 Nov 2016 13:21:09 -0800 (PST)
Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id 3A4AC1E341; Wed, 30 Nov 2016 16:24:28 -0500 (EST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_19133C24-0558-4206-B5F1-1F2377AE7F12"
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
From: Jeffrey Haas 
In-Reply-To: <828EC50E-0659-46F1-90E2-BD883A75A706@juniper.net>
Date: Wed, 30 Nov 2016 16:21:08 -0500
Message-Id: <8FCE845A-5DB6-4630-9F68-949C4B8D3D8F@pfrc.org>
References: <148052490104.3081.2049626653192295584.idtracker@ietfa.amsl.com> <20161130204903.GH10210@Vurt.local>  <828EC50E-0659-46F1-90E2-BD883A75A706@juniper.net>
To: John Scudder 
X-Mailer: Apple Mail (2.3251)
Archived-At: 
Cc: idr@ietf.org
Subject: Re: [Idr] I-D Action: draft-ietf-idr-shutdown-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: Wed, 30 Nov 2016 21:21:28 -0000

--Apple-Mail=_19133C24-0558-4206-B5F1-1F2377AE7F12
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


> On Nov 30, 2016, at 4:13 PM, John G. Scudder  wrote:
>=20
> On Nov 30, 2016, at 3:58 PM, Jeffrey Haas > wrote:
>> I'm somewhat behind in my mail, but why was the data length of the =
notification message not sufficient?
>=20
> It would have been sufficient had the string length not been limited =
to 128 bytes, but it is. Beyond that, if you haven't seen these they =
should provide context.
>=20
> https://www.ietf.org/mail-archive/web/idr/current/msg17117.html =

> https://www.ietf.org/mail-archive/web/idr/current/msg17118.html =

> https://www.ietf.org/mail-archive/web/idr/current/msg17170.html =

Thanks, I hadn't gotten to those yet.
(People get behind on email around IETFs?  Who knew?!)

>=20
>> The main motivation for asking is by having two distinct length =
fields, you now have two different overruns to deal with:
>> 1. The data overruns the length field of the string. (Extra stuff, do =
what?)
>=20
> Presumably what everyone does now, hex dump it.
>=20
>> 2. The length of the string overruns the data. (Not enough stuff, =
completely malformed.)
>=20
> In any case, the connection's going down no matter what so I'm not =
sure there's a need to be as punctilious about error cases as we are for =
other message types.

Yes, it's obvious.  The main reason for commenting is you now have =
additional bits of exception handling in your code.  I was trying to =
figure out why we would want to accommodate a length and incur that =
extra code.

I'm personally a bit undersold on the idea of future stuff being added, =
but I don't strongly object. I'd honestly rather have the option for =
longer shutdown reasons but I also am not going to push on that point.  =
Having lengths a bit more congruent with syslog protocol limits seems =
like a better idea to me.

-- Jeff (although position, length, value feels a bit too XDR like to me =
for comfort)


--Apple-Mail=_19133C24-0558-4206-B5F1-1F2377AE7F12
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii


On Nov 30, 2016, at 4:13 PM, John G. Scudder <jgs@juniper.net> =
wrote:

On Nov 30, 2016, at 3:58 PM, Jeffrey Haas =
<jhaas@pfrc.org> wrote:
I'm somewhat behind in my mail, but why was the data =
length of the notification message not =
sufficient?

It would have been sufficient had the string length not =
been limited to 128 bytes, but it is. Beyond that, if you haven't seen =
these they should provide context.

https://www.ietf.org/mail-archive/web/idr/current/msg17117.html=

https://www.ietf.org/mail-archive/web/idr/current/msg17118.html=

https://www.ietf.org/mail-archive/web/idr/current/msg17170.html=


Thanks, I hadn't =
gotten to those yet.
(People get behind on email around IETFs? =
 Who knew?!)


The main motivation for asking is by having two distinct =
length fields, you now have two different overruns to deal =
with:
1. The data overruns the length field of the =
string. (Extra stuff, do what?)

Presumably what everyone does now, hex =
dump it.

2. The length of =
the string overruns the data. (Not enough stuff, completely =
malformed.)

In any case, the connection's going =
down no matter what so I'm not sure there's a need to be as punctilious =
about error cases as we are for other message =
types.

Yes, it's =
obvious.  The main reason for commenting is you now have additional =
bits of exception handling in your code.  I was trying to figure =
out why we would want to accommodate a length and incur that extra =
code.

I'm personally a bit undersold =
on the idea of future stuff being added, but I don't strongly object. =
I'd honestly rather have the option for longer shutdown reasons but I =
also am not going to push on that point.  Having lengths a bit more =
congruent with syslog protocol limits seems like a better idea to =
me.

-- Jeff (although position, =
length, value feels a bit too XDR like to me for comfort)

=

--Apple-Mail=_19133C24-0558-4206-B5F1-1F2377AE7F12--


From nobody Wed Nov 30 13:34:27 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C032129B21 for ; Wed, 30 Nov 2016 13:34:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.417
X-Spam-Level: 
X-Spam-Status: No, score=-17.417 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=-2.896, 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 blRLIWCnpeL3 for ; Wed, 30 Nov 2016 13:34:24 -0800 (PST)
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 DFAEF12949F for ; Wed, 30 Nov 2016 13:34:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13294; q=dns/txt; s=iport; t=1480541663; x=1481751263; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=PIVlgYLtnvx2UbdS42LBZJmQQ5wLQonRNsTpGtUtD7s=; b=PX8jgXyWoebVmKpwQMLU2DxOdJkKPA/9cU9uKuxlMYRFhppmGjRF3g1M T2tn7ycuTgQS77KHobnD3w5VTIzzL38vTWoRWI9Nym2UaYvHDEyEPHc2R GBEopnpcQHGkq/cLEcJq39UdLGPChd9Yld+Ov3Rk3gRHGw6qMJp8aoXo4 c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAQDxRD9Y/40NJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgnM3DgEBAQEBH1iBAweNPpcJj1eFH4IGKYV5AoF9PxQBAgEBAQE?= =?us-ascii?q?BAQFiKIRoAQEBBC1MEAIBCA4DBAEBKAcyFAkIAgQBDQUIiGUOrwqLSAEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBARcFhj6EW4QbCgYCAVGFKwWJQIsuhWkBkQWBe4R3iUm?= =?us-ascii?q?Nc4QLAR43YTaDVh+BXXIBhWyBMIENAQEB?=
X-IronPort-AV: E=Sophos;i="5.31,574,1473120000";  d="scan'208,217";a="175912792"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Nov 2016 21:34:22 +0000
Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id uAULYMnD027316 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 30 Nov 2016 21:34:22 GMT
Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 30 Nov 2016 15:34:22 -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, 30 Nov 2016 15:34:22 -0600
From: "Jakob Heitz (jheitz)" 
To: Jeffrey Haas , John Scudder 
Thread-Topic: [Idr] I-D Action: draft-ietf-idr-shutdown-01.txt
Thread-Index: AQHSSyqW2EetENBl4EGVU2FiDJhWKaDyZJ2AgAACuYCAAAQUgIAAAioA//+dbxA=
Date: Wed, 30 Nov 2016 21:34:22 +0000
Message-ID: 
References: <148052490104.3081.2049626653192295584.idtracker@ietfa.amsl.com> <20161130204903.GH10210@Vurt.local>  <828EC50E-0659-46F1-90E2-BD883A75A706@juniper.net> <8FCE845A-5DB6-4630-9F68-949C4B8D3D8F@pfrc.org>
In-Reply-To: <8FCE845A-5DB6-4630-9F68-949C4B8D3D8F@pfrc.org>
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.32.152.76]
Content-Type: multipart/alternative; boundary="_000_b98866b0eac34bd4a2c7942334bdba90XCHALN014ciscocom_"
MIME-Version: 1.0
Archived-At: 
Cc: "idr@ietf.org" 
Subject: Re: [Idr] I-D Action: draft-ietf-idr-shutdown-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: Wed, 30 Nov 2016 21:34:26 -0000

--_000_b98866b0eac34bd4a2c7942334bdba90XCHALN014ciscocom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I agree with Jeff.
The potential to add future stuff to this field is quite limited,
given that the field already exists and may have been used for other
purposes. A text field is about as much as you could get away with
under those circumstances. Please don't anyone say CRC.

Thanks,
Jakob.

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jeffrey Haas
Sent: Wednesday, November 30, 2016 1:21 PM
To: John Scudder 
Cc: idr@ietf.org
Subject: Re: [Idr] I-D Action: draft-ietf-idr-shutdown-01.txt


On Nov 30, 2016, at 4:13 PM, John G. Scudder > wrote:

On Nov 30, 2016, at 3:58 PM, Jeffrey Haas > wrote:
I'm somewhat behind in my mail, but why was the data length of the notifica=
tion message not sufficient?

It would have been sufficient had the string length not been limited to 128=
 bytes, but it is. Beyond that, if you haven't seen these they should provi=
de context.

https://www.ietf.org/mail-archive/web/idr/current/msg17117.html
https://www.ietf.org/mail-archive/web/idr/current/msg17118.html
https://www.ietf.org/mail-archive/web/idr/current/msg17170.html

Thanks, I hadn't gotten to those yet.
(People get behind on email around IETFs?  Who knew?!)




The main motivation for asking is by having two distinct length fields, you=
 now have two different overruns to deal with:
1. The data overruns the length field of the string. (Extra stuff, do what?=
)

Presumably what everyone does now, hex dump it.


2. The length of the string overruns the data. (Not enough stuff, completel=
y malformed.)

In any case, the connection's going down no matter what so I'm not sure the=
re's a need to be as punctilious about error cases as we are for other mess=
age types.

Yes, it's obvious.  The main reason for commenting is you now have addition=
al bits of exception handling in your code.  I was trying to figure out why=
 we would want to accommodate a length and incur that extra code.

I'm personally a bit undersold on the idea of future stuff being added, but=
 I don't strongly object. I'd honestly rather have the option for longer sh=
utdown reasons but I also am not going to push on that point.  Having lengt=
hs a bit more congruent with syslog protocol limits seems like a better ide=
a to me.

-- Jeff (although position, length, value feels a bit too XDR like to me fo=
r comfort)


--_000_b98866b0eac34bd4a2c7942334bdba90XCHALN014ciscocom_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











I agree wi=
th Jeff.


The potential to add future stuff to t=
his field is quite limited,


given that the field already exists an=
d may have been used for other


purposes. A text field is about as muc=
h as you could get away with


under those circumstances. Please don'=
t anyone say CRC.


 




Thanks,


Jakob.




 








From: Idr [mailto:idr-bounces@ietf.o=
rg]
On Behalf Of Jeffrey Haas

Sent: Wednesday, November 30, 2016 1:21 PM

To: John Scudder <jgs@juniper.net>

Cc: idr@ietf.org

Subject: Re: [Idr] I-D Action: draft-ietf-idr-shutdown-01.txt






 


 








On Nov 30, 2016, at 4:13 PM, John G. Scudder <jgs@juniper.net> wrote:



 




On Nov 30, 2016, at 3:58 PM, Jeffrey Haas <jhaas@pfrc.org>
 wrote:










I'm somewhat behind in my mail, but why was the da=
ta length of the notification message not sufficient?










 




It would have been sufficient had the string lengt=
h not been limited to 128 bytes, but it is. Beyond that, if you haven't see=
n these they should provide context.






 













 




Thanks, I hadn't gotten to those yet.






(People get behind on email around IETFs?  Who =
knew?!)


































The main motivation for asking is by having two di=
stinct length fields, you now have two different overruns to deal with:






1. The data overruns the length field of the strin=
g. (Extra stuff, do what?)












 




Presumably what everyone does now, hex dump it.





















2. The length of the string overruns the data. (No=
t enough stuff, completely malformed.)












 






In any case, the connection's going down no matter=
 what so I'm not sure there's a need to be as punctilious about error cases=
 as we are for other message types.












 




Yes, it's obvious.  The main reason for comment=
ing is you now have additional bits of exception handling in your code. &nb=
sp;I was trying to figure out why we would want to accommodate a length and=
 incur that extra code.






 






I'm personally a bit undersold on the idea of future=
 stuff being added, but I don't strongly object. I'd honestly rather have t=
he option for longer shutdown reasons but I also am not going to push on th=
at point.  Having lengths a bit more
 congruent with syslog protocol limits seems like a better idea to me.=







 






-- Jeff (although position, length, value feels a bi=
t too XDR like to me for comfort)






 










--_000_b98866b0eac34bd4a2c7942334bdba90XCHALN014ciscocom_--


From nobody Wed Nov 30 13:52:42 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ABA6129B59 for ; Wed, 30 Nov 2016 13:52:41 -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, 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] 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 SwSD7W-wIlXr for ; Wed, 30 Nov 2016 13:52:39 -0800 (PST)
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0120.outbound.protection.outlook.com [104.47.40.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7D08129B57 for ; Wed, 30 Nov 2016 13:52:38 -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=pp4dTX8vRZFc3NqUn3U2FXjYOkn9avGyJEag1UV/C3o=; b=BF9p6Qa3+S32KOlRODvc+8WIEGWvCsDXHzohR0VmEjU1o6eED2Mezn1s7iRQZTLVDElRmYMQrFQguKteGefe8pP0kRmH6qU0Jb9vSA0cqs003hbNEX1no5vHW+hyCfi2VYdZOetS/RLPYngVyVga3y1cMdXZhnqv5xg7zv4K0QY=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; 
Received: from [172.29.33.83] (66.129.241.12) by SN2PR05MB2509.namprd05.prod.outlook.com (10.166.213.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.761.5; Wed, 30 Nov 2016 21:52:33 +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: 
Date: Wed, 30 Nov 2016 16:52:29 -0500
Content-Transfer-Encoding: quoted-printable
Message-ID: 
References: <148052490104.3081.2049626653192295584.idtracker@ietfa.amsl.com> <20161130204903.GH10210@Vurt.local>  <828EC50E-0659-46F1-90E2-BD883A75A706@juniper.net> <8FCE845A-5DB6-4630-9F68-949C4B8D3D8F@pfrc.org> 
To: "Jakob Heitz (jheitz)" 
X-Mailer: Apple Mail (2.3124)
X-Originating-IP: [66.129.241.12]
X-ClientProxiedBy: BN3PR0301CA0026.namprd03.prod.outlook.com (10.160.180.164) To SN2PR05MB2509.namprd05.prod.outlook.com (10.166.213.18)
X-MS-Office365-Filtering-Correlation-Id: 7d5481c4-91de-448a-f1ef-08d4196b3123
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SN2PR05MB2509;
X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2509; 3:GGZsJ22gdbmuMoOvV3GCbtdVUJPQtS6Fpp0Z06XNLBqiKxSrUx3Sm5oQ5tSbi21qeJWS3F1aVtcLX0+mFj9KO+LAxGmcjP76xqMu/0ylqvcbXwcBKi7dm2UwdojG3m9TI8NzUuraT1xVKxop2Shsuj05jXAjLDK9OQjRlRiFyzaWFeZk0lr1ChYG0YExZVYrkMqL8YO35jHGnquq+R4xkGRo2XG9R3M3SrDcUDvMecMoWKGhCqgIzPqXuevLT6H9JprkBrBVqPpiLKGp2ZhQbA==; 25:d/rrdjLagFsu7xh5gBY99F37fxg9Ay2aZ+Pv/o2INLbS1uSv7z5MhHKElxf5SAiWGNV2jeyflAaaK+4+ayNu0ted1R/RXA5HjUITURVwU2RRSx9on4014pBJWtq2yZD7sPLGLLSfmeLvn/ZY4fDUm5XMAr79xMGK6ei8PCivAfwD1ZJtFAJiImredE30JS8CQmVSLgyDBVucPKTOhy47glKp/0YsjuW/agD1/F1kBsjP5q/LEvqIpfjcCXdDk+jdto3KOUvqWXdlItdg9/F67CSt2Lg2xPI1voBhU8O6e9PgCR12XLPUf7nHRHIQ8Us2zl33XnSLJHK2QszM2Zwpa4kRR5e9+nUMH4FV3KpK49pMqfeJCFb3Q5GhP42f2jvYq/vtJxtNWT34hIqgMsnm1DKCnM7DOKVZrwV2UbfboYlmMzYtvSbmhRjnFbp2ZPggjogkUdCFuBQmmptAgpF4ew==
X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2509; 31:3yCGO0ZlUKs7ENcwIBYRwLfUhjVsVHe75gEPoTUP332P9WP8kOpnNDBNTX8ZV49hKjn8vHDwMt0p6NYZ3w9D4efmCtKOY1ybIaBGz2Me7QrLCyEH3DMzCc2YCChVC9SpFiZmPyK6Z9gQcD79+gqejRr+uxkqc/j/Dlyn0GoTJMnf3TcEr73rVA8xsdhSQBunFwHZ03s7rdxPgvYABuvRp4Ct+6ADzG+6XCr78K/CAtgwi9v5/RkNGjTEazXEwFl8tKxVZJF0s9AoVWqs9i0UUXATsUyd5xNw8EERRqBCm7U=; 20:NTh2/uKOA5FuLWBiwrZqi8xgLzEmtNpajuX+EoiF5djESPaR4+r/wbn+yoawhLAJU7fM5JZEJUPrwnKVe8zPZh7pc5LCSPP+ftK9hEoLGJOUqHk9t2mlzLpMk+qqxIjPanU4syhjtKXregRsqhsWSdr6KYf3lgC1PHZSqNWerjJqVusszubhjQDegqZWmYgzpq8H2gYtqMj5MOfU9f84T9II3UDmTZNyySOutGHPKPOMMIPK7zpGe5RgDmtcoB3k8Z6hQza7yfOXq6zT8xCUcso/VFQV5imDfs8uhcfFVwJ9UYY3h4GsP51qTuH4HzPr9MgV4w7aFEzhp0Wmo5fNuUKTHIslt5U0zkbCQthGYeKQqZkSW6+/SOZEoG5AaM94tan8Kt6tdOx4CvqAXM22pRzX6RmTZxOfWsLE9kCU1qtYaTX6TmVFnspTG50H/XYAnFY2iX0KLXhGFv7Px1wcgK2FVnnn23FCXYKhFplHEw5QPG8kKbi1eOns6TCBfj+LqNO/9SQSQq8aMkRE2LZgSIh8Rkh8+xCXPcsdloaXweOCXV0I/WAz2LtmJqNwHZKQZLOB+dThUURpkXRD6xOvFAvfeCyK5kzT6caTKelNx/E=
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)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(6072148); SRVR:SN2PR05MB2509; BCL:0; PCL:0; RULEID:; SRVR:SN2PR05MB2509; 
X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2509; 4:0CxWNZnWowmrpCAxV06p3t0oa8oH/QL/oQgFUFd2a4UCVkA/jQ/wG4xqLs8Ngb97kzE7NOIc7eMuYjclTaI4tV022H6wmWR9P0VpIpMRzvKNN7X0nQS8TDwBiw6frnUEZtgMLxkt56DX/umFn0FyCrmw6avWscVew7cnOKYrKoA2NScKnXJF4Lo0ItJzov+Lb1l/oWHrg+rxsEzRd5+54Bv/co1rmv1W/n7NcJnzzqNpbkae1SMr46cZKhd17lRmfF/7o5lRsJ76JDqmhuXjIyZV/ojK80nr2gEUQ/onxK3C5ILcvB+Q3Zt/pXYGU/rhAAJ5zLHjBjz050hOH5+d9Cd9ZOfbHVlKwp+BRueqet5Qd8+f9uO4GbjqjoBhcaoKQT4YgbrmMxYVSC6uvmGwFv5ZDlibyYkcFA3WGU5FayaI1/D/84iXSB9O/BMfBQgz0zObMKEM7C4+Ddqgqg+vKaJtg5naE1672CSYB+nR6Gu7ynZc/kFsbJEJYGwgpZFTzuOXe3Ldwu5UKPhDKNq4gIdBU5OVcFsIY2Cz2zbgKM9JO98Ed4ow1PlTZrJjKLqecMxLfrDmgYdfEEfUZyUKQgNCBW8FcfjFnG7j716GQSAlYJzvhdEXm6RoZ0xqOEHUxDKAXrA4mvRuAvDnphVaMQ==
X-Forefront-PRVS: 0142F22657
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(7916002)(199003)(189002)(377454003)(24454002)(6666003)(2950100002)(76176999)(92566002)(50986999)(8676002)(81166006)(8746002)(229853002)(36756003)(81156014)(42186005)(33656002)(47776003)(38730400001)(6916009)(50466002)(7736002)(7846002)(6486002)(46406003)(77096006)(230783001)(68736007)(2906002)(189998001)(39450400002)(82746002)(93886004)(83716003)(733004)(3846002)(110136003)(39410400001)(305945005)(4326007)(6116002)(105586002)(66066001)(101416001)(97756001)(106356001)(86362001)(23726003)(97736004)(57306001)(50226002)(5660300001)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR05MB2509; H:[172.29.33.83]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN2PR05MB2509; 23:46yZloO+kA3wlI1efANEJHmhB6EyqybWdMybR3Xin?= =?us-ascii?Q?H/eEL+rKMHX5vSHTavAVcTYqgpOUyNX9mgDb2DFukhXyOx3lzYrvDXR35Krm?= =?us-ascii?Q?dAZd4KYNhZ/T8Ef+xoEgoVi9Sd9DdhDBEQI2pENg0ygKXyI33tVJXj5EtzXO?= =?us-ascii?Q?7JIULIAl3VXk3gIe1M0vV74MSKnFjpkHkFXmGTBkBzGb+fJbI7VUnKxDKzWs?= =?us-ascii?Q?P+lKXxZ7AsRKTEn7lEAt7qRJv15ns7uAo2aO9Ad8E65qESUjBj3I3VnbtEfR?= =?us-ascii?Q?Qi0eQJV9Y/6nmkpqlZtB/llhHa05QtQlx6h1H6xvtL7fZZImR91G6hoLm9NW?= =?us-ascii?Q?36zL4u7N0w3TlSb9Pb6u6sggfZXwzuzBXdgYhH7u8HxtbPQdXO2+3p0DDk3E?= =?us-ascii?Q?kvygvrBAWxK/GXnOdeRqKqhWHvAZvghOv1XmhR/GAvaUxoEzKHPqU2A3pBm2?= =?us-ascii?Q?2kGCVTrm259EU6cEbqdd8n1aHuzlVm7KQo1mAJ3Qcy5GSYnW7WqD5q3maRNV?= =?us-ascii?Q?6DQNqurOstwuP9Ec8unuj8E2HD+7Jg0vEVD2vJXn1rT/ys6eRgaatt77kqT5?= =?us-ascii?Q?Om7DseUNV4x4NDHtW0KoCloqnounCPlAfP/mGuY2h909wR16qqmDz/9mamZF?= =?us-ascii?Q?20pVqXAODlgyDeifpbtyhTV5/P089zgovk7eOz/Mo6zwdzvkOruwACf2U714?= =?us-ascii?Q?TZKqYWFMt4OfsWR6dZdxmjFtDntviC44uIQqPew9GK9P0xrBk/5vmU4rt15d?= =?us-ascii?Q?goe9hyZA2t4q65VXmoZK1kHTWHGcGsPBu2bFTX9t5gdfHgyLBaDyuENM3uIJ?= =?us-ascii?Q?rBJ0Nkr9/2b/xgmsQvpxJJc0UJQT1a0NhcIhQKD/yLLqZOrGDtYHqvh5zJuy?= =?us-ascii?Q?n7L6LNyApkAtyJ57zZoN9GaGLHnj5Nb2mHsDYqRZKE0ByE+khVS4JTclnLt7?= =?us-ascii?Q?Nj4Dh2VBBnQpXxHKXugN1pk4AMj4CMw3MlNfx8DzXT2QEgY4gI8HHmorr8kx?= =?us-ascii?Q?TmOR+qwnyg5Cb4fnQrrsjxdvCFfgTqoneLIeFTwe1jFLTdxG9vDogc6YDL9k?= =?us-ascii?Q?qWtK5nv8HmJD1MRd67JdNJyUIyD7SCfmevabRLCT4mZMxJbltwcarYTp7LRz?= =?us-ascii?Q?6GQ+P6nIbb4EG7PCBjPb/fFCd2By98Op3guk9WEI/1fzMFdwz2U5LlwuSYrp?= =?us-ascii?Q?WoDp4FTe9dZxxBBr2d7KJp6/I3akliMCcbCXXOrJTOYmO2wWj+6v80ZJl0QL?= =?us-ascii?Q?uPSZJm6LQ7tC5gMK+iuN3tm+pXwcr/laYkt1cHrGYXwoWn/rURLUJMJap/q/?= =?us-ascii?Q?zbj8RrLxmZwja16VrrBfkRy3RcAN+VnF//pl74KU0By43ge8sYNr8pzgMJow?= =?us-ascii?Q?6xxhw=3D=3D?=
X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2509; 6:aUGXC6ZKGxV13uzzqNY2h+rmQaMTqKo049LXaC9gjdOvc+2rpF72KFl42BCU7hQf1B5eQ1aZ4TWFj61Zpqx15WLbwe4ZBcRR0nBa76jWai4veQEQkua3BcJ9Lc7rnWpRoyzCH1MBeYo5gCKZhvMGNjoOUBH3RRRYUB/LDXHTSpcn0wnsRP4ED2931LU4c4NNlMdohZZWYn6IX6gt/XSakZ9JDWM6B7uOF9RFYXIQfS15KKlzNENc5SFeF1aZSfkaSlG93utq6L+LI3ze9WFxoz6eb6SFf+FCN6DCIh6L2W2dleI4Prr9h2t8/7/HtE6UvOmZCs9BM4MfQgcGY64DTjc0VNd8bgRqBnxAHUDdpD8ZekLG0FcU9Tp4KEqbexyF6guE9CV8aVxpvVrXtdEX74TYOhOwo7KK39RTbV9n6D8qaUqQ6ev6uMP0vnE45XdemztyAeolj50vXwEdhy7UMBSOlr3rd+obO7+dOUqIzX/Oqwz20paCfGTVaIh5PjjI; 5:PM0Z8LlLM/zilQ2sUgh2aVGP/kx2ovkz5Jlki0PA8vOg29+UMQE1PVks0SZR6UC3XJX1ngrnOP+uaU8mbL2ODprgiFJ/kLI46+oLa1z121COr6VbyklqEbPoL/5tCflJCMoYi0qt+3AMZrDmRvQhxQ==; 24:t3neimvjTU/KNvCHqGlETZaNRbRLfXZ/uuHso0GApJVwLR1yfgmVKA3Rxe4fxRYhVCoQAc7DhjfTA3psBh6CB7R1qRxf61n0LR4hxwkTvZQ=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2509; 7:VpG2Ky6pk6nLe2Q1VV18nKcBQNH+zjcL504atO1LiJzV3vRR31Z/4hhegk/heUG8nYU0cgn5Pn/jx50YqioN5bDGJV/a19FTJB/QrE7F/XETsL4tsTZTGfgsSDD1cst3obZgWy1pNgtp4QNu0PUTKqEJcy7jpFfuDyfw+w7SisFD3MIvv6uVinFrMLKuqrInuPZ3+4gFzEiAMSFdF9Sg1B3/fUhOFKKOl5txFCX/phBzYz+9EtMMyB1eSoRTcucViOe0iwoVDiB0UHgYLRnGrCCsTTwUbOU9yhRes0ibC2127cl1ixTlax+gwy8KZQGSmHs7al/9FT/46SSca3Wks8pDvHtIQ8g9QfDmJobE/JLJbQAGHlCrMYO02x8djuNKXPfUKIr6OBFbIaYlm/8A60kacfnbubswdh/YF0V3lalIxb8+IT1/V/unnY5/aTVL2yhJPbamsEGJlUEpM5hjGg==
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Nov 2016 21:52:33.7832 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR05MB2509
Archived-At: 
Cc: "idr@ietf.org" 
Subject: Re: [Idr] I-D Action: draft-ietf-idr-shutdown-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: Wed, 30 Nov 2016 21:52:41 -0000

On Nov 30, 2016, at 4:34 PM, Jakob Heitz (jheitz)  =
wrote:
> I agree with Jeff.
> The potential to add future stuff to this field is quite limited,
> given that the field already exists and may have been used for other
> purposes. A text field is about as much as you could get away with
> under those circumstances. Please don't anyone say CRC.

SHA-3 HMAC, duh. :-)

What I dislike about leaving the string length out is that you're still =
going to have to police the overall data length to make sure it doesn't =
exceed 127 and decide what to do with any trailing data if it does. In =
effect, you've bitten off an implicit length field anyway by accepting =
the length restriction. Whether or not you think further extensibility =
matters is almost beside the point, but if it's available for "free" =
then I don't see a downside.

If the string's length were not limited to 127 then it would be a =
different story, but Job has made a principled argument for restricting =
the length.

--John=


From nobody Wed Nov 30 13:56:32 2016
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56B0F129B39 for ; Wed, 30 Nov 2016 13:56:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.418
X-Spam-Level: 
X-Spam-Status: No, score=-17.418 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=-2.896, 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 gegjHCmoHDpz for ; Wed, 30 Nov 2016 13:56:18 -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 8BB71129B7D for ; Wed, 30 Nov 2016 13:56:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1460; q=dns/txt; s=iport; t=1480542978; x=1481752578; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=5fhpVE2RmLkBS3Q9eJpV42HwiIAK9hXzJeAmKPlDq+o=; b=ff0uqiZ4wRSBkPOTh+2KEjEV00L+WImYA6r7FbNq9A1zr5KCVFrrRpI4 kkzyoKm+JbtFVvoEtS33lZCKJYRs9pCAkaRZFUGcpZGTdi3IguC3SdR7l AqT7y5nOX3BNeJ4+KBDIt+mfCLdtHv3oVry6nl6OfC0dDGJdV1Jv+kSEt I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ATAQBYSj9Y/5ldJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzgBAQEBAR+BWweNPpcJlHaCBoYiAoF9PxQBAgEBAQEBAQFiKIR?= =?us-ascii?q?oAQEBBDo/DAQCAQgRBAEBAR4JBzIUCQgCBA4FCIhlrxqLSQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBARyGPoRbhCWGBQWaVwGRBYF7hHeJSY1zhAsBHjeBF4VScoVtgTC?= =?us-ascii?q?BDQEBAQ?=
X-IronPort-AV: E=Sophos;i="5.31,574,1473120000"; d="scan'208";a="354290381"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Nov 2016 21:56:17 +0000
Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id uAULuHFZ016554 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 30 Nov 2016 21:56:17 GMT
Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 30 Nov 2016 15:56:17 -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, 30 Nov 2016 15:56:17 -0600
From: "Jakob Heitz (jheitz)" 
To: "John G. Scudder" 
Thread-Topic: [Idr] I-D Action: draft-ietf-idr-shutdown-01.txt
Thread-Index: AQHSSyqW2EetENBl4EGVU2FiDJhWKaDyZJ2AgAACuYCAAAQUgIAAAioA//+dbxCAAGtUgP//nCjQ
Date: Wed, 30 Nov 2016 21:56:16 +0000
Message-ID: <4bab108b7f664f8a8e393619cdfdf788@XCH-ALN-014.cisco.com>
References: <148052490104.3081.2049626653192295584.idtracker@ietfa.amsl.com> <20161130204903.GH10210@Vurt.local>  <828EC50E-0659-46F1-90E2-BD883A75A706@juniper.net> <8FCE845A-5DB6-4630-9F68-949C4B8D3D8F@pfrc.org>  
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: [10.32.152.76]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: "idr@ietf.org" 
Subject: Re: [Idr] I-D Action: draft-ietf-idr-shutdown-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: Wed, 30 Nov 2016 21:56:22 -0000

I also agree with Jeff not to object and not to push for it.

Thanks,
Jakob.


> -----Original Message-----
> From: John G. Scudder [mailto:jgs@juniper.net]
> Sent: Wednesday, November 30, 2016 1:52 PM
> To: Jakob Heitz (jheitz) 
> Cc: Jeffrey Haas ; idr@ietf.org
> Subject: Re: [Idr] I-D Action: draft-ietf-idr-shutdown-01.txt
>=20
> On Nov 30, 2016, at 4:34 PM, Jakob Heitz (jheitz)  wrot=
e:
> > I agree with Jeff.
> > The potential to add future stuff to this field is quite limited,
> > given that the field already exists and may have been used for other
> > purposes. A text field is about as much as you could get away with
> > under those circumstances. Please don't anyone say CRC.
>=20
> SHA-3 HMAC, duh. :-)
>=20
> What I dislike about leaving the string length out is that you're still g=
oing to have to police the overall data
> length to make sure it doesn't exceed 127 and decide what to do with any =
trailing data if it does. In effect, you've
> bitten off an implicit length field anyway by accepting the length restri=
ction. Whether or not you think further
> extensibility matters is almost beside the point, but if it's available f=
or "free" then I don't see a downside.
>=20
> If the string's length were not limited to 127 then it would be a differe=
nt story, but Job has made a principled
> argument for restricting the length.
>=20
> --John